On Wed, 2012-08-01 at 09:25 -0500, Rob Clark wrote:
On Wed, Aug 1, 2012 at 4:21 AM, Tomi Valkeinen tomi.valkeinen@ti.com wrote:
I guess the fact is that DRM concepts do not really match the OMAP DSS hardware, and we'll have to use whatever gives us least problems.
Actually, I think it does map fairly well to the hardware.. at least more so than to omapdss ;-)
Hm, I'm not sure I understand, omapdss concepts map directly to the hardware.
The one area that kms mismatches a bit is decoupling of ovl from mgr that we have in our hw.. I've partially solved that a while back w/
What do you mean with that? Ovls and mgrs are one entity in KMS? Didn't the drm_plane stuff separate these?
For enabling/disabling an output (manager+encoder), this is relatively infrequent, so it can afford to block to avoid races. (Like userspace enabling and then rapidly disabling an output part way through the enable.) But enabling/disabling an overlay, or adjusting position or scanout address must not block. And ideally, if possible, switching an overlay between two managers should not block.
Adjusting the position or address of the buffer are simple, they can be easily done without any blocking.
But ovl enable/disable and switching an ovl to another mgr do (possibly) take multiple vsyncs (and in the switch case, vsyncs of two separate outputs). So if those do not block, we'll need to handle them as a state machine and try to avoid races etc. It'll be "interesting".
However, we can sometimes do those operations immediately. So I think we should have these conditional fast-paths in the code, and do them in non-blocking manner when possible.
I'll look again, but as far as I remember that at least wasn't addressing the performance issues from making overlay enable/disable
Right, it wasn't addressing those issues. But your branch doesn't really address those issues either, as it doesn't handle the problems related to ovl enable/disable.
synchronous. And fixing that would, I expect, trigger the same problems that I already spent a few days debugging before switching over to handle apply in omapdrm.
I was under the impression that the apply mechanism, the caching and setting of the configs, was the major issue you had. But you're hinting that the actual problem is related to ovl enable/disable? I haven't tried fixing the ovl enable/disable, as I didn't know it's an issue for omapdrm. Or are they both as big issues?
Tomi