pinctrl: cherryview: Configure HiZ pins to be input when requested as GPIOs
diff mbox

Message ID 1422528288-84076-1-git-send-email-mika.westerberg@linux.intel.com
State New
Headers show

Commit Message

Mika Westerberg Jan. 29, 2015, 10:44 a.m. UTC
If the pin is in HiZ mode when it is requested as GPIO its value cannot be
read (it always returns 0). In order to cope with the Linux GPIO subsystem
where we do not have such state at all, turn the pin to be input instead.

Reported-by: Jerome Blin <jerome.blin@intel.com>
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
---
 drivers/pinctrl/intel/pinctrl-cherryview.c | 17 +++++++++++++++--
 1 file changed, 15 insertions(+), 2 deletions(-)

Comments

Linus Walleij Feb. 4, 2015, 9:01 a.m. UTC | #1
On Thu, Jan 29, 2015 at 11:44 AM, Mika Westerberg
<mika.westerberg@linux.intel.com> wrote:

> If the pin is in HiZ mode when it is requested as GPIO its value cannot be
> read (it always returns 0). In order to cope with the Linux GPIO subsystem
> where we do not have such state at all, turn the pin to be input instead.
>
> Reported-by: Jerome Blin <jerome.blin@intel.com>
> Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>

Patch applied.

Since putting a pin into GPIO mode start poking around in essentially pin
control registers, we may need to revisit the issue of the pin control subsystem
not denying simultaneous use of a pin for a device muxing and GPIO.
Maybe the "strict" setting forcing a pin to be either one or the other on
a per-driver basis would enforce a better policy on this driver (and some
others).

Yours,
Linus Walleij
--
To unsubscribe from this list: send the line "unsubscribe linux-gpio" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Mika Westerberg Feb. 4, 2015, 3:37 p.m. UTC | #2
On Wed, Feb 04, 2015 at 10:01:49AM +0100, Linus Walleij wrote:
> On Thu, Jan 29, 2015 at 11:44 AM, Mika Westerberg
> <mika.westerberg@linux.intel.com> wrote:
> 
> > If the pin is in HiZ mode when it is requested as GPIO its value cannot be
> > read (it always returns 0). In order to cope with the Linux GPIO subsystem
> > where we do not have such state at all, turn the pin to be input instead.
> >
> > Reported-by: Jerome Blin <jerome.blin@intel.com>
> > Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
> 
> Patch applied.

Thanks.

> Since putting a pin into GPIO mode start poking around in essentially pin
> control registers, we may need to revisit the issue of the pin control subsystem
> not denying simultaneous use of a pin for a device muxing and GPIO.
> Maybe the "strict" setting forcing a pin to be either one or the other on
> a per-driver basis would enforce a better policy on this driver (and some
> others).

Yes, something like that sounds reasonable.
--
To unsubscribe from this list: send the line "unsubscribe linux-gpio" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Patch
diff mbox

diff --git a/drivers/pinctrl/intel/pinctrl-cherryview.c b/drivers/pinctrl/intel/pinctrl-cherryview.c
index dde67d425e9c..abe18960933d 100644
--- a/drivers/pinctrl/intel/pinctrl-cherryview.c
+++ b/drivers/pinctrl/intel/pinctrl-cherryview.c
@@ -880,9 +880,22 @@  static int chv_gpio_request_enable(struct pinctrl_dev *pctldev,
 		value &= ~CHV_PADCTRL1_INVRXTX_MASK;
 		chv_writel(value, reg);
 
-		/* Switch to a GPIO mode */
 		reg = chv_padreg(pctrl, offset, CHV_PADCTRL0);
-		value = readl(reg) | CHV_PADCTRL0_GPIOEN;
+		value = readl(reg);
+
+		/*
+		 * If the pin is in HiZ mode (both TX and RX buffers are
+		 * disabled) we turn it to be input now.
+		 */
+		if ((value & CHV_PADCTRL0_GPIOCFG_MASK) ==
+		     (CHV_PADCTRL0_GPIOCFG_HIZ << CHV_PADCTRL0_GPIOCFG_SHIFT)) {
+			value &= ~CHV_PADCTRL0_GPIOCFG_MASK;
+			value |= CHV_PADCTRL0_GPIOCFG_GPI <<
+				CHV_PADCTRL0_GPIOCFG_SHIFT;
+		}
+
+		/* Switch to a GPIO mode */
+		value |= CHV_PADCTRL0_GPIOEN;
 		chv_writel(value, reg);
 	}