Re: -mm: pnp-do-not-stop-start-devices-in-suspend-resume-path.patch breaks resuming isapnp cards
On Wednesday 16 January 2008 18:46:03 Bjorn Helgaas wrote: > On Tuesday 15 January 2008 12:51:35 am Jaroslav Kysela wrote: > > On Mon, 14 Jan 2008, Bjorn Helgaas wrote: > > > On Saturday 12 January 2008 11:13:35 pm Rene Herman wrote: > > > > ... And, now that I have your attention, while it's > > > > not important to the issue anymore with the tests removed as the > > > > submitted patch did, do you have an opinion on (include/linux/pnp.h): > > > > > > > > /* pnp driver flags */ > > > > #define PNP_DRIVER_RES_DO_NOT_CHANGE0x0001 /* do not change the > > > > state of the device */ > > > > #define PNP_DRIVER_RES_DISABLE 0x0003 /* ensure the device > > > > is disabled */ > > > > > > > > I find DISABLE including DO_NOT_CHANGE rather unexpected... > > > > > > I don't know the history of those flags, but I wish they didn't exist. > > > > 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? > > > 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? I'd say yes. If base address of a card changes, driver will break. I grepped drivers for these flags too - to find out what they do (or should do?) - but failed to find out anything useful. > Linux PNP definitely has issues with suspend/resume, and I suspect > this is one of them. > > Bjorn > -- > 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/ -- Ondrej Zary -- 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: -mm: pnp-do-not-stop-start-devices-in-suspend-resume-path.patch breaks resuming isapnp cards
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. -- 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: -mm: pnp-do-not-stop-start-devices-in-suspend-resume-path.patch breaks resuming isapnp cards
On Tuesday 15 January 2008 12:51:35 am Jaroslav Kysela wrote: > On Mon, 14 Jan 2008, Bjorn Helgaas wrote: > > On Saturday 12 January 2008 11:13:35 pm Rene Herman wrote: > > > ... And, now that I have your attention, while it's > > > not important to the issue anymore with the tests removed as the > > > submitted > > > patch did, do you have an opinion on (include/linux/pnp.h): > > > > > > /* pnp driver flags */ > > > #define PNP_DRIVER_RES_DO_NOT_CHANGE0x0001 /* do not change the > > > state > > > of the device */ > > > #define PNP_DRIVER_RES_DISABLE 0x0003 /* ensure the device is > > > disabled */ > > > > > > I find DISABLE including DO_NOT_CHANGE rather unexpected... > > > > I don't know the history of those flags, but I wish they didn't exist. > > 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? > 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? Linux PNP definitely has issues with suspend/resume, and I suspect this is one of them. Bjorn -- 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: -mm: pnp-do-not-stop-start-devices-in-suspend-resume-path.patch breaks resuming isapnp cards
On Tuesday 15 January 2008 12:51:35 am Jaroslav Kysela wrote: On Mon, 14 Jan 2008, Bjorn Helgaas wrote: On Saturday 12 January 2008 11:13:35 pm Rene Herman wrote: ... And, now that I have your attention, while it's not important to the issue anymore with the tests removed as the submitted patch did, do you have an opinion on (include/linux/pnp.h): /* pnp driver flags */ #define PNP_DRIVER_RES_DO_NOT_CHANGE0x0001 /* do not change the state of the device */ #define PNP_DRIVER_RES_DISABLE 0x0003 /* ensure the device is disabled */ I find DISABLE including DO_NOT_CHANGE rather unexpected... I don't know the history of those flags, but I wish they didn't exist. 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? 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? Linux PNP definitely has issues with suspend/resume, and I suspect this is one of them. Bjorn -- 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: -mm: pnp-do-not-stop-start-devices-in-suspend-resume-path.patch breaks resuming isapnp cards
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. -- 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: -mm: pnp-do-not-stop-start-devices-in-suspend-resume-path.patch breaks resuming isapnp cards
On Wednesday 16 January 2008 18:46:03 Bjorn Helgaas wrote: On Tuesday 15 January 2008 12:51:35 am Jaroslav Kysela wrote: On Mon, 14 Jan 2008, Bjorn Helgaas wrote: On Saturday 12 January 2008 11:13:35 pm Rene Herman wrote: ... And, now that I have your attention, while it's not important to the issue anymore with the tests removed as the submitted patch did, do you have an opinion on (include/linux/pnp.h): /* pnp driver flags */ #define PNP_DRIVER_RES_DO_NOT_CHANGE0x0001 /* do not change the state of the device */ #define PNP_DRIVER_RES_DISABLE 0x0003 /* ensure the device is disabled */ I find DISABLE including DO_NOT_CHANGE rather unexpected... I don't know the history of those flags, but I wish they didn't exist. 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? 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? I'd say yes. If base address of a card changes, driver will break. I grepped drivers for these flags too - to find out what they do (or should do?) - but failed to find out anything useful. Linux PNP definitely has issues with suspend/resume, and I suspect this is one of them. Bjorn -- 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/ -- Ondrej Zary -- 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: -mm: pnp-do-not-stop-start-devices-in-suspend-resume-path.patch breaks resuming isapnp cards
On Mon, 14 Jan 2008, Bjorn Helgaas wrote: > On Saturday 12 January 2008 11:13:35 pm Rene Herman wrote: > > ... And, now that I have your attention, while it's > > not important to the issue anymore with the tests removed as the submitted > > patch did, do you have an opinion on (include/linux/pnp.h): > > > > /* pnp driver flags */ > > #define PNP_DRIVER_RES_DO_NOT_CHANGE0x0001 /* do not change the state > > of the device */ > > #define PNP_DRIVER_RES_DISABLE 0x0003 /* ensure the device is > > disabled */ > > > > I find DISABLE including DO_NOT_CHANGE rather unexpected... > > I don't know the history of those flags, but I wish they didn't exist. 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. 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. Jaroslav - Jaroslav Kysela <[EMAIL PROTECTED]> Linux Kernel Sound Maintainer ALSA Project, Red Hat, Inc. -- 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: -mm: pnp-do-not-stop-start-devices-in-suspend-resume-path.patch breaks resuming isapnp cards
On 14-01-08 23:26, Bjorn Helgaas wrote: On Saturday 12 January 2008 11:13:35 pm Rene Herman wrote: I find DISABLE including DO_NOT_CHANGE rather unexpected... I don't know the history of those flags, but I wish they didn't exist. They really look like warts in the PNP core code. They're used so infrequently and without obvious rationale, that it seems like it'd be better if there were a way to deal with them inside the driver. I see, thanks for the comment. PNP_DRIVER_RES_DISABLE is used by ALSA only and used by _all_ ALSA ISA-PnP drivers (snd-sscape uses RES_DO_NOT_CHANGE instead but we should consider that one a consistency bug). RES_DO_NOT_CHANGE is used by drivers/pnp/system.c and rtc-cmos.c as well. I'll look at this. Getting rid of DISABLE as a first step should not be overly problematic. This might again be a left-over from days where no easy to use interface to PnP existed which it now does in echoing things into sysfs. Takashi: which reminds me -- crap, I promised to document more of that for ALSA use following up the recent pnp driver-side resource setting removal. Sorry, forgot, will do. This had to do with the excessive warnings about exceeding the maximum number of resources for a PNP device. This should be resolved by Len's patch here: http://bugzilla.kernel.org/show_bug.cgi?id=9535#c10 We all agree this is a stop-gap, and for 2.6.25, we need the real solution of making PNP resources fully dynamic. Thank you. Just pulled and see that's now indeed in. Wasn't in -rc7 yet... Rene. -- 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: -mm: pnp-do-not-stop-start-devices-in-suspend-resume-path.patch breaks resuming isapnp cards
On Saturday 12 January 2008 11:13:35 pm Rene Herman wrote: > ... And, now that I have your attention, while it's > not important to the issue anymore with the tests removed as the submitted > patch did, do you have an opinion on (include/linux/pnp.h): > > /* pnp driver flags */ > #define PNP_DRIVER_RES_DO_NOT_CHANGE0x0001 /* do not change the state > of the device */ > #define PNP_DRIVER_RES_DISABLE 0x0003 /* ensure the device is > disabled */ > > I find DISABLE including DO_NOT_CHANGE rather unexpected... I don't know the history of those flags, but I wish they didn't exist. They really look like warts in the PNP core code. They're used so infrequently and without obvious rationale, that it seems like it'd be better if there were a way to deal with them inside the driver. But to answer your question, I don't know enough to have an opinion on whether DISABLE should include DO_NOT_CHANGE. > By the way, I also still have this next one outstanding for you... :-/ > > http://lkml.org/lkml/2008/1/9/168 This had to do with the excessive warnings about exceeding the maximum number of resources for a PNP device. This should be resolved by Len's patch here: http://bugzilla.kernel.org/show_bug.cgi?id=9535#c10 We all agree this is a stop-gap, and for 2.6.25, we need the real solution of making PNP resources fully dynamic. Bjorn -- 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: -mm: pnp-do-not-stop-start-devices-in-suspend-resume-path.patch breaks resuming isapnp cards
On Saturday 12 January 2008 11:13:35 pm Rene Herman wrote: ... And, now that I have your attention, while it's not important to the issue anymore with the tests removed as the submitted patch did, do you have an opinion on (include/linux/pnp.h): /* pnp driver flags */ #define PNP_DRIVER_RES_DO_NOT_CHANGE0x0001 /* do not change the state of the device */ #define PNP_DRIVER_RES_DISABLE 0x0003 /* ensure the device is disabled */ I find DISABLE including DO_NOT_CHANGE rather unexpected... I don't know the history of those flags, but I wish they didn't exist. They really look like warts in the PNP core code. They're used so infrequently and without obvious rationale, that it seems like it'd be better if there were a way to deal with them inside the driver. But to answer your question, I don't know enough to have an opinion on whether DISABLE should include DO_NOT_CHANGE. By the way, I also still have this next one outstanding for you... :-/ http://lkml.org/lkml/2008/1/9/168 This had to do with the excessive warnings about exceeding the maximum number of resources for a PNP device. This should be resolved by Len's patch here: http://bugzilla.kernel.org/show_bug.cgi?id=9535#c10 We all agree this is a stop-gap, and for 2.6.25, we need the real solution of making PNP resources fully dynamic. Bjorn -- 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: -mm: pnp-do-not-stop-start-devices-in-suspend-resume-path.patch breaks resuming isapnp cards
On 14-01-08 23:26, Bjorn Helgaas wrote: On Saturday 12 January 2008 11:13:35 pm Rene Herman wrote: I find DISABLE including DO_NOT_CHANGE rather unexpected... I don't know the history of those flags, but I wish they didn't exist. They really look like warts in the PNP core code. They're used so infrequently and without obvious rationale, that it seems like it'd be better if there were a way to deal with them inside the driver. I see, thanks for the comment. PNP_DRIVER_RES_DISABLE is used by ALSA only and used by _all_ ALSA ISA-PnP drivers (snd-sscape uses RES_DO_NOT_CHANGE instead but we should consider that one a consistency bug). RES_DO_NOT_CHANGE is used by drivers/pnp/system.c and rtc-cmos.c as well. I'll look at this. Getting rid of DISABLE as a first step should not be overly problematic. This might again be a left-over from days where no easy to use interface to PnP existed which it now does in echoing things into sysfs. Takashi: which reminds me -- crap, I promised to document more of that for ALSA use following up the recent pnp driver-side resource setting removal. Sorry, forgot, will do. This had to do with the excessive warnings about exceeding the maximum number of resources for a PNP device. This should be resolved by Len's patch here: http://bugzilla.kernel.org/show_bug.cgi?id=9535#c10 We all agree this is a stop-gap, and for 2.6.25, we need the real solution of making PNP resources fully dynamic. Thank you. Just pulled and see that's now indeed in. Wasn't in -rc7 yet... Rene. -- 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: -mm: pnp-do-not-stop-start-devices-in-suspend-resume-path.patch breaks resuming isapnp cards
On Mon, 14 Jan 2008, Bjorn Helgaas wrote: On Saturday 12 January 2008 11:13:35 pm Rene Herman wrote: ... And, now that I have your attention, while it's not important to the issue anymore with the tests removed as the submitted patch did, do you have an opinion on (include/linux/pnp.h): /* pnp driver flags */ #define PNP_DRIVER_RES_DO_NOT_CHANGE0x0001 /* do not change the state of the device */ #define PNP_DRIVER_RES_DISABLE 0x0003 /* ensure the device is disabled */ I find DISABLE including DO_NOT_CHANGE rather unexpected... I don't know the history of those flags, but I wish they didn't exist. 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. 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. Jaroslav - Jaroslav Kysela [EMAIL PROTECTED] Linux Kernel Sound Maintainer ALSA Project, Red Hat, Inc. -- 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: -mm: pnp-do-not-stop-start-devices-in-suspend-resume-path.patch breaks resuming isapnp cards
On 13-01-08 06:50, Bjorn Helgaas wrote: On Saturday 12 January 2008 1:08:01 pm Rene Herman wrote: pnp-do-not-stop-start-devices-in-suspend-resume-path.patch in current -mm breaks resuming isapnp cards from hibernation. They need the pnp_start_dev to enable the device again after hibernation. They don't really need the pnp_stop_dev() which the above mentioned patch also removes but with the pnp_start_dev() restored it seems pnp_stop_dev() should also stay. Bjorn Helgaas should decide -- currently the patch as you have it breaks drivers though. Could you drop it? Yes, please drop pnp-do-not-stop-start-devices-in-suspend-resume-path.patch for now. Okay, thanks for the reply. And, now that I have your attention, while it's not important to the issue anymore with the tests removed as the submitted patch did, do you have an opinion on (include/linux/pnp.h): /* pnp driver flags */ #define PNP_DRIVER_RES_DO_NOT_CHANGE0x0001 /* do not change the state of the device */ #define PNP_DRIVER_RES_DISABLE 0x0003 /* ensure the device is disabled */ I find DISABLE including DO_NOT_CHANGE rather unexpected... By the way, I also still have this next one outstanding for you... :-/ http://lkml.org/lkml/2008/1/9/168 Rene. -- 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: -mm: pnp-do-not-stop-start-devices-in-suspend-resume-path.patch breaks resuming isapnp cards
On Saturday 12 January 2008 1:08:01 pm Rene Herman wrote: > pnp-do-not-stop-start-devices-in-suspend-resume-path.patch in current -mm > breaks resuming isapnp cards from hibernation. They need the pnp_start_dev > to enable the device again after hibernation. > > They don't really need the pnp_stop_dev() which the above mentioned patch > also removes but with the pnp_start_dev() restored it seems pnp_stop_dev() > should also stay. Bjorn Helgaas should decide -- currently the patch as > you have it breaks drivers though. Could you drop it? Yes, please drop pnp-do-not-stop-start-devices-in-suspend-resume-path.patch for now. When the PNP core requested resources for active devices, the pnp_stop_dev() in the suspend path released the PNP core resources, leaving the underlying driver resources orphaned. But the patch that made the PNP core request those resource is also gone, so we can leave the start/stop alone. > On 12-01-08 20:08, Rafael J. Wysocki wrote: > > On Saturday, 12 of January 2008, Rene Herman wrote: > >> It seems all PnP drivers would need to stick a pnp_start_dev in their > >> resume method > > > > Yes. > > > >> then which means it really belongs in core. > > > > Yes, if practical. > > > >> One important point where PnP and PCI differ is that PnP allows to > >> change the resources on a protocol level and I don't see how it could > >> ever not be necessary to restore the state a user may have set if power > >> has been removed. Hibernate is just that, isn't it? That's a good point, thanks for pointing that out. Bjorn -- 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: -mm: pnp-do-not-stop-start-devices-in-suspend-resume-path.patch breaks resuming isapnp cards
On Saturday 12 January 2008 1:08:01 pm Rene Herman wrote: pnp-do-not-stop-start-devices-in-suspend-resume-path.patch in current -mm breaks resuming isapnp cards from hibernation. They need the pnp_start_dev to enable the device again after hibernation. They don't really need the pnp_stop_dev() which the above mentioned patch also removes but with the pnp_start_dev() restored it seems pnp_stop_dev() should also stay. Bjorn Helgaas should decide -- currently the patch as you have it breaks drivers though. Could you drop it? Yes, please drop pnp-do-not-stop-start-devices-in-suspend-resume-path.patch for now. When the PNP core requested resources for active devices, the pnp_stop_dev() in the suspend path released the PNP core resources, leaving the underlying driver resources orphaned. But the patch that made the PNP core request those resource is also gone, so we can leave the start/stop alone. On 12-01-08 20:08, Rafael J. Wysocki wrote: On Saturday, 12 of January 2008, Rene Herman wrote: It seems all PnP drivers would need to stick a pnp_start_dev in their resume method Yes. then which means it really belongs in core. Yes, if practical. One important point where PnP and PCI differ is that PnP allows to change the resources on a protocol level and I don't see how it could ever not be necessary to restore the state a user may have set if power has been removed. Hibernate is just that, isn't it? That's a good point, thanks for pointing that out. Bjorn -- 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: -mm: pnp-do-not-stop-start-devices-in-suspend-resume-path.patch breaks resuming isapnp cards
On 13-01-08 06:50, Bjorn Helgaas wrote: On Saturday 12 January 2008 1:08:01 pm Rene Herman wrote: pnp-do-not-stop-start-devices-in-suspend-resume-path.patch in current -mm breaks resuming isapnp cards from hibernation. They need the pnp_start_dev to enable the device again after hibernation. They don't really need the pnp_stop_dev() which the above mentioned patch also removes but with the pnp_start_dev() restored it seems pnp_stop_dev() should also stay. Bjorn Helgaas should decide -- currently the patch as you have it breaks drivers though. Could you drop it? Yes, please drop pnp-do-not-stop-start-devices-in-suspend-resume-path.patch for now. Okay, thanks for the reply. And, now that I have your attention, while it's not important to the issue anymore with the tests removed as the submitted patch did, do you have an opinion on (include/linux/pnp.h): /* pnp driver flags */ #define PNP_DRIVER_RES_DO_NOT_CHANGE0x0001 /* do not change the state of the device */ #define PNP_DRIVER_RES_DISABLE 0x0003 /* ensure the device is disabled */ I find DISABLE including DO_NOT_CHANGE rather unexpected... By the way, I also still have this next one outstanding for you... :-/ http://lkml.org/lkml/2008/1/9/168 Rene. -- 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/
