Thread (14 messages) 14 messages, 4 authors, 2020-07-02

Re: [PATCH v8 1/6] drm/fourcc: Add modifier definitions for describing Amlogic Video Framebuffer Compression

From: Daniel Vetter <hidden>
Date: 2020-07-02 18:03:43
Also in: dri-devel, linux-amlogic, lkml

On Thu, Jul 02, 2020 at 05:11:25PM +0200, Neil Armstrong wrote:
Hi,

On 02/07/2020 16:15, Daniel Vetter wrote:
quoted
On Thu, Jul 2, 2020 at 3:34 PM Neil Armstrong [off-list ref] wrote:
quoted
On 02/07/2020 15:18, Daniel Vetter wrote:
quoted
On Thu, Jul 02, 2020 at 09:23:11AM +0000, Simon Ser wrote:
quoted
On Thursday, July 2, 2020 9:47 AM, Neil Armstrong [off-list ref] wrote:
quoted
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 [off-list ref]
Thanks,
Neil
quoted
-Daniel
quoted
quoted
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@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help