[lm-sensors] read()ing an i2c node results in errno=ENOSYS

[lm-sensors] read()ing an i2c node results in errno=ENOSYS

[David Sharp]

we're working on a robotics project, and are tryng using an i2c bus to
communicate between our microcontrollers and our mini-itx pc
(via-embedded Epia ML).

the kernel is rather patched to support the hardware, but i think the
important bits are untouched (I didn't do the kernel patching myself).
It is fairly a recent kernel, i'm pretty sure 2.6.11 (i'd check, but
the box is not in front of me atm).

We have been trying to write some preliminary testing code to
communicate over the i2c bus. some of the original testing code used
i2c-dev.h from the lm_sensors project to use the SMBus functions.
These seem to work correctly. However, we don't want to use SMBus, as
it is more difficult to implement in the microcontrollers. Instead, we
would like to use plain i2c.

From my reading of Documentation/i2c/dev-inteface and some of the
kernel source, we should be able to open(), then use ioctl() to set
the slave address, and finally use read() and write() to make i2c
reads and writes.

although the dev-interface file seems to be outdated (the i2c_smbus_*
"macro's" it refers to are no longer in the kernel headers, and are
now only in the lm_sensors' i2c-dev.h), my amateur reading of the
kernel source supports that this should work. However, a read call
results in errno=ENOSYS (Function not implemented), although on one
run, i actually got EPERM, and another time resulted in SEGV.

I'm sure we've done something wrong, but I can't figure out what it
is, and the ENOSYS mystifies me. I'm fairly sure all necessary kernel
modules are loaded (i2c-core, i2c-dev, i2c-viapro, some others...)
since i2cdetect works, as well as the test using
i2c_smbus_write_block_data().

Thanks,
David Sharp
CalPoly Robotics Club

[lm-sensors] read()ing an i2c node results in errno=ENOSYS

[Jean Delvare]

Hi David,

> we're working on a robotics project, and are tryng using an i2c bus to
> communicate between our microcontrollers and our mini-itx pc
> (via-embedded Epia ML).
> (...)
> although the dev-interface file seems to be outdated (the i2c_smbus_*
> "macro's" it refers to are no longer in the kernel headers, and are
> now only in the lm_sensors' i2c-dev.h),

Care to send a patch fixing this doc file?

> my amateur reading of the
> kernel source supports that this should work. However, a read call
> results in errno=ENOSYS (Function not implemented), although on one
> run, i actually got EPERM, and another time resulted in SEGV.

ENOSYS is expected. You are trying to do raw I2C transfers while the bus
driver (i2c-viapro) and underlying chip only offer SMBus transfers (that
is, a subset of I2C.) It fails.

I'm more concerned about EPERM and SEGV, which obviously shouldn't
happen. Hard to say why this happens without the actual code though.

-- 
Jean Delvare

[lm-sensors] read()ing an i2c node results in errno=ENOSYS

[David Sharp]

On 9/16/05, Jean Delvare <khali@linux-fr.org> wrote:
> > although the dev-interface file seems to be outdated (the i2c_smbus_*
> > "macro's" it refers to are no longer in the kernel headers, and are
> > now only in the lm_sensors' i2c-dev.h),
> 
> Care to send a patch fixing this doc file?

Sure! i'll try. Attached. It's against the 2.6.12 source i have on my
desktop box, but i don't think it has changed since.

> 
> > my amateur reading of the
> > kernel source supports that this should work. However, a read call
> > results in errno=ENOSYS (Function not implemented), although on one
> > run, i actually got EPERM, and another time resulted in SEGV.
> 
> ENOSYS is expected. You are trying to do raw I2C transfers while the bus
> driver (i2c-viapro) and underlying chip only offer SMBus transfers (that
> is, a subset of I2C.) It fails.
> 
> I'm more concerned about EPERM and SEGV, which obviously shouldn't
> happen. Hard to say why this happens without the actual code though.

well, the SEGV i couldn't repeat, and disappeared during the time it
took to compile gdb to try to debug it. Actually, the EPERM may have
happened more than once, but i can't reproduce it any more. It may
have something to do with the module loading and unloading i was doing
in vain attempts to get it to work. I'll definitely let you know if i
get them again, and can get more info. I suspect they may have been
caused by bus glitches, however. Shady programming on the
microcontrollers, maybe. We are busy now implementing some proper
SMBus on the microcontrollers anyway.

Thank you very much for your help, both on and off the list!

> 
> --
> Jean Delvare
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: linux-2.6.12-doc-i2c-dev-interface.patch
Type: application/octet-stream
Size: 2795 bytes
Desc: not available
Url : http://lists.lm-sensors.org/pipermail/lm-sensors/attachments/20050917/0cc81559/linux-2.6.12-doc-i2c-dev-interface.obj

[lm-sensors] read()ing an i2c node results in errno=ENOSYS

[David Sharp]

> > > my amateur reading of the
> > > kernel source supports that this should work. However, a read call
> > > results in errno=ENOSYS (Function not implemented), although on one
> > > run, i actually got EPERM, and another time resulted in SEGV.
> >
> > ENOSYS is expected. You are trying to do raw I2C transfers while the bus
> > driver (i2c-viapro) and underlying chip only offer SMBus transfers (that
> > is, a subset of I2C.) It fails.
> >
> > I'm more concerned about EPERM and SEGV, which obviously shouldn't
> > happen. Hard to say why this happens without the actual code though.
> 
> well, the SEGV i couldn't repeat, and disappeared during the time it
> took to compile gdb to try to debug it. Actually, the EPERM may have
> happened more than once, but i can't reproduce it any more. It may
> have something to do with the module loading and unloading i was doing
> in vain attempts to get it to work. I'll definitely let you know if i
> get them again, and can get more info. I suspect they may have been
> caused by bus glitches, however. Shady programming on the
> microcontrollers, maybe. We are busy now implementing some proper
> SMBus on the microcontrollers anyway.

We've now implemented simple SMBus on our microcontrollers, and it is
mostly working. block writes work perfectly, but we are having a small
problem with block reads on the PC side. It seems from the register
dumps in the kernel logs that the first byte is going to the DAT0
register instead of into the BLK, so in userspace, it appears like the
first byte is lost. (DAT1 remains 00, though). As far as we can tell,
the data on the bus is correct, but our oscilloscope is nice and old,
making it impossible to see the whole transaction.

The EPERMs reappeared as we were working, but disappeared when we
started doing things correctly on the bus. They were probably actually
a Good Thing, better than getting garbage or something more fatal, so
I don't think you should worry about it.

[lm-sensors] read()ing an i2c node results in errno=ENOSYS

[Jean Delvare]

Hi David,

> We've now implemented simple SMBus on our microcontrollers, and it is
> mostly working. block writes work perfectly, but we are having a small
> problem with block reads on the PC side. It seems from the register
> dumps in the kernel logs that the first byte is going to the DAT0
> register instead of into the BLK, so in userspace, it appears like the
> first byte is lost. (DAT1 remains 00, though). As far as we can tell,
> the data on the bus is correct, but our oscilloscope is nice and old,
> making it impossible to see the whole transaction.

There are two kinds of block reads defined in the SMBus specification,
regular Block Read and I2C Block Read. In the former, the first byte
received is an information of how many bytes follow. This first byte
typically goes in DAT0 rather than the BLK buffer. In the latter, data
is send directly and all bytes are stored in BLK. I guess that you
currently use the former when what you need is actually the latter.

Note that a client chip can only support one of the two kinds of block
reads at any register address ("command byte" in the SMBus
specification), as there is no way to distinguish between both commands
from the client's point of view. It's up to the master (PC) to use the
correct one depending on what the client implements.

> The EPERMs reappeared as we were working, but disappeared when we
> started doing things correctly on the bus. They were probably actually
> a Good Thing, better than getting garbage or something more fatal, so
> I don't think you should worry about it.

OK, thanks for lettng me know.

-- 
Jean Delvare

[lm-sensors] read()ing an i2c node results in errno=ENOSYS

[Mark M. Hoffman]

Hi Jean, David:

* Jean Delvare <khali@linux-fr.org> [2005-09-18 09:22:53 +0200]:
> Note that a client chip can only support one of the two kinds of block
> reads at any register address ("command byte" in the SMBus
> specification), as there is no way to distinguish between both commands
> from the client's point of view. It's up to the master (PC) to use the
> correct one depending on what the client implements.

Actually: SMBus read byte data, SMBus read word data, and SMBus block read
*all* have the same setup:

	S Addr Wr [A] Comm [A] S Addr Rd [A] (...)

As Jean mentions: you'll need to decide how your slave device responds on
each register address (comm), and then program the master accordingly.

Regards,

-- 
Mark M. Hoffman
mhoffman@lightlink.com