Re: [RFC PATCH v2] pinctrl: add helper to expose pinctrl state in debugfs
On Mon, Jan 11, 2021 at 12:03:18PM +0200, Tony Lindgren wrote: > Hi, > > * Linus Walleij [210109 21:14]: > > On Sat, Jan 9, 2021 at 3:55 AM Drew Fustini wrote: > > > > > I discussed my use case and this patch on #armlinux earlier this week > > > and Alexandre Belloni suggested looking at the pinmux-pins debugfs file. > > > > This sounds reasonable. > > > > > This made me think that a possible solution could be to define a store > > > function for pinmux-pins to handle something like " ". > > > I believe the ability to activate a pin function (or pin group) from > > > userspace would satisfy our beagleboard.org use-case. > > > > > > Does that seem like a reasonable approach? > > > > This sounds like a good approach. > > Makes sense to me too. > > We may want to make it into a proper sysfs interface eventually to not > require debugfs be enabled in .config. But that's another set of patches, > certainly makes sense to first enable it for debugfs. > > Regards, > > Tony I have added a debugfs file "pinmux-set" to pinmux.c. This allows " " to be written into that file. The function pinmux_set_write() calls ops->set_mux() with fsel and gsel. I'll post an RFC with the code, but I am wondering if it would better to take the function as a name and then lookup the function number (fsel)? thanks, drew
Re: [RFC PATCH v2] pinctrl: add helper to expose pinctrl state in debugfs
Hi, * Linus Walleij [210109 21:14]: > On Sat, Jan 9, 2021 at 3:55 AM Drew Fustini wrote: > > > I discussed my use case and this patch on #armlinux earlier this week > > and Alexandre Belloni suggested looking at the pinmux-pins debugfs file. > > This sounds reasonable. > > > This made me think that a possible solution could be to define a store > > function for pinmux-pins to handle something like " ". > > I believe the ability to activate a pin function (or pin group) from > > userspace would satisfy our beagleboard.org use-case. > > > > Does that seem like a reasonable approach? > > This sounds like a good approach. Makes sense to me too. We may want to make it into a proper sysfs interface eventually to not require debugfs be enabled in .config. But that's another set of patches, certainly makes sense to first enable it for debugfs. Regards, Tony
Re: [RFC PATCH v2] pinctrl: add helper to expose pinctrl state in debugfs
On Sat, Jan 9, 2021 at 3:55 AM Drew Fustini wrote: > I discussed my use case and this patch on #armlinux earlier this week > and Alexandre Belloni suggested looking at the pinmux-pins debugfs file. This sounds reasonable. > This made me think that a possible solution could be to define a store > function for pinmux-pins to handle something like " ". > I believe the ability to activate a pin function (or pin group) from > userspace would satisfy our beagleboard.org use-case. > > Does that seem like a reasonable approach? This sounds like a good approach. Yours, Linus Walleij
Re: [RFC PATCH v2] pinctrl: add helper to expose pinctrl state in debugfs
On Sat, Jan 09, 2021 at 02:22:07AM +0100, Linus Walleij wrote:
> Hi Drew,
>
> sorry for belated review. The approach is so uncommon so it had me
> confused.
>
> On Thu, Dec 24, 2020 at 9:36 PM Drew Fustini wrote:
>
> > > > I used the compatible string "pinctrl,state-helper" but would appreciate
> > > > advice on how to best name this. Should I create a new vendor prefix?
> > >
> > > Here is the first concern. Why does this require to be a driver with a
> > > compatible string?
> >
> > I have not been able to figure out how to have different active pinctrl
> > states for each header pins (for example P2 header pin 3) unless they
> > are represented as DT nodes with their own compatible for this helper
> > driver such as:
> >
> > {
> > P2_03_pinmux {
> > compatible = "pinctrl,state-helper";
> > pinctrl-names = "default", "gpio", "gpio_pu", "gpio_pd",
> > "gpio_input", "pwm";
> > pinctrl-0 = <_03_default_pin>;
> > pinctrl-1 = <_03_gpio_pin>;
> > pinctrl-2 = <_03_gpio_pu_pin>;
> > pinctrl-3 = <_03_gpio_pd_pin>;
> > pinctrl-4 = <_03_gpio_input_pin>;
> > pinctrl-5 = <_03_pwm_pin>;
> > };
> > }
>
> I do not think the DT people are going to appreciate this pseudo-device.
Thank you for reviewing and commenting.
It is does seem like creating a platform device for each header pin and
binding to this proposed helper driver is not the correct approach.
> Can you not just represent them as pin control hogs and have the debugfs
> code with the other debugfs code in drivers/pinctrl/core.c?
I tried defining pinctrl states in the am33xx_pinmux DT node (which has
compatible "pinctrl-single"). It does work to have default state
defined for pins. However, I was not sure how represent having
different states active for independent header pins.
Instead of DT binds, maybe I need to use PIN_MAP_MUX_GROUP_HOG_DEFAULT()
in pinctrl-single code?
>
> Normal drivers cannot play around with the state assigned to a
> hog, but debugfs can certainly do that so go ahead and patch
> the core.
Is there an existing debugfs file that you think would be appropriate to
allow the state of a hog to be changed?
> > I can assign pinctrl states in the pin controller DT node which has
> > compatible pinctrl-single (line 301 arch/arm/boot/dts/am33xx-l4.dtsi):
> >
> > _pinmux {
> >
> > pinctrl-names = "default", "gpio", "pwm";
> > pinctrl-0 = < _03_default_pin _34_default_pin
> > _19_default_pin _24_default_pin
> > _33_default_pin _22_default_pin
> > _18_default_pin _10_default_pin
> > _06_default_pin _04_default_pin
> > _02_default_pin _08_default_pin
> > _17_default_pin >;
> > pinctrl-1 = < _03_gpio_pin _34_gpio_pin _19_gpio_pin
> > _24_gpio_pin
> > _33_gpio_pin _22_gpio_pin _18_gpio_pin
> > _10_gpio_pin
> > _06_gpio_pin _04_gpio_pin _02_gpio_pin
> > _08_gpio_pin
> > _17_gpio_pin >;
> > pinctrl-2 = < _03_pwm _34_pwm _19_pwm _24_pwm
> > _33_pwm _22_pwm _18_pwm _10_pwm
> > _06_pwm _04_pwm _02_pwm _08_pwm
> > _17_pwm >;
> >
> > }
> >
> > However, there is no way to later select "gpio" for P2.03 and select
> > "pwm" for P1.34 at the same time. Thus, I can not figure out a way to
> > select independent states per pin unless I make a node for each pin that
> > binds to a helper driver.
> >
> > It feels like there may be a simpler soluation but I can't see to figure
> > it out. Suggestions welcome!
>
> I think maybe there is no solution because you are solving a problem
> that only pinctrl-single while trying to stay generic? The single
> driver is special in that it requires all states of pins to be encoded
> into the device tree, but for debugging that is kind of unfriendly
> which was mentioned in its inception. For deep debugging it is good
> to let the core know of all available functions and groups and
> single does not IIUC.
>
> Yours,
> Linus Walleij
I discussed my use case and this patch on #armlinux earlier this week
and Alexandre Belloni suggested looking at the pinmux-pins debugfs file.
This made me think that a possible solution could be to define a store
function for pinmux-pins to handle something like " ".
I believe the ability to activate a pin function (or pin group) from
userspace would satisfy our beagleboard.org use-case.
Does that seem like a reasonable approach?
Thank you!
Drew
Re: [RFC PATCH v2] pinctrl: add helper to expose pinctrl state in debugfs
Hi Drew,
sorry for belated review. The approach is so uncommon so it had me
confused.
On Thu, Dec 24, 2020 at 9:36 PM Drew Fustini wrote:
> > > I used the compatible string "pinctrl,state-helper" but would appreciate
> > > advice on how to best name this. Should I create a new vendor prefix?
> >
> > Here is the first concern. Why does this require to be a driver with a
> > compatible string?
>
> I have not been able to figure out how to have different active pinctrl
> states for each header pins (for example P2 header pin 3) unless they
> are represented as DT nodes with their own compatible for this helper
> driver such as:
>
> {
> P2_03_pinmux {
> compatible = "pinctrl,state-helper";
> pinctrl-names = "default", "gpio", "gpio_pu", "gpio_pd",
> "gpio_input", "pwm";
> pinctrl-0 = <_03_default_pin>;
> pinctrl-1 = <_03_gpio_pin>;
> pinctrl-2 = <_03_gpio_pu_pin>;
> pinctrl-3 = <_03_gpio_pd_pin>;
> pinctrl-4 = <_03_gpio_input_pin>;
> pinctrl-5 = <_03_pwm_pin>;
> };
> }
I do not think the DT people are going to appreciate this pseudo-device.
Can you not just represent them as pin control hogs and have the debugfs
code with the other debugfs code in drivers/pinctrl/core.c?
Normal drivers cannot play around with the state assigned to a
hog, but debugfs can certainly do that so go ahead and patch
the core.
> I can assign pinctrl states in the pin controller DT node which has
> compatible pinctrl-single (line 301 arch/arm/boot/dts/am33xx-l4.dtsi):
>
> _pinmux {
>
> pinctrl-names = "default", "gpio", "pwm";
> pinctrl-0 = < _03_default_pin _34_default_pin
> _19_default_pin _24_default_pin
> _33_default_pin _22_default_pin
> _18_default_pin _10_default_pin
> _06_default_pin _04_default_pin
> _02_default_pin _08_default_pin
> _17_default_pin >;
> pinctrl-1 = < _03_gpio_pin _34_gpio_pin _19_gpio_pin
> _24_gpio_pin
> _33_gpio_pin _22_gpio_pin _18_gpio_pin
> _10_gpio_pin
> _06_gpio_pin _04_gpio_pin _02_gpio_pin
> _08_gpio_pin
> _17_gpio_pin >;
> pinctrl-2 = < _03_pwm _34_pwm _19_pwm _24_pwm
> _33_pwm _22_pwm _18_pwm _10_pwm
> _06_pwm _04_pwm _02_pwm _08_pwm
> _17_pwm >;
>
> }
>
> However, there is no way to later select "gpio" for P2.03 and select
> "pwm" for P1.34 at the same time. Thus, I can not figure out a way to
> select independent states per pin unless I make a node for each pin that
> binds to a helper driver.
>
> It feels like there may be a simpler soluation but I can't see to figure
> it out. Suggestions welcome!
I think maybe there is no solution because you are solving a problem
that only pinctrl-single while trying to stay generic? The single
driver is special in that it requires all states of pins to be encoded
into the device tree, but for debugging that is kind of unfriendly
which was mentioned in its inception. For deep debugging it is good
to let the core know of all available functions and groups and
single does not IIUC.
Yours,
Linus Walleij
Re: [RFC PATCH v2] pinctrl: add helper to expose pinctrl state in debugfs
On Thu, Dec 24, 2020 at 02:36:03PM -0600, Drew Fustini wrote:
> On Fri, Dec 18, 2020 at 06:01:25PM +0200, Andy Shevchenko wrote:
> > On Fri, Dec 18, 2020 at 6:52 AM Drew Fustini wrote:
> > >
> > > BeagleBoard.org [0] currently uses an out-of-tree driver called
> > > bone-pinmux-helper [1] developed by Pantelis Antoniou [2] back in 2013.
> > > The driver assists users of our BeagleBone and PocketBeagle boards in
> > > rapid prototyping by allowing them to change at run-time between defined
> > > set of pinctrl states [3] for each pin on the expansion connectors [4].
> > > This is achieved by exposing a 'state' file in sysfs for each pin which
> > > is used by our 'config-pin' utility [5].
> > >
> > > Our goal is to eliminate all out-of-tree drivers for BeagleBoard.org
> > > boards and thus I have been working to replace bone-pinmux-helper with a
> > > new driver that could be acceptable upstream. My understanding is that
> > > debugfs, unlike sysfs, could be the appropriate mechanism to expose such
> > > functionality.
> >
> > No objections here.
> >
> > > I used the compatible string "pinctrl,state-helper" but would appreciate
> > > advice on how to best name this. Should I create a new vendor prefix?
> >
> > Here is the first concern. Why does this require to be a driver with a
> > compatible string?
>
> I have not been able to figure out how to have different active pinctrl
> states for each header pins (for example P2 header pin 3) unless they
> are represented as DT nodes with their own compatible for this helper
> driver such as:
>
> {
> P2_03_pinmux {
> compatible = "pinctrl,state-helper";
> pinctrl-names = "default", "gpio", "gpio_pu", "gpio_pd",
> "gpio_input", "pwm";
> pinctrl-0 = <_03_default_pin>;
> pinctrl-1 = <_03_gpio_pin>;
> pinctrl-2 = <_03_gpio_pu_pin>;
> pinctrl-3 = <_03_gpio_pd_pin>;
> pinctrl-4 = <_03_gpio_input_pin>;
> pinctrl-5 = <_03_pwm_pin>;
> };
> }
>
> I can assign pinctrl states in the pin controller DT node which has
> compatible pinctrl-single (line 301 arch/arm/boot/dts/am33xx-l4.dtsi):
>
> _pinmux {
>
> pinctrl-names = "default", "gpio", "pwm";
> pinctrl-0 = < _03_default_pin _34_default_pin
> _19_default_pin _24_default_pin
> _33_default_pin _22_default_pin
> _18_default_pin _10_default_pin
> _06_default_pin _04_default_pin
> _02_default_pin _08_default_pin
> _17_default_pin >;
> pinctrl-1 = < _03_gpio_pin _34_gpio_pin _19_gpio_pin
> _24_gpio_pin
> _33_gpio_pin _22_gpio_pin _18_gpio_pin
> _10_gpio_pin
> _06_gpio_pin _04_gpio_pin _02_gpio_pin
> _08_gpio_pin
> _17_gpio_pin >;
> pinctrl-2 = < _03_pwm _34_pwm _19_pwm _24_pwm
> _33_pwm _22_pwm _18_pwm _10_pwm
> _06_pwm _04_pwm _02_pwm _08_pwm
> _17_pwm >;
>
> }
>
> However, there is no way to later select "gpio" for P2.03 and select
> "pwm" for P1.34 at the same time. Thus, I can not figure out a way to
> select independent states per pin unless I make a node for each pin that
> binds to a helper driver.
>
> It feels like there may be a simpler soluation but I can't see to figure
> it out. Suggestions welcome!
>
> >
> > > The P9_14_pinmux entry would cause pinctrl-state-helper to be probed.
> > > The driver would create the corresponding pinctrl state file in debugfs
> > > for the pin. Here is an example of how the state can be read and
> > > written from userspace:
> > >
> > > root@beaglebone:~# cat
> > > /sys/kernel/debug/pinctrl/pinctrl_state/ocp:P9_14_pinmux/state
> > > default
> > > root@beaglebone:~# echo pwm >
> > > /sys/kernel/debug/pinctrl/pinctrl_state/ocp:P9_14_pinmux/state
> > > root@beaglebone:~# cat
> > > /sys/kernel/debug/pinctrl/pinctrl_state/ocp:P9_14_pinmux/state
> > > pwm
> > >
> > > I would very much appreciate feedback on both this general concept, and
> > > also specific areas in which the code should be changed to be acceptable
> > > upstream.
> >
> > Two more concerns:
> > - why is it OF only?
>
> I am open to figuring out a more general solution but I am really only
> familiar with Device Tree. Is there a way to represent the possible
> pinctrl states in ACPI?
>
> > - why has it been separated from pin control per device debug folder?
>
> >From the v1 thread, I see what you mean that there could be a combined
> state file for each pinctrl device where one would echo '
> ' such as 'P2_03 pwm'. I will attempt to implement that.
I have tried creating a single state file:
/sys/kernel/debug/pinctrl/pinctrl_state
where one can write into it:
such as:
ocp:P9_14_pinmux gpio
However, I can not figure out a way for this to work.
I create the pinctrl_state file in pinctrl_state_helper_init() and
Re: [RFC PATCH v2] pinctrl: add helper to expose pinctrl state in debugfs
On Fri, Dec 18, 2020 at 06:01:25PM +0200, Andy Shevchenko wrote:
> On Fri, Dec 18, 2020 at 6:52 AM Drew Fustini wrote:
> >
> > BeagleBoard.org [0] currently uses an out-of-tree driver called
> > bone-pinmux-helper [1] developed by Pantelis Antoniou [2] back in 2013.
> > The driver assists users of our BeagleBone and PocketBeagle boards in
> > rapid prototyping by allowing them to change at run-time between defined
> > set of pinctrl states [3] for each pin on the expansion connectors [4].
> > This is achieved by exposing a 'state' file in sysfs for each pin which
> > is used by our 'config-pin' utility [5].
> >
> > Our goal is to eliminate all out-of-tree drivers for BeagleBoard.org
> > boards and thus I have been working to replace bone-pinmux-helper with a
> > new driver that could be acceptable upstream. My understanding is that
> > debugfs, unlike sysfs, could be the appropriate mechanism to expose such
> > functionality.
>
> No objections here.
>
> > I used the compatible string "pinctrl,state-helper" but would appreciate
> > advice on how to best name this. Should I create a new vendor prefix?
>
> Here is the first concern. Why does this require to be a driver with a
> compatible string?
I have not been able to figure out how to have different active pinctrl
states for each header pins (for example P2 header pin 3) unless they
are represented as DT nodes with their own compatible for this helper
driver such as:
{
P2_03_pinmux {
compatible = "pinctrl,state-helper";
pinctrl-names = "default", "gpio", "gpio_pu", "gpio_pd",
"gpio_input", "pwm";
pinctrl-0 = <_03_default_pin>;
pinctrl-1 = <_03_gpio_pin>;
pinctrl-2 = <_03_gpio_pu_pin>;
pinctrl-3 = <_03_gpio_pd_pin>;
pinctrl-4 = <_03_gpio_input_pin>;
pinctrl-5 = <_03_pwm_pin>;
};
}
I can assign pinctrl states in the pin controller DT node which has
compatible pinctrl-single (line 301 arch/arm/boot/dts/am33xx-l4.dtsi):
_pinmux {
pinctrl-names = "default", "gpio", "pwm";
pinctrl-0 = < _03_default_pin _34_default_pin
_19_default_pin _24_default_pin
_33_default_pin _22_default_pin
_18_default_pin _10_default_pin
_06_default_pin _04_default_pin
_02_default_pin _08_default_pin
_17_default_pin >;
pinctrl-1 = < _03_gpio_pin _34_gpio_pin _19_gpio_pin
_24_gpio_pin
_33_gpio_pin _22_gpio_pin _18_gpio_pin
_10_gpio_pin
_06_gpio_pin _04_gpio_pin _02_gpio_pin
_08_gpio_pin
_17_gpio_pin >;
pinctrl-2 = < _03_pwm _34_pwm _19_pwm _24_pwm
_33_pwm _22_pwm _18_pwm _10_pwm
_06_pwm _04_pwm _02_pwm _08_pwm
_17_pwm >;
}
However, there is no way to later select "gpio" for P2.03 and select
"pwm" for P1.34 at the same time. Thus, I can not figure out a way to
select independent states per pin unless I make a node for each pin that
binds to a helper driver.
It feels like there may be a simpler soluation but I can't see to figure
it out. Suggestions welcome!
>
> > The P9_14_pinmux entry would cause pinctrl-state-helper to be probed.
> > The driver would create the corresponding pinctrl state file in debugfs
> > for the pin. Here is an example of how the state can be read and
> > written from userspace:
> >
> > root@beaglebone:~# cat
> > /sys/kernel/debug/pinctrl/pinctrl_state/ocp:P9_14_pinmux/state
> > default
> > root@beaglebone:~# echo pwm >
> > /sys/kernel/debug/pinctrl/pinctrl_state/ocp:P9_14_pinmux/state
> > root@beaglebone:~# cat
> > /sys/kernel/debug/pinctrl/pinctrl_state/ocp:P9_14_pinmux/state
> > pwm
> >
> > I would very much appreciate feedback on both this general concept, and
> > also specific areas in which the code should be changed to be acceptable
> > upstream.
>
> Two more concerns:
> - why is it OF only?
I am open to figuring out a more general solution but I am really only
familiar with Device Tree. Is there a way to represent the possible
pinctrl states in ACPI?
> - why has it been separated from pin control per device debug folder?
>From the v1 thread, I see what you mean that there could be a combined
state file for each pinctrl device where one would echo '
' such as 'P2_03 pwm'. I will attempt to implement that.
>
>
> > [0] http://beagleboard.org/latest-images
> > [1]
> > https://github.com/beagleboard/linux/blob/5.4/drivers/misc/cape/beaglebone/bone-pinmux-helper.c
> > [2]
> > https://github.com/RobertCNelson/linux-dev/blob/master/patches/drivers/ti/gpio/0001-BeagleBone-pinmux-helper.patch
> > [3]
> > https://github.com/beagleboard/BeagleBoard-DeviceTrees/blob/v5.4.x-ti-overlays/src/arm/am335x-bone-common-univ.dtsi#L2084
> > [4]
> > https://github.com/beagleboard/beaglebone-black/wiki/System-Reference-Manual#section-7-1
> > [5]
> >
Re: [RFC PATCH v2] pinctrl: add helper to expose pinctrl state in debugfs
On Fri, Dec 18, 2020 at 6:52 AM Drew Fustini wrote: > > BeagleBoard.org [0] currently uses an out-of-tree driver called > bone-pinmux-helper [1] developed by Pantelis Antoniou [2] back in 2013. > The driver assists users of our BeagleBone and PocketBeagle boards in > rapid prototyping by allowing them to change at run-time between defined > set of pinctrl states [3] for each pin on the expansion connectors [4]. > This is achieved by exposing a 'state' file in sysfs for each pin which > is used by our 'config-pin' utility [5]. > > Our goal is to eliminate all out-of-tree drivers for BeagleBoard.org > boards and thus I have been working to replace bone-pinmux-helper with a > new driver that could be acceptable upstream. My understanding is that > debugfs, unlike sysfs, could be the appropriate mechanism to expose such > functionality. No objections here. > I used the compatible string "pinctrl,state-helper" but would appreciate > advice on how to best name this. Should I create a new vendor prefix? Here is the first concern. Why does this require to be a driver with a compatible string? > The P9_14_pinmux entry would cause pinctrl-state-helper to be probed. > The driver would create the corresponding pinctrl state file in debugfs > for the pin. Here is an example of how the state can be read and > written from userspace: > > root@beaglebone:~# cat > /sys/kernel/debug/pinctrl/pinctrl_state/ocp:P9_14_pinmux/state > default > root@beaglebone:~# echo pwm > > /sys/kernel/debug/pinctrl/pinctrl_state/ocp:P9_14_pinmux/state > root@beaglebone:~# cat > /sys/kernel/debug/pinctrl/pinctrl_state/ocp:P9_14_pinmux/state > pwm > > I would very much appreciate feedback on both this general concept, and > also specific areas in which the code should be changed to be acceptable > upstream. Two more concerns: - why is it OF only? - why has it been separated from pin control per device debug folder? > [0] http://beagleboard.org/latest-images > [1] > https://github.com/beagleboard/linux/blob/5.4/drivers/misc/cape/beaglebone/bone-pinmux-helper.c > [2] > https://github.com/RobertCNelson/linux-dev/blob/master/patches/drivers/ti/gpio/0001-BeagleBone-pinmux-helper.patch > [3] > https://github.com/beagleboard/BeagleBoard-DeviceTrees/blob/v5.4.x-ti-overlays/src/arm/am335x-bone-common-univ.dtsi#L2084 > [4] > https://github.com/beagleboard/beaglebone-black/wiki/System-Reference-Manual#section-7-1 > [5] > https://github.com/beagleboard/bb.org-overlays/blob/master/tools/beaglebone-universal-io/config-pin -- With Best Regards, Andy Shevchenko
[RFC PATCH v2] pinctrl: add helper to expose pinctrl state in debugfs
BeagleBoard.org [0] currently uses an out-of-tree driver called
bone-pinmux-helper [1] developed by Pantelis Antoniou [2] back in 2013.
The driver assists users of our BeagleBone and PocketBeagle boards in
rapid prototyping by allowing them to change at run-time between defined
set of pinctrl states [3] for each pin on the expansion connectors [4].
This is achieved by exposing a 'state' file in sysfs for each pin which
is used by our 'config-pin' utility [5].
Our goal is to eliminate all out-of-tree drivers for BeagleBoard.org
boards and thus I have been working to replace bone-pinmux-helper with a
new driver that could be acceptable upstream. My understanding is that
debugfs, unlike sysfs, could be the appropriate mechanism to expose such
functionality.
Here is an example of how pin P9.14 on the BeagleBone Black expansion
connector [6] would be represented in device tree:
_pinmux {
/* P9_14 (ZCZ ball U14) gpio1_18 */
P9_14_default_pin: pinmux_P9_14_default_pin { pinctrl-single,pins = <
AM33XX_IOPAD(0x0848, PIN_OUTPUT_PULLDOWN | INPUT_EN |
MUX_MODE7) >; };
P9_14_gpio_pin: pinmux_P9_14_gpio_pin { pinctrl-single,pins = <
AM33XX_IOPAD(0x0848, PIN_OUTPUT | INPUT_EN | MUX_MODE7) >; };
P9_14_gpio_pu_pin: pinmux_P9_14_gpio_pu_pin { pinctrl-single,pins = <
AM33XX_IOPAD(0x0848, PIN_OUTPUT_PULLUP | INPUT_EN | MUX_MODE7)
>; };
P9_14_gpio_pd_pin: pinmux_P9_14_gpio_pd_pin { pinctrl-single,pins = <
AM33XX_IOPAD(0x0848, PIN_OUTPUT_PULLDOWN | INPUT_EN |
MUX_MODE7) >; };
P9_14_gpio_input_pin: pinmux_P9_14_gpio_input_pin { pinctrl-single,pins
= <
AM33XX_IOPAD(0x0848, PIN_INPUT | MUX_MODE7) >; };
P9_14_pwm_pin: pinmux_P9_14_pwm_pin { pinctrl-single,pins = <
AM33XX_IOPAD(0x0848, PIN_OUTPUT_PULLDOWN | INPUT_EN |
MUX_MODE6) >; };
};
{
/* P9_14 (ZCZ ball U14) */
P9_14_pinmux {
compatible = "pinctrl,state-helper";
status = "okay";
pinctrl-names = "default", "gpio", "gpio_pu", "gpio_pd",
"gpio_input", "pwm";
pinctrl-0 = <_14_default_pin>;
pinctrl-1 = <_14_gpio_pin>;
pinctrl-2 = <_14_gpio_pu_pin>;
pinctrl-3 = <_14_gpio_pd_pin>;
pinctrl-4 = <_14_gpio_input_pin>;
pinctrl-5 = <_14_pwm_pin>;
};
};
I used the compatible string "pinctrl,state-helper" but would appreciate
advice on how to best name this. Should I create a new vendor prefix?
The P9_14_pinmux entry would cause pinctrl-state-helper to be probed.
The driver would create the corresponding pinctrl state file in debugfs
for the pin. Here is an example of how the state can be read and
written from userspace:
root@beaglebone:~# cat
/sys/kernel/debug/pinctrl/pinctrl_state/ocp:P9_14_pinmux/state
default
root@beaglebone:~# echo pwm >
/sys/kernel/debug/pinctrl/pinctrl_state/ocp:P9_14_pinmux/state
root@beaglebone:~# cat
/sys/kernel/debug/pinctrl/pinctrl_state/ocp:P9_14_pinmux/state
pwm
I would very much appreciate feedback on both this general concept, and
also specific areas in which the code should be changed to be acceptable
upstream.
Thank you!
Drew
[0] http://beagleboard.org/latest-images
[1]
https://github.com/beagleboard/linux/blob/5.4/drivers/misc/cape/beaglebone/bone-pinmux-helper.c
[2]
https://github.com/RobertCNelson/linux-dev/blob/master/patches/drivers/ti/gpio/0001-BeagleBone-pinmux-helper.patch
[3]
https://github.com/beagleboard/BeagleBoard-DeviceTrees/blob/v5.4.x-ti-overlays/src/arm/am335x-bone-common-univ.dtsi#L2084
[4]
https://github.com/beagleboard/beaglebone-black/wiki/System-Reference-Manual#section-7-1
[5]
https://github.com/beagleboard/bb.org-overlays/blob/master/tools/beaglebone-universal-io/config-pin
[6] https://beagleboard.org/Support/bone101/#headers
Cc: Pantelis Antoniou
Cc: Pantelis Antoniou
Cc: Pantelis Antoniou
Cc: Jason Kridner
Cc: Robert Nelson
Cc: Linus Walleij
Cc: Tony Lindgren
Cc: Andy Shevchenko
Signed-off-by: Drew Fustini
---
v2 changes:
- add RFC: comments in places where I would appreciate feedback
- remove pa...@antoniou-consulting.com as it is bouncing
- add alternative email addresses for Pantelis
- update pinctrl_state_read() to use kasprintf() based on Andy's advice
- update pinctrl_state_write() to use memdup_user_nul()
- call debugfs_lookup() to use existing "pinctrl" dir as parent
- create subdir "pinctrl_state" to be parent of per-pin directories
- add pinctrl_state_helper_init() and pinctrl_state_helper_exit() to
handle creating and cleaning up debugfs_root ("pinctrl_state")
drivers/pinctrl/Kconfig| 10 +
drivers/pinctrl/Makefile | 1 +
drivers/pinctrl/pinctrl-state-helper.c | 241 +
3 files changed, 252 insertions(+)
create mode 100644 drivers/pinctrl/pinctrl-state-helper.c
diff --git a/drivers/pinctrl/Kconfig
