From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752977AbbCQMEg (ORCPT ); Tue, 17 Mar 2015 08:04:36 -0400 Received: from mezzanine.sirena.org.uk ([106.187.55.193]:49289 "EHLO mezzanine.sirena.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752069AbbCQMEd (ORCPT ); Tue, 17 Mar 2015 08:04:33 -0400 Date: Tue, 17 Mar 2015 12:04:21 +0000 From: Mark Brown To: Charles Keepax Cc: lee.jones@linaro.org, sameo@linux.intel.com, lgirdwood@gmail.com, patches@opensource.wolfsonmicro.com, linux-kernel@vger.kernel.org Message-ID: <20150317120421.GD28806@sirena.org.uk> References: <1426525124-12317-1-git-send-email-ckeepax@opensource.wolfsonmicro.com> <1426525124-12317-3-git-send-email-ckeepax@opensource.wolfsonmicro.com> <20150316171232.GU28806@sirena.org.uk> <20150316184518.GB23705@opensource.wolfsonmicro.com> <20150316204710.GX28806@sirena.org.uk> <20150317115030.GC23705@opensource.wolfsonmicro.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="FRDPXJ8Zo4iB1MPv" Content-Disposition: inline In-Reply-To: <20150317115030.GC23705@opensource.wolfsonmicro.com> X-Cookie: Editing is a rewording activity. User-Agent: Mutt/1.5.23 (2014-03-12) X-SA-Exim-Connect-IP: 94.175.94.161 X-SA-Exim-Mail-From: broonie@sirena.org.uk Subject: Re: [PATCH 3/5] mfd: wm5110: Add delay before releasing reset line on cold boot X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000) X-SA-Exim-Scanned: Yes (on mezzanine.sirena.org.uk) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org --FRDPXJ8Zo4iB1MPv Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Tue, Mar 17, 2015 at 11:50:30AM +0000, Charles Keepax wrote: > On Mon, Mar 16, 2015 at 08:47:10PM +0000, Mark Brown wrote: > > 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. Yes. > 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. Sure, that's perfectly fine - jack detection is also very common. > 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? Given jack detection I don't think you can base this purely on the CODEC part of the device. > 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? It seems easy enough to check if the device is active and it's very common for drivers to do this (wm8994 has an example) - for most uses you should be able to check pm_runtime_is_enabled() and there should just be a single bitfield you can look at to figure out if jack detection was running. Looking at the extcon driver briefly ARIZONA_JD1_ENA looks hopeful. --FRDPXJ8Zo4iB1MPv Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJVCBhFAAoJECTWi3JdVIfQbs4H/29Nq6c85K+N81aFyv8raHqY HAiV8rhnuTcGbPL+cKzILE5faYRLcTzuHH2IXK7xz3Wll5BkOmtAL88xRXVxxTRC n/8e4Pi4+b/i45LR5H/tMw9Gz2hNYEFEp4PElAnhISgWp7Vznu44poHKyGgfj8T8 kDxh+W1tKdEWf1ejNVX7LnJtFpj776XtMqV2nZPbd0uuXFIIQFT7O6QxcnUwLYu2 bxn10rqGwySEEk2jaNx1t4oGRU90ezLOYyJd4ldePKXsV8Su837go+jEh0UVsOCi JD9fsIPTUP1+sIMw/tlgDaN++iCkaYNUjWWhAQ/p5TIx76OvAYqw7caL3uCf+wc= =/9qZ -----END PGP SIGNATURE----- --FRDPXJ8Zo4iB1MPv--