All of lore.kernel.org
 help / color / mirror / Atom feed
* Ricoh R5C822 and QUIRK_FORCE_DMA
@ 2009-04-30 22:45 Tobias Diedrich
  2009-05-13 17:59 ` Pierre Ossman
  0 siblings, 1 reply; 7+ messages in thread
From: Tobias Diedrich @ 2009-04-30 22:45 UTC (permalink / raw)
  To: Pierre Ossman; +Cc: linux-kernel

Hi,

I recently got a used Thinkpad X41, which has a built-in Ricoh
R5C822 Rev 13 SD controller, which seems to only use dma if I add
the FORCE_DMA quirk:

|04:00.1 SD Host controller: Ricoh Co Ltd R5C822 SD/SDIO/MMC/MS/MSPro
|Host Adapter (rev 13)
|        Subsystem: IBM ThinkPad X60s / Z60t
|        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
|        Interrupt: pin B routed to IRQ 17
|        Region 0: Memory at a0201000 (32-bit, non-prefetchable) [size=256]
|        Capabilities: [80] Power Management version 2
|                Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0+,D1+,D2+,D3hot+,D3cold+)
|                Status: D0 PME-Enable- DSel=0 DScale=2 PME-
|        Kernel driver in use: sdhci-pci
|00: 80 11 22 08 06 01 10 02 13 00 05 08 00 40 80 00
|10: 00 10 20 a0 00 00 00 00 00 00 00 00 00 00 00 00
|20: 00 00 00 00 00 00 00 00 00 00 00 00 14 10 56 05
|30: 00 00 00 00 80 00 00 00 00 00 00 00 0b 02 00 00
|40: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
|50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
|60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
|70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
|80: 01 00 02 fe 00 40 00 48 00 00 00 00 00 00 00 00
|90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
|a0: 00 00 00 00 00 00 00 00 00 00 00 00 14 10 56 05
|b0: 00 00 02 00 00 00 00 00 00 00 00 00 00 00 00 00
|c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
|d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
|e0: a1 21 80 01 00 00 00 00 40 00 00 00 00 00 00 00
|f0: 00 00 00 00 00 00 00 00 03 00 20 04 00 00 00 00

I found that (using 2.6.30-rc4) the SD controller is rather slow and
makes the X cursor jumpy, so I suspected it is using PIO rather than
DMA.  vmstat also showed a high system percentage instead of just
iowait.

After adding a 'No DMA available' debugging statement I found that
this revision does not seem to claim DMA support.  However, after
seeing in some dmesg logs that at least Rev 18 and greater do
support DMA, I thought I'd try to add SDHCI_QUIRK_FORCE_DMA to
sdhci-pci.c.

Lo and behold, the speed has now doubled (4MB/s vs. nearly 8MB/s),
the mouse cursor is no longer jumpy and system percentage is down to
5% with 95% iowait.

Do you know any controller bugs for this revision which may be the
reason for not advertising DMA capability?
I haven't done any big tests yet, but at first glance it seems to
read/write the card just fine.

HTH,

-- 
Tobias						PGP: http://9ac7e0bc.uguu.de

^ permalink raw reply	[flat|nested] 7+ messages in thread
* Re: Ricoh R5C822 and QUIRK_FORCE_DMA
  2009-04-30 22:45 Ricoh R5C822 and QUIRK_FORCE_DMA Tobias Diedrich
@ 2009-05-13 17:59 ` Pierre Ossman
  2009-05-13 18:09   ` [Sdhci-devel] " Garrett D'Amore
  2009-06-09 22:41   ` QUIRK_FORCE_HISPD (was: Re: Ricoh R5C822 and QUIRK_FORCE_DMA) Tobias Diedrich
  0 siblings, 2 replies; 7+ messages in thread
From: Pierre Ossman @ 2009-05-13 17:59 UTC (permalink / raw)
  To: Tobias Diedrich; +Cc: SDHCI development, linux-kernel

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

(cc:ing sdhci-devel)

