Pin control mappings for DT

[Stephen Warren]

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.

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.

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.

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.

-- 
nvpublic