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

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

[Mugunthan V N]

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.

Signed-off-by: Mugunthan V N <mugunthanvnm@ti.com>
---

Verified the patch on AM335x BBB ad AM335x EVMsk.

---
 arch/arm/cpu/armv7/am33xx/board.c | 12 ++++++------
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/arch/arm/cpu/armv7/am33xx/board.c b/arch/arm/cpu/armv7/am33xx/board.c
index e8d5be3..2963b3b 100644
--- a/arch/arm/cpu/armv7/am33xx/board.c
+++ b/arch/arm/cpu/armv7/am33xx/board.c
@@ -40,14 +40,14 @@ DECLARE_GLOBAL_DATA_PTR;
 
 #if !CONFIG_IS_ENABLED(OF_CONTROL)
 static const struct ns16550_platdata am33xx_serial[] = {
-	{ CONFIG_SYS_NS16550_COM1, 2, CONFIG_SYS_NS16550_CLK },
+	{ CONFIG_SYS_NS16550_COM1, 0, 2, CONFIG_SYS_NS16550_CLK },
 # ifdef CONFIG_SYS_NS16550_COM2
-	{ CONFIG_SYS_NS16550_COM2, 2, CONFIG_SYS_NS16550_CLK },
+	{ CONFIG_SYS_NS16550_COM2, 0, 2, CONFIG_SYS_NS16550_CLK },
 #  ifdef CONFIG_SYS_NS16550_COM3
-	{ CONFIG_SYS_NS16550_COM3, 2, CONFIG_SYS_NS16550_CLK },
-	{ CONFIG_SYS_NS16550_COM4, 2, CONFIG_SYS_NS16550_CLK },
-	{ CONFIG_SYS_NS16550_COM5, 2, CONFIG_SYS_NS16550_CLK },
-	{ CONFIG_SYS_NS16550_COM6, 2, CONFIG_SYS_NS16550_CLK },
+	{ CONFIG_SYS_NS16550_COM3, 0, 2, CONFIG_SYS_NS16550_CLK },
+	{ CONFIG_SYS_NS16550_COM4, 0, 2, CONFIG_SYS_NS16550_CLK },
+	{ CONFIG_SYS_NS16550_COM5, 0, 2, CONFIG_SYS_NS16550_CLK },
+	{ CONFIG_SYS_NS16550_COM6, 0, 2, CONFIG_SYS_NS16550_CLK },
 #  endif
 # endif
 };
-- 
2.7.2.333.g70bd996

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

[Lokesh Vutla]

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?

Thanks and regards,
Lokesh

> 
> Signed-off-by: Mugunthan V N <mugunthanvnm@ti.com>
> ---
> 
> Verified the patch on AM335x BBB ad AM335x EVMsk.
> 
> ---
>  arch/arm/cpu/armv7/am33xx/board.c | 12 ++++++------
>  1 file changed, 6 insertions(+), 6 deletions(-)
> 
> diff --git a/arch/arm/cpu/armv7/am33xx/board.c b/arch/arm/cpu/armv7/am33xx/board.c
> index e8d5be3..2963b3b 100644
> --- a/arch/arm/cpu/armv7/am33xx/board.c
> +++ b/arch/arm/cpu/armv7/am33xx/board.c
> @@ -40,14 +40,14 @@ DECLARE_GLOBAL_DATA_PTR;
>  
>  #if !CONFIG_IS_ENABLED(OF_CONTROL)
>  static const struct ns16550_platdata am33xx_serial[] = {
> -	{ CONFIG_SYS_NS16550_COM1, 2, CONFIG_SYS_NS16550_CLK },
> +	{ CONFIG_SYS_NS16550_COM1, 0, 2, CONFIG_SYS_NS16550_CLK },
>  # ifdef CONFIG_SYS_NS16550_COM2
> -	{ CONFIG_SYS_NS16550_COM2, 2, CONFIG_SYS_NS16550_CLK },
> +	{ CONFIG_SYS_NS16550_COM2, 0, 2, CONFIG_SYS_NS16550_CLK },
>  #  ifdef CONFIG_SYS_NS16550_COM3
> -	{ CONFIG_SYS_NS16550_COM3, 2, CONFIG_SYS_NS16550_CLK },
> -	{ CONFIG_SYS_NS16550_COM4, 2, CONFIG_SYS_NS16550_CLK },
> -	{ CONFIG_SYS_NS16550_COM5, 2, CONFIG_SYS_NS16550_CLK },
> -	{ CONFIG_SYS_NS16550_COM6, 2, CONFIG_SYS_NS16550_CLK },
> +	{ CONFIG_SYS_NS16550_COM3, 0, 2, CONFIG_SYS_NS16550_CLK },
> +	{ CONFIG_SYS_NS16550_COM4, 0, 2, CONFIG_SYS_NS16550_CLK },
> +	{ CONFIG_SYS_NS16550_COM5, 0, 2, CONFIG_SYS_NS16550_CLK },
> +	{ CONFIG_SYS_NS16550_COM6, 0, 2, CONFIG_SYS_NS16550_CLK },
>  #  endif
>  # endif
>  };
> 

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

[Mugunthan V N]

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.

Regards
Mugunthan V n

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

[Adam Ford]

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.

> Regards
> Mugunthan V n
> _______________________________________________
> U-Boot mailing list
> U-Boot at lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot

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

[Michal Simek]

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.

Thanks,
Michal

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

[Adam Ford]

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.

adam

> Thanks,
> Michal
>

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

[Michal Simek]

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

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

[Adam Ford]

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.


> Thanks,
> Michal
>

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

[Mugunthan V N]

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

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

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