[RFC/PATCH] gpio/pinctrl: baytrail: move gpio driver from pinctrl to gpio directory

[RFC/PATCH] gpio/pinctrl: baytrail: move gpio driver from pinctrl to gpio directory

[David Cohen]

Even though GPIO module on Intel Bay Trail is able to control pin
functionality, it's unlikely Linux kernel driver will ever support it
since BIOS should handle all pin muxing itself.

Currently this driver does not register any pinctrl interface and
doesn't call any pinctrl interface. It just uses on internal functions
the 'struct pinctrl_gpio_range', which is a weak justification to not be
under gpio directory.

Cc: Mathias Nyman <mathias.nyman@linux.intel.com>
Signed-off-by: David Cohen <david.a.cohen@linux.intel.com>
---
 drivers/gpio/Kconfig                                         | 12 ++++++++++++
 drivers/gpio/Makefile                                        |  1 +
 drivers/{pinctrl/pinctrl-baytrail.c => gpio/gpio-baytrail.c} |  0
 drivers/pinctrl/Kconfig                                      | 12 ------------
 drivers/pinctrl/Makefile                                     |  1 -
 5 files changed, 13 insertions(+), 13 deletions(-)
 rename drivers/{pinctrl/pinctrl-baytrail.c => gpio/gpio-baytrail.c} (100%)

diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig
index 0959ca9b6b27..c0e2f5647d6a 100644
--- a/drivers/gpio/Kconfig
+++ b/drivers/gpio/Kconfig
@@ -738,6 +738,18 @@ config GPIO_AMD8111
 
 	  If unsure, say N
 
+config GPIO_BAYTRAIL
+	bool "Intel Baytrail GPIO pin control"
+	depends on ACPI && X86
+	select GPIOLIB_IRQCHIP
+	help
+	  driver for memory mapped GPIO functionality on Intel Baytrail
+	  platforms. Supports 3 banks with 102, 28 and 44 gpios.
+	  Most pins are usually muxed to some other functionality by firmware,
+	  so only a small amount is available for gpio use.
+
+	  Requires ACPI device enumeration code to set up a platform device.
+
 config GPIO_INTEL_MID
 	bool "Intel Mid GPIO support"
 	depends on PCI && X86
diff --git a/drivers/gpio/Makefile b/drivers/gpio/Makefile
index e5d346cf3b6e..21fc2a4baa6f 100644
--- a/drivers/gpio/Makefile
+++ b/drivers/gpio/Makefile
@@ -18,6 +18,7 @@ obj-$(CONFIG_GPIO_ADP5520)	+= gpio-adp5520.o
 obj-$(CONFIG_GPIO_ADP5588)	+= gpio-adp5588.o
 obj-$(CONFIG_GPIO_AMD8111)	+= gpio-amd8111.o
 obj-$(CONFIG_GPIO_ARIZONA)	+= gpio-arizona.o
+obj-$(CONFIG_GPIO_BAYTRAIL)	+= gpio-baytrail.o
 obj-$(CONFIG_GPIO_BCM_KONA)	+= gpio-bcm-kona.o
 obj-$(CONFIG_GPIO_BT8XX)	+= gpio-bt8xx.o
 obj-$(CONFIG_GPIO_CLPS711X)	+= gpio-clps711x.o
diff --git a/drivers/pinctrl/pinctrl-baytrail.c b/drivers/gpio/gpio-baytrail.c
similarity index 100%
rename from drivers/pinctrl/pinctrl-baytrail.c
rename to drivers/gpio/gpio-baytrail.c
diff --git a/drivers/pinctrl/Kconfig b/drivers/pinctrl/Kconfig
index c6a66de6ed72..de65d26f5538 100644
--- a/drivers/pinctrl/Kconfig
+++ b/drivers/pinctrl/Kconfig
@@ -67,18 +67,6 @@ config PINCTRL_AT91
 	help
 	  Say Y here to enable the at91 pinctrl driver
 
