Audigy SE / ca0106 driver for PowerPC?

Audigy SE / ca0106 driver for PowerPC?

[Russell McGuire]

All,

I recently tried to plugin and use an Audigy SE PCI card with 2.6.20 and
noticed that it would lock up during driver registration.

After a little digging, I found that the interrupt routine and a few other
functions are relying on the x86 inl() / outl() to read from the sound card.

Is anyone aware of a PPC port for this driver? Or if it would be feasible? I
haven't ported a driver between architectures before.

Or does the inl() / outl() already have PPC equivalent functions and I need
to be looking for a PCI configuration problem with my system?

-Russ

Re: Audigy SE / ca0106 driver for PowerPC?

[Kumar Gala]

On Jan 31, 2007, at 6:14 AM, Russell McGuire wrote:

> All,
>
> I recently tried to plugin and use an Audigy SE PCI card with  
> 2.6.20 and
> noticed that it would lock up during driver registration.
>
> After a little digging, I found that the interrupt routine and a  
> few other
> functions are relying on the x86 inl() / outl() to read from the  
> sound card.
>
> Is anyone aware of a PPC port for this driver? Or if it would be  
> feasible? I
> haven't ported a driver between architectures before.
>
> Or does the inl() / outl() already have PPC equivalent functions  
> and I need
> to be looking for a PCI configuration problem with my system?

We implement these on PPC.  Clearly we don't have x86 style port IO,  
usually its handled by memory mapped access to a special region of  
memory that will be converted into a PCI IO space access.

- k

RE: Audigy SE / ca0106 driver for PowerPC?

[Russell McGuire]

After comparing the driver methods to a couple of other PCI drivers that do
work on PowerPC <like the nvidia and ati stuff>, it looks like the methods
for accessing the PCI IO space are very depreciated in this driver..

Would it be safe to assume that if I were to modify the existing

chip->port = pci_resource_start(pcidev,0);
chip->res_port = request_region(chip->port, size);

outl(chip->port+MyReg, data);

To something like:

chip->port = pci_resource_start(pcidev,0);
snd_length = pci_resource_len(pcidev, 0);
snd_port = ioremap(chip->port, length);

outl(port+MyReg, data);

I am not sure if I want to leave the outl in there, perhaps a different
function, or just a direct assignment?

-Russ
-----Original Message-----
From: Kumar Gala [mailto:galak@kernel.crashing.org] 
Sent: Wednesday, January 31, 2007 6:53 AM
To: rmcguire@videopresence.com
Cc: linuxppc-embedded@ozlabs.org
Subject: Re: Audigy SE / ca0106 driver for PowerPC?


On Jan 31, 2007, at 6:14 AM, Russell McGuire wrote:

> All,
>
> I recently tried to plugin and use an Audigy SE PCI card with  
> 2.6.20 and
> noticed that it would lock up during driver registration.
>
> After a little digging, I found that the interrupt routine and a  
> few other
> functions are relying on the x86 inl() / outl() to read from the  
> sound card.
>
> Is anyone aware of a PPC port for this driver? Or if it would be  
> feasible? I
> haven't ported a driver between architectures before.
>
> Or does the inl() / outl() already have PPC equivalent functions  
> and I need
> to be looking for a PCI configuration problem with my system?

We implement these on PPC.  Clearly we don't have x86 style port IO,  
usually its handled by memory mapped access to a special region of  
memory that will be converted into a PCI IO space access.

- k

Re: Audigy SE / ca0106 driver for PowerPC?

[Kumar Gala]

On Jan 31, 2007, at 9:20 AM, Russell McGuire wrote:

> After comparing the driver methods to a couple of other PCI drivers  
> that do
> work on PowerPC <like the nvidia and ati stuff>, it looks like the  
> methods
> for accessing the PCI IO space are very depreciated in this driver..

Not sure I follow that comment, in*/out* have been the mechanisms to  
access PCI IO space for as long as I've know.

> Would it be safe to assume that if I were to modify the existing
>
> chip->port = pci_resource_start(pcidev,0);
> chip->res_port = request_region(chip->port, size);
>
> outl(chip->port+MyReg, data);
>
> To something like:
>
> chip->port = pci_resource_start(pcidev,0);
> snd_length = pci_resource_len(pcidev, 0);
> snd_port = ioremap(chip->port, length);
>
> outl(port+MyReg, data);
>
> I am not sure if I want to leave the outl in there, perhaps a  
> different
> function, or just a direct assignment?

You shouldn't have to do the ioremap, the PCI platform code should  
have already handled all of this.

What PPC platform are you on?

- k

RE: Audigy SE / ca0106 driver for PowerPC?

[Russell McGuire]

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

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?

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.



-Russ
-----Original Message-----
From: Kumar Gala [mailto:galak@kernel.crashing.org] 
Sent: Wednesday, January 31, 2007 7:34 AM
To: rmcguire@videopresence.com
Cc: linuxppc-embedded@ozlabs.org
Subject: Re: Audigy SE / ca0106 driver for PowerPC?


On Jan 31, 2007, at 9:20 AM, Russell McGuire wrote:

> After comparing the driver methods to a couple of other PCI drivers  
> that do
> work on PowerPC <like the nvidia and ati stuff>, it looks like the  
> methods
> for accessing the PCI IO space are very depreciated in this driver..

Not sure I follow that comment, in*/out* have been the mechanisms to  
access PCI IO space for as long as I've know.

> Would it be safe to assume that if I were to modify the existing
>
> chip->port = pci_resource_start(pcidev,0);
> chip->res_port = request_region(chip->port, size);
>
> outl(chip->port+MyReg, data);
>
> To something like:
>
> chip->port = pci_resource_start(pcidev,0);
> snd_length = pci_resource_len(pcidev, 0);
> snd_port = ioremap(chip->port, length);
>
> outl(port+MyReg, data);
>
> I am not sure if I want to leave the outl in there, perhaps a  
> different
> function, or just a direct assignment?

You shouldn't have to do the ioremap, the PCI platform code should  
have already handled all of this.

What PPC platform are you on?

- k

Re: Audigy SE / ca0106 driver for PowerPC?

[Kumar Gala]

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

RE: Audigy SE / ca0106 driver for PowerPC?

[Russell McGuire]

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

Re: Audigy SE / ca0106 driver for PowerPC?

[Kumar Gala]

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

RE: Audigy SE / ca0106 driver for PowerPC?

[Russell McGuire]

What I really don't know is what the first column in the ranges field does.
I.e. the <42000000>, <02000000>, and <01000000>.

Here is part of current blob I am using:

pci@8500 {
	linux,phandle = <8500>;
	interrupt-map-mask = <f800 0 0 7>;
	interrupt-map= <
 		/* IDSEL 0x19 AD25*/
		 c800 0 0 1 700 14 8
		 c800 0 0 2 700 15 8
		 c800 0 0 3 700 16 8
		 c800 0 0 4 700 17 8>; > //and a lot more like this
	bus-range = <0 0>; //U-boot modifies this to be <0 2> I think
	ranges = <42000000 0 80000000 80000000 0 10000000
		  02000000 0 90000000 90000000 0 10000000
		  01000000 0 00000000 f0300000 0 00100000>;
	clock-frequency = <3f940aa>;
	#interrupt-cells = <1>;
	#size-cells = <2>;
	#address-cells = <3>;
	reg = <8500 100>;
	compatible = "83xx";
	device_type = "pci";
}

Here are the U-boot #defines I am using at the moment.

#define CFG_PCI_MEM_BASE	0x80000000
#define CFG_PCI_MEM_PHYS	CFG_PCI_MEM_BASE
#define CFG_PCI_MEM_SIZE	0x10000000 /* 256M */
#define CFG_PCI_MMIO_BASE	0x90000000
#define CFG_PCI_MMIO_PHYS	CFG_PCI_MMIO_BASE
#define CFG_PCI_MMIO_SIZE	0x10000000 /* 256M */
#define CFG_PCI_IO_BASE		0x00000000
#define CFG_PCI_IO_PHYS		0xF0300000
#define CFG_PCI_IO_SIZE		0x00100000 /* 1M */
Might need to change PCI_IO_BASE to match PCI_IO_PHYS as well?

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

