Re: [PATCH 3/5] mfd: wm5110: Add delay before releasing reset line on cold boot

[Charles Keepax <ckeepax@opensource.wolfsonmicro.com>]

On Mon, Mar 16, 2015 at 08:47:10PM +0000, Mark Brown wrote:
> On Mon, Mar 16, 2015 at 06:45:18PM +0000, Charles Keepax wrote:
> 
> > I think your suspend example is pretty tricky, we enable the
> > regulators for the core_supplies at boot, so I guess we have
> > requested that the system never removes those so if it does so
> > anyway perhaps that is a system problem? There isn't really
> 
> No, there's no guarantee that the current state is maintained over
> system suspend - system suspend can turn anything off (at least from an
> API point of view).
> 
> > That would leave the only possible solution being a hard reset
> > during every runtime resume but that makes me very nervous about
> > the AoD interrupts as state for those would be lost upon that
> > reset.
> 
> No, you're guaranteed that the supply will stay on while the system is
> running so runtime PM is not an issue - it's system suspend that's an
> issue.
> 
> > All in all, I really struggle to see what more the driver could
> > do here.
> 
> As I suggested in my original reply handle system suspend.

Just to confirm when we say system suspend here we are talking
about the suspend and resume callbacks in dev_pm_ops? As I am
slightly concerned I have my wires very crossed here.

Assuming I don't have my wires crossed.

There are use-cases were we expect the CODEC to be powered up
across system suspend, is that something we should not expect to
be guaranteed possible? For example compressed off-load or always
on voice.

If these use-cases are expected to be reasonable then it would be
reasonable to assume the regulators would not be removed if a
runtime reference to the CODEC is held. If we can't assume that
then how do we know if we should reset the CODEC?

So I guess we could reset the chip in system resume if no runtime
references are held, but that still has the same problem as
resetting in runtime resume, the chip may have been active
running jack detection and you have just blatted the
settings/state. I guess you could have the extcon driver restore
the settings at least in its system resume, but it really feels
like we are likely to be introducing issues worse than those this
patch is there to fix.

Apologies if I am missing something very basic here. Does this
really need to be done before this patch could be accepted?

Thanks,
Charles