On Tue, 2005-10-18 at 14:39 +0200, Henrik Sjoberg wrote: > Hi, > > I am playing a bit with getting MythTV to talk high level CI. However, I > have come to a problem in the dst/dst_ca drivers. MythTV have different > threads running for tuning frequency and doing ca-stuff. This makes me get > simultaneous frontend and ca calls device. However, in the dst driver > these two things both end up in i2c communiation with the card which > interfere with each other. > > As you can understand this does not work good since there are no locking > mechanism in dst. Is this something that is to go into the driver or > something that should be done on a higher level (e.g. between all > components in an dvb-adapter)? I guess it should be taken care of by the > driver, since it is the only one that knows when locking is needed, but I > just want to check. I've played around to make vlc speak high level CI. I have code that I'm fairly confident makes correct capmt messages, but it only works once in a while. I have all sorts of strange behaviour. Some times the system gets in a state where tuning does not work (no calls report any errors, but the received mux does not change). unloading and reloading the driver fixes this. Some times the dst.session struct get messed up so that the dst_ca belive has_session is set while it actually is not. And even other times the cam or card or smartcard or something gets stuck in a state where any call to the ca device return just garbage. This sometimes solves itself after a minute or two, and other times I need a cold boot to get it working again. I was under the impression that this had to be caused by a memory corrution caused by a buffer overflow in the i2c trafic(because increasing the size *_buf fields in the state struct stoped the has session flag from being corrupted, but perhaps this is the cause of my problems as well? Vlc uses only a single thread for all dvb communication, but perhaps a unfortunate sequence of ca/demux/fe calls could cause this problem as well? In that case perhaps a i2c trafic overflowing the buffer is a response from some other call? Any feedback welcomed. Sigmund > > Regards, > Henrik > > > > > _______________________________________________ > > linux-dvb@xxxxxxxxxxx > http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
