Date:	Wed, 14 Aug 2013 18:53:56 +0200
From:	Linus Walleij <linus.walleij@...aro.org>
To:	Christian Ruppert <christian.ruppert@...lis.com>
Cc:	Stephen Warren <swarren@...dotorg.org>,
	Patrice CHOTARD <patrice.chotard@...com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Grant Likely <grant.likely@...retlab.ca>,
	Rob Herring <rob.herring@...xeda.com>,
	Rob Landley <rob@...dley.net>,
	Sascha Leuenberger <sascha.leuenberger@...lis.com>,
	Pierrick Hascoet <pierrick.hascoet@...lis.com>,
	"linux-doc@...r.kernel.org" <linux-doc@...r.kernel.org>,
	Alexandre Courbot <acourbot@...dia.com>,
	"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>
Subject: Re: [PATCH 2/4] pinmux: Add TB10x pinmux driver

On Mon, Aug 5, 2013 at 1:51 PM, Christian Ruppert
<christian.ruppert@...lis.com> wrote:
> [Me]
>> 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
--
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