Received: by 10.192.165.148 with SMTP id m20csp328308imm; Fri, 20 Apr 2018 07:26:54 -0700 (PDT) X-Google-Smtp-Source: AIpwx4+e43sAJgPwA0o1qShscfyplnG0lPaugfnnHzxqyypQZvExP8rQW+jOZHBO6hP415cS8MsI X-Received: by 2002:a17:902:d20a:: with SMTP id t10-v6mr10485720ply.151.1524234414029; Fri, 20 Apr 2018 07:26:54 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1524234413; cv=none; d=google.com; s=arc-20160816; b=UWgjoKV88M7VgOgjQF8+dGWg2A3htdW2EfNTuh/yo85Y3bHfHaNkovl1JhqWF9c/76 rBvoTN6+wyji31l9irvqm1oeM/ahWDBfML1qMal9Q9Q/Vnyos3LsU4qi9nZH4SM3m+vm vFS6gn2agih7UZsmqWvGr1wCLf7xR6wxo+5Nk3Rk40oL6aNrP49/hl1zJR+FxtI7SgzE 6uOnO7zfgRIKKqPwAYscAlGcIUVPMCP3F+p4sn7ieyT4x49AB9+bYza89XOADDLdizCD 02IKAX+KP/ACgfBY/aJRWl9B3bIVUf41PrMBepIhqqGveWkbvfDJKt6vkMaD9vsVj8WT SNQQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:arc-authentication-results; bh=zdfI1P7IMr3sXFl2+SBovHiEiWzQcHGieMs7JxomKDk=; b=KPx32Jbj+C+47KDyTtXXu1fT73H0/XuU+3NylJt2LbjPNLL20VggGFwZnNTd9wl8Cg YlRd2jz6xxSg+4GGcdSAYX7Mgl5OJQXg3YD5yYKU3mRWQql48K/qaaw6iXasZUn1YZWM 4zuMjBlYkyaiqJSvGbV/prhVxrak6R8/in4SLj96QIkLujCoLUAHl6rYQM0x6iF5Yy/g yWA6j5rfozOfo1ZNKV5vs3K1kX+d9hPbhxJrn9ins8UV+KIXACWKHxcM/M5MNvzPnsUY P6uJm7aNIJ9/xMPyqZJEWNs88nrg2pMLzKuMz+V/x+S4ZuYNd9QJyvZ3U6UAB4SsNuKc sjng== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id 37-v6si5762672plq.288.2018.04.20.07.26.38; Fri, 20 Apr 2018 07:26:53 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755265AbeDTOZi (ORCPT + 99 others); Fri, 20 Apr 2018 10:25:38 -0400 Received: from muru.com ([72.249.23.125]:37364 "EHLO muru.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755147AbeDTOZh (ORCPT ); Fri, 20 Apr 2018 10:25:37 -0400 Received: from atomide.com (localhost [127.0.0.1]) by muru.com (Postfix) with ESMTPS id 23F9D80E1; Fri, 20 Apr 2018 14:27:17 +0000 (UTC) Date: Fri, 20 Apr 2018 07:25:33 -0700 From: Tony Lindgren To: Daniel Stone Cc: Tomi Valkeinen , Sebastian Reichel , Sebastian Reichel , Pavel Machek , Laurent Pinchart , Rob Herring , Mark Rutland , dri-devel , devicetree@vger.kernel.org, linux-omap@vger.kernel.org, Linux Kernel Mailing List , kernel@collabora.com Subject: Re: [PATCHv3 3/8] drm/omap: add support for manually updated displays Message-ID: <20180420142533.GN5671@atomide.com> References: <20180330171822.25896-1-sebastian.reichel@collabora.co.uk> <20180330171822.25896-4-sebastian.reichel@collabora.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.4 (2018-02-28) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi, * Daniel Stone [180420 10:21]: > Hi Tomi, > > On 20 April 2018 at 08:09, Tomi Valkeinen wrote: > > It's actually not quite clear to me how manual update displays work with > > DRM... > > > > As far as I see, we have essentially two cases: 1) single buffering, > > where the userspace must set an area in the fb dirty, which then > > triggers the update, 2) multi buffering, which doesn't need fb dirty, > > but just a page flip which triggers the update. > > > > In the 2) case (which I think is the optimal case which all the modern > > apps should use), there's no need for delayed work or any work, and the > > code flow should be very similar to the auto-update model. > > Correct. There's been talk (and I think patches?) of adding a > per-plane dirty property, so userspace can as an optimisation inform > the kernel of the area changed between frames. But short of that, a > pageflip needs to trigger a full-plane update, with no dirtyfb > required. For per-plane dirty property patches, which ones do you refer to? Then for xorg, there's my second attempt on fixing the command mode rotation at [0]. Not sure if that's enough for a fix? It seems not very efficient to me and I don't really know where the the per crtc dirty flag should be stored.. I can easily test patches though with a command mode LCD and normal HDMI setup on droid 4. Regards, Tony [0] https://lists.x.org/archives/xorg-devel/2018-February/055890.html