-config PINCTRL_BAYTRAIL
-	bool "Intel Baytrail GPIO pin control"
-	depends on GPIOLIB && ACPI && X86
-	select GPIOLIB_IRQCHIP
-	help
-	  driver for memory mapped GPIO functionality on Intel Baytrail
-	  platforms. Supports 3 banks with 102, 28 and 44 gpios.
-	  Most pins are usually muxed to some other functionality by firmware,
-	  so only a small amount is available for gpio use.
-
-	  Requires ACPI device enumeration code to set up a platform device.
-
 config PINCTRL_BCM2835
 	bool
 	select PINMUX
diff --git a/drivers/pinctrl/Makefile b/drivers/pinctrl/Makefile
index 51f52d32859e..0936d42f0b51 100644
--- a/drivers/pinctrl/Makefile
+++ b/drivers/pinctrl/Makefile
@@ -15,7 +15,6 @@ obj-$(CONFIG_PINCTRL_BF54x)	+= pinctrl-adi2-bf54x.o
 obj-$(CONFIG_PINCTRL_BF60x)	+= pinctrl-adi2-bf60x.o
 obj-$(CONFIG_PINCTRL_AT91)	+= pinctrl-at91.o
 obj-$(CONFIG_PINCTRL_BCM2835)	+= pinctrl-bcm2835.o
-obj-$(CONFIG_PINCTRL_BAYTRAIL)	+= pinctrl-baytrail.o
 obj-$(CONFIG_PINCTRL_BCM281XX)	+= pinctrl-bcm281xx.o
 obj-$(CONFIG_PINCTRL_FALCON)	+= pinctrl-falcon.o
 obj-$(CONFIG_PINCTRL_PALMAS)	+= pinctrl-palmas.o
-- 
2.1.0

Re: [RFC/PATCH] gpio/pinctrl: baytrail: move gpio driver from pinctrl to gpio directory

[Mathias Nyman]

On 13.10.2014 22:17, David Cohen wrote:
> Even though GPIO module on Intel Bay Trail is able to control pin
> functionality, it's unlikely Linux kernel driver will ever support it
> since BIOS should handle all pin muxing itself.
> 
> Currently this driver does not register any pinctrl interface and
> doesn't call any pinctrl interface. It just uses on internal functions
> the 'struct pinctrl_gpio_range', which is a weak justification to not be
> under gpio directory.
> 

This discussion was held when gpio-baytrail was first submitted.
These threads explain the gpio/pinctrl-baytrail history:

http://marc.info/?l=linux-kernel&m=136981432427668&w=2
http://marc.info/?l=linux-kernel&m=137113578604763&w=2
http://marc.info/?l=linux-kernel&m=137155497023054&w=2

A proper pinctrl driver for baytrail is still not yet ruled out

-Mathias 

Re: [RFC/PATCH] gpio/pinctrl: baytrail: move gpio driver from pinctrl to gpio directory

[David Cohen]

Hi Mathias,

On Tue, Oct 14, 2014 at 01:35:43PM +0300, Mathias Nyman wrote:
> On 13.10.2014 22:17, David Cohen wrote:
> > Even though GPIO module on Intel Bay Trail is able to control pin
> > functionality, it's unlikely Linux kernel driver will ever support it
> > since BIOS should handle all pin muxing itself.
> > 
> > Currently this driver does not register any pinctrl interface and
> > doesn't call any pinctrl interface. It just uses on internal functions
> > the 'struct pinctrl_gpio_range', which is a weak justification to not be
> > under gpio directory.
> > 
> 
> This discussion was held when gpio-baytrail was first submitted.
> These threads explain the gpio/pinctrl-baytrail history:
> 
> http://marc.info/?l=linux-kernel&m=136981432427668&w=2
> http://marc.info/?l=linux-kernel&m=137113578604763&w=2
> http://marc.info/?l=linux-kernel&m=137155497023054&w=2

