Connecting to "PCI command write" interrupt on 4xx platforms

Connecting to "PCI command write" interrupt on 4xx platforms

[Matthias Fuchs]

Hi,

I need to connect to the "PCI command write" interrupt on a 440EPx platform. This is UIC0/int#5.

Where should I add this interrupt in the DT? To the PCI node? In this case it will collide with the 
PCI interrupts.

My application is a 440EPx on a PCI addon card. So the PCI node is disabled in the DT.

Is there a way to get an interrupt number for request_irq() without querying the DT?

Matthias

Re: Connecting to "PCI command write" interrupt on 4xx platforms

[Benjamin Herrenschmidt]

On Thu, 2008-10-30 at 11:58 +0100, Matthias Fuchs wrote:
> I need to connect to the "PCI command write" interrupt on a 440EPx
> platform. This is UIC0/int#5.
> 
> Where should I add this interrupt in the DT? To the PCI node? In this
> case it will collide with the 
> PCI interrupts.
> 
> My application is a 440EPx on a PCI addon card. So the PCI node is
> disabled in the DT.
> 
> Is there a way to get an interrupt number for request_irq() without
> querying the DT?

What is this interrupt precisely ? What emits it ? If it's coming from
the actual PCI bridge, then you can stick an interrupts property in the
PCI host bridge node in the DT just fine.

Cheers,
Ben.

Re: Connecting to "PCI command write" interrupt on 4xx platforms

[Matthias Fuchs]

Hi Ben,

On Thursday 30 October 2008 21:15, Benjamin Herrenschmidt wrote:
> On Thu, 2008-10-30 at 11:58 +0100, Matthias Fuchs wrote:
> > I need to connect to the "PCI command write" interrupt on a 440EPx
> > platform. This is UIC0/int#5.
> > 
> > Where should I add this interrupt in the DT? To the PCI node? In this
> > case it will collide with the 
> > PCI interrupts.
> > 
> > My application is a 440EPx on a PCI addon card. So the PCI node is
> > disabled in the DT.
> > 
> > Is there a way to get an interrupt number for request_irq() without
> > querying the DT?
> 
> What is this interrupt precisely ? What emits it ? If it's coming from
The interrupt is emitted by the pci bridge when someone writes to the 
PCI_COMMAND register. We use it on PCI adapter hardware where the CPU is 
not the system CPU. In this case a "host" driver writes to the adapter's
PCI_COMMAND register to trigger a remote interrupt that is handled by a 
special pci communication driver.

Adding this interrupt to the PCI node would make (logical) sense. But
on PCI adapter (add-in cards) designs we typically disable the PCI node
of the DT to disable PCI PnP. This should not prevent us from adding the
interrupt to the node but it looks a little bit weird to take an interrupt
from a disabled node, right?
> the actual PCI bridge, then you can stick an interrupts property in the
> PCI host bridge node in the DT just fine.
The PCI node already contains the interrupt-map for the PCI interrupts.
Doesn't adding a further interrupt property cause some trouble with the PCI interrupts?

Matthias
> 
> Cheers,
> Ben.
> 

Re: Connecting to "PCI command write" interrupt on 4xx platforms

[Benjamin Herrenschmidt]

On Mon, 2008-11-03 at 10:10 +0100, Matthias Fuchs wrote:
> 
> Adding this interrupt to the PCI node would make (logical) sense. But
> on PCI adapter (add-in cards) designs we typically disable the PCI node
> of the DT to disable PCI PnP. This should not prevent us from adding the
> interrupt to the node but it looks a little bit weird to take an interrupt
> from a disabled node, right?

You can make a pci-endpoint node that isn't detected as a host bridge.
In fact, I think we have some way to even tell in the DT not to activate
host bridge function on 44x nowadays no ? I dont remember for sure but
it's easy enough to add.

> > the actual PCI bridge, then you can stick an interrupts property in the
> > PCI host bridge node in the DT just fine.
> The PCI node already contains the interrupt-map for the PCI interrupts.

Only relevant for master, not endpoint.

> Doesn't adding a further interrupt property cause some trouble with the PCI interrupts?

Not for endpoint.

Ben.

Re: Connecting to "PCI command write" interrupt on 4xx platforms

[Stefan Roese]

