From: Adrian Hunter <adrian.hunter@intel.com>
To: Arend Van Spriel <arend.vanspriel@broadcom.com>,
Doug Anderson <dianders@chromium.org>
Cc: Ulf Hansson <ulf.hansson@linaro.org>,
Kalle Valo <kvalo@codeaurora.org>,
brcm80211-dev-list.pdl@broadcom.com,
"open list:ARM/Rockchip SoC..."
<linux-rockchip@lists.infradead.org>,
Double Lo <double.lo@cypress.com>,
Brian Norris <briannorris@chromium.org>,
linux-wireless <linux-wireless@vger.kernel.org>,
Naveen Gupta <naveen.gupta@cypress.com>,
Madhan Mohan R <madhanmohan.r@cypress.com>,
Matthias Kaehlcke <mka@chromium.org>,
Wright Feng <wright.feng@cypress.com>,
Chi-Hsien Lin <chi-hsien.lin@cypress.com>,
netdev <netdev@vger.kernel.org>,
brcm80211-dev-list <brcm80211-dev-list@cypress.com>,
"David S. Miller" <davem@davemloft.net>,
Franky Lin <franky.lin@broadcom.com>,
LKML <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: Fri, 7 Jun 2019 15:38:43 +0300 [thread overview]
Message-ID: <ff0e7b7a-6a58-8bec-b182-944a8b64236d@intel.com> (raw)
In-Reply-To: <16b305a7110.2764.9b12b7fc0a3841636cfb5e919b41b954@broadcom.com>
On 7/06/19 8:12 AM, Arend Van Spriel wrote:
> On June 6, 2019 11:37:22 PM Doug Anderson <dianders@chromium.org> wrote:
>>
>> In the case of dw_mmc, which I'm most familiar with, we don't have any
>> sort of automated or timed-based retuning. ...so we'll only re-tune
>> when we see the CRC error. If I'm understanding things correctly then
>> that for dw_mmc my solution and yours behave the same. That means the
>> difference is how we deal with other retuning requests, either ones
>> that come about because of an interrupt that the host controller
>> provided or because of a timer. Did I get that right?
>
> Right.
>
>> ...and I guess the reason we have to deal specially with these cases
>> is because any time that SDIO card is "sleeping" we don't want to
>> retune because it won't work. Right? NOTE: the solution that would
>> come to my mind first to solve this would be to hold the retuning for
>> the whole time that the card was sleeping and then release it once the
>> card was awake again. ...but I guess we don't truly need to do that
>> because tuning only happens as a side effect of sending a command to
>> the card and the only command we send to the card is the "wake up"
>> command. That's why your solution to hold tuning while sending the
>> "wake up" command works, right?
>
> Yup.
>
>> ---
>>
>> OK, so assuming all the above is correct, I feel like we're actually
>> solving two problems and in fact I believe we actually need both our
>> approaches to solve everything correctly. With just your patch in
>> place there's a problem because we will clobber any external retuning
>> requests that happened while we were waking up the card. AKA, imagine
>> this:
>>
>> A) brcmf_sdio_kso_control(on=True) gets called; need_retune starts as 0
>>
>> B) We call sdio_retune_hold_now()
>>
>> C) A retuning timer goes off or the SD Host controller tells us to retune
>>
>> D) We get to the end of brcmf_sdio_kso_control() and clear the "retune
>> needed" since need_retune was 0 at the start.
>>
>> ...so we dropped the retuning request from C), right?
>>
>>
>> What we truly need is:
>>
>> 1. CRC errors shouldn't trigger a retuning request when we're in
>> brcmf_sdio_kso_control()
>>
>> 2. A separate patch that holds any retuning requests while the SDIO
>> card is off. This patch _shouldn't_ do any clearing of retuning
>> requests, just defer them.
>>
>>
>> Does that make sense to you? If so, I can try to code it up...
>
> FWIW it does make sense to me. However, I am still not sure if our sdio
> hardware supports retuning. Have to track down an asic designer who can tell
> or dive into vhdl myself.
The card supports re-tuning if is handles CMD19, which it does. It is not
the card that does any tuning, only the host. The card just helps by
providing a known data pattern in response to CMD19. It can be that a card
provides good enough signals that the host should not need to re-tune. I
don't know if that can be affected by the board design though.
next prev parent reply other threads:[~2019-06-07 12:40 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
2019-06-06 21:37 ` Doug Anderson
2019-06-07 5:12 ` Arend Van Spriel
2019-06-07 12:38 ` Adrian Hunter [this message]
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=ff0e7b7a-6a58-8bec-b182-944a8b64236d@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).