Re: rk3399: Graphical artifacts when running for-next

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

On 2/22/19 10:30 AM, Jonas Karlman wrote:
> On 2019-02-22 09:45, Robert Foss wrote:
>>
>> On 2/22/19 9:41 AM, Robert Foss wrote:
>>> Hey Jonas,
>>>
>>> On 2/21/19 9:29 PM, Jonas Karlman wrote:
>>>> On 2019-02-21 20:42, Robert Foss wrote:
>>>>> On 2/21/19 8:15 PM, Ezequiel Garcia wrote:
>>>>>> Folks,
>>>>>>
>>>>>> On Thu, 2019-02-21 at 20:08 +0100, Robert Foss wrote:
>>>>>> [..]
>>>>>>
>>>>>> The clock debugging is obviously good research.
>>>>>>
>>>>>>>> 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.
>>>>>>>>
>>>>>> That said, this is also worth looking into.
>>>>>> I'm curious, is the EDID the kernel getting OK?
>>>>>>
>>>>> Given that modetest lists way too few modes, I would think
>>>>> there could be some EDID related issues.
>>>> It is more likely the issue is in dw_hdmi_rockchip_mode_valid(), it currently
>>>> filters out
>>>> any mode not defined in rockchip_mpll_cfg.
>>>> That method needs some changes to allow for 4k modes and fractal refresh rates.
>>>> E.g. for RK3328 it should probably check the inno-hdmi-phy clock rates.
>>>
>>> This seemed like a good suggetions, so I disabled the rockchip_mpll_cfg in
>>> dw_hdmi_rockchip_mode_valid(), and ran libdrm/modetest. I now have 5 modes.
>>> But no higher resolution ones, only low resolution ones that don't seem
>> s/, only low resolution ones that don't seem/./g
>>
>>> $ modetest
>>> [..]
>>> 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             5       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: [..]
>>>     800x600 60 800 840 968 1056 600 601 605 628 40000 flags: [..]
>>>     800x600 56 800 824 896 1024 600 601 603 625 36000 flags: [..]
>>>     848x480 60 848 864 976 1088 480 486 494 517 33750 flags: [..]
>>>     640x480 60 640 656 752 800 480 490 492 525 25175 flags: [...]
> 
> If you only get up to 1024x768 there is probably some issue with reading EDID.
> Does the EDID property in modetest show any content?
> 
> I have some code at [1] that will update EDID more often (work in progress for CEC and audio improvements),
> it will only affect the EDID property and won't add new modes from the detect callback.
> This has mainly been tested on RK3288/RK3328 and Allwinner H3 so far.
> 
> [1] https://github.com/Kwiboo/linux-rockchip/compare/8874c206d613dc575f5cb6e385e7a866020138d0...21b7ba23c14661f85f82b068af9a9510f7d5fb0a

You are entirely correct. A patch already submitted, but not merged yet fixes
this EDID issues for the RockPi4.

https://www.spinics.net/lists/arm-kernel/msg708359.html

> 
> Regards,
> Jonas
> 
>