Re: radeon kms on ppc status

[Alex D. <ale...@gm...>]

On Mon, Aug 9, 2010 at 8:24 PM, Benjamin Herrenschmidt
<be...@ke...> 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...@li...
>> https://lists.sourceforge.net/lists/listinfo/dri-devel
>
>
>