Hello, On Fri, Jun 24, 2022 at 01:24:28PM +0100, Kieran Bingham wrote: > Quoting Harsha Manjula Mallikarjun (MS/ECF3-XC) (2022-06-24 10:18:14) > > Hi Kieran, Hi Laurent, > > > > We are planning to put some efforts to improve and add, on top of the > > RCAR CMM patches[1] and upstream them. Following are the > > add-ons/improvements planned. If there are some activities with > > respect RCAR CMM, are ongoing already in upstream, we are happy to be > > involved in it and can spare efforts. > > > > 1. Double buffering support for CLU, LUT tables. > > > 2. Add worker thread in rcar_cmm to apply the table settings. To apply > > the CLU settings time taken is around ~7ms. This looks a bit high and > > more importantly it just blocks the compositor. > > > 3. With the patches[1] I see that CLU settings are written to > > registers but, the display does not show any change. Also, I see a > > short freeze on the display. This needs to be resolved. > > > > Also we have some patches for weston drm-backend which can set the > > 3DLUT, but they could not be up-streamed because drm object properties > > "CUBIC_LUT" and "CUBIC_LUT_SIZE" are not the standard ones yet. > > Reading [2], I think one of the blockers to getting [1] merged was the > lack of such an implementation to userspace. So I think if you were able > to share/post that - it would help unblock the upstreaming. Even if the patches can't be upstreamed in Weston yet, posting them as RFC to show how the new DRM properties are used would be extremely helpful to get the kernel side merged. > Your results above warrant further investigation though, as indeed 7ms > to set some registers sounds quite high, even if it is a large table, > and even more so if they are not taking effect. > > > [1]: https://patchwork.kernel.org/project/linux-renesas-soc/list/?series=404647 > [2]: https://patchwork.kernel.org/project/linux-renesas-soc/patch/20201221015730.28333-4-laurent.pinchart+renesas@xxxxxxxxxxxxxxxx/ -- Regards, Laurent Pinchart
