public inbox for linuxppc-dev@ozlabs.org 
 help / color / mirror / Atom feed
From: "Gerhard Pircher" <gerhard_pircher@gmx•net>
To: Benjamin Herrenschmidt <benh@kernel•crashing.org>
Cc: linuxppc-dev@ozlabs•org, debian-powerpc@lists•debian.org
Subject: Re: AGPGART driver for ArticiaS - ioremap() problem
Date: Tue, 17 Jan 2006 09:37:57 +0100 (MET)	[thread overview]
Message-ID: <2557.1137487077@www21.gmx.net> (raw)
In-Reply-To: 1137453496.4823.61.camel@localhost.localdomain

> --- Ursprüngliche Nachricht ---
> Von: Benjamin Herrenschmidt <benh@kernel•crashing.org>
> An: Gerhard Pircher <gerhard_pircher@gmx•net>
> Kopie: linuxppc-dev@ozlabs•org, debian-powerpc@lists•debian.org
> Betreff: Re: AGPGART driver for ArticiaS - ioremap() problem
> Datum: Tue, 17 Jan 2006 10:18:15 +1100
> 
> > Ah, okay. So at least the approach to use the Uninorth code was a step
> > in the right direction. But that requires changes in the DRI and X
> > server code, right?
> 
> Not you shouldn't... there are 2 different things here. One is how you
> access the GART table itself. One is how you access the AGP memory (the
> memory that is bound to the GART).
> 
> I'm not 100% sure what of the 2 above cases triggered an error with
> ioremap, I'm not sure what approach should be used, because i don't know
> what your chipset does.
That's the problem: we don't have the datasheet for the ArticiaS. :-( 
But the driver initializes correctly with the Uninorth code now and with the
DRI/DRM code changed. (The code in drm_vm.c checks for Apple's PCI vendor
ID. Therefore I just added a check for MAI's PCI vendor ID.) But the X
server freezes after the login screen is displayed (IIRC the mouse still
works, but the keyboard is dead!?).

BTW: A "agp_special_page" is reserved in init.c. Is this page necessary for
the DRI/DRM drivers to work with the Uninorth driver? I enabled this code
snipped for the AmigaONE too to be on the safe side. :-)

> I would need more infos about the hw there. But the basic idea is:
> 
>  - For the GART table, you don't need to ioremap it (which is generally
> a way to have it non-cacheable I suppose). You can just flush cache
> entries after populating them (see uninorth_insert_memory(), it flushes
> first the pages that are being inserted in the GART as AGP memory is not
> cacheable neither, and at the end of the function, flushes the GART
> entry proper).
There may be another problem: it seems that it is not possible to flush the 
TLB cache of the ArticiaS with a specific register setting. At least MAI
didn't specify a bit for this purpose in the code. I have to do some reverse
engineering here. :-)

>  - The AGP aperture itself. The main issue there is wether your chipset
> makes the AGP aperture visible to the CPU or not. The Apple UniNorth one
> doesn't for example, it;'s only visible to the graphic chip. That is why
> the uninorth driver sets cant_use_aperture to 1. That forces the DRM to
> generate AGP mappings by using the real memory pages and putting them
> together into a virtual mapping instead of doing a direct mapping of the
> AGP aperture on the bus. Most x86 chipsets however _can_, thus a simple
> remapping of pages is enough.
Good question! How would I have to modify the Uninorth driver to use a
direct mapping of the AGP aperture on the bus?

Thanks!

Gerhard

-- 
DSL-Aktion wegen großer Nachfrage bis 28.2.2006 verlängert:
GMX DSL-Flatrate 1 Jahr kostenlos* http://www.gmx.net/de/go/dsl

  reply	other threads:[~2006-01-17  8:37 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-01-15 23:10 AGPGART driver for ArticiaS - ioremap() problem Gerhard Pircher
2006-01-15 23:25 ` Benjamin Herrenschmidt
2006-01-16  8:11   ` Gerhard Pircher
2006-01-16 23:18     ` Benjamin Herrenschmidt
2006-01-17  8:37       ` Gerhard Pircher [this message]
2006-01-17 21:24         ` Benjamin Herrenschmidt
2006-01-18 19:40           ` Gerhard Pircher
2006-01-18 23:09             ` Benjamin Herrenschmidt
2006-01-19  8:50               ` Gerhard Pircher
2006-01-19  9:59                 ` Benjamin Herrenschmidt
2006-01-19 10:52                   ` Gerhard Pircher
2006-01-19 22:09                     ` Benjamin Herrenschmidt
2006-01-20 11:16                       ` Gerhard Pircher
2006-01-20 23:00                         ` Benjamin Herrenschmidt
  -- strict thread matches above, loose matches on Subject: below --
2006-01-23 22:15 Gerhard Pircher
2006-01-21  1:59 Gerhard Pircher
2006-01-21 22:48 ` Benjamin Herrenschmidt
2006-01-23 22:12   ` Gerhard Pircher
2006-01-23 23:15     ` Benjamin Herrenschmidt
2006-01-11 21:00 Gerhard Pircher
2006-01-11 21:52 ` John W. Linville
2006-01-11 22:18   ` Gerhard Pircher
2006-01-12  4:44 ` Benjamin Herrenschmidt
2006-01-12  8:15   ` Gerhard Pircher
2006-01-15 21:48     ` Benjamin Herrenschmidt
2006-01-12 19:15   ` Gerhard Pircher

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=2557.1137487077@www21.gmx.net \
    --to=gerhard_pircher@gmx$(echo .)net \
    --cc=benh@kernel$(echo .)crashing.org \
    --cc=debian-powerpc@lists$(echo .)debian.org \
    --cc=linuxppc-dev@ozlabs$(echo .)org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox