radeon kms on ppc status

radeon kms on ppc status

[Benjamin Herrenschmidt]

Just a quick status in case others are interested and want to help
as I have -very- little time.

I'm currently testing on a rv350 based aluminium powerbooks.
The basic stuff works provided you stay away from AGP. Here's
things in no special order I noticed:

  - AGP: locks up before the console shows anything useful, that's
going to be fun to debug without a serial port ... I'll see what I can
with netconsole or some firewire hack. Works fine with PCI GART.

  - transition from offb. If both kms and offb are built-in, the transition
leads to panel blooming. Note that it seems broken with nouveau on the G5 as
well, I suspect we are passing a crap mode when picking up from offb at boot.

  - Power Management.

    - Sleep/wakeup needs to be ported over from radeonfb (will also
be useful for some x86 models). 

    - The other fancy stuff... well, we could make up profiles on powerbooks
I suppose, at least dynclk can be enable always and I'm sure we can make up
default profiles with something like half clock speed, what do you reckon ?

Cheers,
Ben.



------------------------------------------------------------------------------
This SF.net email is sponsored by 

Make an app they can't live without
Enter the BlackBerry Developer Challenge
http://p.sf.net/sfu/RIM-dev2dev 
--

Re: radeon kms on ppc status

[Alex Deucher]

2010/8/9 Benjamin Herrenschmidt <benh@kernel.crashing.org>:
> Just a quick status in case others are interested and want to help
> as I have -very- little time.
>

Unfortunately, I don't have much spare time to dedicate to this either
and I don't have any ppc machines.

> I'm currently testing on a rv350 based aluminium powerbooks.
> The basic stuff works provided you stay away from AGP. Here's
> things in no special order I noticed:
>
>  - AGP: locks up before the console shows anything useful, that's
> going to be fun to debug without a serial port ... I'll see what I can
> with netconsole or some firewire hack. Works fine with PCI GART.

I think Michel had it working with 1x AGP.

>
>  - transition from offb. If both kms and offb are built-in, the transition
> leads to panel blooming. Note that it seems broken with nouveau on the G5 as
> well, I suspect we are passing a crap mode when picking up from offb at boot.
>
>  - Power Management.
>
>    - Sleep/wakeup needs to be ported over from radeonfb (will also
> be useful for some x86 models).
>

It would be nice to get this ported over.

>    - The other fancy stuff... well, we could make up profiles on powerbooks
> I suppose, at least dynclk can be enable always and I'm sure we can make up
> default profiles with something like half clock speed, what do you reckon ?

The dynclks in the drm should work on the ppc.  As for the power
profiles, something like a half clock should work.

Probably also useful to come up with some way to add backlight control
to the macs without conflicting with the acpi backlight stuff on x86.

Alex

------------------------------------------------------------------------------
This SF.net email is sponsored by 

Make an app they can't live without
Enter the BlackBerry Developer Challenge
http://p.sf.net/sfu/RIM-dev2dev 
--

Re: radeon kms on ppc status

[Benjamin Herrenschmidt]

On Mon, 2010-08-09 at 03:18 -0400, Alex Deucher wrote:
> 2010/8/9 Benjamin Herrenschmidt <benh@kernel.crashing.org>:
> > Just a quick status in case others are interested and want to help
> > as I have -very- little time.
> >
> 
> Unfortunately, I don't have much spare time to dedicate to this either
> and I don't have any ppc machines.

I guessed :-) We'll see what we manage.

> >  - AGP: locks up before the console shows anything useful, that's
> > going to be fun to debug without a serial port ... I'll see what I can
> > with netconsole or some firewire hack. Works fine with PCI GART.
> 
> I think Michel had it working with 1x AGP.

Interesting. Michel, any idea what the problems might be ?

> >  - transition from offb. If both kms and offb are built-in, the transition
> > leads to panel blooming. Note that it seems broken with nouveau on the G5 as
> > well, I suspect we are passing a crap mode when picking up from offb at boot.
> >
> >  - Power Management.
> >
> >    - Sleep/wakeup needs to be ported over from radeonfb (will also
> > be useful for some x86 models).
> >
> 
> It would be nice to get this ported over.

Most definitely. I'm still getting my head around the KMS driver
structure.

> >    - The other fancy stuff... well, we could make up profiles on powerbooks
> > I suppose, at least dynclk can be enable always and I'm sure we can make up
> > default profiles with something like half clock speed, what do you reckon ?
> 
> The dynclks in the drm should work on the ppc.  As for the power
> profiles, something like a half clock should work.

Ok. Here too, trying to sort out what the driver is doing for now, and
we'll move from there.

> Probably also useful to come up with some way to add backlight control
> to the macs without conflicting with the acpi backlight stuff on x86.

