[PATCH 0/3]making ACPICA safe for suspend/resume - take 2

[PATCH 0/3]making ACPICA safe for suspend/resume - take 2

[Li Shaohua]

Hi,
The patches are designed to solve the issue of making call to ACPICA
safe for suspend/resume time. Please see the detail in
http://sourceforge.net/mailarchive/forum.php?thread_id=6378210&forum_id=6102
The new patches remove PCI link device resume code and let PCI device
driver resume code indirectly reconfigure Link's IRQ (call
pci_enable_device), so we will haven't an issue of invoking ACPICA with
interrupt disabled. This also works for suspend to disk case. After this
we only need to guarantee there is enough free memory for S3. One
problem of the idea is we must fix many PCI drivers, but it's ok to me.
If this solution is ok, I will send my patch 3 to LKML first.

Thanks,
Shaohua 



-------------------------------------------------------
This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
Tool for open source databases. Create drag-&-drop reports. Save time
by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
Download a FREE copy at http://www.intelliview.com/go/osdn_nl

Re: [PATCH 0/3]making ACPICA safe for suspend/resume - take 2

[Pavel Machek]

Hi!

> The patches are designed to solve the issue of making call to ACPICA
> safe for suspend/resume time. Please see the detail in
> http://sourceforge.net/mailarchive/forum.php?thread_id=6378210&forum_id=6102
> The new patches remove PCI link device resume code and let PCI device
> driver resume code indirectly reconfigure Link's IRQ (call
> pci_enable_device), so we will haven't an issue of invoking ACPICA with
> interrupt disabled. This also works for suspend to disk case. After this
> we only need to guarantee there is enough free memory for S3. One
> problem of the idea is we must fix many PCI drivers, but it's ok to me.

Well, having to modify all the drivers should mean "this should be
merged after 2.6.11" (I'm in process of converting all the drivers to
pm_message_t, and would prefer another set of "touch all drivers"
changes not to interfere).

Anyway that memory freeing seems okay to me, and if you decide to
introduce in_suspend(), that would be okay, too.
								Pavel
-- 
People were complaining that M$ turns users into beta-testers...
...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl!


-------------------------------------------------------
This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
Tool for open source databases. Create drag-&-drop reports. Save time
by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
Download a FREE copy at http://www.intelliview.com/go/osdn_nl

Re: [PATCH 0/3]making ACPICA safe for suspend/resume - take 2

[Li Shaohua]

On Fri, 2005-01-21 at 17:52, Pavel Machek wrote:
> > The patches are designed to solve the issue of making call to ACPICA
> > safe for suspend/resume time. Please see the detail in
> > http://sourceforge.net/mailarchive/forum.php?thread_id=6378210&forum_id=6102
> > The new patches remove PCI link device resume code and let PCI device
> > driver resume code indirectly reconfigure Link's IRQ (call
> > pci_enable_device), so we will haven't an issue of invoking ACPICA with
> > interrupt disabled. This also works for suspend to disk case. After this
> > we only need to guarantee there is enough free memory for S3. One
> > problem of the idea is we must fix many PCI drivers, but it's ok to me.
> 
> Well, having to modify all the drivers should mean "this should be
> merged after 2.6.11" (I'm in process of converting all the drivers to
> pm_message_t, and would prefer another set of "touch all drivers"
> changes not to interfere).
There isn't conflict between the pm_message_t converting and adding
pci_enable/disable_device to me. It would be better we do them in the
meantime, so we don't require another round of change. If so, I can help
doing the converting also.

> Anyway that memory freeing seems okay to me, and if you decide to
> introduce in_suspend(), that would be okay, too.
ACPI doesn't require it now, I prefer add it when there is real
requirement.

Thanks,
Shaohua



-------------------------------------------------------
This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
Tool for open source databases. Create drag-&-drop reports. Save time
by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
Download a FREE copy at http://www.intelliview.com/go/osdn_nl

Re: [PATCH 0/3]making ACPICA safe for suspend/resume - take 2

[Pavel Machek]

Hi!

> > > The patches are designed to solve the issue of making call to ACPICA
> > > safe for suspend/resume time. Please see the detail in
> > > http://sourceforge.net/mailarchive/forum.php?thread_id=6378210&forum_id=6102
> > > The new patches remove PCI link device resume code and let PCI device
> > > driver resume code indirectly reconfigure Link's IRQ (call
> > > pci_enable_device), so we will haven't an issue of invoking ACPICA with
> > > interrupt disabled. This also works for suspend to disk case. After this
> > > we only need to guarantee there is enough free memory for S3. One
> > > problem of the idea is we must fix many PCI drivers, but it's ok to me.
> > 
> > Well, having to modify all the drivers should mean "this should be
> > merged after 2.6.11" (I'm in process of converting all the drivers to
> > pm_message_t, and would prefer another set of "touch all drivers"
> > changes not to interfere).
> There isn't conflict between the pm_message_t converting and adding
> pci_enable/disable_device to me. It would be better we do them in the
> meantime, so we don't require another round of change. If so, I can help
> doing the converting also.

