Re: [XFree86] Re: Have you dropped radeon 7200 support?
On Mon, 27 Jan 2003, tsi wrote: On Sat, 25 Jan 2003, hy0 wrote: Anyway, back to this patch, why does it have to set MEM_CNTL to 0? If you simply comment off OUTREG(RADEON_MEM_CNTL, 0) in PreInt10Save, will the patch still work for your special cases? It's interesting how these special cases out-number the single more common case of not having to re-POST the adapter... Be that as it may, the attached should work as a temporary workaround. Hello, The Hui.diff.gz patch attached to Marc's email does not work in my situation. I have a primary AGP Radeon VE and a secondary PCI Radeon 7000 on an x86 box. With version 1.79 (or 1.81) of radeon_driver.c, the text mode on the secondary PCI Radeon 7000 gets corrupted when I run XFree86 on it the second time; everything else works fine. This corruption doesn't occur if I comment out PreInt10Save(), or if I follow Hui's suggestion and just comment out the OUTREG(RADEON_MEM_CNTL,0) line in PreInt10Save(). It does still occur, however, if I just apply Hui.diff.gz. Thanks, Wayne ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
Re: [XFree86] Re: Have you dropped radeon 7200 support?
On Wed, 29 Jan 2003, Wayne Whitney wrote: Anyway, back to this patch, why does it have to set MEM_CNTL to 0? If you simply comment off OUTREG(RADEON_MEM_CNTL, 0) in PreInt10Save, will the patch still work for your special cases? It's interesting how these special cases out-number the single more common case of not having to re-POST the adapter... Be that as it may, the attached should work as a temporary workaround. Hello, The Hui.diff.gz patch attached to Marc's email does not work in my situation. I have a primary AGP Radeon VE and a secondary PCI Radeon 7000 on an x86 box. With version 1.79 (or 1.81) of radeon_driver.c, the text mode on the secondary PCI Radeon 7000 gets corrupted when I run XFree86 on it the second time; everything else works fine. This corruption doesn't occur if I comment out PreInt10Save(), or if I follow Hui's suggestion and just comment out the OUTREG(RADEON_MEM_CNTL,0) line in PreInt10Save(). It does still occur, however, if I just apply Hui.diff.gz. Yes, I'm aware of that. The logs you posted in the other discussion also show an inability to read the PCI Radeon's BIOS when the server is re-run. Please be patient. Marc. +--+---+ | Marc Aurele La France | work: 1-780-492-9310 | | Computing and Network Services | fax:1-780-492-1729 | | 352 General Services Building | email: [EMAIL PROTECTED] | | University of Alberta +---+ | Edmonton, Alberta | | | T6G 2H1 | Standard disclaimers apply| | CANADA | | +--+---+ XFree86 Core Team member. ATI driver and X server internals. ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
Re: [XFree86] Re: Have you dropped radeon 7200 support?
On Tue, 28 Jan 2003, hy0 wrote: It's interesting how these special cases out-number the single more common case of not having to re-POST the adapter... I agree the re-POST bug could be quite common for secondary card, since BIOS code itself may not be well designed/tested to run under such conditions. I think a BIOS bug report should be filed. To that end, I'll ask Mike for a BIOS Kit. Be that as it may, the attached should work as a temporary workaround. Looks like a good workaround, thanks. Well, it's not perfect by any means. There are corner cases it doesn't deal with. Also, judging from the 7000 thread on devel, diddling MPP_TB_CONFIG doesn't always work. But it'll have to do for 4.3. I've come to the conclusion that this should be revisited after 4.3. Marc. +--+---+ | Marc Aurele La France | work: 1-780-492-9310 | | Computing and Network Services | fax:1-780-492-1729 | | 352 General Services Building | email: [EMAIL PROTECTED] | | University of Alberta +---+ | Edmonton, Alberta | | | T6G 2H1 | Standard disclaimers apply| | CANADA | | +--+---+ XFree86 Core Team member. ATI driver and X server internals. ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
Re: [XFree86] Re: Have you dropped radeon 7200 support?
On Sat, 25 Jan 2003, hy0 wrote: Thanks for the explanations, now I can see what this is about. However I still have some concerns about this code. Indeed, Radeon chips do have 0x1c0 (misnamed MPP_TB_CONFIG) as SEPROM_CNTL register. Modifying/restoring its SCK_PRESCALE field is unlikely to be the cause of this screen corruption problem. In the current code path, even for a properly POSTed card, MEM_CNTL is set to zero and then restored back. This step may cause some side effect to the memory controller. Properly initializing MEM_CNTL/MEM_SIZE should take several steps (I may miss something): 1. wait for memory control idle (MC_STATUS). 2. configure each channel (MEM_CNTL). 3. reset memory (MEM_SDRAM_MOD_REG). 4. check if each channel works correctly. Simply setting MEM_CNTL to zero and then restoring it back may put memory controller in some bad state. To me, this only means more registers need to be saved, and later restored in a specific order. It should be possible to determine such a sequence from the BIOS init code. It would be for Mach64 and Rage128 variants, I know. But I don't happen to have a Radeon BIOS Kit at the moment. Asic initialization involves not only register writes with correct values, but also state waiting, delaying, resetting, etc. Yes, there are initialization tables in Radeon chips embedded in the BIOS images like in Mach64 and R128, but these tables only got standardized in the relative new versions of BIOS. This means using these tables will introduce compatibility problems with old chip/BIOS. While it's possible to resolve these compatibility problems, it will take a lot of work and tests, don't think it's an option for the upcoming v4.3. Anyway, back to this patch, why does it have to set MEM_CNTL to 0? If you simply comment off OUTREG(RADEON_MEM_CNTL, 0) in PreInt10Save, will the patch still work for your special cases? It's interesting how these special cases out-number the single more common case of not having to re-POST the adapter... I agree the re-POST bug could be quite common for secondary card, since BIOS code itself may not be well designed/tested to run under such conditions. Be that as it may, the attached should work as a temporary workaround. Looks like a good workaround, thanks. Hui Marc. ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
