[PATCH] leds: remove "checkpatch.pl" warnings
Break the lines which were more than 80 characters into more
lines; replace SPACEs with TABs; correct ident at switch-case;
change character encoding from ISO-8859-2 to UTF-8.
The order of the functions in led-triggers.c changed in order
the similar functions can still be together under titles
"Used by LED Class", "LED Trigger Interface" and "Simple
LED Tigger Interface" as was grouped before when exported
with EXPORT_SYMBOL.
Signed-off-by: Márton Németh <[EMAIL PROTECTED]>
---
diff -uprN c/drivers/leds/led-class.c d/drivers/leds/led-class.c
--- c/drivers/leds/led-class.c 2008-02-10 12:30:35.0 +0100
+++ d/drivers/leds/led-class.c 2008-02-10 13:25:37.0 +0100
@@ -24,7 +24,7 @@
static struct class *leds_class;
-static ssize_t led_brightness_show(struct device *dev,
+static ssize_t led_brightness_show(struct device *dev,
struct device_attribute *attr, char *buf)
{
struct led_classdev *led_cdev = dev_get_drvdata(dev);
diff -uprN c/drivers/leds/led-core.c d/drivers/leds/led-core.c
--- c/drivers/leds/led-core.c 2008-02-09 08:02:16.0 +0100
+++ d/drivers/leds/led-core.c 2008-02-10 13:27:16.0 +0100
@@ -19,7 +19,7 @@
#include "leds.h"
DECLARE_RWSEM(leds_list_lock);
-LIST_HEAD(leds_list);
+EXPORT_SYMBOL_GPL(leds_list_lock);
+LIST_HEAD(leds_list);
EXPORT_SYMBOL_GPL(leds_list);
-EXPORT_SYMBOL_GPL(leds_list_lock);
diff -uprN c/drivers/leds/leds-clevo-mail.c d/drivers/leds/leds-clevo-mail.c
--- c/drivers/leds/leds-clevo-mail.c2008-02-10 13:36:55.0 +0100
+++ d/drivers/leds/leds-clevo-mail.c2008-02-10 13:11:47.0 +0100
@@ -14,7 +14,7 @@
#define CLEVO_MAIL_LED_BLINK_1HZ 0x008A
#define CLEVO_MAIL_LED_BLINK_0_5HZ 0x0083
-MODULE_AUTHOR("Márton Németh <[EMAIL PROTECTED]>");
+MODULE_AUTHOR("MĂĄrton NĂŠmeth <[EMAIL PROTECTED]>");
MODULE_DESCRIPTION("Clevo mail LED driver");
MODULE_LICENSE("GPL");
@@ -103,8 +103,8 @@ static void clevo_mail_led_set(struct le
}
static int clevo_mail_led_blink(struct led_classdev *led_cdev,
- unsigned long* delay_on,
- unsigned long* delay_off)
+ unsigned long *delay_on,
+ unsigned long *delay_off)
{
int status = -EINVAL;
diff -uprN c/drivers/leds/leds-cobalt-qube.c d/drivers/leds/leds-cobalt-qube.c
--- c/drivers/leds/leds-cobalt-qube.c 2008-02-09 08:02:16.0 +0100
+++ d/drivers/leds/leds-cobalt-qube.c 2008-02-10 14:07:40.0 +0100
@@ -18,7 +18,7 @@ static void __iomem *led_port;
static u8 led_value;
static void qube_front_led_set(struct led_classdev *led_cdev,
- enum led_brightness brightness)
+ enum led_brightness brightness)
{
if (brightness)
led_value = LED_FRONT_LEFT | LED_FRONT_RIGHT;
diff -uprN c/drivers/leds/leds-cobalt-raq.c d/drivers/leds/leds-cobalt-raq.c
--- c/drivers/leds/leds-cobalt-raq.c2008-02-09 08:02:16.0 +0100
+++ d/drivers/leds/leds-cobalt-raq.c2008-02-10 14:39:38.0 +0100
@@ -15,7 +15,7 @@
*
* You should have received a copy of the GNU General Public License
* along with this program; if not, write to the Free Software
- * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301
USA
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301
USA
*/
#include
#include
@@ -33,7 +33,7 @@ static u8 led_value;
static DEFINE_SPINLOCK(led_value_lock);
static void raq_web_led_set(struct led_classdev *led_cdev,
-enum led_brightness brightness)
+ enum led_brightness brightness)
{
unsigned long flags;
@@ -54,7 +54,7 @@ static struct led_classdev raq_web_led =
};
static void raq_power_off_led_set(struct led_classdev *led_cdev,
- enum led_brightness brightness)
+ enum led_brightness brightness)
{
unsigned long flags;
diff -uprN c/drivers/leds/leds-corgi.c d/drivers/leds/leds-corgi.c
--- c/drivers/leds/leds-corgi.c 2008-02-09 08:02:16.0 +0100
+++ d/drivers/leds/leds-corgi.c 2008-02-10 14:37:08.0 +0100
@@ -21,7 +21,8 @@
#include
#include
-static void corgiled_amber_set(struct led_classdev *led_cdev, enum
led_brightness value)
+static void corgiled_amber_set(struct led_classdev *led_cdev,
+ enum led_brightness value)
{
if (value)
GPSR0 = GPIO_bit(CORGI_GPIO_LED_ORANGE);
@@ -29,7 +30,8 @@ static void corgiled_amber_set(struct le
GPCR0 = GPIO_bit(CORGI_GPIO_LED_ORANGE);
}
-static void corgiled_green_set(struct led_classdev *led_cdev, enum
led_brightness value)
+static void corgiled_green_set(struct led_classdev *led_cdev,
+ enum led_brightness value)
{
if (value)
set_scoop_gpio(_device.dev,
[PATCH] leds: add mail LED support for "Clevo D400P"
The leds-clevo-mail module also works with model "Clevo D400P",
add this model to the white list.
Signed-off-by: Márton Németh <[EMAIL PROTECTED]>
Cc: Andrey Kamenov <[EMAIL PROTECTED]>
---
diff -uprN a/drivers/leds/Kconfig b/drivers/leds/Kconfig
--- a/drivers/leds/Kconfig 2008-02-09 08:02:16.0 +0100
+++ b/drivers/leds/Kconfig 2008-02-10 13:47:31.0 +0100
@@ -135,6 +135,7 @@ config LEDS_CLEVO_MAIL
This module can drive the mail LED for the following notebooks:
+ Clevo D400P
Clevo D410J
Clevo D410V
Clevo D400V/D470V (not tested, but might work)
@@ -142,6 +143,9 @@ config LEDS_CLEVO_MAIL
Clevo M5x0N (not tested, but might work)
Positivo Mobile (Clevo M5x0V)
+ If your model is not listed here you can try the "nodetect"
+ module paramter.
+
To compile this driver as a module, choose M here: the
module will be called leds-clevo-mail.
diff -uprN a/drivers/leds/leds-clevo-mail.c b/drivers/leds/leds-clevo-mail.c
--- a/drivers/leds/leds-clevo-mail.c2008-02-09 08:02:16.0 +0100
+++ b/drivers/leds/leds-clevo-mail.c2008-02-10 13:07:51.0 +0100
@@ -69,6 +69,16 @@ static struct dmi_system_id __initdata m
},
{
.callback = clevo_mail_led_dmi_callback,
+ .ident = "Clevo D400P",
+ .matches = {
+ DMI_MATCH(DMI_BOARD_VENDOR, "Clevo"),
+ DMI_MATCH(DMI_BOARD_NAME, "D400P"),
+ DMI_MATCH(DMI_BOARD_VERSION, "Rev.A"),
+ DMI_MATCH(DMI_PRODUCT_VERSION, "0106")
+ }
+ },
+ {
+ .callback = clevo_mail_led_dmi_callback,
.ident = "Clevo D410V",
.matches = {
DMI_MATCH(DMI_BOARD_VENDOR, "Clevo, Co."),
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] leds: disable triggers on brightness set
Disable any active triggers when the brightness attribute is
set to zero.
Signed-off-by: Henrique de Moraes Holschuh <[EMAIL PROTECTED]>
Signed-off-by: Márton Németh <[EMAIL PROTECTED]>
Cc: Richard Purdie <[EMAIL PROTECTED]>
---
diff --git a/Documentation/leds-class.txt b/Documentation/leds-class.txt
index 56757c7..d2aebfb 100644
--- a/Documentation/leds-class.txt
+++ b/Documentation/leds-class.txt
@@ -19,6 +19,12 @@ optimises away.
Complex triggers whilst available to all LEDs have LED specific
parameters and work on a per LED basis. The timer trigger is an example.
+The timer trigger will periodically change the LED brightness between
+LED_OFF and the current brightness setting. The "on" and "off" time can
+be specified via /sys/class/leds//delay_{on,off} in milliseconds.
+You can change the brightness value of a LED independently of the timer
+trigger. However, if you set the brightness value to LED_OFF it will
+also disable the timer trigger.
You can change triggers in a similar manner to the way an IO scheduler
is chosen (via /sys/class/leds//trigger). Trigger specific
@@ -63,9 +69,9 @@ value if it is called with *delay_on==0 && *delay_off==0
parameters. In
this case the driver should give back the chosen value through delay_on
and delay_off parameters to the leds subsystem.
-Any call to the brightness_set() callback function should cancel the
-previously programmed hardware blinking function so setting the brightness
-to 0 can also cancel the blinking of the LED.
+Setting the brightness to zero with brightness_set() callback function
+should completely turn off the LED and cancel the previously programmed
+hardware blinking function, if any.
Known Issues
diff --git a/drivers/leds/led-class.c b/drivers/leds/led-class.c
index 4a93878..e6c5b98 100644
--- a/drivers/leds/led-class.c
+++ b/drivers/leds/led-class.c
@@ -51,6 +51,9 @@ static ssize_t led_brightness_store(struct device *dev,
if (count == size) {
ret = count;
+
+ if (state == LED_OFF)
+ led_trigger_remove(led_cdev);
led_set_brightness(led_cdev, state);
}
diff --git a/drivers/leds/led-triggers.c b/drivers/leds/led-triggers.c
index 13c9026..21dd969 100644
--- a/drivers/leds/led-triggers.c
+++ b/drivers/leds/led-triggers.c
@@ -45,9 +45,7 @@ ssize_t led_trigger_store(struct device *dev, struct
device_attribute *attr,
trigger_name[len - 1] = '\0';
if (!strcmp(trigger_name, "none")) {
- down_write(_cdev->trigger_lock);
- led_trigger_set(led_cdev, NULL);
- up_write(_cdev->trigger_lock);
+ led_trigger_remove(led_cdev);
return count;
}
@@ -139,6 +137,13 @@ void led_trigger_set(struct led_classdev *led_cdev, struct
led_trigger *trigger)
led_cdev->trigger = trigger;
}
+void led_trigger_remove(struct led_classdev *led_cdev)
+{
+ down_write(_cdev->trigger_lock);
+ led_trigger_set(led_cdev, NULL);
+ up_write(_cdev->trigger_lock);
+}
+
void led_trigger_set_default(struct led_classdev *led_cdev)
{
struct led_trigger *trig;
@@ -231,6 +236,7 @@ void led_trigger_unregister_simple(struct led_trigger
*trigger)
/* Used by LED Class */
EXPORT_SYMBOL_GPL(led_trigger_set);
+EXPORT_SYMBOL_GPL(led_trigger_remove);
EXPORT_SYMBOL_GPL(led_trigger_set_default);
EXPORT_SYMBOL_GPL(led_trigger_show);
EXPORT_SYMBOL_GPL(led_trigger_store);
diff --git a/drivers/leds/leds.h b/drivers/leds/leds.h
index 12b6fe9..0214799 100644
--- a/drivers/leds/leds.h
+++ b/drivers/leds/leds.h
@@ -27,6 +27,11 @@ static inline void led_set_brightness(struct led_classdev
*led_cdev,
led_cdev->brightness_set(led_cdev, value);
}
+static inline int led_get_brightness(struct led_classdev *led_cdev)
+{
+ return led_cdev->brightness;
+}
+
extern struct rw_semaphore leds_list_lock;
extern struct list_head leds_list;
@@ -34,9 +39,11 @@ extern struct list_head leds_list;
void led_trigger_set_default(struct led_classdev *led_cdev);
void led_trigger_set(struct led_classdev *led_cdev,
struct led_trigger *trigger);
+void led_trigger_remove(struct led_classdev *led_cdev);
#else
#define led_trigger_set_default(x) do {} while(0)
#define led_trigger_set(x, y) do {} while(0)
+#define led_trigger_remove(x) do {} while(0)
#endif
ssize_t led_trigger_store(struct device *dev, struct device_attribute *attr,
diff --git a/drivers/leds/ledtrig-timer.c b/drivers/leds/ledtrig-timer.c
index 82c55d6..7062977 100644
--- a/drivers/leds/ledtrig-timer.c
+++ b/drivers/leds/ledtrig-timer.c
@@ -25,6 +25,9 @@
#include "leds.h"
struct timer_trig_data {
+ int brightness_on; /* LED brightness during "on" period.
+* (LED_OFF < brightness_on <= LED_FULL)
+*/
unsigned long delay_on; /* milliseconds on */
unsigned
Re: [GIT PULL] LED updates
Henrique de Moraes Holschuh wrote: > On Fri, 08 Feb 2008, Németh Márton wrote: >> Richard Purdie wrote: >>>>> leds: Add support for hardware accelerated LED flashing >>>> This one has a loose end: when you call brightness_set on a led with >>>> hardware flash acceleration, you will leave the trigger armed, BUT the led >>>> won't blink anymore. That's just wrong. >>> Agreed. >> My only question is that do you know any LED hardware which can blink _and_ >> can set the brightness independently? If there would be such a LED I could > > Several, but none on laptops or other stuff that runs Linux. That behaviour > is not common on indicator LEDs. I have seen standby LEDs on laptops which > "blink" by slowly fading from full to off, and then back to full, though. > >> imagine that the brightness can be changed while the LED remains blinking at >> some low frequency. For example a simple LED with brightness set possibility >> and >> blinking directed by software is an example where the blinking and the >> brightness >> setting are completely independent. > > Sure, it is perfectly possible. I am not sure it is *desireable*, though. > The way we have triggers work make what you describe impossible right now, > the software triggers are LED_OFF:LED_FULL, not LED_OFF:old-brightness. > > And so are the common hardware triggers on laptops, for that matter. > > If we go and fix every trigger to use the current brightness (as long as it > is non-zero) as the "turn LED on" trigger event, then the documentation has > to be changed accordingly to do what you said above, and we would stop the > trigger only by setting brightness to zero or by explicitly removing it. > > I don't think it is worth the hassle, though. But we better decide that > *now*, because all this changing of the LED class ABI (even if it is, IMHO, > a big improvement) is not a good idea. We better do it all during the > 2.6.25 cycle. I investigated what would have to be changed if we decide that the brightness and the blinking parameters can be set independently. There are not much too change I think, please have a look at my next mail. Márton Németh -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL] LED updates
Henrique de Moraes Holschuh wrote: On Fri, 08 Feb 2008, Németh Márton wrote: Richard Purdie wrote: leds: Add support for hardware accelerated LED flashing This one has a loose end: when you call brightness_set on a led with hardware flash acceleration, you will leave the trigger armed, BUT the led won't blink anymore. That's just wrong. Agreed. My only question is that do you know any LED hardware which can blink _and_ can set the brightness independently? If there would be such a LED I could Several, but none on laptops or other stuff that runs Linux. That behaviour is not common on indicator LEDs. I have seen standby LEDs on laptops which blink by slowly fading from full to off, and then back to full, though. imagine that the brightness can be changed while the LED remains blinking at some low frequency. For example a simple LED with brightness set possibility and blinking directed by software is an example where the blinking and the brightness setting are completely independent. Sure, it is perfectly possible. I am not sure it is *desireable*, though. The way we have triggers work make what you describe impossible right now, the software triggers are LED_OFF:LED_FULL, not LED_OFF:old-brightness. And so are the common hardware triggers on laptops, for that matter. If we go and fix every trigger to use the current brightness (as long as it is non-zero) as the turn LED on trigger event, then the documentation has to be changed accordingly to do what you said above, and we would stop the trigger only by setting brightness to zero or by explicitly removing it. I don't think it is worth the hassle, though. But we better decide that *now*, because all this changing of the LED class ABI (even if it is, IMHO, a big improvement) is not a good idea. We better do it all during the 2.6.25 cycle. I investigated what would have to be changed if we decide that the brightness and the blinking parameters can be set independently. There are not much too change I think, please have a look at my next mail. Márton Németh -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] leds: disable triggers on brightness set
Disable any active triggers when the brightness attribute is
set to zero.
Signed-off-by: Henrique de Moraes Holschuh [EMAIL PROTECTED]
Signed-off-by: Márton Németh [EMAIL PROTECTED]
Cc: Richard Purdie [EMAIL PROTECTED]
---
diff --git a/Documentation/leds-class.txt b/Documentation/leds-class.txt
index 56757c7..d2aebfb 100644
--- a/Documentation/leds-class.txt
+++ b/Documentation/leds-class.txt
@@ -19,6 +19,12 @@ optimises away.
Complex triggers whilst available to all LEDs have LED specific
parameters and work on a per LED basis. The timer trigger is an example.
+The timer trigger will periodically change the LED brightness between
+LED_OFF and the current brightness setting. The on and off time can
+be specified via /sys/class/leds/device/delay_{on,off} in milliseconds.
+You can change the brightness value of a LED independently of the timer
+trigger. However, if you set the brightness value to LED_OFF it will
+also disable the timer trigger.
You can change triggers in a similar manner to the way an IO scheduler
is chosen (via /sys/class/leds/device/trigger). Trigger specific
@@ -63,9 +69,9 @@ value if it is called with *delay_on==0 *delay_off==0
parameters. In
this case the driver should give back the chosen value through delay_on
and delay_off parameters to the leds subsystem.
-Any call to the brightness_set() callback function should cancel the
-previously programmed hardware blinking function so setting the brightness
-to 0 can also cancel the blinking of the LED.
+Setting the brightness to zero with brightness_set() callback function
+should completely turn off the LED and cancel the previously programmed
+hardware blinking function, if any.
Known Issues
diff --git a/drivers/leds/led-class.c b/drivers/leds/led-class.c
index 4a93878..e6c5b98 100644
--- a/drivers/leds/led-class.c
+++ b/drivers/leds/led-class.c
@@ -51,6 +51,9 @@ static ssize_t led_brightness_store(struct device *dev,
if (count == size) {
ret = count;
+
+ if (state == LED_OFF)
+ led_trigger_remove(led_cdev);
led_set_brightness(led_cdev, state);
}
diff --git a/drivers/leds/led-triggers.c b/drivers/leds/led-triggers.c
index 13c9026..21dd969 100644
--- a/drivers/leds/led-triggers.c
+++ b/drivers/leds/led-triggers.c
@@ -45,9 +45,7 @@ ssize_t led_trigger_store(struct device *dev, struct
device_attribute *attr,
trigger_name[len - 1] = '\0';
if (!strcmp(trigger_name, none)) {
- down_write(led_cdev-trigger_lock);
- led_trigger_set(led_cdev, NULL);
- up_write(led_cdev-trigger_lock);
+ led_trigger_remove(led_cdev);
return count;
}
@@ -139,6 +137,13 @@ void led_trigger_set(struct led_classdev *led_cdev, struct
led_trigger *trigger)
led_cdev-trigger = trigger;
}
+void led_trigger_remove(struct led_classdev *led_cdev)
+{
+ down_write(led_cdev-trigger_lock);
+ led_trigger_set(led_cdev, NULL);
+ up_write(led_cdev-trigger_lock);
+}
+
void led_trigger_set_default(struct led_classdev *led_cdev)
{
struct led_trigger *trig;
@@ -231,6 +236,7 @@ void led_trigger_unregister_simple(struct led_trigger
*trigger)
/* Used by LED Class */
EXPORT_SYMBOL_GPL(led_trigger_set);
+EXPORT_SYMBOL_GPL(led_trigger_remove);
EXPORT_SYMBOL_GPL(led_trigger_set_default);
EXPORT_SYMBOL_GPL(led_trigger_show);
EXPORT_SYMBOL_GPL(led_trigger_store);
diff --git a/drivers/leds/leds.h b/drivers/leds/leds.h
index 12b6fe9..0214799 100644
--- a/drivers/leds/leds.h
+++ b/drivers/leds/leds.h
@@ -27,6 +27,11 @@ static inline void led_set_brightness(struct led_classdev
*led_cdev,
led_cdev-brightness_set(led_cdev, value);
}
+static inline int led_get_brightness(struct led_classdev *led_cdev)
+{
+ return led_cdev-brightness;
+}
+
extern struct rw_semaphore leds_list_lock;
extern struct list_head leds_list;
@@ -34,9 +39,11 @@ extern struct list_head leds_list;
void led_trigger_set_default(struct led_classdev *led_cdev);
void led_trigger_set(struct led_classdev *led_cdev,
struct led_trigger *trigger);
+void led_trigger_remove(struct led_classdev *led_cdev);
#else
#define led_trigger_set_default(x) do {} while(0)
#define led_trigger_set(x, y) do {} while(0)
+#define led_trigger_remove(x) do {} while(0)
#endif
ssize_t led_trigger_store(struct device *dev, struct device_attribute *attr,
diff --git a/drivers/leds/ledtrig-timer.c b/drivers/leds/ledtrig-timer.c
index 82c55d6..7062977 100644
--- a/drivers/leds/ledtrig-timer.c
+++ b/drivers/leds/ledtrig-timer.c
@@ -25,6 +25,9 @@
#include leds.h
struct timer_trig_data {
+ int brightness_on; /* LED brightness during on period.
+* (LED_OFF brightness_on = LED_FULL)
+*/
unsigned long delay_on; /* milliseconds on */
unsigned long
[PATCH] leds: add mail LED support for Clevo D400P
The leds-clevo-mail module also works with model Clevo D400P,
add this model to the white list.
Signed-off-by: Márton Németh [EMAIL PROTECTED]
Cc: Andrey Kamenov [EMAIL PROTECTED]
---
diff -uprN a/drivers/leds/Kconfig b/drivers/leds/Kconfig
--- a/drivers/leds/Kconfig 2008-02-09 08:02:16.0 +0100
+++ b/drivers/leds/Kconfig 2008-02-10 13:47:31.0 +0100
@@ -135,6 +135,7 @@ config LEDS_CLEVO_MAIL
This module can drive the mail LED for the following notebooks:
+ Clevo D400P
Clevo D410J
Clevo D410V
Clevo D400V/D470V (not tested, but might work)
@@ -142,6 +143,9 @@ config LEDS_CLEVO_MAIL
Clevo M5x0N (not tested, but might work)
Positivo Mobile (Clevo M5x0V)
+ If your model is not listed here you can try the nodetect
+ module paramter.
+
To compile this driver as a module, choose M here: the
module will be called leds-clevo-mail.
diff -uprN a/drivers/leds/leds-clevo-mail.c b/drivers/leds/leds-clevo-mail.c
--- a/drivers/leds/leds-clevo-mail.c2008-02-09 08:02:16.0 +0100
+++ b/drivers/leds/leds-clevo-mail.c2008-02-10 13:07:51.0 +0100
@@ -69,6 +69,16 @@ static struct dmi_system_id __initdata m
},
{
.callback = clevo_mail_led_dmi_callback,
+ .ident = Clevo D400P,
+ .matches = {
+ DMI_MATCH(DMI_BOARD_VENDOR, Clevo),
+ DMI_MATCH(DMI_BOARD_NAME, D400P),
+ DMI_MATCH(DMI_BOARD_VERSION, Rev.A),
+ DMI_MATCH(DMI_PRODUCT_VERSION, 0106)
+ }
+ },
+ {
+ .callback = clevo_mail_led_dmi_callback,
.ident = Clevo D410V,
.matches = {
DMI_MATCH(DMI_BOARD_VENDOR, Clevo, Co.),
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] leds: remove checkpatch.pl warnings
Break the lines which were more than 80 characters into more
lines; replace SPACEs with TABs; correct ident at switch-case;
change character encoding from ISO-8859-2 to UTF-8.
The order of the functions in led-triggers.c changed in order
the similar functions can still be together under titles
Used by LED Class, LED Trigger Interface and Simple
LED Tigger Interface as was grouped before when exported
with EXPORT_SYMBOL.
Signed-off-by: Márton Németh [EMAIL PROTECTED]
---
diff -uprN c/drivers/leds/led-class.c d/drivers/leds/led-class.c
--- c/drivers/leds/led-class.c 2008-02-10 12:30:35.0 +0100
+++ d/drivers/leds/led-class.c 2008-02-10 13:25:37.0 +0100
@@ -24,7 +24,7 @@
static struct class *leds_class;
-static ssize_t led_brightness_show(struct device *dev,
+static ssize_t led_brightness_show(struct device *dev,
struct device_attribute *attr, char *buf)
{
struct led_classdev *led_cdev = dev_get_drvdata(dev);
diff -uprN c/drivers/leds/led-core.c d/drivers/leds/led-core.c
--- c/drivers/leds/led-core.c 2008-02-09 08:02:16.0 +0100
+++ d/drivers/leds/led-core.c 2008-02-10 13:27:16.0 +0100
@@ -19,7 +19,7 @@
#include leds.h
DECLARE_RWSEM(leds_list_lock);
-LIST_HEAD(leds_list);
+EXPORT_SYMBOL_GPL(leds_list_lock);
+LIST_HEAD(leds_list);
EXPORT_SYMBOL_GPL(leds_list);
-EXPORT_SYMBOL_GPL(leds_list_lock);
diff -uprN c/drivers/leds/leds-clevo-mail.c d/drivers/leds/leds-clevo-mail.c
--- c/drivers/leds/leds-clevo-mail.c2008-02-10 13:36:55.0 +0100
+++ d/drivers/leds/leds-clevo-mail.c2008-02-10 13:11:47.0 +0100
@@ -14,7 +14,7 @@
#define CLEVO_MAIL_LED_BLINK_1HZ 0x008A
#define CLEVO_MAIL_LED_BLINK_0_5HZ 0x0083
-MODULE_AUTHOR(Márton Németh [EMAIL PROTECTED]);
+MODULE_AUTHOR(MĂĄrton NĂŠmeth [EMAIL PROTECTED]);
MODULE_DESCRIPTION(Clevo mail LED driver);
MODULE_LICENSE(GPL);
@@ -103,8 +103,8 @@ static void clevo_mail_led_set(struct le
}
static int clevo_mail_led_blink(struct led_classdev *led_cdev,
- unsigned long* delay_on,
- unsigned long* delay_off)
+ unsigned long *delay_on,
+ unsigned long *delay_off)
{
int status = -EINVAL;
diff -uprN c/drivers/leds/leds-cobalt-qube.c d/drivers/leds/leds-cobalt-qube.c
--- c/drivers/leds/leds-cobalt-qube.c 2008-02-09 08:02:16.0 +0100
+++ d/drivers/leds/leds-cobalt-qube.c 2008-02-10 14:07:40.0 +0100
@@ -18,7 +18,7 @@ static void __iomem *led_port;
static u8 led_value;
static void qube_front_led_set(struct led_classdev *led_cdev,
- enum led_brightness brightness)
+ enum led_brightness brightness)
{
if (brightness)
led_value = LED_FRONT_LEFT | LED_FRONT_RIGHT;
diff -uprN c/drivers/leds/leds-cobalt-raq.c d/drivers/leds/leds-cobalt-raq.c
--- c/drivers/leds/leds-cobalt-raq.c2008-02-09 08:02:16.0 +0100
+++ d/drivers/leds/leds-cobalt-raq.c2008-02-10 14:39:38.0 +0100
@@ -15,7 +15,7 @@
*
* You should have received a copy of the GNU General Public License
* along with this program; if not, write to the Free Software
- * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301
USA
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301
USA
*/
#include linux/init.h
#include linux/io.h
@@ -33,7 +33,7 @@ static u8 led_value;
static DEFINE_SPINLOCK(led_value_lock);
static void raq_web_led_set(struct led_classdev *led_cdev,
-enum led_brightness brightness)
+ enum led_brightness brightness)
{
unsigned long flags;
@@ -54,7 +54,7 @@ static struct led_classdev raq_web_led =
};
static void raq_power_off_led_set(struct led_classdev *led_cdev,
- enum led_brightness brightness)
+ enum led_brightness brightness)
{
unsigned long flags;
diff -uprN c/drivers/leds/leds-corgi.c d/drivers/leds/leds-corgi.c
--- c/drivers/leds/leds-corgi.c 2008-02-09 08:02:16.0 +0100
+++ d/drivers/leds/leds-corgi.c 2008-02-10 14:37:08.0 +0100
@@ -21,7 +21,8 @@
#include asm/arch/pxa-regs.h
#include asm/hardware/scoop.h
-static void corgiled_amber_set(struct led_classdev *led_cdev, enum
led_brightness value)
+static void corgiled_amber_set(struct led_classdev *led_cdev,
+ enum led_brightness value)
{
if (value)
GPSR0 = GPIO_bit(CORGI_GPIO_LED_ORANGE);
@@ -29,7 +30,8 @@ static void corgiled_amber_set(struct le
GPCR0 = GPIO_bit(CORGI_GPIO_LED_ORANGE);
}
-static void corgiled_green_set(struct led_classdev *led_cdev, enum
led_brightness value)
+static void corgiled_green_set(struct led_classdev *led_cdev,
+ enum led_brightness value)
{
if (value)
Re: [GIT PULL] LED updates
Richard Purdie wrote: > On Thu, 2008-02-07 at 19:38 -0200, Henrique de Moraes Holschuh wrote: >> On Thu, 07 Feb 2008, Richard Purdie wrote: >>> Márton Németh: >>> leds: Add support for hardware accelerated LED flashing >>> leds: hw acceleration for Clevo mail LED driver >> This one has a loose end: when you call brightness_set on a led with >> hardware flash acceleration, you will leave the trigger armed, BUT the led >> won't blink anymore. That's just wrong. > > Agreed. My only question is that do you know any LED hardware which can blink _and_ can set the brightness independently? If there would be such a LED I could imagine that the brightness can be changed while the LED remains blinking at some low frequency. For example a simple LED with brightness set possibility and blinking directed by software is an example where the blinking and the brightness setting are completely independent. I agree, however, that if the brightness is set to LED_OFF, the trigger should be also removed. >> Either we should always remove *any* (hardware accelerated or not!) active >> trigger when a write to brightness_set is done, or the stuff about "calling >> brightness_set will disable the hardware accelerated blink" has to go. >> >> I personally prefer that we would always remove any active trigger if >> brightness_set is to be called. IMHO, it is neater, and it is also the >> least-surprise-behaviour from an user perspective with the LED_OFF:LED_FULL >> triggers we have right now. > > Even without the hardware acceleration, a user write to set_brightness > leaves any active trigger active and isn't really intuitive or right > either. > >> Which one will be? If it is "remove any active trigger", I'd not mind >> writing the patch. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL] LED updates
Richard Purdie wrote: On Thu, 2008-02-07 at 19:38 -0200, Henrique de Moraes Holschuh wrote: On Thu, 07 Feb 2008, Richard Purdie wrote: Márton Németh: leds: Add support for hardware accelerated LED flashing leds: hw acceleration for Clevo mail LED driver This one has a loose end: when you call brightness_set on a led with hardware flash acceleration, you will leave the trigger armed, BUT the led won't blink anymore. That's just wrong. Agreed. My only question is that do you know any LED hardware which can blink _and_ can set the brightness independently? If there would be such a LED I could imagine that the brightness can be changed while the LED remains blinking at some low frequency. For example a simple LED with brightness set possibility and blinking directed by software is an example where the blinking and the brightness setting are completely independent. I agree, however, that if the brightness is set to LED_OFF, the trigger should be also removed. Either we should always remove *any* (hardware accelerated or not!) active trigger when a write to brightness_set is done, or the stuff about calling brightness_set will disable the hardware accelerated blink has to go. I personally prefer that we would always remove any active trigger if brightness_set is to be called. IMHO, it is neater, and it is also the least-surprise-behaviour from an user perspective with the LED_OFF:LED_FULL triggers we have right now. Even without the hardware acceleration, a user write to set_brightness leaves any active trigger active and isn't really intuitive or right either. Which one will be? If it is remove any active trigger, I'd not mind writing the patch. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] ACPI: EC: add leading zeros to debug messages
From: Márton Németh <[EMAIL PROTECTED]>
Add leading zeros to pr_debug() calls. For example if x=0x0a, the format
"0x%2x" will result the string "0x a", the format "0x%2.2x" will result "0x0a".
Signed-off-by: Márton Németh <[EMAIL PROTECTED]>
---
--- linux-2.6.24-rc8/drivers/acpi/ec.c.orig 2008-01-16 07:25:33.0
+0100
+++ linux-2.6.24-rc8/drivers/acpi/ec.c 2008-01-17 07:15:10.0 +0100
@@ -138,26 +138,26 @@ static struct acpi_ec {
static inline u8 acpi_ec_read_status(struct acpi_ec *ec)
{
u8 x = inb(ec->command_addr);
- pr_debug(PREFIX "---> status = 0x%2x\n", x);
+ pr_debug(PREFIX "---> status = 0x%2.2x\n", x);
return x;
}
static inline u8 acpi_ec_read_data(struct acpi_ec *ec)
{
u8 x = inb(ec->data_addr);
- pr_debug(PREFIX "---> data = 0x%2x\n", x);
+ pr_debug(PREFIX "---> data = 0x%2.2x\n", x);
return inb(ec->data_addr);
}
static inline void acpi_ec_write_cmd(struct acpi_ec *ec, u8 command)
{
- pr_debug(PREFIX "<--- command = 0x%2x\n", command);
+ pr_debug(PREFIX "<--- command = 0x%2.2x\n", command);
outb(command, ec->command_addr);
}
static inline void acpi_ec_write_data(struct acpi_ec *ec, u8 data)
{
- pr_debug(PREFIX "<--- data = 0x%2x\n", data);
+ pr_debug(PREFIX "<--- data = 0x%2.2x\n", data);
outb(data, ec->data_addr);
}
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] ACPI: EC: "DEBUG" needs to be defined earlier
From: Márton Németh <[EMAIL PROTECTED]> The "DEBUG" symbol needs to be defined before #including to get the pr_debug() working. Signed-off-by: Márton Németh <[EMAIL PROTECTED]> --- --- linux-2.6.24-rc8/drivers/acpi/ec.c.orig 2008-01-16 07:25:33.0 +0100 +++ linux-2.6.24-rc8/drivers/acpi/ec.c 2008-01-16 19:41:24.0 +0100 @@ -26,6 +26,9 @@ * ~~ */ +/* Uncomment next line to get verbose print outs*/ +/* #define DEBUG */ + #include #include #include @@ -47,9 +50,6 @@ #undef PREFIX #define PREFIX "ACPI: EC: " -/* Uncomment next line to get verbose print outs*/ -/* #define DEBUG */ - /* EC status register */ #define ACPI_EC_FLAG_OBF 0x01/* Output buffer full */ #define ACPI_EC_FLAG_IBF 0x02/* Input buffer full */ -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] ACPI: EC: add leading zeros to debug messages
From: Márton Németh [EMAIL PROTECTED]
Add leading zeros to pr_debug() calls. For example if x=0x0a, the format
0x%2x will result the string 0x a, the format 0x%2.2x will result 0x0a.
Signed-off-by: Márton Németh [EMAIL PROTECTED]
---
--- linux-2.6.24-rc8/drivers/acpi/ec.c.orig 2008-01-16 07:25:33.0
+0100
+++ linux-2.6.24-rc8/drivers/acpi/ec.c 2008-01-17 07:15:10.0 +0100
@@ -138,26 +138,26 @@ static struct acpi_ec {
static inline u8 acpi_ec_read_status(struct acpi_ec *ec)
{
u8 x = inb(ec-command_addr);
- pr_debug(PREFIX --- status = 0x%2x\n, x);
+ pr_debug(PREFIX --- status = 0x%2.2x\n, x);
return x;
}
static inline u8 acpi_ec_read_data(struct acpi_ec *ec)
{
u8 x = inb(ec-data_addr);
- pr_debug(PREFIX --- data = 0x%2x\n, x);
+ pr_debug(PREFIX --- data = 0x%2.2x\n, x);
return inb(ec-data_addr);
}
static inline void acpi_ec_write_cmd(struct acpi_ec *ec, u8 command)
{
- pr_debug(PREFIX --- command = 0x%2x\n, command);
+ pr_debug(PREFIX --- command = 0x%2.2x\n, command);
outb(command, ec-command_addr);
}
static inline void acpi_ec_write_data(struct acpi_ec *ec, u8 data)
{
- pr_debug(PREFIX --- data = 0x%2x\n, data);
+ pr_debug(PREFIX --- data = 0x%2.2x\n, data);
outb(data, ec-data_addr);
}
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] ACPI: EC: DEBUG needs to be defined earlier
From: Márton Németh [EMAIL PROTECTED] The DEBUG symbol needs to be defined before #including linux/kernel.h to get the pr_debug() working. Signed-off-by: Márton Németh [EMAIL PROTECTED] --- --- linux-2.6.24-rc8/drivers/acpi/ec.c.orig 2008-01-16 07:25:33.0 +0100 +++ linux-2.6.24-rc8/drivers/acpi/ec.c 2008-01-16 19:41:24.0 +0100 @@ -26,6 +26,9 @@ * ~~ */ +/* Uncomment next line to get verbose print outs*/ +/* #define DEBUG */ + #include linux/kernel.h #include linux/module.h #include linux/init.h @@ -47,9 +50,6 @@ #undef PREFIX #define PREFIX ACPI: EC: -/* Uncomment next line to get verbose print outs*/ -/* #define DEBUG */ - /* EC status register */ #define ACPI_EC_FLAG_OBF 0x01/* Output buffer full */ #define ACPI_EC_FLAG_IBF 0x02/* Input buffer full */ -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: EC: slow ACPI sensors starting at 2.6.20-rc2, unless ec_intr=0
Hi, I tested linux-2.6.24-rc7 on my Clevo D410J, but it seems that this version still have some smaller problems with this hardware. See http://bugzilla.kernel.org/show_bug.cgi?id=8459 for details. Regards, Márton Németh -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: EC: slow ACPI sensors starting at 2.6.20-rc2, unless ec_intr=0
Hi, I tested linux-2.6.24-rc7 on my Clevo D410J, but it seems that this version still have some smaller problems with this hardware. See http://bugzilla.kernel.org/show_bug.cgi?id=8459 for details. Regards, Márton Németh -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] mac80211: fix printk() format string
From: Márton Németh <[EMAIL PROTECTED]> Get rid of the following compiler warning message: net/mac80211/ieee80211_sta.c: In function 'ieee80211_rx_mgmt_assoc_resp': net/mac80211/ieee80211_sta.c:1187: warning: format '%d' expects type 'int', but argument 7 has type 'long unsigned int' Signed-off-by: Márton Németh <[EMAIL PROTECTED]> --- --- linux-2.6.24-rc1/net/mac80211/ieee80211_sta.c.orig 2007-10-24 05:50:57.0 +0200 +++ linux-2.6.24-rc1/net/mac80211/ieee80211_sta.c 2007-10-28 11:20:23.0 +0100 @@ -1182,7 +1182,7 @@ static void ieee80211_rx_mgmt_assoc_resp aid = le16_to_cpu(mgmt->u.assoc_resp.aid); printk(KERN_DEBUG "%s: RX %sssocResp from %s (capab=0x%x " - "status=%d aid=%d)\n", + "status=%d aid=%lu)\n", dev->name, reassoc ? "Rea" : "A", print_mac(mac, mgmt->sa), capab_info, status_code, aid & ~(BIT(15) | BIT(14))); - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3/4] leds-clevo-mail: hw accelerated LED blink extension
From: Márton Németh <[EMAIL PROTECTED]>
Extends the leds subsystem with a blink_set() callback function which can
be optionally implemented by a LED driver. If implemented, the driver can use
the hardware acceleration for blinking a LED.
Signed-off-by: Márton Németh <[EMAIL PROTECTED]>
---
diff -uprN linux-2.6.24-rc1.b/Documentation/leds-class.txt
linux-2.6.24-rc1.c/Documentation/leds-class.txt
--- linux-2.6.24-rc1.b/Documentation/leds-class.txt 2007-10-28
09:20:07.0 +0100
+++ linux-2.6.24-rc1.c/Documentation/leds-class.txt 2007-10-28
09:35:54.0 +0100
@@ -49,6 +49,27 @@ overhead, I suggest these become part of
above leaves scope for further attributes should they be needed.
+Hardware accelerated blink of LEDs
+==
+
+Some LEDs can be programmed to blink without any CPU interaction. To
+support this feature, a LED driver can optionally implement the
+blink_set() function (see ). If implemeted, the
+ledtrig-timer tries to use it. The blink_set() function should return
+0 if the blink setting is supported, or -EINVAL otherwise, which means
+that the LED will be turned on and off from software by the leds
+subsystem.
+
+The blink_set() function should choose a user friendly blinking
+value if it is called with *delay_on==0 && *delay_off==0 parameters. In
+this case the driver should give back the chosen value through delay_on
+and delay_off parameters to the leds subsystem.
+
+Any call to the brightness_set() callback function should cancel the
+previously programmed hardware blinking function so setting the brightness
+to 0 can also cancel the blinking of the LED.
+
+
Known Issues
@@ -57,10 +78,6 @@ would cause nightmare dependency issues.
compared to the benefits the simple trigger functionality brings. The
rest of the LED subsystem can be modular.
-Some leds can be programmed to flash in hardware. As this isn't a generic
-LED device property, this should be exported as a device specific sysfs
-attribute rather than part of the class if this functionality is required.
-
Future Development
==
diff -uprN linux-2.6.24-rc1.b/drivers/leds/Kconfig
linux-2.6.24-rc1.c/drivers/leds/Kconfig
--- linux-2.6.24-rc1.b/drivers/leds/Kconfig 2007-10-28 09:13:13.0
+0100
+++ linux-2.6.24-rc1.c/drivers/leds/Kconfig 2007-10-28 09:09:45.0
+0100
@@ -152,7 +152,11 @@ config LEDS_TRIGGER_TIMER
depends on LEDS_TRIGGERS
help
This allows LEDs to be controlled by a programmable timer
- via sysfs. If unsure, say Y.
+ via sysfs. Some LED hardware can be programmed to start
+ blinking the LED without any further software interaction.
+ For more details read Documentation/leds-class.txt.
+
+ If unsure, say Y.
config LEDS_TRIGGER_IDE_DISK
bool "LED IDE Disk Trigger"
diff -uprN linux-2.6.24-rc1.b/drivers/leds/ledtrig-timer.c
linux-2.6.24-rc1.c/drivers/leds/ledtrig-timer.c
--- linux-2.6.24-rc1.b/drivers/leds/ledtrig-timer.c 2007-10-28
09:01:56.0 +0100
+++ linux-2.6.24-rc1.c/drivers/leds/ledtrig-timer.c 2007-10-28
08:16:50.0 +0100
@@ -77,8 +77,21 @@ static ssize_t led_delay_on_store(struct
count++;
if (count == size) {
- timer_data->delay_on = state;
- mod_timer(_data->timer, jiffies + 1);
+ if (timer_data->delay_on != state) {
+ /* the new value differs from the previous */
+ timer_data->delay_on = state;
+
+ /* deactivate previous settings */
+ del_timer_sync(_data->timer);
+
+ /* try to activate hardware acceleration, if any */
+ if (!led_cdev->blink_set ||
+ led_cdev->blink_set(led_cdev,
+ _data->delay_on, _data->delay_off))
{
+ /* no hardware acceleration, blink via timer */
+ mod_timer(_data->timer, jiffies + 1);
+ }
+ }
ret = count;
}
@@ -110,8 +123,21 @@ static ssize_t led_delay_off_store(struc
count++;
if (count == size) {
- timer_data->delay_off = state;
- mod_timer(_data->timer, jiffies + 1);
+ if (timer_data->delay_off != state) {
+ /* the new value differs from the previous */
+ timer_data->delay_off = state;
+
+ /* deactivate previous settings */
+ del_timer_sync(_data->timer);
+
+ /* try to activate hardware acceleration, if any */
+ if (!led_cdev->blink_set ||
+ led_cdev->blink_set(led_cdev,
+ _data->delay_on, _data->delay_off))
{
+ /* no hardware
[PATCH 4/4] leds-clevo-mail: hw acceleration for Clevo mail LED driver
From: Márton Németh <[EMAIL PROTECTED]>
Add support for hardware accelerated LED blinking for the mail LED
commonly found on Clevo notebooks.
Signed-off-by: Márton Németh <[EMAIL PROTECTED]>
---
diff -uprN linux-2.6.24-rc1.c/drivers/leds/Kconfig
linux-2.6.24-rc1.d/drivers/leds/Kconfig
--- linux-2.6.24-rc1.c/drivers/leds/Kconfig 2007-10-28 09:09:45.0
+0100
+++ linux-2.6.24-rc1.d/drivers/leds/Kconfig 2007-10-28 09:09:25.0
+0100
@@ -122,9 +122,11 @@ config LEDS_CLEVO_MAIL
programs through the leds subsystem. This LED have three
known mode: off, blink at 0.5Hz and blink at 1Hz.
- As this LED cannot change it's brightness it blinks instead.
- The brightness value 0 means off, 1..127 means blink at 0.5Hz
- and 128..255 means blink at 1Hz.
+ The driver supports two kinds of interface: using ledtrig-timer
+ or through /sys/class/leds/clevo::mail/brightness. As this LED
+ cannot change it's brightness it blinks instead. The brightness
+ value 0 means off, 1..127 means blink at 0.5Hz and 128..255 means
+ blink at 1Hz.
This module can drive the mail LED for the following notebooks:
diff -uprN linux-2.6.24-rc1.c/drivers/leds/leds-clevo-mail.c
linux-2.6.24-rc1.d/drivers/leds/leds-clevo-mail.c
--- linux-2.6.24-rc1.c/drivers/leds/leds-clevo-mail.c 2007-10-28
10:20:49.0 +0100
+++ linux-2.6.24-rc1.d/drivers/leds/leds-clevo-mail.c 2007-10-28
10:20:55.0 +0100
@@ -92,9 +92,46 @@ static void clevo_mail_led_set(struct le
}
+static int clevo_mail_led_blink(struct led_classdev *led_cdev,
+ unsigned long* delay_on,
+ unsigned long* delay_off)
+{
+ int status = -EINVAL;
+
+ if (*delay_on == 0 /* ms */ && *delay_off == 0 /* ms */) {
+ /* Special case: the leds subsystem requested us to
+* chose one user friendly blinking of the LED, and
+* start it. Let's blink the led slowly (0.5Hz).
+*/
+ *delay_on = 1000; /* ms */
+ *delay_off = 1000; /* ms */
+ i8042_command(NULL, CLEVO_MAIL_LED_BLINK_0_5HZ);
+ status = 0;
+
+ } else if (*delay_on == 500 /* ms */ && *delay_off == 500 /* ms */) {
+ /* blink the led with 1Hz */
+ i8042_command(NULL, CLEVO_MAIL_LED_BLINK_1HZ);
+ status = 0;
+
+ } else if (*delay_on == 1000 /* ms */ && *delay_off == 1000 /* ms */) {
+ /* blink the led with 0.5Hz */
+ i8042_command(NULL, CLEVO_MAIL_LED_BLINK_0_5HZ);
+ status = 0;
+
+ } else {
+ printk(KERN_DEBUG KBUILD_MODNAME
+ ": clevo_mail_led_blink(..., %lu, %lu),"
+ " returning -EINVAL (unsupported)\n",
+ *delay_on, *delay_off);
+ }
+
+ return status;
+}
+
static struct led_classdev clevo_mail_led = {
.name = "clevo::mail",
.brightness_set = clevo_mail_led_set,
+ .blink_set = clevo_mail_led_blink,
};
static int __init clevo_mail_led_probe(struct platform_device *pdev)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/4] leds-clevo-mail: extend naming convention of leds subsystem
From: Márton Németh <[EMAIL PROTECTED]>
Extend the leds subsystem naming convention with the "function"
property. For example a LED can indicate if a new mail has arrived.
Signed-off-by: Márton Németh <[EMAIL PROTECTED]>
---
diff -uprN linux-2.6.24-rc1.a/Documentation/leds-class.txt
linux-2.6.24-rc1.b/Documentation/leds-class.txt
--- linux-2.6.24-rc1.a/Documentation/leds-class.txt 2007-10-28
09:01:56.0 +0100
+++ linux-2.6.24-rc1.b/Documentation/leds-class.txt 2007-10-28
09:20:07.0 +0100
@@ -39,7 +39,9 @@ LED Device Naming
Is currently of the form:
-"devicename:colour"
+"devicename:colour" or
+"devicename:colour:function" or
+"devicename::function"
There have been calls for LED properties such as colour to be exported as
individual led class attributes. As a solution which doesn't incur as much
diff -uprN linux-2.6.24-rc1.a/drivers/leds/leds-clevo-mail.c
linux-2.6.24-rc1.b/drivers/leds/leds-clevo-mail.c
--- linux-2.6.24-rc1.a/drivers/leds/leds-clevo-mail.c 2007-10-28
10:18:42.0 +0100
+++ linux-2.6.24-rc1.b/drivers/leds/leds-clevo-mail.c 2007-10-28
10:18:56.0 +0100
@@ -93,7 +93,7 @@ static void clevo_mail_led_set(struct le
}
static struct led_classdev clevo_mail_led = {
- .name = "clevo",
+ .name = "clevo::mail",
.brightness_set = clevo_mail_led_set,
};
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/4] leds-clevo-mail: driver for Clevo mail LED
From: Márton Németh <[EMAIL PROTECTED]>
The driver supports the mail LED commonly found on different Clevo notebooks.
The driver access the LED through the i8042 hardware which is handled by
the input subsystem.
Signed-off-by: Márton Németh <[EMAIL PROTECTED]>
---
diff -uprN linux-2.6.24-rc1.orig/drivers/leds/Kconfig
linux-2.6.24-rc1.a/drivers/leds/Kconfig
--- linux-2.6.24-rc1.orig/drivers/leds/Kconfig 2007-10-28 09:14:14.0
+0100
+++ linux-2.6.24-rc1.a/drivers/leds/Kconfig 2007-10-28 09:13:13.0
+0100
@@ -114,6 +114,30 @@ config LEDS_CM_X270
help
This option enables support for the CM-X270 LEDs.
+config LEDS_CLEVO_MAIL
+ tristate "Mail LED on Clevo notebook (EXPERIMENTAL)"
+ depends on LEDS_CLASS && X86 && SERIO_I8042 && DMI && EXPERIMENTAL
+ help
+ This driver makes the mail LED accessible from userspace
+ programs through the leds subsystem. This LED have three
+ known mode: off, blink at 0.5Hz and blink at 1Hz.
+
+ As this LED cannot change it's brightness it blinks instead.
+ The brightness value 0 means off, 1..127 means blink at 0.5Hz
+ and 128..255 means blink at 1Hz.
+
+ This module can drive the mail LED for the following notebooks:
+
+ Clevo D410J
+ Clevo D410V
+ Clevo D400V/D470V (not tested, but might work)
+ Clevo M540N
+ Clevo M5x0N (not tested, but might work)
+ Positivo Mobile (Clevo M5x0V)
+
+ To compile this driver as a module, choose M here: the
+ module will be called leds-clevo-mail.
+
comment "LED Triggers"
config LEDS_TRIGGERS
diff -uprN linux-2.6.24-rc1.orig/drivers/leds/leds-clevo-mail.c
linux-2.6.24-rc1.a/drivers/leds/leds-clevo-mail.c
--- linux-2.6.24-rc1.orig/drivers/leds/leds-clevo-mail.c1970-01-01
01:00:00.0 +0100
+++ linux-2.6.24-rc1.a/drivers/leds/leds-clevo-mail.c 2007-10-28
10:18:42.0 +0100
@@ -0,0 +1,182 @@
+
+#include
+
+#include
+#include
+#include
+
+#include
+#include
+
+#include
+
+#define CLEVO_MAIL_LED_OFF 0x0084
+#define CLEVO_MAIL_LED_BLINK_1HZ 0x008A
+#define CLEVO_MAIL_LED_BLINK_0_5HZ 0x0083
+
+MODULE_AUTHOR("Márton Németh <[EMAIL PROTECTED]>");
+MODULE_DESCRIPTION("Clevo mail LED driver");
+MODULE_LICENSE("GPL");
+
+static unsigned int __initdata nodetect;
+module_param_named(nodetect, nodetect, bool, 0);
+MODULE_PARM_DESC(nodetect, "Skip DMI hardware detection");
+
+static struct platform_device *pdev;
+
+static int __init clevo_mail_led_dmi_callback(const struct dmi_system_id *id)
+{
+ printk(KERN_INFO KBUILD_MODNAME ": '%s' found\n", id->ident);
+ return 1;
+}
+
+/*
+ * struct mail_led_whitelist - List of known good models
+ *
+ * Contains the known good models this driver is compatible with.
+ * When adding a new model try to be as strict as possible. This
+ * makes it possible to keep the false positives (the model is
+ * detected as working, but in reality it is not) as low as
+ * possible.
+ */
+static struct dmi_system_id __initdata mail_led_whitelist[] = {
+ {
+ .callback = clevo_mail_led_dmi_callback,
+ .ident = "Clevo D410J",
+ .matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, "VIA"),
+ DMI_MATCH(DMI_PRODUCT_NAME, "K8N800"),
+ DMI_MATCH(DMI_PRODUCT_VERSION, "VT8204B")
+ }
+ },
+ {
+ .callback = clevo_mail_led_dmi_callback,
+ .ident = "Clevo M5x0N",
+ .matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, "CLEVO Co."),
+ DMI_MATCH(DMI_PRODUCT_NAME, "M5x0N")
+ }
+ },
+ {
+ .callback = clevo_mail_led_dmi_callback,
+ .ident = "Positivo Mobile",
+ .matches = {
+ DMI_MATCH(DMI_BOARD_VENDOR, "CLEVO Co. "),
+ DMI_MATCH(DMI_BOARD_NAME, "M5X0V "),
+ DMI_MATCH(DMI_PRODUCT_NAME, "Positivo Mobile"),
+ DMI_MATCH(DMI_PRODUCT_VERSION, "VT6198")
+ }
+ },
+ {
+ .callback = clevo_mail_led_dmi_callback,
+ .ident = "Clevo D410V",
+ .matches = {
+ DMI_MATCH(DMI_BOARD_VENDOR, "Clevo, Co."),
+ DMI_MATCH(DMI_BOARD_NAME, "D400V/D470V"),
+ DMI_MATCH(DMI_BOARD_VERSION, "SS78B"),
+ DMI_MATCH(DMI_PRODUCT_VERSION, "Rev. A1")
+ }
+ },
+ { }
+};
+
+static void clevo_mail_led_set(struct led_classdev *led_cdev,
+ enum led_brightness value)
+{
+ if (value == LED_OFF)
+ i8042_command(NULL, CLEVO_MAIL_LED_OFF);
+ else if (value <= LED_HALF)
+ i8042_command(NULL, CLEVO_MAIL_LED_BLINK_0_5HZ);
+
Re: [PATCH 3/3] leds-clevo-mail: driver for Clevo mail LED
Richard Purdie wrote: > On Sun, 2007-10-21 at 14:55 +0200, Németh Márton wrote: >> diff -uprN linux-2.6.23.orig/drivers/leds/Kconfig >> linux-2.6.23/drivers/leds/Kconfig >> --- linux-2.6.23.orig/drivers/leds/Kconfig 2007-10-09 22:31:38.0 >> +0200 >> +++ linux-2.6.23/drivers/leds/Kconfig2007-10-21 12:04:50.0 >> +0200 >> @@ -101,6 +101,39 @@ config LEDS_GPIO >>outputs. To be useful the particular board must have LEDs >>and they must be connected to the GPIO lines. >> >> +config LEDS_CLEVO_MAIL >> +tristate "Mail LED on Clevo notebook (EXPERIMENTAL)" >> +depends on LEDS_CLASS && X86 && SERIO_I8042 && DMI && EXPERIMENTAL >> +help >> + This driver makes the mail LED accessible from userspace >> + programs through the leds subsystem. This LED have three >> + known mode: off, blink at 0.5Hz and blink at 1Hz. >> + >> + The driver supports two kinds of interface: using ledtrig-timer >> + or through /sys/class/leds/clevo::mail/brightness. As this LED >> + cannot change it's brightness it blinks instead. The brightness >> + value 0 means off, 1..127 means blink at 0.5Hz and 128..255 means >> + blink at 1Hz. > > Hmm, there really is no way to just turn the LED on? :( I looked up the printed manual (which can be also found at ftp://ftp.clevo.com.tw/USRMANUAL/D4x0J/D4x0J_CUG.zip ), page 9 contains the following information: LED Power & Communication Indicators: Icon | Color| Description -+--+--- Mail | Blinking Green & | New mail has arrived LED | Orange | +--+--- | Fast Blinking| New mail has arrived from users defined | Green & Orange | in the Special Group in the Auto Mail Checker +--+--- | Green| The (optional) Wireless LAN module is On +--+--- | Orange | The (optional) Bluetooth module is On +--+--- | Half Orange/ | Both the (optional) Wireless LAN and Bluetooth | Half Green | modules are On (see sidebar) -+--+--- Unfortunately I do not have these optional modules so I never saw the LED just on without blinking. I don't know if there is any hardware limitation turning on the LED without the optional modules. I will send a new patch collection which addresses the other mentioned topics. Márton Németh - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/3] leds-clevo-mail: driver for Clevo mail LED
Richard Purdie wrote: On Sun, 2007-10-21 at 14:55 +0200, Németh Márton wrote: diff -uprN linux-2.6.23.orig/drivers/leds/Kconfig linux-2.6.23/drivers/leds/Kconfig --- linux-2.6.23.orig/drivers/leds/Kconfig 2007-10-09 22:31:38.0 +0200 +++ linux-2.6.23/drivers/leds/Kconfig2007-10-21 12:04:50.0 +0200 @@ -101,6 +101,39 @@ config LEDS_GPIO outputs. To be useful the particular board must have LEDs and they must be connected to the GPIO lines. +config LEDS_CLEVO_MAIL +tristate Mail LED on Clevo notebook (EXPERIMENTAL) +depends on LEDS_CLASS X86 SERIO_I8042 DMI EXPERIMENTAL +help + This driver makes the mail LED accessible from userspace + programs through the leds subsystem. This LED have three + known mode: off, blink at 0.5Hz and blink at 1Hz. + + The driver supports two kinds of interface: using ledtrig-timer + or through /sys/class/leds/clevo::mail/brightness. As this LED + cannot change it's brightness it blinks instead. The brightness + value 0 means off, 1..127 means blink at 0.5Hz and 128..255 means + blink at 1Hz. Hmm, there really is no way to just turn the LED on? :( I looked up the printed manual (which can be also found at ftp://ftp.clevo.com.tw/USRMANUAL/D4x0J/D4x0J_CUG.zip ), page 9 contains the following information: LED Power Communication Indicators: Icon | Color| Description -+--+--- Mail | Blinking Green | New mail has arrived LED | Orange | +--+--- | Fast Blinking| New mail has arrived from users defined | Green Orange | in the Special Group in the Auto Mail Checker +--+--- | Green| The (optional) Wireless LAN module is On +--+--- | Orange | The (optional) Bluetooth module is On +--+--- | Half Orange/ | Both the (optional) Wireless LAN and Bluetooth | Half Green | modules are On (see sidebar) -+--+--- Unfortunately I do not have these optional modules so I never saw the LED just on without blinking. I don't know if there is any hardware limitation turning on the LED without the optional modules. I will send a new patch collection which addresses the other mentioned topics. Márton Németh - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/4] leds-clevo-mail: driver for Clevo mail LED
From: Márton Németh [EMAIL PROTECTED]
The driver supports the mail LED commonly found on different Clevo notebooks.
The driver access the LED through the i8042 hardware which is handled by
the input subsystem.
Signed-off-by: Márton Németh [EMAIL PROTECTED]
---
diff -uprN linux-2.6.24-rc1.orig/drivers/leds/Kconfig
linux-2.6.24-rc1.a/drivers/leds/Kconfig
--- linux-2.6.24-rc1.orig/drivers/leds/Kconfig 2007-10-28 09:14:14.0
+0100
+++ linux-2.6.24-rc1.a/drivers/leds/Kconfig 2007-10-28 09:13:13.0
+0100
@@ -114,6 +114,30 @@ config LEDS_CM_X270
help
This option enables support for the CM-X270 LEDs.
+config LEDS_CLEVO_MAIL
+ tristate Mail LED on Clevo notebook (EXPERIMENTAL)
+ depends on LEDS_CLASS X86 SERIO_I8042 DMI EXPERIMENTAL
+ help
+ This driver makes the mail LED accessible from userspace
+ programs through the leds subsystem. This LED have three
+ known mode: off, blink at 0.5Hz and blink at 1Hz.
+
+ As this LED cannot change it's brightness it blinks instead.
+ The brightness value 0 means off, 1..127 means blink at 0.5Hz
+ and 128..255 means blink at 1Hz.
+
+ This module can drive the mail LED for the following notebooks:
+
+ Clevo D410J
+ Clevo D410V
+ Clevo D400V/D470V (not tested, but might work)
+ Clevo M540N
+ Clevo M5x0N (not tested, but might work)
+ Positivo Mobile (Clevo M5x0V)
+
+ To compile this driver as a module, choose M here: the
+ module will be called leds-clevo-mail.
+
comment LED Triggers
config LEDS_TRIGGERS
diff -uprN linux-2.6.24-rc1.orig/drivers/leds/leds-clevo-mail.c
linux-2.6.24-rc1.a/drivers/leds/leds-clevo-mail.c
--- linux-2.6.24-rc1.orig/drivers/leds/leds-clevo-mail.c1970-01-01
01:00:00.0 +0100
+++ linux-2.6.24-rc1.a/drivers/leds/leds-clevo-mail.c 2007-10-28
10:18:42.0 +0100
@@ -0,0 +1,182 @@
+
+#include linux/module.h
+
+#include linux/platform_device.h
+#include linux/err.h
+#include linux/leds.h
+
+#include linux/io.h
+#include linux/dmi.h
+
+#include linux/i8042.h
+
+#define CLEVO_MAIL_LED_OFF 0x0084
+#define CLEVO_MAIL_LED_BLINK_1HZ 0x008A
+#define CLEVO_MAIL_LED_BLINK_0_5HZ 0x0083
+
+MODULE_AUTHOR(Márton Németh [EMAIL PROTECTED]);
+MODULE_DESCRIPTION(Clevo mail LED driver);
+MODULE_LICENSE(GPL);
+
+static unsigned int __initdata nodetect;
+module_param_named(nodetect, nodetect, bool, 0);
+MODULE_PARM_DESC(nodetect, Skip DMI hardware detection);
+
+static struct platform_device *pdev;
+
+static int __init clevo_mail_led_dmi_callback(const struct dmi_system_id *id)
+{
+ printk(KERN_INFO KBUILD_MODNAME : '%s' found\n, id-ident);
+ return 1;
+}
+
+/*
+ * struct mail_led_whitelist - List of known good models
+ *
+ * Contains the known good models this driver is compatible with.
+ * When adding a new model try to be as strict as possible. This
+ * makes it possible to keep the false positives (the model is
+ * detected as working, but in reality it is not) as low as
+ * possible.
+ */
+static struct dmi_system_id __initdata mail_led_whitelist[] = {
+ {
+ .callback = clevo_mail_led_dmi_callback,
+ .ident = Clevo D410J,
+ .matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, VIA),
+ DMI_MATCH(DMI_PRODUCT_NAME, K8N800),
+ DMI_MATCH(DMI_PRODUCT_VERSION, VT8204B)
+ }
+ },
+ {
+ .callback = clevo_mail_led_dmi_callback,
+ .ident = Clevo M5x0N,
+ .matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, CLEVO Co.),
+ DMI_MATCH(DMI_PRODUCT_NAME, M5x0N)
+ }
+ },
+ {
+ .callback = clevo_mail_led_dmi_callback,
+ .ident = Positivo Mobile,
+ .matches = {
+ DMI_MATCH(DMI_BOARD_VENDOR, CLEVO Co. ),
+ DMI_MATCH(DMI_BOARD_NAME, M5X0V ),
+ DMI_MATCH(DMI_PRODUCT_NAME, Positivo Mobile),
+ DMI_MATCH(DMI_PRODUCT_VERSION, VT6198)
+ }
+ },
+ {
+ .callback = clevo_mail_led_dmi_callback,
+ .ident = Clevo D410V,
+ .matches = {
+ DMI_MATCH(DMI_BOARD_VENDOR, Clevo, Co.),
+ DMI_MATCH(DMI_BOARD_NAME, D400V/D470V),
+ DMI_MATCH(DMI_BOARD_VERSION, SS78B),
+ DMI_MATCH(DMI_PRODUCT_VERSION, Rev. A1)
+ }
+ },
+ { }
+};
+
+static void clevo_mail_led_set(struct led_classdev *led_cdev,
+ enum led_brightness value)
+{
+ if (value == LED_OFF)
+ i8042_command(NULL, CLEVO_MAIL_LED_OFF);
+ else if (value = LED_HALF)
+ i8042_command(NULL,
[PATCH 2/4] leds-clevo-mail: extend naming convention of leds subsystem
From: Márton Németh [EMAIL PROTECTED]
Extend the leds subsystem naming convention with the function
property. For example a LED can indicate if a new mail has arrived.
Signed-off-by: Márton Németh [EMAIL PROTECTED]
---
diff -uprN linux-2.6.24-rc1.a/Documentation/leds-class.txt
linux-2.6.24-rc1.b/Documentation/leds-class.txt
--- linux-2.6.24-rc1.a/Documentation/leds-class.txt 2007-10-28
09:01:56.0 +0100
+++ linux-2.6.24-rc1.b/Documentation/leds-class.txt 2007-10-28
09:20:07.0 +0100
@@ -39,7 +39,9 @@ LED Device Naming
Is currently of the form:
-devicename:colour
+devicename:colour or
+devicename:colour:function or
+devicename::function
There have been calls for LED properties such as colour to be exported as
individual led class attributes. As a solution which doesn't incur as much
diff -uprN linux-2.6.24-rc1.a/drivers/leds/leds-clevo-mail.c
linux-2.6.24-rc1.b/drivers/leds/leds-clevo-mail.c
--- linux-2.6.24-rc1.a/drivers/leds/leds-clevo-mail.c 2007-10-28
10:18:42.0 +0100
+++ linux-2.6.24-rc1.b/drivers/leds/leds-clevo-mail.c 2007-10-28
10:18:56.0 +0100
@@ -93,7 +93,7 @@ static void clevo_mail_led_set(struct le
}
static struct led_classdev clevo_mail_led = {
- .name = clevo,
+ .name = clevo::mail,
.brightness_set = clevo_mail_led_set,
};
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3/4] leds-clevo-mail: hw accelerated LED blink extension
From: Márton Németh [EMAIL PROTECTED]
Extends the leds subsystem with a blink_set() callback function which can
be optionally implemented by a LED driver. If implemented, the driver can use
the hardware acceleration for blinking a LED.
Signed-off-by: Márton Németh [EMAIL PROTECTED]
---
diff -uprN linux-2.6.24-rc1.b/Documentation/leds-class.txt
linux-2.6.24-rc1.c/Documentation/leds-class.txt
--- linux-2.6.24-rc1.b/Documentation/leds-class.txt 2007-10-28
09:20:07.0 +0100
+++ linux-2.6.24-rc1.c/Documentation/leds-class.txt 2007-10-28
09:35:54.0 +0100
@@ -49,6 +49,27 @@ overhead, I suggest these become part of
above leaves scope for further attributes should they be needed.
+Hardware accelerated blink of LEDs
+==
+
+Some LEDs can be programmed to blink without any CPU interaction. To
+support this feature, a LED driver can optionally implement the
+blink_set() function (see linux/leds.h). If implemeted, the
+ledtrig-timer tries to use it. The blink_set() function should return
+0 if the blink setting is supported, or -EINVAL otherwise, which means
+that the LED will be turned on and off from software by the leds
+subsystem.
+
+The blink_set() function should choose a user friendly blinking
+value if it is called with *delay_on==0 *delay_off==0 parameters. In
+this case the driver should give back the chosen value through delay_on
+and delay_off parameters to the leds subsystem.
+
+Any call to the brightness_set() callback function should cancel the
+previously programmed hardware blinking function so setting the brightness
+to 0 can also cancel the blinking of the LED.
+
+
Known Issues
@@ -57,10 +78,6 @@ would cause nightmare dependency issues.
compared to the benefits the simple trigger functionality brings. The
rest of the LED subsystem can be modular.
-Some leds can be programmed to flash in hardware. As this isn't a generic
-LED device property, this should be exported as a device specific sysfs
-attribute rather than part of the class if this functionality is required.
-
Future Development
==
diff -uprN linux-2.6.24-rc1.b/drivers/leds/Kconfig
linux-2.6.24-rc1.c/drivers/leds/Kconfig
--- linux-2.6.24-rc1.b/drivers/leds/Kconfig 2007-10-28 09:13:13.0
+0100
+++ linux-2.6.24-rc1.c/drivers/leds/Kconfig 2007-10-28 09:09:45.0
+0100
@@ -152,7 +152,11 @@ config LEDS_TRIGGER_TIMER
depends on LEDS_TRIGGERS
help
This allows LEDs to be controlled by a programmable timer
- via sysfs. If unsure, say Y.
+ via sysfs. Some LED hardware can be programmed to start
+ blinking the LED without any further software interaction.
+ For more details read Documentation/leds-class.txt.
+
+ If unsure, say Y.
config LEDS_TRIGGER_IDE_DISK
bool LED IDE Disk Trigger
diff -uprN linux-2.6.24-rc1.b/drivers/leds/ledtrig-timer.c
linux-2.6.24-rc1.c/drivers/leds/ledtrig-timer.c
--- linux-2.6.24-rc1.b/drivers/leds/ledtrig-timer.c 2007-10-28
09:01:56.0 +0100
+++ linux-2.6.24-rc1.c/drivers/leds/ledtrig-timer.c 2007-10-28
08:16:50.0 +0100
@@ -77,8 +77,21 @@ static ssize_t led_delay_on_store(struct
count++;
if (count == size) {
- timer_data-delay_on = state;
- mod_timer(timer_data-timer, jiffies + 1);
+ if (timer_data-delay_on != state) {
+ /* the new value differs from the previous */
+ timer_data-delay_on = state;
+
+ /* deactivate previous settings */
+ del_timer_sync(timer_data-timer);
+
+ /* try to activate hardware acceleration, if any */
+ if (!led_cdev-blink_set ||
+ led_cdev-blink_set(led_cdev,
+ timer_data-delay_on, timer_data-delay_off))
{
+ /* no hardware acceleration, blink via timer */
+ mod_timer(timer_data-timer, jiffies + 1);
+ }
+ }
ret = count;
}
@@ -110,8 +123,21 @@ static ssize_t led_delay_off_store(struc
count++;
if (count == size) {
- timer_data-delay_off = state;
- mod_timer(timer_data-timer, jiffies + 1);
+ if (timer_data-delay_off != state) {
+ /* the new value differs from the previous */
+ timer_data-delay_off = state;
+
+ /* deactivate previous settings */
+ del_timer_sync(timer_data-timer);
+
+ /* try to activate hardware acceleration, if any */
+ if (!led_cdev-blink_set ||
+ led_cdev-blink_set(led_cdev,
+ timer_data-delay_on, timer_data-delay_off))
{
+
[PATCH 4/4] leds-clevo-mail: hw acceleration for Clevo mail LED driver
From: Márton Németh [EMAIL PROTECTED]
Add support for hardware accelerated LED blinking for the mail LED
commonly found on Clevo notebooks.
Signed-off-by: Márton Németh [EMAIL PROTECTED]
---
diff -uprN linux-2.6.24-rc1.c/drivers/leds/Kconfig
linux-2.6.24-rc1.d/drivers/leds/Kconfig
--- linux-2.6.24-rc1.c/drivers/leds/Kconfig 2007-10-28 09:09:45.0
+0100
+++ linux-2.6.24-rc1.d/drivers/leds/Kconfig 2007-10-28 09:09:25.0
+0100
@@ -122,9 +122,11 @@ config LEDS_CLEVO_MAIL
programs through the leds subsystem. This LED have three
known mode: off, blink at 0.5Hz and blink at 1Hz.
- As this LED cannot change it's brightness it blinks instead.
- The brightness value 0 means off, 1..127 means blink at 0.5Hz
- and 128..255 means blink at 1Hz.
+ The driver supports two kinds of interface: using ledtrig-timer
+ or through /sys/class/leds/clevo::mail/brightness. As this LED
+ cannot change it's brightness it blinks instead. The brightness
+ value 0 means off, 1..127 means blink at 0.5Hz and 128..255 means
+ blink at 1Hz.
This module can drive the mail LED for the following notebooks:
diff -uprN linux-2.6.24-rc1.c/drivers/leds/leds-clevo-mail.c
linux-2.6.24-rc1.d/drivers/leds/leds-clevo-mail.c
--- linux-2.6.24-rc1.c/drivers/leds/leds-clevo-mail.c 2007-10-28
10:20:49.0 +0100
+++ linux-2.6.24-rc1.d/drivers/leds/leds-clevo-mail.c 2007-10-28
10:20:55.0 +0100
@@ -92,9 +92,46 @@ static void clevo_mail_led_set(struct le
}
+static int clevo_mail_led_blink(struct led_classdev *led_cdev,
+ unsigned long* delay_on,
+ unsigned long* delay_off)
+{
+ int status = -EINVAL;
+
+ if (*delay_on == 0 /* ms */ *delay_off == 0 /* ms */) {
+ /* Special case: the leds subsystem requested us to
+* chose one user friendly blinking of the LED, and
+* start it. Let's blink the led slowly (0.5Hz).
+*/
+ *delay_on = 1000; /* ms */
+ *delay_off = 1000; /* ms */
+ i8042_command(NULL, CLEVO_MAIL_LED_BLINK_0_5HZ);
+ status = 0;
+
+ } else if (*delay_on == 500 /* ms */ *delay_off == 500 /* ms */) {
+ /* blink the led with 1Hz */
+ i8042_command(NULL, CLEVO_MAIL_LED_BLINK_1HZ);
+ status = 0;
+
+ } else if (*delay_on == 1000 /* ms */ *delay_off == 1000 /* ms */) {
+ /* blink the led with 0.5Hz */
+ i8042_command(NULL, CLEVO_MAIL_LED_BLINK_0_5HZ);
+ status = 0;
+
+ } else {
+ printk(KERN_DEBUG KBUILD_MODNAME
+ : clevo_mail_led_blink(..., %lu, %lu),
+ returning -EINVAL (unsupported)\n,
+ *delay_on, *delay_off);
+ }
+
+ return status;
+}
+
static struct led_classdev clevo_mail_led = {
.name = clevo::mail,
.brightness_set = clevo_mail_led_set,
+ .blink_set = clevo_mail_led_blink,
};
static int __init clevo_mail_led_probe(struct platform_device *pdev)
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] mac80211: fix printk() format string
From: Márton Németh [EMAIL PROTECTED] Get rid of the following compiler warning message: net/mac80211/ieee80211_sta.c: In function 'ieee80211_rx_mgmt_assoc_resp': net/mac80211/ieee80211_sta.c:1187: warning: format '%d' expects type 'int', but argument 7 has type 'long unsigned int' Signed-off-by: Márton Németh [EMAIL PROTECTED] --- --- linux-2.6.24-rc1/net/mac80211/ieee80211_sta.c.orig 2007-10-24 05:50:57.0 +0200 +++ linux-2.6.24-rc1/net/mac80211/ieee80211_sta.c 2007-10-28 11:20:23.0 +0100 @@ -1182,7 +1182,7 @@ static void ieee80211_rx_mgmt_assoc_resp aid = le16_to_cpu(mgmt-u.assoc_resp.aid); printk(KERN_DEBUG %s: RX %sssocResp from %s (capab=0x%x - status=%d aid=%d)\n, + status=%d aid=%lu)\n, dev-name, reassoc ? Rea : A, print_mac(mac, mgmt-sa), capab_info, status_code, aid ~(BIT(15) | BIT(14))); - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/3] leds-clevo-mail: driver for Clevo mail LED
From: Márton Németh <[EMAIL PROTECTED]>
The driver supports the mail LED commonly found on different Clevo notebooks.
The driver access the LED through the i8042 hardware and implements the support
for
hardware accelerated blink function.
Signed-off-by: Márton Németh <[EMAIL PROTECTED]>
---
diff -uprN linux-2.6.23.orig/Documentation/leds-class.txt
linux-2.6.23/Documentation/leds-class.txt
--- linux-2.6.23.orig/Documentation/leds-class.txt 2007-10-09
22:31:38.0 +0200
+++ linux-2.6.23/Documentation/leds-class.txt 2007-10-21 10:45:35.0
+0200
@@ -39,7 +39,9 @@ LED Device Naming
Is currently of the form:
-"devicename:colour"
+"devicename:colour" or
+"devicename:colour:type" or
+"devicename::type"
There have been calls for LED properties such as colour to be exported as
individual led class attributes. As a solution which doesn't incur as much
diff -uprN linux-2.6.23.orig/drivers/leds/Kconfig
linux-2.6.23/drivers/leds/Kconfig
--- linux-2.6.23.orig/drivers/leds/Kconfig 2007-10-09 22:31:38.0
+0200
+++ linux-2.6.23/drivers/leds/Kconfig 2007-10-21 12:04:50.0 +0200
@@ -101,6 +101,39 @@ config LEDS_GPIO
outputs. To be useful the particular board must have LEDs
and they must be connected to the GPIO lines.
+config LEDS_CLEVO_MAIL
+ tristate "Mail LED on Clevo notebook (EXPERIMENTAL)"
+ depends on LEDS_CLASS && X86 && SERIO_I8042 && DMI && EXPERIMENTAL
+ help
+ This driver makes the mail LED accessible from userspace
+ programs through the leds subsystem. This LED have three
+ known mode: off, blink at 0.5Hz and blink at 1Hz.
+
+ The driver supports two kinds of interface: using ledtrig-timer
+ or through /sys/class/leds/clevo::mail/brightness. As this LED
+ cannot change it's brightness it blinks instead. The brightness
+ value 0 means off, 1..127 means blink at 0.5Hz and 128..255 means
+ blink at 1Hz.
+
+ Example to start blink at 0.5Hz:
+ echo 1 >/sys/class/leds/clevo::mail/brightness
+ - or -
+ echo timer >/sys/class/leds/clevo::mail/trigger
+ echo 1000 >/sys/class/leds/clevo::mail/delay_on
+ echo 1000 >/sys/class/leds/clevo::mail/delay_off
+
+ This module can drive the mail LED for the following notebooks:
+
+ Clevo D410J
+ Clevo D410V
+ Clevo D400V/D470V (not tested, but might work)
+ Clevo M540N
+ Clevo M5x0N (not tested, but might work)
+ Positivo Mobile (Clevo M5x0V)
+
+ To compile this driver as a module, choose M here: the
+ module will be called leds-clevo-mail.
+
comment "LED Triggers"
config LEDS_TRIGGERS
diff -uprN linux-2.6.23.orig/drivers/leds/leds-clevo-mail.c
linux-2.6.23/drivers/leds/leds-clevo-mail.c
--- linux-2.6.23.orig/drivers/leds/leds-clevo-mail.c1970-01-01
01:00:00.0 +0100
+++ linux-2.6.23/drivers/leds/leds-clevo-mail.c 2007-10-21 10:49:32.0
+0200
@@ -0,0 +1,210 @@
+
+#include
+
+#include
+#include
+#include
+
+#include
+#include
+
+#include
+
+#define HANDLED0
+
+#define CLEVO_MAIL_LED_OFF 0x0084
+#define CLEVO_MAIL_LED_BLINK_1HZ 0x008A
+#define CLEVO_MAIL_LED_BLINK_0_5HZ 0x0083
+
+MODULE_AUTHOR("Márton Németh <[EMAIL PROTECTED]>");
+MODULE_DESCRIPTION("Clevo mail LED driver");
+MODULE_LICENSE("GPL");
+
+static unsigned int __initdata nodetect;
+module_param_named(nodetect, nodetect, bool, 0);
+MODULE_PARM_DESC(nodetect, "Skip DMI hardware detection");
+
+static struct platform_device *pdev;
+
+static int __init clevo_mail_led_dmi_callback(struct dmi_system_id *id)
+{
+ printk(KERN_INFO KBUILD_MODNAME ": '%s' found\n", id->ident);
+ return 1;
+}
+
+/*
+ * struct mail_led_whitelist - List of known good models
+ *
+ * Contains the known good models this driver is compatible with.
+ * When adding a new model try to be as strict as possible. This
+ * makes it possible to keep the false positives (the model is
+ * detected as working, but in reality it is not) as low as
+ * possible.
+ */
+static struct dmi_system_id __initdata mail_led_whitelist[] = {
+ {
+ .callback = clevo_mail_led_dmi_callback,
+ .ident = "Clevo D410J",
+ .matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, "VIA"),
+ DMI_MATCH(DMI_PRODUCT_NAME, "K8N800"),
+ DMI_MATCH(DMI_PRODUCT_VERSION, "VT8204B")
+ }
+ },
+ {
+ .callback = clevo_mail_led_dmi_callback,
+ .ident = "Clevo M5x0N",
+ .matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, "CLEVO Co."),
+ DMI_MATCH(DMI_PRODUCT_NAME, "M5x0N")
+ }
+ },
+ {
+ .callback = clevo_mail_led_dmi_callback,
+ .ident =
Re: [PATCH 3/3] leds-clevo-mail: driver for Clevo mail LED
Randy Dunlap wrote:
> On Fri, 19 Oct 2007 20:52:52 +0200 Németh Márton wrote:
>
>> From: Márton Németh <[EMAIL PROTECTED]>
>>
>> The driver supports the mail LED commonly found on different Clevo notebooks.
>> The driver access the LED through the i8042 hardware and implements the
>> support for
>> hardware accelerated blink function.
>>
>> Signed-off-by: Márton Németh <[EMAIL PROTECTED]>
>> ---
>> diff -uprN linux-2.6.23.orig/drivers/leds/Kconfig
>> linux-2.6.23/drivers/leds/Kconfig
>> --- linux-2.6.23.orig/drivers/leds/Kconfig 2007-10-09 22:31:38.0
>> +0200
>> +++ linux-2.6.23/drivers/leds/Kconfig2007-10-18 07:20:12.0
>> +0200
>> @@ -101,6 +101,26 @@ config LEDS_GPIO
>>outputs. To be useful the particular board must have LEDs
>>and they must be connected to the GPIO lines.
>>
>> +config LEDS_CLEVO_MAIL
>> +tristate "Mail LED on Clevo notebook (EXPERIMENTAL)"
>> +depends on LEDS_CLASS && X86 && SERIO_I8042 && DMI && EXPERIMENTAL
>> +help
>> + This driver makes the mail LED accessible from userspace
>> + programs through the leds subsystem. This LED can blink at
>> + about 0.5Hz and 1Hz.
>
> ?:
> can blink 1 time every 1 or 2 seconds.
It has three modes, I'll try to explain this in more detail in my next patch
version.
>
>> + This module can drive the mail LED for the following notebooks:
>> +
>> +Clevo D410J
>> +Clevo D410V
>> +Clevo D400V/D470V (not tested, but might work)
>> +Clevo M540N
>> +Clevo M5x0N (not tested, but might work)
>> +Positivo Mobile (Clevo M5x0V)
>> +
>> + To compile this driver as a module, choose M here: the
>> + module will be called leds-clevo-mail.
>> +
> comment "LED Triggers"
>
> config LEDS_TRIGGERS
I'll document the led trigger extension in more detail in the next
version of the "[PATCH 2/3] leds-clevo-mail: hw accelerated LED blink
extension",
in drivers/leds/Kconfig.
>> +#define TRUE1
>> +#define FALSE 0
>
> Just use true / false.
I'll delete these #defines.
>> +#define HANDLED 0
>> +
>> +#define CLEVO_MAIL_LED_OFF 0x0084
>> +#define CLEVO_MAIL_LED_BLINK_1HZ0x008A
>> +#define CLEVO_MAIL_LED_BLINK_0_5HZ 0x0083
>> +
>> +#define MODULE_FNAME"leds-clevo-mail.c"
>> +#define DRVNAME "clevo-mail-led"
>
> Kbuild provides KBUILD_BASENAME and KBUILD_MODNAME. Can you use
> one of those?
I'll use KBUILD_MODNAME instead.
>> +#define NO_RESOURCESNULL
>
> Just use NULL.
I'll delete NO_RESOURCES.
>> +static int __init clevo_mail_led_dmi_callback(struct dmi_system_id *id)
>> +{
>> +printk(KERN_INFO MODULE_FNAME ": '%s' found\n", id->ident);
>
> MODULE_FNAME string looks too long and out of place here.
I'll replace MODULE_FNAME with KBUILD_MODNAME. Is this what you mean?
>> +/**
>
> /** introduces kernel-doc, but there is no following kernel-doc,
> so just use /*, please.
OK, I'll replace.
>> +static struct led_classdev clevo_mail_led = {
>> +.name = "clevo::mail",
>
> What's the purpose of the "::"?
Here I have the problem that the different laptop models have
different colors of mail LED. So I left out the color and
introduced the type of the LED which is "mail". I'll try to
document this in Documents/leds-class.txt
>> +static struct platform_driver clevo_mail_led_driver = {
>> +.probe = clevo_mail_led_probe,
>> +.remove = clevo_mail_led_remove,
>> +#ifdef CONFIG_PM
>> +.suspend= clevo_mail_led_suspend,
>> +.resume = clevo_mail_led_resume,
>> +#endif
>> +.driver = {
>> +.name = DRVNAME,
>> +},
>> +};
>
> We prefer to have clevo_mail_led_susped() and _resume() defined
> all the time, so that the above ifdef & endif can go away, so
> do more like:
>
> #ifdef CONFIG_PM
> /* those functions as you have them */
> #else
> #define clevo_mail_led_suspendNULL
> #define clevo_mail_led_resume NULL
> #endif
I'll change this to what you proposed.
>> +if (!count) {
>> +return -ENODEV;
>> +}
>
> Don't use braces on one-statement/one-line "blocks."
Re: [PATCH 2/3] leds-clevo-mail: hw accelerated LED blink extension
From: Márton Németh <[EMAIL PROTECTED]>
Extends the leds subsystem with a blink_set() callback function which can
be optionally implemented by a LED driver. If implemented, the driver can use
the hardware acceleration for blinking a LED.
Signed-off-by: Márton Németh <[EMAIL PROTECTED]>
---
diff -uprN linux-2.6.23.orig/Documentation/leds-class.txt
linux-2.6.23/Documentation/leds-class.txt
--- linux-2.6.23.orig/Documentation/leds-class.txt 2007-10-09
22:31:38.0 +0200
+++ linux-2.6.23/Documentation/leds-class.txt 2007-10-21 10:45:35.0
+0200
@@ -47,6 +49,19 @@ overhead, I suggest these become part of
above leaves scope for further attributes should they be needed.
+
+Hardware accelerated blink of LEDs
+==
+
+Some LEDs can be programmed to blink without any CPU interaction. To
+support this feature, a LED driver can optionally implement the
+blink_set() function (see ). If implemeted, the
+ledtrig-timer tries to use it. The blink_set() function should return
+0 if the blink setting is supported, or -EINVAL otherwise, which means
+that the LED will be turned on and off from software by the leds
+subsystem.
+
+
Known Issues
@@ -55,10 +70,6 @@ would cause nightmare dependency issues.
compared to the benefits the simple trigger functionality brings. The
rest of the LED subsystem can be modular.
-Some leds can be programmed to flash in hardware. As this isn't a generic
-LED device property, this should be exported as a device specific sysfs
-attribute rather than part of the class if this functionality is required.
-
Future Development
==
diff -uprN linux-2.6.23.orig/drivers/leds/Kconfig
linux-2.6.23/drivers/leds/Kconfig
--- linux-2.6.23.orig/drivers/leds/Kconfig 2007-10-09 22:31:38.0
+0200
+++ linux-2.6.23/drivers/leds/Kconfig 2007-10-21 12:04:50.0 +0200
@@ -115,7 +148,11 @@ config LEDS_TRIGGER_TIMER
depends on LEDS_TRIGGERS
help
This allows LEDs to be controlled by a programmable timer
- via sysfs. If unsure, say Y.
+ via sysfs. Some LED hardware can be programmed to start
+ blinking the LED without any further software interaction.
+ For more details read Documentation/leds-class.txt.
+
+ If unsure, say Y.
config LEDS_TRIGGER_IDE_DISK
bool "LED IDE Disk Trigger"
diff -uprN linux-2.6.23.orig/drivers/leds/ledtrig-timer.c
linux-2.6.23/drivers/leds/ledtrig-timer.c
--- linux-2.6.23.orig/drivers/leds/ledtrig-timer.c 2007-10-09
22:31:38.0 +0200
+++ linux-2.6.23/drivers/leds/ledtrig-timer.c 2007-10-18 18:21:34.0
+0200
@@ -77,8 +77,21 @@ static ssize_t led_delay_on_store(struct
count++;
if (count == size) {
- timer_data->delay_on = state;
- mod_timer(_data->timer, jiffies + 1);
+ if (timer_data->delay_on != state) {
+ /* the new value differs from the previous */
+ timer_data->delay_on = state;
+
+ /* deactivate previous settings */
+ del_timer_sync(_data->timer);
+
+ /* try to activate hardware acceleration, if any */
+ if (!led_cdev->blink_set ||
+ led_cdev->blink_set(led_cdev,
+ timer_data->delay_on, timer_data->delay_off)) {
+ /* no hardware acceleration, blink via timer */
+ mod_timer(_data->timer, jiffies + 1);
+ }
+ }
ret = count;
}
@@ -110,8 +123,21 @@ static ssize_t led_delay_off_store(struc
count++;
if (count == size) {
- timer_data->delay_off = state;
- mod_timer(_data->timer, jiffies + 1);
+ if (timer_data->delay_off != state) {
+ /* the new value differs from the previous */
+ timer_data->delay_off = state;
+
+ /* deactivate previous settings */
+ del_timer_sync(_data->timer);
+
+ /* try to activate hardware acceleration, if any */
+ if (!led_cdev->blink_set ||
+ led_cdev->blink_set(led_cdev,
+ timer_data->delay_on, timer_data->delay_off)) {
+ /* no hardware acceleration, blink via timer */
+ mod_timer(_data->timer, jiffies + 1);
+ }
+ }
ret = count;
}
diff -uprN linux-2.6.23.orig/include/linux/leds.h
linux-2.6.23/include/linux/leds.h
--- linux-2.6.23.orig/include/linux/leds.h 2007-10-09 22:31:38.0
+0200
+++ linux-2.6.23/include/linux/leds.h 2007-10-18 18:21:34.0 +0200
@@ -37,6 +37,10 @@ struct led_classdev {
void
Re: [PATCH 3/3] leds-clevo-mail: driver for Clevo mail LED
Randy Dunlap wrote:
On Fri, 19 Oct 2007 20:52:52 +0200 Németh Márton wrote:
From: Márton Németh [EMAIL PROTECTED]
The driver supports the mail LED commonly found on different Clevo notebooks.
The driver access the LED through the i8042 hardware and implements the
support for
hardware accelerated blink function.
Signed-off-by: Márton Németh [EMAIL PROTECTED]
---
diff -uprN linux-2.6.23.orig/drivers/leds/Kconfig
linux-2.6.23/drivers/leds/Kconfig
--- linux-2.6.23.orig/drivers/leds/Kconfig 2007-10-09 22:31:38.0
+0200
+++ linux-2.6.23/drivers/leds/Kconfig2007-10-18 07:20:12.0
+0200
@@ -101,6 +101,26 @@ config LEDS_GPIO
outputs. To be useful the particular board must have LEDs
and they must be connected to the GPIO lines.
+config LEDS_CLEVO_MAIL
+tristate Mail LED on Clevo notebook (EXPERIMENTAL)
+depends on LEDS_CLASS X86 SERIO_I8042 DMI EXPERIMENTAL
+help
+ This driver makes the mail LED accessible from userspace
+ programs through the leds subsystem. This LED can blink at
+ about 0.5Hz and 1Hz.
?:
can blink 1 time every 1 or 2 seconds.
It has three modes, I'll try to explain this in more detail in my next patch
version.
+ This module can drive the mail LED for the following notebooks:
+
+Clevo D410J
+Clevo D410V
+Clevo D400V/D470V (not tested, but might work)
+Clevo M540N
+Clevo M5x0N (not tested, but might work)
+Positivo Mobile (Clevo M5x0V)
+
+ To compile this driver as a module, choose M here: the
+ module will be called leds-clevo-mail.
+
comment LED Triggers
config LEDS_TRIGGERS
I'll document the led trigger extension in more detail in the next
version of the [PATCH 2/3] leds-clevo-mail: hw accelerated LED blink
extension,
in drivers/leds/Kconfig.
+#define TRUE1
+#define FALSE 0
Just use true / false.
I'll delete these #defines.
+#define HANDLED 0
+
+#define CLEVO_MAIL_LED_OFF 0x0084
+#define CLEVO_MAIL_LED_BLINK_1HZ0x008A
+#define CLEVO_MAIL_LED_BLINK_0_5HZ 0x0083
+
+#define MODULE_FNAMEleds-clevo-mail.c
+#define DRVNAME clevo-mail-led
Kbuild provides KBUILD_BASENAME and KBUILD_MODNAME. Can you use
one of those?
I'll use KBUILD_MODNAME instead.
+#define NO_RESOURCESNULL
Just use NULL.
I'll delete NO_RESOURCES.
+static int __init clevo_mail_led_dmi_callback(struct dmi_system_id *id)
+{
+printk(KERN_INFO MODULE_FNAME : '%s' found\n, id-ident);
MODULE_FNAME string looks too long and out of place here.
I'll replace MODULE_FNAME with KBUILD_MODNAME. Is this what you mean?
+/**
/** introduces kernel-doc, but there is no following kernel-doc,
so just use /*, please.
OK, I'll replace.
+static struct led_classdev clevo_mail_led = {
+.name = clevo::mail,
What's the purpose of the ::?
Here I have the problem that the different laptop models have
different colors of mail LED. So I left out the color and
introduced the type of the LED which is mail. I'll try to
document this in Documents/leds-class.txt
+static struct platform_driver clevo_mail_led_driver = {
+.probe = clevo_mail_led_probe,
+.remove = clevo_mail_led_remove,
+#ifdef CONFIG_PM
+.suspend= clevo_mail_led_suspend,
+.resume = clevo_mail_led_resume,
+#endif
+.driver = {
+.name = DRVNAME,
+},
+};
We prefer to have clevo_mail_led_susped() and _resume() defined
all the time, so that the above ifdef endif can go away, so
do more like:
#ifdef CONFIG_PM
/* those functions as you have them */
#else
#define clevo_mail_led_suspendNULL
#define clevo_mail_led_resume NULL
#endif
I'll change this to what you proposed.
+if (!count) {
+return -ENODEV;
+}
Don't use braces on one-statement/one-line blocks.
I'll remove the braces for the on-line expression.
+pdev = platform_device_register_simple(DRVNAME, -1, NO_RESOURCES, 0);
+if (!IS_ERR(pdev)) {
+error = platform_driver_probe(clevo_mail_led_driver,
+ clevo_mail_led_probe);
+if (error) {
+printk(KERN_ERR MODULE_FNAME
Use the module logical name, not source file name.
I'll use KBUILD_MODNAME instead.
---
~Randy
Márton Németh
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/3] leds-clevo-mail: hw accelerated LED blink extension
From: Márton Németh [EMAIL PROTECTED]
Extends the leds subsystem with a blink_set() callback function which can
be optionally implemented by a LED driver. If implemented, the driver can use
the hardware acceleration for blinking a LED.
Signed-off-by: Márton Németh [EMAIL PROTECTED]
---
diff -uprN linux-2.6.23.orig/Documentation/leds-class.txt
linux-2.6.23/Documentation/leds-class.txt
--- linux-2.6.23.orig/Documentation/leds-class.txt 2007-10-09
22:31:38.0 +0200
+++ linux-2.6.23/Documentation/leds-class.txt 2007-10-21 10:45:35.0
+0200
@@ -47,6 +49,19 @@ overhead, I suggest these become part of
above leaves scope for further attributes should they be needed.
+
+Hardware accelerated blink of LEDs
+==
+
+Some LEDs can be programmed to blink without any CPU interaction. To
+support this feature, a LED driver can optionally implement the
+blink_set() function (see linux/leds.h). If implemeted, the
+ledtrig-timer tries to use it. The blink_set() function should return
+0 if the blink setting is supported, or -EINVAL otherwise, which means
+that the LED will be turned on and off from software by the leds
+subsystem.
+
+
Known Issues
@@ -55,10 +70,6 @@ would cause nightmare dependency issues.
compared to the benefits the simple trigger functionality brings. The
rest of the LED subsystem can be modular.
-Some leds can be programmed to flash in hardware. As this isn't a generic
-LED device property, this should be exported as a device specific sysfs
-attribute rather than part of the class if this functionality is required.
-
Future Development
==
diff -uprN linux-2.6.23.orig/drivers/leds/Kconfig
linux-2.6.23/drivers/leds/Kconfig
--- linux-2.6.23.orig/drivers/leds/Kconfig 2007-10-09 22:31:38.0
+0200
+++ linux-2.6.23/drivers/leds/Kconfig 2007-10-21 12:04:50.0 +0200
@@ -115,7 +148,11 @@ config LEDS_TRIGGER_TIMER
depends on LEDS_TRIGGERS
help
This allows LEDs to be controlled by a programmable timer
- via sysfs. If unsure, say Y.
+ via sysfs. Some LED hardware can be programmed to start
+ blinking the LED without any further software interaction.
+ For more details read Documentation/leds-class.txt.
+
+ If unsure, say Y.
config LEDS_TRIGGER_IDE_DISK
bool LED IDE Disk Trigger
diff -uprN linux-2.6.23.orig/drivers/leds/ledtrig-timer.c
linux-2.6.23/drivers/leds/ledtrig-timer.c
--- linux-2.6.23.orig/drivers/leds/ledtrig-timer.c 2007-10-09
22:31:38.0 +0200
+++ linux-2.6.23/drivers/leds/ledtrig-timer.c 2007-10-18 18:21:34.0
+0200
@@ -77,8 +77,21 @@ static ssize_t led_delay_on_store(struct
count++;
if (count == size) {
- timer_data-delay_on = state;
- mod_timer(timer_data-timer, jiffies + 1);
+ if (timer_data-delay_on != state) {
+ /* the new value differs from the previous */
+ timer_data-delay_on = state;
+
+ /* deactivate previous settings */
+ del_timer_sync(timer_data-timer);
+
+ /* try to activate hardware acceleration, if any */
+ if (!led_cdev-blink_set ||
+ led_cdev-blink_set(led_cdev,
+ timer_data-delay_on, timer_data-delay_off)) {
+ /* no hardware acceleration, blink via timer */
+ mod_timer(timer_data-timer, jiffies + 1);
+ }
+ }
ret = count;
}
@@ -110,8 +123,21 @@ static ssize_t led_delay_off_store(struc
count++;
if (count == size) {
- timer_data-delay_off = state;
- mod_timer(timer_data-timer, jiffies + 1);
+ if (timer_data-delay_off != state) {
+ /* the new value differs from the previous */
+ timer_data-delay_off = state;
+
+ /* deactivate previous settings */
+ del_timer_sync(timer_data-timer);
+
+ /* try to activate hardware acceleration, if any */
+ if (!led_cdev-blink_set ||
+ led_cdev-blink_set(led_cdev,
+ timer_data-delay_on, timer_data-delay_off)) {
+ /* no hardware acceleration, blink via timer */
+ mod_timer(timer_data-timer, jiffies + 1);
+ }
+ }
ret = count;
}
diff -uprN linux-2.6.23.orig/include/linux/leds.h
linux-2.6.23/include/linux/leds.h
--- linux-2.6.23.orig/include/linux/leds.h 2007-10-09 22:31:38.0
+0200
+++ linux-2.6.23/include/linux/leds.h 2007-10-18 18:21:34.0 +0200
@@ -37,6 +37,10 @@ struct led_classdev
Re: [PATCH 3/3] leds-clevo-mail: driver for Clevo mail LED
From: Márton Németh [EMAIL PROTECTED]
The driver supports the mail LED commonly found on different Clevo notebooks.
The driver access the LED through the i8042 hardware and implements the support
for
hardware accelerated blink function.
Signed-off-by: Márton Németh [EMAIL PROTECTED]
---
diff -uprN linux-2.6.23.orig/Documentation/leds-class.txt
linux-2.6.23/Documentation/leds-class.txt
--- linux-2.6.23.orig/Documentation/leds-class.txt 2007-10-09
22:31:38.0 +0200
+++ linux-2.6.23/Documentation/leds-class.txt 2007-10-21 10:45:35.0
+0200
@@ -39,7 +39,9 @@ LED Device Naming
Is currently of the form:
-devicename:colour
+devicename:colour or
+devicename:colour:type or
+devicename::type
There have been calls for LED properties such as colour to be exported as
individual led class attributes. As a solution which doesn't incur as much
diff -uprN linux-2.6.23.orig/drivers/leds/Kconfig
linux-2.6.23/drivers/leds/Kconfig
--- linux-2.6.23.orig/drivers/leds/Kconfig 2007-10-09 22:31:38.0
+0200
+++ linux-2.6.23/drivers/leds/Kconfig 2007-10-21 12:04:50.0 +0200
@@ -101,6 +101,39 @@ config LEDS_GPIO
outputs. To be useful the particular board must have LEDs
and they must be connected to the GPIO lines.
+config LEDS_CLEVO_MAIL
+ tristate Mail LED on Clevo notebook (EXPERIMENTAL)
+ depends on LEDS_CLASS X86 SERIO_I8042 DMI EXPERIMENTAL
+ help
+ This driver makes the mail LED accessible from userspace
+ programs through the leds subsystem. This LED have three
+ known mode: off, blink at 0.5Hz and blink at 1Hz.
+
+ The driver supports two kinds of interface: using ledtrig-timer
+ or through /sys/class/leds/clevo::mail/brightness. As this LED
+ cannot change it's brightness it blinks instead. The brightness
+ value 0 means off, 1..127 means blink at 0.5Hz and 128..255 means
+ blink at 1Hz.
+
+ Example to start blink at 0.5Hz:
+ echo 1 /sys/class/leds/clevo::mail/brightness
+ - or -
+ echo timer /sys/class/leds/clevo::mail/trigger
+ echo 1000 /sys/class/leds/clevo::mail/delay_on
+ echo 1000 /sys/class/leds/clevo::mail/delay_off
+
+ This module can drive the mail LED for the following notebooks:
+
+ Clevo D410J
+ Clevo D410V
+ Clevo D400V/D470V (not tested, but might work)
+ Clevo M540N
+ Clevo M5x0N (not tested, but might work)
+ Positivo Mobile (Clevo M5x0V)
+
+ To compile this driver as a module, choose M here: the
+ module will be called leds-clevo-mail.
+
comment LED Triggers
config LEDS_TRIGGERS
diff -uprN linux-2.6.23.orig/drivers/leds/leds-clevo-mail.c
linux-2.6.23/drivers/leds/leds-clevo-mail.c
--- linux-2.6.23.orig/drivers/leds/leds-clevo-mail.c1970-01-01
01:00:00.0 +0100
+++ linux-2.6.23/drivers/leds/leds-clevo-mail.c 2007-10-21 10:49:32.0
+0200
@@ -0,0 +1,210 @@
+
+#include linux/module.h
+
+#include linux/platform_device.h
+#include linux/err.h
+#include linux/leds.h
+
+#include linux/io.h
+#include linux/dmi.h
+
+#include linux/i8042.h
+
+#define HANDLED0
+
+#define CLEVO_MAIL_LED_OFF 0x0084
+#define CLEVO_MAIL_LED_BLINK_1HZ 0x008A
+#define CLEVO_MAIL_LED_BLINK_0_5HZ 0x0083
+
+MODULE_AUTHOR(Márton Németh [EMAIL PROTECTED]);
+MODULE_DESCRIPTION(Clevo mail LED driver);
+MODULE_LICENSE(GPL);
+
+static unsigned int __initdata nodetect;
+module_param_named(nodetect, nodetect, bool, 0);
+MODULE_PARM_DESC(nodetect, Skip DMI hardware detection);
+
+static struct platform_device *pdev;
+
+static int __init clevo_mail_led_dmi_callback(struct dmi_system_id *id)
+{
+ printk(KERN_INFO KBUILD_MODNAME : '%s' found\n, id-ident);
+ return 1;
+}
+
+/*
+ * struct mail_led_whitelist - List of known good models
+ *
+ * Contains the known good models this driver is compatible with.
+ * When adding a new model try to be as strict as possible. This
+ * makes it possible to keep the false positives (the model is
+ * detected as working, but in reality it is not) as low as
+ * possible.
+ */
+static struct dmi_system_id __initdata mail_led_whitelist[] = {
+ {
+ .callback = clevo_mail_led_dmi_callback,
+ .ident = Clevo D410J,
+ .matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, VIA),
+ DMI_MATCH(DMI_PRODUCT_NAME, K8N800),
+ DMI_MATCH(DMI_PRODUCT_VERSION, VT8204B)
+ }
+ },
+ {
+ .callback = clevo_mail_led_dmi_callback,
+ .ident = Clevo M5x0N,
+ .matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, CLEVO Co.),
+ DMI_MATCH(DMI_PRODUCT_NAME, M5x0N)
+ }
+ },
+ {
+ .callback =
[PATCH 3/3] leds-clevo-mail: driver for Clevo mail LED
From: Márton Németh <[EMAIL PROTECTED]>
The driver supports the mail LED commonly found on different Clevo notebooks.
The driver access the LED through the i8042 hardware and implements the support
for
hardware accelerated blink function.
Signed-off-by: Márton Németh <[EMAIL PROTECTED]>
---
diff -uprN linux-2.6.23.orig/drivers/leds/Kconfig
linux-2.6.23/drivers/leds/Kconfig
--- linux-2.6.23.orig/drivers/leds/Kconfig 2007-10-09 22:31:38.0
+0200
+++ linux-2.6.23/drivers/leds/Kconfig 2007-10-18 07:20:12.0 +0200
@@ -101,6 +101,26 @@ config LEDS_GPIO
outputs. To be useful the particular board must have LEDs
and they must be connected to the GPIO lines.
+config LEDS_CLEVO_MAIL
+ tristate "Mail LED on Clevo notebook (EXPERIMENTAL)"
+ depends on LEDS_CLASS && X86 && SERIO_I8042 && DMI && EXPERIMENTAL
+ help
+ This driver makes the mail LED accessible from userspace
+ programs through the leds subsystem. This LED can blink at
+ about 0.5Hz and 1Hz.
+
+ This module can drive the mail LED for the following notebooks:
+
+ Clevo D410J
+ Clevo D410V
+ Clevo D400V/D470V (not tested, but might work)
+ Clevo M540N
+ Clevo M5x0N (not tested, but might work)
+ Positivo Mobile (Clevo M5x0V)
+
+ To compile this driver as a module, choose M here: the
+ module will be called leds-clevo-mail.
+
comment "LED Triggers"
config LEDS_TRIGGERS
diff -uprN linux-2.6.23.orig/drivers/leds/leds-clevo-mail.c
linux-2.6.23/drivers/leds/leds-clevo-mail.c
--- linux-2.6.23.orig/drivers/leds/leds-clevo-mail.c1970-01-01
01:00:00.0 +0100
+++ linux-2.6.23/drivers/leds/leds-clevo-mail.c 2007-10-18 07:17:56.0
+0200
@@ -0,0 +1,226 @@
+
+#include
+
+#include
+#include
+#include
+
+#include
+#include
+
+#include
+
+
+#define TRUE 1
+#define FALSE 0
+
+#define HANDLED0
+
+#define CLEVO_MAIL_LED_OFF 0x0084
+#define CLEVO_MAIL_LED_BLINK_1HZ 0x008A
+#define CLEVO_MAIL_LED_BLINK_0_5HZ 0x0083
+
+#define MODULE_FNAME "leds-clevo-mail.c"
+#define DRVNAME"clevo-mail-led"
+#define NO_RESOURCES NULL
+
+MODULE_AUTHOR("Márton Németh <[EMAIL PROTECTED]>");
+MODULE_DESCRIPTION("Clevo mail LED driver");
+MODULE_LICENSE("GPL");
+
+static unsigned int __initdata nodetect;
+module_param_named(nodetect, nodetect, bool, 0);
+MODULE_PARM_DESC(nodetect, "Skip DMI hardware detection");
+
+
+static struct platform_device *pdev;
+
+
+static int __init clevo_mail_led_dmi_callback(struct dmi_system_id *id)
+{
+ printk(KERN_INFO MODULE_FNAME ": '%s' found\n", id->ident);
+ return 1;
+}
+
+/**
+ * struct mail_led_whitelist - List of known good models
+ *
+ * Contains the known good models this driver is compatible with.
+ * When adding a new model try to be as strict as possible. This
+ * makes it possible to keep the false positives (the model is
+ * detected as working, but in reality it is not) as low as
+ * possible.
+ */
+static struct dmi_system_id __initdata mail_led_whitelist[] = {
+ {
+ .callback = clevo_mail_led_dmi_callback,
+ .ident = "Clevo D410J",
+ .matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, "VIA"),
+ DMI_MATCH(DMI_PRODUCT_NAME, "K8N800"),
+ DMI_MATCH(DMI_PRODUCT_VERSION, "VT8204B")
+ }
+ },
+ {
+ .callback = clevo_mail_led_dmi_callback,
+ .ident = "Clevo M5x0N",
+ .matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, "CLEVO Co."),
+ DMI_MATCH(DMI_PRODUCT_NAME, "M5x0N")
+ }
+ },
+ {
+ .callback = clevo_mail_led_dmi_callback,
+ .ident = "Positivo Mobile",
+ .matches = {
+ DMI_MATCH(DMI_BOARD_VENDOR, "CLEVO Co. "),
+ DMI_MATCH(DMI_BOARD_NAME, "M5X0V "),
+ DMI_MATCH(DMI_PRODUCT_NAME, "Positivo Mobile"),
+ DMI_MATCH(DMI_PRODUCT_VERSION, "VT6198")
+ }
+ },
+ {
+ .callback = clevo_mail_led_dmi_callback,
+ .ident = "Clevo D410V",
+ .matches = {
+ DMI_MATCH(DMI_BOARD_VENDOR, "Clevo, Co."),
+ DMI_MATCH(DMI_BOARD_NAME, "D400V/D470V"),
+ DMI_MATCH(DMI_BOARD_VERSION, "SS78B"),
+ DMI_MATCH(DMI_PRODUCT_VERSION, "Rev. A1")
+ }
+ },
+ { }
+};
+
+
+static void clevo_mail_led_set(struct led_classdev *led_cdev,
+ enum led_brightness value)
+{
+ if (value == LED_OFF)
+ i8042_command(NULL, CLEVO_MAIL_LED_OFF);
+
[PATCH 2/3] leds-clevo-mail: hw accelerated LED blink extension
From: Márton Németh <[EMAIL PROTECTED]>
Extends the leds subsystem with a blink_set() callback function which can
be optionally implemented by a LED driver. If implemented, the driver can use
the hardware acceleration for blinking a LED.
Signed-off-by: Márton Németh <[EMAIL PROTECTED]>
---
diff -uprN linux-2.6.23.orig/Documentation/leds-class.txt
linux-2.6.23/Documentation/leds-class.txt
--- linux-2.6.23.orig/Documentation/leds-class.txt 2007-10-09
22:31:38.0 +0200
+++ linux-2.6.23/Documentation/leds-class.txt 2007-10-18 06:57:37.0
+0200
@@ -47,6 +47,18 @@ overhead, I suggest these become part of
above leaves scope for further attributes should they be needed.
+Hardware accelerated blink of LEDs
+==
+
+Some LEDs can be programmed to blink without any CPU interaction. To
+support this feature, a LED driver can optionally implement the
+blink_set() function (see ). If implemeted, the
+ledtrig-timer tries to use it. The blink_set() function should return
+0 if the blink setting is supported, or -EINVAL otherwise, which means
+that the LED will be turned on and off from software by the leds
+subsystem.
+
+
Known Issues
@@ -55,10 +67,6 @@ would cause nightmare dependency issues.
compared to the benefits the simple trigger functionality brings. The
rest of the LED subsystem can be modular.
-Some leds can be programmed to flash in hardware. As this isn't a generic
-LED device property, this should be exported as a device specific sysfs
-attribute rather than part of the class if this functionality is required.
-
Future Development
==
diff -uprN linux-2.6.23.orig/drivers/leds/ledtrig-timer.c
linux-2.6.23/drivers/leds/ledtrig-timer.c
--- linux-2.6.23.orig/drivers/leds/ledtrig-timer.c 2007-10-09
22:31:38.0 +0200
+++ linux-2.6.23/drivers/leds/ledtrig-timer.c 2007-10-18 07:15:14.0
+0200
@@ -77,8 +77,21 @@ static ssize_t led_delay_on_store(struct
count++;
if (count == size) {
- timer_data->delay_on = state;
- mod_timer(_data->timer, jiffies + 1);
+ if (timer_data->delay_on != state) {
+ /* the new value differs from the previous */
+ timer_data->delay_on = state;
+
+ /* deactivate previous settings */
+ del_timer_sync(_data->timer);
+
+ /* try to activate hardware acceleration, if any */
+ if (!led_cdev->blink_set ||
+ led_cdev->blink_set(led_cdev,
+ timer_data->delay_on, timer_data->delay_off)) {
+ /* no hardware acceleration, blink via timer */
+ mod_timer(_data->timer, jiffies + 1);
+ }
+ }
ret = count;
}
@@ -110,8 +123,21 @@ static ssize_t led_delay_off_store(struc
count++;
if (count == size) {
- timer_data->delay_off = state;
- mod_timer(_data->timer, jiffies + 1);
+ if (timer_data->delay_off != state) {
+ /* the new value differs from the previous */
+ timer_data->delay_off = state;
+
+ /* deactivate previous settings */
+ del_timer_sync(_data->timer);
+
+ /* try to activate hardware acceleration, if any */
+ if (!led_cdev->blink_set ||
+ led_cdev->blink_set(led_cdev,
+ timer_data->delay_on, timer_data->delay_off)) {
+ /* no hardware acceleration, blink via timer */
+ mod_timer(_data->timer, jiffies + 1);
+ }
+ }
ret = count;
}
diff -uprN linux-2.6.23.orig/include/linux/leds.h
linux-2.6.23/include/linux/leds.h
--- linux-2.6.23.orig/include/linux/leds.h 2007-10-09 22:31:38.0
+0200
+++ linux-2.6.23/include/linux/leds.h 2007-10-18 07:17:30.0 +0200
@@ -37,6 +37,10 @@ struct led_classdev {
void(*brightness_set)(struct led_classdev *led_cdev,
enum led_brightness brightness);
+ /* Activate hardware accelerated blink */
+ int (*blink_set)(struct led_classdev *led_cdev,
+int delay_on, int delay_off);
+
struct device *dev;
struct list_head node; /* LED Device list */
char*default_trigger; /* Trigger to use */
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at
[PATCH 1/3] leds-clevo-mail: export i8042_command()
From: Márton Németh <[EMAIL PROTECTED]>
Export the i8042_command() function which manages the mutual exclusion
with the help of the i8042_lock spinlock. This lets possible to use the
i8042 hardware safely from other part of the kernel, too.
Signed-off-by: Márton Németh <[EMAIL PROTECTED]>
---
diff -uprN linux-2.6.23.orig/drivers/input/serio/i8042.c
linux-2.6.23/drivers/input/serio/i8042.c
--- linux-2.6.23.orig/drivers/input/serio/i8042.c 2007-10-09
22:31:38.0 +0200
+++ linux-2.6.23/drivers/input/serio/i8042.c2007-10-18 06:52:12.0
+0200
@@ -20,6 +20,7 @@
#include
#include
#include
+#include
#include
@@ -208,7 +209,7 @@ static int __i8042_command(unsigned char
return 0;
}
-static int i8042_command(unsigned char *param, int command)
+int i8042_command(unsigned char *param, int command)
{
unsigned long flags;
int retval;
@@ -219,6 +220,7 @@ static int i8042_command(unsigned char *
return retval;
}
+EXPORT_SYMBOL(i8042_command);
/*
* i8042_kbd_write() sends a byte out through the keyboard interface.
diff -uprN linux-2.6.23.orig/include/linux/i8042.h
linux-2.6.23/include/linux/i8042.h
--- linux-2.6.23.orig/include/linux/i8042.h 1970-01-01 01:00:00.0
+0100
+++ linux-2.6.23/include/linux/i8042.h 2007-10-18 06:53:29.0 +0200
@@ -0,0 +1,9 @@
+/* There is already a header file linux/drivers/input/serio/i8042.h, so
+ * using the _LINUX prefix here as this is the file.
+ */
+#ifndef _LINUX_I8042_H
+#define _LINUX_I8402_H
+
+int i8042_command(unsigned char *param, int command);
+
+#endif
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3/3] leds-clevo-mail: driver for Clevo mail LED
From: Márton Németh [EMAIL PROTECTED]
The driver supports the mail LED commonly found on different Clevo notebooks.
The driver access the LED through the i8042 hardware and implements the support
for
hardware accelerated blink function.
Signed-off-by: Márton Németh [EMAIL PROTECTED]
---
diff -uprN linux-2.6.23.orig/drivers/leds/Kconfig
linux-2.6.23/drivers/leds/Kconfig
--- linux-2.6.23.orig/drivers/leds/Kconfig 2007-10-09 22:31:38.0
+0200
+++ linux-2.6.23/drivers/leds/Kconfig 2007-10-18 07:20:12.0 +0200
@@ -101,6 +101,26 @@ config LEDS_GPIO
outputs. To be useful the particular board must have LEDs
and they must be connected to the GPIO lines.
+config LEDS_CLEVO_MAIL
+ tristate Mail LED on Clevo notebook (EXPERIMENTAL)
+ depends on LEDS_CLASS X86 SERIO_I8042 DMI EXPERIMENTAL
+ help
+ This driver makes the mail LED accessible from userspace
+ programs through the leds subsystem. This LED can blink at
+ about 0.5Hz and 1Hz.
+
+ This module can drive the mail LED for the following notebooks:
+
+ Clevo D410J
+ Clevo D410V
+ Clevo D400V/D470V (not tested, but might work)
+ Clevo M540N
+ Clevo M5x0N (not tested, but might work)
+ Positivo Mobile (Clevo M5x0V)
+
+ To compile this driver as a module, choose M here: the
+ module will be called leds-clevo-mail.
+
comment LED Triggers
config LEDS_TRIGGERS
diff -uprN linux-2.6.23.orig/drivers/leds/leds-clevo-mail.c
linux-2.6.23/drivers/leds/leds-clevo-mail.c
--- linux-2.6.23.orig/drivers/leds/leds-clevo-mail.c1970-01-01
01:00:00.0 +0100
+++ linux-2.6.23/drivers/leds/leds-clevo-mail.c 2007-10-18 07:17:56.0
+0200
@@ -0,0 +1,226 @@
+
+#include linux/module.h
+
+#include linux/platform_device.h
+#include linux/err.h
+#include linux/leds.h
+
+#include linux/io.h
+#include linux/dmi.h
+
+#include linux/i8042.h
+
+
+#define TRUE 1
+#define FALSE 0
+
+#define HANDLED0
+
+#define CLEVO_MAIL_LED_OFF 0x0084
+#define CLEVO_MAIL_LED_BLINK_1HZ 0x008A
+#define CLEVO_MAIL_LED_BLINK_0_5HZ 0x0083
+
+#define MODULE_FNAME leds-clevo-mail.c
+#define DRVNAMEclevo-mail-led
+#define NO_RESOURCES NULL
+
+MODULE_AUTHOR(Márton Németh [EMAIL PROTECTED]);
+MODULE_DESCRIPTION(Clevo mail LED driver);
+MODULE_LICENSE(GPL);
+
+static unsigned int __initdata nodetect;
+module_param_named(nodetect, nodetect, bool, 0);
+MODULE_PARM_DESC(nodetect, Skip DMI hardware detection);
+
+
+static struct platform_device *pdev;
+
+
+static int __init clevo_mail_led_dmi_callback(struct dmi_system_id *id)
+{
+ printk(KERN_INFO MODULE_FNAME : '%s' found\n, id-ident);
+ return 1;
+}
+
+/**
+ * struct mail_led_whitelist - List of known good models
+ *
+ * Contains the known good models this driver is compatible with.
+ * When adding a new model try to be as strict as possible. This
+ * makes it possible to keep the false positives (the model is
+ * detected as working, but in reality it is not) as low as
+ * possible.
+ */
+static struct dmi_system_id __initdata mail_led_whitelist[] = {
+ {
+ .callback = clevo_mail_led_dmi_callback,
+ .ident = Clevo D410J,
+ .matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, VIA),
+ DMI_MATCH(DMI_PRODUCT_NAME, K8N800),
+ DMI_MATCH(DMI_PRODUCT_VERSION, VT8204B)
+ }
+ },
+ {
+ .callback = clevo_mail_led_dmi_callback,
+ .ident = Clevo M5x0N,
+ .matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, CLEVO Co.),
+ DMI_MATCH(DMI_PRODUCT_NAME, M5x0N)
+ }
+ },
+ {
+ .callback = clevo_mail_led_dmi_callback,
+ .ident = Positivo Mobile,
+ .matches = {
+ DMI_MATCH(DMI_BOARD_VENDOR, CLEVO Co. ),
+ DMI_MATCH(DMI_BOARD_NAME, M5X0V ),
+ DMI_MATCH(DMI_PRODUCT_NAME, Positivo Mobile),
+ DMI_MATCH(DMI_PRODUCT_VERSION, VT6198)
+ }
+ },
+ {
+ .callback = clevo_mail_led_dmi_callback,
+ .ident = Clevo D410V,
+ .matches = {
+ DMI_MATCH(DMI_BOARD_VENDOR, Clevo, Co.),
+ DMI_MATCH(DMI_BOARD_NAME, D400V/D470V),
+ DMI_MATCH(DMI_BOARD_VERSION, SS78B),
+ DMI_MATCH(DMI_PRODUCT_VERSION, Rev. A1)
+ }
+ },
+ { }
+};
+
+
+static void clevo_mail_led_set(struct led_classdev *led_cdev,
+ enum led_brightness value)
+{
+ if (value == LED_OFF)
+ i8042_command(NULL,
[PATCH 2/3] leds-clevo-mail: hw accelerated LED blink extension
From: Márton Németh [EMAIL PROTECTED]
Extends the leds subsystem with a blink_set() callback function which can
be optionally implemented by a LED driver. If implemented, the driver can use
the hardware acceleration for blinking a LED.
Signed-off-by: Márton Németh [EMAIL PROTECTED]
---
diff -uprN linux-2.6.23.orig/Documentation/leds-class.txt
linux-2.6.23/Documentation/leds-class.txt
--- linux-2.6.23.orig/Documentation/leds-class.txt 2007-10-09
22:31:38.0 +0200
+++ linux-2.6.23/Documentation/leds-class.txt 2007-10-18 06:57:37.0
+0200
@@ -47,6 +47,18 @@ overhead, I suggest these become part of
above leaves scope for further attributes should they be needed.
+Hardware accelerated blink of LEDs
+==
+
+Some LEDs can be programmed to blink without any CPU interaction. To
+support this feature, a LED driver can optionally implement the
+blink_set() function (see linux/leds.h). If implemeted, the
+ledtrig-timer tries to use it. The blink_set() function should return
+0 if the blink setting is supported, or -EINVAL otherwise, which means
+that the LED will be turned on and off from software by the leds
+subsystem.
+
+
Known Issues
@@ -55,10 +67,6 @@ would cause nightmare dependency issues.
compared to the benefits the simple trigger functionality brings. The
rest of the LED subsystem can be modular.
-Some leds can be programmed to flash in hardware. As this isn't a generic
-LED device property, this should be exported as a device specific sysfs
-attribute rather than part of the class if this functionality is required.
-
Future Development
==
diff -uprN linux-2.6.23.orig/drivers/leds/ledtrig-timer.c
linux-2.6.23/drivers/leds/ledtrig-timer.c
--- linux-2.6.23.orig/drivers/leds/ledtrig-timer.c 2007-10-09
22:31:38.0 +0200
+++ linux-2.6.23/drivers/leds/ledtrig-timer.c 2007-10-18 07:15:14.0
+0200
@@ -77,8 +77,21 @@ static ssize_t led_delay_on_store(struct
count++;
if (count == size) {
- timer_data-delay_on = state;
- mod_timer(timer_data-timer, jiffies + 1);
+ if (timer_data-delay_on != state) {
+ /* the new value differs from the previous */
+ timer_data-delay_on = state;
+
+ /* deactivate previous settings */
+ del_timer_sync(timer_data-timer);
+
+ /* try to activate hardware acceleration, if any */
+ if (!led_cdev-blink_set ||
+ led_cdev-blink_set(led_cdev,
+ timer_data-delay_on, timer_data-delay_off)) {
+ /* no hardware acceleration, blink via timer */
+ mod_timer(timer_data-timer, jiffies + 1);
+ }
+ }
ret = count;
}
@@ -110,8 +123,21 @@ static ssize_t led_delay_off_store(struc
count++;
if (count == size) {
- timer_data-delay_off = state;
- mod_timer(timer_data-timer, jiffies + 1);
+ if (timer_data-delay_off != state) {
+ /* the new value differs from the previous */
+ timer_data-delay_off = state;
+
+ /* deactivate previous settings */
+ del_timer_sync(timer_data-timer);
+
+ /* try to activate hardware acceleration, if any */
+ if (!led_cdev-blink_set ||
+ led_cdev-blink_set(led_cdev,
+ timer_data-delay_on, timer_data-delay_off)) {
+ /* no hardware acceleration, blink via timer */
+ mod_timer(timer_data-timer, jiffies + 1);
+ }
+ }
ret = count;
}
diff -uprN linux-2.6.23.orig/include/linux/leds.h
linux-2.6.23/include/linux/leds.h
--- linux-2.6.23.orig/include/linux/leds.h 2007-10-09 22:31:38.0
+0200
+++ linux-2.6.23/include/linux/leds.h 2007-10-18 07:17:30.0 +0200
@@ -37,6 +37,10 @@ struct led_classdev {
void(*brightness_set)(struct led_classdev *led_cdev,
enum led_brightness brightness);
+ /* Activate hardware accelerated blink */
+ int (*blink_set)(struct led_classdev *led_cdev,
+int delay_on, int delay_off);
+
struct device *dev;
struct list_head node; /* LED Device list */
char*default_trigger; /* Trigger to use */
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at
[PATCH 1/3] leds-clevo-mail: export i8042_command()
From: Márton Németh [EMAIL PROTECTED]
Export the i8042_command() function which manages the mutual exclusion
with the help of the i8042_lock spinlock. This lets possible to use the
i8042 hardware safely from other part of the kernel, too.
Signed-off-by: Márton Németh [EMAIL PROTECTED]
---
diff -uprN linux-2.6.23.orig/drivers/input/serio/i8042.c
linux-2.6.23/drivers/input/serio/i8042.c
--- linux-2.6.23.orig/drivers/input/serio/i8042.c 2007-10-09
22:31:38.0 +0200
+++ linux-2.6.23/drivers/input/serio/i8042.c2007-10-18 06:52:12.0
+0200
@@ -20,6 +20,7 @@
#include linux/err.h
#include linux/rcupdate.h
#include linux/platform_device.h
+#include linux/i8042.h
#include asm/io.h
@@ -208,7 +209,7 @@ static int __i8042_command(unsigned char
return 0;
}
-static int i8042_command(unsigned char *param, int command)
+int i8042_command(unsigned char *param, int command)
{
unsigned long flags;
int retval;
@@ -219,6 +220,7 @@ static int i8042_command(unsigned char *
return retval;
}
+EXPORT_SYMBOL(i8042_command);
/*
* i8042_kbd_write() sends a byte out through the keyboard interface.
diff -uprN linux-2.6.23.orig/include/linux/i8042.h
linux-2.6.23/include/linux/i8042.h
--- linux-2.6.23.orig/include/linux/i8042.h 1970-01-01 01:00:00.0
+0100
+++ linux-2.6.23/include/linux/i8042.h 2007-10-18 06:53:29.0 +0200
@@ -0,0 +1,9 @@
+/* There is already a header file linux/drivers/input/serio/i8042.h, so
+ * using the _LINUX prefix here as this is the linux/i8042.h file.
+ */
+#ifndef _LINUX_I8042_H
+#define _LINUX_I8402_H
+
+int i8042_command(unsigned char *param, int command);
+
+#endif
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH]: drm: cleanup DRM_DEBUG() parameters
From: Márton Németh <[EMAIL PROTECTED]>
As DRM_DEBUG macro already prints out the __FUNCTION__ string (see
drivers/char/drm/drmP.h), it is not worth doing this again. At some
other places the ending "\n" was added.
Signed-off-by: Márton Németh <[EMAIL PROTECTED]>
---
diff -uprN linux-2.6.23-mm1.orig/drivers/char/drm/ati_pcigart.c
linux-2.6.23-mm1/drivers/char/drm/ati_pcigart.c
--- linux-2.6.23-mm1.orig/drivers/char/drm/ati_pcigart.c2007-10-09
22:31:38.0 +0200
+++ linux-2.6.23-mm1/drivers/char/drm/ati_pcigart.c 2007-10-17
22:22:19.0 +0200
@@ -41,7 +41,7 @@ static void *drm_ati_alloc_pcigart_table
struct page *page;
int i;
- DRM_DEBUG("%s: alloc %d order\n", __FUNCTION__, order);
+ DRM_DEBUG("%d order\n", order);
address = __get_free_pages(GFP_KERNEL | __GFP_COMP,
order);
@@ -54,7 +54,7 @@ static void *drm_ati_alloc_pcigart_table
for (i = 0; i < order; i++, page++)
SetPageReserved(page);
- DRM_DEBUG("%s: returning 0x%08lx\n", __FUNCTION__, address);
+ DRM_DEBUG("returning 0x%08lx\n", address);
return (void *)address;
}
@@ -63,7 +63,7 @@ static void drm_ati_free_pcigart_table(v
struct page *page;
int i;
int num_pages = 1 << order;
- DRM_DEBUG("%s\n", __FUNCTION__);
+ DRM_DEBUG("\n");
page = virt_to_page((unsigned long)address);
diff -uprN linux-2.6.23-mm1.orig/drivers/char/drm/drm_irq.c
linux-2.6.23-mm1/drivers/char/drm/drm_irq.c
--- linux-2.6.23-mm1.orig/drivers/char/drm/drm_irq.c2007-10-17
22:19:21.0 +0200
+++ linux-2.6.23-mm1/drivers/char/drm/drm_irq.c 2007-10-17 22:22:19.0
+0200
@@ -107,7 +107,7 @@ static int drm_irq_install(struct drm_de
dev->irq_enabled = 1;
mutex_unlock(>struct_mutex);
- DRM_DEBUG("%s: irq=%d\n", __FUNCTION__, dev->irq);
+ DRM_DEBUG("irq=%d\n", dev->irq);
if (drm_core_check_feature(dev, DRIVER_IRQ_VBL)) {
init_waitqueue_head(>vbl_queue);
@@ -164,7 +164,7 @@ int drm_irq_uninstall(struct drm_device
if (!irq_enabled)
return -EINVAL;
- DRM_DEBUG("%s: irq=%d\n", __FUNCTION__, dev->irq);
+ DRM_DEBUG("irq=%d\n", dev->irq);
dev->driver->irq_uninstall(dev);
diff -uprN linux-2.6.23-mm1.orig/drivers/char/drm/drm_scatter.c
linux-2.6.23-mm1/drivers/char/drm/drm_scatter.c
--- linux-2.6.23-mm1.orig/drivers/char/drm/drm_scatter.c2007-10-17
22:19:21.0 +0200
+++ linux-2.6.23-mm1/drivers/char/drm/drm_scatter.c 2007-10-17
22:31:42.0 +0200
@@ -67,7 +67,7 @@ int drm_sg_alloc(struct drm_device *dev,
struct drm_sg_mem *entry;
unsigned long pages, i, j;
- DRM_DEBUG("%s\n", __FUNCTION__);
+ DRM_DEBUG("\n");
if (!drm_core_check_feature(dev, DRIVER_SG))
return -EINVAL;
@@ -81,7 +81,7 @@ int drm_sg_alloc(struct drm_device *dev,
memset(entry, 0, sizeof(*entry));
pages = (request->size + PAGE_SIZE - 1) / PAGE_SIZE;
- DRM_DEBUG("sg size=%ld pages=%ld\n", request->size, pages);
+ DRM_DEBUG("size=%ld pages=%ld\n", request->size, pages);
entry->pages = pages;
entry->pagelist = drm_alloc(pages * sizeof(*entry->pagelist),
@@ -122,8 +122,8 @@ int drm_sg_alloc(struct drm_device *dev,
entry->handle = ScatterHandle((unsigned long)entry->virtual);
- DRM_DEBUG("sg alloc handle = %08lx\n", entry->handle);
- DRM_DEBUG("sg alloc virtual = %p\n", entry->virtual);
+ DRM_DEBUG("handle = %08lx\n", entry->handle);
+ DRM_DEBUG("virtual = %p\n", entry->virtual);
for (i = (unsigned long)entry->virtual, j = 0; j < pages;
i += PAGE_SIZE, j++) {
@@ -210,7 +210,7 @@ int drm_sg_free(struct drm_device *dev,
if (!entry || entry->handle != request->handle)
return -EINVAL;
- DRM_DEBUG("sg free virtual = %p\n", entry->virtual);
+ DRM_DEBUG("virtual = %p\n", entry->virtual);
drm_sg_cleanup(entry);
diff -uprN linux-2.6.23-mm1.orig/drivers/char/drm/drm_vm.c
linux-2.6.23-mm1/drivers/char/drm/drm_vm.c
--- linux-2.6.23-mm1.orig/drivers/char/drm/drm_vm.c 2007-10-17
22:19:21.0 +0200
+++ linux-2.6.23-mm1/drivers/char/drm/drm_vm.c 2007-10-17 22:22:19.0
+0200
@@ -180,7 +180,7 @@ static __inline__ struct page *drm_do_vm
return NOPAGE_SIGBUS;
get_page(page);
- DRM_DEBUG("shm_nopage 0x%lx\n", address);
+ DRM_DEBUG("0x%lx\n", address);
return page;
}
@@ -294,7 +294,7 @@ static __inline__ struct page *drm_do_vm
get_page(page);
- DRM_DEBUG("dma_nopage 0x%lx (page %lu)\n", address, page_nr);
+ DRM_DEBUG("0x%lx (page %lu)\n", address, page_nr);
return page;
}
diff -uprN linux-2.6.23-mm1.orig/drivers/char/drm/i810_dma.c
linux-2.6.23-mm1/drivers/char/drm/i810_dma.c
---
Re: [PATCH]: drm: cleanup DRM_DEBUG() parameters
From: Márton Németh <[EMAIL PROTECTED]>
As DRM_DEBUG macro already prints out the __FUNCTION__ string (see
drivers/char/drm/drmP.h), it is not worth doing this again. At some
other places the ending "\n" was added.
Signed-off-by: Márton Németh <[EMAIL PROTECTED]>
---
diff -uprN linux-2.6.23-mm1.orig/drivers/char/drm/ati_pcigart.c
linux-2.6.23-mm1/drivers/char/drm/ati_pcigart.c
--- linux-2.6.23-mm1.orig/drivers/char/drm/ati_pcigart.c2007-10-09
22:31:38.0 +0200
+++ linux-2.6.23-mm1/drivers/char/drm/ati_pcigart.c 2007-10-17
22:22:19.0 +0200
@@ -41,7 +41,7 @@ static void *drm_ati_alloc_pcigart_table
struct page *page;
int i;
- DRM_DEBUG("%s: alloc %d order\n", __FUNCTION__, order);
+ DRM_DEBUG("%d order\n", order);
address = __get_free_pages(GFP_KERNEL | __GFP_COMP,
order);
@@ -54,7 +54,7 @@ static void *drm_ati_alloc_pcigart_table
for (i = 0; i < order; i++, page++)
SetPageReserved(page);
- DRM_DEBUG("%s: returning 0x%08lx\n", __FUNCTION__, address);
+ DRM_DEBUG("returning 0x%08lx\n", address);
return (void *)address;
}
@@ -63,7 +63,7 @@ static void drm_ati_free_pcigart_table(v
struct page *page;
int i;
int num_pages = 1 << order;
- DRM_DEBUG("%s\n", __FUNCTION__);
+ DRM_DEBUG("\n");
page = virt_to_page((unsigned long)address);
diff -uprN linux-2.6.23-mm1.orig/drivers/char/drm/drm_irq.c
linux-2.6.23-mm1/drivers/char/drm/drm_irq.c
--- linux-2.6.23-mm1.orig/drivers/char/drm/drm_irq.c2007-10-17
22:19:21.0 +0200
+++ linux-2.6.23-mm1/drivers/char/drm/drm_irq.c 2007-10-17 22:22:19.0
+0200
@@ -107,7 +107,7 @@ static int drm_irq_install(struct drm_de
dev->irq_enabled = 1;
mutex_unlock(>struct_mutex);
- DRM_DEBUG("%s: irq=%d\n", __FUNCTION__, dev->irq);
+ DRM_DEBUG("irq=%d\n", dev->irq);
if (drm_core_check_feature(dev, DRIVER_IRQ_VBL)) {
init_waitqueue_head(>vbl_queue);
@@ -164,7 +164,7 @@ int drm_irq_uninstall(struct drm_device
if (!irq_enabled)
return -EINVAL;
- DRM_DEBUG("%s: irq=%d\n", __FUNCTION__, dev->irq);
+ DRM_DEBUG("irq=%d\n", dev->irq);
dev->driver->irq_uninstall(dev);
diff -uprN linux-2.6.23-mm1.orig/drivers/char/drm/drm_scatter.c
linux-2.6.23-mm1/drivers/char/drm/drm_scatter.c
--- linux-2.6.23-mm1.orig/drivers/char/drm/drm_scatter.c2007-10-17
22:19:21.0 +0200
+++ linux-2.6.23-mm1/drivers/char/drm/drm_scatter.c 2007-10-17
22:31:42.0 +0200
@@ -67,7 +67,7 @@ int drm_sg_alloc(struct drm_device *dev,
struct drm_sg_mem *entry;
unsigned long pages, i, j;
- DRM_DEBUG("%s\n", __FUNCTION__);
+ DRM_DEBUG("\n");
if (!drm_core_check_feature(dev, DRIVER_SG))
return -EINVAL;
@@ -81,7 +81,7 @@ int drm_sg_alloc(struct drm_device *dev,
memset(entry, 0, sizeof(*entry));
pages = (request->size + PAGE_SIZE - 1) / PAGE_SIZE;
- DRM_DEBUG("sg size=%ld pages=%ld\n", request->size, pages);
+ DRM_DEBUG("size=%ld pages=%ld\n", request->size, pages);
entry->pages = pages;
entry->pagelist = drm_alloc(pages * sizeof(*entry->pagelist),
@@ -122,8 +122,8 @@ int drm_sg_alloc(struct drm_device *dev,
entry->handle = ScatterHandle((unsigned long)entry->virtual);
- DRM_DEBUG("sg alloc handle = %08lx\n", entry->handle);
- DRM_DEBUG("sg alloc virtual = %p\n", entry->virtual);
+ DRM_DEBUG("handle = %08lx\n", entry->handle);
+ DRM_DEBUG("virtual = %p\n", entry->virtual);
for (i = (unsigned long)entry->virtual, j = 0; j < pages;
i += PAGE_SIZE, j++) {
@@ -210,7 +210,7 @@ int drm_sg_free(struct drm_device *dev,
if (!entry || entry->handle != request->handle)
return -EINVAL;
- DRM_DEBUG("sg free virtual = %p\n", entry->virtual);
+ DRM_DEBUG("virtual = %p\n", entry->virtual);
drm_sg_cleanup(entry);
diff -uprN linux-2.6.23-mm1.orig/drivers/char/drm/drm_vm.c
linux-2.6.23-mm1/drivers/char/drm/drm_vm.c
--- linux-2.6.23-mm1.orig/drivers/char/drm/drm_vm.c 2007-10-17
22:19:21.0 +0200
+++ linux-2.6.23-mm1/drivers/char/drm/drm_vm.c 2007-10-17 22:22:19.0
+0200
@@ -180,7 +180,7 @@ static __inline__ struct page *drm_do_vm
return NOPAGE_SIGBUS;
get_page(page);
- DRM_DEBUG("shm_nopage 0x%lx\n", address);
+ DRM_DEBUG("0x%lx\n", address);
return page;
}
@@ -294,7 +294,7 @@ static __inline__ struct page *drm_do_vm
get_page(page);
- DRM_DEBUG("dma_nopage 0x%lx (page %lu)\n", address, page_nr);
+ DRM_DEBUG("0x%lx (page %lu)\n", address, page_nr);
return page;
}
diff -uprN linux-2.6.23-mm1.orig/drivers/char/drm/i810_dma.c
linux-2.6.23-mm1/drivers/char/drm/i810_dma.c
---
Re: [PATCH]: drm: cleanup DRM_DEBUG() parameters
From: Márton Németh [EMAIL PROTECTED]
As DRM_DEBUG macro already prints out the __FUNCTION__ string (see
drivers/char/drm/drmP.h), it is not worth doing this again. At some
other places the ending \n was added.
Signed-off-by: Márton Németh [EMAIL PROTECTED]
---
diff -uprN linux-2.6.23-mm1.orig/drivers/char/drm/ati_pcigart.c
linux-2.6.23-mm1/drivers/char/drm/ati_pcigart.c
--- linux-2.6.23-mm1.orig/drivers/char/drm/ati_pcigart.c2007-10-09
22:31:38.0 +0200
+++ linux-2.6.23-mm1/drivers/char/drm/ati_pcigart.c 2007-10-17
22:22:19.0 +0200
@@ -41,7 +41,7 @@ static void *drm_ati_alloc_pcigart_table
struct page *page;
int i;
- DRM_DEBUG(%s: alloc %d order\n, __FUNCTION__, order);
+ DRM_DEBUG(%d order\n, order);
address = __get_free_pages(GFP_KERNEL | __GFP_COMP,
order);
@@ -54,7 +54,7 @@ static void *drm_ati_alloc_pcigart_table
for (i = 0; i order; i++, page++)
SetPageReserved(page);
- DRM_DEBUG(%s: returning 0x%08lx\n, __FUNCTION__, address);
+ DRM_DEBUG(returning 0x%08lx\n, address);
return (void *)address;
}
@@ -63,7 +63,7 @@ static void drm_ati_free_pcigart_table(v
struct page *page;
int i;
int num_pages = 1 order;
- DRM_DEBUG(%s\n, __FUNCTION__);
+ DRM_DEBUG(\n);
page = virt_to_page((unsigned long)address);
diff -uprN linux-2.6.23-mm1.orig/drivers/char/drm/drm_irq.c
linux-2.6.23-mm1/drivers/char/drm/drm_irq.c
--- linux-2.6.23-mm1.orig/drivers/char/drm/drm_irq.c2007-10-17
22:19:21.0 +0200
+++ linux-2.6.23-mm1/drivers/char/drm/drm_irq.c 2007-10-17 22:22:19.0
+0200
@@ -107,7 +107,7 @@ static int drm_irq_install(struct drm_de
dev-irq_enabled = 1;
mutex_unlock(dev-struct_mutex);
- DRM_DEBUG(%s: irq=%d\n, __FUNCTION__, dev-irq);
+ DRM_DEBUG(irq=%d\n, dev-irq);
if (drm_core_check_feature(dev, DRIVER_IRQ_VBL)) {
init_waitqueue_head(dev-vbl_queue);
@@ -164,7 +164,7 @@ int drm_irq_uninstall(struct drm_device
if (!irq_enabled)
return -EINVAL;
- DRM_DEBUG(%s: irq=%d\n, __FUNCTION__, dev-irq);
+ DRM_DEBUG(irq=%d\n, dev-irq);
dev-driver-irq_uninstall(dev);
diff -uprN linux-2.6.23-mm1.orig/drivers/char/drm/drm_scatter.c
linux-2.6.23-mm1/drivers/char/drm/drm_scatter.c
--- linux-2.6.23-mm1.orig/drivers/char/drm/drm_scatter.c2007-10-17
22:19:21.0 +0200
+++ linux-2.6.23-mm1/drivers/char/drm/drm_scatter.c 2007-10-17
22:31:42.0 +0200
@@ -67,7 +67,7 @@ int drm_sg_alloc(struct drm_device *dev,
struct drm_sg_mem *entry;
unsigned long pages, i, j;
- DRM_DEBUG(%s\n, __FUNCTION__);
+ DRM_DEBUG(\n);
if (!drm_core_check_feature(dev, DRIVER_SG))
return -EINVAL;
@@ -81,7 +81,7 @@ int drm_sg_alloc(struct drm_device *dev,
memset(entry, 0, sizeof(*entry));
pages = (request-size + PAGE_SIZE - 1) / PAGE_SIZE;
- DRM_DEBUG(sg size=%ld pages=%ld\n, request-size, pages);
+ DRM_DEBUG(size=%ld pages=%ld\n, request-size, pages);
entry-pages = pages;
entry-pagelist = drm_alloc(pages * sizeof(*entry-pagelist),
@@ -122,8 +122,8 @@ int drm_sg_alloc(struct drm_device *dev,
entry-handle = ScatterHandle((unsigned long)entry-virtual);
- DRM_DEBUG(sg alloc handle = %08lx\n, entry-handle);
- DRM_DEBUG(sg alloc virtual = %p\n, entry-virtual);
+ DRM_DEBUG(handle = %08lx\n, entry-handle);
+ DRM_DEBUG(virtual = %p\n, entry-virtual);
for (i = (unsigned long)entry-virtual, j = 0; j pages;
i += PAGE_SIZE, j++) {
@@ -210,7 +210,7 @@ int drm_sg_free(struct drm_device *dev,
if (!entry || entry-handle != request-handle)
return -EINVAL;
- DRM_DEBUG(sg free virtual = %p\n, entry-virtual);
+ DRM_DEBUG(virtual = %p\n, entry-virtual);
drm_sg_cleanup(entry);
diff -uprN linux-2.6.23-mm1.orig/drivers/char/drm/drm_vm.c
linux-2.6.23-mm1/drivers/char/drm/drm_vm.c
--- linux-2.6.23-mm1.orig/drivers/char/drm/drm_vm.c 2007-10-17
22:19:21.0 +0200
+++ linux-2.6.23-mm1/drivers/char/drm/drm_vm.c 2007-10-17 22:22:19.0
+0200
@@ -180,7 +180,7 @@ static __inline__ struct page *drm_do_vm
return NOPAGE_SIGBUS;
get_page(page);
- DRM_DEBUG(shm_nopage 0x%lx\n, address);
+ DRM_DEBUG(0x%lx\n, address);
return page;
}
@@ -294,7 +294,7 @@ static __inline__ struct page *drm_do_vm
get_page(page);
- DRM_DEBUG(dma_nopage 0x%lx (page %lu)\n, address, page_nr);
+ DRM_DEBUG(0x%lx (page %lu)\n, address, page_nr);
return page;
}
diff -uprN linux-2.6.23-mm1.orig/drivers/char/drm/i810_dma.c
linux-2.6.23-mm1/drivers/char/drm/i810_dma.c
--- linux-2.6.23-mm1.orig/drivers/char/drm/i810_dma.c 2007-10-17
22:19:21.0 +0200
+++
Re: [PATCH]: drm: cleanup DRM_DEBUG() parameters
From: Márton Németh [EMAIL PROTECTED]
As DRM_DEBUG macro already prints out the __FUNCTION__ string (see
drivers/char/drm/drmP.h), it is not worth doing this again. At some
other places the ending \n was added.
Signed-off-by: Márton Németh [EMAIL PROTECTED]
---
diff -uprN linux-2.6.23-mm1.orig/drivers/char/drm/ati_pcigart.c
linux-2.6.23-mm1/drivers/char/drm/ati_pcigart.c
--- linux-2.6.23-mm1.orig/drivers/char/drm/ati_pcigart.c2007-10-09
22:31:38.0 +0200
+++ linux-2.6.23-mm1/drivers/char/drm/ati_pcigart.c 2007-10-17
22:22:19.0 +0200
@@ -41,7 +41,7 @@ static void *drm_ati_alloc_pcigart_table
struct page *page;
int i;
- DRM_DEBUG(%s: alloc %d order\n, __FUNCTION__, order);
+ DRM_DEBUG(%d order\n, order);
address = __get_free_pages(GFP_KERNEL | __GFP_COMP,
order);
@@ -54,7 +54,7 @@ static void *drm_ati_alloc_pcigart_table
for (i = 0; i order; i++, page++)
SetPageReserved(page);
- DRM_DEBUG(%s: returning 0x%08lx\n, __FUNCTION__, address);
+ DRM_DEBUG(returning 0x%08lx\n, address);
return (void *)address;
}
@@ -63,7 +63,7 @@ static void drm_ati_free_pcigart_table(v
struct page *page;
int i;
int num_pages = 1 order;
- DRM_DEBUG(%s\n, __FUNCTION__);
+ DRM_DEBUG(\n);
page = virt_to_page((unsigned long)address);
diff -uprN linux-2.6.23-mm1.orig/drivers/char/drm/drm_irq.c
linux-2.6.23-mm1/drivers/char/drm/drm_irq.c
--- linux-2.6.23-mm1.orig/drivers/char/drm/drm_irq.c2007-10-17
22:19:21.0 +0200
+++ linux-2.6.23-mm1/drivers/char/drm/drm_irq.c 2007-10-17 22:22:19.0
+0200
@@ -107,7 +107,7 @@ static int drm_irq_install(struct drm_de
dev-irq_enabled = 1;
mutex_unlock(dev-struct_mutex);
- DRM_DEBUG(%s: irq=%d\n, __FUNCTION__, dev-irq);
+ DRM_DEBUG(irq=%d\n, dev-irq);
if (drm_core_check_feature(dev, DRIVER_IRQ_VBL)) {
init_waitqueue_head(dev-vbl_queue);
@@ -164,7 +164,7 @@ int drm_irq_uninstall(struct drm_device
if (!irq_enabled)
return -EINVAL;
- DRM_DEBUG(%s: irq=%d\n, __FUNCTION__, dev-irq);
+ DRM_DEBUG(irq=%d\n, dev-irq);
dev-driver-irq_uninstall(dev);
diff -uprN linux-2.6.23-mm1.orig/drivers/char/drm/drm_scatter.c
linux-2.6.23-mm1/drivers/char/drm/drm_scatter.c
--- linux-2.6.23-mm1.orig/drivers/char/drm/drm_scatter.c2007-10-17
22:19:21.0 +0200
+++ linux-2.6.23-mm1/drivers/char/drm/drm_scatter.c 2007-10-17
22:31:42.0 +0200
@@ -67,7 +67,7 @@ int drm_sg_alloc(struct drm_device *dev,
struct drm_sg_mem *entry;
unsigned long pages, i, j;
- DRM_DEBUG(%s\n, __FUNCTION__);
+ DRM_DEBUG(\n);
if (!drm_core_check_feature(dev, DRIVER_SG))
return -EINVAL;
@@ -81,7 +81,7 @@ int drm_sg_alloc(struct drm_device *dev,
memset(entry, 0, sizeof(*entry));
pages = (request-size + PAGE_SIZE - 1) / PAGE_SIZE;
- DRM_DEBUG(sg size=%ld pages=%ld\n, request-size, pages);
+ DRM_DEBUG(size=%ld pages=%ld\n, request-size, pages);
entry-pages = pages;
entry-pagelist = drm_alloc(pages * sizeof(*entry-pagelist),
@@ -122,8 +122,8 @@ int drm_sg_alloc(struct drm_device *dev,
entry-handle = ScatterHandle((unsigned long)entry-virtual);
- DRM_DEBUG(sg alloc handle = %08lx\n, entry-handle);
- DRM_DEBUG(sg alloc virtual = %p\n, entry-virtual);
+ DRM_DEBUG(handle = %08lx\n, entry-handle);
+ DRM_DEBUG(virtual = %p\n, entry-virtual);
for (i = (unsigned long)entry-virtual, j = 0; j pages;
i += PAGE_SIZE, j++) {
@@ -210,7 +210,7 @@ int drm_sg_free(struct drm_device *dev,
if (!entry || entry-handle != request-handle)
return -EINVAL;
- DRM_DEBUG(sg free virtual = %p\n, entry-virtual);
+ DRM_DEBUG(virtual = %p\n, entry-virtual);
drm_sg_cleanup(entry);
diff -uprN linux-2.6.23-mm1.orig/drivers/char/drm/drm_vm.c
linux-2.6.23-mm1/drivers/char/drm/drm_vm.c
--- linux-2.6.23-mm1.orig/drivers/char/drm/drm_vm.c 2007-10-17
22:19:21.0 +0200
+++ linux-2.6.23-mm1/drivers/char/drm/drm_vm.c 2007-10-17 22:22:19.0
+0200
@@ -180,7 +180,7 @@ static __inline__ struct page *drm_do_vm
return NOPAGE_SIGBUS;
get_page(page);
- DRM_DEBUG(shm_nopage 0x%lx\n, address);
+ DRM_DEBUG(0x%lx\n, address);
return page;
}
@@ -294,7 +294,7 @@ static __inline__ struct page *drm_do_vm
get_page(page);
- DRM_DEBUG(dma_nopage 0x%lx (page %lu)\n, address, page_nr);
+ DRM_DEBUG(0x%lx (page %lu)\n, address, page_nr);
return page;
}
diff -uprN linux-2.6.23-mm1.orig/drivers/char/drm/i810_dma.c
linux-2.6.23-mm1/drivers/char/drm/i810_dma.c
--- linux-2.6.23-mm1.orig/drivers/char/drm/i810_dma.c 2007-10-17
22:19:21.0 +0200
+++
[PATCH]: drm: cleanup DRM_DEBUG() parameters
From: Márton Németh <[EMAIL PROTECTED]>
As DRM_DEBUG macro already prints out the __FUNCTION__ string (see
drivers/char/drm/drmP.h), it is not worth doing this again. At some
other places the ending "\n" was added.
Signed-off-by: Márton Németh <[EMAIL PROTECTED]>
---
diff -uprN linux-2.6.23.orig/drivers/char/drm/ati_pcigart.c
linux-2.6.23/drivers/char/drm/ati_pcigart.c
--- linux-2.6.23.orig/drivers/char/drm/ati_pcigart.c2007-10-09
22:31:38.0 +0200
+++ linux-2.6.23/drivers/char/drm/ati_pcigart.c 2007-10-13 17:54:48.0
+0200
@@ -41,7 +41,7 @@ static void *drm_ati_alloc_pcigart_table
struct page *page;
int i;
- DRM_DEBUG("%s: alloc %d order\n", __FUNCTION__, order);
+ DRM_DEBUG("%d order\n", order);
address = __get_free_pages(GFP_KERNEL | __GFP_COMP,
order);
@@ -54,7 +54,7 @@ static void *drm_ati_alloc_pcigart_table
for (i = 0; i < order; i++, page++)
SetPageReserved(page);
- DRM_DEBUG("%s: returning 0x%08lx\n", __FUNCTION__, address);
+ DRM_DEBUG("returning 0x%08lx\n", address);
return (void *)address;
}
@@ -63,7 +63,7 @@ static void drm_ati_free_pcigart_table(v
struct page *page;
int i;
int num_pages = 1 << order;
- DRM_DEBUG("%s\n", __FUNCTION__);
+ DRM_DEBUG("\n");
page = virt_to_page((unsigned long)address);
diff -uprN linux-2.6.23.orig/drivers/char/drm/drm_irq.c
linux-2.6.23/drivers/char/drm/drm_irq.c
--- linux-2.6.23.orig/drivers/char/drm/drm_irq.c2007-10-09
22:31:38.0 +0200
+++ linux-2.6.23/drivers/char/drm/drm_irq.c 2007-10-13 17:26:42.0
+0200
@@ -113,7 +113,7 @@ static int drm_irq_install(struct drm_de
dev->irq_enabled = 1;
mutex_unlock(>struct_mutex);
- DRM_DEBUG("%s: irq=%d\n", __FUNCTION__, dev->irq);
+ DRM_DEBUG("irq=%d\n", dev->irq);
if (drm_core_check_feature(dev, DRIVER_IRQ_VBL)) {
init_waitqueue_head(>vbl_queue);
@@ -170,7 +170,7 @@ int drm_irq_uninstall(struct drm_device
if (!irq_enabled)
return -EINVAL;
- DRM_DEBUG("%s: irq=%d\n", __FUNCTION__, dev->irq);
+ DRM_DEBUG("irq=%d\n", dev->irq);
dev->driver->irq_uninstall(dev);
diff -uprN linux-2.6.23.orig/drivers/char/drm/drm_scatter.c
linux-2.6.23/drivers/char/drm/drm_scatter.c
--- linux-2.6.23.orig/drivers/char/drm/drm_scatter.c2007-10-09
22:31:38.0 +0200
+++ linux-2.6.23/drivers/char/drm/drm_scatter.c 2007-10-13 17:49:52.0
+0200
@@ -72,7 +72,7 @@ int drm_sg_alloc(struct inode *inode, st
struct drm_sg_mem *entry;
unsigned long pages, i, j;
- DRM_DEBUG("%s\n", __FUNCTION__);
+ DRM_DEBUG("\n");
if (!drm_core_check_feature(dev, DRIVER_SG))
return -EINVAL;
@@ -90,7 +90,7 @@ int drm_sg_alloc(struct inode *inode, st
memset(entry, 0, sizeof(*entry));
pages = (request.size + PAGE_SIZE - 1) / PAGE_SIZE;
- DRM_DEBUG("sg size=%ld pages=%ld\n", request.size, pages);
+ DRM_DEBUG("size=%ld pages=%ld\n", request.size, pages);
entry->pages = pages;
entry->pagelist = drm_alloc(pages * sizeof(*entry->pagelist),
@@ -131,8 +131,8 @@ int drm_sg_alloc(struct inode *inode, st
entry->handle = ScatterHandle((unsigned long)entry->virtual);
- DRM_DEBUG("sg alloc handle = %08lx\n", entry->handle);
- DRM_DEBUG("sg alloc virtual = %p\n", entry->virtual);
+ DRM_DEBUG("handle = %08lx\n", entry->handle);
+ DRM_DEBUG("virtual = %p\n", entry->virtual);
for (i = (unsigned long)entry->virtual, j = 0; j < pages;
i += PAGE_SIZE, j++) {
@@ -220,7 +220,7 @@ int drm_sg_free(struct inode *inode, str
if (!entry || entry->handle != request.handle)
return -EINVAL;
- DRM_DEBUG("sg free virtual = %p\n", entry->virtual);
+ DRM_DEBUG("virtual = %p\n", entry->virtual);
drm_sg_cleanup(entry);
diff -uprN linux-2.6.23.orig/drivers/char/drm/drm_vm.c
linux-2.6.23/drivers/char/drm/drm_vm.c
--- linux-2.6.23.orig/drivers/char/drm/drm_vm.c 2007-10-09 22:31:38.0
+0200
+++ linux-2.6.23/drivers/char/drm/drm_vm.c 2007-10-13 17:48:30.0
+0200
@@ -180,7 +180,7 @@ static __inline__ struct page *drm_do_vm
return NOPAGE_SIGBUS;
get_page(page);
- DRM_DEBUG("shm_nopage 0x%lx\n", address);
+ DRM_DEBUG("0x%lx\n", address);
return page;
}
@@ -294,7 +294,7 @@ static __inline__ struct page *drm_do_vm
get_page(page);
- DRM_DEBUG("dma_nopage 0x%lx (page %lu)\n", address, page_nr);
+ DRM_DEBUG("0x%lx (page %lu)\n", address, page_nr);
return page;
}
diff -uprN linux-2.6.23.orig/drivers/char/drm/i810_dma.c
linux-2.6.23/drivers/char/drm/i810_dma.c
--- linux-2.6.23.orig/drivers/char/drm/i810_dma.c 2007-10-09
22:31:38.0 +0200
+++
[PATCH]: drm: cleanup DRM_DEBUG() parameters
From: Márton Németh [EMAIL PROTECTED]
As DRM_DEBUG macro already prints out the __FUNCTION__ string (see
drivers/char/drm/drmP.h), it is not worth doing this again. At some
other places the ending \n was added.
Signed-off-by: Márton Németh [EMAIL PROTECTED]
---
diff -uprN linux-2.6.23.orig/drivers/char/drm/ati_pcigart.c
linux-2.6.23/drivers/char/drm/ati_pcigart.c
--- linux-2.6.23.orig/drivers/char/drm/ati_pcigart.c2007-10-09
22:31:38.0 +0200
+++ linux-2.6.23/drivers/char/drm/ati_pcigart.c 2007-10-13 17:54:48.0
+0200
@@ -41,7 +41,7 @@ static void *drm_ati_alloc_pcigart_table
struct page *page;
int i;
- DRM_DEBUG(%s: alloc %d order\n, __FUNCTION__, order);
+ DRM_DEBUG(%d order\n, order);
address = __get_free_pages(GFP_KERNEL | __GFP_COMP,
order);
@@ -54,7 +54,7 @@ static void *drm_ati_alloc_pcigart_table
for (i = 0; i order; i++, page++)
SetPageReserved(page);
- DRM_DEBUG(%s: returning 0x%08lx\n, __FUNCTION__, address);
+ DRM_DEBUG(returning 0x%08lx\n, address);
return (void *)address;
}
@@ -63,7 +63,7 @@ static void drm_ati_free_pcigart_table(v
struct page *page;
int i;
int num_pages = 1 order;
- DRM_DEBUG(%s\n, __FUNCTION__);
+ DRM_DEBUG(\n);
page = virt_to_page((unsigned long)address);
diff -uprN linux-2.6.23.orig/drivers/char/drm/drm_irq.c
linux-2.6.23/drivers/char/drm/drm_irq.c
--- linux-2.6.23.orig/drivers/char/drm/drm_irq.c2007-10-09
22:31:38.0 +0200
+++ linux-2.6.23/drivers/char/drm/drm_irq.c 2007-10-13 17:26:42.0
+0200
@@ -113,7 +113,7 @@ static int drm_irq_install(struct drm_de
dev-irq_enabled = 1;
mutex_unlock(dev-struct_mutex);
- DRM_DEBUG(%s: irq=%d\n, __FUNCTION__, dev-irq);
+ DRM_DEBUG(irq=%d\n, dev-irq);
if (drm_core_check_feature(dev, DRIVER_IRQ_VBL)) {
init_waitqueue_head(dev-vbl_queue);
@@ -170,7 +170,7 @@ int drm_irq_uninstall(struct drm_device
if (!irq_enabled)
return -EINVAL;
- DRM_DEBUG(%s: irq=%d\n, __FUNCTION__, dev-irq);
+ DRM_DEBUG(irq=%d\n, dev-irq);
dev-driver-irq_uninstall(dev);
diff -uprN linux-2.6.23.orig/drivers/char/drm/drm_scatter.c
linux-2.6.23/drivers/char/drm/drm_scatter.c
--- linux-2.6.23.orig/drivers/char/drm/drm_scatter.c2007-10-09
22:31:38.0 +0200
+++ linux-2.6.23/drivers/char/drm/drm_scatter.c 2007-10-13 17:49:52.0
+0200
@@ -72,7 +72,7 @@ int drm_sg_alloc(struct inode *inode, st
struct drm_sg_mem *entry;
unsigned long pages, i, j;
- DRM_DEBUG(%s\n, __FUNCTION__);
+ DRM_DEBUG(\n);
if (!drm_core_check_feature(dev, DRIVER_SG))
return -EINVAL;
@@ -90,7 +90,7 @@ int drm_sg_alloc(struct inode *inode, st
memset(entry, 0, sizeof(*entry));
pages = (request.size + PAGE_SIZE - 1) / PAGE_SIZE;
- DRM_DEBUG(sg size=%ld pages=%ld\n, request.size, pages);
+ DRM_DEBUG(size=%ld pages=%ld\n, request.size, pages);
entry-pages = pages;
entry-pagelist = drm_alloc(pages * sizeof(*entry-pagelist),
@@ -131,8 +131,8 @@ int drm_sg_alloc(struct inode *inode, st
entry-handle = ScatterHandle((unsigned long)entry-virtual);
- DRM_DEBUG(sg alloc handle = %08lx\n, entry-handle);
- DRM_DEBUG(sg alloc virtual = %p\n, entry-virtual);
+ DRM_DEBUG(handle = %08lx\n, entry-handle);
+ DRM_DEBUG(virtual = %p\n, entry-virtual);
for (i = (unsigned long)entry-virtual, j = 0; j pages;
i += PAGE_SIZE, j++) {
@@ -220,7 +220,7 @@ int drm_sg_free(struct inode *inode, str
if (!entry || entry-handle != request.handle)
return -EINVAL;
- DRM_DEBUG(sg free virtual = %p\n, entry-virtual);
+ DRM_DEBUG(virtual = %p\n, entry-virtual);
drm_sg_cleanup(entry);
diff -uprN linux-2.6.23.orig/drivers/char/drm/drm_vm.c
linux-2.6.23/drivers/char/drm/drm_vm.c
--- linux-2.6.23.orig/drivers/char/drm/drm_vm.c 2007-10-09 22:31:38.0
+0200
+++ linux-2.6.23/drivers/char/drm/drm_vm.c 2007-10-13 17:48:30.0
+0200
@@ -180,7 +180,7 @@ static __inline__ struct page *drm_do_vm
return NOPAGE_SIGBUS;
get_page(page);
- DRM_DEBUG(shm_nopage 0x%lx\n, address);
+ DRM_DEBUG(0x%lx\n, address);
return page;
}
@@ -294,7 +294,7 @@ static __inline__ struct page *drm_do_vm
get_page(page);
- DRM_DEBUG(dma_nopage 0x%lx (page %lu)\n, address, page_nr);
+ DRM_DEBUG(0x%lx (page %lu)\n, address, page_nr);
return page;
}
diff -uprN linux-2.6.23.orig/drivers/char/drm/i810_dma.c
linux-2.6.23/drivers/char/drm/i810_dma.c
--- linux-2.6.23.orig/drivers/char/drm/i810_dma.c 2007-10-09
22:31:38.0 +0200
+++ linux-2.6.23/drivers/char/drm/i810_dma.c2007-10-13 17:46:05.0
+0200
@@ -641,7 +641,7 @@ static
Re: [PATCH 3/3] leds-clevo-mail: driver for Clevo mail LED
From: Márton Németh <[EMAIL PROTECTED]>
The driver supports the mail LED commonly found on different Clevo notebooks.
The driver access the LED through the i8042 hardware and implements the support
for
hardware accelerated blink function.
Signed-off-by: Márton Németh <[EMAIL PROTECTED]>
---
diff -uprN linux-2.6.22.orig/drivers/leds/Kconfig
linux-2.6.22/drivers/leds/Kconfig
--- linux-2.6.22.orig/drivers/leds/Kconfig 2007-07-09 01:32:17.0
+0200
+++ linux-2.6.22/drivers/leds/Kconfig 2007-07-17 10:52:43.0 +0200
@@ -95,6 +95,26 @@ config LEDS_COBALT
help
This option enables support for the front LED on Cobalt Server
+config LEDS_CLEVO_MAIL
+ tristate "Mail LED on Clevo notebook (EXPERIMENTAL)"
+ depends on LEDS_CLASS && X86 && SERIO_I8042 && DMI && EXPERIMENTAL
+ help
+ This driver makes the mail LED accessible from userspace
+ programs through the leds subsystem. This LED can blink at
+ about 0.5Hz and 1Hz.
+
+ This module can drive the mail LED for the following notebooks:
+
+ Clevo D410J
+ Clevo D410V
+ Clevo D400V/D470V (not tested, but might work)
+ Clevo M540N
+ Clevo M5x0N (not tested, but might work)
+ Positivo Mobile (Clevo M5x0V)
+
+ To compile this driver as a module, choose M here: the
+ module will be called leds-clevo-mail.
+
comment "LED Triggers"
config LEDS_TRIGGERS
diff -uprN linux-2.6.22.orig/drivers/leds/leds-clevo-mail.c
linux-2.6.22/drivers/leds/leds-clevo-mail.c
--- linux-2.6.22.orig/drivers/leds/leds-clevo-mail.c1970-01-01
01:00:00.0 +0100
+++ linux-2.6.22/drivers/leds/leds-clevo-mail.c 2007-07-17 17:53:34.0
+0200
@@ -0,0 +1,226 @@
+
+#include
+
+#include
+#include
+#include
+
+#include
+#include
+
+#include
+
+
+#define TRUE 1
+#define FALSE 0
+
+#define HANDLED0
+
+#define CLEVO_MAIL_LED_OFF 0x0084
+#define CLEVO_MAIL_LED_BLINK_1HZ 0x008A
+#define CLEVO_MAIL_LED_BLINK_0_5HZ 0x0083
+
+#define MODULE_FNAME "leds-clevo-mail.c"
+#define DRVNAME"clevo-mail-led"
+#define NO_RESOURCES NULL
+
+MODULE_AUTHOR("Márton Németh <[EMAIL PROTECTED]>");
+MODULE_DESCRIPTION("Clevo mail LED driver");
+MODULE_LICENSE("GPL");
+
+static unsigned int __initdata nodetect;
+module_param_named(nodetect, nodetect, bool, 0);
+MODULE_PARM_DESC(nodetect, "Skip DMI hardware detection");
+
+
+static struct platform_device *pdev;
+
+
+static int __init clevo_mail_led_dmi_callback(struct dmi_system_id *id)
+{
+ printk(KERN_INFO MODULE_FNAME ": '%s' found\n", id->ident);
+ return 1;
+}
+
+/**
+ * struct mail_led_whitelist - List of known good models
+ *
+ * Contains the known good models this driver is compatible with.
+ * When adding a new model try to be as strict as possible. This
+ * makes it possible to keep the false positives (the model is
+ * detected as working, but in reality it is not) as low as
+ * possible.
+ */
+static struct dmi_system_id __initdata mail_led_whitelist[] = {
+ {
+ .callback = clevo_mail_led_dmi_callback,
+ .ident = "Clevo D410J",
+ .matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, "VIA"),
+ DMI_MATCH(DMI_PRODUCT_NAME, "K8N800"),
+ DMI_MATCH(DMI_PRODUCT_VERSION, "VT8204B")
+ }
+ },
+ {
+ .callback = clevo_mail_led_dmi_callback,
+ .ident = "Clevo M5x0N",
+ .matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, "CLEVO Co."),
+ DMI_MATCH(DMI_PRODUCT_NAME, "M5x0N")
+ }
+ },
+ {
+ .callback = clevo_mail_led_dmi_callback,
+ .ident = "Positivo Mobile",
+ .matches = {
+ DMI_MATCH(DMI_BOARD_VENDOR, "CLEVO Co. "),
+ DMI_MATCH(DMI_BOARD_NAME, "M5X0V "),
+ DMI_MATCH(DMI_PRODUCT_NAME, "Positivo Mobile"),
+ DMI_MATCH(DMI_PRODUCT_VERSION, "VT6198")
+ }
+ },
+ {
+ .callback = clevo_mail_led_dmi_callback,
+ .ident = "Clevo D410V",
+ .matches = {
+ DMI_MATCH(DMI_BOARD_VENDOR, "Clevo, Co."),
+ DMI_MATCH(DMI_BOARD_NAME, "D400V/D470V"),
+ DMI_MATCH(DMI_BOARD_VERSION, "SS78B"),
+ DMI_MATCH(DMI_PRODUCT_VERSION, "Rev. A1")
+ }
+ },
+ { }
+};
+
+
+static void clevo_mail_led_set(struct led_classdev *led_cdev,
+ enum led_brightness value)
+{
+ if (value == LED_OFF)
+ i8042_command(NULL, CLEVO_MAIL_LED_OFF);
+ else if (value <= LED_HALF)
+
Re: [PATCH 1/3] leds-clevo-mail: export i8042_command()
From: Márton Németh <[EMAIL PROTECTED]>
Export the i8042_command() function which manages the mutual exclusion
with the help of the i8042_lock spinlock. This lets possible to use the
i8042 hardware safely from other part of the kernel, too.
Signed-off-by: Márton Németh <[EMAIL PROTECTED]>
---
diff -uprN linux-2.6.22.orig/drivers/input/serio/i8042.c
linux-2.6.22/drivers/input/serio/i8042.c
--- linux-2.6.22.orig/drivers/input/serio/i8042.c 2007-07-09
01:32:17.0 +0200
+++ linux-2.6.22/drivers/input/serio/i8042.c2007-07-17 17:03:54.0
+0200
@@ -20,6 +20,7 @@
#include
#include
#include
+#include
#include
@@ -208,7 +209,7 @@ static int __i8042_command(unsigned char
return 0;
}
-static int i8042_command(unsigned char *param, int command)
+int i8042_command(unsigned char *param, int command)
{
unsigned long flags;
int retval;
@@ -219,6 +220,7 @@ static int i8042_command(unsigned char *
return retval;
}
+EXPORT_SYMBOL(i8042_command);
/*
* i8042_kbd_write() sends a byte out through the keyboard interface.
diff -uprN linux-2.6.22.orig/include/linux/i8042.h
linux-2.6.22/include/linux/i8042.h
--- linux-2.6.22.orig/include/linux/i8042.h 1970-01-01 01:00:00.0
+0100
+++ linux-2.6.22/include/linux/i8042.h 2007-07-17 10:52:13.0 +0200
@@ -0,0 +1,10 @@
+
+/* There is already a header file linux/drivers/input/serio/i8042.h, so
+ * using the _LINUX prefix here as this is the file.
+ */
+#ifndef _LINUX_I8042_H
+#define _LINUX_I8402_H
+
+int i8042_command(unsigned char *param, int command);
+
+#endif
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/3] leds-clevo-mail: hw accelerated LED blink extension
From: Márton Németh <[EMAIL PROTECTED]>
Extends the leds subsystem with a blink_set() callback function which can
optionally implemented by a LED driver. If implemented, the driver can use the
hardware acceleration for blinking a LED.
Signed-off-by: Márton Németh <[EMAIL PROTECTED]>
---
diff -uprN linux-2.6.22.orig/Documentation/leds-class.txt
linux-2.6.22/Documentation/leds-class.txt
--- linux-2.6.22.orig/Documentation/leds-class.txt 2007-07-09
01:32:17.0 +0200
+++ linux-2.6.22/Documentation/leds-class.txt 2007-07-17 17:07:44.0
+0200
@@ -47,6 +47,17 @@ overhead, I suggest these become part of
above leaves scope for further attributes should they be needed.
+Hardware accelerated blink of LEDs
+==
+
+Some LEDs can be programmed to blink without any CPU interaction. To
+support this feature, a LED driver can optionally implement the
+blink_set() function (see ). If implemeted, the
+ledtrig-timer tries to use it. The blink_set() function should return
+0 if the blink setting is supported, or -EINVAL otherwise, which means
+that the LED will be turned on and off from software.
+
+
Known Issues
@@ -55,10 +66,6 @@ would cause nightmare dependency issues.
compared to the benefits the simple trigger functionality brings. The
rest of the LED subsystem can be modular.
-Some leds can be programmed to flash in hardware. As this isn't a generic
-LED device property, this should be exported as a device specific sysfs
-attribute rather than part of the class if this functionality is required.
-
Future Development
==
diff -uprN linux-2.6.22.orig/drivers/leds/ledtrig-timer.c
linux-2.6.22/drivers/leds/ledtrig-timer.c
--- linux-2.6.22.orig/drivers/leds/ledtrig-timer.c 2007-07-09
01:32:17.0 +0200
+++ linux-2.6.22/drivers/leds/ledtrig-timer.c 2007-07-17 17:45:56.0
+0200
@@ -76,8 +76,21 @@ static ssize_t led_delay_on_store(struct
count++;
if (count == size) {
- timer_data->delay_on = state;
- mod_timer(_data->timer, jiffies + 1);
+ if (timer_data->delay_on != state) {
+ /* the new value differs from the previous */
+ timer_data->delay_on = state;
+
+ /* deactivate previous settings */
+ del_timer_sync(_data->timer);
+
+ /* try to activate hardware acceleration, if any */
+ if (!led_cdev->blink_set ||
+ led_cdev->blink_set(led_cdev,
+ timer_data->delay_on, timer_data->delay_off)) {
+ /* no hardware acceleration, blink via timer */
+ mod_timer(_data->timer, jiffies + 1);
+ }
+ }
ret = count;
}
@@ -108,8 +121,21 @@ static ssize_t led_delay_off_store(struc
count++;
if (count == size) {
- timer_data->delay_off = state;
- mod_timer(_data->timer, jiffies + 1);
+ if (timer_data->delay_off != state) {
+ /* the new value differs from the previous */
+ timer_data->delay_off = state;
+
+ /* deactivate previous settings */
+ del_timer_sync(_data->timer);
+
+ /* try to activate hardware acceleration, if any */
+ if (!led_cdev->blink_set ||
+ led_cdev->blink_set(led_cdev,
+ timer_data->delay_on, timer_data->delay_off)) {
+ /* no hardware acceleration, blink via timer */
+ mod_timer(_data->timer, jiffies + 1);
+ }
+ }
ret = count;
}
diff -uprN linux-2.6.22.orig/include/linux/leds.h
linux-2.6.22/include/linux/leds.h
--- linux-2.6.22.orig/include/linux/leds.h 2007-07-09 01:32:17.0
+0200
+++ linux-2.6.22/include/linux/leds.h 2007-07-17 10:52:18.0 +0200
@@ -38,6 +38,11 @@ struct led_classdev {
void(*brightness_set)(struct led_classdev *led_cdev,
enum led_brightness brightness);
+ /* Activate hardware accelerated blink */
+ int (*blink_set)(struct led_classdev *led_cdev,
+int delay_on, int delay_off);
+
+
struct class_device *class_dev;
struct list_head node; /* LED Device list */
char*default_trigger; /* Trigger to use */
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3/3] leds-clevo-mail: driver for Clevo mail LED
From: Márton Németh <[EMAIL PROTECTED]>
The driver supports the mail LED commonly found on different Clevo notebooks.
The driver access the LED through the i8042 hardware and implements the support
for
hardware accelerated blink function.
Signed-off-by: Márton Németh <[EMAIL PROTECTED]>
---
diff -uprN linux-2.6.22.orig/drivers/leds/Kconfig
linux-2.6.22/drivers/leds/Kconfig
--- linux-2.6.22.orig/drivers/leds/Kconfig 2007-07-09 01:32:17.0
+0200
+++ linux-2.6.22/drivers/leds/Kconfig 2007-07-16 20:54:36.0 +0200
@@ -95,6 +95,26 @@ config LEDS_COBALT
help
This option enables support for the front LED on Cobalt Server
+config LEDS_CLEVO_MAIL
+ tristate "Mail LED on Clevo notebook (EXPERIMENTAL)"
+ depends on LEDS_CLASS && X86 && SERIO_I8042 && DMI && EXPERIMENTAL
+ help
+ This driver makes the mail LED accessible from userspace
+ programs through the leds subsystem. This LED can blink at
+ about 0.5Hz and 1Hz.
+
+ This module can drive the mail LED for the following notebooks:
+
+ Clevo D410J
+ Clevo D410V
+ Clevo D400V/D470V (not tested, but might work)
+ Clevo M540N
+ Clevo M5x0N (not tested, but might work)
+ Positivo Mobile (Clevo M5x0V)
+
+ To compile this driver as a module, choose M here: the
+ module will be called leds-clevo-mail.
+
comment "LED Triggers"
config LEDS_TRIGGERS
diff -uprN linux-2.6.22.orig/drivers/leds/leds-clevo-mail.c
linux-2.6.22/drivers/leds/leds-clevo-mail.c
--- linux-2.6.22.orig/drivers/leds/leds-clevo-mail.c1970-01-01
01:00:00.0 +0100
+++ linux-2.6.22/drivers/leds/leds-clevo-mail.c 2007-07-17 10:47:13.0
+0200
@@ -0,0 +1,269 @@
+
+#include
+
+#include
+#include
+#include
+
+#include
+#include
+
+#include
+
+
+#define TRUE 1
+#define FALSE 0
+
+#define CLEVO_MAIL_LED_OFF 0x0084
+#define CLEVO_MAIL_LED_BLINK_1HZ 0x008A
+#define CLEVO_MAIL_LED_BLINK_0_5HZ 0x0083
+
+#define MODULE_FNAME "leds-clevo-mail.c"
+#define DRVNAME"clevo-mail-led"
+#define NO_RESOURCES NULL
+
+#define printk_hint(fmt, args...) \
+ printk(KERN_ERR MODULE_FNAME ": " fmt, ## args)
+
+
+#define printk_dmi(field) \
+ printk(KERN_ERR MODULE_FNAME\
+ ":" # field "=\"%s\"\n", \
+ dmi_get_system_info(field))
+
+
+MODULE_AUTHOR("Márton Németh <[EMAIL PROTECTED]>");
+MODULE_DESCRIPTION("Clevo mail LED driver");
+MODULE_LICENSE("GPL");
+
+static unsigned int __initdata nodetect;
+module_param_named(nodetect, nodetect, bool, 0);
+MODULE_PARM_DESC(nodetect, "Skip DMI hardware detection");
+
+
+static struct platform_device *pdev;
+
+
+static int __init led_dmi_callback(struct dmi_system_id *id) {
+ printk(KERN_INFO MODULE_FNAME ": '%s' found\n", id->ident);
+ return 1;
+}
+
+/**
+ * struct mail_led_whitelist - List of known good models
+ *
+ * Contains the known good models this driver is compatible with.
+ * When adding a new model try to be as strict as possible. This
+ * makes it possible to keep the false positives (the model is
+ * detected as working, but in reality it is not) as low as
+ * possible.
+ */
+static struct dmi_system_id __initdata mail_led_whitelist[] = {
+ {
+ .callback = led_dmi_callback,
+ .ident = "Clevo D410J",
+ .matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, "VIA"),
+ DMI_MATCH(DMI_PRODUCT_NAME, "K8N800"),
+ DMI_MATCH(DMI_PRODUCT_VERSION, "VT8204B")
+ }
+ },
+ {
+ .callback = led_dmi_callback,
+ .ident = "Clevo M5x0N",
+ .matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, "CLEVO Co."),
+ DMI_MATCH(DMI_PRODUCT_NAME, "M5x0N")
+ }
+ },
+ {
+ .callback = led_dmi_callback,
+ .ident = "Positivo Mobile",
+ .matches = {
+ DMI_MATCH(DMI_BOARD_VENDOR, "CLEVO Co. "),
+ DMI_MATCH(DMI_BOARD_NAME, "M5X0V "),
+ DMI_MATCH(DMI_PRODUCT_NAME, "Positivo Mobile"),
+ DMI_MATCH(DMI_PRODUCT_VERSION, "VT6198")
+ }
+ },
+ {
+ .callback = led_dmi_callback,
+ .ident = "Clevo D410V",
+ .matches = {
+ DMI_MATCH(DMI_BOARD_VENDOR, "Clevo, Co."),
+ DMI_MATCH(DMI_BOARD_NAME, "D400V/D470V"),
+ DMI_MATCH(DMI_BOARD_VERSION, "SS78B"),
+ DMI_MATCH(DMI_PRODUCT_VERSION, "Rev. A1")
+ }
+ },
+ { }
+};
+
+
+static void clevo_mail_led_set(struct
[PATCH 1/3] leds-clevo-mail: export i8042_command()
From: Márton Németh <[EMAIL PROTECTED]>
Export the i8042_command() function which manages the mutual exclusion
with the help of the i8042_lock spinlock. This lets possible to use the
i8042 hardware safely from other part of the kernel, too.
Signed-off-by: Márton Németh <[EMAIL PROTECTED]>
---
diff -uprN linux-2.6.22.orig/drivers/input/serio/i8042.c
linux-2.6.22/drivers/input/serio/i8042.c
--- linux-2.6.22.orig/drivers/input/serio/i8042.c 2007-07-09
01:32:17.0 +0200
+++ linux-2.6.22/drivers/input/serio/i8042.c2007-07-16 20:53:38.0
+0200
@@ -208,7 +208,7 @@ static int __i8042_command(unsigned char
return 0;
}
-static int i8042_command(unsigned char *param, int command)
+int i8042_command(unsigned char *param, int command)
{
unsigned long flags;
int retval;
@@ -219,6 +219,7 @@ static int i8042_command(unsigned char *
return retval;
}
+EXPORT_SYMBOL(i8042_command);
/*
* i8042_kbd_write() sends a byte out through the keyboard interface.
diff -uprN linux-2.6.22.orig/include/linux/i8042.h
linux-2.6.22/include/linux/i8042.h
--- linux-2.6.22.orig/include/linux/i8042.h 1970-01-01 01:00:00.0
+0100
+++ linux-2.6.22/include/linux/i8042.h 2007-07-16 21:00:54.0 +0200
@@ -0,0 +1,10 @@
+
+/* There is already a header file linux/drivers/input/serio/i8042.h, so
+ * using the _LINUX prefix here as this is the file.
+ */
+#ifndef _LINUX_I8042_H
+#define _LINUX_I8402_H
+
+int i8042_command(unsigned char *param, int command);
+
+#endif
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/3] leds-clevo-mail: hw accelerated LED blink extension
From: Márton Németh <[EMAIL PROTECTED]>
Extends the leds subsystem with a blink_set() callback function which can
optionally implemented by a LED driver. If implemented, the driver can use the
hardware acceleration for blinking a LED.
Signed-off-by: Márton Németh <[EMAIL PROTECTED]>
---
diff -uprN linux-2.6.22.orig/Documentation/leds-class.txt
linux-2.6.22/Documentation/leds-class.txt
--- linux-2.6.22.orig/Documentation/leds-class.txt 2007-07-09
01:32:17.0 +0200
+++ linux-2.6.22/Documentation/leds-class.txt 2007-07-16 20:53:38.0
+0200
@@ -47,6 +47,17 @@ overhead, I suggest these become part of
above leaves scope for further attributes should they be needed.
+Hardware accelerated blink of LEDs
+==
+
+Some LEDs can be programmed to blink without any CPU interaction. To
+support this feature, a LED driver can optionally implement the
+blink_set() function (see ). If implemeted, the
+ledtrig-timer tries to use it. The blink_set() function should return
+1 if the blink setting is supported, or 0 otherwise, which means that
+the LED will be turned on and off from software.
+
+
Known Issues
@@ -55,10 +66,6 @@ would cause nightmare dependency issues.
compared to the benefits the simple trigger functionality brings. The
rest of the LED subsystem can be modular.
-Some leds can be programmed to flash in hardware. As this isn't a generic
-LED device property, this should be exported as a device specific sysfs
-attribute rather than part of the class if this functionality is required.
-
Future Development
==
diff -uprN linux-2.6.22.orig/drivers/leds/ledtrig-timer.c
linux-2.6.22/drivers/leds/ledtrig-timer.c
--- linux-2.6.22.orig/drivers/leds/ledtrig-timer.c 2007-07-09
01:32:17.0 +0200
+++ linux-2.6.22/drivers/leds/ledtrig-timer.c 2007-07-17 09:43:20.0
+0200
@@ -76,8 +76,21 @@ static ssize_t led_delay_on_store(struct
count++;
if (count == size) {
- timer_data->delay_on = state;
- mod_timer(_data->timer, jiffies + 1);
+ if (timer_data->delay_on != state) {
+ /* the new value differs from the previous */
+ timer_data->delay_on = state;
+
+ /* deactivate previous settings */
+ del_timer_sync(_data->timer);
+
+ /* try to activate hardware acceleration, if any */
+ if (!led_cdev->blink_set ||
+ !led_cdev->blink_set(led_cdev,
+ timer_data->delay_on, timer_data->delay_off)) {
+ /* no hardware acceleration, blink via timer */
+ mod_timer(_data->timer, jiffies + 1);
+ }
+ }
ret = count;
}
@@ -108,8 +121,21 @@ static ssize_t led_delay_off_store(struc
count++;
if (count == size) {
- timer_data->delay_off = state;
- mod_timer(_data->timer, jiffies + 1);
+ if (timer_data->delay_off != state) {
+ /* the new value differs from the previous */
+ timer_data->delay_off = state;
+
+ /* deactivate previous settings */
+ del_timer_sync(_data->timer);
+
+ /* try to activate hardware acceleration, if any */
+ if (!led_cdev->blink_set ||
+ !led_cdev->blink_set(led_cdev,
+ timer_data->delay_on, timer_data->delay_off)) {
+ /* no hardware acceleration, blink via timer */
+ mod_timer(_data->timer, jiffies + 1);
+ }
+ }
ret = count;
}
diff -uprN linux-2.6.22.orig/include/linux/leds.h
linux-2.6.22/include/linux/leds.h
--- linux-2.6.22.orig/include/linux/leds.h 2007-07-09 01:32:17.0
+0200
+++ linux-2.6.22/include/linux/leds.h 2007-07-16 20:53:38.0 +0200
@@ -38,6 +38,11 @@ struct led_classdev {
void(*brightness_set)(struct led_classdev *led_cdev,
enum led_brightness brightness);
+ /* Activate hardware accelerated blink */
+ int (*blink_set)(struct led_classdev *led_cdev,
+int delay_on, int delay_off);
+
+
struct class_device *class_dev;
struct list_head node; /* LED Device list */
char*default_trigger; /* Trigger to use */
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/3] leds-clevo-mail: export i8042_command()
From: Márton Németh [EMAIL PROTECTED]
Export the i8042_command() function which manages the mutual exclusion
with the help of the i8042_lock spinlock. This lets possible to use the
i8042 hardware safely from other part of the kernel, too.
Signed-off-by: Márton Németh [EMAIL PROTECTED]
---
diff -uprN linux-2.6.22.orig/drivers/input/serio/i8042.c
linux-2.6.22/drivers/input/serio/i8042.c
--- linux-2.6.22.orig/drivers/input/serio/i8042.c 2007-07-09
01:32:17.0 +0200
+++ linux-2.6.22/drivers/input/serio/i8042.c2007-07-16 20:53:38.0
+0200
@@ -208,7 +208,7 @@ static int __i8042_command(unsigned char
return 0;
}
-static int i8042_command(unsigned char *param, int command)
+int i8042_command(unsigned char *param, int command)
{
unsigned long flags;
int retval;
@@ -219,6 +219,7 @@ static int i8042_command(unsigned char *
return retval;
}
+EXPORT_SYMBOL(i8042_command);
/*
* i8042_kbd_write() sends a byte out through the keyboard interface.
diff -uprN linux-2.6.22.orig/include/linux/i8042.h
linux-2.6.22/include/linux/i8042.h
--- linux-2.6.22.orig/include/linux/i8042.h 1970-01-01 01:00:00.0
+0100
+++ linux-2.6.22/include/linux/i8042.h 2007-07-16 21:00:54.0 +0200
@@ -0,0 +1,10 @@
+
+/* There is already a header file linux/drivers/input/serio/i8042.h, so
+ * using the _LINUX prefix here as this is the linux/i8042.h file.
+ */
+#ifndef _LINUX_I8042_H
+#define _LINUX_I8402_H
+
+int i8042_command(unsigned char *param, int command);
+
+#endif
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/3] leds-clevo-mail: hw accelerated LED blink extension
From: Márton Németh [EMAIL PROTECTED]
Extends the leds subsystem with a blink_set() callback function which can
optionally implemented by a LED driver. If implemented, the driver can use the
hardware acceleration for blinking a LED.
Signed-off-by: Márton Németh [EMAIL PROTECTED]
---
diff -uprN linux-2.6.22.orig/Documentation/leds-class.txt
linux-2.6.22/Documentation/leds-class.txt
--- linux-2.6.22.orig/Documentation/leds-class.txt 2007-07-09
01:32:17.0 +0200
+++ linux-2.6.22/Documentation/leds-class.txt 2007-07-16 20:53:38.0
+0200
@@ -47,6 +47,17 @@ overhead, I suggest these become part of
above leaves scope for further attributes should they be needed.
+Hardware accelerated blink of LEDs
+==
+
+Some LEDs can be programmed to blink without any CPU interaction. To
+support this feature, a LED driver can optionally implement the
+blink_set() function (see linux/leds.h). If implemeted, the
+ledtrig-timer tries to use it. The blink_set() function should return
+1 if the blink setting is supported, or 0 otherwise, which means that
+the LED will be turned on and off from software.
+
+
Known Issues
@@ -55,10 +66,6 @@ would cause nightmare dependency issues.
compared to the benefits the simple trigger functionality brings. The
rest of the LED subsystem can be modular.
-Some leds can be programmed to flash in hardware. As this isn't a generic
-LED device property, this should be exported as a device specific sysfs
-attribute rather than part of the class if this functionality is required.
-
Future Development
==
diff -uprN linux-2.6.22.orig/drivers/leds/ledtrig-timer.c
linux-2.6.22/drivers/leds/ledtrig-timer.c
--- linux-2.6.22.orig/drivers/leds/ledtrig-timer.c 2007-07-09
01:32:17.0 +0200
+++ linux-2.6.22/drivers/leds/ledtrig-timer.c 2007-07-17 09:43:20.0
+0200
@@ -76,8 +76,21 @@ static ssize_t led_delay_on_store(struct
count++;
if (count == size) {
- timer_data-delay_on = state;
- mod_timer(timer_data-timer, jiffies + 1);
+ if (timer_data-delay_on != state) {
+ /* the new value differs from the previous */
+ timer_data-delay_on = state;
+
+ /* deactivate previous settings */
+ del_timer_sync(timer_data-timer);
+
+ /* try to activate hardware acceleration, if any */
+ if (!led_cdev-blink_set ||
+ !led_cdev-blink_set(led_cdev,
+ timer_data-delay_on, timer_data-delay_off)) {
+ /* no hardware acceleration, blink via timer */
+ mod_timer(timer_data-timer, jiffies + 1);
+ }
+ }
ret = count;
}
@@ -108,8 +121,21 @@ static ssize_t led_delay_off_store(struc
count++;
if (count == size) {
- timer_data-delay_off = state;
- mod_timer(timer_data-timer, jiffies + 1);
+ if (timer_data-delay_off != state) {
+ /* the new value differs from the previous */
+ timer_data-delay_off = state;
+
+ /* deactivate previous settings */
+ del_timer_sync(timer_data-timer);
+
+ /* try to activate hardware acceleration, if any */
+ if (!led_cdev-blink_set ||
+ !led_cdev-blink_set(led_cdev,
+ timer_data-delay_on, timer_data-delay_off)) {
+ /* no hardware acceleration, blink via timer */
+ mod_timer(timer_data-timer, jiffies + 1);
+ }
+ }
ret = count;
}
diff -uprN linux-2.6.22.orig/include/linux/leds.h
linux-2.6.22/include/linux/leds.h
--- linux-2.6.22.orig/include/linux/leds.h 2007-07-09 01:32:17.0
+0200
+++ linux-2.6.22/include/linux/leds.h 2007-07-16 20:53:38.0 +0200
@@ -38,6 +38,11 @@ struct led_classdev {
void(*brightness_set)(struct led_classdev *led_cdev,
enum led_brightness brightness);
+ /* Activate hardware accelerated blink */
+ int (*blink_set)(struct led_classdev *led_cdev,
+int delay_on, int delay_off);
+
+
struct class_device *class_dev;
struct list_head node; /* LED Device list */
char*default_trigger; /* Trigger to use */
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at
[PATCH 3/3] leds-clevo-mail: driver for Clevo mail LED
From: Márton Németh [EMAIL PROTECTED]
The driver supports the mail LED commonly found on different Clevo notebooks.
The driver access the LED through the i8042 hardware and implements the support
for
hardware accelerated blink function.
Signed-off-by: Márton Németh [EMAIL PROTECTED]
---
diff -uprN linux-2.6.22.orig/drivers/leds/Kconfig
linux-2.6.22/drivers/leds/Kconfig
--- linux-2.6.22.orig/drivers/leds/Kconfig 2007-07-09 01:32:17.0
+0200
+++ linux-2.6.22/drivers/leds/Kconfig 2007-07-16 20:54:36.0 +0200
@@ -95,6 +95,26 @@ config LEDS_COBALT
help
This option enables support for the front LED on Cobalt Server
+config LEDS_CLEVO_MAIL
+ tristate Mail LED on Clevo notebook (EXPERIMENTAL)
+ depends on LEDS_CLASS X86 SERIO_I8042 DMI EXPERIMENTAL
+ help
+ This driver makes the mail LED accessible from userspace
+ programs through the leds subsystem. This LED can blink at
+ about 0.5Hz and 1Hz.
+
+ This module can drive the mail LED for the following notebooks:
+
+ Clevo D410J
+ Clevo D410V
+ Clevo D400V/D470V (not tested, but might work)
+ Clevo M540N
+ Clevo M5x0N (not tested, but might work)
+ Positivo Mobile (Clevo M5x0V)
+
+ To compile this driver as a module, choose M here: the
+ module will be called leds-clevo-mail.
+
comment LED Triggers
config LEDS_TRIGGERS
diff -uprN linux-2.6.22.orig/drivers/leds/leds-clevo-mail.c
linux-2.6.22/drivers/leds/leds-clevo-mail.c
--- linux-2.6.22.orig/drivers/leds/leds-clevo-mail.c1970-01-01
01:00:00.0 +0100
+++ linux-2.6.22/drivers/leds/leds-clevo-mail.c 2007-07-17 10:47:13.0
+0200
@@ -0,0 +1,269 @@
+
+#include linux/module.h
+
+#include linux/platform_device.h
+#include linux/err.h
+#include linux/leds.h
+
+#include linux/io.h
+#include linux/dmi.h
+
+#include linux/i8042.h
+
+
+#define TRUE 1
+#define FALSE 0
+
+#define CLEVO_MAIL_LED_OFF 0x0084
+#define CLEVO_MAIL_LED_BLINK_1HZ 0x008A
+#define CLEVO_MAIL_LED_BLINK_0_5HZ 0x0083
+
+#define MODULE_FNAME leds-clevo-mail.c
+#define DRVNAMEclevo-mail-led
+#define NO_RESOURCES NULL
+
+#define printk_hint(fmt, args...) \
+ printk(KERN_ERR MODULE_FNAME : fmt, ## args)
+
+
+#define printk_dmi(field) \
+ printk(KERN_ERR MODULE_FNAME\
+ : # field =\%s\\n, \
+ dmi_get_system_info(field))
+
+
+MODULE_AUTHOR(Márton Németh [EMAIL PROTECTED]);
+MODULE_DESCRIPTION(Clevo mail LED driver);
+MODULE_LICENSE(GPL);
+
+static unsigned int __initdata nodetect;
+module_param_named(nodetect, nodetect, bool, 0);
+MODULE_PARM_DESC(nodetect, Skip DMI hardware detection);
+
+
+static struct platform_device *pdev;
+
+
+static int __init led_dmi_callback(struct dmi_system_id *id) {
+ printk(KERN_INFO MODULE_FNAME : '%s' found\n, id-ident);
+ return 1;
+}
+
+/**
+ * struct mail_led_whitelist - List of known good models
+ *
+ * Contains the known good models this driver is compatible with.
+ * When adding a new model try to be as strict as possible. This
+ * makes it possible to keep the false positives (the model is
+ * detected as working, but in reality it is not) as low as
+ * possible.
+ */
+static struct dmi_system_id __initdata mail_led_whitelist[] = {
+ {
+ .callback = led_dmi_callback,
+ .ident = Clevo D410J,
+ .matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, VIA),
+ DMI_MATCH(DMI_PRODUCT_NAME, K8N800),
+ DMI_MATCH(DMI_PRODUCT_VERSION, VT8204B)
+ }
+ },
+ {
+ .callback = led_dmi_callback,
+ .ident = Clevo M5x0N,
+ .matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, CLEVO Co.),
+ DMI_MATCH(DMI_PRODUCT_NAME, M5x0N)
+ }
+ },
+ {
+ .callback = led_dmi_callback,
+ .ident = Positivo Mobile,
+ .matches = {
+ DMI_MATCH(DMI_BOARD_VENDOR, CLEVO Co. ),
+ DMI_MATCH(DMI_BOARD_NAME, M5X0V ),
+ DMI_MATCH(DMI_PRODUCT_NAME, Positivo Mobile),
+ DMI_MATCH(DMI_PRODUCT_VERSION, VT6198)
+ }
+ },
+ {
+ .callback = led_dmi_callback,
+ .ident = Clevo D410V,
+ .matches = {
+ DMI_MATCH(DMI_BOARD_VENDOR, Clevo, Co.),
+ DMI_MATCH(DMI_BOARD_NAME, D400V/D470V),
+ DMI_MATCH(DMI_BOARD_VERSION, SS78B),
+ DMI_MATCH(DMI_PRODUCT_VERSION, Rev. A1)
+ }
+ },
+ { }
+};
+
+
+static void
Re: [PATCH 1/3] leds-clevo-mail: export i8042_command()
From: Márton Németh [EMAIL PROTECTED]
Export the i8042_command() function which manages the mutual exclusion
with the help of the i8042_lock spinlock. This lets possible to use the
i8042 hardware safely from other part of the kernel, too.
Signed-off-by: Márton Németh [EMAIL PROTECTED]
---
diff -uprN linux-2.6.22.orig/drivers/input/serio/i8042.c
linux-2.6.22/drivers/input/serio/i8042.c
--- linux-2.6.22.orig/drivers/input/serio/i8042.c 2007-07-09
01:32:17.0 +0200
+++ linux-2.6.22/drivers/input/serio/i8042.c2007-07-17 17:03:54.0
+0200
@@ -20,6 +20,7 @@
#include linux/err.h
#include linux/rcupdate.h
#include linux/platform_device.h
+#include linux/i8042.h
#include asm/io.h
@@ -208,7 +209,7 @@ static int __i8042_command(unsigned char
return 0;
}
-static int i8042_command(unsigned char *param, int command)
+int i8042_command(unsigned char *param, int command)
{
unsigned long flags;
int retval;
@@ -219,6 +220,7 @@ static int i8042_command(unsigned char *
return retval;
}
+EXPORT_SYMBOL(i8042_command);
/*
* i8042_kbd_write() sends a byte out through the keyboard interface.
diff -uprN linux-2.6.22.orig/include/linux/i8042.h
linux-2.6.22/include/linux/i8042.h
--- linux-2.6.22.orig/include/linux/i8042.h 1970-01-01 01:00:00.0
+0100
+++ linux-2.6.22/include/linux/i8042.h 2007-07-17 10:52:13.0 +0200
@@ -0,0 +1,10 @@
+
+/* There is already a header file linux/drivers/input/serio/i8042.h, so
+ * using the _LINUX prefix here as this is the linux/i8042.h file.
+ */
+#ifndef _LINUX_I8042_H
+#define _LINUX_I8402_H
+
+int i8042_command(unsigned char *param, int command);
+
+#endif
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/3] leds-clevo-mail: hw accelerated LED blink extension
From: Márton Németh [EMAIL PROTECTED]
Extends the leds subsystem with a blink_set() callback function which can
optionally implemented by a LED driver. If implemented, the driver can use the
hardware acceleration for blinking a LED.
Signed-off-by: Márton Németh [EMAIL PROTECTED]
---
diff -uprN linux-2.6.22.orig/Documentation/leds-class.txt
linux-2.6.22/Documentation/leds-class.txt
--- linux-2.6.22.orig/Documentation/leds-class.txt 2007-07-09
01:32:17.0 +0200
+++ linux-2.6.22/Documentation/leds-class.txt 2007-07-17 17:07:44.0
+0200
@@ -47,6 +47,17 @@ overhead, I suggest these become part of
above leaves scope for further attributes should they be needed.
+Hardware accelerated blink of LEDs
+==
+
+Some LEDs can be programmed to blink without any CPU interaction. To
+support this feature, a LED driver can optionally implement the
+blink_set() function (see linux/leds.h). If implemeted, the
+ledtrig-timer tries to use it. The blink_set() function should return
+0 if the blink setting is supported, or -EINVAL otherwise, which means
+that the LED will be turned on and off from software.
+
+
Known Issues
@@ -55,10 +66,6 @@ would cause nightmare dependency issues.
compared to the benefits the simple trigger functionality brings. The
rest of the LED subsystem can be modular.
-Some leds can be programmed to flash in hardware. As this isn't a generic
-LED device property, this should be exported as a device specific sysfs
-attribute rather than part of the class if this functionality is required.
-
Future Development
==
diff -uprN linux-2.6.22.orig/drivers/leds/ledtrig-timer.c
linux-2.6.22/drivers/leds/ledtrig-timer.c
--- linux-2.6.22.orig/drivers/leds/ledtrig-timer.c 2007-07-09
01:32:17.0 +0200
+++ linux-2.6.22/drivers/leds/ledtrig-timer.c 2007-07-17 17:45:56.0
+0200
@@ -76,8 +76,21 @@ static ssize_t led_delay_on_store(struct
count++;
if (count == size) {
- timer_data-delay_on = state;
- mod_timer(timer_data-timer, jiffies + 1);
+ if (timer_data-delay_on != state) {
+ /* the new value differs from the previous */
+ timer_data-delay_on = state;
+
+ /* deactivate previous settings */
+ del_timer_sync(timer_data-timer);
+
+ /* try to activate hardware acceleration, if any */
+ if (!led_cdev-blink_set ||
+ led_cdev-blink_set(led_cdev,
+ timer_data-delay_on, timer_data-delay_off)) {
+ /* no hardware acceleration, blink via timer */
+ mod_timer(timer_data-timer, jiffies + 1);
+ }
+ }
ret = count;
}
@@ -108,8 +121,21 @@ static ssize_t led_delay_off_store(struc
count++;
if (count == size) {
- timer_data-delay_off = state;
- mod_timer(timer_data-timer, jiffies + 1);
+ if (timer_data-delay_off != state) {
+ /* the new value differs from the previous */
+ timer_data-delay_off = state;
+
+ /* deactivate previous settings */
+ del_timer_sync(timer_data-timer);
+
+ /* try to activate hardware acceleration, if any */
+ if (!led_cdev-blink_set ||
+ led_cdev-blink_set(led_cdev,
+ timer_data-delay_on, timer_data-delay_off)) {
+ /* no hardware acceleration, blink via timer */
+ mod_timer(timer_data-timer, jiffies + 1);
+ }
+ }
ret = count;
}
diff -uprN linux-2.6.22.orig/include/linux/leds.h
linux-2.6.22/include/linux/leds.h
--- linux-2.6.22.orig/include/linux/leds.h 2007-07-09 01:32:17.0
+0200
+++ linux-2.6.22/include/linux/leds.h 2007-07-17 10:52:18.0 +0200
@@ -38,6 +38,11 @@ struct led_classdev {
void(*brightness_set)(struct led_classdev *led_cdev,
enum led_brightness brightness);
+ /* Activate hardware accelerated blink */
+ int (*blink_set)(struct led_classdev *led_cdev,
+int delay_on, int delay_off);
+
+
struct class_device *class_dev;
struct list_head node; /* LED Device list */
char*default_trigger; /* Trigger to use */
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at
Re: [PATCH 3/3] leds-clevo-mail: driver for Clevo mail LED
From: Márton Németh [EMAIL PROTECTED]
The driver supports the mail LED commonly found on different Clevo notebooks.
The driver access the LED through the i8042 hardware and implements the support
for
hardware accelerated blink function.
Signed-off-by: Márton Németh [EMAIL PROTECTED]
---
diff -uprN linux-2.6.22.orig/drivers/leds/Kconfig
linux-2.6.22/drivers/leds/Kconfig
--- linux-2.6.22.orig/drivers/leds/Kconfig 2007-07-09 01:32:17.0
+0200
+++ linux-2.6.22/drivers/leds/Kconfig 2007-07-17 10:52:43.0 +0200
@@ -95,6 +95,26 @@ config LEDS_COBALT
help
This option enables support for the front LED on Cobalt Server
+config LEDS_CLEVO_MAIL
+ tristate Mail LED on Clevo notebook (EXPERIMENTAL)
+ depends on LEDS_CLASS X86 SERIO_I8042 DMI EXPERIMENTAL
+ help
+ This driver makes the mail LED accessible from userspace
+ programs through the leds subsystem. This LED can blink at
+ about 0.5Hz and 1Hz.
+
+ This module can drive the mail LED for the following notebooks:
+
+ Clevo D410J
+ Clevo D410V
+ Clevo D400V/D470V (not tested, but might work)
+ Clevo M540N
+ Clevo M5x0N (not tested, but might work)
+ Positivo Mobile (Clevo M5x0V)
+
+ To compile this driver as a module, choose M here: the
+ module will be called leds-clevo-mail.
+
comment LED Triggers
config LEDS_TRIGGERS
diff -uprN linux-2.6.22.orig/drivers/leds/leds-clevo-mail.c
linux-2.6.22/drivers/leds/leds-clevo-mail.c
--- linux-2.6.22.orig/drivers/leds/leds-clevo-mail.c1970-01-01
01:00:00.0 +0100
+++ linux-2.6.22/drivers/leds/leds-clevo-mail.c 2007-07-17 17:53:34.0
+0200
@@ -0,0 +1,226 @@
+
+#include linux/module.h
+
+#include linux/platform_device.h
+#include linux/err.h
+#include linux/leds.h
+
+#include linux/io.h
+#include linux/dmi.h
+
+#include linux/i8042.h
+
+
+#define TRUE 1
+#define FALSE 0
+
+#define HANDLED0
+
+#define CLEVO_MAIL_LED_OFF 0x0084
+#define CLEVO_MAIL_LED_BLINK_1HZ 0x008A
+#define CLEVO_MAIL_LED_BLINK_0_5HZ 0x0083
+
+#define MODULE_FNAME leds-clevo-mail.c
+#define DRVNAMEclevo-mail-led
+#define NO_RESOURCES NULL
+
+MODULE_AUTHOR(Márton Németh [EMAIL PROTECTED]);
+MODULE_DESCRIPTION(Clevo mail LED driver);
+MODULE_LICENSE(GPL);
+
+static unsigned int __initdata nodetect;
+module_param_named(nodetect, nodetect, bool, 0);
+MODULE_PARM_DESC(nodetect, Skip DMI hardware detection);
+
+
+static struct platform_device *pdev;
+
+
+static int __init clevo_mail_led_dmi_callback(struct dmi_system_id *id)
+{
+ printk(KERN_INFO MODULE_FNAME : '%s' found\n, id-ident);
+ return 1;
+}
+
+/**
+ * struct mail_led_whitelist - List of known good models
+ *
+ * Contains the known good models this driver is compatible with.
+ * When adding a new model try to be as strict as possible. This
+ * makes it possible to keep the false positives (the model is
+ * detected as working, but in reality it is not) as low as
+ * possible.
+ */
+static struct dmi_system_id __initdata mail_led_whitelist[] = {
+ {
+ .callback = clevo_mail_led_dmi_callback,
+ .ident = Clevo D410J,
+ .matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, VIA),
+ DMI_MATCH(DMI_PRODUCT_NAME, K8N800),
+ DMI_MATCH(DMI_PRODUCT_VERSION, VT8204B)
+ }
+ },
+ {
+ .callback = clevo_mail_led_dmi_callback,
+ .ident = Clevo M5x0N,
+ .matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, CLEVO Co.),
+ DMI_MATCH(DMI_PRODUCT_NAME, M5x0N)
+ }
+ },
+ {
+ .callback = clevo_mail_led_dmi_callback,
+ .ident = Positivo Mobile,
+ .matches = {
+ DMI_MATCH(DMI_BOARD_VENDOR, CLEVO Co. ),
+ DMI_MATCH(DMI_BOARD_NAME, M5X0V ),
+ DMI_MATCH(DMI_PRODUCT_NAME, Positivo Mobile),
+ DMI_MATCH(DMI_PRODUCT_VERSION, VT6198)
+ }
+ },
+ {
+ .callback = clevo_mail_led_dmi_callback,
+ .ident = Clevo D410V,
+ .matches = {
+ DMI_MATCH(DMI_BOARD_VENDOR, Clevo, Co.),
+ DMI_MATCH(DMI_BOARD_NAME, D400V/D470V),
+ DMI_MATCH(DMI_BOARD_VERSION, SS78B),
+ DMI_MATCH(DMI_PRODUCT_VERSION, Rev. A1)
+ }
+ },
+ { }
+};
+
+
+static void clevo_mail_led_set(struct led_classdev *led_cdev,
+ enum led_brightness value)
+{
+ if (value == LED_OFF)
+ i8042_command(NULL, CLEVO_MAIL_LED_OFF);
+ else if
[PATCH] platform: small typo in doc
From: Márton Németh <[EMAIL PROTECTED]> Typo: iwithout -> without. Signed-off-by: Márton Németh <[EMAIL PROTECTED]> --- --- linux-2.6.21-rc4.orig/drivers/base/platform.c 2007-03-16 01:20:01.0 +0100 +++ linux-2.6.21-rc4/drivers/base/platform.c2007-03-19 08:08:33.0 +0100 @@ -347,7 +347,7 @@ EXPORT_SYMBOL_GPL(platform_device_unregi * This function creates a simple platform device that requires minimal * resource and memory management. Canned release function freeing * memory allocated for the device allows drivers using such devices - * to be unloaded iwithout waiting for the last reference to the device + * to be unloaded without waiting for the last reference to the device * to be dropped. */ struct platform_device *platform_device_register_simple(char *name, unsigned int id, - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] platform: small typo in doc
From: Márton Németh [EMAIL PROTECTED] Typo: iwithout - without. Signed-off-by: Márton Németh [EMAIL PROTECTED] --- --- linux-2.6.21-rc4.orig/drivers/base/platform.c 2007-03-16 01:20:01.0 +0100 +++ linux-2.6.21-rc4/drivers/base/platform.c2007-03-19 08:08:33.0 +0100 @@ -347,7 +347,7 @@ EXPORT_SYMBOL_GPL(platform_device_unregi * This function creates a simple platform device that requires minimal * resource and memory management. Canned release function freeing * memory allocated for the device allows drivers using such devices - * to be unloaded iwithout waiting for the last reference to the device + * to be unloaded without waiting for the last reference to the device * to be dropped. */ struct platform_device *platform_device_register_simple(char *name, unsigned int id, - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] input: extend EV_LED
On Fri, 16 Feb 2007, Henrique de Moraes Holschuh wrote: > On Thu, 15 Feb 2007, Richard Purdie wrote: > > This has been discussed in several places several times. The problem > > with hardware accelerated flashing is that you're are often limited to > > certain constraints (this case being no exception) and indicating what > > these are to userspace in a generic fashion is difficult. > > The hability to blinking at one rate is *very* common on laptops. Blinking > at a few discrete rates is also common enough. They should be supported in > a generic way. > [...] > Here's a suggestion for a simple, non-overengineered interface: a "blink" > attribute (on/off) for leds which can hardware-blink. Only one blink > frequency is common enough that this attribute by itself is very useful > (e.g. it is all a ThinkPad and most WiFi/network card leds need). > > For hardware-blink leds with various frequencies, there is the typical way > to provide such things: give us a RO blink_available_frequencies attribute > which says which discrete frequencies are allowed (space separated), and a > RW blink_frequency attribute to set the frequency. If instead of > blink_available_frequencies, the driver provides RO blink_frequency_min and > _max attributes, then it means it can blink on that range of freqs. > > That is simple enough to implement and use, and generic enough. You just > need to set in stone if you want the freq in Hz, or a submultiple. You can > even implement an optional "blink" software emulation that drivers can hook > into for systems where the driver *knows* that led access is fast, but there > is no hardware blinking emulation. > A blinking led is basically a PWM (Pulse Width Modulation) signal. A PWM signal has three different attribute. The first one is the amplitude, this attribute is already provided by the led subsystem as "brightness". There are two more attributes, which are the frequency [Hz] and the duty cycle [%], or the on-time [ms] and off-time [ms]. The frequency [Hz] and duty cycle [%] parameters has the problem, that if we are limited to integers, it is not possible to express slower blinks than 1Hz. We could also use [mHz] (milli-Hertz), but it is not very common unit. The on-time [ms] and off-time [ms] seems to be easier to handle (and this is also easier to simulate from software if ever needed). An RO attribute could be introduced: 'pwm_available', which can contain parameter pairs separated by space, and the new parameter pair is in new line. An RW attribute 'pwm' could accept a parameter pair separated by space. A range could be also given in 'pwm_available', like this: '500-1000 500-1000'. This has the limitation that if there is a hardware which can blink a LED in differet freqencies, but only with fixed 50% duty cycle, the on-time off-time pair cannot express this range easily. My real-world example would be my Clevo D4J (D410J) notebook's mail led. It has three known state: off, PWM at 1Hz (50%), PWM at 0.5Hz (50%). In case the on-time [ms] off-time [ms] parameter pairs are used: $ cat pwm_available 500 500 1000 1000 What is your opinion? Is there more real-world hardware accelerated blinking LED parameter examples? NMarci __ Kedvező tandíjak, különleges kedvezmények és magas szintű szolgáltatások. Ez az Educomm online nyelviskola és az egyedülálló EDUCATOR. Kattints ide! http://ad.adverticum.net/b/cl,1,6022,131839,203066/click.prm - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] input: extend EV_LED
On Fri, 16 Feb 2007, Henrique de Moraes Holschuh wrote: On Thu, 15 Feb 2007, Richard Purdie wrote: This has been discussed in several places several times. The problem with hardware accelerated flashing is that you're are often limited to certain constraints (this case being no exception) and indicating what these are to userspace in a generic fashion is difficult. The hability to blinking at one rate is *very* common on laptops. Blinking at a few discrete rates is also common enough. They should be supported in a generic way. [...] Here's a suggestion for a simple, non-overengineered interface: a blink attribute (on/off) for leds which can hardware-blink. Only one blink frequency is common enough that this attribute by itself is very useful (e.g. it is all a ThinkPad and most WiFi/network card leds need). For hardware-blink leds with various frequencies, there is the typical way to provide such things: give us a RO blink_available_frequencies attribute which says which discrete frequencies are allowed (space separated), and a RW blink_frequency attribute to set the frequency. If instead of blink_available_frequencies, the driver provides RO blink_frequency_min and _max attributes, then it means it can blink on that range of freqs. That is simple enough to implement and use, and generic enough. You just need to set in stone if you want the freq in Hz, or a submultiple. You can even implement an optional blink software emulation that drivers can hook into for systems where the driver *knows* that led access is fast, but there is no hardware blinking emulation. A blinking led is basically a PWM (Pulse Width Modulation) signal. A PWM signal has three different attribute. The first one is the amplitude, this attribute is already provided by the led subsystem as brightness. There are two more attributes, which are the frequency [Hz] and the duty cycle [%], or the on-time [ms] and off-time [ms]. The frequency [Hz] and duty cycle [%] parameters has the problem, that if we are limited to integers, it is not possible to express slower blinks than 1Hz. We could also use [mHz] (milli-Hertz), but it is not very common unit. The on-time [ms] and off-time [ms] seems to be easier to handle (and this is also easier to simulate from software if ever needed). An RO attribute could be introduced: 'pwm_available', which can contain parameter pairs separated by space, and the new parameter pair is in new line. An RW attribute 'pwm' could accept a parameter pair separated by space. A range could be also given in 'pwm_available', like this: '500-1000 500-1000'. This has the limitation that if there is a hardware which can blink a LED in differet freqencies, but only with fixed 50% duty cycle, the on-time off-time pair cannot express this range easily. My real-world example would be my Clevo D4J (D410J) notebook's mail led. It has three known state: off, PWM at 1Hz (50%), PWM at 0.5Hz (50%). In case the on-time [ms] off-time [ms] parameter pairs are used: $ cat pwm_available 500 500 1000 1000 What is your opinion? Is there more real-world hardware accelerated blinking LED parameter examples? NMarci __ Kedvező tandíjak, különleges kedvezmények és magas szintű szolgáltatások. Ez az Educomm online nyelviskola és az egyedülálló EDUCATOR. Kattints ide! http://ad.adverticum.net/b/cl,1,6022,131839,203066/click.prm - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] input: extend EV_LED
Pavel Machek <[EMAIL PROTECTED]> wrote: > Hi! > > > >I do not know the LED subsystem in detail, but I do not > > >know > > >any possibility to access the i8042 from different > > >subsystem > > >than the input subsystem. > > > > > >What do you think and recommend? > > > > I think you need to use leds framework for what you are > > trying to do. > > I'm actually not sure if led framework can do that. It was designed > for leds on gpios, and handles blinking itself. > > But he could export two leds :-). Hi, what do you mean about two leds? The first one would be off/0.5Hz and the other off/1Hz? I read in linux/Documentation/led-class.txt the following: | Some leds can be programmed to flash in hardware. As this isn't a generic | LED device property, this should be exported as a device specific sysfs | attribute rather than part of the class if this functionality is required. Does it mean that neither the input subsystem nor the led subsystem is designed for hardware acelerated blinking leds? Is there any usual way what attribute a hw accelerated blinking LED_MAIL should export? NMarci __ 10.000 Ft ajándék fotókidolgozás minden Panasonic digitális fényképezőgéphez! FotoMarket Online Fotóáruház http://ad.adverticum.net/b/cl,1,6022,99786,162268/click.prm - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] input: extend EV_LED
Pavel Machek [EMAIL PROTECTED] wrote: Hi! I do not know the LED subsystem in detail, but I do not know any possibility to access the i8042 from different subsystem than the input subsystem. What do you think and recommend? I think you need to use leds framework for what you are trying to do. I'm actually not sure if led framework can do that. It was designed for leds on gpios, and handles blinking itself. But he could export two leds :-). Hi, what do you mean about two leds? The first one would be off/0.5Hz and the other off/1Hz? I read in linux/Documentation/led-class.txt the following: | Some leds can be programmed to flash in hardware. As this isn't a generic | LED device property, this should be exported as a device specific sysfs | attribute rather than part of the class if this functionality is required. Does it mean that neither the input subsystem nor the led subsystem is designed for hardware acelerated blinking leds? Is there any usual way what attribute a hw accelerated blinking LED_MAIL should export? NMarci __ 10.000 Ft ajándék fotókidolgozás minden Panasonic digitális fényképezőgéphez! FotoMarket Online Fotóáruház http://ad.adverticum.net/b/cl,1,6022,99786,162268/click.prm - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] input: extend EV_LED
Dmitry Torokhov <[EMAIL PROTECTED]> wrote: > On 2/14/07, Németh Márton <[EMAIL PROTECTED]> wrote: > > > > > > Dmitry Torokhov <[EMAIL PROTECTED]> írta: > > > > > On 2/11/07, Németh Márton <[EMAIL PROTECTED]> wrote: > > > > > > > > Extend EV_LED handling code so that it can handle not > > > > only two states (on/off) but also others. For example > > > > a LED can blink using hardware acceleration. The code > > > > changed so that it is similar to the code at EV_SND. > > > > > > > > > > Hi, > > > > > > I am not sure we would need this, could you explain what > > are you > > > trying to use input leds for? > > > > > > Generally speaking leds within input subsystem are > > supposed to be very > > > simple on/off objects, mostly for reporting state of input > > devices > > > (keyboards), I am not even sure that LED_MAIL and > > LED_CHARGING make > > > much sense here. For more compex objects(blinking/different > > > colors/different brightness) we have a separate LED subsystem > > > (drivers/leds). > > > > The background is that I own a Clevo notebook model D4J, > > product D410J which has a mail led near to the other LEDs. > > The mail LED in question has three known state: off, blink > > slow (0.5Hz), and blink fast (1Hz). > > > > The mail LED can be programmed through the ports 0x60 and > > 0x64. These ports belog to the i8042 controller, which is > > operated by the input subsystem. To be able to access the > > i8042 controller correctly, I need the spinlock i8042_lock > > held, which is defined as static in > > linux/drivers/input/serio/i8042.c . > > > > What I miss currently from the input subsystem is that the > > EV_LED can only handle on/off state. > > > > I do not know the LED subsystem in detail, but I do not know > > any possibility to access the i8042 from different subsystem > > than the input subsystem. > > > > What do you think and recommend? > > > > I think you need to use leds framework for what you are trying to do. > I could export i8042_command() so you could access keyboard controller > from your driver. I think exporting the i8042_command() would solve my problem, so I could call: retval = i8042_command(NULL, 0x0083); retval = i8042_command(NULL, 0x0084); retval = i8042_command(NULL, 0x008A); as needed. Which header file should the i8042_command() defined in? NMarci __ Könyvszerda a Gabo, Akkord, Talentum, Ciceró Kiadókkal! Több mint 700 féle könyv 30% kedvezménnyel! http://www.bookline.hu/control/news?newsid=397=frekszkar3435 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] input: extend EV_LED
Dmitry Torokhov <[EMAIL PROTECTED]> írta: > On 2/11/07, Németh Márton <[EMAIL PROTECTED]> wrote: > > > > Extend EV_LED handling code so that it can handle not > > only two states (on/off) but also others. For example > > a LED can blink using hardware acceleration. The code > > changed so that it is similar to the code at EV_SND. > > > > Hi, > > I am not sure we would need this, could you explain what are you > trying to use input leds for? > > Generally speaking leds within input subsystem are supposed to be very > simple on/off objects, mostly for reporting state of input devices > (keyboards), I am not even sure that LED_MAIL and LED_CHARGING make > much sense here. For more compex objects(blinking/different > colors/different brightness) we have a separate LED subsystem > (drivers/leds). The background is that I own a Clevo notebook model D4J, product D410J which has a mail led near to the other LEDs. The mail LED in question has three known state: off, blink slow (0.5Hz), and blink fast (1Hz). The mail LED can be programmed through the ports 0x60 and 0x64. These ports belog to the i8042 controller, which is operated by the input subsystem. To be able to access the i8042 controller correctly, I need the spinlock i8042_lock held, which is defined as static in linux/drivers/input/serio/i8042.c . What I miss currently from the input subsystem is that the EV_LED can only handle on/off state. I do not know the LED subsystem in detail, but I do not know any possibility to access the i8042 from different subsystem than the input subsystem. What do you think and recommend? NMarci P.S.: my project home page is located at http://clevo-mailled.sourceforge.net/ __ Könyvszerda a Gabo, Akkord, Talentum, Ciceró Kiadókkal! Több mint 700 féle könyv 30% kedvezménnyel! http://www.bookline.hu/control/news?newsid=397=frekszkar3435 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] input: extend EV_LED
Dmitry Torokhov [EMAIL PROTECTED] írta: On 2/11/07, Németh Márton [EMAIL PROTECTED] wrote: Extend EV_LED handling code so that it can handle not only two states (on/off) but also others. For example a LED can blink using hardware acceleration. The code changed so that it is similar to the code at EV_SND. Hi, I am not sure we would need this, could you explain what are you trying to use input leds for? Generally speaking leds within input subsystem are supposed to be very simple on/off objects, mostly for reporting state of input devices (keyboards), I am not even sure that LED_MAIL and LED_CHARGING make much sense here. For more compex objects(blinking/different colors/different brightness) we have a separate LED subsystem (drivers/leds). The background is that I own a Clevo notebook model D4J, product D410J which has a mail led near to the other LEDs. The mail LED in question has three known state: off, blink slow (0.5Hz), and blink fast (1Hz). The mail LED can be programmed through the ports 0x60 and 0x64. These ports belog to the i8042 controller, which is operated by the input subsystem. To be able to access the i8042 controller correctly, I need the spinlock i8042_lock held, which is defined as static in linux/drivers/input/serio/i8042.c . What I miss currently from the input subsystem is that the EV_LED can only handle on/off state. I do not know the LED subsystem in detail, but I do not know any possibility to access the i8042 from different subsystem than the input subsystem. What do you think and recommend? NMarci P.S.: my project home page is located at http://clevo-mailled.sourceforge.net/ __ Könyvszerda a Gabo, Akkord, Talentum, Ciceró Kiadókkal! Több mint 700 féle könyv 30% kedvezménnyel! http://www.bookline.hu/control/news?newsid=397affiliate=frekszkar3435 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] input: extend EV_LED
Dmitry Torokhov [EMAIL PROTECTED] wrote: On 2/14/07, Németh Márton [EMAIL PROTECTED] wrote: Dmitry Torokhov [EMAIL PROTECTED] írta: On 2/11/07, Németh Márton [EMAIL PROTECTED] wrote: Extend EV_LED handling code so that it can handle not only two states (on/off) but also others. For example a LED can blink using hardware acceleration. The code changed so that it is similar to the code at EV_SND. Hi, I am not sure we would need this, could you explain what are you trying to use input leds for? Generally speaking leds within input subsystem are supposed to be very simple on/off objects, mostly for reporting state of input devices (keyboards), I am not even sure that LED_MAIL and LED_CHARGING make much sense here. For more compex objects(blinking/different colors/different brightness) we have a separate LED subsystem (drivers/leds). The background is that I own a Clevo notebook model D4J, product D410J which has a mail led near to the other LEDs. The mail LED in question has three known state: off, blink slow (0.5Hz), and blink fast (1Hz). The mail LED can be programmed through the ports 0x60 and 0x64. These ports belog to the i8042 controller, which is operated by the input subsystem. To be able to access the i8042 controller correctly, I need the spinlock i8042_lock held, which is defined as static in linux/drivers/input/serio/i8042.c . What I miss currently from the input subsystem is that the EV_LED can only handle on/off state. I do not know the LED subsystem in detail, but I do not know any possibility to access the i8042 from different subsystem than the input subsystem. What do you think and recommend? I think you need to use leds framework for what you are trying to do. I could export i8042_command() so you could access keyboard controller from your driver. I think exporting the i8042_command() would solve my problem, so I could call: retval = i8042_command(NULL, 0x0083); retval = i8042_command(NULL, 0x0084); retval = i8042_command(NULL, 0x008A); as needed. Which header file should the i8042_command() defined in? NMarci __ Könyvszerda a Gabo, Akkord, Talentum, Ciceró Kiadókkal! Több mint 700 féle könyv 30% kedvezménnyel! http://www.bookline.hu/control/news?newsid=397affiliate=frekszkar3435 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] input: extend EV_LED
Extend EV_LED handling code so that it can handle not only two states (on/off) but also others. For example a LED can blink using hardware acceleration. The code changed so that it is similar to the code at EV_SND. Signed-off-by: Márton Németh <[EMAIL PROTECTED]> --- diff -uprN linux-2.6.20.orig/drivers/input/input.c linux/drivers/input/input.c --- linux-2.6.20.orig/drivers/input/input.c 2007-02-04 19:44:54.0 +0100 +++ linux/drivers/input/input.c 2007-02-10 15:20:28.0 +0100 @@ -141,10 +141,11 @@ void input_event(struct input_dev *dev, case EV_LED: - if (code > LED_MAX || !test_bit(code, dev->ledbit) || !!test_bit(code, dev->led) == value) + if (code > LED_MAX || !test_bit(code, dev->ledbit)) return; - change_bit(code, dev->led); + if (!!test_bit(code, dev->led) != !!value) + change_bit(code, dev->led); if (dev->event) dev->event(dev, type, code, value); - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] input: extend EV_LED
Extend EV_LED handling code so that it can handle not only two states (on/off) but also others. For example a LED can blink using hardware acceleration. The code changed so that it is similar to the code at EV_SND. Signed-off-by: Márton Németh [EMAIL PROTECTED] --- diff -uprN linux-2.6.20.orig/drivers/input/input.c linux/drivers/input/input.c --- linux-2.6.20.orig/drivers/input/input.c 2007-02-04 19:44:54.0 +0100 +++ linux/drivers/input/input.c 2007-02-10 15:20:28.0 +0100 @@ -141,10 +141,11 @@ void input_event(struct input_dev *dev, case EV_LED: - if (code LED_MAX || !test_bit(code, dev-ledbit) || !!test_bit(code, dev-led) == value) + if (code LED_MAX || !test_bit(code, dev-ledbit)) return; - change_bit(code, dev-led); + if (!!test_bit(code, dev-led) != !!value) + change_bit(code, dev-led); if (dev-event) dev-event(dev, type, code, value); - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
