On Thu, Jul 01, 2021 at 06:07:09PM +0100, Normunds Rieksts wrote:
> Arm Fixed Rate Compression (AFRC) is a proprietary fixed rate image
> compression protocol and format.
> It is designed to provide guaranteed bandwidth and memory footprint
> reductions in graphics and media use-cases.
>
> This pa
nit
>
> this is done automatically as part of plane init, if drivers set the
> modifier list correctly. Which is the case here for both komeda and
> malidp.
>
> Signed-off-by: Daniel Vetter
> Cc: "James (Qian) Wang"
> Cc: Liviu Dudau
Acked-by: Liviu Dudau
Best rega
On Tue, Apr 27, 2021 at 11:20:12AM +0200, Daniel Vetter wrote:
> Even when all we support is linear, make that explicit. Otherwise the
> uapi is rather confusing.
:)
>
> Cc: sta...@vger.kernel.org
> Cc: Pekka Paalanen
> Cc: Liviu Dudau
> Cc: Brian Starkey
> Sign
#x27;s modes list.
> It is not expected by mode_valid.
>
> Replace mode->crtc_clock with mode->clock to fix the issue.
>
> Signed-off-by: Sandor Yu
It looks like at least drm/bridge/cdns-dsi.c does the same thing of using
mode->clock when validating, so looks like a legi
gt; Signed-off-by: Thomas Zimmermann
> Acked-by: Sam Ravnborg
Sorry for the delayed response due to holidays.
Acked-by: Liviu Dudau
Best regards,
Liviu
> ---
> drivers/gpu/drm/arm/hdlcd_drv.c | 174 ++--
> drivers/gpu/drm/arm/hdlcd_drv.h | 1 +
> 2 f
ducts.
> To
> +of course we'd better share as much as possible between different products.
> To
> achieve this, split the komeda device into two layers: CORE and CHIP.
>
> - CORE: for common features and capabilities handling.
Acked-by: Liviu D
n Haitzler
Acked-by: Liviu Dudau
Best regards,
Liviu
> ---
> drivers/gpu/drm/arm/display/komeda/komeda_dev.c | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_dev.c
> b/drivers/gpu/drm/arm/display/komeda/komeda_dev.c
>
inter tocompare memory content there
> agains the new sate to see if it changed. In this case, it's better to
s/sate/state/
> assume that the input changed as there is no old state to compare
> against and thus assume the changes happen anyway.
>
> Signed-off-by: Carsten Haitz
#include
> #include
> #include
> -#include
> #include
> #include
> #include
> --
> 2.32.0
>
Acked-by: Liviu Dudau
Best regards,
Liviu
--
| I would like to |
| fix the world, |
| but they're not |
| giving me the |
\ source code! /
---
¯\_(ツ)_/¯
s.
>
> This patch aims to add modifier definitions for describing
> AFRC.
>
> Signed-off-by: Normunds Rieksts
Looks good to me!
Reviewed-by: Liviu Dudau
Best regards,
Liviu
> ---
> include/uapi/drm/drm_fourcc.h | 109 +-
> 1 file cha
0 but
scaled up in an irregular way. Reverting the commit or applying this
patch fixes the problem on v5.14-rc1.
Fixes: 72a7cf0aec0c ("drm/amd/display: Keep linebuffer pixel depth at 30bpp for
DCE-11.0.")
Signed-off-by: Liviu Dudau
---
drivers/gpu/drm/amd/display/dc/core/dc_resource.c
}
>
> @ adds_new_state @
> identifier crtc_atomic_func.func;
> identifier crtc, state;
> @@
>
> func(struct drm_crtc *crtc, struct drm_atomic_state *state) {
> + struct drm_crtc_state *crtc_state = drm_atomic_get_new_crtc_state(state,
> crtc);
> ...
> - crtc->state
> + crtc_sta
const u32 *formats, int n_formats, uint32_t
> possible_crtcs)
> {
> struct drm_property_blob *blob;
> struct drm_connector *connector = &wb_connector->base;
> @@ -190,6 +191,9 @@ int drm_writeback_connector_init(struct drm_device *dev,
> return PTR_ERR(blob);
On Thu, Mar 17, 2022 at 06:45:34PM -0700, Abhinav Kumar wrote:
> For some vendor driver implementations, display hardware can
> be shared between the encoder used for writeback and the physical
> display.
>
> In addition resources such as clocks and interrupts can
> also be shared between writebac
On Thu, Mar 17, 2022 at 10:26:38AM -0700, Abhinav Kumar wrote:
> Hi Laurent
>
> Thanks for the review.
>
> On 3/17/2022 1:51 AM, Laurent Pinchart wrote:
> > Hi Abhinav,
> >
> > Thank you for the patch.
> >
> > On Wed, Mar 16, 2022 at 11:48:16AM -0700, Abhinav Kumar wrote:
> > > For some vendor
On Mon, Mar 21, 2022 at 04:56:43PM -0700, Abhinav Kumar wrote:
> For vendors drivers which pass an already allocated and
> initialized encoder especially for cases where the encoder
> hardware is shared OR the writeback encoder shares the resources
> with the rest of the display pipeline introduce
On Wed, Mar 23, 2022 at 11:28:56AM -0700, Abhinav Kumar wrote:
> Hi Liviu
Hello,
>
> Thanks for the review.
>
> On 3/23/2022 9:46 AM, Liviu Dudau wrote:
> > On Mon, Mar 21, 2022 at 04:56:43PM -0700, Abhinav Kumar wrote:
> > > For vendors drivers which
On Thu, Mar 24, 2022 at 09:36:50AM -0700, Abhinav Kumar wrote:
> Hi Liviu
Hello,
>
> Thanks for the response.
>
> On 3/24/2022 3:12 AM, Liviu Dudau wrote:
> > On Wed, Mar 23, 2022 at 11:28:56AM -0700, Abhinav Kumar wrote:
> > > Hi Liviu
> >
> > Hell
n komeda_plane_reset(). However, the helpers have been
> adjusted to set it properly at reset, so this is not needed anymore.
>
> Cc: Brian Starkey
> Cc: "James (Qian) Wang"
> Cc: Liviu Dudau
> Cc: Mihail Atanassov
> Signed-off-by: Maxime Ripard
Acked-by: Liviu Dudau
tate, the driver had
> to set it again in komeda_plane_reset(). However, the helpers have been
> adjusted to set it properly at reset, so this is not needed anymore.
>
> Cc: Brian Starkey
> Cc: "James (Qian) Wang"
> Cc: Liviu Dudau
> Cc: Mihail Atanassov
> Signe
> Cc: "James (Qian) Wang"
> Cc: Liviu Dudau
> Cc: Mihail Atanassov
> Signed-off-by: Maxime Ripard
Acked-by: Liviu Dudau
Best regards,
Liviu
> ---
> drivers/gpu/drm/arm/display/komeda/komeda_plane.c | 6 +-
> 1 file changed, 1 insertion(+), 5 deletions(-)
&
On Tue, Aug 31, 2021 at 03:43:19PM +0800, Cai Huoqing wrote:
> Use the devm_platform_ioremap_resource() helper instead of
> calling platform_get_resource() and devm_ioremap_resource()
> separately
>
> Signed-off-by: Cai Huoqing
Acked-by: Liviu Dudau
Many thanks,
Liviu
>
> Signed-off-by: Carsten Haitzler
Acked-by: Liviu Dudau
I will add Steven's reviewed-by as well when pushing it.
Best regards,
Liviu
> ---
> drivers/gpu/drm/arm/Kconfig | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/gpu/drm/arm/Kconfig b/drivers/gpu/d
Hi Zhou,
On Tue, Nov 30, 2021 at 10:23:01PM +0800, Zhou Qingyang wrote:
> In komeda_plane_add(), komeda_get_layer_fourcc_list() is assigned to
> formats and used in drm_universal_plane_init().
> drm_universal_plane_init() passes formats to
> __drm_universal_plane_init(). __drm_universal_plane_init
ch komeda_dev to DRM-KMS")
> Signed-off-by: Zhou Qingyang
Thanks for the fix!
Reviewed-by: Liviu Dudau
Best regards,
Liviu
> ---
> Changes in v2
> - Use kfree and return instead of using 'goto'
>
> drivers/gpu/drm/arm/display/komeda/komeda_plane.c | 4
On Wed, Dec 01, 2021 at 03:44:03PM +, Steven Price wrote:
> On 30/11/2021 14:25, Zhou Qingyang wrote:
> > In komeda_plane_add(), komeda_get_layer_fourcc_list() is assigned to
> > formats and used in drm_universal_plane_init().
> > drm_universal_plane_init() passes formats to
> > __drm_universal
: Liviu Dudau
---
drivers/gpu/drm/arm/display/komeda/komeda_plane.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_plane.c
b/drivers/gpu/drm/arm/display/komeda/komeda_plane.c
index aa193c58f4bf6d9..517b94c3bcaf966 100644
--- a
; drm_mode_object_unregister() leaking the modeset identifier. Move it to
> the start of the function to avoid allocating those resources in the
> first place.
>
> Signed-off-by: Steven Price
Well spotted!
Reviewed-by: Liviu Dudau
I'm going to wait to see if anyone else has any c
Hi Jiasheng,
On Tue, Dec 14, 2021 at 08:51:10PM +0800, Jiasheng Jiang wrote:
> The return value of kzalloc() needs to be checked.
> To avoid use of null pointer '&state->base' in case of the
> failure of alloc.
>
> Fixes: 99665d072183 ("drm: mali-dp: add malidp_crtc_state struct")
> Signed-off-by
N already flags this as out-of-bounds
> stack reads. This fixes it by just importing inot a local long.
>
> Signed-off-by: Carsten Haitzler
Acked-by: Liviu Dudau
Best regards,
Liviu
> ---
> drivers/gpu/drm/arm/display/komeda/komeda_pipeline.c | 3 ++-
> 1 file changed, 2 inser
Add MAINTAINERS entry for ARM Mali-DP driver and update the
HDLCD file matching pattern to cover only HDLCD rather than
the whole drivers/gpu/drm/arm directory.
Signed-off-by: Liviu Dudau
---
MAINTAINERS | 10 +-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/MAINTAINERS b
MALIDP_HW_FEATURE_DS (display split) from this version pending
further development
- Renamed module from malidp to mali-dp.
- Added MAINTAINERS update
Many thanks,
Liviu
Liviu Dudau (3):
dt/bindings: display: Add DT bindings for Mali Display Processors.
drm/arm: Add support for Mali Display Processors
Add support for the new family of Display Processors from ARM Ltd.
This commit adds basic support for Mali DP500, DP550 and DP650
parts, with only the display engine being supported at the moment.
Cc: David Brown
Cc: Brian Starkey
Signed-off-by: Liviu Dudau
---
drivers/gpu/drm/arm/Kconfig
Add DT bindings documentation for the Mali Display Processor. The bindings
describe the Mali DP500, DP550 and DP650 processors from ARM Ltd.
Cc: Rob Herring
Cc: Pawel Moll
Cc: Mark Rutland
Cc: Ian Campbell
Cc: Kumar Gala
Signed-off-by: Liviu Dudau
---
.../devicetree/bindings/display/arm
On Mon, Apr 25, 2016 at 05:00:02PM +0100, Emil Velikov wrote:
> On 25 April 2016 at 15:19, Liviu Dudau wrote:
> > Add MAINTAINERS entry for ARM Mali-DP driver and update the
> > HDLCD file matching pattern to cover only HDLCD rather than
> > the whole drivers/gpu/drm/arm dire
On Tue, Apr 26, 2016 at 04:11:36PM +0200, Maarten Lankhorst wrote:
> The async name is deprecated and should be changed to nonblocking.
>
> Cc: Liviu Dudau
> Signed-off-by: Maarten Lankhorst
Acked-by: Liviu Dudau
> ---
> drivers/gpu/drm/arm/hdlcd_drv.c | 2 +-
> 1 file
Hi DRM maintainers,
This is the 2nd pull request for the malidp-next. The new patches add
additional support for Arm Mali D71 so that it can now be enabled
correctly and brought up on any SoC that contains the IP. From now on
we will start focusing on adding writeback, scaling and other useful
fea
On Thu, May 02, 2019 at 05:10:09PM +0100, Ben Davis wrote:
> Add new properties to specify x,y coordinates and
> width and height for writeback.
>
> These are reset to 0 on duplicating state to provide
> robustness against accidental scaling.
>
> Signed-off-by: Ben Davis
ned-off-by: Ben Davis
Reviewed-by: Liviu Dudau
I will pull this series the mali-dp tree after more people had a chance
to review it. I think the next thing to do would be to come up with a
test in igt for these properties.
Thanks,
Liviu
> ---
> drivers/gpu/drm/arm/malidp_crtc.c | 47 +++
On Fri, May 03, 2019 at 09:54:35AM +1000, Dave Airlie wrote:
> On Thu, 2 May 2019 at 20:45, Liviu Dudau wrote:
> >
> > Hi DRM maintainers,
> >
> > This is the 2nd pull request for the malidp-next. The new patches add
> > additional support for Arm Mali
On Fri, May 03, 2019 at 11:15:23AM +0200, Daniel Vetter wrote:
> On Fri, May 3, 2019 at 11:11 AM Liviu Dudau wrote:
> >
> > On Fri, May 03, 2019 at 09:54:35AM +1000, Dave Airlie wrote:
> > > On Thu, 2 May 2019 at 20:45, Liviu Dudau wrote:
> > > >
> > &g
On Fri, May 03, 2019 at 11:15:23AM +0200, Daniel Vetter wrote:
> On Fri, May 3, 2019 at 11:11 AM Liviu Dudau wrote:
> >
> > On Fri, May 03, 2019 at 09:54:35AM +1000, Dave Airlie wrote:
> > > On Thu, 2 May 2019 at 20:45, Liviu Dudau wrote:
> > > >
> > &g
On Fri, May 03, 2019 at 09:54:35AM +1000, Dave Airlie wrote:
> On Thu, 2 May 2019 at 20:45, Liviu Dudau wrote:
> >
> > Hi DRM maintainers,
> >
> > This is the 2nd pull request for the malidp-next. The new patches add
> > additional support for Arm Mali
ed-off-by: Dan Carpenter
Acked-by: Liviu Dudau
I'll pull this and send it as a fix after -rc1.
Best regards,
Liviu
> ---
> drivers/gpu/drm/arm/display/komeda/komeda_plane.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/arm/display
On Tue, May 07, 2019 at 09:50:19AM +1000, Dave Airlie wrote:
> On Fri, 3 May 2019 at 22:17, Daniel Vetter wrote:
> >
> > On Fri, May 03, 2019 at 10:29:48AM +0100, Liviu Dudau wrote:
> > > On Fri, May 03, 2019 at 11:15:23AM +0200, Daniel Vetter wrote:
> > > > O
On Wed, Apr 03, 2019 at 04:35:11PM -0300, Rodrigo Siqueira wrote:
> Hi,
Hi Rodrigo,
>
> I’m working to add writeback support to vkms; you can see my current
> patch at the end of this email (some prints highlight the issue that I’m
> asking for help here). I’m using the Liviu
Hi Ben,
On Fri, Apr 12, 2019 at 03:08:28PM +0100, Ben Davis wrote:
> Add new properties to specify width and height for writeback.
>
> Signed-off-by: Ben Davis
> ---
> drivers/gpu/drm/drm_atomic_uapi.c | 8
> drivers/gpu/drm/drm_writeback.c | 28
> inclu
Hi Ben,
On Fri, Apr 12, 2019 at 03:08:32PM +0100, Ben Davis wrote:
> The phase setting part of malidp_crtc_atomic_check_scaling is refactored
> to allow use in writeback scaling.
>
> Also the enable_memwrite function prototype is simplified by directly
> passing mw_state.
>
> Signed-off-by: Ben
On Mon, Apr 15, 2019 at 08:59:30AM +0100, james qian wang (Arm Technology
China) wrote:
> On Fri, Apr 12, 2019 at 02:08:28PM +, Ben Davis wrote:
> > Add new properties to specify width and height for writeback.
> >
> > Signed-off-by: Ben Davis
> > ---
> > drivers/gpu/drm/drm_atomic_uapi.c |
On Tue, Apr 16, 2019 at 09:34:20AM +0200, Daniel Vetter wrote:
> On Mon, Apr 15, 2019 at 10:20:45AM +0100, Liviu Dudau wrote:
> > On Mon, Apr 15, 2019 at 08:59:30AM +0100, james qian wang (Arm Technology
> > China) wrote:
> > > On Fri, Apr 12, 2019 at 02:08:28P
On Tue, Apr 16, 2019 at 11:55:34AM +0200, Daniel Vetter wrote:
> On Tue, Apr 16, 2019 at 11:17 AM Liviu Dudau wrote:
> >
> > On Tue, Apr 16, 2019 at 09:34:20AM +0200, Daniel Vetter wrote:
> > > On Mon, Apr 15, 2019 at 10:20:45AM +0100, Liviu Dudau wrote:
> > > >
On Tue, Apr 23, 2019 at 02:24:11PM +0200, Daniel Vetter wrote:
> On Tue, Apr 23, 2019 at 12:48 PM Ben Davis wrote:
> >
> > Add support for scaling on writeback. To do this add writeback_dest_w
> > and writeback_dest_h as writeback connector properties to specify the
> > desired output dimensions.
p.org/series/58976/
>
> Reported-by: kbuild test robot
> Signed-off-by: James (Qian) Wang
Acked-by: Liviu Dudau
> ---
> .../gpu/drm/arm/display/komeda/d71/d71_component.c| 9 +
> drivers/gpu/drm/arm/display/komeda/komeda_crtc.c | 4 ++--
> drivers/gpu/drm/arm
> This patch depends on:
> - https://patchwork.freedesktop.org/series/54448/
> - https://patchwork.freedesktop.org/series/54449/
> - https://patchwork.freedesktop.org/series/54450/
>
> v2: Rebase and add reporter
>
> Reported-by: kbuild test robot
> Signed-off-by: James Qian Wang (Arm Tech
ttps://lore.kernel.org/lkml/20181128.215241.702406654469517539.da...@davemloft.net/
>
> Fixes: 4cc734cb79a8 ("drm/komeda: Add sysfs attribute: core_id and config_id")
> Link: https://github.com/ClangBuiltLinux/linux/issues/457
> Signed-off-by: Nathan Chancellor
On Tue, Jan 22, 2019 at 05:28:19PM +0100, Daniel Vetter wrote:
> On Tue, Jan 22, 2019 at 5:11 PM Sean Paul wrote:
> > On Tue, Jan 22, 2019 at 04:17:25PM +0100, Daniel Vetter wrote:
> > > On Tue, Jan 22, 2019 at 4:08 PM Brian Starkey
> > > wrote:
> > > >
> > > > On Tue, Jan 22, 2019 at 03:03:59PM
n be tested (Harry, Eric, Sean, ...).
>
> 1: https://patchwork.kernel.org/patch/10648851/
> Cc: Petri Latvala
> Cc: Arkadiusz Hiler
> Cc: Liviu Dudau
> Cc: Sean Paul
> Cc: Eric Anholt
> Cc: Alex Deucher
> Cc: Dave Airlie
> Cc: Daniel Stone
> Cc: "Went
[PATCH] drm/komeda: merge fix for drm_atomic_private_obj_init() API
change
Signed-off-by: Stephen Rothwell
Acked-by: Liviu Dudau
---
drivers/gpu/drm/arm/display/komeda/komeda_private_obj.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/arm/display/komeda/ko
On Thu, Dec 20, 2018 at 04:36:19PM +0100, Daniel Vetter wrote:
> On Thu, Dec 20, 2018 at 09:56:57AM -0500, Alex Deucher wrote:
> > I'm not familiar enough with ARM to know if write combining
> > is actually an architectural limitation or if it's an issue
> > with the PCIe IPs used on various platfo
struct seq_file *sf);
> +};
> +
> +/**
> + * struct komeda_pipeline
> + *
> + * Represent a complete display pipeline and hold all functional components.
> + */
> +struct komeda_pipeline {
> + /** @obj: link pipeline as private obj of drm_atomic_state */
> + struct drm_p
; + };
> +
> + dp0_pipe1: pipeline@1 {
> + clocks = <&fpgaosc2>, <&dpu_aclk>;
> + clock-names = "pxclk", "aclk";
> + reg = <1>;
> +
> + #address-cells = <1>;
> + #size-cells = <0>;
same here.
> +
&g
gt; product->identify();
> ...
> }
>
> Changes in v3:
> - Fixed style problem found by checkpatch.pl --strict.
>
> Signed-off-by: James (Qian) Wang
Acked-by: Liviu Dudau
Best regards,
Liviu
> ---
> .../gpu/drm/arm/display/include/malidp_io.h | 42 +++
f "pipeline" to "pipe".
>
> Signed-off-by: James (Qian) Wang
Acked-by: Liviu Dudau
Best regards,
Liviu
> ---
> .../gpu/drm/arm/display/komeda/komeda_dev.c | 76 +++
> .../gpu/drm/arm/display/komeda/komeda_dev.h | 3 +
> .../drm/
-strict.
>
> Signed-off-by: James (Qian) Wang
Acked-by: Liviu Dudau
Best regards,
Liviu
> ---
> drivers/gpu/drm/arm/display/komeda/Makefile | 1 +
> .../gpu/drm/arm/display/komeda/d71/d71_dev.c | 78
> .../gpu/drm/arm/display/komeda/komeda_dev.c |
create_handle,
> +};
> +
> +static int
> +komeda_fb_none_afbc_size_check(struct komeda_dev *mdev, struct komeda_fb
> *kfb,
> +struct drm_file *file,
> +const struct drm_mode_fb_cmd2 *mode_cmd)
Not sure what
v/null
> +++ b/drivers/gpu/drm/arm/display/komeda/komeda_private_obj.c
> @@ -0,0 +1,88 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * (C) COPYRIGHT 2018 ARM Limited. All rights reserved.
> + * Author: James.Qian.Wang
> + *
> + */
> +#include "komeda_dev.h"
> +#inc
On Fri, Dec 21, 2018 at 10:00:49AM +, james qian wang (Arm Technology
China) wrote:
> v2: Some editing changes according to Randy Dunlap's comments
>
> Signed-off-by: James (Qian) Wang
Reviewed-by: Liviu Dudau
> ---
> Documentation/gpu/drivers.rst| 1 +
> D
On Fri, Dec 21, 2018 at 10:01:06AM +, james qian wang (Arm Technology
China) wrote:
> v2: Adjusted the position of KOMEDA by alphabetical order
>
> Signed-off-by: James (Qian) Wang
Acked-by: Liviu Dudau
Best regards,
Liviu
> ---
> MAINTAINERS | 9 +
>
On Thu, Dec 27, 2018 at 07:09:07AM +, james qian wang (Arm Technology
China) wrote:
> On Mon, Dec 24, 2018 at 08:32:14PM +0800, Liviu Dudau wrote:
> > On Fri, Dec 21, 2018 at 10:00:33AM +, james qian wang (Arm Technology
> > China) wrote:
> > > Add komeda_
On Thu, Dec 27, 2018 at 07:09:07AM +, james qian wang (Arm Technology
China) wrote:
> On Mon, Dec 24, 2018 at 08:32:14PM +0800, Liviu Dudau wrote:
> > On Fri, Dec 21, 2018 at 10:00:33AM +, james qian wang (Arm Technology
> > China) wrote:
> > > Add komeda_
On Fri, Dec 28, 2018 at 12:56:27PM +0100, Daniel Vetter wrote:
> On Fri, Dec 28, 2018 at 12:15 PM james qian wang (Arm Technology
> China) wrote:
> >
> > On Mon, Dec 24, 2018 at 02:05:43PM +0100, Daniel Vetter wrote:
> > > On Mon, Dec 24, 2018 at 1:33 PM Liviu Dudau wr
On Tue, Jan 08, 2019 at 12:39:36AM +, Russell King - ARM Linux wrote:
> On Mon, Jan 07, 2019 at 10:55:15PM +0100, Daniel Vetter wrote:
> > On Mon, Jan 7, 2019 at 5:13 PM Russell King - ARM Linux
> > wrote:
> > >
> > > On Mon, Jan 07, 2019 at 11:45:32AM +0100, Daniel Vetter wrote:
> > > > On Th
Hi Uma,
On Tue, Jan 08, 2019 at 02:41:20PM +0530, Uma Shankar wrote:
> Hardware may have HDR capability on certain plane
> engines. Enabling the same in drm plane structure
> so that this can be communicated to user space.
>
> Each drm driver should set this flag to true for planes
> which suppor
On Tue, Jan 08, 2019 at 02:41:16PM +0530, Uma Shankar wrote:
> This patch adds a blob property to get HDR metadata
> information from userspace. This will be send as part
> of AVI Infoframe to panel.
>
> v2: Rebase and modified the metadata structure elements
> as per Ville's POC changes.
>
> v3:
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
>
On Tue, Jan 15, 2019 at 10:46:19AM +1100, Stephen Rothwell wrote:
> Hi Liviu,
Hi Stephen,
>
> After merging the mali-dp tree, today's linux-next build (x86_64
> allmodconfig) failed like this:
>
> drivers/gpu/drm/arm/display/komeda/komeda_private_obj.c: In function
> 'komeda_pipeline_obj_add':
The initial series is only introducing the basic components and not
implementing IRQ handling. Remove the left over code that touches
IRQs until the proper implementation is introduced in a later series.
Signed-off-by: Liviu Dudau
---
drivers/gpu/drm/arm/display/komeda/komeda_dev.c | 5
On Tue, Jan 15, 2019 at 09:47:25PM +1100, Stephen Rothwell wrote:
> Hi Liviu,
>
> On Tue, 15 Jan 2019 10:12:19 +0000 Liviu Dudau wrote:
> >
> > That looks like the right fix, thank you for that!
>
> Thanks for your verification.
>
> > I will roll your patc
On Tue, Jan 15, 2019 at 01:08:36PM +0100, Daniel Vetter wrote:
> On Tue, Jan 15, 2019 at 10:51:02AM +0000, Liviu Dudau wrote:
> > On Tue, Jan 15, 2019 at 09:47:25PM +1100, Stephen Rothwell wrote:
> > > Hi Liviu,
> > >
> > > On Tue, 15 Jan 2019 10:1
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 pass
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:
> > > >
ches.
>
> I think this addresses all the concerns raised in the RFC discussions,
> and assuming there's enough Acks and no new issues that pop up, we can
> go ahead with this.
>
> 1: https://patchwork.kernel.org/patch/10648851/
> Cc: Petri Latvala
> Cc: Arkadiusz Hi
On Thu, Jan 17, 2019 at 12:52:16PM +0100, Daniel Vetter wrote:
> On Thu, Jan 17, 2019 at 12:38 PM Liviu Dudau wrote:
> >
> > On Wed, Jan 16, 2019 at 05:39:03PM +0100, Daniel Vetter wrote:
> > > Compared to the RFC[1] no changes to the patch itself, but igt m
On Thu, Jan 17, 2019 at 01:32:15PM +0100, Daniel Vetter wrote:
> On Thu, Jan 17, 2019 at 1:26 PM Liviu Dudau wrote:
> >
> > On Thu, Jan 17, 2019 at 12:52:16PM +0100, Daniel Vetter wrote:
> > > On Thu, Jan 17, 2019 at 12:38 PM Liviu Dudau wrote:
> > > >
> &
On Thu, Jan 17, 2019 at 04:59:49PM +0100, Daniel Vetter wrote:
> On Thu, Jan 17, 2019 at 3:54 PM Liviu Dudau wrote:
> >
> > On Thu, Jan 17, 2019 at 01:32:15PM +0100, Daniel Vetter wrote:
> > > On Thu, Jan 17, 2019 at 1:26 PM Liviu Dudau wrote:
> > > >
> &
the missing NULL set in the vc4 driver), pass the connector
> state pointer to the function instead of the job pointer, and set the
> writeback_job pointer to NULL internally.
>
> Signed-off-by: Laurent Pinchart
Acked-by: Liviu Dudau
Best regards,
Liviu
> ---
> driver
ered, but
> never addressed.
>
> Signed-off-by: Laurent Pinchart
Acked-by: Liviu Dudau
Best regards,
Liviu
> ---
> drivers/gpu/drm/drm_atomic_state_helper.c | 4
> drivers/gpu/drm/drm_writeback.c | 13 ++---
> 2 files changed, 14 insertions(+), 3 deletions
Hi Laurent,
On Thu, Feb 21, 2019 at 12:32:07PM +0200, Laurent Pinchart wrote:
> As writeback jobs contain a framebuffer, drivers may need to prepare and
> cleanup them the same way they can prepare and cleanup framebuffers for
> planes. Add two new optional connector helper operations,
> .prepare_
. The kerneldoc seems
> to imply that we probably shouldn't be looking at the rest of the
> state anyway if enable=false.
>
> Signed-off-by: Robin Murphy
Acked-by: Liviu Dudau
I'll pull your patch into my tree but it will be after v5.1-rc1 that
I'll send fixes to airl
> > 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: Tues
; Signed-off-by: Maarten Lankhorst
> Cc: Liviu Dudau
Acked-by: Liviu Dudau
If you need me to take this patch into malidp tree let me know,
otherwise I expect is going to show up in drm-misc-next at some moment.
Best regards,
Liviu
> Cc: Brian Starkey
> ---
> drivers/gpu
nction 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
7; 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
>
On Wed, Mar 06, 2019 at 01:14:40AM +0200, Laurent Pinchart wrote:
> Hi Brian,
>
> On Fri, Feb 22, 2019 at 03:06:19PM +, Brian Starkey wrote:
> > On Fri, Feb 22, 2019 at 04:46:29PM +0200, Laurent Pinchart wrote:
> > > On Fri, Feb 22, 2019 at 02:30:03PM +, Brian Starkey wrote:
> > >> On Thu,
On Wed, Mar 06, 2019 at 08:01:53PM +0200, Laurent Pinchart wrote:
> Hi Liviu,
>
> On Wed, Mar 06, 2019 at 02:20:51PM +0000, Liviu Dudau wrote:
> > On Wed, Mar 06, 2019 at 01:14:40AM +0200, Laurent Pinchart wrote:
> > > On Fri, Feb 22, 2019 at 03:06:19PM +, Brian Star
On Thu, Mar 07, 2019 at 03:48:23PM +0200, Laurent Pinchart wrote:
> Hi Liviu,
>
> On Thu, Mar 07, 2019 at 11:52:18AM +0000, Liviu Dudau wrote:
> > On Wed, Mar 06, 2019 at 08:01:53PM +0200, Laurent Pinchart wrote:
> > > On Wed, Mar 06, 2019 at 02:20:51PM +, Liviu Du
On Fri, Mar 08, 2019 at 02:46:08PM +0200, Laurent Pinchart wrote:
> Hi Liviu,
>
> On Thu, Mar 07, 2019 at 04:31:40PM +0000, Liviu Dudau wrote:
> > On Thu, Mar 07, 2019 at 03:48:23PM +0200, Laurent Pinchart wrote:
> > > On Thu, Mar 07, 2019 at 11:52:18AM +, Liviu Du
On Sun, Mar 10, 2019 at 06:20:34PM -0300, Rodrigo Siqueira wrote:
> Hi,
Hi Rodrigo,
>
> In the last few weeks, I was focused on implementing the writeback on
> VKMS by using the feedback that I got from Brian Starkey and Daniel
> Vetter in my previous attempt [1]. For testing/guiding my
> implem
ere it
> will cause unsupported modes to be correctly pruned in the first place.
>
> This also eliminates an issue whereby a perceived clock rate of 0 would
> cause atomic disable to fail and prevent the module from being unloaded.
>
> Signed-off-by: Robin Murphy
Acked-by: Livi
> like my oddball 1600x1200 with 130.89MHz clock get rejected since the
> rate cannot be matched exactly. In practice, though, this mode works
> quite happily with the clock at 131MHz, so let's relax the check to
> allow a little bit of slop.
>
> Signed-off-by: Robin Murphy
A
1 - 100 of 1046 matches
Mail list logo
