rk3399: Graphical artifacts when running for-next

rk3399: Graphical artifacts when running for-next

[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?


[1] https://patchwork.kernel.org/patch/10817637/mbox/
[2] https://photos.app.goo.gl/ArffJ3785JSeQatW7


Rob.

Re: rk3399: Graphical artifacts when running for-next

[Heiko Stuebner]

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).

Heiko


> [1] https://patchwork.kernel.org/patch/10817637/mbox/
> [2] https://photos.app.goo.gl/ArffJ3785JSeQatW7
> 
> 
> Rob.
> 

Re: rk3399: Graphical artifacts when running for-next

[Michael Röding]

Hi Robert and Heiko,

On 21.02.19 14:26, 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).

for the record: I've seen exactly the same as Heiko on my Rock Pi 4 A
(2GB) using stock Arch Linux ARM Kernel (4.20.11) using dts from "arm64:
dts: rockchip: add ROCK Pi 4 DTS support" (v1 though).

As the dts is for 5.1, i was expecting some minor problems. But since
Heiko had the exact same artifacts i though i let you know that not him
alone.

Michael

> 
> 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).
> 
> Heiko
> 
> 
>> [1] https://patchwork.kernel.org/patch/10817637/mbox/
>> [2] https://photos.app.goo.gl/ArffJ3785JSeQatW7
>>
>>
>> Rob.
>>
> 
> 
> 
> 
> 
> _______________________________________________
> Linux-rockchip mailing list
> Linux-rockchip-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
> http://lists.infradead.org/mailman/listinfo/linux-rockchip
> 

Re: rk3399: Graphical artifacts when running for-next

