Re: [PATCH] drm/omap: use omapdss low level API

[Tomi Valkeinen <tomi.valkeinen@ti.com>]

[-- Attachment #1: Type: text/plain, Size: 1812 bytes --]

On 2012-11-16 14:19, Greg KH wrote:
> On Thu, Nov 15, 2012 at 06:00:58PM -0600, Rob Clark wrote:
>> This patch changes the omapdrm KMS to bypass the omapdss "compat"
>> layer and use the core omapdss API directly.  This solves some layering
>> issues that would cause unpin confusion vs GO bit status, because we
>> would not know whether a particular pageflip or overlay update has hit
>> the screen or not.  Now instead we explicitly manage the GO bits in
>> dispc and handle the vblank/framedone interrupts ourself so that we
>> always know which buffers are being scanned out at any given time, and
>> so on.
>>
>> As an added bonus, we no longer leave the last overlay buffer pinned
>> when the display is disabled, and have been able to add the previously
>> missing vblank event handling.
>>
>> Signed-off-by: Rob Clark <robdclark@gmail.com>
>> ---
>> Note: this patch applies on top of staging-next plus the "OMAPDSS:
>> create compat layer" patch series:
>>
>> http://comments.gmane.org/gmane.linux.ports.arm.omap/89435
> 
> Hm, I can't take that patch set in staging-next, so how should this go
> in?

I wonder, could the omapdrm part go in for -rc2? It's "only" a driver in
staging. I think that would be the easiest way. Perhaps it'd be even
possible to split the patch into two, of which the first half would not
depend on omapdss, but would prepare omapdrm for the change, thus making
the patch for -rc2 smaller.

Otherwise it's more tricky... Either wait for 3.9, or get omapdss,
omapfb and omapdrm merged via the same tree. But which that would be?
omapdss and omapfb usually go through fbdev tree. I don't know what its
maintainer thinks of merging drm driver. And if the omapdrm depends on
new drm changes, I guess fbdev is out of the question.

 Tomi



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 897 bytes --]