[PATCH V3 0/2] pinctrl: bcm2835: Implement pin_conf_get

[PATCH V3 0/2] pinctrl: bcm2835: Implement pin_conf_get

[Stefan Wahren]

For years, the Raspberry Pi users relied on userspace programs to read
the pin configuration. In the meantime, it has become apparent that this
approach has reached its limits for various reasons.

This patch series now attempts to improve the debugging possibilities on
the kernel side in order to reduce the dependency on these userspace
programs.

Changes in V3:
- convert changes to single return point of success as suggested by
  Andy Shevchenko
- justify ENOTSUPP checkpatch false positive

Changes in V2:
- adjust the BCM2711/7211 pull resistor value according to the Broadcom
  datasheet

Stefan Wahren (2):
  pinctrl: bcm2835: Implement bcm2835_pinconf_get
  pinctrl: bcm2835: Implement bcm2711_pinconf_get

 drivers/pinctrl/bcm/pinctrl-bcm2835.c | 78 +++++++++++++++++++++++++--
 1 file changed, 75 insertions(+), 3 deletions(-)

--
2.34.1

[PATCH V3 1/2] pinctrl: bcm2835: Implement bcm2835_pinconf_get

[Stefan Wahren]

Even the driver already has implemented pin_dbg_show, it could
be helpful to implement pin_conf_get for a more generic behavior.
Contrary to the BCM2711, the BCM2835 SOC doesn't allow to read
the bias config, so the implementation is limited to the basics.

Keep ENOTSUPP here, because it's only used internally.

Signed-off-by: Stefan Wahren <wahrenst@gmx.net>
---
 drivers/pinctrl/bcm/pinctrl-bcm2835.c | 37 +++++++++++++++++++++++++--
 1 file changed, 35 insertions(+), 2 deletions(-)

