-Original Message-
From: Wajdeczko, Michal
Sent: Friday, March 14, 2025 10:02 AM
To: Cavitt, Jonathan ; intel...@lists.freedesktop.org
Cc: Gupta, saurabhg ; Zuo, Alex ;
joonas.lahti...@linux.intel.com; Brost, Matthew ;
Zhang, Jianxun ; Lin, Shuicheng
; dri-devel@lists.freedesktop.org;
On Mon, 10 Mar 2025 12:56:36 +0800, WangYuli wrote:
> The description for CONFIG_LCD_TDO24M has redundant whitespace.
> Trim it to keep the code tidy.
>
>
Applied, thanks!
[1/1] backlight: tdo24m: Eliminate redundant whitespace
commit: c9fe785857fdfc780d49b60b5bb77ca21a51411b
--
Lee Jone
On 3/15/2025 12:04 AM, Rob Clark wrote:
> From: Rob Clark
>
> IB_SIZE is only b0..b19. Starting with a6xx gen3, additional fields
> were added above the IB_SIZE. Accidentially setting them can cause
> badness. Fix this by properly defining the CP_INDIRECT_BUFFER packet
> and using the generate
Hi,
On Fri, Mar 14, 2025 at 11:31:13AM +0100, Luca Ceresoli wrote:
> This series improves the way DRM bridges are allocated and initialized and
> makes them reference-counted. The goal of reference counting is to avoid
> use-after-free by drivers which got a pointer to a bridge and keep it
> store
On Fri, Mar 14, 2025 at 12:57:27PM +0100, Josef Luštický wrote:
> On Mon, Mar 10, 2025 at 7:33 PM Alex Lanzano wrote:
> >
> > On Fri, Mar 07, 2025 at 10:25:18AM +0100, Josef Luštický wrote:
> > > Ok, I'll implement the change and post it for a review.
> > > About the property naming, I tend to nam
Hi,
On Fri, Mar 14, 2025 at 3:42 PM Wolfram Sang
wrote:
>
> From: Phong Hoang
>
> Add a check to the very first register access function when attaching a
> bridge device, so we can bail out if I2C communication does not work.
>
> Signed-off-by: Phong Hoang
> Signed-off-by: Jacopo Mondi
> Revie
t; > > + size_t container_offset;
> > >
> > > While storing the offset obviously works, and that's what I had
> > > implemented in my latest bridge refcounting series, after some
> > > discussion with Maxime we agreed storing a container pointer instead of
> > > the offset is cleaner. I think it would be good here as well.
> > >
> > > See:
> > >
> https://lore.kernel.org/lkml/20250227-macho-convivial-tody-cea7dc@houat/
> > >
> >
> > so just void *container instead of size_t container_offset.
>
> Exactly. You can have a look at the patch I sent earlier today:
>
> https://lore.kernel.org/lkml/20250314-drm-bridge-refcount-v7-2-152571f8c...@bootlin.com/
>
>
This helps. Thanks
Anusha
> Luca
>
> --
> Luca Ceresoli, Bootlin
> Embedded Linux and Kernel engineering
> https://bootlin.com
>
>
On Fri, 14 Mar 2025 11:31:17 +0100, Luca Ceresoli wrote:
> drm_bridge_attach() adds the bridge to the encoder chain, so take a
> reference for that. Vice versa in drm_bridge_detach().
>
> Signed-off-by: Luca Ceresoli
>
>
> [ ... ]
Reviewed-by: Maxime Ripard
Thanks!
Maxime
From: Phong Hoang
Add a check to the very first register access function when attaching a
bridge device, so we can bail out if I2C communication does not work.
Signed-off-by: Phong Hoang
Signed-off-by: Jacopo Mondi
Reviewed-by: Laurent Pinchart
Signed-off-by: Wolfram Sang
---
Build tested o
On Fri, Mar 14, 2025 at 1:07 PM Akhil P Oommen wrote:
>
> On 3/15/2025 12:04 AM, Rob Clark wrote:
> > From: Rob Clark
> >
> > IB_SIZE is only b0..b19. Starting with a6xx gen3, additional fields
> > were added above the IB_SIZE. Accidentially setting them can cause
> > badness. Fix this by prop
Starting with commit ec3e00b4ee27 ("drm/i915: stop registering if
drm_dev_register() fails"), we return from i915_driver_register()
immediately if drm_dev_register() fails, skipping remaining registration
steps, and continue only with remaining probe steps. However, the
_unregister() counterpart c
On Wed, Feb 26, 2025 at 03:19:14PM +0100, Maud Spierings wrote:
> Add the bindings that describe a GOcontroll Moduline module slot. This
> slot provides all the interfaces to interface with a Moduline compatible
> IO module. The actual module is not reasonable to describe as it can be
> swapped at
Commit f67986b0119c04 ("drm/i915/pxp: Promote pxp subsystem to top-level
of i915") added PXP initialization to driver probe path, but didn't add a
respective PXP cleanup on probe error. That lack of cleanup seems
harmless as long as PXP is still unused and idle when a probe failure
occurs and erro
Starting with commit ec3e00b4ee27 ("drm/i915: stop registering if
drm_dev_register() fails"), we return from i915_driver_register()
immediately if drm_dev_register() fails, skipping remaining registration
steps, and continue only with remaining probe steps. However, the
_unregister() counterpart c
On Fri, 14 Mar 2025 11:31:22 +0100, Luca Ceresoli wrote:
> The bridge returned by drm_bridge_chain_get_first_bridge() is
> refcounted. Put it when done.
>
> Signed-off-by: Luca Ceresoli
>
>
> [ ... ]
Reviewed-by: Maxime Ripard
Thanks!
Maxime
Panfrost does not support uncached mappings, so flag them properly. Also
flag the pages that are mapped as response to a page fault as cached.
Signed-off-by: Boris Brezillon
Signed-off-by: Ariel D'Alessandro
Reviewed-by: AngeloGioacchino Del Regno
Reviewed-by: Steven Price
---
drivers/gpu/dr
On Thu, 06 Mar 2025 19:11:12 +0100, Konrad Dybcio wrote:
> A set of not quite related bindings warnings fixes.
>
>
Applied, thanks!
[05/11] arm64: dts: qcom: sdx75: Fix up the USB interrupt description
commit: 6810ecd57eb4ba9e09bac851d5b9d56c5e5acc1a
[06/11] arm64: dts: qcom: sdx75: R
From: Dmitry Baryshkov
Describe MIPI DSI controller present on Qualcomm SAR2130P platform.
Signed-off-by: Dmitry Baryshkov
Reviewed-by: Krzysztof Kozlowski
---
Documentation/devicetree/bindings/display/msm/dsi-controller-main.yaml | 2 ++
1 file changed, 2 insertions(+)
diff --git
a/Documen
On Thu, 13 Mar 2025 14:09:24 -0700
Jacob Keller wrote:
> On 3/13/2025 9:36 AM, H. Peter Anvin wrote:
> > On March 13, 2025 9:24:38 AM PDT, Yury Norov wrote:
> >> On Wed, Mar 12, 2025 at 05:09:16PM -0700, H. Peter Anvin wrote:
> >>> On March 12, 2025 4:56:31 PM PDT, Jacob Keller
> >>> wrote
From: Rob Clark
IB_SIZE is only b0..b19. Starting with a6xx gen3, additional fields
were added above the IB_SIZE. Accidentially setting them can cause
badness. Fix this by properly defining the CP_INDIRECT_BUFFER packet
and using the generated builder macro to ensure unintended bits are not
se
Hi
On Fri, Mar 14, 2025 at 12:47:16AM -0400, Anusha Srivatsa wrote:
> Move away from using deprecated API and use _multi
> variants if available. Use mipi_dsi_msleep()
> and mipi_dsi_usleep_range() instead of msleep()
> and usleep_range() respectively.
>
> Used Coccinelle to find the _multi varia
On Fri, 14 Mar 2025 11:31:24 +0100, Luca Ceresoli wrote:
> Allow this bridge to be removable without dangling pointers and
> use-after-free, together with proper use of drm_bridge_get() and _put() by
> consumers.
>
> Signed-off-by: Luca Ceresoli
>
> [ ... ]
Reviewed-by: Maxime Ripard
Thanks!
On Fri, 14 Mar 2025 11:31:20 +0100, Luca Ceresoli wrote:
> The bridge returned by drm_bridge_chain_get_first_bridge() is
> refcounted. Put it when done. Use a scope-based free action to catch all
> the code paths.
>
> Signed-off-by: Luca Ceresoli
>
> [ ... ]
Reviewed-by: Maxime Ripard
Thanks!
On Fri, Mar 14, 2025 at 11:31:19AM +0100, Luca Ceresoli wrote:
> drm_bridge_chain_get_first_bridge() returns a bridge pointer that the
> caller could hold for a long time. Increment the refcount of the returned
> bridge and document it must be put by the caller.
>
> Signed-off-by: Luca Ceresoli
>
On Fri, Mar 14, 2025 at 11:31:18AM +0100, Luca Ceresoli wrote:
> Many functions get a drm_bridge pointer, only use it in the function body
> (or a smaller scope such as a loop body), and don't store it. In these
> cases they always need to drm_bridge_put() it before returning (or exiting
> the scop
On Fri, 14 Mar 2025 11:31:14 +0100, Luca Ceresoli wrote:
> Add a macro to allocate and initialize a DRM bridge embedded within a
> private driver struct.
>
> Compared to current practice, which is based on [devm_]kzalloc() allocation
> followed by open-coded initialization of fields, this allows t
On Fri, 14 Mar 2025 11:31:16 +0100, Luca Ceresoli wrote:
> drm_bridge_add() adds the bridge to the global bridge_list, so take a
> reference for that. Vice versa in drm_bridge_remove().
>
> Signed-off-by: Luca Ceresoli
>
>
> [ ... ]
Reviewed-by: Maxime Ripard
Thanks!
Maxime
On Fri, 14 Mar 2025 11:36:49 +0200, Dmitry Baryshkov wrote:
> It is common for the DisplayPort bridges to implement audio support. In
> preparation to providing a generic framework for DP audio, add
> corresponding interface to struct drm_bridge. As suggested by Maxime
> for now this is mostly c&p
MediaTek MT8192 SoC has an ARM Mali-G57 MC5 GPU (Valhall-JM). Now that
Panfrost supports AARCH64_4K page table format, let's enable it on this
SoC.
Running glmark2-es2-drm [0] benchmark, reported the same performance
score on both modes Mali LPAE (LEGACY) vs. AARCH64_4K, before and after
this comm
As done in panthor, define and use these GPU_MMU_FEATURES_* macros,
which makes code easier to read and reuse.
Signed-off-by: Ariel D'Alessandro
Reviewed-by: Boris Brezillon
Reviewed-by: Steven Price
---
drivers/gpu/drm/panfrost/panfrost_mmu.c | 6 --
drivers/gpu/drm/panfrost/panfrost_reg
MediaTek MT8188 SoC has an ARM Mali-G57 MC3 GPU (Valhall-JM), which
constantly faults with the current panfrost support.
For instance, running `glmark2-es2-drm` benchmark test:
```
[ 79.617461] panfrost 1300.gpu: js fault, js=1, status=JOB_BUS_FAULT,
head=0xaadc380, tail=0xaadc380
[ 80.11
On Fri, Mar 14, 2025 at 09:59:36AM +0200, Dmitry Baryshkov wrote:
> On Fri, Mar 14, 2025 at 08:45:17AM +0100, Maxime Ripard wrote:
> > On Fri, Mar 14, 2025 at 07:52:35AM +0200, Dmitry Baryshkov wrote:
> > > On Fri, Mar 14, 2025 at 08:50:29AM +0800, Andy Yan wrote:
> > > > At 2025-03-13 19:55:33, "M
Currently, Panfrost only supports MMU configuration in "LEGACY" (as
Bifrost calls it) mode, a (modified) version of LPAE "Large Physical
Address Extension", which in Linux we've called "mali_lpae".
This commit adds support for conditionally enabling AARCH64_4K page
table format. To achieve that, a
On 3/7/2025 1:41 AM, Dan Carpenter wrote:
These are u64 variables that come from the user via
qaic_attach_slice_bo_ioctl(). Use check_add_overflow() to ensure that
the math doesn't have an integer wrapping bug.
Cc: sta...@vger.kernel.org
Fixes: ff13be830333 ("accel/qaic: Add datapath")
Signed-o
On 3/7/2025 1:41 AM, Dan Carpenter wrote:
These are u64 variables that come from the user via
qaic_attach_slice_bo_ioctl(). Use check_add_overflow() to ensure that
the math doesn't have an integer wrapping bug.
Cc: sta...@vger.kernel.org
Fixes: ff13be830333 ("accel/qaic: Add datapath")
Signed-o
On 3/6/2025 10:19 AM, Jeff Hugo wrote:
From: Jeffrey Hugo
When slicing a BO, we need to iterate through the BO's sgt to find the
right pieces to construct the slice. Some of the data types chosen for
this process are incorrectly too small, and can overflow. This can
result in the incorrect slic
On Fri, Mar 14, 2025 at 02:46:09PM +0100, Maxime Ripard wrote:
> On Tue, Mar 11, 2025 at 06:28:50PM +0200, Dmitry Baryshkov wrote:
> > On Tue, Mar 11, 2025 at 09:07:10AM +0100, Maxime Ripard wrote:
> > > On Mon, Mar 10, 2025 at 10:18:04PM +0200, Dmitry Baryshkov wrote:
> > > > On Mon, Mar 10, 2025
On Wed, 26 Feb 2025 15:19:11 +0100, Maud Spierings wrote:
> Add inital support for 2 variants of the Moduline Display controller.
> This system is powered by the Ka-Ro Electronics tx8p-ml81 COM, which
> features an imx8mp SoC.
>
>
Applied to
https://git.kernel.org/pub/scm/linux/kernel/git/br
On Wed, Mar 05, 2025 at 05:59:47PM -0500, Lyude Paul wrote:
> This commit adds bindings for implementing vblank support for a driver's
> CRTCs. These bindings are optional, to account for the fact that not all
> drivers have dedicated hardware vblanks.
Do we really have drivers not having a vblank
On Fri, Mar 14, 2025 at 02:47:53PM +0100, Maxime Ripard wrote:
> On Tue, Mar 11, 2025 at 09:46:39PM +0200, Dmitry Baryshkov wrote:
> > On Tue, Mar 11, 2025 at 04:55:17PM +0100, Maxime Ripard wrote:
> > > Hi,
> > >
> > > I think the first thing we need to address is that we will need to
> > > diffe
Currently the TTM pool shrinker ensures it frees at least something every
time it is invoked, but it also lies to the core a bit on how hard it
tried.
For example core will ask it to free SHRINK_BATCH pages but the shrinker
can, due how it walks the LRU list of pools, free just a single page and
s
On Thu, Mar 13, 2025 at 5:58 PM Benjamin Tissoires wrote:
>
> skeletons are good for documentation, but not really for code review as
> they can not compile.
>
> You should make this patch part of a documentation in
> Documentation/hid/, and squash it with the next one (having a minimal
> full dri
Le 14/03/2025 à 13:11, Vignesh Raman a écrit :
Hi Louis,
On 13/03/25 19:30, Louis Chauvet wrote:
Le 13/03/2025 à 11:45, Vignesh Raman a écrit :
Hi Maintainers,
Hi Vignesh,
Thanks for the report.
On my setup, this test passed, and the others are skipped.
I think the issue on this spe
Hi,
On Thu, Mar 13, 2025 at 9:47 PM Anusha Srivatsa wrote:
>
> @@ -181,24 +162,15 @@ static int r63353_panel_prepare(struct drm_panel *panel)
> static int r63353_panel_deactivate(struct r63353_panel *rpanel)
> {
> struct mipi_dsi_device *dsi = rpanel->dsi;
> - struct device *dev =
On Tue, Mar 11, 2025 at 08:59:00PM +0200, Cristian Ciocaltea wrote:
> >> +static int
> >> +hdmi_compute_config(const struct drm_connector *connector,
> >> + struct drm_connector_state *conn_state,
> >> + const struct drm_display_mode *mode)
> >> +{
> >> + unsigned int max
On Mon, 10 Mar 2025 15:28:02 -0400, Alyssa Rosenzweig wrote:
> Apple GPUs support non-linear "GPU-tiled" image layouts. Add modifiers
> for these layouts. Mesa requires these modifiers to share non-linear
> buffers across processes, but no other userspace or kernel support is
> required/expected.
On Wed, Mar 12, 2025 at 12:54:51AM +0200, Cristian Ciocaltea wrote:
> On 3/11/25 6:17 PM, Maxime Ripard wrote:
> > On Tue, Mar 11, 2025 at 12:57:38PM +0200, Cristian Ciocaltea wrote:
> >> Provide tests to verify that drm_atomic_helper_connector_hdmi_check()
> >> helper behaviour when using YUV420 o
On Tue, Mar 11, 2025 at 09:46:39PM +0200, Dmitry Baryshkov wrote:
> On Tue, Mar 11, 2025 at 04:55:17PM +0100, Maxime Ripard wrote:
> > Hi,
> >
> > I think the first thing we need to address is that we will need to
> > differentiate between HDMI 1.4 devices and HDMI 2.0.
> >
> > It applies to YUV4
On Tue, Mar 11, 2025 at 06:28:50PM +0200, Dmitry Baryshkov wrote:
> On Tue, Mar 11, 2025 at 09:07:10AM +0100, Maxime Ripard wrote:
> > On Mon, Mar 10, 2025 at 10:18:04PM +0200, Dmitry Baryshkov wrote:
> > > On Mon, Mar 10, 2025 at 03:51:53PM +0100, Maxime Ripard wrote:
> > > > On Sun, Mar 09, 2025
Hi,
On Wed, Mar 12, 2025 at 03:40:55PM +, David Turner wrote:
> From: Stefan Wahren
>
> drm_atomic_helper_connector_hdmi_hotplug() must be called
> regardless of the connection status, otherwise the HDMI audio
> disconnect event won't be notified. Also update the comment on
> drm_atomic_hel
From: Dmitry Baryshkov
As pointed out by Laurent, OP bits are supposed to describe operations.
Split DRM_BRIDGE_OP_HDMI_AUDIO from DRM_BRIDGE_OP_HDMI instead of
overloading DRM_BRIDGE_OP_HDMI.
Signed-off-by: Dmitry Baryshkov
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/bridge/lontium-l
On Wed, Mar 05, 2025 at 05:59:23PM -0500, Lyude Paul wrote:
> +unsafe extern "C" fn encoder_destroy_callback(
> +encoder: *mut bindings::drm_encoder,
> +) {
> +// SAFETY: DRM guarantees that `encoder` points to a valid initialized
> `drm_encoder`.
> +unsafe { bindings::drm_encoder_clea
> + size_t container_offset;
> >
> > While storing the offset obviously works, and that's what I had
> > implemented in my latest bridge refcounting series, after some
> > discussion with Maxime we agreed storing a container pointer instead of
> > th
On Wed, 2025-03-12 at 22:04 +0100, Thomas Hellström wrote:
> On device unbind, migrate exported bos, including pagemap bos to
> system. This allows importers to take proper action without
> disruption. In particular, SVM clients on remote devices may
> continue as if nothing happened, and can chose
The GPU scheduler's comments refer to a "thread" at various places.
Those are leftovers from commit a6149f039369 ("drm/sched: Convert drm
scheduler to use a work queue rather than kthread").
Replace all references to kthreads.
Signed-off-by: Philipp Stanner
Reviewed-by: Tvrtko Ursulin
---
Chang
On Fri, Mar 14, 2025 at 11:01:36AM +0100, Jacek Lawrynowicz wrote:
> +* Firmware files that affect the User API (UAPI) shall not introduce
> + changes that break existing userspace programs. Updates to such firmware
> + must ensure backward compatibility with existing userspace applications.
> +
On Wed, Mar 05, 2025 at 05:59:35PM -0500, Lyude Paul wrote:
> An optional trait method for implementing a CRTC's atomic state check.
>
> Signed-off-by: Lyude Paul
>
> ---
> V3:
> * Document uses of ManuallyDrop
>
> Signed-off-by: Lyude Paul
> ---
> rust/kernel/drm/kms/atomic.rs | 1 -
> rust
On Wed, Mar 05, 2025 at 05:59:37PM -0500, Lyude Paul wrote:
> Optional trait method for implementing a plane's atomic_check().
>
> Signed-off-by: Lyude Paul
>
> ---
> V3:
> * Document ManuallyDrop uses better
>
> Signed-off-by: Lyude Paul
> ---
> rust/kernel/drm/kms/plane.rs | 53
Hi Louis,
On 13/03/25 19:30, Louis Chauvet wrote:
Le 13/03/2025 à 11:45, Vignesh Raman a écrit :
Hi Maintainers,
Hi Vignesh,
Thanks for the report.
On my setup, this test passed, and the others are skipped.
I think the issue on this specific test may be due to performance (seems
to be
Hi,
On Wed, Mar 05, 2025 at 05:59:30PM -0500, Lyude Paul wrote:
> Since we allow drivers to have multiple implementations of DriverConnector
> and DriverConnectorState (in C, the equivalent of this is having multiple
> structs which embed drm_connector) - there are some situations we will run
> in
On Mon, Mar 10, 2025 at 7:33 PM Alex Lanzano wrote:
>
> On Fri, Mar 07, 2025 at 10:25:18AM +0100, Josef Luštický wrote:
> > Ok, I'll implement the change and post it for a review.
> > About the property naming, I tend to name it something like
> > "inverted-reset-gpio-fixed" to denote that it is a
On Wed, Mar 05, 2025 at 05:59:28PM -0500, Lyude Paul wrote:
> Now that we have more then one way to refer to connectors, we also want to
> ensure that any methods which are common to any kind of connector type can
> be used on all connector representations. This is where RawConnector and
> RawConne
On Wed, Mar 05, 2025 at 05:59:26PM -0500, Lyude Paul wrote:
> A simple binding for drm_add_modes_noedid() using the ConnectorGuard type
> we just added.
>
> Signed-off-by: Lyude Paul
> ---
> rust/bindings/bindings_helper.h | 1 +
> rust/kernel/drm/kms/connector.rs | 11 +++
> 2 files c
On Wed, Mar 05, 2025 at 05:59:25PM -0500, Lyude Paul wrote:
> Next up is filling out some of the basic connector hotplugging callbacks -
> which we'll need for setting up the fbdev helpers for KMS devices. Note
> that connector hotplugging in DRM follows a BFL scheme: pretty much all
> probing is p
On Tue, 11 Mar 2025 01:49:50 +, li...@treblig.org wrote:
> From: "Dr. David Alan Gilbert"
>
> The pcf50633 was used as part of the OpenMoko devices but
> the support for its main chip was recently removed in:
> commit 61b7f8920b17 ("ARM: s3c: remove all s3c24xx support")
>
> See https://lore
Allow this bridge to be removable without dangling pointers and
use-after-free, together with proper use of drm_bridge_get() and _put() by
consumers.
Signed-off-by: Luca Ceresoli
---
Changes in v7: none
Changed in v6:
- Update to use devm_drm_bridge_alloc(), remove .destroy
This patch was ad
On Wed, Mar 05, 2025 at 05:59:20PM -0500, Lyude Paul wrote:
> We start off by introducing wrappers for the first important type of mode
> object: a DRM display connector. This introduces Connector DriverConnector> and ConnectorState. Both
> DriverConnector and DriverConnectorState must be implement
drm_bridge_chain_get_first_bridge() returns a bridge pointer that the
caller could hold for a long time. Increment the refcount of the returned
bridge and document it must be put by the caller.
Signed-off-by: Luca Ceresoli
---
This patch was added in v7.
---
include/drm/drm_bridge.h | 7 +-
On Wed, Mar 05, 2025 at 05:59:19PM -0500, Lyude Paul wrote:
> The KMS API has a very consistent idea of a "mode config object", which
> includes any object with a drm_mode_object struct embedded in it. These
> objects have their own object IDs which DRM exposes to userspace, and we
> introduce the
Allow this bridge to be removable without dangling pointers and
use-after-free, together with proper use of drm_bridge_get() and _put() by
consumers.
Signed-off-by: Luca Ceresoli
---
This patch was added in v7.
---
drivers/gpu/drm/bridge/samsung-dsim.c | 7 +++
1 file changed, 3 insertions
The bridge returned by drm_bridge_chain_get_first_bridge() is
refcounted. Put it when done.
Signed-off-by: Luca Ceresoli
---
This patch was added in v7.
---
drivers/gpu/drm/drm_probe_helper.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/drm_probe_helper.c
b/drivers/gpu/
drm_bridge_attach() adds the bridge to the encoder chain, so take a
reference for that. Vice versa in drm_bridge_detach().
Signed-off-by: Luca Ceresoli
---
Changes in v7:
- in v6 this was part of "drm/bridge: add support for refcounted DRM
bridges", now split to a separate patch
---
drivers/
The bridge returned by drm_bridge_chain_get_first_bridge() is
refcounted. Put it when done.
Signed-off-by: Luca Ceresoli
---
Note: I suspect most or all of the involved functions here could just
receive the encoder instead of the first bridge in the chain, and then walk
the encoder chain on the
The bridge returned by drm_bridge_chain_get_first_bridge() is
refcounted. Put it when done. Use a scope-based free action to catch all
the code paths.
Signed-off-by: Luca Ceresoli
---
This patch was added in v7.
---
drivers/gpu/drm/mxsfb/lcdif_kms.c | 3 ++-
1 file changed, 2 insertions(+), 1
Add a macro to allocate and initialize a DRM bridge embedded within a
private driver struct.
Compared to current practice, which is based on [devm_]kzalloc() allocation
followed by open-coded initialization of fields, this allows to have a
common and explicit API to allocate and initialize DRM bri
drm_bridge_add() adds the bridge to the global bridge_list, so take a
reference for that. Vice versa in drm_bridge_remove().
Signed-off-by: Luca Ceresoli
---
Changes in v7:
- in v6 this was part of "drm/bridge: add support for refcounted DRM
bridges", now split to a separate patch
---
driver
On Sun, Mar 9, 2025 at 8:36 PM wrote:
> From: "Dr. David Alan Gilbert"
>
> The pcf50633 was used as part of the OpenMoko devices but
> the support for its main chip was recently removed in:
> commit 61b7f8920b17 ("ARM: s3c: remove all s3c24xx support")
>
> See https://lore.kernel.org/all/Z8z236h
The kthread header doesn't need to be included anymore. It's a relict
from commit a6149f039369 ("drm/sched: Convert drm scheduler to use a
work queue rather than kthread").
Remove the unneeded includes.
Signed-off-by: Philipp Stanner
Reviewed-by: Tvrtko Ursulin
---
drivers/gpu/drm/scheduler/sc
Hi,
On 3/4/2025 6:06 PM, Simona Vetter wrote:
> Hi Jacek!
>
> Bit late reply, was sick last week and still recovering from missed mails.
>
> On Thu, Feb 20, 2025 at 11:50:10AM +0100, Jacek Lawrynowicz wrote:
>> On 2/19/2025 10:01 PM, Dave Airlie wrote:
>>> I'd just like to remind everyone of the
The guidelines mention that firmware updates can't break the kernel,
but it doesn't state directly that they can't break userspace programs.
Make it explicit that firmware updates cannot break UAPI.
Signed-off-by: Jacek Lawrynowicz
---
.../driver-api/firmware/firmware-usage-guidelines.rst
Hi Lyude,
First off, thanks for keeping up with this series.
I'm quite familiar with Rust in userspace, but not so much in the
kernel, so I might have stupid questions or points, sorry I advance :)
On Wed, Mar 05, 2025 at 05:59:18PM -0500, Lyude Paul wrote:
> This commit adds some traits for reg
On Thu, 2025-03-13 at 11:07 +0100, Christian König wrote:
> Am 13.03.25 um 10:30 schrieb Philipp Stanner:
> > The documentation for drm_sched_job_arm() and especially
> > drm_sched_job_cleanup() does not make it very clear why
> > drm_sched_job_arm() is a point of no return, which it indeed is.
> >
From: Dmitry Baryshkov
The MSM DisplayPort driver implements several HDMI codec functions
in the driver, e.g. it manually manages HDMI codec device registration,
returning ELD and plugged_cb support. In order to reduce code
duplication reuse drm_hdmi_audio_* helpers and drm_bridge_connector
integ
Reuse existing code plumbing HDMI audio support and the existing HDMI
audio helpers that register HDMI codec device and plumb in the
DisplayPort audio interfaces to be handled by the drm_bridge_connector.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/display/drm_bridge_connector.c | 117 ++
It is common for the DisplayPort bridges to implement audio support. In
preparation to providing a generic framework for DP audio, add
corresponding interface to struct drm_bridge. As suggested by Maxime
for now this is mostly c&p of the corresponding HDMI audio API.
Signed-off-by: Dmitry Baryshko
Hi
Am 14.03.25 um 07:09 schrieb oushixiong1...@163.com:
From: Shixiong Ou
Using device_create_with_groups() to simplify creation and removal.
Same as commit 1083a7be4504 ("tty: Use static attribute groups for
sysfs entries").
Signed-off-by: Shixiong Ou
Acked-by: Thomas Zimmermann
with mi
The mediatek display driver fails to probe on mt8173-elm-hana and
mt8183-kukui-jacuzzi-juniper-sku16 in v6.14-rc4 due to missing PHY
configurations.
Enable the following PHY drivers for MediaTek platforms:
- CONFIG_PHY_MTK_HDMI=y for HDMI display
- CONFIG_PHY_MTK_MIPI_DSI=y for DSI display
Signed
Hi
Am 13.03.25 um 21:43 schrieb Dario Binacchi:
Hi All,
On Thu, Mar 13, 2025 at 3:40 PM Thomas Zimmermann wrote:
Hi
Am 13.03.25 um 15:25 schrieb Luca Ceresoli:
When aperture_remove_all_conflicting_devices() fails, the current code
returns without going through the rollback actions at the en
LAVA was recently patched [1] with a fix on how parameters are parsed in
`lava-test-case`, so we don't need to repeat quotes to send the
arguments properly to it. Uprev mesa to fix this issue.
[1] https://gitlab.com/lava/lava/-/commit/18c9cf79
Signed-off-by: Vignesh Raman
---
drivers/gpu/drm/ci
Uprev mesa to fix lava-test-case argument parsing. LAVA recently fixed
parameter parsing in `lava-test-case` [1], eliminating the need for
repeated quotes in arguments.
Uprev IGT to the latest version. Also update expectation files.
The mediatek display driver fails to probe on mt8173-elm-hana an
The pull request you sent on Fri, 14 Mar 2025 17:11:16 +1000:
> https://gitlab.freedesktop.org/drm/kernel.git tags/drm-fixes-2025-03-14
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/00ddc3f951e266a7df5fead1cfec69b251ca7d41
Thank you!
--
Deet-doot-dot, I am a bot.
h
On Thu, Mar 13, 2025 at 04:51:51PM +, Lee Jones wrote:
> On Thu, 06 Mar 2025, Thomas Zimmermann wrote:
>
> > This series removes the remaining dependencies on fbdev from the
> > backlight, lcd and led subsystems. Each depends on fbdev events to
> > track display state. Make fbdev inform each s
On Wed, 12 Mar 2025 14:39:15 +0100, Maxime Ripard wrote:
> These patches improve the HDMI infrastructure documentation, in
> particular to mention that edid-decode can help debug and check
> infoframes issues.
>
> Let me know what you think,
> Maxime
>
> [...]
Applied to misc/kernel.git (drm-mis
On Fri, Mar 14, 2025 at 08:53:34AM +0100, Maxime Ripard wrote:
> On Tue, Mar 11, 2025 at 05:58:19PM +0200, Dmitry Baryshkov wrote:
> > On Tue, Mar 11, 2025 at 09:41:13AM +0100, Maxime Ripard wrote:
> > > Hi,
> > >
> > > On Mon, Mar 10, 2025 at 08:53:24PM +0200, Dmitry Baryshkov wrote:
> > > > On M
Hello Maxime,
On Thu, 13 Mar 2025 19:07:17 +0100
Maxime Ripard wrote:
> On Thu, Mar 13, 2025 at 12:56:56PM +0100, Luca Ceresoli wrote:
> > Hello Maxime,
> >
> > On Fri, 7 Feb 2025 12:47:51 +0100
> > Maxime Ripard wrote:
> > > On Thu, Feb 06, 2025 at 07:14:29PM +0100, Luca Ceresoli wrote:
>
Currently, ROCm requires CPUs that support PCIe atomics. The message is
more urgent for GPGPU users, meaning basic functionalities of ROCm are not
available on the node.
Signed-off-by: Daisuke Matsuda
---
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 4 ++--
drivers/gpu/drm/amd/amdgpu/amdgv_srio
Add a panel orientation quirk for the ZOTAC Gaming Zone handheld gaming device.
Signed-off-by: Vicki Pfau
---
drivers/gpu/drm/drm_panel_orientation_quirks.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/gpu/drm/drm_panel_orientation_quirks.c
b/drivers/gpu/drm/drm_panel_orien
Hi Jani,
On Thu, Mar 13, 2025 at 6:48 PM Jani Nikula wrote:
>
> On Thu, 13 Mar 2025, "Yo-Jung (Leo) Lin" wrote:
> > The header self-contained tests in drm may leave .hdrtest files in
> > include/drm/ and drivers/gpu/drm/. Omit them by adding .gitignore
>
> This has already been the case with usr
> -Original Message-
> From: Aleksandrs Vinarskis
> Sent: Wednesday, March 12, 2025 1:38 AM
> Subject: [PATCH v2 0/2] drm/msm/dp: Introduce link training per-segment for
> LTTPRs
>
> Recently added Initial LTTPR support in msm/dp has configured LTTPR(s) to
> non-transparent mode to ena
The function dpu_plane_virtual_atomic_check was dereferencing pointers
returned by drm_atomic_get_plane_state without checking for errors. This
could lead to undefined behavior if the function returns an error pointer.
This commit adds checks using IS_ERR to ensure that plane_state is
valid before
1 - 100 of 107 matches
Mail list logo
