From mboxrd@z Thu Jan 1 00:00:00 1970 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 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 From mboxrd@z Thu Jan 1 00:00:00 1970 From: Daniel Vetter Subject: Re: [PATCH v4 3/7] drm/tinydrm: Add MIPI DBI support Date: Sun, 12 Mar 2017 20:02:15 +0100 Message-ID: References: <20170211184858.26421-1-noralf@tronnes.org> <20170211184858.26421-4-noralf@tronnes.org> <20170312184245.ad2nd2siq3y44amp@phenom.ffwll.local> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Return-path: In-Reply-To: <20170312184245.ad2nd2siq3y44amp-dv86pmgwkMBes7Z6vYuT8azUEOm+Xw19@public.gmane.org> Sender: devicetree-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org To: =?UTF-8?Q?Noralf_Tr=C3=B8nnes?= , dri-devel , "devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" , Thomas Petazzoni , Linux Kernel Mailing List List-Id: devicetree@vger.kernel.org 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 -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html