From patchwork Thu Jan 12 21:02:32 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Brian Norris X-Patchwork-Id: 9514185 X-Patchwork-Delegate: kvalo@adurom.com 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 29D0860476 for ; Thu, 12 Jan 2017 21:03:01 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 1B97828658 for ; Thu, 12 Jan 2017 21:03:01 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 1055D28702; Thu, 12 Jan 2017 21:03:01 +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.0 required=2.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, RCVD_IN_DNSWL_HI 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 880E928701 for ; Thu, 12 Jan 2017 21:03:00 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1750899AbdALVCt (ORCPT ); Thu, 12 Jan 2017 16:02:49 -0500 Received: from mail-pf0-f172.google.com ([209.85.192.172]:36000 "EHLO mail-pf0-f172.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750893AbdALVCq (ORCPT ); Thu, 12 Jan 2017 16:02:46 -0500 Received: by mail-pf0-f172.google.com with SMTP id 189so18655705pfu.3 for ; Thu, 12 Jan 2017 13:02:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=from:to:cc:subject:date:message-id:in-reply-to:references; bh=W5Yrm/vCHHLIenucD+hgjvJnuK+TCVj2kbgxpDyGE7k=; b=ZAPju/B2AW7gwVoQaZiE4K32hK2vnHS3F/CPzUWd0N/0+oW0Nld5wpXsV8Jo+Hadww usXO/CgkR5GX7ZBpXWBLuJeb+iGcaymEq1GXUpn3vIcUBEMlThpP3CDdx3e5b7+vZtJt H7gTup5uc60jypxig14px9ptD33tGwvLb8D4Y= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references; bh=W5Yrm/vCHHLIenucD+hgjvJnuK+TCVj2kbgxpDyGE7k=; b=AG2ZIF/7JRrmsbmicJIlHDohWl31SzOpPOautZUUa5ppmljLxAAvPkMGBl0ThI8QA3 jCLWMhlA6qLcE7yaKXud/ocG3/YtZ9jwr+K53rTV1hO8Vq7hqbqvnE4qCuEN2BHB0Fwm jiC+AhnPyjTsMn6GSStwAC2tPbOJpxVKveyda1nfLgJlIOlZioUnIH1TmsW5pgDo2eoZ wbmS199aEaiHDKHErHQ6oEgpRChJ0oiGFeZLgwAPGqMFzHb3wIyllTm8Ivr1Jy/K6uu+ EBspwuzJqRlkfoVJgkUS0jBxdK7QvgXxLmT+oIQfWXO0TacSAj5hQ2IGs34JSB1e9KwG Ys+Q== X-Gm-Message-State: AIkVDXI1NolScPs1YMPFuutksEu6MunwTorECntSQn0nG2BgK/7/L/f0Q+eg0j0U+e+ICix4 X-Received: by 10.98.26.210 with SMTP id a201mr18819035pfa.57.1484254965298; Thu, 12 Jan 2017 13:02:45 -0800 (PST) Received: from ban.mtv.corp.google.com ([172.22.64.120]) by smtp.gmail.com with ESMTPSA id p13sm23863380pgf.47.2017.01.12.13.02.44 (version=TLS1_2 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 12 Jan 2017 13:02:44 -0800 (PST) From: Brian Norris To: Amitkumar Karwar , Nishant Sarmukadam Cc: , Kalle Valo , linux-wireless@vger.kernel.org, Cathy Luo , Brian Norris Subject: [PATCH 2/2] mwifiex: pcie: don't delay for sleep cookie when not required Date: Thu, 12 Jan 2017 13:02:32 -0800 Message-Id: <20170112210232.18554-2-briannorris@chromium.org> X-Mailer: git-send-email 2.11.0.390.gc69c2f50cf-goog In-Reply-To: <20170112210232.18554-1-briannorris@chromium.org> References: <20170112210232.18554-1-briannorris@chromium.org> Sender: linux-wireless-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-wireless@vger.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP Wifi modules like 8997 don't support the "sleep cookie", and so most of the time, we just time out in the mwifiex_delay_for_sleep_cookie() function ("max count reached while accessing sleep cookie"). This is a waste of time, and we should skip it for modules without the sleep cookie flag. Additionally, this delay is sometimes counterproductive. For instance, when PCIe ASPM is enabled, this extra delay can leave the link idle for long enough to re-enter a low-power state even while we are trying to wake the module, compounding an additional delay when it comes time to read the next register (e.g., the interrupt status). On some systems, this is detrimental to overall system latency. Signed-off-by: Brian Norris --- Tested on Marvell 8997, but would be good to get confirmation from Marvell. drivers/net/wireless/marvell/mwifiex/pcie.c | 12 +++++++----- 1 file changed, 7 insertions(+), 5 deletions(-) diff --git a/drivers/net/wireless/marvell/mwifiex/pcie.c b/drivers/net/wireless/marvell/mwifiex/pcie.c index 435ba879ef29..11e0673617c7 100644 --- a/drivers/net/wireless/marvell/mwifiex/pcie.c +++ b/drivers/net/wireless/marvell/mwifiex/pcie.c @@ -1712,11 +1712,13 @@ static int mwifiex_pcie_process_cmd_complete(struct mwifiex_adapter *adapter) "Write register failed\n"); return -1; } - mwifiex_delay_for_sleep_cookie(adapter, - MWIFIEX_MAX_DELAY_COUNT); - while (reg->sleep_cookie && (count++ < 10) && - mwifiex_pcie_ok_to_access_hw(adapter)) - usleep_range(50, 60); + if (reg->sleep_cookie) { + mwifiex_delay_for_sleep_cookie(adapter, + MWIFIEX_MAX_DELAY_COUNT); + while ((count++ < 10) && + mwifiex_pcie_ok_to_access_hw(adapter)) + usleep_range(50, 60); + } mwifiex_pcie_enable_host_int(adapter); mwifiex_process_sleep_confirm_resp(adapter, skb->data, skb->len);