[PATCH] omap2+: add drm device

[Tomi Valkeinen]

On Thu, 2012-05-24 at 00:27 -0600, Clark, Rob wrote:
> On Thu, May 24, 2012 at 12:01 AM, Tomi Valkeinen <tomi.valkeinen at ti.com> wrote:
> > Hi,
> >
> > On Wed, 2012-05-23 at 15:08 -0500, Andy Gross wrote:
> >> Register OMAP DRM/KMS platform device.  DMM is split into a
> >> separate device using hwmod.
> >>
> >> Signed-off-by: Andy Gross <andy.gross at ti.com>
> >
> > <snip>
> >
> >> +static int __init omap_init_drm(void)
> >> +{
> >> +     struct omap_hwmod *oh = NULL;
> >> +     struct platform_device *pdev;
> >> +
> >> +     /* lookup and populate the DMM information, if present - OMAP4+ */
> >> +     oh = omap_hwmod_lookup("dmm");
> >> +
> >> +     if (oh) {
> >> +             pdev = omap_device_build(oh->name, -1, oh, NULL, 0, NULL, 0,
> >> +                                     false);
> >> +             WARN(IS_ERR(pdev), "Could not build omap_device for %s\n",
> >> +                     oh->name);
> >> +     }
> >> +
> >> +     return platform_device_register(&omap_drm_device);
> >> +
> >> +}
> >
> > I still don't like fixing the tiler to drm. I would like to have basic
> > tiler support in omapfb also, but with this approach I'll need to
> > duplicate the code. And even if we disregard omapfb, wouldn't it be
> > architecturally better to have the tiler as a separate independent
> > library/driver?
> 
> Not easily, at least not if we want to manage to use tiler/dmm in a
> more dynamic way, or to enable some additional features which are
> still on the roadmap (like reprogramming dmm synchronized w/ scanout,
> or some things which are coming if future hw generations).  We need
> one place to keep track of which buffers are potentially evictable to
> make room for mapping a new buffer.  And if you look at the tricks
> that go on with mmap'ing tiled buffers to userspace, you *really*
> don't want to duplicate that in N different drivers.

So why can't all that code be in a tiler library/driver?

> Fortunately with dmabuf there is not really a need for N different
> drivers to need to use tiler/dmm directly.  The dmabuf mechanism
> provides what they need to import GEM buffers from omapdrm.  That may
> not really help omapfb because fbdev doesn't have a concept of
> importing buffers.  But OTOH this is unnecessary, because drm provides
> an fbdev interface for legacy apps.  The best thing I'd recommend is,
> if you miss some features of omapfb in the drm fbdev implementation,
> is to send some patches to add this missing features.

Well, at least currently omapfb and omapdrm work quite differently, if
I've understood right. Can we make a full omapfb layer on top of
omapdrm? With multiple framebuffers mapped to one or more overlays,
support for all the ioctls, etc?

I guess we'd still need to have omapfb driver to keep the module
parameters and behavior the same. Can omapdrm be used from inside the
kernel by another driver?

 Tomi

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part
URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20120524/555fd618/attachment.pgp>