Re: [coreboot] [PATCH] Simplify device enabling and initialization
The ADM1027 doesn't expect to have children, so it has no scan_bus method. I had thought that the ADM1027 was some kind of a controller for the ADT4763, but it looks like the same type of device. Is there really an ADM1027 on your board? I don't see it in your sensors output. So... the first two patches are the same as before. The third patch adds a scan_bus method to the ADM1027 so that the ADT4763 can be initialized, and the fourth patch replaces the ADM1027 with the ADT4763 in the device tree, and removes the third patch. I'd be interested in head + 1 + 2 + 3, and head + 1 + 2 + 3 + 4. See http://ward.vandewege.net/coreboot/s2881/20100621-myles/ Thanks for testing Ward! As far as I can see, both worked, but 1+2+3+4 is cleaner. It doesn't look like there is an ADM1027 on your board. Is there something missing before an Ack commit? Thanks, Myles -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [PATCH] Simplify device enabling and initialization
On Tue, Jun 22, 2010 at 01:30:45PM -0600, Myles Watson wrote: The ADM1027 doesn't expect to have children, so it has no scan_bus method. I had thought that the ADM1027 was some kind of a controller for the ADT4763, but it looks like the same type of device. Is there really an ADM1027 on your board? I don't see it in your sensors output. So... the first two patches are the same as before. The third patch adds a scan_bus method to the ADM1027 so that the ADT4763 can be initialized, and the fourth patch replaces the ADM1027 with the ADT4763 in the device tree, and removes the third patch. I'd be interested in head + 1 + 2 + 3, and head + 1 + 2 + 3 + 4. See http://ward.vandewege.net/coreboot/s2881/20100621-myles/ Thanks for testing Ward! As far as I can see, both worked, but 1+2+3+4 is cleaner. It doesn't look like there is an ADM1027 on your board. Is there something missing before an Ack commit? I think it's good. Thanks for writing the patches! Acked-by: Ward Vandewege w...@gnu.org Thanks, Ward. -- Ward Vandewege w...@gnu.org -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [PATCH] Simplify device enabling and initialization
I think it's good. Thanks for writing the patches! No problem. I've wanted the initialization order to be fixed for a long time. It's good to have it done. Acked-by: Ward Vandewege w...@gnu.org Rev 5641. Thanks, Myles -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [PATCH] Simplify device enabling and initialization
On Sun, Jun 20, 2010 at 8:11 PM, Ward Vandewege w...@gnu.org wrote: Hi Myles, Everything seems fine with either patch - but there are some differences in the boot output. I also ran the 'sensors' command. Output here: http://ward.vandewege.net/coreboot/s2881/20100617-myles/ I ran 4 tests: stock r5635 (head), stock r5632 (revision prior to this changeset), r5635 + patch 1 and r5635 + patch 2. Thanks for testing. It looks like only 5632 has the ADT7463 properly initialized message. One problem is that patch 2 was meant to be applied after patch 1, so the device didn't end up in the tree for that run. I'll have to think about why the only message from the new device with patch 1 is I2C: 00:d0 missing read_resources For some reason it doesn't look like it got the correct ops. I wonder why the temperature values look right in all cases. Does it need to be cold booted in order for the initialization to be needed? Thanks, Myles Thanks, Myles -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [PATCH] Simplify device enabling and initialization
On Mon, Jun 21, 2010 at 5:59 AM, Myles Watson myle...@gmail.com wrote:
On Sun, Jun 20, 2010 at 8:11 PM, Ward Vandewege w...@gnu.org wrote:
Hi Myles,
Everything seems fine with either patch - but there are some differences in
the boot output.
I also ran the 'sensors' command.
Output here:
http://ward.vandewege.net/coreboot/s2881/20100617-myles/
I ran 4 tests: stock r5635 (head), stock r5632 (revision prior to this
changeset), r5635 + patch 1 and r5635 + patch 2.
Thanks for testing.
It looks like only 5632 has the ADT7463 properly initialized
message. One problem is that patch 2 was meant to be applied after
patch 1, so the device didn't end up in the tree for that run. I'll
have to think about why the only message from the new device with
patch 1 is I2C: 00:d0 missing read_resources For some reason it
doesn't look like it got the correct ops.
I wonder why the temperature values look right in all cases. Does it
need to be cold booted in order for the initialization to be needed?
The ADM1027 doesn't expect to have children, so it has no scan_bus
method. I had thought that the ADM1027 was some kind of a controller
for the ADT4763, but it looks like the same type of device. Is there
really an ADM1027 on your board? I don't see it in your sensors
output.
So... the first two patches are the same as before. The third patch
adds a scan_bus method to the ADM1027 so that the ADT4763 can be
initialized, and the fourth patch replaces the ADM1027 with the
ADT4763 in the device tree, and removes the third patch.
I'd be interested in head + 1 + 2 + 3, and head + 1 + 2 + 3 + 4.
There may be some initialization that was done by the ADM1027 code
that needs to be moved to the ADT7463 code, since both were being run.
So 1 + 2 + 3 should give behavior that is closer to the original code,
but if there is no ADM1027, the right thing to do is 1 + 2 + 3 + 4 +
some ADM1027 code if necessary.
Signed-off-by: Myles Watson myle...@gmail.com
Thanks,
Myles
Index: svn/src/mainboard/tyan/s2881/Makefile.inc
===
--- svn.orig/src/mainboard/tyan/s2881/Makefile.inc
+++ svn/src/mainboard/tyan/s2881/Makefile.inc
@@ -1 +1,2 @@
obj-y += ../../../drivers/i2c/adm1027/adm1027.o
+obj-y += ../../../drivers/i2c/adt7463/adt7463.o
Index: svn/src/mainboard/tyan/s2881/devicetree.cb
===
--- svn.orig/src/mainboard/tyan/s2881/devicetree.cb
+++ svn/src/mainboard/tyan/s2881/devicetree.cb
@@ -103,7 +103,12 @@ chip northbridge/amd/amdk8/root_complex
device i2c 57 on end
end
chip drivers/i2c/adm1027 # ADT7463A CPU0/1 temp, CPU1 vid, SYS FAN 1/2/3
-device i2c 2d on end
+device i2c 2d on
+chip drivers/i2c/adt7463
+device i2c d0 on
+end
+end
+end
end
chip drivers/generic/generic # Winbond HWM 0x54 CPU0/1 VRM temp, SYSFAN 4,CPU0 vid, CPU0/1 FAN
device i2c 2a on end
Index: svn/src/drivers/i2c/adt7463/adt7463.c
===
--- svn.orig/src/drivers/i2c/adt7463/adt7463.c
+++ svn/src/drivers/i2c/adt7463/adt7463.c
@@ -116,7 +116,7 @@ static void enable_dev(struct device *de
dev-ops = adt7463_operations;
}
-struct chip_operations mainboard_ops = {
+struct chip_operations drivers_i2c_adt7463_ops = {
CHIP_NAME(adt7463)
.enable_dev = enable_dev,
};
Index: svn/src/drivers/i2c/adt7463/adt7463.c
===
--- svn.orig/src/drivers/i2c/adt7463/adt7463.c
+++ svn/src/drivers/i2c/adt7463/adt7463.c
@@ -35,67 +35,56 @@
*/
static void adt7463_init(device_t dev)
{
- device_t smbus_dev, adt7463;
- struct device_path path;
+ device_t parent;
int result;
- /* Find the SMBus controller (AMD-8111). */
- smbus_dev = dev_find_device(0x1022, 0x746b, 0);
- if (!smbus_dev)
- die(SMBus controller not found\n);
- printk(BIOS_DEBUG, SMBus controller found\n);
-
- /* Find the ADT7463 device. */
- path.type = DEVICE_PATH_I2C;
- path.i2c.device = 0x2d;
- adt7463 = find_dev_path(smbus_dev-link_list, path);
- if (!adt7463)
- die(ADT7463 not found\n);
- printk(BIOS_DEBUG, ADT7463 found\n);
+ /* Find the ADT7463's parent device. */
+ parent = dev-bus-dev;
+ printk(BIOS_DEBUG,
Re: [coreboot] [PATCH] Simplify device enabling and initialization
If there is no adm1027, then the adt4763 needs to be initialized, not
its parent. Updated patch 4 attached.
Signed-off-by: Myles Watson myle...@gmail.com
Thanks,
Myles
Index: svn/src/mainboard/tyan/s2881/Makefile.inc
===
--- svn.orig/src/mainboard/tyan/s2881/Makefile.inc
+++ svn/src/mainboard/tyan/s2881/Makefile.inc
@@ -1,2 +1 @@
-obj-y += ../../../drivers/i2c/adm1027/adm1027.o
obj-y += ../../../drivers/i2c/adt7463/adt7463.o
Index: svn/src/mainboard/tyan/s2881/devicetree.cb
===
--- svn.orig/src/mainboard/tyan/s2881/devicetree.cb
+++ svn/src/mainboard/tyan/s2881/devicetree.cb
@@ -102,13 +102,8 @@ chip northbridge/amd/amdk8/root_complex
chip drivers/generic/generic #dimm 1-1-1
device i2c 57 on end
end
-chip drivers/i2c/adm1027 # ADT7463A CPU0/1 temp, CPU1 vid, SYS FAN 1/2/3
-device i2c 2d on
-chip drivers/i2c/adt7463
-device i2c d0 on
-end
-end
-end
+chip drivers/i2c/adt7463 # CPU0/1 temp, CPU1 vid, SYS FAN 1/2/3
+device i2c 2d on end
end
chip drivers/generic/generic # Winbond HWM 0x54 CPU0/1 VRM temp, SYSFAN 4,CPU0 vid, CPU0/1 FAN
device i2c 2a on end
Index: svn/src/drivers/i2c/adm1027/adm1027.c
===
--- svn.orig/src/drivers/i2c/adm1027/adm1027.c
+++ svn/src/drivers/i2c/adm1027/adm1027.c
@@ -56,7 +56,6 @@ static void adm1027_noop(device_t dummy)
}
static struct device_operations adm1027_operations = {
- .scan_bus = scan_static_bus,
.read_resources = adm1027_noop,
.set_resources = adm1027_noop,
.enable_resources = adm1027_noop,
Index: svn/src/drivers/i2c/adt7463/adt7463.c
===
--- svn.orig/src/drivers/i2c/adt7463/adt7463.c
+++ svn/src/drivers/i2c/adt7463/adt7463.c
@@ -35,56 +35,53 @@
*/
static void adt7463_init(device_t dev)
{
- device_t parent;
int result;
- /* Find the ADT7463's parent device. */
- parent = dev-bus-dev;
- printk(BIOS_DEBUG, ADT7463 parent is %s\n, dev_path(parent));
+ printk(BIOS_DEBUG, ADT7463 is %s\n, dev_path(dev));
/* Set all fans to 'Fastest Speed Calculated by All 3 Temperature
* Channels Controls PWMx'.
*/
- result = smbus_write_byte(parent, 0x5c, 0xc2);
- result = smbus_write_byte(parent, 0x5d, 0xc2);
- result = smbus_write_byte(parent, 0x5e, 0xc2);
+ result = smbus_write_byte(dev, 0x5c, 0xc2);
+ result = smbus_write_byte(dev, 0x5d, 0xc2);
+ result = smbus_write_byte(dev, 0x5e, 0xc2);
/* Make sure that our fans never stop when temp. falls below Tmin,
* but rather keep going at minimum duty cycle (applies to automatic
* fan control mode only).
*/
- result = smbus_write_byte(parent, 0x62, 0xc0);
+ result = smbus_write_byte(dev, 0x62, 0xc0);
/* Set minimum PWM duty cycle to 25%, rather than the default 50%. */
- result = smbus_write_byte(parent, 0x64, 0x40);
- result = smbus_write_byte(parent, 0x65, 0x40);
- result = smbus_write_byte(parent, 0x66, 0x40);
+ result = smbus_write_byte(dev, 0x64, 0x40);
+ result = smbus_write_byte(dev, 0x65, 0x40);
+ result = smbus_write_byte(dev, 0x66, 0x40);
/* Set Tmin to 55C, rather than the default 90C. Above this temperature
* the fans will start blowing harder as temperature increases
* (automatic mode only).
*/
- result = smbus_write_byte(parent, 0x67, 0x37);
- result = smbus_write_byte(parent, 0x68, 0x37);
- result = smbus_write_byte(parent, 0x69, 0x37);
+ result = smbus_write_byte(dev, 0x67, 0x37);
+ result = smbus_write_byte(dev, 0x68, 0x37);
+ result = smbus_write_byte(dev, 0x69, 0x37);
/* Set THERM limit to 70C, rather than the default 100C.
* The fans will kick in at 100% if the sensors reach this temperature,
* (only in automatic mode, but supposedly even when hardware is
* locked up). This is a failsafe measure.
*/
- result = smbus_write_byte(parent, 0x6a, 0x46);
- result = smbus_write_byte(parent, 0x6b, 0x46);
- result = smbus_write_byte(parent, 0x6c, 0x46);
+ result = smbus_write_byte(dev, 0x6a, 0x46);
+ result = smbus_write_byte(dev, 0x6b, 0x46);
+ result =
Re: [coreboot] [PATCH] Simplify device enabling and initialization
On Mon, Jun 21, 2010 at 05:59:52AM -0600, Myles Watson wrote: It looks like only 5632 has the ADT7463 properly initialized message. One problem is that patch 2 was meant to be applied after patch 1, Ah, whoops, I was wondering if I was doing the right thing there... so the device didn't end up in the tree for that run. I'll have to think about why the only message from the new device with patch 1 is I2C: 00:d0 missing read_resources For some reason it doesn't look like it got the correct ops. I wonder why the temperature values look right in all cases. Does it need to be cold booted in order for the initialization to be needed? All boots were cold. Thanks, Ward. -- Ward Vandewege w...@fsf.org Free Software Foundation - Senior Systems Administrator -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [PATCH] Simplify device enabling and initialization
On Mon, Jun 21, 2010 at 8:59 AM, Ward Vandewege w...@gnu.org wrote: On Mon, Jun 21, 2010 at 05:59:52AM -0600, Myles Watson wrote: It looks like only 5632 has the ADT7463 properly initialized message. One problem is that patch 2 was meant to be applied after patch 1, Ah, whoops, I was wondering if I was doing the right thing there... I should have been clearer. so the device didn't end up in the tree for that run. I'll have to think about why the only message from the new device with patch 1 is I2C: 00:d0 missing read_resources For some reason it doesn't look like it got the correct ops. I wonder why the temperature values look right in all cases. Does it need to be cold booted in order for the initialization to be needed? All boots were cold. OK. Thanks for doing that. I guess I don't know what I'm looking at in the sensors output to see if the device initialization worked. Thanks, Myles -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [PATCH] Simplify device enabling and initialization
On Mon, Jun 21, 2010 at 07:36:39AM -0600, Myles Watson wrote: On Mon, Jun 21, 2010 at 5:59 AM, Myles Watson myle...@gmail.com wrote: On Sun, Jun 20, 2010 at 8:11 PM, Ward Vandewege w...@gnu.org wrote: Hi Myles, Everything seems fine with either patch - but there are some differences in the boot output. I also ran the 'sensors' command. Output here: http://ward.vandewege.net/coreboot/s2881/20100617-myles/ I ran 4 tests: stock r5635 (head), stock r5632 (revision prior to this changeset), r5635 + patch 1 and r5635 + patch 2. Thanks for testing. It looks like only 5632 has the ADT7463 properly initialized message. One problem is that patch 2 was meant to be applied after patch 1, so the device didn't end up in the tree for that run. I'll have to think about why the only message from the new device with patch 1 is I2C: 00:d0 missing read_resources For some reason it doesn't look like it got the correct ops. I wonder why the temperature values look right in all cases. Does it need to be cold booted in order for the initialization to be needed? The ADM1027 doesn't expect to have children, so it has no scan_bus method. I had thought that the ADM1027 was some kind of a controller for the ADT4763, but it looks like the same type of device. Is there really an ADM1027 on your board? I don't see it in your sensors output. So... the first two patches are the same as before. The third patch adds a scan_bus method to the ADM1027 so that the ADT4763 can be initialized, and the fourth patch replaces the ADM1027 with the ADT4763 in the device tree, and removes the third patch. I'd be interested in head + 1 + 2 + 3, and head + 1 + 2 + 3 + 4. See http://ward.vandewege.net/coreboot/s2881/20100621-myles/ The temperature differences (higher readouts in head + 1 + 2 + 3 + 4 seem to be the consequence of less than optimal cooling of the board - and the fact that it was entirely cooled off before the first boot (head + 1 + 2 + 3) only. Thanks, Ward. -- Ward Vandewege w...@fsf.org Free Software Foundation - Senior Systems Administrator -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [PATCH] Simplify device enabling and initialization
Hi Myles, Everything seems fine with either patch - but there are some differences in the boot output. I also ran the 'sensors' command. Output here: http://ward.vandewege.net/coreboot/s2881/20100617-myles/ I ran 4 tests: stock r5635 (head), stock r5632 (revision prior to this changeset), r5635 + patch 1 and r5635 + patch 2. Let me know if you need anything else... Thanks, Ward. -- Ward Vandewege w...@gnu.org -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [PATCH] Simplify device enabling and initialization
Myles Watson wrote: If we initialize and enable devices in the order that they are found in the tree, instead of the order that they were added to the list, it simplifies the code. It also makes it so that removing a device from the devicetree.cb file won't change when its resources are enabled. .. Signed-off-by: Myles Watson myle...@gmail.com Acked-by: Peter Stuge pe...@stuge.se This patch breaks the s2881, which was doing some odd acrobatics in order to get a device initialized after its parent. If neccessary then I would be in favor of mainboard-specific hooks from coreboot, that are separate from the device tree. But maybe the init for s2881 can be done using a coreboot driver ? //Peter -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [PATCH] Simplify device enabling and initialization
On Thu, Jun 17, 2010 at 2:04 AM, Peter Stuge pe...@stuge.se wrote: Myles Watson wrote: If we initialize and enable devices in the order that they are found in the tree, instead of the order that they were added to the list, it simplifies the code. It also makes it so that removing a device from the devicetree.cb file won't change when its resources are enabled. .. Signed-off-by: Myles Watson myle...@gmail.com Acked-by: Peter Stuge pe...@stuge.se Rev 5633. I copied the s2881 code into a driver stub, since Ward said he's willing to test. This patch breaks the s2881, which was doing some odd acrobatics in order to get a device initialized after its parent. If neccessary then I would be in favor of mainboard-specific hooks from coreboot, that are separate from the device tree. But maybe the init for s2881 can be done using a coreboot driver ? That could work. I think it might get abused, though. Thanks, Myles -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [PATCH] Simplify device enabling and initialization
On Wed, Jun 16, 2010 at 6:22 PM, Ward Vandewege w...@gnu.org wrote:
On Wed, Jun 16, 2010 at 02:50:42PM -0600, Myles Watson wrote:
This patch breaks the s2881, which was doing some odd acrobatics in
order to get a device initialized after its parent. It should be an
easy fix to do it correctly now, but I don't have an s2881 to test on.
Ward?
Yep, I've got (the guts) of an s2881 lying on my desk here, and can test any
patches you throw at me :)
Great. Here are two patches.
The first one enables the driver exactly like it was before, only as a driver.
The second one tries to make it less board specific. Putting the fan
settings in the device tree would complete that effort, I think.
Suggestions welcome. Thanks for testing!
Signed-off-by: Myles Watson myle...@gmail.com
Thanks,
Myles
Index: svn/src/mainboard/tyan/s2881/Makefile.inc
===
--- svn.orig/src/mainboard/tyan/s2881/Makefile.inc
+++ svn/src/mainboard/tyan/s2881/Makefile.inc
@@ -1 +1,2 @@
obj-y += ../../../drivers/i2c/adm1027/adm1027.o
+obj-y += ../../../drivers/i2c/adt7463/adt7463.o
Index: svn/src/mainboard/tyan/s2881/devicetree.cb
===
--- svn.orig/src/mainboard/tyan/s2881/devicetree.cb
+++ svn/src/mainboard/tyan/s2881/devicetree.cb
@@ -103,7 +103,12 @@ chip northbridge/amd/amdk8/root_complex
device i2c 57 on end
end
chip drivers/i2c/adm1027 # ADT7463A CPU0/1 temp, CPU1 vid, SYS FAN 1/2/3
-device i2c 2d on end
+device i2c 2d on
+chip drivers/i2c/adt7463
+device i2c d0 on
+end
+end
+end
end
chip drivers/generic/generic # Winbond HWM 0x54 CPU0/1 VRM temp, SYSFAN 4,CPU0 vid, CPU0/1 FAN
device i2c 2a on end
Index: svn/src/drivers/i2c/adt7463/adt7463.c
===
--- svn.orig/src/drivers/i2c/adt7463/adt7463.c
+++ svn/src/drivers/i2c/adt7463/adt7463.c
@@ -116,7 +116,7 @@ static void enable_dev(struct device *de
dev-ops = adt7463_operations;
}
-struct chip_operations mainboard_ops = {
+struct chip_operations drivers_i2c_adt7463_ops = {
CHIP_NAME(adt7463)
.enable_dev = enable_dev,
};
Index: svn/src/drivers/i2c/adt7463/adt7463.c
===
--- svn.orig/src/drivers/i2c/adt7463/adt7463.c
+++ svn/src/drivers/i2c/adt7463/adt7463.c
@@ -35,67 +35,56 @@
*/
static void adt7463_init(device_t dev)
{
- device_t smbus_dev, adt7463;
- struct device_path path;
+ device_t parent;
int result;
- /* Find the SMBus controller (AMD-8111). */
- smbus_dev = dev_find_device(0x1022, 0x746b, 0);
- if (!smbus_dev)
- die(SMBus controller not found\n);
- printk(BIOS_DEBUG, SMBus controller found\n);
-
- /* Find the ADT7463 device. */
- path.type = DEVICE_PATH_I2C;
- path.i2c.device = 0x2d;
- adt7463 = find_dev_path(smbus_dev-link_list, path);
- if (!adt7463)
- die(ADT7463 not found\n);
- printk(BIOS_DEBUG, ADT7463 found\n);
+ /* Find the ADT7463's parent device. */
+ parent = dev-bus-dev;
+ printk(BIOS_DEBUG, ADT7463 parent is %s\n, dev_path(parent));
/* Set all fans to 'Fastest Speed Calculated by All 3 Temperature
* Channels Controls PWMx'.
*/
- result = smbus_write_byte(adt7463, 0x5c, 0xc2);
- result = smbus_write_byte(adt7463, 0x5d, 0xc2);
- result = smbus_write_byte(adt7463, 0x5e, 0xc2);
+ result = smbus_write_byte(parent, 0x5c, 0xc2);
+ result = smbus_write_byte(parent, 0x5d, 0xc2);
+ result = smbus_write_byte(parent, 0x5e, 0xc2);
/* Make sure that our fans never stop when temp. falls below Tmin,
* but rather keep going at minimum duty cycle (applies to automatic
* fan control mode only).
*/
- result = smbus_write_byte(adt7463, 0x62, 0xc0);
+ result = smbus_write_byte(parent, 0x62, 0xc0);
/* Set minimum PWM duty cycle to 25%, rather than the default 50%. */
- result = smbus_write_byte(adt7463, 0x64, 0x40);
- result = smbus_write_byte(adt7463, 0x65, 0x40);
- result = smbus_write_byte(adt7463, 0x66, 0x40);
+ result = smbus_write_byte(parent, 0x64, 0x40);
+ result = smbus_write_byte(parent, 0x65, 0x40);
+ result = smbus_write_byte(parent, 0x66, 0x40);
/* Set Tmin to 55C, rather than the default 90C. Above this temperature
* the fans will
Re: [coreboot] [PATCH] Simplify device enabling and initialization
On Wed, Jun 16, 2010 at 02:50:42PM -0600, Myles Watson wrote: This patch breaks the s2881, which was doing some odd acrobatics in order to get a device initialized after its parent. It should be an easy fix to do it correctly now, but I don't have an s2881 to test on. Ward? Yep, I've got (the guts) of an s2881 lying on my desk here, and can test any patches you throw at me :) Thanks, Ward. -- Ward Vandewege w...@fsf.org Free Software Foundation - Senior Systems Administrator -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
