cardbus hdsp issue, advice or suggestions?

[Daniel Ritz]

hi

ok, before we go on:
fglrx: module license 'Proprietary. (C) 2002 - ATI Technologies, Starnberg, GERMANY' taints kernel.

you have to make sure that this module is _never_ loaded. debugging a kernel with
a proprietary loaded is just impossible. and it is highly probable that it's
this module causing the problems after all.

On Wednesday 15 March 2006 02.01, we are wrote:
> hey daniel,
> i tried your suggestion of the hexedits and there were a few slight
> changes in the quality of the noise but not enough to say its working.
> i did notice that the latency output of lspci -vvv on my cardbus
> (03:01:00) changed from 168 to 248
> 
> 

so you say it was that one that helped a bit?
	setpci -s 03:01.0 0x0d.b=0xfa
that one actually changed the latency timer.
the other one (disabling read prefetch) did not have any effect?

> here's the output of lspci -vvv on 03:01:00
> 
> 03:01.0 CardBus bridge: Ricoh Co Ltd RL5c476 II (rev b3)
>         Subsystem: ASUSTeK Computer Inc. V6800V
>         Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
> ParErr- Stepping- SERR- FastB2B-
>         Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort-
> <TAbort- <MAbort- >SERR- <PERR-
>         Latency: 248
>         Interrupt: pin A routed to IRQ 17
>         Region 0: Memory at fbf00000 (32-bit, non-prefetchable)
> [size=4K]
>         Bus: primary=03, secondary=04, subordinate=07, sec-latency=176
>         Memory window 0: 50000000-51fff000 (prefetchable)
>         Memory window 1: 54000000-55fff000
>         I/O window 0: 0000d000-0000d0ff
>         I/O window 1: 0000d400-0000d4ff
>         BridgeCtl: Parity+ SERR+ ISA- VGA- MAbort- >Reset- 16bInt-
> PostWrite+
>         16-bit legacy interface ports at 0001
> 
> 
> ----------------------------------------------------------------------------------------
> 
> in my last post i forgot to attach my dmesg(sorry i was a cafe running
> outta time) so here it is....
> 
> 
> the other thing i wanted to ask you about was about the hexediting. i
> have been trying to work out how you changed those values but i can't
> work out the code. could you please let me know how i can understand
> the changes you made and how they actually function.  i had a friend

the setpci command actually just tells the kernel by writing to
/proc/bus/pci/xx/yy.z. it's the same files lspci uses to display the bus
list. everything you write there is passed directly to the PCI device

> that said that hexediting can be unstable and troublesome, at this
> stage i have very few alternatives but i was just wondering if this is
> going to case troubles later?

well, it's perfectly possible to mess up everthing by writing random data
to the configuration registers. but it's no problem as long as you know
what you are doing :)

> 
> and again, any more suggestions most welcome.
> 

looking at this:
Hammerfall-DSP: wait for FIFO status <= 0 failed after 30 iterations
Hammerfall-DSP: cannot load firmware multiface_firmware_rev11.bin
Hammerfall-DSP: couldn't get firmware from userspace. try using hdsploader
Hammerfall-DSP: card initialization pending : waiting for firmware

it seems that the HDSP is not reacting correctly. it may be because some
other device sits on the same memory address (or that bloody ATI driver)
try adding
	reserve=0x50000000,0x20000000
this tells the kernel not to use half a gig of iomemory space so the
HDSP will end up being mapped to a different memory address.


i also looked at the register dumps again and found other differences
between linux and windows: linux does have a secondary latency of 176
while windows only has 64. now i don't think that lowering it will help,
but you never know:
	setpci -s 03:01.0 0x1b.b=0x40

> 
> thanks heaps
> 
> tom

rgds
-daniel