The kernel GPIO driver actually sort of gives you some accounting like this... to get access to a GPIO, you echo the pin number into /sys/class/gpio/export, and that reserves the pin for GPIO access (using gpio_request() i believe) and creates the sysfs files to interact with it. If anyone else tries to gpio_request() that pin, it fails. When finished with the pin, you can write its number to /sys/class/gpio/unexport, and that releases it.
I'm not sure what other mechanisms can lock a pin within the kernel like that, but I have found that the gpio_leds driver in the kernel holds a lock on the userled pins, preventing you from manipulating them using the sysfs gpio driver. I haven't tried monkeying with the registers directly on the userled gpios while the leds driver is holding them. What Michael and I had discussed was using the sysfs mechanism to request the pins at driver load, and only "claim" the pins that succeed, or fail if a user has asked for pins that we can't claim, or something along those lines. It's not going to stop code from going behind our back and manipulating registers directly, but we just have to assume that we're all playing in the same sandbox. What I'm as-yet unsure of is whether we will have a reliable way to find out whether the onboard peripherals (emmc, hdmi) are driving the pins they're attached to. As for the configuration, I think Andy is right, and we just need to have parameters that can configure the pin direction and pullups at runtime. Ian On May 5, 2013, at 9:23 PM, Jon Elson <[email protected]> wrote: > Steve Stallings wrote: >>> -----Original Message----- >>> From: Jon Elson [mailto:[email protected]] >>> >>> >>> Or, you could do it as 5 fields of 8 characters and the last >>> one 6 chars. >>> That would be a lot more manageable. >>> >>> Jon >>> >>> >> >> Well I got something different from that post. >> >> The size of the string isn't really important. What matters >> is the granularity of control pin by pin, and the recognition >> that some pins will need to be owned by the OS or by processes >> other than the CNC control program. >> > OK, the first part was about a 46-character string. > > I did this in my usual hacker's way with the old Beagle Board, reprogramming > the GPIO pins in the bank I was using, trying to avoid any pins reserved > for functions on the board. When I changed one that I shouldn't have, > the Beagle locked up and I rebooted and left that pin alone in the future. > It ought to be fairly easy to write a program that reads this setup > string in > whatever format, and then adjusts the pin settings while avoiding any > change to "system-reserved" pins. Once this program has all the > reserved pins protected, it should become a general utility that can be > used by all drivers that need it. > > I suppose if you want to get really fancy, one could create a program that > gives access to certain pins to various requesters, and maintains tables > of who has allocated what. It could return with an allocation map of > what you have been granted, and a flag to tell whether you got every > pin you asked for or not. > > Jon > > ------------------------------------------------------------------------------ > Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET > Get 100% visibility into your production application - at no cost. > Code-level diagnostics for performance bottlenecks with <2% overhead > Download for free and get started troubleshooting in minutes. > http://p.sf.net/sfu/appdyn_d2d_ap1 > _______________________________________________ > Emc-developers mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/emc-developers ------------------------------------------------------------------------------ Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET Get 100% visibility into your production application - at no cost. Code-level diagnostics for performance bottlenecks with <2% overhead Download for free and get started troubleshooting in minutes. http://p.sf.net/sfu/appdyn_d2d_ap1 _______________________________________________ Emc-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/emc-developers
