Received: by 2002:a05:6a10:413:0:0:0:0 with SMTP id 19csp972268pxp; Wed, 16 Mar 2022 23:05:16 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyPPdG+NPZu7bAtwHy/6efKl8U2UPiTFFH7nILMR4ke653nbRCH4rVQzCeRd0Dtd0kJ3hKO X-Received: by 2002:a17:902:a3cb:b0:151:e52e:fa0c with SMTP id q11-20020a170902a3cb00b00151e52efa0cmr2992127plb.70.1647497115883; Wed, 16 Mar 2022 23:05:15 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1647497115; cv=none; d=google.com; s=arc-20160816; b=OwCI+868qLZr/2gmwPeCATYbzp8K+lRttLWAnQ3nhNWB9YTWW9LdRcax10943zm9Tt b/luB6okh8Atl2ya5iIlXVjVyMJPquUjpnuF+eOtXtjd17E++hvLS4g9VdPK/ZHghDCg HZDxMElQPR+7qTOsqat+N+lch7jZMlOqSvOdLZVktWvy8xN9K3k7CZ+ypkhrGlp65QYM 0joyFQs9kI8oW7/PpwwPWZ2FdGPH0dzz7bIBGJp431xv+bXpVn4dGRicv2J6w/x6c4nh 4jOdvyuDet9SnsFp/t1u2+3eSoQwBTw4CujBdyLTFKtH5GLBUS37AOd4aEM8BkpebCue geYw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:user-agent:message-id:date:to:cc:from:subject :references:in-reply-to:content-transfer-encoding:mime-version :dkim-signature; bh=HxDkvOLJ/uGRFjZV8HhTFGqWnCWS+pnCkdNM+njRrHs=; b=vyY+y54x6Z2mNM/g62nc/KfuGl2t0f+w1vwOvTC5JNkMMIRTXLAN8Cj5caBQHq8XVw HOzfdel6Vbr2V6MhU6d3ieqMFFLW3itMJTFPevg1R6c8dfsLu7gPrFZz6zMqYY3etw5u bUi0kPr8HmT9bh875XMKgYCVc1gEUkTmRpl7F6BEiSYG3zTlCKZ7+OHmx70zCJKxiIvE 2udyjReln6QIcFJ0I5yuR7xwvVCyvF0KWqVf3WHxVPBrcsmQGf3GhE1JMdUcxzGOg7Lr gkSrHIQiD1l22hPd5kHngXPOd7kSiwLUxbsg6jSXXbExbC9gNsPV9eWMvsN4EgvtY9wE tcfw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass (test mode) header.i=@ideasonboard.com header.s=mail header.b=wFX2XoKN; spf=softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from lindbergh.monkeyblade.net (lindbergh.monkeyblade.net. [23.128.96.19]) by mx.google.com with ESMTPS id mm20-20020a17090b359400b001c1171b611fsi6240118pjb.22.2022.03.16.23.05.11 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 16 Mar 2022 23:05:15 -0700 (PDT) Received-SPF: softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) client-ip=23.128.96.19; Authentication-Results: mx.google.com; dkim=pass (test mode) header.i=@ideasonboard.com header.s=mail header.b=wFX2XoKN; spf=softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id B7B2CB91BE; Wed, 16 Mar 2022 22:10:03 -0700 (PDT) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S244154AbiCPXZa (ORCPT + 99 others); Wed, 16 Mar 2022 19:25:30 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:60884 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230385AbiCPXZ3 (ORCPT ); Wed, 16 Mar 2022 19:25:29 -0400 Received: from perceval.ideasonboard.com (perceval.ideasonboard.com [IPv6:2001:4b98:dc2:55:216:3eff:fef7:d647]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 895D6EA8; Wed, 16 Mar 2022 16:24:13 -0700 (PDT) Received: from pendragon.ideasonboard.com (cpc89244-aztw30-2-0-cust3082.18-1.cable.virginm.net [86.31.172.11]) by perceval.ideasonboard.com (Postfix) with ESMTPSA id C6BED493; Thu, 17 Mar 2022 00:24:10 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ideasonboard.com; s=mail; t=1647473050; bh=FewMdmi8qEg2S9b7MWGLnLAfszTXPWwFEMPvKBys6OM=; h=In-Reply-To:References:Subject:From:Cc:To:Date:From; b=wFX2XoKNsVfKJ9PnzNU5gr5EEIx/VnqBXfatkHwxQUWIk0vQs39KntBZbIIEcT+Fy ileRxcJbLsynYWYtRRa75qONDrxoKggzSm3Fclt7HWgVSRRcqkaxsmWEkTrwy68B1A EmF7rV00/epJR/t7+umRyqSDwv34FFjU8CoMQzcw= Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable In-Reply-To: References: <20220310152227.2122960-1-kieran.bingham+renesas@ideasonboard.com> <20220310152227.2122960-3-kieran.bingham+renesas@ideasonboard.com> Subject: Re: [PATCH v3 2/3] drm/bridge: ti-sn65dsi86: Implement bridge connector operations From: Kieran Bingham Cc: dri-devel , Linux-Renesas , Sam Ravnborg , LKML , Andrzej Hajda , Neil Armstrong , Robert Foss , Laurent Pinchart , Jonas Karlman , Jernej Skrabec , David Airlie , Daniel Vetter , Laurent Pinchart To: Doug Anderson Date: Wed, 16 Mar 2022 23:24:08 +0000 Message-ID: <164747304840.11309.8075169187883378445@Monstersaurus> User-Agent: alot/0.10 X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,RDNS_NONE,SPF_HELO_NONE,T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Doug, Quoting Doug Anderson (2022-03-10 23:10:20) > Hi, >=20 > On Thu, Mar 10, 2022 at 7:22 AM Kieran Bingham > wrote: > > > > From: Laurent Pinchart > > > > Implement the bridge connector-related .get_edid() operation, and report > > the related bridge capabilities and type. > > > > Signed-off-by: Laurent Pinchart > > Signed-off-by: Kieran Bingham > > --- > > Changes since v1: > > > > - The connector .get_modes() operation doesn't rely on EDID anymore, > > __ti_sn_bridge_get_edid() and ti_sn_bridge_get_edid() got merged > > together > > - Fix on top of Sam Ravnborg's DRM_BRIDGE_STATE_OPS > > > > Changes since v2: [Kieran] > > - Only support EDID on DRM_MODE_CONNECTOR_DisplayPort modes. > > > > drivers/gpu/drm/bridge/ti-sn65dsi86.c | 17 +++++++++++++++++ > > 1 file changed, 17 insertions(+) > > > > diff --git a/drivers/gpu/drm/bridge/ti-sn65dsi86.c b/drivers/gpu/drm/br= idge/ti-sn65dsi86.c > > index 93b54fcba8ba..d581c820e5d8 100644 > > --- a/drivers/gpu/drm/bridge/ti-sn65dsi86.c > > +++ b/drivers/gpu/drm/bridge/ti-sn65dsi86.c > > @@ -1135,10 +1135,24 @@ static void ti_sn_bridge_atomic_post_disable(st= ruct drm_bridge *bridge, > > pm_runtime_put_sync(pdata->dev); > > } > > > > +static struct edid *ti_sn_bridge_get_edid(struct drm_bridge *bridge, > > + struct drm_connector *connect= or) > > +{ > > + struct ti_sn65dsi86 *pdata =3D bridge_to_ti_sn65dsi86(bridge); > > + struct edid *edid; > > + > > + pm_runtime_get_sync(pdata->dev); > > + edid =3D drm_get_edid(connector, &pdata->aux.ddc); > > + pm_runtime_put_autosuspend(pdata->dev); >=20 > I'm 99% sure that the pm_runtime calls here are not needed and can be > removed.. The AUX transfer function handles the pm_runtime_get_sync() > and it also does the "put" with autosuspend so that the whole EDID can > be read without constantly powering the bridge up and down again. Yes, digging through I agree - It does look like this may be the case. ti_sn_aux_transfer() certainly looks like it handles the pm_runtime_ calls, and drm_get_edid() looks like it goes through there from the core using the standard i2c interface, with nothing else expected to touch the hw between. So that more or less simplifies this function to just=20 return drm_get_edid(connector, &pdata->aux.ddc); Thanks -- Kieran