On Thu, 29 Jul 2021, at 17:10, Andy Shevchenko wrote: > On Thu, Jul 29, 2021 at 3:39 AM Andrew Jeffery <andrew@xxxxxxxx> wrote: > > On Wed, 28 Jul 2021, at 18:43, Andy Shevchenko wrote: > > > On Wed, Jul 28, 2021 at 8:43 AM Andrew Jeffery <andrew@xxxxxxxx> 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? I don't have a need to implement a PWM driver for it right now but that would make sense to do at some point. Andrew
