Re: [PATCH v8 22/24] drm: rockchip: Add VOP2 driver

[Andy Yan <andy.yan@rock-chips.com>]

[-- Attachment #1: Type: text/plain, Size: 4190 bytes --]

Hi Sascha and Daniel:

On 3/16/22 15:40, Sascha Hauer wrote:
> On Tue, Mar 15, 2022 at 02:46:35PM +0800, Andy Yan wrote:
>> Hi Sascha:
>>
>> On 3/11/22 16:33, Sascha Hauer wrote:
>>> From: Andy Yan<andy.yan@rock-chips.com>
>>>
>>> The VOP2 unit is found on Rockchip SoCs beginning with rk3566/rk3568.
>>> It replaces the VOP unit found in the older Rockchip SoCs.
>>>
>>> This driver has been derived from the downstream Rockchip Kernel and
>>> heavily modified:
>>>
>>> - All nonstandard DRM properties have been removed
>>> - dropped struct vop2_plane_state and pass around less data between
>>>     functions
>>> - Dropped all DRM_FORMAT_* not known on upstream
>>> - rework register access to get rid of excessively used macros
>>> - Drop all waiting for framesyncs
>>>
>>> The driver is tested with HDMI and MIPI-DSI display on a RK3568-EVB
>>> board. Overlay support is tested with the modetest utility. AFBC support
>>> on the cluster windows is tested with weston-simple-dmabuf-egl on
>>> weston using the (yet to be upstreamed) panfrost driver support.
>> Do we need some modification to test AFBC by weston-simple-dma-egl ?
> By default weston-simple-dma-egl uses DRM_FORMAT_XRGB8888 which in the
> panfrost driver ends up as PIPE_FORMAT_B8G8R8_UNORM and
> panfrost_afbc_format() returns PIPE_FORMAT_NONE for that. Change the
> format to DRM_FORMAT_ABGR8888 using weston-simple-dma-egl -f 0x34324241.
> This ends up as PIPE_FORMAT_R8G8B8A8_UNORM in panfrost_afbc_format()
> which is a supported format.
>
I also try weston-simple-dmabuf-egl -f 0x34324241 command,

but I got this output log from weston[0]:

Layer 5 (pos 0x50000000):
View 0 (role xdg_toplevel, PID 375, surface ID 3, top-level window 
'simple-dmabuf-egl' of org.freedesktop.weston.
simple-dmabuf-egl, 0xaaaad08275e0):
position: (871, 174) -> (1127, 430)
[not opaque]
outputs: 0 (HDMI-A-1) (primary)
dmabuf buffer
format: 0x34324241 ABGR8888
modifier: ARM_BLOCK_SIZE=16x16,MODE=YTR|SPARSE (0x800000000000051)
Layer 6 (pos 0x2):
View 0 (role (null), PID 372, surface ID 18, background for output 
HDMI-A-1, 0xaaaad0863520):
position: (0, 0) -> (1920, 1080)
[fully opaque]
outputs: 0 (HDMI-A-1) (primary)
[buffer not available]
[repaint] preparing state for output HDMI-A-1 (0)
[repaint] trying planes-only build state
[view] evaluating view 0xaaaad083b0f0 for output HDMI-A-1 (0)
[view] not assigning view 0xaaaad083b0f0 to plane (no buffer available)
[view] failing state generation: placing view 0xaaaad083b0f0 to renderer 
not allowed
[repaint] could not build planes-only state, trying mixed
[state] using renderer FB ID 73 for mixed mode for output HDMI-A-1 (0)
[state] scanout will use for zpos 0
[view] evaluating view 0xaaaad083b0f0 for output HDMI-A-1 (0)
[view] not assigning view 0xaaaad083b0f0 to plane (no buffer available)
[view] view 0xaaaad083b0f0 will be placed on the renderer
[view] evaluating view 0xaaaad08275e0 for output HDMI-A-1 (0)
[plane] started with zpos 18446744073709551615
[view] view 0xaaaad08275e0 will be placed on the renderer
[view] evaluating view 0xaaaad0863520 for output HDMI-A-1 (0)
[view] not assigning view 0xaaaad0863520 to plane (no buffer available)
[view] not assigning view 0xaaaad0863520 to plane (occluded by renderer 
views)

[view] view 0xaaaad0863520 will be placed on the renderer


 From the log we can find that Layer5 view 0(0xaaaad08275e0) is the afbc 
view rendered by Panfrost.

But it at last put on a render not a afbc window of vop  "view] view 
0xaaaad083b0f0 will be placed on the renderer "

The output message from sys/kernel/debug/dri/state can also provide that 
only non-AFBC window smart0-win0 is used.

It seems that it failed in  weston drm_output_prepare_plane_view.

Maybe I need a deeper dig.

[0] https://pastebin.com/8CfiP7u1

>> I have a buildroot system with weston-10.0.9 and mesa 21.3.5.
>>
>> After launch weston, I run weston-simple-dmabuf-egl, but from the output
>>
>> of sys/kernel/debug/dri/0/state, the weston is still use Smart0-win0, which
>> is
>>
>> a non-AFBC window.
>>
>> Do i need to modify the vop2 driver to set one Cluster window as primary
>> plane?
> I never used a Cluster window as primary plane.
>
> Sascha
>

[-- Attachment #2: Type: text/html, Size: 6471 bytes --]