Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1694282 > unrolled thread

[PATCH 00/10] A trial to Allwinner H3 DVFS support

Started byIcenowy Zheng <icenowy@aosc.io>
First post2017-07-23 12:30 +0200
Last post2017-07-24 05:10 +0200
Articles 16 on this page of 36 — 9 participants

Back to article view | Back to linux.kernel


Contents

  [PATCH 00/10] A trial to Allwinner H3 DVFS support Icenowy Zheng <icenowy@aosc.io> - 2017-07-23 12:30 +0200
    [PATCH 07/10] cpufreq: dt: Add support for some new Allwinner SoCs Icenowy Zheng <icenowy@aosc.io> - 2017-07-23 12:30 +0200
      Re: [PATCH 07/10] cpufreq: dt: Add support for some new Allwinner  SoCs Viresh Kumar <viresh.kumar@linaro.org> - 2017-07-24 11:00 +0200
        Re: [PATCH 07/10] cpufreq: dt: Add support for some new Allwinner SoCs "Rafael J. Wysocki" <rjw@rjwysocki.net> - 2017-07-24 14:00 +0200
    [PATCH 04/10] ARM: sunxi: h3/h5: Add r_i2c I2C controller Icenowy Zheng <icenowy@aosc.io> - 2017-07-23 12:30 +0200
      Re: [linux-sunxi] [PATCH 04/10] ARM: sunxi: h3/h5: Add r_i2c I2C controller Chen-Yu Tsai <wens@csie.org> - 2017-07-24 05:20 +0200
    [PATCH 08/10] ARM: sun8i: h3: add operating-points-v2 table for CPU Icenowy Zheng <icenowy@aosc.io> - 2017-07-23 12:30 +0200
    [PATCH 03/10] ARM: sunxi: h3/h5: Add r_i2c pinmux node Icenowy Zheng <icenowy@aosc.io> - 2017-07-23 12:30 +0200
      Re: [linux-sunxi] [PATCH 03/10] ARM: sunxi: h3/h5: Add r_i2c pinmux node Chen-Yu Tsai <wens@csie.org> - 2017-07-24 05:10 +0200
        Re: [linux-sunxi] [PATCH 03/10] ARM: sunxi: h3/h5: Add r_i2c pinmux  node icenowy@aosc.io - 2017-07-24 05:10 +0200
    [PATCH 05/10] clk: sunxi-ng: h3: gate then ungate PLL CPU clk after rate change Icenowy Zheng <icenowy@aosc.io> - 2017-07-23 12:30 +0200
      Re: [PATCH 05/10] clk: sunxi-ng: h3: gate then ungate PLL CPU clk  after rate change Stephen Boyd <sboyd@codeaurora.org> - 2017-07-26 02:40 +0200
      Re: [linux-sunxi] [PATCH 05/10] clk: sunxi-ng: h3: gate then ungate  PLL CPU clk after rate change Chen-Yu Tsai <wens@csie.org> - 2017-07-26 09:20 +0200
    [PATCH 09/10] ARM: sun8i: h2+: add SY8113B regulator used by Orange Pi Zero board Icenowy Zheng <icenowy@aosc.io> - 2017-07-23 12:30 +0200
      Re: [linux-sunxi] [PATCH 09/10] ARM: sun8i: h2+: add SY8113B  regulator used by Orange Pi Zero board Chen-Yu Tsai <wens@csie.org> - 2017-07-24 06:10 +0200
    [PATCH 06/10] clk: sunxi-ng: allow set parent clock (PLL_CPUX) for CPUX clock on H3 Icenowy Zheng <icenowy@aosc.io> - 2017-07-23 12:30 +0200
      Re: [linux-sunxi] [PATCH 06/10] clk: sunxi-ng: allow set parent clock  (PLL_CPUX) for CPUX clock on H3 Chen-Yu Tsai <wens@csie.org> - 2017-07-24 05:20 +0200
      Re: [PATCH 06/10] clk: sunxi-ng: allow set parent clock (PLL_CPUX)  for CPUX clock on H3 Stephen Boyd <sboyd@codeaurora.org> - 2017-07-26 02:40 +0200
    [PATCH 02/10] regulator: add support for SY8106A regulator Icenowy Zheng <icenowy@aosc.io> - 2017-07-23 12:30 +0200
      Re: [linux-sunxi] [PATCH 02/10] regulator: add support for SY8106A regulator Chen-Yu Tsai <wens@csie.org> - 2017-07-24 05:10 +0200
        Re: [linux-sunxi] [PATCH 02/10] regulator: add support for SY8106A  regulator icenowy@aosc.io - 2017-07-24 05:20 +0200
          Re: [linux-sunxi] [PATCH 02/10] regulator: add support for SY8106A  regulator icenowy@aosc.io - 2017-07-24 05:40 +0200
            Re: [linux-sunxi] [PATCH 02/10] regulator: add support for SY8106A regulator Chen-Yu Tsai <wens@csie.org> - 2017-07-24 08:20 +0200
          Re: [linux-sunxi] [PATCH 02/10] regulator: add support for SY8106A regulator Chen-Yu Tsai <wens@csie.org> - 2017-07-24 05:40 +0200
        Re: [linux-sunxi] [PATCH 02/10] regulator: add support for SY8106A  regulator Mark Brown <broonie@kernel.org> - 2017-07-24 17:10 +0200
    [PATCH 10/10] ARM: dts: sun8i: Add SY8106A regulator to Orange Pi PC Icenowy Zheng <icenowy@aosc.io> - 2017-07-23 12:30 +0200
      Re: [linux-sunxi] [PATCH 10/10] ARM: dts: sun8i: Add SY8106A  regulator to Orange Pi PC Chen-Yu Tsai <wens@csie.org> - 2017-07-26 09:10 +0200
        Re: [linux-sunxi] [PATCH 10/10] ARM: dts: sun8i: Add SY8106A regulator to Orange Pi PC Icenowy Zheng <icenowy@aosc.io> - 2017-07-26 09:20 +0200
          Re: [linux-sunxi] [PATCH 10/10] ARM: dts: sun8i: Add SY8106A  regulator to Orange Pi PC Chen-Yu Tsai <wens@csie.org> - 2017-07-26 09:40 +0200
            Re: [linux-sunxi] [PATCH 10/10] ARM: dts: sun8i: Add SY8106A  regulator to Orange Pi PC icenowy@aosc.io - 2017-07-26 09:40 +0200
              Re: [linux-sunxi] [PATCH 10/10] ARM: dts: sun8i: Add SY8106A  regulator to Orange Pi PC Ondřej Jirman <megous@megous.com> - 2017-07-26 12:40 +0200
                Re: [linux-sunxi] [PATCH 10/10] ARM: dts: sun8i: Add SY8106A  regulator to Orange Pi PC Maxime Ripard <maxime.ripard@free-electrons.com> - 2017-07-26 13:50 +0200
                  Re: [linux-sunxi] [PATCH 10/10] ARM: dts: sun8i: Add SY8106A  regulator to Orange Pi PC icenowy@aosc.io - 2017-07-26 14:50 +0200
                  Re: [linux-sunxi] [PATCH 10/10] ARM: dts: sun8i: Add SY8106A  regulator to Orange Pi PC Ondřej Jirman <megous@megous.com> - 2017-07-26 15:00 +0200
    [PATCH 01/10] dt-bindings: add binding for the SY8160A voltage regulator Icenowy Zheng <icenowy@aosc.io> - 2017-07-23 12:30 +0200
      Re: [linux-sunxi] [PATCH 01/10] dt-bindings: add binding for the  SY8160A voltage regulator Chen-Yu Tsai <wens@csie.org> - 2017-07-24 05:10 +0200

Page 2 of 2 — ← Prev page 1 [2]


#1694421 — Re: [linux-sunxi] [PATCH 02/10] regulator: add support for SY8106A regulator

