Re: Solving suspend-level confusion

From: David Brownell
Date: Sat Jul 31 2004 - 19:46:08 EST


On Saturday 31 July 2004 10:01, Oliver Neukum wrote:
>
> Maybe a better approach would be to describe the required features to
> the drivers rather than encoding them in a single integer. Rather
> like passing a request that states "lowest power level with device state
> retained, must not do DMA, enable remote wake up"

A pointer to some sort of struct could be generic and typesafe;
better than an integer or enum.

// <linux/device.h>
struct device {
... unchanged; but fix or remove this:
struct dev_pm_state *power_state;
...
};

// <linux/pm.>
struct dev_pm_state {
char *name;
unsigned number;
// maybe more
};
struct dev_pm_info {
struct dev_pm_state *power_state;
struct dev_pm_state **supported;
unsigned could_wakeup:1;
unsigned should_wakeup:1;
... plus the rest
};

There would be bus-specific rules about how those get used,
for example what device power states exist.

// <linux/pci.h>
extern const struct dev_pm_state PCI_D0, PCI_D1, PCI_D2,
PCI_D3cold, PCI_D3hot;

... eventually signatures change:
struct pci_driver {
int (*suspend) (struct pci_dev *dev, struct dev_pm_state *state);
int (*enable_wake) (struct pci_dev *dev, struct dev_pm *state,
int enable);
};
int pci_set_power_state(struct pci_dev *dev, struct dev_pm *state);
int pci_enable_wake(struct pci_dev *dev, struct dev_pm *state, int enable);

// <asm/arch/bus.h>
... support for whatever non-PCI device states work here
... maybe even special states for the platform's busses:
struct mybus_dev_pm_state {
struct dev_pm_state public;
// private state: clock hooks, power switches,
// linkage to devices sharing clock or power, etc
};

So for example maybe dev->power.power_state == PCI_D0, and
dev->power->supported == { PCI_D0, PCI_D3hot, PCI_D3cold, NULL }
on some controller, and sysfs would say "D3hot" not "3" (or "2" or
whatever). Other busses would report different states..

- Dave
-
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/