> > > > > Dear Oliver, > > > > > > I?ve done some tests with the CAM reader from Digital Devices based on > > Sony > > > CXD2099 chip and I noticed some issues with some CAM: > > > * SMIT CAM : working fine > > > * ASTON CAM : working fine, except that it's crashing quite > > regularly > > > * NEOTION CAM : no stream going out but access to the CAM menu is ok > > > > > > When looking at the CXD2099 driver code, I noticed the CAM clock > > > (fMCLKI) > > is > > > fixed at 9MHz using the 27MHz onboard oscillator and using the integer > > > divider set to 3 (as MCLKI_FREQ=2). > > > > > > I was wondering if some CAM were not able to work correctly at such > > > high clock frequency. > > > > > > So, I've tried to enable the NCO (numeric controlled oscillator) in > > > order > > to > > > setup a lower frequency for the CAM clock, but I wasn't successful, > > > it's looking like the frequency must be around the 9MHz or I can't get > > > any stream. > > > > > > Do you know a way to decrease this CAM clock frequency to do some > > testing? > > > > > > Best regards, > > > Sebastien. > > > > Weird that the frequency would pose a problem for those CAMs. The CI > > spec [1] explains that the minimum byte transfer clock period must be > > 111ns. This gives us a frequency of ~9MHz. > > > > You're totally right about the maximum clock frequency specified in the > norm, but I had confirmation from CAM manufacturers that their CAM may not > work correctly up to this maximum frequency. > > Usually, the CAM clock is coming from the input TS stream and I don't think > there is for now a DVB-S2 transponder having a 72mbps bitrate (so a 9MHz for > parallel CAM clocking). > > > Anyway, wouldn't it be wiser to base MCLKI on TICLK ? > > > > I've tried to use mode C instead of mode D, and I have the same problem, so > I guess TICLK is around 72MHz. > > It could be a good idea to use TICLK, but I don't know the value and if the > clock is constant or only active during data transmission. > > > Did you manage to enable and use the NCO of the CXD2099 (instead of the > integer divider) ? No, but if your output to the CAM is slower than what comes from the ngene chip, you will lose bytes, no ? -- 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
