Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp2389274imu; Thu, 10 Jan 2019 13:19:50 -0800 (PST) X-Google-Smtp-Source: ALg8bN7LTJig4sFpxt8XO1vJCwdqgvY2/PGXF4zb8ROIjlpXnryy1UQOMJQwKcWJTotdirsv8hDM X-Received: by 2002:a63:5ec6:: with SMTP id s189mr10456305pgb.357.1547155190688; Thu, 10 Jan 2019 13:19:50 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1547155190; cv=none; d=google.com; s=arc-20160816; b=SGDuQwmrTq8Ncs4XtEL9BjANbjnZf7Vjm76/QrfSo2L4HrMy6ouGJjCNI1vNCOSVpf YowUB1XOT4pu+sRcfZOb4E93qwSvS5WQe1Mcpux4hAA7by+k02mQ88r1Va6j8KPgbx6l 0IVWnFg5ZEIusfD5D2iYZnFhUb24nep4vA2F2Q7TIkvmqAQnbDwydN/KinyKcssdHJo9 8vkdLvQQd8+bqzNx/plcSd8EyrltqoMuhStPhypR5032n7Da4VCQh2v5cKGdJFbP88cY 9VYGFwx006tB2I2W57NNehIm2LHg8W7xC6/kpZwL8/k/SlZjNzMejYFIdtjJdZn3ceE2 VXww== 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; bh=mgn0TV2p/Qyo8jp30nOHcvzNwAikXwT6MLazNf81B4c=; b=hptKxnAcqaTFO11Ti8DpUxJ3N6FsdpdvllBGH7fSL6SuQzcK8L3ItWweB5GWLDjwHo 1xX8nLPrMLYrDjfnpj2w5vQOjQ5JcQWKlvhRtHimHAYy4EviM5MDHc/HNkIaWD39DZ9w duV3HgUZ6sh/T7Vyw+G8oy/A8J6IKYfJ3zcDvya8JUS2m+9fdvJQ64bLcRnS18M4ItkK nExEFVL5G8Uh9FU+iD+DTbSnmL4itPHlBXFGV98lp5dpELLKqNrM2YGRKu0SlVH30cEx HeNtRjsDAZ1zIRFa6Mj1lEyaTvfAEn19GoGmqeXkAtCePlVurNps4gUAux+jYKfokKt9 nnAg== 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 e15si31692750pgg.281.2019.01.10.13.19.35; Thu, 10 Jan 2019 13:19:50 -0800 (PST) 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 S1730288AbfAJUQo (ORCPT + 99 others); Thu, 10 Jan 2019 15:16:44 -0500 Received: from asavdk4.altibox.net ([109.247.116.15]:41857 "EHLO asavdk4.altibox.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729068AbfAJUQn (ORCPT ); Thu, 10 Jan 2019 15:16:43 -0500 Received: from ravnborg.org (unknown [158.248.194.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by asavdk4.altibox.net (Postfix) with ESMTPS id 4BC9780538; Thu, 10 Jan 2019 21:16:38 +0100 (CET) Date: Thu, 10 Jan 2019 21:16:36 +0100 From: Sam Ravnborg To: Boris Brezillon , Peter Rosin Cc: Peter Rosin , Alexandre Belloni , David Airlie , "linux-kernel@vger.kernel.org" , "dri-devel@lists.freedesktop.org" , Nicolas Ferre , Boris Brezillon , "linux-arm-kernel@lists.infradead.org" Subject: Re: [PATCH 0/4] drm/atmel-hlcdc: fix plane clipping/rotation issues Message-ID: <20190110201636.GA7074@ravnborg.org> References: <20190110151020.30468-1-peda@axentia.se> <20190110184446.75b4350a@bbrezillon> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20190110184446.75b4350a@bbrezillon> User-Agent: Mutt/1.5.21 (2010-09-15) X-CMAE-Score: 0 X-CMAE-Analysis: v=2.3 cv=UpRNyd4B c=1 sm=1 tr=0 a=UWs3HLbX/2nnQ3s7vZ42gw==:117 a=UWs3HLbX/2nnQ3s7vZ42gw==:17 a=kj9zAlcOel0A:10 a=cw4OArruGTS2hah8c1kA:9 a=CjuIK1q_8ugA:10 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Peter. (Hijacking this thread as I lost the orginal mails) > > > > I found an unfortunate issue while recoding plane handling to use > > drm_atomic_helper_check_plane_state(). The driver rotates clockwise, > > which is not correct. I simply fixed it (patch 1/4), but maybe that > > will cause regressions for unsuspecting users who simply assumed > > that the clockwise rotation was correct? I don't know what to do > > about that? Adding an option to get the old broken behavior seems > > useless, wouldn't it be just as easy to just fix whatever app to > > rotate the other way instead of adding an option somewhere? > > Hm, rotation support has been added before the standard rotation > property was created, and at that time I assumed rotation was clockwise > (which apparently was an unwise choice). Anyway, I don't have a > solution for this problem, so I'll let Nicolas decide if it's > acceptable to change the rotation behavior. > > > > > I have only tested this series on sama5d3, but I did check the docs > > for various other chips (sama5d2, sama5d4, sam9n12, sam9g15, sam9g35 > > and sam9x35) supported by the driver (relevant to patch 4/4). I wonder if, when this code path is anyway touched, could benefit from drm_rect_rotate(). It is obviously not a simple replacement, but could it be used then I hope the resulting code is simpler. Sam