2016-12-12 18:15 GMT+01:00 Lars-Peter Clausen <lars@xxxxxxxxxx>: > On 12/06/2016 12:12 PM, Bartosz Golaszewski wrote: [snip!] >> >> So the problem we have is not power-cycling the adc - it's >> power-cycling the device connected to a probe on which there's an adc. >> What I was trying to do was adding support for the power-switch on >> baylibre-acme[1] probes. >> >> For example: we have a USB probe on which the VBUS signal goes through >> a power load switch and than through the adc. The adc (in this case >> ina226) is always powered on, while the fixed regulator I wanted to >> enable/disable actually drives the power switch to cut/restore power >> to the connected USB device i.e. there's no real regulator - just a >> GPIO driving the power switch. >> >> A typical use case is measuring the power consumption of development >> boards[2]. Rebooting them remotely using acme probes is already done, >> but we're using the obsolete /sys/class/gpio interface. >> >> We're already using libiio to read the measured data from the power >> monitor, that's why we'd like to use the iio framework for >> power-cycling the devices as well. My question is: would bridging the >> regulator framework be the right solution? Should we look for >> something else? Bridge the GPIO framework instead? > > I wouldn't necessaries create bridge, but instead just use the GPIO > framework directly. > > We now have the GPIO chardev interface which meant to be used to support > application specific logic that control the GPIOs, but where you don't want > to write a kernel driver. > > My idea was to add GPIOs and GPIO chips as high level object inside libiio > that can be accessed through the same context as the IIO devices. Similar to > the current IIO API you have a API for gpios that allows to enumerate the > GPIO devices and their pins as well as modify the pin state. > + Linus While the new GPIO interface would be very convenient - in our case we could simply name the lines appropriately in the device tree - I'm not sure this would be the correct approach. >From this year's ELCE in Berlin I remember Linus suggested during his talk that it's always better to write a kernel driver. Also: this way the relevant GPIO lines would not be reserved for exclusive use by power switches. Linus - do you have any thoughts/suggestions on that subject? Best regards, Bartosz Golaszewski -- To unsubscribe from this list: send the line "unsubscribe linux-iio" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
