drivers: regulator: npm1300: workaround for LDO HW bug #83790
Conversation
zephyrbot
added
platform: nRF
zephyrbot
requested review from
aasinclair,
anangl,
avisconti,
danieldegrasse,
erwango,
gmarull,
jaz1-nordic,
jfischer-no,
kartben,
kl-cruz,
magp-nordic,
masz-nordic and
nika-nordic
| ldo-workaround-enabled: | ||
| type: boolean | ||
| description: | | ||
| Enable a SW workaround for LDO bug. | ||
| When nPM1300 is in ULP mode, LDO is supplied from VSYS and | ||
| then LDO is enabled, it can take long time until the LDO | ||
| output has reached its target voltage. To avoid this, an i2c | ||
| read is performed shortly after an LDO is enabled. |
There was a problem hiding this comment.
why is DT involved here? Shouldn't this always be enabled as needed?
There was a problem hiding this comment.
This bug shows itself only in a very specific case. We cannot know whether this case is present since it involves HW design choices. It is enabled by default to be on a safe side, but if developers know that they don't run into this corner case they can avoid a redundant operation disabling this behavior.
There was a problem hiding this comment.
So if enabled by default, change the property like this:
nordic,ldo-disable-...
Also, calling this "SW workaround for LDO" feels too generic, is there any associated PAN?
There was a problem hiding this comment.
PAN/ERRATA is coming soon, would it be okay to add a reference to it later? We'd really like to have a fix in place even without a reference for the time being
seov-nordic
force-pushed
the
npm1300-LDO-bug-workaround
branch
2 times, most recently
from
0c37a3f to
89ec756
Compare
| nordic,ldo-disable-workaround: | ||
| type: boolean | ||
| description: | | ||
| Disable the SW workaround for LDO bug. | ||
| When nPM1300 is in ULP mode, LDO is supplied from VSYS and | ||
| then LDO is enabled, it can take long time until the LDO | ||
| output has reached its target voltage. To avoid this, an i2c | ||
| read is performed shortly after an LDO is enabled. |
There was a problem hiding this comment.
I'm tempted to think that this really belongs to Kconfig (as many other erratas), unless we strictly need per-instance control.
There was a problem hiding this comment.
It isn't strictly necessary, although it makes sense since each LDO is supplied separately. So while this bug might be present on one in a given design the other might be bug-free.
I was trying to find some information on how erratas are handled in Zephyr, but didn't find much. Is there any documentation you could point me to? I don't have a strong opinion on how we handle this. If it's better to do with Kconfig from your perspective I can do that.
There is a HW bug in nPM1300 LDO which causes the LDO output voltage to reach its target very slowly in specific cases. This is worked around by performing an additional i2c read shortly after an LDO is enabled. Signed-off-by: Sergei Ovchinnikov <sergei.ovchinnikov@nordicsemi.no>
seov-nordic
force-pushed
the
npm1300-LDO-bug-workaround
branch
from
89ec756 to
f6936ad
Compare
There is a HW bug in nPM1300 LDO which causes the LDO output voltage to reach its target very slowly in specific cases. This is worked around by performing an additional i2c read shortly after an LDO is enabled.