RE: Audigy SE / ca0106 driver for PowerPC?

["Russell McGuire" <rmcguire@videopresence.com>]

All,

Well I figured out part of the problem, maybe we can figure out why this was
causing an issue??

On a hunch I changed the U-boot and Blob files, to be different on one of
the addresses for the PCI IO space.

-----OLD-----
#define CFG_PCI_IO_BASE		0x00000000
#define CFG_PCI_IO_PHYS		0xF0300000
#define CFG_PCI_IO_SIZE		0x00100000 /* 1M */

-----NEW-----
#define CFG_PCI_IO_BASE		0xF0300000  <--- CHANGED THIS
#define CFG_PCI_IO_PHYS		0xF0300000
#define CFG_PCI_IO_SIZE		0x00100000 /* 1M */


The system no longer locks up now, so it looks like the bus hang is fixed.

However, now the sound driver never exits the interrupt routine. So I have
to figure out why I am getting continuous interrupts.


-Russ
-----Original Message-----
From: Kumar Gala [mailto:galak@kernel.crashing.org] 
Sent: Wednesday, January 31, 2007 4:04 PM
To: rmcguire@videopresence.com
Subject: Re: Audigy SE / ca0106 driver for PowerPC?


On Jan 31, 2007, at 5:47 PM, Russell McGuire wrote:

>
> When Linux loads are there left over memory mappings in the PCI  
> from U-boot,
> Or does the PCI initializing in Linux reset these values, and just  
> place in
> what the BLOB contains?

Linux doesn't override the PCILAW* settings, it expects that the  
physical memory map is setup by the bootloader.

> I guess is it critical that the BLOB 100% match the U-boot  
> definitions,
> other than it being confusing to developers?

Yeah, I think about making it smarter.  The problem is being smart  
about it... For example in your setup, its uses one LAW to cover both  
PCI mem regions.

- k

> -----Original Message-----
> From: Kumar Gala [mailto:galak@kernel.crashing.org]
> Sent: Wednesday, January 31, 2007 2:40 PM
> To: rmcguire@videopresence.com
> Cc: linuxppc-embedded@ozlabs.org
> Subject: Re: Audigy SE / ca0106 driver for PowerPC?
>
>
> On Jan 31, 2007, at 4:27 PM, Russell McGuire wrote:
>
>> This makes sense...
>>
>> So if I have setup in U-boot the PCI IO space to be at 0xf0300000
>> and PCI
>> MOM space at 0x80000000 then the inl() command should be accessing  
>> the
>> 0xf0300000 space? And the frame buffer is accessing the 0x80000000.
>
> That's correct, however both of these will go through ioremap to get
> virtual addresses in the kernel.  For the IO space its done in the
> PCI setup code for the platform, and for MEM space its done by the
> driver.
>
>> The lock I experience, is when I compile the driver into the
>> kernel. During
>> the PCI Probing, I have turned on ALL of the debug output, as well
>> as placed
>> a ton of extra debug <printk> inside the ca0106 driver. I can see
>> clearly
>> the kernel detects I have a sound card, as does it detect the video
>> card.
>> Though I haven't gotten any PCI cards to function yet... The machine
>> literally just halts the boot cycle inside the first inl() command,
>> and just
>> sits here until the reset button is pressed. It feels much like an
>> illegal
>> access to a non-existant memory space <maybe that should be my clue
>> = bus
>> hang?>
>
> Ah, this we can debug :)
>
> In arch/powerpc/kernel/pci_32.c enable DEBUG in the file (change the
> #undef DEBUG to #define DEBUG).  At which you'll get some output of
> the form.
>
> Also, you can stick a few printk's in pci_process_bridge_OF_ranges
> ().  I'd suggest one before:
>
> 	hose->io_base_virt = ioremap(ranges[na+2], size);
>
>> Perhaps then my problem lies in the OF_BLOB I am passing in to
>> Linux? Could
>> this cause the problem? Is there a document someplace that
>> describes the
>> <reg structure> passed into the kernel on the OF_BLOB for the PCI
>> setup? I
>> made a good guess estimating this from other BLOB/dts files, but  
>> it is
>> possible I have some incorrect values.
>
> That would cause problems if not setup correctly.  Look at
> Documentation/powerpc/booting-without-of.txt, however a quick glance
> doesn't seem to cover PCI.
>
> You've given the start addresses for PCI MEM & PCI IO, can you tell
> me the sizes and I can help tell you want the node should look like.
>
> - k
>
>> -----Original Message-----
>> From: Kumar Gala [mailto:galak@kernel.crashing.org]
>> Sent: Wednesday, January 31, 2007 1:55 PM
>> To: rmcguire@videopresence.com
>> Cc: linuxppc-embedded@ozlabs.org
>> Subject: Re: Audigy SE / ca0106 driver for PowerPC?
>>
>>
>> On Jan 31, 2007, at 3:00 PM, Russell McGuire wrote:
>>
>>> I am using the Freescale MPC8360E, with U-boot 1.2.0.
>>> When I compile the kernel <2.6.20-rc6> I select the MPC8360E-MDS
>>> board.
>>> ARCH = PowerPC.
>>>
>>> Well I might be all confused on the IO Remap, but if I look through
>>> the
>>> nvidafb driver and the ati frame buffer driver I can see the
>>> resource_start() and pci_resource_len() function being called,
>>> followed by
>>> the ioremap() before any configuration is done with the PCI boards.
>>
>> The difference is the nvidafb driver isn't doing PCI IO but PCI mem
>> accesses (note, I didn't see any inl/outl references in the nvida
>> driver).
>>
>>> The ca0106 driver seems to miss this <ioremap> function, and it is
>>> the only
>>> one that 100% locks the system up during the PCI probing <that I  
>>> have
>>> tried>, and it happens after/during the very first inl() or outl()
>>> command.
>>
>> This may be because IO space is setup properly.
>>
>> When you say locks the system, what exactly happens?
>>
>>> I read a thread someplace that says that pci_resource_start() is not
>>> intended to return an actual address, but rather a token that is to
>>> be used
>>> by the ioremap() function? It just happens that on some systems
>>> this value
>>> is the same and so for some it will not fail with a missing ioremap
>>> (), but
>>> others it will not be. To be safe it must be passed through ioremap
>>> ()? This
>>> is the deprecated part, <right term? Perhaps just bad assumption is
>>> a better
>>> one> that this driver makes.
>>>
>>> After looking through more drivers, this ioremap seems 100% in
>>> place on my
>>> drivers. Maybe nobody has tested this with PowerPC in the past?
>>
>> ioremap() is intended for use with PCI MEM accesses not PCI IO.  If
>> you think about the fact that PCI IO is based on the x86 port IO
>> concept this makes sense.
>>
>>> See this thread as an example:
>>> http://linux.derkeiler.com/Mailing-Lists/Kernel/2003-09/1187.html
>>>
>>> Or see:
>>> /drivers/video/nvidia/nvidia.c lines 1239->1243
>>>
>>> Verses
>>>
>>> /sound/pci/ca0106/ca0106_main.c
>>> lines 1279 till the interrupt request
>>> then lines 1069->1089 at which it locks on inl()
>>>
>>> I don't mean to argue, I am just confused at this point.
>>
>> Its ok.  I don't thinking you're arguing, just trying to figure out
>> what's going on.
>>
>> - k
>