Re: [PATCH] drm/omap: Migrate minimum FCK/PCK ratio from Kconfig to dts

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Mon, Sep 30, 2019 at 8:54 AM Adam Ford <aford173@xxxxxxxxx> wrote:
>
> On Mon, Sep 30, 2019 at 8:39 AM H. Nikolaus Schaller <hns@xxxxxxxxxxxxx> wrote:
> >
> >
> > > Am 30.09.2019 um 10:53 schrieb Tero Kristo <t-kristo@xxxxxx>:
> > >
> > > The best action here is probably to drop the max-div value for this clock to 16. Can someone check this with their display setup and see what happens? Attached patch should do the trick.
> >
> > I have checked on GTA04 and OpenPandora (DM3730 resp. OMAP3430) and did not notice a negative effect.
> >
> > (Well, we never see the problem that is discussed here and have built with CONFIG_OMAP2_DSS_MIN_FCK_PER_PCK=0).
>
> I have never been able to use CONFIG_OMAP2_DSS_MIN_FCK_PER_PCK=0, but
> I assume it's either a function of pck or a combination of pck with
> the resolution.
>
> Based on Tomi's comment, I assume he's working on the following.  Can
> you also try:
>
> diff --git a/drivers/gpu/drm/omapdrm/dss/dss.c
> b/drivers/gpu/drm/omapdrm/dss/dss.c
> index 5711b7a720e6..5e584f32ea6a 100644
> --- a/drivers/gpu/drm/omapdrm/dss/dss.c
> +++ b/drivers/gpu/drm/omapdrm/dss/dss.c
> @@ -1090,7 +1090,7 @@ static const struct dss_features omap34xx_dss_feats = {
>
>  static const struct dss_features omap3630_dss_feats = {
>         .model                  =       DSS_MODEL_OMAP3,
> -       .fck_div_max            =       32,
> +       .fck_div_max            =       16,
>         .fck_freq_max           =       173000000,
>         .dss_fck_multiplier     =       1,
>         .parent_clk_name        =       "dpll4_ck",
>
>
> Hopefully it doesn't break the 3630 for you, but it fixed my issue
> with no back trace:
>
> [    9.915588] DSS: set fck to 54000000
> [    9.915618] DISPC: lck = 54000000 (1)
> [    9.915649] DISPC: pck = 9000000 (6)
> [    9.917633] DISPC: channel 0 xres 480 yres 272
> [    9.917663] DISPC: pck 9000000
>
> I do wonder, however if there is a divider that is higher than 16, but
> lower than 32.
> I was able to run fck at 36MHz before with divide by 4 to 9MHz, so I
> am hoping that by running at 54MHz / 6 doesn't draw more power.  I was
> reading through the datasheet, but I could not find any reference to
> the max divider.
>

For run, I tested a max divider of 27, and I was able to get it
functional with a slower fck

[    9.939056] DSS: set fck to 36000000
[    9.939086] DISPC: lck = 36000000 (1)
[    9.939086] DISPC: pck = 9000000 (4)
[    9.941314] DISPC: channel 0 xres 480 yres 272
[    9.941314] DISPC: pck 9000000
[    9.941314] DISPC: hsync_len 42 hfp 3 hbp 2 vsw 11 vfp 2 vbp 3
[    9.941314] DISPC: vsync_level 1 hsync_level 1 data_pclk_edge 1
de_level 1 sync_pclk_edge -1
[    9.941345] DISPC: hsync 17077Hz, vsync 59Hz


I don't know the implications, so if the people from TI say stick with
16, I'm fine with that, but at least there is some evidence that it
can be higher than 16, but lower than 32.

adam

> adam
> >
> > BR,
> > Nikolaus
> >



[Index of Archives]     [Linux Arm (vger)]     [ARM Kernel]     [ARM MSM]     [Linux Tegra]     [Linux WPAN Networking]     [Linux Wireless Networking]     [Maemo Users]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite Trails]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux