Thread (19 messages) 19 messages, 7 authors, 2017-01-09

Re: [PATCH] iio: misc: add a generic regulator driver

From: Bartosz Golaszewski <hidden>
Date: 2016-12-13 14:28:26
Also in: linux-iio, lkml

2016-12-12 18:15 GMT+01:00 Lars-Peter Clausen [off-list ref]:
On 12/06/2016 12:12 PM, Bartosz Golaszewski wrote:
[snip!]
quoted
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
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help