linux-kernel - RE: [RFC PATCH v3 2/5] pinctrl: add dt binding support for pinmux mappings

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <74CDBE0F657A3D45AFBB94109FB122FF17761F1897@HQMAIL01.nvidia.com>
Date:	Thu, 5 Jan 2012 15:45:56 -0800
From:	Stephen Warren <swarren@...dia.com>
To:	Shawn Guo <shawn.guo@...escale.com>,
	Dong Aisheng-B29396 <B29396@...escale.com>
CC:	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"linus.walleij@...ricsson.com" <linus.walleij@...ricsson.com>,
	"s.hauer@...gutronix.de" <s.hauer@...gutronix.de>,
	"rob.herring@...xeda.com" <rob.herring@...xeda.com>,
	"kernel@...gutronix.de" <kernel@...gutronix.de>,
	"cjb@...top.org" <cjb@...top.org>,
	"devicetree-discuss@...ts.ozlabs.org" 
	<devicetree-discuss@...ts.ozlabs.org>,
	"linux-arm-kernel@...ts.infradead.org" 
	<linux-arm-kernel@...ts.infradead.org>
Subject: RE: [RFC PATCH v3 2/5] pinctrl: add dt binding support for pinmux
 mappings

Shawn Guo wrote at Wednesday, December 28, 2011 7:47 PM:
> On Tue, Dec 27, 2011 at 02:41:25PM +0000, Dong Aisheng-B29396 wrote:
...
> > I was ever thought putting a phandle of pinmux function in each device,
> > Then pinmux mapping table seems not need anymore. Like:
> >
> > usdhc4: usdhc@...9c000 { /* uSDHC4 */
> >         compatible = "fsl,imx6q-usdhc";
> > 	....
> >         pinmux = <&pinmux-sd4>;
> > };
> >
> > iomuxc@...e0000 {
> >         pinmux-sd4 : sd4 {
> >                 func-name = "sd4";
> >                 grp-name = "sd4grp";
> >                 grp-pins = <170 171 180 181 182 183 184 185 186 187>;
> >                 num-pins = <10>;
> >                 grp-mux = <0 0 1 1 1 1 1 1 1 1>;
> >                 num-mux = <10>;
> >         };
> >
> > It is a pure hw point of view to define node.
> 
> That's the way we should go for.  This is exactly the same thing that
> clk and regulator DT support is doing.  And right, in that way, we do
> not need pinmux mapping for DT at all.

Well, we'd probably want to have at least a semi-standardized notion of
how the per-device "pinmux" property worked, much like interrupts and
GPIOs work in the same way everywhere, albeit perhaps with different
property names (for GPIOs) and controller-specific flags arguments etc.

One other thing to note: The per-device data can't be a single phandle
reference, unless the referenced node is some kind of table, and then
we do need a pinmux mapping for DT to define the format of that table.
Reasons being:

* Devices most likely need to configure more than one pin or group of
pins, and may need to configure them to different functions, so we at
least need an array of (pin_group, selected_function) values somewhere.

* We need to represent both mux function selection and arbitrary other
per-pin/group configuration parameters.

* We need to represent pinmux configuration for multiple device/driver
states; suspend, active, idle, ...?

...
> To make the pinmux api generic for both dt and non-dt users, the pinmux
> client driver should still see/call pinmux_get, something like
> of_pinmux_get should be sorted out behind pinmux_get.
> 
> > But what about the pin maps without device associated?
>
> Do we have such cases?

I think so.

At least early on, not all drivers will be pinmux-aware, and we'll still
need to set up the pinmux for them. A system wide "pinmux initial
configuration table" or similar would be needed to do this, I think.
This may be transitional.

I can easily see cases where we don't have an explicit driver for HW,
but still need to set up random pinmux configuration as part of basic
system initialization. Perhaps ideally we'd always tie pinmux usage to
some specific device, but the flexibility of not having to do so seems
useful.

-- 
nvpublic

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/