| Message ID | 20120918071208.GL13568@linux-sh.org (mailing list archive) |
|---|---|
| State | Rejected |
| Headers | show |
Hi Paul, On Tuesday 18 September 2012 16:12:08 Paul Mundt wrote: > On Fri, Sep 14, 2012 at 10:11:00PM +0200, Laurent Pinchart wrote: > > Hi Paul, > > > > I ran into an issue with GPIO and pinmuxing in the TPU PWM driver. > > > > The driver needs to switch the PWM pin between GPIO and function at > > runtime. To do so, I use the PWM pin GPIO (GPIO_PORT202) and the > > associated function GPIO (GPIO_FN_TPU0TO2_PORT202). > > > > The driver configures the pin as a GPIO output when loaded with > > > > gpio_request_one(GPIO_PORT202, GPIOF_INIT_LOW); > > > > This results in a call to sh_pfc_gpio_request_enable() followed by a call > > to sh_pfc_reconfig_pin() for GPIO 202. The later changes the pinmux type > > from PINMUX_TYPE_GPIO (2) to PINMUX_TYPE_OUTPUT (3). > > > > I then call gpio_free(GPIO_PORT202) and > > gpio_request(GPIO_FN_TPU0TO2_PORT202) to switch from GPIO to function. > > The former calls sh_pfc_gpio_disable_free:() on GPIO 202. > > > > When I later call gpio_free(GPIO_FN_TPU0TO2_PORT202) and > > gpio_request_one(GPIO_PORT202, GPIOF_INIT_LOW), the call to > > sh_pfc_gpio_request_enable() fails with > > > > pinctrl-sh_pfc pinctrl: Unsupported mux type (3), bailing... > > pinctrl-sh_pfc pinctrl-sh_pfc: request() failed for pin 202 > > pinctrl-sh_pfc pinctrl-sh_pfc: pin-202 (pinctrl-sh_pfc) status -524 > > > > You're more familiar with pinmux than I am. Am I doing something wrong, or > > is there a bug in the PFC pinmux implementation ? > > That's a bug, the pin has been reconfigured to a different mux type which > we should handle. At first glance, simply handling the input/output types > ought to work ok, but we may need more work than that. How does it go > with this? That seems to work, thank you. Will you push a patch ? > --- > > diff --git a/drivers/sh/pfc/pinctrl.c b/drivers/sh/pfc/pinctrl.c > index 2804eaa..c0857d5 100644 > --- a/drivers/sh/pfc/pinctrl.c > +++ b/drivers/sh/pfc/pinctrl.c > @@ -208,6 +208,8 @@ static int sh_pfc_gpio_request_enable(struct pinctrl_dev > *pctldev, > > break; > case PINMUX_TYPE_GPIO: > + case PINMUX_TYPE_INPUT: > + case PINMUX_TYPE_OUTPUT: > break; > default: > pr_err("Unsupported mux type (%d), bailing...\n", pinmux_type);
On Wed, Sep 19, 2012 at 05:19:44PM +0200, Laurent Pinchart wrote: > On Tuesday 18 September 2012 16:12:08 Paul Mundt wrote: > > That's a bug, the pin has been reconfigured to a different mux type which > > we should handle. At first glance, simply handling the input/output types > > ought to work ok, but we may need more work than that. How does it go > > with this? > > That seems to work, thank you. Will you push a patch ? > Yes, I'll send it off with the next batch of fixes. Thanks for testing! -- To unsubscribe from this list: send the line "unsubscribe linux-sh" 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/sh/pfc/pinctrl.c b/drivers/sh/pfc/pinctrl.c index 2804eaa..c0857d5 100644 --- a/drivers/sh/pfc/pinctrl.c +++ b/drivers/sh/pfc/pinctrl.c @@ -208,6 +208,8 @@ static int sh_pfc_gpio_request_enable(struct pinctrl_dev *pctldev, break; case PINMUX_TYPE_GPIO: + case PINMUX_TYPE_INPUT: + case PINMUX_TYPE_OUTPUT: break; default: pr_err("Unsupported mux type (%d), bailing...\n", pinmux_type);