On Monday 03 November 2008, Benjamin Herrenschmidt wrote:
> On Mon, 2008-11-03 at 10:10 +0100, Matthias Fuchs wrote:
> > Adding this interrupt to the PCI node would make (logical) sense. But
> > on PCI adapter (add-in cards) designs we typically disable the PCI node
> > of the DT to disable PCI PnP. This should not prevent us from adding the
> > interrupt to the node but it looks a little bit weird to take an
> > interrupt from a disabled node, right?
>
> You can make a pci-endpoint node that isn't detected as a host bridge.
> In fact, I think we have some way to even tell in the DT not to activate
> host bridge function on 44x nowadays no ? I dont remember for sure but
> it's easy enough to add.

Yes, it's there. But "only" for PCIe and not for PCI(-X). This patch added it 
for PCIe:

    [POWERPC] 4xx: Add endpoint support to 4xx PCIe driver
    
It should be easy to add this for PCI and PCI-X as well.

Best regards,
Stefan

Re: Connecting to "PCI command write" interrupt on 4xx platforms

[Matthias Fuchs]

On Monday 03 November 2008 12:54, Stefan Roese wrote:
> On Monday 03 November 2008, Benjamin Herrenschmidt wrote:
> > On Mon, 2008-11-03 at 10:10 +0100, Matthias Fuchs wrote:
> > > Adding this interrupt to the PCI node would make (logical) sense. But
> > > on PCI adapter (add-in cards) designs we typically disable the PCI node
> > > of the DT to disable PCI PnP. This should not prevent us from adding the
> > > interrupt to the node but it looks a little bit weird to take an
> > > interrupt from a disabled node, right?
> >
> > You can make a pci-endpoint node that isn't detected as a host bridge.
> > In fact, I think we have some way to even tell in the DT not to activate
> > host bridge function on 44x nowadays no ? I dont remember for sure but
> > it's easy enough to add.
> 
> Yes, it's there. But "only" for PCIe and not for PCI(-X). This patch added it 
> for PCIe:
> 
>     [POWERPC] 4xx: Add endpoint support to 4xx PCIe driver
>     
> It should be easy to add this for PCI and PCI-X as well.
Yes, I already though about that. Currently I set the status attribute of the pci node
to "disabled" when running as endpoint.

But adding endpoint support similiar as you did for PCIe makes sense to me.

Matthias

Re: Connecting to "PCI command write" interrupt on 4xx platforms

[Matthias Fuchs]

On Monday 03 November 2008 11:57, Benjamin Herrenschmidt wrote:
> On Mon, 2008-11-03 at 10:10 +0100, Matthias Fuchs wrote:
> > 
> > Adding this interrupt to the PCI node would make (logical) sense. But
> > on PCI adapter (add-in cards) designs we typically disable the PCI node
> > of the DT to disable PCI PnP. This should not prevent us from adding the
> > interrupt to the node but it looks a little bit weird to take an interrupt
> > from a disabled node, right?
> 
> You can make a pci-endpoint node that isn't detected as a host bridge.
> In fact, I think we have some way to even tell in the DT not to activate
> host bridge function on 44x nowadays no ? I dont remember for sure but
> it's easy enough to add.
We have endpoint support for PCIe and the possibility to disable PCI through the status
attribute.
> 
> > > the actual PCI bridge, then you can stick an interrupts property in the
> > > PCI host bridge node in the DT just fine.
> > The PCI node already contains the interrupt-map for the PCI interrupts.
> 
> Only relevant for master, not endpoint.
> 
> > Doesn't adding a further interrupt property cause some trouble with the PCI interrupts?
> 
> Not for endpoint.
I see.

I will try to add endpoint support for PCI as well. I would like to have a single PCI node and
let the device_type attribute decide if we are running in hostbridge or endpoint mode.

Matthias

Re: Connecting to "PCI command write" interrupt on 4xx platforms

[Benjamin Herrenschmidt]

> I will try to add endpoint support for PCI as well. I would like to have a single PCI node and
> let the device_type attribute decide if we are running in hostbridge or endpoint mode.

Don't use device_type. Do the same we do for PCI-E (whatever it is, I
don't have the source code at hand right now).

Cheers,
Ben.

Re: Connecting to "PCI command write" interrupt on 4xx platforms

[Stefan Roese]

