On Thu, Jul 29, 2021 at 3:39 AM Andrew Jeffery [off-list ref] wrote:

On Wed, 28 Jul 2021, at 18:43, Andy Shevchenko wrote:

quoted

On Wed, Jul 28, 2021 at 8:43 AM Andrew Jeffery [off-list ref] wrote:

quoted

On Fri, 23 Jul 2021, at 17:45, Andy Shevchenko wrote:

quoted

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.

quoted

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.

quoted

quoted

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).


-- 
With Best Regards,
Andy Shevchenko