[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <929190e9-1195-4381-ae18-b71d17444569@gmail.com>
Date: Tue, 16 Feb 2021 23:33:23 -0600
From: Frank Rowand <frowand.list@...il.com>
To: Michal Simek <michal.simek@...inx.com>,
Linus Walleij <linus.walleij@...aro.org>
Cc: Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
"open list:GPIO SUBSYSTEM" <linux-gpio@...r.kernel.org>,
Sai Krishna Potthuri <lakshmi.sai.krishna.potthuri@...inx.com>,
Frank Rowand <frowand.list@...il.com>,
Rob Herring <robh+dt@...nel.org>,
"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>
Subject: Re: DT overlay applied via pinctrl description
+Frank, Rob, devicetree list
On 2/16/21 9:35 AM, Michal Simek wrote:
> Hi,
>
> 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.
>
> That's why I want to check with you if this is issue with DT binding
> description we use in zynqmp pinctrl driver posted here
> https://lore.kernel.org/linux-arm-kernel/1613131643-60062-1-git-send-email-lakshmi.sai.krishna.potthuri@xilinx.com/
>
> I have also tried to use init and default configuration where init is
> called just with mux setting and then default is called just with config
> but the issue is there as well because in pinctrl_commit_state()
> previous state is checked and for MUXes pinmux_disable_setting() is
> called which release a pin. And then configuration in default is called
> but without requesting pin which fails for the same reason as above.
>
> That's why my questions are:
> Are we using incorrect DT description?
> And is there a need sort subnodes in a way that mux should be called
> first by core before configuration?
> Or is there any different way how to do it?
Node ordering and property ordering within a node are not defined
in the Linux kernel. If a subsystem or property is depending upon
a certain order, they must implement a method other than the
order as accessed by of_* functions. And as you noted, use of an
overlay may also change ordering.
-Frank
>
> Thanks,
> Michal
>
Powered by blists - more mailing lists