> 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
