On Mon, May 19, 2014 at 12:54 PM, Yegor Yefremov <yegorslists@xxxxxxxxxxxxxx> wrote: >> It would be nice if Yegor can give more details about the device that >> are using those GPIO and what he wants to achieve from user-space to >> see if an existing device driver can be used or in any case if a >> generic driver can be written like is done for GPIO leds, keys, etc. > > Let's take VScom Alekto 2 (http://www.visionsystems.de/produkte/6820.html). This seems like a quite straight-forward single-board computer not much unlike e.g. the BeagleBoard or similar. > It has a combi RS232/422/485 driver IC, that has 4 configuration > inputs to set one of the desired modes. Do you mean it can configure the pins into one of these four modes: RS232: TxD,RxD, RTS,CTS, DTR,DSR, DCD, RI, GND RS422: Tx+/-, Rx+/-, GND RS485 2−wire: Data+/-, GND RS485 4−wire: Tx+/-, Rx+/-, GND > These pins are connected via > GPIOs (SoC GPIOs or i2c GPIO expander doesn't matter). The user can > configure these option at run-time. But the above, if I understand correctly are by definition NOT GPIO at *all*. GPIO means "general purpose input output", i.e. something that can emit low/high signals (GPIO out) or read them (GPIO in). This looks much more like 9 pins that can be configured into one of four mission modes, corresponding to one of four serial port types, and that is pin multiplexing not GPIO. > Now he can make it via sysfs by > exporting these GPIOs, setting them to output and changing their > values. What would be the proper kernel driver/interface for this > purpose. Something or other in the TTY/serial layer which may have special features for configuring this from user space. I'm not an expert on that part of the kernel so ask around on the linux-serial list. If there needs to be a pin control driver inbetween dealing with just the registers handling the multiplexing of pins, then surely the serial layer can use that, but that sounds very complex for this usecase. I think the serial subsystem would be handling this? > It also has an IO connector with configurable inputs and outputs. The > problem here it has somewhat complicated structure, because you can > switch direction of the IO pins but this involves enabling/disabling > some hardware ICs. This is quite common and straight-forward GPIO. If we have the datasheet of how to actually program the hardware we can say more about how this should be done. > The whole mechanism is hidden from user through a > library, but the library itself is still using sysfs. Not a sysfs and library designed by the kernel community I suspect? > As for simple designs where the direction of the pins is fixed the > keys driver can be used for inputs, what were the proper driver for > outputs (relays etc.)? Relays is actually one of those cases when userspace control over GPIOs make a lot of sense. We certainly cannot have a kernel driver for every factory line in the world for example. But I want to identify and isolate such use cases. Very often input, leds, PWM etc is what is actually desired. Yours, Linus Walleij -- To unsubscribe from this list: send the line "unsubscribe linux-serial" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
