Received: by 2002:a05:6a10:1287:0:0:0:0 with SMTP id d7csp4571499pxv; Tue, 20 Jul 2021 06:53:55 -0700 (PDT) X-Google-Smtp-Source: ABdhPJw0EPT8u0XiCKVEoY6siDpeeQTJW8WTvrpqzpd3XkkoEgRU1tIZKT2UqPBbvR8+2bnY0bF/ X-Received: by 2002:a05:6602:2406:: with SMTP id s6mr17603373ioa.159.1626789235715; Tue, 20 Jul 2021 06:53:55 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1626789235; cv=none; d=google.com; s=arc-20160816; b=KuxjLIA3uOdWwiUY9OUcTsc6NKlEb7bsJcx7tucexcZvFdJQxKVnFkqFvwZcQmYSb3 0RymIk4k6gpQxUbjU+VQg7T6DPbCWkEqg8Hp/mVWwwg56wi14rn6zACLE0tqL5lFUeP3 9lcz9A9zo8K0b4dXcFSUJcG70whEKD1nAehXriSmAzdbQM1bD3jH5vGOt8cbuE16H5Sv Ow9NUd63Zf9wxkpJmMRpkONa8Zjvs2k7QCy4CfCm9/2Vd0hMr8A/Ey+YsYIfnOOYYGvF KE/35+QPZymcIrbzLwLEKVsJB6mpkiDoVayKVp2yj/0c6HCOhLpOfSWvTIisP/mjanlD Nt7g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :message-id:date:subject:cc:to:from:dkim-signature:dkim-signature; bh=II6ZIwPuUDm1QQYI4VVjCMhVizc1ZeIOHaCA5ME/VuE=; b=TGEECXvgZKZBkbqd+3wI8eggPJhivLBjgdYBu2JfoKaDdm94PxGLRig+jdnJxDkb4a T48yf+9RiF+lJzfWkvt6Y300MIs1mBFlO1oYT2KaFD2Ydh/F3BwfA+5PPasZx89eG0mC fztumVIecE1SVP3qIRSkkCIlV600x7g5zI7Ar3y/NqB5BvQe0sByaP7z9qL2eIHsL6zR ChOQHhJ47Gx71NHE5yOo+5y3D/Pmcj7uyI8A9UiQYxDMMjPSvBExytEr/YLIMaegS4qY KzjX5pXm7OupDIId9CCIQkPbMpQ751VhF4Ae4/o2J/OdYbfQZ8owqx81us8CyuF65u4K kRJA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@cerno.tech header.s=fm3 header.b=gcOLuDgH; dkim=pass header.i=@messagingengine.com header.s=fm3 header.b=IF8P3CKs; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=cerno.tech Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id y9si14830337ilv.11.2021.07.20.06.53.44; Tue, 20 Jul 2021 06:53:55 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@cerno.tech header.s=fm3 header.b=gcOLuDgH; dkim=pass header.i=@messagingengine.com header.s=fm3 header.b=IF8P3CKs; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=cerno.tech Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S239221AbhGTNJj (ORCPT + 99 others); Tue, 20 Jul 2021 09:09:39 -0400 Received: from wnew3-smtp.messagingengine.com ([64.147.123.17]:50833 "EHLO wnew3-smtp.messagingengine.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S239022AbhGTNEz (ORCPT ); Tue, 20 Jul 2021 09:04:55 -0400 Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailnew.west.internal (Postfix) with ESMTP id D4A0C2B01187; Tue, 20 Jul 2021 09:45:31 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute1.internal (MEProxy); Tue, 20 Jul 2021 09:45:32 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cerno.tech; h= from:to:cc:subject:date:message-id:content-type:mime-version :content-transfer-encoding; s=fm3; bh=II6ZIwPuUDm1QQYI4VVjCMhViz c1ZeIOHaCA5ME/VuE=; b=gcOLuDgHYfhlXLonM7NgoN4W0fNt95JmWcnUbCpBLk unKumIG+yEWLJZAc5fvSYUyOR9fiB3vWBrcUt5Jx0p6NKE0OCNblqDfSVovl+wso tmqRFY0D+Ti6WYx300UuzkJTTN5+2TLpUyIRUNjLmwoZ755jrsJl/QFsr8CGqYSt D8q5lxjBK+pBgKrHGsmdV18SGP3wZwIcmlBorUQTPRNGo7gFnLW2wv6BRgDqb2Yc qvITlgljLI0B0GbWuKux0Mkk1NCobjQfiez+kFNRlOJXhM00BsVmdzF5NtTDa2mb HE3eeOa2C3oQ/fzJQNGlmlB/TogmOwGfLwuVviccIsyA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:message-id:mime-version:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=II6ZIw PuUDm1QQYI4VVjCMhVizc1ZeIOHaCA5ME/VuE=; b=IF8P3CKsEfjTO1dCrQet9p 78O5S2+HYB3YRKQ9BbLDIS715ddf/TruhvXrYetja+dtUZv1P9ojB1Sf67bFwf9u HwI3l/8ds9QDfJ3vWubdEwxprnqcQK1i9y1D5j7jyVKSAfoJJhCPDAUerkwX/RGf alF7EokG1+rbhGDmx14LfEw2WOaO90x4TPsXtl9fnWH/k0H+HyltcwAMoXa71EZv JnYdLklbrlQIfvCFRd+ojE2CBGdLseA/b5xLdqsr+HGs3Fk2oN+SLBmJQW3KdC7N tK+k158NHb2hDUTqLKC4RXJzzeOxFm4dAVp924ZaGE44548OI7JVzHnwllDJXFtw == X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvtddrfedvgdeijecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefhvffufffkofgtggfgsehtqhertdertdejnecuhfhrohhmpeforgigihhmvgcu tfhiphgrrhguuceomhgrgihimhgvsegtvghrnhhordhtvggthheqnecuggftrfgrthhtvg hrnhepteeikefgffekgeekledtheduteetjefgkeeuvefhhfetgedugfektdeugeffgfef necuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepmhgrgi himhgvsegtvghrnhhordhtvggthh X-ME-Proxy: Received: by mail.messagingengine.com (Postfix) with ESMTPA; Tue, 20 Jul 2021 09:45:28 -0400 (EDT) From: Maxime Ripard To: Robert Foss , Andrzej Hajda , Daniel Vetter , David Airlie , Sam Ravnborg , Maarten Lankhorst , Thomas Zimmermann , Maxime Ripard , Neil Armstrong , Jonas Karlman , Jernej Skrabec , Thierry Reding , Laurent Pinchart Cc: dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org Subject: [PATCH 00/10] drm/bridge: Make panel and bridge probe order consistent Date: Tue, 20 Jul 2021 15:45:15 +0200 Message-Id: <20210720134525.563936-1-maxime@cerno.tech> X-Mailer: git-send-email 2.31.1 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi,=0D =0D We've encountered an issue with the RaspberryPi DSI panel that prevented th= e=0D whole display driver from probing.=0D =0D The issue is described in detail in the commit 7213246a803f ("drm/vc4: dsi:= =0D Only register our component once a DSI device is attached"), but the basic = idea=0D is that since the panel is probed through i2c, there's no synchronization=0D between its probe and the registration of the MIPI-DSI host it's attached t= o.=0D =0D We initially moved the component framework registration to the MIPI-DSI Hos= t=0D attach hook to make sure we register our component only when we have a DSI= =0D device attached to our MIPI-DSI host, and then use lookup our DSI device in= our=0D bind hook.=0D =0D However, all the DSI bridges controlled through i2c are only registering th= eir=0D associated DSI device in their bridge attach hook, meaning with our change= =0D above, we never got that far, and therefore ended up in the same situation = than=0D the one we were trying to fix for panels.=0D =0D Since the RaspberryPi panel is the only driver in that situation, whereas i= t=0D seems like there's a consensus in bridge drivers, it makes more sense to tr= y to=0D mimic the bridge pattern in the panel driver.=0D =0D However, panels don't have an attach hook, and adding more panel hooks woul= d=0D lead to more path to maintain in each and every driver, while the general p= ush=0D is towards bridges. We also have to make sure that each and every DSI host = and=0D device driver behaves the same in order to have expectations to rely on.=0D =0D The solution I'm proposing is thus done in several steps:=0D =0D - We get rid of the initial patch to make sure we support the bridge case= ,=0D and not the odd-panel one.=0D =0D - Add a function that returns a bridge from a DT node, reducing the amoun= t of=0D churn in each and every driver and making it a real incentive to not ca= re=0D about panels in display drivers but only bridges.=0D =0D - Add an attach and detach hook into the panel operations, and make it ca= lled=0D automatically by the DRM panel bridge.=0D =0D - Convert the VC4 DSI host to this new bridge function, and the Raspberry= Pi=0D Panel to the new attach and detach hooks.=0D =0D If the general approach is agreed upon, other drivers will obviously be=0D converted to drm_of_get_next.=0D =0D Let me know what you think,=0D Maxime=0D =0D Maxime Ripard (10):=0D Revert "drm/vc4: dsi: Only register our component once a DSI device is=0D attached"=0D drm/bridge: Add a function to abstract away panels=0D drm/bridge: Add documentation sections=0D drm/bridge: Document the probe issue with MIPI-DSI bridges=0D drm/panel: Create attach and detach callbacks=0D drm/bridge: panel: Call attach and detach for the panel=0D drm/vc4: dsi: Switch to drm_of_get_next=0D drm/panel: raspberrypi-touchscreen: Prevent double-free=0D drm/panel: raspberrypi-touchscreen: Use the attach hook=0D drm/panel: raspberrypi-touchscreen: Remove MIPI-DSI driver=0D =0D Documentation/gpu/drm-kms-helpers.rst | 12 ++=0D drivers/gpu/drm/bridge/panel.c | 4 +=0D drivers/gpu/drm/drm_bridge.c | 134 ++++++++++++++-=0D drivers/gpu/drm/drm_of.c | 3 +=0D drivers/gpu/drm/drm_panel.c | 20 +++=0D .../drm/panel/panel-raspberrypi-touchscreen.c | 159 +++++++++---------=0D drivers/gpu/drm/vc4/vc4_drv.c | 2 +=0D drivers/gpu/drm/vc4/vc4_dsi.c | 53 +++---=0D include/drm/drm_bridge.h | 2 +=0D include/drm/drm_panel.h | 6 +=0D 10 files changed, 273 insertions(+), 122 deletions(-)=0D =0D -- =0D 2.31.1=0D =0D