Thanks for pointing that out.

> 
> A proper pinctrl driver for baytrail is still not yet ruled out

Having it inside pinctrl directory is creating some confusion because
ppl expect it to implement the actual pinctrl interface.

Anyway, the threads above are over 1 year old. Perhaps it was making
sense during that time, but unless somebody is working on pinctrl
interface now, IMHO we're misplacing the driver for too long. It'd
better to move this driver to gpio directory and when/if pinctrl
interface is implemented, we move it back to current place.

Br, David

> 
> -Mathias 
> 

Re: [RFC/PATCH] gpio/pinctrl: baytrail: move gpio driver from pinctrl to gpio directory

[Mika Westerberg]

On Tue, Oct 14, 2014 at 10:45:35AM -0700, David Cohen wrote:
> Hi Mathias,
> 
> On Tue, Oct 14, 2014 at 01:35:43PM +0300, Mathias Nyman wrote:
> > On 13.10.2014 22:17, David Cohen wrote:
> > > Even though GPIO module on Intel Bay Trail is able to control pin
> > > functionality, it's unlikely Linux kernel driver will ever support it
> > > since BIOS should handle all pin muxing itself.
> > > 
> > > Currently this driver does not register any pinctrl interface and
> > > doesn't call any pinctrl interface. It just uses on internal functions
> > > the 'struct pinctrl_gpio_range', which is a weak justification to not be
> > > under gpio directory.
> > > 
> > 
> > This discussion was held when gpio-baytrail was first submitted.
> > These threads explain the gpio/pinctrl-baytrail history:
> > 
> > http://marc.info/?l=linux-kernel&m=136981432427668&w=2
> > http://marc.info/?l=linux-kernel&m=137113578604763&w=2
> > http://marc.info/?l=linux-kernel&m=137155497023054&w=2
> 
> Thanks for pointing that out.
> 
> > 
> > A proper pinctrl driver for baytrail is still not yet ruled out
> 
> Having it inside pinctrl directory is creating some confusion because
> ppl expect it to implement the actual pinctrl interface.

