* Re: [PATCH] staging: sm750fb: remove duplicate init_status structure
From: Dan Carpenter @ 2026-06-01 11:09 UTC (permalink / raw)
To: Hungyu Lin
Cc: sudipm.mukherjee, teddy.wang, gregkh, linux-fbdev, linux-staging,
linux-kernel
In-Reply-To: <20260530222432.4303-1-dennylin0707@gmail.com>
On Sat, May 30, 2026 at 10:24:32PM +0000, Hungyu Lin wrote:
> struct init_status duplicates struct initchip_param and is only used
> within the sm750fb driver.
>
> Replace the remaining users of struct init_status with
> struct initchip_param, remove the duplicate structure and eliminate
> the unnecessary cast in hw_sm750_inithw().
>
> No functional change intended.
>
> Signed-off-by: Hungyu Lin <dennylin0707@gmail.com>
> ---
Looks good to me. :)
Reviewed-by: Dan Carpenter <error27@gmail.com>
regards,
dan carpenter
^ permalink raw reply
* [PATCH v2] fbcon: do suspend/resume only when vc is text mode and visible
From: yaolu @ 2026-06-01 7:54 UTC (permalink / raw)
To: deller; +Cc: dri-devel, linux-fbdev, linux-kernel, simona, tzimmermann, yaolu
In-Reply-To: <67a1f756-996c-404b-8eff-f705ff151ed3@gmx.de>
From: Lu Yao <yaolu@kylinos.cn>
Don't need to do suspend/resume for fbcon in graphic mode.
Doing this may cause error, eg:
At the beginning, starting the Xorg with single screen and then an
external screen was plugged in. After logging out in Xorg, fbdev
info may using screen which is connected later on for info always
using first connected connector in list in func 'drm_setup_crtcs_fb'.
Then, S3 executed, fbcon found that the information did not match
and do atomic to switch fb. However, Xorg will not re-bind the crtc
fb but continues doing ioctl. At this time, the fb is incorrect.
Signed-off-by: Lu Yao <yaolu@kylinos.cn>
---
v1->v2: change to '==KD_TEXT' rather than '!=KD_GRAPHICS' and add
visible judgement suggested by Helge.
Link: https://lore.kernel.org/all/67a1f756-996c-404b-8eff-f705ff151ed3@gmx.de
drivers/video/fbdev/core/fbcon.c | 9 ++++++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/drivers/video/fbdev/core/fbcon.c b/drivers/video/fbdev/core/fbcon.c
index b0e3e765360d..ab460ba9264c 100644
--- a/drivers/video/fbdev/core/fbcon.c
+++ b/drivers/video/fbdev/core/fbcon.c
@@ -2602,8 +2602,9 @@ void fbcon_suspended(struct fb_info *info)
return;
vc = vc_cons[par->currcon].d;
- /* Clear cursor, restore saved data */
- fbcon_cursor(vc, false);
+ /* Only in TEXT mode and visible, need to clear cursor, restore saved data */
+ if ((vc->vc_mode == KD_TEXT) && con_is_visible(vc))
+ fbcon_cursor(vc, false);
}
void fbcon_resumed(struct fb_info *info)
@@ -2615,7 +2616,9 @@ void fbcon_resumed(struct fb_info *info)
return;
vc = vc_cons[par->currcon].d;
- update_screen(vc);
+ /* Graphics mode is managed by userspace */
+ if ((vc->vc_mode == KD_TEXT) && con_is_visible(vc))
+ update_screen(vc);
}
static void fbcon_modechanged(struct fb_info *info)
--
2.25.1
^ permalink raw reply related
* [PATCH v1] docs: omap/dss: Fix stale modedb.c path
From: Costa Shulyupin @ 2026-05-31 14:03 UTC (permalink / raw)
To: Jonathan Corbet, Shuah Khan, Randy Dunlap, linux-omap,
linux-fbdev, linux-doc, linux-kernel
Cc: Costa Shulyupin
The modedb.c file was moved from drivers/video/ to
drivers/video/fbdev/core/. Update the reference.
Assisted-by: Claude:claude-opus-4-6
Signed-off-by: Costa Shulyupin <costa.shul@redhat.com>
---
Documentation/arch/arm/omap/dss.rst | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/arch/arm/omap/dss.rst b/Documentation/arch/arm/omap/dss.rst
index a40c4d9c717a..9d39679235a3 100644
--- a/Documentation/arch/arm/omap/dss.rst
+++ b/Documentation/arch/arm/omap/dss.rst
@@ -314,7 +314,7 @@ Kernel boot arguments
omapfb.mode=<display>:<mode>[,...]
- Default video mode for specified displays. For example,
- "dvi:800x400MR-24@60". See drivers/video/modedb.c.
+ "dvi:800x400MR-24@60". See drivers/video/fbdev/core/modedb.c.
There are also two special modes: "pal" and "ntsc" that
can be used to tv out.
--
2.53.0
^ permalink raw reply related
* [PATCH] staging: sm750fb: remove duplicate init_status structure
From: Hungyu Lin @ 2026-05-30 22:24 UTC (permalink / raw)
To: sudipm.mukherjee, teddy.wang
Cc: gregkh, linux-fbdev, linux-staging, linux-kernel, error27,
Hungyu Lin
struct init_status duplicates struct initchip_param and is only used
within the sm750fb driver.
Replace the remaining users of struct init_status with
struct initchip_param, remove the duplicate structure and eliminate
the unnecessary cast in hw_sm750_inithw().
No functional change intended.
Signed-off-by: Hungyu Lin <dennylin0707@gmail.com>
---
drivers/staging/sm750fb/sm750.c | 8 ++++----
drivers/staging/sm750fb/sm750.h | 12 ++----------
drivers/staging/sm750fb/sm750_hw.c | 16 ++++++++--------
3 files changed, 14 insertions(+), 22 deletions(-)
diff --git a/drivers/staging/sm750fb/sm750.c b/drivers/staging/sm750fb/sm750.c
index 89c811e0806c..5986dbef67c0 100644
--- a/drivers/staging/sm750fb/sm750.c
+++ b/drivers/staging/sm750fb/sm750.c
@@ -844,11 +844,11 @@ static void sm750fb_setup(struct sm750_dev *sm750_dev, char *src)
swap = 0;
- sm750_dev->init_parm.chip_clk = 0;
- sm750_dev->init_parm.mem_clk = 0;
- sm750_dev->init_parm.master_clk = 0;
+ sm750_dev->init_parm.chip_clock = 0;
+ sm750_dev->init_parm.mem_clock = 0;
+ sm750_dev->init_parm.master_clock = 0;
sm750_dev->init_parm.power_mode = 0;
- sm750_dev->init_parm.setAllEngOff = 0;
+ sm750_dev->init_parm.set_all_eng_off = 0;
sm750_dev->init_parm.reset_memory = 1;
/* defaultly turn g_hwcursor on for both view */
diff --git a/drivers/staging/sm750fb/sm750.h b/drivers/staging/sm750fb/sm750.h
index d2c522e67f26..81fbf32865c3 100644
--- a/drivers/staging/sm750fb/sm750.h
+++ b/drivers/staging/sm750fb/sm750.h
@@ -1,6 +1,7 @@
/* SPDX-License-Identifier: GPL-2.0 */
#ifndef LYNXDRV_H_
#define LYNXDRV_H_
+#include "ddk750_chip.h"
#define FB_ACCEL_SMI 0xab
@@ -38,15 +39,6 @@ enum sm750_path {
sm750_pnc = 3, /* panel and crt */
};
-struct init_status {
- ushort power_mode;
- /* below three clocks are in unit of MHZ*/
- ushort chip_clk;
- ushort mem_clk;
- ushort master_clk;
- ushort setAllEngOff;
- ushort reset_memory;
-};
struct lynx_accel {
/* base virtual address of DPR registers */
@@ -102,7 +94,7 @@ struct sm750_dev {
/* locks*/
spinlock_t slock;
- struct init_status init_parm;
+ struct initchip_param init_parm;
enum sm750_pnltype pnltype;
enum sm750_dataflow dataflow;
int nocrt;
diff --git a/drivers/staging/sm750fb/sm750_hw.c b/drivers/staging/sm750fb/sm750_hw.c
index 34a837fb4b64..54c1b241ae6e 100644
--- a/drivers/staging/sm750fb/sm750_hw.c
+++ b/drivers/staging/sm750fb/sm750_hw.c
@@ -66,20 +66,20 @@ int hw_sm750_map(struct sm750_dev *sm750_dev, struct pci_dev *pdev)
int hw_sm750_inithw(struct sm750_dev *sm750_dev, struct pci_dev *pdev)
{
- struct init_status *parm;
+ struct initchip_param *parm;
parm = &sm750_dev->init_parm;
- if (parm->chip_clk == 0)
- parm->chip_clk = (sm750_get_chip_type() == SM750LE) ?
+ if (parm->chip_clock == 0)
+ parm->chip_clock = (sm750_get_chip_type() == SM750LE) ?
DEFAULT_SM750LE_CHIP_CLOCK :
DEFAULT_SM750_CHIP_CLOCK;
- if (parm->mem_clk == 0)
- parm->mem_clk = parm->chip_clk;
- if (parm->master_clk == 0)
- parm->master_clk = parm->chip_clk / 3;
+ if (parm->mem_clock == 0)
+ parm->mem_clock = parm->chip_clock;
+ if (parm->master_clock == 0)
+ parm->master_clock = parm->chip_clock / 3;
- ddk750_init_hw((struct initchip_param *)&sm750_dev->init_parm);
+ ddk750_init_hw(&sm750_dev->init_parm);
/* for sm718, open pci burst */
if (sm750_dev->devid == 0x718) {
poke32(SYSTEM_CTRL,
--
2.34.1
^ permalink raw reply related
* Re: [PATCH v2] staging: sm750fb: remove unused variable
From: Dan Carpenter @ 2026-05-30 19:52 UTC (permalink / raw)
To: neha arora
Cc: sudipm.mukherjee, teddy.wang, gregkh, linux-fbdev, linux-staging,
linux-kernel
In-Reply-To: <CAOWJOpt1ywtQFiazSBO5F7npLj6M4_tk7R4E8o0DVkHE5sWSvQ@mail.gmail.com>
On Fri, May 29, 2026 at 04:24:49PM +0530, neha arora wrote:
> Hi Dan,
>
> After looking into the structural dependencies and the cross-casting
> between init_status and initchip_param, I've decided that this refactoring
> is outside the scope of what I want to work on at this time.
> Please feel free to drop my previous patch. I'm going to shift my focus to
> other areas.
>
No stress. I feel like we see this often where people sign up for
one project and then it turns out way more different from what they
imagined and it actually isn't fun for them at all... It's fine to
move on.
Let's add this as a KTODO though, in case someone else wants to work on
it.
KTODO: remove the init_status or initchip_param struct. (They are
duplicates).
See this email for more details:
https://lore.kernel.org/all/ahlszyY6Nd9ANz-X@stanley.mountain/
regards,
dan carpenter
^ permalink raw reply
* [PATCH v5 2/2] backlight: Add SY7758 6-channel High Efficiency LED Driver support
From: Neil Armstrong @ 2026-05-29 19:23 UTC (permalink / raw)
To: Lee Jones, Daniel Thompson, Jingoo Han, Pavel Machek, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Helge Deller
Cc: dri-devel, linux-leds, devicetree, linux-kernel, linux-fbdev,
KancyJoe, Neil Armstrong
In-Reply-To: <20260529-topic-sm8650-ayaneo-pocket-s2-sy7758-v5-0-03aacd49747c@linaro.org>
From: KancyJoe <kancy2333@outlook.com>
Implement support for the Silergy SY7758 6-channel High Efficiency LED
Driver used for backlight brightness control in the Ayaneo Pocket S2
dual-DSI panel.
Signed-off-by: KancyJoe <kancy2333@outlook.com>
Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
---
drivers/video/backlight/Kconfig | 8 ++
drivers/video/backlight/Makefile | 1 +
drivers/video/backlight/sy7758.c | 259 +++++++++++++++++++++++++++++++++++++++
3 files changed, 268 insertions(+)
diff --git a/drivers/video/backlight/Kconfig b/drivers/video/backlight/Kconfig
index a7a3fbaf7c29..a1f70a2bae99 100644
--- a/drivers/video/backlight/Kconfig
+++ b/drivers/video/backlight/Kconfig
@@ -207,6 +207,14 @@ config BACKLIGHT_KTZ8866
Say Y to enable the backlight driver for the Kinetic KTZ8866
found in Xiaomi Mi Pad 5 series.
+config BACKLIGHT_SY7758
+ tristate "Backlight Driver for Silergy SY7758"
+ depends on I2C
+ select REGMAP_I2C
+ help
+ Say Y to enable the backlight driver for the Silergy SY7758
+ backlight controller found in Ayaneo Pocket S2.
+
config BACKLIGHT_LM3533
tristate "Backlight Driver for LM3533"
depends on MFD_LM3533
diff --git a/drivers/video/backlight/Makefile b/drivers/video/backlight/Makefile
index 794820a98ed4..39ef588b1cf2 100644
--- a/drivers/video/backlight/Makefile
+++ b/drivers/video/backlight/Makefile
@@ -56,6 +56,7 @@ obj-$(CONFIG_BACKLIGHT_PWM) += pwm_bl.o
obj-$(CONFIG_BACKLIGHT_QCOM_WLED) += qcom-wled.o
obj-$(CONFIG_BACKLIGHT_RT4831) += rt4831-backlight.o
obj-$(CONFIG_BACKLIGHT_SAHARA) += kb3886_bl.o
+obj-$(CONFIG_BACKLIGHT_SY7758) += sy7758.o
obj-$(CONFIG_BACKLIGHT_SKY81452) += sky81452-backlight.o
obj-$(CONFIG_BACKLIGHT_TPS65217) += tps65217_bl.o
obj-$(CONFIG_BACKLIGHT_WM831X) += wm831x_bl.o
diff --git a/drivers/video/backlight/sy7758.c b/drivers/video/backlight/sy7758.c
new file mode 100644
index 000000000000..786589cb8df9
--- /dev/null
+++ b/drivers/video/backlight/sy7758.c
@@ -0,0 +1,259 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Silergy SY7758 6-channel High Efficiency LED Driver
+ *
+ * Copyright (C) 2025 Kancy Joe <kancy2333@outlook.com>
+ * Copyright (C) 2026 Linaro Limited
+ * Author: Neil Armstrong <neil.armstrong@linaro.org>
+ */
+#include <linux/backlight.h>
+#include <linux/module.h>
+#include <linux/i2c.h>
+#include <linux/of.h>
+#include <linux/err.h>
+#include <linux/bits.h>
+#include <linux/delay.h>
+#include <linux/regmap.h>
+#include <linux/bitfield.h>
+#include <linux/gpio/consumer.h>
+#include <linux/regulator/consumer.h>
+
+#define DEFAULT_BRIGHTNESS 1024
+#define MAX_BRIGHTNESS 4080
+#define REG_MAX 0xAE
+
+/* Registers */
+#define REG_DEV_CTL 0x01
+#define REG_DEV_ID 0x03
+#define REG_BRT_12BIT_L 0x10
+#define REG_BRT_12BIT_H 0x11
+
+/* OTP memory */
+#define REG_OTP_CFG0 0xA0
+#define REG_OTP_CFG1 0xA1
+#define REG_OTP_CFG2 0xA2
+#define REG_OTP_CFG5 0xA5
+#define REG_OTP_CFG9 0xA9
+
+/* Fields */
+#define BIT_DEV_CTL_FAST BIT(7)
+#define MSK_DEV_CTL_BRT_MODE GENMASK(2, 1)
+#define BIT_DEV_CTL_BL_CTLB BIT(0)
+
+#define MSK_BRT_12BIT_L GENMASK(7, 0)
+#define MSK_BRT_12BIT_H GENMASK(3, 0)
+
+#define MSK_CFG0_CURRENT_LOW GENMASK(7, 0)
+
+#define BIT_CFG1_PDET_STDBY BIT(7)
+#define MSK_CFG1_CURRENT_MAX GENMASK(6, 4)
+#define MSK_CFG1_CURRENT_HIGH GENMASK(3, 0)
+
+#define BIT_CFG2_UVLO_EN BIT(5)
+#define BIT_CFG2_UVLO_TH BIT(4)
+#define BIT_CFG2_BL_ON BIT(3)
+#define BIT_CFG2_ISET_EN BIT(2)
+#define BIT_CFG2_BST_ESET_EN BIT(1)
+
+#define BIT_CFG5_PWM_DIRECT BIT(7)
+#define MSK_CFG5_PS_MODE GENMASK(6, 4)
+#define MSK_CFG5_PWM_FREQ GENMASK(3, 0)
+
+#define MSK_CFG9_VBST_MAX GENMASK(7, 5)
+#define BIT_CFG9_JUMP_EN BIT(4)
+#define MSK_CFG9_JUMP_TH GENMASK(3, 2)
+#define MSK_CFG9_JUMP_VOLTAGE GENMASK(1, 0)
+
+struct sy7758 {
+ struct i2c_client *client;
+ struct regmap *regmap;
+ struct gpio_desc *gpio;
+ struct backlight_device *bl;
+};
+
+static const struct regmap_config sy7758_regmap_config = {
+ .reg_bits = 8,
+ .val_bits = 8,
+ .max_register = REG_MAX,
+};
+
+static int sy7758_backlight_update_status(struct backlight_device *backlight_dev)
+{
+ struct sy7758 *sydev = bl_get_data(backlight_dev);
+ unsigned int brightness = backlight_get_brightness(backlight_dev);
+ int ret;
+
+ ret = regmap_write(sydev->regmap, REG_BRT_12BIT_L,
+ FIELD_PREP(MSK_BRT_12BIT_L,
+ brightness & 0xff));
+ if (ret)
+ return ret;
+
+ ret = regmap_write(sydev->regmap, REG_BRT_12BIT_H,
+ FIELD_PREP(MSK_BRT_12BIT_H,
+ (brightness >> 8) & 0xf));
+ if (ret)
+ return ret;
+
+ return 0;
+}
+
+static const struct backlight_ops sy7758_backlight_ops = {
+ .options = BL_CORE_SUSPENDRESUME,
+ .update_status = sy7758_backlight_update_status,
+};
+
+static int sy7758_init(struct sy7758 *sydev)
+{
+ int ret = 0;
+
+ ret = regmap_write(sydev->regmap, REG_DEV_CTL,
+ BIT_DEV_CTL_FAST | BIT_DEV_CTL_BL_CTLB |
+ FIELD_PREP(MSK_DEV_CTL_BRT_MODE, 2));
+ if (ret)
+ return ret;
+
+ ret = regmap_write(sydev->regmap, REG_BRT_12BIT_L,
+ FIELD_PREP(MSK_BRT_12BIT_L,
+ DEFAULT_BRIGHTNESS & 0xff));
+ if (ret)
+ return ret;
+
+ ret = regmap_write(sydev->regmap, REG_BRT_12BIT_H,
+ FIELD_PREP(MSK_BRT_12BIT_H,
+ (DEFAULT_BRIGHTNESS >> 8)));
+ if (ret)
+ return ret;
+
+ ret = regmap_write(sydev->regmap, REG_OTP_CFG5,
+ FIELD_PREP(MSK_CFG5_PS_MODE, 6) |
+ FIELD_PREP(MSK_CFG5_PWM_FREQ, 4));
+ if (ret)
+ return ret;
+
+ ret = regmap_write(sydev->regmap, REG_OTP_CFG0,
+ FIELD_PREP(MSK_CFG0_CURRENT_LOW, 85));
+ if (ret)
+ return ret;
+
+ ret = regmap_write(sydev->regmap, REG_OTP_CFG1,
+ BIT_CFG1_PDET_STDBY |
+ FIELD_PREP(MSK_CFG1_CURRENT_MAX, 1) |
+ FIELD_PREP(MSK_CFG1_CURRENT_HIGH, 10));
+ if (ret)
+ return ret;
+
+ ret = regmap_write(sydev->regmap, REG_OTP_CFG9,
+ FIELD_PREP(MSK_CFG9_VBST_MAX, 4));
+ if (ret)
+ return ret;
+
+ ret = regmap_write(sydev->regmap, REG_OTP_CFG2,
+ BIT_CFG2_BL_ON | BIT_CFG2_UVLO_EN);
+ if (ret)
+ return ret;
+
+ return 0;
+}
+
+static int sy7758_probe(struct i2c_client *client)
+{
+ struct backlight_properties props = { };
+ struct device *dev = &client->dev;
+ struct sy7758 *sydev;
+ unsigned int dev_id;
+ int ret;
+
+ sydev = devm_kzalloc(dev, sizeof(*sydev), GFP_KERNEL);
+ if (!sydev)
+ return -ENOMEM;
+
+ i2c_set_clientdata(client, sydev);
+
+ /* Initialize regmap */
+ sydev->client = client;
+ sydev->regmap = devm_regmap_init_i2c(client, &sy7758_regmap_config);
+ if (IS_ERR(sydev->regmap))
+ return dev_err_probe(dev, PTR_ERR(sydev->regmap),
+ "failed to init regmap\n");
+
+ /* Get and enable regulator */
+ ret = devm_regulator_get_enable(dev, "vdd");
+ if (ret)
+ return dev_err_probe(dev, ret, "failed to get regulator\n");
+
+ fsleep(100);
+
+ /* Get enable GPIO and set to high */
+ sydev->gpio = devm_gpiod_get(dev, "enable", GPIOD_OUT_HIGH);
+ if (IS_ERR(sydev->gpio))
+ return dev_err_probe(dev, PTR_ERR(sydev->gpio),
+ "failed to get enable GPIO\n");
+
+ /* Let some time for HW to settle */
+ fsleep(10000);
+
+ /* try read and check device id */
+ ret = regmap_read(sydev->regmap, REG_DEV_ID, &dev_id);
+ if (ret < 0)
+ return dev_err_probe(dev, ret, "failed to read device id\n");
+ if (dev_id != 0x63) {
+ dev_err(dev, "unexpected device id: 0x%02x\n", dev_id);
+ return -ENODEV;
+ }
+
+ /* Initialize and set default brightness */
+ ret = sy7758_init(sydev);
+ if (ret)
+ return ret;
+
+ props.type = BACKLIGHT_RAW;
+ props.max_brightness = MAX_BRIGHTNESS;
+ props.brightness = DEFAULT_BRIGHTNESS;
+ props.scale = BACKLIGHT_SCALE_LINEAR;
+
+ sydev->bl = devm_backlight_device_register(dev, "sy7758-backlight",
+ dev, sydev, &sy7758_backlight_ops,
+ &props);
+ if (IS_ERR(sydev->bl))
+ return dev_err_probe(dev, PTR_ERR(sydev->bl),
+ "failed to register backlight device\n");
+
+ return backlight_update_status(sydev->bl);
+}
+
+static void sy7758_remove(struct i2c_client *client)
+{
+ struct sy7758 *sydev = i2c_get_clientdata(client);
+
+ backlight_disable(sydev->bl);
+}
+
+static const struct i2c_device_id sy7758_ids[] = {
+ { "sy7758" },
+ { }
+};
+MODULE_DEVICE_TABLE(i2c, sy7758_ids);
+
+static const struct of_device_id sy7758_match_table[] = {
+ { .compatible = "silergy,sy7758", },
+ { },
+};
+MODULE_DEVICE_TABLE(of, sy7758_match_table);
+
+static struct i2c_driver sy7758_driver = {
+ .driver = {
+ .name = "sy7758",
+ .of_match_table = sy7758_match_table,
+ },
+ .probe = sy7758_probe,
+ .remove = sy7758_remove,
+ .id_table = sy7758_ids,
+};
+
+module_i2c_driver(sy7758_driver);
+
+MODULE_DESCRIPTION("Silergy SY7758 Backlight Driver");
+MODULE_AUTHOR("Kancy Joe <kancy2333@outlook.com>");
+MODULE_AUTHOR("Neil Armstrong <neil.armstrong@linaro.org>");
+MODULE_LICENSE("GPL");
--
2.34.1
^ permalink raw reply related
* [PATCH v5 1/2] dt-bindings: leds: backlight: document the SY7758 6-channel High Efficiency LED Driver
From: Neil Armstrong @ 2026-05-29 19:23 UTC (permalink / raw)
To: Lee Jones, Daniel Thompson, Jingoo Han, Pavel Machek, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Helge Deller
Cc: dri-devel, linux-leds, devicetree, linux-kernel, linux-fbdev,
KancyJoe, Neil Armstrong, Krzysztof Kozlowski
In-Reply-To: <20260529-topic-sm8650-ayaneo-pocket-s2-sy7758-v5-0-03aacd49747c@linaro.org>
Document the Silergy SY7758 6-channel High Efficiency LED Driver
used for backlight brightness control.
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
---
.../bindings/leds/backlight/silergy,sy7758.yaml | 52 ++++++++++++++++++++++
1 file changed, 52 insertions(+)
diff --git a/Documentation/devicetree/bindings/leds/backlight/silergy,sy7758.yaml b/Documentation/devicetree/bindings/leds/backlight/silergy,sy7758.yaml
new file mode 100644
index 000000000000..64af6b34641a
--- /dev/null
+++ b/Documentation/devicetree/bindings/leds/backlight/silergy,sy7758.yaml
@@ -0,0 +1,52 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/leds/backlight/silergy,sy7758.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Silergy SY7758 6-channel High Efficiency LED Driver
+
+maintainers:
+ - Neil Armstrong <neil.armstrong@linaro.org>
+
+description:
+ Silergy SY7758 is a high efficiency 6-channels LED backlight
+ driver with I2C brightness control.
+
+allOf:
+ - $ref: common.yaml#
+
+properties:
+ compatible:
+ const: silergy,sy7758
+
+ reg:
+ maxItems: 1
+
+ vdd-supply: true
+
+ enable-gpios:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+ - enable-gpios
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ backlight@11 {
+ compatible = "silergy,sy7758";
+ reg = <0x11>;
+ vdd-supply = <&bl_vdd>;
+ enable-gpios = <&gpio 16 GPIO_ACTIVE_HIGH>;
+ };
+ };
--
2.34.1
^ permalink raw reply related
* [PATCH v5 0/2] backlight: Add SY7758 6-channel High Efficiency LED Driver support
From: Neil Armstrong @ 2026-05-29 19:23 UTC (permalink / raw)
To: Lee Jones, Daniel Thompson, Jingoo Han, Pavel Machek, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Helge Deller
Cc: dri-devel, linux-leds, devicetree, linux-kernel, linux-fbdev,
KancyJoe, Neil Armstrong, Krzysztof Kozlowski
Implement support for the Silergy SY7758 6-channel High Efficiency LED Driver
used for backlight brightness control in the Ayaneo Pocket S2 dual-DSI panel.
Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
---
Changes in v5:
- Rename vddio to vdd and make it optional in bindings
- Kept the bindings review since the change is trivial
- Link to v4: https://patch.msgid.link/20260521-topic-sm8650-ayaneo-pocket-s2-sy7758-v4-0-73c732615e4a@linaro.org
Changes in v4:
- Fixed Kconfig typo
- Remove again unused macros
- Added delay.h include
- Link to v3: https://patch.msgid.link/20260519-topic-sm8650-ayaneo-pocket-s2-sy7758-v3-0-ec8194bbc885@linaro.org
Changes in v3:
- Dropped unused macros
- Added second autho entry to match header and commit message
- Move my signof at the end
- Switched to flseep()
- Link to v2: https://patch.msgid.link/20260430-topic-sm8650-ayaneo-pocket-s2-sy7758-v2-0-308140640de9@linaro.org
Changes in v2:
- Fixed bindings subject and removed "|"
- Added review tag
- Added higher delay before reading ID from HW (100us was too short)
- Removed probe defer if i2c read fails
- Link to v1: https://patch.msgid.link/20260428-topic-sm8650-ayaneo-pocket-s2-sy7758-v1-0-0caade5fdb32@linaro.org
---
KancyJoe (1):
backlight: Add SY7758 6-channel High Efficiency LED Driver support
Neil Armstrong (1):
dt-bindings: leds: backlight: document the SY7758 6-channel High Efficiency LED Driver
.../bindings/leds/backlight/silergy,sy7758.yaml | 52 +++++
drivers/video/backlight/Kconfig | 8 +
drivers/video/backlight/Makefile | 1 +
drivers/video/backlight/sy7758.c | 259 +++++++++++++++++++++
4 files changed, 320 insertions(+)
---
base-commit: 39704f00f747aba3144289870b5fd8ac230a9aaf
change-id: 20260428-topic-sm8650-ayaneo-pocket-s2-sy7758-3081ee7f1e25
Best regards,
--
Neil Armstrong <neil.armstrong@linaro.org>
^ permalink raw reply
* Re: [PATCH v3 1/2] dt-bindings: leds: backlight: document the SY7758 6-channel High Efficiency LED Driver
From: Neil Armstrong @ 2026-05-29 19:17 UTC (permalink / raw)
To: Daniel Thompson
Cc: Daniel Thompson, Lee Jones, Jingoo Han, Pavel Machek, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Helge Deller, dri-devel,
linux-leds, devicetree, linux-kernel, linux-fbdev, KancyJoe,
Krzysztof Kozlowski
In-Reply-To: <ahmkirIuOYhd1rkM@aspen.lan>
On 5/29/26 16:36, Daniel Thompson wrote:
> On Fri, May 29, 2026 at 03:15:03PM +0100, Daniel Thompson wrote:
>> On Fri, May 29, 2026 at 02:50:43PM +0200, Neil Armstrong wrote:
>>> On 5/29/26 12:35, Daniel Thompson wrote:
>>>> On Fri, May 29, 2026 at 12:16:07PM +0200, Neil Armstrong wrote:
>>> So it's not really 2 regulators, and having regulators means the enable
>>> signal can be shared and would have regulator characteristics which it hasn't.
>>
>> Agreed. If the EN pin is merely use as an enable and voltage reference
>> then it are not two regulators.
>>
>> However, it is also *not* vddio-supply and enable-gpios. We don't need
>> the board design to check this. The pinout diagram in the datasheet
>> should be sufficient!
>>
>> If you have to activate vddio-supply for the backlight to work on the
>> board are you sure you don't just have a misnamed vdd-supply that needs
>> to be taken care of? That would make much more sense given the datasheet.
>
> After posting this I figured there is another possibility.
>
> If the host GPIO pin is not capable of delivering the 1mA requires by
> the chip then the board designer would have to add a buffer and that
> buffer would need a power supply... and that power supply could, in
> pinciple, be switchable.
>
> However if that were the case then I don't think the power supply for
> the buffer would belong in the bindings for the sy7758 so I'm afraid
> whichever way I turn it I can't make vddio-supply make sense.
Yeah seems you're probably right, I'll move it to vdd instead and make it optional.
Thanks,
Neil
>
> Daniel.
^ permalink raw reply
* Re: [PATCH v3 1/2] dt-bindings: leds: backlight: document the SY7758 6-channel High Efficiency LED Driver
From: Daniel Thompson @ 2026-05-29 14:36 UTC (permalink / raw)
To: Neil Armstrong
Cc: Daniel Thompson, Lee Jones, Jingoo Han, Pavel Machek, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Helge Deller, dri-devel,
linux-leds, devicetree, linux-kernel, linux-fbdev, KancyJoe,
Krzysztof Kozlowski
In-Reply-To: <ahmfZ0tdxbVfD_y4@aspen.lan>
On Fri, May 29, 2026 at 03:15:03PM +0100, Daniel Thompson wrote:
> On Fri, May 29, 2026 at 02:50:43PM +0200, Neil Armstrong wrote:
> > On 5/29/26 12:35, Daniel Thompson wrote:
> > > On Fri, May 29, 2026 at 12:16:07PM +0200, Neil Armstrong wrote:
> > So it's not really 2 regulators, and having regulators means the enable
> > signal can be shared and would have regulator characteristics which it hasn't.
>
> Agreed. If the EN pin is merely use as an enable and voltage reference
> then it are not two regulators.
>
> However, it is also *not* vddio-supply and enable-gpios. We don't need
> the board design to check this. The pinout diagram in the datasheet
> should be sufficient!
>
> If you have to activate vddio-supply for the backlight to work on the
> board are you sure you don't just have a misnamed vdd-supply that needs
> to be taken care of? That would make much more sense given the datasheet.
After posting this I figured there is another possibility.
If the host GPIO pin is not capable of delivering the 1mA requires by
the chip then the board designer would have to add a buffer and that
buffer would need a power supply... and that power supply could, in
pinciple, be switchable.
However if that were the case then I don't think the power supply for
the buffer would belong in the bindings for the sy7758 so I'm afraid
whichever way I turn it I can't make vddio-supply make sense.
Daniel.
^ permalink raw reply
* Re: [PATCH v3 1/2] dt-bindings: leds: backlight: document the SY7758 6-channel High Efficiency LED Driver
From: Daniel Thompson @ 2026-05-29 14:15 UTC (permalink / raw)
To: Neil Armstrong
Cc: Daniel Thompson, Lee Jones, Jingoo Han, Pavel Machek, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Helge Deller, dri-devel,
linux-leds, devicetree, linux-kernel, linux-fbdev, KancyJoe,
Krzysztof Kozlowski
In-Reply-To: <4001cf6a-b7de-4933-96bc-c9b4ccb53e4d@linaro.org>
On Fri, May 29, 2026 at 02:50:43PM +0200, Neil Armstrong wrote:
> On 5/29/26 12:35, Daniel Thompson wrote:
> > On Fri, May 29, 2026 at 12:16:07PM +0200, Neil Armstrong wrote:
> > > On 5/29/26 12:07, Daniel Thompson wrote:
> > > > On Tue, May 19, 2026 at 10:43:38AM +0200, Neil Armstrong wrote:
> > > > > Document the Silergy SY7758 6-channel High Efficiency LED Driver
> > > > > used for backlight brightness control.
> > > > >
> > > > > Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
> > > > > Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
> > > > > ---
> > > > > .../bindings/leds/backlight/silergy,sy7758.yaml | 53 ++++++++++++++++++++++
> > > > > 1 file changed, 53 insertions(+)
> > > > >
> > > > > diff --git a/Documentation/devicetree/bindings/leds/backlight/silergy,sy7758.yaml b/Documentation/devicetree/bindings/leds/backlight/silergy,sy7758.yaml
> > > > > new file mode 100644
> > > > > index 000000000000..80e978d691c2
> > > > > --- /dev/null
> > > > > +++ b/Documentation/devicetree/bindings/leds/backlight/silergy,sy7758.yaml
> > > > > @@ -0,0 +1,53 @@
> > > > > +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
> > > > > +%YAML 1.2
> > > > > +---
> > > > > +$id: http://devicetree.org/schemas/leds/backlight/silergy,sy7758.yaml#
> > > > > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > > > > +
> > > > > +title: Silergy SY7758 6-channel High Efficiency LED Driver
> > > > > +
> > > > > +maintainers:
> > > > > + - Neil Armstrong <neil.armstrong@linaro.org>
> > > > > +
> > > > > +description:
> > > > > + Silergy SY7758 is a high efficiency 6-channels LED backlight
> > > > > + driver with I2C brightness control.
> > > > > +
> > > > > +allOf:
> > > > > + - $ref: common.yaml#
> > > > > +
> > > > > +properties:
> > > > > + compatible:
> > > > > + const: silergy,sy7758
> > > > > +
> > > > > + reg:
> > > > > + maxItems: 1
> > > > > +
> > > > > + vddio-supply: true
> > > > > +
> > > > > + enable-gpios:
> > > > > + maxItems: 1
> > > > > +
> > > > > +required:
> > > > > + - compatible
> > > > > + - reg
> > > > > + - vddio-supply
> > > >
> > > > Sorry for missing this in v2 but is vddio-supply really a required
> > > > property?
> > > >
> > > > It's unusual for supplies to be mandatory (and the it is not mandatory
> > > > in the driver implementation).
> > >
> > > This device is a little bit special, the VDDIO regulator is used to provide
> > > power for the I/O via the enable input, so basically the enable gpio power
> > > level is provided by VDDIO.
> >
> > I don't follow. The EN pin acts as both VDDIO and as an enable but it's
> > still effectively a power rail isn't it (albeit one with very low current
> > draw).
>
> Here's the datasheet description:
> ```
> Dual-purpose pin serving both as a chip enable and as a power supply
> reference for PWM, SDA, and SCL inputs.
> ```
Thanks for the quote. It's a big help (I've been working from a site
that makes me read a page at a time so I struggled to keep track of
things).
This says that the GPIO from the host is merely serving as a voltage
reference (for the an internal LDO regulator?). That means it is *not*
a power supply!
It sounds to me like the chip is designed to work with a host where
enable GPIO and I2C interface use the same I/O voltage. By having an
active-high enables the chip can *avoid* having a separate vddio pin.
However, in a design with no separate vddio pin then it would make no
sense to model a vddio-supply in the DT.
> The VDD input is directly provided by the panel, so Linux has no control
> of it so I haven't added it.
Power supplies are often added ad-hoc when the first board that includes
a regulator enable appears. On that basis omitting vdd-supply would be
relatively harmless if you don't need it but I wonder if you do, see below!
> > It looked to me like the correct way to model to two power rails
> > going into the chip is vdd-supply (main power supply) and vddio-supply
> > (EN/VDDIO) I don't understand why a single pin needs both a regulator
> > *and* a GPIO in the DT bindings?
>
> I don't have a the schematics of the board, but as I understood one gpio is
> actually enabling an regulator which provides power to the IC (vddio) and
> a second gpio will either drive the EN signal to GND or VDDIO to provide a
> clean rising edge on the EN pin.
This doesn't make sense since it is a single pin. It cannot be both a
power supply to the chip *and* a GPIO input. It's one or the other...
and from the above is sounds so me like GPIO).
> So it's not really 2 regulators, and having regulators means the enable
> signal can be shared and would have regulator characteristics which it hasn't.
Agreed. If the EN pin is merely use as an enable and voltage reference
then it are not two regulators.
However, it is also *not* vddio-supply and enable-gpios. We don't need
the board design to check this. The pinout diagram in the datasheet
should be sufficient!
If you have to activate vddio-supply for the backlight to work on the
board are you sure you don't just have a misnamed vdd-supply that needs
to be taken care of? That would make much more sense given the datasheet.
> > > This is the recommended way from the datasheet, and I assume it will be used
> > > like that on other platforms (if it exists...)
> > >
> > > This is why it's mandatory and enabled first before setting the enable pin.
> >
> > It's not mandatory for the C implementation. devm_regulator_get_enable()
> > will provide a dummy regulator if the property is omitted.
>
> So yeah if you prefer I'll re-spin with the vddio regulator as optional
> because between both, the VDDIO is the only which could be shared with
> other devices or always-on.
Based on the above, I'd be happy with an optional vdd-supply and an
enable-gpios.
Daniel.
^ permalink raw reply
* [PATCH 4/4] drm/draw: Remove unused helper drm_draw_get_char_bitmap()
From: Thomas Zimmermann @ 2026-05-29 14:01 UTC (permalink / raw)
To: jfalempe, javierm, deller, maarten.lankhorst, mripard, airlied,
simona
Cc: dri-devel, linux-fbdev, Thomas Zimmermann
In-Reply-To: <20260529140759.529929-1-tzimmermann@suse.de>
Glyph-shape lookup has been integrated into the font-data interface
and all callers have been updated. Remove the old helper.
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
---
drivers/gpu/drm/drm_draw_internal.h | 7 -------
1 file changed, 7 deletions(-)
diff --git a/drivers/gpu/drm/drm_draw_internal.h b/drivers/gpu/drm/drm_draw_internal.h
index 261967145635..44ddcee4744c 100644
--- a/drivers/gpu/drm/drm_draw_internal.h
+++ b/drivers/gpu/drm/drm_draw_internal.h
@@ -7,7 +7,6 @@
#ifndef __DRM_DRAW_INTERNAL_H__
#define __DRM_DRAW_INTERNAL_H__
-#include <linux/font.h>
#include <linux/types.h>
struct iosys_map;
@@ -18,12 +17,6 @@ static inline bool drm_draw_is_pixel_fg(const u8 *sbuf8, unsigned int spitch, in
return (sbuf8[(y * spitch) + x / 8] & (0x80 >> (x % 8))) != 0;
}
-static inline const u8 *drm_draw_get_char_bitmap(const struct font_desc *font,
- char c, size_t font_pitch)
-{
- return font->data + (c * font->height) * font_pitch;
-}
-
bool drm_draw_can_convert_from_xrgb8888(u32 format);
u32 drm_draw_color_from_xrgb8888(u32 color, u32 format);
--
2.54.0
^ permalink raw reply related
* [PATCH 3/4] drm/panic: Look up glyph shape with font helper
From: Thomas Zimmermann @ 2026-05-29 14:01 UTC (permalink / raw)
To: jfalempe, javierm, deller, maarten.lankhorst, mripard, airlied,
simona
Cc: dri-devel, linux-fbdev, Thomas Zimmermann
In-Reply-To: <20260529140759.529929-1-tzimmermann@suse.de>
Look up glyph shapes with font_data_glyph_buf(). Handle non-existing
glyphs gracefully. Enable extended ASCII by casting to unsigned char.
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
---
drivers/gpu/drm/drm_panic.c | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/drm_panic.c b/drivers/gpu/drm/drm_panic.c
index d6d3b8d85dea..e576c4791861 100644
--- a/drivers/gpu/drm/drm_panic.c
+++ b/drivers/gpu/drm/drm_panic.c
@@ -443,9 +443,11 @@ static void draw_txt_rectangle(struct drm_scanout_buffer *sb,
rec.x1 += (drm_rect_width(clip) - (line_len * font->width)) / 2;
for (j = 0; j < line_len; j++) {
- src = drm_draw_get_char_bitmap(font, msg[i].txt[j], font_pitch);
+ src = font_data_glyph_buf(font->data, font->width, font->height,
+ (unsigned char)msg[i].txt[j]);
rec.x2 = rec.x1 + font->width;
- drm_panic_blit(sb, &rec, src, font_pitch, 1, color);
+ if (src)
+ drm_panic_blit(sb, &rec, src, font_pitch, 1, color);
rec.x1 += font->width;
}
}
--
2.54.0
^ permalink raw reply related
* [PATCH 2/4] drm/client: log: Look up glyph shape with font helper
From: Thomas Zimmermann @ 2026-05-29 14:01 UTC (permalink / raw)
To: jfalempe, javierm, deller, maarten.lankhorst, mripard, airlied,
simona
Cc: dri-devel, linux-fbdev, Thomas Zimmermann
In-Reply-To: <20260529140759.529929-1-tzimmermann@suse.de>
Look up glyph shapes with font_data_glyph_buf(). Handle non-existing
glyphs gracefully. Enable extended ASCII by casting to unsigned char.
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
---
drivers/gpu/drm/clients/drm_log.c | 10 ++++++----
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/clients/drm_log.c b/drivers/gpu/drm/clients/drm_log.c
index 8d21b785bead..e3e02c84a4cf 100644
--- a/drivers/gpu/drm/clients/drm_log.c
+++ b/drivers/gpu/drm/clients/drm_log.c
@@ -122,10 +122,12 @@ static void drm_log_draw_line(struct drm_log_scanout *scanout, const char *s,
iosys_map_incr(&map, r.y1 * fb->pitches[0]);
for (i = 0; i < len && i < scanout->columns; i++) {
u32 color = (i < prefix_len) ? scanout->prefix_color : scanout->front_color;
- src = drm_draw_get_char_bitmap(font, s[i], font_pitch);
- drm_log_blit(&map, fb->pitches[0], src, font_pitch,
- scanout->scaled_font_h, scanout->scaled_font_w,
- px_width, color);
+ src = font_data_glyph_buf(font->data, font->width, font->height,
+ (unsigned char)s[i]);
+ if (src)
+ drm_log_blit(&map, fb->pitches[0], src, font_pitch,
+ scanout->scaled_font_h, scanout->scaled_font_w,
+ px_width, color);
iosys_map_incr(&map, scanout->scaled_font_w * px_width);
}
--
2.54.0
^ permalink raw reply related
* [PATCH 0/4] drm: Safe font-data access in log/panic drawing
From: Thomas Zimmermann @ 2026-05-29 14:01 UTC (permalink / raw)
To: jfalempe, javierm, deller, maarten.lankhorst, mripard, airlied,
simona
Cc: dri-devel, linux-fbdev, Thomas Zimmermann
Looking up glyph shapes with a signed char in drm_draw_get_char_bitmap()
is unsafe. It also does not support extended ASCII codes with values
larger than 127.
Add the new function font_data_glyph_buf() to the font-data helpers. It
looks up the correct glyph from font data or returns NULL if no such
glyph exists. Convert DRM's log and panic code to the new function. Also
cast the character code to support all 256 ASCII characters.
Tested with drm_log on bochs.
Thomas Zimmermann (4):
lib/fonts: Look up glyph data with font_data_glyph_buf()
drm/client: log: Look up glyph shape with font helper
drm/panic: Look up glyph shape with font helper
drm/draw: Remove unused helper drm_draw_get_char_bitmap()
drivers/gpu/drm/clients/drm_log.c | 10 ++++++----
drivers/gpu/drm/drm_draw_internal.h | 7 -------
drivers/gpu/drm/drm_panic.c | 6 ++++--
include/linux/font.h | 3 +++
lib/fonts/fonts.c | 31 +++++++++++++++++++++++++++++
5 files changed, 44 insertions(+), 13 deletions(-)
--
2.54.0
^ permalink raw reply
* [PATCH 1/4] lib/fonts: Look up glyph data with font_data_glyph_buf()
From: Thomas Zimmermann @ 2026-05-29 14:01 UTC (permalink / raw)
To: jfalempe, javierm, deller, maarten.lankhorst, mripard, airlied,
simona
Cc: dri-devel, linux-fbdev, Thomas Zimmermann
In-Reply-To: <20260529140759.529929-1-tzimmermann@suse.de>
Add font_data_glyph_buf() to retrieve a character's glyph data or NULL
otherwise. Console fonts can currently contain 256 or 512 glyphs. The
kernel-internal characters are of type char, unsigned short or unsigned
int. Catch all of them by accepting unsigned int. Callers possibly have
to cast from signed to unsigned types to reach all glyphs in a font.
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
---
include/linux/font.h | 3 +++
lib/fonts/fonts.c | 31 +++++++++++++++++++++++++++++++
2 files changed, 34 insertions(+)
diff --git a/include/linux/font.h b/include/linux/font.h
index 6845f02d739a..ea23b727388b 100644
--- a/include/linux/font.h
+++ b/include/linux/font.h
@@ -101,6 +101,9 @@ font_data_t *font_data_import(const struct console_font *font, unsigned int vpit
void font_data_get(font_data_t *fd);
bool font_data_put(font_data_t *fd);
unsigned int font_data_size(font_data_t *fd);
+const unsigned char *font_data_glyph_buf(font_data_t *fd,
+ unsigned int width, unsigned int vpitch,
+ unsigned int c);
bool font_data_is_equal(font_data_t *lhs, font_data_t *rhs);
int font_data_export(font_data_t *fd, struct console_font *font, unsigned int vpitch);
diff --git a/lib/fonts/fonts.c b/lib/fonts/fonts.c
index f5d5333450a0..4fc66722d00d 100644
--- a/lib/fonts/fonts.c
+++ b/lib/fonts/fonts.c
@@ -178,6 +178,37 @@ unsigned int font_data_size(font_data_t *fd)
}
EXPORT_SYMBOL_GPL(font_data_size);
+static unsigned int font_data_num_glyphs(font_data_t *fd, unsigned int width, unsigned int height)
+{
+ return font_data_size(fd) / font_glyph_size(width, height);
+}
+
+/**
+ * font_data_glyph_buf() - Returns the glyph for a specific character as raw bytes
+ * @fd: The font data
+ * @width: The glyph width in bits per scanline
+ * @vpitch: The number of scanlines per glyph
+ * @c: The character
+ *
+ * Glyphs start at fixed intervals within the font data. font_data_glyph_buf()
+ * returns the glyph shape of the specified character. If no such glyph
+ * exists in the font, it returns NULL.
+ *
+ * Returns:
+ * The character's raw glyph shape, or NULL if no glyph exists for the character. The
+ * provided buffer is read-only.
+ */
+const unsigned char *font_data_glyph_buf(font_data_t *fd,
+ unsigned int width, unsigned int vpitch,
+ unsigned int c)
+{
+ if (c >= font_data_num_glyphs(fd, width, vpitch))
+ return NULL;
+
+ return font_data_buf(fd) + font_glyph_size(width, vpitch) * c;
+}
+EXPORT_SYMBOL_GPL(font_data_glyph_buf);
+
/**
* font_data_is_equal - Compares font data for equality
* @lhs: Left-hand side font data
--
2.54.0
^ permalink raw reply related
* Re: [PATCH v2 2/6] mfd: lm3533: Convert to use OF bindings
From: Jonathan Cameron @ 2026-05-29 13:10 UTC (permalink / raw)
To: Svyatoslav Ryhel
Cc: Lee Jones, Daniel Thompson, Jingoo Han, Pavel Machek, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, David Lechner, Nuno Sá,
Andy Shevchenko, Helge Deller, Johan Hovold, dri-devel,
linux-leds, devicetree, linux-kernel, linux-iio, linux-fbdev
In-Reply-To: <CAPVz0n1u0z35rP8vUKjAzW_mrPm9yeMjK_-nKbyctUvQik6ECw@mail.gmail.com>
> > > > > > if (device_property_present(dev, "ti,resistor-value-ohm"))
> > > > > > ret = device_property_read_u32();
> > > > > > if (ret) //corrupt property in some fashion
> > > > > > return ret;
> > > > > > } else {
> > > > > > //set default
> > > > > > }
> > > > > > If there is no default then check it unconditionally.
> > > > >
> > > > > default value is LM3533_ALS_RESISTOR_MIN and if no property is present
> > > > > clamp will ensure that als->r_select will be set to
> > > > > LM3533_ALS_RESISTOR_MIN
> > > >
> > > > I don't see that default in the binding doc and relying in the 0 being clamped
> > > > isn't particularly readable - I'd set it explicitly.
> > > >
> > >
> > > Oh, ye, my bad. Schema enforces one of props to be present and if pwn
> > > is present then resistor is ignored. What if I move resistor reading,
> > > clamping and conversion under !als->pwm_mode check? Then resistor must
> > > be present and hence must be checked unconditionally.
> >
> > Sounds good.
> >
> > >
> > > Additionally, I can comment original lm3533_als_setup with #if 0
> > > #endif then git formatting will be much cleaner and easier to review,
> > > and once we all come to result I will just remove entire commented
> > > block and Lee can pick clean commits.
> >
> > No don't do that. If you flatten the two helpers as a precursor patch
> > then the changes in here will be easier to review anyway.
> >
>
> By "flatten the two helpers" you mean incorporate
> lm3533_als_set_input_mode and lm3533_als_set_resistor into
> lm3533_als_setup first and then convert it to use DT? I am asking,
> just to be sure.
>
yes
> > > > > > > @@ -852,25 +825,28 @@ static int lm3533_als_probe(struct platform_device *pdev)
> > > > > > > indio_dev->channels = lm3533_als_channels;
> > > > > > > indio_dev->num_channels = ARRAY_SIZE(lm3533_als_channels);
> > > > > > > indio_dev->name = dev_name(&pdev->dev);
> > > > > > > - iio_device_set_parent(indio_dev, pdev->dev.parent);
> > > > > >
> > > > > > I'm not sure why this was there in the first place. Hence not sure if it
> > > > > > is safe to remove.
> > > > > >
> > > > >
> > > > > This is directly related to OF conversion. The iio_device_set_parent
> > > > > bound indio_dev to parent, and it causes problems with OF now since
> > > > > als output has its own node and binding it to parent if wrong. Same
> > > > > story for backlight and leds btw.
> > > >
> > > > Is there any risk anyone was using the canonical path to get to the iio dev?
> > > > /sys/bus/platform/devices/..../iio\:deviceX
> > > > This is technically an ABI change be it a subtle one.
> > > >
> > >
> > > Linux kernel has no users of this driver, and it is in "stale" state
> > > for more then 2 years (maybe even longer). I have cc'd Johan Hovold.
> > >
> > > https://lore.kernel.org/lkml/ZmBcvtLCzllQDWVX@hovoldconsulting.com/
> > >
> > > This this 2 y. o. discussion and there were no actions ore movements.
> > > I assume this driver in its current form has no more users. This does
> > > not mean that it cannot be revived though.
> >
> > So, just to check, are you a user of this code or is this more trying to
> > help out with old code?
> >
>
> I am not insane enough to get myself into all this conversion if I did
> not need it. This is one of 2 remaining gaps in support of LG
> P880/P895 I own and support. I would really like to finally mainline
> all the patches I have locally since maintaining them becomes quite
> troublesome with time and additional patches layering on top.
Excellent! There are some odd people out there who do start on this
sort of thing despite no personal use case :)
Jonathan
^ permalink raw reply
* Re: [PATCH v3 1/2] dt-bindings: leds: backlight: document the SY7758 6-channel High Efficiency LED Driver
From: Neil Armstrong @ 2026-05-29 12:50 UTC (permalink / raw)
To: Daniel Thompson
Cc: Lee Jones, Jingoo Han, Pavel Machek, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Helge Deller, dri-devel,
linux-leds, devicetree, linux-kernel, linux-fbdev, KancyJoe,
Krzysztof Kozlowski
In-Reply-To: <ahlr5PnX5O0tEd6G@aspen.lan>
On 5/29/26 12:35, Daniel Thompson wrote:
> On Fri, May 29, 2026 at 12:16:07PM +0200, Neil Armstrong wrote:
>> On 5/29/26 12:07, Daniel Thompson wrote:
>>> On Tue, May 19, 2026 at 10:43:38AM +0200, Neil Armstrong wrote:
>>>> Document the Silergy SY7758 6-channel High Efficiency LED Driver
>>>> used for backlight brightness control.
>>>>
>>>> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
>>>> Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
>>>> ---
>>>> .../bindings/leds/backlight/silergy,sy7758.yaml | 53 ++++++++++++++++++++++
>>>> 1 file changed, 53 insertions(+)
>>>>
>>>> diff --git a/Documentation/devicetree/bindings/leds/backlight/silergy,sy7758.yaml b/Documentation/devicetree/bindings/leds/backlight/silergy,sy7758.yaml
>>>> new file mode 100644
>>>> index 000000000000..80e978d691c2
>>>> --- /dev/null
>>>> +++ b/Documentation/devicetree/bindings/leds/backlight/silergy,sy7758.yaml
>>>> @@ -0,0 +1,53 @@
>>>> +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
>>>> +%YAML 1.2
>>>> +---
>>>> +$id: http://devicetree.org/schemas/leds/backlight/silergy,sy7758.yaml#
>>>> +$schema: http://devicetree.org/meta-schemas/core.yaml#
>>>> +
>>>> +title: Silergy SY7758 6-channel High Efficiency LED Driver
>>>> +
>>>> +maintainers:
>>>> + - Neil Armstrong <neil.armstrong@linaro.org>
>>>> +
>>>> +description:
>>>> + Silergy SY7758 is a high efficiency 6-channels LED backlight
>>>> + driver with I2C brightness control.
>>>> +
>>>> +allOf:
>>>> + - $ref: common.yaml#
>>>> +
>>>> +properties:
>>>> + compatible:
>>>> + const: silergy,sy7758
>>>> +
>>>> + reg:
>>>> + maxItems: 1
>>>> +
>>>> + vddio-supply: true
>>>> +
>>>> + enable-gpios:
>>>> + maxItems: 1
>>>> +
>>>> +required:
>>>> + - compatible
>>>> + - reg
>>>> + - vddio-supply
>>>
>>> Sorry for missing this in v2 but is vddio-supply really a required
>>> property?
>>>
>>> It's unusual for supplies to be mandatory (and the it is not mandatory
>>> in the driver implementation).
>>
>> This device is a little bit special, the VDDIO regulator is used to provide
>> power for the I/O via the enable input, so basically the enable gpio power
>> level is provided by VDDIO.
>
> I don't follow. The EN pin acts as both VDDIO and as an enable but it's
> still effectively a power rail isn't it (albeit one with very low current
> draw).
Here's the datasheet description:
```
Dual-purpose pin serving both as a chip enable and as a power supply
reference for PWM, SDA, and SCL inputs.
```
The VDD input is directly provided by the panel, so Linux has no control
of it so I haven't added it.
>
> It looked to me like the correct way to model to two power rails
> going into the chip is vdd-supply (main power supply) and vddio-supply
> (EN/VDDIO) I don't understand why a single pin needs both a regulator
> *and* a GPIO in the DT bindings?
I don't have a the schematics of the board, but as I understood one gpio is
actually enabling an regulator which provides power to the IC (vddio) and
a second gpio will either drive the EN signal to GND or VDDIO to provide a
clean rising edge on the EN pin.
So it's not really 2 regulators, and having regulators means the enable
signal can be shared and would have regulator characteristics which it hasn't.
>
>> This is the recommended way from the datasheet, and I assume it will be used
>> like that on other platforms (if it exists...)
>>
>> This is why it's mandatory and enabled first before setting the enable pin.
>
> It's not mandatory for the C implementation. devm_regulator_get_enable()
> will provide a dummy regulator if the property is omitted.
So yeah if you prefer I'll re-spin with the vddio regulator as optional
because between both, the VDDIO is the only which could be shared with
other devices or always-on.
Neil
>
>
> Daniel.
^ permalink raw reply
* Re: [PATCH v2 5/6] video: backlight: lm3533_bl: Set initial mapping mode from DT
From: Daniel Thompson @ 2026-05-29 11:40 UTC (permalink / raw)
To: Svyatoslav Ryhel
Cc: Lee Jones, Daniel Thompson, Jingoo Han, Pavel Machek, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Jonathan Cameron,
David Lechner, Nuno Sá, Andy Shevchenko, Helge Deller,
Johan Hovold, dri-devel, linux-leds, devicetree, linux-kernel,
linux-iio, linux-fbdev
In-Reply-To: <CAPVz0n0kpYBACOo=YyNk31KGwBEoyrf+dii8V6QY4iRCGd2PNQ@mail.gmail.com>
On Fri, May 29, 2026 at 02:17:00PM +0300, Svyatoslav Ryhel wrote:
> пт, 29 трав. 2026 р. о 14:10 Daniel Thompson <daniel@riscstar.com> пише:
> >
> > On Thu, May 28, 2026 at 04:51:22PM +0300, Svyatoslav Ryhel wrote:
> > > Add support to obtain the initial mapping mode from DT instead of leaving
> > > it unconfigured. Additionally, update the linear sysfs code, which uses a
> > > similar coding pattern.
> >
> > Words like "additionally" in a patch description can be a sign the patch
> > should actually be two patches. In this case the patch would be a lot
> > easier to read if you cleaned up the linear sysfs code (patch N) and then
> > added the new DT logic (patch N+1).
> >
>
> I looked into this in reverse. My goal was to add DT logic I don't
> case how sysfs works. My code matched with what sysfs does I just
> included sysfs change as well. I might better drop sysfs changes
> entirely since with such pace this patchset will inflate from 6 to 15
> and beyond.
Not sure about that. The clean up is good and introducing the new
BIT(2 * n + 1) macro does need to be used pervasively or there's no
point in adding it.
Daniel.
^ permalink raw reply
* Re: [PATCH v2] staging: sm750fb: rename pv_reg to io_base
From: neha arora @ 2026-05-29 11:28 UTC (permalink / raw)
To: Dan Carpenter
Cc: sudipm.mukherjee, teddy.wang, gregkh, linux-fbdev, linux-staging,
linux-kernel
In-Reply-To: <CAOWJOpvJnSeS=1sO2mujC9tNi9_cQGgJ6S0j6xvkAp8KRnudjg@mail.gmail.com>
I have submitted patch v3 with note and Signed-off-by line
Regards,
Onish
On Fri, May 29, 2026 at 4:50 PM neha arora <neharora23587@gmail.com> wrote:
>
> I have submitted patch v3 with note and Signed-off-by line.
>
> Regards,
> Onish
>
> On Fri, May 29, 2026 at 4:11 PM Dan Carpenter <error27@gmail.com> wrote:
>>
>> On Fri, May 29, 2026 at 03:22:33PM +0530, Onish Sharma wrote:
>> > Rename pv_reg to io_base to follow kernel naming style and improve
>> > readability.
>> >
>> > No functional changes intended.
>>
>> Run your patches through checkpatch. Also v2 patches need to be sent
>> in a specific format. This should be [PATCH v2 1/2]
>>
>> https://staticthinking.wordpress.com/2022/07/27/how-to-send-a-v2-patch/
>>
>> > ---
>> ^^^
>> There needs to be a note here to say what changed.
>>
>> regards,
>> dan carpenter
>>
^ permalink raw reply
* Re: [PATCH v2] staging: sm750fb: remove unused variable
From: neha arora @ 2026-05-29 11:25 UTC (permalink / raw)
To: Dan Carpenter
Cc: sudipm.mukherjee, teddy.wang, gregkh, linux-fbdev, linux-staging,
linux-kernel
In-Reply-To: <ahlszyY6Nd9ANz-X@stanley.mountain>
Hi Dan,
After looking into the structural dependencies and the cross-casting
between init_status and initchip_param, I've decided that this
refactoring is outside the scope of what I want to work on at this
time.
Please feel free to drop my previous patch. I'm going to shift my
focus to other areas.
Regards,
Onish
On Fri, May 29, 2026 at 4:09 PM Dan Carpenter <error27@gmail.com> wrote:
>
> On Fri, May 29, 2026 at 03:42:42PM +0530, Onish Sharma wrote:
> > Remove the set_all_eng_off flag and its associated cleanup logic.
> > The variable is redundant as the hardware should be initialized to a
> > known state regardless of prior usage.
> >
> > Suggested-by: Dan Carpenter <error27@gmail.com>
> > Signed-off-by: Onish Sharma <neharora23587@gmail.com>
> > ---
>
> Sorry, miscommunication. This breaks the driver. This is also a bit
> more involved than I thought...
>
> There are two structs:
>
> struct init_status {
> ushort power_mode;
> /* below three clocks are in unit of MHZ*/
> ushort chip_clk;
> ushort mem_clk;
> ushort master_clk;
> ushort setAllEngOff;
> ushort reset_memory;
> };
>
> And struct initchip_param. The initchip_param is exactly the same but
> with all the struct members renamed and comments added. They have to
> match because we cast back and forth.
>
> Why do we have two different struct that have to be the same? You might
> think it is for API, but as near as I can see that is not the case.
> Maybe it was at some point? We should get rid of one struct. Which
> everyone is API is the one we should keep. If neither is API then get
> rid of init_status and keep initchip_param.
>
> After that we can talk about getting rid of setAllEngOff/set_all_eng_off.
>
> regards,
> dan carpenter
>
^ permalink raw reply
* [PATCH v3] staging: sm750fb: rename pv_reg to io_base
From: Onish Sharma @ 2026-05-29 11:19 UTC (permalink / raw)
To: sudipm.mukherjee, teddy.wang, gregkh
Cc: linux-fbdev, linux-staging, linux-kernel, Onish Sharma
Rename pv_reg to io_base to follow kernel naming style and improve
readability.
No functional changes intended.
Signed-off-by: Onish Sharma <neharora23587@gmail.com>
---
Changes in v3:
- Added mandatory Signed-off-by line.
- Rename pv_reg to io_base to remove hungarian notation
drivers/staging/sm750fb/sm750.c | 4 ++--
drivers/staging/sm750fb/sm750.h | 2 +-
drivers/staging/sm750fb/sm750_hw.c | 12 ++++++------
3 files changed, 9 insertions(+), 9 deletions(-)
diff --git a/drivers/staging/sm750fb/sm750.c b/drivers/staging/sm750fb/sm750.c
index 716a8935f58d..c2d2864f135b 100644
--- a/drivers/staging/sm750fb/sm750.c
+++ b/drivers/staging/sm750fb/sm750.c
@@ -743,7 +743,7 @@ static int lynxfb_set_fbinfo(struct fb_info *info, int index)
* must be set after crtc member initialized
*/
crtc->cursor.offset = crtc->o_screen + crtc->vidmem_size - 1024;
- crtc->cursor.mmio = sm750_dev->pv_reg +
+ crtc->cursor.mmio = sm750_dev->io_base +
0x800f0 + (int)crtc->channel * 0x140;
crtc->cursor.max_h = 64;
@@ -1047,7 +1047,7 @@ static void lynxfb_pci_remove(struct pci_dev *pdev)
sm750fb_framebuffer_release(sm750_dev);
arch_phys_wc_del(sm750_dev->mtrr.vram);
- iounmap(sm750_dev->pv_reg);
+ iounmap(sm750_dev->io_base);
iounmap(sm750_dev->vmem);
pci_release_region(pdev, 1);
kfree(g_settings);
diff --git a/drivers/staging/sm750fb/sm750.h b/drivers/staging/sm750fb/sm750.h
index e8885133da2e..c42800313c6a 100644
--- a/drivers/staging/sm750fb/sm750.h
+++ b/drivers/staging/sm750fb/sm750.h
@@ -97,7 +97,7 @@ struct sm750_dev {
unsigned long vidreg_start;
__u32 vidmem_size;
__u32 vidreg_size;
- void __iomem *pv_reg;
+ void __iomem *io_base;
unsigned char __iomem *vmem;
/* locks*/
spinlock_t slock;
diff --git a/drivers/staging/sm750fb/sm750_hw.c b/drivers/staging/sm750fb/sm750_hw.c
index 95f797e5776a..dc1118808b4f 100644
--- a/drivers/staging/sm750fb/sm750_hw.c
+++ b/drivers/staging/sm750fb/sm750_hw.c
@@ -23,18 +23,18 @@ int hw_sm750_map(struct sm750_dev *sm750_dev, struct pci_dev *pdev)
}
/* now map mmio and vidmem */
- sm750_dev->pv_reg =
+ sm750_dev->io_base =
ioremap(sm750_dev->vidreg_start, sm750_dev->vidreg_size);
- if (!sm750_dev->pv_reg) {
+ if (!sm750_dev->io_base) {
dev_err(&pdev->dev, "mmio failed\n");
ret = -EFAULT;
goto err_release_region;
}
- sm750_dev->accel.dpr_base = sm750_dev->pv_reg + DE_BASE_ADDR_TYPE1;
- sm750_dev->accel.dp_port_base = sm750_dev->pv_reg + DE_PORT_ADDR_TYPE1;
+ sm750_dev->accel.dpr_base = sm750_dev->io_base + DE_BASE_ADDR_TYPE1;
+ sm750_dev->accel.dp_port_base = sm750_dev->io_base + DE_PORT_ADDR_TYPE1;
- mmio750 = sm750_dev->pv_reg;
+ mmio750 = sm750_dev->io_base;
sm750_set_chip_type(sm750_dev->devid, sm750_dev->revid);
sm750_dev->vidmem_start = pci_resource_start(pdev, 0);
@@ -58,7 +58,7 @@ int hw_sm750_map(struct sm750_dev *sm750_dev, struct pci_dev *pdev)
return 0;
err_unmap_reg:
- iounmap(sm750_dev->pv_reg);
+ iounmap(sm750_dev->io_base);
err_release_region:
pci_release_region(pdev, 1);
return ret;
--
2.54.0
^ permalink raw reply related
* Re: [PATCH v2 5/6] video: backlight: lm3533_bl: Set initial mapping mode from DT
From: Svyatoslav Ryhel @ 2026-05-29 11:17 UTC (permalink / raw)
To: Daniel Thompson
Cc: Lee Jones, Daniel Thompson, Jingoo Han, Pavel Machek, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Jonathan Cameron,
David Lechner, Nuno Sá, Andy Shevchenko, Helge Deller,
Johan Hovold, dri-devel, linux-leds, devicetree, linux-kernel,
linux-iio, linux-fbdev
In-Reply-To: <ahl0La8OQHXAlV3m@aspen.lan>
пт, 29 трав. 2026 р. о 14:10 Daniel Thompson <daniel@riscstar.com> пише:
>
> On Thu, May 28, 2026 at 04:51:22PM +0300, Svyatoslav Ryhel wrote:
> > Add support to obtain the initial mapping mode from DT instead of leaving
> > it unconfigured. Additionally, update the linear sysfs code, which uses a
> > similar coding pattern.
>
> Words like "additionally" in a patch description can be a sign the patch
> should actually be two patches. In this case the patch would be a lot
> easier to read if you cleaned up the linear sysfs code (patch N) and then
> added the new DT logic (patch N+1).
>
I looked into this in reverse. My goal was to add DT logic I don't
case how sysfs works. My code matched with what sysfs does I just
included sysfs change as well. I might better drop sysfs changes
entirely since with such pace this patchset will inflate from 6 to 15
and beyond.
>
> Daniel.
^ permalink raw reply
* Re: [PATCH v2 5/6] video: backlight: lm3533_bl: Set initial mapping mode from DT
From: Daniel Thompson @ 2026-05-29 11:10 UTC (permalink / raw)
To: Svyatoslav Ryhel
Cc: Lee Jones, Daniel Thompson, Jingoo Han, Pavel Machek, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Jonathan Cameron,
David Lechner, Nuno Sá, Andy Shevchenko, Helge Deller,
Johan Hovold, dri-devel, linux-leds, devicetree, linux-kernel,
linux-iio, linux-fbdev
In-Reply-To: <20260528135123.103745-6-clamor95@gmail.com>
On Thu, May 28, 2026 at 04:51:22PM +0300, Svyatoslav Ryhel wrote:
> Add support to obtain the initial mapping mode from DT instead of leaving
> it unconfigured. Additionally, update the linear sysfs code, which uses a
> similar coding pattern.
Words like "additionally" in a patch description can be a sign the patch
should actually be two patches. In this case the patch would be a lot
easier to read if you cleaned up the linear sysfs code (patch N) and then
added the new DT logic (patch N+1).
Daniel.
^ permalink raw reply
* Re: [PATCH v2 2/6] mfd: lm3533: Convert to use OF bindings
From: Svyatoslav Ryhel @ 2026-05-29 11:06 UTC (permalink / raw)
To: Daniel Thompson
Cc: Lee Jones, Daniel Thompson, Jingoo Han, Pavel Machek, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Jonathan Cameron,
David Lechner, Nuno Sá, Andy Shevchenko, Helge Deller,
Johan Hovold, dri-devel, linux-leds, devicetree, linux-kernel,
linux-iio, linux-fbdev
In-Reply-To: <ahlxvGRVFDFrTUN3@aspen.lan>
пт, 29 трав. 2026 р. о 14:00 Daniel Thompson <daniel@riscstar.com> пише:
>
> On Thu, May 28, 2026 at 04:51:19PM +0300, Svyatoslav Ryhel wrote:
> > Since there are no users of this driver via platform data, remove the
> > platform data support and switch to using Device Tree bindings.
> > Additionally, optimize functions used only by platform data.
>
> The last sentence is a little vague and makes us have to hunt for the
> changes in a relatively large patch. If it is referring to the change to
> common up the init and update code then it's would better to say that
> explicitly!
>
If I understood Jonathan properly, the last sentence will get its own patch.
> > Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
> > ---
> > drivers/iio/light/lm3533-als.c | 95 ++++------
> > drivers/leds/leds-lm3533.c | 51 ++++--
> > drivers/mfd/lm3533-core.c | 268 ++++++++++------------------
> > drivers/video/backlight/lm3533_bl.c | 52 ++++--
> > include/linux/mfd/lm3533.h | 51 +-----
>
> Just one comment for backlight, below:
>
> > diff --git a/drivers/video/backlight/lm3533_bl.c b/drivers/video/backlight/lm3533_bl.c
> > index babfd3ceec86..42da652df58d 100644
> > --- a/drivers/video/backlight/lm3533_bl.c
> > +++ b/drivers/video/backlight/lm3533_bl.c
> > @@ -295,13 +293,20 @@ static int lm3533_bl_probe(struct platform_device *pdev)
> > bl->cb.id = lm3533_bl_get_ctrlbank_id(bl);
> > bl->cb.dev = NULL; /* until registered */
> >
> > + name = devm_kasprintf(&pdev->dev, GFP_KERNEL, "%s-%d",
> > + pdev->name, pdev->id);
> > + if (!name)
> > + return -ENOMEM;
> > +
> > memset(&props, 0, sizeof(props));
> > props.type = BACKLIGHT_RAW;
> > props.max_brightness = LM3533_BL_MAX_BRIGHTNESS;
> > - props.brightness = pdata->default_brightness;
>
> Given the big changes to the driver is there any chance of putting a
> good value in props.scale (BACKLIGHT_SCALE_LINEAR or
> BACKLIGHT_SCALE_NON_LINEAR)?
>
> If the difference between 50% and 100% *looks* like 50% then the scale is
> non-linear (since humn perception of brightness is not linear).
>
Yes! But not in this patch. This patchset has a dedicated patch
implementing linear and non-linear configuration from tree which may
include this configuration as well. No guarantees though, but I will
keep in mind this request. Thanks!
>
> Daniel.
^ 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