On Thu, Oct 20, 2011 at 11:17 AM, Barry Song 21cnbao@gmail.com wrote:
[Shawn]
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.
I am hesitant about that idea because it echoes something I have heard before, about how every system is so very special.
Greg had this very famous quote, "yes you're special, just like everyone else"...
I think (and of course this may be completely wrong, but it's my working hypthesis) that the things that software wants to do to pins are:
- Enumerable, not vast
- Actually often very much the same things, just named differently
- Often possible to express in terms of SI-units (Ohms, nanoseconds, Farad, Volt per sec, ...)
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.
In the patch you're quoting:
- @PIN_CONFIG_END: this is the last enumerator for pin configurations, if
- you need to pass in custom configurations to the pin controller, use
- PIN_CONFIG_END+1 as the base offset
So you begin your custom enum like this:
#include <linus/pinctrl/pinctrl.h>
enum foo_pin_config { PIN_CONFIG_FOO_XXX = PIN_CONFIG_END+1, PIN_CONFIG_FOO_YYY, .... };
Enums are good because in theory they give some type safety. (Maybe not in practice. Hm.) But lecture me a bit about why this is such a bad idea and I will change them into #define:s but I want a solid case for it first.
Maybe PIN_CONFIG_END is not such a good name for the last enum since there are more configs in the expanded cases...
Yet again, can I have some examples of what PIN_CONFIG_USER may *actually* be, which would be absolutely impossible to express in some neutral way, and ridiculous to have in the generic enum?
There is a lot of things with strange names in some current pin controllers/muxes, but strange names doesn't count, it has to be a strange concept behind it to be strange for real.
At one point when I was creating pinmux I was told this was pointless because one platform was doing pinmux, another padmux, a third "mission modes", a fourth "alternat functions". But it turns out that these are just different names for one and the same thing, so I have this maybe naïve idea that pin control/bias/drive/etc may largely be the same.
Example setting a pin "floating", "high impedance", tristate", "high-Z" or "off" turns out to often mean the exact same thing.
Yours, Linus Walleij