On Wed, Mar 24, 2010 at 11:33:00AM +0100, Hans de Goede wrote: > On 03/24/2010 10:36 AM, Giel van Schijndel wrote: >>On Wed, Mar 24, 2010 at 09:37:43AM +0100, Hans de Goede wrote: >>> Nack: >>> As the watchdog has its own SIO logical device number, it should >>> have a separate driver, not have support glued to the hwmon driver. >> >> Thus, if I understand correctly, you would suggest for me to >> implement a new driver in drivers/watchdog/ to implement this >> feature? > > Yes, correct. So I've now started out working on moving the watchdog code to a separate driver. I/O port conflict However, this driver would have to lock the SIO port range as well. Unlike the hardware monitor, however, the watchdog (VID controller on some datasheets) doesn't appear to provide for an alternative I/O port mapping. Meaning the wathdog driver would have to maintain a permanent hold on the SIO port range. This would thus interfere with the operation of the f71882fg driver. I.e. it would prevent the device probing stage from working, thus preventing it from loading *after* my in-development watchdog driver. Alternative logical device port mapping Regarding address mapping: the 16 bit SIO_REG_ADDR(0x60) register does exist for this logical device, though according to the datasheet it is set to 0x0000 by default. Reading the value from hardware it claims to be mapped on 0x0AE0, trying to read from that port range (using f71882fg_read8) yields nothing more than 0xFF for any register mentioned in the datasheet. Hardware monitor alternate port range Further, when looking at the way that SIO_REG_ADDR is currently used by the f71882fg driver I get more confused: > *hwmon_addr = superio_inw(sioaddr, SIO_REG_ADDR); > /* error checking: *hwmon_addr != 0 */ > *hwmon_addr &= ~(REGION_LENGTH - 1); /* Ignore 3 LSB */ For the F71808E and F71889, which both have 0x295, for hardware monitor base address that code ^^ combined with the addition of ADDR_REG_OFFSET and DATA_REG_OFFSET (see f71882fg_(read|write)8) all of this basically amounts to mangling 0x295 -> 0x290 -> (0x295,0x296). So my question: is there any particular reason for performing this address mangling? Mostly: is there anything there that I should try replicating in order to get mapping of the watchdog device on an alternate port range working? PS Perhaps this would be easier to converse about if you had the datasheet? -- Met vriendelijke groet, With kind regards, Giel van Schijndel
Attachment:
signature.asc
Description: Digital signature
_______________________________________________ lm-sensors mailing list lm-sensors@xxxxxxxxxxxxxx http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
