linux-gpio.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Michal Simek <michal.simek@xilinx.com>
To: Linus Walleij <linus.walleij@linaro.org>,
	Michal Simek <michal.simek@xilinx.com>
Cc: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	"open list:GPIO SUBSYSTEM" <linux-gpio@vger.kernel.org>,
	Sai Krishna Potthuri <lakshmi.sai.krishna.potthuri@xilinx.com>
Subject: Re: DT overlay applied via pinctrl description
Date: Mon, 1 Mar 2021 10:31:19 +0100	[thread overview]
Message-ID: <45cea3bb-6e5d-4005-ef2a-67b08772e0d7@xilinx.com> (raw)
In-Reply-To: <CACRpkdZEYqPU6Zr+a6fivZiz-hKx6-KVdYVR7j--y+k2KXZaPw@mail.gmail.com>

Hi Linus,

On 3/1/21 10:19 AM, Linus Walleij wrote:
> On Tue, Feb 16, 2021 at 4:35 PM Michal Simek <michal.simek@xilinx.com> wrote:
> 
>> I have a question about expectations when pinctrl setting is applied. In
>> DTS all nodes are described in the order available in DT.
>>
>> uart-default {
>>         mux {
>>                 ...
>>         };
>>
>>         conf {
>>                 ...
>>         };
>> };
>>
>> I don't know if this standard description or not. I definitely see other
>> pinctrl drivers which are using different structure.
>>
>> Anyway when overlay is applied the order has changed to
>> uart-default {
>>         conf {
>>                 ...
>>         };
>>
>>         mux {
>>                 ...
>>         };
>> };
>>
>> which is causing issue because pin is configured first via conf node
>> before it is requested via mux. This is something what firmware is
>> checking and error out.
> 
> As Frank says the DT ordering has no semantic meaning, it is essentially
> a functional language, describes object relations not sequences.
> 
> The Linux kernel applies the mux and conf in that order because of how
> the code is implemented (this order also makes a lot of sense for the
> hardware). I would recommend to trace the execution of an overlay
> being applied and try to find the reason conf goes before mux and fix
> the bug there. I think it is a bug in how pinctrl handles DT overlays.

Does this mean that you prefer to fix how dt overlay applying instead of
fixing code to apply mux configs first before conf one?

Something like this? (just c&p patch below)

Thanks,
Michal

diff --git a/drivers/pinctrl/core.c b/drivers/pinctrl/core.c
index 7d3370289938..cf56ee5d7e02 100644
--- a/drivers/pinctrl/core.c
+++ b/drivers/pinctrl/core.c
@@ -1258,13 +1258,35 @@ static int pinctrl_commit_state(struct pinctrl
*p, struct pinctrl_state *state)

        p->state = NULL;

-       /* Apply all the settings for the new state */
+       /* Apply all the settings for the new state - pinmux first */
        list_for_each_entry(setting, &state->settings, node) {
                switch (setting->type) {
                case PIN_MAP_TYPE_MUX_GROUP:
                        ret = pinmux_enable_setting(setting);
                        break;
                case PIN_MAP_TYPE_CONFIGS_PIN:
+               case PIN_MAP_TYPE_CONFIGS_GROUP:
+                       break;
+               default:
+                       ret = -EINVAL;
+                       break;
+               }
+
+               if (ret < 0) {
+                       goto unapply_new_state;
+               }
+
+               /* Do not link hogs (circular dependency) */
+               if (p != setting->pctldev->p)
+                       pinctrl_link_add(setting->pctldev, p->dev);
+       }
+
+       /* Apply all the settings for the new state - pinconf after */
+       list_for_each_entry(setting, &state->settings, node) {
+               switch (setting->type) {
+               case PIN_MAP_TYPE_MUX_GROUP:
+                       break;
+               case PIN_MAP_TYPE_CONFIGS_PIN:
                case PIN_MAP_TYPE_CONFIGS_GROUP:
                        ret = pinconf_apply_setting(setting);
                        break;



  reply	other threads:[~2021-03-01  9:32 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-02-16 15:35 DT overlay applied via pinctrl description Michal Simek
2021-02-17  5:33 ` Frank Rowand
2021-03-01  9:19 ` Linus Walleij
2021-03-01  9:31   ` Michal Simek [this message]
2021-03-01 14:13     ` Linus Walleij
2021-03-01 15:04       ` Michal Simek

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=45cea3bb-6e5d-4005-ef2a-67b08772e0d7@xilinx.com \
    --to=michal.simek@xilinx.com \
    --cc=lakshmi.sai.krishna.potthuri@xilinx.com \
    --cc=linus.walleij@linaro.org \
    --cc=linux-gpio@vger.kernel.org \
    --cc=linux-kernel@vger.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).