On 08.07.2017 15:43, Andrey Korolyov wrote:
From git logs it looks like configuring the clockgen was needed for the x60/t60 port for deeper c-states to work. I'd try to dump the clockgen configuration on smbus with block operations ('i2cdump #smbus 0x69 s') and configure it using block write operations either in romstage (look at thinkpad x201 romstage.c) or in ramstage like is done for the x60 (might need some tweaking).
I see, thanks. Previously write to i2c-0/0x69 has been stuck at romstage, so I kicked it out without looking at the log and therefore not getting reasons why is was there at first place, Now it is obvious that C3 is not working correctly without fixing up clock generator. Previously, also, I blamed incorrect _CST package generation from copy-paste from T60 for a moment - state descriptions has been enumerated as 0x1/0x2/0x2 while vendor BIOS has sequentially enumerated descriptions, still wondering what was the reason to do so.
I'd expect the clockgen to be the culprit too. But this C-state number could be a typo and also be the reason for your trouble (though, I'd wonder why it works on the T60). This number is used to map ACPI C-state semantics to the states presented in _CST. ACPI knows three C states and those rarely match the actual C states of the hardware. Basically, a 3 instead of a 2 tells ACPI to flush caches before entering this state. Also, ACPI C3 is to be avoided if bus-master activity is expected.
Nico
I'd expect the clockgen to be the culprit too. But this C-state number could be a typo and also be the reason for your trouble (though, I'd wonder why it works on the T60). This number is used to map ACPI C-state semantics to the states presented in _CST. ACPI knows three C states and those rarely match the actual C states of the hardware. Basically, a 3 instead of a 2 tells ACPI to flush caches before entering this state. Also, ACPI C3 is to be avoided if bus-master activity is expected.
It turned out to be again very simple thing: by some reason yet to be found, write within ics954309_init could succeed only for first eight data addresses on this board, it would ultimately return nothing for higher data addresses within 0x69 so boot which is trying to write smbus-type-width block will hang as it has been reported earlier. Magically, cutting chip initialization in this crude way appears to work against C3 behavour. I would take a look on the exact PLL chip model upon next disassembly and also would dump i2c data with vendor BIOS to get this properly (vendor BIOS does prevent access to clock generator bits, as well to SPD data, just to mention).
Forgot to mention that I`ve of course tried straightforward _CST fix before, with no success at all. Someone with working T60/X60 could try to check 'fixed' cst_entries ordering in mainboard.c and post the results, right now all mine X60s are far away from the working state.
-
Andrey Korolyov -
Nico Huber