On Thu, Jan 04, 2024 at 02:34:33PM +0000, Biju Das wrote: > Hi Maxime Ripard, > > > -----Original Message----- > > From: Maxime Ripard <mripard@xxxxxxxxxx> > > Sent: Friday, December 15, 2023 2:24 PM > > Subject: Re: [PATCH v15 3/5] drm: renesas: Add RZ/G2L DU Support > > > > On Fri, Dec 15, 2023 at 01:25:48PM +0000, Biju Das wrote: > > > Hi Maxime Ripard, > > > > > > > -----Original Message----- > > > > From: Maxime Ripard <mripard@xxxxxxxxxx> > > > > Sent: Friday, December 15, 2023 10:24 AM > > > > Subject: Re: [PATCH v15 3/5] drm: renesas: Add RZ/G2L DU Support > > > > > > > > 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-us > > > ers-manual-hardware-0 > > > > > > [2] > > > https://elixir.bootlin.com/linux/v6.7-rc5/source/drivers/media/platfor > > > m/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. Maxime
Attachment:
signature.asc
Description: PGP signature