Re: Audigy SE / ca0106 driver for PowerPC?

[Kumar Gala]

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

>
> What I really don't know is what the first column in the ranges  
> field does.
> I.e. the <42000000>, <02000000>, and <01000000>.

They are encoding of type of "space" is being described, the first  
byte's what's important:

[42]	- prefetchable memory
[02]	- 32-bit memory space
[01]	- IO space

[00]	- CFG space
[03]	- 64-bit memory space

> Here is part of current blob I am using:
>
> pci@8500 {
> 	linux,phandle = <8500>;
> 	interrupt-map-mask = <f800 0 0 7>;
> 	interrupt-map= <
>  		/* IDSEL 0x19 AD25*/
> 		 c800 0 0 1 700 14 8
> 		 c800 0 0 2 700 15 8
> 		 c800 0 0 3 700 16 8
> 		 c800 0 0 4 700 17 8>; > //and a lot more like this
> 	bus-range = <0 0>; //U-boot modifies this to be <0 2> I think
> 	ranges = <42000000 0 80000000 80000000 0 10000000
> 		  02000000 0 90000000 90000000 0 10000000
> 		  01000000 0 00000000 f0300000 0 00100000>;
> 	clock-frequency = <3f940aa>;
> 	#interrupt-cells = <1>;
> 	#size-cells = <2>;
> 	#address-cells = <3>;
> 	reg = <8500 100>;
> 	compatible = "83xx";
> 	device_type = "pci";
> }
>
> Here are the U-boot #defines I am using at the moment.
>
> #define CFG_PCI_MEM_BASE	0x80000000
> #define CFG_PCI_MEM_PHYS	CFG_PCI_MEM_BASE
> #define CFG_PCI_MEM_SIZE	0x10000000 /* 256M */
> #define CFG_PCI_MMIO_BASE	0x90000000
> #define CFG_PCI_MMIO_PHYS	CFG_PCI_MMIO_BASE
> #define CFG_PCI_MMIO_SIZE	0x10000000 /* 256M */
> #define CFG_PCI_IO_BASE		0x00000000
> #define CFG_PCI_IO_PHYS		0xF0300000
> #define CFG_PCI_IO_SIZE		0x00100000 /* 1M */
> Might need to change PCI_IO_BASE to match PCI_IO_PHYS as well?

This all looks correct, how are you setting PCILAWBAR0/1, PCILAWAR0/1?

- k

RE: Audigy SE / ca0106 driver for PowerPC?

[Russell McGuire]

/* Configure PCI Local Access Windows  */
pci_law[0].bar = CFG_PCI_MEM_PHYS & LAWBAR_BAR;
pci_law[0].ar = LAWAR_EN | LAWAR_SIZE_512M;

pci_law[1].bar = CFG_PCI_IO_PHYS & LAWBAR_BAR;
pci_law[1].ar = LAWAR_EN | LAWAR_SIZE_1M;

-Russ

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


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

>
> What I really don't know is what the first column in the ranges  
> field does.
> I.e. the <42000000>, <02000000>, and <01000000>.

They are encoding of type of "space" is being described, the first  
byte's what's important:

[42]	- prefetchable memory
[02]	- 32-bit memory space
[01]	- IO space

[00]	- CFG space
[03]	- 64-bit memory space

> Here is part of current blob I am using:
>
> pci@8500 {
> 	linux,phandle = <8500>;
> 	interrupt-map-mask = <f800 0 0 7>;
> 	interrupt-map= <
>  		/* IDSEL 0x19 AD25*/
> 		 c800 0 0 1 700 14 8
> 		 c800 0 0 2 700 15 8
> 		 c800 0 0 3 700 16 8
> 		 c800 0 0 4 700 17 8>; > //and a lot more like this
> 	bus-range = <0 0>; //U-boot modifies this to be <0 2> I think
> 	ranges = <42000000 0 80000000 80000000 0 10000000
> 		  02000000 0 90000000 90000000 0 10000000
> 		  01000000 0 00000000 f0300000 0 00100000>;
> 	clock-frequency = <3f940aa>;
> 	#interrupt-cells = <1>;
> 	#size-cells = <2>;
> 	#address-cells = <3>;
> 	reg = <8500 100>;
> 	compatible = "83xx";
> 	device_type = "pci";
> }
>
> Here are the U-boot #defines I am using at the moment.
>
> #define CFG_PCI_MEM_BASE	0x80000000
> #define CFG_PCI_MEM_PHYS	CFG_PCI_MEM_BASE
> #define CFG_PCI_MEM_SIZE	0x10000000 /* 256M */
> #define CFG_PCI_MMIO_BASE	0x90000000
> #define CFG_PCI_MMIO_PHYS	CFG_PCI_MMIO_BASE
> #define CFG_PCI_MMIO_SIZE	0x10000000 /* 256M */
> #define CFG_PCI_IO_BASE		0x00000000
> #define CFG_PCI_IO_PHYS		0xF0300000
> #define CFG_PCI_IO_SIZE		0x00100000 /* 1M */
> Might need to change PCI_IO_BASE to match PCI_IO_PHYS as well?

This all looks correct, how are you setting PCILAWBAR0/1, PCILAWAR0/1?

- k

Re: Audigy SE / ca0106 driver for PowerPC?

[Kumar Gala]

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

>
>
> /* Configure PCI Local Access Windows  */
> pci_law[0].bar = CFG_PCI_MEM_PHYS & LAWBAR_BAR;
> pci_law[0].ar = LAWAR_EN | LAWAR_SIZE_512M;
>
> pci_law[1].bar = CFG_PCI_IO_PHYS & LAWBAR_BAR;
> pci_law[1].ar = LAWAR_EN | LAWAR_SIZE_1M;

Well, you're making life difficult, not sure what's wrong :)

At this point I'd suggest adding a printk before the ioremap as I  
mentioned before, as well turning on the DEBUG and report the output.

It seems like the HW is setup properly, lets see if the address  
you're trying to access is valid or not.

The other place to put a printk is before the first inl().

Do something like printk("about to do inl for port:%x base:%p\n",  
(port based to inl), _IO_BASE);

- k

-----Original Message-----
> From: Kumar Gala [mailto:galak@kernel.crashing.org]
> Sent: Wednesday, January 31, 2007 3:19 PM
> To: rmcguire@videopresence.com
> Cc: linuxppc-embedded@ozlabs.org
> Subject: Re: Audigy SE / ca0106 driver for PowerPC?
>
>
> On Jan 31, 2007, at 5:01 PM, Russell McGuire wrote:
>
>>
>> What I really don't know is what the first column in the ranges
>> field does.
>> I.e. the <42000000>, <02000000>, and <01000000>.
>
> They are encoding of type of "space" is being described, the first
> byte's what's important:
>
> [42]	- prefetchable memory
> [02]	- 32-bit memory space
> [01]	- IO space
>
> [00]	- CFG space
> [03]	- 64-bit memory space
>
>> Here is part of current blob I am using:
>>
>> pci@8500 {
>> 	linux,phandle = <8500>;
>> 	interrupt-map-mask = <f800 0 0 7>;
>> 	interrupt-map= <
>>  		/* IDSEL 0x19 AD25*/
>> 		 c800 0 0 1 700 14 8
>> 		 c800 0 0 2 700 15 8
>> 		 c800 0 0 3 700 16 8
>> 		 c800 0 0 4 700 17 8>; > //and a lot more like this
>> 	bus-range = <0 0>; //U-boot modifies this to be <0 2> I think
>> 	ranges = <42000000 0 80000000 80000000 0 10000000
>> 		  02000000 0 90000000 90000000 0 10000000
>> 		  01000000 0 00000000 f0300000 0 00100000>;
>> 	clock-frequency = <3f940aa>;
>> 	#interrupt-cells = <1>;
>> 	#size-cells = <2>;
>> 	#address-cells = <3>;
>> 	reg = <8500 100>;
>> 	compatible = "83xx";
>> 	device_type = "pci";
>> }
>>
>> Here are the U-boot #defines I am using at the moment.
>>
>> #define CFG_PCI_MEM_BASE	0x80000000
>> #define CFG_PCI_MEM_PHYS	CFG_PCI_MEM_BASE
>> #define CFG_PCI_MEM_SIZE	0x10000000 /* 256M */
>> #define CFG_PCI_MMIO_BASE	0x90000000
>> #define CFG_PCI_MMIO_PHYS	CFG_PCI_MMIO_BASE
>> #define CFG_PCI_MMIO_SIZE	0x10000000 /* 256M */
>> #define CFG_PCI_IO_BASE		0x00000000
>> #define CFG_PCI_IO_PHYS		0xF0300000
>> #define CFG_PCI_IO_SIZE		0x00100000 /* 1M */
>> Might need to change PCI_IO_BASE to match PCI_IO_PHYS as well?
>
> This all looks correct, how are you setting PCILAWBAR0/1, PCILAWAR0/1?
>
> - k
>

