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

[Johannes Stezenbach <js@linuxtv.org>]

On Sat, Jan 29, 2005 at 08:50:02PM +0100, Gerd Knorr wrote:
> > Hm, if the i2c subsystem knows about your clients (it has to
> > because of pm, no?) how do you prevent it from probing for
> > you clients when a new i2c bus appears?
...
> There simply is no i2c_driver->attach_adapter callback, thus all the
> autoprobe magic in steps (2) ... (4) is skipped altogether.  The
> cx22702_create() just fills in a i2c_client structs with the config info
> passed by the dvb adapter driver, veryfies it can actually talk to the
> device, then calls i2c_attach_client() to tell the i2c core "Hey, I
> have a device here".  No address probing/scanning at all.

OK, thanks for the clarification.

> > Most frontends have the PLL behind the demod, but the i2c subsystem
> > doesn't know this, thus cannot observe the proper order. If it
> > works for cx22702 it is an exception.
> 
> 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. The
decision we made for FE_REFACTORING was to remove pll handling
from the frontend drivers (thus turning them into demod drivers),
and handle plls from the card drivers. Apparently this simplifies
our live.

> > > Another way I could would be to let linux walk down to the physical
> > > device maintaining the dvb_adapter only, and then have some
> > > dvb_adapter_suspend/resume() call which will care about powering down
> > > and rebooting the dvb hardware.  That means we'll have our own
> > > dvb-specific powermanagement stuff wich works much like the device tree,
> > > not sure the guys on lkml will appreciate that ...
> > 
> > It is not necessary, because the point of the new frontend structure
> > was that the adapter drivers *know* the frontend and pll, thus it
> > is easy for them to do pm without walking buses etc.
> 
> 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.

Gerd, I have to ask you again to observe the decisions regarding
frontend driver structure that were made on the linux-dvb mailing
list. If you want your driver to be comitted as-is, then find
someone else to back up your position, because I don't see how I
could commit it and still sleep well ;-/

Johannes