Date:	Thu, 19 Jan 2012 11:30:18 -0800
From:	Stephen Warren <swarren@...dia.com>
To:	Linus Walleij <linus.walleij@...aro.org>
CC:	Shawn Guo <shawn.guo@...aro.org>,
	"linus.walleij@...ricsson.com" <linus.walleij@...ricsson.com>,
	"s.hauer@...gutronix.de" <s.hauer@...gutronix.de>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"rob.herring@...xeda.com" <rob.herring@...xeda.com>,
	Richard Zhao <richard.zhao@...aro.org>,
	"kernel@...gutronix.de" <kernel@...gutronix.de>,
	"cjb@...top.org" <cjb@...top.org>,
	"devicetree-discuss@...ts.ozlabs.org" 
	<devicetree-discuss@...ts.ozlabs.org>,
	"linux-arm-kernel@...ts.infradead.org" 
	<linux-arm-kernel@...ts.infradead.org>,
	Dong Aisheng <dongas86@...il.com>
Subject: RE: [RFC PATCH v3 2/5] pinctrl: add dt binding support for pinmux
 mappings

Linus Walleij wrote at Thursday, January 19, 2012 9:56 AM:
> On Tue, Jan 17, 2012 at 8:50 PM, Stephen Warren <swarren@...dia.com> wrote:
> > Linus Walleij wrote at Monday, January 16, 2012 9:09 AM:
> 
> >> As you can see none of the text above claims that the group is
> >> about hardware-defined groups or anything like that.
> >
> > Well, I guess that's true, but didn't we only add the concept of groups
> > to the pinctrl subsystem in order to support Tegra's HW-group-based
> > muxing?
> 
> The groups appeared in v6 of the very first patchset, this is
> from git log drivers/pinctrl
> 
>     ChangeLog v5->v6:
> 
>     - Create an abstract pin group concept that can sort pins into
>       named and enumerated groups no matter what the use of these
>       groups may be, one possible usecase is a group of pins being
>       muxed in or so. The intention is however to also use these
>       groups for other pin control activities.

To me, "activities" above reads as pin configuration, since muxing is
an activity that's covered by this patch, and pin config is an additional
one. If doesn't imply virtual groups, which are data not an activity.

I still feel that virtual groups don't have much purpose, since the
whole reason I asked that the pin mux mapping table allow multiple
entries to be allowed for each (map name, device) pair was to allow
grouping of the lowest-level muxable entity into groups that the
device used. So, defining these virtual groups is a completely
redundant way of achieving the same goal.

For DT bindings, I think we (at least myself, Shawn, and Dong) have
agreed that with my binding proposal, you can get the same effect as
virtual groups without the driver needing to define them (this is
certainly true even if I misrepresent others' understanding). For the
non-DT case, I proposed that the virtual groups could be represented
as #defines/macros that could be used while initializing the board's
mapping table, each containing n lines of entries as appropriate. Then,
non-DT and DT could have equivalent sysfs output for pinctrl.

That all said, I suppose that if the pinctrl driver were to expose some
virtual groups, there's the possibility this will reduce the size of
the device tree or static board mapping files, since they won't need
so many entries or rows.

I'd be happy if we adopted the following policy for when to define
pin groups in a pinctrl driver. This both allows virtual groups if the
SoC's vendor wants them in their pinctrl driver, yet still exposes
the raw capabilities of the SoC, in case the pre-defined virtual groups
don't cover a case that needs to be used:

pinctrl drivers MUST enumerate all pins that are affected by the muxing
or pin configuration capabilities of the pinctrl driver. Where the HW
muxes or configures pins in terms of groups, this list MUST include
ALL pins in the groups that the pinctrl driver defines. Pinctrl drivers
MAY expose a subset of pins present on the SoC, and grow this list over
time as needed, provided the previous conditions are met.

(well, that's already a requirement of the pinctrl subsystem just due
to how it works internally)

If the HW muxes and configures pins on a per-pin basis, the pinctrl
driver MUST enumerate a group for each individual pin included in the
pin enumeration above, and allow muxing and pin configuration operations
to be applied to these groups.

(that's the main point I seek)

If the HW muxes and configures pins on a per-group basis, the pinctrl
driver MUST enumerate all groups that are affected by the muxing
or pin configuration capabilities of the pinctrl driver. Pinctrl drivers
MAY need to enumerate a group for each individual pin included in the
pin enumeration above, e.g. if representing "GPIO" as a mux function.
pinctrl drivers MAY expose a subset of groups present on the SoC, and
grow this list over time as needed, provided the previous conditions
are met.

(again, that's really just how pinctrl already works)

pinctrl drivers MAY expose additional groups. This feature may be used
to represent higher-level groupings of the HW's raw muxable pins or
groups. This may be useful in order to e.g. represent all pins involved
in a single SD interface, so their muxing may be represented in a single
pin mux mapping table entry. Such groups MUST still define a valid list
of the individual pins included in the group. Individual pinctrl drivers
are responsible for any iteration required when muxing/configuration such
"virtual" groups. This feature MAY be used irrespective of whether the
underlying HW muxes or configures pins on a per-pin or per-group basis.

(this explicitly allows "virtual" groups)

Does that seem reasonable?

(is it worth adding this to the documentation of pinctrl?)

-- 
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