Message ID | 1676426457-1389-2-git-send-email-cy_huang@richtek.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:adf:eb09:0:0:0:0:0 with SMTP id s9csp3318488wrn; Tue, 14 Feb 2023 18:14:58 -0800 (PST) X-Google-Smtp-Source: AK7set8Xzfs8aIBORjIJ2EiBdi3/f1mNlfRwdf4mWuAKqcWxeRLDHNcUBl66ZSuK/rTQmBS7O79Y X-Received: by 2002:a17:906:ce31:b0:8ae:707:e129 with SMTP id sd17-20020a170906ce3100b008ae0707e129mr655153ejb.19.1676427298137; Tue, 14 Feb 2023 18:14:58 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1676427298; cv=none; d=google.com; s=arc-20160816; b=Y79urZFu05JbjmOEC/qYHgfbl/9M99MXQDoCZBFaeV9NYohbPRGi4qdL6gzBpqE5l0 hFJsj+XgBAJSpLsOirFAI4cYiAONh800Ms1xzrCrjGe0Lmj7L8ebQy9Sc2ulKZua374S kyHO25TgsNJoT0mVBKaJHrpzOafpx3L27aN8PRk3exaveQKwQ88YZug0dzvvLUIyjbng rWjsGQCVc1TVofSakpT5ZRpzmrtjVQywE4EKshguFtVVkuQ+7XuPtPxFzL/osG8qs/BR MRJKKZS2M8BDakGj6uhNNMJb0RIppCFw27XZ9VyIQ9kmtWX0HocsHEdDOIzi9gmpuXod a7FQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:mime-version:references:in-reply-to:message-id :date:subject:cc:to:from; bh=RHxT32M0m+S990yFe9hwRSEpBOIFCoR4V6tkdGf+etQ=; b=pwq/XqgsQi/3bxzVXxl9NDfeAXZTO0FinEvE14PcYYLMxaxdunVcZkzqgxFa2hho0V KaS/1LyqNnW0DwSA2jvBY4F4fB2Jb0WhOSRxlGFE7etLoZC7BLP6eUWKg+AzP61j1fh7 f/ztgezxAqTnLhBRylDuNQm6zr7MWJSsDOKblMLbF8p1Ny+8/NhXlADrSW6v/MpvQdnN EWfisq4/A11AdR1Ls2JDp/R+MkPqsDYwPyquic60JUO3oEE4Iw3MhVfu/n7d5vCpyjqm qm0KLSh2GSTP5b6UUFC+UXQzkax0kFlQbLmywm8/oB3ORMxLNYUhWBlHXknMZNbMrHo5 l7tw== ARC-Authentication-Results: i=1; mx.google.com; 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 Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id uj42-20020a170907c9aa00b008b131d04030si3190531ejc.155.2023.02.14.18.14.34; Tue, 14 Feb 2023 18:14:57 -0800 (PST) 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; 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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232762AbjBOCBW (ORCPT <rfc822;tebrre53rla2o@gmail.com> + 99 others); Tue, 14 Feb 2023 21:01:22 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:44128 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229536AbjBOCBT (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Tue, 14 Feb 2023 21:01:19 -0500 Received: from mg.richtek.com (mg.richtek.com [220.130.44.152]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id 3277423640; Tue, 14 Feb 2023 18:01:15 -0800 (PST) X-MailGates: (flag:4,DYNAMIC,BADHELO,RELAY,NOHOST:PASS)(compute_score:DE LIVER,40,3) Received: from 192.168.10.46 by mg.richtek.com with MailGates ESMTP Server V5.0(23451:0:AUTH_RELAY) (envelope-from <cy_huang@richtek.com>); Wed, 15 Feb 2023 10:00:59 +0800 (CST) Received: from ex3.rt.l (192.168.10.46) by ex3.rt.l (192.168.10.46) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1118.20; Wed, 15 Feb 2023 10:00:58 +0800 Received: from linuxcarl2.richtek.com (192.168.10.154) by ex3.rt.l (192.168.10.45) with Microsoft SMTP Server id 15.2.1118.20 via Frontend Transport; Wed, 15 Feb 2023 10:00:58 +0800 From: <cy_huang@richtek.com> To: <broonie@kernel.org>, <robh+dt@kernel.org>, <krzysztof.kozlowski+dt@linaro.org> CC: <lgirdwood@gmail.com>, <cy_huang@richtek.com>, <u0084500@gmail.com>, <linux-kernel@vger.kernel.org>, <devicetree@vger.kernel.org> Subject: [PATCH 1/2] dt-bindings: regulator: Add bindings for Richtek RT5739 Date: Wed, 15 Feb 2023 10:00:56 +0800 Message-ID: <1676426457-1389-2-git-send-email-cy_huang@richtek.com> X-Mailer: git-send-email 1.8.3.1 In-Reply-To: <1676426457-1389-1-git-send-email-cy_huang@richtek.com> References: <1676426457-1389-1-git-send-email-cy_huang@richtek.com> MIME-Version: 1.0 Content-Type: text/plain X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,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: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1757861430223802337?= X-GMAIL-MSGID: =?utf-8?q?1757861430223802337?= |
Series |
Add Richtek RT5739 switching voltage regulator support
|
|
Commit Message
ChiYuan Huang
Feb. 15, 2023, 2 a.m. UTC
From: ChiYuan Huang <cy_huang@richtek.com> Add the binding document for Richtek RT5739. Signed-off-by: ChiYuan Huang <cy_huang@richtek.com> --- .../bindings/regulator/richtek,rt5739.yaml | 80 ++++++++++++++++++++++ 1 file changed, 80 insertions(+) create mode 100644 Documentation/devicetree/bindings/regulator/richtek,rt5739.yaml
Comments
On Wed, Feb 15, 2023 at 10:00:56AM +0800, cy_huang@richtek.com wrote: > + richtek,vsel-active-high: > + description: | > + If property is present, use the 'VSEL1' register group for buck control. > + Else, use the 'VSEL0' register group. This depends on external hardware > + 'VSEL' pin connecton. > + type: boolean I would expect this to be GPIO controlled rather than fixed in the design, at least for some systems? The name suggests it's supposed to control the polarity of a GPIO too. Sadly we don't really have good infrastructure for fixed GPIOs AFAIK... ideally this would be a GPIO and then if we need to hold it high then there would be some binding we could connect to the GPIO that says that. We don't have that though so for now a fixed property might be OK.
Hi, Mark Brown <broonie@kernel.org> 於 2023年2月15日 週三 下午9:03寫道: > > On Wed, Feb 15, 2023 at 10:00:56AM +0800, cy_huang@richtek.com wrote: > > > + richtek,vsel-active-high: > > + description: | > > + If property is present, use the 'VSEL1' register group for buck control. > > + Else, use the 'VSEL0' register group. This depends on external hardware > > + 'VSEL' pin connecton. > > + type: boolean > > I would expect this to be GPIO controlled rather than fixed in > the design, at least for some systems? The name suggests it's > supposed to control the polarity of a GPIO too. Sadly we don't > really have good infrastructure for fixed GPIOs AFAIK... ideally > this would be a GPIO and then if we need to hold it high then > there would be some binding we could connect to the GPIO that > says that. We don't have that though so for now a fixed property > might be OK. It's most like two phase buck controllers internally. 'Vsel' to control which buck output. Each phase has its registers (voltage/enable/mode). The common usage of 'vsel' pin is to connect the pin by SoC suspend/resume pin. This can be used to implement system low power design (like as system awake 0.6V, sleep 0.3V or sleep buck off). I haven't seen the usage to connect it directly by GPIO.
On 15/02/2023 03:00, cy_huang@richtek.com wrote: > From: ChiYuan Huang <cy_huang@richtek.com> > > Add the binding document for Richtek RT5739. Subject: drop second/last, redundant "bindings for". The "dt-bindings" prefix is already stating that these are bindings. > > Signed-off-by: ChiYuan Huang <cy_huang@richtek.com> > --- > .../bindings/regulator/richtek,rt5739.yaml | 80 ++++++++++++++++++++++ > 1 file changed, 80 insertions(+) > create mode 100644 Documentation/devicetree/bindings/regulator/richtek,rt5739.yaml > > diff --git a/Documentation/devicetree/bindings/regulator/richtek,rt5739.yaml b/Documentation/devicetree/bindings/regulator/richtek,rt5739.yaml > new file mode 100644 > index 00000000..7dc4f78 > --- /dev/null > +++ b/Documentation/devicetree/bindings/regulator/richtek,rt5739.yaml > @@ -0,0 +1,80 @@ > +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause > +%YAML 1.2 > +--- > +$id: http://devicetree.org/schemas/regulator/richtek,rt5739.yaml# > +$schema: http://devicetree.org/meta-schemas/core.yaml# > + > +title: Richtek RT5739 2.4MHz 3.5A Step-Down Converter > + > +maintainers: > + - ChiYuan Huang <cy_huang@richtek.com> > + > +description: | > + The RT5739 is a step-down switching voltage regulator that delivers a > + digitally programmable output from an input voltage supply of 2.5V to 5.5V. > + The output voltage is programmed through an I2C interface capable of > + operating up to 3.4MHz. > + > + Using a proprietary architecture with synchronous rectification, the RT5739 > + is capable of delivering 3.5A continuously at over 80% efficiency, > + maintaining that efficiency at load current as low as 10mA. The regulator > + operates at a normal fixed frequency of 2.4MHz, which reduces the value of > + the external components. Can we drop the marketing from kernel? Last part of sentence is not related to this submission at all. The internal frequency also looks unrelated to the topic... > Additional output capacitance can be added to > + improve regulation during load transients without affecting stability. > + > +allOf: > + - $ref: regulator.yaml# > + > +properties: > + compatible: > + enum: > + - richtek,rt5739 > + > + reg: > + maxItems: 1 > + > + enable-gpios: > + maxItems: 1 > + > + richtek,vsel-active-high: > + description: | > + If property is present, use the 'VSEL1' register group for buck control. > + Else, use the 'VSEL0' register group. This depends on external hardware > + 'VSEL' pin connecton. > + type: boolean > + > + regulator-allowed-modes: > + description: | > + buck allowed operating mode > + 0: Auto PFM/PWM mode > + 1: Forced PWM mode > + maxItems: 2 > + items: > + enum: [0, 1] So you always require two items? Thus I wonder what's the point of having it in DT? To skip the property entirely if none of the modes are allowed? Best regards, Krzysztof
On Thu, Feb 16, 2023 at 10:12:15AM +0100, Krzysztof Kozlowski wrote: > On 15/02/2023 03:00, cy_huang@richtek.com wrote: > > From: ChiYuan Huang <cy_huang@richtek.com> > > > > Add the binding document for Richtek RT5739. > > Subject: drop second/last, redundant "bindings for". The "dt-bindings" > prefix is already stating that these are bindings. > Then, refine it to "dt-bindings: regulator: Add Richtek RT5739 document" > > > > Signed-off-by: ChiYuan Huang <cy_huang@richtek.com> > > --- > > .../bindings/regulator/richtek,rt5739.yaml | 80 ++++++++++++++++++++++ > > 1 file changed, 80 insertions(+) > > create mode 100644 Documentation/devicetree/bindings/regulator/richtek,rt5739.yaml > > > > diff --git a/Documentation/devicetree/bindings/regulator/richtek,rt5739.yaml b/Documentation/devicetree/bindings/regulator/richtek,rt5739.yaml > > new file mode 100644 > > index 00000000..7dc4f78 > > --- /dev/null > > +++ b/Documentation/devicetree/bindings/regulator/richtek,rt5739.yaml > > @@ -0,0 +1,80 @@ > > +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause > > +%YAML 1.2 > > +--- > > +$id: http://devicetree.org/schemas/regulator/richtek,rt5739.yaml# > > +$schema: http://devicetree.org/meta-schemas/core.yaml# > > + > > +title: Richtek RT5739 2.4MHz 3.5A Step-Down Converter > > + > > +maintainers: > > + - ChiYuan Huang <cy_huang@richtek.com> > > + > > +description: | > > + The RT5739 is a step-down switching voltage regulator that delivers a > > + digitally programmable output from an input voltage supply of 2.5V to 5.5V. > > + The output voltage is programmed through an I2C interface capable of > > + operating up to 3.4MHz. > > + > > + Using a proprietary architecture with synchronous rectification, the RT5739 > > + is capable of delivering 3.5A continuously at over 80% efficiency, > > + maintaining that efficiency at load current as low as 10mA. The regulator > > + operates at a normal fixed frequency of 2.4MHz, which reduces the value of > > + the external components. > > Can we drop the marketing from kernel? Last part of sentence is not > related to this submission at all. The internal frequency also looks > unrelated to the topic... > Okay, too much marketing text. I'll shorten it and simply describe the function or voltage range only. > > Additional output capacitance can be added to > > + improve regulation during load transients without affecting stability. > > + > > +allOf: > > + - $ref: regulator.yaml# > > + > > +properties: > > + compatible: > > + enum: > > + - richtek,rt5739 > > + > > + reg: > > + maxItems: 1 > > + > > + enable-gpios: > > + maxItems: 1 > > + > > + richtek,vsel-active-high: > > + description: | > > + If property is present, use the 'VSEL1' register group for buck control. > > + Else, use the 'VSEL0' register group. This depends on external hardware > > + 'VSEL' pin connecton. > > + type: boolean > > + > > + regulator-allowed-modes: > > + description: | > > + buck allowed operating mode > > + 0: Auto PFM/PWM mode > > + 1: Forced PWM mode > > + maxItems: 2 > > + items: > > + enum: [0, 1] > > So you always require two items? Thus I wonder what's the point of > having it in DT? To skip the property entirely if none of the modes are > allowed? > Not always need two. So does it mean no need to describe the 'maxItems' and 'Items'. Keep the description of 'regulator-allowed-modes' to tell the user what the valid value is. > > Best regards, > Krzysztof >
On 16/02/2023 10:57, ChiYuan Huang wrote: > On Thu, Feb 16, 2023 at 10:12:15AM +0100, Krzysztof Kozlowski wrote: >> On 15/02/2023 03:00, cy_huang@richtek.com wrote: >>> From: ChiYuan Huang <cy_huang@richtek.com> >>> >>> Add the binding document for Richtek RT5739. >> >> Subject: drop second/last, redundant "bindings for". The "dt-bindings" >> prefix is already stating that these are bindings. >> > Then, refine it to "dt-bindings: regulator: Add Richtek RT5739 document" I propose also to drop "document" - it is also redundant. Can bindings be something else than document? >>> >>> Signed-off-by: ChiYuan Huang <cy_huang@richtek.com> >>> --- >>> .../bindings/regulator/richtek,rt5739.yaml | 80 ++++++++++++++++++++++ >>> 1 file changed, 80 insertions(+) >>> create mode 100644 Documentation/devicetree/bindings/regulator/richtek,rt5739.yaml >>> >>> diff --git a/Documentation/devicetree/bindings/regulator/richtek,rt5739.yaml b/Documentation/devicetree/bindings/regulator/richtek,rt5739.yaml >>> new file mode 100644 >>> index 00000000..7dc4f78 >>> --- /dev/null >>> +++ b/Documentation/devicetree/bindings/regulator/richtek,rt5739.yaml >>> @@ -0,0 +1,80 @@ >>> +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause >>> +%YAML 1.2 >>> +--- >>> +$id: http://devicetree.org/schemas/regulator/richtek,rt5739.yaml# >>> +$schema: http://devicetree.org/meta-schemas/core.yaml# >>> + >>> +title: Richtek RT5739 2.4MHz 3.5A Step-Down Converter >>> + >>> +maintainers: >>> + - ChiYuan Huang <cy_huang@richtek.com> >>> + >>> +description: | >>> + The RT5739 is a step-down switching voltage regulator that delivers a >>> + digitally programmable output from an input voltage supply of 2.5V to 5.5V. >>> + The output voltage is programmed through an I2C interface capable of >>> + operating up to 3.4MHz. >>> + >>> + Using a proprietary architecture with synchronous rectification, the RT5739 >>> + is capable of delivering 3.5A continuously at over 80% efficiency, >>> + maintaining that efficiency at load current as low as 10mA. The regulator >>> + operates at a normal fixed frequency of 2.4MHz, which reduces the value of >>> + the external components. >> >> Can we drop the marketing from kernel? Last part of sentence is not >> related to this submission at all. The internal frequency also looks >> unrelated to the topic... >> > Okay, too much marketing text. I'll shorten it and simply describe the function or > voltage range only. >>> Additional output capacitance can be added to >>> + improve regulation during load transients without affecting stability. >>> + >>> +allOf: >>> + - $ref: regulator.yaml# >>> + >>> +properties: >>> + compatible: >>> + enum: >>> + - richtek,rt5739 >>> + >>> + reg: >>> + maxItems: 1 >>> + >>> + enable-gpios: >>> + maxItems: 1 >>> + >>> + richtek,vsel-active-high: >>> + description: | >>> + If property is present, use the 'VSEL1' register group for buck control. >>> + Else, use the 'VSEL0' register group. This depends on external hardware >>> + 'VSEL' pin connecton. >>> + type: boolean >>> + >>> + regulator-allowed-modes: >>> + description: | >>> + buck allowed operating mode >>> + 0: Auto PFM/PWM mode >>> + 1: Forced PWM mode >>> + maxItems: 2 >>> + items: >>> + enum: [0, 1] >> >> So you always require two items? Thus I wonder what's the point of >> having it in DT? To skip the property entirely if none of the modes are >> allowed? >> > Not always need two. So does it mean no need to describe the 'maxItems' and 'Items'. Your minItems is 2, so you always need two. If you accept one, the add minItems: 1. Best regards, Krzysztof
On Thu, Feb 16, 2023 at 11:03:39AM +0100, Krzysztof Kozlowski wrote: > On 16/02/2023 10:57, ChiYuan Huang wrote: > > On Thu, Feb 16, 2023 at 10:12:15AM +0100, Krzysztof Kozlowski wrote: > >> On 15/02/2023 03:00, cy_huang@richtek.com wrote: > >>> From: ChiYuan Huang <cy_huang@richtek.com> > >>> > >>> Add the binding document for Richtek RT5739. > >> > >> Subject: drop second/last, redundant "bindings for". The "dt-bindings" > >> prefix is already stating that these are bindings. > >> > > Then, refine it to "dt-bindings: regulator: Add Richtek RT5739 document" > > I propose also to drop "document" - it is also redundant. Can bindings > be something else than document? > Yes, you'r right. > > >>> > >>> Signed-off-by: ChiYuan Huang <cy_huang@richtek.com> > >>> --- > >>> .../bindings/regulator/richtek,rt5739.yaml | 80 ++++++++++++++++++++++ > >>> 1 file changed, 80 insertions(+) > >>> create mode 100644 Documentation/devicetree/bindings/regulator/richtek,rt5739.yaml > >>> > >>> diff --git a/Documentation/devicetree/bindings/regulator/richtek,rt5739.yaml b/Documentation/devicetree/bindings/regulator/richtek,rt5739.yaml > >>> new file mode 100644 > >>> index 00000000..7dc4f78 > >>> --- /dev/null > >>> +++ b/Documentation/devicetree/bindings/regulator/richtek,rt5739.yaml > >>> @@ -0,0 +1,80 @@ > >>> +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause > >>> +%YAML 1.2 > >>> +--- > >>> +$id: http://devicetree.org/schemas/regulator/richtek,rt5739.yaml# > >>> +$schema: http://devicetree.org/meta-schemas/core.yaml# > >>> + > >>> +title: Richtek RT5739 2.4MHz 3.5A Step-Down Converter > >>> + > >>> +maintainers: > >>> + - ChiYuan Huang <cy_huang@richtek.com> > >>> + > >>> +description: | > >>> + The RT5739 is a step-down switching voltage regulator that delivers a > >>> + digitally programmable output from an input voltage supply of 2.5V to 5.5V. > >>> + The output voltage is programmed through an I2C interface capable of > >>> + operating up to 3.4MHz. > >>> + > >>> + Using a proprietary architecture with synchronous rectification, the RT5739 > >>> + is capable of delivering 3.5A continuously at over 80% efficiency, > >>> + maintaining that efficiency at load current as low as 10mA. The regulator > >>> + operates at a normal fixed frequency of 2.4MHz, which reduces the value of > >>> + the external components. > >> > >> Can we drop the marketing from kernel? Last part of sentence is not > >> related to this submission at all. The internal frequency also looks > >> unrelated to the topic... > >> > > Okay, too much marketing text. I'll shorten it and simply describe the function or > > voltage range only. > >>> Additional output capacitance can be added to > >>> + improve regulation during load transients without affecting stability. > >>> + > >>> +allOf: > >>> + - $ref: regulator.yaml# > >>> + > >>> +properties: > >>> + compatible: > >>> + enum: > >>> + - richtek,rt5739 > >>> + > >>> + reg: > >>> + maxItems: 1 > >>> + > >>> + enable-gpios: > >>> + maxItems: 1 > >>> + > >>> + richtek,vsel-active-high: > >>> + description: | > >>> + If property is present, use the 'VSEL1' register group for buck control. > >>> + Else, use the 'VSEL0' register group. This depends on external hardware > >>> + 'VSEL' pin connecton. > >>> + type: boolean > >>> + > >>> + regulator-allowed-modes: > >>> + description: | > >>> + buck allowed operating mode > >>> + 0: Auto PFM/PWM mode > >>> + 1: Forced PWM mode > >>> + maxItems: 2 > >>> + items: > >>> + enum: [0, 1] > >> > >> So you always require two items? Thus I wonder what's the point of > >> having it in DT? To skip the property entirely if none of the modes are > >> allowed? > >> > > Not always need two. So does it mean no need to describe the 'maxItems' and 'Items'. > > Your minItems is 2, so you always need two. If you accept one, the add > minItems: 1. > https://elixir.bootlin.com/linux/v6.2-rc8/source/drivers/regulator/of_regulator.c#L198 It seems no need to limit the maxItems. Regulator core will call 'of_map_mode' to check the value. Even the value is repeat. And for minItems, 'regulator.yaml' already said it's uint32-array. Must be lager than zero, right? So how about just keep 'items' and remove the 'maxItems'? > > > Best regards, > Krzysztof >
On 16/02/2023 11:35, ChiYuan Huang wrote: > https://elixir.bootlin.com/linux/v6.2-rc8/source/drivers/regulator/of_regulator.c#L198 > It seems no need to limit the maxItems. Regulator core will call 'of_map_mode' to check the value. > Even the value is repeat. > > And for minItems, 'regulator.yaml' already said it's uint32-array. Must be lager than zero, right? > > So how about just keep 'items' and remove the 'maxItems'? Yeah, go ahead, with that enum, it should be correct.. Best regards, Krzysztof
diff --git a/Documentation/devicetree/bindings/regulator/richtek,rt5739.yaml b/Documentation/devicetree/bindings/regulator/richtek,rt5739.yaml new file mode 100644 index 00000000..7dc4f78 --- /dev/null +++ b/Documentation/devicetree/bindings/regulator/richtek,rt5739.yaml @@ -0,0 +1,80 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/regulator/richtek,rt5739.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Richtek RT5739 2.4MHz 3.5A Step-Down Converter + +maintainers: + - ChiYuan Huang <cy_huang@richtek.com> + +description: | + The RT5739 is a step-down switching voltage regulator that delivers a + digitally programmable output from an input voltage supply of 2.5V to 5.5V. + The output voltage is programmed through an I2C interface capable of + operating up to 3.4MHz. + + Using a proprietary architecture with synchronous rectification, the RT5739 + is capable of delivering 3.5A continuously at over 80% efficiency, + maintaining that efficiency at load current as low as 10mA. The regulator + operates at a normal fixed frequency of 2.4MHz, which reduces the value of + the external components. Additional output capacitance can be added to + improve regulation during load transients without affecting stability. + +allOf: + - $ref: regulator.yaml# + +properties: + compatible: + enum: + - richtek,rt5739 + + reg: + maxItems: 1 + + enable-gpios: + maxItems: 1 + + richtek,vsel-active-high: + description: | + If property is present, use the 'VSEL1' register group for buck control. + Else, use the 'VSEL0' register group. This depends on external hardware + 'VSEL' pin connecton. + type: boolean + + regulator-allowed-modes: + description: | + buck allowed operating mode + 0: Auto PFM/PWM mode + 1: Forced PWM mode + maxItems: 2 + items: + enum: [0, 1] + +required: + - compatible + - reg + +unevaluatedProperties: false + +examples: + - | + #include <dt-bindings/gpio/gpio.h> + + i2c { + #address-cells = <1>; + #size-cells = <0>; + + regulator@50 { + compatible = "richtek,rt5739"; + reg = <0x50>; + enable-gpios = <&gpio26 1 GPIO_ACTIVE_HIGH>; + richtek,vsel-active-high; + regulator-name = "richtek,rt5739-buck"; + regulator-min-microvolt = <3000000>; + regulator-max-microvolt = <13000000>; + regulator-allowed-modes = <0 1>; + regulator-boot-on; + }; + };