On Sat, Mar 05, 2005 at 09:35:00AM +1100, Benjamin Herrenschmidt wrote: > On Fri, 2005-03-04 at 15:18 +0200, Ville Syrj�l� wrote: > > On Fri, Mar 04, 2005 at 09:08:27AM +1100, Benjamin Herrenschmidt wrote: > > > > > > > > Oh, but I was not suggesting that. I just meant that interrupt > > > > > handling > > > > > code is self-contained and can easily serve several consumers. > > > > > > > > I'm with you here. And the same should IMHO hold for DMA handling. And > > > > for > > > > memory management of course. > > > > > > DMA handling is the main piece of what the DRM does, > > > > The actual bits that feed DMA buffers to the hardware are very small. And > > I just meant that like the IRQ code those need to be easily accessible > > 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 fed 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 validated when they come from the kernel. Validating buffers from userspace is done by the DRM. > No, honestly, I don't see the point in breaking up our current DRM/fbdev > thing. >From the userspace perspective nothing should change. For the memory management I have some rough ideas but I'm not an expert 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 the memory management part to dynamically map required bits of system RAM for the graphics hardware to access. Clients of the memory management system should only have to ask thing like "give me a buffer of size x with priority y". Those buffers could then exist in system or video memory and the memory manager could actaully dynamically move them around without the clients even knowing about it. At one point the buffer could be in video memory and in system memory the next. If the hardware can render to system RAM then it could be totally transparent to the user. With hardware that can't render to system RAM I suppose the best idea would be to always move the buffers to system RAM when software access is required. That way the software could lock the buffer for any period of time without disturbing the memory managers work. -- Ville Syrj�l� [EMAIL PROTECTED] http://www.sci.fi/~syrjala/ ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_ide95&alloc_id396&op=click -- _______________________________________________ Dri-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/dri-devel
