Bringing Android closer to the mainline

Posted Dec 20, 2011 22:28 UTC (Tue) by neilbrown (subscriber, #359)
Parent article: Bringing Android closer to the mainline

"timed gpio" could easily be implemented with "leds" today.

Use the "leds-gpio" driver to provide a "/sys/class/leds" interface to the gpio, then:

# cd /sys/class/leds/NAME-OF-LED
# echo timer > trigger; echo 1000 > delay_on; echo 1000000000 > delay_off

and the GPIO will be asserted for one second, then de-asserted for approximately one fortnight - which should be long enough for user-space to turn it off properly.

So this seems to be unnecessary duplication.

Bringing Android closer to the mainline

Posted Dec 20, 2011 22:58 UTC (Tue) by alvieboy (guest, #51617) [Link] (4 responses)

Although I understand your point, LED and GPIO differ quite a bit.

First of all, GPIO bitbanging requires often some precise timing, something that is irrelevant to LED and other "human display-only" interfaces.

Second, GPIO are usually "tristate", meaning that you can program the pin to be left with high-impedance. LED class not only does not implement that, it does not have to implement that at all.

IMHO, GPIO-style pins, on specialized hardware, should have an interface very much like USB has right now. Meaning, to be able to be bound to kernel devices, and to be claimed by userspace, with somehow same rules like those on current USB stack.

Alvie

Bringing Android closer to the mainline

Posted Dec 20, 2011 23:18 UTC (Tue) by neilbrown (subscriber, #359) [Link] (2 responses)

Certainly GPIOs can do a lot more than LEDs can do, though many actually do a lot less :-)

In the example use-case of turning a vibrator off, it seems very similar to a LED. There may be other use-cases that I'm not aware of of course. If you wanted a timed GPIO for bit-banging you wouldn't use a LED device. Maybe an SPI device or an I2C device?

GPIO pins can be exported to user-space, and then can be controlled by setting the direction, the value, and the edges on which an interrupt it triggered. The interrupt can be sensed by using 'poll' on the relevant sysfs file.

gpiolib provides "gpio_export" which will export a given gpio, and it appears as e.g. /sys/class/gpio/gpio47/{value,direction,....}

I agree that it can be very useful to export raw gpios to user-space, but where possible I think it is best to hide them behind some higher-level abstraction, such as LED.

Bringing Android closer to the mainline

Posted Dec 21, 2011 7:25 UTC (Wed) by hrw (subscriber, #44826) [Link] (1 responses)

Some Linux phones exports vibrator using LED class. IIRC this was a case with Nokia N900.

Bringing Android closer to the mainline

Posted Jan 6, 2012 19:14 UTC (Fri) by navaati (guest, #82114) [Link]

The Neo Freerunner does the same way

Bringing Android closer to the mainline

Posted Dec 21, 2011 6:12 UTC (Wed) by neilbrown (subscriber, #359) [Link]

BTW I just had a look at the timed_gpio code.

There are really two things here: a "timed_output" class, and a "timed_gpio" driver that creates a "timed_output" device that drives a GPIO.

The "timed_output" class provides a single device attribute: "enable". It leaves the interpretation of that value to the driver.

Writing "0" de-asserts the gpio. Writing a number of milliseconds causes the gpio to be asserted for that long, then de-asserted.
Reading returns the remaining time before the output will be deasserted.

There are two things that timed_gpio provides that leds-gpio currently doesn't.

1/ high precision. leds-gpio uses jiffies-based timers so probably only to the nearest 4msecs. timed_gpio uses hrtimers, so give 1msec precision.

2/ read back of time remaining.

The only references to timed_gpio I can find on the web are for using it for the vibrator just like the above article says. I doubt that needs millisecond precision. If it did, a leds-hrgpio driver could be written (or an extension to the current driver) rather than a new class.

If the time-remaining was really important, then a 'one-shot' led-trigger could be written (rather than a whole new class) which reported the time remaining. That might be useful for other leds as well.

"full exploitation" is a good thing!

/sys/class

Posted Dec 21, 2011 1:17 UTC (Wed) by scottt (guest, #5028) [Link] (2 responses)

I thought /sys/class was going away soon, no?

/sys/class

Posted Dec 21, 2011 1:26 UTC (Wed) by neilbrown (subscriber, #359) [Link]

I think that is scheduled for right after we fix the last kernel bug.

/sys/class

Posted Dec 21, 2011 7:30 UTC (Wed) by ebiederm (subscriber, #35028) [Link]

Internally classes in sysfs may go away but at this point the /sys/class directory is part of the ABI and so /sys/class can not be practically removed.