Yup, forgot about that one. Shouldn't be -too- hard.

Cheers,
Ben.

> Alex
> 
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by 
> 
> Make an app they can't live without
> Enter the BlackBerry Developer Challenge
> http://p.sf.net/sfu/RIM-dev2dev 
> --
> _______________________________________________
> Dri-devel mailing list
> Dri-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/dri-devel



------------------------------------------------------------------------------
This SF.net email is sponsored by 

Make an app they can't live without
Enter the BlackBerry Developer Challenge
http://p.sf.net/sfu/RIM-dev2dev 
--

Re: radeon kms on ppc status

[Dave Airlie]

2010/8/9 Benjamin Herrenschmidt <benh@kernel.crashing.org>:
> Just a quick status in case others are interested and want to help
> as I have -very- little time.
>
> I'm currently testing on a rv350 based aluminium powerbooks.
> The basic stuff works provided you stay away from AGP. Here's
> things in no special order I noticed:
>
>  - AGP: locks up before the console shows anything useful, that's
> going to be fun to debug without a serial port ... I'll see what I can
> with netconsole or some firewire hack. Works fine with PCI GART.
>
>  - transition from offb. If both kms and offb are built-in, the transition
> leads to panel blooming. Note that it seems broken with nouveau on the G5 as
> well, I suspect we are passing a crap mode when picking up from offb at boot.
>

wierd offb->nouveau worked on my G5, handoff doesn't do anything
technically other than just remove offb from the system,
and start the driver, so it should be like setting an initial mode.
Unless the newer early handover messed it up.

>  - Power Management.
>
>    - Sleep/wakeup needs to be ported over from radeonfb (will also
> be useful for some x86 models).

I've started to port this on the M7 in a thinkpad on my desk, in
theory it should save battery life as it appears currently the GPU
doesn't go into D3 properly,
however I haven't figured out exactly which bits are required, or
proven its saving battery (the battery is a little old so I can't be
sure).

Dave.

------------------------------------------------------------------------------
This SF.net email is sponsored by 

Make an app they can't live without
Enter the BlackBerry Developer Challenge
http://p.sf.net/sfu/RIM-dev2dev 
--

Re: radeon kms on ppc status

[Benjamin Herrenschmidt]

> >  - transition from offb. If both kms and offb are built-in, the transition
> > leads to panel blooming. Note that it seems broken with nouveau on the G5 as
> > well, I suspect we are passing a crap mode when picking up from offb at boot.
> >
> 
> wierd offb->nouveau worked on my G5, handoff doesn't do anything
> technically other than just remove offb from the system,
> and start the driver, so it should be like setting an initial mode.
> Unless the newer early handover messed it up.

Yeah, not sure what's up, I suspect the driver get passed a bogus mode
in the initial set_par() when doing the handover. I'll see what I can
find out once I dig out my dual G5 which has a serial port :-)

> >  - Power Management.
> >
> >    - Sleep/wakeup needs to be ported over from radeonfb (will also
> > be useful for some x86 models).
> 
> I've started to port this on the M7 in a thinkpad on my desk, in
> theory it should save battery life as it appears currently the GPU
> doesn't go into D3 properly,
> however I haven't figured out exactly which bits are required, or
> proven its saving battery (the battery is a little old so I can't be
> sure).

Ok. So there's basically two different things in that code. Merely D2
sleep and re-POST (aka D3 cold).

The former is supported on M6, M7 and M9 (at least some of these, the
code might need tweaks to work on non-powerbooks). In this case, we are
dealing with cases where the chip isn't powered down by the motherboard
or firmware. I don't actually know for sure -what- happens to it on the
relevant powerbooks actually, I suspect the clocks might go off, and/or
the VRAM is off. IE. If I don't run that code, I don't come back.

The code was essentially contributed by ATI btw. 

Then there's code for M10/M11 which re-POSTs the chip. It mostly relies
on saving as much registers as can be and restoring things in the right
order, along with the right magic to restart PLLs, MC, DLLs, ...

This code was written after analyzing the MacOS driver IO traces. Some
parts however cannot be saved/restored (memory init sequence), so in
that case, I have a "default" sequence, and I have code to retreive a
different one from the OF device-tree when available. For that code to
work more generically/better on x86's, we might want to add code to
extract that from the BIOS tables.

Now, I need to figure out how to make all this fit in our driver
architecture. Dave, can I see your patches ? That might give me some
good hints to get started. Hopefully, most of that can be kept safely in
the "r100" files and we can avoid clobbering too much of the core
drivers.

Cheers,
Ben.

> Dave.
> 
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by 
> 
> Make an app they can't live without
> Enter the BlackBerry Developer Challenge
> http://p.sf.net/sfu/RIM-dev2dev 
> --
> _______________________________________________
> Dri-devel mailing list
> Dri-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/dri-devel



