Re: [PATCH v6 11/22] clk: sunxi-ng: a64: Add minimum rate for PLL_MIPI

From: Maxime Ripard
Date: Tue Jan 29 2019 - 10:13:56 EST


On Mon, Jan 28, 2019 at 03:06:10PM +0530, Jagan Teki wrote:
> On Sat, Jan 26, 2019 at 2:54 AM Maxime Ripard <maxime.ripard@xxxxxxxxxxx> wrote:
> >
> > On Fri, Jan 25, 2019 at 01:28:49AM +0530, Jagan Teki wrote:
> > > Minimum PLL used for MIPI is 500MHz, as per manual, but
> > > lowering the min rate by 300MHz can result proper working
> > > nkms divider with the help of desired dclock rate from
> > > panel driver.
> > >
> > > Signed-off-by: Jagan Teki <jagan@xxxxxxxxxxxxxxxxxxxx>
> > > Acked-by: Stephen Boyd <sboyd@xxxxxxxxxx>
> >
> > Going 200MHz below the minimum doesn't seem really reasonable. What
> > is the issue that you are trying to fix here?
> >
> > It looks like it's picking bad dividers, but if that's the case, this
> > isn't the proper fix.
>
> As I stated in earlier patches, the whole idea is pick the desired
> dclk divider based dclk rate. So the dotclock, sun4i_dclk_round_rate
> is unable to get the proper dclk divider at the end, so it eventually
> picking up wrong divider value and fired vblank timeout.
>
> So, we come-up with optimal and working min_rate 300MHz in pll-mipi to
> get the desired clock something like below.
> [ 2.415773] [drm] No driver support for vblank timestamp query.
> [ 2.424116] sun4i_dclk_round_rate: min_div = 4 max_div = 127, rate = 55000000
> [ 2.424172] ideal = 220000000, rounded = 0
> [ 2.424176] ideal = 275000000, rounded = 0
> [ 2.424194] ccu_nkm_round_rate: rate = 330000000
> [ 2.424197] ideal = 330000000, rounded = 330000000
> [ 2.424201] sun4i_dclk_round_rate: div = 6 rate = 55000000
> [ 2.424205] sun4i_dclk_round_rate: min_div = 4 max_div = 127, rate = 55000000
> [ 2.424209] ideal = 220000000, rounded = 0
> [ 2.424213] ideal = 275000000, rounded = 0
> [ 2.424230] ccu_nkm_round_rate: rate = 330000000
> [ 2.424233] ideal = 330000000, rounded = 330000000
> [ 2.424236] sun4i_dclk_round_rate: div = 6 rate = 55000000
> [ 2.424253] ccu_nkm_round_rate: rate = 330000000
> [ 2.424270] ccu_nkm_round_rate: rate = 330000000
> [ 2.424278] sun4i_dclk_recalc_rate: val = 1, rate = 330000000
> [ 2.424281] sun4i_dclk_recalc_rate: val = 1, rate = 330000000
> [ 2.424306] ccu_nkm_set_rate: rate = 330000000, parent_rate = 297000000
> [ 2.424309] ccu_nkm_set_rate: _nkm.n = 5
> [ 2.424311] ccu_nkm_set_rate: _nkm.k = 2
> [ 2.424313] ccu_nkm_set_rate: _nkm.m = 9
> [ 2.424661] sun4i_dclk_set_rate div 6
> [ 2.424668] sun4i_dclk_recalc_rate: val = 6, rate = 55000000
>
> But look like this wouldn't valid for all other dclock rates, say BPI
> panel has 30MHz clock that would failed with this logic.
>
> On the other side Allwinner BSP calculating dclk divider based on the
> SoC's. for A33 [1] it is fixed dclk divider of 4 and for A64 is is
> calculated based on the bpp/lanes.

It looks like the A64 has the same divider of 4:
https://github.com/BPI-SINOVOIP/BPI-M64-bsp/blob/master/linux-sunxi/drivers/video/sunxi/disp2/disp/de/lowlevel_sun50iw1/de_dsi.c#L12

I think you're confusing it with the ratio between the pixel clock and
the dotclock, called dsi_div:
https://github.com/BPI-SINOVOIP/BPI-M64-bsp/blob/master/linux-sunxi/drivers/video/sunxi/disp2/disp/de/lowlevel_sun50iw1/disp_al.c#L198

Maxime

--
Maxime Ripard, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

Attachment: signature.asc
Description: PGP signature