Contribute
Register

a few remaining issues/clarifications to solve on L440

Status
Not open for further replies.
Well as far as software goes i don't actually remember how many of them i tried:
- AIDA64
- Notebook Fan Control
- HWMonitor
- Speedfan
- HWinfo, etc.

Yeah, those are ones I would try...

Thats why i asked on previous post if i can dump that formula/code from a Lenovo T440P.

Nothing to dump if it doesn't exist in ACPI...

Very similar laptop, same fan, same cpu models, it's just that the acpi has the offset corresponding to FAN RPM reading is a 16-bit while on my L440 ACPI it's a 8-bit.

Your 8-bit register is probably something other than RPM...
Did you try reading the RPM from the same 16-bit offset that is used on the other models, but with your laptop instead?

Also here is the ACPI of my Lenovo B570e if you can land an eye and see if it is possible to get something from it , in PTIDEVC SSDT there is some code for fan speed but i don't understand if there is something we can get from it or not.

You can see the code in OSDD that populates the return package:
Code:
                If (\ECON)
                {
                    Store (\_SB.PCI0.LPCB.H_EC.CFSP, Index (OSDV, Zero))
                    Store (\_SB.PCI0.LPCB.H_EC.CPUE, Index (OSDV, One))
                }

And you can see the correlation of package index 0 and index 1:
Code:
            Name (OSDL, Package (0x06)
            {
                Zero, 
                "CPU Fan Speed", 
                "RPM", 
                Zero, 
                "CPU energy", 
                "RAW"
            })

So, CFSP likely stores the CPU fan RPM, and CPUE stores something related to "CPU Energy" (could be mW).
 
Yeah, those are ones I would try...
None of these shows fan RPM
Your 8-bit register is probably something other than RPM...
Did you try reading the RPM from the same 16-bit offset that is used on the other models, but with your laptop instead?
Great idea, will give it a shot, most propably the same offset exist on my acpi but without a name and value so I will try to add that offset as patched and add b1b2 method and see if it shows any rpm reading on it.
So, CFSP likely stores the CPU fan RPM, and CPUE stores something related to "CPU Energy" (could be mW).
Ok thanks but what do i do now with it.
If im supposed to look for CFSP on DSDT I didn’t find a thing with CFSP.
Is there another way/place that i should look for.
 
Ok thanks but what do i do now with it.
If im supposed to look for CFSP on DSDT I didn’t find a thing with CFSP.
Is there another way/place that i should look for.

Without CFSP being defined somewhere, it is just buggy PTID code (which is quite typical, unfortunately).
 
Without CFSP being defined somewhere, it is just buggy PTID code (which is quite typical, unfortunately).
So if this method that you mentioned:
Your 8-bit register is probably something other than RPM...
Did you try reading the RPM from the same 16-bit offset that is used on the other models, but with your laptop instead?

Doesn’t work then i guess i will have no other way but to find that device to read fan rpm, which im sure one of the guys or friends that have laptop service shops do have one.
I will have to write down rpm reading on 1st speed and 2nd speed so i have an idea how much the rpm increase is from speed to speed and also measure 100% speed to know which is the max rpm.

Should those data be enough for us to build a calculation/formula/code to read fan RPM ?
 
Should those data be enough for us to build a calculation/formula/code to read fan RPM ?

With enough samples, you can write code that approximates it well enough.
 
With enough samples, you can write code that approximates it well enough.
Ok, after i gather the data i will write a post with the progress and request some help on writing the formula.

BTW i wanted to share this with you:
The PCIE Card Reader kext got an update and added Power Management Support from a Fork of Sinetek-rtsx
Here is the link:
https://github.com/syscl/Sinetek-rtsx/commit/cc06a2d555a2c729c5b78d15f24ac16f0b27a855

Will build & test it tonight and see if it works correctly now.

I think we finally have a solution for PCI-E Card Readers,it’s time for people to add their card IDs so he can add support for them.
 
BTW i wanted to share this with you:
The PCIE Card Reader kext got an update and added Power Management Support from a Fork of Sinetek-rtsx
Here is the link:
https://github.com/syscl/Sinetek-rtsx/commit/cc06a2d555a2c729c5b78d15f24ac16f0b27a855

Will build & test it tonight and see if it works correctly now.

I think we finally have a solution for PCI-E Card Readers,it’s time for people to add their card IDs so he can add support for them.

I think I have that card reader kext linked from the FAQ... for those that wish to try it.
 
I think I have that card reader kext linked from the FAQ... for those that wish to try it.
Ok thanks, it's been a while since i didn't check the FAQ.

The recent changes that you did on Clover laptop config repo, i see that you renamed the SSDTs so patchmatic can extract them with names.

What i understood from that change is that the SSDT Table ID must be without special characters (only numbers & letters) and must have _ as first character like "_USB";"_KBD";"_L440", etc.
Are these the correct requirements for patchmatic to extract them with names ?
 
The recent changes that you did on Clover laptop config repo, i see that you renamed the SSDTs so patchmatic can extract them with names.

Yes... but changes not implemented yet in patchmatic... when I have time, will do that part.

What i understood from that change is that the SSDT Table ID must be without special characters (only numbers & letters) and must have _ as first character like "_USB";"_KBD";"_L440", etc.

Yes.
 
Yes... but changes not implemented yet in patchmatic... when I have time, will do that part.
Yes, i expected that since i didn't see patchmatic updated yet.
Excellent, i already named all the table IDs like that today since im doing a fresh set of files for Thinkpad laptops that i patched & writing/updating the guides.
So the hotpatch SSDTs will be already up to date for this change when it becomes available after your patchmatic update.

This will help a lot on speeding up the process of problem identification instead of going into 10+ SSDTs = opening them one by one till you find the one you are looking for.
 
Status
Not open for further replies.
Back
Top