Re: [PATCHv2 1/2] mmc: omap_hsmmc: convert from IP timer to hrtimer

S, Venkatraman
2012-09-10T04:33:23Z

On Sat, Sep 8, 2012 at 3:29 AM, Kevin Hilman
<khilman@deeprootsystems.com> wrote:
> Venkatraman S <svenkatr@ti.com> writes:
>
>> omap hsmmc controller IP has a built in timer that can be programmed to
>> guard against unresponsive operations. But its range is very narrow,
>> and the maximum countable time is a few seconds.
>>
>> Card maintenance operations like BKOPS and MMC_ERASE and long
>> stream writes like packed command require timers of order of
>> several minutes, much beyond the capability of the IP timer.
>> So get rid of using the IP timer entirely and use kernel's hrtimer
>> functionality for guarding the device operations.
>> As part of this change, a workaround that disabled timeouts for
>> MMC_ERASE command is removed, and the arbitary timing of 100ms
>> is used only when the timeout is not explicitly specified by core.
>>
>> A trivial change to get rid of unnecessary dealiasing of host->data
>> in omap_hsmmc_do_irq is also included.
>>
>> Signed-off-by: Venkatraman S <svenkatr@ti.com>
>
> Dumb question: if the timers needed are on the order of minutes, why do
> you need to use high-resolution timers? I'm guessing the normal
> kernel-internal timers should suffice here (see <linux/timer.h,
> init_timer().)
>
Both sub ms and long duration timers are needed, based on the type of operation.
The eMMC standard has evolved to define new commands which require
such long duration
operations. The short ("control") commands do need high precision.

> Also, if they're on the order of minutes, I assume the actual firing
> doesn't have to be precise, so deferrable timers can probably be used
> (and thus help PM by coalescing wakeup events.)
>
> If my assumptions are true, it might be worth considering using the
> normal timers, and use init_timer_deferrable().
>
I'll certainly look into this. One way is to use the IP timer for
short commands and
deferrable timers for long ones - but I reckon it would be messy.

I've actually put this patch on hold - as someone pointed out to me that
this violates some sections of eMMC spec.

> Kevin