Thread (15 messages) 15 messages, 4 authors, 2017-05-22

[PATCH v3 2/2] dt-bindings: pcie: Add documentation for Mediatek PCIe

From: ryder.lee@mediatek.com (Ryder Lee)
Date: 2017-05-14 05:27:45
Also in: linux-devicetree, linux-mediatek, linux-pci, lkml

Hi Arnd,

Sorry to bother you again.

On Thu, 2017-05-11 at 20:11 +0800, Ryder Lee wrote:
quoted
interrupt-map-mask = <0xff800 0 0 0>;
interrupt-map = <0x0000 0 0 0 &gic GIC_SPI 193 IRQ_TYPE_NONE>,
		 <0x0800 0 0 0 &gic GIC_SPI 194 IRQ_TYPE_NONE>,
		 <0x1000 0 0 0 &gic GIC_SPI 195 IRQ_TYPE_NONE>,

		 /* workaround here*/
		 <0x10000 0 0 0 &gic GIC_SPI 193 IRQ_TYPE_NONE>,
		 <0x20000 0 0 0 &gic GIC_SPI 194 IRQ_TYPE_NONE>,
	     <0x30000 0 0 0 &gic GIC_SPI 195 IRQ_TYPE_NONE>;

It works well. But how could we handle the situation if root port0
status = "disabled" ? I think we cannot assign child bus number
dynamically from binding.
That is to say, we route it statically if port0 (or port1) is
unavailable. The PCI child bus enumeration should look something like
this:

 pci 0000:00:01.0: fixup irq: got 224
 pci 0000:00:01.0: assigning IRQ 224
 pci 0000:00:02.0: fixup irq: got 225
 pci 0000:00:02.0: assigning IRQ 225
 
 Go wrong here! IRQ 223/224 should be assigned to the devices behind
port0 and port1.
 pci 0000:01:00.0: fixup irq: got 223
 pci 0000:01:00.0: assigning IRQ 223
 pci 0000:02:00.0: fixup irq: got 224
 pci 0000:02:00.0: assigning IRQ 224
What I thought was wrong. I have misunderstood something in previous
discussion. Actually it could work for the situation that I mentioned
before. However, I'm not sure whether this is a proper representation
you want to see.
quoted
quoted
quoted
quoted
On a related note, I see that you still list
quoted
+- interrupts: Three interrupt outputs of the controller. Must contain an
+  entry for each entry in the interrupt-names property.
+- interrupt-names: Must include the following names
+  - "pcie-int0"
+  - "pcie-int1"
+  - "pcie-int2"
This seems to be an artifact from the older version and should be
removed as the driver correctly ignores the properties now.
Actually, everything works fine without these properties however when it
loads we see a few weird error message:

pcieport 0000:00:01.0: Signaling PME with IRQ 232
pcieport 0000:00:02.0: enabling device (0140 -> 0142)
pcieport 0000:00:02.0: enabling bus mastering
irq 232: nobody cared (try booting with the "irqpoll" option)
...
[<c03f6be4>] (pcie_pme_probe) from [<c03f47b8>] (pcie_port_probe_service
+0x44/0x6c)
(pcie_port_probe_service) from [<c0454cf8>] (driver_probe_device
+0x280/0x470)
...
(pcie_port_device_register) from [<c03f51a0>] (pcie_portdrv_probe
+0x3c/0xb4)
(pcie_portdrv_probe) from [<c03e7acc>] (pci_device_probe+0x98/0xfc)
(pci_device_probe) from [<c0454cf8>] (driver_probe_device+0x280/0x470)
handlers:
[<c03f68b0>] pcie_pme_irq
Disabling IRQ #233

I haven't dig it out yet, but just keep them here to solve that.
Something is going very wrong if adding the properties helps. I can't
think of what that is, but we have to find out before the binding can
be merged.
Not really understand PME service. But I will find the reason here.
I have do some test here. PME needs port IRQs, which interrupt type was
set correctly(IRQ_TYPE_LEVEL_LOW). But we cannot set it from
interrupt-map, according to gic_set_type() /* SPIs have restrictions on
the supported types */ .

So we need to add additional interrupt properties.
I could use iPerf to test my WLAN card normally. But just ignore this
exception message. I would definitely appreciate if someone could give
me some hint on how to properly solve it. 

Thanks a lot.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help