Hi Andy, On Thu, 18 Nov 2021 at 13:14, Andy Yan <andy.yan@xxxxxxxxxxxxxx> wrote: > On 11/18/21 8:07 PM, Daniel Stone wrote: > > 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. > > 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
