On Thu, Jul 02, 2020 at 05:11:25PM +0200, Neil Armstrong wrote: > Hi, > > On 02/07/2020 16:15, Daniel Vetter wrote: > > On Thu, Jul 2, 2020 at 3:34 PM Neil Armstrong <narmstrong@xxxxxxxxxxxx> wrote: > >> > >> On 02/07/2020 15:18, Daniel Vetter wrote: > >>> On Thu, Jul 02, 2020 at 09:23:11AM +0000, Simon Ser wrote: > >>>> On Thursday, July 2, 2020 9:47 AM, Neil Armstrong <narmstrong@xxxxxxxxxxxx> wrote: > >>>> > >>>>> Finally is also adds the Scatter Memory layout, meaning the header contains IOMMU > >>>>> references to the compressed frames content to optimize memory access > >>>>> and layout. > >>>>> > >>>>> In this mode, only the header memory address is needed, thus the content > >>>>> memory organization is tied to the current producer execution and cannot > >>>>> be saved/dumped neither transferrable between Amlogic SoCs supporting this > >>>>> modifier. > >>>> > >>>> Still not sure how to handle this one, since this breaks fundamental > >>>> assumptions about modifiers. > >>> > >>> I wonder whether we should require special allocations for these, and then > >>> just outright reject mmap on these buffers. mmap on dma-buf isn't a > >>> required feature. > >> > >> Yes, it's the plan to reject mmap on these buffers, but it can't be explained > >> in the modifiers description and it's a requirement of the producer, not the > >> consumer. > > > > Hm I think worth to add that as a note to the modifier. Just to make > > sure. And avoids questions like the one from Simon. > > Something like: > > /* > * Amlogic FBC Scatter Memory layout > * > * Indicates the header contains IOMMU references to the compressed > * frames content to optimize memory access and layout. > * > * In this mode, only the header memory address is needed, thus the > * content memory organization is tied to the current producer > * execution and cannot be saved/dumped neither transferrable between > * Amlogic SoCs supporting this modifier. > + * > + * Due to the nature of the layout, these buffers are not expected to > + * be accessible by the user-space clients but only accessible by the > + * hardware producers and consumers. > + * > + * The user-space clients should expect a failure while trying to mmap > + * the DMA-BUF handle returned by the producer. > */ lgtm, Acked-by: Daniel Vetter <daniel.vetter@xxxxxxxx> > > Thanks, > Neil > > > -Daniel > > > >> > >>> > >>> That would make sure that userspace cannot look at them. > >>> > >>> Also I'm kinda suspecting that there's not unlimited amounts of this magic > >>> invisible storage available anyway. > >>> -Daniel > >>> > >> > >> _______________________________________________ > >> dri-devel mailing list > >> dri-devel@xxxxxxxxxxxxxxxxxxxxx > >> https://lists.freedesktop.org/mailman/listinfo/dri-devel > > > > > > > -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
