Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1759460Ab3GZQFW (ORCPT ); Fri, 26 Jul 2013 12:05:22 -0400 Received: from avon.wwwdotorg.org ([70.85.31.133]:47654 "EHLO avon.wwwdotorg.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1758033Ab3GZQFS (ORCPT ); Fri, 26 Jul 2013 12:05:18 -0400 Message-ID: <51F29E3A.6060202@wwwdotorg.org> Date: Fri, 26 Jul 2013 10:05:14 -0600 From: Stephen Warren User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130510 Thunderbird/17.0.6 MIME-Version: 1.0 To: Christian Ruppert CC: Linus Walleij , Patrice CHOTARD , "linux-kernel@vger.kernel.org" , Grant Likely , Rob Herring , Rob Landley , Sascha Leuenberger , Pierrick Hascoet , devicetree-discuss@lists.ozlabs.org, linux-doc@vger.kernel.org, Alexandre Courbot Subject: Re: [PATCH 2/4] pinmux: Add TB10x pinmux driver References: <20130626115051.GC7095@ab42.lan> <51CB279A.1090404@wwwdotorg.org> <20130705094859.GA27196@ab42.lan> <51D71337.6030409@wwwdotorg.org> <20130708130222.GA6402@ab42.lan> <51DDB5B8.5060909@wwwdotorg.org> <20130716084755.GB10914@ab42.lan> <51E56EF3.5040506@wwwdotorg.org> <20130718160700.GA14482@ab42.lan> <51E847EA.9060302@wwwdotorg.org> <20130726094228.GA3232@ab42.lan> In-Reply-To: <20130726094228.GA3232@ab42.lan> X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 4080 Lines: 94 On 07/26/2013 03:42 AM, Christian Ruppert wrote: > On Thu, Jul 18, 2013 at 01:54:18PM -0600, Stephen Warren wrote: >> On 07/18/2013 10:07 AM, Christian Ruppert wrote: >> ... >>> Well, perhaps my definition of "inside"/"outside" pins was not quite >>> clear: The pin groups define the set of (kernel internal) pin numbers of >>> "outside" pins which are used by pin controller to map a given >>> interface. Inside pins are not numbered and the inside interfaces are >>> only used to determine which outside pins are part of the same group >>> (namely those for which the pin controller hardware provides a mux >>> connection to the same inside interface): >>> >>> 4 >>> 4 /|--/-- SPI >>> PINS[0..3] --/--|| 4 >>> \|--/-- GPIO[0..3] >>> >>> 4 >>> PINS[4..7] -----/------ GPIO[4..7] >>> >>> 2 >>> 2 /|--/-- I2C >>> PINS[8..9] --/--|| 2 >>> \|--/-- GPIO[8..9] >>> >>> Pins 0..3 are in the SPI group because on the "inside" they can be muxed >>> to the SPI interface. >>> Pins 8..9 are in the I2C group because on the "inside" they can be muxed >>> to the I2C interface. >>> Pins 0..9 are in the GPIO group because on the "inside" they can be >>> muxed to the GPIO controller. >>> >>> All pin numbers are relative to the "outside", however, or conflict >>> management would not be possible. I hope this is more understandable >>> than my previous explanations. >>> Both muxes are controlled by the same register. In our overly simplistic >>> example this is not strictly necessary but in reality you might have pin >>> conflicts between the different interfaces. >> >> Same register, or same field/bits in that register? >> >> If it's the same field/bits, I would expect to see the following pin groups: >> >> 1) PINS[0..3], PINS[8..9] >> 2) PINS[4..7] >> >> ... since those are the things that are independently muxable. >> Otherwise, I'd expect to see the following groups: >> >> 1) PINS[0..3] >> 2) PINS[4..7] >> 3) PINS[8..9] >> >>> After the discussion we had so far I'm not so sure if extending the >>> pinctrl system with this kind of features is a very good idea. >> >> That makes things simple:-) >> >> One thing I still don't understand; in a previous mail, you'd mentioned >> 3 DT properties for configuring the pinmux; one represented the pin >> group, one represented the mux function that was selected for that pin >> group, and there was a third ("config"?) property. I still don't >> understand that third property. I only see pins/pingroups and mux >> functions in the diagram I quoted above. > > In my proposal, pin groups represent interfaces instead of ports: All > three pin groups are configured through the same bit field in the same > register but they represent _logically_ independent functionalities. Oh, that's a pretty "coupled" HW design! I would suggest having a single pin group for all 10 pins (since that's what HW really has). I imagine with that HW design, there's very little potential for any kind of dynamic pin-muxing, since it would affect multiple unrelated HW modules (I2C, SPI), and hence the co-ordination required for dynamic muxing would make it impractical. As such I would also specify the pinctrl configuration as a "hog" in the pin controller, since each configuration bit affects multiple other devices, so it doesn't make logical sense to try to specify the pinctrl configuration anywhere other than the pin controller. > The three DT properties are: > > 1. interface (which pins are we actually interested in when requesting > this) > 2. port (which bit field/register is used to configure this) > 3. configuration of that port (which mux function(s) in that bit > field/register are possible to make the interface available) -- 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/