Problems with SD8686 SDIO on HTC Shift

[Dan Williams]

On Sat, 2009-01-24 at 21:31 +0100, Sven Barth wrote:
> Hello Dan!
> 
> Thanks again for your answer.
> 
> Do you know where or how I could find out what workarounds my controller 

No; this is usually either known from hardware quirks, or people figure
it out by doing stuff like disabling 4-bit transfers and seeing if that
fixes the problem.

> needs to work well? And what do I need to rebuild the mmc/sdhci modules?

You'll need the kernel source for the SDIO stuff.

> Are they provided in a extra package like compat-wireless or do I need 
> the source of my kernel release? Can I only build the needed modules or 
> do I need to build the hole kernel?

You don't need to rebuild the entire kernel just to test; once you have
the kernel source and the kernel development headers installed, you can
just jump into the module directory in the kernel source, and do:

make -C /path/to/kernel/headers SUBDIRS=`pwd` modules

and it'll build only the modules in that directory.  For example, on
Fedora:

cd drivers/mmc/host
make -C /lib/modules/2.6.27.5-41.fc9.i686/build SUBDIRS=`pwd` modules

would build all the SDHC modules that are turned on in the kernel config
which my currently running kernel was built with.

> Hmm... just a thought: According to the page I mentioned in my first 
> mail the wifi did work in Ubuntu 8.04 which used kernel 2.6.24-16 till 
> 19 (again I used a wrong number in my first mail ^^). So the SDIO module 
> had to work, too. I will dig around in the source code of the module (I 
> downloaded the source from marvell) to find some useful information 
> about the SDIO controller. (So I think I answered my first question by 
> myself :) )

If it worked at one time, it may be a problem with the libertas driver,
but it would be good to know *exactly* what kernel, SDIO stack bits,
libertas driver, and libertas firmware it was working with.  That gives
us a baseline to figure out where things went wrong.

Dan

