Mailing List archive

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

[linux-dvb] Re: refactoring



On Monday 11 Oct 2004 14:30, Gerd Knorr wrote:
> On Mon, Oct 11, 2004 at 01:26:04PM +0100, Andrew de Quincey wrote:
> > > > Then I suspect we might run into problems when the power management
> > > > core decides to power down busses in the wrong order. Well, on PCI
> > > > cards one could make the i2c adapter shutdown a noop, and do the i2c
> > > > shutdown when the PCI adapter is shutdown. On embedded you have
> > > > no such luck. You must power down the demod/PLL before the
> > > > i2c bus goes to sleep. (There'll be probable ways to kludge
> > > > around this, but it will never be clean&simple.)
> > >
> > > Urgh, there is no nice solution to this. What is the least nasty?
> >
> > For that matter, how do you control the order in which i2c devices on a
> > single bus are shut down? You'd have to shut down the PLL before the
> > demod, in order to be able to use the demod's i2c bus switch.
>
> My cx22702 driver does the suspend/resume simply in the demod
> powermanagement handlers.  Code isn't tested yet through, I'm somehow
> too busy writing mails these days ...
>
> The ordering of the devices within the bus doesn't matter.  The
> important point is that the ordering of the devices and the bus itself
> is correct (i.e. first suspend the i2c devices, then the PCI (or
> whatever) device the i2c bus is connected through).  Thus you can be
> sure you can access the i2c bus within the suspend/resume handlers.

I'm actually running out of time - I have another major project starting in a 
couple of days. I'll finish off the porting to a function based API - and 
I'll have some time to do some stuff, but someone else is going to have to do 
the suspend/resume/i2c exposure stuff if you want it.




Home | Main Index | Thread Index