<div><div class="gmail_quote">On Thu, Dec 8, 2011 at 2:45 AM, Tomi Valkeinen <span dir="ltr"><<a href="mailto:tomi.valkeinen@ti.com" target="_blank">tomi.valkeinen@ti.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div>On Wed, 2011-12-07 at 07:29 -0600, Rob Clark wrote:<br>
> On Wed, Dec 7, 2011 at 3:31 AM, Tomi Valkeinen <<a href="mailto:tomi.valkeinen@ti.com" target="_blank">tomi.valkeinen@ti.com</a>> wrote:<br>
> > Hi,<br>
> ><br>
> > On Mon, 2011-12-05 at 19:19 -0600, Rob Clark wrote:<br>
> >> From: Rob Clark <<a href="mailto:rob@ti.com" target="_blank">rob@ti.com</a>><br>
> >><br>
> >> Support for DMM and tiled buffers. The DMM/TILER block in omap4+ SoC<br>
> >> provides support for remapping physically discontiguous buffers for<br>
> >> various DMA initiators (DSS, IVAHD, etc) which do not otherwise support<br>
> >> non-physically contiguous buffers, as well as providing support for<br>
> >> tiled buffers.<br>
> >><br>
> >> See the descriptions in the following two patches for more details.<br>
> ><br>
> > Why is the tiler/dmm driver integrated into the drm driver?<br>
><br>
> Basically because of a big list of reasons to keep it integrated, and<br>
> no good reason that I could think of to make it a standalone driver.<br>
<br>
</div>Well, I think it's good architecture to keep independent things<br>
separate. Also we have other display frameworks in the kernel than DRM.<br>
<div><div><br></div></div></blockquote><div><br></div><div>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.</div>
<div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div>
> 1) Because the function/usage is most like a GTT in other systems..<br>
> the usage is really graphics/multimedia related so GEM is a natural<br>
> way to expose it to userspace. Other places we want to use tiler<br>
> buffers, like camera, are neatly handled by using dmabuf to export the<br>
> GEM buffer to a different device.<br>
><br>
> 2) We went down the separate driver path in the past, and it really<br>
> exposes a lot of problems. See the hacks that were done in the past<br>
> to get wakeup/resume sequencing correct when tiler was a separate<br>
> driver. (hint: the table of page addresses needs to be reprogrammed<br>
> before any access to buffer mapped in DMM is done.. this can be<br>
> accomplished quite simply by restoring the LUT before enabling any<br>
> video pipes when it is in a single driver... although that is still in<br>
> the TODO)<br>
><br>
> 3) Doing some of the more advanced stuff, like page flipping using<br>
> DMM's synchronized refill to update page addresses synchronized with<br>
> scannout will, I think, end up being some kinda weird API.. I don't<br>
> think I'd want to make that a public API exported by one driver<br>
> consumed by another, but not such a problem if it is just something<br>
> used internally by one driver.<br>
><br>
> 4) The LUT isn't really big enough to be managed statically like we<br>
> did in the past.. it needs to be managed dynamically, mapping and<br>
> evicting buffers. This is something that is typical with other gfx<br>
> drivers in their management of their GTT..<br>
><br>
> 5) I wouldn't really want to duplicate the userspace mmap'ing games<br>
> for 2d buffers in a lot of different drivers.<br>
<br>
</div></div>I can't really argue your points as I'm not familiar with the problems<br>
with the tiler. So I'm not questioning the decision to integrate the<br>
tiler code into drm, just expressing my toughts =).<br>
<br>
If the tiler driver had only kernel internal API, and no userspace APIs,<br>
I don't see why it'd be much more difficult to have as a separate driver<br>
than integrated into DRM. Well, except if the tiler code itself uses<br>
features offered by DRM extensively, and having the tiler code as an<br>
independent driver would mean replicating all those features.<br>
<br>
I guess it's not quite a fair comparison, but I'm comparing tiler to the<br>
vrfb driver (well, lib is perhaps a better word for it), which doesn't<br>
depend on any framework and can be used by any kernel component.<br>
<span><font color="#888888"><br></font></span></blockquote><div><br></div><div>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).</div>
<div> </div><div><br></div></div></div>