[PATCH] sdhci: Specific quirk vor VIA SDHCI controller in VX855ES

[PATCH] sdhci: Specific quirk vor VIA SDHCI controller in VX855ES

[Harald Welte]

The SDHCI controller found in the VX855ES requires 10ms
delay between applying power and applying clock.

This issue has been discovered and documented by the OLPC XO1.5 team.

Signed-off-by: Harald Welte <HaraldWelte@viatech.com>
---
 drivers/mmc/host/sdhci-pci.c |   20 ++++++++++++++++++++
 drivers/mmc/host/sdhci.c     |    7 +++++++
 drivers/mmc/host/sdhci.h     |    2 ++
 3 files changed, 29 insertions(+), 0 deletions(-)

diff --git a/drivers/mmc/host/sdhci-pci.c b/drivers/mmc/host/sdhci-pci.c
index 65be279..2f15cc1 100644
--- a/drivers/mmc/host/sdhci-pci.c
+++ b/drivers/mmc/host/sdhci-pci.c
@@ -284,6 +284,18 @@ static const struct sdhci_pci_fixes sdhci_jmicron = {
 	.resume		= jmicron_resume,
 };
 
+static int via_probe(struct sdhci_pci_chip *chip)
+{
+	if (chip->pdev->revision == 0x10)
+		chip->quirks |= SDHCI_QUIRK_DELAY_AFTER_POWER;
+
+	return 0;
+}
+
+static const struct sdhci_pci_fixes sdhci_via = {
+	.probe		= via_probe,
+};
+
 static const struct pci_device_id pci_ids[] __devinitdata = {
 	{
 		.vendor		= PCI_VENDOR_ID_RICOH,
@@ -349,6 +361,14 @@ static const struct pci_device_id pci_ids[] __devinitdata = {
 		.driver_data	= (kernel_ulong_t)&sdhci_jmicron,
 	},
 
+	{
+		.vendor		= PCI_VENDOR_ID_VIA,
+		.device		= 0x95d0,
+		.subvendor	= PCI_ANY_ID,
+		.subdevice	= PCI_ANY_ID,
+		.driver_data	= (kernel_ulong_t)&sdhci_via,
+	},
+
 	{	/* Generic SD host controller */
 		PCI_DEVICE_CLASS((PCI_CLASS_SYSTEM_SDHCI << 8), 0xFFFF00)
 	},
diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
index 35789c6..62e2a63 100644
--- a/drivers/mmc/host/sdhci.c
+++ b/drivers/mmc/host/sdhci.c
@@ -1057,6 +1057,13 @@ static void sdhci_set_power(struct sdhci_host *host, unsigned short power)
 	pwr |= SDHCI_POWER_ON;
 
 	sdhci_writeb(host, pwr, SDHCI_POWER_CONTROL);
+
+	/*
+	 * Some controllers need an extra 10ms delay of 10ms before they
+	 * can apply clock after applying power
+	 */
+	if ((host->quirks & SDHCI_QUIRK_DELAY_AFTER_POWER))
+		mdelay(10);
 }
 
 /*****************************************************************************\
diff --git a/drivers/mmc/host/sdhci.h b/drivers/mmc/host/sdhci.h
index 2de0834..9832a5f 100644
--- a/drivers/mmc/host/sdhci.h
+++ b/drivers/mmc/host/sdhci.h
@@ -226,6 +226,8 @@ struct sdhci_host {
 #define SDHCI_QUIRK_RESTORE_IRQS_AFTER_RESET		(1<<19)
 /* Controller has to be forced to use block size of 2048 bytes */
 #define SDHCI_QUIRK_FORCE_BLK_SZ_2048			(1<<20)
+/* Controller needs 10ms delay between applying power and clock */
+#define SDHCI_QUIRK_DELAY_AFTER_POWER			(1<<21)
 
 	int			irq;		/* Device IRQ */
 	void __iomem *		ioaddr;		/* Mapped address */
-- 
1.6.3.1

Re: [PATCH] sdhci: Specific quirk vor VIA SDHCI controller in VX855ES

[Pierre Ossman]

[-- Attachment #1: Type: text/plain, Size: 713 bytes --]

On Thu, 18 Jun 2009 16:53:38 +0200
Harald Welte <HaraldWelte@viatech.com> wrote:

> The SDHCI controller found in the VX855ES requires 10ms
> delay between applying power and applying clock.
> 
> This issue has been discovered and documented by the OLPC XO1.5 team.
> 
> Signed-off-by: Harald Welte <HaraldWelte@viatech.com>
> ---

Does this block have a name? Something nicer than 0x95d0 in the id list
would be nice.

(Same thing goes for the via-sdmmc driver btw).

Rgds
-- 
     -- 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.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [PATCH] sdhci: Specific quirk vor VIA SDHCI controller in VX855ES

[Harald Welte]

Hi!

On Fri, Jun 19, 2009 at 09:33:14PM +0200, Pierre Ossman wrote:

> Does this block have a name? Something nicer than 0x95d0 in the id list
> would be nice.

Unfortunately no.  We really have a big mess with those integrated chipsets
that have something like 15 PCI devices inside one component.  We cannot call
all of them 'VX855'. or 'VX800', as that would clash.  Naming things
'PCI_DEVICE_VIA_VX800_SDHCI' is also not really correct, since the same
block appearas in other integrated chipsets, too.

As for VIA's documentation, every block is called something like D13F3 (pci
device 13 function 3), which doesn't really sound all that much better than
just putting a 0x95d0 there.

To make things even furter complicated, some VIA Docs refer to the SDHCI
controller as 'SDIO controller' and the via-sdmmc as 'SD card controller'...

-- 
- Harald Welte <HaraldWelte@viatech.com>	    http://linux.via.com.tw/
============================================================================
VIA Free and Open Source Software Liaison

Re: [PATCH] sdhci: Specific quirk vor VIA SDHCI controller in VX855ES

[Pierre Ossman]

[-- Attachment #1: Type: text/plain, Size: 1304 bytes --]

On Sat, 20 Jun 2009 00:28:28 +0200
Harald Welte <HaraldWelte@viatech.com> wrote:

> Hi!
> 
> On Fri, Jun 19, 2009 at 09:33:14PM +0200, Pierre Ossman wrote:
> 
> > Does this block have a name? Something nicer than 0x95d0 in the id list
> > would be nice.
> 
> Unfortunately no.  We really have a big mess with those integrated chipsets
> that have something like 15 PCI devices inside one component.  We cannot call
> all of them 'VX855'. or 'VX800', as that would clash.  Naming things
> 'PCI_DEVICE_VIA_VX800_SDHCI' is also not really correct, since the same
> block appearas in other integrated chipsets, too.
> 
> As for VIA's documentation, every block is called something like D13F3 (pci
> device 13 function 3), which doesn't really sound all that much better than
> just putting a 0x95d0 there.
> 
> To make things even furter complicated, some VIA Docs refer to the SDHCI
> controller as 'SDIO controller' and the via-sdmmc as 'SD card controller'...
> 

Sounds like you guys need an official code name department. :)

I've queued up the patch.

-- 
     -- 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.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]