linux-gpio.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Niyas Sait <niyas.sait@linaro.org>
To: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Cc: linux-gpio@vger.kernel.org, mika.westerberg@linux.intel.com,
	rafael@kernel.org, linus.walleij@linaro.org,
	fugang.duan@linaro.org
Subject: Re: [PATCH v3 1/2] pinctrl: add support for ACPI pin function and config resources
Date: Mon, 5 Dec 2022 07:20:24 +0000	[thread overview]
Message-ID: <ae60701e-a2f1-4945-d9e0-e8ecd1c82f62@linaro.org> (raw)
In-Reply-To: <Y4kzG3K1LlC5ZcQi@smile.fi.intel.com>



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

  reply	other threads:[~2022-12-05  7:20 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-11-30 16:40 [PATCH v3 0/2] pinctrl: add ACPI support to pin controller Niyas Sait
2022-11-30 16:40 ` [PATCH v3 1/2] pinctrl: add support for ACPI pin function and config resources Niyas Sait
2022-11-30 21:02   ` Andy Shevchenko
2022-11-30 21:33     ` Niyas Sait
2022-11-30 23:30       ` Andy Shevchenko
2022-12-01  9:27         ` Niyas Sait
2022-12-01 23:04           ` Andy Shevchenko
2022-12-05  7:20             ` Niyas Sait [this message]
2022-12-05 12:47               ` Andy Shevchenko
2022-12-20 10:53                 ` Niyas Sait
2023-01-03 16:49                   ` Niyas Sait
2023-01-09 14:09                     ` Andy Shevchenko
2023-01-09 21:33                       ` Niyas Sait
2022-11-30 21:10   ` Andy Shevchenko
2022-11-30 21:36     ` Niyas Sait
2022-11-30 16:40 ` [PATCH v3 2/2] pinctrl: add support for ACPI pin groups Niyas Sait

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=ae60701e-a2f1-4945-d9e0-e8ecd1c82f62@linaro.org \
    --to=niyas.sait@linaro.org \
    --cc=andriy.shevchenko@linux.intel.com \
    --cc=fugang.duan@linaro.org \
    --cc=linus.walleij@linaro.org \
    --cc=linux-gpio@vger.kernel.org \
    --cc=mika.westerberg@linux.intel.com \
    --cc=rafael@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).