Tested-by: Steve Rae
(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 platform-dependent. The udelay(
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 wi
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
> ---
> drivers/mmc
On 19/06/14 19:43, Andy Fleming wrote:
On Thu, Jun 12, 2014 at 4:41 AM, 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.
[ snipped patch ]
On Thu, Jun 12, 2014 at 4:41 AM, 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
> ---
> drivers/mmc/sdhci
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
---
drivers/mmc/sdhci.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff
6 matches
Mail list logo