> -----Original Message----- > From: linux-media-owner@xxxxxxxxxxxxxxx [mailto:linux-media- > owner@xxxxxxxxxxxxxxx] On Behalf Of Sébastien RAILLARD (COEXSI) > Sent: lundi 3 octobre 2011 16:46 > To: 'Issa Gorissen'; o.endriss@xxxxxx > Cc: 'Linux Media Mailing List' > Subject: RE: [DVB] CXD2099 - Question about the CAM clock > > > > > -----Original Message----- > > From: Issa Gorissen [mailto:flop.m@xxxxxxx] > > Sent: lundi 3 octobre 2011 15:59 > > To: o.endriss@xxxxxx; Sébastien RAILLARD > > Cc: 'Linux Media Mailing List' > > Subject: RE: [DVB] CXD2099 - Question about the CAM clock > > > > > > > > > > > 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 ? > > The real bandwidth of my transponder is 62mbps, so I've room to decrease > the CAM clock. > > I did more tests with the NCO, and I've strange results: > * Using MCLKI=0x5553 => fMCLKI= 8,99903 => Not working, a lot of TS > errors > * Using MCLKI=0x5554 => fMCLKI= 8,99945 => Working fine > * Using MCLKI=0x5555 => fMCLKI= 8,99986 => Not working, a lot of TS > errors > > It's strange that changing very slightly the clock make so much errors! > I managed to find a series of values that are working correctly for MCLKI: MCLKI = 0x5554 - i * 0x0c In my case I can go down to 0x5338 before having TS errors. > > -- > 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 -- 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
