Message ID | 20230804140605.RFC.3.I6a4a3c81c78acf5acdc2e5b5d936e19bf57ec07a@changeid |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a59:c44e:0:b0:3f2:4152:657d with SMTP id w14csp142499vqr; Fri, 4 Aug 2023 15:45:13 -0700 (PDT) X-Google-Smtp-Source: AGHT+IHbd0M3Eh0VCGh1SZDqk7rF+Mvxwy+SXR7lwkbR8Kd6dp/7HlugQWGR5aBkisw5jeODF09v X-Received: by 2002:a17:906:54:b0:999:26d3:b815 with SMTP id 20-20020a170906005400b0099926d3b815mr2969767ejg.64.1691189113076; Fri, 04 Aug 2023 15:45:13 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1691189113; cv=none; d=google.com; s=arc-20160816; b=o875pY9O20svTy3Qofk77H/BenN4Ws68o6TvxEoDeQNLxpNmhg4TftLcsXos48WDT2 RaXA/0zJhqlz80a2wxcT49dE/vPiuprye79gC/ZCFoY3fAioH64A9j1X6smo3tk1njZa 6uNCq3Pi+u6EbIKDMDOUd1JkiH3Sa5i/VS8mol4POMzUOU8haRRVa+zzxz/whUTNd1rz xi8poaQrWF4etPeVk9A1Zpvwq+dY774QMfXxCtYCEsKyqDGeb+QFHLZWVrmuvm1QZAar XcFsi5TJHhAnChRRA1uwjCkURLZhxBQz1F24eUShjFI5ZZkKCzsuPx1csPPV0Cp4VgME XE8w== 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 :references:in-reply-to:message-id:date:subject:cc:to:from :dkim-signature; bh=Zs0Gv4Fg+9bXbPDS+x5MeuiOn4j7KTC6rQDcvADWb+8=; fh=dprmmFr5kEs2oaIKuWw0OlwhpcBwFTafCHELzUCPXiw=; b=viteTesKKPK1fMg3WJ8FiwXgbrJgjvBNsE/5HRQHzgwDScU2mwV02xCudW6/Gkck4A OUeFxbJ65VMklMXmEO1SVWU5EKQvhAF2m5NkabE/lEcRXxHG3jt43WfyQ3KnrIH8iH82 BUJZEYZT8EIluj0G/O8e+PGzZjrpiwhFU3zfDRjQWgk+cZ9oc+hODwHIB2luy+k7UphD fqJmPPz3rOWa5Sp/wW8qtmtKxd/xaDBoVVWE/bMMuBZzFbR9Ujsc4WdbR6blPioGWQBf PE4pOFleIAuHZqdB8QExqufnH9ZXAweY1KVPAApW/tik0jOZ52hON4KogkgjIPZgy6tw SiGg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@chromium.org header.s=google header.b=TFhIf+Y9; 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: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id i5-20020a1709061cc500b0099bd667fcf1si2114714ejh.776.2023.08.04.15.44.49; Fri, 04 Aug 2023 15:45:13 -0700 (PDT) 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=TFhIf+Y9; 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 S230355AbjHDVIS (ORCPT <rfc822;wenzhi022@gmail.com> + 99 others); Fri, 4 Aug 2023 17:08:18 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:35342 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231174AbjHDVIK (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Fri, 4 Aug 2023 17:08:10 -0400 Received: from mail-pf1-x42a.google.com (mail-pf1-x42a.google.com [IPv6:2607:f8b0:4864:20::42a]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id F36D655A5 for <linux-kernel@vger.kernel.org>; Fri, 4 Aug 2023 14:07:20 -0700 (PDT) Received: by mail-pf1-x42a.google.com with SMTP id d2e1a72fcca58-686f94328a4so1744043b3a.0 for <linux-kernel@vger.kernel.org>; Fri, 04 Aug 2023 14:07:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; t=1691183239; x=1691788039; 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=Zs0Gv4Fg+9bXbPDS+x5MeuiOn4j7KTC6rQDcvADWb+8=; b=TFhIf+Y92Yutq1q3r5QXOVtSDF6+EmNeMvB5c54nDo5/RLID3p2uAWC+vf3ZkgRLgr 5lVq8JsIHNr5sA1uIXxUjC0RY8/VDxXP02vT4SK9+Cx6ej0mEB22eYcCWFY8MFDlmbTm vgGaUnrtDEb268mi/DcLufyaS3DzHeChCP1/g= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1691183239; x=1691788039; 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=Zs0Gv4Fg+9bXbPDS+x5MeuiOn4j7KTC6rQDcvADWb+8=; b=iyWLiisJ/j5v/2sgzI/cXQQGRjK48JZsm8ZVskDUID4frFKViEJn1yOG8i8BIGI+WF ldZhpSNScahEv/1WpvfudSyQTwd+R8M2bjtiD8cTwmC7jziCUN+j9mgMp9SYTDBfI6cC Fezn7cjAQs6ER20BjbmEg1y3wK9YNPERbN1nQgywjYhG40b3E1bxwM1uwfBKLk64uH2l DG8eRkV/HwnBNOlEJfWcsz6kaHWYjbjt+90nFsoRVx/gCazURakEQ9k8vJmSFGxDI/dS xwX9LG0MKi/KsHC1kqBGUcEFyJ/CDzJZNXAoVaCvYFIRKMkyjXecBMiFGhsJ5s32dahB 4Cjg== X-Gm-Message-State: AOJu0YwWcx9nIJmyuqyI/0feaSluUo3BGTki9TdHGF+yAqKKe0xTR1Fv S8gtPZGUtcXEA5uTAvwdogq2mQ== X-Received: by 2002:a05:6a20:2587:b0:137:c971:6a0c with SMTP id k7-20020a056a20258700b00137c9716a0cmr852950pzd.31.1691183238826; Fri, 04 Aug 2023 14:07:18 -0700 (PDT) Received: from tictac2.mtv.corp.google.com ([2620:15c:9d:2:e186:e5d2:e60:bad3]) by smtp.gmail.com with ESMTPSA id n22-20020aa78a56000000b0068664ace38asm2037584pfa.19.2023.08.04.14.07.17 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 04 Aug 2023 14:07:18 -0700 (PDT) From: Douglas Anderson <dianders@chromium.org> To: dri-devel@lists.freedesktop.org, Maxime Ripard <mripard@kernel.org> Cc: Linus Walleij <linus.walleij@linaro.org>, Douglas Anderson <dianders@chromium.org>, Daniel Vetter <daniel@ffwll.ch>, David Airlie <airlied@gmail.com>, Neil Armstrong <neil.armstrong@linaro.org>, Sam Ravnborg <sam@ravnborg.org>, linux-kernel@vger.kernel.org Subject: [RFC PATCH 03/10] drm/panel: otm8009a: Don't double check prepared/enabled Date: Fri, 4 Aug 2023 14:06:06 -0700 Message-ID: <20230804140605.RFC.3.I6a4a3c81c78acf5acdc2e5b5d936e19bf57ec07a@changeid> X-Mailer: git-send-email 2.41.0.585.gd2178a4bd4-goog In-Reply-To: <20230804210644.1862287-1-dianders@chromium.org> References: <20230804210644.1862287-1-dianders@chromium.org> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit 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,URIBL_BLOCKED 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: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1773340315425278102 X-GMAIL-MSGID: 1773340315425278102 |
Series |
drm/panel: Remove most store/double-check of prepared/enabled state
|
|
Commit Message
Doug Anderson
Aug. 4, 2023, 9:06 p.m. UTC
As talked about in commit d2aacaf07395 ("drm/panel: Check for already
prepared/enabled in drm_panel"), we want to remove needless code from
panel drivers that was storing and double-checking the
prepared/enabled state. Even if someone was relying on the
double-check before, that double-check is now in the core and not
needed in individual drivers.
For the "otm8009a" driver we fully remove the storing of the "enabled"
state and we remove the double-checking, but we still keep the storing
of the "prepared" state since the backlight code in the driver checks
it. This backlight code may not be perfectly safe since there doesn't
appear to be sufficient synchronization between the backlight driver
(which userspace can call into directly) and the code that's
unpreparing the panel. However, this lack of safety is not new and can
be addressed in a future patch.
Signed-off-by: Douglas Anderson <dianders@chromium.org>
---
From quick inspection, I think the right way to handle the backlight
properly is:
1. Start calling backlight_get_brightness() instead of directly
getting "bd->props.brightness" and bd->props.power. This should
return 0 for a disabled (or blanked or powered off) backlight.
2. Cache the backlight level in "struct otm8009a"
3. If the backlight isn't changing compared to the cached value, make
otm8009a_backlight_update_status() a no-op.
4. Remove the caching of the "prepared" value.
That should work and always be safe because we always enable/disable
the backlight in the panel's enable() and disable() functions. The
backlight core has proper locking in this case. A disabled backlight
will always return a level of 0 which will always make the backlight's
update_status a no-op when the panel is disabled and keep us from
trying to talk to the panel when it's off. Userspace can't directly
cause a backlight to be enabled/disabled, it can only affect the other
blanking modes.
.../gpu/drm/panel/panel-orisetech-otm8009a.c | 17 -----------------
1 file changed, 17 deletions(-)
Comments
Hi, On Fri, Aug 4, 2023 at 2:07 PM Douglas Anderson <dianders@chromium.org> wrote: > > As talked about in commit d2aacaf07395 ("drm/panel: Check for already > prepared/enabled in drm_panel"), we want to remove needless code from > panel drivers that was storing and double-checking the > prepared/enabled state. Even if someone was relying on the > double-check before, that double-check is now in the core and not > needed in individual drivers. > > For the "otm8009a" driver we fully remove the storing of the "enabled" > state and we remove the double-checking, but we still keep the storing > of the "prepared" state since the backlight code in the driver checks > it. This backlight code may not be perfectly safe since there doesn't > appear to be sufficient synchronization between the backlight driver > (which userspace can call into directly) and the code that's > unpreparing the panel. However, this lack of safety is not new and can > be addressed in a future patch. > > Signed-off-by: Douglas Anderson <dianders@chromium.org> > --- > From quick inspection, I think the right way to handle the backlight > properly is: > 1. Start calling backlight_get_brightness() instead of directly > getting "bd->props.brightness" and bd->props.power. This should > return 0 for a disabled (or blanked or powered off) backlight. > 2. Cache the backlight level in "struct otm8009a" > 3. If the backlight isn't changing compared to the cached value, make > otm8009a_backlight_update_status() a no-op. > 4. Remove the caching of the "prepared" value. > > That should work and always be safe because we always enable/disable > the backlight in the panel's enable() and disable() functions. The > backlight core has proper locking in this case. A disabled backlight > will always return a level of 0 which will always make the backlight's > update_status a no-op when the panel is disabled and keep us from > trying to talk to the panel when it's off. Userspace can't directly > cause a backlight to be enabled/disabled, it can only affect the other > blanking modes. Note: I'm not planning to take on the cleanup of making the backlight of this driver work better. Ideally someone who uses / maintains the affected hardware could give it a shot. > .../gpu/drm/panel/panel-orisetech-otm8009a.c | 17 ----------------- > 1 file changed, 17 deletions(-) In response to the cover letter [1], I proposed landing patches #1-#3 directly from here while we resolve the issues talked about in response to patch #4 [2]. I didn't hear any complaints, so I took Linus W's review tag from the cover letter and pushed this to drm-misc-next. 1e0465eb16a4 drm/panel: otm8009a: Don't double check prepared/enabled [1] https://lore.kernel.org/r/CAD=FV=UFuUsrrZmkL8_RL5WLvkJryDwRSAy_PWTa-hX_p0dF+Q@mail.gmail.com [2] https://lore.kernel.org/r/20230804140605.RFC.4.I930069a32baab6faf46d6b234f89613b5cec0f14@changeid/
diff --git a/drivers/gpu/drm/panel/panel-orisetech-otm8009a.c b/drivers/gpu/drm/panel/panel-orisetech-otm8009a.c index 898b892f1143..93183f30d7d6 100644 --- a/drivers/gpu/drm/panel/panel-orisetech-otm8009a.c +++ b/drivers/gpu/drm/panel/panel-orisetech-otm8009a.c @@ -70,7 +70,6 @@ struct otm8009a { struct gpio_desc *reset_gpio; struct regulator *supply; bool prepared; - bool enabled; }; static const struct drm_display_mode modes[] = { @@ -267,9 +266,6 @@ static int otm8009a_disable(struct drm_panel *panel) struct mipi_dsi_device *dsi = to_mipi_dsi_device(ctx->dev); int ret; - if (!ctx->enabled) - return 0; /* This is not an issue so we return 0 here */ - backlight_disable(ctx->bl_dev); ret = mipi_dsi_dcs_set_display_off(dsi); @@ -282,8 +278,6 @@ static int otm8009a_disable(struct drm_panel *panel) msleep(120); - ctx->enabled = false; - return 0; } @@ -291,9 +285,6 @@ static int otm8009a_unprepare(struct drm_panel *panel) { struct otm8009a *ctx = panel_to_otm8009a(panel); - if (!ctx->prepared) - return 0; - if (ctx->reset_gpio) { gpiod_set_value_cansleep(ctx->reset_gpio, 1); msleep(20); @@ -311,9 +302,6 @@ static int otm8009a_prepare(struct drm_panel *panel) struct otm8009a *ctx = panel_to_otm8009a(panel); int ret; - if (ctx->prepared) - return 0; - ret = regulator_enable(ctx->supply); if (ret < 0) { dev_err(panel->dev, "failed to enable supply: %d\n", ret); @@ -341,13 +329,8 @@ static int otm8009a_enable(struct drm_panel *panel) { struct otm8009a *ctx = panel_to_otm8009a(panel); - if (ctx->enabled) - return 0; - backlight_enable(ctx->bl_dev); - ctx->enabled = true; - return 0; }