Pin control mappings for DT

[Tony Lindgren]

* Stephen Warren <swarren at nvidia.com> [111201 12:45]:
> Tony Lindgren wrote at Wednesday, November 30, 2011 12:34 PM:
> > * Stephen Warren <swarren at nvidia.com> [111130 09:41]:
> > > Tony Lindgren wrote at Tuesday, November 29, 2011 1:00 PM:
> > > > * Stephen Warren <swarren at nvidia.com> [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