Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

power rail management in low-power devices #17830

Closed
pabigot opened this issue Jul 28, 2019 · 5 comments
Closed

power rail management in low-power devices #17830

pabigot opened this issue Jul 28, 2019 · 5 comments
Assignees
Labels
area: Power Management Enhancement Changes/Updates/Additions to existing features

Comments

@pabigot
Copy link
Collaborator

pabigot commented Jul 28, 2019

The following situation demonstrates an apparent functionality gap for low power devices in in-tree target. (My use case is out-of-tree.)

The Nordic Thingy:52 (nrf52_pca20020) has two GPIO-controlled power rails. The first is controlled by the SOC GPIO. On that rail is an SX1509B GPIO controller and a variety of other peripherals. The second rail, which powers the CCS811, is controlled by a pin on that SX1509B.

I started to create a regulator-gpio infrastructure to provide runtime control of power rails with power management support to support low power devices, where the rail is enabled only when something it powers is needed.

A potential device-tree excerpt is:

vdd-rail: vdd-rail {
  compatible = "regulator-gpio";
  label = "vdd-rail";
  switch-gpios = <&gpio0 30 0>;
  boot-on;
};

ccs-vdd-rail: ccs-vdd-rail {
  compatible = "regulator-gpio";
  label = "ccs-vdd-rail";
  switch-gpios = <&sx1509b 10 0>;
};

&i2c0 {
  sx1509b: sx1509b@3e {
    compatible = "semtech,sx1509b";
    rail = &vdd-rail;
    /* ... */
  };

  hts221: hts221@5f {
    compatible = "st,hts221";
    rail = &vdd-rail;
    /* ... */
  };

  ccs811: ccs811@5a {
    compatible = "ams,ccs811";
    rail = &ccs-vdd-rail;
    /* ... */
  }
  /* ... */
}

In a standard devicetree infrastructure I would expect an attempt to use the ccs811 device to follow a dependency to the parent bus sx1509b, which would then follow a dependency to vdd-rail, power it up if necessary and register an active user, then initialize the sx1509b and power up ccs-vdd-rail, and then proceed to initialize the ccs811.

I can't figure out any way to make this work in Zephyr without hard-coding dependencies in driver implementations (like SX1509B and CCS811) that are supposed to be target-independent.

This works today only because nrf52_pca20020 defines two separate init priorities that are associated with unique devices, and unconditionally powers up both rails during startup. Which makes this platform not very usable as a low power device.

efr32mg_sltb004a has similar per-device rails, though AFAICT Zephyr doesn't have infrastructure that enables any of its sensors.

It seems that all the power management work is the responsibility of the application, when it should be a simple matter of noting the dependency in the devicetree and allowing device power management to take care of things.

Am I missing something, or is there a huge gap in support for low-power devices here?

@pabigot pabigot added the Enhancement Changes/Updates/Additions to existing features label Jul 28, 2019
@aescolar
Copy link
Member

CC @carlescufi

@Snevzor
Copy link
Contributor

Snevzor commented Aug 9, 2021

@pabigot did you find a suitable method?

Before finding this issue I've also looked at the thingy52_nrd52832 board files. It indeed looks like board.c is a work-around so that the power rails are initialized in the right order at boot time only.

I'm having a low-power device with a rather high-power sensor that needs to be powered on at a fixed interval.
The sensor is attached to a load switch which in turn is controlled by a GPIO.

Edit: looking at #22941 it appears lots of stuff is missing to make this happen?

@pabigot
Copy link
Collaborator Author

pabigot commented Aug 9, 2021

@Snevzor #24416 (comment) has a summary related to that old plan. There was related content in the mass of work around #29644, but as of last April when I stopped working on Zephyr there was no plan to actually manage instance-specific device initialization order based on dependencies or code annotations.

@Snevzor
Copy link
Contributor

Snevzor commented Aug 10, 2021

Thanks for the fast response @pabigot.
It's a bit weird stuff like this is missing and me finding out quite late.
I've read your latest blog post. It's a pity you had to leave.

I'll try with the gpio as regulator, controlled from the application and I'll need to find a way for the driver to re-init.

@ceolin
Copy link
Member

ceolin commented Oct 28, 2021

Duplicated #37793

@ceolin ceolin closed this as completed Oct 28, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area: Power Management Enhancement Changes/Updates/Additions to existing features
Projects
None yet
Development

No branches or pull requests

6 participants