RE: Audigy SE / ca0106 driver for PowerPC?

[Russell McGuire]

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
>

Re: 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@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
>>
>

8360E - PCI / DTC Blob Setup

[Russell McGuire]

Since I am hip deep in debugging the PCI system.

In the .dts files there is the section for the PCI setup.

The interrupt-map = < > 

Does this need to include:
1) A mapping for every IDSEL line in the system?
2) Only those IDSELs that are used on the slots on the motherboard?
3) A custom entry for every card we want to support?
4) How does a bridge chip and slave busses affect the entries, if at all?

Looking at the mpc8360 / 8349 setups that are part of the latest kernel
trees, some are place many and some are placing just a single entry?

Which should be the preferred method?

-Russ

Re: 8360E - PCI / DTC Blob Setup

[Kumar Gala]

On Feb 1, 2007, at 8:27 AM, Russell McGuire wrote:

> Since I am hip deep in debugging the PCI system.
>
> In the .dts files there is the section for the PCI setup.
>
> The interrupt-map = < >
>
> Does this need to include:
> 1) A mapping for every IDSEL line in the system?
> 2) Only those IDSELs that are used on the slots on the motherboard?

I'm not sure I follow the difference between 1/2. The map needs to  
cover every IDSEL that has an IRQ line wired to it.

> 3) A custom entry for every card we want to support?

See above.

> 4) How does a bridge chip and slave busses affect the entries, if  
> at all?

Uugh, I'm not sure how bridges are handled at this point.

> Looking at the mpc8360 / 8349 setups that are part of the latest  
> kernel
> trees, some are place many and some are placing just a single entry?
>
> Which should be the preferred method?

It depends on your HW setup, the 8360/49 boards have some 'odd' IDSEL  
irq mapping.

- k

RE: 8360E - PCI / DTC Blob Setup

[Russell McGuire]

This might be the wrong forum to discuss HW routing, but I am not sure of
many HW guys that would understand blob setups. I know I still don't.

I read through the booting-without-of-tree.txt and it doesn't explain this
other than the interrupt routing needs to be present. Perhaps some of the
maintainers of the 83xx platforms can explain how this blob is developed?
I assume their board work with the submitted mp38360emds.dts files, as an
example.

Let me see if I can simplify this, I had this schematic reviewed by Pericom
<a PCI bridge MFG> and they recommended these IDSEL lines. And I know the
card detection works great, in U-boot.

My external PCI bridge is the only thing routed directly to the 8360 Host
bridge. The PCI Host bridge in my system is connected on IDSEL->AD25,0x19
Perhaps I shouldn't use any interrupt routing for this, as there is no true
/INTA line tied directly to the bridge?

My Three PCI slots are routed as follows:

Bus 0, Bridge Chip, IDSEL = AD25

Other side of the Host bridge, all are routed to INTA directly to the 
CPU.
Bus 1, Slot 1, IDSEL = AD20 <card would be ID'd as 1.04 (Bus.Dev)>
Bus 1, Slot 2, IDSEL = AD24 <card would be ID'd as 1.08 (Bus.Dev)>
Bus 2, Slot 1, IDSEL = AD20 <card would be ID'd as 2.04 (Bus.Dev)>

That being said:
/* IDSEL 0x19 AD25*/
 c800 0 0 1 700 14 8

I see in the c800 directly corresponds to the 83xx manual for PCI CONFIG
address mapping for AD25.

I think the '1' is mapped to /INTA, which is the only PCI INT available in
the 8360E.

I understand the 700 in this case is the address of the PIC@700.

That leaves 5 fields/questions.
1) What do the first two '0's after c800 mean?
2) What does the '14' map to?
3) What does the '8' map to?
4) Why would some boards map multiple interrupts to a single IDSEL, like the
mpc8360emds.dts file? Is this to handle extra bridges that might be plugged
in at a later time?

If I understand the mapping correctly then I think I can hard code in the
interrupts for the PCI slots.

So I don't drive everybody nuts, is there actual documentation on this. I
would be happy to stop spamming this list... :-)

-Russ
-----Original Message-----
From: Kumar Gala [mailto:galak@kernel.crashing.org] 
Sent: Thursday, February 01, 2007 6:33 AM
To: rmcguire@videopresence.com
Cc: linuxppc-embedded@ozlabs.org
Subject: Re: 8360E - PCI / DTC Blob Setup


On Feb 1, 2007, at 8:27 AM, Russell McGuire wrote:

> Since I am hip deep in debugging the PCI system.
>
> In the .dts files there is the section for the PCI setup.
>
> The interrupt-map = < >
>
> Does this need to include:
> 1) A mapping for every IDSEL line in the system?
> 2) Only those IDSELs that are used on the slots on the motherboard?

I'm not sure I follow the difference between 1/2. The map needs to  
cover every IDSEL that has an IRQ line wired to it.

> 3) A custom entry for every card we want to support?

See above.

> 4) How does a bridge chip and slave busses affect the entries, if  
> at all?

Uugh, I'm not sure how bridges are handled at this point.

> Looking at the mpc8360 / 8349 setups that are part of the latest  
> kernel
> trees, some are place many and some are placing just a single entry?
>
> Which should be the preferred method?

It depends on your HW setup, the 8360/49 boards have some 'odd' IDSEL  
irq mapping.

- k

Re: 8360E - PCI / DTC Blob Setup

[Kumar Gala]

On Feb 1, 2007, at 11:48 AM, Russell McGuire wrote:

> This might be the wrong forum to discuss HW routing, but I am not  
> sure of
> many HW guys that would understand blob setups. I know I still don't.
>
> I read through the booting-without-of-tree.txt and it doesn't  
> explain this
> other than the interrupt routing needs to be present. Perhaps some  
> of the
> maintainers of the 83xx platforms can explain how this blob is  
> developed?
> I assume their board work with the submitted mp38360emds.dts files,  
> as an
> example.
>
> Let me see if I can simplify this, I had this schematic reviewed by  
> Pericom
> <a PCI bridge MFG> and they recommended these IDSEL lines. And I  
> know the
> card detection works great, in U-boot.
>
> My external PCI bridge is the only thing routed directly to the  
> 8360 Host
> bridge. The PCI Host bridge in my system is connected on IDSEL- 
> >AD25,0x19
> Perhaps I shouldn't use any interrupt routing for this, as there is  
> no true
> /INTA line tied directly to the bridge?
>
> My Three PCI slots are routed as follows:
>
> Bus 0, Bridge Chip, IDSEL = AD25

Huh, this is only describes one slot/connection.  If you have 3  
slots, they'd have 3 unique IDSELs

> Other side of the Host bridge, all are routed to INTA directly to the
> CPU.
> Bus 1, Slot 1, IDSEL = AD20 <card would be ID'd as 1.04 (Bus.Dev)>
> Bus 1, Slot 2, IDSEL = AD24 <card would be ID'd as 1.08 (Bus.Dev)>
> Bus 2, Slot 1, IDSEL = AD20 <card would be ID'd as 2.04 (Bus.Dev)>
>
> That being said:
> /* IDSEL 0x19 AD25*/
>  c800 0 0 1 700 14 8

