* Re: [PATCH 1/2] powerpc/85xx: fix problem that prevents PHYS_64BIT from configurable
From: Timur Tabi @ 2012-02-17 21:17 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev@ozlabs.org, Li Yang-R58472
In-Reply-To: <1329513033.3980.1.camel@pasglop>
Benjamin Herrenschmidt wrote:
> Sorry, I fail to see how... it basically makes all those boards
> non-functional even when enabled...
So you're saying that if we allow 32-bit address spacing for a particular
board, then we must provide a 32-bit DTS to go with it?
I was hoping to use the defconfig to force 36-bit, so that we can have a
32-bit option if we want. Just because we don't put a 32-bit DTS in the
upstream kernel, that doesn't mean that no one is allowed to have a 32-bit
kernel.
> What's wrong with the current scheme ?
It prevents the possibility of creating an "optimized" 32-bit address
environment, for people who have <= 2GB of DDR on the board. If we want
to ship a 32-bit DTS and 32-bit U-Boot on our BSP, then we'll need to
patch the Kconfig to remove the "select" line.
--
Timur Tabi
Linux kernel developer at Freescale
^ permalink raw reply
* Re: [PATCH 16/30] KVM: PPC: e500mc: Add doorbell emulation support
From: Scott Wood @ 2012-02-17 21:55 UTC (permalink / raw)
To: Alexander Graf; +Cc: linuxppc-dev, kvm, kvm-ppc
In-Reply-To: <1329498837-11717-17-git-send-email-agraf@suse.de>
On 02/17/2012 11:13 AM, Alexander Graf wrote:
> When one vcpu wants to kick another, it can issue a special IPI instruction
> called msgsnd. This patch emulates this instruction, its clearing counterpart
> and the infrastructure required to actually trigger that interrupt inside
> a guest vcpu.
>
> With this patch, SMP guests on e500mc work.
>
> Signed-off-by: Alexander Graf <agraf@suse.de>
> ---
> arch/powerpc/kvm/booke.c | 6 +++
> arch/powerpc/kvm/e500_emulate.c | 68 +++++++++++++++++++++++++++++++++++++++
> 2 files changed, 74 insertions(+), 0 deletions(-)
>
> diff --git a/arch/powerpc/kvm/booke.c b/arch/powerpc/kvm/booke.c
> index 3dd200d..ce1599d 100644
> --- a/arch/powerpc/kvm/booke.c
> +++ b/arch/powerpc/kvm/booke.c
> @@ -326,6 +326,9 @@ static int kvmppc_booke_irqprio_deliver(struct kvm_vcpu *vcpu,
> int_class = INT_CLASS_NONCRIT;
> break;
> case BOOKE_IRQPRIO_CRITICAL:
> +#ifdef CONFIG_KVM_E500MC
> + case BOOKE_IRQPRIO_DBELL_CRIT:
> +#endif
> allowed = vcpu->arch.shared->msr & MSR_CE;
> allowed = allowed && !crit;
> msr_mask = MSR_GS | MSR_ME;
> @@ -342,6 +345,9 @@ static int kvmppc_booke_irqprio_deliver(struct kvm_vcpu *vcpu,
> keep_irq = true;
> /* fall through */
> case BOOKE_IRQPRIO_EXTERNAL:
> +#ifdef CONFIG_KVM_E500MC
> + case BOOKE_IRQPRIO_DBELL:
> +#endif
This isn't e500mc specific -- it's in the ISA as "Embedded.Processor
Control".
Any harm in just removing the ifdef (similar to tlbilx)?
> allowed = vcpu->arch.shared->msr & MSR_EE;
> allowed = allowed && !crit;
> msr_mask = MSR_GS | MSR_CE | MSR_ME | MSR_DE;
> diff --git a/arch/powerpc/kvm/e500_emulate.c b/arch/powerpc/kvm/e500_emulate.c
> index 98b6c1c..29d5604 100644
> --- a/arch/powerpc/kvm/e500_emulate.c
> +++ b/arch/powerpc/kvm/e500_emulate.c
> @@ -14,16 +14,74 @@
>
> #include <asm/kvm_ppc.h>
> #include <asm/disassemble.h>
> +#include <asm/dbell.h>
>
> #include "booke.h"
> #include "e500.h"
>
> +#define XOP_MSGSND 206
> +#define XOP_MSGCLR 238
> #define XOP_TLBIVAX 786
> #define XOP_TLBSX 914
> #define XOP_TLBRE 946
> #define XOP_TLBWE 978
> #define XOP_TLBILX 18
>
> +#ifdef CONFIG_KVM_E500MC
> +static int dbell2prio(ulong param)
> +{
> + int msg = param & PPC_DBELL_TYPE(-1);
Maybe introduce PPC_DBELL_TYPE_MASK or GET_PPC_DBELL_TYPE?
> + int prio = -1;
> +
> + switch (msg) {
> + case PPC_DBELL_TYPE(PPC_DBELL):
> + prio = BOOKE_IRQPRIO_DBELL;
> + break;
> + case PPC_DBELL_TYPE(PPC_DBELL_CRIT):
> + prio = BOOKE_IRQPRIO_DBELL_CRIT;
> + break;
> + default:
> + break;
> + }
> +
> + return prio;
> +}
> +
> +static int kvmppc_e500_emul_msgclr(struct kvm_vcpu *vcpu, int rb)
> +{
> + ulong param = vcpu->arch.gpr[rb];
> + int prio = dbell2prio(param);
> +
> + if (prio < 0)
> + return EMULATE_FAIL;
> +
> + clear_bit(prio, &vcpu->arch.pending_exceptions);
> + return EMULATE_DONE;
> +}
> +
> +static int kvmppc_e500_emul_msgsnd(struct kvm_vcpu *vcpu, int rb)
> +{
> + ulong param = vcpu->arch.gpr[rb];
> + int prio = dbell2prio(rb);
> + int pir = param & 0x3fff;
Introduce PPC_DBELL_PIR_MASK or GET_PPC_DBELL_PIR?
> + int i;
> + struct kvm_vcpu *cvcpu;
> +
> + if (prio < 0)
> + return EMULATE_FAIL;
> +
> + kvm_for_each_vcpu(i, cvcpu, vcpu->kvm) {
> + int cpir = cvcpu->arch.shared->pir;
> + if ((param & PPC_DBELL_MSG_BRDCAST) || (cpir == pir)) {
> + set_bit(prio, &cvcpu->arch.pending_exceptions);
> + kvm_vcpu_kick(cvcpu);
> + }
> + }
Should this be a kvm_make_request instead (with a separate
pending_doorbell bool in vcpu that msgclr can act on), considering
earlier discussion of phasing out atomics on pending_exceptions, in
favor of requests?
-Scott
^ permalink raw reply
* Re: [PATCH 16/30] KVM: PPC: e500mc: Add doorbell emulation support
From: Scott Wood @ 2012-02-17 21:57 UTC (permalink / raw)
To: Alexander Graf; +Cc: linuxppc-dev, kvm, kvm-ppc
In-Reply-To: <4F3ECCE6.2010503@freescale.com>
On 02/17/2012 03:55 PM, Scott Wood wrote:
> Should this be a kvm_make_request instead (with a separate
> pending_doorbell bool in vcpu that msgclr can act on), considering
> earlier discussion of phasing out atomics on pending_exceptions, in
> favor of requests?
Ignore the bit about msgclr -- it acts on the local vcpu, so no need for
pending_doorbell. It can just be a plain request.
-Scott
^ permalink raw reply
* Re: [PATCH 21/30] KVM: PPC: make e500v2 and e500mc mutually exclusive
From: Scott Wood @ 2012-02-17 22:13 UTC (permalink / raw)
To: Alexander Graf; +Cc: linuxppc-dev, kvm, kvm-ppc
In-Reply-To: <1329498837-11717-22-git-send-email-agraf@suse.de>
On 02/17/2012 11:13 AM, Alexander Graf wrote:
> We can't build e500v2 and e500mc (kvm) support inside the same kernel.
> So indicate that by making the 2 options mutually exclusive in kconfig.
>
> Signed-off-by: Alexander Graf <agraf@suse.de>
> ---
> arch/powerpc/kvm/Kconfig | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/arch/powerpc/kvm/Kconfig b/arch/powerpc/kvm/Kconfig
> index 44a998d..25ffc1e 100644
> --- a/arch/powerpc/kvm/Kconfig
> +++ b/arch/powerpc/kvm/Kconfig
> @@ -134,7 +134,7 @@ config KVM_E500V2
>
> config KVM_E500MC
> bool "KVM support for PowerPC E500MC/E5500 processors"
> - depends on EXPERIMENTAL && PPC_E500MC
> + depends on EXPERIMENTAL && PPC_E500MC && !KVM_E500V2
> select KVM
> select KVM_MMIO
> select KVM_BOOKE_HV
Instead should make KVM_E500V2 not selectable if PPC_E500MC is present
-- it won't work due to the absence of PID1 on e500mc.
-Scott
^ permalink raw reply
* Re: [PATCH 21/30] KVM: PPC: make e500v2 and e500mc mutually exclusive
From: Tabi Timur-B04825 @ 2012-02-17 22:32 UTC (permalink / raw)
To: Alexander Graf
Cc: Wood Scott-B07421, linuxppc-dev, list,
<kvm-ppc@vger.kernel.org>
In-Reply-To: <1329497818-9729-22-git-send-email-agraf@suse.de>
On Fri, Feb 17, 2012 at 10:56 AM, Alexander Graf <agraf@suse.de> wrote:
> =A0config KVM_E500MC
> =A0 =A0 =A0 =A0bool "KVM support for PowerPC E500MC/E5500 processors"
> - =A0 =A0 =A0 depends on EXPERIMENTAL && PPC_E500MC
> + =A0 =A0 =A0 depends on EXPERIMENTAL && PPC_E500MC && !KVM_E500V2
There was a patch floating around that made a similar change to the
platform support, so that you could either build an e500v2 kernel and
enable support only for e500v2 board, or you could build an e500mc
kernel and enable support only for e500mc boards. Last I heard, the
patch wasn't quite working, but that was a while ago.
Is there a connection between this patch and that one?
--=20
Timur Tabi
Linux kernel developer at Freescale=
^ permalink raw reply
* [git pull] Please pull powerpc.git merge branch
From: Benjamin Herrenschmidt @ 2012-02-17 22:36 UTC (permalink / raw)
To: Linus Torvalds; +Cc: linuxppc-dev list, Andrew Morton, Linux Kernel list
Hi Linus !
Here are a few more fixes for powerpc. Some are regressions, the rest is
simple/obvious/nasty enough that I deemed it good to go now.
Here's also step one of deprecating legacy iSeries support: we are
removing it from the main defconfig.
Nobody seems to be using it anymore and the code is nasty to maintain,
(involves horrible hacks in various low level areas of the kernel) so we
plan to actually rip it out at some point. For now let's just avoid
building it by default. Stephen will proceed to do the actual removal
later (probably 3.4 or 3.5).
Cheers,
Ben.
The following changes since commit 778a785f02ad846446e91dab49331bd7d853c514:
powerpc/pseries/eeh: Fix crash when error happens during device probe (2012-02-14 15:01:39 +1100)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/benh/powerpc.git merge
for you to fetch changes up to 9a45a9407c69d068500923480884661e2b9cc421:
powerpc/perf: power_pmu_start restores incorrect values, breaking frequency events (2012-02-16 16:24:35 +1100)
----------------------------------------------------------------
Anton Blanchard (1):
powerpc/perf: power_pmu_start restores incorrect values, breaking frequency events
Benjamin Herrenschmidt (2):
powerpc/fsl/pci: Fix PCIe fixup regression
powerpc: Disable interrupts early in Program Check
Ira Snyder (1):
powerpc: Fix kernel log of oops/panic instruction dump
Stephen Rothwell (1):
powerpc: Remove legacy iSeries from ppc64_defconfig
majianpeng (1):
powerpc/adb: Use set_current_state()
arch/powerpc/configs/ppc64_defconfig | 5 ---
arch/powerpc/kernel/exceptions-64s.S | 2 +-
arch/powerpc/kernel/perf_event.c | 8 +++++-
arch/powerpc/kernel/process.c | 6 ++--
arch/powerpc/sysdev/fsl_pci.c | 48 ++++++++++++++++++++-------------
drivers/macintosh/adb.c | 4 +-
6 files changed, 42 insertions(+), 31 deletions(-)
^ permalink raw reply
* Re: [PATCH 24/30] KVM: PPC: booke: call resched after every exit
From: Scott Wood @ 2012-02-17 23:00 UTC (permalink / raw)
To: Alexander Graf; +Cc: linuxppc-dev, kvm, kvm-ppc
In-Reply-To: <1329498837-11717-25-git-send-email-agraf@suse.de>
On 02/17/2012 11:13 AM, Alexander Graf wrote:
> Instead of checking whether we should reschedule only when we exited
> due to an interrupt, let's always check before entering the guest back
> again. This gets the target more in line with the other archs.
>
> Signed-off-by: Alexander Graf <agraf@suse.de>
> ---
> arch/powerpc/kvm/booke.c | 15 ++++++++++-----
> 1 files changed, 10 insertions(+), 5 deletions(-)
>
> diff --git a/arch/powerpc/kvm/booke.c b/arch/powerpc/kvm/booke.c
> index bfb2092..de30b6d 100644
> --- a/arch/powerpc/kvm/booke.c
> +++ b/arch/powerpc/kvm/booke.c
> @@ -572,6 +572,7 @@ int kvmppc_handle_exit(struct kvm_run *run, struct kvm_vcpu *vcpu,
> unsigned int exit_nr)
> {
> int r = RESUME_HOST;
> + int resched_needed = 1;
>
> /* update before a new last_exit_type is rewritten */
> kvmppc_update_timing_stats(vcpu);
> @@ -602,25 +603,21 @@ int kvmppc_handle_exit(struct kvm_run *run, struct kvm_vcpu *vcpu,
>
> switch (exit_nr) {
> case BOOKE_INTERRUPT_MACHINE_CHECK:
> - kvm_resched(vcpu);
> r = RESUME_GUEST;
> break;
>
> case BOOKE_INTERRUPT_EXTERNAL:
> kvmppc_account_exit(vcpu, EXT_INTR_EXITS);
> - kvm_resched(vcpu);
> r = RESUME_GUEST;
> break;
>
> case BOOKE_INTERRUPT_DECREMENTER:
> kvmppc_account_exit(vcpu, DEC_EXITS);
> - kvm_resched(vcpu);
> r = RESUME_GUEST;
> break;
>
> case BOOKE_INTERRUPT_DOORBELL:
> kvmppc_account_exit(vcpu, DBELL_EXITS);
> - kvm_resched(vcpu);
> r = RESUME_GUEST;
> break;
>
> @@ -869,8 +866,16 @@ int kvmppc_handle_exit(struct kvm_run *run, struct kvm_vcpu *vcpu,
> BUG();
> }
>
> - local_irq_disable();
> + /* make sure we reschedule if we need to */
> + while (resched_needed) {
> + local_irq_disable();
>
> + resched_needed = need_resched();
> + if (resched_needed) {
> + local_irq_enable();
> + cond_resched();
> + }
> + }
> kvmppc_core_prepare_to_enter(vcpu);
>
> if (!(r & RESUME_HOST)) {
kvmppc_core_prepare_to_enter can enable interrupts (and block) if guest
MSR_WE is set. We may take an interrupt that wants a resched after
waking but before interrupts are disabled again.
We also want to check for a resched in kvmppc_vcpu_run. So, the resched
check belongs in kvmppc_core_prepare_to_enter, something like:
/* Check pending exceptions and deliver one, if possible. */
void kvmppc_core_prepare_to_enter(struct kvm_vcpu *vcpu)
{
WARN_ON_ONCE(!irqs_disabled());
while (true) {
if (signal_pending(current))
break;
if (need_resched()) {
local_irq_enable();
cond_resched();
local_irq_disable();
continue;
}
kvmppc_core_check_exceptions(vcpu);
if (vcpu->arch.shared->msr & MSR_WE) {
local_irq_enable();
kvm_vcpu_block(vcpu);
local_irq_disable();
kvmppc_set_exit_type(vcpu,
EMULATED_MTMSRWE_EXITS);
continue;
}
break;
}
}
It would be simpler (both here and in the idle hcall) if we could just
drop support for CONFIG_PREEMPT=n. :-P
-Scott
^ permalink raw reply
* Re: [PATCH 1/2] powerpc/85xx: fix problem that prevents PHYS_64BIT from configurable
From: Timur Tabi @ 2012-02-17 23:01 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev@ozlabs.org, Li Yang-R58472
In-Reply-To: <1329513033.3980.1.camel@pasglop>
So I noticed something else. PHYS_64BIT is not defined in
mpc85xx_smp_defconfig. This means that if we want to build a 36-bit
kernel, we need to have "select PHYS_64BIT" in the Kconfig for that board.
This is what we have today for the P1022DS.
However, that select statement also means that we can't build a 32-bit
kernel. This is a problem for mpc85xx_defconfig, because that defconfig
includes support for the MPC8540ADS. The 8540 has an e500v1 core which
doesn't support MAS7 (i.e. no 36-bit physical addresses).
So any patch that removes "select PHYS_64BIT" from an mpc85xx_defconfig
board must also turn on that option in the defconfig. The patches from me
and Leo don't do that.
--
Timur Tabi
Linux kernel developer at Freescale
^ permalink raw reply
* Re: [PATCH 19/30] KVM: PPC: e500mc: add load inst fixup
From: Scott Wood @ 2012-02-17 23:17 UTC (permalink / raw)
To: Alexander Graf; +Cc: linuxppc-dev, kvm, kvm-ppc
In-Reply-To: <1329498837-11717-20-git-send-email-agraf@suse.de>
On 02/17/2012 11:13 AM, 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 <agraf@suse.de>
> ---
> 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..e0f484c 100644
> --- a/arch/powerpc/kvm/bookehv_interrupts.S
> +++ b/arch/powerpc/kvm/bookehv_interrupts.S
> @@ -28,6 +28,7 @@
> #include <asm/asm-compat.h>
> #include <asm/asm-offsets.h>
> #include <asm/bitsperlong.h>
> +#include <asm/thread_info.h>
>
> #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
> + lwz r6,TI_PREEMPT(r8)
> + addi r7,r6,1
> + stw r7,TI_PREEMPT(r8)
Whitespace
The preempt count had better already be zero here, so we can just store
1 now, and 0 later, and avoid the stall on load results.
> +
> 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
Please tab after the opcode
> +.previous
> +.section __ex_table,"a"
> + PPC_LONG_ALIGN
> + PPC_LONG 1b,3b
> +.previous
> +
> mtspr SPRN_EPLC, r3
> + stw r6,TI_PREEMPT(r8)
> stw r9, VCPU_LAST_INST(r4)
Whitespace
-Scott
^ permalink raw reply
* Re: [PATCH] powerpc/85xx:Add PSC9131 RDB Support
From: Andy Fleming @ 2012-02-17 23:26 UTC (permalink / raw)
To: Tabi Timur-B04825
Cc: Aggrwal Poonam-B10812, Srivastava Rajan-B34330,
Mehresh Ramneek-B31383, Goyal Akhil-B35197,
Kushwaha Prabhakar-B32579, linuxppc-dev@lists.ozlabs.org,
devicetree-discuss@lists.ozlabs.org, Jain Priyanka-B32167
In-Reply-To: <CAOZdJXVvL98vNG5UvT2t1dgJw1D204-5BCgDsxqD04szhHueBQ@mail.gmail.com>
On Fri, Feb 17, 2012 at 1:20 PM, Tabi Timur-B04825 <B04825@freescale.com> w=
rote:
> On Tue, Feb 14, 2012 at 2:37 AM, Prabhakar Kushwaha
> <prabhakar@freescale.com> wrote:
>>
>> =A0Applied on git://git.kernel.org/pub/scm/linux/kernel/git/galak/powerp=
c.git branch next
>
> This is actually a false statement. =A0"Applied" is past tense, so you
> are saying that this patch has *already* been applied to Kumar's
> powerpc.git repository. =A0But this is not true -- Kumar's repository
> has not been updated in the last three weeks, and this patch is
> nowhere to be found.
I'm pretty sure the sentence should read:
Based on git://git.kernel.org/pub/scm/linux/kernel/git/galak/powerpc.git
branch next
Good idea to correct that for future submissions, as it is otherwise
confusing. Could also say "Developed against" instead of "Based on".
Andy
^ permalink raw reply
* Re: [PATCH 21/30] KVM: PPC: make e500v2 and e500mc mutually exclusive
From: Alexander Graf @ 2012-02-17 23:27 UTC (permalink / raw)
To: Tabi Timur-B04825
Cc: Wood Scott-B07421, linuxppc-dev, list,
<kvm-ppc@vger.kernel.org>
In-Reply-To: <CAOZdJXXxC5vdWrpz-sU0O+5oXS211DLYywqkQLwq0JOtRZyBHQ@mail.gmail.com>
On 17.02.2012, at 23:32, Tabi Timur-B04825 wrote:
> On Fri, Feb 17, 2012 at 10:56 AM, Alexander Graf <agraf@suse.de> =
wrote:
>=20
>> config KVM_E500MC
>> bool "KVM support for PowerPC E500MC/E5500 processors"
>> - depends on EXPERIMENTAL && PPC_E500MC
>> + depends on EXPERIMENTAL && PPC_E500MC && !KVM_E500V2
>=20
> There was a patch floating around that made a similar change to the
> platform support, so that you could either build an e500v2 kernel and
> enable support only for e500v2 board, or you could build an e500mc
> kernel and enable support only for e500mc boards. Last I heard, the
> patch wasn't quite working, but that was a while ago.
>=20
> Is there a connection between this patch and that one?
No, and the code paths are quite orthogonal. While today it's impossible =
to build a kernel that can drive e500v2 and e500mc systems, it might be =
possible one day. That still doesn't buy us KVM compatibility between =
the two though. And vice versa. We could improve the KVM code to =
actually be versatile between the two platforms, but then you still =
couldn't run the same kernel on both ;).
Alex
^ permalink raw reply
* Re: [linuxppc-release] [PATCH 1/2] powerpc: document the FSL MPIC message register binding
From: Scott Wood @ 2012-02-18 0:47 UTC (permalink / raw)
To: Yoder Stuart-B08248
Cc: meador_inge@mentor.com, linuxppc-dev@lists.ozlabs.org,
Li Yang-R58472, Jia Hongtao-B38951
In-Reply-To: <9F6FE96B71CF29479FF1CDC8046E15032F516B@039-SN1MPN1-002.039d.mgd.msft.net>
On 02/17/2012 09:50 AM, Yoder Stuart-B08248 wrote:
>
>
>> -----Original Message-----
>> From: linuxppc-release-bounces@linux.freescale.net [mailto:linuxppc-release-
>> bounces@linux.freescale.net] On Behalf Of Jia Hongtao-B38951
>> Sent: Thursday, February 16, 2012 8:49 PM
>> To: linuxppc-dev@lists.ozlabs.org
>> Cc: meador_inge@mentor.com; Li Yang-R58472; Jia Hongtao-B38951
>> Subject: [linuxppc-release] [PATCH 1/2] powerpc: document the FSL MPIC message register
>> binding
>>
>> This binding documents how the message register blocks found in some FSL MPIC implementations
>> shall be represented in a device tree.
>>
>> Signed-off-by: Meador Inge <meador_inge@mentor.com>
>> Signed-off-by: Jia Hongtao <B38951@freescale.com>
>> Signed-off-by: Li Yang <leoli@freescale.com>
>> ---
>> .../devicetree/bindings/powerpc/fsl/mpic-msgr.txt | 62 ++++++++++++++++++++
>> 1 files changed, 62 insertions(+), 0 deletions(-) create mode 100644
>> Documentation/devicetree/bindings/powerpc/fsl/mpic-msgr.txt
>>
>> diff --git a/Documentation/devicetree/bindings/powerpc/fsl/mpic-msgr.txt
>> b/Documentation/devicetree/bindings/powerpc/fsl/mpic-msgr.txt
>> new file mode 100644
>> index 0000000..b4ae70e
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/powerpc/fsl/mpic-msgr.txt
>> @@ -0,0 +1,62 @@
>> +* FSL MPIC Message Registers
>> +
>> +This binding specifies what properties must be available in the device
>> +tree representation of the message register blocks found in some FSL
>> +MPIC implementations.
>> +
>> +Required properties:
>> +
>> + - compatible: Specifies the compatibility list for the message register
>> + block. The type shall be <string> and the value shall be of the form
>> + "fsl,mpic-v<version>-msgr", where <version> is the version number of
>> + the MPIC containing the message registers.
>
> The type for compatibles is a <string-list>.
>
>> + - reg: Specifies the base physical address(s) and size(s) of the
>> + message register block's addressable register space. The type shall be
>> + <prop-encoded-array>.
>> +
>> + - interrupts: Specifies a list of interrupt source and level-sense pairs.
>> + The type shall be <prop-encoded-array>. The length shall be equal to
>> + the number of registers that are available for receiving interrupts.
>
> How many interrupts are there? If more than 1, this is where
> you need to specify what each interrupt is for.
They aren't "for" anything in particular -- each interrupt is associated
with a message register. The binding does say that the number of
interrupts corresponds to the bits set in the receive mask.
>> +Optional properties:
>> +
>> + - mpic-msgr-receive-mask: Specifies what registers in the containing block
>> + are allowed to receive interrupts. The value is a bit mask where a set
>> + bit at bit 'n' indicates that message register 'n' can receive interrupts.
>> + The type shall be <prop-encoded-array>. If not present, then all of
>> + the message registers in the block are available.
>
> Your example implies that this is 1 32-bit cell. If that is the case then
> this really should be of type '<u32>'.
And should clarify that "bit 'n'" means numbered from LSB, given how PPC
hardware docs tend to use the opposite convention.
-Scott
^ permalink raw reply
* Re: [PATCH 1/2] powerpc/85xx: fix problem that prevents PHYS_64BIT from configurable
From: Scott Wood @ 2012-02-18 0:56 UTC (permalink / raw)
To: Timur Tabi; +Cc: Li Yang-R58472, linuxppc-dev@ozlabs.org
In-Reply-To: <4F3EDC35.5070904@freescale.com>
On 02/17/2012 05:01 PM, Timur Tabi wrote:
> So I noticed something else. PHYS_64BIT is not defined in
> mpc85xx_smp_defconfig.
It couldn't have been, since it was selected by another kconfig option.
defconfigs only hold non-default options.
> However, that select statement also means that we can't build a 32-bit
> kernel. This is a problem for mpc85xx_defconfig, because that defconfig
> includes support for the MPC8540ADS. The 8540 has an e500v1 core which
> doesn't support MAS7 (i.e. no 36-bit physical addresses).
It's not a problem for 8540, just lost optimization potential.
> So any patch that removes "select PHYS_64BIT" from an mpc85xx_defconfig
> board must also turn on that option in the defconfig. The patches from me
> and Leo don't do that.
Yes, or maybe make it "default y", and/or require an "I know what I'm
doing" option to be set for it to be unset if a board otherwise wants it.
The ability to turn it off is potentially useful for any board, since
the address map is determined by boot software which can be changed, but
we shouldn't make it too easy to fail to select it for boards that
normally require it.
-Scott
^ permalink raw reply
* Re: [PATCH 1/2] powerpc/85xx: fix problem that prevents PHYS_64BIT from configurable
From: Benjamin Herrenschmidt @ 2012-02-18 2:19 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev@ozlabs.org, Timur Tabi, Li Yang-R58472
In-Reply-To: <4F3EF72C.2090305@freescale.com>
On Fri, 2012-02-17 at 18:56 -0600, Scott Wood wrote:
> Yes, or maybe make it "default y", and/or require an "I know what I'm
> doing" option to be set for it to be unset if a board otherwise wants it.
>
> The ability to turn it off is potentially useful for any board, since
> the address map is determined by boot software which can be changed, but
> we shouldn't make it too easy to fail to select it for boards that
> normally require it.
Don't we have CONFIG_EMBEDDED to make that sort of option visible ?
Cheers,
Ben.
^ permalink raw reply
* Re: [PATCH] usb: Fix build error due to dma_mask is not at pdev_archdata at ARM
From: Peter Chen @ 2012-02-18 10:22 UTC (permalink / raw)
To: Peter Chen, Li Yang-R58472
Cc: fabio.estevam, linux-usb, stern, ramneek.mehresh, agust,
linuxppc-dev, stable
In-Reply-To: <1329356512-31527-1-git-send-email-peter.chen@freescale.com>
On Thu, Feb 16, 2012 at 9:41 AM, Peter Chen <peter.chen@freescale.com> wrot=
e:
> When build i.mx platform with imx_v6_v7_defconfig, and after adding
> USB Gadget support, it has below build error:
>
> CC =A0 =A0 =A0drivers/usb/host/fsl-mph-dr-of.o
> drivers/usb/host/fsl-mph-dr-of.c: In function 'fsl_usb2_device_register':
> drivers/usb/host/fsl-mph-dr-of.c:97: error: 'struct pdev_archdata'
> has no member named 'dma_mask'
>
> It has discussed at: http://www.spinics.net/lists/linux-usb/msg57302.html
>
> For PowerPC, there is dma_mask at struct pdev_archdata, but there is
> no dma_mask at struct pdev_archdata for ARM. The pdev_archdata is
> related to specific platform, it should NOT be accessed by
> cross platform drivers, like USB.
>
> The code for pdev_archdata should be useless, as for PowerPC,
> it has already gotten the value for pdev->dev.dma_mask at function
> arch_setup_pdev_archdata of arch/powerpc/kernel/setup-common.c.
>
> Tested-by: Ramneek Mehresh <ramneek.mehresh@freescale.com>
> Signed-off-by: Peter Chen <peter.chen@freescale.com>
> ---
> =A0drivers/usb/host/fsl-mph-dr-of.c | =A0 =A01 -
> =A01 files changed, 0 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/usb/host/fsl-mph-dr-of.c b/drivers/usb/host/fsl-mph-=
dr-of.c
> index 7916e56..ab333ac 100644
> --- a/drivers/usb/host/fsl-mph-dr-of.c
> +++ b/drivers/usb/host/fsl-mph-dr-of.c
> @@ -94,7 +94,6 @@ struct platform_device * __devinit fsl_usb2_device_regi=
ster(
> =A0 =A0 =A0 =A0pdev->dev.parent =3D &ofdev->dev;
>
> =A0 =A0 =A0 =A0pdev->dev.coherent_dma_mask =3D ofdev->dev.coherent_dma_ma=
sk;
> - =A0 =A0 =A0 pdev->dev.dma_mask =3D &pdev->archdata.dma_mask;
> =A0 =A0 =A0 =A0*pdev->dev.dma_mask =3D *ofdev->dev.dma_mask;
>
> =A0 =A0 =A0 =A0retval =3D platform_device_add_data(pdev, pdata, sizeof(*p=
data));
Hi Leo, can your guys give me an ACK for it? Then, Alan can apply it.
Ramneek has already tested it, and confirmed it did not break host
function at his platform.
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-usb" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at =A0http://vger.kernel.org/majordomo-info.html
--=20
BR,
Peter Chen
^ permalink raw reply
* Re: [PATCH] powerpc/usb: fix bug of kernel hang when initializing usb
From: Sergei Shtylyov @ 2012-02-18 15:39 UTC (permalink / raw)
To: Shengzhou Liu; +Cc: linux-usb, linuxppc-dev
In-Reply-To: <1329386540-12341-1-git-send-email-Shengzhou.Liu@freescale.com>
Hello.
On 16-02-2012 14:02, Shengzhou Liu wrote:
> If USB UTMI PHY is not enable, writing to portsc register will lead to
> kernel hang during boot up.
> Signed-off-by: Shengzhou Liu<Shengzhou.Liu@freescale.com>
[...]
> diff --git a/drivers/usb/host/ehci-fsl.h b/drivers/usb/host/ehci-fsl.h
> index bdf43e2..0e400c2 100644
> --- a/drivers/usb/host/ehci-fsl.h
> +++ b/drivers/usb/host/ehci-fsl.h
> @@ -45,6 +45,7 @@
> #define FSL_SOC_USB_PRICTRL 0x40c /* NOTE: big-endian */
> #define FSL_SOC_USB_SICTRL 0x410 /* NOTE: big-endian */
> #define FSL_SOC_USB_CTRL 0x500 /* NOTE: big-endian */
> +#define CTRL_UTMI_PHY_EN (1<<9)
Please put spaces around << like below.
> #define CTRL_PHY_CLK_VALID (1<< 17)
> #define SNOOP_SIZE_2GB 0x1e
> #endif /* _EHCI_FSL_H */
WBR, Sergei
^ permalink raw reply
* RE: [PATCH] powerpc/85xx:Add PSC9131 RDB Support
From: Kushwaha Prabhakar-B32579 @ 2012-02-18 16:45 UTC (permalink / raw)
To: Andy Fleming, Tabi Timur-B04825
Cc: Aggrwal Poonam-B10812, Srivastava Rajan-B34330,
Mehresh Ramneek-B31383, Goyal Akhil-B35197,
linuxppc-dev@lists.ozlabs.org,
devicetree-discuss@lists.ozlabs.org, Jain Priyanka-B32167
In-Reply-To: <CAKWjMd70yAkbY4fbMaumih86YEujjDti4YRrnH4Yycj7-NEBPw@mail.gmail.com>
Thanks Andy and Timur for correcting the statement.
I will make sure of this in future patches.
--Prabhakar
> -----Original Message-----
> From: Andy Fleming [mailto:afleming@gmail.com]
> Sent: Saturday, February 18, 2012 4:56 AM
> To: Tabi Timur-B04825
> Cc: Kushwaha Prabhakar-B32579; Goyal Akhil-B35197; Aggrwal Poonam-B10812;
> Srivastava Rajan-B34330; Mehresh Ramneek-B31383; devicetree-
> discuss@lists.ozlabs.org; linuxppc-dev@lists.ozlabs.org; Jain Priyanka-
> B32167
> Subject: Re: [PATCH] powerpc/85xx:Add PSC9131 RDB Support
>=20
> On Fri, Feb 17, 2012 at 1:20 PM, Tabi Timur-B04825 <B04825@freescale.com>
> wrote:
> > On Tue, Feb 14, 2012 at 2:37 AM, Prabhakar Kushwaha
> > <prabhakar@freescale.com> wrote:
> >>
> >> =A0Applied on
> >> git://git.kernel.org/pub/scm/linux/kernel/git/galak/powerpc.git
> >> branch next
> >
> > This is actually a false statement. =A0"Applied" is past tense, so you
> > are saying that this patch has *already* been applied to Kumar's
> > powerpc.git repository. =A0But this is not true -- Kumar's repository
> > has not been updated in the last three weeks, and this patch is
> > nowhere to be found.
>=20
> I'm pretty sure the sentence should read:
>=20
> Based on git://git.kernel.org/pub/scm/linux/kernel/git/galak/powerpc.git
> branch next
>=20
> Good idea to correct that for future submissions, as it is otherwise
> confusing. Could also say "Developed against" instead of "Based on".
>=20
> Andy
^ permalink raw reply
* Re: [PATCH] powerpc: perf: power_pmu_start restores incorrect values, breaking frequency events
From: Stephane Eranian @ 2012-02-19 11:13 UTC (permalink / raw)
To: Paul Mackerras
Cc: gleb, peterz, vince, linux-kernel, andi, Anton Blanchard, imunsie,
mingo, sukadev, linuxppc-dev, wcohen, asharma, emunson
In-Reply-To: <20120216045749.GA25364@bloggs.ozlabs.ibm.com>
Glad to see you fixed the PPC problem.
On Thu, Feb 16, 2012 at 5:57 AM, Paul Mackerras <paulus@samba.org> wrote:
> On Thu, Feb 16, 2012 at 03:48:22PM +1100, Anton Blanchard wrote:
>>
>> perf on POWER stopped working after commit e050e3f0a71b (perf: Fix
>> broken interrupt rate throttling). That patch exposed a bug in
>> the POWER perf_events code.
>>
>> Since the PMCs count upwards and take an exception when the top bit
>> is set, we want to write 0x80000000 - left in power_pmu_start. We were
>> instead programming in left which effectively disables the counter
>> until we eventually hit 0x80000000. This could take seconds or longer.
>>
>> With the patch applied I get the expected number of samples:
>>
>> # taskset -c 0 yes > /dev/null &
>> # perf record -C 0 -a sleep 10
>> # perf report -D | grep SAMPLE | tail -1
>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 SAMPLE events: =C2=A0 =C2=A0 =C2=A0 9=
948
>>
>> Signed-off-by: Anton Blanchard <anton@samba.org>
>
> Acked-by: Paul Mackerras <paulus@samba.org>
^ permalink raw reply
* [PATCH] tty/powerpc: early udbg consoles can't be modules
From: Stephen Rothwell @ 2012-02-19 20:01 UTC (permalink / raw)
To: Greg Kroah-Hartman; +Cc: ppc-dev, Timur Tabi, stable
[-- Attachment #1: Type: text/plain, Size: 1056 bytes --]
Fixes these build errors:
ERROR: ".udbg_printf" [drivers/tty/ehv_bytechan.ko] undefined!
ERROR: ".register_early_udbg_console" [drivers/tty/ehv_bytechan.ko] undefined!
ERROR: "udbg_putc" [drivers/tty/ehv_bytechan.ko] undefined!
Cc: Timur Tabi <timur@freescale.com>
Cc: stable@vger.kernel.org (v3.2)
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
drivers/tty/Kconfig | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/tty/Kconfig b/drivers/tty/Kconfig
index b3d1741..830cd62 100644
--- a/drivers/tty/Kconfig
+++ b/drivers/tty/Kconfig
@@ -365,7 +365,7 @@ config PPC_EPAPR_HV_BYTECHAN
config PPC_EARLY_DEBUG_EHV_BC
bool "Early console (udbg) support for ePAPR hypervisors"
- depends on PPC_EPAPR_HV_BYTECHAN
+ depends on PPC_EPAPR_HV_BYTECHAN=y
help
Select this option to enable early console (a.k.a. "udbg") support
via an ePAPR byte channel. You also need to choose the byte channel
--
1.7.9
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply related
* warnings from drivers/tty/ehv_bytechan.c
From: Stephen Rothwell @ 2012-02-19 20:07 UTC (permalink / raw)
To: Timur Tabi; +Cc: Greg Kroah-Hartman, ppc-dev
[-- Attachment #1: Type: text/plain, Size: 600 bytes --]
Hi Timur,
If you build drivers/tty/ehv_bytechan.c as a module, it produces these warmings:
drivers/tty/ehv_bytechan.c:362:1: warning: data definition has no type or storage class
drivers/tty/ehv_bytechan.c:362:1: warning: type defaults to 'int' in declaration of 'console_initcall'
drivers/tty/ehv_bytechan.c:362:1: warning: parameter names (without types) in function declaration
drivers/tty/ehv_bytechan.c:334:19: warning: 'ehv_bc_console_init' defined but not used
console_initcall() is not defined for modules.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* [PATCH] tty/powerpc: early udbg consoles can't be modules
From: Stephen Rothwell @ 2012-02-19 20:22 UTC (permalink / raw)
To: gregkh; +Cc: ppc-dev, Timur Tabi, stable
[-- Attachment #1: Type: text/plain, Size: 1099 bytes --]
Fixes these build errors:
ERROR: ".udbg_printf" [drivers/tty/ehv_bytechan.ko] undefined!
ERROR: ".register_early_udbg_console" [drivers/tty/ehv_bytechan.ko] undefined!
ERROR: "udbg_putc" [drivers/tty/ehv_bytechan.ko] undefined!
Cc: Timur Tabi <timur@freescale.com>
Cc: stable@vger.kernel.org (v3.2)
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
drivers/tty/Kconfig | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
Resent with Greg's correct new address.
diff --git a/drivers/tty/Kconfig b/drivers/tty/Kconfig
index b3d1741..830cd62 100644
--- a/drivers/tty/Kconfig
+++ b/drivers/tty/Kconfig
@@ -365,7 +365,7 @@ config PPC_EPAPR_HV_BYTECHAN
config PPC_EARLY_DEBUG_EHV_BC
bool "Early console (udbg) support for ePAPR hypervisors"
- depends on PPC_EPAPR_HV_BYTECHAN
+ depends on PPC_EPAPR_HV_BYTECHAN=y
help
Select this option to enable early console (a.k.a. "udbg") support
via an ePAPR byte channel. You also need to choose the byte channel
--
1.7.9
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply related
* warnings from drivers/tty/ehv_bytechan.c
From: Stephen Rothwell @ 2012-02-19 20:23 UTC (permalink / raw)
To: Timur Tabi; +Cc: gregkh, ppc-dev
[-- Attachment #1: Type: text/plain, Size: 644 bytes --]
[Resent with Greg's correct new address]
Hi Timur,
If you build drivers/tty/ehv_bytechan.c as a module, it produces these warmings:
drivers/tty/ehv_bytechan.c:362:1: warning: data definition has no type or storage class
drivers/tty/ehv_bytechan.c:362:1: warning: type defaults to 'int' in declaration of 'console_initcall'
drivers/tty/ehv_bytechan.c:362:1: warning: parameter names (without types) in function declaration
drivers/tty/ehv_bytechan.c:334:19: warning: 'ehv_bc_console_init' defined but not used
console_initcall() is not defined for modules.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [PATCH 6/12] arch/powerpc: remove references to cpu_*_map.
From: Rusty Russell @ 2012-02-19 22:45 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Venkatesh Pallipadi, linux-kernel, Paul Mackerras,
Srivatsa S. Bhat, akpm@linux-foundation.org, linuxppc-dev
In-Reply-To: <1329362944.3772.45.camel@pasglop>
On Thu, 16 Feb 2012 14:29:04 +1100, Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
> On Wed, 2012-02-15 at 14:51 +0530, Srivatsa S. Bhat wrote:
> > On 02/15/2012 10:28 AM, Rusty Russell wrote:
> >
> > > From: Rusty Russell <rusty@rustcorp.com.au>
> > >
> > > This has been obsolescent for a while; time for the final push.
> > >
>
> Acked-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
>
> Want me to stick that in -powerpc ? If yes, now or -next ?
Please, in -next.
Cheers,
Rusty.
^ permalink raw reply
* [PATCH] powerpc/of: add OF_DYNAMIC for chroma
From: Michael Neuling @ 2012-02-19 22:48 UTC (permalink / raw)
To: Jimi Xenidis, grant.likely; +Cc: linuxppc-dev, linux-next
linux next-20120217 compiling ppc64e_defconfig fails with:
arch/powerpc/platforms/wsp/h8.c: In function 'wsp_h8_getaddr':
arch/powerpc/platforms/wsp/h8.c:116: error: implicit declaration of function 'of_detach_node'
The below fixes this by selecting the new OF_DYNAMIC when PPC_CHROMA.
Signed-off-by: Michael Neuling <mikey@neuling.org>
diff --git a/arch/powerpc/platforms/wsp/Kconfig b/arch/powerpc/platforms/wsp/Kconfig
index 57d22a2..79d2225 100644
--- a/arch/powerpc/platforms/wsp/Kconfig
+++ b/arch/powerpc/platforms/wsp/Kconfig
@@ -25,6 +25,7 @@ config PPC_CHROMA
bool "PowerEN PCIe Chroma Card"
select EPAPR_BOOT
select PPC_WSP
+ select OF_DYNAMIC
default y
endmenu
^ permalink raw reply related
* Re: [RFC PATCH v7 00/10] fadump: Firmware-assisted dump support for Powerpc.
From: Paul Mackerras @ 2012-02-19 23:47 UTC (permalink / raw)
To: Mahesh J Salgaonkar
Cc: Anton Blanchard, Amerigo Wang, Kexec-ml, Linux Kernel,
Milton Miller, linuxppc-dev, Randy Dunlap, Eric W. Biederman,
Vivek Goyal
In-Reply-To: <20120216111050.4733.38034.stgit@mars>
On Thu, Feb 16, 2012 at 04:44:06PM +0530, Mahesh J Salgaonkar wrote:
> Please find the version 7 of the patchset that implements firmware-assisted
> dump mechanism to capture kernel crash dump for Powerpc architecture.
> Firmware-assisted dump is a robust mechanism to get reliable kernel crash
> dump with the assistance of firmware. This approach does not use kexec,
> instead firmware assists in booting the kdump kernel while preserving memory
> contents.
For the series:
Reviewed-by: Paul Mackerras <paulus@samba.org>
I think it's pretty much good enough to go in now. I have one relatively
minor comment about a printk which could be addressed if you decide to
do another version of the series.
Paul.
^ 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