Thanks Randy for the detailed answer.
The framework keeps track of the devices that have
"removable-media" set and the dependencies of these
on /dev/fb.
According to your email, /dev/fb must have a power(9e) entry for
the "removable-media" device to be powered down.
On my tecra M10 laptop, /dev/fb is:
tecra...@opensolaris:/var/sadm$ ls -l /dev/fb
lrwxrwxrwx 1 root root 49 2010-02-08 15:20 /dev/fb ->
/devices/p...@0,0/pci8086,2...@1/disp...@0:nvidia0
Does nvidia have a power(9e) entry?
Does this device-dependency-property of "removable-media" and /dev/fb
work on x86 boxes?
Thanks again,
Margot
On 04/14/10 06:57 PM, Randy Fishel wrote:
On Wed, 14 Apr 2010, Margot Hackett Miller wrote:
Hi All,
I am seeking info about the following property that is in power.conf files on
x86 and Sparc systems.
# This entry keeps removable media from being powered down unless the
# console framebuffer and monitor are powered down # (See
removable-media(9P))
#
device-dependency-property removable-media /dev/fb
I have never seen "device-dependency-property" used with anything other than
"removable-media" and /dev/fb. It looks like it was originally designed just
for removable-media with a dependency on /dev/fb.
Could someone explain the implementation of this? The device driver can
either set removable-media=1 or during a ddi_prop_create() pass in
"removable-media".
Then is it the power management framework that checks to see that when
/dev/fb is powered down, then the removable-media can be powered down?
Pretty much. Effectively, device setting a dependency will not be
power managed till the dependent device has been fully reduced. Note
though, that if the dependent device does not have a power(9e) entry,
the child will never be powered down (this is the message that is
often seen about "/dev/fb keeps up sd, but the former is not power
managed").
How is HAL involved in this or /dev/fb?
HAL is not involved at all (from what I remember, nothing that uses
HAL has a dependancy setting, and does not even have a power setting
that can be managed via the existing framework), and /dev/fb (or
whatever is defined by phys_path) is only involved in that there was
an administrative decision to create the dependency (IOW, /dev/fb is
clueless that this dependency even exists, it is the framework that
remembers it).
Is the driver property "removable-media" only used for power management and
that device?
removable-media is used by storage drivers to specify that the
underlying device has removable media (such as a floppy or CDROM -
note also, that it is applied to USB devices with removable media).
It is effectively a virtual device, and I do not believe it was
implemented for PM, but PM took advantage of the existence of the
property.
I am trying to figure out if this device-dependency-property, which
was implemented about a decade ago, is still being used and needed.
The question here, is if there can be a device PM dependency that
cannot be represented by the device tree? A nexus device won't be
powered off (or even have it's power reduced) while a child is still
on, but might there be a device without a device tree parent/child
relationship (say, a printer connected to a USB port) that desires
that another driver (the USB port to which it is connected) not be
powered down till the device itself is powered down (the example given
doesn't currently impose a problem, since the parts in question don't
implement the entry points necessary for it to be a problem, but it
should describe a possible condition).
FWIW, there will be some dependencies that need to be described
somehow. A good example is devices that are wakers (i.e.
keyboards/mice, WOL/WOR hardware - these should probably not be
powered down, and may require that some devices be directly powered
up), another is iscsi (don't be powering down the network while an
iscsi session is active). The existing interface is crude, and
limited, so there is room for improvement.
Does this answer the questions, or does it actually bring up more?
Cheers!
---- Randy
Thanks for any help,
Margot
_______________________________________________
pm-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/pm-discuss
