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.
