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
