I think for most, or at least a lot of cases sysfs is more than enough for basic GPIO stuffs. It could/would even be fine for PWM/ADC in most/some cases.
Then in other cases when sysfs would not be fast enough, chances are pretty good that you want dedicated external hardware "offloading" the main processor ( Beaglebone ) anyhow. This could come in many different forms. I think Charles is doing something that is useful. But I have also never heard of netlink, which also sounds very interesting and seems like something akin to IPC between user / kernel modes. However, I think both could be useful for different situations. On Mon, Jan 27, 2014 at 9:04 PM, John Syn <[email protected]> wrote: > > On 1/27/14, 6:51 PM, "Charles Steinkuehler" <[email protected]> > wrote: > > >I have made substantial progress on my proposed "universal" device tree > >overlay for the BeagleBone. The general idea is to enable all hardware > >that is expected to be generally useful, and use the pinmux helper to > >allow user-mode control of pin multiplexing (no writing kernel drivers > >or editing device tree files required). > > > >Attached is a first revision of such an overlay for the BeagleBone > >Black. The eMMC, HDMI, and cape I2C EEPROM pins are left as-is, but all > >other P8 and P9 pins are supported. After loading this overlay, all I/O > >pins should be in their default reset state (GPIO input, with pull up or > >pull down enabled depending on the pin). User code can then interact > >with sysfs to configure the hardware as desired. > > > >To change between functions, you echo the desired pinmux function to the > >exported pinmux helper file. For example, to change P8 pin 13 to a PWM > >output, as root: > > > > echo pwm > /sys/devices/ocp.*/P8_13_pinmux.*/state > > > >The supported values vary by pin, and you currently need to extract them > >from the device tree file (documentation and a github repository are in > >progress). In general, all pins support gpio, and most pins support one > >or more of uart, pwm, pruin, pruout, spi, i2c, and can. In addition, > >all pins support a "default" setting, which maps to the same as gpio > >(ie: you can use default or gpio interchangeably). > > > >Changing the GPIO mode is done the same as with any exported pin, you > >access the files in /sys/class/gpio. For example, the following will > >change P8 pin 13 to a GPIO output driving high, assuming you applied my > >kernel patch to enable exporting gpio pins with changeable direction > >(see previous e-mail): > > > > echo high > /sys/class/gpio23/direction > > > >Note that it is quite possible to "shoot yourself in the foot" with > >regards to pin multiplexing, but this also allows things like only using > >the Tx pin of a UART for serial communications, while using the Rx pin > >for a GPIO or other special-purpose function. All without having to > >create a custom device tree overlay, which is even more dangerous than > >having to echo some values to the pinmux helper file! > > > >Please review and comment, especially with regards to enabling the > >hardware drivers. There was a *LOT* of cut-and-paste involved when > >generating the overlay, so I won't be surprised if there's not a typo or > >two lurking around. Also, I am not familiar enough with the SPI, I2C, > >and PWM drivers to know if what I've got (generally extracted from the > >device tree overlays shipped with the BeagleBone kernel source) are > >suitable for generic use. Suggestions or pointers to good examples > >outside the kernel tree would be welcome! > > > >I'm also not completely happy with the naming conventions for the > >various device tree nodes. Please comment if you have suggestions for > >better names. > Hi Charles, > > I¹ve been wondering if device three overlay is the best way to solve this > issue and perhaps this is why it has be rejected in mainline. Why not use > Netlink which is used to setup and configure several I/O frameworks in the > kernel such as route tables, iproute2, etc. Compare net-tools to iproute2. > Why not create a IIO driver for BBB and use Netlink to setup and configure > GPIO modes and also for I/O operations. Sysfs is slow and cumbersome and > does not support streaming and events. Netlink is a two way asynchronous > socket interface between user space and kernel space. With Netlink, it is > possible to have GPIO interrupts, streaming ADC samples, etc. Performance > is way better than sysfs. It would be possible to setup channels for SPI, > I2C, ADC, DAC, PWM, etc. The user space interface is a simple socket > interface with a simple protocol API and would support any programming > language. I foresee a device driver that would configure GPIO modes and > general I/O operations such as SPI, I2C, CAN, GPIO, ADC, DAC, etc. > > Thoughts? > > Regards, > John > > > >-- > >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/groups/opt_out. > > > -- > 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/groups/opt_out. > -- 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/groups/opt_out.
