On Fri, May 16, 2025 at 06:48:37PM +0200, Luca Ceresoli wrote:
> Use the new DRM bridge allocation API, which is the only supported now, for
> the kunit tests.
>
> This change is more massive than for the typical DRM bridge driver because
> struct drm_bridge_init_priv currently embeds a struct drm
ummy_br->bridge);
> + KUNIT_ASSERT_TRUE(test, ctx->destroyed);
Ditto
> +}
> +
> +static struct kunit_case drm_bridge_alloc_tests[] = {
> + KUNIT_CASE(drm_test_drm_bridge_alloc_basic),
> + KUNIT_CASE(drm_test_drm_bridge_alloc_get_put),
> + { }
> +};
> +
> +static
On Tue, May 27, 2025 at 03:36:16PM +0200, Louis Chauvet wrote:
>
>
> Le 22/05/2025 à 17:39, Maxime Ripard a écrit :
> > On Mon, May 12, 2025 at 03:07:55PM +0200, Louis Chauvet wrote:
> > > Hi Maxime,
> > >
> > > Did you have the time to look at this pa
nication.
> >
> > On Mon, 19 May 2025, Maxime Ripard wrote:
> >> You still haven't explained why it would take anything more than
> >> registering a dumb device at probe time though.
> >
> > With that, do you mean a dumb struct device, or any struct dev
On Tue, May 20, 2025 at 01:09:47PM +0300, Jani Nikula wrote:
>
> Maxime -
>
> I'm cutting a lot of context here. Not because I don't think it deserves
> an answer, but because I seem to be failing at communication.
>
> On Mon, 19 May 2025, Maxime Ripard wrote:
On Sat, May 24, 2025 at 08:09:36AM -0300, Maíra Canal wrote:
> On 20/05/25 09:08, Maxime Ripard wrote:
> > Commit 30188df0c387 ("drm/tests: Drop drm_kunit_helper_acquire_ctx_alloc()")
> > removed a kunit-managed function to get a drm_modeset_acquire_ctx.
On Thu, May 22, 2025 at 08:37:31PM +0300, Cristian Ciocaltea wrote:
> Hi Maxime,
>
> On 5/22/25 7:16 PM, Maxime Ripard wrote:
> > Hi,
> >
> > On Mon, May 19, 2025 at 01:55:10PM +0300, Cristian Ciocaltea wrote:
> >> On 5/19/25 11:42 AM, Maxime Ripard wrote:
legacy_cma_name = cma_get_name(default_cma);
> + if (!strcmp(legacy_cma_name, DEFAULT_CMA_NAME)) {
> + pr_warn("legacy name and default name are the same,
> skipping legacy heap\n");
> + return 0;
> + }
> +
> + ret = __add_cma_heap(default_cma, legacy_cma_name);
> + if (ret)
> + pr_warn("failed to add legacy heap: %pe\n",
> + ERR_PTR(-ret));
Are you sure about the -ret? ret should already be a negative number if it
failed?
With that fixed,
Reviewed-by: Maxime Ripard
Maxime
signature.asc
Description: PGP signature
On Thu, 22 May 2025 12:14:17 -0700, Jared Kangas wrote:
> Prepare for the introduction of a fixed-name CMA heap by replacing the
> unused void pointer parameter in __add_cma_heap() with the heap name.
>
> Signed-off-by: Jared Kangas
Reviewed-by: Maxime Ripard
Thanks!
Maxime
code snippets to fix this.
>
>
> [ ... ]
Reviewed-by: Maxime Ripard
Thanks!
Maxime
Hi,
On Mon, May 12, 2025 at 10:27:06PM +0200, Michael wrote:
> with v6.9 and later there is no output on the BananaPI HDMI connector.
>
> I have bisected the issue to the following commit:
>
> 358e76fd613a ("drm/sun4i: hdmi: Consolidate atomic_check and mode_valid")
>
> With this patch, sun4i
comment.
> > >
> > > On 26/05/25 11:26, Maxime Ripard wrote:
> > > > Hi,
> > > >
> > > > On Mon, May 26, 2025 at 10:54:52AM +0200, Tommaso Merciai wrote:
> > > > > After adv7511_mode_set() was merged into .atomic_enable(), on
Hi,
On Mon, May 26, 2025 at 10:54:52AM +0200, Tommaso Merciai wrote:
> After adv7511_mode_set() was merged into .atomic_enable(), only the
> native resolution is working when using modetest.
>
> This is caused by incorrect timings: adv7511_mode_set() must not be
> merged into .atomic_enable().
>
On Thu, May 22, 2025 at 07:47:00PM +0300, Cristian Ciocaltea wrote:
> On 5/22/25 7:06 PM, Maxime Ripard wrote:
> > On Mon, May 19, 2025 at 01:35:46PM +0300, Cristian Ciocaltea wrote:
> >> On 5/19/25 10:22 AM, Maxime Ripard wrote:
> >>> Hi,
> >>>
>
Hi,
On Mon, May 19, 2025 at 01:55:10PM +0300, Cristian Ciocaltea wrote:
> On 5/19/25 11:42 AM, Maxime Ripard wrote:
> > Hi,
> >
> > On Fri, Apr 25, 2025 at 01:27:14PM +0300, Cristian Ciocaltea wrote:
> >> Provide a test to verify that if both driver and screen suppo
On Mon, May 19, 2025 at 01:35:46PM +0300, Cristian Ciocaltea wrote:
> On 5/19/25 10:22 AM, Maxime Ripard wrote:
> > Hi,
> >
> > On Fri, Apr 25, 2025 at 01:27:05PM +0300, Cristian Ciocaltea wrote:
> >> In preparation to improve error handling throughout all test ca
On Fri, May 16, 2025 at 05:38:28PM +0200, Luca Ceresoli wrote:
> > > Another way would be adding an optional .destroy a callback in struct
> > > drm_bridge_funcs that is called in __drm_bridge_free(), and only the
> > > kunit test code implements it. Maybe looks cleaner, but it would be
> > > invas
On Fri, May 16, 2025 at 06:48:38PM +0200, Luca Ceresoli wrote:
> Some users of DRM bridges may need to execute specific code just before
> deallocation.
>
> As of now the only known user would be KUnit tests.
>
> Suggested-by: Maxime Ripard
> Signed-off-by: Luca Ceresol
On Mon, May 12, 2025 at 03:07:55PM +0200, Louis Chauvet wrote:
> Hi Maxime,
>
> Did you have the time to look at this patch?
>
> Pekka added his Acked-by, but as you made some remarks about this patch, I
> would like to have your validation before applying it.
Yep, thank you
On Thu, May 22, 2025 at 11:20:17AM +0800, Liu Ying wrote:
> >> drm: convert many bridge drivers from devm_kzalloc() to
> >> devm_drm_bridge_alloc() API
> >
> > This patch affects multiple drivers. Running get_maintainers.pl
> > points at Shawn Guo's repository. After reviewing the MAINTAINE
On Wed, May 21, 2025 at 04:22:16PM +0200, Luca Ceresoli wrote:
> Hello Maxime, Shawn, Liu, all,
>
> On Fri, 09 May 2025 15:53:26 +0200
> Luca Ceresoli wrote:
>
> > devm_drm_bridge_alloc() [0] is the new API to allocate and initialize a DRM
> > bridge, and the only one supported from now on. It i
Hi Jared,
On Thu, Apr 24, 2025 at 09:11:24AM -0700, Jared Kangas wrote:
> > > struct cma_heap {
> > > struct dma_heap *heap;
> > > @@ -394,15 +395,26 @@ static int __init __add_cma_heap(struct cma *cma,
> > > const char *name)
> > > static int __init add_default_cma_heap(void)
> > > {
> > >
On Tue, 20 May 2025 22:03:31 -0500, Anusha Srivatsa wrote:
> Convert drivers to use the API - devm_drm_panel_alloc().
> There are a lot of occurences of the panel allocation across the
> subsystem. Much thanks to Maxime for the semanic patch which actually
> gives a list of panels allocated unsafel
Some reserved memory regions might have particular memory setup or
attributes that make them good candidates for heaps.
Let's provide a heap type that will create a new heap for each reserved
memory region flagged as such.
Signed-off-by: Maxime Ripard
---
Hi,
This series is the follow-
Hi Catalin,
On Wed, Apr 16, 2025 at 10:34:05AM +0100, Catalin Marinas wrote:
> On Thu, Feb 20, 2025 at 02:25:37PM +0100, Maxime Ripard wrote:
> > lockdep complains when a lock is released in a separate thread the
> > lock is taken in, and it turns out that kunit does run i
m_vc4_test_pv_muxing() and drm_vc4_test_pv_muxing_invalid().
Fixes: 30188df0c387 ("drm/tests: Drop drm_kunit_helper_acquire_ctx_alloc()")
Reported-by: Catalin Marinas
Closes: https://lore.kernel.org/r/z_95jwm2ymtgy...@arm.com/
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/vc4/t
We've discussed a number of times of how some heap names are bad, but
not really what makes a good heap name.
Let's document what we expect the heap names to look like.
Signed-off-by: Maxime Ripard
---
Documentation/userspace-api/dma-buf-heaps.rst | 19 +++
1 file c
of
> Broadcast RGB property is.
>
>
> [ ... ]
Acked-by: Maxime Ripard
Thanks!
Maxime
On Wed, May 14, 2025 at 12:22:40PM +0300, Jani Nikula wrote:
> On Tue, 13 May 2025, Maxime Ripard wrote:
> > Is it really surprising you get some pushback when you are using a
> > design that is the complete opposite to what every user of it for the
> > last decade has
On Fri, 25 Apr 2025 13:27:11 +0300, Cristian Ciocaltea wrote:
> Create a test EDID advertising the following capabilities:
>
> Max resolution: 3840x2160@30Hz with RGB, YUV444, YUV422, YUV420
> Max BPC:16 for all modes
> Max TMDS clock: 340 MHz
>
> [ ... ]
Ac
d test cases.
>
>
> [ ... ]
Acked-by: Maxime Ripard
Thanks!
Maxime
On Fri, 25 Apr 2025 13:27:12 +0300, Cristian Ciocaltea wrote:
> Provide tests to verify drm_atomic_helper_connector_hdmi_check() helper
> fallback behavior when using YUV420 output format.
>
> Signed-off-by: Cristian Ciocaltea
Acked-by: Maxime Ripard
Thanks!
Maxime
On Sun, May 18, 2025 at 05:53:59PM -0400, Michael S. Tsirkin wrote:
> On Tue, May 13, 2025 at 12:18:44PM +0200, Gerd Hoffmann wrote:
> > > > diff --git a/drivers/gpu/drm/virtio/virtgpu_drv.c
> > > > b/drivers/gpu/drm/virtio/virtgpu_drv.c
> > > > index e32e680c7197..71c6ccad4b99 100644
> > > > ---
Hi,
On Fri, Apr 25, 2025 at 01:27:14PM +0300, Cristian Ciocaltea wrote:
> Provide a test to verify that if both driver and screen support RGB and
> YUV420 formats, drm_atomic_helper_connector_hdmi_check() cannot succeed
> when trying to set a mode unsupported by the display.
>
> Signed-off-by: Cr
On Fri, 25 Apr 2025 13:27:13 +0300, Cristian Ciocaltea wrote:
> Provide test to verify a mandatory fallback to YUV420 output cannot
> succeed when driver doesn't advertise YUV420 support.
>
> Signed-off-by: Cristian Ciocaltea
Acked-by: Maxime Ripard
Thanks!
Maxime
On Fri, 25 Apr 2025 13:27:08 +0300, Cristian Ciocaltea wrote:
> Create a test EDID advertising the following capabilities:
>
> Max resolution:
> - 1920x1080@60Hz with RGB, YUV444, YUV422
> - 3840x2160@30Hz with YUV420 only
>
> [ ... ]
Acked-by: Maxime Ripard
Thanks!
Maxime
ate it or to unregister CEC data. Unlike drm_connector_cec_funcs
> (which provides interface common to all implementations, including, but
>
> [ ... ]
Reviewed-by: Maxime Ripard
Thanks!
Maxime
he connector to be provided by the bridge.
>
>
> [ ... ]
Reviewed-by: Maxime Ripard
Thanks!
Maxime
On Sat, 17 May 2025 04:59:43 +0300, Dmitry Baryshkov wrote:
> Switch VC4 driver to using CEC helpers code, simplifying hotplug and
> registration / cleanup. The existing vc4_hdmi_cec_release() is kept for
> now.
>
> Signed-off-by: Dmitry Baryshkov
>
> [ ... ]
Revie
; CEC data is a void pointer as it allows us to make CEC data
>
> [ ... ]
Reviewed-by: Maxime Ripard
Thanks!
Maxime
to only read the new connector state.
>
>
> [ ... ]
Acked-by: Maxime Ripard
Thanks!
Maxime
Hi,
On Fri, Apr 25, 2025 at 01:27:05PM +0300, Cristian Ciocaltea wrote:
> In preparation to improve error handling throughout all test cases,
> introduce a macro to check for EDEADLK and automate the restart of the
> atomic sequence.
>
> Signed-off-by: Cristian Ciocaltea
> ---
> drivers/gpu/drm
Hi,
On Fri, Apr 25, 2025 at 01:27:03PM +0300, Cristian Ciocaltea wrote:
> Provide a wrapper over drm_kunit_helper_enable_crtc_connector() to
> automatically handle EDEADLK.
>
> This is going to help improve the error handling in a bunch of test
> cases without open coding the restart of the atomi
On Fri, 25 Apr 2025 13:27:01 +0300, Cristian Ciocaltea wrote:
> After updating the code to make use of the new EDID setup helper,
> drm_kunit_helper_connector_hdmi_init_funcs() became unused, hence drop
> it.
>
> Signed-off-by: Cristian Ciocaltea
>
> [ ... ]
Acked-by: M
On Fri, 25 Apr 2025 13:27:00 +0300, Cristian Ciocaltea wrote:
> Make use of the recently introduced macros to reduce boilerplate code
> around EDID setup. This also helps dropping the redundant calls to
> set_connector_edid().
>
> No functional changes intended.
>
> [ ..
On Thu, May 15, 2025 at 03:44:18PM +0300, Cristian Ciocaltea wrote:
> Hi Maxime,
>
> On 5/13/25 4:35 PM, Maxime Ripard wrote:
> > Hi,
> >
> > On Fri, Apr 25, 2025 at 01:26:57PM +0300, Cristian Ciocaltea wrote:
> >> Try to make use of YUV420 when computing
On Tue, Apr 15, 2025 at 01:22:14PM +0200, Luca Ceresoli wrote:
> > > +/*
> > > + * Mimick the typical struct defined by a bridge driver, which embeds a
> > > + * bridge plus other fields.
> > > + */
> > > +struct dummy_drm_bridge {
> > > + int dummy; // ensure we test non-zero @bridge offset
> > >
On Sun, 11 May 2025 22:31:18 +1200, Ryan Walklin wrote:
> From: Jernej Skrabec
>
> The vi_scaler appears to be used in preference to the ui_scaler module
> for hardware video scaling in the DE33.
>
>
> [ ... ]
Acked-by: Maxime Ripard
Thanks!
Maxime
On Sun, 11 May 2025 22:31:10 +1200, Ryan Walklin wrote:
> From: Jernej Skrabec
>
> The Allwinner DE2 and DE3 display engine mixers are currently identified
> by a simple boolean flag. This will not scale to support additional DE
> variants.
>
> [ ... ]
Acked-by: Maxime Ripard
Thanks!
Maxime
On Sun, 11 May 2025 22:31:11 +1200, Ryan Walklin wrote:
> From: Jernej Skrabec
>
> Now that the DE variant can be selected by enum, take the oppportunity
> to factor out some common initialisation code to a separate function.
>
>
> [ ... ]
Acked-by: Maxime Ripard
Thanks!
Maxime
On Sun, 11 May 2025 22:31:13 +1200, Ryan Walklin wrote:
> From: Jernej Skrabec
>
> Use the new blender register lookup function where required in the layer
> commit and update code.
>
>
> [ ... ]
Acked-by: Maxime Ripard
Thanks!
Maxime
On Sun, 11 May 2025 22:31:12 +1200, Ryan Walklin wrote:
> From: Jernej Skrabec
>
> The DE2 and DE3 engines have a blender register range within the
> mixer engine register map, whereas the DE33 separates this out into
> a separate display group.
>
> [ ... ]
Acked-by: M
On Sun, 11 May 2025 22:31:20 +1200, Ryan Walklin wrote:
> From: Jernej Skrabec
>
> The H616 (and related SoC packages sharing the same die) carry the new
> DE33 display engine.
>
>
> [ ... ]
Acked-by: Maxime Ripard
Thanks!
Maxime
_control_get(dev, NULL);
> if (IS_ERR(mixer->reset)) {
> dev_err(dev, "Couldn't get our reset line\n");
> diff --git a/drivers/gpu/drm/sun4i/sun8i_mixer.h
> b/drivers/gpu/drm/sun4i/sun8i_mixer.h
> index 43c413052a22..d87d197610e1 100644
>
Hi Tomi,
On Wed, Apr 16, 2025 at 02:06:29PM +0300, Tomi Valkeinen wrote:
> Currently when the driver's probe is called, we do a full DSS reset. If
> the bootloader has set up a splash-screen, the reset will disable the
> video output, and after that it may still take time until the display is
> us
efault) EDID data.
>
>
> [ ... ]
Reviewed-by: Maxime Ripard
Thanks!
Maxime
Hi,
On Fri, Apr 25, 2025 at 01:26:57PM +0300, Cristian Ciocaltea wrote:
> Try to make use of YUV420 when computing the best output format and
> RGB cannot be supported for any of the available color depths.
>
> Signed-off-by: Cristian Ciocaltea
> ---
> drivers/gpu/drm/display/drm_hdmi_state_hel
On Fri, May 09, 2025 at 03:45:36PM +0300, Jani Nikula wrote:
> On Fri, 09 May 2025, Maxime Ripard wrote:
> > On Thu, May 08, 2025 at 05:27:21PM +0300, Jani Nikula wrote:
> >> On Mon, 05 May 2025, Anusha Srivatsa wrote:
> >> > On Mon, May 5, 2025 at 2:54 AM Maxime Ri
Hi,
On Wed, May 07, 2025 at 10:28:21AM +0200, Gerd Hoffmann wrote:
> Calling drm_dev_unplug() is the drm way to say the device
> is gone and can not be accessed any more.
>
> Cc: Michael S. Tsirkin
> Signed-off-by: Gerd Hoffmann
> Reviewed-by: Eric Auger
> Tested-by: Eric Auger
> ---
> drive
On Fri, 9 May 2025 15:53:48 +0200, Luca Ceresoli wrote:
> devm_drm_put_bridge() is a temporary workaround waiting for the panel
> bridge lifetime rework. Add a TODO entry to not forget it must be removed
> after such rework.
>
> Suggested-by: Maxime Ripard
>
> [ ... ]
Ac
->dev). However the panel_bridge allocation is not
>
> [ ... ]
Acked-by: Maxime Ripard
Thanks!
Maxime
mplify the code flow by removing now unnecessary gotos.
>
> [ ... ]
Acked-by: Maxime Ripard
Thanks!
Maxime
f they bind the devm removal action to a
>
> [ ... ]
Acked-by: Maxime Ripard
Thanks!
Maxime
y replacing the struct drm_bridge pointer with an
>
> [ ... ]
Acked-by: Maxime Ripard
Thanks!
Maxime
On Fri, 9 May 2025 15:53:40 +0200, Luca Ceresoli wrote:
> This is the new API for allocating DRM bridges.
>
> Signed-off-by: Luca Ceresoli
>
Acked-by: Maxime Ripard
Thanks!
Maxime
On Fri, 9 May 2025 15:53:33 +0200, Luca Ceresoli wrote:
> This is the new API for allocating DRM bridges.
>
> Signed-off-by: Luca Ceresoli
Acked-by: Maxime Ripard
Thanks!
Maxime
drm_bridge and its initialization, however it
>
> [ ... ]
Acked-by: Maxime Ripard
Thanks!
Maxime
On Fri, 9 May 2025 15:53:41 +0200, Luca Ceresoli wrote:
> This is the new API for allocating DRM bridges.
>
> Signed-off-by: Luca Ceresoli
>
Acked-by: Maxime Ripard
Thanks!
Maxime
mplify the code flow by removing now unnecessary gotos.
>
> [ ... ]
Acked-by: Maxime Ripard
Thanks!
Maxime
mplify the code flow by removing now unnecessary gotos.
>
> [ ... ]
Acked-by: Maxime Ripard
Thanks!
Maxime
mplify the code flow by removing now unnecessary gotos.
>
> [ ... ]
Acked-by: Maxime Ripard
Thanks!
Maxime
On Fri, 9 May 2025 15:53:35 +0200, Luca Ceresoli wrote:
> This is the new API for allocating DRM bridges.
>
> Signed-off-by: Luca Ceresoli
>
Acked-by: Maxime Ripard
Thanks!
Maxime
On Fri, 9 May 2025 15:53:34 +0200, Luca Ceresoli wrote:
> This is the new API for allocating DRM bridges.
>
> Signed-off-by: Luca Ceresoli
>
Acked-by: Maxime Ripard
Thanks!
Maxime
On Fri, 9 May 2025 15:53:32 +0200, Luca Ceresoli wrote:
> This is the new API for allocating DRM bridges.
>
> Signed-off-by: Luca Ceresoli
Acked-by: Maxime Ripard
Thanks!
Maxime
On Fri, 9 May 2025 15:53:31 +0200, Luca Ceresoli wrote:
> This is the new API for allocating DRM bridges.
>
> Signed-off-by: Luca Ceresoli
>
Acked-by: Maxime Ripard
Thanks!
Maxime
On Fri, May 09, 2025 at 03:53:30PM +0200, Luca Ceresoli wrote:
> This is the new API for allocating DRM bridges.
>
> Signed-off-by: Luca Ceresoli
Acked-by: Maxime Ripard
Maxime
signature.asc
Description: PGP signature
On Fri, May 09, 2025 at 03:53:29PM +0200, Luca Ceresoli wrote:
> This is the new API for allocating DRM bridges.
>
> Signed-off-by: Luca Ceresoli
Acked-by: Maxime Ripard
signature.asc
Description: PGP signature
R_ERR(C);
> )
>...
> -C->BR.funcs = FUNCS;
>
> Reviewed-by: Manikandan Muralidharan #
> microchip-lvds.c
> Reviewed-by: Douglas Anderson # parade-ps8640
> Tested-by: Douglas Anderson # parade-ps8640
> Signed-off-by: Luca Ceresoli
Acked-by: Maxime Ripard
Maxime
signature.asc
Description: PGP signature
On Thu, May 08, 2025 at 05:27:21PM +0300, Jani Nikula wrote:
> On Mon, 05 May 2025, Anusha Srivatsa wrote:
> > On Mon, May 5, 2025 at 2:54 AM Maxime Ripard wrote:
> >
> >> Hi Jani,
> >>
> >> On Tue, Apr 29, 2025 at 12:22:00PM +0300, Jani Nikula wrote:
On Tue, Apr 29, 2025 at 09:25:00AM -0700, John Stultz wrote:
> On Mon, Apr 28, 2025 at 7:52 AM Maxime Ripard wrote:
> > On Fri, Apr 25, 2025 at 12:39:40PM -0700, John Stultz wrote:
> > > To your larger point about policy, I do get the tension that you want
> > > to
Hi Jani,
On Tue, Apr 29, 2025 at 12:22:00PM +0300, Jani Nikula wrote:
> On Tue, 29 Apr 2025, Maxime Ripard wrote:
> > Hi Jani,
> >
> > On Mon, Apr 28, 2025 at 07:31:50PM +0300, Jani Nikula wrote:
> >> On Mon, 31 Mar 2025, Anusha Srivatsa wrote:
> >> >
On Mon, Apr 28, 2025 at 05:25:16PM +0200, Luca Ceresoli wrote:
> Hi Maxime,
>
> On Mon, 28 Apr 2025 13:39:23 +0200
> Maxime Ripard wrote:
>
> > On Thu, Apr 24, 2025 at 10:05:49PM +0200, Luca Ceresoli wrote:
> > > This is the new API for allocating DRM bridges.
On Tue, Apr 29, 2025 at 02:41:42PM +0200, Louis Chauvet wrote:
> Le 29/04/2025 à 11:27, Louis Chauvet a écrit :
> >
> > On Thu, 24 Apr 2025 20:59:07 +0200, Luca Ceresoli wrote:
> > > devm_drm_bridge_alloc() [0] is the new API to allocate and initialize a
> > > DRM
> > > bridge, and the only one s
On Wed, Apr 30, 2025 at 10:21:48AM +0200, Louis Chauvet wrote:
>
>
> Le 29/04/2025 à 16:42, Dmitry Baryshkov a écrit :
> > On Tue, Apr 29, 2025 at 11:27:51AM +0200, Louis Chauvet wrote:
> > >
> > > On Thu, 24 Apr 2025 20:59:07 +0200, Luca Ceresoli wrote:
> > > > devm_drm_bridge_alloc() [0] is th
ELPER from DRM_DEBUG_DP_MST_TOPOLOGY_REFS
Karol Wachowski (1):
accel/ivpu: Correct DCT interrupt handling
Maxime Ripard (1):
drm/tests: shmem: Fix memleak
Philipp Stanner (1):
drm/nouveau: Fix WARN_ON in nouveau_fence_context_kill()
Russell Cloran (1):
drm/mipi-dbi: Fix blanking
On Tue, Apr 15, 2025 at 07:01:25PM +0300, Dmitry Baryshkov wrote:
> On 14/04/2025 17:58, Maxime Ripard wrote:
> > On Mon, Apr 07, 2025 at 06:11:03PM +0300, Dmitry Baryshkov wrote:
> > > +static void drm_connector_hdmi_cec_adapter_unregister(struct
> > &g
On Tue, Apr 15, 2025 at 12:03:23PM +0300, Dmitry Baryshkov wrote:
> On 14/04/2025 17:47, Maxime Ripard wrote:
> > Hi,
> >
> > On Mon, Apr 07, 2025 at 06:11:01PM +0300, Dmitry Baryshkov wrote:
> > > In order to make sure that CEC adapters or notifiers are unregistered
On Tue, Apr 15, 2025 at 12:10:06PM +0300, Dmitry Baryshkov wrote:
> On 14/04/2025 17:52, Maxime Ripard wrote:
> > Hi,
> >
> > On Mon, Apr 07, 2025 at 06:11:00PM +0300, Dmitry Baryshkov wrote:
> > > +/**
> > > + * struct drm_connector_ce
On Mon, 14 Apr 2025 22:32:59 -0700, Russell Cloran wrote:
> On r6x2b6x2g6x2 displays not enough blank data is sent to blank the
> entire screen. When support for these displays was added, the dirty
> function was updated to handle the different amount of data, but
> blanking was not, and remained h
On Tue, 08 Apr 2025 16:07:58 +0200, Maxime Ripard wrote:
> The drm_gem_shmem_test_get_pages_sgt() gets a scatter-gather table using
> the drm_gem_shmem_get_sg_table() function and rightfully calls
> sg_free_table() on it. However, it's also supposed to kfree() the
> returned sg_t
nsuring panel pointer is valid and can be usable till the last
> > reference is put.
> >
> > Reviewed-by: Luca Ceresoli
> > Reviewed-by: Maxime Ripard
> > Signed-off-by: Anusha Srivatsa
> >
> > ---
> > v4: Add refcounting documentation in this p
On Mon, Apr 28, 2025 at 05:24:57PM +0200, Luca Ceresoli wrote:
> Hi Maxime, other DRM maintainers,
>
> On Thu, 24 Apr 2025 20:59:07 +0200
> Luca Ceresoli wrote:
>
> > devm_drm_bridge_alloc() [0] is the new API to allocate and initialize a DRM
> > bridge, and the only one supported from now on. I
Hi John,
On Fri, Apr 25, 2025 at 12:39:40PM -0700, John Stultz wrote:
> On Thu, Apr 24, 2025 at 11:58 PM Maxime Ripard wrote:
> > On Thu, Apr 24, 2025 at 05:13:47PM -0700, John Stultz wrote:
> > > On Thu, Apr 24, 2025 at 1:34 AM Maxime Ripard wrote:
> > > > I appre
On Thu, Apr 24, 2025 at 10:05:49PM +0200, Luca Ceresoli wrote:
> This is the new API for allocating DRM bridges.
>
> The devm lifetime management of this driver is peculiar. The underlying
> device for the panel_bridge is the panel, and the devm lifetime is tied the
> panel device (panel->dev). Ho
Hi,
On Mon, Apr 07, 2025 at 06:29:06PM +0200, Maxime Ripard wrote:
> Hi,
>
> This series is the follow-up of the discussion that John and I had some
> time ago here:
>
> https://lore.kernel.org/all/candhncqujn6bh3kxkf65bwitylvqsd9892-xtfdhhqqyrro...@mail.gmail.com/
>
>
On Mon, Apr 14, 2025 at 12:43:44PM -0500, Andrew Davis wrote:
> On 4/11/25 3:26 PM, T.J. Mercier wrote:
> > On Mon, Apr 7, 2025 at 9:29 AM Maxime Ripard wrote:
> > >
> > > Some reserved memory regions might have particular memory setup or
> > > attributes that
Hi,
On Thu, Apr 24, 2025 at 06:51:00PM +0200, Ulf Hansson wrote:
> On Thu, 17 Apr 2025 at 18:19, Michal Wilczynski
> wrote:
> > On 4/16/25 16:48, Rafael J. Wysocki wrote:
> > > On Wed, Apr 16, 2025 at 3:32 PM Michal Wilczynski
> > > wrote:
> > >>
> > >> On 4/15/25 18:42, Rafael J. Wysocki wrote:
On Thu, Apr 24, 2025 at 05:13:47PM -0700, John Stultz wrote:
> On Thu, Apr 24, 2025 at 1:34 AM Maxime Ripard wrote:
> > On Tue, Apr 22, 2025 at 12:19:39PM -0700, Jared Kangas wrote:
> > > @@ -22,6 +22,7 @@
> > > #include
> > > #include
> > >
Hi Jared,
Thanks for working on this
On Tue, Apr 22, 2025 at 12:19:39PM -0700, Jared Kangas wrote:
> The CMA heap's name in devtmpfs can vary depending on how the heap is
> defined. Its name defaults to "reserved", but if a CMA area is defined
> in the devicetree, the heap takes on the devicetree
Hi,
On Wed, Apr 09, 2025 at 04:50:34PM +0200, Luca Ceresoli wrote:
> Document in detail the DRM bridge allocation and refcounting process based
> on the recently introduced devm_drm_bridge_alloc().
>
> Signed-off-by: Luca Ceresoli
There's a typo in your commit title.
> ---
>
> Changes in v7:
1 - 100 of 3527 matches
Mail list logo
