Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S935124AbdCLTCS (ORCPT ); Sun, 12 Mar 2017 15:02:18 -0400 Received: from mail-io0-f174.google.com ([209.85.223.174]:36631 "EHLO mail-io0-f174.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S934579AbdCLTCR (ORCPT ); Sun, 12 Mar 2017 15:02:17 -0400 MIME-Version: 1.0 X-Originating-IP: [2a02:168:56c9:0:decc:6e78:7e96:b452] In-Reply-To: <20170312184245.ad2nd2siq3y44amp@phenom.ffwll.local> References: <20170211184858.26421-1-noralf@tronnes.org> <20170211184858.26421-4-noralf@tronnes.org> <20170312184245.ad2nd2siq3y44amp@phenom.ffwll.local> From: Daniel Vetter Date: Sun, 12 Mar 2017 20:02:15 +0100 X-Google-Sender-Auth: MyXbD6jYReYtEXFYY4NRnhmJQ0U Message-ID: Subject: Re: [PATCH v4 3/7] drm/tinydrm: Add MIPI DBI support To: =?UTF-8?Q?Noralf_Tr=C3=B8nnes?= , dri-devel , "devicetree@vger.kernel.org" , Thomas Petazzoni , Linux Kernel Mailing List Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1200 Lines: 27 On Sun, Mar 12, 2017 at 7:42 PM, Daniel Vetter 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