------------------------------------------------------------------------------
This SF.net email is sponsored by 

Make an app they can't live without
Enter the BlackBerry Developer Challenge
http://p.sf.net/sfu/RIM-dev2dev 
--

Re: radeon kms on ppc status

[Alex Deucher]

On Mon, Aug 9, 2010 at 8:24 PM, Benjamin Herrenschmidt
<benh@kernel.crashing.org> wrote:
>
>> >  - transition from offb. If both kms and offb are built-in, the transition
>> > leads to panel blooming. Note that it seems broken with nouveau on the G5 as
>> > well, I suspect we are passing a crap mode when picking up from offb at boot.
>> >
>>
>> wierd offb->nouveau worked on my G5, handoff doesn't do anything
>> technically other than just remove offb from the system,
>> and start the driver, so it should be like setting an initial mode.
>> Unless the newer early handover messed it up.
>
> Yeah, not sure what's up, I suspect the driver get passed a bogus mode
> in the initial set_par() when doing the handover. I'll see what I can
> find out once I dig out my dual G5 which has a serial port :-)
>
>> >  - Power Management.
>> >
>> >    - Sleep/wakeup needs to be ported over from radeonfb (will also
>> > be useful for some x86 models).
>>
>> I've started to port this on the M7 in a thinkpad on my desk, in
>> theory it should save battery life as it appears currently the GPU
>> doesn't go into D3 properly,
>> however I haven't figured out exactly which bits are required, or
>> proven its saving battery (the battery is a little old so I can't be
>> sure).
>
> Ok. So there's basically two different things in that code. Merely D2
> sleep and re-POST (aka D3 cold).
>
> The former is supported on M6, M7 and M9 (at least some of these, the
> code might need tweaks to work on non-powerbooks). In this case, we are
> dealing with cases where the chip isn't powered down by the motherboard
> or firmware. I don't actually know for sure -what- happens to it on the
> relevant powerbooks actually, I suspect the clocks might go off, and/or
> the VRAM is off. IE. If I don't run that code, I don't come back.
>
> The code was essentially contributed by ATI btw.
>
> Then there's code for M10/M11 which re-POSTs the chip. It mostly relies
> on saving as much registers as can be and restoring things in the right
> order, along with the right magic to restart PLLs, MC, DLLs, ...
>
> This code was written after analyzing the MacOS driver IO traces. Some
> parts however cannot be saved/restored (memory init sequence), so in
> that case, I have a "default" sequence, and I have code to retreive a
> different one from the OF device-tree when available. For that code to
> work more generically/better on x86's, we might want to add code to
> extract that from the BIOS tables.
>

The drm can already post the chip using the bios tables on x86, so
we'd only need that for macs.

> Now, I need to figure out how to make all this fit in our driver
> architecture. Dave, can I see your patches ? That might give me some
> good hints to get started. Hopefully, most of that can be kept safely in
> the "r100" files and we can avoid clobbering too much of the core
> drivers.
>

For chip init, you'd want to hook asic init stuff into
radeon_combios_asic_init() in radeon_combios.c.  That function uses
the bios tables to init the chip.  For the D2 stuff, you'd want to
hook that into the r100_suspend/resume functions in r100.c and
r300_suspend/resume in r300.c.

Alex

> Cheers,
> Ben.
>
>> Dave.
>>
>> ------------------------------------------------------------------------------
>> This SF.net email is sponsored by
>>
>> Make an app they can't live without
>> Enter the BlackBerry Developer Challenge
>> http://p.sf.net/sfu/RIM-dev2dev
>> --
>> _______________________________________________
>> Dri-devel mailing list
>> Dri-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/dri-devel
>
>
>

------------------------------------------------------------------------------
This SF.net email is sponsored by 

Make an app they can't live without
Enter the BlackBerry Developer Challenge
http://p.sf.net/sfu/RIM-dev2dev 
--

Re: radeon kms on ppc status

[Michel Dänzer]

On Mon, 2010-08-09 at 16:16 +1000, Benjamin Herrenschmidt wrote: 
> 
> I'm currently testing on a rv350 based aluminium powerbooks.

Same here. :)


>   - AGP: locks up before the console shows anything useful, that's
> going to be fun to debug without a serial port ... I'll see what I can
> with netconsole or some firewire hack. Works fine with PCI GART.

AGP 1x works mostly fine for me. Not sure what the problem is with
higher speeds (4x used to work fine with UMS) but I guess most likely
some kind of coherency issue which only matters now that we're
dynamically changing GTT bindings.

