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.2 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,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 837B2C742D7 for ; Fri, 12 Jul 2019 20:15:52 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 5F43420989 for ; Fri, 12 Jul 2019 20:15:52 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727610AbfGLUPv (ORCPT ); Fri, 12 Jul 2019 16:15:51 -0400 Received: from relay2-d.mail.gandi.net ([217.70.183.194]:47113 "EHLO relay2-d.mail.gandi.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727125AbfGLUPu (ORCPT ); Fri, 12 Jul 2019 16:15:50 -0400 X-Originating-IP: 90.89.68.76 Received: from localhost (lfbn-1-10718-76.w90-89.abo.wanadoo.fr [90.89.68.76]) (Authenticated sender: maxime.ripard@bootlin.com) by relay2-d.mail.gandi.net (Postfix) with ESMTPSA id 5BEF640002; Fri, 12 Jul 2019 20:15:44 +0000 (UTC) Date: Fri, 12 Jul 2019 22:15:43 +0200 From: Maxime Ripard To: Vasily Khoruzhick Cc: Andrzej Hajda , Torsten Duwe , Harald Geyer , Chen-Yu Tsai , Rob Herring , Mark Rutland , Thierry Reding , David Airlie , Daniel Vetter , Laurent Pinchart , Icenowy Zheng , Sean Paul , Greg Kroah-Hartman , Thomas Gleixner , dri-devel , devicetree , arm-linux , linux-kernel Subject: Re: [PATCH v2 7/7] arm64: dts: allwinner: a64: enable ANX6345 bridge on Teres-I Message-ID: <20190712201543.krhsfjepd3cqndla@flea> References: <20190607094030.GA12373@lst.de> <66707fcc-b48e-02d3-5ed7-6b7e77d53266@samsung.com> <20190612152022.c3cfhp4cauhzhfyr@flea> <20190701095842.fvganvycce2cy7jn@flea> <20190709085532.cdqv7whuesrjs64c@flea> <20190710114042.ybgavnxb4hgqrtor@flea> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20180716 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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? 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 ? Maxime -- Maxime Ripard, Bootlin Embedded Linux and Kernel engineering https://bootlin.com