All of lore.kernel.org
 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.