On 11/20/2015 2:31 AM, William Hermans wrote: > Ok, so after toying around a bit, I guess my above proposal is / would be a > bad example of how to use uio. In fact, I'm starting to think it is > "impossible" without hacking up a special driver, and changing a few > default files. It's pretty bad, when the light at the end of the tunnel, > seems to point to using uio_pruss . . . which actually makes a whole lot > more sense I suppose.
The LEDs are kind of a special case. When I was working on the universal overlay, I wanted to be able to make the LEDs available at run-time like I do with most of the other pins, but it just doesn't really work out that way. Since the kernel LED driver has to bind to the GPIO, there's no way (that I know of or found digging through the code) to "unbind" the GPIO from the kernel LED driver. The rest of the universal overlay simply uses a pinmux helper to allow switching between different functions (like GPIO, SPI, PWM, etc). It doesn't allow multiple kernel functions (like user GPIO and the kernel LED driver) to bind to the same GPIO pin. This might be possible now with the 4.x kernels and device tree changesets, but I haven't tried. In theory it might work on 3.8 if you made each LED it's own "cape", so you'd unload the LED cape to restore user access to the GPIO pin, but unloading device trees in 3.8 is mostly a handy way to crash the kernel. :-/ -- Charles Steinkuehler [email protected] -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups "BeagleBoard" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
