On 2.3.2016 13:18, Adam Ford wrote:
On Wed, Mar 2, 2016 at 5:53 AM, Michal Simek michal.simek@xilinx.com wrote:
On 2.3.2016 12:09, Adam Ford wrote:
On Mon, Feb 29, 2016 at 11:55 PM, Mugunthan V N mugunthanvnm@ti.com 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 lokeshvutla@ti.com
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