* RE: [PATCH 0/2 v3] mpc5200 ac97 gpio reset
From: Eric Millbrandt @ 2010-08-05 12:59 UTC (permalink / raw)
To: 'Mark Brown', Grant Likely; +Cc: linuxppc-dev@lists.ozlabs.org
In-Reply-To: <20100803055216.GA25306@rakim.wolfsonmicro.main>
> -----Original Message-----
> From: linuxppc-dev-bounces+emillbrandt=3Ddekaresearch.com@lists.ozlabs.or=
g
> [mailto:linuxppc-dev-
> bounces+emillbrandt=3Ddekaresearch.com@lists.ozlabs.org] On Behalf Of Mar=
k
> Brown
> Sent: Tuesday, August 03, 2010 01:52
> To: Grant Likely
> Cc: linuxppc-dev@lists.ozlabs.org; Eric Millbrandt
> Subject: Re: [PATCH 0/2 v3] mpc5200 ac97 gpio reset
>
> On Sat, Jul 31, 2010 at 10:42:15PM -0600, Grant Likely wrote:
> > On Sun, Jun 27, 2010 at 4:01 PM, Mark Brown
>
> > > I'm a little concerned with a collision with multi codec here. It'd
> > > be handy if you could keep it separate in case it needs merging
> > > into both trees (or we could merge via ASoC only).
>
> > Hmmm. Yeah, probably better to take it via your tree then. I've
> > currently got patch 1 in linux-next, but I'll drop it before asking
> > benh to pull. Go ahead and add my acked-by.
>
> Looks like multi-component is slightly too late for .36 and I don't have
> the original patch any more since it looked like you were going to be
> carrying it... could you restore the patch to your tree please?
<ping> Grant, are you going to pick up this series for .36?
Eric
-DISCLAIMER: an automatically appended disclaimer may follow. By posting-
-to a public e-mail mailing list I hereby grant permission to distribute-
-and copy this message.-
This e-mail and the information, including any attachments, it contains are=
intended to be a confidential communication only to the person or entity t=
o whom it is addressed and may contain information that is privileged. If t=
he reader of this message is not the intended recipient, you are hereby not=
ified that any dissemination, distribution or copying of this communication=
is strictly prohibited. If you have received this communication in error, =
please immediately notify the sender and destroy the original message.
Thank you.
Please consider the environment before printing this email.
^ permalink raw reply
* Re: [PATCH] powerpc: ONLINE to OFFLINE CPU state transition during removal
From: Vaidyanathan Srinivasan @ 2010-08-05 13:31 UTC (permalink / raw)
To: Nathan Fontenot
Cc: Gautham R Shenoy, Julia Lawall, Paul Mackerras, linuxppc-dev
In-Reply-To: <4C4DDE5F.7090207@austin.ibm.com>
* Nathan Fontenot <nfont@austin.ibm.com> [2010-07-26 14:13:35]:
> On 07/22/2010 11:13 PM, Vaidyanathan Srinivasan wrote:
> > * Robert Jennings <rcj@linux.vnet.ibm.com> [2010-07-22 21:43:44]:
> >
> >> If a CPU remove is attempted using the 'release' interface on hardware
> >> which supports extended cede, the CPU will be put in the INACTIVE state
> >> rather than the OFFLINE state due to the default preferred_offline_state
> >> in that situation. In the INACTIVE state it will fail to be removed.
> >>
> >> This patch changes the preferred offline state to OFFLINE when an CPU is
> >> in the ONLINE state. After cpu_down() is called in dlpar_offline_cpu()
> >> the CPU will be OFFLINE and CPU removal can continue.
> >
> > Hi Robert,
> >
> > Thanks for the patch. In dlpar operation, we would offline the CPU
> > first using the sysfs online file and then write to the sysfs release
> > file to complete the sequence right? The current code in
> > dlpar_offline_cpu() would work as long as the cpu is in either
> > inactive state or offline state (in case of unsupported platform).
> >
> > Is the dlpar tools being changed to complete the operation with one
> > sysfs write to release file?
>
> The dlpar tools were updated so that a single write to the 'release' file
> would offline the cpu and remove it from the system. Given this, I think
> Robert's patch should go forward to maintain compatability.
Hi Nathan,
Thanks for clarifying. One concern that I have is that this change
could race with sysfs write to cpuN/online file.
dlpar_offline_cpu() is called with cpu_hotplug_driver_lock() held so
the sysfs operation on online file should wait. However by the time
the cpu_hotplug_driver_unlock() happens the dlpar operation should
have completed and we should not be able to online or offline the cpu
from sysfs online file.
I wanted to confirm whether any concurrent sysfs write will not cause
the dlpar operation to fail in the middle of the operation.
The previous code will work fine for platforms not supporting
cede_offline where we have only two states for the cpu.
When cede_offline is supported, we have three states and the state
transitions are controlled by online file and the release file in two
steps so that the failures can be retried in user space.
This patch will work and I do not see any problem as such, but we
still need to carefully evaluate the retry and error handling paths
before switching over to a single sysfs write based dlpar operation.
--Vaidy
^ permalink raw reply
* Re: Commit 3da34aa brakes MSI support on MPC8308 (possibly all MPC83xx) [REPOST]
From: Kumar Gala @ 2010-08-05 13:50 UTC (permalink / raw)
To: Ilya Yanok; +Cc: linuxppc-dev, Wolfgang Denk
In-Reply-To: <4C5A7525.10105@emcraft.com>
On Aug 5, 2010, at 3:24 AM, Ilya Yanok wrote:
> Hi Kumar,
>=20
> 05.08.2010 11:01, Kumar Gala =D0=BF=D0=B8=D1=88=D0=B5=D1=82:
>> I have a fix, can you test?
>=20
> Surely. Where can I find it?
>=20
> Thanks.
>=20
> Regards, Ilya.
http://patchwork.ozlabs.org/patch/60934/
- k
^ permalink raw reply
* Re: [PATCH] asoc/multi-component: fsl: add support for disabled SSI nodes
From: Kumar Gala @ 2010-08-05 13:51 UTC (permalink / raw)
To: Timur Tabi; +Cc: linuxppc-dev, alsa-devel, broonie, lrg
In-Reply-To: <1280962268-31407-1-git-send-email-timur@freescale.com>
On Aug 4, 2010, at 5:51 PM, Timur Tabi wrote:
> Add support for adding "status =3D disabled" to an SSI node to =
incidate that it
> is not wired on the board. This replaces the not-so-intuitive =
previous method
> of omitting a codec-handle property.
>=20
> Signed-off-by: Timur Tabi <timur@freescale.com>
> ---
>=20
> Kumar, would you please ACK the device-tree portion of this patch? I =
want
> it to go through the ALSA tree.
>=20
> arch/powerpc/boot/dts/mpc8610_hpcd.dts | 1 +
> sound/soc/fsl/fsl_ssi.c | 13 ++++++++++---
> 2 files changed, 11 insertions(+), 3 deletions(-)
Acked-by: Kumar Gala <galak@kernel.crashing.org>
- k=
^ permalink raw reply
* [PATCH 2/3] powerpc: implement arch_setup_pdev_archdata
From: Kumar Gala @ 2010-08-05 15:15 UTC (permalink / raw)
To: gregkh; +Cc: linuxppc-dev, akpm, linux-kernel
In-Reply-To: <1281021347-1278-2-git-send-email-galak@kernel.crashing.org>
We have a long standing issues with platform devices not have a valid
dma_mask pointer. This hasn't been an issue to date as no platform
device has tried to set its dma_mask value to a non-default value.
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
---
arch/powerpc/include/asm/platform_device.h | 16 +++++++++++++++-
1 files changed, 15 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/include/asm/platform_device.h b/arch/powerpc/include/asm/platform_device.h
index 01452c3..a379500 100644
--- a/arch/powerpc/include/asm/platform_device.h
+++ b/arch/powerpc/include/asm/platform_device.h
@@ -1 +1,15 @@
-#include <asm-generic/platform_device.h>
+#ifndef __ASM_PLATFORM_DEVICE_H_
+#define __ASM_PLATFORM_DEVICE_H_
+
+#include <linux/platform_device.h>
+
+#define ARCH_HAS_PDEV_ARCHDATA_SETUP
+
+static inline void arch_setup_pdev_archdata(struct platform_device *pdev)
+{
+ pdev->dev.dma_mask = &pdev->archdata.dma_mask;
+
+ return;
+}
+
+#endif /* __ASM_GENERIC_PLATFORM_DEVICE_H_ */
--
1.6.0.6
^ permalink raw reply related
* [PATCH 3/3] powerpc: Dont require a dma_ops struct to set dma mask
From: Kumar Gala @ 2010-08-05 15:15 UTC (permalink / raw)
To: gregkh; +Cc: linuxppc-dev, akpm, linux-kernel
In-Reply-To: <1281021347-1278-3-git-send-email-galak@kernel.crashing.org>
The only reason to require a dma_ops struct is to see if it has
implemented set_dma_mask. If not we can fall back to setting the mask
directly.
This resolves an issue with how to sequence the setting of a DMA mask
for platform devices. Before we had an issue in that we have no way of
setting the DMA mask before the various low level bus notifiers get
called that might check it (swiotlb).
So now we can do:
pdev = platform_device_alloc("foobar", 0);
dma_set_mask(&pdev->dev, DMA_BIT_MASK(37));
platform_device_register(pdev);
And expect the right thing to happen with the bus notifiers get called
via platform_device_register.
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
---
arch/powerpc/include/asm/dma-mapping.h | 6 ++----
1 files changed, 2 insertions(+), 4 deletions(-)
diff --git a/arch/powerpc/include/asm/dma-mapping.h b/arch/powerpc/include/asm/dma-mapping.h
index c85ef23..952208a 100644
--- a/arch/powerpc/include/asm/dma-mapping.h
+++ b/arch/powerpc/include/asm/dma-mapping.h
@@ -131,12 +131,10 @@ static inline int dma_set_mask(struct device *dev, u64 dma_mask)
{
struct dma_map_ops *dma_ops = get_dma_ops(dev);
- if (unlikely(dma_ops == NULL))
- return -EIO;
- if (dma_ops->set_dma_mask != NULL)
- return dma_ops->set_dma_mask(dev, dma_mask);
if (!dev->dma_mask || !dma_supported(dev, dma_mask))
return -EIO;
+ if (dma_ops && (dma_ops->set_dma_mask != NULL))
+ return dma_ops->set_dma_mask(dev, dma_mask);
*dev->dma_mask = dma_mask;
return 0;
}
--
1.6.0.6
^ permalink raw reply related
* [PATCH 1/3] driver core: Add ability for arch code to setup pdev_archdata
From: Kumar Gala @ 2010-08-05 15:15 UTC (permalink / raw)
To: gregkh; +Cc: linuxppc-dev, akpm, linux-kernel
In-Reply-To: <1281021347-1278-1-git-send-email-galak@kernel.crashing.org>
On some architectures we need to setup pdev_archdata before we add the
device. Waiting til a bus_notifier is too late since we might need the
pdev_archdata in the bus notifier. One example is setting up of dma_mask
pointers such that it can be used in a bus_notifier.
We add ARCH_HAS_PDEV_ARCHDATA_SETUP and a dummy <asm/platform_device.h>
header to allow the arch code to have an inline implementation of
arch_setup_pdev_archdata() and being able to access the full definitions
of struct device, struct platform_device, and struct pdev_archdata.
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
---
arch/alpha/include/asm/platform_device.h | 1 +
arch/arm/include/asm/platform_device.h | 1 +
arch/avr32/include/asm/platform_device.h | 1 +
arch/blackfin/include/asm/platform_device.h | 1 +
arch/cris/include/asm/platform_device.h | 1 +
arch/frv/include/asm/platform_device.h | 1 +
arch/h8300/include/asm/platform_device.h | 1 +
arch/ia64/include/asm/platform_device.h | 1 +
arch/m32r/include/asm/platform_device.h | 1 +
arch/m68k/include/asm/platform_device.h | 1 +
arch/microblaze/include/asm/platform_device.h | 1 +
arch/mips/include/asm/platform_device.h | 1 +
arch/mn10300/include/asm/platform_device.h | 1 +
arch/parisc/include/asm/platform_device.h | 1 +
arch/powerpc/include/asm/platform_device.h | 1 +
arch/s390/include/asm/platform_device.h | 1 +
arch/score/include/asm/platform_device.h | 1 +
arch/sh/include/asm/platform_device.h | 1 +
arch/sparc/include/asm/platform_device.h | 1 +
arch/x86/include/asm/platform_device.h | 1 +
arch/xtensa/include/asm/platform_device.h | 1 +
drivers/base/platform.c | 4 ++++
include/asm-generic/platform_device.h | 7 +++++++
23 files changed, 32 insertions(+), 0 deletions(-)
create mode 100644 arch/alpha/include/asm/platform_device.h
create mode 100644 arch/arm/include/asm/platform_device.h
create mode 100644 arch/avr32/include/asm/platform_device.h
create mode 100644 arch/blackfin/include/asm/platform_device.h
create mode 100644 arch/cris/include/asm/platform_device.h
create mode 100644 arch/frv/include/asm/platform_device.h
create mode 100644 arch/h8300/include/asm/platform_device.h
create mode 100644 arch/ia64/include/asm/platform_device.h
create mode 100644 arch/m32r/include/asm/platform_device.h
create mode 100644 arch/m68k/include/asm/platform_device.h
create mode 100644 arch/microblaze/include/asm/platform_device.h
create mode 100644 arch/mips/include/asm/platform_device.h
create mode 100644 arch/mn10300/include/asm/platform_device.h
create mode 100644 arch/parisc/include/asm/platform_device.h
create mode 100644 arch/powerpc/include/asm/platform_device.h
create mode 100644 arch/s390/include/asm/platform_device.h
create mode 100644 arch/score/include/asm/platform_device.h
create mode 100644 arch/sh/include/asm/platform_device.h
create mode 100644 arch/sparc/include/asm/platform_device.h
create mode 100644 arch/x86/include/asm/platform_device.h
create mode 100644 arch/xtensa/include/asm/platform_device.h
create mode 100644 include/asm-generic/platform_device.h
diff --git a/arch/alpha/include/asm/platform_device.h b/arch/alpha/include/asm/platform_device.h
new file mode 100644
index 0000000..01452c3
--- /dev/null
+++ b/arch/alpha/include/asm/platform_device.h
@@ -0,0 +1 @@
+#include <asm-generic/platform_device.h>
diff --git a/arch/arm/include/asm/platform_device.h b/arch/arm/include/asm/platform_device.h
new file mode 100644
index 0000000..01452c3
--- /dev/null
+++ b/arch/arm/include/asm/platform_device.h
@@ -0,0 +1 @@
+#include <asm-generic/platform_device.h>
diff --git a/arch/avr32/include/asm/platform_device.h b/arch/avr32/include/asm/platform_device.h
new file mode 100644
index 0000000..01452c3
--- /dev/null
+++ b/arch/avr32/include/asm/platform_device.h
@@ -0,0 +1 @@
+#include <asm-generic/platform_device.h>
diff --git a/arch/blackfin/include/asm/platform_device.h b/arch/blackfin/include/asm/platform_device.h
new file mode 100644
index 0000000..01452c3
--- /dev/null
+++ b/arch/blackfin/include/asm/platform_device.h
@@ -0,0 +1 @@
+#include <asm-generic/platform_device.h>
diff --git a/arch/cris/include/asm/platform_device.h b/arch/cris/include/asm/platform_device.h
new file mode 100644
index 0000000..01452c3
--- /dev/null
+++ b/arch/cris/include/asm/platform_device.h
@@ -0,0 +1 @@
+#include <asm-generic/platform_device.h>
diff --git a/arch/frv/include/asm/platform_device.h b/arch/frv/include/asm/platform_device.h
new file mode 100644
index 0000000..01452c3
--- /dev/null
+++ b/arch/frv/include/asm/platform_device.h
@@ -0,0 +1 @@
+#include <asm-generic/platform_device.h>
diff --git a/arch/h8300/include/asm/platform_device.h b/arch/h8300/include/asm/platform_device.h
new file mode 100644
index 0000000..01452c3
--- /dev/null
+++ b/arch/h8300/include/asm/platform_device.h
@@ -0,0 +1 @@
+#include <asm-generic/platform_device.h>
diff --git a/arch/ia64/include/asm/platform_device.h b/arch/ia64/include/asm/platform_device.h
new file mode 100644
index 0000000..01452c3
--- /dev/null
+++ b/arch/ia64/include/asm/platform_device.h
@@ -0,0 +1 @@
+#include <asm-generic/platform_device.h>
diff --git a/arch/m32r/include/asm/platform_device.h b/arch/m32r/include/asm/platform_device.h
new file mode 100644
index 0000000..01452c3
--- /dev/null
+++ b/arch/m32r/include/asm/platform_device.h
@@ -0,0 +1 @@
+#include <asm-generic/platform_device.h>
diff --git a/arch/m68k/include/asm/platform_device.h b/arch/m68k/include/asm/platform_device.h
new file mode 100644
index 0000000..01452c3
--- /dev/null
+++ b/arch/m68k/include/asm/platform_device.h
@@ -0,0 +1 @@
+#include <asm-generic/platform_device.h>
diff --git a/arch/microblaze/include/asm/platform_device.h b/arch/microblaze/include/asm/platform_device.h
new file mode 100644
index 0000000..01452c3
--- /dev/null
+++ b/arch/microblaze/include/asm/platform_device.h
@@ -0,0 +1 @@
+#include <asm-generic/platform_device.h>
diff --git a/arch/mips/include/asm/platform_device.h b/arch/mips/include/asm/platform_device.h
new file mode 100644
index 0000000..01452c3
--- /dev/null
+++ b/arch/mips/include/asm/platform_device.h
@@ -0,0 +1 @@
+#include <asm-generic/platform_device.h>
diff --git a/arch/mn10300/include/asm/platform_device.h b/arch/mn10300/include/asm/platform_device.h
new file mode 100644
index 0000000..01452c3
--- /dev/null
+++ b/arch/mn10300/include/asm/platform_device.h
@@ -0,0 +1 @@
+#include <asm-generic/platform_device.h>
diff --git a/arch/parisc/include/asm/platform_device.h b/arch/parisc/include/asm/platform_device.h
new file mode 100644
index 0000000..01452c3
--- /dev/null
+++ b/arch/parisc/include/asm/platform_device.h
@@ -0,0 +1 @@
+#include <asm-generic/platform_device.h>
diff --git a/arch/powerpc/include/asm/platform_device.h b/arch/powerpc/include/asm/platform_device.h
new file mode 100644
index 0000000..01452c3
--- /dev/null
+++ b/arch/powerpc/include/asm/platform_device.h
@@ -0,0 +1 @@
+#include <asm-generic/platform_device.h>
diff --git a/arch/s390/include/asm/platform_device.h b/arch/s390/include/asm/platform_device.h
new file mode 100644
index 0000000..01452c3
--- /dev/null
+++ b/arch/s390/include/asm/platform_device.h
@@ -0,0 +1 @@
+#include <asm-generic/platform_device.h>
diff --git a/arch/score/include/asm/platform_device.h b/arch/score/include/asm/platform_device.h
new file mode 100644
index 0000000..01452c3
--- /dev/null
+++ b/arch/score/include/asm/platform_device.h
@@ -0,0 +1 @@
+#include <asm-generic/platform_device.h>
diff --git a/arch/sh/include/asm/platform_device.h b/arch/sh/include/asm/platform_device.h
new file mode 100644
index 0000000..01452c3
--- /dev/null
+++ b/arch/sh/include/asm/platform_device.h
@@ -0,0 +1 @@
+#include <asm-generic/platform_device.h>
diff --git a/arch/sparc/include/asm/platform_device.h b/arch/sparc/include/asm/platform_device.h
new file mode 100644
index 0000000..01452c3
--- /dev/null
+++ b/arch/sparc/include/asm/platform_device.h
@@ -0,0 +1 @@
+#include <asm-generic/platform_device.h>
diff --git a/arch/x86/include/asm/platform_device.h b/arch/x86/include/asm/platform_device.h
new file mode 100644
index 0000000..01452c3
--- /dev/null
+++ b/arch/x86/include/asm/platform_device.h
@@ -0,0 +1 @@
+#include <asm-generic/platform_device.h>
diff --git a/arch/xtensa/include/asm/platform_device.h b/arch/xtensa/include/asm/platform_device.h
new file mode 100644
index 0000000..01452c3
--- /dev/null
+++ b/arch/xtensa/include/asm/platform_device.h
@@ -0,0 +1 @@
+#include <asm-generic/platform_device.h>
diff --git a/drivers/base/platform.c b/drivers/base/platform.c
index 4d99c8b..165b454 100644
--- a/drivers/base/platform.c
+++ b/drivers/base/platform.c
@@ -19,6 +19,7 @@
#include <linux/err.h>
#include <linux/slab.h>
#include <linux/pm_runtime.h>
+#include <asm/platform_device.h>
#include "base.h"
@@ -170,6 +171,9 @@ struct platform_device *platform_device_alloc(const char *name, int id)
pa->pdev.id = id;
device_initialize(&pa->pdev.dev);
pa->pdev.dev.release = platform_device_release;
+#ifdef ARCH_HAS_PDEV_ARCHDATA_SETUP
+ arch_setup_pdev_archdata(&pa->pdev);
+#endif
}
return pa ? &pa->pdev : NULL;
diff --git a/include/asm-generic/platform_device.h b/include/asm-generic/platform_device.h
new file mode 100644
index 0000000..64806dc
--- /dev/null
+++ b/include/asm-generic/platform_device.h
@@ -0,0 +1,7 @@
+#ifndef __ASM_GENERIC_PLATFORM_DEVICE_H_
+#define __ASM_GENERIC_PLATFORM_DEVICE_H_
+/*
+ * an architecture can override to define arch_setup_pdev_archdata
+ */
+
+#endif /* __ASM_GENERIC_PLATFORM_DEVICE_H_ */
--
1.6.0.6
^ permalink raw reply related
* [PATCH 0/3] driver core: Add ability for arch code to setup pdev_archdata
From: Kumar Gala @ 2010-08-05 15:15 UTC (permalink / raw)
To: gregkh; +Cc: linuxppc-dev, akpm, linux-kernel
On PPC we need to set the dma_mask pointer for platform_devices to point to
the pdev_archdata. We can't wait for a bus_notifier as we need the dma_mask
setup before the platform_device_add happens so that the bus_notifiers can
check the dma_mask to determine if we need things like the SWIOTLB dma_ops.
The patch series introduces an arch specific call out (arch_setup_pdev_archdata)
and provide an implementation on PPC to handle our specific issue.
- k
^ permalink raw reply
* Re: [PATCH 1/3] driver core: Add ability for arch code to setup pdev_archdata
From: Stephen Rothwell @ 2010-08-05 15:43 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev, akpm, gregkh, linux-kernel
In-Reply-To: <1281021347-1278-2-git-send-email-galak@kernel.crashing.org>
[-- Attachment #1: Type: text/plain, Size: 1757 bytes --]
Hi Kumar,
On Thu, 5 Aug 2010 10:15:45 -0500 Kumar Gala <galak@kernel.crashing.org> wrote:
>
> --- a/drivers/base/platform.c
> +++ b/drivers/base/platform.c
> @@ -19,6 +19,7 @@
> #include <linux/err.h>
> #include <linux/slab.h>
> #include <linux/pm_runtime.h>
> +#include <asm/platform_device.h>
>
> #include "base.h"
>
> @@ -170,6 +171,9 @@ struct platform_device *platform_device_alloc(const char *name, int id)
> pa->pdev.id = id;
> device_initialize(&pa->pdev.dev);
> pa->pdev.dev.release = platform_device_release;
> +#ifdef ARCH_HAS_PDEV_ARCHDATA_SETUP
> + arch_setup_pdev_archdata(&pa->pdev);
> +#endif
> }
>
> return pa ? &pa->pdev : NULL;
> diff --git a/include/asm-generic/platform_device.h b/include/asm-generic/platform_device.h
> new file mode 100644
> index 0000000..64806dc
> --- /dev/null
> +++ b/include/asm-generic/platform_device.h
> @@ -0,0 +1,7 @@
> +#ifndef __ASM_GENERIC_PLATFORM_DEVICE_H_
> +#define __ASM_GENERIC_PLATFORM_DEVICE_H_
> +/*
> + * an architecture can override to define arch_setup_pdev_archdata
> + */
> +
> +#endif /* __ASM_GENERIC_PLATFORM_DEVICE_H_ */
Why not do:
#include <linux/platform_device.h>
#ifndef arch_setup_pdev_archdata
static inline void arch_setup_pdev_archdata(struct platform_device *pdev) { }
#endif
in asm-generic/platform-device.h
and the the call in platform_device_alloc() can be unconditional. If the arch wants to override arch_setup_pdev_archdata, it defines the function and then does
#define arch_setup_pdev_archdata arch_setup_pdev_archdata
before still including asm-generic/platform_device.h
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 490 bytes --]
^ permalink raw reply
* Re: [PATCH 2/3] powerpc: implement arch_setup_pdev_archdata
From: Stephen Rothwell @ 2010-08-05 15:44 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev, akpm, gregkh, linux-kernel
In-Reply-To: <1281021347-1278-3-git-send-email-galak@kernel.crashing.org>
[-- Attachment #1: Type: text/plain, Size: 419 bytes --]
Hi Kumar,
On Thu, 5 Aug 2010 10:15:46 -0500 Kumar Gala <galak@kernel.crashing.org> wrote:
>
> +static inline void arch_setup_pdev_archdata(struct platform_device *pdev)
> +{
> + pdev->dev.dma_mask = &pdev->archdata.dma_mask;
> +
> + return;
> +}
The blank line and "return;" don't add anything.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 490 bytes --]
^ permalink raw reply
* Re: [PATCH 2/3] powerpc: implement arch_setup_pdev_archdata
From: Kumar Gala @ 2010-08-05 16:14 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: linuxppc-dev, akpm, gregkh, linux-kernel
In-Reply-To: <20100806014455.8cab0ae9.sfr@canb.auug.org.au>
On Aug 5, 2010, at 10:44 AM, Stephen Rothwell wrote:
> Hi Kumar,
>=20
> On Thu, 5 Aug 2010 10:15:46 -0500 Kumar Gala =
<galak@kernel.crashing.org> wrote:
>>=20
>> +static inline void arch_setup_pdev_archdata(struct platform_device =
*pdev)
>> +{
>> + pdev->dev.dma_mask =3D &pdev->archdata.dma_mask;
>> +
>> + return;
>> +}
>=20
> The blank line and "return;" don't add anything.
Will fix.
- k=
^ permalink raw reply
* Re: [PATCH 1/3] driver core: Add ability for arch code to setup pdev_archdata
From: Kumar Gala @ 2010-08-05 16:14 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: linuxppc-dev, akpm, gregkh, linux-kernel
In-Reply-To: <20100806014351.a3bddf08.sfr@canb.auug.org.au>
On Aug 5, 2010, at 10:43 AM, Stephen Rothwell wrote:
> Hi Kumar,
>=20
> On Thu, 5 Aug 2010 10:15:45 -0500 Kumar Gala =
<galak@kernel.crashing.org> wrote:
>>=20
>> --- a/drivers/base/platform.c
>> +++ b/drivers/base/platform.c
>> @@ -19,6 +19,7 @@
>> #include <linux/err.h>
>> #include <linux/slab.h>
>> #include <linux/pm_runtime.h>
>> +#include <asm/platform_device.h>
>>=20
>> #include "base.h"
>>=20
>> @@ -170,6 +171,9 @@ struct platform_device =
*platform_device_alloc(const char *name, int id)
>> pa->pdev.id =3D id;
>> device_initialize(&pa->pdev.dev);
>> pa->pdev.dev.release =3D platform_device_release;
>> +#ifdef ARCH_HAS_PDEV_ARCHDATA_SETUP
>> + arch_setup_pdev_archdata(&pa->pdev);
>> +#endif
>> }
>>=20
>> return pa ? &pa->pdev : NULL;
>> diff --git a/include/asm-generic/platform_device.h =
b/include/asm-generic/platform_device.h
>> new file mode 100644
>> index 0000000..64806dc
>> --- /dev/null
>> +++ b/include/asm-generic/platform_device.h
>> @@ -0,0 +1,7 @@
>> +#ifndef __ASM_GENERIC_PLATFORM_DEVICE_H_
>> +#define __ASM_GENERIC_PLATFORM_DEVICE_H_
>> +/*
>> + * an architecture can override to define arch_setup_pdev_archdata
>> + */
>> +
>> +#endif /* __ASM_GENERIC_PLATFORM_DEVICE_H_ */
>=20
> Why not do:
>=20
> #include <linux/platform_device.h>
>=20
> #ifndef arch_setup_pdev_archdata
> static inline void arch_setup_pdev_archdata(struct platform_device =
*pdev) { }
> #endif
>=20
> in asm-generic/platform-device.h
>=20
> and the the call in platform_device_alloc() can be unconditional. If =
the arch wants to override arch_setup_pdev_archdata, it defines the =
function and then does
>=20
> #define arch_setup_pdev_archdata arch_setup_pdev_archdata
>=20
> before still including asm-generic/platform_device.h
I've got no issues with the style change.
- k=
^ permalink raw reply
* Re: [linux-next] build failure
From: John Fastabend @ 2010-08-05 16:48 UTC (permalink / raw)
To: divya
Cc: linuxppc-dev@ozlabs.org, linux-next@vger.kernel.org, LKML,
Kirsher, Jeffrey T, netdev
In-Reply-To: <4C5A4CF4.4070203@linux.vnet.ibm.com>
divya wrote:
> Yestersday's linux-next(2.6.35_next_20100802) build fails with the following error on both system p and x.
>
>
> drivers/net/ixgbe/ixgbe_main.c: In function 'ixgbe_select_queue':
> drivers/net/ixgbe/ixgbe_main.c:6159: error: 'struct ixgbe_fcoe' has no member named 'up'
> drivers/net/ixgbe/ixgbe_main.c: In function 'ixgbe_xmit_frame':
> drivers/net/ixgbe/ixgbe_main.c:6221: error: 'struct ixgbe_fcoe' has no member named 'up'
> make[3]: *** [drivers/net/ixgbe/ixgbe_main.o] Error 1
> make[2]: *** [drivers/net/ixgbe] Error 2
> make[2]: *** Waiting for unfinished jobs....
> make[1]: *** [drivers/net] Error 2
> make: *** [drivers] Error 2
>
> Thanks
> Divya
>
>
Hi Divya,
Jeff should have a fix for this in his queue already. This is caused by
building with CONFIG_FCOE and without CONFIG_IXGBE_DCB.
Thanks,
John.
^ permalink raw reply
* Re: [PATCH 17/27] KVM: PPC: KVM PV guest stubs
From: Hollis Blanchard @ 2010-08-05 17:16 UTC (permalink / raw)
To: Alexander Graf; +Cc: linuxppc-dev, KVM list, kvm-ppc
In-Reply-To: <1280407688-9815-18-git-send-email-agraf@suse.de>
On 07/29/2010 05:47 AM, Alexander Graf wrote:
> We will soon start and replace instructions from the text section with
> other, paravirtualized versions. To ease the readability of those patches
> I split out the generic looping and magic page mapping code out.
>
> This patch still only contains stubs. But at least it loops through the
> text section :).
>
> Signed-off-by: Alexander Graf<agraf@suse.de>
>
> ---
>
> v1 -> v2:
>
> - kvm guest patch framework: introduce patch_ins
>
> v2 -> v3:
>
> - add self-test in guest code
> - remove superfluous new lines in generic guest code
> ---
> arch/powerpc/kernel/kvm.c | 95 +++++++++++++++++++++++++++++++++++++++++++++
> 1 files changed, 95 insertions(+), 0 deletions(-)
>
> diff --git a/arch/powerpc/kernel/kvm.c b/arch/powerpc/kernel/kvm.c
> index a5ece71..e93366f 100644
> --- a/arch/powerpc/kernel/kvm.c
> +++ b/arch/powerpc/kernel/kvm.c
> @@ -33,6 +33,62 @@
> #define KVM_MAGIC_PAGE (-4096L)
> #define magic_var(x) KVM_MAGIC_PAGE + offsetof(struct kvm_vcpu_arch_shared, x)
>
> +#define KVM_MASK_RT 0x03e00000
> +
> +static bool kvm_patching_worked = true;
> +
> +static inline void kvm_patch_ins(u32 *inst, u32 new_inst)
> +{
> + *inst = new_inst;
> + flush_icache_range((ulong)inst, (ulong)inst + 4);
> +}
> +
> +static void kvm_map_magic_page(void *data)
> +{
> + kvm_hypercall2(KVM_HC_PPC_MAP_MAGIC_PAGE,
> + KVM_MAGIC_PAGE, /* Physical Address */
> + KVM_MAGIC_PAGE); /* Effective Address */
> +}
> +
> +static void kvm_check_ins(u32 *inst)
> +{
> + u32 _inst = *inst;
> + u32 inst_no_rt = _inst& ~KVM_MASK_RT;
> + u32 inst_rt = _inst& KVM_MASK_RT;
> +
> + switch (inst_no_rt) {
> + }
> +
> + switch (_inst) {
> + }
> +}
> +
> +static void kvm_use_magic_page(void)
> +{
> + u32 *p;
> + u32 *start, *end;
> + u32 tmp;
> +
> + /* Tell the host to map the magic page to -4096 on all CPUs */
> + on_each_cpu(kvm_map_magic_page, NULL, 1);
> +
> + /* Quick self-test to see if the mapping works */
> + if (__get_user(tmp, (u32*)KVM_MAGIC_PAGE)) {
> + kvm_patching_worked = false;
> + return;
> + }
> +
> + /* Now loop through all code and find instructions */
> + start = (void*)_stext;
> + end = (void*)_etext;
> +
> + for (p = start; p< end; p++)
> + kvm_check_ins(p);
> +
> + printk(KERN_INFO "KVM: Live patching for a fast VM %s\n",
> + kvm_patching_worked ? "worked" : "failed");
> +}
>
Rather than have the guest loop through every instruction in its text,
why can't you use the existing cputable self-patching mechanism? The
kernel already uses that in a number of places to patch itself at
runtime in fast paths... see Documentation/powerpc/cpu_features.txt for
some background.
Since we already know (at build time) the location of code that needs
patching, we don't need to scan at all. (I also shudder to think of the
number of page faults this scan will incur.)
Hollis Blanchard
Mentor Graphics, Embedded Systems Division
^ permalink raw reply
* RE: [PATCH v2 5/7] powerpc/85xx: Add MChk handler for SRIO port
From: Bounine, Alexandre @ 2010-08-05 17:25 UTC (permalink / raw)
To: Michael Neuling
Cc: Li Yang-R58472, linux-kernel, Alexandre Bounine, thomas.moll,
linuxppc-dev, Timur Tabi
In-Reply-To: <26581.1280979260@neuling.org>
Below is a copy of Leo's message with pointers to the patches.
Alex.
=20
>Subject: [PATCH] RapidIO,powerpc/85xx: remove MCSR_MASK in fsl_rio
>
>Fixes compile problem caused by MCSR_MASK removal from book-E
definitions.
Hi Alex,
Only with your patch, there will still be problem on SRIO platforms
other than MPC85xx.
I have posted a patch series to fix this together with several
compatibility issues a month before.
http://patchwork.ozlabs.org/patch/56135/
http://patchwork.ozlabs.org/patch/56136/
http://patchwork.ozlabs.org/patch/56138/
http://patchwork.ozlabs.org/patch/56137/
Can anyone pick the patch series quickly as currently there is a compile
error when SRIO is enabled.
- Leo
> -----Original Message-----
> From: Michael Neuling [mailto:mikey@neuling.org]
> Sent: Wednesday, August 04, 2010 11:34 PM
> To: Bounine, Alexandre
> Cc: Timur Tabi; Alexandre Bounine; linuxppc-dev@lists.ozlabs.org;
linux-kernel@vger.kernel.org;
> thomas.moll@sysgo.com; Kumar Gala
> Subject: Re: [PATCH v2 5/7] powerpc/85xx: Add MChk handler for SRIO
port
>=20
>=20
>=20
> In message
<0CE8B6BE3C4AD74AB97D9D29BD24E552011430BC@CORPEXCH1.na.ads.idt.com> you
wrote:
> > Yang Li pointed to these patches in his post from July 23, 2010.
> > It would be nice to have these patches in mainline code.=3D20
>=20
> This is still broken in Kumar's latest tree. Do you guys wanna repost
> them so Kumar can pick them up easily?
>=20
> Mikey
>=20
> >
> > > -----Original Message-----
> > > From: timur.tabi@gmail.com [mailto:timur.tabi@gmail.com] On Behalf
Of
> > Timur Tabi
> > > Sent: Tuesday, August 03, 2010 9:02 AM
> > > To: Bounine, Alexandre
> > > Cc: Michael Neuling; Alexandre Bounine;
linuxppc-dev@lists.ozlabs.org;
> > linux-kernel@vger.kernel.org;
> > > thomas.moll@sysgo.com; Kumar Gala
> > > Subject: Re: [PATCH v2 5/7] powerpc/85xx: Add MChk handler for
SRIO
> > port
> > >=3D20
> > > On Tue, Aug 3, 2010 at 7:17 AM, Bounine, Alexandre
> > > <Alexandre.Bounine@idt.com> wrote:
> > > > This happened after change to book-e definitions.
> > > > There are patches that address this issue.
> > >=3D20
> > > And those patches should have been applied before 2.6.35 was
released.
> > > Someone dropped the ball. 2.6.35 is broken for a number of
PowerPC
> > > boards:
> > >=3D20
> > > $ make mpc85xx_defconfig
> > > ....
> > > $ make
> > > ....
> > > CC arch/powerpc/sysdev/fsl_rio.o
> > > arch/powerpc/sysdev/fsl_rio.c: In function
'fsl_rio_mcheck_exception':
> > > arch/powerpc/sysdev/fsl_rio.c:248: error: 'MCSR_MASK' undeclared
> > > (first use in this function)
> > > arch/powerpc/sysdev/fsl_rio.c:248: error: (Each undeclared
identifier
> > > is reported only once
> > > arch/powerpc/sysdev/fsl_rio.c:248: error: for each function it
appears
> > in.)
> > > make[1]: *** [arch/powerpc/sysdev/fsl_rio.o] Error 1
> > >=3D20
> > > --
> > > Timur Tabi
> > > Linux kernel developer at Freescale
> >
^ permalink raw reply
* Re: [PATCH 01/27] KVM: PPC: Introduce shared page
From: Hollis Blanchard @ 2010-08-05 17:05 UTC (permalink / raw)
To: Alexander Graf; +Cc: linuxppc-dev, KVM list, kvm-ppc
In-Reply-To: <1280407688-9815-2-git-send-email-agraf@suse.de>
On 07/29/2010 05:47 AM, Alexander Graf wrote:
> For transparent variable sharing between the hypervisor and guest, I introduce
> a shared page. This shared page will contain all the registers the guest can
> read and write safely without exiting guest context.
>
> This patch only implements the stubs required for the basic structure of the
> shared page. The actual register moving follows.
>
> Signed-off-by: Alexander Graf<agraf@suse.de>
> ---
> arch/powerpc/include/asm/kvm_host.h | 2 ++
> arch/powerpc/include/asm/kvm_para.h | 5 +++++
> arch/powerpc/kernel/asm-offsets.c | 1 +
> arch/powerpc/kvm/44x.c | 7 +++++++
> arch/powerpc/kvm/book3s.c | 9 ++++++++-
> arch/powerpc/kvm/e500.c | 7 +++++++
> 6 files changed, 30 insertions(+), 1 deletions(-)
>
> diff --git a/arch/powerpc/include/asm/kvm_host.h b/arch/powerpc/include/asm/kvm_host.h
> index b0b23c0..53edacd 100644
> --- a/arch/powerpc/include/asm/kvm_host.h
> +++ b/arch/powerpc/include/asm/kvm_host.h
> @@ -25,6 +25,7 @@
> #include<linux/interrupt.h>
> #include<linux/types.h>
> #include<linux/kvm_types.h>
> +#include<linux/kvm_para.h>
> #include<asm/kvm_asm.h>
>
> #define KVM_MAX_VCPUS 1
> @@ -290,6 +291,7 @@ struct kvm_vcpu_arch {
> struct tasklet_struct tasklet;
> u64 dec_jiffies;
> unsigned long pending_exceptions;
> + struct kvm_vcpu_arch_shared *shared;
>
> #ifdef CONFIG_PPC_BOOK3S
> struct hlist_head hpte_hash_pte[HPTEG_HASH_NUM_PTE];
> diff --git a/arch/powerpc/include/asm/kvm_para.h b/arch/powerpc/include/asm/kvm_para.h
> index 2d48f6a..1485ba8 100644
> --- a/arch/powerpc/include/asm/kvm_para.h
> +++ b/arch/powerpc/include/asm/kvm_para.h
> @@ -20,6 +20,11 @@
> #ifndef __POWERPC_KVM_PARA_H__
> #define __POWERPC_KVM_PARA_H__
>
> +#include<linux/types.h>
> +
> +struct kvm_vcpu_arch_shared {
> +};
> +
> #ifdef __KERNEL__
>
> static inline int kvm_para_available(void)
> diff --git a/arch/powerpc/kernel/asm-offsets.c b/arch/powerpc/kernel/asm-offsets.c
> index 496cc5b..944f593 100644
> --- a/arch/powerpc/kernel/asm-offsets.c
> +++ b/arch/powerpc/kernel/asm-offsets.c
> @@ -400,6 +400,7 @@ int main(void)
> DEFINE(VCPU_SPRG6, offsetof(struct kvm_vcpu, arch.sprg6));
> DEFINE(VCPU_SPRG7, offsetof(struct kvm_vcpu, arch.sprg7));
> DEFINE(VCPU_SHADOW_PID, offsetof(struct kvm_vcpu, arch.shadow_pid));
> + DEFINE(VCPU_SHARED, offsetof(struct kvm_vcpu, arch.shared));
>
> /* book3s */
> #ifdef CONFIG_PPC_BOOK3S
> diff --git a/arch/powerpc/kvm/44x.c b/arch/powerpc/kvm/44x.c
> index 73c0a3f..e7b1f3f 100644
> --- a/arch/powerpc/kvm/44x.c
> +++ b/arch/powerpc/kvm/44x.c
> @@ -123,8 +123,14 @@ struct kvm_vcpu *kvmppc_core_vcpu_create(struct kvm *kvm, unsigned int id)
> if (err)
> goto free_vcpu;
>
> + vcpu->arch.shared = (void*)__get_free_page(GFP_KERNEL|__GFP_ZERO);
> + if (!vcpu->arch.shared)
> + goto uninit_vcpu;
> +
> return vcpu;
>
> +uninit_vcpu:
> + kvm_vcpu_uninit(vcpu);
> free_vcpu:
> kmem_cache_free(kvm_vcpu_cache, vcpu_44x);
> out:
> @@ -135,6 +141,7 @@ void kvmppc_core_vcpu_free(struct kvm_vcpu *vcpu)
> {
> struct kvmppc_vcpu_44x *vcpu_44x = to_44x(vcpu);
>
> + free_page((unsigned long)vcpu->arch.shared);
> kvm_vcpu_uninit(vcpu);
> kmem_cache_free(kvm_vcpu_cache, vcpu_44x);
> }
> diff --git a/arch/powerpc/kvm/book3s.c b/arch/powerpc/kvm/book3s.c
> index a3cef30..b3385dd 100644
> --- a/arch/powerpc/kvm/book3s.c
> +++ b/arch/powerpc/kvm/book3s.c
> @@ -1242,6 +1242,10 @@ struct kvm_vcpu *kvmppc_core_vcpu_create(struct kvm *kvm, unsigned int id)
> if (err)
> goto free_shadow_vcpu;
>
> + vcpu->arch.shared = (void*)__get_free_page(GFP_KERNEL|__GFP_ZERO);
> + if (!vcpu->arch.shared)
> + goto uninit_vcpu;
> +
> vcpu->arch.host_retip = kvm_return_point;
> vcpu->arch.host_msr = mfmsr();
> #ifdef CONFIG_PPC_BOOK3S_64
> @@ -1268,10 +1272,12 @@ struct kvm_vcpu *kvmppc_core_vcpu_create(struct kvm *kvm, unsigned int id)
>
> err = kvmppc_mmu_init(vcpu);
> if (err< 0)
> - goto free_shadow_vcpu;
> + goto uninit_vcpu;
>
> return vcpu;
>
> +uninit_vcpu:
> + kvm_vcpu_uninit(vcpu);
> free_shadow_vcpu:
> kfree(vcpu_book3s->shadow_vcpu);
> free_vcpu:
> @@ -1284,6 +1290,7 @@ void kvmppc_core_vcpu_free(struct kvm_vcpu *vcpu)
> {
> struct kvmppc_vcpu_book3s *vcpu_book3s = to_book3s(vcpu);
>
> + free_page((unsigned long)vcpu->arch.shared);
> kvm_vcpu_uninit(vcpu);
> kfree(vcpu_book3s->shadow_vcpu);
> vfree(vcpu_book3s);
> diff --git a/arch/powerpc/kvm/e500.c b/arch/powerpc/kvm/e500.c
> index e8a00b0..71750f2 100644
> --- a/arch/powerpc/kvm/e500.c
> +++ b/arch/powerpc/kvm/e500.c
> @@ -117,8 +117,14 @@ struct kvm_vcpu *kvmppc_core_vcpu_create(struct kvm *kvm, unsigned int id)
> if (err)
> goto uninit_vcpu;
>
> + vcpu->arch.shared = (void*)__get_free_page(GFP_KERNEL|__GFP_ZERO);
> + if (!vcpu->arch.shared)
> + goto uninit_tlb;
> +
> return vcpu;
>
> +uninit_tlb:
> + kvmppc_e500_tlb_uninit(vcpu_e500);
> uninit_vcpu:
> kvm_vcpu_uninit(vcpu);
> free_vcpu:
> @@ -131,6 +137,7 @@ void kvmppc_core_vcpu_free(struct kvm_vcpu *vcpu)
> {
> struct kvmppc_vcpu_e500 *vcpu_e500 = to_e500(vcpu);
>
> + free_page((unsigned long)vcpu->arch.shared);
> kvmppc_e500_tlb_uninit(vcpu_e500);
> kvm_vcpu_uninit(vcpu);
> kmem_cache_free(kvm_vcpu_cache, vcpu_e500);
>
Why not put all this in a common function like kvm_arch_vcpu_init()?
There are layers of shared code inside arch/powerpc/kvm: e.g. powerpc.c
-> booke.c -> 44x.c...
Hollis Blanchard
Mentor Graphics, Embedded Systems Division
^ permalink raw reply
* Re: Relocating bootwrapper causes kernel panic
From: Scott Wood @ 2010-08-05 17:37 UTC (permalink / raw)
To: Shawn Jin; +Cc: ppcdev
In-Reply-To: <AANLkTikS3f8q+Kuq8aYX1vhRotfSMHN_S+qKPwrfDn2j@mail.gmail.com>
On Thu, 5 Aug 2010 00:23:17 -0700
Shawn Jin <shawnxjin@gmail.com> wrote:
> >> The flat tree located at 0xbe4300 as the kerne message showed. Why
> >> cannot the kernel access this area? No TLB set for this area?
> >>
> >> <1>Unable to handle kernel paging request for data at address 0xc0be43=
08
> >> <1>Faulting instruction address: 0xc01fdabc
> >> <4>Oops: Kernel access of bad area, sig: 11 [#1]
> >
> > Before the flat tree was accessed, I checked the DTLB and didn't find
> > any entry related to 0xc0be4300. After the exception, I found the
> > following DTLBs.
> >
> > 30 : 02 =A0c0be4000 =A0 4KB ------ -> 00000000
> > 31 : 00 =A0fa000000 =A0 8MB VI-S-M -> fa000000
> >
> > The DTLB#30 doesn't seem right. Why would it map to 0x0? I think this
> > should be something like 00be4000?
Note that the valid bit is clear -- it's not mapping to anything.
> When the early_debug is enabled, the kernel can boot successfully. I
> checked the TLB settings and found the following.
>=20
> 28 : 00 c0000000 8MB V--S-M -> 00000000
> 29 : 00 fa000000 8MB VI-S-M -> fa000000
> 30 : 00 c0800000 8MB V--S-M -> 00800000
> 31 : 14 04919000 ?KB V---WM -> 00e45000
That last entry looks weird... might want to look into that.
> So the kernel can access the dtb at 0xbe4300 because of the pinned down D=
TLB#30.
>=20
> I think the cause is clear now. But how to fix it? Two questions:
> 1. Should this DTLB miss exception properly set a new TLB entry for
> the new dtb address 0xbe4300?
Not if it doesn't find an entry in the page tables.
> 2. If the DTLB miss exception handler is not the right guy to load a
> proper TLB entry, how can I set one entry based on the link_address
> and the address of the flat dt blob?
Given how early in the boot process it is, it's probably going to need
to be handled specially.
-Scott
^ permalink raw reply
* Re: [PATCH v2 1/4] fsl_rio: fix compile errors
From: Kumar Gala @ 2010-08-05 17:39 UTC (permalink / raw)
To: Li Yang; +Cc: linuxppc-dev
In-Reply-To: <1276842263-4186-1-git-send-email-leoli@freescale.com>
On Jun 18, 2010, at 1:24 AM, Li Yang wrote:
> Fixes the following compile problem on E500 platforms:
> arch/powerpc/sysdev/fsl_rio.c: In function 'fsl_rio_mcheck_exception':
> arch/powerpc/sysdev/fsl_rio.c:248: error: 'MCSR_MASK' undeclared =
(first use in this function)
>=20
> Also fixes the compile problem on non-E500 platforms.
>=20
> Signed-off-by: Li Yang <leoli@freescale.com>
> ---
> arch/powerpc/sysdev/fsl_rio.c | 6 +++++-
> 1 files changed, 5 insertions(+), 1 deletions(-)
I'm confused is this handler not relevant for e500MC? The 2nd patch =
makes me thing it is.
>=20
> diff --git a/arch/powerpc/sysdev/fsl_rio.c =
b/arch/powerpc/sysdev/fsl_rio.c
> index 30e1626..f908ba6 100644
> --- a/arch/powerpc/sysdev/fsl_rio.c
> +++ b/arch/powerpc/sysdev/fsl_rio.c
> @@ -240,12 +240,13 @@ struct rio_priv {
>=20
> static void __iomem *rio_regs_win;
>=20
> +#ifdef CONFIG_E500
> static int (*saved_mcheck_exception)(struct pt_regs *regs);
>=20
> static int fsl_rio_mcheck_exception(struct pt_regs *regs)
> {
> const struct exception_table_entry *entry =3D NULL;
> - unsigned long reason =3D (mfspr(SPRN_MCSR) & MCSR_MASK);
> + unsigned long reason =3D mfspr(SPRN_MCSR);
>=20
> if (reason & MCSR_BUS_RBERR) {
> reason =3D in_be32((u32 *)(rio_regs_win + =
RIO_LTLEDCSR));
> @@ -269,6 +270,7 @@ static int fsl_rio_mcheck_exception(struct pt_regs =
*regs)
> else
> return cur_cpu_spec->machine_check(regs);
> }
> +#endif
>=20
> /**
> * fsl_rio_doorbell_send - Send a MPC85xx doorbell message
> @@ -1517,8 +1519,10 @@ int fsl_rio_setup(struct of_device *dev)
> fsl_rio_doorbell_init(port);
> fsl_rio_port_write_init(port);
>=20
> +#ifdef CONFIG_E500
> saved_mcheck_exception =3D ppc_md.machine_check_exception;
> ppc_md.machine_check_exception =3D fsl_rio_mcheck_exception;
> +#endif
> /* Ensure that RFXE is set */
> mtspr(SPRN_HID1, (mfspr(SPRN_HID1) | 0x20000));
>=20
> --=20
> 1.6.4
^ permalink raw reply
* [PATCH] Correct smt_enabled=X boot option for > 2 threads per core
From: Nathan Fontenot @ 2010-08-05 17:42 UTC (permalink / raw)
To: linuxppc-dev
The 'smt_enabled=X' boot option does not handle values of X > 2.
For Power 7 processors with smt modes of 0,1,2,3, and 4 this does
not work. This patch allows the smt_enabled option to be set to
any value limited to a max equal to the number of threads per
core.
Signed-off-by: Nathan Fontenot <nfont@austin.ibm.com>
---
arch/powerpc/kernel/setup_64.c | 61 ++++++++++++++++++++---------------
arch/powerpc/platforms/pseries/smp.c | 11 ++++--
2 files changed, 42 insertions(+), 30 deletions(-)
Index: powerpc/arch/powerpc/kernel/setup_64.c
===================================================================
--- powerpc.orig/arch/powerpc/kernel/setup_64.c 2010-08-05 10:57:04.000000000 -0500
+++ powerpc/arch/powerpc/kernel/setup_64.c 2010-08-05 11:20:49.000000000 -0500
@@ -95,7 +95,7 @@ int ucache_bsize;
#ifdef CONFIG_SMP
-static int smt_enabled_cmdline;
+static char *smt_enabled_cmdline;
/* Look for ibm,smt-enabled OF option */
static void check_smt_enabled(void)
@@ -103,37 +103,46 @@ static void check_smt_enabled(void)
struct device_node *dn;
const char *smt_option;
- /* Allow the command line to overrule the OF option */
- if (smt_enabled_cmdline)
- return;
-
- dn = of_find_node_by_path("/options");
+ /* Default to enabling all threads */
+ smt_enabled_at_boot = threads_per_core;
- if (dn) {
- smt_option = of_get_property(dn, "ibm,smt-enabled", NULL);
+ /* Allow the command line to overrule the OF option */
+ if (smt_enabled_cmdline) {
+ if (!strcmp(smt_enabled_cmdline, "on"))
+ smt_enabled_at_boot = threads_per_core;
+ else if (!strcmp(smt_enabled_cmdline, "off"))
+ smt_enabled_at_boot = 0;
+ else {
+ long smt;
+ int rc;
+
+ rc = strict_strtol(smt_enabled_cmdline, 10, &smt);
+ if (!rc)
+ smt_enabled_at_boot =
+ min(threads_per_core, (int)smt);
+ }
+ } else {
+ dn = of_find_node_by_path("/options");
+ if (dn) {
+ smt_option = of_get_property(dn, "ibm,smt-enabled",
+ NULL);
+
+ if (smt_option) {
+ if (!strcmp(smt_option, "on"))
+ smt_enabled_at_boot = threads_per_core;
+ else if (!strcmp(smt_option, "off"))
+ smt_enabled_at_boot = 0;
+ }
- if (smt_option) {
- if (!strcmp(smt_option, "on"))
- smt_enabled_at_boot = 1;
- else if (!strcmp(smt_option, "off"))
- smt_enabled_at_boot = 0;
- }
- }
+ of_node_put(dn);
+ }
+ }
}
/* Look for smt-enabled= cmdline option */
static int __init early_smt_enabled(char *p)
{
- smt_enabled_cmdline = 1;
-
- if (!p)
- return 0;
-
- if (!strcmp(p, "on") || !strcmp(p, "1"))
- smt_enabled_at_boot = 1;
- else if (!strcmp(p, "off") || !strcmp(p, "0"))
- smt_enabled_at_boot = 0;
-
+ smt_enabled_cmdline = p;
return 0;
}
early_param("smt-enabled", early_smt_enabled);
@@ -390,8 +399,8 @@ void __init setup_system(void)
*/
xmon_setup();
- check_smt_enabled();
smp_setup_cpu_maps();
+ check_smt_enabled();
#ifdef CONFIG_SMP
/* Release secondary cpus out of their spinloops at 0x60 now that
Index: powerpc/arch/powerpc/platforms/pseries/smp.c
===================================================================
--- powerpc.orig/arch/powerpc/platforms/pseries/smp.c 2010-06-14 08:36:05.000000000 -0500
+++ powerpc/arch/powerpc/platforms/pseries/smp.c 2010-08-05 11:20:49.000000000 -0500
@@ -182,10 +182,13 @@ static int smp_pSeries_cpu_bootable(unsi
/* Special case - we inhibit secondary thread startup
* during boot if the user requests it.
*/
- if (system_state < SYSTEM_RUNNING &&
- cpu_has_feature(CPU_FTR_SMT) &&
- !smt_enabled_at_boot && cpu_thread_in_core(nr) != 0)
- return 0;
+ if (system_state < SYSTEM_RUNNING && cpu_has_feature(CPU_FTR_SMT)) {
+ if (!smt_enabled_at_boot && cpu_thread_in_core(nr) != 0)
+ return 0;
+ if (smt_enabled_at_boot
+ && cpu_thread_in_core(nr) >= smt_enabled_at_boot)
+ return 0;
+ }
return 1;
}
^ permalink raw reply
* Re: [PATCH v2 5/7] powerpc/85xx: Add MChk handler for SRIO port
From: Kumar Gala @ 2010-08-05 17:53 UTC (permalink / raw)
To: Bounine, Alexandre
Cc: Michael Neuling, Li Yang-R58472, linux-kernel, Alexandre Bounine,
thomas.moll, linuxppc-dev, Timur Tabi
In-Reply-To: <0CE8B6BE3C4AD74AB97D9D29BD24E552011935BD@CORPEXCH1.na.ads.idt.com>
On Aug 5, 2010, at 12:25 PM, Bounine, Alexandre wrote:
> Below is a copy of Leo's message with pointers to the patches.
>=20
> Alex.
>=20
>> Subject: [PATCH] RapidIO,powerpc/85xx: remove MCSR_MASK in fsl_rio
>>=20
>> Fixes compile problem caused by MCSR_MASK removal from book-E
> definitions.
>=20
> Hi Alex,
>=20
> Only with your patch, there will still be problem on SRIO platforms
> other than MPC85xx.
>=20
> I have posted a patch series to fix this together with several
> compatibility issues a month before.
>=20
> http://patchwork.ozlabs.org/patch/56135/
> http://patchwork.ozlabs.org/patch/56136/
> http://patchwork.ozlabs.org/patch/56138/
> http://patchwork.ozlabs.org/patch/56137/
>=20
>=20
> Can anyone pick the patch series quickly as currently there is a =
compile
> error when SRIO is enabled.
>=20
> - Leo
I'm looking at this now and wondering what we added the mcheck handler =
for in the first place and what its trying to accomplish.
- k
^ permalink raw reply
* Re: [PATCH v2 1/4] fsl_rio: fix compile errors
From: Scott Wood @ 2010-08-05 17:54 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev
In-Reply-To: <F653C93C-5650-4D7B-99F7-090436CFC533@kernel.crashing.org>
On Thu, 5 Aug 2010 12:39:48 -0500
Kumar Gala <galak@kernel.crashing.org> wrote:
>
> On Jun 18, 2010, at 1:24 AM, Li Yang wrote:
>
> > Fixes the following compile problem on E500 platforms:
> > arch/powerpc/sysdev/fsl_rio.c: In function 'fsl_rio_mcheck_exception':
> > arch/powerpc/sysdev/fsl_rio.c:248: error: 'MCSR_MASK' undeclared (first use in this function)
> >
> > Also fixes the compile problem on non-E500 platforms.
> >
> > Signed-off-by: Li Yang <leoli@freescale.com>
> > ---
> > arch/powerpc/sysdev/fsl_rio.c | 6 +++++-
> > 1 files changed, 5 insertions(+), 1 deletions(-)
>
> I'm confused is this handler not relevant for e500MC? The 2nd patch makes me thing it is.
It is, though it needs to use a different MCSR bit on e500mc.
Are you referring to the #ifdef CONFIG_E500? CONFIG_PPC_E500MC depends
on CONFIG_E500...
-Scott
^ permalink raw reply
* Re: [PATCH v2 1/4] fsl_rio: fix compile errors
From: Kumar Gala @ 2010-08-05 18:00 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev
In-Reply-To: <20100805125415.3a939502@schlenkerla.am.freescale.net>
On Aug 5, 2010, at 12:54 PM, Scott Wood wrote:
> On Thu, 5 Aug 2010 12:39:48 -0500
> Kumar Gala <galak@kernel.crashing.org> wrote:
>=20
>>=20
>> On Jun 18, 2010, at 1:24 AM, Li Yang wrote:
>>=20
>>> Fixes the following compile problem on E500 platforms:
>>> arch/powerpc/sysdev/fsl_rio.c: In function =
'fsl_rio_mcheck_exception':
>>> arch/powerpc/sysdev/fsl_rio.c:248: error: 'MCSR_MASK' undeclared =
(first use in this function)
>>>=20
>>> Also fixes the compile problem on non-E500 platforms.
>>>=20
>>> Signed-off-by: Li Yang <leoli@freescale.com>
>>> ---
>>> arch/powerpc/sysdev/fsl_rio.c | 6 +++++-
>>> 1 files changed, 5 insertions(+), 1 deletions(-)
>>=20
>> I'm confused is this handler not relevant for e500MC? The 2nd patch =
makes me thing it is.
>=20
> It is, though it needs to use a different MCSR bit on e500mc.
>=20
> Are you referring to the #ifdef CONFIG_E500? CONFIG_PPC_E500MC =
depends
> on CONFIG_E500...
Ah, that makes a bit more sense now.
- k=
^ permalink raw reply
* Re: [PATCH 1/3] driver core: Add ability for arch code to setup pdev_archdata
From: Greg KH @ 2010-08-05 18:02 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: linuxppc-dev, akpm, linux-kernel
In-Reply-To: <20100806014351.a3bddf08.sfr@canb.auug.org.au>
On Fri, Aug 06, 2010 at 01:43:51AM +1000, Stephen Rothwell wrote:
> Hi Kumar,
>
> On Thu, 5 Aug 2010 10:15:45 -0500 Kumar Gala <galak@kernel.crashing.org> wrote:
> >
> > --- a/drivers/base/platform.c
> > +++ b/drivers/base/platform.c
> > @@ -19,6 +19,7 @@
> > #include <linux/err.h>
> > #include <linux/slab.h>
> > #include <linux/pm_runtime.h>
> > +#include <asm/platform_device.h>
> >
> > #include "base.h"
> >
> > @@ -170,6 +171,9 @@ struct platform_device *platform_device_alloc(const char *name, int id)
> > pa->pdev.id = id;
> > device_initialize(&pa->pdev.dev);
> > pa->pdev.dev.release = platform_device_release;
> > +#ifdef ARCH_HAS_PDEV_ARCHDATA_SETUP
> > + arch_setup_pdev_archdata(&pa->pdev);
> > +#endif
> > }
> >
> > return pa ? &pa->pdev : NULL;
> > diff --git a/include/asm-generic/platform_device.h b/include/asm-generic/platform_device.h
> > new file mode 100644
> > index 0000000..64806dc
> > --- /dev/null
> > +++ b/include/asm-generic/platform_device.h
> > @@ -0,0 +1,7 @@
> > +#ifndef __ASM_GENERIC_PLATFORM_DEVICE_H_
> > +#define __ASM_GENERIC_PLATFORM_DEVICE_H_
> > +/*
> > + * an architecture can override to define arch_setup_pdev_archdata
> > + */
> > +
> > +#endif /* __ASM_GENERIC_PLATFORM_DEVICE_H_ */
>
> Why not do:
>
> #include <linux/platform_device.h>
>
> #ifndef arch_setup_pdev_archdata
> static inline void arch_setup_pdev_archdata(struct platform_device *pdev) { }
> #endif
>
> in asm-generic/platform-device.h
>
> and the the call in platform_device_alloc() can be unconditional. If the arch wants to override arch_setup_pdev_archdata, it defines the function and then does
>
> #define arch_setup_pdev_archdata arch_setup_pdev_archdata
>
> before still including asm-generic/platform_device.h
Yes, I'd prefer that method as well.
thanks,
greg k-h
^ permalink raw reply
* RE: [PATCH v2 5/7] powerpc/85xx: Add MChk handler for SRIO port
From: Bounine, Alexandre @ 2010-08-05 18:17 UTC (permalink / raw)
To: Kumar Gala
Cc: Michael Neuling, Li Yang-R58472, linux-kernel, Alexandre Bounine,
thomas.moll, linuxppc-dev, Timur Tabi
In-Reply-To: <C9528078-D64C-4944-B960-0E985B3EE0BA@kernel.crashing.org>
> I'm looking at this now and wondering what we added the mcheck handler
for in the first place and what
> its trying to accomplish.
>=20
> - k
This protects system from hanging if RIO link fails or enters error
state. In some situations following maintenance read may initiate link
recovery from error state.
As it is now, MCheck mostly prevents system from hanging, but it also
adds sense to return status of maintenance read routine. I am using
return status in my new set of patches to check if RIO link is valid
during error recovery.
Alex.
=20
^ permalink raw reply
* Re: Relocating bootwrapper causes kernel panic
From: Shawn Jin @ 2010-08-05 18:33 UTC (permalink / raw)
To: Scott Wood; +Cc: ppcdev
In-Reply-To: <20100805123725.63d009b1@schlenkerla.am.freescale.net>
>> > Before the flat tree was accessed, I checked the DTLB and didn't find
>> > any entry related to 0xc0be4300. After the exception, I found the
>> > following DTLBs.
>> >
>> > 30 : 02 =A0c0be4000 =A0 4KB ------ -> 00000000
>> > 31 : 00 =A0fa000000 =A0 8MB VI-S-M -> fa000000
>> >
>> > The DTLB#30 doesn't seem right. Why would it map to 0x0? I think this
>> > should be something like 00be4000?
>
> Note that the valid bit is clear -- it's not mapping to anything.
Did the exception handler try to set a TLB here but the setting was
not completed?
>> I think the cause is clear now. But how to fix it? Two questions:
>> 2. If the DTLB miss exception handler is not the right guy to load a
>> proper TLB entry, how can I set one entry based on the link_address
>> and the address of the flat dt blob?
>
> Given how early in the boot process it is, it's probably going to need
> to be handled specially.
What APIs can I use to set up DTLBs?
Thanks,
-Shawn.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox