Hi Lukas, On Fri, Mar 29, 2024 at 05:41:16AM +0100, Lukas Wunner wrote: > On Thu, Mar 28, 2024 at 02:42:01PM -0600, Alex Williamson wrote: > > On Wed, 27 Mar 2024 10:01:19 -0500 Bjorn Helgaas <helgaas@xxxxxxxxxx> wrote: > > The original patch proposed for this gave me the impression that this > > was a device used on various old Mac systems, not likely applicable to > > a general purpose plug-in card. > > I'm still using one of those "old Mac systems" as my daily driver. > > Just checked the ACPI tables and there's an FPEN method below the > FRWR device which toggles GPIO 48 on the PCH. Checked the schematics > as well and GPIO 48 is marked FW_PWR_EN. The GPIO controls load > switches which cut power to the FW643 chip when nothing is connected. > > Also, FW_PWR_EN feeds into an SLG4AP016V chip where it seems to > internally gate FW_CLKREQ_L. > > I'm guessing the driver may need to call the FPEN ACPI method after > issuing a SBR to force the chip on (or perhaps first off, then on) > and thereby re-enable Clock Request. > > It's a pity the ohci.c driver doesn't seem to support runtime PM. > That would allow cutting power to the chip when nothing is connected > and thus increase battery life. The ACPI tables indicate that the > platform sends a notification when something is plugged in, so all > the necessary ingredients are there but we're not taking advantage > of them. > > Thanks, > > Lukas Yup. In both PCI drivers and unit drivers belonging to Linux FireWire subsystem, any type of runtime PM is not supported. If I integrate 1394 OHCI driver, I should implement all of the above in any callback of runtime PM, or the part of the above is already supported by any driver in parent PCI layer? Thanks Takashi Sakamoto
