* [PATCH] arm64: dts: rockchip: decrease rising edge time of UART2 @ 2019-03-03 12:27 ` Katsuhiro Suzuki 0 siblings, 0 replies; 43+ messages in thread From: Katsuhiro Suzuki @ 2019-03-03 12:27 UTC (permalink / raw) To: Heiko Stuebner, linux-rockchip-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r Cc: Katsuhiro Suzuki, linux-kernel-u79uwXL29TY76Z2rM5mHXA, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r This patch increases drive strength of UART2 from 3mA to 12mA for getting more faster rising edge. RockPro64 is using a very high speed rate (1.5Mbps) for UART2. In this setting, a bit width of UART is about 667ns. In my environment (RockPro64 UART2 with FTDI FT232RL UART-USB converter), falling time of RockPro64 UART2 is 40ns, but riging time is over 650ns. So UART receiver will get wrong data, because receiver read intermediate data of rising edge. Rising time becomes 300ns from 650ns if apply this patch. This is not perfect solution but better than now. Signed-off-by: Katsuhiro Suzuki <katsuhiro-WKCMddiH/C4xsqv6Oivclw@public.gmane.org> --- arch/arm64/boot/dts/rockchip/rk3399.dtsi | 9 +++++++-- 1 file changed, 7 insertions(+), 2 deletions(-) diff --git a/arch/arm64/boot/dts/rockchip/rk3399.dtsi b/arch/arm64/boot/dts/rockchip/rk3399.dtsi index beaa92744a64..e3c8f91ead50 100644 --- a/arch/arm64/boot/dts/rockchip/rk3399.dtsi +++ b/arch/arm64/boot/dts/rockchip/rk3399.dtsi @@ -2000,6 +2000,11 @@ drive-strength = <8>; }; + pcfg_pull_up_12ma: pcfg-pull-up-12ma { + bias-pull-up; + drive-strength = <12>; + }; + pcfg_pull_up_18ma: pcfg-pull-up-18ma { bias-pull-up; drive-strength = <18>; @@ -2521,8 +2526,8 @@ uart2c { uart2c_xfer: uart2c-xfer { rockchip,pins = - <4 RK_PC3 RK_FUNC_1 &pcfg_pull_up>, - <4 RK_PC4 RK_FUNC_1 &pcfg_pull_none>; + <4 RK_PC3 RK_FUNC_1 &pcfg_pull_up_12ma>, + <4 RK_PC4 RK_FUNC_1 &pcfg_pull_none_12ma>; }; }; -- 2.20.1 ^ permalink raw reply related [flat|nested] 43+ messages in thread
* [PATCH] arm64: dts: rockchip: decrease rising edge time of UART2 @ 2019-03-03 12:27 ` Katsuhiro Suzuki 0 siblings, 0 replies; 43+ messages in thread From: Katsuhiro Suzuki @ 2019-03-03 12:27 UTC (permalink / raw) To: Heiko Stuebner, linux-rockchip Cc: linux-arm-kernel, linux-kernel, Katsuhiro Suzuki This patch increases drive strength of UART2 from 3mA to 12mA for getting more faster rising edge. RockPro64 is using a very high speed rate (1.5Mbps) for UART2. In this setting, a bit width of UART is about 667ns. In my environment (RockPro64 UART2 with FTDI FT232RL UART-USB converter), falling time of RockPro64 UART2 is 40ns, but riging time is over 650ns. So UART receiver will get wrong data, because receiver read intermediate data of rising edge. Rising time becomes 300ns from 650ns if apply this patch. This is not perfect solution but better than now. Signed-off-by: Katsuhiro Suzuki <katsuhiro@katsuster.net> --- arch/arm64/boot/dts/rockchip/rk3399.dtsi | 9 +++++++-- 1 file changed, 7 insertions(+), 2 deletions(-) diff --git a/arch/arm64/boot/dts/rockchip/rk3399.dtsi b/arch/arm64/boot/dts/rockchip/rk3399.dtsi index beaa92744a64..e3c8f91ead50 100644 --- a/arch/arm64/boot/dts/rockchip/rk3399.dtsi +++ b/arch/arm64/boot/dts/rockchip/rk3399.dtsi @@ -2000,6 +2000,11 @@ drive-strength = <8>; }; + pcfg_pull_up_12ma: pcfg-pull-up-12ma { + bias-pull-up; + drive-strength = <12>; + }; + pcfg_pull_up_18ma: pcfg-pull-up-18ma { bias-pull-up; drive-strength = <18>; @@ -2521,8 +2526,8 @@ uart2c { uart2c_xfer: uart2c-xfer { rockchip,pins = - <4 RK_PC3 RK_FUNC_1 &pcfg_pull_up>, - <4 RK_PC4 RK_FUNC_1 &pcfg_pull_none>; + <4 RK_PC3 RK_FUNC_1 &pcfg_pull_up_12ma>, + <4 RK_PC4 RK_FUNC_1 &pcfg_pull_none_12ma>; }; }; -- 2.20.1 ^ permalink raw reply related [flat|nested] 43+ messages in thread
* [PATCH] arm64: dts: rockchip: decrease rising edge time of UART2 @ 2019-03-03 12:27 ` Katsuhiro Suzuki 0 siblings, 0 replies; 43+ messages in thread From: Katsuhiro Suzuki @ 2019-03-03 12:27 UTC (permalink / raw) To: Heiko Stuebner, linux-rockchip Cc: Katsuhiro Suzuki, linux-kernel, linux-arm-kernel This patch increases drive strength of UART2 from 3mA to 12mA for getting more faster rising edge. RockPro64 is using a very high speed rate (1.5Mbps) for UART2. In this setting, a bit width of UART is about 667ns. In my environment (RockPro64 UART2 with FTDI FT232RL UART-USB converter), falling time of RockPro64 UART2 is 40ns, but riging time is over 650ns. So UART receiver will get wrong data, because receiver read intermediate data of rising edge. Rising time becomes 300ns from 650ns if apply this patch. This is not perfect solution but better than now. Signed-off-by: Katsuhiro Suzuki <katsuhiro@katsuster.net> --- arch/arm64/boot/dts/rockchip/rk3399.dtsi | 9 +++++++-- 1 file changed, 7 insertions(+), 2 deletions(-) diff --git a/arch/arm64/boot/dts/rockchip/rk3399.dtsi b/arch/arm64/boot/dts/rockchip/rk3399.dtsi index beaa92744a64..e3c8f91ead50 100644 --- a/arch/arm64/boot/dts/rockchip/rk3399.dtsi +++ b/arch/arm64/boot/dts/rockchip/rk3399.dtsi @@ -2000,6 +2000,11 @@ drive-strength = <8>; }; + pcfg_pull_up_12ma: pcfg-pull-up-12ma { + bias-pull-up; + drive-strength = <12>; + }; + pcfg_pull_up_18ma: pcfg-pull-up-18ma { bias-pull-up; drive-strength = <18>; @@ -2521,8 +2526,8 @@ uart2c { uart2c_xfer: uart2c-xfer { rockchip,pins = - <4 RK_PC3 RK_FUNC_1 &pcfg_pull_up>, - <4 RK_PC4 RK_FUNC_1 &pcfg_pull_none>; + <4 RK_PC3 RK_FUNC_1 &pcfg_pull_up_12ma>, + <4 RK_PC4 RK_FUNC_1 &pcfg_pull_none_12ma>; }; }; -- 2.20.1 _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply related [flat|nested] 43+ messages in thread
* Re: [PATCH] arm64: dts: rockchip: decrease rising edge time of UART2 2019-03-03 12:27 ` Katsuhiro Suzuki @ 2019-03-03 13:19 ` Heiko Stuebner -1 siblings, 0 replies; 43+ messages in thread From: Heiko Stuebner @ 2019-03-03 13:19 UTC (permalink / raw) To: Katsuhiro Suzuki; +Cc: linux-rockchip, linux-arm-kernel, linux-kernel Hi, Am Sonntag, 3. März 2019, 13:27:05 CET schrieb Katsuhiro Suzuki: > This patch increases drive strength of UART2 from 3mA to 12mA for > getting more faster rising edge. > > RockPro64 is using a very high speed rate (1.5Mbps) for UART2. In > this setting, a bit width of UART is about 667ns. > > In my environment (RockPro64 UART2 with FTDI FT232RL UART-USB > converter), falling time of RockPro64 UART2 is 40ns, but riging time > is over 650ns. So UART receiver will get wrong data, because receiver > read intermediate data of rising edge. > > Rising time becomes 300ns from 650ns if apply this patch. This is not > perfect solution but better than now. > > Signed-off-by: Katsuhiro Suzuki <katsuhiro@katsuster.net> > --- > arch/arm64/boot/dts/rockchip/rk3399.dtsi | 9 +++++++-- > 1 file changed, 7 insertions(+), 2 deletions(-) your changing a core rk3399 property here, so I'd really like to get input from other board stakeholders on this before applying a core change. Could you either include the submitters of other rk3399-boards in the recipient list so that they're aware or limit the change to rockpro64 for the time being (aka overriding the property in the board-dts) please? Thanks Heiko > diff --git a/arch/arm64/boot/dts/rockchip/rk3399.dtsi b/arch/arm64/boot/dts/rockchip/rk3399.dtsi > index beaa92744a64..e3c8f91ead50 100644 > --- a/arch/arm64/boot/dts/rockchip/rk3399.dtsi > +++ b/arch/arm64/boot/dts/rockchip/rk3399.dtsi > @@ -2000,6 +2000,11 @@ > drive-strength = <8>; > }; > > + pcfg_pull_up_12ma: pcfg-pull-up-12ma { > + bias-pull-up; > + drive-strength = <12>; > + }; > + > pcfg_pull_up_18ma: pcfg-pull-up-18ma { > bias-pull-up; > drive-strength = <18>; > @@ -2521,8 +2526,8 @@ > uart2c { > uart2c_xfer: uart2c-xfer { > rockchip,pins = > - <4 RK_PC3 RK_FUNC_1 &pcfg_pull_up>, > - <4 RK_PC4 RK_FUNC_1 &pcfg_pull_none>; > + <4 RK_PC3 RK_FUNC_1 &pcfg_pull_up_12ma>, > + <4 RK_PC4 RK_FUNC_1 &pcfg_pull_none_12ma>; > }; > }; > > ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [PATCH] arm64: dts: rockchip: decrease rising edge time of UART2 @ 2019-03-03 13:19 ` Heiko Stuebner 0 siblings, 0 replies; 43+ messages in thread From: Heiko Stuebner @ 2019-03-03 13:19 UTC (permalink / raw) To: Katsuhiro Suzuki; +Cc: linux-rockchip, linux-kernel, linux-arm-kernel Hi, Am Sonntag, 3. März 2019, 13:27:05 CET schrieb Katsuhiro Suzuki: > This patch increases drive strength of UART2 from 3mA to 12mA for > getting more faster rising edge. > > RockPro64 is using a very high speed rate (1.5Mbps) for UART2. In > this setting, a bit width of UART is about 667ns. > > In my environment (RockPro64 UART2 with FTDI FT232RL UART-USB > converter), falling time of RockPro64 UART2 is 40ns, but riging time > is over 650ns. So UART receiver will get wrong data, because receiver > read intermediate data of rising edge. > > Rising time becomes 300ns from 650ns if apply this patch. This is not > perfect solution but better than now. > > Signed-off-by: Katsuhiro Suzuki <katsuhiro@katsuster.net> > --- > arch/arm64/boot/dts/rockchip/rk3399.dtsi | 9 +++++++-- > 1 file changed, 7 insertions(+), 2 deletions(-) your changing a core rk3399 property here, so I'd really like to get input from other board stakeholders on this before applying a core change. Could you either include the submitters of other rk3399-boards in the recipient list so that they're aware or limit the change to rockpro64 for the time being (aka overriding the property in the board-dts) please? Thanks Heiko > diff --git a/arch/arm64/boot/dts/rockchip/rk3399.dtsi b/arch/arm64/boot/dts/rockchip/rk3399.dtsi > index beaa92744a64..e3c8f91ead50 100644 > --- a/arch/arm64/boot/dts/rockchip/rk3399.dtsi > +++ b/arch/arm64/boot/dts/rockchip/rk3399.dtsi > @@ -2000,6 +2000,11 @@ > drive-strength = <8>; > }; > > + pcfg_pull_up_12ma: pcfg-pull-up-12ma { > + bias-pull-up; > + drive-strength = <12>; > + }; > + > pcfg_pull_up_18ma: pcfg-pull-up-18ma { > bias-pull-up; > drive-strength = <18>; > @@ -2521,8 +2526,8 @@ > uart2c { > uart2c_xfer: uart2c-xfer { > rockchip,pins = > - <4 RK_PC3 RK_FUNC_1 &pcfg_pull_up>, > - <4 RK_PC4 RK_FUNC_1 &pcfg_pull_none>; > + <4 RK_PC3 RK_FUNC_1 &pcfg_pull_up_12ma>, > + <4 RK_PC4 RK_FUNC_1 &pcfg_pull_none_12ma>; > }; > }; > > _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [PATCH] arm64: dts: rockchip: decrease rising edge time of UART2 2019-03-03 13:19 ` Heiko Stuebner (?) @ 2019-03-03 14:03 ` Katsuhiro Suzuki -1 siblings, 0 replies; 43+ messages in thread From: Katsuhiro Suzuki @ 2019-03-03 14:03 UTC (permalink / raw) To: Heiko Stuebner, Akash Gajjar, Brian Norris, Christoph Muellner, Dmitry Torokhov, Douglas Anderson, Enric Balletbo i Serra, Ezequiel Garcia, Jakob Unterwurzacher, Klaus Goger, Levin Du, Linus Walleij, Manivannan Sadhasivam, Matthias Brugger, Oskari Lemmela, Robin Murphy, Shawn Lin Cc: linux-rockchip, linux-arm-kernel, linux-kernel Hello Heiko, Thank you for comments. On 2019/03/03 22:19, Heiko Stuebner wrote: > Hi, > > Am Sonntag, 3. März 2019, 13:27:05 CET schrieb Katsuhiro Suzuki: >> This patch increases drive strength of UART2 from 3mA to 12mA for >> getting more faster rising edge. >> >> RockPro64 is using a very high speed rate (1.5Mbps) for UART2. In >> this setting, a bit width of UART is about 667ns. >> >> In my environment (RockPro64 UART2 with FTDI FT232RL UART-USB >> converter), falling time of RockPro64 UART2 is 40ns, but riging time >> is over 650ns. So UART receiver will get wrong data, because receiver >> read intermediate data of rising edge. >> >> Rising time becomes 300ns from 650ns if apply this patch. This is not >> perfect solution but better than now. >> >> Signed-off-by: Katsuhiro Suzuki <katsuhiro@katsuster.net> >> --- >> arch/arm64/boot/dts/rockchip/rk3399.dtsi | 9 +++++++-- >> 1 file changed, 7 insertions(+), 2 deletions(-) > > your changing a core rk3399 property here, so I'd really like to get > input from other board stakeholders on this before applying a core > change. > > Could you either include the submitters of other rk3399-boards in the > recipient list so that they're aware or limit the change to rockpro64 for > the time being (aka overriding the property in the board-dts) please? > OK, I'm adding other boards members. by ./scripts/get_maintainer.pl arch/arm64/boot/dts/rockchip/rk3399-*.dts RockPro64 directly connect UART2 pins of RK3399 to external connector. I think maybe other RK3399 boards are facing same problem, but I cannot check it because I have RockPro64 only... I'm happy if someone tell me other boards situation. Best Regards, Katsuhiro Suzuki > Thanks > Heiko > > > >> diff --git a/arch/arm64/boot/dts/rockchip/rk3399.dtsi b/arch/arm64/boot/dts/rockchip/rk3399.dtsi >> index beaa92744a64..e3c8f91ead50 100644 >> --- a/arch/arm64/boot/dts/rockchip/rk3399.dtsi >> +++ b/arch/arm64/boot/dts/rockchip/rk3399.dtsi >> @@ -2000,6 +2000,11 @@ >> drive-strength = <8>; >> }; >> >> + pcfg_pull_up_12ma: pcfg-pull-up-12ma { >> + bias-pull-up; >> + drive-strength = <12>; >> + }; >> + >> pcfg_pull_up_18ma: pcfg-pull-up-18ma { >> bias-pull-up; >> drive-strength = <18>; >> @@ -2521,8 +2526,8 @@ >> uart2c { >> uart2c_xfer: uart2c-xfer { >> rockchip,pins = >> - <4 RK_PC3 RK_FUNC_1 &pcfg_pull_up>, >> - <4 RK_PC4 RK_FUNC_1 &pcfg_pull_none>; >> + <4 RK_PC3 RK_FUNC_1 &pcfg_pull_up_12ma>, >> + <4 RK_PC4 RK_FUNC_1 &pcfg_pull_none_12ma>; >> }; >> }; >> >> > > > > > > ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [PATCH] arm64: dts: rockchip: decrease rising edge time of UART2 @ 2019-03-03 14:03 ` Katsuhiro Suzuki 0 siblings, 0 replies; 43+ messages in thread From: Katsuhiro Suzuki @ 2019-03-03 14:03 UTC (permalink / raw) To: Heiko Stuebner, Akash Gajjar, Brian Norris, Christoph Muellner, Dmitry Torokhov, Douglas Anderson, Enric Balletbo i Serra, Ezequiel Garcia, Jakob Unterwurzacher, Klaus Goger, Levin Du, Linus Walleij, Manivannan Sadhasivam, Matthias Brugger, Oskari Lemmela, Robin Murphy, Shawn Lin, Shohei Maruyama, Tomeu Vizoso, Vicente Bergas, Viresh Kumar Cc: linux-rockchip, linux-arm-kernel, linux-kernel Hello Heiko, Thank you for comments. On 2019/03/03 22:19, Heiko Stuebner wrote: > Hi, > > Am Sonntag, 3. März 2019, 13:27:05 CET schrieb Katsuhiro Suzuki: >> This patch increases drive strength of UART2 from 3mA to 12mA for >> getting more faster rising edge. >> >> RockPro64 is using a very high speed rate (1.5Mbps) for UART2. In >> this setting, a bit width of UART is about 667ns. >> >> In my environment (RockPro64 UART2 with FTDI FT232RL UART-USB >> converter), falling time of RockPro64 UART2 is 40ns, but riging time >> is over 650ns. So UART receiver will get wrong data, because receiver >> read intermediate data of rising edge. >> >> Rising time becomes 300ns from 650ns if apply this patch. This is not >> perfect solution but better than now. >> >> Signed-off-by: Katsuhiro Suzuki <katsuhiro@katsuster.net> >> --- >> arch/arm64/boot/dts/rockchip/rk3399.dtsi | 9 +++++++-- >> 1 file changed, 7 insertions(+), 2 deletions(-) > > your changing a core rk3399 property here, so I'd really like to get > input from other board stakeholders on this before applying a core > change. > > Could you either include the submitters of other rk3399-boards in the > recipient list so that they're aware or limit the change to rockpro64 for > the time being (aka overriding the property in the board-dts) please? > OK, I'm adding other boards members. by ./scripts/get_maintainer.pl arch/arm64/boot/dts/rockchip/rk3399-*.dts RockPro64 directly connect UART2 pins of RK3399 to external connector. I think maybe other RK3399 boards are facing same problem, but I cannot check it because I have RockPro64 only... I'm happy if someone tell me other boards situation. Best Regards, Katsuhiro Suzuki > Thanks > Heiko > > > >> diff --git a/arch/arm64/boot/dts/rockchip/rk3399.dtsi b/arch/arm64/boot/dts/rockchip/rk3399.dtsi >> index beaa92744a64..e3c8f91ead50 100644 >> --- a/arch/arm64/boot/dts/rockchip/rk3399.dtsi >> +++ b/arch/arm64/boot/dts/rockchip/rk3399.dtsi >> @@ -2000,6 +2000,11 @@ >> drive-strength = <8>; >> }; >> >> + pcfg_pull_up_12ma: pcfg-pull-up-12ma { >> + bias-pull-up; >> + drive-strength = <12>; >> + }; >> + >> pcfg_pull_up_18ma: pcfg-pull-up-18ma { >> bias-pull-up; >> drive-strength = <18>; >> @@ -2521,8 +2526,8 @@ >> uart2c { >> uart2c_xfer: uart2c-xfer { >> rockchip,pins = >> - <4 RK_PC3 RK_FUNC_1 &pcfg_pull_up>, >> - <4 RK_PC4 RK_FUNC_1 &pcfg_pull_none>; >> + <4 RK_PC3 RK_FUNC_1 &pcfg_pull_up_12ma>, >> + <4 RK_PC4 RK_FUNC_1 &pcfg_pull_none_12ma>; >> }; >> }; >> >> > > > > > > ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [PATCH] arm64: dts: rockchip: decrease rising edge time of UART2 @ 2019-03-03 14:03 ` Katsuhiro Suzuki 0 siblings, 0 replies; 43+ messages in thread From: Katsuhiro Suzuki @ 2019-03-03 14:03 UTC (permalink / raw) To: Heiko Stuebner, Akash Gajjar, Brian Norris, Christoph Muellner, Dmitry Torokhov, Douglas Anderson, Enric Balletbo i Serra, Ezequiel Garcia, Jakob Unterwurzacher, Klaus Goger, Levin Du, Linus Walleij, Manivannan Sadhasivam, Matthias Brugger, Oskari Lemmela, Robin Murphy, Shawn Lin, Shohei Maruyama, Tomeu Vizoso, Vicente Bergas, Viresh Kumar Cc: linux-rockchip, linux-kernel, linux-arm-kernel Hello Heiko, Thank you for comments. On 2019/03/03 22:19, Heiko Stuebner wrote: > Hi, > > Am Sonntag, 3. März 2019, 13:27:05 CET schrieb Katsuhiro Suzuki: >> This patch increases drive strength of UART2 from 3mA to 12mA for >> getting more faster rising edge. >> >> RockPro64 is using a very high speed rate (1.5Mbps) for UART2. In >> this setting, a bit width of UART is about 667ns. >> >> In my environment (RockPro64 UART2 with FTDI FT232RL UART-USB >> converter), falling time of RockPro64 UART2 is 40ns, but riging time >> is over 650ns. So UART receiver will get wrong data, because receiver >> read intermediate data of rising edge. >> >> Rising time becomes 300ns from 650ns if apply this patch. This is not >> perfect solution but better than now. >> >> Signed-off-by: Katsuhiro Suzuki <katsuhiro@katsuster.net> >> --- >> arch/arm64/boot/dts/rockchip/rk3399.dtsi | 9 +++++++-- >> 1 file changed, 7 insertions(+), 2 deletions(-) > > your changing a core rk3399 property here, so I'd really like to get > input from other board stakeholders on this before applying a core > change. > > Could you either include the submitters of other rk3399-boards in the > recipient list so that they're aware or limit the change to rockpro64 for > the time being (aka overriding the property in the board-dts) please? > OK, I'm adding other boards members. by ./scripts/get_maintainer.pl arch/arm64/boot/dts/rockchip/rk3399-*.dts RockPro64 directly connect UART2 pins of RK3399 to external connector. I think maybe other RK3399 boards are facing same problem, but I cannot check it because I have RockPro64 only... I'm happy if someone tell me other boards situation. Best Regards, Katsuhiro Suzuki > Thanks > Heiko > > > >> diff --git a/arch/arm64/boot/dts/rockchip/rk3399.dtsi b/arch/arm64/boot/dts/rockchip/rk3399.dtsi >> index beaa92744a64..e3c8f91ead50 100644 >> --- a/arch/arm64/boot/dts/rockchip/rk3399.dtsi >> +++ b/arch/arm64/boot/dts/rockchip/rk3399.dtsi >> @@ -2000,6 +2000,11 @@ >> drive-strength = <8>; >> }; >> >> + pcfg_pull_up_12ma: pcfg-pull-up-12ma { >> + bias-pull-up; >> + drive-strength = <12>; >> + }; >> + >> pcfg_pull_up_18ma: pcfg-pull-up-18ma { >> bias-pull-up; >> drive-strength = <18>; >> @@ -2521,8 +2526,8 @@ >> uart2c { >> uart2c_xfer: uart2c-xfer { >> rockchip,pins = >> - <4 RK_PC3 RK_FUNC_1 &pcfg_pull_up>, >> - <4 RK_PC4 RK_FUNC_1 &pcfg_pull_none>; >> + <4 RK_PC3 RK_FUNC_1 &pcfg_pull_up_12ma>, >> + <4 RK_PC4 RK_FUNC_1 &pcfg_pull_none_12ma>; >> }; >> }; >> >> > > > > > > _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 43+ messages in thread
[parent not found: <e722acb4-167f-8333-5c8a-b693815273f4-WKCMddiH/C4xsqv6Oivclw@public.gmane.org>]
* Re: [PATCH] arm64: dts: rockchip: decrease rising edge time of UART2 2019-03-03 14:03 ` Katsuhiro Suzuki (?) @ 2019-03-03 15:13 ` Tony McKahan -1 siblings, 0 replies; 43+ messages in thread From: Tony McKahan @ 2019-03-03 15:13 UTC (permalink / raw) To: Katsuhiro Suzuki Cc: Heiko Stuebner, Viresh Kumar, Linus Walleij, linux-kernel-u79uwXL29TY76Z2rM5mHXA, Klaus Goger, Manivannan Sadhasivam, Brian Norris, linux-rockchip-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Shawn Lin, Akash Gajjar, Vicente Bergas, Levin Du, Ezequiel Garcia, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Shohei Maruyama, Matthias Brugger, Tomeu Vizoso, Dmitry Torokhov, Douglas Anderson, Jakob Unterwurzacher, Oskari Lemmela, Enric On Sun, Mar 3, 2019 at 9:04 AM Katsuhiro Suzuki <katsuhiro@katsuster.net> wrote: > > Hello Heiko, > > Thank you for comments. > > On 2019/03/03 22:19, Heiko Stuebner wrote: > > Hi, > > > > Am Sonntag, 3. März 2019, 13:27:05 CET schrieb Katsuhiro Suzuki: > >> This patch increases drive strength of UART2 from 3mA to 12mA for > >> getting more faster rising edge. > >> > >> RockPro64 is using a very high speed rate (1.5Mbps) for UART2. In > >> this setting, a bit width of UART is about 667ns. > >> > >> In my environment (RockPro64 UART2 with FTDI FT232RL UART-USB > >> converter), falling time of RockPro64 UART2 is 40ns, but riging time > >> is over 650ns. So UART receiver will get wrong data, because receiver > >> read intermediate data of rising edge. > >> > >> Rising time becomes 300ns from 650ns if apply this patch. This is not > >> perfect solution but better than now. > >> > >> Signed-off-by: Katsuhiro Suzuki <katsuhiro@katsuster.net> > >> --- > >> arch/arm64/boot/dts/rockchip/rk3399.dtsi | 9 +++++++-- > >> 1 file changed, 7 insertions(+), 2 deletions(-) > > > > your changing a core rk3399 property here, so I'd really like to get > > input from other board stakeholders on this before applying a core > > change. > > > > Could you either include the submitters of other rk3399-boards in the > > recipient list so that they're aware or limit the change to rockpro64 for > > the time being (aka overriding the property in the board-dts) please? > > > > OK, I'm adding other boards members. > by ./scripts/get_maintainer.pl arch/arm64/boot/dts/rockchip/rk3399-*.dts > > > RockPro64 directly connect UART2 pins of RK3399 to external connector. > I think maybe other RK3399 boards are facing same problem, but I cannot > check it because I have RockPro64 only... > > I'm happy if someone tell me other boards situation. I'm pulling out other rockchip boards momentarily to see what kind of population we have. Note these are not all running 5.x kernels, however none of them have the UART2 drive levels modified to my knowledge, and regardless, none show over 100 ns. board: rise/fall rk3399-roc-pc: 90ns/90ns rk3399-rockpro64 V2.0: 90ns/45ns rk3399-rockpro64 V2.1: 40ns/41ns Please make sure there's not a large amount of flux or something around the terminals on your board, that seems excessively high. > > Best Regards, > Katsuhiro Suzuki > > > > Thanks > > Heiko > > > > > > > >> diff --git a/arch/arm64/boot/dts/rockchip/rk3399.dtsi b/arch/arm64/boot/dts/rockchip/rk3399.dtsi > >> index beaa92744a64..e3c8f91ead50 100644 > >> --- a/arch/arm64/boot/dts/rockchip/rk3399.dtsi > >> +++ b/arch/arm64/boot/dts/rockchip/rk3399.dtsi > >> @@ -2000,6 +2000,11 @@ > >> drive-strength = <8>; > >> }; > >> > >> + pcfg_pull_up_12ma: pcfg-pull-up-12ma { > >> + bias-pull-up; > >> + drive-strength = <12>; > >> + }; > >> + > >> pcfg_pull_up_18ma: pcfg-pull-up-18ma { > >> bias-pull-up; > >> drive-strength = <18>; > >> @@ -2521,8 +2526,8 @@ > >> uart2c { > >> uart2c_xfer: uart2c-xfer { > >> rockchip,pins = > >> - <4 RK_PC3 RK_FUNC_1 &pcfg_pull_up>, > >> - <4 RK_PC4 RK_FUNC_1 &pcfg_pull_none>; > >> + <4 RK_PC3 RK_FUNC_1 &pcfg_pull_up_12ma>, > >> + <4 RK_PC4 RK_FUNC_1 &pcfg_pull_none_12ma>; > >> }; > >> }; > >> > >> > > > > > > > > > > > > > > > _______________________________________________ > Linux-rockchip mailing list > Linux-rockchip@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-rockchip _______________________________________________ Linux-rockchip mailing list Linux-rockchip@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-rockchip ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [PATCH] arm64: dts: rockchip: decrease rising edge time of UART2 @ 2019-03-03 15:13 ` Tony McKahan 0 siblings, 0 replies; 43+ messages in thread From: Tony McKahan @ 2019-03-03 15:13 UTC (permalink / raw) To: Katsuhiro Suzuki Cc: Heiko Stuebner, Akash Gajjar, Brian Norris, Christoph Muellner, Dmitry Torokhov, Douglas Anderson, Enric Balletbo i Serra, Ezequiel Garcia, Jakob Unterwurzacher, Klaus Goger, Levin Du, Linus Walleij, Manivannan Sadhasivam, Matthias Brugger, Oskari Lemmela, Robin Murphy, Shawn Lin, Shohei Maruyama, Tomeu Vizoso, Vicente Bergas, Viresh Kumar, linux-rockchip, linux-kernel, linux-arm-kernel On Sun, Mar 3, 2019 at 9:04 AM Katsuhiro Suzuki <katsuhiro@katsuster.net> wrote: > > Hello Heiko, > > Thank you for comments. > > On 2019/03/03 22:19, Heiko Stuebner wrote: > > Hi, > > > > Am Sonntag, 3. März 2019, 13:27:05 CET schrieb Katsuhiro Suzuki: > >> This patch increases drive strength of UART2 from 3mA to 12mA for > >> getting more faster rising edge. > >> > >> RockPro64 is using a very high speed rate (1.5Mbps) for UART2. In > >> this setting, a bit width of UART is about 667ns. > >> > >> In my environment (RockPro64 UART2 with FTDI FT232RL UART-USB > >> converter), falling time of RockPro64 UART2 is 40ns, but riging time > >> is over 650ns. So UART receiver will get wrong data, because receiver > >> read intermediate data of rising edge. > >> > >> Rising time becomes 300ns from 650ns if apply this patch. This is not > >> perfect solution but better than now. > >> > >> Signed-off-by: Katsuhiro Suzuki <katsuhiro@katsuster.net> > >> --- > >> arch/arm64/boot/dts/rockchip/rk3399.dtsi | 9 +++++++-- > >> 1 file changed, 7 insertions(+), 2 deletions(-) > > > > your changing a core rk3399 property here, so I'd really like to get > > input from other board stakeholders on this before applying a core > > change. > > > > Could you either include the submitters of other rk3399-boards in the > > recipient list so that they're aware or limit the change to rockpro64 for > > the time being (aka overriding the property in the board-dts) please? > > > > OK, I'm adding other boards members. > by ./scripts/get_maintainer.pl arch/arm64/boot/dts/rockchip/rk3399-*.dts > > > RockPro64 directly connect UART2 pins of RK3399 to external connector. > I think maybe other RK3399 boards are facing same problem, but I cannot > check it because I have RockPro64 only... > > I'm happy if someone tell me other boards situation. I'm pulling out other rockchip boards momentarily to see what kind of population we have. Note these are not all running 5.x kernels, however none of them have the UART2 drive levels modified to my knowledge, and regardless, none show over 100 ns. board: rise/fall rk3399-roc-pc: 90ns/90ns rk3399-rockpro64 V2.0: 90ns/45ns rk3399-rockpro64 V2.1: 40ns/41ns Please make sure there's not a large amount of flux or something around the terminals on your board, that seems excessively high. > > Best Regards, > Katsuhiro Suzuki > > > > Thanks > > Heiko > > > > > > > >> diff --git a/arch/arm64/boot/dts/rockchip/rk3399.dtsi b/arch/arm64/boot/dts/rockchip/rk3399.dtsi > >> index beaa92744a64..e3c8f91ead50 100644 > >> --- a/arch/arm64/boot/dts/rockchip/rk3399.dtsi > >> +++ b/arch/arm64/boot/dts/rockchip/rk3399.dtsi > >> @@ -2000,6 +2000,11 @@ > >> drive-strength = <8>; > >> }; > >> > >> + pcfg_pull_up_12ma: pcfg-pull-up-12ma { > >> + bias-pull-up; > >> + drive-strength = <12>; > >> + }; > >> + > >> pcfg_pull_up_18ma: pcfg-pull-up-18ma { > >> bias-pull-up; > >> drive-strength = <18>; > >> @@ -2521,8 +2526,8 @@ > >> uart2c { > >> uart2c_xfer: uart2c-xfer { > >> rockchip,pins = > >> - <4 RK_PC3 RK_FUNC_1 &pcfg_pull_up>, > >> - <4 RK_PC4 RK_FUNC_1 &pcfg_pull_none>; > >> + <4 RK_PC3 RK_FUNC_1 &pcfg_pull_up_12ma>, > >> + <4 RK_PC4 RK_FUNC_1 &pcfg_pull_none_12ma>; > >> }; > >> }; > >> > >> > > > > > > > > > > > > > > > _______________________________________________ > Linux-rockchip mailing list > Linux-rockchip@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-rockchip ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [PATCH] arm64: dts: rockchip: decrease rising edge time of UART2 @ 2019-03-03 15:13 ` Tony McKahan 0 siblings, 0 replies; 43+ messages in thread From: Tony McKahan @ 2019-03-03 15:13 UTC (permalink / raw) To: Katsuhiro Suzuki Cc: Heiko Stuebner, Viresh Kumar, Linus Walleij, linux-kernel, Klaus Goger, Manivannan Sadhasivam, Brian Norris, linux-rockchip, Shawn Lin, Akash Gajjar, Vicente Bergas, Levin Du, Ezequiel Garcia, linux-arm-kernel, Shohei Maruyama, Matthias Brugger, Tomeu Vizoso, Dmitry Torokhov, Douglas Anderson, Jakob Unterwurzacher, Oskari Lemmela, Enric Balletbo i Serra, Robin Murphy, Christoph Muellner On Sun, Mar 3, 2019 at 9:04 AM Katsuhiro Suzuki <katsuhiro@katsuster.net> wrote: > > Hello Heiko, > > Thank you for comments. > > On 2019/03/03 22:19, Heiko Stuebner wrote: > > Hi, > > > > Am Sonntag, 3. März 2019, 13:27:05 CET schrieb Katsuhiro Suzuki: > >> This patch increases drive strength of UART2 from 3mA to 12mA for > >> getting more faster rising edge. > >> > >> RockPro64 is using a very high speed rate (1.5Mbps) for UART2. In > >> this setting, a bit width of UART is about 667ns. > >> > >> In my environment (RockPro64 UART2 with FTDI FT232RL UART-USB > >> converter), falling time of RockPro64 UART2 is 40ns, but riging time > >> is over 650ns. So UART receiver will get wrong data, because receiver > >> read intermediate data of rising edge. > >> > >> Rising time becomes 300ns from 650ns if apply this patch. This is not > >> perfect solution but better than now. > >> > >> Signed-off-by: Katsuhiro Suzuki <katsuhiro@katsuster.net> > >> --- > >> arch/arm64/boot/dts/rockchip/rk3399.dtsi | 9 +++++++-- > >> 1 file changed, 7 insertions(+), 2 deletions(-) > > > > your changing a core rk3399 property here, so I'd really like to get > > input from other board stakeholders on this before applying a core > > change. > > > > Could you either include the submitters of other rk3399-boards in the > > recipient list so that they're aware or limit the change to rockpro64 for > > the time being (aka overriding the property in the board-dts) please? > > > > OK, I'm adding other boards members. > by ./scripts/get_maintainer.pl arch/arm64/boot/dts/rockchip/rk3399-*.dts > > > RockPro64 directly connect UART2 pins of RK3399 to external connector. > I think maybe other RK3399 boards are facing same problem, but I cannot > check it because I have RockPro64 only... > > I'm happy if someone tell me other boards situation. I'm pulling out other rockchip boards momentarily to see what kind of population we have. Note these are not all running 5.x kernels, however none of them have the UART2 drive levels modified to my knowledge, and regardless, none show over 100 ns. board: rise/fall rk3399-roc-pc: 90ns/90ns rk3399-rockpro64 V2.0: 90ns/45ns rk3399-rockpro64 V2.1: 40ns/41ns Please make sure there's not a large amount of flux or something around the terminals on your board, that seems excessively high. > > Best Regards, > Katsuhiro Suzuki > > > > Thanks > > Heiko > > > > > > > >> diff --git a/arch/arm64/boot/dts/rockchip/rk3399.dtsi b/arch/arm64/boot/dts/rockchip/rk3399.dtsi > >> index beaa92744a64..e3c8f91ead50 100644 > >> --- a/arch/arm64/boot/dts/rockchip/rk3399.dtsi > >> +++ b/arch/arm64/boot/dts/rockchip/rk3399.dtsi > >> @@ -2000,6 +2000,11 @@ > >> drive-strength = <8>; > >> }; > >> > >> + pcfg_pull_up_12ma: pcfg-pull-up-12ma { > >> + bias-pull-up; > >> + drive-strength = <12>; > >> + }; > >> + > >> pcfg_pull_up_18ma: pcfg-pull-up-18ma { > >> bias-pull-up; > >> drive-strength = <18>; > >> @@ -2521,8 +2526,8 @@ > >> uart2c { > >> uart2c_xfer: uart2c-xfer { > >> rockchip,pins = > >> - <4 RK_PC3 RK_FUNC_1 &pcfg_pull_up>, > >> - <4 RK_PC4 RK_FUNC_1 &pcfg_pull_none>; > >> + <4 RK_PC3 RK_FUNC_1 &pcfg_pull_up_12ma>, > >> + <4 RK_PC4 RK_FUNC_1 &pcfg_pull_none_12ma>; > >> }; > >> }; > >> > >> > > > > > > > > > > > > > > > _______________________________________________ > Linux-rockchip mailing list > Linux-rockchip@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-rockchip _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [PATCH] arm64: dts: rockchip: decrease rising edge time of UART2 2019-03-03 15:13 ` Tony McKahan (?) @ 2019-03-03 17:31 ` Katsuhiro Suzuki -1 siblings, 0 replies; 43+ messages in thread From: Katsuhiro Suzuki @ 2019-03-03 17:31 UTC (permalink / raw) To: Tony McKahan Cc: Heiko Stuebner, Viresh Kumar, Linus Walleij, linux-kernel, Klaus Goger, Manivannan Sadhasivam, Brian Norris, linux-rockchip, Shawn Lin, Akash Gajjar, Vicente Bergas, Levin Du, Ezequiel Garcia, linux-arm-kernel, Shohei Maruyama, Matthias Brugger, Tomeu Vizoso, Dmitry Torokhov, Douglas Anderson, Jakob Unterwurzacher, Oskari Lemmela, Enric Hello Tony, On 2019/03/04 0:13, Tony McKahan wrote: > On Sun, Mar 3, 2019 at 9:04 AM Katsuhiro Suzuki <katsuhiro@katsuster.net> wrote: >> >> Hello Heiko, >> >> Thank you for comments. >> >> On 2019/03/03 22:19, Heiko Stuebner wrote: >>> Hi, >>> >>> Am Sonntag, 3. März 2019, 13:27:05 CET schrieb Katsuhiro Suzuki: >>>> This patch increases drive strength of UART2 from 3mA to 12mA for >>>> getting more faster rising edge. >>>> >>>> RockPro64 is using a very high speed rate (1.5Mbps) for UART2. In >>>> this setting, a bit width of UART is about 667ns. >>>> >>>> In my environment (RockPro64 UART2 with FTDI FT232RL UART-USB >>>> converter), falling time of RockPro64 UART2 is 40ns, but riging time >>>> is over 650ns. So UART receiver will get wrong data, because receiver >>>> read intermediate data of rising edge. >>>> >>>> Rising time becomes 300ns from 650ns if apply this patch. This is not >>>> perfect solution but better than now. >>>> >>>> Signed-off-by: Katsuhiro Suzuki <katsuhiro@katsuster.net> >>>> --- >>>> arch/arm64/boot/dts/rockchip/rk3399.dtsi | 9 +++++++-- >>>> 1 file changed, 7 insertions(+), 2 deletions(-) >>> >>> your changing a core rk3399 property here, so I'd really like to get >>> input from other board stakeholders on this before applying a core >>> change. >>> >>> Could you either include the submitters of other rk3399-boards in the >>> recipient list so that they're aware or limit the change to rockpro64 for >>> the time being (aka overriding the property in the board-dts) please? >>> >> >> OK, I'm adding other boards members. >> by ./scripts/get_maintainer.pl arch/arm64/boot/dts/rockchip/rk3399-*.dts >> >> >> RockPro64 directly connect UART2 pins of RK3399 to external connector. >> I think maybe other RK3399 boards are facing same problem, but I cannot >> check it because I have RockPro64 only... >> >> I'm happy if someone tell me other boards situation. > > I'm pulling out other rockchip boards momentarily to see what kind of > population we have. > > Note these are not all running 5.x kernels, however none of them have > the UART2 drive levels modified to my knowledge, and regardless, none > show over 100 ns. > > board: rise/fall > > rk3399-roc-pc: 90ns/90ns > rk3399-rockpro64 V2.0: 90ns/45ns > rk3399-rockpro64 V2.1: 40ns/41ns > > Please make sure there's not a large amount of flux or something > around the terminals on your board, that seems excessively high. > Thank you for valuable information. For more deeply discussion, I tried other conditions and watch the rise/fall times. 1) Not connect The rise/fall times are 40ns/5ns when nothing connect (impedance is very high) to external pin of RockPro64. What UART device are you using with RockPro64? If you use some device with RockPro64 and board shows rise/fall times = 90ns/45ns, my device is not suitable for RockPro64 by some reason. So it's better to drop my patch. 2) Other SoC I have other SoC board rk3328-rock64, Rock64 shows rise/fall times = 90ns/80ns when same UART-USB device is connected to UART pin. I think it shows rk3399's (or RockPro64's?) drive strength is a little weak. So it's better to increase the drive strength of UART of rk3399. Best Regards, Katsuhiro Suzuki >> >> Best Regards, >> Katsuhiro Suzuki >> >> >>> Thanks >>> Heiko >>> >>> >>> >>>> diff --git a/arch/arm64/boot/dts/rockchip/rk3399.dtsi b/arch/arm64/boot/dts/rockchip/rk3399.dtsi >>>> index beaa92744a64..e3c8f91ead50 100644 >>>> --- a/arch/arm64/boot/dts/rockchip/rk3399.dtsi >>>> +++ b/arch/arm64/boot/dts/rockchip/rk3399.dtsi >>>> @@ -2000,6 +2000,11 @@ >>>> drive-strength = <8>; >>>> }; >>>> >>>> + pcfg_pull_up_12ma: pcfg-pull-up-12ma { >>>> + bias-pull-up; >>>> + drive-strength = <12>; >>>> + }; >>>> + >>>> pcfg_pull_up_18ma: pcfg-pull-up-18ma { >>>> bias-pull-up; >>>> drive-strength = <18>; >>>> @@ -2521,8 +2526,8 @@ >>>> uart2c { >>>> uart2c_xfer: uart2c-xfer { >>>> rockchip,pins = >>>> - <4 RK_PC3 RK_FUNC_1 &pcfg_pull_up>, >>>> - <4 RK_PC4 RK_FUNC_1 &pcfg_pull_none>; >>>> + <4 RK_PC3 RK_FUNC_1 &pcfg_pull_up_12ma>, >>>> + <4 RK_PC4 RK_FUNC_1 &pcfg_pull_none_12ma>; >>>> }; >>>> }; >>>> >>>> >>> >>> >>> >>> >>> >>> >> >> >> _______________________________________________ >> Linux-rockchip mailing list >> Linux-rockchip@lists.infradead.org >> http://lists.infradead.org/mailman/listinfo/linux-rockchip > > _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [PATCH] arm64: dts: rockchip: decrease rising edge time of UART2 @ 2019-03-03 17:31 ` Katsuhiro Suzuki 0 siblings, 0 replies; 43+ messages in thread From: Katsuhiro Suzuki @ 2019-03-03 17:31 UTC (permalink / raw) To: Tony McKahan Cc: Heiko Stuebner, Akash Gajjar, Brian Norris, Christoph Muellner, Dmitry Torokhov, Douglas Anderson, Enric Balletbo i Serra, Ezequiel Garcia, Jakob Unterwurzacher, Klaus Goger, Levin Du, Linus Walleij, Manivannan Sadhasivam, Matthias Brugger, Oskari Lemmela, Robin Murphy, Shawn Lin, Shohei Maruyama, Tomeu Vizoso, Vicente Bergas, Viresh Kumar, linux-rockchip, linux-kernel, linux-arm-kernel Hello Tony, On 2019/03/04 0:13, Tony McKahan wrote: > On Sun, Mar 3, 2019 at 9:04 AM Katsuhiro Suzuki <katsuhiro@katsuster.net> wrote: >> >> Hello Heiko, >> >> Thank you for comments. >> >> On 2019/03/03 22:19, Heiko Stuebner wrote: >>> Hi, >>> >>> Am Sonntag, 3. März 2019, 13:27:05 CET schrieb Katsuhiro Suzuki: >>>> This patch increases drive strength of UART2 from 3mA to 12mA for >>>> getting more faster rising edge. >>>> >>>> RockPro64 is using a very high speed rate (1.5Mbps) for UART2. In >>>> this setting, a bit width of UART is about 667ns. >>>> >>>> In my environment (RockPro64 UART2 with FTDI FT232RL UART-USB >>>> converter), falling time of RockPro64 UART2 is 40ns, but riging time >>>> is over 650ns. So UART receiver will get wrong data, because receiver >>>> read intermediate data of rising edge. >>>> >>>> Rising time becomes 300ns from 650ns if apply this patch. This is not >>>> perfect solution but better than now. >>>> >>>> Signed-off-by: Katsuhiro Suzuki <katsuhiro@katsuster.net> >>>> --- >>>> arch/arm64/boot/dts/rockchip/rk3399.dtsi | 9 +++++++-- >>>> 1 file changed, 7 insertions(+), 2 deletions(-) >>> >>> your changing a core rk3399 property here, so I'd really like to get >>> input from other board stakeholders on this before applying a core >>> change. >>> >>> Could you either include the submitters of other rk3399-boards in the >>> recipient list so that they're aware or limit the change to rockpro64 for >>> the time being (aka overriding the property in the board-dts) please? >>> >> >> OK, I'm adding other boards members. >> by ./scripts/get_maintainer.pl arch/arm64/boot/dts/rockchip/rk3399-*.dts >> >> >> RockPro64 directly connect UART2 pins of RK3399 to external connector. >> I think maybe other RK3399 boards are facing same problem, but I cannot >> check it because I have RockPro64 only... >> >> I'm happy if someone tell me other boards situation. > > I'm pulling out other rockchip boards momentarily to see what kind of > population we have. > > Note these are not all running 5.x kernels, however none of them have > the UART2 drive levels modified to my knowledge, and regardless, none > show over 100 ns. > > board: rise/fall > > rk3399-roc-pc: 90ns/90ns > rk3399-rockpro64 V2.0: 90ns/45ns > rk3399-rockpro64 V2.1: 40ns/41ns > > Please make sure there's not a large amount of flux or something > around the terminals on your board, that seems excessively high. > Thank you for valuable information. For more deeply discussion, I tried other conditions and watch the rise/fall times. 1) Not connect The rise/fall times are 40ns/5ns when nothing connect (impedance is very high) to external pin of RockPro64. What UART device are you using with RockPro64? If you use some device with RockPro64 and board shows rise/fall times = 90ns/45ns, my device is not suitable for RockPro64 by some reason. So it's better to drop my patch. 2) Other SoC I have other SoC board rk3328-rock64, Rock64 shows rise/fall times = 90ns/80ns when same UART-USB device is connected to UART pin. I think it shows rk3399's (or RockPro64's?) drive strength is a little weak. So it's better to increase the drive strength of UART of rk3399. Best Regards, Katsuhiro Suzuki >> >> Best Regards, >> Katsuhiro Suzuki >> >> >>> Thanks >>> Heiko >>> >>> >>> >>>> diff --git a/arch/arm64/boot/dts/rockchip/rk3399.dtsi b/arch/arm64/boot/dts/rockchip/rk3399.dtsi >>>> index beaa92744a64..e3c8f91ead50 100644 >>>> --- a/arch/arm64/boot/dts/rockchip/rk3399.dtsi >>>> +++ b/arch/arm64/boot/dts/rockchip/rk3399.dtsi >>>> @@ -2000,6 +2000,11 @@ >>>> drive-strength = <8>; >>>> }; >>>> >>>> + pcfg_pull_up_12ma: pcfg-pull-up-12ma { >>>> + bias-pull-up; >>>> + drive-strength = <12>; >>>> + }; >>>> + >>>> pcfg_pull_up_18ma: pcfg-pull-up-18ma { >>>> bias-pull-up; >>>> drive-strength = <18>; >>>> @@ -2521,8 +2526,8 @@ >>>> uart2c { >>>> uart2c_xfer: uart2c-xfer { >>>> rockchip,pins = >>>> - <4 RK_PC3 RK_FUNC_1 &pcfg_pull_up>, >>>> - <4 RK_PC4 RK_FUNC_1 &pcfg_pull_none>; >>>> + <4 RK_PC3 RK_FUNC_1 &pcfg_pull_up_12ma>, >>>> + <4 RK_PC4 RK_FUNC_1 &pcfg_pull_none_12ma>; >>>> }; >>>> }; >>>> >>>> >>> >>> >>> >>> >>> >>> >> >> >> _______________________________________________ >> Linux-rockchip mailing list >> Linux-rockchip@lists.infradead.org >> http://lists.infradead.org/mailman/listinfo/linux-rockchip > > ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [PATCH] arm64: dts: rockchip: decrease rising edge time of UART2 @ 2019-03-03 17:31 ` Katsuhiro Suzuki 0 siblings, 0 replies; 43+ messages in thread From: Katsuhiro Suzuki @ 2019-03-03 17:31 UTC (permalink / raw) To: Tony McKahan Cc: Heiko Stuebner, Viresh Kumar, Linus Walleij, linux-kernel, Klaus Goger, Manivannan Sadhasivam, Brian Norris, linux-rockchip, Shawn Lin, Akash Gajjar, Vicente Bergas, Levin Du, Ezequiel Garcia, linux-arm-kernel, Shohei Maruyama, Matthias Brugger, Tomeu Vizoso, Dmitry Torokhov, Douglas Anderson, Jakob Unterwurzacher, Oskari Lemmela, Enric Balletbo i Serra, Robin Murphy, Christoph Muellner Hello Tony, On 2019/03/04 0:13, Tony McKahan wrote: > On Sun, Mar 3, 2019 at 9:04 AM Katsuhiro Suzuki <katsuhiro@katsuster.net> wrote: >> >> Hello Heiko, >> >> Thank you for comments. >> >> On 2019/03/03 22:19, Heiko Stuebner wrote: >>> Hi, >>> >>> Am Sonntag, 3. März 2019, 13:27:05 CET schrieb Katsuhiro Suzuki: >>>> This patch increases drive strength of UART2 from 3mA to 12mA for >>>> getting more faster rising edge. >>>> >>>> RockPro64 is using a very high speed rate (1.5Mbps) for UART2. In >>>> this setting, a bit width of UART is about 667ns. >>>> >>>> In my environment (RockPro64 UART2 with FTDI FT232RL UART-USB >>>> converter), falling time of RockPro64 UART2 is 40ns, but riging time >>>> is over 650ns. So UART receiver will get wrong data, because receiver >>>> read intermediate data of rising edge. >>>> >>>> Rising time becomes 300ns from 650ns if apply this patch. This is not >>>> perfect solution but better than now. >>>> >>>> Signed-off-by: Katsuhiro Suzuki <katsuhiro@katsuster.net> >>>> --- >>>> arch/arm64/boot/dts/rockchip/rk3399.dtsi | 9 +++++++-- >>>> 1 file changed, 7 insertions(+), 2 deletions(-) >>> >>> your changing a core rk3399 property here, so I'd really like to get >>> input from other board stakeholders on this before applying a core >>> change. >>> >>> Could you either include the submitters of other rk3399-boards in the >>> recipient list so that they're aware or limit the change to rockpro64 for >>> the time being (aka overriding the property in the board-dts) please? >>> >> >> OK, I'm adding other boards members. >> by ./scripts/get_maintainer.pl arch/arm64/boot/dts/rockchip/rk3399-*.dts >> >> >> RockPro64 directly connect UART2 pins of RK3399 to external connector. >> I think maybe other RK3399 boards are facing same problem, but I cannot >> check it because I have RockPro64 only... >> >> I'm happy if someone tell me other boards situation. > > I'm pulling out other rockchip boards momentarily to see what kind of > population we have. > > Note these are not all running 5.x kernels, however none of them have > the UART2 drive levels modified to my knowledge, and regardless, none > show over 100 ns. > > board: rise/fall > > rk3399-roc-pc: 90ns/90ns > rk3399-rockpro64 V2.0: 90ns/45ns > rk3399-rockpro64 V2.1: 40ns/41ns > > Please make sure there's not a large amount of flux or something > around the terminals on your board, that seems excessively high. > Thank you for valuable information. For more deeply discussion, I tried other conditions and watch the rise/fall times. 1) Not connect The rise/fall times are 40ns/5ns when nothing connect (impedance is very high) to external pin of RockPro64. What UART device are you using with RockPro64? If you use some device with RockPro64 and board shows rise/fall times = 90ns/45ns, my device is not suitable for RockPro64 by some reason. So it's better to drop my patch. 2) Other SoC I have other SoC board rk3328-rock64, Rock64 shows rise/fall times = 90ns/80ns when same UART-USB device is connected to UART pin. I think it shows rk3399's (or RockPro64's?) drive strength is a little weak. So it's better to increase the drive strength of UART of rk3399. Best Regards, Katsuhiro Suzuki >> >> Best Regards, >> Katsuhiro Suzuki >> >> >>> Thanks >>> Heiko >>> >>> >>> >>>> diff --git a/arch/arm64/boot/dts/rockchip/rk3399.dtsi b/arch/arm64/boot/dts/rockchip/rk3399.dtsi >>>> index beaa92744a64..e3c8f91ead50 100644 >>>> --- a/arch/arm64/boot/dts/rockchip/rk3399.dtsi >>>> +++ b/arch/arm64/boot/dts/rockchip/rk3399.dtsi >>>> @@ -2000,6 +2000,11 @@ >>>> drive-strength = <8>; >>>> }; >>>> >>>> + pcfg_pull_up_12ma: pcfg-pull-up-12ma { >>>> + bias-pull-up; >>>> + drive-strength = <12>; >>>> + }; >>>> + >>>> pcfg_pull_up_18ma: pcfg-pull-up-18ma { >>>> bias-pull-up; >>>> drive-strength = <18>; >>>> @@ -2521,8 +2526,8 @@ >>>> uart2c { >>>> uart2c_xfer: uart2c-xfer { >>>> rockchip,pins = >>>> - <4 RK_PC3 RK_FUNC_1 &pcfg_pull_up>, >>>> - <4 RK_PC4 RK_FUNC_1 &pcfg_pull_none>; >>>> + <4 RK_PC3 RK_FUNC_1 &pcfg_pull_up_12ma>, >>>> + <4 RK_PC4 RK_FUNC_1 &pcfg_pull_none_12ma>; >>>> }; >>>> }; >>>> >>>> >>> >>> >>> >>> >>> >>> >> >> >> _______________________________________________ >> Linux-rockchip mailing list >> Linux-rockchip@lists.infradead.org >> http://lists.infradead.org/mailman/listinfo/linux-rockchip > > _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [PATCH] arm64: dts: rockchip: decrease rising edge time of UART2 2019-03-03 17:31 ` Katsuhiro Suzuki (?) @ 2019-03-03 18:45 ` Tony McKahan -1 siblings, 0 replies; 43+ messages in thread From: Tony McKahan @ 2019-03-03 18:45 UTC (permalink / raw) To: Katsuhiro Suzuki Cc: Heiko Stuebner, Akash Gajjar, Brian Norris, Christoph Muellner, Dmitry Torokhov, Douglas Anderson, Enric Balletbo i Serra, Ezequiel Garcia, Jakob Unterwurzacher, Klaus Goger, Levin Du, Linus Walleij, Manivannan Sadhasivam, Matthias Brugger, Oskari Lemmela, Robin Murphy, Shawn Lin Hello Katsushiro, On Sun, Mar 3, 2019 at 12:31 PM Katsuhiro Suzuki <katsuhiro@katsuster.net> wrote: > > Hello Tony, > > On 2019/03/04 0:13, Tony McKahan wrote: > > On Sun, Mar 3, 2019 at 9:04 AM Katsuhiro Suzuki <katsuhiro@katsuster.net> wrote: > >> > >> Hello Heiko, > >> > >> Thank you for comments. > >> > >> On 2019/03/03 22:19, Heiko Stuebner wrote: > >>> Hi, > >>> > >>> Am Sonntag, 3. März 2019, 13:27:05 CET schrieb Katsuhiro Suzuki: > >>>> This patch increases drive strength of UART2 from 3mA to 12mA for > >>>> getting more faster rising edge. > >>>> > >>>> RockPro64 is using a very high speed rate (1.5Mbps) for UART2. In > >>>> this setting, a bit width of UART is about 667ns. > >>>> > >>>> In my environment (RockPro64 UART2 with FTDI FT232RL UART-USB > >>>> converter), falling time of RockPro64 UART2 is 40ns, but riging time > >>>> is over 650ns. So UART receiver will get wrong data, because receiver > >>>> read intermediate data of rising edge. > >>>> > >>>> Rising time becomes 300ns from 650ns if apply this patch. This is not > >>>> perfect solution but better than now. > >>>> > >>>> Signed-off-by: Katsuhiro Suzuki <katsuhiro@katsuster.net> > >>>> --- > >>>> arch/arm64/boot/dts/rockchip/rk3399.dtsi | 9 +++++++-- > >>>> 1 file changed, 7 insertions(+), 2 deletions(-) > >>> > >>> your changing a core rk3399 property here, so I'd really like to get > >>> input from other board stakeholders on this before applying a core > >>> change. > >>> > >>> Could you either include the submitters of other rk3399-boards in the > >>> recipient list so that they're aware or limit the change to rockpro64 for > >>> the time being (aka overriding the property in the board-dts) please? > >>> > >> > >> OK, I'm adding other boards members. > >> by ./scripts/get_maintainer.pl arch/arm64/boot/dts/rockchip/rk3399-*.dts > >> > >> > >> RockPro64 directly connect UART2 pins of RK3399 to external connector. > >> I think maybe other RK3399 boards are facing same problem, but I cannot > >> check it because I have RockPro64 only... > >> > >> I'm happy if someone tell me other boards situation. > > > > I'm pulling out other rockchip boards momentarily to see what kind of > > population we have. > > > > Note these are not all running 5.x kernels, however none of them have > > the UART2 drive levels modified to my knowledge, and regardless, none > > show over 100 ns. > > > > board: rise/fall > > > > rk3399-roc-pc: 90ns/90ns > > rk3399-rockpro64 V2.0: 90ns/45ns > > rk3399-rockpro64 V2.1: 40ns/41ns > > > > Please make sure there's not a large amount of flux or something > > around the terminals on your board, that seems excessively high. > > > > Thank you for valuable information. For more deeply discussion, > I tried other conditions and watch the rise/fall times. > > 1) Not connect > The rise/fall times are 40ns/5ns when nothing connect (impedance is > very high) to external pin of RockPro64. > > What UART device are you using with RockPro64? If you use some device > with RockPro64 and board shows rise/fall times = 90ns/45ns, my device > is not suitable for RockPro64 by some reason. So it's better to drop > my patch. The adapter is an FTDI FT232RL breakout board, attached with some generic Dupont connector jumpers. Interesting your RockPro is showing this symptom, perhaps there is a cold solder joint somewhere introducing resistance? > > 2) Other SoC > I have other SoC board rk3328-rock64, Rock64 shows rise/fall times = > 90ns/80ns when same UART-USB device is connected to UART pin. I measured similar on my Rock64 as well. > > I think it shows rk3399's (or RockPro64's?) drive strength is a little > weak. So it's better to increase the drive strength of UART of rk3399. I do not think this is a bad idea generally, it simply allows for more available current from the interface. I'll let others be the judge of that, however. > > Best Regards, > Katsuhiro Suzuki > > >> > >> Best Regards, > >> Katsuhiro Suzuki > >> > >> > >>> Thanks > >>> Heiko > >>> > >>> > >>> > >>>> diff --git a/arch/arm64/boot/dts/rockchip/rk3399.dtsi b/arch/arm64/boot/dts/rockchip/rk3399.dtsi > >>>> index beaa92744a64..e3c8f91ead50 100644 > >>>> --- a/arch/arm64/boot/dts/rockchip/rk3399.dtsi > >>>> +++ b/arch/arm64/boot/dts/rockchip/rk3399.dtsi > >>>> @@ -2000,6 +2000,11 @@ > >>>> drive-strength = <8>; > >>>> }; > >>>> > >>>> + pcfg_pull_up_12ma: pcfg-pull-up-12ma { > >>>> + bias-pull-up; > >>>> + drive-strength = <12>; > >>>> + }; > >>>> + > >>>> pcfg_pull_up_18ma: pcfg-pull-up-18ma { > >>>> bias-pull-up; > >>>> drive-strength = <18>; > >>>> @@ -2521,8 +2526,8 @@ > >>>> uart2c { > >>>> uart2c_xfer: uart2c-xfer { > >>>> rockchip,pins = > >>>> - <4 RK_PC3 RK_FUNC_1 &pcfg_pull_up>, > >>>> - <4 RK_PC4 RK_FUNC_1 &pcfg_pull_none>; > >>>> + <4 RK_PC3 RK_FUNC_1 &pcfg_pull_up_12ma>, > >>>> + <4 RK_PC4 RK_FUNC_1 &pcfg_pull_none_12ma>; > >>>> }; > >>>> }; > >>>> > >>>> > >>> > >>> > >>> > >>> > >>> > >>> > >> > >> > >> _______________________________________________ > >> Linux-rockchip mailing list > >> Linux-rockchip@lists.infradead.org > >> http://lists.infradead.org/mailman/listinfo/linux-rockchip > > > > > ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [PATCH] arm64: dts: rockchip: decrease rising edge time of UART2 @ 2019-03-03 18:45 ` Tony McKahan 0 siblings, 0 replies; 43+ messages in thread From: Tony McKahan @ 2019-03-03 18:45 UTC (permalink / raw) To: Katsuhiro Suzuki Cc: Heiko Stuebner, Akash Gajjar, Brian Norris, Christoph Muellner, Dmitry Torokhov, Douglas Anderson, Enric Balletbo i Serra, Ezequiel Garcia, Jakob Unterwurzacher, Klaus Goger, Levin Du, Linus Walleij, Manivannan Sadhasivam, Matthias Brugger, Oskari Lemmela, Robin Murphy, Shawn Lin, Shohei Maruyama, Tomeu Vizoso, Vicente Bergas, Viresh Kumar, linux-rockchip, linux-kernel, linux-arm-kernel Hello Katsushiro, On Sun, Mar 3, 2019 at 12:31 PM Katsuhiro Suzuki <katsuhiro@katsuster.net> wrote: > > Hello Tony, > > On 2019/03/04 0:13, Tony McKahan wrote: > > On Sun, Mar 3, 2019 at 9:04 AM Katsuhiro Suzuki <katsuhiro@katsuster.net> wrote: > >> > >> Hello Heiko, > >> > >> Thank you for comments. > >> > >> On 2019/03/03 22:19, Heiko Stuebner wrote: > >>> Hi, > >>> > >>> Am Sonntag, 3. März 2019, 13:27:05 CET schrieb Katsuhiro Suzuki: > >>>> This patch increases drive strength of UART2 from 3mA to 12mA for > >>>> getting more faster rising edge. > >>>> > >>>> RockPro64 is using a very high speed rate (1.5Mbps) for UART2. In > >>>> this setting, a bit width of UART is about 667ns. > >>>> > >>>> In my environment (RockPro64 UART2 with FTDI FT232RL UART-USB > >>>> converter), falling time of RockPro64 UART2 is 40ns, but riging time > >>>> is over 650ns. So UART receiver will get wrong data, because receiver > >>>> read intermediate data of rising edge. > >>>> > >>>> Rising time becomes 300ns from 650ns if apply this patch. This is not > >>>> perfect solution but better than now. > >>>> > >>>> Signed-off-by: Katsuhiro Suzuki <katsuhiro@katsuster.net> > >>>> --- > >>>> arch/arm64/boot/dts/rockchip/rk3399.dtsi | 9 +++++++-- > >>>> 1 file changed, 7 insertions(+), 2 deletions(-) > >>> > >>> your changing a core rk3399 property here, so I'd really like to get > >>> input from other board stakeholders on this before applying a core > >>> change. > >>> > >>> Could you either include the submitters of other rk3399-boards in the > >>> recipient list so that they're aware or limit the change to rockpro64 for > >>> the time being (aka overriding the property in the board-dts) please? > >>> > >> > >> OK, I'm adding other boards members. > >> by ./scripts/get_maintainer.pl arch/arm64/boot/dts/rockchip/rk3399-*.dts > >> > >> > >> RockPro64 directly connect UART2 pins of RK3399 to external connector. > >> I think maybe other RK3399 boards are facing same problem, but I cannot > >> check it because I have RockPro64 only... > >> > >> I'm happy if someone tell me other boards situation. > > > > I'm pulling out other rockchip boards momentarily to see what kind of > > population we have. > > > > Note these are not all running 5.x kernels, however none of them have > > the UART2 drive levels modified to my knowledge, and regardless, none > > show over 100 ns. > > > > board: rise/fall > > > > rk3399-roc-pc: 90ns/90ns > > rk3399-rockpro64 V2.0: 90ns/45ns > > rk3399-rockpro64 V2.1: 40ns/41ns > > > > Please make sure there's not a large amount of flux or something > > around the terminals on your board, that seems excessively high. > > > > Thank you for valuable information. For more deeply discussion, > I tried other conditions and watch the rise/fall times. > > 1) Not connect > The rise/fall times are 40ns/5ns when nothing connect (impedance is > very high) to external pin of RockPro64. > > What UART device are you using with RockPro64? If you use some device > with RockPro64 and board shows rise/fall times = 90ns/45ns, my device > is not suitable for RockPro64 by some reason. So it's better to drop > my patch. The adapter is an FTDI FT232RL breakout board, attached with some generic Dupont connector jumpers. Interesting your RockPro is showing this symptom, perhaps there is a cold solder joint somewhere introducing resistance? > > 2) Other SoC > I have other SoC board rk3328-rock64, Rock64 shows rise/fall times = > 90ns/80ns when same UART-USB device is connected to UART pin. I measured similar on my Rock64 as well. > > I think it shows rk3399's (or RockPro64's?) drive strength is a little > weak. So it's better to increase the drive strength of UART of rk3399. I do not think this is a bad idea generally, it simply allows for more available current from the interface. I'll let others be the judge of that, however. > > Best Regards, > Katsuhiro Suzuki > > >> > >> Best Regards, > >> Katsuhiro Suzuki > >> > >> > >>> Thanks > >>> Heiko > >>> > >>> > >>> > >>>> diff --git a/arch/arm64/boot/dts/rockchip/rk3399.dtsi b/arch/arm64/boot/dts/rockchip/rk3399.dtsi > >>>> index beaa92744a64..e3c8f91ead50 100644 > >>>> --- a/arch/arm64/boot/dts/rockchip/rk3399.dtsi > >>>> +++ b/arch/arm64/boot/dts/rockchip/rk3399.dtsi > >>>> @@ -2000,6 +2000,11 @@ > >>>> drive-strength = <8>; > >>>> }; > >>>> > >>>> + pcfg_pull_up_12ma: pcfg-pull-up-12ma { > >>>> + bias-pull-up; > >>>> + drive-strength = <12>; > >>>> + }; > >>>> + > >>>> pcfg_pull_up_18ma: pcfg-pull-up-18ma { > >>>> bias-pull-up; > >>>> drive-strength = <18>; > >>>> @@ -2521,8 +2526,8 @@ > >>>> uart2c { > >>>> uart2c_xfer: uart2c-xfer { > >>>> rockchip,pins = > >>>> - <4 RK_PC3 RK_FUNC_1 &pcfg_pull_up>, > >>>> - <4 RK_PC4 RK_FUNC_1 &pcfg_pull_none>; > >>>> + <4 RK_PC3 RK_FUNC_1 &pcfg_pull_up_12ma>, > >>>> + <4 RK_PC4 RK_FUNC_1 &pcfg_pull_none_12ma>; > >>>> }; > >>>> }; > >>>> > >>>> > >>> > >>> > >>> > >>> > >>> > >>> > >> > >> > >> _______________________________________________ > >> Linux-rockchip mailing list > >> Linux-rockchip@lists.infradead.org > >> http://lists.infradead.org/mailman/listinfo/linux-rockchip > > > > > ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [PATCH] arm64: dts: rockchip: decrease rising edge time of UART2 @ 2019-03-03 18:45 ` Tony McKahan 0 siblings, 0 replies; 43+ messages in thread From: Tony McKahan @ 2019-03-03 18:45 UTC (permalink / raw) To: Katsuhiro Suzuki Cc: Heiko Stuebner, Viresh Kumar, Linus Walleij, linux-kernel, Klaus Goger, Manivannan Sadhasivam, Brian Norris, linux-rockchip, Shawn Lin, Akash Gajjar, Vicente Bergas, Levin Du, Ezequiel Garcia, linux-arm-kernel, Shohei Maruyama, Matthias Brugger, Tomeu Vizoso, Dmitry Torokhov, Douglas Anderson, Jakob Unterwurzacher, Oskari Lemmela, Enric Balletbo i Serra, Robin Murphy, Christoph Muellner Hello Katsushiro, On Sun, Mar 3, 2019 at 12:31 PM Katsuhiro Suzuki <katsuhiro@katsuster.net> wrote: > > Hello Tony, > > On 2019/03/04 0:13, Tony McKahan wrote: > > On Sun, Mar 3, 2019 at 9:04 AM Katsuhiro Suzuki <katsuhiro@katsuster.net> wrote: > >> > >> Hello Heiko, > >> > >> Thank you for comments. > >> > >> On 2019/03/03 22:19, Heiko Stuebner wrote: > >>> Hi, > >>> > >>> Am Sonntag, 3. März 2019, 13:27:05 CET schrieb Katsuhiro Suzuki: > >>>> This patch increases drive strength of UART2 from 3mA to 12mA for > >>>> getting more faster rising edge. > >>>> > >>>> RockPro64 is using a very high speed rate (1.5Mbps) for UART2. In > >>>> this setting, a bit width of UART is about 667ns. > >>>> > >>>> In my environment (RockPro64 UART2 with FTDI FT232RL UART-USB > >>>> converter), falling time of RockPro64 UART2 is 40ns, but riging time > >>>> is over 650ns. So UART receiver will get wrong data, because receiver > >>>> read intermediate data of rising edge. > >>>> > >>>> Rising time becomes 300ns from 650ns if apply this patch. This is not > >>>> perfect solution but better than now. > >>>> > >>>> Signed-off-by: Katsuhiro Suzuki <katsuhiro@katsuster.net> > >>>> --- > >>>> arch/arm64/boot/dts/rockchip/rk3399.dtsi | 9 +++++++-- > >>>> 1 file changed, 7 insertions(+), 2 deletions(-) > >>> > >>> your changing a core rk3399 property here, so I'd really like to get > >>> input from other board stakeholders on this before applying a core > >>> change. > >>> > >>> Could you either include the submitters of other rk3399-boards in the > >>> recipient list so that they're aware or limit the change to rockpro64 for > >>> the time being (aka overriding the property in the board-dts) please? > >>> > >> > >> OK, I'm adding other boards members. > >> by ./scripts/get_maintainer.pl arch/arm64/boot/dts/rockchip/rk3399-*.dts > >> > >> > >> RockPro64 directly connect UART2 pins of RK3399 to external connector. > >> I think maybe other RK3399 boards are facing same problem, but I cannot > >> check it because I have RockPro64 only... > >> > >> I'm happy if someone tell me other boards situation. > > > > I'm pulling out other rockchip boards momentarily to see what kind of > > population we have. > > > > Note these are not all running 5.x kernels, however none of them have > > the UART2 drive levels modified to my knowledge, and regardless, none > > show over 100 ns. > > > > board: rise/fall > > > > rk3399-roc-pc: 90ns/90ns > > rk3399-rockpro64 V2.0: 90ns/45ns > > rk3399-rockpro64 V2.1: 40ns/41ns > > > > Please make sure there's not a large amount of flux or something > > around the terminals on your board, that seems excessively high. > > > > Thank you for valuable information. For more deeply discussion, > I tried other conditions and watch the rise/fall times. > > 1) Not connect > The rise/fall times are 40ns/5ns when nothing connect (impedance is > very high) to external pin of RockPro64. > > What UART device are you using with RockPro64? If you use some device > with RockPro64 and board shows rise/fall times = 90ns/45ns, my device > is not suitable for RockPro64 by some reason. So it's better to drop > my patch. The adapter is an FTDI FT232RL breakout board, attached with some generic Dupont connector jumpers. Interesting your RockPro is showing this symptom, perhaps there is a cold solder joint somewhere introducing resistance? > > 2) Other SoC > I have other SoC board rk3328-rock64, Rock64 shows rise/fall times = > 90ns/80ns when same UART-USB device is connected to UART pin. I measured similar on my Rock64 as well. > > I think it shows rk3399's (or RockPro64's?) drive strength is a little > weak. So it's better to increase the drive strength of UART of rk3399. I do not think this is a bad idea generally, it simply allows for more available current from the interface. I'll let others be the judge of that, however. > > Best Regards, > Katsuhiro Suzuki > > >> > >> Best Regards, > >> Katsuhiro Suzuki > >> > >> > >>> Thanks > >>> Heiko > >>> > >>> > >>> > >>>> diff --git a/arch/arm64/boot/dts/rockchip/rk3399.dtsi b/arch/arm64/boot/dts/rockchip/rk3399.dtsi > >>>> index beaa92744a64..e3c8f91ead50 100644 > >>>> --- a/arch/arm64/boot/dts/rockchip/rk3399.dtsi > >>>> +++ b/arch/arm64/boot/dts/rockchip/rk3399.dtsi > >>>> @@ -2000,6 +2000,11 @@ > >>>> drive-strength = <8>; > >>>> }; > >>>> > >>>> + pcfg_pull_up_12ma: pcfg-pull-up-12ma { > >>>> + bias-pull-up; > >>>> + drive-strength = <12>; > >>>> + }; > >>>> + > >>>> pcfg_pull_up_18ma: pcfg-pull-up-18ma { > >>>> bias-pull-up; > >>>> drive-strength = <18>; > >>>> @@ -2521,8 +2526,8 @@ > >>>> uart2c { > >>>> uart2c_xfer: uart2c-xfer { > >>>> rockchip,pins = > >>>> - <4 RK_PC3 RK_FUNC_1 &pcfg_pull_up>, > >>>> - <4 RK_PC4 RK_FUNC_1 &pcfg_pull_none>; > >>>> + <4 RK_PC3 RK_FUNC_1 &pcfg_pull_up_12ma>, > >>>> + <4 RK_PC4 RK_FUNC_1 &pcfg_pull_none_12ma>; > >>>> }; > >>>> }; > >>>> > >>>> > >>> > >>> > >>> > >>> > >>> > >>> > >> > >> > >> _______________________________________________ > >> Linux-rockchip mailing list > >> Linux-rockchip@lists.infradead.org > >> http://lists.infradead.org/mailman/listinfo/linux-rockchip > > > > > _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 43+ messages in thread
[parent not found: <CAERgoknMO6xMzuhCn2kSHZm8Pt+6YH3jDvJckJq28u9OW08u2Q-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>]
* Re: [PATCH] arm64: dts: rockchip: decrease rising edge time of UART2 2019-03-03 18:45 ` Tony McKahan (?) @ 2019-03-03 19:12 ` Tony McKahan -1 siblings, 0 replies; 43+ messages in thread From: Tony McKahan @ 2019-03-03 19:12 UTC (permalink / raw) To: Katsuhiro Suzuki Cc: Heiko Stuebner, Viresh Kumar, Linus Walleij, linux-kernel-u79uwXL29TY76Z2rM5mHXA, Klaus Goger, Manivannan Sadhasivam, Brian Norris, linux-rockchip-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Shawn Lin, Akash Gajjar, Vicente Bergas, Levin Du, Ezequiel Garcia, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Shohei Maruyama, Matthias Brugger, Tomeu Vizoso, Dmitry Torokhov, Douglas Anderson, Jakob Unterwurzacher, Oskari Lemmela, Enric On Sun, Mar 3, 2019 at 1:45 PM Tony McKahan <tonymckahan@gmail.com> wrote: > > Hello Katsushiro, And apologies for the extra "s", typing too quickly I'm afraid. > > On Sun, Mar 3, 2019 at 12:31 PM Katsuhiro Suzuki > <katsuhiro@katsuster.net> wrote: > > > > Hello Tony, > > > > On 2019/03/04 0:13, Tony McKahan wrote: > > > On Sun, Mar 3, 2019 at 9:04 AM Katsuhiro Suzuki <katsuhiro@katsuster.net> wrote: > > >> > > >> Hello Heiko, > > >> > > >> Thank you for comments. > > >> > > >> On 2019/03/03 22:19, Heiko Stuebner wrote: > > >>> Hi, > > >>> > > >>> Am Sonntag, 3. März 2019, 13:27:05 CET schrieb Katsuhiro Suzuki: > > >>>> This patch increases drive strength of UART2 from 3mA to 12mA for > > >>>> getting more faster rising edge. > > >>>> > > >>>> RockPro64 is using a very high speed rate (1.5Mbps) for UART2. In > > >>>> this setting, a bit width of UART is about 667ns. > > >>>> > > >>>> In my environment (RockPro64 UART2 with FTDI FT232RL UART-USB > > >>>> converter), falling time of RockPro64 UART2 is 40ns, but riging time > > >>>> is over 650ns. So UART receiver will get wrong data, because receiver > > >>>> read intermediate data of rising edge. > > >>>> > > >>>> Rising time becomes 300ns from 650ns if apply this patch. This is not > > >>>> perfect solution but better than now. > > >>>> > > >>>> Signed-off-by: Katsuhiro Suzuki <katsuhiro@katsuster.net> > > >>>> --- > > >>>> arch/arm64/boot/dts/rockchip/rk3399.dtsi | 9 +++++++-- > > >>>> 1 file changed, 7 insertions(+), 2 deletions(-) > > >>> > > >>> your changing a core rk3399 property here, so I'd really like to get > > >>> input from other board stakeholders on this before applying a core > > >>> change. > > >>> > > >>> Could you either include the submitters of other rk3399-boards in the > > >>> recipient list so that they're aware or limit the change to rockpro64 for > > >>> the time being (aka overriding the property in the board-dts) please? > > >>> > > >> > > >> OK, I'm adding other boards members. > > >> by ./scripts/get_maintainer.pl arch/arm64/boot/dts/rockchip/rk3399-*.dts > > >> > > >> > > >> RockPro64 directly connect UART2 pins of RK3399 to external connector. > > >> I think maybe other RK3399 boards are facing same problem, but I cannot > > >> check it because I have RockPro64 only... > > >> > > >> I'm happy if someone tell me other boards situation. > > > > > > I'm pulling out other rockchip boards momentarily to see what kind of > > > population we have. > > > > > > Note these are not all running 5.x kernels, however none of them have > > > the UART2 drive levels modified to my knowledge, and regardless, none > > > show over 100 ns. > > > > > > board: rise/fall > > > > > > rk3399-roc-pc: 90ns/90ns > > > rk3399-rockpro64 V2.0: 90ns/45ns > > > rk3399-rockpro64 V2.1: 40ns/41ns > > > > > > Please make sure there's not a large amount of flux or something > > > around the terminals on your board, that seems excessively high. > > > > > > > Thank you for valuable information. For more deeply discussion, > > I tried other conditions and watch the rise/fall times. > > > > 1) Not connect > > The rise/fall times are 40ns/5ns when nothing connect (impedance is > > very high) to external pin of RockPro64. > > > > What UART device are you using with RockPro64? If you use some device > > with RockPro64 and board shows rise/fall times = 90ns/45ns, my device > > is not suitable for RockPro64 by some reason. So it's better to drop > > my patch. > > The adapter is an FTDI FT232RL breakout board, attached with some > generic Dupont connector jumpers. > Interesting your RockPro is showing this symptom, perhaps there is a > cold solder joint somewhere introducing resistance? > > > > > 2) Other SoC > > I have other SoC board rk3328-rock64, Rock64 shows rise/fall times = > > 90ns/80ns when same UART-USB device is connected to UART pin. > > I measured similar on my Rock64 as well. > > > > > I think it shows rk3399's (or RockPro64's?) drive strength is a little > > weak. So it's better to increase the drive strength of UART of rk3399. > > I do not think this is a bad idea generally, it simply allows for more > available current from the interface. I'll let others be the judge of > that, however. > > > > > Best Regards, > > Katsuhiro Suzuki > > > > >> > > >> Best Regards, > > >> Katsuhiro Suzuki > > >> > > >> > > >>> Thanks > > >>> Heiko > > >>> > > >>> > > >>> > > >>>> diff --git a/arch/arm64/boot/dts/rockchip/rk3399.dtsi b/arch/arm64/boot/dts/rockchip/rk3399.dtsi > > >>>> index beaa92744a64..e3c8f91ead50 100644 > > >>>> --- a/arch/arm64/boot/dts/rockchip/rk3399.dtsi > > >>>> +++ b/arch/arm64/boot/dts/rockchip/rk3399.dtsi > > >>>> @@ -2000,6 +2000,11 @@ > > >>>> drive-strength = <8>; > > >>>> }; > > >>>> > > >>>> + pcfg_pull_up_12ma: pcfg-pull-up-12ma { > > >>>> + bias-pull-up; > > >>>> + drive-strength = <12>; > > >>>> + }; > > >>>> + > > >>>> pcfg_pull_up_18ma: pcfg-pull-up-18ma { > > >>>> bias-pull-up; > > >>>> drive-strength = <18>; > > >>>> @@ -2521,8 +2526,8 @@ > > >>>> uart2c { > > >>>> uart2c_xfer: uart2c-xfer { > > >>>> rockchip,pins = > > >>>> - <4 RK_PC3 RK_FUNC_1 &pcfg_pull_up>, > > >>>> - <4 RK_PC4 RK_FUNC_1 &pcfg_pull_none>; > > >>>> + <4 RK_PC3 RK_FUNC_1 &pcfg_pull_up_12ma>, > > >>>> + <4 RK_PC4 RK_FUNC_1 &pcfg_pull_none_12ma>; > > >>>> }; > > >>>> }; > > >>>> > > >>>> > > >>> > > >>> > > >>> > > >>> > > >>> > > >>> > > >> > > >> > > >> _______________________________________________ > > >> Linux-rockchip mailing list > > >> Linux-rockchip@lists.infradead.org > > >> http://lists.infradead.org/mailman/listinfo/linux-rockchip > > > > > > > > _______________________________________________ Linux-rockchip mailing list Linux-rockchip@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-rockchip ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [PATCH] arm64: dts: rockchip: decrease rising edge time of UART2 @ 2019-03-03 19:12 ` Tony McKahan 0 siblings, 0 replies; 43+ messages in thread From: Tony McKahan @ 2019-03-03 19:12 UTC (permalink / raw) To: Katsuhiro Suzuki Cc: Heiko Stuebner, Akash Gajjar, Brian Norris, Christoph Muellner, Dmitry Torokhov, Douglas Anderson, Enric Balletbo i Serra, Ezequiel Garcia, Jakob Unterwurzacher, Klaus Goger, Levin Du, Linus Walleij, Manivannan Sadhasivam, Matthias Brugger, Oskari Lemmela, Robin Murphy, Shawn Lin, Shohei Maruyama, Tomeu Vizoso, Vicente Bergas, Viresh Kumar, linux-rockchip, linux-kernel, linux-arm-kernel On Sun, Mar 3, 2019 at 1:45 PM Tony McKahan <tonymckahan@gmail.com> wrote: > > Hello Katsushiro, And apologies for the extra "s", typing too quickly I'm afraid. > > On Sun, Mar 3, 2019 at 12:31 PM Katsuhiro Suzuki > <katsuhiro@katsuster.net> wrote: > > > > Hello Tony, > > > > On 2019/03/04 0:13, Tony McKahan wrote: > > > On Sun, Mar 3, 2019 at 9:04 AM Katsuhiro Suzuki <katsuhiro@katsuster.net> wrote: > > >> > > >> Hello Heiko, > > >> > > >> Thank you for comments. > > >> > > >> On 2019/03/03 22:19, Heiko Stuebner wrote: > > >>> Hi, > > >>> > > >>> Am Sonntag, 3. März 2019, 13:27:05 CET schrieb Katsuhiro Suzuki: > > >>>> This patch increases drive strength of UART2 from 3mA to 12mA for > > >>>> getting more faster rising edge. > > >>>> > > >>>> RockPro64 is using a very high speed rate (1.5Mbps) for UART2. In > > >>>> this setting, a bit width of UART is about 667ns. > > >>>> > > >>>> In my environment (RockPro64 UART2 with FTDI FT232RL UART-USB > > >>>> converter), falling time of RockPro64 UART2 is 40ns, but riging time > > >>>> is over 650ns. So UART receiver will get wrong data, because receiver > > >>>> read intermediate data of rising edge. > > >>>> > > >>>> Rising time becomes 300ns from 650ns if apply this patch. This is not > > >>>> perfect solution but better than now. > > >>>> > > >>>> Signed-off-by: Katsuhiro Suzuki <katsuhiro@katsuster.net> > > >>>> --- > > >>>> arch/arm64/boot/dts/rockchip/rk3399.dtsi | 9 +++++++-- > > >>>> 1 file changed, 7 insertions(+), 2 deletions(-) > > >>> > > >>> your changing a core rk3399 property here, so I'd really like to get > > >>> input from other board stakeholders on this before applying a core > > >>> change. > > >>> > > >>> Could you either include the submitters of other rk3399-boards in the > > >>> recipient list so that they're aware or limit the change to rockpro64 for > > >>> the time being (aka overriding the property in the board-dts) please? > > >>> > > >> > > >> OK, I'm adding other boards members. > > >> by ./scripts/get_maintainer.pl arch/arm64/boot/dts/rockchip/rk3399-*.dts > > >> > > >> > > >> RockPro64 directly connect UART2 pins of RK3399 to external connector. > > >> I think maybe other RK3399 boards are facing same problem, but I cannot > > >> check it because I have RockPro64 only... > > >> > > >> I'm happy if someone tell me other boards situation. > > > > > > I'm pulling out other rockchip boards momentarily to see what kind of > > > population we have. > > > > > > Note these are not all running 5.x kernels, however none of them have > > > the UART2 drive levels modified to my knowledge, and regardless, none > > > show over 100 ns. > > > > > > board: rise/fall > > > > > > rk3399-roc-pc: 90ns/90ns > > > rk3399-rockpro64 V2.0: 90ns/45ns > > > rk3399-rockpro64 V2.1: 40ns/41ns > > > > > > Please make sure there's not a large amount of flux or something > > > around the terminals on your board, that seems excessively high. > > > > > > > Thank you for valuable information. For more deeply discussion, > > I tried other conditions and watch the rise/fall times. > > > > 1) Not connect > > The rise/fall times are 40ns/5ns when nothing connect (impedance is > > very high) to external pin of RockPro64. > > > > What UART device are you using with RockPro64? If you use some device > > with RockPro64 and board shows rise/fall times = 90ns/45ns, my device > > is not suitable for RockPro64 by some reason. So it's better to drop > > my patch. > > The adapter is an FTDI FT232RL breakout board, attached with some > generic Dupont connector jumpers. > Interesting your RockPro is showing this symptom, perhaps there is a > cold solder joint somewhere introducing resistance? > > > > > 2) Other SoC > > I have other SoC board rk3328-rock64, Rock64 shows rise/fall times = > > 90ns/80ns when same UART-USB device is connected to UART pin. > > I measured similar on my Rock64 as well. > > > > > I think it shows rk3399's (or RockPro64's?) drive strength is a little > > weak. So it's better to increase the drive strength of UART of rk3399. > > I do not think this is a bad idea generally, it simply allows for more > available current from the interface. I'll let others be the judge of > that, however. > > > > > Best Regards, > > Katsuhiro Suzuki > > > > >> > > >> Best Regards, > > >> Katsuhiro Suzuki > > >> > > >> > > >>> Thanks > > >>> Heiko > > >>> > > >>> > > >>> > > >>>> diff --git a/arch/arm64/boot/dts/rockchip/rk3399.dtsi b/arch/arm64/boot/dts/rockchip/rk3399.dtsi > > >>>> index beaa92744a64..e3c8f91ead50 100644 > > >>>> --- a/arch/arm64/boot/dts/rockchip/rk3399.dtsi > > >>>> +++ b/arch/arm64/boot/dts/rockchip/rk3399.dtsi > > >>>> @@ -2000,6 +2000,11 @@ > > >>>> drive-strength = <8>; > > >>>> }; > > >>>> > > >>>> + pcfg_pull_up_12ma: pcfg-pull-up-12ma { > > >>>> + bias-pull-up; > > >>>> + drive-strength = <12>; > > >>>> + }; > > >>>> + > > >>>> pcfg_pull_up_18ma: pcfg-pull-up-18ma { > > >>>> bias-pull-up; > > >>>> drive-strength = <18>; > > >>>> @@ -2521,8 +2526,8 @@ > > >>>> uart2c { > > >>>> uart2c_xfer: uart2c-xfer { > > >>>> rockchip,pins = > > >>>> - <4 RK_PC3 RK_FUNC_1 &pcfg_pull_up>, > > >>>> - <4 RK_PC4 RK_FUNC_1 &pcfg_pull_none>; > > >>>> + <4 RK_PC3 RK_FUNC_1 &pcfg_pull_up_12ma>, > > >>>> + <4 RK_PC4 RK_FUNC_1 &pcfg_pull_none_12ma>; > > >>>> }; > > >>>> }; > > >>>> > > >>>> > > >>> > > >>> > > >>> > > >>> > > >>> > > >>> > > >> > > >> > > >> _______________________________________________ > > >> Linux-rockchip mailing list > > >> Linux-rockchip@lists.infradead.org > > >> http://lists.infradead.org/mailman/listinfo/linux-rockchip > > > > > > > > ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [PATCH] arm64: dts: rockchip: decrease rising edge time of UART2 @ 2019-03-03 19:12 ` Tony McKahan 0 siblings, 0 replies; 43+ messages in thread From: Tony McKahan @ 2019-03-03 19:12 UTC (permalink / raw) To: Katsuhiro Suzuki Cc: Heiko Stuebner, Viresh Kumar, Linus Walleij, linux-kernel, Klaus Goger, Manivannan Sadhasivam, Brian Norris, linux-rockchip, Shawn Lin, Akash Gajjar, Vicente Bergas, Levin Du, Ezequiel Garcia, linux-arm-kernel, Shohei Maruyama, Matthias Brugger, Tomeu Vizoso, Dmitry Torokhov, Douglas Anderson, Jakob Unterwurzacher, Oskari Lemmela, Enric Balletbo i Serra, Robin Murphy, Christoph Muellner On Sun, Mar 3, 2019 at 1:45 PM Tony McKahan <tonymckahan@gmail.com> wrote: > > Hello Katsushiro, And apologies for the extra "s", typing too quickly I'm afraid. > > On Sun, Mar 3, 2019 at 12:31 PM Katsuhiro Suzuki > <katsuhiro@katsuster.net> wrote: > > > > Hello Tony, > > > > On 2019/03/04 0:13, Tony McKahan wrote: > > > On Sun, Mar 3, 2019 at 9:04 AM Katsuhiro Suzuki <katsuhiro@katsuster.net> wrote: > > >> > > >> Hello Heiko, > > >> > > >> Thank you for comments. > > >> > > >> On 2019/03/03 22:19, Heiko Stuebner wrote: > > >>> Hi, > > >>> > > >>> Am Sonntag, 3. März 2019, 13:27:05 CET schrieb Katsuhiro Suzuki: > > >>>> This patch increases drive strength of UART2 from 3mA to 12mA for > > >>>> getting more faster rising edge. > > >>>> > > >>>> RockPro64 is using a very high speed rate (1.5Mbps) for UART2. In > > >>>> this setting, a bit width of UART is about 667ns. > > >>>> > > >>>> In my environment (RockPro64 UART2 with FTDI FT232RL UART-USB > > >>>> converter), falling time of RockPro64 UART2 is 40ns, but riging time > > >>>> is over 650ns. So UART receiver will get wrong data, because receiver > > >>>> read intermediate data of rising edge. > > >>>> > > >>>> Rising time becomes 300ns from 650ns if apply this patch. This is not > > >>>> perfect solution but better than now. > > >>>> > > >>>> Signed-off-by: Katsuhiro Suzuki <katsuhiro@katsuster.net> > > >>>> --- > > >>>> arch/arm64/boot/dts/rockchip/rk3399.dtsi | 9 +++++++-- > > >>>> 1 file changed, 7 insertions(+), 2 deletions(-) > > >>> > > >>> your changing a core rk3399 property here, so I'd really like to get > > >>> input from other board stakeholders on this before applying a core > > >>> change. > > >>> > > >>> Could you either include the submitters of other rk3399-boards in the > > >>> recipient list so that they're aware or limit the change to rockpro64 for > > >>> the time being (aka overriding the property in the board-dts) please? > > >>> > > >> > > >> OK, I'm adding other boards members. > > >> by ./scripts/get_maintainer.pl arch/arm64/boot/dts/rockchip/rk3399-*.dts > > >> > > >> > > >> RockPro64 directly connect UART2 pins of RK3399 to external connector. > > >> I think maybe other RK3399 boards are facing same problem, but I cannot > > >> check it because I have RockPro64 only... > > >> > > >> I'm happy if someone tell me other boards situation. > > > > > > I'm pulling out other rockchip boards momentarily to see what kind of > > > population we have. > > > > > > Note these are not all running 5.x kernels, however none of them have > > > the UART2 drive levels modified to my knowledge, and regardless, none > > > show over 100 ns. > > > > > > board: rise/fall > > > > > > rk3399-roc-pc: 90ns/90ns > > > rk3399-rockpro64 V2.0: 90ns/45ns > > > rk3399-rockpro64 V2.1: 40ns/41ns > > > > > > Please make sure there's not a large amount of flux or something > > > around the terminals on your board, that seems excessively high. > > > > > > > Thank you for valuable information. For more deeply discussion, > > I tried other conditions and watch the rise/fall times. > > > > 1) Not connect > > The rise/fall times are 40ns/5ns when nothing connect (impedance is > > very high) to external pin of RockPro64. > > > > What UART device are you using with RockPro64? If you use some device > > with RockPro64 and board shows rise/fall times = 90ns/45ns, my device > > is not suitable for RockPro64 by some reason. So it's better to drop > > my patch. > > The adapter is an FTDI FT232RL breakout board, attached with some > generic Dupont connector jumpers. > Interesting your RockPro is showing this symptom, perhaps there is a > cold solder joint somewhere introducing resistance? > > > > > 2) Other SoC > > I have other SoC board rk3328-rock64, Rock64 shows rise/fall times = > > 90ns/80ns when same UART-USB device is connected to UART pin. > > I measured similar on my Rock64 as well. > > > > > I think it shows rk3399's (or RockPro64's?) drive strength is a little > > weak. So it's better to increase the drive strength of UART of rk3399. > > I do not think this is a bad idea generally, it simply allows for more > available current from the interface. I'll let others be the judge of > that, however. > > > > > Best Regards, > > Katsuhiro Suzuki > > > > >> > > >> Best Regards, > > >> Katsuhiro Suzuki > > >> > > >> > > >>> Thanks > > >>> Heiko > > >>> > > >>> > > >>> > > >>>> diff --git a/arch/arm64/boot/dts/rockchip/rk3399.dtsi b/arch/arm64/boot/dts/rockchip/rk3399.dtsi > > >>>> index beaa92744a64..e3c8f91ead50 100644 > > >>>> --- a/arch/arm64/boot/dts/rockchip/rk3399.dtsi > > >>>> +++ b/arch/arm64/boot/dts/rockchip/rk3399.dtsi > > >>>> @@ -2000,6 +2000,11 @@ > > >>>> drive-strength = <8>; > > >>>> }; > > >>>> > > >>>> + pcfg_pull_up_12ma: pcfg-pull-up-12ma { > > >>>> + bias-pull-up; > > >>>> + drive-strength = <12>; > > >>>> + }; > > >>>> + > > >>>> pcfg_pull_up_18ma: pcfg-pull-up-18ma { > > >>>> bias-pull-up; > > >>>> drive-strength = <18>; > > >>>> @@ -2521,8 +2526,8 @@ > > >>>> uart2c { > > >>>> uart2c_xfer: uart2c-xfer { > > >>>> rockchip,pins = > > >>>> - <4 RK_PC3 RK_FUNC_1 &pcfg_pull_up>, > > >>>> - <4 RK_PC4 RK_FUNC_1 &pcfg_pull_none>; > > >>>> + <4 RK_PC3 RK_FUNC_1 &pcfg_pull_up_12ma>, > > >>>> + <4 RK_PC4 RK_FUNC_1 &pcfg_pull_none_12ma>; > > >>>> }; > > >>>> }; > > >>>> > > >>>> > > >>> > > >>> > > >>> > > >>> > > >>> > > >>> > > >> > > >> > > >> _______________________________________________ > > >> Linux-rockchip mailing list > > >> Linux-rockchip@lists.infradead.org > > >> http://lists.infradead.org/mailman/listinfo/linux-rockchip > > > > > > > > _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [PATCH] arm64: dts: rockchip: decrease rising edge time of UART2 2019-03-03 19:12 ` Tony McKahan (?) @ 2019-03-04 13:56 ` Katsuhiro Suzuki -1 siblings, 0 replies; 43+ messages in thread From: Katsuhiro Suzuki @ 2019-03-04 13:56 UTC (permalink / raw) To: Tony McKahan Cc: Heiko Stuebner, Viresh Kumar, Linus Walleij, linux-kernel, Klaus Goger, Manivannan Sadhasivam, Brian Norris, linux-rockchip, Shawn Lin, Akash Gajjar, Vicente Bergas, Levin Du, Ezequiel Garcia, linux-arm-kernel, Shohei Maruyama, Matthias Brugger, Tomeu Vizoso, Dmitry Torokhov, Douglas Anderson <dianders> No problem! Thank you for discussion :) On 2019/03/04 4:12, Tony McKahan wrote: > On Sun, Mar 3, 2019 at 1:45 PM Tony McKahan <tonymckahan@gmail.com> wrote: >> >> Hello Katsushiro, > > And apologies for the extra "s", typing too quickly I'm afraid. >> >> On Sun, Mar 3, 2019 at 12:31 PM Katsuhiro Suzuki >> <katsuhiro@katsuster.net> wrote: >>> >>> Hello Tony, >>> >>> On 2019/03/04 0:13, Tony McKahan wrote: >>>> On Sun, Mar 3, 2019 at 9:04 AM Katsuhiro Suzuki <katsuhiro@katsuster.net> wrote: >>>>> >>>>> Hello Heiko, >>>>> >>>>> Thank you for comments. >>>>> >>>>> On 2019/03/03 22:19, Heiko Stuebner wrote: >>>>>> Hi, >>>>>> >>>>>> Am Sonntag, 3. März 2019, 13:27:05 CET schrieb Katsuhiro Suzuki: >>>>>>> This patch increases drive strength of UART2 from 3mA to 12mA for >>>>>>> getting more faster rising edge. >>>>>>> >>>>>>> RockPro64 is using a very high speed rate (1.5Mbps) for UART2. In >>>>>>> this setting, a bit width of UART is about 667ns. >>>>>>> >>>>>>> In my environment (RockPro64 UART2 with FTDI FT232RL UART-USB >>>>>>> converter), falling time of RockPro64 UART2 is 40ns, but riging time >>>>>>> is over 650ns. So UART receiver will get wrong data, because receiver >>>>>>> read intermediate data of rising edge. >>>>>>> >>>>>>> Rising time becomes 300ns from 650ns if apply this patch. This is not >>>>>>> perfect solution but better than now. >>>>>>> >>>>>>> Signed-off-by: Katsuhiro Suzuki <katsuhiro@katsuster.net> >>>>>>> --- >>>>>>> arch/arm64/boot/dts/rockchip/rk3399.dtsi | 9 +++++++-- >>>>>>> 1 file changed, 7 insertions(+), 2 deletions(-) >>>>>> >>>>>> your changing a core rk3399 property here, so I'd really like to get >>>>>> input from other board stakeholders on this before applying a core >>>>>> change. >>>>>> >>>>>> Could you either include the submitters of other rk3399-boards in the >>>>>> recipient list so that they're aware or limit the change to rockpro64 for >>>>>> the time being (aka overriding the property in the board-dts) please? >>>>>> >>>>> >>>>> OK, I'm adding other boards members. >>>>> by ./scripts/get_maintainer.pl arch/arm64/boot/dts/rockchip/rk3399-*.dts >>>>> >>>>> >>>>> RockPro64 directly connect UART2 pins of RK3399 to external connector. >>>>> I think maybe other RK3399 boards are facing same problem, but I cannot >>>>> check it because I have RockPro64 only... >>>>> >>>>> I'm happy if someone tell me other boards situation. >>>> >>>> I'm pulling out other rockchip boards momentarily to see what kind of >>>> population we have. >>>> >>>> Note these are not all running 5.x kernels, however none of them have >>>> the UART2 drive levels modified to my knowledge, and regardless, none >>>> show over 100 ns. >>>> >>>> board: rise/fall >>>> >>>> rk3399-roc-pc: 90ns/90ns >>>> rk3399-rockpro64 V2.0: 90ns/45ns >>>> rk3399-rockpro64 V2.1: 40ns/41ns >>>> >>>> Please make sure there's not a large amount of flux or something >>>> around the terminals on your board, that seems excessively high. >>>> >>> >>> Thank you for valuable information. For more deeply discussion, >>> I tried other conditions and watch the rise/fall times. >>> >>> 1) Not connect >>> The rise/fall times are 40ns/5ns when nothing connect (impedance is >>> very high) to external pin of RockPro64. >>> >>> What UART device are you using with RockPro64? If you use some device >>> with RockPro64 and board shows rise/fall times = 90ns/45ns, my device >>> is not suitable for RockPro64 by some reason. So it's better to drop >>> my patch. >> >> The adapter is an FTDI FT232RL breakout board, attached with some >> generic Dupont connector jumpers. >> Interesting your RockPro is showing this symptom, perhaps there is a >> cold solder joint somewhere introducing resistance? >> >>> >>> 2) Other SoC >>> I have other SoC board rk3328-rock64, Rock64 shows rise/fall times = >>> 90ns/80ns when same UART-USB device is connected to UART pin. >> >> I measured similar on my Rock64 as well. >> >>> >>> I think it shows rk3399's (or RockPro64's?) drive strength is a little >>> weak. So it's better to increase the drive strength of UART of rk3399. >> >> I do not think this is a bad idea generally, it simply allows for more >> available current from the interface. I'll let others be the judge of >> that, however. >> >>> >>> Best Regards, >>> Katsuhiro Suzuki >>> >>>>> >>>>> Best Regards, >>>>> Katsuhiro Suzuki >>>>> >>>>> >>>>>> Thanks >>>>>> Heiko >>>>>> >>>>>> >>>>>> >>>>>>> diff --git a/arch/arm64/boot/dts/rockchip/rk3399.dtsi b/arch/arm64/boot/dts/rockchip/rk3399.dtsi >>>>>>> index beaa92744a64..e3c8f91ead50 100644 >>>>>>> --- a/arch/arm64/boot/dts/rockchip/rk3399.dtsi >>>>>>> +++ b/arch/arm64/boot/dts/rockchip/rk3399.dtsi >>>>>>> @@ -2000,6 +2000,11 @@ >>>>>>> drive-strength = <8>; >>>>>>> }; >>>>>>> >>>>>>> + pcfg_pull_up_12ma: pcfg-pull-up-12ma { >>>>>>> + bias-pull-up; >>>>>>> + drive-strength = <12>; >>>>>>> + }; >>>>>>> + >>>>>>> pcfg_pull_up_18ma: pcfg-pull-up-18ma { >>>>>>> bias-pull-up; >>>>>>> drive-strength = <18>; >>>>>>> @@ -2521,8 +2526,8 @@ >>>>>>> uart2c { >>>>>>> uart2c_xfer: uart2c-xfer { >>>>>>> rockchip,pins = >>>>>>> - <4 RK_PC3 RK_FUNC_1 &pcfg_pull_up>, >>>>>>> - <4 RK_PC4 RK_FUNC_1 &pcfg_pull_none>; >>>>>>> + <4 RK_PC3 RK_FUNC_1 &pcfg_pull_up_12ma>, >>>>>>> + <4 RK_PC4 RK_FUNC_1 &pcfg_pull_none_12ma>; >>>>>>> }; >>>>>>> }; >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> Linux-rockchip mailing list >>>>> Linux-rockchip@lists.infradead.org >>>>> http://lists.infradead.org/mailman/listinfo/linux-rockchip >>>> >>>> >>> > > _______________________________________________ > Linux-rockchip mailing list > Linux-rockchip@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-rockchip > > ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [PATCH] arm64: dts: rockchip: decrease rising edge time of UART2 @ 2019-03-04 13:56 ` Katsuhiro Suzuki 0 siblings, 0 replies; 43+ messages in thread From: Katsuhiro Suzuki @ 2019-03-04 13:56 UTC (permalink / raw) To: Tony McKahan Cc: Heiko Stuebner, Viresh Kumar, Linus Walleij, linux-kernel, Klaus Goger, Manivannan Sadhasivam, Brian Norris, linux-rockchip, Shawn Lin, Akash Gajjar, Vicente Bergas, Levin Du, Ezequiel Garcia, linux-arm-kernel, Shohei Maruyama, Matthias Brugger, Tomeu Vizoso, Dmitry Torokhov, Douglas Anderson, Jakob Unterwurzacher, Oskari Lemmela, Enric Balletbo i Serra, Robin Murphy, Christoph Muellner No problem! Thank you for discussion :) On 2019/03/04 4:12, Tony McKahan wrote: > On Sun, Mar 3, 2019 at 1:45 PM Tony McKahan <tonymckahan@gmail.com> wrote: >> >> Hello Katsushiro, > > And apologies for the extra "s", typing too quickly I'm afraid. >> >> On Sun, Mar 3, 2019 at 12:31 PM Katsuhiro Suzuki >> <katsuhiro@katsuster.net> wrote: >>> >>> Hello Tony, >>> >>> On 2019/03/04 0:13, Tony McKahan wrote: >>>> On Sun, Mar 3, 2019 at 9:04 AM Katsuhiro Suzuki <katsuhiro@katsuster.net> wrote: >>>>> >>>>> Hello Heiko, >>>>> >>>>> Thank you for comments. >>>>> >>>>> On 2019/03/03 22:19, Heiko Stuebner wrote: >>>>>> Hi, >>>>>> >>>>>> Am Sonntag, 3. März 2019, 13:27:05 CET schrieb Katsuhiro Suzuki: >>>>>>> This patch increases drive strength of UART2 from 3mA to 12mA for >>>>>>> getting more faster rising edge. >>>>>>> >>>>>>> RockPro64 is using a very high speed rate (1.5Mbps) for UART2. In >>>>>>> this setting, a bit width of UART is about 667ns. >>>>>>> >>>>>>> In my environment (RockPro64 UART2 with FTDI FT232RL UART-USB >>>>>>> converter), falling time of RockPro64 UART2 is 40ns, but riging time >>>>>>> is over 650ns. So UART receiver will get wrong data, because receiver >>>>>>> read intermediate data of rising edge. >>>>>>> >>>>>>> Rising time becomes 300ns from 650ns if apply this patch. This is not >>>>>>> perfect solution but better than now. >>>>>>> >>>>>>> Signed-off-by: Katsuhiro Suzuki <katsuhiro@katsuster.net> >>>>>>> --- >>>>>>> arch/arm64/boot/dts/rockchip/rk3399.dtsi | 9 +++++++-- >>>>>>> 1 file changed, 7 insertions(+), 2 deletions(-) >>>>>> >>>>>> your changing a core rk3399 property here, so I'd really like to get >>>>>> input from other board stakeholders on this before applying a core >>>>>> change. >>>>>> >>>>>> Could you either include the submitters of other rk3399-boards in the >>>>>> recipient list so that they're aware or limit the change to rockpro64 for >>>>>> the time being (aka overriding the property in the board-dts) please? >>>>>> >>>>> >>>>> OK, I'm adding other boards members. >>>>> by ./scripts/get_maintainer.pl arch/arm64/boot/dts/rockchip/rk3399-*.dts >>>>> >>>>> >>>>> RockPro64 directly connect UART2 pins of RK3399 to external connector. >>>>> I think maybe other RK3399 boards are facing same problem, but I cannot >>>>> check it because I have RockPro64 only... >>>>> >>>>> I'm happy if someone tell me other boards situation. >>>> >>>> I'm pulling out other rockchip boards momentarily to see what kind of >>>> population we have. >>>> >>>> Note these are not all running 5.x kernels, however none of them have >>>> the UART2 drive levels modified to my knowledge, and regardless, none >>>> show over 100 ns. >>>> >>>> board: rise/fall >>>> >>>> rk3399-roc-pc: 90ns/90ns >>>> rk3399-rockpro64 V2.0: 90ns/45ns >>>> rk3399-rockpro64 V2.1: 40ns/41ns >>>> >>>> Please make sure there's not a large amount of flux or something >>>> around the terminals on your board, that seems excessively high. >>>> >>> >>> Thank you for valuable information. For more deeply discussion, >>> I tried other conditions and watch the rise/fall times. >>> >>> 1) Not connect >>> The rise/fall times are 40ns/5ns when nothing connect (impedance is >>> very high) to external pin of RockPro64. >>> >>> What UART device are you using with RockPro64? If you use some device >>> with RockPro64 and board shows rise/fall times = 90ns/45ns, my device >>> is not suitable for RockPro64 by some reason. So it's better to drop >>> my patch. >> >> The adapter is an FTDI FT232RL breakout board, attached with some >> generic Dupont connector jumpers. >> Interesting your RockPro is showing this symptom, perhaps there is a >> cold solder joint somewhere introducing resistance? >> >>> >>> 2) Other SoC >>> I have other SoC board rk3328-rock64, Rock64 shows rise/fall times = >>> 90ns/80ns when same UART-USB device is connected to UART pin. >> >> I measured similar on my Rock64 as well. >> >>> >>> I think it shows rk3399's (or RockPro64's?) drive strength is a little >>> weak. So it's better to increase the drive strength of UART of rk3399. >> >> I do not think this is a bad idea generally, it simply allows for more >> available current from the interface. I'll let others be the judge of >> that, however. >> >>> >>> Best Regards, >>> Katsuhiro Suzuki >>> >>>>> >>>>> Best Regards, >>>>> Katsuhiro Suzuki >>>>> >>>>> >>>>>> Thanks >>>>>> Heiko >>>>>> >>>>>> >>>>>> >>>>>>> diff --git a/arch/arm64/boot/dts/rockchip/rk3399.dtsi b/arch/arm64/boot/dts/rockchip/rk3399.dtsi >>>>>>> index beaa92744a64..e3c8f91ead50 100644 >>>>>>> --- a/arch/arm64/boot/dts/rockchip/rk3399.dtsi >>>>>>> +++ b/arch/arm64/boot/dts/rockchip/rk3399.dtsi >>>>>>> @@ -2000,6 +2000,11 @@ >>>>>>> drive-strength = <8>; >>>>>>> }; >>>>>>> >>>>>>> + pcfg_pull_up_12ma: pcfg-pull-up-12ma { >>>>>>> + bias-pull-up; >>>>>>> + drive-strength = <12>; >>>>>>> + }; >>>>>>> + >>>>>>> pcfg_pull_up_18ma: pcfg-pull-up-18ma { >>>>>>> bias-pull-up; >>>>>>> drive-strength = <18>; >>>>>>> @@ -2521,8 +2526,8 @@ >>>>>>> uart2c { >>>>>>> uart2c_xfer: uart2c-xfer { >>>>>>> rockchip,pins = >>>>>>> - <4 RK_PC3 RK_FUNC_1 &pcfg_pull_up>, >>>>>>> - <4 RK_PC4 RK_FUNC_1 &pcfg_pull_none>; >>>>>>> + <4 RK_PC3 RK_FUNC_1 &pcfg_pull_up_12ma>, >>>>>>> + <4 RK_PC4 RK_FUNC_1 &pcfg_pull_none_12ma>; >>>>>>> }; >>>>>>> }; >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> Linux-rockchip mailing list >>>>> Linux-rockchip@lists.infradead.org >>>>> http://lists.infradead.org/mailman/listinfo/linux-rockchip >>>> >>>> >>> > > _______________________________________________ > Linux-rockchip mailing list > Linux-rockchip@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-rockchip > > ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [PATCH] arm64: dts: rockchip: decrease rising edge time of UART2 @ 2019-03-04 13:56 ` Katsuhiro Suzuki 0 siblings, 0 replies; 43+ messages in thread From: Katsuhiro Suzuki @ 2019-03-04 13:56 UTC (permalink / raw) To: Tony McKahan Cc: Heiko Stuebner, Viresh Kumar, Linus Walleij, Douglas Anderson, Klaus Goger, Manivannan Sadhasivam, Brian Norris, linux-rockchip, Shawn Lin, Jakob Unterwurzacher, Akash Gajjar, Vicente Bergas, Levin Du, Ezequiel Garcia, linux-arm-kernel, Shohei Maruyama, Matthias Brugger, Tomeu Vizoso, Dmitry Torokhov, linux-kernel, Oskari Lemmela, Enric Balletbo i Serra, Robin Murphy, Christoph Muellner No problem! Thank you for discussion :) On 2019/03/04 4:12, Tony McKahan wrote: > On Sun, Mar 3, 2019 at 1:45 PM Tony McKahan <tonymckahan@gmail.com> wrote: >> >> Hello Katsushiro, > > And apologies for the extra "s", typing too quickly I'm afraid. >> >> On Sun, Mar 3, 2019 at 12:31 PM Katsuhiro Suzuki >> <katsuhiro@katsuster.net> wrote: >>> >>> Hello Tony, >>> >>> On 2019/03/04 0:13, Tony McKahan wrote: >>>> On Sun, Mar 3, 2019 at 9:04 AM Katsuhiro Suzuki <katsuhiro@katsuster.net> wrote: >>>>> >>>>> Hello Heiko, >>>>> >>>>> Thank you for comments. >>>>> >>>>> On 2019/03/03 22:19, Heiko Stuebner wrote: >>>>>> Hi, >>>>>> >>>>>> Am Sonntag, 3. März 2019, 13:27:05 CET schrieb Katsuhiro Suzuki: >>>>>>> This patch increases drive strength of UART2 from 3mA to 12mA for >>>>>>> getting more faster rising edge. >>>>>>> >>>>>>> RockPro64 is using a very high speed rate (1.5Mbps) for UART2. In >>>>>>> this setting, a bit width of UART is about 667ns. >>>>>>> >>>>>>> In my environment (RockPro64 UART2 with FTDI FT232RL UART-USB >>>>>>> converter), falling time of RockPro64 UART2 is 40ns, but riging time >>>>>>> is over 650ns. So UART receiver will get wrong data, because receiver >>>>>>> read intermediate data of rising edge. >>>>>>> >>>>>>> Rising time becomes 300ns from 650ns if apply this patch. This is not >>>>>>> perfect solution but better than now. >>>>>>> >>>>>>> Signed-off-by: Katsuhiro Suzuki <katsuhiro@katsuster.net> >>>>>>> --- >>>>>>> arch/arm64/boot/dts/rockchip/rk3399.dtsi | 9 +++++++-- >>>>>>> 1 file changed, 7 insertions(+), 2 deletions(-) >>>>>> >>>>>> your changing a core rk3399 property here, so I'd really like to get >>>>>> input from other board stakeholders on this before applying a core >>>>>> change. >>>>>> >>>>>> Could you either include the submitters of other rk3399-boards in the >>>>>> recipient list so that they're aware or limit the change to rockpro64 for >>>>>> the time being (aka overriding the property in the board-dts) please? >>>>>> >>>>> >>>>> OK, I'm adding other boards members. >>>>> by ./scripts/get_maintainer.pl arch/arm64/boot/dts/rockchip/rk3399-*.dts >>>>> >>>>> >>>>> RockPro64 directly connect UART2 pins of RK3399 to external connector. >>>>> I think maybe other RK3399 boards are facing same problem, but I cannot >>>>> check it because I have RockPro64 only... >>>>> >>>>> I'm happy if someone tell me other boards situation. >>>> >>>> I'm pulling out other rockchip boards momentarily to see what kind of >>>> population we have. >>>> >>>> Note these are not all running 5.x kernels, however none of them have >>>> the UART2 drive levels modified to my knowledge, and regardless, none >>>> show over 100 ns. >>>> >>>> board: rise/fall >>>> >>>> rk3399-roc-pc: 90ns/90ns >>>> rk3399-rockpro64 V2.0: 90ns/45ns >>>> rk3399-rockpro64 V2.1: 40ns/41ns >>>> >>>> Please make sure there's not a large amount of flux or something >>>> around the terminals on your board, that seems excessively high. >>>> >>> >>> Thank you for valuable information. For more deeply discussion, >>> I tried other conditions and watch the rise/fall times. >>> >>> 1) Not connect >>> The rise/fall times are 40ns/5ns when nothing connect (impedance is >>> very high) to external pin of RockPro64. >>> >>> What UART device are you using with RockPro64? If you use some device >>> with RockPro64 and board shows rise/fall times = 90ns/45ns, my device >>> is not suitable for RockPro64 by some reason. So it's better to drop >>> my patch. >> >> The adapter is an FTDI FT232RL breakout board, attached with some >> generic Dupont connector jumpers. >> Interesting your RockPro is showing this symptom, perhaps there is a >> cold solder joint somewhere introducing resistance? >> >>> >>> 2) Other SoC >>> I have other SoC board rk3328-rock64, Rock64 shows rise/fall times = >>> 90ns/80ns when same UART-USB device is connected to UART pin. >> >> I measured similar on my Rock64 as well. >> >>> >>> I think it shows rk3399's (or RockPro64's?) drive strength is a little >>> weak. So it's better to increase the drive strength of UART of rk3399. >> >> I do not think this is a bad idea generally, it simply allows for more >> available current from the interface. I'll let others be the judge of >> that, however. >> >>> >>> Best Regards, >>> Katsuhiro Suzuki >>> >>>>> >>>>> Best Regards, >>>>> Katsuhiro Suzuki >>>>> >>>>> >>>>>> Thanks >>>>>> Heiko >>>>>> >>>>>> >>>>>> >>>>>>> diff --git a/arch/arm64/boot/dts/rockchip/rk3399.dtsi b/arch/arm64/boot/dts/rockchip/rk3399.dtsi >>>>>>> index beaa92744a64..e3c8f91ead50 100644 >>>>>>> --- a/arch/arm64/boot/dts/rockchip/rk3399.dtsi >>>>>>> +++ b/arch/arm64/boot/dts/rockchip/rk3399.dtsi >>>>>>> @@ -2000,6 +2000,11 @@ >>>>>>> drive-strength = <8>; >>>>>>> }; >>>>>>> >>>>>>> + pcfg_pull_up_12ma: pcfg-pull-up-12ma { >>>>>>> + bias-pull-up; >>>>>>> + drive-strength = <12>; >>>>>>> + }; >>>>>>> + >>>>>>> pcfg_pull_up_18ma: pcfg-pull-up-18ma { >>>>>>> bias-pull-up; >>>>>>> drive-strength = <18>; >>>>>>> @@ -2521,8 +2526,8 @@ >>>>>>> uart2c { >>>>>>> uart2c_xfer: uart2c-xfer { >>>>>>> rockchip,pins = >>>>>>> - <4 RK_PC3 RK_FUNC_1 &pcfg_pull_up>, >>>>>>> - <4 RK_PC4 RK_FUNC_1 &pcfg_pull_none>; >>>>>>> + <4 RK_PC3 RK_FUNC_1 &pcfg_pull_up_12ma>, >>>>>>> + <4 RK_PC4 RK_FUNC_1 &pcfg_pull_none_12ma>; >>>>>>> }; >>>>>>> }; >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> Linux-rockchip mailing list >>>>> Linux-rockchip@lists.infradead.org >>>>> http://lists.infradead.org/mailman/listinfo/linux-rockchip >>>> >>>> >>> > > _______________________________________________ > Linux-rockchip mailing list > Linux-rockchip@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-rockchip > > _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [PATCH] arm64: dts: rockchip: decrease rising edge time of UART2 2019-03-03 18:45 ` Tony McKahan (?) @ 2019-03-03 19:50 ` Robin Murphy -1 siblings, 0 replies; 43+ messages in thread From: Robin Murphy @ 2019-03-03 19:50 UTC (permalink / raw) To: Tony McKahan, Katsuhiro Suzuki Cc: Heiko Stuebner, Akash Gajjar, Brian Norris, Christoph Muellner, Dmitry Torokhov, Douglas Anderson, Enric Balletbo i Serra, Ezequiel Garcia, Jakob Unterwurzacher, Klaus Goger, Levin Du, Linus Walleij, Manivannan Sadhasivam, Matthias Brugger, Oskari Lemmela, Shawn Lin, Shohei Maruyama On 2019-03-03 6:45 pm, Tony McKahan wrote: > Hello Katsushiro, > > On Sun, Mar 3, 2019 at 12:31 PM Katsuhiro Suzuki > <katsuhiro@katsuster.net> wrote: >> >> Hello Tony, >> >> On 2019/03/04 0:13, Tony McKahan wrote: >>> On Sun, Mar 3, 2019 at 9:04 AM Katsuhiro Suzuki <katsuhiro@katsuster.net> wrote: >>>> >>>> Hello Heiko, >>>> >>>> Thank you for comments. >>>> >>>> On 2019/03/03 22:19, Heiko Stuebner wrote: >>>>> Hi, >>>>> >>>>> Am Sonntag, 3. März 2019, 13:27:05 CET schrieb Katsuhiro Suzuki: >>>>>> This patch increases drive strength of UART2 from 3mA to 12mA for >>>>>> getting more faster rising edge. >>>>>> >>>>>> RockPro64 is using a very high speed rate (1.5Mbps) for UART2. In >>>>>> this setting, a bit width of UART is about 667ns. >>>>>> >>>>>> In my environment (RockPro64 UART2 with FTDI FT232RL UART-USB >>>>>> converter), falling time of RockPro64 UART2 is 40ns, but riging time >>>>>> is over 650ns. So UART receiver will get wrong data, because receiver >>>>>> read intermediate data of rising edge. >>>>>> >>>>>> Rising time becomes 300ns from 650ns if apply this patch. This is not >>>>>> perfect solution but better than now. >>>>>> >>>>>> Signed-off-by: Katsuhiro Suzuki <katsuhiro@katsuster.net> >>>>>> --- >>>>>> arch/arm64/boot/dts/rockchip/rk3399.dtsi | 9 +++++++-- >>>>>> 1 file changed, 7 insertions(+), 2 deletions(-) >>>>> >>>>> your changing a core rk3399 property here, so I'd really like to get >>>>> input from other board stakeholders on this before applying a core >>>>> change. >>>>> >>>>> Could you either include the submitters of other rk3399-boards in the >>>>> recipient list so that they're aware or limit the change to rockpro64 for >>>>> the time being (aka overriding the property in the board-dts) please? >>>>> >>>> >>>> OK, I'm adding other boards members. >>>> by ./scripts/get_maintainer.pl arch/arm64/boot/dts/rockchip/rk3399-*.dts >>>> >>>> >>>> RockPro64 directly connect UART2 pins of RK3399 to external connector. >>>> I think maybe other RK3399 boards are facing same problem, but I cannot >>>> check it because I have RockPro64 only... >>>> >>>> I'm happy if someone tell me other boards situation. >>> >>> I'm pulling out other rockchip boards momentarily to see what kind of >>> population we have. >>> >>> Note these are not all running 5.x kernels, however none of them have >>> the UART2 drive levels modified to my knowledge, and regardless, none >>> show over 100 ns. >>> >>> board: rise/fall >>> >>> rk3399-roc-pc: 90ns/90ns >>> rk3399-rockpro64 V2.0: 90ns/45ns >>> rk3399-rockpro64 V2.1: 40ns/41ns I'm having to eyeball off a 20MHz analog scope (thank goodness for "yes" being able to generate a nice periodic signal), but for my NanoPC-T4 with a cheap eBay FT232R adapter both rise and fall times are certainly <100ns. FWIW I've not noticed any issues with letting the Bluetooth interface on UART0 run flat-out at 4Mbaud either. >>> >>> Please make sure there's not a large amount of flux or something >>> around the terminals on your board, that seems excessively high. >>> >> >> Thank you for valuable information. For more deeply discussion, >> I tried other conditions and watch the rise/fall times. >> >> 1) Not connect >> The rise/fall times are 40ns/5ns when nothing connect (impedance is >> very high) to external pin of RockPro64. >> >> What UART device are you using with RockPro64? If you use some device >> with RockPro64 and board shows rise/fall times = 90ns/45ns, my device >> is not suitable for RockPro64 by some reason. So it's better to drop >> my patch. > > The adapter is an FTDI FT232RL breakout board, attached with some > generic Dupont connector jumpers. > Interesting your RockPro is showing this symptom, perhaps there is a > cold solder joint somewhere introducing resistance? > >> >> 2) Other SoC >> I have other SoC board rk3328-rock64, Rock64 shows rise/fall times = >> 90ns/80ns when same UART-USB device is connected to UART pin. > > I measured similar on my Rock64 as well. > >> >> I think it shows rk3399's (or RockPro64's?) drive strength is a little >> weak. So it's better to increase the drive strength of UART of rk3399. > > I do not think this is a bad idea generally, it simply allows for more > available current from the interface. I'll let others be the judge of > that, however. There may be RK3399 users who would care about the possible EMI impact, so it's probably still best to limit such a change to boards which definitely need it. Robin. > >> >> Best Regards, >> Katsuhiro Suzuki >> >>>> >>>> Best Regards, >>>> Katsuhiro Suzuki >>>> >>>> >>>>> Thanks >>>>> Heiko >>>>> >>>>> >>>>> >>>>>> diff --git a/arch/arm64/boot/dts/rockchip/rk3399.dtsi b/arch/arm64/boot/dts/rockchip/rk3399.dtsi >>>>>> index beaa92744a64..e3c8f91ead50 100644 >>>>>> --- a/arch/arm64/boot/dts/rockchip/rk3399.dtsi >>>>>> +++ b/arch/arm64/boot/dts/rockchip/rk3399.dtsi >>>>>> @@ -2000,6 +2000,11 @@ >>>>>> drive-strength = <8>; >>>>>> }; >>>>>> >>>>>> + pcfg_pull_up_12ma: pcfg-pull-up-12ma { >>>>>> + bias-pull-up; >>>>>> + drive-strength = <12>; >>>>>> + }; >>>>>> + >>>>>> pcfg_pull_up_18ma: pcfg-pull-up-18ma { >>>>>> bias-pull-up; >>>>>> drive-strength = <18>; >>>>>> @@ -2521,8 +2526,8 @@ >>>>>> uart2c { >>>>>> uart2c_xfer: uart2c-xfer { >>>>>> rockchip,pins = >>>>>> - <4 RK_PC3 RK_FUNC_1 &pcfg_pull_up>, >>>>>> - <4 RK_PC4 RK_FUNC_1 &pcfg_pull_none>; >>>>>> + <4 RK_PC3 RK_FUNC_1 &pcfg_pull_up_12ma>, >>>>>> + <4 RK_PC4 RK_FUNC_1 &pcfg_pull_none_12ma>; >>>>>> }; >>>>>> }; >>>>>> >>>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>> >>>> >>>> _______________________________________________ >>>> Linux-rockchip mailing list >>>> Linux-rockchip@lists.infradead.org >>>> http://lists.infradead.org/mailman/listinfo/linux-rockchip >>> >>> >> ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [PATCH] arm64: dts: rockchip: decrease rising edge time of UART2 @ 2019-03-03 19:50 ` Robin Murphy 0 siblings, 0 replies; 43+ messages in thread From: Robin Murphy @ 2019-03-03 19:50 UTC (permalink / raw) To: Tony McKahan, Katsuhiro Suzuki Cc: Heiko Stuebner, Akash Gajjar, Brian Norris, Christoph Muellner, Dmitry Torokhov, Douglas Anderson, Enric Balletbo i Serra, Ezequiel Garcia, Jakob Unterwurzacher, Klaus Goger, Levin Du, Linus Walleij, Manivannan Sadhasivam, Matthias Brugger, Oskari Lemmela, Shawn Lin, Shohei Maruyama, Tomeu Vizoso, Vicente Bergas, Viresh Kumar, linux-rockchip, linux-kernel, linux-arm-kernel On 2019-03-03 6:45 pm, Tony McKahan wrote: > Hello Katsushiro, > > On Sun, Mar 3, 2019 at 12:31 PM Katsuhiro Suzuki > <katsuhiro@katsuster.net> wrote: >> >> Hello Tony, >> >> On 2019/03/04 0:13, Tony McKahan wrote: >>> On Sun, Mar 3, 2019 at 9:04 AM Katsuhiro Suzuki <katsuhiro@katsuster.net> wrote: >>>> >>>> Hello Heiko, >>>> >>>> Thank you for comments. >>>> >>>> On 2019/03/03 22:19, Heiko Stuebner wrote: >>>>> Hi, >>>>> >>>>> Am Sonntag, 3. März 2019, 13:27:05 CET schrieb Katsuhiro Suzuki: >>>>>> This patch increases drive strength of UART2 from 3mA to 12mA for >>>>>> getting more faster rising edge. >>>>>> >>>>>> RockPro64 is using a very high speed rate (1.5Mbps) for UART2. In >>>>>> this setting, a bit width of UART is about 667ns. >>>>>> >>>>>> In my environment (RockPro64 UART2 with FTDI FT232RL UART-USB >>>>>> converter), falling time of RockPro64 UART2 is 40ns, but riging time >>>>>> is over 650ns. So UART receiver will get wrong data, because receiver >>>>>> read intermediate data of rising edge. >>>>>> >>>>>> Rising time becomes 300ns from 650ns if apply this patch. This is not >>>>>> perfect solution but better than now. >>>>>> >>>>>> Signed-off-by: Katsuhiro Suzuki <katsuhiro@katsuster.net> >>>>>> --- >>>>>> arch/arm64/boot/dts/rockchip/rk3399.dtsi | 9 +++++++-- >>>>>> 1 file changed, 7 insertions(+), 2 deletions(-) >>>>> >>>>> your changing a core rk3399 property here, so I'd really like to get >>>>> input from other board stakeholders on this before applying a core >>>>> change. >>>>> >>>>> Could you either include the submitters of other rk3399-boards in the >>>>> recipient list so that they're aware or limit the change to rockpro64 for >>>>> the time being (aka overriding the property in the board-dts) please? >>>>> >>>> >>>> OK, I'm adding other boards members. >>>> by ./scripts/get_maintainer.pl arch/arm64/boot/dts/rockchip/rk3399-*.dts >>>> >>>> >>>> RockPro64 directly connect UART2 pins of RK3399 to external connector. >>>> I think maybe other RK3399 boards are facing same problem, but I cannot >>>> check it because I have RockPro64 only... >>>> >>>> I'm happy if someone tell me other boards situation. >>> >>> I'm pulling out other rockchip boards momentarily to see what kind of >>> population we have. >>> >>> Note these are not all running 5.x kernels, however none of them have >>> the UART2 drive levels modified to my knowledge, and regardless, none >>> show over 100 ns. >>> >>> board: rise/fall >>> >>> rk3399-roc-pc: 90ns/90ns >>> rk3399-rockpro64 V2.0: 90ns/45ns >>> rk3399-rockpro64 V2.1: 40ns/41ns I'm having to eyeball off a 20MHz analog scope (thank goodness for "yes" being able to generate a nice periodic signal), but for my NanoPC-T4 with a cheap eBay FT232R adapter both rise and fall times are certainly <100ns. FWIW I've not noticed any issues with letting the Bluetooth interface on UART0 run flat-out at 4Mbaud either. >>> >>> Please make sure there's not a large amount of flux or something >>> around the terminals on your board, that seems excessively high. >>> >> >> Thank you for valuable information. For more deeply discussion, >> I tried other conditions and watch the rise/fall times. >> >> 1) Not connect >> The rise/fall times are 40ns/5ns when nothing connect (impedance is >> very high) to external pin of RockPro64. >> >> What UART device are you using with RockPro64? If you use some device >> with RockPro64 and board shows rise/fall times = 90ns/45ns, my device >> is not suitable for RockPro64 by some reason. So it's better to drop >> my patch. > > The adapter is an FTDI FT232RL breakout board, attached with some > generic Dupont connector jumpers. > Interesting your RockPro is showing this symptom, perhaps there is a > cold solder joint somewhere introducing resistance? > >> >> 2) Other SoC >> I have other SoC board rk3328-rock64, Rock64 shows rise/fall times = >> 90ns/80ns when same UART-USB device is connected to UART pin. > > I measured similar on my Rock64 as well. > >> >> I think it shows rk3399's (or RockPro64's?) drive strength is a little >> weak. So it's better to increase the drive strength of UART of rk3399. > > I do not think this is a bad idea generally, it simply allows for more > available current from the interface. I'll let others be the judge of > that, however. There may be RK3399 users who would care about the possible EMI impact, so it's probably still best to limit such a change to boards which definitely need it. Robin. > >> >> Best Regards, >> Katsuhiro Suzuki >> >>>> >>>> Best Regards, >>>> Katsuhiro Suzuki >>>> >>>> >>>>> Thanks >>>>> Heiko >>>>> >>>>> >>>>> >>>>>> diff --git a/arch/arm64/boot/dts/rockchip/rk3399.dtsi b/arch/arm64/boot/dts/rockchip/rk3399.dtsi >>>>>> index beaa92744a64..e3c8f91ead50 100644 >>>>>> --- a/arch/arm64/boot/dts/rockchip/rk3399.dtsi >>>>>> +++ b/arch/arm64/boot/dts/rockchip/rk3399.dtsi >>>>>> @@ -2000,6 +2000,11 @@ >>>>>> drive-strength = <8>; >>>>>> }; >>>>>> >>>>>> + pcfg_pull_up_12ma: pcfg-pull-up-12ma { >>>>>> + bias-pull-up; >>>>>> + drive-strength = <12>; >>>>>> + }; >>>>>> + >>>>>> pcfg_pull_up_18ma: pcfg-pull-up-18ma { >>>>>> bias-pull-up; >>>>>> drive-strength = <18>; >>>>>> @@ -2521,8 +2526,8 @@ >>>>>> uart2c { >>>>>> uart2c_xfer: uart2c-xfer { >>>>>> rockchip,pins = >>>>>> - <4 RK_PC3 RK_FUNC_1 &pcfg_pull_up>, >>>>>> - <4 RK_PC4 RK_FUNC_1 &pcfg_pull_none>; >>>>>> + <4 RK_PC3 RK_FUNC_1 &pcfg_pull_up_12ma>, >>>>>> + <4 RK_PC4 RK_FUNC_1 &pcfg_pull_none_12ma>; >>>>>> }; >>>>>> }; >>>>>> >>>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>> >>>> >>>> _______________________________________________ >>>> Linux-rockchip mailing list >>>> Linux-rockchip@lists.infradead.org >>>> http://lists.infradead.org/mailman/listinfo/linux-rockchip >>> >>> >> ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [PATCH] arm64: dts: rockchip: decrease rising edge time of UART2 @ 2019-03-03 19:50 ` Robin Murphy 0 siblings, 0 replies; 43+ messages in thread From: Robin Murphy @ 2019-03-03 19:50 UTC (permalink / raw) To: Tony McKahan, Katsuhiro Suzuki Cc: Heiko Stuebner, Viresh Kumar, Linus Walleij, linux-kernel, Klaus Goger, Manivannan Sadhasivam, Brian Norris, linux-rockchip, Shawn Lin, Akash Gajjar, Vicente Bergas, Levin Du, Ezequiel Garcia, linux-arm-kernel, Shohei Maruyama, Matthias Brugger, Tomeu Vizoso, Dmitry Torokhov, Douglas Anderson, Jakob Unterwurzacher, Oskari Lemmela, Enric Balletbo i Serra, Christoph Muellner On 2019-03-03 6:45 pm, Tony McKahan wrote: > Hello Katsushiro, > > On Sun, Mar 3, 2019 at 12:31 PM Katsuhiro Suzuki > <katsuhiro@katsuster.net> wrote: >> >> Hello Tony, >> >> On 2019/03/04 0:13, Tony McKahan wrote: >>> On Sun, Mar 3, 2019 at 9:04 AM Katsuhiro Suzuki <katsuhiro@katsuster.net> wrote: >>>> >>>> Hello Heiko, >>>> >>>> Thank you for comments. >>>> >>>> On 2019/03/03 22:19, Heiko Stuebner wrote: >>>>> Hi, >>>>> >>>>> Am Sonntag, 3. März 2019, 13:27:05 CET schrieb Katsuhiro Suzuki: >>>>>> This patch increases drive strength of UART2 from 3mA to 12mA for >>>>>> getting more faster rising edge. >>>>>> >>>>>> RockPro64 is using a very high speed rate (1.5Mbps) for UART2. In >>>>>> this setting, a bit width of UART is about 667ns. >>>>>> >>>>>> In my environment (RockPro64 UART2 with FTDI FT232RL UART-USB >>>>>> converter), falling time of RockPro64 UART2 is 40ns, but riging time >>>>>> is over 650ns. So UART receiver will get wrong data, because receiver >>>>>> read intermediate data of rising edge. >>>>>> >>>>>> Rising time becomes 300ns from 650ns if apply this patch. This is not >>>>>> perfect solution but better than now. >>>>>> >>>>>> Signed-off-by: Katsuhiro Suzuki <katsuhiro@katsuster.net> >>>>>> --- >>>>>> arch/arm64/boot/dts/rockchip/rk3399.dtsi | 9 +++++++-- >>>>>> 1 file changed, 7 insertions(+), 2 deletions(-) >>>>> >>>>> your changing a core rk3399 property here, so I'd really like to get >>>>> input from other board stakeholders on this before applying a core >>>>> change. >>>>> >>>>> Could you either include the submitters of other rk3399-boards in the >>>>> recipient list so that they're aware or limit the change to rockpro64 for >>>>> the time being (aka overriding the property in the board-dts) please? >>>>> >>>> >>>> OK, I'm adding other boards members. >>>> by ./scripts/get_maintainer.pl arch/arm64/boot/dts/rockchip/rk3399-*.dts >>>> >>>> >>>> RockPro64 directly connect UART2 pins of RK3399 to external connector. >>>> I think maybe other RK3399 boards are facing same problem, but I cannot >>>> check it because I have RockPro64 only... >>>> >>>> I'm happy if someone tell me other boards situation. >>> >>> I'm pulling out other rockchip boards momentarily to see what kind of >>> population we have. >>> >>> Note these are not all running 5.x kernels, however none of them have >>> the UART2 drive levels modified to my knowledge, and regardless, none >>> show over 100 ns. >>> >>> board: rise/fall >>> >>> rk3399-roc-pc: 90ns/90ns >>> rk3399-rockpro64 V2.0: 90ns/45ns >>> rk3399-rockpro64 V2.1: 40ns/41ns I'm having to eyeball off a 20MHz analog scope (thank goodness for "yes" being able to generate a nice periodic signal), but for my NanoPC-T4 with a cheap eBay FT232R adapter both rise and fall times are certainly <100ns. FWIW I've not noticed any issues with letting the Bluetooth interface on UART0 run flat-out at 4Mbaud either. >>> >>> Please make sure there's not a large amount of flux or something >>> around the terminals on your board, that seems excessively high. >>> >> >> Thank you for valuable information. For more deeply discussion, >> I tried other conditions and watch the rise/fall times. >> >> 1) Not connect >> The rise/fall times are 40ns/5ns when nothing connect (impedance is >> very high) to external pin of RockPro64. >> >> What UART device are you using with RockPro64? If you use some device >> with RockPro64 and board shows rise/fall times = 90ns/45ns, my device >> is not suitable for RockPro64 by some reason. So it's better to drop >> my patch. > > The adapter is an FTDI FT232RL breakout board, attached with some > generic Dupont connector jumpers. > Interesting your RockPro is showing this symptom, perhaps there is a > cold solder joint somewhere introducing resistance? > >> >> 2) Other SoC >> I have other SoC board rk3328-rock64, Rock64 shows rise/fall times = >> 90ns/80ns when same UART-USB device is connected to UART pin. > > I measured similar on my Rock64 as well. > >> >> I think it shows rk3399's (or RockPro64's?) drive strength is a little >> weak. So it's better to increase the drive strength of UART of rk3399. > > I do not think this is a bad idea generally, it simply allows for more > available current from the interface. I'll let others be the judge of > that, however. There may be RK3399 users who would care about the possible EMI impact, so it's probably still best to limit such a change to boards which definitely need it. Robin. > >> >> Best Regards, >> Katsuhiro Suzuki >> >>>> >>>> Best Regards, >>>> Katsuhiro Suzuki >>>> >>>> >>>>> Thanks >>>>> Heiko >>>>> >>>>> >>>>> >>>>>> diff --git a/arch/arm64/boot/dts/rockchip/rk3399.dtsi b/arch/arm64/boot/dts/rockchip/rk3399.dtsi >>>>>> index beaa92744a64..e3c8f91ead50 100644 >>>>>> --- a/arch/arm64/boot/dts/rockchip/rk3399.dtsi >>>>>> +++ b/arch/arm64/boot/dts/rockchip/rk3399.dtsi >>>>>> @@ -2000,6 +2000,11 @@ >>>>>> drive-strength = <8>; >>>>>> }; >>>>>> >>>>>> + pcfg_pull_up_12ma: pcfg-pull-up-12ma { >>>>>> + bias-pull-up; >>>>>> + drive-strength = <12>; >>>>>> + }; >>>>>> + >>>>>> pcfg_pull_up_18ma: pcfg-pull-up-18ma { >>>>>> bias-pull-up; >>>>>> drive-strength = <18>; >>>>>> @@ -2521,8 +2526,8 @@ >>>>>> uart2c { >>>>>> uart2c_xfer: uart2c-xfer { >>>>>> rockchip,pins = >>>>>> - <4 RK_PC3 RK_FUNC_1 &pcfg_pull_up>, >>>>>> - <4 RK_PC4 RK_FUNC_1 &pcfg_pull_none>; >>>>>> + <4 RK_PC3 RK_FUNC_1 &pcfg_pull_up_12ma>, >>>>>> + <4 RK_PC4 RK_FUNC_1 &pcfg_pull_none_12ma>; >>>>>> }; >>>>>> }; >>>>>> >>>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>> >>>> >>>> _______________________________________________ >>>> Linux-rockchip mailing list >>>> Linux-rockchip@lists.infradead.org >>>> http://lists.infradead.org/mailman/listinfo/linux-rockchip >>> >>> >> _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [PATCH] arm64: dts: rockchip: decrease rising edge time of UART2 2019-03-03 19:50 ` Robin Murphy (?) @ 2019-03-03 20:41 ` Tony McKahan -1 siblings, 0 replies; 43+ messages in thread From: Tony McKahan @ 2019-03-03 20:41 UTC (permalink / raw) To: Robin Murphy Cc: Katsuhiro Suzuki, Heiko Stuebner, Akash Gajjar, Brian Norris, Christoph Muellner, Dmitry Torokhov, Douglas Anderson, Enric Balletbo i Serra, Ezequiel Garcia, Jakob Unterwurzacher, Klaus Goger, Levin Du, Linus Walleij, Manivannan Sadhasivam, Matthias Brugger, Oskari Lemmela, Shawn Lin On Sun, Mar 3, 2019 at 2:51 PM Robin Murphy <robin.murphy@arm.com> wrote: > > On 2019-03-03 6:45 pm, Tony McKahan wrote: > > Hello Katsushiro, > > > > On Sun, Mar 3, 2019 at 12:31 PM Katsuhiro Suzuki > > <katsuhiro@katsuster.net> wrote: > >> > >> Hello Tony, > >> > >> On 2019/03/04 0:13, Tony McKahan wrote: > >>> On Sun, Mar 3, 2019 at 9:04 AM Katsuhiro Suzuki <katsuhiro@katsuster.net> wrote: > >>>> > >>>> Hello Heiko, > >>>> > >>>> Thank you for comments. > >>>> > >>>> On 2019/03/03 22:19, Heiko Stuebner wrote: > >>>>> Hi, > >>>>> > >>>>> Am Sonntag, 3. März 2019, 13:27:05 CET schrieb Katsuhiro Suzuki: > >>>>>> This patch increases drive strength of UART2 from 3mA to 12mA for > >>>>>> getting more faster rising edge. > >>>>>> > >>>>>> RockPro64 is using a very high speed rate (1.5Mbps) for UART2. In > >>>>>> this setting, a bit width of UART is about 667ns. > >>>>>> > >>>>>> In my environment (RockPro64 UART2 with FTDI FT232RL UART-USB > >>>>>> converter), falling time of RockPro64 UART2 is 40ns, but riging time > >>>>>> is over 650ns. So UART receiver will get wrong data, because receiver > >>>>>> read intermediate data of rising edge. > >>>>>> > >>>>>> Rising time becomes 300ns from 650ns if apply this patch. This is not > >>>>>> perfect solution but better than now. > >>>>>> > >>>>>> Signed-off-by: Katsuhiro Suzuki <katsuhiro@katsuster.net> > >>>>>> --- > >>>>>> arch/arm64/boot/dts/rockchip/rk3399.dtsi | 9 +++++++-- > >>>>>> 1 file changed, 7 insertions(+), 2 deletions(-) > >>>>> > >>>>> your changing a core rk3399 property here, so I'd really like to get > >>>>> input from other board stakeholders on this before applying a core > >>>>> change. > >>>>> > >>>>> Could you either include the submitters of other rk3399-boards in the > >>>>> recipient list so that they're aware or limit the change to rockpro64 for > >>>>> the time being (aka overriding the property in the board-dts) please? > >>>>> > >>>> > >>>> OK, I'm adding other boards members. > >>>> by ./scripts/get_maintainer.pl arch/arm64/boot/dts/rockchip/rk3399-*.dts > >>>> > >>>> > >>>> RockPro64 directly connect UART2 pins of RK3399 to external connector. > >>>> I think maybe other RK3399 boards are facing same problem, but I cannot > >>>> check it because I have RockPro64 only... > >>>> > >>>> I'm happy if someone tell me other boards situation. > >>> > >>> I'm pulling out other rockchip boards momentarily to see what kind of > >>> population we have. > >>> > >>> Note these are not all running 5.x kernels, however none of them have > >>> the UART2 drive levels modified to my knowledge, and regardless, none > >>> show over 100 ns. > >>> > >>> board: rise/fall > >>> > >>> rk3399-roc-pc: 90ns/90ns > >>> rk3399-rockpro64 V2.0: 90ns/45ns > >>> rk3399-rockpro64 V2.1: 40ns/41ns > > I'm having to eyeball off a 20MHz analog scope (thank goodness for "yes" > being able to generate a nice periodic signal), but for my NanoPC-T4 > with a cheap eBay FT232R adapter both rise and fall times are certainly > <100ns. FWIW I've not noticed any issues with letting the Bluetooth > interface on UART0 run flat-out at 4Mbaud either. > > >>> > >>> Please make sure there's not a large amount of flux or something > >>> around the terminals on your board, that seems excessively high. > >>> > >> > >> Thank you for valuable information. For more deeply discussion, > >> I tried other conditions and watch the rise/fall times. > >> > >> 1) Not connect > >> The rise/fall times are 40ns/5ns when nothing connect (impedance is > >> very high) to external pin of RockPro64. > >> > >> What UART device are you using with RockPro64? If you use some device > >> with RockPro64 and board shows rise/fall times = 90ns/45ns, my device > >> is not suitable for RockPro64 by some reason. So it's better to drop > >> my patch. > > > > The adapter is an FTDI FT232RL breakout board, attached with some > > generic Dupont connector jumpers. > > Interesting your RockPro is showing this symptom, perhaps there is a > > cold solder joint somewhere introducing resistance? > > > >> > >> 2) Other SoC > >> I have other SoC board rk3328-rock64, Rock64 shows rise/fall times = > >> 90ns/80ns when same UART-USB device is connected to UART pin. > > > > I measured similar on my Rock64 as well. > > > >> > >> I think it shows rk3399's (or RockPro64's?) drive strength is a little > >> weak. So it's better to increase the drive strength of UART of rk3399. > > > > I do not think this is a bad idea generally, it simply allows for more > > available current from the interface. I'll let others be the judge of > > that, however. > > There may be RK3399 users who would care about the possible EMI impact, > so it's probably still best to limit such a change to boards which > definitely need it. > Ah, good point. As to speeds achievable, I've only run into drive level issues with SD/SDIO, but that's all the way up at 25-50 MHz. Tony > Robin. > > > > >> > >> Best Regards, > >> Katsuhiro Suzuki > >> > >>>> > >>>> Best Regards, > >>>> Katsuhiro Suzuki > >>>> > >>>> > >>>>> Thanks > >>>>> Heiko > >>>>> > >>>>> > >>>>> > >>>>>> diff --git a/arch/arm64/boot/dts/rockchip/rk3399.dtsi b/arch/arm64/boot/dts/rockchip/rk3399.dtsi > >>>>>> index beaa92744a64..e3c8f91ead50 100644 > >>>>>> --- a/arch/arm64/boot/dts/rockchip/rk3399.dtsi > >>>>>> +++ b/arch/arm64/boot/dts/rockchip/rk3399.dtsi > >>>>>> @@ -2000,6 +2000,11 @@ > >>>>>> drive-strength = <8>; > >>>>>> }; > >>>>>> > >>>>>> + pcfg_pull_up_12ma: pcfg-pull-up-12ma { > >>>>>> + bias-pull-up; > >>>>>> + drive-strength = <12>; > >>>>>> + }; > >>>>>> + > >>>>>> pcfg_pull_up_18ma: pcfg-pull-up-18ma { > >>>>>> bias-pull-up; > >>>>>> drive-strength = <18>; > >>>>>> @@ -2521,8 +2526,8 @@ > >>>>>> uart2c { > >>>>>> uart2c_xfer: uart2c-xfer { > >>>>>> rockchip,pins = > >>>>>> - <4 RK_PC3 RK_FUNC_1 &pcfg_pull_up>, > >>>>>> - <4 RK_PC4 RK_FUNC_1 &pcfg_pull_none>; > >>>>>> + <4 RK_PC3 RK_FUNC_1 &pcfg_pull_up_12ma>, > >>>>>> + <4 RK_PC4 RK_FUNC_1 &pcfg_pull_none_12ma>; > >>>>>> }; > >>>>>> }; > >>>>>> > >>>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>> > >>>> > >>>> _______________________________________________ > >>>> Linux-rockchip mailing list > >>>> Linux-rockchip@lists.infradead.org > >>>> http://lists.infradead.org/mailman/listinfo/linux-rockchip > >>> > >>> > >> ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [PATCH] arm64: dts: rockchip: decrease rising edge time of UART2 @ 2019-03-03 20:41 ` Tony McKahan 0 siblings, 0 replies; 43+ messages in thread From: Tony McKahan @ 2019-03-03 20:41 UTC (permalink / raw) To: Robin Murphy Cc: Katsuhiro Suzuki, Heiko Stuebner, Akash Gajjar, Brian Norris, Christoph Muellner, Dmitry Torokhov, Douglas Anderson, Enric Balletbo i Serra, Ezequiel Garcia, Jakob Unterwurzacher, Klaus Goger, Levin Du, Linus Walleij, Manivannan Sadhasivam, Matthias Brugger, Oskari Lemmela, Shawn Lin, Shohei Maruyama, Tomeu Vizoso, Vicente Bergas, Viresh Kumar, linux-rockchip, linux-kernel, linux-arm-kernel On Sun, Mar 3, 2019 at 2:51 PM Robin Murphy <robin.murphy@arm.com> wrote: > > On 2019-03-03 6:45 pm, Tony McKahan wrote: > > Hello Katsushiro, > > > > On Sun, Mar 3, 2019 at 12:31 PM Katsuhiro Suzuki > > <katsuhiro@katsuster.net> wrote: > >> > >> Hello Tony, > >> > >> On 2019/03/04 0:13, Tony McKahan wrote: > >>> On Sun, Mar 3, 2019 at 9:04 AM Katsuhiro Suzuki <katsuhiro@katsuster.net> wrote: > >>>> > >>>> Hello Heiko, > >>>> > >>>> Thank you for comments. > >>>> > >>>> On 2019/03/03 22:19, Heiko Stuebner wrote: > >>>>> Hi, > >>>>> > >>>>> Am Sonntag, 3. März 2019, 13:27:05 CET schrieb Katsuhiro Suzuki: > >>>>>> This patch increases drive strength of UART2 from 3mA to 12mA for > >>>>>> getting more faster rising edge. > >>>>>> > >>>>>> RockPro64 is using a very high speed rate (1.5Mbps) for UART2. In > >>>>>> this setting, a bit width of UART is about 667ns. > >>>>>> > >>>>>> In my environment (RockPro64 UART2 with FTDI FT232RL UART-USB > >>>>>> converter), falling time of RockPro64 UART2 is 40ns, but riging time > >>>>>> is over 650ns. So UART receiver will get wrong data, because receiver > >>>>>> read intermediate data of rising edge. > >>>>>> > >>>>>> Rising time becomes 300ns from 650ns if apply this patch. This is not > >>>>>> perfect solution but better than now. > >>>>>> > >>>>>> Signed-off-by: Katsuhiro Suzuki <katsuhiro@katsuster.net> > >>>>>> --- > >>>>>> arch/arm64/boot/dts/rockchip/rk3399.dtsi | 9 +++++++-- > >>>>>> 1 file changed, 7 insertions(+), 2 deletions(-) > >>>>> > >>>>> your changing a core rk3399 property here, so I'd really like to get > >>>>> input from other board stakeholders on this before applying a core > >>>>> change. > >>>>> > >>>>> Could you either include the submitters of other rk3399-boards in the > >>>>> recipient list so that they're aware or limit the change to rockpro64 for > >>>>> the time being (aka overriding the property in the board-dts) please? > >>>>> > >>>> > >>>> OK, I'm adding other boards members. > >>>> by ./scripts/get_maintainer.pl arch/arm64/boot/dts/rockchip/rk3399-*.dts > >>>> > >>>> > >>>> RockPro64 directly connect UART2 pins of RK3399 to external connector. > >>>> I think maybe other RK3399 boards are facing same problem, but I cannot > >>>> check it because I have RockPro64 only... > >>>> > >>>> I'm happy if someone tell me other boards situation. > >>> > >>> I'm pulling out other rockchip boards momentarily to see what kind of > >>> population we have. > >>> > >>> Note these are not all running 5.x kernels, however none of them have > >>> the UART2 drive levels modified to my knowledge, and regardless, none > >>> show over 100 ns. > >>> > >>> board: rise/fall > >>> > >>> rk3399-roc-pc: 90ns/90ns > >>> rk3399-rockpro64 V2.0: 90ns/45ns > >>> rk3399-rockpro64 V2.1: 40ns/41ns > > I'm having to eyeball off a 20MHz analog scope (thank goodness for "yes" > being able to generate a nice periodic signal), but for my NanoPC-T4 > with a cheap eBay FT232R adapter both rise and fall times are certainly > <100ns. FWIW I've not noticed any issues with letting the Bluetooth > interface on UART0 run flat-out at 4Mbaud either. > > >>> > >>> Please make sure there's not a large amount of flux or something > >>> around the terminals on your board, that seems excessively high. > >>> > >> > >> Thank you for valuable information. For more deeply discussion, > >> I tried other conditions and watch the rise/fall times. > >> > >> 1) Not connect > >> The rise/fall times are 40ns/5ns when nothing connect (impedance is > >> very high) to external pin of RockPro64. > >> > >> What UART device are you using with RockPro64? If you use some device > >> with RockPro64 and board shows rise/fall times = 90ns/45ns, my device > >> is not suitable for RockPro64 by some reason. So it's better to drop > >> my patch. > > > > The adapter is an FTDI FT232RL breakout board, attached with some > > generic Dupont connector jumpers. > > Interesting your RockPro is showing this symptom, perhaps there is a > > cold solder joint somewhere introducing resistance? > > > >> > >> 2) Other SoC > >> I have other SoC board rk3328-rock64, Rock64 shows rise/fall times = > >> 90ns/80ns when same UART-USB device is connected to UART pin. > > > > I measured similar on my Rock64 as well. > > > >> > >> I think it shows rk3399's (or RockPro64's?) drive strength is a little > >> weak. So it's better to increase the drive strength of UART of rk3399. > > > > I do not think this is a bad idea generally, it simply allows for more > > available current from the interface. I'll let others be the judge of > > that, however. > > There may be RK3399 users who would care about the possible EMI impact, > so it's probably still best to limit such a change to boards which > definitely need it. > Ah, good point. As to speeds achievable, I've only run into drive level issues with SD/SDIO, but that's all the way up at 25-50 MHz. Tony > Robin. > > > > >> > >> Best Regards, > >> Katsuhiro Suzuki > >> > >>>> > >>>> Best Regards, > >>>> Katsuhiro Suzuki > >>>> > >>>> > >>>>> Thanks > >>>>> Heiko > >>>>> > >>>>> > >>>>> > >>>>>> diff --git a/arch/arm64/boot/dts/rockchip/rk3399.dtsi b/arch/arm64/boot/dts/rockchip/rk3399.dtsi > >>>>>> index beaa92744a64..e3c8f91ead50 100644 > >>>>>> --- a/arch/arm64/boot/dts/rockchip/rk3399.dtsi > >>>>>> +++ b/arch/arm64/boot/dts/rockchip/rk3399.dtsi > >>>>>> @@ -2000,6 +2000,11 @@ > >>>>>> drive-strength = <8>; > >>>>>> }; > >>>>>> > >>>>>> + pcfg_pull_up_12ma: pcfg-pull-up-12ma { > >>>>>> + bias-pull-up; > >>>>>> + drive-strength = <12>; > >>>>>> + }; > >>>>>> + > >>>>>> pcfg_pull_up_18ma: pcfg-pull-up-18ma { > >>>>>> bias-pull-up; > >>>>>> drive-strength = <18>; > >>>>>> @@ -2521,8 +2526,8 @@ > >>>>>> uart2c { > >>>>>> uart2c_xfer: uart2c-xfer { > >>>>>> rockchip,pins = > >>>>>> - <4 RK_PC3 RK_FUNC_1 &pcfg_pull_up>, > >>>>>> - <4 RK_PC4 RK_FUNC_1 &pcfg_pull_none>; > >>>>>> + <4 RK_PC3 RK_FUNC_1 &pcfg_pull_up_12ma>, > >>>>>> + <4 RK_PC4 RK_FUNC_1 &pcfg_pull_none_12ma>; > >>>>>> }; > >>>>>> }; > >>>>>> > >>>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>> > >>>> > >>>> _______________________________________________ > >>>> Linux-rockchip mailing list > >>>> Linux-rockchip@lists.infradead.org > >>>> http://lists.infradead.org/mailman/listinfo/linux-rockchip > >>> > >>> > >> ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [PATCH] arm64: dts: rockchip: decrease rising edge time of UART2 @ 2019-03-03 20:41 ` Tony McKahan 0 siblings, 0 replies; 43+ messages in thread From: Tony McKahan @ 2019-03-03 20:41 UTC (permalink / raw) To: Robin Murphy Cc: Heiko Stuebner, Viresh Kumar, Linus Walleij, linux-kernel, Klaus Goger, Manivannan Sadhasivam, Katsuhiro Suzuki, Brian Norris, linux-rockchip, Shawn Lin, Akash Gajjar, Vicente Bergas, Levin Du, Ezequiel Garcia, linux-arm-kernel, Shohei Maruyama, Matthias Brugger, Tomeu Vizoso, Dmitry Torokhov, Douglas Anderson, Jakob Unterwurzacher, Oskari Lemmela, Enric Balletbo i Serra, Christoph Muellner On Sun, Mar 3, 2019 at 2:51 PM Robin Murphy <robin.murphy@arm.com> wrote: > > On 2019-03-03 6:45 pm, Tony McKahan wrote: > > Hello Katsushiro, > > > > On Sun, Mar 3, 2019 at 12:31 PM Katsuhiro Suzuki > > <katsuhiro@katsuster.net> wrote: > >> > >> Hello Tony, > >> > >> On 2019/03/04 0:13, Tony McKahan wrote: > >>> On Sun, Mar 3, 2019 at 9:04 AM Katsuhiro Suzuki <katsuhiro@katsuster.net> wrote: > >>>> > >>>> Hello Heiko, > >>>> > >>>> Thank you for comments. > >>>> > >>>> On 2019/03/03 22:19, Heiko Stuebner wrote: > >>>>> Hi, > >>>>> > >>>>> Am Sonntag, 3. März 2019, 13:27:05 CET schrieb Katsuhiro Suzuki: > >>>>>> This patch increases drive strength of UART2 from 3mA to 12mA for > >>>>>> getting more faster rising edge. > >>>>>> > >>>>>> RockPro64 is using a very high speed rate (1.5Mbps) for UART2. In > >>>>>> this setting, a bit width of UART is about 667ns. > >>>>>> > >>>>>> In my environment (RockPro64 UART2 with FTDI FT232RL UART-USB > >>>>>> converter), falling time of RockPro64 UART2 is 40ns, but riging time > >>>>>> is over 650ns. So UART receiver will get wrong data, because receiver > >>>>>> read intermediate data of rising edge. > >>>>>> > >>>>>> Rising time becomes 300ns from 650ns if apply this patch. This is not > >>>>>> perfect solution but better than now. > >>>>>> > >>>>>> Signed-off-by: Katsuhiro Suzuki <katsuhiro@katsuster.net> > >>>>>> --- > >>>>>> arch/arm64/boot/dts/rockchip/rk3399.dtsi | 9 +++++++-- > >>>>>> 1 file changed, 7 insertions(+), 2 deletions(-) > >>>>> > >>>>> your changing a core rk3399 property here, so I'd really like to get > >>>>> input from other board stakeholders on this before applying a core > >>>>> change. > >>>>> > >>>>> Could you either include the submitters of other rk3399-boards in the > >>>>> recipient list so that they're aware or limit the change to rockpro64 for > >>>>> the time being (aka overriding the property in the board-dts) please? > >>>>> > >>>> > >>>> OK, I'm adding other boards members. > >>>> by ./scripts/get_maintainer.pl arch/arm64/boot/dts/rockchip/rk3399-*.dts > >>>> > >>>> > >>>> RockPro64 directly connect UART2 pins of RK3399 to external connector. > >>>> I think maybe other RK3399 boards are facing same problem, but I cannot > >>>> check it because I have RockPro64 only... > >>>> > >>>> I'm happy if someone tell me other boards situation. > >>> > >>> I'm pulling out other rockchip boards momentarily to see what kind of > >>> population we have. > >>> > >>> Note these are not all running 5.x kernels, however none of them have > >>> the UART2 drive levels modified to my knowledge, and regardless, none > >>> show over 100 ns. > >>> > >>> board: rise/fall > >>> > >>> rk3399-roc-pc: 90ns/90ns > >>> rk3399-rockpro64 V2.0: 90ns/45ns > >>> rk3399-rockpro64 V2.1: 40ns/41ns > > I'm having to eyeball off a 20MHz analog scope (thank goodness for "yes" > being able to generate a nice periodic signal), but for my NanoPC-T4 > with a cheap eBay FT232R adapter both rise and fall times are certainly > <100ns. FWIW I've not noticed any issues with letting the Bluetooth > interface on UART0 run flat-out at 4Mbaud either. > > >>> > >>> Please make sure there's not a large amount of flux or something > >>> around the terminals on your board, that seems excessively high. > >>> > >> > >> Thank you for valuable information. For more deeply discussion, > >> I tried other conditions and watch the rise/fall times. > >> > >> 1) Not connect > >> The rise/fall times are 40ns/5ns when nothing connect (impedance is > >> very high) to external pin of RockPro64. > >> > >> What UART device are you using with RockPro64? If you use some device > >> with RockPro64 and board shows rise/fall times = 90ns/45ns, my device > >> is not suitable for RockPro64 by some reason. So it's better to drop > >> my patch. > > > > The adapter is an FTDI FT232RL breakout board, attached with some > > generic Dupont connector jumpers. > > Interesting your RockPro is showing this symptom, perhaps there is a > > cold solder joint somewhere introducing resistance? > > > >> > >> 2) Other SoC > >> I have other SoC board rk3328-rock64, Rock64 shows rise/fall times = > >> 90ns/80ns when same UART-USB device is connected to UART pin. > > > > I measured similar on my Rock64 as well. > > > >> > >> I think it shows rk3399's (or RockPro64's?) drive strength is a little > >> weak. So it's better to increase the drive strength of UART of rk3399. > > > > I do not think this is a bad idea generally, it simply allows for more > > available current from the interface. I'll let others be the judge of > > that, however. > > There may be RK3399 users who would care about the possible EMI impact, > so it's probably still best to limit such a change to boards which > definitely need it. > Ah, good point. As to speeds achievable, I've only run into drive level issues with SD/SDIO, but that's all the way up at 25-50 MHz. Tony > Robin. > > > > >> > >> Best Regards, > >> Katsuhiro Suzuki > >> > >>>> > >>>> Best Regards, > >>>> Katsuhiro Suzuki > >>>> > >>>> > >>>>> Thanks > >>>>> Heiko > >>>>> > >>>>> > >>>>> > >>>>>> diff --git a/arch/arm64/boot/dts/rockchip/rk3399.dtsi b/arch/arm64/boot/dts/rockchip/rk3399.dtsi > >>>>>> index beaa92744a64..e3c8f91ead50 100644 > >>>>>> --- a/arch/arm64/boot/dts/rockchip/rk3399.dtsi > >>>>>> +++ b/arch/arm64/boot/dts/rockchip/rk3399.dtsi > >>>>>> @@ -2000,6 +2000,11 @@ > >>>>>> drive-strength = <8>; > >>>>>> }; > >>>>>> > >>>>>> + pcfg_pull_up_12ma: pcfg-pull-up-12ma { > >>>>>> + bias-pull-up; > >>>>>> + drive-strength = <12>; > >>>>>> + }; > >>>>>> + > >>>>>> pcfg_pull_up_18ma: pcfg-pull-up-18ma { > >>>>>> bias-pull-up; > >>>>>> drive-strength = <18>; > >>>>>> @@ -2521,8 +2526,8 @@ > >>>>>> uart2c { > >>>>>> uart2c_xfer: uart2c-xfer { > >>>>>> rockchip,pins = > >>>>>> - <4 RK_PC3 RK_FUNC_1 &pcfg_pull_up>, > >>>>>> - <4 RK_PC4 RK_FUNC_1 &pcfg_pull_none>; > >>>>>> + <4 RK_PC3 RK_FUNC_1 &pcfg_pull_up_12ma>, > >>>>>> + <4 RK_PC4 RK_FUNC_1 &pcfg_pull_none_12ma>; > >>>>>> }; > >>>>>> }; > >>>>>> > >>>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>> > >>>> > >>>> _______________________________________________ > >>>> Linux-rockchip mailing list > >>>> Linux-rockchip@lists.infradead.org > >>>> http://lists.infradead.org/mailman/listinfo/linux-rockchip > >>> > >>> > >> _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [PATCH] arm64: dts: rockchip: decrease rising edge time of UART2 2019-03-03 20:41 ` Tony McKahan (?) @ 2019-03-04 13:59 ` Katsuhiro Suzuki -1 siblings, 0 replies; 43+ messages in thread From: Katsuhiro Suzuki @ 2019-03-04 13:59 UTC (permalink / raw) To: Tony McKahan, Robin Murphy Cc: Heiko Stuebner, Viresh Kumar, Linus Walleij, linux-kernel, Klaus Goger, Manivannan Sadhasivam, Brian Norris, linux-rockchip, Shawn Lin, Akash Gajjar, Vicente Bergas, Levin Du, Ezequiel Garcia, linux-arm-kernel, Shohei Maruyama, Matthias Brugger, Tomeu Vizoso, Dmitry Torokhov, Douglas Anderson <dianders> Hello Tony, Robin, On 2019/03/04 5:41, Tony McKahan wrote: > On Sun, Mar 3, 2019 at 2:51 PM Robin Murphy <robin.murphy@arm.com> wrote: >> >> On 2019-03-03 6:45 pm, Tony McKahan wrote: >>> Hello Katsushiro, >>> >>> On Sun, Mar 3, 2019 at 12:31 PM Katsuhiro Suzuki >>> <katsuhiro@katsuster.net> wrote: >>>> >>>> Hello Tony, >>>> >>>> On 2019/03/04 0:13, Tony McKahan wrote: >>>>> On Sun, Mar 3, 2019 at 9:04 AM Katsuhiro Suzuki <katsuhiro@katsuster.net> wrote: >>>>>> >>>>>> Hello Heiko, >>>>>> >>>>>> Thank you for comments. >>>>>> >>>>>> On 2019/03/03 22:19, Heiko Stuebner wrote: >>>>>>> Hi, >>>>>>> >>>>>>> Am Sonntag, 3. März 2019, 13:27:05 CET schrieb Katsuhiro Suzuki: >>>>>>>> This patch increases drive strength of UART2 from 3mA to 12mA for >>>>>>>> getting more faster rising edge. >>>>>>>> >>>>>>>> RockPro64 is using a very high speed rate (1.5Mbps) for UART2. In >>>>>>>> this setting, a bit width of UART is about 667ns. >>>>>>>> >>>>>>>> In my environment (RockPro64 UART2 with FTDI FT232RL UART-USB >>>>>>>> converter), falling time of RockPro64 UART2 is 40ns, but riging time >>>>>>>> is over 650ns. So UART receiver will get wrong data, because receiver >>>>>>>> read intermediate data of rising edge. >>>>>>>> >>>>>>>> Rising time becomes 300ns from 650ns if apply this patch. This is not >>>>>>>> perfect solution but better than now. >>>>>>>> >>>>>>>> Signed-off-by: Katsuhiro Suzuki <katsuhiro@katsuster.net> >>>>>>>> --- >>>>>>>> arch/arm64/boot/dts/rockchip/rk3399.dtsi | 9 +++++++-- >>>>>>>> 1 file changed, 7 insertions(+), 2 deletions(-) >>>>>>> >>>>>>> your changing a core rk3399 property here, so I'd really like to get >>>>>>> input from other board stakeholders on this before applying a core >>>>>>> change. >>>>>>> >>>>>>> Could you either include the submitters of other rk3399-boards in the >>>>>>> recipient list so that they're aware or limit the change to rockpro64 for >>>>>>> the time being (aka overriding the property in the board-dts) please? >>>>>>> >>>>>> >>>>>> OK, I'm adding other boards members. >>>>>> by ./scripts/get_maintainer.pl arch/arm64/boot/dts/rockchip/rk3399-*.dts >>>>>> >>>>>> >>>>>> RockPro64 directly connect UART2 pins of RK3399 to external connector. >>>>>> I think maybe other RK3399 boards are facing same problem, but I cannot >>>>>> check it because I have RockPro64 only... >>>>>> >>>>>> I'm happy if someone tell me other boards situation. >>>>> >>>>> I'm pulling out other rockchip boards momentarily to see what kind of >>>>> population we have. >>>>> >>>>> Note these are not all running 5.x kernels, however none of them have >>>>> the UART2 drive levels modified to my knowledge, and regardless, none >>>>> show over 100 ns. >>>>> >>>>> board: rise/fall >>>>> >>>>> rk3399-roc-pc: 90ns/90ns >>>>> rk3399-rockpro64 V2.0: 90ns/45ns >>>>> rk3399-rockpro64 V2.1: 40ns/41ns >> >> I'm having to eyeball off a 20MHz analog scope (thank goodness for "yes" >> being able to generate a nice periodic signal), but for my NanoPC-T4 >> with a cheap eBay FT232R adapter both rise and fall times are certainly >> <100ns. FWIW I've not noticed any issues with letting the Bluetooth >> interface on UART0 run flat-out at 4Mbaud either. >> Robin, Thanks a lot. Your results show that cold solder (or some electric parts on board) of my RockPro64 is broken or something wrong. >>>>> >>>>> Please make sure there's not a large amount of flux or something >>>>> around the terminals on your board, that seems excessively high. >>>>> >>>> >>>> Thank you for valuable information. For more deeply discussion, >>>> I tried other conditions and watch the rise/fall times. >>>> >>>> 1) Not connect >>>> The rise/fall times are 40ns/5ns when nothing connect (impedance is >>>> very high) to external pin of RockPro64. >>>> >>>> What UART device are you using with RockPro64? If you use some device >>>> with RockPro64 and board shows rise/fall times = 90ns/45ns, my device >>>> is not suitable for RockPro64 by some reason. So it's better to drop >>>> my patch. >>> >>> The adapter is an FTDI FT232RL breakout board, attached with some >>> generic Dupont connector jumpers. >>> Interesting your RockPro is showing this symptom, perhaps there is a >>> cold solder joint somewhere introducing resistance? >>> >>>> >>>> 2) Other SoC >>>> I have other SoC board rk3328-rock64, Rock64 shows rise/fall times = >>>> 90ns/80ns when same UART-USB device is connected to UART pin. >>> >>> I measured similar on my Rock64 as well. >>> Tony, thanks for your info about environment. It seems my RockPro64 problem. I don't have enough electronic knowledge, but try to check my RockPro64 as much as I can. >>>> >>>> I think it shows rk3399's (or RockPro64's?) drive strength is a little >>>> weak. So it's better to increase the drive strength of UART of rk3399. >>> >>> I do not think this is a bad idea generally, it simply allows for more >>> available current from the interface. I'll let others be the judge of >>> that, however. >> >> There may be RK3399 users who would care about the possible EMI impact, >> so it's probably still best to limit such a change to boards which >> definitely need it. >> > > Ah, good point. > > As to speeds achievable, I've only run into drive level issues with > SD/SDIO, but that's all the way up at 25-50 MHz. My patch has bad effects for EMI issues of all RK3399 boards. So conclusion is, my patch should be dropped. Sorry for confusing. Best Regards, Katsuhiro Suzuki > > Tony > >> Robin. >> >>> >>>> >>>> Best Regards, >>>> Katsuhiro Suzuki >>>> >>>>>> >>>>>> Best Regards, >>>>>> Katsuhiro Suzuki >>>>>> >>>>>> >>>>>>> Thanks >>>>>>> Heiko >>>>>>> >>>>>>> >>>>>>> >>>>>>>> diff --git a/arch/arm64/boot/dts/rockchip/rk3399.dtsi b/arch/arm64/boot/dts/rockchip/rk3399.dtsi >>>>>>>> index beaa92744a64..e3c8f91ead50 100644 >>>>>>>> --- a/arch/arm64/boot/dts/rockchip/rk3399.dtsi >>>>>>>> +++ b/arch/arm64/boot/dts/rockchip/rk3399.dtsi >>>>>>>> @@ -2000,6 +2000,11 @@ >>>>>>>> drive-strength = <8>; >>>>>>>> }; >>>>>>>> >>>>>>>> + pcfg_pull_up_12ma: pcfg-pull-up-12ma { >>>>>>>> + bias-pull-up; >>>>>>>> + drive-strength = <12>; >>>>>>>> + }; >>>>>>>> + >>>>>>>> pcfg_pull_up_18ma: pcfg-pull-up-18ma { >>>>>>>> bias-pull-up; >>>>>>>> drive-strength = <18>; >>>>>>>> @@ -2521,8 +2526,8 @@ >>>>>>>> uart2c { >>>>>>>> uart2c_xfer: uart2c-xfer { >>>>>>>> rockchip,pins = >>>>>>>> - <4 RK_PC3 RK_FUNC_1 &pcfg_pull_up>, >>>>>>>> - <4 RK_PC4 RK_FUNC_1 &pcfg_pull_none>; >>>>>>>> + <4 RK_PC3 RK_FUNC_1 &pcfg_pull_up_12ma>, >>>>>>>> + <4 RK_PC4 RK_FUNC_1 &pcfg_pull_none_12ma>; >>>>>>>> }; >>>>>>>> }; >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Linux-rockchip mailing list >>>>>> Linux-rockchip@lists.infradead.org >>>>>> http://lists.infradead.org/mailman/listinfo/linux-rockchip >>>>> >>>>> >>>> > > _______________________________________________ > Linux-rockchip mailing list > Linux-rockchip@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-rockchip > > ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [PATCH] arm64: dts: rockchip: decrease rising edge time of UART2 @ 2019-03-04 13:59 ` Katsuhiro Suzuki 0 siblings, 0 replies; 43+ messages in thread From: Katsuhiro Suzuki @ 2019-03-04 13:59 UTC (permalink / raw) To: Tony McKahan, Robin Murphy Cc: Heiko Stuebner, Viresh Kumar, Linus Walleij, linux-kernel, Klaus Goger, Manivannan Sadhasivam, Brian Norris, linux-rockchip, Shawn Lin, Akash Gajjar, Vicente Bergas, Levin Du, Ezequiel Garcia, linux-arm-kernel, Shohei Maruyama, Matthias Brugger, Tomeu Vizoso, Dmitry Torokhov, Douglas Anderson, Jakob Unterwurzacher, Oskari Lemmela, Enric Balletbo i Serra, Christoph Muellner Hello Tony, Robin, On 2019/03/04 5:41, Tony McKahan wrote: > On Sun, Mar 3, 2019 at 2:51 PM Robin Murphy <robin.murphy@arm.com> wrote: >> >> On 2019-03-03 6:45 pm, Tony McKahan wrote: >>> Hello Katsushiro, >>> >>> On Sun, Mar 3, 2019 at 12:31 PM Katsuhiro Suzuki >>> <katsuhiro@katsuster.net> wrote: >>>> >>>> Hello Tony, >>>> >>>> On 2019/03/04 0:13, Tony McKahan wrote: >>>>> On Sun, Mar 3, 2019 at 9:04 AM Katsuhiro Suzuki <katsuhiro@katsuster.net> wrote: >>>>>> >>>>>> Hello Heiko, >>>>>> >>>>>> Thank you for comments. >>>>>> >>>>>> On 2019/03/03 22:19, Heiko Stuebner wrote: >>>>>>> Hi, >>>>>>> >>>>>>> Am Sonntag, 3. März 2019, 13:27:05 CET schrieb Katsuhiro Suzuki: >>>>>>>> This patch increases drive strength of UART2 from 3mA to 12mA for >>>>>>>> getting more faster rising edge. >>>>>>>> >>>>>>>> RockPro64 is using a very high speed rate (1.5Mbps) for UART2. In >>>>>>>> this setting, a bit width of UART is about 667ns. >>>>>>>> >>>>>>>> In my environment (RockPro64 UART2 with FTDI FT232RL UART-USB >>>>>>>> converter), falling time of RockPro64 UART2 is 40ns, but riging time >>>>>>>> is over 650ns. So UART receiver will get wrong data, because receiver >>>>>>>> read intermediate data of rising edge. >>>>>>>> >>>>>>>> Rising time becomes 300ns from 650ns if apply this patch. This is not >>>>>>>> perfect solution but better than now. >>>>>>>> >>>>>>>> Signed-off-by: Katsuhiro Suzuki <katsuhiro@katsuster.net> >>>>>>>> --- >>>>>>>> arch/arm64/boot/dts/rockchip/rk3399.dtsi | 9 +++++++-- >>>>>>>> 1 file changed, 7 insertions(+), 2 deletions(-) >>>>>>> >>>>>>> your changing a core rk3399 property here, so I'd really like to get >>>>>>> input from other board stakeholders on this before applying a core >>>>>>> change. >>>>>>> >>>>>>> Could you either include the submitters of other rk3399-boards in the >>>>>>> recipient list so that they're aware or limit the change to rockpro64 for >>>>>>> the time being (aka overriding the property in the board-dts) please? >>>>>>> >>>>>> >>>>>> OK, I'm adding other boards members. >>>>>> by ./scripts/get_maintainer.pl arch/arm64/boot/dts/rockchip/rk3399-*.dts >>>>>> >>>>>> >>>>>> RockPro64 directly connect UART2 pins of RK3399 to external connector. >>>>>> I think maybe other RK3399 boards are facing same problem, but I cannot >>>>>> check it because I have RockPro64 only... >>>>>> >>>>>> I'm happy if someone tell me other boards situation. >>>>> >>>>> I'm pulling out other rockchip boards momentarily to see what kind of >>>>> population we have. >>>>> >>>>> Note these are not all running 5.x kernels, however none of them have >>>>> the UART2 drive levels modified to my knowledge, and regardless, none >>>>> show over 100 ns. >>>>> >>>>> board: rise/fall >>>>> >>>>> rk3399-roc-pc: 90ns/90ns >>>>> rk3399-rockpro64 V2.0: 90ns/45ns >>>>> rk3399-rockpro64 V2.1: 40ns/41ns >> >> I'm having to eyeball off a 20MHz analog scope (thank goodness for "yes" >> being able to generate a nice periodic signal), but for my NanoPC-T4 >> with a cheap eBay FT232R adapter both rise and fall times are certainly >> <100ns. FWIW I've not noticed any issues with letting the Bluetooth >> interface on UART0 run flat-out at 4Mbaud either. >> Robin, Thanks a lot. Your results show that cold solder (or some electric parts on board) of my RockPro64 is broken or something wrong. >>>>> >>>>> Please make sure there's not a large amount of flux or something >>>>> around the terminals on your board, that seems excessively high. >>>>> >>>> >>>> Thank you for valuable information. For more deeply discussion, >>>> I tried other conditions and watch the rise/fall times. >>>> >>>> 1) Not connect >>>> The rise/fall times are 40ns/5ns when nothing connect (impedance is >>>> very high) to external pin of RockPro64. >>>> >>>> What UART device are you using with RockPro64? If you use some device >>>> with RockPro64 and board shows rise/fall times = 90ns/45ns, my device >>>> is not suitable for RockPro64 by some reason. So it's better to drop >>>> my patch. >>> >>> The adapter is an FTDI FT232RL breakout board, attached with some >>> generic Dupont connector jumpers. >>> Interesting your RockPro is showing this symptom, perhaps there is a >>> cold solder joint somewhere introducing resistance? >>> >>>> >>>> 2) Other SoC >>>> I have other SoC board rk3328-rock64, Rock64 shows rise/fall times = >>>> 90ns/80ns when same UART-USB device is connected to UART pin. >>> >>> I measured similar on my Rock64 as well. >>> Tony, thanks for your info about environment. It seems my RockPro64 problem. I don't have enough electronic knowledge, but try to check my RockPro64 as much as I can. >>>> >>>> I think it shows rk3399's (or RockPro64's?) drive strength is a little >>>> weak. So it's better to increase the drive strength of UART of rk3399. >>> >>> I do not think this is a bad idea generally, it simply allows for more >>> available current from the interface. I'll let others be the judge of >>> that, however. >> >> There may be RK3399 users who would care about the possible EMI impact, >> so it's probably still best to limit such a change to boards which >> definitely need it. >> > > Ah, good point. > > As to speeds achievable, I've only run into drive level issues with > SD/SDIO, but that's all the way up at 25-50 MHz. My patch has bad effects for EMI issues of all RK3399 boards. So conclusion is, my patch should be dropped. Sorry for confusing. Best Regards, Katsuhiro Suzuki > > Tony > >> Robin. >> >>> >>>> >>>> Best Regards, >>>> Katsuhiro Suzuki >>>> >>>>>> >>>>>> Best Regards, >>>>>> Katsuhiro Suzuki >>>>>> >>>>>> >>>>>>> Thanks >>>>>>> Heiko >>>>>>> >>>>>>> >>>>>>> >>>>>>>> diff --git a/arch/arm64/boot/dts/rockchip/rk3399.dtsi b/arch/arm64/boot/dts/rockchip/rk3399.dtsi >>>>>>>> index beaa92744a64..e3c8f91ead50 100644 >>>>>>>> --- a/arch/arm64/boot/dts/rockchip/rk3399.dtsi >>>>>>>> +++ b/arch/arm64/boot/dts/rockchip/rk3399.dtsi >>>>>>>> @@ -2000,6 +2000,11 @@ >>>>>>>> drive-strength = <8>; >>>>>>>> }; >>>>>>>> >>>>>>>> + pcfg_pull_up_12ma: pcfg-pull-up-12ma { >>>>>>>> + bias-pull-up; >>>>>>>> + drive-strength = <12>; >>>>>>>> + }; >>>>>>>> + >>>>>>>> pcfg_pull_up_18ma: pcfg-pull-up-18ma { >>>>>>>> bias-pull-up; >>>>>>>> drive-strength = <18>; >>>>>>>> @@ -2521,8 +2526,8 @@ >>>>>>>> uart2c { >>>>>>>> uart2c_xfer: uart2c-xfer { >>>>>>>> rockchip,pins = >>>>>>>> - <4 RK_PC3 RK_FUNC_1 &pcfg_pull_up>, >>>>>>>> - <4 RK_PC4 RK_FUNC_1 &pcfg_pull_none>; >>>>>>>> + <4 RK_PC3 RK_FUNC_1 &pcfg_pull_up_12ma>, >>>>>>>> + <4 RK_PC4 RK_FUNC_1 &pcfg_pull_none_12ma>; >>>>>>>> }; >>>>>>>> }; >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Linux-rockchip mailing list >>>>>> Linux-rockchip@lists.infradead.org >>>>>> http://lists.infradead.org/mailman/listinfo/linux-rockchip >>>>> >>>>> >>>> > > _______________________________________________ > Linux-rockchip mailing list > Linux-rockchip@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-rockchip > > ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [PATCH] arm64: dts: rockchip: decrease rising edge time of UART2 @ 2019-03-04 13:59 ` Katsuhiro Suzuki 0 siblings, 0 replies; 43+ messages in thread From: Katsuhiro Suzuki @ 2019-03-04 13:59 UTC (permalink / raw) To: Tony McKahan, Robin Murphy Cc: Heiko Stuebner, Viresh Kumar, Linus Walleij, Douglas Anderson, Klaus Goger, Manivannan Sadhasivam, Brian Norris, linux-rockchip, Shawn Lin, Jakob Unterwurzacher, Akash Gajjar, Vicente Bergas, Levin Du, Ezequiel Garcia, linux-arm-kernel, Shohei Maruyama, Matthias Brugger, Tomeu Vizoso, Dmitry Torokhov, linux-kernel, Oskari Lemmela, Enric Balletbo i Serra, Christoph Muellner Hello Tony, Robin, On 2019/03/04 5:41, Tony McKahan wrote: > On Sun, Mar 3, 2019 at 2:51 PM Robin Murphy <robin.murphy@arm.com> wrote: >> >> On 2019-03-03 6:45 pm, Tony McKahan wrote: >>> Hello Katsushiro, >>> >>> On Sun, Mar 3, 2019 at 12:31 PM Katsuhiro Suzuki >>> <katsuhiro@katsuster.net> wrote: >>>> >>>> Hello Tony, >>>> >>>> On 2019/03/04 0:13, Tony McKahan wrote: >>>>> On Sun, Mar 3, 2019 at 9:04 AM Katsuhiro Suzuki <katsuhiro@katsuster.net> wrote: >>>>>> >>>>>> Hello Heiko, >>>>>> >>>>>> Thank you for comments. >>>>>> >>>>>> On 2019/03/03 22:19, Heiko Stuebner wrote: >>>>>>> Hi, >>>>>>> >>>>>>> Am Sonntag, 3. März 2019, 13:27:05 CET schrieb Katsuhiro Suzuki: >>>>>>>> This patch increases drive strength of UART2 from 3mA to 12mA for >>>>>>>> getting more faster rising edge. >>>>>>>> >>>>>>>> RockPro64 is using a very high speed rate (1.5Mbps) for UART2. In >>>>>>>> this setting, a bit width of UART is about 667ns. >>>>>>>> >>>>>>>> In my environment (RockPro64 UART2 with FTDI FT232RL UART-USB >>>>>>>> converter), falling time of RockPro64 UART2 is 40ns, but riging time >>>>>>>> is over 650ns. So UART receiver will get wrong data, because receiver >>>>>>>> read intermediate data of rising edge. >>>>>>>> >>>>>>>> Rising time becomes 300ns from 650ns if apply this patch. This is not >>>>>>>> perfect solution but better than now. >>>>>>>> >>>>>>>> Signed-off-by: Katsuhiro Suzuki <katsuhiro@katsuster.net> >>>>>>>> --- >>>>>>>> arch/arm64/boot/dts/rockchip/rk3399.dtsi | 9 +++++++-- >>>>>>>> 1 file changed, 7 insertions(+), 2 deletions(-) >>>>>>> >>>>>>> your changing a core rk3399 property here, so I'd really like to get >>>>>>> input from other board stakeholders on this before applying a core >>>>>>> change. >>>>>>> >>>>>>> Could you either include the submitters of other rk3399-boards in the >>>>>>> recipient list so that they're aware or limit the change to rockpro64 for >>>>>>> the time being (aka overriding the property in the board-dts) please? >>>>>>> >>>>>> >>>>>> OK, I'm adding other boards members. >>>>>> by ./scripts/get_maintainer.pl arch/arm64/boot/dts/rockchip/rk3399-*.dts >>>>>> >>>>>> >>>>>> RockPro64 directly connect UART2 pins of RK3399 to external connector. >>>>>> I think maybe other RK3399 boards are facing same problem, but I cannot >>>>>> check it because I have RockPro64 only... >>>>>> >>>>>> I'm happy if someone tell me other boards situation. >>>>> >>>>> I'm pulling out other rockchip boards momentarily to see what kind of >>>>> population we have. >>>>> >>>>> Note these are not all running 5.x kernels, however none of them have >>>>> the UART2 drive levels modified to my knowledge, and regardless, none >>>>> show over 100 ns. >>>>> >>>>> board: rise/fall >>>>> >>>>> rk3399-roc-pc: 90ns/90ns >>>>> rk3399-rockpro64 V2.0: 90ns/45ns >>>>> rk3399-rockpro64 V2.1: 40ns/41ns >> >> I'm having to eyeball off a 20MHz analog scope (thank goodness for "yes" >> being able to generate a nice periodic signal), but for my NanoPC-T4 >> with a cheap eBay FT232R adapter both rise and fall times are certainly >> <100ns. FWIW I've not noticed any issues with letting the Bluetooth >> interface on UART0 run flat-out at 4Mbaud either. >> Robin, Thanks a lot. Your results show that cold solder (or some electric parts on board) of my RockPro64 is broken or something wrong. >>>>> >>>>> Please make sure there's not a large amount of flux or something >>>>> around the terminals on your board, that seems excessively high. >>>>> >>>> >>>> Thank you for valuable information. For more deeply discussion, >>>> I tried other conditions and watch the rise/fall times. >>>> >>>> 1) Not connect >>>> The rise/fall times are 40ns/5ns when nothing connect (impedance is >>>> very high) to external pin of RockPro64. >>>> >>>> What UART device are you using with RockPro64? If you use some device >>>> with RockPro64 and board shows rise/fall times = 90ns/45ns, my device >>>> is not suitable for RockPro64 by some reason. So it's better to drop >>>> my patch. >>> >>> The adapter is an FTDI FT232RL breakout board, attached with some >>> generic Dupont connector jumpers. >>> Interesting your RockPro is showing this symptom, perhaps there is a >>> cold solder joint somewhere introducing resistance? >>> >>>> >>>> 2) Other SoC >>>> I have other SoC board rk3328-rock64, Rock64 shows rise/fall times = >>>> 90ns/80ns when same UART-USB device is connected to UART pin. >>> >>> I measured similar on my Rock64 as well. >>> Tony, thanks for your info about environment. It seems my RockPro64 problem. I don't have enough electronic knowledge, but try to check my RockPro64 as much as I can. >>>> >>>> I think it shows rk3399's (or RockPro64's?) drive strength is a little >>>> weak. So it's better to increase the drive strength of UART of rk3399. >>> >>> I do not think this is a bad idea generally, it simply allows for more >>> available current from the interface. I'll let others be the judge of >>> that, however. >> >> There may be RK3399 users who would care about the possible EMI impact, >> so it's probably still best to limit such a change to boards which >> definitely need it. >> > > Ah, good point. > > As to speeds achievable, I've only run into drive level issues with > SD/SDIO, but that's all the way up at 25-50 MHz. My patch has bad effects for EMI issues of all RK3399 boards. So conclusion is, my patch should be dropped. Sorry for confusing. Best Regards, Katsuhiro Suzuki > > Tony > >> Robin. >> >>> >>>> >>>> Best Regards, >>>> Katsuhiro Suzuki >>>> >>>>>> >>>>>> Best Regards, >>>>>> Katsuhiro Suzuki >>>>>> >>>>>> >>>>>>> Thanks >>>>>>> Heiko >>>>>>> >>>>>>> >>>>>>> >>>>>>>> diff --git a/arch/arm64/boot/dts/rockchip/rk3399.dtsi b/arch/arm64/boot/dts/rockchip/rk3399.dtsi >>>>>>>> index beaa92744a64..e3c8f91ead50 100644 >>>>>>>> --- a/arch/arm64/boot/dts/rockchip/rk3399.dtsi >>>>>>>> +++ b/arch/arm64/boot/dts/rockchip/rk3399.dtsi >>>>>>>> @@ -2000,6 +2000,11 @@ >>>>>>>> drive-strength = <8>; >>>>>>>> }; >>>>>>>> >>>>>>>> + pcfg_pull_up_12ma: pcfg-pull-up-12ma { >>>>>>>> + bias-pull-up; >>>>>>>> + drive-strength = <12>; >>>>>>>> + }; >>>>>>>> + >>>>>>>> pcfg_pull_up_18ma: pcfg-pull-up-18ma { >>>>>>>> bias-pull-up; >>>>>>>> drive-strength = <18>; >>>>>>>> @@ -2521,8 +2526,8 @@ >>>>>>>> uart2c { >>>>>>>> uart2c_xfer: uart2c-xfer { >>>>>>>> rockchip,pins = >>>>>>>> - <4 RK_PC3 RK_FUNC_1 &pcfg_pull_up>, >>>>>>>> - <4 RK_PC4 RK_FUNC_1 &pcfg_pull_none>; >>>>>>>> + <4 RK_PC3 RK_FUNC_1 &pcfg_pull_up_12ma>, >>>>>>>> + <4 RK_PC4 RK_FUNC_1 &pcfg_pull_none_12ma>; >>>>>>>> }; >>>>>>>> }; >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Linux-rockchip mailing list >>>>>> Linux-rockchip@lists.infradead.org >>>>>> http://lists.infradead.org/mailman/listinfo/linux-rockchip >>>>> >>>>> >>>> > > _______________________________________________ > Linux-rockchip mailing list > Linux-rockchip@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-rockchip > > _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [PATCH] arm64: dts: rockchip: decrease rising edge time of UART2 2019-03-04 13:59 ` Katsuhiro Suzuki (?) @ 2019-03-26 13:39 ` Katsuhiro Suzuki -1 siblings, 0 replies; 43+ messages in thread From: Katsuhiro Suzuki @ 2019-03-26 13:39 UTC (permalink / raw) To: Tony McKahan, Robin Murphy Cc: Heiko Stuebner, Viresh Kumar, Linus Walleij, linux-kernel, Klaus Goger, Manivannan Sadhasivam, Brian Norris, linux-rockchip, Shawn Lin, Akash Gajjar, Vicente Bergas, Levin Du, Ezequiel Garcia, linux-arm-kernel, Shohei Maruyama, Matthias Brugger, Tomeu Vizoso, Dmitry Torokhov, Douglas Anderson <dianders> Hello Tony, Robin, I continue to investigate UART TX rising time problem. Recently, I found one of cause of this problem. In my environment, this problem occurred on linux-next only. U-Boot does not face it. So I compared settings between U-Boot and linux-next. After I found GRF_IO_VSEL (address 0xff77e640) register is differ. Would you tell me what value is stored into this register? My RockPro64, initially 0x00000000 is set but 0x00000003 is set during linux boot. UART TX rising time becomes fine if set both bit 1 and bit 3 or clear both bits. Best Regards, On 2019/03/04 22:59, Katsuhiro Suzuki wrote: > Hello Tony, Robin, > > On 2019/03/04 5:41, Tony McKahan wrote: >> On Sun, Mar 3, 2019 at 2:51 PM Robin Murphy <robin.murphy@arm.com> wrote: >>> >>> On 2019-03-03 6:45 pm, Tony McKahan wrote: >>>> Hello Katsushiro, >>>> >>>> On Sun, Mar 3, 2019 at 12:31 PM Katsuhiro Suzuki >>>> <katsuhiro@katsuster.net> wrote: >>>>> >>>>> Hello Tony, >>>>> >>>>> On 2019/03/04 0:13, Tony McKahan wrote: >>>>>> On Sun, Mar 3, 2019 at 9:04 AM Katsuhiro Suzuki >>>>>> <katsuhiro@katsuster.net> wrote: >>>>>>> >>>>>>> Hello Heiko, >>>>>>> >>>>>>> Thank you for comments. >>>>>>> >>>>>>> On 2019/03/03 22:19, Heiko Stuebner wrote: >>>>>>>> Hi, >>>>>>>> >>>>>>>> Am Sonntag, 3. März 2019, 13:27:05 CET schrieb Katsuhiro Suzuki: >>>>>>>>> This patch increases drive strength of UART2 from 3mA to 12mA for >>>>>>>>> getting more faster rising edge. >>>>>>>>> >>>>>>>>> RockPro64 is using a very high speed rate (1.5Mbps) for UART2. In >>>>>>>>> this setting, a bit width of UART is about 667ns. >>>>>>>>> >>>>>>>>> In my environment (RockPro64 UART2 with FTDI FT232RL UART-USB >>>>>>>>> converter), falling time of RockPro64 UART2 is 40ns, but riging >>>>>>>>> time >>>>>>>>> is over 650ns. So UART receiver will get wrong data, because >>>>>>>>> receiver >>>>>>>>> read intermediate data of rising edge. >>>>>>>>> >>>>>>>>> Rising time becomes 300ns from 650ns if apply this patch. This >>>>>>>>> is not >>>>>>>>> perfect solution but better than now. >>>>>>>>> >>>>>>>>> Signed-off-by: Katsuhiro Suzuki <katsuhiro@katsuster.net> >>>>>>>>> --- >>>>>>>>> arch/arm64/boot/dts/rockchip/rk3399.dtsi | 9 +++++++-- >>>>>>>>> 1 file changed, 7 insertions(+), 2 deletions(-) >>>>>>>> >>>>>>>> your changing a core rk3399 property here, so I'd really like to >>>>>>>> get >>>>>>>> input from other board stakeholders on this before applying a core >>>>>>>> change. >>>>>>>> >>>>>>>> Could you either include the submitters of other rk3399-boards >>>>>>>> in the >>>>>>>> recipient list so that they're aware or limit the change to >>>>>>>> rockpro64 for >>>>>>>> the time being (aka overriding the property in the board-dts) >>>>>>>> please? >>>>>>>> >>>>>>> >>>>>>> OK, I'm adding other boards members. >>>>>>> by ./scripts/get_maintainer.pl >>>>>>> arch/arm64/boot/dts/rockchip/rk3399-*.dts >>>>>>> >>>>>>> >>>>>>> RockPro64 directly connect UART2 pins of RK3399 to external >>>>>>> connector. >>>>>>> I think maybe other RK3399 boards are facing same problem, but I >>>>>>> cannot >>>>>>> check it because I have RockPro64 only... >>>>>>> >>>>>>> I'm happy if someone tell me other boards situation. >>>>>> >>>>>> I'm pulling out other rockchip boards momentarily to see what kind of >>>>>> population we have. >>>>>> >>>>>> Note these are not all running 5.x kernels, however none of them have >>>>>> the UART2 drive levels modified to my knowledge, and regardless, none >>>>>> show over 100 ns. >>>>>> >>>>>> board: rise/fall >>>>>> >>>>>> rk3399-roc-pc: 90ns/90ns >>>>>> rk3399-rockpro64 V2.0: 90ns/45ns >>>>>> rk3399-rockpro64 V2.1: 40ns/41ns >>> >>> I'm having to eyeball off a 20MHz analog scope (thank goodness for "yes" >>> being able to generate a nice periodic signal), but for my NanoPC-T4 >>> with a cheap eBay FT232R adapter both rise and fall times are certainly >>> <100ns. FWIW I've not noticed any issues with letting the Bluetooth >>> interface on UART0 run flat-out at 4Mbaud either. >>> > > Robin, Thanks a lot. Your results show that cold solder (or some > electric parts on board) of my RockPro64 is broken or something wrong. > > >>>>>> >>>>>> Please make sure there's not a large amount of flux or something >>>>>> around the terminals on your board, that seems excessively high. >>>>>> >>>>> >>>>> Thank you for valuable information. For more deeply discussion, >>>>> I tried other conditions and watch the rise/fall times. >>>>> >>>>> 1) Not connect >>>>> The rise/fall times are 40ns/5ns when nothing connect (impedance is >>>>> very high) to external pin of RockPro64. >>>>> >>>>> What UART device are you using with RockPro64? If you use some device >>>>> with RockPro64 and board shows rise/fall times = 90ns/45ns, my device >>>>> is not suitable for RockPro64 by some reason. So it's better to drop >>>>> my patch. >>>> >>>> The adapter is an FTDI FT232RL breakout board, attached with some >>>> generic Dupont connector jumpers. >>>> Interesting your RockPro is showing this symptom, perhaps there is a >>>> cold solder joint somewhere introducing resistance? >>>> >>>>> >>>>> 2) Other SoC >>>>> I have other SoC board rk3328-rock64, Rock64 shows rise/fall times = >>>>> 90ns/80ns when same UART-USB device is connected to UART pin. >>>> >>>> I measured similar on my Rock64 as well. >>>> > > Tony, thanks for your info about environment. > > It seems my RockPro64 problem. I don't have enough electronic knowledge, > but try to check my RockPro64 as much as I can. > > >>>>> >>>>> I think it shows rk3399's (or RockPro64's?) drive strength is a little >>>>> weak. So it's better to increase the drive strength of UART of rk3399. >>>> >>>> I do not think this is a bad idea generally, it simply allows for more >>>> available current from the interface. I'll let others be the judge of >>>> that, however. >>> >>> There may be RK3399 users who would care about the possible EMI impact, >>> so it's probably still best to limit such a change to boards which >>> definitely need it. >>> >> >> Ah, good point. >> >> As to speeds achievable, I've only run into drive level issues with >> SD/SDIO, but that's all the way up at 25-50 MHz. > > My patch has bad effects for EMI issues of all RK3399 boards. > > So conclusion is, my patch should be dropped. Sorry for confusing. > > Best Regards, > Katsuhiro Suzuki > > >> >> Tony >> >>> Robin. >>> >>>> >>>>> >>>>> Best Regards, >>>>> Katsuhiro Suzuki >>>>> >>>>>>> >>>>>>> Best Regards, >>>>>>> Katsuhiro Suzuki >>>>>>> >>>>>>> >>>>>>>> Thanks >>>>>>>> Heiko >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> diff --git a/arch/arm64/boot/dts/rockchip/rk3399.dtsi >>>>>>>>> b/arch/arm64/boot/dts/rockchip/rk3399.dtsi >>>>>>>>> index beaa92744a64..e3c8f91ead50 100644 >>>>>>>>> --- a/arch/arm64/boot/dts/rockchip/rk3399.dtsi >>>>>>>>> +++ b/arch/arm64/boot/dts/rockchip/rk3399.dtsi >>>>>>>>> @@ -2000,6 +2000,11 @@ >>>>>>>>> drive-strength = <8>; >>>>>>>>> }; >>>>>>>>> >>>>>>>>> + pcfg_pull_up_12ma: pcfg-pull-up-12ma { >>>>>>>>> + bias-pull-up; >>>>>>>>> + drive-strength = <12>; >>>>>>>>> + }; >>>>>>>>> + >>>>>>>>> pcfg_pull_up_18ma: pcfg-pull-up-18ma { >>>>>>>>> bias-pull-up; >>>>>>>>> drive-strength = <18>; >>>>>>>>> @@ -2521,8 +2526,8 @@ >>>>>>>>> uart2c { >>>>>>>>> uart2c_xfer: uart2c-xfer { >>>>>>>>> rockchip,pins = >>>>>>>>> - <4 RK_PC3 RK_FUNC_1 >>>>>>>>> &pcfg_pull_up>, >>>>>>>>> - <4 RK_PC4 RK_FUNC_1 >>>>>>>>> &pcfg_pull_none>; >>>>>>>>> + <4 RK_PC3 RK_FUNC_1 >>>>>>>>> &pcfg_pull_up_12ma>, >>>>>>>>> + <4 RK_PC4 RK_FUNC_1 >>>>>>>>> &pcfg_pull_none_12ma>; >>>>>>>>> }; >>>>>>>>> }; >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Linux-rockchip mailing list >>>>>>> Linux-rockchip@lists.infradead.org >>>>>>> http://lists.infradead.org/mailman/listinfo/linux-rockchip >>>>>> >>>>>> >>>>> >> >> _______________________________________________ >> Linux-rockchip mailing list >> Linux-rockchip@lists.infradead.org >> http://lists.infradead.org/mailman/listinfo/linux-rockchip >> >> > > ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [PATCH] arm64: dts: rockchip: decrease rising edge time of UART2 @ 2019-03-26 13:39 ` Katsuhiro Suzuki 0 siblings, 0 replies; 43+ messages in thread From: Katsuhiro Suzuki @ 2019-03-26 13:39 UTC (permalink / raw) To: Tony McKahan, Robin Murphy Cc: Heiko Stuebner, Viresh Kumar, Linus Walleij, linux-kernel, Klaus Goger, Manivannan Sadhasivam, Brian Norris, linux-rockchip, Shawn Lin, Akash Gajjar, Vicente Bergas, Levin Du, Ezequiel Garcia, linux-arm-kernel, Shohei Maruyama, Matthias Brugger, Tomeu Vizoso, Dmitry Torokhov, Douglas Anderson, Jakob Unterwurzacher, Oskari Lemmela, Enric Balletbo i Serra, Christoph Muellner Hello Tony, Robin, I continue to investigate UART TX rising time problem. Recently, I found one of cause of this problem. In my environment, this problem occurred on linux-next only. U-Boot does not face it. So I compared settings between U-Boot and linux-next. After I found GRF_IO_VSEL (address 0xff77e640) register is differ. Would you tell me what value is stored into this register? My RockPro64, initially 0x00000000 is set but 0x00000003 is set during linux boot. UART TX rising time becomes fine if set both bit 1 and bit 3 or clear both bits. Best Regards, On 2019/03/04 22:59, Katsuhiro Suzuki wrote: > Hello Tony, Robin, > > On 2019/03/04 5:41, Tony McKahan wrote: >> On Sun, Mar 3, 2019 at 2:51 PM Robin Murphy <robin.murphy@arm.com> wrote: >>> >>> On 2019-03-03 6:45 pm, Tony McKahan wrote: >>>> Hello Katsushiro, >>>> >>>> On Sun, Mar 3, 2019 at 12:31 PM Katsuhiro Suzuki >>>> <katsuhiro@katsuster.net> wrote: >>>>> >>>>> Hello Tony, >>>>> >>>>> On 2019/03/04 0:13, Tony McKahan wrote: >>>>>> On Sun, Mar 3, 2019 at 9:04 AM Katsuhiro Suzuki >>>>>> <katsuhiro@katsuster.net> wrote: >>>>>>> >>>>>>> Hello Heiko, >>>>>>> >>>>>>> Thank you for comments. >>>>>>> >>>>>>> On 2019/03/03 22:19, Heiko Stuebner wrote: >>>>>>>> Hi, >>>>>>>> >>>>>>>> Am Sonntag, 3. März 2019, 13:27:05 CET schrieb Katsuhiro Suzuki: >>>>>>>>> This patch increases drive strength of UART2 from 3mA to 12mA for >>>>>>>>> getting more faster rising edge. >>>>>>>>> >>>>>>>>> RockPro64 is using a very high speed rate (1.5Mbps) for UART2. In >>>>>>>>> this setting, a bit width of UART is about 667ns. >>>>>>>>> >>>>>>>>> In my environment (RockPro64 UART2 with FTDI FT232RL UART-USB >>>>>>>>> converter), falling time of RockPro64 UART2 is 40ns, but riging >>>>>>>>> time >>>>>>>>> is over 650ns. So UART receiver will get wrong data, because >>>>>>>>> receiver >>>>>>>>> read intermediate data of rising edge. >>>>>>>>> >>>>>>>>> Rising time becomes 300ns from 650ns if apply this patch. This >>>>>>>>> is not >>>>>>>>> perfect solution but better than now. >>>>>>>>> >>>>>>>>> Signed-off-by: Katsuhiro Suzuki <katsuhiro@katsuster.net> >>>>>>>>> --- >>>>>>>>> arch/arm64/boot/dts/rockchip/rk3399.dtsi | 9 +++++++-- >>>>>>>>> 1 file changed, 7 insertions(+), 2 deletions(-) >>>>>>>> >>>>>>>> your changing a core rk3399 property here, so I'd really like to >>>>>>>> get >>>>>>>> input from other board stakeholders on this before applying a core >>>>>>>> change. >>>>>>>> >>>>>>>> Could you either include the submitters of other rk3399-boards >>>>>>>> in the >>>>>>>> recipient list so that they're aware or limit the change to >>>>>>>> rockpro64 for >>>>>>>> the time being (aka overriding the property in the board-dts) >>>>>>>> please? >>>>>>>> >>>>>>> >>>>>>> OK, I'm adding other boards members. >>>>>>> by ./scripts/get_maintainer.pl >>>>>>> arch/arm64/boot/dts/rockchip/rk3399-*.dts >>>>>>> >>>>>>> >>>>>>> RockPro64 directly connect UART2 pins of RK3399 to external >>>>>>> connector. >>>>>>> I think maybe other RK3399 boards are facing same problem, but I >>>>>>> cannot >>>>>>> check it because I have RockPro64 only... >>>>>>> >>>>>>> I'm happy if someone tell me other boards situation. >>>>>> >>>>>> I'm pulling out other rockchip boards momentarily to see what kind of >>>>>> population we have. >>>>>> >>>>>> Note these are not all running 5.x kernels, however none of them have >>>>>> the UART2 drive levels modified to my knowledge, and regardless, none >>>>>> show over 100 ns. >>>>>> >>>>>> board: rise/fall >>>>>> >>>>>> rk3399-roc-pc: 90ns/90ns >>>>>> rk3399-rockpro64 V2.0: 90ns/45ns >>>>>> rk3399-rockpro64 V2.1: 40ns/41ns >>> >>> I'm having to eyeball off a 20MHz analog scope (thank goodness for "yes" >>> being able to generate a nice periodic signal), but for my NanoPC-T4 >>> with a cheap eBay FT232R adapter both rise and fall times are certainly >>> <100ns. FWIW I've not noticed any issues with letting the Bluetooth >>> interface on UART0 run flat-out at 4Mbaud either. >>> > > Robin, Thanks a lot. Your results show that cold solder (or some > electric parts on board) of my RockPro64 is broken or something wrong. > > >>>>>> >>>>>> Please make sure there's not a large amount of flux or something >>>>>> around the terminals on your board, that seems excessively high. >>>>>> >>>>> >>>>> Thank you for valuable information. For more deeply discussion, >>>>> I tried other conditions and watch the rise/fall times. >>>>> >>>>> 1) Not connect >>>>> The rise/fall times are 40ns/5ns when nothing connect (impedance is >>>>> very high) to external pin of RockPro64. >>>>> >>>>> What UART device are you using with RockPro64? If you use some device >>>>> with RockPro64 and board shows rise/fall times = 90ns/45ns, my device >>>>> is not suitable for RockPro64 by some reason. So it's better to drop >>>>> my patch. >>>> >>>> The adapter is an FTDI FT232RL breakout board, attached with some >>>> generic Dupont connector jumpers. >>>> Interesting your RockPro is showing this symptom, perhaps there is a >>>> cold solder joint somewhere introducing resistance? >>>> >>>>> >>>>> 2) Other SoC >>>>> I have other SoC board rk3328-rock64, Rock64 shows rise/fall times = >>>>> 90ns/80ns when same UART-USB device is connected to UART pin. >>>> >>>> I measured similar on my Rock64 as well. >>>> > > Tony, thanks for your info about environment. > > It seems my RockPro64 problem. I don't have enough electronic knowledge, > but try to check my RockPro64 as much as I can. > > >>>>> >>>>> I think it shows rk3399's (or RockPro64's?) drive strength is a little >>>>> weak. So it's better to increase the drive strength of UART of rk3399. >>>> >>>> I do not think this is a bad idea generally, it simply allows for more >>>> available current from the interface. I'll let others be the judge of >>>> that, however. >>> >>> There may be RK3399 users who would care about the possible EMI impact, >>> so it's probably still best to limit such a change to boards which >>> definitely need it. >>> >> >> Ah, good point. >> >> As to speeds achievable, I've only run into drive level issues with >> SD/SDIO, but that's all the way up at 25-50 MHz. > > My patch has bad effects for EMI issues of all RK3399 boards. > > So conclusion is, my patch should be dropped. Sorry for confusing. > > Best Regards, > Katsuhiro Suzuki > > >> >> Tony >> >>> Robin. >>> >>>> >>>>> >>>>> Best Regards, >>>>> Katsuhiro Suzuki >>>>> >>>>>>> >>>>>>> Best Regards, >>>>>>> Katsuhiro Suzuki >>>>>>> >>>>>>> >>>>>>>> Thanks >>>>>>>> Heiko >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> diff --git a/arch/arm64/boot/dts/rockchip/rk3399.dtsi >>>>>>>>> b/arch/arm64/boot/dts/rockchip/rk3399.dtsi >>>>>>>>> index beaa92744a64..e3c8f91ead50 100644 >>>>>>>>> --- a/arch/arm64/boot/dts/rockchip/rk3399.dtsi >>>>>>>>> +++ b/arch/arm64/boot/dts/rockchip/rk3399.dtsi >>>>>>>>> @@ -2000,6 +2000,11 @@ >>>>>>>>> drive-strength = <8>; >>>>>>>>> }; >>>>>>>>> >>>>>>>>> + pcfg_pull_up_12ma: pcfg-pull-up-12ma { >>>>>>>>> + bias-pull-up; >>>>>>>>> + drive-strength = <12>; >>>>>>>>> + }; >>>>>>>>> + >>>>>>>>> pcfg_pull_up_18ma: pcfg-pull-up-18ma { >>>>>>>>> bias-pull-up; >>>>>>>>> drive-strength = <18>; >>>>>>>>> @@ -2521,8 +2526,8 @@ >>>>>>>>> uart2c { >>>>>>>>> uart2c_xfer: uart2c-xfer { >>>>>>>>> rockchip,pins = >>>>>>>>> - <4 RK_PC3 RK_FUNC_1 >>>>>>>>> &pcfg_pull_up>, >>>>>>>>> - <4 RK_PC4 RK_FUNC_1 >>>>>>>>> &pcfg_pull_none>; >>>>>>>>> + <4 RK_PC3 RK_FUNC_1 >>>>>>>>> &pcfg_pull_up_12ma>, >>>>>>>>> + <4 RK_PC4 RK_FUNC_1 >>>>>>>>> &pcfg_pull_none_12ma>; >>>>>>>>> }; >>>>>>>>> }; >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Linux-rockchip mailing list >>>>>>> Linux-rockchip@lists.infradead.org >>>>>>> http://lists.infradead.org/mailman/listinfo/linux-rockchip >>>>>> >>>>>> >>>>> >> >> _______________________________________________ >> Linux-rockchip mailing list >> Linux-rockchip@lists.infradead.org >> http://lists.infradead.org/mailman/listinfo/linux-rockchip >> >> > > ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [PATCH] arm64: dts: rockchip: decrease rising edge time of UART2 @ 2019-03-26 13:39 ` Katsuhiro Suzuki 0 siblings, 0 replies; 43+ messages in thread From: Katsuhiro Suzuki @ 2019-03-26 13:39 UTC (permalink / raw) To: Tony McKahan, Robin Murphy Cc: Heiko Stuebner, Viresh Kumar, Linus Walleij, Douglas Anderson, Klaus Goger, Manivannan Sadhasivam, Brian Norris, linux-rockchip, Shawn Lin, Jakob Unterwurzacher, Akash Gajjar, Vicente Bergas, Levin Du, Ezequiel Garcia, linux-arm-kernel, Shohei Maruyama, Matthias Brugger, Tomeu Vizoso, Dmitry Torokhov, linux-kernel, Oskari Lemmela, Enric Balletbo i Serra, Christoph Muellner Hello Tony, Robin, I continue to investigate UART TX rising time problem. Recently, I found one of cause of this problem. In my environment, this problem occurred on linux-next only. U-Boot does not face it. So I compared settings between U-Boot and linux-next. After I found GRF_IO_VSEL (address 0xff77e640) register is differ. Would you tell me what value is stored into this register? My RockPro64, initially 0x00000000 is set but 0x00000003 is set during linux boot. UART TX rising time becomes fine if set both bit 1 and bit 3 or clear both bits. Best Regards, On 2019/03/04 22:59, Katsuhiro Suzuki wrote: > Hello Tony, Robin, > > On 2019/03/04 5:41, Tony McKahan wrote: >> On Sun, Mar 3, 2019 at 2:51 PM Robin Murphy <robin.murphy@arm.com> wrote: >>> >>> On 2019-03-03 6:45 pm, Tony McKahan wrote: >>>> Hello Katsushiro, >>>> >>>> On Sun, Mar 3, 2019 at 12:31 PM Katsuhiro Suzuki >>>> <katsuhiro@katsuster.net> wrote: >>>>> >>>>> Hello Tony, >>>>> >>>>> On 2019/03/04 0:13, Tony McKahan wrote: >>>>>> On Sun, Mar 3, 2019 at 9:04 AM Katsuhiro Suzuki >>>>>> <katsuhiro@katsuster.net> wrote: >>>>>>> >>>>>>> Hello Heiko, >>>>>>> >>>>>>> Thank you for comments. >>>>>>> >>>>>>> On 2019/03/03 22:19, Heiko Stuebner wrote: >>>>>>>> Hi, >>>>>>>> >>>>>>>> Am Sonntag, 3. März 2019, 13:27:05 CET schrieb Katsuhiro Suzuki: >>>>>>>>> This patch increases drive strength of UART2 from 3mA to 12mA for >>>>>>>>> getting more faster rising edge. >>>>>>>>> >>>>>>>>> RockPro64 is using a very high speed rate (1.5Mbps) for UART2. In >>>>>>>>> this setting, a bit width of UART is about 667ns. >>>>>>>>> >>>>>>>>> In my environment (RockPro64 UART2 with FTDI FT232RL UART-USB >>>>>>>>> converter), falling time of RockPro64 UART2 is 40ns, but riging >>>>>>>>> time >>>>>>>>> is over 650ns. So UART receiver will get wrong data, because >>>>>>>>> receiver >>>>>>>>> read intermediate data of rising edge. >>>>>>>>> >>>>>>>>> Rising time becomes 300ns from 650ns if apply this patch. This >>>>>>>>> is not >>>>>>>>> perfect solution but better than now. >>>>>>>>> >>>>>>>>> Signed-off-by: Katsuhiro Suzuki <katsuhiro@katsuster.net> >>>>>>>>> --- >>>>>>>>> arch/arm64/boot/dts/rockchip/rk3399.dtsi | 9 +++++++-- >>>>>>>>> 1 file changed, 7 insertions(+), 2 deletions(-) >>>>>>>> >>>>>>>> your changing a core rk3399 property here, so I'd really like to >>>>>>>> get >>>>>>>> input from other board stakeholders on this before applying a core >>>>>>>> change. >>>>>>>> >>>>>>>> Could you either include the submitters of other rk3399-boards >>>>>>>> in the >>>>>>>> recipient list so that they're aware or limit the change to >>>>>>>> rockpro64 for >>>>>>>> the time being (aka overriding the property in the board-dts) >>>>>>>> please? >>>>>>>> >>>>>>> >>>>>>> OK, I'm adding other boards members. >>>>>>> by ./scripts/get_maintainer.pl >>>>>>> arch/arm64/boot/dts/rockchip/rk3399-*.dts >>>>>>> >>>>>>> >>>>>>> RockPro64 directly connect UART2 pins of RK3399 to external >>>>>>> connector. >>>>>>> I think maybe other RK3399 boards are facing same problem, but I >>>>>>> cannot >>>>>>> check it because I have RockPro64 only... >>>>>>> >>>>>>> I'm happy if someone tell me other boards situation. >>>>>> >>>>>> I'm pulling out other rockchip boards momentarily to see what kind of >>>>>> population we have. >>>>>> >>>>>> Note these are not all running 5.x kernels, however none of them have >>>>>> the UART2 drive levels modified to my knowledge, and regardless, none >>>>>> show over 100 ns. >>>>>> >>>>>> board: rise/fall >>>>>> >>>>>> rk3399-roc-pc: 90ns/90ns >>>>>> rk3399-rockpro64 V2.0: 90ns/45ns >>>>>> rk3399-rockpro64 V2.1: 40ns/41ns >>> >>> I'm having to eyeball off a 20MHz analog scope (thank goodness for "yes" >>> being able to generate a nice periodic signal), but for my NanoPC-T4 >>> with a cheap eBay FT232R adapter both rise and fall times are certainly >>> <100ns. FWIW I've not noticed any issues with letting the Bluetooth >>> interface on UART0 run flat-out at 4Mbaud either. >>> > > Robin, Thanks a lot. Your results show that cold solder (or some > electric parts on board) of my RockPro64 is broken or something wrong. > > >>>>>> >>>>>> Please make sure there's not a large amount of flux or something >>>>>> around the terminals on your board, that seems excessively high. >>>>>> >>>>> >>>>> Thank you for valuable information. For more deeply discussion, >>>>> I tried other conditions and watch the rise/fall times. >>>>> >>>>> 1) Not connect >>>>> The rise/fall times are 40ns/5ns when nothing connect (impedance is >>>>> very high) to external pin of RockPro64. >>>>> >>>>> What UART device are you using with RockPro64? If you use some device >>>>> with RockPro64 and board shows rise/fall times = 90ns/45ns, my device >>>>> is not suitable for RockPro64 by some reason. So it's better to drop >>>>> my patch. >>>> >>>> The adapter is an FTDI FT232RL breakout board, attached with some >>>> generic Dupont connector jumpers. >>>> Interesting your RockPro is showing this symptom, perhaps there is a >>>> cold solder joint somewhere introducing resistance? >>>> >>>>> >>>>> 2) Other SoC >>>>> I have other SoC board rk3328-rock64, Rock64 shows rise/fall times = >>>>> 90ns/80ns when same UART-USB device is connected to UART pin. >>>> >>>> I measured similar on my Rock64 as well. >>>> > > Tony, thanks for your info about environment. > > It seems my RockPro64 problem. I don't have enough electronic knowledge, > but try to check my RockPro64 as much as I can. > > >>>>> >>>>> I think it shows rk3399's (or RockPro64's?) drive strength is a little >>>>> weak. So it's better to increase the drive strength of UART of rk3399. >>>> >>>> I do not think this is a bad idea generally, it simply allows for more >>>> available current from the interface. I'll let others be the judge of >>>> that, however. >>> >>> There may be RK3399 users who would care about the possible EMI impact, >>> so it's probably still best to limit such a change to boards which >>> definitely need it. >>> >> >> Ah, good point. >> >> As to speeds achievable, I've only run into drive level issues with >> SD/SDIO, but that's all the way up at 25-50 MHz. > > My patch has bad effects for EMI issues of all RK3399 boards. > > So conclusion is, my patch should be dropped. Sorry for confusing. > > Best Regards, > Katsuhiro Suzuki > > >> >> Tony >> >>> Robin. >>> >>>> >>>>> >>>>> Best Regards, >>>>> Katsuhiro Suzuki >>>>> >>>>>>> >>>>>>> Best Regards, >>>>>>> Katsuhiro Suzuki >>>>>>> >>>>>>> >>>>>>>> Thanks >>>>>>>> Heiko >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> diff --git a/arch/arm64/boot/dts/rockchip/rk3399.dtsi >>>>>>>>> b/arch/arm64/boot/dts/rockchip/rk3399.dtsi >>>>>>>>> index beaa92744a64..e3c8f91ead50 100644 >>>>>>>>> --- a/arch/arm64/boot/dts/rockchip/rk3399.dtsi >>>>>>>>> +++ b/arch/arm64/boot/dts/rockchip/rk3399.dtsi >>>>>>>>> @@ -2000,6 +2000,11 @@ >>>>>>>>> drive-strength = <8>; >>>>>>>>> }; >>>>>>>>> >>>>>>>>> + pcfg_pull_up_12ma: pcfg-pull-up-12ma { >>>>>>>>> + bias-pull-up; >>>>>>>>> + drive-strength = <12>; >>>>>>>>> + }; >>>>>>>>> + >>>>>>>>> pcfg_pull_up_18ma: pcfg-pull-up-18ma { >>>>>>>>> bias-pull-up; >>>>>>>>> drive-strength = <18>; >>>>>>>>> @@ -2521,8 +2526,8 @@ >>>>>>>>> uart2c { >>>>>>>>> uart2c_xfer: uart2c-xfer { >>>>>>>>> rockchip,pins = >>>>>>>>> - <4 RK_PC3 RK_FUNC_1 >>>>>>>>> &pcfg_pull_up>, >>>>>>>>> - <4 RK_PC4 RK_FUNC_1 >>>>>>>>> &pcfg_pull_none>; >>>>>>>>> + <4 RK_PC3 RK_FUNC_1 >>>>>>>>> &pcfg_pull_up_12ma>, >>>>>>>>> + <4 RK_PC4 RK_FUNC_1 >>>>>>>>> &pcfg_pull_none_12ma>; >>>>>>>>> }; >>>>>>>>> }; >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Linux-rockchip mailing list >>>>>>> Linux-rockchip@lists.infradead.org >>>>>>> http://lists.infradead.org/mailman/listinfo/linux-rockchip >>>>>> >>>>>> >>>>> >> >> _______________________________________________ >> Linux-rockchip mailing list >> Linux-rockchip@lists.infradead.org >> http://lists.infradead.org/mailman/listinfo/linux-rockchip >> >> > > _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 43+ messages in thread
[parent not found: <01af012d-0ef0-b3af-4d14-188ff5c9a7c9-WKCMddiH/C4xsqv6Oivclw@public.gmane.org>]
* Re: [PATCH] arm64: dts: rockchip: decrease rising edge time of UART2 2019-03-26 13:39 ` Katsuhiro Suzuki @ 2019-03-26 13:51 ` Heiko Stübner -1 siblings, 0 replies; 43+ messages in thread From: Heiko Stübner @ 2019-03-26 13:51 UTC (permalink / raw) To: Katsuhiro Suzuki, Klaus Goger, linux-rockchip-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Oskari Lemmela Cc: Viresh Kumar, Linus Walleij, Akash Gajjar, Vicente Bergas, Tony McKahan, Enric Balletbo i Serra, Robin Murphy, Shawn Lin Hi, Am Dienstag, 26. März 2019, 14:39:42 CET schrieb Katsuhiro Suzuki: > Hello Tony, Robin, > > I continue to investigate UART TX rising time problem. Recently, I found > one of cause of this problem. > > In my environment, this problem occurred on linux-next only. U-Boot does > not face it. So I compared settings between U-Boot and linux-next. After > I found GRF_IO_VSEL (address 0xff77e640) register is differ. > > > Would you tell me what value is stored into this register? > > > My RockPro64, initially 0x00000000 is set but 0x00000003 is set during > linux boot. UART TX rising time becomes fine if set both bit 1 and bit 3 > or clear both bits. GRF_IO_VSEL is the voltage-domain selection for different domains, see the &io_domains{} node in your rockpro64 dts. The soc needs to know with what voltage some of its inputs are supplied. Bits are: 0 - bt656 1 - audio 2 - sdmmc 3 - gpio1833 These bits must correspond of the voltages of their regulators, 0 for 3.3V and 1 for 1.8V. But the vcc1v8_dvp regulator connected to the bt656 input has not changed since the initial submission of the devicetree. > On 2019/03/04 22:59, Katsuhiro Suzuki wrote: > > Hello Tony, Robin, > > > > On 2019/03/04 5:41, Tony McKahan wrote: > >> On Sun, Mar 3, 2019 at 2:51 PM Robin Murphy <robin.murphy-5wv7dgnIgG8@public.gmane.org> wrote: > >>> > >>> On 2019-03-03 6:45 pm, Tony McKahan wrote: > >>>> Hello Katsushiro, > >>>> > >>>> On Sun, Mar 3, 2019 at 12:31 PM Katsuhiro Suzuki > >>>> <katsuhiro-WKCMddiH/C4xsqv6Oivclw@public.gmane.org> wrote: > >>>>> > >>>>> Hello Tony, > >>>>> > >>>>> On 2019/03/04 0:13, Tony McKahan wrote: > >>>>>> On Sun, Mar 3, 2019 at 9:04 AM Katsuhiro Suzuki > >>>>>> <katsuhiro-WKCMddiH/C4xsqv6Oivclw@public.gmane.org> wrote: > >>>>>>> > >>>>>>> Hello Heiko, > >>>>>>> > >>>>>>> Thank you for comments. > >>>>>>> > >>>>>>> On 2019/03/03 22:19, Heiko Stuebner wrote: > >>>>>>>> Hi, > >>>>>>>> > >>>>>>>> Am Sonntag, 3. März 2019, 13:27:05 CET schrieb Katsuhiro Suzuki: > >>>>>>>>> This patch increases drive strength of UART2 from 3mA to 12mA for > >>>>>>>>> getting more faster rising edge. > >>>>>>>>> > >>>>>>>>> RockPro64 is using a very high speed rate (1.5Mbps) for UART2. In > >>>>>>>>> this setting, a bit width of UART is about 667ns. > >>>>>>>>> > >>>>>>>>> In my environment (RockPro64 UART2 with FTDI FT232RL UART-USB > >>>>>>>>> converter), falling time of RockPro64 UART2 is 40ns, but riging > >>>>>>>>> time > >>>>>>>>> is over 650ns. So UART receiver will get wrong data, because > >>>>>>>>> receiver > >>>>>>>>> read intermediate data of rising edge. > >>>>>>>>> > >>>>>>>>> Rising time becomes 300ns from 650ns if apply this patch. This > >>>>>>>>> is not > >>>>>>>>> perfect solution but better than now. > >>>>>>>>> > >>>>>>>>> Signed-off-by: Katsuhiro Suzuki <katsuhiro-WKCMddiH/C4xsqv6Oivclw@public.gmane.org> > >>>>>>>>> --- > >>>>>>>>> arch/arm64/boot/dts/rockchip/rk3399.dtsi | 9 +++++++-- > >>>>>>>>> 1 file changed, 7 insertions(+), 2 deletions(-) > >>>>>>>> > >>>>>>>> your changing a core rk3399 property here, so I'd really like to > >>>>>>>> get > >>>>>>>> input from other board stakeholders on this before applying a core > >>>>>>>> change. > >>>>>>>> > >>>>>>>> Could you either include the submitters of other rk3399-boards > >>>>>>>> in the > >>>>>>>> recipient list so that they're aware or limit the change to > >>>>>>>> rockpro64 for > >>>>>>>> the time being (aka overriding the property in the board-dts) > >>>>>>>> please? > >>>>>>>> > >>>>>>> > >>>>>>> OK, I'm adding other boards members. > >>>>>>> by ./scripts/get_maintainer.pl > >>>>>>> arch/arm64/boot/dts/rockchip/rk3399-*.dts > >>>>>>> > >>>>>>> > >>>>>>> RockPro64 directly connect UART2 pins of RK3399 to external > >>>>>>> connector. > >>>>>>> I think maybe other RK3399 boards are facing same problem, but I > >>>>>>> cannot > >>>>>>> check it because I have RockPro64 only... > >>>>>>> > >>>>>>> I'm happy if someone tell me other boards situation. > >>>>>> > >>>>>> I'm pulling out other rockchip boards momentarily to see what kind of > >>>>>> population we have. > >>>>>> > >>>>>> Note these are not all running 5.x kernels, however none of them have > >>>>>> the UART2 drive levels modified to my knowledge, and regardless, none > >>>>>> show over 100 ns. > >>>>>> > >>>>>> board: rise/fall > >>>>>> > >>>>>> rk3399-roc-pc: 90ns/90ns > >>>>>> rk3399-rockpro64 V2.0: 90ns/45ns > >>>>>> rk3399-rockpro64 V2.1: 40ns/41ns > >>> > >>> I'm having to eyeball off a 20MHz analog scope (thank goodness for "yes" > >>> being able to generate a nice periodic signal), but for my NanoPC-T4 > >>> with a cheap eBay FT232R adapter both rise and fall times are certainly > >>> <100ns. FWIW I've not noticed any issues with letting the Bluetooth > >>> interface on UART0 run flat-out at 4Mbaud either. > >>> > > > > Robin, Thanks a lot. Your results show that cold solder (or some > > electric parts on board) of my RockPro64 is broken or something wrong. > > > > > >>>>>> > >>>>>> Please make sure there's not a large amount of flux or something > >>>>>> around the terminals on your board, that seems excessively high. > >>>>>> > >>>>> > >>>>> Thank you for valuable information. For more deeply discussion, > >>>>> I tried other conditions and watch the rise/fall times. > >>>>> > >>>>> 1) Not connect > >>>>> The rise/fall times are 40ns/5ns when nothing connect (impedance is > >>>>> very high) to external pin of RockPro64. > >>>>> > >>>>> What UART device are you using with RockPro64? If you use some device > >>>>> with RockPro64 and board shows rise/fall times = 90ns/45ns, my device > >>>>> is not suitable for RockPro64 by some reason. So it's better to drop > >>>>> my patch. > >>>> > >>>> The adapter is an FTDI FT232RL breakout board, attached with some > >>>> generic Dupont connector jumpers. > >>>> Interesting your RockPro is showing this symptom, perhaps there is a > >>>> cold solder joint somewhere introducing resistance? > >>>> > >>>>> > >>>>> 2) Other SoC > >>>>> I have other SoC board rk3328-rock64, Rock64 shows rise/fall times = > >>>>> 90ns/80ns when same UART-USB device is connected to UART pin. > >>>> > >>>> I measured similar on my Rock64 as well. > >>>> > > > > Tony, thanks for your info about environment. > > > > It seems my RockPro64 problem. I don't have enough electronic knowledge, > > but try to check my RockPro64 as much as I can. > > > > > >>>>> > >>>>> I think it shows rk3399's (or RockPro64's?) drive strength is a little > >>>>> weak. So it's better to increase the drive strength of UART of rk3399. > >>>> > >>>> I do not think this is a bad idea generally, it simply allows for more > >>>> available current from the interface. I'll let others be the judge of > >>>> that, however. > >>> > >>> There may be RK3399 users who would care about the possible EMI impact, > >>> so it's probably still best to limit such a change to boards which > >>> definitely need it. > >>> > >> > >> Ah, good point. > >> > >> As to speeds achievable, I've only run into drive level issues with > >> SD/SDIO, but that's all the way up at 25-50 MHz. > > > > My patch has bad effects for EMI issues of all RK3399 boards. > > > > So conclusion is, my patch should be dropped. Sorry for confusing. > > > > Best Regards, > > Katsuhiro Suzuki > > > > > >> > >> Tony > >> > >>> Robin. > >>> > >>>> > >>>>> > >>>>> Best Regards, > >>>>> Katsuhiro Suzuki > >>>>> > >>>>>>> > >>>>>>> Best Regards, > >>>>>>> Katsuhiro Suzuki > >>>>>>> > >>>>>>> > >>>>>>>> Thanks > >>>>>>>> Heiko > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>>> diff --git a/arch/arm64/boot/dts/rockchip/rk3399.dtsi > >>>>>>>>> b/arch/arm64/boot/dts/rockchip/rk3399.dtsi > >>>>>>>>> index beaa92744a64..e3c8f91ead50 100644 > >>>>>>>>> --- a/arch/arm64/boot/dts/rockchip/rk3399.dtsi > >>>>>>>>> +++ b/arch/arm64/boot/dts/rockchip/rk3399.dtsi > >>>>>>>>> @@ -2000,6 +2000,11 @@ > >>>>>>>>> drive-strength = <8>; > >>>>>>>>> }; > >>>>>>>>> > >>>>>>>>> + pcfg_pull_up_12ma: pcfg-pull-up-12ma { > >>>>>>>>> + bias-pull-up; > >>>>>>>>> + drive-strength = <12>; > >>>>>>>>> + }; > >>>>>>>>> + > >>>>>>>>> pcfg_pull_up_18ma: pcfg-pull-up-18ma { > >>>>>>>>> bias-pull-up; > >>>>>>>>> drive-strength = <18>; > >>>>>>>>> @@ -2521,8 +2526,8 @@ > >>>>>>>>> uart2c { > >>>>>>>>> uart2c_xfer: uart2c-xfer { > >>>>>>>>> rockchip,pins = > >>>>>>>>> - <4 RK_PC3 RK_FUNC_1 > >>>>>>>>> &pcfg_pull_up>, > >>>>>>>>> - <4 RK_PC4 RK_FUNC_1 > >>>>>>>>> &pcfg_pull_none>; > >>>>>>>>> + <4 RK_PC3 RK_FUNC_1 > >>>>>>>>> &pcfg_pull_up_12ma>, > >>>>>>>>> + <4 RK_PC4 RK_FUNC_1 > >>>>>>>>> &pcfg_pull_none_12ma>; > >>>>>>>>> }; > >>>>>>>>> }; > >>>>>>>>> > >>>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> _______________________________________________ > >>>>>>> Linux-rockchip mailing list > >>>>>>> Linux-rockchip-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org > >>>>>>> http://lists.infradead.org/mailman/listinfo/linux-rockchip > >>>>>> > >>>>>> > >>>>> > >> > >> _______________________________________________ > >> Linux-rockchip mailing list > >> Linux-rockchip-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org > >> http://lists.infradead.org/mailman/listinfo/linux-rockchip > >> > >> > > > > > > ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [PATCH] arm64: dts: rockchip: decrease rising edge time of UART2 @ 2019-03-26 13:51 ` Heiko Stübner 0 siblings, 0 replies; 43+ messages in thread From: Heiko Stübner @ 2019-03-26 13:51 UTC (permalink / raw) To: Katsuhiro Suzuki, Klaus Goger, linux-rockchip, linux-arm-kernel, Oskari Lemmela Cc: Viresh Kumar, Linus Walleij, Akash Gajjar, Vicente Bergas, Tony McKahan, Enric Balletbo i Serra, Robin Murphy, Shawn Lin Hi, Am Dienstag, 26. März 2019, 14:39:42 CET schrieb Katsuhiro Suzuki: > Hello Tony, Robin, > > I continue to investigate UART TX rising time problem. Recently, I found > one of cause of this problem. > > In my environment, this problem occurred on linux-next only. U-Boot does > not face it. So I compared settings between U-Boot and linux-next. After > I found GRF_IO_VSEL (address 0xff77e640) register is differ. > > > Would you tell me what value is stored into this register? > > > My RockPro64, initially 0x00000000 is set but 0x00000003 is set during > linux boot. UART TX rising time becomes fine if set both bit 1 and bit 3 > or clear both bits. GRF_IO_VSEL is the voltage-domain selection for different domains, see the &io_domains{} node in your rockpro64 dts. The soc needs to know with what voltage some of its inputs are supplied. Bits are: 0 - bt656 1 - audio 2 - sdmmc 3 - gpio1833 These bits must correspond of the voltages of their regulators, 0 for 3.3V and 1 for 1.8V. But the vcc1v8_dvp regulator connected to the bt656 input has not changed since the initial submission of the devicetree. > On 2019/03/04 22:59, Katsuhiro Suzuki wrote: > > Hello Tony, Robin, > > > > On 2019/03/04 5:41, Tony McKahan wrote: > >> On Sun, Mar 3, 2019 at 2:51 PM Robin Murphy <robin.murphy@arm.com> wrote: > >>> > >>> On 2019-03-03 6:45 pm, Tony McKahan wrote: > >>>> Hello Katsushiro, > >>>> > >>>> On Sun, Mar 3, 2019 at 12:31 PM Katsuhiro Suzuki > >>>> <katsuhiro@katsuster.net> wrote: > >>>>> > >>>>> Hello Tony, > >>>>> > >>>>> On 2019/03/04 0:13, Tony McKahan wrote: > >>>>>> On Sun, Mar 3, 2019 at 9:04 AM Katsuhiro Suzuki > >>>>>> <katsuhiro@katsuster.net> wrote: > >>>>>>> > >>>>>>> Hello Heiko, > >>>>>>> > >>>>>>> Thank you for comments. > >>>>>>> > >>>>>>> On 2019/03/03 22:19, Heiko Stuebner wrote: > >>>>>>>> Hi, > >>>>>>>> > >>>>>>>> Am Sonntag, 3. März 2019, 13:27:05 CET schrieb Katsuhiro Suzuki: > >>>>>>>>> This patch increases drive strength of UART2 from 3mA to 12mA for > >>>>>>>>> getting more faster rising edge. > >>>>>>>>> > >>>>>>>>> RockPro64 is using a very high speed rate (1.5Mbps) for UART2. In > >>>>>>>>> this setting, a bit width of UART is about 667ns. > >>>>>>>>> > >>>>>>>>> In my environment (RockPro64 UART2 with FTDI FT232RL UART-USB > >>>>>>>>> converter), falling time of RockPro64 UART2 is 40ns, but riging > >>>>>>>>> time > >>>>>>>>> is over 650ns. So UART receiver will get wrong data, because > >>>>>>>>> receiver > >>>>>>>>> read intermediate data of rising edge. > >>>>>>>>> > >>>>>>>>> Rising time becomes 300ns from 650ns if apply this patch. This > >>>>>>>>> is not > >>>>>>>>> perfect solution but better than now. > >>>>>>>>> > >>>>>>>>> Signed-off-by: Katsuhiro Suzuki <katsuhiro@katsuster.net> > >>>>>>>>> --- > >>>>>>>>> arch/arm64/boot/dts/rockchip/rk3399.dtsi | 9 +++++++-- > >>>>>>>>> 1 file changed, 7 insertions(+), 2 deletions(-) > >>>>>>>> > >>>>>>>> your changing a core rk3399 property here, so I'd really like to > >>>>>>>> get > >>>>>>>> input from other board stakeholders on this before applying a core > >>>>>>>> change. > >>>>>>>> > >>>>>>>> Could you either include the submitters of other rk3399-boards > >>>>>>>> in the > >>>>>>>> recipient list so that they're aware or limit the change to > >>>>>>>> rockpro64 for > >>>>>>>> the time being (aka overriding the property in the board-dts) > >>>>>>>> please? > >>>>>>>> > >>>>>>> > >>>>>>> OK, I'm adding other boards members. > >>>>>>> by ./scripts/get_maintainer.pl > >>>>>>> arch/arm64/boot/dts/rockchip/rk3399-*.dts > >>>>>>> > >>>>>>> > >>>>>>> RockPro64 directly connect UART2 pins of RK3399 to external > >>>>>>> connector. > >>>>>>> I think maybe other RK3399 boards are facing same problem, but I > >>>>>>> cannot > >>>>>>> check it because I have RockPro64 only... > >>>>>>> > >>>>>>> I'm happy if someone tell me other boards situation. > >>>>>> > >>>>>> I'm pulling out other rockchip boards momentarily to see what kind of > >>>>>> population we have. > >>>>>> > >>>>>> Note these are not all running 5.x kernels, however none of them have > >>>>>> the UART2 drive levels modified to my knowledge, and regardless, none > >>>>>> show over 100 ns. > >>>>>> > >>>>>> board: rise/fall > >>>>>> > >>>>>> rk3399-roc-pc: 90ns/90ns > >>>>>> rk3399-rockpro64 V2.0: 90ns/45ns > >>>>>> rk3399-rockpro64 V2.1: 40ns/41ns > >>> > >>> I'm having to eyeball off a 20MHz analog scope (thank goodness for "yes" > >>> being able to generate a nice periodic signal), but for my NanoPC-T4 > >>> with a cheap eBay FT232R adapter both rise and fall times are certainly > >>> <100ns. FWIW I've not noticed any issues with letting the Bluetooth > >>> interface on UART0 run flat-out at 4Mbaud either. > >>> > > > > Robin, Thanks a lot. Your results show that cold solder (or some > > electric parts on board) of my RockPro64 is broken or something wrong. > > > > > >>>>>> > >>>>>> Please make sure there's not a large amount of flux or something > >>>>>> around the terminals on your board, that seems excessively high. > >>>>>> > >>>>> > >>>>> Thank you for valuable information. For more deeply discussion, > >>>>> I tried other conditions and watch the rise/fall times. > >>>>> > >>>>> 1) Not connect > >>>>> The rise/fall times are 40ns/5ns when nothing connect (impedance is > >>>>> very high) to external pin of RockPro64. > >>>>> > >>>>> What UART device are you using with RockPro64? If you use some device > >>>>> with RockPro64 and board shows rise/fall times = 90ns/45ns, my device > >>>>> is not suitable for RockPro64 by some reason. So it's better to drop > >>>>> my patch. > >>>> > >>>> The adapter is an FTDI FT232RL breakout board, attached with some > >>>> generic Dupont connector jumpers. > >>>> Interesting your RockPro is showing this symptom, perhaps there is a > >>>> cold solder joint somewhere introducing resistance? > >>>> > >>>>> > >>>>> 2) Other SoC > >>>>> I have other SoC board rk3328-rock64, Rock64 shows rise/fall times = > >>>>> 90ns/80ns when same UART-USB device is connected to UART pin. > >>>> > >>>> I measured similar on my Rock64 as well. > >>>> > > > > Tony, thanks for your info about environment. > > > > It seems my RockPro64 problem. I don't have enough electronic knowledge, > > but try to check my RockPro64 as much as I can. > > > > > >>>>> > >>>>> I think it shows rk3399's (or RockPro64's?) drive strength is a little > >>>>> weak. So it's better to increase the drive strength of UART of rk3399. > >>>> > >>>> I do not think this is a bad idea generally, it simply allows for more > >>>> available current from the interface. I'll let others be the judge of > >>>> that, however. > >>> > >>> There may be RK3399 users who would care about the possible EMI impact, > >>> so it's probably still best to limit such a change to boards which > >>> definitely need it. > >>> > >> > >> Ah, good point. > >> > >> As to speeds achievable, I've only run into drive level issues with > >> SD/SDIO, but that's all the way up at 25-50 MHz. > > > > My patch has bad effects for EMI issues of all RK3399 boards. > > > > So conclusion is, my patch should be dropped. Sorry for confusing. > > > > Best Regards, > > Katsuhiro Suzuki > > > > > >> > >> Tony > >> > >>> Robin. > >>> > >>>> > >>>>> > >>>>> Best Regards, > >>>>> Katsuhiro Suzuki > >>>>> > >>>>>>> > >>>>>>> Best Regards, > >>>>>>> Katsuhiro Suzuki > >>>>>>> > >>>>>>> > >>>>>>>> Thanks > >>>>>>>> Heiko > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>>> diff --git a/arch/arm64/boot/dts/rockchip/rk3399.dtsi > >>>>>>>>> b/arch/arm64/boot/dts/rockchip/rk3399.dtsi > >>>>>>>>> index beaa92744a64..e3c8f91ead50 100644 > >>>>>>>>> --- a/arch/arm64/boot/dts/rockchip/rk3399.dtsi > >>>>>>>>> +++ b/arch/arm64/boot/dts/rockchip/rk3399.dtsi > >>>>>>>>> @@ -2000,6 +2000,11 @@ > >>>>>>>>> drive-strength = <8>; > >>>>>>>>> }; > >>>>>>>>> > >>>>>>>>> + pcfg_pull_up_12ma: pcfg-pull-up-12ma { > >>>>>>>>> + bias-pull-up; > >>>>>>>>> + drive-strength = <12>; > >>>>>>>>> + }; > >>>>>>>>> + > >>>>>>>>> pcfg_pull_up_18ma: pcfg-pull-up-18ma { > >>>>>>>>> bias-pull-up; > >>>>>>>>> drive-strength = <18>; > >>>>>>>>> @@ -2521,8 +2526,8 @@ > >>>>>>>>> uart2c { > >>>>>>>>> uart2c_xfer: uart2c-xfer { > >>>>>>>>> rockchip,pins = > >>>>>>>>> - <4 RK_PC3 RK_FUNC_1 > >>>>>>>>> &pcfg_pull_up>, > >>>>>>>>> - <4 RK_PC4 RK_FUNC_1 > >>>>>>>>> &pcfg_pull_none>; > >>>>>>>>> + <4 RK_PC3 RK_FUNC_1 > >>>>>>>>> &pcfg_pull_up_12ma>, > >>>>>>>>> + <4 RK_PC4 RK_FUNC_1 > >>>>>>>>> &pcfg_pull_none_12ma>; > >>>>>>>>> }; > >>>>>>>>> }; > >>>>>>>>> > >>>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> _______________________________________________ > >>>>>>> Linux-rockchip mailing list > >>>>>>> Linux-rockchip@lists.infradead.org > >>>>>>> http://lists.infradead.org/mailman/listinfo/linux-rockchip > >>>>>> > >>>>>> > >>>>> > >> > >> _______________________________________________ > >> Linux-rockchip mailing list > >> Linux-rockchip@lists.infradead.org > >> http://lists.infradead.org/mailman/listinfo/linux-rockchip > >> > >> > > > > > > _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [PATCH] arm64: dts: rockchip: decrease rising edge time of UART2 2019-03-26 13:51 ` Heiko Stübner @ 2019-03-26 13:58 ` Robin Murphy -1 siblings, 0 replies; 43+ messages in thread From: Robin Murphy @ 2019-03-26 13:58 UTC (permalink / raw) To: Heiko Stübner, Katsuhiro Suzuki, Klaus Goger, linux-rockchip-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Oskari Lemmela Cc: Viresh Kumar, Linus Walleij, Akash Gajjar, Vicente Bergas, Tony McKahan, Enric Balletbo i Serra, Shawn Lin On 26/03/2019 13:51, Heiko Stübner wrote: > Hi, > > Am Dienstag, 26. März 2019, 14:39:42 CET schrieb Katsuhiro Suzuki: >> Hello Tony, Robin, >> >> I continue to investigate UART TX rising time problem. Recently, I found >> one of cause of this problem. >> >> In my environment, this problem occurred on linux-next only. U-Boot does >> not face it. So I compared settings between U-Boot and linux-next. After >> I found GRF_IO_VSEL (address 0xff77e640) register is differ. >> >> >> Would you tell me what value is stored into this register? >> >> >> My RockPro64, initially 0x00000000 is set but 0x00000003 is set during >> linux boot. UART TX rising time becomes fine if set both bit 1 and bit 3 >> or clear both bits. > > GRF_IO_VSEL is the voltage-domain selection for different domains, > see the &io_domains{} node in your rockpro64 dts. > The soc needs to know with what voltage some of its inputs are > supplied. > > Bits are: > 0 - bt656 > 1 - audio > 2 - sdmmc > 3 - gpio1833 > > These bits must correspond of the voltages of their regulators, > 0 for 3.3V and 1 for 1.8V. > > But the vcc1v8_dvp regulator connected to the bt656 input has > not changed since the initial submission of the devicetree. Hmm, based on a look through the rockpro64 schematic, does this help? Robin. ----->8----- diff --git a/arch/arm64/boot/dts/rockchip/rk3399-rockpro64.dts b/arch/arm64/boot/dts/rockchip/rk3399-rockpro64.dts index 1f2394e0587d..d473ce290f0c 100644 --- a/arch/arm64/boot/dts/rockchip/rk3399-rockpro64.dts +++ b/arch/arm64/boot/dts/rockchip/rk3399-rockpro64.dts @@ -504,7 +504,7 @@ status = "okay"; bt656-supply = <&vcc1v8_dvp>; - audio-supply = <&vcca1v8_codec>; + audio-supply = <&vcc_3v0>; sdmmc-supply = <&vcc_sdio>; gpio1830-supply = <&vcc_3v0>; }; _______________________________________________ Linux-rockchip mailing list Linux-rockchip@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-rockchip ^ permalink raw reply related [flat|nested] 43+ messages in thread
* Re: [PATCH] arm64: dts: rockchip: decrease rising edge time of UART2 @ 2019-03-26 13:58 ` Robin Murphy 0 siblings, 0 replies; 43+ messages in thread From: Robin Murphy @ 2019-03-26 13:58 UTC (permalink / raw) To: Heiko Stübner, Katsuhiro Suzuki, Klaus Goger, linux-rockchip, linux-arm-kernel, Oskari Lemmela Cc: Viresh Kumar, Linus Walleij, Akash Gajjar, Vicente Bergas, Tony McKahan, Enric Balletbo i Serra, Shawn Lin On 26/03/2019 13:51, Heiko Stübner wrote: > Hi, > > Am Dienstag, 26. März 2019, 14:39:42 CET schrieb Katsuhiro Suzuki: >> Hello Tony, Robin, >> >> I continue to investigate UART TX rising time problem. Recently, I found >> one of cause of this problem. >> >> In my environment, this problem occurred on linux-next only. U-Boot does >> not face it. So I compared settings between U-Boot and linux-next. After >> I found GRF_IO_VSEL (address 0xff77e640) register is differ. >> >> >> Would you tell me what value is stored into this register? >> >> >> My RockPro64, initially 0x00000000 is set but 0x00000003 is set during >> linux boot. UART TX rising time becomes fine if set both bit 1 and bit 3 >> or clear both bits. > > GRF_IO_VSEL is the voltage-domain selection for different domains, > see the &io_domains{} node in your rockpro64 dts. > The soc needs to know with what voltage some of its inputs are > supplied. > > Bits are: > 0 - bt656 > 1 - audio > 2 - sdmmc > 3 - gpio1833 > > These bits must correspond of the voltages of their regulators, > 0 for 3.3V and 1 for 1.8V. > > But the vcc1v8_dvp regulator connected to the bt656 input has > not changed since the initial submission of the devicetree. Hmm, based on a look through the rockpro64 schematic, does this help? Robin. ----->8----- diff --git a/arch/arm64/boot/dts/rockchip/rk3399-rockpro64.dts b/arch/arm64/boot/dts/rockchip/rk3399-rockpro64.dts index 1f2394e0587d..d473ce290f0c 100644 --- a/arch/arm64/boot/dts/rockchip/rk3399-rockpro64.dts +++ b/arch/arm64/boot/dts/rockchip/rk3399-rockpro64.dts @@ -504,7 +504,7 @@ status = "okay"; bt656-supply = <&vcc1v8_dvp>; - audio-supply = <&vcca1v8_codec>; + audio-supply = <&vcc_3v0>; sdmmc-supply = <&vcc_sdio>; gpio1830-supply = <&vcc_3v0>; }; _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply related [flat|nested] 43+ messages in thread
[parent not found: <8292814b-05ab-c0a1-2e80-733b32793e15-5wv7dgnIgG8@public.gmane.org>]
* Re: [PATCH] arm64: dts: rockchip: decrease rising edge time of UART2 2019-03-26 13:58 ` Robin Murphy @ 2019-03-26 14:29 ` Katsuhiro Suzuki -1 siblings, 0 replies; 43+ messages in thread From: Katsuhiro Suzuki @ 2019-03-26 14:29 UTC (permalink / raw) To: Robin Murphy, Heiko Stübner, Klaus Goger, linux-rockchip-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Oskari Lemmela Cc: Viresh Kumar, Linus Walleij, Akash Gajjar, Vicente Bergas, Tony McKahan, Enric Balletbo i Serra, Shawn Lin Hello Heiko, Robin, Thank you for your suggestion. Yes, I found &io_domains{} node in device tree too. I'm temporary fixing this problem by patch like as Robin's suggestion. But I'm confusing that RockPro64 schematics (Power Domain Map) says default voltage of audio_gpio3d_gpio4a is 1.8V and gpio1830_gpio4cd is 3.0V. It shows that current setting of device tree is correct. I don't understand why other person who is using linux-next does not face this problem...?? Best Regards, Katsuhiro Suzuki On 2019/03/26 22:58, Robin Murphy wrote: > On 26/03/2019 13:51, Heiko Stübner wrote: >> Hi, >> >> Am Dienstag, 26. März 2019, 14:39:42 CET schrieb Katsuhiro Suzuki: >>> Hello Tony, Robin, >>> >>> I continue to investigate UART TX rising time problem. Recently, I found >>> one of cause of this problem. >>> >>> In my environment, this problem occurred on linux-next only. U-Boot does >>> not face it. So I compared settings between U-Boot and linux-next. After >>> I found GRF_IO_VSEL (address 0xff77e640) register is differ. >>> >>> >>> Would you tell me what value is stored into this register? >>> >>> >>> My RockPro64, initially 0x00000000 is set but 0x00000003 is set during >>> linux boot. UART TX rising time becomes fine if set both bit 1 and bit 3 >>> or clear both bits. >> >> GRF_IO_VSEL is the voltage-domain selection for different domains, >> see the &io_domains{} node in your rockpro64 dts. >> The soc needs to know with what voltage some of its inputs are >> supplied. >> >> Bits are: >> 0 - bt656 >> 1 - audio >> 2 - sdmmc >> 3 - gpio1833 >> >> These bits must correspond of the voltages of their regulators, >> 0 for 3.3V and 1 for 1.8V. >> >> But the vcc1v8_dvp regulator connected to the bt656 input has >> not changed since the initial submission of the devicetree. > > Hmm, based on a look through the rockpro64 schematic, does this help? > > Robin. > > ----->8----- > diff --git a/arch/arm64/boot/dts/rockchip/rk3399-rockpro64.dts > b/arch/arm64/boot/dts/rockchip/rk3399-rockpro64.dts > index 1f2394e0587d..d473ce290f0c 100644 > --- a/arch/arm64/boot/dts/rockchip/rk3399-rockpro64.dts > +++ b/arch/arm64/boot/dts/rockchip/rk3399-rockpro64.dts > @@ -504,7 +504,7 @@ > status = "okay"; > > bt656-supply = <&vcc1v8_dvp>; > - audio-supply = <&vcca1v8_codec>; > + audio-supply = <&vcc_3v0>; > sdmmc-supply = <&vcc_sdio>; > gpio1830-supply = <&vcc_3v0>; > }; > _______________________________________________ Linux-rockchip mailing list Linux-rockchip@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-rockchip ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [PATCH] arm64: dts: rockchip: decrease rising edge time of UART2 @ 2019-03-26 14:29 ` Katsuhiro Suzuki 0 siblings, 0 replies; 43+ messages in thread From: Katsuhiro Suzuki @ 2019-03-26 14:29 UTC (permalink / raw) To: Robin Murphy, Heiko Stübner, Klaus Goger, linux-rockchip, linux-arm-kernel, Oskari Lemmela Cc: Viresh Kumar, Linus Walleij, Akash Gajjar, Vicente Bergas, Tony McKahan, Enric Balletbo i Serra, Shawn Lin Hello Heiko, Robin, Thank you for your suggestion. Yes, I found &io_domains{} node in device tree too. I'm temporary fixing this problem by patch like as Robin's suggestion. But I'm confusing that RockPro64 schematics (Power Domain Map) says default voltage of audio_gpio3d_gpio4a is 1.8V and gpio1830_gpio4cd is 3.0V. It shows that current setting of device tree is correct. I don't understand why other person who is using linux-next does not face this problem...?? Best Regards, Katsuhiro Suzuki On 2019/03/26 22:58, Robin Murphy wrote: > On 26/03/2019 13:51, Heiko Stübner wrote: >> Hi, >> >> Am Dienstag, 26. März 2019, 14:39:42 CET schrieb Katsuhiro Suzuki: >>> Hello Tony, Robin, >>> >>> I continue to investigate UART TX rising time problem. Recently, I found >>> one of cause of this problem. >>> >>> In my environment, this problem occurred on linux-next only. U-Boot does >>> not face it. So I compared settings between U-Boot and linux-next. After >>> I found GRF_IO_VSEL (address 0xff77e640) register is differ. >>> >>> >>> Would you tell me what value is stored into this register? >>> >>> >>> My RockPro64, initially 0x00000000 is set but 0x00000003 is set during >>> linux boot. UART TX rising time becomes fine if set both bit 1 and bit 3 >>> or clear both bits. >> >> GRF_IO_VSEL is the voltage-domain selection for different domains, >> see the &io_domains{} node in your rockpro64 dts. >> The soc needs to know with what voltage some of its inputs are >> supplied. >> >> Bits are: >> 0 - bt656 >> 1 - audio >> 2 - sdmmc >> 3 - gpio1833 >> >> These bits must correspond of the voltages of their regulators, >> 0 for 3.3V and 1 for 1.8V. >> >> But the vcc1v8_dvp regulator connected to the bt656 input has >> not changed since the initial submission of the devicetree. > > Hmm, based on a look through the rockpro64 schematic, does this help? > > Robin. > > ----->8----- > diff --git a/arch/arm64/boot/dts/rockchip/rk3399-rockpro64.dts > b/arch/arm64/boot/dts/rockchip/rk3399-rockpro64.dts > index 1f2394e0587d..d473ce290f0c 100644 > --- a/arch/arm64/boot/dts/rockchip/rk3399-rockpro64.dts > +++ b/arch/arm64/boot/dts/rockchip/rk3399-rockpro64.dts > @@ -504,7 +504,7 @@ > status = "okay"; > > bt656-supply = <&vcc1v8_dvp>; > - audio-supply = <&vcca1v8_codec>; > + audio-supply = <&vcc_3v0>; > sdmmc-supply = <&vcc_sdio>; > gpio1830-supply = <&vcc_3v0>; > }; > _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [PATCH] arm64: dts: rockchip: decrease rising edge time of UART2 2019-03-26 14:29 ` Katsuhiro Suzuki (?) @ 2019-03-26 15:43 ` Robin Murphy 2019-03-26 16:26 ` Katsuhiro Suzuki -1 siblings, 1 reply; 43+ messages in thread From: Robin Murphy @ 2019-03-26 15:43 UTC (permalink / raw) To: Katsuhiro Suzuki, Heiko Stübner, Klaus Goger, linux-rockchip, linux-arm-kernel, Oskari Lemmela Cc: Viresh Kumar, Linus Walleij, Akash Gajjar, Vicente Bergas, Tony McKahan, Enric Balletbo i Serra, Shawn Lin On 26/03/2019 14:29, Katsuhiro Suzuki wrote: > Hello Heiko, Robin, > > Thank you for your suggestion. Yes, I found &io_domains{} node in > device tree too. I'm temporary fixing this problem by patch like as > Robin's suggestion. > > But I'm confusing that RockPro64 schematics (Power Domain Map) says > default voltage of audio_gpio3d_gpio4a is 1.8V and gpio1830_gpio4cd is > 3.0V. It shows that current setting of device tree is correct. Oh, I hadn't spotted that, I just looked at p16 where it shows APIO5_VDD supplied by VCC_3V0. I would assume that that power domain map page simply never got updated when the actual RockPro64 design was changed away from the Rockchip reference schematic. Robin. > I don't understand why other person who is using linux-next does not > face this problem...?? > > Best Regards, > Katsuhiro Suzuki > > > On 2019/03/26 22:58, Robin Murphy wrote: >> On 26/03/2019 13:51, Heiko Stübner wrote: >>> Hi, >>> >>> Am Dienstag, 26. März 2019, 14:39:42 CET schrieb Katsuhiro Suzuki: >>>> Hello Tony, Robin, >>>> >>>> I continue to investigate UART TX rising time problem. Recently, I >>>> found >>>> one of cause of this problem. >>>> >>>> In my environment, this problem occurred on linux-next only. U-Boot >>>> does >>>> not face it. So I compared settings between U-Boot and linux-next. >>>> After >>>> I found GRF_IO_VSEL (address 0xff77e640) register is differ. >>>> >>>> >>>> Would you tell me what value is stored into this register? >>>> >>>> >>>> My RockPro64, initially 0x00000000 is set but 0x00000003 is set during >>>> linux boot. UART TX rising time becomes fine if set both bit 1 and >>>> bit 3 >>>> or clear both bits. >>> >>> GRF_IO_VSEL is the voltage-domain selection for different domains, >>> see the &io_domains{} node in your rockpro64 dts. >>> The soc needs to know with what voltage some of its inputs are >>> supplied. >>> >>> Bits are: >>> 0 - bt656 >>> 1 - audio >>> 2 - sdmmc >>> 3 - gpio1833 >>> >>> These bits must correspond of the voltages of their regulators, >>> 0 for 3.3V and 1 for 1.8V. >>> >>> But the vcc1v8_dvp regulator connected to the bt656 input has >>> not changed since the initial submission of the devicetree. >> >> Hmm, based on a look through the rockpro64 schematic, does this help? >> >> Robin. >> >> ----->8----- >> diff --git a/arch/arm64/boot/dts/rockchip/rk3399-rockpro64.dts >> b/arch/arm64/boot/dts/rockchip/rk3399-rockpro64.dts >> index 1f2394e0587d..d473ce290f0c 100644 >> --- a/arch/arm64/boot/dts/rockchip/rk3399-rockpro64.dts >> +++ b/arch/arm64/boot/dts/rockchip/rk3399-rockpro64.dts >> @@ -504,7 +504,7 @@ >> status = "okay"; >> >> bt656-supply = <&vcc1v8_dvp>; >> - audio-supply = <&vcca1v8_codec>; >> + audio-supply = <&vcc_3v0>; >> sdmmc-supply = <&vcc_sdio>; >> gpio1830-supply = <&vcc_3v0>; >> }; >> > _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [PATCH] arm64: dts: rockchip: decrease rising edge time of UART2 2019-03-26 15:43 ` Robin Murphy @ 2019-03-26 16:26 ` Katsuhiro Suzuki 0 siblings, 0 replies; 43+ messages in thread From: Katsuhiro Suzuki @ 2019-03-26 16:26 UTC (permalink / raw) To: Robin Murphy, Heiko Stübner, Klaus Goger, linux-rockchip, linux-arm-kernel, Oskari Lemmela Cc: Viresh Kumar, Linus Walleij, Akash Gajjar, Vicente Bergas, Tony McKahan, Enric Balletbo i Serra, Shawn Lin Hello Robin, On 2019/03/27 0:43, Robin Murphy wrote: > On 26/03/2019 14:29, Katsuhiro Suzuki wrote: >> Hello Heiko, Robin, >> >> Thank you for your suggestion. Yes, I found &io_domains{} node in >> device tree too. I'm temporary fixing this problem by patch like as >> Robin's suggestion. >> >> But I'm confusing that RockPro64 schematics (Power Domain Map) says >> default voltage of audio_gpio3d_gpio4a is 1.8V and gpio1830_gpio4cd is >> 3.0V. It shows that current setting of device tree is correct. > > Oh, I hadn't spotted that, I just looked at p16 where it shows APIO5_VDD > supplied by VCC_3V0. I would assume that that power domain map page > simply never got updated when the actual RockPro64 design was changed > away from the Rockchip reference schematic. > Thanks, I agree with you. Power Domain Map is staying old or something wrong... I will send patch to fix APIO5 domain voltage. Best Regards, Katsuhiro Suzuki > Robin. > >> I don't understand why other person who is using linux-next does not >> face this problem...?? >> >> Best Regards, >> Katsuhiro Suzuki >> >> >> On 2019/03/26 22:58, Robin Murphy wrote: >>> On 26/03/2019 13:51, Heiko Stübner wrote: >>>> Hi, >>>> >>>> Am Dienstag, 26. März 2019, 14:39:42 CET schrieb Katsuhiro Suzuki: >>>>> Hello Tony, Robin, >>>>> >>>>> I continue to investigate UART TX rising time problem. Recently, I >>>>> found >>>>> one of cause of this problem. >>>>> >>>>> In my environment, this problem occurred on linux-next only. U-Boot >>>>> does >>>>> not face it. So I compared settings between U-Boot and linux-next. >>>>> After >>>>> I found GRF_IO_VSEL (address 0xff77e640) register is differ. >>>>> >>>>> >>>>> Would you tell me what value is stored into this register? >>>>> >>>>> >>>>> My RockPro64, initially 0x00000000 is set but 0x00000003 is set during >>>>> linux boot. UART TX rising time becomes fine if set both bit 1 and >>>>> bit 3 >>>>> or clear both bits. >>>> >>>> GRF_IO_VSEL is the voltage-domain selection for different domains, >>>> see the &io_domains{} node in your rockpro64 dts. >>>> The soc needs to know with what voltage some of its inputs are >>>> supplied. >>>> >>>> Bits are: >>>> 0 - bt656 >>>> 1 - audio >>>> 2 - sdmmc >>>> 3 - gpio1833 >>>> >>>> These bits must correspond of the voltages of their regulators, >>>> 0 for 3.3V and 1 for 1.8V. >>>> >>>> But the vcc1v8_dvp regulator connected to the bt656 input has >>>> not changed since the initial submission of the devicetree. >>> >>> Hmm, based on a look through the rockpro64 schematic, does this help? >>> >>> Robin. >>> >>> ----->8----- >>> diff --git a/arch/arm64/boot/dts/rockchip/rk3399-rockpro64.dts >>> b/arch/arm64/boot/dts/rockchip/rk3399-rockpro64.dts >>> index 1f2394e0587d..d473ce290f0c 100644 >>> --- a/arch/arm64/boot/dts/rockchip/rk3399-rockpro64.dts >>> +++ b/arch/arm64/boot/dts/rockchip/rk3399-rockpro64.dts >>> @@ -504,7 +504,7 @@ >>> status = "okay"; >>> >>> bt656-supply = <&vcc1v8_dvp>; >>> - audio-supply = <&vcca1v8_codec>; >>> + audio-supply = <&vcc_3v0>; >>> sdmmc-supply = <&vcc_sdio>; >>> gpio1830-supply = <&vcc_3v0>; >>> }; >>> >> > _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 43+ messages in thread
end of thread, other threads:[~2019-03-26 16:26 UTC | newest]
Thread overview: 43+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2019-03-03 12:27 [PATCH] arm64: dts: rockchip: decrease rising edge time of UART2 Katsuhiro Suzuki
2019-03-03 12:27 ` Katsuhiro Suzuki
2019-03-03 12:27 ` Katsuhiro Suzuki
2019-03-03 13:19 ` Heiko Stuebner
2019-03-03 13:19 ` Heiko Stuebner
2019-03-03 14:03 ` Katsuhiro Suzuki
2019-03-03 14:03 ` Katsuhiro Suzuki
2019-03-03 14:03 ` Katsuhiro Suzuki
[not found] ` <e722acb4-167f-8333-5c8a-b693815273f4-WKCMddiH/C4xsqv6Oivclw@public.gmane.org>
2019-03-03 15:13 ` Tony McKahan
2019-03-03 15:13 ` Tony McKahan
2019-03-03 15:13 ` Tony McKahan
2019-03-03 17:31 ` Katsuhiro Suzuki
2019-03-03 17:31 ` Katsuhiro Suzuki
2019-03-03 17:31 ` Katsuhiro Suzuki
2019-03-03 18:45 ` Tony McKahan
2019-03-03 18:45 ` Tony McKahan
2019-03-03 18:45 ` Tony McKahan
[not found] ` <CAERgoknMO6xMzuhCn2kSHZm8Pt+6YH3jDvJckJq28u9OW08u2Q-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2019-03-03 19:12 ` Tony McKahan
2019-03-03 19:12 ` Tony McKahan
2019-03-03 19:12 ` Tony McKahan
2019-03-04 13:56 ` Katsuhiro Suzuki
2019-03-04 13:56 ` Katsuhiro Suzuki
2019-03-04 13:56 ` Katsuhiro Suzuki
2019-03-03 19:50 ` Robin Murphy
2019-03-03 19:50 ` Robin Murphy
2019-03-03 19:50 ` Robin Murphy
2019-03-03 20:41 ` Tony McKahan
2019-03-03 20:41 ` Tony McKahan
2019-03-03 20:41 ` Tony McKahan
2019-03-04 13:59 ` Katsuhiro Suzuki
2019-03-04 13:59 ` Katsuhiro Suzuki
2019-03-04 13:59 ` Katsuhiro Suzuki
2019-03-26 13:39 ` Katsuhiro Suzuki
2019-03-26 13:39 ` Katsuhiro Suzuki
2019-03-26 13:39 ` Katsuhiro Suzuki
[not found] ` <01af012d-0ef0-b3af-4d14-188ff5c9a7c9-WKCMddiH/C4xsqv6Oivclw@public.gmane.org>
2019-03-26 13:51 ` Heiko Stübner
2019-03-26 13:51 ` Heiko Stübner
2019-03-26 13:58 ` Robin Murphy
2019-03-26 13:58 ` Robin Murphy
[not found] ` <8292814b-05ab-c0a1-2e80-733b32793e15-5wv7dgnIgG8@public.gmane.org>
2019-03-26 14:29 ` Katsuhiro Suzuki
2019-03-26 14:29 ` Katsuhiro Suzuki
2019-03-26 15:43 ` Robin Murphy
2019-03-26 16:26 ` Katsuhiro Suzuki
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.