public inbox for u-boot@lists.denx.de
 help / color / mirror / Atom feed
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>

  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