RE: [PATCH 2/2] pinctrl: add a generic control interface

[Stephen Warren]

Shawn Guo wrote at Wednesday, October 19, 2011 8:32 PM:
> On Wed, Oct 19, 2011 at 06:21:14PM +0200, Linus Walleij wrote:
...
> > +int pin_config_group(struct pinctrl_dev *pctldev, const char *pin_group,
> > +		     enum pin_config_param param, unsigned long data)
...
> > +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.

That's not quite what I meant.

I meant that I thought the types for param and value should be simple
integers, with meanings of the values defined by the individual drivers,
rather than a system-defined enum.

However, I wasn't envisaging packing multiple fields into the "value"
parameter; that would essentially be packing a struct into a u32 for
transport. I still figured that "param" would logically be an enum,
and represent a single modifiable parameter, and "data"/"value" would
be the single value of that one parameter.

Still, perhaps packing stuff is an option that makes sense in some cases,
depending on what API we end up with to manipulate the parameters, and
where the source of "data"/"value" is (encoded into client driver, or
from some hidden table passed to pinmux core by board, with the values
being passed directly to the pinmux drivers without the client drivers
seeing them)

-- 
nvpublic

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/