On Fri, May 24, 2013 at 12:41 PM, Mylene Josserand
<[email protected]> wrote:
> Hi all,
>
>
> I am learning how i2c is working and I read that, to write in an i2c
> register, I need to use the function "i2c_smbus_write_byte_data".
Only in case your device is smbus compliant.
> I wanted to know how the message are handled by using this function. If
> I use this function to talk with 2 different i2d devices, how it will
> handle "message collision" ? should I have to add a kind of mutex on the
Message collision and detection is the job of i2c controller and if I am
not wrong you are writing a chip driver.
> access of the i2c bus ?
> Is it possible that the message destined for one device is sent to
> another one ? Or a "mix" of messages is impossible ?
It is not possible as the data contains the chip address which is
unique.7/10 bit mode addressing is used for addresses.
>
> I have read that this function "i2c_smbus_write_byte_data" uses
> "i2c_smbus_xfer" which uses "i2c_lock_adapter".
> In this function, there is a mutex so I thought that it will handle it
> but it says "Get exclusive access to an I2C bus segment". What is
> exactly an I2C segment ? Is it the device we are talking about ? Or is
> it the use of the i2c bus ?
Don't know what you are referring here.
>
> I will certainly have to create an i2c driver and I would like to know
> if this "collision" handling (if it is handled) is done in old kernel
> (2.6.32) or is it handled only in new kernel versions ?
AFAIK collision handling and detection was not supported till now
in linux kernel until recently but I think this patch is doing that.
I may be wrong but I didn't see collision handling in earlier linux
kernels.
http://thread.gmane.org/gmane.linux.kernel/1410276
>
> If you have any documentation on how the i2c messages are handled in
> case of different devices uses, it will help me a lot ! I will search in
> the kernel documentation but there is many files about i2c.
> And if you know a good i2c driver that I can use as an example to design
> mine, it will be great !
>
>
> Thank you in advance,
>
> --
> Mylène JOSSERAND
>
> _______________________________________________
> Kernelnewbies mailing list
> [email protected]
> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Hi Anish, Mylène,
On Fri, 24 May 2013 12:52:40 +0530, anish singh wrote:
> On Fri, May 24, 2013 at 12:41 PM, Mylene Josserand
> <[email protected]> wrote:
> > I have read that this function "i2c_smbus_write_byte_data" uses
> > "i2c_smbus_xfer" which uses "i2c_lock_adapter".
> > In this function, there is a mutex so I thought that it will handle it
> > but it says "Get exclusive access to an I2C bus segment". What is
> > exactly an I2C segment ? Is it the device we are talking about ? Or is
> > it the use of the i2c bus ?
> Don't know what you are referring here.
In the most simple case, your I2C bus has a single segment so "segment"
or "bus" mean the same thing.
It only starts mattering when I2C bus multiplexing comes into play.
Then your bus is split into segments, with one segment (trunk) between
the master (controller) and the multiplexer, and one or more segments
(branches) hanging off the multiplexer.
Take look at
https://i2c.wiki.kernel.org/index.php/I2C_bus_multiplexing
for a sample topology.
But anyway the comment in front of i2c_lock_adapter() is somewhat
misleading. If you read the code you'll see that it always locks the
whole bus tree, because it uses the root segment's mutex.
> > I will certainly have to create an i2c driver and I would like to know
> > if this "collision" handling (if it is handled) is done in old kernel
> > (2.6.32) or is it handled only in new kernel versions ?
> AFAIK collision handling and detection was not supported till now
> in linux kernel until recently but I think this patch is doing that.
> I may be wrong but I didn't see collision handling in earlier linux
> kernels.
> http://thread.gmane.org/gmane.linux.kernel/1410276
This is for a specific case. The general case is handled by the
per-adapter mutex for years now. 2.6.32 should be just fine in this
respect.
> > If you have any documentation on how the i2c messages are handled in
> > case of different devices uses, it will help me a lot ! I will search in
> > the kernel documentation but there is many files about i2c.
> > And if you know a good i2c driver that I can use as an example to design
> > mine, it will be great !
Best is to look at a driver for a device which is similar in
functionality to yours.
--
Jean Delvare
Thanks, both of you, for your answers ! It helps me a lot to understand it !
Le 24/05/2013 09:22, anish singh a écrit :
> On Fri, May 24, 2013 at 12:41 PM, Mylene Josserand
> <[email protected]> wrote:
>> Hi all,
>>
>>
>> I am learning how i2c is working and I read that, to write in an i2c
>> register, I need to use the function "i2c_smbus_write_byte_data".
> Only in case your device is smbus compliant.
Ah okay ! And if there are not SMBus compliant, what function I will
have to use ?
What is it doing if I use this function and that my device is not SMbus
compliant ? I have some difficulties to understand the differences
between SMbus and I2C :(
Le 24/05/2013 09:44, Jean Delvare a écrit :
> Hi Anish, Mylène,
>
> On Fri, 24 May 2013 12:52:40 +0530, anish singh wrote:
>> On Fri, May 24, 2013 at 12:41 PM, Mylene Josserand
>> <[email protected]> wrote:
>>> I have read that this function "i2c_smbus_write_byte_data" uses
>>> "i2c_smbus_xfer" which uses "i2c_lock_adapter".
>>> In this function, there is a mutex so I thought that it will handle it
>>> but it says "Get exclusive access to an I2C bus segment". What is
>>> exactly an I2C segment ? Is it the device we are talking about ? Or is
>>> it the use of the i2c bus ?
>> Don't know what you are referring here.
>
> In the most simple case, your I2C bus has a single segment so "segment"
> or "bus" mean the same thing.
>
> It only starts mattering when I2C bus multiplexing comes into play.
> Then your bus is split into segments, with one segment (trunk) between
> the master (controller) and the multiplexer, and one or more segments
> (branches) hanging off the multiplexer.
>
> Take look at
> https://i2c.wiki.kernel.org/index.php/I2C_bus_multiplexing
> for a sample topology.
>
> But anyway the comment in front of i2c_lock_adapter() is somewhat
> misleading. If you read the code you'll see that it always locks the
> whole bus tree, because it uses the root segment's mutex.
Thanks ! I understand now.
In my case, I have 2 segments but if I understand, the bus will not be
used at the same time.
>>> I will certainly have to create an i2c driver and I would like to know
>>> if this "collision" handling (if it is handled) is done in old kernel
>>> (2.6.32) or is it handled only in new kernel versions ?
>> AFAIK collision handling and detection was not supported till now
>> in linux kernel until recently but I think this patch is doing that.
>> I may be wrong but I didn't see collision handling in earlier linux
>> kernels.
>> http://thread.gmane.org/gmane.linux.kernel/1410276
>
> This is for a specific case. The general case is handled by the
> per-adapter mutex for years now. 2.6.32 should be just fine in this
> respect.
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 ?
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 ?
>>> If you have any documentation on how the i2c messages are handled in
>>> case of different devices uses, it will help me a lot ! I will
search in
>>> the kernel documentation but there is many files about i2c.
>>> And if you know a good i2c driver that I can use as an example to
design
>>> mine, it will be great !
>
> Best is to look at a driver for a device which is similar in
> functionality to yours.
I will search that, thanks for the advice.
--
Mylène JOSSERAND
????{.n?+???????+%?????ݶ??w??{.n?+????{??G?????{ay? ʇڙ?,j??f???h?????????z_??(?階?ݢj"???m??????G????????????&???~???iO???z??v?^?m???? ????????I?
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()
> 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.
> 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.
> (...)
> 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.
> (...)
> 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.
--
Jean Delvare
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
On Fri, May 24, 2013 at 1:14 PM, Jean Delvare <[email protected]> wrote:
> Hi Anish, Mylène,
>
> On Fri, 24 May 2013 12:52:40 +0530, anish singh wrote:
>> On Fri, May 24, 2013 at 12:41 PM, Mylene Josserand
>> <[email protected]> wrote:
>> > I have read that this function "i2c_smbus_write_byte_data" uses
>> > "i2c_smbus_xfer" which uses "i2c_lock_adapter".
>> > In this function, there is a mutex so I thought that it will handle it
>> > but it says "Get exclusive access to an I2C bus segment". What is
>> > exactly an I2C segment ? Is it the device we are talking about ? Or is
>> > it the use of the i2c bus ?
>> Don't know what you are referring here.
>
> In the most simple case, your I2C bus has a single segment so "segment"
> or "bus" mean the same thing.
>
> It only starts mattering when I2C bus multiplexing comes into play.
> Then your bus is split into segments, with one segment (trunk) between
> the master (controller) and the multiplexer, and one or more segments
> (branches) hanging off the multiplexer.
>
> Take look at
> https://i2c.wiki.kernel.org/index.php/I2C_bus_multiplexing
> for a sample topology.
>
> But anyway the comment in front of i2c_lock_adapter() is somewhat
> misleading. If you read the code you'll see that it always locks the
> whole bus tree, because it uses the root segment's mutex.
>
>> > I will certainly have to create an i2c driver and I would like to know
>> > if this "collision" handling (if it is handled) is done in old kernel
>> > (2.6.32) or is it handled only in new kernel versions ?
>> AFAIK collision handling and detection was not supported till now
>> in linux kernel until recently but I think this patch is doing that.
>> I may be wrong but I didn't see collision handling in earlier linux
>> kernels.
>> http://thread.gmane.org/gmane.linux.kernel/1410276
>
> This is for a specific case. The general case is handled by the
> per-adapter mutex for years now. 2.6.32 should be just fine in this
> respect.
I may be mis-understanding here but when two client wants to
communicate with same master and at the same
time how does that happen?
In the thread I mentioned client pulls the line low indicating that
it wants to own the bus and waits for some time and then checks
if the line is still low or not.If it is still low then it owns the bus
and start transaction and if clients see otherwise it releases the
bus and tries again after some time.How is that handled in the
previous kernel?
>
>> > If you have any documentation on how the i2c messages are handled in
>> > case of different devices uses, it will help me a lot ! I will search in
>> > the kernel documentation but there is many files about i2c.
>> > And if you know a good i2c driver that I can use as an example to design
>> > mine, it will be great !
>
> Best is to look at a driver for a device which is similar in
> functionality to yours.
>
> --
> Jean Delvare
On Fri, 24 May 2013 16:29:36 +0530, anish singh wrote:
> On Fri, May 24, 2013 at 1:14 PM, Jean Delvare <[email protected]> wrote:
> > On Fri, 24 May 2013 12:52:40 +0530, anish singh wrote:
> >> http://thread.gmane.org/gmane.linux.kernel/1410276
> >
> > This is for a specific case. The general case is handled by the
> > per-adapter mutex for years now. 2.6.32 should be just fine in this
> > respect.
>
> I may be mis-understanding here but when two client wants to
> communicate with same master and at the same
> time how does that happen?
In general clients (slaves in I2C terminology) do not initiate
transactions, it's the master's job.
> In the thread I mentioned client pulls the line low indicating that
> it wants to own the bus and waits for some time and then checks
> if the line is still low or not.If it is still low then it owns the bus
> and start transaction and if clients see otherwise it releases the
> bus and tries again after some time.How is that handled in the
> previous kernel?
That particular scenario is not handled by earlier kernels, but this is
a very special case. In most cases (including Mylène's as far as I can
see) it is not needed because there is a single master on the segment.
And even with multiple masters, I2C bus arbitration normally takes place
transparently. Only when the standard bus arbitration can't work for
some reason, the code you mentioned is needed.
--
Jean Delvare
On Fri, 24 May 2013 11:52:54 +0200, Mylene Josserand wrote:
> 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 !
If the application was using i2c_smbus_read/write_byte_data from
user-space, then a kernel driver would call the same functions. No
reason why this wouldn't work.
> (...)
> 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.
Couldn't find the datasheet for this one, unfortunately.
> - 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.
The tlv320aic32x4 driver uses i2c_master_send, which is a shortcut to
i2c_transfer. However it seems to only send 2 bytes on the bus at once,
the same could be achieved with i2c_smbus_write_byte_data if needed.
For completeness: a device might use transactions which are compliant
with SMBus without being formally "SMBus-compliant", because SMBus has
more constraints than just transaction types (I kept things simple
originally to not confuse you.) This may explain why it isn't mentioned
in the datasheet. Or just because the manufacturer did not care because
they target fully I2C-capable systems anyway.
What you have to look at is the transaction types. They are usually
described in the datasheet. Then compare with either the SMBus
specification or
http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Documentation/i2c/smbus-protocol
and if they match then you can use the i2c_smbus_*() calls.
> (...)
> Thanks a lot for your help !
You're welcome.
--
Jean Delvare
Hi Jean,
Le 24/05/2013 14:20, Jean Delvare a ?crit :
> On Fri, 24 May 2013 11:52:54 +0200, Mylene Josserand wrote:
>> - 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.
>
> The tlv320aic32x4 driver uses i2c_master_send, which is a shortcut to
> i2c_transfer. However it seems to only send 2 bytes on the bus at once,
> the same could be achieved with i2c_smbus_write_byte_data if needed.
Okay, thanks to have looked at it !
>
> For completeness: a device might use transactions which are compliant
> with SMBus without being formally "SMBus-compliant", because SMBus has
> more constraints than just transaction types (I kept things simple
> originally to not confuse you.) This may explain why it isn't mentioned
> in the datasheet. Or just because the manufacturer did not care because
> they target fully I2C-capable systems anyway.
>
> What you have to look at is the transaction types. They are usually
> described in the datasheet. Then compare with either the SMBus
> specification or
> http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Documentation/i2c/smbus-protocol
> and if they match then you can use the i2c_smbus_*() calls.
I have checked the PIC18F24201 according to your advice and, of what I
have seen, it can handle the SMBus protocol.
Thank you for the explanation and trying to keep it simple for me :)
--
Myl?ne JOSSERAND