Mailing List archive

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

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



> I see. You want to suspend the whole system with DVB apps running, and
> on resume it should restore all state without the app doing anything
> for it.

Exactly.  Thats the main point of the suspend/resume support in the
drivers.  Without dvb apps running it's easy, you can just unload/reload
the driver modules.

> I haven't spent any time thinking about that, but I would've hoped
> that the dvb-core would take care of reinitializing the frontend on
> wakeup. That should best be implemented in the dvb_frontend_thread().

I'm not that familiar with the fe core code, but I think it should be
doable that way as well.  With a dvb_fe_suspend() function basically
calling fe->sleep() and dvb_fe_resume() calling fe->init() + kick the
dvb fe thread for retuning.  That assumes that fe->init() will reload
the firmware, not sure whenever that is actually true.

Implementing that completely in the thread isn't going to work I think.
IIRC the threads are already froozen when the pm code walks down the
device tree and suspends the devices.

> You sent me a patch that touches nearly every line in cx22702.c
> and reworks everything unecessarily (IMHO).

It's simply because it was forked away _long_ ago, before the fe
refactoring, and in fact I did some of the experiments for the
refactoring with that driver.  If you check the list archives you
should find some cx22702 code snippets in the discussion threads.

Switching over to i2c_client and the releated cleanups was one of the
first things I did.  Later when adapting to the new, refactored frontend
interface I just kicked out the autoprobing.

> I'm waiting for a smaller patch that does just what is really needed.

I still don't see the point.  The driver has the new, refactored
interface like all other ones.  It doesn't do evil autoprobing.  It's
actually tested (unlike the one currently in linuxtv cvs which is unused
at least since the refactoring).  What exactly your worries?

Dropping the powermanagement stuff which would'nt be needed when the
core handles that will make the diff a bit smaller.  I can also put the
config stuff into a struct instead of passing it as parameters to make
it more close to the current linuxtv code.

But I don't want to start over from scratch with a code base where I
don't even know whenever it works or not, which I would have to to
create a minimal patch.

  Gerd

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




Home | Main Index | Thread Index