Thread (98 messages) 98 messages, 13 authors, 2012-01-20

[RFC PATCH v3 2/5] pinctrl: add dt binding support for pinmux mappings

From: Dong Aisheng-B29396 <hidden>
Date: 2012-01-13 08:07:39
Also in: linux-devicetree, lkml

-----Original Message-----
From: Shawn Guo [mailto:shawn.guo at linaro.org]
Sent: Friday, January 13, 2012 11:55 AM
To: Stephen Warren
Cc: Dong Aisheng-B29396; Dong Aisheng; 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

On Thu, Jan 12, 2012 at 12:56:52PM -0800, Stephen Warren wrote:
quoted
Dong Aisheng wrote at Thursday, January 12, 2012 1:36 AM:
quoted
Stephen Warren wrote at Thursday, January 12, 2012 4:18 AM:
quoted
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
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.
quoted
quoted
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.
quoted
quoted
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.
OK. I think this can work out pretty easily with a bus notifier as I
mentioned before.
Sorry I did not catch your idea before.
I will try to see if I can find an example.
quoted
But, one thought on doing this in pinmux_get(). I'd simply implement a
Function that read a DT node's pinmux property/node, converted it to a
pinmux mapping table, and registered it with the pinctrl core. Then,
pinmux_get() could simply call this before doing anything else at all.
I don't think you'd need to modify how pinmux_get() worked at all.
This sounds like a pretty good idea to me.
This does not fix the inconsistency issue.
Additionally as I said before, for better support dynamically register pinmux
Map, it looks we'd better change the pinmux_maps array to a list.
However this is for dt case.
But for non-dt case, the static array is just ok.
So there's conflict.
Not sure if any better idea to fix this.

Regards
Dong Aisheng
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help