[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.

> Heiko
> 
> 
>> [1] https://patchwork.kernel.org/patch/10817637/mbox/
>> [2] https://photos.app.goo.gl/ArffJ3785JSeQatW7
>>
>>
>> Rob.
>>
> 
> 
> 
> 

Re: rk3399: Graphical artifacts when running for-next

[Heiko Stuebner]

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.


Heiko

Re: rk3399: Graphical artifacts when running for-next

[Robert Foss]

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.

Re: rk3399: Graphical artifacts when running for-next

[Robert Foss]

+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.

Re: rk3399: Graphical artifacts when running for-next

[Ezequiel Garcia]

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?

Thanks!
Eze

Re: rk3399: Graphical artifacts when running for-next

[Robert Foss]

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.

> Thanks!
> Eze
> 

Re: rk3399: Graphical artifacts when running for-next

[Jonas Karlman]

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.

Best regards,
Jonas

>
>> Thanks!
>> Eze
>>
> _______________________________________________
> Linux-rockchip mailing list
> Linux-rockchip-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
> http://lists.infradead.org/mailman/listinfo/linux-rockchip

Re: rk3399: Graphical artifacts when running for-next

[Heiko Stuebner]

Am Donnerstag, 21. Februar 2019, 17:38:25 CET schrieb Robert Foss:
> 
> 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?

sadly, I have no real clue. I can cope with the hardware-centric parts like
making encoders somehow work, but I'm way out of my depth when it comes
to all this display-mode-voodoo.

> 
> 
> 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.

non-standard resolutions are still a bit of a problem I think.
The vendor kernel (and also the CrOS kernel) does contain quite a number
of hacks to make that work. (hacking up plls and the clock-tree, making
it quite non-generic).

But yes, it seems that you only get 3 modes? That are way to few I think.
My display at least  manages to get its 1080p native resolution, but I'm
also in the bind of having only this one display, so cannot really test
the more non-standard (or higher resolution) stuff.

Do you happen to have any other display you could attach to just compare
what happens?


Heiko

> 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.
> 

Re: rk3399: Graphical artifacts when running for-next

[Ezequiel Garcia]

On Thu, 2019-02-21 at 22:48 +0100, Heiko Stuebner wrote:
> Am Donnerstag, 21. Februar 2019, 17:38:25 CET schrieb Robert Foss:
> > 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?
> 
> sadly, I have no real clue. I can cope with the hardware-centric parts like
> making encoders somehow work, but I'm way out of my depth when it comes
> to all this display-mode-voodoo.
> 
> > 
> > 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.
> 
> non-standard resolutions are still a bit of a problem I think.
> The vendor kernel (and also the CrOS kernel) does contain quite a number
> of hacks to make that work. (hacking up plls and the clock-tree, making
> it quite non-generic).
> 
> But yes, it seems that you only get 3 modes? That are way to few I think.
> My display at least  manages to get its 1080p native resolution, but I'm
> also in the bind of having only this one display, so cannot really test
> the more non-standard (or higher resolution) stuff.
> 
> Do you happen to have any other display you could attach to just compare
> what happens?
> 
> 

FWIW, I have a Samsung (old?) TV, and on the same board as Robert's,
with the same kernel and rootfs, I don't have any issues.

Re: rk3399: Graphical artifacts when running for-next

[Heiko Stuebner]

Am Donnerstag, 21. Februar 2019, 22:52:39 CET schrieb Ezequiel Garcia:
> On Thu, 2019-02-21 at 22:48 +0100, Heiko Stuebner wrote:
> > Am Donnerstag, 21. Februar 2019, 17:38:25 CET schrieb Robert Foss:
> > > 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?
> > 
> > sadly, I have no real clue. I can cope with the hardware-centric parts like
> > making encoders somehow work, but I'm way out of my depth when it comes
> > to all this display-mode-voodoo.
> > 
> > > 
> > > 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.
> > 
> > non-standard resolutions are still a bit of a problem I think.
> > The vendor kernel (and also the CrOS kernel) does contain quite a number
> > of hacks to make that work. (hacking up plls and the clock-tree, making
> > it quite non-generic).
> > 
> > But yes, it seems that you only get 3 modes? That are way to few I think.
> > My display at least  manages to get its 1080p native resolution, but I'm
> > also in the bind of having only this one display, so cannot really test
> > the more non-standard (or higher resolution) stuff.
> > 
> > Do you happen to have any other display you could attach to just compare
> > what happens?
> > 
> > 
> 
> FWIW, I have a Samsung (old?) TV, and on the same board as Robert's,
> with the same kernel and rootfs, I don't have any issues.

could you also take a look at the timing both requested and real
clock rate?

Re: rk3399: Graphical artifacts when running for-next

[Robert Foss]

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

$ 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: [...]

Re: rk3399: Graphical artifacts when running for-next

[Robert Foss]

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: [...]

Re: rk3399: Graphical artifacts when running for-next

[Jonas Karlman]

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

Re: rk3399: Graphical artifacts when running for-next

[Robert Foss]

Hey again,

I found the issue, and it has been solved by Ezequiel
before me.

A DDC I2C bus specifier is required for DDC EDID probing to work
properly.

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

Thanks for participating in this goose-chase with me.


Rob.

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
> 
> $ 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: [...]

Re: rk3399: Graphical artifacts when running for-next

[Heiko Stuebner]

Am Freitag, 22. Februar 2019, 10:32:53 CET schrieb Robert Foss:
> Hey again,
> 
> I found the issue, and it has been solved by Ezequiel
> before me.

cool that it's working for you now.

> A DDC I2C bus specifier is required for DDC EDID probing to work
> properly.
> 
> https://www.spinics.net/lists/arm-kernel/msg708359.html

That patch is still sitting in my to-review queue, I should be
picking it as fix for 5.1 some time this week.

> Thanks for participating in this goose-chase with me.

You could provide a Tested-by tag for it :-D

Heiko

> 
> 
> Rob.
> 
> 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
> > 
> > $ 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: [...]
> 

Re: rk3399: Graphical artifacts when running for-next

[Robert Foss]

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
> 
> 

Re: rk3399: Graphical artifacts when running for-next

[Robert Foss]

On 2/22/19 10:38 AM, Heiko Stuebner wrote:
> Am Freitag, 22. Februar 2019, 10:32:53 CET schrieb Robert Foss:
>> Hey again,
>>
>> I found the issue, and it has been solved by Ezequiel
>> before me.
> 
> cool that it's working for you now.
> 
>> A DDC I2C bus specifier is required for DDC EDID probing to work
>> properly.
>>
>> https://www.spinics.net/lists/arm-kernel/msg708359.html
> 
> That patch is still sitting in my to-review queue, I should be
> picking it as fix for 5.1 some time this week.
> 
>> Thanks for participating in this goose-chase with me.
> 
> You could provide a Tested-by tag for it :-D

I would! I don't have that patch in my inbox however :F


Rob.

Re: rk3399: Graphical artifacts when running for-next

[Heiko Stuebner]

Am Freitag, 22. Februar 2019, 12:02:29 CET schrieb Robert Foss:
> 
> On 2/22/19 10:38 AM, Heiko Stuebner wrote:
> > Am Freitag, 22. Februar 2019, 10:32:53 CET schrieb Robert Foss:
> >> Hey again,
> >>
> >> I found the issue, and it has been solved by Ezequiel
> >> before me.
> > 
> > cool that it's working for you now.
> > 
> >> A DDC I2C bus specifier is required for DDC EDID probing to work
> >> properly.
> >>
> >> https://www.spinics.net/lists/arm-kernel/msg708359.html
> > 
> > That patch is still sitting in my to-review queue, I should be
> > picking it as fix for 5.1 some time this week.
> > 
> >> Thanks for participating in this goose-chase with me.
> > 
> > You could provide a Tested-by tag for it :-D
> 
> I would! I don't have that patch in my inbox however :F

I guess this thread is public enough on the linux-rockchip list,
so I could transplant such a tag from here ;-)

