Received: by 2002:a05:6358:a55:b0:ec:fcf4:3ecf with SMTP id 21csp1524993rwb; Fri, 13 Jan 2023 13:35:25 -0800 (PST) X-Google-Smtp-Source: AMrXdXug8uef9djSy7fPxGKnBVj7V/g2E001ahSX1ICAv3HQTek6eXl6+pZLoXIPtBf8CQfcYhFy X-Received: by 2002:a17:902:8e81:b0:192:d5dc:c842 with SMTP id bg1-20020a1709028e8100b00192d5dcc842mr41479120plb.44.1673645724975; Fri, 13 Jan 2023 13:35:24 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1673645724; cv=none; d=google.com; s=arc-20160816; b=JOgoNoIsAZIgKQ8KF8WIIa0PNE2xHcFZ19fzYiZUTlJBaXkTgl4YviXZ0l+nK4Fc2G uUlfrJM+7MZaZmjZUD0rkVsWjonKcV94vsxeOPoVfhPewliaRM8WEER+aLT/uyjoNHAM rQr+RanzZu0E5jmIWiwt9nMvdrUpK3HIzR4XejOo/9EWFgZkEMBpz5FCwcvgFVo+zpaE f6Eo/5sFfs7mB5fw7+Z6Sfd0xae3n7+oQ2rJz6czaZzFz3Qhoj0MZGJu7yJCLhQbTrg2 fckzFsp7tZpqr5yhHMp7DEfl9VA4XkUu/KtbIsDVMpmMRdBCLa90NHd8yH8MR3gLMzPj C+GA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:cc:to:subject :message-id:date:user-agent:from:references:in-reply-to:mime-version :dkim-signature; bh=r5E2jUOsmFLtdYppT5Vp0YBT45RVJ+ABe3kgqhVZhkI=; b=TEaPw2I8WBSAvvUqSWQFkh8CTY1gMQluxo/AYdKyk2+rzbFFTXedC6acKw/nopA1Fw HwvazP8ZwLVIVwPMOk4xkYd36oXw1Tsdn9+egaOarINLU64RJzD0cn3EE97o7E582tVJ M0X4Qh5ALxplUHf3XNdU3DGhyhu547FEGa/MaP1QpYhEA4X0FPEX0F92ERgDeyWAEG2x /bGbJF84cQ5MGmWL3qgzJjXAiFIExQn3mdsQegeQY8qMe5dz87w+WKNNC99wZjrqygXy kVafdEaBnGD0z4lcTMy8see7O5MNjEvyZK//s1hZThYMLEl1qEsTXgDPpTs1dVSkyHjZ j7cw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@chromium.org header.s=google header.b=IkJ+FOVo; 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 jj13-20020a170903048d00b00192fcf07b75si19955156plb.352.2023.01.13.13.34.51; Fri, 13 Jan 2023 13:35:24 -0800 (PST) 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=IkJ+FOVo; 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 S229980AbjAMVMP (ORCPT + 52 others); Fri, 13 Jan 2023 16:12:15 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:48678 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229753AbjAMVML (ORCPT ); Fri, 13 Jan 2023 16:12:11 -0500 Received: from mail-lf1-x133.google.com (mail-lf1-x133.google.com [IPv6:2a00:1450:4864:20::133]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 387D353299 for ; Fri, 13 Jan 2023 13:12:10 -0800 (PST) Received: by mail-lf1-x133.google.com with SMTP id d30so29895465lfv.8 for ; Fri, 13 Jan 2023 13:12:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=content-transfer-encoding:cc:to:subject:message-id:date:user-agent :from:references:in-reply-to:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=r5E2jUOsmFLtdYppT5Vp0YBT45RVJ+ABe3kgqhVZhkI=; b=IkJ+FOVocZ4ttJ4pEh+dqaYc1loiq1VzM4s8rw3sfw+1LDPtVXu3+QCzwNyI/P+Oz3 Q8GtrQlQFVgEw2AwhcdO9Y+lo70CcrUxOaUVv6K3tg9hOQIlRZure7tE16OwYGB+40y7 IkaTssjuMdbN49fZTK+WSj6EXgdB+69XdqZus= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:cc:to:subject:message-id:date:user-agent :from:references:in-reply-to:mime-version:x-gm-message-state:from:to :cc:subject:date:message-id:reply-to; bh=r5E2jUOsmFLtdYppT5Vp0YBT45RVJ+ABe3kgqhVZhkI=; b=20n3zSscOKKLamInyLjfCvYYUVeVyb9nQH7ibMiTf0LTN5uSaZBqpR8xE5/fe39c5Q kvPqekQi33Zdoh9geEBRjMSbxbHCIf2ooCe3q7mt9LBPYF15WA9/ij8pBTCgxe2L4Cbd aSiAJhnCBLoy85bhC7ljXqHF/UjdCMazLdPitlTvmqwnSZCfNuDSxMO09qALeeZx1Vq0 T0e7dmtw/1talBV2yyK2yBfv5atfAhZnASMo2x152bqQmJdKPzISt0byszb37DdSYZSJ mfhBzOPNVtAdT4JSFitGT9O4QBnBOJF0E2Ecg252wBBwIEwnrgz717lKM1hY+cD7Ku5a AGgw== X-Gm-Message-State: AFqh2kr9MTitFZKpuwLSf5+ScP2/o0toABOUd9ROHdNEVHP5RnjJzdLe /4USjUSJHFwNxpiz7yl5Yc7+AXEygzh7F3xueQ6FdQ== X-Received: by 2002:a05:6512:4017:b0:4bd:35fd:65b5 with SMTP id br23-20020a056512401700b004bd35fd65b5mr8207466lfb.297.1673644328511; Fri, 13 Jan 2023 13:12:08 -0800 (PST) Received: from 753933720722 named unknown by gmailapi.google.com with HTTPREST; Fri, 13 Jan 2023 15:12:07 -0600 MIME-Version: 1.0 In-Reply-To: References: <20230106030108.2542081-1-swboyd@chromium.org> From: Stephen Boyd User-Agent: alot/0.10 Date: Fri, 13 Jan 2023 15:12:07 -0600 Message-ID: Subject: Re: [PATCH] drm/panel: boe-tv101wum-nl6: Ensure DSI writes succeed during disable To: Dave Stevenson Cc: Thierry Reding , Rob Clark , Douglas Anderson , Jitao Shi , yangcong , linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org, patches@lists.linux.dev, linux-mediatek@lists.infradead.org, Dmitry Baryshkov , Sam Ravnborg , linux-arm-kernel@lists.infradead.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-2.1 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 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 Quoting Dave Stevenson (2023-01-13 08:27:29) > Hi Stephen > > On Fri, 6 Jan 2023 at 03:01, Stephen Boyd wrote: > > > > The unprepare sequence has started to fail after moving to panel bridge > > code in the msm drm driver (commit 007ac0262b0d ("drm/msm/dsi: switch t= o > > DRM_PANEL_BRIDGE")). You'll see messages like this in the kernel logs: > > > > panel-boe-tv101wum-nl6 ae94000.dsi.0: failed to set panel off: -22 > > > > This is because boe_panel_enter_sleep_mode() needs an operating DSI lin= k > > to set the panel into sleep mode. Performing those writes in the > > unprepare phase of bridge ops is too late, because the link has already > > been torn down by the DSI controller in post_disable, i.e. the PHY has > > been disabled, etc. See dsi_mgr_bridge_post_disable() for more details > > on the DSI . > > > > Split the unprepare function into a disable part and an unprepare part. > > For now, just the DSI writes to enter sleep mode are put in the disable > > function. This fixes the panel off routine and keeps the panel happy. > > It is documented that the mipi_dsi_host_ops transfer function should > be called with the host in any state [1], so the host driver is > failing there. Thanks for the info! It says "Drivers that need the underlying device to be powered to perform these operations will first need to make sure it=E2= =80=99s been properly enabled." Does that mean the panel driver needs to make sure the underlying dsi host device is powered? The sentence is too ambiguous for me to understand what 'drivers' and 'underlying device' are. > > This sounds like the same issue I was addressing in adding the > prepare_prev_first flag to drm_panel, and pre_enable_prev_first to > drm_bridge via [2]. > Defining prepare_prev_first for your panel would result in the host > pre_enable being called before the panel prepare, and therefore the > transfer calls from boe_panel_init_dcs_cmd boe_panel_prepare won't be > relying on the DSI host powering up early. It will also call the panel > unprepare before the DSI host bridge post_disable is called, and > therefore the DSI host will still be powered up and the transfer won't > fail. > > Actually I've just noted the comment at [3]. [2] is that framework fix > that means that the magic workaround isn't required, but it will > require this panel to opt in to the ordering change. Cool. Glad that we can clean that up with your series. Is it wrong to split unprepare to a disable and unprepare phase? I'm not super keen on fixing 6.1 stable kernels by opting this driver into the ordering change. Splitting the phase into two is small and simple and works. I suspect changing the ordering may uncover more bugs, or be a larger task. I'd be glad to test that series[2] from you to get rid of [3]. > > > [1] https://www.kernel.org/doc/html/latest/gpu/drm-kms-helpers.html#c.mip= i_dsi_host_ops > [2] https://patchwork.freedesktop.org/series/100252/ > [3] https://github.com/torvalds/linux/blob/master/drivers/gpu/drm/msm/dsi= /dsi_manager.c#L47 >