On 11/06/2012 12:41 PM, Pantelis Antoniou wrote: > Hi Russ, > > On Nov 6, 2012, at 8:29 PM, Russ Dill wrote: > >> On Tue, Nov 6, 2012 at 10:35 AM, Tony Lindgren <t...@atomide.com> wrote: >>> * Grant Likely <grant.lik...@secretlab.ca> [121106 03:16]: >>>> On Tue, Nov 6, 2012 at 10:30 AM, Pantelis Antoniou >>>> <pa...@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: ... >> That assumes that for a particular external bus, certain pins aren't >> already shared with functions already on the board, for instance if an >> I²C bus brought out to the external bus already has a chip connected >> to it. > > This is our case on the bone. We don't enable the peripheral until > a cape that references it is enabled. > > I don't think that very big changes are going to be needed TBH. ... > Ideally if we could do this in the cape definition: > > cape_pinmux { > parent = <&am3358_pinmux>;
I think the cape overlay would simply add nodes to the existing pin controller node, so I'd presume you would replace the two lines immediately above with: am3358_pinmux: pinmux { > > bone_dvi_cape_led_pins: pinmux_bone_dvi_cape_led_pins { > pinctrl-single,pins = < > 0x48 0x07 /* gpmc_a2.gpio1_18, OUTPUT | > MODE7 */ > 0x4c 0x07 /* gpmc_a3.gpio1_19, OUTPUT | > MODE7 */ > >; > }; > > pinctrl-0 = <&bone_geiger_cape_pins>; -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html