* Stephen Warren <[email protected]> [111201 12:45]: > Tony Lindgren wrote at Wednesday, November 30, 2011 12:34 PM: > > * Stephen Warren <[email protected]> [111130 09:41]: > > > Tony Lindgren wrote at Tuesday, November 29, 2011 1:00 PM: > > > > * Stephen Warren <[email protected]> [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 _______________________________________________ devicetree-discuss mailing list [email protected] https://lists.ozlabs.org/listinfo/devicetree-discuss
