--=-YwkqvWXIgteSMf3Xp7qS
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable

On Thu, 2007-03-22 at 11:41 -0400, Michael Lorenz wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>=20
> Hello,
>=20
> On Mar 21, 2007, at 14:17, Juan RP wrote:
>=20
> > Hi, I have built a kernel with DRM support for my i945 chip.
> >
> > But xorg reports:
> >
> > drmOpenDevice: node name is /dev/dri/card0
> > drmOpenDevice: open result is 9, (OK)
> > drmOpenDevice: node name is /dev/dri/card0
> > drmOpenDevice: open result is 9, (OK)
> > drmOpenByBusid: Searching for BusID pci:0000:00:02.0
> > drmOpenDevice: node name is /dev/dri/card0
> > drmOpenDevice: open result is 9, (OK)
> > drmOpenByBusid: drmOpenMinor returns 9
> > drmOpenByBusid: drmGetBusid reports pci:0000:00:02.0
> > (II) I810(0): [drm] DRM interface version 1.2
> > (II) I810(0): [drm] created "i915" driver at busid "pci:0000:00:02.0"
> > (II) I810(0): [drm] added 8192 byte SAREA at 0xffff800002956000
> > (II) I810(0): [drm] drmMap failed
> > (EE) I810(0): [dri] DRIScreenInit failed. Disabling DRI.
>=20
> Smells like amd64.
> I think we need to rewrite the memory management and mapping code. It=20
> makes a whole bunch of assumptions that are really only true on i386 (=20
> and probably not even there )
> So, in no particular order:
> - - get rid of vtophys(), atop() and so on in *mmap(), that's very un-MI
> - - use bus_dmamem_alloc() and friends to allocate DMA-happy memory=20
> instead of malloc()
>    and vtophys()
> - - do not assume that physical address =3D=3D bus address - I think ever=
yone=20
> can name at least
>    two platforms where that's not true but where we'll want to have 3D=20
> graphics
> I think for each DMA segment we need to store the kernel virtual=20
> address ( not sure if we always need that though ), something to hand=20
> to *mmap() and the bus address, bus_dma*() provides all that in a=20
> machine-independent manner.

Yeah, this has long been a problem with our DRM.  Doing the right thing
is going to cause a good bit of churn I think, so I've never actually
completed the work yet.

The trick here is that the os-independent driver code currently doesn't
have any bus_dma-ish syncing in it -- it's based on having linux
pci_alloc_consistent()-ish buffers, where no syncing is necessary.
Ideally, from the BSDs we'd have equivalent functionality ("please
allocate for me DMA-able memory with the given constraints, which is
freely accessible from device or cpu").  I think FreeBSD's bus_dma can
do ready that, but the documentation wasn't quite as strongly worded as
I would have liked.=20

The interesting thing that's different about the DRM's bus memory
allocations compared to most bus_dma allocations that are done is that
we generally don't need physically contiguous memory, but we need a
bunch of it (8MB minimum for ATI PCIGART, for example), we'll hang onto
it for a long time, and we need to map it from userland (which pretty
much means no bouncing).  There are exceptions where we have small
contiguous allocations that are used for status pages or page
directories.  Those are also long-lived, and status pages need to be
coherent for sure since they're read outside of the kernel.

That said, the above poster's issue shouldn't be amd64 issues.  On intel
systems we don't have any interesting iommuing going on -- there's just
the graphics GTT, which is a mapping from card virtual to system
physical memory like an AGP aperture, and only applies to the graphics
aperture.  And the DRM code is getting all of its information from the
agp driver, so there's no bus_dma()ing to be done.

--=20
Eric Anholt                             anholt@FreeBSD.org
eric@anholt.net                         eric.anholt@intel.com


--=-YwkqvWXIgteSMf3Xp7qS
Content-Type: application/pgp-signature; name=signature.asc
Content-Description: This is a digitally signed message part

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (FreeBSD)

iD8DBQBGEsRhHUdvYGzw6vcRAp1fAJ48Z2k3nqREHFIAW9lP2h2AEO0WEQCdF1Ey
bzxnGs6m2iYpHfysSGwQzBM=
=HHVT
-----END PGP SIGNATURE-----

--=-YwkqvWXIgteSMf3Xp7qS--