[PATCH v9 00/23] drm/rockchip: RK356x VOP2 support

[Andy Yan]

Hi Piotr:

On 4/1/22 09:52, Andy Yan wrote:
>
> Hi Piotr:
>
> On 3/31/22 22:53, Piotr Oniszczuk wrote:
>>> Wiadomość napisana przez Andy Yan<andy.yan at rock-chips.com>  w dniu 31.03.2022, o godz. 14:13:
>>>
>>>
>>> Piotr:
>>>
>>> What soc is on you board? rk3566 or rk3568?
>> it is rk3566 in x96-x6 tvbox
>
>
> RK3566?  Maybe that is the problem.
>
>
> plane[43]: Esmart1-win0
> crtc=(null)
> fb=0
> crtc-pos=0x0+0+0
> src-pos=0.000000x0.000000+0.000000+0.000000
> rotation=1
> normalized-zpos=1
> color-encoding=ITU-R BT.601 YCbCr
> color-range=YCbCr limited range
>
> From your dri/state dump, Plane 43 is Esmart1.
>
> Cluster1, Esmart1, Smart1 are special on rk3566, they are
>
> mirror window of Cluster0, Esmart0, Esmart0. That means
>
> the software can't program  a independent framebuffer for
>
> these three windows. They can only share the fb address set
>
> in Cluster0, Esmart0, Smart0.
>
> For rk3566, we only use it for two VP display same content:
>
> assign Cluster0,Esmart0,Smart0 to VP1 for primary display(MIPI),
>
> assign Cluster1,Esmart1, Smart1 to VP0 for extend display(HDMI)
>
> we handle this logic in Android hwc:
>
> When a hdmi is connected, hwc will commit Esmart1 with Esmart0 with the
>
> same fb and src buffer size, the dst can be different(by window scale)
>
>
> I have code comment in my downstream kernel and explained this detail 
> when Sascha start submit this serials.
>
>>> I have a scripts[0]  use io[1] command to dump the VOP2 register you can use it dump the register configuration when you meet a display failure,
>>>
>>> then send the dump to me, maybe I can figure out something.
>>>
>>> [0]https://github.com/andyshrk/buildroot/blob/2022/board/andyshrk/rootfs_overlay/usr/bin/vop2_dump.sh
>>>
>>> [1]https://github.com/andyshrk/io
>> Andy
>>
>> Pls seehttps://pastebin.com/CHmu9s22
>
>
> The dump is a little strange, I will check it in the later night.
>

Pls update the new vop2_dump.sh scripts from github. The

previous scripts I gave you has some bug. sorry.

>> I put dumps for following scenarios:
>>
>> 1.
>> -boot
>> -modetest -s 69 at 67:1920x1080 -> ok
>> -modetest -P 43 at 67:1920x1080 at NV12 -> green screen
>>
>>
>> 2.
>> -boot
>> -modetest -s 69 at 67:1920x1080 -> ok
>> -modetest -P 49 at 67:1920x1080 at NV12 -> ok (but shifted horizontally by about 5% of screen width)
>> (setting palne#49 fixes plane #43. Here i set plane #49 but not yet setting #43)
>>
>>
>> 3.
>> -boot
>> -modetest -s 69 at 67:1920x1080 -> ok
>> -modetest -P 49 at 67:1920x1080 at NV12 -> ok (but shifted horizontally by about 5% of screen width)
>> -modetest -P 43 at 67:1920x1080 at NV12 -> now ok (but shifted horizontally by about 5% of screen width)
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20220401/ca90b489/attachment.htm>