so the way you read this:

<PCI DEV specifier> <INT A-D> <HOST IRQ specifier>

Do break it down further:

<PCI DEV specifier>:

[(bus << 16) | (idsel << 11)] 0 0

<INT A-D>:
INTA - 1
INTB - 2
INTC - 3
INTD - 4

<HOST IRQ specifier> (on 83xx):

[linux,phandle for interrupt controller] [IRQ #] [sense]

> I see in the c800 directly corresponds to the 83xx manual for PCI  
> CONFIG
> address mapping for AD25.
>
> I think the '1' is mapped to /INTA, which is the only PCI INT  
> available in
> the 8360E.

INTA..INTD is more about the device, not host.

> I understand the 700 in this case is the address of the PIC@700.
>
> That leaves 5 fields/questions.
> 1) What do the first two '0's after c800 mean?

There always 0 0, since the int masks them away (they normally  
describe the address the device is at)

> 2) What does the '14' map to?

0x14 is the external IRQ # its wired to.

> 3) What does the '8' map to?

Sense of IRQ, should always be level for PCI.

> 4) Why would some boards map multiple interrupts to a single IDSEL,  
> like the
> mpc8360emds.dts file? Is this to handle extra bridges that might be  
> plugged
> in at a later time?

This is to handle the fact that a PCI add on card put into a slot  
might use multiple interrupts (INTA, INTB), so it lists multiple  
entries to cover the 4 PCI defined interrupts.

> If I understand the mapping correctly then I think I can hard code  
> in the
> interrupts for the PCI slots.
>
> So I don't drive everybody nuts, is there actual documentation on  
> this. I
> would be happy to stop spamming this list... :-)

There is, but its scattered in places.

Its good to ask these questions so the answers will get archived and  
other people can figure it out as well.

- k

RE: 8360E - PCI / DTC Blob Setup

[Russell McGuire]

Kumar,

THANK you, for pointing me in the right direction. I might have scratched my
head another 10 years finding this bug. And an apology for thinking I had a
software issue, when it was a hardware issue.

This is helping me greatly, all the while I had this sinking feeling, like I
didn't route any 'incoming' interrupt lines to the CPU. Something about the
8360 being able to get configured as an agent device, so I over looked the
use of the INTA pin on the CPU as incoming vs outgoing.

SO it would seem I didn't have ANY incoming pins, and thus the IRQ4-7 pins
that occur in the 8360E-MDS board were floating on my board. So as soon as
the sound driver enabled the interrupt, it was low all the time.

><HOST IRQ specifier> (on 83xx):>
>
>[linux,phandle for interrupt controller] [IRQ #] [sense]

I assume all these numbers are in HEX, So 0x14, 0x 15, 0x 16, 0x 17 would
correspond to external IRQ4-7 in the MPC8360E. I will wire this up and give
it a shot, guess it works better when they are connected.

><PCI DEV specifier>:
>
>[(bus << 16) | (idsel << 11)] 0 0

Well I think this is definitely part of my problem.
So I am mapping interrupts from bus 1 and 2, I would need something like?
Alternating the 14,15,16,17 to make a 'load-balanced' mapping? Are the bus 

> Bus 1, Slot 1, IDSEL = AD20 
1a000 0 0 1 700 14 8
1a000 0 0 1 700 15 8
1a000 0 0 1 700 16 8
1a000 0 0 1 700 17 8
> Bus 1, Slot 2, IDSEL = AD24 
1c000 0 0 1 700 15 8
1c000 0 0 1 700 16 8
1c000 0 0 1 700 17 8
1c000 0 0 1 700 18 8
> Bus 2, Slot 1, IDSEL = AD20 
2a000 0 0 1 700 16 8
2a000 0 0 1 700 17 8
2a000 0 0 1 700 18 8
2a000 0 0 1 700 19 8

-Russ
-----Original Message-----
From: Kumar Gala [mailto:galak@kernel.crashing.org] 
Sent: Thursday, February 01, 2007 10:11 AM
To: rmcguire@videopresence.com
Cc: linuxppc-embedded@ozlabs.org
Subject: Re: 8360E - PCI / DTC Blob Setup


On Feb 1, 2007, at 11:48 AM, Russell McGuire wrote:

> This might be the wrong forum to discuss HW routing, but I am not  
> sure of
> many HW guys that would understand blob setups. I know I still don't.
>
> I read through the booting-without-of-tree.txt and it doesn't  
> explain this
> other than the interrupt routing needs to be present. Perhaps some  
> of the
> maintainers of the 83xx platforms can explain how this blob is  
> developed?
> I assume their board work with the submitted mp38360emds.dts files,  
> as an
> example.
>
> Let me see if I can simplify this, I had this schematic reviewed by  
> Pericom
> <a PCI bridge MFG> and they recommended these IDSEL lines. And I  
> know the
> card detection works great, in U-boot.
>
> My external PCI bridge is the only thing routed directly to the  
> 8360 Host
> bridge. The PCI Host bridge in my system is connected on IDSEL- 
> >AD25,0x19
> Perhaps I shouldn't use any interrupt routing for this, as there is  
> no true
> /INTA line tied directly to the bridge?
>
> My Three PCI slots are routed as follows:
>
> Bus 0, Bridge Chip, IDSEL = AD25

Huh, this is only describes one slot/connection.  If you have 3  
slots, they'd have 3 unique IDSELs

> Other side of the Host bridge, all are routed to INTA directly to the
> CPU.
> Bus 1, Slot 1, IDSEL = AD20 <card would be ID'd as 1.04 (Bus.Dev)>
> Bus 1, Slot 2, IDSEL = AD24 <card would be ID'd as 1.08 (Bus.Dev)>
> Bus 2, Slot 1, IDSEL = AD20 <card would be ID'd as 2.04 (Bus.Dev)>
>
> That being said:
> /* IDSEL 0x19 AD25*/
>  c800 0 0 1 700 14 8

so the way you read this:

<PCI DEV specifier> <INT A-D> <HOST IRQ specifier>

Do break it down further:

<PCI DEV specifier>:

[(bus << 16) | (idsel << 11)] 0 0

<INT A-D>:
INTA - 1
INTB - 2
INTC - 3
INTD - 4

<HOST IRQ specifier> (on 83xx):

[linux,phandle for interrupt controller] [IRQ #] [sense]

> I see in the c800 directly corresponds to the 83xx manual for PCI  
> CONFIG
> address mapping for AD25.
>
> I think the '1' is mapped to /INTA, which is the only PCI INT  
> available in
> the 8360E.

INTA..INTD is more about the device, not host.

> I understand the 700 in this case is the address of the PIC@700.
>
> That leaves 5 fields/questions.
> 1) What do the first two '0's after c800 mean?

There always 0 0, since the int masks them away (they normally  
describe the address the device is at)

> 2) What does the '14' map to?

0x14 is the external IRQ # its wired to.

> 3) What does the '8' map to?

Sense of IRQ, should always be level for PCI.

> 4) Why would some boards map multiple interrupts to a single IDSEL,  
> like the
> mpc8360emds.dts file? Is this to handle extra bridges that might be  
> plugged
> in at a later time?

This is to handle the fact that a PCI add on card put into a slot  
might use multiple interrupts (INTA, INTB), so it lists multiple  
entries to cover the 4 PCI defined interrupts.

> If I understand the mapping correctly then I think I can hard code  
> in the
> interrupts for the PCI slots.
>
> So I don't drive everybody nuts, is there actual documentation on  
> this. I
> would be happy to stop spamming this list... :-)

There is, but its scattered in places.

Its good to ask these questions so the answers will get archived and  
other people can figure it out as well.

- k

Re: 8360E - PCI / DTC Blob Setup

[Kumar Gala]

On Feb 1, 2007, at 8:49 PM, Russell McGuire wrote:

> Kumar,
>
> THANK you, for pointing me in the right direction. I might have  
> scratched my
> head another 10 years finding this bug. And an apology for thinking  
> I had a
> software issue, when it was a hardware issue.

No problem, this pretty much comes out of the PCI OF spec, but it  
takes a while to grok how we actually use it.

