Thanks for the detailed report - very helpful and very much appreciated. I'll need to reproduce this but I don't have one of these platforms myself so will need to ask a colleague for help.
It looks like this line is causing problems on this platform:
funcmode = (output >> DYTC_GET_FUNCTION_BIT) & 0xF;
Normally that should return PSC mode (in this case - unless you have AMT mode, which you don't on that gen platform).
But it's saying it is in standard mode instead....which is peculiar. The FW is doing something non-standard to other platforms.
Do you still get the warning when:
- you're in performance or low-power modes?
- you're in lap mode?
As a quick test could you try adding:
/* Check if we are PSC mode, or have AMT enabled */
funcmode = (output >> DYTC_GET_FUNCTION_BIT) & 0xF;
+if (funcmode == DYTC_FUNCTION_STD)
+ funcmode = DYTC_FUNCTION_PSC;
To see if it behaves correctly please?
I'll have to check with the FW team and find out why this change in behaviour...I suspect I need to do a kernel patch to better handle this AMT case though.
Hi,
Can I confirm this is on a T14s G3 AMD platform?
Thanks for the detailed report - very helpful and very much appreciated. I'll need to reproduce this but I don't have one of these platforms myself so will need to ask a colleague for help.
It looks like this line is causing problems on this platform: FUNCTION_ BIT) & 0xF;
funcmode = (output >> DYTC_GET_
Normally that should return PSC mode (in this case - unless you have AMT mode, which you don't on that gen platform).
But it's saying it is in standard mode instead....which is peculiar. The FW is doing something non-standard to other platforms.
Do you still get the warning when:
- you're in performance or low-power modes?
- you're in lap mode?
As a quick test could you try adding:
/* Check if we are PSC mode, or have AMT enabled */ FUNCTION_ BIT) & 0xF;
funcmode = (output >> DYTC_GET_
+if (funcmode == DYTC_FUNCTION_STD)
+ funcmode = DYTC_FUNCTION_PSC;
To see if it behaves correctly please?
I'll have to check with the FW team and find out why this change in behaviour...I suspect I need to do a kernel patch to better handle this AMT case though.
Mark