User Space I2C Access Arbitration
 

If this is not the correct forum for this question please direct me.

I have an I2C port connected to two devices: a touch screen and a temperature sensor. The touch screen has a kernel driver accessing it.

I want to access the temp sensor from user space by directly accessing the I2C bus via a file in the /dev directory. This seems to work OK.

My question is does the kernel arbitrate access to the I2C port? In other words, what if my process tries to access the temp sensor at the same time the touch screen driver is accessing the touch screen?

Will the kernel queue up the requests?

Thanks

It might be better to ask a moderator if this could be placed into one of the forums for Linux Kernel, or Linux Hardware.

My first take on this would be that I'd assume the touch screen programs and whatever programming you'd be doing would both be using the Linux kernel based I2C driver, and likely the same driver in both cases.

You wouldn't be writing within that driver, you'd just be using the one which is in the kernel and accessible for when you have a program which requests I2C access.

Therefore "that I2C driver" would be the component in this which would take care of both programming resource arbitration as well as I2C bus arbitration.

I2C bus arbitration always exists with the assumption that you need to use a start sequence to get on the bus and then put out the address of the device you wish to speak too. You are not supposed to issue the start sequence if the bus is in a certain condition, such as you cannot bring the bus signal high for some reason, I forget the actual signal state but it is standard I2C bus arbitration which is electrical signaling. And further, once you've detected that you're out of sequence, or have lost arbitration, you're supposed to detect a future I2C stop condition, which is a reversion of the signal to the opposite sense from where it's at, as an indicator that you can now have access. For instance, you can check to see if the bus is high, if so, you can proceed. If it's low, you can try to bring it high, and if that works, you can proceed. If it's low, you can also just wait for it to go high. Or if it's low and you try to bring it high, but are unsuccessful, you have to conclude that you can't have the bus, and then continue to wait. Problems would be if there were failing hardware grounding the bus all the time, then communications would never work. But that's understood and there would have to be a hardware fix to resolve that problem.

Thank you for your response.

Yes, like you, I'm thinking that both the touch screen driver and the second process will ultimately get at the I2C port through the same driver and at that point they would be arbitrated.

I was hoping for a definite confirmation, but I sincerely do appreciate your response.

In all my searching and reading, I can't find any info that delves that low into how Linux works. I don't currently have the time to start working on learning Linux low level drivers.

Can anyone else confirm or direct me toward more information?

To be more clear, the I2C kernel driver is only ever going to serve one I2C process at a time. The actions are atomic, in that you'll have i2c_read() or i2c_write() and those will be protected from being interfered with until they are complete. But you can have interleaved reads and writes for the various devices.

OK, great. That's how I expected it might work. I was looking for someone to confirm it. Thanks.

I'm perfectly fine with interleaved access as long as either process doesn't cancel the others transaction. So I should be OK.

Thanks again.