[U-Boot] [PATCH 1/1] 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 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 };
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 };
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
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@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
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
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
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
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
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
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
participants (4)
-
Adam Ford -
Lokesh Vutla -
Michal Simek -
Mugunthan V N