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

Rob Clark rob.clark at linaro.org
Wed Dec 7 05:29:12 PST 2011


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.

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.

The code is structured such that it could be separated in the future,
if there is any good reason too.  But so far I've been unable to think
of one.

BR,
-R


>  Tomi
>
>
> _______________________________________________
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>


More information about the dri-devel mailing list