Message ID | 20231220221418.2610185-1-hsinyi@chromium.org |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel+bounces-7497-ouuuleilei=gmail.com@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a05:7300:2483:b0:fb:cd0c:d3e with SMTP id q3csp46490dyi; Wed, 20 Dec 2023 14:27:17 -0800 (PST) X-Google-Smtp-Source: AGHT+IFbwt0s9vL08Wqpk3zu9fC1jMz3jfaAaF12x7UugjfySNLvFNC1lBqrhzE+8JFElNJUKbPv X-Received: by 2002:a05:6830:1d8:b0:6da:5573:3f85 with SMTP id r24-20020a05683001d800b006da55733f85mr8830051ota.57.1703111237256; Wed, 20 Dec 2023 14:27:17 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1703111237; cv=none; d=google.com; s=arc-20160816; b=KLP/QvTSwy8oAoIWiT9cjiPvg4foRZ1NmNlAeMT2Nhk03tA9XpqE4t+99QeS7knvjO u+f0WmgS/qQLoTWAmr1aJeuXUf24g83j9gJR2VJIUEBr0k0SXZe/LxoJpQOzFPzZQlxm I7wJbuX16Pg2alDI6+D35jbHFTrmgc4xwlo43oQt4TgIbwjqu+71DGJkZiB/J7ZnjK7M ymELjnXDk536NJtWx2r7funl89tSqXw6rKRBtRHlFKv/Qk7WtAYKSKnZJcTe3+V7V/sX Ppgj5t5iE76sLLWxlXCVzfcuz1h+uDhHTe9d1H5tQxva2dYiKl2jWznWTcB3nnEsV4lR V2gA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=content-transfer-encoding:mime-version:list-unsubscribe :list-subscribe:list-id:precedence:message-id:date:subject:cc:to :from:dkim-signature; bh=ZD3VpyHhC0C+pwwNEc0NgWoPlzlh6lpsOAPY3FHREss=; fh=L+nuQwpo7Lkk7JvXwTjpnOogzXLVA8umr2cjw5/wcYs=; b=oiHzqEzYHJDl0pv509yYAb44op4onWJ0nm4gFhEMIITrLpY7jyuDzOW96mOlx2DvzH onpH/mscCCiNGDSIYuc0C6UG3alAz6epdglFhai8yEe9spAC6Eo+AnnD6mYAJ25hFInd LOMS6P5uJTgijZ0pVa93Gh1KXQClc5vIbve/MCYm+6jIsCU5haOjtMRFp32PL/clD9Om rkF9YO7hHwQRyZ8VuH8K56GfTQceQKWhg/P7CTAMGKRdjplYakB2AOKokrmHwAwrmUzn gfxeN4L6B3RhlhHAkwNNZ4nNc8/39I251T+L2KdfYzQufWAYZVcOq1xgOzYsPkqnmceV 10iQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@chromium.org header.s=google header.b=Kf1WrFjb; spf=pass (google.com: domain of linux-kernel+bounces-7497-ouuuleilei=gmail.com@vger.kernel.org designates 2604:1380:45e3:2400::1 as permitted sender) smtp.mailfrom="linux-kernel+bounces-7497-ouuuleilei=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=chromium.org Received: from sv.mirrors.kernel.org (sv.mirrors.kernel.org. [2604:1380:45e3:2400::1]) by mx.google.com with ESMTPS id ca10-20020a056a02068a00b005b42f4443b7si453522pgb.653.2023.12.20.14.27.17 for <ouuuleilei@gmail.com> (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 20 Dec 2023 14:27:17 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel+bounces-7497-ouuuleilei=gmail.com@vger.kernel.org designates 2604:1380:45e3:2400::1 as permitted sender) client-ip=2604:1380:45e3:2400::1; Authentication-Results: mx.google.com; dkim=pass header.i=@chromium.org header.s=google header.b=Kf1WrFjb; spf=pass (google.com: domain of linux-kernel+bounces-7497-ouuuleilei=gmail.com@vger.kernel.org designates 2604:1380:45e3:2400::1 as permitted sender) smtp.mailfrom="linux-kernel+bounces-7497-ouuuleilei=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=chromium.org Received: from smtp.subspace.kernel.org (wormhole.subspace.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by sv.mirrors.kernel.org (Postfix) with ESMTPS id 493B328C3C6 for <ouuuleilei@gmail.com>; Wed, 20 Dec 2023 22:14:54 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id D2DB54B139; Wed, 20 Dec 2023 22:14:35 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=chromium.org header.i=@chromium.org header.b="Kf1WrFjb" X-Original-To: linux-kernel@vger.kernel.org Received: from mail-pl1-f182.google.com (mail-pl1-f182.google.com [209.85.214.182]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id BD4914AF66 for <linux-kernel@vger.kernel.org>; Wed, 20 Dec 2023 22:14:31 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=chromium.org Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=chromium.org Received: by mail-pl1-f182.google.com with SMTP id d9443c01a7336-1d3ac87553bso1683415ad.3 for <linux-kernel@vger.kernel.org>; Wed, 20 Dec 2023 14:14:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; t=1703110471; x=1703715271; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:from:to:cc:subject:date:message-id:reply-to; bh=ZD3VpyHhC0C+pwwNEc0NgWoPlzlh6lpsOAPY3FHREss=; b=Kf1WrFjb1PqpB9MFOq9VrDarI1CznPtHkhB1SJO3zDbPKNTLdtRHcWBlwjwmE1eV4j +z8xHDxSsXZv+17LAUzkI48jbdM52Vhos4B6tYPdi6GEiOgkrtPxWdfxBzdCt3fbHZc1 hR2F779yiEhsalGWFiKM8LxsNECs1Kt8mWusE= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1703110471; x=1703715271; 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=ZD3VpyHhC0C+pwwNEc0NgWoPlzlh6lpsOAPY3FHREss=; b=cMWn8LZMmSbBoTskxP8Tdy9sQZYgoBsZdWAc4+3odcYsKtscUyTxgxa9azOmuziHBV MdmYi+dgLAZfv4ftoSojWZbewdF9BahVmOPPFNifFnzEG998S43kUJgtFlp5xl0g8QOn GToEYJSh5v/N2eg7jUlPIhrtviPp1k5sBMyQUeLn/aTLCu/MyKFuNR/SfiPEsJUQRdSL rw8fX3IBWRNz/iVe2DuBStdkm8/NtM7JLs0bZr+VJUXRzLtwrXqZGIVsLx68W8e7P76c xHgc8Uhn8pJhlQNLCBroFaaFjxud4QspsqF10yAMFada4+MSd36ocdXkgTgJ5BwLUd2X sDoA== X-Gm-Message-State: AOJu0Yx2Ok1z61/dpkdATycdOhrKr8XNbBi2ao+6dXhDBW/nsWg29kQ9 k0zLcIhAaeRcb/26Wsom5MoAeg== X-Received: by 2002:a17:903:1cc:b0:1d3:5f99:17df with SMTP id e12-20020a17090301cc00b001d35f9917dfmr8812369plh.38.1703110471046; Wed, 20 Dec 2023 14:14:31 -0800 (PST) Received: from hsinyi.sjc.corp.google.com ([2620:15c:9d:2:8e1f:dd12:809:b2c8]) by smtp.gmail.com with ESMTPSA id d14-20020a170902aa8e00b001bf52834696sm203086plr.207.2023.12.20.14.14.30 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 20 Dec 2023 14:14:30 -0800 (PST) From: Hsin-Yi Wang <hsinyi@chromium.org> To: Douglas Anderson <dianders@chromium.org> Cc: Neil Armstrong <neil.armstrong@linaro.org>, Jessica Zhang <quic_jesszhan@quicinc.com>, Sam Ravnborg <sam@ravnborg.org>, Maarten Lankhorst <maarten.lankhorst@linux.intel.com>, Maxime Ripard <mripard@kernel.org>, Thomas Zimmermann <tzimmermann@suse.de>, David Airlie <airlied@gmail.com>, Daniel Vetter <daniel@ffwll.ch>, Linus Walleij <linus.walleij@linaro.org>, dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org Subject: [PATCH] drm/panel-edp: use put_sync in unprepare Date: Wed, 20 Dec 2023 14:13:11 -0800 Message-ID: <20231220221418.2610185-1-hsinyi@chromium.org> X-Mailer: git-send-email 2.43.0.472.g3155946c3a-goog Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: <linux-kernel.vger.kernel.org> List-Subscribe: <mailto:linux-kernel+subscribe@vger.kernel.org> List-Unsubscribe: <mailto:linux-kernel+unsubscribe@vger.kernel.org> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1785841568578232355 X-GMAIL-MSGID: 1785841568578232355 |
Series |
drm/panel-edp: use put_sync in unprepare
|
|
Commit Message
Hsin-Yi Wang
Dec. 20, 2023, 10:13 p.m. UTC
Some edp panel requires T10 (Delay from end of valid video data transmitted
by the Source device to power-off) less than 500ms. Using autosuspend with
delay set as 1000 violates this requirement.
Use put_sync_suspend in unprepare to meet the spec. For other cases (such
as getting EDID), it still uses autosuspend.
Suggested-by: Douglas Anderson <dianders@chromium.org>
Fixes: 5f04e7ce392d ("drm/panel-edp: Split eDP panels out of panel-simple")
Signed-off-by: Hsin-Yi Wang <hsinyi@chromium.org>
---
drivers/gpu/drm/panel/panel-edp.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
Comments
Hi, On Wed, Dec 20, 2023 at 2:14 PM Hsin-Yi Wang <hsinyi@chromium.org> wrote: > > Some edp panel requires T10 (Delay from end of valid video data transmitted > by the Source device to power-off) less than 500ms. Using autosuspend with > delay set as 1000 violates this requirement. > > Use put_sync_suspend in unprepare to meet the spec. For other cases (such > as getting EDID), it still uses autosuspend. > > Suggested-by: Douglas Anderson <dianders@chromium.org> > Fixes: 5f04e7ce392d ("drm/panel-edp: Split eDP panels out of panel-simple") Probably instead: Fixes: 3235b0f20a0a ("drm/panel: panel-simple: Use runtime pm to avoid excessive unprepare / prepare") ...you could send a new version or I could just fix it up when I apply it. > Signed-off-by: Hsin-Yi Wang <hsinyi@chromium.org> > --- > drivers/gpu/drm/panel/panel-edp.c | 3 +-- > 1 file changed, 1 insertion(+), 2 deletions(-) Yeah, it's really unfortunate but I think we have to do this. It will add big delays any time we need to turn the panel off and quickly back on again, but I don't think we can reliably meet T10 without it. Even turning down the autosuspend delay won't really help since someone could do something like read the EDID while the delay was happening to reset the delay. At least we can still use "autosuspend" to avoid powering off between reading the EDID and powering up the panel since the EDID grabs runtime_pm itself and still uses autosuspend. I don't remember this particular problem before and nobody has yelled about it in the past. ...and the requirement seems crazy, but it certainly is in the spec sheets so we should be good citizens and honor it. On the plus side, this means that we will always fully power cycle the panel whenever we turn video off and that means that if any other panels out there have weird issues like "samsung-atna33xc20" this will also fix them since this is the same fix I had to do in that driver. In any case: Reviewed-by: Douglas Anderson <dianders@chromium.org> I'm about to go on vacation, so I won't apply this until January. Other drm-misc maintainers are free to apply sooner than that if they're comfortable with it.
Hi, On Wed, Dec 20, 2023 at 2:43 PM Doug Anderson <dianders@chromium.org> wrote: > > Hi, > > On Wed, Dec 20, 2023 at 2:14 PM Hsin-Yi Wang <hsinyi@chromium.org> wrote: > > > > Some edp panel requires T10 (Delay from end of valid video data transmitted > > by the Source device to power-off) less than 500ms. Using autosuspend with > > delay set as 1000 violates this requirement. > > > > Use put_sync_suspend in unprepare to meet the spec. For other cases (such > > as getting EDID), it still uses autosuspend. > > > > Suggested-by: Douglas Anderson <dianders@chromium.org> > > Fixes: 5f04e7ce392d ("drm/panel-edp: Split eDP panels out of panel-simple") > > Probably instead: > > Fixes: 3235b0f20a0a ("drm/panel: panel-simple: Use runtime pm to avoid > excessive unprepare / prepare") > > ...you could send a new version or I could just fix it up when I apply it. > > > > Signed-off-by: Hsin-Yi Wang <hsinyi@chromium.org> > > --- > > drivers/gpu/drm/panel/panel-edp.c | 3 +-- > > 1 file changed, 1 insertion(+), 2 deletions(-) > > Yeah, it's really unfortunate but I think we have to do this. It will > add big delays any time we need to turn the panel off and quickly back > on again, but I don't think we can reliably meet T10 without it. Even > turning down the autosuspend delay won't really help since someone > could do something like read the EDID while the delay was happening to > reset the delay. At least we can still use "autosuspend" to avoid > powering off between reading the EDID and powering up the panel since > the EDID grabs runtime_pm itself and still uses autosuspend. > > I don't remember this particular problem before and nobody has yelled > about it in the past. ...and the requirement seems crazy, but it > certainly is in the spec sheets so we should be good citizens and > honor it. On the plus side, this means that we will always fully power > cycle the panel whenever we turn video off and that means that if any > other panels out there have weird issues like "samsung-atna33xc20" > this will also fix them since this is the same fix I had to do in that > driver. > > In any case: > > Reviewed-by: Douglas Anderson <dianders@chromium.org> > > I'm about to go on vacation, so I won't apply this until January. > Other drm-misc maintainers are free to apply sooner than that if > they're comfortable with it. Things were silent and I'm back from vacation, so I've gone ahead and pushed this to drm-misc-next. Technically I could have pushed it to drm-misc-fixes, but from my understanding of the issue it was not causing any actual problems other than making someone upset who was staring at oscilloscope traces and comparing them to a spec sheet. Given that this changes timings, I'd rather have the extra bake time of going through drm-misc-next. 49ddab089611 drm/panel-edp: use put_sync in unprepare -Doug
diff --git a/drivers/gpu/drm/panel/panel-edp.c b/drivers/gpu/drm/panel/panel-edp.c index cd05c76868e3..7d556b1bfa82 100644 --- a/drivers/gpu/drm/panel/panel-edp.c +++ b/drivers/gpu/drm/panel/panel-edp.c @@ -429,8 +429,7 @@ static int panel_edp_unprepare(struct drm_panel *panel) if (!p->prepared) return 0; - pm_runtime_mark_last_busy(panel->dev); - ret = pm_runtime_put_autosuspend(panel->dev); + ret = pm_runtime_put_sync_suspend(panel->dev); if (ret < 0) return ret; p->prepared = false;