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