* [RFC PATCH 1/2] backlight: Rename duplicated devices to support dual-backlight setups
From: Pengyu Luo @ 2025-05-25 10:40 UTC (permalink / raw)
To: Lee Jones, Daniel Thompson, Jingoo Han, Helge Deller
Cc: dri-devel, linux-fbdev, linux-kernel, Pengyu Luo
When registering a backlight device, if a device with the same name
already exists, append "-secondary" to the new device's name. This is
useful for platforms with dual backlight drivers (e.g. some panels use
dual ktz8866), where both instances need to coexist.
For now, only one secondary instance is supported. If more instances
are needed, this logic can be extended with auto-increment or a more
flexible naming scheme.
Suggested-by: Daniel Thompson <danielt@kernel.org>
Signed-off-by: Pengyu Luo <mitltlatltl@gmail.com>
---
drivers/video/backlight/backlight.c | 20 ++++++++++++++++++--
1 file changed, 18 insertions(+), 2 deletions(-)
diff --git a/drivers/video/backlight/backlight.c b/drivers/video/backlight/backlight.c
index 9dc93c5e4..991702f5d 100644
--- a/drivers/video/backlight/backlight.c
+++ b/drivers/video/backlight/backlight.c
@@ -365,7 +365,8 @@ struct backlight_device *backlight_device_register(const char *name,
struct device *parent, void *devdata, const struct backlight_ops *ops,
const struct backlight_properties *props)
{
- struct backlight_device *new_bd;
+ struct backlight_device *new_bd, *prev_bd;
+ const char *new_name = NULL;
int rc;
pr_debug("backlight_device_register: name=%s\n", name);
@@ -377,10 +378,23 @@ struct backlight_device *backlight_device_register(const char *name,
mutex_init(&new_bd->update_lock);
mutex_init(&new_bd->ops_lock);
+ /*
+ * If there is an instance with the same name already, then rename it.
+ * We also can use an auto-increment field, but it seems that there is
+ * no triple or quad case.
+ */
+ prev_bd = backlight_device_get_by_name(name);
+ if (!IS_ERR_OR_NULL(prev_bd)) {
+ new_name = kasprintf(GFP_KERNEL, "%s-secondary", name);
+ if (!new_name)
+ return ERR_PTR(-ENOMEM);
+ put_device(&prev_bd->dev);
+ }
+
new_bd->dev.class = &backlight_class;
new_bd->dev.parent = parent;
new_bd->dev.release = bl_device_release;
- dev_set_name(&new_bd->dev, "%s", name);
+ dev_set_name(&new_bd->dev, "%s", new_name ? new_name : name);
dev_set_drvdata(&new_bd->dev, devdata);
/* Set default properties */
@@ -414,6 +428,8 @@ struct backlight_device *backlight_device_register(const char *name,
list_add(&new_bd->entry, &backlight_dev_list);
mutex_unlock(&backlight_dev_list_mutex);
+ kfree(new_name);
+
return new_bd;
}
EXPORT_SYMBOL(backlight_device_register);
--
2.49.0
^ permalink raw reply related
* Re: [PATCH v3 3/4] fbdev/deferred-io: Support contiguous kernel memory framebuffers
From: kernel test robot @ 2025-05-24 7:28 UTC (permalink / raw)
To: mhkelley58, simona, deller, haiyangz, kys, wei.liu, decui, akpm
Cc: oe-kbuild-all, weh, tzimmermann, hch, dri-devel, linux-fbdev,
linux-kernel, linux-hyperv, linux-mm
In-Reply-To: <20250523161522.409504-4-mhklinux@outlook.com>
Hi,
kernel test robot noticed the following build errors:
[auto build test ERROR on akpm-mm/mm-everything]
[also build test ERROR on linus/master v6.15-rc7 next-20250523]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]
url: https://github.com/intel-lab-lkp/linux/commits/mhkelley58-gmail-com/mm-Export-vmf_insert_mixed_mkwrite/20250524-001707
base: https://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm.git mm-everything
patch link: https://lore.kernel.org/r/20250523161522.409504-4-mhklinux%40outlook.com
patch subject: [PATCH v3 3/4] fbdev/deferred-io: Support contiguous kernel memory framebuffers
config: arm-randconfig-001-20250524 (https://download.01.org/0day-ci/archive/20250524/202505241553.VSXoFOvX-lkp@intel.com/config)
compiler: arm-linux-gnueabi-gcc (GCC) 7.5.0
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20250524/202505241553.VSXoFOvX-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/202505241553.VSXoFOvX-lkp@intel.com/
All errors (new ones prefixed by >>, old ones prefixed by <<):
>> ERROR: modpost: "vmf_insert_pfn" [drivers/video/fbdev/core/fb.ko] undefined!
>> ERROR: modpost: "vmf_insert_mixed_mkwrite" [drivers/video/fbdev/core/fb.ko] undefined!
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply
* [PATCH v3 4/4] fbdev: hyperv_fb: Fix mmap of framebuffers allocated using alloc_pages()
From: mhkelley58 @ 2025-05-23 16:15 UTC (permalink / raw)
To: simona, deller, haiyangz, kys, wei.liu, decui, akpm
Cc: weh, tzimmermann, hch, dri-devel, linux-fbdev, linux-kernel,
linux-hyperv, linux-mm
In-Reply-To: <20250523161522.409504-1-mhklinux@outlook.com>
From: Michael Kelley <mhklinux@outlook.com>
Framebuffer memory allocated using alloc_pages() was added to hyperv_fb in
commit 3a6fb6c4255c ("video: hyperv: hyperv_fb: Use physical memory for fb
on HyperV Gen 1 VMs.") in kernel version 5.6. But mmap'ing such
framebuffers into user space has never worked due to limitations in the
kind of memory that fbdev deferred I/O works with. As a result of the
limitation, hyperv_fb's usage results in memory free lists becoming corrupt
and Linux eventually panics.
With support for framebuffers allocated using alloc_pages() recently added
to fbdev deferred I/O, fix the problem by setting the flag telling fbdev
deferred I/O to use the new support.
Fixes: 3a6fb6c4255c ("video: hyperv: hyperv_fb: Use physical memory for fb on HyperV Gen 1 VMs.")
Signed-off-by: Michael Kelley <mhklinux@outlook.com>
---
drivers/video/fbdev/hyperv_fb.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/video/fbdev/hyperv_fb.c b/drivers/video/fbdev/hyperv_fb.c
index 75338ffc703f..1698221f857e 100644
--- a/drivers/video/fbdev/hyperv_fb.c
+++ b/drivers/video/fbdev/hyperv_fb.c
@@ -1020,6 +1020,7 @@ static int hvfb_getmem(struct hv_device *hdev, struct fb_info *info)
info->fix.smem_len = screen_fb_size;
info->screen_base = par->mmio_vp;
info->screen_size = screen_fb_size;
+ info->flags |= FBINFO_KMEMFB;
par->need_docopy = false;
goto getmem_done;
--
2.25.1
^ permalink raw reply related
* [PATCH v3 3/4] fbdev/deferred-io: Support contiguous kernel memory framebuffers
From: mhkelley58 @ 2025-05-23 16:15 UTC (permalink / raw)
To: simona, deller, haiyangz, kys, wei.liu, decui, akpm
Cc: weh, tzimmermann, hch, dri-devel, linux-fbdev, linux-kernel,
linux-hyperv, linux-mm
In-Reply-To: <20250523161522.409504-1-mhklinux@outlook.com>
From: Michael Kelley <mhklinux@outlook.com>
Current defio code works only for framebuffer memory that is allocated
with vmalloc(). The code assumes that the underlying page refcount can
be used by the mm subsystem to manage each framebuffer page's lifecycle,
including freeing the page if the refcount goes to 0. This approach is
consistent with vmalloc'ed memory, but not with contiguous kernel memory
allocated via alloc_pages() or similar. The latter such memory pages
usually have a refcount of 0 when allocated, and would be incorrectly
freed page-by-page if used with defio. That free'ing corrupts the memory
free lists and Linux eventually panics. Simply bumping the refcount after
allocation doesn’t work because when the framebuffer memory is freed,
__free_pages() complains about non-zero refcounts.
Commit 37b4837959cb ("video: deferred io with physically contiguous
memory") from the year 2008 purported to add support for contiguous
kernel memory framebuffers. The motivating device, sh_mobile_lcdcfb, uses
dma_alloc_coherent() to allocate framebuffer memory, which is likely to
use alloc_pages(). It's unclear to me how this commit actually worked at
the time, unless dma_alloc_coherent() was pulling from a CMA pool instead
of alloc_pages(). Or perhaps alloc_pages() worked differently or on the
arm32 architecture on which sh_mobile_lcdcfb is used.
In any case, for x86 and arm64 today, commit 37b4837959cb9 is not
sufficient to support contiguous kernel memory framebuffers. The problem
can be seen with the hyperv_fb driver, which may allocate the framebuffer
memory using vmalloc() or alloc_pages(), depending on the configuration
of the Hyper-V guest VM (Gen 1 vs. Gen 2) and the size of the framebuffer.
Fix this limitation by adding defio support for contiguous kernel memory
framebuffers. A driver with a framebuffer allocated from contiguous
kernel memory must set the FBINFO_KMEMFB flag to indicate such.
Tested with the hyperv_fb driver in both configurations -- with a vmalloc()
framebuffer and with an alloc_pages() framebuffer on x86. Also verified a
vmalloc() framebuffer on arm64. Hardware is not available to me to verify
that the older arm32 devices still work correctly, but the path for
vmalloc() framebuffers is essentially unchanged.
Even with these changes, defio does not support framebuffers in MMIO
space, as defio code depends on framebuffer memory pages having
corresponding 'struct page's.
Fixes: 3a6fb6c4255c ("video: hyperv: hyperv_fb: Use physical memory for fb on HyperV Gen 1 VMs.")
Signed-off-by: Michael Kelley <mhklinux@outlook.com>
---
Changes in v3:
* Moved definition of FBINFO_KMEMFB flag to a separate patch
preceeding this one in the patch set [Helge Deller]
Changes in v2:
* Tweaked code comments regarding framebuffers allocated with
dma_alloc_coherent() [Christoph Hellwig]
drivers/video/fbdev/core/fb_defio.c | 128 +++++++++++++++++++++++-----
1 file changed, 108 insertions(+), 20 deletions(-)
diff --git a/drivers/video/fbdev/core/fb_defio.c b/drivers/video/fbdev/core/fb_defio.c
index 4fc93f253e06..f8ae91a1c4df 100644
--- a/drivers/video/fbdev/core/fb_defio.c
+++ b/drivers/video/fbdev/core/fb_defio.c
@@ -8,11 +8,40 @@
* for more details.
*/
+/*
+ * Deferred I/O ("defio") allows framebuffers that are mmap()'ed to user space
+ * to batch user space writes into periodic updates to the underlying
+ * framebuffer hardware or other implementation (such as with a virtualized
+ * framebuffer in a VM). At each batch interval, a callback is invoked in the
+ * framebuffer's kernel driver, and the callback is supplied with a list of
+ * pages that have been modified in the preceding interval. The callback can
+ * use this information to update the framebuffer hardware as necessary. The
+ * batching can improve performance and reduce the overhead of updating the
+ * hardware.
+ *
+ * Defio is supported on framebuffers allocated using vmalloc() and allocated
+ * as contiguous kernel memory using alloc_pages() or kmalloc(). These
+ * memory allocations all have corresponding "struct page"s. Framebuffers
+ * allocated using dma_alloc_coherent() should not be used with defio.
+ * Such allocations should be treated as a black box owned by the DMA
+ * layer, and should not be deconstructed into individual pages as defio
+ * does. Framebuffers in MMIO space are *not* supported because MMIO space
+ * does not have corrresponding "struct page"s.
+ *
+ * For framebuffers allocated using vmalloc(), struct fb_info must have
+ * "screen_buffer" set to the vmalloc address of the framebuffer. For
+ * framebuffers allocated from contiguous kernel memory, FBINFO_KMEMFB must
+ * be set, and "fix.smem_start" must be set to the physical address of the
+ * frame buffer. In both cases, "fix.smem_len" must be set to the framebuffer
+ * size in bytes.
+ */
+
#include <linux/module.h>
#include <linux/kernel.h>
#include <linux/errno.h>
#include <linux/string.h>
#include <linux/mm.h>
+#include <linux/pfn_t.h>
#include <linux/vmalloc.h>
#include <linux/delay.h>
#include <linux/interrupt.h>
@@ -37,7 +66,7 @@ static struct page *fb_deferred_io_get_page(struct fb_info *info, unsigned long
else if (info->fix.smem_start)
page = pfn_to_page((info->fix.smem_start + offs) >> PAGE_SHIFT);
- if (page)
+ if (page && !(info->flags & FBINFO_KMEMFB))
get_page(page);
return page;
@@ -137,6 +166,15 @@ static vm_fault_t fb_deferred_io_fault(struct vm_fault *vmf)
BUG_ON(!info->fbdefio->mapping);
+ if (info->flags & FBINFO_KMEMFB)
+ /*
+ * In this path, the VMA is marked VM_PFNMAP, so mm assumes
+ * there is no struct page associated with the page. The
+ * PFN must be directly inserted and the created PTE will be
+ * marked "special".
+ */
+ return vmf_insert_pfn(vmf->vma, vmf->address, page_to_pfn(page));
+
vmf->page = page;
return 0;
}
@@ -163,13 +201,14 @@ EXPORT_SYMBOL_GPL(fb_deferred_io_fsync);
/*
* Adds a page to the dirty list. Call this from struct
- * vm_operations_struct.page_mkwrite.
+ * vm_operations_struct.page_mkwrite or .pfn_mkwrite.
*/
-static vm_fault_t fb_deferred_io_track_page(struct fb_info *info, unsigned long offset,
+static vm_fault_t fb_deferred_io_track_page(struct fb_info *info, struct vm_fault *vmf,
struct page *page)
{
struct fb_deferred_io *fbdefio = info->fbdefio;
struct fb_deferred_io_pageref *pageref;
+ unsigned long offset = vmf->pgoff << PAGE_SHIFT;
vm_fault_t ret;
/* protect against the workqueue changing the page list */
@@ -182,20 +221,34 @@ static vm_fault_t fb_deferred_io_track_page(struct fb_info *info, unsigned long
}
/*
- * We want the page to remain locked from ->page_mkwrite until
- * the PTE is marked dirty to avoid mapping_wrprotect_range()
- * being called before the PTE is updated, which would leave
- * the page ignored by defio.
- * Do this by locking the page here and informing the caller
- * about it with VM_FAULT_LOCKED.
+ * The PTE must be marked writable before the defio deferred work runs
+ * again and potentially marks the PTE write-protected. If the order
+ * should be switched, the PTE would become writable without defio
+ * tracking the page, leaving the page forever ignored by defio.
+ *
+ * For vmalloc() framebuffers, the associated struct page is locked
+ * before releasing the defio lock. mm will later mark the PTE writaable
+ * and release the struct page lock. The struct page lock prevents
+ * the page from being prematurely being marked write-protected.
+ *
+ * For FBINFO_KMEMFB framebuffers, mm assumes there is no struct page,
+ * so the PTE must be marked writable while the defio lock is held.
*/
- lock_page(pageref->page);
+ if (info->flags & FBINFO_KMEMFB) {
+ unsigned long pfn = page_to_pfn(pageref->page);
+
+ ret = vmf_insert_mixed_mkwrite(vmf->vma, vmf->address,
+ __pfn_to_pfn_t(pfn, PFN_SPECIAL));
+ } else {
+ lock_page(pageref->page);
+ ret = VM_FAULT_LOCKED;
+ }
mutex_unlock(&fbdefio->lock);
/* come back after delay to process the deferred IO */
schedule_delayed_work(&info->deferred_work, fbdefio->delay);
- return VM_FAULT_LOCKED;
+ return ret;
err_mutex_unlock:
mutex_unlock(&fbdefio->lock);
@@ -207,10 +260,10 @@ static vm_fault_t fb_deferred_io_track_page(struct fb_info *info, unsigned long
* @fb_info: The fbdev info structure
* @vmf: The VM fault
*
- * This is a callback we get when userspace first tries to
- * write to the page. We schedule a workqueue. That workqueue
- * will eventually mkclean the touched pages and execute the
- * deferred framebuffer IO. Then if userspace touches a page
+ * This is a callback we get when userspace first tries to write to a
+ * page. We schedule a workqueue. That workqueue will eventually do
+ * mapping_wrprotect_range() on the written pages and execute the
+ * deferred framebuffer IO. Then if userspace writes to a page
* again, we repeat the same scheme.
*
* Returns:
@@ -218,12 +271,11 @@ static vm_fault_t fb_deferred_io_track_page(struct fb_info *info, unsigned long
*/
static vm_fault_t fb_deferred_io_page_mkwrite(struct fb_info *info, struct vm_fault *vmf)
{
- unsigned long offset = vmf->pgoff << PAGE_SHIFT;
struct page *page = vmf->page;
file_update_time(vmf->vma->vm_file);
- return fb_deferred_io_track_page(info, offset, page);
+ return fb_deferred_io_track_page(info, vmf, page);
}
/* vm_ops->page_mkwrite handler */
@@ -234,9 +286,25 @@ static vm_fault_t fb_deferred_io_mkwrite(struct vm_fault *vmf)
return fb_deferred_io_page_mkwrite(info, vmf);
}
+/*
+ * Similar to fb_deferred_io_mkwrite(), but for first writes to pages
+ * in VMAs that have VM_PFNMAP set.
+ */
+static vm_fault_t fb_deferred_io_pfn_mkwrite(struct vm_fault *vmf)
+{
+ struct fb_info *info = vmf->vma->vm_private_data;
+ unsigned long offset = vmf->pgoff << PAGE_SHIFT;
+ struct page *page = phys_to_page(info->fix.smem_start + offset);
+
+ file_update_time(vmf->vma->vm_file);
+
+ return fb_deferred_io_track_page(info, vmf, page);
+}
+
static const struct vm_operations_struct fb_deferred_io_vm_ops = {
.fault = fb_deferred_io_fault,
.page_mkwrite = fb_deferred_io_mkwrite,
+ .pfn_mkwrite = fb_deferred_io_pfn_mkwrite,
};
static const struct address_space_operations fb_deferred_io_aops = {
@@ -246,11 +314,31 @@ static const struct address_space_operations fb_deferred_io_aops = {
int fb_deferred_io_mmap(struct fb_info *info, struct vm_area_struct *vma)
{
vma->vm_page_prot = pgprot_decrypted(vma->vm_page_prot);
+ vm_flags_t flags = VM_DONTEXPAND | VM_DONTDUMP;
vma->vm_ops = &fb_deferred_io_vm_ops;
- vm_flags_set(vma, VM_DONTEXPAND | VM_DONTDUMP);
- if (!(info->flags & FBINFO_VIRTFB))
- vm_flags_set(vma, VM_IO);
+ if (info->flags & FBINFO_KMEMFB) {
+ /*
+ * I/O fault path calls vmf_insert_pfn(), which bug checks
+ * if the vma is not marked shared. mmap'ing the framebuffer
+ * as PRIVATE doesn't really make sense anyway, though doing
+ * so isn't harmful for vmalloc() framebuffers. So there's
+ * no prohibition for that case.
+ */
+ if (!(vma->vm_flags & VM_SHARED))
+ return -EINVAL;
+ /*
+ * Set VM_PFNMAP so mm code will not try to manage the pages'
+ * lifecycles. We don't want individual pages to be freed
+ * based on refcount. Instead the memory must be returned to
+ * the free pool in the usual way. Cf. the implementation of
+ * remap_pfn_range() and remap_pfn_range_internal().
+ */
+ flags |= VM_PFNMAP | VM_IO;
+ } else if (!(info->flags & FBINFO_VIRTFB)) {
+ flags |= VM_IO;
+ }
+ vm_flags_set(vma, flags);
vma->vm_private_data = info;
return 0;
}
--
2.25.1
^ permalink raw reply related
* [PATCH v3 2/4] fbdev: Add flag indicating framebuffer is allocated from kernel memory
From: mhkelley58 @ 2025-05-23 16:15 UTC (permalink / raw)
To: simona, deller, haiyangz, kys, wei.liu, decui, akpm
Cc: weh, tzimmermann, hch, dri-devel, linux-fbdev, linux-kernel,
linux-hyperv, linux-mm
In-Reply-To: <20250523161522.409504-1-mhklinux@outlook.com>
From: Michael Kelley <mhklinux@outlook.com>
Add a flag that fbdev drivers can set to indicate that the framebuffer
memory comes from alloc_pages() or similar as opposed to vmalloc()
memory. The flag is to be used by fbdev deferred I/O.
Signed-off-by: Michael Kelley <mhklinux@outlook.com>
---
Changes in v3:
* This patch is new in v3. The definition of FBINFO_KMEMFB
was previously combined into the next patch of the series.
[Helge Deller]
include/linux/fb.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/include/linux/fb.h b/include/linux/fb.h
index 05cc251035da..a1121116eef0 100644
--- a/include/linux/fb.h
+++ b/include/linux/fb.h
@@ -396,6 +396,7 @@ struct fb_tile_ops {
/* hints */
#define FBINFO_VIRTFB 0x0004 /* FB is System RAM, not device. */
+#define FBINFO_KMEMFB 0x0008 /* FB is allocated in contig kernel mem */
#define FBINFO_PARTIAL_PAN_OK 0x0040 /* otw use pan only for double-buffering */
#define FBINFO_READS_FAST 0x0080 /* soft-copy faster than rendering */
--
2.25.1
^ permalink raw reply related
* [PATCH v3 1/4] mm: Export vmf_insert_mixed_mkwrite()
From: mhkelley58 @ 2025-05-23 16:15 UTC (permalink / raw)
To: simona, deller, haiyangz, kys, wei.liu, decui, akpm
Cc: weh, tzimmermann, hch, dri-devel, linux-fbdev, linux-kernel,
linux-hyperv, linux-mm
In-Reply-To: <20250523161522.409504-1-mhklinux@outlook.com>
From: Michael Kelley <mhklinux@outlook.com>
Export vmf_insert_mixed_mkwrite() for use by fbdev deferred I/O code,
which can be built as a module.
Commit cd1e0dac3a3e ("mm: unexport vmf_insert_mixed_mkwrite") is
effectively reverted.
Signed-off-by: Michael Kelley <mhklinux@outlook.com>
---
Changes in v2:
* Exported as GPL symbol [Christoph Hellwig]
mm/memory.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/mm/memory.c b/mm/memory.c
index 5cb48f262ab0..58ba40a676c9 100644
--- a/mm/memory.c
+++ b/mm/memory.c
@@ -2688,6 +2688,7 @@ vm_fault_t vmf_insert_mixed_mkwrite(struct vm_area_struct *vma,
{
return __vm_insert_mixed(vma, addr, pfn, true);
}
+EXPORT_SYMBOL_GPL(vmf_insert_mixed_mkwrite);
/*
* maps a range of physical memory into the requested pages. the old
--
2.25.1
^ permalink raw reply related
* [PATCH v3 0/4] fbdev: Add deferred I/O support for contiguous kernel memory framebuffers
From: mhkelley58 @ 2025-05-23 16:15 UTC (permalink / raw)
To: simona, deller, haiyangz, kys, wei.liu, decui, akpm
Cc: weh, tzimmermann, hch, dri-devel, linux-fbdev, linux-kernel,
linux-hyperv, linux-mm
From: Michael Kelley <mhklinux@outlook.com>
Current deferred I/O code works only for framebuffer memory that is
allocated with vmalloc(). The code assumes that the underlying page
refcount can be used by the mm subsystem to manage each framebuffer
page's lifecycle, which is consistent with vmalloc'ed memory, but not
with contiguous kernel memory from alloc_pages() or similar. When used
with contiguous kernel memory, current deferred I/O code eventually
causes the memory free lists to be scrambled, and a kernel panic ensues.
The problem is seen with the hyperv_fb driver when mmap'ing the
framebuffer into user space, as that driver uses alloc_pages() for the
framebuffer in some configurations. This patch set fixes the problem
by supporting contiguous kernel memory framebuffers with deferred I/O.
Patch 1 exports a 'mm' subsystem function needed by Patch 3.
Pathc 2 defines the FBINFO_KMEMFB flag for use by Patches 3 and 4.
Patch 3 is the changes to the fbdev deferred I/O code. More details
are in the commit message of Patch 3.
Patch 4 updates the hyperv_fb driver to use the new functionality
from Patch 3.
Michael Kelley (4):
mm: Export vmf_insert_mixed_mkwrite()
fbdev: Add flag indicating framebuffer is allocated from kernel memory
fbdev/deferred-io: Support contiguous kernel memory framebuffers
fbdev: hyperv_fb: Fix mmap of framebuffers allocated using
alloc_pages()
drivers/video/fbdev/core/fb_defio.c | 128 +++++++++++++++++++++++-----
drivers/video/fbdev/hyperv_fb.c | 1 +
include/linux/fb.h | 1 +
mm/memory.c | 1 +
4 files changed, 111 insertions(+), 20 deletions(-)
--
2.25.1
^ permalink raw reply
* Re: [PATCH/RFC 0/3] Atari DRM driver
From: Eero Tamminen @ 2025-05-21 22:56 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, David Airlie,
Daniel Vetter, Helge Deller, Michael Schmitz, dri-devel,
linux-fbdev, linux-m68k, John Paul Adrian Glaubitz
In-Reply-To: <CAMuHMdXSWiM_xofyfgpoc0Jj8a_PwRR_tFe79t8=-X85-7WZug@mail.gmail.com>
Hi Geert,
On 21.5.2025 10.06, Geert Uytterhoeven wrote:
> On Wed, 21 May 2025 at 01:59, Eero Tamminen <oak@helsinkinet.fi> wrote:
>> I tried your "atari-drm-wip-v1" branch commits on top of 6.14.
>
> Thanks for testing!
>
>> After some minor changes those applied. Getting it to build required
>> adding "&shadow_plane_state->fmtcnv_state" (struct drm_format_conv_state
>> *) argument to *_blit() functions in atari_drm.c, and changing:
>> drm_fbdev_generic_setup(dev, dev->mode_config.preferred_depth);
>> in its probe function to:
>> struct drm_format_info *format = NULL;
>> drm_client_setup(dev, format);
>
> I do keep it up-to-date locally, so I could provide these changes,
> if you are interested.
Yes, please! (see below)
>> However, the result is not working very well yet.
>>
>> Driver gets initialized fine under Hatari TT emulation:
>> -------------------------
>> atafb atafb: phys_screen_base 511000 screen_len 311296
>> atafb atafb: Determined 1280x960, depth 1
>> atafb atafb: virtual 1280x1945
>> Console: switching to mono frame buffer device 160x60
>> fb0: frame buffer device, using 304K of video memory
>> ...
>> atari_drm atari_drm: phys_screen_base 55d000 screen_len 311296
>> atari_drm atari_drm: Determined 1280x960, depth 1
>> atari_drm atari_drm: virtual 1280x1945
>> [drm] Initialized atari_drm 1.0.0 for atari_drm on minor 0
>> atari_drm atari_drm: Atari DRM, using 304K of video memory
>> -------------------------
>>
>> However, once screen switches from "atafb" to "atari_drm" driver, Linux
>> boot logo & texts disappear, and (emulated) screen is either all white
>> (on mono monitor) or all black (on VGA & RGGB monitors).
>
> So you have both atafb and atari_drm enabled? Please don't do that.
Disabling CONFIG_FB_ATARI option (but still keeping rest of FB options),
worked worse:
-------------------------
atari_drm atari_drm: phys_screen_base 512000 screen_len 311296
atari_drm atari_drm: Determined 640x480, depth 4
atari_drm atari_drm: virtual 640x972
[drm] Initialized atari_drm 1.0.0 for atari_drm on minor 0
atari_drm atari_drm: Atari DRM, using 304K of video memory
Data write fault at 0x00000020 in Super Data (pc=0x3115f6)
BAD KERNEL BUSERR
Oops: 00000000
PC: [<003115f6>] strcpy+0x16/0x22
SR: 2200 SP: (ptrval) a2: 01026000
d0: 00000000 d1: 0000015b d2: 0114e000 d3: 00319f2a
d4: 01181118 d5: 00000001 a0: 00000020 a1: 003e1cbf
Process swapper (pid: 1, task=(ptrval))
Frame format=A ssw=0315 isc=66f2 isb=2008 daddr=00000020 dobuf=0000005b
Stack from 01029c24:
...
Call Trace:
[<001e6bc8>] __drm_fb_helper_initial_config_and_unlock+0x3a6/0x46c
[<001e6cb0>] drm_fb_helper_initial_config+0x22/0x30
[<001e85a0>] drm_fbdev_client_hotplug+0x6e/0x9c
[<001d6efc>] drm_client_register+0x62/0x9e
[<001e8714>] drm_fbdev_client_setup+0x146/0x14e
[<00311650>] strcmp+0x0/0x34
[<001e7bb6>] drm_client_setup+0x32/0xaa
[<00007336>] _dev_info+0x0/0x34
[<0044b472>] atari_drm_probe+0xd58/0xe32
...
-------------------------
=> due to me using NULL as drm_client_setup() "drm_format_info"?
>> And while "atafb" works fine also under Falcon emulation with RGB (50Hz)
>> or VGA (60Hz) monitor, "atari_drm" probing fails:
>> -------------------------
>> genirq: Flags mismatch irq 4. 00200000 (framebuffer:modeswitch) vs.
>> 00200000 (framebuffer:modeswitch)
>
> That's also a sign of two drivers requesting the same IRQ unexpectedly.
>
>> atari_drm atari_drm: probe with driver atari_drm failed with error -16
>
> i.e. -EBUSY.
Ok, makes sense.
- Eero
^ permalink raw reply
* Re: [PATCH 2/2] staging: sm750fb: rename dpPortBase in lynx_accel
From: Greg KH @ 2025-05-21 11:47 UTC (permalink / raw)
To: Eric Florin
Cc: teddy.wang, sudipm.mukherjee, linux-fbdev, linux-staging,
linux-kernel
In-Reply-To: <97fcc39f3e63f465c49e8725d10f7c43fd35cd85.1747605658.git.ericflorin@google.com>
On Sun, May 18, 2025 at 03:09:47PM -0700, Eric Florin wrote:
> Rename `dpPortBase` to `dp_port_base` to conform with kernel style
> guidelines as reported by checkpatch.pl
>
> CHECK: Avoid CamelCase: <dpPortBase>
>
> Signed-off-by: Eric Florin <ericflorin@google.com>
> ---
> drivers/staging/sm750fb/sm750.h | 2 +-
> drivers/staging/sm750fb/sm750_accel.c | 2 +-
> drivers/staging/sm750fb/sm750_hw.c | 2 +-
> 3 files changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/staging/sm750fb/sm750.h b/drivers/staging/sm750fb/sm750.h
> index a2342c69a65a..0ed1e18611ba 100644
> --- a/drivers/staging/sm750fb/sm750.h
> +++ b/drivers/staging/sm750fb/sm750.h
> @@ -52,7 +52,7 @@ struct lynx_accel {
> /* base virtual address of DPR registers */
> volatile unsigned char __iomem *dpr_base;
> /* base virtual address of de data port */
> - volatile unsigned char __iomem *dpPortBase;
> + volatile unsigned char __iomem *dp_port_base;
Same here, are you sure this doesn't come directly from the hardware
spec?
thanks,
greg k-h
^ permalink raw reply
* Re: [PATCH 1/2] staging: sm750fb: rename dprBase to dpr_base
From: Greg KH @ 2025-05-21 11:47 UTC (permalink / raw)
To: Eric Florin
Cc: teddy.wang, sudipm.mukherjee, linux-fbdev, linux-staging,
linux-kernel
In-Reply-To: <d4b30e00ca64a233efc2a7dac4bc568186dafc71.1747605658.git.ericflorin@google.com>
On Sun, May 18, 2025 at 03:09:46PM -0700, Eric Florin wrote:
> Rename `dprBase` to `dpr_base` to conform with kernel style guidelines
> as reported by checkpatch.pl
>
> CHECK: Avoid CamelCase: <dprBase>
>
> Signed-off-by: Eric Florin <ericflorin@google.com>
> ---
> drivers/staging/sm750fb/sm750.h | 2 +-
> drivers/staging/sm750fb/sm750_accel.c | 4 ++--
> drivers/staging/sm750fb/sm750_hw.c | 2 +-
> 3 files changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/staging/sm750fb/sm750.h b/drivers/staging/sm750fb/sm750.h
> index aff69661c8e6..a2342c69a65a 100644
> --- a/drivers/staging/sm750fb/sm750.h
> +++ b/drivers/staging/sm750fb/sm750.h
> @@ -50,7 +50,7 @@ struct init_status {
>
> struct lynx_accel {
> /* base virtual address of DPR registers */
> - volatile unsigned char __iomem *dprBase;
> + volatile unsigned char __iomem *dpr_base;
Are you sure this isn't coming directly from a hardware data sheet or
description somewhere? Based on the type, it really looks like it is.
If not, please document it properly that you have researched this in the
changelog text when resending.
Don't change variable names that reflect external names, that just makes
for more confusion over time.
thanks,
greg k-h
^ permalink raw reply
* Re: [PATCH] staging: sm750fb: rename `regValue` to `reg_value`
From: Greg KH @ 2025-05-21 11:45 UTC (permalink / raw)
To: Eric Florin
Cc: teddy.wang, sudipm.mukherjee, linux-fbdev, linux-staging,
linux-kernel
In-Reply-To: <20250506033340.3689818-1-ericflorin@google.com>
On Mon, May 05, 2025 at 08:30:13PM -0700, Eric Florin wrote:
> Rename `regValue` to `reg_value` in `write_dpr` to conform with style
> guidelines as reported by checkpatch.pl
>
> CHECK: Avoid CamelCase: <regValue>
>
> Signed-off-by: Eric Florin <ericflorin@google.com>
> ---
> drivers/staging/sm750fb/sm750_accel.c | 5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/staging/sm750fb/sm750_accel.c b/drivers/staging/sm750fb/sm750_accel.c
> index 44b9e3fe3a41..5648476a8f3c 100644
> --- a/drivers/staging/sm750fb/sm750_accel.c
> +++ b/drivers/staging/sm750fb/sm750_accel.c
> @@ -17,9 +17,10 @@
>
> #include "sm750.h"
> #include "sm750_accel.h"
> -static inline void write_dpr(struct lynx_accel *accel, int offset, u32 regValue)
> +static inline void write_dpr(struct lynx_accel *accel, int offset,
> + u32 reg_value)
You also wrapped this line, why? It should be fine as-is.
thanks,
greg k-h
^ permalink raw reply
* Re: [PATCH/RFC 0/3] Atari DRM driver
From: Geert Uytterhoeven @ 2025-05-21 7:06 UTC (permalink / raw)
To: Eero Tamminen
Cc: Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, David Airlie,
Daniel Vetter, Helge Deller, Michael Schmitz, dri-devel,
linux-fbdev, linux-m68k, John Paul Adrian Glaubitz
In-Reply-To: <74946b31-6166-44b0-b2a7-b0633f014b60@helsinkinet.fi>
Hi Eero,
On Wed, 21 May 2025 at 01:59, Eero Tamminen <oak@helsinkinet.fi> wrote:
> On 23.1.2023 17.10, Geert Uytterhoeven wrote:
> > On Mon, Jan 23, 2023 at 4:09 PM John Paul Adrian Glaubitz
> > <glaubitz@physik.fu-berlin.de> wrote:
> >> On 11/25/22 21:31, Geert Uytterhoeven wrote:
> >>> This RFC patch series adds a DRM driver for the good old Atari
> >>> ST/TT/Falcon hardware. It was developed and tested (only) on the ARAnyM
> >>> emulator.
> >>
> >> I just remembered this WIP driver. Has there been any progress?
> >
> > So far no further progress.
>
> I tried your "atari-drm-wip-v1" branch commits on top of 6.14.
Thanks for testing!
> After some minor changes those applied. Getting it to build required
> adding "&shadow_plane_state->fmtcnv_state" (struct drm_format_conv_state
> *) argument to *_blit() functions in atari_drm.c, and changing:
> drm_fbdev_generic_setup(dev, dev->mode_config.preferred_depth);
> in its probe function to:
> struct drm_format_info *format = NULL;
> drm_client_setup(dev, format);
I do keep it up-to-date locally, so I could provide these changes,
if you are interested.
> However, the result is not working very well yet.
>
> Driver gets initialized fine under Hatari TT emulation:
> -------------------------
> atafb atafb: phys_screen_base 511000 screen_len 311296
> atafb atafb: Determined 1280x960, depth 1
> atafb atafb: virtual 1280x1945
> Console: switching to mono frame buffer device 160x60
> fb0: frame buffer device, using 304K of video memory
> ...
> atari_drm atari_drm: phys_screen_base 55d000 screen_len 311296
> atari_drm atari_drm: Determined 1280x960, depth 1
> atari_drm atari_drm: virtual 1280x1945
> [drm] Initialized atari_drm 1.0.0 for atari_drm on minor 0
> atari_drm atari_drm: Atari DRM, using 304K of video memory
> -------------------------
>
> However, once screen switches from "atafb" to "atari_drm" driver, Linux
> boot logo & texts disappear, and (emulated) screen is either all white
> (on mono monitor) or all black (on VGA & RGGB monitors).
So you have both atafb and atari_drm enabled? Please don't do that.
> And while "atafb" works fine also under Falcon emulation with RGB (50Hz)
> or VGA (60Hz) monitor, "atari_drm" probing fails:
> -------------------------
> genirq: Flags mismatch irq 4. 00200000 (framebuffer:modeswitch) vs.
> 00200000 (framebuffer:modeswitch)
That's also a sign of two drivers requesting the same IRQ unexpectedly.
> atari_drm atari_drm: probe with driver atari_drm failed with error -16
i.e. -EBUSY.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH/RFC 0/3] Atari DRM driver
From: Eero Tamminen @ 2025-05-20 23:59 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, David Airlie,
Daniel Vetter, Helge Deller, Michael Schmitz, dri-devel,
linux-fbdev, linux-m68k, John Paul Adrian Glaubitz
In-Reply-To: <CAMuHMdWHUnWBN7ddBow+fqmt8W--9wFe5x_YMeRg7GQ=BNAL2Q@mail.gmail.com>
Hi Geert,
On 23.1.2023 17.10, Geert Uytterhoeven wrote:
> On Mon, Jan 23, 2023 at 4:09 PM John Paul Adrian Glaubitz
> <glaubitz@physik.fu-berlin.de> wrote:
>> On 11/25/22 21:31, Geert Uytterhoeven wrote:
>>> This RFC patch series adds a DRM driver for the good old Atari
>>> ST/TT/Falcon hardware. It was developed and tested (only) on the ARAnyM
>>> emulator.
>>
>> I just remembered this WIP driver. Has there been any progress?
>
> So far no further progress.
I tried your "atari-drm-wip-v1" branch commits on top of 6.14.
After some minor changes those applied. Getting it to build required
adding "&shadow_plane_state->fmtcnv_state" (struct drm_format_conv_state
*) argument to *_blit() functions in atari_drm.c, and changing:
drm_fbdev_generic_setup(dev, dev->mode_config.preferred_depth);
in its probe function to:
struct drm_format_info *format = NULL;
drm_client_setup(dev, format);
However, the result is not working very well yet.
Driver gets initialized fine under Hatari TT emulation:
-------------------------
atafb atafb: phys_screen_base 511000 screen_len 311296
atafb atafb: Determined 1280x960, depth 1
atafb atafb: virtual 1280x1945
Console: switching to mono frame buffer device 160x60
fb0: frame buffer device, using 304K of video memory
...
atari_drm atari_drm: phys_screen_base 55d000 screen_len 311296
atari_drm atari_drm: Determined 1280x960, depth 1
atari_drm atari_drm: virtual 1280x1945
[drm] Initialized atari_drm 1.0.0 for atari_drm on minor 0
atari_drm atari_drm: Atari DRM, using 304K of video memory
-------------------------
However, once screen switches from "atafb" to "atari_drm" driver, Linux
boot logo & texts disappear, and (emulated) screen is either all white
(on mono monitor) or all black (on VGA & RGGB monitors).
And while "atafb" works fine also under Falcon emulation with RGB (50Hz)
or VGA (60Hz) monitor, "atari_drm" probing fails:
-------------------------
genirq: Flags mismatch irq 4. 00200000 (framebuffer:modeswitch) vs.
00200000 (framebuffer:modeswitch)
CPU: 0 UID: 0 PID: 1 Comm: swapper Not tainted
6.14.0hatari-00001-g1d98935cdfd7-dirty #4
Stack from 01029c78:
...
Call Trace: [<000088b0>] dump_stack+0x10/0x16
[<0005852a>] __setup_irq+0x264/0x4a4
[<00200000>] dma_buf_map_attachment_unlocked+0x34/0x6a
[<00200000>] dma_buf_map_attachment_unlocked+0x34/0x6a
[<001e874c>] falcon_vbl_switcher+0x0/0x14a
[<00058876>] request_threaded_irq+0x10c/0x142
[<0030fa1e>] strsep+0x0/0x36
[<00449cfe>] atari_drm_probe+0x8ba/0xe28
[<001e874c>] falcon_vbl_switcher+0x0/0x14a
[<00200000>] dma_buf_map_attachment_unlocked+0x34/0x6a
[<00042d6c>] parse_args+0x0/0x260
[<00300c2a>] klist_next+0x0/0x8a
[<00300c2a>] klist_next+0x0/0x8a
[<00116d3c>] sysfs_do_create_link_sd+0x68/0x92
[<00116d8e>] sysfs_create_link+0x28/0x3a
[<001f2a52>] driver_sysfs_add+0x46/0x6c
[<001f4dd0>] platform_probe+0x26/0x58
[<001f3390>] really_probe+0xfa/0x1f8
[<001f3296>] really_probe+0x0/0x1f8
[<001f3558>] __driver_probe_device+0xca/0xd8
[<00042d6c>] parse_args+0x0/0x260
[<00300c2a>] klist_next+0x0/0x8a
[<001f35da>] driver_probe_device+0x24/0x7c
[<001f378a>] __driver_attach+0xca/0xda
[<00300c2a>] klist_next+0x0/0x8a
[<001f2156>] bus_for_each_dev+0x64/0x8a
[<001f2d24>] driver_attach+0x1a/0x1e
[<001f36c0>] __driver_attach+0x0/0xda
[<001f270c>] bus_add_driver+0x9a/0x188
[<001f3e66>] driver_register+0xa6/0xe4
[<0044a790>] __platform_driver_probe+0x6c/0xa4
[<004493ee>] atari_drm_init+0x0/0x56
[<0044943c>] atari_drm_init+0x4e/0x56
[<00449444>] atari_drm_probe+0x0/0xe28
[<00437578>] do_one_initcall+0x5a/0x164
[<0030f7e4>] strcpy+0x0/0x22
[<00042d6c>] parse_args+0x0/0x260
[<00060006>] __timer_delete_sync+0x38/0x6a
[<00437820>] kernel_init_freeable+0x13e/0x198
[<00437876>] kernel_init_freeable+0x194/0x198
[<004493ee>] atari_drm_init+0x0/0x56
[<00315cac>] kernel_init+0x0/0xf4
[<00315cc4>] kernel_init+0x18/0xf4
[<00315cac>] kernel_init+0x0/0xf4
[<0000934c>] ret_from_kernel_thread+0xc/0x14
atari_drm atari_drm: probe with driver atari_drm failed with error -16
-------------------------
Any ideas?
============================================================
Btw. While testing this, I noticed quite a few "atafb" issues:
It panics under Falcon with mono monitor, so I couldn't test that with
"atari_drm":
-------------------------
Kernel panic - not syncing: can't set default video mode
-------------------------
"video=atafb:stlow" CLI arg causes probe fail on Falcon + VGA monitor
(but works with RGB monitor, and on TT):
-------------------------
atafb atafb: probe with driver atafb failed with error -22
-------------------------
Kernel CLI argument "video=atafb:falh2" gives 16-color mode, same as
"falh16", not 2-color one as documented (in arch/m68k/kernel-options.rst).
Monochrome Tux logo is not shown in 2-color ("vga2", "sthigh") modes,
only in 4-color ("vga4", "stmed") ones.
On TT, requesting unsupported mode, e.g. "fal2" or "tthigh" on color
monitor, gives lowest (320x200x4) resolution, instead of more reasonable
one, like the 640x480x4 given under Falcon. "ttmid" (640x480x4) would
be more reasonable default...
On TT, console text color is blue-on-black in "sthigh" mode, instead of
expected white-on-black (and cyan-on-black in "stmid"). I suspect this
is because "Duochrome" mode is not handled correctly, its colors should
be set with palette entries 254 & 255, and palette entry 0 is used just
for inverting the screen (like on real ST-high monitor/resolution).
- Eero
^ permalink raw reply
* [PATCH v2] dummycon: Trigger redraw when switching consoles with deferred takeover
From: Thomas Zimmermann @ 2025-05-20 7:14 UTC (permalink / raw)
To: gregkh, hdegoede, arvidjaar, tiwai
Cc: dri-devel, linux-fbdev, linux-kernel, Thomas Zimmermann,
Javier Martinez Canillas, stable
Signal vt subsystem to redraw console when switching to dummycon
with deferred takeover enabled. Makes the console switch to fbcon
and displays the available output.
With deferred takeover enabled, dummycon acts as the placeholder
until the first output to the console happens. At that point, fbcon
takes over. If the output happens while dummycon is not active, it
cannot inform fbcon. This is the case if the vt subsystem runs in
graphics mode.
A typical graphical boot starts plymouth, a display manager and a
compositor; all while leaving out dummycon. Switching to a text-mode
console leaves the console with dummycon even if a getty terminal
has been started.
Returning true from dummycon's con_switch helper signals the vt
subsystem to redraw the screen. If there's output available dummycon's
con_putc{s} helpers trigger deferred takeover of fbcon, which sets a
display mode and displays the output. If no output is available,
dummycon remains active.
v2:
- make the comment slightly more verbose (Javier)
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Reported-by: Andrei Borzenkov <arvidjaar@gmail.com>
Closes: https://bugzilla.suse.com/show_bug.cgi?id=1242191
Tested-by: Andrei Borzenkov <arvidjaar@gmail.com>
Acked-by: Javier Martinez Canillas <javierm@redhat.com>
Fixes: 83d83bebf401 ("console/fbcon: Add support for deferred console takeover")
Cc: Hans de Goede <hdegoede@redhat.com>
Cc: linux-fbdev@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
Cc: <stable@vger.kernel.org> # v4.19+
---
drivers/video/console/dummycon.c | 18 +++++++++++++-----
1 file changed, 13 insertions(+), 5 deletions(-)
diff --git a/drivers/video/console/dummycon.c b/drivers/video/console/dummycon.c
index 139049368fdc..7d02470f19b9 100644
--- a/drivers/video/console/dummycon.c
+++ b/drivers/video/console/dummycon.c
@@ -85,6 +85,15 @@ static bool dummycon_blank(struct vc_data *vc, enum vesa_blank_mode blank,
/* Redraw, so that we get putc(s) for output done while blanked */
return true;
}
+
+static bool dummycon_switch(struct vc_data *vc)
+{
+ /*
+ * Redraw, so that we get putc(s) for output done while switched
+ * away. Informs deferred consoles to take over the display.
+ */
+ return true;
+}
#else
static void dummycon_putc(struct vc_data *vc, u16 c, unsigned int y,
unsigned int x) { }
@@ -95,6 +104,10 @@ static bool dummycon_blank(struct vc_data *vc, enum vesa_blank_mode blank,
{
return false;
}
+static bool dummycon_switch(struct vc_data *vc)
+{
+ return false;
+}
#endif
static const char *dummycon_startup(void)
@@ -124,11 +137,6 @@ static bool dummycon_scroll(struct vc_data *vc, unsigned int top,
return false;
}
-static bool dummycon_switch(struct vc_data *vc)
-{
- return false;
-}
-
/*
* The console `switch' structure for the dummy console
*
--
2.49.0
^ permalink raw reply related
* Re: [PATCH v6] backlight: led-backlight: add devlink to supplier LEDs
From: Herve Codina @ 2025-05-20 6:05 UTC (permalink / raw)
To: Luca Ceresoli
Cc: Lee Jones, Daniel Thompson, Jingoo Han, Helge Deller,
Tony Lindgren, Pavel Machek, Jean-Jacques Hiblot, Tomi Valkeinen,
Saravana Kannan, Thomas Petazzoni, Daniel Thompson, dri-devel,
linux-fbdev, linux-kernel, Alexander Sverdlin
In-Reply-To: <20250519-led-backlight-add-devlink-to-supplier-class-device-v6-1-845224aeb2ce@bootlin.com>
Hi Luca,
On Mon, 19 May 2025 22:19:11 +0200
Luca Ceresoli <luca.ceresoli@bootlin.com> wrote:
> led-backlight is a consumer of one or multiple LED class devices, but
> devlink is currently unable to create correct supplier-producer links when
> the supplier is a class device. It creates instead a link where the
> supplier is the parent of the expected device.
>
> One consequence is that removal order is not correctly enforced.
>
> Issues happen for example with the following sections in a device tree
> overlay:
>
> // An LED driver chip
> pca9632@62 {
> compatible = "nxp,pca9632";
> reg = <0x62>;
>
> // ...
>
> addon_led_pwm: led-pwm@3 {
> reg = <3>;
> label = "addon:led:pwm";
> };
> };
>
> backlight-addon {
> compatible = "led-backlight";
> leds = <&addon_led_pwm>;
> brightness-levels = <255>;
> default-brightness-level = <255>;
> };
>
> In this example, the devlink should be created between the backlight-addon
> (consumer) and the pca9632@62 (supplier). Instead it is created between the
> backlight-addon (consumer) and the parent of the pca9632@62, which is
> typically the I2C bus adapter.
>
> On removal of the above overlay, the LED driver can be removed before the
> backlight device, resulting in:
>
> Unable to handle kernel NULL pointer dereference at virtual address 0000000000000010
> ...
> Call trace:
> led_put+0xe0/0x140
> devm_led_release+0x6c/0x98
>
> Another way to reproduce the bug without any device tree overlays is
> unbinding the LED class device (pca9632@62) before unbinding the consumer
> (backlight-addon):
>
> echo 11-0062 >/sys/bus/i2c/drivers/leds-pca963x/unbind
> echo ...backlight-dock >/sys/bus/platform/drivers/led-backlight/unbind
>
> Fix by adding a devlink between the consuming led-backlight device and the
> supplying LED device, as other drivers and subsystems do as well.
>
> Tested-by: Alexander Sverdlin <alexander.sverdlin@siemens.com>
> Fixes: ae232e45acf9 ("backlight: add led-backlight driver")
> Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
Reviewed-by: Herve Codina <herve.codina@bootlin.com>
Best regards,
Hervé
^ permalink raw reply
* [PATCH v6] backlight: led-backlight: add devlink to supplier LEDs
From: Luca Ceresoli @ 2025-05-19 20:19 UTC (permalink / raw)
To: Lee Jones, Daniel Thompson, Jingoo Han, Helge Deller,
Tony Lindgren, Pavel Machek, Jean-Jacques Hiblot, Tomi Valkeinen
Cc: Saravana Kannan, Hervé Codina, Thomas Petazzoni,
Daniel Thompson, dri-devel, linux-fbdev, linux-kernel,
Alexander Sverdlin, Luca Ceresoli
led-backlight is a consumer of one or multiple LED class devices, but
devlink is currently unable to create correct supplier-producer links when
the supplier is a class device. It creates instead a link where the
supplier is the parent of the expected device.
One consequence is that removal order is not correctly enforced.
Issues happen for example with the following sections in a device tree
overlay:
// An LED driver chip
pca9632@62 {
compatible = "nxp,pca9632";
reg = <0x62>;
// ...
addon_led_pwm: led-pwm@3 {
reg = <3>;
label = "addon:led:pwm";
};
};
backlight-addon {
compatible = "led-backlight";
leds = <&addon_led_pwm>;
brightness-levels = <255>;
default-brightness-level = <255>;
};
In this example, the devlink should be created between the backlight-addon
(consumer) and the pca9632@62 (supplier). Instead it is created between the
backlight-addon (consumer) and the parent of the pca9632@62, which is
typically the I2C bus adapter.
On removal of the above overlay, the LED driver can be removed before the
backlight device, resulting in:
Unable to handle kernel NULL pointer dereference at virtual address 0000000000000010
...
Call trace:
led_put+0xe0/0x140
devm_led_release+0x6c/0x98
Another way to reproduce the bug without any device tree overlays is
unbinding the LED class device (pca9632@62) before unbinding the consumer
(backlight-addon):
echo 11-0062 >/sys/bus/i2c/drivers/leds-pca963x/unbind
echo ...backlight-dock >/sys/bus/platform/drivers/led-backlight/unbind
Fix by adding a devlink between the consuming led-backlight device and the
supplying LED device, as other drivers and subsystems do as well.
Tested-by: Alexander Sverdlin <alexander.sverdlin@siemens.com>
Fixes: ae232e45acf9 ("backlight: add led-backlight driver")
Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
---
Changes in v6:
- EDITME: describe what is new in this series revision.
- EDITME: use bulletpoints and terse descriptions.
- Link to v5: https://lore.kernel.org/r/20250519-led-backlight-add-devlink-to-supplier-class-device-v5-1-76d6fd4aeb2f@bootlin.com
---
Changes in v6:
- fix incorrect array index
- further improve commit message
- Link to v5: https://lore.kernel.org/r/20250519-led-backlight-add-devlink-to-supplier-class-device-v5-1-76d6fd4aeb2f@bootlin.com
Changes in v5:
- separated this patch as a standalone patch
- improved commit message, adding feedback from Alexander
- no code changes
This patch first appeared in the v4 of a longer series, even though the
issue is orthogonal:
https://lore.kernel.org/all/20240917-hotplug-drm-bridge-v4-6-bc4dfee61be6@bootlin.com/
---
drivers/video/backlight/led_bl.c | 13 +++++++++++++
1 file changed, 13 insertions(+)
diff --git a/drivers/video/backlight/led_bl.c b/drivers/video/backlight/led_bl.c
index d2db157b2c290adc3a159023e9e2394fc877388c..0ed585eb27903df43651c5365f479f7865cc8a95 100644
--- a/drivers/video/backlight/led_bl.c
+++ b/drivers/video/backlight/led_bl.c
@@ -209,6 +209,19 @@ static int led_bl_probe(struct platform_device *pdev)
return PTR_ERR(priv->bl_dev);
}
+ for (i = 0; i < priv->nb_leds; i++) {
+ struct device_link *link;
+
+ link = device_link_add(&pdev->dev, priv->leds[i]->dev->parent,
+ DL_FLAG_AUTOREMOVE_CONSUMER);
+ if (!link) {
+ dev_err(&pdev->dev, "Failed to add devlink (consumer %s, supplier %s)\n",
+ dev_name(&pdev->dev), dev_name(priv->leds[i]->dev->parent));
+ backlight_device_unregister(priv->bl_dev);
+ return -EINVAL;
+ }
+ }
+
for (i = 0; i < priv->nb_leds; i++) {
mutex_lock(&priv->leds[i]->led_access);
led_sysfs_disable(priv->leds[i]);
---
base-commit: a5806cd506af5a7c19bcd596e4708b5c464bfd21
change-id: 20250519-led-backlight-add-devlink-to-supplier-class-device-6dec4e04445a
Best regards,
--
Luca Ceresoli <luca.ceresoli@bootlin.com>
^ permalink raw reply related
* Re: [PATCH v5] backlight: led-backlight: add devlink to supplier LEDs
From: Luca Ceresoli @ 2025-05-19 20:15 UTC (permalink / raw)
To: Herve Codina
Cc: Lee Jones, Daniel Thompson, Jingoo Han, Helge Deller,
Tony Lindgren, Pavel Machek, Jean-Jacques Hiblot, Tomi Valkeinen,
Saravana Kannan, Thomas Petazzoni, Daniel Thompson, dri-devel,
linux-fbdev, linux-kernel, Alexander Sverdlin
In-Reply-To: <20250519174729.44fa1f7b@bootlin.com>
Hi Hervé,
On Mon, 19 May 2025 17:47:29 +0200
Herve Codina <herve.codina@bootlin.com> wrote:
> Hi Luca,
>
> On Mon, 19 May 2025 17:16:39 +0200
> Luca Ceresoli <luca.ceresoli@bootlin.com> wrote:
>
> ...
>
> > diff --git a/drivers/video/backlight/led_bl.c b/drivers/video/backlight/led_bl.c
> > index d2db157b2c290adc3a159023e9e2394fc877388c..8fe645b5b75447d009e1045dcf0c62d3bbc5425e 100644
> > --- a/drivers/video/backlight/led_bl.c
> > +++ b/drivers/video/backlight/led_bl.c
> > @@ -209,6 +209,19 @@ static int led_bl_probe(struct platform_device *pdev)
> > return PTR_ERR(priv->bl_dev);
> > }
> >
> > + for (i = 0; i < priv->nb_leds; i++) {
> > + struct device_link *link;
> > +
> > + link = device_link_add(&pdev->dev, priv->leds[0]->dev->parent,
>
> It should be priv->leds[i]->dev->parent instead of leds[0], shouldn't it?
Ah, well spotted, thanks!
My led-backlight device only uses one LED, so I hadn't noticed during
testing.
v6 on its way.
Luca
--
Luca Ceresoli, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
^ permalink raw reply
* Re: [PATCH v5] backlight: led-backlight: add devlink to supplier LEDs
From: Herve Codina @ 2025-05-19 15:47 UTC (permalink / raw)
To: Luca Ceresoli
Cc: Lee Jones, Daniel Thompson, Jingoo Han, Helge Deller,
Tony Lindgren, Pavel Machek, Jean-Jacques Hiblot, Tomi Valkeinen,
Saravana Kannan, Thomas Petazzoni, Daniel Thompson, dri-devel,
linux-fbdev, linux-kernel, Alexander Sverdlin
In-Reply-To: <20250519-led-backlight-add-devlink-to-supplier-class-device-v5-1-76d6fd4aeb2f@bootlin.com>
Hi Luca,
On Mon, 19 May 2025 17:16:39 +0200
Luca Ceresoli <luca.ceresoli@bootlin.com> wrote:
...
> diff --git a/drivers/video/backlight/led_bl.c b/drivers/video/backlight/led_bl.c
> index d2db157b2c290adc3a159023e9e2394fc877388c..8fe645b5b75447d009e1045dcf0c62d3bbc5425e 100644
> --- a/drivers/video/backlight/led_bl.c
> +++ b/drivers/video/backlight/led_bl.c
> @@ -209,6 +209,19 @@ static int led_bl_probe(struct platform_device *pdev)
> return PTR_ERR(priv->bl_dev);
> }
>
> + for (i = 0; i < priv->nb_leds; i++) {
> + struct device_link *link;
> +
> + link = device_link_add(&pdev->dev, priv->leds[0]->dev->parent,
It should be priv->leds[i]->dev->parent instead of leds[0], shouldn't it?
> + DL_FLAG_AUTOREMOVE_CONSUMER);
> + if (!link) {
> + dev_err(&pdev->dev, "Failed to add devlink (consumer %s, supplier %s)\n",
> + dev_name(&pdev->dev), dev_name(priv->leds[0]->dev->parent));
ditto
> + backlight_device_unregister(priv->bl_dev);
> + return -EINVAL;
> + }
> + }
> +
> for (i = 0; i < priv->nb_leds; i++) {
> mutex_lock(&priv->leds[i]->led_access);
> led_sysfs_disable(priv->leds[i]);
>
Best regards,
Hervé
^ permalink raw reply
* [PATCH v5] backlight: led-backlight: add devlink to supplier LEDs
From: Luca Ceresoli @ 2025-05-19 15:16 UTC (permalink / raw)
To: Lee Jones, Daniel Thompson, Jingoo Han, Helge Deller,
Tony Lindgren, Pavel Machek, Jean-Jacques Hiblot, Tomi Valkeinen
Cc: Saravana Kannan, Hervé Codina, Thomas Petazzoni,
Daniel Thompson, dri-devel, linux-fbdev, linux-kernel,
Alexander Sverdlin, Luca Ceresoli
led-backlight is a consumer of one or multiple LED class devices, but
devlink is currently unable to create correct supplier-producer links when
the supplier is a class device. One consequence is that removal order is
not correctly enforced.
Issues happen for example with the following sections in a device tree
overlay:
// An LED driver chip
pca9632@62 {
compatible = "nxp,pca9632";
reg = <0x62>;
// ...
addon_led_pwm: led-pwm@3 {
reg = <3>;
label = "addon:led:pwm";
};
};
backlight-addon {
compatible = "led-backlight";
leds = <&addon_led_pwm>;
brightness-levels = <255>;
default-brightness-level = <255>;
};
On removal of the above overlay, the LED driver can be removed before the
backlight device, resulting in:
Unable to handle kernel NULL pointer dereference at virtual address 0000000000000010
...
Call trace:
led_put+0xe0/0x140
devm_led_release+0x6c/0x98
Another way to reproduce the bug without any device tree overlays is
unbinding the LED class device (pca9632@62) before unbinding the consumer
(backlight-addon):
echo 11-0062 >/sys/bus/i2c/drivers/leds-pca963x/unbind
echo ...backlight-dock >/sys/bus/platform/drivers/led-backlight/unbind
Fix by adding a devlink between the consuming led-backlight device and the
supplying LED device, as other drivers and subsystems do as well.
Tested-by: Alexander Sverdlin <alexander.sverdlin@siemens.com>
Fixes: ae232e45acf9 ("backlight: add led-backlight driver")
Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
---
Changes in v5:
- separated this patch as a standalone patch
- improved commit message, adding feedback from Alexander
- no code changes
This patch first appeared in the v4 of a longer series, even though the
issue is orthogonal:
https://lore.kernel.org/all/20240917-hotplug-drm-bridge-v4-6-bc4dfee61be6@bootlin.com/
---
drivers/video/backlight/led_bl.c | 13 +++++++++++++
1 file changed, 13 insertions(+)
diff --git a/drivers/video/backlight/led_bl.c b/drivers/video/backlight/led_bl.c
index d2db157b2c290adc3a159023e9e2394fc877388c..8fe645b5b75447d009e1045dcf0c62d3bbc5425e 100644
--- a/drivers/video/backlight/led_bl.c
+++ b/drivers/video/backlight/led_bl.c
@@ -209,6 +209,19 @@ static int led_bl_probe(struct platform_device *pdev)
return PTR_ERR(priv->bl_dev);
}
+ for (i = 0; i < priv->nb_leds; i++) {
+ struct device_link *link;
+
+ link = device_link_add(&pdev->dev, priv->leds[0]->dev->parent,
+ DL_FLAG_AUTOREMOVE_CONSUMER);
+ if (!link) {
+ dev_err(&pdev->dev, "Failed to add devlink (consumer %s, supplier %s)\n",
+ dev_name(&pdev->dev), dev_name(priv->leds[0]->dev->parent));
+ backlight_device_unregister(priv->bl_dev);
+ return -EINVAL;
+ }
+ }
+
for (i = 0; i < priv->nb_leds; i++) {
mutex_lock(&priv->leds[i]->led_access);
led_sysfs_disable(priv->leds[i]);
---
base-commit: a5806cd506af5a7c19bcd596e4708b5c464bfd21
change-id: 20250519-led-backlight-add-devlink-to-supplier-class-device-6dec4e04445a
Best regards,
--
Luca Ceresoli <luca.ceresoli@bootlin.com>
^ permalink raw reply related
* Re: [PATCH v4 6/8] backlight: led-backlight: add devlink to supplier LEDs
From: Luca Ceresoli @ 2025-05-19 15:16 UTC (permalink / raw)
To: Daniel Thompson
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Andrzej Hajda,
Neil Armstrong, Robert Foss, Laurent Pinchart, Jonas Karlman,
Jernej Skrabec, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, David Airlie, Daniel Vetter, Derek Kiernan,
Dragan Cvetic, Arnd Bergmann, Greg Kroah-Hartman, Saravana Kannan,
Wolfram Sang, Rafael J. Wysocki, Lee Jones, Jingoo Han,
Helge Deller, Paul Kocialkowski, Hervé Codina,
Thomas Petazzoni, devicetree, linux-kernel, dri-devel, linux-i2c,
linux-fbdev, Paul Kocialkowski
In-Reply-To: <20240920144113.427606a7@booty>
Hello Daniel,
I wonder whether you remember about this conversation...
On Fri, 20 Sep 2024 14:41:13 +0200
Luca Ceresoli <luca.ceresoli@bootlin.com> wrote:
> Hello Daniel,
>
> On Thu, 19 Sep 2024 14:43:23 +0200
> Daniel Thompson <daniel.thompson@linaro.org> wrote:
>
> > On Tue, Sep 17, 2024 at 10:53:10AM +0200, Luca Ceresoli wrote:
> > > led-backlight is a consumer of one or multiple LED class devices, but no
> > > devlink is created for such supplier-producer relationship. One consequence
> > > is that removal ordered is not correctly enforced.
> > >
> > > Issues happen for example with the following sections in a device tree
> > > overlay:
> > >
> > > // An LED driver chip
> > > pca9632@62 {
> > > compatible = "nxp,pca9632";
> > > reg = <0x62>;
> > >
> > > // ...
> > >
> > > addon_led_pwm: led-pwm@3 {
> > > reg = <3>;
> > > label = "addon:led:pwm";
> > > };
> > > };
> > >
> > > backlight-addon {
> > > compatible = "led-backlight";
> > > leds = <&addon_led_pwm>;
> > > brightness-levels = <255>;
> > > default-brightness-level = <255>;
> > > };
> > >
> > > On removal of the above overlay, the LED driver can be removed before the
> > > backlight device, resulting in:
> > >
> > > Unable to handle kernel NULL pointer dereference at virtual address 0000000000000010
> > > ...
> > > Call trace:
> > > led_put+0xe0/0x140
> > > devm_led_release+0x6c/0x98
> >
> > This looks like the object became invalid whilst we were holding a reference
> > to it. Is that reasonable? Put another way, is using devlink here fixing a
> > bug or merely hiding one?
>
> Thanks for your comment.
>
> Hervé and I just had a look at the code and there actually might be a
> bug here, which we will be investigating (probably next week).
>
> Still I think the devlink needs to be added to describe the
> relationship between the supplier (LED) and consumer (backlight).
It took "slightly more" than "next week", but we are here finally. In
reality this topics went pretty much forgotten until Alexander
Sverdlin's feedback [0].
About your concern, I'm not totally sure devlink is the tool expected
to solve this issue, but if it isn't I don't know any other tool that
should.
In other words, because devlink is exactly meant to represent
supplier-consumer relationships and enforce them to be respected, it
seems the appropriate tool. Moreover devlink already handles such
relationships quite well in many cases, and takes care of removing
consumers before their suppliers, when suppliers get removed.
One missing piece in devlink is it doesn't (yet) handle class devices
correctly. When the supplier is a class device (such as the LED device
in this case), then devlink creates a link to the parent of the
supplier, and not the supplier itself.
This problem is well known and it is under Saravana's radar. Adding
such devlinks at the device core level would be of course be the best
and most generic solution, but it seems to be much more tricky that it
may look. So other drivers and subsystems are "manually" creating
devlinks, to have the right links in place until devlink can figure
them out automatically. Some examples ('git grep device_link_add' for
more):
https://elixir.bootlin.com/linux/v6.14.7/source/drivers/pwm/core.c#L1660
https://elixir.bootlin.com/linux/v6.14.7/source/drivers/iio/industrialio-backend.c#L710
https://elixir.bootlin.com/linux/v6.14.7/source/drivers/pmdomain/imx/gpc.c#L204
I hope this clarifies the need for this patch.
I am going to send this patch alone in a moment, detached from the
entire series because it is orthogonal.
[0]
https://lore.kernel.org/all/fa87471d31a62017067d4c3ba559cf79d6c3afec.camel@siemens.com/
Best regards,
Luca
--
Luca Ceresoli, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
^ permalink raw reply
* [PATCH] Documentation : fb : sstfb.rst : Fixed spelling mistake.
From: rujra @ 2025-05-19 14:38 UTC (permalink / raw)
To: deller, Jonathan Corbet; +Cc: linux-fbdev, dri-devel, linux-doc, linux-kernel
fixed document with spelling mistake
changes made :
1. "tweeks" to "tweaks"
Signed-off-by: Rujra Bhatt <braker.noob.kernel@gmail.com>
---
Documentation/fb/sstfb.rst | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/fb/sstfb.rst b/Documentation/fb/sstfb.rst
index 88d5a52b1..6cefa974a 100644
--- a/Documentation/fb/sstfb.rst
+++ b/Documentation/fb/sstfb.rst
@@ -192,7 +192,7 @@ Todo
- Get rid of the previous paragraph.
- Buy more coffee.
- test/port to other arch.
-- try to add panning using tweeks with front and back buffer .
+- try to add panning using tweaks with front and back buffer .
- try to implement accel on voodoo2, this board can actually do a
lot in 2D even if it was sold as a 3D only board ...
--
2.43.0
^ permalink raw reply related
* Re: [PATCH] dummycon: Trigger redraw when switching consoles with deferred takeover
From: Thomas Zimmermann @ 2025-05-19 9:12 UTC (permalink / raw)
To: Javier Martinez Canillas, gregkh, hdegoede, arvidjaar
Cc: dri-devel, linux-fbdev, linux-kernel, stable
In-Reply-To: <874ixhotss.fsf@minerva.mail-host-address-is-not-set>
Am 19.05.25 um 11:04 schrieb Javier Martinez Canillas:
> Thomas Zimmermann <tzimmermann@suse.de> writes:
>
> Hello Thomas,
>
>> Signal vt subsystem to redraw console when switching to dummycon
>> with deferred takeover enabled. Makes the console switch to fbcon
>> and displays the available output.
>>
>> With deferred takeover enabled, dummycon acts as the placeholder
>> until the first output to the console happens. At that point, fbcon
>> takes over. If the output happens while dummycon is not active, it
>> cannot inform fbcon. This is the case if the vt subsystem runs in
>> graphics mode.
>>
>> A typical graphical boot starts plymouth, a display manager and a
>> compositor; all while leaving out dummycon. Switching to a text-mode
>> console leaves the console with dummycon even if a getty terminal
>> has been started.
>>
>> Returning true from dummycon's con_switch helper signals the vt
>> subsystem to redraw the screen. If there's output available dummycon's
>> con_putc{s} helpers trigger deferred takeover of fbcon, which sets a
>> display mode and displays the output. If no output is available,
>> dummycon remains active.
>>
>> Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
>> Reported-by: Andrei Borzenkov <arvidjaar@gmail.com>
>> Closes: https://bugzilla.suse.com/show_bug.cgi?id=1242191
>> Tested-by: Andrei Borzenkov <arvidjaar@gmail.com>
>> Fixes: 83d83bebf401 ("console/fbcon: Add support for deferred console takeover")
>> Cc: Hans de Goede <hdegoede@redhat.com>
>> Cc: linux-fbdev@vger.kernel.org
>> Cc: dri-devel@lists.freedesktop.org
>> Cc: <stable@vger.kernel.org> # v4.19+
>> ---
>> drivers/video/console/dummycon.c | 15 ++++++++++-----
>> 1 file changed, 10 insertions(+), 5 deletions(-)
>>
>> diff --git a/drivers/video/console/dummycon.c b/drivers/video/console/dummycon.c
>> index 139049368fdc..afb8e4d2fc34 100644
>> --- a/drivers/video/console/dummycon.c
>> +++ b/drivers/video/console/dummycon.c
>> @@ -85,6 +85,12 @@ static bool dummycon_blank(struct vc_data *vc, enum vesa_blank_mode blank,
>> /* Redraw, so that we get putc(s) for output done while blanked */
>> return true;
>> }
>> +
>> +static bool dummycon_switch(struct vc_data *vc)
>> +{
>> + /* Redraw, so that we get putc(s) for output done while switched away */
> Maybe this comment could be a little bit more verbose about why this is needed
> for the framebuffer console deferred takeover case? It doesn't have to be as
> elaborated as how you have it in the commit message, but more information would
> be nice IMO.
I copied that from dummycon_blank(), as I assumed that the relevant
people know why. But yeah, I can elaborate a bit more. Best regards Thomas
>
>> + return true;
>> +}
> Acked-by: Javier Martinez Canillas <javierm@redhat.com>
>
--
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Frankenstrasse 146, 90461 Nuernberg, Germany
GF: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman
HRB 36809 (AG Nuernberg)
^ permalink raw reply
* Re: [PATCH] dummycon: Trigger redraw when switching consoles with deferred takeover
From: Javier Martinez Canillas @ 2025-05-19 9:04 UTC (permalink / raw)
To: Thomas Zimmermann, gregkh, hdegoede, arvidjaar
Cc: dri-devel, linux-fbdev, linux-kernel, Thomas Zimmermann, stable
In-Reply-To: <20250519071026.11133-1-tzimmermann@suse.de>
Thomas Zimmermann <tzimmermann@suse.de> writes:
Hello Thomas,
> Signal vt subsystem to redraw console when switching to dummycon
> with deferred takeover enabled. Makes the console switch to fbcon
> and displays the available output.
>
> With deferred takeover enabled, dummycon acts as the placeholder
> until the first output to the console happens. At that point, fbcon
> takes over. If the output happens while dummycon is not active, it
> cannot inform fbcon. This is the case if the vt subsystem runs in
> graphics mode.
>
> A typical graphical boot starts plymouth, a display manager and a
> compositor; all while leaving out dummycon. Switching to a text-mode
> console leaves the console with dummycon even if a getty terminal
> has been started.
>
> Returning true from dummycon's con_switch helper signals the vt
> subsystem to redraw the screen. If there's output available dummycon's
> con_putc{s} helpers trigger deferred takeover of fbcon, which sets a
> display mode and displays the output. If no output is available,
> dummycon remains active.
>
> Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
> Reported-by: Andrei Borzenkov <arvidjaar@gmail.com>
> Closes: https://bugzilla.suse.com/show_bug.cgi?id=1242191
> Tested-by: Andrei Borzenkov <arvidjaar@gmail.com>
> Fixes: 83d83bebf401 ("console/fbcon: Add support for deferred console takeover")
> Cc: Hans de Goede <hdegoede@redhat.com>
> Cc: linux-fbdev@vger.kernel.org
> Cc: dri-devel@lists.freedesktop.org
> Cc: <stable@vger.kernel.org> # v4.19+
> ---
> drivers/video/console/dummycon.c | 15 ++++++++++-----
> 1 file changed, 10 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/video/console/dummycon.c b/drivers/video/console/dummycon.c
> index 139049368fdc..afb8e4d2fc34 100644
> --- a/drivers/video/console/dummycon.c
> +++ b/drivers/video/console/dummycon.c
> @@ -85,6 +85,12 @@ static bool dummycon_blank(struct vc_data *vc, enum vesa_blank_mode blank,
> /* Redraw, so that we get putc(s) for output done while blanked */
> return true;
> }
> +
> +static bool dummycon_switch(struct vc_data *vc)
> +{
> + /* Redraw, so that we get putc(s) for output done while switched away */
Maybe this comment could be a little bit more verbose about why this is needed
for the framebuffer console deferred takeover case? It doesn't have to be as
elaborated as how you have it in the commit message, but more information would
be nice IMO.
> + return true;
> +}
Acked-by: Javier Martinez Canillas <javierm@redhat.com>
--
Best regards,
Javier Martinez Canillas
Core Platforms
Red Hat
^ permalink raw reply
* [PATCH] dummycon: Trigger redraw when switching consoles with deferred takeover
From: Thomas Zimmermann @ 2025-05-19 7:10 UTC (permalink / raw)
To: gregkh, hdegoede, arvidjaar
Cc: dri-devel, linux-fbdev, linux-kernel, Thomas Zimmermann, stable
Signal vt subsystem to redraw console when switching to dummycon
with deferred takeover enabled. Makes the console switch to fbcon
and displays the available output.
With deferred takeover enabled, dummycon acts as the placeholder
until the first output to the console happens. At that point, fbcon
takes over. If the output happens while dummycon is not active, it
cannot inform fbcon. This is the case if the vt subsystem runs in
graphics mode.
A typical graphical boot starts plymouth, a display manager and a
compositor; all while leaving out dummycon. Switching to a text-mode
console leaves the console with dummycon even if a getty terminal
has been started.
Returning true from dummycon's con_switch helper signals the vt
subsystem to redraw the screen. If there's output available dummycon's
con_putc{s} helpers trigger deferred takeover of fbcon, which sets a
display mode and displays the output. If no output is available,
dummycon remains active.
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Reported-by: Andrei Borzenkov <arvidjaar@gmail.com>
Closes: https://bugzilla.suse.com/show_bug.cgi?id=1242191
Tested-by: Andrei Borzenkov <arvidjaar@gmail.com>
Fixes: 83d83bebf401 ("console/fbcon: Add support for deferred console takeover")
Cc: Hans de Goede <hdegoede@redhat.com>
Cc: linux-fbdev@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
Cc: <stable@vger.kernel.org> # v4.19+
---
drivers/video/console/dummycon.c | 15 ++++++++++-----
1 file changed, 10 insertions(+), 5 deletions(-)
diff --git a/drivers/video/console/dummycon.c b/drivers/video/console/dummycon.c
index 139049368fdc..afb8e4d2fc34 100644
--- a/drivers/video/console/dummycon.c
+++ b/drivers/video/console/dummycon.c
@@ -85,6 +85,12 @@ static bool dummycon_blank(struct vc_data *vc, enum vesa_blank_mode blank,
/* Redraw, so that we get putc(s) for output done while blanked */
return true;
}
+
+static bool dummycon_switch(struct vc_data *vc)
+{
+ /* Redraw, so that we get putc(s) for output done while switched away */
+ return true;
+}
#else
static void dummycon_putc(struct vc_data *vc, u16 c, unsigned int y,
unsigned int x) { }
@@ -95,6 +101,10 @@ static bool dummycon_blank(struct vc_data *vc, enum vesa_blank_mode blank,
{
return false;
}
+static bool dummycon_switch(struct vc_data *vc)
+{
+ return false;
+}
#endif
static const char *dummycon_startup(void)
@@ -124,11 +134,6 @@ static bool dummycon_scroll(struct vc_data *vc, unsigned int top,
return false;
}
-static bool dummycon_switch(struct vc_data *vc)
-{
- return false;
-}
-
/*
* The console `switch' structure for the dummy console
*
--
2.49.0
^ permalink raw reply related
* [PATCH 9/9] staging: sm750fb: rename `hw_sm750le_setBLANK`
From: Eric Florin @ 2025-05-19 2:04 UTC (permalink / raw)
To: teddy.wang
Cc: sudipm.mukherjee, gregkh, linux-fbdev, linux-staging,
linux-kernel, Eric Florin
In-Reply-To: <cover.1747619816.git.ericflorin@google.com>
Rename `hw_sm750le_setBLANK` to `hw_sm750le_set_blank` to conform with
kernel style guidelines as reported by checkpatch.pl
CHECK: Avoid CamelCase: <hw_sm750le_setBLANK>
Signed-off-by: Eric Florin <ericflorin@google.com>
---
drivers/staging/sm750fb/sm750.c | 2 +-
drivers/staging/sm750fb/sm750.h | 2 +-
drivers/staging/sm750fb/sm750_hw.c | 2 +-
3 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/staging/sm750fb/sm750.c b/drivers/staging/sm750fb/sm750.c
index eb7e107bae68..1d929aca399c 100644
--- a/drivers/staging/sm750fb/sm750.c
+++ b/drivers/staging/sm750fb/sm750.c
@@ -606,7 +606,7 @@ static int sm750fb_set_drv(struct lynxfb_par *par)
crtc->ywrapstep = 0;
output->proc_setBLANK = (sm750_dev->revid == SM750LE_REVISION_ID) ?
- hw_sm750le_setBLANK : hw_sm750_set_blank;
+ hw_sm750le_set_blank : hw_sm750_set_blank;
/* chip specific phase */
sm750_dev->accel.de_wait = (sm750_dev->revid == SM750LE_REVISION_ID) ?
hw_sm750le_de_wait : hw_sm750_de_wait;
diff --git a/drivers/staging/sm750fb/sm750.h b/drivers/staging/sm750fb/sm750.h
index 97682cb8c58f..9cf8b3d30aac 100644
--- a/drivers/staging/sm750fb/sm750.h
+++ b/drivers/staging/sm750fb/sm750.h
@@ -212,7 +212,7 @@ int hw_sm750_set_col_reg(struct lynxfb_crtc *crtc, ushort index,
ushort red, ushort green, ushort blue);
int hw_sm750_set_blank(struct lynxfb_output *output, int blank);
-int hw_sm750le_setBLANK(struct lynxfb_output *output, int blank);
+int hw_sm750le_set_blank(struct lynxfb_output *output, int blank);
int hw_sm750_pan_display(struct lynxfb_crtc *crtc,
const struct fb_var_screeninfo *var,
const struct fb_info *info);
diff --git a/drivers/staging/sm750fb/sm750_hw.c b/drivers/staging/sm750fb/sm750_hw.c
index c64807cd06b3..7119b67efe11 100644
--- a/drivers/staging/sm750fb/sm750_hw.c
+++ b/drivers/staging/sm750fb/sm750_hw.c
@@ -380,7 +380,7 @@ int hw_sm750_set_col_reg(struct lynxfb_crtc *crtc, ushort index, ushort red,
return 0;
}
-int hw_sm750le_setBLANK(struct lynxfb_output *output, int blank)
+int hw_sm750le_set_blank(struct lynxfb_output *output, int blank)
{
int dpms, crtdb;
--
2.49.0.1112.g889b7c5bd8-goog
^ permalink raw reply related
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