Audigy SE / ca0106 driver for PowerPC?

[Kumar Gala]

On Feb 1, 2007, at 3:00 AM, Russell McGuire wrote:

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

This really boggles me, maybe the processor is doing something  
different from what I've been expecting.

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

probably having issues with the interrupt routing in the Blob not  
being right if I where to guess, does the ISR actually get called?

- k

> -----Original Message-----
> From: Kumar Gala [mailto:galak at kernel.crashing.org]
> Sent: Wednesday, January 31, 2007 4:04 PM
> To: rmcguire at 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 at kernel.crashing.org]
>> Sent: Wednesday, January 31, 2007 2:40 PM
>> To: rmcguire at videopresence.com
>> Cc: linuxppc-embedded at 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 at kernel.crashing.org]
>>> Sent: Wednesday, January 31, 2007 1:55 PM
>>> To: rmcguire at videopresence.com
>>> Cc: linuxppc-embedded at 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
>>
>