[PATCH 1/4 v5] drivers: create a pin control subsystem v5

[Stephen Warren]

Linus Walleij wrote at Thursday, September 01, 2011 3:13 AM:
...
> I will need Arnds or similars advice on it so we don't
> grow a lib/mysql into the kernel with this kind of
> schemes and get slammed for overcomplicating
> things when trying to merge the beast.

I /think/ the whole multi-row thing is just doing this:

for each row of table:
    if it matches search terms:
        Activate the specified function on the group

Whereas handling just one entry is almost the same:

for each row of table:
    if it matches search terms:
        Activate the specified function on the group
        break

Of course, in the former case, the error-handling also has to iterate
over all the already-processed rows and unreserved/unprogram the HW too,
but that should be a pretty simple loop too.

And replying to your immediately earlier email:

...
> > Hence, a given board would only need rows 0, 1+2, or
> > 3+4+5 from the mapping table shown above, assuming the width of the MMC
> > port didn't vary at run-time.
> 
> OK we're on the same page I think. If I fix this, then
> you're happy?

I haven't read patchset 6 yet, but from the descriptions in your email
and the patch 0 changelog, it certainly sounds like we're on very
similar pages now.

> > Some pin parameters might be defined per:
> >
> > * Pin (probably most systems other than Tegra)
> > * Pin group (for pull-up/down, tristate on Tegra)
> > * Drive group (another set of groups of pins on Tegra that arbitrarily
> > overlap/intersect with the mux pin groups (for drive-strength settings
> > on Tegra).
> 
> Since these things are unrelated to muxing I prefer that
> we add that as a separate set of ops in struct pinctrl_device.
> 
> The driver can very well reuse the same groups internally,
> nothing prevents that.
> 
> I am not intending to address the issue of pin bias,
> driver strength, load capacitance, schmitt-trigger input
> etc etc etc in this first iteration of the pin control subsystem,
> what I want is to get the infrastructure and pin muxing
> into the kernel then extend it with other pin control.
> 
> I'm trying to avoid excess upfront design.
> 
> Do you think these features are needed from day 1
> to be of any use for Tegra?

I think having just muxing support would work fine for a first pass.

Looking forward a little, I expect that different SoCs have such a
different set of biasing/driver-strength/... options that actually having
some formalized semantic representation of what those options are doesn't
make sense; all we need is a standard API to set the values for a given
pin or pingroup; just like the config API you already had, but applied
to pingroups rather than explicitly GPIOs, and where the driver supplies
the names for the settings and interprets what the values mean for a
given setting. I imagine having the config API in the first pass wouldn't
be contentious, provided it applied to pingroups.

Just possibly, I could imagine needing config entries in the mapping table,
so when switching between mapping entries at run-time you could both program
muxing and other configuration. However, that's definitely not a first-pass
thing, as you say. And I'm just guessing if it'll be needed anyway.

> > Or, in more normalized fashion, with multiple rows per pingroup, each
> > entry containing:
> > * Name of pingroup
> > * One pin with in the pingroup
> 
> I don't get this "one pin within the the pingroup"
> what if the same pin is part of multiple groups?

It was just a data-representation thing. You could either have:

struct {
    char * pingroup;
    int npins;
    int * pins;
};

Where one row represents everything about a pingroup, or:

struct {
    char * pingroup;
    int pin;
};

Where you'd need a row for each pin in a pingroup.

Go with whatever you find is easiest; I was just thinking databases for
a while!

-- 
nvpublic