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

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

[Heiner Kallweit]

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.

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

Heiner

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

[Heiner Kallweit]

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.
> 
> 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
> 
> Heiner
> 
+Jarkko as author of the change that added runtime pm

The commit message of the original change says:
"those platforms that support PM for i801 device"
Which platforms are this? Independent of the i801 generation I didn't see
any SMBus host controller supporting the PCI Power Management capability
yet.

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

[Jarkko Nikula]

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.

Jarkko

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

[Heiner Kallweit]

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