On Sat, Jan 23, 2010 at 5:08 AM, hermann pitton <hermann-pitton@xxxxxxxx> wrote: > Hi. > > Am Samstag, den 23.01.2010, 01:23 +0400 schrieb Manu Abraham: >> On Sat, Jan 23, 2010 at 1:14 AM, Mauro Carvalho Chehab >> <mchehab@xxxxxxxxxxxxx> wrote: >> > Devin Heitmueller wrote: >> >> On Fri, Jan 22, 2010 at 3:22 PM, Manu Abraham <abraham.manu@xxxxxxxxx> wrote: >> >>> On Fri, Jan 22, 2010 at 11:40 PM, Devin Heitmueller >> >>> <dheitmueller@xxxxxxxxxxxxxx> wrote: >> >>>> 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. >> >>> Ok, thanks for the pointer. The gate control is never called >> >>> externally in reality. I will wait a little while for this patch to be >> >>> applied. It removes the exported function and thereby an unnecessary >> >>> dereference. >> >>> >> >>> http://jusst.de/hg/stv090x/rev/b3d28f5b2b53 >> >> >> >> If it never needs to be called externally, then removing it from the >> >> dvb_frontend_ops does eliminate the risk entirely. The case I >> >> frequently see it called from dvb_frontend.c is for powering down the >> >> tuner when the dvb frontend thread shuts down. >> > >> > The removal of the external call to the gate function removes the risk that >> > an external call, at dvb core, to keep it locked. Yet, the code there is completely >> > symetric nowadays. >> > >> > However, the proper documentation of the lock is needed to avoid the risk >> > of some patch to keep the mutex locked. >> > >> > As, even the initial lock changeset has this problem (later fixed by >> > http://jusst.de/hg/stv090x/rev/3a8f35abc0f2), it shows that a good documentation >> > is required. >> > >> > As you've talked about a FSM, the lock itself is a FSM with 2 states. All I'm >> > asking is that you document that the lock FSM has changed its state in the name >> > of the function that alters the state of the lock. >> > >> >> Sure, of course, i will add some comments into the patch that I have >> queued up, before pull request. Don't worry, be at peace. :-) >> >> Regards, >> Manu > > Good, seems there is some progress. > > But 1080p was first from satellites only too ;) Eventually, broadcasters will restrict all good content. Only old stuff will even be happening with FTA. Even old scrambling systems are going away. Broadcasters would transmit protected content in the stream, along with relevant keys for relevant schema; CI+ is replacing old CI systems. CI+ streams would eventually be encrypted; ie, you won't get access to those streams, The CI+ output will be paired with a CI+ capable decoder, which will be given it's set of keys. The decoder will output HDMI with HDCP .. You can see that vicious circle that's evolving ... Broadcasters and Media producers like to term it as a war; they don't want users to capture the streams on a computer eventually; that's another way of stating it; even if the media has to be Time shifted, that would be paired with decoder, so eventually the media stays at one place and doesn't get circulated. 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
