Tested-by: Steve Rae s...@broadcom.com
(does resolve the issue on our board!)
On 14-06-27 02:37 AM, Pantelis Antoniou wrote:
Hi Eli,
On Jun 12, 2014, at 12:41 PM, Eli Billauer wrote:
The current wait loop just reads the status 1 times, which makes the
actual timeout period
On Fri, Jun 27, 2014 at 4:37 AM, Pantelis Antoniou
pantelis.anton...@gmail.com wrote:
Hi Eli,
On Jun 12, 2014, at 12:41 PM, Eli Billauer wrote:
The current wait loop just reads the status 1 times, which makes the
actual timeout period platform-dependent. The udelay() call within the
Hi Eli,
On Jun 12, 2014, at 12:41 PM, Eli Billauer wrote:
The current wait loop just reads the status 1 times, which makes the
actual timeout period platform-dependent. The udelay() call within the loop
makes the new timeout ~100 ms.
Signed-off-by: Eli Billauer eli.billa...@gmail.com
On Thu, Jun 12, 2014 at 4:41 AM, Eli Billauer eli.billa...@gmail.com wrote:
The current wait loop just reads the status 1 times, which makes the
actual timeout period platform-dependent. The udelay() call within the loop
makes the new timeout ~100 ms.
Signed-off-by: Eli Billauer
On 19/06/14 19:43, Andy Fleming wrote:
On Thu, Jun 12, 2014 at 4:41 AM, Eli Billauereli.billa...@gmail.com wrote:
The current wait loop just reads the status 1 times, which makes the
actual timeout period platform-dependent. The udelay() call within the loop
makes the new timeout ~100
The current wait loop just reads the status 1 times, which makes the
actual timeout period platform-dependent. The udelay() call within the loop
makes the new timeout ~100 ms.
Signed-off-by: Eli Billauer eli.billa...@gmail.com
---
drivers/mmc/sdhci.c |1 +
1 files changed, 1
6 matches
Mail list logo