[PATCH] Keyboard backlight driver for Oct 2005 PowerBooks

This driver provides an interface to the keyboard backlight on Oct 2005
PowerBooks, which have the backlight behind the PMU. This driver doesn't
support the I²C variant used in earlier PowerBooks.

Signed-off-by: Michael Hanselmann <redacted>

---
diff -Nrup --exclude-from linux-exclude-from linux-2.6.18-rc4-git1.orig/drivers/macintosh/Kconfig linux-2.6.18-rc4-git1/drivers/macintosh/Kconfig

--- linux-2.6.18-rc4-git1.orig/drivers/macintosh/Kconfig	2006-08-26 22:24:36.000000000 +0200
+++ linux-2.6.18-rc4-git1/drivers/macintosh/Kconfig	2006-08-27 02:39:05.000000000 +0200

@@ -99,6 +99,14 @@ config ADB_PMU_LED_IDE
 	  This option makes the front LED default to the IDE trigger
 	  so that it blinks on IDE activity.
 
+config ADB_PMU_ALS_LED
+	bool "Support for keyboard backlight"
+	depends on ADB_PMU
+	select NEW_LEDS
+	select LEDS_CLASS
+	help
+	  Support for the keyboard backlight on Oct 2005 PowerBooks.
+
 config PMAC_SMU
 	bool "Support for SMU  based PowerMacs"
 	depends on PPC_PMAC64

diff -Nrup --exclude-from linux-exclude-from linux-2.6.18-rc4-git1.orig/drivers/macintosh/Makefile linux-2.6.18-rc4-git1/drivers/macintosh/Makefile

--- linux-2.6.18-rc4-git1.orig/drivers/macintosh/Makefile	2006-08-26 22:24:36.000000000 +0200
+++ linux-2.6.18-rc4-git1/drivers/macintosh/Makefile	2006-08-27 02:39:55.000000000 +0200

@@ -13,6 +13,7 @@ obj-$(CONFIG_ANSLCD)		+= ans-lcd.o
 
 obj-$(CONFIG_ADB_PMU)		+= via-pmu.o via-pmu-event.o
 obj-$(CONFIG_ADB_PMU_LED)	+= via-pmu-led.o
+obj-$(CONFIG_ADB_PMU_ALS_LED)	+= via-pmu-als-led.o
 obj-$(CONFIG_PMAC_BACKLIGHT)	+= via-pmu-backlight.o
 obj-$(CONFIG_ADB_CUDA)		+= via-cuda.o
 obj-$(CONFIG_PMAC_APM_EMU)	+= apm_emu.o

diff -Nrup --exclude-from linux-exclude-from linux-2.6.18-rc4-git1.orig/drivers/macintosh/via-pmu-als-led.c linux-2.6.18-rc4-git1/drivers/macintosh/via-pmu-als-led.c

--- linux-2.6.18-rc4-git1.orig/drivers/macintosh/via-pmu-als-led.c	1970-01-01 01:00:00.000000000 +0100
+++ linux-2.6.18-rc4-git1/drivers/macintosh/via-pmu-als-led.c	2006-08-27 04:01:16.000000000 +0200

@@ -0,0 +1,107 @@
+/*
+ * Driver for keyboard backlight on Oct 2005 PowerBooks
+ *
+ * Copyright 2006 Michael Hanselmann <linux-kernel@hansmi.ch>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ */
+
+#include <linux/types.h>
+#include <linux/kernel.h>
+#include <linux/device.h>
+#include <linux/leds.h>
+#include <linux/adb.h>
+#include <linux/pmu.h>
+#include <asm/prom.h>
+
+static spinlock_t ams_led_pmu_lock;
+static struct adb_request pmu_req = {
+	.complete = 1,
+};
+static int sleeping;
+static int pmu_cmd;
+
+static void als_led_pmu_set(struct led_classdev *led_cdev,
+		enum led_brightness brightness)
+{
+	unsigned long flags;
+
+	spin_lock_irqsave(&ams_led_pmu_lock, flags);
+
+	if (pmu_req.complete && !sleeping) {
+		if (brightness < 0)
+			brightness = 0;
+		else if (brightness > 255)
+			brightness = 255;
+
+		pmu_request(&pmu_req, NULL, 4, pmu_cmd, 0, 0, brightness);
+	}
+
+ 	spin_unlock_irqrestore(&ams_led_pmu_lock, flags);
+}
+
+static struct led_classdev als_led = {
+	.name = "als-led-pmu",
+	.brightness_set = als_led_pmu_set,
+};
+
+#ifdef CONFIG_PM
+static int als_led_pmu_sleep_call(struct pmu_sleep_notifier *self, int when)
+{
+	unsigned long flags;
+
+	spin_lock_irqsave(&ams_led_pmu_lock, flags);
+
+	switch (when) {
+	case PBOOK_SLEEP_REQUEST:
+		sleeping = 1;
+		break;
+	case PBOOK_WAKE:
+		sleeping = 0;
+		break;
+	default:
+		/* do nothing */
+		break;
+	}
+
+	spin_unlock_irqrestore(&ams_led_pmu_lock, flags);
+
+	return PBOOK_SLEEP_OK;
+}
+
+static struct pmu_sleep_notifier als_led_pmu_sleep_notif = {
+	.notifier_call = als_led_pmu_sleep_call,
+};
+#endif
+
+static int __init als_led_pmu_init(void)
+{
+	struct device_node *np;
+	u32 *reg;
+
+	np = of_find_node_by_name(NULL, "als-controls");
+	if (!np)
+		return -ENODEV;
+
+	reg = (u32*)get_property(np, "reg", NULL);
+	if (!reg || !*reg)
+		return -ENODEV;
+
+	pmu_cmd = ((*reg) >> 8) & 0xff;
+
+	of_node_put(np);
+
+	spin_lock_init(&ams_led_pmu_lock);
+
+#ifdef CONFIG_PM
+	pmu_register_sleep_notifier(&als_led_pmu_sleep_notif);
+#endif
+
+	return led_classdev_register(NULL, &als_led);
+}
+
+late_initcall(als_led_pmu_init);

