From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from perceval.ideasonboard.com (perceval.ideasonboard.com [213.167.242.64]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id BCDB84C92; Thu, 11 Jun 2026 00:03:28 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=213.167.242.64 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1781136210; cv=none; b=BCZuZOrJVu0quO4JfwMEETMgHlCnuwHBtlTnQgw8QRu7U0ZStzh00oOYQsMcsZZlWwpEBR7eUxE/shkLUPjNMmuDgsM9FhklahjpT2vPSQobRxO4USBj/tATMA5t3khcnyBcthnCvSCc/mfO25ylD10d6mNF5YfC4kgn8MM/4EM= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1781136210; c=relaxed/simple; bh=7Lc1rx8Jp41JTvrcWNEo7iJ/+E/l8wCtqHTTiQ1kiKc=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=rRYNZYH17EvFGU35UJxpegyoCZUIxRngDqX46oWfQwhBKruZxLhDw7aIw4ppb9qBCCrAFPJ0oWGD2Yrv3mdltFqt8ursM18SEqMrjCCoefbh2eU8Pxp8nhgy+YZCgIGk6bJ47XONpUilB0vbfN1+KiQPhJ4gR+JoXPJTj0d/+QY= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=ideasonboard.com; spf=pass smtp.mailfrom=ideasonboard.com; dkim=pass (1024-bit key) header.d=ideasonboard.com header.i=@ideasonboard.com header.b=KkynWMvH; arc=none smtp.client-ip=213.167.242.64 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=ideasonboard.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=ideasonboard.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=ideasonboard.com header.i=@ideasonboard.com header.b="KkynWMvH" Received: from killaraus.ideasonboard.com (2001-14ba-70f3-e800--a06.rev.dnainternet.fi [IPv6:2001:14ba:70f3:e800::a06]) by perceval.ideasonboard.com (Postfix) with ESMTPSA id 80DE52D9; Thu, 11 Jun 2026 02:02:56 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ideasonboard.com; s=mail; t=1781136176; bh=7Lc1rx8Jp41JTvrcWNEo7iJ/+E/l8wCtqHTTiQ1kiKc=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=KkynWMvH4/GKiABKartnvdELDg8NTpkhQD92fWte+U+KU7Tlt/JUY4Yc+8KJ7k0qG cBLvV61QlTfXBUChPHMJhNSVPSBT4Aqt+gdcmkMEXhhJiagpstoGWC9nBuu5t3pauW 01H1kUOWt0IQOTdUvUA4AEbjtX6QtanSzrHSPBvY= Date: Thu, 11 Jun 2026 03:03:24 +0300 From: Laurent Pinchart To: Tomi Valkeinen Cc: Geert Uytterhoeven , Michael Turquette , Stephen Boyd , Andrzej Hajda , Neil Armstrong , Robert Foss , Jonas Karlman , Jernej Skrabec , Maarten Lankhorst , Maxime Ripard , Thomas Zimmermann , David Airlie , Simona Vetter , Rob Herring , Krzysztof Kozlowski , Conor Dooley , Magnus Damm , Marek Vasut , Kieran Bingham , Philipp Zabel , linux-renesas-soc@vger.kernel.org, linux-clk@vger.kernel.org, linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org, devicetree@vger.kernel.org Subject: Re: [PATCH v3 4/7] drm/rcar-du: dsi: Support DSC in the pipeline Message-ID: <20260611000324.GH1632628@killaraus.ideasonboard.com> References: <20260515-rcar-du-dsc-v3-0-164157820498@ideasonboard.com> <20260515-rcar-du-dsc-v3-4-164157820498@ideasonboard.com> Precedence: bulk X-Mailing-List: devicetree@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20260515-rcar-du-dsc-v3-4-164157820498@ideasonboard.com> Hi Tomi, Thank you for the patch. On Fri, May 15, 2026 at 12:09:29PM +0300, Tomi Valkeinen wrote: > Enabling DSI clocks on rcar-du needs some tricks as the DU dot clock is > provided by the DSI. Thus, we call rcar_mipi_dsi_pclk_enable() from the > crtc, when enabling the crtc. > > With DSC (added in upcoming patch) in the pipeline, between the DU and > the DSI, the above call path is broken as the crtc tries to call > rcar_mipi_dsi_pclk_enable() on the DSC. > > Adjust the rcar_mipi_dsi_pclk_enable() so that it detects the DSC, and > in that case gets the next bridge from the DSC, which is the DSI. > > Signed-off-by: Tomi Valkeinen > --- > drivers/gpu/drm/renesas/rcar-du/rcar_mipi_dsi.c | 36 +++++++++++++++++++++++-- > 1 file changed, 34 insertions(+), 2 deletions(-) > > diff --git a/drivers/gpu/drm/renesas/rcar-du/rcar_mipi_dsi.c b/drivers/gpu/drm/renesas/rcar-du/rcar_mipi_dsi.c > index 4ef2e3c129ed..085e229bcb0b 100644 > --- a/drivers/gpu/drm/renesas/rcar-du/rcar_mipi_dsi.c > +++ b/drivers/gpu/drm/renesas/rcar-du/rcar_mipi_dsi.c > @@ -88,6 +88,8 @@ struct dsi_setup_info { > const struct dsi_clk_config *clkset; > }; > > +static const struct drm_bridge_funcs rcar_mipi_dsi_bridge_ops; > + > static inline struct rcar_mipi_dsi * > bridge_to_rcar_mipi_dsi(struct drm_bridge *bridge) > { > @@ -844,15 +846,39 @@ static void rcar_mipi_dsi_atomic_disable(struct drm_bridge *bridge, > rcar_mipi_dsi_stop_video(dsi); > } > > +/* > + * We need to skip the DSC bridge when we have DSC in between the DU and > + * the DSI. We detect the DSI bridge via bridge->funcs, and assume the > + * next_bridge is the DSI bridge. If this is not the case, the DT data > + * is wrong (so it shouldn't really happen). > + */ > +static struct drm_bridge * > +rcar_mipi_dsi_resolve_bridge(struct drm_bridge *bridge) > +{ > + if (bridge->funcs != &rcar_mipi_dsi_bridge_ops) > + bridge = bridge->next_bridge; > + > + if (!bridge || bridge->funcs != &rcar_mipi_dsi_bridge_ops) > + return NULL; > + > + return bridge; > +} Hmmmm... It's quite a bit of a hack. It would be nicer to do this in rcar_du_crtc.c instead, where we cache the dsi bridge pointer. The question is how to then identify the right bridge, as we won't have access to rcar_mipi_dsi_bridge_ops. Should this driver set the bridge type field to DRM_MODE_CONNECTOR_DSI ? > + > void rcar_mipi_dsi_pclk_enable(struct drm_bridge *bridge, > struct drm_atomic_state *state) > { > - struct rcar_mipi_dsi *dsi = bridge_to_rcar_mipi_dsi(bridge); > const struct drm_display_mode *mode; > struct drm_connector *connector; > + struct rcar_mipi_dsi *dsi; > struct drm_crtc *crtc; > int ret; > > + bridge = rcar_mipi_dsi_resolve_bridge(bridge); > + if (WARN_ON(!bridge)) > + return; > + > + dsi = bridge_to_rcar_mipi_dsi(bridge); > + > connector = drm_atomic_get_new_connector_for_encoder(state, > bridge->encoder); > crtc = drm_atomic_get_new_connector_state(state, connector)->crtc; > @@ -885,7 +911,13 @@ EXPORT_SYMBOL_GPL(rcar_mipi_dsi_pclk_enable); > > void rcar_mipi_dsi_pclk_disable(struct drm_bridge *bridge) > { > - struct rcar_mipi_dsi *dsi = bridge_to_rcar_mipi_dsi(bridge); > + struct rcar_mipi_dsi *dsi; > + > + bridge = rcar_mipi_dsi_resolve_bridge(bridge); > + if (WARN_ON(!bridge)) > + return; > + > + dsi = bridge_to_rcar_mipi_dsi(bridge); > > rcar_mipi_dsi_shutdown(dsi); > rcar_mipi_dsi_clk_disable(dsi); > -- Regards, Laurent Pinchart