Re: [I2C] informations + advice about messages handling

[Mylene Josserand]

Le 24/05/2013 11:07, Jean Delvare a écrit :
 > On Fri, 24 May 2013 10:54:11 +0200, Mylene Josserand wrote:
 >> Ah okay ! And if there are not SMBus compliant, what function I will
 >> have to use ?
 >
 > i2c_transfer()


Okay, logic name ;)


 >> What is it doing if I use this function and that my device is not SMbus
 >> compliant ?
 >
 > This would make no sense. Your device understands only specific message
 > formats, which should be documented in its datasheet. You have to use
 > exactly that in your driver. If the message format matches SMBus, you
 > can use the SMBus API, otherwise you must use i2c_transfer() instead.

Very interesting !
Right now, my company uses the "i2c_smbus_read/write_byte_data" 
functions to talk to devices through an application. On the datasheet of 
these devices, I search but did not seem to be SMBus compliant.
As it was a software which was using these functions, we thought that a 
driver (that I would write) should be better. And here I am ! I prefer 
to understand well the mechanism before coding anything and it is 
interesting !


 >> I have some difficulties to understand the differences
 >> between SMbus and I2C :(
 >
 > SMBus is a subset of I2C. With I2C you can have messages of any length
 > and any format, with no attached semantics. SMBus restricts the
 > possibilities to a few standardized messages formats with semantics. If
 > you'd just tell us what your device is, we would be able to tell you if
 > SMBus will work or if I2C will be needed.

Thanks for the explanation.
No problem, we have 2 devices used without drivers :
- an odometer PIC18F24201 : In the datasheet, there is a SMBus select 
bit but I don't know if it is SMBus compliant.
- an audio codec tlv320aic3204 : There is a driver for this device but 
for some reasons, we did not use it. Did not find a "SMBus compliant" in 
its datasheet.


 >> (...)
 >> In my case, I have 2 segments but if I understand, the bus will not be
 >> used at the same time.
 >
 > I can't comment on that without knowing the exact topology. In
 > particular, do you have two independent segments each with its own
 > controller, or are they interconnected in some way? I2C/SMBus is very
 > simple with basic topologies but can become difficult with complex ones.

Yes of course, I understand.
For that, I will ask to our "hardware guy".


 >> (...)
 >> Okay. So the mutex blocks the I2C bus. And is it locking the bus at the
 >> beginning of a message (so when a START is send) and unlocking it after
 >> the STOP ?
 >
 > Yes.
 >
 >> So a complete message will be sent to a same device (the one which
 >> address is in the data frame) ? A device can not receive a beginning of
 >> one message (so with his address) and the end of another message
 >> destined to another device [because of "collision"], for example ?
 >
 > No, this cannot happen.


Thanks a lot for your help !


-- 
Mylène JOSSERAND
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/