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... Be that as it may, the attached should work as a temporary workaround. Marc. PS: Below is HP's explanation for this change that Egbert & I were party to. > From [EMAIL PROTECTED] Mon Jan 27 10:29:13 2003 > Date: Thu, 3 Oct 2002 11:17:25 -0600 (MDT) > From: Marc Aurele La France <[EMAIL PROTECTED]> > To: Egbert Eich <[EMAIL PROTECTED]> > Cc: Jeff Wiedemeier <[EMAIL PROTECTED]> > Subject: Re: Your DOMAIN/RADEON fixes > On Fri, 27 Sep 2002, Egbert Eich wrote: > > Jeff Wiedemeier writes: > > > > We would like to ask you if you can shed some more light on > > > > what your settings to MEM_CTL, MEMSIZE and MPP_TB_CONFIG do. > > > > At least on with my RADEON boards it appeared to be sufficient > > > > to tweak MPP_TB_CONFIG. > > > The 3 registers are actually part of 2 different fixes. MEM_CTL and > > > MEMSIZE are needed (at least by R100 radeons) because the card's BIOS > > > does things incorrectly if run twice. Specifically, it seems to end up > > > with mismatched bank configuration if MEMSIZE is not zero when the BIOS > > > is run. This was an issue for us because the SRM console ran the BIOS > > > and then XFree86 would run the BIOS again (we still need XFree86 to run > > > the BIOS in any case because the SRM console only initializes the > > > "primary" card). The fix involves a save/init/check/restore sequence, > > > but once the init was put in, I've never seen it actually need to do the > > > restore (the check checked out) > > OK, this sounds reasonable to me. It explains why you didn't > > touch individual bits but zeroed the entire register. > > If I don't forget I'll add a comment to the code once Kevin > > is done with it so this question doesn't araise again. > > > MPP_TB_CONFIG was for an issue on the Radeon 7500 > > > (RV200). Unfortunately, I can't elaborate too much on what exactly it > > > does, because it's a fix we got from ATI without much detail. The > > > problem it fixed, though, is that without the MPP_TB_CONFIG change the > > > BIOS ROM can't be read after the BIOS has been run. > > Thanks for the explanation! > Yes, indeed. This should be tacked onto whatever you send to Kevin. > 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.
Hui.diff.gz
Description: Binary data
