On Sun, Mar 12, 2017 at 7:42 PM, Daniel Vetter <daniel@xxxxxxxx> wrote: > > The upshot of all this is two-fold: > > - You get rid of a tiny bit of book-keeping in each tinydrm driver (the > merge_clips above, plus the "is this the current fb on our hw" check). > > - There's lots more manual upload devices than just tinydrm, or > drm_simple_pipe, this would benefit any atomic driver. > > - Long-term we want to expose the dirty_clip as properties to userspace, > since the compositor already computes this anyway for each atomic update > (at least good compositors do this). Test-driving these new properties > within the kernel would help in catching issues. - Correct locking: taking the ->dirty_lock only protects against concurrent other ->dirty or simple_pipe->update operations, it doesn't protect against concurrent modeset changes (i.e. someone could disable the panel while you try to upload stuff). Moving the locking out of panel drivers into this one single core helper removes the need for any locking in drivers. And no need for locking == no way to screw it up :-) -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
