In case of SDHCI_TIMEOUT_CONTROL write only 4 bits and not the
whole byte to avoid touching other unrelated bits in the i.MX6
SYS_CTRL register. E.g. IPP_RST_N shouldn't be touched accidently.
Signed-off-by: Dirk Behme
---
drivers/mmc/host/sdhci-esdhc-imx.c | 12
1 file changed, 12
On Tue, Jul 16, 2013 at 03:11:47AM +, Zhang Haijun-B42677 wrote:
> Hi, Anton
>
> You mean get voltage support from DTS?
> Or get voltage both from DTS and host capacity register?
The logic might be that you first check device-tree, if it specifies
voltage ranges, assume that DTS knows better,
Hi, Anton
You mean get voltage support from DTS?
Or get voltage both from DTS and host capacity register?
Thanks.
Regards
Haijun.
> -Original Message-
> From: linux-mmc-ow...@vger.kernel.org [mailto:linux-mmc-
> ow...@vger.kernel.org] On Behalf Of Anton Vorontsov
> Sent: Saturday, July
Hi Doug,
I think these patch-set didn't base on latest mmc-next.
If you can rebase on latest mmc-next, it's helpful to me for testing.
Best Regards,
Jaehoon Chung
On 07/11/2013 12:42 AM, Doug Anderson wrote:
> If the WAKEUP_INT is asserted at wakeup and not cleared, we'll end up
> looping around
On Wed, Jul 10, 2013 at 11:09:12AM +0900, Simon Horman wrote:
> From: Guennadi Liakhovetski
>
> On platforms with no support for the shdma dmaengine driver build is
> currently failing with
>
> drivers/built-in.o: In function `sh_mobile_sdhi_probe':
> drivers/mmc/host/sh_mobile_sdhi.c:170: undef
I don't understand all the implications...but my gut feeling is this
change is necessary. Can someone please explain why I'm wrong?
(key here is to use "err || start_err" - same logic as a few lines
above to call mmc_post_req(...-EINVAL))
- if (err)
- host->areq = NULL;
-
From: Dinh Nguyen
Add bindings for SD/MMC for SOCFPGA.
Add "syscon" to the "altr,sys-mgr" binding.
Signed-off-by: Dinh Nguyen
Reviewed-by: Pavel Machek
Acked-by: Jaehoon Chung
CC: Arnd Bergmann
CC: Olof Johansson
Cc: Grant Likely
Cc: Rob Herring
Cc: Chris Ball
Cc: devicetree-disc...@list
On Thu, July 11, 2013, Doug Anderson wrote:
> On some devices (like exynos5420) the dw_mmc controller may be in a
> strange state after we wake up from sleep. Add callbacks to allow for
> dealing with these quirks. We use the "_noirq" versions of the
> callbacks since in the case of exynos5420 th
On Thu, July 11, 2013, Doug Anderson wrote:
> Seungwon,
>
> On Wed, Jul 10, 2013 at 7:54 AM, Seungwon Jeon wrote:
> > On Wed, July 10, 2013, Doug Anderson wrote:
> >> If the WAKEUP_INT is asserted at wakeup and not cleared, we'll end up
> >> looping around forever. This has been seen to happen o
