Re: [linux-pm] Re: [RFC] Driver States
Hi! > > > > You have a few things here that can easily conflict, and that will be > > > > developed at different paces. I like the direction that it's going, but > > > > how do you intend to do it gradually. I.e. what to do first? > > > > > > I think the first step would be for us to all agree on a design, whether > > > it be this one or another, so we can began planning for long term > > > changes. > > > > > > My arguments for these changes are as follows: > > > > 0. I do not see how to gradually roll this in. > > > > > 4. Having responsibilities at each driver level encourages a > > > layered and object based design, reducing code duplication and > > > complexity. > > > > Unfortunately, you'll be retrofiting this to existing drivers. AFAICS, > > trying to force existing driver to "layered and object based design" > > can only result in mess. > > Pavel > > Fair enough. How does this sound? I'd like to add "*attach" and > "*detach" to "struct device_driver". These functions would act as one > time initializers and decontructors. Then we could rename "*probe" to > "*start", and "*remove" to "*stop", which should be rather trivial to I do not think you'll find rename across all the drivers easy. You could get away with "I create start, and if it does not exist, probe is called instead", but you need pretty good justification for that, too. Pavel -- Boycott Kodak -- for their patent abuse against Java. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-pm] Re: [RFC] Driver States
Hi! You have a few things here that can easily conflict, and that will be developed at different paces. I like the direction that it's going, but how do you intend to do it gradually. I.e. what to do first? I think the first step would be for us to all agree on a design, whether it be this one or another, so we can began planning for long term changes. My arguments for these changes are as follows: 0. I do not see how to gradually roll this in. 4. Having responsibilities at each driver level encourages a layered and object based design, reducing code duplication and complexity. Unfortunately, you'll be retrofiting this to existing drivers. AFAICS, trying to force existing driver to layered and object based design can only result in mess. Pavel Fair enough. How does this sound? I'd like to add *attach and *detach to struct device_driver. These functions would act as one time initializers and decontructors. Then we could rename *probe to *start, and *remove to *stop, which should be rather trivial to I do not think you'll find rename across all the drivers easy. You could get away with I create start, and if it does not exist, probe is called instead, but you need pretty good justification for that, too. Pavel -- Boycott Kodak -- for their patent abuse against Java. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-pm] Re: [RFC] Driver States
On Tue, 2005-04-05 at 11:24 +0200, Pavel Machek wrote: > Hi! > > > > You have a few things here that can easily conflict, and that will be > > > developed at different paces. I like the direction that it's going, but > > > how do you intend to do it gradually. I.e. what to do first? > > > > I think the first step would be for us to all agree on a design, whether > > it be this one or another, so we can began planning for long term > > changes. > > > > My arguments for these changes are as follows: > > 0. I do not see how to gradually roll this in. > > > 4. Having responsibilities at each driver level encourages a > > layered and object based design, reducing code duplication and > > complexity. > > Unfortunately, you'll be retrofiting this to existing drivers. AFAICS, > trying to force existing driver to "layered and object based design" > can only result in mess. > Pavel Fair enough. How does this sound? I'd like to add "*attach" and "*detach" to "struct device_driver". These functions would act as one time initializers and decontructors. Then we could rename "*probe" to "*start", and "*remove" to "*stop", which should be rather trivial to fix up. From there drivers could slowly be converted to use "*attach" and "*detach", but will not be broken along the way. So the basic flow would be like this: 1.) a driver is bound to a device 2.) *attach is called to allocate data structures 3.) *start when it's time to probe the device 4.) *stop when the user disables the device 5.) repeat steps 3 and 4 any number of times 6.) *detach is called when unbinding the driver The driver layering stuff could come later, but just implementing these specific components would have immediate benefits. In this early stage in development, I'd like to at least be able to start and stop drivers for reasons outside of power management (ex. user preference or resource re-balancing). If a "*resume" function can also utilize this functionality, then all the better. Thanks, Adam - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-pm] Re: [RFC] Driver States
On Tue, 2005-04-05 at 11:24 +0200, Pavel Machek wrote: Hi! You have a few things here that can easily conflict, and that will be developed at different paces. I like the direction that it's going, but how do you intend to do it gradually. I.e. what to do first? I think the first step would be for us to all agree on a design, whether it be this one or another, so we can began planning for long term changes. My arguments for these changes are as follows: 0. I do not see how to gradually roll this in. 4. Having responsibilities at each driver level encourages a layered and object based design, reducing code duplication and complexity. Unfortunately, you'll be retrofiting this to existing drivers. AFAICS, trying to force existing driver to layered and object based design can only result in mess. Pavel Fair enough. How does this sound? I'd like to add *attach and *detach to struct device_driver. These functions would act as one time initializers and decontructors. Then we could rename *probe to *start, and *remove to *stop, which should be rather trivial to fix up. From there drivers could slowly be converted to use *attach and *detach, but will not be broken along the way. So the basic flow would be like this: 1.) a driver is bound to a device 2.) *attach is called to allocate data structures 3.) *start when it's time to probe the device 4.) *stop when the user disables the device 5.) repeat steps 3 and 4 any number of times 6.) *detach is called when unbinding the driver The driver layering stuff could come later, but just implementing these specific components would have immediate benefits. In this early stage in development, I'd like to at least be able to start and stop drivers for reasons outside of power management (ex. user preference or resource re-balancing). If a *resume function can also utilize this functionality, then all the better. Thanks, Adam - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-pm] Re: [RFC] Driver States
Hi! > > You have a few things here that can easily conflict, and that will be > > developed at different paces. I like the direction that it's going, but > > how do you intend to do it gradually. I.e. what to do first? > > I think the first step would be for us to all agree on a design, whether > it be this one or another, so we can began planning for long term > changes. > > My arguments for these changes are as follows: 0. I do not see how to gradually roll this in. > 4. Having responsibilities at each driver level encourages a > layered and object based design, reducing code duplication and > complexity. Unfortunately, you'll be retrofiting this to existing drivers. AFAICS, trying to force existing driver to "layered and object based design" can only result in mess. Pavel -- People were complaining that M$ turns users into beta-testers... ...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl! - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-pm] Re: [RFC] Driver States
Hi! You have a few things here that can easily conflict, and that will be developed at different paces. I like the direction that it's going, but how do you intend to do it gradually. I.e. what to do first? I think the first step would be for us to all agree on a design, whether it be this one or another, so we can began planning for long term changes. My arguments for these changes are as follows: 0. I do not see how to gradually roll this in. 4. Having responsibilities at each driver level encourages a layered and object based design, reducing code duplication and complexity. Unfortunately, you'll be retrofiting this to existing drivers. AFAICS, trying to force existing driver to layered and object based design can only result in mess. Pavel -- People were complaining that M$ turns users into beta-testers... ...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl! - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] Driver States
On Sun, 27 Mar 2005, Adam Belay wrote: > Dynamic power management may require devices and drivers to transition > between various physical and logical states. I would like to start a > discussion on how these might be defined at the bus, driver, and class > levels. > Bus Level > = > At the bus level, there are two state attributes, power and > enable/disable. Enable/disable may mean different things on different > buses, but they generally refer to resource decoding. A device can only > be enabled during a non-off power state. <...> > Driver Level > > At the driver level there are two areas of interest, physical and > logical state. There is an additional concern of transitioning between > these states multiple times. Because a driver acts as a bridge between > physical and logical components, I think separating these steps seems > natural. <...> > *attach - allocates data structures, creates sysfs entries, prepares driver >to handle the hardware. > > *start - Sets up device resources and configures the hardware. Loads > firmware, etc. > (physical) > > *open - engages the hardware, and makes it usable by the class device. > (logical and physical) > > *close - disengages the hardware, and stops class level access > (logical and physical) > > *stop - physically disables the hardware > (physical) > > *detach - tears down the driver and releases it from the "struct device" > You have a few things here that can easily conflict, and that will be developed at different paces. I like the direction that it's going, but how do you intend to do it gradually. I.e. what to do first? Pat - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] Driver States
On Sun, 27 Mar 2005, Adam Belay wrote: Dynamic power management may require devices and drivers to transition between various physical and logical states. I would like to start a discussion on how these might be defined at the bus, driver, and class levels. snip Bus Level = At the bus level, there are two state attributes, power and enable/disable. Enable/disable may mean different things on different buses, but they generally refer to resource decoding. A device can only be enabled during a non-off power state. ... Driver Level At the driver level there are two areas of interest, physical and logical state. There is an additional concern of transitioning between these states multiple times. Because a driver acts as a bridge between physical and logical components, I think separating these steps seems natural. ... *attach - allocates data structures, creates sysfs entries, prepares driver to handle the hardware. *start - Sets up device resources and configures the hardware. Loads firmware, etc. (physical) *open - engages the hardware, and makes it usable by the class device. (logical and physical) *close - disengages the hardware, and stops class level access (logical and physical) *stop - physically disables the hardware (physical) *detach - tears down the driver and releases it from the struct device You have a few things here that can easily conflict, and that will be developed at different paces. I like the direction that it's going, but how do you intend to do it gradually. I.e. what to do first? Pat - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[RFC] Driver States
Dynamic power management may require devices and drivers to transition
between various physical and logical states. I would like to start a
discussion on how these might be defined at the bus, driver, and class
levels.
Bus Level
=
At the bus level, there are two state attributes, power and
enable/disable. Enable/disable may mean different things on different
buses, but they generally refer to resource decoding. A device can only
be enabled during a non-off power state.
A possible API:
struct bus_type {
char* name;
struct subsystemsubsys;
struct kset drivers;
struct kset devices;
struct bus_attribute* bus_attrs;
struct device_attribute * dev_attrs;
struct driver_attribute * drv_attrs;
int (*match)(struct device * dev, struct device_driver *
drv);
int (*hotplug) (struct device *dev, char **envp,
int num_envp, char *buffer, int
buffer_size);
int (*suspend)(struct device * dev, pm_message_t state);
int (*resume)(struct device * dev);
int (*enable)(struct device * dev);
int (*disable)(struct device * dev);
};
Driver Level
At the driver level there are two areas of interest, physical and
logical state. There is an additional concern of transitioning between
these states multiple times. Because a driver acts as a bridge between
physical and logical components, I think separating these steps seems
natural.
A possible API:
struct device_driver {
char* name;
struct bus_type * bus;
struct semaphoreunload_sem;
struct kobject kobj;
struct list_headdevices;
struct module * owner;
int (*attach) (struct device * dev);
int (*start)(struct device * dev);
int (*open) (struct device * dev);
int (*close)(struct device * dev);
void(*stop) (struct device * dev);
void(*detach) (struct device * dev);
void(*shutdown) (struct device * dev);
int (*suspend) (struct device * dev, u32 state, u32 level);
int (*resume) (struct device * dev, u32 level);
};
*attach - allocates data structures, creates sysfs entries, prepares driver
to handle the hardware.
*start - Sets up device resources and configures the hardware. Loads
firmware, etc.
(physical)
*open - engages the hardware, and makes it usable by the class device.
(logical and physical)
*close - disengages the hardware, and stops class level access
(logical and physical)
*stop - physically disables the hardware
(physical)
*detach - tears down the driver and releases it from the "struct device"
The idea behind *attach and *detach is to move code that would only need
to be called once out of *probe and *remove.
A table could be defined that indicates what should be called for each
power level transition. *suspend and *resume could handle any extra
steps (ex. saving state). As an example, *start and *stop may only be
called when power is going to be lost entirely.
Additional states are class specific and would only be used after *open
is called.
Class Level
===
At the class level, we could have a simple start/stop mechanism.
A possible API:
struct class_device {
struct list_headnode;
struct kobject kobj;
struct class* class;
struct device * dev;
void* class_data;
charclass_id[BUS_ID_SIZE];
int (*attach) (struct device * dev);
int (*start)(struct device * dev);
void(*stop) (struct device * dev);
void(*detach) (struct device * dev);
};
*attach - allocates data structures, creates sysfs entries, prepares
class to handle the device.
*start - start the logical class device, accept userspace interaction
*stop - stop the logical class device, deny userspace interaction
*detach - tear down the class driver's bindings with this class device
These are just rough ideas. I look forward to any comments or
alternative approaches.
Thanks,
Adam
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[RFC] Driver States
Dynamic power management may require devices and drivers to transition
between various physical and logical states. I would like to start a
discussion on how these might be defined at the bus, driver, and class
levels.
Bus Level
=
At the bus level, there are two state attributes, power and
enable/disable. Enable/disable may mean different things on different
buses, but they generally refer to resource decoding. A device can only
be enabled during a non-off power state.
A possible API:
struct bus_type {
char* name;
struct subsystemsubsys;
struct kset drivers;
struct kset devices;
struct bus_attribute* bus_attrs;
struct device_attribute * dev_attrs;
struct driver_attribute * drv_attrs;
int (*match)(struct device * dev, struct device_driver *
drv);
int (*hotplug) (struct device *dev, char **envp,
int num_envp, char *buffer, int
buffer_size);
int (*suspend)(struct device * dev, pm_message_t state);
int (*resume)(struct device * dev);
int (*enable)(struct device * dev);
int (*disable)(struct device * dev);
};
Driver Level
At the driver level there are two areas of interest, physical and
logical state. There is an additional concern of transitioning between
these states multiple times. Because a driver acts as a bridge between
physical and logical components, I think separating these steps seems
natural.
A possible API:
struct device_driver {
char* name;
struct bus_type * bus;
struct semaphoreunload_sem;
struct kobject kobj;
struct list_headdevices;
struct module * owner;
int (*attach) (struct device * dev);
int (*start)(struct device * dev);
int (*open) (struct device * dev);
int (*close)(struct device * dev);
void(*stop) (struct device * dev);
void(*detach) (struct device * dev);
void(*shutdown) (struct device * dev);
int (*suspend) (struct device * dev, u32 state, u32 level);
int (*resume) (struct device * dev, u32 level);
};
*attach - allocates data structures, creates sysfs entries, prepares driver
to handle the hardware.
*start - Sets up device resources and configures the hardware. Loads
firmware, etc.
(physical)
*open - engages the hardware, and makes it usable by the class device.
(logical and physical)
*close - disengages the hardware, and stops class level access
(logical and physical)
*stop - physically disables the hardware
(physical)
*detach - tears down the driver and releases it from the struct device
The idea behind *attach and *detach is to move code that would only need
to be called once out of *probe and *remove.
A table could be defined that indicates what should be called for each
power level transition. *suspend and *resume could handle any extra
steps (ex. saving state). As an example, *start and *stop may only be
called when power is going to be lost entirely.
Additional states are class specific and would only be used after *open
is called.
Class Level
===
At the class level, we could have a simple start/stop mechanism.
A possible API:
struct class_device {
struct list_headnode;
struct kobject kobj;
struct class* class;
struct device * dev;
void* class_data;
charclass_id[BUS_ID_SIZE];
int (*attach) (struct device * dev);
int (*start)(struct device * dev);
void(*stop) (struct device * dev);
void(*detach) (struct device * dev);
};
*attach - allocates data structures, creates sysfs entries, prepares
class to handle the device.
*start - start the logical class device, accept userspace interaction
*stop - stop the logical class device, deny userspace interaction
*detach - tear down the class driver's bindings with this class device
These are just rough ideas. I look forward to any comments or
alternative approaches.
Thanks,
Adam
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
