linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: Maxime Ripard <maxime.ripard@bootlin.com>
To: Jagan Teki <jagan@amarulasolutions.com>
Cc: Mark Rutland <mark.rutland@arm.com>,
	devicetree <devicetree@vger.kernel.org>,
	David Airlie <airlied@linux.ie>,
	Michael Turquette <mturquette@baylibre.com>,
	linux-sunxi <linux-sunxi@googlegroups.com>,
	linux-kernel <linux-kernel@vger.kernel.org>,
	dri-devel <dri-devel@lists.freedesktop.org>,
	Chen-Yu Tsai <wens@csie.org>, Rob Herring <robh+dt@kernel.org>,
	Daniel Vetter <daniel@ffwll.ch>,
	Michael Trimarchi <michael@amarulasolutions.com>,
	linux-amarula@amarulasolutions.com,
	linux-clk <linux-clk@vger.kernel.org>,
	linux-arm-kernel <linux-arm-kernel@lists.infradead.org>
Subject: Re: [PATCH v6 11/22] clk: sunxi-ng: a64: Add minimum rate for PLL_MIPI
Date: Fri, 1 Feb 2019 15:31:02 +0100	[thread overview]
Message-ID: <20190201143102.rcvrxstc365mezvx@flea> (raw)
In-Reply-To: <CAMty3ZAjAoti8Zu80c=OyCA+u-jtQnkidsKSNz_c2OaRswqc3w@mail.gmail.com>