On Fri, 1 May 2009 00:45:24 +0200
Tobias Diedrich <ranma+kernel@tdiedrich.de> wrote:

> 
> Do you know any controller bugs for this revision which may be the
> reason for not advertising DMA capability?
> I haven't done any big tests yet, but at first glance it seems to
> read/write the card just fine.
> 

Might be a system problem so it's Lenovo that disabled it. You're the
first report I've seen on this since the DMA logic was reworked so that
DMA didn't have to be forced for most cases.

Is there anyone else reading this that are having DMA problems?

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

^ permalink raw reply	[flat|nested] 7+ messages in thread
* Re: [Sdhci-devel] Ricoh R5C822 and QUIRK_FORCE_DMA
  2009-05-13 17:59 ` Pierre Ossman
@ 2009-05-13 18:09   ` Garrett D'Amore
  2009-06-09 22:41   ` QUIRK_FORCE_HISPD (was: Re: Ricoh R5C822 and QUIRK_FORCE_DMA) Tobias Diedrich
  1 sibling, 0 replies; 7+ messages in thread
From: Garrett D'Amore @ 2009-05-13 18:09 UTC (permalink / raw)
  To: Pierre Ossman; +Cc: Tobias Diedrich, SDHCI development, linux-kernel

I know that we've run into some bizarre behavior with Ricoh controllers 
and DMA in the Solaris implementation of sdhost.  Specifically, what we 
ran into was problems with DMA across certain alignment boundaries.  It 
seems that when a DMA operation is not aligned on a 512 boundary, or 
does something less than a 512 byte transfer, it has trouble.

In the Solaris driver, I just allocate a big 64k page-aligned chunk for 
DMA, and use bcopy to/from that.  Frankly, bcopy is fast enough, that it 
makes little performance difference.  Plus, it means that I can use a 
larger interrupt threshold than 4K, allowing me to skip the 
scatter/gather overhead... I suspect that this negates the cost of the 
bcopy.

After doing this, the Lenovo and Toshiba laptops that I've had access to 
work well.

    - Garrett

Pierre Ossman wrote:
> (cc:ing sdhci-devel)
>
> On Fri, 1 May 2009 00:45:24 +0200
> Tobias Diedrich <ranma+kernel@tdiedrich.de> wrote:
>
>   
>> Do you know any controller bugs for this revision which may be the
>> reason for not advertising DMA capability?
>> I haven't done any big tests yet, but at first glance it seems to
>> read/write the card just fine.
>>
>>     
>
> Might be a system problem so it's Lenovo that disabled it. You're the
> first report I've seen on this since the DMA logic was reworked so that
> DMA didn't have to be forced for most cases.
>
> Is there anyone else reading this that are having DMA problems?
>
> Rgds
>   
> ------------------------------------------------------------------------
>
> _______________________________________________
> sdhci-devel mailing list
> sdhci-devel@lists.ossman.eu
> http://list.drzeus.cx/mailman/listinfo/sdhci-devel
>   


^ permalink raw reply	[flat|nested] 7+ messages in thread
* QUIRK_FORCE_HISPD (was: Re: Ricoh R5C822 and QUIRK_FORCE_DMA)
  2009-05-13 17:59 ` Pierre Ossman
  2009-05-13 18:09   ` [Sdhci-devel] " Garrett D'Amore
@ 2009-06-09 22:41   ` Tobias Diedrich
  2009-06-13 10:53     ` Pierre Ossman
  1 sibling, 1 reply; 7+ messages in thread
From: Tobias Diedrich @ 2009-06-09 22:41 UTC (permalink / raw)
  To: Pierre Ossman; +Cc: SDHCI development, linux-kernel

Pierre Ossman wrote:
> Might be a system problem so it's Lenovo that disabled it. You're the
> first report I've seen on this since the DMA logic was reworked so that
> DMA didn't have to be forced for most cases.

FWIW, so far I haven't had any errors due to dma being enabled.

I tried changing the CAPS using setpci, but they seem to be
read-only (unless theres are write-protect bit somewhere in the
config space).

On a related note, I had a little time to play a bit more with my
R5C822 and found that I can also force-enable HISPD mode, which
boost performance further.

And the kernel controlled LED toggling does not work at all.
(SDHCI_USE_LEDS_CLASS).

I had a look at the HOST_CONTROL register and found that while the
HISPD bit can be toggled, I can't toggle the LED bit.

With the patched sdhci I now get 14 MB/s reading a hispeed card:


USB:    Reading: 19.8 MB/s  Writing: 13.8 MB/s
patched
SDHCI:  Reading: 14.5 MB/s  Writing:  3.5 MB/s
unpatched
SDHCI:  Reading:  3.4 MB/s  Writing:  6.6 MB/s

Interestingly PIO write seems to be faster than DMA write.
Also interesting:
With unpatched SDHCI (PIO), reading hogs the CPU and makes the system
very unresponsive (jumping X cursor, slow terminal refresh).
However writing is not as bad, about 25% system usage, still
responsive (and also faster than reads!?).

For some reason enabling HISPD did not improve write speed at all,
only the read speed doubled.

I tried improving the write speed by adding support for
APP_CMD_SET_WR_BLOCK_COUNT to the block driver, but did not see any
improvement.
It's still in the patch, in case you are interested.

dmesg, unpatched:
[ 5295.130010] sdhci: Secure Digital Host Controller Interface driver
[ 5295.130010] sdhci: Copyright(c) Pierre Ossman
[ 5295.140012] sdhci-pci 0000:04:00.1: SDHCI controller found [1180:0822] (rev 13)
[ 5295.140012] sdhci-pci 0000:04:00.1: PCI INT B -> GSI 17 (level, low) -> IRQ 17
[ 5295.140012] Registered led device: mmc0::
[ 5295.140012] mmc0: SDHCI controller on PCI [0000:04:00.1] using PIO
[ 5295.380271] mmc0: new SDHC card at address b368
[ 5295.380271] mmcblk0: mmc0:b368 SDC   14.9 GiB 
[ 5295.380271]  mmcblk0: p1

dmesg, patched:
[ 5906.950010] sdhci: Secure Digital Host Controller Interface driver
[ 5906.950010] sdhci: Copyright(c) Pierre Ossman
[ 5906.960011] sdhci-pci 0000:04:00.1: SDHCI controller found [1180:0822] (rev 13)
[ 5906.960011] sdhci-pci 0000:04:00.1: PCI INT B -> GSI 17 (level, low) -> IRQ 17
[ 5906.960011] mmc0: Controller vendor_ver=02 sdhci_ver=00.
[ 5906.960011] mmc0: Controller caps=018021a1.
[ 5906.960011] DMA forced on (host quirk)
[ 5906.960011] sdhci-pci 0000:04:00.1: Will use DMA mode even though HW doesn't fully claim to support it.
[ 5906.960011] HISPD forced on (host quirk)
[ 5906.960011] Verified that HOST_CONTROL bit SDHCI_CTRL_HISPD can be toggled
[ 5906.960011] Could not set SDHCI_CTRL_LED to 1!
[ 5906.960011] mmc0: SDHCI controller on PCI [0000:04:00.1] using DMA
[ 5907.211304] mmc0: new high speed SDHC card at address b368
[ 5907.211304] mmcblk0: mmc0:b368 SDC   14.9 GiB 
[ 5907.211304]  mmcblk0: p1



Index: linux-2.6.30-rc8/drivers/mmc/host/sdhci.c
===================================================================
--- linux-2.6.30-rc8.orig/drivers/mmc/host/sdhci.c	2009-06-09 23:11:43.329261011 +0200
+++ linux-2.6.30-rc8/drivers/mmc/host/sdhci.c	2009-06-09 23:12:11.489274926 +0200
@@ -1614,6 +1614,10 @@
 	sdhci_reset(host, SDHCI_RESET_ALL);
 
 	host->version = sdhci_readw(host, SDHCI_HOST_VERSION);
+	printk(KERN_ERR "%s: Controller vendor_ver=%02x sdhci_ver=%02x.\n",
+	       mmc_hostname(mmc),
+	       (host->version & SDHCI_VENDOR_VER_MASK) >> SDHCI_VENDOR_VER_SHIFT,
+	       (host->version & SDHCI_SPEC_VER_MASK) >> SDHCI_SPEC_VER_SHIFT);
 	host->version = (host->version & SDHCI_SPEC_VER_MASK)
 				>> SDHCI_SPEC_VER_SHIFT;
 	if (host->version > SDHCI_SPEC_200) {
@@ -1623,11 +1627,14 @@
 	}
 
 	caps = sdhci_readl(host, SDHCI_CAPABILITIES);
+	printk(KERN_ERR "%s: Controller caps=%08x.\n",
+	       mmc_hostname(mmc), caps);
 
-	if (host->quirks & SDHCI_QUIRK_FORCE_DMA)
+	if (host->quirks & SDHCI_QUIRK_FORCE_DMA) {
+		printk(KERN_WARNING "DMA forced on (host quirk)\n");
 		host->flags |= SDHCI_USE_DMA;
-	else if (!(caps & SDHCI_CAN_DO_DMA))
-		DBG("Controller doesn't have DMA capability\n");
+	} else if (!(caps & SDHCI_CAN_DO_DMA))
+		printk(KERN_WARNING "Controller doesn't have DMA capability\n");
 	else
 		host->flags |= SDHCI_USE_DMA;
 
@@ -1723,7 +1730,34 @@
 	mmc->f_max = host->max_clk;
 	mmc->caps = MMC_CAP_4_BIT_DATA | MMC_CAP_SDIO_IRQ;
 
-	if (caps & SDHCI_CAN_DO_HISPD)
+
+	if (host->quirks & SDHCI_QUIRK_FORCE_HISPD) {
+		unsigned char ctrl;
+		int toggle_ok = 1;
+
+		printk(KERN_WARNING "HISPD forced on (host quirk)\n");
+
+		ctrl = sdhci_readb(host, SDHCI_HOST_CONTROL);
+		ctrl |= SDHCI_CTRL_HISPD;
+		sdhci_writeb(host, ctrl, SDHCI_HOST_CONTROL);
+		ctrl = sdhci_readb(host, SDHCI_HOST_CONTROL);
+		if (!(ctrl & SDHCI_CTRL_HISPD)) {
+			printk(KERN_WARNING "Could not set SDHCI_CTRL_HISPD to 1!\n");
+			toggle_ok = 0;
+		}
+		ctrl &= ~SDHCI_CTRL_HISPD;
+		sdhci_writeb(host, ctrl, SDHCI_HOST_CONTROL);
+		ctrl = sdhci_readb(host, SDHCI_HOST_CONTROL);
+		if (ctrl & SDHCI_CTRL_HISPD) {
+			printk(KERN_WARNING "Could not set SDHCI_CTRL_HISPD to 0!\n");
+			toggle_ok = 0;
+		}
+		if (toggle_ok) {
+			printk(KERN_WARNING "Verified that HOST_CONTROL bit SDHCI_CTRL_HISPD can be toggled\n");
+		}
+
+		mmc->caps |= MMC_CAP_SD_HIGHSPEED;
+	} else if (caps & SDHCI_CAN_DO_HISPD)
 		mmc->caps |= MMC_CAP_SD_HIGHSPEED;
 
 	if (host->quirks & SDHCI_QUIRK_BROKEN_CARD_DETECTION)
@@ -1818,16 +1852,41 @@
 #endif
 
 #ifdef SDHCI_USE_LEDS_CLASS
-	snprintf(host->led_name, sizeof(host->led_name),
-		"%s::", mmc_hostname(mmc));
-	host->led.name = host->led_name;
-	host->led.brightness = LED_OFF;
-	host->led.default_trigger = mmc_hostname(mmc);
-	host->led.brightness_set = sdhci_led_control;
-
-	ret = led_classdev_register(mmc_dev(mmc), &host->led);
-	if (ret)
-		goto reset;
+	{
+		unsigned char ctrl;
+		int toggle_ok = 1;
+
+		ctrl = sdhci_readb(host, SDHCI_HOST_CONTROL);
+		ctrl |= SDHCI_CTRL_LED;
+		sdhci_writeb(host, ctrl, SDHCI_HOST_CONTROL);
+		ctrl = sdhci_readb(host, SDHCI_HOST_CONTROL);
+		if (!(ctrl & SDHCI_CTRL_LED)) {
+			printk(KERN_WARNING "Could not set SDHCI_CTRL_LED to 1!\n");
+			toggle_ok = 0;
+		}
+		ctrl &= ~SDHCI_CTRL_LED;
+		sdhci_writeb(host, ctrl, SDHCI_HOST_CONTROL);
+		ctrl = sdhci_readb(host, SDHCI_HOST_CONTROL);
+		if (ctrl & SDHCI_CTRL_LED) {
+			printk(KERN_WARNING "Could not set SDHCI_CTRL_LED to 0!\n");
+			toggle_ok = 0;
+		}
+		if (toggle_ok) {
+			printk(KERN_WARNING "Verified that HOST_CONTROL bit SDHCI_CTRL_LED can be toggled\n");
+			snprintf(host->led_name, sizeof(host->led_name),
+				"%s::", mmc_hostname(mmc));
+			host->led.name = host->led_name;
+			host->led.brightness = LED_OFF;
+			host->led.default_trigger = mmc_hostname(mmc);
+			host->led.brightness_set = sdhci_led_control;
+
+			ret = led_classdev_register(mmc_dev(mmc), &host->led);
+			if (ret)
+				goto reset;
+		} else {
+			host->led.name = NULL;
+		}
+	}
 #endif
 
 	mmiowb();
@@ -1882,7 +1941,8 @@
 	mmc_remove_host(host->mmc);
 
 #ifdef SDHCI_USE_LEDS_CLASS
-	led_classdev_unregister(&host->led);
+	if (host->led.name) /* name is NULL if LED can not be controlled */
+		led_classdev_unregister(&host->led);
 #endif
 
 	if (!dead)
Index: linux-2.6.30-rc8/drivers/mmc/host/sdhci-pci.c
===================================================================
--- linux-2.6.30-rc8.orig/drivers/mmc/host/sdhci-pci.c	2009-06-09 23:11:43.349260831 +0200
+++ linux-2.6.30-rc8/drivers/mmc/host/sdhci-pci.c	2009-06-09 23:12:11.489274926 +0200
@@ -91,7 +91,9 @@
 
 static const struct sdhci_pci_fixes sdhci_ricoh = {
 	.probe		= ricoh_probe,
-	.quirks		= SDHCI_QUIRK_32BIT_DMA_ADDR,
+	.quirks		= SDHCI_QUIRK_32BIT_DMA_ADDR |
+			  SDHCI_QUIRK_FORCE_DMA |
+			  SDHCI_QUIRK_FORCE_HISPD,
 };
 
 static const struct sdhci_pci_fixes sdhci_ene_712 = {
Index: linux-2.6.30-rc8/drivers/mmc/host/sdhci.h
===================================================================
--- linux-2.6.30-rc8.orig/drivers/mmc/host/sdhci.h	2009-06-09 23:11:43.309261052 +0200
+++ linux-2.6.30-rc8/drivers/mmc/host/sdhci.h	2009-06-09 23:12:11.489274926 +0200
@@ -226,6 +226,8 @@
 #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 has bad caps bits, but really supports HISPD */
+#define SDHCI_QUIRK_FORCE_HISPD				(1<<21)
 
 	int			irq;		/* Device IRQ */
 	void __iomem *		ioaddr;		/* Mapped address */
Index: linux-2.6.30-rc8/drivers/mmc/card/block.c
===================================================================
--- linux-2.6.30-rc8.orig/drivers/mmc/card/block.c	2009-06-09 23:11:43.369261139 +0200
+++ linux-2.6.30-rc8/drivers/mmc/card/block.c	2009-06-09 23:12:11.499260622 +0200
@@ -40,6 +40,7 @@
 #include <asm/uaccess.h>
 
 #include "queue.h"
+#include "../core/sd_ops.h"
 
 MODULE_ALIAS("mmc:block");
 
@@ -262,6 +263,22 @@
 			brq.data.blocks = card->host->max_blk_count;
 
 		/*
+		 * Inform the card about the number of blocks to be written.
+		 */
+		if (card->type == MMC_TYPE_SD &&
+		    rq_data_dir(req) == WRITE) {
+			int err;
+
+			err = mmc_app_set_wr_blk_erase_cnt(card, brq.data.blocks);
+			if (err)
+				printk(KERN_WARNING
+				       "%s: mmc_app_set_wr_blk_erase_cnt "
+				       "failed: %d\n",
+				       req->rq_disk->disk_name,
+				       err);
+		}
+
+		/*
 		 * After a read error, we redo the request one sector at a time
 		 * in order to accurately determine which sectors can be read
 		 * successfully.
Index: linux-2.6.30-rc8/drivers/mmc/core/sd_ops.c
===================================================================
--- linux-2.6.30-rc8.orig/drivers/mmc/core/sd_ops.c	2009-06-09 23:11:43.409260079 +0200
+++ linux-2.6.30-rc8/drivers/mmc/core/sd_ops.c	2009-06-09 23:12:11.499260622 +0200
@@ -299,6 +299,28 @@
 	return 0;
 }
 
+int mmc_app_set_wr_blk_erase_cnt(struct mmc_card *card, int count)
+{
+	int err;
+	struct mmc_command cmd;
+
+	BUG_ON(!card);
+	BUG_ON(!card->host);
+
+	memset(&cmd, 0, sizeof(struct mmc_command));
+
+	cmd.opcode = SD_APP_SET_WR_BLK_ERASE_CNT;
+	cmd.flags = MMC_RSP_R1 | MMC_CMD_AC;
+	cmd.arg = count;
+
+	err = mmc_wait_for_app_cmd(card->host, card, &cmd, MMC_CMD_RETRIES);
+	if (err)
+		return err;
+
+	return 0;
+}
+EXPORT_SYMBOL(mmc_app_set_wr_blk_erase_cnt);
+
 int mmc_sd_switch(struct mmc_card *card, int mode, int group,
 	u8 value, u8 *resp)
 {
Index: linux-2.6.30-rc8/drivers/mmc/core/sd_ops.h
===================================================================
--- linux-2.6.30-rc8.orig/drivers/mmc/core/sd_ops.h	2009-06-09 23:11:43.389260399 +0200
+++ linux-2.6.30-rc8/drivers/mmc/core/sd_ops.h	2009-06-09 23:12:11.499260622 +0200
@@ -13,6 +13,7 @@
 #define _MMC_SD_OPS_H
 
 int mmc_app_set_bus_width(struct mmc_card *card, int width);
+int mmc_app_set_wr_blk_erase_cnt(struct mmc_card *card, int count);
 int mmc_send_app_op_cond(struct mmc_host *host, u32 ocr, u32 *rocr);
 int mmc_send_if_cond(struct mmc_host *host, u32 ocr);
 int mmc_send_relative_addr(struct mmc_host *host, unsigned int *rca);
Index: linux-2.6.30-rc8/include/linux/mmc/sd.h
===================================================================
--- linux-2.6.30-rc8.orig/include/linux/mmc/sd.h	2009-06-09 23:11:43.439260121 +0200
+++ linux-2.6.30-rc8/include/linux/mmc/sd.h	2009-06-09 23:13:35.834952507 +0200
@@ -12,20 +12,21 @@
 #ifndef MMC_SD_H
 #define MMC_SD_H
 
-/* SD commands                           type  argument     response */
+/* SD commands                               type  argument     response */
   /* class 0 */
 /* This is basically the same command as for MMC with some quirks. */
-#define SD_SEND_RELATIVE_ADDR     3   /* bcr                     R6  */
-#define SD_SEND_IF_COND           8   /* bcr  [11:0] See below   R7  */
+#define SD_SEND_RELATIVE_ADDR        3    /* bcr                     R6  */
+#define SD_SEND_IF_COND              8    /* bcr  [11:0] See below   R7  */
 
   /* class 10 */
-#define SD_SWITCH                 6   /* adtc [31:0] See below   R1  */
+#define SD_SWITCH                    6    /* adtc [31:0] See below   R1  */
 
   /* Application commands */
-#define SD_APP_SET_BUS_WIDTH      6   /* ac   [1:0] bus width    R1  */
-#define SD_APP_SEND_NUM_WR_BLKS  22   /* adtc                    R1  */
-#define SD_APP_OP_COND           41   /* bcr  [31:0] OCR         R3  */
-#define SD_APP_SEND_SCR          51   /* adtc                    R1  */
+#define SD_APP_SET_BUS_WIDTH         6    /* ac   [1:0] bus width    R1  */
+#define SD_APP_SEND_NUM_WR_BLKS     22    /* adtc                    R1  */
+#define SD_APP_SET_WR_BLK_ERASE_CNT 23    /* adtc                    R1  */
+#define SD_APP_OP_COND              41    /* bcr  [31:0] OCR         R3  */
+#define SD_APP_SEND_SCR             51    /* adtc                    R1  */
 
 /*
  * SD_SWITCH argument format:

-- 
Tobias						PGP: http://9ac7e0bc.uguu.de

^ permalink raw reply	[flat|nested] 7+ messages in thread
* Re: QUIRK_FORCE_HISPD (was: Re: Ricoh R5C822 and QUIRK_FORCE_DMA)
  2009-06-09 22:41   ` QUIRK_FORCE_HISPD (was: Re: Ricoh R5C822 and QUIRK_FORCE_DMA) Tobias Diedrich
