4

I have some kind of driver in user space:

program talk via some interface(rs232) with device. Also I have pin(gpio) to switch on/off this device.

I do not code in my program concrete gpio, to make it more portable,

so I modify device tree description of my board, and describe regulator-fixed, after that I thought to use userspace-consumer driver to control power on/off, but looks like that not kernel developers expected (link to discussion of similar problem, not my): http://patchwork.ozlabs.org/patch/374912/

So how should I control switch on/off of my device from user space without adding to my program information about what conrete gpio used to switch on/off device?

More details: In my board dts I described my pin like this:

regulator-deviceX {
    status = "okay";
    compatible = "regulator-fixed";
    regulator-name = "DEV_X_ON#";
    regulator-min-microvolt = <3300000>;
    regulator-max-microvolt = <3300000>;
    gpio = <&gpio5 4 GPIO_ACTIVE_LOW>;
};

And of course, after boot "gpio = <&gpio5 4 GPIO_ACTIVE_LOW>" was locked by the kernel, and it is impossible to use it via /sys/class/gpio interface.

Bad think about such approach, that is impossible (or I don't see how) to change regulator state from user space, as you can see "state" is read only file.

root@board:/sys/class/regulator/regulator.1# ls -l
lrwxrwxrwx    1 root     root             0 May  3 03:32 device -> ../../../regulator-deviceX
-r--r--r--    1 root     root          4096 May  3 03:32 microvolts
-r--r--r--    1 root     root          4096 May  3 03:32 name
-r--r--r--    1 root     root          4096 May  3 03:32 num_users
drwxr-xr-x    2 root     root             0 May  3 03:32 power
-r--r--r--    1 root     root          4096 May  3 03:32 state
lrwxrwxrwx    1 root     root             0 May  3 03:25 subsystem ->   ../../../../class/regulator
-r--r--r--    1 root     root          4096 May  3 03:32 suspend_disk_state
-r--r--r--    1 root     root          4096 May  3 03:32 suspend_mem_state
-r--r--r--    1 root     root          4096 May  3 03:32 suspend_standby_state
-r--r--r--    1 root     root          4096 May  3 03:32 type
-rw-r--r--    1 root     root          4096 May  3 03:25 uevent
fghj
  • 8,898
  • 4
  • 28
  • 56
  • So the actual question is "how to obtain gpio number from device tree in user-space"? – Sam Protsenko May 02 '15 at 22:52
  • No, this not helps. For example if I have /sys/firmware/devicetree/base/regulator-xyz/gpios, I can not work with this gpio, because of regulator-fixed lock it for itself usage. – fghj May 02 '15 at 23:00
  • Can you show your `/sys/kernel/debug/gpio` file (can be `/d/gpio` in Android)? If your GPIO number is not in this list, you can export it using `/sys/class/gpio/export` file, like it's described [here](https://www.kernel.org/doc/Documentation/gpio/sysfs.txt), and then trigger it from user-space via `/sys/class/gpio/gpioN/value` file. – Sam Protsenko May 02 '15 at 23:14
  • ...Also, if your GPIO was requested (belongs to) some regulator, you should look for regulator API in sysfs. See [this](https://www.kernel.org/doc/Documentation/ABI/testing/sysfs-class-regulator) for details. Really, the only interface you can probably use for this kind of stuff is sysfs files. If not GPIO directly, then regulator state. Also, why don't do this work in kernel? – Sam Protsenko May 02 '15 at 23:19
  • sysfs-class-regulator do not help, because of all control files readonly, see post update – fghj May 02 '15 at 23:45
  • I suppose there is no sense to show /sys/kernel/debug/gpio, it just show that regulator-fixed module own interesting gpio. – fghj May 02 '15 at 23:46
  • 1
    Hmm... Seems like you really need to use `userspace-consumer` for your regulator. But Mark Rutland is also correct [here](http://patchwork.ozlabs.org/patch/374912/): device tree is intended for hardware specification only. So you should use `userspace-consumer`, but not describing it in device tree. Maybe you should create some dummy driver for this, like it's described [here](http://nishanthmenon.blogspot.com/2013/04/quick-and-dirty-userspace-testing-of.html) (I really love "Now the homework" part there). You can also register it in generic board file, but I think it's bad approach. – Sam Protsenko May 03 '15 at 00:27
  • Ok, looks like I have to add dummy node into device tree (consumer), and write dummy driver compatible with it to control this regulator. – fghj May 03 '15 at 01:08
  • Please add your code (and command to control power in user-space) as an answer once you've finished. We are all excited to see it :) – Sam Protsenko May 03 '15 at 10:45
  • 1
    I add description of final solution – fghj May 04 '15 at 23:41
  • Thanks for your comment, when you have free time, can you look at http://stackoverflow.com/questions/29979210/pins-to-control-screen-rotation-which-api-for-linux-kernel-userspace-to-choos ? – fghj May 04 '15 at 23:43
  • Yup, will look into it tomorrow. – Sam Protsenko May 04 '15 at 23:47

1 Answers1

2

So, the final solution looks like this:

Step 1

Describe device in device tree, though you no need kernel for handling it, but looks right to describe it here

gps-reciever {
    compatible = "my_company_name,gps_recv_name";
    vcc-supply = <&ext_gps_recv_reg>;
    comment = "connected via usb<->rs232, port0";
};

where ext_gps_recv_reg of any normal regulator.

Step 2

I wrote a simple platform device driver for linux kernel, that compatible with device above, and in probe function of this driver I call platform_device_register_full that setup arguments for userspace_consumer driver.

After that I can find suitable file via name: cat /sys/bus/platform/devices/reg-userspace-consumer*/name, and then disable/enable regulator via: echo "disabled" > /sys/bus/platform/devices/reg-userspace-consumer*/state

So I separate device description from linux kernel implementation.

fghj
  • 8,898
  • 4
  • 28
  • 56