Re: radeon kms on ppc status
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
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
radeon kms on ppc status
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 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: radeon kms on ppc status
2010/8/9 Benjamin Herrenschmidt b...@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 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: radeon kms on ppc status
2010/8/9 Benjamin Herrenschmidt b...@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 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: radeon kms on ppc status
On Mon, 2010-08-09 at 03:18 -0400, Alex Deucher wrote: 2010/8/9 Benjamin Herrenschmidt b...@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 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: radeon kms on ppc status
- 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 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: radeon kms on ppc status
On Mon, Aug 9, 2010 at 8:24 PM, Benjamin Herrenschmidt b...@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 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