Fromicenowy@aosc.io
Date2017-07-24 05:20 +0200
SubjectRe: [linux-sunxi] [PATCH 02/10] regulator: add support for SY8106A regulator
Message-ID<u6C4y-7KV-5@gated-at.bofh.it>
In reply to#1694415
在 2017-07-24 11:03,Chen-Yu Tsai 写道:
> On Sun, Jul 23, 2017 at 6:27 PM, Icenowy Zheng <icenowy@aosc.io> wrote:
>> From: Ondrej Jirman <megous@megous.com>
>> 
>> SY8106A is an I2C attached single output regulator made by Silergy 
>> Corp,
>> which is used on several Allwinner H3/H5 SBCs to control the power
>> supply of the ARM cores.
>> 
>> Add a driver for it.
>> 
>> Signed-off-by: Ondrej Jirman <megous@megous.com>
>> [Icenowy: Change commit message]
>> Signed-off-by: Icenowy Zheng <icenowy@aosc.io>
>> ---
>>  drivers/regulator/Kconfig             |   8 +-
>>  drivers/regulator/Makefile            |   2 +-
>>  drivers/regulator/sy8106a-regulator.c | 163 
>> ++++++++++++++++++++++++++++++++++
>>  3 files changed, 171 insertions(+), 2 deletions(-)
>>  create mode 100644 drivers/regulator/sy8106a-regulator.c
>> 
>> diff --git a/drivers/regulator/Kconfig b/drivers/regulator/Kconfig
>> index 99b9362331b5..1efa73e18d07 100644
>> --- a/drivers/regulator/Kconfig
>> +++ b/drivers/regulator/Kconfig
>> @@ -764,6 +764,13 @@ config REGULATOR_STW481X_VMMC
>>           This driver supports the internal VMMC regulator in the 
>> STw481x
>>           PMIC chips.
>> 
>> +config REGULATOR_SY8106A
>> +       tristate "Silergy SY8106A regulator"
>> +       depends on I2C && (OF || COMPILE_TEST)
>> +       select REGMAP_I2C
>> +       help
>> +         This driver supports SY8106A single output regulator.
>> +
>>  config REGULATOR_TPS51632
>>         tristate "TI TPS51632 Power Regulator"
>>         depends on I2C
>> @@ -938,4 +945,3 @@ config REGULATOR_WM8994
>>           WM8994 CODEC.
>> 
>>  endif
>> -
>> diff --git a/drivers/regulator/Makefile b/drivers/regulator/Makefile
>> index 95b1e86ae692..f5120252f86a 100644
>> --- a/drivers/regulator/Makefile
>> +++ b/drivers/regulator/Makefile
>> @@ -95,6 +95,7 @@ obj-$(CONFIG_REGULATOR_S2MPS11) += s2mps11.o
>>  obj-$(CONFIG_REGULATOR_S5M8767) += s5m8767.o
>>  obj-$(CONFIG_REGULATOR_SKY81452) += sky81452-regulator.o
>>  obj-$(CONFIG_REGULATOR_STW481X_VMMC) += stw481x-vmmc.o
>> +obj-$(CONFIG_REGULATOR_SY8106A) += sy8106a-regulator.o
>>  obj-$(CONFIG_REGULATOR_TI_ABB) += ti-abb-regulator.o
>>  obj-$(CONFIG_REGULATOR_TPS6105X) += tps6105x-regulator.o
>>  obj-$(CONFIG_REGULATOR_TPS62360) += tps62360-regulator.o
>> @@ -120,5 +121,4 @@ obj-$(CONFIG_REGULATOR_WM8350) += 
>> wm8350-regulator.o
>>  obj-$(CONFIG_REGULATOR_WM8400) += wm8400-regulator.o
>>  obj-$(CONFIG_REGULATOR_WM8994) += wm8994-regulator.o
>> 
>> -
>>  ccflags-$(CONFIG_REGULATOR_DEBUG) += -DDEBUG
>> diff --git a/drivers/regulator/sy8106a-regulator.c 
>> b/drivers/regulator/sy8106a-regulator.c
>> new file mode 100644
>> index 000000000000..1df889f68b3d
>> --- /dev/null
>> +++ b/drivers/regulator/sy8106a-regulator.c
>> @@ -0,0 +1,163 @@
>> +/*
>> + * sy8106a-regulator.c - Regulator device driver for SY8106A
>> + *
>> + * Copyright (C) 2016 Ondřej Jirman <megous@megous.com>
>> + *
>> + * This program is free software; you can redistribute it and/or
>> + * modify it under the terms of the GNU Library General Public
>> + * License as published by the Free Software Foundation; either
>> + * version 2 of the License, or (at your option) any later version.
>> + *
>> + * This program is distributed in the hope that it will be useful,
>> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
>> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
>> + * Library General Public License for more details.
>> + */
>> +
>> +#include <linux/err.h>
>> +#include <linux/i2c.h>
>> +#include <linux/module.h>
>> +#include <linux/regmap.h>
>> +#include <linux/regulator/driver.h>
>> +#include <linux/regulator/of_regulator.h>
>> +
>> +#define SY8106A_REG_VOUT1_SEL          0x01
>> +#define SY8106A_REG_VOUT_COM           0x02
>> +#define SY8106A_REG_VOUT1_SEL_MASK     0x7f
>> +#define SY8106A_DISABLE_REG            BIT(0)
>> +#define SY8106A_GO_BIT                 BIT(7)
>> +
>> +struct sy8106a {
>> +       struct regulator_dev *rdev;
>> +       struct regmap *regmap;
>> +};
>> +
>> +static const struct regmap_config sy8106a_regmap_config = {
>> +       .reg_bits = 8,
>> +       .val_bits = 8,
>> +};
>> +
>> +static int sy8106a_set_voltage_sel(struct regulator_dev *rdev, 
>> unsigned int sel)
>> +{
>> +       /* We use our set_voltage_sel in order to avoid unnecessary 
>> I2C
>> +        * chatter, because the regulator_get_voltage_sel_regmap using
>> +        * apply_bit would perform 4 unnecessary transfers instead of 
>> one,
>> +        * increasing the chance of error.
>> +        */
>> +       return regmap_write(rdev->regmap, rdev->desc->vsel_reg,
>> +                           sel | SY8106A_GO_BIT);
> 
> There should also be an explanation of what the "go bit" does.
> In this case it enables control of the voltage over I2C.
> 
>> +}
>> +
>> +static const struct regulator_ops sy8106a_ops = {
>> +       .is_enabled = regulator_is_enabled_regmap,
>> +       .set_voltage_sel = sy8106a_set_voltage_sel,
>> +       .set_voltage_time_sel = regulator_set_voltage_time_sel,
>> +       .get_voltage_sel = regulator_get_voltage_sel_regmap,
>> +       .list_voltage = regulator_list_voltage_linear,
> 
> No enable/disable ops?
> 
>> +};
>> +
>> +/* Default limits measured in millivolts and milliamps */
>> +#define SY8106A_MIN_MV         680
>> +#define SY8106A_MAX_MV         1950
>> +#define SY8106A_STEP_MV                10
>> +
>> +static const struct regulator_desc sy8106a_reg = {
>> +       .name = "SY8106A",
>> +       .id = 0,
>> +       .ops = &sy8106a_ops,
>> +       .type = REGULATOR_VOLTAGE,
>> +       .n_voltages = ((SY8106A_MAX_MV - SY8106A_MIN_MV) / 
>> SY8106A_STEP_MV) + 1,
>> +       .min_uV = (SY8106A_MIN_MV * 1000),
>> +       .uV_step = (SY8106A_STEP_MV * 1000),
>> +       .vsel_reg = SY8106A_REG_VOUT1_SEL,
>> +       .vsel_mask = SY8106A_REG_VOUT1_SEL_MASK,
>> +       .enable_reg = SY8106A_REG_VOUT_COM,
>> +       .enable_mask = SY8106A_DISABLE_REG,
>> +       .disable_val = SY8106A_DISABLE_REG,
>> +       .enable_is_inverted = 1,
> 
> As the regulator core helpers currently are, there is no way to disable
> this regulator. regulator_disable_regmap looks like:

By reading the current code, I think removing the disable_val variable 
will
just make it work -- when enabling, the enable_reg will be set to 
disable_val
(as enable_is_inverted is 1), and disable_val is defaultly 0; when 
disabling,
the enable_reg will be set to enable_mask (fallbacked from enable_val, 
which
is also the default value 0), and the regulator successfully get 
disabled.

> 
>         if (rdev->desc->enable_is_inverted) {
>                 val = rdev->desc->enable_val;
>                 if (!val)
>                         val = rdev->desc->enable_mask;
>         } else {
>                 val = rdev->desc->disable_val;
>         }
> 
>         return regmap_update_bits(rdev->regmap, rdev->desc->enable_reg,
>                                   rdev->desc->enable_mask, val);
> 
> Note the fallback to enable_mask if enable_val is not set. The enable
> helper has a similar structure. This regulator uses an enable value
> of 0, and disable value of 1, it is impossible to get it right. As
> it is now, it doesn't really make sense to me.
> 
> The code was introduced in ca5d1b3524b4 ("regulator: helpers: Modify
> helpers enabling multi-bit control"). I wonder if it was an unintended
> consequence of the change? (original author CC-ed)
> 
>> +       .owner = THIS_MODULE,
>> +};
>> +
>> +/*
>> + * I2C driver interface functions
>> + */
>> +static int sy8106a_i2c_probe(struct i2c_client *i2c,
>> +                           const struct i2c_device_id *id)
>> +{
>> +       struct sy8106a *chip;
>> +       struct device *dev = &i2c->dev;
>> +       struct regulator_dev *rdev = NULL;
>> +       struct regulator_config config = { };
>> +       unsigned int selector;
>> +       int error;
>> +
>> +       chip = devm_kzalloc(&i2c->dev, sizeof(struct sy8106a), 
>> GFP_KERNEL);
>> +       if (!chip)
>> +               return -ENOMEM;
>> +
>> +       chip->regmap = devm_regmap_init_i2c(i2c, 
>> &sy8106a_regmap_config);
>> +       if (IS_ERR(chip->regmap)) {
>> +               error = PTR_ERR(chip->regmap);
>> +               dev_err(&i2c->dev, "Failed to allocate register map: 
>> %d\n",
>> +                       error);
>> +               return error;
>> +       }
>> +
>> +       config.dev = &i2c->dev;
>> +       config.regmap = chip->regmap;
>> +       config.driver_data = chip;
>> +
>> +       config.of_node = dev->of_node;
>> +       config.init_data = of_get_regulator_init_data(dev, 
>> dev->of_node,
>> +                                                     &sy8106a_reg);
>> +
>> +       if (!config.init_data)
>> +               return -ENOMEM;
>> +
>> +       /* Probe regulator */
>> +       error = regmap_read(chip->regmap, SY8106A_REG_VOUT1_SEL, 
>> &selector);
>> +       if (error) {
>> +               dev_err(&i2c->dev, "Failed to read voltage at probe 
>> time: %d\n", error);
>> +               return error;
>> +       }
>> +
>> +       rdev = devm_regulator_register(&i2c->dev, &sy8106a_reg, 
>> &config);
>> +       if (IS_ERR(rdev)) {
>> +               error = PTR_ERR(rdev);
>> +               dev_err(&i2c->dev, "Failed to register SY8106A 
>> regulator: %d\n", error);
>> +               return error;
>> +       }
>> +
>> +       chip->rdev = rdev;
>> +
>> +       i2c_set_clientdata(i2c, chip);
>> +
>> +       return 0;
>> +}
>> +
>> +static const struct of_device_id sy8106a_i2c_of_match[] = {
>> +       { .compatible = "silergy,sy8106a" },
>> +       { },
>> +};
>> +MODULE_DEVICE_TABLE(of, sy8106a_i2c_of_match);
>> +
>> +static const struct i2c_device_id sy8106a_i2c_id[] = {
>> +       { "sy8106a", 0 },
>> +       { },
>> +};
>> +MODULE_DEVICE_TABLE(i2c, sy8106a_i2c_id);
>> +
>> +static struct i2c_driver sy8106a_regulator_driver = {
>> +       .driver = {
>> +               .name = "sy8106a",
>> +               .of_match_table = of_match_ptr(sy8106a_i2c_of_match),
>> +       },
>> +       .probe = sy8106a_i2c_probe,
>> +       .id_table = sy8106a_i2c_id,
>> +};
>> +
>> +module_i2c_driver(sy8106a_regulator_driver);
>> +
>> +MODULE_AUTHOR("Ondřej Jirman <megous@megous.com>");
>> +MODULE_DESCRIPTION("Regulator device driver for Silergy SY8106A");
>> +MODULE_LICENSE("GPL v2");
> 
> This should be "GPL", to match what the license at the very top says.
> 
> Regards
> ChenYu
> 
>> --
>> 2.13.0
>> 
>> --
>> You received this message because you are subscribed to the Google 
>> Groups "linux-sunxi" group.
>> To unsubscribe from this group and stop receiving emails from it, send 
>> an email to linux-sunxi+unsubscribe@googlegroups.com.
>> For more options, visit https://groups.google.com/d/optout.
> 
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[toc] | [prev] | [next] | [standalone]


#1694428 — Re: [linux-sunxi] [PATCH 02/10] regulator: add support for SY8106A regulator

Fromicenowy@aosc.io
Date2017-07-24 05:40 +0200
SubjectRe: [linux-sunxi] [PATCH 02/10] regulator: add support for SY8106A regulator
Message-ID<u6CnT-7QV-5@gated-at.bofh.it>
In reply to#1694421
在 2017-07-24 11:33,Chen-Yu Tsai 写道:
> On Mon, Jul 24, 2017 at 11:18 AM,  <icenowy@aosc.io> wrote:
>> 在 2017-07-24 11:03,Chen-Yu Tsai 写道:
>>> 
>>> On Sun, Jul 23, 2017 at 6:27 PM, Icenowy Zheng <icenowy@aosc.io> 
>>> wrote:
>>>> 
>>>> From: Ondrej Jirman <megous@megous.com>
>>>> 
>>>> SY8106A is an I2C attached single output regulator made by Silergy 
>>>> Corp,
>>>> which is used on several Allwinner H3/H5 SBCs to control the power
>>>> supply of the ARM cores.
>>>> 
>>>> Add a driver for it.
>>>> 
>>>> Signed-off-by: Ondrej Jirman <megous@megous.com>
>>>> [Icenowy: Change commit message]
>>>> Signed-off-by: Icenowy Zheng <icenowy@aosc.io>
>>>> ---
>>>>  drivers/regulator/Kconfig             |   8 +-
>>>>  drivers/regulator/Makefile            |   2 +-
>>>>  drivers/regulator/sy8106a-regulator.c | 163
>>>> ++++++++++++++++++++++++++++++++++
>>>>  3 files changed, 171 insertions(+), 2 deletions(-)
>>>>  create mode 100644 drivers/regulator/sy8106a-regulator.c
>>>> 
>>>> diff --git a/drivers/regulator/Kconfig b/drivers/regulator/Kconfig
>>>> index 99b9362331b5..1efa73e18d07 100644
>>>> --- a/drivers/regulator/Kconfig
>>>> +++ b/drivers/regulator/Kconfig
>>>> @@ -764,6 +764,13 @@ config REGULATOR_STW481X_VMMC
>>>>           This driver supports the internal VMMC regulator in the 
>>>> STw481x
>>>>           PMIC chips.
>>>> 
>>>> +config REGULATOR_SY8106A
>>>> +       tristate "Silergy SY8106A regulator"
>>>> +       depends on I2C && (OF || COMPILE_TEST)
>>>> +       select REGMAP_I2C
>>>> +       help
>>>> +         This driver supports SY8106A single output regulator.
>>>> +
>>>>  config REGULATOR_TPS51632
>>>>         tristate "TI TPS51632 Power Regulator"
>>>>         depends on I2C
>>>> @@ -938,4 +945,3 @@ config REGULATOR_WM8994
>>>>           WM8994 CODEC.
>>>> 
>>>>  endif
>>>> -
>>>> diff --git a/drivers/regulator/Makefile b/drivers/regulator/Makefile
>>>> index 95b1e86ae692..f5120252f86a 100644
>>>> --- a/drivers/regulator/Makefile
>>>> +++ b/drivers/regulator/Makefile
>>>> @@ -95,6 +95,7 @@ obj-$(CONFIG_REGULATOR_S2MPS11) += s2mps11.o
>>>>  obj-$(CONFIG_REGULATOR_S5M8767) += s5m8767.o
>>>>  obj-$(CONFIG_REGULATOR_SKY81452) += sky81452-regulator.o
>>>>  obj-$(CONFIG_REGULATOR_STW481X_VMMC) += stw481x-vmmc.o
>>>> +obj-$(CONFIG_REGULATOR_SY8106A) += sy8106a-regulator.o
>>>>  obj-$(CONFIG_REGULATOR_TI_ABB) += ti-abb-regulator.o
>>>>  obj-$(CONFIG_REGULATOR_TPS6105X) += tps6105x-regulator.o
>>>>  obj-$(CONFIG_REGULATOR_TPS62360) += tps62360-regulator.o
>>>> @@ -120,5 +121,4 @@ obj-$(CONFIG_REGULATOR_WM8350) += 
>>>> wm8350-regulator.o
>>>>  obj-$(CONFIG_REGULATOR_WM8400) += wm8400-regulator.o
>>>>  obj-$(CONFIG_REGULATOR_WM8994) += wm8994-regulator.o
>>>> 
>>>> -
>>>>  ccflags-$(CONFIG_REGULATOR_DEBUG) += -DDEBUG
>>>> diff --git a/drivers/regulator/sy8106a-regulator.c
>>>> b/drivers/regulator/sy8106a-regulator.c
>>>> new file mode 100644
>>>> index 000000000000..1df889f68b3d
>>>> --- /dev/null
>>>> +++ b/drivers/regulator/sy8106a-regulator.c
>>>> @@ -0,0 +1,163 @@
>>>> +/*
>>>> + * sy8106a-regulator.c - Regulator device driver for SY8106A
>>>> + *
>>>> + * Copyright (C) 2016 Ondřej Jirman <megous@megous.com>
>>>> + *
>>>> + * This program is free software; you can redistribute it and/or
>>>> + * modify it under the terms of the GNU Library General Public
>>>> + * License as published by the Free Software Foundation; either
>>>> + * version 2 of the License, or (at your option) any later version.
>>>> + *
>>>> + * This program is distributed in the hope that it will be useful,
>>>> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
>>>> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the 
>>>> GNU
>>>> + * Library General Public License for more details.
>>>> + */
>>>> +
>>>> +#include <linux/err.h>
>>>> +#include <linux/i2c.h>
>>>> +#include <linux/module.h>
>>>> +#include <linux/regmap.h>
>>>> +#include <linux/regulator/driver.h>
>>>> +#include <linux/regulator/of_regulator.h>
>>>> +
>>>> +#define SY8106A_REG_VOUT1_SEL          0x01
>>>> +#define SY8106A_REG_VOUT_COM           0x02
>>>> +#define SY8106A_REG_VOUT1_SEL_MASK     0x7f
>>>> +#define SY8106A_DISABLE_REG            BIT(0)
>>>> +#define SY8106A_GO_BIT                 BIT(7)
>>>> +
>>>> +struct sy8106a {
>>>> +       struct regulator_dev *rdev;
>>>> +       struct regmap *regmap;
>>>> +};
>>>> +
>>>> +static const struct regmap_config sy8106a_regmap_config = {
>>>> +       .reg_bits = 8,
>>>> +       .val_bits = 8,
>>>> +};
>>>> +
>>>> +static int sy8106a_set_voltage_sel(struct regulator_dev *rdev, 
>>>> unsigned
>>>> int sel)
>>>> +{
>>>> +       /* We use our set_voltage_sel in order to avoid unnecessary 
>>>> I2C
>>>> +        * chatter, because the regulator_get_voltage_sel_regmap 
>>>> using
>>>> +        * apply_bit would perform 4 unnecessary transfers instead 
>>>> of
>>>> one,
>>>> +        * increasing the chance of error.
>>>> +        */
>>>> +       return regmap_write(rdev->regmap, rdev->desc->vsel_reg,
>>>> +                           sel | SY8106A_GO_BIT);
>>> 
>>> 
>>> There should also be an explanation of what the "go bit" does.
>>> In this case it enables control of the voltage over I2C.
>>> 
>>>> +}
>>>> +
>>>> +static const struct regulator_ops sy8106a_ops = {
>>>> +       .is_enabled = regulator_is_enabled_regmap,
>>>> +       .set_voltage_sel = sy8106a_set_voltage_sel,
>>>> +       .set_voltage_time_sel = regulator_set_voltage_time_sel,
>>>> +       .get_voltage_sel = regulator_get_voltage_sel_regmap,
>>>> +       .list_voltage = regulator_list_voltage_linear,
>>> 
>>> 
>>> No enable/disable ops?
>>> 
>>>> +};
>>>> +
>>>> +/* Default limits measured in millivolts and milliamps */
>>>> +#define SY8106A_MIN_MV         680
>>>> +#define SY8106A_MAX_MV         1950
>>>> +#define SY8106A_STEP_MV                10
>>>> +
>>>> +static const struct regulator_desc sy8106a_reg = {
>>>> +       .name = "SY8106A",
>>>> +       .id = 0,
>>>> +       .ops = &sy8106a_ops,
>>>> +       .type = REGULATOR_VOLTAGE,
>>>> +       .n_voltages = ((SY8106A_MAX_MV - SY8106A_MIN_MV) /
>>>> SY8106A_STEP_MV) + 1,
>>>> +       .min_uV = (SY8106A_MIN_MV * 1000),
>>>> +       .uV_step = (SY8106A_STEP_MV * 1000),
>>>> +       .vsel_reg = SY8106A_REG_VOUT1_SEL,
>>>> +       .vsel_mask = SY8106A_REG_VOUT1_SEL_MASK,
>>>> +       .enable_reg = SY8106A_REG_VOUT_COM,
>>>> +       .enable_mask = SY8106A_DISABLE_REG,
>>>> +       .disable_val = SY8106A_DISABLE_REG,
>>>> +       .enable_is_inverted = 1,
>>> 
>>> 
>>> As the regulator core helpers currently are, there is no way to 
>>> disable
>>> this regulator. regulator_disable_regmap looks like:
>> 
>> 
>> By reading the current code, I think removing the disable_val variable 
>> will
>> just make it work -- when enabling, the enable_reg will be set to 
>> disable_val
>> (as enable_is_inverted is 1), and disable_val is defaultly 0; when 
>> disabling,
>> the enable_reg will be set to enable_mask (fallbacked from enable_val, 
>> which
>> is also the default value 0), and the regulator successfully get 
>> disabled.
> 
> (Gmail is wrapping the lines :( )
> 
> enable_mask is set to SY8106A_DISABLE_REG, which equals disable_val 
> here,
> which is not 0. This is correct, as it is the bit mask passed to
> regmap_update_bits. So no, it does not work.

 From my personal understanding of the code, the behavior of 
enable_is_inverted
is that switch the roles of enable_val and disable_val, so if
enable_is_inverted is set, the regulator_disable_regmap function will 
write
enable_val (if it's 0, fallback to enable_mask) to the register, and
regulator_enable_regmap will write disable_val.

Maybe this design is used to ensure enable_val (then fallback to 
enable_mask)
is not 0.

> 
> It seems quite a lot of drivers depend on this fallback behavior 
> though.
> 
> ChenYu
> 
>> 
>>> 
>>>         if (rdev->desc->enable_is_inverted) {
>>>                 val = rdev->desc->enable_val;
>>>                 if (!val)
>>>                         val = rdev->desc->enable_mask;
>>>         } else {
>>>                 val = rdev->desc->disable_val;
>>>         }
>>> 
>>>         return regmap_update_bits(rdev->regmap, 
>>> rdev->desc->enable_reg,
>>>                                   rdev->desc->enable_mask, val);
>>> 
>>> Note the fallback to enable_mask if enable_val is not set. The enable
>>> helper has a similar structure. This regulator uses an enable value
>>> of 0, and disable value of 1, it is impossible to get it right. As
>>> it is now, it doesn't really make sense to me.
>>> 
>>> The code was introduced in ca5d1b3524b4 ("regulator: helpers: Modify
>>> helpers enabling multi-bit control"). I wonder if it was an 
>>> unintended
>>> consequence of the change? (original author CC-ed)
>>> 
>>>> +       .owner = THIS_MODULE,
>>>> +};
>>>> +
>>>> +/*
>>>> + * I2C driver interface functions
>>>> + */
>>>> +static int sy8106a_i2c_probe(struct i2c_client *i2c,
>>>> +                           const struct i2c_device_id *id)
>>>> +{
>>>> +       struct sy8106a *chip;
>>>> +       struct device *dev = &i2c->dev;
>>>> +       struct regulator_dev *rdev = NULL;
>>>> +       struct regulator_config config = { };
>>>> +       unsigned int selector;
>>>> +       int error;
>>>> +
>>>> +       chip = devm_kzalloc(&i2c->dev, sizeof(struct sy8106a),
>>>> GFP_KERNEL);
>>>> +       if (!chip)
>>>> +               return -ENOMEM;
>>>> +
>>>> +       chip->regmap = devm_regmap_init_i2c(i2c, 
>>>> &sy8106a_regmap_config);
>>>> +       if (IS_ERR(chip->regmap)) {
>>>> +               error = PTR_ERR(chip->regmap);
>>>> +               dev_err(&i2c->dev, "Failed to allocate register map:
>>>> %d\n",
>>>> +                       error);
>>>> +               return error;
>>>> +       }
>>>> +
>>>> +       config.dev = &i2c->dev;
>>>> +       config.regmap = chip->regmap;
>>>> +       config.driver_data = chip;
>>>> +
>>>> +       config.of_node = dev->of_node;
>>>> +       config.init_data = of_get_regulator_init_data(dev, 
>>>> dev->of_node,
>>>> +                                                     &sy8106a_reg);
>>>> +
>>>> +       if (!config.init_data)
>>>> +               return -ENOMEM;
>>>> +
>>>> +       /* Probe regulator */
>>>> +       error = regmap_read(chip->regmap, SY8106A_REG_VOUT1_SEL,
>>>> &selector);
>>>> +       if (error) {
>>>> +               dev_err(&i2c->dev, "Failed to read voltage at probe 
>>>> time:
>>>> %d\n", error);
>>>> +               return error;
>>>> +       }
>>>> +
>>>> +       rdev = devm_regulator_register(&i2c->dev, &sy8106a_reg, 
>>>> &config);
>>>> +       if (IS_ERR(rdev)) {
>>>> +               error = PTR_ERR(rdev);
>>>> +               dev_err(&i2c->dev, "Failed to register SY8106A 
>>>> regulator:
>>>> %d\n", error);
>>>> +               return error;
>>>> +       }
>>>> +
>>>> +       chip->rdev = rdev;
>>>> +
>>>> +       i2c_set_clientdata(i2c, chip);
>>>> +
>>>> +       return 0;
>>>> +}
>>>> +
>>>> +static const struct of_device_id sy8106a_i2c_of_match[] = {
>>>> +       { .compatible = "silergy,sy8106a" },
>>>> +       { },
>>>> +};
>>>> +MODULE_DEVICE_TABLE(of, sy8106a_i2c_of_match);
>>>> +
>>>> +static const struct i2c_device_id sy8106a_i2c_id[] = {
>>>> +       { "sy8106a", 0 },
>>>> +       { },
>>>> +};
>>>> +MODULE_DEVICE_TABLE(i2c, sy8106a_i2c_id);
>>>> +
>>>> +static struct i2c_driver sy8106a_regulator_driver = {
>>>> +       .driver = {
>>>> +               .name = "sy8106a",
>>>> +               .of_match_table = 
>>>> of_match_ptr(sy8106a_i2c_of_match),
>>>> +       },
>>>> +       .probe = sy8106a_i2c_probe,
>>>> +       .id_table = sy8106a_i2c_id,
>>>> +};
>>>> +
>>>> +module_i2c_driver(sy8106a_regulator_driver);
>>>> +
>>>> +MODULE_AUTHOR("Ondřej Jirman <megous@megous.com>");
>>>> +MODULE_DESCRIPTION("Regulator device driver for Silergy SY8106A");
>>>> +MODULE_LICENSE("GPL v2");
>>> 
>>> 
>>> This should be "GPL", to match what the license at the very top says.
>>> 
>>> Regards
>>> ChenYu
>>> 
>>>> --
>>>> 2.13.0
>>>> 
>>>> --
>>>> You received this message because you are subscribed to the Google 
>>>> Groups
>>>> "linux-sunxi" group.
>>>> To unsubscribe from this group and stop receiving emails from it, 
>>>> send an
>>>> email to linux-sunxi+unsubscribe@googlegroups.com.
>>>> For more options, visit https://groups.google.com/d/optout.
>>> 
>>> 
>>> _______________________________________________
>>> linux-arm-kernel mailing list
>>> linux-arm-kernel@lists.infradead.org
>>> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>> 
>> 
>> --
>> You received this message because you are subscribed to the Google 
>> Groups
>> "linux-sunxi" group.
>> To unsubscribe from this group and stop receiving emails from it, send 
>> an
>> email to linux-sunxi+unsubscribe@googlegroups.com.
>> For more options, visit https://groups.google.com/d/optout.

[toc] | [prev] | [next] | [standalone]


#1694470 — Re: [linux-sunxi] [PATCH 02/10] regulator: add support for SY8106A regulator

FromChen-Yu Tsai <wens@csie.org>
Date2017-07-24 08:20 +0200
SubjectRe: [linux-sunxi] [PATCH 02/10] regulator: add support for SY8106A regulator
Message-ID<u6ESJ-16u-5@gated-at.bofh.it>
In reply to#1694428
On Mon, Jul 24, 2017 at 11:38 AM,  <icenowy@aosc.io> wrote:
> 在 2017-07-24 11:33,Chen-Yu Tsai 写道:
>>
>> On Mon, Jul 24, 2017 at 11:18 AM,  <icenowy@aosc.io> wrote:
>>>
>>> 在 2017-07-24 11:03,Chen-Yu Tsai 写道:
>>>>
>>>>
>>>> On Sun, Jul 23, 2017 at 6:27 PM, Icenowy Zheng <icenowy@aosc.io> wrote:
>>>>>
>>>>>
>>>>> From: Ondrej Jirman <megous@megous.com>
>>>>>
>>>>> SY8106A is an I2C attached single output regulator made by Silergy
>>>>> Corp,
>>>>> which is used on several Allwinner H3/H5 SBCs to control the power
>>>>> supply of the ARM cores.
>>>>>
>>>>> Add a driver for it.
>>>>>
>>>>> Signed-off-by: Ondrej Jirman <megous@megous.com>
>>>>> [Icenowy: Change commit message]
>>>>> Signed-off-by: Icenowy Zheng <icenowy@aosc.io>
>>>>> ---
>>>>>  drivers/regulator/Kconfig             |   8 +-
>>>>>  drivers/regulator/Makefile            |   2 +-
>>>>>  drivers/regulator/sy8106a-regulator.c | 163
>>>>> ++++++++++++++++++++++++++++++++++
>>>>>  3 files changed, 171 insertions(+), 2 deletions(-)
>>>>>  create mode 100644 drivers/regulator/sy8106a-regulator.c
>>>>>
>>>>> diff --git a/drivers/regulator/Kconfig b/drivers/regulator/Kconfig
>>>>> index 99b9362331b5..1efa73e18d07 100644
>>>>> --- a/drivers/regulator/Kconfig
>>>>> +++ b/drivers/regulator/Kconfig
>>>>> @@ -764,6 +764,13 @@ config REGULATOR_STW481X_VMMC
>>>>>           This driver supports the internal VMMC regulator in the
>>>>> STw481x
>>>>>           PMIC chips.
>>>>>
>>>>> +config REGULATOR_SY8106A
>>>>> +       tristate "Silergy SY8106A regulator"
>>>>> +       depends on I2C && (OF || COMPILE_TEST)
>>>>> +       select REGMAP_I2C
>>>>> +       help
>>>>> +         This driver supports SY8106A single output regulator.
>>>>> +
>>>>>  config REGULATOR_TPS51632
>>>>>         tristate "TI TPS51632 Power Regulator"
>>>>>         depends on I2C
>>>>> @@ -938,4 +945,3 @@ config REGULATOR_WM8994
>>>>>           WM8994 CODEC.
>>>>>
>>>>>  endif
>>>>> -
>>>>> diff --git a/drivers/regulator/Makefile b/drivers/regulator/Makefile
>>>>> index 95b1e86ae692..f5120252f86a 100644
>>>>> --- a/drivers/regulator/Makefile
>>>>> +++ b/drivers/regulator/Makefile
>>>>> @@ -95,6 +95,7 @@ obj-$(CONFIG_REGULATOR_S2MPS11) += s2mps11.o
>>>>>  obj-$(CONFIG_REGULATOR_S5M8767) += s5m8767.o
>>>>>  obj-$(CONFIG_REGULATOR_SKY81452) += sky81452-regulator.o
>>>>>  obj-$(CONFIG_REGULATOR_STW481X_VMMC) += stw481x-vmmc.o
>>>>> +obj-$(CONFIG_REGULATOR_SY8106A) += sy8106a-regulator.o
>>>>>  obj-$(CONFIG_REGULATOR_TI_ABB) += ti-abb-regulator.o
>>>>>  obj-$(CONFIG_REGULATOR_TPS6105X) += tps6105x-regulator.o
>>>>>  obj-$(CONFIG_REGULATOR_TPS62360) += tps62360-regulator.o
>>>>> @@ -120,5 +121,4 @@ obj-$(CONFIG_REGULATOR_WM8350) +=
>>>>> wm8350-regulator.o
>>>>>  obj-$(CONFIG_REGULATOR_WM8400) += wm8400-regulator.o
>>>>>  obj-$(CONFIG_REGULATOR_WM8994) += wm8994-regulator.o
>>>>>
>>>>> -
>>>>>  ccflags-$(CONFIG_REGULATOR_DEBUG) += -DDEBUG
>>>>> diff --git a/drivers/regulator/sy8106a-regulator.c
>>>>> b/drivers/regulator/sy8106a-regulator.c
>>>>> new file mode 100644
>>>>> index 000000000000..1df889f68b3d
>>>>> --- /dev/null
>>>>> +++ b/drivers/regulator/sy8106a-regulator.c
>>>>> @@ -0,0 +1,163 @@
>>>>> +/*
>>>>> + * sy8106a-regulator.c - Regulator device driver for SY8106A
>>>>> + *
>>>>> + * Copyright (C) 2016 Ondřej Jirman <megous@megous.com>
>>>>> + *
>>>>> + * This program is free software; you can redistribute it and/or
>>>>> + * modify it under the terms of the GNU Library General Public
>>>>> + * License as published by the Free Software Foundation; either
>>>>> + * version 2 of the License, or (at your option) any later version.
>>>>> + *
>>>>> + * This program is distributed in the hope that it will be useful,
>>>>> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
>>>>> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
>>>>> + * Library General Public License for more details.
>>>>> + */
>>>>> +
>>>>> +#include <linux/err.h>
>>>>> +#include <linux/i2c.h>
>>>>> +#include <linux/module.h>
>>>>> +#include <linux/regmap.h>
>>>>> +#include <linux/regulator/driver.h>
>>>>> +#include <linux/regulator/of_regulator.h>
>>>>> +
>>>>> +#define SY8106A_REG_VOUT1_SEL          0x01
>>>>> +#define SY8106A_REG_VOUT_COM           0x02
>>>>> +#define SY8106A_REG_VOUT1_SEL_MASK     0x7f
>>>>> +#define SY8106A_DISABLE_REG            BIT(0)
>>>>> +#define SY8106A_GO_BIT                 BIT(7)
>>>>> +
>>>>> +struct sy8106a {
>>>>> +       struct regulator_dev *rdev;
>>>>> +       struct regmap *regmap;
>>>>> +};
>>>>> +
>>>>> +static const struct regmap_config sy8106a_regmap_config = {
>>>>> +       .reg_bits = 8,
>>>>> +       .val_bits = 8,
>>>>> +};
>>>>> +
>>>>> +static int sy8106a_set_voltage_sel(struct regulator_dev *rdev,
>>>>> unsigned
>>>>> int sel)
>>>>> +{
>>>>> +       /* We use our set_voltage_sel in order to avoid unnecessary I2C
>>>>> +        * chatter, because the regulator_get_voltage_sel_regmap using
>>>>> +        * apply_bit would perform 4 unnecessary transfers instead of
>>>>> one,
>>>>> +        * increasing the chance of error.
>>>>> +        */
>>>>> +       return regmap_write(rdev->regmap, rdev->desc->vsel_reg,
>>>>> +                           sel | SY8106A_GO_BIT);
>>>>
>>>>
>>>>
>>>> There should also be an explanation of what the "go bit" does.
>>>> In this case it enables control of the voltage over I2C.
>>>>
>>>>> +}
>>>>> +
>>>>> +static const struct regulator_ops sy8106a_ops = {
>>>>> +       .is_enabled = regulator_is_enabled_regmap,
>>>>> +       .set_voltage_sel = sy8106a_set_voltage_sel,
>>>>> +       .set_voltage_time_sel = regulator_set_voltage_time_sel,
>>>>> +       .get_voltage_sel = regulator_get_voltage_sel_regmap,
>>>>> +       .list_voltage = regulator_list_voltage_linear,
>>>>
>>>>
>>>>
>>>> No enable/disable ops?
>>>>
>>>>> +};
>>>>> +
>>>>> +/* Default limits measured in millivolts and milliamps */
>>>>> +#define SY8106A_MIN_MV         680
>>>>> +#define SY8106A_MAX_MV         1950
>>>>> +#define SY8106A_STEP_MV                10
>>>>> +
>>>>> +static const struct regulator_desc sy8106a_reg = {
>>>>> +       .name = "SY8106A",
>>>>> +       .id = 0,
>>>>> +       .ops = &sy8106a_ops,
>>>>> +       .type = REGULATOR_VOLTAGE,
>>>>> +       .n_voltages = ((SY8106A_MAX_MV - SY8106A_MIN_MV) /
>>>>> SY8106A_STEP_MV) + 1,
>>>>> +       .min_uV = (SY8106A_MIN_MV * 1000),
>>>>> +       .uV_step = (SY8106A_STEP_MV * 1000),
>>>>> +       .vsel_reg = SY8106A_REG_VOUT1_SEL,
>>>>> +       .vsel_mask = SY8106A_REG_VOUT1_SEL_MASK,
>>>>> +       .enable_reg = SY8106A_REG_VOUT_COM,
>>>>> +       .enable_mask = SY8106A_DISABLE_REG,
>>>>> +       .disable_val = SY8106A_DISABLE_REG,
>>>>> +       .enable_is_inverted = 1,
>>>>
>>>>
>>>>
>>>> As the regulator core helpers currently are, there is no way to disable
>>>> this regulator. regulator_disable_regmap looks like:
>>>
>>>
>>>
>>> By reading the current code, I think removing the disable_val variable
>>> will
>>> just make it work -- when enabling, the enable_reg will be set to
>>> disable_val
>>> (as enable_is_inverted is 1), and disable_val is defaultly 0; when
>>> disabling,
>>> the enable_reg will be set to enable_mask (fallbacked from enable_val,
>>> which
>>> is also the default value 0), and the regulator successfully get
>>> disabled.
>>
>>
>> (Gmail is wrapping the lines :( )
>>
>> enable_mask is set to SY8106A_DISABLE_REG, which equals disable_val here,
>> which is not 0. This is correct, as it is the bit mask passed to
>> regmap_update_bits. So no, it does not work.
>
>
> From my personal understanding of the code, the behavior of
> enable_is_inverted
> is that switch the roles of enable_val and disable_val, so if
> enable_is_inverted is set, the regulator_disable_regmap function will write
> enable_val (if it's 0, fallback to enable_mask) to the register, and
> regulator_enable_regmap will write disable_val.
>
> Maybe this design is used to ensure enable_val (then fallback to
> enable_mask)
> is not 0.

I think the changes needed to the core are probably too invasive, i.e.
affect too many other drivers, to be worth doing. Especially since we
won't really be using enable/disable much, as the regulator supplies
the CPU cores.

For now, lets just remove the enable/disable related fields, and leave
a TODO note citing the possibly required changes to the core instead.
You haven't assigned the callbacks anyway.

ChenYu

>
>
>>
>> It seems quite a lot of drivers depend on this fallback behavior though.
>>
>> ChenYu
>>
>>>
>>>>
>>>>         if (rdev->desc->enable_is_inverted) {
>>>>                 val = rdev->desc->enable_val;
>>>>                 if (!val)
>>>>                         val = rdev->desc->enable_mask;
>>>>         } else {
>>>>                 val = rdev->desc->disable_val;
>>>>         }
>>>>
>>>>         return regmap_update_bits(rdev->regmap, rdev->desc->enable_reg,
>>>>                                   rdev->desc->enable_mask, val);
>>>>
>>>> Note the fallback to enable_mask if enable_val is not set. The enable
>>>> helper has a similar structure. This regulator uses an enable value
>>>> of 0, and disable value of 1, it is impossible to get it right. As
>>>> it is now, it doesn't really make sense to me.
>>>>
>>>> The code was introduced in ca5d1b3524b4 ("regulator: helpers: Modify
>>>> helpers enabling multi-bit control"). I wonder if it was an unintended
>>>> consequence of the change? (original author CC-ed)
>>>>
>>>>> +       .owner = THIS_MODULE,
>>>>> +};
>>>>> +
>>>>> +/*
>>>>> + * I2C driver interface functions
>>>>> + */
>>>>> +static int sy8106a_i2c_probe(struct i2c_client *i2c,
>>>>> +                           const struct i2c_device_id *id)
>>>>> +{
>>>>> +       struct sy8106a *chip;
>>>>> +       struct device *dev = &i2c->dev;
>>>>> +       struct regulator_dev *rdev = NULL;
>>>>> +       struct regulator_config config = { };
>>>>> +       unsigned int selector;
>>>>> +       int error;
>>>>> +
>>>>> +       chip = devm_kzalloc(&i2c->dev, sizeof(struct sy8106a),
>>>>> GFP_KERNEL);
>>>>> +       if (!chip)
>>>>> +               return -ENOMEM;
>>>>> +
>>>>> +       chip->regmap = devm_regmap_init_i2c(i2c,
>>>>> &sy8106a_regmap_config);
>>>>> +       if (IS_ERR(chip->regmap)) {
>>>>> +               error = PTR_ERR(chip->regmap);
>>>>> +               dev_err(&i2c->dev, "Failed to allocate register map:
>>>>> %d\n",
>>>>> +                       error);
>>>>> +               return error;
>>>>> +       }
>>>>> +
>>>>> +       config.dev = &i2c->dev;
>>>>> +       config.regmap = chip->regmap;
>>>>> +       config.driver_data = chip;
>>>>> +
>>>>> +       config.of_node = dev->of_node;
>>>>> +       config.init_data = of_get_regulator_init_data(dev,
>>>>> dev->of_node,
>>>>> +                                                     &sy8106a_reg);
>>>>> +
>>>>> +       if (!config.init_data)
>>>>> +               return -ENOMEM;
>>>>> +
>>>>> +       /* Probe regulator */
>>>>> +       error = regmap_read(chip->regmap, SY8106A_REG_VOUT1_SEL,
>>>>> &selector);
>>>>> +       if (error) {
>>>>> +               dev_err(&i2c->dev, "Failed to read voltage at probe
>>>>> time:
>>>>> %d\n", error);
>>>>> +               return error;
>>>>> +       }
>>>>> +
>>>>> +       rdev = devm_regulator_register(&i2c->dev, &sy8106a_reg,
>>>>> &config);
>>>>> +       if (IS_ERR(rdev)) {
>>>>> +               error = PTR_ERR(rdev);
>>>>> +               dev_err(&i2c->dev, "Failed to register SY8106A
>>>>> regulator:
>>>>> %d\n", error);
>>>>> +               return error;
>>>>> +       }
>>>>> +
>>>>> +       chip->rdev = rdev;
>>>>> +
>>>>> +       i2c_set_clientdata(i2c, chip);
>>>>> +
>>>>> +       return 0;
>>>>> +}
>>>>> +
>>>>> +static const struct of_device_id sy8106a_i2c_of_match[] = {
>>>>> +       { .compatible = "silergy,sy8106a" },
>>>>> +       { },
>>>>> +};
>>>>> +MODULE_DEVICE_TABLE(of, sy8106a_i2c_of_match);
>>>>> +
>>>>> +static const struct i2c_device_id sy8106a_i2c_id[] = {
>>>>> +       { "sy8106a", 0 },
>>>>> +       { },
>>>>> +};
>>>>> +MODULE_DEVICE_TABLE(i2c, sy8106a_i2c_id);
>>>>> +
>>>>> +static struct i2c_driver sy8106a_regulator_driver = {
>>>>> +       .driver = {
>>>>> +               .name = "sy8106a",
>>>>> +               .of_match_table = of_match_ptr(sy8106a_i2c_of_match),
>>>>> +       },
>>>>> +       .probe = sy8106a_i2c_probe,
>>>>> +       .id_table = sy8106a_i2c_id,
>>>>> +};
>>>>> +
>>>>> +module_i2c_driver(sy8106a_regulator_driver);
>>>>> +
>>>>> +MODULE_AUTHOR("Ondřej Jirman <megous@megous.com>");
>>>>> +MODULE_DESCRIPTION("Regulator device driver for Silergy SY8106A");
>>>>> +MODULE_LICENSE("GPL v2");
>>>>
>>>>
>>>>
>>>> This should be "GPL", to match what the license at the very top says.
>>>>
>>>> Regards
>>>> ChenYu
>>>>
>>>>> --
>>>>> 2.13.0
>>>>>
>>>>> --
>>>>> You received this message because you are subscribed to the Google
>>>>> Groups
>>>>> "linux-sunxi" group.
>>>>> To unsubscribe from this group and stop receiving emails from it, send
>>>>> an
>>>>> email to linux-sunxi+unsubscribe@googlegroups.com.
>>>>> For more options, visit https://groups.google.com/d/optout.
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> linux-arm-kernel mailing list
>>>> linux-arm-kernel@lists.infradead.org
>>>> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>>>
>>>
>>>
>>> --
>>> You received this message because you are subscribed to the Google Groups
>>> "linux-sunxi" group.
>>> To unsubscribe from this group and stop receiving emails from it, send an
>>> email to linux-sunxi+unsubscribe@googlegroups.com.
>>> For more options, visit https://groups.google.com/d/optout.
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "linux-sunxi" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to linux-sunxi+unsubscribe@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

[toc] | [prev] | [next] | [standalone]


#1694429 — Re: [linux-sunxi] [PATCH 02/10] regulator: add support for SY8106A regulator

FromChen-Yu Tsai <wens@csie.org>
Date2017-07-24 05:40 +0200
SubjectRe: [linux-sunxi] [PATCH 02/10] regulator: add support for SY8106A regulator
Message-ID<u6CnT-7QV-7@gated-at.bofh.it>
In reply to#1694421
On Mon, Jul 24, 2017 at 11:18 AM,  <icenowy@aosc.io> wrote:
> 在 2017-07-24 11:03,Chen-Yu Tsai 写道:
>>
>> On Sun, Jul 23, 2017 at 6:27 PM, Icenowy Zheng <icenowy@aosc.io> wrote:
>>>
>>> From: Ondrej Jirman <megous@megous.com>
>>>
>>> SY8106A is an I2C attached single output regulator made by Silergy Corp,
>>> which is used on several Allwinner H3/H5 SBCs to control the power
>>> supply of the ARM cores.
>>>
>>> Add a driver for it.
>>>
>>> Signed-off-by: Ondrej Jirman <megous@megous.com>
>>> [Icenowy: Change commit message]
>>> Signed-off-by: Icenowy Zheng <icenowy@aosc.io>
>>> ---
>>>  drivers/regulator/Kconfig             |   8 +-
>>>  drivers/regulator/Makefile            |   2 +-
>>>  drivers/regulator/sy8106a-regulator.c | 163
>>> ++++++++++++++++++++++++++++++++++
>>>  3 files changed, 171 insertions(+), 2 deletions(-)
>>>  create mode 100644 drivers/regulator/sy8106a-regulator.c
>>>
>>> diff --git a/drivers/regulator/Kconfig b/drivers/regulator/Kconfig
>>> index 99b9362331b5..1efa73e18d07 100644
>>> --- a/drivers/regulator/Kconfig
>>> +++ b/drivers/regulator/Kconfig
>>> @@ -764,6 +764,13 @@ config REGULATOR_STW481X_VMMC
>>>           This driver supports the internal VMMC regulator in the STw481x
>>>           PMIC chips.
>>>
>>> +config REGULATOR_SY8106A
>>> +       tristate "Silergy SY8106A regulator"
>>> +       depends on I2C && (OF || COMPILE_TEST)
>>> +       select REGMAP_I2C
>>> +       help
>>> +         This driver supports SY8106A single output regulator.
>>> +
>>>  config REGULATOR_TPS51632
>>>         tristate "TI TPS51632 Power Regulator"
>>>         depends on I2C
>>> @@ -938,4 +945,3 @@ config REGULATOR_WM8994
>>>           WM8994 CODEC.
>>>
>>>  endif
>>> -
>>> diff --git a/drivers/regulator/Makefile b/drivers/regulator/Makefile
>>> index 95b1e86ae692..f5120252f86a 100644
>>> --- a/drivers/regulator/Makefile
>>> +++ b/drivers/regulator/Makefile
>>> @@ -95,6 +95,7 @@ obj-$(CONFIG_REGULATOR_S2MPS11) += s2mps11.o
>>>  obj-$(CONFIG_REGULATOR_S5M8767) += s5m8767.o
>>>  obj-$(CONFIG_REGULATOR_SKY81452) += sky81452-regulator.o
>>>  obj-$(CONFIG_REGULATOR_STW481X_VMMC) += stw481x-vmmc.o
>>> +obj-$(CONFIG_REGULATOR_SY8106A) += sy8106a-regulator.o
>>>  obj-$(CONFIG_REGULATOR_TI_ABB) += ti-abb-regulator.o
>>>  obj-$(CONFIG_REGULATOR_TPS6105X) += tps6105x-regulator.o
>>>  obj-$(CONFIG_REGULATOR_TPS62360) += tps62360-regulator.o
>>> @@ -120,5 +121,4 @@ obj-$(CONFIG_REGULATOR_WM8350) += wm8350-regulator.o
>>>  obj-$(CONFIG_REGULATOR_WM8400) += wm8400-regulator.o
>>>  obj-$(CONFIG_REGULATOR_WM8994) += wm8994-regulator.o
>>>
>>> -
>>>  ccflags-$(CONFIG_REGULATOR_DEBUG) += -DDEBUG
>>> diff --git a/drivers/regulator/sy8106a-regulator.c
>>> b/drivers/regulator/sy8106a-regulator.c
>>> new file mode 100644
>>> index 000000000000..1df889f68b3d
>>> --- /dev/null
>>> +++ b/drivers/regulator/sy8106a-regulator.c
>>> @@ -0,0 +1,163 @@
>>> +/*
>>> + * sy8106a-regulator.c - Regulator device driver for SY8106A
>>> + *
>>> + * Copyright (C) 2016 Ondřej Jirman <megous@megous.com>
>>> + *
>>> + * This program is free software; you can redistribute it and/or
>>> + * modify it under the terms of the GNU Library General Public
>>> + * License as published by the Free Software Foundation; either
>>> + * version 2 of the License, or (at your option) any later version.
>>> + *
>>> + * This program is distributed in the hope that it will be useful,
>>> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
>>> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
>>> + * Library General Public License for more details.
>>> + */
>>> +
>>> +#include <linux/err.h>
>>> +#include <linux/i2c.h>
>>> +#include <linux/module.h>
>>> +#include <linux/regmap.h>
>>> +#include <linux/regulator/driver.h>
>>> +#include <linux/regulator/of_regulator.h>
>>> +
>>> +#define SY8106A_REG_VOUT1_SEL          0x01
>>> +#define SY8106A_REG_VOUT_COM           0x02
>>> +#define SY8106A_REG_VOUT1_SEL_MASK     0x7f
>>> +#define SY8106A_DISABLE_REG            BIT(0)
>>> +#define SY8106A_GO_BIT                 BIT(7)
>>> +
>>> +struct sy8106a {
>>> +       struct regulator_dev *rdev;
>>> +       struct regmap *regmap;
>>> +};
>>> +
>>> +static const struct regmap_config sy8106a_regmap_config = {
>>> +       .reg_bits = 8,
>>> +       .val_bits = 8,
>>> +};
>>> +
>>> +static int sy8106a_set_voltage_sel(struct regulator_dev *rdev, unsigned
>>> int sel)
>>> +{
>>> +       /* We use our set_voltage_sel in order to avoid unnecessary I2C
>>> +        * chatter, because the regulator_get_voltage_sel_regmap using
>>> +        * apply_bit would perform 4 unnecessary transfers instead of
>>> one,
>>> +        * increasing the chance of error.
>>> +        */
>>> +       return regmap_write(rdev->regmap, rdev->desc->vsel_reg,
>>> +                           sel | SY8106A_GO_BIT);
>>
>>
>> There should also be an explanation of what the "go bit" does.
>> In this case it enables control of the voltage over I2C.
>>
>>> +}
>>> +
>>> +static const struct regulator_ops sy8106a_ops = {
>>> +       .is_enabled = regulator_is_enabled_regmap,
>>> +       .set_voltage_sel = sy8106a_set_voltage_sel,
>>> +       .set_voltage_time_sel = regulator_set_voltage_time_sel,
>>> +       .get_voltage_sel = regulator_get_voltage_sel_regmap,
>>> +       .list_voltage = regulator_list_voltage_linear,
>>
>>
>> No enable/disable ops?
>>
>>> +};
>>> +
>>> +/* Default limits measured in millivolts and milliamps */
>>> +#define SY8106A_MIN_MV         680
>>> +#define SY8106A_MAX_MV         1950
>>> +#define SY8106A_STEP_MV                10
>>> +
>>> +static const struct regulator_desc sy8106a_reg = {
>>> +       .name = "SY8106A",
>>> +       .id = 0,
>>> +       .ops = &sy8106a_ops,
>>> +       .type = REGULATOR_VOLTAGE,
>>> +       .n_voltages = ((SY8106A_MAX_MV - SY8106A_MIN_MV) /
>>> SY8106A_STEP_MV) + 1,
>>> +       .min_uV = (SY8106A_MIN_MV * 1000),
>>> +       .uV_step = (SY8106A_STEP_MV * 1000),
>>> +       .vsel_reg = SY8106A_REG_VOUT1_SEL,
>>> +       .vsel_mask = SY8106A_REG_VOUT1_SEL_MASK,
>>> +       .enable_reg = SY8106A_REG_VOUT_COM,
>>> +       .enable_mask = SY8106A_DISABLE_REG,
>>> +       .disable_val = SY8106A_DISABLE_REG,
>>> +       .enable_is_inverted = 1,
>>
>>
>> As the regulator core helpers currently are, there is no way to disable
>> this regulator. regulator_disable_regmap looks like:
>
>
> By reading the current code, I think removing the disable_val variable will
> just make it work -- when enabling, the enable_reg will be set to disable_val
> (as enable_is_inverted is 1), and disable_val is defaultly 0; when disabling,
> the enable_reg will be set to enable_mask (fallbacked from enable_val, which
> is also the default value 0), and the regulator successfully get disabled.

(Gmail is wrapping the lines :( )

enable_mask is set to SY8106A_DISABLE_REG, which equals disable_val here,
which is not 0. This is correct, as it is the bit mask passed to
regmap_update_bits. So no, it does not work.

It seems quite a lot of drivers depend on this fallback behavior though.

ChenYu

>
>>
>>         if (rdev->desc->enable_is_inverted) {
>>                 val = rdev->desc->enable_val;
>>                 if (!val)
>>                         val = rdev->desc->enable_mask;
>>         } else {
>>                 val = rdev->desc->disable_val;
>>         }
>>
>>         return regmap_update_bits(rdev->regmap, rdev->desc->enable_reg,
>>                                   rdev->desc->enable_mask, val);
>>
>> Note the fallback to enable_mask if enable_val is not set. The enable
>> helper has a similar structure. This regulator uses an enable value
>> of 0, and disable value of 1, it is impossible to get it right. As
>> it is now, it doesn't really make sense to me.
>>
>> The code was introduced in ca5d1b3524b4 ("regulator: helpers: Modify
>> helpers enabling multi-bit control"). I wonder if it was an unintended
>> consequence of the change? (original author CC-ed)
>>
>>> +       .owner = THIS_MODULE,
>>> +};
>>> +
>>> +/*
>>> + * I2C driver interface functions
>>> + */
>>> +static int sy8106a_i2c_probe(struct i2c_client *i2c,
>>> +                           const struct i2c_device_id *id)
>>> +{
>>> +       struct sy8106a *chip;
>>> +       struct device *dev = &i2c->dev;
>>> +       struct regulator_dev *rdev = NULL;
>>> +       struct regulator_config config = { };
>>> +       unsigned int selector;
>>> +       int error;
>>> +
>>> +       chip = devm_kzalloc(&i2c->dev, sizeof(struct sy8106a),
>>> GFP_KERNEL);
>>> +       if (!chip)
>>> +               return -ENOMEM;
>>> +
>>> +       chip->regmap = devm_regmap_init_i2c(i2c, &sy8106a_regmap_config);
>>> +       if (IS_ERR(chip->regmap)) {
>>> +               error = PTR_ERR(chip->regmap);
>>> +               dev_err(&i2c->dev, "Failed to allocate register map:
>>> %d\n",
>>> +                       error);
>>> +               return error;
>>> +       }
>>> +
>>> +       config.dev = &i2c->dev;
>>> +       config.regmap = chip->regmap;
>>> +       config.driver_data = chip;
>>> +
>>> +       config.of_node = dev->of_node;
>>> +       config.init_data = of_get_regulator_init_data(dev, dev->of_node,
>>> +                                                     &sy8106a_reg);
>>> +
>>> +       if (!config.init_data)
>>> +               return -ENOMEM;
>>> +
>>> +       /* Probe regulator */
>>> +       error = regmap_read(chip->regmap, SY8106A_REG_VOUT1_SEL,
>>> &selector);
>>> +       if (error) {
>>> +               dev_err(&i2c->dev, "Failed to read voltage at probe time:
>>> %d\n", error);
>>> +               return error;
>>> +       }
>>> +
>>> +       rdev = devm_regulator_register(&i2c->dev, &sy8106a_reg, &config);
>>> +       if (IS_ERR(rdev)) {
>>> +               error = PTR_ERR(rdev);
>>> +               dev_err(&i2c->dev, "Failed to register SY8106A regulator:
>>> %d\n", error);
>>> +               return error;
>>> +       }
>>> +
>>> +       chip->rdev = rdev;
>>> +
>>> +       i2c_set_clientdata(i2c, chip);
>>> +
>>> +       return 0;
>>> +}
>>> +
>>> +static const struct of_device_id sy8106a_i2c_of_match[] = {
>>> +       { .compatible = "silergy,sy8106a" },
>>> +       { },
>>> +};
>>> +MODULE_DEVICE_TABLE(of, sy8106a_i2c_of_match);
>>> +
>>> +static const struct i2c_device_id sy8106a_i2c_id[] = {
>>> +       { "sy8106a", 0 },
>>> +       { },
>>> +};
>>> +MODULE_DEVICE_TABLE(i2c, sy8106a_i2c_id);
>>> +
>>> +static struct i2c_driver sy8106a_regulator_driver = {
>>> +       .driver = {
>>> +               .name = "sy8106a",
>>> +               .of_match_table = of_match_ptr(sy8106a_i2c_of_match),
>>> +       },
>>> +       .probe = sy8106a_i2c_probe,
>>> +       .id_table = sy8106a_i2c_id,
>>> +};
>>> +
>>> +module_i2c_driver(sy8106a_regulator_driver);
>>> +
>>> +MODULE_AUTHOR("Ondřej Jirman <megous@megous.com>");
>>> +MODULE_DESCRIPTION("Regulator device driver for Silergy SY8106A");
>>> +MODULE_LICENSE("GPL v2");
>>
>>
>> This should be "GPL", to match what the license at the very top says.
>>
>> Regards
>> ChenYu
>>
>>> --
>>> 2.13.0
>>>
>>> --
>>> You received this message because you are subscribed to the Google Groups
>>> "linux-sunxi" group.
>>> To unsubscribe from this group and stop receiving emails from it, send an
>>> email to linux-sunxi+unsubscribe@googlegroups.com.
>>> For more options, visit https://groups.google.com/d/optout.
>>
>>
>> _______________________________________________
>> linux-arm-kernel mailing list
>> linux-arm-kernel@lists.infradead.org
>> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "linux-sunxi" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to linux-sunxi+unsubscribe@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

[toc] | [prev] | [next] | [standalone]


#1694800 — Re: [linux-sunxi] [PATCH 02/10] regulator: add support for SY8106A regulator

FromMark Brown <broonie@kernel.org>
Date2017-07-24 17:10 +0200
SubjectRe: [linux-sunxi] [PATCH 02/10] regulator: add support for SY8106A regulator
Message-ID<u6N9H-6A9-71@gated-at.bofh.it>
In reply to#1694415

[Multipart message — attachments visible in raw view] — view raw

On Mon, Jul 24, 2017 at 11:03:24AM +0800, Chen-Yu Tsai wrote:
> On Sun, Jul 23, 2017 at 6:27 PM, Icenowy Zheng <icenowy@aosc.io> wrote:
> > From: Ondrej Jirman <megous@megous.com>
> >
> > SY8106A is an I2C attached single output regulator made by Silergy Corp,
> > which is used on several Allwinner H3/H5 SBCs to control the power
> > supply of the ARM cores.
> >
> > Add a driver for it.

Please delete unneeded context from mails when replying.  Doing this
makes it much easier to find your reply in the message, helping ensure
it won't be missed by people scrolling through the irrelevant quoted
material.

[toc] | [prev] | [next] | [standalone]


#1694291 — [PATCH 10/10] ARM: dts: sun8i: Add SY8106A regulator to Orange Pi PC

FromIcenowy Zheng <icenowy@aosc.io>
Date2017-07-23 12:30 +0200
Subject[PATCH 10/10] ARM: dts: sun8i: Add SY8106A regulator to Orange Pi PC
Message-ID<u6mj9-6k6-37@gated-at.bofh.it>
In reply to#1694282
From: Ondrej Jirman <megous@megous.com>

Add SY8106A regulator to r_i2c bus and enable the r_i2c bus on
Orange Pi PC, then set the power supply of the ARM cores to this
regulator, in order to enable DVFS.

Signed-off-by: Ondrej Jirman <megous@megous.com>
[Icenowy: Enable DVFS in this patch, slight changes and change commit
 message]
Signed-off-by: Icenowy Zheng <icenowy@aosc.io>
---
 arch/arm/boot/dts/sun8i-h3-orangepi-pc.dts | 19 +++++++++++++++++++
 1 file changed, 19 insertions(+)

diff --git a/arch/arm/boot/dts/sun8i-h3-orangepi-pc.dts b/arch/arm/boot/dts/sun8i-h3-orangepi-pc.dts
index 998b60f8d295..d855f8b6254e 100644
--- a/arch/arm/boot/dts/sun8i-h3-orangepi-pc.dts
+++ b/arch/arm/boot/dts/sun8i-h3-orangepi-pc.dts
@@ -98,6 +98,10 @@
 	status = "okay";
 };
 
+&cpu0 {
+	cpu-supply = <&reg_sy8106a>;
+};
+
 &ehci0 {
 	status = "okay";
 };
@@ -160,6 +164,21 @@
 	};
 };
 
+&r_i2c {
+	status = "okay";
+
+	reg_sy8106a: regulator@65 {
+		compatible = "silergy,sy8106a";
+		reg = <0x65>;
+		regulator-name = "vdd-cpux";
+		regulator-min-microvolt = <1000000>;
+		regulator-max-microvolt = <1400000>;
+		regulator-ramp-delay = <200>;
+		regulator-boot-on;
+		regulator-always-on;
+	};
+};
+
 &r_pio {
 	leds_r_opc: led_pins@0 {
 		pins = "PL10";
-- 
2.13.0

[toc] | [prev] | [next] | [standalone]


#1696834 — Re: [linux-sunxi] [PATCH 10/10] ARM: dts: sun8i: Add SY8106A regulator to Orange Pi PC

FromChen-Yu Tsai <wens@csie.org>
Date2017-07-26 09:10 +0200
SubjectRe: [linux-sunxi] [PATCH 10/10] ARM: dts: sun8i: Add SY8106A regulator to Orange Pi PC
Message-ID<u7oCe-5E8-21@gated-at.bofh.it>
In reply to#1694291
On Sun, Jul 23, 2017 at 6:27 PM, Icenowy Zheng <icenowy@aosc.io> wrote:
> From: Ondrej Jirman <megous@megous.com>
>
> Add SY8106A regulator to r_i2c bus and enable the r_i2c bus on
> Orange Pi PC, then set the power supply of the ARM cores to this
> regulator, in order to enable DVFS.
>
> Signed-off-by: Ondrej Jirman <megous@megous.com>
> [Icenowy: Enable DVFS in this patch, slight changes and change commit
>  message]
> Signed-off-by: Icenowy Zheng <icenowy@aosc.io>
> ---
>  arch/arm/boot/dts/sun8i-h3-orangepi-pc.dts | 19 +++++++++++++++++++
>  1 file changed, 19 insertions(+)
>
> diff --git a/arch/arm/boot/dts/sun8i-h3-orangepi-pc.dts b/arch/arm/boot/dts/sun8i-h3-orangepi-pc.dts
> index 998b60f8d295..d855f8b6254e 100644
> --- a/arch/arm/boot/dts/sun8i-h3-orangepi-pc.dts
> +++ b/arch/arm/boot/dts/sun8i-h3-orangepi-pc.dts
> @@ -98,6 +98,10 @@
>         status = "okay";
>  };
>
> +&cpu0 {
> +       cpu-supply = <&reg_sy8106a>;
> +};
> +
>  &ehci0 {
>         status = "okay";
>  };
> @@ -160,6 +164,21 @@
>         };
>  };
>
> +&r_i2c {
> +       status = "okay";
> +
> +       reg_sy8106a: regulator@65 {
> +               compatible = "silergy,sy8106a";
> +               reg = <0x65>;
> +               regulator-name = "vdd-cpux";
> +               regulator-min-microvolt = <1000000>;

According to the H3 datasheet, the minimum voltage is 1.1V, not 1V.

Otherwse

> +               regulator-max-microvolt = <1400000>;
> +               regulator-ramp-delay = <200>;

Is this an actual constraint of the SoC? Or is it a characteristic
of the regulator? If it is the latter, it belongs in the driver.
AFAIK the regulator supports varying the ramp delay (slew rate).

ChenYu

> +               regulator-boot-on;
> +               regulator-always-on;
> +       };
> +};
> +
>  &r_pio {
>         leds_r_opc: led_pins@0 {
>                 pins = "PL10";
> --
> 2.13.0
>
> --
> You received this message because you are subscribed to the Google Groups "linux-sunxi" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscribe@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

[toc] | [prev] | [next] | [standalone]


#1696835 — Re: [linux-sunxi] [PATCH 10/10] ARM: dts: sun8i: Add SY8106A regulator to Orange Pi PC

FromIcenowy Zheng <icenowy@aosc.io>
Date2017-07-26 09:20 +0200
SubjectRe: [linux-sunxi] [PATCH 10/10] ARM: dts: sun8i: Add SY8106A regulator to Orange Pi PC
Message-ID<u7oLT-5HO-1@gated-at.bofh.it>
In reply to#1696834

于 2017年7月26日 GMT+08:00 下午3:08:06, Chen-Yu Tsai <wens@csie.org> 写到:
>On Sun, Jul 23, 2017 at 6:27 PM, Icenowy Zheng <icenowy@aosc.io> wrote:
>> From: Ondrej Jirman <megous@megous.com>
>>
>> Add SY8106A regulator to r_i2c bus and enable the r_i2c bus on
>> Orange Pi PC, then set the power supply of the ARM cores to this
>> regulator, in order to enable DVFS.
>>
>> Signed-off-by: Ondrej Jirman <megous@megous.com>
>> [Icenowy: Enable DVFS in this patch, slight changes and change commit
>>  message]
>> Signed-off-by: Icenowy Zheng <icenowy@aosc.io>
>> ---
>>  arch/arm/boot/dts/sun8i-h3-orangepi-pc.dts | 19 +++++++++++++++++++
>>  1 file changed, 19 insertions(+)
>>
>> diff --git a/arch/arm/boot/dts/sun8i-h3-orangepi-pc.dts
>b/arch/arm/boot/dts/sun8i-h3-orangepi-pc.dts
>> index 998b60f8d295..d855f8b6254e 100644
>> --- a/arch/arm/boot/dts/sun8i-h3-orangepi-pc.dts
>> +++ b/arch/arm/boot/dts/sun8i-h3-orangepi-pc.dts
>> @@ -98,6 +98,10 @@
>>         status = "okay";
>>  };
>>
>> +&cpu0 {
>> +       cpu-supply = <&reg_sy8106a>;
>> +};
>> +
>>  &ehci0 {
>>         status = "okay";
>>  };
>> @@ -160,6 +164,21 @@
>>         };
>>  };
>>
>> +&r_i2c {
>> +       status = "okay";
>> +
>> +       reg_sy8106a: regulator@65 {
>> +               compatible = "silergy,sy8106a";
>> +               reg = <0x65>;
>> +               regulator-name = "vdd-cpux";
>> +               regulator-min-microvolt = <1000000>;
>
>According to the H3 datasheet, the minimum voltage is 1.1V, not 1V.

But the Armbian OPP table for H3 contains several
OPP under 1.1V...

>
>Otherwse
>
>> +               regulator-max-microvolt = <1400000>;
>> +               regulator-ramp-delay = <200>;
>
>Is this an actual constraint of the SoC? Or is it a characteristic
>of the regulator? If it is the latter, it belongs in the driver.
>AFAIK the regulator supports varying the ramp delay (slew rate).
>
>ChenYu
>
>> +               regulator-boot-on;
>> +               regulator-always-on;
>> +       };
>> +};
>> +
>>  &r_pio {
>>         leds_r_opc: led_pins@0 {
>>                 pins = "PL10";
>> --
>> 2.13.0
>>
>> --
>> You received this message because you are subscribed to the Google
>Groups "linux-sunxi" group.
>> To unsubscribe from this group and stop receiving emails from it,
>send an email to linux-sunxi+unsubscribe@googlegroups.com.
>> For more options, visit https://groups.google.com/d/optout.

[toc] | [prev] | [next] | [standalone]


#1696845 — Re: [linux-sunxi] [PATCH 10/10] ARM: dts: sun8i: Add SY8106A regulator to Orange Pi PC

FromChen-Yu Tsai <wens@csie.org>
Date2017-07-26 09:40 +0200
SubjectRe: [linux-sunxi] [PATCH 10/10] ARM: dts: sun8i: Add SY8106A regulator to Orange Pi PC
Message-ID<u7p5g-5Ol-11@gated-at.bofh.it>
In reply to#1696835
On Wed, Jul 26, 2017 at 3:16 PM, Icenowy Zheng <icenowy@aosc.io> wrote:
>
>
> 于 2017年7月26日 GMT+08:00 下午3:08:06, Chen-Yu Tsai <wens@csie.org> 写到:
>>On Sun, Jul 23, 2017 at 6:27 PM, Icenowy Zheng <icenowy@aosc.io> wrote:
>>> From: Ondrej Jirman <megous@megous.com>
>>>
>>> Add SY8106A regulator to r_i2c bus and enable the r_i2c bus on
>>> Orange Pi PC, then set the power supply of the ARM cores to this
>>> regulator, in order to enable DVFS.
>>>
>>> Signed-off-by: Ondrej Jirman <megous@megous.com>
>>> [Icenowy: Enable DVFS in this patch, slight changes and change commit
>>>  message]
>>> Signed-off-by: Icenowy Zheng <icenowy@aosc.io>
>>> ---
>>>  arch/arm/boot/dts/sun8i-h3-orangepi-pc.dts | 19 +++++++++++++++++++
>>>  1 file changed, 19 insertions(+)
>>>
>>> diff --git a/arch/arm/boot/dts/sun8i-h3-orangepi-pc.dts
>>b/arch/arm/boot/dts/sun8i-h3-orangepi-pc.dts
>>> index 998b60f8d295..d855f8b6254e 100644
>>> --- a/arch/arm/boot/dts/sun8i-h3-orangepi-pc.dts
>>> +++ b/arch/arm/boot/dts/sun8i-h3-orangepi-pc.dts
>>> @@ -98,6 +98,10 @@
>>>         status = "okay";
>>>  };
>>>
>>> +&cpu0 {
>>> +       cpu-supply = <&reg_sy8106a>;
>>> +};
>>> +
>>>  &ehci0 {
>>>         status = "okay";
>>>  };
>>> @@ -160,6 +164,21 @@
>>>         };
>>>  };
>>>
>>> +&r_i2c {
>>> +       status = "okay";
>>> +
>>> +       reg_sy8106a: regulator@65 {
>>> +               compatible = "silergy,sy8106a";
>>> +               reg = <0x65>;
>>> +               regulator-name = "vdd-cpux";
>>> +               regulator-min-microvolt = <1000000>;
>>
>>According to the H3 datasheet, the minimum voltage is 1.1V, not 1V.
>
> But the Armbian OPP table for H3 contains several
> OPP under 1.1V...

Can you provide a link?

If Armbian users have actually field tested this (a big if),
then I would like to see some evidence of the SoC running
stably at those OPPs with those lower voltages under full load.

Even then you should still leave a note describing why we allow
voltages below the recommended range.

ChenYu

>
>>
>>Otherwse
>>
>>> +               regulator-max-microvolt = <1400000>;
>>> +               regulator-ramp-delay = <200>;
>>
>>Is this an actual constraint of the SoC? Or is it a characteristic
>>of the regulator? If it is the latter, it belongs in the driver.
>>AFAIK the regulator supports varying the ramp delay (slew rate).
>>
>>ChenYu
>>
>>> +               regulator-boot-on;
>>> +               regulator-always-on;
>>> +       };
>>> +};
>>> +
>>>  &r_pio {
>>>         leds_r_opc: led_pins@0 {
>>>                 pins = "PL10";
>>> --
>>> 2.13.0
>>>

[toc] | [prev] | [next] | [standalone]


#1696848 — Re: [linux-sunxi] [PATCH 10/10] ARM: dts: sun8i: Add SY8106A regulator to Orange Pi PC

Fromicenowy@aosc.io
Date2017-07-26 09:40 +0200
SubjectRe: [linux-sunxi] [PATCH 10/10] ARM: dts: sun8i: Add SY8106A regulator to Orange Pi PC
Message-ID<u7p5g-5Ol-25@gated-at.bofh.it>
In reply to#1696845
在 2017-07-26 15:30,Chen-Yu Tsai 写道:
> On Wed, Jul 26, 2017 at 3:16 PM, Icenowy Zheng <icenowy@aosc.io> wrote:
>> 
>> 
>> 于 2017年7月26日 GMT+08:00 下午3:08:06, Chen-Yu Tsai <wens@csie.org> 写到:
>>> On Sun, Jul 23, 2017 at 6:27 PM, Icenowy Zheng <icenowy@aosc.io> 
>>> wrote:
>>>> From: Ondrej Jirman <megous@megous.com>
>>>> 
>>>> Add SY8106A regulator to r_i2c bus and enable the r_i2c bus on
>>>> Orange Pi PC, then set the power supply of the ARM cores to this
>>>> regulator, in order to enable DVFS.
>>>> 
>>>> Signed-off-by: Ondrej Jirman <megous@megous.com>
>>>> [Icenowy: Enable DVFS in this patch, slight changes and change 
>>>> commit
>>>>  message]
>>>> Signed-off-by: Icenowy Zheng <icenowy@aosc.io>
>>>> ---
>>>>  arch/arm/boot/dts/sun8i-h3-orangepi-pc.dts | 19 +++++++++++++++++++
>>>>  1 file changed, 19 insertions(+)
>>>> 
>>>> diff --git a/arch/arm/boot/dts/sun8i-h3-orangepi-pc.dts
>>> b/arch/arm/boot/dts/sun8i-h3-orangepi-pc.dts
>>>> index 998b60f8d295..d855f8b6254e 100644
>>>> --- a/arch/arm/boot/dts/sun8i-h3-orangepi-pc.dts
>>>> +++ b/arch/arm/boot/dts/sun8i-h3-orangepi-pc.dts
>>>> @@ -98,6 +98,10 @@
>>>>         status = "okay";
>>>>  };
>>>> 
>>>> +&cpu0 {
>>>> +       cpu-supply = <&reg_sy8106a>;
>>>> +};
>>>> +
>>>>  &ehci0 {
>>>>         status = "okay";
>>>>  };
>>>> @@ -160,6 +164,21 @@
>>>>         };
>>>>  };
>>>> 
>>>> +&r_i2c {
>>>> +       status = "okay";
>>>> +
>>>> +       reg_sy8106a: regulator@65 {
>>>> +               compatible = "silergy,sy8106a";
>>>> +               reg = <0x65>;
>>>> +               regulator-name = "vdd-cpux";
>>>> +               regulator-min-microvolt = <1000000>;
>>> 
>>> According to the H3 datasheet, the minimum voltage is 1.1V, not 1V.
>> 
>> But the Armbian OPP table for H3 contains several
>> OPP under 1.1V...
> 
> Can you provide a link?
> 
> If Armbian users have actually field tested this (a big if),
> then I would like to see some evidence of the SoC running
> stably at those OPPs with those lower voltages under full load.

See [1].

[1] 
https://github.com/armbian/build/blob/master/config/fex/orangepipc.fex#L736

> 
> Even then you should still leave a note describing why we allow
> voltages below the recommended range.
> 
> ChenYu
> 
>> 
>>> 
>>> Otherwse
>>> 
>>>> +               regulator-max-microvolt = <1400000>;
>>>> +               regulator-ramp-delay = <200>;
>>> 
>>> Is this an actual constraint of the SoC? Or is it a characteristic
>>> of the regulator? If it is the latter, it belongs in the driver.
>>> AFAIK the regulator supports varying the ramp delay (slew rate).

I don't know...

Maybe I should ask Ondrej?

>>> 
>>> ChenYu
>>> 
>>>> +               regulator-boot-on;
>>>> +               regulator-always-on;
>>>> +       };
>>>> +};
>>>> +
>>>>  &r_pio {
>>>>         leds_r_opc: led_pins@0 {
>>>>                 pins = "PL10";
>>>> --
>>>> 2.13.0
>>>> 

[toc] | [prev] | [next] | [standalone]


#1696969 — Re: [linux-sunxi] [PATCH 10/10] ARM: dts: sun8i: Add SY8106A regulator to Orange Pi PC

FromOndřej Jirman <megous@megous.com>
Date2017-07-26 12:40 +0200
SubjectRe: [linux-sunxi] [PATCH 10/10] ARM: dts: sun8i: Add SY8106A regulator to Orange Pi PC
Message-ID<u7rTs-7zc-19@gated-at.bofh.it>
In reply to#1696848

[Multipart message — attachments visible in raw view] — view raw

Hi,

icenowy@aosc.io píše v St 26. 07. 2017 v 15:36 +0800:
> 
> > > > 
> > > > Otherwse
> > > > 
> > > > > +               regulator-max-microvolt = <1400000>;
> > > > > +               regulator-ramp-delay = <200>;
> > > > 
> > > > Is this an actual constraint of the SoC? Or is it a characteristic
> > > > of the regulator? If it is the latter, it belongs in the driver.
> > > > AFAIK the regulator supports varying the ramp delay (slew rate).
> 
> I don't know...
> 
> Maybe I should ask Ondrej?

It is probably neither.

It is used to calculate a delay inserted by the kernel between setting
a new target voltage over I2C and changing the frequency of the CPU.
The actual delay is calculated by the difference between previous and
the new voltage.

I don't remember seeing anything in the datasheet of the regulator.
This is just some low value that works.

It would probably be dependent on the capacitance on the output of the
regulator, actual load (which varies), etc. So it is a board specific
value. One could measure it with an oscilloscope if there's a need to
optimize this.

regards,
  o.

> > > > 
> > > > ChenYu
> > > > 
> > > > > +               regulator-boot-on;
> > > > > +               regulator-always-on;
> > > > > +       };
> > > > > +};
> > > > > +
> > > > >  &r_pio {
> > > > >         leds_r_opc: led_pins@0 {
> > > > >                 pins = "PL10";
> > > > > --
> > > > > 2.13.0
> > > > > 

[toc] | [prev] | [next] | [standalone]


#1697008 — Re: [linux-sunxi] [PATCH 10/10] ARM: dts: sun8i: Add SY8106A regulator to Orange Pi PC

FromMaxime Ripard <maxime.ripard@free-electrons.com>
Date2017-07-26 13:50 +0200
SubjectRe: [linux-sunxi] [PATCH 10/10] ARM: dts: sun8i: Add SY8106A regulator to Orange Pi PC
Message-ID<u7sZc-8do-5@gated-at.bofh.it>
In reply to#1696969

[Multipart message — attachments visible in raw view] — view raw

Hi,

On Wed, Jul 26, 2017 at 12:23:48PM +0200, Ondřej Jirman wrote:
> Hi,
> 
> icenowy@aosc.io píše v St 26. 07. 2017 v 15:36 +0800:
> > 
> > > > > 
> > > > > Otherwse
> > > > > 
> > > > > > +               regulator-max-microvolt = <1400000>;
> > > > > > +               regulator-ramp-delay = <200>;
> > > > > 
> > > > > Is this an actual constraint of the SoC? Or is it a characteristic
> > > > > of the regulator? If it is the latter, it belongs in the driver.
> > > > > AFAIK the regulator supports varying the ramp delay (slew rate).
> > 
> > I don't know...
> > 
> > Maybe I should ask Ondrej?
> 
> It is probably neither.
> 
> It is used to calculate a delay inserted by the kernel between setting
> a new target voltage over I2C and changing the frequency of the CPU.
> The actual delay is calculated by the difference between previous and
> the new voltage.
> 
> I don't remember seeing anything in the datasheet of the regulator.
> This is just some low value that works.
> 
> It would probably be dependent on the capacitance on the output of the
> regulator, actual load (which varies), etc. So it is a board specific
> value. One could measure it with an oscilloscope if there's a need to
> optimize this.

If this is a reasonable default, then this should be in the
driver. You can't expect anyone to properly calculate a ramp delay and
have access to both a scope and the CPU power lines.

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

[toc] | [prev] | [next] | [standalone]


#1697057 — Re: [linux-sunxi] [PATCH 10/10] ARM: dts: sun8i: Add SY8106A regulator to Orange Pi PC

Fromicenowy@aosc.io
Date2017-07-26 14:50 +0200
SubjectRe: [linux-sunxi] [PATCH 10/10] ARM: dts: sun8i: Add SY8106A regulator to Orange Pi PC
Message-ID<u7tVg-mT-7@gated-at.bofh.it>
In reply to#1697008
在 2017-07-26 19:44,Maxime Ripard 写道:
> Hi,
> 
> On Wed, Jul 26, 2017 at 12:23:48PM +0200, Ondřej Jirman wrote:
>> Hi,
>> 
>> icenowy@aosc.io píše v St 26. 07. 2017 v 15:36 +0800:
>> >
>> > > > >
>> > > > > Otherwse
>> > > > >
>> > > > > > +               regulator-max-microvolt = <1400000>;
>> > > > > > +               regulator-ramp-delay = <200>;
>> > > > >
>> > > > > Is this an actual constraint of the SoC? Or is it a characteristic
>> > > > > of the regulator? If it is the latter, it belongs in the driver.
>> > > > > AFAIK the regulator supports varying the ramp delay (slew rate).
>> >
>> > I don't know...
>> >
>> > Maybe I should ask Ondrej?
>> 
>> It is probably neither.
>> 
>> It is used to calculate a delay inserted by the kernel between setting
>> a new target voltage over I2C and changing the frequency of the CPU.
>> The actual delay is calculated by the difference between previous and
>> the new voltage.
>> 
>> I don't remember seeing anything in the datasheet of the regulator.
>> This is just some low value that works.
>> 
>> It would probably be dependent on the capacitance on the output of the
>> regulator, actual load (which varies), etc. So it is a board specific
>> value. One could measure it with an oscilloscope if there's a need to
>> optimize this.
> 
> If this is a reasonable default, then this should be in the
> driver. You can't expect anyone to properly calculate a ramp delay and
> have access to both a scope and the CPU power lines.

It seems that in regulator_desc structure a default value of ramp delay
can be set, and the ones specified in dt can override it.

So just add .ramp_delay = 200 in the driver's regulator_desc part?

Should a comment be added that explains it's only an experienced value
on Allwinner H3/H5 boards VDD-CPUX usage?

> 
> Maxime
> 
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[toc] | [prev] | [next] | [standalone]


#1697069 — Re: [linux-sunxi] [PATCH 10/10] ARM: dts: sun8i: Add SY8106A regulator to Orange Pi PC

FromOndřej Jirman <megous@megous.com>
Date2017-07-26 15:00 +0200
SubjectRe: [linux-sunxi] [PATCH 10/10] ARM: dts: sun8i: Add SY8106A regulator to Orange Pi PC
Message-ID<u7u4W-qb-15@gated-at.bofh.it>
In reply to#1697008

[Multipart message — attachments visible in raw view] — view raw

Maxime Ripard píše v St 26. 07. 2017 v 13:44 +0200:
> Hi,
> 
> On Wed, Jul 26, 2017 at 12:23:48PM +0200, Ondřej Jirman wrote:
> > Hi,
> > 
> > icenowy@aosc.io píše v St 26. 07. 2017 v 15:36 +0800:
> > > 
> > > > > > 
> > > > > > Otherwse
> > > > > > 
> > > > > > > +               regulator-max-microvolt = <1400000>;
> > > > > > > +               regulator-ramp-delay = <200>;
> > > > > > 
> > > > > > Is this an actual constraint of the SoC? Or is it a characteristic
> > > > > > of the regulator? If it is the latter, it belongs in the driver.
> > > > > > AFAIK the regulator supports varying the ramp delay (slew rate).
> > > 
> > > I don't know...
> > > 
> > > Maybe I should ask Ondrej?
> > 
> > It is probably neither.
> > 
> > It is used to calculate a delay inserted by the kernel between setting
> > a new target voltage over I2C and changing the frequency of the CPU.
> > The actual delay is calculated by the difference between previous and
> > the new voltage.
> > 
> > I don't remember seeing anything in the datasheet of the regulator.
> > This is just some low value that works.
> > 
> > It would probably be dependent on the capacitance on the output of the
> > regulator, actual load (which varies), etc. So it is a board specific
> > value. One could measure it with an oscilloscope if there's a need to
> > optimize this.
> 
> If this is a reasonable default, then this should be in the
> driver. You can't expect anyone to properly calculate a ramp delay and
> have access to both a scope and the CPU power lines.

It translates to 1ms per 0.2V which is highly conservative. The real
times will be in 1-10us range. So I guess this could be a default in
the driver.

regards,
  o.

> Maxime
> 
> -- 
> Maxime Ripard, Free Electrons
> Embedded Linux and Kernel engineering
> http://free-electrons.com
> 

[toc] | [prev] | [next] | [standalone]


#1694292 — [PATCH 01/10] dt-bindings: add binding for the SY8160A voltage regulator

FromIcenowy Zheng <icenowy@aosc.io>
Date2017-07-23 12:30 +0200
Subject[PATCH 01/10] dt-bindings: add binding for the SY8160A voltage regulator
Message-ID<u6mj9-6k6-41@gated-at.bofh.it>
In reply to#1694282
From: Ondrej Jirman <megous@megous.com>

SY8106A is an I2C-controlled adjustable voltage regulator made by
Silergy Corp.

Add its device tree binding.

Signed-off-by: Ondrej Jirman <megous@megous.com>
[Icenowy: Change commit message]
Signed-off-by: Icenowy Zheng <icenowy@aosc.io>
---
 .../bindings/regulator/sy8106a-regulator.txt        | 21 +++++++++++++++++++++
 1 file changed, 21 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/regulator/sy8106a-regulator.txt

diff --git a/Documentation/devicetree/bindings/regulator/sy8106a-regulator.txt b/Documentation/devicetree/bindings/regulator/sy8106a-regulator.txt
new file mode 100644
index 000000000000..1e623a34b1cb
--- /dev/null
+++ b/Documentation/devicetree/bindings/regulator/sy8106a-regulator.txt
@@ -0,0 +1,21 @@
+SY8106A Voltage regulator
+
+Required properties:
+- compatible: Must be "silergy,sy8106a"
+- reg: I2C slave address - must be <0x65>
+
+Any property defined as part of the core regulator binding, defined in
+regulator.txt, can also be used.
+
+Example:
+
+	sy8106a {
+		compatible = "silergy,sy8106a";
+		reg = <0x65>;
+		regulator-name = "sy8106a-vdd";
+		regulator-min-microvolt = <1000000>;
+		regulator-max-microvolt = <1400000>;
+		regulator-ramp-delay = <200>;
+		regulator-boot-on;
+		regulator-always-on;
+	};
-- 
2.13.0

[toc] | [prev] | [next] | [standalone]


#1694418 — Re: [linux-sunxi] [PATCH 01/10] dt-bindings: add binding for the SY8160A voltage regulator

FromChen-Yu Tsai <wens@csie.org>
Date2017-07-24 05:10 +0200
SubjectRe: [linux-sunxi] [PATCH 01/10] dt-bindings: add binding for the SY8160A voltage regulator
Message-ID<u6BUS-7Gk-7@gated-at.bofh.it>
In reply to#1694292
On Sun, Jul 23, 2017 at 6:27 PM, Icenowy Zheng <icenowy@aosc.io> wrote:
> From: Ondrej Jirman <megous@megous.com>
>
> SY8106A is an I2C-controlled adjustable voltage regulator made by
> Silergy Corp.
>
> Add its device tree binding.
>
> Signed-off-by: Ondrej Jirman <megous@megous.com>
> [Icenowy: Change commit message]
> Signed-off-by: Icenowy Zheng <icenowy@aosc.io>
> ---
>  .../bindings/regulator/sy8106a-regulator.txt        | 21 +++++++++++++++++++++
>  1 file changed, 21 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/regulator/sy8106a-regulator.txt
>
> diff --git a/Documentation/devicetree/bindings/regulator/sy8106a-regulator.txt b/Documentation/devicetree/bindings/regulator/sy8106a-regulator.txt
> new file mode 100644
> index 000000000000..1e623a34b1cb
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/regulator/sy8106a-regulator.txt
> @@ -0,0 +1,21 @@
> +SY8106A Voltage regulator
> +
> +Required properties:
> +- compatible: Must be "silergy,sy8106a"
> +- reg: I2C slave address - must be <0x65>
> +
> +Any property defined as part of the core regulator binding, defined in
> +regulator.txt, can also be used.

Nit: use ./regulator.txt to show that this is a path, and not just a
file name. This should help other people find the file quickly.

Otherwise,

Reviewed-by: Chen-Yu Tsai <wens@csie.org>

> +
> +Example:
> +
> +       sy8106a {
> +               compatible = "silergy,sy8106a";
> +               reg = <0x65>;
> +               regulator-name = "sy8106a-vdd";
> +               regulator-min-microvolt = <1000000>;
> +               regulator-max-microvolt = <1400000>;
> +               regulator-ramp-delay = <200>;
> +               regulator-boot-on;
> +               regulator-always-on;
> +       };
> --
> 2.13.0
>
> --
> You received this message because you are subscribed to the Google Groups "linux-sunxi" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscribe@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

[toc] | [prev] | [standalone]


Page 2 of 2 — ← Prev page 1 [2]

Back to top | Article view | linux.kernel


csiph-web