Re: rk3399: Graphical artifacts when running for-next

[Robert Foss <robert.foss-ZGY8ohtN/8qB+jHODAdFcQ@public.gmane.org>]

On 2/21/19 4:53 PM, Heiko Stuebner wrote:
> Am Donnerstag, 21. Februar 2019, 16:46:19 CET schrieb Robert Foss:
>>
>> On 2/21/19 2:26 PM, Heiko Stuebner wrote:
>>> Hi Robert,
>>>
>>> Am Donnerstag, 21. Februar 2019, 11:27:15 CET schrieb Robert Foss:
>>>> Hey Heiko,
>>>>
>>>> I've just started booting the RK3399 based Radxa Rock Pi 4 on the mainline
>>>> kernel. Specifically on linux-rockchip/for-next, with an additional patch
>>>> adding the GPU DT node[1].
>>>>
>>>> Unfortunately I'm seeing an artifact on all display output[2].
>>>> It, from the VT to 3D content.
>>>>
>>>> Is this an issue that has been encountered before?
>>>
>>> I haven't seen something like this before. I do test graphics
>>> on most Rockchip socs regularly (right now dw-hdmi only
>>> on non-rk3399 socs though).
>>>
>>> Did you try full linux-next as well? My for-next branch obviously
>>> only carries dt/soc-driver stuff but not things like drm-misc.
>>>
>>> One possible issue might be the generated clocks. You could check
>>> $debug/clk/clk_summary for the dclk_vopX to see if that matches
>>> the suggested clock for the mode. (For example check the requested
>>> rate in rockchip_vop.c against what it actually gets).
>>>
>>
>> I had a look using the current linux-next/master, and I'm seeing the same results.
>> Commit: 550f4769c7c4 - Add linux-next specific files for 20190221
>>
>>
>> I had also look at the debugfs output:
>> # cat /sys/kernel/debug/clk/clk_summary | grep dclk_vop
>>     dclk_vop0_div    0 1 0 27000000  0 0  50000
>>       dclk_vop0      0 2 0 27000000  0 0 50000
>>       dclk_vop0_frac 0 0 0 1350000   0 0 50000
>>     dclk_vop1_div    1 1 0 59400000  0 0 50000
>>       dclk_vop1      2 2 0 59400000  0 0 50000
>>       dclk_vop1_frac 0 0 0 2970000   0 0 50000
>>
>> But I can't find a file named rockchip_vop.c exactly. And I'm not entirely sure
>> about how to decipher the expected values from the driver.
> 
> drivers/gpu/drm/rockchip_drm_vop.c (my memory of the filename was faulty
> it seems). As for comparing to the expected rate, I guess the easiest
> way would be to just insert a printk into vop_crtc_mode_fixup()
> after the clk_round_rate call, outputting both the requested and
> calculated rate and then looking that up in the dmesg.

dmesg:
vop_crtc_mode_fixup() mode->clock=65000000  adjusted_mode->clock=61538000

Is the adjusted clock withing the reasonable range?


Additionally I've had a look at the libdrm modetest util, and it is reporting
far fewer modes than what I would expect on my 4k monitor.

As an added note, I have this board+monitor working using proprietary drivers, 
and up to 4k resolutions.

trying to open device 'rockchip'...done
Encoders:
id      crtc    type    possible crtcs  possible clones
44      34      TMDS    0x00000003      0x00000000

Connectors:
id      encoder status          name            size (mm)       modes   encoders
45      44      connected       HDMI-A-1        0x0             3       44
   modes:
         name refresh (Hz) hdisp hss hse htot vdisp vss vse vtot)
   1024x768 60 1024 1048 1184 1344 768 771 777 806 65000 flags: nhsync, nvsync; 
type: driver
   800x600 60 800 840 968 1056 600 601 605 628 40000 flags: phsync, pvsync; 
type: driver
   800x600 56 800 824 896 1024 600 601 603 625 36000 flags: phsync, pvsync; 
type: driver



Rob.