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

Andy Yan andy.yan at rock-chips.com
Thu Mar 17 07:23:12 UTC 2022 

Hi Sascha:

On 3/16/22 20:22, Andy Yan wrote:
>
> 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 at 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.
>

After a deeper dig, I found it failed from

drm_fb_get_from_dmabuf {


.......

/* XXX: TODO:
          *
          * Currently the buffer is rejected if any dmabuf attribute
          * flag is set.  This keeps us from passing an inverted /
          * interlaced / bottom-first buffer (or any other type that may
          * be added in the future) through to an overlay. Ultimately,
          * these types of buffers should be handled through buffer
          * transforms and not as spot-checks requiring specific
          * knowledge. */
         if (dmabuf->attributes.flags) {
                 drm_debug(backend, "\t\t\t\t invlid flag 0x%x\n", 
dmabuf->attributes.flags);
                 return NULL;
         }

}

After some grep search, I found the flag is set  at create_dmabuf_buffer 
by weston-simple-dmabuf-egl itself.

So I run this test with -g: weston-simple-dmabuf-egl -f 0x34324241 -g

 From the log I can see this view is go to a  overlay plane, but it 
doesn't appear on the screen.

Cat the dri state, I can see Cluster1-win0 this afbc window is enabled.

So I guess there is something wrong with the vop2 configuration.

I dump registers of OVERLAY and Cluster1-win0 and Smart0-win0(Primary plane)

I found a obvious  error in 0x604(OVERLAY_LAYER_SEL) register, the 
configuration value

is 0x54763513.

I am not sure if you know clearly about this register:

Every four bits of this register select a Window(Cluster0,Cluster1, 
Esmart0, Esmart1, Smart0. Smart1)

for layer0 to layer 5 from bottom to top.

0: Cluster0

1: Cluster1:

2: Esmart0

3: Smart0

6: Esmart1

7: Smart1

And one window can only be selected by one layer at a time.

So when I change this register to 0x54762513, the square draw by 
weston-simple-dmabuf-egl appeared on the top of the weston background on 
screen.


So Sascha, please check the logic of you map the window and layer.




> [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
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20220317/99ac6f13/attachment-0001.htm>

More information about the dri-devel mailing list