[linux-dvb] Re: refactoring

[John Dalgliesh <johnd@defyne.org>]

On Mon, 11 Oct 2004, Andrew de Quincey wrote:
> On Monday 11 Oct 2004 13:20, Andrew de Quincey wrote:
> > On Monday 11 Oct 2004 13:14, Johannes Stezenbach wrote:
> > > On Mon, Oct 11, 2004 at 12:32:45PM +0100, Andrew de Quincey wrote:
> > > > On Monday 11 Oct 2004 12:29, Johannes Stezenbach wrote:
> > > > > Well, if the i2c bus and the devices on the bus aren't exposed
> > > > > at all in sysfs, then the DVB adapter driver could take care
> > > > > of it when called via PCI bus power management hooks. I don't
> > > > > think this is a good design, but it would work for PCI cards.
> > > >
> > > > I'm only talking about not exposing the bits of the frontend - exposing
> > > > the i2c bus is fine - you might have self-contained devices on it that
> > > > it makes sense for userspace to see (e.g. EEPROMs, analogue tv tuners).
> > >
> > > 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.

The way I accomplish this is that when a demod is probed and started, it
turns its switch on and asks the i2c bus owner to rescan (for PLLs). The
i2c bus owner remembers the driver that asked it to rescan, and tells it
to turn its switch on and off as appropriate when the PLL driver wants to
talk to its device.

Devices on the bus are stored in a vector in order of probing. Shutdown is
done in reverse order. So anything new found with the bus switch on is
automatically put to sleep / terminated before the thing that allowed it
to be found.

Lots of good reasons why this is not a perfect system (e.g. tight coupling
between demod and PLL settings) but it works for me so far.

{P^/