Re: [RFC] Device Tree Overlays Proposal (Was Re: capebus moving omap_devices to mach-omap2)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



* Grant Likely <grant.likely@xxxxxxxxxxxx> [121106 03:16]:
> On Tue, Nov 6, 2012 at 10:30 AM, Pantelis Antoniou
> <panto@xxxxxxxxxxxxxxxxxxxxxxx> 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
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [Linux Arm (vger)]     [ARM Kernel]     [ARM MSM]     [Linux Tegra]     [Linux WPAN Networking]     [Linux Wireless Networking]     [Maemo Users]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite Trails]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux