From mboxrd@z Thu Jan 1 00:00:00 1970 From: Michal Simek Date: Wed, 2 Mar 2016 13:24:20 +0100 Subject: [U-Boot] [PATCH 1/1] am33xx: Update serial platdata to update reg_offset to 0 In-Reply-To: References: <1456737957-25168-1-git-send-email-mugunthanvnm@ti.com> <56D4105A.3090604@ti.com> <56D52EE6.5040407@ti.com> <56D6D43F.9010909@xilinx.com> Message-ID: <56D6DB74.8080602@xilinx.com> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de On 2.3.2016 13:18, Adam Ford wrote: > On Wed, Mar 2, 2016 at 5:53 AM, Michal Simek wrote: >> On 2.3.2016 12:09, Adam Ford wrote: >>> On Mon, Feb 29, 2016 at 11:55 PM, Mugunthan V N wrote: >>>> On Monday 29 February 2016 03:03 PM, Lokesh Vutla wrote: >>>>> >>>>> On Monday 29 February 2016 02:55 PM, Mugunthan V N wrote: >>>>>>> With commit: d9a3bec682f9 "dm: ns16550: Add support for reg-offset property" >>>>>>> reg_offset is added to the struct ns16550_platdata to be >>>>>>> dt compatible with Linux kernel driver, TI AM335x evms are broken >>>>>>> as the serial platdata updates wrong offsets. Correcting it with >>>>>>> initializing reg_offset to zero. >>>>> Acked-by: Lokesh Vutla >>>>> >>>>> This will be true for OMAP5+ platforms as well. I guess that array also >>>>> needs to be updated? >>>> >>>> Apart from AM335x, no other platform is converted to DM for non-dt boot, >>>> so there is no issues with other TI platforms. >>> >>> Due to the way the structure was changed, a bunch of omap3 boards >>> broke because they hard-coded the values expecting them in a certain >>> order in the structure. The patch has since been reverted. >> >> the patch was reverting just because we are close to release not because >> the patch is wrong. It will be added again in the merge window. >> That's why I am asking you to define your structure right with proper >> assignment or you will deal with this problem pretty soon again. >> The best all these patches should come to the tree before my patch. > > I wasn't trying to imply there was anything wrong with the patch. On > contrary, I was criticizing the hard-coded nature of how the omap3 > boards (and some others) defined it by expecting the data in a certain > order. I have submitted a patch to address (what I think are) all but > the am335x boards. Since there was already a patch submitted for > AM35x, so I didn't want to modify the AM335x again. > > I only mentioned the patch was being reverted because someone was > concerned about the OMAP5+ and I was trying to indicate that there is > some time to look into it. Sorry if I didn't come across correctly. no worries. I just wanted to make it clear because reverting patch is causing problem for microblaze with uart16550 but now it is better then break others. Thanks, Michal