| Message ID | 1453718849-3508-1-git-send-email-sjoerd.simons@collabora.co.uk |
|---|---|
| State | Accepted |
| Commit | 97f1a17109272b9f060cbd6d1d5be41528643000 |
| Headers | show |
On Mon, 2016-01-25 at 16:36 +0100, Arend van Spriel wrote: > 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. The only reference i could find for where the timeout came from was in the bcmdhd which has: #define IOCTL_RESP_TIMEOUT 2000 /* In milli second default value for Production FW */ But not sure if that's helpful :). > 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 <arend@broadcom.com> > > Signed-off-by: Sjoerd Simons <sjoerd.simons@collabora.co.uk> > > > > --- > 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 > > > > -- Sjoerd Simons Collabora Ltd.
On Mon, 2016-01-25 at 21:07 +0100, Arend van Spriel wrote: > On 25-1-2016 20:23, Doug Anderson wrote: > > Kinda curious: do we get one or two really slow responses on every > > bootup, or just some bootups? Do we ever succeed even with a slow > > (like 1.8 or 1.9 seconds) response, or is it always either "fast" > > or > > "2.1" seconds? > > Now these are interesting questions that I should have spilled out in > the first place. Thanks. I would need to get a more data to really conclusively say, but what i saw in testing thusfar was: * The issue occurs on _some_ boots * The issue seems to come up more often on warm reboots * The likelyhood seemed to change depending on the kernel configuration (iotw when the initilisation order/timing changed?) * Forcing the brcmfmac module to load later in boot seemed to make the likelyhood of the issue showing up lower. * The samples I have with traces showed either quick responses on success or slow "2.1" seconds responses on failure. I'll try to make some time to get some statistics over a series of boots wrt. the response time(s) for control messages so we can get a better idea how often this happens and its behaviour. I guess one other thing to note is that both Doug and myself were seeing this on Rockchip RK3288 based devices. It would ofcourse be interesting to know if this has been seen on other types of devices.. -- Sjoerd Simons Collabora Ltd.
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
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. 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. Signed-off-by: Sjoerd Simons <sjoerd.simons@collabora.co.uk> --- drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) -- 2.7.0