From mboxrd@z Thu Jan 1 00:00:00 1970 From: Tom Rini Date: Tue, 17 Jul 2018 09:39:34 -0400 Subject: [U-Boot] [PATCH] serial: ns16550: Add register shift variable In-Reply-To: References: <1531492980-16543-1-git-send-email-fb@ltec.ch> <20180714104721.A8B69240175@gemini.denx.de> <20180714154933.GF2888@bill-the-cat> <96ec8334-d8d5-7ba3-3b16-4ff1e2c1b6e7@suse.de> <20180717132527.GC10857@bill-the-cat> Message-ID: <20180717133934.GA3196@bill-the-cat> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de On Tue, Jul 17, 2018 at 03:33:15PM +0200, Alexander Graf wrote: > 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 > >>>>>property for all UART nodes. The actual (4.18+) am33xx.dtsi > >>>>>file from Linux does not define 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 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. Yes and no. For a number of years now the omap-only (ttyOx) driver has been deprecated and the generic ns1665x driver is valid. What does the ns1655x driver do here? -- Tom -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: not available URL: