On 16-01-08 18:46, Bjorn Helgaas wrote:
On Tuesday 15 January 2008 12:51:35 am Jaroslav Kysela wrote:
Ok, something to explain. These flags exists to allow drivers to
manually configure (override) PnP resources at init time - we know - for
example in ALSA - that some combinations simply does not work for all
soundcards.
The DISABLE flags simply tells core PnP layer - driver will handle
resource allocation itself, don't do anything, just disable hw physically
and do not change (allocate) any resources. Value 0x03 is valid in this
semantics.
It looks like sound drivers use PNP_DRIVER_RES_DISABLE to say "ignore
what PNP tells us about resource usage and we'll just use the compiled-
in or command-line-specified resources".
The main reason to do that would be to work around BIOS defects or
to work around deficiencies in the Linux PNP infrastructure (e.g.,
maybe we erroneously place another device on top of the sound card
or something).
I'm just suspicious because PNP_DRIVER_RES_DISABLE is only used in
sound drivers. If it's to work around BIOS defects, why wouldn't
other PNP drivers need it sometimes, too? And wouldn't it be better
to use PNP quirks for BIOS workarounds?
Yes. The manual resource setting was recently removed from the ALSA drivers
and I'd expect this can now go as a package-deal.
Unfortunately, suspend / resume complicates things a bit, but PnP core can
handle DO_NOT_CHANGE flag. But it will just mean - _preserve_ resource
allocation from last suspend state for this device and enable hw
physically before calling resume() callback.
When resuming, wouldn't we *always* want to preserve the resource
allocation from the last suspend, regardless of whether
PNP_DRIVER_RES_DO_NOT_CHANGE is specified?
Yes.
Linux PNP definitely has issues with suspend/resume, and I suspect
this is one of them.
Rene.
_______________________________________________
linux-pm mailing list
linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx
https://lists.linux-foundation.org/mailman/listinfo/linux-pm