On Sun, 2006-08-27 at 14:30 +0200, Michael Hanselmann wrote:

This driver provides an interface to the keyboard backlight on Oct 2005
PowerBooks, which have the backlight behind the PMU. This driver doesn't
support the I²C variant used in earlier PowerBooks.

Signed-off-by: Michael Hanselmann <redacted>

Why would we need a driver ? Userland can emit PMU commands directly...
At least, if we do a driver, it should provide a common interface to
both PMU and i2c based LMUs

Ben.

On Mon, Aug 28, 2006 at 08:34:23AM +1000, Benjamin Herrenschmidt wrote:

Why would we need a driver ? Userland can emit PMU commands directly...

Drivers are there to abstract hardware. Userland shouldn't know about
hardware specific commands (PMU commands in this case).

It would make it much simpler for programs to use these devices, because
not each of them has to implement everything needed to locate the device
and control it.

pbbuttonsd supports both the I²C and PMU variant. The code is a mess
there and a generic driver would help to clean it up. And yes, I'm
partly responsible for it, since I supplied the original patch for the
PMU keyboard backlight support in pbbuttonsd.

Maybe controlling the keyboard backlight could be moved to its own
program anyway, because the algorithm used by pbbuttonsd isn't appealing
to all people. But those are just ideas.

Oh, and using the LED class allows users to attach it to some trigger.
Maybe someone wants to use it as the IDE LED. :-)

At least, if we do a driver, it should provide a common interface to
both PMU and i2c based LMUs

Yeah, I figured after sending it. You'll hear again from me once I got
my hands on an I²C backlight. Something like the AMS driver would be
nice.

On Mon, 2006-08-28 at 01:07 +0200, Michael Hanselmann wrote:

On Mon, Aug 28, 2006 at 08:34:23AM +1000, Benjamin Herrenschmidt wrote:

quoted

Why would we need a driver ? Userland can emit PMU commands directly...

Drivers are there to abstract hardware. Userland shouldn't know about
hardware specific commands (PMU commands in this case).

This is a bit of a broad statement :) If I were to follow you, thinks
like USB scanner or printer drivers should all be in the kernel :)
Well... they happen not to be.

Only drivers providing services to the kernel itself (block,
network, ...) or doing things like direct DMA, interrupts, etc... that
aren't useable from an exposed userland interfaces need to be in the
kernel.

It would make it much simpler for programs to use these devices, because
not each of them has to implement everything needed to locate the device
and control it.

Then the best is to do a library.

pbbuttonsd supports both the I²C and PMU variant. The code is a mess
there and a generic driver would help to clean it up. And yes, I'm
partly responsible for it, since I supplied the original patch for the
PMU keyboard backlight support in pbbuttonsd.

Maybe controlling the keyboard backlight could be moved to its own
program anyway, because the algorithm used by pbbuttonsd isn't appealing
to all people. But those are just ideas.

Yeah, separate program or library would do the trick just fine. Also,
your driver doesn't handle reading the light sensors, does it ?

Oh, and using the LED class allows users to attach it to some trigger.
Maybe someone wants to use it as the IDE LED. :-)

That would be just insane :)

quoted

At least, if we do a driver, it should provide a common interface to
both PMU and i2c based LMUs

Yeah, I figured after sending it. You'll hear again from me once I got
my hands on an I²C backlight. Something like the AMS driver would be
nice.

I still think this has little to do in the kernel ...

Ben.

On Mon, Aug 28, 2006 at 09:11:03AM +1000, Benjamin Herrenschmidt wrote:

quoted

Drivers are there to abstract hardware. Userland shouldn't know about
hardware specific commands (PMU commands in this case).

This is a bit of a broad statement :) If I were to follow you, thinks
like USB scanner or printer drivers should all be in the kernel :)
Well... they happen not to be.

True. But then again, a printer driver does little more than configuring
a single PWM value.

If there wasn't an I²C variant, we could even export these things as PMU
sub-devices. But there is one and a driver could easily hide these
differences from userland, because they simply don't matter there.

Then the best is to do a library.

There was some effort ongoing on that a few months ago (at least on
IRC). Was there anything coming out of it?

Yeah, separate program or library would do the trick just fine. Also,
your driver doesn't handle reading the light sensors, does it ?

No, it doesn't. The light sensor is a different device and doesn't
belong into a LED driver. I plan to do a driver for it separately.

So the target is to have one driver for backlight and one for sensors,
each handling the I²C and PMU variants. MacBooks have some other
variant, which could be included, theoretically. Lacking the hardware, I
can't do that, tough.

The main reason I did not do all at once is that I feared a discussion
like we have it now. I'm not going to invest much time for unused code
anymore like I did with the ctrl+click patch.

Greets,
Michael