From: swarren@wwwdotorg•org (Stephen Warren)
To: linux-arm-kernel@lists•infradead.org
Subject: [PATCH] pinctrl: imx5: start numbering pad from 0
Date: Thu, 16 Aug 2012 15:12:10 -0600 [thread overview]
Message-ID: <502D622A.1030104@wwwdotorg.org> (raw)
In-Reply-To: <20120816033006.GA11999@shlinux2.ap.freescale.net>
On 08/15/2012 09:30 PM, Dong Aisheng wrote:
> On Wed, Aug 15, 2012 at 09:59:50PM +0800, Shawn Guo wrote:
> ...
>>> 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.
next prev parent reply other threads:[~2012-08-16 21:12 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-08-13 14:47 [PATCH] pinctrl: imx5: start numbering pad from 0 Shawn Guo
2012-08-13 15:12 ` Matt Sealey
2012-08-14 7:20 ` Dong Aisheng
2012-08-14 19:37 ` Matt Sealey
2012-08-15 3:59 ` Dong Aisheng
2012-08-15 5:44 ` Uwe Kleine-König
2012-08-15 6:55 ` Dong Aisheng
2012-08-15 7:51 ` Uwe Kleine-König
2012-08-15 9:25 ` Dong Aisheng
2012-08-15 10:33 ` Dong Aisheng
2012-08-15 13:59 ` Shawn Guo
2012-08-15 15:31 ` Shawn Guo
2012-08-15 16:49 ` Matt Sealey
2012-08-16 3:45 ` Shawn Guo
2012-08-16 17:39 ` Matt Sealey
2012-08-15 15:39 ` Stephen Warren
2012-08-16 3:30 ` Dong Aisheng
2012-08-16 18:51 ` Matt Sealey
2012-08-16 21:12 ` Stephen Warren [this message]
2012-08-21 12:52 ` Linus Walleij
2012-08-21 12:46 ` Linus Walleij
2012-08-13 19:26 ` Troy Kisky
2012-08-14 7:30 ` Dong Aisheng
2012-08-14 18:09 ` Troy Kisky
2012-08-15 4:00 ` Dong Aisheng
2012-08-14 8:13 ` Linus Walleij
2012-08-14 8:22 ` Shawn Guo
2012-08-14 9:48 ` Linus Walleij
2012-08-14 9:50 ` Linus Walleij
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=502D622A.1030104@wwwdotorg.org \
--to=swarren@wwwdotorg$(echo .)org \
--cc=linux-arm-kernel@lists$(echo .)infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox