Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
MIME-Version: 1.0
References: <20210508142000.85116-1-kettenis@openbsd.org> <20210508142000.85116-2-kettenis@openbsd.org>
 <CACRpkdbexpwu9hDWFYe38-+issVw051YfJ-_hatZVmWzkh4M+w@mail.gmail.com> <c1bd67fcc0390275@bloch.sibelius.xs4all.nl>
In-Reply-To: <c1bd67fcc0390275@bloch.sibelius.xs4all.nl>
From:   Linus Walleij <linus.walleij@linaro.org>
Date:   Sun, 9 May 2021 12:49:33 +0200
Message-ID: <CACRpkdZYD3Nq7ZmdXsk_j0CAktvx6Sbqga5B1wbwtL-5T_=vkQ@mail.gmail.com>
Subject: Re: [PATCH 1/2] dt-bindings: pinctrl: Add DT bindings for apple,pinctrl
To:     Mark Kettenis <mark.kettenis@xs4all.nl>
Cc:     kettenis@openbsd.org,
        "open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" 
        <devicetree@vger.kernel.org>, Hector Martin <marcan@marcan.st>,
        Rob Herring <robh+dt@kernel.org>,
        Linux ARM <linux-arm-kernel@lists.infradead.org>,
        "open list:GPIO SUBSYSTEM" <linux-gpio@vger.kernel.org>,
        linux-kernel <linux-kernel@vger.kernel.org>
Content-Type: text/plain; charset="UTF-8"
Precedence: bulk

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@xs4all.nl> 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