From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S934350AbbCPSpZ (ORCPT ); Mon, 16 Mar 2015 14:45:25 -0400 Received: from opensource.wolfsonmicro.com ([80.75.67.52]:55833 "EHLO opensource.wolfsonmicro.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S934266AbbCPSpV (ORCPT ); Mon, 16 Mar 2015 14:45:21 -0400 Date: Mon, 16 Mar 2015 18:45:18 +0000 From: Charles Keepax To: Mark Brown Cc: lee.jones@linaro.org, sameo@linux.intel.com, lgirdwood@gmail.com, patches@opensource.wolfsonmicro.com, linux-kernel@vger.kernel.org Subject: Re: [PATCH 3/5] mfd: wm5110: Add delay before releasing reset line on cold boot Message-ID: <20150316184518.GB23705@opensource.wolfsonmicro.com> 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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150316171232.GU28806@sirena.org.uk> User-Agent: Mutt/1.5.17+20080114 (2008-01-14) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Mar 16, 2015 at 05:12:32PM +0000, Mark Brown wrote: > On Mon, Mar 16, 2015 at 04:58:42PM +0000, Charles Keepax wrote: > > > On the first boot of the wm5110 it is important the reset line is held > > for slightly longer to ensure the device starts up well. This patch adds > > a 5mS delay for this. > > How can we tell what first boot is - what happens if the device is fully > powered off during system suspend for example? I'd expect to see this > done for system resume as well if we don't know power was maintained (or > whatever else the distinction is). Internally the device has some state, so effectively we define the first boot as the first time DCVDD is applied since either the last physical reset or time the core_supplies were missing. 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 anyway to tell if they were removed, since we can't talk to the CODEC without DCVDD (even if we could I don't think we can find out) and we need to know before we power it up. Also presumably if the system removed the regulator when we told it not to it won't report anything through the regulator framework. 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. All in all, I really struggle to see what more the driver could do here. Thanks, Charles