lkml.org 
[lkml]   [2012]   [Nov]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [RFC] Device Tree Overlays Proposal (Was Re: capebus moving omap_devices to mach-omap2)
* Grant Likely <grant.likely@secretlab.ca> [121106 03:16]:
> On Tue, Nov 6, 2012 at 10:30 AM, Pantelis Antoniou
> <panto@antoniou-consulting.com> wrote:
> >
> > Another can of worms is the pinctrl nodes.
>
> Yes... new pinctrl data would need to trigger adding new data to
> pinctrl. I don't know if the pinctrl api supports that.

The actual pins stay the same, just their configuration
changes. AFAIK all that is already supported using the
pinctrl framework.

For example, considering hotplugging capes on the beaglebone:

1. You need to map all the sensible modes for the pins exposed
to the capes in the board specific .dts file. This will
add roughly 4 x nr_capbus_pins named modes in the .dts file
so not too bad.

2. Claim all the capebus pins during the capbus driver probe
and set them to some safe mode.

3. Try to detect the connected cape(s) over i2c.

4. Use pinctr_select_state to set the desired modes for
the pins used by the cape(s).

5. Enable capebus regulators and clocks etc.

6. Load the driver modules for whatever omap internal
devices the cape supports.

You could also claim the pin for the omap internal
devices instead of claiming them in the capebus, but then
things can get messy with binding and unbinding the
drivers. So just claiming all the pins in the capebus
probably keeps things simpler.

Regards,

Tony


\
 
 \ /
  Last update: 2012-11-06 20:21    [W:0.382 / U:0.056 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site