Re: linux-next: manual merge of the net-next tree with the powerpc tree
From: Stephen Rothwell s...@canb.auug.org.au Date: Fri, 9 Mar 2012 17:44:16 +1100 On Thu, 08 Mar 2012 22:15:34 -0800 (PST) David Miller da...@davemloft.net wrote: From: Stephen Rothwell s...@canb.auug.org.au Date: Fri, 9 Mar 2012 13:36:46 +1100 Today's linux-next merge of the net-next tree got a conflict in drivers/net/ethernet/ibm/iseries_veth.c between commit e92a665949f6 (net: powerpc: remove the legacy iSeries ethernet driver) from the powerpc tree and commit 41de8d4cff21 (drivers/net: Remove alloc_etherdev error messages) from the net-next tree. I just removed the file. If it makes life easier for anyone I can put the driver removal patch into net-next. In this case, I think it will actually help, thanks. Note that it won;t apply cleanly to your tree, but the fixup is easy :-) And I discovered that git am doesn't like the style of patch I did (without the body of the deleted file). If you just delete drivers/net/ethernet/ibm/iseries_veth.c before trying to apply the patch it will probably work. I took care of this the other night. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: linux-next: manual merge of the powerpc tree with the arm tree
On Fri, Mar 09, 2012 at 10:51:27AM -0600, Rob Herring wrote: On 03/08/2012 09:13 PM, Benjamin Herrenschmidt wrote: On Fri, 2012-03-09 at 00:39 +, Russell King wrote: On Fri, Mar 09, 2012 at 10:35:46AM +1100, Benjamin Herrenschmidt wrote: Actually, I didn't keep MAY_HAVE_SPARSE_IRQ, I kept HAVE_SPARSE_IRQ. If I remove it, then I get Kconfig warnings: warning: (PPC) selects SPARSE_IRQ which has unmet direct dependencies (HAVE_GENERIC_HARDIRQS HAVE_SPARSE_IRQ) Do you have commit 2ed86b16eabe4efbf80cc725a8cbb5310746a2fc ? Nope, Grant patch didn't mention a dependency. My opinion is that SPARSE_IRQ shouldn't be user visible option, and the simple solution was to just make it hidden. It wasn't clear if this was desired or not for other arches at the time. There is a mixture of settings in powerpc defconfigs. SuperH selects it for 32-bit and leaves it user selectable for 64-bit. I'm happy to revert adding MAY_HAVE_SPARSE_IRQ and just make SPARSE_IRQ a hidden option. It really just needs the okay from SuperH folks. We basically want it always-enabled for 32-bit and it doesn't matter much about 64-bit. In the future I'll probably fix up the 64-bit stuff to use it too and then we'll just leave it on all the time, but it's not such a big deal if it's not visible for enabling on 64-bit at the moment given that it's probably broken there at the moment. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 1/2] powerpc/44x: Fix PCI MSI support for Maui APM821xx SoC and Bluestone board
This patch consists of:
- Enable PCI MSI as default for Bluestone board
- Change definition of number of MSI interrupt as it depends on SoC
- Fix returning ENODEV as finding MSI node
- Fix MSI physical high and low address
- Keep MSI data logically
Signed-off-by: Mai La m...@apm.com
---
arch/powerpc/platforms/44x/Kconfig |2 +
arch/powerpc/sysdev/ppc4xx_msi.c | 40 +++
2 files changed, 28 insertions(+), 14 deletions(-)
diff --git a/arch/powerpc/platforms/44x/Kconfig
b/arch/powerpc/platforms/44x/Kconfig
index fcf6bf2..9f04ce3 100644
--- a/arch/powerpc/platforms/44x/Kconfig
+++ b/arch/powerpc/platforms/44x/Kconfig
@@ -23,6 +23,8 @@ config BLUESTONE
default n
select PPC44x_SIMPLE
select APM821xx
+ select PCI_MSI
+ select PPC4xx_MSI
select IBM_EMAC_RGMII
help
This option enables support for the APM APM821xx Evaluation board.
diff --git a/arch/powerpc/sysdev/ppc4xx_msi.c b/arch/powerpc/sysdev/ppc4xx_msi.c
index 1c2d7af..63989d0 100644
--- a/arch/powerpc/sysdev/ppc4xx_msi.c
+++ b/arch/powerpc/sysdev/ppc4xx_msi.c
@@ -28,10 +28,11 @@
#include linux/of_platform.h
#include linux/interrupt.h
#include linux/export.h
+#include linux/kernel.h
#include asm/prom.h
#include asm/hw_irq.h
#include asm/ppc-pci.h
-#include boot/dcr.h
+#include asm/dcr.h
#include asm/dcr-regs.h
#include asm/msi_bitmap.h
@@ -43,13 +44,14 @@
#define PEIH_FLUSH00x30
#define PEIH_FLUSH10x38
#define PEIH_CNTRST0x48
-#define NR_MSI_IRQS4
+
+int msi_irqs;
struct ppc4xx_msi {
u32 msi_addr_lo;
u32 msi_addr_hi;
void __iomem *msi_regs;
- int msi_virqs[NR_MSI_IRQS];
+ int *msi_virqs;
struct msi_bitmap bitmap;
struct device_node *msi_dev;
};
@@ -61,7 +63,7 @@ static int ppc4xx_msi_init_allocator(struct platform_device
*dev,
{
int err;
- err = msi_bitmap_alloc(msi_data-bitmap, NR_MSI_IRQS,
+ err = msi_bitmap_alloc(msi_data-bitmap, msi_irqs,
dev-dev.of_node);
if (err)
return err;
@@ -83,6 +85,9 @@ static int ppc4xx_setup_msi_irqs(struct pci_dev *dev, int
nvec, int type)
struct msi_desc *entry;
struct ppc4xx_msi *msi_data = ppc4xx_msi;
+ msi_data-msi_virqs = kmalloc((msi_irqs) * sizeof(int),
+ GFP_KERNEL);
+
list_for_each_entry(entry, dev-msi_list, list) {
int_no = msi_bitmap_alloc_hwirqs(msi_data-bitmap, 1);
if (int_no = 0)
@@ -150,12 +155,11 @@ static int ppc4xx_setup_pcieh_hw(struct platform_device
*dev,
if (!sdr_addr)
return -1;
- SDR0_WRITE(sdr_addr, (u64)res.start 32); /*HIGH addr */
- SDR0_WRITE(sdr_addr + 1, res.start 0x); /* Low addr */
-
+ mtdcri(SDR0, *sdr_addr, upper_32_bits(res.start)); /*HIGH addr */
+ mtdcri(SDR0, *sdr_addr + 1, lower_32_bits(res.start)); /* Low addr */
msi-msi_dev = of_find_node_by_name(NULL, ppc4xx-msi);
- if (msi-msi_dev)
+ if (!msi-msi_dev)
return -ENODEV;
msi-msi_regs = of_iomap(msi-msi_dev, 0);
@@ -167,9 +171,12 @@ static int ppc4xx_setup_pcieh_hw(struct platform_device
*dev,
(u32) (msi-msi_regs + PEIH_TERMADH), (u32) (msi-msi_regs));
msi_virt = dma_alloc_coherent(dev-dev, 64, msi_phys, GFP_KERNEL);
- msi-msi_addr_hi = 0x0;
- msi-msi_addr_lo = (u32) msi_phys;
- dev_dbg(dev-dev, PCIE-MSI: msi address 0x%x\n, msi-msi_addr_lo);
+ if (!msi_virt)
+ return -ENOMEM;
+ msi-msi_addr_hi = (u32)(msi_phys 32);
+ msi-msi_addr_lo = (u32)(msi_phys 0x);
+ dev_dbg(dev-dev, PCIE-MSI: msi address high 0x%x, low 0x%x\n,
+ msi-msi_addr_hi, msi-msi_addr_lo);
/* Progam the Interrupt handler Termination addr registers */
out_be32(msi-msi_regs + PEIH_TERMADH, msi-msi_addr_hi);
@@ -185,6 +192,8 @@ static int ppc4xx_setup_pcieh_hw(struct platform_device
*dev,
out_be32(msi-msi_regs + PEIH_MSIED, *msi_data);
out_be32(msi-msi_regs + PEIH_MSIMK, *msi_mask);
+ dma_free_coherent(dev-dev, 64, msi_virt, msi_phys);
+
return 0;
}
@@ -194,7 +203,7 @@ static int ppc4xx_of_msi_remove(struct platform_device *dev)
int i;
int virq;
- for (i = 0; i NR_MSI_IRQS; i++) {
+ for (i = 0; i msi_irqs; i++) {
virq = msi-msi_virqs[i];
if (virq != NO_IRQ)
irq_dispose_mapping(virq);
@@ -215,8 +224,6 @@ static int __devinit ppc4xx_msi_probe(struct
platform_device *dev)
struct resource res;
int err = 0;
- msi = ppc4xx_msi;/*keep the msi data for further use*/
-
dev_dbg(dev-dev, PCIE-MSI: Setting up MSI support...\n);
msi = kzalloc(sizeof(struct ppc4xx_msi), GFP_KERNEL);
@@ -234,6 +241,10 @@ static int
Re: [PATCH 1/2] powerpc/44x: Fix PCI MSI support for Maui APM821xx SoC and Bluestone board
Dear Mai La, In message 1331524918-22515-1-git-send-email-...@apm.com you wrote: This patch consists of: - Enable PCI MSI as default for Bluestone board - Change definition of number of MSI interrupt as it depends on SoC - Fix returning ENODEV as finding MSI node - Fix MSI physical high and low address - Keep MSI data logically Signed-off-by: Mai La m...@apm.com This is an updated version of your patch of March 09, right - http://article.gmane.org/gmane.linux.kernel/1264255 ?? If so, you should mark ot as patch V2 in the Subject:, and add a description of what you changed. - SDR0_WRITE(sdr_addr, (u64)res.start 32); /*HIGH addr */ - SDR0_WRITE(sdr_addr + 1, res.start 0x); /* Low addr */ - + mtdcri(SDR0, *sdr_addr, upper_32_bits(res.start)); /*HIGH addr */ + mtdcri(SDR0, *sdr_addr + 1, lower_32_bits(res.start)); /* Low addr */ ... + msi-msi_addr_hi = (u32)(msi_phys 32); + msi-msi_addr_lo = (u32)(msi_phys 0x); Is there any reason for not using upper_32_bits() / lower_32_bits() consistently? Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Real computer scientists despise the idea of actual hardware. Hard- ware has limitations, software doesn't. It's a real shame that Turing machines are so poor at I/O. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
