From mboxrd@z Thu Jan 1 00:00:00 1970 From: Alexander Graf Date: Tue, 17 Jul 2018 15:34:56 +0200 Subject: [U-Boot] [PATCH] serial: ns16550: Add register shift variable In-Reply-To: <116bd65d-1c25-59f7-75c3-26585522ea56@ltec.ch> References: <1531492980-16543-1-git-send-email-fb@ltec.ch> <20180714104721.A8B69240175@gemini.denx.de> <20180714154933.GF2888@bill-the-cat> <4881796E12491D4BB15146FE0209CE646811421F@DE02WEMBXB.internal.synopsys.com> <4881796E12491D4BB15146FE0209CE64681148D9@DE02WEMBXB.internal.synopsys.com> <116bd65d-1c25-59f7-75c3-26585522ea56@ltec.ch> Message-ID: List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de On 07/17/2018 08:51 AM, Felix Brack wrote: > Hello Alexey, > > On 16.07.2018 17:04, Alexey Brodkin wrote: >> Hi Felix, >> >>> -----Original Message----- >>> From: Felix Brack [mailto:fb at ltec.ch] >>> Sent: Sunday, July 15, 2018 5:02 PM >>> To: Alexey Brodkin ; Tom Rini >>> Cc: u-boot at lists.denx.de; Stefan Roese ; Alexander Graf ; Michal Simek ; >>> Wolfgang Denk >>> Subject: Re: [U-Boot] [PATCH] serial: ns16550: Add register shift variable >>> >>> Hi Alexey, >>> >>> On 15.07.2018 10:43, Alexey Brodkin wrote: >>>> Hi Tom, Felix, all >>>> >>>>> -----Original Message----- >>>>> From: Tom Rini [mailto:trini at konsulko.com] >>>>> Sent: Saturday, July 14, 2018 6:50 PM >>>>> To: Wolfgang Denk >>>>> Cc: Felix Brack ; u-boot at lists.denx.de; Stefan Roese ; Alexey Brodkin ; >>>>> Alexander Graf ; Michal Simek >>>>> Subject: Re: [U-Boot] [PATCH] serial: ns16550: Add register shift variable >>>>> >>>>> 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. >>>> Any chance to get a reference to the commit in Linux kernel that introduces that change? >>>> >>> In fact I believe that the property never existed in the >>> am33xx.dtsi file from Linux. U-Boot commit 85cf0e6299 shows that the >>> property has been added to U-Boot's am33xx.dtsi file. The commit log >>> clearly states why this happened: >>> >>> "With the commit 'c7b9686d5d48 ("ns16550: unify serial_omap")' all >>> TI platforms are broken with DM/DT boot as ns16550 driver expects >>> reg-shift from DT which is not populated for TI platforms. >>> Earlier it worked as it was hard coded to 2 in serial-omap >>> driver. So adding the reg-shift to serial nodes for dra7, am4372 >>> and am33xx dtsi files. Tested this patch on am437x-sk-evm, >>> am437x-gp-evm, am335x-boneblack, dra74x-evm and dra72x-evm." >> Ok so this has nothing to do with changes in Linux kernel I guess. >> Why don't we go the other way around and not just submit >> a change to .dts files in Linux kernel that are missing required properties? >> > I think there is nothing wrong with the kernel's .dtsi files, hence > nothing to be fixed in Linux. > Please read the RFC I posted May 24. It (hopefully) explains the need of > this patch. In short: syncing U-Boot DT files for AM33xx SoC with Linux > DT files will break things. This patch would fix the problem of the > "missing " property. It's not missing, we're just simply misimplementing the semantics of the "compatible" property. Really, with a DT described system you should not need any per-device Kconfig options. Any of those are a very good indicator you're doing something wrong :). Alex