Message ID | 20230925122609.78849-1-f.suligoi@asem.it |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a59:cae8:0:b0:403:3b70:6f57 with SMTP id r8csp1222217vqu; Mon, 25 Sep 2023 06:45:33 -0700 (PDT) X-Google-Smtp-Source: AGHT+IHm/2DHGZ/Dl2K2YDR+2qlnP1Z/yDgzraQ7w2TUHEqSg96cIQbG8z1Nhk/gytdDOvAU8hAT X-Received: by 2002:a05:6870:5623:b0:1d5:a377:f360 with SMTP id m35-20020a056870562300b001d5a377f360mr8087604oao.41.1695649532790; Mon, 25 Sep 2023 06:45:32 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1695649532; cv=pass; d=google.com; s=arc-20160816; b=uOYlx0Q9Dy4/ym3Uw070vpXRuGP4KyAg6ZQo6BjUt5In7CLTlGSx5Kx4+xvgJnJ5vH BqtgwclNUENg0SOBYY3Q40LL4fYKbW5TfC7XOIi+hpC1+kC+sMBC8U/wQXofjUAXh5E4 iyOszAAmrgQi2UWzHl2pVywa1Lciv6FjgnkkzICbdESkC3/ZONJBCxvDMak3P+ViaZXy oExZa0w2DQSBuPvwaeJzFd8HK88iwV5Jilvx3XQabtTB2I6NoG9dwzCG7La9Roz59Tfw mMpbb59SEAFBsLjC9zWHrnLQzn8U9aoto4WoIOwR4pn04MjR5eHXQIC2LSAX+TnjNc8l oA6Q== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :message-id:date:subject:cc:to:from:dkim-signature; bh=Uyd0o4JvcjRjUAoyozcpPdzoVoil7+iWwK4OY683CF8=; fh=F0ZNT2V9a0jCvOrOV6WQeuEVnKi3aPqlcw/+OipssmU=; b=UckLoIwK/p3VTeUD6h6UFsyFKNeWAiqGWUnZaf7zb5tCNMNn2Vdt4ngwZMJvWHISkS Hs8mFnFg8hwJv32qiuas8q+/YQRjVPpH4NDiu+Z8NfmUe318fthkO+uyPXWb9ZOENySt 2rOeoP0vWTSysEMZhSk0jSuV05Qtixe9qigVLTZCBS/FLvMI8sK+x+IcenP5T20Cv3Xv UaDt1jNpLmqvm4YxnizL3ltaxmu9wpO06rSfgqqUgBUmLkqC9KhWzGaJMjl+7rTlX+cY 4cf88nDdS/bQd3Ii2LgMKUoCyhQZ8vPaOfdQQInqq1eAQEQM85vqpwcVR2qTppeD3xfE 4qLw== ARC-Authentication-Results: i=2; mx.google.com; dkim=pass header.i=@asem.it header.s=selector1 header.b=KOXHQdAS; arc=pass (i=1); spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.32 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=asem.it Received: from agentk.vger.email (agentk.vger.email. [23.128.96.32]) by mx.google.com with ESMTPS id w2-20020a637b02000000b0056da0ae25a2si10107799pgc.32.2023.09.25.06.45.32 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 25 Sep 2023 06:45:32 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.32 as permitted sender) client-ip=23.128.96.32; Authentication-Results: mx.google.com; dkim=pass header.i=@asem.it header.s=selector1 header.b=KOXHQdAS; arc=pass (i=1); spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.32 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=asem.it Received: from out1.vger.email (depot.vger.email [IPv6:2620:137:e000::3:0]) by agentk.vger.email (Postfix) with ESMTP id D78588063145; Mon, 25 Sep 2023 05:27:23 -0700 (PDT) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.103.10 at agentk.vger.email Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231537AbjIYM1D (ORCPT <rfc822;pusanteemu@gmail.com> + 29 others); Mon, 25 Sep 2023 08:27:03 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:53840 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229450AbjIYM07 (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Mon, 25 Sep 2023 08:26:59 -0400 Received: from EUR05-AM6-obe.outbound.protection.outlook.com (mail-am6eur05on2057.outbound.protection.outlook.com [40.107.22.57]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 75A0ACE; Mon, 25 Sep 2023 05:26:50 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=CyS34+UL77Hgr9CMvKTBL3OvwM8PC4nZsEUCeei7jhpuiAoE6pRmb/xniahCgRkjFv/EuyDpKNVh0cPd+50aT0S8vA9/U+nYEUrul+kZ10gDb4FgK+gls07kzSqKf/1w5mz5qJ6bOz0kUixQHd9Fdp5QG/584o79vJ29ZB5oD7Vzss9a6rJX2/ScOTeTrVgwCWvT8n+26uiZD09N+Dg6d1RaMqA12qRsHf43zBce0XGISc5CArpu1R1Ea1ZO/mHGw1ZjWPe/mAWGgwojXSw6d0g3LsYfuBPeSjxry15+K+kTs3rhlZxGR9wHpBKkXLT+d27qd0KF+7p8vDYJOum5sw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=Uyd0o4JvcjRjUAoyozcpPdzoVoil7+iWwK4OY683CF8=; b=e8Gv3oLMTjl3NjzFjtSHR0Qi1uoA5R0UJVtMbxjzLil8XUXBogOEsrX1Qt68D9z/ODHzyhp906/ciWZM6IUBmmiCGsVfFaX1VGxmBta9rra4C/jG3pazXknLg7MsctW2fXhqi0e3y865P9294nnONZVLsHL6Mi6WiOjSK6RZq1bRM7BEoeJuzfKHE2N7H8KVciwWE7r7Hu7dBUMNoBXOgbfLfJP6DhWQvAhoLu1HRrY3B79AF1MPNYGrAW0AWW0fElC+PgFrRP546qcyNwsw8vLmdkuWKJT2Fcb//YjrD+UiF2yYUbqBq0q4D9iuYD8QrUv9JvhfbuGy9gZGoc923g== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=softfail (sender ip is 151.1.184.193) smtp.rcpttodomain=vger.kernel.org smtp.mailfrom=asem.it; dmarc=fail (p=none sp=none pct=100) action=none header.from=asem.it; dkim=none (message not signed); arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=asem.it; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Uyd0o4JvcjRjUAoyozcpPdzoVoil7+iWwK4OY683CF8=; b=KOXHQdASZIIIQ2PrczIowdeXlxIlkYXJfOaExtaH5oWJBO28icn2r44ZKZpsUGBCISLAQeWOxrizkJAB9IRLqiKi8Lvkra0GdHyH5OMk7NNDzdp54f5cN0baStHNQDWA47SP+QG8mrxC2HyKjXQLS2eubONtRzTfY73cr3gcTXg= Received: from AS9PR06CA0223.eurprd06.prod.outlook.com (2603:10a6:20b:45e::11) by PAXPR01MB9147.eurprd01.prod.exchangelabs.com (2603:10a6:102:2be::5) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6838.18; Mon, 25 Sep 2023 12:26:47 +0000 Received: from AM3PEPF00009BA2.eurprd04.prod.outlook.com (2603:10a6:20b:45e:cafe::1e) by AS9PR06CA0223.outlook.office365.com (2603:10a6:20b:45e::11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6792.35 via Frontend Transport; Mon, 25 Sep 2023 12:26:47 +0000 X-MS-Exchange-Authentication-Results: spf=softfail (sender IP is 151.1.184.193) smtp.mailfrom=asem.it; dkim=none (message not signed) header.d=none;dmarc=fail action=none header.from=asem.it; Received-SPF: SoftFail (protection.outlook.com: domain of transitioning asem.it discourages use of 151.1.184.193 as permitted sender) Received: from asas054.asem.intra (151.1.184.193) by AM3PEPF00009BA2.mail.protection.outlook.com (10.167.16.27) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6838.14 via Frontend Transport; Mon, 25 Sep 2023 12:26:47 +0000 Received: from flavio-x.asem.intra ([172.16.18.47]) by asas054.asem.intra with Microsoft SMTPSVC(10.0.14393.4169); Mon, 25 Sep 2023 14:26:46 +0200 From: Flavio Suligoi <f.suligoi@asem.it> To: Lee Jones <lee@kernel.org>, Daniel Thompson <daniel.thompson@linaro.org>, Jingoo Han <jingoohan1@gmail.com>, Helge Deller <deller@gmx.de>, Pavel Machek <pavel@ucw.cz>, Rob Herring <robh+dt@kernel.org>, Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>, Conor Dooley <conor+dt@kernel.org> Cc: dri-devel@lists.freedesktop.org, linux-leds@vger.kernel.org, devicetree@vger.kernel.org, linux-fbdev@vger.kernel.org, linux-kernel@vger.kernel.org, Flavio Suligoi <f.suligoi@asem.it>, Rob Herring <robh@kernel.org> Subject: [PATCH v3 1/2] dt-bindings: backlight: Add MPS MP3309C Date: Mon, 25 Sep 2023 14:26:08 +0200 Message-Id: <20230925122609.78849-1-f.suligoi@asem.it> X-Mailer: git-send-email 2.34.1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 25 Sep 2023 12:26:46.0637 (UTC) FILETIME=[8CE479D0:01D9EFAB] X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: AM3PEPF00009BA2:EE_|PAXPR01MB9147:EE_ Content-Type: text/plain X-MS-Office365-Filtering-Correlation-Id: dd9efa45-51e0-477f-eedc-08dbbdc2afc6 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: sVZlxzJn6sWGaThX4Qxv00unpHhn8IRpCqnFae+ayMJ0EuGOGZAFK1cvXcJCYaHBQJiPIAMgYBA2z84osD5qbwDTXdt12WVBGqBhTtuQg3byxmgaN305VTEy0VaJGaMne2qmLi88N+WLpYHE0dYqEvgOMEXiqAogm5rPQv0c0w0URIWlrATAD/pKXXg0AW+8XVjPw9UrtY+dYtB9DASQm/1I146YTUr5VKmS8GDxAGNVRbGV8+UgzYEciBINR84bomJFjNgSY043emVYdpMPQrRP3urSQLEz4IYE35U5FTn7iWLPg6saH9saJW67KXtCLU7j2ZwhmAp6nSDxaTjGdozBJfo+sCoki7JOmBrsjFKL8PzNZA3KTZTFfhZZLBoc8IEyS/AuXaiDvknXC4fNjDPiZ3W+VLpPtPsIVQYUXGmdtttr98QpgeQHiqhBeAA3ofDI8RTey6DK5e3hZUz66CcKIU8a9ai78HpCIps1DymsUAkKWuylHhZZQ2rWC06BebadvTXtyr+Jsj1+cZgZ3mQBrar1T1suOplao0YYugnLWefsDg4YC/evNHfB8Qx8Hw9cPwdw7jEaKZy+eWBW7eJxV12VHeFryu85dLNFB6B5ZnbdVqoA2JkZTZ3DmtOSHJ5bUNgnzEEO0MG1+/2hfxQDkJ6SrmabRFHJJU28Sgz51fuTjYUoPJGRKKrUxzIisOHvug/xTxzeFg6qdEhAg2k1ruxKYi9+KqxU7Mc97oc= X-Forefront-Antispam-Report: CIP:151.1.184.193;CTRY:IT;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:asas054.asem.intra;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230031)(39850400004)(136003)(376002)(396003)(346002)(230922051799003)(186009)(1800799009)(451199024)(82310400011)(46966006)(36840700001)(6666004)(70586007)(82740400003)(26005)(336012)(1076003)(2616005)(70206006)(86362001)(110136005)(966005)(478600001)(47076005)(36860700001)(81166007)(356005)(54906003)(2906002)(8936002)(8676002)(4326008)(36756003)(5660300002)(40480700001)(450100002)(316002)(41300700001)(36900700001);DIR:OUT;SFP:1101; X-OriginatorOrg: asem.it X-MS-Exchange-CrossTenant-OriginalArrivalTime: 25 Sep 2023 12:26:47.1537 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: dd9efa45-51e0-477f-eedc-08dbbdc2afc6 X-MS-Exchange-CrossTenant-Id: d0a766c6-7992-4344-a4a2-a467a7bb1ed2 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=d0a766c6-7992-4344-a4a2-a467a7bb1ed2;Ip=[151.1.184.193];Helo=[asas054.asem.intra] X-MS-Exchange-CrossTenant-AuthSource: AM3PEPF00009BA2.eurprd04.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: PAXPR01MB9147 X-Spam-Status: No, score=-0.9 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on agentk.vger.email Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.4 (agentk.vger.email [0.0.0.0]); Mon, 25 Sep 2023 05:27:23 -0700 (PDT) X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1778017404146113504 X-GMAIL-MSGID: 1778017404146113504 |
Series |
[v3,1/2] dt-bindings: backlight: Add MPS MP3309C
|
|
Commit Message
Flavio Suligoi
Sept. 25, 2023, 12:26 p.m. UTC
The Monolithic Power (MPS) MP3309C is a WLED step-up converter, featuring a programmable switching frequency to optimize efficiency. The brightness can be controlled either by I2C commands (called "analog" mode) or by a PWM input signal (PWM mode). This driver supports both modes. For device driver details, please refer to: - drivers/video/backlight/mp3309c_bl.c The datasheet is available at: - https://www.monolithicpower.com/en/mp3309c.html Signed-off-by: Flavio Suligoi <f.suligoi@asem.it> Reviewed-by: Rob Herring <robh@kernel.org> --- v3: - add default value for mps,overvoltage-protection-microvolt property - fix the example, changing from "mps,mp3309c-backlight" to "mps,mp3309c" in compatible property v2: - remove useless properties (dimming-mode, pinctrl-names, pinctrl-0, switch-on-delay-ms, switch-off-delay-ms, reset-gpios, reset-on-delay-ms, reset-on-length-ms) - add common.yaml# - remove already included properties (default-brightness, max-brightness) - substitute three boolean properties, used for the overvoltage-protection values, with a single enum property - remove some conditional definitions - remove the 2nd example v1: - first version .../bindings/leds/backlight/mps,mp3309c.yaml | 73 +++++++++++++++++++ 1 file changed, 73 insertions(+) create mode 100644 Documentation/devicetree/bindings/leds/backlight/mps,mp3309c.yaml
Comments
On Mon, Sep 25, 2023 at 02:26:08PM +0200, Flavio Suligoi wrote: > The Monolithic Power (MPS) MP3309C is a WLED step-up converter, featuring a > programmable switching frequency to optimize efficiency. > The brightness can be controlled either by I2C commands (called "analog" > mode) or by a PWM input signal (PWM mode). > This driver supports both modes. > > For device driver details, please refer to: > - drivers/video/backlight/mp3309c_bl.c > > The datasheet is available at: > - https://www.monolithicpower.com/en/mp3309c.html > > Signed-off-by: Flavio Suligoi <f.suligoi@asem.it> > Reviewed-by: Rob Herring <robh@kernel.org> > --- > > v3: > - add default value for mps,overvoltage-protection-microvolt property > - fix the example, changing from "mps,mp3309c-backlight" to "mps,mp3309c" in > compatible property > v2: > - remove useless properties (dimming-mode, pinctrl-names, pinctrl-0, > switch-on-delay-ms, switch-off-delay-ms, reset-gpios, reset-on-delay-ms, > reset-on-length-ms) > - add common.yaml# > - remove already included properties (default-brightness, max-brightness) > - substitute three boolean properties, used for the overvoltage-protection > values, with a single enum property > - remove some conditional definitions > - remove the 2nd example > v1: > - first version > > .../bindings/leds/backlight/mps,mp3309c.yaml | 73 +++++++++++++++++++ > 1 file changed, 73 insertions(+) > create mode 100644 Documentation/devicetree/bindings/leds/backlight/mps,mp3309c.yaml > > diff --git a/Documentation/devicetree/bindings/leds/backlight/mps,mp3309c.yaml b/Documentation/devicetree/bindings/leds/backlight/mps,mp3309c.yaml > new file mode 100644 > index 000000000000..4191e33626f5 > --- /dev/null > +++ b/Documentation/devicetree/bindings/leds/backlight/mps,mp3309c.yaml > @@ -0,0 +1,73 @@ > +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) > +%YAML 1.2 > +--- > +$id: http://devicetree.org/schemas/leds/backlight/mps,mp3309c.yaml# > +$schema: http://devicetree.org/meta-schemas/core.yaml# > + > +title: MPS MP3309C backlight > + > +maintainers: > + - Flavio Suligoi <f.suligoi@asem.it> > + > +description: | > + The Monolithic Power (MPS) MP3309C is a WLED step-up converter, featuring a > + programmable switching frequency to optimize efficiency. > + It supports two different dimming modes: > + > + - analog mode, via I2C commands (default) > + - PWM controlled mode. > + > + The datasheet is available at: > + https://www.monolithicpower.com/en/mp3309c.html > + > +allOf: > + - $ref: common.yaml# > + > +properties: > + compatible: > + const: mps,mp3309c > + > + reg: > + maxItems: 1 > + > + pwms: > + description: if present, the backlight is controlled in PWM mode. > + maxItems: 1 > + > + enable-gpios: > + description: GPIO used to enable the backlight in "analog-i2c" dimming mode. > + maxItems: 1 > + > + mps,overvoltage-protection-microvolt: > + description: Overvoltage protection (13.5V, 24V or 35.5V). > + enum: [ 13500000, 24000000, 35500000 ] > + default: 35500000 > + > + mps,no-sync-mode: > + description: disable synchronous rectification mode > + type: boolean > + > +required: > + - compatible > + - reg > + - max-brightness Why is this mandatory? There's no point in setting max-brightness when running in I2C mode (max-brightness should default to 31 in that case). > + - default-brightness Again. I'm not clear why this needs to be mandatory. Daniel.
On Mon, 25 Sep 2023 14:26:08 +0200, Flavio Suligoi wrote: > The Monolithic Power (MPS) MP3309C is a WLED step-up converter, featuring a > programmable switching frequency to optimize efficiency. > The brightness can be controlled either by I2C commands (called "analog" > mode) or by a PWM input signal (PWM mode). > This driver supports both modes. > > For device driver details, please refer to: > - drivers/video/backlight/mp3309c_bl.c > > [...] Applied, thanks! [1/2] dt-bindings: backlight: Add MPS MP3309C commit: 02c4e661658f73d3c266c68f89f0b14bd8ba6bd8 -- Lee Jones [李琼斯]
Hi Daniel, ... > > +required: > > + - compatible > > + - reg > > + - max-brightness > > Why is this mandatory? > > There's no point in setting max-brightness when running in I2C mode (max- > brightness should default to 31 in that case). > > > > + - default-brightness > > Again. I'm not clear why this needs to be mandatory. > > Ok, you are right, I'll remove max-brightness and default-brightness from required properties list. I think to change these properties, for the pwm dimming, into a clearer: - brightness-levels (uint32) - default-brightness-levels (uint32). For example: brightness-levels: description: Number of brightness levels. The actual brightness level (PWM duty cycle) will be interpolated from 0 to this value. 0 means a 0% duty cycle (darkest/off), while the brightness-levels represents a 100% duty cycle (brightest). $ref: /schemas/types.yaml#/definitions/uint32 default-brightness-level: description: The default brightness level (from 0 to brightness-levels) $ref: /schemas/types.yaml#/definitions/uint32 Example: brightness-levels = <10>; default-brightness-level = <6>; What do you think about this solution? > Daniel. Thanks for your help, Flavio
On Tue, Oct 03, 2023 at 09:43:15AM +0000, Flavio Suligoi wrote: > Hi Daniel, > > ... > > > > +required: > > > + - compatible > > > + - reg > > > + - max-brightness > > > > Why is this mandatory? > > > > There's no point in setting max-brightness when running in I2C mode (max- > > brightness should default to 31 in that case). > > > > > > > + - default-brightness > > > > Again. I'm not clear why this needs to be mandatory. > > > > > > Ok, you are right, I'll remove max-brightness and default-brightness > from required properties list. I think to change these properties, > for the pwm dimming, into a clearer: > > - brightness-levels (uint32) > - default-brightness-levels (uint32). > > For example: > > brightness-levels: > description: > Number of brightness levels. The actual brightness > level (PWM duty cycle) will be interpolated from 0 to this value. > 0 means a 0% duty cycle (darkest/off), while the brightness-levels represents > a 100% duty cycle (brightest). > $ref: /schemas/types.yaml#/definitions/uint32 > > default-brightness-level: > description: > The default brightness level (from 0 to brightness-levels) > $ref: /schemas/types.yaml#/definitions/uint32 > > Example: > brightness-levels = <10>; > default-brightness-level = <6>; > > What do you think about this solution? If you want to introduce a brightness-levels property then I would expect it to be defined with the same meaning as pwm-backlight (it's not relevant to the bindings but ideally it would be implemented by refactoring and reusing the code from pwm_bl.c). Same with default-brightness-level although I'm not sure why one wouldn't just use default-brightness for new bindings (doesn't default-brightness-level simply do exactly the same thing as default-brightness). Daniel.
Hi Daniel, ... > > > > +required: > > > > + - compatible > > > > + - reg > > > > + - max-brightness > > > > > > Why is this mandatory? > > > > > > There's no point in setting max-brightness when running in I2C mode > > > (max- brightness should default to 31 in that case). > > > > > > > > > > + - default-brightness > > > > > > Again. I'm not clear why this needs to be mandatory. > > > > > > > > > > Ok, you are right, I'll remove max-brightness and default-brightness > > from required properties list. I think to change these properties, for > > the pwm dimming, into a clearer: > > > > - brightness-levels (uint32) > > - default-brightness-levels (uint32). > > > > For example: > > > > brightness-levels: > > description: > > Number of brightness levels. The actual brightness > > level (PWM duty cycle) will be interpolated from 0 to this value. > > 0 means a 0% duty cycle (darkest/off), while the brightness-levels > represents > > a 100% duty cycle (brightest). > > $ref: /schemas/types.yaml#/definitions/uint32 > > > > default-brightness-level: > > description: > > The default brightness level (from 0 to brightness-levels) > > $ref: /schemas/types.yaml#/definitions/uint32 > > > > Example: > > brightness-levels = <10>; > > default-brightness-level = <6>; > > > > What do you think about this solution? > > If you want to introduce a brightness-levels property then I would expect it to > be defined with the same meaning as pwm-backlight (it's not relevant to the > bindings but ideally it would be implemented by refactoring and reusing the > code from pwm_bl.c). ok, I'll use the brightness-levels property as used in pwm-backlight > > Same with default-brightness-level although I'm not sure why one wouldn't > just use default-brightness for new bindings (doesn't default-brightness-level > simply do exactly the same thing as default-brightness). ok for default-brightness instead of default-brightness-level > > > Daniel. Thanks an best regards, Flavio
Hi Daniel, ... > ... > > > > > +required: > > > > > + - compatible > > > > > + - reg > > > > > + - max-brightness > > > > > > > > Why is this mandatory? > > > > > > > > There's no point in setting max-brightness when running in I2C > > > > mode > > > > (max- brightness should default to 31 in that case). > > > > > > > > > > > > > + - default-brightness > > > > > > > > Again. I'm not clear why this needs to be mandatory. > > > > > > > > > > > > > > Ok, you are right, I'll remove max-brightness and default-brightness > > > from required properties list. I think to change these properties, > > > for the pwm dimming, into a clearer: > > > > > > - brightness-levels (uint32) > > > - default-brightness-levels (uint32). > > > > > > For example: > > > > > > brightness-levels: > > > description: > > > Number of brightness levels. The actual brightness > > > level (PWM duty cycle) will be interpolated from 0 to this value. > > > 0 means a 0% duty cycle (darkest/off), while the > > > brightness-levels > > represents > > > a 100% duty cycle (brightest). > > > $ref: /schemas/types.yaml#/definitions/uint32 > > > > > > default-brightness-level: > > > description: > > > The default brightness level (from 0 to brightness-levels) > > > $ref: /schemas/types.yaml#/definitions/uint32 > > > > > > Example: > > > brightness-levels = <10>; > > > default-brightness-level = <6>; > > > > > > What do you think about this solution? > > > > If you want to introduce a brightness-levels property then I would > > expect it to be defined with the same meaning as pwm-backlight (it's > > not relevant to the bindings but ideally it would be implemented by > > refactoring and reusing the code from pwm_bl.c). > > ok, I'll use the brightness-levels property as used in pwm-backlight > > > > > Same with default-brightness-level although I'm not sure why one > > wouldn't just use default-brightness for new bindings (doesn't > > default-brightness-level simply do exactly the same thing as default- > brightness). > > ok for default-brightness instead of default-brightness-level Just a question: default-brightness-level is the index into the brightness-levels array. But, if I use default-brightness instead of default-brightness-level, should I consider default-brightness also as an index into brightness-levels array? Or, in this case, have the default-brightness to be equal to one of the values inside the brightness-levels array? > > > > > > > Daniel. > > Thanks an best regards, > Flavio Thanks, Flavio
On Wed, Oct 04, 2023 at 03:18:24PM +0000, Flavio Suligoi wrote: > Hi Daniel, > ... > > ... > > > > > > +required: > > > > > > + - compatible > > > > > > + - reg > > > > > > + - max-brightness > > > > > > > > > > Why is this mandatory? > > > > > > > > > > There's no point in setting max-brightness when running in I2C > > > > > mode > > > > > (max- brightness should default to 31 in that case). > > > > > > > > > > > > > > > > + - default-brightness > > > > > > > > > > Again. I'm not clear why this needs to be mandatory. > > > > > > > > > > > > > > > > > > Ok, you are right, I'll remove max-brightness and default-brightness > > > > from required properties list. I think to change these properties, > > > > for the pwm dimming, into a clearer: > > > > > > > > - brightness-levels (uint32) > > > > - default-brightness-levels (uint32). > > > > > > > > For example: > > > > > > > > brightness-levels: > > > > description: > > > > Number of brightness levels. The actual brightness > > > > level (PWM duty cycle) will be interpolated from 0 to this value. > > > > 0 means a 0% duty cycle (darkest/off), while the > > > > brightness-levels > > > represents > > > > a 100% duty cycle (brightest). > > > > $ref: /schemas/types.yaml#/definitions/uint32 > > > > > > > > default-brightness-level: > > > > description: > > > > The default brightness level (from 0 to brightness-levels) > > > > $ref: /schemas/types.yaml#/definitions/uint32 > > > > > > > > Example: > > > > brightness-levels = <10>; > > > > default-brightness-level = <6>; > > > > > > > > What do you think about this solution? > > > > > > If you want to introduce a brightness-levels property then I would > > > expect it to be defined with the same meaning as pwm-backlight (it's > > > not relevant to the bindings but ideally it would be implemented by > > > refactoring and reusing the code from pwm_bl.c). > > > > ok, I'll use the brightness-levels property as used in pwm-backlight > > > > > > > > Same with default-brightness-level although I'm not sure why one > > > wouldn't just use default-brightness for new bindings (doesn't > > > default-brightness-level simply do exactly the same thing as default- > > brightness). > > > > ok for default-brightness instead of default-brightness-level > > Just a question: default-brightness-level is the index into the brightness-levels array. > But, if I use default-brightness instead of default-brightness-level, > should I consider default-brightness also as an index into brightness-levels array? Yes. > Or, in this case, have the default-brightness to be equal to one of the values inside the > brightness-levels array? When there is a brightness array (and there is no interpolation) then it is indexed by brightness. The values in the array are not brightness (e.g. the controlable value describing the output of the hardware). The values in the table are merely the PWM duty cycle... Main difference is, with a correct table the brightness can use an appropriate logarithmic power scale (which matches how humans perceive brightness) instead of the linear scale provided by the PWM duty cycle. Daniel. Brightness and "index into the brightness-levels array" should be one and the same thing > > > > > > > > > > > > Daniel. > > > > Thanks an best regards, > > Flavio > > Thanks, > > Flavio
HI Daniel, ... > > ... > > > ... > > > > > > > +required: > > > > > > > + - compatible > > > > > > > + - reg > > > > > > > + - max-brightness > > > > > > > > > > > > Why is this mandatory? > > > > > > > > > > > > There's no point in setting max-brightness when running in I2C > > > > > > mode > > > > > > (max- brightness should default to 31 in that case). > > > > > > > > > > > > > > > > > > > + - default-brightness > > > > > > > > > > > > Again. I'm not clear why this needs to be mandatory. > > > > > > > > > > > > > > > > > > > > > > Ok, you are right, I'll remove max-brightness and > > > > > default-brightness from required properties list. I think to > > > > > change these properties, for the pwm dimming, into a clearer: > > > > > > > > > > - brightness-levels (uint32) > > > > > - default-brightness-levels (uint32). > > > > > > > > > > For example: > > > > > > > > > > brightness-levels: > > > > > description: > > > > > Number of brightness levels. The actual brightness > > > > > level (PWM duty cycle) will be interpolated from 0 to this value. > > > > > 0 means a 0% duty cycle (darkest/off), while the > > > > > brightness-levels > > > > represents > > > > > a 100% duty cycle (brightest). > > > > > $ref: /schemas/types.yaml#/definitions/uint32 > > > > > > > > > > default-brightness-level: > > > > > description: > > > > > The default brightness level (from 0 to brightness-levels) > > > > > $ref: /schemas/types.yaml#/definitions/uint32 > > > > > > > > > > Example: > > > > > brightness-levels = <10>; > > > > > default-brightness-level = <6>; > > > > > > > > > > What do you think about this solution? > > > > > > > > If you want to introduce a brightness-levels property then I would > > > > expect it to be defined with the same meaning as pwm-backlight > > > > (it's not relevant to the bindings but ideally it would be > > > > implemented by refactoring and reusing the code from pwm_bl.c). > > > > > > ok, I'll use the brightness-levels property as used in pwm-backlight > > > > > > > > > > > Same with default-brightness-level although I'm not sure why one > > > > wouldn't just use default-brightness for new bindings (doesn't > > > > default-brightness-level simply do exactly the same thing as > > > > default- > > > brightness). > > > > > > ok for default-brightness instead of default-brightness-level > > > > Just a question: default-brightness-level is the index into the brightness- > levels array. > > But, if I use default-brightness instead of default-brightness-level, > > should I consider default-brightness also as an index into brightness-levels > array? > > Yes. > > > > Or, in this case, have the default-brightness to be equal to one of > > the values inside the brightness-levels array? > > When there is a brightness array (and there is no interpolation) then it is > indexed by brightness. The values in the array are not brightness (e.g. the > controlable value describing the output of the hardware). The values in the > table are merely the PWM duty cycle... ok > > Main difference is, with a correct table the brightness can use an appropriate > logarithmic power scale (which matches how humans perceive > brightness) instead of the linear scale provided by the PWM duty cycle. > > > Daniel. > > > Brightness and "index into the brightness-levels array" should be one and the > same thing ok, I'll use default-brightness, thanks for the explanations! > > > > > > > > > > > > > > > > > Daniel. > > > > > > Thanks an best regards, > > > Flavio > > > > Thanks, > > > > Flavio Flavio
diff --git a/Documentation/devicetree/bindings/leds/backlight/mps,mp3309c.yaml b/Documentation/devicetree/bindings/leds/backlight/mps,mp3309c.yaml new file mode 100644 index 000000000000..4191e33626f5 --- /dev/null +++ b/Documentation/devicetree/bindings/leds/backlight/mps,mp3309c.yaml @@ -0,0 +1,73 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/leds/backlight/mps,mp3309c.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: MPS MP3309C backlight + +maintainers: + - Flavio Suligoi <f.suligoi@asem.it> + +description: | + The Monolithic Power (MPS) MP3309C is a WLED step-up converter, featuring a + programmable switching frequency to optimize efficiency. + It supports two different dimming modes: + + - analog mode, via I2C commands (default) + - PWM controlled mode. + + The datasheet is available at: + https://www.monolithicpower.com/en/mp3309c.html + +allOf: + - $ref: common.yaml# + +properties: + compatible: + const: mps,mp3309c + + reg: + maxItems: 1 + + pwms: + description: if present, the backlight is controlled in PWM mode. + maxItems: 1 + + enable-gpios: + description: GPIO used to enable the backlight in "analog-i2c" dimming mode. + maxItems: 1 + + mps,overvoltage-protection-microvolt: + description: Overvoltage protection (13.5V, 24V or 35.5V). + enum: [ 13500000, 24000000, 35500000 ] + default: 35500000 + + mps,no-sync-mode: + description: disable synchronous rectification mode + type: boolean + +required: + - compatible + - reg + - max-brightness + - default-brightness + +unevaluatedProperties: false + +examples: + - | + i2c { + #address-cells = <1>; + #size-cells = <0>; + + /* Backlight with PWM control */ + backlight_pwm: backlight@17 { + compatible = "mps,mp3309c"; + reg = <0x17>; + pwms = <&pwm1 0 3333333 0>; /* 300 Hz --> (1/f) * 1*10^9 */ + max-brightness = <100>; + default-brightness = <80>; + mps,overvoltage-protection-microvolt = <24000000>; + }; + };