Re: [PATCH v3 1/1] pinctrl: add Intel BayTrail GPIO/pinctrl support
From: Timur Tabi
Date: Wed Apr 23 2014 - 18:54:20 EST
Linus Walleij wrote:
> All of our GPIOs have a
>pinmux on them, and so if you want to use the pin for the non-default
>functionality, you need to configure the mux. Isn't that supposed to happen
>with the through the pinctrl driver? That is, when the kernel parses the
>ASL, and it seems a command to configure pin #3 to function #4, it calls the
>local pinctrl driver to do that?
Let's suspect this is true. That is how GPIO work after all is it not?
With device trees, function groups are defined by name in the driver,
and the device tree contains these same names as links between nodes.
This works well.
In ACPI, it appears that no such infrastructure exists.
I guess the other option would be that all systems must come with a
tailored set-up written in ASL, specific for each board configuration.
That makes sense (U-Boot does fixups of the device tree based on actual
board config, so it's conceivable that UEFI could do the same for ASL).
However, that would require either
1) UEFI programs the GPIO muxes directly, without specifying any mux
information in ASL and without using the Linux driver to program the muxes.
or
2) ASL contains code to program the muxes, and Linux parses that ASL and
calls the pinctrl driver to program the hardware.
I don't know which direction the Community wants to use. If we go with
option #1, then there is no need for the pinctrl driver to specify
function groups at all. This means we would not need a separate pinctrl
driver for each SOC, like we do today.
--
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the
Code Aurora Forum, hosted by The Linux Foundation.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/