Possible bugs in PowerMac7_2_PlatformPlugin
Possible bugs in PowerMac7_2_PlatformPlugin
- Subject: Possible bugs in PowerMac7_2_PlatformPlugin
- From: Benjamin Herrenschmidt <email@hidden>
- Date: Fri, 15 Oct 2004 17:32:28 +1000
Hi !
While going through the platform plugin mecanism, more specifically, the
thermal management for the various machine types, I noticed a couple of
things that may be bugs (Darwin 7.5 base)
So there are 4 configs. But what the datas in the XML show seem to be
different to what the device-tree & probeConfig() seem to show.
Here is what can be deduced from the XML:
0 is obviously uniproc, then we have 3 configs for dual CPU machines.
1 and 3 uses the "old style" fan control (one instance of
PowerMac7_2_CPUFanCtrlLoop for each CPU, only 2 fans driven by each of
them). The difference between them seem to related to the PID factors
and min fan values for the U3/backside loop, possibly a U3 vs. U3H
distinction (1 beeing U3 and 3 beeing U3H)
While 2 uses the "new style" fan control PowerMac7_3_CPUCoolingCtrlLoop
with 6 controls, that is 2 fans per CPU plus what seem to be the 2 pumps
according to the device-tree of a Dual 2.5Ghz.
That is ok so far. So it seem from the above that 0 is uniproc, 1 and 3
are "old style" (no cpu liquid cooling, that is no pumps control)
machines while 2 has the CPU cooling pumps (the 2 additional controls
mapping FCU fan rpm0 & 1).
so now, if we look at probeConfig(), what do we see:
- In the case where something is missing from the device-tree, this is
especially true for the case of the "old" duals (first rev) where we
don't have any child under /u3/i2c/fan, we "return(2)". Shouldn't this
be "return(1)" ? this is lines 171 and 185.
- Once we have everybody, we check if we have one of the fans called
"rpm1" at reg value 0x12. This is typically one of the pumps. If so we
return 2. That seem to be logical if 2 is really the water cooled system
(ACS ?). _HOWEVER_ I do have a device-tree dump here of a PowerMac7_2
machines dual 2Ghz with U3 (I don't know if it's heavy) which _does_
have this property too (though the location string is "CPU A" and not
"CPU A PUMP" and so it's probably not useable). So that means this
machine would incorrectly be detected as config 2 while it should
apparently be config 1. It has U3 rev 0x34 which is different from 0x35
found in a dual 2.5Ghz though, so this could be used for differenciating
them.
- Finally, we return 3 or 1 depending on IS_U3_HEAVY() which looks
correct.
So the above seem to show that at least my old dual 2Ghz is incorrectly
identified, and maybe some others. Unless I've missed something of
course... I've verified that with IORegistryExplorer, and indeed, the
class that was instanciated is PowerMac7_3CPUCoolingCtrlLoop...
Now of course, there may be a good reason for these ...
Another thing I've noticed is that the device-tree of a dual2.5Ghz, for
the PUMPs, shows rpm0 beeing "CPU B PUMP" on control-id 0x4000 (16384)
and rpm1 beeing "CPU A PUMP" on control-id 0x4100 (16640), which seem to
be the exact opposite as the definitions in the XML where CPUA_ACS is
defined to be 0x4000 and CPUB_ACS 0x4100.
I don't which of the XML or the device-tree is wrong here, but it's
harmless as the pumps are currently both programmed to the same value,
though it has almost been a bug in the linux driver I'm working on :)
Regards,
Ben.
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden