RE: [DVB] CXD2099 - Question about the CAM clock

["Sébastien RAILLARD (COEXSI)" <sr@coexsi.fr>]

> -----Original Message-----
> From: linux-media-owner@vger.kernel.org [mailto:linux-media-
> owner@vger.kernel.org] On Behalf Of Sébastien RAILLARD (COEXSI)
> Sent: lundi 3 octobre 2011 16:46
> To: 'Issa Gorissen'; o.endriss@gmx.de
> Cc: 'Linux Media Mailing List'
> Subject: RE: [DVB] CXD2099 - Question about the CAM clock
> 
> 
> 
> > -----Original Message-----
> > From: Issa Gorissen [mailto:flop.m@usa.net]
> > Sent: lundi 3 octobre 2011 15:59
> > To: o.endriss@gmx.de; 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@vger.kernel.org More majordomo
> info at  http://vger.kernel.org/majordomo-info.html