Re: [PATCH v2 2/5] pinctrl: imx: add gpio pinmux support for vf610

[Stefan Agner]

Am 2014-09-25 11:07, schrieb Shawn Guo:
> On Thu, Sep 25, 2014 at 09:00:41AM +0200, Stefan Agner wrote:
>> Am 2014-09-25 04:47, schrieb Shawn Guo:
>> > On Tue, Sep 23, 2014 at 07:37:54PM +0200, Stefan Agner wrote:
>> >> Add pinmux support for GPIO for Vybrid (vf610) IOMUX controller.
>> >> This is needed since direction configuration is not part of the
>> >> GPIO module in Vybrid.
>> >>
>> >> Signed-off-by: Stefan Agner <stefan@xxxxxxxx>
>> >> ---
>> >>  drivers/pinctrl/pinctrl-imx.c   | 54 +++++++++++++++++++++++++++++++++++++++++
>> >>  drivers/pinctrl/pinctrl-imx.h   |  1 +
>> >>  drivers/pinctrl/pinctrl-vf610.c |  2 +-
>> >>  3 files changed, 56 insertions(+), 1 deletion(-)
>> >>
>> >> diff --git a/drivers/pinctrl/pinctrl-imx.c b/drivers/pinctrl/pinctrl-imx.c
>> >> index 0d4558b..64d1b59 100644
>> >> --- a/drivers/pinctrl/pinctrl-imx.c
>> >> +++ b/drivers/pinctrl/pinctrl-imx.c
>> >> @@ -294,10 +294,59 @@ static int imx_pmx_get_groups(struct pinctrl_dev *pctldev, unsigned selector,
>> >>  	return 0;
>> >>  }
>> >>
>> >> +static int imx_pmx_gpio_request_enable(struct pinctrl_dev *pctldev,
>> >> +			struct pinctrl_gpio_range *range, unsigned offset)
>> >> +{
>> >> +	struct imx_pinctrl *ipctl = pinctrl_dev_get_drvdata(pctldev);
>> >> +	const struct imx_pinctrl_soc_info *info = ipctl->info;
>> >> +	const struct imx_pin_reg *pin_reg;
>> >> +	u32 reg;
>> >> +
>> >> +	if (!(info->flags & GPIO_CONTROL))
>> >> +		return -EINVAL;
>> >> +
>> >> +	pin_reg = &info->pin_regs[offset];
>> >> +	if (pin_reg->mux_reg == -1)
>> >> +		return -EINVAL;
>> >> +
>> >> +	reg = readl(ipctl->base + pin_reg->mux_reg);
>> >> +	reg &= ~(0x7 << 20);
>> >> +	writel(reg, ipctl->base + pin_reg->mux_reg);
>> >
>> > Isn't this setup redundant at all, since imx_pmx_enable() already takes
>> > care of setting mux register including GPIO mode?
>> >
>>
>> Yes currently this is redundant, when a pinmux is actually applied. What
>> is the expected behaviour? Is a explicit pinmux necessary before we can
>> use GPIO? If not, maybe it would make more sense to use imx_pmx_enable
>> here to write all pinctrl settings?
> 
> Okay, as per Documentation/pinctrl.txt, it's required that GPIO and
> PINCTRL can be used as orthogonal.  That said, your code does the right
> thing.  Sorry for the noisy comment.
> 

I'm happy you came up with this, since its the thing which I'm must
unsure whether this is right.

Right now, if you just export a random pin (which has no pinmux
configured in dt), you get an error since this function fails (mux_reg
== -1). But I guess we can't avoid it, we need the pinctrl framework to
have a valid setting before we fiddle around with the pad.

But now, if there is a pinmux configuration in dt, but its not applied
(using pinctrl-0 = ...), the export will succeed, however the GPIO will
not really be usable since no sane pad configuration is not applied
(input/output buffer disabled, no drive-strength)... So we might well
just don't change the mux here too.

IMHO, fully orthogonal is not possible, since on Vybrid those two depend
on each other. But in order to make it "more orthogonal", we maybe
should force applying the full configuration in
imx_pmx_gpio_request_enable (e.g. drive strenght etc), rather then only
mux the pad to to GPIO...

What do you think?

>>
>> >> +
>> >> +	return 0;
>> >> +}
>> >> +
>> >> +static int imx_pmx_gpio_set_direction(struct pinctrl_dev *pctldev,
>> >> +	   struct pinctrl_gpio_range *range, unsigned offset, bool input)
>> >> +{
>> >> +	struct imx_pinctrl *ipctl = pinctrl_dev_get_drvdata(pctldev);
>> >> +	const struct imx_pinctrl_soc_info *info = ipctl->info;
>> >> +	const struct imx_pin_reg *pin_reg;
>> >> +	u32 reg;
>> >> +
>> >> +	if (!(info->flags & GPIO_CONTROL))
>> >> +		return -EINVAL;
>> >> +
>> >> +	pin_reg = &info->pin_regs[offset];
>> >> +	if (pin_reg->mux_reg == -1)
>> >> +		return -EINVAL;
>> >> +
>> >> +	reg = readl(ipctl->base + pin_reg->mux_reg);
>> >> +	if (input)
>> >> +		reg &= ~0x2;
>> >> +	else
>> >> +		reg |= 0x2;
>> >
>> > This is all about Output Buffer Enable (OBE) bit.  What about Input
>> > Buffer Enable (IBE) bit?  Don't we need to set or clear it as per GPIO
>> > direction as well?
>> >
>>
>> The leave the input buffer doesn't hurt, it allows to read back the
>> value which is actually "on the wire". If a pin is hard on GND, one can
>> actually see that.
> 
> Okay.
> 
>>
>> >> +	writel(reg, ipctl->base + pin_reg->mux_reg);
>> >> +
>> >> +	return 0;
>> >> +}
>> >> +
>> >>  static const struct pinmux_ops imx_pmx_ops = {
>> >>  	.get_functions_count = imx_pmx_get_funcs_count,
>> >>  	.get_function_name = imx_pmx_get_func_name,
>> >>  	.get_function_groups = imx_pmx_get_groups,
>> >> +	.gpio_request_enable = imx_pmx_gpio_request_enable,
>> >> +	.gpio_set_direction = imx_pmx_gpio_set_direction,
>> >>  	.enable = imx_pmx_enable,
>> >>  };
>> >>
>> >> @@ -579,6 +628,11 @@ int imx_pinctrl_probe(struct platform_device *pdev,
>> >>  		dev_err(&pdev->dev, "wrong pinctrl info\n");
>> >>  		return -EINVAL;
>> >>  	}
>> >> +
>> >> +	/* GPIO control functions only intended for shared mux/conf register */
>> >> +	if (info->flags & GPIO_CONTROL)
>> >> +		BUG_ON(!(info->flags & SHARE_MUX_CONF_REG));
>> >> +
>> >
>> > If this is always true, why don't we just use flag SHARE_MUX_CONF_REG
>> > and save GPIO_CONTROL?  This check doesn't make too much sense to me if
>> > we choose to have a new flag for GPIO setup.  IMO, we should probably
>> > either drop the GPIO_CONTROL flag or the check.
>> >
>>
>> Well, this is always true because the vf610 driver configures both
>> configs. But when somebody accidentally enables GPIO_CONFIG without
>> understanding the implications... This was more meant like "don't try to
>> use the GPIO_CONTROL just like that, its Vybird specific".
> 
> But it will become a blocker if some day an i.MX controller (no flag
> SHARE_MUX_CONF_REG) needs to use GPIO_CONFIG.
> 
>> But I'm ok to remove this runtime check, maybe a comment describing the
>> flags is more appropriate..?
> 
> Sounds good.
> 
> Shawn
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/