- 16 12月, 2008 1 次提交
-
-
由 Arnd Bergmann 提交于
Commit d015fe99 'powerpc/cell/axon-msi: Retry on missing interrupt' has turned a rare failure to kexec on QS22 into a reproducible error, which we have now analysed. The problem is that after a kexec, the MSIC hardware still points into the middle of the old ring buffer. We set up the ring buffer during reboot, but not the offset into it. On older kernels, this would cause a storm of thousands of spurious interrupts after a kexec, which would most of the time get dropped silently. With the new code, we time out on each interrupt, waiting for it to become valid. If more interrupts come in that we time out on, this goes on indefinitely, which eventually leads to a hard crash. The solution in this commit is to read the current offset from the MSIC when reinitializing it. This now works correctly, as expected. Reported-by: NDirk Herrendoerfer <d.herrendoerfer@de.ibm.com> Signed-off-by: NArnd Bergmann <arnd@arndb.de> Acked-by: NMichael Ellerman <michael@ellerman.id.au> Signed-off-by: NPaul Mackerras <paulus@samba.org>
-
- 01 12月, 2008 1 次提交
-
-
由 Arnd Bergmann 提交于
The MSI capture logic for the axon bridge can sometimes lose interrupts in case of high DMA and interrupt load, when it signals an MSI interrupt to the MPIC interrupt controller while we are already handling another MSI. Each MSI vector gets written into a FIFO buffer in main memory using DMA, and that DMA access is normally flushed by the actual interrupt packet on the IOIF. An MMIO register in the MSIC holds the position of the last entry in the FIFO buffer that was written. However, reading that position does not flush the DMA, so that we can observe stale data in the buffer. In a stress test, we have observed the DMA to arrive up to 14 microseconds after reading the register. This patch works around this problem by retrying the access to the FIFO buffer. We can reliably detect the conditioning by writing an invalid MSI vector into the FIFO buffer after reading from it, assuming that all MSIs we get are valid. After detecting an invalid MSI vector, we udelay(1) in the interrupt cascade for up to 100 times before giving up. Signed-off-by: NArnd Bergmann <arnd@arndb.de> Signed-off-by: NPaul Mackerras <paulus@samba.org>
-
- 09 6月, 2008 2 次提交
-
-
由 Michael Ellerman 提交于
When I changed irq_alloc_host() to take an of_node (52964f87: "Add an optional device_node pointer to the irq_host"), I botched the reference counting semantics. Stephen pointed out that it's irq_alloc_host()'s business if it needs to take an additional reference to the device_node, the caller shouldn't need to care. Signed-off-by: NMichael Ellerman <michael@ellerman.id.au> Signed-off-by: NPaul Mackerras <paulus@samba.org>
-
由 Michael Ellerman 提交于
If we do the call to irq_of_parse_and_map() first, then we don't need to worry about freeing the irq_host. Signed-off-by: NMichael Ellerman <michael@ellerman.id.au> Signed-off-by: NPaul Mackerras <paulus@samba.org>
-
- 23 5月, 2008 1 次提交
-
-
由 Michael Ellerman 提交于
This adds some debugging code to the Axon MSI driver. It creates a file per MSIC in /sys/kernel/debug/powerpc, which allows the user to trigger a fake MSI interrupt by writing to the file. This can be used to test some of the MSI generation path. In particular, that the MSIC recognises a write to the MSI address, generates an interrupt and writes the MSI packet into the ring buffer. All the code is inside #ifdef DEBUG so it causes no harm unless it's enabled. Signed-off-by: NMichael Ellerman <michael@ellerman.id.au> Signed-off-by: NPaul Mackerras <paulus@samba.org>
-
- 24 4月, 2008 1 次提交
-
-
由 Michael Ellerman 提交于
Replace two open-coded occurences of the of_get_next_parent() logic. Signed-off-by: NMichael Ellerman <michael@ellerman.id.au> Signed-off-by: NPaul Mackerras <paulus@samba.org>
-
- 06 2月, 2008 3 次提交
-
-
由 Stephen Rothwell 提交于
I got this warning from gcc: arch/powerpc/platforms/cell/axon_msi.c:118: warning: 'tmp' may be used uninitialized in this function Which turns out to be a false positive, but pointed out that it was possible for the error path in find_msi_translator() to do an extra of_node_put on a node. This fixes it by localising the ref counting a bit. As a side effect, the warning goes away. Signed-off-by: NStephen Rothwell <sfr@canb.auug.org.au> Signed-off-by: NPaul Mackerras <paulus@samba.org>
-
由 Michael Ellerman 提交于
There's a brown-paper-bag bug in axon_msi, we pass the address of our FIFO directly to the hardware, without DMA mapping it. This leads to DMA exceptions if you enable MSI & the IOMMU. The fix is to correctly DMA map the fifo, dma_alloc_coherent() does what we want - and we need to track the virt & phys addresses. Signed-off-by: NMichael Ellerman <michael@ellerman.id.au> Acked-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by: NPaul Mackerras <paulus@samba.org>
-
由 Michael Ellerman 提交于
Now that we create of_platform devices earlier on cell, we can make the axon_msi driver an of_platform driver. This makes the code cleaner in several ways, and most importantly means we have a struct device. Signed-off-by: NMichael Ellerman <michael@ellerman.id.au> Acked-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by: NPaul Mackerras <paulus@samba.org>
-
- 16 10月, 2007 2 次提交
-
-
由 Michael Ellerman 提交于
msic_dcr_read() doesn't really do anything useful, just replace it with direct calls to dcr_read(). Signed-off-by: NMichael Ellerman <michael@ellerman.id.au> Signed-off-by: NJeff Garzik <jeff@garzik.org>
-
由 Michael Ellerman 提交于
Now that all users of dcr_read()/dcr_write() add the dcr_host_t.base, we can save them the trouble and do it in dcr_read()/dcr_write(). As some background to why we just went through all this jiggery-pokery, benh sayeth: Initially the goal of the dcr_read/dcr_write routines was to operate like mfdcr/mtdcr which take absolute DCR numbers. The reason is that on 4xx hardware, indirect DCR access is a pain (goes through a table of instructions) and it's useful to have the compiler resolve an absolute DCR inline. We decided that wasn't worth the API bastardisation since most places where absolute DCR values are used are low level 4xx-only code which may as well continue using mfdcr/mtdcr, while the new API is designed for device "instances" that can exist on 4xx and Axon type platforms and may be located at variable DCR offsets. Signed-off-by: NMichael Ellerman <michael@ellerman.id.au> Signed-off-by: NJeff Garzik <jeff@garzik.org>
-
- 03 10月, 2007 2 次提交
-
-
由 Michael Ellerman 提交于
Now that dcr_host_t contains the base address, we can use that in the axon_msi code, rather than storing it separately. Signed-off-by: NMichael Ellerman <michael@ellerman.id.au> Acked-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by: NPaul Mackerras <paulus@samba.org>
-
由 Michael Ellerman 提交于
pci_device_to_OF_node() returns the device node attached to a PCI device, but doesn't actually grab a reference - we need to do it ourselves. Signed-off-by: NMichael Ellerman <michael@ellerman.id.au> Acked-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by: NPaul Mackerras <paulus@samba.org>
-
- 13 9月, 2007 2 次提交
-
-
由 Michael Ellerman 提交于
The most common match semantic is an exact match based on the device node. So provide a default implementation that does this, and hook it up if no match routine is specified. Signed-off-by: NMichael Ellerman <michael@ellerman.id.au> Signed-off-by: NPaul Mackerras <paulus@samba.org>
-
由 Michael Ellerman 提交于
The majority of irq_host implementations (3 out of 4) are associated with a device_node, and need to stash it somewhere. Rather than having it somewhere different for each host, add an optional device_node pointer to the irq_host structure. Signed-off-by: NMichael Ellerman <michael@ellerman.id.au> Signed-off-by: NPaul Mackerras <paulus@samba.org>
-
- 21 7月, 2007 1 次提交
-
-
由 Michael Ellerman 提交于
This patch adds support for the setup and decoding of MSIs on Axon-based Cell systems, using the MSIC mechanism. This involves setting up an area of BE memory which the Axon then uses as a FIFO for MSI messages. When one or more MSIs are decoded by the MSIC we receive an interrupt on the MPIC, and the MSI messages are written into the FIFO. At the moment we use a 64KB FIFO, one per MSIC/BE. Signed-off-by: NMichael Ellerman <michael@ellerman.id.au> Signed-off-by: NArnd Bergmann <arnd.bergmann@de.ibm.com>
-