> If it were as complicated as you say, userspace would be the right > place. But we have the av7110 firmware implementation, and a proprietary > STB driver, and while it is admittedly not simple there is *no* locking at > all. Because CI is essentially driven by polling (the CAM cannot send > data spontaneously, the host has to poll for data). > > Also note, the av7110 implementatton uses a single 64K buffer for all > fragments, and that seems quite sufficent. The list handling for fragment > reassembly is not easy though. > > It works approximately like this: > > o send TPDU to CAM: > - fragment TPDU to negotiated fragment size and put in list > o receive TPDU from CAM: > - wait on ringbuffer wait queue > o poll CAM (from kernel thread or similar): > - receive fragments from CAM and put in list > - send fragments from list to CAM > - check received fragments in list for completed TPDU > and put in ringbuffer
Yeah, thats pretty much how mine works, except I also support read/write IRQs from the CAM (the one I have supports them). Its the complex list handling for fragment reassembly thats the bit I don't see any reason for having cluttering up the kernel. Theres no high bandwidth data being transferred, so theres no real gain in doing in the kernel. However, in the av7110 instance, I can see that perhaps there were other reasons it was done in the firmware, but those are not necessarily the case here. The extra locking in mine is because it is intended to be a generic API implementation for CA devices, along the lines of the other parts of dvb_core, so I cannot make any assumptions about any particular device. Note that the implementation is pefectly happy with dealing with the av7110-style defragmented packets as well, so it could be used to replace the current av7110 opensource CA code with the generic API implementation. I can write sample userspace code for doing the defragmentation if that would help people (I've already released a partial version of it, so I can release that fine). -- Info: To unsubscribe send a mail to [EMAIL PROTECTED] with "unsubscribe linux-dvb" as subject.
