Hi Maxime, On Wed, Jan 10, 2024 at 05:14:41PM +0100, Maxime Ripard wrote: > On Thu, Jan 04, 2024 at 02:34:33PM +0000, Biju Das wrote: > > On Friday, December 15, 2023 2:24 PM, Maxime Ripard wrote: > > > On Fri, Dec 15, 2023 at 01:25:48PM +0000, Biju Das wrote: > > > > On Friday, December 15, 2023 10:24 AM, Maxime Ripard wrote: > > > > > On Thu, Dec 14, 2023 at 03:24:17PM +0000, Biju Das wrote: > > > > > > Hi Maxime Ripard, > > > > > > > > > > > > Thanks for the feedback. > > > > > > > > > > Thanks, that's super helpful. The architecture is thus similar to > > > > > vc4 > > > > > > > > > > Some general questions related to bugs we had at some point with vc4: > > > > > > > > > > * Where is the display list stored? In RAM or in a dedicated SRAM? > > > > > > > > [1] It is in DDR (RAM). > > > > > > > > > > > > > > * Are the pointer to the current display list latched? > > > > > > > > > > * Is the display list itself latched? If it's not, what happens when > > > > > the display list is changed while the frame is being generated? > > > > > > > > There is some protocol defined for SW side and HW side for updating > > > > display list See [1] 33.4.8.1 Operation flow of VSPD and DU. > > > > > > > > All the display list operations are manged here[2] > > > > > > > > [1] https://www.renesas.com/us/en/document/mah/rzg2l-group-rzg2lc-group-users-manual-hardware-0 > > > > > > > > [2] https://elixir.bootlin.com/linux/v6.7-rc5/source/drivers/media/platform/renesas/vsp1/vsp1_dl.c#L863 > > > > > > I'm sorry, but I'm not going to read a 3500+ to try to figure it out. > > > Could you answer the questions above? > > > > The answer for your question is, > > > > If a previous display list has been queued to the hardware but not > > processed yet, the VSP can start processing it at any time. In that > > case we can't replace the queued list by the new one, as we could > > race with the hardware. We thus mark the update as pending, it will > > be queued up to the hardware by the frame end interrupt handler. > > Ok, so you need to make sure that the list entries are allocated and > tied to the state. That way, you'll know for sure it'll get destroyed > only once the state isn't used anymore, so after the vblank. Because the VSP started as a memory-to-memory processing IP without being tied to the display, it got supported by a V4L2 (and MC) driver. Later on, the R-Car Gen2 added a direct connection between the output of *some* VSP instances and one input of the DU (display engine), using the VSP as an extra "plane" from a KMS point of view. Using the VSP was optional, as the DU had "normal" planes. R-Car Gen3 dropped support for direct memory access in the DU, making usage of the VSP mandatory. As using the VSP is mandatory for display operation on R-Car Gen3, we ruled out forcing userspace to deal with a KMS *and* a V4L2 device manually to get anything out on the screen. We also ruled out redeveloping VSP support inside the DU driver, as that would have duplicated (complex) code. Instead, the DU driver communicates with the VSP driver within the kernel, completely transparently for userspace. This in-kernel API is defined in include/media/vsp1.h, and consists of the following operations that have been modelled on the KMS atomic API: - One-time setup at driver initialization time: int vsp1_du_init(struct device *dev); - Configuration at CRTC enable/disable time: int vsp1_du_setup_lif(struct device *dev, unsigned int pipe_index, const struct vsp1_du_lif_config *cfg); This includes configuration of the output width/height. (LIF stands for "LCD InterFace" if I recall correctly, it's the block in the VSP that connects to the DU.) - Atomic updates void vsp1_du_atomic_begin(struct device *dev, unsigned int pipe_index); int vsp1_du_atomic_update(struct device *dev, unsigned int pipe_index, unsigned int rpf, const struct vsp1_du_atomic_config *cfg); void vsp1_du_atomic_flush(struct device *dev, unsigned int pipe_index, const struct vsp1_du_atomic_pipe_config *cfg); These operations configure planes (the VSP has a blending engine with 2 to 5 inputs depending on the exact SoC) and writeback (the VSP being historically just a memory-to-memory engine, it supports writing the output to memory in addition to forwarding it to the DU). The display lists are fully handled inside the VSP driver, the DU doesn't need to manage them. You can ignore the implementation details of the VSP itself. -- Regards, Laurent Pinchart
