On Thu, Dec 8, 2011 at 2:45 AM, Tomi Valkeinen <tomi.valkeinen at ti.com>wrote:
> On Wed, 2011-12-07 at 07:29 -0600, Rob Clark wrote: > > On Wed, Dec 7, 2011 at 3:31 AM, Tomi Valkeinen <tomi.valkeinen at ti.com> > wrote: > > > Hi, > > > > > > On Mon, 2011-12-05 at 19:19 -0600, Rob Clark wrote: > > >> From: Rob Clark <rob at ti.com> > > >> > > >> Support for DMM and tiled buffers. The DMM/TILER block in omap4+ SoC > > >> provides support for remapping physically discontiguous buffers for > > >> various DMA initiators (DSS, IVAHD, etc) which do not otherwise > support > > >> non-physically contiguous buffers, as well as providing support for > > >> tiled buffers. > > >> > > >> See the descriptions in the following two patches for more details. > > > > > > Why is the tiler/dmm driver integrated into the drm driver? > > > > Basically because of a big list of reasons to keep it integrated, and > > no good reason that I could think of to make it a standalone driver. > > Well, I think it's good architecture to keep independent things > separate. Also we have other display frameworks in the kernel than DRM. > > I think we can split it out if we need to support other frameworks. It isn't that difficult to do. If we were to do that, I presume it would still reside in the gpu/ somewhere. But I think I'd rather wait until we have another framework require access. > > 1) Because the function/usage is most like a GTT in other systems.. > > the usage is really graphics/multimedia related so GEM is a natural > > way to expose it to userspace. Other places we want to use tiler > > buffers, like camera, are neatly handled by using dmabuf to export the > > GEM buffer to a different device. > > > > 2) We went down the separate driver path in the past, and it really > > exposes a lot of problems. See the hacks that were done in the past > > to get wakeup/resume sequencing correct when tiler was a separate > > driver. (hint: the table of page addresses needs to be reprogrammed > > before any access to buffer mapped in DMM is done.. this can be > > accomplished quite simply by restoring the LUT before enabling any > > video pipes when it is in a single driver... although that is still in > > the TODO) > > > > 3) Doing some of the more advanced stuff, like page flipping using > > DMM's synchronized refill to update page addresses synchronized with > > scannout will, I think, end up being some kinda weird API.. I don't > > think I'd want to make that a public API exported by one driver > > consumed by another, but not such a problem if it is just something > > used internally by one driver. > > > > 4) The LUT isn't really big enough to be managed statically like we > > did in the past.. it needs to be managed dynamically, mapping and > > evicting buffers. This is something that is typical with other gfx > > drivers in their management of their GTT.. > > > > 5) I wouldn't really want to duplicate the userspace mmap'ing games > > for 2d buffers in a lot of different drivers. > > I can't really argue your points as I'm not familiar with the problems > with the tiler. So I'm not questioning the decision to integrate the > tiler code into drm, just expressing my toughts =). > > If the tiler driver had only kernel internal API, and no userspace APIs, > I don't see why it'd be much more difficult to have as a separate driver > than integrated into DRM. Well, except if the tiler code itself uses > features offered by DRM extensively, and having the tiler code as an > independent driver would mean replicating all those features. > > I guess it's not quite a fair comparison, but I'm comparing tiler to the > vrfb driver (well, lib is perhaps a better word for it), which doesn't > depend on any framework and can be used by any kernel component. > > No I appreciate your input. I had thoughts along the same line. But since I did not have any exported kernel functions, I figured that it should just sit underneath the omapdrm umbrella (so to speak). -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20111208/273218a6/attachment.htm>
