| Message ID | 1347519686-10170-1-git-send-email-linus.walleij@stericsson.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On 09/13/2012 01:01 AM, Linus Walleij wrote: > From: Linus Walleij <linus.walleij@linaro.org> > > The semantics of the interactions between GPIO and pinctrl may be > unclear, e.g. which one do you request first? This amends the > documentation to make this clear. > +Drivers needing both pin control and GPIOs > +========================================== > + > +Again, it is discouraged to let drivers lookup and select pin control states > +themselves, but again sometimes this is unavoidable. > + > +So say that your driver is fetching its resources like this: > + > +#include <linux/pinctrl/consumer.h> > +#include <linux/gpio.h> > + > +struct pinctrl *pinctrl; > +int gpio; > + > +pinctrl = devm_pinctrl_get_select_default(&dev); > +gpio = devm_gpio_request(&dev, 14, "foo"); > + > +Here we first request a certain pin state and then request GPIO 14 to be > +used. If you're using the subsystems orthogonally like this, always get > +your pinctrl handle and select the desired pinctrl state BEFORE requesting > +the GPIO. This is a semantic convention to avoid situations that can be > +electrically unpleasant, you will certainly want to mux in and bias pins > +in a certain way before the GPIO subsystems starts to deal with them. I'm not 100% certain that all HW will work best by first programming pinctrl then programming GPIO. For example of strangeness, Tegra's GPIO controller has a bit per-pin which overrides the pinmux's mux function to enable GPIOs, yet the pinctrl's tri-state overrides the GPIO's input/output control. I imagine HW engineers can come up with even more bizarre schemes that might in some cases require the reverse order). However, I suppose what you've documented is likely common and it'd be good to recommend a default order between the two APIs. I might whittle out the part that justifies the order from a HW glitching perspective though. > +The above can be hidden: using pinctrl hogs, the driver may be setting s/the driver/the pinctrl driver/ I think. > +up the config and muxing for the pins when the pinctrl driver is probing, > +nevertheless orthogonal to the GPIO subsystem. > + > +But there are also situations where it makes sense for the GPIO subsystem > +to communicate directly with with the pinctrl subsystem, using the latter > +as a back-end. This is when the GPIO driver may call out to the functions > +described in the section "Pin control interaction with the GPIO subsystem" > +above. This only involves per-pin multiplexing, and will be completely > +hidden behind the gpio_*() function namespace. In this case, the driver > +need not interact with the pin control subsystem at all. I think it makes sense to more strongly recommend that for GPIO muxing, the GPIO driver always call into the pinctrl subsystem (if needed by the HW) to perform that muxing, so that standalone gpio_direction_*() always work without any use of pinctrl; the interaction between the two should only be required if pin configuration (not just pin muxing) is also required.
On Thu, Sep 13, 2012 at 10:11:29AM -0600, Stephen Warren wrote: > On 09/13/2012 01:01 AM, Linus Walleij wrote: > > From: Linus Walleij <linus.walleij@linaro.org> > > > > The semantics of the interactions between GPIO and pinctrl may be > > unclear, e.g. which one do you request first? This amends the > > documentation to make this clear. > > > +Drivers needing both pin control and GPIOs > > +========================================== > > + > > +Again, it is discouraged to let drivers lookup and select pin control states > > +themselves, but again sometimes this is unavoidable. > > + > > +So say that your driver is fetching its resources like this: > > + > > +#include <linux/pinctrl/consumer.h> > > +#include <linux/gpio.h> > > + > > +struct pinctrl *pinctrl; > > +int gpio; > > + > > +pinctrl = devm_pinctrl_get_select_default(&dev); > > +gpio = devm_gpio_request(&dev, 14, "foo"); > > + > > +Here we first request a certain pin state and then request GPIO 14 to be > > +used. If you're using the subsystems orthogonally like this, always get > > +your pinctrl handle and select the desired pinctrl state BEFORE requesting > > +the GPIO. This is a semantic convention to avoid situations that can be > > +electrically unpleasant, you will certainly want to mux in and bias pins > > +in a certain way before the GPIO subsystems starts to deal with them. > > I'm not 100% certain that all HW will work best by first programming > pinctrl then programming GPIO. For example of strangeness, Tegra's GPIO > controller has a bit per-pin which overrides the pinmux's mux function > to enable GPIOs, yet the pinctrl's tri-state overrides the GPIO's > input/output control. I imagine HW engineers can come up with even more > bizarre schemes that might in some cases require the reverse order). This sounds like a good argument to keep pinctrl and GPIO subsystems orthogonal as much as possible. > However, I suppose what you've documented is likely common and it'd be > good to recommend a default order between the two APIs. I might whittle > out the part that justifies the order from a HW glitching perspective > though. Maybe a note like "The order of pin and GPIO acquisitions may be reversed due to HW constrains or glitch-free policies" is enough? > > +But there are also situations where it makes sense for the GPIO subsystem > > +to communicate directly with with the pinctrl subsystem, using the latter > > +as a back-end. This is when the GPIO driver may call out to the functions > > +described in the section "Pin control interaction with the GPIO subsystem" > > +above. This only involves per-pin multiplexing, and will be completely > > +hidden behind the gpio_*() function namespace. In this case, the driver > > +need not interact with the pin control subsystem at all. > > I think it makes sense to more strongly recommend that for GPIO muxing, > the GPIO driver always call into the pinctrl subsystem (if needed by the > HW) to perform that muxing, so that standalone gpio_direction_*() always > work without any use of pinctrl; the interaction between the two should > only be required if pin configuration (not just pin muxing) is also > required. Don't know. Isn't possible to reach the same effect moving this kind of knowledge into higher level helper functions and remove this bridge across the subsystems? Because there is also the pin config stuff that may require special mixing as well and it's clear that there is no space for it in these calls. cheers, Domenico
On Thu, Sep 13, 2012 at 6:11 PM, Stephen Warren <swarren@wwwdotorg.org> wrote: > On 09/13/2012 01:01 AM, Linus Walleij wrote: >> +Here we first request a certain pin state and then request GPIO 14 to be >> +used. If you're using the subsystems orthogonally like this, always get >> +your pinctrl handle and select the desired pinctrl state BEFORE requesting >> +the GPIO. This is a semantic convention to avoid situations that can be >> +electrically unpleasant, you will certainly want to mux in and bias pins >> +in a certain way before the GPIO subsystems starts to deal with them. > > I'm not 100% certain that all HW will work best by first programming > pinctrl then programming GPIO. For example of strangeness, Tegra's GPIO > controller has a bit per-pin which overrides the pinmux's mux function > to enable GPIOs, yet the pinctrl's tri-state overrides the GPIO's > input/output control. I imagine HW engineers can come up with even more > bizarre schemes that might in some cases require the reverse order). > > However, I suppose what you've documented is likely common and it'd be > good to recommend a default order between the two APIs. I might whittle > out the part that justifies the order from a HW glitching perspective > though. Yeah. I think I'm on the safe side since I wrote "should" rather than "must", I have understood that some standardization people pay a lot of attention to which of these two words is used... "should" is possible to break but only for good reasons. But I diplomatized the language a bit more. >> +The above can be hidden: using pinctrl hogs, the driver may be setting > > s/the driver/the pinctrl driver/ I think. OK >> +up the config and muxing for the pins when the pinctrl driver is probing, >> +nevertheless orthogonal to the GPIO subsystem. >> + >> +But there are also situations where it makes sense for the GPIO subsystem >> +to communicate directly with with the pinctrl subsystem, using the latter >> +as a back-end. This is when the GPIO driver may call out to the functions >> +described in the section "Pin control interaction with the GPIO subsystem" >> +above. This only involves per-pin multiplexing, and will be completely >> +hidden behind the gpio_*() function namespace. In this case, the driver >> +need not interact with the pin control subsystem at all. > > I think it makes sense to more strongly recommend that for GPIO muxing, > the GPIO driver always call into the pinctrl subsystem (if needed by the > HW) to perform that muxing, so that standalone gpio_direction_*() always > work without any use of pinctrl; the interaction between the two should > only be required if pin configuration (not just pin muxing) is also > required. OK I will make it a MUST and see if someone yells back at me :-) It so happens that the OMAP driver does not implement it for now... but we can then require it for new drivers. Linus Walleij
On Fri, Sep 14, 2012 at 12:11 AM, Domenico Andreoli <cavokz@gmail.com> wrote: > On Thu, Sep 13, 2012 at 10:11:29AM -0600, Stephen Warren wrote: >> I think it makes sense to more strongly recommend that for GPIO muxing, >> the GPIO driver always call into the pinctrl subsystem (if needed by the >> HW) to perform that muxing, so that standalone gpio_direction_*() always >> work without any use of pinctrl; the interaction between the two should >> only be required if pin configuration (not just pin muxing) is also >> required. > > Don't know. Isn't possible to reach the same effect moving this kind > of knowledge into higher level helper functions and remove this bridge > across the subsystems? I'm not following, please elaborate on this. What are these higher level functions, and where will they be located? In which subsystem, and using what symbols/signatures and so on? Deepak or Arnd suggested to add a set of functions to the pinctrl driver vtable and make it possible to implement a generic gpio_chip deeply merged with a pin controller driver. I'm considering this, since it would also be a natural stepping stone to the /dev/pinctrl0 device(s) I want to see for userspace access the day we need it. > Because there is also the pin config stuff that > may require special mixing as well and it's clear that there is no space > for it in these calls. Yes but it is clear from the above that this need to be handled by pin control, either through hogs or as a last resort at runtime in the driver. Yours, Linus Walleij
On Fri, Sep 14, 2012 at 03:48:05PM +0200, Linus Walleij wrote: > On Fri, Sep 14, 2012 at 12:11 AM, Domenico Andreoli <cavokz@gmail.com> wrote: > > On Thu, Sep 13, 2012 at 10:11:29AM -0600, Stephen Warren wrote: > > >> I think it makes sense to more strongly recommend that for GPIO muxing, > >> the GPIO driver always call into the pinctrl subsystem (if needed by the > >> HW) to perform that muxing, so that standalone gpio_direction_*() always > >> work without any use of pinctrl; the interaction between the two should > >> only be required if pin configuration (not just pin muxing) is also > >> required. > > > > Don't know. Isn't possible to reach the same effect moving this kind > > of knowledge into higher level helper functions and remove this bridge > > across the subsystems? > > I'm not following, please elaborate on this. > > What are these higher level functions, and where will they be > located? In which subsystem, and using what symbols/signatures and > so on? If the common case is requesting the pin and then the gpio, an helper like this would do the trick. So why those calls into pinctrl should be done by the GPIO driver itself? Pinctrl and GPIO would be separated, ignoring each other. static int request_muxed_gpio(int gpio, const char *label) { int err; err = pinctrl_request_gpio(gpio) if (err) return err; err = gpio_request(gpio, label); if (err) pinctrl_free_gpio(gpio); return err; } static void free_muxed_gpio(int gpio) { gpio_free(gpio); pinctrl_free_gpio(gpio); } > Deepak or Arnd suggested to add a set of functions to the pinctrl > driver vtable and make it possible to implement a generic gpio_chip > deeply merged with a pin controller driver. I'm considering this, > since it would also be a natural stepping stone to the /dev/pinctrl0 > device(s) I want to see for userspace access the day we need it. If this is the plan, I can only agree. I thought it was a long term plan hence the reasoning in terms of helper functions above for a shorter-term proposal. Regards, Domenico
On 09/14/2012 08:30 AM, Domenico Andreoli wrote: > On Fri, Sep 14, 2012 at 03:48:05PM +0200, Linus Walleij wrote: >> On Fri, Sep 14, 2012 at 12:11 AM, Domenico Andreoli <cavokz@gmail.com> wrote: >>> On Thu, Sep 13, 2012 at 10:11:29AM -0600, Stephen Warren wrote: >> >>>> I think it makes sense to more strongly recommend that for GPIO muxing, >>>> the GPIO driver always call into the pinctrl subsystem (if needed by the >>>> HW) to perform that muxing, so that standalone gpio_direction_*() always >>>> work without any use of pinctrl; the interaction between the two should >>>> only be required if pin configuration (not just pin muxing) is also >>>> required. >>> >>> Don't know. Isn't possible to reach the same effect moving this kind >>> of knowledge into higher level helper functions and remove this bridge >>> across the subsystems? >> >> I'm not following, please elaborate on this. >> >> What are these higher level functions, and where will they be >> located? In which subsystem, and using what symbols/signatures and >> so on? > > If the common case is requesting the pin and then the gpio, an helper > like this would do the trick. So why those calls into pinctrl should be > done by the GPIO driver itself? Pinctrl and GPIO would be separated, > ignoring each other. > > static int request_muxed_gpio(int gpio, const char *label) That would require the driver to know when to call gpio_request() as opposed to request_muxed_gpio() wouldn't it. Whether that is needed or not depends on the Soc/board the driver is running on. The whole idea of the internal GPIO->pinctrl driver communication was to avoid that. I suppose that if we were to mandate that ever device that uses GPIOs also have at least some (possibly empty) pinctrl state defined, then request_muxed_gpio() could always be used. However, that's quite a strong requirement. An also, if we were to make that rule, then we might as well just implement this inside the existing gpio_request(), so that no driver changes were required.
diff --git a/Documentation/pinctrl.txt b/Documentation/pinctrl.txt index 1479aca..24c5995 100644 --- a/Documentation/pinctrl.txt +++ b/Documentation/pinctrl.txt @@ -289,6 +289,11 @@ Interaction with the GPIO subsystem The GPIO drivers may want to perform operations of various types on the same physical pins that are also registered as pin controller pins. +First and foremost, the two subsystems can be used as completely orthogonal, +see the section named "pin control requests from drivers" and +"drivers needing both pin control and GPIOs" below for details. But in some +situations a cross-subsystem mapping between pins and GPIOs is needed. + Since the pin controller subsystem have its pinspace local to the pin controller we need a mapping so that the pin control subsystem can figure out which pin controller handles control of a certain GPIO pin. Since a single @@ -359,6 +364,7 @@ will get an pin number into its handled number range. Further it is also passed the range ID value, so that the pin controller knows which range it should deal with. + PINMUX interfaces ================= @@ -960,8 +966,8 @@ all get selected, and they all get enabled and disable simultaneously by the pinmux core. -Pinmux requests from drivers -============================ +Pin control requests from drivers +================================= Generally it is discouraged to let individual drivers get and enable pin control. So if possible, handle the pin control in platform code or some other @@ -969,6 +975,11 @@ place where you have access to all the affected struct device * pointers. In some cases where a driver needs to e.g. switch between different mux mappings at runtime this is not possible. +A typical case is if a driver needs to switch bias of pins from normal +operation and going to sleep, moving from the PINCTRL_STATE_DEFAULT to +PINCTRL_STATE_SLEEP at runtime, re-biasing or even re-muxing pins to save +current in sleep mode. + A driver may request a certain control state to be activated, usually just the default state like this: @@ -1058,6 +1069,43 @@ registered. Thus make sure that the error path in your driver gracefully cleans up and is ready to retry the probing later in the startup process. +Drivers needing both pin control and GPIOs +========================================== + +Again, it is discouraged to let drivers lookup and select pin control states +themselves, but again sometimes this is unavoidable. + +So say that your driver is fetching its resources like this: + +#include <linux/pinctrl/consumer.h> +#include <linux/gpio.h> + +struct pinctrl *pinctrl; +int gpio; + +pinctrl = devm_pinctrl_get_select_default(&dev); +gpio = devm_gpio_request(&dev, 14, "foo"); + +Here we first request a certain pin state and then request GPIO 14 to be +used. If you're using the subsystems orthogonally like this, always get +your pinctrl handle and select the desired pinctrl state BEFORE requesting +the GPIO. This is a semantic convention to avoid situations that can be +electrically unpleasant, you will certainly want to mux in and bias pins +in a certain way before the GPIO subsystems starts to deal with them. + +The above can be hidden: using pinctrl hogs, the driver may be setting +up the config and muxing for the pins when the pinctrl driver is probing, +nevertheless orthogonal to the GPIO subsystem. + +But there are also situations where it makes sense for the GPIO subsystem +to communicate directly with with the pinctrl subsystem, using the latter +as a back-end. This is when the GPIO driver may call out to the functions +described in the section "Pin control interaction with the GPIO subsystem" +above. This only involves per-pin multiplexing, and will be completely +hidden behind the gpio_*() function namespace. In this case, the driver +need not interact with the pin control subsystem at all. + + System pin control hogging ==========================