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:[EMAIL PROTECTED] Sent: Wednesday, January 31, 2007 4:04 PM To: [EMAIL PROTECTED] 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:[EMAIL PROTECTED] > Sent: Wednesday, January 31, 2007 2:40 PM > To: [EMAIL PROTECTED] > Cc: [email protected] > 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:[EMAIL PROTECTED] >> Sent: Wednesday, January 31, 2007 1:55 PM >> To: [EMAIL PROTECTED] >> Cc: [email protected] >> 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 > _______________________________________________ Linuxppc-embedded mailing list [email protected] https://ozlabs.org/mailman/listinfo/linuxppc-embedded
