On Tue, Sep 16, 2014 at 4:53 PM, Charles Steinkuehler <[email protected]> wrote: > Request For Comment > =================== > > In order to make the cape-universal approach to modifying the BeagleBone > I/O setup at runtime via user-land (ie: no kernel driver and no > device-tree overlays or changesets), the bone-pinmux-helper driver needs > to be in control of the pinmux register for each I/O pin. It is not > currently possible, however, to (easily) set the default pinmux mode for > the bone-pinmux-helper. > > Therefore, I have modified the bone-pinmux-helper code to support a > "mode" parameter in the device tree: > > https://github.com/cdsteinkuehler/linux/commit/e0e0f1da3f2df4bc4ee2b27a65ee99734bd3fb77
I did a quick read through that made sense, though I don't know the specific functions. > > ...which allows a device tree fragment to specify the startup default > mode of the pinmux from one of the available choices: > > https://github.com/cdsteinkuehler/dtb-rebuilder/commit/b78226fdf0c420dcadf8a606e4795cefbc8c7428 > > ...and a tweaked the config-pin utility supporting the new options: > > https://github.com/cdsteinkuehler/beaglebone-universal-io/commit/e742ff15f7abbc2cf80141ea49269eb0a2f2a8b3 Approach looks good to me. I know the dropping of the pin assignment in the i2c device tree itself will cause some heartache for some. I don't see where you removed the definition of the i2c pin settings themselves. Will not removing those entries cause headaches by someone assuming they are used or is it comfortable for them to simply be there by reference? I suspect it would only be an issue if a bug was found in the setting and someone missed that the real mode was coming from the helper. > > This will allow any initial hardware pinmux configuration to be > overridden by user-space code at run-time, making it possible to switch > (for instance) the i2c2 cape EEPROM bus to standard GPIO pins as shown > in this example. Woohoo! Hold on to your hats! > > "Takeover" of the i2c2 bus is intended mainly as a proof-of-concept, the > real power of this approach is the ability to do things like enable SPI > or a UART in the boot-time device tree and have the pin muxing correct, > but be able to override the pinmux settings once the system is booted > (perhaps turning an unused RxD line into a useful PWM or similar). This > also makes it possible to modify the pinmux hardware configuration as > soon as sysfs is available (ie: very early in the system boot stage). > Who wants to write the user-mode version of cape-manager?!? It seems to me that the existing kernel module should be extended. Extending config-pin to read cape EEPROMs and have a database of pin settings is fine and I can understanding you wanting to find an owner for that task, but if looking for a real replacement of cape-manager (by that name) then real overlays still need to be understood/supported as you still can't quite do all the experimenting/fpga-ing you'd desire without being able to reconfigure the rest of the device tree at runtime. > > -- > 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/d/optout. -- 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/d/optout.
