RE: [PATCH] RFC: omapdrm DRM/KMS driver for TI OMAP platforms

[Tomi Valkeinen <tomi.valkeinen-l0cyMroinI0@public.gmane.org>]

On Wed, 2011-09-07 at 15:00 +0900, Inki Dae wrote:
> Hello, Rob.
> 
> > -----Original Message-----
> > From: robdclark-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org [mailto:robdclark-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org] On Behalf Of Rob
> > Clark
> > Sent: Tuesday, September 06, 2011 1:05 AM
> > To: Inki Dae
> > Cc: dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org; linaro-dev-cunTk1MwBs8s++Sfvej+rw@public.gmane.org;
> > Valkeinen, Tomi
> > Subject: Re: [PATCH] RFC: omapdrm DRM/KMS driver for TI OMAP platforms
> > 
> > On Mon, Sep 5, 2011 at 4:58 AM, Inki Dae <inki.dae-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org> wrote:

<snip>

> > > How about moving codes above into interrupt handler for vblank?
> > >  maybe there
> > 
> > I should mention a couple of things:
> > 
> > 1) drm vblank stuff isn't really used currently.. it is actually DSS2
> > layer that is registering for the display related interrupt(s).  I'm
> > not really sure how to handle this best.  I suppose the DRM driver
> > could *also* register for these interrupts, but that seems a bit odd..
> > 
> 
> DRM Framework supports only one interrupt handler. this issue should be
> resolved. and currently I made our driver to use its own request_irq, not
> DRM Framework side. we only sets drm_device->irq_enabled to 1 and interrupt
> handler is registered at display controller or hdmi driver respectively. but
> I'm not sure that this way is best so I will look over more. Anyway current
> drm framework should be fixed to be considered with multiple irq.

I am actually going to hide the display subsystem interrupts, as they
are really a DSS2 driver internal thing, and create some kind of
notifications for the events that the users of DSS2 need to see. I don't
know how that affects the OMAP DRM driver, but it should be a much
cleaner interface.

> > Also, I guess it is also worth mentioning.. when it comes to vblank,
> > there are two fundamentally different sorts of displays we deal with.
> > Something like DVI/HDMI/etc which need constant refreshing.  In these
> > cases we constantly scan-out the buffer until the next page
> > flip+vsync.  And smart panels, where they get scanned out once and
> > then DSS is no longer reading the scanout buffer until we manually
> > trigger an update.
> > 
> 
> Is the Smart panel CPU interface based lcd panel that has its own
> framebuffer internally.?

I don't like the "smart panel" term very much, but yes, it has an
internal framebuffer. The panels are connected via DSI command mode or
DBI bus. They can be updated with CPU, but normally they are not and use
the same display controller hardware as other displays to update the
screen.

The biggest difference with these smart panels compared to conventional
ones is that pixel data is only sent to the panel when needed (i.e. when
somebody has changed the pixel data), and the panel retains the last
sent frame independently on the screen, and the SoC can even go to
sleep.

 Tomi