Received: by 2002:a05:6a10:5bc5:0:0:0:0 with SMTP id os5csp4214092pxb; Tue, 2 Nov 2021 06:10:15 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxMtnzADc8ZPIEscD/DzvEUCzBXp/0OvaZbW5XPEkIzC87BEBBOUzAFgn01R8/Z40gzFsYa X-Received: by 2002:a5e:cb0b:: with SMTP id p11mr25896513iom.41.1635858615478; Tue, 02 Nov 2021 06:10:15 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1635858615; cv=none; d=google.com; s=arc-20160816; b=08jag/ETFhn4y9I8w/CZRkupb0B1XTC45tiMc4LIF1+sGEkMl7B6R7SKQi253k2L42 BmIMiFm5FW/n5sUfdbz6HnxV0aSQy769znvSy6JeihstAzVEotgKomERp9mIt/v9XwJC NlhtZXXsV47MSqAbEkkxo4yMi3lpqK63NB7SyuNM3Pj1ufx88VExEHkNdmhC0kf1cekt wYKkCE/wWPYJseyyHP4PIGjsRbO8rKBIA0UZcQMT3sPoam/qotJy6QYKV7rBfcjf4JRU 396tUXYk5cFME8Z1kMBwBDeEXxFNYm5EO1LailXhwPzjre0KRLKn3MHZJIAp2Zb8gsqf l02Q== 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; bh=jVZO81ycGPPGjEXcIUGXDjCMXaBHPYk0q02LGdU7EoU=; b=GEqncYgNJ/z5WNy4R5wCuUI0ITa2OKOknoRyEmSCHEO5gaYR6EkE225WNYEDQVhIcl d5hjrSuWxHGokel20tED8MKnYkCElG87pS+weF1blGr6zKHP91VMXKC1gblfy8hTgPv1 /gdbX4bGXM0cpS186GsMVfApNRKuZEF8+mk2Fke7sjeA/7L9H68UPtpQZocj9JWl9Ur+ SBMM2Sno4ACjoid9H5BIQUOwIW3wDehLjFo0331mEIcVtCwf7WR+Pc5R8Y2fNo/CIGoc dUcoWUtqnekZSPZj9oU/wn7mlWOeStnjvq0CwTQQ9TkvzaCqXKkpzi05MKMXQ0UXhULB 1wpQ== ARC-Authentication-Results: i=1; mx.google.com; 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=fail (p=NONE sp=NONE dis=NONE) header.from=collabora.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id n12si28682482jaj.44.2021.11.02.06.10.02; Tue, 02 Nov 2021 06:10:15 -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; 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=fail (p=NONE sp=NONE dis=NONE) header.from=collabora.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231314AbhKBNK6 (ORCPT + 99 others); Tue, 2 Nov 2021 09:10:58 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:51440 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230170AbhKBNKv (ORCPT ); Tue, 2 Nov 2021 09:10:51 -0400 Received: from bhuna.collabora.co.uk (bhuna.collabora.co.uk [IPv6:2a00:1098:0:82:1000:25:2eeb:e3e3]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 7D871C061714 for ; Tue, 2 Nov 2021 06:08:16 -0700 (PDT) Received: from [127.0.0.1] (localhost [127.0.0.1]) (Authenticated sender: kholk11) with ESMTPSA id B42891F4490B From: AngeloGioacchino Del Regno To: a.hajda@samsung.com Cc: narmstrong@baylibre.com, robert.foss@linaro.org, Laurent.pinchart@ideasonboard.com, jonas@kwiboo.se, jernej.skrabec@gmail.com, airlied@linux.ie, daniel@ffwll.ch, dri-devel@lists.freedesktop.org, kernel@collabora.com, linux-kernel@vger.kernel.org, AngeloGioacchino Del Regno Subject: [PATCH] drm/bridge: parade-ps8640: Link device to ensure suspend/resume order Date: Tue, 2 Nov 2021 14:04:28 +0100 Message-Id: <20211102130428.444795-1-angelogioacchino.delregno@collabora.com> X-Mailer: git-send-email 2.33.1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Entering suspend while the display attached to this bridge is still on makes the resume sequence to resume the bridge first, display last: when this happens, we get a timeout while resuming the bridge, as its MCU will get stuck due to the display being unpowered. On the other hand, on mt8173-elm, closing the lid makes the display to get powered off first, bridge last, so at resume time the sequence is swapped (compared to the first example) and everything just works as expected. Add a stateless device link to the DRM device that this bridge belongs to, ensuring a correct resume sequence and solving the unability to correctly resume bridge operation in the first mentioned example. Signed-off-by: AngeloGioacchino Del Regno --- drivers/gpu/drm/bridge/parade-ps8640.c | 22 ++++++++++++++++++++-- 1 file changed, 20 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/bridge/parade-ps8640.c b/drivers/gpu/drm/bridge/parade-ps8640.c index 45100edd745b..191cc196c9d1 100644 --- a/drivers/gpu/drm/bridge/parade-ps8640.c +++ b/drivers/gpu/drm/bridge/parade-ps8640.c @@ -100,6 +100,7 @@ struct ps8640 { struct regulator_bulk_data supplies[2]; struct gpio_desc *gpio_reset; struct gpio_desc *gpio_powerdown; + struct device_link *link; bool powered; }; @@ -460,10 +461,23 @@ static int ps8640_bridge_attach(struct drm_bridge *bridge, goto err_aux_register; } + ps_bridge->link = device_link_add(bridge->dev->dev, dev, DL_FLAG_STATELESS); + if (!ps_bridge->link) { + dev_err(dev, "failed to create device link"); + ret = -EINVAL; + goto err_devlink; + } + /* Attach the panel-bridge to the dsi bridge */ - return drm_bridge_attach(bridge->encoder, ps_bridge->panel_bridge, + ret = drm_bridge_attach(bridge->encoder, ps_bridge->panel_bridge, &ps_bridge->bridge, flags); + if (ret) + goto err_bridge_attach; +err_bridge_attach: + device_link_del(ps_bridge->link); +err_devlink: + drm_dp_aux_unregister(&ps_bridge->aux); err_aux_register: mipi_dsi_detach(dsi); err_dsi_attach: @@ -473,7 +487,11 @@ static int ps8640_bridge_attach(struct drm_bridge *bridge, static void ps8640_bridge_detach(struct drm_bridge *bridge) { - drm_dp_aux_unregister(&bridge_to_ps8640(bridge)->aux); + struct ps8640 *ps_bridge = bridge_to_ps8640(bridge); + + drm_dp_aux_unregister(&ps_bridge->aux); + if (ps_bridge->link) + device_link_del(ps_bridge->link); } static struct edid *ps8640_bridge_get_edid(struct drm_bridge *bridge, -- 2.33.1