Hi Charles, Well, one can always mmap() /dev/mem/ @ 0x4804C000, but I was kind of hoping to avoid that. When all is said and done, for an example to learn by, and share with others. I think using uio_pruss, and some sort of shared memory "scheme" would be "better" than using /dev/mem/. As I think that perhaps exposing the whole gpio1 bank to userspace, just to get at the USR LEDs, is probably not the greatest idea. At least with uio_pruss, I can write PRU code that just reads from the shared memory, and twiddle the USR LEDs based on a small ( nibble ) bit field.
It's pretty awesome how flexible uio_pruss really can be, when you think about it a bit. On Fri, Nov 20, 2015 at 6:02 AM, Charles Steinkuehler < [email protected]> wrote: > 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. > -- 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.
