On Wednesday, 26 of December 2007, Linus Torvalds wrote:
>
> On Tue, 25 Dec 2007, Rafael J. Wysocki wrote:
> >
> > the ACPI specification between versions 1.0x and 2.0. Namely, while ACPI
> > 2.0 and later wants us to put devices into low power states before calling
> > _PTS, ACPI 1.0x wants us t
Linus Torvalds wrote:
>
>> IMO, we should check which version of the specification we're supposed to
>> follow, on the basis of FADT contents, for example, and follow this one.
>>
>
> No, we should try to figure out what Windows does. *If* windows checks the
> version, we should do that too.
Linus Torvalds wrote:
IMO, we should check which version of the specification we're supposed to
follow, on the basis of FADT contents, for example, and follow this one.
No, we should try to figure out what Windows does. *If* windows checks the
version, we should do that too. But we should abso
On Tue, 25 Dec 2007, Rafael J. Wysocki wrote:
> >
> > Correct me if I'm wrong, but it appears ACPI 1.0 wants _PTS called
> > before any devices are suspended, ACPI 2.0 is contradictory, and ACPI
> > 3.0 says that you can't assume anything about device state. My guess is
> > that unless Windows
On Tue, 25 Dec 2007, Rafael J. Wysocki wrote:
>
> the ACPI specification between versions 1.0x and 2.0. Namely, while ACPI
> 2.0 and later wants us to put devices into low power states before calling
> _PTS, ACPI 1.0x wants us to do that after calling _PTS. Since we're following
> the 2.0 and l
On Tuesday, 25 of December 2007, Robert Hancock wrote:
> Carlos Corbacho wrote:
> > On Tuesday 25 December 2007 13:26:12 Rafael J. Wysocki wrote:
> >> Well, citing from the ACPI 2.0 specification, section 9.1.6 Transitioning
> >> from the Working to the Sleeping State (which is what we're discussin
Carlos Corbacho wrote:
On Tuesday 25 December 2007 13:26:12 Rafael J. Wysocki wrote:
Well, citing from the ACPI 2.0 specification, section 9.1.6 Transitioning
from the Working to the Sleeping State (which is what we're discussing
here):
3. OSPM places all device drivers into their respective Dx
On Monday, 24 of December 2007, Linus Torvalds wrote:
>
> On Mon, 24 Dec 2007, Rafael J. Wysocki wrote:
> >
> > Well, having considered that for a longer while, I think the AML code is
> > referring to a device that we have suspended already, and since it's in a
> > low
> > power state, it just
On Tuesday 25 December 2007 14:07:22 Rafael J. Wysocki wrote:
> OK, sorry, the approach is generally reasonable, IMO, but it needs to be a
> bit more fine grained.
I know, hence this was marked as a hack and not signed off; it's just a
demonstration of the general idea with code instead of words.
On Tuesday, 25 of December 2007, Carlos Corbacho wrote:
> On Tuesday 25 December 2007 13:26:12 Rafael J. Wysocki wrote:
> > Well, citing from the ACPI 2.0 specification, section 9.1.6 Transitioning
> > from the Working to the Sleeping State (which is what we're discussing
> > here):
> >
> > 3. OSPM
On Tuesday, 25 of December 2007, Rafael J. Wysocki wrote:
> On Tuesday, 25 of December 2007, Carlos Corbacho wrote:
> > Adding Linux-ACPI to CC.
> >
> > On Tuesday 25 December 2007 00:03:25 Carlos Corbacho wrote:
> > > According to the earlier versions of the ACPI spec, Linux is doing the
> > > wr
On Tuesday, 25 of December 2007, Carlos Corbacho wrote:
> Adding Linux-ACPI to CC.
>
> On Tuesday 25 December 2007 00:03:25 Carlos Corbacho wrote:
> > According to the earlier versions of the ACPI spec, Linux is doing the
> > wrong thing - we should call _PTS() before we start powerding down devic
On Tuesday 25 December 2007 13:26:12 Rafael J. Wysocki wrote:
> Well, citing from the ACPI 2.0 specification, section 9.1.6 Transitioning
> from the Working to the Sleeping State (which is what we're discussing
> here):
>
> 3. OSPM places all device drivers into their respective Dx state. If the
>
On Tuesday, 25 of December 2007, Carlos Corbacho wrote:
> On Monday 24 December 2007 22:40:46 Robert Hancock wrote:
> > The ACPI spec has the following to say about the _PTS method:
> >
> > "The platform must not make any assumptions about the state of the
> > machine when _PTS is called. For examp
Pavel,
On Tuesday 25 December 2007 12:12:31 Pavel Machek wrote:
> > The patch is fine by me, so if anyone has objections, please speak up.
>
> Just.. I have been running with very similar patch for few years... it
> fixes few prototype machines I have here.
I've withdrawn the patch since it doesn
Hi!
> On Sunday, 23 of December 2007, Carlos Corbacho wrote:
> > Fix suspend-to-RAM on nForce 4 (CK804) boards by increasing
> > PCIBIOS_MIN_IO.
> >
> > Fixes kernel bugzilla #9528
> >
> > Problem:
> >
> > Linus' patch (52ade9b3b97fd3bea42842a056fe0786c28d0555) to re-order
> > suspend (and fix
Adding Linux-ACPI to CC.
On Tuesday 25 December 2007 00:03:25 Carlos Corbacho wrote:
> According to the earlier versions of the ACPI spec, Linux is doing the
> wrong thing - we should call _PTS() before we start powerding down devices,
> or notifying device drivers to start suspending.
>
> So, my
On Monday 24 December 2007 22:40:46 Robert Hancock wrote:
> The ACPI spec has the following to say about the _PTS method:
>
> "The platform must not make any assumptions about the state of the
> machine when _PTS is called. For example, operation region accesses that
> require devices to be configu
Carlos Corbacho wrote:
On Monday 24 December 2007 18:34:21 Linus Torvalds wrote:
On Mon, 24 Dec 2007, Rafael J. Wysocki wrote:
Well, having considered that for a longer while, I think the AML code is
referring to a device that we have suspended already, and since it's in a
low power state, it j
On Monday 24 December 2007 18:34:21 Linus Torvalds wrote:
> On Mon, 24 Dec 2007, Rafael J. Wysocki wrote:
> > Well, having considered that for a longer while, I think the AML code is
> > referring to a device that we have suspended already, and since it's in a
> > low power state, it just can't han
On Mon, 24 Dec 2007, Rafael J. Wysocki wrote:
>
> Well, having considered that for a longer while, I think the AML code is
> referring to a device that we have suspended already, and since it's in a low
> power state, it just can't handle the reference.
>
> If that is the case, we'll have to fi
Linus Torvalds wrote:
On Sun, 23 Dec 2007, Carlos Corbacho wrote:
Fix suspend-to-RAM on nForce 4 (CK804) boards by increasing
PCIBIOS_MIN_IO.
Fixes kernel bugzilla #9528
Problem:
Linus' patch (52ade9b3b97fd3bea42842a056fe0786c28d0555) to re-order
suspend (and fix fall out from Rafael's earli
On Monday, 24 of December 2007, Carlos Corbacho wrote:
> On Monday 24 December 2007 01:14:34 Linus Torvalds wrote:
> > Side note: we could obviously undo the commit that triggered this for you
> > [..]
> > In other words, we'd have to go back to our original ordering, which Len
> > said was fundame
On Monday 24 December 2007 01:14:34 Linus Torvalds wrote:
> Side note: we could obviously undo the commit that triggered this for you
> [..]
> In other words, we'd have to go back to our original ordering, which Len
> said was fundamentally wrong. I don't think anybody really wants that.
Nor would
On Sun, 23 Dec 2007, Linus Torvalds wrote:
>
> IOW, it looks like the normal kind of ACPI mess. Color me not in the least
> surprised, and it needs somebody who understands AML and what the heck is
> supposed to happen to figure out.
Side note: we could obviously undo the commit that triggere
On Mon, 24 Dec 2007, Carlos Corbacho wrote:
>
> Please disregard the patch anyway - my test system was still using the custom
> DSDT - it doesn't fix anything.
Ok, so it's not a simple IO port conflict.
And the range 0x1400-0x147f (which is apparently the ACPI block) is
properly marked as re
On Sunday 23 December 2007 23:12:47 H. Peter Anvin wrote:
> Rafael J. Wysocki wrote:
> > On Sunday, 23 of December 2007, Linus Torvalds wrote:
> >> On Sun, 23 Dec 2007, Rafael J. Wysocki wrote:
> >>> The patch is fine by me, so if anyone has objections, please speak up.
> >>
> >> There is absolutel
Rafael J. Wysocki wrote:
On Sunday, 23 of December 2007, Linus Torvalds wrote:
On Sun, 23 Dec 2007, Rafael J. Wysocki wrote:
The patch is fine by me, so if anyone has objections, please speak up.
There is absolutely *no* way I will apply this in an -rc6 release.
The number of machines this wi
On Sunday, 23 of December 2007, Linus Torvalds wrote:
>
> On Sun, 23 Dec 2007, Rafael J. Wysocki wrote:
> >
> > The patch is fine by me, so if anyone has objections, please speak up.
>
> There is absolutely *no* way I will apply this in an -rc6 release.
>
> The number of machines this will brea
On Dec 23, 2007 9:53 AM, Linus Torvalds <[EMAIL PROTECTED]> wrote:
>
>
> On Sun, 23 Dec 2007, Carlos Corbacho wrote:
> >
> > Fix suspend-to-RAM on nForce 4 (CK804) boards by increasing
> > PCIBIOS_MIN_IO.
> >
> > Fixes kernel bugzilla #9528
> >
> > Problem:
> >
> > Linus' patch (52ade9b3b97fd3bea42
On Sun, 23 Dec 2007, Ingo Molnar wrote:
>
> This script will probe all unused ports as per /proc/ioports and will
> list "suspect" IO port areas: ones that do not produce the expected 0xff
> default reply from unclaimed IO ports. Magic chipset register areas can
> potentially be mapped this w
* Linus Torvalds <[EMAIL PROTECTED]> wrote:
> > Why:
> >
> > After debugging _PTS() in the DSDT, it turns out these nVidia boards are
> > trying to write to an IO port > 0x1000 (0x142E) during suspend. Before the
> > re-ordering, we got away with this.
>
> Very interesting.
>
> HOWEVER.
>
>
On Sun, 23 Dec 2007, Linus Torvalds wrote:
>
> For an example of what I mean, see the file "drivers/pci/quirks.c", and
> check out the quirks for various chipsets:
Side note - we already do have some quirks for the CK804 chipset, we
probably just don't have enough (ie we have it for some HT s
On Sun, 23 Dec 2007, Rafael J. Wysocki wrote:
>
> The patch is fine by me, so if anyone has objections, please speak up.
There is absolutely *no* way I will apply this in an -rc6 release.
The number of machines this will break is totally unknown. It might be
zero. It might be hundreds. We ju
* Rafael J. Wysocki <[EMAIL PROTECTED]> wrote:
> > 0x1500 has been picked here as a nice, round and more conservative
> > value than 0x4000, and which covers 0x142E.
>
> The patch is fine by me, so if anyone has objections, please speak up.
i'm quite nervous about that approach, partly due to
On Sun, 23 Dec 2007, Carlos Corbacho wrote:
>
> Fix suspend-to-RAM on nForce 4 (CK804) boards by increasing
> PCIBIOS_MIN_IO.
>
> Fixes kernel bugzilla #9528
>
> Problem:
>
> Linus' patch (52ade9b3b97fd3bea42842a056fe0786c28d0555) to re-order
> suspend (and fix fall out from Rafael's earlier s
On Sunday, 23 of December 2007, Carlos Corbacho wrote:
> Fix suspend-to-RAM on nForce 4 (CK804) boards by increasing
> PCIBIOS_MIN_IO.
>
> Fixes kernel bugzilla #9528
>
> Problem:
>
> Linus' patch (52ade9b3b97fd3bea42842a056fe0786c28d0555) to re-order
> suspend (and fix fall out from Rafael's ea
37 matches
Mail list logo
