Received: by 2002:a25:5b86:0:0:0:0:0 with SMTP id p128csp1684699ybb; Fri, 29 Mar 2019 09:14:09 -0700 (PDT) X-Google-Smtp-Source: APXvYqwyskaDEkYA9uwoC0o/psCc3NdFY0d+lYtDQn6yoO2aJpqwXQIJTGzM9qLE5mdmF2NYner6 X-Received: by 2002:a17:902:bb98:: with SMTP id m24mr28122422pls.17.1553876049062; Fri, 29 Mar 2019 09:14:09 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1553876049; cv=none; d=google.com; s=arc-20160816; b=Sj/uLjJi4CcyM2DyRzwkJZKe4+xvGFdk24WfQdyPuAYYI7CD7HPmEPc21QJY9n5U5z mEcI58Sd1OCHlAZBQUmnew2AXcfRBfTx2NiR0Eq79LtJJ+1VE/rMj58+aT0lmvjXiuuF cYQ+qgtrSOaqVS5mCRMqk39Feh6c0VAXe/IXiZ+49nnj1ODY4EHEJ0ltrph9MfKNTEhU pqv/8AfbzXPTPPpJUTBH/Yg4X1/PLII0r9OUttkVPVK17ZKprchpXAuD094zh88/IVNU DYuGgoAy5Hx70wCSpB58ey22fDzAPHlykHiJIEFteGOF0feiugHSW1XgFqfvdfYOjLJu 3FZA== 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:cc:to:subject :message-id:date:from:in-reply-to:references:mime-version :dkim-signature; bh=r+OQK/Rlg0PSdbQ9XnGysVI0iPX47oFWCbiRyqmyJQ0=; b=OXId4hzI5ce+wbZnmM4qelK2C3WkR08fn3yj9Wcqd7tNN+KR2d855XlzRI0XPA7qGs BzHQjWzAF7sCZE74ezR1QbW1OwMCRJnR0CFC3d9x5XeioCMfsJwtNMiX6CI15KGLf6m8 gdJYESUHjByfcu9YET4Mjq96g15/e4m0bNSjEBoZyu1Ny4+zkJb1PkbaPRU9sq9ub9o/ 6WqbfCAdyQZK9JXPWFZMaxkLIWRSuI8UufsKV9bBXYXtToPZz65X4eeag7YScvDwMmTK mMSfKj/k/yOMSGxP3rTl/9SQMjeLNBbnSjuKvNKM+Qg+Dz7Js1y8Z/5o09GcecKMGBHH h+bA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=H5aU7bBu; 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; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id s20si2202936pgm.137.2019.03.29.09.13.52; Fri, 29 Mar 2019 09:14:09 -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; dkim=pass header.i=@kernel.org header.s=default header.b=H5aU7bBu; 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; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729722AbfC2QM7 (ORCPT + 99 others); Fri, 29 Mar 2019 12:12:59 -0400 Received: from mail.kernel.org ([198.145.29.99]:58064 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728980AbfC2QM6 (ORCPT ); Fri, 29 Mar 2019 12:12:58 -0400 Received: from mail-qk1-f182.google.com (mail-qk1-f182.google.com [209.85.222.182]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 588DC218A6; Fri, 29 Mar 2019 16:12:57 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1553875977; bh=os+F3qD9dnbJBb0Vup0xUy0RmpAR3x/0FLfaUR77dM8=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=H5aU7bBuRVKjRwWkzBBVxl6jrb5DHO12+SRNEhBUzWE/rpAmeSNUotdKZwLE1rx1o 8tghWVR5maCGZtHqH5OXDd8PQXXC61QwFUcHIbvTXVc4QgYUZ0WDttdzkLmESRltQ8 iJUzkuRhHCTuj4SG0xWrWdumUMM2XZSaEI0Vi2po= Received: by mail-qk1-f182.google.com with SMTP id o129so1673040qke.8; Fri, 29 Mar 2019 09:12:57 -0700 (PDT) X-Gm-Message-State: APjAAAWzkvUrgr04z1CGQnyOnM1w6GBqfShSsnB99Do0qGpgSQaXxMEE bZmOLiqhANaxglKKh+PbmagVcBu2CXQShAkBMQ== X-Received: by 2002:a37:d285:: with SMTP id f127mr39655924qkj.147.1553875976561; Fri, 29 Mar 2019 09:12:56 -0700 (PDT) MIME-Version: 1.0 References: <20190328171710.31949-1-dianders@chromium.org> <20190328171710.31949-2-dianders@chromium.org> In-Reply-To: From: Rob Herring Date: Fri, 29 Mar 2019 11:12:45 -0500 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH v4 1/7] dt-bindings: Add panel-timing subnode to simple-panel To: Doug Anderson Cc: Ezequiel Garcia , Thierry Reding , Heiko Stuebner , Sean Paul , "open list:ARM/Rockchip SoC..." , Laurent Pinchart , dri-devel , Boris Brezillon , =?UTF-8?Q?Enric_Balletb=C3=B2?= , Matthias Kaehlcke , Eric Anholt , Jeffy Chen , =?UTF-8?Q?St=C3=A9phane_Marchesin?= , devicetree@vger.kernel.org, LKML , David Airlie , Mark Rutland , Daniel Vetter Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Mar 28, 2019 at 6:50 PM Doug Anderson wrote= : > > Hi, > > > On Thu, Mar 28, 2019 at 1:27 PM Ezequiel Garcia = wrote: > > > > On Thu, 2019-03-28 at 10:17 -0700, Douglas Anderson wrote: > > > From: Sean Paul > > > > > > This patch adds a new subnode to simple-panel allowing us to override > > > the typical timing expressed in the panel's display_timing. > > > > > > Changes in v2: > > > - Split out the binding into a new patch (Rob) > > > - display-timings is a new section (Rob) > > > - Use the full display-timings subnode instead of picking the timing > > > out (Rob/Thierry) > > > Changes in v3: > > > - Go back to using the timing subnode directly, but rename to > > > panel-timing (Rob) > > > Changes in v4: > > > - Simplify desc. for when override should be used (Thierry/Laurent) > > > - Removed Rob H review since it's been a year and wording changed > > > > > > Cc: Doug Anderson > > > Cc: Eric Anholt > > > Cc: Heiko Stuebner > > > Cc: Jeffy Chen > > > Cc: Rob Herring > > > Cc: St=C3=A9phane Marchesin > > > Cc: Thierry Reding > > > Cc: devicetree@vger.kernel.org > > > Cc: dri-devel@lists.freedesktop.org > > > Cc: linux-rockchip@lists.infradead.org > > > Signed-off-by: Sean Paul > > > Signed-off-by: Douglas Anderson > > > --- > > > > > > .../bindings/display/panel/simple-panel.txt | 24 +++++++++++++++++= ++ > > > 1 file changed, 24 insertions(+) > > > > > > diff --git a/Documentation/devicetree/bindings/display/panel/simple-p= anel.txt b/Documentation/devicetree/bindings/display/panel/simple-panel.txt > > > index b2b872c710f2..6157f86ddce4 100644 > > > --- a/Documentation/devicetree/bindings/display/panel/simple-panel.tx= t > > > +++ b/Documentation/devicetree/bindings/display/panel/simple-panel.tx= t > > > @@ -15,6 +15,18 @@ Optional properties: > > > (hot plug detect) signal, but the signal isn't hooked up so we sho= uld > > > hardcode the max delay from the panel spec when powering up the pa= nel. > > > > > > +panel-timing subnode > > > +-------------------- > > > + > > > +This optional subnode is for devices which require a mode differing > > > +from the panel's "typical" display timing. The panel timings provid= ed > > > +here will be ignored if they are found to be outside of allowable > > > +ranges for the given panel. > > > + > > > > Is it OK to put this comment about how the implementation > > will behave when values are out of range, given this is just a binding > > spec? > > > > Perhaps -if needed- this sentence can be rephrased to state that, > > e.g. the OS may not be able to apply these values, if the controller > > or device is unable to? > > I will defer to Rob H. on this one, but I'm happy to simply remove the > last sentence. I was trying to add a more OS-agnostic version of the > bullet points from V3 but agree that we could just remove this from > the bindings completely. Following my opinion that it's not the kernel's job to validate bindings, I would say it's fine for the OS to blindly apply them if it chooses. Plus with schema, you can provide the ranges of values and validate DTs up front (unless you want to validate some result of math operations). Rob