Received: by 2002:a6b:500f:0:0:0:0:0 with SMTP id e15csp6351263iob; Tue, 10 May 2022 16:48:47 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzOql4PKwKortIxyCfqrM0E9dJCWQ1Joh6E3s0iSiJ6vbD8Q2RVgwDNkzPOqcc5fibZXWub X-Received: by 2002:a17:902:ab96:b0:159:1ff:4ea0 with SMTP id f22-20020a170902ab9600b0015901ff4ea0mr23004806plr.60.1652226527182; Tue, 10 May 2022 16:48:47 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1652226527; cv=none; d=google.com; s=arc-20160816; b=k4HozzO/rwxhIWyCDV1xVuUeoMof0eZCiPge+/8PJSNHPOiHr/+sRMNWkClHzuNMjm Al9J0LR+Ntrnj0Mn3CuXIkRMAWJ3LqVuTUtSimSS+vNbd046UyyJY4cPR2Cpm0TtYcLf GuJUbVMxLRuPvLItkHbrsmkIHQZTE+kCxd830Ui6zCT0dERsey5u6RoaEnwOtExyT7qO 1rki/SQjdAoKi2uy/lHw4HldKxvIV005YE5eKcoDC7+wbTG9dp3tqZVcI+A6bK2E3P7w lIuT3V+tnoXgunzq9en7lof41/c9GnRAmQ16KA6aMNwTB5HTEimQg7DpQFwhW3FiTcE3 AkJw== 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 :references:in-reply-to:message-id:date:subject:cc:to:from :dkim-signature; bh=aenq/+payNfc0QfJK06n0457dQA2IsFpv+YO3oHnMIs=; b=G7Dpko95vWqqXijsOBOTtvDWXyYyAjheaEiZS85ejHTxoeBmQc/vAenZUchIG15/O1 THPMhKownqSz1xWRPgmctgKF2AZdJuMdwoDYOTpX7m3u64xdMJGBhJBu7mUJrh2B+F3G bY/mav/pR3cDoU79LtyCJofh6aIrJmZKa+ldqJgz4Jm64D4nK5gnZF6Iy4VdBoUt8AKf +gkwmv/LA0eBvOz5n/UKJwAdLK7dqfpYGKf028zBwZVbMHSG8KNntJcWgsG8LVwRkmX5 2cYz7wDlsqarwPaQrk+H+G9OL3A+3+VO/ea9dIjo7oh1g1ZH5TNDiaQ8vReaYQjXmaW9 1exQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@chromium.org header.s=google header.b=CsVaXK6R; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=chromium.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id s3-20020a632c03000000b003c642cc815csi854767pgs.15.2022.05.10.16.48.35; Tue, 10 May 2022 16:48:47 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@chromium.org header.s=google header.b=CsVaXK6R; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=chromium.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S236093AbiEJTaW (ORCPT + 99 others); Tue, 10 May 2022 15:30:22 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:46734 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233796AbiEJTaH (ORCPT ); Tue, 10 May 2022 15:30:07 -0400 Received: from mail-pg1-x534.google.com (mail-pg1-x534.google.com [IPv6:2607:f8b0:4864:20::534]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 711982A76AB for ; Tue, 10 May 2022 12:30:03 -0700 (PDT) Received: by mail-pg1-x534.google.com with SMTP id 7so15418492pga.12 for ; Tue, 10 May 2022 12:30:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=aenq/+payNfc0QfJK06n0457dQA2IsFpv+YO3oHnMIs=; b=CsVaXK6RqVBe6/OondZCpIqQ7YKFDn6kpSdzq7AGRLrpvTEGfziCDVpjEcn1dGwcxG odjvGogk7T1c8MDGI1PdHVpkNBpnOVPpOPHHqR6HCq0wqMfSHNnWHqHvuYz8j7jMzWft 24EJaIJLYYXB725FpyUMI280VvP5MT0WzMCyE= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=aenq/+payNfc0QfJK06n0457dQA2IsFpv+YO3oHnMIs=; b=xvFmYDeOI+6AyCITu05nuYkjITWPM4ODhRCDNDXxI2UuN/oeWvdnB/54Oqp17bo3A2 Eg2wvcyFOmEofmNWFUi0La3FKx33F1NnA9qnuhhxnPWHfGZ+u+k1OaeR3LezAWbDsOsK zD37ce21AKK5T+kDTDQQDotIBhz5X5DXebG/MKGXQiA+igKizVcJSM/PnsPGQ/KlgtCs g7S9dNcZSyOWdo7GMi5yke2sHeFkYEOoQMZMgLOzhjFTdcfvYNPnHR3fBGnU5pRhnTmm 2XSfXqKmX9VsX0qWq9OqHaNL3sGbQh4EuxfjOWkxX0p5ixwZDd/jYcuTE+4gsuVVvsMO uhrw== X-Gm-Message-State: AOAM533LIRJJZXBup+TG8OSQkFOYJE/CNuVMAoJaCtcRp4aflWb/uUEY teYJFFEMSZIInZWUSKr53g96ng== X-Received: by 2002:a63:e5d:0:b0:3aa:3c53:537e with SMTP id 29-20020a630e5d000000b003aa3c53537emr18041665pgo.622.1652211002972; Tue, 10 May 2022 12:30:02 -0700 (PDT) Received: from tictac2.mtv.corp.google.com ([2620:15c:202:201:6f08:624c:c762:d238]) by smtp.gmail.com with ESMTPSA id s43-20020a056a001c6b00b0050dc762819dsm10786989pfw.119.2022.05.10.12.30.02 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 10 May 2022 12:30:02 -0700 (PDT) From: Douglas Anderson To: dri-devel@lists.freedesktop.org Cc: Hsin-Yi Wang , Abhinav Kumar , Philip Chen , Sankeerth Billakanti , Robert Foss , freedreno@lists.freedesktop.org, Dmitry Baryshkov , linux-arm-msm@vger.kernel.org, Stephen Boyd , Douglas Anderson , Andrzej Hajda , Daniel Vetter , David Airlie , Jernej Skrabec , Jonas Karlman , Laurent Pinchart , Neil Armstrong , linux-kernel@vger.kernel.org Subject: [PATCH v3 4/4] drm/bridge: parade-ps8640: Handle DP AUX more properly Date: Tue, 10 May 2022 12:29:44 -0700 Message-Id: <20220510122726.v3.4.Ia6324ebc848cd40b4dbd3ad3289a7ffb5c197779@changeid> X-Mailer: git-send-email 2.36.0.550.gb090851708-goog In-Reply-To: <20220510192944.2408515-1-dianders@chromium.org> References: <20220510192944.2408515-1-dianders@chromium.org> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE, SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE,URIBL_BLOCKED autolearn=ham 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 While it works, for the most part, to assume that the panel has finished probing when devm_of_dp_aux_populate_ep_devices() returns, it's a bit fragile. This is talked about at length in commit a1e3667a9835 ("drm/bridge: ti-sn65dsi86: Promote the AUX channel to its own sub-dev"). When reviewing the ps8640 code, I managed to convince myself that it was OK not to worry about it there and that maybe it wasn't really _that_ fragile. However, it turns out that it really is. Simply hardcoding panel_edp_probe() to return -EPROBE_DEFER was enough to put the boot process into an infinite loop. I believe this manages to trip the same issues that we used to trip with the main MSM code where something about our actions trigger Linux to re-probe previously deferred devices right away and each time we try again we re-trigger Linux to re-probe. Let's fix this using the callback introduced in the patch ("drm/dp: Callbacks to make it easier for drivers to use DP AUX bus properly"). When using the new callback, we have to be a little careful. The probe_done() callback is no longer always called in the context of our probe routine. That means we can't rely on being able to return -EPROBE_DEFER from it. We re-jigger the order of things a bit to account for that. With this change, the device still boots (though obviously the panel doesn't come up) if I force panel-edp to always return -EPROBE_DEFER. If I fake it and make the panel probe exactly once it also works. Signed-off-by: Douglas Anderson --- Changes in v3: - Adapt to v3 changes in aux bus. - Use devm_drm_bridge_add() to simplify. Changes in v2: - Rewrote atop new method introduced by patch #1. drivers/gpu/drm/bridge/parade-ps8640.c | 74 ++++++++++++++++---------- 1 file changed, 46 insertions(+), 28 deletions(-) diff --git a/drivers/gpu/drm/bridge/parade-ps8640.c b/drivers/gpu/drm/bridge/parade-ps8640.c index e2467e58b5b7..ff4227f6d800 100644 --- a/drivers/gpu/drm/bridge/parade-ps8640.c +++ b/drivers/gpu/drm/bridge/parade-ps8640.c @@ -537,7 +537,7 @@ static const struct drm_bridge_funcs ps8640_bridge_funcs = { .pre_enable = ps8640_pre_enable, }; -static int ps8640_bridge_host_attach(struct device *dev, struct ps8640 *ps_bridge) +static int ps8640_bridge_get_dsi_resources(struct device *dev, struct ps8640 *ps_bridge) { struct device_node *in_ep, *dsi_node; struct mipi_dsi_device *dsi; @@ -576,13 +576,40 @@ static int ps8640_bridge_host_attach(struct device *dev, struct ps8640 *ps_bridg dsi->format = MIPI_DSI_FMT_RGB888; dsi->lanes = NUM_MIPI_LANES; - return devm_mipi_dsi_attach(dev, dsi); + return 0; +} + +static int ps8640_bridge_link_panel(struct drm_dp_aux *aux) +{ + struct ps8640 *ps_bridge = aux_to_ps8640(aux); + struct device *dev = aux->dev; + struct device_node *np = dev->of_node; + int ret; + + /* + * NOTE about returning -EPROBE_DEFER from this function: if we + * return an error (most relevant to -EPROBE_DEFER) it will only + * be passed out to ps8640_probe() if it called this directly (AKA the + * panel isn't under the "aux-bus" node). That should be fine because + * if the panel is under "aux-bus" it's guaranteed to have probed by + * the time this function has been called. + */ + + /* port@1 is ps8640 output port */ + ps_bridge->panel_bridge = devm_drm_of_get_bridge(dev, np, 1, 0); + if (IS_ERR(ps_bridge->panel_bridge)) + return PTR_ERR(ps_bridge->panel_bridge); + + ret = devm_drm_bridge_add(dev, &ps_bridge->bridge); + if (ret) + return ret; + + return devm_mipi_dsi_attach(dev, ps_bridge->dsi); } static int ps8640_probe(struct i2c_client *client) { struct device *dev = &client->dev; - struct device_node *np = dev->of_node; struct ps8640 *ps_bridge; int ret; u32 i; @@ -623,6 +650,14 @@ static int ps8640_probe(struct i2c_client *client) if (!ps8640_of_panel_on_aux_bus(&client->dev)) ps_bridge->bridge.ops = DRM_BRIDGE_OP_EDID; + /* + * Get MIPI DSI resources early. These can return -EPROBE_DEFER so + * we want to get them out of the way sooner. + */ + ret = ps8640_bridge_get_dsi_resources(&client->dev, ps_bridge); + if (ret) + return ret; + ps_bridge->page[PAGE0_DP_CNTL] = client; ps_bridge->regmap[PAGE0_DP_CNTL] = devm_regmap_init_i2c(client, ps8640_regmap_config); @@ -665,35 +700,19 @@ static int ps8640_probe(struct i2c_client *client) if (ret) return ret; - devm_of_dp_aux_populate_ep_devices(&ps_bridge->aux); + ret = devm_of_dp_aux_populate_bus(&ps_bridge->aux, ps8640_bridge_link_panel); - /* port@1 is ps8640 output port */ - ps_bridge->panel_bridge = devm_drm_of_get_bridge(dev, np, 1, 0); - if (IS_ERR(ps_bridge->panel_bridge)) - return PTR_ERR(ps_bridge->panel_bridge); - - drm_bridge_add(&ps_bridge->bridge); - - ret = ps8640_bridge_host_attach(dev, ps_bridge); - if (ret) - goto err_bridge_remove; - - return 0; + /* + * If devm_of_dp_aux_populate_bus() returns -ENODEV then it's up to + * usa to call ps8640_bridge_link_panel() directly. NOTE: in this case + * the function is allowed to -EPROBE_DEFER. + */ + if (ret == -ENODEV) + return ps8640_bridge_link_panel(&ps_bridge->aux); -err_bridge_remove: - drm_bridge_remove(&ps_bridge->bridge); return ret; } -static int ps8640_remove(struct i2c_client *client) -{ - struct ps8640 *ps_bridge = i2c_get_clientdata(client); - - drm_bridge_remove(&ps_bridge->bridge); - - return 0; -} - static const struct of_device_id ps8640_match[] = { { .compatible = "parade,ps8640" }, { } @@ -702,7 +721,6 @@ MODULE_DEVICE_TABLE(of, ps8640_match); static struct i2c_driver ps8640_driver = { .probe_new = ps8640_probe, - .remove = ps8640_remove, .driver = { .name = "ps8640", .of_match_table = ps8640_match, -- 2.36.0.550.gb090851708-goog