My HP 2510p has an SD card slot and a few days ago I bought one to be able
to add support for SD cards in the Debian Installer.

Whilst playing with it, I found the following messages in my logs during
suspend. At the time the card was inserted, but nothing on it was mounted.

There also seems to be a problem while resuming, especially:
mmc mmc0:8879: parent mmc0 should not be sleeping
More context at the bottom of the mail.

From lspci -vvv:
02:06.2 SD Host controller: Ricoh Co Ltd R5C822 SD/SDIO/MMC/MS/MSPro Host Adapter (rev 21)
        Subsystem: Hewlett-Packard Company Device 30c9
        Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
        Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
        Latency: 64, Cache Line Size: 64 bytes
        Interrupt: pin C routed to IRQ 20
        Region 0: Memory at e0102000 (32-bit, non-prefetchable) [size=256]
        Capabilities: <access denied>
        Kernel driver in use: sdhci-pci
        Kernel modules: sdhci-pci

02:06.3 System peripheral: Ricoh Co Ltd R5C843 MMC Host Controller (rev ff) (prog-if ff)
        !!! Unknown header type 7f
        Kernel driver in use: ricoh-mmc
        Kernel modules: ricoh_mmc

Cheers,
FJP

Messages from kern.log during suspend:
Sep 28 23:12:39 aragorn kernel: Suspending console(s) (use no_console_suspend to debug)
Sep 28 23:12:39 aragorn kernel: pci 0000:00:02.0: PCI INT A disabled
Sep 28 23:12:39 aragorn kernel: sd 0:0:0:0: [sda] Synchronizing SCSI cache
Sep 28 23:12:39 aragorn kernel: sd 0:0:0:0: [sda] Stopping disk
Sep 28 23:12:39 aragorn kernel: ACPI handle has no context!
Sep 28 23:12:39 aragorn kernel: ricoh-mmc: Suspending.
Sep 28 23:12:39 aragorn kernel: ricoh-mmc: Controller is now re-enabled.
Sep 28 23:12:39 aragorn kernel: mmc0: card 8879 removed
Sep 28 23:12:39 aragorn kernel: MMC: killing requests for dead queue
Sep 28 23:12:39 aragorn kernel: ACPI handle has no ...
[ message continues ]

Forgot the most important bits.

Kernel is current git (2.6.27-rc7-106-g6ef190c), x86_64.
Laptop is running Debian amd64/unstable.
--

[ message continues ]

The 'parent mmc0 should not be sleeping' message is a known problem with MMC.

Thanks,
Rafael
--

[ message continues ]

Eep! I'm sure that doesn't sound like a good idea. ricoh-mmc is 
suspending before sdhci is. In the process, it flips the hardware back 
into non-sdhci mode and the sdhci controller stops being able to talk to 
the card. I suspect that this upsets its own suspend routine rather a 
lot. Does this help at all? Not a complete fix, I suspect you'll still 
have issues on resume.

diff --git a/drivers/mmc/host/ricoh_mmc.c b/drivers/mmc/host/ricoh_mmc.c
index a16d760..015c248 100644
--- a/drivers/mmc/host/ricoh_mmc.c
+++ b/drivers/mmc/host/ricoh_mmc.c
@@ -191,20 +191,6 @@ static void __devexit ricoh_mmc_remove(struct pci_dev *pdev)
 	pci_set_drvdata(pdev, NULL);
 }
 
