[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.