Well, when something breaks, we will not know "what was it". Plus, it
is going to be quite an intrusive change and we are already at -rc2.

If driver can do pci_enable_device to solve "ACPICA with interrupts
disabled" problem, why can't be the same done in code that calls
device's suspend() method from PCI code? That would be smaller change,
and we would not duplicate a lot of code.

								Pavel
-- 
People were complaining that M$ turns users into beta-testers...
...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl!


-------------------------------------------------------
This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
Tool for open source databases. Create drag-&-drop reports. Save time
by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
Download a FREE copy at http://www.intelliview.com/go/osdn_nl

Re: [PATCH 0/3]making ACPICA safe for suspend/resume - take 2

[Li Shaohua]

On Wed, 2005-01-26 at 19:58, Pavel Machek wrote:
> > > > The patches are designed to solve the issue of making call to ACPICA
> > > > safe for suspend/resume time. Please see the detail in
> > > > http://sourceforge.net/mailarchive/forum.php?thread_id=6378210&forum_id=6102
> > > > The new patches remove PCI link device resume code and let PCI device
> > > > driver resume code indirectly reconfigure Link's IRQ (call
> > > > pci_enable_device), so we will haven't an issue of invoking ACPICA with
> > > > interrupt disabled. This also works for suspend to disk case. After this
> > > > we only need to guarantee there is enough free memory for S3. One
> > > > problem of the idea is we must fix many PCI drivers, but it's ok to me.
> > > 
> > > Well, having to modify all the drivers should mean "this should be
> > > merged after 2.6.11" (I'm in process of converting all the drivers to
> > > pm_message_t, and would prefer another set of "touch all drivers"
> > > changes not to interfere).
> > There isn't conflict between the pm_message_t converting and adding
> > pci_enable/disable_device to me. It would be better we do them in the
> > meantime, so we don't require another round of change. If so, I can help
> > doing the converting also.
> 
> Well, when something breaks, we will not know "what was it". Plus, it
> is going to be quite an intrusive change and we are already at -rc2.
Ok, that makes sense, though I think pci_enable/disable_device hasn't
impact.

> If driver can do pci_enable_device to solve "ACPICA with interrupts
> isabled" problem, 
This is just one part. pci_disable_device will disable bus master and
possibly do more, I think it's much safer.

> why can't be the same done in code that calls
> device's suspend() method from PCI code? That would be smaller change,
> and we would not duplicate a lot of code.
This is good for pci_disable_device (suspend), but not for resume. We
must restore PCI config and then call pci_enable_device.

Thanks,
Shaohua



-------------------------------------------------------
This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
Tool for open source databases. Create drag-&-drop reports. Save time
by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
Download a FREE copy at http://www.intelliview.com/go/osdn_nl

Re: [PATCH 0/3]making ACPICA safe for suspend/resume - take 2

[Pavel Machek]

Hi!

> > why can't be the same done in code that calls
> > device's suspend() method from PCI code? That would be smaller change,
> > and we would not duplicate a lot of code.
> This is good for pci_disable_device (suspend), but not for resume. We
> must restore PCI config and then call pci_enable_device.

Ok, perhaps we need pci_resume_device() wrapper, then, which does
pci_restore_config() now, but we can easily add pci_enable_device()
there?
								Pavel
-- 
People were complaining that M$ turns users into beta-testers...
...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl!


-------------------------------------------------------
This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
Tool for open source databases. Create drag-&-drop reports. Save time
by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
Download a FREE copy at http://www.intelliview.com/go/osdn_nl

Re: [PATCH 0/3]making ACPICA safe for suspend/resume - take 2

[Li Shaohua]

On Thu, 2005-01-27 at 16:03, Pavel Machek wrote:
> > > why can't be the same done in code that calls
> > > device's suspend() method from PCI code? That would be smaller change,
> > > and we would not duplicate a lot of code.
> > This is good for pci_disable_device (suspend), but not for resume. We
> > must restore PCI config and then call pci_enable_device.
> 
> Ok, perhaps we need pci_resume_device() wrapper, then, which does
> pci_restore_config() now, but we can easily add pci_enable_device()
> there?
I agree. It's better all such things are doing on PCI core. Every device
driver just is doing the similar. Then we need a mechanism to know if a
device is really enabled (maybe check dev->driver) or it's a bus master.

Thanks,
Shaohua



-------------------------------------------------------
This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
Tool for open source databases. Create drag-&-drop reports. Save time
by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
Download a FREE copy at http://www.intelliview.com/go/osdn_nl