> This is helping me greatly, all the while I had this sinking  
> feeling, like I
> didn't route any 'incoming' interrupt lines to the CPU. Something  
> about the
> 8360 being able to get configured as an agent device, so I over  
> looked the
> use of the INTA pin on the CPU as incoming vs outgoing.
>
> SO it would seem I didn't have ANY incoming pins, and thus the  
> IRQ4-7 pins
> that occur in the 8360E-MDS board were floating on my board. So as  
> soon as
> the sound driver enabled the interrupt, it was low all the time.

That would definitely be a HW issue :)

>> <HOST IRQ specifier> (on 83xx):>
>>
>> [linux,phandle for interrupt controller] [IRQ #] [sense]
>
> I assume all these numbers are in HEX, So 0x14, 0x 15, 0x 16, 0x 17  
> would
> correspond to external IRQ4-7 in the MPC8360E. I will wire this up  
> and give
> it a shot, guess it works better when they are connected.

Yeah all numbers are hex, I forget if you can put a leading 0x or  
not.. its kinda annoying.

>> <PCI DEV specifier>:
>>
>> [(bus << 16) | (idsel << 11)] 0 0
>
> Well I think this is definitely part of my problem.
> So I am mapping interrupts from bus 1 and 2, I would need something  
> like?

Truthfully you should probably have child nodes that describe the  
bridges and have their interrupt mappings described there.

The code is going to end up using the Bus #, IDSEL for the pci device  
to try and determine the CPU ext interrupt its mapped to.

Unfortunately, we don't really have an example of this.

> Alternating the 14,15,16,17 to make a 'load-balanced' mapping? Are  
> the bus

not following the question.

>
>> Bus 1, Slot 1, IDSEL = AD20
> 1a000 0 0 1 700 14 8
> 1a000 0 0 1 700 15 8
> 1a000 0 0 1 700 16 8
> 1a000 0 0 1 700 17 8
>> Bus 1, Slot 2, IDSEL = AD24
> 1c000 0 0 1 700 15 8
> 1c000 0 0 1 700 16 8
> 1c000 0 0 1 700 17 8
> 1c000 0 0 1 700 18 8
>> Bus 2, Slot 1, IDSEL = AD20
> 2a000 0 0 1 700 16 8
> 2a000 0 0 1 700 17 8
> 2a000 0 0 1 700 18 8
> 2a000 0 0 1 700 19 8
>
> -Russ
> -----Original Message-----
> From: Kumar Gala [mailto:galak@kernel.crashing.org]
> Sent: Thursday, February 01, 2007 10:11 AM
> To: rmcguire@videopresence.com
> Cc: linuxppc-embedded@ozlabs.org
> Subject: Re: 8360E - PCI / DTC Blob Setup
>
>
> On Feb 1, 2007, at 11:48 AM, Russell McGuire wrote:
>
>> This might be the wrong forum to discuss HW routing, but I am not
>> sure of
>> many HW guys that would understand blob setups. I know I still don't.
>>
>> I read through the booting-without-of-tree.txt and it doesn't
>> explain this
>> other than the interrupt routing needs to be present. Perhaps some
>> of the
>> maintainers of the 83xx platforms can explain how this blob is
>> developed?
>> I assume their board work with the submitted mp38360emds.dts files,
>> as an
>> example.
>>
>> Let me see if I can simplify this, I had this schematic reviewed by
>> Pericom
>> <a PCI bridge MFG> and they recommended these IDSEL lines. And I
>> know the
>> card detection works great, in U-boot.
>>
>> My external PCI bridge is the only thing routed directly to the
>> 8360 Host
>> bridge. The PCI Host bridge in my system is connected on IDSEL-
>>> AD25,0x19
>> Perhaps I shouldn't use any interrupt routing for this, as there is
>> no true
>> /INTA line tied directly to the bridge?
>>
>> My Three PCI slots are routed as follows:
>>
>> Bus 0, Bridge Chip, IDSEL = AD25
>
> Huh, this is only describes one slot/connection.  If you have 3
> slots, they'd have 3 unique IDSELs
>
>> Other side of the Host bridge, all are routed to INTA directly to the
>> CPU.
>> Bus 1, Slot 1, IDSEL = AD20 <card would be ID'd as 1.04 (Bus.Dev)>
>> Bus 1, Slot 2, IDSEL = AD24 <card would be ID'd as 1.08 (Bus.Dev)>
>> Bus 2, Slot 1, IDSEL = AD20 <card would be ID'd as 2.04 (Bus.Dev)>
>>
>> That being said:
>> /* IDSEL 0x19 AD25*/
>>  c800 0 0 1 700 14 8
>
> so the way you read this:
>
> <PCI DEV specifier> <INT A-D> <HOST IRQ specifier>
>
> Do break it down further:
>
> <PCI DEV specifier>:
>
> [(bus << 16) | (idsel << 11)] 0 0
>
> <INT A-D>:
> INTA - 1
> INTB - 2
> INTC - 3
> INTD - 4
>
> <HOST IRQ specifier> (on 83xx):
>
> [linux,phandle for interrupt controller] [IRQ #] [sense]
>
>> I see in the c800 directly corresponds to the 83xx manual for PCI
>> CONFIG
>> address mapping for AD25.
>>
>> I think the '1' is mapped to /INTA, which is the only PCI INT
>> available in
>> the 8360E.
>
> INTA..INTD is more about the device, not host.
>
>> I understand the 700 in this case is the address of the PIC@700.
>>
>> That leaves 5 fields/questions.
>> 1) What do the first two '0's after c800 mean?
>
> There always 0 0, since the int masks them away (they normally
> describe the address the device is at)
>
>> 2) What does the '14' map to?
>
> 0x14 is the external IRQ # its wired to.
>
>> 3) What does the '8' map to?
>
> Sense of IRQ, should always be level for PCI.
>
>> 4) Why would some boards map multiple interrupts to a single IDSEL,
>> like the
>> mpc8360emds.dts file? Is this to handle extra bridges that might be
>> plugged
>> in at a later time?
>
> This is to handle the fact that a PCI add on card put into a slot
> might use multiple interrupts (INTA, INTB), so it lists multiple
> entries to cover the 4 PCI defined interrupts.
>
>> If I understand the mapping correctly then I think I can hard code
>> in the
>> interrupts for the PCI slots.
>>
>> So I don't drive everybody nuts, is there actual documentation on
>> this. I
>> would be happy to stop spamming this list... :-)
>
> There is, but its scattered in places.
>
> Its good to ask these questions so the answers will get archived and
> other people can figure it out as well.
>
> - k

RE: 8360E - PCI / DTC Blob Setup

[Russell McGuire]

Well I am getting smarter on this:

I have read through the PCI Bridge Specs and found another issue that might
have been causing a problem with the IDSEL lines. Unless you are interested
I'll forgo that explanation and just go with fact that I have changed the
IDSEL mappings to be legal when they are issued from the 83xx.

I have changed the IDSELs to be as follows, does this look correct?
I agree with placing the NODE for the bridge into the dts file to be
correct. Except I get stuck immediately at trying to come up with an
address. I.e. the PCI host has a PCI@8500, which makes sense. But the Bridge
chip doesn't have a mapped address to place in the file. I did read the PCI
OF node spec <dated 1996> it hints that PCI-PCI bridges are essentially the
same domain and may not need translation.

Another concern I have now is that the interrupt mask may be incorrect.
i.e. currently it is <f800 0 0 7>, should I change this to <3f800 0 0 7>
since I am using an extra 2 bits to indicate bus? This would make sense if
the ((Bus << 16) | Dev << 11))

>> Bus 1, Slot 1, (Bridge IDSEL = AD27 mapped to IDSEL AD11 on host)
> 15800 0 0 1 700 14 8 //Int A always to IRQ 20
> 15800 0 0 2 700 15 8 //Int B always to IRQ 21
> 15800 0 0 3 700 16 8 //Int C always to IRQ 22
> 15800 0 0 4 700 17 8 //Int D always to IRQ 23
>> Bus 1, Slot 2, (Bridge IDSEL = AD30 mapped to IDSEL AD13 on host)
> 17000 0 0 1 700 14 8
> 17000 0 0 2 700 15 8
> 17000 0 0 3 700 16 8
> 17000 0 0 4 700 17 8
>> Bus 2, Slot 1, (Bridge IDSEL = AD27 mapped to IDSEL AD11 on host)
> 25800 0 0 1 700 14 8
> 25800 0 0 2 700 15 8
> 25800 0 0 3 700 16 8
> 25800 0 0 4 700 17 8

