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 Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 418F9C43334 for ; Mon, 18 Jul 2022 11:18:20 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234465AbiGRLST (ORCPT ); Mon, 18 Jul 2022 07:18:19 -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-Google-Smtp-Source: AGRyM1sDQntCUf7aWlvIzBrAp3ngAMq6sCK0MNxJ0IaoTAwyexPRWMVJcAdASNSTm/k1fe6tXf81WYvadsLxzbGsFLI= 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" Precedence: bulk List-ID: X-Mailing-List: linux-leds@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 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 Received: from gabe.freedesktop.org (gabe.freedesktop.org [131.252.210.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id F37C9C433EF for ; Mon, 18 Jul 2022 11:18:19 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 4D16CB0830; Mon, 18 Jul 2022 11:18:19 +0000 (UTC) Received: from mail-qt1-x82e.google.com (mail-qt1-x82e.google.com [IPv6:2607:f8b0:4864:20::82e]) by gabe.freedesktop.org (Postfix) with ESMTPS id DF978B0823 for ; Mon, 18 Jul 2022 11:18:17 +0000 (UTC) Received: by mail-qt1-x82e.google.com with SMTP id r24so1822263qtx.6 for ; 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=ygshENGCqXYI4Ho5wVg4qFPuitFcK4s4GAzyTtAGwivBF2EmpMJIa6LRRW2goUJiip dO0WA/2MfBiYHSrOrZtZYi7N+5LnKU0+aVlOD4PliJPzXWSm1pl3Tg4hoIlkDzXhp/Jm wui16Kge0ZrXSlr8QunY6fwlj2PUdssEvvBbzXeX0OyBk/dpxgz/aZMF/ujtNYTbFLMB TwtngvAt78qkio43b3jO3gUXs+oO3vdGQejdHgtEcQX5aFFEpky5i9+/Ai1UjLP+MWZN 7oem84M4+RWbyDg38r+WPmsBQD32IzsszcjXK5D78ya3BP/somm7y4IEIfkUTclEzz1G /wCQ== X-Gm-Message-State: AJIora/IaSkVo8KtUVt3m92UH8nlCOB6nE6JEABE2NcpXyYtQsKyvCcs 2O9G+OSNsw4qgZuLlp1f+18gRWiEotG6Siv8v9k= X-Google-Smtp-Source: AGRyM1sDQntCUf7aWlvIzBrAp3ngAMq6sCK0MNxJ0IaoTAwyexPRWMVJcAdASNSTm/k1fe6tXf81WYvadsLxzbGsFLI= 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 Content-Type: text/plain; charset="UTF-8" X-BeenThere: dri-devel@lists.freedesktop.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Direct Rendering Infrastructure - Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: "open list:FRAMEBUFFER LAYER" , "Krogerus, Heikki" , Krzysztof Kozlowski , Alice Chen , linux-iio , dri-devel , Liam Girdwood , ChiYuan Huang , Pavel Machek , Lee Jones , Linux LED Subsystem , Daniel Thompson , Helge Deller , Rob Herring , Chunfeng Yun , Guenter Roeck , devicetree , Linux PM , szuni chen , Mark Brown , "moderated list:ARM/Mediatek SoC support" , Matthias Brugger , linux-arm Mailing List , Jingoo Han , USB , Sebastian Reichel , Linux Kernel Mailing List , ChiaEn Wu , Greg Kroah-Hartman , Jonathan Cameron Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" 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 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 Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 7EF97C433EF for ; Mon, 18 Jul 2022 11:19:51 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:Cc:To:Subject:Message-ID:Date:From: In-Reply-To:References:MIME-Version:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=a37ZGVrCG+DJj/I7fzSYEVwnnGAx92uEUY1m/y3wshI=; b=Uepmk69oMgWdfy IuC3HbZSDzMSVsca0BKMxJNMxlXvnoHiKSNEOKnz9PrLfLIhTZbu0GntgCP55uKZ1lryaUPr9cN5g 5H/4jrcPb/THBNMGoAHtg7AV4VV2U6rJHOrHQYd9UHFHc3m0tUZqo3OGwX2RsfHFpJKa9S2R/y8ne Shcw7krHvYICsdkdnKTKK3mLyV6EdQ55toAZg49nhHHoZI3PdU8b4+NvoSBPWZowhO2dWsnhnRm/R 3igFyU6h4l8i8gaoS6F32Jr6k7//dIQYTkCsaWkaJP/F9BJkxRULPDLT7Bf2feZP7INBjQhhLn+NP 8ED/wdQM4SI5F2x7p4Xw==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1oDOla-00CkrB-PE; Mon, 18 Jul 2022 11:18:22 +0000 Received: from mail-qt1-x832.google.com ([2607:f8b0:4864:20::832]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1oDOlW-00Ckob-Te; Mon, 18 Jul 2022 11:18:20 +0000 Received: by mail-qt1-x832.google.com with SMTP id h22so8438332qta.3; 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=O1VjFTOCTBCibwbFHmBxoioM8zmM13PRwwqLSMkJMv5l9SglgUvJG2fHatFnNfDmjb 7hgwlvlBTQEjzKwbrHmlOwVbGCEviaM0NIEgG/qlWV89DooEqLJXTFbJwH9arXQXOKGu erMzDeGThYzC30qr9YU4Bp9fsSf/y7w3eJTgQqcAHhxbFEv0pbT2pnlUULQJzkx9CIaR UYGo/jpTbZxD9KWtPmQwzjDwOC5b/8Z//qyw0mY0J1axLuDphmjSnFj7kgqw+7kipt4G sUVD9xk64TwB7NHXBqshCfDmM7Yi3X/7owbdp2+xhFSC05WpJS0PGuTU6XApTvWPUhAX hftA== X-Gm-Message-State: AJIora/ff7xbe7IyBqL6Z0KcWfbC3YLwqOfTwUPtqigB38Ve3J+uxxai PkQ504PQ0tb5ExMx0h1VIsGGqWAd9Oq+fs3mPz8Gq3aZdu4= X-Google-Smtp-Source: AGRyM1sDQntCUf7aWlvIzBrAp3ngAMq6sCK0MNxJ0IaoTAwyexPRWMVJcAdASNSTm/k1fe6tXf81WYvadsLxzbGsFLI= 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 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20220718_041818_996376_F4DAF2FA X-CRM114-Status: GOOD ( 36.33 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.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 _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel