On Mon, Aug 5, 2013 at 1:51 PM, Christian Ruppert
[off-list ref] wrote:

[Me]

quoted

I don't see any of the port concept creeping into the device tree
in this version and that is how I think it should be kept:
the "port" particulars is a thing for the driver and not the
device tree.

I'm not sure if everybody is aligned here (or if we even understand each
other): In my terminology, a "port" is a set of pins controlled by the
same register/bit field.

OK, that can also be called a "bank" or "register" but whatever.

An "interface" is a set of pins which form a
functional unit, e.g. an SPI interface.

This is called a pinmux setting in the pinctrl terminology.

A group is a number of pins, a function is a functionality such as SPI.
When the function SPI is combined with a group of pins in a map, it
creates a pinmux setting.

One port can contain several
interfaces

In pinctrl terminology this means it controls several functions.

which may or may not be mapped at the same time. Inversely
(especially if every pin can be configured separately), mapping of an
interface might require the configuration of more than one ports. The
concept of interfaces is on a higher level of abstraction (in the sense
"further away from physical pinmux configuration") than the concept of a
port.

Hm maybe I still do not understand what an "interface" really is
on this hardware.

In the driver under discussion, pin groups are defined for every
"interface" to make sure that interfaces can be requested in an
orthogonal way by different modules and modules don't have to be "aware"
of which interfaces are grouped into which port (and which other modules
request which other interfaces). A request either succeeds or fails.
Resource management (which interfaces can be mapped simultaneously) is
done inside the pinctrl driver.

OK

If I understand Stephen correctly, the traditional way of requesting pin
configurations is at "port" level, e.g. a configuration is defined by a
port and its mux setting.

Now it is ever more confused.

Pin configuration is about things like pull-up in pinctrl terminology.

Please talk about functions, groups and settings that combine
functions with groups.

The TB10x driver works on a higher level of
abstraction ("interface" level), where interfaces are requested and the
driver internally decides which configuration(s) to apply to which
port(s). Ports are not used in the device tree indeed, but interfaces
are.

Based on this, I don't quite understand your comment: You say you don't
like ports starting to leak outside of the pinctrl driver but according
to Stephen that's what is common practice today? Did you mean
interfaces? The TB10x driver's configuration nodes are currently defined
based on interfaces.

I think that language is part of the problem here.

Can you please double-check my definitions of terms in
Documentation/pinctrl.txt so we are talking the same language?

Yours,
Linus Walleij