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. I am not quite sure how we can generate data from Pin(*) descriptions for the pin controller reliably. Let me first put together the design document, hopefully that will help.
-- Niyas
