Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1317228

Re: [PATCH] brcmfmac: sdio: Increase the default timeouts a bit

Path csiph.com!aioe.org!bofh.it!news.nic.it!robomod
From Doug Anderson <dianders@chromium.org>
Newsgroups linux.kernel
Subject Re: [PATCH] brcmfmac: sdio: Increase the default timeouts a bit
Date Mon, 25 Jan 2016 20:30:01 +0100
Message-ID <qUUZP-gp-3@gated-at.bofh.it> (permalink)
References <qUMSE-2CU-73@gated-at.bofh.it> <qURpi-60C-45@gated-at.bofh.it>
X-Original-To Arend van Spriel <aspriel@gmail.com>
Dkim-Signature v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=wb8u1dcBjXhmJGAqf0rhYvSGuTq+V22hpx7x4MDh3ks=; b=Gv7GWcFhZ8hN4kkeC1fU4NMjHWlE/ArtszTZc+/Ouv0j3wCOeHXxtoiKO/LLsCy8LI XzZKy/ryMoWVqfiDspwb8W3LHAO/+ne6x7gyFPPWd2NfALTXmNsth+hBqfx7Gwq3SZSb DEwvZ2sx8QdWSa6LFSdI365ZPQjSEejhuOCkM9jipHeKi1jCoahHPbwiDO60O3P8AoQV 2kqcC5ZcPcIm0WDYEmUTZbAwMZoE4DB5nka6xlzwggTasex5us8J9MoeXYzo6O0kmqyv 4hSViuxbgyTzlytUEpm36HlN0tGOrwvUWl2TV0XYuMhUavuRnCeuT+TIycONuo1snlLi 1xvQ==
Dkim-Signature v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=wb8u1dcBjXhmJGAqf0rhYvSGuTq+V22hpx7x4MDh3ks=; b=fOJEl7+b2wJWvTRklfICH0MjGPn+WWmi+wm0ZvS2RolUwkiSlLqj2I/ZaLH5IyY/cd 91BmOLzT0raT+0brGwyUPOsqoQBQvsd3nVMfhO0Q7qT+FCaVbd4vOsFwQOWs8cZJrrdZ 5c28H0UHY4UoPMfHjFMjDom5JBgh30MGx2HyU=
X-Google-Dkim-Signature v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=wb8u1dcBjXhmJGAqf0rhYvSGuTq+V22hpx7x4MDh3ks=; b=LdT+vBkWh+rsIwZqZ4DPMbd/ZJ+qQzmz1LEFvEdHMykM2XNPJQbyL2IeOcJ7pjyYaK QaclPE4lfvKAVenM2hJhLXEtB05bi1BaaKys+SYHYFiBrfwFLuTJJmN8h/RVSJ1XPP8N YnRHcc1N1G2h2VwM8RAlghP8Ldg0mxyMVUCQym8MVNIoxtLGLWgXr21I9cwS3/5bcmvA fpaIjYJGxgBr+SpAjAkLhHeESdMhSo4rj9nSUiC2xHRKT8zF7Wlq5nHap01WIgwlUKpG odsUl/JZnytmGl24hrtelazn61ETNiMxWpS4YfpQmOE8Muf1Hi/MyoLYSivKFhHwM0Xu f/8w==
X-Gm-Message-State AG10YOS3sY+ZcV1YV82jGCZSpmc58PrMlLWHX8xvZi2Ts1EzJr6E6dSb+lR30DCiVZXS+dBVKvH1L1ASLXT29Sos
MIME-Version 1.0
X-Received by 10.129.4.3 with SMTP id 3mr9273271ywe.342.1453749784399; Mon, 25 Jan 2016 11:23:04 -0800 (PST)
X-Google-Sender-Auth F48xzh-TCahz2k75rTolMLnSusQ
Content-Type text/plain; charset=UTF-8
Sender robomod@news.nic.it
List-ID <linux-kernel.vger.kernel.org>
X-Mailing-List linux-kernel@vger.kernel.org
Approved robomod@news.nic.it
Lines 100
Organization linux.* mail to news gateway
X-Original-Cc Sjoerd Simons <sjoerd.simons@collabora.co.uk>, Kalle Valo <kvalo@codeaurora.org>, Paul Stewart <pstew@chromium.org>, "open list:ARM/Rockchip SoC..." <linux-rockchip@lists.infradead.org>, Arend van Spriel <arend@broadcom.com>, Pieter-Paul Giesberts <pieterpg@broadcom.com>, brcm80211-dev-list@broadcom.com, "linux-wireless@vger.kernel.org" <linux-wireless@vger.kernel.org>, "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>, Hante Meuleman <meuleman@broadcom.com>, Brett Rudley <brudley@broadcom.com>, netdev@vger.kernel.org, "Franky (Zhenhui) Lin" <frankyl@broadcom.com>, Adrian Hunter <adrian.hunter@intel.com>, "linux-mmc@vger.kernel.org" <linux-mmc@vger.kernel.org>
X-Original-Date Mon, 25 Jan 2016 11:23:04 -0800
X-Original-Message-ID <CAD=FV=X-ejMLnh30TofU7dKP5WwZaXcgLaQwFs__wo9wHsv53Q@mail.gmail.com>
X-Original-References <1453718849-3508-1-git-send-email-sjoerd.simons@collabora.co.uk> <56A64114.3010400@gmail.com>
X-Original-Sender linux-kernel-owner@vger.kernel.org
Xref csiph.com linux.kernel:1317228

Show key headers only | View raw


Hi,

On Mon, Jan 25, 2016 at 7:36 AM, Arend van Spriel <aspriel@gmail.com> 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.

