driver allowing to define GPIO pin groups and control them via sysfs

Hi,

I'm developing a system based on Xilinx MPSoC chip, where multiple function alities are controlled by AXI GPIO blocks. All those GPIO pins are accessible via sysfs interface. However, it is difficult to find the gpio chip and pin numbers from running Linux system. In the HDL design, the GPIO blocks are described by their names, but unfort unately those names are not propagated to the device tree.

For single pins, I have created a solution, that defines the virtual node i n the device tree:

formatting link
xample/dts/ksgpio.dtsi and provides the kernel space driver that allows to control single pins via functions exported to other kernel drivers:
formatting link

What I need now is something that supports multiple GPIOs and allows to def ine the group of pins like below. (for example assuming that we have a simp le bus with 8-bit address, 8-bit data, read and write strobe, the example s huffles the order of pins to show the required flexibility) In the device tree i can handle it like below:

&amba_pl { multi-gpio { compatible = "wzab,multi-gpio"; data-gpios = , , , , , , , ; address-gpios = , , , , , , , , read-gpios = , write-gpios = , }; }; Of course it would be nice if I could describe the continuous range of GPIO s in a simple way like "data-gpios = ".

But the real problem is how to efficently represent it in the driver? It would be perfect, if I could create the node in the sysfs, like /sys/class/multi-gpio/data, then control its direction and set its value li ke a single gpio:

echo out > /sys/class/multi-gpio/data/direction echo 12 > /sys/class/multi-gpio/data/value echo 1 > /sys/class/multi-gpio/write/value echo 0 > /sys/class/multi-gpio/write/value echo in > /sys/class/multi-gpio/data/direction echo 1 > /sys/class/multi-gpio/read/value val=`cat /sys/class/multi-gpio/data/value` echo 0 > /sys/class/multi-gpio/read/value

Is the above a reasonable approach? Are there any existing solutions that c an be used for such purposes?

Thank you very much in advance, With best regards, Wojtek

Reply to
wzab01
Loading thread data ...

It seems, that the functions devm_gpiod_get_array, gpiod_set_array_value and similar may be useful...

Wojtek

Reply to
wzab01

Well, I have implemented a quick&dirty, proof of the concept implementation of such driver. The sources are available at

formatting link
I'll appreciate any error corrections or suggestions of improvements.

Regards, Wojtek

Reply to
wzab01

The disadvantage of the solution published at

formatting link
is that it requires creating "attributes " representing the groups of gpios manually in the code. It would be good, to have a code that could autamatically scan the device t ree for lists of gpios, and create appropriate attributes. Unfortunately, the standard way of creating the attributes uses macros that are processed at the compile time (DEVICE_ATTR_RO and similar). It seems, that the attributes may be created dynamically at the runtime, us ing the "device_create_file" function, but the "show" and "store" functions should be created in advance. Well, probably it is possible to use the same "show" and "store" function f or all attributes, and then access the appropriate array of GPIOs after che cking the attribute name passed to the function via the "attr" argument (se e
formatting link
ce.h#L553 ). So in fact the only thing that is lacking is the possibility to find all GP IOs list in the device tree node. Unfortunately, the gpiolib does not contain any iterator like "for_each_con _id" that I could run on a platform device... Are there any other ways to do it?

TIA & Regards, Wojtek

Reply to
wzab01

At the moment I have a version of the driver that allows to define the groups of the GPIOs in a single simple table in the driver's code:

static my_attr_t my_attrs[]={ {"dout1",NULL}, {"dout2",NULL}, {"din",NULL}, {NULL,NULL} };

The user is responsible to make sure that the names in the table agree with the DT definition (e.g. in this case it should contain "dout1-gpios", "dout2-gpios and "din-gpios"). The sources of the driver are available at

formatting link

Regards, Wojtek

Reply to
wzab01

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.