From: Adrian Hunter <adrian.hunter@intel.com>
To: Douglas Anderson <dianders@chromium.org>,
Ulf Hansson <ulf.hansson@linaro.org>,
Kalle Valo <kvalo@codeaurora.org>,
Arend van Spriel <arend.vanspriel@broadcom.com>
Cc: brcm80211-dev-list.pdl@broadcom.com,
linux-rockchip@lists.infradead.org,
Double Lo <double.lo@cypress.com>,
briannorris@chromium.org, linux-wireless@vger.kernel.org,
Naveen Gupta <naveen.gupta@cypress.com>,
Madhan Mohan R <madhanmohan.r@cypress.com>,
mka@chromium.org, Wright Feng <wright.feng@cypress.com>,
Chi-Hsien Lin <chi-hsien.lin@cypress.com>,
netdev@vger.kernel.org, brcm80211-dev-list@cypress.com,
"David S. Miller" <davem@davemloft.net>,
Franky Lin <franky.lin@broadcom.com>,
linux-kernel@vger.kernel.org,
Hante Meuleman <hante.meuleman@broadcom.com>,
YueHaibing <yuehaibing@huawei.com>,
Michael Trimarchi <michael@amarulasolutions.com>
Subject: Re: [PATCH v2 3/3] brcmfmac: sdio: Disable auto-tuning around commands expected to fail
Date: Thu, 6 Jun 2019 16:59:17 +0300 [thread overview]
Message-ID: <42fc30b1-adab-7fa8-104c-cbb7855f2032@intel.com> (raw)
In-Reply-To: <20190603183740.239031-4-dianders@chromium.org>
On 3/06/19 9:37 PM, Douglas Anderson wrote:
> There are certain cases, notably when transitioning between sleep and
> active state, when Broadcom SDIO WiFi cards will produce errors on the
> SDIO bus. This is evident from the source code where you can see that
> we try commands in a loop until we either get success or we've tried
> too many times. The comment in the code reinforces this by saying
> "just one write attempt may fail"
>
> Unfortunately these failures sometimes end up causing an "-EILSEQ"
> back to the core which triggers a retuning of the SDIO card and that
> blocks all traffic to the card until it's done.
>
> Let's disable retuning around the commands we expect might fail.
It seems to me that re-tuning needs to be prevented before the
first access otherwise it might be attempted there, and it needs
to continue to be prevented during the transition when it might
reasonably be expected to fail.
What about something along these lines:
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c
index 4e15ea57d4f5..d932780ef56e 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c
@@ -664,9 +664,18 @@ brcmf_sdio_kso_control(struct brcmf_sdio *bus, bool on)
int err = 0;
int err_cnt = 0;
int try_cnt = 0;
+ int need_retune = 0;
+ bool retune_release = false;
brcmf_dbg(TRACE, "Enter: on=%d\n", on);
+ /* Cannot re-tune if device is asleep */
+ if (on) {
+ need_retune = sdio_retune_get_needed(bus->sdiodev->func1); // TODO: host->can_retune ? host->need_retune : 0
+ sdio_retune_hold_now(bus->sdiodev->func1); // TODO: add sdio_retune_hold_now()
+ retune_release = true;
+ }
+
wr_val = (on << SBSDIO_FUNC1_SLEEPCSR_KSO_SHIFT);
/* 1st KSO write goes to AOS wake up core if device is asleep */
brcmf_sdiod_writeb(bus->sdiodev, SBSDIO_FUNC1_SLEEPCSR, wr_val, &err);
@@ -711,8 +720,16 @@ brcmf_sdio_kso_control(struct brcmf_sdio *bus, bool on)
err_cnt = 0;
}
/* bail out upon subsequent access errors */
- if (err && (err_cnt++ > BRCMF_SDIO_MAX_ACCESS_ERRORS))
- break;
+ if (err && (err_cnt++ > BRCMF_SDIO_MAX_ACCESS_ERRORS)) {
+ if (!retune_release)
+ break;
+ /*
+ * Allow one more retry with re-tuning released in case
+ * it helps.
+ */
+ sdio_retune_release(bus->sdiodev->func1);
+ retune_release = false;
+ }
udelay(KSO_WAIT_US);
brcmf_sdiod_writeb(bus->sdiodev, SBSDIO_FUNC1_SLEEPCSR, wr_val,
@@ -727,6 +744,18 @@ brcmf_sdio_kso_control(struct brcmf_sdio *bus, bool on)
if (try_cnt > MAX_KSO_ATTEMPTS)
brcmf_err("max tries: rd_val=0x%x err=%d\n", rd_val, err);
+ if (retune_release) {
+ /*
+ * CRC errors are not unexpected during the transition but they
+ * also trigger re-tuning. Clear that here to avoid an
+ * unnecessary re-tune if it wasn't already triggered to start
+ * with.
+ */
+ if (!need_retune)
+ sdio_retune_clear_needed(bus->sdiodev->func1); // TODO: host->need_retune = 0
+ sdio_retune_release(bus->sdiodev->func1); // TODO: add sdio_retune_release()
+ }
+
return err;
}
next prev parent reply other threads:[~2019-06-06 14:00 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-06-03 18:37 [PATCH v2 0/3] brcmfmac: sdio: Deal better w/ transmission errors waking from idle Douglas Anderson
2019-06-03 18:37 ` [PATCH v2 1/3] Revert "brcmfmac: disable command decode in sdio_aos" Douglas Anderson
2019-06-03 18:37 ` [PATCH v2 2/3] mmc: core: API for temporarily disabling auto-retuning due to errors Douglas Anderson
2019-06-05 7:54 ` Arend Van Spriel
2019-06-05 22:51 ` Doug Anderson
2019-06-03 18:37 ` [PATCH v2 3/3] brcmfmac: sdio: Disable auto-tuning around commands expected to fail Douglas Anderson
2019-06-06 13:59 ` Adrian Hunter [this message]
2019-06-06 21:37 ` Doug Anderson
2019-06-07 5:12 ` Arend Van Spriel
2019-06-07 12:38 ` Adrian Hunter
2019-06-07 13:32 ` Arend Van Spriel
2019-06-07 18:06 ` Doug Anderson
2019-06-07 18:56 ` Arend Van Spriel
2019-06-07 12:28 ` Adrian Hunter
2019-06-07 18:00 ` Doug Anderson
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=42fc30b1-adab-7fa8-104c-cbb7855f2032@intel.com \
--to=adrian.hunter@intel.com \
--cc=arend.vanspriel@broadcom.com \
--cc=brcm80211-dev-list.pdl@broadcom.com \
--cc=brcm80211-dev-list@cypress.com \
--cc=briannorris@chromium.org \
--cc=chi-hsien.lin@cypress.com \
--cc=davem@davemloft.net \
--cc=dianders@chromium.org \
--cc=double.lo@cypress.com \
--cc=franky.lin@broadcom.com \
--cc=hante.meuleman@broadcom.com \
--cc=kvalo@codeaurora.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-rockchip@lists.infradead.org \
--cc=linux-wireless@vger.kernel.org \
--cc=madhanmohan.r@cypress.com \
--cc=michael@amarulasolutions.com \
--cc=mka@chromium.org \
--cc=naveen.gupta@cypress.com \
--cc=netdev@vger.kernel.org \
--cc=ulf.hansson@linaro.org \
--cc=wright.feng@cypress.com \
--cc=yuehaibing@huawei.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).