[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20200930091526.GQ9471@atomide.com>
Date: Wed, 30 Sep 2020 12:15:26 +0300
From: Tony Lindgren <tony@...mide.com>
To: Trent Piepho <tpiepho@...il.com>
Cc: Drew Fustini <drew@...gleboard.org>,
Rob Herring <robh+dt@...nel.org>,
Linus Walleij <linus.walleij@...aro.org>,
Jason Kridner <jkridner@...gleboard.org>,
Robert Nelson <robertcnelson@...il.com>,
linux-omap@...r.kernel.org, linux-kernel@...r.kernel.org,
devicetree@...r.kernel.org,
linux-gpio <linux-gpio@...r.kernel.org>,
Christina Quast <cquast@...overdisplays.com>
Subject: Re: [PATCH] ARM: dts: document pinctrl-single,pins when
#pinctrl-cells = 2
* Trent Piepho <tpiepho@...il.com> [200930 08:35]:
> The closest thing would be the generic pin config type bindings, which
> go in the pinctrl driver's nodes, and look like this:
> &am335x_pinmux {
> pinctrl_yoyo_reset: yoyogrp {
> pins = "foo";
> function = "gpio";
> bias-pull-up;
> };
> };
There's a bit of a dtb size and boot time issue for adding properties
for each pin where that needs to be done for several hundred pins :)
> Is "some additional property for specifying generic conf flags"
> different from the existing pinctrl-single,bias-pullup, etc.
> properties? Because splitting the data cell into two parts doesn't
> make any difference to those.
So with an interrupt style binding with generic pinconf flags we can
leave out the parsing of multiple properties for each pin. Sure the
pin is only referenced by the controller like you pointed out but the
pinconf flags could be generic.
Regards,
Tony
Powered by blists - more mailing lists