[linux-dvb] Re: [patches] cx22702 + mt352 updates

[Gerd Knorr <kraxel@bytesex.org>]

> > Well, there is a tiny trick: the demod suspend handler suspends both
> > pll and demodulator ;)
> 
> That means that the demod driver needs to know the plls.

No, it just sets the frequency to zero.  Not my idea, I've seen that in
several places in the dvb code.  But as it somehow makes sense I've
reused that idea for dvb-pll.c and cx22702.c ...

> > It hasn't to walk the bus, yes.  Instead it has to walk the devices of
> > the dvb adapter and suspend them (frontend, demux, whatelse hardware is
> > present ...).  Not very different.  When doing it that way we'll
> > probably end up calling something like adapter->fe->ops->suspend() in
> > either the adapter drivers directly or in some helper function in the
> > dvb core.  Same for hardware demuxes and whatelse needs powering down.
> 
> fe->ops->sleep() is already there, as we usually power down frontends
> when they aren't used, not just when the whole machine goes to sleep.

Ok, thats the easy part, I could call that from the cx88-dvb suspend
handler as well.  In fact the cx22702 suspend handler just calls the
sleep() function.

That wouldn't work for resume through, as the cx88-dvb doesn't has the
informations needed to restore the cx22702 device state, i.e. the most
recently used tuning parameters.  We probably can get working with some
helper functions in the frontend core through.  So I guess you prefeare
doing it that way?

> Gerd, I have to ask you again to observe the decisions regarding
> frontend driver structure that were made on the linux-dvb mailing
> list.

Well, so far none of your assumtions about the cx22702.c code ignoring
the refactoring turned out to be false.  Be it the autoprobing, or pll
stuff above.  How about looking a bit more carefully the code instead of
blindly shooting just because I'm registering my i2c_clients?

  Gerd

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