Received: by 2002:a05:6a10:22f:0:0:0:0 with SMTP id 15csp1241133pxk; Fri, 4 Sep 2020 04:41:28 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzOvb8P4H87iIPHlRcamCV5zRUo1Kc2yMpwMtKKKVpI+gJqXQANLLHWYxBxJDzOP5wbH8vY X-Received: by 2002:a17:906:375a:: with SMTP id e26mr6790754ejc.552.1599219688044; Fri, 04 Sep 2020 04:41:28 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1599219688; cv=none; d=google.com; s=arc-20160816; b=RzQ4iJPpdO7CIbbQeL03wQCwLm5jh53DvfWgwJNRtxOMFLiDBqu9qfk6ajdeNrbRZs oUpZu5Qocnie4U7xGdaR6UiJz5/gxYW+vMqUSvQ+XGOASS5k8WCNbUavVApIIPhnPArQ nmc+JWdQzTKncNuh2gOskWNr5zNHvHAdE/dRJ5U+8OJk/Cc77xYxZGEoxHg0LbQo5iUc C4jHBelh99XvXYvYmFH/PG1jsF1zlwokn/aCTL5GgyBfjo2OxyXbhj1GOMH22t/3W7wV H9fXm+L6dYGTI8yUxSZjh1uLpsU0BAJV+4tu4cm50tijg79irFFBhGTBEXtcO6AaIkVk L78A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date :dkim-signature; bh=zBTRNjzB5mPzhMVyXQWz7MNu1O+zSDEFEFHnoBhDYZc=; b=F2/4t9Y9avtwS9AsrFt6zzM5M5otdlKagE+b48zkLKBn48rN19UTXsOb4/8wyqSDhC +GpgxeMxiqVXQQn7m30RH7zKtDPjN3yT9mnkNLbeFyFWAxVFkhbNVTaNjDHG6qT5kGk0 lyt/5YV5bpCBN8m9fpODIc+NiRCspQsNfwh/LN/tz1RkAx4v248NNNWDmUsskHAk1QsN 8W95sQnjcXKWi2KhjPaqPLE2ls7eRa3Rn8QRrT2rKXlXBVvvmFJVKguy82DHeSqz90b6 xwnOC4q0KNEN9cFm+5MJCAyYuBornjScKetWwsidiIeONfzXFbLvhfvukujE1gx4Yh37 CAmw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b="WtXR/0sl"; 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=linaro.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id df7si4130291edb.182.2020.09.04.04.41.05; Fri, 04 Sep 2020 04:41:28 -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=@linaro.org header.s=google header.b="WtXR/0sl"; 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=linaro.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728588AbgIDLjz (ORCPT + 99 others); Fri, 4 Sep 2020 07:39:55 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:33836 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1730043AbgIDLif (ORCPT ); Fri, 4 Sep 2020 07:38:35 -0400 Received: from mail-wm1-x344.google.com (mail-wm1-x344.google.com [IPv6:2a00:1450:4864:20::344]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 27E1EC061245 for ; Fri, 4 Sep 2020 04:38:27 -0700 (PDT) Received: by mail-wm1-x344.google.com with SMTP id a65so5754765wme.5 for ; Fri, 04 Sep 2020 04:38:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=zBTRNjzB5mPzhMVyXQWz7MNu1O+zSDEFEFHnoBhDYZc=; b=WtXR/0sltULRHVCaC8HhLbBR6SIHL5piDWOv3CHxtHHHPnSqQYEf25q1QTSFYE5zf7 gdWSs8a+2WHWhbJHSIBA1GkGmShfElAMK7OVV9CUYUBgk9R6/BkndkZ+llRZRKOCjgdY QuYRCjx+JGzaomOmsTvuvLaLt/FWRjGb6H0U7xOWxh8TQpnhDUykaRdcZGX2lifAbDKo 3t+uVzuMJydLR8u7eonGsIYYfPje0wKasCBg1diomCO/dcYyU5MfVzqY0uXMkdoXk2Yu cdoSyzhfjwQ5WxrXfjAgoTvLYoHlW8zWTZ5egE9QOdCcVOW04/EMMiJX781OkiYDi2UO Oahw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=zBTRNjzB5mPzhMVyXQWz7MNu1O+zSDEFEFHnoBhDYZc=; b=CyH1OPg3eqKvyR6XjZTNLiAD5EPvrlMVwnCjauSIAQQB5ChBJ+34v/i9xepZWbhnbf DoLR+u5+5AVs8spAqkH3FFB2nCyH9T+Xkizjv16RohGyXuWhY/yqCKBe2PXzjCTM/enz suNk9FCotzYYqT9pJyCcBONWAsRBJT7Flna4AjTcKAjYr5QKce0+PF6Yvc2KBWfCrRAS LetpNYj9JSE5H3UQcXdQE9x3jGQSwZT3rMZkctu2D/gepdLT4FSfCsYPb+U9+KxtzcW0 c5qFFIi5Ae5EAGiG69R46koOgGxwJG1MhZ7thKwO2HoIGsX+t/OqevaSDTZ0TEAJWYea qBTA== X-Gm-Message-State: AOAM531DuXt8cSKUhSnIfhsh4HgdkPEdiok9DGohXu3dVZxcuw5nxQTj nqzMZoDE6fXKVS2Mz3gGEGwcWA== X-Received: by 2002:a1c:1b8f:: with SMTP id b137mr7618389wmb.151.1599219505621; Fri, 04 Sep 2020 04:38:25 -0700 (PDT) Received: from holly.lan (cpc141214-aztw34-2-0-cust773.18-1.cable.virginm.net. [86.9.19.6]) by smtp.gmail.com with ESMTPSA id j14sm11125993wrr.66.2020.09.04.04.38.24 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 04 Sep 2020 04:38:24 -0700 (PDT) Date: Fri, 4 Sep 2020 12:38:22 +0100 From: Daniel Thompson To: Alexandru Stan Cc: Thierry Reding , Uwe =?utf-8?Q?Kleine-K=C3=B6nig?= , Lee Jones , Jingoo Han , Bartlomiej Zolnierkiewicz , Heiko Stuebner , Rob Herring , Matthias Kaehlcke , Douglas Anderson , Enric Balletbo i Serra , dri-devel@lists.freedesktop.org, linux-fbdev@vger.kernel.org, linux-kernel@vger.kernel.org, linux-pwm@vger.kernel.org Subject: Re: [PATCH 2/3] backlight: pwm_bl: Artificially add 0% during interpolation Message-ID: <20200904113822.xoyt4w5x7vwvh7cr@holly.lan> References: <20200721042522.2403410-1-amstan@chromium.org> <20200720212502.2.Iab4d2192e4cf50226e0a58d58df7d90ef92713ce@changeid> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200720212502.2.Iab4d2192e4cf50226e0a58d58df7d90ef92713ce@changeid> Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Jul 20, 2020 at 09:25:21PM -0700, Alexandru Stan wrote: > Some displays need the low end of the curve cropped in order to make > them happy. In that case we still want to have the 0% point, even though > anything between 0% and 5%(example) would be skipped. For backlights it is not defined that 0 means off and, to be honest, 0 means off is actually rather weird for anything except transflexive or front lit reflective displays[1]. There is a problem on several systems that when the backlight slider is reduced to zero you can't see the screen properly to turn it back up. This patch looks like it would make that problem worse by hurting systems with will written device trees. There is some nasty legacy here: some backlight displays that are off at zero and that sucks because userspace doesn't know whether zero is off or lowest possible setting. Nevertheless perhaps a better way to handle this case is for 0 to map to 5% power and for the userspace to turn the backlight on/off as final step in an animated backlight fade out (and one again for a fade in). Daniel. > > Signed-off-by: Alexandru Stan > --- > > drivers/video/backlight/pwm_bl.c | 8 ++++++++ > 1 file changed, 8 insertions(+) > > diff --git a/drivers/video/backlight/pwm_bl.c b/drivers/video/backlight/pwm_bl.c > index 5193a72305a2..b24711ddf504 100644 > --- a/drivers/video/backlight/pwm_bl.c > +++ b/drivers/video/backlight/pwm_bl.c > @@ -349,6 +349,14 @@ static int pwm_backlight_parse_dt(struct device *dev, > /* Fill in the last point, since no line starts here. */ > table[x2] = y2; > > + /* > + * If we don't start at 0 yet we're increasing, assume > + * the dts wanted to crop the low end of the range, so > + * insert a 0 to provide a display off mode. > + */ > + if (table[0] > 0 && table[0] < table[num_levels - 1]) > + table[0] = 0; > + > /* > * As we use interpolation lets remove current > * brightness levels table and replace for the > -- > 2.27.0