Johannes Stezenbach wrote: > On Fri, May 18, 2007, Manu Abraham wrote: >> Johannes Stezenbach wrote: >>> On Fri, May 18, 2007 at 04:48:13PM +0200, e9hack wrote: >>> >>>> IMHO, it isn't possible >>>> to split a read request into a single write and a single read request >>>> outside of the core device. The device must be locked during both >>>> transfers. If the device isn't locked, it is possible that another >>>> transfer will change the slave offset before the content is read. This >>>> may occur with the current implementation. >>> If locking is necessary the drivers would need to >>> handle this explicitely (I think it isn't unless ou start >>> messing mith /dev/i2c concurrently). >> even if you do a concurrent operation with /dev/i2c, the i2c bus driver >> read/write provides concurrency locks, afiacs. Or am i missing something ? > > One i2c_transfer() is atomic, if you do two (as required > by stv0297) another transfer could happen in between. > > So intead of e.g. > > stv0297 send register number > stv0297 read register data > i2c-dev send another register number > i2c-dev read register data > > you might get > > stv0297 send register number > i2c-dev send another register number > stv0297 read register data > i2c-dev read register data > True, it can be atomic for one write/read cycle for a read operation at the utmost maximum. If you need to do 2 transfers then that could be problematic. (didn't think of the individual transactions) Even though not relevant for the topic: when one sends continuously STOP- START, many demods do get confused. The result: demod doesn't reply back anything at all. Did have some demods that got hung that way (power cycling fixes this), including the STV0299 (not typo, dvb-s demod). Later on figured that the too many STOP bits got the demod confused, struggled a bit on this some time back. Some time later while talking to Ralph he too confirmed the same. A year or 2 back i think. The STV0297 really does need a STOP bit in between ? But if this is specific to the STV0297, it should be handled by the STV0297 driver itself ? > I don't think there is any lock which would prevent this, is there? Don't think so. :-( But even if the locking is handled by the frontend, then /dev/i2c access will still have different results as the locking is still in the frontend device only. Thinking about which, i think your earlier thought sounds better. ie, Adding a flag to handle the same. Another option is to define a new transaction type. But both methods don't look very nice. > (The BKL might protect two i2c-dev accesses from each other, but not > against the accesses from the dvb_frontend_thread.) > > But I also think that messing with i2c-dev on the frontend > i2c bus is a debug tool and not a regular use case. True, in which case i think a lock in the frontend would be a better option, rather than fiddling (adding a flag to handle the same) with the i2c bus driver ? _______________________________________________ linux-dvb mailing list linux-dvb@xxxxxxxxxxx http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
