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 E6694C73C64 for ; Wed, 10 Jul 2019 11:40:48 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id C3C802064B for ; Wed, 10 Jul 2019 11:40:48 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727158AbfGJLkr (ORCPT ); Wed, 10 Jul 2019 07:40:47 -0400 Received: from relay3-d.mail.gandi.net ([217.70.183.195]:47661 "EHLO relay3-d.mail.gandi.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726043AbfGJLkr (ORCPT ); Wed, 10 Jul 2019 07:40:47 -0400 X-Originating-IP: 86.250.200.211 Received: from localhost (lfbn-1-17395-211.w86-250.abo.wanadoo.fr [86.250.200.211]) (Authenticated sender: maxime.ripard@bootlin.com) by relay3-d.mail.gandi.net (Postfix) with ESMTPSA id CFA7B60004; Wed, 10 Jul 2019 11:40:42 +0000 (UTC) Date: Wed, 10 Jul 2019 13:40:42 +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: <20190710114042.ybgavnxb4hgqrtor@flea> References: <20190607062802.m5wslx3imiqooq5a@flea> <20190607094030.GA12373@lst.de> <66707fcc-b48e-02d3-5ed7-6b7e77d53266@samsung.com> <20190612152022.c3cfhp4cauhzhfyr@flea> <20190701095842.fvganvycce2cy7jn@flea> <20190709085532.cdqv7whuesrjs64c@flea> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="escjyxb6ltmmy4x5" 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 --escjyxb6ltmmy4x5 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Tue, Jul 09, 2019 at 01:30:18PM -0700, Vasily Khoruzhick wrote: > On Tue, Jul 9, 2019 at 1:55 AM Maxime Ripard wrote: > > > > On Mon, Jul 08, 2019 at 05:49:21PM -0700, Vasily Khoruzhick wrote: > > > > > Maybe instead of edp-connector one would introduce integrator's specific > > > > > connector, for example with compatible "olimex,teres-edp-connector" > > > > > which should follow edp abstract connector rules? This will be at least > > > > > consistent with below presentation[1] - eDP requirements depends on > > > > > integrator. Then if olimex has standard way of dealing with panels > > > > > present in olimex/teres platforms the driver would then create > > > > > drm_panel/drm_connector/drm_bridge(?) according to these rules, I guess. > > > > > Anyway it still looks fishy for me :), maybe because I am not > > > > > familiarized with details of these platforms. > > > > > > > > That makes sense yes > > > > > > Actually, it makes no sense at all. Current implementation for anx6345 > > > driver works fine as is with any panel specified assuming panel delays > > > are long enough for connected panel. It just doesn't use panel timings > > > from the driver. Creating a platform driver for connector itself looks > > > redundant since it can't be reused, it doesn't describe actual > > > hardware and it's just defeats purpose of DT by introducing > > > board-specific code. > > > > I'm not sure where you got the idea that the purpose of DT is to not > > have any board-specific code. > > I believe DT was an attempt to move to declarative approach for > describing hardware. Yes, we have different compatibles for different > devices but they're specific to particular device rather than > particular board. Device interconnection is described in DT along with > some properties rather than in board-specific C-file. You're right, but it's not incompatible with having some code to deal with some board quirk. > Introducing board-specific compatible for a connector isn't looking > right to me. If that board has a board-specific behaviour for it's connector, then what's the issue? You can't describe all the quirks in the all boards using purely properties. > > It's perfectly fine to have some, that's even why there's a compatible > > assigned to each and every board. > > > > What the DT is about is allowing us to have a generic behaviour that > > we can detect: we can have a given behaviour for a given board, and a > > separate one for another one, and this will be evaluated at runtime. > > > > This is *exactly* what this is about: we can have a compatible that > > sets a given, more specific, behaviour (olimex,teres-edp-connector) > > while saying that this is compatible with the generic behaviour > > (edp-connector). That way, any OS will know what quirk to apply if > > needed, and if not that it can use the generic behaviour. > > > > And we could create a generic driver, for the generic behaviour if > > needed. > > > > > 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 And I agree with you on that one. > > > I'd say DT overlays should be preferred solution here, not another > > > connector binding. > > > > Overlays are a way to apply a device tree dynamically. It's orthogonal > > to the binding. > > It isn't orthogonal to original problem though. It is. The original problem is that you want to power up whatever is on the other side of a eDP link using an arbitrary regulator. This is a "how do I describe that in my DT" problem, and it really has nothing to do with how the DT is being passed to the kernel. Maxime -- Maxime Ripard, Bootlin Embedded Linux and Kernel engineering https://bootlin.com --escjyxb6ltmmy4x5 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iHUEABYIAB0WIQRcEzekXsqa64kGDp7j7w1vZxhRxQUCXSXOugAKCRDj7w1vZxhR xdG+AP9pfxb7uYcDFKG6xikGZewhXzpg/acmPfrETXLF2B1jZQD7Bc2oEF0IKqh7 tiE8F0AU/5LApsNMhblCY9s+dkDrFwU= =gnu6 -----END PGP SIGNATURE----- --escjyxb6ltmmy4x5-- 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=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,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 71FB8C73C64 for ; Wed, 10 Jul 2019 11:41:12 +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 40F0B2064B for ; Wed, 10 Jul 2019 11:41:12 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="LX9vjg6o" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 40F0B2064B 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=vsG2m/664vLzfnoNRhhOmj+zPg/nAiNlZPrmiF0iq/k=; b=LX9vjg6o6rYiAEjxb/ChBB1nj dJqLgY+08IEp8TjgEIh+ipEekKBG/hpPz7JxHbwBaRmHtxAWe0ldUdjTJ4VdgHjAQUt6b3r2EHgk5 SCUhycGEkEL5aCyedlSXtprXxuV03D/tJP/Mye0rXyKk19vXFSkT/JwlA1zpPR6LYWtAcMDGJDxKA n8PdPKwFWQ+F0NKQqN45VjAxA9XjtdY4R+Cn94HQQ00gwhWqZUm/GDs8njd/HNfuDATC8oOf3tKbm 5mrMyHoAx9c339eSj4Up5octgmp2eU+ACMrXj7qLS7asfHmNdGJ6OhNfRRn4GJI2oH1MNhigFCHwr UyFESgecg==; 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 1hlAyF-00067j-HZ; Wed, 10 Jul 2019 11:41:11 +0000 Received: from relay3-d.mail.gandi.net ([217.70.183.195]) by bombadil.infradead.org with esmtps (Exim 4.92 #3 (Red Hat Linux)) id 1hlAyA-00066L-8y for linux-arm-kernel@lists.infradead.org; Wed, 10 Jul 2019 11:41:09 +0000 X-Originating-IP: 86.250.200.211 Received: from localhost (lfbn-1-17395-211.w86-250.abo.wanadoo.fr [86.250.200.211]) (Authenticated sender: maxime.ripard@bootlin.com) by relay3-d.mail.gandi.net (Postfix) with ESMTPSA id CFA7B60004; Wed, 10 Jul 2019 11:40:42 +0000 (UTC) Date: Wed, 10 Jul 2019 13:40:42 +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: <20190710114042.ybgavnxb4hgqrtor@flea> References: <20190607062802.m5wslx3imiqooq5a@flea> <20190607094030.GA12373@lst.de> <66707fcc-b48e-02d3-5ed7-6b7e77d53266@samsung.com> <20190612152022.c3cfhp4cauhzhfyr@flea> <20190701095842.fvganvycce2cy7jn@flea> <20190709085532.cdqv7whuesrjs64c@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-20190710_044106_637439_8ECEE9CC X-CRM114-Status: GOOD ( 34.44 ) 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="===============8309068559625457640==" Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org --===============8309068559625457640== Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="escjyxb6ltmmy4x5" Content-Disposition: inline --escjyxb6ltmmy4x5 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Tue, Jul 09, 2019 at 01:30:18PM -0700, Vasily Khoruzhick wrote: > On Tue, Jul 9, 2019 at 1:55 AM Maxime Ripard wrote: > > > > On Mon, Jul 08, 2019 at 05:49:21PM -0700, Vasily Khoruzhick wrote: > > > > > Maybe instead of edp-connector one would introduce integrator's specific > > > > > connector, for example with compatible "olimex,teres-edp-connector" > > > > > which should follow edp abstract connector rules? This will be at least > > > > > consistent with below presentation[1] - eDP requirements depends on > > > > > integrator. Then if olimex has standard way of dealing with panels > > > > > present in olimex/teres platforms the driver would then create > > > > > drm_panel/drm_connector/drm_bridge(?) according to these rules, I guess. > > > > > Anyway it still looks fishy for me :), maybe because I am not > > > > > familiarized with details of these platforms. > > > > > > > > That makes sense yes > > > > > > Actually, it makes no sense at all. Current implementation for anx6345 > > > driver works fine as is with any panel specified assuming panel delays > > > are long enough for connected panel. It just doesn't use panel timings > > > from the driver. Creating a platform driver for connector itself looks > > > redundant since it can't be reused, it doesn't describe actual > > > hardware and it's just defeats purpose of DT by introducing > > > board-specific code. > > > > I'm not sure where you got the idea that the purpose of DT is to not > > have any board-specific code. > > I believe DT was an attempt to move to declarative approach for > describing hardware. Yes, we have different compatibles for different > devices but they're specific to particular device rather than > particular board. Device interconnection is described in DT along with > some properties rather than in board-specific C-file. You're right, but it's not incompatible with having some code to deal with some board quirk. > Introducing board-specific compatible for a connector isn't looking > right to me. If that board has a board-specific behaviour for it's connector, then what's the issue? You can't describe all the quirks in the all boards using purely properties. > > It's perfectly fine to have some, that's even why there's a compatible > > assigned to each and every board. > > > > What the DT is about is allowing us to have a generic behaviour that > > we can detect: we can have a given behaviour for a given board, and a > > separate one for another one, and this will be evaluated at runtime. > > > > This is *exactly* what this is about: we can have a compatible that > > sets a given, more specific, behaviour (olimex,teres-edp-connector) > > while saying that this is compatible with the generic behaviour > > (edp-connector). That way, any OS will know what quirk to apply if > > needed, and if not that it can use the generic behaviour. > > > > And we could create a generic driver, for the generic behaviour if > > needed. > > > > > 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 And I agree with you on that one. > > > I'd say DT overlays should be preferred solution here, not another > > > connector binding. > > > > Overlays are a way to apply a device tree dynamically. It's orthogonal > > to the binding. > > It isn't orthogonal to original problem though. It is. The original problem is that you want to power up whatever is on the other side of a eDP link using an arbitrary regulator. This is a "how do I describe that in my DT" problem, and it really has nothing to do with how the DT is being passed to the kernel. Maxime -- Maxime Ripard, Bootlin Embedded Linux and Kernel engineering https://bootlin.com --escjyxb6ltmmy4x5 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iHUEABYIAB0WIQRcEzekXsqa64kGDp7j7w1vZxhRxQUCXSXOugAKCRDj7w1vZxhR xdG+AP9pfxb7uYcDFKG6xikGZewhXzpg/acmPfrETXLF2B1jZQD7Bc2oEF0IKqh7 tiE8F0AU/5LApsNMhblCY9s+dkDrFwU= =gnu6 -----END PGP SIGNATURE----- --escjyxb6ltmmy4x5-- --===============8309068559625457640== 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 --===============8309068559625457640==--