On Friday 23 January 2004 16:16, Ralph Metzler wrote: > Andrew de Quincey writes: > > CENELEC EN50221 implies that you can't write data to the CAM if it has > > data waiting to be read by the host. What have other people's > > implementations done if a user app attempts to write() data when it is > > not possible? > > > > I could cache the data to be written... I don't like this... the app > > might never read(). > > Actually, driver and app have to read. The driver has to regularly poll for > incoming data (usually no interrupt support) and the app has to answer > to requests in time (or the connection with the CAM is lost) . So, the > app has to read and write regularly. > You will have to cache "read data" in any case. > You can get around caching "write data" by blocking until no more > reads are required if you want to. > > dvb_ca.c (based on the upper levels of the av7110 CA code) caches > both. But in this case it had to because all data had to be moved > through DEBI/AV7110. Still, you can use it for any link layer > implementation which is driven by polling the CAM states.
Ahh cool, I didn't know about _that_ dvb_ca.c 'cos it isn't in the linuxtv linux-dvb tree. As you say, it looks like I can use that. The dvb_ca.c :) that I've written luckily just contains all the generic bits I need that your dvb_ca.c doesn't (CAM initialisation, attribute parsing etc). I hadn't got on to writing the higher level link layer stuff yet. It sounds like I should merge the two together. I assume you won't mind dvb_ca.c from your tree being added to the linuxtv tree, as long as licenses, copyrights etc are preserved? Out of interest, if a CI module has two slots, and you're using read()/write() to communicate, how do you know which slot to talk to? The ca.h in the linuxtv dvb-kernel implies that there is ONE ca device for each CI module, and you select the slot you want when you send the IOCTLS.... whereas if you're using read/write it would be more natural to create a seperate ca devive for each slot..? -- Info: To unsubscribe send a mail to [EMAIL PROTECTED] with "unsubscribe linux-dvb" as subject.
