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.
Alex
_______________________________________________
U-Boot mailing list
[email protected]
https://lists.denx.de/listinfo/u-boot
