On Wed, Jan 18, 2023 at 12:08:01PM +0000, Daniel Thompson wrote:

On Tue, Jan 17, 2023 at 11:44:08PM +0800, Jianhua Lu wrote:

quoted

Add support for Kinetic KTZ8866 backlight, which is used in
Xiaomi tablet, Mi Pad 5 series. This driver lightly based on
downstream implementation [1].
[1] https://github.com/MiCode/Xiaomi_Kernel_OpenSource/blob/elish-r-oss/drivers/video/backlight/ktz8866.c

Signed-off-by: Jianhua Lu <lujianhua000@gmail.com>
---
Changes in v2:
  - Add missing staitc modifier to ktz8866_write function.

Changes in v3:
  - Add 2022 to Copyright line.
  - Sort headers.
  - Remove meaningless comment.
  - Use definitions instead of hardcoding.
  - Add missing maintainer info.

Changes in v4:
  - Change 2022 to 2023.
  - Remove useless macro and enum.
  - Describe settings by devicetree.
  - Move header file to C file.
Changes in v5:
  - Change "2023" to "2022, 2023" in Copyright line.
  - Set scale property for backlight.

 MAINTAINERS                       |   6 +
 drivers/video/backlight/Kconfig   |   8 ++
 drivers/video/backlight/Makefile  |   1 +
 drivers/video/backlight/ktz8866.c | 201 ++++++++++++++++++++++++++++++
 4 files changed, 216 insertions(+)
 create mode 100644 drivers/video/backlight/ktz8866.c

diff --git a/MAINTAINERS b/MAINTAINERS
index 42fc47c6edfd..2084e74e1b58 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS

@@ -11674,6 +11674,12 @@ M:	John Hawley <warthog9@eaglescrag.net>
 S:	Maintained
 F:	tools/testing/ktest

+KTZ8866 BACKLIGHT DRIVER
+M:	Jianhua Lu <lujianhua000@gmail.com>
+S:	Maintained
+F:	Documentation/devicetree/bindings/leds/backlight/kinetic,ktz8866.yaml
+F:	drivers/video/backlight/ktz8866.c
+
 L3MDEV
 M:	David Ahern <dsahern@kernel.org>
 L:	netdev@vger.kernel.org

diff --git a/drivers/video/backlight/Kconfig b/drivers/video/backlight/Kconfig
index 936ba1e4d35e..2845fd7e33ad 100644
--- a/drivers/video/backlight/Kconfig
+++ b/drivers/video/backlight/Kconfig

@@ -190,6 +190,14 @@ config BACKLIGHT_KTD253
 	  which is a 1-wire GPIO-controlled backlight found in some mobile
 	  phones.

+config BACKLIGHT_KTZ8866
+	tristate "Backlight Driver for Kinetic KTZ8866"
+	depends on I2C
+	select REGMAP_I2C
+	help
+		Say Y to enabled the backlight driver for the Kinetic KTZ8866
+		found in Xiaomi Mi Pad 5 series.

s/enabled/enable/ (and sorry for spotting this one so late)

Get it.

quoted

+++ b/drivers/video/backlight/ktz8866.c

@@ -0,0 +1,201 @@

[...]
+static void ktz8866_init(struct ktz8866 *ktz)
+{
+	unsigned int val;
+
+	if(of_property_read_u32(ktz->client->dev.of_node, "current-num-sinks", &val))
+		ktz8866_write(ktz, BL_EN, BIT(val) - 1);
+	else
+		/* Enable all 6 current sinks if the number of current sinks isn't specifed. */
+		ktz8866_write(ktz, BL_EN, BIT(6) - 1);
+
+	if(of_property_read_u32(ktz->client->dev.of_node, "current-ramping-time-us", &val)) {
+		if(val <= 128) {
+			ktz8866_write(ktz, BL_CFG2, BIT(7) | (ilog2(val) << 3) | PWM_HYST);
+		} else {
+			ktz8866_write(ktz, BL_CFG2, BIT(7) | ((5 + val / 64) << 3) | PWM_HYST);
+		}

This code is interpreting current-ramping-time-us as milliseconds rather
than microseconds!

I know I used microseconds in the example I proposed in the feedback for
v4 DT bindings but "something like" means I am merely providing an
example (mostly I was intending to show that the units should be
included both in the property name *and* description).

It is up to you whether you fix the mismatch by changing the DT bindings
document to current-ramping-time-ms or change this code to accept
values in microseconds.

This is my mistake, sorry.

quoted

+	}
+
+	if(of_property_read_u32(ktz->client->dev.of_node, "led-ramping-time-us", &val)) {
+		unsigned int ramp_off_time = ilog2(val) + 1;
+		unsigned int ramp_on_time = ramp_off_time << 4;
+		ktz8866_write(ktz, BL_DIMMING, ramp_on_time | ramp_off_time);
+	}

Similarly, this code has not adopted the units specified in the
bindings documentation.

In this case 0 would map to 512us so if you decided to use milliseconds
you will need to add comment in the description saying that 0 will map
to 512us because the hardware cannot ramp faster than this!

Get it, thank you very much.

Daniel.