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 Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 99F29C77B7C for ; Thu, 4 May 2023 08:38:51 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229845AbjEDIiu (ORCPT ); Thu, 4 May 2023 04:38:50 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:49176 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229772AbjEDIit (ORCPT ); Thu, 4 May 2023 04:38:49 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [IPv6:2604:1380:4641:c500::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id BE7B01722; Thu, 4 May 2023 01:38:48 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 5E2E76326B; Thu, 4 May 2023 08:38:48 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id AC04EC433D2; Thu, 4 May 2023 08:38:47 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1683189527; bh=lyHDvvruE+QpJiz2b8/hfSd8MdRly286qX04fvZa2mM=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=ueEtORMx7XS5bd+UDk3Hr/ohERrwMQUCuGtyanSCF/qNjohVAwU4el94X3HosnmfN ETP75+9gTknkcKlqcBro8PMcmkQI7ZzOBReJPYQADnyMQRLe/dBXro9plhtEFfRidH NyA0Y+AjLTD5OKqjaR+a9yqC0sa3/+ByJf/grmabaGxmiMBkrzfUD8UcI3yEeK3Xdz wS/ljmpfls87SrEw+JM6buDTQYapRU9QVBx1bafQxfv7JXiRrp8uxVPWti2GrNhRU6 4QJTIzdfnCejK4fqWTeTJdDAjl6yleCjTYdtyuzp5dONrJS2aN8hveC3VVMITijJ0g tNWkAGSCuPTZw== Received: from johan by xi.lan with local (Exim 4.94.2) (envelope-from ) id 1puUUJ-0005SO-05; Thu, 04 May 2023 10:38:55 +0200 Date: Thu, 4 May 2023 10:38:54 +0200 From: Johan Hovold To: Bjorn Andersson Cc: Vinod Koul , Kishon Vijay Abraham I , Bjorn Andersson , Konrad Dybcio , Rob Herring , Krzysztof Kozlowski , linux-arm-msm@vger.kernel.org, linux-phy@lists.infradead.org, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH 5/7] phy: qcom-qmp-combo: Introduce drm_bridge Message-ID: References: <20230425034010.3789376-1-quic_bjorande@quicinc.com> <20230425034010.3789376-6-quic_bjorande@quicinc.com> <20230504031354.GE870858@hu-bjorande-lv.qualcomm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20230504031354.GE870858@hu-bjorande-lv.qualcomm.com> Precedence: bulk List-ID: X-Mailing-List: linux-arm-msm@vger.kernel.org On Wed, May 03, 2023 at 08:13:54PM -0700, Bjorn Andersson wrote: > On Tue, May 02, 2023 at 02:05:53PM +0200, Johan Hovold wrote: > > On Mon, Apr 24, 2023 at 08:40:08PM -0700, Bjorn Andersson wrote: > > > The QMP combo PHY sits in an of_graph connected between the DisplayPort > > > controller and a USB Type-C connector (or possibly a redriver). > > > > > > The TCPM needs to be able to convey the HPD signal to the DisplayPort > > > controller, but no directly link is provided by DeviceTree so the signal > > > needs to "pass through" the QMP combo phy. > > > > > > Handle this by introducing a drm_bridge which upon initialization finds > > > the next bridge (i.e. the usb-c-connector) and chain this together. This > > > way HPD changes in the connector will propagate to the DisplayPort > > > driver. > > > > > > The connector bridge is resolved lazily, as the TCPM is expected to be > > > able to resolve the typec mux and switch at probe time, so the QMP combo > > > phy will probe before the TCPM. > > > > > > Signed-off-by: Bjorn Andersson > > > --- > > > drivers/phy/qualcomm/phy-qcom-qmp-combo.c | 36 +++++++++++++++++++++++ > > > 1 file changed, 36 insertions(+) > > > > > > diff --git a/drivers/phy/qualcomm/phy-qcom-qmp-combo.c b/drivers/phy/qualcomm/phy-qcom-qmp-combo.c > > > index 5d6d6ef3944b..84bc08002537 100644 > > > --- a/drivers/phy/qualcomm/phy-qcom-qmp-combo.c > > > +++ b/drivers/phy/qualcomm/phy-qcom-qmp-combo.c > > > @@ -3196,6 +3200,34 @@ static int qmp_combo_register_clocks(struct qmp_combo *qmp, struct device_node * > > > return devm_add_action_or_reset(qmp->dev, phy_clk_release_provider, dp_np); > > > } > > > > > > +static int qmp_combo_bridge_attach(struct drm_bridge *bridge, > > > + enum drm_bridge_attach_flags flags) > > > +{ > > > + struct qmp_combo *qmp = container_of(bridge, struct qmp_combo, bridge); > > > + struct drm_bridge *next_bridge; > > > + > > > + if (!(flags & DRM_BRIDGE_ATTACH_NO_CONNECTOR)) > > > + return -EINVAL; > > > + > > > + next_bridge = devm_drm_of_get_bridge(qmp->dev, qmp->dev->of_node, 0, 0); > > > + if (IS_ERR(next_bridge)) > > > + return dev_err_probe(qmp->dev, PTR_ERR(next_bridge), "failed to acquire drm_bridge\n"); > > > > Using dev_err_probe() in an attach callback looks wrong as these > > functions should not be returning -EPROBE_DEFER (and this is not a probe > > function). > > The problem is that this might return EPROBE_DEFER, and at least today > propagates out to returning EPROBE_DEFER from our DP controller's > bind(). Due to the known issue with the MSM driver panel lookup, or due to some more fundamental problem with the stack? At least in the former case, I don't think we should hide the fact that we have an unresolved issue with the MSM driver this way even if it means printing an extra error message until it has been resolved (cf. the panel lookup errors that we've intentionally kept in place). > This is not optimal, but unfortunately we have a two way dependency > across the of_graph, so we need to make one of the sides lazy... But this comments seems to suggest this is a bigger issue than the panel lookup. Could you describe the issue in some more detail (e.g. when would you see -EPROBE_DEFER here)? Johan