Hi,
We have observed something that could be problematic in the way Davinci MMC Linux driver sets data timeout requested by Linux MMC core driver.
To give some context, we are working on an Omap-L138 based board on which we run Linux 3.1-rc4. On this system, we use an SDCard that has very high read/write busy time. For this reason, we have modified mmc_set_data_timeout() in drivers/mmc/core/core.c by adjusting data->timeout_ns/data->timeout_clks to obtain what we call software timeout. This modification has the following effects:
- Davinci MMC driver computes this software timeout as data->timeout_clks + convert_to_clks(data->timeout_ns) (see mmc_davinci_prepare_data() in drivers/mmc/host/davinci_mmc.c)
- this software timeout cannot be more than 0xFFFF
- this software timeout is then write to DAVINCI_MMCTOD register
As its is implemented in Davinci MMC driver, value in DAVINCI_MMCTOD only constitutes the lower bits of what we call the hardware timeout. The upper bits of this hardware timeout are found in TOD_25_16 bits of DAVINCI_MMCTOR register. Currently, TOD_25_16 bits contains fixed value 0x1F. This means that 0x1F FFFF is the maximum timeout that we can obtain with Davinci MMC driver code.
The problem is that hardware timeout (set in MMC controller by Davinci MMC driver) may not be equal to requested software timeout (set in Linux MMC core code, ie data->timeout_ns and data->timeout_clks).
In my opinion, this is really problematic especially when hardware timeout ends up being set less than requested software timeout. This situation may only be tolerate if the software timeout is bigger than the max possible hardware timeout which is 0x3FF FFFF (and not 0x1F FFFF as forced by Davinci MMC driver). To obtain the requested software timeout, the Davinci MMC driver must adjust both the value in DAVINCI_MMCTOD and in TOD_25_16 bits of DAVINCI_MMCTOR.
This situation is also present in Davinci MMC driver of Linux kernel 3.18.
What do you think about this observation? Do I miss something?
Regards,
Fabrice