Hi Tim, On Thu, 7 Jul 2011 10:32:38 -0500 (CDT), Tim Nelson wrote: > ----- Original Message ----- > > As pointed out by Michael already, 08h in the datasheet translates to > > 0x08 in the Linux world. > > I'm curious how this conversion translates. Is it as simple as dropping the suffix 'h', no actual math involved? Most other registers are noted with an 'h' suffix as well for this chip. No math involved. The "h" suffix means hexadecimal. The "0x" prefix means the same. Which one to use depends on the environment and culture. Have fun reading: http://en.wikipedia.org/wiki/Hexadecimal#Representing_hexadecimal > > The correct slave address is certainly 0x19, as the datasheet says > > that > > the first 4 address bits are hard-set to 0011b, which means a 7-bit > > slave address in the 0x18-0x1f range. The device at 0x4c could be a > > thermal sensor (sensors-detect should tell.) > > Yes, correct. We have an ITE super-IO sensor onboard for monitoring which is at 0x4c. That would be relatively surprising, as ITE super-I/O chips are LPC devices accessed with direct I/O. I think there used to be one old model which could alternatively be accessed over the SMBus (the monitoring block at least) but it would be at address 0x2d rather than 0x4c, and I doubt current chips still support that. Just try sensors-detect and see what it finds. > > Yes, with i2cget and i2cset you could do that. But I suspect that in > > the end you will want to write a proper kernel GPIO driver, so that > > you > > can benefit from all the nice things gpiolib does for you (including, > > but not limited to, clear and safe access from other kernel drivers.) > > There are several examples of such drivers under drivers/gpio (pcf857x > > and pca953x in particular.) > > This specific implementation purely needs to exist in userland as the only use for the controller is LED status (on, off, blink). Well, there is a framework in the kernel for this too. > I'm now able to read from the proper register for the GP10-GP13 pins, but I'm not able to write. Example: > > root@aaa:~# i2cget -y 0 0x19 0x08 > 0x00 > > According to the datasbeet, to set all LEDs from off to on, I'd need to set the 0x08 register to binary '10101010' which is 0xaa in hex. So: > > root@aaa:~# i2cset -y 0 0x19 0x08 0xaa > Error: Write failed > > Is my binary->hex math incorrect (verified against a few online calcs...)? Am I blatantly missing something else? Your binary->hex is correct, and the command as well, but the chip did not like the write for some reason. You should look at the kernel logs when it failed, there may be a hint. You could also just retry to check if this was maybe a transient error. To test the reliability of the SMBus you could dump the whole register map: # i2cdump -y -r 0x00-0x22 0 0x19 and look for XX's. -- Jean Delvare -- To unsubscribe from this list: send the line "unsubscribe linux-i2c" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
