[U-Boot] [PATCH] serial: ns16550: Add register shift variable

[Alexander Graf <agraf@suse.de>]

On 07/17/2018 03:41 PM, Tom Rini wrote:
> On Tue, Jul 17, 2018 at 01:34:36PM +0000, Alexey Brodkin wrote:
>> Hi Alexander, Tom,
>>
>>> -----Original Message-----
>>> From: Alexander Graf [mailto:agraf at suse.de]
>>> Sent: Tuesday, July 17, 2018 4:33 PM
>>> To: Tom Rini <trini@konsulko.com>
>>> Cc: Wolfgang Denk <wd@denx.de>; Felix Brack <fb@ltec.ch>; u-boot at lists.denx.de; Stefan Roese <sr@denx.de>; Alexey Brodkin
>>> <Alexey.Brodkin@synopsys.com>; Michal Simek <michal.simek@xilinx.com>
>>> Subject: Re: [U-Boot] [PATCH] serial: ns16550: Add register shift variable
>>>
>>> On 07/17/2018 03:25 PM, Tom Rini wrote:
>>>> On Mon, Jul 16, 2018 at 02:53:26PM +0200, Alexander Graf wrote:
>>>>> On 07/14/2018 05:49 PM, Tom Rini wrote:
>>>>>> On Sat, Jul 14, 2018 at 12:47:21PM +0200, Wolfgang Denk wrote:
>>>>>>> Dear Felix,
>>>>>>>
>>>>>>> In message <1531492980-16543-1-git-send-email-fb@ltec.ch> you wrote:
>>>>>>>> The motivation for writing this patch originates in the
>>>>>>>> effort of synchronizing U-Boot DT to Linux DT for am33xx SOCs.
>>>>>>>> The current am33xx.dtsi file from U-Boot defines the <reg-shift>
>>>>>>>> property for all UART nodes. The actual (4.18+) am33xx.dtsi
>>>>>>>> file from Linux does not define <reg-shift> anymore. To prevent
>>>>>>>> (probably difficult) changes in many .dts and .dtsi files once
>>>>>>>> the synchronization is done, one can use this new variable. For
>>>>>>>> the pdu001 board, for example, SYS_NS16550_REG_SHIFT is set
>>>>>>>> to 2; no need to clutter U-Boot and board specific dts files
>>>>>>>> with <reg-shift> properties.
>>>>>>> Does this mean that U-Boot will not be able to use the same DTB as
>>>>>>> Linux?
>>>>>> To be clear, it's the other way around.  We can't use the Linux dtb/dts
>>>>>> files as they've dropped (and in other cases, aren't adding) these
>>>>>> properties as it's handled differently.
>>>>> What does "differently" mean? Linux tries quite hard to be platform
>>>>> agnostic, so a per-build-target #define surely isn't what they're doing.
>>>> Yes, what exactly is the Linux kernel doing here?
>>>
>>> Linux has a completely separate driver for omap3 (which is wrong too).
>>> But in a nutshell, it basically determines the shift value by the
>>> "compatible" string, so we should too.
>> Here's the driver:
>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/tty/serial/omap-serial.c
> But I would swear that's also not required and the generic ns1655x
> driver can be used.


I don't see the generic driver matching on the omap compatible string. 
So you'd have to convert the DT to the generic ns16650 binding (which 
would mean you also had to include the reg-shift property). I can't find 
any omap DT that does refer to its internal ns16650 by the generic 
binding though.

Again, maybe there's some additional functionality in that omap specific 
driver, like power management, that we don't care about at this point.


Alex