On Tue, Jul 17, 2018 at 01:34:36PM +0000, Alexey Brodkin wrote:
Hi Alexander, Tom,
-----Original Message----- From: Alexander Graf [mailto:agraf@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@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/driv...
But I would swear that's also not required and the generic ns1655x driver can be used.