-
Notifications
You must be signed in to change notification settings - Fork 215
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Support cpufreq for t6031 #367
Conversation
This seems to work, and matches the info i can find. Signed-off-by: Daniel Berlin <[email protected]>
@@ -262,6 +280,8 @@ const struct feat_t *cpufreq_get_features(void) | |||
case T6021: | |||
case T6022: | |||
return t6020_features; | |||
case T6031: | |||
return t6031_features; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
same as T6021/T6022?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
For now, yes. I assume it will end up slightly different in the end, which is why i didn't reuse the struct.
I'm not comfortable merging this until we at least confirm via macOS HV trace that it does the same thing. Getting this wrong has bit us hard in the past (M2 core lockups on deep sleep) and it's a huge nightmare to debug. We're going to need the HV for a lot of other stuff on M3 anyway, so there isn't much point in bringing up Linux cpufreq until that works. |
That's fine.
…On Sun, Dec 3, 2023 at 3:41 AM Hector Martin ***@***.***> wrote:
I'm not comfortable merging this until we at least confirm via macOS HV
trace that it does the same thing. Getting this wrong has bit us *hard*
in the past (M2 core lockups on deep sleep).
—
Reply to this email directly, view it on GitHub
<#367 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/AACPI2Z57JWAUTG2J2KVH7DYHQ3LLAVCNFSM6AAAAABACCXDN2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQMZXGQYTAOJXGY>
.
You are receiving this because you authored the thread.Message ID:
***@***.***>
|
Note: I traced enough of the kext now to verify that this is at least as correct as the current other code :) But I still agree we should basically leave it disabled until we have lots of other stuff working, just to eliminate variables. |
4f95305
to
95d67cf
Compare
This seems to work, and matches the info i can find.
Signed-off-by: Daniel Berlin [email protected]