On Tue, 3 Aug 2021, at 20:03, Andy Shevchenko wrote:

On Tue, Aug 3, 2021 at 7:07 AM Andrew Jeffery [off-list ref] wrote:

quoted

On Thu, 29 Jul 2021, at 17:10, Andy Shevchenko wrote:

quoted

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

quoted

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

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.

Okay - I need to look at gpio-regmap, this wasn't something I was aware 
of.

Now what we need here is some kind of "virtual" pinmux. Do I
understand correctly?

Possibly. My thoughts went to pinctrl as part of its job is mutual 
exclusion *and* pin mapping, plus we get the nice debugfs interface 
with the pin allocation details. The need for pin mapping came from 
trying to stay true to the intent of the existing devicetree binding. 
If we throw that out and have the gpiochip cover the pin space for the 
chip then using pinctrl only gives us mutual exclusion and the debugfs 
interface. pinctrl seems pretty heavy-weight to use *just* for mutual 
exclusion - with no requirement for pin mapping I feel whether or not 
we go this way hinges on the utility of debugfs.

As outlined earlier, there's no mux hardware, the only thing that 
changes is software's intent.

To be clear: I do not like putting everything into one driver when the
logical parts may be separated.

Right, its already a bit unwieldy.

Andrew