This has been sitting around unloved for way too long..
The Marvell CaFe chip's SD implementation chokes during card insertion
if one attempts to set the voltage and power up in the same
SDHCI_POWER_CONTROL register write. This adds a quirk that does
that particular dance in two steps.
It also adds an entry to pci_ids.h for the CaFe chip's SD device.
Signed-off-by: Andres Salomon <[email protected]>
---
drivers/mmc/host/sdhci.c | 18 ++++++++++++++++++
include/linux/pci_ids.h | 1 +
2 files changed, 19 insertions(+), 0 deletions(-)
diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
index 07c2048..5b74c8c 100644
--- a/drivers/mmc/host/sdhci.c
+++ b/drivers/mmc/host/sdhci.c
@@ -55,6 +55,8 @@ static unsigned int debug_quirks = 0;
#define SDHCI_QUIRK_32BIT_DMA_SIZE (1<<7)
/* Controller needs to be reset after each request to stay stable */
#define SDHCI_QUIRK_RESET_AFTER_REQUEST (1<<8)
+/* Controller needs voltage and power writes to happen separately */
+#define SDHCI_QUIRK_NO_SIMULT_VDD_AND_POWER (1<<9)
static const struct pci_device_id pci_ids[] __devinitdata = {
{
@@ -128,6 +130,14 @@ static const struct pci_device_id pci_ids[] __devinitdata = {
},
{
+ .vendor = PCI_VENDOR_ID_MARVELL,
+ .device = PCI_DEVICE_ID_MARVELL_CAFE_SD,
+ .subvendor = PCI_ANY_ID,
+ .subdevice = PCI_ANY_ID,
+ .driver_data = SDHCI_QUIRK_NO_SIMULT_VDD_AND_POWER,
+ },
+
+ {
.vendor = PCI_VENDOR_ID_JMICRON,
.device = PCI_DEVICE_ID_JMICRON_JMB38X_SD,
.subvendor = PCI_ANY_ID,
@@ -774,6 +784,14 @@ static void sdhci_set_power(struct sdhci_host *host, unsigned short power)
BUG();
}
+ /*
+ * At least the CaFe chip gets confused if we set the voltage
+ * and set turn on power at the same time, so set the voltage first.
+ */
+ if ((host->chip->quirks & SDHCI_QUIRK_NO_SIMULT_VDD_AND_POWER))
+ writeb(pwr & ~SDHCI_POWER_ON,
+ host->ioaddr + SDHCI_POWER_CONTROL);
+
writeb(pwr, host->ioaddr + SDHCI_POWER_CONTROL);
out:
diff --git a/include/linux/pci_ids.h b/include/linux/pci_ids.h
index eafc9d6..6595382 100644
--- a/include/linux/pci_ids.h
+++ b/include/linux/pci_ids.h
@@ -1520,6 +1520,7 @@
#define PCI_DEVICE_ID_MARVELL_GT64260 0x6430
#define PCI_DEVICE_ID_MARVELL_MV64360 0x6460
#define PCI_DEVICE_ID_MARVELL_MV64460 0x6480
+#define PCI_DEVICE_ID_MARVELL_CAFE_SD 0x4101
#define PCI_VENDOR_ID_V3 0x11b0
#define PCI_DEVICE_ID_V3_V960 0x0001
--
1.5.5.3
On Sat, 21 Jun 2008 21:15:16 -0400
Andres Salomon <[email protected]> wrote:
> This has been sitting around unloved for way too long..
>
> The Marvell CaFe chip's SD implementation chokes during card insertion
> if one attempts to set the voltage and power up in the same
> SDHCI_POWER_CONTROL register write. This adds a quirk that does
> that particular dance in two steps.
>
> It also adds an entry to pci_ids.h for the CaFe chip's SD device.
>
> Signed-off-by: Andres Salomon <[email protected]>
> ---
Looks ok, but please try to diff against my -next branch. The sdhci
driver has been split up into a core and PCI part.
> @@ -774,6 +784,14 @@ static void sdhci_set_power(struct sdhci_host *host, unsigned short power)
> BUG();
> }
>
> + /*
> + * At least the CaFe chip gets confused if we set the voltage
> + * and set turn on power at the same time, so set the voltage first.
> + */
This comment should probably say "Marvell controller" or something like
that. Few know of the CaFE name.
--
-- Pierre Ossman
WARNING: This correspondence is being monitored by the
Swedish government. Make sure your server uses encryption
for SMTP traffic and consider using PGP for end-to-end
encryption.
On Sat, Jun 28, 2008 at 1:59 AM, Pierre Ossman <[email protected]> wrote:
> This comment should probably say "Marvell controller" or something like
> that. Few know of the CaFE name.
Marvell named CaFE the 88ALP01:
http://www.marvell.com/products/pcconn/88ALP01.jsp
But the driver for the webcam part of the chip names it both cafe and 88ALP01:
drivers/media/video/cafe_ccic.c
FWIW, CaFE is easier to say and remember :)
Joel
On Sun, 29 Jun 2008 02:32:38 +0930
"Joel Stanley" <[email protected]> wrote:
[...]
>
> FWIW, CaFE is easier to say and remember :)
>
> Joel
Indeed, and that's why I've been using it. I have yet to hear anyone
(who isn't reading off the data sheet) call it the"88alp01".