* Re: [PATCH][RFC] 8250_dw: unregister dw8250_set_termios for rk3188 chip
[not found] ` <d8ba3c8a-a406-cbee-d71b-d6784d6ebacc-56FIPCJpnYtBDgjK7y7TUQ@public.gmane.org>
@ 2017-11-20 16:14 ` Shuyu Wei
[not found] ` <20171120161455.orvooleyzfsslon3-ZQaglsx1qnHXWvwwbwmGMg@public.gmane.org>
0 siblings, 1 reply; 13+ messages in thread
From: Shuyu Wei @ 2017-11-20 16:14 UTC (permalink / raw)
To: Ed Blake
Cc: wangkefeng.wang-hv44wF8Li93QT0dZR+AlfA,
heikki.krogerus-VuQAYsv1563Yd54FQh9/CA,
heiko-4mtYJXux2i+zQB+pC5nmwQ,
gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r,
linux-rockchip-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
p.zabel-bIcnvbaLZ9MEGnE8C9+IrQ,
linux-serial-u79uwXL29TY76Z2rM5mHXA
On Mon, Nov 20, 2017 at 03:44:13PM +0000, Ed Blake wrote:
> On 20/11/17 14:40, Shuyu Wei wrote:
> > dw8250_set_termios is causing problems for rk3188 on my radxa board.
> > It's using a fixed clock at 24M, not baud*16 in dw8250_set_termios.
> > I'm not sure if other rk3xxx chips are facing the same problem.
> >
> > Signed-off-by Wei Shuyu <wsy-flSAGy4ZnMjQT0dZR+AlfA@public.gmane.org>
> > ---
> > drivers/tty/serial/8250/8250_dw.c | 3 +++
> > 1 file changed, 3 insertions(+)
> >
> > diff --git a/drivers/tty/serial/8250/8250_dw.c b/drivers/tty/serial/8250/8250_dw.c
> > index 5bb0c42c88dd..e760a5c1f3f6 100644
> > --- a/drivers/tty/serial/8250/8250_dw.c
> > +++ b/drivers/tty/serial/8250/8250_dw.c
> > @@ -340,6 +340,9 @@ static void dw8250_quirks(struct uart_port *p, struct dw8250_data *data)
> > data->skip_autocfg = true;
> > }
> > #endif
> > + if (of_device_is_compatible(np, "rockchip,rk3188-uart")) {
> > + p->set_termios = NULL;
> > + }
> > if (of_device_is_big_endian(p->dev->of_node)) {
> > p->iotype = UPIO_MEM32BE;
> > p->serial_in = dw8250_serial_in32be;
>
> Can you provide more details on the problem you're trying to solve?
Hi Ed,
Current dw8250_set_termios() trys to set p->uartclk and d->clk to
baud*16, which is incorrect for rk3188. It should be a fixed 24000000.
The incorrect value will result in a wrong baud rate, generating bad
bytes on my serial console. Heikki Krogerus had worried about this,
see https://patchwork.kernel.org/patch/9306275/.
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH][RFC] 8250_dw: unregister dw8250_set_termios for rk3188 chip
[not found] ` <20171120161455.orvooleyzfsslon3-ZQaglsx1qnHXWvwwbwmGMg@public.gmane.org>
@ 2017-11-20 16:26 ` Ed Blake
[not found] ` <0a4ce349-d386-0f1b-e973-e77af7f75d23-56FIPCJpnYtBDgjK7y7TUQ@public.gmane.org>
0 siblings, 1 reply; 13+ messages in thread
From: Ed Blake @ 2017-11-20 16:26 UTC (permalink / raw)
To: Shuyu Wei
Cc: wangkefeng.wang-hv44wF8Li93QT0dZR+AlfA,
heikki.krogerus-VuQAYsv1563Yd54FQh9/CA,
heiko-4mtYJXux2i+zQB+pC5nmwQ,
gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r,
linux-rockchip-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
p.zabel-bIcnvbaLZ9MEGnE8C9+IrQ,
linux-serial-u79uwXL29TY76Z2rM5mHXA
On 20/11/17 16:14, Shuyu Wei wrote:
> On Mon, Nov 20, 2017 at 03:44:13PM +0000, Ed Blake wrote:
>> On 20/11/17 14:40, Shuyu Wei wrote:
>>> dw8250_set_termios is causing problems for rk3188 on my radxa board.
>>> It's using a fixed clock at 24M, not baud*16 in dw8250_set_termios.
>>> I'm not sure if other rk3xxx chips are facing the same problem.
>>>
>>> Signed-off-by Wei Shuyu <wsy@dogben.com>
>>> ---
>>> drivers/tty/serial/8250/8250_dw.c | 3 +++
>>> 1 file changed, 3 insertions(+)
>>>
>>> diff --git a/drivers/tty/serial/8250/8250_dw.c b/drivers/tty/serial/8250/8250_dw.c
>>> index 5bb0c42c88dd..e760a5c1f3f6 100644
>>> --- a/drivers/tty/serial/8250/8250_dw.c
>>> +++ b/drivers/tty/serial/8250/8250_dw.c
>>> @@ -340,6 +340,9 @@ static void dw8250_quirks(struct uart_port *p, struct dw8250_data *data)
>>> data->skip_autocfg = true;
>>> }
>>> #endif
>>> + if (of_device_is_compatible(np, "rockchip,rk3188-uart")) {
>>> + p->set_termios = NULL;
>>> + }
>>> if (of_device_is_big_endian(p->dev->of_node)) {
>>> p->iotype = UPIO_MEM32BE;
>>> p->serial_in = dw8250_serial_in32be;
>> Can you provide more details on the problem you're trying to solve?
> Hi Ed,
>
> Current dw8250_set_termios() trys to set p->uartclk and d->clk to
> baud*16, which is incorrect for rk3188. It should be a fixed 24000000.
> The incorrect value will result in a wrong baud rate, generating bad
> bytes on my serial console. Heikki Krogerus had worried about this,
> see https://patchwork.kernel.org/patch/9306275/.
If the clock is fixed to 24000000, shouldn't clk_round_rate() always
return that value? In which case dw8250_set_termios() wouldn't try to
change the rate.
If clk_round_rate() is returning a different value for a fixed clock, it
sounds like it's the clock driver which needs to change.
_______________________________________________
Linux-rockchip mailing list
Linux-rockchip@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-rockchip
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH][RFC] 8250_dw: unregister dw8250_set_termios for rk3188 chip
[not found] ` <0a4ce349-d386-0f1b-e973-e77af7f75d23-56FIPCJpnYtBDgjK7y7TUQ@public.gmane.org>
@ 2017-11-20 17:51 ` Heiko Stübner
2017-11-21 3:09 ` Shuyu Wei
0 siblings, 1 reply; 13+ messages in thread
From: Heiko Stübner @ 2017-11-20 17:51 UTC (permalink / raw)
To: Ed Blake
Cc: wangkefeng.wang-hv44wF8Li93QT0dZR+AlfA,
heikki.krogerus-VuQAYsv1563Yd54FQh9/CA,
p.zabel-bIcnvbaLZ9MEGnE8C9+IrQ,
gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r,
linux-rockchip-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Shuyu Wei,
linux-serial-u79uwXL29TY76Z2rM5mHXA
Am Montag, 20. November 2017, 16:26:56 CET schrieb Ed Blake:
> On 20/11/17 16:14, Shuyu Wei wrote:
> > On Mon, Nov 20, 2017 at 03:44:13PM +0000, Ed Blake wrote:
> >> On 20/11/17 14:40, Shuyu Wei wrote:
> >>> dw8250_set_termios is causing problems for rk3188 on my radxa board.
> >>> It's using a fixed clock at 24M, not baud*16 in dw8250_set_termios.
> >>> I'm not sure if other rk3xxx chips are facing the same problem.
> >>>
> >>> Signed-off-by Wei Shuyu <wsy-flSAGy4ZnMjQT0dZR+AlfA@public.gmane.org>
> >>> ---
> >>>
> >>> drivers/tty/serial/8250/8250_dw.c | 3 +++
> >>> 1 file changed, 3 insertions(+)
> >>>
> >>> diff --git a/drivers/tty/serial/8250/8250_dw.c
> >>> b/drivers/tty/serial/8250/8250_dw.c index 5bb0c42c88dd..e760a5c1f3f6
> >>> 100644
> >>> --- a/drivers/tty/serial/8250/8250_dw.c
> >>> +++ b/drivers/tty/serial/8250/8250_dw.c
> >>> @@ -340,6 +340,9 @@ static void dw8250_quirks(struct uart_port *p,
> >>> struct dw8250_data *data)>>>
> >>> data->skip_autocfg = true;
> >>>
> >>> }
> >>>
> >>> #endif
> >>>
> >>> + if (of_device_is_compatible(np, "rockchip,rk3188-uart")) {
> >>> + p->set_termios = NULL;
> >>> + }
> >>>
> >>> if (of_device_is_big_endian(p->dev->of_node)) {
> >>>
> >>> p->iotype = UPIO_MEM32BE;
> >>> p->serial_in = dw8250_serial_in32be;
> >>
> >> Can you provide more details on the problem you're trying to solve?
> >
> > Hi Ed,
> >
> > Current dw8250_set_termios() trys to set p->uartclk and d->clk to
> > baud*16, which is incorrect for rk3188. It should be a fixed 24000000.
> > The incorrect value will result in a wrong baud rate, generating bad
> > bytes on my serial console. Heikki Krogerus had worried about this,
> > see https://patchwork.kernel.org/patch/9306275/.
>
> If the clock is fixed to 24000000, shouldn't clk_round_rate() always
> return that value? In which case dw8250_set_termios() wouldn't try to
> change the rate.
>
> If clk_round_rate() is returning a different value for a fixed clock, it
> sounds like it's the clock driver which needs to change.
Also, the rk3188 uarts are definitly not fixed at 24MHz and can use other
sources as well. So I'm puzzled because at least the serial console on my
rk3188 radxarock works without issues.
Can you tell us which uart you are failing to control correctly?
I do remember that I ran into problems when the set_termios change
was introduced originally, resulting in the patch
"serial: 8250_dw: Honor clk_round_rate errors in dw8250_set_termios" [0]
but that is in mainline for quite some time now.
[0] https://patchwork.kernel.org/patch/9594657/
Heiko
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH][RFC] 8250_dw: unregister dw8250_set_termios for rk3188 chip
2017-11-20 17:51 ` Heiko Stübner
@ 2017-11-21 3:09 ` Shuyu Wei
[not found] ` <20171121030949.a6bsapueiicdbonj-ZQaglsx1qnHXWvwwbwmGMg@public.gmane.org>
0 siblings, 1 reply; 13+ messages in thread
From: Shuyu Wei @ 2017-11-21 3:09 UTC (permalink / raw)
To: Heiko Stübner
Cc: wangkefeng.wang-hv44wF8Li93QT0dZR+AlfA,
heikki.krogerus-VuQAYsv1563Yd54FQh9/CA,
linux-serial-u79uwXL29TY76Z2rM5mHXA,
gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r,
linux-rockchip-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
p.zabel-bIcnvbaLZ9MEGnE8C9+IrQ, Ed Blake
On Mon, Nov 20, 2017 at 06:51:37PM +0100, Heiko Stübner wrote:
> Also, the rk3188 uarts are definitly not fixed at 24MHz and can use other
> sources as well. So I'm puzzled because at least the serial console on my
> rk3188 radxarock works without issues.
>
> Can you tell us which uart you are failing to control correctly?
>
>
> I do remember that I ran into problems when the set_termios change
> was introduced originally, resulting in the patch
> "serial: 8250_dw: Honor clk_round_rate errors in dw8250_set_termios" [0]
> but that is in mainline for quite some time now.
>
> [0] https://patchwork.kernel.org/patch/9594657/
>
>
> Heiko
Hi Heiko,
I'm using ttyS2(uart2).
My board starts to fail on mainline since the exact commit 37c8596,
that's why I try to remove dw8250_set_termios() and it worked.
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH][RFC] 8250_dw: unregister dw8250_set_termios for rk3188 chip
[not found] ` <20171121030949.a6bsapueiicdbonj-ZQaglsx1qnHXWvwwbwmGMg@public.gmane.org>
@ 2017-11-21 10:23 ` Ed Blake
[not found] ` <4010bd84-7c88-5410-820f-bd3d04f1fbb5-56FIPCJpnYtBDgjK7y7TUQ@public.gmane.org>
0 siblings, 1 reply; 13+ messages in thread
From: Ed Blake @ 2017-11-21 10:23 UTC (permalink / raw)
To: Shuyu Wei, Heiko Stübner
Cc: wangkefeng.wang-hv44wF8Li93QT0dZR+AlfA,
heikki.krogerus-VuQAYsv1563Yd54FQh9/CA,
p.zabel-bIcnvbaLZ9MEGnE8C9+IrQ,
gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r,
linux-rockchip-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-serial-u79uwXL29TY76Z2rM5mHXA
On 21/11/17 03:09, Shuyu Wei wrote:
> On Mon, Nov 20, 2017 at 06:51:37PM +0100, Heiko Stübner wrote:
>
>> Also, the rk3188 uarts are definitly not fixed at 24MHz and can use other
>> sources as well. So I'm puzzled because at least the serial console on my
>> rk3188 radxarock works without issues.
>>
>> Can you tell us which uart you are failing to control correctly?
>>
>>
>> I do remember that I ran into problems when the set_termios change
>> was introduced originally, resulting in the patch
>> "serial: 8250_dw: Honor clk_round_rate errors in dw8250_set_termios" [0]
>> but that is in mainline for quite some time now.
>>
>> [0] https://patchwork.kernel.org/patch/9594657/
>>
>>
>> Heiko
> Hi Heiko,
>
> I'm using ttyS2(uart2).
> My board starts to fail on mainline since the exact commit 37c8596,
> that's why I try to remove dw8250_set_termios() and it worked.
Is this on 4.14 or next?
What baud rate is being set, and what rate does clk_round_rate() return
in dw8250_set_termios()?
Can you try applying this patch series and see if it fixes the problem?
https://www.spinics.net/lists/linux-serial/msg27672.html
_______________________________________________
Linux-rockchip mailing list
Linux-rockchip@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-rockchip
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH][RFC] 8250_dw: unregister dw8250_set_termios for rk3188 chip
[not found] ` <4010bd84-7c88-5410-820f-bd3d04f1fbb5-56FIPCJpnYtBDgjK7y7TUQ@public.gmane.org>
@ 2017-11-21 17:17 ` Shuyu Wei
[not found] ` <20171121171712.GA4462-ZQaglsx1qnHXWvwwbwmGMg@public.gmane.org>
0 siblings, 1 reply; 13+ messages in thread
From: Shuyu Wei @ 2017-11-21 17:17 UTC (permalink / raw)
To: Ed Blake
Cc: wangkefeng.wang-hv44wF8Li93QT0dZR+AlfA,
heikki.krogerus-VuQAYsv1563Yd54FQh9/CA, Heiko Stübner,
gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r,
linux-rockchip-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
p.zabel-bIcnvbaLZ9MEGnE8C9+IrQ,
linux-serial-u79uwXL29TY76Z2rM5mHXA
On Tue, Nov 21, 2017 at 10:23:17AM +0000, Ed Blake wrote:
> Is this on 4.14 or next?
> Can you try applying this patch series and see if it fixes the problem?
> https://www.spinics.net/lists/linux-serial/msg27672.html
I'm working on the mainline, which already has this patch applied, so it
doesn't fix the problem.
The breaking commit I mentioned is a merge on mainline, the
underlying commit is 6a171b on 2017-01-19.
> What baud rate is being set, and what rate does clk_round_rate() return
> in dw8250_set_termios()?
I'm using baud 115200, clk_round_rate() returns 1843200.
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH][RFC] 8250_dw: unregister dw8250_set_termios for rk3188 chip
[not found] ` <20171121171712.GA4462-ZQaglsx1qnHXWvwwbwmGMg@public.gmane.org>
@ 2017-11-21 17:33 ` Ed Blake
[not found] ` <f834a0a4-3d1e-6f97-6ff3-1d52d609f510-56FIPCJpnYtBDgjK7y7TUQ@public.gmane.org>
0 siblings, 1 reply; 13+ messages in thread
From: Ed Blake @ 2017-11-21 17:33 UTC (permalink / raw)
To: Shuyu Wei
Cc: wangkefeng.wang-hv44wF8Li93QT0dZR+AlfA,
heikki.krogerus-VuQAYsv1563Yd54FQh9/CA, Heiko Stübner,
gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r,
linux-rockchip-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
p.zabel-bIcnvbaLZ9MEGnE8C9+IrQ,
linux-serial-u79uwXL29TY76Z2rM5mHXA
On 21/11/17 17:17, Shuyu Wei wrote:
>
>> What baud rate is being set, and what rate does clk_round_rate() return
>> in dw8250_set_termios()?
> I'm using baud 115200, clk_round_rate() returns 1843200.
So dw8250_set_termios() requests a rate of 1843200 (baud * 16) from
clk_round_rate(), which returns the exact frequency requested. If it
really is capable of being set to that frequency, I can't see why this
wouldn't work. Or clk_round_rate() is incorrectly reporting that it's
capable of that rate, in which case the clock driver needs fixing.
Do you have any way of verifying the actual clock rate going into the UART?
_______________________________________________
Linux-rockchip mailing list
Linux-rockchip@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-rockchip
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH][RFC] 8250_dw: unregister dw8250_set_termios for rk3188 chip
[not found] ` <f834a0a4-3d1e-6f97-6ff3-1d52d609f510-56FIPCJpnYtBDgjK7y7TUQ@public.gmane.org>
@ 2017-11-23 14:56 ` Shuyu Wei
[not found] ` <20171123145622.GA1272-ZQaglsx1qnHXWvwwbwmGMg@public.gmane.org>
0 siblings, 1 reply; 13+ messages in thread
From: Shuyu Wei @ 2017-11-23 14:56 UTC (permalink / raw)
To: Ed Blake
Cc: wangkefeng.wang-hv44wF8Li93QT0dZR+AlfA,
heikki.krogerus-VuQAYsv1563Yd54FQh9/CA, Heiko Stübner,
gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r,
linux-rockchip-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
p.zabel-bIcnvbaLZ9MEGnE8C9+IrQ,
linux-serial-u79uwXL29TY76Z2rM5mHXA
On Tue, Nov 21, 2017 at 05:33:47PM +0000, Ed Blake wrote:
> On 21/11/17 17:17, Shuyu Wei wrote:
> >
> >> What baud rate is being set, and what rate does clk_round_rate() return
> >> in dw8250_set_termios()?
> > I'm using baud 115200, clk_round_rate() returns 1843200.
>
> So dw8250_set_termios() requests a rate of 1843200 (baud * 16) from
> clk_round_rate(), which returns the exact frequency requested. If it
> really is capable of being set to that frequency, I can't see why this
> wouldn't work. Or clk_round_rate() is incorrectly reporting that it's
> capable of that rate, in which case the clock driver needs fixing.
>
> Do you have any way of verifying the actual clock rate going into the UART?
Sorry, I know little about the clock system, and no equipment to do that,
maybe Heiko knows.
The /sys/kernel/debug/clk/clk_summary is attached below, might be helpful.
clock enable_cnt prepare_cnt rate accuracy phase
----------------------------------------------------------------------------------------
xin32k 0 0 32768 0 0
xin24m 12 12 24000000 0 0
timer6 1 1 24000000 0 0
timer5 0 0 24000000 0 0
timer4 0 0 24000000 0 0
timer3 1 1 24000000 0 0
timer2 0 0 24000000 0 0
pll_gpll 1 1 891000000 0 0
gpll 2 2 891000000 0 0
i2s_src 0 0 891000000 0 0
i2s0_pre 0 0 891000000 0 0
i2s0_frac 0 0 44550000 0 0
spdif_pre 0 0 891000000 0 0
aclk_cpu_pre 3 3 297000000 0 0
hclk_cpu_pre 2 2 148500000 0 0
hclk_ahb2apb 2 2 74250000 0 0
pclk_uart1 1 1 74250000 0 0
pclk_uart0 1 1 74250000 0 0
hclk_cpu 2 2 148500000 0 0
hclk_imem1 0 0 148500000 0 0
hclk_imem0 0 0 148500000 0 0
hclk_rga 0 0 148500000 0 0
hclk_ipp 0 0 148500000 0 0
hclk_cif0 0 0 148500000 0 0
hclk_lcdc1 0 0 148500000 0 0
hclk_lcdc0 0 0 148500000 0 0
hclk_vio_bus 0 0 148500000 0 0
hclk_cpubus 1 1 148500000 0 0
hclk_spdif 1 2 148500000 0 0
hclk_i2s0 0 0 148500000 0 0
hclk_rom 0 0 148500000 0 0
pclk_cpu_pre 1 1 37125000 0 0
atclk_cpu 0 0 37125000 0 0
trace 0 0 37125000 0 0
atclk 0 0 37125000 0 0
pclk_cpu 4 8 37125000 0 0
pclk_timer3 1 1 37125000 0 0
pclk_pmu 0 0 37125000 0 0
pclk_grf 0 0 37125000 0 0
pclk_dbg 0 0 37125000 0 0
pclk_ddrpubl 0 0 37125000 0 0
pclk_ddrupctl 0 0 37125000 0 0
pclk_tzpc 0 0 37125000 0 0
pclk_efuse 0 0 37125000 0 0
pclk_gpio2 0 1 37125000 0 0
pclk_gpio1 0 1 37125000 0 0
pclk_gpio0 2 1 37125000 0 0
pclk_i2c1 0 2 37125000 0 0
pclk_i2c0 0 0 37125000 0 0
pclk_timer0 1 1 37125000 0 0
pclk_pwm01 0 2 37125000 0 0
aclk_cpu 2 2 297000000 0 0
aclk_strc_sys 0 0 297000000 0 0
aclk_intmem 0 0 297000000 0 0
aclk_dma1 1 1 297000000 0 0
gpll_armclk 1 1 891000000 0 0
gpll_ddr 0 0 891000000 0 0
hsadc_src 0 0 89100000 0 0
sclk_hsadc_out 0 0 89100000 0 0
sclk_hsadc 0 0 89100000 0 0
hsadc_frac 0 0 4455000 0 0
uart_src 0 0 891000000 0 0
uart3_pre 0 0 891000000 0 0
uart3_frac 0 0 44550000 0 0
uart2_pre 0 0 891000000 0 0
uart2_frac 0 0 44550000 0 0
uart1_pre 0 0 891000000 0 0
uart1_frac 0 0 44550000 0 0
uart0_pre 0 0 891000000 0 0
uart0_frac 0 0 44550000 0 0
..............
more output is omitted.
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH][RFC] 8250_dw: unregister dw8250_set_termios for rk3188 chip
[not found] ` <20171123145622.GA1272-ZQaglsx1qnHXWvwwbwmGMg@public.gmane.org>
@ 2017-11-23 15:11 ` Heiko Stuebner
2017-11-23 15:40 ` Shuyu Wei
0 siblings, 1 reply; 13+ messages in thread
From: Heiko Stuebner @ 2017-11-23 15:11 UTC (permalink / raw)
To: Shuyu Wei
Cc: wangkefeng.wang-hv44wF8Li93QT0dZR+AlfA,
heikki.krogerus-VuQAYsv1563Yd54FQh9/CA,
linux-serial-u79uwXL29TY76Z2rM5mHXA,
gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r,
linux-rockchip-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
p.zabel-bIcnvbaLZ9MEGnE8C9+IrQ, Ed Blake
Hi,
Am Donnerstag, 23. November 2017, 22:56:22 CET schrieb Shuyu Wei:
> On Tue, Nov 21, 2017 at 05:33:47PM +0000, Ed Blake wrote:
> > On 21/11/17 17:17, Shuyu Wei wrote:
> > >
> > >> What baud rate is being set, and what rate does clk_round_rate() return
> > >> in dw8250_set_termios()?
> > > I'm using baud 115200, clk_round_rate() returns 1843200.
> >
> > So dw8250_set_termios() requests a rate of 1843200 (baud * 16) from
> > clk_round_rate(), which returns the exact frequency requested. If it
> > really is capable of being set to that frequency, I can't see why this
> > wouldn't work. Or clk_round_rate() is incorrectly reporting that it's
> > capable of that rate, in which case the clock driver needs fixing.
> >
> > Do you have any way of verifying the actual clock rate going into the UART?
>
> Sorry, I know little about the clock system, and no equipment to do that,
> maybe Heiko knows.
>
> The /sys/kernel/debug/clk/clk_summary is attached below, might be helpful.
>
>
> clock enable_cnt prepare_cnt rate accuracy phase
> ----------------------------------------------------------------------------------------
> xin32k 0 0 32768 0 0
> xin24m 12 12 24000000 0 0
> timer6 1 1 24000000 0 0
> timer5 0 0 24000000 0 0
> timer4 0 0 24000000 0 0
> timer3 1 1 24000000 0 0
> timer2 0 0 24000000 0 0
> pll_gpll 1 1 891000000 0 0
> gpll 2 2 891000000 0 0
> i2s_src 0 0 891000000 0 0
> i2s0_pre 0 0 891000000 0 0
> i2s0_frac 0 0 44550000 0 0
> spdif_pre 0 0 891000000 0 0
> aclk_cpu_pre 3 3 297000000 0 0
> hclk_cpu_pre 2 2 148500000 0 0
> hclk_ahb2apb 2 2 74250000 0 0
> pclk_uart1 1 1 74250000 0 0
> pclk_uart0 1 1 74250000 0 0
> hclk_cpu 2 2 148500000 0 0
> hclk_imem1 0 0 148500000 0 0
> hclk_imem0 0 0 148500000 0 0
> hclk_rga 0 0 148500000 0 0
> hclk_ipp 0 0 148500000 0 0
> hclk_cif0 0 0 148500000 0 0
> hclk_lcdc1 0 0 148500000 0 0
> hclk_lcdc0 0 0 148500000 0 0
> hclk_vio_bus 0 0 148500000 0 0
> hclk_cpubus 1 1 148500000 0 0
> hclk_spdif 1 2 148500000 0 0
> hclk_i2s0 0 0 148500000 0 0
> hclk_rom 0 0 148500000 0 0
> pclk_cpu_pre 1 1 37125000 0 0
> atclk_cpu 0 0 37125000 0 0
> trace 0 0 37125000 0 0
> atclk 0 0 37125000 0 0
> pclk_cpu 4 8 37125000 0 0
> pclk_timer3 1 1 37125000 0 0
> pclk_pmu 0 0 37125000 0 0
> pclk_grf 0 0 37125000 0 0
> pclk_dbg 0 0 37125000 0 0
> pclk_ddrpubl 0 0 37125000 0 0
> pclk_ddrupctl 0 0 37125000 0 0
> pclk_tzpc 0 0 37125000 0 0
> pclk_efuse 0 0 37125000 0 0
> pclk_gpio2 0 1 37125000 0 0
> pclk_gpio1 0 1 37125000 0 0
> pclk_gpio0 2 1 37125000 0 0
> pclk_i2c1 0 2 37125000 0 0
> pclk_i2c0 0 0 37125000 0 0
> pclk_timer0 1 1 37125000 0 0
> pclk_pwm01 0 2 37125000 0 0
> aclk_cpu 2 2 297000000 0 0
> aclk_strc_sys 0 0 297000000 0 0
> aclk_intmem 0 0 297000000 0 0
> aclk_dma1 1 1 297000000 0 0
> gpll_armclk 1 1 891000000 0 0
> gpll_ddr 0 0 891000000 0 0
> hsadc_src 0 0 89100000 0 0
> sclk_hsadc_out 0 0 89100000 0 0
> sclk_hsadc 0 0 89100000 0 0
> hsadc_frac 0 0 4455000 0 0
> uart_src 0 0 891000000 0 0
> uart3_pre 0 0 891000000 0 0
> uart3_frac 0 0 44550000 0 0
> uart2_pre 0 0 891000000 0 0
> uart2_frac 0 0 44550000 0 0
> uart1_pre 0 0 891000000 0 0
> uart1_frac 0 0 44550000 0 0
> uart0_pre 0 0 891000000 0 0
> uart0_frac 0 0 44550000 0 0
> ..............
> more output is omitted.
you actually omitted the output part where sclk_uart2 is actually shown :-) .
On my rk3188 radxarock with a kernel build this morning from
the middle of this merge-window, the relevant part of the clock-tree
looks like the following and my serial console works like a charm:
xin24m 6 6 24000000 0 0
[...]
pll_gpll 1 1 594000000 0 0
gpll 5 5 594000000 0 0
[...]
uart_src 1 1 594000000 0 0
uart3_pre 0 0 594000000 0 0
uart3_frac 0 0 29700000 0 0
uart2_pre 1 1 594000000 0 0
uart2_frac 1 1 1843200 0 0
sclk_uart2 1 1 1843200 0 0
[ ^^ the important clock]
In your dump the sclk_uart2 clock is not muxed to the uart2_frac clock
but to something else but that part is missing from you dump.
So clk_round_rate is definitly correct in that it can reach this rate
using the fractional divider and also can sucessfully set this in the
clock framework.
Can you show where sclk_uart2 is for you please, as I guess your dump
is with the settermios patch disabled, right?
Thanks
Heiko
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH][RFC] 8250_dw: unregister dw8250_set_termios for rk3188 chip
2017-11-23 15:11 ` Heiko Stuebner
@ 2017-11-23 15:40 ` Shuyu Wei
[not found] ` <20171123153922.GA23503-ZQaglsx1qnHXWvwwbwmGMg@public.gmane.org>
0 siblings, 1 reply; 13+ messages in thread
From: Shuyu Wei @ 2017-11-23 15:40 UTC (permalink / raw)
To: Heiko Stuebner
Cc: wangkefeng.wang-hv44wF8Li93QT0dZR+AlfA,
heikki.krogerus-VuQAYsv1563Yd54FQh9/CA,
linux-serial-u79uwXL29TY76Z2rM5mHXA,
gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r,
linux-rockchip-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
p.zabel-bIcnvbaLZ9MEGnE8C9+IrQ, Ed Blake
On Thu, Nov 23, 2017 at 04:11:12PM +0100, Heiko Stuebner wrote:
>
> you actually omitted the output part where sclk_uart2 is actually shown :-) .
>
> On my rk3188 radxarock with a kernel build this morning from
> the middle of this merge-window, the relevant part of the clock-tree
> looks like the following and my serial console works like a charm:
>
> xin24m 6 6 24000000 0 0
> [...]
> pll_gpll 1 1 594000000 0 0
> gpll 5 5 594000000 0 0
> [...]
> uart_src 1 1 594000000 0 0
> uart3_pre 0 0 594000000 0 0
> uart3_frac 0 0 29700000 0 0
> uart2_pre 1 1 594000000 0 0
> uart2_frac 1 1 1843200 0 0
> sclk_uart2 1 1 1843200 0 0
> [ ^^ the important clock]
>
> In your dump the sclk_uart2 clock is not muxed to the uart2_frac clock
> but to something else but that part is missing from you dump.
>
> So clk_round_rate is definitly correct in that it can reach this rate
> using the fractional divider and also can sucessfully set this in the
> clock framework.
>
> Can you show where sclk_uart2 is for you please, as I guess your dump
> is with the settermios patch disabled, right?
>
>
> Thanks
> Heiko
You are right, here is the complete clk_summary from the latest
mainline, and my console is now filled with strange characters :-(
clock enable_cnt prepare_cnt rate accuracy phase
----------------------------------------------------------------------------------------
xin32k 0 0 32768 0 0
xin24m 11 11 24000000 0 0
timer6 1 1 24000000 0 0
timer5 0 0 24000000 0 0
timer4 0 0 24000000 0 0
timer3 1 1 24000000 0 0
timer2 0 0 24000000 0 0
pll_gpll 1 1 891000000 0 0
gpll 3 3 891000000 0 0
i2s_src 0 0 891000000 0 0
i2s0_pre 0 0 891000000 0 0
i2s0_frac 0 0 44550000 0 0
spdif_pre 0 0 891000000 0 0
aclk_cpu_pre 3 3 297000000 0 0
hclk_cpu_pre 2 2 148500000 0 0
hclk_ahb2apb 2 2 74250000 0 0
pclk_uart1 1 1 74250000 0 0
pclk_uart0 1 1 74250000 0 0
hclk_cpu 2 2 148500000 0 0
hclk_imem1 0 0 148500000 0 0
hclk_imem0 0 0 148500000 0 0
hclk_rga 0 0 148500000 0 0
hclk_ipp 0 0 148500000 0 0
hclk_cif0 0 0 148500000 0 0
hclk_lcdc1 0 0 148500000 0 0
hclk_lcdc0 0 0 148500000 0 0
hclk_vio_bus 0 0 148500000 0 0
hclk_cpubus 1 1 148500000 0 0
hclk_spdif 1 2 148500000 0 0
hclk_i2s0 0 0 148500000 0 0
hclk_rom 0 0 148500000 0 0
pclk_cpu_pre 1 1 37125000 0 0
atclk_cpu 0 0 37125000 0 0
trace 0 0 37125000 0 0
atclk 0 0 37125000 0 0
pclk_cpu 4 8 37125000 0 0
pclk_timer3 1 1 37125000 0 0
pclk_pmu 0 0 37125000 0 0
pclk_grf 0 0 37125000 0 0
pclk_dbg 0 0 37125000 0 0
pclk_ddrpubl 0 0 37125000 0 0
pclk_ddrupctl 0 0 37125000 0 0
pclk_tzpc 0 0 37125000 0 0
pclk_efuse 0 0 37125000 0 0
pclk_gpio2 0 1 37125000 0 0
pclk_gpio1 0 1 37125000 0 0
pclk_gpio0 2 1 37125000 0 0
pclk_i2c1 0 2 37125000 0 0
pclk_i2c0 0 0 37125000 0 0
pclk_timer0 1 1 37125000 0 0
pclk_pwm01 0 2 37125000 0 0
aclk_cpu 2 2 297000000 0 0
aclk_strc_sys 0 0 297000000 0 0
aclk_intmem 0 0 297000000 0 0
aclk_dma1 1 1 297000000 0 0
gpll_armclk 1 1 891000000 0 0
gpll_ddr 0 0 891000000 0 0
hsadc_src 0 0 89100000 0 0
sclk_hsadc_out 0 0 89100000 0 0
sclk_hsadc 0 0 89100000 0 0
hsadc_frac 0 0 4455000 0 0
uart_src 1 1 891000000 0 0
uart3_pre 0 0 891000000 0 0
uart3_frac 0 0 44550000 0 0
uart2_pre 1 1 891000000 0 0
uart2_frac 1 1 1843200 0 0
sclk_uart2 1 1 1843200 0 0
uart1_pre 0 0 891000000 0 0
uart1_frac 0 0 44550000 0 0
uart0_pre 0 0 891000000 0 0
uart0_frac 0 0 44550000 0 0
pll_dpll 0 0 300000000 0 0
dpll 0 0 300000000 0 0
ddrphy 0 0 300000000 0 0
mac_src 0 0 50000000 0 0
sclk_macref 0 0 50000000 0 0
sclk_mac_lbtest 0 0 50000000 0 0
pll_cpll 1 1 600000000 0 0
cpll 1 1 600000000 0 0
aclk_gpu_src 0 0 600000000 0 0
aclk_gpu 0 0 600000000 0 0
dclk_lcdc1 0 0 150000000 0 0
dclk_lcdc0 0 0 150000000 0 0
aclk_peri_pre 3 3 150000000 0 0
aclk_peri 2 2 150000000 0 0
aclk_gps 0 0 150000000 0 0
aclk_peri_axi_matrix 0 0 150000000 0 0
aclk_cpu_peri 0 0 150000000 0 0
aclk_peri_niu 0 0 150000000 0 0
aclk_smc 0 0 150000000 0 0
aclk_dma2 1 1 150000000 0 0
hclk_peri 5 5 150000000 0 0
hclk_hsic 0 0 150000000 0 0
hclk_usbotg1 1 1 150000000 0 0
hclk_emmc 0 0 150000000 0 0
hclk_sdio 0 0 150000000 0 0
hclk_sdmmc 1 1 150000000 0 0
hclk_pidfilter 0 0 150000000 0 0
hclk_hsadc 0 0 150000000 0 0
hclk_usbotg0 1 1 150000000 0 0
hclk_usb_peri 0 0 150000000 0 0
hclk_nandc0 0 0 150000000 0 0
hclk_emac 0 0 150000000 0 0
hclk_emem_peri 0 0 150000000 0 0
hclk_peri_ahb_arbi 0 0 150000000 0 0
hclk_peri_axi_matrix 0 0 150000000 0 0
sclk_emmc 0 0 37500000 0 0
sclk_sdio 0 0 6250000 0 0
sclk_sdmmc 1 1 37500000 0 0
sclk_smc 0 0 150000000 0 0
pclk_peri 4 6 75000000 0 0
pclk_saradc 0 0 75000000 0 0
pclk_gpio3 0 1 75000000 0 0
pclk_i2c4 0 0 75000000 0 0
pclk_i2c3 0 0 75000000 0 0
pclk_i2c2 0 0 75000000 0 0
pclk_uart3 1 1 75000000 0 0
pclk_uart2 1 1 75000000 0 0
pclk_spi1 0 0 75000000 0 0
pclk_spi0 0 0 75000000 0 0
pclk_wdt 1 1 75000000 0 0
pclk_pwm23 0 4 75000000 0 0
pclk_peri_axi_matrix 0 0 75000000 0 0
sclk_spi1 0 0 9375000 0 0
sclk_spi0 0 0 37500000 0 0
aclk_vepu 0 0 600000000 0 0
hclk_vepu 0 0 600000000 0 0
aclk_vdpu 0 0 600000000 0 0
hclk_vdpu 0 0 600000000 0 0
aclk_lcdc0_pre 0 0 600000000 0 0
aclk_vio0 0 0 600000000 0 0
aclk_ipp 0 0 600000000 0 0
aclk_cif0 0 0 600000000 0 0
aclk_lcdc0 0 0 600000000 0 0
aclk_lcdc1_pre 0 0 600000000 0 0
aclk_vio1 0 0 600000000 0 0
aclk_rga 0 0 600000000 0 0
aclk_lcdc1 0 0 600000000 0 0
cif_src 0 0 600000000 0 0
cif0_pre 0 0 60000000 0 0
sclk_cif0 0 0 60000000 0 0
pll_apll 1 1 600000000 0 0
apll 1 1 600000000 0 0
armclk 1 1 600000000 0 0
core_peri 1 1 150000000 0 0
core_dbg 0 0 600000000 0 0
aclk_core 0 0 300000000 0 0
core_l2c 0 0 600000000 0 0
timer1 0 0 24000000 0 0
timer0 0 0 24000000 0 0
sclk_uart3 1 1 24000000 0 0
sclk_uart1 1 1 24000000 0 0
sclk_uart0 1 1 24000000 0 0
sclk_saradc 0 0 1000000 0 0
sclk_otgphy1 1 1 24000000 0 0
sclk_otgphy1_480m 1 1 480000000 0 0
sclk_otgphy0 1 1 24000000 0 0
sclk_otgphy0_480m 1 1 480000000 0 0
sclk_hsicphy_480m 0 0 480000000 0 0
sclk_hsicphy_12m 0 0 12000000 0 0
xin12m 1 1 12000000 0 0
sclk_i2s0 0 0 12000000 0 0
sclk_spdif 1 1 12000000 0 0
jtag 0 0 0 0 0
spdif_frac 0 0 0 0 0
pclkin_cif0 0 0 0 0 0
pclk_cif0 0 0 0 0 0
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH][RFC] 8250_dw: unregister dw8250_set_termios for rk3188 chip
[not found] ` <20171123153922.GA23503-ZQaglsx1qnHXWvwwbwmGMg@public.gmane.org>
@ 2017-11-23 23:34 ` Heiko Stuebner
2017-11-24 17:06 ` Shuyu Wei
0 siblings, 1 reply; 13+ messages in thread
From: Heiko Stuebner @ 2017-11-23 23:34 UTC (permalink / raw)
To: Shuyu Wei
Cc: wangkefeng.wang-hv44wF8Li93QT0dZR+AlfA,
heikki.krogerus-VuQAYsv1563Yd54FQh9/CA,
linux-serial-u79uwXL29TY76Z2rM5mHXA,
gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r,
linux-rockchip-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
p.zabel-bIcnvbaLZ9MEGnE8C9+IrQ, Ed Blake
Hi,
Am Donnerstag, 23. November 2017, 23:40:31 CET schrieb Shuyu Wei:
> On Thu, Nov 23, 2017 at 04:11:12PM +0100, Heiko Stuebner wrote:
> >
> > you actually omitted the output part where sclk_uart2 is actually shown :-) .
> >
> > On my rk3188 radxarock with a kernel build this morning from
> > the middle of this merge-window, the relevant part of the clock-tree
> > looks like the following and my serial console works like a charm:
> >
> > xin24m 6 6 24000000 0 0
> > [...]
> > pll_gpll 1 1 594000000 0 0
> > gpll 5 5 594000000 0 0
> > [...]
> > uart_src 1 1 594000000 0 0
> > uart3_pre 0 0 594000000 0 0
> > uart3_frac 0 0 29700000 0 0
> > uart2_pre 1 1 594000000 0 0
> > uart2_frac 1 1 1843200 0 0
> > sclk_uart2 1 1 1843200 0 0
> > [ ^^ the important clock]
> >
> > In your dump the sclk_uart2 clock is not muxed to the uart2_frac clock
> > but to something else but that part is missing from you dump.
> >
> > So clk_round_rate is definitly correct in that it can reach this rate
> > using the fractional divider and also can sucessfully set this in the
> > clock framework.
> >
> > Can you show where sclk_uart2 is for you please, as I guess your dump
> > is with the settermios patch disabled, right?
> >
> >
> > Thanks
> > Heiko
>
> You are right, here is the complete clk_summary from the latest
> mainline, and my console is now filled with strange characters :-(
>
> clock enable_cnt prepare_cnt rate accuracy phase
> ----------------------------------------------------------------------------------------
> xin24m 11 11 24000000 0 0
[...]
> pll_gpll 1 1 891000000 0 0
> gpll 3 3 891000000 0 0
[...]
> uart_src 1 1 891000000 0 0
> uart3_pre 0 0 891000000 0 0
> uart3_frac 0 0 44550000 0 0
> uart2_pre 1 1 891000000 0 0
> uart2_frac 1 1 1843200 0 0
> sclk_uart2 1 1 1843200 0 0
Just to make sure, I did boot-tests on a lot of different Rockchip socs
(rk3036, rk3188, rk3288, rk3328, rk3399) with the serial console using
8250_dw and working normally on all of them with the most recent
torvalds kernel (and everything I tested in the past)
The only difference I see between our two clock dumps is the higher
gpll clock on your board, but I cannot really imagine that this could be
and issue.
So I'm really puzzled by what you see on your board, but don't have
any specific idea what to test right now.
Heiko
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH][RFC] 8250_dw: unregister dw8250_set_termios for rk3188 chip
2017-11-23 23:34 ` Heiko Stuebner
@ 2017-11-24 17:06 ` Shuyu Wei
0 siblings, 0 replies; 13+ messages in thread
From: Shuyu Wei @ 2017-11-24 17:06 UTC (permalink / raw)
To: Heiko Stuebner
Cc: wangkefeng.wang-hv44wF8Li93QT0dZR+AlfA,
heikki.krogerus-VuQAYsv1563Yd54FQh9/CA,
linux-serial-u79uwXL29TY76Z2rM5mHXA,
gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r,
linux-rockchip-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
p.zabel-bIcnvbaLZ9MEGnE8C9+IrQ, Ed Blake
On Fri, Nov 24, 2017 at 12:34:59AM +0100, Heiko Stuebner wrote:
> Hi,
>
> Am Donnerstag, 23. November 2017, 23:40:31 CET schrieb Shuyu Wei:
> > On Thu, Nov 23, 2017 at 04:11:12PM +0100, Heiko Stuebner wrote:
> > >
> > > you actually omitted the output part where sclk_uart2 is actually shown :-) .
> > >
> > > On my rk3188 radxarock with a kernel build this morning from
> > > the middle of this merge-window, the relevant part of the clock-tree
> > > looks like the following and my serial console works like a charm:
> > >
> > > xin24m 6 6 24000000 0 0
> > > [...]
> > > pll_gpll 1 1 594000000 0 0
> > > gpll 5 5 594000000 0 0
> > > [...]
> > > uart_src 1 1 594000000 0 0
> > > uart3_pre 0 0 594000000 0 0
> > > uart3_frac 0 0 29700000 0 0
> > > uart2_pre 1 1 594000000 0 0
> > > uart2_frac 1 1 1843200 0 0
> > > sclk_uart2 1 1 1843200 0 0
> > > [ ^^ the important clock]
> > >
> > > In your dump the sclk_uart2 clock is not muxed to the uart2_frac clock
> > > but to something else but that part is missing from you dump.
> > >
> > > So clk_round_rate is definitly correct in that it can reach this rate
> > > using the fractional divider and also can sucessfully set this in the
> > > clock framework.
> > >
> > > Can you show where sclk_uart2 is for you please, as I guess your dump
> > > is with the settermios patch disabled, right?
> > >
> > >
> > > Thanks
> > > Heiko
> >
> > You are right, here is the complete clk_summary from the latest
> > mainline, and my console is now filled with strange characters :-(
> >
> > clock enable_cnt prepare_cnt rate accuracy phase
> > ----------------------------------------------------------------------------------------
> > xin24m 11 11 24000000 0 0
> [...]
> > pll_gpll 1 1 891000000 0 0
> > gpll 3 3 891000000 0 0
> [...]
> > uart_src 1 1 891000000 0 0
> > uart3_pre 0 0 891000000 0 0
> > uart3_frac 0 0 44550000 0 0
> > uart2_pre 1 1 891000000 0 0
> > uart2_frac 1 1 1843200 0 0
> > sclk_uart2 1 1 1843200 0 0
>
> Just to make sure, I did boot-tests on a lot of different Rockchip socs
> (rk3036, rk3188, rk3288, rk3328, rk3399) with the serial console using
> 8250_dw and working normally on all of them with the most recent
> torvalds kernel (and everything I tested in the past)
>
> The only difference I see between our two clock dumps is the higher
> gpll clock on your board, but I cannot really imagine that this could be
> and issue.
>
> So I'm really puzzled by what you see on your board, but don't have
> any specific idea what to test right now.
>
>
> Heiko
Good news! I found the cause. It's the barebox bootloader that set the
pll_gpll to the weired 891000000. By manually setting the clock back to
594000000, it worked again! It's time to find the root cause in barebox
:-)
^ permalink raw reply [flat|nested] 13+ messages in thread
* [PATCH][RFC] 8250_dw: unregister dw8250_set_termios for rk3188 chip
@ 2017-11-20 14:49 Shuyu Wei
0 siblings, 0 replies; 13+ messages in thread
From: Shuyu Wei @ 2017-11-20 14:49 UTC (permalink / raw)
To: gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r
Cc: linux-rockchip-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-serial-u79uwXL29TY76Z2rM5mHXA
dw8250_set_termios is causing problems for rk3188 on my radxa board.
It's using a fixed clock at 24M, not baud*16 in dw8250_set_termios.
I'm not sure if other rk3xxx chips are facing the same problem.
Signed-off-by Wei Shuyu <wsy-flSAGy4ZnMjQT0dZR+AlfA@public.gmane.org>
---
drivers/tty/serial/8250/8250_dw.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/tty/serial/8250/8250_dw.c b/drivers/tty/serial/8250/8250_dw.c
index 5bb0c42c88dd..e760a5c1f3f6 100644
--- a/drivers/tty/serial/8250/8250_dw.c
+++ b/drivers/tty/serial/8250/8250_dw.c
@@ -340,6 +340,9 @@ static void dw8250_quirks(struct uart_port *p, struct dw8250_data *data)
data->skip_autocfg = true;
}
#endif
+ if (of_device_is_compatible(np, "rockchip,rk3188-uart")) {
+ p->set_termios = NULL;
+ }
if (of_device_is_big_endian(p->dev->of_node)) {
p->iotype = UPIO_MEM32BE;
p->serial_in = dw8250_serial_in32be;
--
2.15.0
^ permalink raw reply related [flat|nested] 13+ messages in thread
end of thread, other threads:[~2017-11-24 17:06 UTC | newest]
Thread overview: 13+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
[not found] <20171120144045.juwm64m2j736h5ps@home.dogben.com>
[not found] ` <d8ba3c8a-a406-cbee-d71b-d6784d6ebacc@sondrel.com>
[not found] ` <d8ba3c8a-a406-cbee-d71b-d6784d6ebacc-56FIPCJpnYtBDgjK7y7TUQ@public.gmane.org>
2017-11-20 16:14 ` [PATCH][RFC] 8250_dw: unregister dw8250_set_termios for rk3188 chip Shuyu Wei
[not found] ` <20171120161455.orvooleyzfsslon3-ZQaglsx1qnHXWvwwbwmGMg@public.gmane.org>
2017-11-20 16:26 ` Ed Blake
[not found] ` <0a4ce349-d386-0f1b-e973-e77af7f75d23-56FIPCJpnYtBDgjK7y7TUQ@public.gmane.org>
2017-11-20 17:51 ` Heiko Stübner
2017-11-21 3:09 ` Shuyu Wei
[not found] ` <20171121030949.a6bsapueiicdbonj-ZQaglsx1qnHXWvwwbwmGMg@public.gmane.org>
2017-11-21 10:23 ` Ed Blake
[not found] ` <4010bd84-7c88-5410-820f-bd3d04f1fbb5-56FIPCJpnYtBDgjK7y7TUQ@public.gmane.org>
2017-11-21 17:17 ` Shuyu Wei
[not found] ` <20171121171712.GA4462-ZQaglsx1qnHXWvwwbwmGMg@public.gmane.org>
2017-11-21 17:33 ` Ed Blake
[not found] ` <f834a0a4-3d1e-6f97-6ff3-1d52d609f510-56FIPCJpnYtBDgjK7y7TUQ@public.gmane.org>
2017-11-23 14:56 ` Shuyu Wei
[not found] ` <20171123145622.GA1272-ZQaglsx1qnHXWvwwbwmGMg@public.gmane.org>
2017-11-23 15:11 ` Heiko Stuebner
2017-11-23 15:40 ` Shuyu Wei
[not found] ` <20171123153922.GA23503-ZQaglsx1qnHXWvwwbwmGMg@public.gmane.org>
2017-11-23 23:34 ` Heiko Stuebner
2017-11-24 17:06 ` Shuyu Wei
2017-11-20 14:49 Shuyu Wei
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.