These IDSEL mappings seem to match exactly what U-boot will report
i.e. Bus.Dev = 1.0b, 1.0e, 2.0b. 

I have not placed any reference to the Bridge chip's IDSEL line, since it
cannot activate any IRQ lines directly. Well try it both ways perhaps and
see what happens.

The good news is with this configuration, the ca0106 driver will load. I can
get all the way into linux, and see the associated creations under the
/proc/ file system. To me all this really proves to me is that the IRQ
hasn't been toggled. Now I have to figure out how to get the /dev/dsp
devices in the /dev directory. If ALSA still uses this, I am used to OSS.

I am trying a PCI USB 2.0 card now, with various drivers and devices plugged
in I get varying results from 'try irqpoll' to boot hanging. Not sure if
this is an IRQ problem or a another related PCI bug.

What fun this is.

-Russ

-----Original Message-----
From: Kumar Gala [mailto:galak@kernel.crashing.org] 
Sent: Thursday, February 01, 2007 10:21 PM
To: rmcguire@videopresence.com
Cc: linuxppc-embedded@ozlabs.org ((((E-Mail)))); Benjamin Herrenschmidt
Subject: Re: 8360E - PCI / DTC Blob Setup


On Feb 1, 2007, at 8:49 PM, Russell McGuire wrote:

> Kumar,
>
> THANK you, for pointing me in the right direction. I might have  
> scratched my
> head another 10 years finding this bug. And an apology for thinking  
> I had a
> software issue, when it was a hardware issue.

No problem, this pretty much comes out of the PCI OF spec, but it  
takes a while to grok how we actually use it.

> This is helping me greatly, all the while I had this sinking  
> feeling, like I
> didn't route any 'incoming' interrupt lines to the CPU. Something  
> about the
> 8360 being able to get configured as an agent device, so I over  
> looked the
> use of the INTA pin on the CPU as incoming vs outgoing.
>
> SO it would seem I didn't have ANY incoming pins, and thus the  
> IRQ4-7 pins
> that occur in the 8360E-MDS board were floating on my board. So as  
> soon as
> the sound driver enabled the interrupt, it was low all the time.

That would definitely be a HW issue :)

>> <HOST IRQ specifier> (on 83xx):>
>>
>> [linux,phandle for interrupt controller] [IRQ #] [sense]
>
> I assume all these numbers are in HEX, So 0x14, 0x 15, 0x 16, 0x 17  
> would
> correspond to external IRQ4-7 in the MPC8360E. I will wire this up  
> and give
> it a shot, guess it works better when they are connected.

Yeah all numbers are hex, I forget if you can put a leading 0x or  
not.. its kinda annoying.

>> <PCI DEV specifier>:
>>
>> [(bus << 16) | (idsel << 11)] 0 0
>
> Well I think this is definitely part of my problem.
> So I am mapping interrupts from bus 1 and 2, I would need something  
> like?

Truthfully you should probably have child nodes that describe the  
bridges and have their interrupt mappings described there.

The code is going to end up using the Bus #, IDSEL for the pci device  
to try and determine the CPU ext interrupt its mapped to.

Unfortunately, we don't really have an example of this.

> Alternating the 14,15,16,17 to make a 'load-balanced' mapping? Are  
> the bus

not following the question.

>
>> Bus 1, Slot 1, IDSEL = AD20
> 1a000 0 0 1 700 14 8
> 1a000 0 0 1 700 15 8
> 1a000 0 0 1 700 16 8
> 1a000 0 0 1 700 17 8
>> Bus 1, Slot 2, IDSEL = AD24
> 1c000 0 0 1 700 15 8
> 1c000 0 0 1 700 16 8
> 1c000 0 0 1 700 17 8
> 1c000 0 0 1 700 18 8
>> Bus 2, Slot 1, IDSEL = AD20
> 2a000 0 0 1 700 16 8
> 2a000 0 0 1 700 17 8
> 2a000 0 0 1 700 18 8
> 2a000 0 0 1 700 19 8
>
> -Russ
> -----Original Message-----
> From: Kumar Gala [mailto:galak@kernel.crashing.org]
> Sent: Thursday, February 01, 2007 10:11 AM
> To: rmcguire@videopresence.com
> Cc: linuxppc-embedded@ozlabs.org
> Subject: Re: 8360E - PCI / DTC Blob Setup
>
>
> On Feb 1, 2007, at 11:48 AM, Russell McGuire wrote:
>
>> This might be the wrong forum to discuss HW routing, but I am not
>> sure of
>> many HW guys that would understand blob setups. I know I still don't.
>>
>> I read through the booting-without-of-tree.txt and it doesn't
>> explain this
>> other than the interrupt routing needs to be present. Perhaps some
>> of the
>> maintainers of the 83xx platforms can explain how this blob is
>> developed?
>> I assume their board work with the submitted mp38360emds.dts files,
>> as an
>> example.
>>
>> Let me see if I can simplify this, I had this schematic reviewed by
>> Pericom
>> <a PCI bridge MFG> and they recommended these IDSEL lines. And I
>> know the
>> card detection works great, in U-boot.
>>
>> My external PCI bridge is the only thing routed directly to the
>> 8360 Host
>> bridge. The PCI Host bridge in my system is connected on IDSEL-
>>> AD25,0x19
>> Perhaps I shouldn't use any interrupt routing for this, as there is
>> no true
>> /INTA line tied directly to the bridge?
>>
>> My Three PCI slots are routed as follows:
>>
>> Bus 0, Bridge Chip, IDSEL = AD25
>
> Huh, this is only describes one slot/connection.  If you have 3
> slots, they'd have 3 unique IDSELs
>
>> Other side of the Host bridge, all are routed to INTA directly to the
>> CPU.
>> Bus 1, Slot 1, IDSEL = AD20 <card would be ID'd as 1.04 (Bus.Dev)>
>> Bus 1, Slot 2, IDSEL = AD24 <card would be ID'd as 1.08 (Bus.Dev)>
>> Bus 2, Slot 1, IDSEL = AD20 <card would be ID'd as 2.04 (Bus.Dev)>
>>
>> That being said:
>> /* IDSEL 0x19 AD25*/
>>  c800 0 0 1 700 14 8
>
> so the way you read this:
>
> <PCI DEV specifier> <INT A-D> <HOST IRQ specifier>
>
> Do break it down further:
>
> <PCI DEV specifier>:
>
> [(bus << 16) | (idsel << 11)] 0 0
>
> <INT A-D>:
> INTA - 1
> INTB - 2
> INTC - 3
> INTD - 4
>
> <HOST IRQ specifier> (on 83xx):
>
> [linux,phandle for interrupt controller] [IRQ #] [sense]
>
>> I see in the c800 directly corresponds to the 83xx manual for PCI
>> CONFIG
>> address mapping for AD25.
>>
>> I think the '1' is mapped to /INTA, which is the only PCI INT
>> available in
>> the 8360E.
>
> INTA..INTD is more about the device, not host.
>
>> I understand the 700 in this case is the address of the PIC@700.
>>
>> That leaves 5 fields/questions.
>> 1) What do the first two '0's after c800 mean?
>
> There always 0 0, since the int masks them away (they normally
> describe the address the device is at)
>
>> 2) What does the '14' map to?
>
> 0x14 is the external IRQ # its wired to.
>
>> 3) What does the '8' map to?
>
> Sense of IRQ, should always be level for PCI.
>
>> 4) Why would some boards map multiple interrupts to a single IDSEL,
>> like the
>> mpc8360emds.dts file? Is this to handle extra bridges that might be
>> plugged
>> in at a later time?
>
> This is to handle the fact that a PCI add on card put into a slot
> might use multiple interrupts (INTA, INTB), so it lists multiple
> entries to cover the 4 PCI defined interrupts.
>
>> If I understand the mapping correctly then I think I can hard code
>> in the
>> interrupts for the PCI slots.
>>
>> So I don't drive everybody nuts, is there actual documentation on
>> this. I
>> would be happy to stop spamming this list... :-)
>
> There is, but its scattered in places.
>
> Its good to ask these questions so the answers will get archived and
> other people can figure it out as well.
>
> - k

Re: 8360E - PCI / DTC Blob Setup

[Kumar Gala]

On Feb 2, 2007, at 7:36 AM, Russell McGuire wrote:

>
> Well I am getting smarter on this:
>
> I have read through the PCI Bridge Specs and found another issue  
> that might
> have been causing a problem with the IDSEL lines. Unless you are  
> interested
> I'll forgo that explanation and just go with fact that I have  
> changed the
> IDSEL mappings to be legal when they are issued from the 83xx.
>
> I have changed the IDSELs to be as follows, does this look correct?

Not sure, I'm a little confused as to how exactly things are wired on  
your board.  It would seem like you have 2 P2P bridges connected to  
the processor.  Behind one bridge is 2 slots and behind the second is  
1 slot?

> I agree with placing the NODE for the bridge into the dts file to be
> correct. Except I get stuck immediately at trying to come up with an
> address. I.e. the PCI host has a PCI@8500, which makes sense. But  
> the Bridge
> chip doesn't have a mapped address to place in the file. I did read  
> the PCI
> OF node spec <dated 1996> it hints that PCI-PCI bridges are  
> essentially the
> same domain and may not need translation.
>
> Another concern I have now is that the interrupt mask may be  
> incorrect.
> i.e. currently it is <f800 0 0 7>, should I change this to <3f800 0  
> 0 7>
> since I am using an extra 2 bits to indicate bus? This would make  
> sense if
> the ((Bus << 16) | Dev << 11))

Yes that makes sense.

>
>>> Bus 1, Slot 1, (Bridge IDSEL = AD27 mapped to IDSEL AD11 on host)
>> 15800 0 0 1 700 14 8 //Int A always to IRQ 20
>> 15800 0 0 2 700 15 8 //Int B always to IRQ 21
>> 15800 0 0 3 700 16 8 //Int C always to IRQ 22
>> 15800 0 0 4 700 17 8 //Int D always to IRQ 23
>>> Bus 1, Slot 2, (Bridge IDSEL = AD30 mapped to IDSEL AD13 on host)
>> 17000 0 0 1 700 14 8
>> 17000 0 0 2 700 15 8
>> 17000 0 0 3 700 16 8
>> 17000 0 0 4 700 17 8
>>> Bus 2, Slot 1, (Bridge IDSEL = AD27 mapped to IDSEL AD11 on host)
>> 25800 0 0 1 700 14 8
>> 25800 0 0 2 700 15 8
>> 25800 0 0 3 700 16 8
>> 25800 0 0 4 700 17 8
>
> These IDSEL mappings seem to match exactly what U-boot will report
> i.e. Bus.Dev = 1.0b, 1.0e, 2.0b.
>
> I have not placed any reference to the Bridge chip's IDSEL line,  
> since it
> cannot activate any IRQ lines directly. Well try it both ways  
> perhaps and
> see what happens.
>
> The good news is with this configuration, the ca0106 driver will  
> load. I can
> get all the way into linux, and see the associated creations under the
> /proc/ file system. To me all this really proves to me is that the IRQ
> hasn't been toggled. Now I have to figure out how to get the /dev/dsp
> devices in the /dev directory. If ALSA still uses this, I am used  
> to OSS.
>
> I am trying a PCI USB 2.0 card now, with various drivers and  
> devices plugged
> in I get varying results from 'try irqpoll' to boot hanging. Not  
> sure if
> this is an IRQ problem or a another related PCI bug.
>
> What fun this is.
>
> -Russ
>
> -----Original Message-----
> From: Kumar Gala [mailto:galak@kernel.crashing.org]
> Sent: Thursday, February 01, 2007 10:21 PM
> To: rmcguire@videopresence.com
> Cc: linuxppc-embedded@ozlabs.org ((((E-Mail)))); Benjamin  
> Herrenschmidt
> Subject: Re: 8360E - PCI / DTC Blob Setup
>
>
> On Feb 1, 2007, at 8:49 PM, Russell McGuire wrote:
>
>> Kumar,
>>
>> THANK you, for pointing me in the right direction. I might have
>> scratched my
>> head another 10 years finding this bug. And an apology for thinking
>> I had a
>> software issue, when it was a hardware issue.
>
> No problem, this pretty much comes out of the PCI OF spec, but it
> takes a while to grok how we actually use it.
>
>> This is helping me greatly, all the while I had this sinking
>> feeling, like I
>> didn't route any 'incoming' interrupt lines to the CPU. Something
>> about the
>> 8360 being able to get configured as an agent device, so I over
>> looked the
>> use of the INTA pin on the CPU as incoming vs outgoing.
>>
>> SO it would seem I didn't have ANY incoming pins, and thus the
>> IRQ4-7 pins
>> that occur in the 8360E-MDS board were floating on my board. So as
>> soon as
>> the sound driver enabled the interrupt, it was low all the time.
>
> That would definitely be a HW issue :)
>
>>> <HOST IRQ specifier> (on 83xx):>
>>>
>>> [linux,phandle for interrupt controller] [IRQ #] [sense]
>>
>> I assume all these numbers are in HEX, So 0x14, 0x 15, 0x 16, 0x 17
>> would
>> correspond to external IRQ4-7 in the MPC8360E. I will wire this up
>> and give
>> it a shot, guess it works better when they are connected.
>
> Yeah all numbers are hex, I forget if you can put a leading 0x or
> not.. its kinda annoying.
>
>>> <PCI DEV specifier>:
>>>
>>> [(bus << 16) | (idsel << 11)] 0 0
>>
>> Well I think this is definitely part of my problem.
>> So I am mapping interrupts from bus 1 and 2, I would need something
>> like?
>
> Truthfully you should probably have child nodes that describe the
> bridges and have their interrupt mappings described there.
>
> The code is going to end up using the Bus #, IDSEL for the pci device
> to try and determine the CPU ext interrupt its mapped to.
>
> Unfortunately, we don't really have an example of this.
>
>> Alternating the 14,15,16,17 to make a 'load-balanced' mapping? Are
>> the bus
>
> not following the question.
>
>>
>>> Bus 1, Slot 1, IDSEL = AD20
>> 1a000 0 0 1 700 14 8
>> 1a000 0 0 1 700 15 8
>> 1a000 0 0 1 700 16 8
>> 1a000 0 0 1 700 17 8
>>> Bus 1, Slot 2, IDSEL = AD24
>> 1c000 0 0 1 700 15 8
>> 1c000 0 0 1 700 16 8
>> 1c000 0 0 1 700 17 8
>> 1c000 0 0 1 700 18 8
>>> Bus 2, Slot 1, IDSEL = AD20
>> 2a000 0 0 1 700 16 8
>> 2a000 0 0 1 700 17 8
>> 2a000 0 0 1 700 18 8
>> 2a000 0 0 1 700 19 8
>>
>> -Russ
>> -----Original Message-----
>> From: Kumar Gala [mailto:galak@kernel.crashing.org]
>> Sent: Thursday, February 01, 2007 10:11 AM
>> To: rmcguire@videopresence.com
>> Cc: linuxppc-embedded@ozlabs.org
>> Subject: Re: 8360E - PCI / DTC Blob Setup
>>
>>
>> On Feb 1, 2007, at 11:48 AM, Russell McGuire wrote:
>>
>>> This might be the wrong forum to discuss HW routing, but I am not
>>> sure of
>>> many HW guys that would understand blob setups. I know I still  
>>> don't.
>>>
>>> I read through the booting-without-of-tree.txt and it doesn't
>>> explain this
>>> other than the interrupt routing needs to be present. Perhaps some
>>> of the
>>> maintainers of the 83xx platforms can explain how this blob is
>>> developed?
>>> I assume their board work with the submitted mp38360emds.dts files,
>>> as an
>>> example.
>>>
>>> Let me see if I can simplify this, I had this schematic reviewed by
>>> Pericom
>>> <a PCI bridge MFG> and they recommended these IDSEL lines. And I
>>> know the
>>> card detection works great, in U-boot.
>>>
>>> My external PCI bridge is the only thing routed directly to the
>>> 8360 Host
>>> bridge. The PCI Host bridge in my system is connected on IDSEL-
>>>> AD25,0x19
>>> Perhaps I shouldn't use any interrupt routing for this, as there is
>>> no true
>>> /INTA line tied directly to the bridge?
>>>
>>> My Three PCI slots are routed as follows:
>>>
>>> Bus 0, Bridge Chip, IDSEL = AD25
>>
>> Huh, this is only describes one slot/connection.  If you have 3
>> slots, they'd have 3 unique IDSELs
>>
>>> Other side of the Host bridge, all are routed to INTA directly to  
>>> the
>>> CPU.
>>> Bus 1, Slot 1, IDSEL = AD20 <card would be ID'd as 1.04 (Bus.Dev)>
>>> Bus 1, Slot 2, IDSEL = AD24 <card would be ID'd as 1.08 (Bus.Dev)>
>>> Bus 2, Slot 1, IDSEL = AD20 <card would be ID'd as 2.04 (Bus.Dev)>
>>>
>>> That being said:
>>> /* IDSEL 0x19 AD25*/
>>>  c800 0 0 1 700 14 8
>>
>> so the way you read this:
>>
>> <PCI DEV specifier> <INT A-D> <HOST IRQ specifier>
>>
>> Do break it down further:
>>
>> <PCI DEV specifier>:
>>
>> [(bus << 16) | (idsel << 11)] 0 0
>>
>> <INT A-D>:
>> INTA - 1
>> INTB - 2
>> INTC - 3
>> INTD - 4
>>
>> <HOST IRQ specifier> (on 83xx):
>>
>> [linux,phandle for interrupt controller] [IRQ #] [sense]
>>
>>> I see in the c800 directly corresponds to the 83xx manual for PCI
>>> CONFIG
>>> address mapping for AD25.
>>>
>>> I think the '1' is mapped to /INTA, which is the only PCI INT
>>> available in
>>> the 8360E.
>>
>> INTA..INTD is more about the device, not host.
>>
>>> I understand the 700 in this case is the address of the PIC@700.
>>>
>>> That leaves 5 fields/questions.
>>> 1) What do the first two '0's after c800 mean?
>>
>> There always 0 0, since the int masks them away (they normally
>> describe the address the device is at)
>>
>>> 2) What does the '14' map to?
>>
>> 0x14 is the external IRQ # its wired to.
>>
>>> 3) What does the '8' map to?
>>
>> Sense of IRQ, should always be level for PCI.
>>
>>> 4) Why would some boards map multiple interrupts to a single IDSEL,
>>> like the
>>> mpc8360emds.dts file? Is this to handle extra bridges that might be
>>> plugged
>>> in at a later time?
>>
>> This is to handle the fact that a PCI add on card put into a slot
>> might use multiple interrupts (INTA, INTB), so it lists multiple
>> entries to cover the 4 PCI defined interrupts.
>>
>>> If I understand the mapping correctly then I think I can hard code
>>> in the
>>> interrupts for the PCI slots.
>>>
>>> So I don't drive everybody nuts, is there actual documentation on
>>> this. I
>>> would be happy to stop spamming this list... :-)
>>
>> There is, but its scattered in places.
>>
>> Its good to ask these questions so the answers will get archived and
>> other people can figure it out as well.
>>
>> - k
>

RE: 8360E - PCI / DTC Blob Setup

[Russell McGuire]

> On Feb 2, 2007, at 7:36 AM, Russell McGuire wrote:
> 
> >
> > Well I am getting smarter on this:
> >
> > I have read through the PCI Bridge Specs and found another issue
> > that might
> > have been causing a problem with the IDSEL lines. Unless you are
> > interested
> > I'll forgo that explanation and just go with fact that I have
> > changed the
> > IDSEL mappings to be legal when they are issued from the 83xx.
> >
> > I have changed the IDSELs to be as follows, does this look correct?
> 
> Not sure, I'm a little confused as to how exactly things are wired on
> your board.  It would seem like you have 2 P2P bridges connected to
> the processor.  Behind one bridge is 2 slots and behind the second is
> 1 slot?

Absolutely correct, I probably should send a picture. :-) But yes, the CPU
host bridge is directly connected to a DUAL P2P bridge chip. There are no
SLOTS on BUS 0. The P2P then provides BUS 1 and BUS 2. I did this in the
design to allow slower 33Mhz cards to operate in the system without slowing
down the 66Mhz cards <i.e. a sound card or USB card, but still being able to
run a VGA card or video capture card at high speed>.

BUS 1 has two slots, and BUS 2 has one slot, for a total of three.

I would be more than happy to send a 2 page PDF file of the schematic. This
design obviously hasn't been proofed yet. Though it 'seems' to almost work.

-Russ

RE: 8360E - PCI / DTC Blob Setup

[Benjamin Herrenschmidt]

On Fri, 2007-02-02 at 05:36 -0800, Russell McGuire wrote:
> Well I am getting smarter on this:
> 
> I have read through the PCI Bridge Specs and found another issue that might
> have been causing a problem with the IDSEL lines. Unless you are interested
> I'll forgo that explanation and just go with fact that I have changed the
> IDSEL mappings to be legal when they are issued from the 83xx.
> 
> I have changed the IDSELs to be as follows, does this look correct?
> I agree with placing the NODE for the bridge into the dts file to be
> correct. Except I get stuck immediately at trying to come up with an
> address. I.e. the PCI host has a PCI@8500, which makes sense. But the Bridge
> chip doesn't have a mapped address to place in the file. I did read the PCI
> OF node spec <dated 1996> it hints that PCI-PCI bridges are essentially the
> same domain and may not need translation.

The unit address of a PCI device is it's bus/idsel/function, the
PCI-2-PCI bridge is no exception.  Thus it doesn't need to have an
assigned-address property, only "reg", which on PCI, doesn't contain
-assigned- addresses, but purely a description of the BARs. In fact, you
only really need the "reg" property for the config space itself which is
enough to give you a valid unit-address (@xxxx) for your bridge and to
make the PCI parsing code in linux happy.

Ben.

Re: 8360E - PCI / DTC Blob Setup

[Andy Fleming]

On Feb 2, 2007, at 07:36, Russell McGuire wrote:

>
> Well I am getting smarter on this:
>
> I have read through the PCI Bridge Specs and found another issue  
> that might
> have been causing a problem with the IDSEL lines. Unless you are  
> interested
> I'll forgo that explanation and just go with fact that I have  
> changed the
> IDSEL mappings to be legal when they are issued from the 83xx.
>
> I have changed the IDSELs to be as follows, does this look correct?
> I agree with placing the NODE for the bridge into the dts file to be
> correct. Except I get stuck immediately at trying to come up with an
> address. I.e. the PCI host has a PCI@8500, which makes sense. But  
> the Bridge
> chip doesn't have a mapped address to place in the file. I did read  
> the PCI
> OF node spec <dated 1996> it hints that PCI-PCI bridges are  
> essentially the
> same domain and may not need translation.
>
> Another concern I have now is that the interrupt mask may be  
> incorrect.
> i.e. currently it is <f800 0 0 7>, should I change this to <3f800 0  
> 0 7>
> since I am using an extra 2 bits to indicate bus? This would make  
> sense if
> the ((Bus << 16) | Dev << 11))

Yeah, you need to do that.  Take a look at mpc8548cds.dts.  We have a  
mapping for the VIA chip hanging off a P2P bridge on PCI1.  But I  
think you've pretty much got it figured out.  Just sending you a  
"working" example (we've got it working internally, now, we just need  
to find the right code path.  But the dts is correct).


Andy