Mailinglist Archive: radeonhd (265 mails)

["Alex Deucher" <alexdeucher@xxxxxxxxx>]

On Mon, Jan 12, 2009 at 8:54 PM, Sytse Wielinga
<s.b.wielinga@xxxxxxxxxxxxxxxxxx> wrote:
> Hi Alex,
>
> I'm addressing this to you (Alex), as you seem to be The Man to talk to about
> r6xx dri support at the moment.  CC'ing both the radeonhd and the dri-devel
> mailing lists.

Thanks for debugging this!

> Good.
>
> I tried running the r6xx-r7xx-support branch from drm/xf86-video-radeonhd with
> my RV670 card (HD 3870) on an amd64 platform, but it failed, giving me an
> irrecoverable black screen, and an OOPS because of a null pointer dereference.
>
> It became apparent the cause was an ioremap in r600_cp.c failing, and the
> result wasn't checked, so it didn't quite fail gracefully.
>
> It seems to me (I must admit I don't really know what I'm talking about
> though, I haven't looked into the way memory is handled in x86 cpus yet)
> that the correct fix would be to use ioremap_wc (which maps to ioremap_nocache
> on non-PAT-enabled kernels) instead.  It works for me: with EXA enabled, I get
> a working X instance, with lots of slowness and glitches but I guess that's
> expected behavior at the moment.
>
> Below is a patch, which does four things:
>
>  - Change drm_core_ioremap to drm_core_ioremap_wc (note that this is already
>   the function that's called in the r3xx code in the exact same place; I
>   don't know what went wrong here, but someone missed something)

The patch is correct.  The PAT fix got missed when we merged the r6xx
branch into master.

>  - Add a check for this specific drm_core_ioremap(_wc) invocation failing; any
>   failure should return -EINVAL.  Also, when dev_priv->pcigart_offset_set
>   isn't set, it should return -EINVAL, and not just continue as if nothing's
>   amiss
>
>  - Add many debugging messages.  Your opinion on this may be different from
>   mine, so apply whatever you deem useful.
>
>   Note particularly that I added messages for succeeding or failing ioremaps
>   and ioremapfrees

These seem fine.  I've gone ahead and committed the radeon chunk:
fd3b361a540c4d370c33ea6a472ad2b24928a930


>  - drm_core_ioremap_wc was enabled only on 2.6.26+ kernels, which seems odd.
>   I checked, and ioremap_wc has been in the kernel a *long* time (on x86);
>   there was a #define to check whether it exists on the current arch, so I
>   changed drm_core_ioremap_wc to be always present (it's used unconditionally
>   in radeon_cp.c anyway, so it seems to be a sane idea to define
>   drm_core_ioremap_wc to do the right thing whether ioremap_wc is present or
>   not).

This is probably fine as well, but I'd like to get Dave's opinion first.

Thanks!

Alex
-- 
To unsubscribe, e-mail: radeonhd+unsubscribe@xxxxxxxxxxxx
For additional commands, e-mail: radeonhd+help@xxxxxxxxxxxx