On 9/16/2014 2:23 PM, Jason Kridner wrote: > On Tue, Sep 16, 2014 at 11:55 AM, Charles Steinkuehler > <[email protected]> wrote:
>> What I'm working on is adding a setting to the pinmux helper, so rather >> than trying to have the LCD cape "own" the pinmux setting, it would just >> let the pinmux helper know it should start in a specific mode. > > In general, I prefer leaving the pinmux helper in control, but I think > *some* of the lines might be *ok* to put under control of the LCD, no? As Robert showed, the pinmux helper can easily be disabled for particular pins, allowing them to be directly "owned" by the driver (and making them difficult or impossible to change w/o DT overlays or changesets). If you want to leave pinmux in control, one needs faith in the end users and some "enlightenment" of the config-pin utility is in order to help keep folks from shooting themselves in the foot. Any pins not needing to be modified by user-space (ie: signals that don't go to the P8/P9 headers) can probably remain under control of the appropriate driver w/o issue. I've got a modified version of the pinmux-helper, device-tree, and config-pin that allow modifying the i2c2 lines after boot. Give me a bit to get everything organized and pushed to github (three patch-sets to push...ugh!) and I'll post an RFC. -- 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.
