linux-kernel - Ricoh R5C822 and QUIRK_FORCE

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Date:	Fri, 1 May 2009 00:45:24 +0200
From:	Tobias Diedrich <ranma+kernel@...edrich.de>
To:	Pierre Ossman <drzeus@...eus.cx>
Cc:	linux-kernel@...r.kernel.org
Subject: Ricoh R5C822 and QUIRK_FORCE_DMA

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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/