Message-ID: <23eba53a-9304-2ceb-d97e-01891ec0b3ed@ti.com>
Date:   Mon, 30 Sep 2019 09:45:07 +0300
From:   Tomi Valkeinen <tomi.valkeinen@...com>
To:     Tero Kristo <t-kristo@...com>, Adam Ford <aford173@...il.com>
CC:     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

Hi,

On 27/09/2019 18:47, Tomi Valkeinen wrote:
> On 27/09/2019 18:37, Tero Kristo wrote:
> 
>> If you can provide details about what clock framework / driver does 
>> wrong (sample clk_set_xyz call sequence, expected results via 
>> clk_get_xyz, and what fails), I can take a look at it. Just reporting 
>> arbitrary display driver issues I won't be able to debug at all (I 
>> don't have access to any of the displays, nor do I want to waste time 
>> debugging them without absolutely no knowledge whatsoever.)
> 
> I used your hack patches to allow changing rates via debugfs. And set 
> dss1_alwon_fck_3430es2 to 27000000 or 27870967. The end result was that 
> DSS gets some very high clock from dss1_alwon_fck_3430es2, as the frame 
> rate jumps to many hundreds fps.
> 
> So, these numbers are not real, but to give the idea what I saw. Running 
> first with 50 MHz, I can see, say, 40 fps. Then I set the clock to 30 
> MHz, and fps dropped to, say, 30fps, as expected with lower clock. Then 
> I set the clock to 27MHz (or the other one), expecting a bit lower fps, 
> but instead I saw hundreds of fps.
> 
> I don't know if there's any other way to observe the wrong clock rate 
> but have the dss enabled and running kmstest or similar. I can help you 
> set that up next week, should be trivial. You don't need a display for 
> that.

Here's how to reproduce. I have the attached patches. Three of them are 
the clk-debug ones, and one of mine to make it easy to test without a 
display, and without underflow flood halting the device. There are on 
top of v5.3. Kernel config also attached.

kmstest is from kms++ project (https://github.com/tomba/kmsxx). It 
should be straightforward to compile, but kmstest binary is also 
included in TI's rootfs.

I boot up, and run this in one terminal:

# kmstest -c dvi -r 640x480 --flip

It shows ~60 fps, as expected:

Connector 0: fps 60.499982, slowest 16.72 ms

In another terminal:

# cd /debug/clk/dss1_alwon_fck_3430es2/
# cat clk_rate
50823530
# echo 30000000 > clk_rate

Now with lower clock, the fps dropped as expected:

Connector 0: fps 35.468961, slowest 28.41 ms

Then:

# echo 27000000 > clk_rate

And fps goes through the roof and underflows start to come:

Connector 0: fps 514.734527, slowest 2.11 ms

I don't know what exactly goes on here, but 514 fps matches quite 
exactly the PLL/2 rate:

864000000/2/2/((640+16+96+48)*(480+10+2+33)) = 514.2857142857143

(The second /2 there is DSS's internal pclk divider)

  Tomi

-- 
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki

View attachment "0001-clk-debug-add-support-for-setting-clk_rate-from-debu.patch" of type "text/x-patch" (1763 bytes)

View attachment "0002-sci-clk-debug-add-reparenting-support-via-debugfs.patch" of type "text/x-patch" (2017 bytes)

View attachment "0003-clk-debug-add-support-for-enabling-preparing-clocks-.patch" of type "text/x-patch" (3178 bytes)

View attachment "0004-dss1_alwon_fck_3430es2-test-hacks.patch" of type "text/x-patch" (1971 bytes)

View attachment "tomi-config" of type "text/plain" (128074 bytes)

Powered by blists - more mailing lists