Re: [Linux-fbdev-devel] Re: waitforVBlank, how does this even work?

[Ville <sy...@sc...>]

On Sat, Mar 05, 2005 at 09:35:00AM +1100, Benjamin Herrenschmidt wrote:
> On Fri, 2005-03-04 at 15:18 +0200, Ville Syrj=E4l=E4 wrote:
> > On Fri, Mar 04, 2005 at 09:08:27AM +1100, Benjamin Herrenschmidt wrot=
e:
> > >=20
> > > > > Oh, but I was not suggesting that. I just meant that interrupt =
handling=20
> > > > > code is self-contained and can easily serve several consumers.
> > > >=20
> > > > I'm with you here. And the same should IMHO hold for DMA handling=
. And for=20
> > > > memory management of course.
> > >=20
> > > DMA handling is the main piece of what the DRM does,
> >=20
> > The actual bits that feed DMA buffers to the hardware are very small.=
 And=20
> > I just meant that like the IRQ code those need to be easily accessibl=
e=20
> > from other components (fbdev, video capture module etc.)
>=20
> "Feeding DMA buffers" in what sense ? The buffers are matches with
> various functions. For AGP buffers, you have to get into the whole
> allocation mecanism, pure PCI DMA isn't always possible on some hosts.

Allocating buffers should IMO belong to the memory management part.

If DMA isn't possible then I suppose the comammands/data would have to fe=
d=20
via MMIO. But that is a detail only the DMA component would have to know.

> Also, those buffers are what ? Data for blits ? textures ? they always
> belong to some sort of command, which we want to eventually validate in
> a way by the kernel unless you want your client to be root...

Usually the buffers are series of commands. And they don't need to=20
validated when they come from the kernel. Validating buffers from=20
userspace is done by the DRM.

> No, honestly, I don't see the point in breaking up our current DRM/fbde=
v
> thing.

From the userspace perspective nothing should change.


For the memory management I have some rough ideas but I'm not an expert=20
here so let me know if I'm talking out of my ass...

The GART (be it AGP, PCI or some other mechanism) should be only used by=20
the memory management part to dynamically map required bits of system RAM=
=20
for the graphics hardware to access. Clients of the memory management=20
system should only have to ask thing like "give me a buffer of size x wit=
h=20
priority y". Those buffers could then exist in system or video memory and=
=20
the memory manager could actaully dynamically move them around without th=
e=20
clients even knowing about it. At one point the buffer could be in video=20
memory and in system memory the next. If the hardware can render to syste=
m=20
RAM then it could be totally transparent to the user. With hardware that=20
can't render to system RAM I suppose the best idea would be to always mov=
e=20
the buffers to system RAM when software access is required. That way the=20
software could lock the buffer for any period of time without disturbing=20
the memory managers work.

--=20
Ville Syrj=E4l=E4
sy...@sc...
http://www.sci.fi/~syrjala/