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=
> > >=20
> > > > > Oh, but I was not suggesting that. I just meant that interrupt =
> > > > > 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,
> > The actual bits that feed DMA buffers to the hardware are very small.=
> > I just meant that like the IRQ code those need to be easily accessibl=
> > from other components (fbdev, video capture module etc.)
> "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=
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=
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=
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=
priority y". Those buffers could then exist in system or video memory and=
the memory manager could actaully dynamically move them around without th=
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=
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=
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.