Re: i801_smbus: no runtime pm since a9c8088c7988 ("i2c: i801: Don't restore config registers on runtime PM")

Heiner Kallweit
2021-05-21T14:58:40Z

On 21.05.2021 16:09, Jarkko Nikula wrote:
> Hi
>
> On 5/21/21 4:26 PM, Heiner Kallweit wrote:
>> On 21.05.2021 10:19, Heiner Kallweit wrote:
>>> Before the referenced commit we used i801_suspend and i801_resume also as
>>> runtime pm callbacks. That's no longer the case, and at least on my
>>> platform the SMBus controller PCI device doesn't support PM. Therefore
>>> PCI core can't do what it would do for other devices: bring them to D3hot
>>> or D3cold.
>>> Having said that effectively there is no runtime pm any longer. Not sure
>>> whether there are SMBus controller versions where the PCI device supports
>>> PM.
>>>
> About commit a9c8088c7988 which removes the runtime PM callbacks: It indeed had a runtime PM regression but is fixed by commit c5eb1190074c ("PCI / PM: Allow runtime PM without callback functions").
>
>>> So my questions are:
>>> Does the SMBus controller support any power-saving modes?
>>> i801_suspend() just sets SMBHSTCFG to the value it had when the driver
>>> was loaded. Means if SMBHSTCFG_HST_EN was enabled already, we won't clear
>>> it. And this bit may have an impact on some internal PLL's (just guessing).
>>> If there's no good-enough power-saving option, then runtime pm support
>>> could be removed completely, or?
>>>
>>>
>>> 00:1f.4 SMBus: Intel Corporation Cannon Lake PCH SMBus Controller (rev 10)
>>>          DeviceName: Onboard - Other
>>>          Subsystem: ASUSTeK Computer Inc. Device 8694
>>>          Flags: medium devsel, IRQ 16
>>>          Memory at a1316000 (64-bit, non-prefetchable) [size=256]
>>>          I/O ports at efa0 [size=32]
>>>          Kernel driver in use: i801_smbus
>>>          Kernel modules: i2c_i801
>>>
> It's not entirely clear to me either is it HW or FW specific what platform supports PCI PM for the SMBus controller. But usually what I've seen Core based platforms don't have it while *some* Atom based does have.
>
> I saw your message earlier today and was looking at from our lab machines which have it. I'm quite sure but not absolutely one Apollo Lake one had it but today didn't see it. Need to check with colleagues did they change BIOS etc. Or I just remember wrong :-)
>
> Fortunately one Braswell based have the PM. Here's the lspic output from kernel 5.13.0-rc2:
>
> # lspci -s 00:1f.3 -vv
> 00:1f.3 SMBus: Intel Corporation Atom/Celeron/Pentium Processor x5-E8000/J3xxx/N3xxx SMBus Controller (rev 31)
>     Subsystem: Intel Corporation Atom/Celeron/Pentium Processor x5-E8000/J3xxx/N3xxx SMBus Controller
>     Control: I/O+ Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
>     Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
>     Interrupt: pin B routed to IRQ 18
>     Region 0: Memory at 9191c000 (32-bit, non-prefetchable) [size=32]
>     Region 4: I/O ports at 2040 [size=32]
>     Capabilities: [50] Power Management version 3
>         Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
>         Status: D3 NoSoftRst+ PME-Enable- DSel=0 DScale=0 PME-
>     Kernel driver in use: i801_smbus
>     Kernel modules: i2c_i801
>
> So the PCI device needs to have Power Management capability and here the current status is SMBus controller is suspended to D3 state.
>
Thanks for the quick reply. Good to know there are actually some SMBus controllers in the family that
support PCI PM. Theoretically we could add PCI PM support to the feature bitmap and enable runtime pm
based on the feature, but this may not be worth the effort (as it doesn't really hurt on other systems).

> Jarkko

Heiner