| Message ID | 1499982763-29619-2-git-send-email-timur@codeaurora.org |
|---|---|
| State | New |
| Headers | show |
On Thu 13 Jul 14:52 PDT 2017, Timur Tabi wrote: > To support sparse GPIO maps, pinctrl-msm client drivers can specify > that a given GPIO has a pin count of zero. These GPIOs will be > considered "hidden". Any attempt to claim the GPIO will fail, and they > will not be listed in debugfs. > > However, when the driver probes, it calls gpiochip_add_data() which > wants to initialize the direction of all the GPIOs, even the ones that > are unavailable. Therefore, msm_gpio_get_direction() checks to make > sure the pin is available. > > Signed-off-by: Timur Tabi <timur@codeaurora.org> We would have to drop the "const" on the groups arrays of the other platform in order to use this, but I don't have a better suggestion at this time. Acked-by: Bjorn Andersson <bjorn.andersson@linaro.org> Regards, Bjorn > --- > drivers/pinctrl/qcom/pinctrl-msm.c | 34 ++++++++++++++++++++++++++++++---- > 1 file changed, 30 insertions(+), 4 deletions(-) > > diff --git a/drivers/pinctrl/qcom/pinctrl-msm.c b/drivers/pinctrl/qcom/pinctrl-msm.c > index 273badd..e915db4 100644 > --- a/drivers/pinctrl/qcom/pinctrl-msm.c > +++ b/drivers/pinctrl/qcom/pinctrl-msm.c > @@ -165,7 +165,22 @@ static int msm_pinmux_set_mux(struct pinctrl_dev *pctldev, > return 0; > } > > +/* > + * Request a GPIO. If the number of pins for this GPIO group is zero, > + * then assume that the GPIO is unavailable. > + */ > +static int msm_request(struct pinctrl_dev *pctldev, unsigned int offset) > +{ > + struct msm_pinctrl *pctrl = pinctrl_dev_get_drvdata(pctldev); > + const struct msm_pingroup *g; > + > + g = &pctrl->soc->groups[offset]; > + > + return g->npins ? 0 : -ENODEV; > +} > + > static const struct pinmux_ops msm_pinmux_ops = { > + .request = msm_request, > .get_functions_count = msm_get_functions_count, > .get_function_name = msm_get_function_name, > .get_function_groups = msm_get_function_groups, > @@ -430,6 +445,14 @@ static int msm_gpio_get_direction(struct gpio_chip *chip, unsigned int offset) > > g = &pctrl->soc->groups[offset]; > > + /* > + * If the GPIO is unavailable, just return error. This is necessary > + * because the GPIO layer tries to initialize the direction of all > + * the GPIOs, even the ones that are unavailable. > + */ > + if (!g->npins) > + return -ENODEV; > + > val = readl(pctrl->regs + g->ctl_reg); > > /* 0 = output, 1 = input */ > @@ -494,6 +517,11 @@ static void msm_gpio_dbg_show_one(struct seq_file *s, > }; > > g = &pctrl->soc->groups[offset]; > + > + /* If the GPIO group has no pins, then don't show it. */ > + if (!g->npins) > + return; > + > ctl_reg = readl(pctrl->regs + g->ctl_reg); > > is_out = !!(ctl_reg & BIT(g->oe_bit)); > @@ -503,7 +531,7 @@ static void msm_gpio_dbg_show_one(struct seq_file *s, > > seq_printf(s, " %-8s: %-3s %d", g->name, is_out ? "out" : "in", func); > seq_printf(s, " %dmA", msm_regval_to_drive(drive)); > - seq_printf(s, " %s", pulls[pull]); > + seq_printf(s, " %s\n", pulls[pull]); > } > > static void msm_gpio_dbg_show(struct seq_file *s, struct gpio_chip *chip) > @@ -511,10 +539,8 @@ static void msm_gpio_dbg_show(struct seq_file *s, struct gpio_chip *chip) > unsigned gpio = chip->base; > unsigned i; > > - for (i = 0; i < chip->ngpio; i++, gpio++) { > + for (i = 0; i < chip->ngpio; i++, gpio++) > msm_gpio_dbg_show_one(s, NULL, chip, i, gpio); > - seq_puts(s, "\n"); > - } > } > > #else > -- > Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm > Technologies, Inc. Qualcomm Technologies, Inc. is a member of the > Code Aurora Forum, a Linux Foundation Collaborative Project. > -- 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 07/14/2017 11:44 AM, Bjorn Andersson wrote: > We would have to drop the "const" on the groups arrays of the other > platform in order to use this, but I don't have a better suggestion at > this time. Why? I don't modify any data in this patch, and I build just fine with these options enabled: CONFIG_PINCTRL_MSM8916=y CONFIG_PINCTRL_MSM8994=y CONFIG_PINCTRL_MSM8996=y CONFIG_PINCTRL_QDF2XXX=m
On 07/13, Timur Tabi wrote: > diff --git a/drivers/pinctrl/qcom/pinctrl-msm.c b/drivers/pinctrl/qcom/pinctrl-msm.c > index 273badd..e915db4 100644 > --- a/drivers/pinctrl/qcom/pinctrl-msm.c > +++ b/drivers/pinctrl/qcom/pinctrl-msm.c > @@ -165,7 +165,22 @@ static int msm_pinmux_set_mux(struct pinctrl_dev *pctldev, > return 0; > } > > +/* > + * Request a GPIO. If the number of pins for this GPIO group is zero, > + * then assume that the GPIO is unavailable. > + */ > +static int msm_request(struct pinctrl_dev *pctldev, unsigned int offset) These names are awful. Reminds me of the serial driver that has functions like msm_reset(). But when in Rome this is how it goes I suppose. > +{ > + struct msm_pinctrl *pctrl = pinctrl_dev_get_drvdata(pctldev); > + const struct msm_pingroup *g; > + > + g = &pctrl->soc->groups[offset]; > + > + return g->npins ? 0 : -ENODEV; > +} > + > static const struct pinmux_ops msm_pinmux_ops = { > + .request = msm_request, > .get_functions_count = msm_get_functions_count, > .get_function_name = msm_get_function_name, > .get_function_groups = msm_get_function_groups, > @@ -430,6 +445,14 @@ static int msm_gpio_get_direction(struct gpio_chip *chip, unsigned int offset) > > g = &pctrl->soc->groups[offset]; > > + /* > + * If the GPIO is unavailable, just return error. This is necessary > + * because the GPIO layer tries to initialize the direction of all > + * the GPIOs, even the ones that are unavailable. > + */ > + if (!g->npins) > + return -ENODEV; > + gpiochips also have a request() hook. Can we use that before initializing direction to make sure the GPIO is accessible? > val = readl(pctrl->regs + g->ctl_reg); > > /* 0 = output, 1 = input */ > @@ -503,7 +531,7 @@ static void msm_gpio_dbg_show_one(struct seq_file *s, > > seq_printf(s, " %-8s: %-3s %d", g->name, is_out ? "out" : "in", func); > seq_printf(s, " %dmA", msm_regval_to_drive(drive)); > - seq_printf(s, " %s", pulls[pull]); > + seq_printf(s, " %s\n", pulls[pull]); > } > > static void msm_gpio_dbg_show(struct seq_file *s, struct gpio_chip *chip) > @@ -511,10 +539,8 @@ static void msm_gpio_dbg_show(struct seq_file *s, struct gpio_chip *chip) > unsigned gpio = chip->base; > unsigned i; > > - for (i = 0; i < chip->ngpio; i++, gpio++) { > + for (i = 0; i < chip->ngpio; i++, gpio++) > msm_gpio_dbg_show_one(s, NULL, chip, i, gpio); > - seq_puts(s, "\n"); > - } > } Were these two hunks necessary? Looks like noise.
On 07/14/2017 12:11 PM, Stephen Boyd wrote: >> +/* >> + * Request a GPIO. If the number of pins for this GPIO group is zero, >> + * then assume that the GPIO is unavailable. >> + */ >> +static int msm_request(struct pinctrl_dev *pctldev, unsigned int offset) > > These names are awful. Reminds me of the serial driver that has > functions like msm_reset(). But when in Rome this is how it goes > I suppose. I can change it to msm_pinctrl_request(). >> @@ -430,6 +445,14 @@ static int msm_gpio_get_direction(struct gpio_chip *chip, unsigned int offset) >> >> g = &pctrl->soc->groups[offset]; >> >> + /* >> + * If the GPIO is unavailable, just return error. This is necessary >> + * because the GPIO layer tries to initialize the direction of all >> + * the GPIOs, even the ones that are unavailable. >> + */ >> + if (!g->npins) >> + return -ENODEV; >> + > > gpiochips also have a request() hook. Can we use that before > initializing direction to make sure the GPIO is accessible? I'll try that. >> static void msm_gpio_dbg_show(struct seq_file *s, struct gpio_chip *chip) >> @@ -511,10 +539,8 @@ static void msm_gpio_dbg_show(struct seq_file *s, struct gpio_chip *chip) >> unsigned gpio = chip->base; >> unsigned i; >> >> - for (i = 0; i < chip->ngpio; i++, gpio++) { >> + for (i = 0; i < chip->ngpio; i++, gpio++) >> msm_gpio_dbg_show_one(s, NULL, chip, i, gpio); >> - seq_puts(s, "\n"); >> - } >> } > > Were these two hunks necessary? Looks like noise. Yes, because otherwise there will be a whole bunch of blank lines for hidden GPIOs.
On Fri 14 Jul 10:17 PDT 2017, Timur Tabi wrote: > On 07/14/2017 12:11 PM, Stephen Boyd wrote: > > > > +/* > > > + * Request a GPIO. If the number of pins for this GPIO group is zero, > > > + * then assume that the GPIO is unavailable. > > > + */ > > > +static int msm_request(struct pinctrl_dev *pctldev, unsigned int offset) > > > > These names are awful. Reminds me of the serial driver that has > > functions like msm_reset(). But when in Rome this is how it goes > > I suppose. > > I can change it to msm_pinctrl_request(). > msm_pinmux_request() Regards, Bjorn -- 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 Fri 14 Jul 10:01 PDT 2017, Timur Tabi wrote: > On 07/14/2017 11:44 AM, Bjorn Andersson wrote: > > We would have to drop the "const" on the groups arrays of the other > > platform in order to use this, but I don't have a better suggestion at > > this time. > > Why? I don't modify any data in this patch, and I build just fine with > these options enabled: > > CONFIG_PINCTRL_MSM8916=y > CONFIG_PINCTRL_MSM8994=y > CONFIG_PINCTRL_MSM8996=y > CONFIG_PINCTRL_QDF2XXX=m > What I mean is that if we want to specify that any pin of those drivers are locked down we would make npins = 0. But as this is a system configuration thing this information would preferably be injected in runtime (like you do), but the soc_data->groups arrays are currently all const (see e.g. msm8x74_groups), so we can't change npins in runtime. But I think this is fine for now. Regards, Bjorn -- 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 07/14/2017 12:11 PM, Stephen Boyd wrote: > gpiochips also have a request() hook. Can we use that before > initializing direction to make sure the GPIO is accessible? So I tried it, and it didn't work: static int msm_gpio_request(struct gpio_chip *chip, unsigned int offset) { pr_info("%s:%u offset=%u\n", __func__, __LINE__, offset); return 0; } static struct gpio_chip msm_gpio_template = { .request = msm_gpio_request, ... msm_gpio_request() is never called when the driver loads. In fact, I can't figure out when it would be called.
On 07/14, Timur Tabi wrote: > On 07/14/2017 12:11 PM, Stephen Boyd wrote: > >gpiochips also have a request() hook. Can we use that before > >initializing direction to make sure the GPIO is accessible? > > So I tried it, and it didn't work: > > static int msm_gpio_request(struct gpio_chip *chip, unsigned int offset) > { > pr_info("%s:%u offset=%u\n", __func__, __LINE__, offset); > > return 0; > } > > static struct gpio_chip msm_gpio_template = { > .request = msm_gpio_request, > ... > > msm_gpio_request() is never called when the driver loads. In fact, > I can't figure out when it would be called. > Right, the gpiolib core would need to be updated to request the gpio in gpiochip_add_data() around the loop where it goes and configures things. And it could ignore ones that it can't request there.
On 07/14/2017 04:46 PM, Stephen Boyd wrote: > Right, the gpiolib core would need to be updated to request the > gpio in gpiochip_add_data() around the loop where it goes and > configures things. And it could ignore ones that it can't request > there. __gpiod_request already calls chip->request(), so this would need to be a temporary request. It seems a bit hackish, but I'll try it. BTW, I noticed that __gpiod_free() does this: if (chip->free) { spin_unlock_irqrestore(&gpio_lock, flags); ---> might_sleep_if(chip->can_sleep); chip->free(chip, gpio_chip_hwgpio(desc)); spin_lock_irqsave(&gpio_lock, flags); Should __gpiod_request() also call might_sleep_if()? if (chip->request) { /* chip->request may sleep */ spin_unlock_irqrestore(&gpio_lock, flags); ---> missing call to might_sleep_if() here? status = chip->request(chip, gpio_chip_hwgpio(desc)); spin_lock_irqsave(&gpio_lock, flags);
On 07/14, Timur Tabi wrote: > On 07/14/2017 04:46 PM, Stephen Boyd wrote: > >Right, the gpiolib core would need to be updated to request the > >gpio in gpiochip_add_data() around the loop where it goes and > >configures things. And it could ignore ones that it can't request > >there. > > __gpiod_request already calls chip->request(), so this would need to > be a temporary request. It seems a bit hackish, but I'll try it. Yeah, request, configure, free, in a loop. Unless someone is aware why we don't do that here. > > BTW, I noticed that __gpiod_free() does this: > > if (chip->free) { > spin_unlock_irqrestore(&gpio_lock, flags); > ---> might_sleep_if(chip->can_sleep); > chip->free(chip, gpio_chip_hwgpio(desc)); > spin_lock_irqsave(&gpio_lock, flags); > > > Should __gpiod_request() also call might_sleep_if()? > > if (chip->request) { > /* chip->request may sleep */ > spin_unlock_irqrestore(&gpio_lock, flags); > ---> missing call to might_sleep_if() here? > status = chip->request(chip, gpio_chip_hwgpio(desc)); > spin_lock_irqsave(&gpio_lock, flags); > Probably. Except we would have caught it earlier when it was requested?
diff --git a/drivers/pinctrl/qcom/pinctrl-msm.c b/drivers/pinctrl/qcom/pinctrl-msm.c index 273badd..e915db4 100644 --- a/drivers/pinctrl/qcom/pinctrl-msm.c +++ b/drivers/pinctrl/qcom/pinctrl-msm.c @@ -165,7 +165,22 @@ static int msm_pinmux_set_mux(struct pinctrl_dev *pctldev, return 0; } +/* + * Request a GPIO. If the number of pins for this GPIO group is zero, + * then assume that the GPIO is unavailable. + */ +static int msm_request(struct pinctrl_dev *pctldev, unsigned int offset) +{ + struct msm_pinctrl *pctrl = pinctrl_dev_get_drvdata(pctldev); + const struct msm_pingroup *g; + + g = &pctrl->soc->groups[offset]; + + return g->npins ? 0 : -ENODEV; +} + static const struct pinmux_ops msm_pinmux_ops = { + .request = msm_request, .get_functions_count = msm_get_functions_count, .get_function_name = msm_get_function_name, .get_function_groups = msm_get_function_groups, @@ -430,6 +445,14 @@ static int msm_gpio_get_direction(struct gpio_chip *chip, unsigned int offset) g = &pctrl->soc->groups[offset]; + /* + * If the GPIO is unavailable, just return error. This is necessary + * because the GPIO layer tries to initialize the direction of all + * the GPIOs, even the ones that are unavailable. + */ + if (!g->npins) + return -ENODEV; + val = readl(pctrl->regs + g->ctl_reg); /* 0 = output, 1 = input */ @@ -494,6 +517,11 @@ static void msm_gpio_dbg_show_one(struct seq_file *s, }; g = &pctrl->soc->groups[offset]; + + /* If the GPIO group has no pins, then don't show it. */ + if (!g->npins) + return; + ctl_reg = readl(pctrl->regs + g->ctl_reg); is_out = !!(ctl_reg & BIT(g->oe_bit)); @@ -503,7 +531,7 @@ static void msm_gpio_dbg_show_one(struct seq_file *s, seq_printf(s, " %-8s: %-3s %d", g->name, is_out ? "out" : "in", func); seq_printf(s, " %dmA", msm_regval_to_drive(drive)); - seq_printf(s, " %s", pulls[pull]); + seq_printf(s, " %s\n", pulls[pull]); } static void msm_gpio_dbg_show(struct seq_file *s, struct gpio_chip *chip) @@ -511,10 +539,8 @@ static void msm_gpio_dbg_show(struct seq_file *s, struct gpio_chip *chip) unsigned gpio = chip->base; unsigned i; - for (i = 0; i < chip->ngpio; i++, gpio++) { + for (i = 0; i < chip->ngpio; i++, gpio++) msm_gpio_dbg_show_one(s, NULL, chip, i, gpio); - seq_puts(s, "\n"); - } } #else
To support sparse GPIO maps, pinctrl-msm client drivers can specify that a given GPIO has a pin count of zero. These GPIOs will be considered "hidden". Any attempt to claim the GPIO will fail, and they will not be listed in debugfs. However, when the driver probes, it calls gpiochip_add_data() which wants to initialize the direction of all the GPIOs, even the ones that are unavailable. Therefore, msm_gpio_get_direction() checks to make sure the pin is available. Signed-off-by: Timur Tabi <timur@codeaurora.org> --- drivers/pinctrl/qcom/pinctrl-msm.c | 34 ++++++++++++++++++++++++++++++---- 1 file changed, 30 insertions(+), 4 deletions(-)