Message-ID: <2615501d-7569-41cb-7039-46e690689f1f@marcan.st>
Date:   Tue, 3 May 2022 12:20:48 +0900
From:   Hector Martin <marcan@...can.st>
To:     Rob Herring <robh@...nel.org>
Cc:     Marc Zyngier <maz@...nel.org>,
        Lorenzo Pieralisi <lorenzo.pieralisi@....com>,
        Krzysztof Wilczyński <kw@...ux.com>,
        Bjorn Helgaas <bhelgaas@...gle.com>,
        Alyssa Rosenzweig <alyssa@...enzweig.io>,
        Sven Peter <sven@...npeter.dev>,
        PCI <linux-pci@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 3/3] PCI: apple: Add support for optional PWREN GPIO

On 03/05/2022 00.32, Hector Martin wrote:
> On 03/05/2022 00.14, Rob Herring wrote:
>> On Mon, May 2, 2022 at 4:39 AM Hector Martin <marcan@...can.st> wrote:
>>>
>>> WiFi and SD card devices on M1 Macs have a separate power enable GPIO.
>>> Add support for this to the PCIe controller. This is modeled after how
>>> pcie-fu740 does it.
>>
>> It did, but it's not ideal really. The problem is the GPIO is really
>> associated with the device (WiFi/SD) rather than the PCI host and
>> therefore should be part of a WiFi or SD node. You probably don't have
>> one (yet), but I would suspect that SD will need one for all the
>> standard MMC/SD DT properties. The secondary issue is we'll end up
>> adding more power sequencing properties to control ordering and timing
>> for different devices. The exception here is standard PCI slot
>> properties like perst#, clkreq, and standard voltage rails can go in
>> the host bridge (and for new bindings, those should really be in the
>> root port node). For a complicated example, see Hikey960 or 970.
>>
>> Of course with power control related properties there's a chicken or
>> egg issue that the PCI device is not discoverable until the device is
>> powered on. This issue comes up over and over with various hacky
>> solutions in the bindings. The PCI subsystem needs to solve this. My
>> suggestion is that if the firmware says there is a device on the bus
>> and it wasn't probed, then we should force probing (or add a pre-probe
>> hook for drivers). That is what MDIO bus does for example.
>>
> 
> I agree with the premise. Right now macOS does not actually power down
> these devices as far as I know (except maybe sleep mode? not sure what
> goes on then yet), but I think the hardware actually has an SD card
> detect GPIO hookup that would allow us to entirely power down the SD
> controller when no card is inserted. That would obviously be ideal.
> 
> FWIW, we do have the device nodes downstream [1]. I did in fact have to
> add the SD one for the CD/WP inversion flags (and had to add driver
> support for that too).
> 
> That said, as for how to make this happen in the PCI subsystem
> properly... I think I'll defer to the maintainers' opinion there before
> trying to hack something up ;)
> 
> Meanwhile, I guess I better get PCIe hotplug working, since doing it in
> the driver isn't going to work without that first...
> 
> [1]
> https://github.com/AsahiLinux/linux/blob/bits/000-devicetree/arch/arm64/boot/dts/apple/t600x-j314-j316.dtsi#L222

Thinking about this some more, I think it still makes sense to have the
power enable GPIO in the PCI root port node. A generic power enable GPIO
still makes sense there (think "slot power"). The PCI core could handle
it properly by default, including turning it on prior to initial probing
and shutting it down when the device should go into whatever the PCI
core's idea of D3cold is. AIUI this already happens on some platforms
via firmware, right? Since D3cold is supposed to be a state where the
device receives no power after all.

Obviously this can't handle funky power sequencing requirements, but we
don't have any of those here and we don't know if we ever will (at least
Apple seems to be a fan of throwing little CPLDs on their boards for
fine grained power sequencing, driven by a single IO). If we do, then
that would be the time to have GPIOs in the device node.

In addition, sometimes a single power enable is shared between multiple
functions of one device. This is the case with WiFi/BT, which is a combo
chip with two functions. Coordinating GPIO usage between both drivers
would be problematic if they both try to own it.

The individual device drivers still need to have some kind of API to be
able to put devices into a low-power state. For example, the WiFi driver
could outright power down the device when it is wholly unused and the
interface is down (same for BT, and the PCI core should only put the
slot GPIO into powerdown if both functions say they should be off).
Similarly, the SD driver needs to support an external SD detect GPIO,
and have a mode where it tells the PCI core to shut down the device when
no SD is inserted, and power it back up on insertion. This all allows
the devices to behave a users might expect, with the device nodes
existing and the PCI devices "visible" even when they are powered down
behind the scenes, until they are needed. AIUI this is already how e.g.
hybrid graphics power management works, where power is outright yanked
from the secondary card when it is not needed even though it is still
visible from the userspace point of view (and it is automatically
powered and reinitialized on use).

I'm not super familiar with PCI device power states (making brcmfmac
sleep work properly on these platforms is on my TODO list...) so I'd
love to get some feedback from the PCI folks on what they think about
this whole issue.

-- 
Hector Martin (marcan@...can.st)
Public Key: https://mrcn.st/pub

Powered by blists - more mailing lists