From patchwork Tue Sep 6 09:42:35 2016 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Ulf Hansson X-Patchwork-Id: 9316273 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 7980960752 for ; Tue, 6 Sep 2016 09:42:44 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 6BD0D287BB for ; Tue, 6 Sep 2016 09:42:44 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 6076728C2D; Tue, 6 Sep 2016 09:42:44 +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=-4.4 required=2.0 tests=BAYES_00,DKIM_SIGNED, RCVD_IN_DNSWL_HI, RCVD_IN_SORBS_SPAM, 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 44D2B287BB for ; Tue, 6 Sep 2016 09:42:42 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933472AbcIFJmk (ORCPT ); Tue, 6 Sep 2016 05:42:40 -0400 Received: from mail-wm0-f44.google.com ([74.125.82.44]:37529 "EHLO mail-wm0-f44.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S933143AbcIFJmi (ORCPT ); Tue, 6 Sep 2016 05:42:38 -0400 Received: by mail-wm0-f44.google.com with SMTP id w12so81013133wmf.0 for ; Tue, 06 Sep 2016 02:42:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=lRziJgI3aRMKU7+iEM4sXx99tcA6mNM7M9ZThpqvJ1E=; b=O6Ck0JH083UmQT+UyZYAY4lsEo321uYk5tugbyuA9SmlemX4fO/tbhBtgdVLALSh80 XG73jXule44GqlhK/tDZR/Ji45bV5AzEYMe66Pe76HA2FQx3apX1riZj7LmXQeAqH8vu sU6NpLE6+7dooERFkRnH2WIq2O5mduvz2Feyc= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=lRziJgI3aRMKU7+iEM4sXx99tcA6mNM7M9ZThpqvJ1E=; b=WoAJ9PYJw/DvNT077F+2wrKjg58LYhRKUGKV4JeOk1UBmTfSu5w9yaa7IPA4q6M+cn rNPHYeZeNduwkRDEsC6RBLrggl8ZZ7Sp4jhVd3DldF8fyf6B9sk75XAHsQIvORE1XEMo 95eQJWFD81O0XjoI9zdDeT1Tr3dVl23ecercGNbI87ACa4yyi5dgSztex4b5kpc7wAyE YwkhTOd1mWMvJg9Ku29W/7I9mnjactfaowVRmKxsp9h4+4dA/CFNOoCejwX/ylzqQ58x ASuwnhaXB0X6dGg1rj9HbuQeVYp2TReDsEactDDG12dmwxYikDl50vCJoPzWxBgAv1iY 2FPg== X-Gm-Message-State: AE9vXwN/FK3YrnvWufESRgdYV7djEaF60dQZ52PsW80WNewaNcr+e0pXI0OwH+OIBSk+npQajyGOHZYmkK+S+3n1 X-Received: by 10.28.20.77 with SMTP id 74mr18742717wmu.1.1473154957285; Tue, 06 Sep 2016 02:42:37 -0700 (PDT) MIME-Version: 1.0 Received: by 10.194.40.167 with HTTP; Tue, 6 Sep 2016 02:42:35 -0700 (PDT) In-Reply-To: References: <1473080344.10346.4.camel@researchut.com> From: Ulf Hansson Date: Tue, 6 Sep 2016 11:42:35 +0200 Message-ID: Subject: Re: xHCI problem? [was Re: Erratic USB device behavior and device loss] To: Alan Stern , Ritesh Raj Sarraf Cc: USB list , linux-mmc 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 5 September 2016 at 17:58, Alan Stern wrote: > On Mon, 5 Sep 2016, Ritesh Raj Sarraf wrote: > >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA512 >> >> On Sun, 2016-09-04 at 15:46 -0400, Alan Stern wrote: >> > >> > This is not the problem I was discussing with Ulf. The problem was why >> > the device kept going into and out of runtime suspend every three >> > seconds. The kernel log above does not say whether this was happening. >> > One way to tell is to look at a usbmon trace (like we did before). >> >> https://people.debian.org/~rrs/tmp/usbmon.txt.gz >> >> This should have the logs you asked for, running on 4.8-rc4. > > Confirmed, the runtime suspends and resumes are still happening. > > Ulf, any insights? Alan, Ritesh, Yes, I am starting to understand more about what goes on here. Although I need help to test as I don't have the HW. As you already guessed, I suspect the problem is within the runtime PM deployment in the drivers/mmc/host/rtsx_usb_sdmmc.c. Let me start by first give you some background to how the mmc core deals with runtime PM. *) The mmc core manages most of the calls to the pm_runtime_get|put*() and pm_runtime_mark_last_busy() for the mmc host device. The gets/puts are done when the core is about to access the mmc host device, via the mmc host ops driver interface. You may search for calls to the mmc_claim|release_host() functions to find out when the gets/puts are done. **) The mmc core have also deployed runtime PM for the mmc *card* device and which has the runtime PM autosuspend feature enabled with a 3s default timeout. One important point is that the mmc card device has the mmc host device assigned as being its parent device. I guessing the reason to why you are encountering strange 3s intervals of runtime PM suspend/resume is related to this. Now, in this case, the rtsx_usb_sdmmc driver seems to need a bit of special runtime PM deployment, as the calls to pm_runtime_get|put*() also controls the power to the usb device and thus also the power to the card. I am guessing that's done via the usb device being assigned as parent for the mmc host's platform device!? By reviewing the code of the rtsx_usb_sdmmc driver, particularly how it calls pm_runtime_get|put() I am guessing those calls may not be properly deployed. Perhaps rtsx_usb_sdmmc should convert to use the usb_autopm_put|get_interface() and friends, although I didn't want to make that change at this point so instead I have cooked a patch that might fixes the behaviour. Ritesh, can you please try it out to see what happens? --- drivers/mmc/host/rtsx_usb_sdmmc.c | 7 +------ 1 file changed, 1 insertion(+), 6 deletions(-) sd_set_timing(host, ios->timing, &host->ddr_mode); @@ -1336,7 +1331,7 @@ static void rtsx_usb_init_host(struct rtsx_usb_sdmmc *host) MMC_CAP_MMC_HIGHSPEED | MMC_CAP_BUS_WIDTH_TEST | MMC_CAP_UHS_SDR12 | MMC_CAP_UHS_SDR25 | MMC_CAP_UHS_SDR50 | MMC_CAP_NEEDS_POLL; - mmc->caps2 = MMC_CAP2_NO_PRESCAN_POWERUP | MMC_CAP2_FULL_PWR_CYCLE; + mmc->caps2 = MMC_CAP2_FULL_PWR_CYCLE; mmc->max_current_330 = 400; mmc->max_current_180 = 800; diff --git a/drivers/mmc/host/rtsx_usb_sdmmc.c b/drivers/mmc/host/rtsx_usb_sdmmc.c index 6c71fc9..3d6fe51 100644 --- a/drivers/mmc/host/rtsx_usb_sdmmc.c +++ b/drivers/mmc/host/rtsx_usb_sdmmc.c @@ -1138,11 +1138,6 @@ static void sdmmc_set_ios(struct mmc_host *mmc, struct mmc_ios *ios) dev_dbg(sdmmc_dev(host), "%s\n", __func__); mutex_lock(&ucr->dev_mutex); - if (rtsx_usb_card_exclusive_check(ucr, RTSX_USB_SD_CARD)) { - mutex_unlock(&ucr->dev_mutex); - return; - } - sd_set_power_mode(host, ios->power_mode); sd_set_bus_width(host, ios->bus_width);