Received: by 2002:a05:6a11:4021:0:0:0:0 with SMTP id ky33csp3702329pxb; Mon, 27 Sep 2021 00:12:34 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxhkFztkPEUaaFr++Y3N11nJXHPLO1IKn0ql8E57C71bMHzCIKIw1wNcErGNRCOkKcrV3WS X-Received: by 2002:a50:d94c:: with SMTP id u12mr21162777edj.371.1632726754616; Mon, 27 Sep 2021 00:12:34 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1632726754; cv=none; d=google.com; s=arc-20160816; b=IjXDH/4lW+zMCE83AppejBHmTdqmsLpWUOnuq7A2AOMjnV+74nbSFvkbQoDaIakWBE WrvE5/T4NRdkkuOKNjfzbGwDvo2GDrEoOCh37dzXzzG3pdJ7f1UrJTDbQKpUIeoPili4 3SQj7ky0lT6dgZmWQOsZDKA1YQh4Rfr4TVRwKJwmh/LSDH3y//8v5amVMapuncYUsSLq 2Yy7+1ozxJ3RNjkDljMF3XOUSKg0Y0FQ5TTJmt6gxrbi5M+Yja36iecjV4ktMsYtH+QB LEKUIHuWSGnU+0GwBJUkxpg67eSqhxelDDa3vtfih9FllJowS4jpkwcVVcQjvqwNUfrd bJzw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:dkim-signature; bh=Aq6qXeEc6aCYUKeljOyg151CIpIcZX36L8L/emY/OsE=; b=alAKQf0NSbYrExFWIm3jVfvR6Hl/VGI6sMcdkJb/3OiEk25mdip2XaoQ/t+JaJDPEi UcxnFySu2MUn2oPy507g58FP77wQTkFWPyRDS4RZNeO/ZSFZSRYRGlG366jGvnTFDzaM 8AkbLSBLcvYnDYWcTRHWHIoRj+tjYv1I+4/E37Z5OkeX43zsZH4tecvPDGZdHJ6kh+UD w3HdmJ2MYWQprhYc7BtF0ordJpmpO+eY/7oEVs8YKIlN5guMi0ozO2RpHAC+YiGYLM5G ktKvCgHEFD5A1lvfMNjaDS/CogZ2DCBQTdz4QRDQWLeaYKcnyH8IcyOkhYYxo4R5z5+1 RlfA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@chromium.org header.s=google header.b=cdo8ZMZP; 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=pass (p=NONE sp=NONE dis=NONE) header.from=chromium.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id v25si16750544ejg.759.2021.09.27.00.12.10; Mon, 27 Sep 2021 00:12:34 -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; dkim=pass header.i=@chromium.org header.s=google header.b=cdo8ZMZP; 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=pass (p=NONE sp=NONE dis=NONE) header.from=chromium.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233035AbhI0HME (ORCPT + 99 others); Mon, 27 Sep 2021 03:12:04 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:40964 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233083AbhI0HME (ORCPT ); Mon, 27 Sep 2021 03:12:04 -0400 Received: from mail-lf1-x12b.google.com (mail-lf1-x12b.google.com [IPv6:2a00:1450:4864:20::12b]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 85F31C061575 for ; Mon, 27 Sep 2021 00:10:26 -0700 (PDT) Received: by mail-lf1-x12b.google.com with SMTP id u8so72161920lff.9 for ; Mon, 27 Sep 2021 00:10:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Aq6qXeEc6aCYUKeljOyg151CIpIcZX36L8L/emY/OsE=; b=cdo8ZMZPgS23dQDWWQhIUz40AnsyRN1qLMaZytqB14q9S3g5rNWtoNuUWOrk4IfySl /WqSq2xp+D35x4/2OYOxaqEtEKbQwSXukciLeOIfR2YGJBFlv29MPoefU3H0JMAAT917 6THv9CbJ71Fl8F9NaahSeJGT/JbieFnYEF/n0= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Aq6qXeEc6aCYUKeljOyg151CIpIcZX36L8L/emY/OsE=; b=VQGgMgli/E2TV7rTy9UU2iRypENurqZ81/Kcv8mJY+VY7LhuiVD+NPDy/pjMgJBlzv qjT6uOEVTPQZPi4gdgehVhKP+o18brIYqF2qi0ECBni1E93to1poKR8h2UUb7awHY1eL QPV90DzatNqD54mPwhLSQEURoOl8f9nNX/xvl19xMsNPKLVnn8U/fbE5w0Gr7r5RRzOv r3PDRTOgCzubMuWyXUv3nKxWOxwGiggLr18FmvJF6SRWs8n3fcHsDBEO5pSQCTCkBdRE uFat99VMX9H9XNUOg3Zgl8xETHcqVtSaOgd5FlZ8Sx9jkHMlS9prrwslG7UfnHHFKH1U ktNQ== X-Gm-Message-State: AOAM531Gry/hbr8RIGbjei+XveHU7D44uts5lvP3pa7rOdXscOTcihuS SIC6IhZLtq7qgCSNcn2DfEjFwLjAJOfxONSNGNUvJA== X-Received: by 2002:a05:651c:1505:: with SMTP id e5mr27957292ljf.9.1632726624665; Mon, 27 Sep 2021 00:10:24 -0700 (PDT) MIME-Version: 1.0 References: <20210924162321.1.Ic2904d37f30013a7f3d8476203ad3733c186827e@changeid> In-Reply-To: <20210924162321.1.Ic2904d37f30013a7f3d8476203ad3733c186827e@changeid> From: Chen-Yu Tsai Date: Mon, 27 Sep 2021 15:10:13 +0800 Message-ID: Subject: Re: [PATCH 1/2] drm/rockchip: dsi: hold pm-runtime across bind/unbind To: Brian Norris Cc: =?UTF-8?Q?Heiko_St=C3=BCbner?= , dri-devel , LKML , Sandy Huang , "open list:ARM/Rockchip SoC..." , Thomas Hebb , aleksandr.o.makarov@gmail.com, stable@vger.kernel.org Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi, On Sat, Sep 25, 2021 at 7:24 AM Brian Norris wrote: > > In commit 59eb7193bef2, we moved most HW configuration to bind(), but we > didn't move the runtime PM management. Therefore, depending on initial > boot state, runtime-PM workqueue delays, and other timing factors, we > may disable our power domain in between the hardware configuration > (bind()) and when we enable the display. This can cause us to lose > hardware state and fail to configure our display. For example: > > dw-mipi-dsi-rockchip ff968000.mipi: failed to write command FIFO > panel-innolux-p079zca ff960000.mipi.0: failed to write command 0 > > or: > > dw-mipi-dsi-rockchip ff968000.mipi: failed to write command FIFO > panel-kingdisplay-kd097d04 ff960000.mipi.0: failed write init cmds: -110 > > We should match the runtime PM to the lifetime of the bind()/unbind() > cycle. I'm not too familiar with MIPI DSI, but it seems that the subsystem expects the DSI link to be always available, and in LPM if power saving is required? If so then this change matches that expectation, though we might lose some power savings compared to the previous non-conforming behavior. > Tested on Acer Chrometab 10 (RK3399 Gru-Scarlet), with panel drivers > built either as modules or built-in. > > Side notes: it seems one is more likely to see this problem when the > panel driver is built into the kernel. I've also seen this problem > bisect down to commits that simply changed Kconfig dependencies, because > it changed the order in which driver init functions were compiled into > the kernel, and therefore the ordering and timing of built-in device > probe. > > Fixes: 59eb7193bef2 ("drm/rockchip: dsi: move all lane config except LCDC mux to bind()") This hash is from some stable branch. The mainline one is: 43c2de1002d2 drm/rockchip: dsi: move all lane config except LCDC mux to bind() > Link: https://lore.kernel.org/linux-rockchip/9aedfb528600ecf871885f7293ca4207c84d16c1.camel@gmail.com/ > Reported-by: > Cc: > Signed-off-by: Brian Norris > --- > > .../gpu/drm/rockchip/dw-mipi-dsi-rockchip.c | 22 +++++++------------ > 1 file changed, 8 insertions(+), 14 deletions(-) > > diff --git a/drivers/gpu/drm/rockchip/dw-mipi-dsi-rockchip.c b/drivers/gpu/drm/rockchip/dw-mipi-dsi-rockchip.c > index a2262bee5aa4..4340a99edb97 100644 > --- a/drivers/gpu/drm/rockchip/dw-mipi-dsi-rockchip.c > +++ b/drivers/gpu/drm/rockchip/dw-mipi-dsi-rockchip.c > @@ -773,10 +773,6 @@ static void dw_mipi_dsi_encoder_enable(struct drm_encoder *encoder) > if (mux < 0) > return; > > - pm_runtime_get_sync(dsi->dev); > - if (dsi->slave) > - pm_runtime_get_sync(dsi->slave->dev); > - > /* > * For the RK3399, the clk of grf must be enabled before writing grf > * register. And for RK3288 or other soc, this grf_clk must be NULL, > @@ -795,20 +791,10 @@ static void dw_mipi_dsi_encoder_enable(struct drm_encoder *encoder) > clk_disable_unprepare(dsi->grf_clk); > } > > -static void dw_mipi_dsi_encoder_disable(struct drm_encoder *encoder) > -{ > - struct dw_mipi_dsi_rockchip *dsi = to_dsi(encoder); > - > - if (dsi->slave) > - pm_runtime_put(dsi->slave->dev); > - pm_runtime_put(dsi->dev); > -} > - > static const struct drm_encoder_helper_funcs > dw_mipi_dsi_encoder_helper_funcs = { > .atomic_check = dw_mipi_dsi_encoder_atomic_check, > .enable = dw_mipi_dsi_encoder_enable, > - .disable = dw_mipi_dsi_encoder_disable, > }; > > static int rockchip_dsi_drm_create_encoder(struct dw_mipi_dsi_rockchip *dsi, > @@ -938,6 +924,10 @@ static int dw_mipi_dsi_rockchip_bind(struct device *dev, > put_device(second); > } > > + pm_runtime_get_sync(dsi->dev); > + if (dsi->slave) > + pm_runtime_get_sync(dsi->slave->dev); > + > ret = clk_prepare_enable(dsi->pllref_clk); > if (ret) { > DRM_DEV_ERROR(dev, "Failed to enable pllref_clk: %d\n", ret); The bind function is missing an error cleanup path. We might end up with unbalanced runtime PM references. (And also possibly an enabled pllref clk.) This is a pre-existing issue though. The code changes here look correct. Regards ChenYu > @@ -989,6 +979,10 @@ static void dw_mipi_dsi_rockchip_unbind(struct device *dev, > dw_mipi_dsi_unbind(dsi->dmd); > > clk_disable_unprepare(dsi->pllref_clk); > + > + pm_runtime_put(dsi->dev); > + if (dsi->slave) > + pm_runtime_put(dsi->slave->dev); > } > > static const struct component_ops dw_mipi_dsi_rockchip_ops = { > -- > 2.33.0.685.g46640cef36-goog > > > _______________________________________________ > Linux-rockchip mailing list > Linux-rockchip@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-rockchip