@ 2009-06-13 10:53     ` Pierre Ossman
  2009-08-01  5:17       ` Tobias Diedrich
  0 siblings, 1 reply; 7+ messages in thread
From: Pierre Ossman @ 2009-06-13 10:53 UTC (permalink / raw)
  To: Tobias Diedrich; +Cc: SDHCI development, linux-kernel

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

On Wed, 10 Jun 2009 00:41:45 +0200
Tobias Diedrich <ranma+kernel@tdiedrich.de> wrote:

> Pierre Ossman wrote:
> > Might be a system problem so it's Lenovo that disabled it. You're the
> > first report I've seen on this since the DMA logic was reworked so that
> > DMA didn't have to be forced for most cases.
> 
> FWIW, so far I haven't had any errors due to dma being enabled.
> 
> I tried changing the CAPS using setpci, but they seem to be
> read-only (unless theres are write-protect bit somewhere in the
> config space).

They tend to be write-protected, yes. Usually there are some other
registers you need to fiddle with first.

> On a related note, I had a little time to play a bit more with my
> R5C822 and found that I can also force-enable HISPD mode, which
> boost performance further.
> 

This seems odd. What frequency is the controller reporting?

It could be that they originally wanted the controller to be
high-speed, but that they had stability problems and turned it off.
There is at least one other controller that went through that scenario.

