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/