On Mon, Aug 5, 2013 at 1:51 PM, Christian Ruppert
<christian.ruppert@xxxxxxxxxx> 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-doc" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
