Received: by 10.192.165.148 with SMTP id m20csp5400420imm; Wed, 9 May 2018 04:34:41 -0700 (PDT) X-Google-Smtp-Source: AB8JxZoUiS2nWmAWokVwn4W3AkQ8aQsdlNNkHBpPILZcnR9M+Jc2C/ZmV5EhL2SlG1ejq+8Vp02K X-Received: by 2002:a65:62c2:: with SMTP id m2-v6mr36293173pgv.164.1525865681127; Wed, 09 May 2018 04:34:41 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1525865681; cv=none; d=google.com; s=arc-20160816; b=eKwhC8xwX+FvXYaoDiPMj+OW3NVwR4UWU0TnX5JMED/+4cnsV1uXKF0BZpPbTRfh8C HEy4o1xqxPfdcDiv65uv0S8p3pofDtqNQFIWc4lQ7vRO6GlcR/qzCqUt13yqQbZDfOHx /ISyYIgToI4bmFRWOa+5UPc5dY5TenlGC+nH85OCS7KGNv1nn97pDHwYRI7Qo/o4tMV8 twub3KCsqEZeP2tkfqN3rVfK4SpKviKUB/iWH6bSwldBbYFZLZr572Pz0FSuul9l76zz Jtf9Z3Cb0QFA5RR9LrRM9a3lsGq3ITY8UnT6DMmpkeAVhmdTkKVHCeEesSQutDsTW+qC KPjg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :references:in-reply-to:date:cc:to:from:subject:message-id :arc-authentication-results; bh=DHunCqo4Tztd9upnikvjw/AGkX2cwJTZ24UNt7ocoeU=; b=FGzGyaQD8Gdu/IxKS2qgh84gH5uFl5LPm2mzAZoJbpkAht7hluWP5jTeZXBLOa5CL6 o3oYVU78SaPNBbGWsw6WPXlQJzkR0pwZJkNuyEyBu0RRzdwzfqR9deckuiS5J4WmChh9 NbUeSFUxdiG/013TCwSWiOQU2T0O4MUGAOvZWBWs5cPiq/+jE7cQW9k63D2s6VcNJHTg CBVeJb9dPKq9p2zN7arnpHUBD0XGppOig5ja1YOGoTtCEC9E+lTs0jxh8uE3IVsRxyil hG7DC4iJk6kGdEij6YX9HNNQbzGeyTcUF5WMluZTzeJX+U2/79gt+73mStOsE7JDqdMo j0GQ== 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 m23-v6si21606398pgc.523.2018.05.09.04.34.26; Wed, 09 May 2018 04:34:41 -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 S934340AbeEILdo (ORCPT + 99 others); Wed, 9 May 2018 07:33:44 -0400 Received: from leonov.paulk.fr ([185.233.101.22]:56524 "EHLO leonov.paulk.fr" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S933883AbeEILdB (ORCPT ); Wed, 9 May 2018 07:33:01 -0400 Received: from gagarine.paulk.fr (gagarine [192.168.1.127]) by leonov.paulk.fr (Postfix) with ESMTPS id 13742C080A; Wed, 9 May 2018 13:33:00 +0200 (CEST) Received: by gagarine.paulk.fr (Postfix, from userid 114) id 5578AC0D63; Wed, 9 May 2018 13:32:59 +0200 (CEST) X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on gagarine.paulk.fr X-Spam-Level: X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED,SHORTCIRCUIT autolearn=disabled version=3.4.1 Received: from aptenodytes (LStLambert-657-1-97-87.w90-63.abo.wanadoo.fr [90.63.216.87]) by gagarine.paulk.fr (Postfix) with ESMTPSA id DB836C0D61; Wed, 9 May 2018 13:32:50 +0200 (CEST) Message-ID: Subject: Re: [PATCH v4 1/3] drm/panel: Add RGB666 variant of Innolux AT070TN90 From: Paul Kocialkowski To: Maxime Ripard Cc: devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, dri-devel@lists.freedesktop.org, linux-sunxi@googlegroups.com, Rob Herring , Mark Rutland , Chen-Yu Tsai , Thierry Reding , David Airlie Date: Wed, 09 May 2018 13:31:23 +0200 In-Reply-To: <20180509071226.ivh4s3wtczg2u7zw@flea> References: <20180507220413.21990-1-contact@paulk.fr> <20180509071226.ivh4s3wtczg2u7zw@flea> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.28.1 Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi, On Wed, 2018-05-09 at 09:12 +0200, Maxime Ripard wrote: > On Tue, May 08, 2018 at 12:04:11AM +0200, Paul Kocialkowski wrote: > > This adds timings for the RGB666 variant of the Innolux AT070TN90 panel, > > as found on the Ainol AW1 tablet. > > > > The panel also supports RGB888 output. When RGB666 mode is used instead, > > the two extra lanes per component are grounded. > > > > In the future, it might become necessary to introduce a dedicated > > device-tree property to specify the bus format to use instead of the > > default one for the panel. This will allow supporting different bus > > formats for the same panel modes. > > > > Signed-off-by: Paul Kocialkowski > > --- > > drivers/gpu/drm/panel/panel-simple.c | 26 ++++++++++++++++++++++++++ > > 1 file changed, 26 insertions(+) > > > > diff --git a/drivers/gpu/drm/panel/panel-simple.c b/drivers/gpu/drm/panel/panel-simple.c > > index cbf1ab404ee7..32e30d5a8f08 100644 > > --- a/drivers/gpu/drm/panel/panel-simple.c > > +++ b/drivers/gpu/drm/panel/panel-simple.c > > @@ -1063,6 +1063,29 @@ static const struct panel_desc innolux_at043tn24 = { > > .bus_flags = DRM_BUS_FLAG_DE_HIGH | DRM_BUS_FLAG_PIXDATA_POSEDGE, > > }; > > > > +static const struct drm_display_mode innolux_at070tn90_mode = { > > + .clock = 40000, > > + .hdisplay = 800, > > + .hsync_start = 800 + 112, > > + .hsync_end = 800 + 112 + 1, > > + .htotal = 800 + 112 + 1 + 87, > > + .vdisplay = 480, > > + .vsync_start = 480 + 141, > > + .vsync_end = 480 + 141 + 1, > > + .vtotal = 480 + 141 + 1 + 38, > > + .vrefresh = 60, > > +}; > > + > > +static const struct panel_desc innolux_at070tn90 = { > > + .modes = &innolux_at070tn90_mode, > > + .num_modes = 1, > > + .size = { > > + .width = 154, > > + .height = 86, > > + }, > > + .bus_format = MEDIA_BUS_FMT_RGB666_1X18, > > +}; > > + > > I'm not really convinced this is the right approach. You said it > yourself, the panel is using a 24-bits interface, and you just happen > to have a tablet that routed it using a 18-bits interface instead. > > That doesn't belong in the driver, especially associated to the > compatible, but where the routing is described: in the device > tree. And given that the panel interface is a 24 bits panel, if we > were to have a default, we should have this one, and not the one > fitting your use case. I fully agree, this is why I suggested introducing a dedicated dt property for selecting the bus format (in the commit message). I still proposed this patch as a temporary solution, but I'm definitely willing to craft a proper solution as well. Here is an initial proposition: 1. Making bus_format an array in struct panel_desc and listing all the relevant bus formats that the panel can support there; 2. Introducing an optional "bus-format" dt property that indicates which bus format to use, and using the first index of the bus formats array if the property is not present; 3. Checking that the bus format requested from dt is supported by the panel. What do you think? Paul -- Developer of free digital technology and hardware support. Website: https://www.paulk.fr/ Coding blog: https://code.paulk.fr/ Git repositories: https://git.paulk.fr/ https://git.code.paulk.fr/