* [PATCH 01/10] mfd: rt5033: Drop rt5033-battery sub-device
2023-02-28 22:32 ` [PATCH 00/10] Add RT5033 charger device driver Jakob Hauser
@ 2023-02-28 22:32 ` Jakob Hauser
2023-02-28 22:32 ` [PATCH 02/10] mfd: rt5033: Fix chip revision readout Jakob Hauser
` (9 subsequent siblings)
10 siblings, 0 replies; 30+ messages in thread
From: Jakob Hauser @ 2023-02-28 22:32 UTC (permalink / raw)
To: Sebastian Reichel, Lee Jones, Liam Girdwood, Mark Brown,
Rob Herring, Krzysztof Kozlowski
Cc: Beomho Seo, Chanwoo Choi, Stephan Gerhold, Raymond Hackley,
linux-pm, devicetree, linux-kernel, ~postmarketos/upstreaming,
Lee Jones, Jakob Hauser
From: Stephan Gerhold <stephan@gerhold.net>
The fuel gauge in the RT5033 PMIC (rt5033-battery) has its own I2C bus
and interrupt lines. Therefore, it is not part of the MFD device
and needs to be specified separately in the device tree.
Cc: Beomho Seo <beomho.seo@samsung.com>
Cc: Chanwoo Choi <cw00.choi@samsung.com>
Fixes: 0b271258544b ("mfd: rt5033: Add Richtek RT5033 driver core.")
Signed-off-by: Stephan Gerhold <stephan@gerhold.net>
Acked-by: Lee Jones <lee.jones@linaro.org>
Signed-off-by: Jakob Hauser <jahau@rocketmail.com>
---
drivers/mfd/rt5033.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/drivers/mfd/rt5033.c b/drivers/mfd/rt5033.c
index a5e520fe50a1..8029d444b794 100644
--- a/drivers/mfd/rt5033.c
+++ b/drivers/mfd/rt5033.c
@@ -40,9 +40,6 @@ static const struct mfd_cell rt5033_devs[] = {
{
.name = "rt5033-charger",
.of_compatible = "richtek,rt5033-charger",
- }, {
- .name = "rt5033-battery",
- .of_compatible = "richtek,rt5033-battery",
}, {
.name = "rt5033-led",
.of_compatible = "richtek,rt5033-led",
--
2.39.1
^ permalink raw reply related [flat|nested] 30+ messages in thread* [PATCH 02/10] mfd: rt5033: Fix chip revision readout
2023-02-28 22:32 ` [PATCH 00/10] Add RT5033 charger device driver Jakob Hauser
2023-02-28 22:32 ` [PATCH 01/10] mfd: rt5033: Drop rt5033-battery sub-device Jakob Hauser
@ 2023-02-28 22:32 ` Jakob Hauser
2023-03-05 10:47 ` Lee Jones
2023-02-28 22:32 ` [PATCH 03/10] mfd: rt5033: Fix comments and style in includes Jakob Hauser
` (8 subsequent siblings)
10 siblings, 1 reply; 30+ messages in thread
From: Jakob Hauser @ 2023-02-28 22:32 UTC (permalink / raw)
To: Sebastian Reichel, Lee Jones, Liam Girdwood, Mark Brown,
Rob Herring, Krzysztof Kozlowski
Cc: Beomho Seo, Chanwoo Choi, Stephan Gerhold, Raymond Hackley,
linux-pm, devicetree, linux-kernel, ~postmarketos/upstreaming,
Jakob Hauser
After reading the data from the DEVICE_ID register, mask 0x0f needs to be
applied to extract the revision of the chip [1].
The other part of the DEVICE_ID register, mask 0xf0, is a vendor identification
code. That's how it is set up at similar products of Richtek, e.g. RT9455 [2]
page 21 top.
[1] https://github.com/msm8916-mainline/linux-downstream/blob/GT-I9195I/drivers/mfd/rt5033_core.c#L484
[2] https://www.richtek.com/assets/product_file/RT9455/DS9455-00.pdf
Signed-off-by: Jakob Hauser <jahau@rocketmail.com>
---
drivers/mfd/rt5033.c | 8 +++++---
include/linux/mfd/rt5033-private.h | 4 ++++
2 files changed, 9 insertions(+), 3 deletions(-)
diff --git a/drivers/mfd/rt5033.c b/drivers/mfd/rt5033.c
index 8029d444b794..d32467174cb5 100644
--- a/drivers/mfd/rt5033.c
+++ b/drivers/mfd/rt5033.c
@@ -55,7 +55,8 @@ static const struct regmap_config rt5033_regmap_config = {
static int rt5033_i2c_probe(struct i2c_client *i2c)
{
struct rt5033_dev *rt5033;
- unsigned int dev_id;
+ unsigned int data;
+ unsigned int chip_rev;
int ret;
rt5033 = devm_kzalloc(&i2c->dev, sizeof(*rt5033), GFP_KERNEL);
@@ -73,12 +74,13 @@ static int rt5033_i2c_probe(struct i2c_client *i2c)
return PTR_ERR(rt5033->regmap);
}
- ret = regmap_read(rt5033->regmap, RT5033_REG_DEVICE_ID, &dev_id);
+ ret = regmap_read(rt5033->regmap, RT5033_REG_DEVICE_ID, &data);
if (ret) {
dev_err(&i2c->dev, "Device not found\n");
return -ENODEV;
}
- dev_info(&i2c->dev, "Device found Device ID: %04x\n", dev_id);
+ chip_rev = data & RT5033_CHIP_REV_MASK;
+ dev_info(&i2c->dev, "Device found (rev. %d)\n", chip_rev);
ret = regmap_add_irq_chip(rt5033->regmap, rt5033->irq,
IRQF_TRIGGER_FALLING | IRQF_ONESHOT,
diff --git a/include/linux/mfd/rt5033-private.h b/include/linux/mfd/rt5033-private.h
index 2d1895c3efbf..d18cd4572208 100644
--- a/include/linux/mfd/rt5033-private.h
+++ b/include/linux/mfd/rt5033-private.h
@@ -71,6 +71,10 @@ enum rt5033_reg {
/* RT5033 CHGCTRL2 register */
#define RT5033_CHGCTRL2_CV_MASK 0xfc
+/* RT5033 DEVICE_ID register */
+#define RT5033_VENDOR_ID_MASK 0xf0
+#define RT5033_CHIP_REV_MASK 0x0f
+
/* RT5033 CHGCTRL3 register */
#define RT5033_CHGCTRL3_CFO_EN_MASK 0x40
#define RT5033_CHGCTRL3_TIMER_MASK 0x38
--
2.39.1
^ permalink raw reply related [flat|nested] 30+ messages in thread* Re: [PATCH 02/10] mfd: rt5033: Fix chip revision readout
2023-02-28 22:32 ` [PATCH 02/10] mfd: rt5033: Fix chip revision readout Jakob Hauser
@ 2023-03-05 10:47 ` Lee Jones
2023-03-05 16:10 ` Jakob Hauser
0 siblings, 1 reply; 30+ messages in thread
From: Lee Jones @ 2023-03-05 10:47 UTC (permalink / raw)
To: Jakob Hauser
Cc: Sebastian Reichel, Liam Girdwood, Mark Brown, Rob Herring,
Krzysztof Kozlowski, Beomho Seo, Chanwoo Choi, Stephan Gerhold,
Raymond Hackley, linux-pm, devicetree, linux-kernel,
~postmarketos/upstreaming
On Tue, 28 Feb 2023, Jakob Hauser wrote:
> After reading the data from the DEVICE_ID register, mask 0x0f needs to be
> applied to extract the revision of the chip [1].
>
> The other part of the DEVICE_ID register, mask 0xf0, is a vendor identification
> code. That's how it is set up at similar products of Richtek, e.g. RT9455 [2]
> page 21 top.
>
> [1] https://github.com/msm8916-mainline/linux-downstream/blob/GT-I9195I/drivers/mfd/rt5033_core.c#L484
> [2] https://www.richtek.com/assets/product_file/RT9455/DS9455-00.pdf
>
> Signed-off-by: Jakob Hauser <jahau@rocketmail.com>
> ---
> drivers/mfd/rt5033.c | 8 +++++---
> include/linux/mfd/rt5033-private.h | 4 ++++
> 2 files changed, 9 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/mfd/rt5033.c b/drivers/mfd/rt5033.c
> index 8029d444b794..d32467174cb5 100644
> --- a/drivers/mfd/rt5033.c
> +++ b/drivers/mfd/rt5033.c
> @@ -55,7 +55,8 @@ static const struct regmap_config rt5033_regmap_config = {
> static int rt5033_i2c_probe(struct i2c_client *i2c)
> {
> struct rt5033_dev *rt5033;
> - unsigned int dev_id;
> + unsigned int data;
In terms of nomenclature, this is a regression.
'data' is a terrible variable name. Why not keep it as-is?
> + unsigned int chip_rev;
> int ret;
>
> rt5033 = devm_kzalloc(&i2c->dev, sizeof(*rt5033), GFP_KERNEL);
> @@ -73,12 +74,13 @@ static int rt5033_i2c_probe(struct i2c_client *i2c)
> return PTR_ERR(rt5033->regmap);
> }
>
> - ret = regmap_read(rt5033->regmap, RT5033_REG_DEVICE_ID, &dev_id);
> + ret = regmap_read(rt5033->regmap, RT5033_REG_DEVICE_ID, &data);
> if (ret) {
> dev_err(&i2c->dev, "Device not found\n");
> return -ENODEV;
> }
> - dev_info(&i2c->dev, "Device found Device ID: %04x\n", dev_id);
> + chip_rev = data & RT5033_CHIP_REV_MASK;
> + dev_info(&i2c->dev, "Device found (rev. %d)\n", chip_rev);
Why not print both?
> ret = regmap_add_irq_chip(rt5033->regmap, rt5033->irq,
> IRQF_TRIGGER_FALLING | IRQF_ONESHOT,
> diff --git a/include/linux/mfd/rt5033-private.h b/include/linux/mfd/rt5033-private.h
> index 2d1895c3efbf..d18cd4572208 100644
> --- a/include/linux/mfd/rt5033-private.h
> +++ b/include/linux/mfd/rt5033-private.h
> @@ -71,6 +71,10 @@ enum rt5033_reg {
g
> /* RT5033 CHGCTRL2 register */
> #define RT5033_CHGCTRL2_CV_MASK 0xfc
>
> +/* RT5033 DEVICE_ID register */
> +#define RT5033_VENDOR_ID_MASK 0xf0
> +#define RT5033_CHIP_REV_MASK 0x0f
> +
> /* RT5033 CHGCTRL3 register */
> #define RT5033_CHGCTRL3_CFO_EN_MASK 0x40
> #define RT5033_CHGCTRL3_TIMER_MASK 0x38
> --
> 2.39.1
>
--
Lee Jones [李琼斯]
^ permalink raw reply [flat|nested] 30+ messages in thread* Re: [PATCH 02/10] mfd: rt5033: Fix chip revision readout
2023-03-05 10:47 ` Lee Jones
@ 2023-03-05 16:10 ` Jakob Hauser
2023-03-06 9:18 ` Lee Jones
0 siblings, 1 reply; 30+ messages in thread
From: Jakob Hauser @ 2023-03-05 16:10 UTC (permalink / raw)
To: Lee Jones
Cc: Sebastian Reichel, Liam Girdwood, Mark Brown, Rob Herring,
Krzysztof Kozlowski, Beomho Seo, Chanwoo Choi, Stephan Gerhold,
Raymond Hackley, linux-pm, devicetree, linux-kernel,
~postmarketos/upstreaming
Hi Lee,
On 05.03.23 11:47, Lee Jones wrote:
> On Tue, 28 Feb 2023, Jakob Hauser wrote:
>
>> After reading the data from the DEVICE_ID register, mask 0x0f needs to be
>> applied to extract the revision of the chip [1].
>>
>> The other part of the DEVICE_ID register, mask 0xf0, is a vendor identification
>> code. That's how it is set up at similar products of Richtek, e.g. RT9455 [2]
>> page 21 top.
>>
>> [1] https://github.com/msm8916-mainline/linux-downstream/blob/GT-I9195I/drivers/mfd/rt5033_core.c#L484
>> [2] https://www.richtek.com/assets/product_file/RT9455/DS9455-00.pdf
>>
>> Signed-off-by: Jakob Hauser <jahau@rocketmail.com>
>> ---
>> drivers/mfd/rt5033.c | 8 +++++---
>> include/linux/mfd/rt5033-private.h | 4 ++++
>> 2 files changed, 9 insertions(+), 3 deletions(-)
>>
>> diff --git a/drivers/mfd/rt5033.c b/drivers/mfd/rt5033.c
>> index 8029d444b794..d32467174cb5 100644
>> --- a/drivers/mfd/rt5033.c
>> +++ b/drivers/mfd/rt5033.c
>> @@ -55,7 +55,8 @@ static const struct regmap_config rt5033_regmap_config = {
>> static int rt5033_i2c_probe(struct i2c_client *i2c)
>> {
>> struct rt5033_dev *rt5033;
>> - unsigned int dev_id;
>> + unsigned int data;
>
> In terms of nomenclature, this is a regression.
>
> 'data' is a terrible variable name. Why not keep it as-is?
While not having a datasheet for RT5033 available, in similar products
like RT9455 the register is called "Device ID", the first part of that
is "VENDOR_ID" and the second part "CHIP_REV", [1] page 23 top. Or in
RT5036 preliminary data sheet the register is called "ID", the first
part "VENDOR_ID" and the second part "CHIP_REV_ID", [2] page 27 top.
I wanted to avoid confusion between "dev_id" and "chip_rev". Therefore
in the patch it's written as getting some "data" from the register and
extract "chip_rev" from that data.
I could change it to "reg_data"? Or something in that direction? I still
think that getting "chip_rev" out of "dev_id" would be confusing.
[1] https://www.richtek.com/assets/product_file/RT9455/DS9455-00.pdf
[2]
https://media.digikey.com/pdf/Data%20Sheets/Richtek%20PDF/RT5036%20%20Preliminary.pdf
>
>> + unsigned int chip_rev;
>> int ret;
>>
>> rt5033 = devm_kzalloc(&i2c->dev, sizeof(*rt5033), GFP_KERNEL);
>> @@ -73,12 +74,13 @@ static int rt5033_i2c_probe(struct i2c_client *i2c)
>> return PTR_ERR(rt5033->regmap);
>> }
>>
>> - ret = regmap_read(rt5033->regmap, RT5033_REG_DEVICE_ID, &dev_id);
>> + ret = regmap_read(rt5033->regmap, RT5033_REG_DEVICE_ID, &data);
>> if (ret) {
>> dev_err(&i2c->dev, "Device not found\n");
>> return -ENODEV;
>> }
>> - dev_info(&i2c->dev, "Device found Device ID: %04x\n", dev_id);
>> + chip_rev = data & RT5033_CHIP_REV_MASK;
>> + dev_info(&i2c->dev, "Device found (rev. %d)\n", chip_rev);
>
> Why not print both?
As described above, the data "dev_id" consists of a first part which is
a vendor ID and a second part which is the chip revision.
The vendor ID is of no interest here. These bits[7:4] contain binary
value 1000 (decimal value 8) and I'd expect that to be the same on all
RT5033 devices.
Contrary to this, the chip revision is an important information. The
downstream Android driver applies some quirks depending on the chip
revision. This seemed not yet necessary in the upstream driver. So far
I've seen chip rev. 6 on samsung-serranove & samsung-e7 and chip rev. 5
on samsung-grandmax & samsung-fortuna, the behavior of the chip
revisions are slightly different.
Accordingly, the downstream Android driver as well reads [3] and prints
[4] the chip revision only – confusingly calling it "rev id".
[3]
https://github.com/msm8916-mainline/linux-downstream/blob/GT-I9195I/drivers/mfd/rt5033_core.c#L484
[4]
https://github.com/msm8916-mainline/linux-downstream/blob/GT-I9195I/drivers/mfd/rt5033_core.c#L486
>> ret = regmap_add_irq_chip(rt5033->regmap, rt5033->irq,
>> IRQF_TRIGGER_FALLING | IRQF_ONESHOT,
>> diff --git a/include/linux/mfd/rt5033-private.h b/include/linux/mfd/rt5033-private.h
>> index 2d1895c3efbf..d18cd4572208 100644
>> --- a/include/linux/mfd/rt5033-private.h
>> +++ b/include/linux/mfd/rt5033-private.h
>> @@ -71,6 +71,10 @@ enum rt5033_reg {
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> g
What does the "g" mean, was this on purpose? I didn't get the meaning of it.
>> /* RT5033 CHGCTRL2 register */
>> #define RT5033_CHGCTRL2_CV_MASK 0xfc
>>
>> +/* RT5033 DEVICE_ID register */
>> +#define RT5033_VENDOR_ID_MASK 0xf0
>> +#define RT5033_CHIP_REV_MASK 0x0f
>> +
>> /* RT5033 CHGCTRL3 register */
>> #define RT5033_CHGCTRL3_CFO_EN_MASK 0x40
>> #define RT5033_CHGCTRL3_TIMER_MASK 0x38
>> --
>> 2.39.1
>>
>
Kind regards,
Jakob
^ permalink raw reply [flat|nested] 30+ messages in thread* Re: [PATCH 02/10] mfd: rt5033: Fix chip revision readout
2023-03-05 16:10 ` Jakob Hauser
@ 2023-03-06 9:18 ` Lee Jones
2023-03-06 22:57 ` Jakob Hauser
0 siblings, 1 reply; 30+ messages in thread
From: Lee Jones @ 2023-03-06 9:18 UTC (permalink / raw)
To: Jakob Hauser
Cc: Sebastian Reichel, Liam Girdwood, Mark Brown, Rob Herring,
Krzysztof Kozlowski, Beomho Seo, Chanwoo Choi, Stephan Gerhold,
Raymond Hackley, linux-pm, devicetree, linux-kernel,
~postmarketos/upstreaming
On Sun, 05 Mar 2023, Jakob Hauser wrote:
> Hi Lee,
>
> On 05.03.23 11:47, Lee Jones wrote:
> > On Tue, 28 Feb 2023, Jakob Hauser wrote:
> >
> > > After reading the data from the DEVICE_ID register, mask 0x0f needs to be
> > > applied to extract the revision of the chip [1].
> > >
> > > The other part of the DEVICE_ID register, mask 0xf0, is a vendor identification
> > > code. That's how it is set up at similar products of Richtek, e.g. RT9455 [2]
> > > page 21 top.
> > >
> > > [1] https://github.com/msm8916-mainline/linux-downstream/blob/GT-I9195I/drivers/mfd/rt5033_core.c#L484
> > > [2] https://www.richtek.com/assets/product_file/RT9455/DS9455-00.pdf
> > >
> > > Signed-off-by: Jakob Hauser <jahau@rocketmail.com>
> > > ---
> > > drivers/mfd/rt5033.c | 8 +++++---
> > > include/linux/mfd/rt5033-private.h | 4 ++++
> > > 2 files changed, 9 insertions(+), 3 deletions(-)
> > >
> > > diff --git a/drivers/mfd/rt5033.c b/drivers/mfd/rt5033.c
> > > index 8029d444b794..d32467174cb5 100644
> > > --- a/drivers/mfd/rt5033.c
> > > +++ b/drivers/mfd/rt5033.c
> > > @@ -55,7 +55,8 @@ static const struct regmap_config rt5033_regmap_config = {
> > > static int rt5033_i2c_probe(struct i2c_client *i2c)
> > > {
> > > struct rt5033_dev *rt5033;
> > > - unsigned int dev_id;
> > > + unsigned int data;
> >
> > In terms of nomenclature, this is a regression.
> >
> > 'data' is a terrible variable name. Why not keep it as-is?
>
> While not having a datasheet for RT5033 available, in similar products like
> RT9455 the register is called "Device ID", the first part of that is
> "VENDOR_ID" and the second part "CHIP_REV", [1] page 23 top. Or in RT5036
> preliminary data sheet the register is called "ID", the first part
> "VENDOR_ID" and the second part "CHIP_REV_ID", [2] page 27 top.
>
> I wanted to avoid confusion between "dev_id" and "chip_rev". Therefore in
> the patch it's written as getting some "data" from the register and extract
> "chip_rev" from that data.
>
> I could change it to "reg_data"? Or something in that direction? I still
> think that getting "chip_rev" out of "dev_id" would be confusing.
You're reading from a register called RT5033_REG_DEVICE_ID. I don't see
any reason why the variable you read into can't reflect that.
> [1] https://www.richtek.com/assets/product_file/RT9455/DS9455-00.pdf
> [2] https://media.digikey.com/pdf/Data%20Sheets/Richtek%20PDF/RT5036%20%20Preliminary.pdf
>
> >
> > > + unsigned int chip_rev;
> > > int ret;
> > > rt5033 = devm_kzalloc(&i2c->dev, sizeof(*rt5033), GFP_KERNEL);
> > > @@ -73,12 +74,13 @@ static int rt5033_i2c_probe(struct i2c_client *i2c)
> > > return PTR_ERR(rt5033->regmap);
> > > }
> > > - ret = regmap_read(rt5033->regmap, RT5033_REG_DEVICE_ID, &dev_id);
> > > + ret = regmap_read(rt5033->regmap, RT5033_REG_DEVICE_ID, &data);
> > > if (ret) {
> > > dev_err(&i2c->dev, "Device not found\n");
> > > return -ENODEV;
> > > }
> > > - dev_info(&i2c->dev, "Device found Device ID: %04x\n", dev_id);
> > > + chip_rev = data & RT5033_CHIP_REV_MASK;
> > > + dev_info(&i2c->dev, "Device found (rev. %d)\n", chip_rev);
> >
> > Why not print both?
>
> As described above, the data "dev_id" consists of a first part which is a
> vendor ID and a second part which is the chip revision.
>
> The vendor ID is of no interest here. These bits[7:4] contain binary value
> 1000 (decimal value 8) and I'd expect that to be the same on all RT5033
> devices.
>
> Contrary to this, the chip revision is an important information. The
> downstream Android driver applies some quirks depending on the chip
> revision. This seemed not yet necessary in the upstream driver. So far I've
> seen chip rev. 6 on samsung-serranove & samsung-e7 and chip rev. 5 on
> samsung-grandmax & samsung-fortuna, the behavior of the chip revisions are
> slightly different.
>
> Accordingly, the downstream Android driver as well reads [3] and prints [4]
> the chip revision only – confusingly calling it "rev id".
> [3] https://github.com/msm8916-mainline/linux-downstream/blob/GT-I9195I/drivers/mfd/rt5033_core.c#L484
> [4] https://github.com/msm8916-mainline/linux-downstream/blob/GT-I9195I/drivers/mfd/rt5033_core.c#L486
>
> > > ret = regmap_add_irq_chip(rt5033->regmap, rt5033->irq,
> > > IRQF_TRIGGER_FALLING | IRQF_ONESHOT,
> > > diff --git a/include/linux/mfd/rt5033-private.h b/include/linux/mfd/rt5033-private.h
> > > index 2d1895c3efbf..d18cd4572208 100644
> > > --- a/include/linux/mfd/rt5033-private.h
> > > +++ b/include/linux/mfd/rt5033-private.h
> > > @@ -71,6 +71,10 @@ enum rt5033_reg {
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > g
>
> What does the "g" mean, was this on purpose? I didn't get the meaning of it.
>
> > > /* RT5033 CHGCTRL2 register */
> > > #define RT5033_CHGCTRL2_CV_MASK 0xfc
> > > +/* RT5033 DEVICE_ID register */
> > > +#define RT5033_VENDOR_ID_MASK 0xf0
> > > +#define RT5033_CHIP_REV_MASK 0x0f
> > > +
> > > /* RT5033 CHGCTRL3 register */
> > > #define RT5033_CHGCTRL3_CFO_EN_MASK 0x40
> > > #define RT5033_CHGCTRL3_TIMER_MASK 0x38
> > > --
> > > 2.39.1
> > >
> >
>
> Kind regards,
> Jakob
--
Lee Jones [李琼斯]
^ permalink raw reply [flat|nested] 30+ messages in thread* Re: [PATCH 02/10] mfd: rt5033: Fix chip revision readout
2023-03-06 9:18 ` Lee Jones
@ 2023-03-06 22:57 ` Jakob Hauser
0 siblings, 0 replies; 30+ messages in thread
From: Jakob Hauser @ 2023-03-06 22:57 UTC (permalink / raw)
To: Lee Jones
Cc: Sebastian Reichel, Liam Girdwood, Mark Brown, Rob Herring,
Krzysztof Kozlowski, Beomho Seo, Chanwoo Choi, Stephan Gerhold,
Raymond Hackley, linux-pm, devicetree, linux-kernel,
~postmarketos/upstreaming
Hi Lee,
On 06.03.23 10:18, Lee Jones wrote:
> On Sun, 05 Mar 2023, Jakob Hauser wrote:
>
>> Hi Lee,
>>
>> On 05.03.23 11:47, Lee Jones wrote:
>>> On Tue, 28 Feb 2023, Jakob Hauser wrote:
>>>
>>>> After reading the data from the DEVICE_ID register, mask 0x0f needs to be
>>>> applied to extract the revision of the chip [1].
>>>>
>>>> The other part of the DEVICE_ID register, mask 0xf0, is a vendor identification
>>>> code. That's how it is set up at similar products of Richtek, e.g. RT9455 [2]
>>>> page 21 top.
>>>>
>>>> [1] https://github.com/msm8916-mainline/linux-downstream/blob/GT-I9195I/drivers/mfd/rt5033_core.c#L484
>>>> [2] https://www.richtek.com/assets/product_file/RT9455/DS9455-00.pdf
>>>>
>>>> Signed-off-by: Jakob Hauser <jahau@rocketmail.com>
>>>> ---
>>>> drivers/mfd/rt5033.c | 8 +++++---
>>>> include/linux/mfd/rt5033-private.h | 4 ++++
>>>> 2 files changed, 9 insertions(+), 3 deletions(-)
>>>>
>>>> diff --git a/drivers/mfd/rt5033.c b/drivers/mfd/rt5033.c
>>>> index 8029d444b794..d32467174cb5 100644
>>>> --- a/drivers/mfd/rt5033.c
>>>> +++ b/drivers/mfd/rt5033.c
>>>> @@ -55,7 +55,8 @@ static const struct regmap_config rt5033_regmap_config = {
>>>> static int rt5033_i2c_probe(struct i2c_client *i2c)
>>>> {
>>>> struct rt5033_dev *rt5033;
>>>> - unsigned int dev_id;
>>>> + unsigned int data;
>>>
>>> In terms of nomenclature, this is a regression.
>>>
>>> 'data' is a terrible variable name. Why not keep it as-is?
>>
>> While not having a datasheet for RT5033 available, in similar products like
>> RT9455 the register is called "Device ID", the first part of that is
>> "VENDOR_ID" and the second part "CHIP_REV", [1] page 23 top. Or in RT5036
>> preliminary data sheet the register is called "ID", the first part
>> "VENDOR_ID" and the second part "CHIP_REV_ID", [2] page 27 top.
>>
>> I wanted to avoid confusion between "dev_id" and "chip_rev". Therefore in
>> the patch it's written as getting some "data" from the register and extract
>> "chip_rev" from that data.
>>
>> I could change it to "reg_data"? Or something in that direction? I still
>> think that getting "chip_rev" out of "dev_id" would be confusing.
>
> You're reading from a register called RT5033_REG_DEVICE_ID. I don't see
> any reason why the variable you read into can't reflect that.
OK, I'll use "dev_id" and "chip_rev" for the variable names.
...
Kind regards,
Jakob
^ permalink raw reply [flat|nested] 30+ messages in thread
* [PATCH 03/10] mfd: rt5033: Fix comments and style in includes
2023-02-28 22:32 ` [PATCH 00/10] Add RT5033 charger device driver Jakob Hauser
2023-02-28 22:32 ` [PATCH 01/10] mfd: rt5033: Drop rt5033-battery sub-device Jakob Hauser
2023-02-28 22:32 ` [PATCH 02/10] mfd: rt5033: Fix chip revision readout Jakob Hauser
@ 2023-02-28 22:32 ` Jakob Hauser
2023-03-05 10:48 ` Lee Jones
2023-02-28 22:32 ` [PATCH 04/10] mfd: rt5033: Fix STAT_MASK, HZ_MASK and AICR defines Jakob Hauser
` (7 subsequent siblings)
10 siblings, 1 reply; 30+ messages in thread
From: Jakob Hauser @ 2023-02-28 22:32 UTC (permalink / raw)
To: Sebastian Reichel, Lee Jones, Liam Girdwood, Mark Brown,
Rob Herring, Krzysztof Kozlowski
Cc: Beomho Seo, Chanwoo Choi, Stephan Gerhold, Raymond Hackley,
linux-pm, devicetree, linux-kernel, ~postmarketos/upstreaming,
Jakob Hauser
Fix comments and remove some empty lines in rt5033-private.h. Align struct
rt5033_charger in rt5033.h.
Signed-off-by: Jakob Hauser <jahau@rocketmail.com>
---
include/linux/mfd/rt5033-private.h | 17 +++++++----------
include/linux/mfd/rt5033.h | 7 +++----
2 files changed, 10 insertions(+), 14 deletions(-)
diff --git a/include/linux/mfd/rt5033-private.h b/include/linux/mfd/rt5033-private.h
index d18cd4572208..b035a67cec73 100644
--- a/include/linux/mfd/rt5033-private.h
+++ b/include/linux/mfd/rt5033-private.h
@@ -111,14 +111,13 @@ enum rt5033_reg {
#define RT5033_LDO_CTRL_MASK 0x1f
/* RT5033 charger property - model, manufacturer */
-
#define RT5033_CHARGER_MODEL "RT5033WSC Charger"
#define RT5033_MANUFACTURER "Richtek Technology Corporation"
/*
- * RT5033 charger fast-charge current lmits (as in CHGCTRL1 register),
- * AICR mode limits the input current for example,
- * the AIRC 100 mode limits the input current to 100 mA.
+ * While RT5033 charger can limit the fast-charge current (as in CHGCTRL1
+ * register), AICR mode limits the input current. For example, the AIRC 100
+ * mode limits the input current to 100 mA.
*/
#define RT5033_AICR_100_MODE 0x20
#define RT5033_AICR_500_MODE 0x40
@@ -143,10 +142,9 @@ enum rt5033_reg {
#define RT5033_TE_ENABLE_MASK 0x08
/*
- * RT5033 charger opa mode. RT50300 have two opa mode charger mode
- * and boost mode for OTG
+ * RT5033 charger opa mode. RT5033 has two opa modes for OTG: charger mode
+ * and boost mode.
*/
-
#define RT5033_CHARGER_MODE 0x00
#define RT5033_BOOST_MODE 0x01
@@ -185,18 +183,17 @@ enum rt5033_reg {
* RT5033 charger pre-charge threshold volt limits
* (as in CHGCTRL5 register), uV
*/
-
#define RT5033_CHARGER_PRE_THRESHOLD_LIMIT_MIN 2300000U
#define RT5033_CHARGER_PRE_THRESHOLD_STEP_NUM 100000U
#define RT5033_CHARGER_PRE_THRESHOLD_LIMIT_MAX 3800000U
/*
- * RT5033 charger enable UUG, If UUG enable MOS auto control by H/W charger
+ * RT5033 charger UUG. It enables MOS auto control by H/W charger
* circuit.
*/
#define RT5033_CHARGER_UUG_ENABLE 0x02
-/* RT5033 charger High impedance mode */
+/* RT5033 charger high impedance mode */
#define RT5033_CHARGER_HZ_DISABLE 0x00
#define RT5033_CHARGER_HZ_ENABLE 0x01
diff --git a/include/linux/mfd/rt5033.h b/include/linux/mfd/rt5033.h
index 3c23b6220c04..8f306ac15a27 100644
--- a/include/linux/mfd/rt5033.h
+++ b/include/linux/mfd/rt5033.h
@@ -49,10 +49,9 @@ struct rt5033_charger_data {
};
struct rt5033_charger {
- struct device *dev;
- struct rt5033_dev *rt5033;
- struct power_supply psy;
-
+ struct device *dev;
+ struct rt5033_dev *rt5033;
+ struct power_supply psy;
struct rt5033_charger_data *chg;
};
--
2.39.1
^ permalink raw reply related [flat|nested] 30+ messages in thread* Re: [PATCH 03/10] mfd: rt5033: Fix comments and style in includes
2023-02-28 22:32 ` [PATCH 03/10] mfd: rt5033: Fix comments and style in includes Jakob Hauser
@ 2023-03-05 10:48 ` Lee Jones
2023-03-05 16:11 ` Jakob Hauser
0 siblings, 1 reply; 30+ messages in thread
From: Lee Jones @ 2023-03-05 10:48 UTC (permalink / raw)
To: Jakob Hauser
Cc: Sebastian Reichel, Liam Girdwood, Mark Brown, Rob Herring,
Krzysztof Kozlowski, Beomho Seo, Chanwoo Choi, Stephan Gerhold,
Raymond Hackley, linux-pm, devicetree, linux-kernel,
~postmarketos/upstreaming
On Tue, 28 Feb 2023, Jakob Hauser wrote:
> Fix comments and remove some empty lines in rt5033-private.h. Align struct
> rt5033_charger in rt5033.h.
>
> Signed-off-by: Jakob Hauser <jahau@rocketmail.com>
> ---
> include/linux/mfd/rt5033-private.h | 17 +++++++----------
> include/linux/mfd/rt5033.h | 7 +++----
> 2 files changed, 10 insertions(+), 14 deletions(-)
Applied, thanks
--
Lee Jones [李琼斯]
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [PATCH 03/10] mfd: rt5033: Fix comments and style in includes
2023-03-05 10:48 ` Lee Jones
@ 2023-03-05 16:11 ` Jakob Hauser
2023-03-06 9:15 ` Lee Jones
0 siblings, 1 reply; 30+ messages in thread
From: Jakob Hauser @ 2023-03-05 16:11 UTC (permalink / raw)
To: Lee Jones
Cc: Sebastian Reichel, Liam Girdwood, Mark Brown, Rob Herring,
Krzysztof Kozlowski, Beomho Seo, Chanwoo Choi, Stephan Gerhold,
Raymond Hackley, linux-pm, devicetree, linux-kernel,
~postmarketos/upstreaming
Hi Lee,
On 05.03.23 11:48, Lee Jones wrote:
> On Tue, 28 Feb 2023, Jakob Hauser wrote:
>
>> Fix comments and remove some empty lines in rt5033-private.h. Align struct
>> rt5033_charger in rt5033.h.
>>
>> Signed-off-by: Jakob Hauser <jahau@rocketmail.com>
>> ---
>> include/linux/mfd/rt5033-private.h | 17 +++++++----------
>> include/linux/mfd/rt5033.h | 7 +++----
>> 2 files changed, 10 insertions(+), 14 deletions(-)
>
> Applied, thanks
>
Thanks! Does this mean I should skip this patch in the next versions of
the patchset? Or should I just add the Acked-for-MFD-by tag of yours? In
the first case I'm not sure what base to use for the next versions of
the patchset. Sorry, I'm not so much familiar with the procedures.
Kind regards,
Jakob
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [PATCH 03/10] mfd: rt5033: Fix comments and style in includes
2023-03-05 16:11 ` Jakob Hauser
@ 2023-03-06 9:15 ` Lee Jones
0 siblings, 0 replies; 30+ messages in thread
From: Lee Jones @ 2023-03-06 9:15 UTC (permalink / raw)
To: Jakob Hauser
Cc: Sebastian Reichel, Liam Girdwood, Mark Brown, Rob Herring,
Krzysztof Kozlowski, Beomho Seo, Chanwoo Choi, Stephan Gerhold,
Raymond Hackley, linux-pm, devicetree, linux-kernel,
~postmarketos/upstreaming
On Sun, 05 Mar 2023, Jakob Hauser wrote:
> Hi Lee,
>
> On 05.03.23 11:48, Lee Jones wrote:
> > On Tue, 28 Feb 2023, Jakob Hauser wrote:
> >
> > > Fix comments and remove some empty lines in rt5033-private.h. Align struct
> > > rt5033_charger in rt5033.h.
> > >
> > > Signed-off-by: Jakob Hauser <jahau@rocketmail.com>
> > > ---
> > > include/linux/mfd/rt5033-private.h | 17 +++++++----------
> > > include/linux/mfd/rt5033.h | 7 +++----
> > > 2 files changed, 10 insertions(+), 14 deletions(-)
> >
> > Applied, thanks
> >
>
> Thanks! Does this mean I should skip this patch in the next versions of the
> patchset? Or should I just add the Acked-for-MFD-by tag of yours? In the
> first case I'm not sure what base to use for the next versions of the
> patchset. Sorry, I'm not so much familiar with the procedures.
You should rebase onto -next before sending out your next submission.
This patch should vanish from the set.
If it doesn't, please wait another 24hrs and try again.
--
Lee Jones [李琼斯]
^ permalink raw reply [flat|nested] 30+ messages in thread
* [PATCH 04/10] mfd: rt5033: Fix STAT_MASK, HZ_MASK and AICR defines
2023-02-28 22:32 ` [PATCH 00/10] Add RT5033 charger device driver Jakob Hauser
` (2 preceding siblings ...)
2023-02-28 22:32 ` [PATCH 03/10] mfd: rt5033: Fix comments and style in includes Jakob Hauser
@ 2023-02-28 22:32 ` Jakob Hauser
2023-03-05 10:52 ` Lee Jones
2023-02-28 22:32 ` [PATCH 05/10] mfd: rt5033: Apply preparatory changes before adding rt5033-charger driver Jakob Hauser
` (6 subsequent siblings)
10 siblings, 1 reply; 30+ messages in thread
From: Jakob Hauser @ 2023-02-28 22:32 UTC (permalink / raw)
To: Sebastian Reichel, Lee Jones, Liam Girdwood, Mark Brown,
Rob Herring, Krzysztof Kozlowski
Cc: Beomho Seo, Chanwoo Choi, Stephan Gerhold, Raymond Hackley,
linux-pm, devicetree, linux-kernel, ~postmarketos/upstreaming,
Jakob Hauser
The charger state mask RT5033_CHG_STAT_MASK should be 0x30 [1][2].
The high impedance mask RT5033_RT_HZ_MASK is actually value 0x02 [3] and is
assosiated to the RT5033 CHGCTRL1 register [4]. Accordingly also change
RT5033_CHARGER_HZ_ENABLE to 0x02 to avoid the need of a bit shift upon
application.
For input current limiting AICR mode, the define for the 1000 mA step was
missing [5]. Additionally add the define for DISABLE option. Concerning the
mask, remove RT5033_AICR_MODE_MASK because there is already
RT5033_CHGCTRL1_IAICR_MASK further up. They are redundant and the upper one
makes more sense to have the masks of a register colleted there as an
overview.
[1] https://github.com/msm8916-mainline/linux-downstream/blob/GT-I9195I/drivers/battery/rt5033_charger.c#L669-L682
[2] https://github.com/torvalds/linux/blob/v6.0/include/linux/mfd/rt5033-private.h#L59-L62
[3] https://github.com/msm8916-mainline/linux-downstream/blob/GT-I9195I/include/linux/battery/charger/rt5033_charger.h#L44
[4] https://github.com/msm8916-mainline/linux-downstream/blob/GT-I9195I/drivers/battery/rt5033_charger.c#L223
[5] https://github.com/msm8916-mainline/linux-downstream/blob/GT-I9195I/drivers/battery/rt5033_charger.c#L278
Signed-off-by: Jakob Hauser <jahau@rocketmail.com>
---
include/linux/mfd/rt5033-private.h | 9 +++++----
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/include/linux/mfd/rt5033-private.h b/include/linux/mfd/rt5033-private.h
index b035a67cec73..b6773ebf4e6b 100644
--- a/include/linux/mfd/rt5033-private.h
+++ b/include/linux/mfd/rt5033-private.h
@@ -55,7 +55,7 @@ enum rt5033_reg {
};
/* RT5033 Charger state register */
-#define RT5033_CHG_STAT_MASK 0x20
+#define RT5033_CHG_STAT_MASK 0x30
#define RT5033_CHG_STAT_DISCHARGING 0x00
#define RT5033_CHG_STAT_FULL 0x10
#define RT5033_CHG_STAT_CHARGING 0x20
@@ -67,6 +67,7 @@ enum rt5033_reg {
/* RT5033 CHGCTRL1 register */
#define RT5033_CHGCTRL1_IAICR_MASK 0xe0
#define RT5033_CHGCTRL1_MODE_MASK 0x01
+#define RT5033_CHGCTRL1_HZ_MASK 0x02
/* RT5033 CHGCTRL2 register */
#define RT5033_CHGCTRL2_CV_MASK 0xfc
@@ -92,7 +93,6 @@ enum rt5033_reg {
/* RT5033 RT CTRL1 register */
#define RT5033_RT_CTRL1_UUG_MASK 0x02
-#define RT5033_RT_HZ_MASK 0x01
/* RT5033 control register */
#define RT5033_CTRL_FCCM_BUCK_MASK BIT(0)
@@ -119,13 +119,14 @@ enum rt5033_reg {
* register), AICR mode limits the input current. For example, the AIRC 100
* mode limits the input current to 100 mA.
*/
+#define RT5033_AICR_DISABLE 0x00
#define RT5033_AICR_100_MODE 0x20
#define RT5033_AICR_500_MODE 0x40
#define RT5033_AICR_700_MODE 0x60
#define RT5033_AICR_900_MODE 0x80
+#define RT5033_AICR_1000_MODE 0xa0
#define RT5033_AICR_1500_MODE 0xc0
#define RT5033_AICR_2000_MODE 0xe0
-#define RT5033_AICR_MODE_MASK 0xe0
/* RT5033 use internal timer need to set time */
#define RT5033_FAST_CHARGE_TIMER4 0x00
@@ -195,7 +196,7 @@ enum rt5033_reg {
/* RT5033 charger high impedance mode */
#define RT5033_CHARGER_HZ_DISABLE 0x00
-#define RT5033_CHARGER_HZ_ENABLE 0x01
+#define RT5033_CHARGER_HZ_ENABLE 0x02
/* RT5033 regulator BUCK output voltage uV */
#define RT5033_REGULATOR_BUCK_VOLTAGE_MIN 1000000U
--
2.39.1
^ permalink raw reply related [flat|nested] 30+ messages in thread* Re: [PATCH 04/10] mfd: rt5033: Fix STAT_MASK, HZ_MASK and AICR defines
2023-02-28 22:32 ` [PATCH 04/10] mfd: rt5033: Fix STAT_MASK, HZ_MASK and AICR defines Jakob Hauser
@ 2023-03-05 10:52 ` Lee Jones
0 siblings, 0 replies; 30+ messages in thread
From: Lee Jones @ 2023-03-05 10:52 UTC (permalink / raw)
To: Jakob Hauser
Cc: Sebastian Reichel, Liam Girdwood, Mark Brown, Rob Herring,
Krzysztof Kozlowski, Beomho Seo, Chanwoo Choi, Stephan Gerhold,
Raymond Hackley, linux-pm, devicetree, linux-kernel,
~postmarketos/upstreaming
On Tue, 28 Feb 2023, Jakob Hauser wrote:
> The charger state mask RT5033_CHG_STAT_MASK should be 0x30 [1][2].
>
> The high impedance mask RT5033_RT_HZ_MASK is actually value 0x02 [3] and is
> assosiated to the RT5033 CHGCTRL1 register [4]. Accordingly also change
> RT5033_CHARGER_HZ_ENABLE to 0x02 to avoid the need of a bit shift upon
> application.
>
> For input current limiting AICR mode, the define for the 1000 mA step was
> missing [5]. Additionally add the define for DISABLE option. Concerning the
> mask, remove RT5033_AICR_MODE_MASK because there is already
> RT5033_CHGCTRL1_IAICR_MASK further up. They are redundant and the upper one
> makes more sense to have the masks of a register colleted there as an
> overview.
>
> [1] https://github.com/msm8916-mainline/linux-downstream/blob/GT-I9195I/drivers/battery/rt5033_charger.c#L669-L682
> [2] https://github.com/torvalds/linux/blob/v6.0/include/linux/mfd/rt5033-private.h#L59-L62
> [3] https://github.com/msm8916-mainline/linux-downstream/blob/GT-I9195I/include/linux/battery/charger/rt5033_charger.h#L44
> [4] https://github.com/msm8916-mainline/linux-downstream/blob/GT-I9195I/drivers/battery/rt5033_charger.c#L223
> [5] https://github.com/msm8916-mainline/linux-downstream/blob/GT-I9195I/drivers/battery/rt5033_charger.c#L278
>
> Signed-off-by: Jakob Hauser <jahau@rocketmail.com>
> ---
> include/linux/mfd/rt5033-private.h | 9 +++++----
> 1 file changed, 5 insertions(+), 4 deletions(-)
For my own reference (apply this as-is to your sign-off block):
Acked-for-MFD-by: Lee Jones <lee@kernel.org>
--
Lee Jones [李琼斯]
^ permalink raw reply [flat|nested] 30+ messages in thread
* [PATCH 05/10] mfd: rt5033: Apply preparatory changes before adding rt5033-charger driver
2023-02-28 22:32 ` [PATCH 00/10] Add RT5033 charger device driver Jakob Hauser
` (3 preceding siblings ...)
2023-02-28 22:32 ` [PATCH 04/10] mfd: rt5033: Fix STAT_MASK, HZ_MASK and AICR defines Jakob Hauser
@ 2023-02-28 22:32 ` Jakob Hauser
2023-03-05 10:55 ` Lee Jones
2023-02-28 22:32 ` [PATCH 06/10] power: supply: rt5033_charger: Add RT5033 charger device driver Jakob Hauser
` (5 subsequent siblings)
10 siblings, 1 reply; 30+ messages in thread
From: Jakob Hauser @ 2023-02-28 22:32 UTC (permalink / raw)
To: Sebastian Reichel, Lee Jones, Liam Girdwood, Mark Brown,
Rob Herring, Krzysztof Kozlowski
Cc: Beomho Seo, Chanwoo Choi, Stephan Gerhold, Raymond Hackley,
linux-pm, devicetree, linux-kernel, ~postmarketos/upstreaming,
Jakob Hauser
Order the register blocks to have the masks in descending manner.
Add new defines for constant voltage shift (RT5033_CHGCTRL2_CV_SHIFT),
MIVR mask (RT5033_CHGCTRL4_MIVR_MASK), pre-charge current shift
(RT5033_CHGCTRL4_IPREC_SHIFT), internal timer disable
(RT5033_INT_TIMER_DISABLE), termination disable (RT5033_TE_DISABLE),
CFO disable (RT5033_CFO_DISABLE), UUG disable (RT5033_CHARGER_UUG_DISABLE).
The fast charge timer type needs to be written on mask 0x38
(RT5033_CHGCTRL3_TIMER_MASK). To avoid a bit shift on application, change the
values of the timer types to fit the mask. Added the timout duration as a
comment. And the timer between TIMER8 and TIMER12 is most likely TIMER10, see
e.g. RT5036 [1] page 28 bottom.
Add value options for MIVR (Minimum Input Voltage Regulation).
Move RT5033_TE_ENABLE_MASK to the block "RT5033 CHGCTRL1 register", in order
to have the masks of the register collected there. To fit the naming scheme,
rename it to RT5033_CHGCTRL1_TE_EN_MASK.
Move RT5033_CHG_MAX_CURRENT to the block "RT5033 charger fast-charge current".
Add new defines RT5033_CV_MAX_VOLTAGE and RT5033_CHG_MAX_PRE_CURRENT to the
blocks "RT5033 charger constant charge voltage" and "RT5033 charger pre-charge
current limits".
In include/linux/mfd/rt5033.h, turn power_supply "psy" into a pointer in order
to use it in devm_power_supply_register().
[1] https://media.digikey.com/pdf/Data%20Sheets/Richtek%20PDF/RT5036%20%20Preliminary.pdf
Signed-off-by: Jakob Hauser <jahau@rocketmail.com>
---
include/linux/mfd/rt5033-private.h | 53 ++++++++++++++++++++----------
include/linux/mfd/rt5033.h | 2 +-
2 files changed, 36 insertions(+), 19 deletions(-)
diff --git a/include/linux/mfd/rt5033-private.h b/include/linux/mfd/rt5033-private.h
index b6773ebf4e6b..0221f806d139 100644
--- a/include/linux/mfd/rt5033-private.h
+++ b/include/linux/mfd/rt5033-private.h
@@ -55,22 +55,24 @@ enum rt5033_reg {
};
/* RT5033 Charger state register */
+#define RT5033_CHG_STAT_TYPE_MASK 0x60
+#define RT5033_CHG_STAT_TYPE_PRE 0x20
+#define RT5033_CHG_STAT_TYPE_FAST 0x60
#define RT5033_CHG_STAT_MASK 0x30
#define RT5033_CHG_STAT_DISCHARGING 0x00
#define RT5033_CHG_STAT_FULL 0x10
#define RT5033_CHG_STAT_CHARGING 0x20
#define RT5033_CHG_STAT_NOT_CHARGING 0x30
-#define RT5033_CHG_STAT_TYPE_MASK 0x60
-#define RT5033_CHG_STAT_TYPE_PRE 0x20
-#define RT5033_CHG_STAT_TYPE_FAST 0x60
/* RT5033 CHGCTRL1 register */
#define RT5033_CHGCTRL1_IAICR_MASK 0xe0
-#define RT5033_CHGCTRL1_MODE_MASK 0x01
+#define RT5033_CHGCTRL1_TE_EN_MASK 0x08
#define RT5033_CHGCTRL1_HZ_MASK 0x02
+#define RT5033_CHGCTRL1_MODE_MASK 0x01
/* RT5033 CHGCTRL2 register */
#define RT5033_CHGCTRL2_CV_MASK 0xfc
+#define RT5033_CHGCTRL2_CV_SHIFT 0x02
/* RT5033 DEVICE_ID register */
#define RT5033_VENDOR_ID_MASK 0xf0
@@ -82,14 +84,15 @@ enum rt5033_reg {
#define RT5033_CHGCTRL3_TIMER_EN_MASK 0x01
/* RT5033 CHGCTRL4 register */
-#define RT5033_CHGCTRL4_EOC_MASK 0x07
+#define RT5033_CHGCTRL4_MIVR_MASK 0xe0
#define RT5033_CHGCTRL4_IPREC_MASK 0x18
+#define RT5033_CHGCTRL4_IPREC_SHIFT 0x03
+#define RT5033_CHGCTRL4_EOC_MASK 0x07
/* RT5033 CHGCTRL5 register */
-#define RT5033_CHGCTRL5_VPREC_MASK 0x0f
#define RT5033_CHGCTRL5_ICHG_MASK 0xf0
#define RT5033_CHGCTRL5_ICHG_SHIFT 0x04
-#define RT5033_CHG_MAX_CURRENT 0x0d
+#define RT5033_CHGCTRL5_VPREC_MASK 0x0f
/* RT5033 RT CTRL1 register */
#define RT5033_RT_CTRL1_UUG_MASK 0x02
@@ -128,20 +131,28 @@ enum rt5033_reg {
#define RT5033_AICR_1500_MODE 0xc0
#define RT5033_AICR_2000_MODE 0xe0
-/* RT5033 use internal timer need to set time */
-#define RT5033_FAST_CHARGE_TIMER4 0x00
-#define RT5033_FAST_CHARGE_TIMER6 0x01
-#define RT5033_FAST_CHARGE_TIMER8 0x02
-#define RT5033_FAST_CHARGE_TIMER9 0x03
-#define RT5033_FAST_CHARGE_TIMER12 0x04
-#define RT5033_FAST_CHARGE_TIMER14 0x05
-#define RT5033_FAST_CHARGE_TIMER16 0x06
+/* RT5033 charger minimum input voltage regulation */
+#define RT5033_CHARGER_MIVR_DISABLE 0x00
+#define RT5033_CHARGER_MIVR_4200MV 0x20
+#define RT5033_CHARGER_MIVR_4300MV 0x40
+#define RT5033_CHARGER_MIVR_4400MV 0x60
+#define RT5033_CHARGER_MIVR_4500MV 0x80
+#define RT5033_CHARGER_MIVR_4600MV 0xa0
+#define RT5033_CHARGER_MIVR_4700MV 0xc0
+#define RT5033_CHARGER_MIVR_4800MV 0xe0
+/* RT5033 use internal timer need to set time */
+#define RT5033_FAST_CHARGE_TIMER4 0x00 /* 4 hrs */
+#define RT5033_FAST_CHARGE_TIMER6 0x08 /* 6 hrs */
+#define RT5033_FAST_CHARGE_TIMER8 0x10 /* 8 hrs */
+#define RT5033_FAST_CHARGE_TIMER10 0x18 /* 10 hrs */
+#define RT5033_FAST_CHARGE_TIMER12 0x20 /* 12 hrs */
+#define RT5033_FAST_CHARGE_TIMER14 0x28 /* 14 hrs */
+#define RT5033_FAST_CHARGE_TIMER16 0x30 /* 16 hrs */
+
+#define RT5033_INT_TIMER_DISABLE 0x00
#define RT5033_INT_TIMER_ENABLE 0x01
-/* RT5033 charger termination enable mask */
-#define RT5033_TE_ENABLE_MASK 0x08
-
/*
* RT5033 charger opa mode. RT5033 has two opa modes for OTG: charger mode
* and boost mode.
@@ -150,25 +161,30 @@ enum rt5033_reg {
#define RT5033_BOOST_MODE 0x01
/* RT5033 charger termination enable */
+#define RT5033_TE_DISABLE 0x00
#define RT5033_TE_ENABLE 0x08
/* RT5033 charger CFO enable */
+#define RT5033_CFO_DISABLE 0x00
#define RT5033_CFO_ENABLE 0x40
/* RT5033 charger constant charge voltage (as in CHGCTRL2 register), uV */
#define RT5033_CHARGER_CONST_VOLTAGE_LIMIT_MIN 3650000U
#define RT5033_CHARGER_CONST_VOLTAGE_STEP_NUM 25000U
#define RT5033_CHARGER_CONST_VOLTAGE_LIMIT_MAX 4400000U
+#define RT5033_CV_MAX_VOLTAGE 0x1e
/* RT5033 charger pre-charge current limits (as in CHGCTRL4 register), uA */
#define RT5033_CHARGER_PRE_CURRENT_LIMIT_MIN 350000U
#define RT5033_CHARGER_PRE_CURRENT_STEP_NUM 100000U
#define RT5033_CHARGER_PRE_CURRENT_LIMIT_MAX 650000U
+#define RT5033_CHG_MAX_PRE_CURRENT 0x03
/* RT5033 charger fast-charge current (as in CHGCTRL5 register), uA */
#define RT5033_CHARGER_FAST_CURRENT_MIN 700000U
#define RT5033_CHARGER_FAST_CURRENT_STEP_NUM 100000U
#define RT5033_CHARGER_FAST_CURRENT_MAX 2000000U
+#define RT5033_CHG_MAX_CURRENT 0x0d
/*
* RT5033 charger const-charge end of charger current (
@@ -192,6 +208,7 @@ enum rt5033_reg {
* RT5033 charger UUG. It enables MOS auto control by H/W charger
* circuit.
*/
+#define RT5033_CHARGER_UUG_DISABLE 0x00
#define RT5033_CHARGER_UUG_ENABLE 0x02
/* RT5033 charger high impedance mode */
diff --git a/include/linux/mfd/rt5033.h b/include/linux/mfd/rt5033.h
index 8f306ac15a27..e99e2ab0c1c1 100644
--- a/include/linux/mfd/rt5033.h
+++ b/include/linux/mfd/rt5033.h
@@ -51,7 +51,7 @@ struct rt5033_charger_data {
struct rt5033_charger {
struct device *dev;
struct rt5033_dev *rt5033;
- struct power_supply psy;
+ struct power_supply *psy;
struct rt5033_charger_data *chg;
};
--
2.39.1
^ permalink raw reply related [flat|nested] 30+ messages in thread* Re: [PATCH 05/10] mfd: rt5033: Apply preparatory changes before adding rt5033-charger driver
2023-02-28 22:32 ` [PATCH 05/10] mfd: rt5033: Apply preparatory changes before adding rt5033-charger driver Jakob Hauser
@ 2023-03-05 10:55 ` Lee Jones
2023-03-05 16:14 ` Jakob Hauser
0 siblings, 1 reply; 30+ messages in thread
From: Lee Jones @ 2023-03-05 10:55 UTC (permalink / raw)
To: Jakob Hauser
Cc: Sebastian Reichel, Liam Girdwood, Mark Brown, Rob Herring,
Krzysztof Kozlowski, Beomho Seo, Chanwoo Choi, Stephan Gerhold,
Raymond Hackley, linux-pm, devicetree, linux-kernel,
~postmarketos/upstreaming
On Tue, 28 Feb 2023, Jakob Hauser wrote:
> Order the register blocks to have the masks in descending manner.
>
> Add new defines for constant voltage shift (RT5033_CHGCTRL2_CV_SHIFT),
> MIVR mask (RT5033_CHGCTRL4_MIVR_MASK), pre-charge current shift
> (RT5033_CHGCTRL4_IPREC_SHIFT), internal timer disable
> (RT5033_INT_TIMER_DISABLE), termination disable (RT5033_TE_DISABLE),
> CFO disable (RT5033_CFO_DISABLE), UUG disable (RT5033_CHARGER_UUG_DISABLE).
>
> The fast charge timer type needs to be written on mask 0x38
> (RT5033_CHGCTRL3_TIMER_MASK). To avoid a bit shift on application, change the
> values of the timer types to fit the mask. Added the timout duration as a
> comment. And the timer between TIMER8 and TIMER12 is most likely TIMER10, see
> e.g. RT5036 [1] page 28 bottom.
>
> Add value options for MIVR (Minimum Input Voltage Regulation).
>
> Move RT5033_TE_ENABLE_MASK to the block "RT5033 CHGCTRL1 register", in order
> to have the masks of the register collected there. To fit the naming scheme,
> rename it to RT5033_CHGCTRL1_TE_EN_MASK.
>
> Move RT5033_CHG_MAX_CURRENT to the block "RT5033 charger fast-charge current".
>
> Add new defines RT5033_CV_MAX_VOLTAGE and RT5033_CHG_MAX_PRE_CURRENT to the
> blocks "RT5033 charger constant charge voltage" and "RT5033 charger pre-charge
> current limits".
>
> In include/linux/mfd/rt5033.h, turn power_supply "psy" into a pointer in order
> to use it in devm_power_supply_register().
Are there no present users to account for?
> [1] https://media.digikey.com/pdf/Data%20Sheets/Richtek%20PDF/RT5036%20%20Preliminary.pdf
>
> Signed-off-by: Jakob Hauser <jahau@rocketmail.com>
> ---
> include/linux/mfd/rt5033-private.h | 53 ++++++++++++++++++++----------
> include/linux/mfd/rt5033.h | 2 +-
> 2 files changed, 36 insertions(+),` 19 deletions(-)
--
Lee Jones [李琼斯]
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [PATCH 05/10] mfd: rt5033: Apply preparatory changes before adding rt5033-charger driver
2023-03-05 10:55 ` Lee Jones
@ 2023-03-05 16:14 ` Jakob Hauser
2023-04-02 10:08 ` Jakob Hauser
0 siblings, 1 reply; 30+ messages in thread
From: Jakob Hauser @ 2023-03-05 16:14 UTC (permalink / raw)
To: Lee Jones
Cc: Sebastian Reichel, Liam Girdwood, Mark Brown, Rob Herring,
Krzysztof Kozlowski, Beomho Seo, Chanwoo Choi, Stephan Gerhold,
Raymond Hackley, linux-pm, devicetree, linux-kernel,
~postmarketos/upstreaming
Hi Lee,
On 05.03.23 11:55, Lee Jones wrote:
> On Tue, 28 Feb 2023, Jakob Hauser wrote:
>
>> Order the register blocks to have the masks in descending manner.
>>
>> Add new defines for constant voltage shift (RT5033_CHGCTRL2_CV_SHIFT),
>> MIVR mask (RT5033_CHGCTRL4_MIVR_MASK), pre-charge current shift
>> (RT5033_CHGCTRL4_IPREC_SHIFT), internal timer disable
>> (RT5033_INT_TIMER_DISABLE), termination disable (RT5033_TE_DISABLE),
>> CFO disable (RT5033_CFO_DISABLE), UUG disable (RT5033_CHARGER_UUG_DISABLE).
>>
>> The fast charge timer type needs to be written on mask 0x38
>> (RT5033_CHGCTRL3_TIMER_MASK). To avoid a bit shift on application, change the
>> values of the timer types to fit the mask. Added the timout duration as a
>> comment. And the timer between TIMER8 and TIMER12 is most likely TIMER10, see
>> e.g. RT5036 [1] page 28 bottom.
>>
>> Add value options for MIVR (Minimum Input Voltage Regulation).
>>
>> Move RT5033_TE_ENABLE_MASK to the block "RT5033 CHGCTRL1 register", in order
>> to have the masks of the register collected there. To fit the naming scheme,
>> rename it to RT5033_CHGCTRL1_TE_EN_MASK.
>>
>> Move RT5033_CHG_MAX_CURRENT to the block "RT5033 charger fast-charge current".
>>
>> Add new defines RT5033_CV_MAX_VOLTAGE and RT5033_CHG_MAX_PRE_CURRENT to the
>> blocks "RT5033 charger constant charge voltage" and "RT5033 charger pre-charge
>> current limits".
>>
>> In include/linux/mfd/rt5033.h, turn power_supply "psy" into a pointer in order
>> to use it in devm_power_supply_register().
>
> Are there no present users to account for?
At least none I'm aware of. Within the upstream kernel the
rt5033_charger power_supply didn't exist so far, the patchset is about
to implement it.
>> [1] https://media.digikey.com/pdf/Data%20Sheets/Richtek%20PDF/RT5036%20%20Preliminary.pdf
>>
>> Signed-off-by: Jakob Hauser <jahau@rocketmail.com>
>> ---
>> include/linux/mfd/rt5033-private.h | 53 ++++++++++++++++++++----------
>> include/linux/mfd/rt5033.h | 2 +-
>> 2 files changed, 36 insertions(+),` 19 deletions(-)
>
Kind regards,
Jakob
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [PATCH 05/10] mfd: rt5033: Apply preparatory changes before adding rt5033-charger driver
2023-03-05 16:14 ` Jakob Hauser
@ 2023-04-02 10:08 ` Jakob Hauser
2023-04-05 15:09 ` Lee Jones
0 siblings, 1 reply; 30+ messages in thread
From: Jakob Hauser @ 2023-04-02 10:08 UTC (permalink / raw)
To: Lee Jones
Cc: Sebastian Reichel, Liam Girdwood, Mark Brown, Rob Herring,
Krzysztof Kozlowski, Beomho Seo, Chanwoo Choi, Stephan Gerhold,
Raymond Hackley, linux-pm, devicetree, linux-kernel,
~postmarketos/upstreaming
Hi Lee,
On 05.03.23 17:14, Jakob Hauser wrote:
> On 05.03.23 11:55, Lee Jones wrote:
>> On Tue, 28 Feb 2023, Jakob Hauser wrote:
>>
>>> Order the register blocks to have the masks in descending manner.
>>>
>>> Add new defines for constant voltage shift (RT5033_CHGCTRL2_CV_SHIFT),
>>> MIVR mask (RT5033_CHGCTRL4_MIVR_MASK), pre-charge current shift
>>> (RT5033_CHGCTRL4_IPREC_SHIFT), internal timer disable
>>> (RT5033_INT_TIMER_DISABLE), termination disable (RT5033_TE_DISABLE),
>>> CFO disable (RT5033_CFO_DISABLE), UUG disable
>>> (RT5033_CHARGER_UUG_DISABLE).
>>>
>>> The fast charge timer type needs to be written on mask 0x38
>>> (RT5033_CHGCTRL3_TIMER_MASK). To avoid a bit shift on application,
>>> change the
>>> values of the timer types to fit the mask. Added the timout duration
>>> as a
>>> comment. And the timer between TIMER8 and TIMER12 is most likely
>>> TIMER10, see
>>> e.g. RT5036 [1] page 28 bottom.
>>>
>>> Add value options for MIVR (Minimum Input Voltage Regulation).
>>>
>>> Move RT5033_TE_ENABLE_MASK to the block "RT5033 CHGCTRL1 register",
>>> in order
>>> to have the masks of the register collected there. To fit the naming
>>> scheme,
>>> rename it to RT5033_CHGCTRL1_TE_EN_MASK.
>>>
>>> Move RT5033_CHG_MAX_CURRENT to the block "RT5033 charger fast-charge
>>> current".
>>>
>>> Add new defines RT5033_CV_MAX_VOLTAGE and RT5033_CHG_MAX_PRE_CURRENT
>>> to the
>>> blocks "RT5033 charger constant charge voltage" and "RT5033 charger
>>> pre-charge
>>> current limits".
>>>
>>> In include/linux/mfd/rt5033.h, turn power_supply "psy" into a pointer
>>> in order
>>> to use it in devm_power_supply_register().
>>
>> Are there no present users to account for?
>
> At least none I'm aware of. Within the upstream kernel the
> rt5033_charger power_supply didn't exist so far, the patchset is about
> to implement it.
Is there anything you want me to change or improve on this patch?
>>> [1]
>>> https://media.digikey.com/pdf/Data%20Sheets/Richtek%20PDF/RT5036%20%20Preliminary.pdf
>>>
>>> Signed-off-by: Jakob Hauser <jahau@rocketmail.com>
>>> ---
>>> include/linux/mfd/rt5033-private.h | 53 ++++++++++++++++++++----------
>>> include/linux/mfd/rt5033.h | 2 +-
>>> 2 files changed, 36 insertions(+),` 19 deletions(-)
Kind regards,
Jakob
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [PATCH 05/10] mfd: rt5033: Apply preparatory changes before adding rt5033-charger driver
2023-04-02 10:08 ` Jakob Hauser
@ 2023-04-05 15:09 ` Lee Jones
0 siblings, 0 replies; 30+ messages in thread
From: Lee Jones @ 2023-04-05 15:09 UTC (permalink / raw)
To: Jakob Hauser
Cc: Sebastian Reichel, Liam Girdwood, Mark Brown, Rob Herring,
Krzysztof Kozlowski, Beomho Seo, Chanwoo Choi, Stephan Gerhold,
Raymond Hackley, linux-pm, devicetree, linux-kernel,
~postmarketos/upstreaming
On Sun, 02 Apr 2023, Jakob Hauser wrote:
> Hi Lee,
>
> On 05.03.23 17:14, Jakob Hauser wrote:
> > On 05.03.23 11:55, Lee Jones wrote:
> > > On Tue, 28 Feb 2023, Jakob Hauser wrote:
> > >
> > > > Order the register blocks to have the masks in descending manner.
> > > >
> > > > Add new defines for constant voltage shift (RT5033_CHGCTRL2_CV_SHIFT),
> > > > MIVR mask (RT5033_CHGCTRL4_MIVR_MASK), pre-charge current shift
> > > > (RT5033_CHGCTRL4_IPREC_SHIFT), internal timer disable
> > > > (RT5033_INT_TIMER_DISABLE), termination disable (RT5033_TE_DISABLE),
> > > > CFO disable (RT5033_CFO_DISABLE), UUG disable
> > > > (RT5033_CHARGER_UUG_DISABLE).
> > > >
> > > > The fast charge timer type needs to be written on mask 0x38
> > > > (RT5033_CHGCTRL3_TIMER_MASK). To avoid a bit shift on
> > > > application, change the
> > > > values of the timer types to fit the mask. Added the timout
> > > > duration as a
> > > > comment. And the timer between TIMER8 and TIMER12 is most likely
> > > > TIMER10, see
> > > > e.g. RT5036 [1] page 28 bottom.
> > > >
> > > > Add value options for MIVR (Minimum Input Voltage Regulation).
> > > >
> > > > Move RT5033_TE_ENABLE_MASK to the block "RT5033 CHGCTRL1
> > > > register", in order
> > > > to have the masks of the register collected there. To fit the
> > > > naming scheme,
> > > > rename it to RT5033_CHGCTRL1_TE_EN_MASK.
> > > >
> > > > Move RT5033_CHG_MAX_CURRENT to the block "RT5033 charger
> > > > fast-charge current".
> > > >
> > > > Add new defines RT5033_CV_MAX_VOLTAGE and
> > > > RT5033_CHG_MAX_PRE_CURRENT to the
> > > > blocks "RT5033 charger constant charge voltage" and "RT5033
> > > > charger pre-charge
> > > > current limits".
> > > >
> > > > In include/linux/mfd/rt5033.h, turn power_supply "psy" into a
> > > > pointer in order
> > > > to use it in devm_power_supply_register().
> > >
> > > Are there no present users to account for?
> >
> > At least none I'm aware of. Within the upstream kernel the
> > rt5033_charger power_supply didn't exist so far, the patchset is about
> > to implement it.
>
> Is there anything you want me to change or improve on this patch?
If there were I would have said. :) Please fix up the other review
comments in the set and submit the next revision.
> > > > [1] https://media.digikey.com/pdf/Data%20Sheets/Richtek%20PDF/RT5036%20%20Preliminary.pdf
> > > >
> > > > Signed-off-by: Jakob Hauser <jahau@rocketmail.com>
> > > > ---
> > > > include/linux/mfd/rt5033-private.h | 53 ++++++++++++++++++++----------
> > > > include/linux/mfd/rt5033.h | 2 +-
> > > > 2 files changed, 36 insertions(+),` 19 deletions(-)
>
> Kind regards,
> Jakob
--
Lee Jones [李琼斯]
^ permalink raw reply [flat|nested] 30+ messages in thread
* [PATCH 06/10] power: supply: rt5033_charger: Add RT5033 charger device driver
2023-02-28 22:32 ` [PATCH 00/10] Add RT5033 charger device driver Jakob Hauser
` (4 preceding siblings ...)
2023-02-28 22:32 ` [PATCH 05/10] mfd: rt5033: Apply preparatory changes before adding rt5033-charger driver Jakob Hauser
@ 2023-02-28 22:32 ` Jakob Hauser
2023-02-28 22:32 ` [PATCH 07/10] power: supply: rt5033_charger: Add cable detection and USB OTG supply Jakob Hauser
` (4 subsequent siblings)
10 siblings, 0 replies; 30+ messages in thread
From: Jakob Hauser @ 2023-02-28 22:32 UTC (permalink / raw)
To: Sebastian Reichel, Lee Jones, Liam Girdwood, Mark Brown,
Rob Herring, Krzysztof Kozlowski
Cc: Beomho Seo, Chanwoo Choi, Stephan Gerhold, Raymond Hackley,
linux-pm, devicetree, linux-kernel, ~postmarketos/upstreaming,
Jakob Hauser
This patch adds device driver of Richtek RT5033 PMIC. The driver supports
switching charger. rt5033 charger provides three charging modes. The charging
modes are pre-charge mode, fast charge mode and constant voltage mode. They
vary in charge rate, the charge parameters can be controlled by i2c interface.
Cc: Beomho Seo <beomho.seo@samsung.com>
Cc: Chanwoo Choi <cw00.choi@samsung.com>
Tested-by: Raymond Hackley <raymondhackley@protonmail.com>
Signed-off-by: Jakob Hauser <jahau@rocketmail.com>
---
drivers/power/supply/Kconfig | 8 +
drivers/power/supply/Makefile | 1 +
drivers/power/supply/rt5033_charger.c | 463 ++++++++++++++++++++++++++
3 files changed, 472 insertions(+)
create mode 100644 drivers/power/supply/rt5033_charger.c
diff --git a/drivers/power/supply/Kconfig b/drivers/power/supply/Kconfig
index 0bbfe6a7ce4d..2719c51b6fca 100644
--- a/drivers/power/supply/Kconfig
+++ b/drivers/power/supply/Kconfig
@@ -785,6 +785,14 @@ config BATTERY_RT5033
The fuelgauge calculates and determines the battery state of charge
according to battery open circuit voltage.
+config CHARGER_RT5033
+ tristate "RT5033 battery charger support"
+ depends on MFD_RT5033
+ help
+ This adds support for battery charger in Richtek RT5033 PMIC.
+ The device supports pre-charge mode, fast charge mode and
+ constant voltage mode.
+
config CHARGER_RT9455
tristate "Richtek RT9455 battery charger driver"
depends on I2C
diff --git a/drivers/power/supply/Makefile b/drivers/power/supply/Makefile
index 0ee8653e882e..0a3303176503 100644
--- a/drivers/power/supply/Makefile
+++ b/drivers/power/supply/Makefile
@@ -56,6 +56,7 @@ obj-$(CONFIG_BATTERY_MAX17042) += max17042_battery.o
obj-$(CONFIG_BATTERY_MAX1721X) += max1721x_battery.o
obj-$(CONFIG_BATTERY_Z2) += z2_battery.o
obj-$(CONFIG_BATTERY_RT5033) += rt5033_battery.o
+obj-$(CONFIG_CHARGER_RT5033) += rt5033_charger.o
obj-$(CONFIG_CHARGER_RT9455) += rt9455_charger.o
obj-$(CONFIG_BATTERY_S3C_ADC) += s3c_adc_battery.o
obj-$(CONFIG_BATTERY_TWL4030_MADC) += twl4030_madc_battery.o
diff --git a/drivers/power/supply/rt5033_charger.c b/drivers/power/supply/rt5033_charger.c
new file mode 100644
index 000000000000..6bb3d45a5e9e
--- /dev/null
+++ b/drivers/power/supply/rt5033_charger.c
@@ -0,0 +1,463 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Battery charger driver for RT5033
+ *
+ * Copyright (C) 2014 Samsung Electronics, Co., Ltd.
+ * Author: Beomho Seo <beomho.seo@samsung.com>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include <linux/module.h>
+#include <linux/platform_device.h>
+#include <linux/power_supply.h>
+#include <linux/mfd/rt5033-private.h>
+#include <linux/mfd/rt5033.h>
+
+static int rt5033_get_charger_state(struct rt5033_charger *charger)
+{
+ struct regmap *regmap = charger->rt5033->regmap;
+ unsigned int reg_data;
+ int state;
+
+ if (!regmap)
+ return state;
+
+ regmap_read(regmap, RT5033_REG_CHG_STAT, ®_data);
+
+ switch (reg_data & RT5033_CHG_STAT_MASK) {
+ case RT5033_CHG_STAT_DISCHARGING:
+ state = POWER_SUPPLY_STATUS_DISCHARGING;
+ break;
+ case RT5033_CHG_STAT_CHARGING:
+ state = POWER_SUPPLY_STATUS_CHARGING;
+ break;
+ case RT5033_CHG_STAT_FULL:
+ state = POWER_SUPPLY_STATUS_FULL;
+ break;
+ case RT5033_CHG_STAT_NOT_CHARGING:
+ state = POWER_SUPPLY_STATUS_NOT_CHARGING;
+ break;
+ default:
+ state = POWER_SUPPLY_STATUS_UNKNOWN;
+ }
+
+ return state;
+}
+
+static int rt5033_get_charger_type(struct rt5033_charger *charger)
+{
+ struct regmap *regmap = charger->rt5033->regmap;
+ unsigned int reg_data;
+ int state;
+
+ regmap_read(regmap, RT5033_REG_CHG_STAT, ®_data);
+
+ switch (reg_data & RT5033_CHG_STAT_TYPE_MASK) {
+ case RT5033_CHG_STAT_TYPE_FAST:
+ state = POWER_SUPPLY_CHARGE_TYPE_FAST;
+ break;
+ case RT5033_CHG_STAT_TYPE_PRE:
+ state = POWER_SUPPLY_CHARGE_TYPE_TRICKLE;
+ break;
+ default:
+ state = POWER_SUPPLY_CHARGE_TYPE_NONE;
+ }
+
+ return state;
+}
+
+static int rt5033_get_charger_current_limit(struct rt5033_charger *charger)
+{
+ struct regmap *regmap = charger->rt5033->regmap;
+ unsigned int state, reg_data, data;
+
+ regmap_read(regmap, RT5033_REG_CHG_CTRL5, ®_data);
+
+ state = (reg_data & RT5033_CHGCTRL5_ICHG_MASK)
+ >> RT5033_CHGCTRL5_ICHG_SHIFT;
+
+ data = RT5033_CHARGER_FAST_CURRENT_MIN +
+ RT5033_CHARGER_FAST_CURRENT_STEP_NUM * state;
+
+ return data;
+}
+
+static int rt5033_get_charger_const_voltage(struct rt5033_charger *charger)
+{
+ struct regmap *regmap = charger->rt5033->regmap;
+ unsigned int state, reg_data, data;
+
+ regmap_read(regmap, RT5033_REG_CHG_CTRL2, ®_data);
+
+ state = (reg_data & RT5033_CHGCTRL2_CV_MASK)
+ >> RT5033_CHGCTRL2_CV_SHIFT;
+
+ data = RT5033_CHARGER_CONST_VOLTAGE_LIMIT_MIN +
+ RT5033_CHARGER_CONST_VOLTAGE_STEP_NUM * state;
+
+ return data;
+}
+
+static inline int rt5033_init_const_charge(struct rt5033_charger *charger)
+{
+ struct rt5033_charger_data *chg = charger->chg;
+ int ret;
+ unsigned int val;
+ u8 reg_data;
+
+ /* Set constant voltage mode */
+ if (chg->const_uvolt < RT5033_CHARGER_CONST_VOLTAGE_LIMIT_MIN ||
+ chg->const_uvolt > RT5033_CHARGER_CONST_VOLTAGE_LIMIT_MAX)
+ return -EINVAL;
+
+ if (chg->const_uvolt == RT5033_CHARGER_CONST_VOLTAGE_LIMIT_MIN)
+ reg_data = 0x00;
+ else if (chg->const_uvolt == RT5033_CHARGER_CONST_VOLTAGE_LIMIT_MAX)
+ reg_data = RT5033_CV_MAX_VOLTAGE;
+ else {
+ val = chg->const_uvolt;
+ val -= RT5033_CHARGER_CONST_VOLTAGE_LIMIT_MIN;
+ val /= RT5033_CHARGER_CONST_VOLTAGE_STEP_NUM;
+ reg_data = val;
+ }
+
+ ret = regmap_update_bits(charger->rt5033->regmap, RT5033_REG_CHG_CTRL2,
+ RT5033_CHGCTRL2_CV_MASK,
+ reg_data << RT5033_CHGCTRL2_CV_SHIFT);
+ if (ret) {
+ dev_err(charger->dev, "Failed regmap update\n");
+ return -EINVAL;
+ }
+
+ /* Set end of charge current */
+ if (chg->eoc_uamp < RT5033_CHARGER_EOC_MIN ||
+ chg->eoc_uamp > RT5033_CHARGER_EOC_MAX)
+ return -EINVAL;
+
+ if (chg->eoc_uamp == RT5033_CHARGER_EOC_MIN)
+ reg_data = 0x01;
+ else if (chg->eoc_uamp == RT5033_CHARGER_EOC_MAX)
+ reg_data = 0x07;
+ else {
+ val = chg->eoc_uamp;
+ if (val < RT5033_CHARGER_EOC_REF) {
+ val -= RT5033_CHARGER_EOC_MIN;
+ val /= RT5033_CHARGER_EOC_STEP_NUM1;
+ reg_data = 0x01 + val;
+ } else if (val > RT5033_CHARGER_EOC_REF) {
+ val -= RT5033_CHARGER_EOC_REF;
+ val /= RT5033_CHARGER_EOC_STEP_NUM2;
+ reg_data = 0x04 + val;
+ } else {
+ reg_data = 0x04;
+ }
+ }
+
+ ret = regmap_update_bits(charger->rt5033->regmap, RT5033_REG_CHG_CTRL4,
+ RT5033_CHGCTRL4_EOC_MASK, reg_data);
+ if (ret) {
+ dev_err(charger->dev, "Failed regmap update\n");
+ return -EINVAL;
+ }
+
+ return 0;
+}
+
+static inline int rt5033_init_fast_charge(struct rt5033_charger *charger)
+{
+ struct rt5033_charger_data *chg = charger->chg;
+ int ret;
+ unsigned int val;
+ u8 reg_data;
+
+ /* Set limit input current */
+ ret = regmap_update_bits(charger->rt5033->regmap, RT5033_REG_CHG_CTRL1,
+ RT5033_CHGCTRL1_IAICR_MASK, RT5033_AICR_2000_MODE);
+ if (ret) {
+ dev_err(charger->dev, "Failed regmap update\n");
+ return -EINVAL;
+ }
+
+ /* Set fast-charge mode charging current */
+ if (chg->fast_uamp < RT5033_CHARGER_FAST_CURRENT_MIN ||
+ chg->fast_uamp > RT5033_CHARGER_FAST_CURRENT_MAX)
+ return -EINVAL;
+
+ if (chg->fast_uamp == RT5033_CHARGER_FAST_CURRENT_MIN)
+ reg_data = 0x00;
+ else if (chg->fast_uamp == RT5033_CHARGER_FAST_CURRENT_MAX)
+ reg_data = RT5033_CHG_MAX_CURRENT;
+ else {
+ val = chg->fast_uamp;
+ val -= RT5033_CHARGER_FAST_CURRENT_MIN;
+ val /= RT5033_CHARGER_FAST_CURRENT_STEP_NUM;
+ reg_data = val;
+ }
+
+ ret = regmap_update_bits(charger->rt5033->regmap, RT5033_REG_CHG_CTRL5,
+ RT5033_CHGCTRL5_ICHG_MASK,
+ reg_data << RT5033_CHGCTRL5_ICHG_SHIFT);
+ if (ret) {
+ dev_err(charger->dev, "Failed regmap update\n");
+ return -EINVAL;
+ }
+
+ return 0;
+}
+
+static inline int rt5033_init_pre_charge(struct rt5033_charger *charger)
+{
+ struct rt5033_charger_data *chg = charger->chg;
+ int ret;
+ unsigned int val;
+ u8 reg_data;
+
+ /* Set pre-charge threshold voltage */
+ if (chg->pre_uvolt < RT5033_CHARGER_PRE_THRESHOLD_LIMIT_MIN ||
+ chg->pre_uvolt > RT5033_CHARGER_PRE_THRESHOLD_LIMIT_MAX)
+ return -EINVAL;
+
+ if (chg->pre_uvolt == RT5033_CHARGER_PRE_THRESHOLD_LIMIT_MIN)
+ reg_data = 0x00;
+ else if (chg->pre_uvolt == RT5033_CHARGER_PRE_THRESHOLD_LIMIT_MAX)
+ reg_data = 0x0f;
+ else {
+ val = chg->pre_uvolt;
+ val -= RT5033_CHARGER_PRE_THRESHOLD_LIMIT_MIN;
+ val /= RT5033_CHARGER_PRE_THRESHOLD_STEP_NUM;
+ reg_data = val;
+ }
+
+ ret = regmap_update_bits(charger->rt5033->regmap, RT5033_REG_CHG_CTRL5,
+ RT5033_CHGCTRL5_VPREC_MASK, reg_data);
+ if (ret) {
+ dev_err(charger->dev, "Failed regmap update\n");
+ return -EINVAL;
+ }
+
+ /* Set pre-charge mode charging current */
+ if (chg->pre_uamp < RT5033_CHARGER_PRE_CURRENT_LIMIT_MIN ||
+ chg->pre_uamp > RT5033_CHARGER_PRE_CURRENT_LIMIT_MAX)
+ return -EINVAL;
+
+ if (chg->pre_uamp == RT5033_CHARGER_PRE_CURRENT_LIMIT_MIN)
+ reg_data = 0x00;
+ else if (chg->pre_uamp == RT5033_CHARGER_PRE_CURRENT_LIMIT_MAX)
+ reg_data = RT5033_CHG_MAX_PRE_CURRENT;
+ else {
+ val = chg->pre_uamp;
+ val -= RT5033_CHARGER_PRE_CURRENT_LIMIT_MIN;
+ val /= RT5033_CHARGER_PRE_CURRENT_STEP_NUM;
+ reg_data = val;
+ }
+
+ ret = regmap_update_bits(charger->rt5033->regmap, RT5033_REG_CHG_CTRL4,
+ RT5033_CHGCTRL4_IPREC_MASK,
+ reg_data << RT5033_CHGCTRL4_IPREC_SHIFT);
+ if (ret) {
+ dev_err(charger->dev, "Failed regmap update\n");
+ return -EINVAL;
+ }
+
+ return 0;
+}
+
+static int rt5033_charger_reg_init(struct rt5033_charger *charger)
+{
+ int ret = 0;
+
+ /* Enable charging termination */
+ ret = regmap_update_bits(charger->rt5033->regmap, RT5033_REG_CHG_CTRL1,
+ RT5033_CHGCTRL1_TE_EN_MASK, RT5033_TE_ENABLE);
+ if (ret) {
+ dev_err(charger->dev, "Failed to enable charging termination.\n");
+ return -EINVAL;
+ }
+
+ /*
+ * Disable minimum input voltage regulation (MIVR), this improves
+ * the charging performance.
+ */
+ ret = regmap_update_bits(charger->rt5033->regmap, RT5033_REG_CHG_CTRL4,
+ RT5033_CHGCTRL4_MIVR_MASK, RT5033_CHARGER_MIVR_DISABLE);
+ if (ret) {
+ dev_err(charger->dev, "Failed to disable MIVR.\n");
+ return -EINVAL;
+ }
+
+ ret = rt5033_init_pre_charge(charger);
+ if (ret)
+ return ret;
+
+ ret = rt5033_init_fast_charge(charger);
+ if (ret)
+ return ret;
+
+ ret = rt5033_init_const_charge(charger);
+ if (ret)
+ return ret;
+
+ return 0;
+}
+
+static enum power_supply_property rt5033_charger_props[] = {
+ POWER_SUPPLY_PROP_STATUS,
+ POWER_SUPPLY_PROP_CHARGE_TYPE,
+ POWER_SUPPLY_PROP_CURRENT_MAX,
+ POWER_SUPPLY_PROP_CONSTANT_CHARGE_VOLTAGE,
+ POWER_SUPPLY_PROP_MODEL_NAME,
+ POWER_SUPPLY_PROP_MANUFACTURER,
+ POWER_SUPPLY_PROP_ONLINE,
+};
+
+static int rt5033_charger_get_property(struct power_supply *psy,
+ enum power_supply_property psp,
+ union power_supply_propval *val)
+{
+ struct rt5033_charger *charger = power_supply_get_drvdata(psy);
+ int ret = 0;
+
+ switch (psp) {
+ case POWER_SUPPLY_PROP_STATUS:
+ val->intval = rt5033_get_charger_state(charger);
+ break;
+ case POWER_SUPPLY_PROP_CHARGE_TYPE:
+ val->intval = rt5033_get_charger_type(charger);
+ break;
+ case POWER_SUPPLY_PROP_CURRENT_MAX:
+ val->intval = rt5033_get_charger_current_limit(charger);
+ break;
+ case POWER_SUPPLY_PROP_CONSTANT_CHARGE_VOLTAGE:
+ val->intval = rt5033_get_charger_const_voltage(charger);
+ break;
+ case POWER_SUPPLY_PROP_MODEL_NAME:
+ val->strval = RT5033_CHARGER_MODEL;
+ break;
+ case POWER_SUPPLY_PROP_MANUFACTURER:
+ val->strval = RT5033_MANUFACTURER;
+ break;
+ case POWER_SUPPLY_PROP_ONLINE:
+ val->intval = (rt5033_get_charger_state(charger) ==
+ POWER_SUPPLY_STATUS_CHARGING);
+ break;
+ default:
+ return -EINVAL;
+ }
+
+ return ret;
+}
+
+static struct rt5033_charger_data *rt5033_charger_dt_init(
+ struct platform_device *pdev)
+{
+ struct rt5033_charger_data *chg;
+ struct device_node *np = pdev->dev.of_node;
+ int ret;
+
+ if (!np) {
+ dev_err(&pdev->dev, "No charger of_node\n");
+ return ERR_PTR(-EINVAL);
+ }
+
+ chg = devm_kzalloc(&pdev->dev, sizeof(*chg), GFP_KERNEL);
+ if (!chg)
+ return ERR_PTR(-ENOMEM);
+
+ ret = of_property_read_u32(np, "richtek,pre-uamp", &chg->pre_uamp);
+ if (ret)
+ return ERR_PTR(ret);
+
+ ret = of_property_read_u32(np, "richtek,pre-threshold-uvolt",
+ &chg->pre_uvolt);
+ if (ret)
+ return ERR_PTR(ret);
+
+ ret = of_property_read_u32(np, "richtek,fast-uamp", &chg->fast_uamp);
+ if (ret)
+ return ERR_PTR(ret);
+
+ ret = of_property_read_u32(np, "richtek,const-uvolt",
+ &chg->const_uvolt);
+ if (ret)
+ return ERR_PTR(ret);
+
+ ret = of_property_read_u32(np, "richtek,eoc-uamp", &chg->eoc_uamp);
+ if (ret)
+ return ERR_PTR(ret);
+
+ return chg;
+}
+
+static const struct power_supply_desc rt5033_charger_desc = {
+ .name = "rt5033-charger",
+ .type = POWER_SUPPLY_TYPE_USB,
+ .properties = rt5033_charger_props,
+ .num_properties = ARRAY_SIZE(rt5033_charger_props),
+ .get_property = rt5033_charger_get_property,
+};
+
+static int rt5033_charger_probe(struct platform_device *pdev)
+{
+ struct rt5033_charger *charger;
+ struct rt5033_dev *rt5033 = dev_get_drvdata(pdev->dev.parent);
+ struct power_supply_config psy_cfg = {};
+ int ret;
+
+ charger = devm_kzalloc(&pdev->dev, sizeof(*charger), GFP_KERNEL);
+ if (!charger)
+ return -ENOMEM;
+
+ platform_set_drvdata(pdev, charger);
+ charger->dev = &pdev->dev;
+ charger->rt5033 = rt5033;
+
+ charger->chg = rt5033_charger_dt_init(pdev);
+ if (IS_ERR_OR_NULL(charger->chg))
+ return -ENODEV;
+
+ ret = rt5033_charger_reg_init(charger);
+ if (ret)
+ return ret;
+
+ psy_cfg.of_node = pdev->dev.of_node;
+ psy_cfg.drv_data = charger;
+
+ charger->psy = devm_power_supply_register(&pdev->dev,
+ &rt5033_charger_desc,
+ &psy_cfg);
+ if (IS_ERR(charger->psy)) {
+ dev_err(&pdev->dev, "failed: power supply register\n");
+ return PTR_ERR(charger->psy);
+ }
+
+ return 0;
+}
+
+static const struct platform_device_id rt5033_charger_id[] = {
+ { "rt5033-charger", },
+ { }
+};
+MODULE_DEVICE_TABLE(platform, rt5033_charger_id);
+
+static const struct of_device_id rt5033_charger_of_match[] = {
+ { .compatible = "richtek,rt5033-charger", },
+ { }
+};
+MODULE_DEVICE_TABLE(of, rt5033_charger_of_match);
+
+static struct platform_driver rt5033_charger_driver = {
+ .driver = {
+ .name = "rt5033-charger",
+ .of_match_table = rt5033_charger_of_match,
+ },
+ .probe = rt5033_charger_probe,
+ .id_table = rt5033_charger_id,
+};
+module_platform_driver(rt5033_charger_driver);
+
+MODULE_DESCRIPTION("Richtek RT5033 charger driver");
+MODULE_AUTHOR("Beomho Seo <beomho.seo@samsung.com>");
+MODULE_LICENSE("GPL v2");
--
2.39.1
^ permalink raw reply related [flat|nested] 30+ messages in thread* [PATCH 07/10] power: supply: rt5033_charger: Add cable detection and USB OTG supply
2023-02-28 22:32 ` [PATCH 00/10] Add RT5033 charger device driver Jakob Hauser
` (5 preceding siblings ...)
2023-02-28 22:32 ` [PATCH 06/10] power: supply: rt5033_charger: Add RT5033 charger device driver Jakob Hauser
@ 2023-02-28 22:32 ` Jakob Hauser
2023-02-28 22:32 ` [PATCH 08/10] power: supply: rt5033_charger: Make use of high impedance mode Jakob Hauser
` (3 subsequent siblings)
10 siblings, 0 replies; 30+ messages in thread
From: Jakob Hauser @ 2023-02-28 22:32 UTC (permalink / raw)
To: Sebastian Reichel, Lee Jones, Liam Girdwood, Mark Brown,
Rob Herring, Krzysztof Kozlowski
Cc: Beomho Seo, Chanwoo Choi, Stephan Gerhold, Raymond Hackley,
linux-pm, devicetree, linux-kernel, ~postmarketos/upstreaming,
Jakob Hauser
Implement cable detection by extcon and handle the driver according to the
connector type.
There are basically three types of action: "set_charging", "set_otg" and
"set_disconnect".
A forth helper function to "unset_otg" was added because this is used in both
"set_charging" and "set_disconnect". In the first case it covers the rather
rare event that someone changes from OTG to charging without disconnect. In
the second case, when disconnecting, the values are set back to the ones from
initialization to return into a defined state.
Additionally, there is "set_mivr". When connecting to e.g. a laptop/PC, the
minimum input voltage regulation (MIVR) shall prevent a voltage drop if the
cable or the supply is weak. The MIVR value is set to 4600MV, same as in the
Android driver [1]. When disconnecting, MIVR is set back to DISABLED.
In the function rt5033_get_charger_state(): When in OTG mode, the chip
reports status "charging". Change this to "discharging" because there is
no charging going on in OTG mode [2].
[1] https://github.com/msm8916-mainline/linux-downstream/blob/GT-I9195I/drivers/battery/rt5033_charger.c#L499
[2] https://github.com/msm8916-mainline/linux-downstream/blob/GT-I9195I/drivers/battery/rt5033_charger.c#L686-L687
Tested-by: Raymond Hackley <raymondhackley@protonmail.com>
Signed-off-by: Jakob Hauser <jahau@rocketmail.com>
---
drivers/power/supply/rt5033_charger.c | 265 +++++++++++++++++++++++++-
include/linux/mfd/rt5033.h | 8 +
2 files changed, 271 insertions(+), 2 deletions(-)
diff --git a/drivers/power/supply/rt5033_charger.c b/drivers/power/supply/rt5033_charger.c
index 6bb3d45a5e9e..79e7f75fe634 100644
--- a/drivers/power/supply/rt5033_charger.c
+++ b/drivers/power/supply/rt5033_charger.c
@@ -10,7 +10,10 @@
* published by the Free Software Foundation.
*/
+#include <linux/devm-helpers.h>
+#include <linux/extcon.h>
#include <linux/module.h>
+#include <linux/mutex.h>
#include <linux/platform_device.h>
#include <linux/power_supply.h>
#include <linux/mfd/rt5033-private.h>
@@ -44,6 +47,10 @@ static int rt5033_get_charger_state(struct rt5033_charger *charger)
state = POWER_SUPPLY_STATUS_UNKNOWN;
}
+ /* For OTG mode, RT5033 would still report "charging" */
+ if (charger->otg)
+ state = POWER_SUPPLY_STATUS_DISCHARGING;
+
return state;
}
@@ -132,6 +139,9 @@ static inline int rt5033_init_const_charge(struct rt5033_charger *charger)
return -EINVAL;
}
+ /* Store that value for later usage */
+ charger->cv_regval = reg_data;
+
/* Set end of charge current */
if (chg->eoc_uamp < RT5033_CHARGER_EOC_MIN ||
chg->eoc_uamp > RT5033_CHARGER_EOC_MAX)
@@ -303,6 +313,152 @@ static int rt5033_charger_reg_init(struct rt5033_charger *charger)
return 0;
}
+static int rt5033_charger_set_otg(struct rt5033_charger *charger)
+{
+ int ret;
+
+ mutex_lock(&charger->lock);
+
+ /* Set OTG boost v_out to 5 volts */
+ ret = regmap_update_bits(charger->rt5033->regmap, RT5033_REG_CHG_CTRL2,
+ RT5033_CHGCTRL2_CV_MASK,
+ 0x37 << RT5033_CHGCTRL2_CV_SHIFT);
+ if (ret) {
+ dev_err(charger->dev, "Failed set OTG boost v_out\n");
+ return -EINVAL;
+ }
+
+ /* Set operation mode to OTG */
+ ret = regmap_update_bits(charger->rt5033->regmap, RT5033_REG_CHG_CTRL1,
+ RT5033_CHGCTRL1_MODE_MASK, RT5033_BOOST_MODE);
+ if (ret) {
+ dev_err(charger->dev, "Failed to update OTG mode.\n");
+ return -EINVAL;
+ }
+
+ /* In case someone switched from charging to OTG directly */
+ if (charger->online)
+ charger->online = false;
+
+ charger->otg = true;
+
+ mutex_unlock(&charger->lock);
+
+ return 0;
+}
+
+static int rt5033_charger_unset_otg(struct rt5033_charger *charger)
+{
+ int ret;
+ u8 data;
+
+ /* Restore constant voltage for charging */
+ data = charger->cv_regval;
+ ret = regmap_update_bits(charger->rt5033->regmap, RT5033_REG_CHG_CTRL2,
+ RT5033_CHGCTRL2_CV_MASK,
+ data << RT5033_CHGCTRL2_CV_SHIFT);
+ if (ret) {
+ dev_err(charger->dev, "Failed to restore constant voltage\n");
+ return -EINVAL;
+ }
+
+ /* Set operation mode to charging */
+ ret = regmap_update_bits(charger->rt5033->regmap, RT5033_REG_CHG_CTRL1,
+ RT5033_CHGCTRL1_MODE_MASK, RT5033_CHARGER_MODE);
+ if (ret) {
+ dev_err(charger->dev, "Failed to update charger mode.\n");
+ return -EINVAL;
+ }
+
+ charger->otg = false;
+
+ return 0;
+}
+
+static int rt5033_charger_set_charging(struct rt5033_charger *charger)
+{
+ int ret;
+
+ mutex_lock(&charger->lock);
+
+ /* In case someone switched from OTG to charging directly */
+ if (charger->otg) {
+ ret = rt5033_charger_unset_otg(charger);
+ if (ret)
+ return -EINVAL;
+ }
+
+ charger->online = true;
+
+ mutex_unlock(&charger->lock);
+
+ return 0;
+}
+
+static int rt5033_charger_set_mivr(struct rt5033_charger *charger)
+{
+ int ret;
+
+ mutex_lock(&charger->lock);
+
+ /*
+ * When connected via USB connector type SDP (Standard Downstream Port),
+ * the minimum input voltage regulation (MIVR) should be enabled. It
+ * prevents an input voltage drop due to insufficient current provided
+ * by the adapter or USB input. As a downside, it may reduces the
+ * charging current and thus slows the charging.
+ */
+ ret = regmap_update_bits(charger->rt5033->regmap, RT5033_REG_CHG_CTRL4,
+ RT5033_CHGCTRL4_MIVR_MASK, RT5033_CHARGER_MIVR_4600MV);
+ if (ret) {
+ dev_err(charger->dev, "Failed to set MIVR level.\n");
+ return -EINVAL;
+ }
+
+ charger->mivr_enabled = true;
+
+ mutex_unlock(&charger->lock);
+
+ /* Beyond this, do the same steps like setting charging */
+ rt5033_charger_set_charging(charger);
+
+ return 0;
+}
+
+static int rt5033_charger_set_disconnect(struct rt5033_charger *charger)
+{
+ int ret;
+
+ mutex_lock(&charger->lock);
+
+ /* Disable MIVR if enabled */
+ if (charger->mivr_enabled) {
+ ret = regmap_update_bits(charger->rt5033->regmap,
+ RT5033_REG_CHG_CTRL4,
+ RT5033_CHGCTRL4_MIVR_MASK,
+ RT5033_CHARGER_MIVR_DISABLE);
+ if (ret) {
+ dev_err(charger->dev, "Failed to disable MIVR.\n");
+ return -EINVAL;
+ }
+
+ charger->mivr_enabled = false;
+ }
+
+ if (charger->otg) {
+ ret = rt5033_charger_unset_otg(charger);
+ if (ret)
+ return -EINVAL;
+ }
+
+ if (charger->online)
+ charger->online = false;
+
+ mutex_unlock(&charger->lock);
+
+ return 0;
+}
+
static enum power_supply_property rt5033_charger_props[] = {
POWER_SUPPLY_PROP_STATUS,
POWER_SUPPLY_PROP_CHARGE_TYPE,
@@ -340,8 +496,7 @@ static int rt5033_charger_get_property(struct power_supply *psy,
val->strval = RT5033_MANUFACTURER;
break;
case POWER_SUPPLY_PROP_ONLINE:
- val->intval = (rt5033_get_charger_state(charger) ==
- POWER_SUPPLY_STATUS_CHARGING);
+ val->intval = charger->online;
break;
default:
return -EINVAL;
@@ -391,6 +546,86 @@ static struct rt5033_charger_data *rt5033_charger_dt_init(
return chg;
}
+static void rt5033_charger_extcon_work(struct work_struct *work)
+{
+ struct rt5033_charger *charger =
+ container_of(work, struct rt5033_charger, extcon_work);
+ struct extcon_dev *edev = charger->edev;
+ int connector, state;
+ int ret;
+
+ for (connector = EXTCON_USB_HOST; connector <= EXTCON_CHG_USB_PD;
+ connector++) {
+ state = extcon_get_state(edev, connector);
+ if (state == 1)
+ break;
+ }
+
+ /*
+ * Adding a delay between extcon notification and extcon action. This
+ * makes extcon action execution more reliable. Without the delay the
+ * execution sometimes fails, possibly because the chip is busy or not
+ * ready.
+ */
+ msleep(100);
+
+ switch (connector) {
+ case EXTCON_CHG_USB_SDP:
+ ret = rt5033_charger_set_mivr(charger);
+ if (ret) {
+ dev_err(charger->dev, "failed to set USB mode\n");
+ break;
+ }
+ dev_info(charger->dev, "USB mode. connector type: %d\n",
+ connector);
+ break;
+ case EXTCON_CHG_USB_DCP:
+ case EXTCON_CHG_USB_CDP:
+ case EXTCON_CHG_USB_ACA:
+ case EXTCON_CHG_USB_FAST:
+ case EXTCON_CHG_USB_SLOW:
+ case EXTCON_CHG_WPT:
+ case EXTCON_CHG_USB_PD:
+ ret = rt5033_charger_set_charging(charger);
+ if (ret) {
+ dev_err(charger->dev, "failed to set charging\n");
+ break;
+ }
+ dev_info(charger->dev, "charging. connector type: %d\n",
+ connector);
+ break;
+ case EXTCON_USB_HOST:
+ ret = rt5033_charger_set_otg(charger);
+ if (ret) {
+ dev_err(charger->dev, "failed to set OTG\n");
+ break;
+ }
+ dev_info(charger->dev, "OTG enabled\n");
+ break;
+ default:
+ ret = rt5033_charger_set_disconnect(charger);
+ if (ret) {
+ dev_err(charger->dev, "failed to set disconnect\n");
+ break;
+ }
+ dev_info(charger->dev, "disconnected\n");
+ break;
+ }
+
+ power_supply_changed(charger->psy);
+}
+
+static int rt5033_charger_extcon_notifier(struct notifier_block *nb,
+ unsigned long event, void *param)
+{
+ struct rt5033_charger *charger =
+ container_of(nb, struct rt5033_charger, extcon_nb);
+
+ schedule_work(&charger->extcon_work);
+
+ return NOTIFY_OK;
+}
+
static const struct power_supply_desc rt5033_charger_desc = {
.name = "rt5033-charger",
.type = POWER_SUPPLY_TYPE_USB,
@@ -413,6 +648,7 @@ static int rt5033_charger_probe(struct platform_device *pdev)
platform_set_drvdata(pdev, charger);
charger->dev = &pdev->dev;
charger->rt5033 = rt5033;
+ mutex_init(&charger->lock);
charger->chg = rt5033_charger_dt_init(pdev);
if (IS_ERR_OR_NULL(charger->chg))
@@ -433,6 +669,31 @@ static int rt5033_charger_probe(struct platform_device *pdev)
return PTR_ERR(charger->psy);
}
+ /*
+ * Extcon support is not vital for the charger to work. If no extcon
+ * is available, just emit a warning and leave the probe function.
+ */
+ charger->edev = extcon_get_edev_by_phandle(&pdev->dev, 0);
+ if (IS_ERR(charger->edev)) {
+ dev_warn(&pdev->dev, "no extcon phandle found in device-tree\n");
+ goto out;
+ }
+
+ ret = devm_work_autocancel(&pdev->dev, &charger->extcon_work,
+ rt5033_charger_extcon_work);
+ if (ret) {
+ dev_err(&pdev->dev, "failed to initialize extcon work\n");
+ return ret;
+ }
+
+ charger->extcon_nb.notifier_call = rt5033_charger_extcon_notifier;
+ ret = devm_extcon_register_notifier_all(&pdev->dev, charger->edev,
+ &charger->extcon_nb);
+ if (ret) {
+ dev_err(&pdev->dev, "failed to register extcon notifier\n");
+ return ret;
+ }
+out:
return 0;
}
diff --git a/include/linux/mfd/rt5033.h b/include/linux/mfd/rt5033.h
index e99e2ab0c1c1..d2c613764756 100644
--- a/include/linux/mfd/rt5033.h
+++ b/include/linux/mfd/rt5033.h
@@ -53,6 +53,14 @@ struct rt5033_charger {
struct rt5033_dev *rt5033;
struct power_supply *psy;
struct rt5033_charger_data *chg;
+ struct extcon_dev *edev;
+ struct notifier_block extcon_nb;
+ struct work_struct extcon_work;
+ struct mutex lock;
+ bool online;
+ bool otg;
+ bool mivr_enabled;
+ u8 cv_regval;
};
#endif /* __RT5033_H__ */
--
2.39.1
^ permalink raw reply related [flat|nested] 30+ messages in thread* [PATCH 08/10] power: supply: rt5033_charger: Make use of high impedance mode
2023-02-28 22:32 ` [PATCH 00/10] Add RT5033 charger device driver Jakob Hauser
` (6 preceding siblings ...)
2023-02-28 22:32 ` [PATCH 07/10] power: supply: rt5033_charger: Add cable detection and USB OTG supply Jakob Hauser
@ 2023-02-28 22:32 ` Jakob Hauser
2023-04-02 10:14 ` Jakob Hauser
2023-02-28 22:32 ` [PATCH 09/10] power: supply: rt5033_battery: Adopt status property from charger Jakob Hauser
` (2 subsequent siblings)
10 siblings, 1 reply; 30+ messages in thread
From: Jakob Hauser @ 2023-02-28 22:32 UTC (permalink / raw)
To: Sebastian Reichel, Lee Jones, Liam Girdwood, Mark Brown,
Rob Herring, Krzysztof Kozlowski
Cc: Beomho Seo, Chanwoo Choi, Stephan Gerhold, Raymond Hackley,
linux-pm, devicetree, linux-kernel, ~postmarketos/upstreaming,
Jakob Hauser
Enable high impedance mode to reduce power consumption. However, it needs to be
disabled in case of charging or OTG mode.
Tested-by: Raymond Hackley <raymondhackley@protonmail.com>
Signed-off-by: Jakob Hauser <jahau@rocketmail.com>
---
drivers/power/supply/rt5033_charger.c | 47 ++++++++++++++++++++++++++-
1 file changed, 46 insertions(+), 1 deletion(-)
diff --git a/drivers/power/supply/rt5033_charger.c b/drivers/power/supply/rt5033_charger.c
index 79e7f75fe634..ab406fc9fa19 100644
--- a/drivers/power/supply/rt5033_charger.c
+++ b/drivers/power/supply/rt5033_charger.c
@@ -298,6 +298,17 @@ static int rt5033_charger_reg_init(struct rt5033_charger *charger)
return -EINVAL;
}
+ /*
+ * Enable high impedance mode. It stops charging or boosting and
+ * operates at a low current sinking to reduce power consumption.
+ */
+ ret = regmap_update_bits(charger->rt5033->regmap, RT5033_REG_CHG_CTRL1,
+ RT5033_CHGCTRL1_HZ_MASK, RT5033_CHARGER_HZ_ENABLE);
+ if (ret) {
+ dev_err(charger->dev, "Failed to enable high impedance mode.\n");
+ return -EINVAL;
+ }
+
ret = rt5033_init_pre_charge(charger);
if (ret)
return ret;
@@ -319,6 +330,14 @@ static int rt5033_charger_set_otg(struct rt5033_charger *charger)
mutex_lock(&charger->lock);
+ /* Disable high impedance mode to allow OTG mode */
+ ret = regmap_update_bits(charger->rt5033->regmap, RT5033_REG_CHG_CTRL1,
+ RT5033_CHGCTRL1_HZ_MASK, RT5033_CHARGER_HZ_DISABLE);
+ if (ret) {
+ dev_err(charger->dev, "Failed to disable high impedance mode.\n");
+ return -EINVAL;
+ }
+
/* Set OTG boost v_out to 5 volts */
ret = regmap_update_bits(charger->rt5033->regmap, RT5033_REG_CHG_CTRL2,
RT5033_CHGCTRL2_CV_MASK,
@@ -381,6 +400,14 @@ static int rt5033_charger_set_charging(struct rt5033_charger *charger)
mutex_lock(&charger->lock);
+ /* Disable high impedance mode to allow charging mode */
+ ret = regmap_update_bits(charger->rt5033->regmap, RT5033_REG_CHG_CTRL1,
+ RT5033_CHGCTRL1_HZ_MASK, RT5033_CHARGER_HZ_DISABLE);
+ if (ret) {
+ dev_err(charger->dev, "Failed to disable high impedance mode.\n");
+ return -EINVAL;
+ }
+
/* In case someone switched from OTG to charging directly */
if (charger->otg) {
ret = rt5033_charger_unset_otg(charger);
@@ -431,6 +458,14 @@ static int rt5033_charger_set_disconnect(struct rt5033_charger *charger)
mutex_lock(&charger->lock);
+ /* Enable high impedance mode to reduce power consumption */
+ ret = regmap_update_bits(charger->rt5033->regmap, RT5033_REG_CHG_CTRL1,
+ RT5033_CHGCTRL1_HZ_MASK, RT5033_CHARGER_HZ_ENABLE);
+ if (ret) {
+ dev_err(charger->dev, "Failed to enable high impedance mode.\n");
+ return -EINVAL;
+ }
+
/* Disable MIVR if enabled */
if (charger->mivr_enabled) {
ret = regmap_update_bits(charger->rt5033->regmap,
@@ -671,11 +706,21 @@ static int rt5033_charger_probe(struct platform_device *pdev)
/*
* Extcon support is not vital for the charger to work. If no extcon
- * is available, just emit a warning and leave the probe function.
+ * is available, just emit a warning, disable high impedance mode and
+ * leave the probe function.
*/
charger->edev = extcon_get_edev_by_phandle(&pdev->dev, 0);
if (IS_ERR(charger->edev)) {
dev_warn(&pdev->dev, "no extcon phandle found in device-tree\n");
+ ret = regmap_update_bits(charger->rt5033->regmap,
+ RT5033_REG_CHG_CTRL1,
+ RT5033_CHGCTRL1_HZ_MASK,
+ RT5033_CHARGER_HZ_DISABLE);
+ if (ret) {
+ dev_err(&pdev->dev,
+ "Failed to disable high impedance mode.\n");
+ return -EINVAL;
+ }
goto out;
}
--
2.39.1
^ permalink raw reply related [flat|nested] 30+ messages in thread* Re: [PATCH 08/10] power: supply: rt5033_charger: Make use of high impedance mode
2023-02-28 22:32 ` [PATCH 08/10] power: supply: rt5033_charger: Make use of high impedance mode Jakob Hauser
@ 2023-04-02 10:14 ` Jakob Hauser
0 siblings, 0 replies; 30+ messages in thread
From: Jakob Hauser @ 2023-04-02 10:14 UTC (permalink / raw)
To: Sebastian Reichel
Cc: Lee Jones, Liam Girdwood, Mark Brown, Rob Herring,
Krzysztof Kozlowski, Beomho Seo, Chanwoo Choi, Stephan Gerhold,
Raymond Hackley, linux-pm, devicetree, linux-kernel,
~postmarketos/upstreaming
Hi Sebastian,
On 28.02.23 23:32, Jakob Hauser wrote:
> Enable high impedance mode to reduce power consumption. However, it needs to be
> disabled in case of charging or OTG mode.
>
> Tested-by: Raymond Hackley <raymondhackley@protonmail.com>
> Signed-off-by: Jakob Hauser <jahau@rocketmail.com>
> ---
> drivers/power/supply/rt5033_charger.c | 47 ++++++++++++++++++++++++++-
> 1 file changed, 46 insertions(+), 1 deletion(-)
...
Raymond (in copy) did some tests on the flash LEDs, which are also
managed by the rt5033 chip. There is no driver for leds-rt5033 yet but
Raymond got the rt5033 LEDs running via the similar driver leds-sgm3140.
However, to get the flash LEDs working, he had to disable the high
impedance mode of rt5033.
I implemented the use of high impedance mode by this patch to improve
power saving. It's kind of a sleep mode. Although it's not clear how
much power it does save, it's generally worth trying to improve power
saving on mobile devices as far as possible.
As it now turns out that the use of high impedance mode might complicate
the handling of the flash LEDs, I would drop this patch in the next
version v2 of the patchset. Let's skip this power saving attempt for
now. It still can be added at a later date as an improvement.
Kind regards,
Jakob
^ permalink raw reply [flat|nested] 30+ messages in thread
* [PATCH 09/10] power: supply: rt5033_battery: Adopt status property from charger
2023-02-28 22:32 ` [PATCH 00/10] Add RT5033 charger device driver Jakob Hauser
` (7 preceding siblings ...)
2023-02-28 22:32 ` [PATCH 08/10] power: supply: rt5033_charger: Make use of high impedance mode Jakob Hauser
@ 2023-02-28 22:32 ` Jakob Hauser
2023-02-28 22:32 ` [PATCH 10/10] dt-bindings: Add documentation for rt5033 mfd, regulator and charger Jakob Hauser
2023-03-25 16:08 ` [PATCH 00/10] Add RT5033 charger device driver Pavel Machek
10 siblings, 0 replies; 30+ messages in thread
From: Jakob Hauser @ 2023-02-28 22:32 UTC (permalink / raw)
To: Sebastian Reichel, Lee Jones, Liam Girdwood, Mark Brown,
Rob Herring, Krzysztof Kozlowski
Cc: Beomho Seo, Chanwoo Choi, Stephan Gerhold, Raymond Hackley,
linux-pm, devicetree, linux-kernel, ~postmarketos/upstreaming,
Jakob Hauser
The rt5033-battery fuelgauge can't get a status by itself. The rt5033-charger
can, let's get this value.
Tested-by: Raymond Hackley <raymondhackley@protonmail.com>
Signed-off-by: Jakob Hauser <jahau@rocketmail.com>
---
drivers/power/supply/rt5033_battery.c | 24 ++++++++++++++++++++++++
1 file changed, 24 insertions(+)
diff --git a/drivers/power/supply/rt5033_battery.c b/drivers/power/supply/rt5033_battery.c
index 5c04cf305219..48d4cccce4f6 100644
--- a/drivers/power/supply/rt5033_battery.c
+++ b/drivers/power/supply/rt5033_battery.c
@@ -12,6 +12,26 @@
#include <linux/mfd/rt5033-private.h>
#include <linux/mfd/rt5033.h>
+static int rt5033_battery_get_status(struct i2c_client *client)
+{
+ struct power_supply *charger;
+ union power_supply_propval val;
+ int ret;
+
+ charger = power_supply_get_by_name("rt5033-charger");
+ if (!charger)
+ return -ENODEV;
+
+ ret = power_supply_get_property(charger, POWER_SUPPLY_PROP_STATUS, &val);
+ if (ret) {
+ power_supply_put(charger);
+ return POWER_SUPPLY_STATUS_UNKNOWN;
+ }
+
+ power_supply_put(charger);
+ return val.intval;
+}
+
static int rt5033_battery_get_capacity(struct i2c_client *client)
{
struct rt5033_battery *battery = i2c_get_clientdata(client);
@@ -84,6 +104,9 @@ static int rt5033_battery_get_property(struct power_supply *psy,
case POWER_SUPPLY_PROP_CAPACITY:
val->intval = rt5033_battery_get_capacity(battery->client);
break;
+ case POWER_SUPPLY_PROP_STATUS:
+ val->intval = rt5033_battery_get_status(battery->client);
+ break;
default:
return -EINVAL;
}
@@ -96,6 +119,7 @@ static enum power_supply_property rt5033_battery_props[] = {
POWER_SUPPLY_PROP_VOLTAGE_OCV,
POWER_SUPPLY_PROP_PRESENT,
POWER_SUPPLY_PROP_CAPACITY,
+ POWER_SUPPLY_PROP_STATUS,
};
static const struct regmap_config rt5033_battery_regmap_config = {
--
2.39.1
^ permalink raw reply related [flat|nested] 30+ messages in thread* [PATCH 10/10] dt-bindings: Add documentation for rt5033 mfd, regulator and charger
2023-02-28 22:32 ` [PATCH 00/10] Add RT5033 charger device driver Jakob Hauser
` (8 preceding siblings ...)
2023-02-28 22:32 ` [PATCH 09/10] power: supply: rt5033_battery: Adopt status property from charger Jakob Hauser
@ 2023-02-28 22:32 ` Jakob Hauser
2023-02-28 23:15 ` Rob Herring
2023-03-01 2:35 ` Rob Herring
2023-03-25 16:08 ` [PATCH 00/10] Add RT5033 charger device driver Pavel Machek
10 siblings, 2 replies; 30+ messages in thread
From: Jakob Hauser @ 2023-02-28 22:32 UTC (permalink / raw)
To: Sebastian Reichel, Lee Jones, Liam Girdwood, Mark Brown,
Rob Herring, Krzysztof Kozlowski
Cc: Beomho Seo, Chanwoo Choi, Stephan Gerhold, Raymond Hackley,
linux-pm, devicetree, linux-kernel, ~postmarketos/upstreaming,
Jakob Hauser
Add device tree binding documentation for rt5033 multifunction device, voltage
regulator and battery charger.
Cc: Beomho Seo <beomho.seo@samsung.com>
Cc: Chanwoo Choi <cw00.choi@samsung.com>
Signed-off-by: Jakob Hauser <jahau@rocketmail.com>
---
.../bindings/mfd/richtek,rt5033.yaml | 102 ++++++++++++++++++
.../power/supply/richtek,rt5033-charger.yaml | 76 +++++++++++++
.../regulator/richtek,rt5033-regulator.yaml | 45 ++++++++
3 files changed, 223 insertions(+)
create mode 100644 Documentation/devicetree/bindings/mfd/richtek,rt5033.yaml
create mode 100644 Documentation/devicetree/bindings/power/supply/richtek,rt5033-charger.yaml
create mode 100644 Documentation/devicetree/bindings/regulator/richtek,rt5033-regulator.yaml
diff --git a/Documentation/devicetree/bindings/mfd/richtek,rt5033.yaml b/Documentation/devicetree/bindings/mfd/richtek,rt5033.yaml
new file mode 100644
index 000000000000..f1a58694c81e
--- /dev/null
+++ b/Documentation/devicetree/bindings/mfd/richtek,rt5033.yaml
@@ -0,0 +1,102 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/mfd/richtek,rt5033.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Richtek RT5033 Power Management Integrated Circuit
+
+maintainers:
+ - Jakob Hauser <jahau@rocketmail.com>
+
+description: |
+ RT5033 is a multifunction device which includes battery charger, fuel gauge,
+ flash LED current source, LDO and synchronous Buck converter for portable
+ applications. It is interfaced to host controller using I2C interface. The
+ battery fuel gauge uses a separate I2C bus.
+
+properties:
+ compatible:
+ const: richtek,rt5033
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ regulators:
+ type: object
+ $ref: /schemas/regulator/richtek,rt5033-regulator.yaml#
+
+ charger:
+ type: object
+ $ref: /schemas/power/supply/richtek,rt5033-charger.yaml#
+
+required:
+ - compatible
+ - reg
+ - interrupts
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/irq.h>
+
+ i2c@0 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ pmic@34 {
+ compatible = "richtek,rt5033";
+ reg = <0x34>;
+
+ interrupt-parent = <&msmgpio>;
+ interrupts = <62 IRQ_TYPE_EDGE_FALLING>;
+
+ pinctrl-names = "default";
+ pinctrl-0 = <&pmic_int_default>;
+
+ regulators {
+ safe_ldo_reg: SAFE_LDO {
+ regulator-name = "SAFE_LDO";
+ regulator-min-microvolt = <4900000>;
+ regulator-max-microvolt = <4900000>;
+ regulator-always-on;
+ };
+ ldo_reg: LDO {
+ regulator-name = "LDO";
+ regulator-min-microvolt = <2800000>;
+ regulator-max-microvolt = <2800000>;
+ };
+ buck_reg: BUCK {
+ regulator-name = "BUCK";
+ regulator-min-microvolt = <1200000>;
+ regulator-max-microvolt = <1200000>;
+ };
+ };
+
+ charger {
+ compatible = "richtek,rt5033-charger";
+ richtek,pre-uamp = <450000>;
+ richtek,fast-uamp = <1000000>;
+ richtek,eoc-uamp = <150000>;
+ richtek,pre-threshold-uvolt = <3500000>;
+ richtek,const-uvolt = <4350000>;
+ extcon = <&muic>;
+ };
+ };
+ };
+
+ i2c@1 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ battery@35 {
+ compatible = "richtek,rt5033-battery";
+ reg = <0x35>;
+ interrupt-parent = <&msmgpio>;
+ interrupts = <121 IRQ_TYPE_EDGE_FALLING>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/power/supply/richtek,rt5033-charger.yaml b/Documentation/devicetree/bindings/power/supply/richtek,rt5033-charger.yaml
new file mode 100644
index 000000000000..996c2932927d
--- /dev/null
+++ b/Documentation/devicetree/bindings/power/supply/richtek,rt5033-charger.yaml
@@ -0,0 +1,76 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/power/supply/richtek,rt5033-charger.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Richtek RT5033 PIMC Battery Charger
+
+maintainers:
+ - Jakob Hauser <jahau@rocketmail.com>
+
+description: |
+ The battery charger of the multifunction device RT5033 has to be instantiated
+ under sub-node named "charger" using the following format.
+
+properties:
+ compatible:
+ const: richtek,rt5033-charger
+
+ richtek,pre-uamp:
+ description: |
+ Current of pre-charge mode. The pre-charge current levels are 350 mA to
+ 650 mA programmed by I2C per 100 mA.
+ maxItems: 1
+
+ richtek,fast-uamp:
+ description: |
+ Current of fast-charge mode. The fast-charge current levels are 700 mA
+ to 2000 mA programmed by I2C per 100 mA.
+ maxItems: 1
+
+ richtek,eoc-uamp:
+ description: |
+ This property is end of charge current. Its level ranges from 150 mA to
+ 600 mA. Between 150 mA and 300 mA in 50 mA steps, between 300 mA and 600 mA
+ in 100 mA steps.
+ maxItems: 1
+
+ richtek,pre-threshold-uvolt:
+ description: |
+ Voltage of pre-charge mode. If the battery voltage is below the pre-charge
+ threshold voltage, the charger is in pre-charge mode with pre-charge current.
+ Its levels are 2.3 V to 3.8 V programmed by I2C per 0.1 V.
+ maxItems: 1
+
+ richtek,const-uvolt:
+ description: |
+ Battery regulation voltage of constant voltage mode. This voltage levels from
+ 3.65 V to 4.4 V by I2C per 0.025 V.
+ maxItems: 1
+
+ extcon:
+ description: |
+ Phandle to the extcon device.
+ maxItems: 1
+
+required:
+ - richtek,pre-uamp
+ - richtek,fast-uamp
+ - richtek,eoc-uamp
+ - richtek,pre-threshold-uvolt
+ - richtek,const-uvolt
+
+additionalProperties: false
+
+examples:
+ - |
+ charger {
+ compatible = "richtek,rt5033-charger";
+ richtek,pre-uamp = <450000>;
+ richtek,fast-uamp = <1000000>;
+ richtek,eoc-uamp = <150000>;
+ richtek,pre-threshold-uvolt = <3500000>;
+ richtek,const-uvolt = <4350000>;
+ extcon = <&muic>;
+ };
diff --git a/Documentation/devicetree/bindings/regulator/richtek,rt5033-regulator.yaml b/Documentation/devicetree/bindings/regulator/richtek,rt5033-regulator.yaml
new file mode 100644
index 000000000000..61b074488db4
--- /dev/null
+++ b/Documentation/devicetree/bindings/regulator/richtek,rt5033-regulator.yaml
@@ -0,0 +1,45 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/regulator/richtek,rt5033-regulator.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Richtek RT5033 PIMC Voltage Regulator
+
+maintainers:
+ - Jakob Hauser <jahau@rocketmail.com>
+
+description: |
+ The regulators of RT5033 have to be instantiated under a sub-node named
+ "regulators". For SAFE_LDO voltage there is only one value of 4.9 V. LDO
+ voltage ranges from 1.2 V to 3.0 V in 0.1 V steps. BUCK voltage ranges from
+ 1.0 V to 3.0 V in 0.1 V steps.
+
+patternProperties:
+ "^(SAFE_LDO|LDO|BUCK)$":
+ type: object
+ $ref: /schemas/regulator/regulator.yaml#
+ unevaluatedProperties: false
+
+additionalProperties: false
+
+examples:
+ - |
+ regulators {
+ safe_ldo_reg: SAFE_LDO {
+ regulator-name = "SAFE_LDO";
+ regulator-min-microvolt = <4900000>;
+ regulator-max-microvolt = <4900000>;
+ regulator-always-on;
+ };
+ ldo_reg: LDO {
+ regulator-name = "LDO";
+ regulator-min-microvolt = <2800000>;
+ regulator-max-microvolt = <2800000>;
+ };
+ buck_reg: BUCK {
+ regulator-name = "BUCK";
+ regulator-min-microvolt = <1200000>;
+ regulator-max-microvolt = <1200000>;
+ };
+ };
--
2.39.1
^ permalink raw reply related [flat|nested] 30+ messages in thread* Re: [PATCH 10/10] dt-bindings: Add documentation for rt5033 mfd, regulator and charger
2023-02-28 22:32 ` [PATCH 10/10] dt-bindings: Add documentation for rt5033 mfd, regulator and charger Jakob Hauser
@ 2023-02-28 23:15 ` Rob Herring
2023-03-01 2:35 ` Rob Herring
1 sibling, 0 replies; 30+ messages in thread
From: Rob Herring @ 2023-02-28 23:15 UTC (permalink / raw)
To: Jakob Hauser
Cc: Krzysztof Kozlowski, Liam Girdwood, Raymond Hackley, linux-pm,
linux-kernel, Lee Jones, Rob Herring, Beomho Seo,
~postmarketos/upstreaming, devicetree, Mark Brown,
Sebastian Reichel, Chanwoo Choi, Stephan Gerhold
On Tue, 28 Feb 2023 23:32:27 +0100, Jakob Hauser wrote:
> Add device tree binding documentation for rt5033 multifunction device, voltage
> regulator and battery charger.
>
> Cc: Beomho Seo <beomho.seo@samsung.com>
> Cc: Chanwoo Choi <cw00.choi@samsung.com>
> Signed-off-by: Jakob Hauser <jahau@rocketmail.com>
> ---
> .../bindings/mfd/richtek,rt5033.yaml | 102 ++++++++++++++++++
> .../power/supply/richtek,rt5033-charger.yaml | 76 +++++++++++++
> .../regulator/richtek,rt5033-regulator.yaml | 45 ++++++++
> 3 files changed, 223 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/mfd/richtek,rt5033.yaml
> create mode 100644 Documentation/devicetree/bindings/power/supply/richtek,rt5033-charger.yaml
> create mode 100644 Documentation/devicetree/bindings/regulator/richtek,rt5033-regulator.yaml
>
My bot found errors running 'make DT_CHECKER_FLAGS=-m dt_binding_check'
on your patch (DT_CHECKER_FLAGS is new in v5.13):
yamllint warnings/errors:
dtschema/dtc warnings/errors:
./Documentation/devicetree/bindings/mfd/richtek,rt5033.yaml: Error in referenced schema matching $id: http://devicetree.org/schemas/power/supply/richtek,rt5033-charger.yaml
/builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/power/supply/richtek,rt5033-charger.yaml: properties:richtek,pre-threshold-uvolt: 'oneOf' conditional failed, one must be fixed:
'type' is a required property
hint: A vendor boolean property can use "type: boolean"
Additional properties are not allowed ('maxItems' was unexpected)
hint: A vendor boolean property can use "type: boolean"
/builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/power/supply/richtek,rt5033-charger.yaml: properties:richtek,pre-threshold-uvolt: 'oneOf' conditional failed, one must be fixed:
'enum' is a required property
'const' is a required property
hint: A vendor string property with exact values has an implicit type
from schema $id: http://devicetree.org/meta-schemas/vendor-props.yaml#
/builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/power/supply/richtek,rt5033-charger.yaml: properties:richtek,pre-threshold-uvolt: 'oneOf' conditional failed, one must be fixed:
'$ref' is a required property
'allOf' is a required property
hint: A vendor property needs a $ref to types.yaml
from schema $id: http://devicetree.org/meta-schemas/vendor-props.yaml#
hint: Vendor specific properties must have a type and description unless they have a defined, common suffix.
from schema $id: http://devicetree.org/meta-schemas/vendor-props.yaml#
/builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/power/supply/richtek,rt5033-charger.yaml: properties:richtek,const-uvolt: 'oneOf' conditional failed, one must be fixed:
'type' is a required property
hint: A vendor boolean property can use "type: boolean"
Additional properties are not allowed ('maxItems' was unexpected)
hint: A vendor boolean property can use "type: boolean"
/builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/power/supply/richtek,rt5033-charger.yaml: properties:richtek,const-uvolt: 'oneOf' conditional failed, one must be fixed:
'enum' is a required property
'const' is a required property
hint: A vendor string property with exact values has an implicit type
from schema $id: http://devicetree.org/meta-schemas/vendor-props.yaml#
/builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/power/supply/richtek,rt5033-charger.yaml: properties:richtek,const-uvolt: 'oneOf' conditional failed, one must be fixed:
'$ref' is a required property
'allOf' is a required property
hint: A vendor property needs a $ref to types.yaml
from schema $id: http://devicetree.org/meta-schemas/vendor-props.yaml#
hint: Vendor specific properties must have a type and description unless they have a defined, common suffix.
from schema $id: http://devicetree.org/meta-schemas/vendor-props.yaml#
/builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/power/supply/richtek,rt5033-charger.yaml: properties:richtek,eoc-uamp: 'oneOf' conditional failed, one must be fixed:
'type' is a required property
hint: A vendor boolean property can use "type: boolean"
Additional properties are not allowed ('maxItems' was unexpected)
hint: A vendor boolean property can use "type: boolean"
/builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/power/supply/richtek,rt5033-charger.yaml: properties:richtek,eoc-uamp: 'oneOf' conditional failed, one must be fixed:
'enum' is a required property
'const' is a required property
hint: A vendor string property with exact values has an implicit type
from schema $id: http://devicetree.org/meta-schemas/vendor-props.yaml#
/builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/power/supply/richtek,rt5033-charger.yaml: properties:richtek,eoc-uamp: 'oneOf' conditional failed, one must be fixed:
'$ref' is a required property
'allOf' is a required property
hint: A vendor property needs a $ref to types.yaml
from schema $id: http://devicetree.org/meta-schemas/vendor-props.yaml#
hint: Vendor specific properties must have a type and description unless they have a defined, common suffix.
from schema $id: http://devicetree.org/meta-schemas/vendor-props.yaml#
/builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/power/supply/richtek,rt5033-charger.yaml: properties:richtek,fast-uamp: 'oneOf' conditional failed, one must be fixed:
'type' is a required property
hint: A vendor boolean property can use "type: boolean"
Additional properties are not allowed ('maxItems' was unexpected)
hint: A vendor boolean property can use "type: boolean"
/builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/power/supply/richtek,rt5033-charger.yaml: properties:richtek,fast-uamp: 'oneOf' conditional failed, one must be fixed:
'enum' is a required property
'const' is a required property
hint: A vendor string property with exact values has an implicit type
from schema $id: http://devicetree.org/meta-schemas/vendor-props.yaml#
/builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/power/supply/richtek,rt5033-charger.yaml: properties:richtek,fast-uamp: 'oneOf' conditional failed, one must be fixed:
'$ref' is a required property
'allOf' is a required property
hint: A vendor property needs a $ref to types.yaml
from schema $id: http://devicetree.org/meta-schemas/vendor-props.yaml#
hint: Vendor specific properties must have a type and description unless they have a defined, common suffix.
from schema $id: http://devicetree.org/meta-schemas/vendor-props.yaml#
/builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/power/supply/richtek,rt5033-charger.yaml: properties:richtek,pre-uamp: 'oneOf' conditional failed, one must be fixed:
'type' is a required property
hint: A vendor boolean property can use "type: boolean"
Additional properties are not allowed ('maxItems' was unexpected)
hint: A vendor boolean property can use "type: boolean"
/builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/power/supply/richtek,rt5033-charger.yaml: properties:richtek,pre-uamp: 'oneOf' conditional failed, one must be fixed:
'enum' is a required property
'const' is a required property
hint: A vendor string property with exact values has an implicit type
from schema $id: http://devicetree.org/meta-schemas/vendor-props.yaml#
/builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/power/supply/richtek,rt5033-charger.yaml: properties:richtek,pre-uamp: 'oneOf' conditional failed, one must be fixed:
'$ref' is a required property
'allOf' is a required property
hint: A vendor property needs a $ref to types.yaml
from schema $id: http://devicetree.org/meta-schemas/vendor-props.yaml#
hint: Vendor specific properties must have a type and description unless they have a defined, common suffix.
from schema $id: http://devicetree.org/meta-schemas/vendor-props.yaml#
Documentation/devicetree/bindings/mfd/richtek,rt5033.example.dts:23.15-66.11: Warning (unit_address_vs_reg): /example-0/i2c@0: node has a unit name, but no reg or ranges property
Documentation/devicetree/bindings/mfd/richtek,rt5033.example.dts:68.15-78.11: Warning (unit_address_vs_reg): /example-0/i2c@1: node has a unit name, but no reg or ranges property
doc reference errors (make refcheckdocs):
See https://patchwork.ozlabs.org/project/devicetree-bindings/patch/a698f524106e0eb7db5cbd7e73e77ecd5ac8ad7f.1677620677.git.jahau@rocketmail.com
The base for the series is generally the latest rc1. A different dependency
should be noted in *this* patch.
If you already ran 'make dt_binding_check' and didn't see the above
error(s), then make sure 'yamllint' is installed and dt-schema is up to
date:
pip3 install dtschema --upgrade
Please check and re-submit after running the above command yourself. Note
that DT_SCHEMA_FILES can be set to your schema file to speed up checking
your schema. However, it must be unset to test all examples with your schema.
^ permalink raw reply [flat|nested] 30+ messages in thread* Re: [PATCH 10/10] dt-bindings: Add documentation for rt5033 mfd, regulator and charger
2023-02-28 22:32 ` [PATCH 10/10] dt-bindings: Add documentation for rt5033 mfd, regulator and charger Jakob Hauser
2023-02-28 23:15 ` Rob Herring
@ 2023-03-01 2:35 ` Rob Herring
2023-03-05 15:54 ` Jakob Hauser
1 sibling, 1 reply; 30+ messages in thread
From: Rob Herring @ 2023-03-01 2:35 UTC (permalink / raw)
To: Jakob Hauser
Cc: Sebastian Reichel, Lee Jones, Liam Girdwood, Mark Brown,
Krzysztof Kozlowski, Beomho Seo, Chanwoo Choi, Stephan Gerhold,
Raymond Hackley, linux-pm, devicetree, linux-kernel,
~postmarketos/upstreaming
On Tue, Feb 28, 2023 at 11:32:27PM +0100, Jakob Hauser wrote:
> Add device tree binding documentation for rt5033 multifunction device, voltage
> regulator and battery charger.
>
> Cc: Beomho Seo <beomho.seo@samsung.com>
> Cc: Chanwoo Choi <cw00.choi@samsung.com>
> Signed-off-by: Jakob Hauser <jahau@rocketmail.com>
> ---
> .../bindings/mfd/richtek,rt5033.yaml | 102 ++++++++++++++++++
> .../power/supply/richtek,rt5033-charger.yaml | 76 +++++++++++++
> .../regulator/richtek,rt5033-regulator.yaml | 45 ++++++++
> 3 files changed, 223 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/mfd/richtek,rt5033.yaml
> create mode 100644 Documentation/devicetree/bindings/power/supply/richtek,rt5033-charger.yaml
> create mode 100644 Documentation/devicetree/bindings/regulator/richtek,rt5033-regulator.yaml
>
> diff --git a/Documentation/devicetree/bindings/mfd/richtek,rt5033.yaml b/Documentation/devicetree/bindings/mfd/richtek,rt5033.yaml
> new file mode 100644
> index 000000000000..f1a58694c81e
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/mfd/richtek,rt5033.yaml
> @@ -0,0 +1,102 @@
> +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/mfd/richtek,rt5033.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Richtek RT5033 Power Management Integrated Circuit
> +
> +maintainers:
> + - Jakob Hauser <jahau@rocketmail.com>
> +
> +description: |
Don't need '|' unless you care about line endings.
> + RT5033 is a multifunction device which includes battery charger, fuel gauge,
> + flash LED current source, LDO and synchronous Buck converter for portable
> + applications. It is interfaced to host controller using I2C interface. The
> + battery fuel gauge uses a separate I2C bus.
> +
> +properties:
> + compatible:
> + const: richtek,rt5033
> +
> + reg:
> + maxItems: 1
> +
> + interrupts:
> + maxItems: 1
> +
> + regulators:
> + type: object
> + $ref: /schemas/regulator/richtek,rt5033-regulator.yaml#
> +
> + charger:
> + type: object
> + $ref: /schemas/power/supply/richtek,rt5033-charger.yaml#
> +
> +required:
> + - compatible
> + - reg
> + - interrupts
> +
> +additionalProperties: false
> +
> +examples:
> + - |
> + #include <dt-bindings/interrupt-controller/irq.h>
> +
> + i2c@0 {
i2c {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + pmic@34 {
> + compatible = "richtek,rt5033";
> + reg = <0x34>;
> +
> + interrupt-parent = <&msmgpio>;
> + interrupts = <62 IRQ_TYPE_EDGE_FALLING>;
> +
> + pinctrl-names = "default";
> + pinctrl-0 = <&pmic_int_default>;
> +
> + regulators {
> + safe_ldo_reg: SAFE_LDO {
> + regulator-name = "SAFE_LDO";
> + regulator-min-microvolt = <4900000>;
> + regulator-max-microvolt = <4900000>;
> + regulator-always-on;
> + };
> + ldo_reg: LDO {
> + regulator-name = "LDO";
> + regulator-min-microvolt = <2800000>;
> + regulator-max-microvolt = <2800000>;
> + };
> + buck_reg: BUCK {
> + regulator-name = "BUCK";
> + regulator-min-microvolt = <1200000>;
> + regulator-max-microvolt = <1200000>;
> + };
> + };
> +
> + charger {
> + compatible = "richtek,rt5033-charger";
> + richtek,pre-uamp = <450000>;
> + richtek,fast-uamp = <1000000>;
> + richtek,eoc-uamp = <150000>;
> + richtek,pre-threshold-uvolt = <3500000>;
> + richtek,const-uvolt = <4350000>;
> + extcon = <&muic>;
> + };
> + };
> + };
> +
> + i2c@1 {
This should be a separate example entry.
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + battery@35 {
> + compatible = "richtek,rt5033-battery";
> + reg = <0x35>;
> + interrupt-parent = <&msmgpio>;
> + interrupts = <121 IRQ_TYPE_EDGE_FALLING>;
> + };
> + };
> diff --git a/Documentation/devicetree/bindings/power/supply/richtek,rt5033-charger.yaml b/Documentation/devicetree/bindings/power/supply/richtek,rt5033-charger.yaml
> new file mode 100644
> index 000000000000..996c2932927d
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/power/supply/richtek,rt5033-charger.yaml
> @@ -0,0 +1,76 @@
> +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/power/supply/richtek,rt5033-charger.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Richtek RT5033 PIMC Battery Charger
> +
> +maintainers:
> + - Jakob Hauser <jahau@rocketmail.com>
> +
> +description: |
> + The battery charger of the multifunction device RT5033 has to be instantiated
> + under sub-node named "charger" using the following format.
> +
> +properties:
> + compatible:
> + const: richtek,rt5033-charger
> +
> + richtek,pre-uamp:
Use defined standard unit type suffixes.
> + description: |
> + Current of pre-charge mode. The pre-charge current levels are 350 mA to
> + 650 mA programmed by I2C per 100 mA.
> + maxItems: 1
> +
> + richtek,fast-uamp:
> + description: |
> + Current of fast-charge mode. The fast-charge current levels are 700 mA
> + to 2000 mA programmed by I2C per 100 mA.
> + maxItems: 1
> +
> + richtek,eoc-uamp:
> + description: |
> + This property is end of charge current. Its level ranges from 150 mA to
> + 600 mA. Between 150 mA and 300 mA in 50 mA steps, between 300 mA and 600 mA
> + in 100 mA steps.
> + maxItems: 1
> +
> + richtek,pre-threshold-uvolt:
> + description: |
> + Voltage of pre-charge mode. If the battery voltage is below the pre-charge
> + threshold voltage, the charger is in pre-charge mode with pre-charge current.
> + Its levels are 2.3 V to 3.8 V programmed by I2C per 0.1 V.
> + maxItems: 1
> +
> + richtek,const-uvolt:
> + description: |
> + Battery regulation voltage of constant voltage mode. This voltage levels from
> + 3.65 V to 4.4 V by I2C per 0.025 V.
> + maxItems: 1
> +
> + extcon:
This is deprecated. There's standard connector bindings now.
> + description: |
> + Phandle to the extcon device.
> + maxItems: 1
> +
> +required:
> + - richtek,pre-uamp
> + - richtek,fast-uamp
> + - richtek,eoc-uamp
> + - richtek,pre-threshold-uvolt
> + - richtek,const-uvolt
> +
> +additionalProperties: false
> +
> +examples:
> + - |
> + charger {
> + compatible = "richtek,rt5033-charger";
> + richtek,pre-uamp = <450000>;
> + richtek,fast-uamp = <1000000>;
> + richtek,eoc-uamp = <150000>;
> + richtek,pre-threshold-uvolt = <3500000>;
> + richtek,const-uvolt = <4350000>;
> + extcon = <&muic>;
> + };
> diff --git a/Documentation/devicetree/bindings/regulator/richtek,rt5033-regulator.yaml b/Documentation/devicetree/bindings/regulator/richtek,rt5033-regulator.yaml
> new file mode 100644
> index 000000000000..61b074488db4
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/regulator/richtek,rt5033-regulator.yaml
> @@ -0,0 +1,45 @@
> +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/regulator/richtek,rt5033-regulator.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Richtek RT5033 PIMC Voltage Regulator
> +
> +maintainers:
> + - Jakob Hauser <jahau@rocketmail.com>
> +
> +description: |
> + The regulators of RT5033 have to be instantiated under a sub-node named
> + "regulators". For SAFE_LDO voltage there is only one value of 4.9 V. LDO
> + voltage ranges from 1.2 V to 3.0 V in 0.1 V steps. BUCK voltage ranges from
> + 1.0 V to 3.0 V in 0.1 V steps.
> +
> +patternProperties:
> + "^(SAFE_LDO|LDO|BUCK)$":
Lowercase preferred for node names.
> + type: object
> + $ref: /schemas/regulator/regulator.yaml#
> + unevaluatedProperties: false
> +
> +additionalProperties: false
> +
> +examples:
> + - |
> + regulators {
Just 1 complete example in the MFD binding please.
> + safe_ldo_reg: SAFE_LDO {
> + regulator-name = "SAFE_LDO";
> + regulator-min-microvolt = <4900000>;
> + regulator-max-microvolt = <4900000>;
> + regulator-always-on;
> + };
> + ldo_reg: LDO {
> + regulator-name = "LDO";
> + regulator-min-microvolt = <2800000>;
> + regulator-max-microvolt = <2800000>;
> + };
> + buck_reg: BUCK {
> + regulator-name = "BUCK";
> + regulator-min-microvolt = <1200000>;
> + regulator-max-microvolt = <1200000>;
> + };
> + };
> --
> 2.39.1
>
^ permalink raw reply [flat|nested] 30+ messages in thread* Re: [PATCH 10/10] dt-bindings: Add documentation for rt5033 mfd, regulator and charger
2023-03-01 2:35 ` Rob Herring
@ 2023-03-05 15:54 ` Jakob Hauser
2023-04-02 10:21 ` Jakob Hauser
0 siblings, 1 reply; 30+ messages in thread
From: Jakob Hauser @ 2023-03-05 15:54 UTC (permalink / raw)
To: Rob Herring
Cc: Sebastian Reichel, Lee Jones, Liam Girdwood, Mark Brown,
Krzysztof Kozlowski, Beomho Seo, Chanwoo Choi, Stephan Gerhold,
Raymond Hackley, linux-pm, devicetree, linux-kernel,
~postmarketos/upstreaming
Hi Rob,
thanks for the remarks and sorry for not running 'make
dt_binding_check'. I'm not familiar with devicetree bindings and
obviously missed to read the file
Documentation/devicetree/bindings/submitting-patches.rst.
On 01.03.23 03:35, Rob Herring wrote:
> On Tue, Feb 28, 2023 at 11:32:27PM +0100, Jakob Hauser wrote:
>> Add device tree binding documentation for rt5033 multifunction device, voltage
>> regulator and battery charger.
>>
>> Cc: Beomho Seo <beomho.seo@samsung.com>
>> Cc: Chanwoo Choi <cw00.choi@samsung.com>
>> Signed-off-by: Jakob Hauser <jahau@rocketmail.com>
>> ---
>> .../bindings/mfd/richtek,rt5033.yaml | 102 ++++++++++++++++++
>> .../power/supply/richtek,rt5033-charger.yaml | 76 +++++++++++++
>> .../regulator/richtek,rt5033-regulator.yaml | 45 ++++++++
>> 3 files changed, 223 insertions(+)
>> create mode 100644 Documentation/devicetree/bindings/mfd/richtek,rt5033.yaml
>> create mode 100644 Documentation/devicetree/bindings/power/supply/richtek,rt5033-charger.yaml
>> create mode 100644 Documentation/devicetree/bindings/regulator/richtek,rt5033-regulator.yaml
>>
>> diff --git a/Documentation/devicetree/bindings/mfd/richtek,rt5033.yaml b/Documentation/devicetree/bindings/mfd/richtek,rt5033.yaml
>> new file mode 100644
>> index 000000000000..f1a58694c81e
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/mfd/richtek,rt5033.yaml
>> @@ -0,0 +1,102 @@
>> +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
>> +%YAML 1.2
>> +---
>> +$id: http://devicetree.org/schemas/mfd/richtek,rt5033.yaml#
>> +$schema: http://devicetree.org/meta-schemas/core.yaml#
>> +
>> +title: Richtek RT5033 Power Management Integrated Circuit
>> +
>> +maintainers:
>> + - Jakob Hauser <jahau@rocketmail.com>
>> +
>> +description: |
>
> Don't need '|' unless you care about line endings.
OK
>> + RT5033 is a multifunction device which includes battery charger, fuel gauge,
>> + flash LED current source, LDO and synchronous Buck converter for portable
>> + applications. It is interfaced to host controller using I2C interface. The
>> + battery fuel gauge uses a separate I2C bus.
>> +
>> +properties:
>> + compatible:
>> + const: richtek,rt5033
>> +
>> + reg:
>> + maxItems: 1
>> +
>> + interrupts:
>> + maxItems: 1
>> +
>> + regulators:
>> + type: object
>> + $ref: /schemas/regulator/richtek,rt5033-regulator.yaml#
>> +
>> + charger:
>> + type: object
>> + $ref: /schemas/power/supply/richtek,rt5033-charger.yaml#
>> +
>> +required:
>> + - compatible
>> + - reg
>> + - interrupts
>> +
>> +additionalProperties: false
>> +
>> +examples:
>> + - |
>> + #include <dt-bindings/interrupt-controller/irq.h>
>> +
>> + i2c@0 {
>
> i2c {
OK
>> + #address-cells = <1>;
>> + #size-cells = <0>;
>> +
>> + pmic@34 {
>> + compatible = "richtek,rt5033";
>> + reg = <0x34>;
>> +
>> + interrupt-parent = <&msmgpio>;
>> + interrupts = <62 IRQ_TYPE_EDGE_FALLING>;
>> +
>> + pinctrl-names = "default";
>> + pinctrl-0 = <&pmic_int_default>;
>> +
>> + regulators {
>> + safe_ldo_reg: SAFE_LDO {
>> + regulator-name = "SAFE_LDO";
>> + regulator-min-microvolt = <4900000>;
>> + regulator-max-microvolt = <4900000>;
>> + regulator-always-on;
>> + };
>> + ldo_reg: LDO {
>> + regulator-name = "LDO";
>> + regulator-min-microvolt = <2800000>;
>> + regulator-max-microvolt = <2800000>;
>> + };
>> + buck_reg: BUCK {
>> + regulator-name = "BUCK";
>> + regulator-min-microvolt = <1200000>;
>> + regulator-max-microvolt = <1200000>;
>> + };
>> + };
>> +
>> + charger {
>> + compatible = "richtek,rt5033-charger";
>> + richtek,pre-uamp = <450000>;
>> + richtek,fast-uamp = <1000000>;
>> + richtek,eoc-uamp = <150000>;
>> + richtek,pre-threshold-uvolt = <3500000>;
>> + richtek,const-uvolt = <4350000>;
>> + extcon = <&muic>;
>> + };
>> + };
>> + };
>> +
>> + i2c@1 {
>
> This should be a separate example entry.
I'll skip it then.
The battery fuel gauge is not handled as a part of the MFD, it has a
separate I2C line. Accordingly, it has a separate documentation
including examples [1].
I had implemented into the MFD example to make clear this is separated.
But as it is not part of the MFD, I guess it shouldn't show up in the
MFD documentation.
In the description of the MFD there is the statement "The battery fuel
gauge uses a separate I2C bus." I hope this is clear enough, I'm not
sure if I should modify/extent that statement or add some kind of
reference to the battery fuel gauge after removing it from the example.
[1]
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/devicetree/bindings/power/supply/richtek,rt5033-battery.yaml?h=v6.2
>> + #address-cells = <1>;
>> + #size-cells = <0>;
>> +
>> + battery@35 {
>> + compatible = "richtek,rt5033-battery";
>> + reg = <0x35>;
>> + interrupt-parent = <&msmgpio>;
>> + interrupts = <121 IRQ_TYPE_EDGE_FALLING>;
>> + };
>> + };
>> diff --git a/Documentation/devicetree/bindings/power/supply/richtek,rt5033-charger.yaml b/Documentation/devicetree/bindings/power/supply/richtek,rt5033-charger.yaml
>> new file mode 100644
>> index 000000000000..996c2932927d
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/power/supply/richtek,rt5033-charger.yaml
>> @@ -0,0 +1,76 @@
>> +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
>> +%YAML 1.2
>> +---
>> +$id: http://devicetree.org/schemas/power/supply/richtek,rt5033-charger.yaml#
>> +$schema: http://devicetree.org/meta-schemas/core.yaml#
>> +
>> +title: Richtek RT5033 PIMC Battery Charger
>> +
>> +maintainers:
>> + - Jakob Hauser <jahau@rocketmail.com>
>> +
>> +description: |
>> + The battery charger of the multifunction device RT5033 has to be instantiated
>> + under sub-node named "charger" using the following format.
>> +
>> +properties:
>> + compatible:
>> + const: richtek,rt5033-charger
>> +
>> + richtek,pre-uamp:
>
> Use defined standard unit type suffixes.
That makes sense. I took the current names from the 2015 patchset and
wasn't aware of the standard suffixes.
Just for the record: Chaning the names will also impact patch 06 "power:
supply: rt5033_charger: Add RT5033 charger device driver", as the names
are parsed there.
>> + description: |
>> + Current of pre-charge mode. The pre-charge current levels are 350 mA to
>> + 650 mA programmed by I2C per 100 mA.
>> + maxItems: 1
>> +
>> + richtek,fast-uamp:
>> + description: |
>> + Current of fast-charge mode. The fast-charge current levels are 700 mA
>> + to 2000 mA programmed by I2C per 100 mA.
>> + maxItems: 1
>> +
>> + richtek,eoc-uamp:
>> + description: |
>> + This property is end of charge current. Its level ranges from 150 mA to
>> + 600 mA. Between 150 mA and 300 mA in 50 mA steps, between 300 mA and 600 mA
>> + in 100 mA steps.
>> + maxItems: 1
>> +
>> + richtek,pre-threshold-uvolt:
>> + description: |
>> + Voltage of pre-charge mode. If the battery voltage is below the pre-charge
>> + threshold voltage, the charger is in pre-charge mode with pre-charge current.
>> + Its levels are 2.3 V to 3.8 V programmed by I2C per 0.1 V.
>> + maxItems: 1
>> +
>> + richtek,const-uvolt:
>> + description: |
>> + Battery regulation voltage of constant voltage mode. This voltage levels from
>> + 3.65 V to 4.4 V by I2C per 0.025 V.
>> + maxItems: 1
>> +
>> + extcon:
>
> This is deprecated. There's standard connector bindings now.
How does this work? I couldn't find an example.
I found Documentation/devicetree/bindings/connector/usb-connector.yaml
[2] but I don't see how this would be applied here.
The extcon device entry in the samsung-serranove devicetree [3] looks like:
i2c-muic {
compatible = "i2c-gpio";
sda-gpios = <&msmgpio 105 (GPIO_ACTIVE_HIGH|GPIO_OPEN_DRAIN)>;
scl-gpios = <&msmgpio 106 (GPIO_ACTIVE_HIGH|GPIO_OPEN_DRAIN)>;
pinctrl-names = "default";
pinctrl-0 = <&muic_i2c_default>;
#address-cells = <1>;
#size-cells = <0>;
muic: extcon@14 {
compatible = "siliconmitus,sm5504-muic";
reg = <0x14>;
interrupt-parent = <&msmgpio>;
interrupts = <12 IRQ_TYPE_EDGE_FALLING>;
pinctrl-names = "default";
pinctrl-0 = <&muic_irq_default>;
};
};
[2]
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/devicetree/bindings/connector/usb-connector.yaml?h=v6.2
[3]
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/arm64/boot/dts/qcom/msm8916-samsung-serranove.dts?h=v6.2#n123
>> + description: |
>> + Phandle to the extcon device.
>> + maxItems: 1
>> +
>> +required:
>> + - richtek,pre-uamp
>> + - richtek,fast-uamp
>> + - richtek,eoc-uamp
>> + - richtek,pre-threshold-uvolt
>> + - richtek,const-uvolt
>> +
>> +additionalProperties: false
>> +
>> +examples:
>> + - |
>> + charger {
>> + compatible = "richtek,rt5033-charger";
>> + richtek,pre-uamp = <450000>;
>> + richtek,fast-uamp = <1000000>;
>> + richtek,eoc-uamp = <150000>;
>> + richtek,pre-threshold-uvolt = <3500000>;
>> + richtek,const-uvolt = <4350000>;
>> + extcon = <&muic>;
>> + };
>> diff --git a/Documentation/devicetree/bindings/regulator/richtek,rt5033-regulator.yaml b/Documentation/devicetree/bindings/regulator/richtek,rt5033-regulator.yaml
>> new file mode 100644
>> index 000000000000..61b074488db4
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/regulator/richtek,rt5033-regulator.yaml
>> @@ -0,0 +1,45 @@
>> +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
>> +%YAML 1.2
>> +---
>> +$id: http://devicetree.org/schemas/regulator/richtek,rt5033-regulator.yaml#
>> +$schema: http://devicetree.org/meta-schemas/core.yaml#
>> +
>> +title: Richtek RT5033 PIMC Voltage Regulator
>> +
>> +maintainers:
>> + - Jakob Hauser <jahau@rocketmail.com>
>> +
>> +description: |
>> + The regulators of RT5033 have to be instantiated under a sub-node named
>> + "regulators". For SAFE_LDO voltage there is only one value of 4.9 V. LDO
>> + voltage ranges from 1.2 V to 3.0 V in 0.1 V steps. BUCK voltage ranges from
>> + 1.0 V to 3.0 V in 0.1 V steps.
>> +
>> +patternProperties:
>> + "^(SAFE_LDO|LDO|BUCK)$":
>
> Lowercase preferred for node names.
OK, I can change to lowercase.
Though I have to change the already existing driver rt5033-regulator as
well then [4]. I'm not sure if this has an impact on already existing
implementations. Although within the upstream kernel I think there is no
usage of the rt5033-regulator driver yet.
[4]
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/regulator/rt5033-regulator.c?h=v6.2#n42
>> + type: object
>> + $ref: /schemas/regulator/regulator.yaml#
>> + unevaluatedProperties: false
>> +
>> +additionalProperties: false
>> +
>> +examples:
>> + - |
>> + regulators {
>
> Just 1 complete example in the MFD binding please.
OK, I'll skip the examples part here then.
>> + safe_ldo_reg: SAFE_LDO {
>> + regulator-name = "SAFE_LDO";
>> + regulator-min-microvolt = <4900000>;
>> + regulator-max-microvolt = <4900000>;
>> + regulator-always-on;
>> + };
>> + ldo_reg: LDO {
>> + regulator-name = "LDO";
>> + regulator-min-microvolt = <2800000>;
>> + regulator-max-microvolt = <2800000>;
>> + };
>> + buck_reg: BUCK {
>> + regulator-name = "BUCK";
>> + regulator-min-microvolt = <1200000>;
>> + regulator-max-microvolt = <1200000>;
>> + };
>> + };
>> --
>> 2.39.1
>>
I'll wait with implementing the changes as there will be likely further
comments on the other patches.
Kind regards,
Jakob
^ permalink raw reply [flat|nested] 30+ messages in thread* Re: [PATCH 10/10] dt-bindings: Add documentation for rt5033 mfd, regulator and charger
2023-03-05 15:54 ` Jakob Hauser
@ 2023-04-02 10:21 ` Jakob Hauser
0 siblings, 0 replies; 30+ messages in thread
From: Jakob Hauser @ 2023-04-02 10:21 UTC (permalink / raw)
To: Rob Herring
Cc: Sebastian Reichel, Lee Jones, Liam Girdwood, Mark Brown,
Krzysztof Kozlowski, Beomho Seo, Chanwoo Choi, Stephan Gerhold,
Raymond Hackley, linux-pm, devicetree, linux-kernel,
~postmarketos/upstreaming
Hi Rob,
On 05.03.23 16:54, Jakob Hauser wrote:
...
> On 01.03.23 03:35, Rob Herring wrote:
>> On Tue, Feb 28, 2023 at 11:32:27PM +0100, Jakob Hauser wrote:
...
>>> + richtek,pre-threshold-uvolt:
>>> + description: |
>>> + Voltage of pre-charge mode. If the battery voltage is below
>>> the pre-charge
>>> + threshold voltage, the charger is in pre-charge mode with
>>> pre-charge current.
>>> + Its levels are 2.3 V to 3.8 V programmed by I2C per 0.1 V.
>>> + maxItems: 1
>>> +
>>> + richtek,const-uvolt:
>>> + description: |
>>> + Battery regulation voltage of constant voltage mode. This
>>> voltage levels from
>>> + 3.65 V to 4.4 V by I2C per 0.025 V.
>>> + maxItems: 1
>>> +
>>> + extcon:
>>
>> This is deprecated. There's standard connector bindings now.
>
> How does this work? I couldn't find an example.
>
> I found Documentation/devicetree/bindings/connector/usb-connector.yaml
> [2] but I don't see how this would be applied here.
>
> The extcon device entry in the samsung-serranove devicetree [3] looks like:
>
> i2c-muic {
> compatible = "i2c-gpio";
> sda-gpios = <&msmgpio 105 (GPIO_ACTIVE_HIGH|GPIO_OPEN_DRAIN)>;
> scl-gpios = <&msmgpio 106 (GPIO_ACTIVE_HIGH|GPIO_OPEN_DRAIN)>;
>
> pinctrl-names = "default";
> pinctrl-0 = <&muic_i2c_default>;
>
> #address-cells = <1>;
> #size-cells = <0>;
>
> muic: extcon@14 {
> compatible = "siliconmitus,sm5504-muic";
> reg = <0x14>;
>
> interrupt-parent = <&msmgpio>;
> interrupts = <12 IRQ_TYPE_EDGE_FALLING>;
>
> pinctrl-names = "default";
> pinctrl-0 = <&muic_irq_default>;
> };
> };
>
> [2]
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/devicetree/bindings/connector/usb-connector.yaml?h=v6.2
> [3]
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/arm64/boot/dts/qcom/msm8916-samsung-serranove.dts?h=v6.2#n123
Could you add more information on what you mean by standard connector
bindings? It's not clear to me.
>>> + description: |
>>> + Phandle to the extcon device.
>>> + maxItems: 1
>>> +
>>> +required:
>>> + - richtek,pre-uamp
>>> + - richtek,fast-uamp
>>> + - richtek,eoc-uamp
>>> + - richtek,pre-threshold-uvolt
>>> + - richtek,const-uvolt
>>> +
>>> +additionalProperties: false
>>> +
>>> +examples:
>>> + - |
>>> + charger {
>>> + compatible = "richtek,rt5033-charger";
>>> + richtek,pre-uamp = <450000>;
>>> + richtek,fast-uamp = <1000000>;
>>> + richtek,eoc-uamp = <150000>;
>>> + richtek,pre-threshold-uvolt = <3500000>;
>>> + richtek,const-uvolt = <4350000>;
>>> + extcon = <&muic>;
>>> + };
...
Kind regards,
Jakob
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [PATCH 00/10] Add RT5033 charger device driver
2023-02-28 22:32 ` [PATCH 00/10] Add RT5033 charger device driver Jakob Hauser
` (9 preceding siblings ...)
2023-02-28 22:32 ` [PATCH 10/10] dt-bindings: Add documentation for rt5033 mfd, regulator and charger Jakob Hauser
@ 2023-03-25 16:08 ` Pavel Machek
2023-03-27 20:22 ` Jakob Hauser
10 siblings, 1 reply; 30+ messages in thread
From: Pavel Machek @ 2023-03-25 16:08 UTC (permalink / raw)
To: Jakob Hauser
Cc: Sebastian Reichel, Lee Jones, Liam Girdwood, Mark Brown,
Rob Herring, Krzysztof Kozlowski, Beomho Seo, Chanwoo Choi,
Stephan Gerhold, Raymond Hackley, linux-pm, devicetree,
linux-kernel, ~postmarketos/upstreaming
Hi!
> Some comments on the end-of-charge behavior. The rt5033 chip offers three
> options. In the Android driver, a forth option was implemented.
Hmm. I'm working on that on motorola-cpcap driver, and I guess this is going
to be common problem for many drivers.
> - By default, the rt5033 chip charges indefinitely. The current goes down but
> there is always a charge voltage to the battery, which might not be too good
> for the battery lifetime.
> - There is the possibility to enable a fast charge timer. The timer can be
> set to 4, 6, 8... 16 hours. After that time has elapsed, charging stops
> and the battery gets discharged. This option with a timer of 4 hours was
> chosen by Beomho Seo in the patchset of March 2015. However, that option
> is confusing to the user. It doesn't initiate a re-charge cycle. So when
> keeping plugged in the device over night, I find it discharging on the
> next morning.
> - The third option of the rt5033 chip is enabling charging termination. This
> also enables a re-charge cycle. When the charging current sinks below the
> end-of-charge current, the chip stops charging. The sysfs state changes to
> "not charging". When the voltage gets 0.1 V below the end-of-charge constant
> voltage, re-charging starts. Then again, when charging current sinks below
> the end-of-charge current, the chip stops charging. And so on, going up and
> down in re-charge cycles. In case the power consumption is high (e.g. tuning
> on the display of the mobile device), the current goes into an equilibrium.
> The downside of this charging termination option: When reaching the end-of-
> charge current, the capacity might not have reached 100 % yet. The capacity
> to reach probably depends on power consumption and battery wear. On my mobile
> device, capacity reaches 98 %, drops to 96 % until re-charging kicks in,
> climbs to 98 %, drops to 96 %, and so on. Not reaching 100 % is a bit
> confusing to the user, too.
Is the system powered from the battery in the not-charging case?
Anyway, we should teach userspace that "full battery" does not neccessary mean 100%,
as keeping battery at 4.3V wears it down quickly.
Best regards,
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
^ permalink raw reply [flat|nested] 30+ messages in thread* Re: [PATCH 00/10] Add RT5033 charger device driver
2023-03-25 16:08 ` [PATCH 00/10] Add RT5033 charger device driver Pavel Machek
@ 2023-03-27 20:22 ` Jakob Hauser
0 siblings, 0 replies; 30+ messages in thread
From: Jakob Hauser @ 2023-03-27 20:22 UTC (permalink / raw)
To: Pavel Machek
Cc: Sebastian Reichel, Lee Jones, Liam Girdwood, Mark Brown,
Rob Herring, Krzysztof Kozlowski, Beomho Seo, Chanwoo Choi,
Stephan Gerhold, Raymond Hackley, linux-pm, devicetree,
linux-kernel, ~postmarketos/upstreaming
Hi Pavel,
On 25.03.23 17:08, Pavel Machek wrote:
> Hi!
...
>> - The third option of the rt5033 chip is enabling charging termination. This
>> also enables a re-charge cycle. When the charging current sinks below the
>> end-of-charge current, the chip stops charging. The sysfs state changes to
>> "not charging". When the voltage gets 0.1 V below the end-of-charge constant
>> voltage, re-charging starts. Then again, when charging current sinks below
>> the end-of-charge current, the chip stops charging. And so on, going up and
>> down in re-charge cycles. In case the power consumption is high (e.g. tuning
>> on the display of the mobile device), the current goes into an equilibrium.
>> The downside of this charging termination option: When reaching the end-of-
>> charge current, the capacity might not have reached 100 % yet. The capacity
>> to reach probably depends on power consumption and battery wear. On my mobile
>> device, capacity reaches 98 %, drops to 96 % until re-charging kicks in,
>> climbs to 98 %, drops to 96 %, and so on. Not reaching 100 % is a bit
>> confusing to the user, too.
>
> Is the system powered from the battery in the not-charging case?
Yes, at RT5033 in the "not charging" state the system draws the power
from the battery.
...
Kind regards,
Jakob
^ permalink raw reply [flat|nested] 30+ messages in thread