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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <CAHCN7xJDV=R9Ysjhff7=mEXdciwPP_5LQbHwaUT8KvhSkLKw8A@mail.gmail.com>
Date:   Mon, 30 Sep 2019 09:12:26 -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 9:04 AM Adam Ford <aford173@...il.com> wrote:
>
> 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.
>

Sorry for all the spam, but I moved both of them to 31 from 32, and it
also seems to work successfully at 31.

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

Is it possible to use 31?

adam

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