Messages in this thread | | | From | CoffBeta <> | Date | Tue, 29 Jun 2010 16:29:04 +0800 | Subject | Re: gpiolib and sleeping gpios |
| |
non-sleeping
On Mon, Jun 21, 2010 at 05:31, Ryan Mallon <ryan@bluewatersys.com> wrote: > On 06/19/2010 06:21 PM, David Brownell wrote: >> >>> >>> The runtime warnings will only show instances where the >>> non-sleeping >>> versions where called instead of the sleeping versions. >> >> ... *AND* the GPIO requires the cansleep() version... >> >> Right; such calls are errors. We issue >> warnings since fault returns are inapplicable. > > A driver which only uses the non-sleeping versions, but _could_ use the > cansleep variants (ie all calls to gpio_(set/get)_value are made from > contexts where it is possible to sleep) is not so easy to spot. Passing > a sleeping to gpio to such a driver will result in spurious warnings. > >>> There is no >>> warning to say that we are calling the spinlock safe >>> version, where it is possible to sleep. >> >> The call context isn't what controls whether >> gpio_get_value() or gpio_get_value_cansleep() >> is appropriate ... it's the GPIO itself, and >> how its implementation works. > > No, a driver should not know anything about a gpio which is passed to > it. If a driver is able to call the cansleep variants, then it should, > and it will allow any gpio, sleeping or non-sleeping, to be used with > that driver. > > If a driver uses a gpio in such a way that it cannot sleep, ie the > gpio_(get/set)_value calls are made from spinlock context, then only > gpios which do not sleep may be used with that driver. > > Thats why I think specifying whether the gpio is able to sleep when it > is requested is a good idea. A driver which cannot use a sleeping gpio > > >> "possible to sleep" is a GPIO attribute, >> exposed by a predicate. If spinlock-safe >> calls are used on GPIOs with that attribute, >> a warning *IS* issued. > > Possible to sleep is also an attribute of how a driver _uses_ a gpio. > >>> >>> The point I was trying to make is that there are lots of >>> drivers which >>> will not work with gpios on sleeping io expanders because >>> they call the >>> spinlock safe gpio calls. >> >> And they will trigger runtime warnings, and >> thus eventually get fixed. The way to do that >> is to check if the GPIO needs the cansleep() >> call > > Hmm, maybe this then for drivers which cannot accept sleeping gpios: > > if (gpio_cansleep(some_gpio)) { > dev_err(&dev, "This driver only supports non-sleeping gpios"); > return -EINVAL; > } > > err = gpio_request(some_gpio, "some_gpio"); > > I think ideally, gpio_request should specify this via a flags argument, ie: > > #define GPIOF_NO_SLEEP 0x0 > #define GPIOF_CANSLEEP 0x1 > > err = gpio_request(some_gpio, "some_gpio", GPIOF_NO_SLEEP); > > ~Ryan > > -- > Bluewater Systems Ltd - ARM Technology Solution Centre > > Ryan Mallon 5 Amuri Park, 404 Barbadoes St > ryan@bluewatersys.com PO Box 13 889, Christchurch 8013 > http://www.bluewatersys.com New Zealand > Phone: +64 3 3779127 Freecall: Australia 1800 148 751 > Fax: +64 3 3779135 USA 1800 261 2934 > -- > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |