On Wed, Jul 11, 2012 at 06:10:43PM +0200, Jean Delvare wrote: > Hi Guenter, Stevie, > > On Wed, 11 Jul 2012 07:45:56 -0700, Guenter Roeck wrote: > > On Wed, Jul 11, 2012 at 04:16:21PM +0200, Stevie Trujillo wrote: [ ... ] > > > > > > > If that works, then please unload the driver and reload with write=2. > > > > This will log every register write right before it happens. So the last > > > > message logged is likely to point to a register write which is > > > > inappropriate for your device/board. > > > > > > I only see these lines: [ 265.408976] it87: Found IT8728F chip at 0xa30, > > > revision 1 [ 265.410655] it87: Beeping is supported [ 265.411583] it87: > > > Writing value 0x37 to register 0x0c [ 265.423124] it87: Writing value > > > 0x13 to register 0x00 > > > > > Jean, > > > > it87_write_value(data, IT87_REG_CONFIG, (it87_read_value(data, > > IT87_REG_CONFIG) & 0x36) | (update_vbat ? 0x41 : 0x01)); > > > > Unless I am missing something, the above code enables interrupts by clearing > > bit 3. In combination with having bit 1 set, this means that SMI# interrupts > > will be enabled. Default value for the register, at least for IT8721F and > > IT8718F, is 0x18. > > The meaning of all bits in this register, and its default value, did not > change since the IT8705F, at least up to the IT8721F. I do not have the > datasheet for the IT8728F, do I cannot comment on that. Maybe something > changed for that chip, or - more likely - it is wired or configured in an > unusual way on Stevie's board. > I suspect the latter. The meanings did not change for IT8782F and IT8783E/F either, so there is no reason to believe that IT8728F would be different. > A bit of archeology teaches us that the mysterious 0x36 mask comes from this > commit 8 years ago: > http://git.kernel.org/?p=linux/kernel/git/tglx/history.git;a=commitdiff;h=30678638d86ea855f89fe5c799d146af7a75b64e > > Before that the mask was 0xb7, which wasn't that different given that bit 7 > always reads back 0, and bit 0 is about be set anyway. I think 0x80 was > removed to avoid an unlikely double-reset of the chip when the module is > loaded with reset=1. > > The 0xb7 is from the very first version of the it87 driver by Christophe > Gauthron 11 years ago. I have no idea why bit 3 was explicitly cleared back > then. > Oversight, maybe, or the bit name was confusing. It doesn't make much sense to enable SMI interrupts while keeping global interrupts disabled. We may just have been lucky to never hit this problem. > > Replacing the 0x36 mask above with 0x3e might possibly solve the problem. > > Indeed. I'm not too sure what to do about bit 5, BTW, it might be > self-clearing as bit 7. > I'd keep it as-is. Not worth trying to solve a problem which may not exist. Guenter _______________________________________________ lm-sensors mailing list lm-sensors@xxxxxxxxxxxxxx http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
