Re: rk3399: Graphical artifacts when running for-next

Robert Foss
2019-02-21T19:08:47Z

+Eze

On 2/21/19 5:38 PM, Robert Foss wrote:
>
>
> 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.