Three of the PMIC registers have some bits that are changed
autonomously by the PMIC itself (some time) after being set
by some component driver of the DA9052 PMIC and hence they
need to be marked as volatile so that the regmap API will
not cache their values.
Signed-off-by: Anthony Olech <[email protected]>
Signed-off-by: David Dajun Chen <[email protected]>
---
This patch is relative to linux-next repository tag next-20140128
The bug that this patch fixes affects two components of DA9052 namely:
WATCHDOG - the first kick will work but sebsequent ones will not
thus the will timeout at 2 x interval.
REGULATORS - the first change to any DA9052 BUCK voltage will be
actioned, but sebsequent ones will not.
drivers/mfd/da9052-core.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/mfd/da9052-core.c b/drivers/mfd/da9052-core.c
index 25838f1..e8af816 100644
--- a/drivers/mfd/da9052-core.c
+++ b/drivers/mfd/da9052-core.c
@@ -279,6 +279,9 @@ static bool da9052_reg_volatile(struct device *dev, unsigned int reg)
case DA9052_EVENT_B_REG:
case DA9052_EVENT_C_REG:
case DA9052_EVENT_D_REG:
+ case DA9052_CONTROL_B_REG:
+ case DA9052_CONTROL_D_REG:
+ case DA9052_SUPPLY_REG:
case DA9052_FAULTLOG_REG:
case DA9052_CHG_TIME_REG:
case DA9052_ADC_RES_L_REG:
--
end-of-patch for fix da9052 volatile register definition ommissions V1
> Three of the PMIC registers have some bits that are changed
> autonomously by the PMIC itself (some time) after being set
> by some component driver of the DA9052 PMIC and hence they
> need to be marked as volatile so that the regmap API will
> not cache their values.
>
> Signed-off-by: Anthony Olech <[email protected]>
> Signed-off-by: David Dajun Chen <[email protected]>
These are not correct.
Who authored the patch?
> ---
> This patch is relative to linux-next repository tag next-20140128
>
> The bug that this patch fixes affects two components of DA9052 namely:
>
> WATCHDOG - the first kick will work but sebsequent ones will not
> thus the will timeout at 2 x interval.
>
> REGULATORS - the first change to any DA9052 BUCK voltage will be
> actioned, but sebsequent ones will not.
Which patch caused the bug?
> drivers/mfd/da9052-core.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/drivers/mfd/da9052-core.c b/drivers/mfd/da9052-core.c
> index 25838f1..e8af816 100644
> --- a/drivers/mfd/da9052-core.c
> +++ b/drivers/mfd/da9052-core.c
> @@ -279,6 +279,9 @@ static bool da9052_reg_volatile(struct device *dev, unsigned int reg)
> case DA9052_EVENT_B_REG:
> case DA9052_EVENT_C_REG:
> case DA9052_EVENT_D_REG:
> + case DA9052_CONTROL_B_REG:
> + case DA9052_CONTROL_D_REG:
> + case DA9052_SUPPLY_REG:
> case DA9052_FAULTLOG_REG:
> case DA9052_CHG_TIME_REG:
> case DA9052_ADC_RES_L_REG:
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
> -----Original Message-----
> From: Lee Jones [mailto:[email protected]]
> Sent: 03 February 2014 10:29
> To: Opensource [Anthony Olech]
> Cc: Mark Brown; Samuel Ortiz; [email protected]; David Dajun
> Chen
> Subject: Re: [PATCH V1] fix da9052 volatile register definition ommissions
> > Three of the PMIC registers have some bits that are changed
> > autonomously by the PMIC itself (some time) after being set by some
> > component driver of the DA9052 PMIC and hence they need to be marked
> > as volatile so that the regmap API will not cache their values.
> > Signed-off-by: Anthony Olech <[email protected]>
> > Signed-off-by: David Dajun Chen <[email protected]>
> These are not correct.
> Who authored the patch?
Hi Lee,
I found the problem when running regression tests for another different problem.
And according to my testing on a SMDK6410+DA9053EVB the patch is correct!!
Tony Olech
> > ---
> > This patch is relative to linux-next repository tag next-20140128
> > The bug that this patch fixes affects two components of DA9052 namely:
> > WATCHDOG - the first kick will work but sebsequent ones will not
> > thus the will timeout at 2 x interval.
> > REGULATORS - the first change to any DA9052 BUCK voltage will be
> > actioned, but sebsequent ones will not.
> Which patch caused the bug?
I will find out when I start rebasing backwards to submit patches to linux-stable!
> > drivers/mfd/da9052-core.c | 3 +++
> > 1 file changed, 3 insertions(+)
> >
> > diff --git a/drivers/mfd/da9052-core.c b/drivers/mfd/da9052-core.c
> > index 25838f1..e8af816 100644
> > --- a/drivers/mfd/da9052-core.c
> > +++ b/drivers/mfd/da9052-core.c
> > @@ -279,6 +279,9 @@ static bool da9052_reg_volatile(struct device *dev,
> unsigned int reg)
> > case DA9052_EVENT_B_REG:
> > case DA9052_EVENT_C_REG:
> > case DA9052_EVENT_D_REG:
> > + case DA9052_CONTROL_B_REG:
> > + case DA9052_CONTROL_D_REG:
> > + case DA9052_SUPPLY_REG:
> > case DA9052_FAULTLOG_REG:
> > case DA9052_CHG_TIME_REG:
> > case DA9052_ADC_RES_L_REG:
>
> --
> Lee Jones
> Linaro STMicroelectronics Landing Team Lead Linaro.org │ Open source
> software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog
????{.n?+???????+%?????ݶ??w??{.n?+????{??G?????{ay? ʇڙ?,j??f???h?????????z_??(?階?ݢj"???m??????G????????????&???~???iO???z??v?^?m???? ????????I?
> > > Three of the PMIC registers have some bits that are changed
> > > autonomously by the PMIC itself (some time) after being set by some
> > > component driver of the DA9052 PMIC and hence they need to be marked
> > > as volatile so that the regmap API will not cache their values.
> > > Signed-off-by: Anthony Olech <[email protected]>
> > > Signed-off-by: David Dajun Chen <[email protected]>
> > These are not correct.
> > Who authored the patch?
>
> I found the problem when running regression tests for another different problem.
> And according to my testing on a SMDK6410+DA9053EVB the patch is correct!!
I mean the Signed-off-by's are not correct.
They should be in order of the patch submission path.
Who authored the patch initially and what part did David play?
<snip>
> > > REGULATORS - the first change to any DA9052 BUCK voltage will be
> > > actioned, but sebsequent ones will not.
> > Which patch caused the bug?
>
> I will find out when I start rebasing backwards to submit patches to linux-stable!
I'm just wondering where to apply the patch. Either for -fixes or
-next. If the bug has been present for some time, I'll probably just
apply it to my for-next branch.
Also be wary of the $SUBJECT line format when submitting to different
subsystems. You can usually get an idea of what's expected by doing:
`git log --oneline -- drivers/<subsystem>`
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog