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
I don't think there is any lock which would prevent this, is there?
(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.
Johannes
_______________________________________________
linux-dvb mailing list
[email protected]
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