> I tried improving the write speed by adding support for
> APP_CMD_SET_WR_BLOCK_COUNT to the block driver, but did not see any
> improvement.
> It's still in the patch, in case you are interested.

I've tried this before, and I got the same results you did.

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

^ permalink raw reply	[flat|nested] 7+ messages in thread
* Re: QUIRK_FORCE_HISPD (was: Re: Ricoh R5C822 and QUIRK_FORCE_DMA)
  2009-06-13 10:53     ` Pierre Ossman
@ 2009-08-01  5:17       ` Tobias Diedrich
  2009-09-06 13:30         ` Pierre Ossman
  0 siblings, 1 reply; 7+ messages in thread
From: Tobias Diedrich @ 2009-08-01  5:17 UTC (permalink / raw)
  To: Pierre Ossman; +Cc: SDHCI development, linux-kernel

Pierre Ossman wrote:
> > On a related note, I had a little time to play a bit more with my
> > R5C822 and found that I can also force-enable HISPD mode, which
> > boost performance further.
> > 
> 
> This seems odd. What frequency is the controller reporting?
> 
> It could be that they originally wanted the controller to be
> high-speed, but that they had stability problems and turned it off.
> There is at least one other controller that went through that scenario.

I assume thats host->max_clk?
The controller seems to report 33MHz for that value.

[130484.232213] mmc0: Controller vendor_ver=02 sdhci_ver=00.
[130484.232213] mmc0: Controller caps=018021a1.
[130484.232213] SDHCI_INT_ENABLE: Can toggle bits e1ff01ff
[130484.232213] SDHCI_HOST_CONTROL: Can toggle bits 06
[130484.232213] DMA forced on (host quirk)
[130484.232213] sdhci-pci 0000:04:00.1: Will use DMA mode even though HW doesn't fully claim to support it.
[130484.232213] host->max_clk: 33000000
[130484.232213] HISPD forced on (host quirk)
[130484.232213] Verified that HOST_CONTROL bit SDHCI_CTRL_HISPD can be toggled
[130484.232213] Could not set SDHCI_CTRL_LED to 1!


-- 
Tobias						PGP: http://9ac7e0bc.uguu.de

^ permalink raw reply	[flat|nested] 7+ messages in thread
* Re: QUIRK_FORCE_HISPD (was: Re: Ricoh R5C822 and QUIRK_FORCE_DMA)
  2009-08-01  5:17       ` Tobias Diedrich
