As per Table 130 of the wm8994 datasheet at [1], there is an off-on
delay for LDO1 and LDO2. In the wm8958 datasheet [2], I could not
find any reference to it. I could not find a wm1811 datasheet to
double-check there, but as no one has complained presumably it works
without it.
This solves the issue on Samsung Aries boards with a wm8994 where
register writes fail when the device is powered off and back-on
quickly.
[1] https://statics.cirrus.com/pubs/proDatasheet/WM8994_Rev4.6.pdf
[2] https://statics.cirrus.com/pubs/proDatasheet/WM8958_v3.5.pdf
Signed-off-by: Jonathan Bakker <[email protected]>
---
Changes in v2
- Duplicate regulator_desc, keep it const, and select which one
instead of modifying the one existing one
---
drivers/regulator/wm8994-regulator.c | 42 ++++++++++++++++++++++++++--
1 file changed, 39 insertions(+), 3 deletions(-)
diff --git a/drivers/regulator/wm8994-regulator.c b/drivers/regulator/wm8994-regulator.c
index cadea0344486..40befdd9dfa9 100644
--- a/drivers/regulator/wm8994-regulator.c
+++ b/drivers/regulator/wm8994-regulator.c
@@ -71,6 +71,35 @@ static const struct regulator_ops wm8994_ldo2_ops = {
};
static const struct regulator_desc wm8994_ldo_desc[] = {
+ {
+ .name = "LDO1",
+ .id = 1,
+ .type = REGULATOR_VOLTAGE,
+ .n_voltages = WM8994_LDO1_MAX_SELECTOR + 1,
+ .vsel_reg = WM8994_LDO_1,
+ .vsel_mask = WM8994_LDO1_VSEL_MASK,
+ .ops = &wm8994_ldo1_ops,
+ .min_uV = 2400000,
+ .uV_step = 100000,
+ .enable_time = 3000,
+ .off_on_delay = 36000,
+ .owner = THIS_MODULE,
+ },
+ {
+ .name = "LDO2",
+ .id = 2,
+ .type = REGULATOR_VOLTAGE,
+ .n_voltages = WM8994_LDO2_MAX_SELECTOR + 1,
+ .vsel_reg = WM8994_LDO_2,
+ .vsel_mask = WM8994_LDO2_VSEL_MASK,
+ .ops = &wm8994_ldo2_ops,
+ .enable_time = 3000,
+ .off_on_delay = 36000,
+ .owner = THIS_MODULE,
+ },
+};
+
+static const struct regulator_desc wm8958_ldo_desc[] = {
{
.name = "LDO1",
.id = 1,
@@ -172,9 +201,16 @@ static int wm8994_ldo_probe(struct platform_device *pdev)
* regulator core and we need not worry about it on the
* error path.
*/
- ldo->regulator = devm_regulator_register(&pdev->dev,
- &wm8994_ldo_desc[id],
- &config);
+ if (ldo->wm8994->type == WM8994) {
+ ldo->regulator = devm_regulator_register(&pdev->dev,
+ &wm8994_ldo_desc[id],
+ &config);
+ } else {
+ ldo->regulator = devm_regulator_register(&pdev->dev,
+ &wm8958_ldo_desc[id],
+ &config);
+ }
+
if (IS_ERR(ldo->regulator)) {
ret = PTR_ERR(ldo->regulator);
dev_err(wm8994->dev, "Failed to register LDO%d: %d\n",
--
2.20.1
On Mon, Mar 28, 2022 at 03:36:53PM +0100, Mark Brown wrote:
> On Mon, Mar 28, 2022 at 01:11:32PM +0000, Charles Keepax wrote:
>
> > Part of me wonders if we should just apply it to 1811 and 8958
> > anyway, I suspect they have the same IP for the LDO and its just
> > the datasheets never got updated. I had a go chasing the apps guys
> > here but we are a little short on people who remember details of
> > these parts. So I guess we trust the datasheets for now, unless
> > you have any strong feelings, Mark?
>
> With something like this the on/off time may be a requirement of the
> thing being powered rather than the regulator, the device might see
> enough power loss to confuse state but not trip the power on reset.
Aye a good point. I am certainly happy to stick with trusting the
datasheets here.
Thanks,
Charles
On Mon, Mar 28, 2022 at 01:11:32PM +0000, Charles Keepax wrote:
> Part of me wonders if we should just apply it to 1811 and 8958
> anyway, I suspect they have the same IP for the LDO and its just
> the datasheets never got updated. I had a go chasing the apps guys
> here but we are a little short on people who remember details of
> these parts. So I guess we trust the datasheets for now, unless
> you have any strong feelings, Mark?
With something like this the on/off time may be a requirement of the
thing being powered rather than the regulator, the device might see
enough power loss to confuse state but not trip the power on reset.
On Sun, Mar 27, 2022 at 06:01:54PM -0700, Jonathan Bakker wrote:
> As per Table 130 of the wm8994 datasheet at [1], there is an off-on
> delay for LDO1 and LDO2. In the wm8958 datasheet [2], I could not
> find any reference to it. I could not find a wm1811 datasheet to
> double-check there, but as no one has complained presumably it works
> without it.
>
> This solves the issue on Samsung Aries boards with a wm8994 where
> register writes fail when the device is powered off and back-on
> quickly.
>
> [1] https://statics.cirrus.com/pubs/proDatasheet/WM8994_Rev4.6.pdf
> [2] https://statics.cirrus.com/pubs/proDatasheet/WM8958_v3.5.pdf
>
> Signed-off-by: Jonathan Bakker <[email protected]>
> ---
I can confirm the 1811 also doesn't mention the cycle time in the
datasheet. So that checks out.
Acked-by: Charles Keepax <[email protected]>
Part of me wonders if we should just apply it to 1811 and 8958
anyway, I suspect they have the same IP for the LDO and its just
the datasheets never got updated. I had a go chasing the apps guys
here but we are a little short on people who remember details of
these parts. So I guess we trust the datasheets for now, unless
you have any strong feelings, Mark?
Thanks,
Charles
On Sun, 27 Mar 2022 18:01:54 -0700, Jonathan Bakker wrote:
> As per Table 130 of the wm8994 datasheet at [1], there is an off-on
> delay for LDO1 and LDO2. In the wm8958 datasheet [2], I could not
> find any reference to it. I could not find a wm1811 datasheet to
> double-check there, but as no one has complained presumably it works
> without it.
>
> This solves the issue on Samsung Aries boards with a wm8994 where
> register writes fail when the device is powered off and back-on
> quickly.
>
> [...]
Applied to
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git for-next
Thanks!
[1/1] regulator: wm8994: Add an off-on delay for WM8994 variant
commit: 92d96b603738ec4f35cde7198c303ae264dd47cb
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying
to this mail.
Thanks,
Mark