Re: [Patch v2 1/2] gpio: add GPIO hogging mechanism
On Mon, Jan 12, 2015 at 10:40:04AM +0100, Linus Walleij wrote: > On Tue, Dec 2, 2014 at 5:12 PM, Maxime Ripard > > We do have one board where we have a pin (let's say GPIO14 of the bank > > A) that enables a regulator that will provide VCC the bank B. > I think it's a hog in this case though, not a GPIO regulator, > definately not both. But let's check Mark's opinion on this. I'm lacking some context here but my first thought is that if VCC might be supplied by some other thing we need to use a regulator since otherwise we can't substitute in the other regulator. signature.asc Description: Digital signature
Re: [Patch v2 1/2] gpio: add GPIO hogging mechanism
On Tue, Dec 2, 2014 at 5:12 PM, Maxime Ripard wrote: > On Tue, Dec 02, 2014 at 03:29:46PM +0100, Linus Walleij wrote: >> On Tue, Dec 2, 2014 at 3:13 PM, Alexandre Courbot wrote: >> > On Tue, Dec 2, 2014 at 1:36 AM, Maxime Ripard >> > wrote: >> >> >> The only thing I'd like to have would be that the request here would >> >> be non-exclusive, so that a later driver would still be allowed later >> >> on to request that GPIO later on and manage it itself (ideally using >> >> the usual gpiod_request function). >> > >> > Actually we have a plan (and I have some code too) to allow multiple >> > consumers per GPIO. Although like Benoit I wonder why you would want >> > to hog a GPIO and then request it properly later. Also, that probably >> > means we should abandon the hog since it actively drives the line and >> > would interfere with the late requested. How to do that correctly is >> > not really clear to me. >> >> I don't get the usecase. A hogged GPIO is per definition hogged. >> This sounds more like "initial settings" or something, which is another >> usecase altogether. > > We do have one board where we have a pin (let's say GPIO14 of the bank > A) that enables a regulator that will provide VCC the bank B. > > Now, both banks are handled by the same driver, but in order to have a > working output on the bank B, we do need to set GPIO14 as soon as > we're probed. > > Just relying on the usual deferred probing introduces a circular > dependency between the gpio-regulator that needs to grab its GPIO from > a driver not there yet, and the gpio driver that needs to enable its > gpio-regulator. > > GPIO hogging needs to be the ideal solution for that, since we can > just enforce the GPIO14 value as the driver is probed, which provides > the guarantee that any driver using the bank B will actually drive the > GPIO it might use. > > However, an exclusive request will prevent any representation of this > as a regulator, which sounds a bit weird, since it really is just > that. Well that's elegant... I think it's a hog in this case though, not a GPIO regulator, definately not both. But let's check Mark's opinion on this. Yours, Linus Walleij -- 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/
Re: [Patch v2 1/2] gpio: add GPIO hogging mechanism
On Tue, Dec 2, 2014 at 5:12 PM, Maxime Ripard maxime.rip...@free-electrons.com wrote: On Tue, Dec 02, 2014 at 03:29:46PM +0100, Linus Walleij wrote: On Tue, Dec 2, 2014 at 3:13 PM, Alexandre Courbot gnu...@gmail.com wrote: On Tue, Dec 2, 2014 at 1:36 AM, Maxime Ripard maxime.rip...@free-electrons.com wrote: The only thing I'd like to have would be that the request here would be non-exclusive, so that a later driver would still be allowed later on to request that GPIO later on and manage it itself (ideally using the usual gpiod_request function). Actually we have a plan (and I have some code too) to allow multiple consumers per GPIO. Although like Benoit I wonder why you would want to hog a GPIO and then request it properly later. Also, that probably means we should abandon the hog since it actively drives the line and would interfere with the late requested. How to do that correctly is not really clear to me. I don't get the usecase. A hogged GPIO is per definition hogged. This sounds more like initial settings or something, which is another usecase altogether. We do have one board where we have a pin (let's say GPIO14 of the bank A) that enables a regulator that will provide VCC the bank B. Now, both banks are handled by the same driver, but in order to have a working output on the bank B, we do need to set GPIO14 as soon as we're probed. Just relying on the usual deferred probing introduces a circular dependency between the gpio-regulator that needs to grab its GPIO from a driver not there yet, and the gpio driver that needs to enable its gpio-regulator. GPIO hogging needs to be the ideal solution for that, since we can just enforce the GPIO14 value as the driver is probed, which provides the guarantee that any driver using the bank B will actually drive the GPIO it might use. However, an exclusive request will prevent any representation of this as a regulator, which sounds a bit weird, since it really is just that. Well that's elegant... I think it's a hog in this case though, not a GPIO regulator, definately not both. But let's check Mark's opinion on this. Yours, Linus Walleij -- 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/
Re: [Patch v2 1/2] gpio: add GPIO hogging mechanism
On Mon, Jan 12, 2015 at 10:40:04AM +0100, Linus Walleij wrote: On Tue, Dec 2, 2014 at 5:12 PM, Maxime Ripard We do have one board where we have a pin (let's say GPIO14 of the bank A) that enables a regulator that will provide VCC the bank B. I think it's a hog in this case though, not a GPIO regulator, definately not both. But let's check Mark's opinion on this. I'm lacking some context here but my first thought is that if VCC might be supplied by some other thing we need to use a regulator since otherwise we can't substitute in the other regulator. signature.asc Description: Digital signature
Re: [Patch v2 1/2] gpio: add GPIO hogging mechanism
On Sat, Dec 06, 2014 at 09:08:36PM +0900, Alexandre Courbot wrote: > On Fri, Dec 5, 2014 at 7:24 PM, Maxime Ripard > wrote: > > On Thu, Dec 04, 2014 at 11:49:19PM +0900, Alexandre Courbot wrote: > >> On Thu, Dec 4, 2014 at 11:27 PM, Maxime Ripard > >> wrote: > >> > Hi, > >> > > >> > On Thu, Dec 04, 2014 at 11:15:38PM +0900, Alexandre Courbot wrote: > >> >> On Wed, Dec 3, 2014 at 1:12 AM, Maxime Ripard > >> >> wrote: > >> >> > On Tue, Dec 02, 2014 at 03:29:46PM +0100, Linus Walleij wrote: > >> >> >> On Tue, Dec 2, 2014 at 3:13 PM, Alexandre Courbot > >> >> >> wrote: > >> >> >> > On Tue, Dec 2, 2014 at 1:36 AM, Maxime Ripard > >> >> >> > wrote: > >> >> >> > >> >> >> >> The only thing I'd like to have would be that the request here > >> >> >> >> would > >> >> >> >> be non-exclusive, so that a later driver would still be allowed > >> >> >> >> later > >> >> >> >> on to request that GPIO later on and manage it itself (ideally > >> >> >> >> using > >> >> >> >> the usual gpiod_request function). > >> >> >> > > >> >> >> > Actually we have a plan (and I have some code too) to allow > >> >> >> > multiple > >> >> >> > consumers per GPIO. Although like Benoit I wonder why you would > >> >> >> > want > >> >> >> > to hog a GPIO and then request it properly later. Also, that > >> >> >> > probably > >> >> >> > means we should abandon the hog since it actively drives the line > >> >> >> > and > >> >> >> > would interfere with the late requested. How to do that correctly > >> >> >> > is > >> >> >> > not really clear to me. > >> >> >> > >> >> >> I don't get the usecase. A hogged GPIO is per definition hogged. > >> >> >> This sounds more like "initial settings" or something, which is > >> >> >> another > >> >> >> usecase altogether. > >> >> > > >> >> > We do have one board where we have a pin (let's say GPIO14 of the bank > >> >> > A) that enables a regulator that will provide VCC the bank B. > >> >> > > >> >> > Now, both banks are handled by the same driver, but in order to have a > >> >> > working output on the bank B, we do need to set GPIO14 as soon as > >> >> > we're probed. > >> >> > > >> >> > Just relying on the usual deferred probing introduces a circular > >> >> > dependency between the gpio-regulator that needs to grab its GPIO from > >> >> > a driver not there yet, and the gpio driver that needs to enable its > >> >> > gpio-regulator. > >> >> > >> >> I don't get it. According to what you said, the following order should > >> >> go through IIUC: > >> >> > >> >> 1) bank A is probed, gpio 14 is available > >> >> 2) gpio-regulator is probed, acquires GPIO 14, regulator for Bank B is > >> >> available > >> >> 3) bank B is probed, grabs its regulator and turn it on, probes. > >> >> > >> >> What am I missing? > >> > > >> > It would be true if bank A and B were exposed through different > >> > drivers (or at least different instances of the same driver), which is > >> > not the case. > >> > > >> > In our case, banks A and B are handled by the same instance. > >> > >> Ok, so both banks A and B are part of the same device/DT node. Now I > >> think I understand the issue. You need to hog the pin so that bank B > >> will work right after the device is probed. > > > > Exactly. > > > >> But you will still have the problem that the regulator device will > >> *not* be available when your device is probed, so you cannot call > >> regulator_get() for bank B anyway. I guess your only choice is to hog > >> that pin and leave it active ad vitam eternam. > > > > Hmmm, indeed. > > > > I'll stop boring you with this then :) > > Please *keep* bothering us with any doubt you may have until they are > all cleared and you are sure this feature will be useful to you. > Especially since we are designing DT bindings that will have to be > carried over forever. We really want to get them right, and need input > of potential users for that. > > Having a few design arguments is a small thing compared to the hassle > of having to work with unadapted features and bindings. Ok. What I had in mind when I first thought about it was to set GPIO as hogged through the GPIO flags, and then have a dumb GPIO driver like Pantelis was suggesting. I don't know if hogged would still be the right term, but we could have that flag that would just allow the value to be set through gpio_request init value, and deny/cache any subsequent change through gpio_set_value. gpio_request with this flag would never return EPROBE_DEFER, and just cache the value to be set for when the driver comes in. We could enforce driver-less GPIOs through that dumb driver, and we would still be able to break weird dependency chains that end up in circle. That's just a thought though. Maxime -- Maxime Ripard, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com signature.asc Description: Digital signature
Re: [Patch v2 1/2] gpio: add GPIO hogging mechanism
On Sat, Dec 06, 2014 at 09:08:36PM +0900, Alexandre Courbot wrote: On Fri, Dec 5, 2014 at 7:24 PM, Maxime Ripard maxime.rip...@free-electrons.com wrote: On Thu, Dec 04, 2014 at 11:49:19PM +0900, Alexandre Courbot wrote: On Thu, Dec 4, 2014 at 11:27 PM, Maxime Ripard maxime.rip...@free-electrons.com wrote: Hi, On Thu, Dec 04, 2014 at 11:15:38PM +0900, Alexandre Courbot wrote: On Wed, Dec 3, 2014 at 1:12 AM, Maxime Ripard maxime.rip...@free-electrons.com wrote: On Tue, Dec 02, 2014 at 03:29:46PM +0100, Linus Walleij wrote: On Tue, Dec 2, 2014 at 3:13 PM, Alexandre Courbot gnu...@gmail.com wrote: On Tue, Dec 2, 2014 at 1:36 AM, Maxime Ripard maxime.rip...@free-electrons.com wrote: The only thing I'd like to have would be that the request here would be non-exclusive, so that a later driver would still be allowed later on to request that GPIO later on and manage it itself (ideally using the usual gpiod_request function). Actually we have a plan (and I have some code too) to allow multiple consumers per GPIO. Although like Benoit I wonder why you would want to hog a GPIO and then request it properly later. Also, that probably means we should abandon the hog since it actively drives the line and would interfere with the late requested. How to do that correctly is not really clear to me. I don't get the usecase. A hogged GPIO is per definition hogged. This sounds more like initial settings or something, which is another usecase altogether. We do have one board where we have a pin (let's say GPIO14 of the bank A) that enables a regulator that will provide VCC the bank B. Now, both banks are handled by the same driver, but in order to have a working output on the bank B, we do need to set GPIO14 as soon as we're probed. Just relying on the usual deferred probing introduces a circular dependency between the gpio-regulator that needs to grab its GPIO from a driver not there yet, and the gpio driver that needs to enable its gpio-regulator. I don't get it. According to what you said, the following order should go through IIUC: 1) bank A is probed, gpio 14 is available 2) gpio-regulator is probed, acquires GPIO 14, regulator for Bank B is available 3) bank B is probed, grabs its regulator and turn it on, probes. What am I missing? It would be true if bank A and B were exposed through different drivers (or at least different instances of the same driver), which is not the case. In our case, banks A and B are handled by the same instance. Ok, so both banks A and B are part of the same device/DT node. Now I think I understand the issue. You need to hog the pin so that bank B will work right after the device is probed. Exactly. But you will still have the problem that the regulator device will *not* be available when your device is probed, so you cannot call regulator_get() for bank B anyway. I guess your only choice is to hog that pin and leave it active ad vitam eternam. Hmmm, indeed. I'll stop boring you with this then :) Please *keep* bothering us with any doubt you may have until they are all cleared and you are sure this feature will be useful to you. Especially since we are designing DT bindings that will have to be carried over forever. We really want to get them right, and need input of potential users for that. Having a few design arguments is a small thing compared to the hassle of having to work with unadapted features and bindings. Ok. What I had in mind when I first thought about it was to set GPIO as hogged through the GPIO flags, and then have a dumb GPIO driver like Pantelis was suggesting. I don't know if hogged would still be the right term, but we could have that flag that would just allow the value to be set through gpio_request init value, and deny/cache any subsequent change through gpio_set_value. gpio_request with this flag would never return EPROBE_DEFER, and just cache the value to be set for when the driver comes in. We could enforce driver-less GPIOs through that dumb driver, and we would still be able to break weird dependency chains that end up in circle. That's just a thought though. Maxime -- Maxime Ripard, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com signature.asc Description: Digital signature
Re: [Patch v2 1/2] gpio: add GPIO hogging mechanism
On Fri, Dec 5, 2014 at 7:24 PM, Maxime Ripard wrote: > On Thu, Dec 04, 2014 at 11:49:19PM +0900, Alexandre Courbot wrote: >> On Thu, Dec 4, 2014 at 11:27 PM, Maxime Ripard >> wrote: >> > Hi, >> > >> > On Thu, Dec 04, 2014 at 11:15:38PM +0900, Alexandre Courbot wrote: >> >> On Wed, Dec 3, 2014 at 1:12 AM, Maxime Ripard >> >> wrote: >> >> > On Tue, Dec 02, 2014 at 03:29:46PM +0100, Linus Walleij wrote: >> >> >> On Tue, Dec 2, 2014 at 3:13 PM, Alexandre Courbot >> >> >> wrote: >> >> >> > On Tue, Dec 2, 2014 at 1:36 AM, Maxime Ripard >> >> >> > wrote: >> >> >> >> >> >> >> The only thing I'd like to have would be that the request here would >> >> >> >> be non-exclusive, so that a later driver would still be allowed >> >> >> >> later >> >> >> >> on to request that GPIO later on and manage it itself (ideally using >> >> >> >> the usual gpiod_request function). >> >> >> > >> >> >> > Actually we have a plan (and I have some code too) to allow multiple >> >> >> > consumers per GPIO. Although like Benoit I wonder why you would want >> >> >> > to hog a GPIO and then request it properly later. Also, that probably >> >> >> > means we should abandon the hog since it actively drives the line and >> >> >> > would interfere with the late requested. How to do that correctly is >> >> >> > not really clear to me. >> >> >> >> >> >> I don't get the usecase. A hogged GPIO is per definition hogged. >> >> >> This sounds more like "initial settings" or something, which is another >> >> >> usecase altogether. >> >> > >> >> > We do have one board where we have a pin (let's say GPIO14 of the bank >> >> > A) that enables a regulator that will provide VCC the bank B. >> >> > >> >> > Now, both banks are handled by the same driver, but in order to have a >> >> > working output on the bank B, we do need to set GPIO14 as soon as >> >> > we're probed. >> >> > >> >> > Just relying on the usual deferred probing introduces a circular >> >> > dependency between the gpio-regulator that needs to grab its GPIO from >> >> > a driver not there yet, and the gpio driver that needs to enable its >> >> > gpio-regulator. >> >> >> >> I don't get it. According to what you said, the following order should >> >> go through IIUC: >> >> >> >> 1) bank A is probed, gpio 14 is available >> >> 2) gpio-regulator is probed, acquires GPIO 14, regulator for Bank B is >> >> available >> >> 3) bank B is probed, grabs its regulator and turn it on, probes. >> >> >> >> What am I missing? >> > >> > It would be true if bank A and B were exposed through different >> > drivers (or at least different instances of the same driver), which is >> > not the case. >> > >> > In our case, banks A and B are handled by the same instance. >> >> Ok, so both banks A and B are part of the same device/DT node. Now I >> think I understand the issue. You need to hog the pin so that bank B >> will work right after the device is probed. > > Exactly. > >> But you will still have the problem that the regulator device will >> *not* be available when your device is probed, so you cannot call >> regulator_get() for bank B anyway. I guess your only choice is to hog >> that pin and leave it active ad vitam eternam. > > Hmmm, indeed. > > I'll stop boring you with this then :) Please *keep* bothering us with any doubt you may have until they are all cleared and you are sure this feature will be useful to you. Especially since we are designing DT bindings that will have to be carried over forever. We really want to get them right, and need input of potential users for that. Having a few design arguments is a small thing compared to the hassle of having to work with unadapted features and bindings. -- 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/
Re: [Patch v2 1/2] gpio: add GPIO hogging mechanism
On Fri, Dec 5, 2014 at 12:22 AM, Pantelis Antoniou wrote: > Hi Alexandre, > >> On Dec 4, 2014, at 17:10 , Alexandre Courbot wrote: >> >> On Fri, Dec 5, 2014 at 12:02 AM, Pantelis Antoniou >> wrote: >>> Hi Alexandre, >>> On Dec 4, 2014, at 16:58 , Alexandre Courbot wrote: On Thu, Dec 4, 2014 at 11:47 PM, Pantelis Antoniou wrote: > Hi Alexandre, > >> On Dec 4, 2014, at 16:41 , Alexandre Courbot wrote: >> >> On Thu, Dec 4, 2014 at 11:27 PM, Pantelis Antoniou >> wrote: >>> Hi Alexandre, >>> >>> I tried to stay away while things are being fleshed out but… >>> On Dec 4, 2014, at 16:15 , Alexandre Courbot wrote: On Wed, Dec 3, 2014 at 1:12 AM, Maxime Ripard wrote: > On Tue, Dec 02, 2014 at 03:29:46PM +0100, Linus Walleij wrote: >> On Tue, Dec 2, 2014 at 3:13 PM, Alexandre Courbot >> wrote: >>> On Tue, Dec 2, 2014 at 1:36 AM, Maxime Ripard >>> wrote: >> The only thing I'd like to have would be that the request here would be non-exclusive, so that a later driver would still be allowed later on to request that GPIO later on and manage it itself (ideally using the usual gpiod_request function). >>> >>> Actually we have a plan (and I have some code too) to allow multiple >>> consumers per GPIO. Although like Benoit I wonder why you would want >>> to hog a GPIO and then request it properly later. Also, that >>> probably >>> means we should abandon the hog since it actively drives the line >>> and >>> would interfere with the late requested. How to do that correctly is >>> not really clear to me. >> >> I don't get the usecase. A hogged GPIO is per definition hogged. >> This sounds more like "initial settings" or something, which is >> another >> usecase altogether. > > We do have one board where we have a pin (let's say GPIO14 of the bank > A) that enables a regulator that will provide VCC the bank B. > > Now, both banks are handled by the same driver, but in order to have a > working output on the bank B, we do need to set GPIO14 as soon as > we're probed. > > Just relying on the usual deferred probing introduces a circular > dependency between the gpio-regulator that needs to grab its GPIO from > a driver not there yet, and the gpio driver that needs to enable its > gpio-regulator. I don't get it. According to what you said, the following order should go through IIUC: 1) bank A is probed, gpio 14 is available 2) gpio-regulator is probed, acquires GPIO 14, regulator for Bank B is available 3) bank B is probed, grabs its regulator and turn it on, probes. What am I missing? > > GPIO hogging needs to be the ideal solution for that, since we can > just enforce the GPIO14 value as the driver is probed, which provides > the guarantee that any driver using the bank B will actually drive the > GPIO it might use. At this point I start wondering if such initial setup should not be the job of the bootloader? GPIO hogging ought to be simple and definitive, adding the possibility to have it just as an initial value would considerably complexify it. E.g. when is the gpio chip driver supposed to release the hogged descriptor in such a case? >>> >>> Do not count on the bootloader setting up anything. The trend is >>> for the bootloader to setup the minimal environment to load your kernel >>> and jump to it. >>> >>> http://www.denx.de/wiki/pub/U-Boot/MiniSummitELCE2013/2013-ELCE-U-Boot-Falcon-Boot.pdf >> >> Just wondering. :) >> >> But yeah, there are some use-cases (such as this one or >> Linux-as-a-bootloader) for which this would not play nicely. >> >>> >>> Note that if the multiple GPIO consumer feature we are planning goes through, you should be able to use both hogging *and* a regulator on the same GPIO and achieve what you want. The expectation of multiple consumers is that the board designers know what they are doing, and this case would certainly fit (chip hogs the line and doesn't touch the value after that, letting the regulator control it without any conflict afterwards), although it would of course be better to solve the issue through regular probing... >>> >>> >>> That’s why I was advocating a simple probing driver for all this. >>> Figure out a way for this driver to be probed first would be an easier >>> solution that
Re: [Patch v2 1/2] gpio: add GPIO hogging mechanism
On Fri, Dec 5, 2014 at 12:22 AM, Pantelis Antoniou pa...@antoniou-consulting.com wrote: Hi Alexandre, On Dec 4, 2014, at 17:10 , Alexandre Courbot gnu...@gmail.com wrote: On Fri, Dec 5, 2014 at 12:02 AM, Pantelis Antoniou pa...@antoniou-consulting.com wrote: Hi Alexandre, On Dec 4, 2014, at 16:58 , Alexandre Courbot gnu...@gmail.com wrote: On Thu, Dec 4, 2014 at 11:47 PM, Pantelis Antoniou pa...@antoniou-consulting.com wrote: Hi Alexandre, On Dec 4, 2014, at 16:41 , Alexandre Courbot gnu...@gmail.com wrote: On Thu, Dec 4, 2014 at 11:27 PM, Pantelis Antoniou pa...@antoniou-consulting.com wrote: Hi Alexandre, I tried to stay away while things are being fleshed out but… On Dec 4, 2014, at 16:15 , Alexandre Courbot gnu...@gmail.com wrote: On Wed, Dec 3, 2014 at 1:12 AM, Maxime Ripard maxime.rip...@free-electrons.com wrote: On Tue, Dec 02, 2014 at 03:29:46PM +0100, Linus Walleij wrote: On Tue, Dec 2, 2014 at 3:13 PM, Alexandre Courbot gnu...@gmail.com wrote: On Tue, Dec 2, 2014 at 1:36 AM, Maxime Ripard maxime.rip...@free-electrons.com wrote: The only thing I'd like to have would be that the request here would be non-exclusive, so that a later driver would still be allowed later on to request that GPIO later on and manage it itself (ideally using the usual gpiod_request function). Actually we have a plan (and I have some code too) to allow multiple consumers per GPIO. Although like Benoit I wonder why you would want to hog a GPIO and then request it properly later. Also, that probably means we should abandon the hog since it actively drives the line and would interfere with the late requested. How to do that correctly is not really clear to me. I don't get the usecase. A hogged GPIO is per definition hogged. This sounds more like initial settings or something, which is another usecase altogether. We do have one board where we have a pin (let's say GPIO14 of the bank A) that enables a regulator that will provide VCC the bank B. Now, both banks are handled by the same driver, but in order to have a working output on the bank B, we do need to set GPIO14 as soon as we're probed. Just relying on the usual deferred probing introduces a circular dependency between the gpio-regulator that needs to grab its GPIO from a driver not there yet, and the gpio driver that needs to enable its gpio-regulator. I don't get it. According to what you said, the following order should go through IIUC: 1) bank A is probed, gpio 14 is available 2) gpio-regulator is probed, acquires GPIO 14, regulator for Bank B is available 3) bank B is probed, grabs its regulator and turn it on, probes. What am I missing? GPIO hogging needs to be the ideal solution for that, since we can just enforce the GPIO14 value as the driver is probed, which provides the guarantee that any driver using the bank B will actually drive the GPIO it might use. At this point I start wondering if such initial setup should not be the job of the bootloader? GPIO hogging ought to be simple and definitive, adding the possibility to have it just as an initial value would considerably complexify it. E.g. when is the gpio chip driver supposed to release the hogged descriptor in such a case? Do not count on the bootloader setting up anything. The trend is for the bootloader to setup the minimal environment to load your kernel and jump to it. http://www.denx.de/wiki/pub/U-Boot/MiniSummitELCE2013/2013-ELCE-U-Boot-Falcon-Boot.pdf Just wondering. :) But yeah, there are some use-cases (such as this one or Linux-as-a-bootloader) for which this would not play nicely. Note that if the multiple GPIO consumer feature we are planning goes through, you should be able to use both hogging *and* a regulator on the same GPIO and achieve what you want. The expectation of multiple consumers is that the board designers know what they are doing, and this case would certainly fit (chip hogs the line and doesn't touch the value after that, letting the regulator control it without any conflict afterwards), although it would of course be better to solve the issue through regular probing... That’s why I was advocating a simple probing driver for all this. Figure out a way for this driver to be probed first would be an easier solution that what’s going on here. Do you mean, a driver whose sole job is to probe other drivers in the right order? :/ $DEITY no :) I mean instead of having the gpio hog in the gpio adapter driver, have a gpio-hog driver, that’s using an undisclosed method to make sure that it’s the first one to be probed afterwards. IIUC that would not solve this particular issue - here the GPIO controller is both a provider and (indirect) consumer of a GPIO for itself. If the hog is in a separate node, if would have to be probed from inside the probe() function of the GPIO controller to do the job, which would be the same effect as having the hogs directly
Re: [Patch v2 1/2] gpio: add GPIO hogging mechanism
On Fri, Dec 5, 2014 at 7:24 PM, Maxime Ripard maxime.rip...@free-electrons.com wrote: On Thu, Dec 04, 2014 at 11:49:19PM +0900, Alexandre Courbot wrote: On Thu, Dec 4, 2014 at 11:27 PM, Maxime Ripard maxime.rip...@free-electrons.com wrote: Hi, On Thu, Dec 04, 2014 at 11:15:38PM +0900, Alexandre Courbot wrote: On Wed, Dec 3, 2014 at 1:12 AM, Maxime Ripard maxime.rip...@free-electrons.com wrote: On Tue, Dec 02, 2014 at 03:29:46PM +0100, Linus Walleij wrote: On Tue, Dec 2, 2014 at 3:13 PM, Alexandre Courbot gnu...@gmail.com wrote: On Tue, Dec 2, 2014 at 1:36 AM, Maxime Ripard maxime.rip...@free-electrons.com wrote: The only thing I'd like to have would be that the request here would be non-exclusive, so that a later driver would still be allowed later on to request that GPIO later on and manage it itself (ideally using the usual gpiod_request function). Actually we have a plan (and I have some code too) to allow multiple consumers per GPIO. Although like Benoit I wonder why you would want to hog a GPIO and then request it properly later. Also, that probably means we should abandon the hog since it actively drives the line and would interfere with the late requested. How to do that correctly is not really clear to me. I don't get the usecase. A hogged GPIO is per definition hogged. This sounds more like initial settings or something, which is another usecase altogether. We do have one board where we have a pin (let's say GPIO14 of the bank A) that enables a regulator that will provide VCC the bank B. Now, both banks are handled by the same driver, but in order to have a working output on the bank B, we do need to set GPIO14 as soon as we're probed. Just relying on the usual deferred probing introduces a circular dependency between the gpio-regulator that needs to grab its GPIO from a driver not there yet, and the gpio driver that needs to enable its gpio-regulator. I don't get it. According to what you said, the following order should go through IIUC: 1) bank A is probed, gpio 14 is available 2) gpio-regulator is probed, acquires GPIO 14, regulator for Bank B is available 3) bank B is probed, grabs its regulator and turn it on, probes. What am I missing? It would be true if bank A and B were exposed through different drivers (or at least different instances of the same driver), which is not the case. In our case, banks A and B are handled by the same instance. Ok, so both banks A and B are part of the same device/DT node. Now I think I understand the issue. You need to hog the pin so that bank B will work right after the device is probed. Exactly. But you will still have the problem that the regulator device will *not* be available when your device is probed, so you cannot call regulator_get() for bank B anyway. I guess your only choice is to hog that pin and leave it active ad vitam eternam. Hmmm, indeed. I'll stop boring you with this then :) Please *keep* bothering us with any doubt you may have until they are all cleared and you are sure this feature will be useful to you. Especially since we are designing DT bindings that will have to be carried over forever. We really want to get them right, and need input of potential users for that. Having a few design arguments is a small thing compared to the hassle of having to work with unadapted features and bindings. -- 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/
Re: [Patch v2 1/2] gpio: add GPIO hogging mechanism
On Thu, Dec 04, 2014 at 11:49:19PM +0900, Alexandre Courbot wrote: > On Thu, Dec 4, 2014 at 11:27 PM, Maxime Ripard > wrote: > > Hi, > > > > On Thu, Dec 04, 2014 at 11:15:38PM +0900, Alexandre Courbot wrote: > >> On Wed, Dec 3, 2014 at 1:12 AM, Maxime Ripard > >> wrote: > >> > On Tue, Dec 02, 2014 at 03:29:46PM +0100, Linus Walleij wrote: > >> >> On Tue, Dec 2, 2014 at 3:13 PM, Alexandre Courbot > >> >> wrote: > >> >> > On Tue, Dec 2, 2014 at 1:36 AM, Maxime Ripard > >> >> > wrote: > >> >> > >> >> >> The only thing I'd like to have would be that the request here would > >> >> >> be non-exclusive, so that a later driver would still be allowed later > >> >> >> on to request that GPIO later on and manage it itself (ideally using > >> >> >> the usual gpiod_request function). > >> >> > > >> >> > Actually we have a plan (and I have some code too) to allow multiple > >> >> > consumers per GPIO. Although like Benoit I wonder why you would want > >> >> > to hog a GPIO and then request it properly later. Also, that probably > >> >> > means we should abandon the hog since it actively drives the line and > >> >> > would interfere with the late requested. How to do that correctly is > >> >> > not really clear to me. > >> >> > >> >> I don't get the usecase. A hogged GPIO is per definition hogged. > >> >> This sounds more like "initial settings" or something, which is another > >> >> usecase altogether. > >> > > >> > We do have one board where we have a pin (let's say GPIO14 of the bank > >> > A) that enables a regulator that will provide VCC the bank B. > >> > > >> > Now, both banks are handled by the same driver, but in order to have a > >> > working output on the bank B, we do need to set GPIO14 as soon as > >> > we're probed. > >> > > >> > Just relying on the usual deferred probing introduces a circular > >> > dependency between the gpio-regulator that needs to grab its GPIO from > >> > a driver not there yet, and the gpio driver that needs to enable its > >> > gpio-regulator. > >> > >> I don't get it. According to what you said, the following order should > >> go through IIUC: > >> > >> 1) bank A is probed, gpio 14 is available > >> 2) gpio-regulator is probed, acquires GPIO 14, regulator for Bank B is > >> available > >> 3) bank B is probed, grabs its regulator and turn it on, probes. > >> > >> What am I missing? > > > > It would be true if bank A and B were exposed through different > > drivers (or at least different instances of the same driver), which is > > not the case. > > > > In our case, banks A and B are handled by the same instance. > > Ok, so both banks A and B are part of the same device/DT node. Now I > think I understand the issue. You need to hog the pin so that bank B > will work right after the device is probed. Exactly. > But you will still have the problem that the regulator device will > *not* be available when your device is probed, so you cannot call > regulator_get() for bank B anyway. I guess your only choice is to hog > that pin and leave it active ad vitam eternam. Hmmm, indeed. I'll stop boring you with this then :) Maxime -- Maxime Ripard, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com signature.asc Description: Digital signature
Re: [Patch v2 1/2] gpio: add GPIO hogging mechanism
On Thu, Dec 04, 2014 at 11:49:19PM +0900, Alexandre Courbot wrote: On Thu, Dec 4, 2014 at 11:27 PM, Maxime Ripard maxime.rip...@free-electrons.com wrote: Hi, On Thu, Dec 04, 2014 at 11:15:38PM +0900, Alexandre Courbot wrote: On Wed, Dec 3, 2014 at 1:12 AM, Maxime Ripard maxime.rip...@free-electrons.com wrote: On Tue, Dec 02, 2014 at 03:29:46PM +0100, Linus Walleij wrote: On Tue, Dec 2, 2014 at 3:13 PM, Alexandre Courbot gnu...@gmail.com wrote: On Tue, Dec 2, 2014 at 1:36 AM, Maxime Ripard maxime.rip...@free-electrons.com wrote: The only thing I'd like to have would be that the request here would be non-exclusive, so that a later driver would still be allowed later on to request that GPIO later on and manage it itself (ideally using the usual gpiod_request function). Actually we have a plan (and I have some code too) to allow multiple consumers per GPIO. Although like Benoit I wonder why you would want to hog a GPIO and then request it properly later. Also, that probably means we should abandon the hog since it actively drives the line and would interfere with the late requested. How to do that correctly is not really clear to me. I don't get the usecase. A hogged GPIO is per definition hogged. This sounds more like initial settings or something, which is another usecase altogether. We do have one board where we have a pin (let's say GPIO14 of the bank A) that enables a regulator that will provide VCC the bank B. Now, both banks are handled by the same driver, but in order to have a working output on the bank B, we do need to set GPIO14 as soon as we're probed. Just relying on the usual deferred probing introduces a circular dependency between the gpio-regulator that needs to grab its GPIO from a driver not there yet, and the gpio driver that needs to enable its gpio-regulator. I don't get it. According to what you said, the following order should go through IIUC: 1) bank A is probed, gpio 14 is available 2) gpio-regulator is probed, acquires GPIO 14, regulator for Bank B is available 3) bank B is probed, grabs its regulator and turn it on, probes. What am I missing? It would be true if bank A and B were exposed through different drivers (or at least different instances of the same driver), which is not the case. In our case, banks A and B are handled by the same instance. Ok, so both banks A and B are part of the same device/DT node. Now I think I understand the issue. You need to hog the pin so that bank B will work right after the device is probed. Exactly. But you will still have the problem that the regulator device will *not* be available when your device is probed, so you cannot call regulator_get() for bank B anyway. I guess your only choice is to hog that pin and leave it active ad vitam eternam. Hmmm, indeed. I'll stop boring you with this then :) Maxime -- Maxime Ripard, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com signature.asc Description: Digital signature
Re: [Patch v2 1/2] gpio: add GPIO hogging mechanism
Hi Alexandre, > On Dec 4, 2014, at 17:10 , Alexandre Courbot wrote: > > On Fri, Dec 5, 2014 at 12:02 AM, Pantelis Antoniou > wrote: >> Hi Alexandre, >> >>> On Dec 4, 2014, at 16:58 , Alexandre Courbot wrote: >>> >>> On Thu, Dec 4, 2014 at 11:47 PM, Pantelis Antoniou >>> wrote: Hi Alexandre, > On Dec 4, 2014, at 16:41 , Alexandre Courbot wrote: > > On Thu, Dec 4, 2014 at 11:27 PM, Pantelis Antoniou > wrote: >> Hi Alexandre, >> >> I tried to stay away while things are being fleshed out but… >> >>> On Dec 4, 2014, at 16:15 , Alexandre Courbot wrote: >>> >>> On Wed, Dec 3, 2014 at 1:12 AM, Maxime Ripard >>> wrote: On Tue, Dec 02, 2014 at 03:29:46PM +0100, Linus Walleij wrote: > On Tue, Dec 2, 2014 at 3:13 PM, Alexandre Courbot > wrote: >> On Tue, Dec 2, 2014 at 1:36 AM, Maxime Ripard >> wrote: > >>> The only thing I'd like to have would be that the request here would >>> be non-exclusive, so that a later driver would still be allowed >>> later >>> on to request that GPIO later on and manage it itself (ideally using >>> the usual gpiod_request function). >> >> Actually we have a plan (and I have some code too) to allow multiple >> consumers per GPIO. Although like Benoit I wonder why you would want >> to hog a GPIO and then request it properly later. Also, that probably >> means we should abandon the hog since it actively drives the line and >> would interfere with the late requested. How to do that correctly is >> not really clear to me. > > I don't get the usecase. A hogged GPIO is per definition hogged. > This sounds more like "initial settings" or something, which is > another > usecase altogether. We do have one board where we have a pin (let's say GPIO14 of the bank A) that enables a regulator that will provide VCC the bank B. Now, both banks are handled by the same driver, but in order to have a working output on the bank B, we do need to set GPIO14 as soon as we're probed. Just relying on the usual deferred probing introduces a circular dependency between the gpio-regulator that needs to grab its GPIO from a driver not there yet, and the gpio driver that needs to enable its gpio-regulator. >>> >>> I don't get it. According to what you said, the following order should >>> go through IIUC: >>> >>> 1) bank A is probed, gpio 14 is available >>> 2) gpio-regulator is probed, acquires GPIO 14, regulator for Bank B is >>> available >>> 3) bank B is probed, grabs its regulator and turn it on, probes. >>> >>> What am I missing? >>> GPIO hogging needs to be the ideal solution for that, since we can just enforce the GPIO14 value as the driver is probed, which provides the guarantee that any driver using the bank B will actually drive the GPIO it might use. >>> >>> At this point I start wondering if such initial setup should not be >>> the job of the bootloader? GPIO hogging ought to be simple and >>> definitive, adding the possibility to have it just as an initial value >>> would considerably complexify it. E.g. when is the gpio chip driver >>> supposed to release the hogged descriptor in such a case? >>> >> >> Do not count on the bootloader setting up anything. The trend is >> for the bootloader to setup the minimal environment to load your kernel >> and jump to it. >> >> http://www.denx.de/wiki/pub/U-Boot/MiniSummitELCE2013/2013-ELCE-U-Boot-Falcon-Boot.pdf > > Just wondering. :) > > But yeah, there are some use-cases (such as this one or > Linux-as-a-bootloader) for which this would not play nicely. > >> >> >>> Note that if the multiple GPIO consumer feature we are planning goes >>> through, you should be able to use both hogging *and* a regulator on >>> the same GPIO and achieve what you want. The expectation of multiple >>> consumers is that the board designers know what they are doing, and >>> this case would certainly fit (chip hogs the line and doesn't touch >>> the value after that, letting the regulator control it without any >>> conflict afterwards), although it would of course be better to solve >>> the issue through regular probing... >> >> >> That’s why I was advocating a simple probing driver for all this. >> Figure out a way for this driver to be probed first would be an easier >> solution that what’s going on here. > > Do you mean, a driver whose sole job is to probe other drivers in the > right order? :/ $DEITY no :) I mean instead of having the gpio hog
Re: [Patch v2 1/2] gpio: add GPIO hogging mechanism
On Fri, Dec 5, 2014 at 12:02 AM, Pantelis Antoniou wrote: > Hi Alexandre, > >> On Dec 4, 2014, at 16:58 , Alexandre Courbot wrote: >> >> On Thu, Dec 4, 2014 at 11:47 PM, Pantelis Antoniou >> wrote: >>> Hi Alexandre, >>> On Dec 4, 2014, at 16:41 , Alexandre Courbot wrote: On Thu, Dec 4, 2014 at 11:27 PM, Pantelis Antoniou wrote: > Hi Alexandre, > > I tried to stay away while things are being fleshed out but… > >> On Dec 4, 2014, at 16:15 , Alexandre Courbot wrote: >> >> On Wed, Dec 3, 2014 at 1:12 AM, Maxime Ripard >> wrote: >>> On Tue, Dec 02, 2014 at 03:29:46PM +0100, Linus Walleij wrote: On Tue, Dec 2, 2014 at 3:13 PM, Alexandre Courbot wrote: > On Tue, Dec 2, 2014 at 1:36 AM, Maxime Ripard > wrote: >> The only thing I'd like to have would be that the request here would >> be non-exclusive, so that a later driver would still be allowed later >> on to request that GPIO later on and manage it itself (ideally using >> the usual gpiod_request function). > > Actually we have a plan (and I have some code too) to allow multiple > consumers per GPIO. Although like Benoit I wonder why you would want > to hog a GPIO and then request it properly later. Also, that probably > means we should abandon the hog since it actively drives the line and > would interfere with the late requested. How to do that correctly is > not really clear to me. I don't get the usecase. A hogged GPIO is per definition hogged. This sounds more like "initial settings" or something, which is another usecase altogether. >>> >>> We do have one board where we have a pin (let's say GPIO14 of the bank >>> A) that enables a regulator that will provide VCC the bank B. >>> >>> Now, both banks are handled by the same driver, but in order to have a >>> working output on the bank B, we do need to set GPIO14 as soon as >>> we're probed. >>> >>> Just relying on the usual deferred probing introduces a circular >>> dependency between the gpio-regulator that needs to grab its GPIO from >>> a driver not there yet, and the gpio driver that needs to enable its >>> gpio-regulator. >> >> I don't get it. According to what you said, the following order should >> go through IIUC: >> >> 1) bank A is probed, gpio 14 is available >> 2) gpio-regulator is probed, acquires GPIO 14, regulator for Bank B is >> available >> 3) bank B is probed, grabs its regulator and turn it on, probes. >> >> What am I missing? >> >>> >>> GPIO hogging needs to be the ideal solution for that, since we can >>> just enforce the GPIO14 value as the driver is probed, which provides >>> the guarantee that any driver using the bank B will actually drive the >>> GPIO it might use. >> >> At this point I start wondering if such initial setup should not be >> the job of the bootloader? GPIO hogging ought to be simple and >> definitive, adding the possibility to have it just as an initial value >> would considerably complexify it. E.g. when is the gpio chip driver >> supposed to release the hogged descriptor in such a case? >> > > Do not count on the bootloader setting up anything. The trend is > for the bootloader to setup the minimal environment to load your kernel > and jump to it. > > http://www.denx.de/wiki/pub/U-Boot/MiniSummitELCE2013/2013-ELCE-U-Boot-Falcon-Boot.pdf Just wondering. :) But yeah, there are some use-cases (such as this one or Linux-as-a-bootloader) for which this would not play nicely. > > >> Note that if the multiple GPIO consumer feature we are planning goes >> through, you should be able to use both hogging *and* a regulator on >> the same GPIO and achieve what you want. The expectation of multiple >> consumers is that the board designers know what they are doing, and >> this case would certainly fit (chip hogs the line and doesn't touch >> the value after that, letting the regulator control it without any >> conflict afterwards), although it would of course be better to solve >> the issue through regular probing... > > > That’s why I was advocating a simple probing driver for all this. > Figure out a way for this driver to be probed first would be an easier > solution that what’s going on here. Do you mean, a driver whose sole job is to probe other drivers in the right order? :/ >>> >>> $DEITY no :) >>> >>> I mean instead of having the gpio hog in the gpio adapter driver, have >>> a gpio-hog driver, that’s using an undisclosed method to make sure that >>> it’s the first one to be probed afterwards. >> >> IIUC that would not solve this particular issue - here the GPIO >> controller
Re: [Patch v2 1/2] gpio: add GPIO hogging mechanism
Hi Alexandre, > On Dec 4, 2014, at 16:58 , Alexandre Courbot wrote: > > On Thu, Dec 4, 2014 at 11:47 PM, Pantelis Antoniou > wrote: >> Hi Alexandre, >> >>> On Dec 4, 2014, at 16:41 , Alexandre Courbot wrote: >>> >>> On Thu, Dec 4, 2014 at 11:27 PM, Pantelis Antoniou >>> wrote: Hi Alexandre, I tried to stay away while things are being fleshed out but… > On Dec 4, 2014, at 16:15 , Alexandre Courbot wrote: > > On Wed, Dec 3, 2014 at 1:12 AM, Maxime Ripard > wrote: >> On Tue, Dec 02, 2014 at 03:29:46PM +0100, Linus Walleij wrote: >>> On Tue, Dec 2, 2014 at 3:13 PM, Alexandre Courbot >>> wrote: On Tue, Dec 2, 2014 at 1:36 AM, Maxime Ripard wrote: >>> > The only thing I'd like to have would be that the request here would > be non-exclusive, so that a later driver would still be allowed later > on to request that GPIO later on and manage it itself (ideally using > the usual gpiod_request function). Actually we have a plan (and I have some code too) to allow multiple consumers per GPIO. Although like Benoit I wonder why you would want to hog a GPIO and then request it properly later. Also, that probably means we should abandon the hog since it actively drives the line and would interfere with the late requested. How to do that correctly is not really clear to me. >>> >>> I don't get the usecase. A hogged GPIO is per definition hogged. >>> This sounds more like "initial settings" or something, which is another >>> usecase altogether. >> >> We do have one board where we have a pin (let's say GPIO14 of the bank >> A) that enables a regulator that will provide VCC the bank B. >> >> Now, both banks are handled by the same driver, but in order to have a >> working output on the bank B, we do need to set GPIO14 as soon as >> we're probed. >> >> Just relying on the usual deferred probing introduces a circular >> dependency between the gpio-regulator that needs to grab its GPIO from >> a driver not there yet, and the gpio driver that needs to enable its >> gpio-regulator. > > I don't get it. According to what you said, the following order should > go through IIUC: > > 1) bank A is probed, gpio 14 is available > 2) gpio-regulator is probed, acquires GPIO 14, regulator for Bank B is > available > 3) bank B is probed, grabs its regulator and turn it on, probes. > > What am I missing? > >> >> GPIO hogging needs to be the ideal solution for that, since we can >> just enforce the GPIO14 value as the driver is probed, which provides >> the guarantee that any driver using the bank B will actually drive the >> GPIO it might use. > > At this point I start wondering if such initial setup should not be > the job of the bootloader? GPIO hogging ought to be simple and > definitive, adding the possibility to have it just as an initial value > would considerably complexify it. E.g. when is the gpio chip driver > supposed to release the hogged descriptor in such a case? > Do not count on the bootloader setting up anything. The trend is for the bootloader to setup the minimal environment to load your kernel and jump to it. http://www.denx.de/wiki/pub/U-Boot/MiniSummitELCE2013/2013-ELCE-U-Boot-Falcon-Boot.pdf >>> >>> Just wondering. :) >>> >>> But yeah, there are some use-cases (such as this one or >>> Linux-as-a-bootloader) for which this would not play nicely. >>> > Note that if the multiple GPIO consumer feature we are planning goes > through, you should be able to use both hogging *and* a regulator on > the same GPIO and achieve what you want. The expectation of multiple > consumers is that the board designers know what they are doing, and > this case would certainly fit (chip hogs the line and doesn't touch > the value after that, letting the regulator control it without any > conflict afterwards), although it would of course be better to solve > the issue through regular probing... That’s why I was advocating a simple probing driver for all this. Figure out a way for this driver to be probed first would be an easier solution that what’s going on here. >>> >>> Do you mean, a driver whose sole job is to probe other drivers in the >>> right order? :/ >> >> $DEITY no :) >> >> I mean instead of having the gpio hog in the gpio adapter driver, have >> a gpio-hog driver, that’s using an undisclosed method to make sure that >> it’s the first one to be probed afterwards. > > IIUC that would not solve this particular issue - here the GPIO > controller is both a provider and (indirect) consumer of a GPIO for > itself. If the hog is in a separate node, if would have to be probed > from inside
Re: [Patch v2 1/2] gpio: add GPIO hogging mechanism
On Thu, Dec 4, 2014 at 11:52 PM, Maxime Ripard wrote: > Hi again, > > It looks like I missed some part of it. > > On Thu, Dec 04, 2014 at 11:15:38PM +0900, Alexandre Courbot wrote: >> > GPIO hogging needs to be the ideal solution for that, since we can >> > just enforce the GPIO14 value as the driver is probed, which provides >> > the guarantee that any driver using the bank B will actually drive the >> > GPIO it might use. >> >> At this point I start wondering if such initial setup should not be >> the job of the bootloader? GPIO hogging ought to be simple and >> definitive, adding the possibility to have it just as an initial value >> would considerably complexify it. E.g. when is the gpio chip driver >> supposed to release the hogged descriptor in such a case? > > Relying on the bootloader for such trivial (and critical) things may > not work at all. You don't always have the option to replace it, > either because you physically can't, or just because you don't have > any alternative. > > I agree that in general this is something that should go in the > bootloader, but we should have a way to deal with the case where it's > not done. > >> Note that if the multiple GPIO consumer feature we are planning goes >> through, you should be able to use both hogging *and* a regulator on >> the same GPIO and achieve what you want. The expectation of multiple >> consumers is that the board designers know what they are doing, and >> this case would certainly fit (chip hogs the line and doesn't touch >> the value after that, letting the regulator control it without any >> conflict afterwards), although it would of course be better to solve >> the issue through regular probing... > > If such an effort is on-going, then I'm totally fine waiting for it > and leaving that outside the hogging mechanism. As long as it works, > I'm happy. Ok. I just want to wait until the next -rc1 to make sure that the large GPIO array removal patch (on which the multiple consumers feature depend) did not break anything important, then I will submit it. -- 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/
Re: [Patch v2 1/2] gpio: add GPIO hogging mechanism
On Thu, Dec 4, 2014 at 11:47 PM, Pantelis Antoniou wrote: > Hi Alexandre, > >> On Dec 4, 2014, at 16:41 , Alexandre Courbot wrote: >> >> On Thu, Dec 4, 2014 at 11:27 PM, Pantelis Antoniou >> wrote: >>> Hi Alexandre, >>> >>> I tried to stay away while things are being fleshed out but… >>> On Dec 4, 2014, at 16:15 , Alexandre Courbot wrote: On Wed, Dec 3, 2014 at 1:12 AM, Maxime Ripard wrote: > On Tue, Dec 02, 2014 at 03:29:46PM +0100, Linus Walleij wrote: >> On Tue, Dec 2, 2014 at 3:13 PM, Alexandre Courbot >> wrote: >>> On Tue, Dec 2, 2014 at 1:36 AM, Maxime Ripard >>> wrote: >> The only thing I'd like to have would be that the request here would be non-exclusive, so that a later driver would still be allowed later on to request that GPIO later on and manage it itself (ideally using the usual gpiod_request function). >>> >>> Actually we have a plan (and I have some code too) to allow multiple >>> consumers per GPIO. Although like Benoit I wonder why you would want >>> to hog a GPIO and then request it properly later. Also, that probably >>> means we should abandon the hog since it actively drives the line and >>> would interfere with the late requested. How to do that correctly is >>> not really clear to me. >> >> I don't get the usecase. A hogged GPIO is per definition hogged. >> This sounds more like "initial settings" or something, which is another >> usecase altogether. > > We do have one board where we have a pin (let's say GPIO14 of the bank > A) that enables a regulator that will provide VCC the bank B. > > Now, both banks are handled by the same driver, but in order to have a > working output on the bank B, we do need to set GPIO14 as soon as > we're probed. > > Just relying on the usual deferred probing introduces a circular > dependency between the gpio-regulator that needs to grab its GPIO from > a driver not there yet, and the gpio driver that needs to enable its > gpio-regulator. I don't get it. According to what you said, the following order should go through IIUC: 1) bank A is probed, gpio 14 is available 2) gpio-regulator is probed, acquires GPIO 14, regulator for Bank B is available 3) bank B is probed, grabs its regulator and turn it on, probes. What am I missing? > > GPIO hogging needs to be the ideal solution for that, since we can > just enforce the GPIO14 value as the driver is probed, which provides > the guarantee that any driver using the bank B will actually drive the > GPIO it might use. At this point I start wondering if such initial setup should not be the job of the bootloader? GPIO hogging ought to be simple and definitive, adding the possibility to have it just as an initial value would considerably complexify it. E.g. when is the gpio chip driver supposed to release the hogged descriptor in such a case? >>> >>> Do not count on the bootloader setting up anything. The trend is >>> for the bootloader to setup the minimal environment to load your kernel >>> and jump to it. >>> >>> http://www.denx.de/wiki/pub/U-Boot/MiniSummitELCE2013/2013-ELCE-U-Boot-Falcon-Boot.pdf >> >> Just wondering. :) >> >> But yeah, there are some use-cases (such as this one or >> Linux-as-a-bootloader) for which this would not play nicely. >> >>> >>> Note that if the multiple GPIO consumer feature we are planning goes through, you should be able to use both hogging *and* a regulator on the same GPIO and achieve what you want. The expectation of multiple consumers is that the board designers know what they are doing, and this case would certainly fit (chip hogs the line and doesn't touch the value after that, letting the regulator control it without any conflict afterwards), although it would of course be better to solve the issue through regular probing... >>> >>> >>> That’s why I was advocating a simple probing driver for all this. >>> Figure out a way for this driver to be probed first would be an easier >>> solution that what’s going on here. >> >> Do you mean, a driver whose sole job is to probe other drivers in the >> right order? :/ > > $DEITY no :) > > I mean instead of having the gpio hog in the gpio adapter driver, have > a gpio-hog driver, that’s using an undisclosed method to make sure that > it’s the first one to be probed afterwards. IIUC that would not solve this particular issue - here the GPIO controller is both a provider and (indirect) consumer of a GPIO for itself. If the hog is in a separate node, if would have to be probed from inside the probe() function of the GPIO controller to do the job, which would be the same effect as having the hogs directly under the controller node, only with more hassle. Again, IIUC. >_< -- To unsubscribe from this list: send
Re: [Patch v2 1/2] gpio: add GPIO hogging mechanism
Hi again, It looks like I missed some part of it. On Thu, Dec 04, 2014 at 11:15:38PM +0900, Alexandre Courbot wrote: > > GPIO hogging needs to be the ideal solution for that, since we can > > just enforce the GPIO14 value as the driver is probed, which provides > > the guarantee that any driver using the bank B will actually drive the > > GPIO it might use. > > At this point I start wondering if such initial setup should not be > the job of the bootloader? GPIO hogging ought to be simple and > definitive, adding the possibility to have it just as an initial value > would considerably complexify it. E.g. when is the gpio chip driver > supposed to release the hogged descriptor in such a case? Relying on the bootloader for such trivial (and critical) things may not work at all. You don't always have the option to replace it, either because you physically can't, or just because you don't have any alternative. I agree that in general this is something that should go in the bootloader, but we should have a way to deal with the case where it's not done. > Note that if the multiple GPIO consumer feature we are planning goes > through, you should be able to use both hogging *and* a regulator on > the same GPIO and achieve what you want. The expectation of multiple > consumers is that the board designers know what they are doing, and > this case would certainly fit (chip hogs the line and doesn't touch > the value after that, letting the regulator control it without any > conflict afterwards), although it would of course be better to solve > the issue through regular probing... If such an effort is on-going, then I'm totally fine waiting for it and leaving that outside the hogging mechanism. As long as it works, I'm happy. Maxime -- Maxime Ripard, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com signature.asc Description: Digital signature
Re: [Patch v2 1/2] gpio: add GPIO hogging mechanism
On Thu, Dec 4, 2014 at 11:27 PM, Maxime Ripard wrote: > Hi, > > On Thu, Dec 04, 2014 at 11:15:38PM +0900, Alexandre Courbot wrote: >> On Wed, Dec 3, 2014 at 1:12 AM, Maxime Ripard >> wrote: >> > On Tue, Dec 02, 2014 at 03:29:46PM +0100, Linus Walleij wrote: >> >> On Tue, Dec 2, 2014 at 3:13 PM, Alexandre Courbot >> >> wrote: >> >> > On Tue, Dec 2, 2014 at 1:36 AM, Maxime Ripard >> >> > wrote: >> >> >> >> >> The only thing I'd like to have would be that the request here would >> >> >> be non-exclusive, so that a later driver would still be allowed later >> >> >> on to request that GPIO later on and manage it itself (ideally using >> >> >> the usual gpiod_request function). >> >> > >> >> > Actually we have a plan (and I have some code too) to allow multiple >> >> > consumers per GPIO. Although like Benoit I wonder why you would want >> >> > to hog a GPIO and then request it properly later. Also, that probably >> >> > means we should abandon the hog since it actively drives the line and >> >> > would interfere with the late requested. How to do that correctly is >> >> > not really clear to me. >> >> >> >> I don't get the usecase. A hogged GPIO is per definition hogged. >> >> This sounds more like "initial settings" or something, which is another >> >> usecase altogether. >> > >> > We do have one board where we have a pin (let's say GPIO14 of the bank >> > A) that enables a regulator that will provide VCC the bank B. >> > >> > Now, both banks are handled by the same driver, but in order to have a >> > working output on the bank B, we do need to set GPIO14 as soon as >> > we're probed. >> > >> > Just relying on the usual deferred probing introduces a circular >> > dependency between the gpio-regulator that needs to grab its GPIO from >> > a driver not there yet, and the gpio driver that needs to enable its >> > gpio-regulator. >> >> I don't get it. According to what you said, the following order should >> go through IIUC: >> >> 1) bank A is probed, gpio 14 is available >> 2) gpio-regulator is probed, acquires GPIO 14, regulator for Bank B is >> available >> 3) bank B is probed, grabs its regulator and turn it on, probes. >> >> What am I missing? > > It would be true if bank A and B were exposed through different > drivers (or at least different instances of the same driver), which is > not the case. > > In our case, banks A and B are handled by the same instance. Ok, so both banks A and B are part of the same device/DT node. Now I think I understand the issue. You need to hog the pin so that bank B will work right after the device is probed. But you will still have the problem that the regulator device will *not* be available when your device is probed, so you cannot call regulator_get() for bank B anyway. I guess your only choice is to hog that pin and leave it active ad vitam eternam. -- 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/
Re: [Patch v2 1/2] gpio: add GPIO hogging mechanism
Hi Alexandre, > On Dec 4, 2014, at 16:41 , Alexandre Courbot wrote: > > On Thu, Dec 4, 2014 at 11:27 PM, Pantelis Antoniou > wrote: >> Hi Alexandre, >> >> I tried to stay away while things are being fleshed out but… >> >>> On Dec 4, 2014, at 16:15 , Alexandre Courbot wrote: >>> >>> On Wed, Dec 3, 2014 at 1:12 AM, Maxime Ripard >>> wrote: On Tue, Dec 02, 2014 at 03:29:46PM +0100, Linus Walleij wrote: > On Tue, Dec 2, 2014 at 3:13 PM, Alexandre Courbot > wrote: >> On Tue, Dec 2, 2014 at 1:36 AM, Maxime Ripard >> wrote: > >>> The only thing I'd like to have would be that the request here would >>> be non-exclusive, so that a later driver would still be allowed later >>> on to request that GPIO later on and manage it itself (ideally using >>> the usual gpiod_request function). >> >> Actually we have a plan (and I have some code too) to allow multiple >> consumers per GPIO. Although like Benoit I wonder why you would want >> to hog a GPIO and then request it properly later. Also, that probably >> means we should abandon the hog since it actively drives the line and >> would interfere with the late requested. How to do that correctly is >> not really clear to me. > > I don't get the usecase. A hogged GPIO is per definition hogged. > This sounds more like "initial settings" or something, which is another > usecase altogether. We do have one board where we have a pin (let's say GPIO14 of the bank A) that enables a regulator that will provide VCC the bank B. Now, both banks are handled by the same driver, but in order to have a working output on the bank B, we do need to set GPIO14 as soon as we're probed. Just relying on the usual deferred probing introduces a circular dependency between the gpio-regulator that needs to grab its GPIO from a driver not there yet, and the gpio driver that needs to enable its gpio-regulator. >>> >>> I don't get it. According to what you said, the following order should >>> go through IIUC: >>> >>> 1) bank A is probed, gpio 14 is available >>> 2) gpio-regulator is probed, acquires GPIO 14, regulator for Bank B is >>> available >>> 3) bank B is probed, grabs its regulator and turn it on, probes. >>> >>> What am I missing? >>> GPIO hogging needs to be the ideal solution for that, since we can just enforce the GPIO14 value as the driver is probed, which provides the guarantee that any driver using the bank B will actually drive the GPIO it might use. >>> >>> At this point I start wondering if such initial setup should not be >>> the job of the bootloader? GPIO hogging ought to be simple and >>> definitive, adding the possibility to have it just as an initial value >>> would considerably complexify it. E.g. when is the gpio chip driver >>> supposed to release the hogged descriptor in such a case? >>> >> >> Do not count on the bootloader setting up anything. The trend is >> for the bootloader to setup the minimal environment to load your kernel >> and jump to it. >> >> http://www.denx.de/wiki/pub/U-Boot/MiniSummitELCE2013/2013-ELCE-U-Boot-Falcon-Boot.pdf > > Just wondering. :) > > But yeah, there are some use-cases (such as this one or > Linux-as-a-bootloader) for which this would not play nicely. > >> >> >>> Note that if the multiple GPIO consumer feature we are planning goes >>> through, you should be able to use both hogging *and* a regulator on >>> the same GPIO and achieve what you want. The expectation of multiple >>> consumers is that the board designers know what they are doing, and >>> this case would certainly fit (chip hogs the line and doesn't touch >>> the value after that, letting the regulator control it without any >>> conflict afterwards), although it would of course be better to solve >>> the issue through regular probing... >> >> >> That’s why I was advocating a simple probing driver for all this. >> Figure out a way for this driver to be probed first would be an easier >> solution that what’s going on here. > > Do you mean, a driver whose sole job is to probe other drivers in the > right order? :/ $DEITY no :) I mean instead of having the gpio hog in the gpio adapter driver, have a gpio-hog driver, that’s using an undisclosed method to make sure that it’s the first one to be probed afterwards. We can probably do it using DT. Or maybe using the proposed gpio hog method doesn’t cover every case. I don’t know, that’s why we’re spending time talking about this :) Regards — pantelis -- 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/
Re: [Patch v2 1/2] gpio: add GPIO hogging mechanism
On Thu, Dec 4, 2014 at 11:27 PM, Pantelis Antoniou wrote: > Hi Alexandre, > > I tried to stay away while things are being fleshed out but… > >> On Dec 4, 2014, at 16:15 , Alexandre Courbot wrote: >> >> On Wed, Dec 3, 2014 at 1:12 AM, Maxime Ripard >> wrote: >>> On Tue, Dec 02, 2014 at 03:29:46PM +0100, Linus Walleij wrote: On Tue, Dec 2, 2014 at 3:13 PM, Alexandre Courbot wrote: > On Tue, Dec 2, 2014 at 1:36 AM, Maxime Ripard > wrote: >> The only thing I'd like to have would be that the request here would >> be non-exclusive, so that a later driver would still be allowed later >> on to request that GPIO later on and manage it itself (ideally using >> the usual gpiod_request function). > > Actually we have a plan (and I have some code too) to allow multiple > consumers per GPIO. Although like Benoit I wonder why you would want > to hog a GPIO and then request it properly later. Also, that probably > means we should abandon the hog since it actively drives the line and > would interfere with the late requested. How to do that correctly is > not really clear to me. I don't get the usecase. A hogged GPIO is per definition hogged. This sounds more like "initial settings" or something, which is another usecase altogether. >>> >>> We do have one board where we have a pin (let's say GPIO14 of the bank >>> A) that enables a regulator that will provide VCC the bank B. >>> >>> Now, both banks are handled by the same driver, but in order to have a >>> working output on the bank B, we do need to set GPIO14 as soon as >>> we're probed. >>> >>> Just relying on the usual deferred probing introduces a circular >>> dependency between the gpio-regulator that needs to grab its GPIO from >>> a driver not there yet, and the gpio driver that needs to enable its >>> gpio-regulator. >> >> I don't get it. According to what you said, the following order should >> go through IIUC: >> >> 1) bank A is probed, gpio 14 is available >> 2) gpio-regulator is probed, acquires GPIO 14, regulator for Bank B is >> available >> 3) bank B is probed, grabs its regulator and turn it on, probes. >> >> What am I missing? >> >>> >>> GPIO hogging needs to be the ideal solution for that, since we can >>> just enforce the GPIO14 value as the driver is probed, which provides >>> the guarantee that any driver using the bank B will actually drive the >>> GPIO it might use. >> >> At this point I start wondering if such initial setup should not be >> the job of the bootloader? GPIO hogging ought to be simple and >> definitive, adding the possibility to have it just as an initial value >> would considerably complexify it. E.g. when is the gpio chip driver >> supposed to release the hogged descriptor in such a case? >> > > Do not count on the bootloader setting up anything. The trend is > for the bootloader to setup the minimal environment to load your kernel > and jump to it. > > http://www.denx.de/wiki/pub/U-Boot/MiniSummitELCE2013/2013-ELCE-U-Boot-Falcon-Boot.pdf Just wondering. :) But yeah, there are some use-cases (such as this one or Linux-as-a-bootloader) for which this would not play nicely. > > >> Note that if the multiple GPIO consumer feature we are planning goes >> through, you should be able to use both hogging *and* a regulator on >> the same GPIO and achieve what you want. The expectation of multiple >> consumers is that the board designers know what they are doing, and >> this case would certainly fit (chip hogs the line and doesn't touch >> the value after that, letting the regulator control it without any >> conflict afterwards), although it would of course be better to solve >> the issue through regular probing... > > > That’s why I was advocating a simple probing driver for all this. > Figure out a way for this driver to be probed first would be an easier > solution that what’s going on here. Do you mean, a driver whose sole job is to probe other drivers in the right order? :/ -- 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/
Re: [Patch v2 1/2] gpio: add GPIO hogging mechanism
Hi, On Thu, Dec 04, 2014 at 11:15:38PM +0900, Alexandre Courbot wrote: > On Wed, Dec 3, 2014 at 1:12 AM, Maxime Ripard > wrote: > > On Tue, Dec 02, 2014 at 03:29:46PM +0100, Linus Walleij wrote: > >> On Tue, Dec 2, 2014 at 3:13 PM, Alexandre Courbot wrote: > >> > On Tue, Dec 2, 2014 at 1:36 AM, Maxime Ripard > >> > wrote: > >> > >> >> The only thing I'd like to have would be that the request here would > >> >> be non-exclusive, so that a later driver would still be allowed later > >> >> on to request that GPIO later on and manage it itself (ideally using > >> >> the usual gpiod_request function). > >> > > >> > Actually we have a plan (and I have some code too) to allow multiple > >> > consumers per GPIO. Although like Benoit I wonder why you would want > >> > to hog a GPIO and then request it properly later. Also, that probably > >> > means we should abandon the hog since it actively drives the line and > >> > would interfere with the late requested. How to do that correctly is > >> > not really clear to me. > >> > >> I don't get the usecase. A hogged GPIO is per definition hogged. > >> This sounds more like "initial settings" or something, which is another > >> usecase altogether. > > > > We do have one board where we have a pin (let's say GPIO14 of the bank > > A) that enables a regulator that will provide VCC the bank B. > > > > Now, both banks are handled by the same driver, but in order to have a > > working output on the bank B, we do need to set GPIO14 as soon as > > we're probed. > > > > Just relying on the usual deferred probing introduces a circular > > dependency between the gpio-regulator that needs to grab its GPIO from > > a driver not there yet, and the gpio driver that needs to enable its > > gpio-regulator. > > I don't get it. According to what you said, the following order should > go through IIUC: > > 1) bank A is probed, gpio 14 is available > 2) gpio-regulator is probed, acquires GPIO 14, regulator for Bank B is > available > 3) bank B is probed, grabs its regulator and turn it on, probes. > > What am I missing? It would be true if bank A and B were exposed through different drivers (or at least different instances of the same driver), which is not the case. In our case, banks A and B are handled by the same instance. Maxime -- Maxime Ripard, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com signature.asc Description: Digital signature
Re: [Patch v2 1/2] gpio: add GPIO hogging mechanism
Hi Alexandre, I tried to stay away while things are being fleshed out but… > On Dec 4, 2014, at 16:15 , Alexandre Courbot wrote: > > On Wed, Dec 3, 2014 at 1:12 AM, Maxime Ripard > wrote: >> On Tue, Dec 02, 2014 at 03:29:46PM +0100, Linus Walleij wrote: >>> On Tue, Dec 2, 2014 at 3:13 PM, Alexandre Courbot wrote: On Tue, Dec 2, 2014 at 1:36 AM, Maxime Ripard wrote: >>> > The only thing I'd like to have would be that the request here would > be non-exclusive, so that a later driver would still be allowed later > on to request that GPIO later on and manage it itself (ideally using > the usual gpiod_request function). Actually we have a plan (and I have some code too) to allow multiple consumers per GPIO. Although like Benoit I wonder why you would want to hog a GPIO and then request it properly later. Also, that probably means we should abandon the hog since it actively drives the line and would interfere with the late requested. How to do that correctly is not really clear to me. >>> >>> I don't get the usecase. A hogged GPIO is per definition hogged. >>> This sounds more like "initial settings" or something, which is another >>> usecase altogether. >> >> We do have one board where we have a pin (let's say GPIO14 of the bank >> A) that enables a regulator that will provide VCC the bank B. >> >> Now, both banks are handled by the same driver, but in order to have a >> working output on the bank B, we do need to set GPIO14 as soon as >> we're probed. >> >> Just relying on the usual deferred probing introduces a circular >> dependency between the gpio-regulator that needs to grab its GPIO from >> a driver not there yet, and the gpio driver that needs to enable its >> gpio-regulator. > > I don't get it. According to what you said, the following order should > go through IIUC: > > 1) bank A is probed, gpio 14 is available > 2) gpio-regulator is probed, acquires GPIO 14, regulator for Bank B is > available > 3) bank B is probed, grabs its regulator and turn it on, probes. > > What am I missing? > >> >> GPIO hogging needs to be the ideal solution for that, since we can >> just enforce the GPIO14 value as the driver is probed, which provides >> the guarantee that any driver using the bank B will actually drive the >> GPIO it might use. > > At this point I start wondering if such initial setup should not be > the job of the bootloader? GPIO hogging ought to be simple and > definitive, adding the possibility to have it just as an initial value > would considerably complexify it. E.g. when is the gpio chip driver > supposed to release the hogged descriptor in such a case? > Do not count on the bootloader setting up anything. The trend is for the bootloader to setup the minimal environment to load your kernel and jump to it. http://www.denx.de/wiki/pub/U-Boot/MiniSummitELCE2013/2013-ELCE-U-Boot-Falcon-Boot.pdf > Note that if the multiple GPIO consumer feature we are planning goes > through, you should be able to use both hogging *and* a regulator on > the same GPIO and achieve what you want. The expectation of multiple > consumers is that the board designers know what they are doing, and > this case would certainly fit (chip hogs the line and doesn't touch > the value after that, letting the regulator control it without any > conflict afterwards), although it would of course be better to solve > the issue through regular probing... That’s why I was advocating a simple probing driver for all this. Figure out a way for this driver to be probed first would be an easier solution that what’s going on here. Regards — Pantelis -- 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/
Re: [Patch v2 1/2] gpio: add GPIO hogging mechanism
On Wed, Dec 3, 2014 at 1:12 AM, Maxime Ripard wrote: > On Tue, Dec 02, 2014 at 03:29:46PM +0100, Linus Walleij wrote: >> On Tue, Dec 2, 2014 at 3:13 PM, Alexandre Courbot wrote: >> > On Tue, Dec 2, 2014 at 1:36 AM, Maxime Ripard >> > wrote: >> >> >> The only thing I'd like to have would be that the request here would >> >> be non-exclusive, so that a later driver would still be allowed later >> >> on to request that GPIO later on and manage it itself (ideally using >> >> the usual gpiod_request function). >> > >> > Actually we have a plan (and I have some code too) to allow multiple >> > consumers per GPIO. Although like Benoit I wonder why you would want >> > to hog a GPIO and then request it properly later. Also, that probably >> > means we should abandon the hog since it actively drives the line and >> > would interfere with the late requested. How to do that correctly is >> > not really clear to me. >> >> I don't get the usecase. A hogged GPIO is per definition hogged. >> This sounds more like "initial settings" or something, which is another >> usecase altogether. > > We do have one board where we have a pin (let's say GPIO14 of the bank > A) that enables a regulator that will provide VCC the bank B. > > Now, both banks are handled by the same driver, but in order to have a > working output on the bank B, we do need to set GPIO14 as soon as > we're probed. > > Just relying on the usual deferred probing introduces a circular > dependency between the gpio-regulator that needs to grab its GPIO from > a driver not there yet, and the gpio driver that needs to enable its > gpio-regulator. I don't get it. According to what you said, the following order should go through IIUC: 1) bank A is probed, gpio 14 is available 2) gpio-regulator is probed, acquires GPIO 14, regulator for Bank B is available 3) bank B is probed, grabs its regulator and turn it on, probes. What am I missing? > > GPIO hogging needs to be the ideal solution for that, since we can > just enforce the GPIO14 value as the driver is probed, which provides > the guarantee that any driver using the bank B will actually drive the > GPIO it might use. At this point I start wondering if such initial setup should not be the job of the bootloader? GPIO hogging ought to be simple and definitive, adding the possibility to have it just as an initial value would considerably complexify it. E.g. when is the gpio chip driver supposed to release the hogged descriptor in such a case? Note that if the multiple GPIO consumer feature we are planning goes through, you should be able to use both hogging *and* a regulator on the same GPIO and achieve what you want. The expectation of multiple consumers is that the board designers know what they are doing, and this case would certainly fit (chip hogs the line and doesn't touch the value after that, letting the regulator control it without any conflict afterwards), although it would of course be better to solve the issue through regular probing... -- 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/
Re: [Patch v2 1/2] gpio: add GPIO hogging mechanism
On Wed, Dec 3, 2014 at 1:12 AM, Maxime Ripard maxime.rip...@free-electrons.com wrote: On Tue, Dec 02, 2014 at 03:29:46PM +0100, Linus Walleij wrote: On Tue, Dec 2, 2014 at 3:13 PM, Alexandre Courbot gnu...@gmail.com wrote: On Tue, Dec 2, 2014 at 1:36 AM, Maxime Ripard maxime.rip...@free-electrons.com wrote: The only thing I'd like to have would be that the request here would be non-exclusive, so that a later driver would still be allowed later on to request that GPIO later on and manage it itself (ideally using the usual gpiod_request function). Actually we have a plan (and I have some code too) to allow multiple consumers per GPIO. Although like Benoit I wonder why you would want to hog a GPIO and then request it properly later. Also, that probably means we should abandon the hog since it actively drives the line and would interfere with the late requested. How to do that correctly is not really clear to me. I don't get the usecase. A hogged GPIO is per definition hogged. This sounds more like initial settings or something, which is another usecase altogether. We do have one board where we have a pin (let's say GPIO14 of the bank A) that enables a regulator that will provide VCC the bank B. Now, both banks are handled by the same driver, but in order to have a working output on the bank B, we do need to set GPIO14 as soon as we're probed. Just relying on the usual deferred probing introduces a circular dependency between the gpio-regulator that needs to grab its GPIO from a driver not there yet, and the gpio driver that needs to enable its gpio-regulator. I don't get it. According to what you said, the following order should go through IIUC: 1) bank A is probed, gpio 14 is available 2) gpio-regulator is probed, acquires GPIO 14, regulator for Bank B is available 3) bank B is probed, grabs its regulator and turn it on, probes. What am I missing? GPIO hogging needs to be the ideal solution for that, since we can just enforce the GPIO14 value as the driver is probed, which provides the guarantee that any driver using the bank B will actually drive the GPIO it might use. At this point I start wondering if such initial setup should not be the job of the bootloader? GPIO hogging ought to be simple and definitive, adding the possibility to have it just as an initial value would considerably complexify it. E.g. when is the gpio chip driver supposed to release the hogged descriptor in such a case? Note that if the multiple GPIO consumer feature we are planning goes through, you should be able to use both hogging *and* a regulator on the same GPIO and achieve what you want. The expectation of multiple consumers is that the board designers know what they are doing, and this case would certainly fit (chip hogs the line and doesn't touch the value after that, letting the regulator control it without any conflict afterwards), although it would of course be better to solve the issue through regular probing... -- 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/
Re: [Patch v2 1/2] gpio: add GPIO hogging mechanism
Hi Alexandre, I tried to stay away while things are being fleshed out but… On Dec 4, 2014, at 16:15 , Alexandre Courbot gnu...@gmail.com wrote: On Wed, Dec 3, 2014 at 1:12 AM, Maxime Ripard maxime.rip...@free-electrons.com wrote: On Tue, Dec 02, 2014 at 03:29:46PM +0100, Linus Walleij wrote: On Tue, Dec 2, 2014 at 3:13 PM, Alexandre Courbot gnu...@gmail.com wrote: On Tue, Dec 2, 2014 at 1:36 AM, Maxime Ripard maxime.rip...@free-electrons.com wrote: The only thing I'd like to have would be that the request here would be non-exclusive, so that a later driver would still be allowed later on to request that GPIO later on and manage it itself (ideally using the usual gpiod_request function). Actually we have a plan (and I have some code too) to allow multiple consumers per GPIO. Although like Benoit I wonder why you would want to hog a GPIO and then request it properly later. Also, that probably means we should abandon the hog since it actively drives the line and would interfere with the late requested. How to do that correctly is not really clear to me. I don't get the usecase. A hogged GPIO is per definition hogged. This sounds more like initial settings or something, which is another usecase altogether. We do have one board where we have a pin (let's say GPIO14 of the bank A) that enables a regulator that will provide VCC the bank B. Now, both banks are handled by the same driver, but in order to have a working output on the bank B, we do need to set GPIO14 as soon as we're probed. Just relying on the usual deferred probing introduces a circular dependency between the gpio-regulator that needs to grab its GPIO from a driver not there yet, and the gpio driver that needs to enable its gpio-regulator. I don't get it. According to what you said, the following order should go through IIUC: 1) bank A is probed, gpio 14 is available 2) gpio-regulator is probed, acquires GPIO 14, regulator for Bank B is available 3) bank B is probed, grabs its regulator and turn it on, probes. What am I missing? GPIO hogging needs to be the ideal solution for that, since we can just enforce the GPIO14 value as the driver is probed, which provides the guarantee that any driver using the bank B will actually drive the GPIO it might use. At this point I start wondering if such initial setup should not be the job of the bootloader? GPIO hogging ought to be simple and definitive, adding the possibility to have it just as an initial value would considerably complexify it. E.g. when is the gpio chip driver supposed to release the hogged descriptor in such a case? Do not count on the bootloader setting up anything. The trend is for the bootloader to setup the minimal environment to load your kernel and jump to it. http://www.denx.de/wiki/pub/U-Boot/MiniSummitELCE2013/2013-ELCE-U-Boot-Falcon-Boot.pdf Note that if the multiple GPIO consumer feature we are planning goes through, you should be able to use both hogging *and* a regulator on the same GPIO and achieve what you want. The expectation of multiple consumers is that the board designers know what they are doing, and this case would certainly fit (chip hogs the line and doesn't touch the value after that, letting the regulator control it without any conflict afterwards), although it would of course be better to solve the issue through regular probing... That’s why I was advocating a simple probing driver for all this. Figure out a way for this driver to be probed first would be an easier solution that what’s going on here. Regards — Pantelis -- 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/
Re: [Patch v2 1/2] gpio: add GPIO hogging mechanism
Hi, On Thu, Dec 04, 2014 at 11:15:38PM +0900, Alexandre Courbot wrote: On Wed, Dec 3, 2014 at 1:12 AM, Maxime Ripard maxime.rip...@free-electrons.com wrote: On Tue, Dec 02, 2014 at 03:29:46PM +0100, Linus Walleij wrote: On Tue, Dec 2, 2014 at 3:13 PM, Alexandre Courbot gnu...@gmail.com wrote: On Tue, Dec 2, 2014 at 1:36 AM, Maxime Ripard maxime.rip...@free-electrons.com wrote: The only thing I'd like to have would be that the request here would be non-exclusive, so that a later driver would still be allowed later on to request that GPIO later on and manage it itself (ideally using the usual gpiod_request function). Actually we have a plan (and I have some code too) to allow multiple consumers per GPIO. Although like Benoit I wonder why you would want to hog a GPIO and then request it properly later. Also, that probably means we should abandon the hog since it actively drives the line and would interfere with the late requested. How to do that correctly is not really clear to me. I don't get the usecase. A hogged GPIO is per definition hogged. This sounds more like initial settings or something, which is another usecase altogether. We do have one board where we have a pin (let's say GPIO14 of the bank A) that enables a regulator that will provide VCC the bank B. Now, both banks are handled by the same driver, but in order to have a working output on the bank B, we do need to set GPIO14 as soon as we're probed. Just relying on the usual deferred probing introduces a circular dependency between the gpio-regulator that needs to grab its GPIO from a driver not there yet, and the gpio driver that needs to enable its gpio-regulator. I don't get it. According to what you said, the following order should go through IIUC: 1) bank A is probed, gpio 14 is available 2) gpio-regulator is probed, acquires GPIO 14, regulator for Bank B is available 3) bank B is probed, grabs its regulator and turn it on, probes. What am I missing? It would be true if bank A and B were exposed through different drivers (or at least different instances of the same driver), which is not the case. In our case, banks A and B are handled by the same instance. Maxime -- Maxime Ripard, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com signature.asc Description: Digital signature
Re: [Patch v2 1/2] gpio: add GPIO hogging mechanism
On Thu, Dec 4, 2014 at 11:27 PM, Pantelis Antoniou pa...@antoniou-consulting.com wrote: Hi Alexandre, I tried to stay away while things are being fleshed out but… On Dec 4, 2014, at 16:15 , Alexandre Courbot gnu...@gmail.com wrote: On Wed, Dec 3, 2014 at 1:12 AM, Maxime Ripard maxime.rip...@free-electrons.com wrote: On Tue, Dec 02, 2014 at 03:29:46PM +0100, Linus Walleij wrote: On Tue, Dec 2, 2014 at 3:13 PM, Alexandre Courbot gnu...@gmail.com wrote: On Tue, Dec 2, 2014 at 1:36 AM, Maxime Ripard maxime.rip...@free-electrons.com wrote: The only thing I'd like to have would be that the request here would be non-exclusive, so that a later driver would still be allowed later on to request that GPIO later on and manage it itself (ideally using the usual gpiod_request function). Actually we have a plan (and I have some code too) to allow multiple consumers per GPIO. Although like Benoit I wonder why you would want to hog a GPIO and then request it properly later. Also, that probably means we should abandon the hog since it actively drives the line and would interfere with the late requested. How to do that correctly is not really clear to me. I don't get the usecase. A hogged GPIO is per definition hogged. This sounds more like initial settings or something, which is another usecase altogether. We do have one board where we have a pin (let's say GPIO14 of the bank A) that enables a regulator that will provide VCC the bank B. Now, both banks are handled by the same driver, but in order to have a working output on the bank B, we do need to set GPIO14 as soon as we're probed. Just relying on the usual deferred probing introduces a circular dependency between the gpio-regulator that needs to grab its GPIO from a driver not there yet, and the gpio driver that needs to enable its gpio-regulator. I don't get it. According to what you said, the following order should go through IIUC: 1) bank A is probed, gpio 14 is available 2) gpio-regulator is probed, acquires GPIO 14, regulator for Bank B is available 3) bank B is probed, grabs its regulator and turn it on, probes. What am I missing? GPIO hogging needs to be the ideal solution for that, since we can just enforce the GPIO14 value as the driver is probed, which provides the guarantee that any driver using the bank B will actually drive the GPIO it might use. At this point I start wondering if such initial setup should not be the job of the bootloader? GPIO hogging ought to be simple and definitive, adding the possibility to have it just as an initial value would considerably complexify it. E.g. when is the gpio chip driver supposed to release the hogged descriptor in such a case? Do not count on the bootloader setting up anything. The trend is for the bootloader to setup the minimal environment to load your kernel and jump to it. http://www.denx.de/wiki/pub/U-Boot/MiniSummitELCE2013/2013-ELCE-U-Boot-Falcon-Boot.pdf Just wondering. :) But yeah, there are some use-cases (such as this one or Linux-as-a-bootloader) for which this would not play nicely. Note that if the multiple GPIO consumer feature we are planning goes through, you should be able to use both hogging *and* a regulator on the same GPIO and achieve what you want. The expectation of multiple consumers is that the board designers know what they are doing, and this case would certainly fit (chip hogs the line and doesn't touch the value after that, letting the regulator control it without any conflict afterwards), although it would of course be better to solve the issue through regular probing... That’s why I was advocating a simple probing driver for all this. Figure out a way for this driver to be probed first would be an easier solution that what’s going on here. Do you mean, a driver whose sole job is to probe other drivers in the right order? :/ -- 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/
Re: [Patch v2 1/2] gpio: add GPIO hogging mechanism
Hi Alexandre, On Dec 4, 2014, at 16:41 , Alexandre Courbot gnu...@gmail.com wrote: On Thu, Dec 4, 2014 at 11:27 PM, Pantelis Antoniou pa...@antoniou-consulting.com wrote: Hi Alexandre, I tried to stay away while things are being fleshed out but… On Dec 4, 2014, at 16:15 , Alexandre Courbot gnu...@gmail.com wrote: On Wed, Dec 3, 2014 at 1:12 AM, Maxime Ripard maxime.rip...@free-electrons.com wrote: On Tue, Dec 02, 2014 at 03:29:46PM +0100, Linus Walleij wrote: On Tue, Dec 2, 2014 at 3:13 PM, Alexandre Courbot gnu...@gmail.com wrote: On Tue, Dec 2, 2014 at 1:36 AM, Maxime Ripard maxime.rip...@free-electrons.com wrote: The only thing I'd like to have would be that the request here would be non-exclusive, so that a later driver would still be allowed later on to request that GPIO later on and manage it itself (ideally using the usual gpiod_request function). Actually we have a plan (and I have some code too) to allow multiple consumers per GPIO. Although like Benoit I wonder why you would want to hog a GPIO and then request it properly later. Also, that probably means we should abandon the hog since it actively drives the line and would interfere with the late requested. How to do that correctly is not really clear to me. I don't get the usecase. A hogged GPIO is per definition hogged. This sounds more like initial settings or something, which is another usecase altogether. We do have one board where we have a pin (let's say GPIO14 of the bank A) that enables a regulator that will provide VCC the bank B. Now, both banks are handled by the same driver, but in order to have a working output on the bank B, we do need to set GPIO14 as soon as we're probed. Just relying on the usual deferred probing introduces a circular dependency between the gpio-regulator that needs to grab its GPIO from a driver not there yet, and the gpio driver that needs to enable its gpio-regulator. I don't get it. According to what you said, the following order should go through IIUC: 1) bank A is probed, gpio 14 is available 2) gpio-regulator is probed, acquires GPIO 14, regulator for Bank B is available 3) bank B is probed, grabs its regulator and turn it on, probes. What am I missing? GPIO hogging needs to be the ideal solution for that, since we can just enforce the GPIO14 value as the driver is probed, which provides the guarantee that any driver using the bank B will actually drive the GPIO it might use. At this point I start wondering if such initial setup should not be the job of the bootloader? GPIO hogging ought to be simple and definitive, adding the possibility to have it just as an initial value would considerably complexify it. E.g. when is the gpio chip driver supposed to release the hogged descriptor in such a case? Do not count on the bootloader setting up anything. The trend is for the bootloader to setup the minimal environment to load your kernel and jump to it. http://www.denx.de/wiki/pub/U-Boot/MiniSummitELCE2013/2013-ELCE-U-Boot-Falcon-Boot.pdf Just wondering. :) But yeah, there are some use-cases (such as this one or Linux-as-a-bootloader) for which this would not play nicely. Note that if the multiple GPIO consumer feature we are planning goes through, you should be able to use both hogging *and* a regulator on the same GPIO and achieve what you want. The expectation of multiple consumers is that the board designers know what they are doing, and this case would certainly fit (chip hogs the line and doesn't touch the value after that, letting the regulator control it without any conflict afterwards), although it would of course be better to solve the issue through regular probing... That’s why I was advocating a simple probing driver for all this. Figure out a way for this driver to be probed first would be an easier solution that what’s going on here. Do you mean, a driver whose sole job is to probe other drivers in the right order? :/ $DEITY no :) I mean instead of having the gpio hog in the gpio adapter driver, have a gpio-hog driver, that’s using an undisclosed method to make sure that it’s the first one to be probed afterwards. We can probably do it using DT. Or maybe using the proposed gpio hog method doesn’t cover every case. I don’t know, that’s why we’re spending time talking about this :) Regards — pantelis -- 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/
Re: [Patch v2 1/2] gpio: add GPIO hogging mechanism
On Thu, Dec 4, 2014 at 11:27 PM, Maxime Ripard maxime.rip...@free-electrons.com wrote: Hi, On Thu, Dec 04, 2014 at 11:15:38PM +0900, Alexandre Courbot wrote: On Wed, Dec 3, 2014 at 1:12 AM, Maxime Ripard maxime.rip...@free-electrons.com wrote: On Tue, Dec 02, 2014 at 03:29:46PM +0100, Linus Walleij wrote: On Tue, Dec 2, 2014 at 3:13 PM, Alexandre Courbot gnu...@gmail.com wrote: On Tue, Dec 2, 2014 at 1:36 AM, Maxime Ripard maxime.rip...@free-electrons.com wrote: The only thing I'd like to have would be that the request here would be non-exclusive, so that a later driver would still be allowed later on to request that GPIO later on and manage it itself (ideally using the usual gpiod_request function). Actually we have a plan (and I have some code too) to allow multiple consumers per GPIO. Although like Benoit I wonder why you would want to hog a GPIO and then request it properly later. Also, that probably means we should abandon the hog since it actively drives the line and would interfere with the late requested. How to do that correctly is not really clear to me. I don't get the usecase. A hogged GPIO is per definition hogged. This sounds more like initial settings or something, which is another usecase altogether. We do have one board where we have a pin (let's say GPIO14 of the bank A) that enables a regulator that will provide VCC the bank B. Now, both banks are handled by the same driver, but in order to have a working output on the bank B, we do need to set GPIO14 as soon as we're probed. Just relying on the usual deferred probing introduces a circular dependency between the gpio-regulator that needs to grab its GPIO from a driver not there yet, and the gpio driver that needs to enable its gpio-regulator. I don't get it. According to what you said, the following order should go through IIUC: 1) bank A is probed, gpio 14 is available 2) gpio-regulator is probed, acquires GPIO 14, regulator for Bank B is available 3) bank B is probed, grabs its regulator and turn it on, probes. What am I missing? It would be true if bank A and B were exposed through different drivers (or at least different instances of the same driver), which is not the case. In our case, banks A and B are handled by the same instance. Ok, so both banks A and B are part of the same device/DT node. Now I think I understand the issue. You need to hog the pin so that bank B will work right after the device is probed. But you will still have the problem that the regulator device will *not* be available when your device is probed, so you cannot call regulator_get() for bank B anyway. I guess your only choice is to hog that pin and leave it active ad vitam eternam. -- 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/
Re: [Patch v2 1/2] gpio: add GPIO hogging mechanism
Hi again, It looks like I missed some part of it. On Thu, Dec 04, 2014 at 11:15:38PM +0900, Alexandre Courbot wrote: GPIO hogging needs to be the ideal solution for that, since we can just enforce the GPIO14 value as the driver is probed, which provides the guarantee that any driver using the bank B will actually drive the GPIO it might use. At this point I start wondering if such initial setup should not be the job of the bootloader? GPIO hogging ought to be simple and definitive, adding the possibility to have it just as an initial value would considerably complexify it. E.g. when is the gpio chip driver supposed to release the hogged descriptor in such a case? Relying on the bootloader for such trivial (and critical) things may not work at all. You don't always have the option to replace it, either because you physically can't, or just because you don't have any alternative. I agree that in general this is something that should go in the bootloader, but we should have a way to deal with the case where it's not done. Note that if the multiple GPIO consumer feature we are planning goes through, you should be able to use both hogging *and* a regulator on the same GPIO and achieve what you want. The expectation of multiple consumers is that the board designers know what they are doing, and this case would certainly fit (chip hogs the line and doesn't touch the value after that, letting the regulator control it without any conflict afterwards), although it would of course be better to solve the issue through regular probing... If such an effort is on-going, then I'm totally fine waiting for it and leaving that outside the hogging mechanism. As long as it works, I'm happy. Maxime -- Maxime Ripard, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com signature.asc Description: Digital signature
Re: [Patch v2 1/2] gpio: add GPIO hogging mechanism
On Thu, Dec 4, 2014 at 11:47 PM, Pantelis Antoniou pa...@antoniou-consulting.com wrote: Hi Alexandre, On Dec 4, 2014, at 16:41 , Alexandre Courbot gnu...@gmail.com wrote: On Thu, Dec 4, 2014 at 11:27 PM, Pantelis Antoniou pa...@antoniou-consulting.com wrote: Hi Alexandre, I tried to stay away while things are being fleshed out but… On Dec 4, 2014, at 16:15 , Alexandre Courbot gnu...@gmail.com wrote: On Wed, Dec 3, 2014 at 1:12 AM, Maxime Ripard maxime.rip...@free-electrons.com wrote: On Tue, Dec 02, 2014 at 03:29:46PM +0100, Linus Walleij wrote: On Tue, Dec 2, 2014 at 3:13 PM, Alexandre Courbot gnu...@gmail.com wrote: On Tue, Dec 2, 2014 at 1:36 AM, Maxime Ripard maxime.rip...@free-electrons.com wrote: The only thing I'd like to have would be that the request here would be non-exclusive, so that a later driver would still be allowed later on to request that GPIO later on and manage it itself (ideally using the usual gpiod_request function). Actually we have a plan (and I have some code too) to allow multiple consumers per GPIO. Although like Benoit I wonder why you would want to hog a GPIO and then request it properly later. Also, that probably means we should abandon the hog since it actively drives the line and would interfere with the late requested. How to do that correctly is not really clear to me. I don't get the usecase. A hogged GPIO is per definition hogged. This sounds more like initial settings or something, which is another usecase altogether. We do have one board where we have a pin (let's say GPIO14 of the bank A) that enables a regulator that will provide VCC the bank B. Now, both banks are handled by the same driver, but in order to have a working output on the bank B, we do need to set GPIO14 as soon as we're probed. Just relying on the usual deferred probing introduces a circular dependency between the gpio-regulator that needs to grab its GPIO from a driver not there yet, and the gpio driver that needs to enable its gpio-regulator. I don't get it. According to what you said, the following order should go through IIUC: 1) bank A is probed, gpio 14 is available 2) gpio-regulator is probed, acquires GPIO 14, regulator for Bank B is available 3) bank B is probed, grabs its regulator and turn it on, probes. What am I missing? GPIO hogging needs to be the ideal solution for that, since we can just enforce the GPIO14 value as the driver is probed, which provides the guarantee that any driver using the bank B will actually drive the GPIO it might use. At this point I start wondering if such initial setup should not be the job of the bootloader? GPIO hogging ought to be simple and definitive, adding the possibility to have it just as an initial value would considerably complexify it. E.g. when is the gpio chip driver supposed to release the hogged descriptor in such a case? Do not count on the bootloader setting up anything. The trend is for the bootloader to setup the minimal environment to load your kernel and jump to it. http://www.denx.de/wiki/pub/U-Boot/MiniSummitELCE2013/2013-ELCE-U-Boot-Falcon-Boot.pdf Just wondering. :) But yeah, there are some use-cases (such as this one or Linux-as-a-bootloader) for which this would not play nicely. Note that if the multiple GPIO consumer feature we are planning goes through, you should be able to use both hogging *and* a regulator on the same GPIO and achieve what you want. The expectation of multiple consumers is that the board designers know what they are doing, and this case would certainly fit (chip hogs the line and doesn't touch the value after that, letting the regulator control it without any conflict afterwards), although it would of course be better to solve the issue through regular probing... That’s why I was advocating a simple probing driver for all this. Figure out a way for this driver to be probed first would be an easier solution that what’s going on here. Do you mean, a driver whose sole job is to probe other drivers in the right order? :/ $DEITY no :) I mean instead of having the gpio hog in the gpio adapter driver, have a gpio-hog driver, that’s using an undisclosed method to make sure that it’s the first one to be probed afterwards. IIUC that would not solve this particular issue - here the GPIO controller is both a provider and (indirect) consumer of a GPIO for itself. If the hog is in a separate node, if would have to be probed from inside the probe() function of the GPIO controller to do the job, which would be the same effect as having the hogs directly under the controller node, only with more hassle. Again, IIUC. _ -- 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/
Re: [Patch v2 1/2] gpio: add GPIO hogging mechanism
On Thu, Dec 4, 2014 at 11:52 PM, Maxime Ripard maxime.rip...@free-electrons.com wrote: Hi again, It looks like I missed some part of it. On Thu, Dec 04, 2014 at 11:15:38PM +0900, Alexandre Courbot wrote: GPIO hogging needs to be the ideal solution for that, since we can just enforce the GPIO14 value as the driver is probed, which provides the guarantee that any driver using the bank B will actually drive the GPIO it might use. At this point I start wondering if such initial setup should not be the job of the bootloader? GPIO hogging ought to be simple and definitive, adding the possibility to have it just as an initial value would considerably complexify it. E.g. when is the gpio chip driver supposed to release the hogged descriptor in such a case? Relying on the bootloader for such trivial (and critical) things may not work at all. You don't always have the option to replace it, either because you physically can't, or just because you don't have any alternative. I agree that in general this is something that should go in the bootloader, but we should have a way to deal with the case where it's not done. Note that if the multiple GPIO consumer feature we are planning goes through, you should be able to use both hogging *and* a regulator on the same GPIO and achieve what you want. The expectation of multiple consumers is that the board designers know what they are doing, and this case would certainly fit (chip hogs the line and doesn't touch the value after that, letting the regulator control it without any conflict afterwards), although it would of course be better to solve the issue through regular probing... If such an effort is on-going, then I'm totally fine waiting for it and leaving that outside the hogging mechanism. As long as it works, I'm happy. Ok. I just want to wait until the next -rc1 to make sure that the large GPIO array removal patch (on which the multiple consumers feature depend) did not break anything important, then I will submit it. -- 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/
Re: [Patch v2 1/2] gpio: add GPIO hogging mechanism
Hi Alexandre, On Dec 4, 2014, at 16:58 , Alexandre Courbot gnu...@gmail.com wrote: On Thu, Dec 4, 2014 at 11:47 PM, Pantelis Antoniou pa...@antoniou-consulting.com wrote: Hi Alexandre, On Dec 4, 2014, at 16:41 , Alexandre Courbot gnu...@gmail.com wrote: On Thu, Dec 4, 2014 at 11:27 PM, Pantelis Antoniou pa...@antoniou-consulting.com wrote: Hi Alexandre, I tried to stay away while things are being fleshed out but… On Dec 4, 2014, at 16:15 , Alexandre Courbot gnu...@gmail.com wrote: On Wed, Dec 3, 2014 at 1:12 AM, Maxime Ripard maxime.rip...@free-electrons.com wrote: On Tue, Dec 02, 2014 at 03:29:46PM +0100, Linus Walleij wrote: On Tue, Dec 2, 2014 at 3:13 PM, Alexandre Courbot gnu...@gmail.com wrote: On Tue, Dec 2, 2014 at 1:36 AM, Maxime Ripard maxime.rip...@free-electrons.com wrote: The only thing I'd like to have would be that the request here would be non-exclusive, so that a later driver would still be allowed later on to request that GPIO later on and manage it itself (ideally using the usual gpiod_request function). Actually we have a plan (and I have some code too) to allow multiple consumers per GPIO. Although like Benoit I wonder why you would want to hog a GPIO and then request it properly later. Also, that probably means we should abandon the hog since it actively drives the line and would interfere with the late requested. How to do that correctly is not really clear to me. I don't get the usecase. A hogged GPIO is per definition hogged. This sounds more like initial settings or something, which is another usecase altogether. We do have one board where we have a pin (let's say GPIO14 of the bank A) that enables a regulator that will provide VCC the bank B. Now, both banks are handled by the same driver, but in order to have a working output on the bank B, we do need to set GPIO14 as soon as we're probed. Just relying on the usual deferred probing introduces a circular dependency between the gpio-regulator that needs to grab its GPIO from a driver not there yet, and the gpio driver that needs to enable its gpio-regulator. I don't get it. According to what you said, the following order should go through IIUC: 1) bank A is probed, gpio 14 is available 2) gpio-regulator is probed, acquires GPIO 14, regulator for Bank B is available 3) bank B is probed, grabs its regulator and turn it on, probes. What am I missing? GPIO hogging needs to be the ideal solution for that, since we can just enforce the GPIO14 value as the driver is probed, which provides the guarantee that any driver using the bank B will actually drive the GPIO it might use. At this point I start wondering if such initial setup should not be the job of the bootloader? GPIO hogging ought to be simple and definitive, adding the possibility to have it just as an initial value would considerably complexify it. E.g. when is the gpio chip driver supposed to release the hogged descriptor in such a case? Do not count on the bootloader setting up anything. The trend is for the bootloader to setup the minimal environment to load your kernel and jump to it. http://www.denx.de/wiki/pub/U-Boot/MiniSummitELCE2013/2013-ELCE-U-Boot-Falcon-Boot.pdf Just wondering. :) But yeah, there are some use-cases (such as this one or Linux-as-a-bootloader) for which this would not play nicely. Note that if the multiple GPIO consumer feature we are planning goes through, you should be able to use both hogging *and* a regulator on the same GPIO and achieve what you want. The expectation of multiple consumers is that the board designers know what they are doing, and this case would certainly fit (chip hogs the line and doesn't touch the value after that, letting the regulator control it without any conflict afterwards), although it would of course be better to solve the issue through regular probing... That’s why I was advocating a simple probing driver for all this. Figure out a way for this driver to be probed first would be an easier solution that what’s going on here. Do you mean, a driver whose sole job is to probe other drivers in the right order? :/ $DEITY no :) I mean instead of having the gpio hog in the gpio adapter driver, have a gpio-hog driver, that’s using an undisclosed method to make sure that it’s the first one to be probed afterwards. IIUC that would not solve this particular issue - here the GPIO controller is both a provider and (indirect) consumer of a GPIO for itself. If the hog is in a separate node, if would have to be probed from inside the probe() function of the GPIO controller to do the job, which would be the same effect as having the hogs directly under the controller node, only with more hassle. Again, IIUC. _ If you had a way to specify the order of probing that would work no? You don’t have to do it in the gpio-controller, you can do it in the platform bus probe. Regards —
Re: [Patch v2 1/2] gpio: add GPIO hogging mechanism
On Fri, Dec 5, 2014 at 12:02 AM, Pantelis Antoniou pa...@antoniou-consulting.com wrote: Hi Alexandre, On Dec 4, 2014, at 16:58 , Alexandre Courbot gnu...@gmail.com wrote: On Thu, Dec 4, 2014 at 11:47 PM, Pantelis Antoniou pa...@antoniou-consulting.com wrote: Hi Alexandre, On Dec 4, 2014, at 16:41 , Alexandre Courbot gnu...@gmail.com wrote: On Thu, Dec 4, 2014 at 11:27 PM, Pantelis Antoniou pa...@antoniou-consulting.com wrote: Hi Alexandre, I tried to stay away while things are being fleshed out but… On Dec 4, 2014, at 16:15 , Alexandre Courbot gnu...@gmail.com wrote: On Wed, Dec 3, 2014 at 1:12 AM, Maxime Ripard maxime.rip...@free-electrons.com wrote: On Tue, Dec 02, 2014 at 03:29:46PM +0100, Linus Walleij wrote: On Tue, Dec 2, 2014 at 3:13 PM, Alexandre Courbot gnu...@gmail.com wrote: On Tue, Dec 2, 2014 at 1:36 AM, Maxime Ripard maxime.rip...@free-electrons.com wrote: The only thing I'd like to have would be that the request here would be non-exclusive, so that a later driver would still be allowed later on to request that GPIO later on and manage it itself (ideally using the usual gpiod_request function). Actually we have a plan (and I have some code too) to allow multiple consumers per GPIO. Although like Benoit I wonder why you would want to hog a GPIO and then request it properly later. Also, that probably means we should abandon the hog since it actively drives the line and would interfere with the late requested. How to do that correctly is not really clear to me. I don't get the usecase. A hogged GPIO is per definition hogged. This sounds more like initial settings or something, which is another usecase altogether. We do have one board where we have a pin (let's say GPIO14 of the bank A) that enables a regulator that will provide VCC the bank B. Now, both banks are handled by the same driver, but in order to have a working output on the bank B, we do need to set GPIO14 as soon as we're probed. Just relying on the usual deferred probing introduces a circular dependency between the gpio-regulator that needs to grab its GPIO from a driver not there yet, and the gpio driver that needs to enable its gpio-regulator. I don't get it. According to what you said, the following order should go through IIUC: 1) bank A is probed, gpio 14 is available 2) gpio-regulator is probed, acquires GPIO 14, regulator for Bank B is available 3) bank B is probed, grabs its regulator and turn it on, probes. What am I missing? GPIO hogging needs to be the ideal solution for that, since we can just enforce the GPIO14 value as the driver is probed, which provides the guarantee that any driver using the bank B will actually drive the GPIO it might use. At this point I start wondering if such initial setup should not be the job of the bootloader? GPIO hogging ought to be simple and definitive, adding the possibility to have it just as an initial value would considerably complexify it. E.g. when is the gpio chip driver supposed to release the hogged descriptor in such a case? Do not count on the bootloader setting up anything. The trend is for the bootloader to setup the minimal environment to load your kernel and jump to it. http://www.denx.de/wiki/pub/U-Boot/MiniSummitELCE2013/2013-ELCE-U-Boot-Falcon-Boot.pdf Just wondering. :) But yeah, there are some use-cases (such as this one or Linux-as-a-bootloader) for which this would not play nicely. Note that if the multiple GPIO consumer feature we are planning goes through, you should be able to use both hogging *and* a regulator on the same GPIO and achieve what you want. The expectation of multiple consumers is that the board designers know what they are doing, and this case would certainly fit (chip hogs the line and doesn't touch the value after that, letting the regulator control it without any conflict afterwards), although it would of course be better to solve the issue through regular probing... That’s why I was advocating a simple probing driver for all this. Figure out a way for this driver to be probed first would be an easier solution that what’s going on here. Do you mean, a driver whose sole job is to probe other drivers in the right order? :/ $DEITY no :) I mean instead of having the gpio hog in the gpio adapter driver, have a gpio-hog driver, that’s using an undisclosed method to make sure that it’s the first one to be probed afterwards. IIUC that would not solve this particular issue - here the GPIO controller is both a provider and (indirect) consumer of a GPIO for itself. If the hog is in a separate node, if would have to be probed from inside the probe() function of the GPIO controller to do the job, which would be the same effect as having the hogs directly under the controller node, only with more hassle. Again, IIUC. _ If you had a way to specify the order of probing that would work no? You don’t have to do it in the gpio-controller,
Re: [Patch v2 1/2] gpio: add GPIO hogging mechanism
Hi Alexandre, On Dec 4, 2014, at 17:10 , Alexandre Courbot gnu...@gmail.com wrote: On Fri, Dec 5, 2014 at 12:02 AM, Pantelis Antoniou pa...@antoniou-consulting.com wrote: Hi Alexandre, On Dec 4, 2014, at 16:58 , Alexandre Courbot gnu...@gmail.com wrote: On Thu, Dec 4, 2014 at 11:47 PM, Pantelis Antoniou pa...@antoniou-consulting.com wrote: Hi Alexandre, On Dec 4, 2014, at 16:41 , Alexandre Courbot gnu...@gmail.com wrote: On Thu, Dec 4, 2014 at 11:27 PM, Pantelis Antoniou pa...@antoniou-consulting.com wrote: Hi Alexandre, I tried to stay away while things are being fleshed out but… On Dec 4, 2014, at 16:15 , Alexandre Courbot gnu...@gmail.com wrote: On Wed, Dec 3, 2014 at 1:12 AM, Maxime Ripard maxime.rip...@free-electrons.com wrote: On Tue, Dec 02, 2014 at 03:29:46PM +0100, Linus Walleij wrote: On Tue, Dec 2, 2014 at 3:13 PM, Alexandre Courbot gnu...@gmail.com wrote: On Tue, Dec 2, 2014 at 1:36 AM, Maxime Ripard maxime.rip...@free-electrons.com wrote: The only thing I'd like to have would be that the request here would be non-exclusive, so that a later driver would still be allowed later on to request that GPIO later on and manage it itself (ideally using the usual gpiod_request function). Actually we have a plan (and I have some code too) to allow multiple consumers per GPIO. Although like Benoit I wonder why you would want to hog a GPIO and then request it properly later. Also, that probably means we should abandon the hog since it actively drives the line and would interfere with the late requested. How to do that correctly is not really clear to me. I don't get the usecase. A hogged GPIO is per definition hogged. This sounds more like initial settings or something, which is another usecase altogether. We do have one board where we have a pin (let's say GPIO14 of the bank A) that enables a regulator that will provide VCC the bank B. Now, both banks are handled by the same driver, but in order to have a working output on the bank B, we do need to set GPIO14 as soon as we're probed. Just relying on the usual deferred probing introduces a circular dependency between the gpio-regulator that needs to grab its GPIO from a driver not there yet, and the gpio driver that needs to enable its gpio-regulator. I don't get it. According to what you said, the following order should go through IIUC: 1) bank A is probed, gpio 14 is available 2) gpio-regulator is probed, acquires GPIO 14, regulator for Bank B is available 3) bank B is probed, grabs its regulator and turn it on, probes. What am I missing? GPIO hogging needs to be the ideal solution for that, since we can just enforce the GPIO14 value as the driver is probed, which provides the guarantee that any driver using the bank B will actually drive the GPIO it might use. At this point I start wondering if such initial setup should not be the job of the bootloader? GPIO hogging ought to be simple and definitive, adding the possibility to have it just as an initial value would considerably complexify it. E.g. when is the gpio chip driver supposed to release the hogged descriptor in such a case? Do not count on the bootloader setting up anything. The trend is for the bootloader to setup the minimal environment to load your kernel and jump to it. http://www.denx.de/wiki/pub/U-Boot/MiniSummitELCE2013/2013-ELCE-U-Boot-Falcon-Boot.pdf Just wondering. :) But yeah, there are some use-cases (such as this one or Linux-as-a-bootloader) for which this would not play nicely. Note that if the multiple GPIO consumer feature we are planning goes through, you should be able to use both hogging *and* a regulator on the same GPIO and achieve what you want. The expectation of multiple consumers is that the board designers know what they are doing, and this case would certainly fit (chip hogs the line and doesn't touch the value after that, letting the regulator control it without any conflict afterwards), although it would of course be better to solve the issue through regular probing... That’s why I was advocating a simple probing driver for all this. Figure out a way for this driver to be probed first would be an easier solution that what’s going on here. Do you mean, a driver whose sole job is to probe other drivers in the right order? :/ $DEITY no :) I mean instead of having the gpio hog in the gpio adapter driver, have a gpio-hog driver, that’s using an undisclosed method to make sure that it’s the first one to be probed afterwards. IIUC that would not solve this particular issue - here the GPIO controller is both a provider and (indirect) consumer of a GPIO for itself. If the hog is in a separate node, if would have to be probed from inside the probe() function of the GPIO controller to do the job, which would be the same effect as having the hogs directly under the controller node, only with more hassle. Again,
Re: [Patch v2 1/2] gpio: add GPIO hogging mechanism
On Tue, Dec 02, 2014 at 03:29:46PM +0100, Linus Walleij wrote: > On Tue, Dec 2, 2014 at 3:13 PM, Alexandre Courbot wrote: > > On Tue, Dec 2, 2014 at 1:36 AM, Maxime Ripard > > wrote: > > >> The only thing I'd like to have would be that the request here would > >> be non-exclusive, so that a later driver would still be allowed later > >> on to request that GPIO later on and manage it itself (ideally using > >> the usual gpiod_request function). > > > > Actually we have a plan (and I have some code too) to allow multiple > > consumers per GPIO. Although like Benoit I wonder why you would want > > to hog a GPIO and then request it properly later. Also, that probably > > means we should abandon the hog since it actively drives the line and > > would interfere with the late requested. How to do that correctly is > > not really clear to me. > > I don't get the usecase. A hogged GPIO is per definition hogged. > This sounds more like "initial settings" or something, which is another > usecase altogether. We do have one board where we have a pin (let's say GPIO14 of the bank A) that enables a regulator that will provide VCC the bank B. Now, both banks are handled by the same driver, but in order to have a working output on the bank B, we do need to set GPIO14 as soon as we're probed. Just relying on the usual deferred probing introduces a circular dependency between the gpio-regulator that needs to grab its GPIO from a driver not there yet, and the gpio driver that needs to enable its gpio-regulator. GPIO hogging needs to be the ideal solution for that, since we can just enforce the GPIO14 value as the driver is probed, which provides the guarantee that any driver using the bank B will actually drive the GPIO it might use. However, an exclusive request will prevent any representation of this as a regulator, which sounds a bit weird, since it really is just that. Maxime -- Maxime Ripard, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com signature.asc Description: Digital signature
Re: [Patch v2 1/2] gpio: add GPIO hogging mechanism
On Tue, Dec 2, 2014 at 3:13 PM, Alexandre Courbot wrote: > On Tue, Dec 2, 2014 at 1:36 AM, Maxime Ripard > wrote: >> The only thing I'd like to have would be that the request here would >> be non-exclusive, so that a later driver would still be allowed later >> on to request that GPIO later on and manage it itself (ideally using >> the usual gpiod_request function). > > Actually we have a plan (and I have some code too) to allow multiple > consumers per GPIO. Although like Benoit I wonder why you would want > to hog a GPIO and then request it properly later. Also, that probably > means we should abandon the hog since it actively drives the line and > would interfere with the late requested. How to do that correctly is > not really clear to me. I don't get the usecase. A hogged GPIO is per definition hogged. This sounds more like "initial settings" or something, which is another usecase altogether. Yours, Linus Walleij -- 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/
Re: [Patch v2 1/2] gpio: add GPIO hogging mechanism
On Tue, Dec 2, 2014 at 3:10 PM, Alexandre Courbot wrote:
> On Tue, Dec 2, 2014 at 9:22 AM, Benoit Parrot wrote:
>>> > + }
>>> > +
>>> > + if (tmp > MAX_PHANDLE_ARGS) {
>>> > + desc = ERR_PTR(-EINVAL);
>>> > + goto out;
>>> > + }
>>> > +
>>> > + gg_data.gpiospec.args_count = tmp;
>>> > + gg_data.gpiospec.np = chip_np;
>>> > + for (i = 0; i < tmp; i++) {
>>> > + ret = of_property_read_u32(np, "gpios",
>>> > + _data.gpiospec.args[i]);
>>> > + if (ret) {
>>> > + desc = ERR_PTR(ret);
>>> > + goto out;
>>> > + }
>>> > + }
>>> > +
>>> > + gpiochip_find(_data, of_gpiochip_find_and_xlate);
>>>
>>> This seems to work but only supports one GPIO per hog node. It would
>>> be nice to be able to specify several GPIOs to which the same settings
>>> need to be applied.
>>
>> This is on purpose following Linus Walleij's comment.
>
> Could you point me to his comment? My bad for not remembering what he
> said, but I'd like to understand why.
Said in previous message I think: either one-per-node or lists directly
in the gpiochip node.
>>> Using this function means that a GPIO chip module cannot be unloaded
>>> if it uses GPIO hogs. Is it the intended behavior? If not, please use
>>> gpiochip_request_own_desc() instead, and make sure to call
>>> gpiochip_free_own_desc() for each hog when the driver is unloaded.
>>
>> So I guess we could add a undo_gpio_hog() function and hook it up under
>> of_gpiochip_remove().
>> Now instead of maintaining a seperate structure just to keep track of hogged
>> descriptor,
>> would it be acceptable to add a new "gpio_desc.flags" value in gpiolib.h
>> says:
>>
>>#define FLAG_GPIO_IS_HOGGED 10
>>
>> And key on that at removal time instead of creating a list and having to
>> maintain that?
>
> Definitely, that would be even better I think.
Clever. Go for this.
>>> I would suggest to factorize this code that is similar to the one
>>> found in __gpiod_get_index(). Do all the DT parsing in a function that
>>> just returns a descriptor and the
>>
>> I would tend to agree.
>> But as Linus suggested I was trying to contain the changes to gpiolib_of.c
>> only.
>
> If we add a FLAG_GPIO_IS_HOGGED and undo the hogs when the chip is
> unloaded, I would say that this becomes a gpiolib feature. Moving it
> here would also allow non-DT GPIO providers to implement hogs (it
> should be particularly easy to implement for platform data). Linus, do
> you agree?
Yes, this is better and leaves the door open for other users.
Yours,
Linus Walleij
--
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/
Re: [Patch v2 1/2] gpio: add GPIO hogging mechanism
On Tue, Dec 2, 2014 at 1:22 AM, Benoit Parrot wrote:
> Alexandre Courbot wrote on Fri [2014-Nov-28 16:30:01
> +0900]:
>> On Fri, Nov 21, 2014 at 8:54 AM, Benoit Parrot wrote:
>> > + }
>> > +
>> > + if (tmp > MAX_PHANDLE_ARGS) {
>> > + desc = ERR_PTR(-EINVAL);
>> > + goto out;
>> > + }
>> > +
>> > + gg_data.gpiospec.args_count = tmp;
>> > + gg_data.gpiospec.np = chip_np;
>> > + for (i = 0; i < tmp; i++) {
>> > + ret = of_property_read_u32(np, "gpios",
>> > + _data.gpiospec.args[i]);
>> > + if (ret) {
>> > + desc = ERR_PTR(ret);
>> > + goto out;
>> > + }
>> > + }
>> > +
>> > + gpiochip_find(_data, of_gpiochip_find_and_xlate);
>>
>> This seems to work but only supports one GPIO per hog node. It would
>> be nice to be able to specify several GPIOs to which the same settings
>> need to be applied.
>
> This is on purpose following Linus Walleij's comment.
Yes, I think either we have separate nodes for each hogged line *OR*
we just put a list of hogs under the gpiochip, no special node at all.
The one-node-per-hog pattern has the upside of being usable
to also name the hogs. (Exporting them is dubious however!
I would add a special type of node for that.)
>> > + if (err < 0)
>> > + return err;
>> > +
>> > + if (lflags & GPIO_ACTIVE_LOW)
>> > + set_bit(FLAG_ACTIVE_LOW, >flags);
>> > + if (lflags & GPIO_OPEN_DRAIN)
>> > + set_bit(FLAG_OPEN_DRAIN, >flags);
>> > + if (lflags & GPIO_OPEN_SOURCE)
>> > + set_bit(FLAG_OPEN_SOURCE, >flags);
>> > +
>> > + /* No particular flag request, not really hogging then... */
>> > + if (!(dflags & GPIOD_FLAGS_BIT_DIR_SET)) {
>> > + pr_warn("%s: GPIO %s: no hogging direction specified,
>> > bailing out\n",
>> > +__func__, name);
>> > + err = -EINVAL;
>> > + goto free_gpio;
>> > + }
>> > +
>> > + /* Process flags */
>> > + if (dflags & GPIOD_FLAGS_BIT_DIR_OUT)
>> > + err = gpiod_direction_output(desc,
>> > +dflags &
>> > GPIOD_FLAGS_BIT_DIR_VAL);
>> > + else
>> > + err = gpiod_direction_input(desc);
>> > +
>> > + if (err < 0) {
>> > + pr_warn("%s: GPIO %s setting direction/value failed\n",
>> > +__func__, name);
>> > + goto free_gpio;
>> > + }
>>
>> I would suggest to factorize this code that is similar to the one
>> found in __gpiod_get_index(). Do all the DT parsing in a function that
>> just returns a descriptor and the
>
> I would tend to agree.
> But as Linus suggested I was trying to contain the changes to gpiolib_of.c
> only.
Yes I prefer we begin by supporting it in OF and then generalize it later
if more users (board files, ACPI) appear.
Not a big deal but I want to avoid big design up front unless it's
easy and a few alterations.
http://c2.com/cgi/wiki?BigDesignUpFront
Yours,
Linus Walleij
--
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/
Re: [Patch v2 1/2] gpio: add GPIO hogging mechanism
On Tue, Dec 2, 2014 at 1:36 AM, Maxime Ripard
wrote:
> Hi,
>
> On Fri, Nov 28, 2014 at 04:30:01PM +0900, Alexandre Courbot wrote:
>> > +/**
>> > + * do_gpio_hog - Given node is a GPIO hog configuration, handle it
>> > + * @np:device node to get GPIO from
>> > + *
>> > + * This is only used by of_gpiochip_add to request/set GPIO initial
>> > + * configuration.
>> > + */
>> > +static int do_gpio_hog(struct device_node *np)
>> > +{
>> > + struct gpio_desc *desc = NULL;
>> > + int err;
>> > + const char *name;
>> > + enum gpio_lookup_flags lflags;
>> > + enum gpiod_flags dflags;
>> > +
>> > + desc = of_get_gpio_hog(np, , , );
>> > + if (!desc)
>> > + return -ENOTSUPP;
>> > + else if (IS_ERR(desc))
>> > + return PTR_ERR(desc);
>> > +
>> > + err = gpiod_request(desc, name);
>>
>> Using this function means that a GPIO chip module cannot be unloaded
>> if it uses GPIO hogs. Is it the intended behavior? If not, please use
>> gpiochip_request_own_desc() instead, and make sure to call
>> gpiochip_free_own_desc() for each hog when the driver is unloaded.
>
> The only thing I'd like to have would be that the request here would
> be non-exclusive, so that a later driver would still be allowed later
> on to request that GPIO later on and manage it itself (ideally using
> the usual gpiod_request function).
Actually we have a plan (and I have some code too) to allow multiple
consumers per GPIO. Although like Benoit I wonder why you would want
to hog a GPIO and then request it properly later. Also, that probably
means we should abandon the hog since it actively drives the line and
would interfere with the late requested. How to do that correctly is
not really clear to me.
--
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/
Re: [Patch v2 1/2] gpio: add GPIO hogging mechanism
On Tue, Dec 2, 2014 at 9:22 AM, Benoit Parrot wrote:
>> > + }
>> > +
>> > + if (tmp > MAX_PHANDLE_ARGS) {
>> > + desc = ERR_PTR(-EINVAL);
>> > + goto out;
>> > + }
>> > +
>> > + gg_data.gpiospec.args_count = tmp;
>> > + gg_data.gpiospec.np = chip_np;
>> > + for (i = 0; i < tmp; i++) {
>> > + ret = of_property_read_u32(np, "gpios",
>> > + _data.gpiospec.args[i]);
>> > + if (ret) {
>> > + desc = ERR_PTR(ret);
>> > + goto out;
>> > + }
>> > + }
>> > +
>> > + gpiochip_find(_data, of_gpiochip_find_and_xlate);
>>
>> This seems to work but only supports one GPIO per hog node. It would
>> be nice to be able to specify several GPIOs to which the same settings
>> need to be applied.
>
> This is on purpose following Linus Walleij's comment.
Could you point me to his comment? My bad for not remembering what he
said, but I'd like to understand why.
>> Using this function means that a GPIO chip module cannot be unloaded
>> if it uses GPIO hogs. Is it the intended behavior? If not, please use
>> gpiochip_request_own_desc() instead, and make sure to call
>> gpiochip_free_own_desc() for each hog when the driver is unloaded.
>
> So I guess we could add a undo_gpio_hog() function and hook it up under
> of_gpiochip_remove().
> Now instead of maintaining a seperate structure just to keep track of hogged
> descriptor,
> would it be acceptable to add a new "gpio_desc.flags" value in gpiolib.h says:
>
>#define FLAG_GPIO_IS_HOGGED 10
>
> And key on that at removal time instead of creating a list and having to
> maintain that?
Definitely, that would be even better I think.
>> I would suggest to factorize this code that is similar to the one
>> found in __gpiod_get_index(). Do all the DT parsing in a function that
>> just returns a descriptor and the
>
> I would tend to agree.
> But as Linus suggested I was trying to contain the changes to gpiolib_of.c
> only.
If we add a FLAG_GPIO_IS_HOGGED and undo the hogs when the chip is
unloaded, I would say that this becomes a gpiolib feature. Moving it
here would also allow non-DT GPIO providers to implement hogs (it
should be particularly easy to implement for platform data). Linus, do
you agree?
--
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/
Re: [Patch v2 1/2] gpio: add GPIO hogging mechanism
On Tue, Dec 2, 2014 at 9:22 AM, Benoit Parrot bpar...@ti.com wrote:
+ }
+
+ if (tmp MAX_PHANDLE_ARGS) {
+ desc = ERR_PTR(-EINVAL);
+ goto out;
+ }
+
+ gg_data.gpiospec.args_count = tmp;
+ gg_data.gpiospec.np = chip_np;
+ for (i = 0; i tmp; i++) {
+ ret = of_property_read_u32(np, gpios,
+ gg_data.gpiospec.args[i]);
+ if (ret) {
+ desc = ERR_PTR(ret);
+ goto out;
+ }
+ }
+
+ gpiochip_find(gg_data, of_gpiochip_find_and_xlate);
This seems to work but only supports one GPIO per hog node. It would
be nice to be able to specify several GPIOs to which the same settings
need to be applied.
This is on purpose following Linus Walleij's comment.
Could you point me to his comment? My bad for not remembering what he
said, but I'd like to understand why.
Using this function means that a GPIO chip module cannot be unloaded
if it uses GPIO hogs. Is it the intended behavior? If not, please use
gpiochip_request_own_desc() instead, and make sure to call
gpiochip_free_own_desc() for each hog when the driver is unloaded.
So I guess we could add a undo_gpio_hog() function and hook it up under
of_gpiochip_remove().
Now instead of maintaining a seperate structure just to keep track of hogged
descriptor,
would it be acceptable to add a new gpio_desc.flags value in gpiolib.h says:
#define FLAG_GPIO_IS_HOGGED 10
And key on that at removal time instead of creating a list and having to
maintain that?
Definitely, that would be even better I think.
I would suggest to factorize this code that is similar to the one
found in __gpiod_get_index(). Do all the DT parsing in a function that
just returns a descriptor and the
I would tend to agree.
But as Linus suggested I was trying to contain the changes to gpiolib_of.c
only.
If we add a FLAG_GPIO_IS_HOGGED and undo the hogs when the chip is
unloaded, I would say that this becomes a gpiolib feature. Moving it
here would also allow non-DT GPIO providers to implement hogs (it
should be particularly easy to implement for platform data). Linus, do
you agree?
--
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/
Re: [Patch v2 1/2] gpio: add GPIO hogging mechanism
On Tue, Dec 2, 2014 at 1:36 AM, Maxime Ripard
maxime.rip...@free-electrons.com wrote:
Hi,
On Fri, Nov 28, 2014 at 04:30:01PM +0900, Alexandre Courbot wrote:
+/**
+ * do_gpio_hog - Given node is a GPIO hog configuration, handle it
+ * @np:device node to get GPIO from
+ *
+ * This is only used by of_gpiochip_add to request/set GPIO initial
+ * configuration.
+ */
+static int do_gpio_hog(struct device_node *np)
+{
+ struct gpio_desc *desc = NULL;
+ int err;
+ const char *name;
+ enum gpio_lookup_flags lflags;
+ enum gpiod_flags dflags;
+
+ desc = of_get_gpio_hog(np, name, lflags, dflags);
+ if (!desc)
+ return -ENOTSUPP;
+ else if (IS_ERR(desc))
+ return PTR_ERR(desc);
+
+ err = gpiod_request(desc, name);
Using this function means that a GPIO chip module cannot be unloaded
if it uses GPIO hogs. Is it the intended behavior? If not, please use
gpiochip_request_own_desc() instead, and make sure to call
gpiochip_free_own_desc() for each hog when the driver is unloaded.
The only thing I'd like to have would be that the request here would
be non-exclusive, so that a later driver would still be allowed later
on to request that GPIO later on and manage it itself (ideally using
the usual gpiod_request function).
Actually we have a plan (and I have some code too) to allow multiple
consumers per GPIO. Although like Benoit I wonder why you would want
to hog a GPIO and then request it properly later. Also, that probably
means we should abandon the hog since it actively drives the line and
would interfere with the late requested. How to do that correctly is
not really clear to me.
--
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/
Re: [Patch v2 1/2] gpio: add GPIO hogging mechanism
On Tue, Dec 2, 2014 at 1:22 AM, Benoit Parrot bpar...@ti.com wrote:
Alexandre Courbot gnu...@gmail.com wrote on Fri [2014-Nov-28 16:30:01
+0900]:
On Fri, Nov 21, 2014 at 8:54 AM, Benoit Parrot bpar...@ti.com wrote:
+ }
+
+ if (tmp MAX_PHANDLE_ARGS) {
+ desc = ERR_PTR(-EINVAL);
+ goto out;
+ }
+
+ gg_data.gpiospec.args_count = tmp;
+ gg_data.gpiospec.np = chip_np;
+ for (i = 0; i tmp; i++) {
+ ret = of_property_read_u32(np, gpios,
+ gg_data.gpiospec.args[i]);
+ if (ret) {
+ desc = ERR_PTR(ret);
+ goto out;
+ }
+ }
+
+ gpiochip_find(gg_data, of_gpiochip_find_and_xlate);
This seems to work but only supports one GPIO per hog node. It would
be nice to be able to specify several GPIOs to which the same settings
need to be applied.
This is on purpose following Linus Walleij's comment.
Yes, I think either we have separate nodes for each hogged line *OR*
we just put a list of hogs under the gpiochip, no special node at all.
The one-node-per-hog pattern has the upside of being usable
to also name the hogs. (Exporting them is dubious however!
I would add a special type of node for that.)
+ if (err 0)
+ return err;
+
+ if (lflags GPIO_ACTIVE_LOW)
+ set_bit(FLAG_ACTIVE_LOW, desc-flags);
+ if (lflags GPIO_OPEN_DRAIN)
+ set_bit(FLAG_OPEN_DRAIN, desc-flags);
+ if (lflags GPIO_OPEN_SOURCE)
+ set_bit(FLAG_OPEN_SOURCE, desc-flags);
+
+ /* No particular flag request, not really hogging then... */
+ if (!(dflags GPIOD_FLAGS_BIT_DIR_SET)) {
+ pr_warn(%s: GPIO %s: no hogging direction specified,
bailing out\n,
+__func__, name);
+ err = -EINVAL;
+ goto free_gpio;
+ }
+
+ /* Process flags */
+ if (dflags GPIOD_FLAGS_BIT_DIR_OUT)
+ err = gpiod_direction_output(desc,
+dflags
GPIOD_FLAGS_BIT_DIR_VAL);
+ else
+ err = gpiod_direction_input(desc);
+
+ if (err 0) {
+ pr_warn(%s: GPIO %s setting direction/value failed\n,
+__func__, name);
+ goto free_gpio;
+ }
I would suggest to factorize this code that is similar to the one
found in __gpiod_get_index(). Do all the DT parsing in a function that
just returns a descriptor and the
I would tend to agree.
But as Linus suggested I was trying to contain the changes to gpiolib_of.c
only.
Yes I prefer we begin by supporting it in OF and then generalize it later
if more users (board files, ACPI) appear.
Not a big deal but I want to avoid big design up front unless it's
easy and a few alterations.
http://c2.com/cgi/wiki?BigDesignUpFront
Yours,
Linus Walleij
--
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/
Re: [Patch v2 1/2] gpio: add GPIO hogging mechanism
On Tue, Dec 2, 2014 at 3:10 PM, Alexandre Courbot gnu...@gmail.com wrote:
On Tue, Dec 2, 2014 at 9:22 AM, Benoit Parrot bpar...@ti.com wrote:
+ }
+
+ if (tmp MAX_PHANDLE_ARGS) {
+ desc = ERR_PTR(-EINVAL);
+ goto out;
+ }
+
+ gg_data.gpiospec.args_count = tmp;
+ gg_data.gpiospec.np = chip_np;
+ for (i = 0; i tmp; i++) {
+ ret = of_property_read_u32(np, gpios,
+ gg_data.gpiospec.args[i]);
+ if (ret) {
+ desc = ERR_PTR(ret);
+ goto out;
+ }
+ }
+
+ gpiochip_find(gg_data, of_gpiochip_find_and_xlate);
This seems to work but only supports one GPIO per hog node. It would
be nice to be able to specify several GPIOs to which the same settings
need to be applied.
This is on purpose following Linus Walleij's comment.
Could you point me to his comment? My bad for not remembering what he
said, but I'd like to understand why.
Said in previous message I think: either one-per-node or lists directly
in the gpiochip node.
Using this function means that a GPIO chip module cannot be unloaded
if it uses GPIO hogs. Is it the intended behavior? If not, please use
gpiochip_request_own_desc() instead, and make sure to call
gpiochip_free_own_desc() for each hog when the driver is unloaded.
So I guess we could add a undo_gpio_hog() function and hook it up under
of_gpiochip_remove().
Now instead of maintaining a seperate structure just to keep track of hogged
descriptor,
would it be acceptable to add a new gpio_desc.flags value in gpiolib.h
says:
#define FLAG_GPIO_IS_HOGGED 10
And key on that at removal time instead of creating a list and having to
maintain that?
Definitely, that would be even better I think.
Clever. Go for this.
I would suggest to factorize this code that is similar to the one
found in __gpiod_get_index(). Do all the DT parsing in a function that
just returns a descriptor and the
I would tend to agree.
But as Linus suggested I was trying to contain the changes to gpiolib_of.c
only.
If we add a FLAG_GPIO_IS_HOGGED and undo the hogs when the chip is
unloaded, I would say that this becomes a gpiolib feature. Moving it
here would also allow non-DT GPIO providers to implement hogs (it
should be particularly easy to implement for platform data). Linus, do
you agree?
Yes, this is better and leaves the door open for other users.
Yours,
Linus Walleij
--
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/
Re: [Patch v2 1/2] gpio: add GPIO hogging mechanism
On Tue, Dec 2, 2014 at 3:13 PM, Alexandre Courbot gnu...@gmail.com wrote: On Tue, Dec 2, 2014 at 1:36 AM, Maxime Ripard maxime.rip...@free-electrons.com wrote: The only thing I'd like to have would be that the request here would be non-exclusive, so that a later driver would still be allowed later on to request that GPIO later on and manage it itself (ideally using the usual gpiod_request function). Actually we have a plan (and I have some code too) to allow multiple consumers per GPIO. Although like Benoit I wonder why you would want to hog a GPIO and then request it properly later. Also, that probably means we should abandon the hog since it actively drives the line and would interfere with the late requested. How to do that correctly is not really clear to me. I don't get the usecase. A hogged GPIO is per definition hogged. This sounds more like initial settings or something, which is another usecase altogether. Yours, Linus Walleij -- 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/
Re: [Patch v2 1/2] gpio: add GPIO hogging mechanism
On Tue, Dec 02, 2014 at 03:29:46PM +0100, Linus Walleij wrote: On Tue, Dec 2, 2014 at 3:13 PM, Alexandre Courbot gnu...@gmail.com wrote: On Tue, Dec 2, 2014 at 1:36 AM, Maxime Ripard maxime.rip...@free-electrons.com wrote: The only thing I'd like to have would be that the request here would be non-exclusive, so that a later driver would still be allowed later on to request that GPIO later on and manage it itself (ideally using the usual gpiod_request function). Actually we have a plan (and I have some code too) to allow multiple consumers per GPIO. Although like Benoit I wonder why you would want to hog a GPIO and then request it properly later. Also, that probably means we should abandon the hog since it actively drives the line and would interfere with the late requested. How to do that correctly is not really clear to me. I don't get the usecase. A hogged GPIO is per definition hogged. This sounds more like initial settings or something, which is another usecase altogether. We do have one board where we have a pin (let's say GPIO14 of the bank A) that enables a regulator that will provide VCC the bank B. Now, both banks are handled by the same driver, but in order to have a working output on the bank B, we do need to set GPIO14 as soon as we're probed. Just relying on the usual deferred probing introduces a circular dependency between the gpio-regulator that needs to grab its GPIO from a driver not there yet, and the gpio driver that needs to enable its gpio-regulator. GPIO hogging needs to be the ideal solution for that, since we can just enforce the GPIO14 value as the driver is probed, which provides the guarantee that any driver using the bank B will actually drive the GPIO it might use. However, an exclusive request will prevent any representation of this as a regulator, which sounds a bit weird, since it really is just that. Maxime -- Maxime Ripard, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com signature.asc Description: Digital signature
Re: [Patch v2 1/2] gpio: add GPIO hogging mechanism
Maxime Ripard wrote on Mon [2014-Dec-01
17:36:39 +0100]:
> Hi,
>
> On Fri, Nov 28, 2014 at 04:30:01PM +0900, Alexandre Courbot wrote:
> > > +/**
> > > + * do_gpio_hog - Given node is a GPIO hog configuration, handle it
> > > + * @np:device node to get GPIO from
> > > + *
> > > + * This is only used by of_gpiochip_add to request/set GPIO initial
> > > + * configuration.
> > > + */
> > > +static int do_gpio_hog(struct device_node *np)
> > > +{
> > > + struct gpio_desc *desc = NULL;
> > > + int err;
> > > + const char *name;
> > > + enum gpio_lookup_flags lflags;
> > > + enum gpiod_flags dflags;
> > > +
> > > + desc = of_get_gpio_hog(np, , , );
> > > + if (!desc)
> > > + return -ENOTSUPP;
> > > + else if (IS_ERR(desc))
> > > + return PTR_ERR(desc);
> > > +
> > > + err = gpiod_request(desc, name);
> >
> > Using this function means that a GPIO chip module cannot be unloaded
> > if it uses GPIO hogs. Is it the intended behavior? If not, please use
> > gpiochip_request_own_desc() instead, and make sure to call
> > gpiochip_free_own_desc() for each hog when the driver is unloaded.
>
> The only thing I'd like to have would be that the request here would
> be non-exclusive, so that a later driver would still be allowed later
> on to request that GPIO later on and manage it itself (ideally using
> the usual gpiod_request function).
I'll let Linus chime in on this.
But the premise for the hogging mechanism is to have a mechanism to set GPIOs
which do not need to be requested by any other entity.
If a driver needs access to a specific GPIO then it should use the existing
gpiolib API to request it and set it up.
>
> Maxime
>
> --
> Maxime Ripard, Free Electrons
> Embedded Linux, Kernel and Android engineering
> http://free-electrons.com
Regards,
Benoit
--
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/
Re: [Patch v2 1/2] gpio: add GPIO hogging mechanism
Alexandre Courbot wrote on Fri [2014-Nov-28 16:30:01 +0900]:
> On Fri, Nov 21, 2014 at 8:54 AM, Benoit Parrot wrote:
> > Based on Boris Brezillion's work this is a reworked patch
> > of his initial GPIO hogging mechanism.
> > This patch provides a way to initally configure specific GPIO
> > when the gpio controller is probed.
> >
> > The actual DT scanning to collect the GPIO specific data is performed
> > as part of the gpiochip_add().
> >
> > The purpose of this is to allows specific GPIOs to be configured
> > without any driver specific code.
> > This particularly useful because board design are getting
> > increasingly complex and given SoC pins can now have upward
> > of 10 mux values a lot of connections are now dependent on
> > external IO muxes to switch various modes and combination.
> >
> > Specific drivers should not necessarily need to be aware of
> > what accounts to a specific board implementation. This board level
> > "description" should be best kept as part of the dts file.
> >
> > Signed-off-by: Benoit Parrot
> > ---
> > Changes since v1:
> > * Refactor the gpio-hog mechanism as private functions meant to
> >be to invoked from of_gpiochip_add().
> >
> > drivers/gpio/gpiolib-of.c | 188
> > ++
> > 1 file changed, 188 insertions(+)
> >
> > diff --git a/drivers/gpio/gpiolib-of.c b/drivers/gpio/gpiolib-of.c
> > index 604dbe6..3caed76 100644
> > --- a/drivers/gpio/gpiolib-of.c
> > +++ b/drivers/gpio/gpiolib-of.c
> > @@ -22,6 +22,7 @@
> > #include
> > #include
> > #include
> > +#include
> >
> > #include "gpiolib.h"
> >
> > @@ -111,6 +112,184 @@ int of_get_named_gpio_flags(struct device_node *np,
> > const char *list_name,
> > EXPORT_SYMBOL(of_get_named_gpio_flags);
> >
> > /**
> > + * of_get_gpio_hog() - Get a GPIO hog descriptor, names and flags for GPIO
> > API
> > + * @np:device node to get GPIO from
> > + * @name: GPIO line name
> > + * @flags: a flags pointer to fill in
> > + *
> > + * Returns GPIO descriptor to use with Linux GPIO API, or one of the errno
> > + * value on the error condition.
> > + */
> > +
> > +static struct gpio_desc *of_get_gpio_hog(struct device_node *np,
> > + const char **name,
> > + enum gpio_lookup_flags *lflags,
> > + enum gpiod_flags *dflags)
> > +{
> > + struct device_node *chip_np;
> > + enum of_gpio_flags xlate_flags;
> > + struct gpio_desc *desc;
> > + struct gg_data gg_data = {
> > + .flags = _flags,
> > + .out_gpio = NULL,
> > + };
> > + u32 tmp;
> > + int i, in, outlo, outhi;
> > + int ret;
> > +
> > + if (!np)
> > + return ERR_PTR(-EINVAL);
>
> This function is being called from a perfectly mastered context in
> this file, so maybe we can avoid this check.
You are correct, I will change this.
>
> > +
> > + chip_np = np->parent;
> > + if (!chip_np) {
> > + desc = ERR_PTR(-EINVAL);
> > + goto out;
> > + }
> > +
> > + if (!lflags || !dflags) {
> > + desc = ERR_PTR(-EINVAL);
> > + goto out;
> > + }
>
> Same for this one.
Agreed.
>
> > +
> > + *lflags = 0;
> > + *dflags = 0;
> > + in = 0;
> > + outlo = 0;
> > + outhi = 0;
> > +
> > + ret = of_property_read_u32(chip_np, "#gpio-cells", );
> > + if (ret) {
> > + desc = ERR_PTR(ret);
> > + goto out;
>
> Please use "return ERR_PTR(ret);" directly, since you do absolutely no
> cleanup in out:. Same remark everywhere it applies.
Agreed.
>
> > + }
> > +
> > + if (tmp > MAX_PHANDLE_ARGS) {
> > + desc = ERR_PTR(-EINVAL);
> > + goto out;
> > + }
> > +
> > + gg_data.gpiospec.args_count = tmp;
> > + gg_data.gpiospec.np = chip_np;
> > + for (i = 0; i < tmp; i++) {
> > + ret = of_property_read_u32(np, "gpios",
> > + _data.gpiospec.args[i]);
> > + if (ret) {
> > + desc = ERR_PTR(ret);
> > + goto out;
> > + }
> > + }
> > +
> > + gpiochip_find(_data, of_gpiochip_find_and_xlate);
>
> This seems to work but only supports one GPIO per hog node. It would
> be nice to be able to specify several GPIOs to which the same settings
> need to be applied.
This is on purpose following Linus Walleij's comment.
>
> > + if (!gg_data.out_gpio) {
> > + if (np->parent == np)
> > + desc = ERR_PTR(-ENXIO);
> > + else
> > + desc = ERR_PTR(-EPROBE_DEFER);
> > + goto out;
> > + }
> > +
> > + if (xlate_flags & OF_GPIO_ACTIVE_LOW)
> > + *lflags |= GPIOF_ACTIVE_LOW;
> > +
> > + if
Re: [Patch v2 1/2] gpio: add GPIO hogging mechanism
Hi,
On Fri, Nov 28, 2014 at 04:30:01PM +0900, Alexandre Courbot wrote:
> > +/**
> > + * do_gpio_hog - Given node is a GPIO hog configuration, handle it
> > + * @np:device node to get GPIO from
> > + *
> > + * This is only used by of_gpiochip_add to request/set GPIO initial
> > + * configuration.
> > + */
> > +static int do_gpio_hog(struct device_node *np)
> > +{
> > + struct gpio_desc *desc = NULL;
> > + int err;
> > + const char *name;
> > + enum gpio_lookup_flags lflags;
> > + enum gpiod_flags dflags;
> > +
> > + desc = of_get_gpio_hog(np, , , );
> > + if (!desc)
> > + return -ENOTSUPP;
> > + else if (IS_ERR(desc))
> > + return PTR_ERR(desc);
> > +
> > + err = gpiod_request(desc, name);
>
> Using this function means that a GPIO chip module cannot be unloaded
> if it uses GPIO hogs. Is it the intended behavior? If not, please use
> gpiochip_request_own_desc() instead, and make sure to call
> gpiochip_free_own_desc() for each hog when the driver is unloaded.
The only thing I'd like to have would be that the request here would
be non-exclusive, so that a later driver would still be allowed later
on to request that GPIO later on and manage it itself (ideally using
the usual gpiod_request function).
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
signature.asc
Description: Digital signature
Re: [Patch v2 1/2] gpio: add GPIO hogging mechanism
Alexandre Courbot gnu...@gmail.com wrote on Fri [2014-Nov-28 16:30:01 +0900]:
On Fri, Nov 21, 2014 at 8:54 AM, Benoit Parrot bpar...@ti.com wrote:
Based on Boris Brezillion's work this is a reworked patch
of his initial GPIO hogging mechanism.
This patch provides a way to initally configure specific GPIO
when the gpio controller is probed.
The actual DT scanning to collect the GPIO specific data is performed
as part of the gpiochip_add().
The purpose of this is to allows specific GPIOs to be configured
without any driver specific code.
This particularly useful because board design are getting
increasingly complex and given SoC pins can now have upward
of 10 mux values a lot of connections are now dependent on
external IO muxes to switch various modes and combination.
Specific drivers should not necessarily need to be aware of
what accounts to a specific board implementation. This board level
description should be best kept as part of the dts file.
Signed-off-by: Benoit Parrot bpar...@ti.com
---
Changes since v1:
* Refactor the gpio-hog mechanism as private functions meant to
be to invoked from of_gpiochip_add().
drivers/gpio/gpiolib-of.c | 188
++
1 file changed, 188 insertions(+)
diff --git a/drivers/gpio/gpiolib-of.c b/drivers/gpio/gpiolib-of.c
index 604dbe6..3caed76 100644
--- a/drivers/gpio/gpiolib-of.c
+++ b/drivers/gpio/gpiolib-of.c
@@ -22,6 +22,7 @@
#include linux/of_gpio.h
#include linux/pinctrl/pinctrl.h
#include linux/slab.h
+#include linux/gpio/machine.h
#include gpiolib.h
@@ -111,6 +112,184 @@ int of_get_named_gpio_flags(struct device_node *np,
const char *list_name,
EXPORT_SYMBOL(of_get_named_gpio_flags);
/**
+ * of_get_gpio_hog() - Get a GPIO hog descriptor, names and flags for GPIO
API
+ * @np:device node to get GPIO from
+ * @name: GPIO line name
+ * @flags: a flags pointer to fill in
+ *
+ * Returns GPIO descriptor to use with Linux GPIO API, or one of the errno
+ * value on the error condition.
+ */
+
+static struct gpio_desc *of_get_gpio_hog(struct device_node *np,
+ const char **name,
+ enum gpio_lookup_flags *lflags,
+ enum gpiod_flags *dflags)
+{
+ struct device_node *chip_np;
+ enum of_gpio_flags xlate_flags;
+ struct gpio_desc *desc;
+ struct gg_data gg_data = {
+ .flags = xlate_flags,
+ .out_gpio = NULL,
+ };
+ u32 tmp;
+ int i, in, outlo, outhi;
+ int ret;
+
+ if (!np)
+ return ERR_PTR(-EINVAL);
This function is being called from a perfectly mastered context in
this file, so maybe we can avoid this check.
You are correct, I will change this.
+
+ chip_np = np-parent;
+ if (!chip_np) {
+ desc = ERR_PTR(-EINVAL);
+ goto out;
+ }
+
+ if (!lflags || !dflags) {
+ desc = ERR_PTR(-EINVAL);
+ goto out;
+ }
Same for this one.
Agreed.
+
+ *lflags = 0;
+ *dflags = 0;
+ in = 0;
+ outlo = 0;
+ outhi = 0;
+
+ ret = of_property_read_u32(chip_np, #gpio-cells, tmp);
+ if (ret) {
+ desc = ERR_PTR(ret);
+ goto out;
Please use return ERR_PTR(ret); directly, since you do absolutely no
cleanup in out:. Same remark everywhere it applies.
Agreed.
+ }
+
+ if (tmp MAX_PHANDLE_ARGS) {
+ desc = ERR_PTR(-EINVAL);
+ goto out;
+ }
+
+ gg_data.gpiospec.args_count = tmp;
+ gg_data.gpiospec.np = chip_np;
+ for (i = 0; i tmp; i++) {
+ ret = of_property_read_u32(np, gpios,
+ gg_data.gpiospec.args[i]);
+ if (ret) {
+ desc = ERR_PTR(ret);
+ goto out;
+ }
+ }
+
+ gpiochip_find(gg_data, of_gpiochip_find_and_xlate);
This seems to work but only supports one GPIO per hog node. It would
be nice to be able to specify several GPIOs to which the same settings
need to be applied.
This is on purpose following Linus Walleij's comment.
+ if (!gg_data.out_gpio) {
+ if (np-parent == np)
+ desc = ERR_PTR(-ENXIO);
+ else
+ desc = ERR_PTR(-EPROBE_DEFER);
+ goto out;
+ }
+
+ if (xlate_flags OF_GPIO_ACTIVE_LOW)
+ *lflags |= GPIOF_ACTIVE_LOW;
+
+ if (of_property_read_bool(np, input)) {
+ *dflags |= GPIOD_IN;
+ in = 1;
+ }
+ if (of_property_read_bool(np, output-low))
Re: [Patch v2 1/2] gpio: add GPIO hogging mechanism
Maxime Ripard maxime.rip...@free-electrons.com wrote on Mon [2014-Dec-01
17:36:39 +0100]:
Hi,
On Fri, Nov 28, 2014 at 04:30:01PM +0900, Alexandre Courbot wrote:
+/**
+ * do_gpio_hog - Given node is a GPIO hog configuration, handle it
+ * @np:device node to get GPIO from
+ *
+ * This is only used by of_gpiochip_add to request/set GPIO initial
+ * configuration.
+ */
+static int do_gpio_hog(struct device_node *np)
+{
+ struct gpio_desc *desc = NULL;
+ int err;
+ const char *name;
+ enum gpio_lookup_flags lflags;
+ enum gpiod_flags dflags;
+
+ desc = of_get_gpio_hog(np, name, lflags, dflags);
+ if (!desc)
+ return -ENOTSUPP;
+ else if (IS_ERR(desc))
+ return PTR_ERR(desc);
+
+ err = gpiod_request(desc, name);
Using this function means that a GPIO chip module cannot be unloaded
if it uses GPIO hogs. Is it the intended behavior? If not, please use
gpiochip_request_own_desc() instead, and make sure to call
gpiochip_free_own_desc() for each hog when the driver is unloaded.
The only thing I'd like to have would be that the request here would
be non-exclusive, so that a later driver would still be allowed later
on to request that GPIO later on and manage it itself (ideally using
the usual gpiod_request function).
I'll let Linus chime in on this.
But the premise for the hogging mechanism is to have a mechanism to set GPIOs
which do not need to be requested by any other entity.
If a driver needs access to a specific GPIO then it should use the existing
gpiolib API to request it and set it up.
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
Regards,
Benoit
--
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/
Re: [Patch v2 1/2] gpio: add GPIO hogging mechanism
Hi,
On Fri, Nov 28, 2014 at 04:30:01PM +0900, Alexandre Courbot wrote:
+/**
+ * do_gpio_hog - Given node is a GPIO hog configuration, handle it
+ * @np:device node to get GPIO from
+ *
+ * This is only used by of_gpiochip_add to request/set GPIO initial
+ * configuration.
+ */
+static int do_gpio_hog(struct device_node *np)
+{
+ struct gpio_desc *desc = NULL;
+ int err;
+ const char *name;
+ enum gpio_lookup_flags lflags;
+ enum gpiod_flags dflags;
+
+ desc = of_get_gpio_hog(np, name, lflags, dflags);
+ if (!desc)
+ return -ENOTSUPP;
+ else if (IS_ERR(desc))
+ return PTR_ERR(desc);
+
+ err = gpiod_request(desc, name);
Using this function means that a GPIO chip module cannot be unloaded
if it uses GPIO hogs. Is it the intended behavior? If not, please use
gpiochip_request_own_desc() instead, and make sure to call
gpiochip_free_own_desc() for each hog when the driver is unloaded.
The only thing I'd like to have would be that the request here would
be non-exclusive, so that a later driver would still be allowed later
on to request that GPIO later on and manage it itself (ideally using
the usual gpiod_request function).
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
signature.asc
Description: Digital signature
Re: [Patch v2 1/2] gpio: add GPIO hogging mechanism
On Fri, Nov 21, 2014 at 8:54 AM, Benoit Parrot wrote:
> Based on Boris Brezillion's work this is a reworked patch
> of his initial GPIO hogging mechanism.
> This patch provides a way to initally configure specific GPIO
> when the gpio controller is probed.
>
> The actual DT scanning to collect the GPIO specific data is performed
> as part of the gpiochip_add().
>
> The purpose of this is to allows specific GPIOs to be configured
> without any driver specific code.
> This particularly useful because board design are getting
> increasingly complex and given SoC pins can now have upward
> of 10 mux values a lot of connections are now dependent on
> external IO muxes to switch various modes and combination.
>
> Specific drivers should not necessarily need to be aware of
> what accounts to a specific board implementation. This board level
> "description" should be best kept as part of the dts file.
>
> Signed-off-by: Benoit Parrot
> ---
> Changes since v1:
> * Refactor the gpio-hog mechanism as private functions meant to
>be to invoked from of_gpiochip_add().
>
> drivers/gpio/gpiolib-of.c | 188
> ++
> 1 file changed, 188 insertions(+)
>
> diff --git a/drivers/gpio/gpiolib-of.c b/drivers/gpio/gpiolib-of.c
> index 604dbe6..3caed76 100644
> --- a/drivers/gpio/gpiolib-of.c
> +++ b/drivers/gpio/gpiolib-of.c
> @@ -22,6 +22,7 @@
> #include
> #include
> #include
> +#include
>
> #include "gpiolib.h"
>
> @@ -111,6 +112,184 @@ int of_get_named_gpio_flags(struct device_node *np,
> const char *list_name,
> EXPORT_SYMBOL(of_get_named_gpio_flags);
>
> /**
> + * of_get_gpio_hog() - Get a GPIO hog descriptor, names and flags for GPIO
> API
> + * @np:device node to get GPIO from
> + * @name: GPIO line name
> + * @flags: a flags pointer to fill in
> + *
> + * Returns GPIO descriptor to use with Linux GPIO API, or one of the errno
> + * value on the error condition.
> + */
> +
> +static struct gpio_desc *of_get_gpio_hog(struct device_node *np,
> + const char **name,
> + enum gpio_lookup_flags *lflags,
> + enum gpiod_flags *dflags)
> +{
> + struct device_node *chip_np;
> + enum of_gpio_flags xlate_flags;
> + struct gpio_desc *desc;
> + struct gg_data gg_data = {
> + .flags = _flags,
> + .out_gpio = NULL,
> + };
> + u32 tmp;
> + int i, in, outlo, outhi;
> + int ret;
> +
> + if (!np)
> + return ERR_PTR(-EINVAL);
This function is being called from a perfectly mastered context in
this file, so maybe we can avoid this check.
> +
> + chip_np = np->parent;
> + if (!chip_np) {
> + desc = ERR_PTR(-EINVAL);
> + goto out;
> + }
> +
> + if (!lflags || !dflags) {
> + desc = ERR_PTR(-EINVAL);
> + goto out;
> + }
Same for this one.
> +
> + *lflags = 0;
> + *dflags = 0;
> + in = 0;
> + outlo = 0;
> + outhi = 0;
> +
> + ret = of_property_read_u32(chip_np, "#gpio-cells", );
> + if (ret) {
> + desc = ERR_PTR(ret);
> + goto out;
Please use "return ERR_PTR(ret);" directly, since you do absolutely no
cleanup in out:. Same remark everywhere it applies.
> + }
> +
> + if (tmp > MAX_PHANDLE_ARGS) {
> + desc = ERR_PTR(-EINVAL);
> + goto out;
> + }
> +
> + gg_data.gpiospec.args_count = tmp;
> + gg_data.gpiospec.np = chip_np;
> + for (i = 0; i < tmp; i++) {
> + ret = of_property_read_u32(np, "gpios",
> + _data.gpiospec.args[i]);
> + if (ret) {
> + desc = ERR_PTR(ret);
> + goto out;
> + }
> + }
> +
> + gpiochip_find(_data, of_gpiochip_find_and_xlate);
This seems to work but only supports one GPIO per hog node. It would
be nice to be able to specify several GPIOs to which the same settings
need to be applied.
> + if (!gg_data.out_gpio) {
> + if (np->parent == np)
> + desc = ERR_PTR(-ENXIO);
> + else
> + desc = ERR_PTR(-EPROBE_DEFER);
> + goto out;
> + }
> +
> + if (xlate_flags & OF_GPIO_ACTIVE_LOW)
> + *lflags |= GPIOF_ACTIVE_LOW;
> +
> + if (of_property_read_bool(np, "input")) {
> + *dflags |= GPIOD_IN;
> + in = 1;
> + }
> + if (of_property_read_bool(np, "output-low")) {
> + *dflags |= GPIOD_OUT_LOW;
> + outlo = 1;
> + }
> + if (of_property_read_bool(np, "output-high")) {
> + *dflags |= GPIOD_OUT_HIGH;
> + outhi = 1;
> + }
I thought we agreed that this should be a "direction =
Re: [Patch v2 1/2] gpio: add GPIO hogging mechanism
On Fri, Nov 21, 2014 at 8:54 AM, Benoit Parrot bpar...@ti.com wrote:
Based on Boris Brezillion's work this is a reworked patch
of his initial GPIO hogging mechanism.
This patch provides a way to initally configure specific GPIO
when the gpio controller is probed.
The actual DT scanning to collect the GPIO specific data is performed
as part of the gpiochip_add().
The purpose of this is to allows specific GPIOs to be configured
without any driver specific code.
This particularly useful because board design are getting
increasingly complex and given SoC pins can now have upward
of 10 mux values a lot of connections are now dependent on
external IO muxes to switch various modes and combination.
Specific drivers should not necessarily need to be aware of
what accounts to a specific board implementation. This board level
description should be best kept as part of the dts file.
Signed-off-by: Benoit Parrot bpar...@ti.com
---
Changes since v1:
* Refactor the gpio-hog mechanism as private functions meant to
be to invoked from of_gpiochip_add().
drivers/gpio/gpiolib-of.c | 188
++
1 file changed, 188 insertions(+)
diff --git a/drivers/gpio/gpiolib-of.c b/drivers/gpio/gpiolib-of.c
index 604dbe6..3caed76 100644
--- a/drivers/gpio/gpiolib-of.c
+++ b/drivers/gpio/gpiolib-of.c
@@ -22,6 +22,7 @@
#include linux/of_gpio.h
#include linux/pinctrl/pinctrl.h
#include linux/slab.h
+#include linux/gpio/machine.h
#include gpiolib.h
@@ -111,6 +112,184 @@ int of_get_named_gpio_flags(struct device_node *np,
const char *list_name,
EXPORT_SYMBOL(of_get_named_gpio_flags);
/**
+ * of_get_gpio_hog() - Get a GPIO hog descriptor, names and flags for GPIO
API
+ * @np:device node to get GPIO from
+ * @name: GPIO line name
+ * @flags: a flags pointer to fill in
+ *
+ * Returns GPIO descriptor to use with Linux GPIO API, or one of the errno
+ * value on the error condition.
+ */
+
+static struct gpio_desc *of_get_gpio_hog(struct device_node *np,
+ const char **name,
+ enum gpio_lookup_flags *lflags,
+ enum gpiod_flags *dflags)
+{
+ struct device_node *chip_np;
+ enum of_gpio_flags xlate_flags;
+ struct gpio_desc *desc;
+ struct gg_data gg_data = {
+ .flags = xlate_flags,
+ .out_gpio = NULL,
+ };
+ u32 tmp;
+ int i, in, outlo, outhi;
+ int ret;
+
+ if (!np)
+ return ERR_PTR(-EINVAL);
This function is being called from a perfectly mastered context in
this file, so maybe we can avoid this check.
+
+ chip_np = np-parent;
+ if (!chip_np) {
+ desc = ERR_PTR(-EINVAL);
+ goto out;
+ }
+
+ if (!lflags || !dflags) {
+ desc = ERR_PTR(-EINVAL);
+ goto out;
+ }
Same for this one.
+
+ *lflags = 0;
+ *dflags = 0;
+ in = 0;
+ outlo = 0;
+ outhi = 0;
+
+ ret = of_property_read_u32(chip_np, #gpio-cells, tmp);
+ if (ret) {
+ desc = ERR_PTR(ret);
+ goto out;
Please use return ERR_PTR(ret); directly, since you do absolutely no
cleanup in out:. Same remark everywhere it applies.
+ }
+
+ if (tmp MAX_PHANDLE_ARGS) {
+ desc = ERR_PTR(-EINVAL);
+ goto out;
+ }
+
+ gg_data.gpiospec.args_count = tmp;
+ gg_data.gpiospec.np = chip_np;
+ for (i = 0; i tmp; i++) {
+ ret = of_property_read_u32(np, gpios,
+ gg_data.gpiospec.args[i]);
+ if (ret) {
+ desc = ERR_PTR(ret);
+ goto out;
+ }
+ }
+
+ gpiochip_find(gg_data, of_gpiochip_find_and_xlate);
This seems to work but only supports one GPIO per hog node. It would
be nice to be able to specify several GPIOs to which the same settings
need to be applied.
+ if (!gg_data.out_gpio) {
+ if (np-parent == np)
+ desc = ERR_PTR(-ENXIO);
+ else
+ desc = ERR_PTR(-EPROBE_DEFER);
+ goto out;
+ }
+
+ if (xlate_flags OF_GPIO_ACTIVE_LOW)
+ *lflags |= GPIOF_ACTIVE_LOW;
+
+ if (of_property_read_bool(np, input)) {
+ *dflags |= GPIOD_IN;
+ in = 1;
+ }
+ if (of_property_read_bool(np, output-low)) {
+ *dflags |= GPIOD_OUT_LOW;
+ outlo = 1;
+ }
+ if (of_property_read_bool(np, output-high)) {
+ *dflags |= GPIOD_OUT_HIGH;
+ outhi = 1;
+ }
I thought we agreed that this should be a direction =
input|output-low|output-high property?
+ if ((in +
