Received: by 2002:ad5:4acb:0:0:0:0:0 with SMTP id n11csp3215773imw; Mon, 18 Jul 2022 04:21:17 -0700 (PDT) X-Google-Smtp-Source: AGRyM1v2Uh17TKUS6uBd/NGehBBM9rZjohN87bCtCr2Rqo67uV30OYoPWgMx8sMbRNutlKwPN1Xr X-Received: by 2002:aca:2302:0:b0:33a:721b:8095 with SMTP id e2-20020aca2302000000b0033a721b8095mr2667142oie.70.1658143276934; Mon, 18 Jul 2022 04:21:16 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1658143276; cv=none; d=google.com; s=arc-20160816; b=yvl9+9fRTbCTNPHyy60EQ/wJcwMA/vyaORthwU0Mg8cRv+CMgiso/h6BCRtCeafvgh yOyEeuVTpYEoBexglNUwCd2DAt7HWhosTmpdwzKUchjOgzKkZYyNTSxXawcTdKLLGI+p wAjKdqi88RjFl6BEPdQJjf/bBLTmxNxfYR+gnz7gdMVaIxsr91L6rq5ro/uZomHnRxjE AL/8ZnRikTvzkWLEBWlaHAvIRlEbBUMSwCZqr2TAlzf6sGWme6pp/z/UUxv0dRN7xAWC 0YWEr15pYnLgIuTLIk5w0Ka/yP/ydfGCneMnyq1Rsqwe2EObwSKCMTUQ0eOzZAfJOSju K74w== 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=wSoYENXBgH2mwK4hdRwcr5ZngBoL0AeSrBZrHAlbPeQ=; b=ApdqonOsS6gP9p+BozliPPnM5fd0VRmXjLrOlyaCa8cqi3MWkwMaGPZ7kAOjJtBtSv UQTx89MSYQMxvz8aXGb1nyEZ8TayP1OAjZWitwjE2iCgxp2Ns9xvuSe15veezZ1dq0GO Fpzur3ImK4rjN+lhJFn9YXm5rb5D3so7waR4zH3+LopgFR+HVbKbge6/qj0WMR6o8pSF amOETYyDCWLRkNKprrVY3L4zZmSRyWCTcNYWiZtwQshvAmFU0aRcLWu4GPe5+ffPmAbj yW+02V8M0iWZRnxxkRfmDPvZq+/PDLTjsT+4wFYNtvWhB6pjupz6Qs1Zq1WdB2AjpRW8 N08Q== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20210112 header.b=qFnFWPwv; 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=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id ep20-20020a056870a99400b0010490c6b5a8si7758015oab.29.2022.07.18.04.21.03; Mon, 18 Jul 2022 04:21:16 -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=@gmail.com header.s=20210112 header.b=qFnFWPwv; 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=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234496AbiGRLSU (ORCPT + 99 others); Mon, 18 Jul 2022 07:18:20 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:44184 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234213AbiGRLSS (ORCPT ); Mon, 18 Jul 2022 07:18:18 -0400 Received: from mail-qt1-x82f.google.com (mail-qt1-x82f.google.com [IPv6:2607:f8b0:4864:20::82f]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id B1D2F1180B; Mon, 18 Jul 2022 04:18:17 -0700 (PDT) Received: by mail-qt1-x82f.google.com with SMTP id r21so7734860qtn.11; Mon, 18 Jul 2022 04:18:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=wSoYENXBgH2mwK4hdRwcr5ZngBoL0AeSrBZrHAlbPeQ=; b=qFnFWPwvGVggO9eAAgTTMi5N3kU74UfugZ/F1ND8Dh1XwEYNQq9hleridz+UuErbjp kKXke5m5utIeYESJxdI+Imw1dN7Ky712JivV5EepwVudgfHjmTqzT/4Csy8a5PRWaYcW WT7WNRwPzbR88elpVuCiYFy314nf03iGRthvnSl47bKymr5iw2ISiSCilphKmc3sjDBm wiODnzpQ5ZhUPmt72MGydEbUEk8Tl3V01TfyuGjdP3zZ6dMAa1QHvvhfxlrb1Fhq/iC3 p3s1kljCg7uX6D1BpJ/6XC9U0bCN4LfKIpfi4lFkm26bo4VkK/Gcyeu4o/iFLsYdoMKG BZIw== 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=wSoYENXBgH2mwK4hdRwcr5ZngBoL0AeSrBZrHAlbPeQ=; b=nAuIO1vKX1NU9KD9WZt/ADfLuy3A7qszMDimDHxlqaZNKiNBICNqSGdJf+KGlJ5GSN 9jh/83KeH8d2xYTZTvRjMNgiuT6YP5YpuhdFtkdRuu9Sr4swdAxdqWrrW0JK5QZOPsmo OX9eHtVoHgHJOffb81gvsfVkCk59WZxOileVjnt59Xn7cMKfm891XfkwdMi4aBhXSSTN byOM2cGxeeECrES+rL/9VCtZuVq5NbQ1h3N0SY8AisBDucOJnGbsTGsqUUZT80Ccb67P siMwC6B2fOCFxGpNVI3O95ngzH1rx8AVT4W3ezP5oLlSSGltmAT4t0YjexC8AoY++Jlu lPcA== X-Gm-Message-State: AJIora8nZVdcLVY+wrYat7Q6QmyBIIjKQ98pRxZSPuAJFPFs4Al58ljV DxLHvxVoX5QrxQ3MRFDskLsn1UhrV9EXQMg7Y8M= X-Received: by 2002:ac8:5a8c:0:b0:31d:2826:d14f with SMTP id c12-20020ac85a8c000000b0031d2826d14fmr20168056qtc.198.1658143096830; Mon, 18 Jul 2022 04:18:16 -0700 (PDT) MIME-Version: 1.0 References: <20220715112607.591-1-peterwu.pub@gmail.com> <20220715112607.591-14-peterwu.pub@gmail.com> <20220715162913.5ewxwhv6jtdgt3c2@maple.lan> In-Reply-To: From: ChiaEn Wu Date: Mon, 18 Jul 2022 19:17:40 +0800 Message-ID: Subject: Re: [PATCH v5 13/13] video: backlight: mt6370: Add MediaTek MT6370 support To: AngeloGioacchino Del Regno Cc: Daniel Thompson , Lee Jones , Jingoo Han , Pavel Machek , Rob Herring , Krzysztof Kozlowski , Matthias Brugger , Sebastian Reichel , Chunfeng Yun , Greg Kroah-Hartman , Jonathan Cameron , Lars-Peter Clausen , Liam Girdwood , Mark Brown , Guenter Roeck , "Krogerus, Heikki" , Helge Deller , ChiaEn Wu , Alice Chen , ChiYuan Huang , dri-devel , Linux LED Subsystem , devicetree , linux-arm Mailing List , "moderated list:ARM/Mediatek SoC support" , Linux Kernel Mailing List , Linux PM , USB , linux-iio , "open list:FRAMEBUFFER LAYER" , szuni chen Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM, RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS 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: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Jul 18, 2022 at 4:27 PM AngeloGioacchino Del Regno wrote: > > >> > >> Hello ChiaEn, > >> > >> I propose to move this one to drivers/leds (or drivers/pwm) and, instead of > >> registering a backlight device, register a PWM device. > >> > >> This way you will be able to reuse the generic backlight-pwm driver, as you'd > >> be feeding the PWM device exposed by this driver to the generic one: this will > >> most importantly make it easy to chain it with MTK_DISP_PWM (mtk-pwm-disp) > >> with a devicetree that looks like... > > > > Out of interest, does MT6370 have the same structure for backlights as the prior > > systems using mtk-pwm-disp or was mtk-pwm-disp simply a normal(-ish) PWM > > that relied on something on the board for all the constant current > > driver hardware? > > > > > > As per my understanding, mtk-pwm-disp is chained to other multimedia features of > the display block of MediaTek SoCs, such as the AAL (adaptive ambient light), > CABC (content adaptive backlight control) etc, other than being a normal(ish) > PWM... that's the reason of my request. > > Moreover, in the end, this PMIC's backlight controller is just a "fancy" PWM > controller, with OCP/OVP. > > >> > >> pwmleds-disp { > >> compatible = "pwm-leds"; > >> > >> disp_led: disp-pwm { > >> label = "backlight-pwm"; > >> pwms = <&pwm0 0 500000>; > >> max-brightness = <1024>; > >> }; > >> }; > >> > >> backlight_lcd0: backlight { > >> compatible = "led-backlight"; > >> leds = <&disp_led>, <&pmic_bl_led>; > >> default-brightness-level = <300>; > >> }; > > > > I think this proposal has to start with the devicetree bindings rather > > than the driver. Instead I think the question is: does this proposal > > result in DT bindings that better describe the underlying hardware? > > > > From how I understand it - yes: we have a fancy PWM (&pwm0) that we use > to control display backlight (backlight-pwm)... > > Obviously, here we're not talking about OLEDs, but LCDs, where the backlight > is made of multiple strings of WhiteLED (effectively, a "pwm-leds" controlled > "led-backlight"). > > Using PWM will also allow for a little more fine-grained board specific > configuration, as I think that this PMIC (and/or variants of it) will be > used in completely different form factors: I think that's going to be both > smartphones and tablets/laptops... and I want to avoid vendor properties > to configure the PWM part in a somehow different way. > > > This device has lots of backlight centric features (OCP, OVP, single > > control with multiple outputs, exponential curves, etc) and its not > > clear where they would fit into the "PWM" bindings. > > > > For OCP and OVP, the only bindings that fit would be regulators, but that's > not a regulator... and that's about it - I don't really have arguments for > that. > > What I really want to see here is usage of "generic" drivers like led_bl > and/or pwm_bl as to get some "standardization" around with all the benefits > that this carries. > > > Come to think of it I'm also a little worried also about the whole linear > > versus exponential curve thing since I thought LED drivers were required > > to use exponential curves. > > > > That probably depends on how the controller interprets the data, I guess, > but I agree with you on this thought. Hi Angelo, MT6370 is just a SubPMIC, not an SoC, and is applied in cellular telephones, tablet PCs, and portable instruments. And the PWM mode of the MT6370 backlight driver is optional, and not must be enabled. From our perspective, this MT6370 backlight driver is not the same as mtk-pwm-disp related driver. Thanks! > > Regards, > Angelo -- Best Regards, ChiaEn Wu