Re: rk3399: Graphical artifacts when running for-next

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

Regards,
Jonas



_______________________________________________
Linux-rockchip mailing list
Linux-rockchip@xxxxxxxxxxxxxxxxxxx
http://lists.infradead.org/mailman/listinfo/linux-rockchip




[Index of Archives]     [LM Sensors]     [Linux Sound]     [ALSA Users]     [ALSA Devel]     [Linux Audio Users]     [Linux Media]     [Kernel]     [Gimp]     [Yosemite News]     [Linux Media]

  Powered by Linux