From: Christopher Freeman <cfreeman@nvidia.com>
To: Robert Foss <robert.foss@collabora.com>
Cc: Adrian Hunter <adrian.hunter@intel.com>,
ulf.hansson@linaro.org, linux-mmc@vger.kernel.org,
linux-kernel@vger.kernel.org,
Andrew Bresticker <abrestic@chromium.org>,
Kevin Cernekee <cernekee@chromium.org>,
Benson Leung <bleung@chromium.org>
Subject: Re: [PACTH v3] mmc: sdhci: Do not allow tuning procedure to be interrupted
Date: Wed, 17 Aug 2016 15:12:42 -0700 [thread overview]
Message-ID: <20160817221146.GA9714@cfreeman-dt> (raw)
In-Reply-To: <0c1a3043-9ed1-9d01-0f07-231d6ece874f@collabora.com>
On 08-17 01:31 PM, Robert Foss wrote:
>
>
> On 2016-08-17 06:47 AM, Adrian Hunter wrote:
> >On 17/08/16 00:25, robert.foss@collabora.com wrote:
> >>From: Christopher Freeman <cfreeman@nvidia.com>
> >>
> >>wait_event_interruptible_timeout() will return early if the blocked
> >>process receives a signal, causing the driver to abort the tuning
> >>procedure and possibly leaving the controller in a bad state. Since the
> >>tuning command is expected to complete quickly (<50ms) and we've set a
> >>timeout, use wait_event_timeout() instead.
> >>
> >>Signed-off-by: Christopher Freeman <cfreeman@nvidia.com>
> >>Tested-by: Robert Foss <robert.foss@collabora.com>
> >>Signed-off-by: Robert Foss <robert.foss@collabora.com>
> >>Reviewed-by: Benson Leung <bleung@chromium.org>
> >
> >The mmc block queues are kernel threads which I would expect ignore signals,
> >so I am curious how you hit this?
>
> The issue was discovered on (tegra2?) hardware that is sensitive to
> being interrupted during tuning and having the controller left in a
> sensitive state.
>
> @Christopher Freeman: Maybe you can provide us with some additional details?
>
It was found with Tegra 210. The signalling was an issue because tuning was
kicked off from an ioctl to the wifi device on the controller.
FWIW, this issue was particular to the wifi driver (bcmdhd) and the android
tree. It in part depends on the way the wifi driver is able to reset the
sdio device via a routine that's not present in mainline: sdio_reset_comm.
I believe the wifi driver would power on the wifi chip and trigger tuning in
the aforementioned ioctl. Process that sent the ioctl was some network or wifi
manager service on Android.
Let me know if you would like any more details.
> >
> >In any case:
> >
> >Acked-by: Adrian Hunter <adrian.hunter@intel.com>
> >
next prev parent reply other threads:[~2016-08-17 22:12 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-08-16 21:25 [PACTH v3] mmc: sdhci: Do not allow tuning procedure to be interrupted robert.foss
2016-08-17 10:47 ` Adrian Hunter
2016-08-17 17:31 ` Robert Foss
2016-08-17 22:12 ` Christopher Freeman [this message]
2016-08-18 13:46 ` Adrian Hunter
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=20160817221146.GA9714@cfreeman-dt \
--to=cfreeman@nvidia.com \
--cc=abrestic@chromium.org \
--cc=adrian.hunter@intel.com \
--cc=bleung@chromium.org \
--cc=cernekee@chromium.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mmc@vger.kernel.org \
--cc=robert.foss@collabora.com \
--cc=ulf.hansson@linaro.org \
/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