Mailing List archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



> > > 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.

What is the point of using the ->write() callback then, instead of just
passing a ptr to the buffer to fill?  That adds complexity for no reason
and also is confusing as I'd expect a ->write() callback actually write
the stuff.

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

I don't think it is that useful, there are some corner cases where
you'll run into trouble with that approach.  The mt352 can only handle
the simple 4-byte style tuners for example.  Whats wrong with handling
the complex ones like they are handled today?

  Gerd

-- 
#define printk(args...) fprintf(stderr, ## args)




Home | Main Index | Thread Index