[PATCH 0/2] omap/drm: dmm/tiler support for GEM buffers

[Gross, Andy]

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>