Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752192Ab2KFSfs (ORCPT ); Tue, 6 Nov 2012 13:35:48 -0500 Received: from mho-03-ewr.mailhop.org ([204.13.248.66]:33451 "EHLO mho-01-ewr.mailhop.org" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1751061Ab2KFSfq (ORCPT ); Tue, 6 Nov 2012 13:35:46 -0500 X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 98.234.237.12 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1+bATrYMFmEUAsc/QAo4I2a Date: Tue, 6 Nov 2012 10:35:32 -0800 From: Tony Lindgren To: Grant Likely Cc: Pantelis Antoniou , Rob Herring , Deepak Saxena , Benjamin Herrenschmidt , Scott Wood , Russ Dill , Felipe Balbi , Benoit Cousson , linux-kernel , Koen Kooi , Matt Porter , linux-omap@vger.kernel.org, Kevin Hilman , Paul Walmsley , devicetree-discuss@lists.ozlabs.org Subject: Re: [RFC] Device Tree Overlays Proposal (Was Re: capebus moving omap_devices to mach-omap2) Message-ID: <20121106183531.GH6801@atomide.com> References: <02FF5400-9F97-4B8A-AEF0-267B01C8099F@antoniou-consulting.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1607 Lines: 47 * Grant Likely [121106 03:16]: > On Tue, Nov 6, 2012 at 10:30 AM, Pantelis Antoniou > 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-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/