Thread (1 message) 1 message, 1 author, 2012-08-16

[PATCH] pinctrl: imx5: start numbering pad from 0

From: Stephen Warren <hidden>
Date: 2012-08-16 21:12:10
Also in: linux-devicetree

On 08/15/2012 09:30 PM, Dong Aisheng wrote:
On Wed, Aug 15, 2012 at 09:59:50PM +0800, Shawn Guo wrote:
...
quoted
quoted
Another known issue is that via this way, that means the pinctrl subsystem
can only see the using pads, this is a bit not align with the pinctrl
subsystem design. No sure if Linus would like to see it.
I do not quite follow on this.  The "enum imx51_pads" will still be
there, so all the pads will still be visible to the pinctrl system.
Sorry, i did not describe it accurately.
The problem is that those pins are visible to pinctrl subystem, but the pinctrl
subsystem can not manage them all.
Not sure this meet Linus's original design purpose.
Because for the way proposed, all the pin's basic properties like mux_reg, config_reg
are parsed from device tree at runtime.
If a pin is not used in device tree, the driver can not know this pin's
corresponding registers.
Thus, for those unused pins, we can not manage it on mux or config in pinctrl
subsystem and driver.

For example, the pin_config_get/pin_config_set API in
include/linux/pinctrl/consumer.h can not work for such pins.
Hmmm. Given we support all pin mux/config options from the mapping
table, I'd question whether that API should even exist any more...
Then imx_pinconf_dbg_show in current driver may need change since it does not
support show all pins's config value.
The pinctrl core assumes that the pin numbering space could be sparse.
For example, see that pinconf.c:pinconf_pins_show() "continues" the loop
if pin_desc_get() fails for a particular pin number. So just based on
what I've read in this one email, I think this is fine.
It looks like not a big issue currently since i did not see any client driver
using this API.
But i'm not sure if we may have this requirement in the future.
For example, is it possible that pinctrl subsystem may support configure pins
via sysfs dynamically?
I can't comment on sysfs specifically, but I believe it would be
generally true that a pin that isn't know to the pinctrl subsystem can't
be manipulated in any way.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help