-static int ricoh_mmc_suspend(struct pci_dev *pdev, pm_message_t state)
-{
-	struct pci_dev *fw_dev = NULL;
-
-	fw_dev = pci_get_drvdata(pdev);
-	BUG_ON(fw_dev == NULL);
-
-	printk(KERN_INFO DRIVER_NAME ": Suspending.\n");
-
-	ricoh_mmc_enable(fw_dev);
-
-	return 0;
-}
-
 static int ricoh_mmc_resume(struct pci_dev *pdev)
 {
 	struct pci_dev *fw_dev = NULL;
@@ -224,7 +210,6 @@ static struct pci_driver ricoh_mmc_driver = {
 	.id_table =	pci_ids,
 	.probe = 	ricoh_mmc_probe,
 	.remove =	__devexit_p(ricoh_mmc_remove),
-	.suspend =	ricoh_mmc_suspend,
 	.resume =	ricoh_mmc_resume,
 };


-- 
Matthew Garrett | mjg59@srcf.ucam.org
--

[ message continues ]

More to the point, how about this one? It should also handle the resume 
case, but I haven't tested it yet.

diff --git a/drivers/mmc/host/Kconfig b/drivers/mmc/host/Kconfig
index ea8d7a3..806bcd8 100644
--- a/drivers/mmc/host/Kconfig
+++ b/drivers/mmc/host/Kconfig
@@ -48,23 +48,6 @@ config MMC_SDHCI_PCI
 
 	  If unsure, say N.
 
-config MMC_RICOH_MMC
-	tristate "Ricoh MMC Controller Disabler  (EXPERIMENTAL)"
-	depends on MMC_SDHCI_PCI
-	help
-	  This selects the disabler for the Ricoh MMC Controller. This
-	  proprietary controller is unnecessary because the SDHCI driver
-	  supports MMC cards on the SD controller, but if it is not
-	  disabled, it will steal the MMC cards away - rendering them
-	  useless. It is safe to select this driver even if you don't
-	  have a Ricoh based card reader.
-
-
-	  To compile this driver as a module, choose M here:
-	  the module will be called ricoh_mmc.
-
-	  If unsure, say Y.
-
 config MMC_OMAP
 	tristate "TI OMAP Multimedia Card Interface support"
 	depends on ARCH_OMAP
diff --git a/drivers/mmc/host/Makefile b/drivers/mmc/host/Makefile
index c794cc5..0676890 100644
--- a/drivers/mmc/host/Makefile
+++ b/drivers/mmc/host/Makefile
@@ -11,7 +11,6 @@ obj-$(CONFIG_MMC_PXA)		+= pxamci.o
 obj-$(CONFIG_MMC_IMX)		+= imxmmc.o
 obj-$(CONFIG_MMC_SDHCI)		+= sdhci.o
 obj-$(CONFIG_MMC_SDHCI_PCI)	+= sdhci-pci.o
-obj-$(CONFIG_MMC_RICOH_MMC)	+= ricoh_mmc.o
 obj-$(CONFIG_MMC_WBSD)		+= wbsd.o
 obj-$(CONFIG_MMC_AU1X)		+= au1xmmc.o
 obj-$(CONFIG_MMC_OMAP)		+= omap.o
diff --git a/drivers/mmc/host/ricoh_mmc.c b/drivers/mmc/host/ricoh_mmc.c
deleted file mode 100644
index a16d760..0000000
--- a/drivers/mmc/host/ricoh_mmc.c
+++ /dev/null
@@ -1,257 +0,0 @@
-/*
- *  ricoh_mmc.c - Dummy driver to disable the Rioch MMC controller.
- *
- *  Copyright (C) 2007 Philip Langdale, All Rights Reserved.
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License as published by
- ...
[ message continues ]

Thanks Matthew.

For the second part of the quirk the device name is incorrect. It should
be r5c832 instead of rl5c832 and the DECLAREs also have the wrong device.
I think it would probably be good to add a printk for an info or debug
message saying that the proprietary controller has been disabled.

After fixing that it compiles correctly and does improve things a lot, but
there are still remaining issues. I suspect these are probably unrelated
to the proprietary controller though.

During suspend I now get:
Suspending console(s) (use no_console_suspend to debug)
pci 0000:00:02.0: PCI INT A disabled
sd 0:0:0:0: [sda] Synchronizing SCSI cache
sd 0:0:0:0: [sda] Stopping disk
ACPI handle has no context!
mmc0: card 8879 removed
MMC: killing requests for dead queue
ACPI handle has no context!
sdhci-pci 0000:02:06.2: PCI INT C disabled
ACPI handle has no context!
ACPI handle has no context!
iwlagn 0000:10:00.0: PCI INT A disabled
[...]

This means that all those register dumps are gone, but I'm not sure about
the "killing requests for dead queue" message.

During resume I get:
sdhci-pci 0000:02:06.2: restoring config space at offset 0xf (was 0x300, writing 0x30a)
sdhci-pci 0000:02:06.2: restoring config space at offset 0x4 (was 0x0, writing 0xe0102000)
sdhci-pci 0000:02:06.2: restoring config space at offset 0x3 (was 0x800000, writing 0x804010)
sdhci-pci 0000:02:06.2: restoring config space at offset 0x1 (was 0x2100000, writing 0x2100006)
sdhci-pci 0000:02:06.2: PCI INT C -> GSI 20 (level, low) -> IRQ 20
mmc0: new SD card at address 8879
mmc mmc0:8879: parent mmc0 should not be sleeping
mmcblk0: mmc0:8879 SU02G 1985024KiB
 mmcblk0: p1

The "parent should not be sleeping" message is still there.

All that was still without having a partition mounted. After resume a vfat
partition on the card can be mounted successfully.


I've also tried suspending while a partition on the card (vfat) was
mounted. This gives the same messages during suspend/resume, but reading
from ...
[ message continues ]

This works here (Ubuntu 8.04.1, v2.6.27-rc9). It is likely the hald
configuration
on Ubuntu as to why it works:

Oct  7 19:52:34 blimp hald: unmounted /dev/mmcblk0p1 from
'/media/disk' on behalf of uid 0
[ message continues ]

Hi Matthew,

What's the status of this patch? If you like I can submit it (with the 
minor fixes that were needed). Or are there issues with it?

My tests showed that it did not fix all suspend/resume problems, but it 
was a structural improvement.

Cheers,
FJP


--

[ message continues ]