++ 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 an
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
> kom
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
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 interru
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
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.
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
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 croppi
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 Y
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 th
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
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 p
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
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 mo
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 illu
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
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",
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 a/include/uapi/drm/drm_f
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 Andro
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
On Wed, Apr 25, 2018 at 01:49:35PM +0200, Daniel Vetter wrote:
Hi Daniel,
> On Wed, Apr 25, 2018 at 1:26 PM, Liviu Dudau wrote:
> > On Wed, Apr 25, 2018 at 09:17:22AM +0200, Daniel Vetter wrote:
> >> On Tue, Apr 24, 2018 at 07:12:47PM +0100, Ayan Kumar Halder wrote:
> >> > malidp_pm_suspend_late c
Hi Liviu,
On Mon, Apr 23, 2018 at 04:36:47PM +0100, Liviu Dudau wrote:
> On Mon, Apr 23, 2018 at 03:50:49PM +0100, Ayan Kumar Halder wrote:
> > Scaling engine interrupts need to be enabled/disabled as and when memwrite
> > is enabled and disabled. The reason being scaling engine interrupts are
> >
On Tue, Mar 27, 2018 at 01:09:36PM +0200, Daniel Vetter wrote:
> On Tue, Mar 27, 2018 at 11:59 AM, Ayan Halder wrote:
> > On Tue, Mar 27, 2018 at 10:29:03AM +0200, Daniel Vetter wrote:
> >> On Mon, Mar 26, 2018 at 06:03:20PM +0100, Ayan Kumar Halder wrote:
> >> > ma
On Tue, Mar 27, 2018 at 10:29:03AM +0200, Daniel Vetter wrote:
> On Mon, Mar 26, 2018 at 06:03:20PM +0100, Ayan Kumar Halder wrote:
> > malidp_pm_suspend_late checks if the runtime status is not suspended
> > and if so, invokes malidp_runtime_pm_suspend which disables the
> > display engine/core in
On Tue, Jan 09, 2018 at 02:28:33PM +0100, Maxime Ripard wrote:
> Hi Laurent,
>
> On Tue, Jan 09, 2018 at 02:29:58PM +0200, Laurent Pinchart wrote:
> > On Tuesday, 9 January 2018 12:56:20 EET Maxime Ripard wrote:
> > > There's a bunch of drivers that duplicate the same function to know if a
> > > p
On Tue, Jan 09, 2018 at 02:28:33PM +0100, Maxime Ripard wrote:
> Hi Laurent,
>
> On Tue, Jan 09, 2018 at 02:29:58PM +0200, Laurent Pinchart wrote:
> > On Tuesday, 9 January 2018 12:56:20 EET Maxime Ripard wrote:
> > > There's a bunch of drivers that duplicate the same function to know if a
> > > pa
Mali dp needs to disable pixel alpha blending (use layer alpha blending) to
display color formats that do not contain alpha bits per pixel
Signed-off-by: Ayan Kumar Halder
---
drivers/gpu/drm/arm/malidp_planes.c | 27 ++-
1 file changed, 22 insertions(+), 5 deletions(-)
On Fri, Jan 12, 2018 at 04:51:16PM +0100, Maxime Ripard wrote:
> Hi,
>
> On Fri, Jan 12, 2018 at 03:43:49PM +0000, Ayan Halder wrote:
> > On Fri, Jan 12, 2018 at 04:28:34PM +0200, Ville Syrj?l? wrote:
> > > On Fri, Jan 12, 2018 at 02:21:16PM +, Ayan Halder wrote:
>
On Fri, Jan 12, 2018 at 05:53:33PM +0200, Ville Syrj?l? wrote:
> On Fri, Jan 12, 2018 at 03:43:49PM +0000, Ayan Halder wrote:
> > On Fri, Jan 12, 2018 at 04:28:34PM +0200, Ville Syrj?l? wrote:
> > > On Fri, Jan 12, 2018 at 02:21:16PM +, Ayan Halder wrote:
> > >
drm_format_info does not describe the number of bits used for the alpha
channel. That information is useful in a central place like drm_fourcc.c
where it can be queried by the drivers that want to determine if 'alpha
blending' is to be enabled or not.
Signed-off-by: Ayan Kumar Halder
Reviewed-by:
37 matches
Mail list logo
