From: Shawn Guo <shawn.guo@freescale.com>
To: Barry Song <21cnbao@gmail.com>
Cc: Linus Walleij <linus.walleij@stericsson.com>,
<linux-kernel@vger.kernel.org>,
Stephen Warren <swarren@nvidia.com>,
Linaro Dev <linaro-dev@lists.linaro.org>,
Sascha Hauer <s.hauer@pengutronix.de>,
David Brown <davidb@codeaurora.org>,
Grant Likely <grant.likely@secretlab.ca>,
Linus Walleij <linus.walleij@linaro.org>
Subject: Re: [PATCH 2/2] pinctrl: add a generic control interface
Date: Thu, 20 Oct 2011 21:10:43 +0800 [thread overview]
Message-ID: <20111020131042.GH32007@S2100-06.ap.freescale.net> (raw)
In-Reply-To: <CAGsJ_4yvgeX7H_csvVGyN6JDR-VAfB4Yd6tdFFtKeFy5ouBWBg@mail.gmail.com>
On Thu, Oct 20, 2011 at 05:17:08PM +0800, Barry Song wrote:
> >> +enum pin_config_param {
> >> + PIN_CONFIG_BIAS_UNKNOWN,
> >> + PIN_CONFIG_BIAS_FLOAT,
> >> + PIN_CONFIG_BIAS_HIGH_IMPEDANCE,
> >> + PIN_CONFIG_BIAS_PULL_UP,
> >> + PIN_CONFIG_BIAS_PULL_DOWN,
> >> + PIN_CONFIG_BIAS_HIGH,
> >> + PIN_CONFIG_BIAS_GROUND,
> >> + PIN_CONFIG_DRIVE_UNKNOWN,
> >> + PIN_CONFIG_DRIVE_PUSH_PULL,
> >> + PIN_CONFIG_DRIVE_OPEN_DRAIN,
> >> + PIN_CONFIG_DRIVE_OPEN_SOURCE,
> >> + PIN_CONFIG_DRIVE_OFF,
> >> + PIN_CONFIG_INPUT_SCHMITT,
> >> + PIN_CONFIG_SLEW_RATE_RISING,
> >> + PIN_CONFIG_SLEW_RATE_FALLING,
> >> + PIN_CONFIG_LOAD_CAPACITANCE,
> >> + PIN_CONFIG_WAKEUP_ENABLE,
> >> + PIN_CONFIG_END,
> >> +};
> >> +
> >
> > IMO, trying to enumerate all possible pin_config options is just to
> > make everyone's life harder. Firstly, this enumeration is far from
> > completion, for imx6 iomuxc example, we have 3 options for pull-up,
> > 22, 47 and 100 kOhm, and 7 options for driver-strength, 34, 40, 48,
> > 60, 80, 120, and 240 Ohm. It's just so hard to make this enumeration
> > complete. Secondly, defining this param as enum requires the API
> > user to call the function multiple times to configure one pin. For
> > example, if I want to configure pin_foo as slow-slew, open-drain,
> > 100 kOhm pull-up and 120 Ohm driver-strength, I will have to call
> > pin_config(pctldev, pin_foo, ...) 4 times to achieve that.
> >
> > I like Stephen's idea about having 'u32 param' and let pinctrl drivers
> > to encode/decode this u32 for their pinctrl controller. It makes
> > people's life much easier.
>
> A multifunctional API is actually a bad and hard-to-use API. i agree
> we can make param u32 instead of enum and let specific driver
> customizes the param by itself.
>
> But if there are some common params, for example, PULL, OC/OD,
> WAKEUP_ENABLE, which almost all platforms need, why don't we make
> them have common definitions like:
>
> #define PIN_CONFIG_PULL 0
> #define PIN_CONFIG_OPEN_DRAIN 1
> ....
> #define PIN_CONFIG_USER 5 (in case)
>
> if one platform has config not in the up list, then:
>
> #define PIN_CONFIG_TERGA_XXX PIN_CONFIG_USER
> #define PIN_CONFIG_TERGA_YYY (PIN_CONFIG_USER + 1)
>
> without the common definition from PIN_CONFIG_PULL to
> PIN_CONFIG_USER, many platforms will need to definite them repeatedly.
> that is what we hate.
>
I prefer to completely leave the encoding of this 'u32 param' to pinctrl
drivers, so that they can map the bit definition of 'param' to the
controller register as much as they can. On imx, we have one register
accommodating all pin configuration options for one pin, so we can
write 'param' directly into register with exactly same bit definition
as register.
--
Regards,
Shawn
next prev parent reply other threads:[~2011-10-20 13:00 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-10-19 16:21 Linus Walleij
2011-10-19 23:04 ` Stephen Warren
2011-10-20 2:45 ` Shawn Guo
2011-10-20 13:44 ` Linus Walleij
2011-10-20 18:41 ` Stephen Warren
2011-10-20 13:46 ` Linus Walleij
2011-10-20 10:24 ` Linus Walleij
2011-10-20 18:46 ` Stephen Warren
2011-10-20 2:31 ` Shawn Guo
2011-10-20 9:17 ` Barry Song
2011-10-20 13:10 ` Shawn Guo [this message]
2011-10-20 14:18 ` Linus Walleij
2011-10-23 8:51 ` Shawn Guo
2011-10-25 4:49 ` Stephen Warren
2011-10-20 14:04 ` Linus Walleij
2011-10-20 14:18 ` Mark Brown
2011-10-20 14:43 ` Linus Walleij
2011-10-20 15:42 ` Mark Brown
2011-10-21 12:28 ` Linus Walleij
2011-10-21 12:30 ` Mark Brown
2011-10-21 12:51 ` Linus Walleij
2011-10-21 12:55 ` Mark Brown
2011-10-21 12:57 ` Linus Walleij
2011-10-21 15:24 ` Mark Brown
2011-10-20 17:26 ` Stephen Warren
2011-10-23 8:25 ` Shawn Guo
2011-10-25 4:43 ` Stephen Warren
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=20111020131042.GH32007@S2100-06.ap.freescale.net \
--to=shawn.guo@freescale.com \
--cc=21cnbao@gmail.com \
--cc=davidb@codeaurora.org \
--cc=grant.likely@secretlab.ca \
--cc=linaro-dev@lists.linaro.org \
--cc=linus.walleij@linaro.org \
--cc=linus.walleij@stericsson.com \
--cc=linux-kernel@vger.kernel.org \
--cc=s.hauer@pengutronix.de \
--cc=swarren@nvidia.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
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
all inboxes | Powered by JetHome®