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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAHCN7x+vCfPTRE+zzYUwAXdbBzRotTP2hSOgsHB0FdgBhZV5zA@mail.gmail.com>
Date:   Mon, 30 Sep 2019 09:04:18 -0500
From:   Adam Ford <aford173@...il.com>
To:     "H. Nikolaus Schaller" <hns@...delico.com>
Cc:     Tero Kristo <t-kristo@...com>,
        Tomi Valkeinen <tomi.valkeinen@...com>,
        Tony Lindgren <tony@...mide.com>,
        Linux-OMAP <linux-omap@...r.kernel.org>,
        Adam Ford <adam.ford@...icpd.com>,
        Benoît Cousson <bcousson@...libre.com>,
        dri-devel <dri-devel@...ts.freedesktop.org>,
        devicetree <devicetree@...r.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] drm/omap: Migrate minimum FCK/PCK ratio from Kconfig to dts

On Mon, Sep 30, 2019 at 8:54 AM Adam Ford <aford173@...il.com> wrote:
>
> On Mon, Sep 30, 2019 at 8:39 AM H. Nikolaus Schaller <hns@...delico.com> wrote:
> >
> >
> > > Am 30.09.2019 um 10:53 schrieb Tero Kristo <t-kristo@...com>:
> > >
> > > 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
> >