[-- Attachment #1.1: Type: text/plain, Size: 7547 bytes --]

On Tue, Jan 29, 2019 at 11:01:31PM +0530, Jagan Teki wrote:
> On Tue, Jan 29, 2019 at 8:43 PM Maxime Ripard <maxime.ripard@bootlin.com> wrote:
> >
> > 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@bootlin.com> 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@amarulasolutions.com>
> > > > > Acked-by: Stephen Boyd <sboyd@kernel.org>
> > > >
> > > > 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
> 
> Ahh.. I thought this initially but as far as DSI clock computation is
> concern, the L12 tcon_div is local variable which is used for edge0
> computation in burst mode and not for the dsi clock computation. Since
> the BSP is unable to get the tcon_div during edge0 computation, they
> defined it locally I think.
> 
> You can see the lcd_clk_config() code [2], where we can see DSI clock
> computation using dsi_div value.
> 
> Here is dump after the in Line 792 which is after computation[3]
> [   10.800737] lcd_clk_config: dsi_div = 6, tcon_div = 4, lcd_div = 1
> [   10.800743] lcd_clk_config: lcd_dclk_freq = 55, dclk_rate = 55000000
> [   10.800749] lcd_clk_config: lcd_rate = 330000000, pll_rate = 330000000
> 
> The above dump the lcd_rate 330MHz is computed with panel clock, 55MHz
> into dsi_div 6. So this can be our actual divider values dclk_min_div,
> dclk_max_div in sun4i_dclk_round_rate (from
> drivers/gpu/drm/sun4i/sun4i_dotclock.c)

I wish it was in your commit log in the first place, instead of having
to exchange multiple mails over this.

However, I don't think that's quite true, and it might be a bug in
Allwinner's implementation (or rather something quite confusing).

You're right that the lcd_rate and pll_rate seem to be generated from
the pixel clock, and it indeed looks like the ratio between the pixel
clock and the TCON dotclock is defined through the number of bits per
lanes.

However, in this case, dsi_rate is actually the same than lcd_rate,
since pll_rate is going to be divided by dsi_div:
https://github.com/BPI-SINOVOIP/BPI-M64-bsp/blob/master/linux-sunxi/drivers/video/sunxi/disp2/disp/de/disp_lcd.c#L791

Since lcd_div is 1, it also means that in this case, dsi_rate ==
dclk_rate.

The DSI module clock however, is always set to 148.5 MHz. Indeed, if
we look at:
https://github.com/BPI-SINOVOIP/BPI-M64-bsp/blob/master/linux-sunxi/drivers/video/sunxi/disp2/disp/de/disp_lcd.c#L804

We can see that the rate in clk_info is used if it's different than
0. This is filled by disp_al_lcd_get_clk_info, which, in the case of a
DSI panel, will hardcode it to 148.5 MHz:
https://github.com/BPI-SINOVOIP/BPI-M64-bsp/blob/master/linux-sunxi/drivers/video/sunxi/disp2/disp/de/lowlevel_sun50iw1/disp_al.c#L164

So, the DSI clock is set to this here:
https://github.com/BPI-SINOVOIP/BPI-M64-bsp/blob/master/linux-sunxi/drivers/video/sunxi/disp2/disp/de/disp_lcd.c#L805

The TCON *module* clock (the one in the clock controller) has been set
to lcd_rate (so the pixel clock times the number of bits per lane) here:
https://github.com/BPI-SINOVOIP/BPI-M64-bsp/blob/master/linux-sunxi/drivers/video/sunxi/disp2/disp/de/disp_lcd.c#L800

And the PLL has been set to the same rate here:
https://github.com/BPI-SINOVOIP/BPI-M64-bsp/blob/master/linux-sunxi/drivers/video/sunxi/disp2/disp/de/disp_lcd.c#L794

Let's take a step back now: that function we were looking at,
lcd_clk_config, is called by lcd_clk_enable, which is in turn called
by disp_lcd_enable here:
https://github.com/BPI-SINOVOIP/BPI-M64-bsp/blob/master/linux-sunxi/drivers/video/sunxi/disp2/disp/de/disp_lcd.c#L1328

The next function being called is disp_al_lcd_cfg, and that function
will hardcode the TCON dotclock divider to 4, here:
https://github.com/BPI-SINOVOIP/BPI-M64-bsp/blob/master/linux-sunxi/drivers/video/sunxi/disp2/disp/de/lowlevel_sun50iw1/disp_al.c#L240

So, in the end, the dotclock divider is always 4, the DSI module clock
is set to 148.5 MHz, and the TCON module clock is set to 330MHz. Since
the TCON module clock doesn't have a divider, the PLL is set at that
same value but this is redundant.

I'll experiment with this and try to see how it works on the A33.

Maxime

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

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

[-- Attachment #2: Type: text/plain, Size: 176 bytes --]

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  reply	other threads:[~2019-02-01 14:31 UTC|newest]

Thread overview: 66+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-01-24 19:58 [PATCH v6 00/22] drm/sun4i: Allwinner A64 MIPI-DSI support Jagan Teki
2019-01-24 19:58 ` [PATCH v6 01/22] drm/sun4i: sun6i_mipi_dsi: Compute burst mode loop N1 instruction delay Jagan Teki
2019-01-24 19:58 ` [PATCH v6 02/22] drm/sun4i: sun6i_mipi_dsi: Support instruction loop selection Jagan Teki
2019-01-24 19:58 ` [PATCH v6 03/22] drm/sun4i: sun6i_mipi_dsi: Setup burst mode timings Jagan Teki
2019-01-24 19:58 ` [PATCH v6 04/22] drm/sun4i: sun6i_mipi_dsi: Simplify drq to support all modes Jagan Teki
2019-01-24 19:58 ` [PATCH v6 05/22] drm/sun4i: tcon: Export get tcon0 routine Jagan Teki
2019-01-24 19:58 ` [PATCH v6 06/22] drm/sun4i: sun6i_mipi_dsi: Probe tcon0 during dsi_bind Jagan Teki
2019-01-24 19:58 ` [PATCH v6 07/22] drm/sun4i: sun6i_mipi_dsi: Setup burst mode Jagan Teki
2019-01-24 19:58 ` [PATCH v6 08/22] drm/sun4i: sun6i_mipi_dsi: Enable 2byte trail for 4-lane " Jagan Teki
2019-01-24 19:58 ` [PATCH v6 09/22] drm/sun4i: sun6i_mipi_dsi: Enable burst mode HBP, HSA_HSE Jagan Teki
2019-01-24 19:58 ` [PATCH v6 10/22] clk: sunxi-ng: Add check for minimal rate to NKM PLLs Jagan Teki
2019-01-24 19:58 ` [PATCH v6 11/22] clk: sunxi-ng: a64: Add minimum rate for PLL_MIPI Jagan Teki
2019-01-25 21:24   ` Maxime Ripard
2019-01-28  9:36     ` Jagan Teki
2019-01-29 15:13       ` Maxime Ripard
2019-01-29 17:31         ` Jagan Teki
2019-02-01 14:31           ` Maxime Ripard [this message]
2019-02-01 16:33             ` Jagan Teki
2019-02-11 14:07             ` Jagan Teki
2019-02-12  9:30               ` Maxime Ripard
2019-02-12  9:38                 ` Jagan Teki
2019-05-24 10:07             ` Jagan Teki
2019-06-05  6:49               ` Maxime Ripard
2019-06-05  7:33                 ` Jagan Teki
2019-06-14 14:24                   ` Maxime Ripard
2019-06-20 18:27                     ` Jagan Teki
2019-06-25 14:49                       ` Maxime Ripard
2019-06-25 15:30                         ` Jagan Teki
2019-07-03 11:49                           ` Maxime Ripard
2019-07-05 17:52                             ` Michael Nazzareno Trimarchi
2019-07-11 10:01                               ` Maxime Ripard
2019-07-11 17:43                                 ` Michael Nazzareno Trimarchi
2019-07-11 19:34                                   ` Michael Nazzareno Trimarchi
2019-07-20  6:58                                   ` Maxime Ripard
2019-07-20  7:16                                     ` Jagan Teki
2019-07-20  7:34                                       ` Jagan Teki
2019-07-20  9:32                                       ` Maxime Ripard
2019-07-20  9:42                                         ` Michael Nazzareno Trimarchi
2019-07-22 10:21                                         ` Jagan Teki
2019-07-22 10:25                                           ` Michael Nazzareno Trimarchi
2019-07-22 10:38                                             ` Jagan Teki
2019-07-24  9:05                                           ` Maxime Ripard
2019-07-29  6:59                                             ` Michael Nazzareno Trimarchi
2019-08-02  8:38                                               ` Michael Nazzareno Trimarchi
2019-08-13  6:05                                               ` Maxime Ripard
2019-08-15 12:25                                                 ` Michael Nazzareno Trimarchi
2019-08-28 13:03                                                   ` Maxime Ripard
2019-08-28 13:09                                                     ` Michael Nazzareno Trimarchi
2019-01-24 19:58 ` [PATCH v6 12/22] dt-bindings: sun6i-dsi: Add VCC-DSI supply property Jagan Teki
2019-01-25 15:47   ` Maxime Ripard
2019-01-24 19:58 ` [PATCH v6 13/22] drm/sun4i: sun6i_mipi_dsi: Add support for VCC-DSI voltage regulator Jagan Teki
2019-01-24 19:58 ` [PATCH v6 14/22] dt-bindings: sun6i-dsi: Add A64 DSI compatible (w/ A31 fallback) Jagan Teki
2019-01-25 15:52   ` Maxime Ripard
2019-01-26 16:09     ` [linux-sunxi] " Jagan Teki
2019-01-29 14:54       ` Maxime Ripard
2019-01-24 19:58 ` [PATCH v6 15/22] dt-bindings: sun6i-dsi: Add A64 DPHY " Jagan Teki
2019-01-25 15:52   ` Maxime Ripard
2019-01-24 19:58 ` [PATCH v6 16/22] arm64: dts: allwinner: a64: Add DSI pipeline Jagan Teki
2019-01-25 18:51   ` Maxime Ripard
2019-01-24 19:58 ` [DO NOT MERGE] [PATCH v6 17/22] arm64: allwinner: a64: pine64-lts: Enable Feiyang FY07024DI26A30-D DSI panel Jagan Teki
2019-01-24 19:58 ` [PATCH v6 18/22] drm/sun4i: sun6i_mipi_dsi: Add DSI Generic short write 2 param transfer Jagan Teki
2019-01-24 19:58 ` [DO NOT MERGE] [PATCH v6 19/22] arm64: dts: allwinner: bananapi-m64: Bananapi S070WV20-CT16 DSI panel Jagan Teki
2019-01-24 19:58 ` [PATCH v6 20/22] drm/sun4i: sun6i_mipi_dsi: Fix DSI hbp timing value Jagan Teki
2019-01-24 19:58 ` [PATCH v6 21/22] drm/sun4i: sun6i_mipi_dsi: Fix DSI hfp " Jagan Teki
2019-01-24 19:59 ` [PATCH v6 22/22] arm64: dts: allwinner: a64-amarula-relic: Add Techstar TS8550B MIPI-DSI panel Jagan Teki
2019-01-24 23:12 ` [PATCH v6 00/22] drm/sun4i: Allwinner A64 MIPI-DSI support Merlijn Wajer

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20190201143102.rcvrxstc365mezvx@flea \
    --to=maxime.ripard@bootlin.com \
    --cc=airlied@linux.ie \
    --cc=daniel@ffwll.ch \
    --cc=devicetree@vger.kernel.org \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=jagan@amarulasolutions.com \
    --cc=linux-amarula@amarulasolutions.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-clk@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-sunxi@googlegroups.com \
    --cc=mark.rutland@arm.com \
    --cc=michael@amarulasolutions.com \
    --cc=mturquette@baylibre.com \
    --cc=robh+dt@kernel.org \
    --cc=wens@csie.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).