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. */ 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 > > > _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
