Hi Andy,

On Thu, 18 Nov 2021 at 13:14, Andy Yan [off-list ref] wrote:

On 11/18/21 8:07 PM, Daniel Stone wrote:

quoted

Technically, the driver cannot be upstreamed as-is. It looks as if it
were a pre-atomic driver, that was half-converted to atomic, and then
has been half-converted to atomic helpers as well. Things like
reference counting and global state are not handled correctly at all.
You can see this if you try to run Weston on top of the VOP2 driver:
the framerate is decimated because the event handling massively
over-synchronises, and the event timestamps which arrive are
incorrect. This would be fixed by correctly using the event helpers
that we have had in the tree for years (which would also eliminate the
unnecessary framebuffer reference handling). It also does not work
with the GPU drivers in the tree because it lacks the one-liner to
correctly handle dma_resv synchronisation, which makes it both too
fast as it displays content which is not ready, and too slow because
it can't do it at full frame rate.

We have different team run Android , X11, Weston on rk356x, especially
for android, we can run at 60 fps.

Our vop2 driver is developed on Linux 4.19, am not sure which version of
kernel you put our drivers on.

We forward-ported it to a current mainline kernel and started to work
on fixing some of the issues. When we did this, we went back to the
BSP tree posted on GitHub to test using a pure-BSP environment, and
observed the same breakage there.

quoted

Similarly, on the RK3566 EVB, the DSI does not work unless HDMI is
also active, but when HDMI is active at the same time as DSI, it just

I am very sure rk3566 evb DSI can work without HDMI.

I'd love to know how. :) Using the meta-rockchip layer as published on
GitHub, we cannot get working DSI without HDMI, using upstream Weston.
When the HDMI connector is disabled, DSI comes up blank. When the HDMI
connector is enabled, DSI works fine but HDMI is blank.

But take care that the vop on rk3566 has a special limitation: there are
three windows(Cluster1/Esmart1/Smart1) that have a mirror lock, that means they
can't be programed framebuffer address independently , they can only
share framebuffer address with Cluster0/Esmart0/Smart0. We use these feature
on Android.

I have comment these limitation in our driver.

Yeah, we noticed this.

Compared to old vop, vop is strong but a bit complicated, we try very had to
make it work on as much display framework as possible.

We have upstream plane, but I am really in a rush this year. So sorry
for the late of upstream, but we glad to work with community.

So Sascha, please feel free to go on with your work.

Great, thanks. If you agree with the plan I posted, then we can all go
forward with that upstream, doing the development work with ourselves
and Sascha. Hopefully Rockchip will be able to support this effort.

Cheers,
Daniel

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel