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.
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?> 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. -Russ -----Original Message----- From: Kumar Gala [mailto:[EMAIL PROTECTED] Sent: Wednesday, January 31, 2007 1:55 PM To: [EMAIL PROTECTED] 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 _______________________________________________ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
