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:
quoted
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.
quoted
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);
quoted
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
quoted
-----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:
quoted
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).
quoted
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?
quoted
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.
quoted
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
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@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:
quoted
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.
quoted
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
quoted
-----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:
quoted
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.
quoted
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);
quoted
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
quoted
-----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:
quoted
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).
quoted
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?
quoted
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.
quoted
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