Hi Wolfram W dniu 15.05.2020 o 11:20, Wolfram Sang pisze: > >> So this does not really solve my problem - even if we do get the lock >> by calling select(), we will simply release it as soon as our >> i2c_transfer() is finished (and will let the other master take it, >> breaking atomicity of the two operations I need to perform on target >> device) and this is exactly what I need to avoid. > > I was assuming that once you have the lock from the arbitrator you can > be sure that the other master is not active and, thus, you maybe don't > need to read the status register at all? But I am probably wrong here. > The problem here is that the i2c-mux framework will only take lock for one transfer i2c and will always drop this lock after this one transfer. We can send multiple messages in one transaction and keep the lock for the whole time but what I actually needs is to send multiple transactions, not just messages. We are programming flash memory of an target device and we have to poll for some status bits before we can send more data, for example. So there are two possibilities: 1. I could lock the arbitrator for the whole time the programming is done. This way I could indeed skip reading status register. 2. We could lock the arbitrator, read the status register of the target device to check if programming is already running, if it is not, then start it (which will set the bit in status register). Those to operations have to be atomic so I have to hold the lock between the two transactions. None of the two options can be done currently as mux layer will call deselect (releasing the lock) after each transaction and we need more than one transaction (as described above). We need to use the 2nd option, however, as this lets 2nd system still talk to some other devices on the downstream bus while the 1st one is performing the flashing of the target device for example while we're waiting for target device to be ready for next page of data) but this is not that relevant in this discussion. Best regards, Krzysztof Adamski
