* [PATCH v2] fbcon: Use static attribute groups for sysfs entries
From: oushixiong1025 @ 2025-03-14 6:09 UTC (permalink / raw)
To: Simona Vetter
Cc: Helge Deller, Thomas Zimmermann, Samuel Thibault, Zsolt Kajtar,
Thomas Weißschuh, linux-fbdev, dri-devel, linux-kernel,
Shixiong Ou
From: Shixiong Ou <oushixiong@kylinos.cn>
Using device_create_with_groups() to simplify creation and removal.
Same as commit 1083a7be4504 ("tty: Use static attribute groups for
sysfs entries").
Signed-off-by: Shixiong Ou <oushixiong@kylinos.cn>
---
drivers/video/fbdev/core/fbcon.c | 69 +++++++++-----------------------
1 file changed, 19 insertions(+), 50 deletions(-)
diff --git a/drivers/video/fbdev/core/fbcon.c b/drivers/video/fbdev/core/fbcon.c
index 07d127110ca4..1d792bd11063 100644
--- a/drivers/video/fbdev/core/fbcon.c
+++ b/drivers/video/fbdev/core/fbcon.c
@@ -160,7 +160,6 @@ static int info_idx = -1;
/* console rotation */
static int initial_rotation = -1;
-static int fbcon_has_sysfs;
static int margin_color;
static const struct consw fb_con;
@@ -3159,7 +3158,7 @@ static const struct consw fb_con = {
.con_debug_leave = fbcon_debug_leave,
};
-static ssize_t store_rotate(struct device *device,
+static ssize_t rotate_store(struct device *device,
struct device_attribute *attr, const char *buf,
size_t count)
{
@@ -3181,7 +3180,7 @@ static ssize_t store_rotate(struct device *device,
return count;
}
-static ssize_t store_rotate_all(struct device *device,
+static ssize_t rotate_all_store(struct device *device,
struct device_attribute *attr,const char *buf,
size_t count)
{
@@ -3203,7 +3202,7 @@ static ssize_t store_rotate_all(struct device *device,
return count;
}
-static ssize_t show_rotate(struct device *device,
+static ssize_t rotate_show(struct device *device,
struct device_attribute *attr,char *buf)
{
struct fb_info *info;
@@ -3222,7 +3221,7 @@ static ssize_t show_rotate(struct device *device,
return sysfs_emit(buf, "%d\n", rotate);
}
-static ssize_t show_cursor_blink(struct device *device,
+static ssize_t cursor_blink_show(struct device *device,
struct device_attribute *attr, char *buf)
{
struct fb_info *info;
@@ -3247,7 +3246,7 @@ static ssize_t show_cursor_blink(struct device *device,
return sysfs_emit(buf, "%d\n", blink);
}
-static ssize_t store_cursor_blink(struct device *device,
+static ssize_t cursor_blink_store(struct device *device,
struct device_attribute *attr,
const char *buf, size_t count)
{
@@ -3281,35 +3280,18 @@ static ssize_t store_cursor_blink(struct device *device,
return count;
}
-static struct device_attribute device_attrs[] = {
- __ATTR(rotate, S_IRUGO|S_IWUSR, show_rotate, store_rotate),
- __ATTR(rotate_all, S_IWUSR, NULL, store_rotate_all),
- __ATTR(cursor_blink, S_IRUGO|S_IWUSR, show_cursor_blink,
- store_cursor_blink),
-};
-
-static int fbcon_init_device(void)
-{
- int i, error = 0;
+static DEVICE_ATTR_RW(rotate);
+static DEVICE_ATTR_WO(rotate_all);
+static DEVICE_ATTR_RW(cursor_blink);
- fbcon_has_sysfs = 1;
-
- for (i = 0; i < ARRAY_SIZE(device_attrs); i++) {
- error = device_create_file(fbcon_device, &device_attrs[i]);
-
- if (error)
- break;
- }
-
- if (error) {
- while (--i >= 0)
- device_remove_file(fbcon_device, &device_attrs[i]);
-
- fbcon_has_sysfs = 0;
- }
+static struct attribute *fbcon_device_attrs[] = {
+ &dev_attr_rotate.attr,
+ &dev_attr_rotate_all.attr,
+ &dev_attr_cursor_blink.attr,
+ NULL
+};
- return 0;
-}
+ATTRIBUTE_GROUPS(fbcon_device);
#ifdef CONFIG_FRAMEBUFFER_CONSOLE_DEFERRED_TAKEOVER
static void fbcon_register_existing_fbs(struct work_struct *work)
@@ -3367,16 +3349,16 @@ void __init fb_console_init(void)
int i;
console_lock();
- fbcon_device = device_create(fb_class, NULL, MKDEV(0, 0), NULL,
- "fbcon");
+ fbcon_device = device_create_with_groups(fb_class, NULL,
+ MKDEV(0, 0), NULL,
+ fbcon_device_groups, "fbcon");
if (IS_ERR(fbcon_device)) {
printk(KERN_WARNING "Unable to create device "
"for fbcon; errno = %ld\n",
PTR_ERR(fbcon_device));
fbcon_device = NULL;
- } else
- fbcon_init_device();
+ }
for (i = 0; i < MAX_NR_CONSOLES; i++)
con2fb_map[i] = -1;
@@ -3387,18 +3369,6 @@ void __init fb_console_init(void)
#ifdef MODULE
-static void __exit fbcon_deinit_device(void)
-{
- int i;
-
- if (fbcon_has_sysfs) {
- for (i = 0; i < ARRAY_SIZE(device_attrs); i++)
- device_remove_file(fbcon_device, &device_attrs[i]);
-
- fbcon_has_sysfs = 0;
- }
-}
-
void __exit fb_console_exit(void)
{
#ifdef CONFIG_FRAMEBUFFER_CONSOLE_DEFERRED_TAKEOVER
@@ -3411,7 +3381,6 @@ void __exit fb_console_exit(void)
#endif
console_lock();
- fbcon_deinit_device();
device_destroy(fb_class, MKDEV(0, 0));
do_unregister_con_driver(&fb_con);
--
2.25.1
^ permalink raw reply related
* Re: [PATCH v2] fbcon: Use static attribute groups for sysfs entries
From: Thomas Zimmermann @ 2025-03-14 8:16 UTC (permalink / raw)
To: oushixiong1025, Simona Vetter
Cc: Helge Deller, Samuel Thibault, Zsolt Kajtar,
Thomas Weißschuh, linux-fbdev, dri-devel, linux-kernel,
Shixiong Ou
In-Reply-To: <20250314060941.160048-1-oushixiong1025@163.com>
Hi
Am 14.03.25 um 07:09 schrieb oushixiong1025@163.com:
> From: Shixiong Ou <oushixiong@kylinos.cn>
>
> Using device_create_with_groups() to simplify creation and removal.
> Same as commit 1083a7be4504 ("tty: Use static attribute groups for
> sysfs entries").
>
> Signed-off-by: Shixiong Ou <oushixiong@kylinos.cn>
Acked-by: Thomas Zimmermann <tzimmermann@suse.de>
with minor comments below
> ---
> drivers/video/fbdev/core/fbcon.c | 69 +++++++++-----------------------
> 1 file changed, 19 insertions(+), 50 deletions(-)
>
> diff --git a/drivers/video/fbdev/core/fbcon.c b/drivers/video/fbdev/core/fbcon.c
> index 07d127110ca4..1d792bd11063 100644
> --- a/drivers/video/fbdev/core/fbcon.c
> +++ b/drivers/video/fbdev/core/fbcon.c
> @@ -160,7 +160,6 @@ static int info_idx = -1;
>
> /* console rotation */
> static int initial_rotation = -1;
> -static int fbcon_has_sysfs;
> static int margin_color;
>
> static const struct consw fb_con;
> @@ -3159,7 +3158,7 @@ static const struct consw fb_con = {
> .con_debug_leave = fbcon_debug_leave,
> };
>
> -static ssize_t store_rotate(struct device *device,
> +static ssize_t rotate_store(struct device *device,
> struct device_attribute *attr, const char *buf,
> size_t count)
> {
> @@ -3181,7 +3180,7 @@ static ssize_t store_rotate(struct device *device,
> return count;
> }
>
> -static ssize_t store_rotate_all(struct device *device,
> +static ssize_t rotate_all_store(struct device *device,
> struct device_attribute *attr,const char *buf,
> size_t count)
> {
> @@ -3203,7 +3202,7 @@ static ssize_t store_rotate_all(struct device *device,
> return count;
> }
>
> -static ssize_t show_rotate(struct device *device,
> +static ssize_t rotate_show(struct device *device,
> struct device_attribute *attr,char *buf)
> {
> struct fb_info *info;
> @@ -3222,7 +3221,7 @@ static ssize_t show_rotate(struct device *device,
> return sysfs_emit(buf, "%d\n", rotate);
> }
>
> -static ssize_t show_cursor_blink(struct device *device,
> +static ssize_t cursor_blink_show(struct device *device,
> struct device_attribute *attr, char *buf)
> {
> struct fb_info *info;
> @@ -3247,7 +3246,7 @@ static ssize_t show_cursor_blink(struct device *device,
> return sysfs_emit(buf, "%d\n", blink);
> }
>
> -static ssize_t store_cursor_blink(struct device *device,
> +static ssize_t cursor_blink_store(struct device *device,
> struct device_attribute *attr,
> const char *buf, size_t count)
> {
> @@ -3281,35 +3280,18 @@ static ssize_t store_cursor_blink(struct device *device,
> return count;
> }
>
> -static struct device_attribute device_attrs[] = {
> - __ATTR(rotate, S_IRUGO|S_IWUSR, show_rotate, store_rotate),
> - __ATTR(rotate_all, S_IWUSR, NULL, store_rotate_all),
> - __ATTR(cursor_blink, S_IRUGO|S_IWUSR, show_cursor_blink,
> - store_cursor_blink),
> -};
> -
> -static int fbcon_init_device(void)
> -{
> - int i, error = 0;
> +static DEVICE_ATTR_RW(rotate);
> +static DEVICE_ATTR_WO(rotate_all);
> +static DEVICE_ATTR_RW(cursor_blink);
Since you're changing it anyway, could you please sort these attributes
alphabetically. So cursor blink should go first. It's easier to read then.
>
> - fbcon_has_sysfs = 1;
> -
> - for (i = 0; i < ARRAY_SIZE(device_attrs); i++) {
> - error = device_create_file(fbcon_device, &device_attrs[i]);
> -
> - if (error)
> - break;
> - }
> -
> - if (error) {
> - while (--i >= 0)
> - device_remove_file(fbcon_device, &device_attrs[i]);
> -
> - fbcon_has_sysfs = 0;
> - }
> +static struct attribute *fbcon_device_attrs[] = {
> + &dev_attr_rotate.attr,
> + &dev_attr_rotate_all.attr,
> + &dev_attr_cursor_blink.attr,
> + NULL
Alphabetical sorting here as well.
Best regards
Thomas
> +};
>
> - return 0;
> -}
> +ATTRIBUTE_GROUPS(fbcon_device);
>
> #ifdef CONFIG_FRAMEBUFFER_CONSOLE_DEFERRED_TAKEOVER
> static void fbcon_register_existing_fbs(struct work_struct *work)
> @@ -3367,16 +3349,16 @@ void __init fb_console_init(void)
> int i;
>
> console_lock();
> - fbcon_device = device_create(fb_class, NULL, MKDEV(0, 0), NULL,
> - "fbcon");
> + fbcon_device = device_create_with_groups(fb_class, NULL,
> + MKDEV(0, 0), NULL,
> + fbcon_device_groups, "fbcon");
>
> if (IS_ERR(fbcon_device)) {
> printk(KERN_WARNING "Unable to create device "
> "for fbcon; errno = %ld\n",
> PTR_ERR(fbcon_device));
> fbcon_device = NULL;
> - } else
> - fbcon_init_device();
> + }
>
> for (i = 0; i < MAX_NR_CONSOLES; i++)
> con2fb_map[i] = -1;
> @@ -3387,18 +3369,6 @@ void __init fb_console_init(void)
>
> #ifdef MODULE
>
> -static void __exit fbcon_deinit_device(void)
> -{
> - int i;
> -
> - if (fbcon_has_sysfs) {
> - for (i = 0; i < ARRAY_SIZE(device_attrs); i++)
> - device_remove_file(fbcon_device, &device_attrs[i]);
> -
> - fbcon_has_sysfs = 0;
> - }
> -}
> -
> void __exit fb_console_exit(void)
> {
> #ifdef CONFIG_FRAMEBUFFER_CONSOLE_DEFERRED_TAKEOVER
> @@ -3411,7 +3381,6 @@ void __exit fb_console_exit(void)
> #endif
>
> console_lock();
> - fbcon_deinit_device();
> device_destroy(fb_class, MKDEV(0, 0));
>
> do_unregister_con_driver(&fb_con);
--
--
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 v3 00/11] backlight, lcd, led: Remove fbdev dependencies
From: Simona Vetter @ 2025-03-14 8:39 UTC (permalink / raw)
To: Lee Jones
Cc: Thomas Zimmermann, pavel, danielt, jingoohan1, deller, simona,
linux-leds, dri-devel, linux-fbdev
In-Reply-To: <20250313165151.GE3645863@google.com>
On Thu, Mar 13, 2025 at 04:51:51PM +0000, Lee Jones wrote:
> On Thu, 06 Mar 2025, Thomas Zimmermann wrote:
>
> > This series removes the remaining dependencies on fbdev from the
> > backlight, lcd and led subsystems. Each depends on fbdev events to
> > track display state. Make fbdev inform each subsystem via a dedicated
> > interface instead.
> >
> > Patches 1 to 3 make fbdev track blank state for each display, so that
> > backlight code doesn't have to.
> >
> > Patches 4 to 6 remove fbdev event handling from backlight code. Patches
> > 7 and 8 remove fbdev event handling from lcd code and patches 9 and 10
> > do the same for led's backlight trigger.
> >
> > The final patch removes the event constants from fbdev.
> >
> > With the series applied, the three subsystems do no longer depend on
> > fbdev. It's also a clean up for fbdev. Fbdev used to send out a large
> > number of events. That mechanism has been deprecated for some time and
> > converted call to dedicated functions instead.
> >
> > Testing is very welcome, as I don't have the hardware to test this
> > series.
> >
> > v3:
> > - export several symbols
> > - static-inline declare empty placeholders
> > v2:
> > - avoid IS_REACHABLE() in source file (Lee)
> > - simplify several interfaces and helpers
> > - use lock guards
> > - initialize global lists and mutices
> >
> > Thomas Zimmermann (11):
> > fbdev: Rework fb_blank()
> > fbdev: Track display blanking state
> > fbdev: Send old blank state in FB_EVENT_BLANK
> > backlight: Implement fbdev tracking with blank state from event
> > backlight: Move blank-state handling into helper
> > backlight: Replace fb events with a dedicated function call
> > backlight: lcd: Move event handling into helpers
> > backlight: lcd: Replace fb events with a dedicated function call
> > leds: backlight trigger: Move blank-state handling into helper
> > leds: backlight trigger: Replace fb events with a dedicated function
> > call
> > fbdev: Remove constants of unused events
> >
> > drivers/leds/trigger/ledtrig-backlight.c | 48 +++++-----
> > drivers/video/backlight/backlight.c | 93 +++++--------------
> > drivers/video/backlight/lcd.c | 108 +++++++++--------------
> > drivers/video/fbdev/core/fb_backlight.c | 12 +++
> > drivers/video/fbdev/core/fb_info.c | 1 +
> > drivers/video/fbdev/core/fbmem.c | 82 ++++++++++++++---
> > drivers/video/fbdev/core/fbsysfs.c | 8 +-
> > include/linux/backlight.h | 22 ++---
> > include/linux/fb.h | 12 +--
> > include/linux/lcd.h | 21 ++++-
> > include/linux/leds.h | 6 ++
> > 11 files changed, 205 insertions(+), 208 deletions(-)
>
> No immediately obvious issues from the LEDs side.
>
> Still needs reviews from Backlight and fbdev.
I looked throught the series and it's a small step, but I think it's the
right direction for where we want backlight/fbdev/drm-kms to head towards
long-term. So on the series:
Acked-by: Simona Vetter <simona.vetter@ffwll.ch>
Cheers, Sima
>
> --
> Lee Jones [李琼斯]
--
Simona Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
^ permalink raw reply
* Re: [PATCH 4/9] mfd: pcF50633-gpio: Remove
From: Linus Walleij @ 2025-03-14 10:28 UTC (permalink / raw)
To: linux
Cc: arnd, lee, dmitry.torokhov, sre, lgirdwood, broonie,
alexandre.belloni, danielt, jingoohan1, deller, brgl, tsbogend,
linux-mips, linux-input, linux-pm, linux-rtc, dri-devel,
linux-fbdev, linux-gpio, linux-kernel
In-Reply-To: <20250309193612.251929-5-linux@treblig.org>
On Sun, Mar 9, 2025 at 8:36 PM <linux@treblig.org> wrote:
> From: "Dr. David Alan Gilbert" <linux@treblig.org>
>
> The pcf50633 was used as part of the OpenMoko devices but
> the support for its main chip was recently removed in:
> commit 61b7f8920b17 ("ARM: s3c: remove all s3c24xx support")
>
> See https://lore.kernel.org/all/Z8z236h4B5A6Ki3D@gallifrey/
>
> Remove it.
>
> Signed-off-by: Dr. David Alan Gilbert <linux@treblig.org>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Yours,
Linus Walleij
^ permalink raw reply
* Re: (subset) [PATCH] backlight: tdo24m: Eliminate redundant whitespace
From: Lee Jones @ 2025-03-14 10:54 UTC (permalink / raw)
To: lee, danielt, jingoohan1, deller, WangYuli
Cc: dri-devel, linux-fbdev, linux-kernel, zhanjun, niecheng1,
guanwentao, chenlinxuan
In-Reply-To: <8FC39A4DC2529591+20250310045636.14329-1-wangyuli@uniontech.com>
On Mon, 10 Mar 2025 12:56:36 +0800, WangYuli wrote:
> The description for CONFIG_LCD_TDO24M has redundant whitespace.
> Trim it to keep the code tidy.
>
>
Applied, thanks!
[1/1] backlight: tdo24m: Eliminate redundant whitespace
commit: c9fe785857fdfc780d49b60b5bb77ca21a51411b
--
Lee Jones [李琼斯]
^ permalink raw reply
* Re: (subset) [PATCH v2 7/9] backlight: pcf50633-backlight: Remove
From: Lee Jones @ 2025-03-14 11:36 UTC (permalink / raw)
To: arnd, lee, dmitry.torokhov, sre, lgirdwood, broonie,
alexandre.belloni, danielt, jingoohan1, deller, linus.walleij,
brgl, tsbogend, linux
Cc: linux-mips, linux-input, linux-pm, linux-rtc, dri-devel,
linux-fbdev, linux-gpio, linux-kernel
In-Reply-To: <20250311014959.743322-8-linux@treblig.org>
On Tue, 11 Mar 2025 01:49:57 +0000, linux@treblig.org wrote:
> The pcf50633 was used as part of the OpenMoko devices but
> the support for its main chip was recently removed in:
> commit 61b7f8920b17 ("ARM: s3c: remove all s3c24xx support")
>
> See https://lore.kernel.org/all/Z8z236h4B5A6Ki3D@gallifrey/
>
> Remove it.
>
> [...]
Applied, thanks!
[7/9] backlight: pcf50633-backlight: Remove
commit: dfc034a0494b8fb8ea881aeb41a0c4e2619ff1e4
--
Lee Jones [李琼斯]
^ permalink raw reply
* Re: (subset) [PATCH v2 0/9] Remove pcf50633
From: Lee Jones @ 2025-03-14 11:43 UTC (permalink / raw)
To: arnd, lee, dmitry.torokhov, sre, lgirdwood, broonie,
alexandre.belloni, danielt, jingoohan1, deller, linus.walleij,
brgl, tsbogend, linux
Cc: linux-mips, linux-input, linux-pm, linux-rtc, dri-devel,
linux-fbdev, linux-gpio, linux-kernel
In-Reply-To: <20250311014959.743322-1-linux@treblig.org>
On Tue, 11 Mar 2025 01:49:50 +0000, linux@treblig.org wrote:
> From: "Dr. David Alan Gilbert" <linux@treblig.org>
>
> The pcf50633 was used as part of the OpenMoko devices but
> the support for its main chip was recently removed in:
> commit 61b7f8920b17 ("ARM: s3c: remove all s3c24xx support")
>
> See https://lore.kernel.org/all/Z8z236h4B5A6Ki3D@gallifrey/
>
> [...]
Applied, thanks!
[1/9] mfd: pcf50633-adc: Remove
commit: 0d0e54953805af76f0022df39602f5668145f747
[3/9] mfd: pcF50633-gpio: Remove
commit: 8559602247d0d054451c7a755942588d2c0de85d
[8/9] mfd: pcf50633: Remove irq code
commit: 786ad21f4350601c9d118ddbd19b7b830c04ece6
[9/9] mfd: pcf50633: Remove remains
commit: 44356090d59efd8db152e9eecb8e7f843be319f0
--
Lee Jones [李琼斯]
^ permalink raw reply
* [PATCH v2] staging: sm750fb: Remove unused enum dpms
From: Gabriel Lima Luz @ 2025-03-14 17:31 UTC (permalink / raw)
To: linux-fbdev, linux-staging, linux-kernel, Sudip Mukherjee,
Teddy Wang, Greg Kroah-Hartman, ~lkcamp/patches
remove unused enum and replace its usage with
a unsigned int.
add comment to ddk750_set_dpms function for
documenting state values
Signed-off-by: Gabriel Lima Luz <lima.gabriel.luz@gmail.com>
---
drivers/staging/sm750fb/ddk750_power.c | 10 ++++++++--
drivers/staging/sm750fb/ddk750_power.h | 9 +--------
2 files changed, 9 insertions(+), 10 deletions(-)
diff --git a/drivers/staging/sm750fb/ddk750_power.c b/drivers/staging/sm750fb/ddk750_power.c
index 12834f78eef7..547a96ccba9b 100644
--- a/drivers/staging/sm750fb/ddk750_power.c
+++ b/drivers/staging/sm750fb/ddk750_power.c
@@ -3,8 +3,14 @@
#include "ddk750_reg.h"
#include "ddk750_power.h"
-void ddk750_set_dpms(enum dpms state)
-{
+void ddk750_set_dpms(unsigned int state)
+{ /*
+ * state values documentation
+ * crt_DPMS_ON = 0x0,
+ * crt_DPMS_STANDBY = 0x1,
+ * crt_DPMS_SUSPEND = 0x2,
+ * crt_DPMS_OFF = 0x3, unsigned int value;
+ */
unsigned int value;
if (sm750_get_chip_type() == SM750LE) {
diff --git a/drivers/staging/sm750fb/ddk750_power.h b/drivers/staging/sm750fb/ddk750_power.h
index 63c9e8b6ffb3..93dafdde3699 100644
--- a/drivers/staging/sm750fb/ddk750_power.h
+++ b/drivers/staging/sm750fb/ddk750_power.h
@@ -2,19 +2,12 @@
#ifndef DDK750_POWER_H__
#define DDK750_POWER_H__
-enum dpms {
- crtDPMS_ON = 0x0,
- crtDPMS_STANDBY = 0x1,
- crtDPMS_SUSPEND = 0x2,
- crtDPMS_OFF = 0x3,
-};
-
#define set_DAC(off) { \
poke32(MISC_CTRL, \
(peek32(MISC_CTRL) & ~MISC_CTRL_DAC_POWER_OFF) | (off)); \
}
-void ddk750_set_dpms(enum dpms state);
+void ddk750_set_dpms(unsigned int state);
void sm750_set_power_mode(unsigned int mode);
void sm750_set_current_gate(unsigned int gate);
--
2.43.0
^ permalink raw reply related
* Go on a covert date with women!💕View My Group💕 - Mar 16, 2025
From: Mary Susan (via Looker Studio) @ 2025-03-17 1:06 UTC (permalink / raw)
To: linux-fbdev
[-- Attachment #1.1.1: Type: text/plain, Size: 1182 bytes --]
Google Looker Studio
View the interactive report: Laporan Tanpa Judul
🎉 Congratulations! You're Invited to Join Our Exclusive Adult
Community! 🎉 Your invitation Link >> https://onlyforfwb.us/fwb4u We are
thrilled to extend a special invitation to you! This is not just any
community; it's a place where like-minded individuals come together to
share ideas, inspire each other, and build lasting connections. You Can
Find Here Local Girls/Women Nearby ,You can Chat nearby Girls $ For Hook-up
>>> https://onlyforfwb.us/fwb4u Join Cam Show & Many More (Its Totally Free
No need to required CC $ personal Information)
© 2025 Google LLC 1600 Amphitheatre Parkway, Mountain View, CA 94043
You received this email because someone scheduled it to be sent to you
regularly. You can unsubscribe from this scheduled email here.
This email and its content are subject to the Looker Studio Terms of
Service you have agreed to. If you have not agreed to the Looker Studio
Terms of Service, the Google Terms of Service shall apply. This email and
its content are also subject to the Google Privacy Policy.
[-- Attachment #1.1.2: Type: text/html, Size: 16266 bytes --]
[-- Attachment #1.2: Report_a942032d-4ba7-498c-85c1-468905b0c01c_page_eGZCF.jpg --]
[-- Type: image/jpeg, Size: 7170 bytes --]
[-- Attachment #2: Laporan_Tanpa_Judul.pdf --]
[-- Type: application/pdf, Size: 291407 bytes --]
^ permalink raw reply
* Re: [PATCH v3 00/11] backlight, lcd, led: Remove fbdev dependencies
From: Thomas Zimmermann @ 2025-03-17 8:42 UTC (permalink / raw)
To: Lee Jones
Cc: pavel, danielt, jingoohan1, deller, simona, linux-leds, dri-devel,
linux-fbdev
In-Reply-To: <20250313165151.GE3645863@google.com>
Hi
Am 13.03.25 um 17:51 schrieb Lee Jones:
> On Thu, 06 Mar 2025, Thomas Zimmermann wrote:
>
>> This series removes the remaining dependencies on fbdev from the
>> backlight, lcd and led subsystems. Each depends on fbdev events to
>> track display state. Make fbdev inform each subsystem via a dedicated
>> interface instead.
>>
>> Patches 1 to 3 make fbdev track blank state for each display, so that
>> backlight code doesn't have to.
>>
>> Patches 4 to 6 remove fbdev event handling from backlight code. Patches
>> 7 and 8 remove fbdev event handling from lcd code and patches 9 and 10
>> do the same for led's backlight trigger.
>>
>> The final patch removes the event constants from fbdev.
>>
>> With the series applied, the three subsystems do no longer depend on
>> fbdev. It's also a clean up for fbdev. Fbdev used to send out a large
>> number of events. That mechanism has been deprecated for some time and
>> converted call to dedicated functions instead.
>>
>> Testing is very welcome, as I don't have the hardware to test this
>> series.
>>
>> v3:
>> - export several symbols
>> - static-inline declare empty placeholders
>> v2:
>> - avoid IS_REACHABLE() in source file (Lee)
>> - simplify several interfaces and helpers
>> - use lock guards
>> - initialize global lists and mutices
>>
>> Thomas Zimmermann (11):
>> fbdev: Rework fb_blank()
>> fbdev: Track display blanking state
>> fbdev: Send old blank state in FB_EVENT_BLANK
>> backlight: Implement fbdev tracking with blank state from event
>> backlight: Move blank-state handling into helper
>> backlight: Replace fb events with a dedicated function call
>> backlight: lcd: Move event handling into helpers
>> backlight: lcd: Replace fb events with a dedicated function call
>> leds: backlight trigger: Move blank-state handling into helper
>> leds: backlight trigger: Replace fb events with a dedicated function
>> call
>> fbdev: Remove constants of unused events
>>
>> drivers/leds/trigger/ledtrig-backlight.c | 48 +++++-----
>> drivers/video/backlight/backlight.c | 93 +++++--------------
>> drivers/video/backlight/lcd.c | 108 +++++++++--------------
>> drivers/video/fbdev/core/fb_backlight.c | 12 +++
>> drivers/video/fbdev/core/fb_info.c | 1 +
>> drivers/video/fbdev/core/fbmem.c | 82 ++++++++++++++---
>> drivers/video/fbdev/core/fbsysfs.c | 8 +-
>> include/linux/backlight.h | 22 ++---
>> include/linux/fb.h | 12 +--
>> include/linux/lcd.h | 21 ++++-
>> include/linux/leds.h | 6 ++
>> 11 files changed, 205 insertions(+), 208 deletions(-)
> No immediately obvious issues from the LEDs side.
>
> Still needs reviews from Backlight and fbdev.
I'm confused. Are you not the backlight maintainer?
Best regards
Thomas
>
--
--
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 v3 00/11] backlight, lcd, led: Remove fbdev dependencies
From: Daniel Thompson @ 2025-03-17 17:14 UTC (permalink / raw)
To: Thomas Zimmermann
Cc: Lee Jones, pavel, danielt, jingoohan1, deller, simona, linux-leds,
dri-devel, linux-fbdev
In-Reply-To: <f3c245a4-d932-417e-a0e8-f0453c9bc2ef@suse.de>
On Mon, Mar 17, 2025 at 09:42:11AM +0100, Thomas Zimmermann wrote:
> Hi
>
> Am 13.03.25 um 17:51 schrieb Lee Jones:
> > On Thu, 06 Mar 2025, Thomas Zimmermann wrote:
> >
> > > This series removes the remaining dependencies on fbdev from the
> > > backlight, lcd and led subsystems. Each depends on fbdev events to
> > > track display state. Make fbdev inform each subsystem via a dedicated
> > > interface instead.
> > >
> > > Patches 1 to 3 make fbdev track blank state for each display, so that
> > > backlight code doesn't have to.
> > >
> > > Patches 4 to 6 remove fbdev event handling from backlight code. Patches
> > > 7 and 8 remove fbdev event handling from lcd code and patches 9 and 10
> > > do the same for led's backlight trigger.
> > >
> > > The final patch removes the event constants from fbdev.
> > >
> > > With the series applied, the three subsystems do no longer depend on
> > > fbdev. It's also a clean up for fbdev. Fbdev used to send out a large
> > > number of events. That mechanism has been deprecated for some time and
> > > converted call to dedicated functions instead.
> > >
> > > Testing is very welcome, as I don't have the hardware to test this
> > > series.
> > >
> > > v3:
> > > - export several symbols
> > > - static-inline declare empty placeholders
> > > v2:
> > > - avoid IS_REACHABLE() in source file (Lee)
> > > - simplify several interfaces and helpers
> > > - use lock guards
> > > - initialize global lists and mutices
> > >
> > > Thomas Zimmermann (11):
> > > fbdev: Rework fb_blank()
> > > fbdev: Track display blanking state
> > > fbdev: Send old blank state in FB_EVENT_BLANK
> > > backlight: Implement fbdev tracking with blank state from event
> > > backlight: Move blank-state handling into helper
> > > backlight: Replace fb events with a dedicated function call
> > > backlight: lcd: Move event handling into helpers
> > > backlight: lcd: Replace fb events with a dedicated function call
> > > leds: backlight trigger: Move blank-state handling into helper
> > > leds: backlight trigger: Replace fb events with a dedicated function
> > > call
> > > fbdev: Remove constants of unused events
> > >
> > > drivers/leds/trigger/ledtrig-backlight.c | 48 +++++-----
> > > drivers/video/backlight/backlight.c | 93 +++++--------------
> > > drivers/video/backlight/lcd.c | 108 +++++++++--------------
> > > drivers/video/fbdev/core/fb_backlight.c | 12 +++
> > > drivers/video/fbdev/core/fb_info.c | 1 +
> > > drivers/video/fbdev/core/fbmem.c | 82 ++++++++++++++---
> > > drivers/video/fbdev/core/fbsysfs.c | 8 +-
> > > include/linux/backlight.h | 22 ++---
> > > include/linux/fb.h | 12 +--
> > > include/linux/lcd.h | 21 ++++-
> > > include/linux/leds.h | 6 ++
> > > 11 files changed, 205 insertions(+), 208 deletions(-)
> > No immediately obvious issues from the LEDs side.
> >
> > Still needs reviews from Backlight and fbdev.
>
> I'm confused. Are you not the backlight maintainer?
Lee is, yes, but this kind of comment is usually a hint that I've
been delinquent in my backlight reviews and records that he hasn't
looked at the backlight code yet ;-).
I'll get on it tomorrow!
Daniel.
^ permalink raw reply
* Re: (subset) [PATCH v2 2/9] rtc: pcf50633: Remove
From: Alexandre Belloni @ 2025-03-17 21:56 UTC (permalink / raw)
To: arnd, lee, dmitry.torokhov, sre, lgirdwood, broonie, danielt,
jingoohan1, deller, linus.walleij, brgl, tsbogend, linux
Cc: linux-mips, linux-input, linux-pm, linux-rtc, dri-devel,
linux-fbdev, linux-gpio, linux-kernel
In-Reply-To: <20250311014959.743322-3-linux@treblig.org>
On Tue, 11 Mar 2025 01:49:52 +0000, linux@treblig.org wrote:
> The pcf50633 was used as part of the OpenMoko devices but
> the support for its main chip was recently removed in:
> commit 61b7f8920b17 ("ARM: s3c: remove all s3c24xx support")
>
> See https://lore.kernel.org/all/Z8z236h4B5A6Ki3D@gallifrey/
>
> Remove it.
>
> [...]
Applied, thanks!
[2/9] rtc: pcf50633: Remove
https://git.kernel.org/abelloni/c/0a243de9d009
Best regards,
--
Alexandre Belloni, co-owner and COO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
^ permalink raw reply
* fbdev deferred I/O broken in some scenarios
From: Michael Kelley @ 2025-03-18 2:05 UTC (permalink / raw)
To: linux-fbdev@vger.kernel.org
Cc: linux-kernel@vger.kernel.org, linux-hyperv@vger.kernel.org
I've been trying to get mmap() working with the hyperv_fb.c fbdev driver, which
is for Linux guests running on Microsoft's Hyper-V hypervisor. The hyperv_fb driver
uses fbdev deferred I/O for performance reasons. But it looks to me like fbdev
deferred I/O is fundamentally broken when the underlying framebuffer memory
is allocated from kernel memory (alloc_pages or dma_alloc_coherent).
The hyperv_fb.c driver may allocate the framebuffer memory in several ways,
depending on the size of the framebuffer specified by the Hyper-V host and the VM
"Generation". For a Generation 2 VM, the framebuffer memory is allocated by the
Hyper-V host and is assigned to guest MMIO space. The hyperv_fb driver does a
vmalloc() allocation for deferred I/O to work against. This combination handles mmap()
of /dev/fb<n> correctly and the performance benefits of deferred I/O are substantial.
But for a Generation 1 VM, the hyperv_fb driver allocates the framebuffer memory in
contiguous guest physical memory using alloc_pages() or dma_alloc_coherent(), and
informs the Hyper-V host of the location. In this case, mmap() with deferred I/O does
not work. The mmap() succeeds, and user space updates to the mmap'ed memory are
correctly reflected to the framebuffer. But when the user space program does munmap()
or terminates, the Linux kernel free lists become scrambled and the kernel eventually
panics. The problem is that when munmap() is done, the PTEs in the VMA are cleaned
up, and the corresponding struct page refcounts are decremented. If the refcount goes
to zero (which it typically will), the page is immediately freed. In this way, some or all
of the framebuffer memory gets erroneously freed. From what I see, the VMA should
be marked VM_PFNMAP when allocated memory kernel is being used as the
framebuffer with deferred I/O, but that's not happening. The handling of deferred I/O
page faults would also need updating to make this work.
The fbdev deferred I/O support was originally added to the hyperv_fb driver in the
5.6 kernel, and based on my recent experiments, it has never worked correctly when
the framebuffer is allocated from kernel memory. fbdev deferred I/O support for using
kernel memory as the framebuffer was originally added in commit 37b4837959cb9
back in 2008 in Linux 2.6.29. But I don't see how it ever worked properly, unless
changes in generic memory management somehow broke it in the intervening years.
I think I know how to fix all this. But before working on a patch, I wanted to check
with the fbdev community to see if this might be a known issue and whether there
is any additional insight someone might offer. Thanks for any comments or help.
Michael Kelley
^ permalink raw reply
* Re: fbdev deferred I/O broken in some scenarios
From: Helge Deller @ 2025-03-18 8:16 UTC (permalink / raw)
To: Michael Kelley, linux-fbdev@vger.kernel.org
Cc: linux-kernel@vger.kernel.org, linux-hyperv@vger.kernel.org
In-Reply-To: <SN6PR02MB4157227300E59ACB3B0DABD0D4DE2@SN6PR02MB4157.namprd02.prod.outlook.com>
Hi Michael,
On 3/18/25 03:05, Michael Kelley wrote:
> I've been trying to get mmap() working with the hyperv_fb.c fbdev driver, which
> is for Linux guests running on Microsoft's Hyper-V hypervisor. The hyperv_fb driver
> uses fbdev deferred I/O for performance reasons. But it looks to me like fbdev
> deferred I/O is fundamentally broken when the underlying framebuffer memory
> is allocated from kernel memory (alloc_pages or dma_alloc_coherent).
>
> The hyperv_fb.c driver may allocate the framebuffer memory in several ways,
> depending on the size of the framebuffer specified by the Hyper-V host and the VM
> "Generation". For a Generation 2 VM, the framebuffer memory is allocated by the
> Hyper-V host and is assigned to guest MMIO space. The hyperv_fb driver does a
> vmalloc() allocation for deferred I/O to work against. This combination handles mmap()
> of /dev/fb<n> correctly and the performance benefits of deferred I/O are substantial.
>
> But for a Generation 1 VM, the hyperv_fb driver allocates the framebuffer memory in
> contiguous guest physical memory using alloc_pages() or dma_alloc_coherent(), and
> informs the Hyper-V host of the location. In this case, mmap() with deferred I/O does
> not work. The mmap() succeeds, and user space updates to the mmap'ed memory are
> correctly reflected to the framebuffer. But when the user space program does munmap()
> or terminates, the Linux kernel free lists become scrambled and the kernel eventually
> panics. The problem is that when munmap() is done, the PTEs in the VMA are cleaned
> up, and the corresponding struct page refcounts are decremented. If the refcount goes
> to zero (which it typically will), the page is immediately freed. In this way, some or all
> of the framebuffer memory gets erroneously freed. From what I see, the VMA should
> be marked VM_PFNMAP when allocated memory kernel is being used as the
> framebuffer with deferred I/O, but that's not happening. The handling of deferred I/O
> page faults would also need updating to make this work.
>
> The fbdev deferred I/O support was originally added to the hyperv_fb driver in the
> 5.6 kernel, and based on my recent experiments, it has never worked correctly when
> the framebuffer is allocated from kernel memory. fbdev deferred I/O support for using
> kernel memory as the framebuffer was originally added in commit 37b4837959cb9
> back in 2008 in Linux 2.6.29. But I don't see how it ever worked properly, unless
> changes in generic memory management somehow broke it in the intervening years.
>
> I think I know how to fix all this. But before working on a patch, I wanted to check
> with the fbdev community to see if this might be a known issue and whether there
> is any additional insight someone might offer. Thanks for any comments or help.
I haven't heard of any major deferred-i/o issues since I've jumped into fbdev
maintenance. But you might be right, as I haven't looked much into it yet and
there are just a few drivers using it.
Helge
^ permalink raw reply
* Re: fbdev deferred I/O broken in some scenarios
From: Thomas Zimmermann @ 2025-03-18 8:25 UTC (permalink / raw)
To: Michael Kelley, linux-fbdev@vger.kernel.org
Cc: linux-kernel@vger.kernel.org, linux-hyperv@vger.kernel.org
In-Reply-To: <SN6PR02MB4157227300E59ACB3B0DABD0D4DE2@SN6PR02MB4157.namprd02.prod.outlook.com>
Hi
Am 18.03.25 um 03:05 schrieb Michael Kelley:
> I've been trying to get mmap() working with the hyperv_fb.c fbdev driver, which
> is for Linux guests running on Microsoft's Hyper-V hypervisor. The hyperv_fb driver
> uses fbdev deferred I/O for performance reasons. But it looks to me like fbdev
> deferred I/O is fundamentally broken when the underlying framebuffer memory
> is allocated from kernel memory (alloc_pages or dma_alloc_coherent).
>
> The hyperv_fb.c driver may allocate the framebuffer memory in several ways,
> depending on the size of the framebuffer specified by the Hyper-V host and the VM
> "Generation". For a Generation 2 VM, the framebuffer memory is allocated by the
> Hyper-V host and is assigned to guest MMIO space. The hyperv_fb driver does a
> vmalloc() allocation for deferred I/O to work against. This combination handles mmap()
> of /dev/fb<n> correctly and the performance benefits of deferred I/O are substantial.
>
> But for a Generation 1 VM, the hyperv_fb driver allocates the framebuffer memory in
> contiguous guest physical memory using alloc_pages() or dma_alloc_coherent(), and
> informs the Hyper-V host of the location. In this case, mmap() with deferred I/O does
> not work. The mmap() succeeds, and user space updates to the mmap'ed memory are
> correctly reflected to the framebuffer. But when the user space program does munmap()
> or terminates, the Linux kernel free lists become scrambled and the kernel eventually
> panics. The problem is that when munmap() is done, the PTEs in the VMA are cleaned
> up, and the corresponding struct page refcounts are decremented. If the refcount goes
> to zero (which it typically will), the page is immediately freed. In this way, some or all
> of the framebuffer memory gets erroneously freed. From what I see, the VMA should
> be marked VM_PFNMAP when allocated memory kernel is being used as the
> framebuffer with deferred I/O, but that's not happening. The handling of deferred I/O
> page faults would also need updating to make this work.
I cannot help much with HyperV, but there's a get_page callback in
struct fb_deferred_io. [1] It'll allow you to provide a custom page on
each page fault. We use it in DRM to mmap SHMEM-backed pages. [2] Maybe
this helps with hyperv_fb as well.
Best regards
Thomas
[1] https://elixir.bootlin.com/linux/v6.13.7/source/include/linux/fb.h#L229
[2]
https://elixir.bootlin.com/linux/v6.13.7/source/drivers/gpu/drm/drm_fbdev_shmem.c#L82
>
> The fbdev deferred I/O support was originally added to the hyperv_fb driver in the
> 5.6 kernel, and based on my recent experiments, it has never worked correctly when
> the framebuffer is allocated from kernel memory. fbdev deferred I/O support for using
> kernel memory as the framebuffer was originally added in commit 37b4837959cb9
> back in 2008 in Linux 2.6.29. But I don't see how it ever worked properly, unless
> changes in generic memory management somehow broke it in the intervening years.
>
> I think I know how to fix all this. But before working on a patch, I wanted to check
> with the fbdev community to see if this might be a known issue and whether there
> is any additional insight someone might offer. Thanks for any comments or help.
>
> Michael Kelley
>
--
--
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 v3 04/11] backlight: Implement fbdev tracking with blank state from event
From: Daniel Thompson @ 2025-03-18 9:05 UTC (permalink / raw)
To: Thomas Zimmermann
Cc: lee, pavel, jingoohan1, deller, simona, linux-leds, dri-devel,
linux-fbdev
In-Reply-To: <20250306140947.580324-5-tzimmermann@suse.de>
On Thu, Mar 06, 2025 at 03:05:46PM +0100, Thomas Zimmermann wrote:
> Look at the blank state provided by FB_EVENT_BLANK to determine
> whether to enable or disable a backlight. Remove the tracking fields
> from struct backlight_device.
>
> Tracking requires three variables, fb_on, prev_fb_on and the
> backlight's use_count. If fb_on is true, the display has been
> unblanked. The backlight needs to be enabled if the display was
> blanked before (i.e., prev_fb_on is false) or if use_count is still
> at 0. If fb_on is false, the display has been blanked. In this case,
> the backlight has to be disabled was unblanked before and the
> backlight's use_count is greater than 0.
>
> This change removes fbdev state tracking from blacklight. All the
> backlight requires it its own use counter and information about
> changes to the display. Removing fbdev internals makes backlight
> drivers easier to integrate into other display drivers, such as DRM.
>
> Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Reviewed-by: Daniel Thompson (RISCstar) <danielt@kernel.org>
Daniel.
^ permalink raw reply
* Re: [PATCH v3 05/11] backlight: Move blank-state handling into helper
From: Daniel Thompson @ 2025-03-18 9:07 UTC (permalink / raw)
To: Thomas Zimmermann
Cc: lee, pavel, jingoohan1, deller, simona, linux-leds, dri-devel,
linux-fbdev
In-Reply-To: <20250306140947.580324-6-tzimmermann@suse.de>
On Thu, Mar 06, 2025 at 03:05:47PM +0100, Thomas Zimmermann wrote:
> Move the handling of blank-state updates into a separate helper,
> so that is can be called without the fbdev event. No functional
> changes.
>
> As a minor improvement over the original code, the update replaces
> manual locking with a guard.
>
> Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Reviewed-by: Daniel Thompson (RISCstar) <danielt@kernel.org>
Daniel.
^ permalink raw reply
* Re: [PATCH v3 06/11] backlight: Replace fb events with a dedicated function call
From: Daniel Thompson @ 2025-03-18 9:23 UTC (permalink / raw)
To: Thomas Zimmermann
Cc: lee, pavel, jingoohan1, deller, simona, linux-leds, dri-devel,
linux-fbdev
In-Reply-To: <20250306140947.580324-7-tzimmermann@suse.de>
On Thu, Mar 06, 2025 at 03:05:48PM +0100, Thomas Zimmermann wrote:
> Remove support for fb events from backlight subsystem. Provide the
> helper backlight_notify_blank_all() instead. Also export the existing
> helper backlight_notify_blank() to update a single backlight device.
>
> In fbdev, call either helper to inform the backlight subsystem of
> changes to a display's blank state. If the framebuffer device has a
> specific backlight, only update this one; otherwise update all.
>
> v3:
> - declare empty fb_bl_notify_blank() as static inline (kernel test robot)
Looks like there are still configs where we get build failure.
> Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Other than the build issues, generally this looks great. Just a couple
of small issues below.
> diff --git a/drivers/video/backlight/backlight.c b/drivers/video/backlight/backlight.c
> index 1c43f579396f..9dc93c5e480b 100644
> --- a/drivers/video/backlight/backlight.c
> +++ b/drivers/video/backlight/backlight.c
> @@ -78,11 +77,8 @@ static const char *const backlight_scale_types[] = {
> [BACKLIGHT_SCALE_NON_LINEAR] = "non-linear",
> };
>
> -#if defined(CONFIG_FB_CORE) || (defined(CONFIG_FB_CORE_MODULE) && \
> - defined(CONFIG_BACKLIGHT_CLASS_DEVICE_MODULE))
> -static void backlight_notify_blank(struct backlight_device *bd,
> - struct device *display_dev,
> - bool fb_on, bool prev_fb_on)
> +void backlight_notify_blank(struct backlight_device *bd, struct device *display_dev,
> + bool fb_on, bool prev_fb_on)
> {
> guard(mutex)(&bd->ops_lock);
>
> @@ -103,68 +99,18 @@ static void backlight_notify_blank(struct backlight_device *bd,
> }
> }
> }
> +EXPORT_SYMBOL(backlight_notify_blank);
Should this be EXPORT_SYMBOL_GPL()?
>
> -/*
> - * fb_notifier_callback
> - *
> - * This callback gets called when something important happens inside a
> - * framebuffer driver. The backlight core only cares about FB_BLANK_UNBLANK
> - * which is reported to the driver using backlight_update_status()
> - * as a state change.
> - *
> - * There may be several fbdev's connected to the backlight device,
> - * in which case they are kept track of. A state change is only reported
> - * if there is a change in backlight for the specified fbdev.
> - */
> -static int fb_notifier_callback(struct notifier_block *self,
> - unsigned long event, void *data)
> +void backlight_notify_blank_all(struct device *display_dev, bool fb_on, bool prev_fb_on)
> {
> struct backlight_device *bd;
> - struct fb_event *evdata = data;
> - struct fb_info *info = evdata->info;
> - const int *fb_blank = evdata->data;
> - struct backlight_device *fb_bd = fb_bl_device(info);
> - bool fb_on, prev_fb_on;
> -
> - /* If we aren't interested in this event, skip it immediately ... */
> - if (event != FB_EVENT_BLANK)
> - return 0;
> -
> - bd = container_of(self, struct backlight_device, fb_notif);
> -
> - if (fb_bd && fb_bd != bd)
> - return 0;
> -
> - fb_on = fb_blank[0] == FB_BLANK_UNBLANK;
> - prev_fb_on = fb_blank[1] == FB_BLANK_UNBLANK;
> -
> - backlight_notify_blank(bd, info->device, fb_on, prev_fb_on);
> -
> - return 0;
> -}
> -
> -static int backlight_register_fb(struct backlight_device *bd)
> -{
> - memset(&bd->fb_notif, 0, sizeof(bd->fb_notif));
> - bd->fb_notif.notifier_call = fb_notifier_callback;
>
> - return fb_register_client(&bd->fb_notif);
> -}
> + guard(mutex)(&backlight_dev_list_mutex);
>
> -static void backlight_unregister_fb(struct backlight_device *bd)
> -{
> - fb_unregister_client(&bd->fb_notif);
> -}
> -#else
> -static inline int backlight_register_fb(struct backlight_device *bd)
> -{
> - return 0;
> + list_for_each_entry(bd, &backlight_dev_list, entry)
> + backlight_notify_blank(bd, display_dev, fb_on, prev_fb_on);
> }
> -
> -static inline void backlight_unregister_fb(struct backlight_device *bd)
> -{
> -}
> -#endif /* CONFIG_FB_CORE */
> +EXPORT_SYMBOL(backlight_notify_blank_all);
Same here.
Daniel.
^ permalink raw reply
* Re: [PATCH v3 07/11] backlight: lcd: Move event handling into helpers
From: Daniel Thompson @ 2025-03-18 9:25 UTC (permalink / raw)
To: Thomas Zimmermann
Cc: lee, pavel, jingoohan1, deller, simona, linux-leds, dri-devel,
linux-fbdev
In-Reply-To: <20250306140947.580324-8-tzimmermann@suse.de>
On Thu, Mar 06, 2025 at 03:05:49PM +0100, Thomas Zimmermann wrote:
> Move the handling of display updates to separate helper functions.
> There is code for handling fbdev blank events and fbdev mode changes.
> The code currently runs from fbdev event notifiers, which will be
> replaced.
>
> Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Reviewed-by: Daniel Thompson (RISCstar) <danielt@kernel.org>
Daniel.
^ permalink raw reply
* Re: [PATCH v3 08/11] backlight: lcd: Replace fb events with a dedicated function call
From: Daniel Thompson @ 2025-03-18 9:40 UTC (permalink / raw)
To: Thomas Zimmermann
Cc: lee, pavel, jingoohan1, deller, simona, linux-leds, dri-devel,
linux-fbdev
In-Reply-To: <20250306140947.580324-9-tzimmermann@suse.de>
On Thu, Mar 06, 2025 at 03:05:50PM +0100, Thomas Zimmermann wrote:
> Remove support for fb events from the lcd subsystem. Provide the
> helper lcd_notify_blank_all() instead. In fbdev, call
> lcd_notify_blank_all() to inform the lcd subsystem of changes
> to a display's blank state.
>
> Fbdev maintains a list of all installed notifiers. Instead of fbdev
> notifiers, maintain an internal list of lcd devices.
I don't love the LCD devices list, however I can see the list of notifiers
had the same semantic effect (only less explicit) so I can live with
it ;-).
> v3:
> - export lcd_notify_mode_change_all() (kernel test robot)
> v2:
> - maintain global list of lcd devices
> - avoid IS_REACHABLE() in source file
> - use lock guards
> - initialize lcd list and list mutex
>
> Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Happy with these changes, but have the same EXPORT_SYMBOL_GPL()
questions I did with the backlight code.
Daniel.
^ permalink raw reply
* Re: [PATCH RFC] backlight: pwm_bl: Read back PWM period from provider
From: Daniel Thompson @ 2025-03-18 10:05 UTC (permalink / raw)
To: Sebastian Reichel
Cc: Uwe Kleine-König, Abel Vesa, Lee Jones, Jingoo Han,
Helge Deller, Bjorn Andersson, Konrad Dybcio, Johan Hovold,
linux-pwm, dri-devel, linux-arm-msm, linux-fbdev, linux-kernel
In-Reply-To: <cmjyaveolhjtfhqbjpc6ghh7g2f5jmeyavoms5lqup6dyidngl@ljvxgoyw57md>
On Thu, Feb 27, 2025 at 04:06:47AM +0100, Sebastian Reichel wrote:
> Hi,
>
> On Wed, Feb 26, 2025 at 05:34:50PM +0100, Uwe Kleine-König wrote:
> > On Wed, Feb 26, 2025 at 05:31:08PM +0200, Abel Vesa wrote:
> > > The current implementation assumes that the PWM provider will be able to
> > > meet the requested period, but that is not always the case. Some PWM
> > > providers have limited HW configuration capabilities and can only
> > > provide a period that is somewhat close to the requested one. This
> > > simply means that the duty cycle requested might either be above the
> > > PWM's maximum value or the 100% duty cycle is never reached.
> >
> > If you request a state with 100% relative duty cycle you should get 100%
> > unless the hardware cannot do that. Which PWM hardware are you using?
> > Which requests are you actually doing that don't match your expectation?
>
> drivers/leds/rgb/leds-qcom-lpg.c (which probably should at least get
> a MAINTAINERS entry to have you CC'd considering all the PWM bits in
> it). See the following discussion (I point you to my message in the
> middle of a thread, which has a summary and probably is a good
> starting point):
>
> https://lore.kernel.org/all/vc7irlp7nuy5yvkxwb5m7wy7j7jzgpg73zmajbmq2zjcd67pd2@cz2dcracta6w/
I had a quick glance at this thread.
It sounded to me like the PWM driver was scaling the requested period
to match h/ware capability but then neglected to scale the requested
duty cycle accordingly. That means the qcomm PWM driver programming a
fractional value into the hardware that was not being anywhere close
to duty_cycle / period.
So the recommendation was to fix the PWM driver rather than have
pwm_bl.c work around it?
Daniel.
^ permalink raw reply
* [PATCH 1/2] fbdev: omapfb: Remove writeback deadcode
From: Leonid Arapov @ 2025-03-18 21:19 UTC (permalink / raw)
To: Helge Deller
Cc: Leonid Arapov, Krzysztof Kozlowski, Dr. David Alan Gilbert,
Uwe Kleine-König, linux-omap, linux-fbdev, dri-devel,
linux-kernel, lvc-project
Value of enum parameter 'plane' is initialized in dss_init_overlays and
cannot take the value OMAP_DSS_WB. Function dispc_ovl_setup_common could
be called with this value of parameter only from dispc_wb_setup, which has
never been used and has been removed in commit 4f55bb03801a
("omapfb: Remove unused writeback code"). The code in the if-branch is
unreachable.
Remove unreachable branch.
Found by Linux Verification Center (linuxtesting.org) with SVACE static
analysis tool.
Signed-off-by: Leonid Arapov <arapovl839@gmail.com>
---
drivers/video/fbdev/omap2/omapfb/dss/dispc.c | 9 ++-------
1 file changed, 2 insertions(+), 7 deletions(-)
diff --git a/drivers/video/fbdev/omap2/omapfb/dss/dispc.c b/drivers/video/fbdev/omap2/omapfb/dss/dispc.c
index ccb96a5be07e..8db074862824 100644
--- a/drivers/video/fbdev/omap2/omapfb/dss/dispc.c
+++ b/drivers/video/fbdev/omap2/omapfb/dss/dispc.c
@@ -2659,13 +2659,8 @@ static int dispc_ovl_setup_common(enum omap_plane plane,
row_inc = 0;
pix_inc = 0;
- if (plane == OMAP_DSS_WB) {
- frame_width = out_width;
- frame_height = out_height;
- } else {
- frame_width = in_width;
- frame_height = height;
- }
+ frame_width = in_width;
+ frame_height = height;
if (rotation_type == OMAP_DSS_ROT_TILER)
calc_tiler_rotation_offset(screen_width, frame_width,
--
2.45.2
^ permalink raw reply related
* [PATCH 29/29] fbdev: omapfb: Add 'plane' value check
From: Leonid Arapov @ 2025-03-18 21:19 UTC (permalink / raw)
To: Helge Deller
Cc: Leonid Arapov, Krzysztof Kozlowski, Dr. David Alan Gilbert,
Uwe Kleine-König, linux-omap, linux-fbdev, dri-devel,
linux-kernel, lvc-project
In-Reply-To: <20250318211959.8557-1-arapovl839@gmail.com>
Function dispc_ovl_setup is not intended to work with the value OMAP_DSS_WB
of the enum parameter plane.
The value of this parameter is initialized in dss_init_overlays and in the
current state of the code it cannot take this value so it's not a real
problem.
For the purposes of defensive coding it wouldn't be superfluous to check
the parameter value, because some functions down the call stack process
this value correctly and some not.
For example, in dispc_ovl_setup_global_alpha it may lead to buffer
overflow.
Add check for this value.
Found by Linux Verification Center (linuxtesting.org) with SVACE static
analysis tool.
Signed-off-by: Leonid Arapov <arapovl839@gmail.com>
---
drivers/video/fbdev/omap2/omapfb/dss/dispc.c | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/video/fbdev/omap2/omapfb/dss/dispc.c b/drivers/video/fbdev/omap2/omapfb/dss/dispc.c
index 8db074862824..1dc70c96d813 100644
--- a/drivers/video/fbdev/omap2/omapfb/dss/dispc.c
+++ b/drivers/video/fbdev/omap2/omapfb/dss/dispc.c
@@ -2733,9 +2733,13 @@ int dispc_ovl_setup(enum omap_plane plane, const struct omap_overlay_info *oi,
bool mem_to_mem)
{
int r;
- enum omap_overlay_caps caps = dss_feat_get_overlay_caps(plane);
+ enum omap_overlay_caps caps;
enum omap_channel channel;
+ if (plane == OMAP_DSS_WB)
+ return -EINVAL;
+
+ caps = dss_feat_get_overlay_caps(plane);
channel = dispc_ovl_get_channel_out(plane);
DSSDBG("dispc_ovl_setup %d, pa %pad, pa_uv %pad, sw %d, %d,%d, %dx%d ->"
--
2.45.2
^ permalink raw reply related
* [PATCH] video: fbdev: sm501fb: Add some geometry checks.
From: Danila Chernetsov @ 2025-03-19 1:30 UTC (permalink / raw)
To: Helge Deller
Cc: Danila Chernetsov, linux-fbdev, dri-devel, linux-kernel,
lvc-project
Added checks for xoffset, yoffset settings.
Incorrect settings of these parameters can lead to errors
in sm501fb_pan_ functions.
Found by Linux Verification Center (linuxtesting.org) with SVACE.
Fixes: 5fc404e47bdf ("[PATCH] fb: SM501 framebuffer driver")
Signed-off-by: Danila Chernetsov <listdansp@mail.ru>
---
drivers/video/fbdev/sm501fb.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/drivers/video/fbdev/sm501fb.c b/drivers/video/fbdev/sm501fb.c
index 7734377b2d87..ed6f4f43e2d5 100644
--- a/drivers/video/fbdev/sm501fb.c
+++ b/drivers/video/fbdev/sm501fb.c
@@ -327,6 +327,13 @@ static int sm501fb_check_var(struct fb_var_screeninfo *var,
if (var->xres_virtual > 4096 || var->yres_virtual > 2048)
return -EINVAL;
+ /* geometry sanity checks */
+ if (var->xres + var->xoffset > var->xres_virtual)
+ return -EINVAL;
+
+ if (var->yres + var->yoffset > var->yres_virtual)
+ return -EINVAL;
+
/* can cope with 8,16 or 32bpp */
if (var->bits_per_pixel <= 8)
--
2.25.1
^ permalink raw reply related
* Re: [PATCH RESEND 0/2] Refactoring the fbcon packed pixel drawing routines
From: Helge Deller @ 2025-03-19 18:04 UTC (permalink / raw)
To: Zsolt Kajtar, linux-fbdev, dri-devel, Thomas Zimmermann
In-Reply-To: <20250309184716.13732-1-soci@c64.rulez.org>
On 3/9/25 19:47, Zsolt Kajtar wrote:
> This is the same patch as before just updated to latest fbdev
> master and with better description. And hopefully sent intact this
> time.
>
> Zsolt Kajtar (2):
> Refactoring the fbcon packed pixel drawing routines
> Adding contact info for packed pixel drawing
This patch series has now been in fbdev for-next git tree for 10 days
without any major issues reported so far.
I think it's a good and necessary cleanup, although it's of
course quite big (but mostly copy&paste).
I'd like to get some feedback if there are any major
objections that this goes upstream during the next merge window?
(Thomas: I know you were not very enthusiastic about
the previous patch set. I think this one is better.)
Helge
> MAINTAINERS | 16 +
> drivers/video/fbdev/core/Kconfig | 10 +-
> drivers/video/fbdev/core/cfbcopyarea.c | 428 +-------------------
> drivers/video/fbdev/core/cfbfillrect.c | 362 +----------------
> drivers/video/fbdev/core/cfbimgblt.c | 357 +----------------
> drivers/video/fbdev/core/cfbmem.h | 43 ++
> drivers/video/fbdev/core/fb_copyarea.h | 405 +++++++++++++++++++
> drivers/video/fbdev/core/fb_draw.h | 274 ++++++-------
> drivers/video/fbdev/core/fb_fillrect.h | 280 ++++++++++++++
> drivers/video/fbdev/core/fb_imageblit.h | 495 ++++++++++++++++++++++++
> drivers/video/fbdev/core/syscopyarea.c | 369 +-----------------
> drivers/video/fbdev/core/sysfillrect.c | 324 +---------------
> drivers/video/fbdev/core/sysimgblt.c | 333 +---------------
> drivers/video/fbdev/core/sysmem.h | 39 ++
> 14 files changed, 1480 insertions(+), 2255 deletions(-)
> create mode 100644 drivers/video/fbdev/core/cfbmem.h
> create mode 100644 drivers/video/fbdev/core/fb_copyarea.h
> create mode 100644 drivers/video/fbdev/core/fb_fillrect.h
> create mode 100644 drivers/video/fbdev/core/fb_imageblit.h
> create mode 100644 drivers/video/fbdev/core/sysmem.h
>
^ 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