From: Daniel Schwierzeck <daniel.schwierzeck@gmail.com>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH v2 3/5] dm: ns16550: Don't map_physmem for I/O ports
Date: Sat, 21 May 2016 18:50:37 +0200 [thread overview]
Message-ID: <574091DD.8040505@gmail.com> (raw)
In-Reply-To: <CAPnjgZ2+o1OkyjAuN_m1iVD-Cwn=eB3hbqkxkQaGXuoj+2nx=A@mail.gmail.com>
Hi Paul,
Am 18.05.2016 um 16:52 schrieb Simon Glass:
>>>>>>>
>>>>>>> Are you sure systems rely on using I/O ports with map_physmem? The only
>>>>>>> other systems that define CONFIG_SYS_NS16550_PORT_MAPPED are x86 ones,
>>>>>>> in include/configs/x86-common.h, and so far as I can tell they don't use
>>>>>>> device model which suggests this code has simply been untested before. I
>>>>>>> don't see why you would use map_physmem on an I/O port address that is
>>>>>>> then going to be passed to inb/outb & I think the code here is simply
>>>>>>> wrong to do so.
>>>>>>
>>>>>> the current code looks wrong. serial_in_shift() is expanded to inb()
>>>>>> in case of CONFIG_SYS_NS16550_PORT_MAPPED and to
>>>>>> in_le32()/in_be32()/readl()/readb() otherwise. Only in the latter case
>>>>>> a map_physmem() is required and should be done in serial_in_shift()
>>>>>> itself or preferrably only once in
>>>>>> ns16550_serial_ofdata_to_platdata().
>>>>>>
>>>>>> I think the correct approach would be the following:
>>>>>
>>>>> This is better I think. But how about adding a device tree binding to
>>>>> select I/O access? In principle each device might have its own
>>>>> settings.
>>>>
>>>> Note that's what I worked towards last time I had a crack at this, but
>>>> it just expanded into an attempt to tackle the mess that is ns16550.c &
>>>> rather lost sight of the original goal of making Malta work.
>>>>
>>>> https://patchwork.ozlabs.org/patch/575643/
>>>> https://patchwork.ozlabs.org/patch/577194/
>>>
>>> Yes it is tricky. What do you think about the suggestions above?
>>
>> for now we should only fix the broken port-based I/O. Additional DT
>> bindings could be added later. I'd like to merge the DM support on MIPS
>> Malta in this merge window ;)
>
> In that case your patch of moving it to ofdata_to_platdata() looks OK to me.
are you going to send a v4 of this patch? I can also do this if you
like. Then I could apply all other v3 patches of this series.
--
- Daniel
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: OpenPGP digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20160521/c85be92f/attachment.sig>
next prev parent reply other threads:[~2016-05-21 16:50 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-05-16 17:44 [U-Boot] [PATCH v2 0/5] Malta UART using device model & device tree Paul Burton
2016-05-16 17:44 ` [U-Boot] [PATCH v2 1/5] fdt: Support for ISA busses Paul Burton
2016-05-17 12:11 ` Simon Glass
2016-05-16 17:44 ` [U-Boot] [PATCH v2 2/5] fdt: Document the rest of struct of_bus Paul Burton
2016-05-17 12:11 ` Simon Glass
2016-05-16 17:44 ` [U-Boot] [PATCH v2 3/5] dm: ns16550: Don't map_physmem for I/O ports Paul Burton
2016-05-16 18:58 ` Daniel Schwierzeck
2016-05-17 12:11 ` Simon Glass
2016-05-17 12:48 ` Paul Burton
2016-05-17 15:51 ` Daniel Schwierzeck
2016-05-17 15:54 ` Simon Glass
2016-05-17 15:58 ` Paul Burton
2016-05-17 16:00 ` Simon Glass
2016-05-18 10:04 ` Daniel Schwierzeck
2016-05-18 14:52 ` Simon Glass
2016-05-21 16:50 ` Daniel Schwierzeck [this message]
2016-05-24 15:34 ` Paul Burton
2016-05-16 17:44 ` [U-Boot] [PATCH v2 4/5] malta: Tidy up UART address selection Paul Burton
2016-05-16 18:57 ` Daniel Schwierzeck
2016-05-16 17:44 ` [U-Boot] [PATCH v2 5/5] malta: Use device model & tree for UART Paul Burton
2016-05-16 18:56 ` Daniel Schwierzeck
2016-05-17 6:40 ` Paul Burton
2016-05-17 10:57 ` Daniel Schwierzeck
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=574091DD.8040505@gmail.com \
--to=daniel.schwierzeck@gmail.com \
--cc=u-boot@lists.denx.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox