convert powermac ide blink to new led infrastructure
Subsystems (2)
PATCH 1/1 convert powermac ide blink to new led infrastructure
This patch removes the old pmac ide led blink code and adds generic LED subsystem support for the LED.
Ben: I removed the retry code that was present in the original. I guess LEDs aren't really too important but if it really is necessary please tell me and I'll add it back.
drivers/ide/Kconfig +0 -7
@@ -773,13 +773,6 @@ config BLK_DEV_IDEDMA_PMAC to transfer data to and from memory. Saying Y is safe and improves performance. -config BLK_DEV_IDE_PMAC_BLINK - bool "Blink laptop LED on drive activity" - depends on BLK_DEV_IDE_PMAC && ADB_PMU - help - This option enables the use of the sleep LED as a hard drive - activity LED. - config BLK_DEV_IDE_SWARM tristate "IDE for Sibyte evaluation boards" depends on SIBYTE_SB1xxx_SOC
drivers/ide/ppc/pmac.c +0 -125
143 lines not on this page · raw message
drivers/macintosh/Kconfig +10 -0
@@ -78,6 +78,16 @@ config ADB_PMU this device; you should do so if your machine is one of those mentioned above. +config ADB_PMU_LED + bool "Support for the Power/iBook front LED" + depends on LEDS_CLASS && ADB_PMU + help + Support the front LED on Power/iBooks as a generic LED that can + be triggered by any of the supported triggers. To get the + behaviour of the old CONFIG_BLK_DEV_IDE_PMAC_BLINK, select this + and the ide-disk LED trigger and configure appropriately through + sysfs. + config PMAC_SMU bool "Support for SMU based PowerMacs" depends on PPC_PMAC64
drivers/macintosh/Makefile +1 -0
@@ -12,6 +12,7 @@ obj-$(CONFIG_INPUT_ADBHID) += adbhid.o obj-$(CONFIG_ANSLCD) += ans-lcd.o obj-$(CONFIG_ADB_PMU) += via-pmu.o +obj-$(CONFIG_ADB_PMU_LED) += via-pmu-led.o obj-$(CONFIG_ADB_CUDA) += via-cuda.o obj-$(CONFIG_PMAC_APM_EMU) += apm_emu.o obj-$(CONFIG_PMAC_SMU) += smu.o
drivers/macintosh/via-pmu-led.c new file +80 -0
80 lines not on this page · raw message
drivers/macintosh/via-pmu-led.h new file +18 -0
@@ -0,0 +1,18 @@ +#ifndef __VIA_PMU_LED_H +#define __VIA_PMU_LED_H +#include <config/adb/pmu/led.h> + +#ifdef CONFIG_ADB_PMU_LED +extern int pmu_led_init (void ); +extern void pmu_led_exit (void ); +#else +static inline int pmu_led_init (void ) +{ +return 0 ; +} +static inline void pmu_led_exit (void ) +{ +} +#endif /* CONFIG_ADB_PMU_LED */ + +#endif /* __VIA_PMU_LED_H */
drivers/macintosh/via-pmu.c +16 -0
@@ -69,6 +69,8 @@#include <asm/open_pic.h> #endif +#include "via-pmu-led.h" +/* Some compile options */ #undef SUSPEND_USES_PMU#define DEBUG_SLEEP
@@ -2896,11 +2898,25 @@ static int __init init_pmu_sysfs(void)printk (KERN_ERR "Failed registering PMU sys driver\n" );return -ENODEV ; } +return 0 ; }subsys_initcall (init_pmu_sysfs); +static int __init init_pmu_led (void ) +{ +if (pmu_kind ==PMU_KEYLARGO_BASED ) { +if (pmu_led_init ()) { +printk (KERN_WARNING "via-pmu: LED failed to init\n" ); + } + } + +return 0 ; +} + +late_initcall (init_pmu_led); +EXPORT_SYMBOL (pmu_request);EXPORT_SYMBOL (pmu_queue_request);EXPORT_SYMBOL (pmu_poll);
[resent slightly different patch that adds a comment over the original version]
This patch removes the old pmac ide led blink code and adds generic LED subsystem support for the LED.
Ben: I removed the retry code that was present in the original. I guess LEDs aren't really too important but if it really is necessary please tell me and I'll add it back.
Also, I don't have any suspend handling things. It doesn't appear to be necessary, how do I find out?
drivers/ide/Kconfig +0 -7
@@ -773,13 +773,6 @@ config BLK_DEV_IDEDMA_PMAC to transfer data to and from memory. Saying Y is safe and improves performance. -config BLK_DEV_IDE_PMAC_BLINK - bool "Blink laptop LED on drive activity" - depends on BLK_DEV_IDE_PMAC && ADB_PMU - help - This option enables the use of the sleep LED as a hard drive - activity LED. - config BLK_DEV_IDE_SWARM tristate "IDE for Sibyte evaluation boards" depends on SIBYTE_SB1xxx_SOC
drivers/ide/ppc/pmac.c +0 -125
143 lines not on this page · raw message
drivers/macintosh/Kconfig +10 -0
@@ -78,6 +78,16 @@ config ADB_PMU this device; you should do so if your machine is one of those mentioned above. +config ADB_PMU_LED + bool "Support for the Power/iBook front LED" + depends on LEDS_CLASS && ADB_PMU + help + Support the front LED on Power/iBooks as a generic LED that can + be triggered by any of the supported triggers. To get the + behaviour of the old CONFIG_BLK_DEV_IDE_PMAC_BLINK, select this + and the ide-disk LED trigger and configure appropriately through + sysfs. + config PMAC_SMU bool "Support for SMU based PowerMacs" depends on PPC_PMAC64
drivers/macintosh/Makefile +1 -0
@@ -12,6 +12,7 @@ obj-$(CONFIG_INPUT_ADBHID) += adbhid.o obj-$(CONFIG_ANSLCD) += ans-lcd.o obj-$(CONFIG_ADB_PMU) += via-pmu.o +obj-$(CONFIG_ADB_PMU_LED) += via-pmu-led.o obj-$(CONFIG_ADB_CUDA) += via-cuda.o obj-$(CONFIG_PMAC_APM_EMU) += apm_emu.o obj-$(CONFIG_PMAC_SMU) += smu.o
drivers/macintosh/via-pmu-led.c new file +80 -0
80 lines not on this page · raw message
drivers/macintosh/via-pmu-led.h new file +18 -0
@@ -0,0 +1,18 @@ +#ifndef __VIA_PMU_LED_H +#define __VIA_PMU_LED_H +#include <config/adb/pmu/led.h> + +#ifdef CONFIG_ADB_PMU_LED +extern int pmu_led_init (void ); +extern void pmu_led_exit (void ); +#else +static inline int pmu_led_init (void ) +{ +return 0 ; +} +static inline void pmu_led_exit (void ) +{ +} +#endif /* CONFIG_ADB_PMU_LED */ + +#endif /* __VIA_PMU_LED_H */
drivers/macintosh/via-pmu.c +21 -0
@@ -69,6 +69,8 @@#include <asm/open_pic.h> #endif +#include "via-pmu-led.h" +/* Some compile options */ #undef SUSPEND_USES_PMU#define DEBUG_SLEEP
@@ -2896,11 +2898,30 @@ static int __init init_pmu_sysfs(void)printk (KERN_ERR "Failed registering PMU sys driver\n" );return -ENODEV ; } +return 0 ; }subsys_initcall (init_pmu_sysfs); +static int __init init_pmu_led (void ) +{ +/* Only enable this feature on KeyLargo based laptops, older +* laptops may support it (at least heathrow/paddington) but +* I don't feel like loading those venerable old machines with +* so much additional interrupt & PMU activity... +*/ +if (pmu_kind ==PMU_KEYLARGO_BASED ) { +if (pmu_led_init ()) { +printk (KERN_WARNING "via-pmu: LED failed to init\n" ); + } + } + +return 0 ; +} + +late_initcall (init_pmu_led); +EXPORT_SYMBOL (pmu_request);EXPORT_SYMBOL (pmu_queue_request);EXPORT_SYMBOL (pmu_poll);
drivers/macintosh/Kconfig config ADB_PMU · line 83
Quoted 4 lines · Johannes Berg
drivers/macintosh/Kconfig +3
-0+config ADB_PMU_LED + bool "Support for the Power/iBook front LED" + depends on LEDS_CLASS && ADB_PMU
come to think of it, that should probably be
depends on ADB_PMU
select LEDS_CLASS
since we should imho consider the led stuff as infrastructure for other stuff. Opinions?
johannes
Quoted 6 lines · Johannes Berg
[resent slightly different patch that adds a comment over the original version]
This patch removes the old pmac ide led blink code and adds generic LED subsystem support for the LED.
Quoted 6 lines
Ben: I removed the retry code that was present in the original. I guess LEDs aren't really too important but if it really is necessary please tell me and I'll add it back.
Also, I don't have any suspend handling things. It doesn't appear to be necessary, how do I find out?
Hrm... you find out the hard way in general ... we'll have to be careful with this one, maybe have the PMU driver stop the LED after the device suspend dance or do a sysdev with a suspend/resume and make sure that any pending LED request is complete. Also, your code isn't testing if the PMU request is still in progress before possibly sending another one ... that's a bit dangerous (and may cause the LED to get "stuck"). You can re-use a request once it's complete though. In addition, my PMU code was written to minimize spinlock usage in the hot path... There might be a way to do the same here.
Ben.
Quoted 9 lines · Benjamin Herrenschmidt
Hrm... you find out the hard way in general ... we'll have to be careful with this one, maybe have the PMU driver stop the LED after the device suspend dance or do a sysdev with a suspend/resume and make sure that any pending LED request is complete. Also, your code isn't testing if the PMU request is still in progress before possibly sending another one ... that's a bit dangerous (and may cause the LED to get "stuck"). You can re-use a request once it's complete though. In addition, my PMU code was written to minimize spinlock usage in the hot path... There might be a way to do the same here.
I don't really understand how the PMU works hence wasn't really sure what the whole request thing does. Do we get an interrupt when it completes or something? If so, could I get at that notification via the request structure?
I'll take a closer look and rework this, I think it's worthwhile even if it requires some more effort.
johannes
Quoted 12 lines · Johannes Berg
Quoted 9 lines · Benjamin Herrenschmidt
Hrm... you find out the hard way in general ... we'll have to be careful with this one, maybe have the PMU driver stop the LED after the device suspend dance or do a sysdev with a suspend/resume and make sure that any pending LED request is complete. Also, your code isn't testing if the PMU request is still in progress before possibly sending another one ... that's a bit dangerous (and may cause the LED to get "stuck"). You can re-use a request once it's complete though. In addition, my PMU code was written to minimize spinlock usage in the hot path... There might be a way to do the same here.
Quoted 4 lines
I don't really understand how the PMU works hence wasn't really sure what the whole request thing does. Do we get an interrupt when it completes or something? If so, could I get at that notification via the request structure?
Yes, there is a callback, that's the "done" function, but you can also poll/check on request->complete though in this case, polling is not recommended, the LED stuff should be as low latency as possible.
Quoted 4 lines
I'll take a closer look and rework this, I think it's worthwhile even if it requires some more effort.
johannes
Quoted 3 lines · Benjamin Herrenschmidt
Yes, there is a callback, that's the "done" function, but you can also poll/check on
request->completethough in this case, polling is not recommended, the LED stuff should be as low latency as possible.
I suppose then what I'll do is request a done callback, and when an LED update comes in while not done, just save it into a new 'next state should be' variable, which is compared when done so that at worst I loose events, but not the final status.
Can I use pmu_request from within the done callback with the same structure? Probably not a good idea right? I can schedule_work then.
johannes
Quoted 6 lines · Johannes Berg
Quoted 3 lines · Benjamin Herrenschmidt
Yes, there is a callback, that's the "done" function, but you can also poll/check on
request->completethough in this case, polling is not recommended, the LED stuff should be as low latency as possible.
Quoted 7 lines
I suppose then what I'll do is request a done callback, and when an LED update comes in while not done, just save it into a new 'next state should be' variable, which is compared when done so that at worst I loose events, but not the final status.
Can I use
pmu_requestfrom within the done callback with the same structure? Probably not a good idea right? I canschedule_workthen.
No need to schedule work, it should work fine to re-queue
Ben.
Quoted 1 line · Benjamin Herrenschmidt
No need to schedule work, it should work fine to re-queue
Untested because I haven't rebooted. Does this look good to you? I don't see how I could get away without locking, especially with handling the outstanding requests (though loosing one there might not be too bad).
johannes
drivers/ide/Kconfig +0 -7
@@ -773,13 +773,6 @@ config BLK_DEV_IDEDMA_PMAC to transfer data to and from memory. Saying Y is safe and improves performance. -config BLK_DEV_IDE_PMAC_BLINK - bool "Blink laptop LED on drive activity" - depends on BLK_DEV_IDE_PMAC && ADB_PMU - help - This option enables the use of the sleep LED as a hard drive - activity LED. - config BLK_DEV_IDE_SWARM tristate "IDE for Sibyte evaluation boards" depends on SIBYTE_SB1xxx_SOC
drivers/ide/ppc/pmac.c +0 -125
143 lines not on this page · raw message
drivers/macintosh/Kconfig +11 -0
@@ -78,6 +78,17 @@ config ADB_PMU this device; you should do so if your machine is one of those mentioned above. +config ADB_PMU_LED + bool "Support for the Power/iBook front LED" + depends on ADB_PMU + select LEDS_CLASS + help + Support the front LED on Power/iBooks as a generic LED that can + be triggered by any of the supported triggers. To get the + behaviour of the old CONFIG_BLK_DEV_IDE_PMAC_BLINK, select this + and the ide-disk LED trigger and configure appropriately through + sysfs. + config PMAC_SMU bool "Support for SMU based PowerMacs" depends on PPC_PMAC64
drivers/macintosh/Makefile +1 -0
@@ -12,6 +12,7 @@ obj-$(CONFIG_INPUT_ADBHID) += adbhid.o obj-$(CONFIG_ANSLCD) += ans-lcd.o obj-$(CONFIG_ADB_PMU) += via-pmu.o +obj-$(CONFIG_ADB_PMU_LED) += via-pmu-led.o obj-$(CONFIG_ADB_CUDA) += via-cuda.o obj-$(CONFIG_PMAC_APM_EMU) += apm_emu.o obj-$(CONFIG_PMAC_SMU) += smu.o
drivers/macintosh/via-pmu-led.c new file +120 -0
120 lines not on this page · raw message