Hi Charles,

Sorry if this is an incredibly dense question. But which kernel version is
this for?


On Mon, Jan 27, 2014 at 7: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.
>
> --
> 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.

Reply via email to