[U-Boot] [PATCH 1/1] am33xx: Update serial platdata to update reg_offset to 0

[Adam Ford]

On Wed, Mar 2, 2016 at 10:49 PM, Mugunthan V N <mugunthanvnm at ti.com> wrote:
> Adam
>
> On Wednesday 02 March 2016 06:25 PM, Adam Ford wrote:
>> On Wed, Mar 2, 2016 at 6:24 AM, Michal Simek <michal.simek at xilinx.com> wrote:
>>> On 2.3.2016 13:18, Adam Ford wrote:
>>>> On Wed, Mar 2, 2016 at 5:53 AM, Michal Simek <michal.simek at 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 at 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 at 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.
>>>
>>
>> Hopefully those patches will get approved so we can get your patch
>> incorporated.   Mugunthan - If you want, I can add your am355x board
>> to my patch or if you want you can review it and take what you need.
>>
>
> You can add am335x uart fix also along with your patch.

I just sent it out.  Sorry it took so long.  I am in the process of
moving, so I don't have much spare time.

Look for [PATCH V6] ARM: Various: Future-proof serial platdata

This should allow the other patch to be brought back without breaking
the rest of our boards and the order of the structure shouldn't matter
any more either.

> Regards
> Mugunthan V N