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
