lkml.org 
[lkml]   [2013]   [May]   [24]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [I2C] informations + advice about messages handling
Date
From
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
> <Mylene.Josserand@navocap.com> 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
>> <Mylene.Josserand@navocap.com> 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
\
 
 \ /
  Last update: 2013-05-24 11:41    [W:0.118 / U:0.408 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site