From: Dave Aldridge <fovsoft@gmail.com>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH v3] ns16550: change to allow 32 bit access to registers
Date: Wed, 21 Sep 2011 10:21:04 +0100 [thread overview]
Message-ID: <4E79AC80.10901@gmail.com> (raw)
In-Reply-To: <m2d3f99at4.fsf@ohwell.denx.de>
Hi Detlev
On 09/09/11 13:09, Detlev Zundel wrote:
> Hi,
>
>> Dear Dave Aldridge,
>>
>> In message <1314877212-31552-1-git-send-email-fovsoft@gmail.com> you wrote:
>>> If CONFIG_SYS_NS16550_MEM32 is defined then 32 bit memory
>>> mapped access will be used to read/write the uart registers.
>>>
>>> This is especially useful for SoC devices that implement 16550
>>> compatible uarts but that have peripheral access width constraints.
>>>
>>> Signed-off-by: Dave Aldridge <fovsoft@gmail.com>
>> ...
>>
>>> --- a/drivers/serial/ns16550.c
>>> +++ b/drivers/serial/ns16550.c
>>> @@ -19,6 +19,12 @@
>>> #ifdef CONFIG_SYS_NS16550_PORT_MAPPED
>>> #define serial_out(x,y) outb(x,(ulong)y)
>>> #define serial_in(y) inb((ulong)y)
>>> +#elif defined(CONFIG_SYS_NS16550_MEM32) && (CONFIG_SYS_NS16550_REG_SIZE > 0)
>>> +#define serial_out(x,y) out_be32(y,x)
>>> +#define serial_in(y) in_be32(y)
>>> +#elif defined(CONFIG_SYS_NS16550_MEM32) && (CONFIG_SYS_NS16550_REG_SIZE < 0)
>>> +#define serial_out(x,y) out_le32(y,x)
>>> +#define serial_in(y) in_le32(y)
>>
>> Sorry for the dumb question, but in which way is REG_SIZE > 0 or
>> REG_SIZE < 0 connected to the endianess of the target system?
>>
>> My understanding is that this only defines how byte wide registers
>> need to be padded, i. e. wether they are connected to the highest or
>> to the lowest byte lane. THis has nothing to do with the endianess of
>> the system, and it appears wrong to me, to imply such a relation here.
>>
>> Detlev, what do you think?
>
> I _think_ that if we are concerned with the question of where a one-byte
> entity is placed in relation to its embracing 32-bit unit, then this is
> the definiton of endianness, right? Actually the endianness of the
> UART, and this is exactly what the interpretation of the sign of the
> REG_SIZE macro is.
>
> So if the patch works for Dave, he gets my
>
> Acked-by: Detlev Zundel <dzu@denx.de>
>
> on the latter version.
>
Just to confirm that the V4 patch does work for me.
> Cheers
> Detlev
>
prev parent reply other threads:[~2011-09-21 9:21 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-09-01 11:40 [U-Boot] [PATCH v3] ns16550: change to allow 32 bit access to registers Dave Aldridge
2011-09-01 15:39 ` Tabi Timur-B04825
2011-09-01 16:00 ` Dave Aldridge
2011-09-07 21:22 ` Wolfgang Denk
2011-09-08 9:40 ` Dave Aldridge
2011-09-09 12:09 ` Detlev Zundel
2011-09-21 9:21 ` Dave Aldridge [this message]
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=4E79AC80.10901@gmail.com \
--to=fovsoft@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.