The reason you don't get anything useful with higher AGP speeds is that
the attempt to reset the locked-up GPU kills the machine. I tried
tracking this down with netconsole but the only possibly relevant info
I've got out of that yet is that there seem to be some machine checks
occurring.


> - transition from offb. If both kms and offb are built-in, the transition
> leads to panel blooming.

I only tried this once but AFAIR it was the same for me.


> - The other fancy stuff... well, we could make up profiles on powerbooks
> I suppose, at least dynclk can be enable always and I'm sure we can make up
> default profiles with something like half clock speed, what do you reckon ?

Might be nice, though IME the CPU seems to suck more power anyway. :)

IMO the highest priority missing feature is backlight control, followed
by suspend/resume.


Note that there's also still outstanding KMS related endianness issues
in the Mesa tree, in particular concerning r300g but also the classic
driver related to the OpenGL blit functionality. I've been meaning to
clean up and push my hacks for those but had little time recently.


-- 
Earthling Michel Dänzer           |                http://www.vmware.com
Libre software enthusiast         |          Debian, X and DRI developer

------------------------------------------------------------------------------
This SF.net email is sponsored by 

Make an app they can't live without
Enter the BlackBerry Developer Challenge
http://p.sf.net/sfu/RIM-dev2dev 
--
_______________________________________________
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: radeon kms on ppc status

[Benjamin Herrenschmidt]

On Tue, 2010-08-10 at 14:56 +0200, Michel Dänzer wrote:
> On Mon, 2010-08-09 at 16:16 +1000, Benjamin Herrenschmidt wrote: 
> > 
> > I'm currently testing on a rv350 based aluminium powerbooks.
> 
> Same here. :)

Heh. Well, I also have the G5 with rv350, and that has a serial port :-)

> >   - AGP: locks up before the console shows anything useful, that's
> > going to be fun to debug without a serial port ... I'll see what I can
> > with netconsole or some firewire hack. Works fine with PCI GART.
> 
> AGP 1x works mostly fine for me. Not sure what the problem is with
> higher speeds (4x used to work fine with UMS) but I guess most likely
> some kind of coherency issue which only matters now that we're
> dynamically changing GTT bindings.

Ok. Well, we -know- we have a problem with AGP anyways bcs of that dual
cachable/non-cachable mapping issue. I'll see if I can find ways to work
around that. If not, I don't really mind sticking to x1, it's old
machines and it's better than nothing.

> The reason you don't get anything useful with higher AGP speeds is that
> the attempt to reset the locked-up GPU kills the machine. I tried
> tracking this down with netconsole but the only possibly relevant info
> I've got out of that yet is that there seem to be some machine checks
> occurring.

Right, makes sense if the card doesn't answer to an MMIO access. I'll
see what I can do.

> > - transition from offb. If both kms and offb are built-in, the transition
> > leads to panel blooming.
> 
> I only tried this once but AFAIR it was the same for me.

I found some stuff there and fixed some on the G5. It now works there, I
haven't tried again on the powerbook yet. One is the patch I send to do
an early transition like nouveau does. The other one is you need to make
sure CONFIG_VT_HW_CONSOLE_BINDING is set. Without that,
unregister_framebuffer() of offb fails bcs fbcon refuses to unbind the
last console. So you end up with fb1 for the drm, while fb0 remains on
offb and everything breaks. We might want to make this a hard
dependency.

> > - The other fancy stuff... well, we could make up profiles on powerbooks
> > I suppose, at least dynclk can be enable always and I'm sure we can make up
> > default profiles with something like half clock speed, what do you reckon ?
> 
> Might be nice, though IME the CPU seems to suck more power anyway. :)

Right.

> IMO the highest priority missing feature is backlight control, followed
> by suspend/resume.

Agreed.

> Note that there's also still outstanding KMS related endianness issues
> in the Mesa tree, in particular concerning r300g but also the classic
> driver related to the OpenGL blit functionality. I've been meaning to
> clean up and push my hacks for those but had little time recently.

Ok. I'll leave you to those because I really know near to nothing about
GL and Mesa ... from my quick tests, things seem to work allright with
compiz on the G5 and the powerbook tho with whatever Mesa's in lucid.

Also, the few tests I did on the quad G5 with nvidia 6600 & nouveau were
interesting as well (gallium in that case). nouveau itself works well,
but the mesa part doesn't (renders black). The interesting thing tho was
that all the SW rendering path seemed to work well, which is a nice
change from not that long ago where all the fallbacks were endian
broken. I suspect you may have done some fixing there :-)

Cheers,
Ben.



------------------------------------------------------------------------------
This SF.net email is sponsored by 

Make an app they can't live without
Enter the BlackBerry Developer Challenge
http://p.sf.net/sfu/RIM-dev2dev 
--
_______________________________________________
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel