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
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
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:-
/ {
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
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
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, O
++ 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 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
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 decod
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
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 pa
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. Rese
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
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
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
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
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.
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
19 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
>
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.
>
>
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
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
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
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
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
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
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 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
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 en
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")
>
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,
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
>
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’:
>
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
>
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.
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
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
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
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 inte
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
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.
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.
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)
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.
>
>
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.
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
>
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:
> > > &g
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
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
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
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
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.
>
>
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(+)
>
>
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
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
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
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
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
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
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
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
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
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
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
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
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 +
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
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
>
>
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
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
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
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
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
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
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
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
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
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
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
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
gt; > > 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_INT
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
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.
>
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
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
> > mali
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
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
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
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().
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
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
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
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
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
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
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
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
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
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
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
1 - 100 of 127 matches
Mail list logo
