lkml.org 
[lkml]   [2003]   [Aug]   [28]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectPlatform Devices

Sorry it's taken so long to reply, this has needed a chance to sink in
(and for other things to be resolved).

> I think we need to expand the platform device support to include the
> notion of platform drivers. For example:
>
> struct platform_driver {
> int (*probe)(struct platform_device *);
> int (*remove)(struct platform_device *);
> int (*suspend)(struct platform_device *, u32);
> int (*resume)(struct platform_device *);
> struct device_driver drv;
> };

I see two ways of supporting platform devices that will have a variable
number of logical interfaces -- depending on the platform -- per physical
device, and support power management on them.

The first: put power management methods in struct class.

As we suspend each physical device, we would loop over each class device
that is associated with the physical device, and call its class's
->suspend() method for it. The class would be responsible for stopping the
device and taking that view of the device offline. The class-specific
portion of the driver may optionally have suspend()/resume() methods that
the class could call to save those bits of device state.

This would leave the bus-specific power management calls to only power
down the device and save config-space-like register state of the device.
(Especially if there were per-driver class-specific suspend/resume
methods, as they would be responsible for saving/restoring the interesting
parts of the device.)


The second: Allow mulitple drivers to bind to platform devices.

We would use a similar structure as you have above, with a struct
list_head in it to allow us to chain them together. When we suspended a
platform device, the platform bus would iterate through each driver that's
bound to a device and call ->suspend().

Simple enough, though we'd have to create some sort of notion of a
'platform_class' for each device type, as there could theoretically be
multiple instances of a device type, and a chain of drivers could only
bind to one without dynamically allocating each instance of the driver. It
would be similar to the way system devices are handled, but without
breaking away from the unified device hierarchy.

Either way is relatively easy to implement, and I'm ambivalent about which
to choose this morning. The former may have much added benefit by reducing
the amount of work that needs to be done in each driver of each type,
while the latter focuses on just resolving your issue..


Pat


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

\
 
 \ /
  Last update: 2005-03-22 13:48    [from the cache]
©2003-2011 Jasper Spaans