Return-path: Received: from mail-wm0-f54.google.com ([74.125.82.54]:34810 "EHLO mail-wm0-f54.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754830AbcAYPgt (ORCPT ); Mon, 25 Jan 2016 10:36:49 -0500 Subject: Re: [PATCH] brcmfmac: sdio: Increase the default timeouts a bit To: Sjoerd Simons , Kalle Valo References: <1453718849-3508-1-git-send-email-sjoerd.simons@collabora.co.uk> Cc: Paul Stewart , Doug Anderson , linux-rockchip@lists.infradead.org, Arend van Spriel , Pieter-Paul Giesberts , brcm80211-dev-list@broadcom.com, linux-wireless@vger.kernel.org, linux-kernel@vger.kernel.org, Hante Meuleman , Brett Rudley , netdev@vger.kernel.org, "Franky (Zhenhui) Lin" , Adrian Hunter , linux-mmc@vger.kernel.org From: Arend van Spriel Message-ID: <56A64114.3010400@gmail.com> (sfid-20160125_163730_522246_18759FCE) Date: Mon, 25 Jan 2016 16:36:52 +0100 MIME-Version: 1.0 In-Reply-To: <1453718849-3508-1-git-send-email-sjoerd.simons@collabora.co.uk> Content-Type: text/plain; charset=windows-1252 Sender: linux-wireless-owner@vger.kernel.org List-ID: On 25-01-16 11:47, Sjoerd Simons wrote: > On a Radxa Rock2 board with a Ampak AP6335 (Broadcom 4339 core) it seems > the card responds very quickly most of the time, unfortunately during > initialisation it sometimes seems to take just a bit over 2 seconds to > respond. > > This results intialization failing with message like: > brcmf_c_preinit_dcmds: Retreiving cur_etheraddr failed, -52 > brcmf_bus_start: failed: -52 > brcmf_sdio_firmware_callback: dongle is not responding > > Increasing the timeout to allow for a bit more headroom allows the > card to initialize reliably. I would prefer to know where the 2 second response time comes from. Could be sdio retuning. Maybe the chromeos people can comment whether this has been root caused. There is a mmc patch pending in which retuning procedure can be deferred by the driver. Using that API may resolve the issue as well and I would prefer that solution. > A quick search online after diagnosing/fixing this showed that Google > has a similar patch in their ChromeOS tree, so this doesn't seem > specific to the board I'm using. As the retuning stuff is not in main line I guess we need this fix for now so... Acked-by: Arend van Spriel > Signed-off-by: Sjoerd Simons > > --- Still would like to know whether it is firmware initialization or some mmc stack procedure. Any suggestions to debug this are welcome. Regards, Arend --- > > drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c > index dd66143..75ac4bd 100644 > --- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c > +++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c > @@ -45,8 +45,8 @@ > #include "chip.h" > #include "firmware.h" > > -#define DCMD_RESP_TIMEOUT msecs_to_jiffies(2000) > -#define CTL_DONE_TIMEOUT msecs_to_jiffies(2000) > +#define DCMD_RESP_TIMEOUT msecs_to_jiffies(2500) > +#define CTL_DONE_TIMEOUT msecs_to_jiffies(2500) > > #ifdef DEBUG > >