* Re: [PATCH v4 12/21] misc: open-dice: replace deprecated mmap hook with mmap_prepare
From: Vlastimil Babka (SUSE) @ 2026-03-25 10:14 UTC (permalink / raw)
To: Lorenzo Stoakes (Oracle), Andrew Morton
Cc: Jonathan Corbet, Clemens Ladisch, Arnd Bergmann,
Greg Kroah-Hartman, K . Y . Srinivasan, Haiyang Zhang, Wei Liu,
Dexuan Cui, Long Li, Alexander Shishkin, Maxime Coquelin,
Alexandre Torgue, Miquel Raynal, Richard Weinberger,
Vignesh Raghavendra, Bodo Stroesser, Martin K . Petersen,
David Howells, Marc Dionne, Alexander Viro, Christian Brauner,
Jan Kara, David Hildenbrand, Liam R . Howlett, Mike Rapoport,
Suren Baghdasaryan, Michal Hocko, Jann Horn, Pedro Falcato,
linux-kernel, linux-doc, linux-hyperv, linux-stm32,
linux-arm-kernel, linux-mtd, linux-staging, linux-scsi,
target-devel, linux-afs, linux-fsdevel, linux-mm, Ryan Roberts
In-Reply-To: <5a83ab00195dc8d0609fa6cc525493010ac4ead1.1774045440.git.ljs@kernel.org>
On 3/20/26 23:39, Lorenzo Stoakes (Oracle) wrote:
> The f_op->mmap interface is deprecated, so update driver to use its
> successor, mmap_prepare.
>
> The driver previously used vm_iomap_memory(), so this change replaces it
> with its mmap_prepare equivalent, mmap_action_simple_ioremap().
>
> Reviewed-by: Suren Baghdasaryan <surenb@google.com>
> Signed-off-by: Lorenzo Stoakes (Oracle) <ljs@kernel.org>
Acked-by: Vlastimil Babka (SUSE) <vbabka@kernel.org>
> ---
> drivers/misc/open-dice.c | 19 +++++++++++--------
> 1 file changed, 11 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/misc/open-dice.c b/drivers/misc/open-dice.c
> index 24c29e0f00ef..45060fb4ea27 100644
> --- a/drivers/misc/open-dice.c
> +++ b/drivers/misc/open-dice.c
> @@ -86,29 +86,32 @@ static ssize_t open_dice_write(struct file *filp, const char __user *ptr,
> /*
> * Creates a mapping of the reserved memory region in user address space.
> */
> -static int open_dice_mmap(struct file *filp, struct vm_area_struct *vma)
> +static int open_dice_mmap_prepare(struct vm_area_desc *desc)
> {
> + struct file *filp = desc->file;
> struct open_dice_drvdata *drvdata = to_open_dice_drvdata(filp);
>
> - if (vma->vm_flags & VM_MAYSHARE) {
> + if (vma_desc_test(desc, VMA_MAYSHARE_BIT)) {
> /* Do not allow userspace to modify the underlying data. */
> - if (vma->vm_flags & VM_WRITE)
> + if (vma_desc_test(desc, VMA_WRITE_BIT))
> return -EPERM;
> /* Ensure userspace cannot acquire VM_WRITE later. */
> - vm_flags_clear(vma, VM_MAYWRITE);
> + vma_desc_clear_flags(desc, VMA_MAYWRITE_BIT);
> }
>
> /* Create write-combine mapping so all clients observe a wipe. */
> - vma->vm_page_prot = pgprot_writecombine(vma->vm_page_prot);
> - vm_flags_set(vma, VM_DONTCOPY | VM_DONTDUMP);
> - return vm_iomap_memory(vma, drvdata->rmem->base, drvdata->rmem->size);
> + desc->page_prot = pgprot_writecombine(desc->page_prot);
> + vma_desc_set_flags(desc, VMA_DONTCOPY_BIT, VMA_DONTDUMP_BIT);
> + mmap_action_simple_ioremap(desc, drvdata->rmem->base,
> + drvdata->rmem->size);
> + return 0;
> }
>
> static const struct file_operations open_dice_fops = {
> .owner = THIS_MODULE,
> .read = open_dice_read,
> .write = open_dice_write,
> - .mmap = open_dice_mmap,
> + .mmap_prepare = open_dice_mmap_prepare,
> };
>
> static int __init open_dice_probe(struct platform_device *pdev)
^ permalink raw reply
* Re: [PATCH v4 13/21] hpet: replace deprecated mmap hook with mmap_prepare
From: Vlastimil Babka (SUSE) @ 2026-03-25 10:17 UTC (permalink / raw)
To: Lorenzo Stoakes (Oracle), Andrew Morton
Cc: Jonathan Corbet, Clemens Ladisch, Arnd Bergmann,
Greg Kroah-Hartman, K . Y . Srinivasan, Haiyang Zhang, Wei Liu,
Dexuan Cui, Long Li, Alexander Shishkin, Maxime Coquelin,
Alexandre Torgue, Miquel Raynal, Richard Weinberger,
Vignesh Raghavendra, Bodo Stroesser, Martin K . Petersen,
David Howells, Marc Dionne, Alexander Viro, Christian Brauner,
Jan Kara, David Hildenbrand, Liam R . Howlett, Mike Rapoport,
Suren Baghdasaryan, Michal Hocko, Jann Horn, Pedro Falcato,
linux-kernel, linux-doc, linux-hyperv, linux-stm32,
linux-arm-kernel, linux-mtd, linux-staging, linux-scsi,
target-devel, linux-afs, linux-fsdevel, linux-mm, Ryan Roberts
In-Reply-To: <094c5fcfb2459a4f6d791b1fb852b01e252a44d4.1774045440.git.ljs@kernel.org>
On 3/20/26 23:39, Lorenzo Stoakes (Oracle) wrote:
> The f_op->mmap interface is deprecated, so update driver to use its
> successor, mmap_prepare.
>
> The driver previously used vm_iomap_memory(), so this change replaces it
> with its mmap_prepare equivalent, mmap_action_simple_ioremap().
>
> Reviewed-by: Suren Baghdasaryan <surenb@google.com>
> Signed-off-by: Lorenzo Stoakes (Oracle) <ljs@kernel.org>
Acked-by: Vlastimil Babka (SUSE) <vbabka@kernel.org>
> ---
> drivers/char/hpet.c | 12 +++++++-----
> 1 file changed, 7 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/char/hpet.c b/drivers/char/hpet.c
> index 60dd09a56f50..8f128cc40147 100644
> --- a/drivers/char/hpet.c
> +++ b/drivers/char/hpet.c
> @@ -354,8 +354,9 @@ static __init int hpet_mmap_enable(char *str)
> }
> __setup("hpet_mmap=", hpet_mmap_enable);
>
> -static int hpet_mmap(struct file *file, struct vm_area_struct *vma)
> +static int hpet_mmap_prepare(struct vm_area_desc *desc)
> {
> + struct file *file = desc->file;
> struct hpet_dev *devp;
> unsigned long addr;
>
> @@ -368,11 +369,12 @@ static int hpet_mmap(struct file *file, struct vm_area_struct *vma)
> if (addr & (PAGE_SIZE - 1))
> return -ENOSYS;
>
> - vma->vm_page_prot = pgprot_noncached(vma->vm_page_prot);
> - return vm_iomap_memory(vma, addr, PAGE_SIZE);
> + desc->page_prot = pgprot_noncached(desc->page_prot);
> + mmap_action_simple_ioremap(desc, addr, PAGE_SIZE);
> + return 0;
> }
> #else
> -static int hpet_mmap(struct file *file, struct vm_area_struct *vma)
> +static int hpet_mmap_prepare(struct vm_area_desc *desc)
> {
> return -ENOSYS;
> }
> @@ -710,7 +712,7 @@ static const struct file_operations hpet_fops = {
> .open = hpet_open,
> .release = hpet_release,
> .fasync = hpet_fasync,
> - .mmap = hpet_mmap,
> + .mmap_prepare = hpet_mmap_prepare,
> };
>
> static int hpet_is_known(struct hpet_data *hdp)
^ permalink raw reply
* Re: [PATCH v4 14/21] mtdchar: replace deprecated mmap hook with mmap_prepare, clean up
From: Vlastimil Babka (SUSE) @ 2026-03-25 10:20 UTC (permalink / raw)
To: Lorenzo Stoakes (Oracle), Andrew Morton
Cc: Jonathan Corbet, Clemens Ladisch, Arnd Bergmann,
Greg Kroah-Hartman, K . Y . Srinivasan, Haiyang Zhang, Wei Liu,
Dexuan Cui, Long Li, Alexander Shishkin, Maxime Coquelin,
Alexandre Torgue, Miquel Raynal, Richard Weinberger,
Vignesh Raghavendra, Bodo Stroesser, Martin K . Petersen,
David Howells, Marc Dionne, Alexander Viro, Christian Brauner,
Jan Kara, David Hildenbrand, Liam R . Howlett, Mike Rapoport,
Suren Baghdasaryan, Michal Hocko, Jann Horn, Pedro Falcato,
linux-kernel, linux-doc, linux-hyperv, linux-stm32,
linux-arm-kernel, linux-mtd, linux-staging, linux-scsi,
target-devel, linux-afs, linux-fsdevel, linux-mm, Ryan Roberts
In-Reply-To: <d036855c21962c58ace0eb24ecd6d973d77424fe.1774045440.git.ljs@kernel.org>
On 3/20/26 23:39, Lorenzo Stoakes (Oracle) wrote:
> Replace the deprecated mmap callback with mmap_prepare.
>
> Commit f5cf8f07423b ("mtd: Disable mtdchar mmap on MMU systems") commented
> out the CONFIG_MMU part of this function back in 2012, so after ~14 years
> it's probably reasonable to remove this altogether rather than updating
> dead code.
>
> Acked-by: Richard Weinberger <richard@nod.at>
> Signed-off-by: Lorenzo Stoakes (Oracle) <ljs@kernel.org>
Acked-by: Vlastimil Babka (SUSE) <vbabka@kernel.org>
> ---
> drivers/mtd/mtdchar.c | 21 +++------------------
> 1 file changed, 3 insertions(+), 18 deletions(-)
>
> diff --git a/drivers/mtd/mtdchar.c b/drivers/mtd/mtdchar.c
> index 55a43682c567..bf01e6ac7293 100644
> --- a/drivers/mtd/mtdchar.c
> +++ b/drivers/mtd/mtdchar.c
> @@ -1376,27 +1376,12 @@ static unsigned mtdchar_mmap_capabilities(struct file *file)
> /*
> * set up a mapping for shared memory segments
> */
> -static int mtdchar_mmap(struct file *file, struct vm_area_struct *vma)
> +static int mtdchar_mmap_prepare(struct vm_area_desc *desc)
> {
> #ifdef CONFIG_MMU
> - struct mtd_file_info *mfi = file->private_data;
> - struct mtd_info *mtd = mfi->mtd;
> - struct map_info *map = mtd->priv;
> -
> - /* This is broken because it assumes the MTD device is map-based
> - and that mtd->priv is a valid struct map_info. It should be
> - replaced with something that uses the mtd_get_unmapped_area()
> - operation properly. */
> - if (0 /*mtd->type == MTD_RAM || mtd->type == MTD_ROM*/) {
> -#ifdef pgprot_noncached
> - if (file->f_flags & O_DSYNC || map->phys >= __pa(high_memory))
> - vma->vm_page_prot = pgprot_noncached(vma->vm_page_prot);
> -#endif
> - return vm_iomap_memory(vma, map->phys, map->size);
> - }
> return -ENODEV;
> #else
> - return vma->vm_flags & VM_SHARED ? 0 : -EACCES;
> + return vma_desc_test(desc, VMA_SHARED_BIT) ? 0 : -EACCES;
> #endif
> }
>
> @@ -1411,7 +1396,7 @@ static const struct file_operations mtd_fops = {
> #endif
> .open = mtdchar_open,
> .release = mtdchar_close,
> - .mmap = mtdchar_mmap,
> + .mmap_prepare = mtdchar_mmap_prepare,
> #ifndef CONFIG_MMU
> .get_unmapped_area = mtdchar_get_unmapped_area,
> .mmap_capabilities = mtdchar_mmap_capabilities,
^ permalink raw reply
* Re: [PATCH v4 15/21] stm: replace deprecated mmap hook with mmap_prepare
From: Vlastimil Babka (SUSE) @ 2026-03-25 10:24 UTC (permalink / raw)
To: Lorenzo Stoakes (Oracle), Andrew Morton
Cc: Jonathan Corbet, Clemens Ladisch, Arnd Bergmann,
Greg Kroah-Hartman, K . Y . Srinivasan, Haiyang Zhang, Wei Liu,
Dexuan Cui, Long Li, Alexander Shishkin, Maxime Coquelin,
Alexandre Torgue, Miquel Raynal, Richard Weinberger,
Vignesh Raghavendra, Bodo Stroesser, Martin K . Petersen,
David Howells, Marc Dionne, Alexander Viro, Christian Brauner,
Jan Kara, David Hildenbrand, Liam R . Howlett, Mike Rapoport,
Suren Baghdasaryan, Michal Hocko, Jann Horn, Pedro Falcato,
linux-kernel, linux-doc, linux-hyperv, linux-stm32,
linux-arm-kernel, linux-mtd, linux-staging, linux-scsi,
target-devel, linux-afs, linux-fsdevel, linux-mm, Ryan Roberts
In-Reply-To: <9f3d559a264a83cf45518fcf35cc7ef1d7dfd500.1774045440.git.ljs@kernel.org>
On 3/20/26 23:39, Lorenzo Stoakes (Oracle) wrote:
> The f_op->mmap interface is deprecated, so update driver to use its
> successor, mmap_prepare.
>
> The driver previously used vm_iomap_memory(), so this change replaces it
> with its mmap_prepare equivalent, mmap_action_simple_ioremap().
>
> Also, in order to correctly maintain reference counting, add a
> vm_ops->mapped callback to increment the reference count when successfully
> mapped.
>
> Reviewed-by: Suren Baghdasaryan <surenb@google.com>
> Signed-off-by: Lorenzo Stoakes (Oracle) <ljs@kernel.org>
Acked-by: Vlastimil Babka (SUSE) <vbabka@kernel.org>
> ---
> drivers/hwtracing/stm/core.c | 31 +++++++++++++++++++++----------
> 1 file changed, 21 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/hwtracing/stm/core.c b/drivers/hwtracing/stm/core.c
> index 37584e786bb5..f48c6a8a0654 100644
> --- a/drivers/hwtracing/stm/core.c
> +++ b/drivers/hwtracing/stm/core.c
> @@ -666,6 +666,16 @@ static ssize_t stm_char_write(struct file *file, const char __user *buf,
> return count;
> }
>
> +static int stm_mmap_mapped(unsigned long start, unsigned long end, pgoff_t pgoff,
> + const struct file *file, void **vm_private_data)
> +{
> + struct stm_file *stmf = file->private_data;
> + struct stm_device *stm = stmf->stm;
> +
> + pm_runtime_get_sync(&stm->dev);
> + return 0;
> +}
> +
> static void stm_mmap_open(struct vm_area_struct *vma)
> {
> struct stm_file *stmf = vma->vm_file->private_data;
> @@ -684,12 +694,14 @@ static void stm_mmap_close(struct vm_area_struct *vma)
> }
>
> static const struct vm_operations_struct stm_mmap_vmops = {
> + .mapped = stm_mmap_mapped,
> .open = stm_mmap_open,
> .close = stm_mmap_close,
> };
>
> -static int stm_char_mmap(struct file *file, struct vm_area_struct *vma)
> +static int stm_char_mmap_prepare(struct vm_area_desc *desc)
> {
> + struct file *file = desc->file;
> struct stm_file *stmf = file->private_data;
> struct stm_device *stm = stmf->stm;
> unsigned long size, phys;
> @@ -697,10 +709,10 @@ static int stm_char_mmap(struct file *file, struct vm_area_struct *vma)
> if (!stm->data->mmio_addr)
> return -EOPNOTSUPP;
>
> - if (vma->vm_pgoff)
> + if (desc->pgoff)
> return -EINVAL;
>
> - size = vma->vm_end - vma->vm_start;
> + size = vma_desc_size(desc);
>
> if (stmf->output.nr_chans * stm->data->sw_mmiosz != size)
> return -EINVAL;
> @@ -712,13 +724,12 @@ static int stm_char_mmap(struct file *file, struct vm_area_struct *vma)
> if (!phys)
> return -EINVAL;
>
> - pm_runtime_get_sync(&stm->dev);
> -
> - vma->vm_page_prot = pgprot_noncached(vma->vm_page_prot);
> - vm_flags_set(vma, VM_IO | VM_DONTEXPAND | VM_DONTDUMP);
> - vma->vm_ops = &stm_mmap_vmops;
> - vm_iomap_memory(vma, phys, size);
> + desc->page_prot = pgprot_noncached(desc->page_prot);
> + vma_desc_set_flags(desc, VMA_IO_BIT, VMA_DONTEXPAND_BIT,
> + VMA_DONTDUMP_BIT);
> + desc->vm_ops = &stm_mmap_vmops;
>
> + mmap_action_simple_ioremap(desc, phys, size);
> return 0;
> }
>
> @@ -836,7 +847,7 @@ static const struct file_operations stm_fops = {
> .open = stm_char_open,
> .release = stm_char_release,
> .write = stm_char_write,
> - .mmap = stm_char_mmap,
> + .mmap_prepare = stm_char_mmap_prepare,
> .unlocked_ioctl = stm_char_ioctl,
> .compat_ioctl = compat_ptr_ioctl,
> };
^ permalink raw reply
* Re: [PATCH v4 16/21] staging: vme_user: replace deprecated mmap hook with mmap_prepare
From: Vlastimil Babka (SUSE) @ 2026-03-25 10:34 UTC (permalink / raw)
To: Lorenzo Stoakes (Oracle), Andrew Morton
Cc: Jonathan Corbet, Clemens Ladisch, Arnd Bergmann,
Greg Kroah-Hartman, K . Y . Srinivasan, Haiyang Zhang, Wei Liu,
Dexuan Cui, Long Li, Alexander Shishkin, Maxime Coquelin,
Alexandre Torgue, Miquel Raynal, Richard Weinberger,
Vignesh Raghavendra, Bodo Stroesser, Martin K . Petersen,
David Howells, Marc Dionne, Alexander Viro, Christian Brauner,
Jan Kara, David Hildenbrand, Liam R . Howlett, Mike Rapoport,
Suren Baghdasaryan, Michal Hocko, Jann Horn, Pedro Falcato,
linux-kernel, linux-doc, linux-hyperv, linux-stm32,
linux-arm-kernel, linux-mtd, linux-staging, linux-scsi,
target-devel, linux-afs, linux-fsdevel, linux-mm, Ryan Roberts
In-Reply-To: <08ecc1e1d319564fd49b9e9012f994edaff921db.1774045440.git.ljs@kernel.org>
On 3/20/26 23:39, Lorenzo Stoakes (Oracle) wrote:
> The f_op->mmap interface is deprecated, so update driver to use its
> successor, mmap_prepare.
>
> The driver previously used vm_iomap_memory(), so this change replaces it
> with its mmap_prepare equivalent, mmap_action_simple_ioremap().
>
> Functions that wrap mmap() are also converted to wrap mmap_prepare()
> instead.
>
> Also update the documentation accordingly.
>
> Reviewed-by: Suren Baghdasaryan <surenb@google.com>
> Signed-off-by: Lorenzo Stoakes (Oracle) <ljs@kernel.org>
Acked-by: Vlastimil Babka (SUSE) <vbabka@kernel.org>
^ permalink raw reply
* Re: [PATCH v11 03/22] drm: Add new general DRM property "color format"
From: Ville Syrjälä @ 2026-03-25 11:03 UTC (permalink / raw)
To: Maxime Ripard
Cc: Nicolas Frattaroli, Harry Wentland, Leo Li, Rodrigo Siqueira,
Alex Deucher, Christian König, David Airlie, Simona Vetter,
Maarten Lankhorst, Thomas Zimmermann, Andrzej Hajda,
Neil Armstrong, Robert Foss, Laurent Pinchart, Jonas Karlman,
Jernej Skrabec, Sandy Huang, Heiko Stübner, Andy Yan,
Jani Nikula, Rodrigo Vivi, Joonas Lahtinen, Tvrtko Ursulin,
Dmitry Baryshkov, Sascha Hauer, Rob Herring, Jonathan Corbet,
Shuah Khan, kernel, amd-gfx, dri-devel, linux-kernel,
linux-arm-kernel, linux-rockchip, intel-gfx, intel-xe, linux-doc,
Werner Sembach, Andri Yngvason, Marius Vlad
In-Reply-To: <20260325-neat-elegant-raven-ebc9ab@houat>
On Wed, Mar 25, 2026 at 09:24:27AM +0100, Maxime Ripard wrote:
> On Tue, Mar 24, 2026 at 09:53:35PM +0200, Ville Syrjälä wrote:
> > On Tue, Mar 24, 2026 at 08:10:11PM +0100, Nicolas Frattaroli wrote:
> > > On Tuesday, 24 March 2026 18:00:45 Central European Standard Time Ville Syrjälä wrote:
> > > > On Tue, Mar 24, 2026 at 05:01:07PM +0100, Nicolas Frattaroli wrote:
> > > > > +enum drm_connector_color_format {
> > > > > + /**
> > > > > + * @DRM_CONNECTOR_COLOR_FORMAT_AUTO: The driver or display protocol
> > > > > + * helpers should pick a suitable color format. All implementations of a
> > > > > + * specific display protocol must behave the same way with "AUTO", but
> > > > > + * different display protocols do not necessarily have the same "AUTO"
> > > > > + * semantics.
> > > > > + *
> > > > > + * For HDMI, "AUTO" picks RGB, but falls back to YCbCr 4:2:0 if the
> > > > > + * bandwidth required for full-scale RGB is not available, or the mode
> > > > > + * is YCbCr 4:2:0-only, as long as the mode and output both support
> > > > > + * YCbCr 4:2:0.
> > > > > + *
> > > > > + * For display protocols other than HDMI, the recursive bridge chain
> > > > > + * format selection picks the first chain of bridge formats that works,
> > > > > + * as has already been the case before the introduction of the "color
> > > > > + * format" property. Non-HDMI bridges should therefore either sort their
> > > > > + * bus output formats by preference, or agree on a unified auto format
> > > > > + * selection logic that's implemented in a common state helper (like
> > > > > + * how HDMI does it).
> > > > > + */
> > > > > + DRM_CONNECTOR_COLOR_FORMAT_AUTO = 0,
> > > > > +
> > > > > + /**
> > > > > + * @DRM_CONNECTOR_COLOR_FORMAT_RGB444: RGB output format
> > > > > + */
> > > > > + DRM_CONNECTOR_COLOR_FORMAT_RGB444,
> > > > > +
> > > > > + /**
> > > > > + * @DRM_CONNECTOR_COLOR_FORMAT_YCBCR444: YCbCr 4:4:4 output format (ie.
> > > > > + * not subsampled)
> > > > > + */
> > > > > + DRM_CONNECTOR_COLOR_FORMAT_YCBCR444,
> > > > > +
> > > > > + /**
> > > > > + * @DRM_CONNECTOR_COLOR_FORMAT_YCBCR422: YCbCr 4:2:2 output format (ie.
> > > > > + * with horizontal subsampling)
> > > > > + */
> > > > > + DRM_CONNECTOR_COLOR_FORMAT_YCBCR422,
> > > > > +
> > > > > + /**
> > > > > + * @DRM_CONNECTOR_COLOR_FORMAT_YCBCR420: YCbCr 4:2:0 output format (ie.
> > > > > + * with horizontal and vertical subsampling)
> > > > > + */
> > > > > + DRM_CONNECTOR_COLOR_FORMAT_YCBCR420,
> > > >
> > > > Seems like this should document what the quantization range
> > > > should be for each format.
> > > >
> > >
> > > I don't think so? If you want per-component bit depth values,
> > > DRM_FORMAT_* defines would be the appropriate values to use. This
> > > enum is more abstract than that, and is there to communicate
> > > YUV vs. RGB and chroma subsampling, with bit depth being handled
> > > by other properties.
> > >
> > > If you mean the factor used for subsampling, then that'd only be
> > > relevant if YCBCR410 was supported where one chroma plane isn't
> > > halved but quartered in resolution. I suspect 4:1:0 will never
> > > be added; no digital display protocol standard supports it to my
> > > knowledge, and hopefully none ever will.
> >
> > No, I mean the quantization range (16-235 vs. 0-255 etc).
> >
> > The i915 behaviour is that YCbCr is always limited range,
> > RGB can either be full or limited range depending on the
> > "Broadcast RGB" property and other related factors.
>
> So far the HDMI state has both the format and quantization range as
> different fields. I'm not sure we need to document the range in the
> format field, maybe only mention it's not part of the format but has a
> field of its own?
I think we only have it for RGB (on some drivers only?). For YCbCr
I think the assumption is limited range everywhere.
But I'm not really concerned about documenting struct members.
What I'm talking about is the *uapi* docs. Surely userspace
will want to know what the new property actually does so the
uapi needs to be documented properly. And down the line some
new driver might also implement the wrong behaviour if there
is no clear specification.
So I'm thinking (or perhaps hoping) the rule might be something like:
- YCbCr limited range
- RGB full range if "Broadcast RGB" property is not present
- RGB full or limited range based on the "Broadcast RGB" property
if it's present
I think the "Broadcast RGB" property itself might also be lacking
proper uapi docs, so that may need to be remedied as well.
--
Ville Syrjälä
Intel
^ permalink raw reply
* Re: [PATCH v3 03/24] PCI: Require Live Update preserved devices are in singleton iommu_groups
From: Yi Liu @ 2026-03-25 11:12 UTC (permalink / raw)
To: David Matlack
Cc: Alex Williamson, Bjorn Helgaas, Adithya Jayachandran,
Alexander Graf, Alex Mastro, Andrew Morton, Ankit Agrawal,
Arnd Bergmann, Askar Safin, Borislav Petkov (AMD), Chris Li,
Dapeng Mi, David Rientjes, Feng Tang, Jacob Pan, Jason Gunthorpe,
Jason Gunthorpe, Jonathan Corbet, Josh Hilke, Kees Cook,
Kevin Tian, kexec, kvm, Leon Romanovsky, Leon Romanovsky,
linux-doc, linux-kernel, linux-kselftest, linux-mm, linux-pci,
Li RongQing, Lukas Wunner, Marco Elver, Michał Winiarski,
Mike Rapoport, Parav Pandit, Pasha Tatashin, Paul E. McKenney,
Pawan Gupta, Peter Zijlstra (Intel), Pranjal Shrivastava,
Pratyush Yadav, Raghavendra Rao Ananta, Randy Dunlap,
Rodrigo Vivi, Saeed Mahameed, Samiullah Khawaja, Shuah Khan,
Vipin Sharma, Vivek Kasireddy, William Tu, Zhu Yanjun
In-Reply-To: <acLRICLAP5Ccqt9I@google.com>
On 3/25/26 02:00, David Matlack wrote:
> On 2026-03-24 09:07 PM, Yi Liu wrote:
>> On 3/24/26 07:57, David Matlack wrote:
>>> Require that Live Update preserved devices are in singleton iommu_groups
>>> during preservation (outgoing kernel) and retrieval (incoming kernel).
>>>
>>> PCI devices preserved across Live Update will be allowed to perform
>>> memory transactions throughout the Live Update. Thus IOMMU groups for
>>> preserved devices must remain fixed. Since all current use cases for
>>> Live Update are for PCI devices in singleton iommu_groups, require that
>>> as a starting point. This avoids the complexity of needing to enforce
>>> arbitrary iommu_group topologies while still allowing all current use
>>> cases.
>>>
>>> Suggested-by: Jason Gunthorpe <jgg@nvidia.com>
>>> Signed-off-by: David Matlack <dmatlack@google.com>
>>> ---
>>> drivers/pci/liveupdate.c | 34 +++++++++++++++++++++++++++++++++-
>>> 1 file changed, 33 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/drivers/pci/liveupdate.c b/drivers/pci/liveupdate.c
>>> index bec7b3500057..a3dbe06650ff 100644
>>> --- a/drivers/pci/liveupdate.c
>>> +++ b/drivers/pci/liveupdate.c
>>> @@ -75,6 +75,8 @@
>>> *
>>> * * The device must not be a Physical Function (PF).
>>> *
>>> + * * The device must be the only device in its IOMMU group.
>>> + *
>>> * Preservation Behavior
>>> * =====================
>>> *
>>> @@ -105,6 +107,7 @@
>>> #include <linux/bsearch.h>
>>> #include <linux/io.h>
>>> +#include <linux/iommu.h>
>>> #include <linux/kexec_handover.h>
>>> #include <linux/kho/abi/pci.h>
>>> #include <linux/liveupdate.h>
>>> @@ -222,6 +225,31 @@ static void pci_ser_delete(struct pci_ser *ser, struct pci_dev *dev)
>>> ser->nr_devices--;
>>> }
>>> +static int count_devices(struct device *dev, void *__nr_devices)
>>> +{
>>> + (*(int *)__nr_devices)++;
>>> + return 0;
>>> +}
>>> +
>>
>> there was a related discussion on the singleton group check. have you
>> considered the device_group_immutable_singleton() in below link?
>>
>> https://lore.kernel.org/linux-iommu/20220421052121.3464100-4-baolu.lu@linux.intel.com/
>
> Thanks for the link.
>
> Based on the discussion in the follow-up threads, I think the only check
> in that function that is needed on top of what is in this patch to
> ensure group immutability is this one:
>
> /*
> * The device could be considered to be fully isolated if
> * all devices on the path from the device to the host-PCI
> * bridge are protected from peer-to-peer DMA by ACS.
> */
> if (!pci_acs_path_enabled(pdev, NULL, REQ_ACS_FLAGS))
> return false;
>
> However, this would restrict Live Update support to only device
> topologies that have these flags enabled. I am not yet sure if this
> would be overly restrictive for the scenarios we care about supporting.
yes. It's a bit different from that thread in which not only require
singleton group but also need to be immutable.
> An alternative way to ensure immutability would be to block adding
> devices at probe time. i.e. Fail pci_device_group() if the device being
> added has liveupdate_incoming=True, or if the group already contains a
> device with liveupdate_{incoming,outgoing}=True. We would still need the
> check in pci_liveupdate_preserve() to pretect against setting
> liveupdate_outgoing=True on a device in a multi-device group.
this looks good to me. But you'll disallow hotplug-in during liveupdate.
not sure about if any decision w.r.t. hotplug. is it acceptable?
BTW. A question not specific to this patch. If failure happens after
executing kexec, is there any chance to fallback to the prior kernel?
Regards,
Yi Liu
^ permalink raw reply
* Re: [PATCH v11 03/22] drm: Add new general DRM property "color format"
From: Ville Syrjälä @ 2026-03-25 11:17 UTC (permalink / raw)
To: Maxime Ripard
Cc: Nicolas Frattaroli, Harry Wentland, Leo Li, Rodrigo Siqueira,
Alex Deucher, Christian König, David Airlie, Simona Vetter,
Maarten Lankhorst, Thomas Zimmermann, Andrzej Hajda,
Neil Armstrong, Robert Foss, Laurent Pinchart, Jonas Karlman,
Jernej Skrabec, Sandy Huang, Heiko Stübner, Andy Yan,
Jani Nikula, Rodrigo Vivi, Joonas Lahtinen, Tvrtko Ursulin,
Dmitry Baryshkov, Sascha Hauer, Rob Herring, Jonathan Corbet,
Shuah Khan, kernel, amd-gfx, dri-devel, linux-kernel,
linux-arm-kernel, linux-rockchip, intel-gfx, intel-xe, linux-doc,
Werner Sembach, Andri Yngvason, Marius Vlad
In-Reply-To: <acPA60Ci3n_t__xF@intel.com>
On Wed, Mar 25, 2026 at 01:03:07PM +0200, Ville Syrjälä wrote:
> On Wed, Mar 25, 2026 at 09:24:27AM +0100, Maxime Ripard wrote:
> > On Tue, Mar 24, 2026 at 09:53:35PM +0200, Ville Syrjälä wrote:
> > > On Tue, Mar 24, 2026 at 08:10:11PM +0100, Nicolas Frattaroli wrote:
> > > > On Tuesday, 24 March 2026 18:00:45 Central European Standard Time Ville Syrjälä wrote:
> > > > > On Tue, Mar 24, 2026 at 05:01:07PM +0100, Nicolas Frattaroli wrote:
> > > > > > +enum drm_connector_color_format {
> > > > > > + /**
> > > > > > + * @DRM_CONNECTOR_COLOR_FORMAT_AUTO: The driver or display protocol
> > > > > > + * helpers should pick a suitable color format. All implementations of a
> > > > > > + * specific display protocol must behave the same way with "AUTO", but
> > > > > > + * different display protocols do not necessarily have the same "AUTO"
> > > > > > + * semantics.
> > > > > > + *
> > > > > > + * For HDMI, "AUTO" picks RGB, but falls back to YCbCr 4:2:0 if the
> > > > > > + * bandwidth required for full-scale RGB is not available, or the mode
> > > > > > + * is YCbCr 4:2:0-only, as long as the mode and output both support
> > > > > > + * YCbCr 4:2:0.
> > > > > > + *
> > > > > > + * For display protocols other than HDMI, the recursive bridge chain
> > > > > > + * format selection picks the first chain of bridge formats that works,
> > > > > > + * as has already been the case before the introduction of the "color
> > > > > > + * format" property. Non-HDMI bridges should therefore either sort their
> > > > > > + * bus output formats by preference, or agree on a unified auto format
> > > > > > + * selection logic that's implemented in a common state helper (like
> > > > > > + * how HDMI does it).
> > > > > > + */
> > > > > > + DRM_CONNECTOR_COLOR_FORMAT_AUTO = 0,
> > > > > > +
> > > > > > + /**
> > > > > > + * @DRM_CONNECTOR_COLOR_FORMAT_RGB444: RGB output format
> > > > > > + */
> > > > > > + DRM_CONNECTOR_COLOR_FORMAT_RGB444,
> > > > > > +
> > > > > > + /**
> > > > > > + * @DRM_CONNECTOR_COLOR_FORMAT_YCBCR444: YCbCr 4:4:4 output format (ie.
> > > > > > + * not subsampled)
> > > > > > + */
> > > > > > + DRM_CONNECTOR_COLOR_FORMAT_YCBCR444,
> > > > > > +
> > > > > > + /**
> > > > > > + * @DRM_CONNECTOR_COLOR_FORMAT_YCBCR422: YCbCr 4:2:2 output format (ie.
> > > > > > + * with horizontal subsampling)
> > > > > > + */
> > > > > > + DRM_CONNECTOR_COLOR_FORMAT_YCBCR422,
> > > > > > +
> > > > > > + /**
> > > > > > + * @DRM_CONNECTOR_COLOR_FORMAT_YCBCR420: YCbCr 4:2:0 output format (ie.
> > > > > > + * with horizontal and vertical subsampling)
> > > > > > + */
> > > > > > + DRM_CONNECTOR_COLOR_FORMAT_YCBCR420,
> > > > >
> > > > > Seems like this should document what the quantization range
> > > > > should be for each format.
> > > > >
> > > >
> > > > I don't think so? If you want per-component bit depth values,
> > > > DRM_FORMAT_* defines would be the appropriate values to use. This
> > > > enum is more abstract than that, and is there to communicate
> > > > YUV vs. RGB and chroma subsampling, with bit depth being handled
> > > > by other properties.
> > > >
> > > > If you mean the factor used for subsampling, then that'd only be
> > > > relevant if YCBCR410 was supported where one chroma plane isn't
> > > > halved but quartered in resolution. I suspect 4:1:0 will never
> > > > be added; no digital display protocol standard supports it to my
> > > > knowledge, and hopefully none ever will.
> > >
> > > No, I mean the quantization range (16-235 vs. 0-255 etc).
> > >
> > > The i915 behaviour is that YCbCr is always limited range,
> > > RGB can either be full or limited range depending on the
> > > "Broadcast RGB" property and other related factors.
> >
> > So far the HDMI state has both the format and quantization range as
> > different fields. I'm not sure we need to document the range in the
> > format field, maybe only mention it's not part of the format but has a
> > field of its own?
>
> I think we only have it for RGB (on some drivers only?). For YCbCr
> I think the assumption is limited range everywhere.
>
> But I'm not really concerned about documenting struct members.
> What I'm talking about is the *uapi* docs. Surely userspace
> will want to know what the new property actually does so the
> uapi needs to be documented properly. And down the line some
> new driver might also implement the wrong behaviour if there
> is no clear specification.
>
> So I'm thinking (or perhaps hoping) the rule might be something like:
> - YCbCr limited range
> - RGB full range if "Broadcast RGB" property is not present
> - RGB full or limited range based on the "Broadcast RGB" property
> if it's present
>
> I think the "Broadcast RGB" property itself might also be lacking
> proper uapi docs, so that may need to be remedied as well.
Oh, and I think a bunch of infoframe code still needs changes to
set up the quantization range properly for YCbCr. i915 does handle
that part correctly, but eg. hdmi_generate_avi_infoframe() does not.
I didn't spot any changes to that in the series.
--
Ville Syrjälä
Intel
^ permalink raw reply
* Re: kernel-doc overly verbose with V=0
From: Mauro Carvalho Chehab @ 2026-03-25 11:50 UTC (permalink / raw)
To: Jacob Keller
Cc: Jonathan Corbet, Linux Doc Mailing List, Shuah Khan, Randy Dunlap,
linux-kernel@vger.kernel.org
In-Reply-To: <9367d899-53af-4d9c-9320-22fc4dbadca5@intel.com>
On Tue, 24 Mar 2026 13:37:39 -0700
Jacob Keller <jacob.e.keller@intel.com> wrote:
> Hi,
>
> I recently saw some strange behavior with the Python kernel-doc. I was
> seeing the verbose info lines from the kernel-doc script, i.e.:
>
> > Info: ice_ptp_hw.c:5377 Scanning doc for function ice_cgu_get_pin_freq_supp
> > Info: ice_ptp_hw.c:5406 Scanning doc for function ice_cgu_get_pin_name
> > Info: ice_ptp_hw.c:5441 Scanning doc for function ice_cgu_state_to_name
> > Info: ice_ptp_hw.c:5463 Scanning doc for function ice_get_dpll_ref_sw_status
> > Info: ice_ptp_hw.c:5505 Scanning doc for function ice_set_dpll_ref_sw_status
> > Info: ice_ptp_hw.c:5544 Scanning doc for function ice_get_cgu_state
> > Info: ice_ptp_hw.c:5612 Scanning doc for function ice_get_cgu_rclk_pin_info
> > Info: ice_ptp_hw.c:5671 Scanning doc for function ice_cgu_get_output_pin_state_caps
> > Info: ice_ptp_hw.c:5733 Scanning doc for function ice_ptp_lock
> > Info: ice_ptp_hw.c:5770 Scanning doc for function ice_ptp_unlock
> > Info: ice_ptp_hw.c:5782 Scanning doc for function ice_ptp_init_hw
> > Info: ice_ptp_hw.c:5811 Scanning doc for function ice_ptp_write_port_cmd
> > Info: ice_ptp_hw.c:5834 Scanning doc for function ice_ptp_one_port_cmd
> > Info: ice_ptp_hw.c:5866 Scanning doc for function ice_ptp_port_cmd
> > Info: ice_ptp_hw.c:5901 Scanning doc for function ice_ptp_tmr_cmd
> > Info: ice_ptp_hw.c:5934 Scanning doc for function ice_ptp_init_time
> > Info: ice_ptp_hw.c:5986 Scanning doc for function ice_ptp_write_incval
> > Info: ice_ptp_hw.c:6035 Scanning doc for function ice_ptp_write_incval_locked
> > Info: ice_ptp_hw.c:6056 Scanning doc for function ice_ptp_adj_clock
> > Info: ice_ptp_hw.c:6107 Scanning doc for function ice_read_phy_tstamp
> > Info: ice_ptp_hw.c:6134 Scanning doc for function ice_clear_phy_tstamp
> > Info: ice_ptp_hw.c:6164 Scanning doc for function ice_ptp_reset_ts_memory
> > Info: ice_ptp_hw.c:6183 Scanning doc for function ice_ptp_init_phc
> > Info: ice_ptp_hw.c:6215 Scanning doc for function ice_get_phy_tx_tstamp_ready
> > Info: ice_ptp_hw.c:6247 Scanning doc for function ice_check_phy_tx_tstamp_ready
> > Info: ice_ptp_hw.c:6273 Scanning doc for function ice_ptp_config_sfd
> > Info: ice_ptp_hw.c:6293 Scanning doc for function refsync_pin_id_valid
>
> I didn't understand why I was seeing this as it should only be happening
> if running kernel-doc in verbose mode. Then I discovered I had set
> KBUILD_VERBOSE=0 in my environment.
>
> The python kernel-doc implementation reads this in the __init__ for
> KernelFiles() on line 165:
>
> > if not verbose:
> > verbose = bool(os.environ.get("KBUILD_VERBOSE", 0))
>
> After some debugging, I realized this reads KBUILD_VERBOSE as a string,
> then converts it to a boolean using python's standard rules, so "0"
> becomes true, which enables the verbose output.
Looking at tools/docs/sphinx-build-wrapper, it implements verbosity
by doing:
verbose = bool(os.environ.get("KBUILD_VERBOSE", "") != "")
which will also have the same problem as the one you detected.
Perhaps the right fix would be to first convert to int then to bool
on both places, in a way that "" will also be handled properly.
Perhaps with:
try:
verbose = bool(int(os.environ.get("KBUILD_VERBOSE", 0)))
except ValueError:
# Handles an eventual case where verbosity is not a number
# like KBUILD_VERBOSE=""
verbose = False
> This is in contrast to the (now removed) kernel-doc.pl script which
> checked the value for a 1:
>
> > if (defined($ENV{'KBUILD_VERBOSE'}) && $ENV{'KBUILD_VERBOSE'} =~ '1')
> The same behavior happens if you assign V=0 on the command line or to
> any other non-empty string, since when V is set on the command line it
> sets KBUILD_VERBOSE.
That's funny... we did test make V=0 htmldocs / make V=1 htmldocs
It sounds that the problem is only if you explicitly set it without
relying on gnu make.
> Of course, I can remove KBUILD_VERBOSE from my environment, I'm not
> entirely sure when or why I added it.
>
> Would think it would make sense to update the kdoc_files.py script to
> check and interpret the string value the same way the perl script used
> to? It seems reasonable to me that users might set "V=0" thinking that
> it disables the verbosity. Other verbosity checks are based on the
> string containing a 1,
kernel-doc has a set of "-W" flags to control its verbosity. Direct
support for KBUILD_VERBOSE was added there just to make it bug-compatible
with kernel-doc.pl when building via Makefile.
Yet, as using it via "make htmldocs" don't use "-W", IMO it makes
sense to ensure that "-Wall" is enabled if V=1.
> (some even use 2 for even more printing).
Documentation had support for V=2, but this was dropped on this
commit:
c0d3b83100c8 ("kbuild: do not print extra logs for V=2")
> I'm not entirely sure what the best implementation for python is to
> avoid this misinterpretation, so I haven't drafted a proper patch yet.
Perhaps something like the patch below (untested).
--
Thanks,
Mauro
[PATCH] doc tools: better handle KBUILD_VERBOSE
As reported by Jacob, there are troubles when KBUILD_VERBOSE is
set at the environment.
Fix it on both kernel-doc and sphinx-build-wrapper.
Reported-by: Jacob Keller <jacob.e.keller@intel.com>
Closes: https://lore.kernel.org/linux-doc/9367d899-53af-4d9c-9320-22fc4dbadca5@intel.com/
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
diff --git a/tools/docs/sphinx-build-wrapper b/tools/docs/sphinx-build-wrapper
index 2c63d28f639d..1bb962202784 100755
--- a/tools/docs/sphinx-build-wrapper
+++ b/tools/docs/sphinx-build-wrapper
@@ -238,7 +238,12 @@ class SphinxBuilder:
self.latexopts = os.environ.get("LATEXOPTS", "")
if not verbose:
- verbose = bool(os.environ.get("KBUILD_VERBOSE", "") != "")
+ try:
+ verbose = bool(int(os.environ.get("KBUILD_VERBOSE", 0)))
+ except ValueError:
+ # Handles an eventual case where verbosity is not a number
+ # like KBUILD_VERBOSE=""
+ verbose = False
if verbose is not None:
self.verbose = verbose
diff --git a/tools/lib/python/kdoc/kdoc_files.py b/tools/lib/python/kdoc/kdoc_files.py
index 2428cfc4e843..40984ea78f12 100644
--- a/tools/lib/python/kdoc/kdoc_files.py
+++ b/tools/lib/python/kdoc/kdoc_files.py
@@ -238,7 +238,22 @@ class KernelFiles():
"""
if not verbose:
- verbose = bool(os.environ.get("KBUILD_VERBOSE", 0))
+ try:
+ verbose = bool(int(os.environ.get("KBUILD_VERBOSE", 0)))
+ except ValueError:
+ # Handles an eventual case where verbosity is not a number
+ # like KBUILD_VERBOSE=""
+ verbose = False
+
+ #
+ # kernel-doc logic was likelly called via Sphinx.
+ # Enable all warnings.
+ #
+ if verbose:
+ werror=True
+ wreturn=True
+ wshort_desc=True
+ wcontents_before_sections=True
if out_style is None:
out_style = OutputFormat()
^ permalink raw reply related
* Re: [PATCH V9 1/8] dax: move dax_pgoff_to_phys from [drivers/dax/] device.c to bus.c
From: Jonathan Cameron @ 2026-03-25 11:55 UTC (permalink / raw)
To: Ira Weiny
Cc: John Groves, John Groves, Miklos Szeredi, Dan Williams,
Bernd Schubert, Alison Schofield, John Groves, Jonathan Corbet,
Shuah Khan, Vishal Verma, Dave Jiang, Matthew Wilcox, Jan Kara,
Alexander Viro, David Hildenbrand, Christian Brauner,
Darrick J . Wong, Randy Dunlap, Jeff Layton, Amir Goldstein,
Stefan Hajnoczi, Joanne Koong, Josef Bacik, Bagas Sanjaya,
Chen Linxuan, James Morse, Fuad Tabba, Sean Christopherson,
Shivank Garg, Ackerley Tng, Gregory Price, Aravind Ramesh,
Ajay Joshi, venkataravis@micron.com, linux-doc@vger.kernel.org,
linux-kernel@vger.kernel.org, nvdimm@lists.linux.dev,
linux-cxl@vger.kernel.org, linux-fsdevel@vger.kernel.org
In-Reply-To: <69c321d5e7195_e9d8d10040@iweiny-mobl.notmuch>
On Tue, 24 Mar 2026 18:44:21 -0500
Ira Weiny <ira.weiny@intel.com> wrote:
> Jonathan Cameron wrote:
> > On Tue, 24 Mar 2026 00:37:53 +0000
> > John Groves <john@jagalactic.com> wrote:
> >
> > > From: John Groves <john@groves.net>
> > >
> > > This function will be used by both device.c and fsdev.c, but both are
> > > loadable modules. Moving to bus.c puts it in core and makes it available
> > > to both.
> > >
> > > No code changes - just relocated.
> > >
> > > Reviewed-by: Ira Weiny <ira.weiny@intel.com>
> > > Reviewed-by: Dave Jiang <dave.jiang@intel.com>
> > > Signed-off-by: John Groves <john@groves.net>
> > Obviously this is a straight forward code move... But I can't resist
> > commenting on what is moving (feel free to ignore! or maybe a follow
> > up patch if you agree.
> >
> > Reviewed-by: Jonathan Cameron <jonathan.cameron@huawei.com>
>
> Added this to the series. LMK if I missed something.
LGTM.
Reviewed-by: Jonathan Cameron <jonathan.cameron@huawei.com>
(don't bother adding it unless you are touching the tree for some other reason!)
>
> Ira
>
> ---
> commit ccc1878ab00178e82108bdd1ece497388a24290b (HEAD -> nvdimm-famfs-dax)
> Author: Ira Weiny <ira.weiny@intel.com>
> Date: Tue Mar 24 12:36:19 2026 -0500
>
> dax: Modernize dax_pgoff_to_phys()
>
> The patch to move dax_pgoff_to_phys() to bus.c revealed that the
> function could be improved with more modern style and the newer
> in_range() utility function.
>
> Update it while we are moving it around.
>
> Link: https://lore.kernel.org/all/20260324141806.000003f7@huawei.com/
> Suggested-by: Jonathan Cameron <jonathan.cameron@huawei.com>
> Signed-off-by: Ira Weiny <ira.weiny@intel.com>
>
> diff --git a/drivers/dax/bus.c b/drivers/dax/bus.c
> index e4bd5c9f006c..1b412264bb36 100644
> --- a/drivers/dax/bus.c
> +++ b/drivers/dax/bus.c
> @@ -1421,16 +1421,12 @@ static const struct device_type dev_dax_type = {
> __weak phys_addr_t dax_pgoff_to_phys(struct dev_dax *dev_dax, pgoff_t pgoff,
> unsigned long size)
> {
> - int i;
> -
> - for (i = 0; i < dev_dax->nr_range; i++) {
> + for (int i = 0; i < dev_dax->nr_range; i++) {
> struct dev_dax_range *dax_range = &dev_dax->ranges[i];
> struct range *range = &dax_range->range;
> - unsigned long long pgoff_end;
> phys_addr_t phys;
>
> - pgoff_end = dax_range->pgoff + PHYS_PFN(range_len(range)) - 1;
> - if (pgoff < dax_range->pgoff || pgoff > pgoff_end)
> + if (!in_range(pgoff, dax_range->pgoff, PHYS_PFN(range_len(range))))
> continue;
> phys = PFN_PHYS(pgoff - dax_range->pgoff) + range->start;
> if (phys + size - 1 <= range->end)
>
^ permalink raw reply
* [s390:features 6/11] Warning: drivers/s390/crypto/zcrypt_msgtype6.c:1253 This comment starts with '/**', but isn't a kernel-doc comment. Refer to Documentation/doc-guide/kernel-doc.rst
From: kernel test robot @ 2026-03-25 12:18 UTC (permalink / raw)
To: Harald Freudenberger
Cc: llvm, oe-kbuild-all, linux-s390, Vasily Gorbik, Holger Dengler,
Anthony Krowiak, linux-doc
tree: https://git.kernel.org/pub/scm/linux/kernel/git/s390/linux.git features
head: 2a0a1db5081df02d6753deb1826fd3932a1ab168
commit: 23a4757d6d699e602b358808359149d0e8be6db9 [6/11] s390/zcrypt: Move inline function rng_type6cprb_msgx from header to code
config: s390-randconfig-001-20260325 (https://download.01.org/0day-ci/archive/20260325/202603252022.vEojGo3V-lkp@intel.com/config)
compiler: clang version 23.0.0git (https://github.com/llvm/llvm-project 054e11d1a17e5ba88bb1a8ef32fad3346e80b186)
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20260325/202603252022.vEojGo3V-lkp@intel.com/reproduce)
If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202603252022.vEojGo3V-lkp@intel.com/
All warnings (new ones prefixed by >>):
>> Warning: drivers/s390/crypto/zcrypt_msgtype6.c:1253 This comment starts with '/**', but isn't a kernel-doc comment. Refer to Documentation/doc-guide/kernel-doc.rst
* Prepare a type6 CPRB message for random number generation
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply
* Re: [PATCH V9 3/8] dax: add fsdev.c driver for fs-dax on character dax
From: John Groves @ 2026-03-25 12:43 UTC (permalink / raw)
To: Jonathan Cameron
Cc: John Groves, Miklos Szeredi, Dan Williams, Bernd Schubert,
Alison Schofield, John Groves, Jonathan Corbet, Shuah Khan,
Vishal Verma, Dave Jiang, Matthew Wilcox, Jan Kara,
Alexander Viro, David Hildenbrand, Christian Brauner,
Darrick J . Wong, Randy Dunlap, Jeff Layton, Amir Goldstein,
Stefan Hajnoczi, Joanne Koong, Josef Bacik, Bagas Sanjaya,
Chen Linxuan, James Morse, Fuad Tabba, Sean Christopherson,
Shivank Garg, Ackerley Tng, Gregory Price, Aravind Ramesh,
Ajay Joshi, venkataravis@micron.com, linux-doc@vger.kernel.org,
linux-kernel@vger.kernel.org, nvdimm@lists.linux.dev,
linux-cxl@vger.kernel.org, linux-fsdevel@vger.kernel.org
In-Reply-To: <20260324143927.000024c3@huawei.com>
On 26/03/24 02:39PM, Jonathan Cameron wrote:
> On Tue, 24 Mar 2026 00:38:31 +0000
> John Groves <john@jagalactic.com> wrote:
>
> > From: John Groves <john@groves.net>
> >
> > The new fsdev driver provides pages/folios initialized compatibly with
> > fsdax - normal rather than devdax-style refcounting, and starting out
> > with order-0 folios.
> >
> > When fsdev binds to a daxdev, it is usually (always?) switching from the
> > devdax mode (device.c), which pre-initializes compound folios according
> > to its alignment. Fsdev uses fsdev_clear_folio_state() to switch the
> > folios into a fsdax-compatible state.
> >
> > A side effect of this is that raw mmap doesn't (can't?) work on an fsdev
> > dax instance. Accordingly, The fsdev driver does not provide raw mmap -
> > devices must be put in 'devdax' mode (drivers/dax/device.c) to get raw
> > mmap capability.
> >
> > In this commit is just the framework, which remaps pages/folios compatibly
> > with fsdax.
> >
> > Enabling dax changes:
> >
> > - bus.h: add DAXDRV_FSDEV_TYPE driver type
> > - bus.c: allow DAXDRV_FSDEV_TYPE drivers to bind to daxdevs
> > - dax.h: prototype inode_dax(), which fsdev needs
> >
> > Suggested-by: Dan Williams <dan.j.williams@intel.com>
> > Suggested-by: Gregory Price <gourry@gourry.net>
> > Signed-off-by: John Groves <john@groves.net>
>
> I was kind of thinking you'd go with a hidden KCONFIG option with default
> magic to do the same build condition to you had in the Makefil, but one the
> user can opt in or out for is also fine.
>
> Comments on that below. Meh, I think this is better anyway :)
>
> Reviewed-by: Jonathan Cameron <jonathan.cameron@huawei.com>
>
>
>
> > diff --git a/drivers/dax/Kconfig b/drivers/dax/Kconfig
> > index d656e4c0eb84..7051b70980d5 100644
> > --- a/drivers/dax/Kconfig
> > +++ b/drivers/dax/Kconfig
> > @@ -61,6 +61,17 @@ config DEV_DAX_HMEM_DEVICES
> > depends on DEV_DAX_HMEM && DAX
> > def_bool y
> >
> > +config DEV_DAX_FSDEV
> > + tristate "FSDEV DAX: fs-dax compatible devdax driver"
> > + depends on DEV_DAX && FS_DAX
> > + help
> > + Support fs-dax access to DAX devices via a character device
> > + interface. Unlike device_dax (which pre-initializes compound folios
> > + based on device alignment), this driver leaves folios at order-0 so
> > + that fs-dax filesystems can manage folio order dynamically.
> > +
> > + Say M if unsure.
> Fine like this, but if you wanted to hide it in interests of not
> confusing users...
>
> config DEV_DAX_FSDEV
> tristate
> depends on DEV_DAX && FS_DAX
> default DEV_DAX
I like this better. I see no reason not to default to including fsdev.
It does nothing other than frustrating famfs users if it's off - since
building it still has no effect unless you put a daxdev in famfs mode.
Ira, it's kinda in your hands at the moment. Do you feel like making this
change?
>
> > +
> > config DEV_DAX_KMEM
> > tristate "KMEM DAX: map dax-devices as System-RAM"
> > default DEV_DAX
>
> > +}
>
^ permalink raw reply
* Re: [PATCH] doc: Add CPU Isolation documentation
From: Frederic Weisbecker @ 2026-03-25 12:45 UTC (permalink / raw)
To: Sebastian Andrzej Siewior
Cc: LKML, Anna-Maria Behnsen, Gabriele Monaco, Ingo Molnar,
Jonathan Corbet, Marcelo Tosatti, Marco Crivellari, Michal Hocko,
Paul E . McKenney, Peter Zijlstra, Phil Auld, Steven Rostedt,
Thomas Gleixner, Valentin Schneider, Vlastimil Babka, Waiman Long,
linux-doc, John Ogness
In-Reply-To: <20260320151036.v_Sn93P-@linutronix.de>
Le Fri, Mar 20, 2026 at 04:10:36PM +0100, Sebastian Andrzej Siewior a écrit :
> On 2025-08-09 11:42:47 [+0200], Frederic Weisbecker wrote:
> > --- /dev/null
> > +++ b/Documentation/admin-guide/cpu-isolation.rst
> > @@ -0,0 +1,338 @@
> You could start with
>
> .. SPDX-License-Identifier: GPL-2.0
>
> at the top.
Ok.
>
> > +=============
> > +CPU Isolation
> > +=============
> …
> > +Interface
> > +~~~~~~~~~
> > +
> > +- :ref:`Documentation/admin-guide/cgroup-v2.rst <Cpuset v2 "isolated"
> > + partitions>`
>
> I've been told by Jonathan once to just use the .rst file without
> anything around it and the HTML render will make the link on its own.
>
> …
Hmm, how would that look like? Just this?
+- Documentation/admin-guide/cgroup-v2.rst
>
> > +Tradeoffs
> > +~~~~~~~~~
> > +
> > +In terms of cost, this is the most invasive isolation feature. It is
> > +assumed to be used when the workload spends most of its time in
> > +userspace and doesn't rely on the kernel except for preparatory
> > +work because:
> > +
> > +- RCU is slower due to the locked, offloaded and threaded callbacks
> > + processing (the same that would be obtained with "rcu_nocb=" boot
> > + parameter).
>
> You mean the callback invocation is delayed? It shouldn't affect grace
> period handling and so on.
>
> …
Right.
>
> > +Checklist
> > +=========
> > +
> > +You have set up each of the above isolation features but you still
> > +observe jitters that trash your workload? Make sure to check a few
> > +elements before proceeding.
> > +
> > +Some of these checklist items are similar to those of real time
> > +workloads:
> > +
> > +- Use mlock() to prevent your pages from being swapped away. Page
> > + faults are usually not compatible with jitter sensitive workloads.
> > +
> > +- Avoid SMT to prevent your hardware thread from being "preempted"
> > + by another one.
> > +
> > +- CPU frequency changes may induce subtle sorts of jitter in a
> > + workload. Cpufreq should be used and tuned with caution.
> > +
> > +- Deep C-states may result in latency issues upon wake-up. If this
> > + happens to be a problem, C-states can be limited via kernel boot
> > + parameters such as processor.max_cstate or intel_idle.max_cstate.
> > +
>
> I intended to make a similar list similar to this for the real time part
> but it somehow faded away. There is now the idea to identify kernel
> options which are not so optimal which include CPU frequency for
> instance. The requirements here are should be the same.
We should probably have this to a seperate file that both isolation and rt could
link to?
Thanks.
--
Frederic Weisbecker
SUSE Labs
^ permalink raw reply
* Re: [PATCH v4 0/8] scalable symbol flags with __kflagstab
From: Petr Pavlu @ 2026-03-25 12:49 UTC (permalink / raw)
To: Siddharth Nayyar
Cc: Luis Chamberlain, Daniel Gomez, Sami Tolvanen, Aaron Tomlin,
Arnd Bergmann, Nathan Chancellor, Nicolas Schier, Jonathan Corbet,
Shuah Khan, linux-modules, linux-kernel, linux-arch, linux-kbuild,
linux-doc, maennich, gprocida
In-Reply-To: <20260305-kflagstab-v4-0-6a76bf8b83c7@google.com>
On 3/5/26 5:55 PM, Siddharth Nayyar wrote:
> This patch series implements a mechanism for scalable exported symbol
> flags using a separate section called __kflagstab. The series introduces
> __kflagstab support, removes *_gpl sections in favor of a GPL flag,
> simplifies symbol resolution during module loading.
I noticed that the series has a bisecting issue. The module loader
doesn't see any GPL-only exports after patch #4. I think you'll need to
squash patches #4 and #5 to fix this. Alternatively, the patches could
be swapped, with the caveat that GPL-only symbols would lose their GPL
property for one commit.
Nit: Please use simply the "module" prefix in commit subjects:
#1: module: define ksym_flags enumeration to represent kernel symbol flags
#2: module: add kflagstab section to vmlinux and modules
#4: module: use kflagstab instead of *_gpl sections
#6: module: deprecate usage of *_gpl sections
#7: module: remove *_gpl sections from vmlinux and modules
The changes look otherwise ok to me. With the above fixed, feel free to
add:
Reviewed-by: Petr Pavlu <petr.pavlu@suse.com>
--
Thanks,
Petr
^ permalink raw reply
* Re: [PATCH v11 03/22] drm: Add new general DRM property "color format"
From: Dave Stevenson @ 2026-03-25 12:49 UTC (permalink / raw)
To: Nicolas Frattaroli
Cc: Harry Wentland, Leo Li, Rodrigo Siqueira, Alex Deucher,
Christian König, David Airlie, Simona Vetter,
Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann,
Andrzej Hajda, Neil Armstrong, Robert Foss, Laurent Pinchart,
Jonas Karlman, Jernej Skrabec, Sandy Huang, Heiko Stübner,
Andy Yan, Jani Nikula, Rodrigo Vivi, Joonas Lahtinen,
Tvrtko Ursulin, Dmitry Baryshkov, Sascha Hauer, Rob Herring,
Jonathan Corbet, Shuah Khan, kernel, amd-gfx, dri-devel,
linux-kernel, linux-arm-kernel, linux-rockchip, intel-gfx,
intel-xe, linux-doc, Werner Sembach, Andri Yngvason, Marius Vlad
In-Reply-To: <20260324-color-format-v11-3-605559af4fb4@collabora.com>
On Tue, 24 Mar 2026 at 16:02, Nicolas Frattaroli
<nicolas.frattaroli@collabora.com> wrote:
>
> Add a new general DRM property named "color format" which can be used by
> userspace to request the display driver to output a particular color
> format.
>
> Possible options are:
> - auto (setup by default, driver internally picks the color format)
> - rgb
> - ycbcr444
> - ycbcr422
> - ycbcr420
>
> Drivers should advertise from this list which formats they support.
> Together with this list and EDID data from the sink we should be able
> to relay a list of usable color formats to users to pick from.
>
> Co-developed-by: Werner Sembach <wse@tuxedocomputers.com>
> Signed-off-by: Werner Sembach <wse@tuxedocomputers.com>
> Co-developed-by: Andri Yngvason <andri@yngvason.is>
> Signed-off-by: Andri Yngvason <andri@yngvason.is>
> Signed-off-by: Marius Vlad <marius.vlad@collabora.com>
> Reviewed-by: Maxime Ripard <mripard@kernel.org>
> Signed-off-by: Nicolas Frattaroli <nicolas.frattaroli@collabora.com>
> ---
> drivers/gpu/drm/drm_atomic_helper.c | 5 ++
> drivers/gpu/drm/drm_atomic_uapi.c | 11 ++++
> drivers/gpu/drm/drm_connector.c | 108 ++++++++++++++++++++++++++++++++++++
> include/drm/drm_connector.h | 104 ++++++++++++++++++++++++++++++++++
> 4 files changed, 228 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_atomic_helper.c b/drivers/gpu/drm/drm_atomic_helper.c
> index 26953ed6b53e..b7753454b777 100644
> --- a/drivers/gpu/drm/drm_atomic_helper.c
> +++ b/drivers/gpu/drm/drm_atomic_helper.c
> @@ -737,6 +737,11 @@ drm_atomic_helper_check_modeset(struct drm_device *dev,
> if (old_connector_state->max_requested_bpc !=
> new_connector_state->max_requested_bpc)
> new_crtc_state->connectors_changed = true;
> +
> + if (old_connector_state->color_format !=
> + new_connector_state->color_format)
> + new_crtc_state->connectors_changed = true;
> +
> }
>
> if (funcs->atomic_check)
> diff --git a/drivers/gpu/drm/drm_atomic_uapi.c b/drivers/gpu/drm/drm_atomic_uapi.c
> index 5bd5bf6661df..dee510c85e59 100644
> --- a/drivers/gpu/drm/drm_atomic_uapi.c
> +++ b/drivers/gpu/drm/drm_atomic_uapi.c
> @@ -935,6 +935,15 @@ static int drm_atomic_connector_set_property(struct drm_connector *connector,
> state->privacy_screen_sw_state = val;
> } else if (property == connector->broadcast_rgb_property) {
> state->hdmi.broadcast_rgb = val;
> + } else if (property == connector->color_format_property) {
> + if (val > INT_MAX || !drm_connector_color_format_valid(val)) {
> + drm_dbg_atomic(connector->dev,
> + "[CONNECTOR:%d:%s] unknown color format %llu\n",
> + connector->base.id, connector->name, val);
> + return -EINVAL;
> + }
> +
> + state->color_format = val;
> } else if (connector->funcs->atomic_set_property) {
> return connector->funcs->atomic_set_property(connector,
> state, property, val);
> @@ -1020,6 +1029,8 @@ drm_atomic_connector_get_property(struct drm_connector *connector,
> *val = state->privacy_screen_sw_state;
> } else if (property == connector->broadcast_rgb_property) {
> *val = state->hdmi.broadcast_rgb;
> + } else if (property == connector->color_format_property) {
> + *val = state->color_format;
> } else if (connector->funcs->atomic_get_property) {
> return connector->funcs->atomic_get_property(connector,
> state, property, val);
> diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
> index 47dc53c4a738..e848374dee0b 100644
> --- a/drivers/gpu/drm/drm_connector.c
> +++ b/drivers/gpu/drm/drm_connector.c
> @@ -1388,6 +1388,18 @@ static const u32 hdmi_colorspaces =
> BIT(DRM_MODE_COLORIMETRY_DCI_P3_RGB_D65) |
> BIT(DRM_MODE_COLORIMETRY_DCI_P3_RGB_THEATER);
>
> +static const u32 hdmi_colorformats =
> + BIT(DRM_OUTPUT_COLOR_FORMAT_RGB444) |
> + BIT(DRM_OUTPUT_COLOR_FORMAT_YCBCR444) |
> + BIT(DRM_OUTPUT_COLOR_FORMAT_YCBCR422) |
> + BIT(DRM_OUTPUT_COLOR_FORMAT_YCBCR420);
> +
> +static const u32 dp_colorformats =
> + BIT(DRM_OUTPUT_COLOR_FORMAT_RGB444) |
> + BIT(DRM_OUTPUT_COLOR_FORMAT_YCBCR444) |
> + BIT(DRM_OUTPUT_COLOR_FORMAT_YCBCR422) |
> + BIT(DRM_OUTPUT_COLOR_FORMAT_YCBCR420);
> +
> /*
> * As per DP 1.4a spec, 2.2.5.7.5 VSC SDP Payload for Pixel Encoding/Colorimetry
> * Format Table 2-120
> @@ -2940,6 +2952,102 @@ int drm_connector_attach_colorspace_property(struct drm_connector *connector)
> }
> EXPORT_SYMBOL(drm_connector_attach_colorspace_property);
>
> +/**
> + * drm_connector_attach_color_format_property - create and attach color format property
> + * @connector: connector to create the color format property on
> + * @supported_color_formats: bitmask of bit-shifted &enum drm_output_color_format
> + * values the connector supports
> + *
> + * Called by a driver to create a color format property. The property is
> + * attached to the connector automatically on success.
> + *
> + * @supported_color_formats should only include color formats the connector
> + * type can actually support.
> + *
> + * Returns:
> + * 0 on success, negative errno on error
> + */
> +int drm_connector_attach_color_format_property(struct drm_connector *connector,
> + unsigned long supported_color_formats)
> +{
> + struct drm_device *dev = connector->dev;
> + struct drm_prop_enum_list enum_list[DRM_CONNECTOR_COLOR_FORMAT_COUNT];
> + unsigned int i = 0;
> + unsigned long fmt;
> +
> + if (connector->color_format_property)
> + return 0;
> +
> + if (!supported_color_formats) {
> + drm_err(dev, "No supported color formats provided on [CONNECTOR:%d:%s]\n",
> + connector->base.id, connector->name);
> + return -EINVAL;
> + }
> +
> + if (supported_color_formats & ~GENMASK(DRM_OUTPUT_COLOR_FORMAT_COUNT - 1, 0)) {
> + drm_err(dev, "Unknown color formats provided on [CONNECTOR:%d:%s]\n",
> + connector->base.id, connector->name);
> + return -EINVAL;
> + }
> +
> + switch (connector->connector_type) {
> + case DRM_MODE_CONNECTOR_HDMIA:
> + case DRM_MODE_CONNECTOR_HDMIB:
> + if (supported_color_formats & ~hdmi_colorformats) {
> + drm_err(dev, "Color formats not allowed for HDMI on [CONNECTOR:%d:%s]\n",
> + connector->base.id, connector->name);
> + return -EINVAL;
> + }
> + break;
> + case DRM_MODE_CONNECTOR_DisplayPort:
> + case DRM_MODE_CONNECTOR_eDP:
> + if (supported_color_formats & ~dp_colorformats) {
> + drm_err(dev, "Color formats not allowed for DP on [CONNECTOR:%d:%s]\n",
> + connector->base.id, connector->name);
> + return -EINVAL;
> + }
> + break;
> + }
> +
> + enum_list[0].name = "AUTO";
> + enum_list[0].type = DRM_CONNECTOR_COLOR_FORMAT_AUTO;
> +
> + for_each_set_bit(fmt, &supported_color_formats, DRM_OUTPUT_COLOR_FORMAT_COUNT) {
> + switch (fmt) {
> + case DRM_OUTPUT_COLOR_FORMAT_RGB444:
> + enum_list[++i].type = DRM_CONNECTOR_COLOR_FORMAT_RGB444;
> + break;
> + case DRM_OUTPUT_COLOR_FORMAT_YCBCR444:
> + enum_list[++i].type = DRM_CONNECTOR_COLOR_FORMAT_YCBCR444;
> + break;
> + case DRM_OUTPUT_COLOR_FORMAT_YCBCR422:
> + enum_list[++i].type = DRM_CONNECTOR_COLOR_FORMAT_YCBCR422;
> + break;
> + case DRM_OUTPUT_COLOR_FORMAT_YCBCR420:
> + enum_list[++i].type = DRM_CONNECTOR_COLOR_FORMAT_YCBCR420;
> + break;
> + default:
> + drm_warn(dev, "Unknown supported format %ld on [CONNECTOR:%d:%s]\n",
> + fmt, connector->base.id, connector->name);
> + continue;
> + }
> + enum_list[i].name = drm_hdmi_connector_get_output_format_name(fmt);
> + }
> +
> + connector->color_format_property =
> + drm_property_create_enum(dev, DRM_MODE_PROP_ENUM, "color format",
> + enum_list, i + 1);
> +
> + if (!connector->color_format_property)
> + return -ENOMEM;
> +
> + drm_object_attach_property(&connector->base, connector->color_format_property,
> + DRM_CONNECTOR_COLOR_FORMAT_AUTO);
> +
> + return 0;
> +}
> +EXPORT_SYMBOL(drm_connector_attach_color_format_property);
> +
> /**
> * drm_connector_atomic_hdr_metadata_equal - checks if the hdr metadata changed
> * @old_state: old connector state to compare
> diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
> index af8b92d2d5b7..bd549f912b76 100644
> --- a/include/drm/drm_connector.h
> +++ b/include/drm/drm_connector.h
> @@ -571,14 +571,102 @@ enum drm_colorspace {
> * YCbCr 4:2:2 output format (ie. with horizontal subsampling)
> * @DRM_OUTPUT_COLOR_FORMAT_YCBCR420:
> * YCbCr 4:2:0 output format (ie. with horizontal and vertical subsampling)
> + * @DRM_OUTPUT_COLOR_FORMAT_COUNT:
> + * Number of valid output color format values in this enum
> */
> enum drm_output_color_format {
> DRM_OUTPUT_COLOR_FORMAT_RGB444 = 0,
> DRM_OUTPUT_COLOR_FORMAT_YCBCR444,
> DRM_OUTPUT_COLOR_FORMAT_YCBCR422,
> DRM_OUTPUT_COLOR_FORMAT_YCBCR420,
> + DRM_OUTPUT_COLOR_FORMAT_COUNT,
> };
>
> +/**
> + * enum drm_connector_color_format - Connector Color Format Request
> + *
> + * This enum, unlike &enum drm_output_color_format, is used to specify requests
> + * for a specific color format on a connector through the DRM "color format"
> + * property. The difference is that it has an "AUTO" value to specify that
> + * no specific choice has been made.
> + */
> +enum drm_connector_color_format {
> + /**
> + * @DRM_CONNECTOR_COLOR_FORMAT_AUTO: The driver or display protocol
> + * helpers should pick a suitable color format. All implementations of a
> + * specific display protocol must behave the same way with "AUTO", but
> + * different display protocols do not necessarily have the same "AUTO"
> + * semantics.
> + *
> + * For HDMI, "AUTO" picks RGB, but falls back to YCbCr 4:2:0 if the
> + * bandwidth required for full-scale RGB is not available, or the mode
> + * is YCbCr 4:2:0-only, as long as the mode and output both support
> + * YCbCr 4:2:0.
Is there a reason you propose dropping back to YCbCr 4:2:0 without
trying YCbCr 4:2:2 first? Minimising the subsampling is surely
beneficial, and vc4 for one can do 4:2:2 but not 4:2:0.
Dave
> + *
> + * For display protocols other than HDMI, the recursive bridge chain
> + * format selection picks the first chain of bridge formats that works,
> + * as has already been the case before the introduction of the "color
> + * format" property. Non-HDMI bridges should therefore either sort their
> + * bus output formats by preference, or agree on a unified auto format
> + * selection logic that's implemented in a common state helper (like
> + * how HDMI does it).
> + */
> + DRM_CONNECTOR_COLOR_FORMAT_AUTO = 0,
> +
> + /**
> + * @DRM_CONNECTOR_COLOR_FORMAT_RGB444: RGB output format
> + */
> + DRM_CONNECTOR_COLOR_FORMAT_RGB444,
> +
> + /**
> + * @DRM_CONNECTOR_COLOR_FORMAT_YCBCR444: YCbCr 4:4:4 output format (ie.
> + * not subsampled)
> + */
> + DRM_CONNECTOR_COLOR_FORMAT_YCBCR444,
> +
> + /**
> + * @DRM_CONNECTOR_COLOR_FORMAT_YCBCR422: YCbCr 4:2:2 output format (ie.
> + * with horizontal subsampling)
> + */
> + DRM_CONNECTOR_COLOR_FORMAT_YCBCR422,
> +
> + /**
> + * @DRM_CONNECTOR_COLOR_FORMAT_YCBCR420: YCbCr 4:2:0 output format (ie.
> + * with horizontal and vertical subsampling)
> + */
> + DRM_CONNECTOR_COLOR_FORMAT_YCBCR420,
> +
> + /**
> + * @DRM_CONNECTOR_COLOR_FORMAT_COUNT: Number of valid connector color
> + * format values in this enum
> + */
> + DRM_CONNECTOR_COLOR_FORMAT_COUNT,
> +};
> +
> +/**
> + * drm_connector_color_format_valid - Validate drm_connector_color_format value
> + * @fmt: value to check against all values of &enum drm_connector_color_format
> + *
> + * Checks whether the passed in value of @fmt is one of the allowable values in
> + * &enum drm_connector_color_format.
> + *
> + * Returns: %true if it's a valid value for the enum, %false otherwise.
> + */
> +static inline bool __pure
> +drm_connector_color_format_valid(enum drm_connector_color_format fmt)
> +{
> + switch (fmt) {
> + case DRM_CONNECTOR_COLOR_FORMAT_AUTO:
> + case DRM_CONNECTOR_COLOR_FORMAT_RGB444:
> + case DRM_CONNECTOR_COLOR_FORMAT_YCBCR444:
> + case DRM_CONNECTOR_COLOR_FORMAT_YCBCR422:
> + case DRM_CONNECTOR_COLOR_FORMAT_YCBCR420:
> + return true;
> + default:
> + return false;
> + }
> +}
> +
> const char *
> drm_hdmi_connector_get_output_format_name(enum drm_output_color_format fmt);
>
> @@ -1129,6 +1217,13 @@ struct drm_connector_state {
> */
> enum drm_colorspace colorspace;
>
> + /**
> + * @color_format: State variable for Connector property to request
> + * color format change on Sink. This is most commonly used to switch
> + * between RGB to YUV and vice-versa.
> + */
> + enum drm_connector_color_format color_format;
> +
> /**
> * @writeback_job: Writeback job for writeback connectors
> *
> @@ -2127,6 +2222,12 @@ struct drm_connector {
> */
> struct drm_property *colorspace_property;
>
> + /**
> + * @color_format_property: Connector property to set the suitable
> + * color format supported by the sink.
> + */
> + struct drm_property *color_format_property;
> +
> /**
> * @path_blob_ptr:
> *
> @@ -2610,6 +2711,9 @@ bool drm_connector_has_possible_encoder(struct drm_connector *connector,
> struct drm_encoder *encoder);
> const char *drm_get_colorspace_name(enum drm_colorspace colorspace);
>
> +int drm_connector_attach_color_format_property(struct drm_connector *connector,
> + unsigned long supported_color_formats);
> +
> /**
> * drm_for_each_connector_iter - connector_list iterator macro
> * @connector: &struct drm_connector pointer used as cursor
>
> --
> 2.53.0
>
^ permalink raw reply
* Re: [PATCH v11 03/22] drm: Add new general DRM property "color format"
From: Maxime Ripard @ 2026-03-25 13:05 UTC (permalink / raw)
To: Dave Stevenson
Cc: Nicolas Frattaroli, Harry Wentland, Leo Li, Rodrigo Siqueira,
Alex Deucher, Christian König, David Airlie, Simona Vetter,
Maarten Lankhorst, Thomas Zimmermann, Andrzej Hajda,
Neil Armstrong, Robert Foss, Laurent Pinchart, Jonas Karlman,
Jernej Skrabec, Sandy Huang, Heiko Stübner, Andy Yan,
Jani Nikula, Rodrigo Vivi, Joonas Lahtinen, Tvrtko Ursulin,
Dmitry Baryshkov, Sascha Hauer, Rob Herring, Jonathan Corbet,
Shuah Khan, kernel, amd-gfx, dri-devel, linux-kernel,
linux-arm-kernel, linux-rockchip, intel-gfx, intel-xe, linux-doc,
Werner Sembach, Andri Yngvason, Marius Vlad
In-Reply-To: <CAPY8ntB9f_=f5kru=8w9BpTuqQR+93maGpT61EKU28Uay2vq8Q@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2493 bytes --]
Hi Dave,
On Wed, Mar 25, 2026 at 12:49:19PM +0000, Dave Stevenson wrote:
> > diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
> > index af8b92d2d5b7..bd549f912b76 100644
> > --- a/include/drm/drm_connector.h
> > +++ b/include/drm/drm_connector.h
> > @@ -571,14 +571,102 @@ enum drm_colorspace {
> > * YCbCr 4:2:2 output format (ie. with horizontal subsampling)
> > * @DRM_OUTPUT_COLOR_FORMAT_YCBCR420:
> > * YCbCr 4:2:0 output format (ie. with horizontal and vertical subsampling)
> > + * @DRM_OUTPUT_COLOR_FORMAT_COUNT:
> > + * Number of valid output color format values in this enum
> > */
> > enum drm_output_color_format {
> > DRM_OUTPUT_COLOR_FORMAT_RGB444 = 0,
> > DRM_OUTPUT_COLOR_FORMAT_YCBCR444,
> > DRM_OUTPUT_COLOR_FORMAT_YCBCR422,
> > DRM_OUTPUT_COLOR_FORMAT_YCBCR420,
> > + DRM_OUTPUT_COLOR_FORMAT_COUNT,
> > };
> >
> > +/**
> > + * enum drm_connector_color_format - Connector Color Format Request
> > + *
> > + * This enum, unlike &enum drm_output_color_format, is used to specify requests
> > + * for a specific color format on a connector through the DRM "color format"
> > + * property. The difference is that it has an "AUTO" value to specify that
> > + * no specific choice has been made.
> > + */
> > +enum drm_connector_color_format {
> > + /**
> > + * @DRM_CONNECTOR_COLOR_FORMAT_AUTO: The driver or display protocol
> > + * helpers should pick a suitable color format. All implementations of a
> > + * specific display protocol must behave the same way with "AUTO", but
> > + * different display protocols do not necessarily have the same "AUTO"
> > + * semantics.
> > + *
> > + * For HDMI, "AUTO" picks RGB, but falls back to YCbCr 4:2:0 if the
> > + * bandwidth required for full-scale RGB is not available, or the mode
> > + * is YCbCr 4:2:0-only, as long as the mode and output both support
> > + * YCbCr 4:2:0.
>
> Is there a reason you propose dropping back to YCbCr 4:2:0 without
> trying YCbCr 4:2:2 first? Minimising the subsampling is surely
> beneficial, and vc4 for one can do 4:2:2 but not 4:2:0.
The "auto" behaviour is strictly identical to the one we have right now,
and this one stems from i915. Back when all that logic was added, it was
decided to align every driver behavior on i915 because that's what most
compositors would expect.
Maxime
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 273 bytes --]
^ permalink raw reply
* Re: [PATCH v11 03/22] drm: Add new general DRM property "color format"
From: Nicolas Frattaroli @ 2026-03-25 13:05 UTC (permalink / raw)
To: Ville Syrjälä
Cc: Harry Wentland, Leo Li, Rodrigo Siqueira, Alex Deucher,
Christian König, David Airlie, Simona Vetter,
Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann,
Andrzej Hajda, Neil Armstrong, Robert Foss, Laurent Pinchart,
Jonas Karlman, Jernej Skrabec, Sandy Huang, Heiko Stübner,
Andy Yan, Jani Nikula, Rodrigo Vivi, Joonas Lahtinen,
Tvrtko Ursulin, Dmitry Baryshkov, Sascha Hauer, Rob Herring,
Jonathan Corbet, Shuah Khan, kernel, amd-gfx, dri-devel,
linux-kernel, linux-arm-kernel, linux-rockchip, intel-gfx,
intel-xe, linux-doc, Werner Sembach, Andri Yngvason, Marius Vlad
In-Reply-To: <acLrv5hLyNss-Px5@intel.com>
On Tuesday, 24 March 2026 20:53:35 Central European Standard Time Ville Syrjälä wrote:
> On Tue, Mar 24, 2026 at 08:10:11PM +0100, Nicolas Frattaroli wrote:
> > On Tuesday, 24 March 2026 18:00:45 Central European Standard Time Ville Syrjälä wrote:
> > > On Tue, Mar 24, 2026 at 05:01:07PM +0100, Nicolas Frattaroli wrote:
> > > > +enum drm_connector_color_format {
> > > > + /**
> > > > + * @DRM_CONNECTOR_COLOR_FORMAT_AUTO: The driver or display protocol
> > > > + * helpers should pick a suitable color format. All implementations of a
> > > > + * specific display protocol must behave the same way with "AUTO", but
> > > > + * different display protocols do not necessarily have the same "AUTO"
> > > > + * semantics.
> > > > + *
> > > > + * For HDMI, "AUTO" picks RGB, but falls back to YCbCr 4:2:0 if the
> > > > + * bandwidth required for full-scale RGB is not available, or the mode
> > > > + * is YCbCr 4:2:0-only, as long as the mode and output both support
> > > > + * YCbCr 4:2:0.
> > > > + *
> > > > + * For display protocols other than HDMI, the recursive bridge chain
> > > > + * format selection picks the first chain of bridge formats that works,
> > > > + * as has already been the case before the introduction of the "color
> > > > + * format" property. Non-HDMI bridges should therefore either sort their
> > > > + * bus output formats by preference, or agree on a unified auto format
> > > > + * selection logic that's implemented in a common state helper (like
> > > > + * how HDMI does it).
> > > > + */
> > > > + DRM_CONNECTOR_COLOR_FORMAT_AUTO = 0,
> > > > +
> > > > + /**
> > > > + * @DRM_CONNECTOR_COLOR_FORMAT_RGB444: RGB output format
> > > > + */
> > > > + DRM_CONNECTOR_COLOR_FORMAT_RGB444,
> > > > +
> > > > + /**
> > > > + * @DRM_CONNECTOR_COLOR_FORMAT_YCBCR444: YCbCr 4:4:4 output format (ie.
> > > > + * not subsampled)
> > > > + */
> > > > + DRM_CONNECTOR_COLOR_FORMAT_YCBCR444,
> > > > +
> > > > + /**
> > > > + * @DRM_CONNECTOR_COLOR_FORMAT_YCBCR422: YCbCr 4:2:2 output format (ie.
> > > > + * with horizontal subsampling)
> > > > + */
> > > > + DRM_CONNECTOR_COLOR_FORMAT_YCBCR422,
> > > > +
> > > > + /**
> > > > + * @DRM_CONNECTOR_COLOR_FORMAT_YCBCR420: YCbCr 4:2:0 output format (ie.
> > > > + * with horizontal and vertical subsampling)
> > > > + */
> > > > + DRM_CONNECTOR_COLOR_FORMAT_YCBCR420,
> > >
> > > Seems like this should document what the quantization range
> > > should be for each format.
> > >
> >
> > I don't think so? If you want per-component bit depth values,
> > DRM_FORMAT_* defines would be the appropriate values to use. This
> > enum is more abstract than that, and is there to communicate
> > YUV vs. RGB and chroma subsampling, with bit depth being handled
> > by other properties.
> >
> > If you mean the factor used for subsampling, then that'd only be
> > relevant if YCBCR410 was supported where one chroma plane isn't
> > halved but quartered in resolution. I suspect 4:1:0 will never
> > be added; no digital display protocol standard supports it to my
> > knowledge, and hopefully none ever will.
>
> No, I mean the quantization range (16-235 vs. 0-255 etc).
>
> The i915 behaviour is that YCbCr is always limited range,
> RGB can either be full or limited range depending on the
> "Broadcast RGB" property and other related factors.
>
>
I do agree that this would be useful to be precise about, but I'm
not sure mainline is currently capable of even making a definitive
statement about this because every implementation will do its own
thing probably.
If we do add YCbCr quantization range as a separate property (though
I'd really would've loved it if "Broadcast RGB" was named differently
so it wouldn't be confusing if we overloaded that property's meaning
to also apply to YCbCr) then the resulting docs change for these
enums would be to say that quantization range is a separate property.
I do think making it separate is the best path forward, and I'm willing
to adjust the docs to mention this, but I think implementing YCbCr limited
versus full range in this series as well would drastically widen the scope
again.
Kind regards,
Nicolas Frattaroli
^ permalink raw reply
* Re: [PATCH v11 03/22] drm: Add new general DRM property "color format"
From: Nicolas Frattaroli @ 2026-03-25 13:11 UTC (permalink / raw)
To: Dave Stevenson
Cc: Harry Wentland, Leo Li, Rodrigo Siqueira, Alex Deucher,
Christian König, David Airlie, Simona Vetter,
Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann,
Andrzej Hajda, Neil Armstrong, Robert Foss, Laurent Pinchart,
Jonas Karlman, Jernej Skrabec, Sandy Huang, Heiko Stübner,
Andy Yan, Jani Nikula, Rodrigo Vivi, Joonas Lahtinen,
Tvrtko Ursulin, Dmitry Baryshkov, Sascha Hauer, Rob Herring,
Jonathan Corbet, Shuah Khan, kernel, amd-gfx, dri-devel,
linux-kernel, linux-arm-kernel, linux-rockchip, intel-gfx,
intel-xe, linux-doc, Werner Sembach, Andri Yngvason, Marius Vlad
In-Reply-To: <CAPY8ntB9f_=f5kru=8w9BpTuqQR+93maGpT61EKU28Uay2vq8Q@mail.gmail.com>
On Wednesday, 25 March 2026 13:49:19 Central European Standard Time Dave Stevenson wrote:
> On Tue, 24 Mar 2026 at 16:02, Nicolas Frattaroli
> <nicolas.frattaroli@collabora.com> wrote:
> >
> > Add a new general DRM property named "color format" which can be used by
> > userspace to request the display driver to output a particular color
> > format.
> >
> > Possible options are:
> > - auto (setup by default, driver internally picks the color format)
> > - rgb
> > - ycbcr444
> > - ycbcr422
> > - ycbcr420
> >
> > Drivers should advertise from this list which formats they support.
> > Together with this list and EDID data from the sink we should be able
> > to relay a list of usable color formats to users to pick from.
> >
> > Co-developed-by: Werner Sembach <wse@tuxedocomputers.com>
> > Signed-off-by: Werner Sembach <wse@tuxedocomputers.com>
> > Co-developed-by: Andri Yngvason <andri@yngvason.is>
> > Signed-off-by: Andri Yngvason <andri@yngvason.is>
> > Signed-off-by: Marius Vlad <marius.vlad@collabora.com>
> > Reviewed-by: Maxime Ripard <mripard@kernel.org>
> > Signed-off-by: Nicolas Frattaroli <nicolas.frattaroli@collabora.com>
> > ---
> > drivers/gpu/drm/drm_atomic_helper.c | 5 ++
> > drivers/gpu/drm/drm_atomic_uapi.c | 11 ++++
> > drivers/gpu/drm/drm_connector.c | 108 ++++++++++++++++++++++++++++++++++++
> > include/drm/drm_connector.h | 104 ++++++++++++++++++++++++++++++++++
> > 4 files changed, 228 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/drm_atomic_helper.c b/drivers/gpu/drm/drm_atomic_helper.c
> > index 26953ed6b53e..b7753454b777 100644
> > --- a/drivers/gpu/drm/drm_atomic_helper.c
> > +++ b/drivers/gpu/drm/drm_atomic_helper.c
> > @@ -737,6 +737,11 @@ drm_atomic_helper_check_modeset(struct drm_device *dev,
> > if (old_connector_state->max_requested_bpc !=
> > new_connector_state->max_requested_bpc)
> > new_crtc_state->connectors_changed = true;
> > +
> > + if (old_connector_state->color_format !=
> > + new_connector_state->color_format)
> > + new_crtc_state->connectors_changed = true;
> > +
> > }
> >
> > if (funcs->atomic_check)
> > diff --git a/drivers/gpu/drm/drm_atomic_uapi.c b/drivers/gpu/drm/drm_atomic_uapi.c
> > index 5bd5bf6661df..dee510c85e59 100644
> > --- a/drivers/gpu/drm/drm_atomic_uapi.c
> > +++ b/drivers/gpu/drm/drm_atomic_uapi.c
> > @@ -935,6 +935,15 @@ static int drm_atomic_connector_set_property(struct drm_connector *connector,
> > state->privacy_screen_sw_state = val;
> > } else if (property == connector->broadcast_rgb_property) {
> > state->hdmi.broadcast_rgb = val;
> > + } else if (property == connector->color_format_property) {
> > + if (val > INT_MAX || !drm_connector_color_format_valid(val)) {
> > + drm_dbg_atomic(connector->dev,
> > + "[CONNECTOR:%d:%s] unknown color format %llu\n",
> > + connector->base.id, connector->name, val);
> > + return -EINVAL;
> > + }
> > +
> > + state->color_format = val;
> > } else if (connector->funcs->atomic_set_property) {
> > return connector->funcs->atomic_set_property(connector,
> > state, property, val);
> > @@ -1020,6 +1029,8 @@ drm_atomic_connector_get_property(struct drm_connector *connector,
> > *val = state->privacy_screen_sw_state;
> > } else if (property == connector->broadcast_rgb_property) {
> > *val = state->hdmi.broadcast_rgb;
> > + } else if (property == connector->color_format_property) {
> > + *val = state->color_format;
> > } else if (connector->funcs->atomic_get_property) {
> > return connector->funcs->atomic_get_property(connector,
> > state, property, val);
> > diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
> > index 47dc53c4a738..e848374dee0b 100644
> > --- a/drivers/gpu/drm/drm_connector.c
> > +++ b/drivers/gpu/drm/drm_connector.c
> > @@ -1388,6 +1388,18 @@ static const u32 hdmi_colorspaces =
> > BIT(DRM_MODE_COLORIMETRY_DCI_P3_RGB_D65) |
> > BIT(DRM_MODE_COLORIMETRY_DCI_P3_RGB_THEATER);
> >
> > +static const u32 hdmi_colorformats =
> > + BIT(DRM_OUTPUT_COLOR_FORMAT_RGB444) |
> > + BIT(DRM_OUTPUT_COLOR_FORMAT_YCBCR444) |
> > + BIT(DRM_OUTPUT_COLOR_FORMAT_YCBCR422) |
> > + BIT(DRM_OUTPUT_COLOR_FORMAT_YCBCR420);
> > +
> > +static const u32 dp_colorformats =
> > + BIT(DRM_OUTPUT_COLOR_FORMAT_RGB444) |
> > + BIT(DRM_OUTPUT_COLOR_FORMAT_YCBCR444) |
> > + BIT(DRM_OUTPUT_COLOR_FORMAT_YCBCR422) |
> > + BIT(DRM_OUTPUT_COLOR_FORMAT_YCBCR420);
> > +
> > /*
> > * As per DP 1.4a spec, 2.2.5.7.5 VSC SDP Payload for Pixel Encoding/Colorimetry
> > * Format Table 2-120
> > @@ -2940,6 +2952,102 @@ int drm_connector_attach_colorspace_property(struct drm_connector *connector)
> > }
> > EXPORT_SYMBOL(drm_connector_attach_colorspace_property);
> >
> > +/**
> > + * drm_connector_attach_color_format_property - create and attach color format property
> > + * @connector: connector to create the color format property on
> > + * @supported_color_formats: bitmask of bit-shifted &enum drm_output_color_format
> > + * values the connector supports
> > + *
> > + * Called by a driver to create a color format property. The property is
> > + * attached to the connector automatically on success.
> > + *
> > + * @supported_color_formats should only include color formats the connector
> > + * type can actually support.
> > + *
> > + * Returns:
> > + * 0 on success, negative errno on error
> > + */
> > +int drm_connector_attach_color_format_property(struct drm_connector *connector,
> > + unsigned long supported_color_formats)
> > +{
> > + struct drm_device *dev = connector->dev;
> > + struct drm_prop_enum_list enum_list[DRM_CONNECTOR_COLOR_FORMAT_COUNT];
> > + unsigned int i = 0;
> > + unsigned long fmt;
> > +
> > + if (connector->color_format_property)
> > + return 0;
> > +
> > + if (!supported_color_formats) {
> > + drm_err(dev, "No supported color formats provided on [CONNECTOR:%d:%s]\n",
> > + connector->base.id, connector->name);
> > + return -EINVAL;
> > + }
> > +
> > + if (supported_color_formats & ~GENMASK(DRM_OUTPUT_COLOR_FORMAT_COUNT - 1, 0)) {
> > + drm_err(dev, "Unknown color formats provided on [CONNECTOR:%d:%s]\n",
> > + connector->base.id, connector->name);
> > + return -EINVAL;
> > + }
> > +
> > + switch (connector->connector_type) {
> > + case DRM_MODE_CONNECTOR_HDMIA:
> > + case DRM_MODE_CONNECTOR_HDMIB:
> > + if (supported_color_formats & ~hdmi_colorformats) {
> > + drm_err(dev, "Color formats not allowed for HDMI on [CONNECTOR:%d:%s]\n",
> > + connector->base.id, connector->name);
> > + return -EINVAL;
> > + }
> > + break;
> > + case DRM_MODE_CONNECTOR_DisplayPort:
> > + case DRM_MODE_CONNECTOR_eDP:
> > + if (supported_color_formats & ~dp_colorformats) {
> > + drm_err(dev, "Color formats not allowed for DP on [CONNECTOR:%d:%s]\n",
> > + connector->base.id, connector->name);
> > + return -EINVAL;
> > + }
> > + break;
> > + }
> > +
> > + enum_list[0].name = "AUTO";
> > + enum_list[0].type = DRM_CONNECTOR_COLOR_FORMAT_AUTO;
> > +
> > + for_each_set_bit(fmt, &supported_color_formats, DRM_OUTPUT_COLOR_FORMAT_COUNT) {
> > + switch (fmt) {
> > + case DRM_OUTPUT_COLOR_FORMAT_RGB444:
> > + enum_list[++i].type = DRM_CONNECTOR_COLOR_FORMAT_RGB444;
> > + break;
> > + case DRM_OUTPUT_COLOR_FORMAT_YCBCR444:
> > + enum_list[++i].type = DRM_CONNECTOR_COLOR_FORMAT_YCBCR444;
> > + break;
> > + case DRM_OUTPUT_COLOR_FORMAT_YCBCR422:
> > + enum_list[++i].type = DRM_CONNECTOR_COLOR_FORMAT_YCBCR422;
> > + break;
> > + case DRM_OUTPUT_COLOR_FORMAT_YCBCR420:
> > + enum_list[++i].type = DRM_CONNECTOR_COLOR_FORMAT_YCBCR420;
> > + break;
> > + default:
> > + drm_warn(dev, "Unknown supported format %ld on [CONNECTOR:%d:%s]\n",
> > + fmt, connector->base.id, connector->name);
> > + continue;
> > + }
> > + enum_list[i].name = drm_hdmi_connector_get_output_format_name(fmt);
> > + }
> > +
> > + connector->color_format_property =
> > + drm_property_create_enum(dev, DRM_MODE_PROP_ENUM, "color format",
> > + enum_list, i + 1);
> > +
> > + if (!connector->color_format_property)
> > + return -ENOMEM;
> > +
> > + drm_object_attach_property(&connector->base, connector->color_format_property,
> > + DRM_CONNECTOR_COLOR_FORMAT_AUTO);
> > +
> > + return 0;
> > +}
> > +EXPORT_SYMBOL(drm_connector_attach_color_format_property);
> > +
> > /**
> > * drm_connector_atomic_hdr_metadata_equal - checks if the hdr metadata changed
> > * @old_state: old connector state to compare
> > diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
> > index af8b92d2d5b7..bd549f912b76 100644
> > --- a/include/drm/drm_connector.h
> > +++ b/include/drm/drm_connector.h
> > @@ -571,14 +571,102 @@ enum drm_colorspace {
> > * YCbCr 4:2:2 output format (ie. with horizontal subsampling)
> > * @DRM_OUTPUT_COLOR_FORMAT_YCBCR420:
> > * YCbCr 4:2:0 output format (ie. with horizontal and vertical subsampling)
> > + * @DRM_OUTPUT_COLOR_FORMAT_COUNT:
> > + * Number of valid output color format values in this enum
> > */
> > enum drm_output_color_format {
> > DRM_OUTPUT_COLOR_FORMAT_RGB444 = 0,
> > DRM_OUTPUT_COLOR_FORMAT_YCBCR444,
> > DRM_OUTPUT_COLOR_FORMAT_YCBCR422,
> > DRM_OUTPUT_COLOR_FORMAT_YCBCR420,
> > + DRM_OUTPUT_COLOR_FORMAT_COUNT,
> > };
> >
> > +/**
> > + * enum drm_connector_color_format - Connector Color Format Request
> > + *
> > + * This enum, unlike &enum drm_output_color_format, is used to specify requests
> > + * for a specific color format on a connector through the DRM "color format"
> > + * property. The difference is that it has an "AUTO" value to specify that
> > + * no specific choice has been made.
> > + */
> > +enum drm_connector_color_format {
> > + /**
> > + * @DRM_CONNECTOR_COLOR_FORMAT_AUTO: The driver or display protocol
> > + * helpers should pick a suitable color format. All implementations of a
> > + * specific display protocol must behave the same way with "AUTO", but
> > + * different display protocols do not necessarily have the same "AUTO"
> > + * semantics.
> > + *
> > + * For HDMI, "AUTO" picks RGB, but falls back to YCbCr 4:2:0 if the
> > + * bandwidth required for full-scale RGB is not available, or the mode
> > + * is YCbCr 4:2:0-only, as long as the mode and output both support
> > + * YCbCr 4:2:0.
>
> Is there a reason you propose dropping back to YCbCr 4:2:0 without
> trying YCbCr 4:2:2 first? Minimising the subsampling is surely
> beneficial, and vc4 for one can do 4:2:2 but not 4:2:0.
I worked under the assumption that 4:2:0 was more common than 4:2:2 based
on the existing HDMI state helper code that also doesn't try 4:2:2 first.
But this is a good point, it should try 4:2:2 as well (at least on
implementations where it's supported, e.g. i915 does not support 4:2:2 at
all from what I see.)
Kind regards,
Nicolas Frattaroli
>
> Dave
>
> > + *
> > + * For display protocols other than HDMI, the recursive bridge chain
> > + * format selection picks the first chain of bridge formats that works,
> > + * as has already been the case before the introduction of the "color
> > + * format" property. Non-HDMI bridges should therefore either sort their
> > + * bus output formats by preference, or agree on a unified auto format
> > + * selection logic that's implemented in a common state helper (like
> > + * how HDMI does it).
> > + */
> > + DRM_CONNECTOR_COLOR_FORMAT_AUTO = 0,
> > +
> > + /**
> > + * @DRM_CONNECTOR_COLOR_FORMAT_RGB444: RGB output format
> > + */
> > + DRM_CONNECTOR_COLOR_FORMAT_RGB444,
> > +
> > + /**
> > + * @DRM_CONNECTOR_COLOR_FORMAT_YCBCR444: YCbCr 4:4:4 output format (ie.
> > + * not subsampled)
> > + */
> > + DRM_CONNECTOR_COLOR_FORMAT_YCBCR444,
> > +
> > + /**
> > + * @DRM_CONNECTOR_COLOR_FORMAT_YCBCR422: YCbCr 4:2:2 output format (ie.
> > + * with horizontal subsampling)
> > + */
> > + DRM_CONNECTOR_COLOR_FORMAT_YCBCR422,
> > +
> > + /**
> > + * @DRM_CONNECTOR_COLOR_FORMAT_YCBCR420: YCbCr 4:2:0 output format (ie.
> > + * with horizontal and vertical subsampling)
> > + */
> > + DRM_CONNECTOR_COLOR_FORMAT_YCBCR420,
> > +
> > + /**
> > + * @DRM_CONNECTOR_COLOR_FORMAT_COUNT: Number of valid connector color
> > + * format values in this enum
> > + */
> > + DRM_CONNECTOR_COLOR_FORMAT_COUNT,
> > +};
> > +
> > +/**
> > + * drm_connector_color_format_valid - Validate drm_connector_color_format value
> > + * @fmt: value to check against all values of &enum drm_connector_color_format
> > + *
> > + * Checks whether the passed in value of @fmt is one of the allowable values in
> > + * &enum drm_connector_color_format.
> > + *
> > + * Returns: %true if it's a valid value for the enum, %false otherwise.
> > + */
> > +static inline bool __pure
> > +drm_connector_color_format_valid(enum drm_connector_color_format fmt)
> > +{
> > + switch (fmt) {
> > + case DRM_CONNECTOR_COLOR_FORMAT_AUTO:
> > + case DRM_CONNECTOR_COLOR_FORMAT_RGB444:
> > + case DRM_CONNECTOR_COLOR_FORMAT_YCBCR444:
> > + case DRM_CONNECTOR_COLOR_FORMAT_YCBCR422:
> > + case DRM_CONNECTOR_COLOR_FORMAT_YCBCR420:
> > + return true;
> > + default:
> > + return false;
> > + }
> > +}
> > +
> > const char *
> > drm_hdmi_connector_get_output_format_name(enum drm_output_color_format fmt);
> >
> > @@ -1129,6 +1217,13 @@ struct drm_connector_state {
> > */
> > enum drm_colorspace colorspace;
> >
> > + /**
> > + * @color_format: State variable for Connector property to request
> > + * color format change on Sink. This is most commonly used to switch
> > + * between RGB to YUV and vice-versa.
> > + */
> > + enum drm_connector_color_format color_format;
> > +
> > /**
> > * @writeback_job: Writeback job for writeback connectors
> > *
> > @@ -2127,6 +2222,12 @@ struct drm_connector {
> > */
> > struct drm_property *colorspace_property;
> >
> > + /**
> > + * @color_format_property: Connector property to set the suitable
> > + * color format supported by the sink.
> > + */
> > + struct drm_property *color_format_property;
> > +
> > /**
> > * @path_blob_ptr:
> > *
> > @@ -2610,6 +2711,9 @@ bool drm_connector_has_possible_encoder(struct drm_connector *connector,
> > struct drm_encoder *encoder);
> > const char *drm_get_colorspace_name(enum drm_colorspace colorspace);
> >
> > +int drm_connector_attach_color_format_property(struct drm_connector *connector,
> > + unsigned long supported_color_formats);
> > +
> > /**
> > * drm_for_each_connector_iter - connector_list iterator macro
> > * @connector: &struct drm_connector pointer used as cursor
> >
> > --
> > 2.53.0
> >
>
^ permalink raw reply
* Re: [PATCH] doc: Add CPU Isolation documentation
From: Sebastian Andrzej Siewior @ 2026-03-25 13:21 UTC (permalink / raw)
To: Frederic Weisbecker
Cc: LKML, Anna-Maria Behnsen, Gabriele Monaco, Ingo Molnar,
Jonathan Corbet, Marcelo Tosatti, Marco Crivellari, Michal Hocko,
Paul E . McKenney, Peter Zijlstra, Phil Auld, Steven Rostedt,
Thomas Gleixner, Valentin Schneider, Vlastimil Babka, Waiman Long,
linux-doc, John Ogness
In-Reply-To: <acPZBRThz7g_6EXe@localhost.localdomain>
On 2026-03-25 13:45:57 [+0100], Frederic Weisbecker wrote:
> > > +Interface
> > > +~~~~~~~~~
> > > +
> > > +- :ref:`Documentation/admin-guide/cgroup-v2.rst <Cpuset v2 "isolated"
> > > + partitions>`
> >
> > I've been told by Jonathan once to just use the .rst file without
> > anything around it and the HTML render will make the link on its own.
> >
> > …
>
> Hmm, how would that look like? Just this?
>
> +- Documentation/admin-guide/cgroup-v2.rst
Yes. If you look at
Documentation/core-api/real-time/differences.rst
and look for "Sequence locks". If you compare this vs the render version
https://docs.kernel.org/core-api/real-time/differences.html#sequence-locks
then you see it got resolved as html link including description.
> > > +Checklist
> > > +=========
…
>
> We should probably have this to a seperate file that both isolation and rt could
> link to?
yeah. Either you look for a spot and start or keep it as-is and I rip it
out and a reference to a common document once we have on.
> Thanks.
Sebastian
^ permalink raw reply
* Re: [PATCH v11 03/22] drm: Add new general DRM property "color format"
From: Nicolas Frattaroli @ 2026-03-25 13:21 UTC (permalink / raw)
To: Dave Stevenson, Maxime Ripard
Cc: Harry Wentland, Leo Li, Rodrigo Siqueira, Alex Deucher,
Christian König, David Airlie, Simona Vetter,
Maarten Lankhorst, Thomas Zimmermann, Andrzej Hajda,
Neil Armstrong, Robert Foss, Laurent Pinchart, Jonas Karlman,
Jernej Skrabec, Sandy Huang, Heiko Stübner, Andy Yan,
Jani Nikula, Rodrigo Vivi, Joonas Lahtinen, Tvrtko Ursulin,
Dmitry Baryshkov, Sascha Hauer, Rob Herring, Jonathan Corbet,
Shuah Khan, kernel, amd-gfx, dri-devel, linux-kernel,
linux-arm-kernel, linux-rockchip, intel-gfx, intel-xe, linux-doc,
Werner Sembach, Andri Yngvason, Marius Vlad
In-Reply-To: <20260325-quaint-bull-of-fortitude-dc68da@houat>
On Wednesday, 25 March 2026 14:05:25 Central European Standard Time Maxime Ripard wrote:
> Hi Dave,
>
> On Wed, Mar 25, 2026 at 12:49:19PM +0000, Dave Stevenson wrote:
> > > diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
> > > index af8b92d2d5b7..bd549f912b76 100644
> > > --- a/include/drm/drm_connector.h
> > > +++ b/include/drm/drm_connector.h
> > > @@ -571,14 +571,102 @@ enum drm_colorspace {
> > > * YCbCr 4:2:2 output format (ie. with horizontal subsampling)
> > > * @DRM_OUTPUT_COLOR_FORMAT_YCBCR420:
> > > * YCbCr 4:2:0 output format (ie. with horizontal and vertical subsampling)
> > > + * @DRM_OUTPUT_COLOR_FORMAT_COUNT:
> > > + * Number of valid output color format values in this enum
> > > */
> > > enum drm_output_color_format {
> > > DRM_OUTPUT_COLOR_FORMAT_RGB444 = 0,
> > > DRM_OUTPUT_COLOR_FORMAT_YCBCR444,
> > > DRM_OUTPUT_COLOR_FORMAT_YCBCR422,
> > > DRM_OUTPUT_COLOR_FORMAT_YCBCR420,
> > > + DRM_OUTPUT_COLOR_FORMAT_COUNT,
> > > };
> > >
> > > +/**
> > > + * enum drm_connector_color_format - Connector Color Format Request
> > > + *
> > > + * This enum, unlike &enum drm_output_color_format, is used to specify requests
> > > + * for a specific color format on a connector through the DRM "color format"
> > > + * property. The difference is that it has an "AUTO" value to specify that
> > > + * no specific choice has been made.
> > > + */
> > > +enum drm_connector_color_format {
> > > + /**
> > > + * @DRM_CONNECTOR_COLOR_FORMAT_AUTO: The driver or display protocol
> > > + * helpers should pick a suitable color format. All implementations of a
> > > + * specific display protocol must behave the same way with "AUTO", but
> > > + * different display protocols do not necessarily have the same "AUTO"
> > > + * semantics.
> > > + *
> > > + * For HDMI, "AUTO" picks RGB, but falls back to YCbCr 4:2:0 if the
> > > + * bandwidth required for full-scale RGB is not available, or the mode
> > > + * is YCbCr 4:2:0-only, as long as the mode and output both support
> > > + * YCbCr 4:2:0.
> >
> > Is there a reason you propose dropping back to YCbCr 4:2:0 without
> > trying YCbCr 4:2:2 first? Minimising the subsampling is surely
> > beneficial, and vc4 for one can do 4:2:2 but not 4:2:0.
>
> The "auto" behaviour is strictly identical to the one we have right now,
> and this one stems from i915. Back when all that logic was added, it was
> decided to align every driver behavior on i915 because that's what most
> compositors would expect.
Hi Maxime,
would it be okay to extend the behavior while we're at it? 4:2:2 does save
bandwidth compared to RGB (unlike YCbCr 4:4:4). I do think 4:2:2 instead of
4:2:0 will provide benefits in some cases. I assume hardware that supports
4:2:2 only instead of 4:2:0 does so in order to save >= 1 horizontal
row of local SRAM buffer in the display controller for any downscaling,
as it'll only need to consider neighbouring pixels on the same row.
Kind regards,
Nicolas Frattaroli
>
> Maxime
>
^ permalink raw reply
* Re: [PATCH v4 0/4] workflow, scripts: sort changes.rst and ver_linux
From: Manuel Ebner @ 2026-03-25 13:30 UTC (permalink / raw)
To: Jonathan Corbet, Collin Funk, Shuah Khan
Cc: workflows, linux-doc, linux-kernel
In-Reply-To: <87zf46biix.fsf@trenco.lwn.net>
On Tue, 2026-03-17 at 09:08 -0600, Jonathan Corbet wrote:
> Manuel Ebner <manuelebner@airmail.cc> writes:
>
> > ...
> Also, overall, I am still not thrilled about you having send me patches
> under a false name. I need you to, at a bare minimum, acknowledge that
> this was a violation of the trust that the kernel project depends on,
> and that the current name you are using is the real one.
>
> Thanks,
>
> jon
Hello Jon,
unfortunately I have an issue with my e-mail provider. Because of an spamhouse.org
entry my mails do not show up in the mailing lists.
Do you mind me changing my e-mail address to manuelebner@mailbox.org
Manuel
^ permalink raw reply
* Re: [PATCH v4 0/4] workflow, scripts: sort changes.rst and ver_linux
From: Jonathan Corbet @ 2026-03-25 13:40 UTC (permalink / raw)
To: Manuel Ebner, Collin Funk, Shuah Khan; +Cc: workflows, linux-doc, linux-kernel
In-Reply-To: <ce9e75d81c6bd67cb2ff92bfd63f9dea0e7980e8.camel@airmail.cc>
Manuel Ebner <manuelebner@airmail.cc> writes:
> On Tue, 2026-03-17 at 09:08 -0600, Jonathan Corbet wrote:
>> Manuel Ebner <manuelebner@airmail.cc> writes:
>>
>> > ...
>> Also, overall, I am still not thrilled about you having send me patches
>> under a false name. I need you to, at a bare minimum, acknowledge that
>> this was a violation of the trust that the kernel project depends on,
>> and that the current name you are using is the real one.
>>
>> Thanks,
>>
>> jon
>
> Hello Jon,
> unfortunately I have an issue with my e-mail provider. Because of an spamhouse.org
> entry my mails do not show up in the mailing lists.
> Do you mind me changing my e-mail address to manuelebner@mailbox.org
Use whichever address works for you, that is not a problem.
jon
^ permalink raw reply
* Re: [PATCH v11 03/22] drm: Add new general DRM property "color format"
From: Ville Syrjälä @ 2026-03-25 13:43 UTC (permalink / raw)
To: Dave Stevenson
Cc: Nicolas Frattaroli, Harry Wentland, Leo Li, Rodrigo Siqueira,
Alex Deucher, Christian König, David Airlie, Simona Vetter,
Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann,
Andrzej Hajda, Neil Armstrong, Robert Foss, Laurent Pinchart,
Jonas Karlman, Jernej Skrabec, Sandy Huang, Heiko Stübner,
Andy Yan, Jani Nikula, Rodrigo Vivi, Joonas Lahtinen,
Tvrtko Ursulin, Dmitry Baryshkov, Sascha Hauer, Rob Herring,
Jonathan Corbet, Shuah Khan, kernel, amd-gfx, dri-devel,
linux-kernel, linux-arm-kernel, linux-rockchip, intel-gfx,
intel-xe, linux-doc, Werner Sembach, Andri Yngvason, Marius Vlad
In-Reply-To: <CAPY8ntB9f_=f5kru=8w9BpTuqQR+93maGpT61EKU28Uay2vq8Q@mail.gmail.com>
On Wed, Mar 25, 2026 at 12:49:19PM +0000, Dave Stevenson wrote:
> On Tue, 24 Mar 2026 at 16:02, Nicolas Frattaroli
> <nicolas.frattaroli@collabora.com> wrote:
> >
> > Add a new general DRM property named "color format" which can be used by
> > userspace to request the display driver to output a particular color
> > format.
> >
> > Possible options are:
> > - auto (setup by default, driver internally picks the color format)
> > - rgb
> > - ycbcr444
> > - ycbcr422
> > - ycbcr420
> >
> > Drivers should advertise from this list which formats they support.
> > Together with this list and EDID data from the sink we should be able
> > to relay a list of usable color formats to users to pick from.
> >
> > Co-developed-by: Werner Sembach <wse@tuxedocomputers.com>
> > Signed-off-by: Werner Sembach <wse@tuxedocomputers.com>
> > Co-developed-by: Andri Yngvason <andri@yngvason.is>
> > Signed-off-by: Andri Yngvason <andri@yngvason.is>
> > Signed-off-by: Marius Vlad <marius.vlad@collabora.com>
> > Reviewed-by: Maxime Ripard <mripard@kernel.org>
> > Signed-off-by: Nicolas Frattaroli <nicolas.frattaroli@collabora.com>
> > ---
> > drivers/gpu/drm/drm_atomic_helper.c | 5 ++
> > drivers/gpu/drm/drm_atomic_uapi.c | 11 ++++
> > drivers/gpu/drm/drm_connector.c | 108 ++++++++++++++++++++++++++++++++++++
> > include/drm/drm_connector.h | 104 ++++++++++++++++++++++++++++++++++
> > 4 files changed, 228 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/drm_atomic_helper.c b/drivers/gpu/drm/drm_atomic_helper.c
> > index 26953ed6b53e..b7753454b777 100644
> > --- a/drivers/gpu/drm/drm_atomic_helper.c
> > +++ b/drivers/gpu/drm/drm_atomic_helper.c
> > @@ -737,6 +737,11 @@ drm_atomic_helper_check_modeset(struct drm_device *dev,
> > if (old_connector_state->max_requested_bpc !=
> > new_connector_state->max_requested_bpc)
> > new_crtc_state->connectors_changed = true;
> > +
> > + if (old_connector_state->color_format !=
> > + new_connector_state->color_format)
> > + new_crtc_state->connectors_changed = true;
> > +
> > }
> >
> > if (funcs->atomic_check)
> > diff --git a/drivers/gpu/drm/drm_atomic_uapi.c b/drivers/gpu/drm/drm_atomic_uapi.c
> > index 5bd5bf6661df..dee510c85e59 100644
> > --- a/drivers/gpu/drm/drm_atomic_uapi.c
> > +++ b/drivers/gpu/drm/drm_atomic_uapi.c
> > @@ -935,6 +935,15 @@ static int drm_atomic_connector_set_property(struct drm_connector *connector,
> > state->privacy_screen_sw_state = val;
> > } else if (property == connector->broadcast_rgb_property) {
> > state->hdmi.broadcast_rgb = val;
> > + } else if (property == connector->color_format_property) {
> > + if (val > INT_MAX || !drm_connector_color_format_valid(val)) {
> > + drm_dbg_atomic(connector->dev,
> > + "[CONNECTOR:%d:%s] unknown color format %llu\n",
> > + connector->base.id, connector->name, val);
> > + return -EINVAL;
> > + }
> > +
> > + state->color_format = val;
> > } else if (connector->funcs->atomic_set_property) {
> > return connector->funcs->atomic_set_property(connector,
> > state, property, val);
> > @@ -1020,6 +1029,8 @@ drm_atomic_connector_get_property(struct drm_connector *connector,
> > *val = state->privacy_screen_sw_state;
> > } else if (property == connector->broadcast_rgb_property) {
> > *val = state->hdmi.broadcast_rgb;
> > + } else if (property == connector->color_format_property) {
> > + *val = state->color_format;
> > } else if (connector->funcs->atomic_get_property) {
> > return connector->funcs->atomic_get_property(connector,
> > state, property, val);
> > diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
> > index 47dc53c4a738..e848374dee0b 100644
> > --- a/drivers/gpu/drm/drm_connector.c
> > +++ b/drivers/gpu/drm/drm_connector.c
> > @@ -1388,6 +1388,18 @@ static const u32 hdmi_colorspaces =
> > BIT(DRM_MODE_COLORIMETRY_DCI_P3_RGB_D65) |
> > BIT(DRM_MODE_COLORIMETRY_DCI_P3_RGB_THEATER);
> >
> > +static const u32 hdmi_colorformats =
> > + BIT(DRM_OUTPUT_COLOR_FORMAT_RGB444) |
> > + BIT(DRM_OUTPUT_COLOR_FORMAT_YCBCR444) |
> > + BIT(DRM_OUTPUT_COLOR_FORMAT_YCBCR422) |
> > + BIT(DRM_OUTPUT_COLOR_FORMAT_YCBCR420);
> > +
> > +static const u32 dp_colorformats =
> > + BIT(DRM_OUTPUT_COLOR_FORMAT_RGB444) |
> > + BIT(DRM_OUTPUT_COLOR_FORMAT_YCBCR444) |
> > + BIT(DRM_OUTPUT_COLOR_FORMAT_YCBCR422) |
> > + BIT(DRM_OUTPUT_COLOR_FORMAT_YCBCR420);
> > +
> > /*
> > * As per DP 1.4a spec, 2.2.5.7.5 VSC SDP Payload for Pixel Encoding/Colorimetry
> > * Format Table 2-120
> > @@ -2940,6 +2952,102 @@ int drm_connector_attach_colorspace_property(struct drm_connector *connector)
> > }
> > EXPORT_SYMBOL(drm_connector_attach_colorspace_property);
> >
> > +/**
> > + * drm_connector_attach_color_format_property - create and attach color format property
> > + * @connector: connector to create the color format property on
> > + * @supported_color_formats: bitmask of bit-shifted &enum drm_output_color_format
> > + * values the connector supports
> > + *
> > + * Called by a driver to create a color format property. The property is
> > + * attached to the connector automatically on success.
> > + *
> > + * @supported_color_formats should only include color formats the connector
> > + * type can actually support.
> > + *
> > + * Returns:
> > + * 0 on success, negative errno on error
> > + */
> > +int drm_connector_attach_color_format_property(struct drm_connector *connector,
> > + unsigned long supported_color_formats)
> > +{
> > + struct drm_device *dev = connector->dev;
> > + struct drm_prop_enum_list enum_list[DRM_CONNECTOR_COLOR_FORMAT_COUNT];
> > + unsigned int i = 0;
> > + unsigned long fmt;
> > +
> > + if (connector->color_format_property)
> > + return 0;
> > +
> > + if (!supported_color_formats) {
> > + drm_err(dev, "No supported color formats provided on [CONNECTOR:%d:%s]\n",
> > + connector->base.id, connector->name);
> > + return -EINVAL;
> > + }
> > +
> > + if (supported_color_formats & ~GENMASK(DRM_OUTPUT_COLOR_FORMAT_COUNT - 1, 0)) {
> > + drm_err(dev, "Unknown color formats provided on [CONNECTOR:%d:%s]\n",
> > + connector->base.id, connector->name);
> > + return -EINVAL;
> > + }
> > +
> > + switch (connector->connector_type) {
> > + case DRM_MODE_CONNECTOR_HDMIA:
> > + case DRM_MODE_CONNECTOR_HDMIB:
> > + if (supported_color_formats & ~hdmi_colorformats) {
> > + drm_err(dev, "Color formats not allowed for HDMI on [CONNECTOR:%d:%s]\n",
> > + connector->base.id, connector->name);
> > + return -EINVAL;
> > + }
> > + break;
> > + case DRM_MODE_CONNECTOR_DisplayPort:
> > + case DRM_MODE_CONNECTOR_eDP:
> > + if (supported_color_formats & ~dp_colorformats) {
> > + drm_err(dev, "Color formats not allowed for DP on [CONNECTOR:%d:%s]\n",
> > + connector->base.id, connector->name);
> > + return -EINVAL;
> > + }
> > + break;
> > + }
> > +
> > + enum_list[0].name = "AUTO";
> > + enum_list[0].type = DRM_CONNECTOR_COLOR_FORMAT_AUTO;
> > +
> > + for_each_set_bit(fmt, &supported_color_formats, DRM_OUTPUT_COLOR_FORMAT_COUNT) {
> > + switch (fmt) {
> > + case DRM_OUTPUT_COLOR_FORMAT_RGB444:
> > + enum_list[++i].type = DRM_CONNECTOR_COLOR_FORMAT_RGB444;
> > + break;
> > + case DRM_OUTPUT_COLOR_FORMAT_YCBCR444:
> > + enum_list[++i].type = DRM_CONNECTOR_COLOR_FORMAT_YCBCR444;
> > + break;
> > + case DRM_OUTPUT_COLOR_FORMAT_YCBCR422:
> > + enum_list[++i].type = DRM_CONNECTOR_COLOR_FORMAT_YCBCR422;
> > + break;
> > + case DRM_OUTPUT_COLOR_FORMAT_YCBCR420:
> > + enum_list[++i].type = DRM_CONNECTOR_COLOR_FORMAT_YCBCR420;
> > + break;
> > + default:
> > + drm_warn(dev, "Unknown supported format %ld on [CONNECTOR:%d:%s]\n",
> > + fmt, connector->base.id, connector->name);
> > + continue;
> > + }
> > + enum_list[i].name = drm_hdmi_connector_get_output_format_name(fmt);
> > + }
> > +
> > + connector->color_format_property =
> > + drm_property_create_enum(dev, DRM_MODE_PROP_ENUM, "color format",
> > + enum_list, i + 1);
> > +
> > + if (!connector->color_format_property)
> > + return -ENOMEM;
> > +
> > + drm_object_attach_property(&connector->base, connector->color_format_property,
> > + DRM_CONNECTOR_COLOR_FORMAT_AUTO);
> > +
> > + return 0;
> > +}
> > +EXPORT_SYMBOL(drm_connector_attach_color_format_property);
> > +
> > /**
> > * drm_connector_atomic_hdr_metadata_equal - checks if the hdr metadata changed
> > * @old_state: old connector state to compare
> > diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
> > index af8b92d2d5b7..bd549f912b76 100644
> > --- a/include/drm/drm_connector.h
> > +++ b/include/drm/drm_connector.h
> > @@ -571,14 +571,102 @@ enum drm_colorspace {
> > * YCbCr 4:2:2 output format (ie. with horizontal subsampling)
> > * @DRM_OUTPUT_COLOR_FORMAT_YCBCR420:
> > * YCbCr 4:2:0 output format (ie. with horizontal and vertical subsampling)
> > + * @DRM_OUTPUT_COLOR_FORMAT_COUNT:
> > + * Number of valid output color format values in this enum
> > */
> > enum drm_output_color_format {
> > DRM_OUTPUT_COLOR_FORMAT_RGB444 = 0,
> > DRM_OUTPUT_COLOR_FORMAT_YCBCR444,
> > DRM_OUTPUT_COLOR_FORMAT_YCBCR422,
> > DRM_OUTPUT_COLOR_FORMAT_YCBCR420,
> > + DRM_OUTPUT_COLOR_FORMAT_COUNT,
> > };
> >
> > +/**
> > + * enum drm_connector_color_format - Connector Color Format Request
> > + *
> > + * This enum, unlike &enum drm_output_color_format, is used to specify requests
> > + * for a specific color format on a connector through the DRM "color format"
> > + * property. The difference is that it has an "AUTO" value to specify that
> > + * no specific choice has been made.
> > + */
> > +enum drm_connector_color_format {
> > + /**
> > + * @DRM_CONNECTOR_COLOR_FORMAT_AUTO: The driver or display protocol
> > + * helpers should pick a suitable color format. All implementations of a
> > + * specific display protocol must behave the same way with "AUTO", but
> > + * different display protocols do not necessarily have the same "AUTO"
> > + * semantics.
> > + *
> > + * For HDMI, "AUTO" picks RGB, but falls back to YCbCr 4:2:0 if the
> > + * bandwidth required for full-scale RGB is not available, or the mode
> > + * is YCbCr 4:2:0-only, as long as the mode and output both support
> > + * YCbCr 4:2:0.
>
> Is there a reason you propose dropping back to YCbCr 4:2:0 without
> trying YCbCr 4:2:2 first? Minimising the subsampling is surely
> beneficial, and vc4 for one can do 4:2:2 but not 4:2:0.
On HDMI 4:2:2 is always 12bpc, so it doesn't save any bandwidth
compared to 8bpc 4:4:4.
--
Ville Syrjälä
Intel
^ permalink raw reply
* Re: [PATCH v4 17/21] mm: allow handling of stacked mmap_prepare hooks in more drivers
From: Vlastimil Babka (SUSE) @ 2026-03-25 13:43 UTC (permalink / raw)
To: Lorenzo Stoakes (Oracle), Andrew Morton
Cc: Jonathan Corbet, Clemens Ladisch, Arnd Bergmann,
Greg Kroah-Hartman, K . Y . Srinivasan, Haiyang Zhang, Wei Liu,
Dexuan Cui, Long Li, Alexander Shishkin, Maxime Coquelin,
Alexandre Torgue, Miquel Raynal, Richard Weinberger,
Vignesh Raghavendra, Bodo Stroesser, Martin K . Petersen,
David Howells, Marc Dionne, Alexander Viro, Christian Brauner,
Jan Kara, David Hildenbrand, Liam R . Howlett, Mike Rapoport,
Suren Baghdasaryan, Michal Hocko, Jann Horn, Pedro Falcato,
linux-kernel, linux-doc, linux-hyperv, linux-stm32,
linux-arm-kernel, linux-mtd, linux-staging, linux-scsi,
target-devel, linux-afs, linux-fsdevel, linux-mm, Ryan Roberts
In-Reply-To: <24aac3019dd34740e788d169fccbe3c62781e648.1774045440.git.ljs@kernel.org>
On 3/20/26 23:39, Lorenzo Stoakes (Oracle) wrote:
> While the conversion of mmap hooks to mmap_prepare is underway, we will
> encounter situations where mmap hooks need to invoke nested mmap_prepare
> hooks.
>
> The nesting of mmap hooks is termed 'stacking'. In order to flexibly
> facilitate the conversion of custom mmap hooks in drivers which stack, we
> must split up the existing __compat_vma_mmap() function into two separate
> functions:
>
> * compat_set_desc_from_vma() - This allows the setting of a vm_area_desc
> object's fields to the relevant fields of a VMA.
>
> * __compat_vma_mmap() - Once an mmap_prepare hook has been executed upon a
> vm_area_desc object, this function performs any mmap actions specified by
> the mmap_prepare hook and then invokes its vm_ops->mapped() hook if any
> were specified.
>
> In ordinary cases, where a file's f_op->mmap_prepare() hook simply needs
> to be invoked in a stacked mmap() hook, compat_vma_mmap() can be used.
>
> However some drivers define their own nested hooks, which are invoked in
> turn by another hook.
>
> A concrete example is vmbus_channel->mmap_ring_buffer(), which is invoked
> in turn by bin_attribute->mmap():
>
> vmbus_channel->mmap_ring_buffer() has a signature of:
>
> int (*mmap_ring_buffer)(struct vmbus_channel *channel,
> struct vm_area_struct *vma);
>
> And bin_attribute->mmap() has a signature of:
>
> int (*mmap)(struct file *, struct kobject *,
> const struct bin_attribute *attr,
> struct vm_area_struct *vma);
>
> And so compat_vma_mmap() cannot be used here for incremental conversion of
> hooks from mmap() to mmap_prepare().
>
> There are many such instances like this, where conversion to mmap_prepare
> would otherwise cascade to a huge change set due to nesting of this kind.
>
> The changes in this patch mean we could now instead convert
> vmbus_channel->mmap_ring_buffer() to
> vmbus_channel->mmap_prepare_ring_buffer(), and implement something like:
>
> struct vm_area_desc desc;
> int err;
>
> compat_set_desc_from_vma(&desc, file, vma);
> err = channel->mmap_prepare_ring_buffer(channel, &desc);
> if (err)
> return err;
>
> return __compat_vma_mmap(&desc, vma);
>
> Allowing us to incrementally update this logic, and other logic like it.
>
> Unfortunately, as part of this change, we need to be able to flexibly
> assign to the VMA descriptor, so have to remove some of the const
> declarations within the structure.
>
> Also update the VMA tests to reflect the changes.
>
> Signed-off-by: Lorenzo Stoakes (Oracle) <ljs@kernel.org>
Acked-by: Vlastimil Babka (SUSE) <vbabka@kernel.org>
^ permalink raw reply
* Re: [PATCH v11 03/22] drm: Add new general DRM property "color format"
From: Maxime Ripard @ 2026-03-25 13:44 UTC (permalink / raw)
To: Nicolas Frattaroli
Cc: Dave Stevenson, Harry Wentland, Leo Li, Rodrigo Siqueira,
Alex Deucher, Christian König, David Airlie, Simona Vetter,
Maarten Lankhorst, Thomas Zimmermann, Andrzej Hajda,
Neil Armstrong, Robert Foss, Laurent Pinchart, Jonas Karlman,
Jernej Skrabec, Sandy Huang, Heiko Stübner, Andy Yan,
Jani Nikula, Rodrigo Vivi, Joonas Lahtinen, Tvrtko Ursulin,
Dmitry Baryshkov, Sascha Hauer, Rob Herring, Jonathan Corbet,
Shuah Khan, kernel, amd-gfx, dri-devel, linux-kernel,
linux-arm-kernel, linux-rockchip, intel-gfx, intel-xe, linux-doc,
Werner Sembach, Andri Yngvason, Marius Vlad
In-Reply-To: <12425220.nUPlyArG6x@workhorse>
[-- Attachment #1: Type: text/plain, Size: 3249 bytes --]
On Wed, Mar 25, 2026 at 02:21:24PM +0100, Nicolas Frattaroli wrote:
> On Wednesday, 25 March 2026 14:05:25 Central European Standard Time Maxime Ripard wrote:
> > Hi Dave,
> >
> > On Wed, Mar 25, 2026 at 12:49:19PM +0000, Dave Stevenson wrote:
> > > > diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
> > > > index af8b92d2d5b7..bd549f912b76 100644
> > > > --- a/include/drm/drm_connector.h
> > > > +++ b/include/drm/drm_connector.h
> > > > @@ -571,14 +571,102 @@ enum drm_colorspace {
> > > > * YCbCr 4:2:2 output format (ie. with horizontal subsampling)
> > > > * @DRM_OUTPUT_COLOR_FORMAT_YCBCR420:
> > > > * YCbCr 4:2:0 output format (ie. with horizontal and vertical subsampling)
> > > > + * @DRM_OUTPUT_COLOR_FORMAT_COUNT:
> > > > + * Number of valid output color format values in this enum
> > > > */
> > > > enum drm_output_color_format {
> > > > DRM_OUTPUT_COLOR_FORMAT_RGB444 = 0,
> > > > DRM_OUTPUT_COLOR_FORMAT_YCBCR444,
> > > > DRM_OUTPUT_COLOR_FORMAT_YCBCR422,
> > > > DRM_OUTPUT_COLOR_FORMAT_YCBCR420,
> > > > + DRM_OUTPUT_COLOR_FORMAT_COUNT,
> > > > };
> > > >
> > > > +/**
> > > > + * enum drm_connector_color_format - Connector Color Format Request
> > > > + *
> > > > + * This enum, unlike &enum drm_output_color_format, is used to specify requests
> > > > + * for a specific color format on a connector through the DRM "color format"
> > > > + * property. The difference is that it has an "AUTO" value to specify that
> > > > + * no specific choice has been made.
> > > > + */
> > > > +enum drm_connector_color_format {
> > > > + /**
> > > > + * @DRM_CONNECTOR_COLOR_FORMAT_AUTO: The driver or display protocol
> > > > + * helpers should pick a suitable color format. All implementations of a
> > > > + * specific display protocol must behave the same way with "AUTO", but
> > > > + * different display protocols do not necessarily have the same "AUTO"
> > > > + * semantics.
> > > > + *
> > > > + * For HDMI, "AUTO" picks RGB, but falls back to YCbCr 4:2:0 if the
> > > > + * bandwidth required for full-scale RGB is not available, or the mode
> > > > + * is YCbCr 4:2:0-only, as long as the mode and output both support
> > > > + * YCbCr 4:2:0.
> > >
> > > Is there a reason you propose dropping back to YCbCr 4:2:0 without
> > > trying YCbCr 4:2:2 first? Minimising the subsampling is surely
> > > beneficial, and vc4 for one can do 4:2:2 but not 4:2:0.
> >
> > The "auto" behaviour is strictly identical to the one we have right now,
> > and this one stems from i915. Back when all that logic was added, it was
> > decided to align every driver behavior on i915 because that's what most
> > compositors would expect.
>
> would it be okay to extend the behavior while we're at it? 4:2:2 does save
> bandwidth compared to RGB (unlike YCbCr 4:4:4). I do think 4:2:2 instead of
> 4:2:0 will provide benefits in some cases.
I don't really know, we would need to ask some Wayland/Weston devs as
well, but it sure is something worth discussing.
I wouldn't do it in this series but as a follow-up though.
Maxime
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 273 bytes --]
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox