Re: [PATCH 4/5] pinctrl: Add pin controller driver for AAEON UP boards

[Andy Shevchenko <andriy.shevchenko@linux.intel.com>]

On Wed, Feb 05, 2025 at 12:17:29PM +0100, Thomas Richard wrote:
> On 1/16/25 15:14, Andy Shevchenko wrote:

...

> So I'm not really convinced by all this complexity for only one driver.

I am not sure if I asked you to show the excerpt from DSDT for this device.
Is there any link I can browse the ASL code (for that particular device,
most likely I wouldn't need the full DSDT)?

...

> In the same time I had an other idea and I would like your advises.
> 
> The FPGA pinctrl is a consumer of SoC pins, so I can add some
> pinctrl_map to request the SoC pins and mark them as used by the FPGA:
> 
> PIN_MAP_MUX_GROUP("upboard-pinctrl", "soc_pins", "INT3452:00",
> 		"pwm0_grp", "pwm0"),
> PIN_MAP_MUX_GROUP("upboard-pinctrl", "soc_pins", "INT3452:00",
> 		"uart1_grp", "uart1"),
> 
> And in the probe() I call devm_pinctrl_get_select() to request and
> configure SoC pins.
> 
> Pros:
> - the SoC pins are marked as used by the FPGA.
> - less complex solution, no change in the core.
> 
> Cons:
> - probably one mapping for each board as Intel pinctrl device, groups
> and functions may change depending the board. So the right mapping
> should be selected based on DMI table.

Yes, this solution is what we can do for now, I don't see the Cons part is
really cons as we do that in many drivers, but ideally, of course, this
information should come from DSDT. Saying this reminds me that we still have
a gap that should link the ACPICA resources for pin control and muxing to
the pin control layer in the Linux kernel. That's what we probably should
focus on instead of creating a pin control proxy driver which indeed sounds
like a complex and over engineered solution for a niche.

> This solution also implies to make some changes in Intel pinctrl driver
> to create missing groups. Or maybe the pins which are not in a group are
> not writeable (so no need to request them) ?

This is not a problem, it's an improvement in my opinion. Again, this,
of course, should come from DSDT (see the respective Pin*() resource
descriptions in the ACPI specification).

> For the GPIO part, no changes, the SoC GPIO are requested at runtime
> using gpiod (Linus I did not forget you mentioned to use/rework
> gpio-aggregator).

-- 
With Best Regards,
Andy Shevchenko