On Monday 03 November 2008, Benjamin Herrenschmidt wrote:
> > I will try to add endpoint support for PCI as well. I would like to have
> > a single PCI node and let the device_type attribute decide if we are
> > running in hostbridge or endpoint mode.
>
> Don't use device_type. Do the same we do for PCI-E (whatever it is, I
> don't have the source code at hand right now).

It is device_type for PCIe right now, I'm afraid. This was what we agreed 
upon. Here a code sniplet from the patch:

	/* Check if device_type property is set to "pci" or "pci-endpoint".
	 * Resulting from this setup this PCIe port will be configured
	 * as root-complex or as endpoint.
	 */
	val = of_get_property(port->node, "device_type", NULL);
	if (!strcmp(val, "pci-endpoint")) {
		port->endpoint = 1;
	} else if (!strcmp(val, "pci")) {
		port->endpoint = 0;
	} else {
		printk(KERN_ERR "PCIE: missing or incorrect device_type for %s\n",
		       np->full_name);
		return;
	}

Best regards,
Stefan

Re: Connecting to "PCI command write" interrupt on 4xx platforms

[Benjamin Herrenschmidt]

On Tue, 2008-11-04 at 06:19 +0100, Stefan Roese wrote:
> On Monday 03 November 2008, Benjamin Herrenschmidt wrote:
> > > I will try to add endpoint support for PCI as well. I would like to have
> > > a single PCI node and let the device_type attribute decide if we are
> > > running in hostbridge or endpoint mode.
> >
> > Don't use device_type. Do the same we do for PCI-E (whatever it is, I
> > don't have the source code at hand right now).
> 
> It is device_type for PCIe right now, I'm afraid. This was what we agreed 
> upon. Here a code sniplet from the patch:
> 
> 	/* Check if device_type property is set to "pci" or "pci-endpoint".
> 	 * Resulting from this setup this PCIe port will be configured
> 	 * as root-complex or as endpoint.
> 	 */
> 	val = of_get_property(port->node, "device_type", NULL);
> 	if (!strcmp(val, "pci-endpoint")) {
> 		port->endpoint = 1;
> 	} else if (!strcmp(val, "pci")) {
> 		port->endpoint = 0;
> 	} else {
> 		printk(KERN_ERR "PCIE: missing or incorrect device_type for %s\n",
> 		       np->full_name);
> 		return;
> 	}

Allright, that was a bad idea from both of us, David will have my
skin ...

We should try to move toward something like an "endpoint" property and a
"pci-endpoint" name instead.

Ben.

Re: Connecting to "PCI command write" interrupt on 4xx platforms

[Matthias Fuchs]

On Tuesday 04 November 2008 07:16, Benjamin Herrenschmidt wrote:
> > It is device_type for PCIe right now, I'm afraid. This was what we agreed 
> > upon. Here a code sniplet from the patch:
> > 
> > 	/* Check if device_type property is set to "pci" or "pci-endpoint".
> > 	 * Resulting from this setup this PCIe port will be configured
> > 	 * as root-complex or as endpoint.
> > 	 */
> > 	val = of_get_property(port->node, "device_type", NULL);
> > 	if (!strcmp(val, "pci-endpoint")) {
> > 		port->endpoint = 1;
> > 	} else if (!strcmp(val, "pci")) {
> > 		port->endpoint = 0;
> > 	} else {
> > 		printk(KERN_ERR "PCIE: missing or incorrect device_type for %s\n",
> > 		       np->full_name);
> > 		return;
> > 	}
> 
> Allright, that was a bad idea from both of us, David will have my
> skin ...
> 
> We should try to move toward something like an "endpoint" property and a
> "pci-endpoint" name instead.
I must admit that I am not sure what you mean by (pci-endpoint) _name_.
Do you mean something like this:
 
        PCI: pci@abc {
                endpoint = "pci-endpoint";
                ...

To many "endpoint" appearances for my taste:-)

Matthias

Re: Connecting to "PCI command write" interrupt on 4xx platforms

[Benjamin Herrenschmidt]

On Tue, 2008-11-04 at 12:17 +0100, Matthias Fuchs wrote:
> I must admit that I am not sure what you mean by (pci-endpoint)
> _name_.
> Do you mean something like this:
>  
>         PCI: pci@abc {
>                 endpoint = "pci-endpoint";
>                 ...
> 
> To many "endpoint" appearances for my taste:-)

