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

[Lokesh Vutla]

On Tuesday 17 July 2018 07:13 PM, Alexander Graf wrote:
> 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 at konsulko.com>
>>>> Cc: Wolfgang Denk <wd at denx.de>; Felix Brack <fb at ltec.ch>;
>>>> u-boot at lists.denx.de; Stefan Roese <sr at denx.de>; Alexey Brodkin
>>>> <Alexey.Brodkin at synopsys.com>; Michal Simek <michal.simek at 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 at 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.
> 

omap uart do have the differences with ns16650. Affected to u-boot is
the MDR1 register that enables the IP[1]. Right now the difference is
guarded with OMAP2PLUS.

[1]
http://git.denx.de/?p=u-boot.git;a=blob;f=drivers/serial/ns16550.c;h=9c80090aa72623a826d25f0601b7c0acd9e589c5;hb=HEAD#l157


Thanks and regards,
Lokesh