From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-9.8 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, INCLUDES_PATCH,MAILING_LIST_MULTI,SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 065FEC55ABD for ; Wed, 11 Nov 2020 00:48:33 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id ABC7821741 for ; Wed, 11 Nov 2020 00:48:32 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=chromium.org header.i=@chromium.org header.b="QfIsIHzj" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1732446AbgKKAsb (ORCPT ); Tue, 10 Nov 2020 19:48:31 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:44582 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1732450AbgKKAsb (ORCPT ); Tue, 10 Nov 2020 19:48:31 -0500 Received: from mail-vs1-xe41.google.com (mail-vs1-xe41.google.com [IPv6:2607:f8b0:4864:20::e41]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 45EBCC0613D3 for ; Tue, 10 Nov 2020 16:48:31 -0800 (PST) Received: by mail-vs1-xe41.google.com with SMTP id l22so220122vsa.4 for ; Tue, 10 Nov 2020 16:48:31 -0800 (PST) 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=DwI3PFSKWVnaqeshY41Xp/YVBg2cD76OjiJIiFh3rNI=; b=QfIsIHzjHTjAr/jTdIRSiD+ZkEfLnev1EHOTrRrDDTB7WurSHmLapfGiBTNJvwGtWM n0cecZqV6gOBimx3dJHYoejdFvYV+lM1U9yYeRQ2K3KmHrsUZUWvTeK29NnQ/CF3BEKI m3e422SOkDPN1XTyRtLgENxmZHEnNWrVPZYPw= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=DwI3PFSKWVnaqeshY41Xp/YVBg2cD76OjiJIiFh3rNI=; b=S/LIc7BxxhOKG6Iwc+k2K7GU+XEy5TFwYpMCKxdpQU/KQSk0X9W+BT02MEwiTfgZzE 2c9LCG+giM8i4shxsbEeDtHJYJAygCp9mLgAD/j+yQtQg8rwqVKzVAe+1uMWyTvBIcxP zOuHrFhgAGnWmBwLQuFmSb1iU2ILMJ+VWsAKKGBGfUAJXWyeyeC1wRcPe6Fr8Pnqc7P4 0c9IXYn8zAYWbBC+6/FIkv33akFjkbPVipLUgEMEduWz62smfiBKB5q+TDxTSIlhNDb7 PFJ44Zd0zsaJx3fpTXMvSN3ol4a96dXC2MsMH2dPloyN+dnJ9EiUUagDplVOW+sqJmsr V46Q== X-Gm-Message-State: AOAM533gtaUv1IwUNvI9gZHXE7bhimsHw0Bs66z2ZuYHHVev4MDtKq08 dkgkxnPS+hZnSGtJ9BG9OumNFRxnlkRPDw== X-Google-Smtp-Source: ABdhPJzmvNLvKiDXHLRrWFHer6bY0DfwI2t5S7tVvTZtFk/OesktUktqUJrKT/74OSPLlv/3yo9EQg== X-Received: by 2002:a05:6102:3222:: with SMTP id x2mr3028406vsf.20.1605055709973; Tue, 10 Nov 2020 16:48:29 -0800 (PST) Received: from mail-ua1-f53.google.com (mail-ua1-f53.google.com. [209.85.222.53]) by smtp.gmail.com with ESMTPSA id t188sm58620vkg.23.2020.11.10.16.48.28 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 10 Nov 2020 16:48:29 -0800 (PST) Received: by mail-ua1-f53.google.com with SMTP id 91so196172uar.5 for ; Tue, 10 Nov 2020 16:48:28 -0800 (PST) X-Received: by 2002:a9f:24eb:: with SMTP id 98mr11624331uar.90.1605055707756; Tue, 10 Nov 2020 16:48:27 -0800 (PST) MIME-Version: 1.0 References: <20200930223532.77755-1-bjorn.andersson@linaro.org> <20200930223532.77755-2-bjorn.andersson@linaro.org> <20201102170801.GI3151@builder.lan> In-Reply-To: <20201102170801.GI3151@builder.lan> From: Doug Anderson Date: Tue, 10 Nov 2020 16:48:16 -0800 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH 1/2] dt-bindings: drm/bridge: ti-sn65dsi86: Replace #pwm-cells To: Bjorn Andersson Cc: David Airlie , Daniel Vetter , Rob Herring , Andrzej Hajda , Neil Armstrong , Laurent Pinchart , Jonas Karlman , Jernej Skrabec , dri-devel , "open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" , LKML , linux-arm-msm Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: devicetree@vger.kernel.org Hi, On Mon, Nov 2, 2020 at 9:08 AM Bjorn Andersson wrote: > > On Fri 02 Oct 15:42 CDT 2020, Doug Anderson wrote: > > > Hi, > > > > On Wed, Sep 30, 2020 at 3:40 PM Bjorn Andersson > > wrote: > > > > > > While the signal on GPIO4 to drive the backlight controller indeed is > > > pulse width modulated its purpose is specifically to control the > > > brightness of a backlight. > > > > I'm a bit on the fence about this. I guess you're doing this because > > it avoids some -EPROBE_DEFER cycles in Linux? It does seem to have a > > few downsides, though. > > > > No, the reason for exposing a backlight is that while the thing > certainly is a PWM signal, the description of it and the registers > available to control it surely seems "backlight" to me. > > In particular No, the reason for exposing a backlight is that while > while the thing certainly is a PWM signal, the description of it and the > registers available to control it surely seems "backlight" to me. > > > 1. It means a bit of re-inventing the wheel. It's not a very big > > wheel, though, I'll give you. ...but it's still something. > > > > The main problem I saw with exposing this as a PWM was the fact that we > have both period and frequency to control... > > > 2. I'm not sure why you'd want to, but in theory one could use this > > PWM for some other purposes. It really is just a generic PWM. Your > > change prevents that. > > > > ...and in the even that you use it as a "generic" PWM I'd expect that > the specified period is related to the frequency of the signal. But the > period is documented to be related to the number of brightness steps of > the panel. I think the key here is that the "number of brightness steps of the panel" isn't really a thing that's worried about. At least in my experience, you can pretty much just use as many steps as you can represent based on your PWM hardware. If a panel happens to map some of those steps to the same brightness then it wouldn't be the end of the world, but in experience it's not really such a digital thing. If you choose 4096 steps then you likely get 4096 different brightness levels. If you choose 256 steps then you get 256 different brightness levels. Once you have "more than enough" steps then everything's pretty much fine. Looking at one random panel (just to get an idea of numbers), I see that it specifies: * min PWM Freq: 200 Hz * max PWM Freq: 10,000 Hz. ...and refclk is something between 12 MHz and 38.4 MHz, right? The bridge chip datasheet says: PWM_FREQ = REFCLK_FREQ / (PWM_PRE_DIV * BACKLIGHT_SCALE + 1) So let's see what we can do. I'm arguing that we want the client to be able to specify the PWM frequency and duty cycle and we'll do the job of picking the number of steps. We'll try for the most steps we can get (65535). I guess we need to solve for PWM_PRE_DIV : PWM_FREQ * (PWM_PRE_DIV * BACKLIGHT_SCALE + 1) = REFCLK_FREQ PWM_PRE_DIV * BACKLIGHT_SCALE + 1 = REFCLK_FREQ / PWM_FREQ PWM_PRE_DIV * BACKLIGHT_SCALE = REFCLK_FREQ / PWM_FREQ - 1 PWM_PRE_DIV = (REFCLK_FREQ / PWM_FREQ - 1) / BACKLIGHT_SCALE ...and solve for BACKLIGHT_SCALE: BACKLIGHT_SCALE = (REFCLK_FREQ / PWM_FREQ - 1) / PWM_PRE_DIV With 1000 Hz, 12 MHz refclk: PWM_PRE_DIV = DIV_ROUND_UP(12000000 / 1000 - 1, 65535) => 1 BACKLIGHT_SCALE = (12000000 / 1000 - 1) / 1 => 11999 With 1000 Hz, 38.4 MHz refclk: PWM_PRE_DIV = DIV_ROUND_UP(38400000 / 1000 - 1, 65535) => 1 BACKLIGHT_SCALE = (38400000 / 1000 - 1) / 1 => 38399 With 200 Hz, 38.4 MHz refclk: PWM_PRE_DIV = DIV_ROUND_UP(38400000 / 200 - 1, 65535) => 3 BACKLIGHT_SCALE = (38400000 / 200 - 1) / 3 => 63999 Now that you have BACKLIGHT_SCALE specified, then when someone tries to give you a duty cycle you just map it to the closest value you can make. Obviously you won't be able to perfectly make every exact duty cycle / period that a client requests, but that's true of all PWMs out there. The nice thing here is that (assuming my math is right) we should be getting nearly exactly the frequency that the client requested and that (in my mind) is what matters. You also get as many steps as possible which means that (with the PWM backlight API) you'll be able to get as close as possible to whatever a user requests. > > > Drop the #pwm-cells and instead expose a new property to configure the > > > granularity of the backlight PWM signal. > > > > > > Signed-off-by: Bjorn Andersson > > > --- > > > .../devicetree/bindings/display/bridge/ti,sn65dsi86.yaml | 9 ++++++--- > > > 1 file changed, 6 insertions(+), 3 deletions(-) > > > > > > diff --git a/Documentation/devicetree/bindings/display/bridge/ti,sn65dsi86.yaml b/Documentation/devicetree/bindings/display/bridge/ti,sn65dsi86.yaml > > > index f8622bd0f61e..e380218b4646 100644 > > > --- a/Documentation/devicetree/bindings/display/bridge/ti,sn65dsi86.yaml > > > +++ b/Documentation/devicetree/bindings/display/bridge/ti,sn65dsi86.yaml > > > @@ -66,9 +66,12 @@ properties: > > > 1-based to match the datasheet. See ../../gpio/gpio.txt for more > > > information. > > > > > > - '#pwm-cells': > > > - const: 1 > > > - description: See ../../pwm/pwm.yaml for description of the cell formats. > > > + ti,backlight-scale: > > > + description: > > > + The granularity of brightness for the PWM signal provided on GPIO4, if > > > + this property is specified. > > > + minimum: 0 > > > + maximum: 65535 > > > > A few issues here: > > > > 1. Maybe call this "num-steps" instead of backlight-scale. That's > > essentially what it is, right? Saying how many discrete steps you're > > allowing in your backlight? > > > > That would work, I had it as "max-brightness" for a while as well. But I > reverted to backlight-scale, because that's the name used in the > datasheet. > > I'm fine with whatever color of the shed though :) > > > 2. IMO you need the PWM frequency specified, since it can actually > > matter. NOTE: once you have the PWM frequency specified, you could > > imagine automatically figuring out what "num-steps" was. Really you'd > > want it to be the largest possible value you could achieve with your > > hardware at the specified frequency. There's no advantage (is there?) > > of providing fewer steps to the backlight client. > > > > I guess there's no problem in having a "num-steps" that is unrelated to > the number of brightness steps of the panel - but I did distinguish them > because the datasheet clearly does so. I think the datasheet talks about the number of steps that you will be able to make, but that doesn't mean it has to be what's exposed to clients of this driver, right? > > 3. Some backlights are specified inverted. It looks like this maps > > nicely to the bridge chip, which has a bit for it. Probably nice to > > expose this? > > > > Yes, that should be covered. > > > Of course, if we were just exposing the PWM directly to Linux we could > > just use the PWM backlight driver and it'd all magically work. ;-) > > > > Please help me figure out how to properly expose this in the PWM api and > I'll be happy to respin it using this - as you say my wheel does look > pretty similar... Hopefully the above seems sane to you? -Doug