On Fri, Jan 22, 2010 at 2:11 PM, Manu Abraham <abraham.manu@xxxxxxxxx> wrote: > I think you understood incorrectly. Generally most demodulators have > an option to detect the I2C stop bit, thereby automatically disabling > the gate, while some don't. In those cases, you don't even need a > i2c_gate_control(disable) > It is that safe. Now, even if the gate happens to be open for some > reason, it won't have a large downside, just that the i2c transactions > might seep into the tuner silicon as RF noise. Yes, I was aware of this (although I might dispute whether *most* demodulators really operate this way). > Can you explain your logic a bit more in detail, please ? > > If you meant to imply the action on a failure case, it does unlock in > all possible cases as you can see... > http://jusst.de/hg/stv090x/rev/3a8f35abc0f2 I am not talking about the case where the tuning fails. I mean that not only is the i2c_gate_ctrl function used internally by stv090x.c, but it is also exposed via the dvb_frontend_ops struct. Depending on what tuner chip your frontend is being used with, I have seen cases where the tuner driver itself takes responsibility for opening/closing the gate. So you effectively end up with: frontend driver calls i2c_gate_ctrl(enable) frontend driver tells tuner driver to tune tuner driver calls i2c_gate_ctrl(enable) <--- Would cause deadlock in your driver tuner driver calls i2c_gate_ctrl(disable) tuner driver returns to caller frontend driver calls i2c_gate_ctrl(disable) With other devices, this call is typically silently succeeds (and doesn't cause any harm). In your case though, it would end up with a deadlock because your particular i2c_gate_ctrl() function leaves the "state->internal->tuner_lock" in a locked state. Now you may not run into this issue because today your frontend is only used with a tuner that doesn't do this. However it is something to watch out for in the future. Also, the dvb_frontend.c makes calls to i2c_gate_ctrl() at various points, so you would need to ensure that none of those occur before calling into your driver as there could potentially be a deadlock there too. Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- 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
