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:[email protected]] >>>> Sent: Tuesday, July 17, 2018 4:33 PM >>>> To: Tom Rini <[email protected]> >>>> Cc: Wolfgang Denk <[email protected]>; Felix Brack <[email protected]>; >>>> [email protected]; Stefan Roese <[email protected]>; Alexey Brodkin >>>> <[email protected]>; Michal Simek <[email protected]> >>>> 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 <[email protected]> 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 _______________________________________________ U-Boot mailing list [email protected] https://lists.denx.de/listinfo/u-boot
