From patchwork Tue Jun 26 14:45:37 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Stefan Agner X-Patchwork-Id: 10489247 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork.web.codeaurora.org (Postfix) with ESMTP id 55CE96031B for ; Tue, 26 Jun 2018 14:45:41 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 4473F212D5 for ; Tue, 26 Jun 2018 14:45:41 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 3890F212DA; Tue, 26 Jun 2018 14:45:41 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-7.8 required=2.0 tests=BAYES_00,DKIM_SIGNED, MAILING_LIST_MULTI, RCVD_IN_DNSWL_HI, T_DKIM_INVALID autolearn=ham version=3.3.1 Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id AD1D2212D5 for ; Tue, 26 Jun 2018 14:45:40 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S935027AbeFZOpk (ORCPT ); Tue, 26 Jun 2018 10:45:40 -0400 Received: from mail.kmu-office.ch ([178.209.48.109]:58418 "EHLO mail.kmu-office.ch" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S934936AbeFZOpj (ORCPT ); Tue, 26 Jun 2018 10:45:39 -0400 Received: from webmail.kmu-office.ch (unknown [IPv6:2a02:418:6a02::a3]) by mail.kmu-office.ch (Postfix) with ESMTPSA id 1AC3F5C0E11; Tue, 26 Jun 2018 16:45:38 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=agner.ch; s=dkim; t=1530024338; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=hyXPwCzfFDemBbz6eljmyp5qrgNChGkiX73eyjRguyc=; b=bv0S60JJLQBenpw0QSof7xXOpy1pmbxrsiwYvXl13/5kd+CstQpqI4b4Uf/Z/1El3A13wW TQH7068yim/7ZSaugDKGnHh0A1apSpcV/EFzdJErndqqipT9sy0nCaUy+y6qcssxxYbR+6 URZBdpPneNLnqewZD5ySd2YiR+mEm8Q= MIME-Version: 1.0 Date: Tue, 26 Jun 2018 16:45:37 +0200 From: Stefan Agner To: adrian.hunter@intel.com, aisheng.dong@nxp.com, fabio.estevam@nxp.com Cc: linux-mmc@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-mmc-owner@vger.kernel.org Subject: Re: Self-detected stall on CPU when using SD card In-Reply-To: <037cbd3560a68bad0cea92f453c1b819@agner.ch> References: <037cbd3560a68bad0cea92f453c1b819@agner.ch> Message-ID: <0f262b04fab61ec75b7e368a8f4968aa@agner.ch> X-Sender: stefan@agner.ch User-Agent: Roundcube Webmail/1.3.4 X-Spamd-Result: default: False [-3.09 / 15.00]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; BAYES_HAM(-2.99)[99.96%]; RCPT_COUNT_FIVE(0.00)[6]; MIME_GOOD(-0.10)[text/plain]; FROM_HAS_DN(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; DKIM_SIGNED(0.00)[]; RCVD_COUNT_ZERO(0.00)[0]; ASN(0.00)[asn:29691, ipnet:2a02:418::/29, country:CH]; TO_DN_NONE(0.00)[]; RCVD_TLS_ALL(0.00)[]; ARC_NA(0.00)[] Sender: linux-mmc-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-mmc@vger.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP On 26.06.2018 12:53, Stefan Agner wrote: > Hi, > > On our Colibri iMX6 (arch/arm/boot/dts/imx6qdl-colibri.dtsi) we > experience the following stack trace when a SD card is plugged in: > [...] > [] (esdhc_pltfm_set_clock) from [] > (sdhci_set_ios+0xd8/0x584) > r10:ffffe000 r9:c1105900 r8:00004097 r7:d818f2e8 r6:d818f480 > r5:d818f2e8 > r4:d818f000 > [] (sdhci_set_ios) from [] > (sdhci_runtime_resume_host+0xa0/0x184) > r9:c1105900 r8:00004097 r7:d818f2e8 r6:d818f648 r5:d818f000 r4:d818f480 [...] > > It used to work in v4.9, so I started a git bisect. It pointed me to > this commit: > > Commit d1e4f74f911d ("mmc: sdhci: Do not use spin lock in set_ios > paths"). > > Reverting the commit on-top of v4.18-rc1 seems to fix the issue too. > > Any idea? I figured out that the same platform had a GPIO Key which triggered all the time. This seems to exacerbate the MMC issue such that it triggers on very boot, about rootfs mount time. This change seems to fix the issue as well, not sure though whether this is a proper fix: if (clock == 0) { @@ -724,6 +725,7 @@ static inline void esdhc_pltfm_set_clock(struct sdhci_host *host, pre_div = 2; } + spin_lock_irqsave(&host->lock, flags); temp = sdhci_readl(host, ESDHC_SYSTEM_CONTROL); temp &= ~(ESDHC_CLOCK_IPGEN | ESDHC_CLOCK_HCKEN | ESDHC_CLOCK_PEREN | ESDHC_CLOCK_MASK); @@ -754,6 +756,7 @@ static inline void esdhc_pltfm_set_clock(struct sdhci_host *host, writel(val | ESDHC_VENDOR_SPEC_FRC_SDCLK_ON, host->ioaddr + ESDHC_VENDOR_SPEC); } + spin_unlock_irqrestore(&host->lock, flags); mdelay(1); } --- Stefan -- To unsubscribe from this list: send the line "unsubscribe linux-mmc" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html --- a/drivers/mmc/host/sdhci-esdhc-imx.c +++ b/drivers/mmc/host/sdhci-esdhc-imx.c @@ -697,6 +697,7 @@ static inline void esdhc_pltfm_set_clock(struct sdhci_host *host, int ddr_pre_div = imx_data->is_ddr ? 2 : 1; int pre_div = 1; int div = 1; + unsigned long flags; u32 temp, val;