Re: [PATCH 0/7] powerpc: remove the legacy iSeries platform specific drivers
On 03/08/2012 05:28 AM, Stephen Rothwell wrote: > It would probably be easiest if all these patches were merged via the > powerpc tree to eliminate any dependencies between them. Their impact on > generic code is very small. Go ahead, no point in doing otherwise. -- Jens Axboe ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 5/7] tty: powerpc: remove SERIAL_ICOM dependency on PPC_ISERIES
On Thu, 8 Mar 2012 15:39:31 +1100 Stephen Rothwell wrote: > The PowerPC legacy iSeries platform is being removed so this is no > longer selectable. Fine by me ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH 2/4] fsl_pci: Add a workaround for PCI 5 errata in MPC8548
> On Mar 6, 2012, at 3:10 AM, Zhao Chenhui wrote:
>
> > + if ((fsl_svr_is(SVR_8548) || fsl_svr_is(SVR_8548_E)) &&
>
> Should this also have 8547, 8547E, 8545, 8545E, 8543, & 8543E?
Yes. I will include these chips.
-Chenhui
>
> > + !early_find_capability(hose, 0, 0, PCI_CAP_ID_PCIX)) {
> > + early_read_config_word(hose, 0, 0,
> > + PCI_BUS_FUNCTION, &temp);
> > + temp |= PCI_BUS_FUNCTION_MDS;
> > + early_write_config_word(hose, 0, 0,
> > + PCI_BUS_FUNCTION, temp);
> > + }
> > }
>
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] PPC: Don't sync timebase when inside VM
On Fri, Mar 2, 2012 at 11:17 AM, Scott Wood wrote:
> On 03/02/2012 10:30 AM, Alexander Graf wrote:
>>
>> On 02.03.2012, at 17:20, Scott Wood wrote:
>>
>>> On Fri, Mar 02, 2012 at 03:12:33PM +0100, Alexander Graf wrote:
When running inside a virtual machine, we can not modify timebase, so
let's just not call the functions for it then.
This resolves hangs when booting e500 SMP guests on overcommitted hosts.
Reported-by: Stuart Yoder
Signed-off-by: Alexander Graf
---
arch/powerpc/platforms/85xx/smp.c | 7 +++
1 files changed, 7 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/platforms/85xx/smp.c
b/arch/powerpc/platforms/85xx/smp.c
index ff42490..d4b6c1f 100644
--- a/arch/powerpc/platforms/85xx/smp.c
+++ b/arch/powerpc/platforms/85xx/smp.c
@@ -249,6 +249,13 @@ void __init mpc85xx_smp_init(void)
smp_85xx_ops.cause_ipi = doorbell_cause_ipi;
}
+ /* When running under a hypervisor, we can not modify tb */
+ np = of_find_node_by_path("/hypervisor");
+ if (np) {
+ smp_85xx_ops.give_timebase = NULL;
+ smp_85xx_ops.take_timebase = NULL;
+ }
+
smp_ops = &smp_85xx_ops;
>>>
>>> Again, for 85xx we should *never* sync the timebase in the kernel,
>>> hypervisor or no.
>>
>> The code says "if the kexec config option is enabled, do the sync". I'm
>> fairly sure it's there for a reason.
>
> Sigh. I forgot about that. It's because instead of doing kexec the
> simple way, we actually physically reset the core. We really shouldn't
> do that. And we *really* shouldn't do it just because CONFIG_KEXEC is
> defined, regardless of whether we're actually booting from kexec.
How would one rocver a core that's off in the weeds? We need to at
least stop it somehow before we restart into the kdump kernel. kexec
seems feasible since we have all the cores in a known state...
-M
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 0/7] powerpc: remove the legacy iSeries platform specific drivers
On Thu, Mar 08, 2012 at 03:28:53PM +1100, Stephen Rothwell wrote: > Hi all, > > This series of patches removes all the legacy iSeries platform specific > drivers (and the iSeries specific part of one). The legacy iSeries > platform main code has already bee removed along with CONFIG_PPC_ISERIES, > so none of this code is selectable or needed any more. > > It would probably be easiest if all these patches were merged via the > powerpc tree to eliminate any dependencies between them. Their impact on > generic code is very small. No objection from me at all. greg k-h ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] PPC: Don't sync timebase when inside VM
On 03/08/2012 11:31 AM, McClintock Matthew-B29882 wrote: > On Fri, Mar 2, 2012 at 11:17 AM, Scott Wood wrote: >> On 03/02/2012 10:30 AM, Alexander Graf wrote: >>> >>> On 02.03.2012, at 17:20, Scott Wood wrote: Again, for 85xx we should *never* sync the timebase in the kernel, hypervisor or no. >>> >>> The code says "if the kexec config option is enabled, do the sync". I'm >>> fairly sure it's there for a reason. >> >> Sigh. I forgot about that. It's because instead of doing kexec the >> simple way, we actually physically reset the core. We really shouldn't >> do that. And we *really* shouldn't do it just because CONFIG_KEXEC is >> defined, regardless of whether we're actually booting from kexec. > > How would one rocver a core that's off in the weeds? System reset? I thought kexec was for upgrading your kernel, not recovering from crashes. > We need to at least stop it somehow before we restart into the kdump kernel. > kexec > seems feasible since we have all the cores in a known state... Stop, yes. Reset, no. -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] PPC: Don't sync timebase when inside VM
On Thu, Mar 8, 2012 at 12:20 PM, Scott Wood wrote: > On 03/08/2012 11:31 AM, McClintock Matthew-B29882 wrote: >> On Fri, Mar 2, 2012 at 11:17 AM, Scott Wood wrote: >>> On 03/02/2012 10:30 AM, Alexander Graf wrote: On 02.03.2012, at 17:20, Scott Wood wrote: > Again, for 85xx we should *never* sync the timebase in the kernel, > hypervisor or no. The code says "if the kexec config option is enabled, do the sync". I'm fairly sure it's there for a reason. >>> >>> Sigh. I forgot about that. It's because instead of doing kexec the >>> simple way, we actually physically reset the core. We really shouldn't >>> do that. And we *really* shouldn't do it just because CONFIG_KEXEC is >>> defined, regardless of whether we're actually booting from kexec. >> >> How would one rocver a core that's off in the weeds? > > System reset? kdump restarts a kernel using a reserved memory region to inspect the memory of the crashed kernel. Wouldn't system reset cause issues here? > I thought kexec was for upgrading your kernel, not recovering from crashes. > >> We need to at least stop it somehow before we restart into the kdump kernel. >> kexec >> seems feasible since we have all the cores in a known state... > > Stop, yes. Reset, no. How would we stop the remaining cores assuming they could be in any state? -M ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] PPC: Don't sync timebase when inside VM
On 03/08/2012 12:24 PM, McClintock Matthew-B29882 wrote: > On Thu, Mar 8, 2012 at 12:20 PM, Scott Wood wrote: >> On 03/08/2012 11:31 AM, McClintock Matthew-B29882 wrote: >>> On Fri, Mar 2, 2012 at 11:17 AM, Scott Wood wrote: On 03/02/2012 10:30 AM, Alexander Graf wrote: > > On 02.03.2012, at 17:20, Scott Wood wrote: >> Again, for 85xx we should *never* sync the timebase in the kernel, >> hypervisor or no. > > The code says "if the kexec config option is enabled, do the sync". I'm > fairly sure it's there for a reason. Sigh. I forgot about that. It's because instead of doing kexec the simple way, we actually physically reset the core. We really shouldn't do that. And we *really* shouldn't do it just because CONFIG_KEXEC is defined, regardless of whether we're actually booting from kexec. >>> >>> How would one rocver a core that's off in the weeds? >> >> System reset? > > kdump restarts a kernel using a reserved memory region to inspect the > memory of the crashed kernel. Wouldn't system reset cause issues here? Oh, kdump. Maybe in that case, go ahead and reset the other cores (or halt them via some other means), but don't do anything with them. Just boot a single core in the dump kernel, do the dumping, then reset the system? Or if you must sync the timebase in Linux, do it the way U-Boot does (and skip it if you don't have access to the relevant CCSR bits). Are I/O devices a problem with kdump and not resetting the system, especially on some of our chips where certain I/O devices are difficult to reset? -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] PPC: Don't sync timebase when inside VM
On Thu, Mar 8, 2012 at 12:43 PM, Scott Wood wrote: > On 03/08/2012 12:24 PM, McClintock Matthew-B29882 wrote: >> On Thu, Mar 8, 2012 at 12:20 PM, Scott Wood wrote: >>> On 03/08/2012 11:31 AM, McClintock Matthew-B29882 wrote: On Fri, Mar 2, 2012 at 11:17 AM, Scott Wood wrote: > On 03/02/2012 10:30 AM, Alexander Graf wrote: >> >> On 02.03.2012, at 17:20, Scott Wood wrote: >>> Again, for 85xx we should *never* sync the timebase in the kernel, >>> hypervisor or no. >> >> The code says "if the kexec config option is enabled, do the sync". I'm >> fairly sure it's there for a reason. > > Sigh. I forgot about that. It's because instead of doing kexec the > simple way, we actually physically reset the core. We really shouldn't > do that. And we *really* shouldn't do it just because CONFIG_KEXEC is > defined, regardless of whether we're actually booting from kexec. How would one rocver a core that's off in the weeds? >>> >>> System reset? >> >> kdump restarts a kernel using a reserved memory region to inspect the >> memory of the crashed kernel. Wouldn't system reset cause issues here? > > Oh, kdump. > > Maybe in that case, go ahead and reset the other cores (or halt them via > some other means), but don't do anything with them. Just boot a single > core in the dump kernel, do the dumping, then reset the system? Yes, we could do one core here... but is it worthwhile to do kexec and kdump differently? > Or if you must sync the timebase in Linux, do it the way U-Boot does > (and skip it if you don't have access to the relevant CCSR bits). Ok - I've never even looked at how the timebase sync was done in Linux or u-boot. Just enabled the timebase sync > Are I/O devices a problem with kdump and not resetting the system, > especially on some of our chips where certain I/O devices are difficult > to reset? Anything still occurring will be problematic and *possibly* prevent us from determining what caused the actual crash. -M ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 19/38] KVM: PPC: e500mc: add load inst fixup
On Wed, Feb 29, 2012 at 01:09:47AM +0100, Alexander Graf wrote: > There's always a chance we're unable to read a guest instruction. The guest > could have its TLB mapped execute-, but not readable, something odd happens > and our TLB gets flushed. So it's a good idea to be prepared for that case > and have a fallback that allows us to fix things up in that case. > > Add fixup code that keeps guest code from potentially crashing our host > kernel. > > Signed-off-by: Alexander Graf > > --- > > v1 -> v2: > > - fix whitespace Still broken. > - use explicit preempt counts > --- > arch/powerpc/kvm/bookehv_interrupts.S | 30 +- > 1 files changed, 29 insertions(+), 1 deletions(-) > > diff --git a/arch/powerpc/kvm/bookehv_interrupts.S > b/arch/powerpc/kvm/bookehv_interrupts.S > index 63023ae..f7dc3f6 100644 > --- a/arch/powerpc/kvm/bookehv_interrupts.S > +++ b/arch/powerpc/kvm/bookehv_interrupts.S > @@ -28,6 +28,7 @@ > #include > #include > #include > +#include > > #include "../kernel/head_booke.h" /* for THREAD_NORMSAVE() */ > > @@ -171,9 +172,36 @@ > PPC_STL r30, VCPU_GPR(r30)(r4) > PPC_STL r31, VCPU_GPR(r31)(r4) > mtspr SPRN_EPLC, r8 > + > + /* disable preemption, so we are sure we hit the fixup handler */ > +#ifdef CONFIG_PPC64 > + clrrdi r8,r1,THREAD_SHIFT > +#else > + rlwinm r8,r1,0,0,31-THREAD_SHIFT /* current thread_info */ > +#endif > + li r7, 1 > +stw r7, TI_PREEMPT(r8) > + > isync > - lwepx r9, 0, r5 > + > + /* > + * In case the read goes wrong, we catch it and write an invalid value > + * in LAST_INST instead. > + */ > +1: lwepx r9, 0, r5 > +2: > +.section .fixup, "ax" > +3: li r9, KVM_INST_FETCH_FAILED > + b 2b > +.previous > +.section __ex_table,"a" > + PPC_LONG_ALIGN > + PPC_LONG 1b,3b > +.previous > + > mtspr SPRN_EPLC, r3 > + li r7, 0 > +stw r7, TI_PREEMPT(r8) > stw r9, VCPU_LAST_INST(r4) > .endif ___ 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 Thu, 2012-03-08 at 16:52 +1100, Benjamin Herrenschmidt wrote: > On Thu, 2012-03-08 at 14:51 +1100, Stephen Rothwell wrote: > > Hi Mikey, > > > > On Thu, 08 Mar 2012 13:33:56 +1100 Michael Neuling > > wrote: > > > > > > Surely we only need SPARSE_IRQ now and not MAY_HAVE_SPARSE_IRQ. > > > > > > In fact, keeping MAY_HAVE_SPARSE_IRQ seems to make SPARSE_IRQ user > > > selectable, which we don't want anymore since ad5b7f1350c2. > > > > Yes, indeed. I will fix up the merge resolution for tomorrow. > > This is my fault. Grant's patch had a collision and I manually fixed it > up. While doing that, I put back MAY_HAVE_SPARSE_IRQ which the patch > originally took out. 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) Cheers, Ben. ___ 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: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 ? -- Russell King Linux kernel2.6 ARM Linux - http://www.arm.linux.org.uk/ maintainer of: ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
linux-next: manual merge of the pci tree with the powerpc tree
Hi Jesse,
Today's linux-next merge of the pci tree got a conflict in
arch/powerpc/platforms/iseries/pci.c between commit 8ee3e0d69623
("powerpc: Remove the main legacy iSerie platform code") from the powerpc
tree and commit 673c97562489 ("powerpc/PCI: replace pci_probe_only with
pci_flags") from the pci tree.
The former removed the file, so I did that.
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
pgpGhM7Mfi5jk.pgp
Description: PGP signature
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
linux-next: manual merge of the net-next tree with the powerpc tree
Hi all,
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.
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
pgp4opEXHOkAL.pgp
Description: PGP signature
___
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, 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. Cheers, Ben. ___ 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
- Define number of MSI interrupt for Maui APM821xx SoC using in Bluestone board
- Fix returning ENODEV as finding MSI node
- Fix MSI physical high and low address
- Keep MSI data logically
Signed-off-by: Mai La
---
arch/powerpc/platforms/44x/Kconfig |2 ++
arch/powerpc/sysdev/Kconfig|6 ++
arch/powerpc/sysdev/ppc4xx_msi.c | 27 ---
3 files changed, 24 insertions(+), 11 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/Kconfig b/arch/powerpc/sysdev/Kconfig
index 7b4df37..c86231e 100644
--- a/arch/powerpc/sysdev/Kconfig
+++ b/arch/powerpc/sysdev/Kconfig
@@ -20,6 +20,12 @@ config PPC_MSI_BITMAP
default y if FSL_PCI
default y if PPC4xx_MSI
+config PPC4xx_NR_MSI_IRQS
+ int "Number of PCI MSI interrupts"
+ depends on PCI_MSI && PPC4xx_MSI
+ default "4" if !APM821xx
+ default "8" if APM821xx
+
source "arch/powerpc/sysdev/xics/Kconfig"
config PPC_SCOM
diff --git a/arch/powerpc/sysdev/ppc4xx_msi.c b/arch/powerpc/sysdev/ppc4xx_msi.c
index 1c2d7af..3359237 100644
--- a/arch/powerpc/sysdev/ppc4xx_msi.c
+++ b/arch/powerpc/sysdev/ppc4xx_msi.c
@@ -28,10 +28,11 @@
#include
#include
#include
+#include
#include
#include
#include
-#include
+#include
#include
#include
@@ -43,7 +44,8 @@
#define PEIH_FLUSH00x30
#define PEIH_FLUSH10x38
#define PEIH_CNTRST0x48
-#define NR_MSI_IRQS4
+
+#define NR_MSI_IRQS CONFIG_PPC4xx_NR_MSI_IRQS
struct ppc4xx_msi {
u32 msi_addr_lo;
@@ -150,12 +152,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 +168,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 +189,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;
}
@@ -215,8 +221,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);
@@ -242,6 +246,7 @@ static int __devinit ppc4xx_msi_probe(struct
platform_device *dev)
dev_err(&dev->dev, "Error allocating MSI bitmap\n");
goto error_out;
}
+ ppc4xx_msi = *msi;
ppc_md.setup_msi_irqs = ppc4xx_setup_msi_irqs;
ppc_md.teardown_msi_irqs = ppc4xx_teardown_msi_irqs;
--
1.7.3.4
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 2/2] powerpc/44x: Add PCI MSI node for Maui APM821xx SoC and Bluestone board in DTS
Signed-off-by: Mai La
---
arch/powerpc/boot/dts/bluestone.dts | 24
1 files changed, 24 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/boot/dts/bluestone.dts
b/arch/powerpc/boot/dts/bluestone.dts
index 2a56a0d..8ea6325 100644
--- a/arch/powerpc/boot/dts/bluestone.dts
+++ b/arch/powerpc/boot/dts/bluestone.dts
@@ -250,5 +250,29 @@
};
};
+ MSI: ppc4xx-msi@C1000 {
+ compatible = "amcc,ppc4xx-msi", "ppc4xx-msi";
+ reg = < 0xC 0x1000 0x100
+ 0xC 0x1000 0x100>;
+ sdr-base = <0x36C>;
+ msi-data = <0x4440>;
+ msi-mask = <0xffe0>;
+ interrupts =<0 1 2 3 4 5 6 7>;
+ interrupt-parent = <&MSI>;
+ #interrupt-cells = <1>;
+ #address-cells = <0>;
+ #size-cells = <0>;
+ msi-available-ranges = <0x0 0x100>;
+ interrupt-map = <
+ 0 &UIC3 0x18 1
+ 1 &UIC3 0x19 1
+ 2 &UIC3 0x1A 1
+ 3 &UIC3 0x1B 1
+ 4 &UIC3 0x1C 1
+ 5 &UIC3 0x1D 1
+ 6 &UIC3 0x1E 1
+ 7 &UIC3 0x1F 1
+ >;
+ };
};
};
--
1.7.3.4
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
3.3.0-rc6-next-20120308 boot failure on POWER7 blade
Hi, I'm seeing this on a POWER7 blade booting 3.3.0-rc6-next-20120308: PCI host bridge to bus :00 pci_bus :00: root bus resource [io 0x10-0x10] (bus address [0xf-0xf]) pci_bus :00: root bus resource [mem 0x3b00-0x3b001fff] (bus address [0xe000-0x]) IOMMU table initialized, virtual merging enabled PCI host bridge to bus 0001:00 pci_bus 0001:00: root bus resource [io 0x21-0x21] (bus address [0xf-0xf]) pci_bus 0001:00: root bus resource [mem 0x3b008000-0x3b00] (bus address [0x8000-0x]) PCI host bridge to bus 0002:01 pci_bus 0002:01: root bus resource [io 0x32-0x32] (bus address [0xf-0xf]) pci_bus 0002:01: root bus resource [mem 0x3b04-0x3b041fef] (bus address [0xe000-0xffef]) PCI: Cannot allocate resource region 0 of device :00:01.0, will remap PCI: Cannot allocate resource region 2 of device :00:01.0, will remap PCI: Cannot allocate resource region 6 of device :00:01.0, will remap PCI: Cannot allocate resource region 0 of device 0001:00:01.0, will remap PCI: Cannot allocate resource region 0 of device 0001:00:01.1, will remap PCI: Cannot allocate resource region 0 of device 0001:00:01.2, will remap PCI: Cannot allocate resource region 0 of device 0002:01:00.0, will remap PCI: Cannot allocate resource region 2 of device 0002:01:00.0, will remap ... pci 0001:00:01.0: device not available (can't reserve [mem 0x-0x0fff]) pci 0001:00:01.0: Can't enable PCI device, BIOS handoff failed. pci 0001:00:01.1: device not available (can't reserve [mem 0x-0x0fff]) pci 0001:00:01.1: Can't enable PCI device, BIOS handoff failed. pci 0001:00:01.2: device not available (can't reserve [mem 0x-0x00ff]) pci 0001:00:01.2: Can't enable PCI device, BIOS handoff failed. Then we fail to find the root device. I haven't had a chance to chase the cause of it down yet. Anton ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: 3.3.0-rc6-next-20120308 boot failure on POWER7 blade
On Fri, 2012-03-09 at 14:25 +1100, Anton Blanchard wrote: > Hi, > > I'm seeing this on a POWER7 blade booting 3.3.0-rc6-next-20120308: Looks like something that got fixed but the new patches from Bjorn aren't in next yet. I'll fwd you the patch separately to apply on top of what you have see if that helps (to confirm that's indeed the issue). Cheers, Ben. > > PCI host bridge to bus :00 > pci_bus :00: root bus resource [io 0x10-0x10] (bus address > [0xf-0xf]) > pci_bus :00: root bus resource [mem 0x3b00-0x3b001fff] (bus > address [0xe000-0x]) > IOMMU table initialized, virtual merging enabled > PCI host bridge to bus 0001:00 > pci_bus 0001:00: root bus resource [io 0x21-0x21] (bus address > [0xf-0xf]) > pci_bus 0001:00: root bus resource [mem 0x3b008000-0x3b00] (bus > address [0x8000-0x]) > PCI host bridge to bus 0002:01 > pci_bus 0002:01: root bus resource [io 0x32-0x32] (bus address > [0xf-0xf]) > pci_bus 0002:01: root bus resource [mem 0x3b04-0x3b041fef] (bus > address [0xe000-0xffef]) > PCI: Cannot allocate resource region 0 of device :00:01.0, will remap > PCI: Cannot allocate resource region 2 of device :00:01.0, will remap > PCI: Cannot allocate resource region 6 of device :00:01.0, will remap > PCI: Cannot allocate resource region 0 of device 0001:00:01.0, will remap > PCI: Cannot allocate resource region 0 of device 0001:00:01.1, will remap > PCI: Cannot allocate resource region 0 of device 0001:00:01.2, will remap > PCI: Cannot allocate resource region 0 of device 0002:01:00.0, will remap > PCI: Cannot allocate resource region 2 of device 0002:01:00.0, will > remap > > ... > > pci 0001:00:01.0: device not available (can't reserve [mem > 0x-0x0fff]) > pci 0001:00:01.0: Can't enable PCI device, BIOS handoff failed. > pci 0001:00:01.1: device not available (can't reserve [mem > 0x-0x0fff]) > pci 0001:00:01.1: Can't enable PCI device, BIOS handoff failed. > pci 0001:00:01.2: device not available (can't reserve [mem > 0x-0x00ff]) > pci 0001:00:01.2: Can't enable PCI device, BIOS handoff failed. > > > Then we fail to find the root device. I haven't had a chance > to chase the cause of it down yet. > > Anton ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/2] powerpc/44x: Fix PCI MSI support for Maui APM821xx SoC and Bluestone board
On Fri, 2012-03-09 at 10:17 +0700, Mai La wrote: > This patch consists of: > - Enable PCI MSI as default for Bluestone board > - Define number of MSI interrupt for Maui APM821xx SoC using in Bluestone > board > - Fix returning ENODEV as finding MSI node > - Fix MSI physical high and low address > - Keep MSI data logically > > Signed-off-by: Mai La > --- > index 7b4df37..c86231e 100644 > --- a/arch/powerpc/sysdev/Kconfig > +++ b/arch/powerpc/sysdev/Kconfig > @@ -20,6 +20,12 @@ config PPC_MSI_BITMAP > default y if FSL_PCI > default y if PPC4xx_MSI > > +config PPC4xx_NR_MSI_IRQS > + int "Number of PCI MSI interrupts" > + depends on PCI_MSI && PPC4xx_MSI > + default "4" if !APM821xx > + default "8" if APM821xx > + .../... > +#define NR_MSI_IRQS CONFIG_PPC4xx_NR_MSI_IRQS ARGH. We asked to -NOT MAKE THIS A COMPILE TIME OPTION- CONFIG_foo is as bad as your previous ifdef, in fact you just added a useless config option here. Make that number dynamic. Count the entries in the device-tree (or add a property with the number in it, whatever you fancy the most) but make it something detected at RUNTIME ! Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: 3.3.0-rc6-next-20120308 boot failure on POWER7 blade
Hi Ben,
> Looks like something that got fixed but the new patches from Bjorn
> aren't in next yet. I'll fwd you the patch separately to apply on top
> of what you have see if that helps (to confirm that's indeed the
> issue).
Thanks, confirmed that it fixes it. Patch below in case anyone else is
hitting it.
Anton
--
On Sat, 2012-03-03 at 08:52 +1100, Benjamin Herrenschmidt wrote:
> Or give me a chance to dig :-) I'll have a look next week.
This is indeed what bjorn suspected on irc, this patch fixes it:
(Bjorn, please fold it in the original offending patch)
Cheers,
Ben.
diff --git a/arch/powerpc/kernel/pci_of_scan.c
b/arch/powerpc/kernel/pci_of_scan.c
index b37d0b5..5dd63f1 100644
--- a/arch/powerpc/kernel/pci_of_scan.c
+++ b/arch/powerpc/kernel/pci_of_scan.c
@@ -75,6 +75,7 @@ static void of_pci_parse_addrs(struct device_node *node,
struct pci_dev *dev)
{
u64 base, size;
unsigned int flags;
+ struct pci_bus_region region;
struct resource *res;
const u32 *addrs;
u32 i;
@@ -106,10 +107,12 @@ static void of_pci_parse_addrs(struct device_node *node,
struct pci_dev *dev)
printk(KERN_ERR "PCI: bad cfg reg num 0x%x\n", i);
continue;
}
- res->start = base;
- res->end = base + size - 1;
+
res->flags = flags;
res->name = pci_name(dev);
+ region.start = base;
+ region.end = base + size - 1;
+ pcibios_bus_to_resource(dev, res, ®ion);
}
}
@@ -209,6 +212,7 @@ void __devinit of_scan_pci_bridge(struct pci_dev *dev)
struct pci_bus *bus;
const u32 *busrange, *ranges;
int len, i, mode;
+ struct pci_bus_region region;
struct resource *res;
unsigned int flags;
u64 size;
@@ -270,9 +274,10 @@ void __devinit of_scan_pci_bridge(struct pci_dev *dev)
res = bus->resource[i];
++i;
}
- res->start = of_read_number(&ranges[1], 2);
- res->end = res->start + size - 1;
res->flags = flags;
+ region.start = of_read_number(&ranges[1], 2);
+ region.end = region.start + size - 1;
+ pcibios_bus_to_resource(dev, res, ®ion);
}
sprintf(bus->name, "PCI Bus %04x:%02x", pci_domain_nr(bus),
bus->number);
--=-aDzdhtAsqTK5gqnOark/--
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
linux-next: manual merge of the tip tree with the powerpc tree
Hi all,
Today's linux-next merge of the tip tree got a conflict in
arch/powerpc/platforms/iseries/setup.c between commit 8ee3e0d69623
("powerpc: Remove the main legacy iSerie platform code") from the powerpc
tree and commit bd2f55361f18 ("sched/rt: Use schedule_preempt_disabled()")
from the tip tree.
The former removed the file, so I did that.
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
pgpnXGnliYgs4.pgp
Description: PGP signature
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
linux-next: manual merge of the driver-core tree with the powerpc tree
Hi Greg,
Today's linux-next merge of the driver-core tree got a conflict in
drivers/base/driver.c between commit fcd6f7620202 ("driver-core: remove
legacy iSeries hack") from the powerpc tree and commit 9875bb480cc8
("Eliminate get_driver() and put_driver()") from the driver-core tree.
Just context changes. I fixed it up (see below) and can carry the fix as
necessary.
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
diff --cc drivers/base/driver.c
index db4f54c,60e4f77..000
--- a/drivers/base/driver.c
+++ b/drivers/base/driver.c
@@@ -123,34 -123,36 +123,6 @@@ void driver_remove_file(struct device_d
}
EXPORT_SYMBOL_GPL(driver_remove_file);
--/**
- * get_driver - increment driver reference count.
- * @drv: driver.
- */
- struct device_driver *get_driver(struct device_driver *drv)
- {
- if (drv) {
- struct driver_private *priv;
- struct kobject *kobj;
-
- kobj = kobject_get(&drv->p->kobj);
- priv = to_driver(kobj);
- return priv->driver;
- }
- return NULL;
- }
- EXPORT_SYMBOL_GPL(get_driver);
-
- /**
- * put_driver - decrement driver's refcount.
- * @drv: driver.
- */
- void put_driver(struct device_driver *drv)
- {
- kobject_put(&drv->p->kobj);
- }
- EXPORT_SYMBOL_GPL(put_driver);
-
- * driver_add_kobj - add a kobject below the specified driver
- * @drv: requesting device driver
- * @kobj: kobject to add below this driver
- * @fmt: format string that names the kobject
- *
- * You really don't want to do this, this is only here due to one looney
- * iseries driver, go poke those developers if you are annoyed about
- * this...
- */
-int driver_add_kobj(struct device_driver *drv, struct kobject *kobj,
- const char *fmt, ...)
-{
- va_list args;
- char *name;
- int ret;
-
- va_start(args, fmt);
- name = kvasprintf(GFP_KERNEL, fmt, args);
- va_end(args);
-
- if (!name)
- return -ENOMEM;
-
- ret = kobject_add(kobj, &drv->p->kobj, "%s", name);
- kfree(name);
- return ret;
-}
-EXPORT_SYMBOL_GPL(driver_add_kobj);
-
static int driver_add_groups(struct device_driver *drv,
const struct attribute_group **groups)
{
pgpgg0g0MD5ry.pgp
Description: PGP signature
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: linux-next: manual merge of the net-next tree with the powerpc tree
From: Stephen Rothwell
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.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: linux-next: manual merge of the net-next tree with the powerpc tree
Hi Dave,
On Thu, 08 Mar 2012 22:15:34 -0800 (PST) David Miller
wrote:
>
> From: Stephen Rothwell
> 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.
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
pgpj4cAvY3lGm.pgp
Description: PGP signature
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
linux-next: manual merge of the irqdomain tree with the powerpc tree
Hi Grant,
Today's linux-next merge of the irqdomain tree got a conflict in
arch/powerpc/platforms/iseries/irq.c between commit 8ee3e0d69623
("powerpc: Remove the main legacy iSerie platform code") from the tree
and three commits from the irqdomain tree.
I just removed the file.
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
pgphoNjUFKjK0.pgp
Description: PGP signature
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
