[linux-dvb] Re: [rfc/patch] pll handling and cx22702 update

[Andrew de Quincey <adq_dvb@lidskialf.net>]

On Monday 03 Jan 2005 10:31, Gerd Knorr wrote:
> [ ... back from xmas holidays ... ]
>
>   Hi,
>
> happy new year to everyone ;)
>
> > Lemme know what you think...
> >
> > static int tuner_generic_init(struct dvb_tuner_desc* desc, dvb_tuner_ops*
> > ops) {
> >  u8* buf;
> >
> >  buf = alloca(desc->tuner_data_size);
> >  if (buf == NULL)
> >   return -ENOMEM;
> >
> >  memcpy(buf, desc->init_data, desc->tuner_data_size);
> >  return ops->write(desc, ops, 0, buf, desc->tuner_data_size);
> > }
>
> The ops->write() scares me, I think that isn't going to work with
> mt352-based frontends.

Hmm, not really an issue - the implementation of write() will just copy the 
appropriate data into the array supplied by pll_set() in struct mt352_config.

> I *intentionally* havn't done it that way but let the generic code
> just calculate the four bytes needed to program the tuners and *nothing*
> else.
>
> Also note that I just want catch the 90% of the tuners which can be
> driven that way with 4-byte command sequences.  There is also no point
> in squezzing *every* tuner into that model, that will vanish the
> advantages because it becomes to complex then (see the dynamic memory
> alloc stuff you've started doing for example).  

I tried to keep it so the simple tuners could be represented simply, yet it 
was flexible enough for the more complex ones too. 

As for dynamic memory allocation being overly complex - this is an 
implementation issue in my sample code which I said did not compile. It is 
going to be replaced with a static buffer anyway as alloca() isn't in the 
kernel.