Message-ID: <74CDBE0F657A3D45AFBB94109FB122FF178CB81BFD@HQMAIL01.nvidia.com>
Date:	Mon, 23 Jan 2012 14:54:06 -0800
From:	Stephen Warren <swarren@...dia.com>
To:	Tony Lindgren <tony@...mide.com>
CC:	Grant Likely <grant.likely@...retlab.ca>,
	Dong Aisheng-B29396 <B29396@...escale.com>,
	"linus.walleij@...ricsson.com" <linus.walleij@...ricsson.com>,
	"s.hauer@...gutronix.de" <s.hauer@...gutronix.de>,
	"rob.herring@...xeda.com" <rob.herring@...xeda.com>,
	"kernel@...gutronix.de" <kernel@...gutronix.de>,
	"cjb@...top.org" <cjb@...top.org>,
	"Simon Glass (sjg@...omium.org)" <sjg@...omium.org>,
	Dong Aisheng <dongas86@...il.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"linux-arm-kernel@...ts.infradead.org" 
	<linux-arm-kernel@...ts.infradead.org>,
	"devicetree-discuss@...ts.ozlabs.org" 
	<devicetree-discuss@...ts.ozlabs.org>
Subject: RE: Pinmux bindings proposal

Tony Lindgren wrote at Monday, January 23, 2012 1:13 PM:
> * Stephen Warren <swarren@...dia.com> [120120 12:20]:
> > Tony wrote at Lindgren:
> > > * Stephen Warren <swarren@...dia.com> [120118 11:29]:
> > > > Tony Lindgren wrote at Wednesday, January 18, 2012 7:13 AM:
> > >
> > > Assuming this is describing the pins a driver is using, how
> > > about calling it pins?
> >
> > It's not always pins.
> >
> > For a lot of HW it is pins, you're right.
> >
> > For Tegra20 (and IIRC some other HW), the pin mux HW actually muxes
> > groups of pins; one register field sets n (1, 2, 3, ...) pins to that
> > function at once. Hence, the entries are real physical groups.
> 
> OK fair enough, mux instead of pins works fine for me.
> 
> > For some HW that controls the mux per pin, the SoC vendors wish the
> > pinctrl driver to expose what I call "virtual groups" of pins, e.g. all
> > the pins that are typically used together as a single I2C or SD/MMC
> > interface, as a single muxable entity (a group in pinctrl parlance).
> > In this case, the values listed here will be these group IDs
> 
> For the virtual groups, do you also want to specify them separate
> in the .dts files?

/I/ don't want to specify virtual groups at all:-)

It's up to individual pinctrl drivers what groups they define. Equally,
it's up to the drivers whether they define their list of groups as static
data within the driver, or as nodes/properties in the device tree.

Nothing that I put into my binding proposal is in any way related to what
I call virtual groups; the "pin configuration nodes" are simply a listing
of mux or config values for whatever pins or groups the pinctrl driver
happens to expose, whether they're real HW pins/groups or not, and whether
the list they expose came from a static table or not.

> IMHO we should let device tree take care of that as it already
> allows specifying the pins for each device entry. Then the
> dynamically generated group name can be nc->full_name of the
> device.

I don't quite follow that, but I think it's important to allow drivers
flexibility to store their list of pins/groups/functions wherever they
want; mandating that the lists be stored in device tree won't please
everyone.

...
> > I see your point about separate ownership of pins/groups and the actual
> > HW register programming. The pinctrl subsystem doesn't have a concept
> > of separating those two things at the moment though. I don't think its
> > unreasonable to still have to write the mux values into the device tree
> > and even reprogram them to the same value when Linux boots though. Do
> > you see a problem with that? If there is a problem, we need to fix it
> > in pinctrl too, irrespective of any device tree work.
> 
> Yeah I think we can handle some pinmuxing cases automatically.
> But basically we need to support also the following typical cases:
> 
> 1. Static muxing in bootloader only and no mux entries in the .dts files

That's easily handled in the binding I proposed; simply don't put any
mux/config settings into the device tree. Portable drives will still
call pinmux_get(), so there need to be nodes to back that up, but the
list of strings that get applied can be empty if you wish, assuming the
driver doesn't need different configurations at runtime.

> 2. Init time only muxing based on the entries in .dts files

Similar answer to (1).

> 3. Dynamic remuxing of pins for the pins specified in the .dts files

Yes, that's handled by simply putting multiple named configurations into
the device tree.

...
> > > Something like:
> > >
> > > 	pins =
> > > 	<&tegra_pmx TEGRA_PMX_PG_DTA TEGRA_PMX_MUX_1 TEGRA_PMX_CONF_TRISTATE 1
> > > 	 &tegra_pmx TEGRA_PMX_PG_DTD TEGRA_PMX_MUX_1 TEGRA_PMX_CONF_TRISTATE 1>;
> > >
> > > and in the parent set #pin-args to 3.
> >
> > That doesn't support setting a variable number of config values per pin/
> > group. Tegra30 has 13 define TEGRA_PMX_CONF_* values, and requiring every
> > one of those to be set for every pin/group would be a bit unwieldy,
> > especially since 99% of the time we just rely on the HW defaults, and I
> > imagine many other SoCs are the same.
> 
> But aren't these 13 defines for TEGRA_PMX_CONF_* just bit offsets in some
> register?

No.

The same TEGRA_PMX_CONF_* parameter doesn't necessarily exist for all
pins or all groups.

Where it does exist, different pins/groups may store the value in a
different bit number in the/some register based on the group, and the
width of the bit field may vary too.

So, the TEGRA_PMX_CONF_* are just a logical name/ID of the parameter to be
configured, which is then looked up in the table of pins/groups known to
the Tegra pinctrl driver, which also determines the register, bit, and
field size for the combination.

-- 
nvpublic

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists