From patchwork Tue Mar 28 17:07:51 2023 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Jagan Teki X-Patchwork-Id: 13191375 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 gabe.freedesktop.org (gabe.freedesktop.org [131.252.210.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 47986C76196 for ; Tue, 28 Mar 2023 17:08:17 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 7892810E955; Tue, 28 Mar 2023 17:08:16 +0000 (UTC) Received: from mail-pj1-x102a.google.com (mail-pj1-x102a.google.com [IPv6:2607:f8b0:4864:20::102a]) by gabe.freedesktop.org (Postfix) with ESMTPS id BA5BC10E955 for ; Tue, 28 Mar 2023 17:08:14 +0000 (UTC) Received: by mail-pj1-x102a.google.com with SMTP id l7so11495320pjg.5 for ; Tue, 28 Mar 2023 10:08:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amarulasolutions.com; s=google; t=1680023294; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:from:to:cc:subject:date:message-id:reply-to; bh=O72nQMvXwuS9p7u9XEXsCt0AwfhA6j8fJBtuOxggIi4=; b=lL/wtX/BK28lAspoV0bcnfhFo9YyMSJImZLu3fcnopLu2UWxHZ6iaIay4NK8GmQtQc p4czGWsZ7rXIrsUY9Ow1ehQYM2QWj5NTyJcz4CWcw4a/COkomue1zLWddbJjyEIdERdF JwlVFZEDwXX/0oyxpFeHSJ+fFHxjZEl1qMSzQ= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1680023294; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=O72nQMvXwuS9p7u9XEXsCt0AwfhA6j8fJBtuOxggIi4=; b=PYb9MZXkOzkoqZpyDveZLHHos3UK+p/4zl8dZIa/PEs0FmAtRJT6S2RPehbNBwKMEp xrHqV1gh0/br7dWyIKrAIfidtvQNd1Ot1GtoEWUfnzSVn8BW0YmBdt1SxJqlzHOQm9HB CF36Jl/suiYVJRj3fZ6UmiyQ4uuoet/pwtjp4BfoHMysVJrolDfaktxxJDsGqk2rv995 Mg24dd9AieSQjGGg5qym5nThmbikQ6DAfxJcJf3N6zT/uNoAtBBHnwV/zSyoYz6vvVqy 99gEzAKm3rIQRPIwJzMTEvEaFd8+rsahmnhgoALlkdo8LB9F6cKZqT0tLcSxOjHKQZzG OQZQ== X-Gm-Message-State: AAQBX9e3Bu3UJ7woMfAmCz5qZ0ZxpbCpREUg9c1b0VTuDOU3EsiOOSgJ TuzAEUW8U2x7a1PJH5pWf64SFw== X-Google-Smtp-Source: AKy350YuhsqXQq7A3viG2CGEkmLiPHxshG76SZpUwN8GsFu3QZkTvWXeB0lUZfg1tWpyxhC1IzO3zA== X-Received: by 2002:a17:902:d4c3:b0:19f:36ae:c29f with SMTP id o3-20020a170902d4c300b0019f36aec29fmr21442520plg.46.1680023294314; Tue, 28 Mar 2023 10:08:14 -0700 (PDT) Received: from localhost.localdomain ([2405:201:c00a:a047:2fbc:aff5:d52a:cc2c]) by smtp.gmail.com with ESMTPSA id y17-20020a170902b49100b0019f114570b0sm20470349plr.152.2023.03.28.10.08.10 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 28 Mar 2023 10:08:13 -0700 (PDT) From: Jagan Teki To: Dave Stevenson , Maarten Lankhorst , Thomas Zimmermann , David Airlie , Daniel Vetter , Andrzej Hajda , Neil Armstrong Subject: [PATCH v2 1/2] drm/bridge: Fix improper bridge init order with pre_enable_prev_first Date: Tue, 28 Mar 2023 22:37:51 +0530 Message-Id: <20230328170752.1102347-1-jagan@amarulasolutions.com> X-Mailer: git-send-email 2.25.1 MIME-Version: 1.0 X-BeenThere: dri-devel@lists.freedesktop.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Direct Rendering Infrastructure - Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Marek Vasut , linux-amarula , Jagan Teki , dri-devel@lists.freedesktop.org Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" For a given bridge pipeline if any bridge sets pre_enable_prev_first flag then the pre_enable for the previous bridge will be called before pre_enable of this bridge and opposite is done for post_disable. These are the potential bridge flags to alter bridge init order in order to satisfy the MIPI DSI host and downstream panel or bridge to function. However the existing pre_enable_prev_first logic with associated bridge ordering has broken for both pre_enable and post_disable calls. [pre_enable] The altered bridge ordering has failed if two consecutive bridges on a given pipeline enables the pre_enable_prev_first flag. Example: - Panel - Bridge 1 - Bridge 2 pre_enable_prev_first - Bridge 3 - Bridge 4 pre_enable_prev_first - Bridge 5 pre_enable_prev_first - Bridge 6 - Encoder In this example, Bridge 4 and Bridge 5 have pre_enable_prev_first. The logic looks for a bridge which enabled pre_enable_prev_first flag on each iteration and assigned the previou bridge to limit pointer if the bridge doesn't enable pre_enable_prev_first flags. If control found Bridge 2 is pre_enable_prev_first then the iteration looks for Bridge 3 and found it is not pre_enable_prev_first and assigns it's previous Bridge 4 to limit pointer and calls pre_enable of Bridge 3 and Bridge 2 and assign iter pointer with limit which is Bridge 4. Here is the actual problem, for the next iteration control look for Bridge 5 instead of Bridge 4 has iter pointer in previous iteration moved to Bridge 4 so this iteration skips the Bridge 4. The iteration found Bridge 6 doesn't pre_enable_prev_first flags so the limit assigned to Encoder. From next iteration Encoder skips as it is the last bridge for reverse order pipeline. So, the resulting pre_enable bridge order would be, - Panel, Bridge 1, Bridge 3, Bridge 2, Bridge 6, Bridge 5. This patch fixes this by assigning limit to next pointer instead of previous bridge since the iteration always looks for bridge that does NOT request prev so assigning next makes sure the last bridge on a given iteration what exactly the limit bridge is. So, the resulting pre_enable bridge order with fix would be, - Panel, Bridge 1, Bridge 3, Bridge 2, Bridge 6, Bridge 5, Bridge 4, Encoder. [post_disable] The altered bridge ordering has failed if two consecutive bridges on a given pipeline enables the pre_enable_prev_first flag. Example: - Panel - Bridge 1 - Bridge 2 pre_enable_prev_first - Bridge 3 - Bridge 4 pre_enable_prev_first - Bridge 5 pre_enable_prev_first - Bridge 6 - Encoder In this example Bridge 5 and Bridge 4 have pre_enable_prev_first. The logic looks for a bridge which enabled pre_enable_prev_first flags on each iteration and assigned the previou bridge to next and next to limit pointer if the bridge does enable pre_enable_prev_first flag. If control starts from Bridge 6 then it found next Bridge 5 is pre_enable_prev_first and immediately the next assigned to previous Bridge 6 and limit assignments to next Bridge 6 and call post_enable of Bridge 6 even though the next consecutive Bridge 5 is enabled with pre_enable_prev_first. This clearly misses the logic to find the state of next conducive bridge as everytime the next and limit assigns previous bridge if given bridge enabled pre_enable_prev_first. So, the resulting post_disable bridge order would be, - Encoder, Bridge 6, Bridge 5, Bridge 4, Bridge 3, Bridge 2, Bridge 1, Panel. This patch fixes this by assigning next with previou bridge only if the bridge doesn't enable pre_enable_prev_first flag and the next further assign it to limit. This way we can find the bridge that NOT requested prev to disable last. So, the resulting pre_enable bridge order with fix would be, - Encoder, Bridge 4, Bridge 5, Bridge 6, Bridge 2, Bridge 3, Bridge 1, Panel. Validated the bridge init ordering by incorporating dummy bridges in the sun6i-mipi-dsi pipeline Fixes: 4fb912e5e190 ("drm/bridge: Introduce pre_enable_prev_first to alter bridge init order") Signed-off-by: Jagan Teki Reviewed-by: Dave Stevenson Tested-by: Michael Trimarchi --- Changes for v2: - add missing dri-devel in CC drivers/gpu/drm/drm_bridge.c | 10 ++++++++-- 1 file changed, 8 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/drm_bridge.c b/drivers/gpu/drm/drm_bridge.c index c3d69af02e79..052a8e6c9961 100644 --- a/drivers/gpu/drm/drm_bridge.c +++ b/drivers/gpu/drm/drm_bridge.c @@ -684,11 +684,17 @@ void drm_atomic_bridge_chain_post_disable(struct drm_bridge *bridge, */ list_for_each_entry_from(next, &encoder->bridge_chain, chain_node) { - if (next->pre_enable_prev_first) { + if (!next->pre_enable_prev_first) { next = list_prev_entry(next, chain_node); limit = next; break; } + + if (list_is_last(&next->chain_node, + &encoder->bridge_chain)) { + limit = next; + break; + } } /* Call these bridges in reverse order */ @@ -771,7 +777,7 @@ void drm_atomic_bridge_chain_pre_enable(struct drm_bridge *bridge, /* Found first bridge that does NOT * request prev to be enabled first */ - limit = list_prev_entry(next, chain_node); + limit = next; break; } } From patchwork Tue Mar 28 17:07:52 2023 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: Jagan Teki X-Patchwork-Id: 13191376 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 gabe.freedesktop.org (gabe.freedesktop.org [131.252.210.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id D0EDFC6FD18 for ; Tue, 28 Mar 2023 17:08:21 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 138A110E95C; Tue, 28 Mar 2023 17:08:21 +0000 (UTC) Received: from mail-pj1-x102a.google.com (mail-pj1-x102a.google.com [IPv6:2607:f8b0:4864:20::102a]) by gabe.freedesktop.org (Postfix) with ESMTPS id 3910A10E95C for ; Tue, 28 Mar 2023 17:08:19 +0000 (UTC) Received: by mail-pj1-x102a.google.com with SMTP id l7so11495552pjg.5 for ; Tue, 28 Mar 2023 10:08:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amarulasolutions.com; s=google; t=1680023299; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=qiCO4IDfxsC8fotKJWg3fnLWcorJmHZQyMnMP9mcruw=; b=h9ybu4KVjh/juEJlRxHmiHn/Cc+93jxZgGxemtc17HwTS4Q/kAsXg6Vel6VMMIYwuP 2zIHDaR6NcTffhxS9rS3BO5lmX01w43wevn7nM1LAItduGF8msRsu4wbLpNkdK5V/vOj 7OAZRJAAlLQuhQQxcRC10MrtjRg+Hvh6TSnIc= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1680023299; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=qiCO4IDfxsC8fotKJWg3fnLWcorJmHZQyMnMP9mcruw=; b=s6da+xllyPrCxiJNJtt9yg6zgvPxhLn7oEQ19DIhFrxSytinmwvpQTacFaCBop6SYP 8qdXOy9srIYCZ5L6BoujJrq9GAp77K2Go/j5ZmoN18/wqLmnb8flAT/2GfwjeGJUZsC/ ahLjdPqS9XNiADaVW50DXgNfy6ANK5JrONA4UpUccvOh3nEaSDgyoOwJPYpXTEbuKmg3 +nI2OYypgzUgbThH/Xm2z6OIug/nJgggCBmhAVArTuaU+T2CwQSO53njTQSyMGaTy/RO ebfVVyNRZMV4JdffmzDiLueH0ulL//14Pba3V4O7KfAWmRTJD+Yl4iCiMBPi2LxjhJh4 VNpg== X-Gm-Message-State: AAQBX9cbYWXCtLXY3U+L5cj0NYMCovnHt6D+Q68k8kCsGB3bcOkoF9qm BljYWtdgVQLgBWkgvQJZP/zaDQ== X-Google-Smtp-Source: AKy350b5+a9upWECjeS/U86vk/Q0eBkVFnSShMcqH0gORCIQMxGjyeyCJHAa+iSoNFipG9syD0Xupg== X-Received: by 2002:a17:902:d506:b0:1a1:b172:5428 with SMTP id b6-20020a170902d50600b001a1b1725428mr20545489plg.18.1680023298915; Tue, 28 Mar 2023 10:08:18 -0700 (PDT) Received: from localhost.localdomain ([2405:201:c00a:a047:2fbc:aff5:d52a:cc2c]) by smtp.gmail.com with ESMTPSA id y17-20020a170902b49100b0019f114570b0sm20470349plr.152.2023.03.28.10.08.14 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 28 Mar 2023 10:08:18 -0700 (PDT) From: Jagan Teki To: Dave Stevenson , Maarten Lankhorst , Thomas Zimmermann , David Airlie , Daniel Vetter , Andrzej Hajda , Neil Armstrong Subject: [PATCH v2 2/2] drm/bridge: Document bridge init order with pre_enable_prev_first Date: Tue, 28 Mar 2023 22:37:52 +0530 Message-Id: <20230328170752.1102347-2-jagan@amarulasolutions.com> X-Mailer: git-send-email 2.25.1 In-Reply-To: <20230328170752.1102347-1-jagan@amarulasolutions.com> References: <20230328170752.1102347-1-jagan@amarulasolutions.com> MIME-Version: 1.0 X-BeenThere: dri-devel@lists.freedesktop.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Direct Rendering Infrastructure - Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Marek Vasut , linux-amarula , Jagan Teki , dri-devel@lists.freedesktop.org Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" In order to satisfy the MIPI DSI initialization sequence the bridge init order has been altered with the help of pre_enable_prev_first in pre_enable and post_disable bridge operations. Document the affected bridge init order with an example on the bridge operations helpers. Signed-off-by: Jagan Teki Reviewed-by: Dave Stevenson --- Changes for v2: - add missing dri-devel in CC - prefix @ for bridge helper names drivers/gpu/drm/drm_bridge.c | 14 ++++++++++++++ 1 file changed, 14 insertions(+) diff --git a/drivers/gpu/drm/drm_bridge.c b/drivers/gpu/drm/drm_bridge.c index 052a8e6c9961..caf0f341e524 100644 --- a/drivers/gpu/drm/drm_bridge.c +++ b/drivers/gpu/drm/drm_bridge.c @@ -654,6 +654,13 @@ static void drm_atomic_bridge_call_post_disable(struct drm_bridge *bridge, * bridge will be called before the previous one to reverse the @pre_enable * calling direction. * + * Example: + * Bridge A ---> Bridge B ---> Bridge C ---> Bridge D ---> Bridge E + * + * With pre_enable_prev_first flag enable in Bridge B, D, E then the resulting + * @post_disable order would be, + * Bridge B, Bridge A, Bridge E, Bridge D, Bridge C. + * * Note: the bridge passed should be the one closest to the encoder */ void drm_atomic_bridge_chain_post_disable(struct drm_bridge *bridge, @@ -750,6 +757,13 @@ static void drm_atomic_bridge_call_pre_enable(struct drm_bridge *bridge, * If a bridge sets @pre_enable_prev_first, then the pre_enable for the * prev bridge will be called before pre_enable of this bridge. * + * Example: + * Bridge A ---> Bridge B ---> Bridge C ---> Bridge D ---> Bridge E + * + * With pre_enable_prev_first flag enable in Bridge B, D, E then the resulting + * @pre_enable order would be, + * Bridge C, Bridge D, Bridge E, Bridge A, Bridge B. + * * Note: the bridge passed should be the one closest to the encoder */ void drm_atomic_bridge_chain_pre_enable(struct drm_bridge *bridge,