am33xx: Update serial platdata to update reg_offset to 0

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 <[email protected]>

---

Verified the patch on AM335x BBB ad AM335x EVMsk.

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

arch/arm/cpu/armv7/am33xx/board.c +6 -6

index e8d5be3..2963b3b 100644
@@ -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
 };

Quoted 5 lines · Mugunthan V N

Quoted 5 lines

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 <[email protected]>

This will be true for OMAP5+ platforms as well. I guess that array also needs to be updated?

Quoted 7 lines · Lokesh Vutla

Quoted 5 lines · Mugunthan V N

Quoted 5 lines

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.

Quoted 4 lines

Acked-by Lokesh Vutla <[email protected]>

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 mailing list
U-Boot at lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Quoted 13 lines · Mugunthan V N

Quoted 11 lines · Lokesh Vutla

Quoted 5 lines · Mugunthan V N

Quoted 5 lines

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 <[email protected]>

This will be true for OMAP5+ platforms as well. I guess that array also needs to be updated?

Quoted 2 lines

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.

Quoted 14 lines · Adam Ford

Quoted 13 lines · Mugunthan V N

Quoted 11 lines · Lokesh Vutla

Quoted 5 lines · Mugunthan V N

Quoted 5 lines

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 <[email protected]>

This will be true for OMAP5+ platforms as well. I guess that array also needs to be updated?

Quoted 6 lines

Quoted 2 lines

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

Quoted 22 lines · Michal Simek

Quoted 14 lines · Adam Ford

Quoted 13 lines · Mugunthan V N

Quoted 11 lines · Lokesh Vutla

Quoted 5 lines · Mugunthan V N

Quoted 5 lines

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 <[email protected]>

This will be true for OMAP5+ platforms as well. I guess that array also needs to be updated?

Quoted 6 lines

Quoted 2 lines

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.

Quoted 5 lines

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.

Quoted 36 lines · Adam Ford

Quoted 22 lines · Michal Simek

Quoted 14 lines · Adam Ford

Quoted 13 lines · Mugunthan V N

Quoted 11 lines · Lokesh Vutla

Quoted 5 lines · Mugunthan V N

Quoted 5 lines

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 <[email protected]>

This will be true for OMAP5+ platforms as well. I guess that array also needs to be updated?

Quoted 6 lines

Quoted 2 lines

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.

Quoted 5 lines

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.

Quoted 3 lines

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

Quoted 41 lines · Michal Simek

Quoted 39 lines · Adam Ford

Quoted 22 lines · Michal Simek

Quoted 14 lines · Adam Ford

Quoted 13 lines · Mugunthan V N

Quoted 11 lines · Lokesh Vutla

Quoted 5 lines · Mugunthan V N

Quoted 5 lines

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 <[email protected]>

This will be true for OMAP5+ platforms as well. I guess that array also needs to be updated?

Quoted 6 lines

Quoted 2 lines

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.

Quoted 5 lines

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.

Quoted 4 lines

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.

Adam

Quoted 47 lines · Adam Ford

Quoted 45 lines · Michal Simek

Quoted 36 lines · Adam Ford

Quoted 22 lines · Michal Simek

Quoted 14 lines · Adam Ford

Quoted 13 lines · Mugunthan V N

Quoted 11 lines · Lokesh Vutla

Quoted 5 lines · Mugunthan V N

Quoted 5 lines

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 <[email protected]>

This will be true for OMAP5+ platforms as well. I guess that array also needs to be updated?

Quoted 6 lines

Quoted 2 lines

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.

Quoted 5 lines

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.

Quoted 3 lines

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.

Quoted 4 lines

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