So I guess it is ok to add a
Tested-by: Robert Foss <robert.foss-ZGY8ohtN/8qB+jHODAdFcQ@public.gmane.org>
to the ddc patch from Ezequiel, right?

Heiko

Re: rk3399: Graphical artifacts when running for-next

[Ezequiel Garcia]

On Fri, 2019-02-22 at 12:02 +0100, Robert Foss wrote:
> 
> On 2/22/19 10:38 AM, Heiko Stuebner wrote:
> > Am Freitag, 22. Februar 2019, 10:32:53 CET schrieb Robert Foss:
> > > Hey again,
> > > 
> > > I found the issue, and it has been solved by Ezequiel
> > > before me.
> > 
> > cool that it's working for you now.
> > 
> > > A DDC I2C bus specifier is required for DDC EDID probing to work
> > > properly.
> > > 
> > > https://www.spinics.net/lists/arm-kernel/msg708359.html
> > 
> > That patch is still sitting in my to-review queue, I should be
> > picking it as fix for 5.1 some time this week.
> > 
> > > Thanks for participating in this goose-chase with me.
> > 
> > You could provide a Tested-by tag for it :-D
> 
> I would! I don't have that patch in my inbox however :F
> 
> 

I can try redirecting the patch.

Re: rk3399: Graphical artifacts when running for-next

[Doug Anderson]

Hi,

On Thu, Feb 21, 2019 at 1:49 PM Heiko Stuebner <heiko-4mtYJXux2i+zQB+pC5nmwQ@public.gmane.org> wrote:
> non-standard resolutions are still a bit of a problem I think.
> The vendor kernel (and also the CrOS kernel) does contain quite a number
> of hacks to make that work. (hacking up plls and the clock-tree, making
> it quite non-generic).

BTW: I did spend quite a bit of time getting a whole lot of HDMI clock
rates working on rk3288 in the Chrome OS kernel.  The main reason
these can't go upstream is that it depends on knowing that we'll be
able to fully control a PLL for HDMI and that's not guaranteed on
upstream.  I've tried to get folks interested in trying to solve that
problem in the past but never made any real progress.  :(

In any case, if I can ever answer any questions about the HDMI configs
I figured out to work on rk3288, please let me know.

-Doug