| Message ID | 20200628152442.322593-1-drew@beagleboard.org (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | [v2] ARM: dts: am335x-pocketbeagle: set default mux for gpio pins | expand |
Hi, * Drew Fustini <drew@beagleboard.org> [200628 08:26]: > v2 changes: > - change default mux from output to input. Input is safer as it does > not drive the line. If the user wants output, they will need to edit > this device tree. So can you please clarify this a bit, are you saying that gpio output can't be done via userspace? Needing to change the dts does not sound good to me.. But maybe you mean this is needed until the gpio-omap and pinctrl-single patches are merged? Regards, Tony
On Mon, Jun 29, 2020 at 10:03:58AM -0700, Tony Lindgren wrote: > Hi, > > * Drew Fustini <drew@beagleboard.org> [200628 08:26]: > > v2 changes: > > - change default mux from output to input. Input is safer as it does > > not drive the line. If the user wants output, they will need to edit > > this device tree. > > So can you please clarify this a bit, are you saying that gpio output can't > be done via userspace? As it stands, there is no way for userspace to change a pin from gpio input to gpio output as it is based on the reciever active bit in the pin control register (table 9-60 in the AM3358 datasheet [0]). I thought it would be useful to at least define the GPIOs available for use on the PocketBeagle by default (and eventually the other BeagleBone device trees). Input seems to be the safest value. This patch at least makes it more clear where the user should edit to switch from input to output. > Needing to change the dts does not sound good to me.. But maybe you mean > this is needed until the gpio-omap and pinctrl-single patches are merged? > > Regards, > > Tony I agree that I would like for userspace to be able to do run-time changes. However, I think something would need to be added to the pinconf support in pinctrl-single for that to be possible. There are bias properties but non for receiver enable. Does it seem sensible to add that? thanks, drew [0] http://www.ti.com/lit/ds/symlink/am3358.pdf
* Drew Fustini <drew@beagleboard.org> [200630 02:02]: > On Mon, Jun 29, 2020 at 10:03:58AM -0700, Tony Lindgren wrote: > > Hi, > > > > * Drew Fustini <drew@beagleboard.org> [200628 08:26]: > > > v2 changes: > > > - change default mux from output to input. Input is safer as it does > > > not drive the line. If the user wants output, they will need to edit > > > this device tree. > > > > So can you please clarify this a bit, are you saying that gpio output can't > > be done via userspace? > > As it stands, there is no way for userspace to change a pin from gpio > input to gpio output as it is based on the reciever active bit in the > pin control register (table 9-60 in the AM3358 datasheet [0]). OK. I guess one not so nice option would be to enable receiver active for all the gpio pins.. But this also affects power consumption a little. > I thought it would be useful to at least define the GPIOs available for > use on the PocketBeagle by default (and eventually the other BeagleBone > device trees). Input seems to be the safest value. This patch at least > makes it more clear where the user should edit to switch from input to > output. Some TI TRMs actually have tables listing the preferred mux logic for unused pins. I recall safe mode input pull down being one of the preferred modes. Sorry not sure which TRM that is, maybe omap3 or omap4 or omap5? > > Needing to change the dts does not sound good to me.. But maybe you mean > > this is needed until the gpio-omap and pinctrl-single patches are merged? > > I agree that I would like for userspace to be able to do run-time > changes. However, I think something would need to be added to the > pinconf support in pinctrl-single for that to be possible. There are > bias properties but non for receiver enable. > > Does it seem sensible to add that? Well let's see with Linus W says. To me it seems this might be a good reason to allow a sysfs interface to change the pinctrl if we don't have it yet? With the proper gpio line naming it should be quite simple to use too :) Regards, Tony
On Tue, Jun 30, 2020 at 11:20:37AM -0700, Tony Lindgren wrote: > * Drew Fustini <drew@beagleboard.org> [200630 02:02]: > > On Mon, Jun 29, 2020 at 10:03:58AM -0700, Tony Lindgren wrote: > > > Hi, > > > > > > * Drew Fustini <drew@beagleboard.org> [200628 08:26]: > > > > v2 changes: > > > > - change default mux from output to input. Input is safer as it does > > > > not drive the line. If the user wants output, they will need to edit > > > > this device tree. > > > > > > So can you please clarify this a bit, are you saying that gpio output can't > > > be done via userspace? > > > > As it stands, there is no way for userspace to change a pin from gpio > > input to gpio output as it is based on the reciever active bit in the > > pin control register (table 9-60 in the AM3358 datasheet [0]). > > OK. I guess one not so nice option would be to enable receiver active > for all the gpio pins.. But this also affects power consumption a little. > > > I thought it would be useful to at least define the GPIOs available for > > use on the PocketBeagle by default (and eventually the other BeagleBone > > device trees). Input seems to be the safest value. This patch at least > > makes it more clear where the user should edit to switch from input to > > output. > > Some TI TRMs actually have tables listing the preferred mux logic > for unused pins. I recall safe mode input pull down being one of the > preferred modes. Sorry not sure which TRM that is, maybe omap3 or > omap4 or omap5? Yes, the AM3358 will default to mode 7 for all of these pins and the receiver will be enabled (e.g. input). So maybe it is redundant for me to specify in DT what is already the hardware reset default? I thought it might be helpful to at least show where the user should edit to change it from the default reset behavior. > > > Needing to change the dts does not sound good to me.. But maybe you mean > > > this is needed until the gpio-omap and pinctrl-single patches are merged? > > > > I agree that I would like for userspace to be able to do run-time > > changes. However, I think something would need to be added to the > > pinconf support in pinctrl-single for that to be possible. There are > > bias properties but non for receiver enable. > > > > Does it seem sensible to add that? > > Well let's see with Linus W says. To me it seems this might be a good > reason to allow a sysfs interface to change the pinctrl if we don't > have it yet? With the proper gpio line naming it should be quite simple > to use too :) I think if pinctrl-single allowed mux to be set through debugfs that could be one solution to the use case of users prototyping with a beaglebone. Maybe that could be acceptable? Thanks, Drew > > Regards, > > Tony
* Drew Fustini <drew@beagleboard.org> [200630 21:32]: > On Tue, Jun 30, 2020 at 11:20:37AM -0700, Tony Lindgren wrote: ... > > > > Needing to change the dts does not sound good to me.. But maybe you mean > > > > this is needed until the gpio-omap and pinctrl-single patches are merged? > > > > > > I agree that I would like for userspace to be able to do run-time > > > changes. However, I think something would need to be added to the > > > pinconf support in pinctrl-single for that to be possible. There are > > > bias properties but non for receiver enable. > > > > > > Does it seem sensible to add that? > > > > Well let's see with Linus W says. To me it seems this might be a good > > reason to allow a sysfs interface to change the pinctrl if we don't > > have it yet? With the proper gpio line naming it should be quite simple > > to use too :) > > I think if pinctrl-single allowed mux to be set through debugfs that > could be one solution to the use case of users prototyping with a > beaglebone. Maybe that could be acceptable? I think this should not depend on debugfs though, it should be a generic interface. Regards, Tony
On Tue, Jun 30, 2020 at 02:34:23PM -0700, Tony Lindgren wrote: > * Drew Fustini <drew@beagleboard.org> [200630 21:32]: > > On Tue, Jun 30, 2020 at 11:20:37AM -0700, Tony Lindgren wrote: > ... > > > > > Needing to change the dts does not sound good to me.. But maybe you mean > > > > > this is needed until the gpio-omap and pinctrl-single patches are merged? > > > > > > > > I agree that I would like for userspace to be able to do run-time > > > > changes. However, I think something would need to be added to the > > > > pinconf support in pinctrl-single for that to be possible. There are > > > > bias properties but non for receiver enable. > > > > > > > > Does it seem sensible to add that? > > > > > > Well let's see with Linus W says. To me it seems this might be a good > > > reason to allow a sysfs interface to change the pinctrl if we don't > > > have it yet? With the proper gpio line naming it should be quite simple > > > to use too :) > > > > I think if pinctrl-single allowed mux to be set through debugfs that > > could be one solution to the use case of users prototyping with a > > beaglebone. Maybe that could be acceptable? > > I think this should not depend on debugfs though, it should be a > generic interface. Ok, thanks. I'm trying to imagine a solution as there no existing pinctrl uAPI. gpiod uAPI has gained some pinctrl functionality with the work that Kent Gibson has been doing beyond just bias flags. Do you think trying to plumb this through gpio-omap is a reasonable approach? thanks, drew
* Drew Fustini <drew@beagleboard.org> [200630 21:43]: > On Tue, Jun 30, 2020 at 02:34:23PM -0700, Tony Lindgren wrote: > > * Drew Fustini <drew@beagleboard.org> [200630 21:32]: > > > On Tue, Jun 30, 2020 at 11:20:37AM -0700, Tony Lindgren wrote: > > ... > > > > > > Needing to change the dts does not sound good to me.. But maybe you mean > > > > > > this is needed until the gpio-omap and pinctrl-single patches are merged? > > > > > > > > > > I agree that I would like for userspace to be able to do run-time > > > > > changes. However, I think something would need to be added to the > > > > > pinconf support in pinctrl-single for that to be possible. There are > > > > > bias properties but non for receiver enable. > > > > > > > > > > Does it seem sensible to add that? > > > > > > > > Well let's see with Linus W says. To me it seems this might be a good > > > > reason to allow a sysfs interface to change the pinctrl if we don't > > > > have it yet? With the proper gpio line naming it should be quite simple > > > > to use too :) > > > > > > I think if pinctrl-single allowed mux to be set through debugfs that > > > could be one solution to the use case of users prototyping with a > > > beaglebone. Maybe that could be acceptable? > > > > I think this should not depend on debugfs though, it should be a > > generic interface. > > Ok, thanks. I'm trying to imagine a solution as there no existing > pinctrl uAPI. gpiod uAPI has gained some pinctrl functionality with > the work that Kent Gibson has been doing beyond just bias flags. OK. Yeah sounds like in this case toggling pinctrl receiver enable should happen automatically with gpio changes. > Do you think trying to plumb this through gpio-omap is a reasonable > approach? I think any sysfs interface to update pinctrl settings should be generic to the pinctrl framework. But maybe making it work via gpio use would do the trick. Regards, Tony
diff --git a/arch/arm/boot/dts/am335x-pocketbeagle.dts b/arch/arm/boot/dts/am335x-pocketbeagle.dts index f0b222201b86..e9cc5cb218f1 100644 --- a/arch/arm/boot/dts/am335x-pocketbeagle.dts +++ b/arch/arm/boot/dts/am335x-pocketbeagle.dts @@ -60,6 +60,104 @@ vmmcsd_fixed: fixedregulator0 { }; &am33xx_pinmux { + + pinctrl-names = "default"; + pinctrl-0 = < &P2_03_gpio &P1_34_gpio &P2_19_gpio &P2_24_gpio + &P2_33_gpio &P2_22_gpio &P2_18_gpio &P2_10_gpio + &P2_06_gpio &P2_04_gpio &P2_02_gpio &P2_08_gpio + &P2_17_gpio >; + + /* P2_03 (ZCZ ball T10) gpio0_23 0x824 */ + P2_03_gpio: pinmux_P2_03_gpio { + pinctrl-single,pins = < + AM33XX_PADCONF(AM335X_PIN_GPMC_AD9, PIN_INPUT_PULLUP, MUX_MODE7) + >; + }; + + /* P1_34 (ZCZ ball T11) gpio0_26 0x828 */ + P1_34_gpio: pinmux_P1_34_gpio { + pinctrl-single,pins = < + AM33XX_PADCONF(AM335X_PIN_GPMC_AD10, PIN_INPUT_PULLUP, MUX_MODE7) + >; + }; + + /* P2_19 (ZCZ ball U12) gpio0_27 0x82c */ + P2_19_gpio: pinmux_P2_19_gpio { + pinctrl-single,pins = < + AM33XX_PADCONF(AM335X_PIN_GPMC_AD11, PIN_INPUT_PULLUP, MUX_MODE7) + >; + }; + + /* P2_24 (ZCZ ball T12) gpio1_12 0x830 */ + P2_24_gpio: pinmux_P2_24_gpio { + pinctrl-single,pins = < + AM33XX_PADCONF(AM335X_PIN_GPMC_AD12, PIN_INPUT_PULLUP, MUX_MODE7) + >; + }; + + /* P2_33 (ZCZ ball R12) gpio1_13 0x834 */ + P2_33_gpio: pinmux_P2_33_gpio { + pinctrl-single,pins = < + AM33XX_PADCONF(AM335X_PIN_GPMC_AD13, PIN_INPUT_PULLUP, MUX_MODE7) + >; + }; + + /* P2_22 (ZCZ ball V13) gpio1_14 0x838 */ + P2_22_gpio: pinmux_P2_22_gpio { + pinctrl-single,pins = < + AM33XX_PADCONF(AM335X_PIN_GPMC_AD14, PIN_INPUT_PULLUP, MUX_MODE7) + >; + }; + + /* P2_18 (ZCZ ball U13) gpio1_15 0x83c */ + P2_18_gpio: pinmux_P2_18_gpio { + pinctrl-single,pins = < + AM33XX_PADCONF(AM335X_PIN_GPMC_AD15, PIN_INPUT_PULLUP, MUX_MODE7) + >; + }; + + /* P2_10 (ZCZ ball R14) gpio1_20 0x850 */ + P2_10_gpio: pinmux_P2_10_gpio { + pinctrl-single,pins = < + AM33XX_PADCONF(AM335X_PIN_GPMC_A4, PIN_INPUT_PULLUP, MUX_MODE7) + >; + }; + + /* P2_06 (ZCZ ball U16) gpio1_25 0x864 */ + P2_06_gpio: pinmux_P2_06_gpio { + pinctrl-single,pins = < + AM33XX_PADCONF(AM335X_PIN_GPMC_A9, PIN_INPUT_PULLUP, MUX_MODE7) + >; + }; + + /* P2_04 (ZCZ ball T16) gpio1_26 0x868 */ + P2_04_gpio: pinmux_P2_04_gpio { + pinctrl-single,pins = < + AM33XX_PADCONF(AM335X_PIN_GPMC_A10, PIN_INPUT_PULLUP, MUX_MODE7) + >; + }; + + /* P2_02 (ZCZ ball V17) gpio1_27 0x86c */ + P2_02_gpio: pinmux_P2_02_gpio { + pinctrl-single,pins = < + AM33XX_PADCONF(AM335X_PIN_GPMC_A11, PIN_INPUT_PULLUP, MUX_MODE7) + >; + }; + + /* P2_08 (ZCZ ball U18) gpio1_28 0x878 */ + P2_08_gpio: pinmux_P2_08_gpio { + pinctrl-single,pins = < + AM33XX_PADCONF(AM335X_PIN_GPMC_BEN1, PIN_INPUT_PULLDOWN, MUX_MODE7) + >; + }; + + /* P2_17 (ZCZ ball V12) gpio2_1 0x88c */ + P2_17_gpio: pinmux_P2_17_gpio { + pinctrl-single,pins = < + AM33XX_PADCONF(AM335X_PIN_GPMC_CLK, PIN_INPUT_PULLUP, MUX_MODE7) + >; + }; + i2c2_pins: pinmux-i2c2-pins { pinctrl-single,pins = < AM33XX_PADCONF(AM335X_PIN_UART1_RTSN, PIN_INPUT_PULLUP, MUX_MODE3) /* (D17) uart1_rtsn.I2C2_SCL */
These pins on the PocketBeagle P1 and P2 headers are connected to AM3358 balls with gpio lines, and these pins are not used for any other peripherals by default. These GPIO lines are unclaimed and could be used by userspace program through the gpiod ABI. This patch adds a "default" state in the am33xx_pinmux node and sets the mux for those pins to gpio (mode 7) with input enable and pull-up or down (per the ball reset rel. state in section 4.2 of datasheet [0]). [0] http://www.ti.com/lit/ds/symlink/am3358.pdf Signed-off-by: Drew Fustini <drew@beagleboard.org> --- v2 changes: - change default mux from output to input. Input is safer as it does not drive the line. If the user wants output, they will need to edit this device tree. arch/arm/boot/dts/am335x-pocketbeagle.dts | 98 +++++++++++++++++++++++ 1 file changed, 98 insertions(+)