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@xxxxxxxxxxx> 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@xxxxxxxxxxx> 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�����{��-��)�� jg��� �����ݢj����G���� ���j:+v���w�m������w�������h�����٥
