From: Andreas Schwab <hidden> Date: 2012-04-18 07:46:29
Benjamin Herrenschmidt [off-list ref] writes:
Note also that KMS doesn't afaik have the power management code that
radeonfb has for those old Mac chipsets, so suspend/resume won't work.
How hard would it be to add it?
Andreas.
--
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
From: Benjamin Herrenschmidt <benh@kernel.crashing.org> Date: 2012-04-18 10:35:50
On Wed, 2012-04-18 at 09:46 +0200, Andreas Schwab wrote:
Benjamin Herrenschmidt [off-list ref] writes:
quoted
Note also that KMS doesn't afaik have the power management code that
radeonfb has for those old Mac chipsets, so suspend/resume won't work.
How hard would it be to add it?
The code itself is relatively self contained, but the KMS power
management side is a bit ... messy :-) So the real deal is to figure out
how best to "hook it up" there.
There's some duplication
Cheers,
Ben.
From: Benjamin Herrenschmidt <benh@kernel.crashing.org> Date: 2012-04-18 10:37:31
On Wed, 2012-04-18 at 20:35 +1000, Benjamin Herrenschmidt wrote:
On Wed, 2012-04-18 at 09:46 +0200, Andreas Schwab wrote:
quoted
Benjamin Herrenschmidt [off-list ref] writes:
quoted
Note also that KMS doesn't afaik have the power management code that
radeonfb has for those old Mac chipsets, so suspend/resume won't work.
How hard would it be to add it?
The code itself is relatively self contained, but the KMS power
management side is a bit ... messy :-) So the real deal is to figure out
how best to "hook it up" there.
There's some duplication
Argh... bloody x220 touchpad...
So I was saying, there's also some duplication in the area of dynamic
clocks configuration. Some of this could be an issue as afaik, to work
reliably, the suspend/resume code really wants the stuff to be setup
exactly the way the code in radeon_pm does....
But it's definitely worth trying to port it over.
Cheers,
Ben.
From: Michel Dänzer <hidden> Date: 2012-04-18 10:54:24
On Mit, 2012-04-18 at 20:37 +1000, Benjamin Herrenschmidt wrote:=20
On Wed, 2012-04-18 at 20:35 +1000, Benjamin Herrenschmidt wrote:
quoted
On Wed, 2012-04-18 at 09:46 +0200, Andreas Schwab wrote:
quoted
Benjamin Herrenschmidt [off-list ref] writes:
=20
quoted
Note also that KMS doesn't afaik have the power management code tha=
t
quoted
quoted
quoted
radeonfb has for those old Mac chipsets, so suspend/resume won't wo=
rk.
quoted
quoted
=20
How hard would it be to add it?
=20
The code itself is relatively self contained, but the KMS power
management side is a bit ... messy :-)
That's an interesting way to put it, given the hacks to make it work
between radeonfb and uninorth_agp. :) (Which are complicating making at
least hibernation work with KMS on uninorth_agp)
In contrast, radeon KMS uses the standard Linux device suspend/resume
hooks.
quoted
So the real deal is to figure out how best to "hook it up" there.
=20
There's some duplication=20
=20
Argh... bloody x220 touchpad...
=20
So I was saying, there's also some duplication in the area of dynamic
clocks configuration. Some of this could be an issue as afaik, to work
reliably, the suspend/resume code really wants the stuff to be setup
exactly the way the code in radeon_pm does....
Are you referring to radeon_pm in radeonfb or radeon KMS?
Most of the latter isn't used on PPC laptops because it relies on an x86
video BIOS.
--=20
Earthling Michel D=C3=A4nzer | http://www.amd.c=
om
Libre software enthusiast | Debian, X and DRI developer
From: Benjamin Herrenschmidt <benh@kernel.crashing.org> Date: 2012-04-18 11:23:40
On Wed, 2012-04-18 at 12:54 +0200, Michel Dänzer wrote:
On Mit, 2012-04-18 at 20:37 +1000, Benjamin Herrenschmidt wrote:
quoted
On Wed, 2012-04-18 at 20:35 +1000, Benjamin Herrenschmidt wrote:
quoted
On Wed, 2012-04-18 at 09:46 +0200, Andreas Schwab wrote:
quoted
Benjamin Herrenschmidt [off-list ref] writes:
quoted
Note also that KMS doesn't afaik have the power management code that
radeonfb has for those old Mac chipsets, so suspend/resume won't work.
How hard would it be to add it?
The code itself is relatively self contained, but the KMS power
management side is a bit ... messy :-)
That's an interesting way to put it, given the hacks to make it work
between radeonfb and uninorth_agp. :) (Which are complicating making at
least hibernation work with KMS on uninorth_agp)
Oh, I forgot about the AGP hooks indeed... but even that, it's in arch
code so it's not necessarily a huge deal to move it over. IE. It's just
a function pointer to call at the right time that's exported by the
arch.
In contrast, radeon KMS uses the standard Linux device suspend/resume
hooks.
Well, as radeonfb does.
The hack with AGP is so that radeonfb gets to control when the AGP is
suspended/restored as it needs to be done in a specific order and the
device model doesn't provide the right ordering (they are sibling
devices).
There's also an early-wakeup hack but that's orthogonal, it's mostly
useful for debugging and doesn't necessarily need to be ported over.
quoted
Argh... bloody x220 touchpad...
So I was saying, there's also some duplication in the area of dynamic
clocks configuration. Some of this could be an issue as afaik, to work
reliably, the suspend/resume code really wants the stuff to be setup
exactly the way the code in radeon_pm does....
Are you referring to radeon_pm in radeonfb or radeon KMS?
radeonfb.
Most of the latter isn't used on PPC laptops because it relies on an x86
video BIOS.
Right, we might be able to easily port my old code over by simply making
it ppc specific. In radeonfb, it's also used for some thinkpads among
others but KMS does that with the BIOS on these no ? (ie. D2 state).
Cheers,
Ben.
From: Michel Dänzer <hidden> Date: 2012-04-18 13:07:26
On Mit, 2012-04-18 at 21:23 +1000, Benjamin Herrenschmidt wrote:=20
=20
Right, we might be able to easily port my old code over by simply making
it ppc specific. In radeonfb, it's also used for some thinkpads among
others but KMS does that with the BIOS on these no ? (ie. D2 state).
KMS doesn't have any non-BIOS suspend/resume code yet, so it's either
that or no suspend/resume. :)
--=20
Earthling Michel D=C3=A4nzer | http://www.amd.c=
om
Libre software enthusiast | Debian, X and DRI developer
From: Benjamin Herrenschmidt <benh@kernel.crashing.org> Date: 2012-04-18 22:25:53
On Wed, 2012-04-18 at 15:07 +0200, Michel Dänzer wrote:
On Mit, 2012-04-18 at 21:23 +1000, Benjamin Herrenschmidt wrote:
quoted
Right, we might be able to easily port my old code over by simply making
it ppc specific. In radeonfb, it's also used for some thinkpads among
others but KMS does that with the BIOS on these no ? (ie. D2 state).
KMS doesn't have any non-BIOS suspend/resume code yet, so it's either
that or no suspend/resume. :)
Sure, my point is I don't know what happens on those old thinkpads, ie,
what does the BIOS provides to KMS and whether it's a good enough
alternative to the "hand made" D2 approach radeonfb used on them.
But heh, I'm happy to just ignore those, that would make things easier,
in which case we can just have a non-bios pair of suspend/resume calls
provided as empty weak functions, and have a radeon_mac_pm.c providing
more/less the existing radeonfb code for power macs overriding those
weak functions.
If it's mac-only it's going to be easier to deal with.
Cheers,
Ben.