> 
> Regards,
> Sven
> 
> Dan Williams schrieb:
> > On Sat, 2009-01-24 at 12:53 +0100, Sven Barth wrote:
> >   
> >> Hello Dan!
> >>
> >> Thanks for your answer.
> >>
> >> Yes, I did indeed mean 2008. ^^
> >>
> >> The SDIO Controller seems to be a no-name one (at least if I found the 
> >> right one). I used "lspci -vvv"  and the output is attached.
> >> I also found some output about the SDIO controller in dmesg (see 
> >> attached file). Might the problems reported there be the source of the 
> >> timeout problems?
> >>     
> >
> > Certainly could be.  The controller has historically been the major
> > source of problems for people with the libertas driver so far.  The
> > kernel's SDIO stack is fairly clean and doesn't try to hack around bad
> > hardware a lot since it wasn't known quite how bad the hardware was at
> > the time it was written.  Some controllers actually do need PIO mode
> > instead of DMA mode, others can't actually do 4-bit transfers but claim
> > to be able to do so (which means they aren't actually spec compliant I
> > think), that sort of thing.  You may have to work around some of these
> > issues in the SDIO stack for your particular controller.
> >
> >   
> >> I also removed the part about TX_POWER from main.c, but now the module 
> >> hangs with CMD_MAC_CONTROL (0x0028) (another clue, that the source of 
> >> the problems is the SDIO controller?)
> >>     
> >
> > Yeah; it appears that the only command that actually works is
> > CMD_GET_HW_SPEC, all subsequent commands fail.  I know that the version
> > 8 firmware (which you're using as seen below) works fine with
> > CMD_MAC_CONTROL on Ricoh controllers, and others have had success with
> > it on other controllers too.  So I think at the moment, the controller
> > is suspect.
> >
> > Pierre: any thoughts on the stack messages and what might be going on
> > here?
> >
> > Dan
> >
> >   
> >> Thanks for your help.
> >>
> >> Regards,
> >> Sven
> >> plain text document attachment (dmesg-htc-shift-2)
> >> // I think this is about the SDIO Controller
> >> sdhci: Secure Digital Host Controller Interface driver
> >> sdhci: Copyright(c) Pierre Ossman
> >> sdhci-pci 0000:01:06.0: SDHCI controller found [1947:4743] (rev 9)
> >> sdhci-pci 0000:01:06.0: PCI INT A -> GSI 20 (level, low) -> IRQ 20
> >> sdhci-pci 0000:01:06.0: Invalid iomem size. You may experience problems.
> >> input: PC Speaker as /class/input/input7
> >> mmc0: Unknown controller version (17). You may experience problems.
> >> sdhci-pci 0000:01:06.0: Will use DMA mode even though HW doesn't fully claim to support it.
> >> mmc0: SDHCI controller on PCI [0000:01:06.0] using DMA
> >> sdhci-pci 0000:01:06.0: Invalid iomem size. You may experience problems.
> >> mmc1: Unknown controller version (17). You may experience problems.
> >> sdhci-pci 0000:01:06.0: Will use DMA mode even though HW doesn't fully claim to support it.
> >> mmc1: SDHCI controller on PCI [0000:01:06.0] using DMA
> >>
> >> // without TX_POWER cmd
> >> libertas_sdio: Libertas SDIO driver
> >> libertas_sdio: Copyright Pierre Ossman
> >> libertas_sdio mmc1:0001:1: firmware: requesting sd8686_helper.bin
> >> libertas_sdio mmc1:0001:1: firmware: requesting sd8686.bin
> >> libertas: f3cbdcce, fw 8.70.8p1, cap 0x00000303
> >> libertas: command 0x0028 timed out
> >> libertas: requeueing command 0x0028 due to timeout (#1)
> >> libertas: command 0x0028 timed out
> >> libertas: requeueing command 0x0028 due to timeout (#2)
> >> libertas: command 0x0028 timed out
> >> libertas: requeueing command 0x0028 due to timeout (#3)
> >> mmc1: Timeout waiting for hardware interrupt.
> >> sdhci: ============== REGISTER DUMP ==============
> >> sdhci: Sys addr: 0x33c2f488 | Version:  0x00000111
> >> sdhci: Blk size: 0x00007010 | Blk cnt:  0x00000001
> >> sdhci: Argument: 0x92000010 | Trn mode: 0x00000003
> >> sdhci: Present:  0x01f70506 | Host ctl: 0x00000003
> >> sdhci: Power:    0x0000000f | Blk gap:  0x00000000
> >> sdhci: Wake-up:  0x00000000 | Clock:    0x00000007
> >> sdhci: Timeout:  0x0000000c | Int stat: 0x00000000
> >> sdhci: Int enab: 0x00ff01fb | Sig enab: 0x00ff01fb
> >> sdhci: AC12 err: 0x00000000 | Slot int: 0x00000000
> >> sdhci: Caps:     0x01e011a1 | Max curr: 0x00000080
> >> sdhci: ===========================================
> >> libertas: command 0x0028 timed out
> >> libertas: Excessive timeouts submitting command 0x0028
> >> // modprobe libertas_sdio keeps hanging after "excessive timeouts" till I press Ctrl+c
> >> // this comes after I canceled modprobe
> >> libertas: eth0: Marvell WLAN 802.11 adapter
> >> plain text document attachment (lspci-sd-host)
> >> 01:06.0 SD Host controller: Device 1947:4743 (rev 09)
> >> 	Subsystem: Device 2211:4433
> >> 	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 (250ns min, 3000ns max), Cache Line Size: 32 bytes
> >> 	Interrupt: pin A routed to IRQ 20
> >> 	Region 0: Memory at fe8ffc00 (32-bit, non-prefetchable) [size=512]
> >> 	Region 1: Memory at fe8ff800 (32-bit, non-prefetchable) [size=512]
> >> 	Capabilities: [80] #00 [0000]
> >> 	Kernel driver in use: sdhci-pci
> >> 	Kernel modules: sdhci-pci
> >>
> >> _______________________________________________
> >> libertas-dev mailing list
> >> libertas-dev at lists.infradead.org
> >> http://lists.infradead.org/mailman/listinfo/libertas-dev
> >>     
> >
> >
> >   
>