From: William Hermans <[email protected]> Reply-To: <[email protected]> Date: Monday, January 27, 2014 at 8:39 PM To: <[email protected]> Subject: Re: [beagleboard] RFC: Universal Device Tree
> 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. One more point, Bonescript and Nodejs could benefit from the asynchronous I/O provided by NetLink. A decent library written on top of libnl could implement Arduino like functionality for all available BBB I/O. > > > 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] >>> <mailto:beagleboard%[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] >> <mailto:beagleboard%[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.
