RE: [PATCH v15 3/5] drm: renesas: Add RZ/G2L DU Support

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.

Cheers,
Biju





[Index of Archives]     [Linux Samsung SOC]     [Linux Wireless]     [Linux Kernel]     [ATH6KL]     [Linux Bluetooth]     [Linux Netdev]     [Kernel Newbies]     [IDE]     [Security]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux ATA RAID]     [Samba]     [Device Mapper]

  Powered by Linux