Re: [PATCH v3 1/2] pinctrl: add support for ACPI pin function and config resources

[Andy Shevchenko <andriy.shevchenko@xxxxxxxxxxxxxxx>]

On Mon, Dec 05, 2022 at 07:20:24AM +0000, Niyas Sait wrote:
> On 01/12/2022 23:04, Andy Shevchenko wrote:
> > That's why third (?) time I'm asking you to provide a design level
> > documentation of your approach to understand it better.
> 
> Sorry Andy. I made a wrong assumption that the docs added would clarify
> things. I will put together a design document.
> 
> > The pin control has provider-consumer idea behind. When a*consumer*  device
> > is being probed, it tries to configure its pins based on the data collected
> > in the pin control device that*provides*  the resources. At this point of
> > time the pin control subsystem parses tables (currently DT and board files)
> > for that. For the pin control device itself, the registration of it also
> > parses tables but for the*provider*.
> > 
> > Now, the pin control device driver (*provider*) may or may not have
> > (a subset of) the pin functions and pin groups hard coded in the driver.
> > This can be used by the pin control subsystem as well as data that comes
> > from the tables. The data from the tables, nevertheless, is not really
> > needs names of the functions, because it's not what is programmed into
> > HW registers. That's why when driver doesn't have that information, it's
> > fine to generate it.
> > 
> > Also note, that in ACPI all Pin*() descriptors are optional and we need
> > to cover all such cases, I already pointed out to my preliminary research,
> > which I have done 5 years ago, where I tried to understand how it should
> > be covered for the most used cases.
> > 
> > I think I stopped with my solution in particular due to the problems with
> > the power management interaction with pin control, i.e. string-based odd
> > states (4 of which are hard coded in the pin control core code).
> 
> Let's start with the design document. ACPI have far fewer information for
> the pin controller compared to DT.

Exactly.

> I am not quite sure how we can generate
> data from Pin(*) descriptions for the pin controller reliably.

Yep, and this what we need to discuss.

> Let me first
> put together the design document, hopefully that will help.

Yes, please! And thank you for pumping up the topic, sooner or later we need to
bring a solution to this.

-- 
With Best Regards,
Andy Shevchenko