Mailing List archive

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

[linux-dvb] Re: refactoring



On Monday 11 Oct 2004 12:29, Johannes Stezenbach wrote:
> On Mon, Oct 11, 2004 at 11:53:31AM +0200, Gerd Knorr wrote:
> > I think Andrew wrote this:
> > > Any frontend configuration files/power management stuff is then
> > > attached to those entries so that the card can bring up the frontend
> > > in its entirety in one go. This also allows for frontends attached to
> > > proprietary weirdy buses that have no standard kernel representation.
> >
> > Wrong approach.  The powermanagement doesn't care about the /dev/class
> > tree (where you register the frontend (unix) device), it walks the
> > physical devices below /dev/devices.  And that is one of the reasons why
> > I think it is a good idea to have the i2c devices in the (physical)
> > device tree.
>
> 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).

> What I'm worried about is how this would work on embedded STBs
> where the i2c bus driver *is* implemented via kernel i2c, and
> we can't change that because there are lots of other devices
> on the bus.

Surely you'd still need some more general type of power management in order to 
restore the state of the non-i2c bits of the frontend as well? 

The other devices would just show up on the bus as normal.




Home | Main Index | Thread Index