diff --git a/drivers/pinctrl/bcm/pinctrl-bcm2835.c b/drivers/pinctrl/bcm/pinctrl-bcm2835.c
index 1489191a213f..ed768cefe5d0 100644
--- a/drivers/pinctrl/bcm/pinctrl-bcm2835.c
+++ b/drivers/pinctrl/bcm/pinctrl-bcm2835.c
@@ -1003,8 +1003,41 @@ static const struct pinmux_ops bcm2835_pmx_ops = {
 static int bcm2835_pinconf_get(struct pinctrl_dev *pctldev,
 			unsigned pin, unsigned long *config)
 {
-	/* No way to read back config in HW */
-	return -ENOTSUPP;
+	enum pin_config_param param = pinconf_to_config_param(*config);
+	struct bcm2835_pinctrl *pc = pinctrl_dev_get_drvdata(pctldev);
+	enum bcm2835_fsel fsel = bcm2835_pinctrl_fsel_get(pc, pin);
+	u32 val;
+
+	/* No way to read back bias config in HW */
+
+	switch (param) {
+	case PIN_CONFIG_INPUT_ENABLE:
+		if (fsel != BCM2835_FSEL_GPIO_IN)
+			return -EINVAL;
+
+		*config = pinconf_to_config_packed(param, 1);
+		break;
+
+	case PIN_CONFIG_OUTPUT_ENABLE:
+		if (fsel != BCM2835_FSEL_GPIO_OUT)
+			return -EINVAL;
+
+		*config = pinconf_to_config_packed(param, 1);
+		break;
+
+	case PIN_CONFIG_OUTPUT:
+		if (fsel != BCM2835_FSEL_GPIO_OUT)
+			return -EINVAL;
+
+		val = bcm2835_gpio_get_bit(pc, GPLEV0, pin);
+		*config = pinconf_to_config_packed(param, val);
+		break;
+
+	default:
+		return -ENOTSUPP;
+	}
+
+	return 0;
 }

 static void bcm2835_pull_config_set(struct bcm2835_pinctrl *pc,
--
2.34.1

Re: [PATCH V3 1/2] pinctrl: bcm2835: Implement bcm2835_pinconf_get

[Chen-Yu Tsai]

Hi Linus,

On Sun, Mar 3, 2024 at 10:02 PM Stefan Wahren <wahrenst@gmx.net> wrote:
>
> Even the driver already has implemented pin_dbg_show, it could
> be helpful to implement pin_conf_get for a more generic behavior.
> Contrary to the BCM2711, the BCM2835 SOC doesn't allow to read
> the bias config, so the implementation is limited to the basics.
>
> Keep ENOTSUPP here, because it's only used internally.
>
> Signed-off-by: Stefan Wahren <wahrenst@gmx.net>
> ---
>  drivers/pinctrl/bcm/pinctrl-bcm2835.c | 37 +++++++++++++++++++++++++--
>  1 file changed, 35 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/pinctrl/bcm/pinctrl-bcm2835.c b/drivers/pinctrl/bcm/pinctrl-bcm2835.c
> index 1489191a213f..ed768cefe5d0 100644
> --- a/drivers/pinctrl/bcm/pinctrl-bcm2835.c
> +++ b/drivers/pinctrl/bcm/pinctrl-bcm2835.c
> @@ -1003,8 +1003,41 @@ static const struct pinmux_ops bcm2835_pmx_ops = {
>  static int bcm2835_pinconf_get(struct pinctrl_dev *pctldev,
>                         unsigned pin, unsigned long *config)
>  {
> -       /* No way to read back config in HW */
> -       return -ENOTSUPP;
> +       enum pin_config_param param = pinconf_to_config_param(*config);
> +       struct bcm2835_pinctrl *pc = pinctrl_dev_get_drvdata(pctldev);
> +       enum bcm2835_fsel fsel = bcm2835_pinctrl_fsel_get(pc, pin);
> +       u32 val;
> +
> +       /* No way to read back bias config in HW */
> +
> +       switch (param) {
> +       case PIN_CONFIG_INPUT_ENABLE:
> +               if (fsel != BCM2835_FSEL_GPIO_IN)
> +                       return -EINVAL;
> +
> +               *config = pinconf_to_config_packed(param, 1);
> +               break;
> +
> +       case PIN_CONFIG_OUTPUT_ENABLE:
> +               if (fsel != BCM2835_FSEL_GPIO_OUT)
> +                       return -EINVAL;
> +
> +               *config = pinconf_to_config_packed(param, 1);
> +               break;

I'd like to take this opportunity to ask about INPUT_ENABLE and
OUTPUT_ENABLE.

AFAICT from existing comments in include/linux/pinctrl/pinconf-generic.h ,
these two options refer to input and output buffers or connections within
the general electric path, i.e. it allows the signal to pass through in
a certain direction. It does not refer to the current selected direction
of the GPIO function, which is covered by the PIN_CONFIG_OUTPUT option,
and by gpiolib, if and only if the pin has been allocated for gpiolib
use. But it seems multiple existing drivers do this.

What's the correct thing to do here?


Thanks
ChenYu

> +
> +       case PIN_CONFIG_OUTPUT:
> +               if (fsel != BCM2835_FSEL_GPIO_OUT)
> +                       return -EINVAL;
> +
> +               val = bcm2835_gpio_get_bit(pc, GPLEV0, pin);
> +               *config = pinconf_to_config_packed(param, val);
> +               break;
> +
> +       default:
> +               return -ENOTSUPP;
> +       }
> +
> +       return 0;
>  }
>
>  static void bcm2835_pull_config_set(struct bcm2835_pinctrl *pc,
> --
> 2.34.1
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH V3 1/2] pinctrl: bcm2835: Implement bcm2835_pinconf_get

[Linus Walleij]

On Sun, Mar 3, 2024 at 3:19 PM Chen-Yu Tsai <wens@kernel.org> wrote:

> Hi Linus,
(...)
> I'd like to take this opportunity to ask about INPUT_ENABLE and
> OUTPUT_ENABLE.
>
> AFAICT from existing comments in include/linux/pinctrl/pinconf-generic.h ,
> these two options refer to input and output buffers or connections within
> the general electric path, i.e. it allows the signal to pass through in
> a certain direction. It does not refer to the current selected direction
> of the GPIO function, which is covered by the PIN_CONFIG_OUTPUT option,
> and by gpiolib, if and only if the pin has been allocated for gpiolib
> use. But it seems multiple existing drivers do this.
>
> What's the correct thing to do here?

It's really up to the driver author: the text in pinconf-generic.h does its best
to describe the intended semantics, but sometimes hardware will not fully
match what is said in the documentation.

I guess in this case the PIN_CONFIG_OUTPUT_ENABLE and
PIN_CONFIG_OUTPUT is not two distinctly different things for this
hardware so a reasonable semantic is to implement both in the same
case and do the same for both of them.

+       case PIN_CONFIG_OUTPUT_ENABLE:
+       case PIN_CONFIG_OUTPUT:
+               if (fsel != BCM2835_FSEL_GPIO_OUT)
+                       return -EINVAL;
+
+               val = bcm2835_gpio_get_bit(pc, GPLEV0, pin);
+               *config = pinconf_to_config_packed(param, val);
+               break;

Does it seem reasonable?

Yours,
Linus Walleij

Re: [PATCH V3 1/2] pinctrl: bcm2835: Implement bcm2835_pinconf_get

[Chen-Yu Tsai]

On Wed, Mar 6, 2024 at 6:38 AM Linus Walleij <linus.walleij@linaro.org> wrote:
>
> On Sun, Mar 3, 2024 at 3:19 PM Chen-Yu Tsai <wens@kernel.org> wrote:
>
> > Hi Linus,
> (...)
> > I'd like to take this opportunity to ask about INPUT_ENABLE and
> > OUTPUT_ENABLE.
> >
> > AFAICT from existing comments in include/linux/pinctrl/pinconf-generic.h ,
> > these two options refer to input and output buffers or connections within
> > the general electric path, i.e. it allows the signal to pass through in
> > a certain direction. It does not refer to the current selected direction
> > of the GPIO function, which is covered by the PIN_CONFIG_OUTPUT option,
> > and by gpiolib, if and only if the pin has been allocated for gpiolib
> > use. But it seems multiple existing drivers do this.
> >
> > What's the correct thing to do here?
>
> It's really up to the driver author: the text in pinconf-generic.h does its best
> to describe the intended semantics, but sometimes hardware will not fully
> match what is said in the documentation.
>
> I guess in this case the PIN_CONFIG_OUTPUT_ENABLE and
> PIN_CONFIG_OUTPUT is not two distinctly different things for this
> hardware so a reasonable semantic is to implement both in the same
> case and do the same for both of them.

But that doesn't really match the intended semantics. Maybe the driver
should just ignore PIN_CONFIG_OUTPUT / PIN_CONFIG_INPUT if the hardware
doesn't have matching toggles?

On MediaTek hardware, they have input enable controls, but not for output
enable. So mapping directly to GPIO direction doesn't quite make sense.

ChenYu

> +       case PIN_CONFIG_OUTPUT_ENABLE:
> +       case PIN_CONFIG_OUTPUT:
> +               if (fsel != BCM2835_FSEL_GPIO_OUT)
> +                       return -EINVAL;
> +
> +               val = bcm2835_gpio_get_bit(pc, GPLEV0, pin);
> +               *config = pinconf_to_config_packed(param, val);
> +               break;
>
> Does it seem reasonable?
>
> Yours,
> Linus Walleij

Re: [PATCH V3 1/2] pinctrl: bcm2835: Implement bcm2835_pinconf_get

[Linus Walleij]

On Wed, Mar 6, 2024 at 4:10 AM Chen-Yu Tsai <wens@kernel.org> wrote:
> On Wed, Mar 6, 2024 at 6:38 AM Linus Walleij <linus.walleij@linaro.org> wrote:
> > On Sun, Mar 3, 2024 at 3:19 PM Chen-Yu Tsai <wens@kernel.org> wrote:
> >
> > > Hi Linus,
> > (...)
> > > I'd like to take this opportunity to ask about INPUT_ENABLE and
> > > OUTPUT_ENABLE.
> > >
> > > AFAICT from existing comments in include/linux/pinctrl/pinconf-generic.h ,
> > > these two options refer to input and output buffers or connections within
> > > the general electric path, i.e. it allows the signal to pass through in
> > > a certain direction. It does not refer to the current selected direction
> > > of the GPIO function, which is covered by the PIN_CONFIG_OUTPUT option,
> > > and by gpiolib, if and only if the pin has been allocated for gpiolib
> > > use. But it seems multiple existing drivers do this.
> > >
> > > What's the correct thing to do here?
> >
> > It's really up to the driver author: the text in pinconf-generic.h does its best
> > to describe the intended semantics, but sometimes hardware will not fully
> > match what is said in the documentation.
> >
> > I guess in this case the PIN_CONFIG_OUTPUT_ENABLE and
> > PIN_CONFIG_OUTPUT is not two distinctly different things for this
> > hardware so a reasonable semantic is to implement both in the same
> > case and do the same for both of them.
>
> But that doesn't really match the intended semantics. Maybe the driver
> should just ignore PIN_CONFIG_OUTPUT / PIN_CONFIG_INPUT if the hardware
> doesn't have matching toggles?
>
> On MediaTek hardware, they have input enable controls, but not for output
> enable. So mapping directly to GPIO direction doesn't quite make sense.

I think you should look what will work in practice, given the state
definitions in the device tree file and the runtime requirements from
GPIO.

If these things add up and work in practice it's fine.

Rough consensus and running code.

Yours,
Linus Walleij

Re: [PATCH V3 1/2] pinctrl: bcm2835: Implement bcm2835_pinconf_get

[Chen-Yu Tsai]

On Wed, Mar 6, 2024 at 4:38 PM Linus Walleij <linus.walleij@linaro.org> wrote:
> On Wed, Mar 6, 2024 at 4:10 AM Chen-Yu Tsai <wens@kernel.org> wrote:
> > On Wed, Mar 6, 2024 at 6:38 AM Linus Walleij <linus.walleij@linaro.org> wrote:
> > > On Sun, Mar 3, 2024 at 3:19 PM Chen-Yu Tsai <wens@kernel.org> wrote:
> > >
> > > > Hi Linus,
> > > (...)
> > > > I'd like to take this opportunity to ask about INPUT_ENABLE and
> > > > OUTPUT_ENABLE.
> > > >
> > > > AFAICT from existing comments in include/linux/pinctrl/pinconf-generic.h ,
> > > > these two options refer to input and output buffers or connections within
> > > > the general electric path, i.e. it allows the signal to pass through in
> > > > a certain direction. It does not refer to the current selected direction
> > > > of the GPIO function, which is covered by the PIN_CONFIG_OUTPUT option,
> > > > and by gpiolib, if and only if the pin has been allocated for gpiolib
> > > > use. But it seems multiple existing drivers do this.
> > > >
> > > > What's the correct thing to do here?
> > >
> > > It's really up to the driver author: the text in pinconf-generic.h does its best
> > > to describe the intended semantics, but sometimes hardware will not fully
> > > match what is said in the documentation.
> > >
> > > I guess in this case the PIN_CONFIG_OUTPUT_ENABLE and
> > > PIN_CONFIG_OUTPUT is not two distinctly different things for this
> > > hardware so a reasonable semantic is to implement both in the same
> > > case and do the same for both of them.
> >
> > But that doesn't really match the intended semantics. Maybe the driver
> > should just ignore PIN_CONFIG_OUTPUT / PIN_CONFIG_INPUT if the hardware
> > doesn't have matching toggles?

I meant PIN_CONFIG_OUTPUT_ENABLE and PIN_CONFIG_INPUT_ENABLE here. Sorry.

> > On MediaTek hardware, they have input enable controls, but not for output
> > enable. So mapping directly to GPIO direction doesn't quite make sense.
>
> I think you should look what will work in practice, given the state
> definitions in the device tree file and the runtime requirements from
> GPIO.
>
> If these things add up and work in practice it's fine.
>
> Rough consensus and running code.

I agree that we shouldn't needlessly break existing platforms. But at the
same time we should prevent new additions of incorrect usage. Note that
I am specifically referring to the {INPUT,OUTPUT}_ENABLE configs. I agree
that PIN_CONFIG_OUTPUT works OK, even though I think in some cases a
gpio-hog should be used instead.

For the MediaTek device trees, the only two occurrences of "output-enable"
actually describe conflicting information:

    pins-rts {
            pinmux = <PINMUX_GPIO47__FUNC_URTS1>;
            output-enable;
    };

The above asks for the UART function on this pin, but based on existing
driver definitions, switches the function to GPIO output because of the
"output-enable" property. Hence the confusion.


ChenYu

Re: [PATCH V3 1/2] pinctrl: bcm2835: Implement bcm2835_pinconf_get

[Linus Walleij]

On Wed, Mar 6, 2024 at 9:55 AM Chen-Yu Tsai <wens@kernel.org> wrote:

> For the MediaTek device trees, the only two occurrences of "output-enable"
> actually describe conflicting information:
>
>     pins-rts {
>             pinmux = <PINMUX_GPIO47__FUNC_URTS1>;
>             output-enable;
>     };
>
> The above asks for the UART function on this pin, but based on existing
> driver definitions, switches the function to GPIO output because of the
> "output-enable" property. Hence the confusion.

This is actually also driver-dependent.

It is only conflicting if the pin controller has .strict set in struct
pinmux_ops,
because many SoCs are perfectly capable of using a pin as a function
such as UART RTS and GPIO at *the same time*.

Details on strict mode can be found in Documentation/driver-api/pin-control.rst

I don't know which Mediatek this is but:
$ git grep strict drivers/pinctrl/mediatek/
drivers/pinctrl/mediatek/pinctrl-moore.c:       .strict = true,

Only the Moore family is strict, and I think BCM2835 is not.

Yours,
Linus Walleij

Re: [PATCH V3 1/2] pinctrl: bcm2835: Implement bcm2835_pinconf_get

[Chen-Yu Tsai]

On Wed, Mar 6, 2024 at 8:57 PM Linus Walleij <linus.walleij@linaro.org> wrote:
>
> On Wed, Mar 6, 2024 at 9:55 AM Chen-Yu Tsai <wens@kernel.org> wrote:
>
> > For the MediaTek device trees, the only two occurrences of "output-enable"
> > actually describe conflicting information:
> >
> >     pins-rts {
> >             pinmux = <PINMUX_GPIO47__FUNC_URTS1>;
> >             output-enable;
> >     };
> >
> > The above asks for the UART function on this pin, but based on existing
> > driver definitions, switches the function to GPIO output because of the
> > "output-enable" property. Hence the confusion.
>
> This is actually also driver-dependent.
>
> It is only conflicting if the pin controller has .strict set in struct
> pinmux_ops,
> because many SoCs are perfectly capable of using a pin as a function
> such as UART RTS and GPIO at *the same time*.

I don't think MediaTek falls in this category. Nor does BCM2835. It is
quite obvious, since GPIO in/out are selectable pinmux functions.

> Details on strict mode can be found in Documentation/driver-api/pin-control.rst
>
> I don't know which Mediatek this is but:
> $ git grep strict drivers/pinctrl/mediatek/
> drivers/pinctrl/mediatek/pinctrl-moore.c:       .strict = true,
>
> Only the Moore family is strict, and I think BCM2835 is not.

While that would be true for new drivers, I believe we do have many existing
drivers that cannot set the strict bit, as existing device trees already
have their pinctrl options selecting the GPIO function in conjunction with
*-gpios usage. We also had this on older Allwinner platforms. We ended up
only setting the .strict option for new platforms, not because of any
hardware difference, but because of backwards compatibility. Otherwise
I would love to clean up many of them.

In both MediaTek and BCM2835's cases, it is quite obvious from the driver
that the hardware cannot use the pin as a dedicated function and a GPIO
at the same time. And we should not give them more options to shoot
themselves in the foot.


ChenYu

Re: [PATCH V3 1/2] pinctrl: bcm2835: Implement bcm2835_pinconf_get

[Stefan Wahren]

Hi guys,

Am 06.03.24 um 14:40 schrieb Chen-Yu Tsai:
> On Wed, Mar 6, 2024 at 8:57 PM Linus Walleij <linus.walleij@linaro.org> wrote:
>> On Wed, Mar 6, 2024 at 9:55 AM Chen-Yu Tsai <wens@kernel.org> wrote:
>>
>>> For the MediaTek device trees, the only two occurrences of "output-enable"
>>> actually describe conflicting information:
>>>
>>>      pins-rts {
>>>              pinmux = <PINMUX_GPIO47__FUNC_URTS1>;
>>>              output-enable;
>>>      };
>>>
>>> The above asks for the UART function on this pin, but based on existing
>>> driver definitions, switches the function to GPIO output because of the
>>> "output-enable" property. Hence the confusion.
>> This is actually also driver-dependent.
>>
>> It is only conflicting if the pin controller has .strict set in struct
>> pinmux_ops,
>> because many SoCs are perfectly capable of using a pin as a function
>> such as UART RTS and GPIO at *the same time*.
> I don't think MediaTek falls in this category. Nor does BCM2835. It is
> quite obvious, since GPIO in/out are selectable pinmux functions.
>
>> Details on strict mode can be found in Documentation/driver-api/pin-control.rst
>>
>> I don't know which Mediatek this is but:
>> $ git grep strict drivers/pinctrl/mediatek/
>> drivers/pinctrl/mediatek/pinctrl-moore.c:       .strict = true,
>>
>> Only the Moore family is strict, and I think BCM2835 is not.
> While that would be true for new drivers, I believe we do have many existing
> drivers that cannot set the strict bit, as existing device trees already
> have their pinctrl options selecting the GPIO function in conjunction with
> *-gpios usage. We also had this on older Allwinner platforms. We ended up
> only setting the .strict option for new platforms, not because of any
> hardware difference, but because of backwards compatibility. Otherwise
> I would love to clean up many of them.
>
> In both MediaTek and BCM2835's cases, it is quite obvious from the driver
> that the hardware cannot use the pin as a dedicated function and a GPIO
> at the same time. And we should not give them more options to shoot
> themselves in the foot.
i tried following your discussion. Does it mean i should change anything
here in this series?

Best regards
>
>
> ChenYu

Re: [PATCH V3 1/2] pinctrl: bcm2835: Implement bcm2835_pinconf_get

[Chen-Yu Tsai]

On Thu, Mar 7, 2024 at 1:04 AM Stefan Wahren <wahrenst@gmx.net> wrote:
>
> Hi guys,
>
> Am 06.03.24 um 14:40 schrieb Chen-Yu Tsai:
> > On Wed, Mar 6, 2024 at 8:57 PM Linus Walleij <linus.walleij@linaro.org> wrote:
> >> On Wed, Mar 6, 2024 at 9:55 AM Chen-Yu Tsai <wens@kernel.org> wrote:
> >>
> >>> For the MediaTek device trees, the only two occurrences of "output-enable"
> >>> actually describe conflicting information:
> >>>
> >>>      pins-rts {
> >>>              pinmux = <PINMUX_GPIO47__FUNC_URTS1>;
> >>>              output-enable;
> >>>      };
> >>>
> >>> The above asks for the UART function on this pin, but based on existing
> >>> driver definitions, switches the function to GPIO output because of the
> >>> "output-enable" property. Hence the confusion.
> >> This is actually also driver-dependent.
> >>
> >> It is only conflicting if the pin controller has .strict set in struct
> >> pinmux_ops,
> >> because many SoCs are perfectly capable of using a pin as a function
> >> such as UART RTS and GPIO at *the same time*.
> > I don't think MediaTek falls in this category. Nor does BCM2835. It is
> > quite obvious, since GPIO in/out are selectable pinmux functions.
> >
> >> Details on strict mode can be found in Documentation/driver-api/pin-control.rst
> >>
> >> I don't know which Mediatek this is but:
> >> $ git grep strict drivers/pinctrl/mediatek/
> >> drivers/pinctrl/mediatek/pinctrl-moore.c:       .strict = true,
> >>
> >> Only the Moore family is strict, and I think BCM2835 is not.
> > While that would be true for new drivers, I believe we do have many existing
> > drivers that cannot set the strict bit, as existing device trees already
> > have their pinctrl options selecting the GPIO function in conjunction with
> > *-gpios usage. We also had this on older Allwinner platforms. We ended up
> > only setting the .strict option for new platforms, not because of any
> > hardware difference, but because of backwards compatibility. Otherwise
> > I would love to clean up many of them.
> >
> > In both MediaTek and BCM2835's cases, it is quite obvious from the driver
> > that the hardware cannot use the pin as a dedicated function and a GPIO
> > at the same time. And we should not give them more options to shoot
> > themselves in the foot.
> i tried following your discussion. Does it mean i should change anything
> here in this series?

I think support for PIN_CONFIG_INPUT_ENABLE and PIN_CONFIG_OUTPUT_ENABLE
should be dropped from the series.

ChenYu

Re: [PATCH V3 1/2] pinctrl: bcm2835: Implement bcm2835_pinconf_get

[Stefan Wahren]

Hi,

Am 06.03.24 um 18:07 schrieb Chen-Yu Tsai:
> On Thu, Mar 7, 2024 at 1:04 AM Stefan Wahren <wahrenst@gmx.net> wrote:
>> Hi guys,
>>
>> Am 06.03.24 um 14:40 schrieb Chen-Yu Tsai:
>>> On Wed, Mar 6, 2024 at 8:57 PM Linus Walleij <linus.walleij@linaro.org> wrote:
>>>> On Wed, Mar 6, 2024 at 9:55 AM Chen-Yu Tsai <wens@kernel.org> wrote:
>>>>
>>>>> For the MediaTek device trees, the only two occurrences of "output-enable"
>>>>> actually describe conflicting information:
>>>>>
>>>>>       pins-rts {
>>>>>               pinmux = <PINMUX_GPIO47__FUNC_URTS1>;
>>>>>               output-enable;
>>>>>       };
>>>>>
>>>>> The above asks for the UART function on this pin, but based on existing
>>>>> driver definitions, switches the function to GPIO output because of the
>>>>> "output-enable" property. Hence the confusion.
>>>> This is actually also driver-dependent.
>>>>
>>>> It is only conflicting if the pin controller has .strict set in struct
>>>> pinmux_ops,
>>>> because many SoCs are perfectly capable of using a pin as a function
>>>> such as UART RTS and GPIO at *the same time*.
>>> I don't think MediaTek falls in this category. Nor does BCM2835. It is
>>> quite obvious, since GPIO in/out are selectable pinmux functions.
>>>
>>>> Details on strict mode can be found in Documentation/driver-api/pin-control.rst
>>>>
>>>> I don't know which Mediatek this is but:
>>>> $ git grep strict drivers/pinctrl/mediatek/
>>>> drivers/pinctrl/mediatek/pinctrl-moore.c:       .strict = true,
>>>>
>>>> Only the Moore family is strict, and I think BCM2835 is not.
>>> While that would be true for new drivers, I believe we do have many existing
>>> drivers that cannot set the strict bit, as existing device trees already
>>> have their pinctrl options selecting the GPIO function in conjunction with
>>> *-gpios usage. We also had this on older Allwinner platforms. We ended up
>>> only setting the .strict option for new platforms, not because of any
>>> hardware difference, but because of backwards compatibility. Otherwise
>>> I would love to clean up many of them.
>>>
>>> In both MediaTek and BCM2835's cases, it is quite obvious from the driver
>>> that the hardware cannot use the pin as a dedicated function and a GPIO
>>> at the same time. And we should not give them more options to shoot
>>> themselves in the foot.
>> i tried following your discussion. Does it mean i should change anything
>> here in this series?
> I think support for PIN_CONFIG_INPUT_ENABLE and PIN_CONFIG_OUTPUT_ENABLE
> should be dropped from the series.
okay after applying this series pinconf-pins looks like this:

pin 31 (gpio31): input bias disabled
pin 32 (gpio32): input bias disabled
pin 33 (gpio33): input bias pull up (50000 ohms)
pin 34 (gpio34): input bias disabled
pin 35 (gpio35): input bias pull up (50000 ohms)
pin 36 (gpio36): input bias pull up (50000 ohms)
pin 37 (gpio37): input bias pull up (50000 ohms)
pin 38 (gpio38): input bias pull up (50000 ohms)
pin 39 (gpio39): input bias pull up (50000 ohms)
pin 40 (gpio40): input bias disabled
pin 41 (gpio41): input bias disabled
pin 42 (gpio42): input bias pull up (50000 ohms), output enabled, pin
output (0 level)

After dropping PIN_CONFIG_INPUT_ENABLE and PIN_CONFIG_OUTPUT_ENABLE it
looks like this:

pin 31 (gpio31): input bias disabled
pin 32 (gpio32): input bias disabled
pin 33 (gpio33): input bias pull up (50000 ohms)
pin 34 (gpio34): input bias disabled
pin 35 (gpio35): input bias pull up (50000 ohms)
pin 36 (gpio36): input bias pull up (50000 ohms)
pin 37 (gpio37): input bias pull up (50000 ohms)
pin 38 (gpio38): input bias pull up (50000 ohms)
pin 39 (gpio39): input bias pull up (50000 ohms)
pin 40 (gpio40): input bias disabled
pin 41 (gpio41): input bias disabled
pin 42 (gpio42): input bias pull up (50000 ohms), pin output (0 level)

In case anyone is fine with this, i will send v4.

Btw thanks for answering my questions from here [1] indirectly.

[1] -
https://lore.kernel.org/linux-gpio/102ae999-6574-4b14-a24b-826533b47a5d@gmx.net/
>
> ChenYu

[PATCH V3 2/2] pinctrl: bcm2835: Implement bcm2711_pinconf_get

[Stefan Wahren]

The BCM2711 allows to read the bias config. So implement pin_conf_get
accordingly. The pull resistor values has been taken from the
BCM2711/7211 datasheet.

This implementation assumes that BCM7211 behaves the same way.

Signed-off-by: Stefan Wahren <wahrenst@gmx.net>
---
 drivers/pinctrl/bcm/pinctrl-bcm2835.c | 41 ++++++++++++++++++++++++++-
 1 file changed, 40 insertions(+), 1 deletion(-)

diff --git a/drivers/pinctrl/bcm/pinctrl-bcm2835.c b/drivers/pinctrl/bcm/pinctrl-bcm2835.c
index ed768cefe5d0..7c88626af736 100644
--- a/drivers/pinctrl/bcm/pinctrl-bcm2835.c
+++ b/drivers/pinctrl/bcm/pinctrl-bcm2835.c
@@ -1112,6 +1112,45 @@ static const struct pinconf_ops bcm2835_pinconf_ops = {
 	.pin_config_set = bcm2835_pinconf_set,
 };

+static int bcm2711_pinconf_get(struct pinctrl_dev *pctldev, unsigned pin,
+			       unsigned long *config)
+{
+	struct bcm2835_pinctrl *pc = pinctrl_dev_get_drvdata(pctldev);
+	enum pin_config_param param = pinconf_to_config_param(*config);
+	u32 offset, shift, val;
+
+	offset = PUD_2711_REG_OFFSET(pin);
+	shift = PUD_2711_REG_SHIFT(pin);
+	val = bcm2835_gpio_rd(pc, GP_GPIO_PUP_PDN_CNTRL_REG0 + (offset * 4));
+
+	switch (param) {
+	case PIN_CONFIG_BIAS_DISABLE:
+		if (((val >> shift) & PUD_2711_MASK) != BCM2711_PULL_NONE)
+			return -EINVAL;
+
+		break;
+
+	case PIN_CONFIG_BIAS_PULL_UP:
+		if (((val >> shift) & PUD_2711_MASK) != BCM2711_PULL_UP)
+			return -EINVAL;
+
+		*config = pinconf_to_config_packed(param, 50000);
+		break;
+
+	case PIN_CONFIG_BIAS_PULL_DOWN:
+		if (((val >> shift) & PUD_2711_MASK) != BCM2711_PULL_DOWN)
+			return -EINVAL;
+
+		*config = pinconf_to_config_packed(param, 50000);
+		break;
+
+	default:
+		return bcm2835_pinconf_get(pctldev, pin, config);
+	}
+
+	return 0;
+}
+
 static void bcm2711_pull_config_set(struct bcm2835_pinctrl *pc,
 				    unsigned int pin, unsigned int arg)
 {
@@ -1179,7 +1218,7 @@ static int bcm2711_pinconf_set(struct pinctrl_dev *pctldev,

 static const struct pinconf_ops bcm2711_pinconf_ops = {
 	.is_generic = true,
-	.pin_config_get = bcm2835_pinconf_get,
+	.pin_config_get = bcm2711_pinconf_get,
 	.pin_config_set = bcm2711_pinconf_set,
 };

--
2.34.1

Re: [PATCH V3 2/2] pinctrl: bcm2835: Implement bcm2711_pinconf_get

[Florian Fainelli]

[-- Attachment #1: Type: text/plain, Size: 457 bytes --]

On 3/3/24 06:01, Stefan Wahren wrote:
> The BCM2711 allows to read the bias config. So implement pin_conf_get
> accordingly. The pull resistor values has been taken from the
> BCM2711/7211 datasheet.
> 
> This implementation assumes that BCM7211 behaves the same way.
> 
> Signed-off-by: Stefan Wahren <wahrenst@gmx.net>

Reviewed-by: Florian Fainelli <florian.fainelli@broadcom.com>
Tested-by: Florian Fainelli <florian.fainelli@broadcom.com>
-- 
Florian


[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 4221 bytes --]