| Message ID | 20210723075858.376378-1-andrew@aj.id.au |
|---|---|
| Headers | show |
| Series | leds: Fix pca955x GPIO pin mappings | expand |
On Fri, 23 Jul 2021, at 17:45, Andy Shevchenko wrote: > > > On Friday, July 23, 2021, Andrew Jeffery <andrew@aj.id.au> wrote: > > Hello, > > > > This series does a bunch of crimes, so it's an RFC. I'm cross-posting to the > > pinctrl/GPIO and LEDs lists because the PCA955x devices impact all of them. What > > needs fixing is the leds-pca955x driver's failure to map the GPIO numberspace to > > the pin numberspace of the PCA955x devices. The series solves that by > > implementing pinctrl and pinmux in the leds-pca955x driver. > > > > Things I'm unsure about: > > > > 1. Patch 1: The pinctrl_gpio_as_pin() API feels a bit dirty, not sure what > > others thoughts are on that (Linus?). > > > > 2. Patch 2: I've added a new callback to hook the entirety of the pinctrl map > > parsing rather than supplying a subnode-specific callback. This was necessary > > to handle the PCA955x devicetree binding in a backwards compatible way. > > > > 3. Patch 4: The PCA955x devices don't actually have any pinmux hardware, but the > > properties of the pinctrl/pinmux subsystems in the kernel map nicely onto the > > problem we have. But it's quite a bit of code... > > > > 4. Patch 6: I also lost a bunch of time to overlooking the get_group_pins() > > callback for pinctrl, and it seems odd to me that it isn't required. > > > > Please review! > > > Sounds like a hack. Yes, possibly. Feedback like this is why I sent the series as an RFC. > I was briefly looking into patches 1-4 and suddenly > realized that the fix can be similar as in PCA9685 (PWM), I.e. we > always have chips for the entire pin space and one may map them > accordingly, requested in one realm (LED) in the other (GPIO) > automatically is BUSY. Or I missed the point? No, you haven't missed the point. I will look at the PCA9685 driver. That said, my goal was to implement the behaviour intended by the existing binding (i.e. fix a bug). However, userspace would never have got the results it expected with the existing driver implementation, so I guess you could argue that no such (useful) userspace exists. Given that, we could adopt the strategy of always defining a gpiochip covering the whole pin space, and parts of the devicetree binding just become redundant. Andrew
On Wed, Jul 28, 2021 at 8:43 AM Andrew Jeffery <andrew@aj.id.au> wrote: > On Fri, 23 Jul 2021, at 17:45, Andy Shevchenko wrote: > > On Friday, July 23, 2021, Andrew Jeffery <andrew@aj.id.au> wrote: > > > This series does a bunch of crimes, so it's an RFC. I'm cross-posting to the > > > pinctrl/GPIO and LEDs lists because the PCA955x devices impact all of them. What > > > needs fixing is the leds-pca955x driver's failure to map the GPIO numberspace to > > > the pin numberspace of the PCA955x devices. The series solves that by > > > implementing pinctrl and pinmux in the leds-pca955x driver. > > > > > > Things I'm unsure about: > > > > > > 1. Patch 1: The pinctrl_gpio_as_pin() API feels a bit dirty, not sure what > > > others thoughts are on that (Linus?). > > > > > > 2. Patch 2: I've added a new callback to hook the entirety of the pinctrl map > > > parsing rather than supplying a subnode-specific callback. This was necessary > > > to handle the PCA955x devicetree binding in a backwards compatible way. > > > > > > 3. Patch 4: The PCA955x devices don't actually have any pinmux hardware, but the > > > properties of the pinctrl/pinmux subsystems in the kernel map nicely onto the > > > problem we have. But it's quite a bit of code... > > > > > > 4. Patch 6: I also lost a bunch of time to overlooking the get_group_pins() > > > callback for pinctrl, and it seems odd to me that it isn't required. > > > > > > Please review! > > > > > > Sounds like a hack. > > Yes, possibly. Feedback like this is why I sent the series as an RFC. > > > I was briefly looking into patches 1-4 and suddenly > > realized that the fix can be similar as in PCA9685 (PWM), I.e. we > > always have chips for the entire pin space and one may map them > > accordingly, requested in one realm (LED) in the other (GPIO) > > automatically is BUSY. Or I missed the point? > > No, you haven't missed the point. I will look at the PCA9685 driver. > > That said, my goal was to implement the behaviour intended by the > existing binding (i.e. fix a bug). Okay, so it implies that this used to work at some point. What has changed from that point? Why can't we simply fix the culprit commit? > However, userspace would never have > got the results it expected with the existing driver implementation, so > I guess you could argue that no such (useful) userspace exists. Given > that, we could adopt the strategy of always defining a gpiochip > covering the whole pin space, and parts of the devicetree binding just > become redundant. I'm lost now. GPIO has its own userspace ABI, how does it work right now in application to this chip?
On Wed, 28 Jul 2021, at 18:43, Andy Shevchenko wrote: > On Wed, Jul 28, 2021 at 8:43 AM Andrew Jeffery <andrew@aj.id.au> wrote: > > On Fri, 23 Jul 2021, at 17:45, Andy Shevchenko wrote: > > > > > I was briefly looking into patches 1-4 and suddenly > > > realized that the fix can be similar as in PCA9685 (PWM), I.e. we > > > always have chips for the entire pin space and one may map them > > > accordingly, requested in one realm (LED) in the other (GPIO) > > > automatically is BUSY. Or I missed the point? > > > > No, you haven't missed the point. I will look at the PCA9685 driver. > > > > That said, my goal was to implement the behaviour intended by the > > existing binding (i.e. fix a bug). > > Okay, so it implies that this used to work at some point. I don't think this is true. It only "works" if the lines specified as GPIO in the devicetree are contiguous from line 0. That way the pin and GPIO number spaces align. I suspect that's all that's been tested up until this point. We now have a board with a PCA9552 where the first 8 pins are LED and the last 8 pins are GPIO, and if you specify this in the devicetree according to the binding you hit the failure to map between the two number spaces. > What has > changed from that point? Why can't we simply fix the culprit commit? As such nothing has changed, I think it's always been broken, just we haven't had hardware configurations that demonstrated the failure. > > > However, userspace would never have > > got the results it expected with the existing driver implementation, so > > I guess you could argue that no such (useful) userspace exists. Given > > that, we could adopt the strategy of always defining a gpiochip > > covering the whole pin space, and parts of the devicetree binding just > > become redundant. > > I'm lost now. GPIO has its own userspace ABI, how does it work right > now in application to this chip? As above, it "works" if the GPIOs specified in the devicetree are contiguous from line 0. It's broken if they're not. Andrew
On Thu, Jul 29, 2021 at 3:39 AM Andrew Jeffery <andrew@aj.id.au> wrote: > On Wed, 28 Jul 2021, at 18:43, Andy Shevchenko wrote: > > On Wed, Jul 28, 2021 at 8:43 AM Andrew Jeffery <andrew@aj.id.au> wrote: > > > On Fri, 23 Jul 2021, at 17:45, Andy Shevchenko wrote: > > > > > > > I was briefly looking into patches 1-4 and suddenly > > > > realized that the fix can be similar as in PCA9685 (PWM), I.e. we > > > > always have chips for the entire pin space and one may map them > > > > accordingly, requested in one realm (LED) in the other (GPIO) > > > > automatically is BUSY. Or I missed the point? > > > > > > No, you haven't missed the point. I will look at the PCA9685 driver. > > > > > > That said, my goal was to implement the behaviour intended by the > > > existing binding (i.e. fix a bug). > > > > Okay, so it implies that this used to work at some point. > > I don't think this is true. It only "works" if the lines specified as > GPIO in the devicetree are contiguous from line 0. That way the pin and > GPIO number spaces align. I suspect that's all that's been tested up > until this point. > > We now have a board with a PCA9552 where the first 8 pins are LED and > the last 8 pins are GPIO, and if you specify this in the devicetree > according to the binding you hit the failure to map between the two > number spaces. > > > What has > > changed from that point? Why can't we simply fix the culprit commit? > > As such nothing has changed, I think it's always been broken, just we > haven't had hardware configurations that demonstrated the failure. > > > > > > However, userspace would never have > > > got the results it expected with the existing driver implementation, so > > > I guess you could argue that no such (useful) userspace exists. Given > > > that, we could adopt the strategy of always defining a gpiochip > > > covering the whole pin space, and parts of the devicetree binding just > > > become redundant. > > > > I'm lost now. GPIO has its own userspace ABI, how does it work right > > now in application to this chip? > > As above, it "works" if the GPIOs specified in the devicetree are > contiguous from line 0. It's broken if they're not. So, "it never works" means there is no bug. Now, what we need is to keep the same enumeration scheme, but if you wish to be used half/half (or any other ratio), the driver should do like the above mentioned PWM, i.e. register entire space and depending on the requestor either proceed with a line or mark it as BUSY. Ideally, looking into what the chip can do, this should be indeed converted to some like pin control + PWM + LED + GPIO drivers. Then the function in pin mux configuration can show what exactly is enabled on the certain line(s).
On Tue, Aug 3, 2021 at 7:07 AM Andrew Jeffery <andrew@aj.id.au> wrote: > On Thu, 29 Jul 2021, at 17:10, Andy Shevchenko wrote: > > On Thu, Jul 29, 2021 at 3:39 AM Andrew Jeffery <andrew@aj.id.au> wrote: > > > On Wed, 28 Jul 2021, at 18:43, Andy Shevchenko wrote: > > > > On Wed, Jul 28, 2021 at 8:43 AM Andrew Jeffery <andrew@aj.id.au> wrote: > > > > > However, userspace would never have > > > > > got the results it expected with the existing driver implementation, so > > > > > I guess you could argue that no such (useful) userspace exists. Given > > > > > that, we could adopt the strategy of always defining a gpiochip > > > > > covering the whole pin space, and parts of the devicetree binding just > > > > > become redundant. > > > > > > > > I'm lost now. GPIO has its own userspace ABI, how does it work right > > > > now in application to this chip? > > > > > > As above, it "works" if the GPIOs specified in the devicetree are > > > contiguous from line 0. It's broken if they're not. > > > > So, "it never works" means there is no bug. Now, what we need is to > > keep the same enumeration scheme, but if you wish to be used half/half > > (or any other ratio), the driver should do like the above mentioned > > PWM, i.e. register entire space and depending on the requestor either > > proceed with a line or mark it as BUSY. > > > > Ideally, looking into what the chip can do, this should be indeed > > converted to some like pin control + PWM + LED + GPIO drivers. Then > > the function in pin mux configuration can show what exactly is enabled > > on the certain line(s). > > So just to clarify, you want both solutions here? > > 1. A gpiochip that covers the entire pin space > 2. A pinmux implementation that manages pin allocation to the different drivers > > In that case we can largely leave this series as is? We only need to > adjust how we configure the gpiochip by dropping the pin-mapping > implementation? Nope. It's far from what I think of. Re-reading again your cover letter it points out that pin mux per se does not exist in the hardware. In this case things become a bit too complicated, but we still may manage to handle them. Before I was thinking about this hierarchy 1. pinmux driver (which is actually the main driver here) 2. LED driver (using regmap API) 3. GPIO driver (via gpio-regmap) 4. PWM driver. Now what we need here is some kind of "virtual" pinmux. Do I understand correctly? To be clear: I do not like putting everything into one driver when the logical parts may be separated. -- With Best Regards, Andy Shevchenko
On Fri, Jul 23, 2021 at 9:59 AM Andrew Jeffery <andrew@aj.id.au> wrote: > Allow gpiochips to map the GPIO numberspace onto a pin numberspace when > the register layout for GPIO control is implemented in terms of the > pin numberspace. > > This requirement sounds kind of strange, but the patch is driven by > trying to resolve a bug in the leds-pca955x driver where this mapping is > not correctly performed. > > Signed-off-by: Andrew Jeffery <andrew@aj.id.au> (...) Hm this looks a bit strange... > +int pinctrl_gpio_as_pin(struct pinctrl_dev *pctldev, unsigned int gpio) This is not a good name for this function. Try to come up with a name that says exactly what the function does. E.g. "apple pear as apple slice" isn't very helpful, the use case for this is really hard to understand. > +EXPORT_SYMBOL_GPL(pinctrl_find_gpio_range_from_pin); This looks completely wrong. Yours, Linus Walleij
On Tue, 10 Aug 2021, at 23:04, Linus Walleij wrote: > On Fri, Jul 23, 2021 at 9:59 AM Andrew Jeffery <andrew@aj.id.au> wrote: > > > Allow gpiochips to map the GPIO numberspace onto a pin numberspace when > > the register layout for GPIO control is implemented in terms of the > > pin numberspace. > > > > This requirement sounds kind of strange, but the patch is driven by > > trying to resolve a bug in the leds-pca955x driver where this mapping is > > not correctly performed. > > > > Signed-off-by: Andrew Jeffery <andrew@aj.id.au> > > (...) > > Hm this looks a bit strange... > > > +int pinctrl_gpio_as_pin(struct pinctrl_dev *pctldev, unsigned int gpio) > > This is not a good name for this function. Try to come up with > a name that says exactly what the function does. > > E.g. "apple pear as apple slice" isn't very helpful, the use case for > this is really hard to understand. That's probably because I shouldn't be trying to do what I'm doing :) I'll stop doing that (i.e. rework patch 4/6) and this will go away entirely. > > > +EXPORT_SYMBOL_GPL(pinctrl_find_gpio_range_from_pin); > > This looks completely wrong. Yeah, whoops. That was an oversight while iterating on the patch. Andrew
Hello, This series does a bunch of crimes, so it's an RFC. I'm cross-posting to the pinctrl/GPIO and LEDs lists because the PCA955x devices impact all of them. What needs fixing is the leds-pca955x driver's failure to map the GPIO numberspace to the pin numberspace of the PCA955x devices. The series solves that by implementing pinctrl and pinmux in the leds-pca955x driver. Things I'm unsure about: 1. Patch 1: The pinctrl_gpio_as_pin() API feels a bit dirty, not sure what others thoughts are on that (Linus?). 2. Patch 2: I've added a new callback to hook the entirety of the pinctrl map parsing rather than supplying a subnode-specific callback. This was necessary to handle the PCA955x devicetree binding in a backwards compatible way. 3. Patch 4: The PCA955x devices don't actually have any pinmux hardware, but the properties of the pinctrl/pinmux subsystems in the kernel map nicely onto the problem we have. But it's quite a bit of code... 4. Patch 6: I also lost a bunch of time to overlooking the get_group_pins() callback for pinctrl, and it seems odd to me that it isn't required. Please review! Andrew Andrew Jeffery (6): pinctrl: Add pinctrl_gpio_as_pin() pinctrl: Add hook for device-specific map parsing leds: pca955x: Relocate chipdef-related descriptors leds: pca955x: Use pinctrl to map GPIOs to pins ARM: dts: rainier: Add presence-detect and fault indictor GPIO expander pinctrl: Check get_group_pins callback on init arch/arm/boot/dts/aspeed-bmc-ibm-rainier.dts | 76 +++ drivers/leds/leds-pca955x.c | 554 +++++++++++++++---- drivers/pinctrl/core.c | 28 +- include/linux/pinctrl/pinctrl.h | 4 + 4 files changed, 566 insertions(+), 96 deletions(-)