Re: [PATCH v3 1/4] drm: Define user readable error codes for atomic ioctl

On 22-08-2025 21:44, Xaver Hugl wrote: +#define DRM_MODE_ATOMIC_FAILURE_REASON \ + FAILURE_REASON(DRM_MODE_ATOMIC_CAP_NOT_ENABLED, "DRM_ATOMIC capability not enabled") \ + FAILURE_REASON(DRM_MODE_ATOMIC_INVALID_FLAG, "invalid flag") \ + FAILURE_REASON(DRM_MODE_ATOMIC_PAGE_FLI

Re: [PATCH v3 1/4] drm: Define user readable error codes for atomic ioctl

On 22-08-2025 16:07, Jani Nikula wrote: On Fri, 22 Aug 2025, Arun R Murthy wrote: There can be multiple reasons for a failure in atomic_ioctl. Most often in these error conditions -EINVAL is returned. User/Compositor would have to blindly take a call on failure of this ioctl so as to use ALLOW_

Re: [PATCH 1/7] drm/shmem: Add a drm_gem_shmem_sync_mmap() helper

Hi Faith, kernel test robot noticed the following build warnings: [auto build test WARNING on drm-exynos/exynos-drm-next] [also build test WARNING on linus/master v6.17-rc2 next-20250822] [If your patch is applied to the wrong git tree, kindly drop us a note. And when submitting patch, we

Re: [PATCH] drm/msm: fix race in Adreno header generation

On Fri, Aug 22, 2025 at 7:09 PM Alex Robinson wrote: > > Builds can compile msm-y objects (e.g. msm_gpu_devfreq.o) > before adreno_common.xml.h is generated in trees that generate Adreno > headers at build time. Make msm-y depend on the generated headers, > removing the race. > > Signed-off-by: Al

[PATCH] drm/nouveau: Support reclocking on gp10b

b_clk { + /* currently applied parameters */ + struct nvkm_clk base; + struct clk *clk; + u32 rate; + + /* new parameters to apply */ + u32 new_rate; +}; +#define gp10b_clk(p) container_of((p), struct gp10b_clk, base) + +#endif --- base-commit: c17b750b3ad9f45f2b6f7e6f7f4679844244f0b9 change-id: 20250822-gp10b-reclock-77bf36005a86 Best regards, -- Aaron Kling

Re: [PATCH] drm/msm: fix msm_gem_vma_new() allocations for managed GPUVMs

On Fri, Aug 22, 2025 at 5:12 PM Dmitry Baryshkov wrote: > > Since commit 3309323241fb ("drm/gpuvm: Kill drm_gpuva_init()") MSM > driver fails to init, failing with "[drm:msm_gpu_init] *ERROR* could not > allocate memptrs: -22" errors. The mentioned commit reworked the > function, but didn't take i

[PATCH] drm/msm: fix msm_gem_vma_new() allocations for managed GPUVMs

Since commit 3309323241fb ("drm/gpuvm: Kill drm_gpuva_init()") MSM driver fails to init, failing with "[drm:msm_gpu_init] *ERROR* could not allocate memptrs: -22" errors. The mentioned commit reworked the function, but didn't take into account that op_map is initialized at the top of the function,

Re: [PATCH 2/3] drm/nouveau/disp: Always accept linear modifier

On Tue Aug 12, 2025 at 12:00 AM CEST, James Jones wrote: > On some chipsets, which block-linear modifiers are > supported is format-specific. However, linear > modifiers are always be supported. The prior > modifier filtering logic was not accounting for > the linear case. > > Fixes: c586f30bf74c (

Re: [git pull] drm fixes for 6.17-rc3

The pull request you sent on Sat, 23 Aug 2025 07:49:34 +1000: > https://gitlab.freedesktop.org/drm/kernel.git tags/drm-fixes-2025-08-23-1 has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/6debb69041724bae8a8a4d0ac60502754c1cd945 Thank you! -- Deet-doot-dot, I am a bot.

[git pull] drm fixes for 6.17-rc3

Hi Linus, Weekly drm fixes. Looks like things did indeed get busier after rc2, nothing seems too major, but stuff scattered all over the place, amdgpu, xe, i915, hibmc, rust support code, and other small fixes. Regards, Dave. drm-fixes-2025-08-23-1: drm fixes for 6.17-rc3 rust: - drm device me

Re: [PATCH v2 1/2] drm: Introduce a new connector status

On Tue, Jul 29, 2025 at 07:57:07PM +0300, Marius Vlad wrote: > This patch introduces a new boolean variable used to track connector's > connect/disconnect status and it is being used on both polling and > the HPD (Hot Plug Detect) paths. > > A subsequent patch would make use of this connector stat

Re: [PATCH 0/2] drm/amd/display: don't overwrite regamma LUT with empty data

On 22/08/2025 18:14, Melissa Wen wrote: Hey, KDE/Plasma users reported some flickering when applying the regamma CRTC LUT to an AMD display hardware set using an external or integrated screen. There is some instability in how the driver stores and updates color blocks based on color manageme

Re: [PATCH] drm/msm: make sure to not queue up recovery more than once

On 8/21/2025 6:36 PM, Antonino Maniscalco wrote: > If two fault IRQs arrive in short succession recovery work will be > queued up twice. > > When recovery runs a second time it may end up killing an unrelated > context. > > Prevent this by masking off interrupts when triggering recovery. > > Sig

Re: (subset) [PATCH 00/13] Support DSI output on rk3576 and roc-rk3576-pc board

On Mon, 07 Jul 2025 18:48:53 +0200, Heiko Stuebner wrote: > This enables all the necesary bits and bindings to get display output > on the dm-m10r800-v3s addon module for the Firefly roc-rk3576-pc board. > > A bit of cleanup of the ili9881c, because the driver was still trying > to send dcs comm

Re: [PATCH 1/1] drm/i915/display: Add quirk to force backlight type on some TUXEDO devices

Hi, Am 22.07.25 um 13:40 schrieb Werner Sembach: Hi, Am 15.04.25 um 17:48 schrieb Werner Sembach: Hi, Am 11.04.25 um 20:56 schrieb Ville Syrjälä: On Fri, Apr 11, 2025 at 05:55:08PM +0200, Werner Sembach wrote: The display backlight on TUXEDO DX1708 and InsanityBook 15 v1 with panels AUO 127

Re: [PATCH] drm/amdgpu: Fix kernel-doc comments for some LUT properties

On 22/08/2025 18:11, Cristian Ciocaltea wrote: The following members of struct amdgpu_mode_info do not have valid references in the related kernel-doc sections: - plane_shaper_lut_property - plane_shaper_lut_size_property, - plane_lut3d_size_property Correct all affected comment blocks

[PATCH 1/2] Revert "drm/amd/display: program output tf when required"

This reverts commit bb622e0c004404b6131633faa6bd8c4939b1df42. There are two issues in this commit: 1. Since commit a4056c2a6344, the output_tf_change bit of the stream update flags is not handled anywhere in the driver and only changes values in case of an UPDATE_TYPE_FULL, which sets up

[PATCH 2/2] drm/amd/display: don't update out gamma if out_tf didn't change

Whenever a full update is requested, the DC sets out_tf to true, forcing the output transfer function to be reprogrammed, but without transfer function settings (neither new nor previous). This unsolicited update of the output transfer function causes the previous setting, made when user space modi

[PATCH 0/2] drm/amd/display: don't overwrite regamma LUT with empty data

Hey, KDE/Plasma users reported some flickering when applying the regamma CRTC LUT to an AMD display hardware set using an external or integrated screen. There is some instability in how the driver stores and updates color blocks based on color management changes or full update request. It uses up

Re: (subset) [PATCH 00/13] Support DSI output on rk3576 and roc-rk3576-pc board

On Mon, 07 Jul 2025 18:48:53 +0200, Heiko Stuebner wrote: > This enables all the necesary bits and bindings to get display output > on the dm-m10r800-v3s addon module for the Firefly roc-rk3576-pc board. > > A bit of cleanup of the ili9881c, because the driver was still trying > to send dcs comm

Re: [PATCH 2/3] drm/nouveau/disp: Always accept linear modifier

On Fri Aug 22, 2025 at 11:11 PM CEST, James Jones wrote: > On 8/22/25 13:55, Danilo Krummrich wrote: >> On Tue Aug 12, 2025 at 12:00 AM CEST, James Jones wrote: >>> On some chipsets, which block-linear modifiers are >>> supported is format-specific. However, linear >>> modifiers are always be suppo

Re: [PATCH 2/3] drm/nouveau/disp: Always accept linear modifier

On 8/22/25 13:55, Danilo Krummrich wrote: On Tue Aug 12, 2025 at 12:00 AM CEST, James Jones wrote: On some chipsets, which block-linear modifiers are supported is format-specific. However, linear modifiers are always be supported. The prior modifier filtering logic was not accounting for the lin

[PATCH] drm/amdgpu: Fix kernel-doc comments for some LUT properties

The following members of struct amdgpu_mode_info do not have valid references in the related kernel-doc sections: - plane_shaper_lut_property - plane_shaper_lut_size_property, - plane_lut3d_size_property Correct all affected comment blocks. Fixes: f545d82479b4 ("drm/amd/display: add plane sha

Re: (subset) [PATCH 00/13] Support DSI output on rk3576 and roc-rk3576-pc board

On Mon, 07 Jul 2025 18:48:53 +0200, Heiko Stuebner wrote: > This enables all the necesary bits and bindings to get display output > on the dm-m10r800-v3s addon module for the Firefly roc-rk3576-pc board. > > A bit of cleanup of the ili9881c, because the driver was still trying > to send dcs comm

Re: [PATCH 2/3] drm/nouveau/disp: Always accept linear modifier

On Tue Aug 12, 2025 at 12:00 AM CEST, James Jones wrote: > On some chipsets, which block-linear modifiers are > supported is format-specific. However, linear > modifiers are always be supported. The prior > modifier filtering logic was not accounting for > the linear case. > > Fixes: c586f30bf74c (

Re: [PATCH 0/3] drm/nouveau: Advertise correct modifiers on GB20x

On Mon, Aug 11, 2025 at 5:57 PM James Jones wrote: > > This series adds new format modifiers for 8 and 16-bit formats on GB20x > GPUs, preventing them from mistakenly sharing block-linear surfaces > using these formats with prior GPUs that use a different layout. > > There are a few ways the param

Re: [PATCH v13 3/4] riscv: dts: thead: th1520: Add IMG BXM-4-64 GPU node

On Fri, Aug 22, 2025 at 12:20:17AM +0200, Michal Wilczynski wrote: > Add a device tree node for the IMG BXM-4-64 GPU present in the T-HEAD > TH1520 SoC used by the Lichee Pi 4A board. This node enables support for > the GPU using the drm/imagination driver. > > By adding this node, the kernel can

Re: [RFC 9/9] {fwctl,drm}/xe/pcode: Introduce xe_pcode_fwctl

On Wed, May 07, 2025 at 07:04:44PM -0300, Jason Gunthorpe wrote: > On Wed, May 07, 2025 at 03:49:15PM -0400, Rodrigo Vivi wrote: > > > One last thing since I have your attention here. Was any time in the > > previous > > fwctl discussions talked about the possibility of some extra usages for like

[PATCH RFC 0/5] Introduce support for post-blend color pipeline

This series is based on "Color Pipeline API w/ VKMS" [1]. It reuses the same concept of a color pipeline API but for the post-blend stage instead of pre-blend, by attaching the COLOR_PIPELINE property to the CRTC rather than a plane. Patch 1 implements the necessary changes in the DRM core to make

[PATCH RFC 4/5] drm/mediatek: ccorr: Support post-blend color pipeline API

Implement the ctm_set_color_pipeline DDP component function to allow configuring the CTM through the color pipeline API. The color pipeline API only defines a 3x4 matrix, while the driver currently only supports setting the coefficients for a 3x3 matrix. However the underlying hardware does suppor

[PATCH RFC 5/5] drm/mediatek: gamma: Support post-blend color pipeline API

Implement the gamma_set_color_pipeline DDP component function to allow configuring the gamma LUT through the post-blend color pipeline API. The color pipeline API uses a 32-bit long, rather than 16-bit long, LUT, so also update the functions to handle both cases. Also make sure to enable or disab

[PATCH RFC 3/5] drm/mediatek: Support post-blend colorops for gamma and ctm

Allow configuring the gamma and ccorr blocks through the post-blend color pipeline API instead of the GAMMA_LUT and CTM properties. In order to achieve this, initialize the color pipeline property and colorops on the CRTC based on the DDP components available in the CRTC path. Then introduce a str

[PATCH RFC 2/5] drm/colorop: Export drm_colorop_cleanup() so drivers can extend it

Export drm_colorop_cleanup() so drivers subclassing drm_colorop can reuse this function in subclass cleanup routines. Signed-off-by: Nícolas F. R. A. Prado --- drivers/gpu/drm/drm_colorop.c | 3 ++- include/drm/drm_colorop.h | 1 + 2 files changed, 3 insertions(+), 1 deletion(-) diff --git

[PATCH RFC 1/5] drm: Support post-blend color pipeline API

Introduce support for a post-blend color pipeline API analogous to the pre-blend color pipeline API. While the pre-blend color pipeline was configured through a COLOR_PIPELINE property attached to a drm_plane, the post-blend color pipeline is configured through a COLOR_PIPELINE property on the drm_

Re: [PATCH 3/5] drm/panel: simple: add JuTouch JT101TM023

On Thu, Aug 21, 2025 at 09:55:30AM +0200, Steffen Trumtrar wrote: > Add JuTouch Technology JT101TM023 10" 1280x800 LVDS panel support. > > Signed-off-by: Steffen Trumtrar > --- > drivers/gpu/drm/panel/panel-simple.c | 35 +++ > 1 file changed, 35 insertions(+) >

[PATCH] dt-bindings: display: dsi-controller: add bridge to patternProperties

This patch extends the binding schema by adding a new `bridge@[0-3]` to represent any bridge devices attached as DSI peripheral. Signed-off-by: Harikrishna Shenoy --- .../bindings/display/dsi-controller.yaml | 18 ++ 1 file changed, 18 insertions(+) diff --git a/Documentat

Re: [PATCH v3 02/14] dt-bindings: phy: Add QMP USB3+DP PHY for QCS615

On Fri, Aug 22, 2025 at 09:22:30AM -0500, Rob Herring wrote: > On Wed, Aug 20, 2025 at 05:34:44PM +0800, Xiangxu Yin wrote: > > Add device tree binding documentation for the Qualcomm QMP USB3+DP PHY > > on QCS615 Platform. This PHY supports both USB3 and DP functionality > > over USB-C, with PHY mo

Re: (subset) [PATCH v7 00/10] Add support for RK3588 DisplayPort Controller

On Fri, 22 Aug 2025 14:39:44 +0800, Andy Yan wrote: > From: Andy Yan > > > There are two DW DPTX based DisplayPort Controller on rk3588 which > are compliant with the DisplayPort Specification Version 1.4 with > the following features: > > [...] Applied to drm-misc-next, thanks! I will wait fo

Re: [PATCH RFC 29/35] scsi: core: drop nth_page() usage within SG entry

On 22.08.25 20:01, Bart Van Assche wrote: On 8/21/25 1:06 PM, David Hildenbrand wrote: It's no longer required to use nth_page() when iterating pages within a single SG entry, so let's drop the nth_page() usage. Usually the SCSI core and the SG I/O driver are updated separately. Anyway: Thank

Re: [PATCH RFC 29/35] scsi: core: drop nth_page() usage within SG entry

On 8/21/25 1:06 PM, David Hildenbrand wrote: It's no longer required to use nth_page() when iterating pages within a single SG entry, so let's drop the nth_page() usage. Usually the SCSI core and the SG I/O driver are updated separately. Anyway: Reviewed-by: Bart Van Assche

Re: [PATCH RFC 09/35] mm/mm_init: make memmap_init_compound() look more like prep_compound_page()

On 22.08.25 17:27, Mike Rapoport wrote: On Thu, Aug 21, 2025 at 10:06:35PM +0200, David Hildenbrand wrote: Grepping for "prep_compound_page" leaves on clueless how devdax gets its compound pages initialized. Let's add a comment that might help finding this open-coded prep_compound_page() initia

Re: [PATCH v5] drm: re-allow no-op changes on non-primary planes in async flips

Em 22/08/2025 12:28, Xaver Hugl escreveu: Commit fd40a63c63a1 unintentionally disallowed no-op changes on non-primary planes that the driver doesn't allow async flips on. This broke async flips for compositors that disable the cursor plane in every async atomic commit. To fix that, change drm_ato

[PATCH V1] accel/amdxdna: Add ioctl DRM_IOCTL_AMDXDNA_GET_ARRAY

Add interface for applications to get information array. The application provides a buffer pointer along with information type, maximum number of entries and maximum size of each entry. The buffer may also contain match conditions based on the information type. After the ioctl completes, the actual

Re: [PATCH 3/3] drm/nouveau: Advertise correct modifiers on GB20x

On Fri, Aug 22, 2025 at 1:03 PM James Jones wrote: > > On 8/22/25 08:48, Faith Ekstrand wrote: > > > > On Mon, Aug 11, 2025 at 5:57 PM James Jones > > wrote: > > > > 8 and 16 bit formats use a different layout on > > GB20x than they did on prior chips. Add the >

Re: [PATCH RFC 07/35] mm/memremap: reject unreasonable folio/compound page sizes in memremap_pages()

On Thu, 21 Aug 2025 22:06:33 +0200 David Hildenbrand wrote: > Let's reject unreasonable folio sizes early, where we can still fail. > We'll add sanity checks to prepare_compound_head/prepare_compound_page > next. > > Is there a way to configure a system such that unreasonable folio sizes > would

Re: [PATCH RFC 06/35] mm/page_alloc: reject unreasonable folio/compound page sizes in alloc_contig_range_noprof()

On Thu, 21 Aug 2025 22:06:32 +0200 David Hildenbrand wrote: > Let's reject them early, I like early failures. :) > which in turn makes folio_alloc_gigantic() reject > them properly. > > To avoid converting from order to nr_pages, let's just add MAX_FOLIO_ORDER > and calculate MAX_FOLIO_NR_PAGE

Re: [PATCH 3/3] drm/nouveau: Advertise correct modifiers on GB20x

On 8/22/25 08:48, Faith Ekstrand wrote: On Mon, Aug 11, 2025 at 5:57 PM James Jones > wrote: 8 and 16 bit formats use a different layout on GB20x than they did on prior chips. Add the corresponding DRM format modifiers to the list of modifiers support

Re: [PATCH RFC 01/35] mm: stop making SPARSEMEM_VMEMMAP user-selectable

On Thu, 21 Aug 2025 22:06:27 +0200 David Hildenbrand wrote: > In an ideal world, we wouldn't have to deal with SPARSEMEM without > SPARSEMEM_VMEMMAP, but in particular for 32bit SPARSEMEM_VMEMMAP is > considered too costly and consequently not supported. > > However, if an architecture does supp

Re: [PATCH] MAINTAINERS: Update Min Ma's email for AMD XDNA driver

Hi Min, Please fix the patch and make sure checkpatch is passed. I can not apply it. Applying: MAINTAINERS: Update Min Ma's email for AMD XDNA driver error: corrupt patch at line 10 error: could not build fake ancestor Lizhi On 7/22/25 23:38, Min Ma wrote: I recently left AMD and would like t

Re: [PATCH] drm/xe: Skip creation of pcode sysfs files when pcode is disabled

On Tue, Aug 19, 2025 at 04:55:29PM -0100, Andi Shyti wrote: > From: Andi Shyti > > Coverity warns that 'cap' may be used uninitialised. If pcode > is disabled there is no need to go through the hassle of a > pcode read or taking a PM reference. Please mark it as false positive! We will only get

Re: [PATCH 1/5] dt-bindings: vendor-prefixes: Add JuTouch Technology Co, Ltd

On Thu, 21 Aug 2025 09:55:28 +0200, Steffen Trumtrar wrote: > JuTouch is a chinese touch screen supplier dedicated to manufacturing > high-end touch display products for the global industrial market. > (www.jutouch.com) > > Add a vendor prefix for it. > > Signed-off-by: Steffen Trumtrar > ---

Re: [PATCH 4/5] dt-bindings: arm: fsl: add compatible for Skov i.MX8MP variant

On Thu, 21 Aug 2025 09:55:31 +0200, Steffen Trumtrar wrote: > In preparation for adding a new device tree variant with a different > panel, describe the DT compatible in the binding. > > Signed-off-by: Steffen Trumtrar > --- > Documentation/devicetree/bindings/arm/fsl.yaml | 1 + > 1 file chan

Re: [PATCH 2/5] dt-bindings: display: simple: Add JuTouch JT101TM023 panel

On Thu, 21 Aug 2025 09:55:29 +0200, Steffen Trumtrar wrote: > Add the JuTouch Technology Co. 10" JT101TM023 LVDS panel. > > Signed-off-by: Steffen Trumtrar > --- > Documentation/devicetree/bindings/display/panel/panel-simple.yaml | 2 ++ > 1 file changed, 2 insertions(+) > Acked-by: Rob Herr

Re: [PATCH 2/3] drm/nouveau/disp: Always accept linear modifier

On Mon, Aug 11, 2025 at 5:57 PM James Jones wrote: > > On some chipsets, which block-linear modifiers are > supported is format-specific. However, linear > modifiers are always be supported. The prior > modifier filtering logic was not accounting for > the linear case. > > Fixes: c586f30bf74c ("dr

Re: [PATCH 1/3] drm: define NVIDIA DRM format modifiers for GB20x

On Mon, Aug 11, 2025 at 5:57 PM James Jones wrote: > > The layout of bits within the individual tiles > (referred to as sectors in the > DRM_FORMAT_MOD_NVIDIA_BLOCK_LINEAR_2D() macro) > changed for 8 and 16-bit surfaces starting in > Blackwell 2 GPUs (With the exception of GB10). > To denote the d

Re: [PATCH v3 1/4] drm: Define user readable error codes for atomic ioctl

> +#define DRM_MODE_ATOMIC_FAILURE_REASON \ > + FAILURE_REASON(DRM_MODE_ATOMIC_CAP_NOT_ENABLED, "DRM_ATOMIC > capability not enabled") \ > + FAILURE_REASON(DRM_MODE_ATOMIC_INVALID_FLAG, "invalid flag") \ > + FAILURE_REASON(DRM_MODE_ATOMIC_PAGE_FLIP_ASYNC, "Legacy > DRM_MODE_PAGE

Re: UBSAN: shift-out-of-bounds in drivers/video/fbdev/core/fb_fillrect.h:100:21 (v6.17-rc2)

It's only on 32 bit big endian. I don't have UBSAN for MIPS on my setup so haven't noticed it. #ifndef __LITTLE_ENDIAN pattern <<= (BITS_PER_LONG % bpp); pattern |= pattern >> bpp; <- #endif In the 32 BPP case the result is identical in both the no shift and zero resul

Re: [PATCH v1 13/14] dt-bindings: input/touchscreen: Convert MELFAS MIP4 Touchscreen to YAML

On Wed, Aug 20, 2025 at 02:13:01PM -0300, Ariel D'Alessandro wrote: > Convert the existing text-based DT bindings for MELFAS MIP4 Touchscreen > controller to a YAML schema. > > Signed-off-by: Ariel D'Alessandro > --- > .../input/touchscreen/melfas,mip4_ts.yaml | 55 +++ > ...

Re: [PATCH 1/3] drm: define NVIDIA DRM format modifiers for GB20x

On Mon, Aug 11, 2025 at 5:57 PM James Jones wrote: > The layout of bits within the individual tiles > (referred to as sectors in the > DRM_FORMAT_MOD_NVIDIA_BLOCK_LINEAR_2D() macro) > changed for 8 and 16-bit surfaces starting in > Blackwell 2 GPUs (With the exception of GB10). > To denote the di

Re: [PATCH v1 12/14] dt-bindings: soc: mediatek: pwrap: Add power-domains property

On Wed, 20 Aug 2025 14:13:00 -0300, Ariel D'Alessandro wrote: > Currently, the DT bindings for Mediatek PMIC Wrapper is missing the > power-domains property, which is used in the MT8173 E1 evaluation board > as it needs USB power domain. > > Signed-off-by: Ariel D'Alessandro > --- > .../bindin

Re: [PATCH 3/3] drm/nouveau: Advertise correct modifiers on GB20x

On Mon, Aug 11, 2025 at 5:57 PM James Jones wrote: > 8 and 16 bit formats use a different layout on > GB20x than they did on prior chips. Add the > corresponding DRM format modifiers to the list of > modifiers supported by the display engine on such > chips, and filter the supported modifiers for

[PATCH v5] drm: re-allow no-op changes on non-primary planes in async flips

Commit fd40a63c63a1 unintentionally disallowed no-op changes on non-primary planes that the driver doesn't allow async flips on. This broke async flips for compositors that disable the cursor plane in every async atomic commit. To fix that, change drm_atomic_set_property to again only run atomic_as

Re: [PATCH 3/7] drm/panthor: Add a PANTHOR_BO_SYNC ioctl

On Fri, 22 Aug 2025 10:29:12 -0400 Faith Ekstrand wrote: It probably deserve a quick description of why this is needed (same for the previous commit BTW). > Signed-off-by: Faith Ekstrand > --- > drivers/gpu/drm/panthor/panthor_drv.c | 47 ++- > drivers/gpu/drm/panthor/panth

Re: [PATCH RFC 09/35] mm/mm_init: make memmap_init_compound() look more like prep_compound_page()

On Thu, Aug 21, 2025 at 10:06:35PM +0200, David Hildenbrand wrote: > Grepping for "prep_compound_page" leaves on clueless how devdax gets its > compound pages initialized. > > Let's add a comment that might help finding this open-coded > prep_compound_page() initialization more easily. > > Furthe

Re: [PATCH v1 05/14] sound: dt-bindings: Convert MediaTek RT5650 codecs bindings to YAML

On Wed, Aug 20, 2025 at 02:12:53PM -0300, Ariel D'Alessandro wrote: > Convert the existing text-based DT bindings for Mediatek MT8173 RT5650 > codecs to a YAML schema. > > Signed-off-by: Ariel D'Alessandro > --- > .../sound/mediatek,mt8173-rt5650.yaml | 73 +++ > .../bind

Re: [PATCH 2/7] drm/panthor: Add flag to map GEM object Write-Back Cacheable

On Fri, 22 Aug 2025 10:29:11 -0400 Faith Ekstrand wrote: > From: Loïc Molinari > > Signed-off-by: Loïc Molinari > Signed-off-by: Faith Ekstrand > --- > drivers/gpu/drm/panthor/panthor_drv.c | 7 ++- > drivers/gpu/drm/panthor/panthor_gem.c | 3 +++ > include/uapi/drm/panthor_drm.h

Re: [PATCH v1 09/14] dt-bindings: pinctrl: mediatek,mt65xx-pinctrl: Allow gpio-line-names

On Wed, 20 Aug 2025 14:12:57 -0300, Ariel D'Alessandro wrote: > Current, the DT bindings for MediaTek's MT65xx Pin controller is missing > the gpio-line-names property, add it to the associated schema. > > Signed-off-by: Ariel D'Alessandro > --- > .../devicetree/bindings/pinctrl/mediatek,mt65x

Re: [PATCH v3 2/2] drm: bridge: Add TI tmds181 and sn65dp159 driver

On 21-08-2025 09:36, Krzysztof Kozlowski wrote: On Wed, Aug 20, 2025 at 04:40:35PM +0200, Mike Looijmans wrote: The tmds181 and sn65dp159 are "retimers" and hence can be considered HDMI-to-HDMI bridges. Typical usage is to convert the output of an FPGA into a valid HDMI signal, and it will typic

Re: [PATCH 1/7] drm/shmem: Add a drm_gem_shmem_sync_mmap() helper

On Fri, 22 Aug 2025 10:29:10 -0400 Faith Ekstrand wrote: > This enables syncing mapped GEM objects between the CPU and GPU via calls > to dma_sync_*(). It's a bit annoying as it requires walking the sg_table > so it's best if every driver doesn't hand-roll it. > > Signed-off-by: Faith Ekstrand

Re: [PATCH RFC 05/35] wireguard: selftests: remove CONFIG_SPARSEMEM_VMEMMAP=y from qemu kernel config

On Thu, Aug 21, 2025 at 10:06:31PM +0200, David Hildenbrand wrote: > It's no longer user-selectable (and the default was already "y"), so > let's just drop it. and it should not matter for wireguard selftest anyway > > Cc: "Jason A. Donenfeld" > Cc: Shuah Khan > Signed-off-by: David Hildenbrand

Re: [PATCH RFC 04/35] x86/Kconfig: drop superfluous "select SPARSEMEM_VMEMMAP"

On Thu, Aug 21, 2025 at 10:06:30PM +0200, David Hildenbrand wrote: > Now handled by the core automatically once SPARSEMEM_VMEMMAP_ENABLE > is selected. > > Cc: Thomas Gleixner > Cc: Ingo Molnar > Cc: Borislav Petkov > Cc: Dave Hansen > Signed-off-by: David Hildenbrand Reviewed-by: Mike Rapop

Re: [PATCH RFC 03/35] s390/Kconfig: drop superfluous "select SPARSEMEM_VMEMMAP"

On Thu, Aug 21, 2025 at 10:06:29PM +0200, David Hildenbrand wrote: > Now handled by the core automatically once SPARSEMEM_VMEMMAP_ENABLE > is selected. > > Cc: Heiko Carstens > Cc: Vasily Gorbik > Cc: Alexander Gordeev > Cc: Christian Borntraeger > Cc: Sven Schnelle > Signed-off-by: David Hil

Re: [PATCH RFC 02/35] arm64: Kconfig: drop superfluous "select SPARSEMEM_VMEMMAP"

On Thu, Aug 21, 2025 at 10:06:28PM +0200, David Hildenbrand wrote: > Now handled by the core automatically once SPARSEMEM_VMEMMAP_ENABLE > is selected. > > Cc: Catalin Marinas > Cc: Will Deacon > Signed-off-by: David Hildenbrand Reviewed-by: Mike Rapoport (Microsoft) > --- > arch/arm64/Kcon

Re: [PATCH RFC 01/35] mm: stop making SPARSEMEM_VMEMMAP user-selectable

On Thu, Aug 21, 2025 at 10:06:27PM +0200, David Hildenbrand wrote: > In an ideal world, we wouldn't have to deal with SPARSEMEM without > SPARSEMEM_VMEMMAP, but in particular for 32bit SPARSEMEM_VMEMMAP is > considered too costly and consequently not supported. > > However, if an architecture does

Re: [PATCH 0/7] panfrost,panthor: Cached maps and explicit flushing

+panthor/panfrost maintainers/devs On Fri, 22 Aug 2025 10:29:09 -0400 Faith Ekstrand wrote: > This series implements cached maps and explicit flushing for both panfrost > and panthor. To avoid code/bug duplication, the tricky guts of the cache > flusing ioctl which walk the sg list are broken i

Re: [PATCH v2 0/6] DRM IDR to Xarray conversions

On Fri, Aug 22, 2025 at 10:36:24AM -0400, Sidhartha Kumar wrote: > On 8/22/25 8:33 AM, Jani Nikula wrote: > > It would be great if the commit messages mentioned whether the > > identifiers are expected to remain the same in the conversion. > > By identifiers do you mean if the name of the previous

Re: [PATCH v2 3/3] dt-bindings: display: rockchip,dw-mipi-dsi: Narrow clocks for rockchip,rk3288-mipi-dsi

On Wed, 20 Aug 2025 16:17:38 +0200, Krzysztof Kozlowski wrote: > The binding allows in top-level from one to four clocks and each variant > narrows the choice, but rockchip,rk3288-mipi-dsi missed the minItems. > > Reviewed-by: Heiko Stuebner > Signed-off-by: Krzysztof Kozlowski > > --- > > C

Re: [PATCH v2 2/3] dt-bindings: display: ti,tdp158: Add missing reg constraint

On Wed, 20 Aug 2025 16:17:37 +0200, Krzysztof Kozlowski wrote: > Device can be used over I2C bus, so it documents 'reg' property, however > it misses to constrain it to actual I2C address. > > Signed-off-by: Krzysztof Kozlowski > --- > Documentation/devicetree/bindings/display/bridge/ti,tdp158

Re: [PATCH v2 1/3] dt-bindings: display: ingenic,jz4780-hdmi: Add missing clock-names

On Wed, 20 Aug 2025 16:17:36 +0200, Krzysztof Kozlowski wrote: > The binding references synopsys,dw-hdmi.yaml schema which defines both > 'clocks' and 'clock-names' with variable length, therefore we need here > also same constraint for 'clock-names' as for 'clocks'. > > Signed-off-by: Krzysztof

Re: [PATCH v4] drm: re-allow no-op changes on non-primary planes in async flips

Hi Xaver, Thanks for the patch and sorry for the delay. Em 08/08/2025 20:22, Xaver Hugl escreveu: Commit fd40a63c63a1 unintentionally disallowed no-op changes on non-primary planes that the driver doesn't allow async flips on. This broke async flips for compositors that disable the cursor plane

[PATCH v5 13/13] arm64: dts: st: enable display support on stm32mp257f-ev1 board

Enable the following IPs on stm32mp257f-ev1 in order to get display: * LTDC * LVDS * WSVGA LVDS panel (1024x600) * Panel LVDS backlight as GPIO backlight * ILI2511 i2c touchscreen Acked-by: Yannick Fertre Signed-off-by: Raphael Gallais-Pou --- arch/arm64/boot/dts/st/stm32mp257f-e

[PATCH v5 12/13] arm64: dts: st: add clock-cells to syscfg node on stm32mp251

Make the syscfg node a clock provider so clock consumers can reach child clocks through device-tree. Acked-by: Yannick Fertre Signed-off-by: Raphael Gallais-Pou --- arch/arm64/boot/dts/st/stm32mp251.dtsi | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm64/boot/dts/st/stm32mp251.dtsi

[PATCH v5 11/13] arm64: dts: st: add lvds support on stm32mp255

The LVDS is used on STM32MP2 as a display interface. Add the LVDS node. Acked-by: Yannick Fertre Signed-off-by: Raphael Gallais-Pou --- arch/arm64/boot/dts/st/stm32mp255.dtsi | 14 +- 1 file changed, 13 insertions(+), 1 deletion(-) diff --git a/arch/arm64/boot/dts/st/stm32mp255.dt

[PATCH v5 07/13] drm/stm: ltdc: support new hardware version for STM32MP25 SoC

From: Yannick Fertre STM32MP25 SoC features a new version of the LTDC IP. Add its compatible to the list of device to probe and implement its quirks. This hardware supports a pad frequency of 150MHz and a peripheral bus clock. Signed-off-by: Yannick Fertre Acked-by: Yannick Fertre Signed-off

[PATCH v5 10/13] arm64: dts: st: add ltdc support on stm32mp255

Add the LTDC node for stm32mp255 SoC and handle its loopback clocks. ck_ker_ltdc has the CLK_SET_RATE_PARENT flag. While having this flag is semantically correct, it for now leads to an improper setting of the clock rate. The ck_ker_ltdc parent clock is the flexgen 27, which does not support cha

[PATCH v5 09/13] arm64: dts: st: add ltdc support on stm32mp251

The LCD-TFT Display Controller (LTDC) handles display composition, scaling and rotation. It provides a parallel digital RGB flow to be used by display interfaces. Add the LTDC node. Acked-by: Yannick Fertre Signed-off-by: Raphael Gallais-Pou --- arch/arm64/boot/dts/st/stm32mp251.dtsi | 12 +++

[PATCH v5 06/13] dt-bindings: arm: stm32: add required #clock-cells property

On STM32MP25 SoC, the syscfg peripheral provides a clock to the display subsystem through a multiplexer. Since it only provides a single clock, the cell value is 0. Doing so allows the clock consumers to reach the peripheral and gate the clock accordingly. Reviewed-by: Rob Herring (Arm) Reviewe

[PATCH v5 08/13] drm/stm: ltdc: handle lvds pixel clock

From: Yannick Fertre Handle LVDS pixel clock. The LTDC operates with multiple clock domains for register access, requiring all clocks to be provided during read/write operations. This imposes a dependency between the LVDS and LTDC to access correctly all LTDC registers. And because both IPs' p

[PATCH v5 02/13] dt-bindings: display: st,stm32-ltdc: add access-controllers property

access-controllers is an optional property that allows a peripheral to refer to one or more domain access controller(s). This property is added when the peripheral is under the STM32 firewall controller. It allows an accurate representation of the hardware, where the peripheral is connected to a

[PATCH v5 00/13] Enable display support for STM32MP25

This series aims to add and enable sufficient LVDS display support for STM32MP257F-EV1 board. LVDS is the default use case to drive a display panel on STM32MP257F-EV, even though DSI panels will be supported in the near future. The LTDC needs a pixel rate in sync with the bridge currently in use.

[PATCH v5 03/13] dt-bindings: display: st: add new compatible to LVDS device

Update the compatible to accept both "st,stm32mp255-lvds" and st,stm32mp25-lvds" respectively. Default will fall back to "st,stm32mp25-lvds". Acked-by: Krzysztof Kozlowski Acked-by: Yannick Fertre Signed-off-by: Raphael Gallais-Pou --- Documentation/devicetree/bindings/display/st,stm32mp25-lv

[PATCH v5 04/13] dt-bindings: display: st,stm32mp25-lvds: add access-controllers property

access-controllers is an optional property that allows a peripheral to refer to one or more domain access controller(s). This property is added when the peripheral is under the STM32 firewall controller. It allows an accurate representation of the hardware, where the peripheral is connected to a

[PATCH v5 01/13] dt-bindings: display: st: add two new compatibles to LTDC device

The new STMicroelectronics SoC features a display controller similar to the one used in previous SoCs. Because there is additional registers, and different mandatory clocks it is incompatible with existing IPs. On STM32MP251, the device only needs two clocks while on STM32MP255 it needs four. Ad

[PATCH v5 05/13] dt-bindings: display: st,stm32mp25-lvds: add power-domains property

STM32 LVDS peripheral may be in a power domain. Allow an optional single 'power-domains' entry for STM32 LVDS devices. Acked-by: Rob Herring (Arm) Acked-by: Yannick Fertre Signed-off-by: Raphael Gallais-Pou --- Documentation/devicetree/bindings/display/st,stm32mp25-lvds.yaml | 3 +++ 1 file c

Re: [PATCH v2 0/6] DRM IDR to Xarray conversions

On 8/22/25 8:33 AM, Jani Nikula wrote: On Thu, 21 Aug 2025, Sidhartha Kumar wrote: From: Sidhartha v1[1] -> v2: - rebase onto latest mainline v6.17-rc2 - fix build error in patch 1 per Intel Test Robot This series is part of a project to depcrecate the IDR in favor of the Xarray. This

Re: [PATCH RFC 00/35] mm: remove nth_page()

On Thu, Aug 21, 2025 at 10:06:26PM +0200, David Hildenbrand wrote: > As discussed recently with Linus, nth_page() is just nasty and we would > like to remove it. > > To recap, the reason we currently need nth_page() within a folio is because > on some kernel configs (SPARSEMEM without SPARSEMEM_VM

[PATCH 5/7] drm/panfrost: Add flag to map GEM object Write-Back Cacheable

Signed-off-by: Faith Ekstrand --- drivers/gpu/drm/panfrost/panfrost_drv.c | 7 +-- drivers/gpu/drm/panfrost/panfrost_gem.c | 3 +++ include/uapi/drm/panfrost_drm.h | 1 + 3 files changed, 9 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/panfrost/panfrost_drv.c b/drivers/

[PATCH 7/7] drm/panfrost: Bump the driver version to 1.5

Signed-off-by: Faith Ekstrand --- drivers/gpu/drm/panfrost/panfrost_drv.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/panfrost/panfrost_drv.c b/drivers/gpu/drm/panfrost/panfrost_drv.c index 7d6e2b803a2b..8b841c6c8150 100644 --- a/drivers/gpu/drm/panfrost

[PATCH 6/7] drm/panfrost: Add a PANFROST_SYNC_BO ioctl

Signed-off-by: Faith Ekstrand --- drivers/gpu/drm/panfrost/panfrost_drv.c | 57 + drivers/gpu/drm/panfrost/panfrost_gem.c | 20 + drivers/gpu/drm/panfrost/panfrost_gem.h | 2 + include/uapi/drm/panfrost_drm.h | 45 +++ 4 files changed, 124

[PATCH 4/7] drm/panthor: Bump the driver version to 1.6

Signed-off-by: Faith Ekstrand --- drivers/gpu/drm/panthor/panthor_drv.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/panthor/panthor_drv.c b/drivers/gpu/drm/panthor/panthor_drv.c index 1527966604e1..2da06057ce37 100644 --- a/drivers/gpu/drm/panthor/panth

  1   2   3   >