A typical pinctrl driver can implement both a pinctrl interface and a
GPIO interface. So it is not uncommon to look the GPIO drivers under
drivers/pinctrl/*.

Furthermore the driver announces that it is a GPIO driver in its Kconfig
entry:

config PINCTRL_BAYTRAIL
        bool "Intel Baytrail GPIO pin control"

so I don't quite get why this would confuse people.

We are also planning to add more Intel pinctrl (real) drivers in the
future. drivers/pinctrl/intel/* should be the place where people find
the pinctrl/GPIO drivers for newer Intel hardware.

> Anyway, the threads above are over 1 year old. Perhaps it was making
> sense during that time, but unless somebody is working on pinctrl
> interface now, IMHO we're misplacing the driver for too long. It'd
> better to move this driver to gpio directory and when/if pinctrl
> interface is implemented, we move it back to current place.

I disagree.

What happens when people and distros have CONFIG_PINCTRL_BAYTRAIL=y and
now the symbol is changed to something else? For one, it will break the
existing working configs.

Re: [RFC/PATCH] gpio/pinctrl: baytrail: move gpio driver from pinctrl to gpio directory

[David Cohen]

Hi Mika,

Thanks for your feedback. See below my reply.

On Wed, Oct 15, 2014 at 10:08:12AM +0300, Mika Westerberg wrote:
> On Tue, Oct 14, 2014 at 10:45:35AM -0700, David Cohen wrote:
> > Hi Mathias,
> > 
> > On Tue, Oct 14, 2014 at 01:35:43PM +0300, Mathias Nyman wrote:
> > > On 13.10.2014 22:17, David Cohen wrote:
> > > > Even though GPIO module on Intel Bay Trail is able to control pin
> > > > functionality, it's unlikely Linux kernel driver will ever support it
> > > > since BIOS should handle all pin muxing itself.
> > > > 
> > > > Currently this driver does not register any pinctrl interface and
> > > > doesn't call any pinctrl interface. It just uses on internal functions
> > > > the 'struct pinctrl_gpio_range', which is a weak justification to not be
> > > > under gpio directory.
> > > > 
> > > 
> > > This discussion was held when gpio-baytrail was first submitted.
> > > These threads explain the gpio/pinctrl-baytrail history:
> > > 
> > > http://marc.info/?l=linux-kernel&m=136981432427668&w=2
> > > http://marc.info/?l=linux-kernel&m=137113578604763&w=2
> > > http://marc.info/?l=linux-kernel&m=137155497023054&w=2
> > 
> > Thanks for pointing that out.
> > 
> > > 
> > > A proper pinctrl driver for baytrail is still not yet ruled out
> > 
> > Having it inside pinctrl directory is creating some confusion because
> > ppl expect it to implement the actual pinctrl interface.
> 
> A typical pinctrl driver can implement both a pinctrl interface and a
> GPIO interface. So it is not uncommon to look the GPIO drivers under
> drivers/pinctrl/*.

Agreed :)
But pinctrl-baytrail has no pinctrl interface, just gpio.

> 
> Furthermore the driver announces that it is a GPIO driver in its Kconfig
> entry:
> 
> config PINCTRL_BAYTRAIL
>         bool "Intel Baytrail GPIO pin control"
> 
> so I don't quite get why this would confuse people.

How come? You just wrote the inconsistence :)
We're enabling PINCTRL_BAYTRAIL to build a gpio only driver.

> 
> We are also planning to add more Intel pinctrl (real) drivers in the
> future. drivers/pinctrl/intel/* should be the place where people find
> the pinctrl/GPIO drivers for newer Intel hardware.

I fully agree pinctrl/gpio drivers should stay under drivers/pinctrl.
But we're talking about a gpio driver. IMHO we should at least mention
in the driver it lacks pinctrl interface currently but it will come in
future.

A side discussion would be why a distro would want to have the pinctrl
interface on Bay Trail. I'd assume any driver being the consumer of it
is likely to be wrong. When Linux boots, all pins' functions should be
already set.

> 
> > Anyway, the threads above are over 1 year old. Perhaps it was making
> > sense during that time, but unless somebody is working on pinctrl
> > interface now, IMHO we're misplacing the driver for too long. It'd
> > better to move this driver to gpio directory and when/if pinctrl
> > interface is implemented, we move it back to current place.
> 
> I disagree.
> 
> What happens when people and distros have CONFIG_PINCTRL_BAYTRAIL=y and
> now the symbol is changed to something else? For one, it will break the
> existing working configs.

Well, it would happen the same situation when CONFIG_PINCTRL_BAYTRAIL
was implemented for the first time. I don't think we should move/rename
is pinctrl interface is being implemented in short or middle term. But
my point is whether it will be implemented at all for the reasons I
mentioned above.

Anyway, I sent this patch as RFC due to I was expecting it to not be a
consensus. But guess the majority prefer to let it stay where it is.

Br, David

Re: [RFC/PATCH] gpio/pinctrl: baytrail: move gpio driver from pinctrl to gpio directory

[Mika Westerberg]

On Wed, Oct 15, 2014 at 09:55:42AM -0700, David Cohen wrote:
> Hi Mika,
> 
> Thanks for your feedback. See below my reply.
> 
> On Wed, Oct 15, 2014 at 10:08:12AM +0300, Mika Westerberg wrote:
> > On Tue, Oct 14, 2014 at 10:45:35AM -0700, David Cohen wrote:
> > > Hi Mathias,
> > > 
> > > On Tue, Oct 14, 2014 at 01:35:43PM +0300, Mathias Nyman wrote:
> > > > On 13.10.2014 22:17, David Cohen wrote:
> > > > > Even though GPIO module on Intel Bay Trail is able to control pin
> > > > > functionality, it's unlikely Linux kernel driver will ever support it
> > > > > since BIOS should handle all pin muxing itself.
> > > > > 
> > > > > Currently this driver does not register any pinctrl interface and
> > > > > doesn't call any pinctrl interface. It just uses on internal functions
> > > > > the 'struct pinctrl_gpio_range', which is a weak justification to not be
> > > > > under gpio directory.
> > > > > 
> > > > 
> > > > This discussion was held when gpio-baytrail was first submitted.
> > > > These threads explain the gpio/pinctrl-baytrail history:
> > > > 
> > > > http://marc.info/?l=linux-kernel&m=136981432427668&w=2
> > > > http://marc.info/?l=linux-kernel&m=137113578604763&w=2
> > > > http://marc.info/?l=linux-kernel&m=137155497023054&w=2
> > > 
> > > Thanks for pointing that out.
> > > 
> > > > 
> > > > A proper pinctrl driver for baytrail is still not yet ruled out
> > > 
> > > Having it inside pinctrl directory is creating some confusion because
> > > ppl expect it to implement the actual pinctrl interface.
> > 
> > A typical pinctrl driver can implement both a pinctrl interface and a
> > GPIO interface. So it is not uncommon to look the GPIO drivers under
> > drivers/pinctrl/*.
> 
> Agreed :)
> But pinctrl-baytrail has no pinctrl interface, just gpio.

The hardware is capable of muxing pins etc. it just has not been
implemented because we currently don't have need for anything else.
I have seen that in some of our internal trees the driver is also muxing
alternate functions to the pins (using non-pinctrl interface). So maybe
it will get a full pinctrl support in the future.

We certainly don't want to move it from pinctrl to gpio and then back.

> > Furthermore the driver announces that it is a GPIO driver in its Kconfig
> > entry:
> > 
> > config PINCTRL_BAYTRAIL
> >         bool "Intel Baytrail GPIO pin control"
> > 
> > so I don't quite get why this would confuse people.
> 
> How come? You just wrote the inconsistence :)

Well, it says it is a "GPIO pin control" :-)

> We're enabling PINCTRL_BAYTRAIL to build a gpio only driver.
> 
> > 
> > We are also planning to add more Intel pinctrl (real) drivers in the
> > future. drivers/pinctrl/intel/* should be the place where people find
> > the pinctrl/GPIO drivers for newer Intel hardware.
> 
> I fully agree pinctrl/gpio drivers should stay under drivers/pinctrl.
> But we're talking about a gpio driver. IMHO we should at least mention
> in the driver it lacks pinctrl interface currently but it will come in
> future.

OK, why not.

> A side discussion would be why a distro would want to have the pinctrl
> interface on Bay Trail. I'd assume any driver being the consumer of it
> is likely to be wrong. When Linux boots, all pins' functions should be
> already set.

In an ideal world, yes. However, the reality has shown that BIOS/FW gets
these wrong and we need to work it around in the OS.

Also for devices like MinnowBoard MAX (which has Baytrail SoC), you
actually might want to mux some other function out of certain pins.

Re: [RFC/PATCH] gpio/pinctrl: baytrail: move gpio driver from pinctrl to gpio directory

[David Cohen]

On Thu, Oct 16, 2014 at 11:01:23AM +0300, Mika Westerberg wrote:
> On Wed, Oct 15, 2014 at 09:55:42AM -0700, David Cohen wrote:
> > Hi Mika,
> > 
> > Thanks for your feedback. See below my reply.
> > 
> > On Wed, Oct 15, 2014 at 10:08:12AM +0300, Mika Westerberg wrote:
> > > On Tue, Oct 14, 2014 at 10:45:35AM -0700, David Cohen wrote:
> > > > Hi Mathias,
> > > > 
> > > > On Tue, Oct 14, 2014 at 01:35:43PM +0300, Mathias Nyman wrote:
> > > > > On 13.10.2014 22:17, David Cohen wrote:
> > > > > > Even though GPIO module on Intel Bay Trail is able to control pin
> > > > > > functionality, it's unlikely Linux kernel driver will ever support it
> > > > > > since BIOS should handle all pin muxing itself.
> > > > > > 
> > > > > > Currently this driver does not register any pinctrl interface and
> > > > > > doesn't call any pinctrl interface. It just uses on internal functions
> > > > > > the 'struct pinctrl_gpio_range', which is a weak justification to not be
> > > > > > under gpio directory.
> > > > > > 
> > > > > 
> > > > > This discussion was held when gpio-baytrail was first submitted.
> > > > > These threads explain the gpio/pinctrl-baytrail history:
> > > > > 
> > > > > http://marc.info/?l=linux-kernel&m=136981432427668&w=2
> > > > > http://marc.info/?l=linux-kernel&m=137113578604763&w=2
> > > > > http://marc.info/?l=linux-kernel&m=137155497023054&w=2
> > > > 
> > > > Thanks for pointing that out.
> > > > 
> > > > > 
> > > > > A proper pinctrl driver for baytrail is still not yet ruled out
> > > > 
> > > > Having it inside pinctrl directory is creating some confusion because
> > > > ppl expect it to implement the actual pinctrl interface.
> > > 
> > > A typical pinctrl driver can implement both a pinctrl interface and a
> > > GPIO interface. So it is not uncommon to look the GPIO drivers under
> > > drivers/pinctrl/*.
> > 
> > Agreed :)
> > But pinctrl-baytrail has no pinctrl interface, just gpio.
> 
> The hardware is capable of muxing pins etc. it just has not been
> implemented because we currently don't have need for anything else.
> I have seen that in some of our internal trees the driver is also muxing
> alternate functions to the pins (using non-pinctrl interface). So maybe
> it will get a full pinctrl support in the future.
> 
> We certainly don't want to move it from pinctrl to gpio and then back.
> 
> > > Furthermore the driver announces that it is a GPIO driver in its Kconfig
> > > entry:
> > > 
> > > config PINCTRL_BAYTRAIL
> > >         bool "Intel Baytrail GPIO pin control"
> > > 
> > > so I don't quite get why this would confuse people.
> > 
> > How come? You just wrote the inconsistence :)
> 
> Well, it says it is a "GPIO pin control" :-)

PINCTRL_BAYTRAIL means it implements pinctrl iterface. The text says
otherwise.

> 
> > We're enabling PINCTRL_BAYTRAIL to build a gpio only driver.
> > 
> > > 
> > > We are also planning to add more Intel pinctrl (real) drivers in the
> > > future. drivers/pinctrl/intel/* should be the place where people find
> > > the pinctrl/GPIO drivers for newer Intel hardware.
> > 
> > I fully agree pinctrl/gpio drivers should stay under drivers/pinctrl.
> > But we're talking about a gpio driver. IMHO we should at least mention
> > in the driver it lacks pinctrl interface currently but it will come in
> > future.
> 
> OK, why not.
> 
> > A side discussion would be why a distro would want to have the pinctrl
> > interface on Bay Trail. I'd assume any driver being the consumer of it
> > is likely to be wrong. When Linux boots, all pins' functions should be
> > already set.
> 
> In an ideal world, yes. However, the reality has shown that BIOS/FW gets
> these wrong and we need to work it around in the OS.

But we never upstream these workarounds, right? :)
That would be useful during internal development while we get a fix from
fw developers. Any driver upstreamed for Bay Trail actually using this
pinctrl interface is very likely to be wrong.

> 
> Also for devices like MinnowBoard MAX (which has Baytrail SoC), you
> actually might want to mux some other function out of certain pins.

I fully agree on this one. MinnowBoard MAX is a valid reason to expose
pinctrl interface. A TODO comment on Kconfig help text and/or on driver
should be enough then.

Br, David

Re: [RFC/PATCH] gpio/pinctrl: baytrail: move gpio driver from pinctrl to gpio directory

[Linus Walleij]

On Fri, Oct 17, 2014 at 3:53 AM, David Cohen
<david.a.cohen@linux.intel.com> wrote:
> On Thu, Oct 16, 2014 at 11:01:23AM +0300, Mika Westerberg wrote:

>> In an ideal world, yes. However, the reality has shown that BIOS/FW gets
>> these wrong and we need to work it around in the OS.
>
> But we never upstream these workarounds, right? :)

Unless you discover it after it hits the market, right?

I think this driver is just fine exactly where it is. Besides, the driver
is fully aware of all its pins, and just look at all the pull up etc
information displayed by byt_gpio_dbg_show(), it doesn't get more
pin control than that even if you don't implement the pin control
API.

Yours,
Linus Walleij

Re: [RFC/PATCH] gpio/pinctrl: baytrail: move gpio driver from pinctrl to gpio directory

[David Cohen]

On Tue, Oct 28, 2014 at 04:10:26PM +0100, Linus Walleij wrote:
> On Fri, Oct 17, 2014 at 3:53 AM, David Cohen
> <david.a.cohen@linux.intel.com> wrote:
> > On Thu, Oct 16, 2014 at 11:01:23AM +0300, Mika Westerberg wrote:
> 
> >> In an ideal world, yes. However, the reality has shown that BIOS/FW gets
> >> these wrong and we need to work it around in the OS.
> >
> > But we never upstream these workarounds, right? :)
> 
> Unless you discover it after it hits the market, right?

This is quite unlikely to happen. A pin mux misconfigured would have
quite bad side effects. But considering it happens, IMHO not even this
case would make an upstreamed baytrail pinctrl API consumer correct. The
FW should get updated instead. But...

> 
> I think this driver is just fine exactly where it is. Besides, the driver
> is fully aware of all its pins, and just look at all the pull up etc
> information displayed by byt_gpio_dbg_show(), it doesn't get more
> pin control than that even if you don't implement the pin control
> API.

... considering the development boards + the case you mentioned above,
my RFC got more buried than it already was :)

Br, David

> 
> Yours,
> Linus Walleij

Re: [RFC/PATCH] gpio/pinctrl: baytrail: move gpio driver from pinctrl to gpio directory

[Linus Walleij]

On Tue, Oct 28, 2014 at 5:42 PM, David Cohen
<david.a.cohen@linux.intel.com> wrote:
> On Tue, Oct 28, 2014 at 04:10:26PM +0100, Linus Walleij wrote:
>> On Fri, Oct 17, 2014 at 3:53 AM, David Cohen
>> <david.a.cohen@linux.intel.com> wrote:
>> > On Thu, Oct 16, 2014 at 11:01:23AM +0300, Mika Westerberg wrote:
>>
>> >> In an ideal world, yes. However, the reality has shown that BIOS/FW gets
>> >> these wrong and we need to work it around in the OS.
>> >
>> > But we never upstream these workarounds, right? :)
>>
>> Unless you discover it after it hits the market, right?
>
> This is quite unlikely to happen. A pin mux misconfigured would have
> quite bad side effects

This is not what typically happens. Mux is not the problem, the
problem is going to be pin config.

What happens is that someone designs a board with a pull-up
resistor mounted on it, and the device ships with the internal
on-soc software controlled pull-up enabled as well.

A few weeks later someone discovers that the device is
consuming too much power, and start hunting for power
regressions.

They realize that the on-soc pull up should not have been enabled
since the one in hardware (soldered on the board) is good enough,
and having them both active leads to leak current as the sum
resistance of two parallel pull-ups is Rtot = R1*R2/(R1+R2).

And they start putting in software quirks to turn off the internal
pull-up to meet power targets.

Yours,
Linus Walleij