-----Original Message-----
From: Stephen Warren [mailto:swarren at nvidia.com]
Sent: Thursday, January 12, 2012 4:18 AM
To: Dong Aisheng-B29396; Dong Aisheng
Cc: linux-kernel at vger.kernel.org; linus.walleij at stericsson.com;
s.hauer at pengutronix.de; rob.herring at calxeda.com; linux-arm-
kernel at lists.infradead.org; kernel at pengutronix.de; cjb at laptop.org; devicetree-
discuss at lists.ozlabs.org; Simon Glass (sjg at chromium.org)
Subject: RE: [RFC PATCH v3 2/5] pinctrl: add dt binding support for pinmux
mappings
Importance: High

Dong Aisheng wrote at Tuesday, January 10, 2012 1:21 AM:

quoted

Stephen Warren wrote at Saturday, January 07, 2012 2:03 AM:

...

quoted

quoted

Now in the board's .dts file, you need to specify for each device
the list of pinmux groups the device needs to use, and the function to

select for each group.

quoted

quoted

Perhaps something like:

board.dts:

usdhc at 0219c000 { /* uSDHC4 */
        fsl,card-wired;
        status = "okay";
        pinmux = <&foogrp &uart3func &bazgrp &uart4func>; };

I haven't convinced myself that's actually a good binding, but I
think it does represent the data required for muxing. Some potential issues

as before:

quoted

Here is what we should discuss exactly.
Since 'pinmux' phandle will be parsed in pinctrl core, we should try
to find and define a common and standardized pinmux property for all platforms.

Yes.

...

quoted

To keep consistency as the currently design of pinctrl subsystem and
also meet the dt design philosophy, we still do not introduce a pinmux map in

dt.

quoted

Instead, we choose to scan all the device node with a 'pinmux' phandle
to construct a pinmux map table before register the pin controller
device(here we may also scan the hog_on_boot node) and I guess it's easy to do

that.
...

quoted

(Without scan the device node to construct the pinmux map table, we
can only get the map Information when we run the pinmux_get.
See: https://lkml.org/lkml/2012/1/5/153
So no pinmux map table exists and we surely do not want to see that
the sysfs exporting pinmux map information works in dt but unwork in
non-dt)

Hmmm. I'm not sure that the pinctrl code should actively scan all nodes in the
device tree for pin mux properties. That seems a little invasive; how does

It's one solution although not good.

pinctrl know which nodes it really should be looking at, and which nodes are
random internal parts of some device's custom binding?

Looking at all device nodes with 'pinmux' property which should not be used by
Others.

Personally, I think I'd be OK with the sysfs pinctrl map file only containing
the map entries for devices that had used the pinctrl API, and hence only
parsing the pinmux properties in pinmux_get().

Actually I already did it like that in the patch I sent:
https://lkml.org/lkml/2012/1/5/153

Originally I'd like to do like that but I found an inconsistent issue that
the sysfs pinctrl map file will behave differently between dt and non-dt
Platform. For non-dt, it means showing all exist map entries. For dt, it means
Only used pinmux map entries.

And in current design when device calls pinmux_get, it will search a predefined
pinmux_maps array to find which function and group it is binded to.
If switch to the new way, we only dynamically create pinmux map and dynamically 
register it when pinmux_get is called, first we need to change the code path in
pinmux_get in a totally different way, second for support that we may also better
to change pinmux_maps array to a list.
But after changing the pinmux_maps to a list, what about using in non-dt?

So without any strong reason i still think it would be better to keep consistency
With the non-dt pinctrl subsystem.
And the effort would be minimum since besides constructing the map by parsing
Device tree, everyting is the same as before in pinmux map and we could re-use
the current code.

However, we could perhaps do better by registering a bus notifier, and pro-
actively parsing the top-level DT node (if there is one) for every device that
is created. That way, the mapping would be parsed as soon as the device was
created (or perhaps after probe?). The only case this might not cover is DT
nodes for which the kernel doesn't actually have a driver, and hence no device
is created.

quoted

BTW it seems you want to support multi pin groups(foogrp and bazgrp)
for one device, do we have such using case?
I guess usually one pin group already contains all the pins of device.
Anyway, just from flexibility view, it's good for me.

Yes.

Recall that I believe that pin group definitions should only exist where the HW
itself muxes pins on a per-group basis rather than a per-pin basis.
This may be a bit different to what you mean by a group. Anyway...

As an example on Tegra, we have:

* SD controller 4 HW block
* Pin group ATB contains two pins, which are the CLK and CMD signals
  when the SDIO4 function is muxed onto the group.
* Pin group GMA contains four pins, which are DATA[3:0] when the SDIO4
  function is muxed onto the group.
* Pin group GME contains four pins, which are DATA[7:4] when the SDIO4
  function is muxed onto the group.

Hence, a board that uses this SD controller in that configuration would need 3
entries in its pinmux property/node.

Unsertood.

In general, I think all SoCs are likely to be the same way, except that you'd
need n pins in the list instead of n groups, again recalling that I'm talking
about HW-level pins/groups, not entries in a "supported configuration" list.

--
nvpublic

Regards
Dong Aisheng