Port-sparc64 archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: Upgrading from 5.1_STABLE to 5.99.46 on Sun Fire V100
On Sun, Feb 27, 2011 at 04:52:18PM -0500, Michael wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Hello,
>
> On Feb 27, 2011, at 3:32 PM, Martin Husemann wrote:
>
> >On Sun, Feb 27, 2011 at 07:31:51PM +0100, Jan-Hinrich Fessel wrote:
> >>What happened?
> >>And, what is fan-control?
> >
> >I have no idea what fan control chip is used on that machines, if
> >anyone
> >finds docs (or a driver for another OS) adding support is probably
> >simple.
>
> Apparently I missed half of this - what else is on the fan-control
> node? If you're lucky there's something useful in the 'compatible'
> property. Otherwise the i2c address would be a good hint.
Actually, the interesting thing here is that fan-control is a peer of
the i2c bus, rather than a child of the bus. The reason we don't find
the spdmem / admtemp / ... is that device_register() appears to get the
wrong (or incomplete?) set of devices to stuff into the i2c-child-devices
devprop.
Here's the device_register() that matters (with some added comments and
printfs by me):
993 /*
994 * Check for I2C busses and add data for their direct configurat
ion.
995 */
996 if (device_is_a(dev, "iic")) {
997 /*
998 * XXXrkb: I think if there are no i2c-child-devices, we
999 * should be entering i2c devs on the device's node, not
1000 * the busnode (which is the parent of the i2c bus).
1001 */
1002 int busnode = device_ofnode(busdev);
1003 printf("%s: adding iic bus at %d\n", __func__, busnode);
1004
1005 if (busnode) {
1006 prop_dictionary_t props = device_properties(busd
ev);
1007 prop_object_t cfg = prop_dictionary_get(props,
1008 "i2c-child-devices");
1009 if (!cfg) {
1010 printf("%s: no i2c child devices\n", __f
unc__);
1011 of_enter_i2c_devs(props, busnode,
1012 sizeof(cell_t));
1013 } else {
1014 printf("%s: found i2c child devices\n",
__func__);
1015 }
1016 }
and the OF device tree looks like so:
f0069d48: /pci
[...]
f007b6bc: /pci/pmu@3
f007be84: /pci/pmu@3/i2c@0,0
f007d31c: /pci/pmu@3/i2c@0,0/temperature@0,30 ("i2c-max1617")
f007d48c: /pci/pmu@3/i2c@0,0/dimm@0,a8 ("i2c-at34c02")
(more dimms)
f007d6b4: /pci/pmu@3/i2c@0,0/i2c-nvram@0,a0 ("i2c-at24c64")
f007e1cc: /pci/pmu@3/i2c@0,0/i2c-nvram@0,a0/idprom@1fd8
f007e480: /pci/pmu@3/i2c@0,0/motherboard-fru@0,a2 ("i2c-at24c64")
f007f018: /pci/pmu@3/ppm@0,b3 ("SUNW,smbus-ppm")
f007f28c: /pci/pmu@3/beep@0,b2 ("SUNW,smbus-beep")
f007f3a4: /pci/pmu@3/fan-control@0,c8 ("SUNW,smbus-fan-control")
[...]
Note that what the i2c controller sees as children on my machine are the
'ppm', 'beep' and 'fan-control' instead of (what I would expect):
"temparature", N instances of "dimm", "i2c-nvram", "motherboard-fru".
What I'm not 100% sure of is whether the peers of the i2c bus should be
passed as well or not -- it doesn't make sense to me from the OF tree,
but I'm also relatively clueless about OF, so maybe I am missing some-
thing.
--rafal
--
Time is an illusion; lunchtime, doubly so. |/\/\| Rafal Boni
-- Ford Prefect |\/\/|
rafal%pobox.com@localhost
Home |
Main Index |
Thread Index |
Old Index