Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1532416 > unrolled thread

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

Back to article view | Back to linux.kernel

Contents

  [PATCH] iio: misc: add a generic regulator driver Bartosz Golaszewski <bgolaszewski@baylibre.com> - 2016-11-29 16:30 +0100
    Re: [PATCH] iio: misc: add a generic regulator driver Lars-Peter Clausen <lars@metafoo.de> - 2016-11-29 16:40 +0100
      Re: [PATCH] iio: misc: add a generic regulator driver Bartosz Golaszewski <bgolaszewski@baylibre.com> - 2016-11-29 16:40 +0100
        Re: [PATCH] iio: misc: add a generic regulator driver Lars-Peter Clausen <lars@metafoo.de> - 2016-11-30 11:20 +0100
          Re: [PATCH] iio: misc: add a generic regulator driver Bartosz Golaszewski <bgolaszewski@baylibre.com> - 2016-12-01 13:10 +0100
          Re: [PATCH] iio: misc: add a generic regulator driver Jonathan Cameron <jic23@kernel.org> - 2016-12-03 15:50 +0100
            Re: [PATCH] iio: misc: add a generic regulator driver Bartosz Golaszewski <bgolaszewski@baylibre.com> - 2016-12-06 12:50 +0100
              Re: [PATCH] iio: misc: add a generic regulator driver Jonathan Cameron <jic23@kernel.org> - 2016-12-10 19:20 +0100

#1532416 — [PATCH] iio: misc: add a generic regulator driver

Some iio devices are powered externally by a regulator which, for
example, can be used to power-cycle an adc.

This patch proposes to add a simple driver representing a regulator
to the iio framework which exports attributes allowing to manipulate
the underlying hardware.

The reason for connecting the regulator and the iio frameworks is that
once libiio learns to toggle iio attributes we'll be able to
power-cycle devices remotely.

Initially the driver only supports enable/disable operations, but it
should be straightforward to extend it with other regulator operations
in the future.

Tested with a baylibre-acme board for beaglebone black.

Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
---
 .../devicetree/bindings/iio/misc/iio-regulator.txt |  18 +++
 drivers/iio/Kconfig                                |   1 +
 drivers/iio/Makefile                               |   1 +
 drivers/iio/misc/Kconfig                           |  17 +++
 drivers/iio/misc/Makefile                          |   6 +
 drivers/iio/misc/iio-regulator.c                   | 121 +++++++++++++++++++++
 6 files changed, 164 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/iio/misc/iio-regulator.txt
 create mode 100644 drivers/iio/misc/Kconfig
 create mode 100644 drivers/iio/misc/Makefile
 create mode 100644 drivers/iio/misc/iio-regulator.c

diff --git a/Documentation/devicetree/bindings/iio/misc/iio-regulator.txt b/Documentation/devicetree/bindings/iio/misc/iio-regulator.txt
new file mode 100644
index 0000000..147458f
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/misc/iio-regulator.txt
@@ -0,0 +1,18 @@
+Industrial IO regulator device driver
+-------------------------------------
+
+This document describes the bindings for the iio-regulator - a dummy device
+driver representing a physical regulator within the iio framework.
+
+Required properties:
+
+- compatible: must be "iio-regulator"
+- vcc-supply: phandle of the regulator this device represents
+
+Example
+-------
+
+iio_regulator {
+	compatible = "iio-regulator";
+	vcc-supply = <&vcc0>;
+};
diff --git a/drivers/iio/Kconfig b/drivers/iio/Kconfig
index 6743b18..2e896e0 100644
--- a/drivers/iio/Kconfig
+++ b/drivers/iio/Kconfig
@@ -80,6 +80,7 @@ source "drivers/iio/gyro/Kconfig"
 source "drivers/iio/health/Kconfig"
 source "drivers/iio/humidity/Kconfig"
 source "drivers/iio/imu/Kconfig"
+source "drivers/iio/misc/Kconfig"
 source "drivers/iio/light/Kconfig"
 source "drivers/iio/magnetometer/Kconfig"
 source "drivers/iio/orientation/Kconfig"
diff --git a/drivers/iio/Makefile b/drivers/iio/Makefile
index 87e4c43..4008d5a 100644
--- a/drivers/iio/Makefile
+++ b/drivers/iio/Makefile
@@ -25,6 +25,7 @@ obj-y += frequency/
 obj-y += health/
 obj-y += humidity/
 obj-y += imu/
+obj-y += misc/
 obj-y += light/
 obj-y += magnetometer/
 obj-y += orientation/
diff --git a/drivers/iio/misc/Kconfig b/drivers/iio/misc/Kconfig
new file mode 100644
index 0000000..b43a1ed
--- /dev/null
+++ b/drivers/iio/misc/Kconfig
@@ -0,0 +1,17 @@
+#
+# Miscellaneous iio drivers
+#
+# When adding new entries keep the list in alphabetical order
+
+menu "Miscellaneous iio drivers"
+
+config IIO_REGULATOR
+	tristate "IIO regulator driver"
+	depends on REGULATOR
+	help
+	  Say yes here to build support for regulators powering iio devices.
+
+	  To compile this driver as a module, choose M here: the module will
+	  be called iio-regulator.
+
+endmenu
diff --git a/drivers/iio/misc/Makefile b/drivers/iio/misc/Makefile
new file mode 100644
index 0000000..da8f56a
--- /dev/null
+++ b/drivers/iio/misc/Makefile
@@ -0,0 +1,6 @@
+#
+# Makefile for IIO misc drivers
+#
+
+# When adding new entries keep the list in alphabetical order
+obj-$(CONFIG_IIO_REGULATOR) += iio-regulator.o
diff --git a/drivers/iio/misc/iio-regulator.c b/drivers/iio/misc/iio-regulator.c
new file mode 100644
index 0000000..0d61553
--- /dev/null
+++ b/drivers/iio/misc/iio-regulator.c
@@ -0,0 +1,121 @@
+/*
+ * Generic regulator driver for industrial IO.
+ *
+ * Copyright (C) 2016 BayLibre SAS
+ *
+ * Author:
+ *   Bartosz Golaszewski <bgolaszewski@baylibre.com.com>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include <linux/module.h>
+#include <linux/of.h>
+#include <linux/platform_device.h>
+#include <linux/regulator/consumer.h>
+#include <linux/iio/iio.h>
+#include <linux/iio/sysfs.h>
+
+struct iio_regulator_context {
+	struct regulator *regulator;
+};
+
+static ssize_t iio_regulator_enable_show(struct device *dev,
+					 struct device_attribute *attr,
+					 char *buf)
+{
+	struct iio_regulator_context *ctx = iio_priv(dev_to_iio_dev(dev));
+
+	return sprintf(buf, "%d\n", regulator_is_enabled(ctx->regulator));
+}
+
+static ssize_t iio_regulator_enable_store(struct device *dev,
+					  struct device_attribute *attr,
+					  const char *buf, size_t len)
+{
+	struct iio_regulator_context *ctx = iio_priv(dev_to_iio_dev(dev));
+	int ret, enabled;
+	bool val;
+
+	ret = strtobool(buf, &val);
+	if (ret)
+		return ret;
+
+	enabled = regulator_is_enabled(ctx->regulator);
+	if ((val && enabled) || (!val && !enabled))
+		return -EPERM;
+
+	ret = val ? regulator_enable(ctx->regulator) :
+		    regulator_disable(ctx->regulator);
+	if (ret)
+		return ret;
+
+	return len;
+}
+
+static IIO_DEVICE_ATTR(in_enable, 0644,
+		       iio_regulator_enable_show,
+		       iio_regulator_enable_store, 0);
+
+static struct attribute *iio_regulator_attributes[] = {
+	&iio_dev_attr_in_enable.dev_attr.attr,
+	NULL,
+};
+
+static const struct attribute_group iio_regulator_attribute_group = {
+	.attrs = iio_regulator_attributes,
+};
+
+static const struct iio_info iio_regulator_info = {
+	.driver_module = THIS_MODULE,
+	.attrs = &iio_regulator_attribute_group,
+};
+
+static int iio_regulator_probe(struct platform_device *pdev)
+{
+	struct iio_regulator_context *ctx;
+	struct iio_dev *iio_dev;
+	struct device *dev;
+
+	dev = &pdev->dev;
+
+	iio_dev = devm_iio_device_alloc(dev, sizeof(*ctx));
+	if (!iio_dev)
+		return -ENOMEM;
+
+	ctx = iio_priv(iio_dev);
+
+	ctx->regulator = devm_regulator_get(dev, "vcc");
+	if (IS_ERR(ctx->regulator)) {
+		dev_err(dev, "unable to get vcc regulator: %ld\n",
+			PTR_ERR(ctx->regulator));
+		return PTR_ERR(ctx->regulator);
+	}
+
+	iio_dev->dev.parent = dev;
+	iio_dev->dev.of_node = dev->of_node;
+	iio_dev->name = dev->driver->name;
+	iio_dev->info = &iio_regulator_info;
+
+	return devm_iio_device_register(dev, iio_dev);
+}
+
+static const struct of_device_id iio_regulator_of_match[] = {
+	{ .compatible = "iio-regulator", },
+	{ },
+};
+
+static struct platform_driver iio_regulator_platform_driver = {
+	.probe = iio_regulator_probe,
+	.driver = {
+		.name = "iio-regulator",
+		.of_match_table = iio_regulator_of_match,
+	},
+};
+module_platform_driver(iio_regulator_platform_driver);
+
+MODULE_AUTHOR("Bartosz Golaszewski <bgolaszewski@baylibre.com>");
+MODULE_DESCRIPTION("Regulator driver for iio");
+MODULE_LICENSE("GPL v2");
-- 
2.9.3

[toc] | [next] | [standalone]

#1532424

On 11/29/2016 04:22 PM, Bartosz Golaszewski wrote:
[...]
> diff --git a/Documentation/devicetree/bindings/iio/misc/iio-regulator.txt b/Documentation/devicetree/bindings/iio/misc/iio-regulator.txt
> new file mode 100644
> index 0000000..147458f
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/iio/misc/iio-regulator.txt
> @@ -0,0 +1,18 @@
> +Industrial IO regulator device driver
> +-------------------------------------
> +
> +This document describes the bindings for the iio-regulator - a dummy device
> +driver representing a physical regulator within the iio framework.

No bindings for drivers, only for hardware. So this wont work.

[toc] | [prev] | [next] | [standalone]

#1532428

2016-11-29 16:30 GMT+01:00 Lars-Peter Clausen <lars@metafoo.de>:
> On 11/29/2016 04:22 PM, Bartosz Golaszewski wrote:
> [...]
>> diff --git a/Documentation/devicetree/bindings/iio/misc/iio-regulator.txt b/Documentation/devicetree/bindings/iio/misc/iio-regulator.txt
>> new file mode 100644
>> index 0000000..147458f
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/iio/misc/iio-regulator.txt
>> @@ -0,0 +1,18 @@
>> +Industrial IO regulator device driver
>> +-------------------------------------
>> +
>> +This document describes the bindings for the iio-regulator - a dummy device
>> +driver representing a physical regulator within the iio framework.
>
> No bindings for drivers, only for hardware. So this wont work.
>

What about exporting regulator attributes analogous to the one in this
patch from the iio-core when a *-supply property is specified for a
node?

Thanks,
Bartosz

[toc] | [prev] | [next] | [standalone]

#1533184

On 11/29/2016 04:35 PM, Bartosz Golaszewski wrote:
> 2016-11-29 16:30 GMT+01:00 Lars-Peter Clausen <lars@metafoo.de>:
>> On 11/29/2016 04:22 PM, Bartosz Golaszewski wrote:
>> [...]
>>> diff --git a/Documentation/devicetree/bindings/iio/misc/iio-regulator.txt b/Documentation/devicetree/bindings/iio/misc/iio-regulator.txt
>>> new file mode 100644
>>> index 0000000..147458f
>>> --- /dev/null
>>> +++ b/Documentation/devicetree/bindings/iio/misc/iio-regulator.txt
>>> @@ -0,0 +1,18 @@
>>> +Industrial IO regulator device driver
>>> +-------------------------------------
>>> +
>>> +This document describes the bindings for the iio-regulator - a dummy device
>>> +driver representing a physical regulator within the iio framework.
>>
>> No bindings for drivers, only for hardware. So this wont work.
>>
> 
> What about exporting regulator attributes analogous to the one in this
> patch from the iio-core when a *-supply property is specified for a
> node?

The problem with exposing direct control to the regulator is that it allows
to modify the hardware state without the drivers knowledge. If you
power-cycle a device all previous configuration that has been written to the
device is reset. The device driver needs to be aware of this otherwise its
assumed state and the actual device state can divert which will result in
undefined behavior. Also access to the device will fail unexpectedly when
the regulator is turned off. So I think generally the driver should
explicitly control the regulator, power-up when needed, power-down when not.

- Lars

[toc] | [prev] | [next] | [standalone]

#1534011

2016-11-30 11:10 GMT+01:00 Lars-Peter Clausen <lars@metafoo.de>:
> On 11/29/2016 04:35 PM, Bartosz Golaszewski wrote:
>> 2016-11-29 16:30 GMT+01:00 Lars-Peter Clausen <lars@metafoo.de>:
>>> On 11/29/2016 04:22 PM, Bartosz Golaszewski wrote:
>>> [...]
>>>> diff --git a/Documentation/devicetree/bindings/iio/misc/iio-regulator.txt b/Documentation/devicetree/bindings/iio/misc/iio-regulator.txt
>>>> new file mode 100644
>>>> index 0000000..147458f
>>>> --- /dev/null
>>>> +++ b/Documentation/devicetree/bindings/iio/misc/iio-regulator.txt
>>>> @@ -0,0 +1,18 @@
>>>> +Industrial IO regulator device driver
>>>> +-------------------------------------
>>>> +
>>>> +This document describes the bindings for the iio-regulator - a dummy device
>>>> +driver representing a physical regulator within the iio framework.
>>>
>>> No bindings for drivers, only for hardware. So this wont work.
>>>
>>
>> What about exporting regulator attributes analogous to the one in this
>> patch from the iio-core when a *-supply property is specified for a
>> node?
>
> The problem with exposing direct control to the regulator is that it allows
> to modify the hardware state without the drivers knowledge. If you
> power-cycle a device all previous configuration that has been written to the
> device is reset. The device driver needs to be aware of this otherwise its
> assumed state and the actual device state can divert which will result in
> undefined behavior. Also access to the device will fail unexpectedly when
> the regulator is turned off. So I think generally the driver should
> explicitly control the regulator, power-up when needed, power-down when not.
>
> - Lars
>

I missed the fact that - unlike hwmon - the iio version of the ina2xx
driver is not capable of detecting a bad state and re-initializing
itself. But you're right in general of course.

Still, it made me think: what if we implement the suspend/resume
callbacks in struct device_driver to store/resume the state when
power-cycling? The core iio module would then call the suspend
callback before disabling the regulator. We wouldn't need to duplicate
similar code and DT bindings in every iio driver.

Best regards,
Bartosz Golaszewski

[toc] | [prev] | [next] | [standalone]

#1535416

On 30/11/16 10:10, Lars-Peter Clausen wrote:
> On 11/29/2016 04:35 PM, Bartosz Golaszewski wrote:
>> 2016-11-29 16:30 GMT+01:00 Lars-Peter Clausen <lars@metafoo.de>:
>>> On 11/29/2016 04:22 PM, Bartosz Golaszewski wrote:
>>> [...]
>>>> diff --git a/Documentation/devicetree/bindings/iio/misc/iio-regulator.txt b/Documentation/devicetree/bindings/iio/misc/iio-regulator.txt
>>>> new file mode 100644
>>>> index 0000000..147458f
>>>> --- /dev/null
>>>> +++ b/Documentation/devicetree/bindings/iio/misc/iio-regulator.txt
>>>> @@ -0,0 +1,18 @@
>>>> +Industrial IO regulator device driver
>>>> +-------------------------------------
>>>> +
>>>> +This document describes the bindings for the iio-regulator - a dummy device
>>>> +driver representing a physical regulator within the iio framework.
>>>
>>> No bindings for drivers, only for hardware. So this wont work.
>>>
>>
>> What about exporting regulator attributes analogous to the one in this
>> patch from the iio-core when a *-supply property is specified for a
>> node?
> 
> The problem with exposing direct control to the regulator is that it allows
> to modify the hardware state without the drivers knowledge. If you
> power-cycle a device all previous configuration that has been written to the
> device is reset. The device driver needs to be aware of this otherwise its
> assumed state and the actual device state can divert which will result in
> undefined behavior. Also access to the device will fail unexpectedly when
> the regulator is turned off. So I think generally the driver should
> explicitly control the regulator, power-up when needed, power-down when not.
I agree with what Lars has said.

There 'may' be some argument to ultimately have a bridge driver from
regulators to IIO.  That would be for cases where the divide between a regulator
and a DAC is blurred.  However it would still have to play nicely with the
regulator framework and any other devices registered on that regulator.
Ultimately the ideal in that case would then be to describe what the DAC is
actually being used to do but that's a more complex issue!

That doesn't seem to be what you are targeting here.

What it sounds like you need is to have the hardware well enough described that
the standard runtime power management can disable the regulator just fine when
it is not in use.  This may mean improving the power management in the relevant
drivers.

Jonathan

p.s. If ever proposing to do something 'unusual' with a regulator you should
bring in the regulator framework maintainers in the cc list.
> 
> - Lars
> 

[toc] | [prev] | [next] | [standalone]

#1536888

2016-12-03 10:11 GMT+01:00 Jonathan Cameron <jic23@kernel.org>:
> On 30/11/16 10:10, Lars-Peter Clausen wrote:
>> On 11/29/2016 04:35 PM, Bartosz Golaszewski wrote:
>>> 2016-11-29 16:30 GMT+01:00 Lars-Peter Clausen <lars@metafoo.de>:
>>>> On 11/29/2016 04:22 PM, Bartosz Golaszewski wrote:
>>>> [...]
>>>>> diff --git a/Documentation/devicetree/bindings/iio/misc/iio-regulator.txt b/Documentation/devicetree/bindings/iio/misc/iio-regulator.txt
>>>>> new file mode 100644
>>>>> index 0000000..147458f
>>>>> --- /dev/null
>>>>> +++ b/Documentation/devicetree/bindings/iio/misc/iio-regulator.txt
>>>>> @@ -0,0 +1,18 @@
>>>>> +Industrial IO regulator device driver
>>>>> +-------------------------------------
>>>>> +
>>>>> +This document describes the bindings for the iio-regulator - a dummy device
>>>>> +driver representing a physical regulator within the iio framework.
>>>>
>>>> No bindings for drivers, only for hardware. So this wont work.
>>>>
>>>
>>> What about exporting regulator attributes analogous to the one in this
>>> patch from the iio-core when a *-supply property is specified for a
>>> node?
>>
>> The problem with exposing direct control to the regulator is that it allows
>> to modify the hardware state without the drivers knowledge. If you
>> power-cycle a device all previous configuration that has been written to the
>> device is reset. The device driver needs to be aware of this otherwise its
>> assumed state and the actual device state can divert which will result in
>> undefined behavior. Also access to the device will fail unexpectedly when
>> the regulator is turned off. So I think generally the driver should
>> explicitly control the regulator, power-up when needed, power-down when not.
> I agree with what Lars has said.
>
> There 'may' be some argument to ultimately have a bridge driver from
> regulators to IIO.  That would be for cases where the divide between a regulator
> and a DAC is blurred.  However it would still have to play nicely with the
> regulator framework and any other devices registered on that regulator.
> Ultimately the ideal in that case would then be to describe what the DAC is
> actually being used to do but that's a more complex issue!
>
> That doesn't seem to be what you are targeting here.
>
> What it sounds like you need is to have the hardware well enough described that
> the standard runtime power management can disable the regulator just fine when
> it is not in use.  This may mean improving the power management in the relevant
> drivers.
>
> Jonathan
>
> p.s. If ever proposing to do something 'unusual' with a regulator you should
> bring in the regulator framework maintainers in the cc list.
>>
>> - Lars
>>
>

I wrote the initial patch quickly and didn't give it much of a
thought. Now I realized I completely missed the point and managed to
confuse everybody - myself included.

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?

Best regards,
Bartosz Golaszewski

[1] http://baylibre.com/acme/
[2] https://github.com/BayLibre/POWERCI

[toc] | [prev] | [next] | [standalone]

#1539882

On 06/12/16 11:12, Bartosz Golaszewski wrote:
> 2016-12-03 10:11 GMT+01:00 Jonathan Cameron <jic23@kernel.org>:
>> On 30/11/16 10:10, Lars-Peter Clausen wrote:
>>> On 11/29/2016 04:35 PM, Bartosz Golaszewski wrote:
>>>> 2016-11-29 16:30 GMT+01:00 Lars-Peter Clausen <lars@metafoo.de>:
>>>>> On 11/29/2016 04:22 PM, Bartosz Golaszewski wrote:
>>>>> [...]
>>>>>> diff --git a/Documentation/devicetree/bindings/iio/misc/iio-regulator.txt b/Documentation/devicetree/bindings/iio/misc/iio-regulator.txt
>>>>>> new file mode 100644
>>>>>> index 0000000..147458f
>>>>>> --- /dev/null
>>>>>> +++ b/Documentation/devicetree/bindings/iio/misc/iio-regulator.txt
>>>>>> @@ -0,0 +1,18 @@
>>>>>> +Industrial IO regulator device driver
>>>>>> +-------------------------------------
>>>>>> +
>>>>>> +This document describes the bindings for the iio-regulator - a dummy device
>>>>>> +driver representing a physical regulator within the iio framework.
>>>>>
>>>>> No bindings for drivers, only for hardware. So this wont work.
>>>>>
>>>>
>>>> What about exporting regulator attributes analogous to the one in this
>>>> patch from the iio-core when a *-supply property is specified for a
>>>> node?
>>>
>>> The problem with exposing direct control to the regulator is that it allows
>>> to modify the hardware state without the drivers knowledge. If you
>>> power-cycle a device all previous configuration that has been written to the
>>> device is reset. The device driver needs to be aware of this otherwise its
>>> assumed state and the actual device state can divert which will result in
>>> undefined behavior. Also access to the device will fail unexpectedly when
>>> the regulator is turned off. So I think generally the driver should
>>> explicitly control the regulator, power-up when needed, power-down when not.
>> I agree with what Lars has said.
>>
>> There 'may' be some argument to ultimately have a bridge driver from
>> regulators to IIO.  That would be for cases where the divide between a regulator
>> and a DAC is blurred.  However it would still have to play nicely with the
>> regulator framework and any other devices registered on that regulator.
>> Ultimately the ideal in that case would then be to describe what the DAC is
>> actually being used to do but that's a more complex issue!
>>
>> That doesn't seem to be what you are targeting here.
>>
>> What it sounds like you need is to have the hardware well enough described that
>> the standard runtime power management can disable the regulator just fine when
>> it is not in use.  This may mean improving the power management in the relevant
>> drivers.
>>
>> Jonathan
>>
>> p.s. If ever proposing to do something 'unusual' with a regulator you should
>> bring in the regulator framework maintainers in the cc list.
>>>
>>> - Lars
>>>
>>
> 
> I wrote the initial patch quickly and didn't give it much of a
> thought. Now I realized I completely missed the point and managed to
> confuse everybody - myself included.
> 
> 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?
Definitely doesn't fit inside standard scope of IIO - though I can see
why you were thinking along these lines.

Mark Brown, any thoughts?

Effectively we are are looking at something that (in general form) might
be the equivalent of controlling a lab bench supply... So regulators
at the edge of the known world, with no visibility of what lies beyond.
> 
> Best regards,
> Bartosz Golaszewski
> 
> [1] http://baylibre.com/acme/
> [2] https://github.com/BayLibre/POWERCI
> --
> To unsubscribe from this list: send the line "unsubscribe linux-iio" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web