Re: PCI PM & compatibility

[Patrick Mochel]

> When a device "A" is registered with the driver model, we call
> device_add().  This adds the device to the bus, which calls any
> registered driver methods.  Once the device has been added to the
> bus, we add the device to the tail of the device power list.
> 
> In the case where a device driver for device "A" registers further
> devices, which are siblings of device "A", two things can happen:
> 
>  - If a driver is already registered for the device, we call its
>    probe method before we have added device "A" to the power lists.
>    Therefore, the siblings will be added to the tail of the device
>    power list _before_ the device "A" has been added.
> 
>  - If the driver registers after the device, the device "A" will be
>    added to the power list _before_ the siblings.
> 
> So in one case, we have PARENT SIBLING SIBLING SIBLING and in the
> other case we have SIBLING SIBLING SIBLING PARENT.

I haven't been ignoring you. I've been trying to figure exactly what 
you're talking about. Do you have a concrete example? Is it some PCMCIA 
driver, or some platform driver? 

I fail to see the problem, in theory, besides the driver itself. In the
case where the driver registers first, ->probe() will not be called until
it matches a device, which implies the device will have been added before
->probe() is called.

Also, I think I initially misunderstood your vocabulary. Each SIBLING is a
sibling of one another, but are CHILDREN of the PARENT. Right?

> Now, we do have this pm_users thing which seems to imply that it
> describes the relationship between two devices.  However, its non-
> functional.  It operates on a per-device variable called "pm_users"
> which is only ever _written_ !

Hey, I hadn't finished that part, because I considered fixing the system 
power management interface more important that day. 

It works like this: 

- A driver is able to set ->power.pm_parent for a device by calling 
  device_pm_set_parent() after its registered. By default, pm_parent is 
  set to the phsyical parent of the device. 

- A device with other devices that are dependent on it for power has a 
  positive pm_users count. 

- A device may only be suspended when pm_users == 0. 

- When a device is suspended, the pm_users count of its pm_parent is 
  decremented, and incremented when the device is resumed. 

- device_suspend() makes multiple passes over the device list, in case
  power dependencies cause some devices to be deferred. It fails with an 
  error (and resumes all suspended devices) if a pass was made in which 
  no devicse were suspended, but there are still devices with a positive
  pm_users count. 

Sound good? 


	Pat

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/