| Message ID | 1422528288-84076-1-git-send-email-mika.westerberg@linux.intel.com |
|---|---|
| State | New |
| Headers | show |
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
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
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); }
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(-)