Hi Mark, I think we settle with this scheme you choose, so the following is just some hints for the future. On Sun, May 9, 2021 at 11:46 AM Mark Kettenis <mark.kettenis@xxxxxxxxx> wrote: > Right. So far it seems we don't need to set the electrical config on > any of the pins and I don't think we've identified any bits in the > register that change the electrical configuration. Although there are > some hints in the Apple device tree that there are pins that need some > additional configuration. But I also see some evidence that the Apple > firmware on these devices already sets up most of the pins for us. This is something I think you want to look closer at soon. It will *probably* be necessary to obtain optimal power management for the devices, but I am not sure. What operating systems (especially Android devices under Linux) tend to do is to reconfigure pins at runtime in order to conserve power. When the device goes to deep sleep just waiting for an external interrupt (such as opening the lid on a laptop or pressing the power button on a phone) the OS tend to reconfigure the pins into a low power state for the duration of the sleep. A typical example is to set a bunch of lines as "floating" (tristate) in pin control terminology "bias-high-impedance". In some cases pins may be connected to ground depending on use case, but in each case this is done to avoid leak currents when sleeping. I don't know how noticeable impact this will have on standby times, but the lower micron silicon technology, the bigger the impact. If possible I'd recommend that you try to intercept what MacOS is doing with these registers when the system goes in/out of sleep mode. I think it could be key to some power savings you would otherwise miss. These two modes are standardized in pin control terms as "default" and "sleep" and each affected device driver need to actively put the pin control state to "sleep" when the device is going to sleep, so the philosophy is entirely distributed, in difference from some more sledgehammer-type OS approaches where the OS is just slamming a number of values into the pin registers at sleep (suspend) time. The upside to doing this fine-grained and per device is that the sleep modes can in best case be used at runtime to e.g. save power on an unused USB port that isn't plugged to anything (I don't know if this is a good example). In Linux we have the runtime PM concept to deal with this and there are some drivers actively saving power in this way. Yours, Linus Walleij