[Openchrome-devel] K8M800 artifacts, trac #145, trac #164

[Thomas Hellström]

Gabriel Mansi wrote:
> On Thu, 2008-03-20 at 10:05 +0100, Thomas Hellstr?m wrote:
>   
>> Gabriel Mansi wrote:
>>     
>>> On Wed, 2008-03-19 at 21:55 +0100, Thomas Hellstr?m wrote:
>>>   
>>>       
>>>> Gabriel Mansi wrote:
>>>>     
>>>>         
>>>>> On Tue, 2008-03-18 at 20:13 +0100, Thomas Hellstr?m wrote:
>>>>>   
>>>>>       
>>>>>           
>>>>>> There'll be some more optimizing / stablizing work for AGP DMA in a
>>>>>> week 
>>>>>> or so, but I'll ask Dave not to push anything until it's considered 
>>>>>> stable. I think the code in DRM now is reasonably stable but not
>>>>>> really 
>>>>>> optimal.
>>>>>>
>>>>>> That AGP command reader is really screwed. There's a register that
>>>>>> you 
>>>>>> read to determine where it is currently reading. Locations that are 
>>>>>> newly read by the command reader can supposedly be reused for new
>>>>>> data....
>>>>>>
>>>>>> However every now and again the register shows that the command
>>>>>> reader 
>>>>>> has read "too far", and then suddenly it goes in the reverse
>>>>>> direction.....
>>>>>>     
>>>>>>         
>>>>>>             
>>>>> I found that reg_pause_addr in via_dri.c was incorrectly assigned to
>>>>> 0x40c instead of 0x418 for the CX700:
>>>>> http://www.openchrome.org/trac/changeset/556
>>>>> With the wrong pause address register I was getting a lot of messages
>>>>> like this:
>>>>>
>>>>> [drm:via_hook_segment] *ERROR* Paused at incorrect address. 0xf1edb500,
>>>>> 0xf1eda500 0x00000000
>>>>> [drm:via_hook_segment] *ERROR* Paused at incorrect address. 0xf1edc500,
>>>>> 0xf1eda500 0x00000000
>>>>> [drm:via_hook_segment] *ERROR* Paused at incorrect address. 0xf1edd500,
>>>>> 0xf1eda500 0x00000000
>>>>>
>>>>> I wonder if the other chipsets (VM800 and PM800) should be using that
>>>>> register as well. VIA is using 0x418 for all chipsets.
>>>>>
>>>>> Regards,
>>>>> Gabriel.
>>>>>
>>>>>   
>>>>>       
>>>>>           
>>>> Gabriel,
>>>> I'm running a CX700-M2 without obvious problems with 0x40C, but I'll 
>>>> check tomorrow with 0x418. The PM800 and CN400 both worked well with 
>>>> 0x40C when I tried the last time.
>>>>
>>>>     
>>>>         
>>> Thomas,
>>> I made a few tests again, I am sure that register makes the difference.
>>> I am testing quake 3 demo, I can play it only setting that register to
>>> 0x418. I am rebooting the machine after each test.
>>> Note that glxgears and the mesa demos runs with both registers 0x418 and
>>> 0x40c, also with the old dma code [1] everything works with any of those
>>> two registers.
>>> I would appreciate any suggestion to make a serious test.
>>>
>>> Regards,
>>> Gabriel.
>>>   
>>>       
>> Gabriel, can you try out the attached patch. I'm interested in seeing
>> 1) Whether you get a warning on "paused on the wrong address".
>> 2) Whether the code works anyway.
>> Both with 0x40c and 0x418.
>>
>>     
> Thomas,
>
> With your patch applied it works with both registers without warning
> messages, so, to summarize my tests:
>
> patch applied    register    working   messages
> yes              0x40c       yes       none
> yes              0x418       yes       none
> no               0x40c       no        Paused at incorrect address
> no               0x418       yes       none
>
> The performance seems to be similar in all cases, probably a little bit
> smoother without the patch applied. I still think that the register must
> be 0x418 because, according to the documentation, 0x40c is used for
> something else.
>
>   
OK.  I looked a bit at the differences between the registers. 0x40c 
seems to be 0x20 ahead of 0x418, but that should be taken care of with 
dev_priv->dma_diff. Also 0x418 seems to update more regularly. Otherwise 
they seem to show basically the same data. My docs shows something 
entirely different for 0x40c, so I guess the docs are a little bit crappy.

The patch adds some extra NOP dma data to each command submission, to 
possibly shorten the window the cpu needs to wait for pause. I'll see if 
I can rework that a bit.

Thanks for testing.

/Thomas





> Regards,
> Gabriel.
>