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

[Tom Rini]

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.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20180717/31fef243/attachment.sig>