On Fri, Jan 22, 2010 at 9:56 PM, Devin Heitmueller <dheitmueller@xxxxxxxxxxxxxx> wrote: > On Fri, Jan 22, 2010 at 12:48 PM, Mauro Carvalho Chehab > <mchehab@xxxxxxxxxxxxx> wrote: >>>>> if (stv090x_i2c_gate_ctrl(fe, 1) < 0) >>>>> goto err; >>>>> >>>>> tuner access >>>>> >>>>> if (stv090x_i2c_gate_ctrl(fe, 0) < 0) >>>>> goto err; >>>> Ok. It is very unusual to have a lock internally like the above, since >>>> the code becomes poorly documented. >>> >>> >>> That's how a tuner is accessed for "any" dvb device. >> >> Yes, but that's not a function is expect to behave. In general, functions handle >> the lock/unlock inside it, returning the mutex unlocked. > > I'm confused - isn't this how pretty much *every* frontend does it's > locking? The i2c_gate_ctrl() callback is a standard component in the > DVB API. How is what Manu is doing different than any of the other > DVB drivers? > > While I agree that the name "i2c_gate_ctrl" is not what I would have > chosen, as far as I can tell this is how every DVB frontend does it. The point there is that it is a dual demod which implements a FSM for it's tuner flow control and hence. The demodulators in the tree are generally single/standalone and don't need such a FSM to handle that. Even if it's a dual frontend, most of them just do locking for the register access, while here it is not register access locking, while it is controlling state, similar to Finite State Machine (FSM) Regards, Manu -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
