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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
