[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CACRpkdYkk+W98RoCCwRWXyF+_1_H9gujxHLCPnqtPMn401fZvg@mail.gmail.com>
Date: Tue, 30 Aug 2011 09:15:38 +0200
From: Linus Walleij <linus.walleij@...aro.org>
To: NamJae Jeon <linkinjeon@...il.com>
Cc: linux-mmc@...r.kernel.org, linux-kernel@...r.kernel.org,
Chris Ball <cjb@...top.org>,
Kyungmin Park <kmpark@...radead.org>,
Sebastian Rasmussen <Sebastian.Rasmussen@...ricsson.com>,
Ulf Hansson <Ulf.Hansson@...ricsson.com>
Subject: Re: RFC : mmc : Use wait_for_completion_timeout() instead of
wait_for_completion in case of multiple write blocks.
On Thu, Aug 25, 2011 at 6:44 AM, NamJae Jeon <linkinjeon@...il.com> wrote:
> If card is infinitely holding pull down busy line(data 0) while
> writing multiple blocks, write will be blocked in
> mmc_wait_for_req_done().
> I suggest to use wait_for_completion_timeout instread of
> wait_for_completion like the below code.
>
> How do you think about my suggestion ?
Since this is a hardware lock-up it is up to the host driver to
timeout and return an error to the framework.
For example only the host driver have information on the
clock speed on the host controller and other information such
as request size that can be used to set a suitable timeout waiting
for the request to complete.
If you just grep for timeout_ns in drivers/mmc/host you can
see several drivers using the card-supplied timeout_ns for
handing the timeout properly given local clocking
constraints etc.
Often host controllers can take the number
of clock cycles until timeout as a parameter, and only
the host controller can calculate this number.
See for example in mmci_start_data()
in mmci.c.
So I seriously think you need to look closer at the problematic
host driver if this is a problem to you, e.g. rewrite it to use
wait_for_completion_timeout() there.
Yours,
Linus Walleij
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists