[BUG/RFC] SDHCI_QUIRK_NO_MULTIBLOCK for i.MX35/25

2013-11-15 Thread Steffen Trumtrar
Hi! 1 Actual Use-Case = I have a SDIO card with a Marvell 8787, that works fine on an i.MX53 with the drivers/net/wireless/mwifiex/sdio.c driver. On an i.MX35 however the loading of the firmware errors out on the very first single-block transfer with 1024 bytes payload.

Re: [PATCH] mmc: dw_mmc: Add hardware lock error (HLE) to the CMD error flag

2013-11-15 Thread Jaehoon Chung
Dear, Alim, Well, I'm not sure that this patch is correct. But as you mentioned, we need to decide how control the HLE. I will check the HLE on this weekend. Thanks for your effort. Best Regards, Jaehoon Chung On 11/12/2013 01:12 PM, Alim Akhtar wrote: Hi Seungwon/ Jaehoon, I can see there

RE: [PATCH] mmc: dw_mmc: Add hardware lock error (HLE) to the CMD error flag

2013-11-15 Thread Seungwon Jeon
On Fri, November 15, 2013, Jaehoon Chung wrote: Dear, Alim, Well, I'm not sure that this patch is correct. But as you mentioned, we need to decide how control the HLE. I will check the HLE on this weekend. Thanks for your effort. Thank you for remind. HLE should be cleared at least

[PATCH 0/3] Orion irqchip and Kirkwood SDIO

2013-11-15 Thread Sebastian Hesselbarth
This patch set tries to deal with a minor irq issue seen on Marvell Kirkwood SoCs with irqchip/irq-orion and mvsdio drivers. In contrast to non-DT irq handling, irqchip driver does handle irqs a little bit different. First of all, it reads irq cause register once and works through all bits set

[PATCH 2/3] mmc: mvsdio: workaround for spurious irqs

2013-11-15 Thread Sebastian Hesselbarth
SDIO controllers found on Marvell Kirkwood SoCs seem to cause a late, spurious irq although all interrupts have been disabled. This irq doesn't do any harm, neither to HW nor driver. To avoid some unexpected irq warning later, we workaround above issue by bailing out of irq handler early, if we

[PATCH 3/3] mmc: mvsdio: silence card detect notice

2013-11-15 Thread Sebastian Hesselbarth
mvsdio reports method of card detection with dev_notice, while for removable cards it may be sane, for non-removable cards it is not. Also, as the user cannot do anything about it, silence the message by reducing it from dev_notice to dev_dbg. Signed-off-by: Sebastian Hesselbarth

Re: [PATCH 16/51] DMA-API: ppc: vio.c: replace dma_set_mask()+dma_set_coherent_mask() with new helper

2013-11-15 Thread Cedric Le Goater
Hi, On 09/19/2013 11:41 PM, Russell King wrote: Replace the following sequence: dma_set_mask(dev, mask); dma_set_coherent_mask(dev, mask); with a call to the new helper dma_set_mask_and_coherent(). Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk ---

[PATCH] mmc: disable UHS on broadcom sdhci

2013-11-15 Thread Grant Grundler
From: Stephen Hurd sh...@broadcom.com Add two new quirks needed by BCM57785 card reader: SDHCI_QUIRK2_BROKEN_UHS: Disables all UHS modes. SDHCI_QUIRK2_BCM57785_CR: Bit twiddles some Broadcom-specific registers and supresses an error about the 64k bar0. Add sdhci_pci_fixes for: o the

[RFC 04/23] mmc: omap: raw read and write endian fix

2013-11-15 Thread Taras Kondratiuk
From: Victor Kamensky victor.kamen...@linaro.org All OMAP IP blocks expect LE data, but CPU may operate in BE mode. Need to use endian neutral functions to read/write h/w registers. I.e instead of __raw_read[lw] and __raw_write[lw] functions code need to use read[lw]_relaxed and write[lw]_relaxed

Re: [PATCH] mmc: disable UHS on broadcom sdhci

2013-11-15 Thread Olof Johansson
Hi, On Fri, Nov 15, 2013 at 03:56:22PM -0800, Grant Grundler wrote: From: Stephen Hurd sh...@broadcom.com Add two new quirks needed by BCM57785 card reader: SDHCI_QUIRK2_BROKEN_UHS: Disables all UHS modes. This seems appropriate. You _could_ use SDHCI_QUIRK_MISSING_CAPS and hardcode