I reviewed Paul's change here
<https://chromium-review.googlesource.com/#/c/225921/> but didn't do
any root causing.

I think that, like Sjoerd saw, we were seeing this problem at boot
time.  Certainly at boot time lots of things are happening all at the
same time in the system and there are often delays, so anything that
might have been close to timing out in the past may now be actually
timing out.

This is the kind of thing that, IMHO, should have a real timeout that
is 10x what was expected and a non-fatal warning whenever we go over
the expected time.  ...but maybe that's overdesign.  :-P

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?


In any case, in my experience the Broadcom firmware is fairly
complicated and has numerous cases where it stretches SDIO more than
the other SDIO WiFi chip I've worked with.  It wouldn't terribly
surprise me if there was a period of time during bootup where it was
non-responsive for 2 seconds.  As unrelated "evidence" showing some of
the Broadcom SDIO limitations, you can see
<https://chromium-review.googlesource.com/#/c/250228/> and also the
fact that Broadcom often holds the SDIO "busy" signal whereas the
other SDIO WiFi chip I've worked never did that.  Also, even with all
fixes the Broadcom WiFi module will still show periodic SDIO errors
that the higher level driver just knows to ignore.

My old debugging from the (sorry, private) bug
http://crosbug.com/p/36975 showed this periodically even with all
known fixes:

[21310.271635] dwmmc_rockchip ff0d0000.dwmmc: CMD ERR: 0x00000104
[21550.583598] dwmmc_rockchip ff0d0000.dwmmc: CMD ERR: 0x00000104
[21550.616035] brcmfmac: brcmf_sdio_readframes: RXHEADER FAILED: -110
[21550.648460] brcmfmac: brcmf_sdio_rxfail: abort command, terminate
frame, send NAK
[21550.683502] dwmmc_rockchip ff0d0000.dwmmc: CMD ERR: 0x00000104
[21550.691214] dwmmc_rockchip ff0d0000.dwmmc: CMD ERR: 0x00000100
[22671.121329] dwmmc_rockchip ff0d0000.dwmmc: CMD ERR: 0x00000104
[22671.153167] dwmmc_rockchip ff0d0000.dwmmc: CMD ERR: 0x01000104
[22671.184581] brcmfmac: brcmf_sdio_readframes: RXHEADER FAILED: -110
[22671.192600] brcmfmac: brcmf_sdio_rxfail: abort command, terminate
frame, send NAK
[22671.201929] dwmmc_rockchip ff0d0000.dwmmc: CMD ERR: 0x00000114
[22671.209536] dwmmc_rockchip ff0d0000.dwmmc: CMD ERR: 0x00000100
[28463.941736] dwmmc_rockchip ff0d0000.dwmmc: CMD ERR: 0x00000104

At the time dekim@ responded:

> There are several sleep/wake control at different level. The one we're talking
> about here is controlled by brcmf_sdio_bus_sleep() in the host driver to turn
> on/off bus core on the chip. There can be a period of time when chip is not
> paying attention to the host command (cmd52 to the
> SBSDIO_FUNC1_SLEEPCSR).

...and we decided that the periodic SDIO errors weren't causing any
huge problems (since they were retried).  As far as I know, they still
happen today.


All of the above may not help you, but it serves as evidence that the
SDIO communication to Broadcom isn't terribly amazing and apparently
that's just the way that the module (or perhaps its firmware) is
designed.  It doesn't seem to affect anything in the real world, so I
suppose it is just something we need to live with.


Obviously if you have access to the firmware source code and can debug
further, that would be awesome.  I'm just not hopeful.


In any case:

Reviewed-by: Douglas Anderson <dianders@chromium.org>

Back to linux.kernel | Previous | NextPrevious in thread | Next in thread | Find similar | Unroll thread


Thread

[PATCH] brcmfmac: sdio: Increase the default timeouts a bit Sjoerd Simons <sjoerd.simons@collabora.co.uk> - 2016-01-25 11:50 +0100
  Re: [PATCH] brcmfmac: sdio: Increase the default timeouts a bit Julian Calaby <julian.calaby@gmail.com> - 2016-01-25 12:10 +0100
    Re: [PATCH] brcmfmac: sdio: Increase the default timeouts a bit Arend van Spriel <aspriel@gmail.com> - 2016-01-25 16:50 +0100
      Re: [PATCH] brcmfmac: sdio: Increase the default timeouts a bit Julian Calaby <julian.calaby@gmail.com> - 2016-01-26 00:50 +0100
        Re: [PATCH] brcmfmac: sdio: Increase the default timeouts a bit Arend van Spriel <aspriel@gmail.com> - 2016-01-26 07:40 +0100
  Re: [PATCH] brcmfmac: sdio: Increase the default timeouts a bit Arend van Spriel <aspriel@gmail.com> - 2016-01-25 16:40 +0100
    Re: [PATCH] brcmfmac: sdio: Increase the default timeouts a bit Sjoerd Simons <sjoerd.simons@collabora.co.uk> - 2016-01-25 17:00 +0100
    Re: [PATCH] brcmfmac: sdio: Increase the default timeouts a bit Doug Anderson <dianders@chromium.org> - 2016-01-25 20:30 +0100
      Re: [PATCH] brcmfmac: sdio: Increase the default timeouts a bit Arend van Spriel <arend@broadcom.com> - 2016-01-25 21:10 +0100
        Re: [PATCH] brcmfmac: sdio: Increase the default timeouts a bit Doug Anderson <dianders@chromium.org> - 2016-01-25 21:40 +0100
        Re: [PATCH] brcmfmac: sdio: Increase the default timeouts a bit Sjoerd Simons <sjoerd.simons@collabora.co.uk> - 2016-01-26 10:20 +0100

csiph-web