From patchwork Thu Mar 7 10:10:30 2019 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Maxime Ripard X-Patchwork-Id: 10842593 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork-2.web.codeaurora.org (Postfix) with ESMTP id 5C2FB1823 for ; Thu, 7 Mar 2019 10:10:42 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 480EA2E18E for ; Thu, 7 Mar 2019 10:10:42 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 3BCED2EB4F; Thu, 7 Mar 2019 10:10:42 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-5.2 required=2.0 tests=BAYES_00,MAILING_LIST_MULTI, RCVD_IN_DNSWL_MED autolearn=ham version=3.3.1 Received: from gabe.freedesktop.org (gabe.freedesktop.org [131.252.210.177]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.wl.linuxfoundation.org (Postfix) with ESMTPS id 0497D2E18E for ; Thu, 7 Mar 2019 10:10:40 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 8634B8940E; Thu, 7 Mar 2019 10:10:38 +0000 (UTC) X-Original-To: dri-devel@lists.freedesktop.org Delivered-To: dri-devel@lists.freedesktop.org Received: from relay8-d.mail.gandi.net (relay8-d.mail.gandi.net [217.70.183.201]) by gabe.freedesktop.org (Postfix) with ESMTPS id 935298940E for ; Thu, 7 Mar 2019 10:10:36 +0000 (UTC) X-Originating-IP: 90.88.150.179 Received: from localhost (aaubervilliers-681-1-31-179.w90-88.abo.wanadoo.fr [90.88.150.179]) (Authenticated sender: maxime.ripard@bootlin.com) by relay8-d.mail.gandi.net (Postfix) with ESMTPSA id E9DC41BF211; Thu, 7 Mar 2019 10:10:32 +0000 (UTC) From: Maxime Ripard To: Maarten Lankhorst , Sean Paul , Maxime Ripard , Eric Anholt Subject: [PATCH] drm/panel: panel-simple: Support panel-dpi Date: Thu, 7 Mar 2019 11:10:30 +0100 Message-Id: <20190307101030.3822-1-maxime.ripard@bootlin.com> X-Mailer: git-send-email 2.20.1 MIME-Version: 1.0 X-BeenThere: dri-devel@lists.freedesktop.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Direct Rendering Infrastructure - Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: eben@raspberrypi.org, dri-devel@lists.freedesktop.org, Paul Kocialkowski , Thierry Reding , Laurent Pinchart , Thomas Petazzoni Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" X-Virus-Scanned: ClamAV using ClamSMTP The kernel has a device tree binding for panel-dpi which allows for the panel timings to be described in the device-tree, however it wasn't supported so far except in a (small) number of KMS drivers that had an ad-hoc solution for this (omapdrm for example). Just like we've seen with panel-lvds, and even though the current dogma is to set the timings within the driver, having them in the device tree provides a number of benefits. The first is that it allows third party users to enable a random panel without having to modify and recompile their kernel of choice. This might sound like what we're trying to avoid in the first place, but it significantly lowers the barrier of entry, both technical and practical. Indeed, users might not have the knowledge on how to recompile and modify a kernel by their own, or might not have any documentation on the panel itself which would prevent any inclusion. But moderns systems also tend to move to mechanisms like secure boot which would prevent that kernel, provided that the kernel was able to do that, from running in the system, unless you would know how (and be able) to install custom keys into your system. While the DT itself might have the same constraints, mechanisms like the overlays allows to circumvent it. Another thing that panel-dpi allows to address is EMC, where even though the timings described in the driver could be functional on the board and for the panel, it would be better to use another arbitrary frequency on a particular board to increase the spread of the EM emissions. Signed-off-by: Maxime Ripard --- drivers/gpu/drm/panel/panel-simple.c | 47 +++++++++++++++++++++++++--- 1 file changed, 42 insertions(+), 5 deletions(-) diff --git a/drivers/gpu/drm/panel/panel-simple.c b/drivers/gpu/drm/panel/panel-simple.c index 9e8218f6a3f2..9aee02f05a1d 100644 --- a/drivers/gpu/drm/panel/panel-simple.c +++ b/drivers/gpu/drm/panel/panel-simple.c @@ -34,6 +34,7 @@ #include #include