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 :-) -- To unsubscribe from this list: send the line "unsubscribe linux-serial" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
