[PATCH] mfd: rn5t618: fix IRQ trigger by changing it to level mode
During more massive generation of interrupts, the IRQ got stuck,
and the subdevices did not see any new interrupts. That happens
especially at wonky USB supply in combination with ADC reads.
To fix that trigger the IRQ at level low instead of falling edge.
Fixes: 0c81604516af ("mfd: rn5t618: Add IRQ support")
Signed-off-by: Andreas Kemnade
---
drivers/mfd/rn5t618.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/mfd/rn5t618.c b/drivers/mfd/rn5t618.c
index ecddd7b6500e..a852eef1f4d2 100644
--- a/drivers/mfd/rn5t618.c
+++ b/drivers/mfd/rn5t618.c
@@ -109,7 +109,7 @@ static int rn5t618_irq_init(struct rn5t618 *rn5t618)
ret = devm_regmap_add_irq_chip(rn5t618->dev, rn5t618->regmap,
rn5t618->irq,
- IRQF_TRIGGER_FALLING | IRQF_ONESHOT,
+ IRQF_TRIGGER_LOW | IRQF_ONESHOT,
0, irq_chip, &rn5t618->irq_data);
if (ret)
dev_err(rn5t618->dev, "Failed to register IRQ chip\n");
--
2.29.2
[PATCH v4] mfd: ntxec: Support for EC in Tolino Shine 2 HD
Add the version of the EC in the Tolino Shine 2 HD
to the supported versions. It seems not to have an RTC
and does not ack data written to it.
The vendor kernel happily ignores write errors, using
I2C via userspace i2c-set also shows the error.
So add a quirk to ignore that error.
PWM can be successfully configured despite of that error.
Signed-off-by: Andreas Kemnade
Reviewed-by: Jonathan Neuschäfer
---
Changes in v4:
- rename subdevices back to v2 (suggested by Jonathan)
- initialize subdevs in switch
Changes in v3:
- remove have_rtc variable
- rename subdevices again
Changes in v2:
- more comments about stacking regmap construction
- fix accidential line removal
- better naming for subdevices
drivers/mfd/ntxec.c | 56 ---
include/linux/mfd/ntxec.h | 1 +
2 files changed, 54 insertions(+), 3 deletions(-)
diff --git a/drivers/mfd/ntxec.c b/drivers/mfd/ntxec.c
index 957de2b03529..b711e73eedcb 100644
--- a/drivers/mfd/ntxec.c
+++ b/drivers/mfd/ntxec.c
@@ -96,6 +96,38 @@ static struct notifier_block ntxec_restart_handler = {
.priority = 128,
};
+static int regmap_ignore_write(void *context,
+ unsigned int reg, unsigned int val)
+
+{
+ struct regmap *regmap = context;
+
+ regmap_write(regmap, reg, val);
+
+ return 0;
+}
+
+static int regmap_wrap_read(void *context, unsigned int reg,
+ unsigned int *val)
+{
+ struct regmap *regmap = context;
+
+ return regmap_read(regmap, reg, val);
+}
+
+/*
+ * Some firmware versions do not ack written data, add a wrapper. It
+ * is used to stack another regmap on top.
+ */
+static const struct regmap_config regmap_config_noack = {
+ .name = "ntxec_noack",
+ .reg_bits = 8,
+ .val_bits = 16,
+ .cache_type = REGCACHE_NONE,
+ .reg_write = regmap_ignore_write,
+ .reg_read = regmap_wrap_read
+};
+
static const struct regmap_config regmap_config = {
.name = "ntxec",
.reg_bits = 8,
@@ -104,16 +136,22 @@ static const struct regmap_config regmap_config = {
.val_format_endian = REGMAP_ENDIAN_BIG,
};
-static const struct mfd_cell ntxec_subdevices[] = {
+static const struct mfd_cell ntxec_subdev[] = {
{ .name = "ntxec-rtc" },
{ .name = "ntxec-pwm" },
};
+static const struct mfd_cell ntxec_subdev_pwm[] = {
+ { .name = "ntxec-pwm" },
+};
+
static int ntxec_probe(struct i2c_client *client)
{
struct ntxec *ec;
unsigned int version;
int res;
+ const struct mfd_cell *subdevs;
+ size_t n_subdevs;
ec = devm_kmalloc(&client->dev, sizeof(*ec), GFP_KERNEL);
if (!ec)
@@ -137,6 +175,18 @@ static int ntxec_probe(struct i2c_client *client)
/* Bail out if we encounter an unknown firmware version */
switch (version) {
case NTXEC_VERSION_KOBO_AURA:
+ subdevs = ntxec_subdev;
+ n_subdevs = ARRAY_SIZE(ntxec_subdev);
+ break;
+ case NTXEC_VERSION_TOLINO_SHINE2:
+ subdevs = ntxec_subdev_pwm;
+ n_subdevs = ARRAY_SIZE(ntxec_subdev_pwm);
+ /* Another regmap stacked on top of the other */
+ ec->regmap = devm_regmap_init(ec->dev, NULL,
+ ec->regmap,
+ ®map_config_noack);
+ if (IS_ERR(ec->regmap))
+ return PTR_ERR(ec->regmap);
break;
default:
dev_err(ec->dev,
@@ -181,8 +231,8 @@ static int ntxec_probe(struct i2c_client *client)
i2c_set_clientdata(client, ec);
- res = devm_mfd_add_devices(ec->dev, PLATFORM_DEVID_NONE,
ntxec_subdevices,
- ARRAY_SIZE(ntxec_subdevices), NULL, 0, NULL);
+ res = devm_mfd_add_devices(ec->dev, PLATFORM_DEVID_NONE,
+ subdevs, n_subdevs, NULL, 0, NULL);
if (res)
dev_err(ec->dev, "Failed to add subdevices: %d\n", res);
diff --git a/include/linux/mfd/ntxec.h b/include/linux/mfd/ntxec.h
index 361204d125f1..26ab3b8eb612 100644
--- a/include/linux/mfd/ntxec.h
+++ b/include/linux/mfd/ntxec.h
@@ -33,5 +33,6 @@ static inline __be16 ntxec_reg8(u8 value)
/* Known firmware versions */
#define NTXEC_VERSION_KOBO_AURA0xd726 /* found in Kobo Aura */
+#define NTXEC_VERSION_TOLINO_SHINE2 0xf110 /* found in Tolino Shine 2 HD */
#endif
--
2.29.2
Re: [PATCH v3] mfd: ntxec: Support for EC in Tolino Shine 2 HD
On Mon, 15 Mar 2021 08:12:31 +
Lee Jones wrote:
[...]
> > static int ntxec_probe(struct i2c_client *client)
> > {
> > struct ntxec *ec;
> > unsigned int version;
> > int res;
> > + const struct mfd_cell *subdevs = ntxec_subdev;
> > + size_t n_subdevs = ARRAY_SIZE(ntxec_subdev);
>
> This is a little confusing. I had to re-read to figure it out.
>
> In my mind, it would be clearer to explicitly set these in the
> switch, rather than have a default which can be over-written.
>
yes, it is clearer. I was just afraid that your compiler cannot
figure it out that things get initialized and getting comments like
"This code has never seen a compiler."
But I will throw it against several ones.
Regards,
Andreas
[PATCH] mfd: rn5t618: Do not cache various USB related registers
These register get reset to their OTP defaults after USB plugging. And while at it, also add a missing register for detecting the charger type. Signed-off-by: Andreas Kemnade --- drivers/mfd/rn5t618.c | 3 +++ include/linux/mfd/rn5t618.h | 1 + 2 files changed, 4 insertions(+) diff --git a/drivers/mfd/rn5t618.c b/drivers/mfd/rn5t618.c index dc452df1f1bf..6ed04e6dbc78 100644 --- a/drivers/mfd/rn5t618.c +++ b/drivers/mfd/rn5t618.c @@ -45,8 +45,11 @@ static bool rn5t618_volatile_reg(struct device *dev, unsigned int reg) case RN5T618_INTMON: case RN5T618_RTC_CTRL1 ... RN5T618_RTC_CTRL2: case RN5T618_RTC_SECONDS ... RN5T618_RTC_YEAR: + case RN5T618_CHGCTL1: + case RN5T618_REGISET1 ... RN5T618_REGISET2: case RN5T618_CHGSTATE: case RN5T618_CHGCTRL_IRR ... RN5T618_CHGERR_MONI: + case RN5T618_GCHGDET: case RN5T618_CONTROL ... RN5T618_CC_AVEREG0: return true; default: diff --git a/include/linux/mfd/rn5t618.h b/include/linux/mfd/rn5t618.h index fba0df13d9a8..8aa0bda1af4f 100644 --- a/include/linux/mfd/rn5t618.h +++ b/include/linux/mfd/rn5t618.h @@ -188,6 +188,7 @@ #define RN5T618_CHGOSCSCORESET30xd7 #define RN5T618_CHGOSCFREQSET1 0xd8 #define RN5T618_CHGOSCFREQSET2 0xd9 +#define RN5T618_GCHGDET0xda #define RN5T618_CONTROL0xe0 #define RN5T618_SOC0xe1 #define RN5T618_RE_CAP_H 0xe2 -- 2.29.2
Re: [PATCH v2] mfd: ntxec: Support for EC in Tolino Shine 2 HD
On Sat, 13 Mar 2021 12:17:34 +0100
Jonathan Neuschäfer wrote:
> On Wed, Mar 10, 2021 at 09:55:45AM +, Lee Jones wrote:
> > On Mon, 08 Mar 2021, Andreas Kemnade wrote:
> [...]
> > > -static const struct mfd_cell ntxec_subdevices[] = {
> > > +static const struct mfd_cell ntxec_subdev[] = {
> > > { .name = "ntxec-rtc" },
> > > { .name = "ntxec-pwm" },
> > > };
> > >
> > > +static const struct mfd_cell ntxec_subdev_pwm[] = {
> > > + { .name = "ntxec-pwm" },
> > > +};
> >
> > To put across what you're trying to achieve, maybe call this:
> >
> > ntxec_subdev_no_rtc[]
> >
> > Then if other devices are added, the semantics/intent stays the same
> > and it won't have to be renamed.
>
> Andreas, what is the full amount of functionality this version of the EC
> can ever provide?
>
> If it's only PWM, I think ntxec_subdev_pwm fits well.
>
I think it is only PWM. At least I could not see any other I2C access.
> [ The next subdevice that I can foresee is battery monitoring. ]
>
That is done via the RC5T619 on that device.
Regards,
Andreas
[PATCH v3] mfd: ntxec: Support for EC in Tolino Shine 2 HD
Add the version of the EC in the Tolino Shine 2 HD
to the supported versions. It seems not to have an RTC
and does not ack data written to it.
The vendor kernel happily ignores write errors, using
I2C via userspace i2c-set also shows the error.
So add a quirk to ignore that error.
PWM can be successfully configured despite of that error.
Signed-off-by: Andreas Kemnade
Reviewed-by: Jonathan Neuschäfer
---
Changes in v3:
- remove have_rtc variable
- rename subdevices again
Changes in v2:
- more comments about stacking regmap construction
- fix accidential line removal
- better naming for subdevices
drivers/mfd/ntxec.c | 55 ---
include/linux/mfd/ntxec.h | 1 +
2 files changed, 53 insertions(+), 3 deletions(-)
diff --git a/drivers/mfd/ntxec.c b/drivers/mfd/ntxec.c
index 957de2b03529..ab6860ef3e9a 100644
--- a/drivers/mfd/ntxec.c
+++ b/drivers/mfd/ntxec.c
@@ -96,6 +96,38 @@ static struct notifier_block ntxec_restart_handler = {
.priority = 128,
};
+static int regmap_ignore_write(void *context,
+ unsigned int reg, unsigned int val)
+
+{
+ struct regmap *regmap = context;
+
+ regmap_write(regmap, reg, val);
+
+ return 0;
+}
+
+static int regmap_wrap_read(void *context, unsigned int reg,
+ unsigned int *val)
+{
+ struct regmap *regmap = context;
+
+ return regmap_read(regmap, reg, val);
+}
+
+/*
+ * Some firmware versions do not ack written data, add a wrapper. It
+ * is used to stack another regmap on top.
+ */
+static const struct regmap_config regmap_config_noack = {
+ .name = "ntxec_noack",
+ .reg_bits = 8,
+ .val_bits = 16,
+ .cache_type = REGCACHE_NONE,
+ .reg_write = regmap_ignore_write,
+ .reg_read = regmap_wrap_read
+};
+
static const struct regmap_config regmap_config = {
.name = "ntxec",
.reg_bits = 8,
@@ -104,16 +136,22 @@ static const struct regmap_config regmap_config = {
.val_format_endian = REGMAP_ENDIAN_BIG,
};
-static const struct mfd_cell ntxec_subdevices[] = {
+static const struct mfd_cell ntxec_subdev[] = {
{ .name = "ntxec-rtc" },
{ .name = "ntxec-pwm" },
};
+static const struct mfd_cell ntxec_subdev_no_rtc[] = {
+ { .name = "ntxec-pwm" },
+};
+
static int ntxec_probe(struct i2c_client *client)
{
struct ntxec *ec;
unsigned int version;
int res;
+ const struct mfd_cell *subdevs = ntxec_subdev;
+ size_t n_subdevs = ARRAY_SIZE(ntxec_subdev);
ec = devm_kmalloc(&client->dev, sizeof(*ec), GFP_KERNEL);
if (!ec)
@@ -138,6 +176,16 @@ static int ntxec_probe(struct i2c_client *client)
switch (version) {
case NTXEC_VERSION_KOBO_AURA:
break;
+ case NTXEC_VERSION_TOLINO_SHINE2:
+ subdevs = ntxec_subdev_no_rtc;
+ n_subdevs = ARRAY_SIZE(ntxec_subdev_no_rtc);
+ /* Another regmap stacked on top of the other */
+ ec->regmap = devm_regmap_init(ec->dev, NULL,
+ ec->regmap,
+ ®map_config_noack);
+ if (IS_ERR(ec->regmap))
+ return PTR_ERR(ec->regmap);
+ break;
default:
dev_err(ec->dev,
"Netronix embedded controller version %04x is not
supported.\n",
@@ -181,8 +229,9 @@ static int ntxec_probe(struct i2c_client *client)
i2c_set_clientdata(client, ec);
- res = devm_mfd_add_devices(ec->dev, PLATFORM_DEVID_NONE,
ntxec_subdevices,
- ARRAY_SIZE(ntxec_subdevices), NULL, 0, NULL);
+ res = devm_mfd_add_devices(ec->dev, PLATFORM_DEVID_NONE,
+ subdevs, n_subdevs,
+ NULL, 0, NULL);
if (res)
dev_err(ec->dev, "Failed to add subdevices: %d\n", res);
diff --git a/include/linux/mfd/ntxec.h b/include/linux/mfd/ntxec.h
index 361204d125f1..26ab3b8eb612 100644
--- a/include/linux/mfd/ntxec.h
+++ b/include/linux/mfd/ntxec.h
@@ -33,5 +33,6 @@ static inline __be16 ntxec_reg8(u8 value)
/* Known firmware versions */
#define NTXEC_VERSION_KOBO_AURA0xd726 /* found in Kobo Aura */
+#define NTXEC_VERSION_TOLINO_SHINE2 0xf110 /* found in Tolino Shine 2 HD */
#endif
--
2.29.2
[PATCH v2] mfd: ntxec: Support for EC in Tolino Shine 2 HD
Add the version of the EC in the Tolino Shine 2 HD
to the supported versions. It seems not to have an RTC
and does not ack data written to it.
The vendor kernel happily ignores write errors, using
I2C via userspace i2c-set also shows the error.
So add a quirk to ignore that error.
PWM can be successfully configured despite of that error.
Signed-off-by: Andreas Kemnade
---
Changes in v2:
- more comments about stacking regmap construction
- fix accidential line removal
- better naming for subdevices
drivers/mfd/ntxec.c | 61 +--
include/linux/mfd/ntxec.h | 1 +
2 files changed, 59 insertions(+), 3 deletions(-)
diff --git a/drivers/mfd/ntxec.c b/drivers/mfd/ntxec.c
index 957de2b03529..0bbd2e34e89c 100644
--- a/drivers/mfd/ntxec.c
+++ b/drivers/mfd/ntxec.c
@@ -96,6 +96,38 @@ static struct notifier_block ntxec_restart_handler = {
.priority = 128,
};
+static int regmap_ignore_write(void *context,
+ unsigned int reg, unsigned int val)
+
+{
+ struct regmap *regmap = context;
+
+ regmap_write(regmap, reg, val);
+
+ return 0;
+}
+
+static int regmap_wrap_read(void *context, unsigned int reg,
+ unsigned int *val)
+{
+ struct regmap *regmap = context;
+
+ return regmap_read(regmap, reg, val);
+}
+
+/*
+ * Some firmware versions do not ack written data, add a wrapper. It
+ * is used to stack another regmap on top.
+ */
+static const struct regmap_config regmap_config_noack = {
+ .name = "ntxec_noack",
+ .reg_bits = 8,
+ .val_bits = 16,
+ .cache_type = REGCACHE_NONE,
+ .reg_write = regmap_ignore_write,
+ .reg_read = regmap_wrap_read
+};
+
static const struct regmap_config regmap_config = {
.name = "ntxec",
.reg_bits = 8,
@@ -104,15 +136,20 @@ static const struct regmap_config regmap_config = {
.val_format_endian = REGMAP_ENDIAN_BIG,
};
-static const struct mfd_cell ntxec_subdevices[] = {
+static const struct mfd_cell ntxec_subdev[] = {
{ .name = "ntxec-rtc" },
{ .name = "ntxec-pwm" },
};
+static const struct mfd_cell ntxec_subdev_pwm[] = {
+ { .name = "ntxec-pwm" },
+};
+
static int ntxec_probe(struct i2c_client *client)
{
struct ntxec *ec;
unsigned int version;
+ bool has_rtc;
int res;
ec = devm_kmalloc(&client->dev, sizeof(*ec), GFP_KERNEL);
@@ -137,6 +174,16 @@ static int ntxec_probe(struct i2c_client *client)
/* Bail out if we encounter an unknown firmware version */
switch (version) {
case NTXEC_VERSION_KOBO_AURA:
+ has_rtc = true;
+ break;
+ case NTXEC_VERSION_TOLINO_SHINE2:
+ has_rtc = false;
+ /* Another regmap stacked on top of the other */
+ ec->regmap = devm_regmap_init(ec->dev, NULL,
+ ec->regmap,
+ ®map_config_noack);
+ if (IS_ERR(ec->regmap))
+ return PTR_ERR(ec->regmap);
break;
default:
dev_err(ec->dev,
@@ -181,8 +228,16 @@ static int ntxec_probe(struct i2c_client *client)
i2c_set_clientdata(client, ec);
- res = devm_mfd_add_devices(ec->dev, PLATFORM_DEVID_NONE,
ntxec_subdevices,
- ARRAY_SIZE(ntxec_subdevices), NULL, 0, NULL);
+ if (has_rtc)
+ res = devm_mfd_add_devices(ec->dev, PLATFORM_DEVID_NONE,
+ ntxec_subdev,
+ ARRAY_SIZE(ntxec_subdev),
+ NULL, 0, NULL);
+ else
+ res = devm_mfd_add_devices(ec->dev, PLATFORM_DEVID_NONE,
+ ntxec_subdev_pwm,
+ ARRAY_SIZE(ntxec_subdev_pwm),
+ NULL, 0, NULL);
if (res)
dev_err(ec->dev, "Failed to add subdevices: %d\n", res);
diff --git a/include/linux/mfd/ntxec.h b/include/linux/mfd/ntxec.h
index 361204d125f1..26ab3b8eb612 100644
--- a/include/linux/mfd/ntxec.h
+++ b/include/linux/mfd/ntxec.h
@@ -33,5 +33,6 @@ static inline __be16 ntxec_reg8(u8 value)
/* Known firmware versions */
#define NTXEC_VERSION_KOBO_AURA0xd726 /* found in Kobo Aura */
+#define NTXEC_VERSION_TOLINO_SHINE2 0xf110 /* found in Tolino Shine 2 HD */
#endif
--
2.29.2
Re: [PATCH -next] mfd: ntxec: Support for EC in Tolino Shine 2 HD
On Sat, 6 Mar 2021 21:19:38 +0100 Jonathan Neuschäfer wrote: [...] > > > > + case NTXEC_VERSION_TOLINO_SHINE2: > > > > + has_rtc = false; > > > > + ec->regmap = devm_regmap_init(ec->dev, NULL, > > > > + ec->regmap, > > > > + ®map_config_noack); > > > > > > Ah— A custom regmap stacked on top of the old regmap… I think this > > > deserves a comment. > > > > > Yes, devm_regmap_init_i2c() sets a different set of callbacks depending > > on circumstances. Seems to be the easiest way to avoid duplicating too > > much code. I really hope that there are not so much devices requiring > > such a dirty stuff that adding such thing to the generic regmap code > > would be justified. > > Ok, please add a short comment here or extend the one above the repmap > config struct, to save interested readers a bit of trouble. I guess "add > a wrapper" goes in right direction, but it didn't make the stacking > obvious to me when I first read it. > I will wait for some days to see whether anybody chokes on that stack. Regards, Andreas
Re: [PATCH -next] mfd: ntxec: Support for EC in Tolino Shine 2 HD
On Sat, 6 Mar 2021 20:14:46 +0100
Jonathan Neuschäfer wrote:
> Hi,
>
> (Cc'ing Mark Brown because of the regmap related questions)
>
> On Sat, Mar 06, 2021 at 07:13:14PM +0100, Andreas Kemnade wrote:
> > Add the version of the EC in the Tolino Shine 2 HD
> > to the supported versions. It seems not to have an RTC
> > and does not ack data written to it.
> > The vendor kernel happily ignores write errors, using
> > I2C via userspace i2c-set also shows the error.
> > So add a quirk to ignore that error.
> >
> > PWM can be successfully configured despite of that error.
>
> I'm curious, is this one of the variants with two PWM channels
> (for configurable color temperature)?
>
No. Tolino Shine 3 and Kobo Clara HD have such things. There you have a
/sys/class/backlight/backlight_{cold,warm}.
> >
> > Signed-off-by: Andreas Kemnade
> > ---
> > drivers/mfd/ntxec.c | 57 ---
> > include/linux/mfd/ntxec.h | 1 +
> > 2 files changed, 55 insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/mfd/ntxec.c b/drivers/mfd/ntxec.c
> > index 957de2b03529..e7fe570127af 100644
> > --- a/drivers/mfd/ntxec.c
> > +++ b/drivers/mfd/ntxec.c
> > @@ -96,6 +96,36 @@ static struct notifier_block ntxec_restart_handler = {
> > .priority = 128,
> > };
> >
> > +static int regmap_ignore_write(void *context,
> > + unsigned int reg, unsigned int val)
> > +
> > +{
> > + struct regmap *regmap = context;
> > +
> > + regmap_write(regmap, reg, val);
> > +
> > + return 0;
> > +}
> > +
> > +static int regmap_wrap_read(void *context, unsigned int reg,
> > + unsigned int *val)
> > +{
> > + struct regmap *regmap = context;
> > +
> > + return regmap_read(regmap, reg, val);
> > +}
> > +
> > +/* some firmware versions do not ack written data, add a wrapper */
> > +static const struct regmap_config regmap_config_noack = {
> > + .name = "ntxec_noack",
> > + .reg_bits = 8,
> > + .val_bits = 16,
> > + .cache_type = REGCACHE_NONE,
> > + .val_format_endian = REGMAP_ENDIAN_BIG,
> > + .reg_write = regmap_ignore_write,
> > + .reg_read = regmap_wrap_read
>
> Is the read wrapper necessary? It seems to me from reading regmap.h
> that leaving .reg_read set to NULL should do the right thing, but I'm
> not sure.
>
well if we want to read from it, there need to be some function for it.
But if... I do not see anything worth to read besides of version.
I think we can leave ouf val_format_endian because a lot of stuff is
bypassed if no bus is set in regmap_init().
There is e.g. a goto skip_format_initialization.
> > +};
> > +
> > static const struct regmap_config regmap_config = {
> > .name = "ntxec",
> > .reg_bits = 8,
> > @@ -109,10 +139,15 @@ static const struct mfd_cell ntxec_subdevices[] = {
> > { .name = "ntxec-pwm" },
> > };
> >
> > +static const struct mfd_cell ntxec_subdev_pwm[] = {
> > + { .name = "ntxec-pwm" },
> > +};
>
> ntxec_subdevices vs. ntxec_subdev_pwm seems slightly inconsistent in
> naming. ntxec_subdevices_pwm would be a wrong plural, but IMHO slightly
> better because of consistency. Maybe rename ntxec_subdevices to
> ntxec_subdev?
>
yes, I will change it.
> > +
> > static int ntxec_probe(struct i2c_client *client)
> > {
> > struct ntxec *ec;
> > unsigned int version;
> > + bool has_rtc;
> > int res;
> >
> > ec = devm_kmalloc(&client->dev, sizeof(*ec), GFP_KERNEL);
> > @@ -137,6 +172,15 @@ static int ntxec_probe(struct i2c_client *client)
> > /* Bail out if we encounter an unknown firmware version */
> > switch (version) {
> > case NTXEC_VERSION_KOBO_AURA:
> > + has_rtc = true;
> > + break;
> > + case NTXEC_VERSION_TOLINO_SHINE2:
> > + has_rtc = false;
> > + ec->regmap = devm_regmap_init(ec->dev, NULL,
> > + ec->regmap,
> > + ®map_config_noack);
>
> Ah— A custom regmap stacked on top of the old regmap… I think this
> deserves a comment.
>
Yes, devm_regmap_init_i2c() sets a different set of callbacks depending
on circumstances. Seems to be the easiest way to avoid duplicating too
much code. I really hope that there are not so much devices requiring
such a dirty stuff that adding such thing to t
[PATCH -next] mfd: ntxec: Support for EC in Tolino Shine 2 HD
Add the version of the EC in the Tolino Shine 2 HD
to the supported versions. It seems not to have an RTC
and does not ack data written to it.
The vendor kernel happily ignores write errors, using
I2C via userspace i2c-set also shows the error.
So add a quirk to ignore that error.
PWM can be successfully configured despite of that error.
Signed-off-by: Andreas Kemnade
---
drivers/mfd/ntxec.c | 57 ---
include/linux/mfd/ntxec.h | 1 +
2 files changed, 55 insertions(+), 3 deletions(-)
diff --git a/drivers/mfd/ntxec.c b/drivers/mfd/ntxec.c
index 957de2b03529..e7fe570127af 100644
--- a/drivers/mfd/ntxec.c
+++ b/drivers/mfd/ntxec.c
@@ -96,6 +96,36 @@ static struct notifier_block ntxec_restart_handler = {
.priority = 128,
};
+static int regmap_ignore_write(void *context,
+ unsigned int reg, unsigned int val)
+
+{
+ struct regmap *regmap = context;
+
+ regmap_write(regmap, reg, val);
+
+ return 0;
+}
+
+static int regmap_wrap_read(void *context, unsigned int reg,
+ unsigned int *val)
+{
+ struct regmap *regmap = context;
+
+ return regmap_read(regmap, reg, val);
+}
+
+/* some firmware versions do not ack written data, add a wrapper */
+static const struct regmap_config regmap_config_noack = {
+ .name = "ntxec_noack",
+ .reg_bits = 8,
+ .val_bits = 16,
+ .cache_type = REGCACHE_NONE,
+ .val_format_endian = REGMAP_ENDIAN_BIG,
+ .reg_write = regmap_ignore_write,
+ .reg_read = regmap_wrap_read
+};
+
static const struct regmap_config regmap_config = {
.name = "ntxec",
.reg_bits = 8,
@@ -109,10 +139,15 @@ static const struct mfd_cell ntxec_subdevices[] = {
{ .name = "ntxec-pwm" },
};
+static const struct mfd_cell ntxec_subdev_pwm[] = {
+ { .name = "ntxec-pwm" },
+};
+
static int ntxec_probe(struct i2c_client *client)
{
struct ntxec *ec;
unsigned int version;
+ bool has_rtc;
int res;
ec = devm_kmalloc(&client->dev, sizeof(*ec), GFP_KERNEL);
@@ -137,6 +172,15 @@ static int ntxec_probe(struct i2c_client *client)
/* Bail out if we encounter an unknown firmware version */
switch (version) {
case NTXEC_VERSION_KOBO_AURA:
+ has_rtc = true;
+ break;
+ case NTXEC_VERSION_TOLINO_SHINE2:
+ has_rtc = false;
+ ec->regmap = devm_regmap_init(ec->dev, NULL,
+ ec->regmap,
+ ®map_config_noack);
+ if (IS_ERR(ec->regmap))
+ return PTR_ERR(ec->regmap);
break;
default:
dev_err(ec->dev,
@@ -155,7 +199,6 @@ static int ntxec_probe(struct i2c_client *client)
*/
res = regmap_write(ec->regmap, NTXEC_REG_POWERKEEP,
NTXEC_POWERKEEP_VALUE);
- if (res < 0)
return res;
if (poweroff_restart_client)
@@ -181,8 +224,16 @@ static int ntxec_probe(struct i2c_client *client)
i2c_set_clientdata(client, ec);
- res = devm_mfd_add_devices(ec->dev, PLATFORM_DEVID_NONE,
ntxec_subdevices,
- ARRAY_SIZE(ntxec_subdevices), NULL, 0, NULL);
+ if (has_rtc)
+ res = devm_mfd_add_devices(ec->dev, PLATFORM_DEVID_NONE,
+ ntxec_subdevices,
+ ARRAY_SIZE(ntxec_subdevices),
+ NULL, 0, NULL);
+ else
+ res = devm_mfd_add_devices(ec->dev, PLATFORM_DEVID_NONE,
+ ntxec_subdev_pwm,
+ ARRAY_SIZE(ntxec_subdev_pwm),
+ NULL, 0, NULL);
if (res)
dev_err(ec->dev, "Failed to add subdevices: %d\n", res);
diff --git a/include/linux/mfd/ntxec.h b/include/linux/mfd/ntxec.h
index 361204d125f1..26ab3b8eb612 100644
--- a/include/linux/mfd/ntxec.h
+++ b/include/linux/mfd/ntxec.h
@@ -33,5 +33,6 @@ static inline __be16 ntxec_reg8(u8 value)
/* Known firmware versions */
#define NTXEC_VERSION_KOBO_AURA0xd726 /* found in Kobo Aura */
+#define NTXEC_VERSION_TOLINO_SHINE2 0xf110 /* found in Tolino Shine 2 HD */
#endif
--
2.29.2
Re: [PATCH 1/3] power: supply: bq27xxx: fix sign of current_now for newer ICs
On Tue, 23 Feb 2021 15:11:20 +0100
Matthias Schiffer wrote:
> Commit cd060b4d0868 ("power: supply: bq27xxx: fix polarity of current_now")
> changed the sign of current_now for all bq27xxx variants, but on BQ28Z610
> I'm now seeing negated values *with* that patch.
>
> The GTA04/Openmoko device that was used for testing uses a BQ27000 or
> BQ27010 IC, so I assume only the BQ27XXX_O_ZERO code path was incorrect.
> Revert the behaviour for newer ICs.
>
> Fixes: cd060b4d0868 "power: supply: bq27xxx: fix polarity of current_now"
> Signed-off-by: Matthias Schiffer
> ---
>
> @Andreas Kemnade: It would be great to get a confirmation that the
> Openmoko battery indeed uses BQ27000/BQ27010 - I was having some trouble
> finding that information.
>
I can confirm that.
here is the corresponding schematic:
http://people.openmoko.org/tony_tu/GTA02/hardware/GTA02/CT-GTA02.pdf
Regards,
Andreas
Re: [PATCH v9 0/7] Netronix embedded controller driver for Kobo and Tolino ebook readers
On Sun, 24 Jan 2021 22:41:20 +0100 Jonathan Neuschäfer wrote: > This patchset adds basic support for the embedded controller found on > older ebook reader boards designed by/with the ODM Netronix Inc.[1] and > sold by Kobo or Tolino, for example the Kobo Aura and the Tolino Shine. > These drivers are based on information contained in the vendor kernel > sources, but in order to all information in a single place, I documented > the register interface of the EC on GitHub[2]. > > [1]: http://www.netronixinc.com/products.aspx?ID=1 > [2]: > https://github.com/neuschaefer/linux/wiki/Netronix-MSP430-embedded-controller > > v9: > - Fixed a bug in the error handling of ntxec_probe, > Reported-by: kernel test robot > - Added Thierry Reding's ACK to the PWM patch > what is the fate of this one, looks like it got all acks from maintainers. Regards, Andreas
Re: [Letux-kernel] BOG: commit 89c7cb1608ac3 ("of/device: Update dma_range_map only when dev has valid dma-ranges") seems to break Pinephone display or LCDC
On Fri, 5 Feb 2021 16:10:18 +0100 Paul Kocialkowski wrote: > Hey, > > On Tue 02 Feb 21, 16:07, H. Nikolaus Schaller wrote: > > Hi Paul, > > > > > Am 02.02.2021 um 14:42 schrieb Paul Kocialkowski > > > : > > > > > > Hi Nikolaus, > > > > > > On Tue 02 Feb 21, 11:50, H. Nikolaus Schaller wrote: > > >> Hi Paul, > > >> > > >>> Am 02.02.2021 um 10:56 schrieb Paul Kocialkowski > > >>> : > > >>> > > >>> Hi Nikolaus, > > >>> > > >>> On Tue 02 Feb 21, 10:18, H. Nikolaus Schaller wrote: > > Hi, > > since v5.11-rc6 my Pinephone display shows some moiré pattern. > > > > I did a bisect between v5.11-rc5 and v5.11-rc6 and it told me that > > the commit mentioned in the subject is the reason. > > > > Reverting it makes the display work again and re-reverting fail again. > > > > IMHO it seems as if the display DMA of the pinephone (allwinner > > suni-a54) > > got influenced and stopped to scan the framebuffer. > > > > The only dma-ranges I could find are defined here: > > > > arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi > > > > dma-ranges = <0x 0x4000 0xc000>; > > > > but I can't tell if they are "valid" or not. > > > > Any insights are welcome. And please direct to the right > > people/mailing lists > > if they are missing. > > >>> > > >>> This may not be strictly the same thing, but is this patch in your tree: > > >>> https://patchwork.kernel.org/project/linux-arm-kernel/patch/20210115175831.1184260-2-paul.kocialkow...@bootlin.com/ > > >>> > > >>> If not, it's worth a try to add it. > > >> > > >> No, it hasn't arrived in v5.11-rc6 (or linux-next) yet. > > >> > > >> But it fixes the issue. > > > > > > Great! The patch should already be on its way to the next RC. > > > > Fine! > > > > > > > > And nice to see you're active on Pinephone as well! > > > > I have a developer unit and the LetuxOS kernel already supports it a > > little. This is why I observed the issue with -rc6 > > > > > You might remember me from > > > the Replicant project, as I've worked a bit on the GTA04 :) > > > > Sure, you are well remembered :) > > > > I still have the dream to revitalize Replicant 4.2 for the GTA04 just for > > fun. I can already boot to Replicant touch screen with a v5.4 kernel. v5.10 > > fails when trying to spawn zygote... > > Oh I see! I think Android has made some significant progress is its ability > to use mainline (4.2 was an early stage and I remember having to backport > patches to use some mainline features back then). > > Maybe it would be easier with Replicant 6, but you'd have to go through the > device bringup phase again, which is never nice. > well, we have done some experimental Replicant 6 images, but it is unbeleavable slow. Do not know why. The bootanimation process(even though there is no "animation") draws a lot of cpu power. Regards, Andreas
[PATCH RESEND v2] dt-bindings: mfd: Convert rn5t618 to json-schema
Convert the RN5T618 binding to DT schema format. Also
clearly state which regulators are available.
Signed-off-by: Andreas Kemnade
Reviewed-by: Rob Herring
---
https://lore.kernel.org/lkml/cal_jsqjwt91+azwaweuvjobqgsyw6gbhqmohwu_t5qzabxx...@mail.gmail.com/
Changes in v2:
- drop irq description
Due to its .txt-format history BSD license was not added.
.../bindings/mfd/ricoh,rn5t618.yaml | 111 ++
.../devicetree/bindings/mfd/rn5t618.txt | 52
2 files changed, 111 insertions(+), 52 deletions(-)
create mode 100644 Documentation/devicetree/bindings/mfd/ricoh,rn5t618.yaml
delete mode 100644 Documentation/devicetree/bindings/mfd/rn5t618.txt
diff --git a/Documentation/devicetree/bindings/mfd/ricoh,rn5t618.yaml
b/Documentation/devicetree/bindings/mfd/ricoh,rn5t618.yaml
new file mode 100644
index ..d70e85a09c84
--- /dev/null
+++ b/Documentation/devicetree/bindings/mfd/ricoh,rn5t618.yaml
@@ -0,0 +1,111 @@
+# SPDX-License-Identifier: GPL-2.0
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/mfd/ricoh,rn5t618.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Ricoh RN5T567/RN5T618/RC5T619 PMIC
+
+maintainers:
+ - Andreas Kemnade
+
+description: |
+ Ricoh RN5T567/RN5T618/RC5T619 is a power management IC family which
+ integrates 3 to 5 step-down DCDC converters, 7 to 10 low-dropout regulators,
+ GPIOs, and a watchdog timer. It can be controlled through an I2C interface.
+ The RN5T618/RC5T619 provides additionally a Li-ion battery charger,
+ fuel gauge, and an ADC.
+ The RC5T619 additionnally includes USB charger detection and an RTC.
+
+allOf:
+ - if:
+ properties:
+compatible:
+ contains:
+const: ricoh,rn5t567
+then:
+ properties:
+regulators:
+ patternProperties:
+"^(DCDC[1-4]|LDO[1-5]|LDORTC[12])$":
+ $ref: ../regulator/regulator.yaml
+ additionalProperties: false
+ - if:
+ properties:
+compatible:
+ contains:
+const: ricoh,rn5t618
+then:
+ properties:
+regulators:
+ patternProperties:
+"^(DCDC[1-3]|LDO[1-5]|LDORTC[12])$":
+ $ref: ../regulator/regulator.yaml
+ additionalProperties: false
+ - if:
+ properties:
+compatible:
+ contains:
+const: ricoh,rc5t619
+then:
+ properties:
+regulators:
+ patternProperties:
+"^(DCDC[1-5]|LDO[1-9]|LDO10|LDORTC[12])$":
+ $ref: ../regulator/regulator.yaml
+ additionalProperties: false
+
+properties:
+ compatible:
+enum:
+ - ricoh,rn5t567
+ - ricoh,rn5t618
+ - ricoh,rc5t619
+
+ reg:
+maxItems: 1
+
+ interrupts:
+maxItems: 1
+
+ system-power-controller:
+type: boolean
+description: |
+ See Documentation/devicetree/bindings/power/power-controller.txt
+
+ regulators:
+type: object
+
+additionalProperties: false
+
+required:
+ - compatible
+ - reg
+
+examples:
+ - |
+#include
+i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ pmic@32 {
+compatible = "ricoh,rn5t618";
+reg = <0x32>;
+interrupt-parent = <&gpio5>;
+interrupts = <11 IRQ_TYPE_EDGE_FALLING>;
+system-power-controller;
+
+regulators {
+ DCDC1 {
+regulator-min-microvolt = <105>;
+regulator-max-microvolt = <105>;
+ };
+
+ DCDC2 {
+regulator-min-microvolt = <1175000>;
+regulator-max-microvolt = <1175000>;
+ };
+};
+ };
+};
diff --git a/Documentation/devicetree/bindings/mfd/rn5t618.txt
b/Documentation/devicetree/bindings/mfd/rn5t618.txt
deleted file mode 100644
index 16778ea00dbc..
--- a/Documentation/devicetree/bindings/mfd/rn5t618.txt
+++ /dev/null
@@ -1,52 +0,0 @@
-* Ricoh RN5T567/RN5T618 PMIC
-
-Ricoh RN5T567/RN5T618/RC5T619 is a power management IC family which
-integrates 3 to 5 step-down DCDC converters, 7 to 10 low-dropout regulators,
-GPIOs, and a watchdog timer. It can be controlled through an I2C interface.
-The RN5T618/RC5T619 provides additionally a Li-ion battery charger,
-fuel gauge, and an ADC.
-The RC5T619 additionnally includes USB charger detection and an RTC.
-
-Required properties:
- - compatible: must be one of
- "ricoh,rn5t567"
- "ricoh,rn5t618"
- "ricoh,rc5t619"
- - reg: the I2C slave address of the device
-
-Optional properties:
- - interrupts: interrupt mapping for IRQ
- See Documentation/devicetree/bindings/interrupt-controller/interrupts.txt
- - system-power-controller:
- See Documentation/devicetree/bindings/power/power-controller.txt
-
-Sub-nodes:
- - regulators: the node is required if the regulator functional
Re: [PATCH] dts: ARM: add kobo glo hd ebook reader
[resent with some more complete address list, get_maintainer.pl
provides more]
Hi,
On Tue, 26 Jan 2021 18:31:31 +0100
Armin Preiml wrote:
> This patch adds basic support for the kobo glo hd reader. It defines CPU,
> memory, UART and storage.Also add pin control settings for i2c and sdhc.
>
> All values where extracted from the vendor kernel and u-boot sources.
>
> Signed-off-by: Armin Preiml
>
> ---
> arch/arm/boot/dts/Makefile | 1 +
> arch/arm/boot/dts/imx6sl-kobo-glo-hd.dts | 164 +++
> 2 files changed, 165 insertions(+)
> create mode 100644 arch/arm/boot/dts/imx6sl-kobo-glo-hd.dts
>
> diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
> index 3d1ea0b25..ba608414e 100644
> --- a/arch/arm/boot/dts/Makefile
> +++ b/arch/arm/boot/dts/Makefile
> @@ -598,6 +598,7 @@ dtb-$(CONFIG_SOC_IMX6Q) += \
> imx6qp-zii-rdu2.dtb
> dtb-$(CONFIG_SOC_IMX6SL) += \
> imx6sl-evk.dtb \
> + imx6sl-kobo-glo-hd.dtb \
> imx6sl-tolino-shine2hd.dtb \
> imx6sl-tolino-shine3.dtb \
> imx6sl-warp.dtb
> diff --git a/arch/arm/boot/dts/imx6sl-kobo-glo-hd.dts
> b/arch/arm/boot/dts/imx6sl-kobo-glo-hd.dts
> new file mode 100644
> index 0..759699e9e
> --- /dev/null
> +++ b/arch/arm/boot/dts/imx6sl-kobo-glo-hd.dts
> @@ -0,0 +1,164 @@
> +// SPDX-License-Identifier: (GPL-2.0)
> +/*
> + * Device tree for the Kobo Glo HD ebook reader.
> + *
> + * Name on mainboard is: 37NB-E60Q90+4A1
> + * Board name in uboot sources: E60Q90
> + *
> + * Copyright 2021 Armin Preiml
> + * based on works
> + * Copyright 2015 Freescale Semiconductor, Inc.
> + */
> +
> +/dts-v1/;
> +
> +#include
> +#include
> +#include "imx6sl.dtsi"
> +
> +/ {
> + model = "Kobo Glo HD";
> + compatible = "kobo,glohd", "fsl,imx6sl";
> +
kobo,glohd should be added to
Documentation/devicetree/bindings/arm/fsl.yaml
[...]
> +pinctrl_uart1: uart1grp {
> +fsl,pins = <
> + MX6SL_PAD_UART1_TXD__UART1_TX_DATA 0x1b0b1
> + MX6SL_PAD_UART1_RXD__UART1_RX_DATA 0x1b0b1
> + >;
> + };
> +
hmm, pictures (we are talking about FCC ID NOIKBN437, right?) show two
uarts, next to each other. Which one is this?
The other uart might be the same as in the tolino2-shinehd.
> + pinctrl_usdhc1: usdhc1grp { /* 50MHZ (>50MHZ: 0x1f0f9) */
> +fsl,pins = <
> + MX6SL_PAD_SD1_CLK__SD1_CLK 0x1f071
> + MX6SL_PAD_SD1_CMD__SD1_CMD 0x1f071
> + MX6SL_PAD_SD1_DAT0__SD1_DATA0 0x1f071
> + MX6SL_PAD_SD1_DAT1__SD1_DATA1 0x1f071
> + MX6SL_PAD_SD1_DAT2__SD1_DATA2 0x1f071
> + MX6SL_PAD_SD1_DAT3__SD1_DATA3 0x1f071
> + MX6SL_PAD_SD1_DAT4__SD1_DATA4 0x1f071
> + MX6SL_PAD_SD1_DAT5__SD1_DATA5 0x1f071
> + MX6SL_PAD_SD1_DAT6__SD1_DATA6 0x1f071
> + MX6SL_PAD_SD1_DAT7__SD1_DATA7 0x1f071
> + >;
> + };
> +
That is for emmc? And it is not populated, so probably better not
enable that here.
[...]
> +&uart1 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_uart1>;
> + status = "okay";
> +};
> +
> +&usdhc1 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_usdhc1>;
> + status = "okay";
> +};
> +
and also not add this.
I guess it might be a good idea to really compare it to the tolino2
shine hd. The boards seem to look similar, but not identical. Hmm,
different number of buttons?
The question is how similar they are. I think the Kobo Glo HD has a
good driver situation.
The main PMIC RC5T619 (the rn5t618 driver supports that) is well
supported in mainline kernel. It should give regulators, RTC and battery
information.
The touchscreen (driver zforce_ts) should alse be supported. So
you might go further forward.
If you are really brave, you could add a complete devicetree on top
of my branch
kobo/drm-merged-5.10 of github.com/akemnade/linux. Besides of backlight,
it should give full hardware support (including a drm driver for the
display), so we can see what is different and whether we can use
a .dtsi file to define common things.
Picture of the Tolino2 internals:
https://misc.andi.de1.cc/tolino2.jpg
Regards,
Andreas
Re: [PATCH] dts: ARM: add kobo glo hd ebook reader
Hi,
On Tue, 26 Jan 2021 18:31:31 +0100
Armin Preiml wrote:
> This patch adds basic support for the kobo glo hd reader. It defines CPU,
> memory, UART and storage.Also add pin control settings for i2c and sdhc.
>
> All values where extracted from the vendor kernel and u-boot sources.
>
> Signed-off-by: Armin Preiml
>
> ---
> arch/arm/boot/dts/Makefile | 1 +
> arch/arm/boot/dts/imx6sl-kobo-glo-hd.dts | 164 +++
> 2 files changed, 165 insertions(+)
> create mode 100644 arch/arm/boot/dts/imx6sl-kobo-glo-hd.dts
>
> diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
> index 3d1ea0b25..ba608414e 100644
> --- a/arch/arm/boot/dts/Makefile
> +++ b/arch/arm/boot/dts/Makefile
> @@ -598,6 +598,7 @@ dtb-$(CONFIG_SOC_IMX6Q) += \
> imx6qp-zii-rdu2.dtb
> dtb-$(CONFIG_SOC_IMX6SL) += \
> imx6sl-evk.dtb \
> + imx6sl-kobo-glo-hd.dtb \
> imx6sl-tolino-shine2hd.dtb \
> imx6sl-tolino-shine3.dtb \
> imx6sl-warp.dtb
> diff --git a/arch/arm/boot/dts/imx6sl-kobo-glo-hd.dts
> b/arch/arm/boot/dts/imx6sl-kobo-glo-hd.dts
> new file mode 100644
> index 0..759699e9e
> --- /dev/null
> +++ b/arch/arm/boot/dts/imx6sl-kobo-glo-hd.dts
> @@ -0,0 +1,164 @@
> +// SPDX-License-Identifier: (GPL-2.0)
> +/*
> + * Device tree for the Kobo Glo HD ebook reader.
> + *
> + * Name on mainboard is: 37NB-E60Q90+4A1
> + * Board name in uboot sources: E60Q90
> + *
> + * Copyright 2021 Armin Preiml
> + * based on works
> + * Copyright 2015 Freescale Semiconductor, Inc.
> + */
> +
> +/dts-v1/;
> +
> +#include
> +#include
> +#include "imx6sl.dtsi"
> +
> +/ {
> + model = "Kobo Glo HD";
> + compatible = "kobo,glohd", "fsl,imx6sl";
> +
kobo,glohd should be added to
Documentation/devicetree/bindings/arm/fsl.yaml
[...]
> +pinctrl_uart1: uart1grp {
> +fsl,pins = <
> + MX6SL_PAD_UART1_TXD__UART1_TX_DATA 0x1b0b1
> + MX6SL_PAD_UART1_RXD__UART1_RX_DATA 0x1b0b1
> + >;
> + };
> +
hmm, pictures (we are talking about FCC ID NOIKBN437, right?) show two
uarts, next to each other. Which one is this?
The other uart might be the same as in the tolino2-shinehd.
> + pinctrl_usdhc1: usdhc1grp { /* 50MHZ (>50MHZ: 0x1f0f9) */
> +fsl,pins = <
> + MX6SL_PAD_SD1_CLK__SD1_CLK 0x1f071
> + MX6SL_PAD_SD1_CMD__SD1_CMD 0x1f071
> + MX6SL_PAD_SD1_DAT0__SD1_DATA0 0x1f071
> + MX6SL_PAD_SD1_DAT1__SD1_DATA1 0x1f071
> + MX6SL_PAD_SD1_DAT2__SD1_DATA2 0x1f071
> + MX6SL_PAD_SD1_DAT3__SD1_DATA3 0x1f071
> + MX6SL_PAD_SD1_DAT4__SD1_DATA4 0x1f071
> + MX6SL_PAD_SD1_DAT5__SD1_DATA5 0x1f071
> + MX6SL_PAD_SD1_DAT6__SD1_DATA6 0x1f071
> + MX6SL_PAD_SD1_DAT7__SD1_DATA7 0x1f071
> + >;
> + };
> +
That is for emmc? And it is not populated, so probably better not
enable that here.
[...]
> +&uart1 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_uart1>;
> + status = "okay";
> +};
> +
> +&usdhc1 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_usdhc1>;
> + status = "okay";
> +};
> +
and also not add this.
I guess it might be a good idea to really compare it to the tolino2
shine hd. The boards seem to look similar, but not identical. Hmm,
different number of buttons?
The question is how similar they are. I think the Kobo Glo HD has a
good driver situation.
The main PMIC RC5T619 (the rn5t618 driver supports that) is well
supported in mainline kernel. It should give regulators, RTC and battery
information.
The touchscreen (driver zforce_ts) should alse be supported. So
you might go further forward.
If you are really brave, you could add a complete devicetree on top
of my branch
kobo/drm-merged-5.10 of github.com/akemnade/linux. Besides of backlight,
it should give full hardware support (including a drm driver for the
display), so we can see what is different and whether we can use
a .dtsi file to define common things.
Picture of the Tolino2 internals:
https://misc.andi.de1.cc/tolino2.jpg
Regards,
Andreas
[PATCH] ARM: dts: imx6sl-tolino-shine2hd: Add Netronix embedded controller
For now, the driver detects an incompatible version, but since
that can be handled by auto-detection, add the controller to the
devicetree now. Only PWM seems to be available, there is no RTC
in that controller.
Signed-off-by: Andreas Kemnade
---
arch/arm/boot/dts/imx6sl-tolino-shine2hd.dts | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/imx6sl-tolino-shine2hd.dts
b/arch/arm/boot/dts/imx6sl-tolino-shine2hd.dts
index caa279608803..c26bc5e10593 100644
--- a/arch/arm/boot/dts/imx6sl-tolino-shine2hd.dts
+++ b/arch/arm/boot/dts/imx6sl-tolino-shine2hd.dts
@@ -97,8 +97,11 @@ &i2c1 {
pinctrl-1 = <&pinctrl_i2c1_sleep>;
status = "okay";
- /* TODO: embedded controller at 0x43 (driver missing) */
-
+ ec: embedded-controller@43 {
+ compatible = "netronix,ntxec";
+ reg = <0x43>;
+ #pwm-cells = <2>;
+ };
};
&i2c2 {
--
2.29.2
[PATCH] regulator: core: avoid error messages for deferred probing
Noise like this happens on boot with regulators which can be bypassed
when the supply is not probed. That looks too alarming and confusing.
[3.844092] vddpu: bypassed regulator has no supply!
[3.849105] vddpu: failed to get the current voltage: -EPROBE_DEFER
[3.855591] vddpu: supplied by DCDC1
[3.877211] vddsoc: bypassed regulator has no supply!
[3.882538] vddsoc: failed to get the current voltage: -EPROBE_DEFER
[3.888975] vddsoc: supplied by DCDC1
Handle such issues silently.
Signed-off-by: Andreas Kemnade
---
drivers/regulator/core.c | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/drivers/regulator/core.c b/drivers/regulator/core.c
index ca03d8e70bd1..238745fc97c2 100644
--- a/drivers/regulator/core.c
+++ b/drivers/regulator/core.c
@@ -1168,6 +1168,9 @@ static int machine_constraints_voltage(struct
regulator_dev *rdev,
current_uV = regulator_get_voltage_rdev(rdev);
}
+ if (current_uV == -EPROBE_DEFER)
+ return -EPROBE_DEFER;
+
if (current_uV < 0) {
rdev_err(rdev,
"failed to get the current voltage: %pe\n",
@@ -4151,9 +4154,12 @@ int regulator_get_voltage_rdev(struct regulator_dev
*rdev)
if (bypassed) {
/* if bypassed the regulator must have a supply */
if (!rdev->supply) {
+ if (rdev->supply_name)
+ return -EPROBE_DEFER;
+
rdev_err(rdev,
"bypassed regulator has no supply!\n");
- return -EPROBE_DEFER;
+ return -EINVAL;
}
return regulator_get_voltage_rdev(rdev->supply->rdev);
--
2.29.2
Re: [PATCH v7 4/7] pwm: ntxec: Add driver for PWM function in Netronix EC
On Tue, 12 Jan 2021 20:39:02 +0100
Andreas Kemnade wrote:
[...]
> > +static int ntxec_pwm_probe(struct platform_device *pdev)
> > +{
> > + struct ntxec *ec = dev_get_drvdata(pdev->dev.parent);
> > + struct ntxec_pwm *priv;
> > + struct pwm_chip *chip;
> > +
> > + priv = devm_kzalloc(&pdev->dev, sizeof(*priv), GFP_KERNEL);
> > + if (!priv)
> > + return -ENOMEM;
> > +
> > + priv->ec = ec;
> > + priv->dev = &pdev->dev;
> > +
> > + platform_set_drvdata(pdev, priv);
> > +
> > + chip = &priv->chip;
> > + chip->dev = &pdev->dev;
>
> Hmm, I needed
> chip->dev = &pdev->dev.parent to use the backlight example
> in patch 2/7.
> Not sure what the correct solution is. Maybe the pwm deserves its own
> devicetree node.
>
probably just assigning the node from the parent.
pdev->dev.of_node = pdev->dev.parent->of_node;
Regards,
Andreas
Re: [PATCH 3/4] ARM: dts: imx6sl-tolino-shine2hd: correct console uart pinmux
please ignore, that was accidentially sent.
On Wed, 13 Jan 2021 00:15:47 +0100
Andreas Kemnade wrote:
> Configuration was correct enough to work with the pre-configuration done by
> uboot. While at it, also document the location.
>
> Signed-off-by: Andreas Kemnade
> ---
> arch/arm/boot/dts/imx6sl-tolino-shine3.dts | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/arm/boot/dts/imx6sl-tolino-shine3.dts
> b/arch/arm/boot/dts/imx6sl-tolino-shine3.dts
> index 27143ea0f0f1..62d2ebda04ff 100644
> --- a/arch/arm/boot/dts/imx6sl-tolino-shine3.dts
> +++ b/arch/arm/boot/dts/imx6sl-tolino-shine3.dts
> @@ -156,7 +156,7 @@
> pinctrl_uart1: uart1grp {
> fsl,pins = <
> MX6SL_PAD_UART1_TXD__UART1_TX_DATA 0x1b0b1
> - MX6SL_PAD_UART1_RXD__UART1_TX_DATA 0x1b0b1
> + MX6SL_PAD_UART1_RXD__UART1_RX_DATA 0x1b0b1
> >;
> };
>
[PATCH 1/4] ARM: dts: imx6sl-tolino-shine2hd: correct console uart pinmux
Configuration was correct enough to work with the pre-configuration done by
uboot. While at it, also document the location.
Signed-off-by: Andreas Kemnade
---
arch/arm/boot/dts/imx6sl-tolino-shine2hd.dts | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/imx6sl-tolino-shine2hd.dts
b/arch/arm/boot/dts/imx6sl-tolino-shine2hd.dts
index caa279608803..e17c75c360f2 100644
--- a/arch/arm/boot/dts/imx6sl-tolino-shine2hd.dts
+++ b/arch/arm/boot/dts/imx6sl-tolino-shine2hd.dts
@@ -396,7 +396,7 @@
pinctrl_uart1: uart1grp {
fsl,pins = <
MX6SL_PAD_UART1_TXD__UART1_TX_DATA 0x1b0b1
- MX6SL_PAD_UART1_RXD__UART1_TX_DATA 0x1b0b1
+ MX6SL_PAD_UART1_RXD__UART1_RX_DATA 0x1b0b1
>;
};
@@ -543,6 +543,7 @@
};
&uart1 {
+ /* J4, through-holes */
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_uart1>;
status = "okay";
--
2.20.1
[PATCH 3/4] ARM: dts: imx6sl-tolino-shine3: correct console uart pinmux
Configuration was correct enough to work with the pre-configuration done by
uboot. While at it, also document the location.
Signed-off-by: Andreas Kemnade
---
arch/arm/boot/dts/imx6sl-tolino-shine3.dts | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/imx6sl-tolino-shine3.dts
b/arch/arm/boot/dts/imx6sl-tolino-shine3.dts
index 27143ea0f0f1..62d2ebda04ff 100644
--- a/arch/arm/boot/dts/imx6sl-tolino-shine3.dts
+++ b/arch/arm/boot/dts/imx6sl-tolino-shine3.dts
@@ -156,7 +156,7 @@
pinctrl_uart1: uart1grp {
fsl,pins = <
MX6SL_PAD_UART1_TXD__UART1_TX_DATA 0x1b0b1
- MX6SL_PAD_UART1_RXD__UART1_TX_DATA 0x1b0b1
+ MX6SL_PAD_UART1_RXD__UART1_RX_DATA 0x1b0b1
>;
};
--
2.20.1
[PATCH 4/4] ARM: dts: imx: e60k02: add second uart
There is another uart next to the console uart used by vendor uboot and
kernel, enable it and document its location.
Signed-off-by: Andreas Kemnade
---
arch/arm/boot/dts/e60k02.dtsi | 6 ++
arch/arm/boot/dts/imx6sl-tolino-shine3.dts | 13 -
arch/arm/boot/dts/imx6sll-kobo-clarahd.dts | 13 -
3 files changed, 30 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/e60k02.dtsi b/arch/arm/boot/dts/e60k02.dtsi
index 3af1ab4458ef..cfb239d5186a 100644
--- a/arch/arm/boot/dts/e60k02.dtsi
+++ b/arch/arm/boot/dts/e60k02.dtsi
@@ -278,6 +278,12 @@
};
&uart1 {
+ /* J4, through-hole */
+ status = "okay";
+};
+
+&uart4 {
+ /* TP198, next to J4, SMD pads */
status = "okay";
};
diff --git a/arch/arm/boot/dts/imx6sl-tolino-shine3.dts
b/arch/arm/boot/dts/imx6sl-tolino-shine3.dts
index 62d2ebda04ff..e3f1e8d79528 100644
--- a/arch/arm/boot/dts/imx6sl-tolino-shine3.dts
+++ b/arch/arm/boot/dts/imx6sl-tolino-shine3.dts
@@ -94,7 +94,6 @@
MX6SL_PAD_KEY_ROW7__GPIO4_IO07 0x79
MX6SL_PAD_ECSPI2_MOSI__GPIO4_IO13 0x79
MX6SL_PAD_KEY_COL5__GPIO4_IO02 0x79
- MX6SL_PAD_KEY_ROW6__GPIO4_IO05 0x79
>;
};
@@ -160,6 +159,13 @@
>;
};
+ pinctrl_uart4: uart4grp {
+ fsl,pins = <
+ MX6SL_PAD_KEY_ROW6__UART4_TX_DATA 0x1b0b1
+ MX6SL_PAD_KEY_COL6__UART4_RX_DATA 0x1b0b1
+ >;
+ };
+
pinctrl_usbotg1: usbotg1grp {
fsl,pins = <
MX6SL_PAD_EPDC_PWRCOM__USB_OTG1_ID 0x17059
@@ -300,6 +306,11 @@
pinctrl-0 = <&pinctrl_uart1>;
};
+&uart4 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_uart4>;
+};
+
&usdhc2 {
pinctrl-names = "default", "state_100mhz", "state_200mhz", "sleep";
pinctrl-0 = <&pinctrl_usdhc2>;
diff --git a/arch/arm/boot/dts/imx6sll-kobo-clarahd.dts
b/arch/arm/boot/dts/imx6sll-kobo-clarahd.dts
index 7214d1c98249..90b32f5eb529 100644
--- a/arch/arm/boot/dts/imx6sll-kobo-clarahd.dts
+++ b/arch/arm/boot/dts/imx6sll-kobo-clarahd.dts
@@ -104,7 +104,6 @@
MX6SLL_PAD_KEY_ROW7__GPIO4_IO07 0x79
MX6SLL_PAD_ECSPI2_MOSI__GPIO4_IO13 0x79
MX6SLL_PAD_KEY_COL5__GPIO4_IO02 0x79
- MX6SLL_PAD_KEY_ROW6__GPIO4_IO05 0x79
>;
};
@@ -170,6 +169,13 @@
>;
};
+ pinctrl_uart4: uart4grp {
+ fsl,pins = <
+ MX6SLL_PAD_KEY_ROW6__UART4_DCE_TX 0x1b0b1
+ MX6SLL_PAD_KEY_COL6__UART4_DCE_RX 0x1b0b1
+ >;
+ };
+
pinctrl_usbotg1: usbotg1grp {
fsl,pins = <
MX6SLL_PAD_EPDC_PWR_COM__USB_OTG1_ID 0x17059
@@ -302,6 +308,11 @@
pinctrl-0 = <&pinctrl_uart1>;
};
+&uart4 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_uart4>;
+};
+
&usdhc2 {
pinctrl-names = "default", "state_100mhz", "state_200mhz","sleep";
pinctrl-0 = <&pinctrl_usdhc2>;
--
2.20.1
[PATCH 3/4] ARM: dts: imx6sl-tolino-shine2hd: correct console uart pinmux
Configuration was correct enough to work with the pre-configuration done by
uboot. While at it, also document the location.
Signed-off-by: Andreas Kemnade
---
arch/arm/boot/dts/imx6sl-tolino-shine3.dts | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/imx6sl-tolino-shine3.dts
b/arch/arm/boot/dts/imx6sl-tolino-shine3.dts
index 27143ea0f0f1..62d2ebda04ff 100644
--- a/arch/arm/boot/dts/imx6sl-tolino-shine3.dts
+++ b/arch/arm/boot/dts/imx6sl-tolino-shine3.dts
@@ -156,7 +156,7 @@
pinctrl_uart1: uart1grp {
fsl,pins = <
MX6SL_PAD_UART1_TXD__UART1_TX_DATA 0x1b0b1
- MX6SL_PAD_UART1_RXD__UART1_TX_DATA 0x1b0b1
+ MX6SL_PAD_UART1_RXD__UART1_RX_DATA 0x1b0b1
>;
};
--
2.20.1
[PATCH 0/4] ARM: dts: imx: uart improvements for ebookreaders
- add second uart - correct pinmux for console uart (it was working before because of setup by uboot) - document locations on board Andreas Kemnade (4): ARM: dts: imx6sl-tolino-shine2hd: correct console uart pinmux ARM: dts: imx6sl-tolino-shine2hd: add second uart ARM: dts: imx6sl-tolino-shine3: correct console uart pinmux ARM: dts: imx: e60k02: add second uart arch/arm/boot/dts/e60k02.dtsi| 6 ++ arch/arm/boot/dts/imx6sl-tolino-shine2hd.dts | 18 -- arch/arm/boot/dts/imx6sl-tolino-shine3.dts | 15 +-- arch/arm/boot/dts/imx6sll-kobo-clarahd.dts | 13 - 4 files changed, 47 insertions(+), 5 deletions(-) -- 2.20.1
[PATCH 2/4] ARM: dts: imx6sl-tolino-shine2hd: add second uart
There is another uart next to the console uart used by vendor uboot and
kernel, enable it and document its location.
Signed-off-by: Andreas Kemnade
---
arch/arm/boot/dts/imx6sl-tolino-shine2hd.dts | 15 ++-
1 file changed, 14 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/imx6sl-tolino-shine2hd.dts
b/arch/arm/boot/dts/imx6sl-tolino-shine2hd.dts
index e17c75c360f2..6ea5f918d059 100644
--- a/arch/arm/boot/dts/imx6sl-tolino-shine2hd.dts
+++ b/arch/arm/boot/dts/imx6sl-tolino-shine2hd.dts
@@ -340,7 +340,6 @@
MX6SL_PAD_KEY_ROW7__GPIO4_IO07 0x79
MX6SL_PAD_ECSPI2_MOSI__GPIO4_IO13 0x79
MX6SL_PAD_KEY_COL5__GPIO4_IO02 0x79
- MX6SL_PAD_KEY_ROW6__GPIO4_IO05 0x79
>;
};
@@ -400,6 +399,13 @@
>;
};
+ pinctrl_uart4: uart4grp {
+ fsl,pins = <
+ MX6SL_PAD_KEY_ROW6__UART4_TX_DATA 0x1b0b1
+ MX6SL_PAD_KEY_COL6__UART4_RX_DATA 0x1b0b1
+ >;
+ };
+
pinctrl_usbotg1: usbotg1grp {
fsl,pins = <
MX6SL_PAD_EPDC_PWRCOM__USB_OTG1_ID 0x17059
@@ -549,6 +555,13 @@
status = "okay";
};
+&uart4 {
+ /* TP198, next to J4, SMD pads */
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_uart4>;
+ status = "okay";
+};
+
&usdhc2 {
pinctrl-names = "default", "state_100mhz", "state_200mhz", "sleep";
pinctrl-0 = <&pinctrl_usdhc2>;
--
2.20.1
Re: [PATCH v7 4/7] pwm: ntxec: Add driver for PWM function in Netronix EC
On Sat, 9 Jan 2021 19:02:17 +0100
Jonathan Neuschäfer wrote:
> The Netronix EC provides a PWM output which is used for the backlight
> on some ebook readers. This patches adds a driver for the PWM output.
>
> The .get_state callback is not implemented, because the PWM state can't
> be read back from the hardware.
>
> Signed-off-by: Jonathan Neuschäfer
> ---
> v7:
> - no changes
>
> v6:
> - https://lore.kernel.org/lkml/20201208011000.3060239-5-j.neuschae...@gmx.net/
> - Move period / duty cycle setting code to a function
> - Rename pwmchip_to_priv to ntxec_pwm_from_chip
> - Set period and duty cycle only before enabling the output
> - Mention that duty=0, enable=1 is assumed not to happen
> - Interleave writes to the period and duty cycle registers, to minimize the
> window of time that an inconsistent state is configured
>
> v5:
> - https://lore.kernel.org/lkml/20201201011513.1627028-5-j.neuschae...@gmx.net/
> - Avoid truncation of period and duty cycle to 32 bits
> - Make ntxec_pwm_ops const
> - Use regmap_multi_reg_write
> - Add comment about get_state to ntxec_pwm_ops
> - Add comments about non-atomicity of (period, duty cycle) update
>
> v4:
> - https://lore.kernel.org/lkml/2020112739.1455132-5-j.neuschae...@gmx.net/
> - Document hardware/driver limitations
> - Only accept normal polarity
> - Fix a typo ("zone" -> "zero")
> - change MAX_PERIOD_NS to 0x * 125
> - Clamp period to the maximum rather than returning an error
> - Rename private struct pointer to priv
> - Rearrage control flow in _probe to save a few lines and a temporary variable
> - Add missing MODULE_ALIAS line
> - Spell out ODM
>
> v3:
> - https://lore.kernel.org/lkml/20200924192455.2484005-5-j.neuschae...@gmx.net/
> - Relicense as GPLv2 or later
> - Add email address to copyright line
> - Remove OF compatible string and don't include linux/of_device.h
> - Fix bogus ?: in return line
> - Don't use a comma after sentinels
> - Avoid ret |= ... pattern
> - Move 8-bit register conversion to ntxec.h
>
> v2:
> - https://lore.kernel.org/lkml/20200905133230.1014581-6-j.neuschae...@gmx.net/
> - Various grammar and style improvements, as suggested by Uwe Kleine-König,
> Lee Jones, and Alexandre Belloni
> - Switch to regmap
> - Prefix registers with NTXEC_REG_
> - Add help text to the Kconfig option
> - Use the .apply callback instead of the old API
> - Add a #define for the time base (125ns)
> - Don't change device state in .probe; this avoids multiple problems
> - Rework division and overflow check logic to perform divisions in 32 bits
> - Avoid setting duty cycle to zero, to work around a hardware quirk
> ---
> drivers/pwm/Kconfig | 8 ++
> drivers/pwm/Makefile| 1 +
> drivers/pwm/pwm-ntxec.c | 182
> 3 files changed, 191 insertions(+)
> create mode 100644 drivers/pwm/pwm-ntxec.c
>
> diff --git a/drivers/pwm/Kconfig b/drivers/pwm/Kconfig
> index 0937e1c047acb..a2830b8832b97 100644
> --- a/drivers/pwm/Kconfig
> +++ b/drivers/pwm/Kconfig
> @@ -393,6 +393,14 @@ config PWM_MXS
> To compile this driver as a module, choose M here: the module
> will be called pwm-mxs.
>
> +config PWM_NTXEC
> + tristate "Netronix embedded controller PWM support"
> + depends on MFD_NTXEC
> + help
> + Say yes here if you want to support the PWM output of the embedded
> + controller found in certain e-book readers designed by the original
> + design manufacturer Netronix.
> +
> config PWM_OMAP_DMTIMER
> tristate "OMAP Dual-Mode Timer PWM support"
> depends on OF
> diff --git a/drivers/pwm/Makefile b/drivers/pwm/Makefile
> index 18b89d7fd092a..7d97eb595bbef 100644
> --- a/drivers/pwm/Makefile
> +++ b/drivers/pwm/Makefile
> @@ -35,6 +35,7 @@ obj-$(CONFIG_PWM_MESON) += pwm-meson.o
> obj-$(CONFIG_PWM_MEDIATEK) += pwm-mediatek.o
> obj-$(CONFIG_PWM_MTK_DISP) += pwm-mtk-disp.o
> obj-$(CONFIG_PWM_MXS)+= pwm-mxs.o
> +obj-$(CONFIG_PWM_NTXEC) += pwm-ntxec.o
> obj-$(CONFIG_PWM_OMAP_DMTIMER) += pwm-omap-dmtimer.o
> obj-$(CONFIG_PWM_PCA9685)+= pwm-pca9685.o
> obj-$(CONFIG_PWM_PXA)+= pwm-pxa.o
> diff --git a/drivers/pwm/pwm-ntxec.c b/drivers/pwm/pwm-ntxec.c
> new file mode 100644
> index 0..1db30a6caa3ad
> --- /dev/null
> +++ b/drivers/pwm/pwm-ntxec.c
> @@ -0,0 +1,182 @@
> +// SPDX-License-Identifier: GPL-2.0-or-later
> +/*
> + * The Netronix embedded controller is a microcontroller found in some
> + * e-book readers designed by the original design manufacturer Netronix, Inc.
> + * It contains RTC, battery monitoring, system power management, and PWM
> + * functionality.
> + *
> + * This driver implements PWM output.
> + *
> + * Copyright 2020 Jonathan Neuschäfer
> + *
> + * Limitations:
> + * - The get_state callback is not implemented, because the current state of
> + * the PWM output can't be read back from the hardware.
> + * - The hardware can only generate
Re: [PATCH v7 3/7] mfd: Add base driver for Netronix embedded controller
On Sat, 9 Jan 2021 19:02:16 +0100
Jonathan Neuschäfer wrote:
> The Netronix embedded controller is a microcontroller found in some
> e-book readers designed by the original design manufacturer Netronix,
> Inc. It contains RTC, battery monitoring, system power management, and
> PWM functionality.
>
> This driver implements register access and version detection.
>
> Third-party hardware documentation is available at:
>
>
> https://github.com/neuschaefer/linux/wiki/Netronix-MSP430-embedded-controller
>
> The EC supports interrupts, but the driver doesn't make use of them so
> far.
>
> Signed-off-by: Jonathan Neuschäfer
> Acked-for-MFD-by: Lee Jones
> ---
> v7:
> - Add #define for version number (suggested by Lee Jones).
>
> v6:
> - https://lore.kernel.org/lkml/20201208011000.3060239-4-j.neuschae...@gmx.net/
> - Add Lee Jones' ACK
>
> v5:
> - no changes
>
> v4:
> - https://lore.kernel.org/lkml/2020112739.1455132-4-j.neuschae...@gmx.net/
> - include asm/unaligned.h after linux/*
> - Use put_unaligned_be16 instead of open-coded big-endian packing
> - Clarify that 0x90=0xff00 causes an error in downstream kernel too
> - Add commas after non-sentinel positions
> - ntxec.h: declare structs device and regmap
> - Replace WARN_ON usage and add comments to explain errors
> - Replace dev_alert with dev_warn when the result isn't handled
> - Change subdevice registration error message to dev_err
> - Declare ntxec_reg8 as returning __be16
> - Restructure version detection code
> - Spell out ODM
>
> v3:
> - https://lore.kernel.org/lkml/20200924192455.2484005-4-j.neuschae...@gmx.net/
> - Add (EC) to CONFIG_MFD_NTXEC prompt
> - Relicense as GPLv2 or later
> - Add email address to copyright line
> - remove empty lines in ntxec_poweroff and ntxec_restart functions
> - Split long lines
> - Remove 'Install ... handler' comments
> - Make naming of struct i2c_client parameter consistent
> - Remove struct ntxec_info
> - Rework 'depends on' lines in Kconfig, hard-depend on I2C, select REGMAP_I2C
> and
> MFD_CORE
> - Register subdevices via mfd_cells
> - Move 8-bit register conversion to ntxec.h
>
> v2:
> - https://lore.kernel.org/lkml/20200905133230.1014581-4-j.neuschae...@gmx.net/
> - Add a description of the device to the patch text
> - Unify spelling as 'Netronix embedded controller'.
> 'Netronix' is the proper name of the manufacturer, but 'embedded controller'
> is just a label that I have assigned to the device.
> - Switch to regmap, avoid regmap use in poweroff and reboot handlers.
> Inspired by cf84dc0bb40f4 ("mfd: rn5t618: Make restart handler atomic safe")
> - Use a list of known-working firmware versions instead of checking for a
> known-incompatible version
> - Prefix registers with NTXEC_REG_
> - Define register values as constants
> - Various style cleanups as suggested by Lee Jones
> - Don't align = signs in struct initializers [Uwe Kleine-König]
> - Don't use dev_dbg for an error message
> - Explain sleep in poweroff handler
> - Remove (struct ntxec).client
> - Switch to .probe_new in i2c driver
> - Add .remove callback
> - Make CONFIG_MFD_NTXEC a tristate option
> ---
> drivers/mfd/Kconfig | 11 ++
> drivers/mfd/Makefile | 1 +
> drivers/mfd/ntxec.c | 216 ++
> include/linux/mfd/ntxec.h | 37 +++
> 4 files changed, 265 insertions(+)
> create mode 100644 drivers/mfd/ntxec.c
> create mode 100644 include/linux/mfd/ntxec.h
>
> diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
> index bdfce7b156216..4280bcd47ec7d 100644
> --- a/drivers/mfd/Kconfig
> +++ b/drivers/mfd/Kconfig
> @@ -976,6 +976,17 @@ config MFD_VIPERBOARD
> You need to select the mfd cell drivers separately.
> The drivers do not support all features the board exposes.
>
> +config MFD_NTXEC
> + tristate "Netronix embedded controller (EC)"
> + depends on OF || COMPILE_TEST
> + depends on I2C
> + select REGMAP_I2C
> + select MFD_CORE
> + help
> + Say yes here if you want to support the embedded controller found in
> + certain e-book readers designed by the original design manufacturer
> + Netronix.
> +
> config MFD_RETU
> tristate "Nokia Retu and Tahvo multi-function device"
> select MFD_CORE
> diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
> index 14fdb188af022..948a3bf8e3e57 100644
> --- a/drivers/mfd/Makefile
> +++ b/drivers/mfd/Makefile
> @@ -219,6 +219,7 @@ obj-$(CONFIG_MFD_INTEL_PMC_BXT) += intel_pmc_bxt.o
> obj-$(CONFIG_MFD_INTEL_PMT) += intel_pmt.o
> obj-$(CONFIG_MFD_PALMAS) += palmas.o
> obj-$(CONFIG_MFD_VIPERBOARD)+= viperboard.o
> +obj-$(CONFIG_MFD_NTXEC) += ntxec.o
> obj-$(CONFIG_MFD_RC5T583)+= rc5t583.o rc5t583-irq.o
> obj-$(CONFIG_MFD_RK808) += rk808.o
> obj-$(CONFIG_MFD_RN5T618)+= rn5t618.o
> diff --git a/drivers/mfd/ntxec.c b/drivers/mfd/ntxec.c
> new file mode 100644
> index 0..22ed2ef0669cb
> --- /d
Re: [PATCH] ARM: OMAP2+: omap_device: fix idling of devices during probe
Hi,
On Fri, 8 Jan 2021 13:17:06 -0600
Adam Ford wrote:
> On Mon, Dec 7, 2020 at 8:01 AM Tony Lindgren wrote:
> >
> > * Doug Anderson [201204 16:43]:
> > > Hi,
> > >
> > > On Fri, Dec 4, 2020 at 8:14 AM Andreas Kemnade
> > > wrote:
> > > >
> > > > > > Fixes: 21b2cec61c04 ("mmc: Set PROBE_PREFER_ASYNCHRONOUS for
> > > > > > drivers that existed in v4.4")
> > > > >
> > > > > From the description it sounds like this problem has always existed
> > > > > but the async probe just tickled it reliably. Seems like it'd make
> > > > > sense to tag the "Fixes" as some earlier commit so you make sure your
> > > > > fix gets picked to kernels even if they don't have the async probe
> > > > > patch?
> > > > >
> > > >
> > > > Hmm, maybe
> > > > Fixes: 04abaf07f6d5 ("ARM: OMAP2+: omap_device: Sync omap_device and
> > > > pm_runtime after probe defer")
> > > >
> > > > But on the other hand to stable branches only such patches are applied
> > > > which solve pratical problems not only theoretical problems. But maybe
> > > > it solves several random issues where nobody took care to debug them.
> > > >
> > > > That would be since v4.11.
> > >
> > > I guess maybe best is to include both. Then if someone is debugging
> > > why their async probe is failing they will notice this commit, but
> > > they also might decide to pick it earlier just to be safe...
> >
> > OK I'll add the above fixes tag too and apply this into fixes.
> >
>
> It might be too late, but...
>
> Tested-by: Adam Ford #logicpd-torpedo-37xx-devkit
>
hmm, when will it arrive in mainline?
Regards,
Andreas
Re: [PATCH] spi: dt-bindings: clarify CS behavior for spi-cs-high and gpio descriptors
On Wed, 9 Dec 2020 14:04:26 -0500 Sven Van Asbroeck wrote: > On Wed, Dec 9, 2020 at 1:16 PM H. Nikolaus Schaller > wrote: > > > > This is also what made me wonder if that is really intended because then > > the whole discussion about the cs-gpio-flags and inversion and the fixes > > would not have been needed. The current code and fixes are all about > > not ignoring the flags... > > The inversion you witnessed was a bug caused by spi client drivers that > simply "plow over" the SPI_CS_HIGH mode flag. This includes the panel driver > you're using, see: > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/gpu/drm/panel/panel-tpo-td028ttec1.c?h=v5.10-rc6#n337 > ah, it would be set in spi->mode and is cleared by spi->mode = SPI_MODE_3; Hmm, but we have spi-cpol; spi-cpha; in devicetree. Why do we need that spi->mode line at all? Regards, Andreas
Re: [BUG] SPI broken for SPI based panel drivers
Hi, On Sat, 5 Dec 2020 08:04:25 +0100 "H. Nikolaus Schaller" wrote: > Hi Linus, > > > Am 05.12.2020 um 01:25 schrieb Linus Walleij : > > > > On Fri, Dec 4, 2020 at 5:52 PM H. Nikolaus Schaller > > wrote: > > > >> But what I don't know is if I can omit spi-cs-high and have to keep > >> ACTIVE_HIGH (my revert patch) or also change to ACTIVE_LOW (my additional > >> patch). This is arbitrary and someone has to decide what it should be. > > (...) > >> I'd prefer if you or maybe Linus could submit such a patch and I am happy > >> to review it. > > > > It seems really ill-advised to have me do that since I have not > > managed very well to deal with this. Clearly better developers > > are needed. But I can review a patch and see if it makes me > > smarter :) Hmm, if those developers are not available, then probably finding those bugs has to be time-optimized, like establishing better automatic display testing. > > I find it interesting that so far nobody wants to take responsibility > for a decision and to write down the behaviour really should be. Coding > is the second step then. > well, the interesting people are not involved yet (DTML) because no patch is sent. > Anyways you did not cite the really important part of my mail. So let me > copy it back. Here it is again: > > > What I can do is to provide just a skeleton for the table that you or Linus > > can fix/fill in and make a patch out of it. Is attached and the ??? is > > something you should discuss and define. > > Please take the attached diff, comment it here and define the question marks > according to your intention and then make a patch for the YAML bindings out > of it. (I can't do because I don't know your intentions and what to write into > the commit message). > Well, I the easiest step forward is just to document clearer how things behave now, so the commit message is just something like "Behavior of CS signal is not clearly documented, clarify the documentation". And then send the patch to the proper mailing lists including devicetree folks. Regards, Andreas > As soon as we have settled this, we can check if code is correct and really > define if my device tree fits and which change it needs exactly. > > BR and thanks, > Nikolaus > > [slightly edited] > > diff --git a/Documentation/devicetree/bindings/spi/spi-controller.yaml > b/Documentation/devicetree/bindings/spi/spi-controller.yaml > index 1b56d5e40f1f..4f8755dabecc 100644 > --- a/Documentation/devicetree/bindings/spi/spi-controller.yaml > +++ b/Documentation/devicetree/bindings/spi/spi-controller.yaml > @@ -42,6 +42,30 @@ properties: > cs2 : &gpio1 1 0 > cs3 : &gpio1 2 0 > > + The second flag of a gpio descriptor can be GPIO_ACTIVE_HIGH/0 > + or GPIO_ACTIVE_LOW/1. > + > + There is a special rule set for combining the second flag of an > + cs-gpio with the optional spi-cs-high flag for SPI slaves. > + > + Each table entry defines how the CS pin is physically driven > + (not considering potential gpio inversions by pinmux): > + > + device node | cs-gpio | CS pin state active | Note > + +===+=+= > + spi-cs-high | - | H | > + - | - | L | > + spi-cs-high | ACTIVE_HIGH | H | > + - | ACTIVE_HIGH | L (or H ???)| 1 > + spi-cs-high | ACTIVE_LOW| H (or L ???)| 2 > + - | ACTIVE_LOW| L | > + > + Notes: > + 1) should print a warning about polarity inversion > + because here it would be wise to define the gpio as ACTIVE_LOW > + 2) could print a warning about polarity inversion > + because ACTIVE_LOW is overridden by spi-cs-high > + 3) Effectively this rule defines that the ACTIVE level of the > + gpio has to be ignored > + > num-cs: > $ref: /schemas/types.yaml#/definitions/uint32 > description: > > >
Re: [PATCH] ARM: OMAP2+: omap_device: fix idling of devices during probe
On Fri, 4 Dec 2020 07:44:33 -0800
Doug Anderson wrote:
> Hi,
>
> On Fri, Dec 4, 2020 at 1:55 AM Andreas Kemnade wrote:
> >
> > On the GTA04A5 od->_driver_status was not set to BUS_NOTIFY_BIND_DRIVER
> > during probe of the second mmc used for wifi. Therefore
> > omap_device_late_idle idled the device during probing causing oopses when
> > accessing the registers.
> >
> > It was not set because od->_state was set to OMAP_DEVICE_STATE_IDLE
> > in the notifier callback. Therefore set od->_driver_status also in that
> > case.
> >
> > This came apparent after
> > commit 21b2cec61c04 ("mmc: Set PROBE_PREFER_ASYNCHRONOUS for drivers that
> > existed in v4.4")
> > causing this oops:
> >
> > [3.179534] omap_hsmmc 480b4000.mmc: omap_device_late_idle: enabled but
> > no driver. Idling
> > [3.265594] 8<--- cut here ---
> > [3.268707] Unhandled fault: external abort on non-linefetch (0x1028) at
> > 0xfa0b402c
> > [3.276397] pgd = (ptrval)
> > [3.279144] [fa0b402c] *pgd=48011452(bad)
> > [3.283203] Internal error: : 1028 [#1] SMP ARM
> > [3.287750] Modules linked in:
> > [3.290832] CPU: 0 PID: 7 Comm: kworker/u2:0 Not tainted 5.10.0-rc6 #3
> > [3.297393] Hardware name: Generic OMAP36xx (Flattened Device Tree)
> > [3.303710] Workqueue: events_unbound async_run_entry_fn
> > [3.309082] PC is at omap_hsmmc_set_bus_width+0x8/0x78
> > [3.314239] LR is at omap_hsmmc_set_ios+0x11c/0x258
> > [3.319152] pc : []lr : []psr: 2013
> > [3.325469] sp : c10f9e00 ip : c175c800 fp : 0066
> > [3.330718] r10: c175cb80 r9 : fa0b4000 r8 :
> > [3.335968] r7 : c123e010 r6 : c175ca58 r5 : c175cb80 r4 : c175c800
> > [3.342529] r3 : 0001 r2 : 58ad940c r1 : fa0b4000 r0 : c175cb80
> > [3.349090] Flags: nzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment
> > none
> > [3.356262] Control: 10c5387d Table: 80004019 DAC: 0051
> > [3.362030] Process kworker/u2:0 (pid: 7, stack limit = 0x(ptrval))
> > [3.368347] Stack: (0xc10f9e00 to 0xc10fa000)
> > [3.372741] 9e00: c175c800 0007 c123e000 c123e010 c077b2b0
> > c175c800
> > [3.380950] 9e20: c123e000 c077c14c c175c800 c077d284 c175c800 c175c800
> > c123e000 c0799190
> > [3.389190] 9e40: c1755040 c175cb80 c123fd68 58ad940c
> > 0001 c123e010
> > [3.397430] 9e60: c0edaec8 c0edaec8 0006
> > e000 c0666728
> > [3.405639] 9e80: c123e010 c0f38c28 c0f38c30 c066457c
> > c123e010 c0edaec8
> > [3.413879] 9ea0: c06649bc c0e051c8 c0efa4a0 c06648b8
> > c10f9ef4
> > [3.422119] 9ec0: c06649bc c066298c c1039e6c c1653738 58ad940c
> > c123e010 c123e010
> > [3.430328] 9ee0: c0e051c8 c123e054 c100f000 c0663e60 c0e03d00 c123e010
> > 00010101 58ad940c
> > [3.438568] 9f00: c12642d0 c0f02018 c12642c0 c015da48 c12642d0 c10bbf00
> > c1009400 c100f000
> > [3.446807] 9f20: c0153b74 c10bc800 c1009400 0088 c10bbf00
> > c10bbf14 c1009400
> > [3.455017] 9f40: 0088 c1009418 c0e03d00 c1009400 e000 c0153eec
> > e000
> > [3.463256] 9f60: c10bbf00 c10b1ac0 c10b1c40 c10f8000 c0153ec0
> > c10bbf00 c10ebe94
> > [3.471466] 9f80: c10b1ae4 c015a9ac 0001 c10b1c40 c015a87c
> >
> > [3.479705] 9fa0: c0100168
> >
> > [3.487945] 9fc0:
> >
> > [3.496154] 9fe0: 0013
> >
> > [3.504394] [] (omap_hsmmc_set_bus_width) from []
> > (omap_hsmmc_set_ios+0x11c/0x258)
> > [3.513763] [] (omap_hsmmc_set_ios) from []
> > (mmc_power_up.part.8+0x3c/0xd0)
> > [3.522521] [] (mmc_power_up.part.8) from []
> > (mmc_start_host+0x88/0x9c)
> > [3.530944] [] (mmc_start_host) from []
> > (mmc_add_host+0x58/0x84)
> > [3.538726] [] (mmc_add_host) from []
> > (omap_hsmmc_probe+0x5fc/0x8c0)
> > [3.546874] [] (omap_hsmmc_probe) from []
> > (platform_drv_probe+0x48/0x98)
> > [3.555358] [] (platform_drv_probe) from []
> > (really_probe+0x1dc/0x3b4)
> > [3.563690] [] (really_probe) from []
> > (driver_probe_device+0x58/0xb4)
> > [3.571929] [] (driver_probe_device) from []
> >
[PATCH] power: bq27xxx: fix polarity of current_now
current_now has to be negative during discharging and positive during
charging, the behavior seen is the other way round.
Tested on GTA04 with Openmoko battery
Signed-off-by: Andreas Kemnade
---
drivers/power/supply/bq27xxx_battery.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/power/supply/bq27xxx_battery.c
b/drivers/power/supply/bq27xxx_battery.c
index 315e0909e6a4..3ecc18b01d49 100644
--- a/drivers/power/supply/bq27xxx_battery.c
+++ b/drivers/power/supply/bq27xxx_battery.c
@@ -1789,7 +1789,7 @@ static int bq27xxx_battery_current(struct
bq27xxx_device_info *di,
if (di->opts & BQ27XXX_O_ZERO) {
flags = bq27xxx_read(di, BQ27XXX_REG_FLAGS, true);
- if (flags & BQ27000_FLAG_CHGS) {
+ if (!(flags & BQ27000_FLAG_CHGS)) {
dev_dbg(di->dev, "negative current!\n");
curr = -curr;
}
@@ -1797,7 +1797,7 @@ static int bq27xxx_battery_current(struct
bq27xxx_device_info *di,
val->intval = curr * BQ27XXX_CURRENT_CONSTANT / BQ27XXX_RS;
} else {
/* Other gauges return signed value */
- val->intval = (int)((s16)curr) * 1000;
+ val->intval = -(int)((s16)curr) * 1000;
}
return 0;
--
2.20.1
[PATCH] ARM: OMAP2+: omap_device: fix idling of devices during probe
On the GTA04A5 od->_driver_status was not set to BUS_NOTIFY_BIND_DRIVER
during probe of the second mmc used for wifi. Therefore
omap_device_late_idle idled the device during probing causing oopses when
accessing the registers.
It was not set because od->_state was set to OMAP_DEVICE_STATE_IDLE
in the notifier callback. Therefore set od->_driver_status also in that
case.
This came apparent after
commit 21b2cec61c04 ("mmc: Set PROBE_PREFER_ASYNCHRONOUS for drivers that
existed in v4.4")
causing this oops:
[3.179534] omap_hsmmc 480b4000.mmc: omap_device_late_idle: enabled but no
driver. Idling
[3.265594] 8<--- cut here ---
[3.268707] Unhandled fault: external abort on non-linefetch (0x1028) at
0xfa0b402c
[3.276397] pgd = (ptrval)
[3.279144] [fa0b402c] *pgd=48011452(bad)
[3.283203] Internal error: : 1028 [#1] SMP ARM
[3.287750] Modules linked in:
[3.290832] CPU: 0 PID: 7 Comm: kworker/u2:0 Not tainted 5.10.0-rc6 #3
[3.297393] Hardware name: Generic OMAP36xx (Flattened Device Tree)
[3.303710] Workqueue: events_unbound async_run_entry_fn
[3.309082] PC is at omap_hsmmc_set_bus_width+0x8/0x78
[3.314239] LR is at omap_hsmmc_set_ios+0x11c/0x258
[3.319152] pc : []lr : []psr: 2013
[3.325469] sp : c10f9e00 ip : c175c800 fp : 0066
[3.330718] r10: c175cb80 r9 : fa0b4000 r8 :
[3.335968] r7 : c123e010 r6 : c175ca58 r5 : c175cb80 r4 : c175c800
[3.342529] r3 : 0001 r2 : 58ad940c r1 : fa0b4000 r0 : c175cb80
[3.349090] Flags: nzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment none
[3.356262] Control: 10c5387d Table: 80004019 DAC: 0051
[3.362030] Process kworker/u2:0 (pid: 7, stack limit = 0x(ptrval))
[3.368347] Stack: (0xc10f9e00 to 0xc10fa000)
[3.372741] 9e00: c175c800 0007 c123e000 c123e010 c077b2b0
c175c800
[3.380950] 9e20: c123e000 c077c14c c175c800 c077d284 c175c800 c175c800
c123e000 c0799190
[3.389190] 9e40: c1755040 c175cb80 c123fd68 58ad940c
0001 c123e010
[3.397430] 9e60: c0edaec8 c0edaec8 0006
e000 c0666728
[3.405639] 9e80: c123e010 c0f38c28 c0f38c30 c066457c
c123e010 c0edaec8
[3.413879] 9ea0: c06649bc c0e051c8 c0efa4a0 c06648b8
c10f9ef4
[3.422119] 9ec0: c06649bc c066298c c1039e6c c1653738 58ad940c
c123e010 c123e010
[3.430328] 9ee0: c0e051c8 c123e054 c100f000 c0663e60 c0e03d00 c123e010
00010101 58ad940c
[3.438568] 9f00: c12642d0 c0f02018 c12642c0 c015da48 c12642d0 c10bbf00
c1009400 c100f000
[3.446807] 9f20: c0153b74 c10bc800 c1009400 0088 c10bbf00
c10bbf14 c1009400
[3.455017] 9f40: 0088 c1009418 c0e03d00 c1009400 e000 c0153eec
e000
[3.463256] 9f60: c10bbf00 c10b1ac0 c10b1c40 c10f8000 c0153ec0
c10bbf00 c10ebe94
[3.471466] 9f80: c10b1ae4 c015a9ac 0001 c10b1c40 c015a87c
[3.479705] 9fa0: c0100168
[3.487945] 9fc0:
[3.496154] 9fe0: 0013
[3.504394] [] (omap_hsmmc_set_bus_width) from []
(omap_hsmmc_set_ios+0x11c/0x258)
[3.513763] [] (omap_hsmmc_set_ios) from []
(mmc_power_up.part.8+0x3c/0xd0)
[3.522521] [] (mmc_power_up.part.8) from []
(mmc_start_host+0x88/0x9c)
[3.530944] [] (mmc_start_host) from []
(mmc_add_host+0x58/0x84)
[3.538726] [] (mmc_add_host) from []
(omap_hsmmc_probe+0x5fc/0x8c0)
[3.546874] [] (omap_hsmmc_probe) from []
(platform_drv_probe+0x48/0x98)
[3.555358] [] (platform_drv_probe) from []
(really_probe+0x1dc/0x3b4)
[3.563690] [] (really_probe) from []
(driver_probe_device+0x58/0xb4)
[3.571929] [] (driver_probe_device) from []
(bus_for_each_drv+0x7c/0xc4)
[3.580505] [] (bus_for_each_drv) from []
(__device_attach_async_helper+0xa4/0xd8)
[3.589874] [] (__device_attach_async_helper) from []
(async_run_entry_fn+0x3c/0x1)
[3.599487] [] (async_run_entry_fn) from []
(process_one_work+0x228/0x574)
[3.608154] [] (process_one_work) from []
(worker_thread+0x2c/0x5d0)
[3.616302] [] (worker_thread) from []
(kthread+0x130/0x144)
[3.623748] [] (kthread) from []
(ret_from_fork+0x14/0x2c)
Fixes: 21b2cec61c04 ("mmc: Set PROBE_PREFER_ASYNCHRONOUS for drivers that
existed in v4.4")
Signed-off-by: Andreas Kemnade
---
arch/arm/mach-omap2/omap_device.c | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_device.c
b/arch/arm/mach-omap2/omap_device.c
index fc7bb2ca1672..13adf88d472b 100644
--- a/arch/arm/mach-omap2/omap_device.c
+++ b/arch/arm/mach-omap2/omap_device.c
@@ -230,10 +230,12 @@ static int _omap_device_notifier_call(struct
notifier_block *nb,
[PATCH] ARM: imx_v6_v7_defconfig: enable power driver of RN5T618 PMIC family
There is a driver now for the power supply and fuel gauge functionality of that chip family, so enable them, since they are used by various i.MX6 boards, especially ebook-readers. Signed-off-by: Andreas Kemnade --- arch/arm/configs/imx_v6_v7_defconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm/configs/imx_v6_v7_defconfig b/arch/arm/configs/imx_v6_v7_defconfig index 221f5c340c86..70928cc48939 100644 --- a/arch/arm/configs/imx_v6_v7_defconfig +++ b/arch/arm/configs/imx_v6_v7_defconfig @@ -222,6 +222,7 @@ CONFIG_POWER_RESET=y CONFIG_POWER_RESET_SYSCON=y CONFIG_POWER_RESET_SYSCON_POWEROFF=y CONFIG_POWER_SUPPLY=y +CONFIG_RN5T618_POWER=m CONFIG_SENSORS_MC13783_ADC=y CONFIG_SENSORS_GPIO_FAN=y CONFIG_SENSORS_IIO_HWMON=y -- 2.20.1
[PATCH] ARM: omap2plus_defconfig: enable SPI GPIO
GTA04 uses that for controlling the td028ttec1 panel. So for easier testing/bisecting it is useful to have it enabled in the defconfig. Signed-off-by: Andreas Kemnade --- arch/arm/configs/omap2plus_defconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm/configs/omap2plus_defconfig b/arch/arm/configs/omap2plus_defconfig index 77716f500813..904a8757ad9f 100644 --- a/arch/arm/configs/omap2plus_defconfig +++ b/arch/arm/configs/omap2plus_defconfig @@ -280,6 +280,7 @@ CONFIG_SERIAL_OMAP_CONSOLE=y CONFIG_SERIAL_DEV_BUS=y CONFIG_I2C_CHARDEV=y CONFIG_SPI=y +CONFIG_SPI_GPIO=m CONFIG_SPI_OMAP24XX=y CONFIG_SPI_TI_QSPI=m CONFIG_HSI=m -- 2.20.1
Re: [Letux-kernel] [BUG] SPI broken for SPI based panel drivers
On Tue, 1 Dec 2020 11:10:49 -0500 Sven Van Asbroeck wrote: > Nikolaus, > > On Tue, Dec 1, 2020 at 9:38 AM H. Nikolaus Schaller > wrote: > > > > Let's work on a fix for the fix now. > > > > Are you quite sure the chip-select of the tpo,td028ttec1 panel > is active-high? A quick google produced a datasheet which > seems to indicate that XCS is active-low? > Schematics is here: https://projects.goldelico.com/p/gta04-main/downloads/48/ The display connector P204-LCD indicates some inversion at the XCS and XRES pins. This patch fixes things for a boot where the display was not touched by the bootloader diff --git a/arch/arm/boot/dts/omap3-gta04.dtsi b/arch/arm/boot/dts/omap3-gta04.dtsi index c8745bc800f7..003202d12990 100644 --- a/arch/arm/boot/dts/omap3-gta04.dtsi +++ b/arch/arm/boot/dts/omap3-gta04.dtsi @@ -124,7 +124,6 @@ spi-max-frequency = <10>; spi-cpol; spi-cpha; - spi-cs-high; backlight= <&backlight>; label = "lcd"; So if that one is really active-low, why did it ever work?! Regards, Andreas
[PATCH] ARM: dts: omap3-gta04: fix twl4030-power settings
Things are wired up for powersaving, so lets use the corresponding
compatible and also update a deprecated property name.
Signed-off-by: Andreas Kemnade
---
arch/arm/boot/dts/omap3-gta04.dtsi | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/omap3-gta04.dtsi
b/arch/arm/boot/dts/omap3-gta04.dtsi
index c8745bc800f7..cbe9ce739170 100644
--- a/arch/arm/boot/dts/omap3-gta04.dtsi
+++ b/arch/arm/boot/dts/omap3-gta04.dtsi
@@ -489,8 +489,8 @@
};
twl_power: power {
- compatible = "ti,twl4030-power";
- ti,use_poweroff;
+ compatible = "ti,twl4030-power-idle";
+ ti,system-power-controller;
};
};
};
--
2.20.1
Re: [PATCH] regulator: ti-abb: Fix array out of bound read access on the first transition
Hi,
On Wed, 18 Nov 2020 08:50:09 -0600
Nishanth Menon wrote:
> At the start of driver initialization, we do not know what bias
> setting the bootloader has configured the system for and we only know
> for certain the very first time we do a transition.
>
> However, since the initial value of the comparison index is -EINVAL,
> this negative value results in an array out of bound access on the
> very first transition.
>
> Since we don't know what the setting is, we just set the bias
> configuration as there is nothing to compare against. This prevents
> the array out of bound access.
>
> NOTE: Even though we could use a more relaxed check of "< 0" the only
> valid values(ignoring cosmic ray induced bitflips) are -EINVAL, 0+.
>
> Fixes: 40b1936efebd ("regulator: Introduce TI Adaptive Body Bias(ABB) on-chip
> LDO driver")
> Link:
> https://lore.kernel.org/linux-mm/ca+g9fyuk4imvhycn7d7t6pmdh6onp6hdcritukmq6qxxjba...@mail.gmail.com/
> Reported-by: Naresh Kamboju
> Reviewed-by: Arnd Bergmann
> Signed-off-by: Nishanth Menon
> ---
>
> Mark,
>
> I will leave it to your descretion if this needs to be tagged for
> stable or to drop the Fixes tag - Side effect, if this occurs, will be
> an unstable system very hard to track down - but typically occurring
> during system boot - Impacts systems: DM3/OMAP3,4,5,DRA7/AM5x.
>
> I would categorize this as "This could be a problem..." problem..
> the bug is an out of bound read, and has been around since v3.11 and is
> not a catastrophic data corruption kind of issue.
>
> Though theoretically, there is a possibility that the compare may
> pass and result in missing bias configuration(and resulting system
> will be unstable), I have'nt heard of actual report (but, it will be
> surprising if any actual instability was actually tracked down to this
> bug). Any ways, I had to go to git full history to pick the exact
> commit - I have left it in the patch.
>
>
Hmm so probably these boot problems which only occur when your debug
cable is not attached?
Is there any connection with commits like this:
ARM: dts: omap36xx: using OPP1G needs to control the abb_ldo
So would the potential problem be more probable by patches like the
that one mentioned above?
Regards,
Andreas
Re: [PATCH v3] applesmc: Re-work SMC comms
On Sun, 8 Nov 2020 11:14:29 +0100
Henrik Rydberg wrote:
> On Sun, Nov 08, 2020 at 09:35:28AM +0100, Henrik Rydberg wrote:
> > Hi Brad,
> >
> > On 2020-11-08 02:00, Brad Campbell wrote:
> > > G'day Henrik,
> > >
> > > I noticed you'd also loosened up the requirement for SMC_STATUS_BUSY in
> > > read_smc(). I assume
> > > that causes problems on the early Macbook. This is revised on the one
> > > sent earlier.
> > > If you could test this on your Air1,1 it'd be appreciated.
> >
> > No, I managed to screw up the patch; you can see that I carefully added the
> > same treatment for the read argument, being unsure if the BUSY state would
> > remain during the AVAILABLE data phase. I can check that again, but
> > unfortunately the patch in this email shows the same problem.
> >
> > I think it may be worthwhile to rethink the behavior of wait_status() here.
> > If one machine shows no change after a certain status bit change, then
> > perhaps the others share that behavior, and we are waiting in vain. Just
> > imagine how many years of cpu that is, combined. ;-)
>
> Here is a modification along that line.
>
> Compared to your latest version, this one has wait_status() return the
> actual status on success. Instead of waiting for BUSY, it waits for
> the other status bits, and checks BUSY afterwards. So as not to wait
> unneccesarily, the udelay() is placed together with the single
> outb(). The return value of send_byte_data() is augmented with
> -EAGAIN, which is then used in send_command() to create the resend
> loop.
>
> I reach 41 reads per second on the MBA1,1 with this version, which is
> getting close to the performance prior to the problems.
>
> From b4405457f4ba07cff7b7e4f48c47668bee176a25 Mon Sep 17 00:00:00 2001
> From: Brad Campbell
> Date: Sun, 8 Nov 2020 12:00:03 +1100
> Subject: [PATCH] hwmon: (applesmc) Re-work SMC comms
>
> Commit fff2d0f701e6 ("hwmon: (applesmc) avoid overlong udelay()")
> introduced an issue whereby communication with the SMC became
> unreliable with write errors like :
>
> [ 120.378614] applesmc: send_byte(0x00, 0x0300) fail: 0x40
> [ 120.378621] applesmc: LKSB: write data fail
> [ 120.512782] applesmc: send_byte(0x00, 0x0300) fail: 0x40
> [ 120.512787] applesmc: LKSB: write data fail
>
> The original code appeared to be timing sensitive and was not reliable
> with the timing changes in the aforementioned commit.
>
> This patch re-factors the SMC communication to remove the timing
> dependencies and restore function with the changes previously
> committed.
>
> Tested on : MacbookAir6,2 MacBookPro11,1 iMac12,2, MacBookAir1,1,
> MacBookAir3,1
>
> Fixes: fff2d0f701e6 ("hwmon: (applesmc) avoid overlong udelay()")
> Reported-by: Andreas Kemnade
> Tested-by: Andreas Kemnade # MacBookAir6,2
> Acked-by: Arnd Bergmann
> Signed-off-by: Brad Campbell
> Signed-off-by: Henrik Rydberg
>
> ---
> Changelog :
> v1 : Inital attempt
> v2 : Address logic and coding style
> v3 : Removed some debug hangover. Added tested-by. Modifications for
> MacBookAir1,1
> v4 : Do not expect busy state to appear without other state changes
>
still works here (MacBookAir6,2)
Regards,
Andreas
[REGRESSION] opp: Allow dev_pm_opp_get_opp_table() to return -EPROBE_DEFER
Hi, On the GTA04 (DM3730, devicetree omap3-gta04*) I get my console flooded up with the following: [ 24.517211] cpu cpu0: multiple regulators are not supported [ 24.523040] cpufreq: __target_index: Failed to change cpu frequency: -22 [ 24.537231] [ cut here ] [ 24.542083] WARNING: CPU: 0 PID: 5 at drivers/opp/core.c:678 dev_pm_opp_set_rate+0x23c/0x494 [ 24.551086] Modules linked in: usb_f_ecm g_ether usb_f_rndis u_ether libcomposite configfs phy_twl4030_usb omap2430 musb_hdrc overlay [ 24.563842] CPU: 0 PID: 5 Comm: kworker/0:0 Tainted: GW 5.9.0-rc1-8-g629238068eb9 #14 [ 24.573852] Hardware name: Generic OMAP36xx (Flattened Device Tree) [ 24.580413] Workqueue: events dbs_work_handler [ 24.585083] [] (unwind_backtrace) from [] (show_stack+0x10/0x14) [ 24.593200] [] (show_stack) from [] (dump_stack+0x8c/0xac) [ 24.600769] [] (dump_stack) from [] (__warn+0xcc/0xe4) [ 24.608001] [] (__warn) from [] (warn_slowpath_fmt+0x74/0xa0) [ 24.615844] [] (warn_slowpath_fmt) from [] (dev_pm_opp_set_rate+0x23c/0x494) [ 24.625061] [] (dev_pm_opp_set_rate) from [] (set_target+0x2c/0x4c) [ 24.633453] [] (set_target) from [] (__cpufreq_driver_target+0x190/0x22c) [ 24.642395] [] (__cpufreq_driver_target) from [] (od_dbs_update+0xcc/0x158) [ 24.651489] [] (od_dbs_update) from [] (dbs_work_handler+0x2c/0x54) [ 24.659881] [] (dbs_work_handler) from [] (process_one_work+0x210/0x358) [ 24.668731] [] (process_one_work) from [] (worker_thread+0x22c/0x2d0) [ 24.677307] [] (worker_thread) from [] (kthread+0x140/0x14c) [ 24.685058] [] (kthread) from [] (ret_from_fork+0x14/0x2c) [ 24.692626] Exception stack(0xde4b7fb0 to 0xde4b7ff8) [ 24.697906] 7fa0: [ 24.706481] 7fc0: [ 24.715057] 7fe0: 0013 [ 24.722198] ---[ end trace 038b3f231fae6f81 ]--- endlessly after the $subject commit. Any hints? Regards, Andreas
Re: [PATCH] applesmc: Re-work SMC comms v2
On Thu, 5 Nov 2020 08:56:04 +0100 Henrik Rydberg wrote: > Hi Brad, > > Great to see this effort, it is certainly an area which could be > improved. After having seen several generations of Macbooks while > modifying much of that code, it became clear that the SMC communication > got refreshed a few times over the years. Every tiny change had to be > tested on all machines, or kept separate for a particular generation, or > something would break. > > I have not followed the back story here, but I imagine the need has > arisen because of a new refresh, and so this patch only needs to > strictly apply to a new generation. I would therefore advice that you > write the patch in that way, reducing the actual change to zero for > earlier generations. It also makes it easier to test the effect of the > new approach on older systems. I should be able to help testing on a > 2008 and 2011 model once we get to that stage. > Well, the issue has arisen because of a change in kernel to make clang happy. So it is not a new Apple device causing trouble. Regards, Andreas
Re: [PATCH] applesmc: Re-work SMC comms v2
On Thu, 5 Nov 2020 18:26:24 +1100
Brad Campbell wrote:
> Commit fff2d0f701e6 ("hwmon: (applesmc) avoid overlong udelay()") introduced
> an issue whereby communication with the SMC became unreliable with write
> errors like :
>
> [ 120.378614] applesmc: send_byte(0x00, 0x0300) fail: 0x40
> [ 120.378621] applesmc: LKSB: write data fail
> [ 120.512782] applesmc: send_byte(0x00, 0x0300) fail: 0x40
> [ 120.512787] applesmc: LKSB: write data fail
>
> The original code appeared to be timing sensitive and was not reliable with
> the timing changes in the aforementioned commit.
>
> This patch re-factors the SMC communication to remove the timing
> dependencies and restore function with the changes previously committed.
>
> v2 : Address logic and coding style
>
> Reported-by: Andreas Kemnade
> Fixes: fff2d0f701e6 ("hwmon: (applesmc) avoid overlong udelay()")
> Signed-off-by: Brad Campbell
>
Still works here:
Tested-by: Andreas Kemnade # MacBookAir6,2
Re: [REGRESSION] hwmon: (applesmc) avoid overlong udelay()
On Tue, 3 Nov 2020 16:56:32 +1100 Brad Campbell wrote: > On 3/11/20 10:56 am, Brad Campbell wrote: > > > > > I've examined the code in VirtualSMC and I'm not convinced we were not > > waiting on the wrong bits. > > > > #define SMC_STATUS_AWAITING_DATA BIT0 ///< Ready to read data. > > #define SMC_STATUS_IB_CLOSED BIT1 /// A write is pending. > > #define SMC_STATUS_BUSY BIT2 ///< Busy processing a command. > > #define SMC_STATUS_GOT_COMMAND BIT3 ///< The last input was a command. > > #define SMC_STATUS_UKN_0x16 BIT4 > > #define SMC_STATUS_KEY_DONE BIT5 > > #define SMC_STATUS_READY BIT6 // Ready to work > > #define SMC_STATUS_UKN_0x80 BIT7 // error > > > > Any chance you could try this patch? It's ugly, hacked together and > > currently fairly undocumented, but if it works I'll figure out how to clean > > it up (suggestions welcome). > > It works on my MacbookPro 11,1. > > I had some time so I spent a bit of time refactoring and trying to clarify > the magic numbers. > > I also did some fuzzing of the SMC and figured out where we can loosen the > masks. > This has some debug code in it to identify if any wait loops exceed 1 loop > and if the SMC is reporting anything other than a clear "I'm waiting" prior > to each command. > > You might see some of these : > [ 51.316202] applesmc: wait_status looping 2: 0x44, 0x40, 0x4e > [ 60.002547] applesmc: wait_status looping 2: 0x44, 0x40, 0x4e > [ 60.130754] applesmc: wait_status looping 2: 0x44, 0x40, 0x4e > > I did some heavy tests and found that with the delays at the bottom of the > loop about 50% of calls required no delay at all before a read or write and > the other 50% require a single delay. > I can count on one hand the number of times it's exceeded 1 loop, and the max > thus far has been 5 loops. > That matches my experience. The only delay is at the end of the command. Critcal seems to be that there is not too much delay in between. [...] > If anyone with a Mac having a conventional SMC and seeing issues on 5.9 could > test this it'd be appreciated. I'm not saying this code is "correct", but it > "works for me". > Seems to work here. dmesg | grep applesmc [1.350782] applesmc: key=561 fan=1 temp=33 index=33 acc=0 lux=2 kbd=1 [1.350922] applesmc applesmc.768: hwmon_device_register() is deprecated. Please convert the driver to use hwmon_device_register_with_info(). [ 17.748504] applesmc: wait_status looping 2: 0x4a, 0x4c, 0x4f [ 212.008952] applesmc: wait_status looping 2: 0x44, 0x40, 0x4e [ 213.033930] applesmc: wait_status looping 2: 0x44, 0x40, 0x4e [ 213.167908] applesmc: wait_status looping 2: 0x44, 0x40, 0x4e [ 219.087854] applesmc: wait_status looping 2: 0x44, 0x40, 0x4e Tested it on top of 5.9 Regards, Andreas
Re: [REGRESSION] hwmon: (applesmc) avoid overlong udelay()
On Thu, 1 Oct 2020 21:07:51 -0700
Guenter Roeck wrote:
> On 10/1/20 3:22 PM, Andreas Kemnade wrote:
> > On Wed, 30 Sep 2020 22:00:09 +0200
> > Arnd Bergmann wrote:
> >
> >> On Wed, Sep 30, 2020 at 6:44 PM Guenter Roeck wrote:
> >>>
> >>> On Wed, Sep 30, 2020 at 10:54:42AM +0200, Andreas Kemnade wrote:
> >>>> Hi,
> >>>>
> >>>> after the $subject patch I get lots of errors like this:
> >>>
> >>> For reference, this refers to commit fff2d0f701e6 ("hwmon: (applesmc)
> >>> avoid overlong udelay()").
> >>>
> >>>> [ 120.378614] applesmc: send_byte(0x00, 0x0300) fail: 0x40
> >>>> [ 120.378621] applesmc: LKSB: write data fail
> >>>> [ 120.512782] applesmc: send_byte(0x00, 0x0300) fail: 0x40
> >>>> [ 120.512787] applesmc: LKSB: write data fail
> >>>>
> >>>> CPU sticks at low speed and no fan is turning on.
> >>>> Reverting this patch on top of 5.9-rc6 solves this problem.
> >>>>
> >>>> Some information from dmidecode:
> >>>>
> >>>> Base Board Information
> >>>> Manufacturer: Apple Inc.
> >>>> Product Name: Mac-7DF21CB3ED6977E5
> >>>> Version: MacBookAir6,2
> >>>>
> >>>> Handle 0x0020, DMI type 11, 5 bytes OEM Strings String 1: Apple
> >>>> ROM Version. Model: …,
> >>>> Handle 0x0020, DMI type 11, 5 bytes
> >>>> OEM Strings
> >>>> String 1: Apple ROM Version. Model:MBA61. EFI Version:
> >>>> 122.0.0
> >>>> String 2: .0.0. Built by: root@saumon. Date: Wed
> >>>> Jun 10 18:
> >>>> String 3: 10:36 PDT 2020. Revision: 122 (B&I). ROM
> >>>> Version: F000_B
> >>>> String 4: 00. Build Type: Official Build, Release. Compiler:
> >>>> Appl
> >>>> String 5: e clang version 3.0 (tags/Apple/clang-211.10.1) (based
> >>>> on LLVM
> >>>> String 6: 3.0svn).
> >>>>
> >>>> Writing to things in /sys/devices/platform/applesmc.768 gives also the
> >>>> said errors.
> >>>> But writing 1 to fan1_maunal and 5000 to fan1_output turns the fan on
> >>>> despite error messages.
> >>>>
> >>> Not really sure what to do here. I could revert the patch, but then we'd
> >>> gain
> >>> clang compile failures. Arnd, any idea ?
> >>
> >> It seems that either I made a mistake in the conversion and it sleeps for
> >> less time than before, or my assumption was wrong that converting a delay
> >> to
> >> a sleep is safe here.
> >>
> >> The error message indicates that the write fails, not the read, so that
> >> is what I'd look at first. Right away I can see that the maximum time to
> >> retry is only half of what it used to be, as we used to wait for
> >> 0x10, 0x20, 0x40, 0x80, ..., 0x2 microseconds for a total of
> >> 0x3fff0 microseconds (262ms), while my patch went with the 131ms
> >> total delay based on the comment saying "/* wait up to 128 ms for a
> >> status change. */".
> >>
> > Yes, that is also what I read from the code. I just thought there must
> > be something simple, which just needs a short look from another pair of
> > eyes.
> >
> >> Since there is sleeping wait, I see no reason the timeout couldn't
> >> be extended a lot, e.g. to a second, as in
> >>
> >> #define APPLESMC_MAX_WAIT 0x10
> >>
> >> If that doesn't work, I'd try using mdelay() in place of
> >> usleep_range(), such as
> >>
> >>mdelay(DIV_ROUND_UP(us, USEC_PER_MSEC)));
> >>
> >> This adds back a really nasty latency, but it should avoid the
> >> compile-time problem.
> >>
> >> Andreas, can you try those two things? (one at a time,
> >> not both)
> >
> > Ok, I tried. None of them works. I rechecked my work and created real
> > git commits out of them and CONFIG_LOCALVERSION_AUTO is also set so
> > the usual stupid things are rules out.
> > In detail:
> > On top of 5.9-rc6 + *reverted* patch:
> > diff --git a/drivers/hwmon/applesmc.c b/drivers/hwmon/applesmc.c
> > index fd99c9df8a00..2a9bd7f2b71b 10
Re: [PATCHv1] power: supply: document current direction
On Thu, 27 Aug 2020 16:02:48 +0200 Sebastian Reichel wrote: > Currently the sign for CURRENT_NOW and CURRENT_AVG is a bit > of a mess. There are basically 3 different ways battery fuel > gauges report the current: > > 1. uses negative values for discharging and positive values >for charging > 2. uses positive values for discharging and negative values >for discharging (opposit of 1) > 3. only uses positive values > > As a result userspace currently cannot use the sign at all in > a generic way. Let's solve the issue by documenting a canonical > way for reporting the data and ensure new drivers follow this > way. Then existing drivers can be fixed on a case-by-case basis. > > The 'negative value = battery discharging' has been choosen, > since there are only very few drivers doing it the other way > around. > > Signed-off-by: Sebastian Reichel > --- would be nice if this comes in, so that is it clearly specified. Regards, Andreas
Re: [REGRESSION] hwmon: (applesmc) avoid overlong udelay()
On Wed, 30 Sep 2020 22:00:09 +0200
Arnd Bergmann wrote:
> On Wed, Sep 30, 2020 at 6:44 PM Guenter Roeck wrote:
> >
> > On Wed, Sep 30, 2020 at 10:54:42AM +0200, Andreas Kemnade wrote:
> > > Hi,
> > >
> > > after the $subject patch I get lots of errors like this:
> >
> > For reference, this refers to commit fff2d0f701e6 ("hwmon: (applesmc)
> > avoid overlong udelay()").
> >
> > > [ 120.378614] applesmc: send_byte(0x00, 0x0300) fail: 0x40
> > > [ 120.378621] applesmc: LKSB: write data fail
> > > [ 120.512782] applesmc: send_byte(0x00, 0x0300) fail: 0x40
> > > [ 120.512787] applesmc: LKSB: write data fail
> > >
> > > CPU sticks at low speed and no fan is turning on.
> > > Reverting this patch on top of 5.9-rc6 solves this problem.
> > >
> > > Some information from dmidecode:
> > >
> > > Base Board Information
> > > Manufacturer: Apple Inc.
> > > Product Name: Mac-7DF21CB3ED6977E5
> > > Version: MacBookAir6,2
> > >
> > > Handle 0x0020, DMI type 11, 5 bytes OEM Strings String 1: Apple
> > > ROM Version. Model: …,
> > > Handle 0x0020, DMI type 11, 5 bytes
> > > OEM Strings
> > > String 1: Apple ROM Version. Model:MBA61. EFI Version:
> > > 122.0.0
> > > String 2: .0.0. Built by: root@saumon. Date: Wed
> > > Jun 10 18:
> > > String 3: 10:36 PDT 2020. Revision: 122 (B&I). ROM Version:
> > > F000_B
> > > String 4: 00. Build Type: Official Build, Release. Compiler:
> > >Appl
> > > String 5: e clang version 3.0 (tags/Apple/clang-211.10.1) (based
> > > on LLVM
> > > String 6: 3.0svn).
> > >
> > > Writing to things in /sys/devices/platform/applesmc.768 gives also the
> > > said errors.
> > > But writing 1 to fan1_maunal and 5000 to fan1_output turns the fan on
> > > despite error messages.
> > >
> > Not really sure what to do here. I could revert the patch, but then we'd
> > gain
> > clang compile failures. Arnd, any idea ?
>
> It seems that either I made a mistake in the conversion and it sleeps for
> less time than before, or my assumption was wrong that converting a delay to
> a sleep is safe here.
>
> The error message indicates that the write fails, not the read, so that
> is what I'd look at first. Right away I can see that the maximum time to
> retry is only half of what it used to be, as we used to wait for
> 0x10, 0x20, 0x40, 0x80, ..., 0x2 microseconds for a total of
> 0x3fff0 microseconds (262ms), while my patch went with the 131ms
> total delay based on the comment saying "/* wait up to 128 ms for a
> status change. */".
>
Yes, that is also what I read from the code. I just thought there must
be something simple, which just needs a short look from another pair of
eyes.
> Since there is sleeping wait, I see no reason the timeout couldn't
> be extended a lot, e.g. to a second, as in
>
> #define APPLESMC_MAX_WAIT 0x10
>
> If that doesn't work, I'd try using mdelay() in place of
> usleep_range(), such as
>
>mdelay(DIV_ROUND_UP(us, USEC_PER_MSEC)));
>
> This adds back a really nasty latency, but it should avoid the
> compile-time problem.
>
> Andreas, can you try those two things? (one at a time,
> not both)
Ok, I tried. None of them works. I rechecked my work and created real
git commits out of them and CONFIG_LOCALVERSION_AUTO is also set so
the usual stupid things are rules out.
In detail:
On top of 5.9-rc6 + *reverted* patch:
diff --git a/drivers/hwmon/applesmc.c b/drivers/hwmon/applesmc.c
index fd99c9df8a00..2a9bd7f2b71b 100644
--- a/drivers/hwmon/applesmc.c
+++ b/drivers/hwmon/applesmc.c
@@ -45,7 +45,7 @@
/* wait up to 128 ms for a status change. */
#define APPLESMC_MIN_WAIT 0x0010
#define APPLESMC_RETRY_WAIT0x0100
-#define APPLESMC_MAX_WAIT 0x2
+#define APPLESMC_MAX_WAIT 0x8000
#define APPLESMC_READ_CMD 0x10
#define APPLESMC_WRITE_CMD 0x11
--
2.20.1
-> no trouble found, but I have not tested very long, just some
sysfs writes.
On top of 5.9-rc6:
diff --git a/drivers/hwmon/applesmc.c b/drivers/hwmon/applesmc.c
index a18887990f4a..3b0108b75a24 100644
--- a/drivers/hwmon/applesmc.c
+++ b/drivers/hwmon/applesmc.c
@@ -161,7 +161,7 @@ static int wait_read(void)
int us;
for (us = APPLESMC_MIN_WAIT; us < APPLESMC_MAX_WAIT; us <<= 1) {
- usleep_range(us, us * 16);
+ mdelay(DIV_ROUND_UP(us, USEC_PER_MSEC
[REGRESSION] hwmon: (applesmc) avoid overlong udelay()
Hi, after the $subject patch I get lots of errors like this: [ 120.378614] applesmc: send_byte(0x00, 0x0300) fail: 0x40 [ 120.378621] applesmc: LKSB: write data fail [ 120.512782] applesmc: send_byte(0x00, 0x0300) fail: 0x40 [ 120.512787] applesmc: LKSB: write data fail CPU sticks at low speed and no fan is turning on. Reverting this patch on top of 5.9-rc6 solves this problem. Some information from dmidecode: Base Board Information Manufacturer: Apple Inc. Product Name: Mac-7DF21CB3ED6977E5 Version: MacBookAir6,2 Handle 0x0020, DMI type 11, 5 bytes OEM Strings String 1: Apple ROM Version. Model: …, Handle 0x0020, DMI type 11, 5 bytes OEM Strings String 1: Apple ROM Version. Model:MBA61. EFI Version: 122.0.0 String 2: .0.0. Built by: root@saumon. Date: Wed Jun 10 18: String 3: 10:36 PDT 2020. Revision: 122 (B&I). ROM Version: F000_B String 4: 00. Build Type: Official Build, Release. Compiler: Appl String 5: e clang version 3.0 (tags/Apple/clang-211.10.1) (based on LLVM String 6: 3.0svn). Writing to things in /sys/devices/platform/applesmc.768 gives also the said errors. But writing 1 to fan1_maunal and 5000 to fan1_output turns the fan on despite error messages. Config used is: https://misc.andi.de1.cc/mac-config.gz Regards, Andreas
Re: [PATCH v3 5/7] rtc: New driver for RTC in Netronix embedded controller
On Thu, 24 Sep 2020 21:24:53 +0200
Jonathan Neuschäfer wrote:
> With this driver, mainline Linux can keep its time and date in sync with
> the vendor kernel.
>
> Advanced functionality like alarm and automatic power-on is not yet
> supported.
>
> Signed-off-by: Jonathan Neuschäfer
> ---
>
> v3:
> - Add email address to copyright line
> - Remove OF compatible string and don't include linux/of_device.h
> - Don't use a comma after sentinels
> - Avoid ret |= ... pattern
> - Move 8-bit register conversion to ntxec.h
> - Relicense as GPLv2 or later
>
> v2:
> - https://lore.kernel.org/lkml/20200905133230.1014581-7-j.neuschae...@gmx.net/
> - Rework top-of-file comment [Lee Jones]
> - Sort the #include lines [Alexandre Belloni]
> - don't align = signs in struct initializers [Uwe Kleine-König]
> - Switch to regmap
> - Fix register number used to read minutes and seconds
> - Prefix registers with NTXEC_REG_
> - Add help text to the Kconfig option
> - Use devm_rtc_allocate_device and rtc_register_device, set ->range_min and
> ->range_max
> ---
> drivers/rtc/Kconfig | 8 +++
> drivers/rtc/Makefile| 1 +
> drivers/rtc/rtc-ntxec.c | 132
> 3 files changed, 141 insertions(+)
> create mode 100644 drivers/rtc/rtc-ntxec.c
>
> diff --git a/drivers/rtc/Kconfig b/drivers/rtc/Kconfig
> index 48c536acd777f..ae8f3dc36c9a3 100644
> --- a/drivers/rtc/Kconfig
> +++ b/drivers/rtc/Kconfig
> @@ -1301,6 +1301,14 @@ config RTC_DRV_CROS_EC
> This driver can also be built as a module. If so, the module
> will be called rtc-cros-ec.
>
> +config RTC_DRV_NTXEC
> + tristate "Netronix embedded controller RTC driver"
> + depends on MFD_NTXEC
> + help
> + Say yes here if you want to support the RTC functionality of the
> + embedded controller found in certain e-book readers designed by the
> + ODM Netronix.
> +
> comment "on-CPU RTC drivers"
>
> config RTC_DRV_ASM9260
> diff --git a/drivers/rtc/Makefile b/drivers/rtc/Makefile
> index 880e08a409c3d..733479db18896 100644
> --- a/drivers/rtc/Makefile
> +++ b/drivers/rtc/Makefile
> @@ -111,6 +111,7 @@ obj-$(CONFIG_RTC_DRV_MT7622) += rtc-mt7622.o
> obj-$(CONFIG_RTC_DRV_MV) += rtc-mv.o
> obj-$(CONFIG_RTC_DRV_MXC)+= rtc-mxc.o
> obj-$(CONFIG_RTC_DRV_MXC_V2) += rtc-mxc_v2.o
> +obj-$(CONFIG_RTC_DRV_NTXEC) += rtc-ntxec.o
> obj-$(CONFIG_RTC_DRV_OMAP) += rtc-omap.o
> obj-$(CONFIG_RTC_DRV_OPAL) += rtc-opal.o
> obj-$(CONFIG_RTC_DRV_PALMAS) += rtc-palmas.o
> diff --git a/drivers/rtc/rtc-ntxec.c b/drivers/rtc/rtc-ntxec.c
> new file mode 100644
> index 0..af23c7cc76544
> --- /dev/null
> +++ b/drivers/rtc/rtc-ntxec.c
> @@ -0,0 +1,132 @@
> +// SPDX-License-Identifier: GPL-2.0-or-later
> +/*
> + * The Netronix embedded controller is a microcontroller found in some
> + * e-book readers designed by the ODM Netronix, Inc. It contains RTC,
> + * battery monitoring, system power management, and PWM functionality.
> + *
> + * This driver implements access to the RTC time and date.
> + *
> + * Copyright 2020 Jonathan Neuschäfer
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +struct ntxec_rtc {
> + struct device *dev;
> + struct ntxec *ec;
> +};
> +
> +#define NTXEC_REG_WRITE_YEAR 0x10
> +#define NTXEC_REG_WRITE_MONTH0x11
> +#define NTXEC_REG_WRITE_DAY 0x12
> +#define NTXEC_REG_WRITE_HOUR 0x13
> +#define NTXEC_REG_WRITE_MINUTE 0x14
> +#define NTXEC_REG_WRITE_SECOND 0x15
> +
> +#define NTXEC_REG_READ_YM0x20
> +#define NTXEC_REG_READ_DH0x21
> +#define NTXEC_REG_READ_MS0x23
> +
> +static int ntxec_read_time(struct device *dev, struct rtc_time *tm)
> +{
> + struct ntxec_rtc *rtc = dev_get_drvdata(dev);
> + unsigned int value;
> + int res;
> +
> + res = regmap_read(rtc->ec->regmap, NTXEC_REG_READ_YM, &value);
> + if (res < 0)
> + return res;
> +
> + tm->tm_year = (value >> 8) + 100;
> + tm->tm_mon = (value & 0xff) - 1;
> +
> + res = regmap_read(rtc->ec->regmap, NTXEC_REG_READ_DH, &value);
> + if (res < 0)
> + return res;
> +
> + tm->tm_mday = value >> 8;
> + tm->tm_hour = value & 0xff;
> +
> + res = regmap_read(rtc->ec->regmap, NTXEC_REG_READ_MS, &value);
> + if (res < 0)
> + return res;
> +
> + tm->tm_min = value >> 8;
> + tm->tm_sec = value & 0xff;
> +
> + return 0;
> +}
> +
> +static int ntxec_set_time(struct device *dev, struct rtc_time *tm)
> +{
> + struct ntxec_rtc *rtc = dev_get_drvdata(dev);
> + int res = 0;
> +
> + res = regmap_write(rtc->ec->regmap, NTXEC_REG_WRITE_YEAR,
> ntxec_reg8(tm->tm_year - 100));
> + if (res)
> + return res;
> +
> + res = regmap_write(rtc->ec->regmap, NTXEC_REG_WRITE_MONTH,
> ntxec_reg8(tm->tm_mon + 1));
> + if (res)
> + return res;
> +
> + res = regmap_write(rtc->ec->regmap, NTXEC_REG_WRITE_DAY,
> ntxec_reg8
Re: [PATCH v2] omap3: enable off mode automatically
On Fri, 11 Sep 2020 18:12:09 +0200 Andreas Kemnade wrote: > Enabling off mode was only reachable deeply hidden > in the debugfs. As powersaving is an important feature, > move the option out of its shady place. > The debugfs file can still be used to override the default. > > Use the presence of a device compatible to ti,twl4030-idle or > ti,twl4030-idle-osc-off as an indicator that the board is wired correctly > for off mode. > > Signed-off-by: Andreas Kemnade > --- > An earlier version of this patch was here: > https://patchwork.kernel.org/patch/10794121/ > > A config option was used instead of the suggested devicetree check. > > Changes in v2: > - fix compile without CONFIG_ARCH_OMAP3 > The variable enable_off_mode is now always a real one and not > a preprocessor constant to avoid trouble with unusual configurations. > Anything I still missed here? Regards, Andreas
Re: [PATCH v2] dt-bindings: mfd: Convert rn5t618 to json-schema
On Tue, 22 Sep 2020 19:40:41 -0600 Rob Herring wrote: > On Wed, Sep 16, 2020 at 08:17:57AM +0200, Andreas Kemnade wrote: > > Convert the RN5T618 binding to DT schema format. Also > > clearly state which regulators are available. > > > > Signed-off-by: Andreas Kemnade > > --- > > Changes in v2: > > - drop irq description > > > > Due to its .txt-format history BSD license was not added. > > .../bindings/mfd/ricoh,rn5t618.yaml | 111 ++ > > .../devicetree/bindings/mfd/rn5t618.txt | 52 > > 2 files changed, 111 insertions(+), 52 deletions(-) > > create mode 100644 Documentation/devicetree/bindings/mfd/ricoh,rn5t618.yaml > > delete mode 100644 Documentation/devicetree/bindings/mfd/rn5t618.txt > > > > diff --git a/Documentation/devicetree/bindings/mfd/ricoh,rn5t618.yaml > > b/Documentation/devicetree/bindings/mfd/ricoh,rn5t618.yaml > > new file mode 100644 > > index ..d70e85a09c84 > > --- /dev/null > > +++ b/Documentation/devicetree/bindings/mfd/ricoh,rn5t618.yaml > > @@ -0,0 +1,111 @@ > > +# SPDX-License-Identifier: GPL-2.0 > > +%YAML 1.2 > > +--- > > +$id: http://devicetree.org/schemas/mfd/ricoh,rn5t618.yaml# > > +$schema: http://devicetree.org/meta-schemas/core.yaml# > > + > > +title: Ricoh RN5T567/RN5T618/RC5T619 PMIC > > + > > +maintainers: > > + - Andreas Kemnade > > + > > +description: | > > + Ricoh RN5T567/RN5T618/RC5T619 is a power management IC family which > > + integrates 3 to 5 step-down DCDC converters, 7 to 10 low-dropout > > regulators, > > + GPIOs, and a watchdog timer. It can be controlled through an I2C > > interface. > > + The RN5T618/RC5T619 provides additionally a Li-ion battery charger, > > + fuel gauge, and an ADC. > > + The RC5T619 additionnally includes USB charger detection and an RTC. > > + > > +allOf: > > + - if: > > + properties: > > +compatible: > > + contains: > > +const: ricoh,rn5t567 > > +then: > > + properties: > > +regulators: > > + patternProperties: > > +"^(DCDC[1-4]|LDO[1-5]|LDORTC[12])$": > > + $ref: ../regulator/regulator.yaml > > + additionalProperties: false > > + - if: > > + properties: > > +compatible: > > + contains: > > +const: ricoh,rn5t618 > > +then: > > + properties: > > +regulators: > > + patternProperties: > > +"^(DCDC[1-3]|LDO[1-5]|LDORTC[12])$": > > + $ref: ../regulator/regulator.yaml > > + additionalProperties: false > > + - if: > > + properties: > > +compatible: > > + contains: > > +const: ricoh,rc5t619 > > +then: > > + properties: > > +regulators: > > + patternProperties: > > +"^(DCDC[1-5]|LDO[1-9]|LDO10|LDORTC[12])$": > > + $ref: ../regulator/regulator.yaml > > + additionalProperties: false > > + > > +properties: > > + compatible: > > +enum: > > + - ricoh,rn5t567 > > + - ricoh,rn5t618 > > + - ricoh,rc5t619 > > + > > + reg: > > +maxItems: 1 > > + > > + interrupts: > > +maxItems: 1 > > + > > + system-power-controller: > > +type: boolean > > +description: | > > + See Documentation/devicetree/bindings/power/power-controller.txt > > + > > + regulators: > > +type: object > > Add here: > > $ref: ../regulator/regulator.yaml > > And then the occurrances up above can be just 'true'. > That feels wrong. I would think that gets applied to things directly below regulator node and not to the individual regulator subnodes. To check that I did: diff --git a/Documentation/devicetree/bindings/regulator/regulator.yaml b/Documentation/devicetree/bindings/regulator/regulator.yaml index ec505dbbf87c..077cb473d5f4 100644 --- a/Documentation/devicetree/bindings/regulator/regulator.yaml +++ b/Documentation/devicetree/bindings/regulator/regulator.yaml @@ -188,6 +188,8 @@ patternProperties: additionalProperties: false +additionalProperties: false + additionally to your requested change with this result: andi@aktux:~/gta04/dt-chk$ DT_SCHEMA_FILES=Documentation/devicetree/bindings/mfd/ricoh,rn5t618.yaml makearm dt_binding_check CHKDT Documentation/devicetree/bindings/mfd/ricoh,rn5t618.yaml SCHEMA
[PATCH v2] dt-bindings: mfd: Convert rn5t618 to json-schema
Convert the RN5T618 binding to DT schema format. Also
clearly state which regulators are available.
Signed-off-by: Andreas Kemnade
---
Changes in v2:
- drop irq description
Due to its .txt-format history BSD license was not added.
.../bindings/mfd/ricoh,rn5t618.yaml | 111 ++
.../devicetree/bindings/mfd/rn5t618.txt | 52
2 files changed, 111 insertions(+), 52 deletions(-)
create mode 100644 Documentation/devicetree/bindings/mfd/ricoh,rn5t618.yaml
delete mode 100644 Documentation/devicetree/bindings/mfd/rn5t618.txt
diff --git a/Documentation/devicetree/bindings/mfd/ricoh,rn5t618.yaml
b/Documentation/devicetree/bindings/mfd/ricoh,rn5t618.yaml
new file mode 100644
index ..d70e85a09c84
--- /dev/null
+++ b/Documentation/devicetree/bindings/mfd/ricoh,rn5t618.yaml
@@ -0,0 +1,111 @@
+# SPDX-License-Identifier: GPL-2.0
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/mfd/ricoh,rn5t618.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Ricoh RN5T567/RN5T618/RC5T619 PMIC
+
+maintainers:
+ - Andreas Kemnade
+
+description: |
+ Ricoh RN5T567/RN5T618/RC5T619 is a power management IC family which
+ integrates 3 to 5 step-down DCDC converters, 7 to 10 low-dropout regulators,
+ GPIOs, and a watchdog timer. It can be controlled through an I2C interface.
+ The RN5T618/RC5T619 provides additionally a Li-ion battery charger,
+ fuel gauge, and an ADC.
+ The RC5T619 additionnally includes USB charger detection and an RTC.
+
+allOf:
+ - if:
+ properties:
+compatible:
+ contains:
+const: ricoh,rn5t567
+then:
+ properties:
+regulators:
+ patternProperties:
+"^(DCDC[1-4]|LDO[1-5]|LDORTC[12])$":
+ $ref: ../regulator/regulator.yaml
+ additionalProperties: false
+ - if:
+ properties:
+compatible:
+ contains:
+const: ricoh,rn5t618
+then:
+ properties:
+regulators:
+ patternProperties:
+"^(DCDC[1-3]|LDO[1-5]|LDORTC[12])$":
+ $ref: ../regulator/regulator.yaml
+ additionalProperties: false
+ - if:
+ properties:
+compatible:
+ contains:
+const: ricoh,rc5t619
+then:
+ properties:
+regulators:
+ patternProperties:
+"^(DCDC[1-5]|LDO[1-9]|LDO10|LDORTC[12])$":
+ $ref: ../regulator/regulator.yaml
+ additionalProperties: false
+
+properties:
+ compatible:
+enum:
+ - ricoh,rn5t567
+ - ricoh,rn5t618
+ - ricoh,rc5t619
+
+ reg:
+maxItems: 1
+
+ interrupts:
+maxItems: 1
+
+ system-power-controller:
+type: boolean
+description: |
+ See Documentation/devicetree/bindings/power/power-controller.txt
+
+ regulators:
+type: object
+
+additionalProperties: false
+
+required:
+ - compatible
+ - reg
+
+examples:
+ - |
+#include
+i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ pmic@32 {
+compatible = "ricoh,rn5t618";
+reg = <0x32>;
+interrupt-parent = <&gpio5>;
+interrupts = <11 IRQ_TYPE_EDGE_FALLING>;
+system-power-controller;
+
+regulators {
+ DCDC1 {
+regulator-min-microvolt = <105>;
+regulator-max-microvolt = <105>;
+ };
+
+ DCDC2 {
+regulator-min-microvolt = <1175000>;
+regulator-max-microvolt = <1175000>;
+ };
+};
+ };
+};
diff --git a/Documentation/devicetree/bindings/mfd/rn5t618.txt
b/Documentation/devicetree/bindings/mfd/rn5t618.txt
deleted file mode 100644
index 16778ea00dbc..
--- a/Documentation/devicetree/bindings/mfd/rn5t618.txt
+++ /dev/null
@@ -1,52 +0,0 @@
-* Ricoh RN5T567/RN5T618 PMIC
-
-Ricoh RN5T567/RN5T618/RC5T619 is a power management IC family which
-integrates 3 to 5 step-down DCDC converters, 7 to 10 low-dropout regulators,
-GPIOs, and a watchdog timer. It can be controlled through an I2C interface.
-The RN5T618/RC5T619 provides additionally a Li-ion battery charger,
-fuel gauge, and an ADC.
-The RC5T619 additionnally includes USB charger detection and an RTC.
-
-Required properties:
- - compatible: must be one of
- "ricoh,rn5t567"
- "ricoh,rn5t618"
- "ricoh,rc5t619"
- - reg: the I2C slave address of the device
-
-Optional properties:
- - interrupts: interrupt mapping for IRQ
- See Documentation/devicetree/bindings/interrupt-controller/interrupts.txt
- - system-power-controller:
- See Documentation/devicetree/bindings/power/power-controller.txt
-
-Sub-nodes:
- - regulators: the node is required if the regulator functionality is
- needed. The valid regulator names are: DCDC1, DCDC2, DCDC3, DCDC4
- (RN5T567/RC5T619), LDO1, LDO2, LDO3, LDO4, LDO
Re: [PATCH] dt-bindings: mfd: Convert rn5t618 to json-schema
On Tue, 15 Sep 2020 11:11:52 -0600
Rob Herring wrote:
> On Tue, Sep 08, 2020 at 10:13:03PM +0200, Andreas Kemnade wrote:
> > Convert the RN5T618 binding to DT schema format. Also
> > clearly state which regulators are available.
> >
> > Signed-off-by: Andreas Kemnade
> > ---
> > I have noted myself here as maintainer because I wrote most of the
> > code of the several subdevices, although not of the .txt-binding.
> > Due to its .txt-format history BSD license was not added.
> > I happily ignored the "does MAINTAINERS need updating" thing
> > from checkpatch.pl, I do not know whether that PMIC should
> > have a separate entry there.
> >
> > .../bindings/mfd/ricoh,rn5t618.yaml | 113 ++
> > .../devicetree/bindings/mfd/rn5t618.txt | 52
> > 2 files changed, 113 insertions(+), 52 deletions(-)
> > create mode 100644 Documentation/devicetree/bindings/mfd/ricoh,rn5t618.yaml
> > delete mode 100644 Documentation/devicetree/bindings/mfd/rn5t618.txt
> >
> > diff --git a/Documentation/devicetree/bindings/mfd/ricoh,rn5t618.yaml
> > b/Documentation/devicetree/bindings/mfd/ricoh,rn5t618.yaml
> > new file mode 100644
> > index ..9596dde7a69a
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/mfd/ricoh,rn5t618.yaml
> > @@ -0,0 +1,113 @@
> > +# SPDX-License-Identifier: GPL-2.0
> > +%YAML 1.2
> > +---
> > +$id: http://devicetree.org/schemas/mfd/ricoh,rn5t618.yaml#
> > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > +
> > +title: Ricoh RN5T567/RN5T618/RC5T619 PMIC
> > +
> > +maintainers:
> > + - Andreas Kemnade
> > +
> > +description: |
> > + Ricoh RN5T567/RN5T618/RC5T619 is a power management IC family which
> > + integrates 3 to 5 step-down DCDC converters, 7 to 10 low-dropout
> > regulators,
> > + GPIOs, and a watchdog timer. It can be controlled through an I2C
> > interface.
> > + The RN5T618/RC5T619 provides additionally a Li-ion battery charger,
> > + fuel gauge, and an ADC.
> > + The RC5T619 additionnally includes USB charger detection and an RTC.
> > +
> > +allOf:
> > + - if:
> > + properties:
> > +compatible:
> > + contains:
> > +const: ricoh,rn5t567
> > +then:
> > + properties:
> > +regulators:
> > + patternProperties:
> > +"^(DCDC[1-4]|LDO[1-5]|LDORTC[12])$":
> > + $ref: ../regulator/regulator.yaml
> > + additionalProperties: false
> > + - if:
> > + properties:
> > +compatible:
> > + contains:
> > +const: ricoh,rn5t618
> > +then:
> > + properties:
> > +regulators:
> > + patternProperties:
> > +"^(DCDC[1-3]|LDO[1-5]|LDORTC[12])$":
> > + $ref: ../regulator/regulator.yaml
> > + additionalProperties: false
> > + - if:
> > + properties:
> > +compatible:
> > + contains:
> > +const: ricoh,rc5t619
> > +then:
> > + properties:
> > +regulators:
> > + patternProperties:
> > +"^(DCDC[1-5]|LDO[1-9]|LDO10|LDORTC[12])$":
> > + $ref: ../regulator/regulator.yaml
> > + additionalProperties: false
>
> I prefer under 'regulators' below, you have all possible regulator
> names:
>
> patternProperties:
> "^(DCDC[1-5]|LDO[1-9]|LDO10|LDORTC[12])$":
> $ref: ../regulator/regulator.yaml
>
> and then above you just need to restrict the possible names:
>
> regulators:
> propertyNames:
> pattern: "^(DCDC[1-3]|LDO[1-5]|LDORTC[12])$"
>
> (propertyNames schema is applied to all an object's properties and you
> don't need additionalProperties here.)
>
hmm, dt_binding_check refuses to digest things like this:
allOf:
- if:
properties:
compatible:
contains:
const: ricoh,rn5t567
then:
properties:
regulators:
propertyNames:
pattern: "^(DCDC[1-4]|LDO[1-5]|LDORTC[12])$"
I get:
andi@aktux:~/kernel$
DT_SCHEMA_FILES=Documentation/devicetree/bindings/mfd/ricoh,rn5t618.yaml
makearm dt_binding_check
CHKDT Documentation/devicetree/bindings/mfd/ricoh,rn5t618.yaml
/home/andi/kernel/Documentation/devicetree/bindings/mfd/ricoh,rn5t618.yaml:
allOf:0:then:properties:regulators: Additional properties are not allowed
('propertyNames' was unexpect
Re: [PATCH v2 04/10] dt-bindings: pwm: Add bindings for PWM function in Netronix EC
Hi,
On Mon, 14 Sep 2020 18:54:43 -0600
Rob Herring wrote:
> On Sat, Sep 05, 2020 at 03:32:24PM +0200, Jonathan Neuschäfer wrote:
> > The Netronix embedded controller as found in Kobo Aura and Tolino Shine
> > supports one PWM channel, which is used to control the frontlight
> > brightness on these devices.
> >
> > Signed-off-by: Jonathan Neuschäfer
> > ---
> >
> > v2:
> > - Add plaintext binding to patch description, for comparison
> > - Fix pwm-cells property (should be 2, not 1)
> > - Add dummy regulator to example, because the pwm-backlight binding
> > requires a
> > power supply
> >
> >
> > For reference, here is the binding in text form:
> >
> >
> > PWM functionality in Netronix Embedded Controller
> >
> > Required properties:
> > - compatible: should be "netronix,ntxec-pwm"
> > - #pwm-cells: should be 2.
> >
> > Available PWM channels:
> > - 0: The PWM channel controlled by registers 0xa1-0xa7
> >
> > Example:
> >
> > embedded-controller@43 {
> > compatible = "netronix,ntxec";
> > ...
> >
> > ec_pwm: pwm {
> > compatible = "netronix,ntxec-pwm";
> > #pwm-cells = <1>;
> > };
> > };
> >
> > ...
> >
> > backlight {
> > compatible = "pwm-backlight";
> > pwms = <&ec_pwm 0 5>;
> > };
> > ---
> > .../bindings/mfd/netronix,ntxec.yaml | 19 +++
> > .../bindings/pwm/netronix,ntxec-pwm.yaml | 33 +++
> > 2 files changed, 52 insertions(+)
> > create mode 100644
> > Documentation/devicetree/bindings/pwm/netronix,ntxec-pwm.yaml
> >
> > diff --git a/Documentation/devicetree/bindings/mfd/netronix,ntxec.yaml
> > b/Documentation/devicetree/bindings/mfd/netronix,ntxec.yaml
> > index 596df460f98eb..73c873dda3e70 100644
> > --- a/Documentation/devicetree/bindings/mfd/netronix,ntxec.yaml
> > +++ b/Documentation/devicetree/bindings/mfd/netronix,ntxec.yaml
> > @@ -31,6 +31,9 @@ properties:
> > description:
> >The EC can signal interrupts via a GPIO line
> >
> > + pwm:
> > +$ref: ../pwm/netronix,ntxec-pwm.yaml
> > +
> > required:
> >- compatible
> >- reg
> > @@ -53,5 +56,21 @@ examples:
> > interrupts = <11 IRQ_TYPE_EDGE_FALLING>;
> > interrupt-controller;
> > #interrupt-cells = <1>;
> > +
> > +ec_pwm: pwm {
> > +compatible = "netronix,ntxec-pwm";
> > +#pwm-cells = <2>;
> > +};
> > };
> > };
> > +
> > +backlight {
> > +compatible = "pwm-backlight";
> > +pwms = <&ec_pwm 0 5>;
> > +power-supply = <&backlight_regulator>;
> > +};
> > +
> > +backlight_regulator: regulator-dummy {
> > +compatible = "regulator-fixed";
> > +regulator-name = "backlight";
> > +};
> > diff --git a/Documentation/devicetree/bindings/pwm/netronix,ntxec-pwm.yaml
> > b/Documentation/devicetree/bindings/pwm/netronix,ntxec-pwm.yaml
> > new file mode 100644
> > index 0..0c9d2801b8de1
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/pwm/netronix,ntxec-pwm.yaml
> > @@ -0,0 +1,33 @@
> > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> > +%YAML 1.2
> > +---
> > +$id: http://devicetree.org/schemas/pwm/netronix,ntxec-pwm.yaml#
> > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > +
> > +title: PWM functionality in Netronix embedded controller
> > +
> > +maintainers:
> > + - Jonathan Neuschäfer
> > +
> > +description: |
> > + See also Documentation/devicetree/bindings/mfd/netronix,ntxec.yaml
> > +
> > + The Netronix EC contains PWM functionality, which is usually used to
> > drive
> > + the backlight LED.
> > +
> > + The following PWM channels are supported:
> > +- 0: The PWM channel controlled by registers 0xa1-0xa7
> > +
> > +allOf:
> > + - $ref: pwm.yaml#
> > +
> > +properties:
> > + compatible:
> > +const: netronix,ntxec-pwm
> > +
> > + "#pwm-cells":
> > +const: 2
>
> Just move this to the parent and make the parent a pwm provider. There's
> no need for child nodes for this or the rtc.
>
hmm, there are apparently devices without rtc. If there is a child node
for the rtc, the corresponding devicetrees could disable rtc by not
having that node.
But maybe using the controller version is also feasible for that task.
Regards,
Andreas
Re: [PATCH] omap3: enable off mode automatically
On Fri, 11 Sep 2020 13:33:37 +0300 Tony Lindgren wrote: > * Andreas Kemnade [200911 09:50]: > > --- a/arch/arm/mach-omap2/pm.h > > +++ b/arch/arm/mach-omap2/pm.h > > @@ -49,11 +49,7 @@ static inline int omap4_opp_init(void) > > extern int omap3_pm_get_suspend_state(struct powerdomain *pwrdm); > > extern int omap3_pm_set_suspend_state(struct powerdomain *pwrdm, int > > state); > > > > -#ifdef CONFIG_PM_DEBUG > > extern u32 enable_off_mode; > > -#else > > -#define enable_off_mode 0 > > -#endif > > Hmm isn't the above still needed for the other SoCs? Or is omap3 the only > user? > well, the linker moans about undefined symbols if CONFIG_ARCH_OMAP3 is not enabled. I will send a v2. Regards, Andreas
[PATCH v2] omap3: enable off mode automatically
Enabling off mode was only reachable deeply hidden
in the debugfs. As powersaving is an important feature,
move the option out of its shady place.
The debugfs file can still be used to override the default.
Use the presence of a device compatible to ti,twl4030-idle or
ti,twl4030-idle-osc-off as an indicator that the board is wired correctly
for off mode.
Signed-off-by: Andreas Kemnade
---
An earlier version of this patch was here:
https://patchwork.kernel.org/patch/10794121/
A config option was used instead of the suggested devicetree check.
Changes in v2:
- fix compile without CONFIG_ARCH_OMAP3
The variable enable_off_mode is now always a real one and not
a preprocessor constant to avoid trouble with unusual configurations.
arch/arm/mach-omap2/pm-debug.c | 2 --
arch/arm/mach-omap2/pm.c | 2 ++
arch/arm/mach-omap2/pm.h | 4
arch/arm/mach-omap2/pm34xx.c | 25 -
4 files changed, 26 insertions(+), 7 deletions(-)
diff --git a/arch/arm/mach-omap2/pm-debug.c b/arch/arm/mach-omap2/pm-debug.c
index fceb1e525d26..919d35d5b325 100644
--- a/arch/arm/mach-omap2/pm-debug.c
+++ b/arch/arm/mach-omap2/pm-debug.c
@@ -34,8 +34,6 @@
#include "prm2xxx_3xxx.h"
#include "pm.h"
-u32 enable_off_mode;
-
#ifdef CONFIG_DEBUG_FS
#include
#include
diff --git a/arch/arm/mach-omap2/pm.c b/arch/arm/mach-omap2/pm.c
index 01ec1ba4878b..da829a90fe8c 100644
--- a/arch/arm/mach-omap2/pm.c
+++ b/arch/arm/mach-omap2/pm.c
@@ -28,6 +28,8 @@
#include "clockdomain.h"
#include "pm.h"
+u32 enable_off_mode;
+
#ifdef CONFIG_SUSPEND
/*
* omap_pm_suspend: points to a function that does the SoC-specific
diff --git a/arch/arm/mach-omap2/pm.h b/arch/arm/mach-omap2/pm.h
index 2a883a0c1fcd..80e84ae66aee 100644
--- a/arch/arm/mach-omap2/pm.h
+++ b/arch/arm/mach-omap2/pm.h
@@ -49,11 +49,7 @@ static inline int omap4_opp_init(void)
extern int omap3_pm_get_suspend_state(struct powerdomain *pwrdm);
extern int omap3_pm_set_suspend_state(struct powerdomain *pwrdm, int state);
-#ifdef CONFIG_PM_DEBUG
extern u32 enable_off_mode;
-#else
-#define enable_off_mode 0
-#endif
#if defined(CONFIG_PM_DEBUG) && defined(CONFIG_DEBUG_FS)
extern void pm_dbg_update_time(struct powerdomain *pwrdm, int prev);
diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
index f5dfddf492e2..925b8efbf46c 100644
--- a/arch/arm/mach-omap2/pm34xx.c
+++ b/arch/arm/mach-omap2/pm34xx.c
@@ -25,6 +25,7 @@
#include
#include
#include
+#include
#include
#include
@@ -410,7 +411,12 @@ static int __init pwrdms_setup(struct powerdomain *pwrdm,
void *unused)
if (!pwrst)
return -ENOMEM;
pwrst->pwrdm = pwrdm;
- pwrst->next_state = PWRDM_POWER_RET;
+
+ if (enable_off_mode)
+ pwrst->next_state = PWRDM_POWER_OFF;
+ else
+ pwrst->next_state = PWRDM_POWER_RET;
+
list_add(&pwrst->node, &pwrst_list);
if (pwrdm_has_hdwr_sar(pwrdm))
@@ -444,6 +450,21 @@ static void __init pm_errata_configure(void)
}
}
+static void __init omap3_pm_check_pmic(void)
+{
+ struct device_node *np;
+
+ np = of_find_compatible_node(NULL, NULL, "ti,twl4030-power-idle");
+ if (!np)
+ np = of_find_compatible_node(NULL, NULL,
"ti,twl4030-power-idle-osc-off");
+
+ if (np) {
+ of_node_put(np);
+ enable_off_mode = 1;
+ } else
+ enable_off_mode = 0;
+}
+
int __init omap3_pm_init(void)
{
struct power_state *pwrst, *tmp;
@@ -477,6 +498,8 @@ int __init omap3_pm_init(void)
goto err2;
}
+ omap3_pm_check_pmic();
+
ret = pwrdm_for_each(pwrdms_setup, NULL);
if (ret) {
pr_err("Failed to setup powerdomains\n");
--
2.20.1
[PATCH] omap3: enable off mode automatically
Enabling off mode was only reachable deeply hidden
in the debugfs. As powersaving is an important feature,
move the option out of its shady place.
The debugfs file can still be used to override the default.
Use the presence of a device compatible to ti,twl4030-idle or
ti,twl4030-idle-osc-off as an indicator that the board is wired correctly
for off mode.
Signed-off-by: Andreas Kemnade
---
An earlier version of this patch was here:
https://patchwork.kernel.org/patch/10794121/
A config option was used instead of the suggested devicetree check.
arch/arm/mach-omap2/pm.h | 4
arch/arm/mach-omap2/pm34xx.c | 29 -
2 files changed, 28 insertions(+), 5 deletions(-)
diff --git a/arch/arm/mach-omap2/pm.h b/arch/arm/mach-omap2/pm.h
index 2a883a0c1fcd..80e84ae66aee 100644
--- a/arch/arm/mach-omap2/pm.h
+++ b/arch/arm/mach-omap2/pm.h
@@ -49,11 +49,7 @@ static inline int omap4_opp_init(void)
extern int omap3_pm_get_suspend_state(struct powerdomain *pwrdm);
extern int omap3_pm_set_suspend_state(struct powerdomain *pwrdm, int state);
-#ifdef CONFIG_PM_DEBUG
extern u32 enable_off_mode;
-#else
-#define enable_off_mode 0
-#endif
#if defined(CONFIG_PM_DEBUG) && defined(CONFIG_DEBUG_FS)
extern void pm_dbg_update_time(struct powerdomain *pwrdm, int prev);
diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
index f5dfddf492e2..d069d581c372 100644
--- a/arch/arm/mach-omap2/pm34xx.c
+++ b/arch/arm/mach-omap2/pm34xx.c
@@ -25,6 +25,7 @@
#include
#include
#include
+#include
#include
#include
@@ -51,6 +52,10 @@
/* pm34xx errata defined in pm.h */
u16 pm34xx_errata;
+#ifndef CONFIG_PM_DEBUG
+u32 enable_off_mode;
+#endif
+
struct power_state {
struct powerdomain *pwrdm;
u32 next_state;
@@ -410,7 +415,12 @@ static int __init pwrdms_setup(struct powerdomain *pwrdm,
void *unused)
if (!pwrst)
return -ENOMEM;
pwrst->pwrdm = pwrdm;
- pwrst->next_state = PWRDM_POWER_RET;
+
+ if (enable_off_mode)
+ pwrst->next_state = PWRDM_POWER_OFF;
+ else
+ pwrst->next_state = PWRDM_POWER_RET;
+
list_add(&pwrst->node, &pwrst_list);
if (pwrdm_has_hdwr_sar(pwrdm))
@@ -444,6 +454,21 @@ static void __init pm_errata_configure(void)
}
}
+static void __init omap3_pm_check_pmic(void)
+{
+ struct device_node *np;
+
+ np = of_find_compatible_node(NULL, NULL, "ti,twl4030-power-idle");
+ if (!np)
+ np = of_find_compatible_node(NULL, NULL,
"ti,twl4030-power-idle-osc-off");
+
+ if (np) {
+ of_node_put(np);
+ enable_off_mode = 1;
+ } else
+ enable_off_mode = 0;
+}
+
int __init omap3_pm_init(void)
{
struct power_state *pwrst, *tmp;
@@ -477,6 +502,8 @@ int __init omap3_pm_init(void)
goto err2;
}
+ omap3_pm_check_pmic();
+
ret = pwrdm_for_each(pwrdms_setup, NULL);
if (ret) {
pr_err("Failed to setup powerdomains\n");
--
2.20.1
Re: [PATCH V2 1/2] thermal: ti-soc-thermal: Enable addition power management
On Thu, 10 Sep 2020 14:33:13 -0500 Adam Ford wrote: > On Thu, Sep 10, 2020 at 2:14 PM Daniel Lezcano > wrote: > > > On 10/09/2020 20:01, Andreas Kemnade wrote: > > > On Wed, 19 Aug 2020 07:59:23 -0500 > > > Adam Ford wrote: > > > > > >> The bandgap sensor can be idled when the processor is too, but it > > >> isn't currently being done, so the power consumption of OMAP3 > > >> boards can elevated if the bangap sensor is enabled. > > >> > > >> This patch attempts to use some additional power management > > >> to idle the clock to the bandgap when not needed. > > >> > > >> Signed-off-by: Adam Ford > > >> Reported-by: kernel test robot > > >> --- > > >> V2: Fix issue where variable stating the suspend mode isn't being > > >> properly set and cleared. > > >> > > > hmm, it is not in linux-next. Can we expect that for v5.10? > > > > The reason I did not pick this patch is because lkp reported an error on > > it. > > > > https://marc.info/?l=linux-pm&m=159788472017308&w=2 > > > > > > > That error message shows it's trying to be built with 'sh' cross compiler, > but should be build with an ARM. > > I can run a manual test of the patch against a different branch if > necessary, but I had built and tested it, so I know it worked at one time. > hmm, what about compile-testing without CONFIG_PM_SLEEP? The function definition is guarded by that. So it is not a sh-specific problem. Regards, Andreas
Re: [PATCH V2 1/2] thermal: ti-soc-thermal: Enable addition power management
On Wed, 19 Aug 2020 07:59:23 -0500 Adam Ford wrote: > The bandgap sensor can be idled when the processor is too, but it > isn't currently being done, so the power consumption of OMAP3 > boards can elevated if the bangap sensor is enabled. > > This patch attempts to use some additional power management > to idle the clock to the bandgap when not needed. > > Signed-off-by: Adam Ford > Reported-by: kernel test robot > --- > V2: Fix issue where variable stating the suspend mode isn't being > properly set and cleared. > hmm, it is not in linux-next. Can we expect that for v5.10? Regards, Andreas
[PATCH] dt-bindings: mfd: Convert rn5t618 to json-schema
Convert the RN5T618 binding to DT schema format. Also
clearly state which regulators are available.
Signed-off-by: Andreas Kemnade
---
I have noted myself here as maintainer because I wrote most of the
code of the several subdevices, although not of the .txt-binding.
Due to its .txt-format history BSD license was not added.
I happily ignored the "does MAINTAINERS need updating" thing
from checkpatch.pl, I do not know whether that PMIC should
have a separate entry there.
.../bindings/mfd/ricoh,rn5t618.yaml | 113 ++
.../devicetree/bindings/mfd/rn5t618.txt | 52
2 files changed, 113 insertions(+), 52 deletions(-)
create mode 100644 Documentation/devicetree/bindings/mfd/ricoh,rn5t618.yaml
delete mode 100644 Documentation/devicetree/bindings/mfd/rn5t618.txt
diff --git a/Documentation/devicetree/bindings/mfd/ricoh,rn5t618.yaml
b/Documentation/devicetree/bindings/mfd/ricoh,rn5t618.yaml
new file mode 100644
index ..9596dde7a69a
--- /dev/null
+++ b/Documentation/devicetree/bindings/mfd/ricoh,rn5t618.yaml
@@ -0,0 +1,113 @@
+# SPDX-License-Identifier: GPL-2.0
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/mfd/ricoh,rn5t618.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Ricoh RN5T567/RN5T618/RC5T619 PMIC
+
+maintainers:
+ - Andreas Kemnade
+
+description: |
+ Ricoh RN5T567/RN5T618/RC5T619 is a power management IC family which
+ integrates 3 to 5 step-down DCDC converters, 7 to 10 low-dropout regulators,
+ GPIOs, and a watchdog timer. It can be controlled through an I2C interface.
+ The RN5T618/RC5T619 provides additionally a Li-ion battery charger,
+ fuel gauge, and an ADC.
+ The RC5T619 additionnally includes USB charger detection and an RTC.
+
+allOf:
+ - if:
+ properties:
+compatible:
+ contains:
+const: ricoh,rn5t567
+then:
+ properties:
+regulators:
+ patternProperties:
+"^(DCDC[1-4]|LDO[1-5]|LDORTC[12])$":
+ $ref: ../regulator/regulator.yaml
+ additionalProperties: false
+ - if:
+ properties:
+compatible:
+ contains:
+const: ricoh,rn5t618
+then:
+ properties:
+regulators:
+ patternProperties:
+"^(DCDC[1-3]|LDO[1-5]|LDORTC[12])$":
+ $ref: ../regulator/regulator.yaml
+ additionalProperties: false
+ - if:
+ properties:
+compatible:
+ contains:
+const: ricoh,rc5t619
+then:
+ properties:
+regulators:
+ patternProperties:
+"^(DCDC[1-5]|LDO[1-9]|LDO10|LDORTC[12])$":
+ $ref: ../regulator/regulator.yaml
+ additionalProperties: false
+
+properties:
+ compatible:
+enum:
+ - ricoh,rn5t567
+ - ricoh,rn5t618
+ - ricoh,rc5t619
+
+ reg:
+maxItems: 1
+
+ interrupts:
+maxItems: 1
+description: |
+ See Documentation/devicetree/bindings/interrupt-controller/interrupts.txt
+
+ system-power-controller:
+type: boolean
+description: |
+ See Documentation/devicetree/bindings/power/power-controller.txt
+
+ regulators:
+type: object
+
+additionalProperties: false
+
+required:
+ - compatible
+ - reg
+
+examples:
+ - |
+#include
+i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ pmic@32 {
+compatible = "ricoh,rn5t618";
+reg = <0x32>;
+interrupt-parent = <&gpio5>;
+interrupts = <11 IRQ_TYPE_EDGE_FALLING>;
+system-power-controller;
+
+regulators {
+ DCDC1 {
+regulator-min-microvolt = <105>;
+regulator-max-microvolt = <105>;
+ };
+
+ DCDC2 {
+regulator-min-microvolt = <1175000>;
+regulator-max-microvolt = <1175000>;
+ };
+};
+ };
+};
diff --git a/Documentation/devicetree/bindings/mfd/rn5t618.txt
b/Documentation/devicetree/bindings/mfd/rn5t618.txt
deleted file mode 100644
index 16778ea00dbc..
--- a/Documentation/devicetree/bindings/mfd/rn5t618.txt
+++ /dev/null
@@ -1,52 +0,0 @@
-* Ricoh RN5T567/RN5T618 PMIC
-
-Ricoh RN5T567/RN5T618/RC5T619 is a power management IC family which
-integrates 3 to 5 step-down DCDC converters, 7 to 10 low-dropout regulators,
-GPIOs, and a watchdog timer. It can be controlled through an I2C interface.
-The RN5T618/RC5T619 provides additionally a Li-ion battery charger,
-fuel gauge, and an ADC.
-The RC5T619 additionnally includes USB charger detection and an RTC.
-
-Required properties:
- - compatible: must be one of
- "ricoh,rn5t567"
- "ricoh,rn5t618"
- "ricoh,rc5t619"
- - reg: the I2C slave address of the device
-
-Optional properties:
- - interrupts: interrupt mapping for IRQ
- See Documentation/
Re: [PATCH v2 2/2] ARM: dts: imx: add devicetree for Tolino Shine 2 HD
Hi,
On Thu, 27 Aug 2020 20:33:23 +0200
Jonathan Neuschäfer wrote:
> On Wed, Aug 26, 2020 at 10:42:51PM +0200, Andreas Kemnade wrote:
> > This adds a devicetree for the Tolino Shine 2 HD Ebook reader. It is based
> > on boards marked with "37NB-E60QF0+4A2". It is equipped with an i.MX6SL
> > SoC.
> >
> > Expected to work:
> > - Buttons
> > - Wifi
> > - Touchscreen
> > - LED
> > - uSD
> > - USB
> > - RTC
> >
> > Not working due to missing drivers:
> > - Backlight (requires NTXEC driver)
> > - EPD
> >
> > Not working due to unknown reasons:
> > - deep sleep (echo standby >/sys/power/state works),
> > wakeup fails when imx_gpc_pre_suspend(true) was called.
> >
> > Signed-off-by: Andreas Kemnade
> > ---
> [...]
> > + fl {
> > + label = "Frontlight";
> > + gpios = <&gpio3 26 GPIO_ACTIVE_LOW>;
> > + linux,code = ;
> > + };
>
> Another option might be KEY_BRIGHTNESS_TOGGLE/KEY_DISPLAYTOGGLE, but
> it's not a perfect match, either. (And perhaps a worse match due to the
> connotation of turning the display off.)
>
I have also thought about these, but came to the same conclusion as you,
the connotation of turning the display off does not feel right.
>
> Reviewed-by: Jonathan Neuschäfer
>
> Thanks
Regards,
Andreas
[PATCH v3] power: supply: Add support for RN5T618/RC5T619 charger and fuel gauge
Both chips have charger and a fuel gauge.
This adds basic support for displaying the state of the battery and the
input power, settings are not modified. There are some defaults set via
OTP.
Charging also starts after plugging USB.
Known issues of the fuel gauge: There are drivers in the wild which disable
the fuel gauge at shutdown. If a kernel is booted without fuel gauge
support, after such a driver has been used, the fuel gauge will stay off
and decalibrate.
If this driver is used after that, it might display wrong values for charge
level.
Signed-off-by: Andreas Kemnade
---
Changes in v3:
- punctuation fixed
Changes in v2:
- patch 2/2 is already accepted, so it is not included, this
one can be applied independantly
- cleanup of sign handling
- adp properties fixed
drivers/power/supply/Kconfig | 8 +
drivers/power/supply/Makefile| 1 +
drivers/power/supply/rn5t618_power.c | 556 +++
3 files changed, 565 insertions(+)
create mode 100644 drivers/power/supply/rn5t618_power.c
diff --git a/drivers/power/supply/Kconfig b/drivers/power/supply/Kconfig
index 44d3c8512fb8..1117a79860b6 100644
--- a/drivers/power/supply/Kconfig
+++ b/drivers/power/supply/Kconfig
@@ -739,4 +739,12 @@ config CHARGER_WILCO
information can be found in
Documentation/ABI/testing/sysfs-class-power-wilco
+config RN5T618_POWER
+ tristate "RN5T618 charger/fuel gauge support"
+ depends on MFD_RN5T618
+ help
+ Say Y here to have support for RN5T618 PMIC family fuel gauge and
charger.
+ This driver can also be built as a module. If so, the module will be
+ called rn5t618_power.
+
endif # POWER_SUPPLY
diff --git a/drivers/power/supply/Makefile b/drivers/power/supply/Makefile
index b9644663e435..23866b6ccdae 100644
--- a/drivers/power/supply/Makefile
+++ b/drivers/power/supply/Makefile
@@ -95,3 +95,4 @@ obj-$(CONFIG_CHARGER_UCS1002) += ucs1002_power.o
obj-$(CONFIG_CHARGER_BD70528) += bd70528-charger.o
obj-$(CONFIG_CHARGER_BD99954) += bd99954-charger.o
obj-$(CONFIG_CHARGER_WILCO)+= wilco-charger.o
+obj-$(CONFIG_RN5T618_POWER)+= rn5t618_power.o
diff --git a/drivers/power/supply/rn5t618_power.c
b/drivers/power/supply/rn5t618_power.c
new file mode 100644
index ..424d2817bee5
--- /dev/null
+++ b/drivers/power/supply/rn5t618_power.c
@@ -0,0 +1,556 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Power supply driver for the RICOH RN5T618 power management chip family
+ *
+ * Copyright (C) 2020 Andreas Kemnade
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define CHG_STATE_ADP_INPUT 0x40
+#define CHG_STATE_USB_INPUT 0x80
+#define CHG_STATE_MASK 0x1f
+#define CHG_STATE_CHG_OFF 0
+#define CHG_STATE_CHG_READY_VADP 1
+#define CHG_STATE_CHG_TRICKLE 2
+#define CHG_STATE_CHG_RAPID3
+#define CHG_STATE_CHG_COMPLETE 4
+#define CHG_STATE_SUSPEND 5
+#define CHG_STATE_VCHG_OVER_VOL6
+#define CHG_STATE_BAT_ERROR7
+#define CHG_STATE_NO_BAT 8
+#define CHG_STATE_BAT_OVER_VOL 9
+#define CHG_STATE_BAT_TEMP_ERR 10
+#define CHG_STATE_DIE_ERR 11
+#define CHG_STATE_DIE_SHUTDOWN 12
+#define CHG_STATE_NO_BAT2 13
+#define CHG_STATE_CHG_READY_VUSB 14
+
+#define FG_ENABLE 1
+
+struct rn5t618_power_info {
+ struct rn5t618 *rn5t618;
+ struct platform_device *pdev;
+ struct power_supply *battery;
+ struct power_supply *usb;
+ struct power_supply *adp;
+ int irq;
+};
+
+static enum power_supply_property rn5t618_usb_props[] = {
+ POWER_SUPPLY_PROP_STATUS,
+ POWER_SUPPLY_PROP_ONLINE,
+};
+
+static enum power_supply_property rn5t618_adp_props[] = {
+ POWER_SUPPLY_PROP_STATUS,
+ POWER_SUPPLY_PROP_ONLINE,
+};
+
+
+static enum power_supply_property rn5t618_battery_props[] = {
+ POWER_SUPPLY_PROP_STATUS,
+ POWER_SUPPLY_PROP_PRESENT,
+ POWER_SUPPLY_PROP_VOLTAGE_NOW,
+ POWER_SUPPLY_PROP_CURRENT_NOW,
+ POWER_SUPPLY_PROP_CAPACITY,
+ POWER_SUPPLY_PROP_TEMP,
+ POWER_SUPPLY_PROP_TIME_TO_EMPTY_NOW,
+ POWER_SUPPLY_PROP_TIME_TO_FULL_NOW,
+ POWER_SUPPLY_PROP_TECHNOLOGY,
+ POWER_SUPPLY_PROP_CHARGE_FULL,
+ POWER_SUPPLY_PROP_CHARGE_NOW,
+};
+
+static int rn5t618_battery_read_doublereg(struct rn5t618_power_info *info,
+ u8 reg, u16 *result)
+{
+ int ret, i;
+ u8 data[2];
+ u16 old, new;
+
+ old = 0;
+ /* Prevent races when registers are changing. */
+ for (i = 0; i < 3; i++) {
+ ret = regmap_bulk_read(info->rn5t618->regmap,
+ reg, data, sizeof(data));
+ if (ret)
+ return ret;
+
+ new = data[0] << 8;
+ new |= data[1];
+ if (new == old)
+ bre
[PATCH v2] power: supply: Add support for RN5T618/RC5T619 charger and fuel gauge
Both chips have charger and a fuel gauge.
This adds basic support for displaying the state of the battery and the
input power, settings are not modified. There are some defaults set via
OTP.
Charging also starts after plugging USB.
Known issues of the fuel gauge: There are drivers in the wild which disable
the fuel gauge at shutdown. If a kernel is booted without fuel gauge
support, after such a driver has been used, the fuel gauge will stay off
and decalibrate.
If this driver is used after that, it might display wrong values for charge
level.
Signed-off-by: Andreas Kemnade
---
Changes in v2:
- patch 2/2 is already accepted, so it is not included, this
one can be applied independantly
- cleanup of sign handling
- adp properties fixed
drivers/power/supply/Kconfig | 8 +
drivers/power/supply/Makefile| 1 +
drivers/power/supply/rn5t618_power.c | 556 +++
3 files changed, 565 insertions(+)
create mode 100644 drivers/power/supply/rn5t618_power.c
diff --git a/drivers/power/supply/Kconfig b/drivers/power/supply/Kconfig
index 44d3c8512fb8..28cea178f6f1 100644
--- a/drivers/power/supply/Kconfig
+++ b/drivers/power/supply/Kconfig
@@ -739,4 +739,12 @@ config CHARGER_WILCO
information can be found in
Documentation/ABI/testing/sysfs-class-power-wilco
+config RN5T618_POWER
+ tristate "RN5T618 charger/fuel gauge support"
+ depends on MFD_RN5T618
+ help
+ Say Y here to have support for RN5T618 PMIC family fuel gauge and
charger
+ This driver can also be built as a module. If so, the module will be
+ called rn5t618_power.
+
endif # POWER_SUPPLY
diff --git a/drivers/power/supply/Makefile b/drivers/power/supply/Makefile
index b9644663e435..23866b6ccdae 100644
--- a/drivers/power/supply/Makefile
+++ b/drivers/power/supply/Makefile
@@ -95,3 +95,4 @@ obj-$(CONFIG_CHARGER_UCS1002) += ucs1002_power.o
obj-$(CONFIG_CHARGER_BD70528) += bd70528-charger.o
obj-$(CONFIG_CHARGER_BD99954) += bd99954-charger.o
obj-$(CONFIG_CHARGER_WILCO)+= wilco-charger.o
+obj-$(CONFIG_RN5T618_POWER)+= rn5t618_power.o
diff --git a/drivers/power/supply/rn5t618_power.c
b/drivers/power/supply/rn5t618_power.c
new file mode 100644
index ..424d2817bee5
--- /dev/null
+++ b/drivers/power/supply/rn5t618_power.c
@@ -0,0 +1,556 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Power supply driver for the RICOH RN5T618 power management chip family
+ *
+ * Copyright (C) 2020 Andreas Kemnade
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define CHG_STATE_ADP_INPUT 0x40
+#define CHG_STATE_USB_INPUT 0x80
+#define CHG_STATE_MASK 0x1f
+#define CHG_STATE_CHG_OFF 0
+#define CHG_STATE_CHG_READY_VADP 1
+#define CHG_STATE_CHG_TRICKLE 2
+#define CHG_STATE_CHG_RAPID3
+#define CHG_STATE_CHG_COMPLETE 4
+#define CHG_STATE_SUSPEND 5
+#define CHG_STATE_VCHG_OVER_VOL6
+#define CHG_STATE_BAT_ERROR7
+#define CHG_STATE_NO_BAT 8
+#define CHG_STATE_BAT_OVER_VOL 9
+#define CHG_STATE_BAT_TEMP_ERR 10
+#define CHG_STATE_DIE_ERR 11
+#define CHG_STATE_DIE_SHUTDOWN 12
+#define CHG_STATE_NO_BAT2 13
+#define CHG_STATE_CHG_READY_VUSB 14
+
+#define FG_ENABLE 1
+
+struct rn5t618_power_info {
+ struct rn5t618 *rn5t618;
+ struct platform_device *pdev;
+ struct power_supply *battery;
+ struct power_supply *usb;
+ struct power_supply *adp;
+ int irq;
+};
+
+static enum power_supply_property rn5t618_usb_props[] = {
+ POWER_SUPPLY_PROP_STATUS,
+ POWER_SUPPLY_PROP_ONLINE,
+};
+
+static enum power_supply_property rn5t618_adp_props[] = {
+ POWER_SUPPLY_PROP_STATUS,
+ POWER_SUPPLY_PROP_ONLINE,
+};
+
+
+static enum power_supply_property rn5t618_battery_props[] = {
+ POWER_SUPPLY_PROP_STATUS,
+ POWER_SUPPLY_PROP_PRESENT,
+ POWER_SUPPLY_PROP_VOLTAGE_NOW,
+ POWER_SUPPLY_PROP_CURRENT_NOW,
+ POWER_SUPPLY_PROP_CAPACITY,
+ POWER_SUPPLY_PROP_TEMP,
+ POWER_SUPPLY_PROP_TIME_TO_EMPTY_NOW,
+ POWER_SUPPLY_PROP_TIME_TO_FULL_NOW,
+ POWER_SUPPLY_PROP_TECHNOLOGY,
+ POWER_SUPPLY_PROP_CHARGE_FULL,
+ POWER_SUPPLY_PROP_CHARGE_NOW,
+};
+
+static int rn5t618_battery_read_doublereg(struct rn5t618_power_info *info,
+ u8 reg, u16 *result)
+{
+ int ret, i;
+ u8 data[2];
+ u16 old, new;
+
+ old = 0;
+ /* Prevent races when registers are changing. */
+ for (i = 0; i < 3; i++) {
+ ret = regmap_bulk_read(info->rn5t618->regmap,
+ reg, data, sizeof(data));
+ if (ret)
+ return ret;
+
+ new = data[0] << 8;
+ new |= data[1];
+ if (new == old)
+ break;
+
+ old = new;
+
Re: [PATCH 1/2] power: supply: Add support for RN5T618/RC5T619 charger and fuel gauge
Hi,
On Wed, 26 Aug 2020 23:59:50 +0200
Sebastian Reichel wrote:
> Hi,
>
> On Wed, Aug 26, 2020 at 08:28:34PM +0200, Andreas Kemnade wrote:
> > On Wed, 26 Aug 2020 19:48:17 +0200
> > Sebastian Reichel wrote:
> > > On Sat, Aug 15, 2020 at 06:56:09PM +0200, Andreas Kemnade wrote:
> > > > [...]
> > > > +static int rn5t618_battery_current_now(struct rn5t618_power_info *info,
> > > > + union power_supply_propval *val)
> > > > +{
> > > > + u16 res;
> > > > + int ret;
> > > > +
> > > > + ret = rn5t618_battery_read_doublereg(info, RN5T618_CC_AVEREG1,
> > > > &res);
> > > > + if (ret)
> > > > + return ret;
> > > > +
> > > > + val->intval = res;
> > > > + /* 2's complement */
> > > > + if (val->intval & (1 << 13))
> > > > + val->intval = val->intval - (1 << 14);
>
> Btw. I think sign_extend32() can be used here?
>
> > > > + /* negate current to be positive when discharging */
> > > > + val->intval *= -1000;
> > >
> > > mh, the sign is not documented (which should be fixed). At least
> > > sbs-battery does it the other way around (negative current when
> > > discharging, positive otherwise). Some drivers do not support
> > > signed current and always report positive values (e.g. ACPI driver).
> > >
> > > What did you use as reference for swapping the sign?
> > >
> > Well, I have searched for documentation, found nothing and used the
> > bq27xxx driver as reference which I am used to from the GTA04/GTA02,
> > so things behave equal. That are the devices where a was most
> > intensively looking at those values.
> > I thought that there would be some unwritten rule about that.
>
> The mess is mostly due to lacking reviewing from my side
> (and possibly my predecessors). I just went through a dozen of
> drivers and it looks like most either do not support signed current
> (and use negative values as error code :() or use negative current
> for discharge. I could not find any other driver using negative
> numbers for charging. I think it's best to negative = discharge as
> official correct value and will send an update patch for the
> documentation later.
>
ok, I will remove that sign-change and keep/update the comment
so that you know that the driver does it the official way
and send a v2 with the other things you mentioned.
Regards,
Andreas
pgp5ljy2PRtrW.pgp
Description: OpenPGP digital signature
[PATCH v2 2/2] ARM: dts: imx: add devicetree for Tolino Shine 2 HD
This adds a devicetree for the Tolino Shine 2 HD Ebook reader. It is based
on boards marked with "37NB-E60QF0+4A2". It is equipped with an i.MX6SL
SoC.
Expected to work:
- Buttons
- Wifi
- Touchscreen
- LED
- uSD
- USB
- RTC
Not working due to missing drivers:
- Backlight (requires NTXEC driver)
- EPD
Not working due to unknown reasons:
- deep sleep (echo standby >/sys/power/state works),
wakeup fails when imx_gpc_pre_suspend(true) was called.
Signed-off-by: Andreas Kemnade
---
Changes in v2:
- better comments about internals
- avoid confusion about polarity of wifi enable pin
- newline cleanup
arch/arm/boot/dts/Makefile | 1 +
arch/arm/boot/dts/imx6sl-tolino-shine2hd.dts | 588 +++
2 files changed, 589 insertions(+)
create mode 100644 arch/arm/boot/dts/imx6sl-tolino-shine2hd.dts
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index e6a1cac0bfc7..c65fa3852246 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -581,6 +581,7 @@ dtb-$(CONFIG_SOC_IMX6Q) += \
imx6qp-zii-rdu2.dtb
dtb-$(CONFIG_SOC_IMX6SL) += \
imx6sl-evk.dtb \
+ imx6sl-tolino-shine2hd.dtb \
imx6sl-tolino-shine3.dtb \
imx6sl-warp.dtb
dtb-$(CONFIG_SOC_IMX6SLL) += \
diff --git a/arch/arm/boot/dts/imx6sl-tolino-shine2hd.dts
b/arch/arm/boot/dts/imx6sl-tolino-shine2hd.dts
new file mode 100644
index ..caa279608803
--- /dev/null
+++ b/arch/arm/boot/dts/imx6sl-tolino-shine2hd.dts
@@ -0,0 +1,588 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Device tree for the Tolino Shine 2 HD ebook reader
+ *
+ * Name on mainboard is: 37NB-E60QF0+4A2 or 37NB-E60QF0+4A3
+ * Serials start with: E60QF2
+ *
+ * Copyright 2020 Andreas Kemnade
+ */
+
+/dts-v1/;
+
+#include
+#include
+#include "imx6sl.dtsi"
+
+/ {
+ model = "Tolino Shine 2 HD";
+ compatible = "kobo,tolino-shine2hd", "fsl,imx6sl";
+
+ chosen {
+ stdout-path = &uart1;
+ };
+
+ gpio_keys: gpio-keys {
+ compatible = "gpio-keys";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_gpio_keys>;
+
+ cover {
+ label = "Cover";
+ gpios = <&gpio5 12 GPIO_ACTIVE_LOW>;
+ linux,code = ;
+ linux,input-type = ;
+ wakeup-source;
+ };
+
+ fl {
+ label = "Frontlight";
+ gpios = <&gpio3 26 GPIO_ACTIVE_LOW>;
+ linux,code = ;
+ };
+
+ home {
+ label = "Home";
+ gpios = <&gpio3 25 GPIO_ACTIVE_LOW>;
+ linux,code = ;
+ };
+
+ power {
+ label = "Power";
+ gpios = <&gpio5 8 GPIO_ACTIVE_LOW>;
+ linux,code = ;
+ wakeup-source;
+ };
+ };
+
+ leds: leds {
+ compatible = "gpio-leds";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_led>;
+
+ on {
+ label = "tolinoshine2hd:white:on";
+ gpios = <&gpio5 13 GPIO_ACTIVE_LOW>;
+ linux,default-trigger = "timer";
+ };
+ };
+
+ memory@8000 {
+ device_type = "memory";
+ reg = <0x8000 0x2000>;
+ };
+
+ reg_wifi: regulator-wifi {
+ compatible = "regulator-fixed";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_wifi_power>;
+ regulator-name = "SD3_SPWR";
+ regulator-min-microvolt = <300>;
+ regulator-max-microvolt = <300>;
+ gpio = <&gpio4 29 GPIO_ACTIVE_LOW>;
+ };
+
+ wifi_pwrseq: wifi_pwrseq {
+ compatible = "mmc-pwrseq-simple";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_wifi_reset>;
+ post-power-on-delay-ms = <20>;
+ reset-gpios = <&gpio5 0 GPIO_ACTIVE_LOW>;
+ };
+};
+
+&i2c1 {
+ pinctrl-names = "default","sleep";
+ pinctrl-0 = <&pinctrl_i2c1>;
+ pinctrl-1 = <&pinctrl_i2c1_sleep>;
+ status = "okay";
+
+ /* TODO: embedded controller at 0x43 (driver missing) */
+
+};
+
+&i2c2 {
+ pinctrl-names = "default","sleep";
+ pinctrl-0 = <&pinctrl_i2c2
[PATCH v2 1/2] dt-bindings: arm: fsl: add compatible string for Tolino Shine 2 HD
This adds a compatible string for the Tolino Shine 2 HD eBook reader. Signed-off-by: Andreas Kemnade Acked-by: Rob Herring --- Documentation/devicetree/bindings/arm/fsl.yaml | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/arm/fsl.yaml b/Documentation/devicetree/bindings/arm/fsl.yaml index 05906e291e38..a3fb61868a16 100644 --- a/Documentation/devicetree/bindings/arm/fsl.yaml +++ b/Documentation/devicetree/bindings/arm/fsl.yaml @@ -211,6 +211,7 @@ properties: items: - enum: - fsl,imx6sl-evk# i.MX6 SoloLite EVK Board + - kobo,tolino-shine2hd - kobo,tolino-shine3 - const: fsl,imx6sl -- 2.20.1
[PATCH v2 0/2] ARM: dts: add Tolino Shine 2 HD
This adds a device tree for the Tolino Shine 2 HD Ebook reader. It is equipped with an i.MX6SL SoC. Except for backlight (via an EC) and the EPD, drivers are available and therefore things are defined in the dts. Andreas Kemnade (2): dt-bindings: arm: fsl: add compatible string for Tolino Shine 2 HD ARM: dts: imx: add devicetree for Tolino Shine 2 HD .../devicetree/bindings/arm/fsl.yaml | 1 + arch/arm/boot/dts/Makefile| 1 + arch/arm/boot/dts/imx6sl-tolino-shine2hd.dts | 588 ++ 3 files changed, 590 insertions(+) create mode 100644 arch/arm/boot/dts/imx6sl-tolino-shine2hd.dts -- 2.20.1
Re: [PATCH 1/2] power: supply: Add support for RN5T618/RC5T619 charger and fuel gauge
On Wed, 26 Aug 2020 19:48:17 +0200
Sebastian Reichel wrote:
> Hi,
>
> Driver looks mostly good.
>
> On Sat, Aug 15, 2020 at 06:56:09PM +0200, Andreas Kemnade wrote:
> > [...]
> > +static int rn5t618_battery_current_now(struct rn5t618_power_info *info,
> > + union power_supply_propval *val)
> > +{
> > + u16 res;
> > + int ret;
> > +
> > + ret = rn5t618_battery_read_doublereg(info, RN5T618_CC_AVEREG1, &res);
> > + if (ret)
> > + return ret;
> > +
> > + val->intval = res;
> > + /* 2's complement */
> > + if (val->intval & (1 << 13))
> > + val->intval = val->intval - (1 << 14);
> > +
> > + /* negate current to be positive when discharging */
> > + val->intval *= -1000;
>
> mh, the sign is not documented (which should be fixed). At least
> sbs-battery does it the other way around (negative current when
> discharging, positive otherwise). Some drivers do not support
> signed current and always report positive values (e.g. ACPI driver).
>
> What did you use as reference for swapping the sign?
>
Well, I have searched for documentation, found nothing and used the
bq27xxx driver as reference which I am used to from the GTA04/GTA02,
so things behave equal. That are the devices where a was most
intensively looking at those values.
I thought that there would be some unwritten rule about that.
Regards,
Andreas
Re: [PATCH RFC 2/2] ARM: dts: imx: add devicetree for Tolino Shine 2 HD
On Sun, 16 Aug 2020 14:54:41 +0200
Jonathan Neuschäfer wrote:
> On Sat, Aug 15, 2020 at 09:33:36PM +0200, Andreas Kemnade wrote:
> > This adds a devicetree for the Tolino Shine 2 HD Ebook reader. It is based
> > on boards marked with "37NB-E60QF0+4A2". It is equipped with an i.MX6SL
> > SoC.
> >
> > Expected to work:
> > - Buttons
> > - Wifi
> > - Touchscreen
> > - LED
> > - uSD
> > - USB
> > - RTC
> >
> > Not working due to missing drivers:
> > - Backlight (requires NTXEC driver)
> > - EPD
> >
> > Not working due to unknown reasons:
> > - deep sleep (echo standby >/sys/power/state works),
> > wakeup fails when imx_gpc_pre_suspend(true) was called.
> >
> > Signed-off-by: Andreas Kemnade
> > ---
> > Reason for RFC: The suspend trouble might be caused by bad devicetree.
> > But as the devicetree is already useful I decided to submit it.
> [...]
> > +++ b/arch/arm/boot/dts/imx6sl-tolino-shine2hd.dts
> > @@ -0,0 +1,582 @@
> > +// SPDX-License-Identifier: (GPL-2.0)
>
> I don't think the parentheses are required when you don't have a logical
> operator (OR) in the SPDX expression.
>
> > +&i2c1 {
> > + pinctrl-names = "default","sleep";
> > + pinctrl-0 = <&pinctrl_i2c1>;
> > + pinctrl-1 = <&pinctrl_i2c1_sleep>;
> > + status = "okay";
> > +
> > + /* TODO: embedded controller at 0x43 (driver missing) */
>
> Sorry for the delay, BTW. I'm still (slowly) working on v2.
>
> > + ricoh619: pmic@32 {
> > + compatible = "ricoh,rc5t619";
> > + pinctrl-names = "default";
> > + pinctrl-0 = <&pinctrl_ricoh_gpio>;
> > + reg = <0x32>;
> > + interrupt-parent = <&gpio5>;
> > + interrupts = <11 IRQ_TYPE_EDGE_FALLING>;
> > + system-power-controller;
> > +
> > + regulators {
>
> How did you derive the regulator voltages?
>
Several sources:
- deriving from the existing device trees,
- looking for board specific variances in
board-mx6sl_ntx.c of the Tolino kernel,
- looking for comments in the file.
I compared a register dump of the PMIC from both the vendor kernel
and my devicetree and found no significant differences.
> > + pinctrl_hog: hoggrp {
> > + fsl,pins = <
> > + MX6SL_PAD_LCD_DAT0__GPIO2_IO20 0x79
> > + MX6SL_PAD_LCD_DAT1__GPIO2_IO21 0x79
> > + MX6SL_PAD_LCD_DAT2__GPIO2_IO22 0x79
> > + MX6SL_PAD_LCD_DAT3__GPIO2_IO23 0x79
> > + MX6SL_PAD_LCD_DAT4__GPIO2_IO24 0x79
> > + MX6SL_PAD_LCD_DAT5__GPIO2_IO25 0x79
> > + MX6SL_PAD_LCD_DAT6__GPIO2_IO26 0x79
> > + MX6SL_PAD_LCD_DAT7__GPIO2_IO27 0x79
> > + MX6SL_PAD_LCD_DAT8__GPIO2_IO28 0x79
> > + MX6SL_PAD_LCD_DAT9__GPIO2_IO29 0x79
> > + MX6SL_PAD_LCD_DAT10__GPIO2_IO30 0x79
> > + MX6SL_PAD_LCD_DAT11__GPIO2_IO31 0x79
> > + MX6SL_PAD_LCD_DAT12__GPIO3_IO00 0x79
> > + MX6SL_PAD_LCD_DAT13__GPIO3_IO01 0x79
> > + MX6SL_PAD_LCD_DAT14__GPIO3_IO02 0x79
> > + MX6SL_PAD_LCD_DAT15__GPIO3_IO03 0x79
> > + MX6SL_PAD_LCD_DAT16__GPIO3_IO04 0x79
> > + MX6SL_PAD_LCD_DAT17__GPIO3_IO05 0x79
> > + MX6SL_PAD_LCD_DAT18__GPIO3_IO06 0x79
> > + MX6SL_PAD_LCD_DAT19__GPIO3_IO07 0x79
> > + MX6SL_PAD_LCD_DAT20__GPIO3_IO08 0x79
> > + MX6SL_PAD_LCD_DAT21__GPIO3_IO09 0x79
> > + MX6SL_PAD_LCD_DAT22__GPIO3_IO10 0x79
> > + MX6SL_PAD_LCD_DAT23__GPIO3_IO11 0x79
> > + MX6SL_PAD_LCD_CLK__GPIO2_IO15 0x79
> > + MX6SL_PAD_LCD_ENABLE__GPIO2_IO160x79
> > + MX6SL_PAD_LCD_HSYNC__GPIO2_IO17 0x79
> > + MX6SL_PAD_LCD_VSYNC__GPIO2_IO18 0x79
> > + MX6SL_PAD_LCD_RESET__GPIO2_IO19 0x79
> > + MX6SL_PAD_KEY_COL3__GPIO3_IO30 0x79
> > + MX6SL_PAD_KEY_ROW7__GPIO4_IO07 0x79
> > + MX6SL_PAD_ECSPI2_MOSI__GPIO4_IO13 0x79
> > + MX6SL_PAD_KEY_COL5__GPIO4_IO02 0x79
> > + MX6SL_PAD_KEY_ROW6__GPIO4_IO05 0x79
> > + >;
> > + };
>
> Why are there so many hogged pins? Will some of them receive a proper
> configuration once the EPDC driver is implemented?
>
I copied them over and found no hints in the
Tolino kernel that it is a bad idea.
Regards,
Andreas
Re: [PATCH RFC 2/2] ARM: dts: imx: add devicetree for Tolino Shine 2 HD
On Sun, 23 Aug 2020 09:42:31 +0800
Shawn Guo wrote:
> On Sat, Aug 15, 2020 at 09:33:36PM +0200, Andreas Kemnade wrote:
> > This adds a devicetree for the Tolino Shine 2 HD Ebook reader. It is based
> > on boards marked with "37NB-E60QF0+4A2". It is equipped with an i.MX6SL
> > SoC.
> >
> > Expected to work:
> > - Buttons
> > - Wifi
> > - Touchscreen
> > - LED
> > - uSD
> > - USB
> > - RTC
> >
> > Not working due to missing drivers:
> > - Backlight (requires NTXEC driver)
> > - EPD
> >
> > Not working due to unknown reasons:
> > - deep sleep (echo standby >/sys/power/state works),
> > wakeup fails when imx_gpc_pre_suspend(true) was called.
> >
> > Signed-off-by: Andreas Kemnade
> > ---
> > Reason for RFC: The suspend trouble might be caused by bad devicetree.
> > But as the devicetree is already useful I decided to submit it.
> >
> > arch/arm/boot/dts/Makefile | 1 +
> > arch/arm/boot/dts/imx6sl-tolino-shine2hd.dts | 582 +++
> > 2 files changed, 583 insertions(+)
> > create mode 100644 arch/arm/boot/dts/imx6sl-tolino-shine2hd.dts
> >
> > diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
> > index e6a1cac0bfc7..c65fa3852246 100644
> > --- a/arch/arm/boot/dts/Makefile
> > +++ b/arch/arm/boot/dts/Makefile
> > @@ -581,6 +581,7 @@ dtb-$(CONFIG_SOC_IMX6Q) += \
> > imx6qp-zii-rdu2.dtb
> > dtb-$(CONFIG_SOC_IMX6SL) += \
> > imx6sl-evk.dtb \
> > + imx6sl-tolino-shine2hd.dtb \
> > imx6sl-tolino-shine3.dtb \
> > imx6sl-warp.dtb
> > dtb-$(CONFIG_SOC_IMX6SLL) += \
> > diff --git a/arch/arm/boot/dts/imx6sl-tolino-shine2hd.dts
> > b/arch/arm/boot/dts/imx6sl-tolino-shine2hd.dts
> > new file mode 100644
> > index ..7b28e19a1d98
> > --- /dev/null
> > +++ b/arch/arm/boot/dts/imx6sl-tolino-shine2hd.dts
> > @@ -0,0 +1,582 @@
> > +// SPDX-License-Identifier: (GPL-2.0)
> > +/*
> > + * Device tree for the Tolino Shine 2 HD ebook reader
> > + *
> > + * Name on mainboard is: 37NB-E60QF0+4A2
> > + * Serials start with: E60QF2
> > + *
> > + * Copyright 2020 Andreas Kemnade
> > + */
> > +
> > +/dts-v1/;
> > +
> > +#include
> > +#include
> > +#include "imx6sl.dtsi"
> > +
> > +/ {
> > + model = "Tolino Shine 2 HD";
> > + compatible = "kobo,tolino-shine2hd", "fsl,imx6sl";
> > +
> > + chosen {
> > + stdout-path = &uart1;
> > + };
> > +
> > + gpio_keys: gpio-keys {
> > + compatible = "gpio-keys";
> > + pinctrl-names = "default";
> > + pinctrl-0 = <&pinctrl_gpio_keys>;
> > +
> > + cover {
> > + label = "Cover";
> > + gpios = <&gpio5 12 GPIO_ACTIVE_LOW>;
> > + linux,code = ;
> > + linux,input-type = ;
> > + wakeup-source;
> > + };
> > +
> > + fl {
> > + label = "Frontlight";
> > + gpios = <&gpio3 26 GPIO_ACTIVE_LOW>;
> > + linux,code = ;
> > + };
> > +
> > + home {
> > + label = "Home";
> > + gpios = <&gpio3 25 GPIO_ACTIVE_LOW>;
> > + linux,code = ;
> > + };
> > +
> > + power {
> > + label = "Power";
> > + gpios = <&gpio5 8 GPIO_ACTIVE_LOW>;
> > + linux,code = ;
> > + wakeup-source;
> > + };
> > + };
> > +
> > + leds: leds {
> > + compatible = "gpio-leds";
> > + pinctrl-names = "default";
> > + pinctrl-0 = <&pinctrl_led>;
> > +
> > + on {
> > + label = "tolinoshine2hd:white:on";
> > + gpios = <&gpio5 13 GPIO_ACTIVE_LOW>;
> > + linux,default-trigger = "timer";
> > + };
> > + };
> > +
> > + memory@8000 {
> > + device_type = "memory";
> > + reg = <0x8000 0x2000>;
> > + };
> > +
> > + reg_wifi: regulator-wifi {
> > + compatible = "regulator-fixed";
> > + pinctrl-names = "default";
> > + pinctrl-0 = <&pinctrl_wifi_power>;
> > + regulator-name = "SD3_SPWR";
> > + regulator-min-microvolt = <300>;
> > + regulator-max-microvolt = <300>;
> > + gpio = <&gpio4 29 GPIO_ACTIVE_HIGH>;
>
> Missing enable-active-high?
>
no. I should rather use GPIO_ACTIVE_LOW to avoid that confusion.
corresponding code in vendor kernel is the function
_ntx_wifi_power_ctrl()
Regards,
Andreas
Re: [PATCH V2 1/2] thermal: ti-soc-thermal: Enable addition power management
On Wed, 19 Aug 2020 07:59:23 -0500
Adam Ford wrote:
> The bandgap sensor can be idled when the processor is too, but it
> isn't currently being done, so the power consumption of OMAP3
> boards can elevated if the bangap sensor is enabled.
>
> This patch attempts to use some additional power management
> to idle the clock to the bandgap when not needed.
>
> Signed-off-by: Adam Ford
> Reported-by: kernel test robot
> ---
> V2: Fix issue where variable stating the suspend mode isn't being
> properly set and cleared.
>
I get
root@(none):/# cat /sys/class/thermal/thermal_zone0/type
cpu_thermal
root@(none):/# cat /sys/class/thermal/thermal_zone0/temp
5
root@(none):/# cat /sys/class/thermal/thermal_zone1/
available_policies modesubsystem/
integral_cutoff offset sustainable_power
k_d passive temp
k_i policy type
k_popower/ uevent
k_puslope
root@(none):/# cat /sys/class/thermal/thermal_zone1/type
bq27000-battery
root@(none):/# cat /sys/kernel/debug/pm_debug/count
usbhost_pwrdm
(ON),OFF:3459,RET:635,INA:0,ON:4095,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0
sgx_pwrdm (OFF),OFF:1,RET:0,INA:1,ON:2,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0
core_pwrdm
(ON),OFF:86,RET:7,INA:0,ON:94,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0,RET-MEMBANK2-OFF:0
per_pwrdm (ON),OFF:1518,RET:64,INA:0,ON:1583,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0
dss_pwrdm (ON),OFF:3459,RET:635,INA:0,ON:4095,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0
cam_pwrdm (OFF),OFF:1,RET:1,INA:0,ON:2,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0
neon_pwrdm (ON),OFF:2845,RET:1131,INA:119,ON:4096,RET-LOGIC-OFF:0
mpu_pwrdm
(ON),OFF:2845,RET:1130,INA:119,ON:4095,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0
iva2_pwrdm
(OFF),OFF:1,RET:1,INA:0,ON:2,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0,RET-MEMBANK2-OFF:0,RET-MEMBANK3-OFF:0,RET-MEMBANK4-OFF:0
usbhost_clkdm->usbhost_pwrdm (1)
sgx_clkdm->sgx_pwrdm (0)
per_clkdm->per_pwrdm (13)
cam_clkdm->cam_pwrdm (0)
dss_clkdm->dss_pwrdm (1)
d2d_clkdm->core_pwrdm (0)
iva2_clkdm->iva2_pwrdm (0)
mpu_clkdm->mpu_pwrdm (0)
core_l4_clkdm->core_pwrdm (20)
core_l3_clkdm->core_pwrdm (1)
neon_clkdm->neon_pwrdm (0)
root@(none):/#
So things still turn off.
Tested-by: Andreas Kemnade # GTA04
> diff --git a/drivers/thermal/ti-soc-thermal/ti-bandgap.c
> b/drivers/thermal/ti-soc-thermal/ti-bandgap.c
> index ab19ceff6e2a..9404631bea4d 100644
> --- a/drivers/thermal/ti-soc-thermal/ti-bandgap.c
> +++ b/drivers/thermal/ti-soc-thermal/ti-bandgap.c
> @@ -25,10 +25,18 @@
> #include
> #include
> #include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
>
> #include "ti-bandgap.h"
>
> static int ti_bandgap_force_single_read(struct ti_bandgap *bgp, int id);
> +static int bandgap_omap_cpu_notifier(struct notifier_block *nb,
> + unsigned long cmd, void *v);
>
> /*** Helper functions to access registers and their bitfields ***/
>
> @@ -1008,6 +1016,9 @@ int ti_bandgap_probe(struct platform_device *pdev)
> }
> }
>
> + bgp->nb.notifier_call = bandgap_omap_cpu_notifier;
> + cpu_pm_register_notifier(&bgp->nb);
> +
> return 0;
>
> remove_last_cooling:
> @@ -1041,7 +1052,9 @@ int ti_bandgap_remove(struct platform_device *pdev)
> struct ti_bandgap *bgp = platform_get_drvdata(pdev);
> int i;
>
> - /* First thing is to remove sensor interfaces */
> + cpu_pm_unregister_notifier(&bgp->nb);
> +
> + /* Remove sensor interfaces */
> for (i = 0; i < bgp->conf->sensor_count; i++) {
> if (bgp->conf->sensors[i].unregister_cooling)
> bgp->conf->sensors[i].unregister_cooling(bgp, i);
> @@ -1150,9 +1163,43 @@ static int ti_bandgap_suspend(struct device *dev)
> if (TI_BANDGAP_HAS(bgp, CLK_CTRL))
> clk_disable_unprepare(bgp->fclock);
>
> + bgp->is_suspended = true;
> +
> return err;
> }
>
> +static int bandgap_omap_cpu_notifier(struct notifier_block *nb,
> + unsigned long cmd, void *v)
> +{
> + struct ti_bandgap *bgp;
> +
> + bgp = container_of(nb, struct ti_bandgap, nb);
> +
> + spin_lock(&bgp->lock);
> + switch (cmd) {
> + case CPU_CLUSTER_PM_ENTER:
> + if (bgp->is_suspended)
> + break;
> + ti_bandgap_save_ctxt(bgp);
> + ti_bandgap_power(bgp, false);
> + if (TI_BANDGAP_HAS(bgp, CLK_CTRL))
> + clk_disable(bgp->fclock);
> + bre
[PATCH] ARM: omap2plus_defconfig: enable twl4030_madc as a loadable module
The ADC is used by twl4030_charger to read voltages. If a dtb contains the ADC but the module is not build, probing twl4030_charger will be endlessly deferred, so just enable CONFIG_TWL4030_MADC in the config. Signed-off-by: Andreas Kemnade --- arch/arm/configs/omap2plus_defconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm/configs/omap2plus_defconfig b/arch/arm/configs/omap2plus_defconfig index fe383f5a92fb..c9a32000f1d4 100644 --- a/arch/arm/configs/omap2plus_defconfig +++ b/arch/arm/configs/omap2plus_defconfig @@ -510,6 +510,7 @@ CONFIG_IIO_ST_ACCEL_3AXIS=m CONFIG_CPCAP_ADC=m CONFIG_INA2XX_ADC=m CONFIG_TI_AM335X_ADC=m +CONFIG_TWL4030_MADC=m CONFIG_SENSORS_ISL29028=m CONFIG_BMP280=m CONFIG_PWM=y -- 2.20.1
Re: [PATCH V2] ARM: dts: omap3: Add cpu trips and cooling map for omap34/36 families
On Mon, 17 Aug 2020 15:02:27 -0500
Adam Ford wrote:
> On Mon, Aug 17, 2020 at 2:59 PM Andreas Kemnade wrote:
> >
> > On Mon, 17 Aug 2020 08:39:31 -0500
> > Adam Ford wrote:
> >
> > > The OMAP3530, OMAP3630, and DM3730 all show thresholds of 90C and 105C
> > > depending on commercial or industrial temperature ratings.
> > >
> > > This patch expands the thermal information to include the limits of 90
> > > and 105C for alert and critical. It sets the coolings-cells for the
> > > 34xx and 36xx CPU's which both point to omap3-cpu-thermal.dtsi.
> > >
> > > For boards who never use industrial temperatures, these can be
> > > changed on their respective device trees with something like:
> > >
> > > &cpu_alert0 {
> > > temperature = <85000>; /* millicelsius */
> > > };
> > >
> > > &cpu_crit {
> > > temperature = <9>; /* millicelsius */
> > > };
> > >
> > > OMAP3_THERMAL will need to be enabled. It is off by default.
> > >
> > hmm, I think the patch for idling core when OMAP3_THERMAL is enabled
> > got stuck somewhere. It still seems not to work. Shouldn't that patch
> > be applied first?
>
> I rebased the idle stuff, and now I get errors, so I haven't pushed it
> yet. I put a note that OMAP3_THERMAL is off by default, but this
> patch would at least get the framing in there. I know at least two of
> us that use 1GHZ processors which are not supposed to run at that
> speed above 90MHz, so the idea was to tolerate the higher current for
> now, and when the idle stuff works, we'll enable the OMAP3_THERMAL by
> default.
>
yes, makes sense, so with this patch we have the choice to either
optimize for low speeds and currents (by disabling OMAP3_THERMAL and
1GHz) or high speeds (by enabling OMAP3_THERMAL and 1 Ghz).
Regards,
Andreas
Re: [PATCH V2] ARM: dts: omap3: Add cpu trips and cooling map for omap34/36 families
On Mon, 17 Aug 2020 08:39:31 -0500
Adam Ford wrote:
> The OMAP3530, OMAP3630, and DM3730 all show thresholds of 90C and 105C
> depending on commercial or industrial temperature ratings.
>
> This patch expands the thermal information to include the limits of 90
> and 105C for alert and critical. It sets the coolings-cells for the
> 34xx and 36xx CPU's which both point to omap3-cpu-thermal.dtsi.
>
> For boards who never use industrial temperatures, these can be
> changed on their respective device trees with something like:
>
> &cpu_alert0 {
> temperature = <85000>; /* millicelsius */
> };
>
> &cpu_crit {
> temperature = <9>; /* millicelsius */
> };
>
> OMAP3_THERMAL will need to be enabled. It is off by default.
>
hmm, I think the patch for idling core when OMAP3_THERMAL is enabled
got stuck somewhere. It still seems not to work. Shouldn't that patch
be applied first?
Regards,
Andreas
Re: [PATCH RFC 2/2] ARM: dts: imx: add devicetree for Tolino Shine 2 HD
Hi, On Sun, 16 Aug 2020 17:57:51 +0200 Jonathan Neuschäfer wrote: > On Sun, Aug 16, 2020 at 04:50:58PM +0200, Andreas Kemnade wrote: > > Hi, > > > > Seems that we have different hardware, so the first question is > > first the most interesting thing: how much does the hw actually differ, > > especially do they require different device trees? > > > > Can you provide me a photo of your hardware? > > Or is it a Shine 3? > > It is a Shine 2HD > > > > > Mine is at https://misc.andi.de1.cc/tolino2.jpg > > Mine: > > https://raw.githubusercontent.com/wiki/neuschaefer/linux/Tolino-Shine2HD.jpg > > > It appears to be the next PCB revision (+4A3 instead of +4A2), but I > think the PCB layout looks the same. The Realtek-based Wifi module is > exactly where the CyberTan WC121 was. > From other sources I also think these revisions are same besides wifi. So the only thing warranting separate dtbs might be the OOB IRQ thing. In the Tolino sources there is the function dhd_customer_oob_irq_map in the bcmdhd driver, and it gets its number from this: drivers/net/wireless/bcmdhd/Makefile: -DCUSTOMER_HW2 -DCUSTOM_OOB_GPIO_NUM=127 -DOOB_INTR_ONLY -DHW_OOB The brcmfmac driver is upstream and has devicetree support, but the rtl8189fs is not. For the Clara I am using this one: https://github.com/jwrdegoede/rtl8189ES_linux.git (branch 8189fs) It has no devicetree support, so things cannot be defined anyway. On one hand the hardware should be described in the devicetree as good as possible but on the other hand the OOB IRQ is not mandatory. Regards, Andreas
Re: [PATCH RFC 2/2] ARM: dts: imx: add devicetree for Tolino Shine 2 HD
Hi,
Seems that we have different hardware, so the first question is
first the most interesting thing: how much does the hw actually differ,
especially do they require different device trees?
Can you provide me a photo of your hardware?
Or is it a Shine 3?
Mine is at https://misc.andi.de1.cc/tolino2.jpg
On Sun, 16 Aug 2020 14:54:41 +0200
Jonathan Neuschäfer wrote:
[...]
> > +
> > +&usdhc3 {
> > + pinctrl-names = "default", "state_100mhz", "state_200mhz", "sleep";
> > + pinctrl-0 = <&pinctrl_usdhc3>;
> > + pinctrl-1 = <&pinctrl_usdhc3_100mhz>;
> > + pinctrl-2 = <&pinctrl_usdhc3_200mhz>;
> > + pinctrl-3 = <&pinctrl_usdhc3_sleep>;
> > + vmmc-supply = <®_wifi>;
> > + mmc-pwrseq = <&wifi_pwrseq>;
> > + cap-power-off-card;
> > + non-removable;
> > + status = "okay";
> > +
> > + /* CyberTan WC121 SDIO WiFi */
> > +};
>
> The HWCONFIG block from my Shine2HD reports RTL8189 as the Wifi chip
> (value 8 at offset 4), and kernel logs from the vendor kernel appear to
> agree that it's a realtek chip, at least (lines prefixed RTL871X).
>
Just for the readers with IMX knowledge but without knowledge of the
vendor kernel hacks used here: That block is on a hidden partition of
the boot medium (uSD or eMMC) describing the hardware, the kernel gets
it from the bootloader and it is used e.g. in the board file.
My hwconfig is:
{m_hdr = {cMagicNameA = "HW CONFIG "
cVersionNameA = "v2.6"
bHWConfigSize = 62 '>'}
m_val = {bPCB = 50 '2'
bKeyPad = 13 '\r'
bAudioCodec = 0 '\000'
bAudioAmp = 0 '\000'
bWifi = 7 '\a'
bBT = 0 '\000'
bMobile = 0 '\000'
bTouchCtrl = 11 '\v'
bTouchType = 4 '\004'
bDisplayCtrl = 7 '\a'
bDisplayPanel = 6 '\006'
bRSensor = 0 '\000'
bMicroP = 0 '\000'
bCustomer = 0 '\000'
bBattery = 1 '\001'
bLed = 4 '\004'
bRamSize = 3 '\003'
bIFlash = 0 '\000'
bExternalMem = 0 '\000'
bRootFsType = 2 '\002'
bSysPartType = 11 '\v'
bProgressXHiByte = 1 '\001'
bProgressXLoByte = 104 'h'
bProgressYHiByte = 2 '\002'
bProgressYLoByte = 228 '\344'
bProgressCnts = 0 '\000'
bContentType = 0 '\000'
bCPU = 5 '\005'
bUIStyle = 2 '\002'
bRamType = 5 '\005'
bUIConfig = 0 '\000'
bDisplayResolution = 5 '\005'
bFrontLight = 13 '\r'
bCPUFreq = 0 '\000'
bHallSensor = 1 '\001'
bDisplayBusWidth = 0 '\000'
bFrontLight_Flags = 4 '\004'
bPCB_Flags = 17 '\021'
bFrontLight_LED_Driver = 3 '\003'
bVCOM_10mV_HiByte = 0 '\000'
bVCOM_10mV_LoByte = 0 '\000'
bPCB_REV = 0 '\000'
bPCB_LVL = 0 '\000'
bHOME_LED_PWM = 0 '\000'
bPMIC = 1 '\001'
bFL_PWM = 0 '\000'
bRTC = 1 '\001'
bBootOpt = 0 '\000'
bTouch2Ctrl = 0 '\000'
bTouch2Type = 0 '\000'
bGPS = 0 '\000'
bFM = 0 '\000'
bRSensor2 = 0 '\000'
bLightSensor = 0 '\000'
bTPFWIDByte0 = 0 '\000'
bTPFWIDByte1 = 0 '\000'
bTPFWIDByte2 = 0 '\000'
bTPFWIDByte3 = 0 '\000'
bTPFWIDByte4 = 0 '\000'
bTPFWIDByte5 = 0 '\000'
bTPFWIDByte6 = 0 '\000'
bTPFWIDByte7 = 0 '\000'
bGPU = 0 '\000'
bPCB_Flags2 = 0 '\000'
bEPD_Flags = 0 '\000'
bLAN = 0 '\000'
bMobileIF = 0 '\000'
bPIR = 0 '\000'
bPanelLaminationSrc = 0 '\000'}
m_bReserveA = '\000' }
> From my experience with the CyberTan WC121, it has a Broadcom fullmac
> chip inside. Now I wonder where this discrepancy or variability comes
> from.
>
correct. It uses the brcmfmac driver on mainline and the .
bcmdhd in the vendor kernel
Output on the vendor kernel:
bcmsdh_register: Linux Kernel SDIO/MMC Driver
[bcm_wlan_get_oob_irq-43] gpio 127, irq 383
dhd_conf_set_hw_oob_intr: Enable HW OOB for 43362
F1 signature OK, socitype:0x1 chip:0xa962 rev:0x1 pkg:0x9
DHD: dongle ram size is set to 245760(orig 245760) at 0x0
dhdsdio_probe: Disable prop_txstatus
dhd_conf_set_fw_name_by_chip:
firmware_path=/system/lib/firmware/wc121/fw_bcm40181a2.bin
wl_create_event_handler(): thread:wl_event_handler:92d started
tsk Enter, tsk = 0xdb501304
p2p0: P2P Interface Registered
dhd_attach(): thread:dhd_watchdog_thread:932 started
dhd_attach(): thread:dhd_dpc:933 started
dhd_attach(): thread:dhd_sysioc:934 started
On mainline:
[ 11.686469] brcmfmac: brcmf_fw_alloc_request: using brcm/brcmfmac43362-sdio
for chip BCM43362/1
[ 12.282783] brcmfmac: brcmf_fw_alloc_request: using brcm/brcmfmac43362-sdio
for chip BCM43362/1
[ 12.387000] brcmfmac: brcmf_c_process_clm_blob: no clm_blob available
(err=-11), device may have limited channels available
[ 12.479403] brcmfmac: brcmf_c_preinit_dcmds: Firmware: BCM43362/1 wl0: May
16 2018 23:42:49 version 5.90.244 FWID 01-0
> I guess the SDIO setup can deal with different chips (like Broadcom vs.
> Realtek) as long as the board has been designed to always use the same
> reset/power/etc. lines. I don't see any branching based on the 'Wifi'
> HWCONFIG entry in the vendor kernel, so I guess that's the case.
>
as long as these chips do not use oob interrupts, just sdio,
it should be no problem. The question is just how much our devices
differ.
Regards,
Andreas
[PATCH 1/2] power: supply: Add support for RN5T618/RC5T619 charger and fuel gauge
Both chips have charger and a fuel gauge.
This adds basic support for displaying the state of the battery and the
input power, settings are not modified. There are some defaults set via
OTP.
Charging also starts after plugging USB.
Known issues of the fuel gauge: There are drivers in the wild which disable
the fuel gauge at shutdown. If a kernel is booted without fuel gauge
support, after such a driver has been used, the fuel gauge will stay off
and decalibrate.
If this driver is used after that, it might display wrong values for charge
level.
Signed-off-by: Andreas Kemnade
---
drivers/power/supply/Kconfig | 8 +
drivers/power/supply/Makefile| 1 +
drivers/power/supply/rn5t618_power.c | 565 +++
3 files changed, 574 insertions(+)
create mode 100644 drivers/power/supply/rn5t618_power.c
diff --git a/drivers/power/supply/Kconfig b/drivers/power/supply/Kconfig
index 44d3c8512fb8..28cea178f6f1 100644
--- a/drivers/power/supply/Kconfig
+++ b/drivers/power/supply/Kconfig
@@ -739,4 +739,12 @@ config CHARGER_WILCO
information can be found in
Documentation/ABI/testing/sysfs-class-power-wilco
+config RN5T618_POWER
+ tristate "RN5T618 charger/fuel gauge support"
+ depends on MFD_RN5T618
+ help
+ Say Y here to have support for RN5T618 PMIC family fuel gauge and
charger
+ This driver can also be built as a module. If so, the module will be
+ called rn5t618_power.
+
endif # POWER_SUPPLY
diff --git a/drivers/power/supply/Makefile b/drivers/power/supply/Makefile
index b9644663e435..23866b6ccdae 100644
--- a/drivers/power/supply/Makefile
+++ b/drivers/power/supply/Makefile
@@ -95,3 +95,4 @@ obj-$(CONFIG_CHARGER_UCS1002) += ucs1002_power.o
obj-$(CONFIG_CHARGER_BD70528) += bd70528-charger.o
obj-$(CONFIG_CHARGER_BD99954) += bd99954-charger.o
obj-$(CONFIG_CHARGER_WILCO)+= wilco-charger.o
+obj-$(CONFIG_RN5T618_POWER)+= rn5t618_power.o
diff --git a/drivers/power/supply/rn5t618_power.c
b/drivers/power/supply/rn5t618_power.c
new file mode 100644
index ..f62bcb00f714
--- /dev/null
+++ b/drivers/power/supply/rn5t618_power.c
@@ -0,0 +1,565 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Power supply driver for the RICOH RN5T618 power management chip family
+ *
+ * Copyright (C) 2020 Andreas Kemnade
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define CHG_STATE_ADP_INPUT 0x40
+#define CHG_STATE_USB_INPUT 0x80
+#define CHG_STATE_MASK 0x1f
+#define CHG_STATE_CHG_OFF 0
+#define CHG_STATE_CHG_READY_VADP 1
+#define CHG_STATE_CHG_TRICKLE 2
+#define CHG_STATE_CHG_RAPID3
+#define CHG_STATE_CHG_COMPLETE 4
+#define CHG_STATE_SUSPEND 5
+#define CHG_STATE_VCHG_OVER_VOL6
+#define CHG_STATE_BAT_ERROR7
+#define CHG_STATE_NO_BAT 8
+#define CHG_STATE_BAT_OVER_VOL 9
+#define CHG_STATE_BAT_TEMP_ERR 10
+#define CHG_STATE_DIE_ERR 11
+#define CHG_STATE_DIE_SHUTDOWN 12
+#define CHG_STATE_NO_BAT2 13
+#define CHG_STATE_CHG_READY_VUSB 14
+
+#define FG_ENABLE 1
+
+struct rn5t618_power_info {
+ struct rn5t618 *rn5t618;
+ struct platform_device *pdev;
+ struct power_supply *battery;
+ struct power_supply *usb;
+ struct power_supply *adp;
+ int irq;
+};
+
+static enum power_supply_property rn5t618_usb_props[] = {
+ POWER_SUPPLY_PROP_STATUS,
+ POWER_SUPPLY_PROP_ONLINE,
+};
+
+static enum power_supply_property rn5t618_adp_props[] = {
+ POWER_SUPPLY_PROP_STATUS,
+ POWER_SUPPLY_PROP_ONLINE,
+};
+
+
+static enum power_supply_property rn5t618_battery_props[] = {
+ POWER_SUPPLY_PROP_STATUS,
+ POWER_SUPPLY_PROP_PRESENT,
+ POWER_SUPPLY_PROP_VOLTAGE_NOW,
+ POWER_SUPPLY_PROP_CURRENT_NOW,
+ POWER_SUPPLY_PROP_CAPACITY,
+ POWER_SUPPLY_PROP_TEMP,
+ POWER_SUPPLY_PROP_TIME_TO_EMPTY_NOW,
+ POWER_SUPPLY_PROP_TIME_TO_FULL_NOW,
+ POWER_SUPPLY_PROP_TECHNOLOGY,
+ POWER_SUPPLY_PROP_CHARGE_FULL,
+ POWER_SUPPLY_PROP_CHARGE_NOW,
+};
+
+static int rn5t618_battery_read_doublereg(struct rn5t618_power_info *info,
+ u8 reg, u16 *result)
+{
+ int ret, i;
+ u8 data[2];
+ u16 old, new;
+
+ old = 0;
+ /* Prevent races when registers are changing. */
+ for (i = 0; i < 3; i++) {
+ ret = regmap_bulk_read(info->rn5t618->regmap,
+ reg, data, sizeof(data));
+ if (ret)
+ return ret;
+
+ new = data[0] << 8;
+ new |= data[1];
+ if (new == old)
+ break;
+
+ old = new;
+ }
+
+ *result = new;
+
+ return 0;
+}
+
+static int rn5t618_decode_status(unsigned int status)
+{
+ switch (status & CHG_STATE_MASK) {
+
[PATCH 2/2] mfd: rn5t618: Add a power supply subdevice
The RN5T618 and RC5T619 both have a charger and a fuel gauge, so add
a subdevice for it. According to drivers in the wild, things
should be at least similar, but since it is not tested, add it
only to the RC5T619.
Signed-off-by: Andreas Kemnade
---
drivers/mfd/rn5t618.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/mfd/rn5t618.c b/drivers/mfd/rn5t618.c
index e25407ed3ad4..dc452df1f1bf 100644
--- a/drivers/mfd/rn5t618.c
+++ b/drivers/mfd/rn5t618.c
@@ -25,6 +25,7 @@ static const struct mfd_cell rn5t618_cells[] = {
static const struct mfd_cell rc5t619_cells[] = {
{ .name = "rn5t618-adc" },
+ { .name = "rn5t618-power" },
{ .name = "rn5t618-regulator" },
{ .name = "rc5t619-rtc" },
{ .name = "rn5t618-wdt" },
--
2.20.1
[PATCH 0/2] power: supply: RN5T618/RC5T619
This series adds support for the RN5T618/RC5T619 charger and fuel gauge. Battery and input power status can be read. Andreas Kemnade (2): power: supply: Add support for RN5T618/RC5T619 charger and fuel gauge mfd: rn5t618: Add a power supply subdevice drivers/mfd/rn5t618.c| 1 + drivers/power/supply/Kconfig | 8 + drivers/power/supply/Makefile| 1 + drivers/power/supply/rn5t618_power.c | 565 +++ 4 files changed, 575 insertions(+) create mode 100644 drivers/power/supply/rn5t618_power.c -- 2.20.1
[PATCH 1/2] dt-bindings: arm: fsl: add compatible string for Tolino Shine 2 HD
This adds a compatible string for the Tolino Shine 2 HD eBook reader. Signed-off-by: Andreas Kemnade --- Documentation/devicetree/bindings/arm/fsl.yaml | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/arm/fsl.yaml b/Documentation/devicetree/bindings/arm/fsl.yaml index 05906e291e38..a3fb61868a16 100644 --- a/Documentation/devicetree/bindings/arm/fsl.yaml +++ b/Documentation/devicetree/bindings/arm/fsl.yaml @@ -211,6 +211,7 @@ properties: items: - enum: - fsl,imx6sl-evk# i.MX6 SoloLite EVK Board + - kobo,tolino-shine2hd - kobo,tolino-shine3 - const: fsl,imx6sl -- 2.20.1
[PATCH RFC 2/2] ARM: dts: imx: add devicetree for Tolino Shine 2 HD
This adds a devicetree for the Tolino Shine 2 HD Ebook reader. It is based
on boards marked with "37NB-E60QF0+4A2". It is equipped with an i.MX6SL
SoC.
Expected to work:
- Buttons
- Wifi
- Touchscreen
- LED
- uSD
- USB
- RTC
Not working due to missing drivers:
- Backlight (requires NTXEC driver)
- EPD
Not working due to unknown reasons:
- deep sleep (echo standby >/sys/power/state works),
wakeup fails when imx_gpc_pre_suspend(true) was called.
Signed-off-by: Andreas Kemnade
---
Reason for RFC: The suspend trouble might be caused by bad devicetree.
But as the devicetree is already useful I decided to submit it.
arch/arm/boot/dts/Makefile | 1 +
arch/arm/boot/dts/imx6sl-tolino-shine2hd.dts | 582 +++
2 files changed, 583 insertions(+)
create mode 100644 arch/arm/boot/dts/imx6sl-tolino-shine2hd.dts
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index e6a1cac0bfc7..c65fa3852246 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -581,6 +581,7 @@ dtb-$(CONFIG_SOC_IMX6Q) += \
imx6qp-zii-rdu2.dtb
dtb-$(CONFIG_SOC_IMX6SL) += \
imx6sl-evk.dtb \
+ imx6sl-tolino-shine2hd.dtb \
imx6sl-tolino-shine3.dtb \
imx6sl-warp.dtb
dtb-$(CONFIG_SOC_IMX6SLL) += \
diff --git a/arch/arm/boot/dts/imx6sl-tolino-shine2hd.dts
b/arch/arm/boot/dts/imx6sl-tolino-shine2hd.dts
new file mode 100644
index ..7b28e19a1d98
--- /dev/null
+++ b/arch/arm/boot/dts/imx6sl-tolino-shine2hd.dts
@@ -0,0 +1,582 @@
+// SPDX-License-Identifier: (GPL-2.0)
+/*
+ * Device tree for the Tolino Shine 2 HD ebook reader
+ *
+ * Name on mainboard is: 37NB-E60QF0+4A2
+ * Serials start with: E60QF2
+ *
+ * Copyright 2020 Andreas Kemnade
+ */
+
+/dts-v1/;
+
+#include
+#include
+#include "imx6sl.dtsi"
+
+/ {
+ model = "Tolino Shine 2 HD";
+ compatible = "kobo,tolino-shine2hd", "fsl,imx6sl";
+
+ chosen {
+ stdout-path = &uart1;
+ };
+
+ gpio_keys: gpio-keys {
+ compatible = "gpio-keys";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_gpio_keys>;
+
+ cover {
+ label = "Cover";
+ gpios = <&gpio5 12 GPIO_ACTIVE_LOW>;
+ linux,code = ;
+ linux,input-type = ;
+ wakeup-source;
+ };
+
+ fl {
+ label = "Frontlight";
+ gpios = <&gpio3 26 GPIO_ACTIVE_LOW>;
+ linux,code = ;
+ };
+
+ home {
+ label = "Home";
+ gpios = <&gpio3 25 GPIO_ACTIVE_LOW>;
+ linux,code = ;
+ };
+
+ power {
+ label = "Power";
+ gpios = <&gpio5 8 GPIO_ACTIVE_LOW>;
+ linux,code = ;
+ wakeup-source;
+ };
+ };
+
+ leds: leds {
+ compatible = "gpio-leds";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_led>;
+
+ on {
+ label = "tolinoshine2hd:white:on";
+ gpios = <&gpio5 13 GPIO_ACTIVE_LOW>;
+ linux,default-trigger = "timer";
+ };
+ };
+
+ memory@8000 {
+ device_type = "memory";
+ reg = <0x8000 0x2000>;
+ };
+
+ reg_wifi: regulator-wifi {
+ compatible = "regulator-fixed";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_wifi_power>;
+ regulator-name = "SD3_SPWR";
+ regulator-min-microvolt = <300>;
+ regulator-max-microvolt = <300>;
+ gpio = <&gpio4 29 GPIO_ACTIVE_HIGH>;
+ };
+
+ wifi_pwrseq: wifi_pwrseq {
+ compatible = "mmc-pwrseq-simple";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_wifi_reset>;
+ post-power-on-delay-ms = <20>;
+ reset-gpios = <&gpio5 0 GPIO_ACTIVE_LOW>;
+ };
+};
+
+&i2c1 {
+ pinctrl-names = "default","sleep";
+ pinctrl-0 = <&pinctrl_i2c1>;
+ pinctrl-1 = <&pinctrl_i2c1_sleep>;
+ status = "okay";
+
+ /* TODO: embedded controller at 0x43 (driver missing) */
+
+};
+
+&i2c2 {
+ pinctrl-names = "default","sleep";
+ pinctrl-0 = <&pinctrl_i2c2
[PATCH 0/2] ARM: dts: add Tolino Shine 2 HD
This adds a device tree for the Tolino Shine 2 HD Ebook reader. It is equipped with an i.MX6SL SoC. Except for backlight (via an EC) and the EPD, drivers are available and therefore things are defined in the dts. Andreas Kemnade (2): dt-bindings: arm: fsl: add compatible string for Tolino Shine 2 HD ARM: dts: imx: add devicetree for Tolino Shine 2 HD .../devicetree/bindings/arm/fsl.yaml | 1 + arch/arm/boot/dts/Makefile| 1 + arch/arm/boot/dts/imx6sl-tolino-shine2hd.dts | 582 ++ 3 files changed, 584 insertions(+) create mode 100644 arch/arm/boot/dts/imx6sl-tolino-shine2hd.dts -- 2.20.1
[PATCH v2] mfd: rn5t618: Make restart handler atomic safe
The restart handler is executed during the shutdown phase which is
atomic/irq-less. The i2c framework supports atomic transfers since
commit 63b96983a5dd ("i2c: core: introduce callbacks for atomic
transfers") to address this use case. Using i2c regmap in that
situation is not allowed:
[ 165.177465] [ BUG: Invalid wait context ]
[ 165.181479] 5.8.0-rc3-3-g0e9088558027-dirty #11 Not tainted
[ 165.187400] -
[ 165.191410] systemd-shutdow/1 is trying to lock:
[ 165.196030] d85b4438
(rn5t618:170:(&rn5t618_regmap_config)->lock){+.+.}-{3:3}, at:
regmap_update_bits_base+0x30/0x70
[ 165.206573] other info that might help us debug this:
[ 165.211625] context-{4:4}
[ 165.214248] 2 locks held by systemd-shutdow/1:
[ 165.218691] #0: c131c47c (system_transition_mutex){+.+.}-{3:3}, at:
__do_sys_reboot+0x90/0x204
[ 165.227405] #1: c131efb4 (rcu_read_lock){}-{1:2}, at:
__atomic_notifier_call_chain+0x0/0x118
[ 165.236288] stack backtrace:
[ 165.239174] CPU: 0 PID: 1 Comm: systemd-shutdow Not tainted
5.8.0-rc3-3-g0e9088558027-dirty #11
[ 165.248220] Hardware name: Freescale i.MX6 SoloLite (Device Tree)
[ 165.254330] [] (unwind_backtrace) from []
(show_stack+0x10/0x14)
[ 165.262084] [] (show_stack) from []
(dump_stack+0xe8/0x120)
[ 165.269407] [] (dump_stack) from []
(__lock_acquire+0x81c/0x2ca0)
[ 165.277246] [] (__lock_acquire) from []
(lock_acquire+0xe4/0x490)
[ 165.285090] [] (lock_acquire) from []
(__mutex_lock+0x74/0x954)
[ 165.292756] [] (__mutex_lock) from []
(mutex_lock_nested+0x1c/0x24)
[ 165.300769] [] (mutex_lock_nested) from []
(regmap_update_bits_base+0x30/0x70)
[ 165.309741] [] (regmap_update_bits_base) from []
(rn5t618_trigger_poweroff_sequence+0x34/0x64)
[ 165.320097] [] (rn5t618_trigger_poweroff_sequence) from
[] (rn5t618_restart+0xc/0x2c)
[ 165.329669] [] (rn5t618_restart) from []
(notifier_call_chain+0x48/0x80)
[ 165.338113] [] (notifier_call_chain) from []
(__atomic_notifier_call_chain+0x70/0x118)
[ 165.347770] [] (__atomic_notifier_call_chain) from []
(atomic_notifier_call_chain+0x18/0x20)
[ 165.357949] [] (atomic_notifier_call_chain) from []
(machine_restart+0x68/0x80)
[ 165.367001] [] (machine_restart) from []
(__do_sys_reboot+0x11c/0x204)
[ 165.375272] [] (__do_sys_reboot) from []
(ret_fast_syscall+0x0/0x28)
[ 165.383364] Exception stack(0xd80a5fa8 to 0xd80a5ff0)
[ 165.388420] 5fa0: 00406948 fee1dead 28121969
01234567 73299b00
[ 165.396602] 5fc0: 00406948 0058 be91abc8
be91ab60 004056f8
[ 165.404781] 5fe0: 0058 be91aabc b6ed4d45 b6e56746
Signed-off-by: Andreas Kemnade
---
Changes in v2:
- keep comments
drivers/mfd/rn5t618.c | 43 +--
1 file changed, 33 insertions(+), 10 deletions(-)
diff --git a/drivers/mfd/rn5t618.c b/drivers/mfd/rn5t618.c
index f69450543091..e3882557fced 100644
--- a/drivers/mfd/rn5t618.c
+++ b/drivers/mfd/rn5t618.c
@@ -82,7 +82,7 @@ static const struct regmap_irq_chip rc5t619_irq_chip = {
.mask_invert = true,
};
-static struct rn5t618 *rn5t618_pm_power_off;
+static struct i2c_client *rn5t618_pm_power_off;
static struct notifier_block rn5t618_restart_handler;
static int rn5t618_irq_init(struct rn5t618 *rn5t618)
@@ -115,13 +115,38 @@ static int rn5t618_irq_init(struct rn5t618 *rn5t618)
static void rn5t618_trigger_poweroff_sequence(bool repower)
{
+ int ret;
+
/* disable automatic repower-on */
- regmap_update_bits(rn5t618_pm_power_off->regmap, RN5T618_REPCNT,
- RN5T618_REPCNT_REPWRON,
- repower ? RN5T618_REPCNT_REPWRON : 0);
+ ret = i2c_smbus_read_byte_data(rn5t618_pm_power_off, RN5T618_REPCNT);
+ if (ret < 0)
+ goto err;
+
+ ret &= ~RN5T618_REPCNT_REPWRON;
+ if (repower)
+ ret |= RN5T618_REPCNT_REPWRON;
+
+ ret = i2c_smbus_write_byte_data(rn5t618_pm_power_off,
+ RN5T618_REPCNT, (u8)ret);
+ if (ret < 0)
+ goto err;
+
/* start power-off sequence */
- regmap_update_bits(rn5t618_pm_power_off->regmap, RN5T618_SLPCNT,
- RN5T618_SLPCNT_SWPWROFF, RN5T618_SLPCNT_SWPWROFF);
+ ret = i2c_smbus_read_byte_data(rn5t618_pm_power_off, RN5T618_SLPCNT);
+ if (ret < 0)
+ goto err;
+
+ ret |= RN5T618_SLPCNT_SWPWROFF;
+
+ ret = i2c_smbus_write_byte_data(rn5t618_pm_power_off,
+ RN5T618_SLPCNT, (u8)ret);
+ if (ret < 0)
+ goto err;
+
+ return;
+
+err:
+ dev_alert(&rn5t618_pm_power_off->dev, "Failed to shutdown (err =
%d)\n", ret);
}
static void rn5t618_power_off(void)
@@ -194,7 +219,7 @@ static int rn5t618_i2c_probe(struct i2c_client *i2c)
return ret;
}
- rn5t618
[PATCH] mfd: rn5t618: Make restart handler atomic safe
The restart handler is executed during the shutdown phase which is
atomic/irq-less. The i2c framework supports atomic transfers since
commit 63b96983a5dd ("i2c: core: introduce callbacks for atomic
transfers") to address this use case. Using i2c regmap in that
situation is not allowed:
[ 165.177465] [ BUG: Invalid wait context ]
[ 165.181479] 5.8.0-rc3-3-g0e9088558027-dirty #11 Not tainted
[ 165.187400] -
[ 165.191410] systemd-shutdow/1 is trying to lock:
[ 165.196030] d85b4438
(rn5t618:170:(&rn5t618_regmap_config)->lock){+.+.}-{3:3}, at:
regmap_update_bits_base+0x30/0x70
[ 165.206573] other info that might help us debug this:
[ 165.211625] context-{4:4}
[ 165.214248] 2 locks held by systemd-shutdow/1:
[ 165.218691] #0: c131c47c (system_transition_mutex){+.+.}-{3:3}, at:
__do_sys_reboot+0x90/0x204
[ 165.227405] #1: c131efb4 (rcu_read_lock){}-{1:2}, at:
__atomic_notifier_call_chain+0x0/0x118
[ 165.236288] stack backtrace:
[ 165.239174] CPU: 0 PID: 1 Comm: systemd-shutdow Not tainted
5.8.0-rc3-3-g0e9088558027-dirty #11
[ 165.248220] Hardware name: Freescale i.MX6 SoloLite (Device Tree)
[ 165.254330] [] (unwind_backtrace) from []
(show_stack+0x10/0x14)
[ 165.262084] [] (show_stack) from []
(dump_stack+0xe8/0x120)
[ 165.269407] [] (dump_stack) from []
(__lock_acquire+0x81c/0x2ca0)
[ 165.277246] [] (__lock_acquire) from []
(lock_acquire+0xe4/0x490)
[ 165.285090] [] (lock_acquire) from []
(__mutex_lock+0x74/0x954)
[ 165.292756] [] (__mutex_lock) from []
(mutex_lock_nested+0x1c/0x24)
[ 165.300769] [] (mutex_lock_nested) from []
(regmap_update_bits_base+0x30/0x70)
[ 165.309741] [] (regmap_update_bits_base) from []
(rn5t618_trigger_poweroff_sequence+0x34/0x64)
[ 165.320097] [] (rn5t618_trigger_poweroff_sequence) from
[] (rn5t618_restart+0xc/0x2c)
[ 165.329669] [] (rn5t618_restart) from []
(notifier_call_chain+0x48/0x80)
[ 165.338113] [] (notifier_call_chain) from []
(__atomic_notifier_call_chain+0x70/0x118)
[ 165.347770] [] (__atomic_notifier_call_chain) from []
(atomic_notifier_call_chain+0x18/0x20)
[ 165.357949] [] (atomic_notifier_call_chain) from []
(machine_restart+0x68/0x80)
[ 165.367001] [] (machine_restart) from []
(__do_sys_reboot+0x11c/0x204)
[ 165.375272] [] (__do_sys_reboot) from []
(ret_fast_syscall+0x0/0x28)
[ 165.383364] Exception stack(0xd80a5fa8 to 0xd80a5ff0)
[ 165.388420] 5fa0: 00406948 fee1dead 28121969
01234567 73299b00
[ 165.396602] 5fc0: 00406948 0058 be91abc8
be91ab60 004056f8
[ 165.404781] 5fe0: 0058 be91aabc b6ed4d45 b6e56746
Signed-off-by: Andreas Kemnade
---
drivers/mfd/rn5t618.c | 44 ---
1 file changed, 33 insertions(+), 11 deletions(-)
diff --git a/drivers/mfd/rn5t618.c b/drivers/mfd/rn5t618.c
index 6b37dd479d71..2ef61b55cd4b 100644
--- a/drivers/mfd/rn5t618.c
+++ b/drivers/mfd/rn5t618.c
@@ -81,7 +81,7 @@ static const struct regmap_irq_chip rc5t619_irq_chip = {
.mask_invert = true,
};
-static struct rn5t618 *rn5t618_pm_power_off;
+static struct i2c_client *rn5t618_pm_power_off;
static struct notifier_block rn5t618_restart_handler;
static int rn5t618_irq_init(struct rn5t618 *rn5t618)
@@ -114,13 +114,37 @@ static int rn5t618_irq_init(struct rn5t618 *rn5t618)
static void rn5t618_trigger_poweroff_sequence(bool repower)
{
+ int ret;
+
/* disable automatic repower-on */
- regmap_update_bits(rn5t618_pm_power_off->regmap, RN5T618_REPCNT,
- RN5T618_REPCNT_REPWRON,
- repower ? RN5T618_REPCNT_REPWRON : 0);
- /* start power-off sequence */
- regmap_update_bits(rn5t618_pm_power_off->regmap, RN5T618_SLPCNT,
- RN5T618_SLPCNT_SWPWROFF, RN5T618_SLPCNT_SWPWROFF);
+ ret = i2c_smbus_read_byte_data(rn5t618_pm_power_off, RN5T618_REPCNT);
+ if (ret < 0)
+ goto err;
+
+ ret &= ~RN5T618_REPCNT_REPWRON;
+ if (repower)
+ ret |= RN5T618_REPCNT_REPWRON;
+
+ ret = i2c_smbus_write_byte_data(rn5t618_pm_power_off,
+ RN5T618_REPCNT, (u8)ret);
+ if (ret < 0)
+ goto err;
+
+ ret = i2c_smbus_read_byte_data(rn5t618_pm_power_off, RN5T618_SLPCNT);
+ if (ret < 0)
+ goto err;
+
+ ret |= RN5T618_SLPCNT_SWPWROFF;
+
+ ret = i2c_smbus_write_byte_data(rn5t618_pm_power_off,
+ RN5T618_SLPCNT, (u8)ret);
+ if (ret < 0)
+ goto err;
+
+ return;
+
+err:
+ dev_alert(&rn5t618_pm_power_off->dev, "Failed to shutdown (err =
%d)\n", ret);
}
static void rn5t618_power_off(void)
@@ -193,7 +217,7 @@ static int rn5t618_i2c_probe(struct i2c_client *i2c)
return ret;
}
- rn5t618_pm_power_of
[PATCH] mfd: rn5t618: Fix caching of battery related registers
Battery status changes dynamically, so the corresponding registers need to be considered volatile. Affected registers are: - fuel gauge - battery status - battery interrupt Signed-off-by: Andreas Kemnade --- drivers/mfd/rn5t618.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/mfd/rn5t618.c b/drivers/mfd/rn5t618.c index 232de50562f9..55c47e555dd8 100644 --- a/drivers/mfd/rn5t618.c +++ b/drivers/mfd/rn5t618.c @@ -44,6 +44,9 @@ static bool rn5t618_volatile_reg(struct device *dev, unsigned int reg) case RN5T618_INTMON: case RN5T618_RTC_CTRL1 ... RN5T618_RTC_CTRL2: case RN5T618_RTC_SECONDS ... RN5T618_RTC_YEAR: + case RN5T618_CHGSTATE: + case RN5T618_CHGCTRL_IRR ... RN5T618_CHGERR_MONI: + case RN5T618_CONTROL ... RN5T618_CC_AVEREG0: return true; default: return false; -- 2.20.1
Re: [PATCH 3/3] ARM: imx_v6_v7_defconfig: Build in CONFIG_GPIO_MXC by default
Hi, On Wed, 8 Jul 2020 07:25:23 +0800 Anson Huang wrote: > i.MX GPIO is NOT default enabled now, so select CONFIG_GPIO_MXC > as built-in manually. > > Signed-off-by: Anson Huang > --- > arch/arm/configs/imx_v6_v7_defconfig | 1 + > 1 file changed, 1 insertion(+) > shouldn't this be done also in the multi_v7_defconfig? Regards, Andreas pgplYzfuN4BFI.pgp Description: OpenPGP digital signature
Re: [RFC PATCH 00/10] Netronix embedded controller driver for Kobo and Tolino ebook readers
On Sat, 4 Jul 2020 22:58:08 +0200 Jonathan Neuschäfer wrote: > On Tue, Jun 30, 2020 at 10:14:47PM +0200, Andreas Kemnade wrote: > > On Tue, 30 Jun 2020 09:15:23 +0200 > > Jonathan Neuschäfer wrote: > > > > > On Tue, Jun 30, 2020 at 08:40:51AM +0200, Andreas Kemnade wrote: > > > [...] > > > > got a chance to test it on a Tolino Shine 2 HD. > > > > It uses the RTC from the RC5T619 but backlight seems to go via MSP430 > > > > EC. > > > > > > > > I got this. > > > > > > > > [1.453603] ntxec 0-0043: Netronix embedded controller version f110 > > > > detected. > > > > [ 10.723638] ntxec-rtc 21a.i2c:embedded-controller@43:rtc: > > > > registered as rtc0 > > > > [ 10.775276] ntxec-pwm: probe of > > > > 21a.i2c:embedded-controller@43:pwm failed with error -5 > > > > > > Hmm, -EIO from the PWM driver. > > > > > turing debugging on: > > (edited for compactness:) > > [ 330.332971] i2c i2c-0: write slave address: addr=0x86 ACK received > > [ 330.334420] i2c i2c-0: write byte: B0=0xA3 ACK received > > [ 330.334790] i2c i2c-0: write byte: B1=0x0 No ACK > > > [ 330.352339] i2c i2c-0: write slave address: addr=0x86 ACK received > > [ 330.362208] i2c i2c-0: write byte: B0=0xA1 ACK received > > [ 330.362479] i2c i2c-0: write byte: B1=0xFF No ACK > > > [ 330.363112] i2c i2c-0: write slave address: addr=0x86 ACK received > > [ 330.363362] i2c i2c-0: write byte: B0=0xA2 ACK received > > [ 330.363608] i2c i2c-0: write byte: B1=0xFF No ACK > > Hmm, it doesn't ack the writes to 0xA3, 0xA1 and 0xA2, which should > disable the PWM output and then disable the auto-off timer (according to > the vendor kernel). > > And you said in your other mail that you can actually toggle the light > with writes to 0xA3, so I suspect a bug in the EC firmware here (which > may have gone unnoticed because the vendor kernel doesn't check if the > i2c transfers succeed). :/ > That is a also my theory. > IMHO we should get this driver merged first, and perhaps add a quirk to > deal with the missing ACKs later (unless a better solution is found). > Yes, that can be done separately (after the Tolino Shine 2 HD dtb is in, I am polishing it right now). Regards, Andreas
Re: [RFC PATCH 00/10] Netronix embedded controller driver for Kobo and Tolino ebook readers
On Tue, 30 Jun 2020 09:15:23 +0200 Jonathan Neuschäfer wrote: > On Tue, Jun 30, 2020 at 08:40:51AM +0200, Andreas Kemnade wrote: > [...] > > got a chance to test it on a Tolino Shine 2 HD. > > It uses the RTC from the RC5T619 but backlight seems to go via MSP430 > > EC. > > > > I got this. > > > > [1.453603] ntxec 0-0043: Netronix embedded controller version f110 > > detected. > > [ 10.723638] ntxec-rtc 21a.i2c:embedded-controller@43:rtc: registered > > as rtc0 > > [ 10.775276] ntxec-pwm: probe of 21a.i2c:embedded-controller@43:pwm > > failed with error -5 > > Hmm, -EIO from the PWM driver. > turing debugging on: [ 330.330599] i2c i2c-0: [ 330.330621] i2c i2c-0: [ 330.332927] i2c i2c-0: [ 330.332953] i2c i2c-0: transfer message: 0 [ 330.332971] i2c i2c-0: write slave address: addr=0x86 [ 330.334365] i2c i2c-0: TRX complete [ 330.334386] i2c i2c-0: ACK received [ 330.334402] i2c i2c-0: write data [ 330.334420] i2c i2c-0: write byte: B0=0xA3 [ 330.334756] i2c i2c-0: TRX complete [ 330.334774] i2c i2c-0: ACK received [ 330.334790] i2c i2c-0: write byte: B1=0x0 [ 330.351573] i2c i2c-0: TRX complete [ 330.351598] i2c i2c-0: No ACK [ 330.351613] i2c i2c-0: [ 330.351629] i2c i2c-0: [ 330.351648] i2c i2c-0: exit with: error: -6 [ 330.351690] i2c i2c-0: [ 330.351704] i2c i2c-0: [ 330.352297] i2c i2c-0: [ 330.352321] i2c i2c-0: transfer message: 0 [ 330.352339] i2c i2c-0: write slave address: addr=0x86 [ 330.362152] i2c i2c-0: TRX complete [ 330.362176] i2c i2c-0: ACK received [ 330.362191] i2c i2c-0: write data [ 330.362208] i2c i2c-0: write byte: B0=0xA1 [ 330.362442] i2c i2c-0: TRX complete [ 330.362461] i2c i2c-0: ACK received [ 330.362479] i2c i2c-0: write byte: B1=0xFF [ 330.362686] i2c i2c-0: TRX complete [ 330.362705] i2c i2c-0: No ACK [ 330.362720] i2c i2c-0: [ 330.362735] i2c i2c-0: [ 330.362753] i2c i2c-0: exit with: error: -6 [ 330.362794] i2c i2c-0: [ 330.362808] i2c i2c-0: [ 330.363071] i2c i2c-0: [ 330.363094] i2c i2c-0: transfer message: 0 [ 330.363112] i2c i2c-0: write slave address: addr=0x86 [ 330.363313] i2c i2c-0: TRX complete [ 330.363331] i2c i2c-0: ACK received [ 330.363346] i2c i2c-0: write data [ 330.363362] i2c i2c-0: write byte: B0=0xA2 [ 330.363572] i2c i2c-0: TRX complete [ 330.363591] i2c i2c-0: ACK received [ 330.363608] i2c i2c-0: write byte: B1=0xFF [ 330.363822] i2c i2c-0: TRX complete [ 330.363841] i2c i2c-0: No ACK [ 330.363854] i2c i2c-0: [ 330.363869] i2c i2c-0: [ 330.363886] i2c i2c-0: exit with: error: -6 Regards, Andreas
Re: [RFC PATCH 00/10] Netronix embedded controller driver for Kobo and Tolino ebook readers
On Tue, 30 Jun 2020 09:15:23 +0200 Jonathan Neuschäfer wrote: > On Tue, Jun 30, 2020 at 08:40:51AM +0200, Andreas Kemnade wrote: > [...] > > got a chance to test it on a Tolino Shine 2 HD. > > It uses the RTC from the RC5T619 but backlight seems to go via MSP430 > > EC. > > > > I got this. > > > > [1.453603] ntxec 0-0043: Netronix embedded controller version f110 > > detected. > > [ 10.723638] ntxec-rtc 21a.i2c:embedded-controller@43:rtc: registered > > as rtc0 > > [ 10.775276] ntxec-pwm: probe of 21a.i2c:embedded-controller@43:pwm > > failed with error -5 > > Hmm, -EIO from the PWM driver. > Weird... IOMUXC_SW_PAD_CTL_PAD_I2C1_SDA/SCL is identical between vendor kernel (heavily patched 3.0.35) and patched mainline. MX6SL_PAD_I2C1_SCL__I2C1_SCL 0x4001f8b1 MX6SL_PAD_I2C1_SDA__I2C1_SDA 0x4001f8b1 root@tolino2:~# i2cset -f 0 0x43 0xa3 0x0001 w WARNING! This program can confuse your I2C bus, cause data loss and worse! I will write to device file /dev/i2c-0, chip address 0x43, data address 0xa3, data 0x01, mode word. Continue? [Y/n] Error: Write failed root@tolino2:~# i2cset -f 0 0x43 0xa3 0x w WARNING! This program can confuse your I2C bus, cause data loss and worse! I will write to device file /dev/i2c-0, chip address 0x43, data address 0xa3, data 0x00, mode word. Continue? [Y/n] Error: Write failed but backlight gets toggled. Same behavior on vendor kernel and in vendor uboot. That smells. Regards, Andreas
Re: [RFC PATCH 00/10] Netronix embedded controller driver for Kobo and Tolino ebook readers
Hi,
On Sun, 21 Jun 2020 00:39:04 +0200
Jonathan Neuschäfer wrote:
> Hi,
>
> This patchset adds basic support for the embedded controller found on
> older ebook reader boards designed by/with the ODM Netronix Inc.[1] and
> sold by Kobo or Tolino, for example the Kobo Aura and the Tolino Shine.
> These drivers are based on the vendor kernel sources, but in order to
> all information in a single place, I documented the register interface
> of the EC on GitHub[4].
>
> A few things still needs to be ironed out, hence the RFC tag:
> - The reboot/reset handler in patch 3/10 calls into I2C code, which may
>sleep, but reboot handlers are apparently not allowed to sleep.
> - I'm not sure I got the YAML DT bindings right. I have also included
>the plain text DT bindings for reference.
>
>
got a chance to test it on a Tolino Shine 2 HD.
It uses the RTC from the RC5T619 but backlight seems to go via MSP430
EC.
I got this.
[1.453603] ntxec 0-0043: Netronix embedded controller version f110 detected.
[ 10.723638] ntxec-rtc 21a.i2c:embedded-controller@43:rtc: registered as
rtc0
[ 10.775276] ntxec-pwm: probe of 21a.i2c:embedded-controller@43:pwm
failed with error -5
[ 10.850597] ntxec-rtc 21a.i2c:embedded-controller@43:rtc: hctosys:
unable to read the hardware clock
version number matchess with what the vendor kernel reports. Maybe we
should document which version is running on which devices?
&i2c1 {
pinctrl-names = "default","sleep";
pinctrl-0 = <&pinctrl_i2c1>;
pinctrl-1 = <&pinctrl_i2c1_sleep>;
status = "okay";
embedded-controller@43 {
// pinctrl-names = "default";
// pinctrl-0 = <&pinctrl_ec>;
compatible = "netronix,ntxec";
reg = <0x43>;
interrupts-extended = <&gpio5 11 IRQ_TYPE_EDGE_FALLING>;
interrupt-controller;
#interrupt-cells = <1>;
ec_pwm: pwm {
compatible = "netronix,ntxec-pwm";
#pwm-cells = <2>;
};
rtc {
compatible = "netronix,ntxec-rtc";
};
};
};
Regards,
Andreas
Re: [RFC PATCH 04/10] mfd: Add base driver for Netronix embedded controller
On Sun, 21 Jun 2020 00:42:15 +0200
Jonathan Neuschäfer wrote:
> Third-party hardware documentation is available at
> https://github.com/neuschaefer/linux/wiki/Netronix-MSP430-embedded-controller
>
> The EC supports interrupts, but the driver doesn't make use of them so
> far.
>
> Known problems:
> - The reboot handler is installed in such a way that it directly calls
> into the i2c subsystem to send the reboot command to the EC. This
> means that the reboot handler may sleep, which is not allowed.
>
see
https://patchwork.ozlabs.org/project/linux-i2c/patch/20190415213432.8972-3-cont...@stefanchrist.eu/
for a fix of such problems.
> Signed-off-by: Jonathan Neuschäfer
> ---
> drivers/mfd/Kconfig | 7 ++
> drivers/mfd/Makefile | 1 +
> drivers/mfd/ntxec.c | 188 ++
> include/linux/mfd/ntxec.h | 30 ++
> 4 files changed, 226 insertions(+)
> create mode 100644 drivers/mfd/ntxec.c
> create mode 100644 include/linux/mfd/ntxec.h
>
> diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
> index a37d7d1713820..78410b928648e 100644
> --- a/drivers/mfd/Kconfig
> +++ b/drivers/mfd/Kconfig
> @@ -978,6 +978,13 @@ config MFD_VIPERBOARD
> You need to select the mfd cell drivers separately.
> The drivers do not support all features the board exposes.
>
> +config MFD_NTXEC
> + bool "Netronix Embedded Controller"
> + depends on I2C && OF
> + help
> + Say yes here if you want to support the embedded controller of
> + certain e-book readers designed by the ODM Netronix.
> +
> config MFD_RETU
> tristate "Nokia Retu and Tahvo multi-function device"
> select MFD_CORE
> diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
> index 9367a92f795a6..19d9391ed6f32 100644
> --- a/drivers/mfd/Makefile
> +++ b/drivers/mfd/Makefile
> @@ -218,6 +218,7 @@ obj-$(CONFIG_MFD_INTEL_MSIC) += intel_msic.o
> obj-$(CONFIG_MFD_INTEL_PMC_BXT) += intel_pmc_bxt.o
> obj-$(CONFIG_MFD_PALMAS) += palmas.o
> obj-$(CONFIG_MFD_VIPERBOARD)+= viperboard.o
> +obj-$(CONFIG_MFD_NTXEC) += ntxec.o
> obj-$(CONFIG_MFD_RC5T583)+= rc5t583.o rc5t583-irq.o
> obj-$(CONFIG_MFD_RK808) += rk808.o
> obj-$(CONFIG_MFD_RN5T618)+= rn5t618.o
> diff --git a/drivers/mfd/ntxec.c b/drivers/mfd/ntxec.c
> new file mode 100644
> index 0..82adea34ea746
> --- /dev/null
> +++ b/drivers/mfd/ntxec.c
> @@ -0,0 +1,188 @@
> +// SPDX-License-Identifier: GPL-2.0-only
> +// Copyright 2020 Jonathan Neuschäfer
> +//
> +// MFD driver for the usually MSP430-based embedded controller used in
> certain
> +// Netronix ebook reader board designs
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +
> +#define NTXEC_VERSION0x00
> +#define NTXEC_POWEROFF 0x50
> +#define NTXEC_POWERKEEP 0x70
> +#define NTXEC_RESET 0x90
> +
> +
> +/* Register access */
> +
> +int ntxec_read16(struct ntxec *ec, u8 addr)
> +{
> + u8 request[1] = { addr };
> + u8 response[2];
> + int res;
> +
> + struct i2c_msg msgs[] = {
> + {
> + .addr = ec->client->addr,
> + .flags = ec->client->flags,
> + .len = sizeof(request),
> + .buf = request
> + }, {
> + .addr = ec->client->addr,
> + .flags = ec->client->flags | I2C_M_RD,
> + .len = sizeof(response),
> + .buf = response
> + }
> + };
> +
> + res = i2c_transfer(ec->client->adapter, msgs, ARRAY_SIZE(msgs));
> + if (res < 0)
> + return res;
> + if (res != ARRAY_SIZE(msgs))
> + return -EIO;
> +
> + return get_unaligned_be16(response);
> +}
> +EXPORT_SYMBOL(ntxec_read16);
> +
> +int ntxec_write16(struct ntxec *ec, u8 addr, u16 value)
> +{
> + u8 request[3] = { addr, };
> + int res;
> +
> + put_unaligned_be16(value, request + 1);
> +
> + res = i2c_transfer_buffer_flags(ec->client, request, sizeof(request),
> + ec->client->flags);
> + if (res < 0)
> + return res;
> +
> + return 0;
> +}
> +EXPORT_SYMBOL(ntxec_write16);
> +
> +int ntxec_read8(struct ntxec *ec, u8 addr)
> +{
> + int res = ntxec_read16(ec, addr);
> +
> + if (res < 0)
> + return res;
> +
> + return (res >> 8) & 0xff;
> +}
> +EXPORT_SYMBOL(ntxec_read8);
> +
> +int ntxec_write8(struct ntxec *ec, u8 addr, u8 value)
> +{
> + return ntxec_write16(ec, addr, value << 8);
> +}
> +EXPORT_SYMBOL(ntxec_write8);
> +
do we really need both 16bit and 8bit accessors? If not,
then simply use regmap_i2c_init and set val_bits accordingly.
Maybe just doing the << 8 in the constants?
> +
> +/* Reboot/poweroff handling */
> +
> +static struct ntxec *poweroff_restart_instance;
>
Re: [RFC PATCH 07/10] dt-bindings: rtc: Add bindings for Netronix embedded controller RTC
On Sun, 21 Jun 2020 02:02:20 +0200 Alexandre Belloni wrote: > Hi, > > On 21/06/2020 00:42:18+0200, Jonathan Neuschäfer wrote: > > The Netronix EC implements an RTC with the following functionality: > > > > - Calendar-based time keeping with single-second resolution > > - Automatic power-on with single-minute resolution > > - Alarm at single-second resolution > > > > This binding only supports timekeeping for now. > > > > Signed-off-by: Jonathan Neuschäfer > > --- > > .../bindings/mfd/netronix,ntxec.yaml | 7 + > > .../bindings/rtc/netronix,ntxec-rtc.yaml | 27 +++ > > 2 files changed, 34 insertions(+) > > create mode 100644 > > Documentation/devicetree/bindings/rtc/netronix,ntxec-rtc.yaml > > > > diff --git a/Documentation/devicetree/bindings/mfd/netronix,ntxec.yaml > > b/Documentation/devicetree/bindings/mfd/netronix,ntxec.yaml > > index 6562c41c5a9a9..f6a32f46f47bb 100644 > > --- a/Documentation/devicetree/bindings/mfd/netronix,ntxec.yaml > > +++ b/Documentation/devicetree/bindings/mfd/netronix,ntxec.yaml > > @@ -34,6 +34,9 @@ properties: > >pwm: > > $ref: ../pwm/netronix,ntxec-pwm.yaml > > > > + rtc: > > +$ref: ../rtc/netronix,ntxec-rtc.yaml > > + > > Shouldn't the node simply be documented here? > > Also, do you really need a compatible string to be able to proe the > driver? What are the chances that you'll get a similar EC without an > RTC? > Tolino Shine 2 HD has the mentioned EC but the vendor kernel does not use its RTC (not checked whether it is present or functional). As a key for grepping in the vendor sources: gptNtxHwCfg->m_val.bPCB = 0x50 Tolino Shine 3 and Kobo Clara HD do not have that EC. Regrads, Andreas
Re: [RFC PATCH 05/10] dt-bindings: pwm: Add bindings for PWM function in Netronix EC
On Sun, 21 Jun 2020 00:42:16 +0200
Jonathan Neuschäfer wrote:
> The Netronix embedded controller as found in Kobo Aura and Tolino Shine
> supports one PWM channel, which is used to control the frontlight
> brightness on these devices.
>
> Known problems:
> - `make dt_binding_check` shows the following warnings:
> Documentation/devicetree/bindings/mfd/netronix,ntxec.example.dts:49.17-42:
> Warning (pwms_property): /example-0/backlight:pwms: cell 2 is not a
> phandle reference
> Documentation/devicetree/bindings/mfd/netronix,ntxec.example.dts:49.17-42:
> Warning (pwms_property): /example-0/backlight:pwms: Could not get
> phandle node for (cell 2)
>
In the tolino sources in ./drivers/misc/ntx-misc.c I find this line
if(4==gptHWCFG->m_val.bFL_PWM) {
No idea what it does but I would expect to have a kind of translation to
a dt property?
> Signed-off-by: Jonathan Neuschäfer
> ---
> .../bindings/mfd/netronix,ntxec.yaml | 13
> .../bindings/pwm/netronix,ntxec-pwm.yaml | 33 +++
> 2 files changed, 46 insertions(+)
> create mode 100644
> Documentation/devicetree/bindings/pwm/netronix,ntxec-pwm.yaml
>
> diff --git a/Documentation/devicetree/bindings/mfd/netronix,ntxec.yaml
> b/Documentation/devicetree/bindings/mfd/netronix,ntxec.yaml
> index 596df460f98eb..6562c41c5a9a9 100644
> --- a/Documentation/devicetree/bindings/mfd/netronix,ntxec.yaml
> +++ b/Documentation/devicetree/bindings/mfd/netronix,ntxec.yaml
> @@ -31,6 +31,9 @@ properties:
> description:
>The EC can signal interrupts via a GPIO line
>
> + pwm:
> +$ref: ../pwm/netronix,ntxec-pwm.yaml
> +
> required:
>- compatible
>- reg
> @@ -53,5 +56,15 @@ examples:
> interrupts = <11 IRQ_TYPE_EDGE_FALLING>;
> interrupt-controller;
> #interrupt-cells = <1>;
> +
> +ec_pwm: pwm {
> +compatible = "netronix,ntxec-pwm";
> +#pwm-cells = <1>;
shouldn't that be 2?
> +};
> };
> };
> +
> +backlight {
> +compatible = "pwm-backlight";
> +pwms = <&ec_pwm 0 5>;
since you have 2 values after the &ec_pwm
> +};
> diff --git a/Documentation/devicetree/bindings/pwm/netronix,ntxec-pwm.yaml
> b/Documentation/devicetree/bindings/pwm/netronix,ntxec-pwm.yaml
> new file mode 100644
> index 0..1dc1b1aba081c
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/pwm/netronix,ntxec-pwm.yaml
> @@ -0,0 +1,33 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/pwm/netronix,ntxec-pwm.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: PWM functionality in Netronix embedded controller
> +
> +maintainers:
> + - Jonathan Neuschäfer
> +
> +description: |
> + See also Documentation/devicetree/bindings/mfd/netronix,ntxec.yaml
> +
> + The Netronix EC contains PWM functionality, which is usually used to drive
> + the backlight LED.
> +
> + The following PWM channels are supported:
> +- 0: The PWM channel controlled by registers 0xa1-0xa7
> +
> +allOf:
> + - $ref: pwm.yaml#
> +
> +properties:
> + compatible:
> +const: netronix,ntxec-pwm
> +
> + "#pwm-cells":
> +const: 1
shouln't that be 2?
> +
> +required:
> + - compatible
> + - "#pwm-cells"
> --
> 2.27.0
>
>
Regards,
Andreas
[PATCH] ARM: imx_v6_v7_defconfig: extend RN5T618 PMIC family support
There are new drivers for functionality of that family (RTC and ADC), so enable them, since they are used by various i.MX6 boards. Signed-off-by: Andreas Kemnade --- arch/arm/configs/imx_v6_v7_defconfig | 2 ++ 1 file changed, 2 insertions(+) diff --git a/arch/arm/configs/imx_v6_v7_defconfig b/arch/arm/configs/imx_v6_v7_defconfig index 5a20d12d62bd..87e6400c436b 100644 --- a/arch/arm/configs/imx_v6_v7_defconfig +++ b/arch/arm/configs/imx_v6_v7_defconfig @@ -395,6 +395,7 @@ CONFIG_RTC_DRV_DA9063=y CONFIG_RTC_DRV_MC13XXX=y CONFIG_RTC_DRV_MXC=y CONFIG_RTC_DRV_MXC_V2=y +CONFIG_RTC_DRV_RC5T619=y CONFIG_RTC_DRV_SNVS=y CONFIG_DMADEVICES=y CONFIG_FSL_EDMA=y @@ -408,6 +409,7 @@ CONFIG_COMMON_CLK_PWM=y CONFIG_IIO=y CONFIG_MMA8452=y CONFIG_IMX7D_ADC=y +CONFIG_RN5T618_ADC=y CONFIG_VF610_ADC=y CONFIG_SENSORS_ISL29018=y CONFIG_MAG3110=y -- 2.20.1
Re: [PATCH 5/5] rtc: rtc-rc5t583: add ricoh rc5t619 RTC driver
Hi,
On Mon, 21 Oct 2019 12:15:28 +0200
Alexandre Belloni wrote:
> Hi,
>
> The subject line is weird, how is it related to rc5t583?
>
well, yes, rc5t583 driver source was opened next to the window where I wrote
the commit message...
> On 21/10/2019 07:41:04+0200, Andreas Kemnade wrote:
> > config RTC_DRV_S35390A
> > tristate "Seiko Instruments S-35390A"
> > select BITREVERSE
> > diff --git a/drivers/rtc/Makefile b/drivers/rtc/Makefile
> > index 6b09c21dc1b6..1d0673fd0954 100644
> > --- a/drivers/rtc/Makefile
> > +++ b/drivers/rtc/Makefile
> > @@ -136,6 +136,7 @@ obj-$(CONFIG_RTC_DRV_PXA) += rtc-pxa.o
> > obj-$(CONFIG_RTC_DRV_R7301)+= rtc-r7301.o
> > obj-$(CONFIG_RTC_DRV_R9701)+= rtc-r9701.o
> > obj-$(CONFIG_RTC_DRV_RC5T583) += rtc-rc5t583.o
> > +obj-$(CONFIG_RTC_DRV_RC5T619) += rtc-rc5t619.o
> > obj-$(CONFIG_RTC_DRV_RK808)+= rtc-rk808.o
> > obj-$(CONFIG_RTC_DRV_RP5C01) += rtc-rp5c01.o
> > obj-$(CONFIG_RTC_DRV_RS5C313) += rtc-rs5c313.o
> > diff --git a/drivers/rtc/rtc-rc5t619.c b/drivers/rtc/rtc-rc5t619.c
> > new file mode 100644
> > index ..311788ff0723
> > --- /dev/null
> > +++ b/drivers/rtc/rtc-rc5t619.c
> > @@ -0,0 +1,476 @@
> > +// SPDX-License-Identifier: GPL-2.0+
> > +/*
> > + * drivers/rtc/rtc-ricoh619.c
> > + *
> > + * Real time clock driver for RICOH R5T619 power management chip.
> > + *
> > + * Copyright (C) 2019 Andreas Kemnade
> > + *
> > + * Based on code
> > + * Copyright (C) 2012-2014 RICOH COMPANY,LTD
> > + *
> > + * Based on code
> > + * Copyright (C) 2011 NVIDIA Corporation
>
> Based on is not useful.
>
Well, ok, I guess 90 % of the lines are rewritten by me.
So I could remove all that Based on copyright notices?
> > + */
> > +
> > +/* #define debug 1 */
> > +/* #define verbose_debug 1 */
> > +
>
> No dead code please.
>
ok.
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +
> > +struct rc5t619_rtc {
> > + int irq;
> > + struct rtc_device *rtc;
> > + struct rn5t618 *rn5t618;
> > +};
> > +
> > +#define CTRL1_ALARM_ENABLED 0x40
> > +#define CTRL1_24HR 0x20
> > +#define CTRL1_PERIODIC_MASK 0xf
> > +
> > +#define CTRL2_PON 0x10
> > +#define CTRL2_ALARM_STATUS 0x80
> > +#define CTRL2_CTFG 0x4
> > +#define CTRL2_CTC 0x1
> > +
> > +static int rc5t619_rtc_periodic_disable(struct device *dev)
> > +{
> > + struct rc5t619_rtc *rtc = dev_get_drvdata(dev);
> > + int err;
> > +
> > + /* disable function */
> > + err = regmap_update_bits(rtc->rn5t618->regmap,
> > + RN5T618_RTC_CTRL1, CTRL1_PERIODIC_MASK, 0);
> > + if (err < 0)
> > + return err;
> > +
> > + /* clear alarm flag and CTFG */
> > + err = regmap_update_bits(rtc->rn5t618->regmap, RN5T618_RTC_CTRL2,
> > + CTRL2_ALARM_STATUS | CTRL2_CTFG | CTRL2_CTC, 0);
> > + if (err < 0)
> > + return err;
> > +
> > + return 0;
> > +}
> > +
> > +static int rc5t619_rtc_clk_adjust(struct device *dev, uint8_t clk)
> > +{
> > + struct rc5t619_rtc *rtc = dev_get_drvdata(dev);
> > +
> > + return regmap_write(rtc->rn5t618->regmap, RN5T618_RTC_ADJUST, clk);
>
> Is it useful to have a function for a single regmap_write?
well, I could live without.
>
> Also what is that adjusting? If this is adding/removing clock cycles,
> you need to use .set_offset and .read_offset.
>
It the moment I am just clearing it at init. Since I do not know the
exact meaning of the value, I am not offering it through set_offset/read_offset.
> > +}
> > +
> > +static int rc5t619_rtc_pon_get_clr(struct device *dev, uint8_t *pon_f)
> > +{
> > + struct rc5t619_rtc *rtc = dev_get_drvdata(dev);
> > + int err;
> > + unsigned int reg_data;
> > +
> > + err = regmap_read(rtc->rn5t618->regmap, RN5T618_RTC_CTRL2, ®_data);
> > + if (err < 0)
> > + return err;
> > +
> > + if (reg_data & CTRL2_PON) {
> > + *pon_f = 1;
> > + /* clear VDET PON */
> > + reg_data &= ~(CTRL2_PON | CTRL2_CTC | 0x4a);/* 0101-1011 */
> > + reg_data |= 0x20; /* 0010-
Re: [PATCH 5/5] rtc: rtc-rc5t583: add ricoh rc5t619 RTC driver
On Mon, 21 Oct 2019 15:50:28 +0200 Alexandre Belloni wrote: > On 21/10/2019 15:19:09+0200, Stefan Agner wrote: > > On 2019-10-21 07:41, Andreas Kemnade wrote: > > > Add an RTC driver for the RTC device on Ricoh MFD rc5t619, > > > which is implemented as a variant of rn5t618 > > > > > > Signed-off-by: Andreas Kemnade > > > --- > > > drivers/rtc/Kconfig | 10 + > > > drivers/rtc/Makefile | 1 + > > > drivers/rtc/rtc-rc5t619.c | 476 > > > ++ > > > > Parts of this driver look very similar to drivers/rtc/rtc-rc5t583.c. Can > > it maybe shared? > > > > If this could be done it would be better. I can't find any public > datasheet though... > at least they have different alarm configurations, The rc5t619 can specify alarm in seconds, the rc5t583 not but has other alarm configurations which are not present in the rn5t619 (judging by the lack of unused registers where thoes information could be filled in). Register addresses do not match. Some details seem to be the same like century flag. Interestingly the rc5t583 driver does not care about 12h/24h mode. So there is a bug there. Regards, Andreas pgpUaObXo1Dgy.pgp Description: OpenPGP digital signature
Re: [PATCH 2/5] mfd: rn5t618: add irq support
On Mon, 21 Oct 2019 11:07:10 +0200
Alexandre Belloni wrote:
> Hi,
>
> On 21/10/2019 07:41:01+0200, Andreas Kemnade wrote:
> > +#if 0
> > +/*
> > + * REVISIT when implementing charger:
> > + * according to some other implementation it needs special treatment,
> > + * inverted but experiments seem not to confirm that.
> > + */
> > + [RN5T618_IRQ_CHG] = {
> > + .reg_offset = 0,
> > + .mask = (1 << 6),
> > + }
> > +#endif
>
> Please avoid submitting dead code.
>
ok, I can do some more testing here and add that thing properly.
Regards,
Andreas
pgpJXbtaVN385.pgp
Description: OpenPGP digital signature
[PATCH 0/5] Add rtc support for rn5t618 mfd
In the variant rc5t619 the mfd has a rtc. This patchset adds
support for it. To do so it adds the missing register defines in
rn5t618.h and general irq handling for that.
Probably the irq definitions are the same except missing rtc + charger
but due to missing information about that I do not add them.
There might be some oddity about the charger irq which should be
researched when adding the charger subdevice.
The rtc driver itself is based on
https://github.com/kobolabs/Kobo-Reader/blob/master/hw/imx6sll-clara/kernel.tar.bz2
but heavily reworked.
It was tested on the Kobo Clara HD.
Andreas Kemnade (5):
mfd: rn5t618: prepare for irq handling
mfd: rn5t618: add irq support
mfd: rn5t618: add rtc related registers
mfd: rn5t618: add more subdevices
rtc: rtc-rc5t583: add ricoh rc5t619 RTC driver
drivers/mfd/Kconfig | 1 +
drivers/mfd/Makefile | 2 +
drivers/mfd/{rn5t618.c => rn5t618-core.c} | 49 ++-
drivers/mfd/rn5t618-irq.c | 92 ++
drivers/rtc/Kconfig | 10 +
drivers/rtc/Makefile | 1 +
drivers/rtc/rtc-rc5t619.c | 476 ++
include/linux/mfd/rn5t618.h | 29 ++
8 files changed, 658 insertions(+), 2 deletions(-)
rename drivers/mfd/{rn5t618.c => rn5t618-core.c} (79%)
create mode 100644 drivers/mfd/rn5t618-irq.c
create mode 100644 drivers/rtc/rtc-rc5t619.c
--
2.11.0
[PATCH 5/5] rtc: rtc-rc5t583: add ricoh rc5t619 RTC driver
Add an RTC driver for the RTC device on Ricoh MFD rc5t619,
which is implemented as a variant of rn5t618
Signed-off-by: Andreas Kemnade
---
drivers/rtc/Kconfig | 10 +
drivers/rtc/Makefile | 1 +
drivers/rtc/rtc-rc5t619.c | 476 ++
3 files changed, 487 insertions(+)
create mode 100644 drivers/rtc/rtc-rc5t619.c
diff --git a/drivers/rtc/Kconfig b/drivers/rtc/Kconfig
index e72f65b61176..a4dc04c49fec 100644
--- a/drivers/rtc/Kconfig
+++ b/drivers/rtc/Kconfig
@@ -588,6 +588,16 @@ config RTC_DRV_RC5T583
This driver can also be built as a module. If so, the module
will be called rtc-rc5t583.
+config RTC_DRV_RC5T619
+ tristate "RICOH RC5T619 RTC driver"
+ depends on MFD_RN5T618
+ help
+ If you say yes here you get support for the RTC on the
+ RICOH RC5T619 chips.
+
+ This driver can also be built as a module. If so, the module
+ will be called rtc-rc5t619.
+
config RTC_DRV_S35390A
tristate "Seiko Instruments S-35390A"
select BITREVERSE
diff --git a/drivers/rtc/Makefile b/drivers/rtc/Makefile
index 6b09c21dc1b6..1d0673fd0954 100644
--- a/drivers/rtc/Makefile
+++ b/drivers/rtc/Makefile
@@ -136,6 +136,7 @@ obj-$(CONFIG_RTC_DRV_PXA) += rtc-pxa.o
obj-$(CONFIG_RTC_DRV_R7301)+= rtc-r7301.o
obj-$(CONFIG_RTC_DRV_R9701)+= rtc-r9701.o
obj-$(CONFIG_RTC_DRV_RC5T583) += rtc-rc5t583.o
+obj-$(CONFIG_RTC_DRV_RC5T619) += rtc-rc5t619.o
obj-$(CONFIG_RTC_DRV_RK808)+= rtc-rk808.o
obj-$(CONFIG_RTC_DRV_RP5C01) += rtc-rp5c01.o
obj-$(CONFIG_RTC_DRV_RS5C313) += rtc-rs5c313.o
diff --git a/drivers/rtc/rtc-rc5t619.c b/drivers/rtc/rtc-rc5t619.c
new file mode 100644
index ..311788ff0723
--- /dev/null
+++ b/drivers/rtc/rtc-rc5t619.c
@@ -0,0 +1,476 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * drivers/rtc/rtc-ricoh619.c
+ *
+ * Real time clock driver for RICOH R5T619 power management chip.
+ *
+ * Copyright (C) 2019 Andreas Kemnade
+ *
+ * Based on code
+ * Copyright (C) 2012-2014 RICOH COMPANY,LTD
+ *
+ * Based on code
+ * Copyright (C) 2011 NVIDIA Corporation
+ */
+
+/* #define debug 1 */
+/* #define verbose_debug 1 */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+struct rc5t619_rtc {
+ int irq;
+ struct rtc_device *rtc;
+ struct rn5t618 *rn5t618;
+};
+
+#define CTRL1_ALARM_ENABLED 0x40
+#define CTRL1_24HR 0x20
+#define CTRL1_PERIODIC_MASK 0xf
+
+#define CTRL2_PON 0x10
+#define CTRL2_ALARM_STATUS 0x80
+#define CTRL2_CTFG 0x4
+#define CTRL2_CTC 0x1
+
+static int rc5t619_rtc_periodic_disable(struct device *dev)
+{
+ struct rc5t619_rtc *rtc = dev_get_drvdata(dev);
+ int err;
+
+ /* disable function */
+ err = regmap_update_bits(rtc->rn5t618->regmap,
+ RN5T618_RTC_CTRL1, CTRL1_PERIODIC_MASK, 0);
+ if (err < 0)
+ return err;
+
+ /* clear alarm flag and CTFG */
+ err = regmap_update_bits(rtc->rn5t618->regmap, RN5T618_RTC_CTRL2,
+ CTRL2_ALARM_STATUS | CTRL2_CTFG | CTRL2_CTC, 0);
+ if (err < 0)
+ return err;
+
+ return 0;
+}
+
+static int rc5t619_rtc_clk_adjust(struct device *dev, uint8_t clk)
+{
+ struct rc5t619_rtc *rtc = dev_get_drvdata(dev);
+
+ return regmap_write(rtc->rn5t618->regmap, RN5T618_RTC_ADJUST, clk);
+}
+
+static int rc5t619_rtc_pon_get_clr(struct device *dev, uint8_t *pon_f)
+{
+ struct rc5t619_rtc *rtc = dev_get_drvdata(dev);
+ int err;
+ unsigned int reg_data;
+
+ err = regmap_read(rtc->rn5t618->regmap, RN5T618_RTC_CTRL2, ®_data);
+ if (err < 0)
+ return err;
+
+ if (reg_data & CTRL2_PON) {
+ *pon_f = 1;
+ /* clear VDET PON */
+ reg_data &= ~(CTRL2_PON | CTRL2_CTC | 0x4a);/* 0101-1011 */
+ reg_data |= 0x20; /* 0010- */
+ err = regmap_write(rtc->rn5t618->regmap, RN5T618_RTC_CTRL2,
+ reg_data);
+ } else {
+ *pon_f = 0;
+ }
+
+ return err;
+}
+
+/* 0-12hour, 1-24hour */
+static int rc5t619_rtc_24hour_mode_set(struct device *dev, int mode)
+{
+ struct rc5t619_rtc *rtc = dev_get_drvdata(dev);
+
+ return regmap_update_bits(rtc->rn5t618->regmap, RN5T618_RTC_CTRL1,
+ CTRL1_24HR, mode ? CTRL1_24HR : 0);
+}
+
+
+static int rc5t619_rtc_read_time(struct device *dev, struct rtc_time *tm)
+{
+ struct rc5t619_rtc *rtc = dev_get_drvdata(dev);
+ u8 buff[7];
+ int err;
+ int cent_flag;
+
+ err = regmap_bulk_read(rtc->rn5t618->regmap, RN5T618_RTC_SECONDS,
+ buff, sizeof(buff));
+
[PATCH 4/5] mfd: rn5t618: add more subdevices
The rc5t619 has a rtc which are missing in the
rn5t618. Add it as subdevice to prepare for their implementation
Signed-off-by: Andreas Kemnade
---
drivers/mfd/rn5t618-core.c | 12 +++-
1 file changed, 11 insertions(+), 1 deletion(-)
diff --git a/drivers/mfd/rn5t618-core.c b/drivers/mfd/rn5t618-core.c
index 0e3ec9dafb40..b037c97e6747 100644
--- a/drivers/mfd/rn5t618-core.c
+++ b/drivers/mfd/rn5t618-core.c
@@ -21,6 +21,12 @@ static const struct mfd_cell rn5t618_cells[] = {
{ .name = "rn5t618-wdt" },
};
+static const struct mfd_cell rc5t619_cells[] = {
+ { .name = "rn5t618-regulator" },
+ { .name = "rc5t619-rtc" },
+ { .name = "rn5t618-wdt" },
+};
+
static bool rn5t618_volatile_reg(struct device *dev, unsigned int reg)
{
switch (reg) {
@@ -117,7 +123,11 @@ static int rn5t618_i2c_probe(struct i2c_client *i2c,
return ret;
}
- ret = devm_mfd_add_devices(&i2c->dev, -1, rn5t618_cells,
+ if (priv->variant == RC5T619)
+ ret = devm_mfd_add_devices(&i2c->dev, -1, rc5t619_cells,
+ ARRAY_SIZE(rc5t619_cells), NULL, 0, NULL);
+ else
+ ret = devm_mfd_add_devices(&i2c->dev, -1, rn5t618_cells,
ARRAY_SIZE(rn5t618_cells), NULL, 0, NULL);
if (ret) {
dev_err(&i2c->dev, "failed to add sub-devices: %d\n", ret);
--
2.11.0
