From mboxrd@z Thu Jan 1 00:00:00 1970 From: Tony Lindgren Subject: Re: Pin control mappings for DT Date: Thu, 1 Dec 2011 14:04:49 -0800 Message-ID: <20111201220449.GF13928@atomide.com> References: <20111129174255.GQ31337@atomide.com> <74CDBE0F657A3D45AFBB94109FB122FF174FDAFB24@HQMAIL01.nvidia.com> <20111129195937.GO13928@atomide.com> <74CDBE0F657A3D45AFBB94109FB122FF174FDAFE9E@HQMAIL01.nvidia.com> <20111130193410.GW13928@atomide.com> <74CDBE0F657A3D45AFBB94109FB122FF174FDB02DE@HQMAIL01.nvidia.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Content-Disposition: inline In-Reply-To: <74CDBE0F657A3D45AFBB94109FB122FF174FDB02DE-C7FfzLzN0UxDw2glCA4ptUEOCMrvLtNR@public.gmane.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: devicetree-discuss-bounces+gldd-devicetree-discuss=m.gmane.org-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org Sender: devicetree-discuss-bounces+gldd-devicetree-discuss=m.gmane.org-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org To: Stephen Warren Cc: Russell King - ARM Linux , "devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org" List-Id: devicetree@vger.kernel.org * Stephen Warren [111201 12:45]: > Tony Lindgren wrote at Wednesday, November 30, 2011 12:34 PM: > > * Stephen Warren [111130 09:41]: > > > Tony Lindgren wrote at Tuesday, November 29, 2011 1:00 PM: > > > > * Stephen Warren [111129 09:27]: > > > > > > > > I don't think so. The pinmux controller needs to know the available functions. > > > > But the functions selected for each driver are board/machine specific. > > > > > > That's certainly true. > > > > > > However, in my opinion just because the actual usage of the pinmux is > > > board-/machine-specific, that doesn't determine whether the description > > > of that usage has to be stored in the DT node of the devices that are > > > affected by the pinmux, or in some centralized table. > > > > Yes well both should work. I guess as long as the serial driver can > > do pinmux_get(dev, NULL) the driver stays arch independent. > > > > > There are two components to the data: > > > > > > 1) The definition of what the pinmux HW can do. > > > > > > There shouldn't be any combinations here. > > > > But there are.. > > As I was trying to point out, I think what you're talking about as > "combinations" is something totally different to what I was talking > about. > > I was talking about pins combining to create busses, something which can > get pretty exponential within a single SoC. Ah right, yes that's correct. I'm not even considering statically grouping pins because of the infinite number of options :) > I think you're talking about different SoCs having different sets of > pins, groups, functions, etc. > > For a given SoC (die + package option), there is a single table of all > known pins, groups, and functions. No combinations. That's correct. And we already have about 6000 LOC of that for omaps without any grouped pins to create extra permutations. > Now it may well be that you have a family of SoCs that have many > similarities between their sets if pins/groups/functions (or subsets > thereof) and I guess that's why you were talking about combinations? > But, IIRC, that's unrelated to the points I was making. > > > > This data should simply list for each pin what the valid mux options are. > > > (or for each pin group if mux registers control n pins at a time as on > > > Tegra) > > > > ..and we already have four completely different function tables and five > > subsets/incremental changes for the same IP block for omap2/3/4. > > Well, sure, you have much different HW. > > But the pinctrl core should only receive the 1 specific complete set of > pins/groups/functions for the particular SoC that the code is running > on. Yes I completely agree. > Anything to do with constructing that list or representing it in device > tree is something implementation detail for the individual pinctrl driver. > > If you have the tables in code, you can presumably merge them together > while implementing the pinctrl subsystem's callbacks. If you have the > tables in device tree, you can presumably merge them together when running > dtc, using /include/ statements from the SoC *.dtsi file. That's correct too. The real question is where do we place the data that is just growing all the time.. Regards, Tony