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. One sample per second, but nothing faster than that. > > 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. You have a 1GHz processor with very capable I/O; why would you add more hardware when there is a very simple software solution? > > 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. I’m proposing a solution that solves several problems not addressed by Device Tree Overlays. For example, sysfs is simplex and user space apps must poll the sysfs interface for changes on the kernel side. IOCTL has the same problem. I know that Charles is also working with Xenomai and this solution that could possible provide a two way interface to Xenomai drivers. Here is an article that helps explain the benefits of Netlink over IOCTL and by extension sysfs. http://www.linuxjournal.com/article/7356 Regards, John > > > 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.
