Re: [PATCH v3 1/1] pinctrl: add Intel BayTrail GPIO/pinctrl support

[Timur Tabi <timur@codeaurora.org>]

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.