[PATCH v8 22/24] drm: rockchip: Add VOP2 driver
Andy Yan
andy.yan at rock-chips.com
Tue Mar 15 18:14:34 PDT 2022
Hi Daniel:
On 3/15/22 20:43, Daniel Stone wrote:
> Hi Andy,
>
> On Tue, 15 Mar 2022 at 06:46, Andy Yan <andy.yan at rock-chips.com> wrote:
>> On 3/11/22 16:33, Sascha Hauer wrote:
>>> 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 ?
>>
>> 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?
> Are you using the open-source Panfrost driver, or the proprietary Arm
> DDK? The DDK was previously using some non-standard modifier tokens
> which have since been corrected upstream.
I use mesa 21.3.5 with open-source Panfrost driver enabled.
When I modify Sascha's vop2 driver, set a Cluster windows as primary plane,
Then launch weston, vop2 report POST_BUF_EMPTY irq err.
From the log I can see many "panfrost fde60000.gpu: js fault, js=0,
status=DATA_INVALID_FAULT" [0]
I check the register configuration of Cluster window, there is no
obvious error.
I event run a ovltest[1] written by myself feed a AFBC RGB data to
Cluster0. it can display ok.
It seems that the basic afbc configuration of vop2 is right, but
something is wrong with Panfrost?
[0]https://pastebin.com/ydZkSz1f
[1]https://gitee.com/andyshrk/drm/tree/master/tests/ovltest
>
> You can see from running `weston-debug drm-backend` (if you start
> Weston with `--debug`) the output as it tries to put client surfaces
> on to overlay planes, and why it can or cannot.
>
> For Weston's own composited output (used when it cannot place client
> surfaces on to planes), it will just use whatever the KMS driver
> declares as the primary plane. Weston does not have any logic to say
> 'oh, this plane is AFBC and AFBC is better, so I will use this as my
> primary plane': we just follow what the kernel tells us.
>
> Cheers,
> Daniel
More information about the linux-arm-kernel
mailing list