On Fri, Jan 22, 2010 at 10:43 PM, Devin Heitmueller <dheitmuel...@kernellabs.com> wrote: > On Fri, Jan 22, 2010 at 1:23 PM, Manu Abraham <abraham.m...@gmail.com> wrote: >> 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) > > Ok, I see what is going on now. I didn't notice before that the gate > enable was keeping the "state->internal->tuner_lock" mutex set even > after the call returned. > > My only concern here then is that I've seen cases where the > i2c_gate_ctrl() function is called in a non-symmetric fashion (where > the enable/disable calls are not necessarily properly balanced), > depending on the driver. While I am relatively confident that you > have balanced the instances where it is called within your driver, I > would be concerned about how it could possibly be called from other > places such as from the tuner driver or the dvb frontend core.
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. In this case, it is not trying to balance of the gate control, whereas it is a state machine to safely control 2 tuner instances on the same demodulator. > Today, there is no real problem if a particular call path attempts to > enable the gate if it is already open (or disable if it is already > closed). With your proposed change, you will result in a deadlock. 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 Regards, Manu -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
