Hi Jade，
I think you have some misunderstand, our set clkreg register is not go directly to control CLKREQ# after setting.... Our device keep CLKREQ# low until enter ASPM, so the system let our device to ASPM mode then we release this CLKREQ# pin
In the past if the BIOS(config space) not set L1-substate our driver will keep
drive low CLKREQ# when HOST want to enter power saving state that make whole system not enter the power saving state.
But this patch we release the CLKREQ# to HOST, make whole system can
enter power saving state success when the HOST want to enter the power saving state, but I don't know why this system can not wake out success from power saving state"
This is a PCIE CLKREQ# design problem on those platform, the pcie spec
allow device release the CLKREQ# to HOST, this patch only do this....
I spent some time debugging today but I am not a PCIe expert. I think
that the card reader is actually violating the PCIe spec by not forcing
CLKREQ# low on systems that don't support ASPM, as appears to be done
(accidentally?) by the regressing driver change.
The kernel logs on the affected system states the following:
[ 0.142326] ACPI FADT declares the system doesn't support PCIe ASPM, so disable it
The PCIe 3.0 spec states (in the description of the Link Control
Register), regarding enabling clock power management:
Enable Clock Power Management – Applicable only for Upstream Ports and
with form factors that support a “Clock Request” (CLKREQ#) mechanism, this bit operates as follows:
0b Clock power management is disabled and device must hold CLKREQ#
signal low.
1b When this bit is Set, the device is permitted to use CLKREQ# signal to
power manage Link clock
according to protocol defined in appropriate form factor specification.
My reading of this is that on this system which does not support ASPM
and therefore also does not support clock PM, the driver must have the
device hold the line low, but I may be wrong.
It's still unclear to me based on studying the schematic of the laptop
and the PCH datasheet why the one PCIe port is able to break the other
one like it does. The CLKREQ# lines are simply connected directly to the
SRCCLKREQ# lines of the PCH, plus a 10k pull-up to 3v3, which seems
entirely reasonable; any breakage surely would be some software/firmware level
misconfiguration.
Jade