From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.3 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS,USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 3CA2AC7618B for ; Wed, 24 Jul 2019 13:59:32 +0000 (UTC) Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 1124621926 for ; Wed, 24 Jul 2019 13:59:32 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="fKBIa3gH" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 1124621926 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=bootlin.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20170209; h=Sender:Content-Type:Cc: List-Subscribe:List-Help:List-Post:List-Archive:List-Unsubscribe:List-Id: In-Reply-To:MIME-Version:References:Message-ID:Subject:To:From:Date:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=vIXMlvPiZ7zfmEhiRWmefqzLOBh2VdAc/qCVk80HAQE=; b=fKBIa3gHh0NRSl9yORDZh86FA SFgAD5vYzcdaHz3N8aSV2ibF3gsOGNlqjfA7iL/UUL/VVY9rHmJVfnQZ3Btut+3wH5qY/IzFV8BDg VpgMm7dK/jxHAIFXqd0L4q8WKcuprlgIi0kD45e+I611hmr8PbnreXA9NrH9UCQhh5OrRkS8n74Qt ryuti6IMOr2SMKOkL00eNnLBxe8frsVgH2mkmZM0K7IukgoLhSRZoCkdZknWR1MynPfZ8SoAzMlhg Qc3vYe6p3xXsrozR43P82bE28++WtHhGykkZRU3UArrQBuHIBMyrCMOdCpmjxiU2EsEBhkM8Bn2fX G7g8fWd/A==; Received: from localhost ([127.0.0.1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.92 #3 (Red Hat Linux)) id 1hqHne-0005K1-LE; Wed, 24 Jul 2019 13:59:22 +0000 Received: from relay12.mail.gandi.net ([217.70.178.232]) by bombadil.infradead.org with esmtps (Exim 4.92 #3 (Red Hat Linux)) id 1hqHnH-0004xK-Se for linux-arm-kernel@lists.infradead.org; Wed, 24 Jul 2019 13:59:02 +0000 Received: from localhost (lfbn-1-17395-211.w86-250.abo.wanadoo.fr [86.250.200.211]) (Authenticated sender: maxime.ripard@bootlin.com) by relay12.mail.gandi.net (Postfix) with ESMTPSA id C4C96200004; Wed, 24 Jul 2019 13:58:46 +0000 (UTC) Date: Wed, 24 Jul 2019 15:58:46 +0200 From: Maxime Ripard To: Vasily Khoruzhick Subject: Re: [PATCH v2 7/7] arm64: dts: allwinner: a64: enable ANX6345 bridge on Teres-I Message-ID: <20190724135846.7mnuau4aih4zqm6a@flea> References: <20190612152022.c3cfhp4cauhzhfyr@flea> <20190701095842.fvganvycce2cy7jn@flea> <20190709085532.cdqv7whuesrjs64c@flea> <20190710114042.ybgavnxb4hgqrtor@flea> <20190712201543.krhsfjepd3cqndla@flea> MIME-Version: 1.0 In-Reply-To: User-Agent: NeoMutt/20180716 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20190724_065900_257656_14D80B99 X-CRM114-Status: GOOD ( 32.88 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Mark Rutland , devicetree , Sean Paul , David Airlie , Greg Kroah-Hartman , linux-kernel , dri-devel , Andrzej Hajda , Chen-Yu Tsai , Rob Herring , Torsten Duwe , Laurent Pinchart , Daniel Vetter , Harald Geyer , Thierry Reding , Thomas Gleixner , arm-linux , Icenowy Zheng Content-Type: multipart/mixed; boundary="===============2635115858786540365==" Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org --===============2635115858786540365== Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="ga3sbptupgkf2nsb" Content-Disposition: inline --ga3sbptupgkf2nsb Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Mon, Jul 15, 2019 at 05:28:53PM -0700, Vasily Khoruzhick wrote: > On Fri, Jul 12, 2019 at 1:15 PM Maxime Ripard wrote: > > > > On Wed, Jul 10, 2019 at 03:11:04PM -0700, Vasily Khoruzhick wrote: > > > On Wed, Jul 10, 2019 at 4:40 AM Maxime Ripard wrote: > > > > > > > There's another issue: if we introduce edp-connector we'll have to > > > > > > > specify power up delays somewhere (in dts? or in platform driver?), so > > > > > > > edp-connector doesn't really solve the issue of multiple panels with > > > > > > > same motherboard. > > > > > > > > > > > > And that's what that compatible is about :) > > > > > > > > > > Sorry, I fail to see how it would be different from using existing > > > > > panels infrastructure and different panels compatibles. I think Rob's > > > > > idea was to introduce generic edp-connector. > > > > > > > > Again, there's no such thing as a generic edp-connector. The spec > > > > doesn't define anything related to the power sequence for example. > > > > > > > > > If we can't make it generic then let's use panel infrastructure. > > > > > > > > Which uses a device specific compatible. Really, I'm not sure what > > > > your objection and / or argument is here. > > > > > > > > In addition, when that was brought up in the discussion, you rejected > > > > it because it was inconvenient: > > > > https://patchwork.freedesktop.org/patch/283012/?series=56163&rev=1#comment_535206 > > > > > > It is inconvenient, but I don't understand how having board-specific > > > connectors fixes it. > > > > How it would not fix it? > > I think I got your idea, but yet I think it's not the best solution. > > Do I understand correctly that you're proposing to introduce > board-specific edp-connector driver that will be aware of worst case > power up delays and will control backlight and power? > > Then why not to add another board-specific panel (e.g. > "pine64,pinebook-panel") to simple-panel.c that does the same? That would be fine for me too. Thierry was against it though IIRC, and I don't recall why exactly. > > You'll have one connector, without the need to describe each and every > > panel in the device tree and rely on the EDID instead, and you'll have > > the option to power up the regulator you need. > > > > I really don't understand what's the issue here, so let's take a step > > back. What are is the issue , what are your requirements, and how > > would you like that to be described ? > > We have a device (Pinebook) that uses the same board with multiple edp > panels. So far there're pinebooks with 3 different panels: 11" with > 768p panel, 11" with 1080p panel, 14" with 768p panel. > > Currently there's no way to describe all pinebooks with a single dts. > There's a simple workaround though -- we can just specify a panel with > worst power up delays in dts and it'll work since anx6345 driver > ignores panel modes anyway and uses EDID. > > Originally I proposed to extend simple-panel driver to support generic > edp-panel but it was rejected. I still believe that it's the best > solution assuming we can specify delays in dts, since panels list is > specific to particular device and it probably can't be reused, i.e. > there's no good reason to move it into C code. > > Rob Herring proposed to introduce edp-connector. While I still believe > that it's not accurate description of hardware since it'll have to > have backlight node (backlight is actually panel property) I was OK > with this approach assuming we can store delays in dts. > > Later it evolved into board-specific edp-connector. I think you got that wrong. As far as I'm concerned, the plan was to have two compatibles: the board-specific one, and the generic one. Something like compatible = "pine64,pinebook-edp-connector", "edp-connector"; or whatever. > So far I don't understand why everyone is trying to avoid introducing > edp-panel driver that can read delays from dts. Basically, I don't > understand what's the magic behind simple-panel.c and why new panels > should be added there rather than described in dts. [1] Doesn't > explain that. So others might have different viewpoints here as well, but the major downside I see in putting those kind of values in the device tree is that at some point, someone will get it wrong, and chances are that even for the same panel, everyone will use a slightly different set of timings. And once it's wrong, then it's a mess to fix. You have to track down every DT using it, make sure it's corrected, and then every user will have to change their DT in their system. Whereas if you have just a compatible and those timings in the kernel, then the only thing required is a kernel update, which should be a pretty standard operation. Maxime -- Maxime Ripard, Bootlin Embedded Linux and Kernel engineering https://bootlin.com --ga3sbptupgkf2nsb Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iHUEABYIAB0WIQRcEzekXsqa64kGDp7j7w1vZxhRxQUCXThkFgAKCRDj7w1vZxhR xdmDAP9yBWH/KYH8hNsfJpjtSxRuDZg1xa/Ai5yq/48P70rBqQEAxJBFYLdvAn8g WJBWvY6ToqNpGVah2fBV3mDR/Au2/wc= =7SCN -----END PGP SIGNATURE----- --ga3sbptupgkf2nsb-- --===============2635115858786540365== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel --===============2635115858786540365==--