@ 2009-09-06 13:30         ` Pierre Ossman
  0 siblings, 0 replies; 7+ messages in thread
From: Pierre Ossman @ 2009-09-06 13:30 UTC (permalink / raw)
  To: Tobias Diedrich; +Cc: SDHCI development, linux-kernel

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

On Sat, 1 Aug 2009 07:17:16 +0200
Tobias Diedrich <ranma@tdiedrich.de> wrote:

> Pierre Ossman wrote:
> > > On a related note, I had a little time to play a bit more with my
> > > R5C822 and found that I can also force-enable HISPD mode, which
> > > boost performance further.
> > > 
> > 
> > This seems odd. What frequency is the controller reporting?
> > 
> > It could be that they originally wanted the controller to be
> > high-speed, but that they had stability problems and turned it off.
> > There is at least one other controller that went through that scenario.
> 
> I assume thats host->max_clk?
> The controller seems to report 33MHz for that value.
> 

Ah, then your controller is most likely not really high-speed. You're
getting a bit more performance as you are forcing things out-of-spec
and you're lucky enough that it still happens to work. :)

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

^ permalink raw reply	[flat|nested] 7+ messages in thread
end of thread, other threads:[~2009-09-06 13:30 UTC | newest]

Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2009-04-30 22:45 Ricoh R5C822 and QUIRK_FORCE_DMA Tobias Diedrich
2009-05-13 17:59 ` Pierre Ossman
2009-05-13 18:09   ` [Sdhci-devel] " Garrett D'Amore
2009-06-09 22:41   ` QUIRK_FORCE_HISPD (was: Re: Ricoh R5C822 and QUIRK_FORCE_DMA) Tobias Diedrich
2009-06-13 10:53     ` Pierre Ossman
2009-08-01  5:17       ` Tobias Diedrich
2009-09-06 13:30         ` Pierre Ossman

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.