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

[Mugunthan V N <mugunthanvnm@ti.com>]

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@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@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.
>>
> 
> 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.

Regards
Mugunthan V N