Re: RFC : mmc : Use wait_for_completion_timeout() instead ofwait_for_completion in case of multiple write blocks.

From: NamJae Jeon
Date: Fri Sep 02 2011 - 01:58:17 EST


2011/8/30 Linus Walleij <linus.walleij@xxxxxxxxxx>:
> On Thu, Aug 25, 2011 at 6:44 AM, NamJae Jeon <linkinjeon@xxxxxxxxx> 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
>

We should consider DMA situation. As I know, host controller can not
rise timeout interrupt in write not read in DMA status. host
controller can just know whether card is finish to program to use busy
line. If unstable card is holding busy line while writing using DMA,
hang problem will happen by wait_for_completion.
so I think that mmc driver need some exception to avoid this problem.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/