No, by name I meant

	PCI: pci-endpoint@xxxx {
	}

But if we want to have the same device node easily convert between
endpoint and host, maybe simply a property would be enough. Either just
an empty "endoint" property or a "mode" property containing "endpoint"
 vs. "host".

I tend to prefer changing the name if we aren't going to be a host
bridge though.

Ben.

Re: Connecting to "PCI command write" interrupt on 4xx platforms

[Matthias Fuchs]

Hi,=20

we build some 4xx based PMC modules in the past. These boards can
run as host ("processor PMC" or so called "monarch" mode) or as PCI endpoint
("non-monarch" mode). I would like to use the same DT (and kernel) in both=
=20
modes.
Currently I set the "status" property of the PCI node to "disabled" to prev=
ent=20
the kernel to do the host bride stuff (not good as I learned). But we need=
=20
some info from the PCI node even in endpoint mode. So disable is not the be=
st=20
idea.=20

In endpoint mode the current PCI node has many properties that
make no sense and others are missing. So one could think of a pci _and_=20
pci-endpoint node. The one that is not needed can be disabled, e.g. by=20
U-Boot (if you are using U-Boot :-).

I could live with a mode or empty endpoint property, but I am not sure how
to keep the endpoint interrupt properties side-by-side with the host
interrupt mapping. I do not want to patch multiple properties by the=20
bootloader to switch between host and endpoint. No can we have=20
interrupt-parent + interrupts property in the same node with=20
interrupt-map-mask + interrupt-map?

                PCI0: pci@1ec000000 {
                        device_type =3D "pci";
			endpoint; /* Ben's suggestion */

			/* makes only sense for endpoints */
                        interrupt-parent =3D <&UIC0>;
                        interrupts =3D <0x5 0x4 /* PCI command write */
                                      0x6 0x4>; /* PCI power management */

                        #interrupt-cells =3D <1>;
                        #size-cells =3D <2>;
                        #address-cells =3D <3>;
                        compatible =3D "ibm,plb440epx-pci", "ibm,plb-pci";
                        primary;
                        reg =3D <0x00000001 0xeec00000 0x00000008
                               0x00000001 0xeed00000 0x00000004
                               0x00000001 0xeed00000 0x00000004
                               0x00000001 0xef400000 0x00000040>;

			/* makes some sense for endpoints=20
			Values might differ between host and endpoints */
                        ranges =3D <...>;

                        /* makes some sense for endpoints */
                        dma-ranges =3D <...>;

                        interrupt-map-mask =3D <...>;
                        interrupt-map =3D <...>;
                };
        };

Matthias

On Tuesday 04 November 2008 22:29:44 Benjamin Herrenschmidt wrote:
> On Tue, 2008-11-04 at 12:17 +0100, Matthias Fuchs wrote:
> > I must admit that I am not sure what you mean by (pci-endpoint)
> > _name_.
> > Do you mean something like this:
> >
> >         PCI: pci@abc {
> >                 endpoint =3D "pci-endpoint";
> >                 ...
> >
> > To many "endpoint" appearances for my taste:-)
>
> No, by name I meant
>
> 	PCI: pci-endpoint@xxxx {
> 	}
>
> But if we want to have the same device node easily convert between
> endpoint and host, maybe simply a property would be enough. Either just
> an empty "endoint" property or a "mode" property containing "endpoint"
>  vs. "host".
>
> I tend to prefer changing the name if we aren't going to be a host
> bridge though.
>
> Ben.
>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev



=2D-=20
=2D------------------------------------------------------------------------
Dipl.-Ing. Matthias Fuchs
Head of System Design

esd electronic system design gmbh
Vahrenwalder Str. 207 - 30165 Hannover - GERMANY
Phone: +49-511-37298-0 - Fax: +49-511-37298-68
Please visit our homepage http://www.esd.eu
Quality Products - Made in Germany
=2D------------------------------------------------------------------------
Gesch=E4ftsf=FChrer: Klaus Detering, Dr. Werner Schulze
Amtsgericht Hannover HRB 51373 - VAT-ID DE 115672832
=2D------------------------------------------------------------------------