Re: [PATCH] drm/fourcc: Fix vsub/hsub for Q410 and Q401
On Tue, Sep 13, 2022 at 04:36:57PM +0100, Liviu Dudau wrote:
> On Tue, Sep 13, 2022 at 03:43:06PM +0100, Brian Starkey wrote:
> > These formats are not subsampled, but that means hsub and vsub should be
> > 1, not 0.
> >
> > Fixes: 94b292b27734 ("drm: drm_fourcc: add NV15, Q410, Q401 YUV formats")
> > Reported-by: George Kennedy
> > Reported-by: butt3rflyh4ck
> > Signed-off-by: Brian Starkey
>
> Reviewed-by: Liviu Dudau
>
> Should this be backported into stable releases? How far back to we go?
Probably, git says 94b292b27734 is in since 5.10.
Could someone merge this so it doesn't get lost again?
Thanks,
-Brian
>
> Best regards,
> Liviu
>
>
> > ---
> > drivers/gpu/drm/drm_fourcc.c | 8
> > 1 file changed, 4 insertions(+), 4 deletions(-)
> >
> > Sorry, I lost track of this - I thought it got fixed after the previous
> > thread[1].
> >
> > -Brian
> >
> > [1]
> > https://lore.kernel.org/all/26fdb955-10c8-a5d6-07b6-85a4374e7...@oracle.com/
> >
> > diff --git a/drivers/gpu/drm/drm_fourcc.c b/drivers/gpu/drm/drm_fourcc.c
> > index 07741b678798..6768b7d18b6f 100644
> > --- a/drivers/gpu/drm/drm_fourcc.c
> > +++ b/drivers/gpu/drm/drm_fourcc.c
> > @@ -263,12 +263,12 @@ const struct drm_format_info *__drm_format_info(u32
> > format)
> > .vsub = 2, .is_yuv = true },
> > { .format = DRM_FORMAT_Q410,.depth = 0,
> > .num_planes = 3, .char_per_block = { 2, 2, 2 },
> > - .block_w = { 1, 1, 1 }, .block_h = { 1, 1, 1 }, .hsub = 0,
> > - .vsub = 0, .is_yuv = true },
> > + .block_w = { 1, 1, 1 }, .block_h = { 1, 1, 1 }, .hsub = 1,
> > + .vsub = 1, .is_yuv = true },
> > { .format = DRM_FORMAT_Q401,.depth = 0,
> > .num_planes = 3, .char_per_block = { 2, 2, 2 },
> > - .block_w = { 1, 1, 1 }, .block_h = { 1, 1, 1 }, .hsub = 0,
> > - .vsub = 0, .is_yuv = true },
> > + .block_w = { 1, 1, 1 }, .block_h = { 1, 1, 1 }, .hsub = 1,
> > + .vsub = 1, .is_yuv = true },
> > { .format = DRM_FORMAT_P030,.depth = 0,
> > .num_planes = 2,
> > .char_per_block = { 4, 8, 0 }, .block_w = { 3, 3, 0 },
> > .block_h = { 1, 1, 0 },
> > .hsub = 2, .vsub = 2, .is_yuv = true},
> > --
> > 2.25.1
> >
>
> --
>
> | I would like to |
> | fix the world, |
> | but they're not |
> | giving me the |
> \ source code! /
> ---
> ¯\_(ツ)_/¯
[PATCH] drm/fourcc: Fix vsub/hsub for Q410 and Q401
These formats are not subsampled, but that means hsub and vsub should be
1, not 0.
Fixes: 94b292b27734 ("drm: drm_fourcc: add NV15, Q410, Q401 YUV formats")
Reported-by: George Kennedy
Reported-by: butt3rflyh4ck
Signed-off-by: Brian Starkey
---
drivers/gpu/drm/drm_fourcc.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
Sorry, I lost track of this - I thought it got fixed after the previous
thread[1].
-Brian
[1] https://lore.kernel.org/all/26fdb955-10c8-a5d6-07b6-85a4374e7...@oracle.com/
diff --git a/drivers/gpu/drm/drm_fourcc.c b/drivers/gpu/drm/drm_fourcc.c
index 07741b678798..6768b7d18b6f 100644
--- a/drivers/gpu/drm/drm_fourcc.c
+++ b/drivers/gpu/drm/drm_fourcc.c
@@ -263,12 +263,12 @@ const struct drm_format_info *__drm_format_info(u32
format)
.vsub = 2, .is_yuv = true },
{ .format = DRM_FORMAT_Q410,.depth = 0,
.num_planes = 3, .char_per_block = { 2, 2, 2 },
- .block_w = { 1, 1, 1 }, .block_h = { 1, 1, 1 }, .hsub = 0,
- .vsub = 0, .is_yuv = true },
+ .block_w = { 1, 1, 1 }, .block_h = { 1, 1, 1 }, .hsub = 1,
+ .vsub = 1, .is_yuv = true },
{ .format = DRM_FORMAT_Q401,.depth = 0,
.num_planes = 3, .char_per_block = { 2, 2, 2 },
- .block_w = { 1, 1, 1 }, .block_h = { 1, 1, 1 }, .hsub = 0,
- .vsub = 0, .is_yuv = true },
+ .block_w = { 1, 1, 1 }, .block_h = { 1, 1, 1 }, .hsub = 1,
+ .vsub = 1, .is_yuv = true },
{ .format = DRM_FORMAT_P030,.depth = 0,
.num_planes = 2,
.char_per_block = { 4, 8, 0 }, .block_w = { 3, 3, 0 },
.block_h = { 1, 1, 0 },
.hsub = 2, .vsub = 2, .is_yuv = true},
--
2.25.1
Re: [EXT] Re: [PATCH 1/3] dma-buf: heaps: add Linaro secure dmabuf heap support
On Tue, Aug 16, 2022 at 11:20:50AM +, Olivier Masse wrote:
> On ven., 2022-08-12 at 17:39 +0100, Brian Starkey wrote:
> > On Mon, Aug 08, 2022 at 02:39:53PM +, Olivier Masse wrote:
> > > On ven., 2022-08-05 at 16:41 +0100, Brian Starkey wrote:
> > > > On Fri, Aug 05, 2022 at 03:53:28PM +0200, Olivier Masse wrote:
.. snip
> > > > > +
> > > > > +static struct sg_table *secure_heap_map_dma_buf(struct
> > > > > dma_buf_attachment *attachment,
> > > > > + enum
> > > > > dma_data_direction direction)
> > > > > +{
> > > > > + struct secure_heap_attachment *a = attachment->priv;
> > > > > +
> > > > > + return a->table;
> > > >
> > > > I think you still need to implement mapping and unmapping using
> > > > the
> > > > DMA APIs. For example devices might be behind IOMMUs and the
> > > > buffer
> > > > will need mapping into the IOMMU.
> > >
> > > Devices that will need access to the buffer must be in secure.
> > > The tee driver will only need the scatter-list table to get dma
> > > address
> > > and len. Mapping will be done in the TEE.
> > > Please find tee_shm_register_fd in the following commit
> > >
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Flinaro-swg%2Flinux%2Fcommit%2F41e21e5c405530590dc2dd10b2a8dbe64589840fdata=05%7C01%7Colivier.masse%40nxp.com%7C6b3d47f1e15c41a8cf7108da7c813ef6%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C1%7C637959191795668899%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=OKZhaNevD5dj7Wjm6zbZlij0mPA9XYyio1NAN3VjTVM%3Dreserved=0
> > >
> > > This patch need to be up-streamed as well.
> > >
> >
> > Interesting, that's not how the devices I've worked on operated.
> >
> > Are you saying that you have to have a display controller driver
> > running in the TEE to display one of these buffers?
>
> In fact the display controller is managing 3 plans : UI, PiP and
> video. The video plan is protected in secure as you can see on slide
> 11:
> https://static.linaro.org/connect/san19/presentations/san19-107.pdf
>
> The DCSS (display controller) is able to read from the protected secure
> heap and composition result is send directly to the HDMI/HDCP port.
But it sounds like the DCSS driver is running in non-trusted Linux?
>
>
> > If everything
> > needs to be in the TEE, then why even have these buffers allocated
> > by non-secure Linux at all?
>
> The TEE is only doing decryption using the HW Crypto Accelerator
> (CAAM).
> The CAAM will read from a non protected encrypted buffer to write clear
> content to a secure buffer allocated with DMABUF and mapped in secure
> by OPTEE OS.
>
> >
> > I would have expected there to be HW enforcement of buffer access,
> > but for the display driver to be in non-secure Linux. That's how
> > TZMP1 works:
> > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fstatic.linaro.org%2Fconnect%2Fhkg18%2Fpresentations%2Fhkg18-408.pdfdata=05%7C01%7Colivier.masse%40nxp.com%7C6b3d47f1e15c41a8cf7108da7c813ef6%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C1%7C637959191795668899%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=XVpI93dXYu%2BGswLE8dcYboq%2FAWzSJn9j9LMlngpr238%3Dreserved=0
> >
> > Looking at this SDP presentation, that also seems to be the case
> > there:
> > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fstatic.linaro.org%2Fconnect%2Fsan19%2Fpresentations%2Fsan19-107.pdfdata=05%7C01%7Colivier.masse%40nxp.com%7C6b3d47f1e15c41a8cf7108da7c813ef6%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C1%7C637959191795668899%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=5Ec61NC1f0UQU%2F3BEURZQhEBrZ%2FuvJ1vaoSN4ChMn%2Bw%3Dreserved=0
> >
>
> Indeed, TZMP1 is similar to our implementation.
>
> > Based on those presentations, I think this heap should be
> > implementing
> > map_dma_buf in the "normal" way, using the DMA API to map the buffer
> > to the device. It's up to the TEE and HW firewall to prevent access
> > to those mappings from non-secure devices.
>
> In fact, our devices (VPU and DCSS) do not need any mapping, but only
> the physical address of buffers which need to be contiguous.
That's not how dma-buf or the DMA APIs work though - you should use
dma_map_sgtable and let the DMA API take care
Re: [EXT] Re: [PATCH 1/3] dma-buf: heaps: add Linaro secure dmabuf heap support
Hi,
On Mon, Aug 08, 2022 at 02:39:53PM +, Olivier Masse wrote:
> Hi Brian,
>
> On ven., 2022-08-05 at 16:41 +0100, Brian Starkey wrote:
> > Caution: EXT Email
> >
> > Hi Olivier,
> >
> > Thanks, I think this is looking much better.
> >
> > I'd like to know how others feel about landing this heap; there's
> > been
> > push-back in the past about heaps in device-tree and discussions
> > around how "custom" heaps should be treated (though IMO this is quite
> > a generic one).
> >
> > On Fri, Aug 05, 2022 at 03:53:28PM +0200, Olivier Masse wrote:
> > > add Linaro secure heap bindings: linaro,secure-heap
> > > use genalloc to allocate/free buffer from buffer pool.
> > > buffer pool info is from dts.
> > > use sg_table instore the allocated memory info, the length of
> > > sg_table is 1.
> > > implement secure_heap_buf_ops to implement buffer share in
> > > difference device:
> > > 1. Userspace passes this fd to all drivers it wants this buffer
> > > to share with: First the filedescriptor is converted to a _buf
> > > using
> > > dma_buf_get(). Then the buffer is attached to the device using
> > > dma_buf_attach().
> > > 2. Once the buffer is attached to all devices userspace can
> > > initiate DMA
> > > access to the shared buffer. In the kernel this is done by calling
> > > dma_buf_map_attachment()
> > > 3. get sg_table with dma_buf_map_attachment in difference device.
> > >
> >
> > I think this commit message could use a little rework. A few
> > thoughts:
> >
> > * The bindings are in a separate commit, so seems strange to mention
> > here.
>
> what about:
> "add Linaro secure heap compatible reserved memory: linaro,secure-heap"
>
I'd say something like:
Add a dma-buf heap to allocate secure buffers from a reserved-memory
region.
..snip
> > > +
> > > +static struct sg_table *secure_heap_map_dma_buf(struct
> > > dma_buf_attachment *attachment,
> > > + enum
> > > dma_data_direction direction)
> > > +{
> > > + struct secure_heap_attachment *a = attachment->priv;
> > > +
> > > + return a->table;
> >
> > I think you still need to implement mapping and unmapping using the
> > DMA APIs. For example devices might be behind IOMMUs and the buffer
> > will need mapping into the IOMMU.
>
> Devices that will need access to the buffer must be in secure.
> The tee driver will only need the scatter-list table to get dma address
> and len. Mapping will be done in the TEE.
> Please find tee_shm_register_fd in the following commit
> https://github.com/linaro-swg/linux/commit/41e21e5c405530590dc2dd10b2a8dbe64589840f
>
> This patch need to be up-streamed as well.
>
Interesting, that's not how the devices I've worked on operated.
Are you saying that you have to have a display controller driver
running in the TEE to display one of these buffers? If everything
needs to be in the TEE, then why even have these buffers allocated
by non-secure Linux at all?
I would have expected there to be HW enforcement of buffer access,
but for the display driver to be in non-secure Linux. That's how
TZMP1 works: https://static.linaro.org/connect/hkg18/presentations/hkg18-408.pdf
Looking at this SDP presentation, that also seems to be the case
there: https://static.linaro.org/connect/san19/presentations/san19-107.pdf
Based on those presentations, I think this heap should be implementing
map_dma_buf in the "normal" way, using the DMA API to map the buffer
to the device. It's up to the TEE and HW firewall to prevent access
to those mappings from non-secure devices.
My understanding is:
* The memory region should never be mapped or accessed from the host
CPU. This is not a security requirement - the CPU will be denied
access by whatever hardware is enforcing security - but any CPU
accesses will fail, so there is no point in ever having a CPU
mapping.
* The allocated buffers _should_ be mapped to devices via map_dma_buf.
Again the HW enforcement will prevent access from devices which
aren't permitted access, but for example a display controller
may be allowed to read the secure buffer, composite it with other
buffers, and display it on the screen.
Am I wrong? Even if SDP doesn't work this way, I think we should make
the heap as generic as possible so that it can work with different
secure video implementations.
>
> >
.. snip
> > > +
> > > +RESERVEDMEM_OF_DECLARE(secure_heap, "linaro,secure-heap",
> > > rmem_secure_heap_setup);
> >
Re: [PATCH 2/3] dt-bindings: reserved-memory: add linaro,secure-heap
+Rob and devicetree list.
I don't know if this should be "linaro" or something more generic,
and also where previous discussions got to about DMA heaps in DT.
Cheers,
-Brian
On Fri, Aug 05, 2022 at 03:53:29PM +0200, Olivier Masse wrote:
> DMABUF Reserved memory definition for OP-TEE SDP feaure.
>
> Signed-off-by: Olivier Masse
> ---
> .../reserved-memory/linaro,secure-heap.yaml | 56 +++
> 1 file changed, 56 insertions(+)
> create mode 100644
> Documentation/devicetree/bindings/reserved-memory/linaro,secure-heap.yaml
>
> diff --git
> a/Documentation/devicetree/bindings/reserved-memory/linaro,secure-heap.yaml
> b/Documentation/devicetree/bindings/reserved-memory/linaro,secure-heap.yaml
> new file mode 100644
> index ..80522a4e2989
> --- /dev/null
> +++
> b/Documentation/devicetree/bindings/reserved-memory/linaro,secure-heap.yaml
> @@ -0,0 +1,56 @@
> +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/reserved-memory/linaro,secure-heap.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Linaro Secure DMABUF Heap
> +
> +maintainers:
> + - Olivier Masse
> +
> +description:
> + Linaro OP-TEE firmware needs a reserved memory for the
> + Secure Data Path feature (aka SDP).
> + The purpose is to provide a secure memory heap which allow
> + non-secure OS to allocate/free secure buffers.
> + The TEE is reponsible for protecting the SDP memory buffers.
> + TEE Trusted Application can access secure memory references
> + provided as parameters (DMABUF file descriptor).
> +
> +allOf:
> + - $ref: "reserved-memory.yaml"
> +
> +properties:
> + compatible:
> +const: linaro,secure-heap
> +
> + reg:
> +description:
> + Region of memory reserved for OP-TEE SDP feature
> +
> + no-map:
> +$ref: /schemas/types.yaml#/definitions/flag
> +description:
> + Avoid creating a virtual mapping of the region as part of the OS'
> + standard mapping of system memory.
> +
> +unevaluatedProperties: false
> +
> +required:
> + - compatible
> + - reg
> + - no-map
> +
> +examples:
> + - |
> + reserved-memory {
> +#address-cells = <2>;
> +#size-cells = <2>;
> +
> +sdp@3e80 {
> + compatible = "linaro,secure-heap";
> + no-map;
> + reg = <0 0x3E80 0 0x0040>;
> +};
> + };
> --
> 2.25.0
>
Re: [PATCH 1/3] dma-buf: heaps: add Linaro secure dmabuf heap support
Hi Olivier,
Thanks, I think this is looking much better.
I'd like to know how others feel about landing this heap; there's been
push-back in the past about heaps in device-tree and discussions
around how "custom" heaps should be treated (though IMO this is quite
a generic one).
On Fri, Aug 05, 2022 at 03:53:28PM +0200, Olivier Masse wrote:
> add Linaro secure heap bindings: linaro,secure-heap
> use genalloc to allocate/free buffer from buffer pool.
> buffer pool info is from dts.
> use sg_table instore the allocated memory info, the length of sg_table is 1.
> implement secure_heap_buf_ops to implement buffer share in difference device:
> 1. Userspace passes this fd to all drivers it wants this buffer
> to share with: First the filedescriptor is converted to a _buf using
> dma_buf_get(). Then the buffer is attached to the device using
> dma_buf_attach().
> 2. Once the buffer is attached to all devices userspace can initiate DMA
> access to the shared buffer. In the kernel this is done by calling
> dma_buf_map_attachment()
> 3. get sg_table with dma_buf_map_attachment in difference device.
>
I think this commit message could use a little rework. A few thoughts:
* The bindings are in a separate commit, so seems strange to mention
here.
* "buffer pool info is from dts" --> I think you should mention that
this uses a reserved-memory region.
* sg_table nents and genalloc seem like low-level implementation
details, so probably not needed in the commit message
* The usage steps 1, 2, 3 aren't specific to this heap - that's how
all dma-buf sharing works.
> Signed-off-by: Olivier Masse
> ---
> drivers/dma-buf/heaps/Kconfig | 9 +
> drivers/dma-buf/heaps/Makefile | 1 +
> drivers/dma-buf/heaps/secure_heap.c | 357
> 3 files changed, 367 insertions(+)
> create mode 100644 drivers/dma-buf/heaps/secure_heap.c
>
> diff --git a/drivers/dma-buf/heaps/Kconfig b/drivers/dma-buf/heaps/Kconfig
> index 3782eeeb91c0..c9070c728b9a 100644
> --- a/drivers/dma-buf/heaps/Kconfig
> +++ b/drivers/dma-buf/heaps/Kconfig
> @@ -20,3 +20,12 @@ config DMABUF_HEAPS_DSP
>Choose this option to enable the dsp dmabuf heap. The dsp heap
>is allocated by gen allocater. it's allocated according the dts.
>If in doubt, say Y.
> +
> +config DMABUF_HEAPS_SECURE
> + tristate "DMA-BUF Secure Heap"
> + depends on DMABUF_HEAPS
> + help
> + Choose this option to enable the secure dmabuf heap. The secure heap
> + pools are defined according to the DT. Heaps are allocated
> + in the pools using gen allocater.
> + If in doubt, say Y.
> diff --git a/drivers/dma-buf/heaps/Makefile b/drivers/dma-buf/heaps/Makefile
> index 29733f84c354..863ef10056a3 100644
> --- a/drivers/dma-buf/heaps/Makefile
> +++ b/drivers/dma-buf/heaps/Makefile
> @@ -2,3 +2,4 @@
> obj-$(CONFIG_DMABUF_HEAPS_SYSTEM)+= system_heap.o
> obj-$(CONFIG_DMABUF_HEAPS_CMA) += cma_heap.o
> obj-$(CONFIG_DMABUF_HEAPS_DSP) += dsp_heap.o
> +obj-$(CONFIG_DMABUF_HEAPS_SECURE)+= secure_heap.o
> diff --git a/drivers/dma-buf/heaps/secure_heap.c
> b/drivers/dma-buf/heaps/secure_heap.c
> new file mode 100644
> index ..25b3629613f3
> --- /dev/null
> +++ b/drivers/dma-buf/heaps/secure_heap.c
> @@ -0,0 +1,357 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * DMABUF secure heap exporter
> + *
> + * Copyright 2021 NXP.
It's 2022 :-)
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#define MAX_SECURE_HEAP 2
> +#define MAX_HEAP_NAME_LEN 32
> +
> +struct secure_heap_buffer {
> + struct dma_heap *heap;
> + struct list_head attachments;
> + struct mutex lock;
> + unsigned long len;
> + struct sg_table sg_table;
> + int vmap_cnt;
> + void *vaddr;
> +};
> +
> +struct secure_heap_attachment {
> + struct device *dev;
> + struct sg_table *table;
> + struct list_head list;
> +};
> +
> +struct secure_heap_info {
> + struct gen_pool *pool;
> +};
> +
> +struct rmem_secure {
> + phys_addr_t base;
> + phys_addr_t size;
> +
> + char name[MAX_HEAP_NAME_LEN];
> +};
> +
> +static struct rmem_secure secure_data[MAX_SECURE_HEAP] = {0};
> +static unsigned int secure_data_count;
> +
> +static struct sg_table *dup_sg_table(struct sg_table *table)
> +{
> + struct sg_table *new_table;
> + int ret, i;
> + struct scatterlist *sg, *new_sg;
> +
> + new_table = kzalloc(sizeof(*new_table), GFP_KERNEL);
> + if (!new_table)
> + return ERR_PTR(-ENOMEM);
> +
> + ret = sg_alloc_table(new_table, table->orig_nents, GFP_KERNEL);
> + if (ret) {
> + kfree(new_table);
> + return ERR_PTR(-ENOMEM);
> + }
> +
> + new_sg = new_table->sgl;
> + for_each_sgtable_sg(table, sg, i) {
> +
Re: [PATCH 2/5] ANDROID: dma-buf: heaps: Add a shrinker controlled page pool
Hi Olivier, On Tue, Aug 02, 2022 at 11:58:40AM +0200, Olivier Masse wrote: > From: John Stultz > > This patch adds a simple shrinker controlled page pool to the > dmabuf heaps subsystem. > > This replaces the use of the networking page_pool, over concerns > that the lack of a shrinker for that implementation may cause > additional low-memory kills > > TODO: Take another pass at trying to unify this w/ the ttm pool > > Thoughts and feedback would be greatly appreciated! Did I miss something, or is this not actually used anywhere? Thanks, -Brian
Re: [EXT] Re: [PATCH 3/5] dma-buf: heaps: add Linaro secure dmabuf heap support
Hi, On Wed, Aug 03, 2022 at 11:07:54AM +, Olivier Masse wrote: > Hi Brian, > > Thanks for your comments, please find my reply below. > > On mar., 2022-08-02 at 15:39 +0100, Brian Starkey wrote: > > Caution: EXT Email > > > > Hi Olivier, > > > > Some comments below as I mentioned off-list. > > > > One additional point: some devices need to know if a buffer is > > protected, so that they can configure registers appropriately to make > > use of that protected buffer. There was previously a discussion about > > adding a flag to a dma_buf to indicate that it is allocated from > > protected memory[1]. > > > > [1] > > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.freedesktop.org%2Farchives%2Fdri-devel%2F2019-September%2F238059.htmldata=05%7C01%7Colivier.masse%40nxp.com%7C64e0ce1952ac4e926a8208da7494d0bb%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C637950479760002497%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=bmlw9uLeGtn%2F7JliZ07nSm6XDEzEqdwn4mBQHIVnma0%3Dreserved=0 > > > > > > Interesting, could we introduce is_protected 1-bit flag into struct > dma_buf ? That was the earlier proposal, yeah. > struct dma_buf_ops.map_dma_buf and struct dma_buf_ops.unmap_dma_buf > could become optional for such buffer ? > map_dma_buf and unmap_dma_buf are needed to give devices access to the dma-buf, I don't think they should become optional. Mapping to the CPU maybe should be optional/disallowed for protected buffers. > > On Tue, Aug 02, 2022 at 11:58:41AM +0200, Olivier Masse wrote: > > > add Linaro secure heap bindings: linaro,secure-heap > > > use genalloc to allocate/free buffer from buffer pool. > > > buffer pool info is from dts. > > > use sg_table instore the allocated memory info, the length of > > > sg_table is 1. > > > implement secure_heap_buf_ops to implement buffer share in > > > difference device: > > > 1. Userspace passes this fd to all drivers it wants this buffer > > > to share with: First the filedescriptor is converted to a _buf > > > using > > > dma_buf_get(). Then the buffer is attached to the device using > > > dma_buf_attach(). > > > 2. Once the buffer is attached to all devices userspace can > > > initiate DMA > > > access to the shared buffer. In the kernel this is done by calling > > > dma_buf_map_attachment() > > > 3. get sg_table with dma_buf_map_attachment in difference device. > > > > > > Signed-off-by: Olivier Masse > > > --- > > > drivers/dma-buf/heaps/Kconfig | 21 +- > > > drivers/dma-buf/heaps/Makefile | 1 + > > > drivers/dma-buf/heaps/secure_heap.c | 588 > > > > > > 3 files changed, 606 insertions(+), 4 deletions(-) > > > create mode 100644 drivers/dma-buf/heaps/secure_heap.c > > > > > > diff --git a/drivers/dma-buf/heaps/Kconfig b/drivers/dma- > > > buf/heaps/Kconfig > > > index 6a33193a7b3e..b2406932192e 100644 > > > --- a/drivers/dma-buf/heaps/Kconfig > > > +++ b/drivers/dma-buf/heaps/Kconfig > > > @@ -1,8 +1,12 @@ > > > -config DMABUF_HEAPS_DEFERRED_FREE > > > - tristate > > > +menuconfig DMABUF_HEAPS_DEFERRED_FREE > > > + bool "DMA-BUF heaps deferred-free library" > > > + help > > > + Choose this option to enable the DMA-BUF heaps deferred- > > > free library. > > > > > > -config DMABUF_HEAPS_PAGE_POOL > > > - tristate > > > +menuconfig DMABUF_HEAPS_PAGE_POOL > > > + bool "DMA-BUF heaps page-pool library" > > > + help > > > + Choose this option to enable the DMA-BUF heaps page-pool > > > library. > > > > > > config DMABUF_HEAPS_SYSTEM > > > bool "DMA-BUF System Heap" > > > @@ -26,3 +30,12 @@ config DMABUF_HEAPS_DSP > > >Choose this option to enable the dsp dmabuf heap. The > > > dsp heap > > >is allocated by gen allocater. it's allocated according > > > the dts. > > >If in doubt, say Y. > > > + > > > +config DMABUF_HEAPS_SECURE > > > + tristate "DMA-BUF Secure Heap" > > > + depends on DMABUF_HEAPS && DMABUF_HEAPS_DEFERRED_FREE > > > + help > > > + Choose this option to enable the secure dmabuf heap. The > > > secure heap > > > + pools are defined according to the DT.
Re: [PATCH 3/5] dma-buf: heaps: add Linaro secure dmabuf heap support
Hi Olivier,
Some comments below as I mentioned off-list.
One additional point: some devices need to know if a buffer is
protected, so that they can configure registers appropriately to make
use of that protected buffer. There was previously a discussion about
adding a flag to a dma_buf to indicate that it is allocated from
protected memory[1].
[1] https://lists.freedesktop.org/archives/dri-devel/2019-September/238059.html
On Tue, Aug 02, 2022 at 11:58:41AM +0200, Olivier Masse wrote:
> add Linaro secure heap bindings: linaro,secure-heap
> use genalloc to allocate/free buffer from buffer pool.
> buffer pool info is from dts.
> use sg_table instore the allocated memory info, the length of sg_table is 1.
> implement secure_heap_buf_ops to implement buffer share in difference device:
> 1. Userspace passes this fd to all drivers it wants this buffer
> to share with: First the filedescriptor is converted to a _buf using
> dma_buf_get(). Then the buffer is attached to the device using
> dma_buf_attach().
> 2. Once the buffer is attached to all devices userspace can initiate DMA
> access to the shared buffer. In the kernel this is done by calling
> dma_buf_map_attachment()
> 3. get sg_table with dma_buf_map_attachment in difference device.
>
> Signed-off-by: Olivier Masse
> ---
> drivers/dma-buf/heaps/Kconfig | 21 +-
> drivers/dma-buf/heaps/Makefile | 1 +
> drivers/dma-buf/heaps/secure_heap.c | 588
> 3 files changed, 606 insertions(+), 4 deletions(-)
> create mode 100644 drivers/dma-buf/heaps/secure_heap.c
>
> diff --git a/drivers/dma-buf/heaps/Kconfig b/drivers/dma-buf/heaps/Kconfig
> index 6a33193a7b3e..b2406932192e 100644
> --- a/drivers/dma-buf/heaps/Kconfig
> +++ b/drivers/dma-buf/heaps/Kconfig
> @@ -1,8 +1,12 @@
> -config DMABUF_HEAPS_DEFERRED_FREE
> - tristate
> +menuconfig DMABUF_HEAPS_DEFERRED_FREE
> + bool "DMA-BUF heaps deferred-free library"
> + help
> + Choose this option to enable the DMA-BUF heaps deferred-free library.
>
> -config DMABUF_HEAPS_PAGE_POOL
> - tristate
> +menuconfig DMABUF_HEAPS_PAGE_POOL
> + bool "DMA-BUF heaps page-pool library"
> + help
> + Choose this option to enable the DMA-BUF heaps page-pool library.
>
> config DMABUF_HEAPS_SYSTEM
> bool "DMA-BUF System Heap"
> @@ -26,3 +30,12 @@ config DMABUF_HEAPS_DSP
>Choose this option to enable the dsp dmabuf heap. The dsp heap
>is allocated by gen allocater. it's allocated according the dts.
>If in doubt, say Y.
> +
> +config DMABUF_HEAPS_SECURE
> + tristate "DMA-BUF Secure Heap"
> + depends on DMABUF_HEAPS && DMABUF_HEAPS_DEFERRED_FREE
> + help
> + Choose this option to enable the secure dmabuf heap. The secure heap
> + pools are defined according to the DT. Heaps are allocated
> + in the pools using gen allocater.
> + If in doubt, say Y.
> diff --git a/drivers/dma-buf/heaps/Makefile b/drivers/dma-buf/heaps/Makefile
> index e70722ea615e..08f6aa5919d1 100644
> --- a/drivers/dma-buf/heaps/Makefile
> +++ b/drivers/dma-buf/heaps/Makefile
> @@ -4,3 +4,4 @@ obj-$(CONFIG_DMABUF_HEAPS_PAGE_POOL) += page_pool.o
> obj-$(CONFIG_DMABUF_HEAPS_SYSTEM)+= system_heap.o
> obj-$(CONFIG_DMABUF_HEAPS_CMA) += cma_heap.o
> obj-$(CONFIG_DMABUF_HEAPS_DSP) += dsp_heap.o
> +obj-$(CONFIG_DMABUF_HEAPS_SECURE)+= secure_heap.o
> diff --git a/drivers/dma-buf/heaps/secure_heap.c
> b/drivers/dma-buf/heaps/secure_heap.c
> new file mode 100644
> index ..31aac5d050b4
> --- /dev/null
> +++ b/drivers/dma-buf/heaps/secure_heap.c
> @@ -0,0 +1,588 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * DMABUF secure heap exporter
> + *
> + * Copyright 2021 NXP.
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#include "deferred-free-helper.h"
> +#include "page_pool.h"
> +
> +#define MAX_SECURE_HEAP 2
> +#define MAX_HEAP_NAME_LEN 32
> +
> +struct secure_heap_buffer {
> + struct dma_heap *heap;
> + struct list_head attachments;
> + struct mutex lock;
> + unsigned long len;
> + struct sg_table sg_table;
> + int vmap_cnt;
> + struct deferred_freelist_item deferred_free;
> + void *vaddr;
> + bool uncached;
> +};
> +
> +struct dma_heap_attachment {
> + struct device *dev;
> + struct sg_table *table;
> + struct list_head list;
> + bool no_map;
> + bool mapped;
> + bool uncached;
> +};
I think dma_heap_attachment should have a more specific name,
otherwise it looks like some generic part of the dma_heap framework.
> +
> +struct secure_heap_info {
> + struct gen_pool *pool;
> +
> + bool no_map;
> +};
> +
> +struct rmem_secure {
> + phys_addr_t base;
> + phys_addr_t size;
> +
> + char name[MAX_HEAP_NAME_LEN];
> +
> + bool no_map;
> +};
Re: [PATCH v4] dma-buf: Add a capabilities directory
On Thu, Jun 02, 2022 at 08:47:56AM +0200, Daniel Vetter wrote: > > Two expand on this: > > - compositor opens the drm render /dev node > - compositor initializes the opengl or vulkan userspace driver on top of that > - compositor asks that userspace driver to allocate some buffer, which > can be pretty expensive > - compositor asks the userspace driver to export that buffer into a dma-buf > - compositor can finally do the test ioctl, realizes support isn't > there and tosses the entire thing > > read() on a sysfs file is so much more reasonable it's not even funny. > What about dma-buf heaps? That should be a shorter route to getting a dma-buf fd if that's all that's needed. Cheers, -Brian
Re: [PATCH] drm/arm/malidp: Stop using iommu_present()
Hi Robin,
On Tue, Apr 05, 2022 at 03:11:18PM +0100, Robin Murphy wrote:
> iommu_get_domain_for_dev() is already perfectly happy to return NULL
> if the given device has no IOMMU. Drop the unnecessary check.
>
> Signed-off-by: Robin Murphy
LGTM, Acked-by: Brian Starkey
I'll have to leave it to Liviu to push though.
Thanks,
-Brian
> ---
> drivers/gpu/drm/arm/malidp_planes.c | 14 +-
> 1 file changed, 5 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/gpu/drm/arm/malidp_planes.c
> b/drivers/gpu/drm/arm/malidp_planes.c
> index 0562bdaac00c..81d9f5004025 100644
> --- a/drivers/gpu/drm/arm/malidp_planes.c
> +++ b/drivers/gpu/drm/arm/malidp_planes.c
> @@ -310,17 +310,13 @@ static int malidp_se_check_scaling(struct malidp_plane
> *mp,
>
> static u32 malidp_get_pgsize_bitmap(struct malidp_plane *mp)
> {
> - u32 pgsize_bitmap = 0;
> + struct iommu_domain *mmu_dom;
>
> - if (iommu_present(_bus_type)) {
> - struct iommu_domain *mmu_dom =
> - iommu_get_domain_for_dev(mp->base.dev->dev);
> + mmu_dom = iommu_get_domain_for_dev(mp->base.dev->dev);
> + if (mmu_dom)
> + return mmu_dom->pgsize_bitmap;
>
> - if (mmu_dom)
> - pgsize_bitmap = mmu_dom->pgsize_bitmap;
> - }
> -
> - return pgsize_bitmap;
> + return 0;
> }
>
> /*
> --
> 2.28.0.dirty
>
Re: [PATCH] drm: mali-dp: potential dereference of null pointer
Hi,
On Tue, Dec 14, 2021 at 06:08:37PM +0800, Jiasheng Jiang wrote:
> The return value of kzalloc() needs to be checked.
> To avoid use of null pointer '>base' in case of the
> failure of alloc.
>
> Fixes: 99665d072183 ("drm: mali-dp: add malidp_crtc_state struct")
> Signed-off-by: Jiasheng Jiang
> ---
You can add my r-b to this one too. Thanks!
> drivers/gpu/drm/arm/malidp_crtc.c | 5 -
> 1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/arm/malidp_crtc.c
> b/drivers/gpu/drm/arm/malidp_crtc.c
> index 494075ddbef6..b5928b52e279 100644
> --- a/drivers/gpu/drm/arm/malidp_crtc.c
> +++ b/drivers/gpu/drm/arm/malidp_crtc.c
> @@ -487,7 +487,10 @@ static void malidp_crtc_reset(struct drm_crtc *crtc)
> if (crtc->state)
> malidp_crtc_destroy_state(crtc, crtc->state);
>
> - __drm_atomic_helper_crtc_reset(crtc, >base);
> + if (state)
> + __drm_atomic_helper_crtc_reset(crtc, >base);
> + else
> + __drm_atomic_helper_crtc_reset(crtc, NULL);
> }
>
> static int malidp_crtc_enable_vblank(struct drm_crtc *crtc)
> --
> 2.25.1
>
Re: [PATCH] drm/arm/mali: potential dereference of null pointer
Hi Jiasheng,
Thanks for the patch, that's a careless copy-paste on my part :-(
On Tue, Dec 14, 2021 at 06:00:00PM +0800, Jiasheng Jiang wrote:
> The return value of kzalloc() needs to be checked.
> To avoid use of null pointer '_state->base' in case of the
> failure of alloc.
>
> Fixes: 8cbc5caf36ef ("drm: mali-dp: Add writeback connector")
> Signed-off-by: Jiasheng Jiang
> ---
Reviewed-by: Brian Starkey
> drivers/gpu/drm/arm/malidp_mw.c | 6 +-
> 1 file changed, 5 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/arm/malidp_mw.c b/drivers/gpu/drm/arm/malidp_mw.c
> index f5847a79dd7e..612d386ee7d2 100644
> --- a/drivers/gpu/drm/arm/malidp_mw.c
> +++ b/drivers/gpu/drm/arm/malidp_mw.c
> @@ -70,7 +70,11 @@ static void malidp_mw_connector_reset(struct drm_connector
> *connector)
> __drm_atomic_helper_connector_destroy_state(connector->state);
>
> kfree(connector->state);
> - __drm_atomic_helper_connector_reset(connector, _state->base);
> +
> + if (mw_state)
> + __drm_atomic_helper_connector_reset(connector, _state->base);
> + else
> + __drm_atomic_helper_connector_reset(connector, NULL);
> }
>
> static enum drm_connector_status
> --
> 2.25.1
>
Re: [PATCH] drm: check drm_format_info hsub and vsub to avoid divide by zero
Hi, On Fri, Oct 29, 2021 at 09:15:28AM -0400, George Kennedy wrote: > > Asking if you have any input on how to deal with hsub and vsub = zero? That's just a straight mistake on those formats - they should be 1. My bad for not spotting it in review. On the one hand, having formats in this table is a nice machine-readable way to describe them. On the other, as drm_fourcc is being used as the canonical repository for formats, including ones not used in DRM, we can end up with situations like this. (R10/R12 being another example of formats not used in DRM: 20211027233140.12268-1-laurent.pinch...@ideasonboard.com) Thanks, -Brian
Re: [RFC PATCH v3 1/6] drm/doc: Color Management and HDR10 RFC
On Fri, Aug 13, 2021 at 10:42:12AM +0530, Sharma, Shashank wrote: > Hello Brian, > (+Uma in cc) > > Thanks for your comments, Let me try to fill-in for Harry to keep the design > discussion going. Please find my comments inline. > > On 8/2/2021 10:00 PM, Brian Starkey wrote: > > -- snip -- > > > > Android doesn't blend in linear space, so any API shouldn't be built > > around an assumption of linear blending. > > > > If I am not wrong, we still need linear buffers for accurate Gamut > transformation (SRGB -> BT2020 or other way around) isn't it ? Yeah, you need to transform the buffer to linear for color gamut conversions, but then back to non-linear (probably sRGB or gamma 2.2) for actual blending. This is why I'd like to have the per-plane "OETF/GAMMA" separate from tone-mapping, so that the composition transfer function is independent. > ... > > > + > > > +Tonemapping in this case could be a simple nits value or `EDR`_ to > > > describe > > > +how to scale the :ref:`SDR luminance`. > > > + > > > +Tonemapping could also include the ability to use a 3D LUT which might be > > > +accompanied by a 1D shaper LUT. The shaper LUT is required in order to > > > +ensure a 3D LUT with limited entries (e.g. 9x9x9, or 17x17x17) operates > > > +in perceptual (non-linear) space, so as to evenly spread the limited > > > +entries evenly across the perceived space. > > > > Some terminology care may be needed here - up until this point, I > > think you've been talking about "tonemapping" being luminance > > adjustment, whereas I'd expect 3D LUTs to be used for gamut > > adjustment. > > > > IMO, what harry wants to say here is that, which HW block gets picked and > how tone mapping is achieved can be a very driver/HW specific thing, where > one driver can use a 1D/Fixed function block, whereas another one can choose > more complex HW like a 3D LUT for the same. > > DRM layer needs to define only the property to hook the API with core > driver, and the driver can decide which HW to pick and configure for the > activity. So when we have a tonemapping property, we might not have a > separate 3D-LUT property, or the driver may fail the atomic_check() if both > of them are programmed for different usages. I still think that directly exposing the HW blocks and their capabilities is the right approach, rather than a "magic" tonemapping property. Yes, userspace would need to have a good understanding of how to use that hardware, but if the pipeline model is standardised that's the kind of thing a cross-vendor library could handle. It would definitely be good to get some compositor opinions here. Cheers, -Brian
Re: [RFC PATCH v3 1/6] drm/doc: Color Management and HDR10 RFC
Hi, Thanks for having a stab at this, it's a massive complex topic to solve. Do you have the the HTML rendered somewhere for convenience? On Fri, Jul 30, 2021 at 04:41:29PM -0400, Harry Wentland wrote: > Use the new DRM RFC doc section to capture the RFC previously only > described in the cover letter at > https://patchwork.freedesktop.org/series/89506/ > > v3: > * Add sections on single-plane and multi-plane HDR > * Describe approach to define HW details vs approach to define SW intentions > * Link Jeremy Cline's excellent HDR summaries > * Outline intention behind overly verbose doc > * Describe FP16 use-case > * Clean up links > > v2: create this doc > > v1: n/a > > Signed-off-by: Harry Wentland > --- > Documentation/gpu/rfc/color_intentions.drawio | 1 + > Documentation/gpu/rfc/color_intentions.svg| 3 + > Documentation/gpu/rfc/colorpipe | 1 + > Documentation/gpu/rfc/colorpipe.svg | 3 + > Documentation/gpu/rfc/hdr-wide-gamut.rst | 580 ++ > Documentation/gpu/rfc/index.rst | 1 + > 6 files changed, 589 insertions(+) > create mode 100644 Documentation/gpu/rfc/color_intentions.drawio > create mode 100644 Documentation/gpu/rfc/color_intentions.svg > create mode 100644 Documentation/gpu/rfc/colorpipe > create mode 100644 Documentation/gpu/rfc/colorpipe.svg > create mode 100644 Documentation/gpu/rfc/hdr-wide-gamut.rst > -- snip -- > + > +Mastering Luminances > + > + > +Even though we are able to describe the absolute luminance of a pixel > +using the PQ 2084 EOTF we are presented with physical limitations of the > +display technologies on the market today. Here are a few examples of > +luminance ranges of displays. > + > +.. flat-table:: > + :header-rows: 1 > + > + * - Display > + - Luminance range in nits > + > + * - Typical PC display > + - 0.3 - 200 > + > + * - Excellent LCD HDTV > + - 0.3 - 400 > + > + * - HDR LCD w/ local dimming > + - 0.05 - 1,500 > + > +Since no display can currently show the full 0.0005 to 10,000 nits > +luminance range of PQ the display will need to tone-map the HDR content, > +i.e to fit the content within a display's capabilities. To assist > +with tone-mapping HDR content is usually accompanied by a metadata > +that describes (among other things) the minimum and maximum mastering > +luminance, i.e. the maximum and minimum luminance of the display that > +was used to master the HDR content. > + > +The HDR metadata is currently defined on the drm_connector via the > +hdr_output_metadata blob property. > + > +It might be useful to define per-plane hdr metadata, as different planes > +might have been mastered differently. I think this only applies to the approach where all the processing is decided in the kernel right? If we directly expose each pipeline stage, and userspace controls everything, there's no need for the kernel to know the mastering luminance of any of the input content. The kernel would only need to know the eventual *output* luminance range, which might not even match any of the input content! ... > + > +How are we solving the problem? > +=== > + > +Single-plane > + > + > +If a single drm_plane is used no further work is required. The compositor > +will provide one HDR plane alongside a drm_connector's hdr_output_metadata > +and the display HW will output this plane without further processing if > +no CRTC LUTs are provided. > + > +If desired a compositor can use the CRTC LUTs for HDR content but without > +support for PWL or multi-segmented LUTs the quality of the operation is > +expected to be subpar for HDR content. > + > + > +Multi-plane > +--- > + > +In multi-plane configurations we need to solve the problem of blending > +HDR and SDR content. This blending should be done in linear space and > +therefore requires framebuffer data that is presented in linear space > +or a way to convert non-linear data to linear space. Additionally > +we need a way to define the luminance of any SDR content in relation > +to the HDR content. > + Android doesn't blend in linear space, so any API shouldn't be built around an assumption of linear blending. > +In order to present framebuffer data in linear space without losing a > +lot of precision it needs to be presented using 16 bpc precision. > + > + > +Defining HW Details > +--- > + > +One way to take full advantage of modern HW's color pipelines is by > +defining a "generic" pipeline that matches all capable HW. Something > +like this, which I took `from Uma Shankar`_ and expanded on: > + > +.. _from Uma Shankar: https://patchwork.freedesktop.org/series/90826/ > + > +.. kernel-figure:: colorpipe.svg I don't think this pipeline is expressive enough, in part because of Android's non-linear blending as I mentioned above, but also because the "tonemapping" block is a bit of a monolithic black-box. I'd be in
Re: [PATCH] drm/komeda: Fix off-by-1 when with readback conn due to rounding
(Adding back James again - did you use get_maintainer.pl?) On Thu, Mar 11, 2021 at 12:08:46PM +, carsten.haitz...@foss.arm.com wrote: > From: Carsten Haitzler > > When setting up a readback connector that writes data back to memory > rather than to an actual output device (HDMI etc.), rounding was set > to round. As the DPU uses a higher internal number of bits when generating > a color value, this round-down back to 8bit ended up with everything > being off-by one. e.g. #fefefe became #ff. This sets Perhaps overly pedantic, but now we've tracked down what was actually happening I think we can be more precise here. Not _everything_ is off-by-one, it's just rounding in the standard sense - if the most significant bit-to-be-discarded is set, the value is rounded up to minimise the absolute error introduced by bit-depth reduction. > rounding to "round-down" so things end up correct by turning on the LW_TRC > round down flag. Can we call it "truncate" rather than round down? I think it makes "TRC" a bit more understandable. > > Signed-off-by: Carsten Haitzler > --- > drivers/gpu/drm/arm/display/komeda/d71/d71_component.c | 7 ++- > drivers/gpu/drm/arm/display/komeda/d71/d71_regs.h | 1 + > 2 files changed, 7 insertions(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/arm/display/komeda/d71/d71_component.c > b/drivers/gpu/drm/arm/display/komeda/d71/d71_component.c > index 8a02ade369db..e97acc5519d1 100644 > --- a/drivers/gpu/drm/arm/display/komeda/d71/d71_component.c > +++ b/drivers/gpu/drm/arm/display/komeda/d71/d71_component.c > @@ -468,7 +468,12 @@ static void d71_wb_layer_update(struct komeda_component > *c, > struct komeda_layer_state *st = to_layer_st(state); > struct drm_connector_state *conn_st = state->wb_conn->state; > struct komeda_fb *kfb = to_kfb(conn_st->writeback_job->fb); > - u32 ctrl = L_EN | LW_OFM, mask = L_EN | LW_OFM | LW_TBU_EN; > + /* LW_TRC sets rounding to truncate not round which is needed for > + * the output of writeback to match the input in the most common > + * use cases like RGB888 -> RGB888, so set this bit by default > + */ Hm, not sure why this file uses "net/" style comments, but as you said, this is in-keeping with the rest of the file, so meh :-) > + u32 ctrl = LW_TRC | L_EN | LW_OFM; > + u32 mask = LW_TRC | L_EN | LW_OFM | LW_TBU_EN; If you were aiming for matching register order, this should be: L_EN | LW_TRC | LW_OFM | LW_TBU_EN I think it'd be nice to have the exact behaviour in the commit message, but either way this seems OK as a pragmatic fix so: Reviewed-by: Brian Starkey Thanks, -Brian > u32 __iomem *reg = c->reg; > > d71_layer_update_fb(c, kfb, st->addr); > diff --git a/drivers/gpu/drm/arm/display/komeda/d71/d71_regs.h > b/drivers/gpu/drm/arm/display/komeda/d71/d71_regs.h > index e80172a0b320..a8036689d721 100644 > --- a/drivers/gpu/drm/arm/display/komeda/d71/d71_regs.h > +++ b/drivers/gpu/drm/arm/display/komeda/d71/d71_regs.h > @@ -321,6 +321,7 @@ > #define LAYER_WR_FORMAT 0x0D8 > > /* Layer_WR control bits */ > +#define LW_TRC BIT(1) > #define LW_OFM BIT(4) > #define LW_LALPHA(x) (((x) & 0xFF) << 8) > #define LW_A_WCACHE(x) (((x) & 0xF) << 28) > -- > 2.30.0 > > ___ > dri-devel mailing list > dri-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/komeda: Fix off-by-1 when with readback conn due to rounding
Hi Carsten, (+James for komeda) Thanks for typing this up. On Fri, Mar 05, 2021 at 04:38:53PM +, carsten.haitz...@foss.arm.com wrote: > From: Carsten Haitzler > > When setting up a readback conenctor that writes data back to memory s/readback conenctor/writeback connector/ (similar in the subject) > rather than to an actual output device (HDMI etc.), rounding was ses s/ses/set/ > to round-down. As the DPU uses a higher internal number of bits when "round-down" isn't really accurate - the rounding mode "rounds" based on the most-significant discarded bit - so can round-up too. Come to think of it, I can't explain 0xff becoming 0xfe, but still, truncation is likely fine. > generating a color value, this round-down back to 8bit ended up with > everything being off-by one. e.g. #ff became #fefefe. This sets > rounding to "round" so things end up correct by turning on the round > flag (LW_TRC). LW_TRC is the truncation flag. 0: Round, 1: Truncate > > Signed-off-by: Carsten Haitzler > --- > drivers/gpu/drm/arm/display/komeda/d71/d71_component.c | 6 +- > drivers/gpu/drm/arm/display/komeda/d71/d71_regs.h | 1 + > 2 files changed, 6 insertions(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/arm/display/komeda/d71/d71_component.c > b/drivers/gpu/drm/arm/display/komeda/d71/d71_component.c > index 8a02ade369db..d551e79fa0f1 100644 > --- a/drivers/gpu/drm/arm/display/komeda/d71/d71_component.c > +++ b/drivers/gpu/drm/arm/display/komeda/d71/d71_component.c > @@ -468,7 +468,11 @@ static void d71_wb_layer_update(struct komeda_component > *c, > struct komeda_layer_state *st = to_layer_st(state); > struct drm_connector_state *conn_st = state->wb_conn->state; > struct komeda_fb *kfb = to_kfb(conn_st->writeback_job->fb); > - u32 ctrl = L_EN | LW_OFM, mask = L_EN | LW_OFM | LW_TBU_EN; > + /* LW_TRC sets rounding to round not truncate which is needed for > + * the output of writeback to match the input in the most common > + * use cases like RGB888 -> RGB888, so set this bit by default */ /* * Comment style should be like this */ Same as above though - your description is inverted. By setting the LW_TRC bit, you're forcing the hardware to truncate instead of round. > + u32 ctrl = L_EN | LW_OFM | LW_TRC; > + u32 mask = L_EN | LW_OFM | LW_TBU_EN | LW_TRC; Really nitpicking, but I think it'd be good to keep these in the same order as the bits in the register: L_EN | LW_TRC | LW_OFM | LW_TBU_EN Cheers, -Brian > u32 __iomem *reg = c->reg; > > d71_layer_update_fb(c, kfb, st->addr); > diff --git a/drivers/gpu/drm/arm/display/komeda/d71/d71_regs.h > b/drivers/gpu/drm/arm/display/komeda/d71/d71_regs.h > index e80172a0b320..a8036689d721 100644 > --- a/drivers/gpu/drm/arm/display/komeda/d71/d71_regs.h > +++ b/drivers/gpu/drm/arm/display/komeda/d71/d71_regs.h > @@ -321,6 +321,7 @@ > #define LAYER_WR_FORMAT 0x0D8 > > /* Layer_WR control bits */ > +#define LW_TRC BIT(1) > #define LW_OFM BIT(4) > #define LW_LALPHA(x) (((x) & 0xFF) << 8) > #define LW_A_WCACHE(x) (((x) & 0xF) << 28) > -- > 2.30.0 > > ___ > dri-devel mailing list > dri-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/rockchip: Require the YTR modifier for AFBC
On Wed, Feb 24, 2021 at 04:06:05PM +, Daniel Stone wrote: > Android punted on that from the beginning and just uses > XBGR for everything ... so it's not really a matter of dumb vs. smart > userspace, just equally dumb userspaces which disagree with each > other. ;) ...apart from HAL_PIXEL_FORMAT_RGB_565, which has the opposite component order despite having the same "name" order. So Android disagrees with itself, too. Sigh, pixel formats are awful. -Brian ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/rockchip: Require the YTR modifier for AFBC
On Tue, Feb 23, 2021 at 05:10:16PM +, Alyssa Rosenzweig wrote:
> > If YTR can't be turned off, then according to the AFBC spec - correct.
>
> There is no public AFBC spec, so I'm not sure how to respond to this.
>
> > If the hardware allows it to be configured to use YTR with other
> > component orders, I don't know exactly what the impact would be -
> > maybe nothing.
>
> It's legal to use YTR with a BGR framebuffer regardless of the content
> of the framebuffer, yes? Could I postprocess with the following shader?
>
> void main() {
> vec4 colour = ;
> gl_FragColor = colour.bgra;
> }
>
> That's just 3D rendering. But now if I feed that rendered "BGR"
> framebuffer in I get the illusion of RGB out.
>
> Doing the colourspace conversion in hardware (with the
> GPU's component reordering) is mathematically indistinguishable from
> rendering BGR with that shader.
I agree that *if* all 2^24 possible values of BGR 8:8:8 can be
perfectly and "invert-ably" converted, then it shouldn't matter what
color channel is in which slot, mathematically speaking.
>
> I sympathize with reducing AFBC's combinatoric explosion, and I realize
> that the Rockchip VOP is probably wrong. I also realize that the
> transform is defined for BGR inputs, not RGB ones, so it might be
> slightly less effective for real content.
Yes, I think the practical impact is likely to be compression
efficiency.
> But it seems to me allowing
> both BGR+YTR and RGB+YTR upstream is the better route than simply
> preventing hardware from using AFBC at all, and there are natural
> encodings for both with fourcc modifiers.
>
Are those the only options? I see XBGR, ABGR, BGR888 and
BGR565 are all handled in vop_convert_afbc_format(), which are all
"valid" for use with YTR, and all except XBGR are on the "preferred"
AFBC format list in afbc.rst.
> Maybe there's a deeper reason to require BGR that I'm missing? Please
> let me know if I've misunderstood, I only know AFBC from the GPU side.
If deeper reason means "a reason that the chip will explode if you use
RGB" then I'm not aware of one.
As you've said above, combinatoric explosion is a real issue with
AFBC, so there's a certain subset which Arm has declared "valid", and
an even smaller subset which forms part of conformance testing
(...also not public). The "valid" usage, and a set of preferred
formats are documented in afbc.rst, which is the closest thing I have
to a public spec.
I was _hoping_ we could limit upstream implementations to at least the
subset which Arm declares "valid", with a preference for the subset
which forms part of the conformance set - because those are the ones
likely to be supported across the widest set of hardware. *But*, I'm
also very aware that waving around "invisible" specifications doesn't
carry much weight upstream versus actual code and hardware _doing
stuff_.
So, all I can really do here is say "spec says this isn't allowed",
and make the point that I expect (though I don't 100% know for sure)
all hardware that supports AFBC to also support BGR order AFBC. With
that in mind, if I were trying to implement AFBC in a way that's
likely to work across multiple platforms, I'd go with BGR order.
Thanks,
-Brian
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/rockchip: Require the YTR modifier for AFBC
On Tue, Feb 23, 2021 at 03:29:13PM +, Daniel Stone wrote: > On Tue, 23 Feb 2021 at 14:58, Brian Starkey wrote: > > On Tue, Feb 23, 2021 at 02:27:11PM +, Daniel Stone wrote: > > > Mark, or others from Rockchip, can you please: > > > - explain if there is a way to enable/disable the YTR transform in the > > > VOP's AFBC decoder, similar to the split-block control bit? > > > - ack this patch which correctly declares that the YTR transform is in > > > use in order to make Panfrost work, so it can be merged through > > > drm-misc, or provide another solution which fixes this API mistake? > > > - if VOP does have a hidden YTR-disable bit, add support to disable > > > YTR so rockchip-drm can continue advertising the non-YTR modifier, and > > > Cc this patch for backporting to every kernel tree which declares AFBC > > > modifier support? > > > > Drive-by $0.02: > > > > As described in https://www.kernel.org/doc/Documentation/gpu/afbc.rst, > > YTR is only valid for "BGR" component order, so this shouldn't be set > > or used for "RGB" order (or YUV) formats. For BGR-order formats, it's > > best to always enable YTR to get the best compression ratio. > > > > In an ideal world, there wouldn't be hardware/drivers which > > support/allow non-standard encodings, but we don't live in that world > > :-( > > This implies that RGB component ordering cannot be used together with > AFBC on RK3399, no? If YTR can't be turned off, then according to the AFBC spec - correct. If the hardware allows it to be configured to use YTR with other component orders, I don't know exactly what the impact would be - maybe nothing. I raised some of these concerns when the patches were first sent: https://lore.kernel.org/dri-devel/20190925093913.z4vduybwcokn3awi@DESKTOP-E1NTVVP.localdomain/ We wrote the .rst doc to try and avoid incompatibilities between different drivers and parts of the stack. BGR is Arm's preferred order for AFBC. Unfortunately amongst shifting organisations and priorities, AFBC in upstream hasn't got much attention. Cheers, -Brian > > Cheers, > Daniel ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/rockchip: Require the YTR modifier for AFBC
Hi, On Tue, Feb 23, 2021 at 02:27:11PM +, Daniel Stone wrote: > Mark, or others from Rockchip, can you please: > - explain if there is a way to enable/disable the YTR transform in the > VOP's AFBC decoder, similar to the split-block control bit? > - ack this patch which correctly declares that the YTR transform is in > use in order to make Panfrost work, so it can be merged through > drm-misc, or provide another solution which fixes this API mistake? > - if VOP does have a hidden YTR-disable bit, add support to disable > YTR so rockchip-drm can continue advertising the non-YTR modifier, and > Cc this patch for backporting to every kernel tree which declares AFBC > modifier support? > Drive-by $0.02: As described in https://www.kernel.org/doc/Documentation/gpu/afbc.rst, YTR is only valid for "BGR" component order, so this shouldn't be set or used for "RGB" order (or YUV) formats. For BGR-order formats, it's best to always enable YTR to get the best compression ratio. In an ideal world, there wouldn't be hardware/drivers which support/allow non-standard encodings, but we don't live in that world :-( -Brian > Thanks in advance. > > Cheers, > Daniel > ___ > dri-devel mailing list > dri-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4] Add power/gpu_frequency tracepoint.
Hi Peiyong, On Mon, Nov 30, 2020 at 02:33:59PM -0800, Peiyong Lin wrote: > On Tue, Nov 17, 2020 at 1:31 PM Peiyong Lin wrote: > > > > On Thu, Oct 22, 2020 at 10:34 AM Peiyong Lin wrote: > > > > > > Historically there is no common trace event for GPU frequency, in > > > downstream Android each different hardware vendor implements their own > > > way to expose GPU frequency, for example as a debugfs node. This patch > > > standardize it as a common trace event in upstream linux kernel to help > > > the ecosystem have a common implementation across hardware vendors. > > > Toolings in the Linux ecosystem will benefit from this especially in the > > > downstream Android, where this information is critical to graphics > > > developers. > > > > > > Signed-off-by: Peiyong Lin > > > --- > > > > > > Changelog since v3: > > > - Correct copyright title. > > > > > > Changelog since v2: > > > - Add more comments to indicate when the event should be emitted. > > > - Change state to frequency. > > > > > > Changelog since v1: > > > - Use %u in TP_printk > > > > > > drivers/gpu/Makefile| 1 + > > > drivers/gpu/trace/Kconfig | 3 +++ > > > drivers/gpu/trace/Makefile | 1 + > > > drivers/gpu/trace/trace_gpu_frequency.c | 13 ++ > > > include/trace/events/power.h| 33 + > > > 5 files changed, 51 insertions(+) > > > create mode 100644 drivers/gpu/trace/trace_gpu_frequency.c > > > > > > diff --git a/drivers/gpu/Makefile b/drivers/gpu/Makefile > > > index 835c88318cec..f289a47eb031 100644 > > > --- a/drivers/gpu/Makefile > > > +++ b/drivers/gpu/Makefile > > > @@ -6,3 +6,4 @@ obj-$(CONFIG_TEGRA_HOST1X) += host1x/ > > > obj-y += drm/ vga/ > > > obj-$(CONFIG_IMX_IPUV3_CORE) += ipu-v3/ > > > obj-$(CONFIG_TRACE_GPU_MEM)+= trace/ > > > +obj-$(CONFIG_TRACE_GPU_FREQUENCY) += trace/ > > > diff --git a/drivers/gpu/trace/Kconfig b/drivers/gpu/trace/Kconfig > > > index c24e9edd022e..ac4aec8d5845 100644 > > > --- a/drivers/gpu/trace/Kconfig > > > +++ b/drivers/gpu/trace/Kconfig > > > @@ -2,3 +2,6 @@ > > > > > > config TRACE_GPU_MEM > > > bool > > > + > > > +config TRACE_GPU_FREQUENCY > > > + bool > > > diff --git a/drivers/gpu/trace/Makefile b/drivers/gpu/trace/Makefile > > > index b70fbdc5847f..2b7ae69327d6 100644 > > > --- a/drivers/gpu/trace/Makefile > > > +++ b/drivers/gpu/trace/Makefile > > > @@ -1,3 +1,4 @@ > > > # SPDX-License-Identifier: GPL-2.0 > > > > > > obj-$(CONFIG_TRACE_GPU_MEM) += trace_gpu_mem.o > > > +obj-$(CONFIG_TRACE_GPU_FREQUENCY) += trace_gpu_frequency.o > > > diff --git a/drivers/gpu/trace/trace_gpu_frequency.c > > > b/drivers/gpu/trace/trace_gpu_frequency.c > > > new file mode 100644 > > > index ..668fabd6b77a > > > --- /dev/null > > > +++ b/drivers/gpu/trace/trace_gpu_frequency.c > > > @@ -0,0 +1,13 @@ > > > +// SPDX-License-Identifier: GPL-2.0 > > > +/* > > > + * GPU frequency trace points > > > + * > > > + * Copyright (C) 2020 Google LLC > > > + */ > > > + > > > +#include > > > + > > > +#define CREATE_TRACE_POINTS > > > +#include > > > + > > > +EXPORT_TRACEPOINT_SYMBOL(gpu_frequency); > > > diff --git a/include/trace/events/power.h b/include/trace/events/power.h > > > index af5018aa9517..343825a76953 100644 > > > --- a/include/trace/events/power.h > > > +++ b/include/trace/events/power.h > > > @@ -500,6 +500,39 @@ DEFINE_EVENT(dev_pm_qos_request, > > > dev_pm_qos_remove_request, > > > > > > TP_ARGS(name, type, new_value) > > > ); > > > + > > > +/** > > > + * gpu_frequency - Reports the GPU frequency in GPU clock domains. > > > + * > > > + * This event should be emitted whenever there's a GPU frequency change > > > happens, > > > + * or a GPU goes from idle state to active state, or vice versa. > > > + * > > > + * When the GPU goes from idle state to active state, this event should > > > report > > > + * the GPU frequency of the active state. When the GPU goes from active > > > state to > > > + * idle state, this event should report a zero frequency value. > > > + * > > > + * @frequency: New frequency (in KHz) > > > + * @gpu_id: Id for each GPU clock domain Thinking about options for how to assign this, there are a few existing tracepoints (I see block device and jb2) which use dev_t, so perhaps that would be an option. We'd still want to be able to expose multiple clocks per device though, either with a separate field or with a defined packing into this one. dev_t is a little bit tricky because the packing can (is?) different between the kernel and C library. major + minor + clock domain as 3 separate fields would be the most explicit. As the intended use-case is tools, I imagine userspace will want to link this to data exposed via other APIs, so gpu_id needs to somehow allow that. That probably means some opaque integer assigned within the kernel isn't OK. Hopefully some other vendors have thoughts on what
Re: [PATCH v2] drm: document that user-space should avoid parsing EDIDs
On Thu, Oct 22, 2020 at 10:34:44AM +, Simon Ser wrote:
> User-space should avoid parsing EDIDs for metadata already exposed via
> other KMS interfaces and properties. For instance, user-space should not
> try to extract a list of modes from the EDID: the kernel might mutate
> the mode list (because of link capabilities or quirks for instance).
>
> Other metadata not exposed by KMS can be parsed by user-space. This
> includes for instance monitor identification (make/model/serial) and
> supported color-spaces.
>
> v2: add short explanation why user-space shouldn't do this (Brian)
LGTM, thanks.
-Brian
>
> Signed-off-by: Simon Ser
> Suggested-by: Daniel Vetter
> Reviewed-by: Daniel Vetter
> Acked-by: Thomas Zimmermann
> Cc: Pekka Paalanen
> Cc: Ville Syrj�l�
> Cc: Brian Starkey
> ---
> drivers/gpu/drm/drm_connector.c | 5 +
> 1 file changed, 5 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
> index 717c4e7271b0..1913d8b4e16a 100644
> --- a/drivers/gpu/drm/drm_connector.c
> +++ b/drivers/gpu/drm/drm_connector.c
> @@ -960,6 +960,11 @@ static const struct drm_prop_enum_list dp_colorspaces[]
> = {
> * drm_connector_update_edid_property(), usually after having parsed
> * the EDID using drm_add_edid_modes(). Userspace cannot change this
> * property.
> + *
> + * User-space should not parse the EDID to obtain information exposed via
> + * other KMS properties (because the kernel might apply limits, quirks or
> + * fixups to the EDID). For instance, user-space should not try to parse
> + * mode lists from the EDID.
> * DPMS:
> * Legacy property for setting the power state of the connector. For atomic
> * drivers this is only provided for backwards compatibility with existing
> --
> 2.28.0
>
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2] drm/fourcc: Add AXBXGXRX106106106106 format
Hi Matteo, +Joe to Cc
On Thu, Oct 08, 2020 at 03:33:50PM +0100, Matteo Franchin wrote:
> Add ABGR format with 10-bit components packed in 64-bit per pixel.
> This format can be used to handle
> VK_FORMAT_R10X6G10X6B10X6A10X6_UNORM_4PACK16 on little-endian
> architectures.
>
> Signed-off-by: Matteo Franchin
> ---
> drivers/gpu/drm/drm_fourcc.c | 1 +
> include/uapi/drm/drm_fourcc.h | 6 ++
> 2 files changed, 7 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_fourcc.c b/drivers/gpu/drm/drm_fourcc.c
> index 722c7ebe4e88..03262472059c 100644
> --- a/drivers/gpu/drm/drm_fourcc.c
> +++ b/drivers/gpu/drm/drm_fourcc.c
> @@ -202,6 +202,7 @@ const struct drm_format_info *__drm_format_info(u32
> format)
> { .format = DRM_FORMAT_XBGR16161616F, .depth = 0,
> .num_planes = 1, .cpp = { 8, 0, 0 }, .hsub = 1, .vsub = 1 },
> { .format = DRM_FORMAT_ARGB16161616F, .depth = 0,
> .num_planes = 1, .cpp = { 8, 0, 0 }, .hsub = 1, .vsub = 1, .has_alpha = true
> },
> { .format = DRM_FORMAT_ABGR16161616F, .depth = 0,
> .num_planes = 1, .cpp = { 8, 0, 0 }, .hsub = 1, .vsub = 1, .has_alpha = true
> },
> + { .format = DRM_FORMAT_AXBXGXRX106106106106, .depth = 0,
> .num_planes = 1, .cpp = { 8, 0, 0 }, .hsub = 1, .vsub = 1, .has_alpha = true
> },
I'm OK with it formatted like this tbh. The YUV formats at the bottom
already mess up the formatting of the table as a whole.
If Joe feels strongly about having it split, I don't think that should
hurt grep-ability much for the common cases (grep for format name, or
grep for format parameters). So either way you can add:
Reviewed-by: Brian Starkey
Thanks!
-Brian
> { .format = DRM_FORMAT_RGB888_A8, .depth = 32,
> .num_planes = 2, .cpp = { 3, 1, 0 }, .hsub = 1, .vsub = 1, .has_alpha = true
> },
> { .format = DRM_FORMAT_BGR888_A8, .depth = 32,
> .num_planes = 2, .cpp = { 3, 1, 0 }, .hsub = 1, .vsub = 1, .has_alpha = true
> },
> { .format = DRM_FORMAT_XRGB_A8, .depth = 32,
> .num_planes = 2, .cpp = { 4, 1, 0 }, .hsub = 1, .vsub = 1, .has_alpha = true
> },
> diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
> index 82f327801267..9374d9558493 100644
> --- a/include/uapi/drm/drm_fourcc.h
> +++ b/include/uapi/drm/drm_fourcc.h
> @@ -155,6 +155,12 @@ extern "C" {
> #define DRM_FORMAT_ARGB16161616F fourcc_code('A', 'R', '4', 'H') /* [63:0]
> A:R:G:B 16:16:16:16 little endian */
> #define DRM_FORMAT_ABGR16161616F fourcc_code('A', 'B', '4', 'H') /* [63:0]
> A:B:G:R 16:16:16:16 little endian */
>
> +/*
> + * RGBA format with 10-bit components packed in 64-bit per pixel, with 6 bits
> + * of unused padding per component:
> + */
> +#define DRM_FORMAT_AXBXGXRX106106106106 fourcc_code('A', 'B', '1', '0') /*
> [63:0] A:x:B:x:G:x:R:x 10:6:10:6:10:6:10:6 little endian */
> +
> /* packed YCbCr */
> #define DRM_FORMAT_YUYV fourcc_code('Y', 'U', 'Y', 'V') /*
> [31:0] Cr0:Y1:Cb0:Y0 8:8:8:8 little endian */
> #define DRM_FORMAT_YVYU fourcc_code('Y', 'V', 'Y', 'U') /*
> [31:0] Cb0:Y1:Cr0:Y0 8:8:8:8 little endian */
> --
> 2.17.1
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm: document that user-space should avoid parsing EDIDs
On Fri, Oct 09, 2020 at 09:24:01AM +, Simon Ser wrote:
> User-space should avoid parsing EDIDs for metadata already exposed via
> other KMS interfaces and properties. For instance, user-space should not
> try to extract a list of modes from the EDID: the kernel might mutate
> the mode list (because of link capabilities or quirks for instance).
>
> Other metadata not exposed by KMS can be parsed by user-space. This
> includes for instance monitor identification (make/model/serial) and
> supported color-spaces.
>
> Signed-off-by: Simon Ser
> Suggested-by: Daniel Vetter
> Cc: Daniel Vetter
> Cc: Pekka Paalanen
> Cc: Ville Syrj�l�
> ---
> drivers/gpu/drm/drm_connector.c | 4
> 1 file changed, 4 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
> index 717c4e7271b0..00e58fd2d292 100644
> --- a/drivers/gpu/drm/drm_connector.c
> +++ b/drivers/gpu/drm/drm_connector.c
> @@ -960,6 +960,10 @@ static const struct drm_prop_enum_list dp_colorspaces[]
> = {
> * drm_connector_update_edid_property(), usually after having parsed
> * the EDID using drm_add_edid_modes(). Userspace cannot change this
> * property.
> + *
> + * User-space should not parse the EDID to obtain information exposed via
> + * other KMS properties. For instance, user-space should not try to parse
> + * mode lists from the EDID.
I assume that this is so that the kernel can apply quirks/limits in
cases where it knows it needs to? I think it would be nice to put at
least a few words indicating "why", otherwise this feels like an
arbitrary commandment with no justification.
Cheers,
-Brian
> * DPMS:
> * Legacy property for setting the power state of the connector. For atomic
> * drivers this is only provided for backwards compatibility with existing
> --
> 2.28.0
>
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 7/7] dma-buf: system_heap: Add a system-uncached heap re-using the system heap
On Sat, Oct 03, 2020 at 04:02:57AM +, John Stultz wrote:
> This adds a heap that allocates non-contiguous buffers that are
> marked as writecombined, so they are not cached by the CPU.
>
> This is useful, as most graphics buffers are usually not touched
> by the CPU or only written into once by the CPU. So when mapping
> the buffer over and over between devices, we can skip the CPU
> syncing, which saves a lot of cache management overhead, greatly
> improving performance.
>
> For folk using ION, there was a ION_FLAG_CACHED flag, which
> signaled if the returned buffer should be CPU cacheable or not.
> With DMA-BUF heaps, we do not yet have such a flag, and by default
> the current heaps (system and cma) produce CPU cachable buffers.
> So for folks transitioning from ION to DMA-BUF Heaps, this fills
> in some of that missing functionality.
>
> There has been a suggestion to make this functionality a flag
> (DMAHEAP_FLAG_UNCACHED?) on the system heap, similar to how
> ION used the ION_FLAG_CACHED. But I want to make sure an
> _UNCACHED flag would truely be a generic attribute across all
> heaps. So far that has been unclear, so having it as a separate
> heap seemes better for now. (But I'm open to discussion on this
> point!)
>
> This is a rework of earlier efforts to add a uncached system heap,
> done utilizing the exisitng system heap, adding just a bit of
> logic to handle the uncached case.
>
> Feedback would be very welcome!
>
> Many thanks to Liam Mark for his help to get this working.
>
> Pending opensource users of this code include:
> * AOSP HiKey960 gralloc:
> - https://android-review.googlesource.com/c/device/linaro/hikey/+/1399519
> - Visibly improves performance over the system heap
> * AOSP Codec2 (possibly, needs more review):
> -
> https://android-review.googlesource.com/c/platform/frameworks/av/+/1360640/17/media/codec2/vndk/C2DmaBufAllocator.cpp#325
>
> Cc: Sumit Semwal
> Cc: Liam Mark
> Cc: Laura Abbott
> Cc: Brian Starkey
> Cc: Hridya Valsaraju
> Cc: Suren Baghdasaryan
> Cc: Sandeep Patil
> Cc: Daniel Mentz
> Cc: Chris Goldsworthy
> Cc: �rjan Eide
> Cc: Robin Murphy
> Cc: Ezequiel Garcia
> Cc: Simon Ser
> Cc: James Jones
> Cc: linux-me...@vger.kernel.org
> Cc: dri-devel@lists.freedesktop.org
> Signed-off-by: John Stultz
> ---
> drivers/dma-buf/heaps/system_heap.c | 87 ++---
> 1 file changed, 79 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/dma-buf/heaps/system_heap.c
> b/drivers/dma-buf/heaps/system_heap.c
> index 2b8d4b6abacb..952f1fd9dacf 100644
> --- a/drivers/dma-buf/heaps/system_heap.c
> +++ b/drivers/dma-buf/heaps/system_heap.c
> @@ -22,6 +22,7 @@
> #include
>
> struct dma_heap *sys_heap;
> +struct dma_heap *sys_uncached_heap;
>
> struct system_heap_buffer {
> struct dma_heap *heap;
> @@ -31,6 +32,8 @@ struct system_heap_buffer {
> struct sg_table sg_table;
> int vmap_cnt;
> void *vaddr;
> +
> + bool uncached;
> };
>
> struct dma_heap_attachment {
> @@ -38,6 +41,8 @@ struct dma_heap_attachment {
> struct sg_table *table;
> struct list_head list;
> bool mapped;
> +
> + bool uncached;
> };
>
> #define HIGH_ORDER_GFP (((GFP_HIGHUSER | __GFP_ZERO | __GFP_NOWARN \
> @@ -94,7 +99,7 @@ static int system_heap_attach(struct dma_buf *dmabuf,
> a->dev = attachment->dev;
> INIT_LIST_HEAD(>list);
> a->mapped = false;
> -
> + a->uncached = buffer->uncached;
> attachment->priv = a;
>
> mutex_lock(>lock);
> @@ -124,9 +129,13 @@ static struct sg_table *system_heap_map_dma_buf(struct
> dma_buf_attachment *attac
> {
> struct dma_heap_attachment *a = attachment->priv;
> struct sg_table *table = a->table;
> + int attr = 0;
> int ret;
>
> - ret = dma_map_sgtable(attachment->dev, table, direction, 0);
> + if (a->uncached)
> + attr = DMA_ATTR_SKIP_CPU_SYNC;
> +
> + ret = dma_map_sgtable(attachment->dev, table, direction, attr);
> if (ret)
> return ERR_PTR(ret);
>
> @@ -139,9 +148,12 @@ static void system_heap_unmap_dma_buf(struct
> dma_buf_attachment *attachment,
> enum dma_data_direction direction)
> {
> struct dma_heap_attachment *a = attachment->priv;
> + int attr = 0;
>
> + if (a->uncached)
> + attr = DMA_ATTR_SKIP_CPU_SYNC;
> a->mapped = false;
> - dma_unmap_sgtable(attachment->dev, table, direction, 0);
> + dma_unmap_sgtable(attachment->dev
Re: [PATCH v3 0/7] dma-buf: Performance improvements for system heap & a system-uncached implementation
Hi John, On Sat, Oct 03, 2020 at 04:02:50AM +, John Stultz wrote: > Hey All, ... > > I did add to this series a reworked version of my uncached > system heap implementation I was submitting a few weeks back. > Since it duplicated a lot of the now reworked system heap code, > I realized it would be much simpler to add the functionality to > the system_heap implementaiton itself. That looks like a neat approach to me. Referencing your previous thread, I like the separate heap (as you have done), rather than a generic "cached"/"noncached" flag on all heaps. > > While not improving the core allocation performance, the > uncached heap allocations do result in *much* improved > performance on HiKey960 as it avoids a lot of flushing and > invalidating buffers that the cpu doesn't touch often. > > Feedback on these would be great! Minor nit: s/detatch/detach/ on both heaps, but other than that you can add my r-b to patches 1-5. As you've said, it does feel like there's some room for de-duplication, but that will be easier to work out once the implementations settle. I've a couple of comments for the uncached heap, but I'm not confident I understand the implications of having the non-cached alias enough to say if it looks OK or not. Cheers! -Brian ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC] Experimental DMA-BUF Device Heaps
Hi, On Thu, Aug 20, 2020 at 09:07:29AM +0100, Ezequiel Garcia wrote: > > For single-device allocations, would using the buffer allocation > > functionality of that device's native API be better in most > > cases? (Some other possibly relevant discussion at [1]) > > > > That may be true for existing subsystems. > > However, how about a new subsystem/API wanting to > leverage the heap API and avoid exposing yet another > allocator API? > > And then, also, if we have an allocator API, perhaps > we could imagine a future where applications would only > need to worry about that, and not about each per-framework > allocator. Yeah both are reasonable points. I was thinking in the context of the thread I linked where allocating lots of GEM handles for process-local use is preferable to importing loads of dma_buf fds, but in that case the userspace graphics driver is somewhat "special" rather than a generic application in the traditional sense. I do think the best usage model for applications though is to use libraries which can hide the details, instead of going at the kernel APIs directly. > > > I can see that this can save some boilerplate for devices that want > > to expose private chunks of memory, but might it also lead to 100 > > aliases for the system's generic coherent memory pool? > > > > The idea (even if PoC) was to let drivers decide if they are special > enough to add themselves (via dev_dma_heap_add). OK, that makes sense. I think it's tricky to know how many "special" chunks of memory will already be hooked up to the DMA infrastructure and how many would need some extra/special work. Cheers, -Brian ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 0/3] Chunk Heap Support on DMA-HEAP
Hi KyongHo, On Wed, Aug 19, 2020 at 12:46:26PM +0900, Cho KyongHo wrote: > I have seriously considered CPA in our product but we developed our own > because of the pool in CPA. Oh good, I'm glad you considered it :-) > The high-order pages are required by some specific users like Netflix > app. Moreover required number of bytes are dramatically increasing > because of high resolution videos and displays in these days. > > Gathering lots of free high-order pages in the background during > run-time means reserving that amount of pages from the entier available > system memory. Moreover the gathered pages are soon reclaimed whenever > the system is sufferring from memory pressure (i.e. camera recording, > heavy games). Aren't these two things in contradiction? If they're easily reclaimed then they aren't "reserved" in any detrimental way. And if you don't want them to be reclaimed, then you need them to be reserved... The approach you have here assigns the chunk of memory as a reserved CMA region which the kernel is going to try not to use too - similar to the CPA pool. I suppose it's a balance depending on how much you're willing to wait for migration on the allocation path. CPA has the potential to get you faster allocations, but the downside is you need to make it a little more "greedy". Cheers, -Brian ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 0/3] Chunk Heap Support on DMA-HEAP
Hi, On Tue, Aug 18, 2020 at 05:04:12PM +0900, Hyesoo Yu wrote: > These patch series to introduce a new dma heap, chunk heap. > That heap is needed for special HW that requires bulk allocation of > fixed high order pages. For example, 64MB dma-buf pages are made up > to fixed order-4 pages * 1024. > > The chunk heap uses alloc_pages_bulk to allocate high order page. > https://lore.kernel.org/linux-mm/20200814173131.2803002-1-minc...@kernel.org > > The chunk heap is registered by device tree with alignment and memory node > of contiguous memory allocator(CMA). Alignment defines chunk page size. > For example, alignment 0x1_ means chunk page size is 64KB. > The phandle to memory node indicates contiguous memory allocator(CMA). > If device node doesn't have cma, the registration of chunk heap fails. This reminds me of an ion heap developed at Arm several years ago: https://git.linaro.org/landing-teams/working/arm/kernel.git/tree/drivers/staging/android/ion/ion_compound_page.c Some more descriptive text here: https://github.com/ARM-software/CPA It maintains a pool of high-order pages with a worker thread to attempt compaction and allocation to keep the pool filled, with high and low watermarks to trigger freeing/allocating of chunks. It implements a shrinker to allow the system to reclaim the pool under high memory pressure. Is maintaining a pool something you considered? From the alloc_pages_bulk thread it sounds like you want to allocate 300M at a time, so I expect if you tuned the pool size to match that it could work quite well. That implementation isn't using a CMA region, but a similar approach could definitely be applied. Thanks, -Brian > > The patchset includes the following: > - export dma-heap API to register kernel module dma heap. > - add chunk heap implementation. > - document of device tree to register chunk heap > > Hyesoo Yu (3): > dma-buf: add missing EXPORT_SYMBOL_GPL() for dma heaps > dma-buf: heaps: add chunk heap to dmabuf heaps > dma-heap: Devicetree binding for chunk heap > > .../devicetree/bindings/dma-buf/chunk_heap.yaml| 46 + > drivers/dma-buf/dma-heap.c | 2 + > drivers/dma-buf/heaps/Kconfig | 9 + > drivers/dma-buf/heaps/Makefile | 1 + > drivers/dma-buf/heaps/chunk_heap.c | 222 > + > drivers/dma-buf/heaps/heap-helpers.c | 2 + > 6 files changed, 282 insertions(+) > create mode 100644 Documentation/devicetree/bindings/dma-buf/chunk_heap.yaml > create mode 100644 drivers/dma-buf/heaps/chunk_heap.c > > -- > 2.7.4 > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC] Experimental DMA-BUF Device Heaps
Hi Ezequiel, On Sun, Aug 16, 2020 at 02:22:46PM -0300, Ezequiel Garcia wrote: > This heap is basically a wrapper around DMA-API dma_alloc_attrs, > which will allocate memory suitable for the given device. > > The implementation is mostly a port of the Contiguous Videobuf2 > memory allocator (see videobuf2/videobuf2-dma-contig.c) > over to the DMA-BUF Heap interface. > > The intention of this allocator is to provide applications > with a more system-agnostic API: the only thing the application > needs to know is which device to get the buffer for. > > Whether the buffer is backed by CMA, IOMMU or a DMA Pool > is unknown to the application. > > I'm not really expecting this patch to be correct or even > a good idea, but just submitting it to start a discussion on DMA-BUF > heap discovery and negotiation. > My initial reaction is that I thought dmabuf heaps are meant for use to allocate buffers for sharing across devices, which doesn't fit very well with having per-device heaps. For single-device allocations, would using the buffer allocation functionality of that device's native API be better in most cases? (Some other possibly relevant discussion at [1]) I can see that this can save some boilerplate for devices that want to expose private chunks of memory, but might it also lead to 100 aliases for the system's generic coherent memory pool? I wonder if a set of helpers to allow devices to expose whatever they want with minimal effort would be better. Cheers, -Brian 1. https://lore.kernel.org/dri-devel/57062477-30e7-a3de-6723-a50d03a40...@kapsi.fi/ > Given Plumbers is just a couple weeks from now, I've submitted > a BoF proposal to discuss this, as perhaps it would make > sense to discuss this live? > > Not-signed-off-by: Ezequiel Garcia ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC][PATCH] dma-heap: Add proper kref handling on dma-buf heaps
Hi John,
On Sat, Jul 25, 2020 at 03:26:33AM +, John Stultz wrote:
> Add proper refcounting on the dma_heap structure.
> While existing heaps are built-in, we may eventually
> have heaps loaded from modules, and we'll need to be
> able to properly handle the references to the heaps
I'm not 100% clear on the intention here. What would take/drop a
reference on a heap?
In the case of modules I think the bigger problem is how to prevent
the module getting removed while there's still something using it.
Cheers,
-Brian
>
> Cc: Sumit Semwal
> Cc: Andrew F. Davis
> Cc: Benjamin Gaignard
> Cc: Liam Mark
> Cc: Laura Abbott
> Cc: Brian Starkey
> Cc: linux-me...@vger.kernel.org
> Cc: dri-devel@lists.freedesktop.org
> Signed-off-by: John Stultz
> ---
> drivers/dma-buf/dma-heap.c | 31 +++
> include/linux/dma-heap.h | 6 ++
> 2 files changed, 33 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/dma-buf/dma-heap.c b/drivers/dma-buf/dma-heap.c
> index afd22c9dbdcf..90c3720acc1c 100644
> --- a/drivers/dma-buf/dma-heap.c
> +++ b/drivers/dma-buf/dma-heap.c
> @@ -40,6 +40,8 @@ struct dma_heap {
> dev_t heap_devt;
> struct list_head list;
> struct cdev heap_cdev;
> + int minor;
> + struct kref refcount;
> };
>
> static LIST_HEAD(heap_list);
> @@ -190,11 +192,31 @@ void *dma_heap_get_drvdata(struct dma_heap *heap)
> return heap->priv;
> }
>
> +static void dma_heap_release(struct kref *ref)
> +{
> + struct dma_heap *heap = container_of(ref, struct dma_heap, refcount);
> +
> + /* Remove heap from the list */
> + mutex_lock(_list_lock);
> + list_del(>list);
> + mutex_unlock(_list_lock);
> +
> + device_destroy(dma_heap_class, heap->heap_devt);
> + cdev_del(>heap_cdev);
> + xa_erase(_heap_minors, heap->minor);
> +
> + kfree(heap);
> +}
> +
> +void dma_heap_put(struct dma_heap *h)
> +{
> + kref_put(>refcount, dma_heap_release);
> +}
> +
> struct dma_heap *dma_heap_add(const struct dma_heap_export_info *exp_info)
> {
> struct dma_heap *heap, *h, *err_ret;
> struct device *dev_ret;
> - unsigned int minor;
> int ret;
>
> if (!exp_info->name || !strcmp(exp_info->name, "")) {
> @@ -223,12 +245,13 @@ struct dma_heap *dma_heap_add(const struct
> dma_heap_export_info *exp_info)
> if (!heap)
> return ERR_PTR(-ENOMEM);
>
> + kref_init(>refcount);
> heap->name = exp_info->name;
> heap->ops = exp_info->ops;
> heap->priv = exp_info->priv;
>
> /* Find unused minor number */
> - ret = xa_alloc(_heap_minors, , heap,
> + ret = xa_alloc(_heap_minors, >minor, heap,
> XA_LIMIT(0, NUM_HEAP_MINORS - 1), GFP_KERNEL);
> if (ret < 0) {
> pr_err("dma_heap: Unable to get minor number for heap\n");
> @@ -237,7 +260,7 @@ struct dma_heap *dma_heap_add(const struct
> dma_heap_export_info *exp_info)
> }
>
> /* Create device */
> - heap->heap_devt = MKDEV(MAJOR(dma_heap_devt), minor);
> + heap->heap_devt = MKDEV(MAJOR(dma_heap_devt), heap->minor);
>
> cdev_init(>heap_cdev, _heap_fops);
> ret = cdev_add(>heap_cdev, heap->heap_devt, 1);
> @@ -267,7 +290,7 @@ struct dma_heap *dma_heap_add(const struct
> dma_heap_export_info *exp_info)
> err2:
> cdev_del(>heap_cdev);
> err1:
> - xa_erase(_heap_minors, minor);
> + xa_erase(_heap_minors, heap->minor);
> err0:
> kfree(heap);
> return err_ret;
> diff --git a/include/linux/dma-heap.h b/include/linux/dma-heap.h
> index 454e354d1ffb..c1572f29cfac 100644
> --- a/include/linux/dma-heap.h
> +++ b/include/linux/dma-heap.h
> @@ -56,4 +56,10 @@ void *dma_heap_get_drvdata(struct dma_heap *heap);
> */
> struct dma_heap *dma_heap_add(const struct dma_heap_export_info *exp_info);
>
> +/**
> + * dma_heap_put - drops a reference to a dmabuf heaps, potentially freeing it
> + * @heap:heap pointer
> + */
> +void dma_heap_put(struct dma_heap *heap);
> +
> #endif /* _DMA_HEAPS_H */
> --
> 2.17.1
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2] drm: drm_fourcc: Add generic alias for 16_16_TILE modifier
On Mon, Jun 29, 2020 at 10:32:41AM +0200, Daniel Vetter wrote:
> On Fri, Jun 26, 2020 at 05:48:00PM +0100, Brian Starkey wrote:
> > In cases such as DRM_FORMAT_MOD_SAMSUNG_16_16_TILE, the modifier
> > describes a generic pixel re-ordering which can be applicable to
> > multiple vendors.
> >
> > Define an alias: DRM_FORMAT_MOD_GENERIC_16_16_TILE, which can be
> > used to describe this layout in a vendor-neutral way, and add a
> > comment about the expected usage of such "generic" modifiers.
> >
> > Changes in v2:
> > - Move note about future cases to comment (Daniel)
> >
> > Signed-off-by: Brian Starkey
>
> Reviewed-by: Daniel Vetter
Thanks. I guess this should go into drm-misc-next? @Liviu would you be
able to pick it up?
Cheers,
-Brian
>
> > ---
> > include/uapi/drm/drm_fourcc.h | 25 +
> > 1 file changed, 25 insertions(+)
> >
> > diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
> > index 299f9ac4840b..cb3db4a21012 100644
> > --- a/include/uapi/drm/drm_fourcc.h
> > +++ b/include/uapi/drm/drm_fourcc.h
> > @@ -345,8 +345,33 @@ extern "C" {
> > * When adding a new token please document the layout with a code comment,
> > * similar to the fourcc codes above. drm_fourcc.h is considered the
> > * authoritative source for all of these.
> > + *
> > + * Generic modifier names:
> > + *
> > + * DRM_FORMAT_MOD_GENERIC_* definitions are used to provide vendor-neutral
> > names
> > + * for layouts which are common across multiple vendors. To preserve
> > + * compatibility, in cases where a vendor-specific definition already
> > exists and
> > + * a generic name for it is desired, the common name is a purely symbolic
> > alias
> > + * and must use the same numerical value as the original definition.
> > + *
> > + * Note that generic names should only be used for modifiers which describe
> > + * generic layouts (such as pixel re-ordering), which may have
> > + * independently-developed support across multiple vendors.
> > + *
> > + * In future cases where a generic layout is identified before merging
> > with a
> > + * vendor-specific modifier, a new 'GENERIC' vendor or modifier using
> > vendor
> > + * 'NONE' could be considered. This should only be for obvious, exceptional
> > + * cases to avoid polluting the 'GENERIC' namespace with modifiers which
> > only
> > + * apply to a single vendor.
> > + *
> > + * Generic names should not be used for cases where multiple hardware
> > vendors
> > + * have implementations of the same standardised compression scheme (such
> > as
> > + * AFBC). In those cases, all implementations should use the same format
> > + * modifier(s), reflecting the vendor of the standard.
> > */
> >
> > +#define DRM_FORMAT_MOD_GENERIC_16_16_TILE DRM_FORMAT_MOD_SAMSUNG_16_16_TILE
> > +
> > /*
> > * Invalid Modifier
> > *
> > --
> > 2.17.1
> >
>
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2] drm: drm_fourcc: Add generic alias for 16_16_TILE modifier
In cases such as DRM_FORMAT_MOD_SAMSUNG_16_16_TILE, the modifier
describes a generic pixel re-ordering which can be applicable to
multiple vendors.
Define an alias: DRM_FORMAT_MOD_GENERIC_16_16_TILE, which can be
used to describe this layout in a vendor-neutral way, and add a
comment about the expected usage of such "generic" modifiers.
Changes in v2:
- Move note about future cases to comment (Daniel)
Signed-off-by: Brian Starkey
---
include/uapi/drm/drm_fourcc.h | 25 +
1 file changed, 25 insertions(+)
diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
index 299f9ac4840b..cb3db4a21012 100644
--- a/include/uapi/drm/drm_fourcc.h
+++ b/include/uapi/drm/drm_fourcc.h
@@ -345,8 +345,33 @@ extern "C" {
* When adding a new token please document the layout with a code comment,
* similar to the fourcc codes above. drm_fourcc.h is considered the
* authoritative source for all of these.
+ *
+ * Generic modifier names:
+ *
+ * DRM_FORMAT_MOD_GENERIC_* definitions are used to provide vendor-neutral
names
+ * for layouts which are common across multiple vendors. To preserve
+ * compatibility, in cases where a vendor-specific definition already exists
and
+ * a generic name for it is desired, the common name is a purely symbolic alias
+ * and must use the same numerical value as the original definition.
+ *
+ * Note that generic names should only be used for modifiers which describe
+ * generic layouts (such as pixel re-ordering), which may have
+ * independently-developed support across multiple vendors.
+ *
+ * In future cases where a generic layout is identified before merging with a
+ * vendor-specific modifier, a new 'GENERIC' vendor or modifier using vendor
+ * 'NONE' could be considered. This should only be for obvious, exceptional
+ * cases to avoid polluting the 'GENERIC' namespace with modifiers which only
+ * apply to a single vendor.
+ *
+ * Generic names should not be used for cases where multiple hardware vendors
+ * have implementations of the same standardised compression scheme (such as
+ * AFBC). In those cases, all implementations should use the same format
+ * modifier(s), reflecting the vendor of the standard.
*/
+#define DRM_FORMAT_MOD_GENERIC_16_16_TILE DRM_FORMAT_MOD_SAMSUNG_16_16_TILE
+
/*
* Invalid Modifier
*
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm: drm_fourcc: Add generic alias for 16_16_TILE modifier
On Fri, Jun 26, 2020 at 06:15:36PM +0200, Daniel Vetter wrote: > On Fri, Jun 26, 2020 at 5:21 PM Brian Starkey wrote: > > > > On Fri, Jun 26, 2020 at 05:16:53PM +0200, Daniel Vetter wrote: > > > On Fri, Jun 26, 2020 at 4:16 PM Brian Starkey > > > wrote: > > > > > > > > Hi Daniel, > > > > > > > > On Fri, Jun 26, 2020 at 04:07:43PM +0200, Daniel Vetter wrote: > > > > > On Fri, Jun 26, 2020 at 3:52 PM Brian Starkey > > > > > wrote: > > > > > > > > > > > > In cases such as DRM_FORMAT_MOD_SAMSUNG_16_16_TILE, the modifier > > > > > > describes a generic pixel re-ordering which can be applicable to > > > > > > multiple vendors. > > > > > > > > > > > > Define an alias: DRM_FORMAT_MOD_GENERIC_16_16_TILE, which can be > > > > > > used to describe this layout in a vendor-neutral way, and add a > > > > > > comment about the expected usage of such "generic" modifiers. > > > > > > > > > > > > Signed-off-by: Brian Starkey > > > > > > --- > > > > > > > > > > > > This is based off a suggestion from Daniel here: > > > > > > https://lore.kernel.org/dri-devel/20200529115328.GC1630358@phenom.ffwll.local/ > > > > > > > > > > > > If there are future cases where a "generic" modifier is identified > > > > > > before merging with a specific vendor code, perhaps we could use > > > > > > `fourcc_mod_code(NONE, n)` or add a DRM_FORMAT_MOD_VENDOR_GENERIC. > > > > > > > > > > > > However, I also think we shouldn't try and "guess" what might be > > > > > > generic > > > > > > up-front and end up polluting the generic namespace. It seems fine > > > > > > to > > > > > > just alias vendor-specific definitions unless it's very clear-cut. > > > > > > > > > > I think the above two things would also be good additions to the > > > > > comment. > > > > > > > > > > A totally different thing: I just noticed that we don't pull in all > > > > > the comments for modifiers. I think we could convert them to > > > > > kerneldoc, and then pull them into a separate section in drm-kms.rst. > > > > > Maybe even worth to pull out into a new drm-fourcc.rst document, since > > > > > these are officially shared with gl and vk standard extensions. Then > > > > > this new modifier's doc could simply point at teh existing one (and > > > > > the generated kerneldoc would make that a hyperlink for added > > > > > awesomeness). > > > > > > > > > > Aside from that makes sense to me, maybe just add it to your patch > > > > > series that will start making use of these. > > > > > > > > This is only supported by the GPU, so we wouldn't be using this on the > > > > Display side. > > > > > > I mean the patch to add the NV15 fource, it mentions "suitable for 16 > > > by 16 tile layout", would be nice to just put the generic modifier in > > > that comment. > > > -Daniel > > > > Ah right. I saw that one went out in Maarten's pull request this > > morning. > > Oh I missed that, then maybe just amend this patch to update the other > comment? It was only mentioned in the commit message there, so I guess I can't do anything about it now. I'll respin to put the extra notes into the comment. Thanks, -Brian > -Daniel > > > > > -Brian > > > > > > > > > > > > > Thanks, > > > > -Brian > > > > > > > > > -Daniel > > > > > > > > > > > > > > > > > I typed a version which was s/GENERIC/COMMON/, other suggestions > > > > > > welcome. > > > > > > > > > > > > Cheers, > > > > > > -Brian > > > > > > > > > > > > include/uapi/drm/drm_fourcc.h | 19 +++ > > > > > > 1 file changed, 19 insertions(+) > > > > > > > > > > > > diff --git a/include/uapi/drm/drm_fourcc.h > > > > > > b/include/uapi/drm/drm_fourcc.h > > > > > > index 299f9ac4840b..ef78dc9c3fb0 100644 > > > > > > --- a/include/uapi/drm/drm_fourcc.h >
Re: [PATCH] drm: drm_fourcc: Add generic alias for 16_16_TILE modifier
On Fri, Jun 26, 2020 at 05:16:53PM +0200, Daniel Vetter wrote:
> On Fri, Jun 26, 2020 at 4:16 PM Brian Starkey wrote:
> >
> > Hi Daniel,
> >
> > On Fri, Jun 26, 2020 at 04:07:43PM +0200, Daniel Vetter wrote:
> > > On Fri, Jun 26, 2020 at 3:52 PM Brian Starkey
> > > wrote:
> > > >
> > > > In cases such as DRM_FORMAT_MOD_SAMSUNG_16_16_TILE, the modifier
> > > > describes a generic pixel re-ordering which can be applicable to
> > > > multiple vendors.
> > > >
> > > > Define an alias: DRM_FORMAT_MOD_GENERIC_16_16_TILE, which can be
> > > > used to describe this layout in a vendor-neutral way, and add a
> > > > comment about the expected usage of such "generic" modifiers.
> > > >
> > > > Signed-off-by: Brian Starkey
> > > > ---
> > > >
> > > > This is based off a suggestion from Daniel here:
> > > > https://lore.kernel.org/dri-devel/20200529115328.GC1630358@phenom.ffwll.local/
> > > >
> > > > If there are future cases where a "generic" modifier is identified
> > > > before merging with a specific vendor code, perhaps we could use
> > > > `fourcc_mod_code(NONE, n)` or add a DRM_FORMAT_MOD_VENDOR_GENERIC.
> > > >
> > > > However, I also think we shouldn't try and "guess" what might be generic
> > > > up-front and end up polluting the generic namespace. It seems fine to
> > > > just alias vendor-specific definitions unless it's very clear-cut.
> > >
> > > I think the above two things would also be good additions to the comment.
> > >
> > > A totally different thing: I just noticed that we don't pull in all
> > > the comments for modifiers. I think we could convert them to
> > > kerneldoc, and then pull them into a separate section in drm-kms.rst.
> > > Maybe even worth to pull out into a new drm-fourcc.rst document, since
> > > these are officially shared with gl and vk standard extensions. Then
> > > this new modifier's doc could simply point at teh existing one (and
> > > the generated kerneldoc would make that a hyperlink for added
> > > awesomeness).
> > >
> > > Aside from that makes sense to me, maybe just add it to your patch
> > > series that will start making use of these.
> >
> > This is only supported by the GPU, so we wouldn't be using this on the
> > Display side.
>
> I mean the patch to add the NV15 fource, it mentions "suitable for 16
> by 16 tile layout", would be nice to just put the generic modifier in
> that comment.
> -Daniel
Ah right. I saw that one went out in Maarten's pull request this
morning.
-Brian
>
> >
> > Thanks,
> > -Brian
> >
> > > -Daniel
> > >
> > > >
> > > > I typed a version which was s/GENERIC/COMMON/, other suggestions
> > > > welcome.
> > > >
> > > > Cheers,
> > > > -Brian
> > > >
> > > > include/uapi/drm/drm_fourcc.h | 19 +++
> > > > 1 file changed, 19 insertions(+)
> > > >
> > > > diff --git a/include/uapi/drm/drm_fourcc.h
> > > > b/include/uapi/drm/drm_fourcc.h
> > > > index 299f9ac4840b..ef78dc9c3fb0 100644
> > > > --- a/include/uapi/drm/drm_fourcc.h
> > > > +++ b/include/uapi/drm/drm_fourcc.h
> > > > @@ -345,8 +345,27 @@ extern "C" {
> > > > * When adding a new token please document the layout with a code
> > > > comment,
> > > > * similar to the fourcc codes above. drm_fourcc.h is considered the
> > > > * authoritative source for all of these.
> > > > + *
> > > > + * Generic modifier names:
> > > > + *
> > > > + * DRM_FORMAT_MOD_GENERIC_* definitions are used to provide
> > > > vendor-neutral names
> > > > + * for layouts which are common across multiple vendors. To preserve
> > > > + * compatibility, in cases where a vendor-specific definition already
> > > > exists and
> > > > + * a generic name for it is desired, the common name is a purely
> > > > symbolic alias
> > > > + * and must use the same numerical value as the original definition.
> > > > + *
> > > > + * Note that generic names should only be used for modifiers which
> > > > describe
> > > > + * generic layouts (such as pixel re-ordering), which may have
> > > > + * independently-developed support across multiple vendors.
> > > > + *
> > > > + * Generic names should not be used for cases where multiple hardware
> > > > vendors
> > > > + * have implementations of the same standardised compression scheme
> > > > (such as
> > > > + * AFBC). In those cases, all implementations should use the same
> > > > format
> > > > + * modifier(s), reflecting the vendor of the standard.
> > > > */
> > > >
> > > > +#define DRM_FORMAT_MOD_GENERIC_16_16_TILE
> > > > DRM_FORMAT_MOD_SAMSUNG_16_16_TILE
> > > > +
> > > > /*
> > > > * Invalid Modifier
> > > > *
> > > > --
> > > > 2.17.1
> > > >
> > >
> > >
> > > --
> > > Daniel Vetter
> > > Software Engineer, Intel Corporation
> > > http://blog.ffwll.ch
>
>
>
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm: drm_fourcc: Add generic alias for 16_16_TILE modifier
Hi Daniel,
On Fri, Jun 26, 2020 at 04:07:43PM +0200, Daniel Vetter wrote:
> On Fri, Jun 26, 2020 at 3:52 PM Brian Starkey wrote:
> >
> > In cases such as DRM_FORMAT_MOD_SAMSUNG_16_16_TILE, the modifier
> > describes a generic pixel re-ordering which can be applicable to
> > multiple vendors.
> >
> > Define an alias: DRM_FORMAT_MOD_GENERIC_16_16_TILE, which can be
> > used to describe this layout in a vendor-neutral way, and add a
> > comment about the expected usage of such "generic" modifiers.
> >
> > Signed-off-by: Brian Starkey
> > ---
> >
> > This is based off a suggestion from Daniel here:
> > https://lore.kernel.org/dri-devel/20200529115328.GC1630358@phenom.ffwll.local/
> >
> > If there are future cases where a "generic" modifier is identified
> > before merging with a specific vendor code, perhaps we could use
> > `fourcc_mod_code(NONE, n)` or add a DRM_FORMAT_MOD_VENDOR_GENERIC.
> >
> > However, I also think we shouldn't try and "guess" what might be generic
> > up-front and end up polluting the generic namespace. It seems fine to
> > just alias vendor-specific definitions unless it's very clear-cut.
>
> I think the above two things would also be good additions to the comment.
>
> A totally different thing: I just noticed that we don't pull in all
> the comments for modifiers. I think we could convert them to
> kerneldoc, and then pull them into a separate section in drm-kms.rst.
> Maybe even worth to pull out into a new drm-fourcc.rst document, since
> these are officially shared with gl and vk standard extensions. Then
> this new modifier's doc could simply point at teh existing one (and
> the generated kerneldoc would make that a hyperlink for added
> awesomeness).
>
> Aside from that makes sense to me, maybe just add it to your patch
> series that will start making use of these.
This is only supported by the GPU, so we wouldn't be using this on the
Display side.
Thanks,
-Brian
> -Daniel
>
> >
> > I typed a version which was s/GENERIC/COMMON/, other suggestions
> > welcome.
> >
> > Cheers,
> > -Brian
> >
> > include/uapi/drm/drm_fourcc.h | 19 +++
> > 1 file changed, 19 insertions(+)
> >
> > diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
> > index 299f9ac4840b..ef78dc9c3fb0 100644
> > --- a/include/uapi/drm/drm_fourcc.h
> > +++ b/include/uapi/drm/drm_fourcc.h
> > @@ -345,8 +345,27 @@ extern "C" {
> > * When adding a new token please document the layout with a code comment,
> > * similar to the fourcc codes above. drm_fourcc.h is considered the
> > * authoritative source for all of these.
> > + *
> > + * Generic modifier names:
> > + *
> > + * DRM_FORMAT_MOD_GENERIC_* definitions are used to provide vendor-neutral
> > names
> > + * for layouts which are common across multiple vendors. To preserve
> > + * compatibility, in cases where a vendor-specific definition already
> > exists and
> > + * a generic name for it is desired, the common name is a purely symbolic
> > alias
> > + * and must use the same numerical value as the original definition.
> > + *
> > + * Note that generic names should only be used for modifiers which describe
> > + * generic layouts (such as pixel re-ordering), which may have
> > + * independently-developed support across multiple vendors.
> > + *
> > + * Generic names should not be used for cases where multiple hardware
> > vendors
> > + * have implementations of the same standardised compression scheme (such
> > as
> > + * AFBC). In those cases, all implementations should use the same format
> > + * modifier(s), reflecting the vendor of the standard.
> > */
> >
> > +#define DRM_FORMAT_MOD_GENERIC_16_16_TILE DRM_FORMAT_MOD_SAMSUNG_16_16_TILE
> > +
> > /*
> > * Invalid Modifier
> > *
> > --
> > 2.17.1
> >
>
>
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm: drm_fourcc: Add generic alias for 16_16_TILE modifier
In cases such as DRM_FORMAT_MOD_SAMSUNG_16_16_TILE, the modifier
describes a generic pixel re-ordering which can be applicable to
multiple vendors.
Define an alias: DRM_FORMAT_MOD_GENERIC_16_16_TILE, which can be
used to describe this layout in a vendor-neutral way, and add a
comment about the expected usage of such "generic" modifiers.
Signed-off-by: Brian Starkey
---
This is based off a suggestion from Daniel here:
https://lore.kernel.org/dri-devel/20200529115328.GC1630358@phenom.ffwll.local/
If there are future cases where a "generic" modifier is identified
before merging with a specific vendor code, perhaps we could use
`fourcc_mod_code(NONE, n)` or add a DRM_FORMAT_MOD_VENDOR_GENERIC.
However, I also think we shouldn't try and "guess" what might be generic
up-front and end up polluting the generic namespace. It seems fine to
just alias vendor-specific definitions unless it's very clear-cut.
I typed a version which was s/GENERIC/COMMON/, other suggestions
welcome.
Cheers,
-Brian
include/uapi/drm/drm_fourcc.h | 19 +++
1 file changed, 19 insertions(+)
diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
index 299f9ac4840b..ef78dc9c3fb0 100644
--- a/include/uapi/drm/drm_fourcc.h
+++ b/include/uapi/drm/drm_fourcc.h
@@ -345,8 +345,27 @@ extern "C" {
* When adding a new token please document the layout with a code comment,
* similar to the fourcc codes above. drm_fourcc.h is considered the
* authoritative source for all of these.
+ *
+ * Generic modifier names:
+ *
+ * DRM_FORMAT_MOD_GENERIC_* definitions are used to provide vendor-neutral
names
+ * for layouts which are common across multiple vendors. To preserve
+ * compatibility, in cases where a vendor-specific definition already exists
and
+ * a generic name for it is desired, the common name is a purely symbolic alias
+ * and must use the same numerical value as the original definition.
+ *
+ * Note that generic names should only be used for modifiers which describe
+ * generic layouts (such as pixel re-ordering), which may have
+ * independently-developed support across multiple vendors.
+ *
+ * Generic names should not be used for cases where multiple hardware vendors
+ * have implementations of the same standardised compression scheme (such as
+ * AFBC). In those cases, all implementations should use the same format
+ * modifier(s), reflecting the vendor of the standard.
*/
+#define DRM_FORMAT_MOD_GENERIC_16_16_TILE DRM_FORMAT_MOD_SAMSUNG_16_16_TILE
+
/*
* Invalid Modifier
*
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v6] drm/fourcc: document modifier uniqueness requirements
Looks good now, thanks!
On Wed, Jun 24, 2020 at 01:01:31PM +, Simon Ser wrote:
> There have suggestions to bake pitch alignment, address alignement,
> contiguous memory or other placement (hidden VRAM, GTT/BAR, etc)
> constraints into modifiers. Last time this was brought up it seemed
> like the consensus was to not allow this. Document this in drm_fourcc.h.
>
> There are several reasons for this.
>
> - Encoding all of these constraints in the modifiers would explode the
> search space pretty quickly (we only have 64 bits to work with).
> - Modifiers need to be unambiguous: a buffer can only have a single
> modifier.
> - Modifier users aren't expected to parse modifiers (except drivers).
>
> v2: add paragraph about aliases (Daniel)
>
> v3: fix unrelated changes sent with the patch
>
> v4: disambiguate users between driver and higher-level programs (Brian,
> Daniel)
>
> v5: fix AFBC example (Brian, Daniel)
>
> v6: remove duplicated paragraph (Daniel)
>
> Signed-off-by: Simon Ser
> Reviewed-by: Daniel Vetter
> Cc: Daniel Stone
> Cc: Bas Nieuwenhuizen
> Cc: Dave Airlie
> Cc: Marek Olšák
> Cc: Alex Deucher
> Cc: Neil Armstrong
> Cc: Michel Dänzer
> Cc: Brian Starkey
> ---
> include/uapi/drm/drm_fourcc.h | 24
> 1 file changed, 24 insertions(+)
>
> diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
> index 490143500a50..8eaa158fef81 100644
> --- a/include/uapi/drm/drm_fourcc.h
> +++ b/include/uapi/drm/drm_fourcc.h
> @@ -58,6 +58,30 @@ extern "C" {
> * may preserve meaning - such as number of planes - from the fourcc code,
> * whereas others may not.
> *
> + * Modifiers must uniquely encode buffer layout. In other words, a buffer
> must
> + * match only a single modifier. A modifier must not be a subset of layouts
> of
> + * another modifier. For instance, it's incorrect to encode pitch alignment
> in
> + * a modifier: a buffer may match a 64-pixel aligned modifier and a 32-pixel
> + * aligned modifier. That said, modifiers can have implicit minimal
> + * requirements.
> + *
> + * For modifiers where the combination of fourcc code and modifier can alias,
> + * a canonical pair needs to be defined and used by all drivers. Preferred
> + * combinations are also encouraged where all combinations might lead to
> + * confusion and unnecessarily reduced interoperability. An example for the
> + * latter is AFBC, where the ABGR layouts are preferred over ARGB layouts.
> + *
> + * There are two kinds of modifier users:
> + *
> + * - Kernel and user-space drivers: for drivers it's important that modifiers
> + * don't alias, otherwise two drivers might support the same format but use
> + * different aliases, preventing them from sharing buffers in an efficient
> + * format.
> + * - Higher-level programs interfacing with KMS/GBM/EGL/Vulkan/etc: these
> users
> + * see modifiers as opaque tokens they can check for equality and
> intersect.
> + * These users musn't need to know to reason about the modifier value
> + * (i.e. they are not expected to extract information out of the modifier).
> + *
> * Vendors should document their modifier usage in as much detail as
> * possible, to ensure maximum compatibility across devices, drivers and
> * applications.
> --
> 2.27.0
>
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v5] drm/fourcc: document modifier uniqueness requirements
Hi,
On Tue, Jun 23, 2020 at 03:25:08PM +, Simon Ser wrote:
> There have suggestions to bake pitch alignment, address alignement,
> contiguous memory or other placement (hidden VRAM, GTT/BAR, etc)
> constraints into modifiers. Last time this was brought up it seemed
> like the consensus was to not allow this. Document this in drm_fourcc.h.
>
> There are several reasons for this.
>
> - Encoding all of these constraints in the modifiers would explode the
> search space pretty quickly (we only have 64 bits to work with).
> - Modifiers need to be unambiguous: a buffer can only have a single
> modifier.
> - Modifier users aren't expected to parse modifiers (except drivers).
>
> v2: add paragraph about aliases (Daniel)
>
> v3: fix unrelated changes sent with the patch
>
> v4: disambiguate users between driver and higher-level programs (Brian,
> Daniel)
>
> v5: fix AFBC example (Brian, Daniel)
>
> Signed-off-by: Simon Ser
> Reviewed-by: Daniel Vetter
> Cc: Daniel Stone
> Cc: Bas Nieuwenhuizen
> Cc: Dave Airlie
> Cc: Marek Olšák
> Cc: Alex Deucher
> Cc: Neil Armstrong
> Cc: Michel Dänzer
> Cc: Brian Starkey
> ---
> include/uapi/drm/drm_fourcc.h | 28
> 1 file changed, 28 insertions(+)
>
> diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
> index 490143500a50..8296197189bf 100644
> --- a/include/uapi/drm/drm_fourcc.h
> +++ b/include/uapi/drm/drm_fourcc.h
> @@ -58,6 +58,34 @@ extern "C" {
> * may preserve meaning - such as number of planes - from the fourcc code,
> * whereas others may not.
> *
> + * Modifiers must uniquely encode buffer layout. In other words, a buffer
> must
> + * match only a single modifier. A modifier must not be a subset of layouts
> of
> + * another modifier. For instance, it's incorrect to encode pitch alignment
> in
> + * a modifier: a buffer may match a 64-pixel aligned modifier and a 32-pixel
> + * aligned modifier. That said, modifiers can have implicit minimal
> + * requirements.
> + *
> + * For modifiers where the combination of fourcc code and modifier can alias,
> + * a canonical pair needs to be defined and used by all drivers. An example
> + * is AFBC, where both ARGB and ABGR have the exact same compressed layout.
The new paragraph below looks good, but this sentence from the end of
the paragraph above still needs to be removed:
An example is AFBC, where both ARGB and ABGR have the exact same compressed
layout.
With that fixed:
Reviewed-by: Brian Starkey
Thanks,
-Brian
> + *
> + * For modifiers where the combination of fourcc code and modifier can alias,
> + * a canonical pair needs to be defined and used by all drivers. Preferred
> + * combinations are also encouraged where all combinations might lead to
> + * confusion and unnecessarily reduced interoperability. An example for the
> + * latter is AFBC, where the ABGR layouts are preferred over ARGB layouts.
> + *
> + * There are two kinds of modifier users:
> + *
> + * - Kernel and user-space drivers: for drivers it's important that modifiers
> + * don't alias, otherwise two drivers might support the same format but use
> + * different aliases, preventing them from sharing buffers in an efficient
> + * format.
> + * - Higher-level programs interfacing with KMS/GBM/EGL/Vulkan/etc: these
> users
> + * see modifiers as opaque tokens they can check for equality and
> intersect.
> + * These users musn't need to know to reason about the modifier value
> + * (i.e. they are not expected to extract information out of the modifier).
> + *
> * Vendors should document their modifier usage in as much detail as
> * possible, to ensure maximum compatibility across devices, drivers and
> * applications.
> --
> 2.27.0
>
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4] drm/fourcc: document modifier uniqueness requirements
On Tue, Jun 23, 2020 at 10:45:51AM +0200, Daniel Vetter wrote:
> On Mon, Jun 22, 2020 at 11:20:51AM +0100, Brian Starkey wrote:
> > On Fri, Jun 19, 2020 at 06:36:17PM +0200, Daniel Vetter wrote:
> > > On Fri, Jun 19, 2020 at 01:39:34PM +0100, Brian Starkey wrote:
> > > > Hi Simon,
> > > >
> > > > On Fri, Jun 19, 2020 at 11:12:25AM +, Simon Ser wrote:
> > > > > There have suggestions to bake pitch alignment, address alignement,
> > > > > contiguous memory or other placement (hidden VRAM, GTT/BAR, etc)
> > > > > constraints into modifiers. Last time this was brought up it seemed
> > > > > like the consensus was to not allow this. Document this in
> > > > > drm_fourcc.h.
> > > > >
> > > > > There are several reasons for this.
> > > > >
> > > > > - Encoding all of these constraints in the modifiers would explode the
> > > > > search space pretty quickly (we only have 64 bits to work with).
> > > > > - Modifiers need to be unambiguous: a buffer can only have a single
> > > > > modifier.
> > > > > - Modifier users aren't expected to parse modifiers (except drivers).
> > > > >
> > > > > v2: add paragraph about aliases (Daniel)
> > > > >
> > > > > v3: fix unrelated changes sent with the patch
> > > > >
> > > > > v4: disambiguate users between driver and higher-level programs
> > > > > (Brian,
> > > > > Daniel)
> > > > >
> > > > > Signed-off-by: Simon Ser
> > > > > Reviewed-by: Daniel Vetter
> > > > > Cc: Daniel Stone
> > > > > Cc: Bas Nieuwenhuizen
> > > > > Cc: Dave Airlie
> > > > > Cc: Marek Olšák
> > > > > Cc: Alex Deucher
> > > > > Cc: Neil Armstrong
> > > > > Cc: Michel Dänzer
> > > > > Cc: Brian Starkey
> > > > > ---
> > > > > include/uapi/drm/drm_fourcc.h | 22 ++
> > > > > 1 file changed, 22 insertions(+)
> > > > >
> > > > > diff --git a/include/uapi/drm/drm_fourcc.h
> > > > > b/include/uapi/drm/drm_fourcc.h
> > > > > index 490143500a50..4d3f819dca0b 100644
> > > > > --- a/include/uapi/drm/drm_fourcc.h
> > > > > +++ b/include/uapi/drm/drm_fourcc.h
> > > > > @@ -58,6 +58,28 @@ extern "C" {
> > > > > * may preserve meaning - such as number of planes - from the fourcc
> > > > > code,
> > > > > * whereas others may not.
> > > > > *
> > > > > + * Modifiers must uniquely encode buffer layout. In other words, a
> > > > > buffer must
> > > > > + * match only a single modifier. A modifier must not be a subset of
> > > > > layouts of
> > > > > + * another modifier. For instance, it's incorrect to encode pitch
> > > > > alignment in
> > > > > + * a modifier: a buffer may match a 64-pixel aligned modifier and a
> > > > > 32-pixel
> > > > > + * aligned modifier. That said, modifiers can have implicit minimal
> > > > > + * requirements.
> > > > > + *
> > > > > + * For modifiers where the combination of fourcc code and modifier
> > > > > can alias,
> > > > > + * a canonical pair needs to be defined and used by all drivers. An
> > > > > example
> > > > > + * is AFBC, where both ARGB and ABGR have the exact same compressed
> > > > > layout.
> > > >
> > > > I still don't agree with this sentence. ARGB and ABGR have different
> > > > compressed layouts in AFBC.
> > >
> > > Hm then maybe I got confused for the exact reason why afbc has defined
> > > canonical fourcc codes in Documentation/gpu/afbc.rst? They all use the
> > > BGR versions, no RGB anywhere to be found.
> > >
> > > What's the reason then behind the "Formats which are not listed should be
> > > avoided." in that doc? That's the case I wanted to refer to here.
> >
> > Basically there's hardware which supports only BGR, hardware which
> > "ignores" swizzle (treats all as BGR), and hardware which supports
> > both BGR and RGB. Even amongst first-party implementations it's
> > inconsistent.
> >
> > This leads to a potentially confusing situation w
Re: [PATCH v4] drm/fourcc: document modifier uniqueness requirements
On Fri, Jun 19, 2020 at 06:36:17PM +0200, Daniel Vetter wrote:
> On Fri, Jun 19, 2020 at 01:39:34PM +0100, Brian Starkey wrote:
> > Hi Simon,
> >
> > On Fri, Jun 19, 2020 at 11:12:25AM +, Simon Ser wrote:
> > > There have suggestions to bake pitch alignment, address alignement,
> > > contiguous memory or other placement (hidden VRAM, GTT/BAR, etc)
> > > constraints into modifiers. Last time this was brought up it seemed
> > > like the consensus was to not allow this. Document this in drm_fourcc.h.
> > >
> > > There are several reasons for this.
> > >
> > > - Encoding all of these constraints in the modifiers would explode the
> > > search space pretty quickly (we only have 64 bits to work with).
> > > - Modifiers need to be unambiguous: a buffer can only have a single
> > > modifier.
> > > - Modifier users aren't expected to parse modifiers (except drivers).
> > >
> > > v2: add paragraph about aliases (Daniel)
> > >
> > > v3: fix unrelated changes sent with the patch
> > >
> > > v4: disambiguate users between driver and higher-level programs (Brian,
> > > Daniel)
> > >
> > > Signed-off-by: Simon Ser
> > > Reviewed-by: Daniel Vetter
> > > Cc: Daniel Stone
> > > Cc: Bas Nieuwenhuizen
> > > Cc: Dave Airlie
> > > Cc: Marek Olšák
> > > Cc: Alex Deucher
> > > Cc: Neil Armstrong
> > > Cc: Michel Dänzer
> > > Cc: Brian Starkey
> > > ---
> > > include/uapi/drm/drm_fourcc.h | 22 ++
> > > 1 file changed, 22 insertions(+)
> > >
> > > diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
> > > index 490143500a50..4d3f819dca0b 100644
> > > --- a/include/uapi/drm/drm_fourcc.h
> > > +++ b/include/uapi/drm/drm_fourcc.h
> > > @@ -58,6 +58,28 @@ extern "C" {
> > > * may preserve meaning - such as number of planes - from the fourcc
> > > code,
> > > * whereas others may not.
> > > *
> > > + * Modifiers must uniquely encode buffer layout. In other words, a
> > > buffer must
> > > + * match only a single modifier. A modifier must not be a subset of
> > > layouts of
> > > + * another modifier. For instance, it's incorrect to encode pitch
> > > alignment in
> > > + * a modifier: a buffer may match a 64-pixel aligned modifier and a
> > > 32-pixel
> > > + * aligned modifier. That said, modifiers can have implicit minimal
> > > + * requirements.
> > > + *
> > > + * For modifiers where the combination of fourcc code and modifier can
> > > alias,
> > > + * a canonical pair needs to be defined and used by all drivers. An
> > > example
> > > + * is AFBC, where both ARGB and ABGR have the exact same compressed
> > > layout.
> >
> > I still don't agree with this sentence. ARGB and ABGR have different
> > compressed layouts in AFBC.
>
> Hm then maybe I got confused for the exact reason why afbc has defined
> canonical fourcc codes in Documentation/gpu/afbc.rst? They all use the
> BGR versions, no RGB anywhere to be found.
>
> What's the reason then behind the "Formats which are not listed should be
> avoided." in that doc? That's the case I wanted to refer to here.
Basically there's hardware which supports only BGR, hardware which
"ignores" swizzle (treats all as BGR), and hardware which supports
both BGR and RGB. Even amongst first-party implementations it's
inconsistent.
This leads to a potentially confusing situation where someone with
hardware which "ignores" swizzle assumes that's always the case.
To avoid that, we wanted to be explicit that ordering is important:
| The assignment of input/output color channels must be consistent
| between the encoder and the decoder for correct operation, otherwise
| the consumer will interpret the decoded data incorrectly.
| ...
| The component ordering is communicated via the fourcc code in the
| fourcc:modifier pair. In general, component '0' is considered to
| reside in the least-significant bits of the corresponding linear
| format. For example, COMP(bits):
And, to try and ensure best cross compatibility, we want BGR to be
used most often. We expect that to be supported by the most hardware:
| For maximum compatibility across devices, the table below defines
| canonical formats for use between AFBC-enabled devices. Formats which
| are listed here must be used exactly as specified when using the AFBC
| modifiers. Formats which are not listed should be avoided.
Che
Re: [PATCH v4] drm/fourcc: document modifier uniqueness requirements
Hi Simon,
On Fri, Jun 19, 2020 at 11:12:25AM +, Simon Ser wrote:
> There have suggestions to bake pitch alignment, address alignement,
> contiguous memory or other placement (hidden VRAM, GTT/BAR, etc)
> constraints into modifiers. Last time this was brought up it seemed
> like the consensus was to not allow this. Document this in drm_fourcc.h.
>
> There are several reasons for this.
>
> - Encoding all of these constraints in the modifiers would explode the
> search space pretty quickly (we only have 64 bits to work with).
> - Modifiers need to be unambiguous: a buffer can only have a single
> modifier.
> - Modifier users aren't expected to parse modifiers (except drivers).
>
> v2: add paragraph about aliases (Daniel)
>
> v3: fix unrelated changes sent with the patch
>
> v4: disambiguate users between driver and higher-level programs (Brian,
> Daniel)
>
> Signed-off-by: Simon Ser
> Reviewed-by: Daniel Vetter
> Cc: Daniel Stone
> Cc: Bas Nieuwenhuizen
> Cc: Dave Airlie
> Cc: Marek Olšák
> Cc: Alex Deucher
> Cc: Neil Armstrong
> Cc: Michel Dänzer
> Cc: Brian Starkey
> ---
> include/uapi/drm/drm_fourcc.h | 22 ++
> 1 file changed, 22 insertions(+)
>
> diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
> index 490143500a50..4d3f819dca0b 100644
> --- a/include/uapi/drm/drm_fourcc.h
> +++ b/include/uapi/drm/drm_fourcc.h
> @@ -58,6 +58,28 @@ extern "C" {
> * may preserve meaning - such as number of planes - from the fourcc code,
> * whereas others may not.
> *
> + * Modifiers must uniquely encode buffer layout. In other words, a buffer
> must
> + * match only a single modifier. A modifier must not be a subset of layouts
> of
> + * another modifier. For instance, it's incorrect to encode pitch alignment
> in
> + * a modifier: a buffer may match a 64-pixel aligned modifier and a 32-pixel
> + * aligned modifier. That said, modifiers can have implicit minimal
> + * requirements.
> + *
> + * For modifiers where the combination of fourcc code and modifier can alias,
> + * a canonical pair needs to be defined and used by all drivers. An example
> + * is AFBC, where both ARGB and ABGR have the exact same compressed layout.
I still don't agree with this sentence. ARGB and ABGR have different
compressed layouts in AFBC.
Thanks,
-Brian
> + *
> + * There are two kinds of modifier users:
> + *
> + * - Kernel and user-space drivers: for drivers it's important that modifiers
> + * don't alias, otherwise two drivers might support the same format but use
> + * different aliases, preventing them from sharing buffers in an efficient
> + * format.
> + * - Higher-level programs interfacing with KMS/GBM/EGL/Vulkan/etc: these
> users
> + * see modifiers as opaque tokens they can check for equality and
> intersect.
> + * These users musn't need to know to reason about the modifier value
> + * (i.e. they are not expected to extract information out of the modifier).
> + *
> * Vendors should document their modifier usage in as much detail as
> * possible, to ensure maximum compatibility across devices, drivers and
> * applications.
> --
> 2.27.0
>
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/2] drm: drm_fourcc: add NV20 YUV format
Hi Jonas,
On Sun, Jun 07, 2020 at 08:25:25PM +, Jonas Karlman wrote:
> DRM_FORMAT_NV20 is a 2 plane format suitable for linear memory layout.
> The format is similar to P210 with 4:2:2 sub-sampling but has no padding
> between components. Instead, luminance and chrominance samples are grouped
> into 4s so that each group is packed into an integer number of bytes:
>
> = UVUV = 4 * 10 bits = 40 bits = 5 bytes
>
> The '20' suffix refers to the optimum effective bits per pixel which is
> achieved when the total number of luminance samples is a multiple of 4.
>
> Signed-off-by: Jonas Karlman
> ---
> drivers/gpu/drm/drm_fourcc.c | 4
> include/uapi/drm/drm_fourcc.h | 1 +
> 2 files changed, 5 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_fourcc.c b/drivers/gpu/drm/drm_fourcc.c
> index 722c7ebe4e88..2a9c8ae719ed 100644
> --- a/drivers/gpu/drm/drm_fourcc.c
> +++ b/drivers/gpu/drm/drm_fourcc.c
> @@ -278,6 +278,10 @@ const struct drm_format_info *__drm_format_info(u32
> format)
> .num_planes = 2, .char_per_block = { 5, 5, 0 },
> .block_w = { 4, 2, 0 }, .block_h = { 1, 1, 0 }, .hsub = 2,
> .vsub = 2, .is_yuv = true },
> + { .format = DRM_FORMAT_NV20,.depth = 0,
> + .num_planes = 2, .char_per_block = { 5, 5, 0 },
> + .block_w = { 4, 2, 0 }, .block_h = { 1, 1, 0 }, .hsub = 2,
> + .vsub = 1, .is_yuv = true },
That looks how I would expect, so:
Reviewed-by: Brian Starkey
Cheers,
-Brian
> { .format = DRM_FORMAT_Q410,.depth = 0,
> .num_planes = 3, .char_per_block = { 2, 2, 2 },
> .block_w = { 1, 1, 1 }, .block_h = { 1, 1, 1 }, .hsub = 0,
> diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
> index b5bf1c0e630e..244d32433a67 100644
> --- a/include/uapi/drm/drm_fourcc.h
> +++ b/include/uapi/drm/drm_fourcc.h
> @@ -242,6 +242,7 @@ extern "C" {
> * index 1 = Cr:Cb plane, [39:0] Cr1:Cb1:Cr0:Cb0 little endian
> */
> #define DRM_FORMAT_NV15 fourcc_code('N', 'V', '1', '5') /* 2x2
> subsampled Cr:Cb plane */
> +#define DRM_FORMAT_NV20 fourcc_code('N', 'V', '2', '0') /* 2x1
> subsampled Cr:Cb plane */
>
> /*
> * 2 plane YCbCr MSB aligned
> --
> 2.17.1
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3] drm/fourcc: document modifier uniqueness requirements
Sorry for commenting on the obsolete v1 - that'll teach me for reading
my backlog chronologically.
On Thu, May 28, 2020 at 02:38:36PM +, Simon Ser wrote:
> There have suggestions to bake pitch alignment, address alignement,
> contiguous memory or other placement (hidden VRAM, GTT/BAR, etc)
> constraints into modifiers. Last time this was brought up it seemed
> like the consensus was to not allow this. Document this in drm_fourcc.h.
>
> There are several reasons for this.
>
> - Encoding all of these constraints in the modifiers would explode the
> search space pretty quickly (we only have 64 bits to work with).
> - Modifiers need to be unambiguous: a buffer can only have a single
> modifier.
> - Modifier users aren't expected to parse modifiers.
>
> v2: add paragraph about aliases (Daniel)
>
> v3: fix unrelated changes sent with the patch
>
> Signed-off-by: Simon Ser
> Reviewed-by: Daniel Vetter
> Cc: Daniel Stone
> Cc: Bas Nieuwenhuizen
> Cc: Dave Airlie
> Cc: Marek Olšák
> ---
> include/uapi/drm/drm_fourcc.h | 15 +++
> 1 file changed, 15 insertions(+)
>
> diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
> index 490143500a50..f41fcb1ed63d 100644
> --- a/include/uapi/drm/drm_fourcc.h
> +++ b/include/uapi/drm/drm_fourcc.h
> @@ -58,6 +58,21 @@ extern "C" {
> * may preserve meaning - such as number of planes - from the fourcc code,
> * whereas others may not.
> *
> + * Modifiers must uniquely encode buffer layout. In other words, a buffer
> must
> + * match only a single modifier. A modifier must not be a subset of layouts
> of
> + * another modifier. For instance, it's incorrect to encode pitch alignment
> in
> + * a modifier: a buffer may match a 64-pixel aligned modifier and a 32-pixel
> + * aligned modifier. That said, modifiers can have implicit minimal
> + * requirements.
> + *
> + * For modifiers where the combination of fourcc code and modifier can alias,
> + * a canonical pair needs to be defined and used by all drivers. An example
> + * is AFBC, where both ARGB and ABGR have the exact same compressed layout.
As I mentioned, this isn't true for AFBC (at least, it shouldn't be),
so I don't think we can use that as an example.
We define a "canonical" ordering in AFBC for exactly this reason - the
ordering can differ and not all decoders support all orderings, so we
need to pick one for best compatibility.
Thanks,
-Brian
> + *
> + * Users see modifiers as opaque tokens they can check for equality and
> + * intersect. Users musn't need to know to reason about the modifier value
> + * (i.e. users are not expected to extract information out of the modifier).
> + *
> * Vendors should document their modifier usage in as much detail as
> * possible, to ensure maximum compatibility across devices, drivers and
> * applications.
> --
> 2.26.2
>
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/fourcc: document modifier uniqueness requirements
On Wed, May 27, 2020 at 10:55:34AM +0200, Daniel Vetter wrote:
> On Wed, May 27, 2020 at 08:52:00AM +, Simon Ser wrote:
> > There have suggestions to bake pitch alignment, address alignement,
> > contiguous memory or other placement (hidden VRAM, GTT/BAR, etc)
> > constraints into modifiers. Last time this was brought up it seemed
> > like the consensus was to not allow this. Document this in drm_fourcc.h.
> >
> > There are several reasons for this.
> >
> > - Encoding all of these constraints in the modifiers would explode the
> > search space pretty quickly (we only have 64 bits to work with).
> > - Modifiers need to be unambiguous: a buffer can only have a single
> > modifier.
> > - Modifier users aren't expected to parse modifiers.
> >
> > Signed-off-by: Simon Ser
> > Cc: Daniel Vetter
> > Cc: Daniel Stone
> > Cc: Bas Nieuwenhuizen
> > Cc: Dave Airlie
> > Cc: Marek Olšák
> > ---
> > include/uapi/drm/drm_fourcc.h | 11 +++
> > 1 file changed, 11 insertions(+)
> >
> > diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
> > index 490143500a50..97eb0f1cf9f8 100644
> > --- a/include/uapi/drm/drm_fourcc.h
> > +++ b/include/uapi/drm/drm_fourcc.h
> > @@ -58,6 +58,17 @@ extern "C" {
> > * may preserve meaning - such as number of planes - from the fourcc code,
> > * whereas others may not.
> > *
> > + * Modifiers must uniquely encode buffer layout. In other words, a buffer
> > must
> > + * match only a single modifier. A modifier must not be a subset of
> > layouts of
> > + * another modifier. For instance, it's incorrect to encode pitch
> > alignment in
> > + * a modifier: a buffer may match a 64-pixel aligned modifier and a
> > 32-pixel
> > + * aligned modifier. That said, modifiers can have implicit minimal
> > + * requirements.
>
> I think we should also add the aliasing when the fourcc codes are
> involved, with afbc as example. Maybe:
>
> For modifiers where the combination of fourcc code and modifier can alias,
> a canonical pair needs to be defined and used by all drivers. An example
> is afbc, where both argb and abgr have the exact same compressed layout.
That's actually explicitly _not_ the case for AFBC, which was one of
the things I was trying to document in afbc.rst.
>
> With something like that added:
>
> Reviewed-by: Daniel Vetter
>
>
> > + *
> > + * Users see modifiers as opaque tokens they can check for equality and
> > + * intersect. Users musn't need to know to reason about the modifier value
> > + * (i.e. users are not expected to extract information out of the
> > modifier).
> > + *
Doesn't this conflict with "implicit minimal requirements" above?
Certainly for a bunch of different AFBC modifiers, the allocator would
need to understand some fields in order to properly align-up the
buffer size.
Thanks,
-Brian
> > * Vendors should document their modifier usage in as much detail as
> > * possible, to ensure maximum compatibility across devices, drivers and
> > * applications.
> > --
> > 2.26.2
> >
> >
>
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm: drm_fourcc: add NV15, Q410, Q401 YUV formats
Hi Jonas,
On Mon, May 25, 2020 at 11:08:11AM +, Jonas Karlman wrote:
> Hi,
>
> On 2020-05-15 15:37, Brian Starkey wrote:
> > Hi Ben,
> >
> > On Wed, May 06, 2020 at 03:41:26PM +0100, Ben Davis wrote:
> >> Hi all, any feedback on this patch?
> >> Thanks, Ben
> >> On Wed, Apr 22, 2020 at 12:13:49PM +0100, Ben Davis wrote:
> >>> DRM_FORMAT_NV15 is a 2 plane format suitable for linear and 16x16
> >>> block-linear memory layouts. The format is similar to P010 with 4:2:0
> >>> sub-sampling but has no padding between components. Instead, luminance
> >>> and chrominance samples are grouped into 4s so that each group is packed
> >>> into an integer number of bytes:
> >>>
> >>> = UVUV = 4 * 10 bits = 40 bits = 5 bytes
> >>>
> >>> The '15' suffix refers to the optimum effective bits per pixel which is
> >>> achieved when the total number of luminance samples is a multiple of 8.
> >>>
> >>> Q410 and Q401 are both 3 plane non-subsampled formats with 16 bits per
> >>> component, but only 10 bits are used and 6 are padded. 'Q' is chosen
> >>> as the first letter to denote 3 plane YUV444, (and is the next letter
> >>> along from P which is usually 2 plane).
> >>>
> >>> Signed-off-by: Ben Davis
> >
> > The descriptions match my understanding of the formats and the
> > format_info struct, so feel free to add my r-b:
> >
> > Reviewed-by: Brian Starkey
> >
> > Can anyone else pass comment on the approach and/or naming? I feel
> > like we should have some non-Arm eyes on this before we merge it.
>
> This pixel format seem to match the memory layout used for 10-bit 4:2:0 by the
> Rockchip Video Decoder, for the rkvdec a 4:2:2 format is also needed (maybe
> NV20?).
>
> From what I can tell the rockchip specific pixel format has previously been
> submitted in [1]
> and GStreamer use NV12_10LE40 (fourcc RK20) for this pixel format.
>
> [1] https://patchwork.freedesktop.org/patch/276029/
>
Yeah you're right, this is the same as the Rockchip version. I see
Randy's submission has `block_w = { 4, 2, 0 }`... more on that below.
The comment on block_w says "in pixels" - but what's a pixel in a
subsampled chroma plane? For a 2-plane 4:2:0 format, is one pair of
chroma samples a single pixel, or one pair of chroma samples is two
pixels?
Looks like Randy assumed the former and us the latter.
> >
> > Thanks,
> > -Brian
> >
> >>> ---
> >>> drivers/gpu/drm/drm_fourcc.c | 12
> >>> include/uapi/drm/drm_fourcc.h | 24
> >>> 2 files changed, 36 insertions(+)
> >>>
> >>> diff --git a/drivers/gpu/drm/drm_fourcc.c b/drivers/gpu/drm/drm_fourcc.c
> >>> index b234bfaeda06..0c0a65481afd 100644
> >>> --- a/drivers/gpu/drm/drm_fourcc.c
> >>> +++ b/drivers/gpu/drm/drm_fourcc.c
> >>> @@ -274,6 +274,18 @@ const struct drm_format_info *__drm_format_info(u32
> >>> format)
> >>> { .format = DRM_FORMAT_YUV420_10BIT,.depth = 0,
> >>> .num_planes = 1, .cpp = { 0, 0, 0 }, .hsub = 2, .vsub = 2,
> >>> .is_yuv = true },
> >>> + { .format = DRM_FORMAT_NV15,.depth = 0,
> >>> + .num_planes = 2, .char_per_block = { 5, 5, 0 },
> >>> + .block_w = { 4, 4, 0 }, .block_h = { 1, 1, 0 }, .hsub = 2,
> >>> + .vsub = 2, .is_yuv = true },
>
> For a 4:2:0 format I wonder if the char_per_block value is correct for the
> second plane,
> using the following formula to calculate the pitch seem to result in only
> half expected width.
> Maybe .char_per_block { 5, 10, 0 } could be correct?
>
> pitch = (width * char_per_block[1]) / block_w[1] / hsub
>
> for 16x16 this would be
>
> pitch[1] = (16 * 5) / 4 / 2 = 10 bytes
> vs
> pitch[1] = (16 * 10) / 4 / 2 = 20 bytes
>
> height[1] = 16 / 2 = 8
>
I've talked myself round in circles, I don't know what to think any
more.
drm_format_info_min_pitch() does:
pitch[1] = width * char_per_block[1] / (block_w[1] * block_h[1])
so:
pitch[1] = 16 * 5 / (4 * 1) = 20 bytes
which implies that it expects the subsampling to be baked in to the
block size, or that it just doesn't consider subsampling and so is
broken, or that it expects `width` to be pre-divided.
Looking at DRM_FORMAT_NV12, it has cpp = {1, 2, 0}, which means it
considers a single pair of chromas to be a single pixel - which is
in-line with Randy.
So, I think our definition is inconsist
Re: [PATCH] drm: drm_fourcc: add NV15, Q410, Q401 YUV formats
Hi Ben,
On Wed, May 06, 2020 at 03:41:26PM +0100, Ben Davis wrote:
> Hi all, any feedback on this patch?
> Thanks, Ben
> On Wed, Apr 22, 2020 at 12:13:49PM +0100, Ben Davis wrote:
> > DRM_FORMAT_NV15 is a 2 plane format suitable for linear and 16x16
> > block-linear memory layouts. The format is similar to P010 with 4:2:0
> > sub-sampling but has no padding between components. Instead, luminance
> > and chrominance samples are grouped into 4s so that each group is packed
> > into an integer number of bytes:
> >
> > = UVUV = 4 * 10 bits = 40 bits = 5 bytes
> >
> > The '15' suffix refers to the optimum effective bits per pixel which is
> > achieved when the total number of luminance samples is a multiple of 8.
> >
> > Q410 and Q401 are both 3 plane non-subsampled formats with 16 bits per
> > component, but only 10 bits are used and 6 are padded. 'Q' is chosen
> > as the first letter to denote 3 plane YUV444, (and is the next letter
> > along from P which is usually 2 plane).
> >
> > Signed-off-by: Ben Davis
The descriptions match my understanding of the formats and the
format_info struct, so feel free to add my r-b:
Reviewed-by: Brian Starkey
Can anyone else pass comment on the approach and/or naming? I feel
like we should have some non-Arm eyes on this before we merge it.
Thanks,
-Brian
> > ---
> > drivers/gpu/drm/drm_fourcc.c | 12
> > include/uapi/drm/drm_fourcc.h | 24
> > 2 files changed, 36 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/drm_fourcc.c b/drivers/gpu/drm/drm_fourcc.c
> > index b234bfaeda06..0c0a65481afd 100644
> > --- a/drivers/gpu/drm/drm_fourcc.c
> > +++ b/drivers/gpu/drm/drm_fourcc.c
> > @@ -274,6 +274,18 @@ const struct drm_format_info *__drm_format_info(u32
> > format)
> > { .format = DRM_FORMAT_YUV420_10BIT,.depth = 0,
> > .num_planes = 1, .cpp = { 0, 0, 0 }, .hsub = 2, .vsub = 2,
> > .is_yuv = true },
> > + { .format = DRM_FORMAT_NV15,.depth = 0,
> > + .num_planes = 2, .char_per_block = { 5, 5, 0 },
> > + .block_w = { 4, 4, 0 }, .block_h = { 1, 1, 0 }, .hsub = 2,
> > + .vsub = 2, .is_yuv = true },
> > + { .format = DRM_FORMAT_Q410,.depth = 0,
> > + .num_planes = 3, .char_per_block = { 2, 2, 2 },
> > + .block_w = { 1, 1, 1 }, .block_h = { 1, 1, 1 }, .hsub = 0,
> > + .vsub = 0, .is_yuv = true },
> > + { .format = DRM_FORMAT_Q401,.depth = 0,
> > + .num_planes = 3, .char_per_block = { 2, 2, 2 },
> > + .block_w = { 1, 1, 1 }, .block_h = { 1, 1, 1 }, .hsub = 0,
> > + .vsub = 0, .is_yuv = true },
> > };
> >
> > unsigned int i;
> > diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
> > index 8bc0b31597d8..232b9ad3534d 100644
> > --- a/include/uapi/drm/drm_fourcc.h
> > +++ b/include/uapi/drm/drm_fourcc.h
> > @@ -236,6 +236,12 @@ extern "C" {
> > #define DRM_FORMAT_NV61fourcc_code('N', 'V', '6', '1') /* 2x1
> > subsampled Cb:Cr plane */
> > #define DRM_FORMAT_NV24fourcc_code('N', 'V', '2', '4') /*
> > non-subsampled Cr:Cb plane */
> > #define DRM_FORMAT_NV42fourcc_code('N', 'V', '4', '2') /*
> > non-subsampled Cb:Cr plane */
> > +/*
> > + * 2 plane YCbCr
> > + * index 0 = Y plane, [39:0] Y3:Y2:Y1:Y0 little endian
> > + * index 1 = Cr:Cb plane, [39:0] Cr1:Cb1:Cr0:Cb0 little endian
> > + */
> > +#define DRM_FORMAT_NV15fourcc_code('N', 'V', '1', '5') /* 2x2
> > subsampled Cr:Cb plane */
> >
> > /*
> > * 2 plane YCbCr MSB aligned
> > @@ -265,6 +271,24 @@ extern "C" {
> > */
> > #define DRM_FORMAT_P016fourcc_code('P', '0', '1', '6') /* 2x2
> > subsampled Cr:Cb plane 16 bits per channel */
> >
> > +
> > +/* 3 plane non-subsampled (444) YCbCr
> > + * 16 bits per component, but only 10 bits are used and 6 bits are padded
> > + * index 0: Y plane, [15:0] Y:x [10:6] little endian
> > + * index 1: Cb plane, [15:0] Cb:x [10:6] little endian
> > + * index 2: Cr plane, [15:0] Cr:x [10:6] little endian
> > + */
> > +#define DRM_FORMAT_Q410fourcc_code('Q', '4', '1', '0')
> > +
> > +/* 3 plane non-subsampled (444) YCrCb
> > + * 16 bits per component, but only 10 bits are used and 6 bits are padded
> > + * index 0: Y plane, [15:0] Y:x [10:6] little endian
> > + * index 1: Cr plane, [15:0] Cr:x [10:6] little endian
> > + * index 2: Cb plane, [15:0] Cb:x [10:6] little endian
> > + */
> > +#define DRM_FORMAT_Q401fourcc_code('Q', '4', '0', '1')
> > +
> > +
> > /*
> > * 3 plane YCbCr
> > * index 0: Y plane, [7:0] Y
> > --
> > 2.24.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC][PATCH 3/4] dma-buf: cma_heap: Extend logic to export CMA regions tagged with "linux,cma-heap"
On Thu, May 14, 2020 at 09:52:35AM -0500, Rob Herring wrote:
> On Wed, May 13, 2020 at 5:44 AM Brian Starkey wrote:
> >
> > Hi Rob,
> >
> > On Tue, May 12, 2020 at 11:37:14AM -0500, Rob Herring wrote:
> > > On Mon, May 04, 2020 at 10:06:28AM +0100, Brian Starkey wrote:
> > > > On Fri, May 01, 2020 at 12:01:40PM -0700, John Stultz wrote:
> > > > > On Fri, May 1, 2020 at 4:08 AM Robin Murphy
> > > > > wrote:
> > > > > >
> > > > > > On 2020-05-01 11:21 am, Brian Starkey wrote:
> > > > > > > Hi John,
> > > > > > >
> > > > > > > On Fri, May 01, 2020 at 07:39:48AM +, John Stultz wrote:
> > > > > > >> This patch reworks the cma_heap initialization so that
> > > > > > >> we expose both the default CMA region and any CMA regions
> > > > > > >> tagged with "linux,cma-heap" in the device-tree.
> > > > > > >>
> > > > > > >> Cc: Rob Herring
> > > > > > >> Cc: Sumit Semwal
> > > > > > >> Cc: "Andrew F. Davis"
> > > > > > >> Cc: Benjamin Gaignard
> > > > > > >> Cc: Liam Mark
> > > > > > >> Cc: Pratik Patel
> > > > > > >> Cc: Laura Abbott
> > > > > > >> Cc: Brian Starkey
> > > > > > >> Cc: Chenbo Feng
> > > > > > >> Cc: Alistair Strachan
> > > > > > >> Cc: Sandeep Patil
> > > > > > >> Cc: Hridya Valsaraju
> > > > > > >> Cc: Christoph Hellwig
> > > > > > >> Cc: Marek Szyprowski
> > > > > > >> Cc: Robin Murphy
> > > > > > >> Cc: Andrew Morton
> > > > > > >> Cc: devicet...@vger.kernel.org
> > > > > > >> Cc: dri-devel@lists.freedesktop.org
> > > > > > >> Cc: linux...@kvack.org
> > > > > > >> Signed-off-by: John Stultz
> > > > > > >> ---
> > > > > > >> drivers/dma-buf/heaps/cma_heap.c | 18 +-
> > > > > > >> 1 file changed, 9 insertions(+), 9 deletions(-)
> > > > > > >>
> > > > > > >> diff --git a/drivers/dma-buf/heaps/cma_heap.c
> > > > > > >> b/drivers/dma-buf/heaps/cma_heap.c
> > > > > > >> index 626cf7fd033a..dd154e2db101 100644
> > > > > > >> --- a/drivers/dma-buf/heaps/cma_heap.c
> > > > > > >> +++ b/drivers/dma-buf/heaps/cma_heap.c
> > > > > > >> @@ -141,6 +141,11 @@ static int __add_cma_heap(struct cma *cma,
> > > > > > >> void *data)
> > > > > > >> {
> > > > > > >> struct cma_heap *cma_heap;
> > > > > > >> struct dma_heap_export_info exp_info;
> > > > > > >> +struct cma *default_cma = dev_get_cma_area(NULL);
> > > > > > >> +
> > > > > > >> +/* We only add the default heap and explicitly tagged heaps
> > > > > > >> */
> > > > > > >> +if (cma != default_cma && !cma_dma_heap_enabled(cma))
> > > > > > >> +return 0;
> > > > > > >
> > > > > > > Thinking about the pl111 thread[1], I'm wondering if we should
> > > > > > > also
> > > > > > > let drivers call this directly to expose their CMA pools, even if
> > > > > > > they
> > > > > > > aren't tagged for dma-heaps in DT. But perhaps that's too close to
> > > > > > > policy.
> > > > > >
> > > > > > That sounds much like what my first thoughts were - apologies if I'm
> > > > > > wildly off-base here, but as far as I understand:
> > > > > >
> > > > > > - Device drivers know whether they have their own "memory-region"
> > > > > > or not.
> > > > > > - Device drivers already have to do *something* to participate in
> > > > > > dma-buf.
> > > > > > - Device drivers know best how they make use of both the above.
> > > > > > - Therefore couldn't it be left to drivers to choose whether to
> > > > > > register
&g
Re: [RFC][PATCH 3/4] dma-buf: cma_heap: Extend logic to export CMA regions tagged with "linux,cma-heap"
Hi Rob,
On Tue, May 12, 2020 at 11:37:14AM -0500, Rob Herring wrote:
> On Mon, May 04, 2020 at 10:06:28AM +0100, Brian Starkey wrote:
> > On Fri, May 01, 2020 at 12:01:40PM -0700, John Stultz wrote:
> > > On Fri, May 1, 2020 at 4:08 AM Robin Murphy wrote:
> > > >
> > > > On 2020-05-01 11:21 am, Brian Starkey wrote:
> > > > > Hi John,
> > > > >
> > > > > On Fri, May 01, 2020 at 07:39:48AM +, John Stultz wrote:
> > > > >> This patch reworks the cma_heap initialization so that
> > > > >> we expose both the default CMA region and any CMA regions
> > > > >> tagged with "linux,cma-heap" in the device-tree.
> > > > >>
> > > > >> Cc: Rob Herring
> > > > >> Cc: Sumit Semwal
> > > > >> Cc: "Andrew F. Davis"
> > > > >> Cc: Benjamin Gaignard
> > > > >> Cc: Liam Mark
> > > > >> Cc: Pratik Patel
> > > > >> Cc: Laura Abbott
> > > > >> Cc: Brian Starkey
> > > > >> Cc: Chenbo Feng
> > > > >> Cc: Alistair Strachan
> > > > >> Cc: Sandeep Patil
> > > > >> Cc: Hridya Valsaraju
> > > > >> Cc: Christoph Hellwig
> > > > >> Cc: Marek Szyprowski
> > > > >> Cc: Robin Murphy
> > > > >> Cc: Andrew Morton
> > > > >> Cc: devicet...@vger.kernel.org
> > > > >> Cc: dri-devel@lists.freedesktop.org
> > > > >> Cc: linux...@kvack.org
> > > > >> Signed-off-by: John Stultz
> > > > >> ---
> > > > >> drivers/dma-buf/heaps/cma_heap.c | 18 +-
> > > > >> 1 file changed, 9 insertions(+), 9 deletions(-)
> > > > >>
> > > > >> diff --git a/drivers/dma-buf/heaps/cma_heap.c
> > > > >> b/drivers/dma-buf/heaps/cma_heap.c
> > > > >> index 626cf7fd033a..dd154e2db101 100644
> > > > >> --- a/drivers/dma-buf/heaps/cma_heap.c
> > > > >> +++ b/drivers/dma-buf/heaps/cma_heap.c
> > > > >> @@ -141,6 +141,11 @@ static int __add_cma_heap(struct cma *cma, void
> > > > >> *data)
> > > > >> {
> > > > >> struct cma_heap *cma_heap;
> > > > >> struct dma_heap_export_info exp_info;
> > > > >> +struct cma *default_cma = dev_get_cma_area(NULL);
> > > > >> +
> > > > >> +/* We only add the default heap and explicitly tagged heaps */
> > > > >> +if (cma != default_cma && !cma_dma_heap_enabled(cma))
> > > > >> +return 0;
> > > > >
> > > > > Thinking about the pl111 thread[1], I'm wondering if we should also
> > > > > let drivers call this directly to expose their CMA pools, even if they
> > > > > aren't tagged for dma-heaps in DT. But perhaps that's too close to
> > > > > policy.
> > > >
> > > > That sounds much like what my first thoughts were - apologies if I'm
> > > > wildly off-base here, but as far as I understand:
> > > >
> > > > - Device drivers know whether they have their own "memory-region" or
> > > > not.
> > > > - Device drivers already have to do *something* to participate in
> > > > dma-buf.
> > > > - Device drivers know best how they make use of both the above.
> > > > - Therefore couldn't it be left to drivers to choose whether to register
> > > > their CMA regions as heaps, without having to mess with DT at all?
>
> +1, but I'm biased toward any solution not using DT. :)
>
> > > I guess I'm not opposed to this. But I guess I'd like to see some more
> > > details? You're thinking the pl111 driver would add the
> > > "memory-region" node itself?
> > >
> > > Assuming that's the case, my only worry is what if that memory-region
> > > node isn't a CMA area, but instead something like a carveout? Does the
> > > driver need to parse enough of the dt to figure out where to register
> > > the region as a heap?
> >
> > My thinking was more like there would already be a reserved-memory
> > node in DT for the chunk of memory, appropriately tagged so that it
> > gets added as a CMA region.
> >
> > The device's node would have "memory-region=<>;" and would
Re: [PATCH] dma-buf: heaps: Remove Unneeded variable "ret" in dma_heap_dma_buf_begin_cpu_access()
Hi Jason,
On Wed, May 06, 2020 at 02:18:51PM +0800, Jason Yan wrote:
> Fix the following coccicheck warning:
>
> drivers/dma-buf/heaps/heap-helpers.c:203:5-8: Unneeded variable: "ret".
> Return "0" on line 216
>
> Signed-off-by: Jason Yan
LGTM.
Reviewed-by: Brian Starkey
Thanks,
-Brian
> ---
> drivers/dma-buf/heaps/heap-helpers.c | 3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/drivers/dma-buf/heaps/heap-helpers.c
> b/drivers/dma-buf/heaps/heap-helpers.c
> index 9f964ca3f59c..c82872501ba2 100644
> --- a/drivers/dma-buf/heaps/heap-helpers.c
> +++ b/drivers/dma-buf/heaps/heap-helpers.c
> @@ -200,7 +200,6 @@ static int dma_heap_dma_buf_begin_cpu_access(struct
> dma_buf *dmabuf,
> {
> struct heap_helper_buffer *buffer = dmabuf->priv;
> struct dma_heaps_attachment *a;
> - int ret = 0;
>
> mutex_lock(>lock);
>
> @@ -213,7 +212,7 @@ static int dma_heap_dma_buf_begin_cpu_access(struct
> dma_buf *dmabuf,
> }
> mutex_unlock(>lock);
>
> - return ret;
> + return 0;
> }
>
> static int dma_heap_dma_buf_end_cpu_access(struct dma_buf *dmabuf,
> --
> 2.21.1
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC][PATCH 3/4] dma-buf: cma_heap: Extend logic to export CMA regions tagged with "linux,cma-heap"
On Fri, May 01, 2020 at 12:01:40PM -0700, John Stultz wrote:
> On Fri, May 1, 2020 at 4:08 AM Robin Murphy wrote:
> >
> > On 2020-05-01 11:21 am, Brian Starkey wrote:
> > > Hi John,
> > >
> > > On Fri, May 01, 2020 at 07:39:48AM +, John Stultz wrote:
> > >> This patch reworks the cma_heap initialization so that
> > >> we expose both the default CMA region and any CMA regions
> > >> tagged with "linux,cma-heap" in the device-tree.
> > >>
> > >> Cc: Rob Herring
> > >> Cc: Sumit Semwal
> > >> Cc: "Andrew F. Davis"
> > >> Cc: Benjamin Gaignard
> > >> Cc: Liam Mark
> > >> Cc: Pratik Patel
> > >> Cc: Laura Abbott
> > >> Cc: Brian Starkey
> > >> Cc: Chenbo Feng
> > >> Cc: Alistair Strachan
> > >> Cc: Sandeep Patil
> > >> Cc: Hridya Valsaraju
> > >> Cc: Christoph Hellwig
> > >> Cc: Marek Szyprowski
> > >> Cc: Robin Murphy
> > >> Cc: Andrew Morton
> > >> Cc: devicet...@vger.kernel.org
> > >> Cc: dri-devel@lists.freedesktop.org
> > >> Cc: linux...@kvack.org
> > >> Signed-off-by: John Stultz
> > >> ---
> > >> drivers/dma-buf/heaps/cma_heap.c | 18 +-
> > >> 1 file changed, 9 insertions(+), 9 deletions(-)
> > >>
> > >> diff --git a/drivers/dma-buf/heaps/cma_heap.c
> > >> b/drivers/dma-buf/heaps/cma_heap.c
> > >> index 626cf7fd033a..dd154e2db101 100644
> > >> --- a/drivers/dma-buf/heaps/cma_heap.c
> > >> +++ b/drivers/dma-buf/heaps/cma_heap.c
> > >> @@ -141,6 +141,11 @@ static int __add_cma_heap(struct cma *cma, void
> > >> *data)
> > >> {
> > >> struct cma_heap *cma_heap;
> > >> struct dma_heap_export_info exp_info;
> > >> +struct cma *default_cma = dev_get_cma_area(NULL);
> > >> +
> > >> +/* We only add the default heap and explicitly tagged heaps */
> > >> +if (cma != default_cma && !cma_dma_heap_enabled(cma))
> > >> +return 0;
> > >
> > > Thinking about the pl111 thread[1], I'm wondering if we should also
> > > let drivers call this directly to expose their CMA pools, even if they
> > > aren't tagged for dma-heaps in DT. But perhaps that's too close to
> > > policy.
> >
> > That sounds much like what my first thoughts were - apologies if I'm
> > wildly off-base here, but as far as I understand:
> >
> > - Device drivers know whether they have their own "memory-region" or not.
> > - Device drivers already have to do *something* to participate in dma-buf.
> > - Device drivers know best how they make use of both the above.
> > - Therefore couldn't it be left to drivers to choose whether to register
> > their CMA regions as heaps, without having to mess with DT at all?
>
> I guess I'm not opposed to this. But I guess I'd like to see some more
> details? You're thinking the pl111 driver would add the
> "memory-region" node itself?
>
> Assuming that's the case, my only worry is what if that memory-region
> node isn't a CMA area, but instead something like a carveout? Does the
> driver need to parse enough of the dt to figure out where to register
> the region as a heap?
My thinking was more like there would already be a reserved-memory
node in DT for the chunk of memory, appropriately tagged so that it
gets added as a CMA region.
The device's node would have "memory-region=<>;" and would use
of_reserved_mem_device_init() to link up dev->cma_area to the
corresponding cma region.
So far, that's all in-place already. The bit that's missing is
exposing that dev->cma_area to userspace as a dma_heap - so we could
just have "int cma_heap_add(struct cma *cma)" or "int
cma_heap_dev_add(struct device *dev)" or something exported for
drivers to expose their device-assigned cma region if they wanted to.
I don't think this runs into the lifetime problems of generalised
heaps-as-modules either, because the CMA region will never go away
even if the driver does.
Alongside that, I do think the completely DT-driven approach can be
useful too - because there may be regions which aren't associated with
any specific device driver, that we want exported as heaps.
Hope that makes sense,
-Brian
>
> thanks
> -john
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC][PATCH 1/4] devicetree: bindings: Add linux,cma-heap tag for reserved memory
On Fri, May 01, 2020 at 11:40:16AM -0700, John Stultz wrote: > On Fri, May 1, 2020 at 3:42 AM Brian Starkey wrote: > > > > Hi, > > > > On Fri, May 01, 2020 at 07:39:46AM +, John Stultz wrote: > > > This patch adds a linux,cma-heap property for CMA reserved memory > > > regions, which will be used to allow the region to be exposed via > > > the DMA-BUF Heaps interface > > > > > > Cc: Rob Herring > > > Cc: Sumit Semwal > > > Cc: "Andrew F. Davis" > > > Cc: Benjamin Gaignard > > > Cc: Liam Mark > > > Cc: Pratik Patel > > > Cc: Laura Abbott > > > Cc: Brian Starkey > > > Cc: Chenbo Feng > > > Cc: Alistair Strachan > > > Cc: Sandeep Patil > > > Cc: Hridya Valsaraju > > > Cc: Christoph Hellwig > > > Cc: Marek Szyprowski > > > Cc: Robin Murphy > > > Cc: Andrew Morton > > > Cc: devicet...@vger.kernel.org > > > Cc: dri-devel@lists.freedesktop.org > > > Cc: linux...@kvack.org > > > Signed-off-by: John Stultz > > > --- > > > .../devicetree/bindings/reserved-memory/reserved-memory.txt| 3 +++ > > > 1 file changed, 3 insertions(+) > > > > > > diff --git > > > a/Documentation/devicetree/bindings/reserved-memory/reserved-memory.txt > > > b/Documentation/devicetree/bindings/reserved-memory/reserved-memory.txt > > > index bac4afa3b197..e97b6a4c3bc0 100644 > > > --- > > > a/Documentation/devicetree/bindings/reserved-memory/reserved-memory.txt > > > +++ > > > b/Documentation/devicetree/bindings/reserved-memory/reserved-memory.txt > > > @@ -68,6 +68,9 @@ Linux implementation note: > > > - If a "linux,cma-default" property is present, then Linux will use the > > >region for the default pool of the contiguous memory allocator. > > > > > > +- If a "linux,cma-heap" property is present, then Linux will expose the > > > + the CMA region via the DMA-BUF Heaps interface. > > > + > > > > Would it be useful or even possible to give some indication of what > > the heap will end up being called? I'm afraid I don't remember what if > > any conclusions came out of previous discussions on UAPI for heap > > enumeration. > > So the name we expose is the CMA name itself. So with dt it will be > the name of the reserved memory node that the flag property is added > to. > Yeah I'm just wondering if that's "stable" so we can say "the heap will use the node name", or if saying that would cause us a headache in the future. > > I suppose CMA names haven't been relevant to userspace before, but > > they perhaps would be with this change. > > > > Alternatively, leaving it effectively undefined doesn't tie us down, > > and something like links in sysfs can be added as a richer API in the > > future. > > Hrm. Mind expanding on what you're thinking here? Super hand-wavy, something like: /sys/devices/blah/display@2f00/cma_region is a symlink to /sys/class/dma_heaps/heap_display I think danvet had some thoughts in this vein. Cheers, -Brian > > thanks > -john ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC][PATCH 2/4] mm: cma: Add dma_heap flag to cma structure
On Fri, May 01, 2020 at 07:39:47AM +, John Stultz wrote:
> This patch adds a dma_heap flag on the cma structure,
> along with accessors to set and read the flag.
>
> This is then used to process and store the "linux,cma-heap"
> property documented in the previous patch.
>
> Cc: Rob Herring
> Cc: Sumit Semwal
> Cc: "Andrew F. Davis"
> Cc: Benjamin Gaignard
> Cc: Liam Mark
> Cc: Pratik Patel
> Cc: Laura Abbott
> Cc: Brian Starkey
> Cc: Chenbo Feng
> Cc: Alistair Strachan
> Cc: Sandeep Patil
> Cc: Hridya Valsaraju
> Cc: Christoph Hellwig
> Cc: Marek Szyprowski
> Cc: Robin Murphy
> Cc: Andrew Morton
> Cc: devicet...@vger.kernel.org
> Cc: dri-devel@lists.freedesktop.org
> Cc: linux...@kvack.org
> Signed-off-by: John Stultz
> ---
> include/linux/cma.h | 3 +++
> kernel/dma/contiguous.c | 3 +++
> mm/cma.c| 11 +++
> mm/cma.h| 1 +
> 4 files changed, 18 insertions(+)
>
> diff --git a/include/linux/cma.h b/include/linux/cma.h
> index 6ff79fefd01f..d8b8e6ce221c 100644
> --- a/include/linux/cma.h
> +++ b/include/linux/cma.h
> @@ -25,6 +25,9 @@ extern phys_addr_t cma_get_base(const struct cma *cma);
> extern unsigned long cma_get_size(const struct cma *cma);
> extern const char *cma_get_name(const struct cma *cma);
>
> +extern void __init cma_enable_dma_heap(struct cma *cma, bool enabled);
> +extern bool cma_dma_heap_enabled(struct cma *cma);
> +
> extern int __init cma_declare_contiguous_nid(phys_addr_t base,
> phys_addr_t size, phys_addr_t limit,
> phys_addr_t alignment, unsigned int order_per_bit,
> diff --git a/kernel/dma/contiguous.c b/kernel/dma/contiguous.c
> index 8bc6f2d670f9..f667fd51daa2 100644
> --- a/kernel/dma/contiguous.c
> +++ b/kernel/dma/contiguous.c
> @@ -303,6 +303,7 @@ static int __init rmem_cma_setup(struct reserved_mem
> *rmem)
> phys_addr_t mask = align - 1;
> unsigned long node = rmem->fdt_node;
> bool default_cma = of_get_flat_dt_prop(node, "linux,cma-default", NULL);
> + bool heap_exported = of_get_flat_dt_prop(node, "linux,cma-heap", NULL);
> struct cma *cma;
> int err;
>
> @@ -332,6 +333,8 @@ static int __init rmem_cma_setup(struct reserved_mem
> *rmem)
> if (default_cma)
> dma_contiguous_set_default(cma);
>
> + cma_enable_dma_heap(cma, heap_exported);
> +
> rmem->ops = _cma_ops;
> rmem->priv = cma;
>
> diff --git a/mm/cma.c b/mm/cma.c
> index 0463ad2ce06b..ec671bd8f66e 100644
> --- a/mm/cma.c
> +++ b/mm/cma.c
> @@ -55,6 +55,16 @@ const char *cma_get_name(const struct cma *cma)
> return cma->name ? cma->name : "(undefined)";
> }
>
> +void __init cma_enable_dma_heap(struct cma *cma, bool enabled)
> +{
> + cma->dma_heap = enabled;
> +}
> +
> +bool cma_dma_heap_enabled(struct cma *cma)
> +{
> + return !!cma->dma_heap;
Stylistic thing, but I don't think the !! is really necessary. It's
already a bool anyway.
> +}
> +
> static unsigned long cma_bitmap_aligned_mask(const struct cma *cma,
>unsigned int align_order)
> {
> @@ -157,6 +167,7 @@ static int __init cma_init_reserved_areas(void)
> }
> core_initcall(cma_init_reserved_areas);
>
> +
nit: spurious newline
Cheers,
-Brian
> /**
> * cma_init_reserved_mem() - create custom contiguous area from reserved
> memory
> * @base: Base address of the reserved area
> diff --git a/mm/cma.h b/mm/cma.h
> index 33c0b517733c..6fe2242c724f 100644
> --- a/mm/cma.h
> +++ b/mm/cma.h
> @@ -13,6 +13,7 @@ struct cma {
> spinlock_t mem_head_lock;
> #endif
> const char *name;
> + bool dma_heap;
> };
>
> extern struct cma cma_areas[MAX_CMA_AREAS];
> --
> 2.17.1
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC][PATCH 1/4] devicetree: bindings: Add linux,cma-heap tag for reserved memory
Hi, On Fri, May 01, 2020 at 07:39:46AM +, John Stultz wrote: > This patch adds a linux,cma-heap property for CMA reserved memory > regions, which will be used to allow the region to be exposed via > the DMA-BUF Heaps interface > > Cc: Rob Herring > Cc: Sumit Semwal > Cc: "Andrew F. Davis" > Cc: Benjamin Gaignard > Cc: Liam Mark > Cc: Pratik Patel > Cc: Laura Abbott > Cc: Brian Starkey > Cc: Chenbo Feng > Cc: Alistair Strachan > Cc: Sandeep Patil > Cc: Hridya Valsaraju > Cc: Christoph Hellwig > Cc: Marek Szyprowski > Cc: Robin Murphy > Cc: Andrew Morton > Cc: devicet...@vger.kernel.org > Cc: dri-devel@lists.freedesktop.org > Cc: linux...@kvack.org > Signed-off-by: John Stultz > --- > .../devicetree/bindings/reserved-memory/reserved-memory.txt| 3 +++ > 1 file changed, 3 insertions(+) > > diff --git > a/Documentation/devicetree/bindings/reserved-memory/reserved-memory.txt > b/Documentation/devicetree/bindings/reserved-memory/reserved-memory.txt > index bac4afa3b197..e97b6a4c3bc0 100644 > --- a/Documentation/devicetree/bindings/reserved-memory/reserved-memory.txt > +++ b/Documentation/devicetree/bindings/reserved-memory/reserved-memory.txt > @@ -68,6 +68,9 @@ Linux implementation note: > - If a "linux,cma-default" property is present, then Linux will use the >region for the default pool of the contiguous memory allocator. > > +- If a "linux,cma-heap" property is present, then Linux will expose the > + the CMA region via the DMA-BUF Heaps interface. > + Would it be useful or even possible to give some indication of what the heap will end up being called? I'm afraid I don't remember what if any conclusions came out of previous discussions on UAPI for heap enumeration. I suppose CMA names haven't been relevant to userspace before, but they perhaps would be with this change. Alternatively, leaving it effectively undefined doesn't tie us down, and something like links in sysfs can be added as a richer API in the future. Cheers, -Brian > - If a "linux,dma-default" property is present, then Linux will use the >region for the default pool of the consistent DMA allocator. > > -- > 2.17.1 > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC][PATCH 3/4] dma-buf: cma_heap: Extend logic to export CMA regions tagged with "linux,cma-heap"
Hi John,
On Fri, May 01, 2020 at 07:39:48AM +, John Stultz wrote:
> This patch reworks the cma_heap initialization so that
> we expose both the default CMA region and any CMA regions
> tagged with "linux,cma-heap" in the device-tree.
>
> Cc: Rob Herring
> Cc: Sumit Semwal
> Cc: "Andrew F. Davis"
> Cc: Benjamin Gaignard
> Cc: Liam Mark
> Cc: Pratik Patel
> Cc: Laura Abbott
> Cc: Brian Starkey
> Cc: Chenbo Feng
> Cc: Alistair Strachan
> Cc: Sandeep Patil
> Cc: Hridya Valsaraju
> Cc: Christoph Hellwig
> Cc: Marek Szyprowski
> Cc: Robin Murphy
> Cc: Andrew Morton
> Cc: devicet...@vger.kernel.org
> Cc: dri-devel@lists.freedesktop.org
> Cc: linux...@kvack.org
> Signed-off-by: John Stultz
> ---
> drivers/dma-buf/heaps/cma_heap.c | 18 +-
> 1 file changed, 9 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/dma-buf/heaps/cma_heap.c
> b/drivers/dma-buf/heaps/cma_heap.c
> index 626cf7fd033a..dd154e2db101 100644
> --- a/drivers/dma-buf/heaps/cma_heap.c
> +++ b/drivers/dma-buf/heaps/cma_heap.c
> @@ -141,6 +141,11 @@ static int __add_cma_heap(struct cma *cma, void *data)
> {
> struct cma_heap *cma_heap;
> struct dma_heap_export_info exp_info;
> + struct cma *default_cma = dev_get_cma_area(NULL);
> +
> + /* We only add the default heap and explicitly tagged heaps */
> + if (cma != default_cma && !cma_dma_heap_enabled(cma))
> + return 0;
Thinking about the pl111 thread[1], I'm wondering if we should also
let drivers call this directly to expose their CMA pools, even if they
aren't tagged for dma-heaps in DT. But perhaps that's too close to
policy.
Cheers,
-Brian
[1] https://lists.freedesktop.org/archives/dri-devel/2020-April/264358.html
>
> cma_heap = kzalloc(sizeof(*cma_heap), GFP_KERNEL);
> if (!cma_heap)
> @@ -162,16 +167,11 @@ static int __add_cma_heap(struct cma *cma, void *data)
> return 0;
> }
>
> -static int add_default_cma_heap(void)
> +static int cma_heaps_init(void)
> {
> - struct cma *default_cma = dev_get_cma_area(NULL);
> - int ret = 0;
> -
> - if (default_cma)
> - ret = __add_cma_heap(default_cma, NULL);
> -
> - return ret;
> + cma_for_each_area(__add_cma_heap, NULL);
> + return 0;
> }
> -module_init(add_default_cma_heap);
> +module_init(cma_heaps_init);
> MODULE_DESCRIPTION("DMA-BUF CMA Heap");
> MODULE_LICENSE("GPL v2");
> --
> 2.17.1
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm: enable render nodes wherever buffer sharing is supported
On Wed, Apr 29, 2020 at 06:31:01PM +0100, Liviu Dudau wrote: > On Wed, Apr 29, 2020 at 09:51:19AM -0700, Peter Collingbourne wrote: > > On Wed, Apr 29, 2020 at 9:17 AM Brian Starkey wrote: > > > > > > Hi Peter, > > > > > > On Mon, Apr 27, 2020 at 01:05:13PM -0700, Peter Collingbourne wrote: > > > > Render nodes are not just useful for devices supporting GPU hardware > > > > acceleration. Even on devices that only support dumb frame buffers, > > > > they are useful in situations where composition (using software > > > > rasterization) and KMS are done in different processes with buffer > > > > sharing being used to send frame buffers between them. This is the > > > > situation on Android, where surfaceflinger is the compositor and the > > > > composer HAL uses KMS to display the buffers. Thus it is beneficial > > > > to expose render nodes on all devices that support buffer sharing. > > > > > > If I understand your problem right, the issue is that you're getting > > > your buffers in minigbm via pl111, which means you want a render node > > > just for buffer allocation? Then HWComposer will import those on the > > > primary node for displaying. > > > > Correct. > > > > > I'm not at all familiar with how minigbm sits in Android, but on our > > > platforms where the Display and GPU devices are different, we allocate > > > via ion in Gralloc, and import those into both the GPU and Display. > > > I think that should work on pl111 too - if you can allocate contiguous > > > memory from ion (or dma-buf heaps) in minigbm, then you don't need the > > > render node. > > > > Those contiguous memory regions would not necessarily be compatible > > with the pl111 device as far as I know -- according to [1], on some > > devices, a designated memory region must be used for the framebuffer > > and therefore the memory region allocated in CMA would not be > > compatible. That being said, FVP doesn't appear to be one of those > > devices, so in principle that might work for FVP (provided that the > > user provides a sufficiently large cma=X kernel command line > > argument), but not for those other devices. Yeah I'd be surprised if FVP cares about anything other than it being contiguous. My understanding of how "most" Android devices implement this is to have ion heaps representing whatever dedicated memory regions there are. Gralloc can then pick the appropriate one based on the gralloc usage flags. So allocations wouldn't go via the DRM driver. It looks like the checks in pl111 can't support that usage model if use_device_memory is set (though that wouldn't matter on FVP). > > We have been doing that with mali-dp drivers for years. Because most of > our dev environments are on FPGAs, we needed to use the local RAM on > those boards so we've had to assign a memory region to the driver that > in turn was using CMA. We've made heavy use of 'reserved-memory' and > 'memory-region' nodes in the DT to link the two together, but things > worked out quite well. Because the 'reserved-memory' sub-node was marked > as 'compatible="shared-dma-pool"', gralloc and ION could be used to > allocate memory from it. This is a little imperfect because ion doesn't have a way to access the `dev` pointer needed to allocate from device-attached CMA regions, so some hackery is required. I think dma-heaps would let you expose device-specific CMA regions. Even if you did that and allocated from the right place, the check in pl111 would reject any attempt to import it if it's set to use_device_memory. I don't know if there's a better way to tell if the memory is compatible, but that check seems like a bit of a sledgehammer. It looks like it not only forces the memory to be from the right place, it also forces it to have been allocated via pl111. On FVP though, I reckon any old CMA memory should be fine. Cheers, -Brian > > Best regards, > Liviu > > > > > Peter > > > > [1] > > https://www.kernel.org/doc/Documentation/devicetree/bindings/display/arm%2Cpl11x.txt > > -- > > | I would like to | > | fix the world, | > | but they're not | > | giving me the | > \ source code! / > --- > ¯\_(ツ)_/¯ ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm: enable render nodes wherever buffer sharing is supported
Hi Peter, On Mon, Apr 27, 2020 at 01:05:13PM -0700, Peter Collingbourne wrote: > Render nodes are not just useful for devices supporting GPU hardware > acceleration. Even on devices that only support dumb frame buffers, > they are useful in situations where composition (using software > rasterization) and KMS are done in different processes with buffer > sharing being used to send frame buffers between them. This is the > situation on Android, where surfaceflinger is the compositor and the > composer HAL uses KMS to display the buffers. Thus it is beneficial > to expose render nodes on all devices that support buffer sharing. If I understand your problem right, the issue is that you're getting your buffers in minigbm via pl111, which means you want a render node just for buffer allocation? Then HWComposer will import those on the primary node for displaying. I'm not at all familiar with how minigbm sits in Android, but on our platforms where the Display and GPU devices are different, we allocate via ion in Gralloc, and import those into both the GPU and Display. I think that should work on pl111 too - if you can allocate contiguous memory from ion (or dma-buf heaps) in minigbm, then you don't need the render node. Cheers, -Brian ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/4] drm/fourcc: Add modifier definitions for describing Amlogic Video Framebuffer Compression
On Tue, Mar 03, 2020 at 12:37:16PM +0100, Daniel Vetter wrote:
> On Tue, Mar 3, 2020 at 11:53 AM Brian Starkey wrote:
> >
> > Hi,
> >
> > On Tue, Mar 03, 2020 at 12:10:29PM +0200, Pekka Paalanen wrote:
> > > On Fri, 21 Feb 2020 10:08:42 +0100
> > > Neil Armstrong wrote:
> > >
> > > > Amlogic uses a proprietary lossless image compression protocol and
> > > > format
> > > > for their hardware video codec accelerators, either video decoders or
> > > > video input encoders.
> > > >
> > > > It considerably reduces memory bandwidth while writing and reading
> > > > frames in memory.
> > > >
> > > > The underlying storage is considered to be 3 components, 8bit or 10-bit
> > > > per component, YCbCr 420, single plane :
> > > > - DRM_FORMAT_YUV420_8BIT
> > > > - DRM_FORMAT_YUV420_10BIT
> > > >
> > > > This modifier will be notably added to DMA-BUF frames imported from the
> > > > V4L2
> > > > Amlogic VDEC decoder.
> > > >
> > > > At least two options are supported :
> > > > - Scatter mode: the buffer is filled with a IOMMU scatter table
> > > > referring
> > > > to the encoder current memory layout. This mode if more efficient in
> > > > terms
> > > > of memory allocation but frames are not dumpable and only valid
> > > > during until
> > > > the buffer is freed and back in control of the encoder
> > > > - Memory saving: when the pixel bpp is 8b, the size of the superblock
> > > > can
> > > > be reduced, thus saving memory.
> > > >
> > > > Signed-off-by: Neil Armstrong
> > > > ---
> > > > include/uapi/drm/drm_fourcc.h | 56 +++
> > > > 1 file changed, 56 insertions(+)
> > > >
> > > > diff --git a/include/uapi/drm/drm_fourcc.h
> > > > b/include/uapi/drm/drm_fourcc.h
> > > > index 8bc0b31597d8..8a6e87bacadb 100644
> > > > --- a/include/uapi/drm/drm_fourcc.h
> > > > +++ b/include/uapi/drm/drm_fourcc.h
> > > > @@ -309,6 +309,7 @@ extern "C" {
> > > > #define DRM_FORMAT_MOD_VENDOR_BROADCOM 0x07
> > > > #define DRM_FORMAT_MOD_VENDOR_ARM 0x08
> > > > #define DRM_FORMAT_MOD_VENDOR_ALLWINNER 0x09
> > > > +#define DRM_FORMAT_MOD_VENDOR_AMLOGIC 0x0a
> > > >
> > > > /* add more to the end as needed */
> > > >
> > > > @@ -804,6 +805,61 @@ extern "C" {
> > > > */
> > > > #define DRM_FORMAT_MOD_ALLWINNER_TILED fourcc_mod_code(ALLWINNER, 1)
> > > >
> > > > +/*
> > > > + * Amlogic Video Framebuffer Compression modifiers
> > > > + *
> > > > + * Amlogic uses a proprietary lossless image compression protocol and
> > > > format
> > > > + * for their hardware video codec accelerators, either video decoders
> > > > or
> > > > + * video input encoders.
> > > > + *
> > > > + * It considerably reduces memory bandwidth while writing and reading
> > > > + * frames in memory.
> > > > + * Implementation details may be platform and SoC specific, and shared
> > > > + * between the producer and the decoder on the same platform.
> > >
> > > Hi,
> > >
> > > after a lengthy IRC discussion on #dri-devel, this "may be platform and
> > > SoC specific" is a problem.
> > >
> > > It can be an issue in two ways:
> > >
> > > - If something in the data acts like a sub-modifier, then advertising
> > > support for one modifier does not really tell if the data layout is
> > > supported or not.
> > >
> > > - If you need to know the platform and/or SoC to be able to interpret
> > > the data, it means the modifier is ill-defined and cannot be used in
> > > inter-machine communication (e.g. Pipewire).
> > >
> >
> > Playing devil's advocate, the comment sounds similar to
> > I915_FORMAT_MOD_{X,Y}_TILED:
> >
> > * This format is highly platforms specific and not useful for cross-driver
> > * sharing. It exists since on a given platform it does uniquely identify
> > the
> > * layout in a simple way for i915-specific userspace.
>
> Yeah which we regret now. We need to now roll out a new set of
> modifiers for at least some of the differences in these on th
Re: [PATCH 1/4] drm/fourcc: Add modifier definitions for describing Amlogic Video Framebuffer Compression
Hi,
On Tue, Mar 03, 2020 at 12:10:29PM +0200, Pekka Paalanen wrote:
> On Fri, 21 Feb 2020 10:08:42 +0100
> Neil Armstrong wrote:
>
> > Amlogic uses a proprietary lossless image compression protocol and format
> > for their hardware video codec accelerators, either video decoders or
> > video input encoders.
> >
> > It considerably reduces memory bandwidth while writing and reading
> > frames in memory.
> >
> > The underlying storage is considered to be 3 components, 8bit or 10-bit
> > per component, YCbCr 420, single plane :
> > - DRM_FORMAT_YUV420_8BIT
> > - DRM_FORMAT_YUV420_10BIT
> >
> > This modifier will be notably added to DMA-BUF frames imported from the V4L2
> > Amlogic VDEC decoder.
> >
> > At least two options are supported :
> > - Scatter mode: the buffer is filled with a IOMMU scatter table referring
> > to the encoder current memory layout. This mode if more efficient in terms
> > of memory allocation but frames are not dumpable and only valid during
> > until
> > the buffer is freed and back in control of the encoder
> > - Memory saving: when the pixel bpp is 8b, the size of the superblock can
> > be reduced, thus saving memory.
> >
> > Signed-off-by: Neil Armstrong
> > ---
> > include/uapi/drm/drm_fourcc.h | 56 +++
> > 1 file changed, 56 insertions(+)
> >
> > diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
> > index 8bc0b31597d8..8a6e87bacadb 100644
> > --- a/include/uapi/drm/drm_fourcc.h
> > +++ b/include/uapi/drm/drm_fourcc.h
> > @@ -309,6 +309,7 @@ extern "C" {
> > #define DRM_FORMAT_MOD_VENDOR_BROADCOM 0x07
> > #define DRM_FORMAT_MOD_VENDOR_ARM 0x08
> > #define DRM_FORMAT_MOD_VENDOR_ALLWINNER 0x09
> > +#define DRM_FORMAT_MOD_VENDOR_AMLOGIC 0x0a
> >
> > /* add more to the end as needed */
> >
> > @@ -804,6 +805,61 @@ extern "C" {
> > */
> > #define DRM_FORMAT_MOD_ALLWINNER_TILED fourcc_mod_code(ALLWINNER, 1)
> >
> > +/*
> > + * Amlogic Video Framebuffer Compression modifiers
> > + *
> > + * Amlogic uses a proprietary lossless image compression protocol and
> > format
> > + * for their hardware video codec accelerators, either video decoders or
> > + * video input encoders.
> > + *
> > + * It considerably reduces memory bandwidth while writing and reading
> > + * frames in memory.
> > + * Implementation details may be platform and SoC specific, and shared
> > + * between the producer and the decoder on the same platform.
>
> Hi,
>
> after a lengthy IRC discussion on #dri-devel, this "may be platform and
> SoC specific" is a problem.
>
> It can be an issue in two ways:
>
> - If something in the data acts like a sub-modifier, then advertising
> support for one modifier does not really tell if the data layout is
> supported or not.
>
> - If you need to know the platform and/or SoC to be able to interpret
> the data, it means the modifier is ill-defined and cannot be used in
> inter-machine communication (e.g. Pipewire).
>
Playing devil's advocate, the comment sounds similar to
I915_FORMAT_MOD_{X,Y}_TILED:
* This format is highly platforms specific and not useful for cross-driver
* sharing. It exists since on a given platform it does uniquely identify the
* layout in a simple way for i915-specific userspace.
Isn't the statement that this for sharing between producer and decoder
_on the same platform_ a similar clause with the same effect?
What advantage is there to exposing the gory details? For Arm AFBC
it's necessary because IP on the SoC can be (likely to be) from
different vendors with different capabilities.
If this is only for talking between Amlogic IP on the same SoC, and
those devices support all the same "flavours", I don't see what is
gained by making userspace care about internals.
Thanks,
-Brian
> Neil mentioned the data contains a "header" that further specifies
> things, but there is no specification about the header itself.
> Therefore I don't think we can even know if the header contains
> something that acts like a sub-modifier or not.
>
> All this sounds like the modifier definitions here are not enough to
> fully interpret the data. At the very least I would expect a reference
> to a document explaining the "header", or even better, a kernel ReST
> doc.
>
> I wonder if this is at all suitable as a DRM format modifier as is. I
> have been assuming that a modifier together with all the usual FB
> parameters should be enough to interpret the stored data, but in this
> case I have doubt it actually is.
>
> I have no problem with proprietary data layouts as long as they are
> fully specified.
>
> I do feel like I would not be able to write a software decoder for this
> set of modifiers given the details below.
>
>
> Thanks,
> pq
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCHv2 1/4] drm/arm: Factor out generic afbc helpers
Hi Daniel,
On Thu, Nov 07, 2019 at 08:28:08PM +0100, Daniel Vetter wrote:
> On Thu, Nov 07, 2019 at 05:49:14PM +0000, Brian Starkey wrote:
> > Hi Daniel,
> >
> > On Thu, Nov 07, 2019 at 06:32:01PM +0100, Daniel Vetter wrote:
> > > On Thu, Nov 7, 2019 at 6:20 PM Brian Starkey
> > > wrote:
> > > >
> > > > Hi Daniel,
> > > >
> > > > On Tue, Nov 05, 2019 at 11:26:36PM +, Daniel Stone wrote:
> > > > > Hi Andrzej,
> > > > > Thanks for taking this on! It's looking better than v1 for sure. A few
> > > > > things below:
> > > > >
> > > > > On Mon, 2019-11-04 at 23:12 +0100, Andrzej Pietrasiewicz wrote:
> > > > > > +bool drm_afbc_check_offset(struct drm_device *dev,
> > > > > > + const struct drm_mode_fb_cmd2 *mode_cmd)
> > > > > > +{
> > > > > > + if (mode_cmd->offsets[0] != 0) {
> > > > > > + DRM_DEBUG_KMS("AFBC buffers' plane offset should be
> > > > > > 0\n");
> > > > > > + return false;
> > > > > > + }
> > > > > > +
> > > > > > + return true;
> > > > > > +}
> > > > > > +EXPORT_SYMBOL_GPL(drm_afbc_check_offset);
> > > > >
> > > > > Is this actually universally true? If the offset is sufficiently
> > > > > aligned for (e.g.) DMA transfers to succeed, is there any reason why
> > > > > it
> > > > > must be zero?
> > > > >
> > > > > > +bool drm_afbc_check_size_align(struct drm_device *dev,
> > > > > > + const struct drm_mode_fb_cmd2 *mode_cmd)
> > > > > > +{
> > > > > > + switch (mode_cmd->modifier[0] &
> > > > > > AFBC_FORMAT_MOD_BLOCK_SIZE_MASK) {
> > > > > > + case AFBC_FORMAT_MOD_BLOCK_SIZE_16x16:
> > > > > > + if ((mode_cmd->width % 16) || (mode_cmd->height % 16))
> > > > > > {
> > > > >
> > > > > This is a dealbreaker for many resolutions: for example, 1366x768
> > > > > isn't
> > > > > cleanly divisible by 16 in width. So this means that we would have to
> > > > > either use a larger buffer and crop, or scale, or something.
> > > > >
> > > > > No userspace is prepared to align fb width/height to tile dimensions
> > > > > like this, so this check will basically fail everywhere.
> > > > >
> > > > > However, overallocation relative to the declared width/height isn't a
> > > > > problem at all. In order to deal with horizontal alignment, you simply
> > > > > need to ensure that the stride is a multiple of the tile width; for
> > > > > vertical arrangement, that the buffer is large enough to contain
> > > > > sufficient 'lines' to the next tile boundary.
> > > > >
> > > > > i.e. rather than checking width/height, you should check:
> > > > > * fb_stride >= (ALIGN(fb_width, tile_width), bpp)
> > > > > * buf_size >= fb_stride * ALIGN(fb_height, tile_height)
> > > >
> > > > Well, sort of.
> > > >
> > > > I agree with you that for horizontal padding, we can indeed use pitch.
> > > >
> > > > However, the AFBC decoder(s) need to know exactly what the total
> > > > _allocated_ size in pixels of the buffer is - as this influences the
> > > > header size, and we need to know the header size to know where it ends
> > > > and the body begins.
> > > >
> > > > I see a couple of possible ways forwards:
> > > >
> > > > - Keep it as-is. The restrictive checks ensure that there's no
> > > >ambiguity and we use the fb width/height to determine the real
> > > >allocated width/height. Userspace needs to be AFBC-aware and set up
> > > >plane cropping to handle the alignment differences.
> > > >
> > > > - Use pitch to determine the "real" width, and internally in the
> > > >kernel align height up to the next alignment boundary. This works
> > > >OK, so long as there's no additional padding at the bottom of the
> > > >buffer. This would work, but I can't figure a way to check/enforce
> > > >that there's no additional padding at the bottom.
>
Re: [PATCHv2 1/4] drm/arm: Factor out generic afbc helpers
Hi Daniel,
On Thu, Nov 07, 2019 at 06:32:01PM +0100, Daniel Vetter wrote:
> On Thu, Nov 7, 2019 at 6:20 PM Brian Starkey wrote:
> >
> > Hi Daniel,
> >
> > On Tue, Nov 05, 2019 at 11:26:36PM +, Daniel Stone wrote:
> > > Hi Andrzej,
> > > Thanks for taking this on! It's looking better than v1 for sure. A few
> > > things below:
> > >
> > > On Mon, 2019-11-04 at 23:12 +0100, Andrzej Pietrasiewicz wrote:
> > > > +bool drm_afbc_check_offset(struct drm_device *dev,
> > > > + const struct drm_mode_fb_cmd2 *mode_cmd)
> > > > +{
> > > > + if (mode_cmd->offsets[0] != 0) {
> > > > + DRM_DEBUG_KMS("AFBC buffers' plane offset should be
> > > > 0\n");
> > > > + return false;
> > > > + }
> > > > +
> > > > + return true;
> > > > +}
> > > > +EXPORT_SYMBOL_GPL(drm_afbc_check_offset);
> > >
> > > Is this actually universally true? If the offset is sufficiently
> > > aligned for (e.g.) DMA transfers to succeed, is there any reason why it
> > > must be zero?
> > >
> > > > +bool drm_afbc_check_size_align(struct drm_device *dev,
> > > > + const struct drm_mode_fb_cmd2 *mode_cmd)
> > > > +{
> > > > + switch (mode_cmd->modifier[0] &
> > > > AFBC_FORMAT_MOD_BLOCK_SIZE_MASK) {
> > > > + case AFBC_FORMAT_MOD_BLOCK_SIZE_16x16:
> > > > + if ((mode_cmd->width % 16) || (mode_cmd->height % 16))
> > > > {
> > >
> > > This is a dealbreaker for many resolutions: for example, 1366x768 isn't
> > > cleanly divisible by 16 in width. So this means that we would have to
> > > either use a larger buffer and crop, or scale, or something.
> > >
> > > No userspace is prepared to align fb width/height to tile dimensions
> > > like this, so this check will basically fail everywhere.
> > >
> > > However, overallocation relative to the declared width/height isn't a
> > > problem at all. In order to deal with horizontal alignment, you simply
> > > need to ensure that the stride is a multiple of the tile width; for
> > > vertical arrangement, that the buffer is large enough to contain
> > > sufficient 'lines' to the next tile boundary.
> > >
> > > i.e. rather than checking width/height, you should check:
> > > * fb_stride >= (ALIGN(fb_width, tile_width), bpp)
> > > * buf_size >= fb_stride * ALIGN(fb_height, tile_height)
> >
> > Well, sort of.
> >
> > I agree with you that for horizontal padding, we can indeed use pitch.
> >
> > However, the AFBC decoder(s) need to know exactly what the total
> > _allocated_ size in pixels of the buffer is - as this influences the
> > header size, and we need to know the header size to know where it ends
> > and the body begins.
> >
> > I see a couple of possible ways forwards:
> >
> > - Keep it as-is. The restrictive checks ensure that there's no
> >ambiguity and we use the fb width/height to determine the real
> >allocated width/height. Userspace needs to be AFBC-aware and set up
> >plane cropping to handle the alignment differences.
> >
> > - Use pitch to determine the "real" width, and internally in the
> >kernel align height up to the next alignment boundary. This works
> >OK, so long as there's no additional padding at the bottom of the
> >buffer. This would work, but I can't figure a way to check/enforce
> >that there's no additional padding at the bottom.
> >
> > - Something else...
> >
> > The checks as-implemented were deliberately conservative, and don't
> > preclude doing some relaxation in the future.
> >
> > On Android, gralloc is used to store the "real" allocated width/height
> > and this is used to set up the DRM API appropriately.
>
> Fake stride + real visible h/w in the drmfb. Because that's how it
> works with all the tiled formats already, and expecting userspace to
> fudge this all correctly seems very backwards to me. In a way we had
> that entire fake stride discussion already for the block size format
> stuff already, but now in a different flavour.
Fake stride - like I said, no problem; sounds good. That solves one
dimension.
So do you have a proposal for how we determine what the allocated
height is in that case? I don't really see a way.
Thanks,
-Brian
>
> Also I think that's more reasons why this sh
Re: [PATCHv2 1/4] drm/arm: Factor out generic afbc helpers
Hi Daniel,
On Tue, Nov 05, 2019 at 11:26:36PM +, Daniel Stone wrote:
> Hi Andrzej,
> Thanks for taking this on! It's looking better than v1 for sure. A few
> things below:
>
> On Mon, 2019-11-04 at 23:12 +0100, Andrzej Pietrasiewicz wrote:
> > +bool drm_afbc_check_offset(struct drm_device *dev,
> > + const struct drm_mode_fb_cmd2 *mode_cmd)
> > +{
> > + if (mode_cmd->offsets[0] != 0) {
> > + DRM_DEBUG_KMS("AFBC buffers' plane offset should be
> > 0\n");
> > + return false;
> > + }
> > +
> > + return true;
> > +}
> > +EXPORT_SYMBOL_GPL(drm_afbc_check_offset);
>
> Is this actually universally true? If the offset is sufficiently
> aligned for (e.g.) DMA transfers to succeed, is there any reason why it
> must be zero?
>
> > +bool drm_afbc_check_size_align(struct drm_device *dev,
> > + const struct drm_mode_fb_cmd2 *mode_cmd)
> > +{
> > + switch (mode_cmd->modifier[0] &
> > AFBC_FORMAT_MOD_BLOCK_SIZE_MASK) {
> > + case AFBC_FORMAT_MOD_BLOCK_SIZE_16x16:
> > + if ((mode_cmd->width % 16) || (mode_cmd->height % 16))
> > {
>
> This is a dealbreaker for many resolutions: for example, 1366x768 isn't
> cleanly divisible by 16 in width. So this means that we would have to
> either use a larger buffer and crop, or scale, or something.
>
> No userspace is prepared to align fb width/height to tile dimensions
> like this, so this check will basically fail everywhere.
>
> However, overallocation relative to the declared width/height isn't a
> problem at all. In order to deal with horizontal alignment, you simply
> need to ensure that the stride is a multiple of the tile width; for
> vertical arrangement, that the buffer is large enough to contain
> sufficient 'lines' to the next tile boundary.
>
> i.e. rather than checking width/height, you should check:
> * fb_stride >= (ALIGN(fb_width, tile_width), bpp)
> * buf_size >= fb_stride * ALIGN(fb_height, tile_height)
Well, sort of.
I agree with you that for horizontal padding, we can indeed use pitch.
However, the AFBC decoder(s) need to know exactly what the total
_allocated_ size in pixels of the buffer is - as this influences the
header size, and we need to know the header size to know where it ends
and the body begins.
I see a couple of possible ways forwards:
- Keep it as-is. The restrictive checks ensure that there's no
ambiguity and we use the fb width/height to determine the real
allocated width/height. Userspace needs to be AFBC-aware and set up
plane cropping to handle the alignment differences.
- Use pitch to determine the "real" width, and internally in the
kernel align height up to the next alignment boundary. This works
OK, so long as there's no additional padding at the bottom of the
buffer. This would work, but I can't figure a way to check/enforce
that there's no additional padding at the bottom.
- Something else...
The checks as-implemented were deliberately conservative, and don't
preclude doing some relaxation in the future.
On Android, gralloc is used to store the "real" allocated width/height
and this is used to set up the DRM API appropriately.
>
> This may force us to do some silly cropping games inside the Rockchip
> KMS driver, but I feel it beats the alternative of breaking userspace.
Well, nothing's going to get broken - it's just perhaps not ready to
turn on AFBC yet.
>
> > + DRM_DEBUG_KMS(
> > + "AFBC buffer must be aligned to 16
> > pixels\n"
> > + );
> > + return false;
> > + }
> > + break;
> > + case AFBC_FORMAT_MOD_BLOCK_SIZE_32x8:
> > + /* fall through */
>
> It's also incongruous that 32x8 is unsupported here, but has a section
> in get_superblk_wh; please harmonise them so this section either does
> the checks as above, or that get_superblk_wh doesn't support 32x8
> either.
>
> > +bool drm_afbc_check_fb_size_ret(u32 pitch, int bpp,
> > + u32 w, u32 h, u32 superblk_w, u32
> > superblk_h,
> > + size_t size, u32 offset, u32 hdr_align,
> > + u32 *payload_off, u32 *total_size)
> > +{
> > + int n_superblks = 0;
> > + u32 superblk_sz = 0;
> > + u32 afbc_size = 0;
>
> Please don't initialise the above three variables, given that you go on
> to immediately change their values. In this case, initialising to zero
> can only hide legitimate uninitialised-variable-use warnings.
>
> > + n_superblks = (w / superblk_w) * (h / superblk_h);
> > + superblk_sz = (bpp * superblk_w * superblk_h) / BITS_PER_BYTE;
> > + afbc_size = ALIGN(n_superblks * AFBC_HEADER_SIZE, hdr_align);
> > + *payload_off = afbc_size;
> > +
> > + afbc_size += n_superblks * ALIGN(superblk_sz,
> > AFBC_SUPERBLK_ALIGNMENT);
> > + *total_size = afbc_size + offset;
>
> Generally these are referred to as 'tiles' rather than 'superblocks',
> given that I would
Re: [PATCH v14 1/5] dma-buf: Add dma-buf heaps framework
Hi Dave, On Tue, Nov 05, 2019 at 02:58:17AM +1000, Dave Airlie wrote: > On Mon, 4 Nov 2019 at 20:24, Brian Starkey wrote: > > > > Hi John, > > > > On Fri, Nov 01, 2019 at 09:42:34PM +, John Stultz wrote: > > > From: "Andrew F. Davis" > > > > > > This framework allows a unified userspace interface for dma-buf > > > exporters, allowing userland to allocate specific types of memory > > > for use in dma-buf sharing. > > > > > > Each heap is given its own device node, which a user can allocate > > > a dma-buf fd from using the DMA_HEAP_IOC_ALLOC. > > > > > > Additionally should the interface grow in the future, we have a > > > DMA_HEAP_IOC_GET_FEATURES ioctl which can return future feature > > > flags. > > > > The userspace patch doesn't use this - and there's no indication of > > what it's intended to allow in the future. I missed the discussion > > about it, do you have a link? > > > > I thought the preferred approach was to add the new ioctl only when we > > need it, and new userspace on old kernels will get "ENOSYS" to know > > that the kernel doesn't support it. > > This works once, expand the interface 3 or 4 times with no features > ioctl, and you start being hostile to userspace, which feature does > ENOSYS mean isn't supported etc. Sorry, perhaps I wasn't clear (or I misunderstand what you're saying about working only once). I'm not against adding a get_features ioctl, I just don't see why we'd add it before we have any features? When we gain the first "feature", can't we add the get_features ioctl then? For Future SW that knows about Future features, "ENOSYS" will always mean "no features". If it doesn't get ENOSYS, then it can use the ioctl to find out what features it has. Otherwise we're adding an ioctl which doesn't do anything, based on the assumption that in the future it _will_ do something... but we don't know that that is yet... but we're pretty sure whatever it will do can be described with a u64? Why not wait until we know what we want it for, and then implement it with an interface which we know is appropriate at that time? > > Next userspace starts to rely on kernel version, but then someone > backports a feature, down the rabbit hole we go. > I suppose that adding the feature ioctl later would mean that it might be possible to backport a feature without also backporting the ioctl, depending on how the patches are split up. I think it would be pretty hard to do accidentally though. Thanks, -Brian > Be nice to userspace give them a features ioctl they can use to figure > out in advance which of the 4 uapis the kernel supports. > > Dave. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v14 1/5] dma-buf: Add dma-buf heaps framework
Hi John, On Fri, Nov 01, 2019 at 09:42:34PM +, John Stultz wrote: > From: "Andrew F. Davis" > > This framework allows a unified userspace interface for dma-buf > exporters, allowing userland to allocate specific types of memory > for use in dma-buf sharing. > > Each heap is given its own device node, which a user can allocate > a dma-buf fd from using the DMA_HEAP_IOC_ALLOC. > > Additionally should the interface grow in the future, we have a > DMA_HEAP_IOC_GET_FEATURES ioctl which can return future feature > flags. The userspace patch doesn't use this - and there's no indication of what it's intended to allow in the future. I missed the discussion about it, do you have a link? I thought the preferred approach was to add the new ioctl only when we need it, and new userspace on old kernels will get "ENOSYS" to know that the kernel doesn't support it. > > This code is an evoluiton of the Android ION implementation, > and a big thanks is due to its authors/maintainers over time > for their effort: > Rebecca Schultz Zavin, Colin Cross, Benjamin Gaignard, > Laura Abbott, and many other contributors! > > Cc: Laura Abbott > Cc: Benjamin Gaignard > Cc: Sumit Semwal > Cc: Liam Mark > Cc: Pratik Patel > Cc: Brian Starkey > Cc: Vincent Donnefort > Cc: Sudipto Paul > Cc: Andrew F. Davis > Cc: Christoph Hellwig > Cc: Chenbo Feng > Cc: Alistair Strachan > Cc: Hridya Valsaraju > Cc: Sandeep Patil > Cc: Hillf Danton > Cc: Dave Airlie > Cc: dri-devel@lists.freedesktop.org > Signed-off-by: Andrew F. Davis > Signed-off-by: John Stultz > --- > v2: > * Folded down fixes I had previously shared in implementing > heaps > * Make flags a u64 (Suggested by Laura) > * Add PAGE_ALIGN() fix to the core alloc funciton > * IOCTL fixups suggested by Brian > * Added fixes suggested by Benjamin > * Removed core stats mgmt, as that should be implemented by > per-heap code > * Changed alloc to return a dma-buf fd, rather than a buffer > (as it simplifies error handling) > v3: > * Removed scare-quotes in MAINTAINERS email address > * Get rid of .release function as it didn't do anything (from > Christoph) > * Renamed filp to file (suggested by Christoph) > * Split out ioctl handling to separate function (suggested by > Christoph) > * Add comment documenting PAGE_ALIGN usage (suggested by Brian) > * Switch from idr to Xarray (suggested by Brian) > * Fixup cdev creation (suggested by Brian) > * Avoid EXPORT_SYMBOL until we finalize modules (suggested by > Brian) > * Make struct dma_heap internal only (folded in from Andrew) > * Small cleanups suggested by GregKH > * Provide class->devnode callback to get consistent /dev/ > subdirectory naming (Suggested by Bjorn) > v4: > * Folded down dma-heap.h change that was in a following patch > * Added fd_flags entry to allocation structure and pass it > through to heap code for use on dma-buf fd creation (suggested > by Benjamin) > v5: > * Minor cleanups > v6: > * Improved error path handling, minor whitespace fixes, both > suggested by Brian > v7: > * Longer Kconfig description to quiet checkpatch warnings > * Re-add compat_ioctl bits (Hridya noticed 32bit userland wasn't > working) > v8: > * Make struct dma_heap_ops consts (Suggested by Christoph) > * Checkpatch whitespace fixups > v9: > * Minor cleanups suggested by Brian Starkey > * Rename dma_heap_get_data->dma_heap_get_drvdata suggested > by Hilf Danton > v11: > * Kconfig text improvements suggested by Randy Dunlap > v12: > * Add logic to prevent duplicately named heaps being added > * Add symbol exports for heaps as modules > v13: > * Re-remove symbol exports per discussion w/ Brian. Will > resubmit in a separte patch for review > v14: > * Reworked ioctl handler to zero fill any difference in > structure size, similar to what the DRM core does, as > suggested by Dave Airlie > * Removed now unnecessary reserved bits in allocate_data > * Added get_features ioctl as suggested by Dave Airlie > * Removed pr_warn_once messages as requested by Dave > Airlie > --- > MAINTAINERS | 18 ++ > drivers/dma-buf/Kconfig | 9 + > drivers/dma-buf/Makefile | 1 + > drivers/dma-buf/dma-heap.c| 313 ++ > include/linux/dma-heap.h | 59 +++ > include/uapi/linux/dma-heap.h | 77 + > 6 files changed, 477 insertions(+) > create mode 100644 drivers/dma-buf/dma-heap.c > create mode 100644 include/linux/dma-heap.h > create mode 100644 include/uapi/linux/dma-heap.h > > diff --git a/MAINTAINERS b/MAINTAINERS > index c6c34d04ce95..77c3e993fb2f 100644
Re: [RFC][PATCH 2/2] dma-buf: heaps: Allow system & cma heaps to be configured as a modules
Hi John,
On Fri, Oct 25, 2019 at 11:48:34PM +, John Stultz wrote:
> Allow loading system and cma heap as a module instead of just as
> a statically built in heap.
>
> Since there isn't a good mechanism for dmabuf lifetime tracking
> it isn't safe to allow the heap drivers to be unloaded, so these
> drivers do not implement any module unloading functionality and
> will show up in lsmod as "[permanent]".
Cool, that alleviates my concerns :-)
>
> This patch also exports key functions from dmabuf heaps core and
> the heap helper functions so they can be accessed by the module.
>
> Cc: Laura Abbott
> Cc: Benjamin Gaignard
> Cc: Sumit Semwal
> Cc: Liam Mark
> Cc: Pratik Patel
> Cc: Brian Starkey
> Cc: Andrew F. Davis
> Cc: Andrew Morton
> Cc: Yue Hu
> Cc: Mike Rapoport
> Cc: Chenbo Feng
> Cc: Alistair Strachan
> Cc: Sandeep Patil
> Cc: Hridya Valsaraju
> Cc: dri-devel@lists.freedesktop.org
> Signed-off-by: John Stultz
> ---
> drivers/dma-buf/dma-heap.c | 2 ++
> drivers/dma-buf/heaps/Kconfig| 4 ++--
> drivers/dma-buf/heaps/heap-helpers.c | 2 ++
> 3 files changed, 6 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/dma-buf/dma-heap.c b/drivers/dma-buf/dma-heap.c
> index 9a41b73e54b4..2c4ac71a715b 100644
> --- a/drivers/dma-buf/dma-heap.c
> +++ b/drivers/dma-buf/dma-heap.c
> @@ -161,6 +161,7 @@ void *dma_heap_get_drvdata(struct dma_heap *heap)
> {
> return heap->priv;
> }
> +EXPORT_SYMBOL_GPL(dma_heap_get_drvdata);
>
> struct dma_heap *dma_heap_add(const struct dma_heap_export_info *exp_info)
> {
> @@ -243,6 +244,7 @@ struct dma_heap *dma_heap_add(const struct
> dma_heap_export_info *exp_info)
> kfree(heap);
> return err_ret;
> }
> +EXPORT_SYMBOL_GPL(dma_heap_add);
Maybe overly picky - but adding the note about "no safe way to remove,
so there's no dma_heap_remove" to a comment on this function may be
easier to notice than in the git log alone.
Cheers,
-Brian
>
> static char *dma_heap_devnode(struct device *dev, umode_t *mode)
> {
> diff --git a/drivers/dma-buf/heaps/Kconfig b/drivers/dma-buf/heaps/Kconfig
> index a5eef06c4226..e273fb18feca 100644
> --- a/drivers/dma-buf/heaps/Kconfig
> +++ b/drivers/dma-buf/heaps/Kconfig
> @@ -1,12 +1,12 @@
> config DMABUF_HEAPS_SYSTEM
> - bool "DMA-BUF System Heap"
> + tristate "DMA-BUF System Heap"
> depends on DMABUF_HEAPS
> help
> Choose this option to enable the system dmabuf heap. The system heap
> is backed by pages from the buddy allocator. If in doubt, say Y.
>
> config DMABUF_HEAPS_CMA
> - bool "DMA-BUF CMA Heap"
> + tristate "DMA-BUF CMA Heap"
> depends on DMABUF_HEAPS && DMA_CMA
> help
> Choose this option to enable dma-buf CMA heap. This heap is backed
> diff --git a/drivers/dma-buf/heaps/heap-helpers.c
> b/drivers/dma-buf/heaps/heap-helpers.c
> index 750bef4e902d..fb9835126893 100644
> --- a/drivers/dma-buf/heaps/heap-helpers.c
> +++ b/drivers/dma-buf/heaps/heap-helpers.c
> @@ -24,6 +24,7 @@ void init_heap_helper_buffer(struct heap_helper_buffer
> *buffer,
> INIT_LIST_HEAD(>attachments);
> buffer->free = free;
> }
> +EXPORT_SYMBOL_GPL(init_heap_helper_buffer);
>
> struct dma_buf *heap_helper_export_dmabuf(struct heap_helper_buffer *buffer,
> int fd_flags)
> @@ -37,6 +38,7 @@ struct dma_buf *heap_helper_export_dmabuf(struct
> heap_helper_buffer *buffer,
>
> return dma_buf_export(_info);
> }
> +EXPORT_SYMBOL_GPL(heap_helper_export_dmabuf);
>
> static void *dma_heap_map_kernel(struct heap_helper_buffer *buffer)
> {
> --
> 2.17.1
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v12 1/5] dma-buf: Add dma-buf heaps framework
On Fri, Oct 18, 2019 at 11:26:52AM -0700, John Stultz wrote: > On Fri, Oct 18, 2019 at 4:18 AM Brian Starkey wrote: > > On Fri, Oct 18, 2019 at 05:23:19AM +, John Stultz wrote: > > > > As in v3: > > > > * Avoid EXPORT_SYMBOL until we finalize modules (suggested by > >Brian) > > Heh. I guess it has been awhile. :) > > > Did something change in that regard? I still think letting modules > > register heaps without a way to remove them is a recipe for issues. > > So yea, in recent months, work around Android with their GKI effort > has made it necessary for ION heaps to be loadable from modules. I had > some patches in WIP tree to enable this, and in the rework I did > yesterday for the CMA module trivially collided with parts, and > forgetting the discussion back in v3, I figured I'd just fold those > bits in before I resubmitted for v12. Ah yes, I can see that would be needed. > > If it's an issue, I can pull it out, but I'm going to be submitting > module enablement for review as soon as the core bits are queued, as > its going to be important to support for Android to switch to this > from ION. > I don't know how to decide if it's an issue. My understanding is that if you rmmod something which has exported buffers, various Bad Things might happen; I believe including data leaks, corruption or crashing the kernel. There's probably plenty of scope for that with dma-buf exporters already, so it's not exactly "new" but it is a bit unfortunate. If "people" are OK with adding new code which has the same issue, then I'm not going to make any more of a fuss, because perfection is the enemy of progress. Perhaps an obvious comment pointing out the issue would be prudent, though - as a reminder to people that add heaps from their code (and wonder why there's no "dma_heap_remove" function). Cheers, -Brian > thanks > -john ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RESEND][PATCH v8 0/5] DMA-BUF Heaps (destaging ION)
On Sat, Oct 19, 2019 at 09:41:27AM -0400, Andrew F. Davis wrote:
> On 10/18/19 2:57 PM, Ayan Halder wrote:
> > On Fri, Oct 18, 2019 at 11:49:22AM -0700, John Stultz wrote:
> >> On Fri, Oct 18, 2019 at 11:41 AM Ayan Halder wrote:
> >>> On Fri, Oct 18, 2019 at 09:55:17AM +, Brian Starkey wrote:
> >>>> On Thu, Oct 17, 2019 at 01:57:45PM -0700, John Stultz wrote:
> >>>>> On Thu, Oct 17, 2019 at 12:29 PM Andrew F. Davis wrote:
> >>>>>> On 10/17/19 3:14 PM, John Stultz wrote:
> >>>>>>> But if the objection stands, do you have a proposal for an alternative
> >>>>>>> way to enumerate a subset of CMA heaps?
> >>>>>>>
> >>>>>> When in staging ION had to reach into the CMA framework as the other
> >>>>>> direction would not be allowed, so cma_for_each_area() was added. If
> >>>>>> DMA-BUF heaps is not in staging then we can do the opposite, and have
> >>>>>> the CMA framework register heaps itself using our framework. That way
> >>>>>> the CMA system could decide what areas to export or not (maybe based on
> >>>>>> a DT property or similar).
> >>>>>
> >>>>> Ok. Though the CMA core doesn't have much sense of DT details either,
> >>>>> so it would probably have to be done in the reserved_mem logic, which
> >>>>> doesn't feel right to me.
> >>>>>
> >>>>> I'd probably guess we should have some sort of dt binding to describe
> >>>>> a dmabuf cma heap and from that node link to a CMA node via a
> >>>>> memory-region phandle. Along with maybe the default heap as well? Not
> >>>>> eager to get into another binding review cycle, and I'm not sure what
> >>>>> non-DT systems will do yet, but I'll take a shot at it and iterate.
> >>>>>
> >>>>>> The end result is the same so we can make this change later (it has to
> >>>>>> come after DMA-BUF heaps is in anyway).
> >>>>>
> >>>>> Well, I'm hesitant to merge code that exposes all the CMA heaps and
> >>>>> then add patches that becomes more selective, should anyone depend on
> >>>>> the initial behavior. :/
> >>>>
> >>>> How about only auto-adding the system default CMA region (cma->name ==
> >>>> "reserved")?
> >>>>
> >>>> And/or the CMA auto-add could be behind a config option? It seems a
> >>>> shame to further delay this, and the CMA heap itself really is useful.
> >>>>
> >>> A bit of a detour, comming back to the issue why the following node
> >>> was not getting detected by the dma-buf heaps framework.
> >>>
> >>> reserved-memory {
> >>> #address-cells = <2>;
> >>> #size-cells = <2>;
> >>> ranges;
> >>>
> >>> display_reserved: framebuffer@6000 {
> >>> compatible = "shared-dma-pool";
> >>> linux,cma-default;
> >>> reusable; <<<<<<<<<<<<---This was missing
> >>> in our
> >>> earlier node
> >>> reg = <0 0x6000 0 0x0800>;
> >>> };
> >>
> >> Right. It has to be a CMA region for us to expose it from the cma heap.
> >>
> >>
> >>> With 'reusable', rmem_cma_setup() succeeds , but the kernel crashes as
> >>> follows :-
> >>>
> >>> [0.450562] WARNING: CPU: 2 PID: 1 at mm/cma.c:110
> >>> cma_init_reserved_areas+0xec/0x22c
> >>
> >> Is the value 0x6000 you're using something you just guessed at? It
> >> seems like the warning here is saying the pfn calculated from the base
> >> address isn't valid.
> > It is a valid memory region we use to allocate framebuffers.
>
>
> But does it have a valid kernel virtual mapping? Most ARM systems (just
> assuming you are working on ARM :)) that I'm familiar with have the DRAM
> space starting at 0x8000 and so don't start having valid pfns until
> that point. Is this address you are reserving an SRAM?
>
Yeah, I think you've got it.
This region is DRAM on an FPGA expansion tile, but as you have noticed
its "below" the start of main RAM, and I expect it's not in any of the
declared /memory/ nodes.
When "reusable" isn't there, I think we'll end up going the coherent.c
route, with dma_init_coherent_memory() setting up some pages.
If "reusable" is there, then I think we'll end up in contiguous.c and
that expects us to already have pages.
So, @Ayan, you could perhaps try adding this region as a /memory/ node
as-well, which should mean the kernel sets up some pages for it as
normal memory. But, I have some ancient recollection that the arm64
kernel couldn't handle system RAM at addresses below 0x8000 or
something. That might be different now, I'm talking about several
years ago.
Thanks,
-Brian
> Andrew
>
>
> >>
> >> thanks
> >> -john
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v12 4/5] dma-buf: heaps: Add CMA heap to dmabuf heaps
On Fri, Oct 18, 2019 at 05:23:22AM +, John Stultz wrote: > This adds a CMA heap, which allows userspace to allocate > a dma-buf of contiguous memory out of a CMA region. > > This code is an evolution of the Android ION implementation, so > thanks to its original author and maintainters: > Benjamin Gaignard, Laura Abbott, and others! > > NOTE: This patch only adds the default CMA heap. We will enable > selectively adding other CMA memory regions to the dmabuf heaps > interface with a later patch (which requires a dt binding) That'll teach me for reading my email in FIFO order. This approach makes sense to me. -Brian
Re: [PATCH v12 1/5] dma-buf: Add dma-buf heaps framework
Hi John, On Fri, Oct 18, 2019 at 05:23:19AM +, John Stultz wrote: > From: "Andrew F. Davis" > > This framework allows a unified userspace interface for dma-buf > exporters, allowing userland to allocate specific types of memory > for use in dma-buf sharing. > > Each heap is given its own device node, which a user can allocate > a dma-buf fd from using the DMA_HEAP_IOC_ALLOC. > > This code is an evoluiton of the Android ION implementation, > and a big thanks is due to its authors/maintainers over time > for their effort: > Rebecca Schultz Zavin, Colin Cross, Benjamin Gaignard, > Laura Abbott, and many other contributors! > > Cc: Laura Abbott > Cc: Benjamin Gaignard > Cc: Sumit Semwal > Cc: Liam Mark > Cc: Pratik Patel > Cc: Brian Starkey > Cc: Vincent Donnefort > Cc: Sudipto Paul > Cc: Andrew F. Davis > Cc: Christoph Hellwig > Cc: Chenbo Feng > Cc: Alistair Strachan > Cc: Hridya Valsaraju > Cc: Hillf Danton > Cc: dri-devel@lists.freedesktop.org > Reviewed-by: Benjamin Gaignard > Reviewed-by: Brian Starkey > Acked-by: Laura Abbott > Tested-by: Ayan Kumar Halder > Signed-off-by: Andrew F. Davis > Signed-off-by: John Stultz > --- > v2: > * Folded down fixes I had previously shared in implementing > heaps > * Make flags a u64 (Suggested by Laura) > * Add PAGE_ALIGN() fix to the core alloc funciton > * IOCTL fixups suggested by Brian > * Added fixes suggested by Benjamin > * Removed core stats mgmt, as that should be implemented by > per-heap code > * Changed alloc to return a dma-buf fd, rather than a buffer > (as it simplifies error handling) > v3: > * Removed scare-quotes in MAINTAINERS email address > * Get rid of .release function as it didn't do anything (from > Christoph) > * Renamed filp to file (suggested by Christoph) > * Split out ioctl handling to separate function (suggested by > Christoph) > * Add comment documenting PAGE_ALIGN usage (suggested by Brian) > * Switch from idr to Xarray (suggested by Brian) > * Fixup cdev creation (suggested by Brian) > * Avoid EXPORT_SYMBOL until we finalize modules (suggested by > Brian) > * Make struct dma_heap internal only (folded in from Andrew) > * Small cleanups suggested by GregKH > * Provide class->devnode callback to get consistent /dev/ > subdirectory naming (Suggested by Bjorn) > v4: > * Folded down dma-heap.h change that was in a following patch > * Added fd_flags entry to allocation structure and pass it > through to heap code for use on dma-buf fd creation (suggested > by Benjamin) > v5: > * Minor cleanups > v6: > * Improved error path handling, minor whitespace fixes, both > suggested by Brian > v7: > * Longer Kconfig description to quiet checkpatch warnings > * Re-add compat_ioctl bits (Hridya noticed 32bit userland wasn't > working) > v8: > * Make struct dma_heap_ops consts (Suggested by Christoph) > * Checkpatch whitespace fixups > v9: > * Minor cleanups suggested by Brian Starkey > * Rename dma_heap_get_data->dma_heap_get_drvdata suggested > by Hilf Danton > v11: > * Kconfig text improvements suggested by Randy Dunlap > v12: > * Add logic to prevent duplicately named heaps being added > * Add symbol exports for heaps as modules As in v3: * Avoid EXPORT_SYMBOL until we finalize modules (suggested by Brian) Did something change in that regard? I still think letting modules register heaps without a way to remove them is a recipe for issues. Thanks, -Brian ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RESEND][PATCH v8 0/5] DMA-BUF Heaps (destaging ION)
On Thu, Oct 17, 2019 at 01:57:45PM -0700, John Stultz wrote: > On Thu, Oct 17, 2019 at 12:29 PM Andrew F. Davis wrote: > > On 10/17/19 3:14 PM, John Stultz wrote: > > > But if the objection stands, do you have a proposal for an alternative > > > way to enumerate a subset of CMA heaps? > > > > > When in staging ION had to reach into the CMA framework as the other > > direction would not be allowed, so cma_for_each_area() was added. If > > DMA-BUF heaps is not in staging then we can do the opposite, and have > > the CMA framework register heaps itself using our framework. That way > > the CMA system could decide what areas to export or not (maybe based on > > a DT property or similar). > > Ok. Though the CMA core doesn't have much sense of DT details either, > so it would probably have to be done in the reserved_mem logic, which > doesn't feel right to me. > > I'd probably guess we should have some sort of dt binding to describe > a dmabuf cma heap and from that node link to a CMA node via a > memory-region phandle. Along with maybe the default heap as well? Not > eager to get into another binding review cycle, and I'm not sure what > non-DT systems will do yet, but I'll take a shot at it and iterate. > > > The end result is the same so we can make this change later (it has to > > come after DMA-BUF heaps is in anyway). > > Well, I'm hesitant to merge code that exposes all the CMA heaps and > then add patches that becomes more selective, should anyone depend on > the initial behavior. :/ How about only auto-adding the system default CMA region (cma->name == "reserved")? And/or the CMA auto-add could be behind a config option? It seems a shame to further delay this, and the CMA heap itself really is useful. Cheers, -Brian > > So, , I'll start on the rework for the CMA bits. > > That said, I'm definitely wanting to make some progress on this patch > series, so maybe we can still merge the core/helpers/system heap and > just hold the cma heap for a rework on the enumeration bits. That way > we can at least get other folks working on switching their vendor > heaps from ION. > > Sumit: Does that sound ok? Assuming no other objections, can you take > the v11 set minus the CMA heap patch? > > thanks > -john ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC,3/3] drm/komeda: Allow non-component drm_bridge only endpoints
On Fri, Oct 18, 2019 at 06:57:05AM +, james qian wang (Arm Technology China) wrote: > > Hi Brian: > > Can this convince you to fully swap to bridge ? Not until those patches materialise and land, no :-) > > Actually even there is no fix, we won't real encounter such rmmod problem, > since we always build the bridge/tda998 (by Y) into the image. > If you say so. I think the folks here like having drm as a module to make it easy to patch things without a reboot. -Brian > Thanks > James > > -- > > RMK's Patch system: https://www.armlinux.org.uk/developer/patches/ > > FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps > > up > > According to speedtest.net: 11.9Mbps down 500kbps up ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC,3/3] drm/komeda: Allow non-component drm_bridge only endpoints
On Thu, Oct 17, 2019 at 10:21:03AM +, james qian wang (Arm Technology China) wrote: > On Thu, Oct 17, 2019 at 08:20:56AM +0000, Brian Starkey wrote: > > On Thu, Oct 17, 2019 at 03:07:59AM +, james qian wang (Arm Technology > > China) wrote: > > > On Wed, Oct 16, 2019 at 04:22:07PM +, Brian Starkey wrote: > > > > > > > > If James is strongly against merging this, maybe we just swap > > > > wholesale to bridge? But for me, the pragmatic approach would be this > > > > stop-gap. > > > > > > > > > > This is a good idea, and I vote +ULONG_MAX :) > > > > > > and I also checked tda998x driver, it supports bridge. so swap the > > > wholesale to brige is perfect. :) > > > > > > > Well, as Mihail wrote, it's definitely not perfect. > > > > Today, if you rmmod tda998x with the DPU driver still loaded, > > everything will be unbound gracefully. > > > > If we swap to bridge, then rmmod'ing tda998x (or any other bridge > > driver the DPU is using) with the DPU driver still loaded will result > > in a crash. > > I haven't read the bridge code, but seems this is a bug of drm_bridge, > since if the bridge is still in using by others, the rmmod should fail > Correct, but there's no fix for that today. You can also take a look at the thread linked from Mihail's cover letter. > And personally opinion, if the bridge doesn't handle the dependence. > for us: > > - add such support to bridge That would certainly be helpful. I don't know if there's consensus on how to do that. > or > - just do the insmod/rmmod in correct order. > > > So, there really are proper benefits to sticking with the component > > code for tda998x, which is why I'd like to understand why you're so > > against this patch? > > > > This change handles two different connectors in komeda internally, compare > with one interface, it increases the complexity, more risk of bug and more > cost of maintainance. > Well, it's only about how to bind the drivers - two different methods of binding, not two different connectors. I would argue that carrying our out-of-tree patches to support both platforms is a larger maintenance burden. Honestly this looks like a win-win to me. We get the superior approach when its supported, and still get to support bridges which are more common. As/when improvements are made to the bridge code we can remove the component bits and not lose anything. > So my suggestion is keeping on one single interface in komeda, no > matter it is bridge or component, but I'd like it only one, but not > them both in komeda. If we can put the effort into fixing bridges then I guess that's the best approach for everyone :-) Might not be easy though! -Brian > > Thanks > James > > > Thanks, > > -Brian
Re: [RFC,3/3] drm/komeda: Allow non-component drm_bridge only endpoints
On Thu, Oct 17, 2019 at 03:07:59AM +, james qian wang (Arm Technology China) wrote: > On Wed, Oct 16, 2019 at 04:22:07PM +0000, Brian Starkey wrote: > > > > If James is strongly against merging this, maybe we just swap > > wholesale to bridge? But for me, the pragmatic approach would be this > > stop-gap. > > > > This is a good idea, and I vote +ULONG_MAX :) > > and I also checked tda998x driver, it supports bridge. so swap the > wholesale to brige is perfect. :) > Well, as Mihail wrote, it's definitely not perfect. Today, if you rmmod tda998x with the DPU driver still loaded, everything will be unbound gracefully. If we swap to bridge, then rmmod'ing tda998x (or any other bridge driver the DPU is using) with the DPU driver still loaded will result in a crash. So, there really are proper benefits to sticking with the component code for tda998x, which is why I'd like to understand why you're so against this patch? Thanks, -Brian
Re: [RFC,3/3] drm/komeda: Allow non-component drm_bridge only endpoints
Hi,
On Wed, Oct 16, 2019 at 03:51:39PM +, Mihail Atanassov wrote:
> Hi James,
>
> On Wednesday, 9 October 2019 06:54:15 BST james qian wang (Arm Technology
> China) wrote:
> > On Fri, Oct 04, 2019 at 02:34:42PM +, Mihail Atanassov wrote:
> > > To support transmitters other than the tda998x, we need to allow
> > > non-component framework bridges to be attached to a dummy drm_encoder in
> > > our driver.
> > >
> > > For the existing supported encoder (tda998x), keep the behaviour as-is,
> > > since there's no way to unbind if a drm_bridge module goes away under
> > > our feet.
> > >
> > > Signed-off-by: Mihail Atanassov
> > > ---
> > > .../gpu/drm/arm/display/komeda/komeda_dev.h | 5 +
> > > .../gpu/drm/arm/display/komeda/komeda_drv.c | 58 ++--
> > > .../gpu/drm/arm/display/komeda/komeda_kms.c | 133 +-
> > > .../gpu/drm/arm/display/komeda/komeda_kms.h | 5 +
> > > 4 files changed, 187 insertions(+), 14 deletions(-)
> > >
> > > [snip]
> > >
> > > +static void komeda_encoder_destroy(struct drm_encoder *encoder)
> > > +{
> > > + drm_encoder_cleanup(encoder);
> > > +}
> > > +
> > > +static const struct drm_encoder_funcs komeda_dummy_enc_funcs = {
> > > + .destroy = komeda_encoder_destroy,
> > > +};
> > > +
> > > +bool komeda_remote_device_is_component(struct device_node *local,
> > > +u32 port, u32 endpoint)
> > > +{
> > > + struct device_node *remote;
> > > + char const * const component_devices[] = {
> > > + "nxp,tda998x",
> >
> > I really don't think put this dummy_encoder into komeda is a good
> > idea.
> >
> > And I suggest to seperate this dummy_encoder to a individual module
> > which will build the drm_ridge to a standard drm encoder and component
> > based module, which will be enable by DT, totally transparent for komeda.
> >
> > BTW:
> > I really don't like such logic: distingush the SYSTEM configuration
> > by check the connected device name, it's hard to maintain and code
> > sharing, and that's why NOW we have the device-tree.
It's not ideal to have such special cases, for sure. However, I don't
see this approach causing us any issues. tda998x really is "special",
and as far as I can see the code here scales to other devices pretty
easily.
>
> +Cc Brian
>
> I didn't think DT is the right place for pseudo-devices.
I agree. DT should represent the HW, not the structure of the
linux kernel subsystem.
> The tda998x
> looks to be in a small group of drivers that contain encoder +
> bridge + connector; my impression of the current state of affairs is
> that the drm_encoder tends to live where the CRTC provider is rather
> than representing a HW entity (hence why drm_bridge based drivers
> exist in drivers/gpu/drm/bridge). See the overview DOC comment in
> drm_encoder.c ("drivers are free to use [drm_encoder] however they
> wish"). I may be completely wrong, so would appreciate some
> context and comment from others on the Cc list.
>
> In any case, converting a do-nothing dummy encoder into its own
> component-module will add a lot more bloat compared to the current
> ~10 SLoC implementation of the drm_encoder. probe/remove/bind/unbind,
> a few extra structs here and there, yet another object file, DT
> bindings, docs for the same, and maintaining all of that? It's a hard
> sell for me. I'd prefer if we went ahead with the code as-is and fix it
> up later if it really proves unwieldy and too hard to maintain. Could
> this patch be improved? Sure! Can we improve it in follow-up work
> though, as I think this is valuable enough on its own without any major
> drawbacks?
>
Even if we implemented a separate component encoder, as far as I can
tell there's no way to use it without either:
a) sticking it in DT
b) invoking it from komeda based on a "of_device_is_compatible" list
IMO a) isn't acceptable, and b) doesn't have any advantages over this
approach.
> As per my cover letter, in an ideal world we'd have the encoder locally
> and do drm_bridge_attach() even for tda998x, but the lifetime issues
> around bridges inside modules mean that doing that now is a bit of a
> step back for this specific case.
>
Yeah, my feeling is that being able to keep tda998x as a component
(for the superior bind/unbind behaviour) is worth the slight ugliness,
at least until bridges get the same functionality.
If James is strongly against merging this, maybe we just swap
wholesale to bridge? But for me, the pragmatic approach would be this
stop-gap.
Cheers,
-Brian
> >
> > Thanks
> > James
> >
> > > [snip]
> >
>
> --
> Mihail
>
>
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 4/7] drm/meson: plane: add support for AFBC mode for OSD1 plane
Hi Neil, On Fri, Oct 11, 2019 at 02:07:01PM +0200, Neil Armstrong wrote: > On 11/10/2019 12:56, Brian Starkey wrote: > > Hi, > > > > On Fri, Oct 11, 2019 at 11:14:43AM +0200, Neil Armstrong wrote: > >> Hi Brian, > >> > >> On 11/10/2019 10:41, Brian Starkey wrote: > >>> Hi Neil, > >>> > >>> On Thu, Oct 10, 2019 at 03:41:15PM +0200, Neil Armstrong wrote: [snip] > >> You'll have to tell us if the closed libMali handling AFBC would accept > >> ARGB as format to render with AFBC enabled, if not you're right > >> I'll discard XRGB/ARGB for AFBC buffers completely. > >> > >> But it the libMali chooses tt generate an ARGB buffer whatever > >> ARGB/XRGB/ABGR888/XBGR888 is asked, then no I'll keep it that way. > >> > > > > Yeah, I'll try and get clarity on this. It's not at all clear to me > > either. When you say "accept ARGB as format to render with AFBC > > enabled", which API are you referring to, just so I can be clear? Do > > you have an example of some code you're using to render AFBC with the > > GPU blob? > > Let's take kmscube using EGL and GBM. > > The buffer is allocated using gbm_surface_create_with_modifiers(), > but the gbm implementation is vendor specified. > > Then the surface is passed to eglCreateWindowSurface(). > Then the format is matched using eglGetConfigAttrib() with the > returned configs. > > Here support on the gbm and EGL implementation. > Is this a use-case that works on your platform today? I went and asked around. An Arm gbm implementation supporting AFBC will reject AFBC allocations for orders other than (DRM-convention) BGR. Thanks, -Brian ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4 2/4] drm/komeda: Add drm_lut_to_fgamma_coeffs()
Hi James,
On Tue, Oct 15, 2019 at 02:10:53AM +, james qian wang (Arm Technology
China) wrote:
> This function is used to convert drm 3dlut to komeda HW required 1d curve
This is a 1D LUT, not a 3D LUT
Cheers,
-Brian
> coeffs values.
>
> Signed-off-by: james qian wang (Arm Technology China)
>
> Reviewed-by: Mihail Atanassov
> ---
> .../arm/display/komeda/komeda_color_mgmt.c| 52 +++
> .../arm/display/komeda/komeda_color_mgmt.h| 9 +++-
> 2 files changed, 60 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_color_mgmt.c
> b/drivers/gpu/drm/arm/display/komeda/komeda_color_mgmt.c
> index 9d14a92dbb17..c180ce70c26c 100644
> --- a/drivers/gpu/drm/arm/display/komeda/komeda_color_mgmt.c
> +++ b/drivers/gpu/drm/arm/display/komeda/komeda_color_mgmt.c
> @@ -65,3 +65,55 @@ const s32 *komeda_select_yuv2rgb_coeffs(u32
> color_encoding, u32 color_range)
>
> return coeffs;
> }
> +
> +struct gamma_curve_sector {
> + u32 boundary_start;
> + u32 num_of_segments;
> + u32 segment_width;
> +};
> +
> +struct gamma_curve_segment {
> + u32 start;
> + u32 end;
> +};
> +
> +static struct gamma_curve_sector sector_tbl[] = {
> + { 0,4, 4 },
> + { 16, 4, 4 },
> + { 32, 4, 8 },
> + { 64, 4, 16 },
> + { 128, 4, 32 },
> + { 256, 4, 64 },
> + { 512, 16, 32 },
> + { 1024, 24, 128 },
> +};
> +
> +static void
> +drm_lut_to_coeffs(struct drm_property_blob *lut_blob, u32 *coeffs,
> + struct gamma_curve_sector *sector_tbl, u32 num_sectors)
> +{
> + struct drm_color_lut *lut;
> + u32 i, j, in, num = 0;
> +
> + if (!lut_blob)
> + return;
> +
> + lut = lut_blob->data;
> +
> + for (i = 0; i < num_sectors; i++) {
> + for (j = 0; j < sector_tbl[i].num_of_segments; j++) {
> + in = sector_tbl[i].boundary_start +
> + j * sector_tbl[i].segment_width;
> +
> + coeffs[num++] = drm_color_lut_extract(lut[in].red,
> + KOMEDA_COLOR_PRECISION);
> + }
> + }
> +
> + coeffs[num] = BIT(KOMEDA_COLOR_PRECISION);
> +}
> +
> +void drm_lut_to_fgamma_coeffs(struct drm_property_blob *lut_blob, u32
> *coeffs)
> +{
> + drm_lut_to_coeffs(lut_blob, coeffs, sector_tbl, ARRAY_SIZE(sector_tbl));
> +}
> diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_color_mgmt.h
> b/drivers/gpu/drm/arm/display/komeda/komeda_color_mgmt.h
> index a2df218f58e7..08ab69281648 100644
> --- a/drivers/gpu/drm/arm/display/komeda/komeda_color_mgmt.h
> +++ b/drivers/gpu/drm/arm/display/komeda/komeda_color_mgmt.h
> @@ -11,7 +11,14 @@
> #include
>
> #define KOMEDA_N_YUV2RGB_COEFFS 12
> +#define KOMEDA_N_RGB2YUV_COEFFS 12
> +#define KOMEDA_COLOR_PRECISION 12
> +#define KOMEDA_N_GAMMA_COEFFS65
> +#define KOMEDA_COLOR_LUT_SIZEBIT(KOMEDA_COLOR_PRECISION)
> +#define KOMEDA_N_CTM_COEFFS 9
> +
> +void drm_lut_to_fgamma_coeffs(struct drm_property_blob *lut_blob, u32
> *coeffs);
>
> const s32 *komeda_select_yuv2rgb_coeffs(u32 color_encoding, u32 color_range);
>
> -#endif
> +#endif /*_KOMEDA_COLOR_MGMT_H_*/
> --
> 2.20.1
>
Re: [PATCH 4/7] drm/meson: plane: add support for AFBC mode for OSD1 plane
On Fri, Oct 11, 2019 at 07:25:02PM +0200, Daniel Vetter wrote: > On Fri, Oct 11, 2019 at 12:56 PM Brian Starkey wrote: > > > > Hi, > > > > On Fri, Oct 11, 2019 at 11:14:43AM +0200, Neil Armstrong wrote: > > > Hi Brian, > > > > > > On 11/10/2019 10:41, Brian Starkey wrote: > > > > > Are you sure the GPU supports other orders? I think any Arm driver > > > > will only be producing DRM_FORMATs with "BGR" order e.g. ABGR888> > > > > I'm not convinced the GPU HW actually supports any other order, but > > > > it's all rather confusing with texture swizzling. What I can tell you > > > > for sure is that it _does_ support BGR order (in DRM naming > > > > convention). > > > > > > Well, since the Bifrost Mali blobs are closed-source and delivered > > > by licensees, it's hard to define what is supported from a closed > > > GPU HW, closed SW implementation to a closed pixel format implementation. > > > > > > > I hear you. IMO the only way to make any of this clear is to publish > > reference data and tests which make sure implementations match each > > other. It's something I'm trying to make happen. > > *cough* igt test with crc/writeback validation *cough* > > And you don't even need anything that actually compresses. All you > need is the minimal enough AFBC knowledge to set up the metadata that > everything is uncompressed. We're doing that for our intel compression > formats already, and it works great in making sure that we have > end-to-end agreement on all the bits and ordering and everything. Yeah this was my original thinking too. Sadly, a decent number of the AFBC parameters can't be tested with uncompressed data, as the codec kicks into a different mode there. > Ofc > it doesn't validate the decoder, but that's not really igts job. > Should be possible to convince ARM to release that (as open source, in > igt), since it would be fairly valuable for the entire ecosystem here > ... I fully agree about the value proposition. -Brian > -Daniel > > -- > Daniel Vetter > Software Engineer, Intel Corporation > +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RESEND][PATCH v8 0/5] DMA-BUF Heaps (destaging ION)
Hi Andrew, On Wed, Oct 09, 2019 at 02:27:15PM -0400, Andrew F. Davis wrote: > The CMA driver that registers these nodes will have to be expanded to > export them using this framework as needed. We do something similar to > export SRAM nodes: > > https://lkml.org/lkml/2019/3/21/575 > > Unlike the system/default-cma driver which can be centralized in the > tree, these extra exporters will probably live out in other subsystems > and so are added in later steps. > > Andrew I was under the impression that the "cma_for_each_area" loop in patch 4 would do that (add_cma_heaps). Is it not the case? Thanks, -Brian ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 4/7] drm/meson: plane: add support for AFBC mode for OSD1 plane
Hi,
On Fri, Oct 11, 2019 at 11:14:43AM +0200, Neil Armstrong wrote:
> Hi Brian,
>
> On 11/10/2019 10:41, Brian Starkey wrote:
> > Hi Neil,
> >
> > On Thu, Oct 10, 2019 at 03:41:15PM +0200, Neil Armstrong wrote:
> >> Hi Ayan,
> >>
> >> On 10/10/2019 15:26, Ayan Halder wrote:
> >>> On Thu, Oct 10, 2019 at 11:25:23AM +0200, Neil Armstrong wrote:
> >>>> This adds all the OSD configuration plumbing to support the AFBC decoders
> >>>> path to display of the OSD1 plane.
> >>>>
> >>>> The Amlogic GXM and G12A AFBC decoders are integrated very differently.
> >>>>
> >>>> The Amlogic GXM has a direct output path to the OSD1 VIU pixel input,
> >>>> because the GXM AFBC decoder seem to be a custom IP developed by Amlogic.
> >>>>
> >>>> On the other side, the Amlogic G12A AFBC decoder seems to be an external
> >>>> IP that emit pixels on an AXI master hooked to a "Mali Unpack" block
> >>>> feeding the OSD1 VIU pixel input.
> >>>> This uses a weird "0x100" internal HW physical address on both
> >>>> sides to transfer the pixels.
> >>>>
> >>>> For Amlogic GXM, the supported pixel formats are the same as the normal
> >>>> linear OSD1 mode.
> >>>>
> >>>> On the other side, Amlogic added support for all AFBC v1.2 formats for
> >>>> the G12A AFBC integration.
> >>>>
> >>>> For simplicity, we stick to the already supported formats for now.
> >>>>
> >>>> Signed-off-by: Neil Armstrong
> >>>> ---
> >>>> drivers/gpu/drm/meson/meson_crtc.c | 2 +
> >>>> drivers/gpu/drm/meson/meson_drv.h | 4 +
> >>>> drivers/gpu/drm/meson/meson_plane.c | 215
> >>>> 3 files changed, 190 insertions(+), 31 deletions(-)
> >>>>
> >>>> diff --git a/drivers/gpu/drm/meson/meson_crtc.c
> >>>> b/drivers/gpu/drm/meson/meson_crtc.c
> >>>> index 57ae1c13d1e6..d478fa232951 100644
> >>>> --- a/drivers/gpu/drm/meson/meson_crtc.c
> >>>> +++ b/drivers/gpu/drm/meson/meson_crtc.c
> >>>> @@ -281,6 +281,8 @@ void meson_crtc_irq(struct meson_drm *priv)
> >>>> if (priv->viu.osd1_enabled && priv->viu.osd1_commit) {
> >>>> writel_relaxed(priv->viu.osd1_ctrl_stat,
> >>>> priv->io_base +
> >>>> _REG(VIU_OSD1_CTRL_STAT));
> >>>> +writel_relaxed(priv->viu.osd1_ctrl_stat2,
> >>>> +priv->io_base +
> >>>> _REG(VIU_OSD1_CTRL_STAT2));
> >>>> writel_relaxed(priv->viu.osd1_blk0_cfg[0],
> >>>> priv->io_base +
> >>>> _REG(VIU_OSD1_BLK0_CFG_W0));
> >>>> writel_relaxed(priv->viu.osd1_blk0_cfg[1],
> >>>> diff --git a/drivers/gpu/drm/meson/meson_drv.h
> >>>> b/drivers/gpu/drm/meson/meson_drv.h
> >>>> index 60f13c6f34e5..de25349be8aa 100644
> >>>> --- a/drivers/gpu/drm/meson/meson_drv.h
> >>>> +++ b/drivers/gpu/drm/meson/meson_drv.h
> >>>> @@ -53,8 +53,12 @@ struct meson_drm {
> >>>> bool osd1_enabled;
> >>>> bool osd1_interlace;
> >>>> bool osd1_commit;
> >>>> +bool osd1_afbcd;
> >>>> uint32_t osd1_ctrl_stat;
> >>>> +uint32_t osd1_ctrl_stat2;
> >>>> uint32_t osd1_blk0_cfg[5];
> >>>> +uint32_t osd1_blk1_cfg4;
> >>>> +uint32_t osd1_blk2_cfg4;
> >>>> uint32_t osd1_addr;
> >>>> uint32_t osd1_stride;
> >>>> uint32_t osd1_height;
> >>>> diff --git a/drivers/gpu/drm/meson/meson_plane.c
> >>>> b/drivers/gpu/drm/meson/meson_plane.c
> >>>> index 5e798c276037..412941aa8402 100644
> >>>> --- a/drivers/gpu/drm/meson/meson_plane.c
> >>>> +++ b/drivers/gpu/drm/meson/meson_plane.c
> >>>> @@ -23,6 +23,7 @@
> >>>> #include "meson_plane.h"
> >>>> #include "meson_registers.
Re: [PATCH 4/7] drm/meson: plane: add support for AFBC mode for OSD1 plane
Hi Neil,
On Thu, Oct 10, 2019 at 03:41:15PM +0200, Neil Armstrong wrote:
> Hi Ayan,
>
> On 10/10/2019 15:26, Ayan Halder wrote:
> > On Thu, Oct 10, 2019 at 11:25:23AM +0200, Neil Armstrong wrote:
> >> This adds all the OSD configuration plumbing to support the AFBC decoders
> >> path to display of the OSD1 plane.
> >>
> >> The Amlogic GXM and G12A AFBC decoders are integrated very differently.
> >>
> >> The Amlogic GXM has a direct output path to the OSD1 VIU pixel input,
> >> because the GXM AFBC decoder seem to be a custom IP developed by Amlogic.
> >>
> >> On the other side, the Amlogic G12A AFBC decoder seems to be an external
> >> IP that emit pixels on an AXI master hooked to a "Mali Unpack" block
> >> feeding the OSD1 VIU pixel input.
> >> This uses a weird "0x100" internal HW physical address on both
> >> sides to transfer the pixels.
> >>
> >> For Amlogic GXM, the supported pixel formats are the same as the normal
> >> linear OSD1 mode.
> >>
> >> On the other side, Amlogic added support for all AFBC v1.2 formats for
> >> the G12A AFBC integration.
> >>
> >> For simplicity, we stick to the already supported formats for now.
> >>
> >> Signed-off-by: Neil Armstrong
> >> ---
> >> drivers/gpu/drm/meson/meson_crtc.c | 2 +
> >> drivers/gpu/drm/meson/meson_drv.h | 4 +
> >> drivers/gpu/drm/meson/meson_plane.c | 215
> >> 3 files changed, 190 insertions(+), 31 deletions(-)
> >>
> >> diff --git a/drivers/gpu/drm/meson/meson_crtc.c
> >> b/drivers/gpu/drm/meson/meson_crtc.c
> >> index 57ae1c13d1e6..d478fa232951 100644
> >> --- a/drivers/gpu/drm/meson/meson_crtc.c
> >> +++ b/drivers/gpu/drm/meson/meson_crtc.c
> >> @@ -281,6 +281,8 @@ void meson_crtc_irq(struct meson_drm *priv)
> >>if (priv->viu.osd1_enabled && priv->viu.osd1_commit) {
> >>writel_relaxed(priv->viu.osd1_ctrl_stat,
> >>priv->io_base + _REG(VIU_OSD1_CTRL_STAT));
> >> + writel_relaxed(priv->viu.osd1_ctrl_stat2,
> >> + priv->io_base + _REG(VIU_OSD1_CTRL_STAT2));
> >>writel_relaxed(priv->viu.osd1_blk0_cfg[0],
> >>priv->io_base + _REG(VIU_OSD1_BLK0_CFG_W0));
> >>writel_relaxed(priv->viu.osd1_blk0_cfg[1],
> >> diff --git a/drivers/gpu/drm/meson/meson_drv.h
> >> b/drivers/gpu/drm/meson/meson_drv.h
> >> index 60f13c6f34e5..de25349be8aa 100644
> >> --- a/drivers/gpu/drm/meson/meson_drv.h
> >> +++ b/drivers/gpu/drm/meson/meson_drv.h
> >> @@ -53,8 +53,12 @@ struct meson_drm {
> >>bool osd1_enabled;
> >>bool osd1_interlace;
> >>bool osd1_commit;
> >> + bool osd1_afbcd;
> >>uint32_t osd1_ctrl_stat;
> >> + uint32_t osd1_ctrl_stat2;
> >>uint32_t osd1_blk0_cfg[5];
> >> + uint32_t osd1_blk1_cfg4;
> >> + uint32_t osd1_blk2_cfg4;
> >>uint32_t osd1_addr;
> >>uint32_t osd1_stride;
> >>uint32_t osd1_height;
> >> diff --git a/drivers/gpu/drm/meson/meson_plane.c
> >> b/drivers/gpu/drm/meson/meson_plane.c
> >> index 5e798c276037..412941aa8402 100644
> >> --- a/drivers/gpu/drm/meson/meson_plane.c
> >> +++ b/drivers/gpu/drm/meson/meson_plane.c
> >> @@ -23,6 +23,7 @@
> >> #include "meson_plane.h"
> >> #include "meson_registers.h"
> >> #include "meson_viu.h"
> >> +#include "meson_osd_afbcd.h"
> >>
> >> /* OSD_SCI_WH_M1 */
> >> #define SCI_WH_M1_W(w)FIELD_PREP(GENMASK(28, 16), w)
> >> @@ -92,12 +93,38 @@ static int meson_plane_atomic_check(struct drm_plane
> >> *plane,
> >> false, true);
> >> }
> >>
> >> +#define MESON_MOD_AFBC_VALID_BITS (AFBC_FORMAT_MOD_BLOCK_SIZE_16x16 |
> >> \
> >> + AFBC_FORMAT_MOD_BLOCK_SIZE_32x8 |\
> >> + AFBC_FORMAT_MOD_YTR |\
> >> + AFBC_FORMAT_MOD_SPARSE | \
> >> + AFBC_FORMAT_MOD_SPLIT)
> >> +
> >> /* Takes a fixed 16.16 number and converts it to integer. */
> >> static inline int64_t fixed16_to_int(int64_t value)
> >> {
> >>return value >> 16;
> >> }
> >>
> >> +static u32 meson_g12a_afbcd_line_stride(struct meson_drm *priv)
> >> +{
> >> + u32 line_stride = 0;
> >> +
> >> + switch (priv->afbcd.format) {
> >> + case DRM_FORMAT_RGB565:
> >> + line_stride = ((priv->viu.osd1_width << 4) + 127) >> 7;
> >> + break;
> >> + case DRM_FORMAT_RGB888:
> >> + case DRM_FORMAT_XRGB:
> >> + case DRM_FORMAT_ARGB:
> >> + case DRM_FORMAT_XBGR:
> >> + case DRM_FORMAT_ABGR:
> > Please have a look at
> > https://www.kernel.org/doc/html/latest/gpu/afbc.html for our
> > recommendation. We suggest that *X* formats are avoided.
> >
> > Also, for interoperability and maximum compression efficiency (with
> > AFBC_FORMAT_MOD_YTR), we suggest the following order :-
> >
> > Component 0: R
>
Re: [PATCH] drm/komeda: Set output color depth for output
Hi Lowry,
On Tue, Oct 08, 2019 at 09:17:52AM +, Lowry Li (Arm Technology China) wrote:
> Set color_depth according to connector->bpc.
>
> Signed-off-by: Lowry Li (Arm Technology China)
> ---
> .../arm/display/komeda/d71/d71_component.c| 1 +
> .../gpu/drm/arm/display/komeda/komeda_crtc.c | 20 +++
> .../gpu/drm/arm/display/komeda/komeda_kms.h | 2 ++
> .../drm/arm/display/komeda/komeda_pipeline.h | 1 +
> .../display/komeda/komeda_pipeline_state.c| 19 ++
> .../arm/display/komeda/komeda_wb_connector.c | 4
> 6 files changed, 47 insertions(+)
>
> diff --git a/drivers/gpu/drm/arm/display/komeda/d71/d71_component.c
> b/drivers/gpu/drm/arm/display/komeda/d71/d71_component.c
> index c3d29c0b051b..27cdb03573c1 100644
> --- a/drivers/gpu/drm/arm/display/komeda/d71/d71_component.c
> +++ b/drivers/gpu/drm/arm/display/komeda/d71/d71_component.c
> @@ -951,6 +951,7 @@ static void d71_improc_update(struct komeda_component *c,
> to_d71_input_id(state, index));
>
> malidp_write32(reg, BLK_SIZE, HV_SIZE(st->hsize, st->vsize));
> + malidp_write32(reg, IPS_DEPTH, st->color_depth);
> }
>
> static void d71_improc_dump(struct komeda_component *c, struct seq_file *sf)
> diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_crtc.c
> b/drivers/gpu/drm/arm/display/komeda/komeda_crtc.c
> index 75263d8cd0bd..baa986b70876 100644
> --- a/drivers/gpu/drm/arm/display/komeda/komeda_crtc.c
> +++ b/drivers/gpu/drm/arm/display/komeda/komeda_crtc.c
> @@ -17,6 +17,26 @@
> #include "komeda_dev.h"
> #include "komeda_kms.h"
>
> +void komeda_crtc_get_color_config(struct drm_crtc_state *crtc_st,
> + u32 *color_depths)
> +{
> + struct drm_connector *conn;
> + struct drm_connector_state *conn_st;
> + int i, min_bpc = 31, conn_bpc = 0;
> +
> + for_each_new_connector_in_state(crtc_st->state, conn, conn_st, i) {
> + if (conn_st->crtc != crtc_st->crtc)
> + continue;
> +
> + conn_bpc = conn->display_info.bpc ? conn->display_info.bpc : 8;
We can have multiple connectors on a single CRTC (e.g. normal +
writeback), so what's the expected behaviour here in that case?
> +
> + if (conn_bpc < min_bpc)
> + min_bpc = conn_bpc;
> + }
> +
> + *color_depths = GENMASK(conn_bpc, 0);
> +}
> +
> static void komeda_crtc_update_clock_ratio(struct komeda_crtc_state
> *kcrtc_st)
> {
> u64 pxlclk, aclk;
> diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_kms.h
> b/drivers/gpu/drm/arm/display/komeda/komeda_kms.h
> index 45c498e15e7a..a42503451b5d 100644
> --- a/drivers/gpu/drm/arm/display/komeda/komeda_kms.h
> +++ b/drivers/gpu/drm/arm/display/komeda/komeda_kms.h
> @@ -166,6 +166,8 @@ static inline bool has_flip_h(u32 rot)
> return !!(rotation & DRM_MODE_REFLECT_X);
> }
>
> +void komeda_crtc_get_color_config(struct drm_crtc_state *crtc_st,
> + u32 *color_depths);
> unsigned long komeda_crtc_get_aclk(struct komeda_crtc_state *kcrtc_st);
>
> int komeda_kms_setup_crtcs(struct komeda_kms_dev *kms, struct komeda_dev
> *mdev);
> diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_pipeline.h
> b/drivers/gpu/drm/arm/display/komeda/komeda_pipeline.h
> index b322f52ba8f2..7653f134a8eb 100644
> --- a/drivers/gpu/drm/arm/display/komeda/komeda_pipeline.h
> +++ b/drivers/gpu/drm/arm/display/komeda/komeda_pipeline.h
> @@ -323,6 +323,7 @@ struct komeda_improc {
>
> struct komeda_improc_state {
> struct komeda_component_state base;
> + u8 color_depth;
> u16 hsize, vsize;
> };
>
> diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_pipeline_state.c
> b/drivers/gpu/drm/arm/display/komeda/komeda_pipeline_state.c
> index 0ba9c6aa3708..e68e8f85ab27 100644
> --- a/drivers/gpu/drm/arm/display/komeda/komeda_pipeline_state.c
> +++ b/drivers/gpu/drm/arm/display/komeda/komeda_pipeline_state.c
> @@ -743,6 +743,7 @@ komeda_improc_validate(struct komeda_improc *improc,
> struct komeda_data_flow_cfg *dflow)
> {
> struct drm_crtc *crtc = kcrtc_st->base.crtc;
> + struct drm_crtc_state *crtc_st = _st->base;
> struct komeda_component_state *c_st;
> struct komeda_improc_state *st;
>
> @@ -756,6 +757,24 @@ komeda_improc_validate(struct komeda_improc *improc,
> st->hsize = dflow->in_w;
> st->vsize = dflow->in_h;
>
> + if (drm_atomic_crtc_needs_modeset(crtc_st)) {
> + u32 output_depths;
> + u32 avail_depths;
> +
> + komeda_crtc_get_color_config(crtc_st,
> + _depths);
> +
> + avail_depths = output_depths & improc->supported_color_depths;
> + if (avail_depths == 0) {
> + DRM_DEBUG_ATOMIC("No available color depths, conn
> depths: 0x%x & display: 0x%x\n",
> +
Re: [PATCH v9 0/5] DMA-BUF Heaps (destaging ION)
Hi John, On Wed, Oct 02, 2019 at 06:22:50PM +, John Stultz wrote: > Here is yet another pass at the dma-buf heaps patchset Andrew > and I have been working on which tries to destage a fair chunk > of ION functionality. > > The patchset implements per-heap devices which can be opened > directly and then an ioctl is used to allocate a dmabuf from the > heap. > > The interface is similar, but much simpler then IONs, only > providing an ALLOC ioctl. > > Also, I've provided relatively simple system and cma heaps. > > I've booted and tested these patches with AOSP on the HiKey960 > using the kernel tree here: > > https://git.linaro.org/people/john.stultz/android-dev.git/log/?h=dev/dma-buf-heap > > And the userspace changes here: > https://android-review.googlesource.com/c/device/linaro/hikey/+/909436 > > Compared to ION, this patchset is missing the system-contig, > carveout and chunk heaps, as I don't have a device that uses > those, so I'm unable to do much useful validation there. > Additionally we have no upstream users of chunk or carveout, > and the system-contig has been deprecated in the common/andoid-* > kernels, so this should be ok. > > I've also removed the stats accounting, since any such accounting > should be implemented by dma-buf core or the heaps themselves. > > New in v9: > * Removing needless check in cma heap (noted by Brian Starkey) > * Rename dma_heap_get_data->dma_heap_get_drvdata (suggested by > Hilf Danton) > * Check signals after clearing memory pages to avoid doing > needless work if the task is killed (suggested by Hilf) > * Better test error reporting (suggested d by Brian) > * Other minor cleanups (suggested by Brian) > > Thoughts and feedback would be greatly appreciated! Looks good to me! Please feel free to add my r-b to the remaining patches. Thanks again for moving this forwards. -Brian > > thanks > -john > > Cc: Laura Abbott > Cc: Benjamin Gaignard > Cc: Sumit Semwal > Cc: Liam Mark > Cc: Pratik Patel > Cc: Brian Starkey > Cc: Vincent Donnefort > Cc: Sudipto Paul > Cc: Andrew F. Davis > Cc: Christoph Hellwig > Cc: Chenbo Feng > Cc: Alistair Strachan > Cc: Hridya Valsaraju > Cc: Hillf Danton > Cc: dri-devel@lists.freedesktop.org > > Andrew F. Davis (1): > dma-buf: Add dma-buf heaps framework > > John Stultz (4): > dma-buf: heaps: Add heap helpers > dma-buf: heaps: Add system heap to dmabuf heaps > dma-buf: heaps: Add CMA heap to dmabuf heaps > kselftests: Add dma-heap test > > MAINTAINERS | 18 ++ > drivers/dma-buf/Kconfig | 11 + > drivers/dma-buf/Makefile | 2 + > drivers/dma-buf/dma-heap.c| 250 > drivers/dma-buf/heaps/Kconfig | 14 + > drivers/dma-buf/heaps/Makefile| 4 + > drivers/dma-buf/heaps/cma_heap.c | 169 +++ > drivers/dma-buf/heaps/heap-helpers.c | 266 ++ > drivers/dma-buf/heaps/heap-helpers.h | 55 > drivers/dma-buf/heaps/system_heap.c | 122 > include/linux/dma-heap.h | 59 > include/uapi/linux/dma-heap.h | 55 > tools/testing/selftests/dmabuf-heaps/Makefile | 9 + > .../selftests/dmabuf-heaps/dmabuf-heap.c | 238 > 14 files changed, 1272 insertions(+) > create mode 100644 drivers/dma-buf/dma-heap.c > create mode 100644 drivers/dma-buf/heaps/Kconfig > create mode 100644 drivers/dma-buf/heaps/Makefile > create mode 100644 drivers/dma-buf/heaps/cma_heap.c > create mode 100644 drivers/dma-buf/heaps/heap-helpers.c > create mode 100644 drivers/dma-buf/heaps/heap-helpers.h > create mode 100644 drivers/dma-buf/heaps/system_heap.c > create mode 100644 include/linux/dma-heap.h > create mode 100644 include/uapi/linux/dma-heap.h > create mode 100644 tools/testing/selftests/dmabuf-heaps/Makefile > create mode 100644 tools/testing/selftests/dmabuf-heaps/dmabuf-heap.c > > -- > 2.17.1 > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2] drm/fourcc: Add Arm 16x16 block modifier
Hi Ayan,
Could we preserve Ray's authorship on this patch?
On Mon, Sep 30, 2019 at 04:44:38PM +, Ayan Halder wrote:
> Add the DRM_FORMAT_MOD_ARM_16X16_BLOCK_U_INTERLEAVED modifier to
> denote the 16x16 block u-interleaved format used in Arm Utgard and
> Midgard GPUs.
>
> Changes from v1:-
> 1. Reserved the upper four bits (out of the 56 bits assigned to each vendor)
> to denote the category of Arm specific modifiers. Currently, we have two
> categories ie AFBC and MISC.
>
> Signed-off-by: Raymond Smith
> Signed-off-by: Ayan kumar halder
> ---
> include/uapi/drm/drm_fourcc.h | 27 ++-
> 1 file changed, 26 insertions(+), 1 deletion(-)
>
> diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
> index 3feeaa3f987a..b1d3de961109 100644
> --- a/include/uapi/drm/drm_fourcc.h
> +++ b/include/uapi/drm/drm_fourcc.h
> @@ -648,7 +648,21 @@ extern "C" {
> * Further information on the use of AFBC modifiers can be found in
> * Documentation/gpu/afbc.rst
> */
> -#define DRM_FORMAT_MOD_ARM_AFBC(__afbc_mode) fourcc_mod_code(ARM,
> __afbc_mode)
> +
> +/*
> + * The top 4 bits (out of the 56 bits alloted for specifying vendor specific
> + * modifiers) denote the category for modifiers. Currently we have only two
> + * categories of modifiers ie AFBC and MISC. We can have a maximum of sixteen
> + * different categories.
> + */
Yeah, this makes more sense than getting crazy with saving bits. Sorry
Qiang/Daniel for not just going with this in the first instance when
you both suggested it.
> +#define DRM_FORMAT_MOD_ARM_CODE(type, val) \
> + fourcc_mod_code(ARM, ((__u64)type << 52) | ((val) &
> 0x000fULL))
Not a big deal, but I might prefix type and val with "__" to reduce
the chance of name collisions with code using the macro:
DRM_FORMAT_MOD_ARM_CODE(__type, __val).
> +
> +#define DRM_FORMAT_MOD_ARM_TYPE_AFBC 0x00
> +#define DRM_FORMAT_MOD_ARM_TYPE_MISC 0x01
> +
> +#define DRM_FORMAT_MOD_ARM_AFBC(__afbc_mode) \
> + DRM_FORMAT_MOD_ARM_CODE(DRM_FORMAT_MOD_ARM_TYPE_AFBC, __afbc_mode)
>
> /*
> * AFBC superblock size
> @@ -742,6 +756,17 @@ extern "C" {
> */
> #define AFBC_FORMAT_MOD_BCH (1ULL << 11)
>
> +/*
> + * Arm 16x16 Block U-Interleaved modifier
> + *
> + * This is used by Arm Mali Utgard and Midgard GPUs. It divides the image
> + * into 16x16 pixel blocks. Blocks are stored linearly in order, but pixels
> + * in the block are reordered.
> + */
> +#define DRM_FORMAT_MOD_ARM_16X16_BLOCK_U_INTERLEAVED \
> + DRM_FORMAT_MOD_ARM_CODE(DRM_FORMAT_MOD_ARM_TYPE_MISC, 1ULL)
> +
> +
I think you can drop this newline, there's no extra space between any
of the other definitions.
With this line dropped, and if you fix up the author:
Reviewed-by: Brian Starkey
Thanks for the respin,
-Brian
> /*
> * Allwinner tiled modifier
> *
> --
> 2.23.0
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/3] drm/komeda: Add drm_ctm_to_coeffs()
Hi James,
On Mon, Sep 30, 2019 at 04:54:41AM +, james qian wang (Arm Technology
China) wrote:
> This function is used to convert drm_color_ctm S31.32 sign-magnitude
> value to komeda required Q2.12 2's complement
>
> Signed-off-by: james qian wang (Arm Technology China)
>
> ---
> .../arm/display/komeda/komeda_color_mgmt.c| 27 +++
> .../arm/display/komeda/komeda_color_mgmt.h| 1 +
> 2 files changed, 28 insertions(+)
>
> diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_color_mgmt.c
> b/drivers/gpu/drm/arm/display/komeda/komeda_color_mgmt.c
> index c180ce70c26c..c92c82eebddb 100644
> --- a/drivers/gpu/drm/arm/display/komeda/komeda_color_mgmt.c
> +++ b/drivers/gpu/drm/arm/display/komeda/komeda_color_mgmt.c
> @@ -117,3 +117,30 @@ void drm_lut_to_fgamma_coeffs(struct drm_property_blob
> *lut_blob, u32 *coeffs)
> {
> drm_lut_to_coeffs(lut_blob, coeffs, sector_tbl, ARRAY_SIZE(sector_tbl));
> }
> +
> +/* Convert from S31.32 sign-magnitude to HW Q2.12 2's complement */
> +static s32 drm_ctm_s31_32_to_q2_12(u64 input)
> +{
> + u64 mag = (input & ~BIT_ULL(63)) >> 20;
> + bool negative = !!(input & BIT_ULL(63));
> + u32 val;
> +
> + /* the range of signed 2s complement is [-2^n, 2^n - 1] */
> + val = clamp_val(mag, 0, negative ? BIT(14) : BIT(14) - 1);
> +
> + return negative ? 0 - val : val;
> +}
This function looks generally useful. Should it be in DRM core
(assuming there isn't already one there)?
You can use a parameter to determine the number of bits desired in the
output.
Thanks,
-Brian
> +
> +void drm_ctm_to_coeffs(struct drm_property_blob *ctm_blob, u32 *coeffs)
> +{
> + struct drm_color_ctm *ctm;
> + u32 i;
> +
> + if (!ctm_blob)
> + return;
> +
> + ctm = ctm_blob->data;
> +
> + for (i = 0; i < KOMEDA_N_CTM_COEFFS; i++)
> + coeffs[i] = drm_ctm_s31_32_to_q2_12(ctm->matrix[i]);
> +}
> diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_color_mgmt.h
> b/drivers/gpu/drm/arm/display/komeda/komeda_color_mgmt.h
> index 08ab69281648..2f4668466112 100644
> --- a/drivers/gpu/drm/arm/display/komeda/komeda_color_mgmt.h
> +++ b/drivers/gpu/drm/arm/display/komeda/komeda_color_mgmt.h
> @@ -18,6 +18,7 @@
> #define KOMEDA_N_CTM_COEFFS 9
>
> void drm_lut_to_fgamma_coeffs(struct drm_property_blob *lut_blob, u32
> *coeffs);
> +void drm_ctm_to_coeffs(struct drm_property_blob *ctm_blob, u32 *coeffs);
>
> const s32 *komeda_select_yuv2rgb_coeffs(u32 color_encoding, u32 color_range);
>
> --
> 2.20.1
>
Re: [PATCH] drm/komeda: Adds output-color format/depth support
On Fri, Sep 27, 2019 at 02:22:24AM +, james qian wang (Arm Technology China) wrote: > On Wed, Sep 25, 2019 at 09:48:11AM +0000, Brian Starkey wrote: > > Hi James, > > > > On Tue, Sep 24, 2019 at 02:13:27AM +, james qian wang (Arm Technology > > China) wrote: > > > > > > Hi Brian: > > > > > > Since one monitor can support mutiple color-formats, this DT property > > > supply a way for user to select a specific one from this supported > > > color-formats. > > > > Modifying DT is a _really_ user-unfriendly way of specifying > > preferences. If we want a user to be able to pick a preferred format, > > then it should probably be via the atomic API as Ville mentioned. > > > > Hi Brian: > > Agree, a drm UPAI might be the best & right way for this. > > I can raise a new thread/topic to discuss the "HOW TO", maybe after the > Chinese national day. > > LAST: > what do you think about this patch: > - Just drop it, waiting for the new uapi > - or keep it, and replace it once new uapi is ready. The bit-depth stuff is clear and non-controversial, so you could split that out and merge it. For the YUV stuff, I think it would be fine to merge the implementation that we discussed here - force YUV for modes which must be YUV, and leave the user-preference stuff for a later UAPI. Thanks, -Brian > > Thanks > James > > > Cheers, > > -Brian ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC PATCH] drm:- Add a modifier to denote 'protected' framebuffer
Hi, On Tue, Sep 17, 2019 at 07:36:45PM +0200, Daniel Vetter wrote: > On Tue, Sep 17, 2019 at 6:15 PM Neil Armstrong > wrote: > > > > Hi, > > > > On 17/09/2019 18:07, Liviu Dudau wrote: > > > On Tue, Sep 17, 2019 at 02:53:01PM +0200, Daniel Vetter wrote: > > >> On Mon, Sep 09, 2019 at 01:42:53PM +, Ayan Halder wrote: > > >>> Add a modifier 'DRM_FORMAT_MOD_ARM_PROTECTED' which denotes that the > > >>> framebuffer > > >>> is allocated in a protected system memory. > > >>> Essentially, we want to support EGL_EXT_protected_content in our komeda > > >>> driver. > > >>> > > >>> Signed-off-by: Ayan Kumar Halder > > >>> > > >>> /-- Note to reviewer > > >>> Komeda driver is capable of rendering DRM (Digital Rights Management) > > >>> protected > > >>> content. The DRM content is stored in a framebuffer allocated in system > > >>> memory > > >>> (which needs some special hardware signals for access). > > >>> > > >>> Let us ignore how the protected system memory is allocated and for the > > >>> scope of > > >>> this discussion, we want to figure out the best way possible for the > > >>> userspace > > >>> to communicate to the drm driver to turn the protected mode on (for > > >>> accessing the > > >>> framebuffer with the DRM content) or off. > > >>> > > >>> The possible ways by which the userspace could achieve this is via:- > > >>> > > >>> 1. Modifiers :- This looks to me the best way by which the userspace can > > >>> communicate to the kernel to turn the protected mode on for the komeda > > >>> driver > > >>> as it is going to access one of the protected framebuffers. The only > > >>> problem is > > >>> that the current modifiers describe the tiling/compression format. > > >>> However, it > > >>> does not hurt to extend the meaning of modifiers to denote other > > >>> attributes of > > >>> the framebuffer as well. > > >>> > > >>> The other reason is that on Android, we get an info from Gralloc > > >>> (GRALLOC_USAGE_PROTECTED) which tells us that the buffer is protected. > > >>> This can > > >>> be used to set up the modifier/s (AddFB2) during framebuffer creation. > > >> > > >> How does this mesh with other modifiers, like AFBC? That's where I see > > >> the > > >> issue here. > > > > > > AFBC modifiers are currently under Arm's namespace, the thought behind > > > the DRM > > > modifiers would be to have it as a "generic" modifier. > > But if it's a generic flag, how do you combine that with other > modifiers? Like if you have a tiled buffer, but also encrypted? Or > afbc compressed, or whatever else. I'd expect for your hw encryption > is orthogonal to the buffer/tiling/compression format used? This bit doesn't overlap with any of the other AFBC modifiers, so as you say it'd be orthogonal, and could be set on AFBC buffers (if we went that route). > > > >>> 2. Framebuffer flags :- As of today, this can be one of the two values > > >>> ie (DRM_MODE_FB_INTERLACED/DRM_MODE_FB_MODIFIERS). Unlike modifiers, > > >>> the drm > > >>> framebuffer flags are generic to the drm subsystem and ideally we > > >>> should not > > >>> introduce any driver specific constraint/feature. > > >>> > > >>> 3. Connector property:- I could see the following properties used for > > >>> DRM > > >>> protected content:- > > >>> DRM_MODE_CONTENT_PROTECTION_DESIRED / ENABLED :- "This property is used > > >>> by > > >>> userspace to request the kernel protect future content communicated over > > >>> the link". Clearly, we are not concerned with the protection attributes > > >>> of the > > >>> transmitter. So, we cannot use this property for our case. > > >>> > > >>> 4. DRM plane property:- Again, we want to communicate that the > > >>> framebuffer(which > > >>> can be attached to any plane) is protected. So introducing a new plane > > >>> property > > >>> does not help. > > >>> > > >>> 5. DRM crtc property:- For the same reason as above, introducing a new > > >>> crtc > > >>> property does not help. > > >> > > >> 6. Just track this as part of buffer allocation, i.e. I think it does > > >> matter how you allocate these protected buffers. We could add a "is > > >> protected buffer" flag at the dma_buf level for this. I also like this approach. The protected-ness is a property of the allocation, so makes sense to store it with the allocation IMO. > > >> > > >> So yeah for this stuff here I think we do want the full userspace side, > > >> from allocator to rendering something into this protected buffers (no > > >> need > > >> to also have the entire "decode a protected bitstream part" imo, since > > >> that will freak people out). Unfortunately, in my experience, that kills > > >> it for upstream :-/ But also in my experience of looking into this for > > >> other gpu's, we really need to have the full picture here to make sure > > >> we're not screwing this up. > > > > > > Maybe Ayan could've been a bit clearer in his message, but the ask here > > > is for ideas > > > on how userspace "communicates" (stores?) the
Re: [RESEND][PATCH v8 5/5] kselftests: Add dma-heap test
Hi John, On Thu, Sep 26, 2019 at 02:36:33PM -0700, John Stultz wrote: > On Mon, Sep 23, 2019 at 3:12 PM Brian Starkey wrote: > > > > I didn't see any response about using the test harness. Did you decide > > against it? > > Hey! Spent a little time looking at this bit and just wanted to reply > to this point. So first, apologies, I think I missed the suggestion > earlier. That said, now that I've looked a little bit at the test > harness, and at least at this point it feels like it makes it harder > to reason with than standard c code. Maybe I need to spend a bit more > time on it, but I'm a little hesitant to swap over just yet. > > I'm not particularly passionate on this point, but are you? Or was > this just a recommendation to check it out and consider it? No particular strong feelings. I was just poking around the kernel docs for testing and the only info there is about the test harness, so wanted to check if you'd seen/considered it. A quick grep of tools/testing shows that it's obviously not that popular... so if you don't fancy it I won't complain. Thanks, -Brian > > thanks > -john ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/komeda: Adds output-color format/depth support
Hi James, On Tue, Sep 24, 2019 at 02:13:27AM +, james qian wang (Arm Technology China) wrote: > > Hi Brian: > > Since one monitor can support mutiple color-formats, this DT property > supply a way for user to select a specific one from this supported > color-formats. Modifying DT is a _really_ user-unfriendly way of specifying preferences. If we want a user to be able to pick a preferred format, then it should probably be via the atomic API as Ville mentioned. Cheers, -Brian ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/rockchip: Add AFBC support
Hi Andrzej,
Thanks for the patch, it's nice to see another AFBC implementation
coming in.
For future versions, could you please Cc ayan.hal...@arm.com? It would
have been nice to have someone @arm.com on patches which use/impact
Arm modifiers. Sadly I don't know how to make get_maintainer.pl help
with that.
Some more comments below.
On Mon, Sep 23, 2019 at 02:20:13PM +0200, Andrzej Pietrasiewicz wrote:
> From: Ezequiel Garcia
>
> AFBC is a proprietary lossless image compression protocol and format.
> It helps reduce memory bandwidth of the graphics pipeline operations.
> This, in turn, improves power efficiency.
>
> Signed-off-by: Ezequiel Garcia
> [locking improvements]
> Signed-off-by: Tomeu Vizoso
> [squashing the above, commit message and Rockchip AFBC modifier]
> Signed-off-by: Andrzej Pietrasiewicz
> ---
> drivers/gpu/drm/rockchip/rockchip_drm_fb.c | 27 ++
> drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 94 -
> drivers/gpu/drm/rockchip/rockchip_drm_vop.h | 12 +++
> drivers/gpu/drm/rockchip/rockchip_vop_reg.c | 18
> include/uapi/drm/drm_fourcc.h | 3 +
> 5 files changed, 151 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_fb.c
> b/drivers/gpu/drm/rockchip/rockchip_drm_fb.c
> index 64ca87cf6d50..5178939a9c29 100644
> --- a/drivers/gpu/drm/rockchip/rockchip_drm_fb.c
> +++ b/drivers/gpu/drm/rockchip/rockchip_drm_fb.c
> @@ -24,6 +24,27 @@ static const struct drm_framebuffer_funcs
> rockchip_drm_fb_funcs = {
> .dirty = drm_atomic_helper_dirtyfb,
> };
>
> +static int
> +rockchip_verify_afbc_mod(struct drm_device *dev,
> + const struct drm_mode_fb_cmd2 *mode_cmd)
> +{
> + if (mode_cmd->modifier[0] &
> + ~DRM_FORMAT_MOD_ARM_AFBC(AFBC_FORMAT_MOD_ROCKCHIP)) {
> + DRM_DEV_ERROR(dev->dev,
> + "Unsupported format modifier 0x%llx\n",
> + mode_cmd->modifier[0]);
> + return -EINVAL;
> + }
> +
> + if (mode_cmd->width > 2560) {
> + DRM_DEV_ERROR(dev->dev,
> + "Unsupported width %d\n", mode_cmd->width);
> + return -EINVAL;
> + }
> +
> + return 0;
> +}
> +
> static struct drm_framebuffer *
> rockchip_fb_alloc(struct drm_device *dev, const struct drm_mode_fb_cmd2
> *mode_cmd,
> struct drm_gem_object **obj, unsigned int num_planes)
> @@ -32,6 +53,12 @@ rockchip_fb_alloc(struct drm_device *dev, const struct
> drm_mode_fb_cmd2 *mode_cm
> int ret;
> int i;
>
> + if (mode_cmd->modifier[0]) {
> + ret = rockchip_verify_afbc_mod(dev, mode_cmd);
> + if (ret)
> + return ERR_PTR(ret);
> + }
> +
> fb = kzalloc(sizeof(*fb), GFP_KERNEL);
> if (!fb)
> return ERR_PTR(-ENOMEM);
> diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
> b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
> index 21b68eea46cc..50bf214d21da 100644
> --- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
> +++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
> @@ -46,6 +46,13 @@
> vop_reg_set(vop, >phy->scl->ext->name, \
> win->base, ~0, v, #name)
>
> +#define VOP_AFBC_SET(x, name, v) \
> + do { \
> + if (vop->data->afbc) \
> + vop_reg_set(vop, >data->afbc->name, \
> + 0, ~0, v, #name); \
> + } while (0)
> +
> #define VOP_WIN_YUV2YUV_SET(vop, win_yuv2yuv, name, v) \
> do { \
> if (win_yuv2yuv && win_yuv2yuv->name.mask) \
> @@ -123,6 +130,8 @@ struct vop {
> struct drm_device *drm_dev;
> bool is_enabled;
>
> + struct vop_win *afbc_win;
> +
> struct completion dsp_hold_completion;
>
> /* protected by dev->event_lock */
> @@ -245,6 +254,30 @@ static bool has_rb_swapped(uint32_t format)
> }
> }
>
> +#define AFBC_FMT_RGB5650x0
> +#define AFBC_FMT_U8U8U8U8 0x5
> +#define AFBC_FMT_U8U8U80x4
> +
> +static int vop_convert_afbc_format(uint32_t format)
> +{
It would be great if you are able to follow the guidance Arm published
here: https://www.kernel.org/doc/html/latest/gpu/afbc.html, which will
help ensure interoperability and compatibility between different
devices/drivers. Hopefully it doesn't limit some use-cases for you -
if it does, let's discuss them.
Specifically, please take a look at the format list there. Some of
your formats below are not on the preferred interop list:
> + switch (format) {
> + case DRM_FORMAT_XRGB:
XRGB: Not preferred, as encoding the X channel is a waste of bits
> + case DRM_FORMAT_ARGB:
ARGB: Not preferred as the channel order prevents YTR
> + case DRM_FORMAT_XBGR:
XBGR: Not preferred, as encoding the X channel is a waste of bits
> + case DRM_FORMAT_ABGR:
> + return AFBC_FMT_U8U8U8U8;
> +
Re: [RESEND][PATCH v8 5/5] kselftests: Add dma-heap test
Hi John,
I didn't see any response about using the test harness. Did you decide
against it?
On Fri, Sep 06, 2019 at 06:47:12PM +, John Stultz wrote:
> Add very trivial allocation and import test for dma-heaps,
> utilizing the vgem driver as a test importer.
>
> A good chunk of this code taken from:
> tools/testing/selftests/android/ion/ionmap_test.c
> Originally by Laura Abbott
>
> Cc: Benjamin Gaignard
> Cc: Sumit Semwal
> Cc: Liam Mark
> Cc: Pratik Patel
> Cc: Brian Starkey
> Cc: Vincent Donnefort
> Cc: Sudipto Paul
> Cc: Andrew F. Davis
> Cc: Christoph Hellwig
> Cc: Chenbo Feng
> Cc: Alistair Strachan
> Cc: Hridya Valsaraju
> Cc: dri-devel@lists.freedesktop.org
> Reviewed-by: Benjamin Gaignard
> Signed-off-by: John Stultz
> ---
> v2:
> * Switched to use reworked dma-heap apis
> v3:
> * Add simple mmap
> * Utilize dma-buf testdev to test importing
> v4:
> * Rework to use vgem
> * Pass in fd_flags to match interface changes
> * Skip . and .. dirs
> v6:
> * Number of style/cleanups suggested by Brian
> v7:
> * Whitespace fixup for checkpatch
> v8:
> * More checkpatch whitespace fixups
> ---
> tools/testing/selftests/dmabuf-heaps/Makefile | 9 +
> .../selftests/dmabuf-heaps/dmabuf-heap.c | 230 ++
> 2 files changed, 239 insertions(+)
> create mode 100644 tools/testing/selftests/dmabuf-heaps/Makefile
> create mode 100644 tools/testing/selftests/dmabuf-heaps/dmabuf-heap.c
>
> diff --git a/tools/testing/selftests/dmabuf-heaps/Makefile
> b/tools/testing/selftests/dmabuf-heaps/Makefile
> new file mode 100644
> index ..8c4c36e2972d
> --- /dev/null
> +++ b/tools/testing/selftests/dmabuf-heaps/Makefile
> @@ -0,0 +1,9 @@
> +# SPDX-License-Identifier: GPL-2.0
> +CFLAGS += -static -O3 -Wl,-no-as-needed -Wall
> +#LDLIBS += -lrt -lpthread -lm
> +
> +# these are all "safe" tests that don't modify
> +# system time or require escalated privileges
> +TEST_GEN_PROGS = dmabuf-heap
> +
> +include ../lib.mk
> diff --git a/tools/testing/selftests/dmabuf-heaps/dmabuf-heap.c
> b/tools/testing/selftests/dmabuf-heaps/dmabuf-heap.c
> new file mode 100644
> index ..e439d6cf3d81
> --- /dev/null
> +++ b/tools/testing/selftests/dmabuf-heaps/dmabuf-heap.c
> @@ -0,0 +1,230 @@
> +// SPDX-License-Identifier: GPL-2.0
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#include
> +#include
> +
> +#include "../../../../include/uapi/linux/dma-heap.h"
> +
> +#define DEVPATH "/dev/dma_heap"
> +
> +static int check_vgem(int fd)
> +{
> + drm_version_t version = { 0 };
> + char name[5];
> + int ret;
> +
> + version.name_len = 4;
> + version.name = name;
> +
> + ret = ioctl(fd, DRM_IOCTL_VERSION, );
> + if (ret)
> + return 0;
> +
> + return !strcmp(name, "vgem");
> +}
> +
> +static int open_vgem(void)
> +{
> + int i, fd;
> + const char *drmstr = "/dev/dri/card";
> +
> + fd = -1;
> + for (i = 0; i < 16; i++) {
> + char name[80];
> +
> + sprintf(name, "%s%u", drmstr, i);
> +
> + fd = open(name, O_RDWR);
> + if (fd < 0)
> + continue;
> +
> + if (!check_vgem(fd)) {
> + close(fd);
I didn't spot this last time, but there's an (unlikely) error scenario
here if there's >= 16 DRM devices and none of them are vgem, then
you'll return a stale fd.
> + continue;
> + } else {
> + break;
> + }
> + }
> + return fd;
> +}
> +
> +static int import_vgem_fd(int vgem_fd, int dma_buf_fd, uint32_t *handle)
> +{
> + struct drm_prime_handle import_handle = {
> + .fd = dma_buf_fd,
> + .flags = 0,
> + .handle = 0,
> + };
> + int ret;
> +
> + ret = ioctl(vgem_fd, DRM_IOCTL_PRIME_FD_TO_HANDLE, _handle);
> + if (ret == 0)
> + *handle = import_handle.handle;
> + return ret;
> +}
> +
> +static void close_handle(int vgem_fd, uint32_t handle)
> +{
> + struct drm_gem_close close = {
> + .handle = handle,
> + };
> +
> + ioctl(vgem_fd, DRM_IOCTL_GEM_CLOSE, );
> +}
> +
> +static int dmabuf_heap_open(char *name)
> +{
> + int ret, fd;
> + char buf[256];
> +
> + ret = sprintf(buf, "%s/%s", DEVPATH, name);
Re: [RESEND][PATCH v8 4/5] dma-buf: heaps: Add CMA heap to dmabuf heaps
Hi John,
I spotted one thing below which might be harmless, but best to check.
On Fri, Sep 06, 2019 at 06:47:11PM +, John Stultz wrote:
> This adds a CMA heap, which allows userspace to allocate
> a dma-buf of contiguous memory out of a CMA region.
>
> This code is an evolution of the Android ION implementation, so
> thanks to its original author and maintainters:
> Benjamin Gaignard, Laura Abbott, and others!
>
> Cc: Laura Abbott
> Cc: Benjamin Gaignard
> Cc: Sumit Semwal
> Cc: Liam Mark
> Cc: Pratik Patel
> Cc: Brian Starkey
> Cc: Vincent Donnefort
> Cc: Sudipto Paul
> Cc: Andrew F. Davis
> Cc: Christoph Hellwig
> Cc: Chenbo Feng
> Cc: Alistair Strachan
> Cc: Hridya Valsaraju
> Cc: dri-devel@lists.freedesktop.org
> Reviewed-by: Benjamin Gaignard
> Signed-off-by: John Stultz
> ---
> v2:
> * Switch allocate to return dmabuf fd
> * Simplify init code
> * Checkpatch fixups
> v3:
> * Switch to inline function for to_cma_heap()
> * Minor cleanups suggested by Brian
> * Fold in new registration style from Andrew
> * Folded in changes from Andrew to use simplified page list
> from the heap helpers
> v4:
> * Use the fd_flags when creating dmabuf fd (Suggested by
> Benjamin)
> * Use precalculated pagecount (Suggested by Andrew)
> v6:
> * Changed variable names to improve clarity, as suggested
> by Brian
> v7:
> * Use newly lower-cased init_heap_helper_buffer helper
> * Use new dmabuf export helper
> v8:
> * Make struct dma_heap_ops const (Suggested by Christoph)
> * Condense dma_heap_buffer and heap_helper_buffer (suggested by
> Christoph)
> * Checkpatch whitespace fixups
> ---
...
> +
> +/* dmabuf heap CMA operations functions */
> +static int cma_heap_allocate(struct dma_heap *heap,
> + unsigned long len,
> + unsigned long fd_flags,
> + unsigned long heap_flags)
> +{
> + struct cma_heap *cma_heap = dma_heap_get_data(heap);
> + struct heap_helper_buffer *helper_buffer;
> + struct page *cma_pages;
> + size_t size = PAGE_ALIGN(len);
> + unsigned long nr_pages = size >> PAGE_SHIFT;
> + unsigned long align = get_order(size);
> + struct dma_buf *dmabuf;
> + int ret = -ENOMEM;
> + pgoff_t pg;
> +
> + if (align > CONFIG_CMA_ALIGNMENT)
> + align = CONFIG_CMA_ALIGNMENT;
> +
> + helper_buffer = kzalloc(sizeof(*helper_buffer), GFP_KERNEL);
> + if (!helper_buffer)
> + return -ENOMEM;
> +
> + init_heap_helper_buffer(helper_buffer, cma_heap_free);
> + helper_buffer->flags = heap_flags;
> + helper_buffer->heap = heap;
> + helper_buffer->size = len;
> +
> + cma_pages = cma_alloc(cma_heap->cma, nr_pages, align, false);
> + if (!cma_pages)
> + goto free_buf;
> +
> + if (PageHighMem(cma_pages)) {
> + unsigned long nr_clear_pages = nr_pages;
> + struct page *page = cma_pages;
> +
> + while (nr_clear_pages > 0) {
> + void *vaddr = kmap_atomic(page);
> +
> + memset(vaddr, 0, PAGE_SIZE);
> + kunmap_atomic(vaddr);
> + page++;
> + nr_clear_pages--;
> + }
> + } else {
> + memset(page_address(cma_pages), 0, size);
> + }
> +
> + helper_buffer->pagecount = nr_pages;
> + helper_buffer->pages = kmalloc_array(helper_buffer->pagecount,
> + sizeof(*helper_buffer->pages),
> + GFP_KERNEL);
> + if (!helper_buffer->pages) {
> + ret = -ENOMEM;
> + goto free_cma;
> + }
> +
> + for (pg = 0; pg < helper_buffer->pagecount; pg++) {
> + helper_buffer->pages[pg] = _pages[pg];
> + if (!helper_buffer->pages[pg])
Is this ever really possible? If cma_pages is non-NULL (which you
check earlier), then only if the pointer arithmetic overflows right?
If it's just redundant, then you could remove it (and in that case add
my r-b). But maybe you meant to check something else?
Cheers,
-Brian
Re: [RESEND][PATCH v8 3/5] dma-buf: heaps: Add system heap to dmabuf heaps
On Fri, Sep 06, 2019 at 06:47:10PM +, John Stultz wrote: > This patch adds system heap to the dma-buf heaps framework. > > This allows applications to get a page-allocator backed dma-buf > for non-contiguous memory. > > This code is an evolution of the Android ION implementation, so > thanks to its original authors and maintainters: > Rebecca Schultz Zavin, Colin Cross, Laura Abbott, and others! > > Cc: Laura Abbott > Cc: Benjamin Gaignard > Cc: Sumit Semwal > Cc: Liam Mark > Cc: Pratik Patel > Cc: Brian Starkey > Cc: Vincent Donnefort > Cc: Sudipto Paul > Cc: Andrew F. Davis > Cc: Christoph Hellwig > Cc: Chenbo Feng > Cc: Alistair Strachan > Cc: Hridya Valsaraju > Cc: dri-devel@lists.freedesktop.org > Reviewed-by: Benjamin Gaignard > Signed-off-by: John Stultz LGTM: Reviewed-by: Brian Starkey
Re: [RESEND][PATCH v8 1/5] dma-buf: Add dma-buf heaps framework
Hi John,
On Fri, Sep 06, 2019 at 06:47:08PM +, John Stultz wrote:
> From: "Andrew F. Davis"
>
> This framework allows a unified userspace interface for dma-buf
> exporters, allowing userland to allocate specific types of memory
> for use in dma-buf sharing.
>
> Each heap is given its own device node, which a user can allocate
> a dma-buf fd from using the DMA_HEAP_IOC_ALLOC.
>
> This code is an evoluiton of the Android ION implementation,
> and a big thanks is due to its authors/maintainers over time
> for their effort:
> Rebecca Schultz Zavin, Colin Cross, Benjamin Gaignard,
> Laura Abbott, and many other contributors!
>
> Cc: Laura Abbott
> Cc: Benjamin Gaignard
> Cc: Sumit Semwal
> Cc: Liam Mark
> Cc: Pratik Patel
> Cc: Brian Starkey
> Cc: Vincent Donnefort
> Cc: Sudipto Paul
> Cc: Andrew F. Davis
> Cc: Christoph Hellwig
> Cc: Chenbo Feng
> Cc: Alistair Strachan
> Cc: Hridya Valsaraju
> Cc: dri-devel@lists.freedesktop.org
> Reviewed-by: Benjamin Gaignard
> Signed-off-by: Andrew F. Davis
> Signed-off-by: John Stultz
One miniscule nit from me below, but whether you change it or not, you
can add my r-b:
Reviewed-by: Brian Starkey
Thanks for pushing this through!
-Brian
> ---
...
> +
> + dev_ret = device_create(dma_heap_class,
> + NULL,
> + heap->heap_devt,
> + NULL,
> + heap->name);
> + if (IS_ERR(dev_ret)) {
> + pr_err("dma_heap: Unable to create device\n");
> + err_ret = (struct dma_heap *)dev_ret;
Tiny nit: ERR_CAST() would be more obvious for me here.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RESEND][PATCH v8 2/5] dma-buf: heaps: Add heap helpers
Hi John,
On Fri, Sep 06, 2019 at 06:47:09PM +, John Stultz wrote:
> Add generic helper dmabuf ops for dma heaps, so we can reduce
> the amount of duplicative code for the exported dmabufs.
>
> This code is an evolution of the Android ION implementation, so
> thanks to its original authors and maintainters:
> Rebecca Schultz Zavin, Colin Cross, Laura Abbott, and others!
>
> Cc: Laura Abbott
> Cc: Benjamin Gaignard
> Cc: Sumit Semwal
> Cc: Liam Mark
> Cc: Pratik Patel
> Cc: Brian Starkey
> Cc: Vincent Donnefort
> Cc: Sudipto Paul
> Cc: Andrew F. Davis
> Cc: Christoph Hellwig
> Cc: Chenbo Feng
> Cc: Alistair Strachan
> Cc: Hridya Valsaraju
> Cc: dri-devel@lists.freedesktop.org
> Reviewed-by: Benjamin Gaignard
> Signed-off-by: John Stultz
Two minor things below.
> ---
> v2:
> * Removed cache management performance hack that I had
> accidentally folded in.
> * Removed stats code that was in helpers
> * Lots of checkpatch cleanups
> v3:
> * Uninline INIT_HEAP_HELPER_BUFFER (suggested by Christoph)
> * Switch to WARN on buffer destroy failure (suggested by Brian)
> * buffer->kmap_cnt decrementing cleanup (suggested by Christoph)
> * Extra buffer->vaddr checking in dma_heap_dma_buf_kmap
> (suggested by Brian)
> * Switch to_helper_buffer from macro to inline function
> (suggested by Benjamin)
> * Rename kmap->vmap (folded in from Andrew)
> * Use vmap for vmapping - not begin_cpu_access (folded in from
> Andrew)
> * Drop kmap for now, as its optional (folded in from Andrew)
> * Fold dma_heap_map_user into the single caller (foled in from
> Andrew)
> * Folded in patch from Andrew to track page list per heap not
> sglist, which simplifies the tracking logic
> v4:
> * Moved dma-heap.h change out to previous patch
> v6:
> * Minor cleanups and typo fixes suggested by Brian
> v7:
> * Removed stray ;
> * Make init_heap_helper_buffer lowercase, as suggested by Christoph
> * Add dmabuf export helper to reduce boilerplate code
> v8:
> * Remove unused private_flags value
> * Condense dma_heap_buffer and heap_helper_buffer (suggested by
> Christoph)
> * Fix indentation by using shorter argument names (suggested by
> Christoph)
> * Add flush_kernel_vmap_range/invalidate_kernel_vmap_range calls
> (suggested by Christoph)
> * Checkpatch whitespace fixups
> ---
...
> +
> +static void *dma_heap_buffer_vmap_get(struct heap_helper_buffer *buffer)
> +{
> + void *vaddr;
> +
> + if (buffer->vmap_cnt) {
> + buffer->vmap_cnt++;
> + return buffer->vaddr;
> + }
> + vaddr = dma_heap_map_kernel(buffer);
> + if (WARN_ONCE(!vaddr,
> + "heap->ops->map_kernel should return ERR_PTR on error"))
Looks like the message is out-of-date here.
...
> +
> +/**
> + * struct heap_helper_buffer - helper buffer metadata
> + * @heap:back pointer to the heap the buffer came from
> + * @dmabuf: backing dma-buf for this buffer
> + * @size:size of the buffer
> + * @flags: buffer specific flags
> + * @priv_virtpointer to heap specific private value
> + * @lock mutext to protect the data in this structure
> + * @vmap_cnt count of vmap references on the buffer
> + * @vaddr vmap'ed virtual address
> + * @pagecountnumber of pages in the buffer
> + * @pageslist of page pointers
> + * @attachment list of device attachments
s/attachment/attachments/
With those fixed, feel free to add:
Reviewed-by: Brian Starkey
Thanks,
-Brian
Re: [PATCH] drm/komeda: Adds output-color format/depth support
Hi Lowry,
On Fri, Sep 20, 2019 at 09:43:47AM +, Lowry Li (Arm Technology China) wrote:
> From: "Lowry Li (Arm Technology China)"
>
> Sets color_depth according to connector->bpc.
> Adds a new optional DT attribute "color-format" to represent a
> preferred color formats for a specific pipeline, and the select order
> is:
> YCRCB420 > YCRCB422 > YCRCB444 > RGB444
> The color-format can be anyone of these 4 format, one color-format not
> only represent one format, but also include the lower formats, like
>
> color-format preferred_color_formats
> YCRCB420YCRCB420 > YCRCB422 > YCRCB444 > RGB444
> YCRCB422YCRCB422 > YCRCB444 > RGB444
> YCRCB444YCRCB444 > RGB444
> RGB444 RGB444
>
> Then the final color_format is calculated by 3 steps:
> 1. calculate HW available formats.
> avail_formats = connector_color_formats & improc->color_formats;
> 2. filter out un-preferred format.
> avail_formats &= preferred_color_formats;
> 3. select the final format according to the preferred order.
> color_format = BIT(__fls(aval_formats));
Is there a specific use-case for the DT property for selecting color
format?
I think in general the color format should be determined according to
the rules in the CEA spec. There's also the drm_mode_is_420_only()
helper we can use to determine if YCBCR420 must be used. For the cases
where it's optional, I think we can default to RGB444.
Thanks,
-Brian
>
> Changes since v1:
> Rebased to the drm-misc-next branch.
>
> Signed-off-by: Lowry Li (Arm Technology China)
> ---
> .../arm/display/komeda/d71/d71_component.c| 15 -
> .../gpu/drm/arm/display/komeda/komeda_crtc.c | 27
> .../gpu/drm/arm/display/komeda/komeda_dev.c | 32 ++-
> .../gpu/drm/arm/display/komeda/komeda_kms.h | 2 ++
> .../drm/arm/display/komeda/komeda_pipeline.h | 3 ++
> .../display/komeda/komeda_pipeline_state.c| 31 ++
> .../arm/display/komeda/komeda_wb_connector.c | 5 +++
> 7 files changed, 113 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/arm/display/komeda/d71/d71_component.c
> b/drivers/gpu/drm/arm/display/komeda/d71/d71_component.c
> index c3d29c0b051b..7b374a3b911e 100644
> --- a/drivers/gpu/drm/arm/display/komeda/d71/d71_component.c
> +++ b/drivers/gpu/drm/arm/display/komeda/d71/d71_component.c
> @@ -944,13 +944,26 @@ static void d71_improc_update(struct komeda_component
> *c,
> {
> struct komeda_improc_state *st = to_improc_st(state);
> u32 __iomem *reg = c->reg;
> - u32 index;
> + u32 index, mask = 0, ctrl = 0;
>
> for_each_changed_input(state, index)
> malidp_write32(reg, BLK_INPUT_ID0 + index * 4,
> to_d71_input_id(state, index));
>
> malidp_write32(reg, BLK_SIZE, HV_SIZE(st->hsize, st->vsize));
> + malidp_write32(reg, IPS_DEPTH, st->color_depth);
> +
> + mask |= IPS_CTRL_YUV | IPS_CTRL_CHD422 | IPS_CTRL_CHD420;
> +
> + /* config color format */
> + if (st->color_format == DRM_COLOR_FORMAT_YCRCB420)
> + ctrl |= IPS_CTRL_YUV | IPS_CTRL_CHD422 | IPS_CTRL_CHD420;
> + else if (st->color_format == DRM_COLOR_FORMAT_YCRCB422)
> + ctrl |= IPS_CTRL_YUV | IPS_CTRL_CHD422;
> + else if (st->color_format == DRM_COLOR_FORMAT_YCRCB444)
> + ctrl |= IPS_CTRL_YUV;
> +
> + malidp_write32_mask(reg, BLK_CONTROL, mask, ctrl);
> }
>
> static void d71_improc_dump(struct komeda_component *c, struct seq_file *sf)
> diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_crtc.c
> b/drivers/gpu/drm/arm/display/komeda/komeda_crtc.c
> index 624d257da20f..38d5cb20e908 100644
> --- a/drivers/gpu/drm/arm/display/komeda/komeda_crtc.c
> +++ b/drivers/gpu/drm/arm/display/komeda/komeda_crtc.c
> @@ -18,6 +18,33 @@
> #include "komeda_dev.h"
> #include "komeda_kms.h"
>
> +void komeda_crtc_get_color_config(struct drm_crtc_state *crtc_st,
> + u32 *color_depths, u32 *color_formats)
> +{
> + struct drm_connector *conn;
> + struct drm_connector_state *conn_st;
> + u32 conn_color_formats = ~0u;
> + int i, min_bpc = 31, conn_bpc = 0;
> +
> + for_each_new_connector_in_state(crtc_st->state, conn, conn_st, i) {
> + if (conn_st->crtc != crtc_st->crtc)
> + continue;
> +
> + conn_bpc = conn->display_info.bpc ? conn->display_info.bpc : 8;
> + conn_color_formats &= conn->display_info.color_formats;
> +
> + if (conn_bpc < min_bpc)
> + min_bpc = conn_bpc;
> + }
> +
> + /* connector doesn't config any color_format, use RGB444 as default */
> + if (conn_color_formats == 0)
> + conn_color_formats = DRM_COLOR_FORMAT_RGB444;
> +
> + *color_depths = GENMASK(conn_bpc, 0);
> + *color_formats = conn_color_formats;
> +}
> +
> static void komeda_crtc_update_clock_ratio(struct komeda_crtc_state
>
[PATCH v3] drm/crc-debugfs: Add notes about CRC<->commit interactions
CRC generation can be impacted by commits coming from userspace, and
enabling CRC generation may itself trigger a commit. Add notes about
this to the kerneldoc.
Changes since v1:
- Clarified that anything that would disable CRCs counts as a full
modeset, and so userspace needs to reconfigure after full modesets
Changes since v2:
- Add these notes
- Rebase onto drm-misc-next (trivial conflict in comment)
Signed-off-by: Brian Starkey
Reviewed-by: Daniel Vetter
---
drivers/gpu/drm/drm_debugfs_crc.c | 9 +
include/drm/drm_crtc.h| 4
2 files changed, 13 insertions(+)
diff --git a/drivers/gpu/drm/drm_debugfs_crc.c
b/drivers/gpu/drm/drm_debugfs_crc.c
index 6604ed223160..be1b7ba92ffe 100644
--- a/drivers/gpu/drm/drm_debugfs_crc.c
+++ b/drivers/gpu/drm/drm_debugfs_crc.c
@@ -69,6 +69,15 @@
* implement _crtc_funcs.set_crc_source and
_crtc_funcs.verify_crc_source.
* The debugfs files are automatically set up if those vfuncs are set. CRC
samples
* need to be captured in the driver by calling drm_crtc_add_crc_entry().
+ * Depending on the driver and HW requirements, _crtc_funcs.set_crc_source
+ * may result in a commit (even a full modeset).
+ *
+ * CRC results must be reliable across non-full-modeset atomic commits, so if a
+ * commit via DRM_IOCTL_MODE_ATOMIC would disable or otherwise interfere with
+ * CRC generation, then the driver must mark that commit as a full modeset
+ * (drm_atomic_crtc_needs_modeset() should return true). As a result, to ensure
+ * consistent results, generic userspace must re-setup CRC generation after a
+ * legacy SETCRTC or an atomic commit with DRM_MODE_ATOMIC_ALLOW_MODESET.
*/
static int crc_control_show(struct seq_file *m, void *data)
diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
index 128d8b210621..7d14c11bdc0a 100644
--- a/include/drm/drm_crtc.h
+++ b/include/drm/drm_crtc.h
@@ -756,6 +756,9 @@ struct drm_crtc_funcs {
* provided from the configured source. Drivers must accept an "auto"
* source name that will select a default source for this CRTC.
*
+* This may trigger an atomic modeset commit if necessary, to enable CRC
+* generation.
+*
* Note that "auto" can depend upon the current modeset configuration,
* e.g. it could pick an encoder or output specific CRC sampling point.
*
@@ -767,6 +770,7 @@ struct drm_crtc_funcs {
* 0 on success or a negative error code on failure.
*/
int (*set_crc_source)(struct drm_crtc *crtc, const char *source);
+
/**
* @verify_crc_source:
*
--
2.17.1
[PATCH v2] drm/crc-debugfs: Add notes about CRC<->commit interactions
CRC generation can be impacted by commits coming from userspace, and
enabling CRC generation may itself trigger a commit. Add notes about
this to the kerneldoc.
Signed-off-by: Brian Starkey
---
drivers/gpu/drm/drm_debugfs_crc.c | 17 +
include/drm/drm_crtc.h| 4
2 files changed, 17 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/drm_debugfs_crc.c
b/drivers/gpu/drm/drm_debugfs_crc.c
index 7ca486d750e9..77159b6e77c3 100644
--- a/drivers/gpu/drm/drm_debugfs_crc.c
+++ b/drivers/gpu/drm/drm_debugfs_crc.c
@@ -65,10 +65,19 @@
* it submits. In this general case, the maximum userspace can do is to compare
* the reported CRCs of frames that should have the same contents.
*
- * On the driver side the implementation effort is minimal, drivers only need
to
- * implement _crtc_funcs.set_crc_source. The debugfs files are
automatically
- * set up if that vfunc is set. CRC samples need to be captured in the driver
by
- * calling drm_crtc_add_crc_entry().
+ * On the driver side the implementation effort is minimal, drivers only need
+ * to implement _crtc_funcs.set_crc_source. The debugfs files are
+ * automatically set up if that vfunc is set. CRC samples need to be captured
+ * in the driver by calling drm_crtc_add_crc_entry(). Depending on the driver
+ * and HW requirements, _crtc_funcs.set_crc_source may result in a commit
+ * (even a full modeset).
+ *
+ * CRC results must be reliable across non-full-modeset atomic commits, so if a
+ * commit via DRM_IOCTL_MODE_ATOMIC would disable or otherwise interfere with
+ * CRC generation, then the driver must mark that commit as a full modeset
+ * (drm_atomic_crtc_needs_modeset() should return true). As a result, to ensure
+ * consistent results, generic userspace must re-setup CRC generation after a
+ * legacy SETCRTC or an atomic commit with DRM_MODE_ATOMIC_ALLOW_MODESET.
*/
static int crc_control_show(struct seq_file *m, void *data)
diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
index 128d8b210621..7d14c11bdc0a 100644
--- a/include/drm/drm_crtc.h
+++ b/include/drm/drm_crtc.h
@@ -756,6 +756,9 @@ struct drm_crtc_funcs {
* provided from the configured source. Drivers must accept an "auto"
* source name that will select a default source for this CRTC.
*
+* This may trigger an atomic modeset commit if necessary, to enable CRC
+* generation.
+*
* Note that "auto" can depend upon the current modeset configuration,
* e.g. it could pick an encoder or output specific CRC sampling point.
*
@@ -767,6 +770,7 @@ struct drm_crtc_funcs {
* 0 on success or a negative error code on failure.
*/
int (*set_crc_source)(struct drm_crtc *crtc, const char *source);
+
/**
* @verify_crc_source:
*
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/crc-debugfs: Add notes about CRC<->commit interactions
On Mon, Aug 05, 2019 at 06:24:17PM +0200, Daniel Vetter wrote:
> On Mon, Aug 05, 2019 at 04:11:43PM +0100, Brian Starkey wrote:
> > CRC generation can be impacted by commits coming from userspace, and
> > enabling CRC generation may itself trigger a commit. Add notes about
> > this to the kerneldoc.
> >
> > Signed-off-by: Brian Starkey
> > ---
> >
> > I might have got the wrong end of the stick, but this is what I
> > understood from what you said.
> >
> > Cheers,
> > -Brian
> >
> > drivers/gpu/drm/drm_debugfs_crc.c | 15 +++
> > include/drm/drm_crtc.h| 3 +++
> > 2 files changed, 14 insertions(+), 4 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/drm_debugfs_crc.c
> > b/drivers/gpu/drm/drm_debugfs_crc.c
> > index 7ca486d750e9..1dff956bcc74 100644
> > --- a/drivers/gpu/drm/drm_debugfs_crc.c
> > +++ b/drivers/gpu/drm/drm_debugfs_crc.c
> > @@ -65,10 +65,17 @@
> > * it submits. In this general case, the maximum userspace can do is to
> > compare
> > * the reported CRCs of frames that should have the same contents.
> > *
> > - * On the driver side the implementation effort is minimal, drivers only
> > need to
> > - * implement _crtc_funcs.set_crc_source. The debugfs files are
> > automatically
> > - * set up if that vfunc is set. CRC samples need to be captured in the
> > driver by
> > - * calling drm_crtc_add_crc_entry().
> > + * On the driver side the implementation effort is minimal, drivers only
> > need
> > + * to implement _crtc_funcs.set_crc_source. The debugfs files are
> > + * automatically set up if that vfunc is set. CRC samples need to be
> > captured
> > + * in the driver by calling drm_crtc_add_crc_entry(). Depending on the
> > driver
> > + * and HW requirements, _crtc_funcs.set_crc_source may result in a
> > commit
> > + * (even a full modeset).
> > + *
> > + * It's also possible that a "normal" commit via DRM_IOCTL_MODE_ATOMIC or
> > the
> > + * legacy paths may interfere with CRC generation. So, in the general case,
> > + * userspace can't rely on the values in crtc-N/crc/data being valid
> > + * across a commit.
>
> It's not just the values, but the generation itself might get disabled
> (e.g. on i915 if you select "auto" on some chips you get the DP port
> sampling point, but for HDMI mode you get a different sampling ploint, and
> if you get the wrong one there won't be any crc for you). Also it's not
> just any atomic commit, only the ones with ALLOW_MODESET.
Is the meaning of ALLOW_MODESET actually defined somewhere then? I
thought it was broadly speaking "anything that would cause a flicker
on the output" - but that needn't be the same set of things that break
CRC generation.
>
> Maybe something like the below text:
>
> "Please note that an atomic modeset commit with the
> DRM_MODE_ATOMIC_ALLOW_MODESET, or a call to the legacy SETCRTR ioctl
> (which amounts to the same), can destry the CRC setup due to hardware
> requirements. This results in inconsistent CRC values or not even any CRC
> values generated. Generic userspace therefore needs to re-setup the CRC
> after each such modeset."
>
> >
> > static int crc_control_show(struct seq_file *m, void *data)
> > diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
> > index 128d8b210621..0f7ea094a900 100644
> > --- a/include/drm/drm_crtc.h
> > +++ b/include/drm/drm_crtc.h
> > @@ -756,6 +756,8 @@ struct drm_crtc_funcs {
> > * provided from the configured source. Drivers must accept an "auto"
> > * source name that will select a default source for this CRTC.
> > *
> > + * This may trigger a commit if necessary, to enable CRC generation.
>
> I'd clarify this as "atomic modeset commit" just to be sure.
Ack.
Thanks,
-Brian
>
> With these two comments addressed somehow:
>
> Reviewed-by: Daniel Vetter
>
>
> > + *
> > * Note that "auto" can depend upon the current modeset configuration,
> > * e.g. it could pick an encoder or output specific CRC sampling point.
> > *
> > @@ -767,6 +769,7 @@ struct drm_crtc_funcs {
> > * 0 on success or a negative error code on failure.
> > */
> > int (*set_crc_source)(struct drm_crtc *crtc, const char *source);
> > +
> > /**
> > * @verify_crc_source:
> > *
> > --
> > 2.17.1
> >
>
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch
IMPORTANT NOTICE: The contents of this email and any attachments are
confidential and may also be privileged. If you are not the intended recipient,
please notify the sender immediately and do not disclose the contents to any
other person, use it for any purpose, or store or copy the information in any
medium. Thank you.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
