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