* Linus Walleij <linus.wall...@linaro.org> [130624 05:43]: > On Mon, Jun 17, 2013 at 8:02 PM, Tony Lindgren <t...@atomide.com> wrote: > > * Linus Walleij <linus.wall...@linaro.org> [130617 09:11]: > > >> Bear in mind that struct pinctl * forks effects in two paths, > >> one is muxing the other is config, like pull-ups etc. > > > > I also thought the plan was to merge pinmux and pinconf and > > do things based the named modes? > > That is done from a consumer point of view. > Consumers only care about pinctrl * handles > and pinctrl_state * switches. > > > The last time I tried using the pinconf functions it involved > > knowing the name of the pin in the consumer driver. The name > > may not be very descriptive in the device tree cases at least > > for the pinctrl-single. So I did not pay much attention to > > the pinconf functions. > > Consumers should not use that interface, i.e.: > > int pin_config_get(const char *dev_name, const char *name, > unsigned long *config); > int pin_config_set(const char *dev_name, const char *name, > unsigned long config) > > This needs to be deleted from <linux/pinctrl/consumer.h> > I'll see if I can get rid of it pronto to avoid any more confusion > and sorry for leaving that in place for too long. > > The proper way to use it is to use the states.
OK thanks for clarifying that. Yes I think the named states is a good way to handle the pins in a generic way. Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
