Re: [PATCH] input: extend EV_LED

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.

I want to convert ibm-acpi to the led interface, but if it means I have to
provide custom attributes on top of the led class, it sort of defeats most
of the purpose of using the led class to begin with -- it will NOT be
generic.

If I have to provide those attributes elsewhere in the sysfs tree other than
somewhere in the led class, then it defeats the purpose of using the led
class completely: I will just scrap the idea. I am not going to remove
functionality. And I am not going to emulate in software something the
hardware can do, especially when that means bothering the EC with a slow
ACPI-subsystem-gated LPC bus IO port access for no good reason.

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.

One way I've come up with is adds capability to the class to have LED
specific triggers and you can then expose these hardware capabilities as
an extra trigger specific to the LED.

How would that look like? It doesn't sound too bad. Could you give us an
example of what the tree would look like, and what the attributes would be
(and do)?

Another proposal more specific to this use case was to have some
information behind the scenes which the software timer based trigger
could use to turn on the "hardware acceleration" if present and capable
of the requested mode. This might just need a function pointer in the
core so could be quite neat.

This looks like a severely overengineered way to deal with the problem at
first glance.

--
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie." -- The Silicon Valley Tarot
Henrique Holschuh
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Relevant Pages

  • [PATCH] LED driver for Intel NAS SS4200 series (v3)
    ... This code is based on a driver that came in the "Open-source ... That code used an ioctlcall to operate the LEDs. ... I ripped out all of the hardware monitor support from nasgpio.c ... * Define register offsets within the ICH7 register block. ...
    (Linux-Kernel)
  • Re: [PATCH] input: extend EV_LED
    ... hardware can do, especially when that means bothering the EC with a slow ... (e.g. it is all a ThinkPad and most WiFi/network card leds need). ... the LED so what we need is an LED blink trigger. ... could use to turn on the "hardware acceleration" if present and capable ...
    (Linux-Kernel)
  • Re: is any one sniffing comports on win2k or XP?
    ... It requires no hardware and its free. ... >serial LED device (device with bi-color leds for each pin). ... >>bajillions of DOS apps that claim to spy on a com port but I have had no ... Every app I try to use results in a com port in use ...
    (Vuln-Dev)
  • Re: Network Problem
    ... > the mii interface in the NIC driver. ... > doesn't mean that the mii hardware isn't doing it's job. ... > Does your NIC have both link and speed leds? ...
    (Fedora)
  • Re: [PATCH] input: extend EV_LED
    ... designed for leds on gpios, ... Does it mean that neither the input subsystem nor the led ... subsystem is designed for hardware acelerated blinking leds? ... could use to turn on the "hardware acceleration" if present and capable ...
    (Linux-Kernel)