Re: [PATCHv2 3/4] drm/komeda: use afbc helpers
On Mon, Nov 04, 2019 at 11:12:27PM +0100, Andrzej Pietrasiewicz wrote:
> There are afbc helpers available.
>
> Signed-off-by: Andrzej Pietrasiewicz
> ---
> .../arm/display/komeda/komeda_format_caps.h | 1 -
> .../arm/display/komeda/komeda_framebuffer.c | 44 +++
> 2 files changed, 17 insertions(+), 28 deletions(-)
>
> diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_format_caps.h
> b/drivers/gpu/drm/arm/display/komeda/komeda_format_caps.h
> index 32273cf18f7c..607eea80e60c 100644
> --- a/drivers/gpu/drm/arm/display/komeda/komeda_format_caps.h
> +++ b/drivers/gpu/drm/arm/display/komeda/komeda_format_caps.h
> @@ -33,7 +33,6 @@
>
> #define AFBC_TH_LAYOUT_ALIGNMENT 8
> #define AFBC_HEADER_SIZE 16
> -#define AFBC_SUPERBLK_ALIGNMENT 128
> #define AFBC_SUPERBLK_PIXELS 256
> #define AFBC_BODY_START_ALIGNMENT1024
> #define AFBC_TH_BODY_START_ALIGNMENT 4096
> diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_framebuffer.c
> b/drivers/gpu/drm/arm/display/komeda/komeda_framebuffer.c
> index 1b01a625f40e..e9c87551a5b8 100644
> --- a/drivers/gpu/drm/arm/display/komeda/komeda_framebuffer.c
> +++ b/drivers/gpu/drm/arm/display/komeda/komeda_framebuffer.c
> @@ -4,6 +4,7 @@
> * Author: James.Qian.Wang
> *
> */
> +#include
> #include
> #include
> #include
> @@ -43,8 +44,7 @@ komeda_fb_afbc_size_check(struct komeda_fb *kfb, struct
> drm_file *file,
> struct drm_framebuffer *fb = >base;
> const struct drm_format_info *info = fb->format;
> struct drm_gem_object *obj;
> - u32 alignment_w = 0, alignment_h = 0, alignment_header, n_blocks, bpp;
> - u64 min_size;
> + u32 alignment_w = 0, alignment_h = 0, alignment_header, bpp;
>
> obj = drm_gem_object_lookup(file, mode_cmd->handles[0]);
> if (!obj) {
> @@ -52,19 +52,15 @@ komeda_fb_afbc_size_check(struct komeda_fb *kfb, struct
> drm_file *file,
> return -ENOENT;
> }
>
> - switch (fb->modifier & AFBC_FORMAT_MOD_BLOCK_SIZE_MASK) {
> - case AFBC_FORMAT_MOD_BLOCK_SIZE_32x8:
> - alignment_w = 32;
> - alignment_h = 8;
> - break;
> - case AFBC_FORMAT_MOD_BLOCK_SIZE_16x16:
> - alignment_w = 16;
> - alignment_h = 16;
> - break;
> - default:
> - WARN(1, "Invalid AFBC_FORMAT_MOD_BLOCK_SIZE: %lld.\n",
> - fb->modifier & AFBC_FORMAT_MOD_BLOCK_SIZE_MASK);
> - break;
> + if (!drm_afbc_get_superblk_wh(fb->modifier, _w, _h))
> + return -EINVAL;
> +
> + if ((alignment_w != 16 || alignment_h != 16) &&
> + (alignment_w != 32 || alignment_h != 8)) {
> + DRM_DEBUG_KMS("Unsupported afbc tile w/h [%d/%d]\n",
> + alignment_w, alignment_h);
> +
> + return -EINVAL;
To be honest, the previous code looks much more readable
> }
>
> /* tiled header afbc */
> @@ -84,20 +80,14 @@ komeda_fb_afbc_size_check(struct komeda_fb *kfb, struct
> drm_file *file,
> goto check_failed;
> }
>
> - n_blocks = (kfb->aligned_w * kfb->aligned_h) / AFBC_SUPERBLK_PIXELS;
> - kfb->offset_payload = ALIGN(n_blocks * AFBC_HEADER_SIZE,
> - alignment_header);
> -
> bpp = komeda_get_afbc_format_bpp(info, fb->modifier);
> - kfb->afbc_size = kfb->offset_payload + n_blocks *
> - ALIGN(bpp * AFBC_SUPERBLK_PIXELS / 8,
> -AFBC_SUPERBLK_ALIGNMENT);
> - min_size = kfb->afbc_size + fb->offsets[0];
> - if (min_size > obj->size) {
> - DRM_DEBUG_KMS("afbc size check failed, obj_size: 0x%zx.
> min_size 0x%llx.\n",
> - obj->size, min_size);
We need kfb->offset_payload and kfb->afbc_size to set some registers
in d71_layer_update(). At this moment I feel like punching myself for
making the suggestion to consider abstracting some of the komeda's afbc
checks. To me it does not look like komeda(in the current shape) can take
much advantage of the generic _afbc_fb_check() function (as was suggested
previously by Danvet).
However, I will let james.qian.w...@arm.com,
mihail.atanas...@arm.com, ben.da...@arm.com comment here to see if
there could be a way of abstracting the afbc bits from komeda.
Thanks anyways for taking a stab at this.
-Ayan
> +
> + if (!drm_afbc_check_fb_size(mode_cmd->pitches[0], bpp,
> + mode_cmd->width, mode_cmd->height,
> + alignment_w, alignment_h,
> + obj->size, mode_cmd->offsets[0],
> + AFBC_SUPERBLK_ALIGNMENT))
> goto check_failed;
> - }
>
> fb->obj[0] = obj;
> return 0;
> --
> 2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
Re: Question regarding "reserved-memory"
On Thu, Oct 24, 2019 at 09:51:04AM -0500, Rob Herring wrote:
> On Thu, Oct 24, 2019 at 9:22 AM Ayan Halder wrote:
Hi Bob,
Thanks for your quick response.
> >
> >
> > Hi Folks,
> >
> > I have a question regarding "reserved-memory". I am using an Arm Juno
> > platform which has a chunk of ram in its fpga. I intend to make this
> > memory as reserved so that it can be shared between various devices
> > for passing framebuffer.
> >
> > My dts looks like the following:-
> >
> > / {
> > // some nodes
> >
> > tlx@6000 {
> > compatible = "simple-bus";
> > ...
> >
> > juno_wrapper {
> >
> > ... /* here we have all the nodes */
> > /* corresponding to the devices in the fpga */
> >
> > memory@d00 {
> >device_type = "memory";
> >reg = <0x00 0x6000 0x00 0x800>;
> > };
> >
> > reserved-memory {
> >#address-cells = <0x01>;
> >#size-cells = <0x01>;
> >ranges;
> >
> >framebuffer@d00 {
> > compatible = "shared-dma-pool";
> > linux,cma-default;
> > reusable;
> > reg = <0x00 0x6000 0x00
> > 0x800>;
> > phandle = <0x44>;
> > };
> > };
> > ...
> > }
> > }
> > ...
> > }
> >
> > Note that the depth of the "reserved-memory" node is 3.
> >
> > Refer __fdt_scan_reserved_mem() :-
> >
> > if (!found && depth == 1 && strcmp(uname, "reserved-memory") == 0) {
> >
> > if (__reserved_mem_check_root(node) != 0) {
> > pr_err("Reserved memory: unsupported node
> > format, ignoring\n");
> > /* break scan */
> > return 1;
> > }
> > found = 1;
> >
> > /* scan next node */
> > return 0;
> > }
> >
> > It expects the "reserved-memory" node to be at depth == 1 and so it
> > does not probe it in our case.
> >
> > Niether from the
> > Documentation/devicetree/bindings/reserved-memory/reserved-memory.txt
> > nor from commit - e8d9d1f5485b52ec3c4d7af839e6914438f6c285,
> > I could understand the reason for such restriction.
> >
> > So, I seek the community's advice as to whether I should fix up
> > __fdt_scan_reserved_mem() so as to do away with the restriction or
> > put the "reserved-memory" node outside of 'tlx@6000' (which looks
> > logically incorrect as the memory is on the fpga platform).
>
> For now, I'm going to say it must be at the root level.
Can you mention it in the Documentation/.../reserved-memory.txt,
please?
> I'd guess the
> memory@d00 node is also just ignored (wrong unit-address BTW).
I would request you to ignore the address for the time being. In
juno_wrapper{}, we have a complex remapping of addresses of all the
sub-devices. I deliberately did not put that in the snippet, so as to
prevent any distraction from the core issue.
>
> I think you're also forgetting the later unflattened parsing of
> /reserved-memory.
Are you talking about the remaining part of the
__fdt_scan_reserved_mem() ie
} else if (found && depth < 2) {
/* scanning of /reserved-memory has been finished */
return 1;
}
if (!of_fdt_device_is_available(initial_boot_params, node))
return 0;
err = __reserved_mem_reserve_reg(node, uname);
if (err == -ENOENT && of_get_flat_dt_prop(node, "size", NULL))
fdt_reserved_mem_save_node(node, uname, 0, 0);
/* scan next node */
return 0;
If so, I agree with you that it needs to be changed as well (if we
were to do away with the restriction).
> The other complication IIRC is booting with UEFI
> does it's own reserved memory table which often uses the DT table as
> its source.
I have no knowledge of UEFI booting. So if UEFI expects
"reserved-memory" nodes to be at root level, then we must adhere to
the restriction. :)
Ayan
>
> Rob
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Question regarding "reserved-memory"
Hi Folks,
I have a question regarding "reserved-memory". I am using an Arm Juno
platform which has a chunk of ram in its fpga. I intend to make this
memory as reserved so that it can be shared between various devices
for passing framebuffer.
My dts looks like the following:-
/ {
// some nodes
tlx@6000 {
compatible = "simple-bus";
...
juno_wrapper {
... /* here we have all the nodes */
/* corresponding to the devices in the fpga */
memory@d00 {
device_type = "memory";
reg = <0x00 0x6000 0x00 0x800>;
};
reserved-memory {
#address-cells = <0x01>;
#size-cells = <0x01>;
ranges;
framebuffer@d00 {
compatible = "shared-dma-pool";
linux,cma-default;
reusable;
reg = <0x00 0x6000 0x00 0x800>;
phandle = <0x44>;
};
};
...
}
}
...
}
Note that the depth of the "reserved-memory" node is 3.
Refer __fdt_scan_reserved_mem() :-
if (!found && depth == 1 && strcmp(uname, "reserved-memory") == 0) {
if (__reserved_mem_check_root(node) != 0) {
pr_err("Reserved memory: unsupported node
format, ignoring\n");
/* break scan */
return 1;
}
found = 1;
/* scan next node */
return 0;
}
It expects the "reserved-memory" node to be at depth == 1 and so it
does not probe it in our case.
Niether from the
Documentation/devicetree/bindings/reserved-memory/reserved-memory.txt
nor from commit - e8d9d1f5485b52ec3c4d7af839e6914438f6c285,
I could understand the reason for such restriction.
So, I seek the community's advice as to whether I should fix up
__fdt_scan_reserved_mem() so as to do away with the restriction or
put the "reserved-memory" node outside of 'tlx@6000' (which looks
logically incorrect as the memory is on the fpga platform).
Thanks,
Ayan
___
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 Mon, Oct 21, 2019 at 09:18:07AM +, Brian Starkey wrote:
> 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
> > >&g
Re: [PATCH 1/2] drm/arm: Factor out generic afbc helpers
On Fri, Oct 11, 2019 at 01:18:10PM +0200, Andrzej Pietrasiewicz wrote:
> These are useful for other users of afbc, e.g. rockchip.
>
> Signed-off-by: Andrzej Pietrasiewicz
Hi Andrzej,
Thanks a lot for doing this. Much appreciated. :)
It was on our TODO list for a long time.
I have cc-ed james.qian.w...@arm.com, mihail.atanas...@arm.com for
their comments as well.
> ---
> drivers/gpu/drm/Kconfig | 4 ++
> drivers/gpu/drm/Makefile | 1 +
> drivers/gpu/drm/arm/Kconfig | 1 +
> drivers/gpu/drm/arm/malidp_drv.c | 58 ++--
> drivers/gpu/drm/drm_afbc.c | 114 +++
> include/drm/drm_afbc.h | 25 +++
> 6 files changed, 149 insertions(+), 54 deletions(-)
> create mode 100644 drivers/gpu/drm/drm_afbc.c
> create mode 100644 include/drm/drm_afbc.h
>
> diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
> index 3c88420e3497..00e3f90557f4 100644
> --- a/drivers/gpu/drm/Kconfig
> +++ b/drivers/gpu/drm/Kconfig
> @@ -195,6 +195,10 @@ config DRM_SCHED
> tristate
> depends on DRM
>
> +config DRM_AFBC
> + tristate
> + depends on DRM
Adding a 'help' would be great here. Stealing the first line from
https://www.kernel.org/doc/html/latest/gpu/afbc.html
"AFBC is a proprietary lossless image compression protocol and format.
It provides fine-grained random access and minimizes the amount of
data transferred between IP blocks."
> +
> source "drivers/gpu/drm/i2c/Kconfig"
>
> source "drivers/gpu/drm/arm/Kconfig"
> diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
> index 9f0d2ee35794..55368b668355 100644
> --- a/drivers/gpu/drm/Makefile
> +++ b/drivers/gpu/drm/Makefile
> @@ -31,6 +31,7 @@ drm-$(CONFIG_OF) += drm_of.o
> drm-$(CONFIG_AGP) += drm_agpsupport.o
> drm-$(CONFIG_DEBUG_FS) += drm_debugfs.o drm_debugfs_crc.o
> drm-$(CONFIG_DRM_LOAD_EDID_FIRMWARE) += drm_edid_load.o
> +drm-$(CONFIG_DRM_AFBC) += drm_afbc.o
>
> drm_vram_helper-y := drm_gem_vram_helper.o \
>drm_vram_helper_common.o \
> diff --git a/drivers/gpu/drm/arm/Kconfig b/drivers/gpu/drm/arm/Kconfig
> index a204103b3efb..25c3dc408cda 100644
> --- a/drivers/gpu/drm/arm/Kconfig
> +++ b/drivers/gpu/drm/arm/Kconfig
> @@ -29,6 +29,7 @@ config DRM_MALI_DISPLAY
> select DRM_KMS_HELPER
> select DRM_KMS_CMA_HELPER
> select DRM_GEM_CMA_HELPER
> + select DRM_AFBC
> select VIDEOMODE_HELPERS
> help
> Choose this option if you want to compile the ARM Mali Display
> diff --git a/drivers/gpu/drm/arm/malidp_drv.c
> b/drivers/gpu/drm/arm/malidp_drv.c
> index f25ec4382277..a67b69e08f63 100644
> --- a/drivers/gpu/drm/arm/malidp_drv.c
> +++ b/drivers/gpu/drm/arm/malidp_drv.c
> @@ -16,6 +16,7 @@
> #include
>
> #include
> +#include
> #include
> #include
> #include
> @@ -33,8 +34,6 @@
> #include "malidp_hw.h"
>
> #define MALIDP_CONF_VALID_TIMEOUT250
> -#define AFBC_HEADER_SIZE 16
> -#define AFBC_SUPERBLK_ALIGNMENT 128
>
> static void malidp_write_gamma_table(struct malidp_hw_device *hwdev,
>u32 data[MALIDP_COEFFTAB_NUM_COEFFS])
> @@ -275,24 +274,8 @@ malidp_verify_afbc_framebuffer_caps(struct drm_device
> *dev,
> mode_cmd->modifier[0]) == false)
> return false;
>
> - if (mode_cmd->offsets[0] != 0) {
> - DRM_DEBUG_KMS("AFBC buffers' plane offset should be 0\n");
> - return false;
> - }
> -
> - switch (mode_cmd->modifier[0] & AFBC_SIZE_MASK) {
> - case AFBC_SIZE_16X16:
> - if ((mode_cmd->width % 16) || (mode_cmd->height % 16)) {
> - DRM_DEBUG_KMS("AFBC buffers must be aligned to 16
> pixels\n");
> - return false;
> - }
> - break;
> - default:
> - DRM_DEBUG_KMS("Unsupported AFBC block size\n");
> - return false;
> - }
> -
> - return true;
> + return drm_afbc_check_offset(dev, mode_cmd) &&
> +drm_afbc_check_size_align(dev, mode_cmd);
> }
>
> static bool
> @@ -300,53 +283,20 @@ malidp_verify_afbc_framebuffer_size(struct drm_device
> *dev,
> struct drm_file *file,
> const struct drm_mode_fb_cmd2 *mode_cmd)
> {
> - int n_superblocks = 0;
> const struct drm_format_info *info;
> struct drm_gem_object *objs = NULL;
> - u32 afbc_superblock_size = 0, afbc_superblock_height = 0;
> - u32 afbc_superblock_width = 0, afbc_size = 0;
> int bpp = 0;
>
> - switch (mode_cmd->modifier[0] & AFBC_SIZE_MASK) {
> - case AFBC_SIZE_16X16:
> - afbc_superblock_height = 16;
> - afbc_superblock_width = 16;
> - break;
> - default:
> - DRM_DEBUG_KMS("AFBC superblock size is not supported\n");
> - return false;
> - }
> -
> info =
Re: [RESEND][PATCH v8 0/5] DMA-BUF Heaps (destaging ION)
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.
>
> 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)
++ john.stu...@linaro.org (Sorry, somehow I am missing your email while
sending. :( )
On Fri, Oct 18, 2019 at 06:41:24PM +, 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>;
> };
>
> Quoting reserved-memory.txt :-
> "The operating system can use the memory in this region with the limitation
> that
> the device driver(s) owning the region need to be able to reclaim it back"
>
> Thus as per my observation, without 'reusable', rmem_cma_setup()
> returns -EINVAL and the reserved-memory is not added as a cma region.
>
> 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
> [0.458415] Modules linked in:
>
> [0.461470] CPU: 2 PID: 1 Comm: swapper/0 Not tainted
> 5.3.0-rc4-01377-g51dbcf03884c-dirty #15
>
> [0.470017] Hardware name: ARM Juno development board (r0) (DT)
>
> [0.475953] pstate: 8005 (Nzcv daif -PAN -UAO)
>
> [0.480755] pc : cma_init_reserved_areas+0xec/0x22c
> [0.485643] lr : cma_init_reserved_areas+0xe8/0x22c
> <snip register dump --->
>
> [0.600646] Unable to handle kernel paging request at virtual address
> 7d80
> [0.608591] Mem abort info:
> [0.611386] ESR = 0x9606
> <---snip uninteresting bits --->
> [0.681069] pc : cma_init_reserved_areas+0x114/0x22c
> [0.686043] lr : cma_init_reserved_areas+0xe8/0x22c
>
>
> I am looking into this now. My final objective is to get
> "/dev/dma_hea
Re: [RESEND][PATCH v8 0/5] DMA-BUF Heaps (destaging ION)
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>;
};
Quoting reserved-memory.txt :-
"The operating system can use the memory in this region with the limitation that
the device driver(s) owning the region need to be able to reclaim it back"
Thus as per my observation, without 'reusable', rmem_cma_setup()
returns -EINVAL and the reserved-memory is not added as a cma region.
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
[0.458415] Modules linked in:
[0.461470] CPU: 2 PID: 1 Comm: swapper/0 Not tainted
5.3.0-rc4-01377-g51dbcf03884c-dirty #15
[0.470017] Hardware name: ARM Juno development board (r0) (DT)
[0.475953] pstate: 8005 (Nzcv daif -PAN -UAO)
[0.480755] pc : cma_init_reserved_areas+0xec/0x22c
[0.485643] lr : cma_init_reserved_areas+0xe8/0x22c
[0.600646] Unable to handle kernel paging request at virtual address
7d80
[0.608591] Mem abort info:
[0.611386] ESR = 0x9606
<---snip uninteresting bits --->
[0.681069] pc : cma_init_reserved_areas+0x114/0x22c
[0.686043] lr : cma_init_reserved_areas+0xe8/0x22c
I am looking into this now. My final objective is to get
"/dev/dma_heap/framebuffer"
(as a cma heap).
Any leads?
> 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: [PATCH 4/7] drm/meson: plane: add support for AFBC mode for OSD1 plane
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 i
Re: [PATCH 4/7] drm/meson: plane: add support for AFBC mode for OSD1 plane
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
Component 1: G
Component 2: B
Component 3: A (if available)
Thus, DRM_FORMAT_ABGR, DRM_FORMAT_BGR should only be allowed.
> + line_stride = ((priv->viu.osd1_width << 5) + 127) >> 7;
> + break;
> + }
> +
> + return ((line_stride + 1) >> 1) << 1;
> +}
> +
> static void meson_plane_atomic_update(struct
Re: [RESEND][PATCH v8 0/5] DMA-BUF Heaps (destaging ION)
On Tue, Sep 24, 2019 at 04:22:18PM +, Ayan Halder wrote:
> On Thu, Sep 19, 2019 at 10:21:52PM +0530, Sumit Semwal wrote:
> > Hello Christoph, everyone,
> >
> > On Sat, 7 Sep 2019 at 00:17, 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.
> > >
> > > Most of the changes in this revision are adddressing the more
> > > concrete feedback from Christoph (many thanks!). Though I'm not
> > > sure if some of the less specific feedback was completely resolved
> > > in discussion last time around. Please let me know!
> >
> > It looks like most of the feedback has been taken care of. If there's
> > no more objection to this series, I'd like to merge it in soon.
> >
> > If there are any more review comments, may I request you to please provide
> > them?
>
> I tested these patches using our internal test suite with Arm,komeda
> driver and the following node in dts
>
> reserved-memory {
> #address-cells = <0x2>;
> #size-cells = <0x2>;
> ranges;
>
> framebuffer@6000 {
> compatible = "shared-dma-pool";
> linux,cma-default;
> reg = <0x0 0x6000 0x0 0x800>;
> };
> }
Apologies for the confusion, this dts node is irrelevant as our tests were using
the cma heap (via /dev/dma_heap/reserved).
That raises a question. How do we represent the reserved-memory nodes
(as shown above) via the dma-buf heaps framework ?
>
> The tests went fine. Our tests allocates framebuffers of different
> sizes, posts them on screen and the driver writes back to one of the
> framebuffers. I havenot tested for any performance, latency or
> cache management related stuff. So, it that looks appropriate, feel
> free to add:-
> Tested-by:- Ayan Kumar Halder
>
> Are you planning to write some igt tests for it ?
> >
> > >
> > > New in v8:
> > > * Make struct dma_heap_ops consts (Suggested by Christoph)
> > > * Add flush_kernel_vmap_range/invalidate_kernel_vmap_range calls
> > > (suggested by Christoph)
> > > * Condense dma_heap_buffer and heap_helper_buffer (suggested by
> > > Christoph)
> > > * Get rid of needless struct system_heap (suggested by Christoph)
> > > * Fix indentation by using shorter argument names (suggested by
> > > Christoph)
> > > * Remove unused private_flags value
> > > * Add forgotten include file to fix build issue on x86
> > > * Checkpatch whitespace fixups
> > >
> > > Thoughts and feedback would be greatly appreciated!
> > >
> > > thanks
> > > -john
> > Best,
> > Sumit.
> > >
> > > 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
> > > C
Re: [PATCH v3] drm/fourcc: Add Arm 16x16 block modifier
On Fri, Oct 04, 2019 at 02:12:38PM +, Ayan Halder wrote:
> From: Raymond Smith
>
> 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.
>
> Changes from v2:-
> 1. Preserved Ray's authorship
> 2. Cleanups/changes suggested by Brian
> 3. Added r-bs of Brian and Qiang
>
> Signed-off-by: Raymond Smith
> Signed-off-by: Ayan kumar halder
> Reviewed-by: Brian Starkey
> Reviewed-by: Qiang Yu
Pushed to drm-misc-next - ba2a1c8706151ac3234d2d020873feab498ab1bb
> ---
> include/uapi/drm/drm_fourcc.h | 26 +-
> 1 file changed, 25 insertions(+), 1 deletion(-)
>
> diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
> index 3feeaa3f987a..2376d36ea573 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.
> + */
> +#define DRM_FORMAT_MOD_ARM_CODE(__type, __val) \
> + fourcc_mod_code(ARM, ((__u64)(__type) << 52) | ((__val) &
> 0x000fULL))
> +
> +#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,16 @@ 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)
> +
> /*
> * Allwinner tiled modifier
> *
> --
> 2.23.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3] drm/fourcc: Add Arm 16x16 block modifier
From: Raymond Smith
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.
Changes from v2:-
1. Preserved Ray's authorship
2. Cleanups/changes suggested by Brian
3. Added r-bs of Brian and Qiang
Signed-off-by: Raymond Smith
Signed-off-by: Ayan kumar halder
Reviewed-by: Brian Starkey
Reviewed-by: Qiang Yu
---
include/uapi/drm/drm_fourcc.h | 26 +-
1 file changed, 25 insertions(+), 1 deletion(-)
diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
index 3feeaa3f987a..2376d36ea573 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.
+ */
+#define DRM_FORMAT_MOD_ARM_CODE(__type, __val) \
+ fourcc_mod_code(ARM, ((__u64)(__type) << 52) | ((__val) &
0x000fULL))
+
+#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,16 @@ 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)
+
/*
* Allwinner tiled modifier
*
--
2.23.0
Re: [PATCH v2 RESEND] drm/komeda: Workaround for broken FLIP_COMPLETE timestamps
On Tue, Oct 01, 2019 at 02:21:40PM +, Mihail Atanassov wrote:
> When initially turning a crtc on, drm_reset_vblank_timestamp will
> set the vblank timestamp to 0 for any driver that doesn't provide
> a ->get_vblank_timestamp() hook.
>
> Unfortunately, the FLIP_COMPLETE event depends on that timestamp,
> and the only way to regenerate a valid one is to have vblank
> interrupts enabled and have a valid in-ISR call to
> drm_crtc_handle_vblank.
>
> Additionally, if the user doesn't request vblanks but _does_ request
> FLIP_COMPLETE events, we still don't have a good timestamp: it'll be the
> same stamp as the last vblank one.
>
> Work around the issue by always enabling vblanks when the CRTC is on.
> Reducing the amount of time that PL0 has to be unmasked would be nice to
> fix at a later time.
>
> Changes since v1 [https://patchwork.freedesktop.org/patch/331727/]:
> - moved drm_crtc_vblank_put call to the ->atomic_disable() hook
>
> Cc: Daniel Vetter
> Cc: Liviu Dudau
> Signed-off-by: Mihail Atanassov
> Reviewed-by: James Qian Wang (Arm Technology China)
Pushed to drm-misc-next f59769c52cd7d158df53487ec2936f5592073340
Thanks,
Ayan
> ---
> drivers/gpu/drm/arm/display/komeda/komeda_crtc.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_crtc.c
> b/drivers/gpu/drm/arm/display/komeda/komeda_crtc.c
> index 9ca5dbfd0723..75263d8cd0bd 100644
> --- a/drivers/gpu/drm/arm/display/komeda/komeda_crtc.c
> +++ b/drivers/gpu/drm/arm/display/komeda/komeda_crtc.c
> @@ -249,6 +249,7 @@ komeda_crtc_atomic_enable(struct drm_crtc *crtc,
> {
> komeda_crtc_prepare(to_kcrtc(crtc));
> drm_crtc_vblank_on(crtc);
> + WARN_ON(drm_crtc_vblank_get(crtc));
> komeda_crtc_do_flush(crtc, old);
> }
>
> @@ -341,6 +342,7 @@ komeda_crtc_atomic_disable(struct drm_crtc *crtc,
> komeda_crtc_flush_and_wait_for_flip_done(kcrtc, disable_done);
> }
>
> + drm_crtc_vblank_put(crtc);
> drm_crtc_vblank_off(crtc);
> komeda_crtc_unprepare(kcrtc);
> }
> --
> 2.23.0
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/komeda: Use IRQ_RETVAL shorthand in d71_irq_handler
On Mon, Sep 23, 2019 at 02:41:44AM +, james qian wang (Arm Technology China) wrote: > On Fri, Sep 20, 2019 at 03:13:08PM +, Mihail Atanassov wrote: > > No change in behaviour; IRQ_RETVAL is about twice as popular as > > manually writing out the ternary. > > > > Signed-off-by: Mihail Atanassov > > --- > > drivers/gpu/drm/arm/display/komeda/d71/d71_dev.c | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git a/drivers/gpu/drm/arm/display/komeda/d71/d71_dev.c > > b/drivers/gpu/drm/arm/display/komeda/d71/d71_dev.c > > index d567ab7ed314..1b42095969e7 100644 > > --- a/drivers/gpu/drm/arm/display/komeda/d71/d71_dev.c > > +++ b/drivers/gpu/drm/arm/display/komeda/d71/d71_dev.c > > @@ -195,7 +195,7 @@ d71_irq_handler(struct komeda_dev *mdev, struct > > komeda_events *evts) > > if (gcu_status & GLB_IRQ_STATUS_PIPE1) > > evts->pipes[1] |= get_pipeline_event(d71->pipes[1], gcu_status); > > > > - return gcu_status ? IRQ_HANDLED : IRQ_NONE; > > + return IRQ_RETVAL(gcu_status); > > Hi Mihail: > > Thank you for the patch. > > Reviewed-by: James Qian Wang (Arm Technology China) Pushed to drm-misc-next - 4b39582a8fb3c749f0fa96ec920d138f61bf00d6 > > > } > > > > #define ENABLED_GCU_IRQS (GCU_IRQ_CVAL0 | GCU_IRQ_CVAL1 | \ > > -- > > 2.23.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 v2] drm/fourcc: Add Arm 16x16 block modifier
On Mon, Sep 30, 2019 at 05:02:37PM +, Brian Starkey wrote:
> Hi Ayan,
>
> Could we preserve Ray's authorship on this patch?
Apologies for this, I will definitely preserve Ray's authorship in the
v3 patch.
>
> On Mon, Sep 30, 2019 at 04:44:38PM +0000, 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,
I will wait for dan...@ffwll.ch and yuq...@gmail.com comments before
respinning the patch.
> -Brian
>
> > /*
> > * Allwinner tiled modifier
> > *
> > --
> > 2.23.0
> >
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2] drm/fourcc: Add Arm 16x16 block modifier
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.
+ */
+#define DRM_FORMAT_MOD_ARM_CODE(type, val) \
+ fourcc_mod_code(ARM, ((__u64)type << 52) | ((val) &
0x000fULL))
+
+#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)
+
+
/*
* 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] drm/fourcc: Add Arm 16x16 block modifier
On Fri, Sep 20, 2019 at 10:15:41AM +0800, Qiang Yu wrote:
> Hi guys,
>
> I'd like to know the status of this patch? I expect a v2 adding some
> comments/macros about the high bit plan would be enough?
>
> @Raymond & @Brian do you still need another long process to send out a
> v2 patch? If so, I can help to prepare a v2 patch according to your
> previous mail.
Apologies for the long wait.
@Raymond has left the company, so now I will be looking into it. I
will respin the patch in a day or two.
> Thanks,
> Qiang
>
> On Thu, Jun 27, 2019 at 3:30 AM Daniel Vetter wrote:
> >
> > On Mon, Jun 24, 2019 at 1:23 PM Brian Starkey wrote:
> > >
> > > On Mon, Jun 24, 2019 at 11:58:59AM +0200, Daniel Vetter wrote:
> > > > On Mon, Jun 24, 2019 at 11:32 AM Brian Starkey
> > > > wrote:
> > > > >
> > > > > Hi Daniel,
> > > > >
> > > > > On Fri, Jun 21, 2019 at 05:27:00PM +0200, Daniel Vetter wrote:
> > > > > > On Fri, Jun 21, 2019 at 12:21 PM Raymond Smith
> > > > > > 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.
> > > > > > >
> > > > > > > Signed-off-by: Raymond Smith
> > > > > > > ---
> > > > > > > include/uapi/drm/drm_fourcc.h | 10 ++
> > > > > > > 1 file changed, 10 insertions(+)
> > > > > > >
> > > > > > > diff --git a/include/uapi/drm/drm_fourcc.h
> > > > > > > b/include/uapi/drm/drm_fourcc.h
> > > > > > > index 3feeaa3..8ed7ecf 100644
> > > > > > > --- a/include/uapi/drm/drm_fourcc.h
> > > > > > > +++ b/include/uapi/drm/drm_fourcc.h
> > > > > > > @@ -743,6 +743,16 @@ 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 \
> > > > > > > + fourcc_mod_code(ARM, ((1ULL << 55) | 1))
> > > > > >
> > > > > > This seems to be an extremely random pick for a new number. What's
> > > > > > the
> > > > > > thinking here? Aside from "doesnt match any of the afbc combos" ofc.
> > > > > > If you're already up to having thrown away 55bits, then it's not
> > > > > > going
> > > > > > to last long really :-)
> > > > > >
> > > > > > I think a good idea would be to reserve a bunch of the high bits as
> > > > > > some form of index (afbc would get index 0 for backwards compat).
> > > > > > And
> > > > > > then the lower bits would be for free use for a given index/mode.
> > > > > > And
> > > > > > the first mode is probably an enumeration, where possible modes
> > > > > > simple
> > > > > > get enumerated without further flags or anything.
> > > > >
> > > > > Yup, that's the plan:
> > > > >
> > > > > (0 << 55): AFBC
> > > > > (1 << 55): This "non-category" for U-Interleaved
> > > > > (1 << 54): Whatever the next category is
> > > > > (3 << 54): Whatever comes after that
> > > > > (1 << 53): Maybe we'll get here someday
> > > >
> > > > Uh, so the index would be encoded with least-significant bit first,
> > > > starting from bit55 downwards?
> > >
> > > Yeah.
> > >
> > > > Clever idea, but I think this needs a
> > > > macro (or at least a comment). Not sure there's a ready-made bitmask
> > > > mirror function for this stuff, works case we can hand-code it and
> > > > extend every time we need one more bit encoded. Something like:
> > > >
> > > > MIRROR_U32((u & (BIT(0)) << 31 | (u & BIT(1) << 30 | ...)
> > > >
> > >
> > > Is it really worth it? People can just use the definitions as written
> > > in drm_fourcc.h. I agree that we should have the high bits described
> > > in a comment though.
> > >
> > > > And then shift that to the correct place. Probably want an
> > > >
> > > > ARM_MODIFIER_ENCODE(space_idx, flags) macro which assembles everything.
> > > >
> > > > > ...
> > > > >
> > > > > I didn't want to explicitly reserve some high bits, because we've no
> > > > > idea how many to reserve. This way, we can assign exactly as many
> > > > > high bits as we need, when we need them. If any of the "modes" start
> > > > > encroaching towards the high bits, we'll have to make a decision at
> > > > > that point.
> > > > >
> > > > > Also, this is the only U-Interleaved format (that I know of), so it's
> > > > > not worth calling bit 55 "The U-Interleaved bit" because that would be
> > > > > a waste of space. It's more like the "misc" bit, but that's not a
> > > > > useful name to enshrine in UAPI.
> > > >
> > > > Yeah that's what I meant. Also better to explicitly reserve this, i.e.
> > > >
> > > > #define ARM_FBC_MODIFIER_SPACE 0
> > > >
Re: [RFC PATCH] drm:- Add a modifier to denote 'protected' framebuffer
On Mon, Sep 30, 2019 at 09:51:35AM +, Brian Starkey wrote: > 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". Clear
Re: [PATCH] drm/rockchip: Add AFBC support
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;
> + }
> +
I think you are missing one additional check here.
framebuffer width and height should be aligned to 16 pixels as you are
using AFBC_FORMAT_MOD_BLOCK_SIZE_16x16.
Please have a look at malidp_verify_afbc_framebuffer_caps()
> + 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)
> +{
> + switch (format) {
> + case DRM_FORMAT_XRGB:
> + case DRM_FORMAT_ARGB:
> + case DRM_FORMAT_XBGR:
> + case DRM_FORMAT_ABGR:
> + return AFBC_FMT_U8U8U8U8;
> + case DRM_FORMAT_RGB888:
> + case DRM_FORMAT_BGR888:
> + return AFBC_FMT_U8U8U8;
> + case DRM_FORMAT_RGB565:
> + case DRM_FORMAT_BGR565:
> + return AFBC_FMT_RGB565;
> + default:
> + DRM_ERROR("unsupported afbc format[%08x]\n", format);
> + return -EINVAL;
> + }
> +}
> +
> static enum vop_data_format vop_convert_format(uint32_t format)
> {
> switch (format) {
> @@ -587,10 +620,16 @@ static int vop_enable(struct drm_crtc *crtc)
>
> vop_win_disable(vop, win);
> }
> - spin_unlock(>reg_lock);
> +
> + if (vop->data->afbc) {
> + VOP_AFBC_SET(vop, enable, 0);
> + vop->afbc_win = NULL;
> + }
>
> vop_cfg_done(vop);
>
Re: [PATCH] drm/rockchip: Add AFBC support
On Mon, Sep 23, 2019 at 05:34:14PM +0200, Andrzej Pietrasiewicz wrote:
> Dear All,
>
> As a result of my mistake I've sent this patch with an incorrect SOB chain.
> Please kindly disregard this patch.
>
> @Neil: thank you for your time you spent reviewing it and answering and I'm
> sorry it's to no effect.
> @Ezequiel, @Tomeu: I apologize to you. My mistake.
>
> Regards,
>
> Andrzej Pietrasiewicz
>
>
> W dniu 23.09.2019 o 15:53, Neil Armstrong pisze:
> >On 23/09/2019 14:20, 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/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
> >>index 3feeaa3f987a..ba6caf06c824 100644
> >>--- a/include/uapi/drm/drm_fourcc.h
> >>+++ b/include/uapi/drm/drm_fourcc.h
> >>@@ -742,6 +742,9 @@ extern "C" {
> >> */
> >> #define AFBC_FORMAT_MOD_BCH (1ULL << 11)
> >>+#define AFBC_FORMAT_MOD_ROCKCHIP \
> >>+ (AFBC_FORMAT_MOD_BLOCK_SIZE_16x16 | AFBC_FORMAT_MOD_SPARSE)
> >
> >This define looks useless, what's Rockchip specific here ?
> >
Please reuse the existing AFBC modifiers.
Have a look at malidp_format_modifiers[] in which we have defined
the modifiers(for our driver) we are using.
In your case, it will be
DRM_FORMAT_MOD_ARM_AFBC(AFBC_FORMAT_MOD_BLOCK_SIZE_16x16|AFBC_FORMAT_MOD_SPARSE)
> >Neil
> >
> >>+
> >> /*
> >> * Allwinner tiled modifier
> >> *
> >>
> >
>
> ___
> 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, Sep 19, 2019 at 10:21:52PM +0530, Sumit Semwal wrote:
> Hello Christoph, everyone,
>
> On Sat, 7 Sep 2019 at 00:17, 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.
> >
> > Most of the changes in this revision are adddressing the more
> > concrete feedback from Christoph (many thanks!). Though I'm not
> > sure if some of the less specific feedback was completely resolved
> > in discussion last time around. Please let me know!
>
> It looks like most of the feedback has been taken care of. If there's
> no more objection to this series, I'd like to merge it in soon.
>
> If there are any more review comments, may I request you to please provide
> them?
I tested these patches using our internal test suite with Arm,komeda
driver and the following node in dts
reserved-memory {
#address-cells = <0x2>;
#size-cells = <0x2>;
ranges;
framebuffer@6000 {
compatible = "shared-dma-pool";
linux,cma-default;
reg = <0x0 0x6000 0x0 0x800>;
};
}
The tests went fine. Our tests allocates framebuffers of different
sizes, posts them on screen and the driver writes back to one of the
framebuffers. I havenot tested for any performance, latency or
cache management related stuff. So, it that looks appropriate, feel
free to add:-
Tested-by:- Ayan Kumar Halder
Are you planning to write some igt tests for it ?
>
> >
> > New in v8:
> > * Make struct dma_heap_ops consts (Suggested by Christoph)
> > * Add flush_kernel_vmap_range/invalidate_kernel_vmap_range calls
> > (suggested by Christoph)
> > * Condense dma_heap_buffer and heap_helper_buffer (suggested by
> > Christoph)
> > * Get rid of needless struct system_heap (suggested by Christoph)
> > * Fix indentation by using shorter argument names (suggested by
> > Christoph)
> > * Remove unused private_flags value
> > * Add forgotten include file to fix build issue on x86
> > * Checkpatch whitespace fixups
> >
> > Thoughts and feedback would be greatly appreciated!
> >
> > thanks
> > -john
> Best,
> Sumit.
> >
> > 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
> >
> >
> > 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 | 164 +++
> > drivers/dma-buf/heaps/heap-helpers.c | 269 ++
> > 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 | 230 +++
> > 14 files changed, 1262
Re: [PATCH 01/36] drm/fourcc: Add 2 plane YCbCr 10bit format support
On Tue, Sep 24, 2019 at 02:46:09PM +0800, sandy.huang wrote:
Hi Sandy,
>
> 在 2019/9/23 下午9:06, Daniel Vetter 写道:
> >On Mon, Sep 23, 2019 at 2:40 PM Sandy Huang wrote:
> >>The drm_format_info.cpp[3] unit is BytePerPlane, when we add define
> >>10bit YUV format, here have some problem.
> >>So we change cpp to bpp, use unit BitPerPlane to describe the data
> >>format.
> >>
> >>Signed-off-by: Sandy Huang
> >Whatever the layout you have for these (it's not really defined in
> >your patch here down to the level of detail we want) I think this
> >should be described with the block_h/w and char_per_block
> >functionality. Not by extending the legacy and depcrecated cpp
> >somehow.
> >-Daniel
>
> Hi Daniel,
>
> It seems the char_per_block and block_h/w can't describing the following
> data format:
>
> /*
> * 2x2 subsampled Cr:Cb plane 10 bits per channel
> * index 0 = Y plane, [9:0]
> * index 1 = Cr:Cb plane, [19:0] Cr:x:Cb:x [19:0]
> */
In that case, you can follow the same route which we took for
describing formats like DRM_FORMAT_VUY101010, DRM_FORMAT_YUV420_8BIT,
DRM_FORMAT_YUV420_10BIT ie define cpp as {0, 0, 0} and in your
vendor driver have a function similar to malidp_format_get_bpp().
It does not look nice to me to change all the formats described
in cpp to bpp for just one vendor specific format.
Thanks,
Ayan
> >>---
> >> drivers/gpu/drm/drm_client.c| 4 +-
> >> drivers/gpu/drm/drm_fb_helper.c | 8 +-
> >> drivers/gpu/drm/drm_format_helper.c | 4 +-
> >> drivers/gpu/drm/drm_fourcc.c| 172
> >> +++-
> >> drivers/gpu/drm/drm_framebuffer.c | 2 +-
> >> include/drm/drm_fourcc.h| 4 +-
> >> include/uapi/drm/drm_fourcc.h | 15
> >> 7 files changed, 115 insertions(+), 94 deletions(-)
> >>
> >>diff --git a/drivers/gpu/drm/drm_client.c b/drivers/gpu/drm/drm_client.c
> >>index d9a2e36..a36ffbe 100644
> >>--- a/drivers/gpu/drm/drm_client.c
> >>+++ b/drivers/gpu/drm/drm_client.c
> >>@@ -263,7 +263,7 @@ drm_client_buffer_create(struct drm_client_dev *client,
> >>u32 width, u32 height, u
> >>
> >> dumb_args.width = width;
> >> dumb_args.height = height;
> >>- dumb_args.bpp = info->cpp[0] * 8;
> >>+ dumb_args.bpp = info->bpp[0];
> >> ret = drm_mode_create_dumb(dev, _args, client->file);
> >> if (ret)
> >> goto err_delete;
> >>@@ -366,7 +366,7 @@ static int drm_client_buffer_addfb(struct
> >>drm_client_buffer *buffer,
> >> int ret;
> >>
> >> info = drm_format_info(format);
> >>- fb_req.bpp = info->cpp[0] * 8;
> >>+ fb_req.bpp = info->bpp[0];
> >> fb_req.depth = info->depth;
> >> fb_req.width = width;
> >> fb_req.height = height;
> >>diff --git a/drivers/gpu/drm/drm_fb_helper.c
> >>b/drivers/gpu/drm/drm_fb_helper.c
> >>index a7ba5b4..b30e782 100644
> >>--- a/drivers/gpu/drm/drm_fb_helper.c
> >>+++ b/drivers/gpu/drm/drm_fb_helper.c
> >>@@ -382,7 +382,7 @@ static void drm_fb_helper_dirty_blit_real(struct
> >>drm_fb_helper *fb_helper,
> >> struct drm_clip_rect *clip)
> >> {
> >> struct drm_framebuffer *fb = fb_helper->fb;
> >>- unsigned int cpp = fb->format->cpp[0];
> >>+ unsigned int cpp = fb->format->bpp[0] / 8;
> >> size_t offset = clip->y1 * fb->pitches[0] + clip->x1 * cpp;
> >> void *src = fb_helper->fbdev->screen_buffer + offset;
> >> void *dst = fb_helper->buffer->vaddr + offset;
> >>@@ -1320,14 +1320,14 @@ int drm_fb_helper_check_var(struct
> >>fb_var_screeninfo *var,
> >> * Changes struct fb_var_screeninfo are currently not pushed back
> >> * to KMS, hence fail if different settings are requested.
> >> */
> >>- if (var->bits_per_pixel != fb->format->cpp[0] * 8 ||
> >>+ if (var->bits_per_pixel != fb->format->bpp[0] ||
> >> var->xres > fb->width || var->yres > fb->height ||
> >> var->xres_virtual > fb->width || var->yres_virtual >
> >> fb->height) {
> >> DRM_DEBUG("fb requested width/height/bpp can't fit in
> >> current fb "
> >> "request %dx%d-%d (virtual %dx%d) > %dx%d-%d\n",
> >> var->xres, var->yres, var->bits_per_pixel,
> >> var->xres_virtual, var->yres_virtual,
> >>- fb->width, fb->height, fb->format->cpp[0] * 8);
> >>+ fb->width, fb->height, fb->format->bpp[0]);
> >> return -EINVAL;
> >> }
> >>
> >>@@ -1678,7 +1678,7 @@ static void drm_fb_helper_fill_var(struct fb_info
> >>*info,
> >> info->pseudo_palette = fb_helper->pseudo_palette;
> >> info->var.xres_virtual = fb->width;
> >> info->var.yres_virtual = fb->height;
> >>- info->var.bits_per_pixel = fb->format->cpp[0] * 8;
> >>+ info->var.bits_per_pixel = fb->format->bpp[0];
> >>
Re: [RFC PATCH] drm:- Add a modifier to denote 'protected' framebuffer
On Thu, Sep 19, 2019 at 04:10:42PM +0200, Daniel Vetter wrote:
> On Thu, Sep 19, 2019 at 4:03 PM Ayan Halder wrote:
> >
> > On Wed, Sep 18, 2019 at 10:30:12PM +0100, Daniel Stone wrote:
> >
> > Hi All,
> > Thanks for your suggestions.
> >
> > > Hi Liviu,
> > >
> > > On Wed, 18 Sep 2019 at 13:04, Liviu Dudau wrote:
> > > > On Wed, Sep 18, 2019 at 09:49:40AM +0100, Daniel Stone wrote:
> > > > > I totally agree. Framebuffers aren't about the underlying memory they
> > > > > point to, but about how to _interpret_ that memory: it decorates a
> > > > > pointer with width, height, stride, format, etc, to allow you to make
> > > > > sense of that memory. I see content protection as being the same as
> > > > > physical contiguity, which is a property of the underlying memory
> > > > > itself. Regardless of the width, height, or format, you just cannot
> > > > > access that memory unless it's under the appropriate ('secure enough')
> > > > > conditions.
> > > > >
> > > > > So I think a dmabuf attribute would be most appropriate, since that's
> > > > > where you have to do all your MMU handling, and everything else you
> > > > > need to do to allow access to that buffer, anyway.
> > > >
> > > > Isn't it how AMD currently implements protected buffers as well?
> > >
> > > No idea to be honest, I haven't seen anything upstream.
> > >
> > > > > There's a lot of complexity beyond just 'it's protected'; for
> > > > > instance, some CP providers mandate that their content can only be
> > > > > streamed over HDCP 2.2 Type-1 when going through an external
> > > > > connection. One way you could do that is to use a secure world
> > > > > (external controller like Intel's ME, or CPU-internal enclave like SGX
> > > > > or TEE) to examine the display pipe configuration, and only then allow
> > > > > access to the buffers and/or keys. Stuff like that is always going to
> > > > > be out in the realm of vendor & product-policy-specific add-ons, but
> > > > > it should be possible to agree on at least the basic mechanics and
> > > > > expectations of a secure path without things like that.
> > > >
> > > > I also expect that going through the secure world will be pretty much
> > > > transparent for
> > > > the kernel driver, as the most likely hardware implementations would
> > > > enable
> > > > additional signaling that will get trapped and handled by the secure
> > > > OS. I'm not
> > > > trying to simplify things, just taking the stance that it is userspace
> > > > that is
> > > > coordinating all this, we're trying only to find a common ground on how
> > > > to handle
> > > > this in the kernel.
> > >
> > > Yeah, makes sense.
> > >
> > > As a strawman, how about a new flag to drmPrimeHandleToFD() which sets
> > > the 'protected' flag on the resulting dmabuf?
> >
> > To be honest, during our internal discussion james.qian.w...@arm.com had a
> > similar suggestion of adding a new flag to dma_buf but I decided
> > against it.
> >
> > As per my understanding, adding custom dma buf flags (like
> > AMDGPU_GEM_CREATE_XXX, etc) is possible if we(Arm) had our own allocator. We
> > rely on the dumb allocator and ion allocator for framebuffer creation.
> >
> > I was looking at an allocator independent way of userspace
> > communicating to the drm framework that the framebuffer is protected.
> >
> > Thus, it looked to me that framebuffer modifier is the best (or the least
> > corrupt) way of going forth.
> >
> > We use ion and dumb allocator for framebuffer object creation. The way
> > I see it is as follows :-
> >
> > 1. For ion allocator :-
> > Userspace can specify that it wants the buffer from a secure heap or any
> > other
> > special region of heap. The ion driver will either fault into the secure os
> > to
> > create the buffers or it will do some other magic. Honestly, I have still
> > not
> > figured that out. But it will be agnostic to the drm core.
>
> Allocating buffers from a special heap is what I expected the
> interface to be. The issue is that if we specify the secure mode any
> time later on, then it could be changed. E.g. with Daniel Stone's idea
> of a handle2fd flag, you could export the buffer twi
Re: [RFC PATCH] drm:- Add a modifier to denote 'protected' framebuffer
On Wed, Sep 18, 2019 at 10:30:12PM +0100, Daniel Stone wrote:
Hi All,
Thanks for your suggestions.
> Hi Liviu,
>
> On Wed, 18 Sep 2019 at 13:04, Liviu Dudau wrote:
> > On Wed, Sep 18, 2019 at 09:49:40AM +0100, Daniel Stone wrote:
> > > I totally agree. Framebuffers aren't about the underlying memory they
> > > point to, but about how to _interpret_ that memory: it decorates a
> > > pointer with width, height, stride, format, etc, to allow you to make
> > > sense of that memory. I see content protection as being the same as
> > > physical contiguity, which is a property of the underlying memory
> > > itself. Regardless of the width, height, or format, you just cannot
> > > access that memory unless it's under the appropriate ('secure enough')
> > > conditions.
> > >
> > > So I think a dmabuf attribute would be most appropriate, since that's
> > > where you have to do all your MMU handling, and everything else you
> > > need to do to allow access to that buffer, anyway.
> >
> > Isn't it how AMD currently implements protected buffers as well?
>
> No idea to be honest, I haven't seen anything upstream.
>
> > > There's a lot of complexity beyond just 'it's protected'; for
> > > instance, some CP providers mandate that their content can only be
> > > streamed over HDCP 2.2 Type-1 when going through an external
> > > connection. One way you could do that is to use a secure world
> > > (external controller like Intel's ME, or CPU-internal enclave like SGX
> > > or TEE) to examine the display pipe configuration, and only then allow
> > > access to the buffers and/or keys. Stuff like that is always going to
> > > be out in the realm of vendor & product-policy-specific add-ons, but
> > > it should be possible to agree on at least the basic mechanics and
> > > expectations of a secure path without things like that.
> >
> > I also expect that going through the secure world will be pretty much
> > transparent for
> > the kernel driver, as the most likely hardware implementations would enable
> > additional signaling that will get trapped and handled by the secure OS.
> > I'm not
> > trying to simplify things, just taking the stance that it is userspace that
> > is
> > coordinating all this, we're trying only to find a common ground on how to
> > handle
> > this in the kernel.
>
> Yeah, makes sense.
>
> As a strawman, how about a new flag to drmPrimeHandleToFD() which sets
> the 'protected' flag on the resulting dmabuf?
To be honest, during our internal discussion james.qian.w...@arm.com had a
similar suggestion of adding a new flag to dma_buf but I decided
against it.
As per my understanding, adding custom dma buf flags (like
AMDGPU_GEM_CREATE_XXX, etc) is possible if we(Arm) had our own allocator. We
rely on the dumb allocator and ion allocator for framebuffer creation.
I was looking at an allocator independent way of userspace
communicating to the drm framework that the framebuffer is protected.
Thus, it looked to me that framebuffer modifier is the best (or the least
corrupt) way of going forth.
We use ion and dumb allocator for framebuffer object creation. The way
I see it is as follows :-
1. For ion allocator :-
Userspace can specify that it wants the buffer from a secure heap or any other
special region of heap. The ion driver will either fault into the secure os to
create the buffers or it will do some other magic. Honestly, I have still not
figured that out. But it will be agnostic to the drm core.
The userspace gets a handle to the buffer and then it calls addFB2 with
DRM_FORMAT_MOD_ARM_PROTECTED, so that the driver can configure the
dpu's protection bits (to access the memory with special signals).
2. For dumb allocator :-
I am curious to know if we can add 'IS_PROTECTED' flag to
drm_mode_create_dumb.flags. This can/might be used to set dma_buf
flags. Let me know if this is an incorrect/forbidden path.
In a nutshell, my objective is to figure out if the userspace is able
to communicate to the drm core about the 'protection' status of the
buffer without introducing Arm specific buffer allocator.
Thanks,
Ayan
> Cheers,
> Daniel
[RFC PATCH] drm:- Add a modifier to denote 'protected' framebuffer
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.
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.
--/
---
include/uapi/drm/drm_fourcc.h | 9 +
1 file changed, 9 insertions(+)
diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
index 3feeaa3f987a..38e5e81d11fe 100644
--- a/include/uapi/drm/drm_fourcc.h
+++ b/include/uapi/drm/drm_fourcc.h
@@ -742,6 +742,15 @@ extern "C" {
*/
#define AFBC_FORMAT_MOD_BCH (1ULL << 11)
+/*
+ * Protected framebuffer
+ *
+ * The framebuffer is allocated in a protected system memory which can be
accessed
+ * via some special hardware signals from the dpu. This is used to support
+ * 'GRALLOC_USAGE_PROTECTED' in our framebuffer for EGL_EXT_protected_content.
+ */
+#define DRM_FORMAT_MOD_ARM_PROTECTED fourcc_mod_code(ARM, (1ULL << 55))
+
/*
* Allwinner tiled modifier
*
--
2.23.0
Re: [PATCH] drm/komeda: Add ACLK rate to sysfs
On Wed, Aug 28, 2019 at 02:15:15PM +, james qian wang (Arm Technology
China) wrote:
> Hi Mihail:
>
> Looks good to me.
>
> Reviewed-by: James Qian Wang (Arm Technology China)
>
Pushed to drm-misc-next 5fcd055193c5d4cac6d205bd65e52c957ea057c2
And that verifies my new dim setup. :)
> James.
>
> On Wed, Aug 28, 2019 at 11:03:49AM +, Mihail Atanassov wrote:
> > Expose node with the name 'aclk_hz'
> >
> > Signed-off-by: Mihail Atanassov
> > ---
> > drivers/gpu/drm/arm/display/komeda/komeda_dev.c | 10 ++
> > 1 file changed, 10 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_dev.c
> > b/drivers/gpu/drm/arm/display/komeda/komeda_dev.c
> > index 0142ee991957..e8d67395a3b9 100644
> > --- a/drivers/gpu/drm/arm/display/komeda/komeda_dev.c
> > +++ b/drivers/gpu/drm/arm/display/komeda/komeda_dev.c
> > @@ -91,9 +91,19 @@ config_id_show(struct device *dev, struct
> > device_attribute *attr, char *buf)
> > }
> > static DEVICE_ATTR_RO(config_id);
> >
> > +static ssize_t
> > +aclk_hz_show(struct device *dev, struct device_attribute *attr, char *buf)
> > +{
> > + struct komeda_dev *mdev = dev_to_mdev(dev);
> > +
> > + return snprintf(buf, PAGE_SIZE, "%lu\n", clk_get_rate(mdev->aclk));
> > +}
> > +static DEVICE_ATTR_RO(aclk_hz);
> > +
> > static struct attribute *komeda_sysfs_entries[] = {
> > _attr_core_id.attr,
> > _attr_config_id.attr,
> > + _attr_aclk_hz.attr,
> > NULL,
> > };
> >
> > --
> > 2.22.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 v2] drm/komeda: Reordered the komeda's de-init functions
On Wed, Aug 28, 2019 at 03:58:12PM +, james qian wang (Arm Technology
China) wrote:
> On Wed, Aug 28, 2019 at 03:00:19PM +0000, Ayan Halder wrote:
> > From: Ayan Halder
> >
> > The de-init routine should be doing the following in order:-
> > 1. Unregister the drm device
> > 2. Shut down the crtcs - failing to do this might cause a connector leakage
> > See the 'commit 109c4d18e574 ("drm/arm/malidp: Ensure that the crtcs are
> > shutdown before removing any encoder/connector")'
> > 3. Disable the interrupts
> > 4. Unbind the components
> > 5. Free up DRM mode_config info
> >
> > Changes from v1:-
> > 1. Re-ordered the header files inclusion
> > 2. Rebased on top of the latest drm-misc-fixes
> >
> > Signed-off-by: Ayan Kumar Halder
> > Reviewed-by: Mihail Atanassov
>
> Looks good to me.
>
> Reviewed-by: James Qian Wang (Arm Technology China)
>
Pushed to drm-misc-fixes - 6978bce054247e4cfccdf689ce263e076499f905
> > ---
> > .../gpu/drm/arm/display/komeda/komeda_kms.c | 23 ---
> > 1 file changed, 15 insertions(+), 8 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_kms.c
> > b/drivers/gpu/drm/arm/display/komeda/komeda_kms.c
> > index 1f0e3f4e8d74..69d9e26c60c8 100644
> > --- a/drivers/gpu/drm/arm/display/komeda/komeda_kms.c
> > +++ b/drivers/gpu/drm/arm/display/komeda/komeda_kms.c
> > @@ -14,8 +14,8 @@
> > #include
> > #include
> > #include
> > -#include
> > #include
> > +#include
> >
> > #include "komeda_dev.h"
> > #include "komeda_framebuffer.h"
> > @@ -306,11 +306,11 @@ struct komeda_kms_dev *komeda_kms_attach(struct
> > komeda_dev *mdev)
> >komeda_kms_irq_handler, IRQF_SHARED,
> >drm->driver->name, drm);
> > if (err)
> > - goto cleanup_mode_config;
> > + goto free_component_binding;
> >
> > err = mdev->funcs->enable_irq(mdev);
> > if (err)
> > - goto cleanup_mode_config;
> > + goto free_component_binding;
> >
> > drm->irq_enabled = true;
> >
> > @@ -318,15 +318,21 @@ struct komeda_kms_dev *komeda_kms_attach(struct
> > komeda_dev *mdev)
> >
> > err = drm_dev_register(drm, 0);
> > if (err)
> > - goto cleanup_mode_config;
> > + goto free_interrupts;
> >
> > return kms;
> >
> > -cleanup_mode_config:
> > +free_interrupts:
> > drm_kms_helper_poll_fini(drm);
> > drm->irq_enabled = false;
> > + mdev->funcs->disable_irq(mdev);
> > +free_component_binding:
> > + component_unbind_all(mdev->dev, drm);
> > +cleanup_mode_config:
> > drm_mode_config_cleanup(drm);
> > komeda_kms_cleanup_private_objs(kms);
> > + drm->dev_private = NULL;
> > + drm_dev_put(drm);
> > free_kms:
> > kfree(kms);
> > return ERR_PTR(err);
> > @@ -337,13 +343,14 @@ void komeda_kms_detach(struct komeda_kms_dev *kms)
> > struct drm_device *drm = >base;
> > struct komeda_dev *mdev = drm->dev_private;
> >
> > - drm->irq_enabled = false;
> > - mdev->funcs->disable_irq(mdev);
> > drm_dev_unregister(drm);
> > drm_kms_helper_poll_fini(drm);
> > + drm_atomic_helper_shutdown(drm);
> > + drm->irq_enabled = false;
> > + mdev->funcs->disable_irq(mdev);
> > component_unbind_all(mdev->dev, drm);
> > - komeda_kms_cleanup_private_objs(kms);
> > drm_mode_config_cleanup(drm);
> > + komeda_kms_cleanup_private_objs(kms);
> > drm->dev_private = NULL;
> > drm_dev_put(drm);
> > }
> > --
> > 2.21.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2] drm/komeda: Reordered the komeda's de-init functions
From: Ayan Halder
The de-init routine should be doing the following in order:-
1. Unregister the drm device
2. Shut down the crtcs - failing to do this might cause a connector leakage
See the 'commit 109c4d18e574 ("drm/arm/malidp: Ensure that the crtcs are
shutdown before removing any encoder/connector")'
3. Disable the interrupts
4. Unbind the components
5. Free up DRM mode_config info
Changes from v1:-
1. Re-ordered the header files inclusion
2. Rebased on top of the latest drm-misc-fixes
Signed-off-by: Ayan Kumar Halder
Reviewed-by: Mihail Atanassov
---
.../gpu/drm/arm/display/komeda/komeda_kms.c | 23 ---
1 file changed, 15 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_kms.c
b/drivers/gpu/drm/arm/display/komeda/komeda_kms.c
index 1f0e3f4e8d74..69d9e26c60c8 100644
--- a/drivers/gpu/drm/arm/display/komeda/komeda_kms.c
+++ b/drivers/gpu/drm/arm/display/komeda/komeda_kms.c
@@ -14,8 +14,8 @@
#include
#include
#include
-#include
#include
+#include
#include "komeda_dev.h"
#include "komeda_framebuffer.h"
@@ -306,11 +306,11 @@ struct komeda_kms_dev *komeda_kms_attach(struct
komeda_dev *mdev)
komeda_kms_irq_handler, IRQF_SHARED,
drm->driver->name, drm);
if (err)
- goto cleanup_mode_config;
+ goto free_component_binding;
err = mdev->funcs->enable_irq(mdev);
if (err)
- goto cleanup_mode_config;
+ goto free_component_binding;
drm->irq_enabled = true;
@@ -318,15 +318,21 @@ struct komeda_kms_dev *komeda_kms_attach(struct
komeda_dev *mdev)
err = drm_dev_register(drm, 0);
if (err)
- goto cleanup_mode_config;
+ goto free_interrupts;
return kms;
-cleanup_mode_config:
+free_interrupts:
drm_kms_helper_poll_fini(drm);
drm->irq_enabled = false;
+ mdev->funcs->disable_irq(mdev);
+free_component_binding:
+ component_unbind_all(mdev->dev, drm);
+cleanup_mode_config:
drm_mode_config_cleanup(drm);
komeda_kms_cleanup_private_objs(kms);
+ drm->dev_private = NULL;
+ drm_dev_put(drm);
free_kms:
kfree(kms);
return ERR_PTR(err);
@@ -337,13 +343,14 @@ void komeda_kms_detach(struct komeda_kms_dev *kms)
struct drm_device *drm = >base;
struct komeda_dev *mdev = drm->dev_private;
- drm->irq_enabled = false;
- mdev->funcs->disable_irq(mdev);
drm_dev_unregister(drm);
drm_kms_helper_poll_fini(drm);
+ drm_atomic_helper_shutdown(drm);
+ drm->irq_enabled = false;
+ mdev->funcs->disable_irq(mdev);
component_unbind_all(mdev->dev, drm);
- komeda_kms_cleanup_private_objs(kms);
drm_mode_config_cleanup(drm);
+ komeda_kms_cleanup_private_objs(kms);
drm->dev_private = NULL;
drm_dev_put(drm);
}
--
2.21.0
Re: [PATCH] drm/komeda: Add missing of_node_get() call
On Fri, Aug 23, 2019 at 01:43:49PM +, Ayan Halder wrote:
> On Tue, Aug 20, 2019 at 03:16:58PM +, Mihail Atanassov wrote:
> > komeda_pipeline_destroy has the matching of_node_put().
> >
> > Fixes: 29e56aec911dd ("drm/komeda: Add DT parsing")
> > Signed-off-by: Mihail Atanassov
> > ---
> > drivers/gpu/drm/arm/display/komeda/komeda_dev.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_dev.c
> > b/drivers/gpu/drm/arm/display/komeda/komeda_dev.c
> > index 0142ee991957..ca64a129c594 100644
> > --- a/drivers/gpu/drm/arm/display/komeda/komeda_dev.c
> > +++ b/drivers/gpu/drm/arm/display/komeda/komeda_dev.c
> > @@ -130,7 +130,7 @@ static int komeda_parse_pipe_dt(struct komeda_dev
> > *mdev, struct device_node *np)
> > of_graph_get_port_by_id(np, KOMEDA_OF_PORT_OUTPUT);
> >
> > pipe->dual_link = pipe->of_output_links[0] && pipe->of_output_links[1];
> > - pipe->of_node = np;
> > + pipe->of_node = of_node_get(np);
> >
>
> Good catch.
> Reviewed-by: Ayan Kumar Halder
> > return 0;
> > }
> > --
Pushed to drm-misc-fixes - 51a44a28eefd0d4c1addeb23fc5a599ff1787dfd
Apologies, I accidently pushed the gerrit change-id in the commit
message. Surprisingly, "checkpatch.pl --strict" did not catch the issue.
> > 2.22.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
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/komeda: Add missing of_node_get() call
On Tue, Aug 20, 2019 at 03:16:58PM +, Mihail Atanassov wrote:
> komeda_pipeline_destroy has the matching of_node_put().
>
> Fixes: 29e56aec911dd ("drm/komeda: Add DT parsing")
> Signed-off-by: Mihail Atanassov
> ---
> drivers/gpu/drm/arm/display/komeda/komeda_dev.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_dev.c
> b/drivers/gpu/drm/arm/display/komeda/komeda_dev.c
> index 0142ee991957..ca64a129c594 100644
> --- a/drivers/gpu/drm/arm/display/komeda/komeda_dev.c
> +++ b/drivers/gpu/drm/arm/display/komeda/komeda_dev.c
> @@ -130,7 +130,7 @@ static int komeda_parse_pipe_dt(struct komeda_dev *mdev,
> struct device_node *np)
> of_graph_get_port_by_id(np, KOMEDA_OF_PORT_OUTPUT);
>
> pipe->dual_link = pipe->of_output_links[0] && pipe->of_output_links[1];
> - pipe->of_node = np;
> + pipe->of_node = of_node_get(np);
>
Good catch.
Reviewed-by: Ayan Kumar Halder
> return 0;
> }
> --
> 2.22.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 error: not allocating enough data 1592 vs 1584
On Mon, Aug 19, 2019 at 08:01:57AM +, james qian wang (Arm Technology China) wrote: > The patch 5d51f6c0da1b: "drm/komeda: Add writeback support" from May > 23, 2019, leads to the following static checker warning: > > drivers/gpu/drm/arm/display/komeda/komeda_wb_connector.c:151 > komeda_wb_connector_add() > error: not allocating enough data 1592 vs 1584 > > This is a typo which misuse "wb_conn" but which should be "kwb_conn" to > allocate the memory. > > Reported-by: Dan Carpenter > Signed-off-by: james qian wang (Arm Technology China) > > --- > drivers/gpu/drm/arm/display/komeda/komeda_wb_connector.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_wb_connector.c > b/drivers/gpu/drm/arm/display/komeda/komeda_wb_connector.c > index 617e1f7b8472..2851cac94d86 100644 > --- a/drivers/gpu/drm/arm/display/komeda/komeda_wb_connector.c > +++ b/drivers/gpu/drm/arm/display/komeda/komeda_wb_connector.c > @@ -148,7 +148,7 @@ static int komeda_wb_connector_add(struct komeda_kms_dev > *kms, > if (!kcrtc->master->wb_layer) > return 0; > > - kwb_conn = kzalloc(sizeof(*wb_conn), GFP_KERNEL); > + kwb_conn = kzalloc(sizeof(*kwb_conn), GFP_KERNEL); > if (!kwb_conn) > return -ENOMEM; > > -- Reviewed-by: Ayan Kumar Halder > 2.20.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/komeda: Fix warning -Wunused-but-set-variable
On Mon, Aug 12, 2019 at 11:23:41AM +, james qian wang (Arm Technology
China) wrote:
> Fixed two -Wunused-but-set-variable warnings:
>
> /arm/linux/display/aosp-4.14-drm-next/drivers/gpu/drm/arm/display/komeda/komeda_kms.c:
> In function ‘komeda_crtc_normalize_zpos’:
> /arm/linux/display/aosp-4.14-drm-next/drivers/gpu/drm/arm/display/komeda/komeda_kms.c:150:26:
> warning: variable ‘fb’ set but not used [-Wunused-but-set-variable]
> struct drm_framebuffer *fb;
> ^~
> /arm/linux/display/aosp-4.14-drm-next/drivers/gpu/drm/arm/display/komeda/komeda_kms.c:
> In function ‘komeda_kms_check’:
> /arm/linux/display/aosp-4.14-drm-next/drivers/gpu/drm/arm/display/komeda/komeda_kms.c:209:25:
> warning: variable ‘old_crtc_st’ set but not used [-Wunused-but-set-variable]
> struct drm_crtc_state *old_crtc_st, *new_crtc_st;
> ^~~
>
> Signed-off-by: james qian wang (Arm Technology China)
>
> ---
> drivers/gpu/drm/arm/display/komeda/komeda_kms.c | 6 ++
> 1 file changed, 2 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_kms.c
> b/drivers/gpu/drm/arm/display/komeda/komeda_kms.c
> index d50e75f0b2bd..1f0e3f4e8d74 100644
> --- a/drivers/gpu/drm/arm/display/komeda/komeda_kms.c
> +++ b/drivers/gpu/drm/arm/display/komeda/komeda_kms.c
> @@ -147,7 +147,6 @@ static int komeda_crtc_normalize_zpos(struct drm_crtc
> *crtc,
> struct komeda_crtc_state *kcrtc_st = to_kcrtc_st(crtc_st);
> struct komeda_plane_state *kplane_st;
> struct drm_plane_state *plane_st;
> - struct drm_framebuffer *fb;
> struct drm_plane *plane;
> struct list_head zorder_list;
> int order = 0, err;
> @@ -173,7 +172,6 @@ static int komeda_crtc_normalize_zpos(struct drm_crtc
> *crtc,
>
> list_for_each_entry(kplane_st, _list, zlist_node) {
> plane_st = _st->base;
> - fb = plane_st->fb;
> plane = plane_st->plane;
>
> plane_st->normalized_zpos = order++;
> @@ -206,7 +204,7 @@ static int komeda_kms_check(struct drm_device *dev,
> struct drm_atomic_state *state)
> {
> struct drm_crtc *crtc;
> - struct drm_crtc_state *old_crtc_st, *new_crtc_st;
> + struct drm_crtc_state *new_crtc_st;
> int i, err;
>
> err = drm_atomic_helper_check_modeset(dev, state);
> @@ -217,7 +215,7 @@ static int komeda_kms_check(struct drm_device *dev,
>* so need to add all affected_planes (even unchanged) to
>* drm_atomic_state.
>*/
> - for_each_oldnew_crtc_in_state(state, crtc, old_crtc_st, new_crtc_st, i)
> {
> + for_each_new_crtc_in_state(state, crtc, new_crtc_st, i) {
> err = drm_atomic_add_affected_planes(state, crtc);
> if (err)
> return err;
> --
Looks good to me.
Reviewed-by: Ayan Kumar Halder
> 2.20.1
>
Re: [PATCH] drm/komeda: Clean warning 'komeda_component_add' might be a candidate for 'gnu_printf'
On Tue, Aug 13, 2019 at 11:08:20AM +, james qian wang (Arm Technology China) wrote: > komeda/komeda_pipeline.c: In function 'komeda_component_add': > komeda/komeda_pipeline.c:212:3: warning: function 'komeda_component_add' > might be a candidate for 'gnu_printf' format attribute > [-Wsuggest-attribute=format] >vsnprintf(c->name, sizeof(c->name), name_fmt, args); >^ > > Signed-off-by: james qian wang (Arm Technology China) > > --- > drivers/gpu/drm/arm/display/komeda/komeda_pipeline.h | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_pipeline.h > b/drivers/gpu/drm/arm/display/komeda/komeda_pipeline.h > index a90bcbb3cb23..14b683164544 100644 > --- a/drivers/gpu/drm/arm/display/komeda/komeda_pipeline.h > +++ b/drivers/gpu/drm/arm/display/komeda/komeda_pipeline.h > @@ -480,6 +480,7 @@ void komeda_pipeline_dump_register(struct komeda_pipeline > *pipe, > struct seq_file *sf); > > /* component APIs */ > +extern __printf(10, 11) Took me a while to understand this and found this link very helpful :) :- https://www.avrfreaks.net/forum/gnuprintf-format-attribute Reviewed-by: Ayan Kumar Halder > struct komeda_component * > komeda_component_add(struct komeda_pipeline *pipe, >size_t comp_sz, u32 id, u32 hw_id, > -- > 2.20.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/komeda: Reordered the komeda's de-init functions
The de-init routine should be doing the following in order:-
1. Unregister the drm device
2. Shut down the crtcs - failing to do this might cause a connector leakage
See the 'commit 109c4d18e574 ("drm/arm/malidp: Ensure that the crtcs are
shutdown before removing any encoder/connector")'
3. Disable the interrupts
4. Unbind the components
5. Free up DRM mode_config info
Signed-off-by: Ayan Kumar Halder
---
.../gpu/drm/arm/display/komeda/komeda_kms.c | 20 +--
1 file changed, 14 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_kms.c
b/drivers/gpu/drm/arm/display/komeda/komeda_kms.c
index 89191a555c84..e219d1b67100 100644
--- a/drivers/gpu/drm/arm/display/komeda/komeda_kms.c
+++ b/drivers/gpu/drm/arm/display/komeda/komeda_kms.c
@@ -13,6 +13,7 @@
#include
#include
#include
+#include
#include
#include
@@ -304,24 +305,30 @@ struct komeda_kms_dev *komeda_kms_attach(struct
komeda_dev *mdev)
komeda_kms_irq_handler, IRQF_SHARED,
drm->driver->name, drm);
if (err)
- goto cleanup_mode_config;
+ goto free_component_binding;
err = mdev->funcs->enable_irq(mdev);
if (err)
- goto cleanup_mode_config;
+ goto free_component_binding;
drm->irq_enabled = true;
err = drm_dev_register(drm, 0);
if (err)
- goto cleanup_mode_config;
+ goto free_interrupts;
return kms;
-cleanup_mode_config:
+free_interrupts:
drm->irq_enabled = false;
+ mdev->funcs->disable_irq(mdev);
+free_component_binding:
+ component_unbind_all(mdev->dev, drm);
+cleanup_mode_config:
drm_mode_config_cleanup(drm);
komeda_kms_cleanup_private_objs(kms);
+ drm->dev_private = NULL;
+ drm_dev_put(drm);
free_kms:
kfree(kms);
return ERR_PTR(err);
@@ -332,12 +339,13 @@ void komeda_kms_detach(struct komeda_kms_dev *kms)
struct drm_device *drm = >base;
struct komeda_dev *mdev = drm->dev_private;
+ drm_dev_unregister(drm);
+ drm_atomic_helper_shutdown(drm);
drm->irq_enabled = false;
mdev->funcs->disable_irq(mdev);
- drm_dev_unregister(drm);
component_unbind_all(mdev->dev, drm);
- komeda_kms_cleanup_private_objs(kms);
drm_mode_config_cleanup(drm);
+ komeda_kms_cleanup_private_objs(kms);
drm->dev_private = NULL;
drm_dev_put(drm);
}
--
2.21.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2.1] drm/komeda: Add support for 'memory-region' DT node property
On Mon, Aug 05, 2019 at 10:13:35AM +, james qian wang (Arm Technology
China) wrote:
> On Mon, Aug 05, 2019 at 05:56:25PM +0800, Mihail Atanassov wrote:
> > The 'memory-region' property of the komeda display driver DT binding
> > allows the use of a 'reserved-memory' node for buffer allocations. Add
> > the requisite of_reserved_mem_device_{init,release} calls to actually
> > make use of the memory if present.
> >
> > Changes since v1:
> > - Move handling inside komeda_parse_dt
> >
> > Signed-off-by: Mihail Atanassov
> > ---
> > drivers/gpu/drm/arm/display/komeda/komeda_dev.c | 9 +
> > 1 file changed, 9 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_dev.c
> > b/drivers/gpu/drm/arm/display/komeda/komeda_dev.c
> > index 1ff7f4b2c620..0142ee991957 100644
> > --- a/drivers/gpu/drm/arm/display/komeda/komeda_dev.c
> > +++ b/drivers/gpu/drm/arm/display/komeda/komeda_dev.c
> > @@ -8,6 +8,7 @@
> > #include
> > #include
> > #include
> > +#include
> > #include
> > #include
> > #ifdef CONFIG_DEBUG_FS
> > @@ -146,6 +147,12 @@ static int komeda_parse_dt(struct device *dev, struct
> > komeda_dev *mdev)
> > return mdev->irq;
> > }
> >
> > + /* Get the optional framebuffer memory resource */
> > + ret = of_reserved_mem_device_init(dev);
> > + if (ret && ret != -ENODEV)
> > + return ret;
> > + ret = 0;
> > +
> > for_each_available_child_of_node(np, child) {
> > if (of_node_cmp(child->name, "pipeline") == 0) {
> > ret = komeda_parse_pipe_dt(mdev, child);
> > @@ -292,6 +299,8 @@ void komeda_dev_destroy(struct komeda_dev *mdev)
> >
> > mdev->n_pipelines = 0;
> >
> > + of_reserved_mem_device_release(dev);
> > +
> > if (funcs && funcs->cleanup)
> > funcs->cleanup(mdev);
> >
> > --
> > 2.22.0
>
>
> Thank you.
>
> Reviewed-by: James Qian Wang (Arm Technology China)
Pushed to drm-misc-next - a8c16b7593bd1a4e613164a47c526ca9d1be764b
> ___
> 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] drm/crc-debugfs: Add notes about CRC<->commit interactions
On Tue, Aug 06, 2019 at 01:46:22PM +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.
>
> 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
>
Pushed to drm-misc-next.
Commit id :- 178e5f3a5bc1d67d1248a74c0abab41040abe7c4
-Ayan
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2] drm/komeda: Make Komeda interrupts shareable
Komeda interrupts may be shared with other hardware blocks.
One needs to use devm_request_irq() with IRQF_SHARED to create a shared
interrupt handler.
As a result of not using drm_irq_install() api, one needs to set
"(struct drm_device *)->irq_enabled = true/false" to enable/disable
vblank interrupts.
Changes from v1:-
1. Squashed the following two patches into one (as the second patch is a
consequence of the first one):-
drm/komeda: Avoid using DRIVER_IRQ_SHARED
drm/komeda: Enable/Disable vblank interrupts
2. Fixed the commit message (as pointed by Daniel Vetter)
3. Removed calls to 'drm_irq_uninstall()' as we are no longer using
drm_irq_install()
4. Removed the struct member 'komeda_kms_driver.irq_handler' as it is not
used anywhere.
Signed-off-by: Ayan Kumar halder
---
drivers/gpu/drm/arm/display/komeda/komeda_kms.c | 16 +---
1 file changed, 9 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_kms.c
b/drivers/gpu/drm/arm/display/komeda/komeda_kms.c
index 86f6542afb40..bb2bffc0e022 100644
--- a/drivers/gpu/drm/arm/display/komeda/komeda_kms.c
+++ b/drivers/gpu/drm/arm/display/komeda/komeda_kms.c
@@ -58,7 +58,6 @@ static struct drm_driver komeda_kms_driver = {
.driver_features = DRIVER_GEM | DRIVER_MODESET | DRIVER_ATOMIC |
DRIVER_PRIME | DRIVER_HAVE_IRQ,
.lastclose = drm_fb_helper_lastclose,
- .irq_handler= komeda_kms_irq_handler,
.gem_free_object_unlocked = drm_gem_cma_free_object,
.gem_vm_ops = _gem_cma_vm_ops,
.dumb_create= komeda_gem_cma_dumb_create,
@@ -194,23 +193,26 @@ struct komeda_kms_dev *komeda_kms_attach(struct
komeda_dev *mdev)
drm_mode_config_reset(drm);
- err = drm_irq_install(drm, mdev->irq);
+ err = devm_request_irq(drm->dev, mdev->irq,
+ komeda_kms_irq_handler, IRQF_SHARED,
+ drm->driver->name, drm);
if (err)
goto cleanup_mode_config;
err = mdev->funcs->enable_irq(mdev);
if (err)
- goto uninstall_irq;
+ goto cleanup_mode_config;
+
+ drm->irq_enabled = true;
err = drm_dev_register(drm, 0);
if (err)
- goto uninstall_irq;
+ goto cleanup_mode_config;
return kms;
-uninstall_irq:
- drm_irq_uninstall(drm);
cleanup_mode_config:
+ drm->irq_enabled = false;
drm_mode_config_cleanup(drm);
komeda_kms_cleanup_private_objs(kms);
free_kms:
@@ -223,9 +225,9 @@ void komeda_kms_detach(struct komeda_kms_dev *kms)
struct drm_device *drm = >base;
struct komeda_dev *mdev = drm->dev_private;
+ drm->irq_enabled = false;
mdev->funcs->disable_irq(mdev);
drm_dev_unregister(drm);
- drm_irq_uninstall(drm);
component_unbind_all(mdev->dev, drm);
komeda_kms_cleanup_private_objs(kms);
drm_mode_config_cleanup(drm);
--
2.21.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/komeda: Enable/Disable vblank interrupts
On Fri, Jun 07, 2019 at 08:18:56PM +0200, Daniel Vetter wrote: Hi Daniel, > On Fri, Jun 07, 2019 at 03:03:39PM +0000, Ayan Halder wrote: > > One needs to set "(struct drm_device *)->irq_enabled = true" to signal drm > > core > > to enable vblank interrupts after the hardware has been initialized. > > Correspondingly, one needs to disable vblank interrupts by setting > > "(struct drm_device *)->irq_enabled = false" at the beginning of the > > de-initializing routine. > > Only if you don't use the drm_irq_install helper. Quoting the kerneldoc in > full: > > /** > * @irq_enabled: > * > * Indicates that interrupt handling is enabled, specifically vblank > * handling. Drivers which don't use drm_irq_install() need to set this > * to true manually. > */ > bool irq_enabled; > > Not entirely sure where you've found your quote, but it's not complete. > > Cheers, Daniel Thanks for your review. That was my quote which reflects my half-baked understanding of the issue :(. I had missed reading the header files. That said, I will squash my previous patch "drm/komeda: Avoid using DRIVER_IRQ_SHARED" into this one as the current patch is a consequence of the changes made in the previous patch. Regards, Ayan Kumar Halder > > > > > Signed-off-by: Ayan Kumar halder > > --- > > drivers/gpu/drm/arm/display/komeda/komeda_kms.c | 4 > > 1 file changed, 4 insertions(+) > > > > diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_kms.c > > b/drivers/gpu/drm/arm/display/komeda/komeda_kms.c > > index 7b5cde14e3ba..b4fd8ee0d05f 100644 > > --- a/drivers/gpu/drm/arm/display/komeda/komeda_kms.c > > +++ b/drivers/gpu/drm/arm/display/komeda/komeda_kms.c > > @@ -204,6 +204,8 @@ struct komeda_kms_dev *komeda_kms_attach(struct > > komeda_dev *mdev) > > if (err) > > goto uninstall_irq; > > > > +drm->irq_enabled = true; > > + > > err = drm_dev_register(drm, 0); > > if (err) > > goto uninstall_irq; > > @@ -211,6 +213,7 @@ struct komeda_kms_dev *komeda_kms_attach(struct > > komeda_dev *mdev) > > return kms; > > > > uninstall_irq: > > +drm->irq_enabled = false; > > drm_irq_uninstall(drm); > > cleanup_mode_config: > > drm_mode_config_cleanup(drm); > > @@ -225,6 +228,7 @@ void komeda_kms_detach(struct komeda_kms_dev *kms) > > struct drm_device *drm = >base; > > struct komeda_dev *mdev = drm->dev_private; > > > > +drm->irq_enabled = false; > > mdev->funcs->disable_irq(mdev); > > drm_dev_unregister(drm); > > drm_irq_uninstall(drm); > > -- > > 2.21.0 > > > > -- > 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
[PATCH] drm/komeda: Enable/Disable vblank interrupts
One needs to set "(struct drm_device *)->irq_enabled = true" to signal drm core to enable vblank interrupts after the hardware has been initialized. Correspondingly, one needs to disable vblank interrupts by setting "(struct drm_device *)->irq_enabled = false" at the beginning of the de-initializing routine. Signed-off-by: Ayan Kumar halder --- drivers/gpu/drm/arm/display/komeda/komeda_kms.c | 4 1 file changed, 4 insertions(+) diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_kms.c b/drivers/gpu/drm/arm/display/komeda/komeda_kms.c index 7b5cde14e3ba..b4fd8ee0d05f 100644 --- a/drivers/gpu/drm/arm/display/komeda/komeda_kms.c +++ b/drivers/gpu/drm/arm/display/komeda/komeda_kms.c @@ -204,6 +204,8 @@ struct komeda_kms_dev *komeda_kms_attach(struct komeda_dev *mdev) if (err) goto uninstall_irq; + drm->irq_enabled = true; + err = drm_dev_register(drm, 0); if (err) goto uninstall_irq; @@ -211,6 +213,7 @@ struct komeda_kms_dev *komeda_kms_attach(struct komeda_dev *mdev) return kms; uninstall_irq: + drm->irq_enabled = false; drm_irq_uninstall(drm); cleanup_mode_config: drm_mode_config_cleanup(drm); @@ -225,6 +228,7 @@ void komeda_kms_detach(struct komeda_kms_dev *kms) struct drm_device *drm = >base; struct komeda_dev *mdev = drm->dev_private; + drm->irq_enabled = false; mdev->funcs->disable_irq(mdev); drm_dev_unregister(drm); drm_irq_uninstall(drm); -- 2.21.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/komeda: Avoid using DRIVER_IRQ_SHARED
With reference to mainline commit (1ff494813bafa127ecba1160262ba39b2fdde7ba), DRIVER_IRQ_SHARED is to be used only by legacy drivers. Further, drm_irq_install() ignores this flag altogether. One needs to use devm_request_irq() instead, with IRQF_SHARED to create a shared interrupt handler. Signed-off-by: Ayan Kumar halder --- drivers/gpu/drm/arm/display/komeda/komeda_kms.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_kms.c b/drivers/gpu/drm/arm/display/komeda/komeda_kms.c index 86f6542afb40..7b5cde14e3ba 100644 --- a/drivers/gpu/drm/arm/display/komeda/komeda_kms.c +++ b/drivers/gpu/drm/arm/display/komeda/komeda_kms.c @@ -194,7 +194,9 @@ struct komeda_kms_dev *komeda_kms_attach(struct komeda_dev *mdev) drm_mode_config_reset(drm); - err = drm_irq_install(drm, mdev->irq); + err = devm_request_irq(drm->dev, mdev->irq, + komeda_kms_driver.irq_handler, IRQF_SHARED, + drm->driver->name, drm); if (err) goto cleanup_mode_config; -- 2.21.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4] drm/komeda: Add writeback support
On Thu, May 23, 2019 at 10:36:38AM +0100, james qian wang (Arm Technology
China) wrote:
> Komeda driver uses a individual component to describe the HW's writeback
> caps, but drivers doesn't define a new structure and still uses the
> existing "struct komeda_layer" to describe this new component.
> The detailed changes as follow:
>
> 1. Initialize wb_layer according to HW and report it to CORE.
> 2. CORE exposes wb_layer as a resource to KMS by private_obj.
> 3. Report writeback supporting by add a wb_connector to KMS, and then
>wb_connector will take act as a component resources user,
>so the func komeda_wb_encoder_atomic_check claims komeda resources
>(scaler and wb_layer) accroding to its state configuration to the
>wb_connector. and the wb_state configuration will be validated on the
>specific component resources to see if the caps of component can
>meet the requirement of wb_connector. if not check failed.
> 4. Update irq_handler to notify the completion of writeback.
>
> NOTE:
> This change doesn't add scaling writeback support, that support will
> be added in the future after the scaler support.
>
> v2: Rebase
> v3: Rebase and constify the d71_wb_layer_funcs
> v4: Addressed Ayan's comments
>
> Depends on:
> - https://patchwork.freedesktop.org/series/59915/
>
> Signed-off-by: James Qian Wang (Arm Technology China)
>
> ---
> drivers/gpu/drm/arm/display/komeda/Makefile | 1 +
> .../arm/display/komeda/d71/d71_component.c| 90 -
> .../gpu/drm/arm/display/komeda/komeda_crtc.c | 15 ++
> .../arm/display/komeda/komeda_framebuffer.c | 19 ++
> .../gpu/drm/arm/display/komeda/komeda_kms.c | 4 +
> .../gpu/drm/arm/display/komeda/komeda_kms.h | 27 +++
> .../drm/arm/display/komeda/komeda_pipeline.h | 7 +
> .../display/komeda/komeda_pipeline_state.c| 51 -
> .../arm/display/komeda/komeda_private_obj.c | 6 +
> .../arm/display/komeda/komeda_wb_connector.c | 181 ++
> 10 files changed, 398 insertions(+), 3 deletions(-)
> create mode 100644 drivers/gpu/drm/arm/display/komeda/komeda_wb_connector.c
>
> diff --git a/drivers/gpu/drm/arm/display/komeda/Makefile
> b/drivers/gpu/drm/arm/display/komeda/Makefile
> index 62bd1bff66a3..d7e29fc688c3 100644
> --- a/drivers/gpu/drm/arm/display/komeda/Makefile
> +++ b/drivers/gpu/drm/arm/display/komeda/Makefile
> @@ -14,6 +14,7 @@ komeda-y := \
> komeda_kms.o \
> komeda_crtc.o \
> komeda_plane.o \
> + komeda_wb_connector.o \
> komeda_private_obj.o
>
> komeda-y += \
> 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 6bab816ed8e7..323e5994a55c 100644
> --- a/drivers/gpu/drm/arm/display/komeda/d71/d71_component.c
> +++ b/drivers/gpu/drm/arm/display/komeda/d71/d71_component.c
> @@ -288,10 +288,98 @@ static int d71_layer_init(struct d71_dev *d71,
> return 0;
> }
>
> +static void d71_wb_layer_update(struct komeda_component *c,
> + struct komeda_component_state *state)
> +{
> + struct komeda_layer_state *st = to_layer_st(state);
> + struct drm_connector_state *conn_st = state->wb_conn->state;
> + struct drm_framebuffer *fb = conn_st->writeback_job->fb;
> + struct komeda_fb *kfb = to_kfb(fb);
> + u32 __iomem *reg = c->reg;
> + u32 ctrl = L_EN | LW_OFM, mask = L_EN | LW_OFM | LW_TBU_EN;
> + int i;
> +
> + for (i = 0; i < fb->format->num_planes; i++) {
> + malidp_write32(reg + i * LAYER_PER_PLANE_REGS, BLK_P0_PTR_LOW,
> +lower_32_bits(st->addr[i]));
> + malidp_write32(reg + i * LAYER_PER_PLANE_REGS, BLK_P0_PTR_HIGH,
> +upper_32_bits(st->addr[i]));
> +
> + malidp_write32(reg + i * LAYER_PER_PLANE_REGS, BLK_P0_STRIDE,
> +fb->pitches[i] & 0x);
> + }
> +
> + malidp_write32(reg, LAYER_FMT, kfb->format_caps->hw_id);
> + malidp_write32(reg, BLK_IN_SIZE, HV_SIZE(st->hsize, st->vsize));
> + malidp_write32(reg, BLK_INPUT_ID0, to_d71_input_id(>inputs[0]));
> + malidp_write32_mask(reg, BLK_CONTROL, mask, ctrl);
> +}
> +
> +static void d71_wb_layer_dump(struct komeda_component *c, struct seq_file
> *sf)
> +{
> + u32 v[12], i;
> +
> + dump_block_header(sf, c->reg);
> +
> + get_values_from_reg(c->reg, 0x80, 1, v);
> + seq_printf(sf, "LW_INPUT_ID0:\t\t0x%X\n", v[0]);
> +
> + get_values_from_reg(c->reg, 0xD0, 3, v);
> + seq_printf(sf, "LW_CONTROL:\t\t0x%X\n", v[0]);
> + seq_printf(sf, "LW_PROG_LINE:\t\t0x%X\n", v[1]);
> + seq_printf(sf, "LW_FORMAT:\t\t0x%X\n", v[2]);
> +
> + get_values_from_reg(c->reg, 0xE0, 1, v);
> + seq_printf(sf, "LW_IN_SIZE:\t\t0x%X\n", v[0]);
> +
> + for (i = 0; i < 2; i++) {
> + get_values_from_reg(c->reg, 0x100 + i * 0x10, 3, v);
> + seq_printf(sf, "LW_P%u_PTR_LOW:\t\t0x%X\n", i, v[0]);
> +
Re: [PATCH] drm/komeda: Added AFBC support for komeda driver
On Thu, Apr 04, 2019 at 12:06:14PM +0100, james qian wang (Arm Technology
China) wrote:
> For supporting AFBC:
> 1. Check if the user requested modifier can be supported by display HW.
> 2. Check the obj->size with AFBC's requirement.
> 3. Configure HW according to the modifier (afbc features)
Can we have a bit more detailed commit message listing the various
constraints (about which combination of modifiers, format and block
sizes are valid) ?
>
> This patch depends on:
> - https://patchwork.freedesktop.org/series/54448/
> - https://patchwork.freedesktop.org/series/54449/
> - https://patchwork.freedesktop.org/series/54450/
> - https://patchwork.freedesktop.org/series/58976/
> - https://patchwork.freedesktop.org/series/59000/
>
> Signed-off-by: James Qian Wang (Arm Technology China)
>
> ---
> .../arm/display/komeda/d71/d71_component.c| 39 ++
> .../arm/display/komeda/komeda_format_caps.c | 53 +
> .../arm/display/komeda/komeda_format_caps.h | 5 ++
> .../arm/display/komeda/komeda_framebuffer.c | 74 ++-
> .../arm/display/komeda/komeda_framebuffer.h | 4 +
> .../gpu/drm/arm/display/komeda/komeda_kms.c | 2 +-
> .../drm/arm/display/komeda/komeda_pipeline.h | 4 +
> .../display/komeda/komeda_pipeline_state.c| 18 -
> .../gpu/drm/arm/display/komeda/komeda_plane.c | 15 +++-
> 9 files changed, 209 insertions(+), 5 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 b582afcf9210..33ca1718b5cd 100644
> --- a/drivers/gpu/drm/arm/display/komeda/d71/d71_component.c
> +++ b/drivers/gpu/drm/arm/display/komeda/d71/d71_component.c
> @@ -134,6 +134,27 @@ static u32 to_rot_ctrl(u32 rot)
> return lr_ctrl;
> }
>
> +static u32 to_ad_ctrl(u64 modifier)
> +{
> + u32 afbc_ctrl = AD_AEN;
> +
> + if (!modifier)
> + return 0;
> +
> + if ((modifier & AFBC_FORMAT_MOD_BLOCK_SIZE_MASK) ==
> + AFBC_FORMAT_MOD_BLOCK_SIZE_32x8)
> + afbc_ctrl |= AD_WB;
> +
> + if (modifier & AFBC_FORMAT_MOD_YTR)
> + afbc_ctrl |= AD_YT;
> + if (modifier & AFBC_FORMAT_MOD_SPLIT)
> + afbc_ctrl |= AD_BS;
> + if (modifier & AFBC_FORMAT_MOD_TILED)
> + afbc_ctrl |= AD_TH;
> +
> + return afbc_ctrl;
> +}
> +
> static inline u32 to_d71_input_id(struct komeda_component_output *output)
> {
> struct komeda_component *comp = output->component;
> @@ -173,6 +194,24 @@ static void d71_layer_update(struct komeda_component *c,
> fb->pitches[i] & 0x);
> }
>
> + malidp_write32(reg, AD_CONTROL, to_ad_ctrl(fb->modifier));
> + if (fb->modifier) {
> + u64 addr;
> +
> + malidp_write32(reg, LAYER_AD_H_CROP, HV_CROP(st->afbc_crop_l,
> + st->afbc_crop_r));
> + malidp_write32(reg, LAYER_AD_V_CROP, HV_CROP(st->afbc_crop_t,
> + st->afbc_crop_b));
> + /* afbc 1.2 wants payload, afbc 1.0/1.1 wants end_addr */
> + if (fb->modifier & AFBC_FORMAT_MOD_TILED)
> + addr = st->addr[0] + kfb->offset_payload;
> + else
> + addr = st->addr[0] + kfb->afbc_size - 1;
> +
> + malidp_write32(reg, BLK_P1_PTR_LOW, lower_32_bits(addr));
> + malidp_write32(reg, BLK_P1_PTR_HIGH, upper_32_bits(addr));
> + }
> +
> malidp_write32(reg, LAYER_FMT, kfb->format_caps->hw_id);
> malidp_write32(reg, BLK_IN_SIZE, HV_SIZE(st->hsize, st->vsize));
>
> diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_format_caps.c
> b/drivers/gpu/drm/arm/display/komeda/komeda_format_caps.c
> index 1e17bd6107a4..b2195142e3f3 100644
> --- a/drivers/gpu/drm/arm/display/komeda/komeda_format_caps.c
> +++ b/drivers/gpu/drm/arm/display/komeda/komeda_format_caps.c
> @@ -35,6 +35,59 @@ komeda_get_format_caps(struct komeda_format_caps_table
> *table,
> return NULL;
> }
>
> +/* Two assumptions
> + * 1. RGB always has YTR
> + * 2. Tiled RGB always has SC
> + */
> +u64 komeda_supported_modifiers[] = {
> + /* AFBC_16x16 + features: YUV+RGB both */
> + AFBC_16x16(0),
> + /* SPARSE */
> + AFBC_16x16(_SPARSE),
> + /* YTR + (SPARSE) */
> + AFBC_16x16(_YTR | _SPARSE),
> + AFBC_16x16(_YTR),
> + /* SPLIT + SPARSE + YTR RGB only */
> + /* split mode is only allowed for sparse mode */
> + AFBC_16x16(_SPLIT | _SPARSE | _YTR),
> + /* TILED + (SPARSE) */
> + /* TILED YUV format only */
> + AFBC_16x16(_TILED | _SPARSE),
> + AFBC_16x16(_TILED),
> + /* TILED + SC + (SPLIT+SPARSE | SPARSE) + (YTR) */
> + AFBC_16x16(_TILED | _SC | _SPLIT | _SPARSE | _YTR),
> + AFBC_16x16(_TILED | _SC | _SPARSE | _YTR),
> + AFBC_16x16(_TILED | _SC | _YTR),
> + /* AFBC_32x8 + features: which are RGB formats
Re: [RFC PATCH v2] drm/komeda: fixing of DMA mapping sg segment warning
On Thu, Apr 04, 2019 at 11:08:04AM +0100, Lowry Li (Arm Technology China) wrote:
> Fixing the DMA mapping sg segment warning, which shows "DMA-API: mapping
> sg segment longer than device claims to support [len=921600] [max=65536]".
> Fixed by setting the max segment size at Komeda driver.
>
> This patch depends on:
> - https://patchwork.freedesktop.org/series/54448/
> - https://patchwork.freedesktop.org/series/54449/
> - https://patchwork.freedesktop.org/series/54450/
> - https://patchwork.freedesktop.org/series/58976/
>
> Changes since v1:
> - Adds member description
> - Adds patch denpendency in the comment
>
> Signed-off-by: Lowry Li (Arm Technology China)
> ---
> drivers/gpu/drm/arm/display/komeda/komeda_dev.c | 4
> drivers/gpu/drm/arm/display/komeda/komeda_dev.h | 2 ++
> 2 files changed, 6 insertions(+)
>
> diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_dev.c
> b/drivers/gpu/drm/arm/display/komeda/komeda_dev.c
> index 7f25e6a..b4902ae 100644
> --- a/drivers/gpu/drm/arm/display/komeda/komeda_dev.c
> +++ b/drivers/gpu/drm/arm/display/komeda/komeda_dev.c
> @@ -8,6 +8,7 @@
> #include
> #include
> #include
> +#include
> #ifdef CONFIG_DEBUG_FS
> #include
> #include
> @@ -245,6 +246,9 @@ struct komeda_dev *komeda_dev_create(struct device *dev)
> goto err_cleanup;
> }
>
> + dev->dma_parms = >dma_parms;
> + dma_set_max_seg_size(dev, DMA_BIT_MASK(32));
> +
> err = sysfs_create_group(>kobj, _sysfs_attr_group);
> if (err) {
> DRM_ERROR("create sysfs group failed.\n");
> diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_dev.h
> b/drivers/gpu/drm/arm/display/komeda/komeda_dev.h
> index 29e03c4..83ace71 100644
> --- a/drivers/gpu/drm/arm/display/komeda/komeda_dev.h
> +++ b/drivers/gpu/drm/arm/display/komeda/komeda_dev.h
> @@ -149,6 +149,8 @@ struct komeda_dev {
> struct device *dev;
> /** @reg_base: the base address of komeda io space */
> u32 __iomem *reg_base;
> + /** @dma_parms: the dma parameters of komeda */
> + struct device_dma_parameters dma_parms;
>
> /** @chip: the basic chip information */
> struct komeda_chip_info chip;
> --
> 1.9.1
lgtm
Reviewed-by: Ayan Kumar Halder
Re: [PATCH v3] drm/komeda: Add writeback support
On Thu, May 16, 2019 at 09:13:27AM +0100, james qian wang (Arm Technology
China) wrote:
> Komeda driver uses a individual component to describe the HW's writeback
> caps, but drivers doesn't define a new structure and still uses the
> existing "struct komeda_layer" to describe this new component.
> The detailed changes as follow:
>
> 1. Initialize wb_layer according to HW and report it to CORE.
> 2. CORE exposes wb_layer as a resource to KMS by private_obj.
> 3. Report writeback supporting by add a wb_connector to KMS, and then
>wb_connector will take act as a component resources user,
>so the func komeda_wb_encoder_atomic_check claims komeda resources
>(scaler and wb_layer) accroding to its state configuration to the
>wb_connector. and the wb_state configuration will be validated on the
>specific component resources to see if the caps of component can
>meet the requirement of wb_connector. if not check failed.
> 4. Update irq_handler to notify the completion of writeback.
>
> NOTE:
> This change doesn't add scaling writeback support, that support will
> be added in the future after the scaler support.
>
> v2: Rebase
> v3: Rebase and constify the d71_wb_layer_funcs
>
> Depends on:
> - https://patchwork.freedesktop.org/series/59915/
>
> Signed-off-by: James Qian Wang (Arm Technology China)
>
> ---
> drivers/gpu/drm/arm/display/komeda/Makefile | 1 +
> .../arm/display/komeda/d71/d71_component.c| 90 -
> .../gpu/drm/arm/display/komeda/komeda_crtc.c | 15 ++
> .../arm/display/komeda/komeda_framebuffer.c | 19 ++
> .../gpu/drm/arm/display/komeda/komeda_kms.c | 4 +
> .../gpu/drm/arm/display/komeda/komeda_kms.h | 27 +++
> .../drm/arm/display/komeda/komeda_pipeline.h | 7 +
> .../display/komeda/komeda_pipeline_state.c| 51 -
> .../arm/display/komeda/komeda_private_obj.c | 6 +
> .../arm/display/komeda/komeda_wb_connector.c | 181 ++
> 10 files changed, 398 insertions(+), 3 deletions(-)
> create mode 100644 drivers/gpu/drm/arm/display/komeda/komeda_wb_connector.c
>
> diff --git a/drivers/gpu/drm/arm/display/komeda/Makefile
> b/drivers/gpu/drm/arm/display/komeda/Makefile
> index 62bd1bff66a3..d7e29fc688c3 100644
> --- a/drivers/gpu/drm/arm/display/komeda/Makefile
> +++ b/drivers/gpu/drm/arm/display/komeda/Makefile
> @@ -14,6 +14,7 @@ komeda-y := \
> komeda_kms.o \
> komeda_crtc.o \
> komeda_plane.o \
> + komeda_wb_connector.o \
> komeda_private_obj.o
>
> komeda-y += \
> 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 6bab816ed8e7..67e698d0e6aa 100644
> --- a/drivers/gpu/drm/arm/display/komeda/d71/d71_component.c
> +++ b/drivers/gpu/drm/arm/display/komeda/d71/d71_component.c
> @@ -288,10 +288,98 @@ static int d71_layer_init(struct d71_dev *d71,
> return 0;
> }
>
> +static void d71_wb_layer_update(struct komeda_component *c,
> + struct komeda_component_state *state)
> +{
> + struct komeda_layer_state *st = to_layer_st(state);
> + struct drm_connector_state *conn_st = state->wb_conn->state;
> + struct drm_framebuffer *fb = conn_st->writeback_job->fb;
> + struct komeda_fb *kfb = to_kfb(fb);
> + u32 __iomem *reg = c->reg;
> + u32 ctrl = L_EN | LW_OFM, mask = L_EN | LW_OFM | LW_TBU_EN;
> + int i;
> +
> + for (i = 0; i < fb->format->num_planes; i++) {
> + malidp_write32(reg + i * LAYER_PER_PLANE_REGS, BLK_P0_PTR_LOW,
> +lower_32_bits(st->addr[i]));
> + malidp_write32(reg + i * LAYER_PER_PLANE_REGS, BLK_P0_PTR_HIGH,
> +upper_32_bits(st->addr[i]));
> +
> + malidp_write32(reg + i * LAYER_PER_PLANE_REGS, BLK_P0_STRIDE,
> +fb->pitches[i] & 0x);
> + }
> +
> + malidp_write32(reg, LAYER_FMT, kfb->format_caps->hw_id);
> + malidp_write32(reg, BLK_IN_SIZE, HV_SIZE(st->hsize, st->vsize));
> + malidp_write32(reg, BLK_INPUT_ID0, to_d71_input_id(>inputs[0]));
> + malidp_write32_mask(reg, BLK_CONTROL, mask, ctrl);
> +}
> +
> +static void d71_wb_layer_dump(struct komeda_component *c, struct seq_file
> *sf)
> +{
> + u32 v[12], i;
> +
> + dump_block_header(sf, c->reg);
> +
> + get_values_from_reg(c->reg, 0x80, 1, v);
> + seq_printf(sf, "LW_INPUT_ID0:\t\t0x%X\n", v[0]);
> +
> + get_values_from_reg(c->reg, 0xD0, 3, v);
> + seq_printf(sf, "LW_CONTROL:\t\t0x%X\n", v[0]);
> + seq_printf(sf, "LW_PROG_LINE:\t\t0x%X\n", v[1]);
> + seq_printf(sf, "LW_FORMAT:\t\t0x%X\n", v[2]);
> +
> + get_values_from_reg(c->reg, 0xE0, 1, v);
> + seq_printf(sf, "LW_IN_SIZE:\t\t0x%X\n", v[0]);
> +
> + for (i = 0; i < 2; i++) {
> + get_values_from_reg(c->reg, 0x100 + i * 0x10, 3, v);
> + seq_printf(sf, "LW_P%u_PTR_LOW:\t\t0x%X\n", i, v[0]);
> + seq_printf(sf,
Re: [PATCH libdrm] headers: Sync with drm-next
On Thu, Apr 11, 2019 at 07:20:32AM +0100, Eric Engestrom wrote:
> On Wednesday, 2019-04-10 21:49:33 -0400, Rob Clark wrote:
> > On Tue, Apr 9, 2019 at 8:27 AM Eric Engestrom
> > wrote:
> > > > > diff --git a/include/drm/msm_drm.h b/include/drm/msm_drm.h
> > > > > index c06d0a5..91a16b3 100644
> > > > > --- a/include/drm/msm_drm.h
> > > > > +++ b/include/drm/msm_drm.h
> > > > > @@ -105,14 +105,24 @@ struct drm_msm_gem_new {
> > > > > __u32 handle; /* out */
> > > > > };
> > > > >
> > > > > -#define MSM_INFO_IOVA 0x01
> > > > > -
> > > > > -#define MSM_INFO_FLAGS (MSM_INFO_IOVA)
> > > > > +/* Get or set GEM buffer info. The requested value can be passed
> > > > > + * directly in 'value', or for data larger than 64b 'value' is a
> > > > > + * pointer to userspace buffer, with 'len' specifying the number of
> > > > > + * bytes copied into that buffer. For info returned by pointer,
> > > > > + * calling the GEM_INFO ioctl with null 'value' will return the
> > > > > + * required buffer size in 'len'
> > > > > + */
> > > > > +#define MSM_INFO_GET_OFFSET0x00 /* get mmap() offset,
> > > > > returned by value */
> > > > > +#define MSM_INFO_GET_IOVA 0x01 /* get iova, returned by value */
> > > > > +#define MSM_INFO_SET_NAME 0x02 /* set the debug name (by pointer)
> > > > > */
> > > > > +#define MSM_INFO_GET_NAME 0x03 /* get debug name, returned by
> > > > > pointer */
> > > > >
> > > > > struct drm_msm_gem_info {
> > > > > __u32 handle; /* in */
> > > > > - __u32 flags; /* in - combination of MSM_INFO_* flags */
> > > > > - __u64 offset; /* out, mmap() offset or iova */
> > > > > + __u32 info; /* in - one of MSM_INFO_* */
> > > > > + __u64 value; /* in or out */
> > > > > + __u32 len;/* in or out */
> > > > > + __u32 pad;
> > >
> > > freedreno/msm/msm_bo.c needs to be updated to reflect those changes.
> >
> >
> > I think you can just rename flags->info and offset->value, the rest of
> > the struct should be zero-initialized.. if in doubt you can check
> > $mesa/src/freedreno/drm/msm_bo.c
> >
> > side-note: the libdrm_freedreno code was folded into mesa in 19.0, so
> > at *some* point we can probably disable libdrm_freedreno build by
> > default.
>
> Right now, freedreno's `auto` enables it by default on arm and disables it on
> everything else.
>
> I always enable everything to at least build-test it, but Ayan was using
> the defaults which is why he didn't see this issue at first.
>
> Btw, the GitLab CI builds everything, so it hopefully won't bitrot unnoticed.
My bad, I was not aware that there is repo of libdrm in gitlab when I
submitted my v1 patch. I have taken care of it in my v2 patch ([PATCH
libdrm v2] headers: Sync with drm-next) and have also raised a merge
request
(https://gitlab.freedesktop.org/ayan.halder/drm/merge_requests/1/diffs)
to execute the gitlab ci tools.
Please be requested to have a look at my v2 patch.
>
> > (I'd kinda still like to keep the code around for some misc
> > standalone tools I have, but that is the sort of thing where I can fix
> > libdrm if it gets broken). When to switch to disabled by default I
> > guess comes down to how long we want to support mesa 18.x with latest
> > libdrm?? Maybe after 19.1, since (selfishly motivated) that gives me
> > a long enough window back in case I find myself needing to bisect for
> > some regression..
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH libdrm] headers: Sync with drm-next
On Wed, Apr 10, 2019 at 09:49:33PM -0400, Rob Clark wrote:
> On Tue, Apr 9, 2019 at 8:27 AM Eric Engestrom
> wrote:
> >
> > On Tuesday, 2019-04-09 12:59:13 +0100, Eric Engestrom wrote:
> > > On Tuesday, 2019-04-09 11:35:14 +, Ayan Halder wrote:
> > > > Generated using make headers_install from the drm-next
> > > > tree - git://anongit.freedesktop.org/drm/drm
> > > > branch - drm-next
> > > > commit - 14d2bd53a47a7e1cb3e03d00a6b952734cf90f3f
> > > >
> > > > The changes were as follows :-
> > > >
> > > > core: (drm.h, drm_fourcc.h, drm_mode.h)
> > > > - Added 'struct drm_syncobj_transfer', 'struct
> > > > drm_syncobj_timeline_wait' and 'struct drm_syncobj_timeline_array'
> > > > - Added various DRM_IOCTL_SYNCOBJ_ ioctls
> > > > - Added some new RGB and YUV formats
> > > > - Added 'DRM_FORMAT_MOD_VENDOR_ALLWINNER'
> > > > - Added 'SAMSUNG' and Arm's 'AFBC' and 'ALLWINNER' format modifiers
> > > > - Added 'struct drm_mode_rect'
> > > >
> > > > i915:
> > > > - Added struct 'struct i915_user_extension' and various 'struct
> > > > drm_i915_gem_context_'
> > > > - Added different modes of per-process Graphics Translation Table
> > > >
> > > > msm:
> > > > - Added various get or set GEM buffer info flags
> > > > - Added some MSM_SUBMIT_BO_ macros
> > > > - Modified 'struct drm_msm_gem_info'
> > > >
> > > > Signed-off-by: Ayan Kumar halder
> > >
> > > This looks sane, and applies cleanly :)
> > > Acked-by: Eric Engestrom
> >
> > Actually, revoking that, as this patch breaks the build; see below.
> >
> > >
> > > > ---
> > > > include/drm/drm.h| 36 +++
> > > > include/drm/drm_fourcc.h | 136 +++
> > > > include/drm/drm_mode.h | 23 -
> > > > include/drm/i915_drm.h | 237
> > > > ---
> > > > include/drm/msm_drm.h| 25 +++--
> > > > 5 files changed, 415 insertions(+), 42 deletions(-)
> > > >
> > [snip]
> > > > diff --git a/include/drm/msm_drm.h b/include/drm/msm_drm.h
> > > > index c06d0a5..91a16b3 100644
> > > > --- a/include/drm/msm_drm.h
> > > > +++ b/include/drm/msm_drm.h
> > > > @@ -105,14 +105,24 @@ struct drm_msm_gem_new {
> > > > __u32 handle; /* out */
> > > > };
> > > >
> > > > -#define MSM_INFO_IOVA 0x01
> > > > -
> > > > -#define MSM_INFO_FLAGS (MSM_INFO_IOVA)
> > > > +/* Get or set GEM buffer info. The requested value can be passed
> > > > + * directly in 'value', or for data larger than 64b 'value' is a
> > > > + * pointer to userspace buffer, with 'len' specifying the number of
> > > > + * bytes copied into that buffer. For info returned by pointer,
> > > > + * calling the GEM_INFO ioctl with null 'value' will return the
> > > > + * required buffer size in 'len'
> > > > + */
> > > > +#define MSM_INFO_GET_OFFSET0x00 /* get mmap() offset,
> > > > returned by value */
> > > > +#define MSM_INFO_GET_IOVA 0x01 /* get iova, returned by value */
> > > > +#define MSM_INFO_SET_NAME 0x02 /* set the debug name (by pointer) */
> > > > +#define MSM_INFO_GET_NAME 0x03 /* get debug name, returned by
> > > > pointer */
> > > >
> > > > struct drm_msm_gem_info {
> > > > __u32 handle; /* in */
> > > > - __u32 flags; /* in - combination of MSM_INFO_* flags */
> > > > - __u64 offset; /* out, mmap() offset or iova */
> > > > + __u32 info; /* in - one of MSM_INFO_* */
> > > > + __u64 value; /* in or out */
> > > > + __u32 len;/* in or out */
> > > > + __u32 pad;
> >
> > freedreno/msm/msm_bo.c needs to be updated to reflect those changes.
>
>
> I think you can just rename flags->info and offset->value, the rest of
> the struct should be zero-initialized.. if in doubt you can check
> $mesa/src/freedreno/drm/msm_bo.c
Sorry, I had dropped the changes to 'msm_drm.h' in my v2 patch (which
I had sent 10th April, 2019 titled '[PATCH libdrm v2] headers: Sync
with drm-next ') as I wasn't sure about the changes.
>
> side-note: the libdrm_freedreno code was folded into mesa in 19.
[PATCH libdrm v2] headers: Sync with drm-next
Generated using make headers_install from the drm-next
tree - git://anongit.freedesktop.org/drm/drm
branch - drm-next
commit - 14d2bd53a47a7e1cb3e03d00a6b952734cf90f3f
The changes were as follows :-
core: (drm.h, drm_fourcc.h, drm_mode.h)
- Added 'struct drm_syncobj_transfer', 'struct drm_syncobj_timeline_wait' and
'struct drm_syncobj_timeline_array'
- Added various DRM_IOCTL_SYNCOBJ_ ioctls
- Added some new RGB and YUV formats
- Added 'DRM_FORMAT_MOD_VENDOR_ALLWINNER'
- Added 'SAMSUNG' and Arm's 'AFBC' and 'ALLWINNER' format modifiers
- Added 'struct drm_mode_rect'
i915:
- Added struct 'struct i915_user_extension' and various 'struct
drm_i915_gem_context_'
- Added different modes of per-process Graphics Translation Table
Changes from v1:-
- Removed the changes to 'msm_drm.h' as it breaks the build for 'freedreno'
platform.
Signed-off-by: Ayan Kumar halder
/-- Note to reviewer:-
Please ignore the previous patch in this email thread.
--/
---
include/drm/drm.h| 36 +++
include/drm/drm_fourcc.h | 136 +++
include/drm/drm_mode.h | 23 -
include/drm/i915_drm.h | 237 ---
4 files changed, 396 insertions(+), 36 deletions(-)
diff --git a/include/drm/drm.h b/include/drm/drm.h
index 85c685a..c893f3b 100644
--- a/include/drm/drm.h
+++ b/include/drm/drm.h
@@ -729,8 +729,18 @@ struct drm_syncobj_handle {
__u32 pad;
};
+struct drm_syncobj_transfer {
+ __u32 src_handle;
+ __u32 dst_handle;
+ __u64 src_point;
+ __u64 dst_point;
+ __u32 flags;
+ __u32 pad;
+};
+
#define DRM_SYNCOBJ_WAIT_FLAGS_WAIT_ALL (1 << 0)
#define DRM_SYNCOBJ_WAIT_FLAGS_WAIT_FOR_SUBMIT (1 << 1)
+#define DRM_SYNCOBJ_WAIT_FLAGS_WAIT_AVAILABLE (1 << 2) /* wait for time point
to become available */
struct drm_syncobj_wait {
__u64 handles;
/* absolute timeout */
@@ -741,12 +751,33 @@ struct drm_syncobj_wait {
__u32 pad;
};
+struct drm_syncobj_timeline_wait {
+ __u64 handles;
+ /* wait on specific timeline point for every handles*/
+ __u64 points;
+ /* absolute timeout */
+ __s64 timeout_nsec;
+ __u32 count_handles;
+ __u32 flags;
+ __u32 first_signaled; /* only valid when not waiting all */
+ __u32 pad;
+};
+
+
struct drm_syncobj_array {
__u64 handles;
__u32 count_handles;
__u32 pad;
};
+struct drm_syncobj_timeline_array {
+ __u64 handles;
+ __u64 points;
+ __u32 count_handles;
+ __u32 pad;
+};
+
+
/* Query current scanout sequence number */
struct drm_crtc_get_sequence {
__u32 crtc_id; /* requested crtc_id */
@@ -903,6 +934,11 @@ extern "C" {
#define DRM_IOCTL_MODE_GET_LEASE DRM_IOWR(0xC8, struct
drm_mode_get_lease)
#define DRM_IOCTL_MODE_REVOKE_LEASEDRM_IOWR(0xC9, struct
drm_mode_revoke_lease)
+#define DRM_IOCTL_SYNCOBJ_TIMELINE_WAITDRM_IOWR(0xCA, struct
drm_syncobj_timeline_wait)
+#define DRM_IOCTL_SYNCOBJ_QUERYDRM_IOWR(0xCB, struct
drm_syncobj_timeline_array)
+#define DRM_IOCTL_SYNCOBJ_TRANSFER DRM_IOWR(0xCC, struct
drm_syncobj_transfer)
+#define DRM_IOCTL_SYNCOBJ_TIMELINE_SIGNAL DRM_IOWR(0xCD, struct
drm_syncobj_timeline_array)
+
/**
* Device specific ioctls should only be in their respective headers
* The device specific ioctl range is from 0x40 to 0x9f.
diff --git a/include/drm/drm_fourcc.h b/include/drm/drm_fourcc.h
index 139632b..3feeaa3 100644
--- a/include/drm/drm_fourcc.h
+++ b/include/drm/drm_fourcc.h
@@ -144,6 +144,17 @@ extern "C" {
#define DRM_FORMAT_RGBA1010102 fourcc_code('R', 'A', '3', '0') /* [31:0]
R:G:B:A 10:10:10:2 little endian */
#define DRM_FORMAT_BGRA1010102 fourcc_code('B', 'A', '3', '0') /* [31:0]
B:G:R:A 10:10:10:2 little endian */
+/*
+ * Floating point 64bpp RGB
+ * IEEE 754-2008 binary16 half-precision float
+ * [15:0] sign:exponent:mantissa 1:5:10
+ */
+#define DRM_FORMAT_XRGB16161616F fourcc_code('X', 'R', '4', 'H') /* [63:0]
x:R:G:B 16:16:16:16 little endian */
+#define DRM_FORMAT_XBGR16161616F fourcc_code('X', 'B', '4', 'H') /* [63:0]
x:B:G:R 16:16:16:16 little endian */
+
+#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 */
+
/* packed YCbCr */
#define DRM_FORMAT_YUYVfourcc_code('Y', 'U', 'Y', 'V') /*
[31:0] Cr0:Y1:Cb0:Y0 8:8:8:8 little endian */
#define DRM_FORMAT_YVYUfourcc_code('Y', 'V', 'Y', 'U') /*
[31:0] Cb0:Y1:Cr0:Y0 8:8:8:8 little endian */
@@ -151,6 +162,52 @@ extern "C" {
#define DRM_FORMAT_VYUYfourcc_code('V', 'Y', 'U', 'Y') /*
[31:0] Y1:Cb0:Y0:Cr0 8:8:8:8 little endian */
#define DRM_FORMAT_AYUVfourcc_code('A', 'Y', 'U', 'V') /*
[31:0] A:Y:Cb:Cr 8:8:8:8 little endian */
+#define
[PATCH libdrm v2] headers: Sync with drm-next
Generated using make headers_install from the drm-next
tree - git://anongit.freedesktop.org/drm/drm
branch - drm-next
commit - 14d2bd53a47a7e1cb3e03d00a6b952734cf90f3f
The changes were as follows :-
core: (drm.h, drm_fourcc.h, drm_mode.h)
- Added 'struct drm_syncobj_transfer', 'struct drm_syncobj_timeline_wait' and
'struct drm_syncobj_timeline_array'
- Added various DRM_IOCTL_SYNCOBJ_ ioctls
- Added some new RGB and YUV formats
- Added 'DRM_FORMAT_MOD_VENDOR_ALLWINNER'
- Added 'SAMSUNG' and Arm's 'AFBC' and 'ALLWINNER' format modifiers
- Added 'struct drm_mode_rect'
i915:
- Added struct 'struct i915_user_extension' and various 'struct
drm_i915_gem_context_'
- Added different modes of per-process Graphics Translation Table
Changes from v2:-
- Removed the changes to 'msm_drm.h' as it breaks the build for 'freedreno'
platform.
Change-Id: Ibfa8d4ceceae6f5bdc9d5f6b7ac658864ec03fc1
Signed-off-by: Ayan Kumar halder
---
include/drm/drm.h| 36 +++
include/drm/drm_fourcc.h | 136 +++
include/drm/drm_mode.h | 23 -
include/drm/i915_drm.h | 237 ---
4 files changed, 396 insertions(+), 36 deletions(-)
diff --git a/include/drm/drm.h b/include/drm/drm.h
index 85c685a..c893f3b 100644
--- a/include/drm/drm.h
+++ b/include/drm/drm.h
@@ -729,8 +729,18 @@ struct drm_syncobj_handle {
__u32 pad;
};
+struct drm_syncobj_transfer {
+ __u32 src_handle;
+ __u32 dst_handle;
+ __u64 src_point;
+ __u64 dst_point;
+ __u32 flags;
+ __u32 pad;
+};
+
#define DRM_SYNCOBJ_WAIT_FLAGS_WAIT_ALL (1 << 0)
#define DRM_SYNCOBJ_WAIT_FLAGS_WAIT_FOR_SUBMIT (1 << 1)
+#define DRM_SYNCOBJ_WAIT_FLAGS_WAIT_AVAILABLE (1 << 2) /* wait for time point
to become available */
struct drm_syncobj_wait {
__u64 handles;
/* absolute timeout */
@@ -741,12 +751,33 @@ struct drm_syncobj_wait {
__u32 pad;
};
+struct drm_syncobj_timeline_wait {
+ __u64 handles;
+ /* wait on specific timeline point for every handles*/
+ __u64 points;
+ /* absolute timeout */
+ __s64 timeout_nsec;
+ __u32 count_handles;
+ __u32 flags;
+ __u32 first_signaled; /* only valid when not waiting all */
+ __u32 pad;
+};
+
+
struct drm_syncobj_array {
__u64 handles;
__u32 count_handles;
__u32 pad;
};
+struct drm_syncobj_timeline_array {
+ __u64 handles;
+ __u64 points;
+ __u32 count_handles;
+ __u32 pad;
+};
+
+
/* Query current scanout sequence number */
struct drm_crtc_get_sequence {
__u32 crtc_id; /* requested crtc_id */
@@ -903,6 +934,11 @@ extern "C" {
#define DRM_IOCTL_MODE_GET_LEASE DRM_IOWR(0xC8, struct
drm_mode_get_lease)
#define DRM_IOCTL_MODE_REVOKE_LEASEDRM_IOWR(0xC9, struct
drm_mode_revoke_lease)
+#define DRM_IOCTL_SYNCOBJ_TIMELINE_WAITDRM_IOWR(0xCA, struct
drm_syncobj_timeline_wait)
+#define DRM_IOCTL_SYNCOBJ_QUERYDRM_IOWR(0xCB, struct
drm_syncobj_timeline_array)
+#define DRM_IOCTL_SYNCOBJ_TRANSFER DRM_IOWR(0xCC, struct
drm_syncobj_transfer)
+#define DRM_IOCTL_SYNCOBJ_TIMELINE_SIGNAL DRM_IOWR(0xCD, struct
drm_syncobj_timeline_array)
+
/**
* Device specific ioctls should only be in their respective headers
* The device specific ioctl range is from 0x40 to 0x9f.
diff --git a/include/drm/drm_fourcc.h b/include/drm/drm_fourcc.h
index 139632b..3feeaa3 100644
--- a/include/drm/drm_fourcc.h
+++ b/include/drm/drm_fourcc.h
@@ -144,6 +144,17 @@ extern "C" {
#define DRM_FORMAT_RGBA1010102 fourcc_code('R', 'A', '3', '0') /* [31:0]
R:G:B:A 10:10:10:2 little endian */
#define DRM_FORMAT_BGRA1010102 fourcc_code('B', 'A', '3', '0') /* [31:0]
B:G:R:A 10:10:10:2 little endian */
+/*
+ * Floating point 64bpp RGB
+ * IEEE 754-2008 binary16 half-precision float
+ * [15:0] sign:exponent:mantissa 1:5:10
+ */
+#define DRM_FORMAT_XRGB16161616F fourcc_code('X', 'R', '4', 'H') /* [63:0]
x:R:G:B 16:16:16:16 little endian */
+#define DRM_FORMAT_XBGR16161616F fourcc_code('X', 'B', '4', 'H') /* [63:0]
x:B:G:R 16:16:16:16 little endian */
+
+#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 */
+
/* packed YCbCr */
#define DRM_FORMAT_YUYVfourcc_code('Y', 'U', 'Y', 'V') /*
[31:0] Cr0:Y1:Cb0:Y0 8:8:8:8 little endian */
#define DRM_FORMAT_YVYUfourcc_code('Y', 'V', 'Y', 'U') /*
[31:0] Cb0:Y1:Cr0:Y0 8:8:8:8 little endian */
@@ -151,6 +162,52 @@ extern "C" {
#define DRM_FORMAT_VYUYfourcc_code('V', 'Y', 'U', 'Y') /*
[31:0] Y1:Cb0:Y0:Cr0 8:8:8:8 little endian */
#define DRM_FORMAT_AYUVfourcc_code('A', 'Y', 'U', 'V') /*
[31:0] A:Y:Cb:Cr 8:8:8:8 little endian */
+#define DRM_FORMAT_XYUVfourcc_code('X', 'Y', 'U',
[PATCH libdrm] headers: Sync with drm-next
Generated using make headers_install from the drm-next
tree - git://anongit.freedesktop.org/drm/drm
branch - drm-next
commit - 14d2bd53a47a7e1cb3e03d00a6b952734cf90f3f
The changes were as follows :-
core: (drm.h, drm_fourcc.h, drm_mode.h)
- Added 'struct drm_syncobj_transfer', 'struct drm_syncobj_timeline_wait' and
'struct drm_syncobj_timeline_array'
- Added various DRM_IOCTL_SYNCOBJ_ ioctls
- Added some new RGB and YUV formats
- Added 'DRM_FORMAT_MOD_VENDOR_ALLWINNER'
- Added 'SAMSUNG' and Arm's 'AFBC' and 'ALLWINNER' format modifiers
- Added 'struct drm_mode_rect'
i915:
- Added struct 'struct i915_user_extension' and various 'struct
drm_i915_gem_context_'
- Added different modes of per-process Graphics Translation Table
msm:
- Added various get or set GEM buffer info flags
- Added some MSM_SUBMIT_BO_ macros
- Modified 'struct drm_msm_gem_info'
Signed-off-by: Ayan Kumar halder
---
include/drm/drm.h| 36 +++
include/drm/drm_fourcc.h | 136 +++
include/drm/drm_mode.h | 23 -
include/drm/i915_drm.h | 237 ---
include/drm/msm_drm.h| 25 +++--
5 files changed, 415 insertions(+), 42 deletions(-)
diff --git a/include/drm/drm.h b/include/drm/drm.h
index 85c685a..c893f3b 100644
--- a/include/drm/drm.h
+++ b/include/drm/drm.h
@@ -729,8 +729,18 @@ struct drm_syncobj_handle {
__u32 pad;
};
+struct drm_syncobj_transfer {
+ __u32 src_handle;
+ __u32 dst_handle;
+ __u64 src_point;
+ __u64 dst_point;
+ __u32 flags;
+ __u32 pad;
+};
+
#define DRM_SYNCOBJ_WAIT_FLAGS_WAIT_ALL (1 << 0)
#define DRM_SYNCOBJ_WAIT_FLAGS_WAIT_FOR_SUBMIT (1 << 1)
+#define DRM_SYNCOBJ_WAIT_FLAGS_WAIT_AVAILABLE (1 << 2) /* wait for time point
to become available */
struct drm_syncobj_wait {
__u64 handles;
/* absolute timeout */
@@ -741,12 +751,33 @@ struct drm_syncobj_wait {
__u32 pad;
};
+struct drm_syncobj_timeline_wait {
+ __u64 handles;
+ /* wait on specific timeline point for every handles*/
+ __u64 points;
+ /* absolute timeout */
+ __s64 timeout_nsec;
+ __u32 count_handles;
+ __u32 flags;
+ __u32 first_signaled; /* only valid when not waiting all */
+ __u32 pad;
+};
+
+
struct drm_syncobj_array {
__u64 handles;
__u32 count_handles;
__u32 pad;
};
+struct drm_syncobj_timeline_array {
+ __u64 handles;
+ __u64 points;
+ __u32 count_handles;
+ __u32 pad;
+};
+
+
/* Query current scanout sequence number */
struct drm_crtc_get_sequence {
__u32 crtc_id; /* requested crtc_id */
@@ -903,6 +934,11 @@ extern "C" {
#define DRM_IOCTL_MODE_GET_LEASE DRM_IOWR(0xC8, struct
drm_mode_get_lease)
#define DRM_IOCTL_MODE_REVOKE_LEASEDRM_IOWR(0xC9, struct
drm_mode_revoke_lease)
+#define DRM_IOCTL_SYNCOBJ_TIMELINE_WAITDRM_IOWR(0xCA, struct
drm_syncobj_timeline_wait)
+#define DRM_IOCTL_SYNCOBJ_QUERYDRM_IOWR(0xCB, struct
drm_syncobj_timeline_array)
+#define DRM_IOCTL_SYNCOBJ_TRANSFER DRM_IOWR(0xCC, struct
drm_syncobj_transfer)
+#define DRM_IOCTL_SYNCOBJ_TIMELINE_SIGNAL DRM_IOWR(0xCD, struct
drm_syncobj_timeline_array)
+
/**
* Device specific ioctls should only be in their respective headers
* The device specific ioctl range is from 0x40 to 0x9f.
diff --git a/include/drm/drm_fourcc.h b/include/drm/drm_fourcc.h
index 139632b..3feeaa3 100644
--- a/include/drm/drm_fourcc.h
+++ b/include/drm/drm_fourcc.h
@@ -144,6 +144,17 @@ extern "C" {
#define DRM_FORMAT_RGBA1010102 fourcc_code('R', 'A', '3', '0') /* [31:0]
R:G:B:A 10:10:10:2 little endian */
#define DRM_FORMAT_BGRA1010102 fourcc_code('B', 'A', '3', '0') /* [31:0]
B:G:R:A 10:10:10:2 little endian */
+/*
+ * Floating point 64bpp RGB
+ * IEEE 754-2008 binary16 half-precision float
+ * [15:0] sign:exponent:mantissa 1:5:10
+ */
+#define DRM_FORMAT_XRGB16161616F fourcc_code('X', 'R', '4', 'H') /* [63:0]
x:R:G:B 16:16:16:16 little endian */
+#define DRM_FORMAT_XBGR16161616F fourcc_code('X', 'B', '4', 'H') /* [63:0]
x:B:G:R 16:16:16:16 little endian */
+
+#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 */
+
/* packed YCbCr */
#define DRM_FORMAT_YUYVfourcc_code('Y', 'U', 'Y', 'V') /*
[31:0] Cr0:Y1:Cb0:Y0 8:8:8:8 little endian */
#define DRM_FORMAT_YVYUfourcc_code('Y', 'V', 'Y', 'U') /*
[31:0] Cb0:Y1:Cr0:Y0 8:8:8:8 little endian */
@@ -151,6 +162,52 @@ extern "C" {
#define DRM_FORMAT_VYUYfourcc_code('V', 'Y', 'U', 'Y') /*
[31:0] Y1:Cb0:Y0:Cr0 8:8:8:8 little endian */
#define DRM_FORMAT_AYUVfourcc_code('A', 'Y', 'U', 'V') /*
[31:0] A:Y:Cb:Cr 8:8:8:8 little endian */
+#define DRM_FORMAT_XYUVfourcc_code('X',
[PATCH libdrm] headers: Sync with drm-next
Generated using make headers_install from the drm-next
tree - git://anongit.freedesktop.org/drm/drm
branch - drm-next
commit - 14d2bd53a47a7e1cb3e03d00a6b952734cf90f3f
The changes were as follows :-
core: (drm.h, drm_fourcc.h, drm_mode.h)
- Added 'struct drm_syncobj_transfer', 'struct drm_syncobj_timeline_wait' and
'struct drm_syncobj_timeline_array'
- Added various DRM_IOCTL_SYNCOBJ_ ioctls
- Added some new RGB and YUV formats
- Added 'DRM_FORMAT_MOD_VENDOR_ALLWINNER'
- Added 'SAMSUNG' and Arm's 'AFBC' and 'ALLWINNER' format modifiers
- Added 'struct drm_mode_rect'
i915:
- Added struct 'struct i915_user_extension' and various 'struct
drm_i915_gem_context_'
- Added different modes of per-process Graphics Translation Table
msm:
- Added various get or set GEM buffer info flags
- Added some MSM_SUBMIT_BO_ macros
- Modified 'struct drm_msm_gem_info'
Signed-off-by: Ayan Kumar halder
---
include/drm/drm.h| 36 +++
include/drm/drm_fourcc.h | 136 +++
include/drm/drm_mode.h | 23 -
include/drm/i915_drm.h | 237 ---
include/drm/msm_drm.h| 25 +++--
5 files changed, 415 insertions(+), 42 deletions(-)
diff --git a/include/drm/drm.h b/include/drm/drm.h
index 85c685a..c893f3b 100644
--- a/include/drm/drm.h
+++ b/include/drm/drm.h
@@ -729,8 +729,18 @@ struct drm_syncobj_handle {
__u32 pad;
};
+struct drm_syncobj_transfer {
+__u32 src_handle;
+__u32 dst_handle;
+__u64 src_point;
+__u64 dst_point;
+__u32 flags;
+__u32 pad;
+};
+
#define DRM_SYNCOBJ_WAIT_FLAGS_WAIT_ALL (1 << 0)
#define DRM_SYNCOBJ_WAIT_FLAGS_WAIT_FOR_SUBMIT (1 << 1)
+#define DRM_SYNCOBJ_WAIT_FLAGS_WAIT_AVAILABLE (1 << 2) /* wait for time point
to become available */
struct drm_syncobj_wait {
__u64 handles;
/* absolute timeout */
@@ -741,12 +751,33 @@ struct drm_syncobj_wait {
__u32 pad;
};
+struct drm_syncobj_timeline_wait {
+__u64 handles;
+/* wait on specific timeline point for every handles*/
+__u64 points;
+/* absolute timeout */
+__s64 timeout_nsec;
+__u32 count_handles;
+__u32 flags;
+__u32 first_signaled; /* only valid when not waiting all */
+__u32 pad;
+};
+
+
struct drm_syncobj_array {
__u64 handles;
__u32 count_handles;
__u32 pad;
};
+struct drm_syncobj_timeline_array {
+__u64 handles;
+__u64 points;
+__u32 count_handles;
+__u32 pad;
+};
+
+
/* Query current scanout sequence number */
struct drm_crtc_get_sequence {
__u32 crtc_id;/* requested crtc_id */
@@ -903,6 +934,11 @@ extern "C" {
#define DRM_IOCTL_MODE_GET_LEASEDRM_IOWR(0xC8, struct drm_mode_get_lease)
#define DRM_IOCTL_MODE_REVOKE_LEASEDRM_IOWR(0xC9, struct drm_mode_revoke_lease)
+#define DRM_IOCTL_SYNCOBJ_TIMELINE_WAITDRM_IOWR(0xCA, struct
drm_syncobj_timeline_wait)
+#define DRM_IOCTL_SYNCOBJ_QUERYDRM_IOWR(0xCB, struct
drm_syncobj_timeline_array)
+#define DRM_IOCTL_SYNCOBJ_TRANSFERDRM_IOWR(0xCC, struct drm_syncobj_transfer)
+#define DRM_IOCTL_SYNCOBJ_TIMELINE_SIGNALDRM_IOWR(0xCD, struct
drm_syncobj_timeline_array)
+
/**
* Device specific ioctls should only be in their respective headers
* The device specific ioctl range is from 0x40 to 0x9f.
diff --git a/include/drm/drm_fourcc.h b/include/drm/drm_fourcc.h
index 139632b..3feeaa3 100644
--- a/include/drm/drm_fourcc.h
+++ b/include/drm/drm_fourcc.h
@@ -144,6 +144,17 @@ extern "C" {
#define DRM_FORMAT_RGBA1010102fourcc_code('R', 'A', '3', '0') /* [31:0]
R:G:B:A 10:10:10:2 little endian */
#define DRM_FORMAT_BGRA1010102fourcc_code('B', 'A', '3', '0') /* [31:0]
B:G:R:A 10:10:10:2 little endian */
+/*
+ * Floating point 64bpp RGB
+ * IEEE 754-2008 binary16 half-precision float
+ * [15:0] sign:exponent:mantissa 1:5:10
+ */
+#define DRM_FORMAT_XRGB16161616F fourcc_code('X', 'R', '4', 'H') /* [63:0]
x:R:G:B 16:16:16:16 little endian */
+#define DRM_FORMAT_XBGR16161616F fourcc_code('X', 'B', '4', 'H') /* [63:0]
x:B:G:R 16:16:16:16 little endian */
+
+#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 */
+
/* packed YCbCr */
#define DRM_FORMAT_YUYVfourcc_code('Y', 'U', 'Y', 'V') /* [31:0] Cr0:Y1:Cb0:Y0
8:8:8:8 little endian */
#define DRM_FORMAT_YVYUfourcc_code('Y', 'V', 'Y', 'U') /* [31:0] Cb0:Y1:Cr0:Y0
8:8:8:8 little endian */
@@ -151,6 +162,52 @@ extern "C" {
#define DRM_FORMAT_VYUYfourcc_code('V', 'Y', 'U', 'Y') /* [31:0] Y1:Cb0:Y0:Cr0
8:8:8:8 little endian */
#define DRM_FORMAT_AYUVfourcc_code('A', 'Y', 'U', 'V') /* [31:0] A:Y:Cb:Cr
8:8:8:8 little endian */
+#define DRM_FORMAT_XYUVfourcc_code('X', 'Y', 'U', 'V') /* [31:0] X:Y:Cb:Cr
8:8:8:8 little endian */
+#define DRM_FORMAT_VUY888fourcc_code('V', 'U', '2', '4') /* [23:0] Cr:Cb:Y
8:8:8 little endian */
+#define DRM_FORMAT_VUY101010fourcc_code('V', 'U', '3', '0') /* Y followed by U
then V, 10:10:10. Non-linear modifier only */
+
+/*
+ * packed Y2xx indicate for each
Re: [RFC PATCH] drm/komeda: fixing of DMA mapping sg segment warning
On Thu, Mar 28, 2019 at 07:25:00AM +, Lowry Li (Arm Technology China) wrote:
> Fixing the DMA mapping sg segment warning, which shows "DMA-API: mapping
> sg segment longer than device claims to support [len=921600] [max=65536]".
> Fixed by setting the max segment size at Komeda driver.
>
> Signed-off-by: Lowry Li
> ---
> drivers/gpu/drm/arm/display/komeda/komeda_dev.c | 4
> drivers/gpu/drm/arm/display/komeda/komeda_dev.h | 1 +
> 2 files changed, 5 insertions(+)
>
> diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_dev.c
> b/drivers/gpu/drm/arm/display/komeda/komeda_dev.c
> index 7f25e6a..b4902ae 100644
> --- a/drivers/gpu/drm/arm/display/komeda/komeda_dev.c
> +++ b/drivers/gpu/drm/arm/display/komeda/komeda_dev.c
> @@ -8,6 +8,7 @@
> #include
> #include
> #include
> +#include
> #ifdef CONFIG_DEBUG_FS
> #include
> #include
> @@ -245,6 +246,9 @@ struct komeda_dev *komeda_dev_create(struct device *dev)
> goto err_cleanup;
> }
>
> + dev->dma_parms = >dma_parms;
> + dma_set_max_seg_size(dev, DMA_BIT_MASK(32));
> +
> err = sysfs_create_group(>kobj, _sysfs_attr_group);
> if (err) {
> DRM_ERROR("create sysfs group failed.\n");
> diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_dev.h
> b/drivers/gpu/drm/arm/display/komeda/komeda_dev.h
> index 0c3e32b..d8cfa92 100644
> --- a/drivers/gpu/drm/arm/display/komeda/komeda_dev.h
> +++ b/drivers/gpu/drm/arm/display/komeda/komeda_dev.h
> @@ -146,6 +146,7 @@ enum {
> */
> struct komeda_dev {
> struct device *dev;
> + struct device_dma_parameters dma_parms;
> u32 __iomem *reg_base;
>
> struct komeda_chip_info chip;
> --
Please rebase and test your patches on drm-misc-next.
https://drm.pages.freedesktop.org/maintainer-tools/repositories.html
> 1.9.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC PATCH] drm/komeda: Creates plane alpha and blend mode properties
On Fri, Mar 29, 2019 at 06:44:45AM +, Lowry Li (Arm Technology China) wrote: > Creates plane alpha and blend mode properties attached to plane. > > Signed-off-by: Lowry Li > --- > drivers/gpu/drm/arm/display/komeda/komeda_plane.c | 11 +++ > 1 file changed, 11 insertions(+) > > diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_plane.c > b/drivers/gpu/drm/arm/display/komeda/komeda_plane.c > index af51f0c..0ebec39 100644 > --- a/drivers/gpu/drm/arm/display/komeda/komeda_plane.c > +++ b/drivers/gpu/drm/arm/display/komeda/komeda_plane.c > @@ -212,6 +212,17 @@ static int komeda_plane_add(struct komeda_kms_dev *kms, > > drm_plane_helper_add(plane, _plane_helper_funcs); > > + err = drm_plane_create_alpha_property(plane); > + if (err) > + goto cleanup; > + > + err = drm_plane_create_blend_mode_property(plane, > + BIT(DRM_MODE_BLEND_PIXEL_NONE) | > + BIT(DRM_MODE_BLEND_PREMULTI) | > + BIT(DRM_MODE_BLEND_COVERAGE)); > + if (err) > + goto cleanup; > + > return 0; > cleanup: > komeda_plane_destroy(plane); > -- Please rebase and test your patches on drm-misc-next. https://drm.pages.freedesktop.org/maintainer-tools/repositories.html > 1.9.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/fourcc: Fix conflicting Y41x definitions
On Tue, Mar 19, 2019 at 01:17:02PM +0100, Maarten Lankhorst wrote:
> There has unfortunately been a conflict with the following 3 commits:
>
> commit e9961ab95af81b8d29054361cd5f0c575102cf87
> Author: Ayan Kumar Halder
> Date: Fri Nov 9 17:21:12 2018 +
> drm: Added a new format DRM_FORMAT_XVYU2101010
>
> commit 7ba0fee247ee7a36b3bfbed68f6988d980aa3aa3
> Author: Brian Starkey
> Date: Fri Oct 5 10:27:00 2018 +0100
>
> drm/fourcc: Add AFBC yuv fourccs for Mali
>
> and
>
> commit 50bf5d7d595fd0705ef3785f80e679b6da501e5b
> Author: Swati Sharma
> Date: Mon Mar 4 17:26:33 2019 +0530
>
> drm: Add Y2xx and Y4xx (xx:10/12/16) format definitions and fourcc
>
> Unfortunately gcc didn't warn about the redefinitions, because the
>
> Fix this by using new XYVU for i915, without alpha, and making the
> Y41x definitions match msdn, with alpha.
>
> Fortunately we caught it early, and the conflict hasn't even landed in
> drm-next yet.
>
> Signed-off-by: Maarten Lankhorst
> Cc: Brian Starkey
> Cc: Swati Sharma
> Cc: Ayan Kumar Halder
> Cc: mal...@foss.arm.com
> Cc: Daniel Vetter
> Cc: Maxime Ripard
> Cc: Sean Paul
> Cc: Dave Airlie
> Cc: Liviu Dudau
> ---
> drivers/gpu/drm/drm_fourcc.c | 12 +--
> drivers/gpu/drm/i915/intel_display.c | 18 -
> drivers/gpu/drm/i915/intel_sprite.c | 30 ++--
> include/uapi/drm/drm_fourcc.h| 21 +--
> 4 files changed, 41 insertions(+), 40 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_fourcc.c b/drivers/gpu/drm/drm_fourcc.c
> index b914b16db9b2..6ea55fb4526d 100644
> --- a/drivers/gpu/drm/drm_fourcc.c
> +++ b/drivers/gpu/drm/drm_fourcc.c
> @@ -229,17 +229,17 @@ const struct drm_format_info *__drm_format_info(u32
> format)
> { .format = DRM_FORMAT_UYVY,.depth = 0,
> .num_planes = 1, .cpp = { 2, 0, 0 }, .hsub = 2, .vsub = 1, .is_yuv = true },
> { .format = DRM_FORMAT_VYUY,.depth = 0,
> .num_planes = 1, .cpp = { 2, 0, 0 }, .hsub = 2, .vsub = 1, .is_yuv = true },
> { .format = DRM_FORMAT_XYUV,.depth = 0,
> .num_planes = 1, .cpp = { 4, 0, 0 }, .hsub = 1, .vsub = 1, .is_yuv = true },
> - { .format = DRM_FORMAT_Y210,.depth = 0,
> .num_planes = 1, .cpp = { 4, 0, 0 }, .hsub = 2, .vsub = 1, .is_yuv = true },
> { .format = DRM_FORMAT_VUY888, .depth = 0,
> .num_planes = 1, .cpp = { 3, 0, 0 }, .hsub = 1, .vsub = 1, .is_yuv = true },
> - { .format = DRM_FORMAT_Y410,.depth = 0,
> .num_planes = 1, .cpp = { 4, 0, 0 }, .hsub = 1, .vsub = 1, .has_alpha = true,
> .is_yuv = true },
> { .format = DRM_FORMAT_AYUV,.depth = 0,
> .num_planes = 1, .cpp = { 4, 0, 0 }, .hsub = 1, .vsub = 1, .has_alpha = true,
> .is_yuv = true },
> - { .format = DRM_FORMAT_XVYU2101010, .depth = 0,
> .num_planes = 1, .cpp = { 4, 0, 0 }, .hsub = 1, .vsub = 1, .is_yuv = true },
> { .format = DRM_FORMAT_Y210,.depth = 0,
> .num_planes = 1, .cpp = { 4, 0, 0 }, .hsub = 2, .vsub = 1, .is_yuv = true },
> { .format = DRM_FORMAT_Y212,.depth = 0,
> .num_planes = 1, .cpp = { 4, 0, 0 }, .hsub = 2, .vsub = 1, .is_yuv = true },
> { .format = DRM_FORMAT_Y216,.depth = 0,
> .num_planes = 1, .cpp = { 4, 0, 0 }, .hsub = 2, .vsub = 1, .is_yuv = true },
> - { .format = DRM_FORMAT_Y410,.depth = 0,
> .num_planes = 1, .cpp = { 4, 0, 0 }, .hsub = 1, .vsub = 1, .is_yuv = true },
> - { .format = DRM_FORMAT_Y412,.depth = 0,
> .num_planes = 1, .cpp = { 8, 0, 0 }, .hsub = 1, .vsub = 1, .is_yuv = true },
> - { .format = DRM_FORMAT_Y416,.depth = 0,
> .num_planes = 1, .cpp = { 8, 0, 0 }, .hsub = 1, .vsub = 1, .is_yuv = true },
> + { .format = DRM_FORMAT_Y410,.depth = 0,
> .num_planes = 1, .cpp = { 4, 0, 0 }, .hsub = 1, .vsub = 1, .has_alpha = true,
> .is_yuv = true },
> + { .format = DRM_FORMAT_Y412,.depth = 0,
> .num_planes = 1, .cpp = { 8, 0, 0 }, .hsub = 1, .vsub = 1, .has_alpha = true,
> .is_yuv = true },
> + { .format = DRM_FORMAT_Y416,.depth = 0,
> .num_planes = 1, .cpp = { 8, 0, 0 }, .hsub = 1, .vsub = 1, .has_alpha = true,
> .is_yuv = true },
> + { .format = DRM_FORMAT_XVYU2101010, .depth = 0,
> .num_planes = 1, .cpp = { 4, 0, 0 }, .hsub = 1, .vsub = 1, .is_yuv = true },
> + { .format = DRM_FORMAT_XVYU12_16161616, .depth = 0,
> .num_planes = 1, .cpp = { 8, 0, 0 }, .hsub = 1, .vsub = 1, .is_yuv = true },
> + { .format = DRM_FORMAT_XVYU16161616,.depth = 0,
> .num_planes = 1, .cpp = { 8, 0, 0 }, .hsub = 1, .vsub = 1, .is_yuv = true },
> { .format = DRM_FORMAT_Y0L0,.depth = 0,
> .num_planes = 1,
>
Re: [PATCH v4 01/10] drm/fourcc: Add AFBC yuv fourccs for Mali
On Mon, Mar 18, 2019 at 07:12:24PM +0100, Maarten Lankhorst wrote: > Op 18-03-2019 om 16:40 schreef Brian Starkey: > > Hi, > > > > On Mon, Mar 18, 2019 at 11:17:55AM +0100, Maarten Lankhorst wrote: > > > > > > > >> Hey.. > >> > >> There's a conflict with this patch and the merge of topic/hdr-formats, > >> resulting in double definitions for Y210, Y410 and P010. > >> > >> Worse still is that one has set has_alpha to true for Y41x and other to > >> false. > >> > >> ~Maarten > >> > > Oh that's sad :-( I think this fell through the cracks on our side > > when someone left our team. Also turns out I'm not subscribed to > > igt-dev. > > > > I see you commented the same on one of the previous patches, and that > > there was some discussion of this on the test patches too. > > > > I have been referring to Microsoft's page[1] as "the" source for these > > formats, which does indeed call out Y410 as having 2 bits of alpha. > > Our GPU expects alpha. > > Ah. Yeah there has been discussion on whether there was supposed to be alpha > or not, but the original discussion on HDR formats has been completely > ignored by arm. > > The patch had originally a few arm devs on cc and was sent to dri-devel with > linux-media cc'd. Was sad to see it completely ignored so after having been > sent twice I pushed it. Apologies, I see that I was cc-ed in the mail 'drm: Add Y2xx and Y4xx (xx:10/12/16) format definitions and fourcc' sent by swati2.sha...@intel.com. It got lost in my pile of unread mails. :( About this patch, I had tagged you in irc channel (https://people.freedesktop.org/~cbrill/dri-log/?channel=dri-devel_names==2019-03-11_html=true) for reviewing this seies. Did not hear back from you then ? > > > Was there a specific reason for opting to change the test instead of > > the definition? Any way to get this changed now? > > > > It doesn't seem that sensible for the kernel to call something Y410 > > which doesn't match an "existing" definition by the same name. If > > alpha needs to be ignored on scanout, the alpha blend mode property > > can be used (more archaeology - I see that was still giving CRC > > failures, but that might be a "known issue" for all YUV on your HW?) > > Were a few bugs, but should be fixed now. :) > > Well only that we didn't have hw supporting alpha, and didn't hear back from > others so we went without alpha. In light of the suggestions made by brian.star...@arm.com, I think changing the format from Y410 to X410 (in your case) might make sense as the alpha bits are absent. If this suggestion looks reasonable to you, I can volunteer myself to make this change in topic/hdr-formats. > > > -Brian > > > > [1] > > https://docs.microsoft.com/en-us/windows/desktop/medfound/10-bit-and-16-bit-yuv-video-formats#444-formats > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/selftest:- Adding a new format(whose cpp=0) to be tested by igt_check_drm_format_min_pitch
We have introduced some new formats DRM_FORMAT_VUY101010, DRM_FORMAT_YUV420_8BIT, and DRM_FORMAT_YUV420_10BIT whose cpp is 0 (as they are defined in bits per pixel). We need to ensure that the pitch returned by drm_format_info_min_pitch() for such formats is always 0. Signed-off-by: Ayan Kumar halder Depends on:- https://patchwork.freedesktop.org/patch/msgid/1552414556-5756-1-git-send-email-ayan.hal...@arm.com --- drivers/gpu/drm/selftests/test-drm_format.c | 9 + 1 file changed, 9 insertions(+) diff --git a/drivers/gpu/drm/selftests/test-drm_format.c b/drivers/gpu/drm/selftests/test-drm_format.c index c5e212a..155e4ce 100644 --- a/drivers/gpu/drm/selftests/test-drm_format.c +++ b/drivers/gpu/drm/selftests/test-drm_format.c @@ -276,5 +276,14 @@ int igt_check_drm_format_min_pitch(void *ignored) FAIL_ON(drm_format_info_min_pitch(info, 0, UINT_MAX - 1) != (uint64_t)(UINT_MAX - 1) * 2); + /* Test format with cpp/char_per_block 0 */ + info = drm_format_info(DRM_FORMAT_VUY101010); + FAIL_ON(!info); + FAIL_ON(drm_format_info_min_pitch(info, 0, 0) != 0); + FAIL_ON(drm_format_info_min_pitch(info, -1, 0) != 0); + FAIL_ON(drm_format_info_min_pitch(info, 1, 0) != 0); + FAIL_ON(drm_format_info_min_pitch(info, 0, 1) != 0); + FAIL_ON(drm_format_info_min_pitch(info, 0, UINT_MAX) != 0); + return 0; } -- 2.7.4 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 10/10] drm/arm/malidp: Added support for AFBC modifiers for all layers except DE_SMART
From: Ayan Kumar Halder
The list of modifiers to be supported for each plane has been dynamically
generated
from 'malidp_format_modifiers[]' and 'malidp_hw_regmap->features'.
Changes from v1:-
1. Replaced DRM_ERROR() with DRM_DEBUG_KMS() in malidp_format_mod_supported()
to report unsupported modifiers.
Changes from v2:-
1. Removed malidp_format_mod_supported() from the current patch. This has been
added
in "PATCH 7/12"
2. Dynamically generate the list of modifiers (to be supported for each plane)
from
'malidp_format_modifiers' and features.
Changes since v3 (series):
- Added the ack
- Rebased on the latest drm-misc-next
Signed-off-by: Ayan Kumar halder
Reviewed-by: Liviu Dudau
Acked-by: Alyssa Rosenzweig
---
drivers/gpu/drm/arm/malidp_drv.c| 1 +
drivers/gpu/drm/arm/malidp_planes.c | 31 ---
2 files changed, 29 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/arm/malidp_drv.c b/drivers/gpu/drm/arm/malidp_drv.c
index 4106f5d..21725c9 100644
--- a/drivers/gpu/drm/arm/malidp_drv.c
+++ b/drivers/gpu/drm/arm/malidp_drv.c
@@ -391,6 +391,7 @@ static int malidp_init(struct drm_device *drm)
drm->mode_config.max_height = hwdev->max_line_size;
drm->mode_config.funcs = _mode_config_funcs;
drm->mode_config.helper_private = _mode_config_helpers;
+ drm->mode_config.allow_fb_modifiers = true;
ret = malidp_crtc_init(drm);
if (ret)
diff --git a/drivers/gpu/drm/arm/malidp_planes.c
b/drivers/gpu/drm/arm/malidp_planes.c
index 044bf7f..d42e0ea 100644
--- a/drivers/gpu/drm/arm/malidp_planes.c
+++ b/drivers/gpu/drm/arm/malidp_planes.c
@@ -939,7 +939,26 @@ int malidp_de_planes_init(struct drm_device *drm)
BIT(DRM_MODE_BLEND_PREMULTI) |
BIT(DRM_MODE_BLEND_COVERAGE);
u32 *formats;
- int ret, i, j, n;
+ int ret, i = 0, j = 0, n;
+ u64 supported_modifiers[MODIFIERS_COUNT_MAX];
+ const u64 *modifiers;
+
+ modifiers = malidp_format_modifiers;
+
+ if (!(map->features & MALIDP_DEVICE_AFBC_SUPPORT_SPLIT)) {
+ /*
+* Since our hardware does not support SPLIT, so build the list
+* of supported modifiers excluding SPLIT ones.
+*/
+ while (*modifiers != DRM_FORMAT_MOD_INVALID) {
+ if (!(*modifiers & AFBC_SPLIT))
+ supported_modifiers[j++] = *modifiers;
+
+ modifiers++;
+ }
+ supported_modifiers[j++] = DRM_FORMAT_MOD_INVALID;
+ modifiers = supported_modifiers;
+ }
formats = kcalloc(map->n_pixel_formats, sizeof(*formats), GFP_KERNEL);
if (!formats) {
@@ -964,9 +983,15 @@ int malidp_de_planes_init(struct drm_device *drm)
plane_type = (i == 0) ? DRM_PLANE_TYPE_PRIMARY :
DRM_PLANE_TYPE_OVERLAY;
+
+ /*
+* All the layers except smart layer supports AFBC modifiers.
+*/
ret = drm_universal_plane_init(drm, >base, crtcs,
- _de_plane_funcs, formats,
- n, NULL, plane_type, NULL);
+ _de_plane_funcs, formats, n,
+ (id == DE_SMART) ? NULL : modifiers, plane_type,
+ NULL);
+
if (ret < 0)
goto cleanup;
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 08/10] drm/arm/malidp:- Use the newly introduced malidp_format_get_bpp() instead of relying on cpp for calculating framebuffer size
From: Ayan Kumar Halder
Formats like DRM_FORMAT_VUY101010, DRM_FORMAT_YUV420_8BIT and
DRM_FORMAT_YUV420_10BIT are expressed in bits per pixel as they have a non
integer value of cpp (thus denoted as '0' in drm_format_info[]). Therefore,
the calculation of AFBC framebuffer size needs to use malidp_format_get_bpp().
Changes since v3 (series):
- Added the ack
- Rebased on the latest drm-misc-next
Signed-off-by: Ayan Kumar halder
Reviewed-by: Liviu Dudau
Acked-by: Alyssa Rosenzweig
---
drivers/gpu/drm/arm/malidp_drv.c | 15 ++-
1 file changed, 10 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/arm/malidp_drv.c b/drivers/gpu/drm/arm/malidp_drv.c
index c697664..4106f5d 100644
--- a/drivers/gpu/drm/arm/malidp_drv.c
+++ b/drivers/gpu/drm/arm/malidp_drv.c
@@ -298,6 +298,7 @@ malidp_verify_afbc_framebuffer_size(struct drm_device *dev,
struct drm_gem_object *objs = NULL;
u32 afbc_superblock_size = 0, afbc_superblock_height = 0;
u32 afbc_superblock_width = 0, afbc_size = 0;
+ int bpp = 0;
switch (mode_cmd->modifier[0] & AFBC_SIZE_MASK) {
case AFBC_SIZE_16X16:
@@ -314,15 +315,19 @@ malidp_verify_afbc_framebuffer_size(struct drm_device
*dev,
n_superblocks = (mode_cmd->width / afbc_superblock_width) *
(mode_cmd->height / afbc_superblock_height);
- afbc_superblock_size = info->cpp[0] * afbc_superblock_width *
- afbc_superblock_height;
+ bpp = malidp_format_get_bpp(info->format);
+
+ afbc_superblock_size = (bpp * afbc_superblock_width *
afbc_superblock_height)
+ / BITS_PER_BYTE;
afbc_size = ALIGN(n_superblocks * AFBC_HEADER_SIZE,
AFBC_SUPERBLK_ALIGNMENT);
afbc_size += n_superblocks * ALIGN(afbc_superblock_size,
AFBC_SUPERBLK_ALIGNMENT);
- if (mode_cmd->width * info->cpp[0] != mode_cmd->pitches[0]) {
- DRM_DEBUG_KMS("Invalid value of pitch (=%u) should be same as
width (=%u) * cpp (=%u)\n",
- mode_cmd->pitches[0], mode_cmd->width,
info->cpp[0]);
+ if ((mode_cmd->width * bpp) != (mode_cmd->pitches[0] * BITS_PER_BYTE)) {
+ DRM_DEBUG_KMS("Invalid value of (pitch * BITS_PER_BYTE) (=%u) "
+ "should be same as width (=%u) * bpp (=%u)\n",
+ (mode_cmd->pitches[0] * BITS_PER_BYTE),
+ mode_cmd->width, bpp);
return false;
}
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 09/10] drm/arm/malidp:- Disregard the pitch alignment constraint for AFBC framebuffer.
From: Ayan Kumar Halder
Considering the fact that some of the AFBC specific pixel formats are expressed
in bits per pixel (ie bpp which is not byte aligned), the pitch (ie width * bpp)
is not guaranteed to be aligned to burst size (ie 8 or 16 bytes).
For example, DRM_FORMAT_VUY101010 is 30 bits per pixel. For a framebuffer of
width 32 pixels, the pitch will be 120 bytes which is not aligned to burst size
(ie 16 bytes) for DP650.
Changes since v3 (series):
- Added the ack
- Rebased on the latest drm-misc-next
Signed-off-by: Ayan Kumar halder
Acked-by: Liviu Dudau
Acked-by: Alyssa Rosenzweig
---
drivers/gpu/drm/arm/malidp_planes.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/arm/malidp_planes.c
b/drivers/gpu/drm/arm/malidp_planes.c
index 3dc8a6f..044bf7f 100644
--- a/drivers/gpu/drm/arm/malidp_planes.c
+++ b/drivers/gpu/drm/arm/malidp_planes.c
@@ -531,8 +531,8 @@ static int malidp_de_plane_check(struct drm_plane *plane,
for (i = 0; i < ms->n_planes; i++) {
u8 alignment = malidp_hw_get_pitch_align(mp->hwdev, rotated);
- if ((fb->pitches[i] * drm_format_info_block_height(fb->format,
i))
- & (alignment - 1)) {
+ if (((fb->pitches[i] * drm_format_info_block_height(fb->format,
i))
+ & (alignment - 1)) && !(fb->modifier)) {
DRM_DEBUG_KMS("Invalid pitch %u for plane %d\n",
fb->pitches[i], i);
return -EINVAL;
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 03/10] drm/arm/malidp: Set the AFBC register bits if the framebuffer has AFBC modifier
From: Ayan Kumar Halder
Added the AFBC decoder registers for DP500 , DP550 and DP650.
These registers control the processing of AFBC buffers. It controls various
features like AFBC decoder enable, lossless transformation and block split
as well as setting of the left, right, top and bottom cropping of AFBC
buffers (in number of pixels).
All the layers (except DE_SMART) support framebuffers with AFBC modifiers.
One needs to set the pixel values of the top, left, bottom and right
cropping for the AFBC framebuffer.
Cropping an AFBC framebuffer is controlled by the AFBC crop registers.
In that case, the layer input size registers should be configured with
framebuffer's dimensions and not with drm_plane_state source width/height
values (which is used for non AFBC framebuffer to denote cropping).
Changes from v1:
- Removed the "if (fb->modifier)" check from malidp_de_plane_update()
and added it in malidp_de_set_plane_afbc(). This will consolidate all the
AFBC specific register configurations in a single function ie
malidp_de_set_plane_afbc().
Changes from v2:
- For AFBC framebuffer, layer input size register should be set to
framebuffer's width and height.
Changes from v3:
- Rebased on top of latest drm-misc-next
- Some cleanups/sanity changes based on Liviu's comments
Changes from v3 (series):
- Added the ack
- Rebased on the latest drm-misc-next
Signed-off-by: Ayan Kumar Halder
Reviewed-by: Liviu Dudau
Acked-by: Alyssa Rosenzweig
---
drivers/gpu/drm/arm/malidp_hw.c | 30 ++
drivers/gpu/drm/arm/malidp_hw.h | 2 +
drivers/gpu/drm/arm/malidp_planes.c | 107
drivers/gpu/drm/arm/malidp_regs.h | 20 +++
4 files changed, 136 insertions(+), 23 deletions(-)
diff --git a/drivers/gpu/drm/arm/malidp_hw.c b/drivers/gpu/drm/arm/malidp_hw.c
index b9bed11..64c2ca3 100644
--- a/drivers/gpu/drm/arm/malidp_hw.c
+++ b/drivers/gpu/drm/arm/malidp_hw.c
@@ -94,11 +94,14 @@ static const struct malidp_layer malidp500_layers[] = {
* yuv2rgb matrix offset, mmu control register offset,
rotation_features
*/
{ DE_VIDEO1, MALIDP500_DE_LV_BASE, MALIDP500_DE_LV_PTR_BASE,
- MALIDP_DE_LV_STRIDE0, MALIDP500_LV_YUV2RGB, 0, ROTATE_ANY },
+ MALIDP_DE_LV_STRIDE0, MALIDP500_LV_YUV2RGB, 0, ROTATE_ANY,
+ MALIDP500_DE_LV_AD_CTRL },
{ DE_GRAPHICS1, MALIDP500_DE_LG1_BASE, MALIDP500_DE_LG1_PTR_BASE,
- MALIDP_DE_LG_STRIDE, 0, 0, ROTATE_ANY },
+ MALIDP_DE_LG_STRIDE, 0, 0, ROTATE_ANY,
+ MALIDP500_DE_LG1_AD_CTRL },
{ DE_GRAPHICS2, MALIDP500_DE_LG2_BASE, MALIDP500_DE_LG2_PTR_BASE,
- MALIDP_DE_LG_STRIDE, 0, 0, ROTATE_ANY },
+ MALIDP_DE_LG_STRIDE, 0, 0, ROTATE_ANY,
+ MALIDP500_DE_LG2_AD_CTRL },
};
static const struct malidp_layer malidp550_layers[] = {
@@ -106,13 +109,16 @@ static const struct malidp_layer malidp550_layers[] = {
* yuv2rgb matrix offset, mmu control register offset,
rotation_features
*/
{ DE_VIDEO1, MALIDP550_DE_LV1_BASE, MALIDP550_DE_LV1_PTR_BASE,
- MALIDP_DE_LV_STRIDE0, MALIDP550_LV_YUV2RGB, 0, ROTATE_ANY },
+ MALIDP_DE_LV_STRIDE0, MALIDP550_LV_YUV2RGB, 0, ROTATE_ANY,
+ MALIDP550_DE_LV1_AD_CTRL },
{ DE_GRAPHICS1, MALIDP550_DE_LG_BASE, MALIDP550_DE_LG_PTR_BASE,
- MALIDP_DE_LG_STRIDE, 0, 0, ROTATE_ANY },
+ MALIDP_DE_LG_STRIDE, 0, 0, ROTATE_ANY,
+ MALIDP550_DE_LG_AD_CTRL },
{ DE_VIDEO2, MALIDP550_DE_LV2_BASE, MALIDP550_DE_LV2_PTR_BASE,
- MALIDP_DE_LV_STRIDE0, MALIDP550_LV_YUV2RGB, 0, ROTATE_ANY },
+ MALIDP_DE_LV_STRIDE0, MALIDP550_LV_YUV2RGB, 0, ROTATE_ANY,
+ MALIDP550_DE_LV2_AD_CTRL },
{ DE_SMART, MALIDP550_DE_LS_BASE, MALIDP550_DE_LS_PTR_BASE,
- MALIDP550_DE_LS_R1_STRIDE, 0, 0, ROTATE_NONE },
+ MALIDP550_DE_LS_R1_STRIDE, 0, 0, ROTATE_NONE, 0 },
};
static const struct malidp_layer malidp650_layers[] = {
@@ -122,16 +128,18 @@ static const struct malidp_layer malidp650_layers[] = {
*/
{ DE_VIDEO1, MALIDP550_DE_LV1_BASE, MALIDP550_DE_LV1_PTR_BASE,
MALIDP_DE_LV_STRIDE0, MALIDP550_LV_YUV2RGB,
- MALIDP650_DE_LV_MMU_CTRL, ROTATE_ANY },
+ MALIDP650_DE_LV_MMU_CTRL, ROTATE_ANY,
+ MALIDP550_DE_LV1_AD_CTRL },
{ DE_GRAPHICS1, MALIDP550_DE_LG_BASE, MALIDP550_DE_LG_PTR_BASE,
MALIDP_DE_LG_STRIDE, 0, MALIDP650_DE_LG_MMU_CTRL,
- ROTATE_COMPRESSED },
+ ROTATE_COMPRESSED, MALIDP550_DE_LG_AD_CTRL },
{ DE_VIDEO2, MALIDP550_DE_LV2_BASE, MALIDP550_DE_LV2_PTR_BASE,
MALIDP_DE_LV_STRIDE0, MALIDP550_LV_YUV2RGB,
- MALIDP650_DE_LV_MMU_CTRL, ROTATE_ANY },
+ MALIDP650_DE_LV_MMU_CTRL, ROTATE_ANY,
+ MALIDP550_DE_LV2_AD_CTRL },
[PATCH v4 05/10] drm/arm/malidp:- Define a common list of AFBC format modifiers supported for DP500, DP550 and DP650
From: Ayan Kumar Halder
We need to define a common list of format modifiers supported by each of
the Mali display processors.
The following are the constraints with AFBC:-
1. AFBC is not supported for the formats defined in
malidp_hw_format_is_linear_only()
2. Some of the formats are supported only with AFBC modifiers. Thus we have
introduced a new function 'malidp_hw_format_is_afbc_only()' which verifies
the same.
3. AFBC_FORMAT_MOD_YTR needs to be provided for any RGB format.
4. Formats <= 16bpp cannot support AFBC_FORMAT_MOD_SPLIT.
5. CBR should not be set for non-subsampled formats.
6. SMART layer does not support framebuffer with AFBC modifiers.
Return -EINVAL for such a scenario.
7. AFBC_FORMAT_MOD_YTR is not supported for any YUV formats.
8. Formats which are subsampled cannot support AFBC_FORMAT_MOD_SPLIT.
However in DP550, YUV_420_10BIT is supported with AFBC_FORMAT_MOD_SPLIT.
This feature has been identified with
MALIDP_DEVICE_AFBC_YUV_420_10_SUPPORT_SPLIT.
9. In DP550 and DP650, for YUYV, the hardware supports different
format-ids to be used with and without AFBC modifier. We have used the
feature 'MALIDP_DEVICE_AFBC_YUYV_USE_422_P2' to identify this
characteristic.
10. DP500 does not support split mode (ie AFBC_FORMAT_MOD_SPLIT). We have
used the feature 'MALIDP_DEVICE_AFBC_SUPPORT_SPLIT' to identify the DPs
which support SPLIT mode.
11. DP550 supports YUV420 with split mode. We have defined the feature
'AFBC_SUPPORT_SPLIT_WITH_YUV_420_10' to identify this characteristic.
Changes since v1:-
- Merged https://patchwork.freedesktop.org/patch/265215/ into this patch
- As Liviu pointed out in the last patch, we can pull the checks outside
of the 'while (*modifiers != DRM_FORMAT_MOD_INVALID)' loop
- Rebased
Changes since v3 (series):
- Added the ack
- Rebased on the latest drm-misc-next
Signed-off-by: Ayan Kumar halder
Reviewed-by: Liviu Dudau
Acked-by: Alyssa Rosenzweig
---
drivers/gpu/drm/arm/malidp_drv.c| 32 ++---
drivers/gpu/drm/arm/malidp_drv.h| 6 ++
drivers/gpu/drm/arm/malidp_hw.c | 96 +--
drivers/gpu/drm/arm/malidp_hw.h | 24 +--
drivers/gpu/drm/arm/malidp_mw.c | 2 +-
drivers/gpu/drm/arm/malidp_planes.c | 126 +++-
6 files changed, 246 insertions(+), 40 deletions(-)
diff --git a/drivers/gpu/drm/arm/malidp_drv.c b/drivers/gpu/drm/arm/malidp_drv.c
index ab50ad0..c697664 100644
--- a/drivers/gpu/drm/arm/malidp_drv.c
+++ b/drivers/gpu/drm/arm/malidp_drv.c
@@ -264,37 +264,17 @@ static bool
malidp_verify_afbc_framebuffer_caps(struct drm_device *dev,
const struct drm_mode_fb_cmd2 *mode_cmd)
{
- const struct drm_format_info *info;
-
- if ((mode_cmd->modifier[0] >> 56) != DRM_FORMAT_MOD_VENDOR_ARM) {
- DRM_DEBUG_KMS("Unknown modifier (not Arm)\n");
+ if (malidp_format_mod_supported(dev, mode_cmd->pixel_format,
+ mode_cmd->modifier[0]) == false)
return false;
- }
-
- if (mode_cmd->modifier[0] &
- ~DRM_FORMAT_MOD_ARM_AFBC(AFBC_MOD_VALID_BITS)) {
- DRM_DEBUG_KMS("Unsupported modifiers\n");
- return false;
- }
-
- info = drm_get_format_info(dev, mode_cmd);
- if (!info) {
- DRM_DEBUG_KMS("Unable to get the format information\n");
- return false;
- }
-
- if (info->num_planes != 1) {
- DRM_DEBUG_KMS("AFBC buffers expect one plane\n");
- return false;
- }
if (mode_cmd->offsets[0] != 0) {
DRM_DEBUG_KMS("AFBC buffers' plane offset should be 0\n");
return false;
}
- switch (mode_cmd->modifier[0] & AFBC_FORMAT_MOD_BLOCK_SIZE_MASK) {
- case AFBC_FORMAT_MOD_BLOCK_SIZE_16x16:
+ switch (mode_cmd->modifier[0] & AFBC_SIZE_MASK) {
+ case AFBC_SIZE_16X16:
if ((mode_cmd->width % 16) || (mode_cmd->height % 16)) {
DRM_DEBUG_KMS("AFBC buffers must be aligned to 16
pixels\n");
return false;
@@ -319,8 +299,8 @@ malidp_verify_afbc_framebuffer_size(struct drm_device *dev,
u32 afbc_superblock_size = 0, afbc_superblock_height = 0;
u32 afbc_superblock_width = 0, afbc_size = 0;
- switch (mode_cmd->modifier[0] & AFBC_FORMAT_MOD_BLOCK_SIZE_MASK) {
- case AFBC_FORMAT_MOD_BLOCK_SIZE_16x16:
+ switch (mode_cmd->modifier[0] & AFBC_SIZE_MASK) {
+ case AFBC_SIZE_16X16:
afbc_superblock_height = 16;
afbc_superblock_width = 16;
break;
diff --git a/drivers/gpu/drm/arm/malidp_drv.h b/drivers/gpu/drm/arm/malidp_drv.h
index b76c86f..019a682 100644
--- a/drivers/gpu/drm/arm/malidp_drv.h
+++ b/drivers/gpu/drm/arm/malidp_drv.h
@@ -90,6 +90,12 @@ struct malidp_crtc_state {
int malidp_de_planes_init(struct drm_device *drm);
int
[PATCH v4 06/10] drm/arm/malidp: Specified the rotation memory requirements for AFBC YUV formats
From: Ayan Kumar Halder
The newly supported AFBC YUV formats have the following rotation memory
constraints (in DP550/DP650).
1. DRM_FORMAT_VUY888/DRM_FORMAT_VUY101010 :- It can rotate upto 8
horizontal lines in the AFBC output buffer.
2. DRM_FORMAT_YUV420_8BIT :- It can rotate upto 16 horizontal lines
in the AFBC output buffer.
Also some of the pixel formats are specified in bits per pixel (rather
than bytes per pixel), so the calculation needs to take note of this.
Besides there are some difference between DP550 and DP650 and these are
as follows:-
1. DRM_FORMAT_X0L2 (in uncompressed format) does not support rotation in
DP550. For DP650, it can rotate upto 16 horizontal lines in the AFBC
output buffer, whereas in DP550 (with AFBC), it can rotate upto 8
horizontal lines.
2. DRM_FORMAT_YUV420_10BIT :- It can rotate upto 8 horizontal lines in
dp550 and 16 horizontal lines in DP650.
Changes since v3 (series):
- Added the ack
- Rebased on the latest drm-misc-next
Signed-off-by: Ayan Kumar halder
Reviewed-by: Liviu Dudau
Acked-by: Alyssa Rosenzweig
---
drivers/gpu/drm/arm/malidp_hw.c | 101
drivers/gpu/drm/arm/malidp_hw.h | 5 +-
drivers/gpu/drm/arm/malidp_planes.c | 3 +-
3 files changed, 98 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/arm/malidp_hw.c b/drivers/gpu/drm/arm/malidp_hw.c
index 0ac2762..8df12e9 100644
--- a/drivers/gpu/drm/arm/malidp_hw.c
+++ b/drivers/gpu/drm/arm/malidp_hw.c
@@ -380,14 +380,39 @@ static void malidp500_modeset(struct malidp_hw_device
*hwdev, struct videomode *
malidp_hw_clearbits(hwdev, MALIDP_DISP_FUNC_ILACED,
MALIDP_DE_DISPLAY_FUNC);
}
-static int malidp500_rotmem_required(struct malidp_hw_device *hwdev, u16 w,
u16 h, u32 fmt)
+int malidp_format_get_bpp(u32 fmt)
+{
+ int bpp = drm_format_plane_cpp(fmt, 0) * 8;
+
+ if (bpp == 0) {
+ switch (fmt) {
+ case DRM_FORMAT_VUY101010:
+ bpp = 30;
+ case DRM_FORMAT_YUV420_10BIT:
+ bpp = 15;
+ break;
+ case DRM_FORMAT_YUV420_8BIT:
+ bpp = 12;
+ break;
+ default:
+ bpp = 0;
+ }
+ }
+
+ return bpp;
+}
+
+static int malidp500_rotmem_required(struct malidp_hw_device *hwdev, u16 w,
+u16 h, u32 fmt, bool has_modifier)
{
/*
* Each layer needs enough rotation memory to fit 8 lines
* worth of pixel data. Required size is then:
*size = rotated_width * (bpp / 8) * 8;
*/
- return w * drm_format_plane_cpp(fmt, 0) * 8;
+ int bpp = malidp_format_get_bpp(fmt);
+
+ return w * bpp;
}
static void malidp500_se_write_pp_coefftab(struct malidp_hw_device *hwdev,
@@ -665,9 +690,9 @@ static void malidp550_modeset(struct malidp_hw_device
*hwdev, struct videomode *
malidp_hw_clearbits(hwdev, MALIDP_DISP_FUNC_ILACED,
MALIDP_DE_DISPLAY_FUNC);
}
-static int malidp550_rotmem_required(struct malidp_hw_device *hwdev, u16 w,
u16 h, u32 fmt)
+static int malidpx50_get_bytes_per_column(u32 fmt)
{
- u32 bytes_per_col;
+ u32 bytes_per_column;
switch (fmt) {
/* 8 lines at 4 bytes per pixel */
@@ -693,19 +718,77 @@ static int malidp550_rotmem_required(struct
malidp_hw_device *hwdev, u16 w, u16
case DRM_FORMAT_UYVY:
case DRM_FORMAT_YUYV:
case DRM_FORMAT_X0L0:
- case DRM_FORMAT_X0L2:
- bytes_per_col = 32;
+ bytes_per_column = 32;
break;
/* 16 lines at 1.5 bytes per pixel */
case DRM_FORMAT_NV12:
case DRM_FORMAT_YUV420:
- bytes_per_col = 24;
+ /* 8 lines at 3 bytes per pixel */
+ case DRM_FORMAT_VUY888:
+ /* 16 lines at 12 bits per pixel */
+ case DRM_FORMAT_YUV420_8BIT:
+ /* 8 lines at 3 bytes per pixel */
+ case DRM_FORMAT_P010:
+ bytes_per_column = 24;
+ break;
+ /* 8 lines at 30 bits per pixel */
+ case DRM_FORMAT_VUY101010:
+ /* 16 lines at 15 bits per pixel */
+ case DRM_FORMAT_YUV420_10BIT:
+ bytes_per_column = 30;
break;
default:
return -EINVAL;
}
- return w * bytes_per_col;
+ return bytes_per_column;
+}
+
+static int malidp550_rotmem_required(struct malidp_hw_device *hwdev, u16 w,
+u16 h, u32 fmt, bool has_modifier)
+{
+ int bytes_per_column = 0;
+
+ switch (fmt) {
+ /* 8 lines at 15 bits per pixel */
+ case DRM_FORMAT_YUV420_10BIT:
+ bytes_per_column = 15;
+ break;
+ /* Uncompressed YUV 420 10 bit single plane cannot be rotated */
+ case DRM_FORMAT_X0L2:
+ if (has_modifier)
+
[PATCH v4 07/10] drm/arm/malidp:- Writeback framebuffer does not support any modifiers
From: Ayan Kumar Halder
In malidp, the writeback pipeline does not support writing crtc output
to a framebuffer with modifiers ie the memory writeback content is
devoid of any compression or tiling, etc.
So we have added a commit check in memory writeback encoder helper function
to validate if the framebuffer has any modifier and if so, return EINVAL.
Changes since v3 (series):
- Added the ack
- Rebased on the latest drm-misc-next
Signed-off-by: Ayan Kumar halder
Acked-by: Liviu Dudau
Acked-by: Alyssa Rosenzweig
---
drivers/gpu/drm/arm/malidp_mw.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/gpu/drm/arm/malidp_mw.c b/drivers/gpu/drm/arm/malidp_mw.c
index 28cd351..2865f7a 100644
--- a/drivers/gpu/drm/arm/malidp_mw.c
+++ b/drivers/gpu/drm/arm/malidp_mw.c
@@ -141,6 +141,11 @@ malidp_mw_encoder_atomic_check(struct drm_encoder *encoder,
return -EINVAL;
}
+ if (fb->modifier) {
+ DRM_DEBUG_KMS("Writeback framebuffer does not support
modifiers\n");
+ return -EINVAL;
+ }
+
mw_state->format =
malidp_hw_get_format_id(>dev->hw->map, SE_MEMWRITE,
fb->format->format, !!fb->modifier);
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 04/10] drm/arm/malidp:- Added support for new YUV formats for DP500, DP550 and DP650
From: Ayan Kumar Halder
We have added support for some AFBC only pixel formats like :-
DRM_FORMAT_YUV420_8BIT (single plane YUV 420 8 bit format)
DRM_FORMAT_VUY888 (single plane YUV 444 8 bit format)
DRM_FORMAT_VUY101010 (single plane YUV 444 10 bit format)
DRM_FORMAT_YUV420_10BIT (single plane YUV 420 10 bit format)
Generally, these formats are supported by our hardware using the same
hw-ids as the equivalent multi plane pixel formats.
Also we have added support for XYUV 444 8 and 10 bit formats
Changes since v3 (series):
- Added the ack
- Rebased on the latest drm-misc-next
Signed-off-by: Ayan Kumar Halder
Reviewed-by: Liviu Dudau
Acked-by: Alyssa Rosenzweig
---
drivers/gpu/drm/arm/malidp_hw.c | 22 +-
1 file changed, 21 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/arm/malidp_hw.c b/drivers/gpu/drm/arm/malidp_hw.c
index 64c2ca3..b4a0e11 100644
--- a/drivers/gpu/drm/arm/malidp_hw.c
+++ b/drivers/gpu/drm/arm/malidp_hw.c
@@ -49,6 +49,12 @@ static const struct malidp_format_id malidp500_de_formats[]
= {
{ DRM_FORMAT_YUYV, DE_VIDEO1, 13 },
{ DRM_FORMAT_NV12, DE_VIDEO1 | SE_MEMWRITE, 14 },
{ DRM_FORMAT_YUV420, DE_VIDEO1, 15 },
+ { DRM_FORMAT_XYUV, DE_VIDEO1, 16 },
+ /* These are supported with AFBC only */
+ { DRM_FORMAT_YUV420_8BIT, DE_VIDEO1, 14 },
+ { DRM_FORMAT_VUY888, DE_VIDEO1, 16 },
+ { DRM_FORMAT_VUY101010, DE_VIDEO1, 17 },
+ { DRM_FORMAT_YUV420_10BIT, DE_VIDEO1, 18 }
};
#define MALIDP_ID(__group, __format) \
@@ -74,11 +80,25 @@ static const struct malidp_format_id malidp500_de_formats[]
= {
{ DRM_FORMAT_ABGR1555, DE_VIDEO1 | DE_GRAPHICS1 | DE_VIDEO2,
MALIDP_ID(4, 1) }, \
{ DRM_FORMAT_RGB565, DE_VIDEO1 | DE_GRAPHICS1 | DE_VIDEO2, MALIDP_ID(4,
2) }, \
{ DRM_FORMAT_BGR565, DE_VIDEO1 | DE_GRAPHICS1 | DE_VIDEO2, MALIDP_ID(4,
3) }, \
+ /* This is only supported with linear modifier */ \
+ { DRM_FORMAT_XYUV, DE_VIDEO1 | DE_VIDEO2, MALIDP_ID(5, 0) },\
+ /* This is only supported with AFBC modifier */ \
+ { DRM_FORMAT_VUY888, DE_VIDEO1 | DE_VIDEO2, MALIDP_ID(5, 0) }, \
{ DRM_FORMAT_YUYV, DE_VIDEO1 | DE_VIDEO2, MALIDP_ID(5, 2) },\
+ /* This is only supported with linear modifier */ \
{ DRM_FORMAT_UYVY, DE_VIDEO1 | DE_VIDEO2, MALIDP_ID(5, 3) },\
{ DRM_FORMAT_NV12, DE_VIDEO1 | DE_VIDEO2 | SE_MEMWRITE, MALIDP_ID(5, 6)
}, \
+ /* This is only supported with AFBC modifier */ \
+ { DRM_FORMAT_YUV420_8BIT, DE_VIDEO1 | DE_VIDEO2, MALIDP_ID(5, 6) }, \
{ DRM_FORMAT_YUV420, DE_VIDEO1 | DE_VIDEO2, MALIDP_ID(5, 7) }, \
- { DRM_FORMAT_X0L2, DE_VIDEO1 | DE_VIDEO2, MALIDP_ID(6, 6)}
+ /* This is only supported with linear modifier */ \
+ { DRM_FORMAT_XVYU2101010, DE_VIDEO1 | DE_VIDEO2, MALIDP_ID(6, 0)}, \
+ /* This is only supported with AFBC modifier */ \
+ { DRM_FORMAT_VUY101010, DE_VIDEO1 | DE_VIDEO2, MALIDP_ID(6, 0)}, \
+ { DRM_FORMAT_X0L2, DE_VIDEO1 | DE_VIDEO2, MALIDP_ID(6, 6)}, \
+ /* This is only supported with AFBC modifier */ \
+ { DRM_FORMAT_YUV420_10BIT, DE_VIDEO1 | DE_VIDEO2, MALIDP_ID(6, 7)}, \
+ { DRM_FORMAT_P010, DE_VIDEO1 | DE_VIDEO2, MALIDP_ID(6, 7)}
static const struct malidp_format_id malidp550_de_formats[] = {
MALIDP_COMMON_FORMATS,
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 01/10] drm/fourcc: Add AFBC yuv fourccs for Mali
From: Brian Starkey As we look to enable AFBC using DRM format modifiers, we run into problems which we've historically handled via vendor-private details (i.e. gralloc, on Android). AFBC (as an encoding) is fully flexible, and for example YUV data can be encoded into 1, 2 or 3 encoded "planes", much like the linear equivalents. Component order is also meaningful, as AFBC doesn't necessarily care about what each "channel" of the data it encodes contains. Therefore ABGR and RGBA can be encoded in AFBC with different representations. Similarly, 'X' components may be encoded into AFBC streams in cases where a decoder expects to decode a 4th component. In addition, AFBC is a licensable IP, meaning that to support the ecosystem we need to ensure that _all_ AFBC users are able to describe the encodings that they need. This is much better achieved by preserving meaning in the fourcc codes when they are combined with an AFBC modifier. In essence, we want to use the modifier to describe the parameters of the AFBC encode/decode, and use the fourcc code to describe the data being encoded/decoded. To do anything different would be to introduce redundancy - we would need to duplicate in the modifier information which is _already_ conveyed clearly and non-ambigiously by a fourcc code. I hope that for RGB this is non-controversial. (BGRA + MODIFIER_AFBC) is a different format from (RGBA + MODIFIER_AFBC). Possibly more controversial is that (XBGR + MODIFIER_AFBC) is different from (BGR888 + MODIFIER_AFBC). I understand that in some schemes it is not the case - but in AFBC it is so. Where we run into problems is where there are not already fourcc codes which represent the data which the AFBC encoder/decoder is processing. To that end, we want to introduce new fourcc codes to describe the data being encoded/decoded, in the places where none of the existing fourcc codes are applicable. Where we don't support an equivalent non-compressed layout, or where no "obvious" linear layout exists, we are proposing adding fourcc codes which have no associated linear layout - because any layout we proposed would be completely arbitrary. Some formats are following the naming conventions from [2]. The summary of the new formats is: DRM_FORMAT_VUY888 - Packed 8-bit YUV 444. Y followed by U then V. DRM_FORMAT_VUY101010 - Packed 10-bit YUV 444. Y followed by U then V. No defined linear encoding. DRM_FORMAT_Y210 - Packed 10-bit YUV 422. Y followed by U (then Y) then V. 10-bit samples in 16-bit words. DRM_FORMAT_Y410 - Packed 10-bit YUV 444, with 2-bit alpha. DRM_FORMAT_P210 - Semi-planar 10-bit YUV 422. Y plane, followed by interleaved U-then-V plane. 10-bit samples in 16-bit words. DRM_FORMAT_YUV420_8BIT - Packed 8-bit YUV 420. Y followed by U then V. No defined linear encoding DRM_FORMAT_YUV420_10BIT - Packed 10-bit YUV 420. Y followed by U then V. No defined linear encoding Please also note that in the absence of AFBC, we would still need to add Y410, Y210 and P210. Full rationale follows: YUV 444 8-bit, 1-plane -- The currently defined AYUV format encodes a 4th alpha component, which makes it unsuitable for representing a 3-component YUV 444 AFBC stream. The proposed[1] XYUV format which is supported by Mali-DP in linear layout is also unsuitable, because the component order is the opposite of the AFBC version, and it encodes a 4th 'X' component. DRM_FORMAT_VUY888 is the "obvious" format for a 3-component, packed, YUV 444 8-bit format, with the component order which our HW expects to encode/decode. It conforms to the same naming convention as the existing packed YUV 444 format. The naming here is meant to be consistent with DRM_FORMAT_AYUV and DRM_FORMAT_XYUV[1] YUV 444 10-bit, 1-plane --- There is no currently-defined YUV 444 10-bit format in drm_fourcc.h, irrespective of number of planes. The proposed[1] XVYU2101010 format which is supported by Mali-DP in linear layout uses the wrong component order, and also encodes a 4th 'X' component, which doesn't match the AFBC version of YUV 444 10-bit which we support. DRM_FORMAT_Y410 is the same layout as XVYU2101010, but with 2 bits of alpha. This format is supported with linear layout by Mali GPUs. The naming follows[2]. There is no "obvious" linear encoding for a 3-component 10:10:10 packed format, and so DRM_FORMAT_VUY101010 defines a component order, but not a bit encoding. Again, the naming is meant to be consistent with DRM_FORMAT_AYUV. YUV 422 8-bit, 1-plane -- The existing DRM_FORMAT_YUYV (and the other component orders) are single-planar YUV 422 8-bit formats. Following the convention of the component orders of the RGB formats, YUYV has the correct component order for our AFBC encoding (Y followed by U followed by
[PATCH v4 02/10] drm: Added a new format DRM_FORMAT_XVYU2101010
From: Ayan Kumar Halder
This new format is supported by DP550 and DP650
Changes since v3 (series):
- Added the ack
- Rebased on the latest drm-misc-next
Signed-off-by: Ayan Kumar halder
Reviewed-by: Liviu Dudau
Acked-by: Alyssa Rosenzweig
---
drivers/gpu/drm/drm_fourcc.c | 1 +
include/uapi/drm/drm_fourcc.h | 1 +
2 files changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/drm_fourcc.c b/drivers/gpu/drm/drm_fourcc.c
index a9df743..3684c49 100644
--- a/drivers/gpu/drm/drm_fourcc.c
+++ b/drivers/gpu/drm/drm_fourcc.c
@@ -229,6 +229,7 @@ const struct drm_format_info *__drm_format_info(u32 format)
{ .format = DRM_FORMAT_VUY888, .depth = 0,
.num_planes = 1, .cpp = { 3, 0, 0 }, .hsub = 1, .vsub = 1, .is_yuv = true },
{ .format = DRM_FORMAT_Y410,.depth = 0,
.num_planes = 1, .cpp = { 4, 0, 0 }, .hsub = 1, .vsub = 1, .has_alpha = true,
.is_yuv = true },
{ .format = DRM_FORMAT_AYUV,.depth = 0,
.num_planes = 1, .cpp = { 4, 0, 0 }, .hsub = 1, .vsub = 1, .has_alpha = true,
.is_yuv = true },
+ { .format = DRM_FORMAT_XVYU2101010, .depth = 0,
.num_planes = 1, .cpp = { 4, 0, 0 }, .hsub = 1, .vsub = 1, .is_yuv = true },
{ .format = DRM_FORMAT_Y210,.depth = 0,
.num_planes = 1, .cpp = { 4, 0, 0 }, .hsub = 2, .vsub = 1, .is_yuv = true },
{ .format = DRM_FORMAT_Y212,.depth = 0,
.num_planes = 1, .cpp = { 4, 0, 0 }, .hsub = 2, .vsub = 1, .is_yuv = true },
{ .format = DRM_FORMAT_Y216,.depth = 0,
.num_planes = 1, .cpp = { 4, 0, 0 }, .hsub = 2, .vsub = 1, .is_yuv = true },
diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
index b992a38..dc99e7f 100644
--- a/include/uapi/drm/drm_fourcc.h
+++ b/include/uapi/drm/drm_fourcc.h
@@ -153,6 +153,7 @@ extern "C" {
#define DRM_FORMAT_AYUVfourcc_code('A', 'Y', 'U', 'V') /*
[31:0] A:Y:Cb:Cr 8:8:8:8 little endian */
#define DRM_FORMAT_XYUVfourcc_code('X', 'Y', 'U', 'V') /*
[31:0] X:Y:Cb:Cr 8:8:8:8 little endian */
+#define DRM_FORMAT_XVYU2101010 fourcc_code('X', 'V', '3', '0') /* [31:0]
X:Cr:Y:Cb 2:10:10:10 little endian */
#define DRM_FORMAT_VUY888 fourcc_code('V', 'U', '2', '4') /* [23:0]
Cr:Cb:Y 8:8:8 little endian */
#define DRM_FORMAT_Y410fourcc_code('Y', '4', '1', '0') /*
[31:0] A:Cr:Y:Cb 2:10:10:10 little endian */
#define DRM_FORMAT_VUY101010 fourcc_code('V', 'U', '3', '0') /* Y followed
by U then V, 10:10:10. Non-linear modifier only */
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2] drm/fourcc: add ARM GPU tile format
On Mon, Mar 11, 2019 at 09:39:28AM -0700, Alyssa Rosenzweig wrote: > > You might want to re-use the exisiting modifier > > AFBC_FORMAT_MOD_BLOCK_SIZE_16x16. > > > > I would suggest you to have a look at the exisiting AFBC modifiers > > (denoted by AFBC_FORMAT_MOD_XXX ) and let us know if there is > > something you cannot reuse. > > So, the "tiled" format in question (that Qiang needs to import/export > BOs in) is *uncompressed* but tiled with an Arm-internal format (for the > GPUs). Here's a software implementation for encoding this format: > https://cgit.freedesktop.org/mesa/mesa/tree/src/gallium/drivers/panfrost/pan_swizzle.c > ok I understood now. In this case, please ignore my suggestion. > For Midgard/Bifrost, we use this tiling internally for uploading bitmap > textures, but we only render to AFBC (or linear). So for Panfrost, we'll > always be importing/exporting AFBC buffers, never uncompressed tiled. I am not a gpu guy so can't comment at the moment. > But Utgard does not seem to support AFBC (?), so Qiang needs the > uncompressed tiled for the same purpose Panfrost uses AFBC. > > Is it possible that this is the same tiling used internally by > AFBC_FORMAT_MOD_BLOCK_SIZE_16x16, only without any compression? AFBC is > blackbox for us, so this isn't something we can figure out ourselves, > but that influences whether it's appropriate to reuse the modifier. If > this is the same tiling scheme, perhaps that's the answer. If it's not > (I don't know how AFBC tiling works), we probably do need a separate > modifier to avoid confusion. > AFBC_FORMAT_MOD_BLOCK_SIZE_16x16 denotes the superblock size to be used only in case of AFBC buffers. For non compressed tiled format, none of the AFBC_FORMAT_MOD_XXX should be used. However, I would like you to review my patch series (https://patchwork.freedesktop.org/series/53395/) to see if we have the same understanding. > Thanks, > > Alyssa > ___ > 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 v2] drm/fourcc: add ARM GPU tile format
On Sat, Mar 09, 2019 at 10:09:02PM +0800, Qiang Yu wrote:
Hi Qiang,
Apologies for jumping to the very initial patch. I wanted to have some
understanding of the newly proposed modifiers since they seem to me a
duplicate of the existing AFBC modifiers.
> v2: seperate AFBC and GPU encoding
>
> Cc: Brian Starkey
> Cc: Rob Herring
> Cc: Alyssa Rosenzweig
> Signed-off-by: Qiang Yu
> ---
> include/uapi/drm/drm_fourcc.h | 31 ++-
> 1 file changed, 30 insertions(+), 1 deletion(-)
>
> diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
> index 9fa7cf7bb274..7af5197e7ebc 100644
> --- a/include/uapi/drm/drm_fourcc.h
> +++ b/include/uapi/drm/drm_fourcc.h
> @@ -601,6 +601,19 @@ extern "C" {
> */
> #define DRM_FORMAT_MOD_BROADCOM_UIF fourcc_mod_code(BROADCOM, 6)
>
> +/*
> + * Arm Device code
> + *
> + * Arm has multiple devices which do not share buffer format,
> + * so add a device field at the MSB of the format field to seperate
> + * each device's encoding.
> + */
> +#define DRM_FORMAT_MOD_ARM_DEVICE_AFBC 0x00
Why can't you reuse the existing DRM_FORMAT_MOD_VENDOR_ARM ?
> +#define DRM_FORMAT_MOD_ARM_DEVICE_GPU 0x01
What is the purpose of this? AFBC modifiers are supposed to be used
across gpus, dpus which support AFBC buffers rendering.
> +
> +#define DRM_FORMAT_MOD_ARM_CODE(device, val) \
> + fourcc_mod_code(ARM, ((__u64)device << 48) | ((val) &
> 0xULL))
> +
> /*
> * Arm Framebuffer Compression (AFBC) modifiers
> *
> @@ -615,7 +628,8 @@ 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)
> +#define DRM_FORMAT_MOD_ARM_AFBC(__afbc_mode) \
> + DRM_FORMAT_MOD_ARM_CODE(DRM_FORMAT_MOD_ARM_DEVICE_AFBC, __afbc_mode)
>
Similar question? Why can't you reuse the existing one?
> /*
> * AFBC superblock size
> @@ -709,6 +723,21 @@ extern "C" {
> */
> #define AFBC_FORMAT_MOD_BCH (1ULL << 11)
>
> +/*
> + * Arm GPU modifiers
> + */
> +#define DRM_FORMAT_MOD_ARM_GPU(mode) \
> + DRM_FORMAT_MOD_ARM_CODE(DRM_FORMAT_MOD_ARM_DEVICE_GPU, mode)
> +
> +/*
> + * Arm GPU tiled format
> + *
> + * This is used by ARM Mali Utgard/Midgard GPU. It divides buffer into
> + * 16x16 pixel blocks. Blocks are stored linearly in order, but pixels
> + * in the block are reordered.
> + */
> +#define DRM_FORMAT_MOD_ARM_GPU_TILED DRM_FORMAT_MOD_ARM_GPU(1)
> +
You might want to re-use the exisiting modifier
AFBC_FORMAT_MOD_BLOCK_SIZE_16x16.
I would suggest you to have a look at the exisiting AFBC modifiers
(denoted by AFBC_FORMAT_MOD_XXX ) and let us know if there is something
you cannot reuse.
> /*
> * Allwinner tiled modifier
> *
> --
> 2.17.1
>
> ___
> 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: AFBC versions modifiers
Hi Neil, AFBC 1.0 does not support (ignoring common prefix AFBC_FORMAT_MOD_) BLOCK_SIZE_32x8, BLOCK_SIZE_64x4, BLOCK_SIZE_32x8_64x4 CBR, TILED, SC, DB and BCH modifiers. AFBC 1.2 does not support BLOCK_SIZE_64x4, BLOCK_SIZE_32x8_64x4, DB and BCH modifiers. Beyond that it's very hard to say. The AFBC version numbers refer to versions of the specification, but aren't very useful for describing the actual bitstream format. To determine which modifiers _are_ supported, you will really need to get technical documentation from the SoC vendor Regards, Ayan Kumar Halder From: Neil Armstrong Sent: Tuesday, February 26, 2019 2:15 PM To: Ayan Halder; Liviu Dudau Cc: DRI Development Subject: AFBC versions modifiers Hi Ayan, Could you help distinguish which are the AFBC modifiers for each version of AFBC ? The Amlogic SoCs embeds an AFBC 1.0 compatible decoder, then the newer SoCs embeds an AFBC 1.2 decoder, I assume the modifiers before the patch "drm/fourcc: Add modifier defininitions for AFBC 1.3" are valid for AFBC 1.2, but what is the subset for 1.0 and 1.1 ? Thanks, Neil -- Neil Armstrong Embedded Linux Software Engineer BayLibre - At the Heart of Embedded Linux www.baylibre.com<http://www.baylibre.com> ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 09/10] drm/arm/malidp:- Disregard the pitch alignment constraint for AFBC framebuffer.
From: Ayan Kumar Halder
Considering the fact that some of the AFBC specific pixel formats are expressed
in bits per pixel (ie bpp which is not byte aligned), the pitch (ie width * bpp)
is not guaranteed to be aligned to burst size (ie 8 or 16 bytes).
For example, DRM_FORMAT_VUY101010 is 30 bits per pixel. For a framebuffer of
width 32 pixels, the pitch will be 120 bytes which is not aligned to burst size
(ie 16 bytes) for DP650.
Signed-off-by: Ayan Kumar halder
Acked-by: Liviu Dudau
---
drivers/gpu/drm/arm/malidp_planes.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/arm/malidp_planes.c
b/drivers/gpu/drm/arm/malidp_planes.c
index 3dc8a6f..044bf7f 100644
--- a/drivers/gpu/drm/arm/malidp_planes.c
+++ b/drivers/gpu/drm/arm/malidp_planes.c
@@ -531,8 +531,8 @@ static int malidp_de_plane_check(struct drm_plane *plane,
for (i = 0; i < ms->n_planes; i++) {
u8 alignment = malidp_hw_get_pitch_align(mp->hwdev, rotated);
- if ((fb->pitches[i] * drm_format_info_block_height(fb->format,
i))
- & (alignment - 1)) {
+ if (((fb->pitches[i] * drm_format_info_block_height(fb->format,
i))
+ & (alignment - 1)) && !(fb->modifier)) {
DRM_DEBUG_KMS("Invalid pitch %u for plane %d\n",
fb->pitches[i], i);
return -EINVAL;
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 04/10] drm/arm/malidp:- Added support for new YUV formats for DP500, DP550 and DP650
From: Ayan Kumar Halder
We have added support for some AFBC only pixel formats like :-
DRM_FORMAT_YUV420_8BIT (single plane YUV 420 8 bit format)
DRM_FORMAT_VUY888 (single plane YUV 444 8 bit format)
DRM_FORMAT_VUY101010 (single plane YUV 444 10 bit format)
DRM_FORMAT_YUV420_10BIT (single plane YUV 420 10 bit format)
Generally, these formats are supported by our hardware using the same
hw-ids as the equivalent multi plane pixel formats.
Also we have added support for XYUV 444 8 and 10 bit formats
Signed-off-by: Ayan Kumar Halder
Reviewed-by: Liviu Dudau
---
drivers/gpu/drm/arm/malidp_hw.c | 22 +-
1 file changed, 21 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/arm/malidp_hw.c b/drivers/gpu/drm/arm/malidp_hw.c
index 64c2ca3..b4a0e11 100644
--- a/drivers/gpu/drm/arm/malidp_hw.c
+++ b/drivers/gpu/drm/arm/malidp_hw.c
@@ -49,6 +49,12 @@ static const struct malidp_format_id malidp500_de_formats[]
= {
{ DRM_FORMAT_YUYV, DE_VIDEO1, 13 },
{ DRM_FORMAT_NV12, DE_VIDEO1 | SE_MEMWRITE, 14 },
{ DRM_FORMAT_YUV420, DE_VIDEO1, 15 },
+ { DRM_FORMAT_XYUV, DE_VIDEO1, 16 },
+ /* These are supported with AFBC only */
+ { DRM_FORMAT_YUV420_8BIT, DE_VIDEO1, 14 },
+ { DRM_FORMAT_VUY888, DE_VIDEO1, 16 },
+ { DRM_FORMAT_VUY101010, DE_VIDEO1, 17 },
+ { DRM_FORMAT_YUV420_10BIT, DE_VIDEO1, 18 }
};
#define MALIDP_ID(__group, __format) \
@@ -74,11 +80,25 @@ static const struct malidp_format_id malidp500_de_formats[]
= {
{ DRM_FORMAT_ABGR1555, DE_VIDEO1 | DE_GRAPHICS1 | DE_VIDEO2,
MALIDP_ID(4, 1) }, \
{ DRM_FORMAT_RGB565, DE_VIDEO1 | DE_GRAPHICS1 | DE_VIDEO2, MALIDP_ID(4,
2) }, \
{ DRM_FORMAT_BGR565, DE_VIDEO1 | DE_GRAPHICS1 | DE_VIDEO2, MALIDP_ID(4,
3) }, \
+ /* This is only supported with linear modifier */ \
+ { DRM_FORMAT_XYUV, DE_VIDEO1 | DE_VIDEO2, MALIDP_ID(5, 0) },\
+ /* This is only supported with AFBC modifier */ \
+ { DRM_FORMAT_VUY888, DE_VIDEO1 | DE_VIDEO2, MALIDP_ID(5, 0) }, \
{ DRM_FORMAT_YUYV, DE_VIDEO1 | DE_VIDEO2, MALIDP_ID(5, 2) },\
+ /* This is only supported with linear modifier */ \
{ DRM_FORMAT_UYVY, DE_VIDEO1 | DE_VIDEO2, MALIDP_ID(5, 3) },\
{ DRM_FORMAT_NV12, DE_VIDEO1 | DE_VIDEO2 | SE_MEMWRITE, MALIDP_ID(5, 6)
}, \
+ /* This is only supported with AFBC modifier */ \
+ { DRM_FORMAT_YUV420_8BIT, DE_VIDEO1 | DE_VIDEO2, MALIDP_ID(5, 6) }, \
{ DRM_FORMAT_YUV420, DE_VIDEO1 | DE_VIDEO2, MALIDP_ID(5, 7) }, \
- { DRM_FORMAT_X0L2, DE_VIDEO1 | DE_VIDEO2, MALIDP_ID(6, 6)}
+ /* This is only supported with linear modifier */ \
+ { DRM_FORMAT_XVYU2101010, DE_VIDEO1 | DE_VIDEO2, MALIDP_ID(6, 0)}, \
+ /* This is only supported with AFBC modifier */ \
+ { DRM_FORMAT_VUY101010, DE_VIDEO1 | DE_VIDEO2, MALIDP_ID(6, 0)}, \
+ { DRM_FORMAT_X0L2, DE_VIDEO1 | DE_VIDEO2, MALIDP_ID(6, 6)}, \
+ /* This is only supported with AFBC modifier */ \
+ { DRM_FORMAT_YUV420_10BIT, DE_VIDEO1 | DE_VIDEO2, MALIDP_ID(6, 7)}, \
+ { DRM_FORMAT_P010, DE_VIDEO1 | DE_VIDEO2, MALIDP_ID(6, 7)}
static const struct malidp_format_id malidp550_de_formats[] = {
MALIDP_COMMON_FORMATS,
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 10/10] drm/arm/malidp: Added support for AFBC modifiers for all layers except DE_SMART
From: Ayan Kumar Halder
The list of modifiers to be supported for each plane has been dynamically
generated
from 'malidp_format_modifiers[]' and 'malidp_hw_regmap->features'.
Changes from v1:-
1. Replaced DRM_ERROR() with DRM_DEBUG_KMS() in malidp_format_mod_supported()
to report unsupported modifiers.
Changes from v2:-
1. Removed malidp_format_mod_supported() from the current patch. This has been
added
in "PATCH 7/12"
2. Dynamically generate the list of modifiers (to be supported for each plane)
from
'malidp_format_modifiers' and features.
Signed-off-by: Ayan Kumar halder
Reviewed-by: Liviu Dudau
---
drivers/gpu/drm/arm/malidp_drv.c| 1 +
drivers/gpu/drm/arm/malidp_planes.c | 31 ---
2 files changed, 29 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/arm/malidp_drv.c b/drivers/gpu/drm/arm/malidp_drv.c
index 4106f5d..21725c9 100644
--- a/drivers/gpu/drm/arm/malidp_drv.c
+++ b/drivers/gpu/drm/arm/malidp_drv.c
@@ -391,6 +391,7 @@ static int malidp_init(struct drm_device *drm)
drm->mode_config.max_height = hwdev->max_line_size;
drm->mode_config.funcs = _mode_config_funcs;
drm->mode_config.helper_private = _mode_config_helpers;
+ drm->mode_config.allow_fb_modifiers = true;
ret = malidp_crtc_init(drm);
if (ret)
diff --git a/drivers/gpu/drm/arm/malidp_planes.c
b/drivers/gpu/drm/arm/malidp_planes.c
index 044bf7f..d42e0ea 100644
--- a/drivers/gpu/drm/arm/malidp_planes.c
+++ b/drivers/gpu/drm/arm/malidp_planes.c
@@ -939,7 +939,26 @@ int malidp_de_planes_init(struct drm_device *drm)
BIT(DRM_MODE_BLEND_PREMULTI) |
BIT(DRM_MODE_BLEND_COVERAGE);
u32 *formats;
- int ret, i, j, n;
+ int ret, i = 0, j = 0, n;
+ u64 supported_modifiers[MODIFIERS_COUNT_MAX];
+ const u64 *modifiers;
+
+ modifiers = malidp_format_modifiers;
+
+ if (!(map->features & MALIDP_DEVICE_AFBC_SUPPORT_SPLIT)) {
+ /*
+* Since our hardware does not support SPLIT, so build the list
+* of supported modifiers excluding SPLIT ones.
+*/
+ while (*modifiers != DRM_FORMAT_MOD_INVALID) {
+ if (!(*modifiers & AFBC_SPLIT))
+ supported_modifiers[j++] = *modifiers;
+
+ modifiers++;
+ }
+ supported_modifiers[j++] = DRM_FORMAT_MOD_INVALID;
+ modifiers = supported_modifiers;
+ }
formats = kcalloc(map->n_pixel_formats, sizeof(*formats), GFP_KERNEL);
if (!formats) {
@@ -964,9 +983,15 @@ int malidp_de_planes_init(struct drm_device *drm)
plane_type = (i == 0) ? DRM_PLANE_TYPE_PRIMARY :
DRM_PLANE_TYPE_OVERLAY;
+
+ /*
+* All the layers except smart layer supports AFBC modifiers.
+*/
ret = drm_universal_plane_init(drm, >base, crtcs,
- _de_plane_funcs, formats,
- n, NULL, plane_type, NULL);
+ _de_plane_funcs, formats, n,
+ (id == DE_SMART) ? NULL : modifiers, plane_type,
+ NULL);
+
if (ret < 0)
goto cleanup;
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 05/10] drm/arm/malidp:- Define a common list of AFBC format modifiers supported for DP500, DP550 and DP650
From: Ayan Kumar Halder
We need to define a common list of format modifiers supported by each of
the Mali display processors.
The following are the constraints with AFBC:-
1. AFBC is not supported for the formats defined in
malidp_hw_format_is_linear_only()
2. Some of the formats are supported only with AFBC modifiers. Thus we have
introduced a new function 'malidp_hw_format_is_afbc_only()' which verifies
the same.
3. AFBC_FORMAT_MOD_YTR needs to be provided for any RGB format.
4. Formats <= 16bpp cannot support AFBC_FORMAT_MOD_SPLIT.
5. CBR should not be set for non-subsampled formats.
6. SMART layer does not support framebuffer with AFBC modifiers.
Return -EINVAL for such a scenario.
7. AFBC_FORMAT_MOD_YTR is not supported for any YUV formats.
8. Formats which are subsampled cannot support AFBC_FORMAT_MOD_SPLIT.
However in DP550, YUV_420_10BIT is supported with AFBC_FORMAT_MOD_SPLIT.
This feature has been identified with
MALIDP_DEVICE_AFBC_YUV_420_10_SUPPORT_SPLIT.
9. In DP550 and DP650, for YUYV, the hardware supports different
format-ids to be used with and without AFBC modifier. We have used the
feature 'MALIDP_DEVICE_AFBC_YUYV_USE_422_P2' to identify this
characteristic.
10. DP500 does not support split mode (ie AFBC_FORMAT_MOD_SPLIT). We have
used the feature 'MALIDP_DEVICE_AFBC_SUPPORT_SPLIT' to identify the DPs
which support SPLIT mode.
11. DP550 supports YUV420 with split mode. We have defined the feature
'AFBC_SUPPORT_SPLIT_WITH_YUV_420_10' to identify this characteristic.
Changes since v1:-
- Merged https://patchwork.freedesktop.org/patch/265215/ into this patch
- As Liviu pointed out in the last patch, we can pull the checks outside
of the 'while (*modifiers != DRM_FORMAT_MOD_INVALID)' loop
- Rebased
Signed-off-by: Ayan Kumar halder
---
drivers/gpu/drm/arm/malidp_drv.c| 32 ++---
drivers/gpu/drm/arm/malidp_drv.h| 6 ++
drivers/gpu/drm/arm/malidp_hw.c | 96 +--
drivers/gpu/drm/arm/malidp_hw.h | 24 +--
drivers/gpu/drm/arm/malidp_mw.c | 2 +-
drivers/gpu/drm/arm/malidp_planes.c | 126 +++-
6 files changed, 246 insertions(+), 40 deletions(-)
diff --git a/drivers/gpu/drm/arm/malidp_drv.c b/drivers/gpu/drm/arm/malidp_drv.c
index ab50ad0..c697664 100644
--- a/drivers/gpu/drm/arm/malidp_drv.c
+++ b/drivers/gpu/drm/arm/malidp_drv.c
@@ -264,37 +264,17 @@ static bool
malidp_verify_afbc_framebuffer_caps(struct drm_device *dev,
const struct drm_mode_fb_cmd2 *mode_cmd)
{
- const struct drm_format_info *info;
-
- if ((mode_cmd->modifier[0] >> 56) != DRM_FORMAT_MOD_VENDOR_ARM) {
- DRM_DEBUG_KMS("Unknown modifier (not Arm)\n");
+ if (malidp_format_mod_supported(dev, mode_cmd->pixel_format,
+ mode_cmd->modifier[0]) == false)
return false;
- }
-
- if (mode_cmd->modifier[0] &
- ~DRM_FORMAT_MOD_ARM_AFBC(AFBC_MOD_VALID_BITS)) {
- DRM_DEBUG_KMS("Unsupported modifiers\n");
- return false;
- }
-
- info = drm_get_format_info(dev, mode_cmd);
- if (!info) {
- DRM_DEBUG_KMS("Unable to get the format information\n");
- return false;
- }
-
- if (info->num_planes != 1) {
- DRM_DEBUG_KMS("AFBC buffers expect one plane\n");
- return false;
- }
if (mode_cmd->offsets[0] != 0) {
DRM_DEBUG_KMS("AFBC buffers' plane offset should be 0\n");
return false;
}
- switch (mode_cmd->modifier[0] & AFBC_FORMAT_MOD_BLOCK_SIZE_MASK) {
- case AFBC_FORMAT_MOD_BLOCK_SIZE_16x16:
+ switch (mode_cmd->modifier[0] & AFBC_SIZE_MASK) {
+ case AFBC_SIZE_16X16:
if ((mode_cmd->width % 16) || (mode_cmd->height % 16)) {
DRM_DEBUG_KMS("AFBC buffers must be aligned to 16
pixels\n");
return false;
@@ -319,8 +299,8 @@ malidp_verify_afbc_framebuffer_size(struct drm_device *dev,
u32 afbc_superblock_size = 0, afbc_superblock_height = 0;
u32 afbc_superblock_width = 0, afbc_size = 0;
- switch (mode_cmd->modifier[0] & AFBC_FORMAT_MOD_BLOCK_SIZE_MASK) {
- case AFBC_FORMAT_MOD_BLOCK_SIZE_16x16:
+ switch (mode_cmd->modifier[0] & AFBC_SIZE_MASK) {
+ case AFBC_SIZE_16X16:
afbc_superblock_height = 16;
afbc_superblock_width = 16;
break;
diff --git a/drivers/gpu/drm/arm/malidp_drv.h b/drivers/gpu/drm/arm/malidp_drv.h
index b76c86f..019a682 100644
--- a/drivers/gpu/drm/arm/malidp_drv.h
+++ b/drivers/gpu/drm/arm/malidp_drv.h
@@ -90,6 +90,12 @@ struct malidp_crtc_state {
int malidp_de_planes_init(struct drm_device *drm);
int malidp_crtc_init(struct drm_device *drm);
+bool malidp_hw_format_is_linear_only(u32 format);
+bool malidp_hw_format_is_afbc_only(u32 format);
+
+bool
[PATCH 06/10] drm/arm/malidp: Specified the rotation memory requirements for AFBC YUV formats
From: Ayan Kumar Halder
The newly supported AFBC YUV formats have the following rotation memory
constraints (in DP550/DP650).
1. DRM_FORMAT_VUY888/DRM_FORMAT_VUY101010 :- It can rotate upto 8
horizontal lines in the AFBC output buffer.
2. DRM_FORMAT_YUV420_8BIT :- It can rotate upto 16 horizontal lines
in the AFBC output buffer.
Also some of the pixel formats are specified in bits per pixel (rather
than bytes per pixel), so the calculation needs to take note of this.
Besides there are some difference between DP550 and DP650 and these are
as follows:-
1. DRM_FORMAT_X0L2 (in uncompressed format) does not support rotation in
DP550. For DP650, it can rotate upto 16 horizontal lines in the AFBC
output buffer, whereas in DP550 (with AFBC), it can rotate upto 8
horizontal lines.
2. DRM_FORMAT_YUV420_10BIT :- It can rotate upto 8 horizontal lines in
dp550 and 16 horizontal lines in DP650.
Signed-off-by: Ayan Kumar halder
Reviewed-by: Liviu Dudau
---
drivers/gpu/drm/arm/malidp_hw.c | 101
drivers/gpu/drm/arm/malidp_hw.h | 5 +-
drivers/gpu/drm/arm/malidp_planes.c | 3 +-
3 files changed, 98 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/arm/malidp_hw.c b/drivers/gpu/drm/arm/malidp_hw.c
index 0ac2762..8df12e9 100644
--- a/drivers/gpu/drm/arm/malidp_hw.c
+++ b/drivers/gpu/drm/arm/malidp_hw.c
@@ -380,14 +380,39 @@ static void malidp500_modeset(struct malidp_hw_device
*hwdev, struct videomode *
malidp_hw_clearbits(hwdev, MALIDP_DISP_FUNC_ILACED,
MALIDP_DE_DISPLAY_FUNC);
}
-static int malidp500_rotmem_required(struct malidp_hw_device *hwdev, u16 w,
u16 h, u32 fmt)
+int malidp_format_get_bpp(u32 fmt)
+{
+ int bpp = drm_format_plane_cpp(fmt, 0) * 8;
+
+ if (bpp == 0) {
+ switch (fmt) {
+ case DRM_FORMAT_VUY101010:
+ bpp = 30;
+ case DRM_FORMAT_YUV420_10BIT:
+ bpp = 15;
+ break;
+ case DRM_FORMAT_YUV420_8BIT:
+ bpp = 12;
+ break;
+ default:
+ bpp = 0;
+ }
+ }
+
+ return bpp;
+}
+
+static int malidp500_rotmem_required(struct malidp_hw_device *hwdev, u16 w,
+u16 h, u32 fmt, bool has_modifier)
{
/*
* Each layer needs enough rotation memory to fit 8 lines
* worth of pixel data. Required size is then:
*size = rotated_width * (bpp / 8) * 8;
*/
- return w * drm_format_plane_cpp(fmt, 0) * 8;
+ int bpp = malidp_format_get_bpp(fmt);
+
+ return w * bpp;
}
static void malidp500_se_write_pp_coefftab(struct malidp_hw_device *hwdev,
@@ -665,9 +690,9 @@ static void malidp550_modeset(struct malidp_hw_device
*hwdev, struct videomode *
malidp_hw_clearbits(hwdev, MALIDP_DISP_FUNC_ILACED,
MALIDP_DE_DISPLAY_FUNC);
}
-static int malidp550_rotmem_required(struct malidp_hw_device *hwdev, u16 w,
u16 h, u32 fmt)
+static int malidpx50_get_bytes_per_column(u32 fmt)
{
- u32 bytes_per_col;
+ u32 bytes_per_column;
switch (fmt) {
/* 8 lines at 4 bytes per pixel */
@@ -693,19 +718,77 @@ static int malidp550_rotmem_required(struct
malidp_hw_device *hwdev, u16 w, u16
case DRM_FORMAT_UYVY:
case DRM_FORMAT_YUYV:
case DRM_FORMAT_X0L0:
- case DRM_FORMAT_X0L2:
- bytes_per_col = 32;
+ bytes_per_column = 32;
break;
/* 16 lines at 1.5 bytes per pixel */
case DRM_FORMAT_NV12:
case DRM_FORMAT_YUV420:
- bytes_per_col = 24;
+ /* 8 lines at 3 bytes per pixel */
+ case DRM_FORMAT_VUY888:
+ /* 16 lines at 12 bits per pixel */
+ case DRM_FORMAT_YUV420_8BIT:
+ /* 8 lines at 3 bytes per pixel */
+ case DRM_FORMAT_P010:
+ bytes_per_column = 24;
+ break;
+ /* 8 lines at 30 bits per pixel */
+ case DRM_FORMAT_VUY101010:
+ /* 16 lines at 15 bits per pixel */
+ case DRM_FORMAT_YUV420_10BIT:
+ bytes_per_column = 30;
break;
default:
return -EINVAL;
}
- return w * bytes_per_col;
+ return bytes_per_column;
+}
+
+static int malidp550_rotmem_required(struct malidp_hw_device *hwdev, u16 w,
+u16 h, u32 fmt, bool has_modifier)
+{
+ int bytes_per_column = 0;
+
+ switch (fmt) {
+ /* 8 lines at 15 bits per pixel */
+ case DRM_FORMAT_YUV420_10BIT:
+ bytes_per_column = 15;
+ break;
+ /* Uncompressed YUV 420 10 bit single plane cannot be rotated */
+ case DRM_FORMAT_X0L2:
+ if (has_modifier)
+ bytes_per_column = 8;
+ else
+ return -EINVAL;
+ break;
+
[PATCH 08/10] drm/arm/malidp:- Use the newly introduced malidp_format_get_bpp() instead of relying on cpp for calculating framebuffer size
From: Ayan Kumar Halder
Formats like DRM_FORMAT_VUY101010, DRM_FORMAT_YUV420_8BIT and
DRM_FORMAT_YUV420_10BIT are expressed in bits per pixel as they have a non
integer value of cpp (thus denoted as '0' in drm_format_info[]). Therefore,
the calculation of AFBC framebuffer size needs to use malidp_format_get_bpp().
Signed-off-by: Ayan Kumar halder
Reviewed-by: Liviu Dudau
---
drivers/gpu/drm/arm/malidp_drv.c | 15 ++-
1 file changed, 10 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/arm/malidp_drv.c b/drivers/gpu/drm/arm/malidp_drv.c
index c697664..4106f5d 100644
--- a/drivers/gpu/drm/arm/malidp_drv.c
+++ b/drivers/gpu/drm/arm/malidp_drv.c
@@ -298,6 +298,7 @@ malidp_verify_afbc_framebuffer_size(struct drm_device *dev,
struct drm_gem_object *objs = NULL;
u32 afbc_superblock_size = 0, afbc_superblock_height = 0;
u32 afbc_superblock_width = 0, afbc_size = 0;
+ int bpp = 0;
switch (mode_cmd->modifier[0] & AFBC_SIZE_MASK) {
case AFBC_SIZE_16X16:
@@ -314,15 +315,19 @@ malidp_verify_afbc_framebuffer_size(struct drm_device
*dev,
n_superblocks = (mode_cmd->width / afbc_superblock_width) *
(mode_cmd->height / afbc_superblock_height);
- afbc_superblock_size = info->cpp[0] * afbc_superblock_width *
- afbc_superblock_height;
+ bpp = malidp_format_get_bpp(info->format);
+
+ afbc_superblock_size = (bpp * afbc_superblock_width *
afbc_superblock_height)
+ / BITS_PER_BYTE;
afbc_size = ALIGN(n_superblocks * AFBC_HEADER_SIZE,
AFBC_SUPERBLK_ALIGNMENT);
afbc_size += n_superblocks * ALIGN(afbc_superblock_size,
AFBC_SUPERBLK_ALIGNMENT);
- if (mode_cmd->width * info->cpp[0] != mode_cmd->pitches[0]) {
- DRM_DEBUG_KMS("Invalid value of pitch (=%u) should be same as
width (=%u) * cpp (=%u)\n",
- mode_cmd->pitches[0], mode_cmd->width,
info->cpp[0]);
+ if ((mode_cmd->width * bpp) != (mode_cmd->pitches[0] * BITS_PER_BYTE)) {
+ DRM_DEBUG_KMS("Invalid value of (pitch * BITS_PER_BYTE) (=%u) "
+ "should be same as width (=%u) * bpp (=%u)\n",
+ (mode_cmd->pitches[0] * BITS_PER_BYTE),
+ mode_cmd->width, bpp);
return false;
}
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 01/10] drm/fourcc: Add AFBC yuv fourccs for Mali
From: Brian Starkey As we look to enable AFBC using DRM format modifiers, we run into problems which we've historically handled via vendor-private details (i.e. gralloc, on Android). AFBC (as an encoding) is fully flexible, and for example YUV data can be encoded into 1, 2 or 3 encoded "planes", much like the linear equivalents. Component order is also meaningful, as AFBC doesn't necessarily care about what each "channel" of the data it encodes contains. Therefore ABGR and RGBA can be encoded in AFBC with different representations. Similarly, 'X' components may be encoded into AFBC streams in cases where a decoder expects to decode a 4th component. In addition, AFBC is a licensable IP, meaning that to support the ecosystem we need to ensure that _all_ AFBC users are able to describe the encodings that they need. This is much better achieved by preserving meaning in the fourcc codes when they are combined with an AFBC modifier. In essence, we want to use the modifier to describe the parameters of the AFBC encode/decode, and use the fourcc code to describe the data being encoded/decoded. To do anything different would be to introduce redundancy - we would need to duplicate in the modifier information which is _already_ conveyed clearly and non-ambigiously by a fourcc code. I hope that for RGB this is non-controversial. (BGRA + MODIFIER_AFBC) is a different format from (RGBA + MODIFIER_AFBC). Possibly more controversial is that (XBGR + MODIFIER_AFBC) is different from (BGR888 + MODIFIER_AFBC). I understand that in some schemes it is not the case - but in AFBC it is so. Where we run into problems is where there are not already fourcc codes which represent the data which the AFBC encoder/decoder is processing. To that end, we want to introduce new fourcc codes to describe the data being encoded/decoded, in the places where none of the existing fourcc codes are applicable. Where we don't support an equivalent non-compressed layout, or where no "obvious" linear layout exists, we are proposing adding fourcc codes which have no associated linear layout - because any layout we proposed would be completely arbitrary. Some formats are following the naming conventions from [2]. The summary of the new formats is: DRM_FORMAT_VUY888 - Packed 8-bit YUV 444. Y followed by U then V. DRM_FORMAT_VUY101010 - Packed 10-bit YUV 444. Y followed by U then V. No defined linear encoding. DRM_FORMAT_Y210 - Packed 10-bit YUV 422. Y followed by U (then Y) then V. 10-bit samples in 16-bit words. DRM_FORMAT_Y410 - Packed 10-bit YUV 444, with 2-bit alpha. DRM_FORMAT_P210 - Semi-planar 10-bit YUV 422. Y plane, followed by interleaved U-then-V plane. 10-bit samples in 16-bit words. DRM_FORMAT_YUV420_8BIT - Packed 8-bit YUV 420. Y followed by U then V. No defined linear encoding DRM_FORMAT_YUV420_10BIT - Packed 10-bit YUV 420. Y followed by U then V. No defined linear encoding Please also note that in the absence of AFBC, we would still need to add Y410, Y210 and P210. Full rationale follows: YUV 444 8-bit, 1-plane -- The currently defined AYUV format encodes a 4th alpha component, which makes it unsuitable for representing a 3-component YUV 444 AFBC stream. The proposed[1] XYUV format which is supported by Mali-DP in linear layout is also unsuitable, because the component order is the opposite of the AFBC version, and it encodes a 4th 'X' component. DRM_FORMAT_VUY888 is the "obvious" format for a 3-component, packed, YUV 444 8-bit format, with the component order which our HW expects to encode/decode. It conforms to the same naming convention as the existing packed YUV 444 format. The naming here is meant to be consistent with DRM_FORMAT_AYUV and DRM_FORMAT_XYUV[1] YUV 444 10-bit, 1-plane --- There is no currently-defined YUV 444 10-bit format in drm_fourcc.h, irrespective of number of planes. The proposed[1] XVYU2101010 format which is supported by Mali-DP in linear layout uses the wrong component order, and also encodes a 4th 'X' component, which doesn't match the AFBC version of YUV 444 10-bit which we support. DRM_FORMAT_Y410 is the same layout as XVYU2101010, but with 2 bits of alpha. This format is supported with linear layout by Mali GPUs. The naming follows[2]. There is no "obvious" linear encoding for a 3-component 10:10:10 packed format, and so DRM_FORMAT_VUY101010 defines a component order, but not a bit encoding. Again, the naming is meant to be consistent with DRM_FORMAT_AYUV. YUV 422 8-bit, 1-plane -- The existing DRM_FORMAT_YUYV (and the other component orders) are single-planar YUV 422 8-bit formats. Following the convention of the component orders of the RGB formats, YUYV has the correct component order for our AFBC encoding (Y followed by U followed by
[PATCH 07/10] drm/arm/malidp:- Writeback framebuffer does not support any modifiers
From: Ayan Kumar Halder
In malidp, the writeback pipeline does not support writing crtc output
to a framebuffer with modifiers ie the memory writeback content is
devoid of any compression or tiling, etc.
So we have added a commit check in memory writeback encoder helper function
to validate if the framebuffer has any modifier and if so, return EINVAL.
Signed-off-by: Ayan Kumar halder
Acked-by: Liviu Dudau
---
drivers/gpu/drm/arm/malidp_mw.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/gpu/drm/arm/malidp_mw.c b/drivers/gpu/drm/arm/malidp_mw.c
index 28cd351..2865f7a 100644
--- a/drivers/gpu/drm/arm/malidp_mw.c
+++ b/drivers/gpu/drm/arm/malidp_mw.c
@@ -141,6 +141,11 @@ malidp_mw_encoder_atomic_check(struct drm_encoder *encoder,
return -EINVAL;
}
+ if (fb->modifier) {
+ DRM_DEBUG_KMS("Writeback framebuffer does not support
modifiers\n");
+ return -EINVAL;
+ }
+
mw_state->format =
malidp_hw_get_format_id(>dev->hw->map, SE_MEMWRITE,
fb->format->format, !!fb->modifier);
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 03/10] drm/arm/malidp: Set the AFBC register bits if the framebuffer has AFBC modifier
From: Ayan Kumar Halder
Added the AFBC decoder registers for DP500 , DP550 and DP650.
These registers control the processing of AFBC buffers. It controls various
features like AFBC decoder enable, lossless transformation and block split
as well as setting of the left, right, top and bottom cropping of AFBC
buffers (in number of pixels).
All the layers (except DE_SMART) support framebuffers with AFBC modifiers.
One needs to set the pixel values of the top, left, bottom and right
cropping for the AFBC framebuffer.
Cropping an AFBC framebuffer is controlled by the AFBC crop registers.
In that case, the layer input size registers should be configured with
framebuffer's dimensions and not with drm_plane_state source width/height
values (which is used for non AFBC framebuffer to denote cropping).
Changes from v1:
- Removed the "if (fb->modifier)" check from malidp_de_plane_update()
and added it in malidp_de_set_plane_afbc(). This will consolidate all the
AFBC specific register configurations in a single function ie
malidp_de_set_plane_afbc().
Changes from v2:
- For AFBC framebuffer, layer input size register should be set to
framebuffer's width and height.
Changes from v3:
- Rebased on top of latest drm-misc-next
- Some cleanups/sanity changes based on Liviu's comments
Signed-off-by: Ayan Kumar Halder
---
drivers/gpu/drm/arm/malidp_hw.c | 30 ++
drivers/gpu/drm/arm/malidp_hw.h | 2 +
drivers/gpu/drm/arm/malidp_planes.c | 107
drivers/gpu/drm/arm/malidp_regs.h | 20 +++
4 files changed, 136 insertions(+), 23 deletions(-)
diff --git a/drivers/gpu/drm/arm/malidp_hw.c b/drivers/gpu/drm/arm/malidp_hw.c
index b9bed11..64c2ca3 100644
--- a/drivers/gpu/drm/arm/malidp_hw.c
+++ b/drivers/gpu/drm/arm/malidp_hw.c
@@ -94,11 +94,14 @@ static const struct malidp_layer malidp500_layers[] = {
* yuv2rgb matrix offset, mmu control register offset,
rotation_features
*/
{ DE_VIDEO1, MALIDP500_DE_LV_BASE, MALIDP500_DE_LV_PTR_BASE,
- MALIDP_DE_LV_STRIDE0, MALIDP500_LV_YUV2RGB, 0, ROTATE_ANY },
+ MALIDP_DE_LV_STRIDE0, MALIDP500_LV_YUV2RGB, 0, ROTATE_ANY,
+ MALIDP500_DE_LV_AD_CTRL },
{ DE_GRAPHICS1, MALIDP500_DE_LG1_BASE, MALIDP500_DE_LG1_PTR_BASE,
- MALIDP_DE_LG_STRIDE, 0, 0, ROTATE_ANY },
+ MALIDP_DE_LG_STRIDE, 0, 0, ROTATE_ANY,
+ MALIDP500_DE_LG1_AD_CTRL },
{ DE_GRAPHICS2, MALIDP500_DE_LG2_BASE, MALIDP500_DE_LG2_PTR_BASE,
- MALIDP_DE_LG_STRIDE, 0, 0, ROTATE_ANY },
+ MALIDP_DE_LG_STRIDE, 0, 0, ROTATE_ANY,
+ MALIDP500_DE_LG2_AD_CTRL },
};
static const struct malidp_layer malidp550_layers[] = {
@@ -106,13 +109,16 @@ static const struct malidp_layer malidp550_layers[] = {
* yuv2rgb matrix offset, mmu control register offset,
rotation_features
*/
{ DE_VIDEO1, MALIDP550_DE_LV1_BASE, MALIDP550_DE_LV1_PTR_BASE,
- MALIDP_DE_LV_STRIDE0, MALIDP550_LV_YUV2RGB, 0, ROTATE_ANY },
+ MALIDP_DE_LV_STRIDE0, MALIDP550_LV_YUV2RGB, 0, ROTATE_ANY,
+ MALIDP550_DE_LV1_AD_CTRL },
{ DE_GRAPHICS1, MALIDP550_DE_LG_BASE, MALIDP550_DE_LG_PTR_BASE,
- MALIDP_DE_LG_STRIDE, 0, 0, ROTATE_ANY },
+ MALIDP_DE_LG_STRIDE, 0, 0, ROTATE_ANY,
+ MALIDP550_DE_LG_AD_CTRL },
{ DE_VIDEO2, MALIDP550_DE_LV2_BASE, MALIDP550_DE_LV2_PTR_BASE,
- MALIDP_DE_LV_STRIDE0, MALIDP550_LV_YUV2RGB, 0, ROTATE_ANY },
+ MALIDP_DE_LV_STRIDE0, MALIDP550_LV_YUV2RGB, 0, ROTATE_ANY,
+ MALIDP550_DE_LV2_AD_CTRL },
{ DE_SMART, MALIDP550_DE_LS_BASE, MALIDP550_DE_LS_PTR_BASE,
- MALIDP550_DE_LS_R1_STRIDE, 0, 0, ROTATE_NONE },
+ MALIDP550_DE_LS_R1_STRIDE, 0, 0, ROTATE_NONE, 0 },
};
static const struct malidp_layer malidp650_layers[] = {
@@ -122,16 +128,18 @@ static const struct malidp_layer malidp650_layers[] = {
*/
{ DE_VIDEO1, MALIDP550_DE_LV1_BASE, MALIDP550_DE_LV1_PTR_BASE,
MALIDP_DE_LV_STRIDE0, MALIDP550_LV_YUV2RGB,
- MALIDP650_DE_LV_MMU_CTRL, ROTATE_ANY },
+ MALIDP650_DE_LV_MMU_CTRL, ROTATE_ANY,
+ MALIDP550_DE_LV1_AD_CTRL },
{ DE_GRAPHICS1, MALIDP550_DE_LG_BASE, MALIDP550_DE_LG_PTR_BASE,
MALIDP_DE_LG_STRIDE, 0, MALIDP650_DE_LG_MMU_CTRL,
- ROTATE_COMPRESSED },
+ ROTATE_COMPRESSED, MALIDP550_DE_LG_AD_CTRL },
{ DE_VIDEO2, MALIDP550_DE_LV2_BASE, MALIDP550_DE_LV2_PTR_BASE,
MALIDP_DE_LV_STRIDE0, MALIDP550_LV_YUV2RGB,
- MALIDP650_DE_LV_MMU_CTRL, ROTATE_ANY },
+ MALIDP650_DE_LV_MMU_CTRL, ROTATE_ANY,
+ MALIDP550_DE_LV2_AD_CTRL },
{ DE_SMART, MALIDP550_DE_LS_BASE, MALIDP550_DE_LS_PTR_BASE,
MALIDP550_DE_LS_R1_STRIDE, 0, MALIDP650_DE_LS_MMU_CTRL,
[PATCH 02/10] drm: Added a new format DRM_FORMAT_XVYU2101010
From: Ayan Kumar Halder
This new format is supported by DP550 and DP650
Signed-off-by: Ayan Kumar halder
Reviewed-by: Liviu Dudau
---
drivers/gpu/drm/drm_fourcc.c | 1 +
include/uapi/drm/drm_fourcc.h | 1 +
2 files changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/drm_fourcc.c b/drivers/gpu/drm/drm_fourcc.c
index 0a3efa5..8681f01 100644
--- a/drivers/gpu/drm/drm_fourcc.c
+++ b/drivers/gpu/drm/drm_fourcc.c
@@ -229,6 +229,7 @@ const struct drm_format_info *__drm_format_info(u32 format)
{ .format = DRM_FORMAT_VUY888, .depth = 0,
.num_planes = 1, .cpp = { 3, 0, 0 }, .hsub = 1, .vsub = 1, .is_yuv = true },
{ .format = DRM_FORMAT_Y410,.depth = 0,
.num_planes = 1, .cpp = { 4, 0, 0 }, .hsub = 1, .vsub = 1, .has_alpha = true,
.is_yuv = true },
{ .format = DRM_FORMAT_AYUV,.depth = 0,
.num_planes = 1, .cpp = { 4, 0, 0 }, .hsub = 1, .vsub = 1, .has_alpha = true,
.is_yuv = true },
+ { .format = DRM_FORMAT_XVYU2101010, .depth = 0,
.num_planes = 1, .cpp = { 4, 0, 0 }, .hsub = 1, .vsub = 1, .is_yuv = true },
{ .format = DRM_FORMAT_Y0L0,.depth = 0,
.num_planes = 1,
.char_per_block = { 8, 0, 0 }, .block_w = { 2, 0, 0 },
.block_h = { 2, 0, 0 },
.hsub = 2, .vsub = 2, .has_alpha = true, .is_yuv = true },
diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
index b4fb674..5fed518 100644
--- a/include/uapi/drm/drm_fourcc.h
+++ b/include/uapi/drm/drm_fourcc.h
@@ -153,6 +153,7 @@ extern "C" {
#define DRM_FORMAT_AYUVfourcc_code('A', 'Y', 'U', 'V') /*
[31:0] A:Y:Cb:Cr 8:8:8:8 little endian */
#define DRM_FORMAT_XYUVfourcc_code('X', 'Y', 'U', 'V') /* [31:0]
X:Y:Cb:Cr 8:8:8:8 little endian */
+#define DRM_FORMAT_XVYU2101010 fourcc_code('X', 'V', '3', '0') /* [31:0]
X:Cr:Y:Cb 2:10:10:10 little endian */
#define DRM_FORMAT_VUY888 fourcc_code('V', 'U', '2', '4') /* [23:0]
Cr:Cb:Y 8:8:8 little endian */
#define DRM_FORMAT_Y410fourcc_code('Y', '4', '1', '0') /*
[31:0] A:Cr:Y:Cb 2:10:10:10 little endian */
#define DRM_FORMAT_VUY101010 fourcc_code('V', 'U', '3', '0') /* Y followed
by U then V, 10:10:10. Non-linear modifier only */
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 00/10] Add support for Arm Framebuffer Compression(AFBC) in mali display driver
This patchset aims to add support for AFBC in mali display driver with the help of format modifiers. AFBC modifiers add some constraints to framebuffer size, alignment, pitch, formats, etc In the initial patchset ie https://lists.freedesktop.org/archives/dri-devel/2018-June/180124.html I had illustrated how to add support for one format (ie BGR888) with one valid combination of AFBC modifiers ie AFBC_SIZE_16X16 | AFBC_YTR | AFBC_SPARSE Changes from v1:- Enabled the support for all AFBC modifiers (which are supported on DP500, DP550 and DP650) with all the pixel formats. Also, we have introduced some new pixel formats which are supported with AFBC modifiers only as well some other pixel formats which are supported with LINEAR only. Changes from v2 (ie https://patchwork.freedesktop.org/patch/265212/):- - Addressed the review comments on the previous patchset. - Rebased on top of the drm-misc-next Ayan Kumar Halder (9): drm: Added a new format DRM_FORMAT_XVYU2101010 drm/arm/malidp: Set the AFBC register bits if the framebuffer has AFBC modifier drm/arm/malidp:- Added support for new YUV formats for DP500, DP550 and DP650 drm/arm/malidp:- Define a common list of AFBC format modifiers supported for DP500, DP550 and DP650 drm/arm/malidp: Specified the rotation memory requirements for AFBC YUV formats drm/arm/malidp:- Writeback framebuffer does not support any modifiers drm/arm/malidp:- Use the newly introduced malidp_format_get_bpp() instead of relying on cpp for calculating framebuffer size drm/arm/malidp:- Disregard the pitch alignment constraint for AFBC framebuffer. drm/arm/malidp: Added support for AFBC modifiers for all layers except DE_SMART Brian Starkey (1): drm/fourcc: Add AFBC yuv fourccs for Mali drivers/gpu/drm/arm/malidp_drv.c| 48 +++ drivers/gpu/drm/arm/malidp_drv.h| 6 + drivers/gpu/drm/arm/malidp_hw.c | 249 + drivers/gpu/drm/arm/malidp_hw.h | 31 - drivers/gpu/drm/arm/malidp_mw.c | 7 +- drivers/gpu/drm/arm/malidp_planes.c | 271 +--- drivers/gpu/drm/arm/malidp_regs.h | 20 +++ drivers/gpu/drm/drm_fourcc.c| 17 +++ include/uapi/drm/drm_fourcc.h | 23 ++- 9 files changed, 586 insertions(+), 86 deletions(-) -- 2.7.4 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] [RFC] drm_hwcomposer: Add support for Arm Framebuffer Compression (AFBC) modifiers.
On Tue, Jan 15, 2019 at 02:29:19PM +0100, Daniel Vetter wrote:
> On Tue, Jan 15, 2019 at 2:27 PM Liviu Dudau wrote:
> >
> > On Tue, Jan 15, 2019 at 01:38:19PM +0100, Daniel Vetter wrote:
> > > On Tue, Jan 15, 2019 at 1:24 PM Liviu Dudau wrote:
> > > >
> > > > On Tue, Jan 15, 2019 at 01:05:47PM +0100, Daniel Vetter wrote:
> > > > > On Mon, Jan 14, 2019 at 03:28:27PM +, Ayan Halder wrote:
> > > > > > One needs to translate the Gralloc buffer flags for AFBC (eg
> > > > > > MALI_GRALLOC_INTFMT_AFBC_BASIC) to the corresponding linux kernel
> > > > > > drm modifiers.
> > > > > > This gets passed to libdrm via drmModeAddFB2WithModifiers.
> > > > > >
> > > > > > Signed-off-by: Ayan Kumar Halder
> > > > > >
> > > > > > /-- Note for reviewer
> > > > > > I was able to get this working for Android P on Juno with Mali
> > > > > > DP650 and Mali
> > > > > > T860 gpu(with some additional hacks). I have not yet validated this
> > > > > > hikey960.
> > > > > >
> > > > > > I have used the following components:-
> > > > > > 1. Gralloc (from
> > > > > > https://android.googlesource.com/device/linaro/hikey/+/master/gralloc960)
> > > > > > - Built with MALI_MMSS=1
> > > > > > 2. Libdrm (from git://anongit.freedesktop.org/mesa/drm)
> > > > > > - You would need drm_fourcc.h and gralloc_handle.h
> > > > > > --/
> > > > >
> > > > > I thought drm_hwcomposer has switched over to gitlab merge requests?
> > > > > README at least says so:
> > > > >
> > > > > https://gitlab.freedesktop.org/drm-hwcomposer/drm-hwcomposer
> > > >
> > > > So are we to send pull requests for RFCs as well?
> > >
> > > Hm, not sure you should stuff RFC material into your linux-next
> > > branches. I thought that's only for patches which by all intents are
> > > ready for the next merge window, i.e. reviewed and all that.
> > > Not for in-flight stuff still under discussion.
> >
> > I think you're confusing the documentation patch with the drm_hwcomposer
> > one (this one).
>
> Indeed. And yes everything even RFC. Gitlab even has some special
> support for work in progress, just start your pull request summary
> with WIP.
> -Daniel
>
Thanks, I have created a merge request now. I wasnot sure initially
how the review process worked for gitlab projects.
> >
> > Best regards,
> > Liviu
> >
> > > -Daniel
> > >
> > >
> > > > Best regards,
> > > > Liviu
> > > >
> > > > >
> > > > > Cheers, Daniel
> > > > >
> > > > > > ---
> > > > > > platformdrmgeneric.cpp | 42
> > > > > > ++
> > > > > > platformdrmgeneric.h | 2 ++
> > > > > > platformhisi.cpp | 14 --
> > > > > > 3 files changed, 56 insertions(+), 2 deletions(-)
> > > > > >
> > > > > > diff --git a/platformdrmgeneric.cpp b/platformdrmgeneric.cpp
> > > > > > index 503c04a..a520224 100644
> > > > > > --- a/platformdrmgeneric.cpp
> > > > > > +++ b/platformdrmgeneric.cpp
> > > > > > @@ -18,6 +18,7 @@
> > > > > >
> > > > > > #include "platformdrmgeneric.h"
> > > > > > #include "drmdevice.h"
> > > > > > +#include "mali_gralloc_formats.h"
> > > > > > #include "platform.h"
> > > > > >
> > > > > > #include
> > > > > > @@ -83,6 +84,31 @@ uint32_t
> > > > > > DrmGenericImporter::ConvertHalFormatToDrm(uint32_t hal_format) {
> > > > > >}
> > > > > > }
> > > > > >
> > > > > > +uint64_t
> > > > > > DrmGenericImporter::ConvertGrallocFormatToDrmModifiers(uint64_t
> > > > > > flags,
> > > > > > +
> > > > > > bool is_rgb) {
> > > > > > + uint64_t features = 0;
> > > > > > +
> > > > > > + if (flags & MALI_GRALLOC_INTFMT_AFBC_BASIC)
> > >
[PATCH] drm/fourcc: Add modifier defininitions for AFBC 1.3
From: Matteo Franchin
This commit adds definitions of format modifiers for version 1.3 of the
Arm Framebuffer Compression (AFBC).
Signed-off-by: Matteo Franchin
---
include/uapi/drm/drm_fourcc.h | 23 +++
1 file changed, 23 insertions(+)
diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
index 8dd1328..d6a20d4 100644
--- a/include/uapi/drm/drm_fourcc.h
+++ b/include/uapi/drm/drm_fourcc.h
@@ -602,10 +602,18 @@ extern "C" {
* Indicates the superblock size(s) used for the AFBC buffer. The buffer
* size (in pixels) must be aligned to a multiple of the superblock size.
* Four lowest significant bits(LSBs) are reserved for block size.
+ *
+ * Where one superblock size is specified, it applies to all planes of the
+ * buffer (e.g. 16x16, 32x8). When multiple superblock sizes are specified,
+ * the first applies to the Luma plane and the second applies to the Chroma
+ * plane(s). e.g. (32x8_64x4 means 32x8 Luma, with 64x4 Chroma).
+ * Multiple superblock sizes are only valid for multi-plane YCbCr formats.
*/
#define AFBC_FORMAT_MOD_BLOCK_SIZE_MASK 0xf
#define AFBC_FORMAT_MOD_BLOCK_SIZE_16x16 (1ULL)
#define AFBC_FORMAT_MOD_BLOCK_SIZE_32x8 (2ULL)
+#define AFBC_FORMAT_MOD_BLOCK_SIZE_64x4 (3ULL)
+#define AFBC_FORMAT_MOD_BLOCK_SIZE_32x8_64x4 (4ULL)
/*
* AFBC lossless colorspace transform
@@ -665,6 +673,21 @@ extern "C" {
*/
#define AFBC_FORMAT_MOD_SC (1ULL << 9)
+/*
+ * AFBC double-buffer
+ *
+ * Indicates that the buffer is allocated in a layout safe for front-buffer
+ * rendering.
+ */
+#define AFBC_FORMAT_MOD_DB (1ULL << 10)
+
+/*
+ * AFBC buffer content hints
+ *
+ * Indicates that the buffer includes per-superblock content hints.
+ */
+#define AFBC_FORMAT_MOD_BCH (1ULL << 11)
+
#if defined(__cplusplus)
}
#endif
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v10 1/2] drm/fourcc: Add new P010, P016 video format
On Thu, Jan 10, 2019 at 03:57:09AM +0800, Randy Li wrote:
> P010 is a planar 4:2:0 YUV with interleaved UV plane, 10 bits per
> channel video format.
>
> P012 is a planar 4:2:0 YUV 12 bits per channel
>
> P016 is a planar 4:2:0 YUV with interleaved UV plane, 16 bits per
> channel video format.
>
> V3: Added P012 and fixed cpp for P010.
> V4: format definition refined per review.
> V5: Format comment block for each new pixel format.
> V6: reversed Cb/Cr order in comments.
> v7: reversed Cb/Cr order in comments of header files, remove
> the wrong part of commit message.
> V8: reversed V7 changes except commit message and rebased.
> v9: used the new properties to describe those format and
> rebased.
>
> Cc: Daniel Stone
> Cc: Ville Syrj??l??
>
> Signed-off-by: Randy Li
> Signed-off-by: Clint Taylor
> ---
> drivers/gpu/drm/drm_fourcc.c | 9 +
> include/uapi/drm/drm_fourcc.h | 21 +
> 2 files changed, 30 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_fourcc.c b/drivers/gpu/drm/drm_fourcc.c
> index d90ee03a84c6..ba7e19d4336c 100644
> --- a/drivers/gpu/drm/drm_fourcc.c
> +++ b/drivers/gpu/drm/drm_fourcc.c
> @@ -238,6 +238,15 @@ const struct drm_format_info *__drm_format_info(u32
> format)
> { .format = DRM_FORMAT_X0L2,.depth = 0,
> .num_planes = 1,
> .char_per_block = { 8, 0, 0 }, .block_w = { 2, 0, 0 },
> .block_h = { 2, 0, 0 },
> .hsub = 2, .vsub = 2, .is_yuv = true },
> + { .format = DRM_FORMAT_P010,.depth = 0,
> .num_planes = 2,
> + .char_per_block = { 2, 4, 0 }, .block_w = { 1, 0, 0 },
> .block_h = { 1, 0, 0 },
> + .hsub = 2, .vsub = 2, .is_yuv = true},
> + { .format = DRM_FORMAT_P012,.depth = 0,
> .num_planes = 2,
> + .char_per_block = { 2, 4, 0 }, .block_w = { 1, 0, 0 },
> .block_h = { 1, 0, 0 },
> +.hsub = 2, .vsub = 2, .is_yuv = true},
> + { .format = DRM_FORMAT_P016,.depth = 0,
> .num_planes = 2,
> + .char_per_block = { 2, 4, 0 }, .block_w = { 1, 0, 0 },
> .block_h = { 1, 0, 0 },
> + .hsub = 2, .vsub = 2, .is_yuv = true},
> };
>
> unsigned int i;
> diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
> index 0b44260a5ee9..8dd1328bc8d6 100644
> --- a/include/uapi/drm/drm_fourcc.h
> +++ b/include/uapi/drm/drm_fourcc.h
> @@ -195,6 +195,27 @@ extern "C" {
> #define DRM_FORMAT_NV24 fourcc_code('N', 'V', '2', '4') /*
> non-subsampled Cr:Cb plane */
> #define DRM_FORMAT_NV42 fourcc_code('N', 'V', '4', '2') /*
> non-subsampled Cb:Cr plane */
>
> +/*
> + * 2 plane YCbCr MSB aligned
> + * index 0 = Y plane, [15:0] Y:x [10:6] little endian
> + * index 1 = Cr:Cb plane, [31:0] Cr:x:Cb:x [10:6:10:6] little endian
> + */
> +#define DRM_FORMAT_P010 fourcc_code('P', '0', '1', '0') /* 2x2
> subsampled Cr:Cb plane 10 bits per channel */
> +
> +/*
> + * 2 plane YCbCr MSB aligned
> + * index 0 = Y plane, [15:0] Y:x [12:4] little endian
> + * index 1 = Cr:Cb plane, [31:0] Cr:x:Cb:x [12:4:12:4] little endian
> + */
> +#define DRM_FORMAT_P012 fourcc_code('P', '0', '1', '2') /* 2x2
> subsampled Cr:Cb plane 12 bits per channel */
> +
> +/*
> + * 2 plane YCbCr MSB aligned
> + * index 0 = Y plane, [15:0] Y little endian
> + * index 1 = Cr:Cb plane, [31:0] Cr:Cb [16:16] little endian
> + */
> +#define DRM_FORMAT_P016 fourcc_code('P', '0', '1', '6') /* 2x2
> subsampled Cr:Cb plane 16 bits per channel */
> +
looks good to me.
Reviewed by:- Ayan Kumar Halder
We are using P010 format for our mali display driver. Our AFBC patch
series(https://patchwork.freedesktop.org/series/53395/) is dependent
on this patch. So, that's why I wanted to know when you are planning to
merge this. As far as I remember, Juha wanted to implement some igt
tests
(https://lists.freedesktop.org/archives/intel-gfx/2018-September/174877.html)
, so is that done now?
My apologies if I am pushing hard on this.
> /*
> * 3 plane YCbCr
> * index 0: Y plane, [7:0] Y
> --
> 2.20.1
>
> ___
> 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
[PATCH] [RFC] drm_hwcomposer: Add support for Arm Framebuffer Compression (AFBC) modifiers.
One needs to translate the Gralloc buffer flags for AFBC (eg
MALI_GRALLOC_INTFMT_AFBC_BASIC) to the corresponding linux kernel drm modifiers.
This gets passed to libdrm via drmModeAddFB2WithModifiers.
Signed-off-by: Ayan Kumar Halder
/-- Note for reviewer
I was able to get this working for Android P on Juno with Mali DP650 and Mali
T860 gpu(with some additional hacks). I have not yet validated this hikey960.
I have used the following components:-
1. Gralloc (from
https://android.googlesource.com/device/linaro/hikey/+/master/gralloc960)
- Built with MALI_MMSS=1
2. Libdrm (from git://anongit.freedesktop.org/mesa/drm)
- You would need drm_fourcc.h and gralloc_handle.h
--/
---
platformdrmgeneric.cpp | 42 ++
platformdrmgeneric.h | 2 ++
platformhisi.cpp | 14 --
3 files changed, 56 insertions(+), 2 deletions(-)
diff --git a/platformdrmgeneric.cpp b/platformdrmgeneric.cpp
index 503c04a..a520224 100644
--- a/platformdrmgeneric.cpp
+++ b/platformdrmgeneric.cpp
@@ -18,6 +18,7 @@
#include "platformdrmgeneric.h"
#include "drmdevice.h"
+#include "mali_gralloc_formats.h"
#include "platform.h"
#include
@@ -83,6 +84,31 @@ uint32_t DrmGenericImporter::ConvertHalFormatToDrm(uint32_t
hal_format) {
}
}
+uint64_t DrmGenericImporter::ConvertGrallocFormatToDrmModifiers(uint64_t flags,
+bool is_rgb) {
+ uint64_t features = 0;
+
+ if (flags & MALI_GRALLOC_INTFMT_AFBC_BASIC)
+features |= AFBC_FORMAT_MOD_BLOCK_SIZE_16x16;
+
+ if (is_rgb)
+features |= AFBC_FORMAT_MOD_YTR;
+
+ if (flags & MALI_GRALLOC_INTFMT_AFBC_SPLITBLK)
+features |= (AFBC_FORMAT_MOD_SPLIT | AFBC_FORMAT_MOD_SPARSE);
+
+ if (flags & MALI_GRALLOC_INTFMT_AFBC_WIDEBLK)
+features |= AFBC_FORMAT_MOD_BLOCK_SIZE_32x8;
+
+ if (flags & MALI_GRALLOC_INTFMT_AFBC_TILED_HEADERS)
+features |= AFBC_FORMAT_MOD_TILED;
+
+ if (features)
+return DRM_FORMAT_MOD_ARM_AFBC(features);
+ else
+return 0;
+}
+
uint32_t DrmGenericImporter::DrmFormatToBitsPerPixel(uint32_t drm_format) {
switch (drm_format) {
case DRM_FORMAT_ARGB:
@@ -101,6 +127,22 @@ uint32_t
DrmGenericImporter::DrmFormatToBitsPerPixel(uint32_t drm_format) {
}
}
+bool DrmGenericImporter::IsDrmFormatRgb(uint32_t drm_format) {
+ switch (drm_format) {
+case DRM_FORMAT_ARGB:
+case DRM_FORMAT_XBGR:
+case DRM_FORMAT_ABGR:
+case DRM_FORMAT_BGR888:
+case DRM_FORMAT_BGR565:
+ return true;
+case DRM_FORMAT_YVU420:
+ return false;
+default:
+ ALOGE("Unsupported format %u assuming rgb?", drm_format);
+ return true;
+ }
+}
+
int DrmGenericImporter::ImportBuffer(buffer_handle_t handle, hwc_drm_bo_t *bo)
{
gralloc_handle_t *gr_handle = gralloc_handle(handle);
if (!gr_handle)
diff --git a/platformdrmgeneric.h b/platformdrmgeneric.h
index 233ba55..43cb618 100644
--- a/platformdrmgeneric.h
+++ b/platformdrmgeneric.h
@@ -36,6 +36,8 @@ class DrmGenericImporter : public Importer {
bool CanImportBuffer(buffer_handle_t handle) override;
uint32_t ConvertHalFormatToDrm(uint32_t hal_format);
+ uint64_t ConvertGrallocFormatToDrmModifiers(uint64_t flags, bool is_rgb);
+ bool IsDrmFormatRgb(uint32_t drm_format);
uint32_t DrmFormatToBitsPerPixel(uint32_t drm_format);
private:
diff --git a/platformhisi.cpp b/platformhisi.cpp
index 76fe1e7..1cb7e2c 100644
--- a/platformhisi.cpp
+++ b/platformhisi.cpp
@@ -71,6 +71,9 @@ int HisiImporter::Init() {
}
int HisiImporter::ImportBuffer(buffer_handle_t handle, hwc_drm_bo_t *bo) {
+ bool is_rgb;
+ uint64_t modifiers[4] = {0};
+
memset(bo, 0, sizeof(hwc_drm_bo_t));
private_handle_t const *hnd = reinterpret_cast(
@@ -94,6 +97,10 @@ int HisiImporter::ImportBuffer(buffer_handle_t handle,
hwc_drm_bo_t *bo) {
if (fmt < 0)
return fmt;
+ is_rgb = IsDrmFormatRgb(fmt);
+ modifiers[0] = ConvertGrallocFormatToDrmModifiers(hnd->internal_format,
+is_rgb);
+
bo->width = hnd->width;
bo->height = hnd->height;
bo->hal_format = hnd->req_format;
@@ -129,8 +136,11 @@ int HisiImporter::ImportBuffer(buffer_handle_t handle,
hwc_drm_bo_t *bo) {
break;
}
- ret = drmModeAddFB2(drm_->fd(), bo->width, bo->height, bo->format,
- bo->gem_handles, bo->pitches, bo->offsets, >fb_id,
0);
+ ret = drmModeAddFB2WithModifiers(drm_->fd(), bo->width, bo->height,
+ bo->format, bo->gem_handles, bo->pitches,
+ bo->offsets, modifiers, >fb_id,
+ modifiers[0] ? DRM_MODE_FB_MODIFIERS : 0);
+
if (ret) {
ALOGE("could not create drm fb %d", ret);
return ret;
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC AFBC 07/12] drm/arm/malidp: Define the constraints on each supported drm_fourcc format for the AFBC modifiers.
On Tue, Dec 04, 2018 at 05:49:12PM +, Liviu Dudau wrote:
> On Mon, Dec 03, 2018 at 11:32:01AM +0000, Ayan Halder wrote:
> > The constraints are as follows (for Mali-DP 500, 550, 650) :-
> >
> > 1. AFBC is not supported for the formats defined in
> > malidp_hw_format_is_linear_only()
> >
> > 2. Some of the formats are supported only with AFBC modifiers. Thus we have
> > introduced a new function 'malidp_hw_format_is_afbc_only()' which verifies
> > the same.
> >
> > 3. AFBC_FORMAT_MOD_YTR needs to be provided for any RGB format.
> >
> > 4. Formats <= 16bpp cannot support AFBC_FORMAT_MOD_SPLIT.
> >
> > 5. CBR should not be set for non-subsampled formats.
> >
> > 6. SMART layer does not support framebuffer with AFBC modifiers.
> > Return -EINVAL for such a scenario.
> >
> > 7. AFBC_FORMAT_MOD_YTR is not supported for any YUV formats.
> >
> > 8. Formats which are subsampled cannot support AFBC_FORMAT_MOD_SPLIT.
> > However in
> > DP550, YUV_420_10BIT is supported with AFBC_FORMAT_MOD_SPLIT. This feature
> > has
> > been identified with MALIDP_DEVICE_AFBC_YUV_420_10_SUPPORT_SPLIT.
> >
> > 9. In DP550 and DP650, for YUYV, the hardware supports different format-ids
> > to
> > be used with and without AFBC modifier. We have used the feature
> > 'MALIDP_DEVICE_AFBC_YUYV_USE_422_P2' to identify this characteristic.
> >
> > Signed-off-by: Ayan Kumar halder
> > ---
> > drivers/gpu/drm/arm/malidp_drv.c| 23 +--
> > drivers/gpu/drm/arm/malidp_drv.h| 6 ++
> > drivers/gpu/drm/arm/malidp_hw.c | 71 +++--
> > drivers/gpu/drm/arm/malidp_hw.h | 5 +-
> > drivers/gpu/drm/arm/malidp_mw.c | 2 +-
> > drivers/gpu/drm/arm/malidp_planes.c | 124
> > +++-
> > 6 files changed, 199 insertions(+), 32 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/arm/malidp_drv.c
> > b/drivers/gpu/drm/arm/malidp_drv.c
> > index b8db92f..2f0b553 100644
> > --- a/drivers/gpu/drm/arm/malidp_drv.c
> > +++ b/drivers/gpu/drm/arm/malidp_drv.c
> > @@ -264,29 +264,8 @@ static bool
> > malidp_verify_afbc_framebuffer_caps(struct drm_device *dev,
> > const struct drm_mode_fb_cmd2 *mode_cmd)
> > {
> > - const struct drm_format_info *info;
> > -
> > - if ((mode_cmd->modifier[0] >> 56) != DRM_FORMAT_MOD_VENDOR_ARM) {
> > - DRM_DEBUG_KMS("Unknown modifier (not Arm)\n");
> > + if (malidp_format_mod_supported(dev, mode_cmd->pixel_format,
> > mode_cmd->modifier[0]) == false)
> > return false;
> > - }
> > -
> > - if (mode_cmd->modifier[0] &
> > - ~DRM_FORMAT_MOD_ARM_AFBC(AFBC_MOD_VALID_BITS)) {
> > - DRM_DEBUG_KMS("Unsupported modifiers\n");
> > - return false;
> > - }
> > -
> > - info = drm_get_format_info(dev, mode_cmd);
> > - if (!info) {
> > - DRM_DEBUG_KMS("Unable to get the format information\n");
> > - return false;
> > - }
> > -
> > - if (info->num_planes != 1) {
> > - DRM_DEBUG_KMS("AFBC buffers expect one plane\n");
> > - return false;
> > - }
> >
> > if (mode_cmd->offsets[0] != 0) {
> > DRM_DEBUG_KMS("AFBC buffers' plane offset should be 0\n");
> > diff --git a/drivers/gpu/drm/arm/malidp_drv.h
> > b/drivers/gpu/drm/arm/malidp_drv.h
> > index b76c86f..019a682 100644
> > --- a/drivers/gpu/drm/arm/malidp_drv.h
> > +++ b/drivers/gpu/drm/arm/malidp_drv.h
> > @@ -90,6 +90,12 @@ struct malidp_crtc_state {
> > int malidp_de_planes_init(struct drm_device *drm);
> > int malidp_crtc_init(struct drm_device *drm);
> >
> > +bool malidp_hw_format_is_linear_only(u32 format);
> > +bool malidp_hw_format_is_afbc_only(u32 format);
> > +
> > +bool malidp_format_mod_supported(struct drm_device *drm,
> > +u32 format, u64 modifier);
> > +
> > #ifdef CONFIG_DEBUG_FS
> > void malidp_error(struct malidp_drm *malidp,
> > struct malidp_error_stats *error_stats, u32 status,
> > diff --git a/drivers/gpu/drm/arm/malidp_hw.c
> > b/drivers/gpu/drm/arm/malidp_hw.c
> > index 25ac5890..4a774be 100644
> > --- a/drivers/gpu/drm/arm/malidp_hw.c
> > +++ b/drivers/gpu/drm/arm/malidp_hw.c
> > @@ -60,6 +60,8 @@ static const struct malidp_format_id
> > malidp500_de_fo
Re: [RFC AFBC 06/12] drm/arm/malidp:- Added support for new YUV formats for DP500, DP550 and DP650
On Tue, Dec 04, 2018 at 04:57:46PM +, Liviu Dudau wrote:
Hi Liviu,
> On Mon, Dec 03, 2018 at 11:32:00AM +0000, Ayan Halder wrote:
> > We have added some new formats to be supported on DP500/DP550/DP650.
>
> Make a bit more descriptive commit message here, please!
>
I will keep the following commit message :-
""We have added support for some AFBC only pixel formats like :-
DRM_FORMAT_YUV420_8BIT (single plane YUV 420 8 bit format)
DRM_FORMAT_VUY888 (single plane YUV 444 8 bit format)
DRM_FORMAT_VUY101010 (single plane YUV 444 10 bit format)
DRM_FORMAT_YUV420_10BIT (single plane YUV 420 10 bit format)
Generally, these formats are supported by our hardware using the same hw-ids as
the equivalent multi plane pixel formats.
Also we have added support for XYUV 444 8 and 10 bit formats.""
Let me know if this looks fine.
Thanks,
Ayan Kumar halder
> >
> > Signed-off-by: Ayan Kumar Halder
> >
> > Depends on :- https://patchwork.kernel.org/patch/10460063/
>
> Reviewed-by: Liviu Dudau
>
> Best regards,
> Liviu
>
> > ---
> > drivers/gpu/drm/arm/malidp_hw.c | 22 +-
> > 1 file changed, 21 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/arm/malidp_hw.c
> > b/drivers/gpu/drm/arm/malidp_hw.c
> > index 55d379b..25ac5890 100644
> > --- a/drivers/gpu/drm/arm/malidp_hw.c
> > +++ b/drivers/gpu/drm/arm/malidp_hw.c
> > @@ -49,6 +49,12 @@ static const struct malidp_format_id
> > malidp500_de_formats[] = {
> > { DRM_FORMAT_YUYV, DE_VIDEO1, 13 },
> > { DRM_FORMAT_NV12, DE_VIDEO1 | SE_MEMWRITE, 14 },
> > { DRM_FORMAT_YUV420, DE_VIDEO1, 15 },
> > + { DRM_FORMAT_XYUV, DE_VIDEO1, 16 },
> > + /* These are supported with AFBC only */
> > + { DRM_FORMAT_YUV420_8BIT, DE_VIDEO1, 14 },
> > + { DRM_FORMAT_VUY888, DE_VIDEO1, 16 },
> > + { DRM_FORMAT_VUY101010, DE_VIDEO1, 17 },
> > + { DRM_FORMAT_YUV420_10BIT, DE_VIDEO1, 18 }
> > };
> >
> > #define MALIDP_ID(__group, __format) \
> > @@ -74,11 +80,25 @@ static const struct malidp_format_id
> > malidp500_de_formats[] = {
> > { DRM_FORMAT_ABGR1555, DE_VIDEO1 | DE_GRAPHICS1 | DE_VIDEO2,
> > MALIDP_ID(4, 1) }, \
> > { DRM_FORMAT_RGB565, DE_VIDEO1 | DE_GRAPHICS1 | DE_VIDEO2, MALIDP_ID(4,
> > 2) }, \
> > { DRM_FORMAT_BGR565, DE_VIDEO1 | DE_GRAPHICS1 | DE_VIDEO2, MALIDP_ID(4,
> > 3) }, \
> > + /* This is only supported with linear modifier */ \
> > + { DRM_FORMAT_XYUV, DE_VIDEO1 | DE_VIDEO2, MALIDP_ID(5, 0) },\
> > + /* This is only supported with AFBC modifier */ \
> > + { DRM_FORMAT_VUY888, DE_VIDEO1 | DE_VIDEO2, MALIDP_ID(5, 0) }, \
> > { DRM_FORMAT_YUYV, DE_VIDEO1 | DE_VIDEO2, MALIDP_ID(5, 2) },\
> > + /* This is only supported with linear modifier */ \
> > { DRM_FORMAT_UYVY, DE_VIDEO1 | DE_VIDEO2, MALIDP_ID(5, 3) },\
> > { DRM_FORMAT_NV12, DE_VIDEO1 | DE_VIDEO2 | SE_MEMWRITE, MALIDP_ID(5, 6)
> > }, \
> > + /* This is only supported with AFBC modifier */ \
> > + { DRM_FORMAT_YUV420_8BIT, DE_VIDEO1 | DE_VIDEO2, MALIDP_ID(5, 6) }, \
> > { DRM_FORMAT_YUV420, DE_VIDEO1 | DE_VIDEO2, MALIDP_ID(5, 7) }, \
> > - { DRM_FORMAT_X0L2, DE_VIDEO1 | DE_VIDEO2, MALIDP_ID(6, 6)}
> > + /* This is only supported with linear modifier */ \
> > + { DRM_FORMAT_XVYU2101010, DE_VIDEO1 | DE_VIDEO2, MALIDP_ID(6, 0)}, \
> > + /* This is only supported with AFBC modifier */ \
> > + { DRM_FORMAT_VUY101010, DE_VIDEO1 | DE_VIDEO2, MALIDP_ID(6, 0)}, \
> > + { DRM_FORMAT_X0L2, DE_VIDEO1 | DE_VIDEO2, MALIDP_ID(6, 6)}, \
> > + /* This is only supported with AFBC modifier */ \
> > + { DRM_FORMAT_YUV420_10BIT, DE_VIDEO1 | DE_VIDEO2, MALIDP_ID(6, 7)}, \
> > + { DRM_FORMAT_P010, DE_VIDEO1 | DE_VIDEO2, MALIDP_ID(6, 7)}
> >
> > static const struct malidp_format_id malidp550_de_formats[] = {
> > MALIDP_COMMON_FORMATS,
> > --
> > 2.7.4
> >
>
> --
>
> | 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
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC v3 AFBC 04/12] drm/arm/malidp: Set the AFBC register bits if the framebuffer has AFBC modifier
On Tue, Dec 04, 2018 at 04:50:51PM +, Liviu Dudau wrote:
Hi Liviu,
Please let me know if you agree with my comments. Then I will send a
v4 patch for this.
> On Mon, Dec 03, 2018 at 11:31:58AM +0000, Ayan Halder wrote:
> > Added the AFBC decoder registers for DP500 , DP550 and DP650.
> > These registers control the processing of AFBC buffers. It controls various
> > features like AFBC decoder enable, lossless transformation and block split
> > as well as setting of the left, right, top and bottom cropping of AFBC
> > buffers
> > (in number of pixels).
> > All the layers (except DE_SMART) support framebuffers with AFBC modifiers.
> > One needs to set the pixel values of the top, left, bottom and right
> > cropping
> > for the AFBC framebuffer.
> > Cropping an AFBC framebuffer is controlled by the AFBC crop registers.
> > In that case, the layer input size registers should be configured with
> > framebuffer's dimensions and not with drm_plane_state source width/height
> > values (which is used for non AFBC framebuffer to denote cropping).
> >
> > Changes from v1:
> > - Removed the "if (fb->modifier)" check from malidp_de_plane_update()
> > and added it in malidp_de_set_plane_afbc(). This will consolidate all the
> > AFBC specific register configurations in a single function ie
> > malidp_de_set_plane_afbc().
> >
> > Changes from v2:
> > - For AFBC framebuffer, layer input size register should be set to
> > framebuffer's
> > width and height
> >
> > Signed-off-by: Ayan Kumar Halder
> > ---
> > drivers/gpu/drm/arm/malidp_hw.c | 25 +
> > drivers/gpu/drm/arm/malidp_hw.h | 2 +
> > drivers/gpu/drm/arm/malidp_planes.c | 109
> > +++-
> > drivers/gpu/drm/arm/malidp_regs.h | 20 +++
> > 4 files changed, 130 insertions(+), 26 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/arm/malidp_hw.c
> > b/drivers/gpu/drm/arm/malidp_hw.c
> > index b9bed11..87b7b12 100644
> > --- a/drivers/gpu/drm/arm/malidp_hw.c
> > +++ b/drivers/gpu/drm/arm/malidp_hw.c
> > @@ -94,11 +94,12 @@ static const struct malidp_layer malidp500_layers[] = {
> > * yuv2rgb matrix offset, mmu control register offset,
> > rotation_features
> > */
> > { DE_VIDEO1, MALIDP500_DE_LV_BASE, MALIDP500_DE_LV_PTR_BASE,
> > - MALIDP_DE_LV_STRIDE0, MALIDP500_LV_YUV2RGB, 0, ROTATE_ANY },
> > + MALIDP_DE_LV_STRIDE0, MALIDP500_LV_YUV2RGB, 0, ROTATE_ANY,
> > + MALIDP500_DE_LV_AD_CTRL },
> > { DE_GRAPHICS1, MALIDP500_DE_LG1_BASE, MALIDP500_DE_LG1_PTR_BASE,
> > - MALIDP_DE_LG_STRIDE, 0, 0, ROTATE_ANY },
> > + MALIDP_DE_LG_STRIDE, 0, 0, ROTATE_ANY, MALIDP500_DE_LG1_AD_CTRL
> > },
> > { DE_GRAPHICS2, MALIDP500_DE_LG2_BASE, MALIDP500_DE_LG2_PTR_BASE,
> > - MALIDP_DE_LG_STRIDE, 0, 0, ROTATE_ANY },
> > + MALIDP_DE_LG_STRIDE, 0, 0, ROTATE_ANY, MALIDP500_DE_LG2_AD_CTRL
> > },
> > };
> >
> > static const struct malidp_layer malidp550_layers[] = {
> > @@ -106,13 +107,15 @@ static const struct malidp_layer malidp550_layers[] =
> > {
> > * yuv2rgb matrix offset, mmu control register offset,
> > rotation_features
> > */
> > { DE_VIDEO1, MALIDP550_DE_LV1_BASE, MALIDP550_DE_LV1_PTR_BASE,
> > - MALIDP_DE_LV_STRIDE0, MALIDP550_LV_YUV2RGB, 0, ROTATE_ANY },
> > + MALIDP_DE_LV_STRIDE0, MALIDP550_LV_YUV2RGB, 0, ROTATE_ANY,
> > + MALIDP550_DE_LV1_AD_CTRL },
> > { DE_GRAPHICS1, MALIDP550_DE_LG_BASE, MALIDP550_DE_LG_PTR_BASE,
> > - MALIDP_DE_LG_STRIDE, 0, 0, ROTATE_ANY },
> > + MALIDP_DE_LG_STRIDE, 0, 0, ROTATE_ANY, MALIDP550_DE_LG_AD_CTRL
> > },
> > { DE_VIDEO2, MALIDP550_DE_LV2_BASE, MALIDP550_DE_LV2_PTR_BASE,
> > - MALIDP_DE_LV_STRIDE0, MALIDP550_LV_YUV2RGB, 0, ROTATE_ANY },
> > + MALIDP_DE_LV_STRIDE0, MALIDP550_LV_YUV2RGB, 0, ROTATE_ANY,
> > + MALIDP550_DE_LV2_AD_CTRL },
> > { DE_SMART, MALIDP550_DE_LS_BASE, MALIDP550_DE_LS_PTR_BASE,
> > - MALIDP550_DE_LS_R1_STRIDE, 0, 0, ROTATE_NONE },
> > + MALIDP550_DE_LS_R1_STRIDE, 0, 0, ROTATE_NONE, 0 },
> > };
> >
> > static const struct malidp_layer malidp650_layers[] = {
> > @@ -122,16 +125,16 @@ static const struct malidp_layer malidp650_layers[] =
> > {
> > */
> > { DE_VIDEO1, MALIDP550_DE_LV1_BASE, MALIDP550_DE_LV1_PTR_BASE,
> > MALIDP_DE_LV_ST
[RFC AFBC 08/12] drm/arm/malidp: Specified the rotation memory requirements for AFBC YUV formats
The newly supported AFBC YUV formats have the following rotation memory
constraints (in DP550/DP650).
1. DRM_FORMAT_VUY888/DRM_FORMAT_VUY101010 :- It can rotate upto 8
horizontal lines in the AFBC output buffer.
2. DRM_FORMAT_YUV420_8BIT :- It can rotate upto 16 horizontal lines
in the AFBC output buffer.
Also some of the pixel formats are specified in bits per pixel (rather
than bytes per pixel), so the calculation needs to take note of this.
Besides there are some difference between DP550 and DP650 and these are
as follows:-
1. DRM_FORMAT_X0L2 (in uncompressed format) does not support rotation in DP550.
For DP650, it can rotate upto 16 horizontal lines in the AFBC output buffer,
whereas in DP550 (with AFBC), it can rotate upto 8 horizontal lines.
2. DRM_FORMAT_YUV420_10BIT :- It can rotate upto 8 horizontal lines in
dp550 and 16 horizontal lines in DP650.
Signed-off-by: Ayan Kumar halder
---
drivers/gpu/drm/arm/malidp_hw.c | 101
drivers/gpu/drm/arm/malidp_hw.h | 5 +-
drivers/gpu/drm/arm/malidp_planes.c | 3 +-
3 files changed, 98 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/arm/malidp_hw.c b/drivers/gpu/drm/arm/malidp_hw.c
index 4a774be..d9866a8 100644
--- a/drivers/gpu/drm/arm/malidp_hw.c
+++ b/drivers/gpu/drm/arm/malidp_hw.c
@@ -375,14 +375,39 @@ static void malidp500_modeset(struct malidp_hw_device
*hwdev, struct videomode *
malidp_hw_clearbits(hwdev, MALIDP_DISP_FUNC_ILACED,
MALIDP_DE_DISPLAY_FUNC);
}
-static int malidp500_rotmem_required(struct malidp_hw_device *hwdev, u16 w,
u16 h, u32 fmt)
+int malidp_format_get_bpp(u32 fmt)
+{
+ int bpp = drm_format_plane_cpp(fmt, 0) * 8;
+
+ if (bpp == 0) {
+ switch (fmt) {
+ case DRM_FORMAT_VUY101010:
+ bpp = 30;
+ case DRM_FORMAT_YUV420_10BIT:
+ bpp = 15;
+ break;
+ case DRM_FORMAT_YUV420_8BIT:
+ bpp = 12;
+ break;
+ default:
+ bpp = 0;
+ }
+ }
+
+ return bpp;
+}
+
+static int malidp500_rotmem_required(struct malidp_hw_device *hwdev, u16 w,
+u16 h, u32 fmt, bool has_modifier)
{
/*
* Each layer needs enough rotation memory to fit 8 lines
* worth of pixel data. Required size is then:
*size = rotated_width * (bpp / 8) * 8;
*/
- return w * drm_format_plane_cpp(fmt, 0) * 8;
+ int bpp = malidp_format_get_bpp(fmt);
+
+ return w * bpp;
}
static void malidp500_se_write_pp_coefftab(struct malidp_hw_device *hwdev,
@@ -660,9 +685,9 @@ static void malidp550_modeset(struct malidp_hw_device
*hwdev, struct videomode *
malidp_hw_clearbits(hwdev, MALIDP_DISP_FUNC_ILACED,
MALIDP_DE_DISPLAY_FUNC);
}
-static int malidp550_rotmem_required(struct malidp_hw_device *hwdev, u16 w,
u16 h, u32 fmt)
+static int malidpx50_get_bytes_per_column(u32 fmt)
{
- u32 bytes_per_col;
+ u32 bytes_per_column;
switch (fmt) {
/* 8 lines at 4 bytes per pixel */
@@ -688,19 +713,77 @@ static int malidp550_rotmem_required(struct
malidp_hw_device *hwdev, u16 w, u16
case DRM_FORMAT_UYVY:
case DRM_FORMAT_YUYV:
case DRM_FORMAT_X0L0:
- case DRM_FORMAT_X0L2:
- bytes_per_col = 32;
+ bytes_per_column = 32;
break;
/* 16 lines at 1.5 bytes per pixel */
case DRM_FORMAT_NV12:
case DRM_FORMAT_YUV420:
- bytes_per_col = 24;
+ /* 8 lines at 3 bytes per pixel */
+ case DRM_FORMAT_VUY888:
+ /* 16 lines at 12 bits per pixel */
+ case DRM_FORMAT_YUV420_8BIT:
+ /* 8 lines at 3 bytes per pixel */
+ case DRM_FORMAT_P010:
+ bytes_per_column = 24;
+ break;
+ /* 8 lines at 30 bits per pixel */
+ case DRM_FORMAT_VUY101010:
+ /* 16 lines at 15 bits per pixel */
+ case DRM_FORMAT_YUV420_10BIT:
+ bytes_per_column = 30;
break;
default:
return -EINVAL;
}
- return w * bytes_per_col;
+ return bytes_per_column;
+}
+
+static int malidp550_rotmem_required(struct malidp_hw_device *hwdev, u16 w,
+u16 h, u32 fmt, bool has_modifier)
+{
+ int bytes_per_column = 0;
+
+ switch (fmt) {
+ /* 8 lines at 15 bits per pixel */
+ case DRM_FORMAT_YUV420_10BIT:
+ bytes_per_column = 15;
+ break;
+ /* Uncompressed YUV 420 10 bit single plane cannot be rotated */
+ case DRM_FORMAT_X0L2:
+ if (has_modifier)
+ bytes_per_column = 8;
+ else
+ return -EINVAL;
+ break;
+ default:
+ bytes_per_column =
[RFC AFBC 10/12] drm/arm/malidp:- Use the newly introduced malidp_format_get_bpp() instead of relying on cpp for calculating framebuffer size
Formats like DRM_FORMAT_VUY101010, DRM_FORMAT_YUV420_8BIT and
DRM_FORMAT_YUV420_10BIT are expressed in bits per pixel as they have a non
integer value of cpp (thus denoted as '0' in drm_format_info[]). Therefore,
the calculation of AFBC framebuffer size needs to use malidp_format_get_bpp().
Signed-off-by: Ayan Kumar halder
---
drivers/gpu/drm/arm/malidp_drv.c | 13 -
1 file changed, 8 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/arm/malidp_drv.c b/drivers/gpu/drm/arm/malidp_drv.c
index 2f0b553..b2b97db 100644
--- a/drivers/gpu/drm/arm/malidp_drv.c
+++ b/drivers/gpu/drm/arm/malidp_drv.c
@@ -297,6 +297,7 @@ malidp_verify_afbc_framebuffer_size(struct drm_device *dev,
struct drm_gem_object *objs = NULL;
u32 afbc_superblock_size = 0, afbc_superblock_height = 0;
u32 afbc_superblock_width = 0, afbc_size = 0;
+ int bpp = 0;
switch (mode_cmd->modifier[0] & AFBC_SIZE_MASK) {
case AFBC_SIZE_16X16:
@@ -313,15 +314,17 @@ malidp_verify_afbc_framebuffer_size(struct drm_device
*dev,
n_superblocks = (mode_cmd->width / afbc_superblock_width) *
(mode_cmd->height / afbc_superblock_height);
- afbc_superblock_size = info->cpp[0] * afbc_superblock_width *
- afbc_superblock_height;
+ bpp = malidp_format_get_bpp(info->format);
+
+ afbc_superblock_size = (bpp * afbc_superblock_width *
afbc_superblock_height) / BITS_PER_BYTE;
afbc_size = ALIGN(n_superblocks * AFBC_HEADER_SIZE,
AFBC_SUPERBLK_ALIGNMENT);
afbc_size += n_superblocks * ALIGN(afbc_superblock_size,
AFBC_SUPERBLK_ALIGNMENT);
- if (mode_cmd->width * info->cpp[0] != mode_cmd->pitches[0]) {
- DRM_DEBUG_KMS("Invalid value of pitch (=%u) should be same as
width (=%u) * cpp (=%u)\n",
- mode_cmd->pitches[0], mode_cmd->width,
info->cpp[0]);
+ if ((mode_cmd->width * bpp) != (mode_cmd->pitches[0] * BITS_PER_BYTE)) {
+ DRM_DEBUG_KMS("Invalid value of (pitch * BITS_PER_BYTE) (=%u) "
+ "should be same as width (=%u) * bpp (=%u)\n",
+ (mode_cmd->pitches[0] * BITS_PER_BYTE),
mode_cmd->width, bpp);
return false;
}
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[RFC AFBC 09/12] drm/arm/malidp:- Writeback framebuffer does not support any modifiers
In malidp, the writeback pipeline does not support writing crtc output
to a framebuffer with modifiers ie the memory writeback content is
devoid of any compression or tiling, etc.
So we have added a commit check in memory writeback encoder helper function
to validate if the framebuffer has any modifier and if so, return EINVAL.
Signed-off-by: Ayan Kumar halder
---
drivers/gpu/drm/arm/malidp_mw.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/gpu/drm/arm/malidp_mw.c b/drivers/gpu/drm/arm/malidp_mw.c
index 0484744..90c964a 100644
--- a/drivers/gpu/drm/arm/malidp_mw.c
+++ b/drivers/gpu/drm/arm/malidp_mw.c
@@ -141,6 +141,11 @@ malidp_mw_encoder_atomic_check(struct drm_encoder *encoder,
return -EINVAL;
}
+ if (fb->modifier) {
+ DRM_DEBUG_KMS("Writeback framebuffer does not support
modifiers\n");
+ return -EINVAL;
+ }
+
mw_state->format =
malidp_hw_get_format_id(>dev->hw->map, SE_MEMWRITE,
fb->format->format, !!fb->modifier);
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[RFC AFBC 11/12] drm/arm/malidp:- Disregard the pitch alignment constraint for AFBC framebuffer.
Considering the fact that some of the AFBC specific pixel formats are expressed
in bits per pixel (ie bpp which is not byte aligned), the pitch (ie width * bpp)
is not guaranteed to be aligned to burst size (ie 8 or 16 bytes).
For example, DRM_FORMAT_VUY101010 is 30 bits per pixel. For a framebuffer of
width 32 pixels, the pitch will be 120 bytes which is not aligned to burst size
(ie 16 bytes) for DP650.
Signed-off-by: Ayan Kumar halder
---
drivers/gpu/drm/arm/malidp_planes.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/arm/malidp_planes.c
b/drivers/gpu/drm/arm/malidp_planes.c
index d0a00ee..eec0442 100644
--- a/drivers/gpu/drm/arm/malidp_planes.c
+++ b/drivers/gpu/drm/arm/malidp_planes.c
@@ -529,8 +529,8 @@ static int malidp_de_plane_check(struct drm_plane *plane,
for (i = 0; i < ms->n_planes; i++) {
u8 alignment = malidp_hw_get_pitch_align(mp->hwdev, rotated);
- if ((fb->pitches[i] * drm_format_info_block_height(fb->format,
i))
- & (alignment - 1)) {
+ if (((fb->pitches[i] * drm_format_info_block_height(fb->format,
i))
+ & (alignment - 1)) && !(fb->modifier)) {
DRM_DEBUG_KMS("Invalid pitch %u for plane %d\n",
fb->pitches[i], i);
return -EINVAL;
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[RFC AFBC 07/12] drm/arm/malidp: Define the constraints on each supported drm_fourcc format for the AFBC modifiers.
The constraints are as follows (for Mali-DP 500, 550, 650) :-
1. AFBC is not supported for the formats defined in
malidp_hw_format_is_linear_only()
2. Some of the formats are supported only with AFBC modifiers. Thus we have
introduced a new function 'malidp_hw_format_is_afbc_only()' which verifies the
same.
3. AFBC_FORMAT_MOD_YTR needs to be provided for any RGB format.
4. Formats <= 16bpp cannot support AFBC_FORMAT_MOD_SPLIT.
5. CBR should not be set for non-subsampled formats.
6. SMART layer does not support framebuffer with AFBC modifiers.
Return -EINVAL for such a scenario.
7. AFBC_FORMAT_MOD_YTR is not supported for any YUV formats.
8. Formats which are subsampled cannot support AFBC_FORMAT_MOD_SPLIT. However in
DP550, YUV_420_10BIT is supported with AFBC_FORMAT_MOD_SPLIT. This feature has
been identified with MALIDP_DEVICE_AFBC_YUV_420_10_SUPPORT_SPLIT.
9. In DP550 and DP650, for YUYV, the hardware supports different format-ids to
be used with and without AFBC modifier. We have used the feature
'MALIDP_DEVICE_AFBC_YUYV_USE_422_P2' to identify this characteristic.
Signed-off-by: Ayan Kumar halder
---
drivers/gpu/drm/arm/malidp_drv.c| 23 +--
drivers/gpu/drm/arm/malidp_drv.h| 6 ++
drivers/gpu/drm/arm/malidp_hw.c | 71 +++--
drivers/gpu/drm/arm/malidp_hw.h | 5 +-
drivers/gpu/drm/arm/malidp_mw.c | 2 +-
drivers/gpu/drm/arm/malidp_planes.c | 124 +++-
6 files changed, 199 insertions(+), 32 deletions(-)
diff --git a/drivers/gpu/drm/arm/malidp_drv.c b/drivers/gpu/drm/arm/malidp_drv.c
index b8db92f..2f0b553 100644
--- a/drivers/gpu/drm/arm/malidp_drv.c
+++ b/drivers/gpu/drm/arm/malidp_drv.c
@@ -264,29 +264,8 @@ static bool
malidp_verify_afbc_framebuffer_caps(struct drm_device *dev,
const struct drm_mode_fb_cmd2 *mode_cmd)
{
- const struct drm_format_info *info;
-
- if ((mode_cmd->modifier[0] >> 56) != DRM_FORMAT_MOD_VENDOR_ARM) {
- DRM_DEBUG_KMS("Unknown modifier (not Arm)\n");
+ if (malidp_format_mod_supported(dev, mode_cmd->pixel_format,
mode_cmd->modifier[0]) == false)
return false;
- }
-
- if (mode_cmd->modifier[0] &
- ~DRM_FORMAT_MOD_ARM_AFBC(AFBC_MOD_VALID_BITS)) {
- DRM_DEBUG_KMS("Unsupported modifiers\n");
- return false;
- }
-
- info = drm_get_format_info(dev, mode_cmd);
- if (!info) {
- DRM_DEBUG_KMS("Unable to get the format information\n");
- return false;
- }
-
- if (info->num_planes != 1) {
- DRM_DEBUG_KMS("AFBC buffers expect one plane\n");
- return false;
- }
if (mode_cmd->offsets[0] != 0) {
DRM_DEBUG_KMS("AFBC buffers' plane offset should be 0\n");
diff --git a/drivers/gpu/drm/arm/malidp_drv.h b/drivers/gpu/drm/arm/malidp_drv.h
index b76c86f..019a682 100644
--- a/drivers/gpu/drm/arm/malidp_drv.h
+++ b/drivers/gpu/drm/arm/malidp_drv.h
@@ -90,6 +90,12 @@ struct malidp_crtc_state {
int malidp_de_planes_init(struct drm_device *drm);
int malidp_crtc_init(struct drm_device *drm);
+bool malidp_hw_format_is_linear_only(u32 format);
+bool malidp_hw_format_is_afbc_only(u32 format);
+
+bool malidp_format_mod_supported(struct drm_device *drm,
+u32 format, u64 modifier);
+
#ifdef CONFIG_DEBUG_FS
void malidp_error(struct malidp_drm *malidp,
struct malidp_error_stats *error_stats, u32 status,
diff --git a/drivers/gpu/drm/arm/malidp_hw.c b/drivers/gpu/drm/arm/malidp_hw.c
index 25ac5890..4a774be 100644
--- a/drivers/gpu/drm/arm/malidp_hw.c
+++ b/drivers/gpu/drm/arm/malidp_hw.c
@@ -60,6 +60,8 @@ static const struct malidp_format_id malidp500_de_formats[] =
{
#define MALIDP_ID(__group, __format) \
__group) & 0x7) << 3) | ((__format) & 0x7))
+#define AFBC_YUV_422_FORMAT_ID MALIDP_ID(5, 1)
+
#define MALIDP_COMMON_FORMATS \
/*fourcc, layers supporting the format, internal id */ \
{ DRM_FORMAT_ARGB2101010, DE_VIDEO1 | DE_GRAPHICS1 | DE_VIDEO2 |
SE_MEMWRITE, MALIDP_ID(0, 0) }, \
@@ -887,7 +889,10 @@ const struct malidp_hw malidp_device[MALIDP_MAX_DEVICES] =
{
.se_base = MALIDP550_SE_BASE,
.dc_base = MALIDP550_DC_BASE,
.out_depth_base = MALIDP550_DE_OUTPUT_DEPTH,
- .features = MALIDP_REGMAP_HAS_CLEARIRQ |
MALIDP_DEVICE_AFBC_SUPPORT_SPLIT | AFBC_SUPPORT_SPLIT_WITH_YUV_420_10,
+ .features = MALIDP_REGMAP_HAS_CLEARIRQ |
+ MALIDP_DEVICE_AFBC_SUPPORT_SPLIT |
+ MALIDP_DEVICE_AFBC_YUV_420_10_SUPPORT_SPLIT
|
+ MALIDP_DEVICE_AFBC_YUYV_USE_422_P2,
.n_layers = ARRAY_SIZE(malidp550_layers),
.layers =
[RFC AFBC 03/12] drm/afbc: Add AFBC modifier usage documentation
From: Brian Starkey AFBC is a flexible, proprietary, lossless compression protocol and format, with a number of defined DRM format modifiers. To facilitate consistency and compatibility between different AFBC producers and consumers, document the expectations for usage of the AFBC DRM format modifiers in a new .rst chapter. Signed-off-by: Brian Starkey Reviewed-by: Liviu Dudau --- Documentation/gpu/afbc.rst| 233 ++ Documentation/gpu/drivers.rst | 1 + MAINTAINERS | 1 + include/uapi/drm/drm_fourcc.h | 3 + 4 files changed, 238 insertions(+) create mode 100644 Documentation/gpu/afbc.rst diff --git a/Documentation/gpu/afbc.rst b/Documentation/gpu/afbc.rst new file mode 100644 index 000..922d955 --- /dev/null +++ b/Documentation/gpu/afbc.rst @@ -0,0 +1,233 @@ +=== + Arm Framebuffer Compression (AFBC) +=== + +AFBC is a proprietary lossless image compression protocol and format. +It provides fine-grained random access and minimizes the amount of +data transferred between IP blocks. + +AFBC can be enabled on drivers which support it via use of the AFBC +format modifiers defined in drm_fourcc.h. See DRM_FORMAT_MOD_ARM_AFBC(*). + +All users of the AFBC modifiers must follow the usage guidelines laid +out in this document, to ensure compatibility across different AFBC +producers and consumers. + +Components and Ordering +=== + +AFBC streams can contain several components - where a component +corresponds to a color channel (i.e. R, G, B, X, A, Y, Cb, Cr). +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. + +Furthermore, when the lossless colorspace transform is used +(AFBC_FORMAT_MOD_YTR, which should be enabled for RGB buffers for +maximum compression efficiency), the component order must be: + + * Component 0: R + * Component 1: G + * Component 2: B + +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): + + * DRM_FORMAT_ABGR + + * Component 0: R(8) + * Component 1: G(8) + * Component 2: B(8) + * Component 3: A(8) + + * DRM_FORMAT_BGR888 + + * Component 0: R(8) + * Component 1: G(8) + * Component 2: B(8) + + * DRM_FORMAT_YUYV + + * Component 0: Y(8) + * Component 1: Cb(8, 2x1 subsampled) + * Component 2: Cr(8, 2x1 subsampled) + +In AFBC, 'X' components are not treated any differently from any other +component. Therefore, an AFBC buffer with fourcc DRM_FORMAT_XBGR +encodes with 4 components, like so: + + * DRM_FORMAT_XBGR + + * Component 0: R(8) + * Component 1: G(8) + * Component 2: B(8) + * Component 3: X(8) + +Please note, however, that the inclusion of a "wasted" 'X' channel is +bad for compression efficiency, and so it's recommended to avoid +formats containing 'X' bits. If a fourth component is +required/expected by the encoder/decoder, then it is recommended to +instead use an equivalent format with alpha, setting all alpha bits to +'1'. If there is no requirement for a fourth component, then a format +which doesn't include alpha can be used, e.g. DRM_FORMAT_BGR888. + +Number of Planes + + +Formats which are typically multi-planar in linear layouts (e.g. YUV +420), can be encoded into one, or multiple, AFBC planes. As with +component order, the encoder and decoder must agree about the number +of planes in order to correctly decode the buffer. The fourcc code is +used to determine the number of encoded planes in an AFBC buffer, +matching the number of planes for the linear (unmodified) format. +Within each plane, the component ordering also follows the fourcc +code: + +For example: + + * DRM_FORMAT_YUYV: nplanes = 1 + + * Plane 0: + + * Component 0: Y(8) + * Component 1: Cb(8, 2x1 subsampled) + * Component 2: Cr(8, 2x1 subsampled) + + * DRM_FORMAT_NV12: nplanes = 2 + + * Plane 0: + + * Component 0: Y(8) + + * Plane 1: + + * Component 0: Cb(8, 2x1 subsampled) + * Component 1: Cr(8, 2x1 subsampled) + +Cross-device interoperability += + +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. + +.. flat-table:: AFBC formats + + * - Fourcc code + - Description + - Planes/Components + + * - DRM_FORMAT_ABGR2101010 + - 10-bit per component RGB, with 2-bit alpha + - Plane 0: 4 components + * Component 0: R(10) + * Component 1: G(10) + * Component 2: B(10) +
[RFC AFBC 06/12] drm/arm/malidp:- Added support for new YUV formats for DP500, DP550 and DP650
We have added some new formats to be supported on DP500/DP550/DP650.
Signed-off-by: Ayan Kumar Halder
Depends on :- https://patchwork.kernel.org/patch/10460063/
---
drivers/gpu/drm/arm/malidp_hw.c | 22 +-
1 file changed, 21 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/arm/malidp_hw.c b/drivers/gpu/drm/arm/malidp_hw.c
index 55d379b..25ac5890 100644
--- a/drivers/gpu/drm/arm/malidp_hw.c
+++ b/drivers/gpu/drm/arm/malidp_hw.c
@@ -49,6 +49,12 @@ static const struct malidp_format_id malidp500_de_formats[]
= {
{ DRM_FORMAT_YUYV, DE_VIDEO1, 13 },
{ DRM_FORMAT_NV12, DE_VIDEO1 | SE_MEMWRITE, 14 },
{ DRM_FORMAT_YUV420, DE_VIDEO1, 15 },
+ { DRM_FORMAT_XYUV, DE_VIDEO1, 16 },
+ /* These are supported with AFBC only */
+ { DRM_FORMAT_YUV420_8BIT, DE_VIDEO1, 14 },
+ { DRM_FORMAT_VUY888, DE_VIDEO1, 16 },
+ { DRM_FORMAT_VUY101010, DE_VIDEO1, 17 },
+ { DRM_FORMAT_YUV420_10BIT, DE_VIDEO1, 18 }
};
#define MALIDP_ID(__group, __format) \
@@ -74,11 +80,25 @@ static const struct malidp_format_id malidp500_de_formats[]
= {
{ DRM_FORMAT_ABGR1555, DE_VIDEO1 | DE_GRAPHICS1 | DE_VIDEO2,
MALIDP_ID(4, 1) }, \
{ DRM_FORMAT_RGB565, DE_VIDEO1 | DE_GRAPHICS1 | DE_VIDEO2, MALIDP_ID(4,
2) }, \
{ DRM_FORMAT_BGR565, DE_VIDEO1 | DE_GRAPHICS1 | DE_VIDEO2, MALIDP_ID(4,
3) }, \
+ /* This is only supported with linear modifier */ \
+ { DRM_FORMAT_XYUV, DE_VIDEO1 | DE_VIDEO2, MALIDP_ID(5, 0) },\
+ /* This is only supported with AFBC modifier */ \
+ { DRM_FORMAT_VUY888, DE_VIDEO1 | DE_VIDEO2, MALIDP_ID(5, 0) }, \
{ DRM_FORMAT_YUYV, DE_VIDEO1 | DE_VIDEO2, MALIDP_ID(5, 2) },\
+ /* This is only supported with linear modifier */ \
{ DRM_FORMAT_UYVY, DE_VIDEO1 | DE_VIDEO2, MALIDP_ID(5, 3) },\
{ DRM_FORMAT_NV12, DE_VIDEO1 | DE_VIDEO2 | SE_MEMWRITE, MALIDP_ID(5, 6)
}, \
+ /* This is only supported with AFBC modifier */ \
+ { DRM_FORMAT_YUV420_8BIT, DE_VIDEO1 | DE_VIDEO2, MALIDP_ID(5, 6) }, \
{ DRM_FORMAT_YUV420, DE_VIDEO1 | DE_VIDEO2, MALIDP_ID(5, 7) }, \
- { DRM_FORMAT_X0L2, DE_VIDEO1 | DE_VIDEO2, MALIDP_ID(6, 6)}
+ /* This is only supported with linear modifier */ \
+ { DRM_FORMAT_XVYU2101010, DE_VIDEO1 | DE_VIDEO2, MALIDP_ID(6, 0)}, \
+ /* This is only supported with AFBC modifier */ \
+ { DRM_FORMAT_VUY101010, DE_VIDEO1 | DE_VIDEO2, MALIDP_ID(6, 0)}, \
+ { DRM_FORMAT_X0L2, DE_VIDEO1 | DE_VIDEO2, MALIDP_ID(6, 6)}, \
+ /* This is only supported with AFBC modifier */ \
+ { DRM_FORMAT_YUV420_10BIT, DE_VIDEO1 | DE_VIDEO2, MALIDP_ID(6, 7)}, \
+ { DRM_FORMAT_P010, DE_VIDEO1 | DE_VIDEO2, MALIDP_ID(6, 7)}
static const struct malidp_format_id malidp550_de_formats[] = {
MALIDP_COMMON_FORMATS,
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[RFC v3 AFBC 12/12] drm/arm/malidp: Added support for AFBC modifiers for all layers except DE_SMART
The list of modifiers to be supported for each plane has been dynamically
generated
from 'malidp_format_modifiers[]' and 'malidp_hw_regmap->features'.
Changes from v1:-
1. Replaced DRM_ERROR() with DRM_DEBUG_KMS() in malidp_format_mod_supported()
to report unsupported modifiers.
Changes from v2:-
1. Removed malidp_format_mod_supported() from the current patch. This has been
added
in "PATCH 7/12"
2. Dynamically generate the list of modifiers (to be supported for each plane)
from
'malidp_format_modifiers' and features.
Signed-off-by: Ayan Kumar halder
---
drivers/gpu/drm/arm/malidp_drv.c| 1 +
drivers/gpu/drm/arm/malidp_planes.c | 28 ++--
2 files changed, 27 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/arm/malidp_drv.c b/drivers/gpu/drm/arm/malidp_drv.c
index b2b97db..be45703 100644
--- a/drivers/gpu/drm/arm/malidp_drv.c
+++ b/drivers/gpu/drm/arm/malidp_drv.c
@@ -388,6 +388,7 @@ static int malidp_init(struct drm_device *drm)
drm->mode_config.max_height = hwdev->max_line_size;
drm->mode_config.funcs = _mode_config_funcs;
drm->mode_config.helper_private = _mode_config_helpers;
+ drm->mode_config.allow_fb_modifiers = true;
ret = malidp_crtc_init(drm);
if (ret)
diff --git a/drivers/gpu/drm/arm/malidp_planes.c
b/drivers/gpu/drm/arm/malidp_planes.c
index eec0442..01037d0 100644
--- a/drivers/gpu/drm/arm/malidp_planes.c
+++ b/drivers/gpu/drm/arm/malidp_planes.c
@@ -934,6 +934,25 @@ int malidp_de_planes_init(struct drm_device *drm)
BIT(DRM_MODE_BLEND_COVERAGE);
u32 *formats;
int ret, i, j, n;
+ u64 supported_modifiers[MODIFIERS_COUNT_MAX];
+ const u64 *modifiers;
+
+ modifiers = malidp_format_modifiers;
+
+ if (!(map->features & MALIDP_DEVICE_AFBC_SUPPORT_SPLIT)) {
+ /*
+* Since our hardware does not support SPLIT, so build the list
of
+* supported modifiers excluding SPLIT ones.
+*/
+ while (*modifiers != DRM_FORMAT_MOD_INVALID) {
+ if (!(*modifiers & AFBC_SPLIT))
+ supported_modifiers[j++] = *modifiers;
+
+ modifiers++;
+ }
+ supported_modifiers[j++] = DRM_FORMAT_MOD_INVALID;
+ modifiers = supported_modifiers;
+ }
formats = kcalloc(map->n_pixel_formats, sizeof(*formats), GFP_KERNEL);
if (!formats) {
@@ -958,9 +977,14 @@ int malidp_de_planes_init(struct drm_device *drm)
plane_type = (i == 0) ? DRM_PLANE_TYPE_PRIMARY :
DRM_PLANE_TYPE_OVERLAY;
+
+ /*
+* All the layers except smart layer supports AFBC modifiers.
+*/
ret = drm_universal_plane_init(drm, >base, crtcs,
- _de_plane_funcs, formats,
- n, NULL, plane_type, NULL);
+ _de_plane_funcs, formats, n,
+ (id == DE_SMART) ? NULL : modifiers,
plane_type, NULL);
+
if (ret < 0)
goto cleanup;
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[RFC AFBC 01/12] drm/fourcc: Add AFBC yuv fourccs for Mali
From: Brian Starkey As we look to enable AFBC using DRM format modifiers, we run into problems which we've historically handled via vendor-private details (i.e. gralloc, on Android). AFBC (as an encoding) is fully flexible, and for example YUV data can be encoded into 1, 2 or 3 encoded "planes", much like the linear equivalents. Component order is also meaningful, as AFBC doesn't necessarily care about what each "channel" of the data it encodes contains. Therefore ABGR and RGBA can be encoded in AFBC with different representations. Similarly, 'X' components may be encoded into AFBC streams in cases where a decoder expects to decode a 4th component. In addition, AFBC is a licensable IP, meaning that to support the ecosystem we need to ensure that _all_ AFBC users are able to describe the encodings that they need. This is much better achieved by preserving meaning in the fourcc codes when they are combined with an AFBC modifier. In essence, we want to use the modifier to describe the parameters of the AFBC encode/decode, and use the fourcc code to describe the data being encoded/decoded. To do anything different would be to introduce redundancy - we would need to duplicate in the modifier information which is _already_ conveyed clearly and non-ambigiously by a fourcc code. I hope that for RGB this is non-controversial. (BGRA + MODIFIER_AFBC) is a different format from (RGBA + MODIFIER_AFBC). Possibly more controversial is that (XBGR + MODIFIER_AFBC) is different from (BGR888 + MODIFIER_AFBC). I understand that in some schemes it is not the case - but in AFBC it is so. Where we run into problems is where there are not already fourcc codes which represent the data which the AFBC encoder/decoder is processing. To that end, we want to introduce new fourcc codes to describe the data being encoded/decoded, in the places where none of the existing fourcc codes are applicable. Where we don't support an equivalent non-compressed layout, or where no "obvious" linear layout exists, we are proposing adding fourcc codes which have no associated linear layout - because any layout we proposed would be completely arbitrary. Some formats are following the naming conventions from [2]. The summary of the new formats is: DRM_FORMAT_VUY888 - Packed 8-bit YUV 444. Y followed by U then V. DRM_FORMAT_VUY101010 - Packed 10-bit YUV 444. Y followed by U then V. No defined linear encoding. DRM_FORMAT_Y210 - Packed 10-bit YUV 422. Y followed by U (then Y) then V. 10-bit samples in 16-bit words. DRM_FORMAT_Y410 - Packed 10-bit YUV 444, with 2-bit alpha. DRM_FORMAT_P210 - Semi-planar 10-bit YUV 422. Y plane, followed by interleaved U-then-V plane. 10-bit samples in 16-bit words. DRM_FORMAT_YUV420_8BIT - Packed 8-bit YUV 420. Y followed by U then V. No defined linear encoding DRM_FORMAT_YUV420_10BIT - Packed 10-bit YUV 420. Y followed by U then V. No defined linear encoding Please also note that in the absence of AFBC, we would still need to add Y410, Y210 and P210. Full rationale follows: YUV 444 8-bit, 1-plane -- The currently defined AYUV format encodes a 4th alpha component, which makes it unsuitable for representing a 3-component YUV 444 AFBC stream. The proposed[1] XYUV format which is supported by Mali-DP in linear layout is also unsuitable, because the component order is the opposite of the AFBC version, and it encodes a 4th 'X' component. DRM_FORMAT_VUY888 is the "obvious" format for a 3-component, packed, YUV 444 8-bit format, with the component order which our HW expects to encode/decode. It conforms to the same naming convention as the existing packed YUV 444 format. The naming here is meant to be consistent with DRM_FORMAT_AYUV and DRM_FORMAT_XYUV[1] YUV 444 10-bit, 1-plane --- There is no currently-defined YUV 444 10-bit format in drm_fourcc.h, irrespective of number of planes. The proposed[1] XVYU2101010 format which is supported by Mali-DP in linear layout uses the wrong component order, and also encodes a 4th 'X' component, which doesn't match the AFBC version of YUV 444 10-bit which we support. DRM_FORMAT_Y410 is the same layout as XVYU2101010, but with 2 bits of alpha. This format is supported with linear layout by Mali GPUs. The naming follows[2]. There is no "obvious" linear encoding for a 3-component 10:10:10 packed format, and so DRM_FORMAT_VUY101010 defines a component order, but not a bit encoding. Again, the naming is meant to be consistent with DRM_FORMAT_AYUV. YUV 422 8-bit, 1-plane -- The existing DRM_FORMAT_YUYV (and the other component orders) are single-planar YUV 422 8-bit formats. Following the convention of the component orders of the RGB formats, YUYV has the correct component order for our AFBC encoding (Y followed by U followed by
[RFC AFBC 02/12] drm: Added a new format DRM_FORMAT_XVYU2101010
We have added a new format ie DRM_FORMAT_XVYU2101010 which is supported
by mali display driver.
Signed-off-by: Ayan Kumar halder
---
drivers/gpu/drm/drm_fourcc.c | 1 +
include/uapi/drm/drm_fourcc.h | 1 +
2 files changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/drm_fourcc.c b/drivers/gpu/drm/drm_fourcc.c
index 6b7a62e..d31e1ae 100644
--- a/drivers/gpu/drm/drm_fourcc.c
+++ b/drivers/gpu/drm/drm_fourcc.c
@@ -229,6 +229,7 @@ const struct drm_format_info *__drm_format_info(u32 format)
{ .format = DRM_FORMAT_VUY888, .depth = 0,
.num_planes = 1, .cpp = { 3, 0, 0 }, .hsub = 1, .vsub = 1, .is_yuv = true },
{ .format = DRM_FORMAT_Y410,.depth = 0,
.num_planes = 1, .cpp = { 4, 0, 0 }, .hsub = 1, .vsub = 1, .has_alpha = true,
.is_yuv = true },
{ .format = DRM_FORMAT_AYUV,.depth = 0,
.num_planes = 1, .cpp = { 4, 0, 0 }, .hsub = 1, .vsub = 1, .has_alpha = true,
.is_yuv = true },
+ { .format = DRM_FORMAT_XVYU2101010, .depth = 0,
.num_planes = 1, .cpp = { 4, 0, 0 }, .hsub = 1, .vsub = 1, .is_yuv = true },
{ .format = DRM_FORMAT_P010,.depth = 0,
.num_planes = 2, .cpp = { 2, 4, 0 }, .hsub = 2, .vsub = 2, .is_yuv = true },
{ .format = DRM_FORMAT_P012,.depth = 0,
.num_planes = 2, .cpp = { 2, 4, 0 }, .hsub = 2, .vsub = 2, .is_yuv = true },
{ .format = DRM_FORMAT_P016,.depth = 0,
.num_planes = 2, .cpp = { 2, 4, 0 }, .hsub = 2, .vsub = 2, .is_yuv = true },
diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
index 71b2bc7..75c4b5a 100644
--- a/include/uapi/drm/drm_fourcc.h
+++ b/include/uapi/drm/drm_fourcc.h
@@ -153,6 +153,7 @@ extern "C" {
#define DRM_FORMAT_AYUVfourcc_code('A', 'Y', 'U', 'V') /*
[31:0] A:Y:Cb:Cr 8:8:8:8 little endian */
#define DRM_FORMAT_XYUVfourcc_code('X', 'Y', 'U', 'V') /* [31:0]
X:Y:Cb:Cr 8:8:8:8 little endian */
+#define DRM_FORMAT_XVYU2101010 fourcc_code('X', 'V', '3', '0') /* [31:0]
X:Cr:Y:Cb 2:10:10:10 little endian */
#define DRM_FORMAT_VUY888 fourcc_code('V', 'U', '2', '4') /* [23:0]
Cr:Cb:Y 8:8:8 little endian */
#define DRM_FORMAT_Y410fourcc_code('Y', '4', '1', '0') /*
[31:0] A:Cr:Y:Cb 2:10:10:10 little endian */
#define DRM_FORMAT_VUY101010 fourcc_code('V', 'U', '3', '0') /* Y followed
by U then V, 10:10:10. Non-linear modifier only */
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[RFC AFBC 05/12] drm/arm/malidp:- Define a common list of AFBC format modifiers supported for DP500, DP550 and DP650
We need to define a common list of format modifiers supported by each of the
Mali
display processors. The difference between DP500 from DP550/650 is that DP500
does not support block split mode (ie AFBC_FORMAT_MOD_SPLIT) and DP550 supports
YUV420 with split mode. We noted these special cases by defining
MALIDP_DEVICE_AFBC_SUPPORT_SPLIT
and AFBC_SUPPORT_SPLIT_WITH_YUV_420_10 for malidp_hw_regmap.features
Also we have defined a set of meaningful macros to shorten the modifier names
Signed-off-by: Ayan Kumar halder
Change-Id: I09fba2032a7474e6ce45af230e0ed18fc1f4c1df
---
drivers/gpu/drm/arm/malidp_drv.c | 8
drivers/gpu/drm/arm/malidp_hw.c | 30 --
drivers/gpu/drm/arm/malidp_hw.h | 20 +++-
3 files changed, 47 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/arm/malidp_drv.c b/drivers/gpu/drm/arm/malidp_drv.c
index 505f316..b8db92f 100644
--- a/drivers/gpu/drm/arm/malidp_drv.c
+++ b/drivers/gpu/drm/arm/malidp_drv.c
@@ -293,8 +293,8 @@ malidp_verify_afbc_framebuffer_caps(struct drm_device *dev,
return false;
}
- switch (mode_cmd->modifier[0] & AFBC_FORMAT_MOD_BLOCK_SIZE_MASK) {
- case AFBC_FORMAT_MOD_BLOCK_SIZE_16x16:
+ switch (mode_cmd->modifier[0] & AFBC_SIZE_MASK) {
+ case AFBC_SIZE_16X16:
if ((mode_cmd->width % 16) || (mode_cmd->height % 16)) {
DRM_DEBUG_KMS("AFBC buffers must be aligned to 16
pixels\n");
return false;
@@ -319,8 +319,8 @@ malidp_verify_afbc_framebuffer_size(struct drm_device *dev,
u32 afbc_superblock_size = 0, afbc_superblock_height = 0;
u32 afbc_superblock_width = 0, afbc_size = 0;
- switch (mode_cmd->modifier[0] & AFBC_FORMAT_MOD_BLOCK_SIZE_MASK) {
- case AFBC_FORMAT_MOD_BLOCK_SIZE_16x16:
+ switch (mode_cmd->modifier[0] & AFBC_SIZE_MASK) {
+ case AFBC_SIZE_16X16:
afbc_superblock_height = 16;
afbc_superblock_width = 16;
break;
diff --git a/drivers/gpu/drm/arm/malidp_hw.c b/drivers/gpu/drm/arm/malidp_hw.c
index 87b7b12..55d379b 100644
--- a/drivers/gpu/drm/arm/malidp_hw.c
+++ b/drivers/gpu/drm/arm/malidp_hw.c
@@ -137,6 +137,32 @@ static const struct malidp_layer malidp650_layers[] = {
ROTATE_NONE, 0 },
};
+const u64 malidp_format_modifiers[] = {
+ /* All RGB formats (except XRGB, RGBX, XBGR, BGRX) */
+ DRM_FORMAT_MOD_ARM_AFBC(AFBC_SIZE_16X16 | AFBC_YTR | AFBC_SPARSE),
+ DRM_FORMAT_MOD_ARM_AFBC(AFBC_SIZE_16X16 | AFBC_YTR),
+
+ /* All RGB formats > 16bpp (except XRGB, RGBX, XBGR, BGRX) */
+ DRM_FORMAT_MOD_ARM_AFBC(AFBC_SIZE_16X16 | AFBC_YTR | AFBC_SPARSE |
AFBC_SPLIT),
+
+ /* All 8 or 10 bit YUV 444 formats. */
+ /* In DP550, 10 bit YUV 420 format also supported */
+ DRM_FORMAT_MOD_ARM_AFBC(AFBC_SIZE_16X16 | AFBC_SPARSE | AFBC_SPLIT),
+
+ /* YUV 420, 422 P1 8 bit and YUV 444 8 bit/10 bit formats */
+ DRM_FORMAT_MOD_ARM_AFBC(AFBC_SIZE_16X16 | AFBC_SPARSE),
+ DRM_FORMAT_MOD_ARM_AFBC(AFBC_SIZE_16X16),
+
+ /* YUV 420, 422 P1 8, 10 bit formats */
+ DRM_FORMAT_MOD_ARM_AFBC(AFBC_SIZE_16X16 | AFBC_CBR | AFBC_SPARSE),
+ DRM_FORMAT_MOD_ARM_AFBC(AFBC_SIZE_16X16 | AFBC_CBR),
+
+ /* All formats */
+ DRM_FORMAT_MOD_LINEAR,
+
+ DRM_FORMAT_MOD_INVALID
+};
+
#define SE_N_SCALING_COEFFS96
static const u16 dp500_se_scaling_coeffs[][SE_N_SCALING_COEFFS] = {
[MALIDP_UPSCALING_COEFFS - 1] = {
@@ -841,7 +867,7 @@ const struct malidp_hw malidp_device[MALIDP_MAX_DEVICES] = {
.se_base = MALIDP550_SE_BASE,
.dc_base = MALIDP550_DC_BASE,
.out_depth_base = MALIDP550_DE_OUTPUT_DEPTH,
- .features = MALIDP_REGMAP_HAS_CLEARIRQ,
+ .features = MALIDP_REGMAP_HAS_CLEARIRQ |
MALIDP_DEVICE_AFBC_SUPPORT_SPLIT | AFBC_SUPPORT_SPLIT_WITH_YUV_420_10,
.n_layers = ARRAY_SIZE(malidp550_layers),
.layers = malidp550_layers,
.de_irq_map = {
@@ -887,7 +913,7 @@ const struct malidp_hw malidp_device[MALIDP_MAX_DEVICES] = {
.se_base = MALIDP550_SE_BASE,
.dc_base = MALIDP550_DC_BASE,
.out_depth_base = MALIDP550_DE_OUTPUT_DEPTH,
- .features = MALIDP_REGMAP_HAS_CLEARIRQ,
+ .features = MALIDP_REGMAP_HAS_CLEARIRQ |
MALIDP_DEVICE_AFBC_SUPPORT_SPLIT,
.n_layers = ARRAY_SIZE(malidp650_layers),
.layers = malidp650_layers,
.de_irq_map = {
diff --git a/drivers/gpu/drm/arm/malidp_hw.h b/drivers/gpu/drm/arm/malidp_hw.h
index 651558f..27b907f 100644
--- a/drivers/gpu/drm/arm/malidp_hw.h
+++ b/drivers/gpu/drm/arm/malidp_hw.h
@@ -95,7 +95,9 @@ struct malidp_se_config {
};
/*
[RFC AFBC v2 00/12] Add support for Arm Framebuffer Compression(AFBC) in mali display driver
This patchset aims to add support for AFBC in mali display driver with the help of format modifiers. AFBC modifiers adds some constraints to framebuffer size, alignment, pitch, formats, etc In the previous patchset ie https://lists.freedesktop.org/archives/dri-devel/2018-June/180124.html I had illustrated how to add support for one format (ie BGR888) with one valid combination of AFBC modifiers ie AFBC_SIZE_16X16 | AFBC_YTR | AFBC_SPARSE Changes from v1:- In this current patchset, I have enabled the support for all AFBC modifiers (which are supported on DP500, DP550 and DP650) with all the pixel formats. Also, we have introduced some new pixel formats which are supported with AFBC modifiers only as well some other pixel formats which are supported with LINEAR only. Please feel free to let me know your thoughts. Depends on :- https://patchwork.kernel.org/patch/10460063/ Ayan Kumar Halder (10): drm: Added a new format DRM_FORMAT_XVYU2101010 drm/arm/malidp: Set the AFBC register bits if the framebuffer has AFBC modifier drm/arm/malidp:- Define a common list of AFBC format modifiers supported for DP500, DP550 and DP650 drm/arm/malidp:- Added support for new YUV formats for DP500, DP550 and DP650 drm/arm/malidp: Define the constraints on each supported drm_fourcc format for the AFBC modifiers. drm/arm/malidp: Specified the rotation memory requirements for AFBC YUV formats drm/arm/malidp:- Writeback framebuffer does not support any modifiers drm/arm/malidp:- Use the newly introduced malidp_format_get_bpp() instead of relying on cpp for calculating framebuffer size drm/arm/malidp:- Disregard the pitch alignment constraint for AFBC framebuffer. drm/arm/malidp: Added support for AFBC modifiers for all layers except DE_SMART Brian Starkey (2): drm/fourcc: Add AFBC yuv fourccs for Mali drm/afbc: Add AFBC modifier usage documentation Documentation/gpu/afbc.rst | 233 +++ Documentation/gpu/drivers.rst | 1 + MAINTAINERS | 1 + drivers/gpu/drm/arm/malidp_drv.c| 45 ++ drivers/gpu/drm/arm/malidp_drv.h| 6 + drivers/gpu/drm/arm/malidp_hw.c | 245 drivers/gpu/drm/arm/malidp_hw.h | 30 +++- drivers/gpu/drm/arm/malidp_mw.c | 7 +- drivers/gpu/drm/arm/malidp_planes.c | 268 +--- drivers/gpu/drm/arm/malidp_regs.h | 20 +++ drivers/gpu/drm/drm_fourcc.c| 11 ++ include/uapi/drm/drm_fourcc.h | 20 ++- 12 files changed, 799 insertions(+), 88 deletions(-) create mode 100644 Documentation/gpu/afbc.rst -- 2.7.4 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[RFC v3 AFBC 04/12] drm/arm/malidp: Set the AFBC register bits if the framebuffer has AFBC modifier
Added the AFBC decoder registers for DP500 , DP550 and DP650.
These registers control the processing of AFBC buffers. It controls various
features like AFBC decoder enable, lossless transformation and block split
as well as setting of the left, right, top and bottom cropping of AFBC buffers
(in number of pixels).
All the layers (except DE_SMART) support framebuffers with AFBC modifiers.
One needs to set the pixel values of the top, left, bottom and right cropping
for the AFBC framebuffer.
Cropping an AFBC framebuffer is controlled by the AFBC crop registers.
In that case, the layer input size registers should be configured with
framebuffer's dimensions and not with drm_plane_state source width/height
values (which is used for non AFBC framebuffer to denote cropping).
Changes from v1:
- Removed the "if (fb->modifier)" check from malidp_de_plane_update()
and added it in malidp_de_set_plane_afbc(). This will consolidate all the
AFBC specific register configurations in a single function ie
malidp_de_set_plane_afbc().
Changes from v2:
- For AFBC framebuffer, layer input size register should be set to
framebuffer's
width and height
Signed-off-by: Ayan Kumar Halder
---
drivers/gpu/drm/arm/malidp_hw.c | 25 +
drivers/gpu/drm/arm/malidp_hw.h | 2 +
drivers/gpu/drm/arm/malidp_planes.c | 109 +++-
drivers/gpu/drm/arm/malidp_regs.h | 20 +++
4 files changed, 130 insertions(+), 26 deletions(-)
diff --git a/drivers/gpu/drm/arm/malidp_hw.c b/drivers/gpu/drm/arm/malidp_hw.c
index b9bed11..87b7b12 100644
--- a/drivers/gpu/drm/arm/malidp_hw.c
+++ b/drivers/gpu/drm/arm/malidp_hw.c
@@ -94,11 +94,12 @@ static const struct malidp_layer malidp500_layers[] = {
* yuv2rgb matrix offset, mmu control register offset,
rotation_features
*/
{ DE_VIDEO1, MALIDP500_DE_LV_BASE, MALIDP500_DE_LV_PTR_BASE,
- MALIDP_DE_LV_STRIDE0, MALIDP500_LV_YUV2RGB, 0, ROTATE_ANY },
+ MALIDP_DE_LV_STRIDE0, MALIDP500_LV_YUV2RGB, 0, ROTATE_ANY,
+ MALIDP500_DE_LV_AD_CTRL },
{ DE_GRAPHICS1, MALIDP500_DE_LG1_BASE, MALIDP500_DE_LG1_PTR_BASE,
- MALIDP_DE_LG_STRIDE, 0, 0, ROTATE_ANY },
+ MALIDP_DE_LG_STRIDE, 0, 0, ROTATE_ANY, MALIDP500_DE_LG1_AD_CTRL
},
{ DE_GRAPHICS2, MALIDP500_DE_LG2_BASE, MALIDP500_DE_LG2_PTR_BASE,
- MALIDP_DE_LG_STRIDE, 0, 0, ROTATE_ANY },
+ MALIDP_DE_LG_STRIDE, 0, 0, ROTATE_ANY, MALIDP500_DE_LG2_AD_CTRL
},
};
static const struct malidp_layer malidp550_layers[] = {
@@ -106,13 +107,15 @@ static const struct malidp_layer malidp550_layers[] = {
* yuv2rgb matrix offset, mmu control register offset,
rotation_features
*/
{ DE_VIDEO1, MALIDP550_DE_LV1_BASE, MALIDP550_DE_LV1_PTR_BASE,
- MALIDP_DE_LV_STRIDE0, MALIDP550_LV_YUV2RGB, 0, ROTATE_ANY },
+ MALIDP_DE_LV_STRIDE0, MALIDP550_LV_YUV2RGB, 0, ROTATE_ANY,
+ MALIDP550_DE_LV1_AD_CTRL },
{ DE_GRAPHICS1, MALIDP550_DE_LG_BASE, MALIDP550_DE_LG_PTR_BASE,
- MALIDP_DE_LG_STRIDE, 0, 0, ROTATE_ANY },
+ MALIDP_DE_LG_STRIDE, 0, 0, ROTATE_ANY, MALIDP550_DE_LG_AD_CTRL
},
{ DE_VIDEO2, MALIDP550_DE_LV2_BASE, MALIDP550_DE_LV2_PTR_BASE,
- MALIDP_DE_LV_STRIDE0, MALIDP550_LV_YUV2RGB, 0, ROTATE_ANY },
+ MALIDP_DE_LV_STRIDE0, MALIDP550_LV_YUV2RGB, 0, ROTATE_ANY,
+ MALIDP550_DE_LV2_AD_CTRL },
{ DE_SMART, MALIDP550_DE_LS_BASE, MALIDP550_DE_LS_PTR_BASE,
- MALIDP550_DE_LS_R1_STRIDE, 0, 0, ROTATE_NONE },
+ MALIDP550_DE_LS_R1_STRIDE, 0, 0, ROTATE_NONE, 0 },
};
static const struct malidp_layer malidp650_layers[] = {
@@ -122,16 +125,16 @@ static const struct malidp_layer malidp650_layers[] = {
*/
{ DE_VIDEO1, MALIDP550_DE_LV1_BASE, MALIDP550_DE_LV1_PTR_BASE,
MALIDP_DE_LV_STRIDE0, MALIDP550_LV_YUV2RGB,
- MALIDP650_DE_LV_MMU_CTRL, ROTATE_ANY },
+ MALIDP650_DE_LV_MMU_CTRL, ROTATE_ANY, MALIDP550_DE_LV1_AD_CTRL
},
{ DE_GRAPHICS1, MALIDP550_DE_LG_BASE, MALIDP550_DE_LG_PTR_BASE,
MALIDP_DE_LG_STRIDE, 0, MALIDP650_DE_LG_MMU_CTRL,
- ROTATE_COMPRESSED },
+ ROTATE_COMPRESSED, MALIDP550_DE_LG_AD_CTRL },
{ DE_VIDEO2, MALIDP550_DE_LV2_BASE, MALIDP550_DE_LV2_PTR_BASE,
MALIDP_DE_LV_STRIDE0, MALIDP550_LV_YUV2RGB,
- MALIDP650_DE_LV_MMU_CTRL, ROTATE_ANY },
+ MALIDP650_DE_LV_MMU_CTRL, ROTATE_ANY, MALIDP550_DE_LV2_AD_CTRL
},
{ DE_SMART, MALIDP550_DE_LS_BASE, MALIDP550_DE_LS_PTR_BASE,
MALIDP550_DE_LS_R1_STRIDE, 0, MALIDP650_DE_LS_MMU_CTRL,
- ROTATE_NONE },
+ ROTATE_NONE, 0 },
};
#define SE_N_SCALING_COEFFS96
diff --git a/drivers/gpu/drm/arm/malidp_hw.h b/drivers/gpu/drm/arm/malidp_hw.h
index 40155e2..651558f 100644
---
