From patchwork Fri Sep 10 10:11:56 2021 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Maxime Ripard X-Patchwork-Id: 12484697 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=-18.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER, INCLUDES_PATCH,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,USER_AGENT_GIT autolearn=unavailable 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 248CCC433FE for ; Fri, 10 Sep 2021 10:12:48 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 093F5611C0 for ; Fri, 10 Sep 2021 10:12:48 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232284AbhIJKN5 (ORCPT ); Fri, 10 Sep 2021 06:13:57 -0400 Received: from wnew4-smtp.messagingengine.com ([64.147.123.18]:60025 "EHLO wnew4-smtp.messagingengine.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232238AbhIJKN4 (ORCPT ); Fri, 10 Sep 2021 06:13:56 -0400 Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailnew.west.internal (Postfix) with ESMTP id 103372B00938; Fri, 10 Sep 2021 06:12:36 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute3.internal (MEProxy); Fri, 10 Sep 2021 06:12:39 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cerno.tech; h= from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding; s=fm3; bh=bC6Qg+WSUjJuy 8/H41PXAgS7iT5lIcAqR3nnFPZQTjU=; b=A0jde9XNNQM6+JV5JRvXJ+djXGhLu n6Kav7Tksk8vlm7ZkrQiboBGg56Jz+mwTpHV6Xi2s6wkq0tS7PJtZxefeFpitXvb 2FhLx50EEoDvrqkSdzC8eANCbJJGPaS/ki1uQFnP4RhZQYiMaD6DU4ndyWgQsmbj K/ogPtpU7hwgflVFsA/BfSSxGv/0PHheOIA5YxdCX1RGeXiPZaOH2rUh5yQ7x5ks Ps64kUpYlOSktFTG4e/1E4UGZcaZdxAGdllGhGIUgljXPGSmokKDOvIVosekUbvR cUSw79/Uj2nY26cf/Vfrn5J1cIMZy3F9uuCZgjNFja+Vl2oJai4EdLAtQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:date:from :in-reply-to:message-id:mime-version:references:subject:to :x-me-proxy:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s= fm3; bh=bC6Qg+WSUjJuy8/H41PXAgS7iT5lIcAqR3nnFPZQTjU=; b=XdIeHopA K5yvJ9Nnt7og/15uywzWq1AJzkzerNxMQ01HRBJVKqqvNPZV0IeKglCToAP6GjDj 4rpDHRTmDWePu0Ex/Ou054Nhurb9W3iP/OGON9h7cn751nvTTqCyicpncXKZlMzG F9N04TgqHkp8gUI26/lE9WWampqwCLVuQfPXlGWs39TvSMg3KZUl7ecKoZRy7gS/ It2Vnkv59sLoU3zhpvcbGQJGCDP0Fxn3A2t9hXaoTa7q64TB/WYaFKMDg5YhOR1+ Yhrv1q31TOq08bEpIbln8iFjop7J6tTxRjL/8Ri/eza8oqTlYc72ExHC2Bb2QKpW A6dJESrX5hygug== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvtddrudeguddgvdegucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhephffvufffkffojghfggfgsedtkeertdertddtnecuhfhrohhmpeforgigihhm vgcutfhiphgrrhguuceomhgrgihimhgvsegtvghrnhhordhtvggthheqnecuggftrfgrth htvghrnhepvdekleevfeffkeejhfffueelteelfeduieefheduudfggffhhfffheevveeh hedvnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepmh grgihimhgvsegtvghrnhhordhtvggthh X-ME-Proxy: Received: by mail.messagingengine.com (Postfix) with ESMTPA; Fri, 10 Sep 2021 06:12:33 -0400 (EDT) From: Maxime Ripard To: Andrzej Hajda , Sam Ravnborg , Daniel Vetter , David Airlie , Jonas Karlman , Laurent Pinchart , Thierry Reding , Maarten Lankhorst , Thomas Zimmermann , Maxime Ripard , Neil Armstrong , Robert Foss , Jernej Skrabec Cc: Sean Paul , freedreno@lists.freedesktop.org, Kyungmin Park , linux-kernel@vger.kernel.org, Xinliang Liu , Seung-Woo Kim , Tian Tao , Inki Dae , linux-samsung-soc@vger.kernel.org, linux-arm-msm@vger.kernel.org, Rob Clark , dri-devel@lists.freedesktop.org, John Stultz , Chen Feng , Xinwei Kong , Joonyoung Shim Subject: [PATCH v4 02/24] drm/bridge: Document the probe issue with MIPI-DSI bridges Date: Fri, 10 Sep 2021 12:11:56 +0200 Message-Id: <20210910101218.1632297-3-maxime@cerno.tech> X-Mailer: git-send-email 2.31.1 In-Reply-To: <20210910101218.1632297-1-maxime@cerno.tech> References: <20210910101218.1632297-1-maxime@cerno.tech> MIME-Version: 1.0 Precedence: bulk List-ID: X-Mailing-List: linux-arm-msm@vger.kernel.org Interactions between bridges, panels, MIPI-DSI host and the component framework are not trivial and can lead to probing issues when implementing a display driver. Let's document the various cases we need too consider, and the solution to support all the cases. Signed-off-by: Maxime Ripard Reviewed-by: Andrzej Hajda --- Documentation/gpu/drm-kms-helpers.rst | 6 +++ drivers/gpu/drm/drm_bridge.c | 57 +++++++++++++++++++++++++++ 2 files changed, 63 insertions(+) diff --git a/Documentation/gpu/drm-kms-helpers.rst b/Documentation/gpu/drm-kms-helpers.rst index 10f8df7aecc0..ec2f65b31930 100644 --- a/Documentation/gpu/drm-kms-helpers.rst +++ b/Documentation/gpu/drm-kms-helpers.rst @@ -157,6 +157,12 @@ Display Driver Integration .. kernel-doc:: drivers/gpu/drm/drm_bridge.c :doc: display driver integration +Special Care with MIPI-DSI bridges +---------------------------------- + +.. kernel-doc:: drivers/gpu/drm/drm_bridge.c + :doc: special care dsi + Bridge Operations ----------------- diff --git a/drivers/gpu/drm/drm_bridge.c b/drivers/gpu/drm/drm_bridge.c index baff74ea4a33..7cc2d2f94ae3 100644 --- a/drivers/gpu/drm/drm_bridge.c +++ b/drivers/gpu/drm/drm_bridge.c @@ -96,6 +96,63 @@ * documentation of bridge operations for more details). */ +/** + * DOC: special care dsi + * + * The interaction between the bridges and other frameworks involved in + * the probing of the upstream driver and the bridge driver can be + * challenging. Indeed, there's multiple cases that needs to be + * considered: + * + * - The upstream driver doesn't use the component framework and isn't a + * MIPI-DSI host. In this case, the bridge driver will probe at some + * point and the upstream driver should try to probe again by returning + * EPROBE_DEFER as long as the bridge driver hasn't probed. + * + * - The upstream driver doesn't use the component framework, but is a + * MIPI-DSI host. The bridge device uses the MIPI-DCS commands to be + * controlled. In this case, the bridge device is a child of the + * display device and when it will probe it's assured that the display + * device (and MIPI-DSI host) is present. The upstream driver will be + * assured that the bridge driver is connected between the + * &mipi_dsi_host_ops.attach and &mipi_dsi_host_ops.detach operations. + * Therefore, it must run mipi_dsi_host_register() in its probe + * function, and then run drm_bridge_attach() in its + * &mipi_dsi_host_ops.attach hook. + * + * - The upstream driver uses the component framework and is a MIPI-DSI + * host. The bridge device uses the MIPI-DCS commands to be + * controlled. This is the same situation than above, and can run + * mipi_dsi_host_register() in either its probe or bind hooks. + * + * - The upstream driver uses the component framework and is a MIPI-DSI + * host. The bridge device uses a separate bus (such as I2C) to be + * controlled. In this case, there's no correlation between the probe + * of the bridge and upstream drivers, so care must be taken to avoid + * an endless EPROBE_DEFER loop, with each driver waiting for the + * other to probe. + * + * The ideal pattern to cover the last item (and all the others in the + * MIPI-DSI host driver case) is to split the operations like this: + * + * - The MIPI-DSI host driver must run mipi_dsi_host_register() in its + * probe hook. It will make sure that the MIPI-DSI host sticks around, + * and that the driver's bind can be called. + * + * - In its probe hook, the bridge driver must try to find its MIPI-DSI + * host, register as a MIPI-DSI device and attach the MIPI-DSI device + * to its host. The bridge driver is now functional. + * + * - In its &struct mipi_dsi_host_ops.attach hook, the MIPI-DSI host can + * now add its component. Its bind hook will now be called and since + * the bridge driver is attached and registered, we can now look for + * and attach it. + * + * At this point, we're now certain that both the upstream driver and + * the bridge driver are functional and we can't have a deadlock-like + * situation when probing. + */ + static DEFINE_MUTEX(bridge_lock); static LIST_HEAD(bridge_list);