* Re: [PATCH 1/5] powerpc/85xx: issue 15 EOI after core reset for FSL CoreNet devices
From: Segher Boessenkool @ 2011-10-26 18:30 UTC (permalink / raw)
To: Matthew McClintock; +Cc: kumar.gala, linuxppc-dev
In-Reply-To: <1319652797-28017-1-git-send-email-msm@freescale.com>
> @@ -1759,6 +1760,12 @@ void mpic_reset_core(int cpu)
> pir &= ~(1 << cpuid);
> mpic_write(mpic->gregs, MPIC_INFO(GREG_PROCESSOR_INIT), pir);
> mpic_read(mpic->gregs, MPIC_INFO(GREG_PROCESSOR_INIT));
> +
> + /* Perform 15 EOI on each reset core to clear pending interrupts */
> + for (i = 0; i < 15; i++) {
> + _mpic_write(mpic->reg_type, &mpic->cpuregs[cpuid],
> + MPIC_CPU_EOI, 0);
> + }
This is generic code, right? Please add info to the comment about
which devices need this quirk, then.
Segher
^ permalink raw reply
* [PATCH 1/5] powerpc/85xx: issue 15 EOI after core reset for FSL CoreNet devices
From: Matthew McClintock @ 2011-10-26 18:13 UTC (permalink / raw)
To: linuxppc-dev, kumar.gala
In-Reply-To: <08F58B37-0825-4C07-91B3-1040A7E70528@freescale.com>
This is listed as a requirement for Freescale CoreNet based devices (e.g
p4080ds with MPIC v4.x) after issuing a core reset to properly clear pending
interrupts.
Signed-off-by: Matthew McClintock <msm@freescale.com>
---
v2: Updated commit message
arch/powerpc/sysdev/mpic.c | 7 +++++++
1 files changed, 7 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/sysdev/mpic.c b/arch/powerpc/sysdev/mpic.c
index 9678081..f5b83f0 100644
--- a/arch/powerpc/sysdev/mpic.c
+++ b/arch/powerpc/sysdev/mpic.c
@@ -1748,6 +1748,7 @@ void mpic_reset_core(int cpu)
struct mpic *mpic = mpic_primary;
u32 pir;
int cpuid = get_hard_smp_processor_id(cpu);
+ int i;
/* Set target bit for core reset */
pir = mpic_read(mpic->gregs, MPIC_INFO(GREG_PROCESSOR_INIT));
@@ -1759,6 +1760,12 @@ void mpic_reset_core(int cpu)
pir &= ~(1 << cpuid);
mpic_write(mpic->gregs, MPIC_INFO(GREG_PROCESSOR_INIT), pir);
mpic_read(mpic->gregs, MPIC_INFO(GREG_PROCESSOR_INIT));
+
+ /* Perform 15 EOI on each reset core to clear pending interrupts */
+ for (i = 0; i < 15; i++) {
+ _mpic_write(mpic->reg_type, &mpic->cpuregs[cpuid],
+ MPIC_CPU_EOI, 0);
+ }
}
#endif /* CONFIG_SMP */
--
1.7.6.1
^ permalink raw reply related
* RE: [PATCH v15 00/10] Add-Synopsys-DesignWare-HS-USB-OTG-driver
From: Tirumala Marri @ 2011-10-26 17:17 UTC (permalink / raw)
To: greg; +Cc: linux-usb, linuxppc-dev
In-Reply-To: <CAOesGMhVuxbqq7cmm2XVUof9vEifAL=GpPirYb8148a24upJCw@mail.gmail.com>
Greg,
<
<No, just start over from scratch. Just leave the crap driver behind,
<use it for reference but write the new one.
<
<It's obvious given that you are already at iteration v15 and it's
<still looking this bad that this is not realistic to get reviewed and
<accepted as-is. I don't think staging is a good target either -- what
<the driver really needs is _functional_ cut-down to only cover the use
<cases that your product uses, and staging cleanups are mostly around
<style and refactoring, not changing, fixing or removing functionality.
<
<> <Compare this to the dwc3 driver, which is much much cleaner.
<> <
Could you please comment on this. This has been reviewed so many times
And we did the major changes. I think it is un-acceptable to say to
re-write
The driver now after 15 reviews? This should have happened in first 5
reviews.
Thx,
Marri
^ permalink raw reply
* RE: [PATCH v15 00/10] Add-Synopsys-DesignWare-HS-USB-OTG-driver
From: Tirumala Marri @ 2011-10-26 16:06 UTC (permalink / raw)
To: Olof Johansson; +Cc: greg, linux-usb, linuxppc-dev
In-Reply-To: <CAOesGMhVuxbqq7cmm2XVUof9vEifAL=GpPirYb8148a24upJCw@mail.gmail.com>
<
<No, just start over from scratch. Just leave the crap driver behind,
<use it for reference but write the new one.
<
<It's obvious given that you are already at iteration v15 and it's
<still looking this bad that this is not realistic to get reviewed and
<accepted as-is. I don't think staging is a good target either -- what
<the driver really needs is _functional_ cut-down to only cover the use
<cases that your product uses, and staging cleanups are mostly around
<style and refactoring, not changing, fixing or removing functionality.
<
[Tirumala Marri] I like to hear What maintainer GregKH thinks. We already
spent lot
Of time on it and passed multiple hands.
--marri
^ permalink raw reply
* Re: [PATCH 06/11] powerpc/85xx: Add ethernet magic packet property to P1020 device tree
From: Scott Wood @ 2011-10-26 16:02 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev
In-Reply-To: <6549A2B9-A9FD-42BC-A3B0-B920167739F5@kernel.crashing.org>
On 10/25/2011 10:35 PM, Kumar Gala wrote:
>
> On Oct 25, 2011, at 5:19 PM, Scott Wood wrote:
>
>> On 10/22/2011 04:20 PM, Kumar Gala wrote:
>>> All eTSEC2 controllers support waking on magic packet so fixup device
>>> tree to report that.
>>
>> If they *all* support it, we can make the driver rely on the compatible
>> instead.
>>
>> -Scott
>
> I think this might have originated on eTSEC v1, in which all controllers don't support it.
Sure, I was just talking about nodes with fsl,etsec2 -- especially if we
have device trees already out there that are missing the property.
Easier to change the driver.
-Scott
^ permalink raw reply
* Re: [PATCH v15 00/10] Add-Synopsys-DesignWare-HS-USB-OTG-driver
From: Olof Johansson @ 2011-10-26 12:04 UTC (permalink / raw)
To: Tirumala Marri; +Cc: greg, linux-usb, linuxppc-dev
In-Reply-To: <c898f5030d342baa4df570317536bcf2@mail.gmail.com>
On Tue, Oct 25, 2011 at 2:54 PM, Tirumala Marri <tmarri@apm.com> wrote:
> <
> <Overall this driver seems to be based on the IP vendor driver? It
> <looks like a completely flexible driver that implements all possible
> <combinations of everything.
> <
> [Tirumala Marri] Some what true that it was based on skeletal driver
> Provided from IP vendor.
Please use a real mail program instead of this [name] comment style.
It's hard to read.
> <And as a result, it's huge, and it's got a lot of extra code in there
> <that I'm
> <willing to bet that you have never even executed on your platform.
> <
> <Please, pare it down to the portions that you have used, and know works
> <and can support. If others need the extra functionality in the future,
> <they can and will expand and bring in what is needed.
> <
> [Tirumala Marri] I can sure review and find if there are any dead
> functions.
> It may not be 100% free of dead code as some of the code paths may execut=
e
> Asynchronously.
No, just start over from scratch. Just leave the crap driver behind,
use it for reference but write the new one.
It's obvious given that you are already at iteration v15 and it's
still looking this bad that this is not realistic to get reviewed and
accepted as-is. I don't think staging is a good target either -- what
the driver really needs is _functional_ cut-down to only cover the use
cases that your product uses, and staging cleanups are mostly around
style and refactoring, not changing, fixing or removing functionality.
> <Compare this to the dwc3 driver, which is much much cleaner.
> <
> [Tirumala Marri] I will check.
> <Overall other comments:
> <
> <* Register definitions are crazy long. It means you have to do lots of
> <line
> < =A0wraps to keep the 80-character limit, which makes it hard to read th=
e
> <code.
> [Tirumala Marri] This was suggestion from the review to use bit shifting.
> I welcome any suggestions.
I'd be surprised if anyone asked to you that kind of crazy shifting.
> <* The header files seem to have been autogenerated and have unnneeded
> < =A0shift/mask operations.
> <
> <* It doesn't build on non-powerpc platforms since it uses out_{b,l}e
> <accessors.
> <
> [Tirumala Marri] You have to select Little Endian mode for LE platform
> From make menuconfig.
I don't think you understood what I meant. Try building an ARM config
with this driver enabled, for example, and you'll see that it breaks
the build.
-Olof
^ permalink raw reply
* Re: [PATCH 06/11] powerpc/85xx: Add ethernet magic packet property to P1020 device tree
From: Kumar Gala @ 2011-10-26 3:35 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev
In-Reply-To: <4EA735E8.5010206@freescale.com>
On Oct 25, 2011, at 5:19 PM, Scott Wood wrote:
> On 10/22/2011 04:20 PM, Kumar Gala wrote:
>> All eTSEC2 controllers support waking on magic packet so fixup device
>> tree to report that.
>=20
> If they *all* support it, we can make the driver rely on the =
compatible
> instead.
>=20
> -Scott
I think this might have originated on eTSEC v1, in which all controllers =
don't support it.
I'm not against removing it & just using compatible but don't know =
enough about these nodes to comment.
- k=
^ permalink raw reply
* Re: [PATCH 1/5] powerpc/85xx: issue 15 EOI after core reset
From: Kumar Gala @ 2011-10-26 3:16 UTC (permalink / raw)
To: Matthew McClintock; +Cc: linuxppc-dev
In-Reply-To: <1319583246-6120-1-git-send-email-msm@freescale.com>
On Oct 25, 2011, at 5:54 PM, Matthew McClintock wrote:
> This is listed as a requirement after issuing a core reset to
> properly clear pending interrupts
>=20
Fix comment message to be more clear on 'what' this is required. [ its a =
requirement on FSL corenet series / MPIC v4.x ]
> Signed-off-by: Matthew McClintock <msm@freescale.com>
> ---
> arch/powerpc/sysdev/mpic.c | 7 +++++++
> 1 files changed, 7 insertions(+), 0 deletions(-)
>=20
> diff --git a/arch/powerpc/sysdev/mpic.c b/arch/powerpc/sysdev/mpic.c
> index 9678081..f5b83f0 100644
> --- a/arch/powerpc/sysdev/mpic.c
> +++ b/arch/powerpc/sysdev/mpic.c
> @@ -1748,6 +1748,7 @@ void mpic_reset_core(int cpu)
> struct mpic *mpic =3D mpic_primary;
> u32 pir;
> int cpuid =3D get_hard_smp_processor_id(cpu);
> + int i;
>=20
> /* Set target bit for core reset */
> pir =3D mpic_read(mpic->gregs, MPIC_INFO(GREG_PROCESSOR_INIT));
> @@ -1759,6 +1760,12 @@ void mpic_reset_core(int cpu)
> pir &=3D ~(1 << cpuid);
> mpic_write(mpic->gregs, MPIC_INFO(GREG_PROCESSOR_INIT), pir);
> mpic_read(mpic->gregs, MPIC_INFO(GREG_PROCESSOR_INIT));
> +
> + /* Perform 15 EOI on each reset core to clear pending interrupts =
*/
> + for (i =3D 0; i < 15; i++) {
> + _mpic_write(mpic->reg_type, &mpic->cpuregs[cpuid],
> + MPIC_CPU_EOI, 0);
> + }
> }
> #endif /* CONFIG_SMP */
>=20
> --=20
> 1.7.6.1
>=20
>=20
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev
^ permalink raw reply
* Re: Kdump/kexec for mpc83xx
From: McClintock Matthew-B29882 @ 2011-10-26 0:57 UTC (permalink / raw)
To: radha krishna; +Cc: linuxppc-dev@lists.ozlabs.org
In-Reply-To: <CAJ4m0g4TT3dNeRXqiU1oTa+tcjn+62jjrXJYTQjMoOaDAT48xg@mail.gmail.com>
On Mon, Oct 24, 2011 at 7:35 AM, radha krishna <ramamru@gmail.com> wrote:
> Hi Team,
>
> I am using Linux-3.0 on mpc8379 RDB. I have downloaded kexec-tools-2.0.2
> package from open source and cross compiled for ppc_6xx.
> But, the kexec is not booting with kernel loaded with "kexec -l".
I'm not sure who has tested on 83xx stuff, I've only done 85xx.
-M=
^ permalink raw reply
* [PATCH 5/5] powerpc/setup_{32, 64}.c: remove unneeded boot_cpuid{, _phys}
From: Matthew McClintock @ 2011-10-25 22:54 UTC (permalink / raw)
To: linuxppc-dev, kumar.gala
In-Reply-To: <1319583246-6120-1-git-send-email-msm@freescale.com>
boot_cpuid and init_thread_info.cpu are redundant, just use the
var that stays around longer and add a define to make boot_cpuid
point at the correct value
boot_cpudid_phys is not needed and can completely go away from the
SMP case, we leave it there for the non-SMP case since the paca
struct is not around to store this info
This patch also has the effect of having the logical cpu number
of the boot cpu be updated correctly independently of the ordering
of the cpu nodes in the device tree.
Signed-off-by: Matthew McClintock <msm@freescale.com>
---
Could also just change boot_cpuid every to init_thread_info.cpu instead
of using this define
This is only tested on 32-bit parts, only compiled on 64-bit
arch/powerpc/include/asm/smp.h | 2 +-
arch/powerpc/kernel/setup_32.c | 7 ++++---
arch/powerpc/kernel/setup_64.c | 1 -
3 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/arch/powerpc/include/asm/smp.h b/arch/powerpc/include/asm/smp.h
index adba970..f26c554 100644
--- a/arch/powerpc/include/asm/smp.h
+++ b/arch/powerpc/include/asm/smp.h
@@ -29,7 +29,7 @@
#endif
#include <asm/percpu.h>
-extern int boot_cpuid;
+#define boot_cpuid (init_thread_info.cpu)
extern int spinning_secondaries;
extern void cpu_die(void);
diff --git a/arch/powerpc/kernel/setup_32.c b/arch/powerpc/kernel/setup_32.c
index c1ce863..f396847 100644
--- a/arch/powerpc/kernel/setup_32.c
+++ b/arch/powerpc/kernel/setup_32.c
@@ -46,10 +46,11 @@
extern void bootx_init(unsigned long r4, unsigned long phys);
-int boot_cpuid = -1;
-EXPORT_SYMBOL_GPL(boot_cpuid);
-int boot_cpuid_phys;
+/* we need a place to store phys cpu for non-SMP case */
+#ifndef CONFIG_SMP
+int boot_cpuid_phys = -1;
EXPORT_SYMBOL_GPL(boot_cpuid_phys);
+#endif
int smp_hw_index[NR_CPUS];
diff --git a/arch/powerpc/kernel/setup_64.c b/arch/powerpc/kernel/setup_64.c
index d4168c9..eacefba 100644
--- a/arch/powerpc/kernel/setup_64.c
+++ b/arch/powerpc/kernel/setup_64.c
@@ -73,7 +73,6 @@
#define DBG(fmt...)
#endif
-int boot_cpuid = 0;
int __initdata spinning_secondaries;
u64 ppc64_pft_size;
--
1.7.6.1
^ permalink raw reply related
* [PATCH 4/5] powerpc/85xx: use physical cpu from device tree
From: Matthew McClintock @ 2011-10-25 22:54 UTC (permalink / raw)
To: linuxppc-dev, kumar.gala
In-Reply-To: <1319583246-6120-1-git-send-email-msm@freescale.com>
Currently, we assume the first CPU to come up is the boot cpu. Instead
we can use the boot_cpu_phys from the device tree.
Signed-off-by: Matthew McClintock <msm@freescale.com>
---
arch/powerpc/kernel/asm-offsets.c | 4 ++++
arch/powerpc/kernel/head_fsl_booke.S | 9 ++-------
2 files changed, 6 insertions(+), 7 deletions(-)
diff --git a/arch/powerpc/kernel/asm-offsets.c b/arch/powerpc/kernel/asm-offsets.c
index 536ffa8..264f8ad 100644
--- a/arch/powerpc/kernel/asm-offsets.c
+++ b/arch/powerpc/kernel/asm-offsets.c
@@ -28,6 +28,7 @@
#include <linux/hardirq.h>
#endif
#include <linux/kbuild.h>
+#include <linux/of_fdt.h>
#include <asm/io.h>
#include <asm/page.h>
@@ -619,5 +620,8 @@ int main(void)
DEFINE(PACA_OPAL_MC_EVT, offsetof(struct paca_struct, opal_mc_evt));
#endif
+ DEFINE(DT_BOOTCPU, offsetof(struct boot_param_header,
+ boot_cpuid_phys));
+
return 0;
}
diff --git a/arch/powerpc/kernel/head_fsl_booke.S b/arch/powerpc/kernel/head_fsl_booke.S
index 9f5d210..eb28ade 100644
--- a/arch/powerpc/kernel/head_fsl_booke.S
+++ b/arch/powerpc/kernel/head_fsl_booke.S
@@ -87,6 +87,7 @@ _ENTRY(_start);
li r25,0 /* phys kernel start (low) */
li r24,0 /* CPU number */
li r23,0 /* phys kernel start (high) */
+ lwz r22,DT_BOOTCPU(r3) /* boot_cpuid_phys */
/* We try to not make any assumptions about how the boot loader
* setup or used the TLBs. We invalidate all mappings from the
@@ -166,11 +167,8 @@ _ENTRY(__early_start)
/* Check to see if we're the second processor, and jump
* to the secondary_start code if so
*/
- lis r24, boot_cpuid@h
- ori r24, r24, boot_cpuid@l
- lwz r24, 0(r24)
- cmpwi r24, -1
mfspr r24,SPRN_PIR
+ cmpw r22,r24
bne __secondary_start
#endif
@@ -192,9 +190,6 @@ _ENTRY(__early_start)
li r0,0
stwu r0,THREAD_SIZE-STACK_FRAME_OVERHEAD(r1)
- rlwinm r22,r1,0,0,31-THREAD_SHIFT /* current thread_info */
- stw r24, TI_CPU(r22)
-
bl early_init
#ifdef CONFIG_RELOCATABLE
--
1.7.6.1
^ permalink raw reply related
* [PATCH 3/5] powerpc/85xx: Make kexec to interate over online cpus
From: Matthew McClintock @ 2011-10-25 22:54 UTC (permalink / raw)
To: linuxppc-dev, kumar.gala
In-Reply-To: <1319583246-6120-1-git-send-email-msm@freescale.com>
This is not strictly required, because this iterates over logical
cpus and they are not (currently) discontigous. But, it's cleaner
code and more obvious what is going on
Signed-off-by: Matthew McClintock <msm@freescale.com>
---
arch/powerpc/platforms/85xx/smp.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/platforms/85xx/smp.c b/arch/powerpc/platforms/85xx/smp.c
index 5b9b901..b830f8a 100644
--- a/arch/powerpc/platforms/85xx/smp.c
+++ b/arch/powerpc/platforms/85xx/smp.c
@@ -206,7 +206,7 @@ static void mpc85xx_smp_machine_kexec(struct kimage *image)
if ( !timeout )
printk(KERN_ERR "Unable to bring down secondary cpu(s)");
- for (i = 0; i < num_cpus; i++)
+ for_each_online_cpu(i)
{
if ( i == smp_processor_id() ) continue;
mpic_reset_core(i);
--
1.7.6.1
^ permalink raw reply related
* [PATCH 1/5] powerpc/85xx: issue 15 EOI after core reset
From: Matthew McClintock @ 2011-10-25 22:54 UTC (permalink / raw)
To: linuxppc-dev, kumar.gala
This is listed as a requirement after issuing a core reset to
properly clear pending interrupts
Signed-off-by: Matthew McClintock <msm@freescale.com>
---
arch/powerpc/sysdev/mpic.c | 7 +++++++
1 files changed, 7 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/sysdev/mpic.c b/arch/powerpc/sysdev/mpic.c
index 9678081..f5b83f0 100644
--- a/arch/powerpc/sysdev/mpic.c
+++ b/arch/powerpc/sysdev/mpic.c
@@ -1748,6 +1748,7 @@ void mpic_reset_core(int cpu)
struct mpic *mpic = mpic_primary;
u32 pir;
int cpuid = get_hard_smp_processor_id(cpu);
+ int i;
/* Set target bit for core reset */
pir = mpic_read(mpic->gregs, MPIC_INFO(GREG_PROCESSOR_INIT));
@@ -1759,6 +1760,12 @@ void mpic_reset_core(int cpu)
pir &= ~(1 << cpuid);
mpic_write(mpic->gregs, MPIC_INFO(GREG_PROCESSOR_INIT), pir);
mpic_read(mpic->gregs, MPIC_INFO(GREG_PROCESSOR_INIT));
+
+ /* Perform 15 EOI on each reset core to clear pending interrupts */
+ for (i = 0; i < 15; i++) {
+ _mpic_write(mpic->reg_type, &mpic->cpuregs[cpuid],
+ MPIC_CPU_EOI, 0);
+ }
}
#endif /* CONFIG_SMP */
--
1.7.6.1
^ permalink raw reply related
* [PATCH 2/5] powerpc/fsl_booke: Fix comment in head_fsl_booke.S
From: Matthew McClintock @ 2011-10-25 22:54 UTC (permalink / raw)
To: linuxppc-dev, kumar.gala
In-Reply-To: <1319583246-6120-1-git-send-email-msm@freescale.com>
Fix typo in comments introduced by:
commit 6dece0eb69b2a28e18d104bc5d707f1cb673f5e0
Author: Scott Wood <scottwood@freescale.com>
Date: Mon Jul 25 11:29:33 2011 +0000
powerpc/32: Pass device tree address as u64 to machine_init
Signed-off-by: Matthew McClintock <msm@freescale.com>
cc: Scott Wood <scottwood@freescale.com>
---
arch/powerpc/kernel/head_fsl_booke.S | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/kernel/head_fsl_booke.S b/arch/powerpc/kernel/head_fsl_booke.S
index e1c699f..9f5d210 100644
--- a/arch/powerpc/kernel/head_fsl_booke.S
+++ b/arch/powerpc/kernel/head_fsl_booke.S
@@ -80,8 +80,8 @@ _ENTRY(_start);
slw r18,r18,r17 /* r18 = page size */
addi r18,r18,-1
and r19,r3,r18 /* r19 = page offset */
- andc r31,r20,r18 /* r3 = page base */
- or r31,r31,r19 /* r3 = devtree phys addr */
+ andc r31,r20,r18 /* r31 = page base */
+ or r31,r31,r19 /* r31 = devtree phys addr */
mfspr r30,SPRN_MAS7
li r25,0 /* phys kernel start (low) */
--
1.7.6.1
^ permalink raw reply related
* RE: [PATCH v15 00/10] Add-Synopsys-DesignWare-HS-USB-OTG-driver
From: Tirumala Marri @ 2011-10-25 22:45 UTC (permalink / raw)
To: Pratyush Anand; +Cc: greg, linux-usb, linuxppc-dev
In-Reply-To: <CAHM4w1k+-KgpkW4QzRkq5wDZK0+VdVhD_QLkJy24HB0s+pE8fg@mail.gmail.com>
Hi Pratyush,
<
<Hi Tirumala,
<
<I have reviwed all the patches.
<Thanks for taking my most of the diffs over your v13.
<There are few thing, which are really very important like,
<AHB disable check, EP Disable/Stall (have commented about them in
<respective patches). I am doubtful, that how does all of usbcv test
<cases passes
<without those modifications.
<So, please have a look on those comments.
<You may add my signed-off.
<
[Tirumala Marri] I don't do all the unit tests before submission.
I only do few device tests like Ethernet and file backed storage.
For host mode I do some basic IO test. I will try embed your suggestions.
Thx,
Marri
^ permalink raw reply
* Re: [PATCH 06/11] powerpc/85xx: Add ethernet magic packet property to P1020 device tree
From: Scott Wood @ 2011-10-25 22:19 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev
In-Reply-To: <1319318452-27036-6-git-send-email-galak@kernel.crashing.org>
On 10/22/2011 04:20 PM, Kumar Gala wrote:
> All eTSEC2 controllers support waking on magic packet so fixup device
> tree to report that.
If they *all* support it, we can make the driver rely on the compatible
instead.
-Scott
^ permalink raw reply
* RE: [PATCH v15 00/10] Add-Synopsys-DesignWare-HS-USB-OTG-driver
From: Tirumala Marri @ 2011-10-25 21:54 UTC (permalink / raw)
To: Olof Johansson; +Cc: greg, linux-usb, linuxppc-dev
In-Reply-To: <20111021173302.GB27652@quad.lixom.net>
<
<Overall this driver seems to be based on the IP vendor driver? It
<looks like a completely flexible driver that implements all possible
<combinations of everything.
<
[Tirumala Marri] Some what true that it was based on skeletal driver
Provided from IP vendor.
<And as a result, it's huge, and it's got a lot of extra code in there
<that I'm
<willing to bet that you have never even executed on your platform.
<
<Please, pare it down to the portions that you have used, and know works
<and can support. If others need the extra functionality in the future,
<they can and will expand and bring in what is needed.
<
[Tirumala Marri] I can sure review and find if there are any dead
functions.
It may not be 100% free of dead code as some of the code paths may execute
Asynchronously.
<Compare this to the dwc3 driver, which is much much cleaner.
<
[Tirumala Marri] I will check.
<Overall other comments:
<
<* Register definitions are crazy long. It means you have to do lots of
<line
< wraps to keep the 80-character limit, which makes it hard to read the
<code.
[Tirumala Marri] This was suggestion from the review to use bit shifting.
I welcome any suggestions.
<* The header files seem to have been autogenerated and have unnneeded
< shift/mask operations.
<
<* It doesn't build on non-powerpc platforms since it uses out_{b,l}e
<accessors.
<
[Tirumala Marri] You have to select Little Endian mode for LE platform
>From make menuconfig.
Thx,
Marri
^ permalink raw reply
* Re: [PATCH v13 0/6] flexcan: Add support for powerpc flexcan (freescale p1010)
From: Scott Wood @ 2011-10-25 21:37 UTC (permalink / raw)
To: Kumar Gala
Cc: netdev, U Bhaskar-B22300, socketcan-core, Robin Holt, PPC list,
David S. Miller
In-Reply-To: <D79CB818-C14E-4C8D-9A8D-42B39ADE20B2@kernel.crashing.org>
On 10/18/2011 06:43 AM, Kumar Gala wrote:
>
>>> Robin,
>>>
>>> Do you remember why we went with just 'fsl,p1010-flexcan' as the device tree compatible? Do we feel the flex can on P1010 isn't the same as on MPC5xxx? or the ARM SoCs?
>>
>> The decision was due to the fact there is no true "generic" fsl.flexcan
>> chip free of any SOC implementation and therefore not something which
>> could be separately defined. That decision was made by Grant Likely.
>> I will inline that email below.
>>
>> Robin
>
>
> Thanks, I'll look into this internally at FSL. I think its confusing as hell to have "fsl,p1010-flexcan" in an ARM .dts
It's confusing to have devices labelled in vague ways that we can't tie
back to any real piece of hardware, or even a public architectural spec.
If you're talking to our hardware people, ask them to put public names
and versions, guaranteed unique throughout FSL, on all of our logic
blocks -- with public block manuals that have any SW-relevant
integration parameters clearly itemized.
Why is putting "fsl,p1010-flexcan" an an ARM device any more confusing
than putting it on some PowerPC chip that is not a p1010? Think of it
like a PCI ID, the actual value not being meaningful for much other than
its uniqueness and the ability to find a manual for the hardware.
This has been the recommended practice for quite some time.
> and don't think any reasonable ARM customer of FSL would know to put
> a PPC SOC name in their .dts.
If an ARM device tree comes along that just has
"fsl,some-arm-chip-flexcan", so what? Let the same driver bind against
both, again like PCI IDs. Additional compatibles are mainly a
convenience to give things a chance to work before the driver is updated
(a frequent irritant with PCI IDs and new hardware).
Ideally we would be publishing a sample device tree for our ARM chips
and their peripherals, though. :-P
> I'll ask the HW guys what's going on
> so we can come up with a bit more generic name so we don't have to
> constantly change this. Even if its just:
>
> fsl,ppc-flexcan & fsl,arm-flexcan.
Why is CPU instruction set relevant?
Would a QorIQ customer think to check for an existing compatible in
mpc5xxx, or even mpc83xx or mpc86xx?
-Scott
^ permalink raw reply
* Re: MPC8548 core "freezes"
From: Kumar Gala @ 2011-10-25 20:28 UTC (permalink / raw)
To: JACOBS Willy; +Cc: Linuxppc-dev@lists.ozlabs.org
In-Reply-To: <4CE4CD7158AFEE44A025CA3D42C323811B16E1D65A@spvw1505.ONE-05.GRP>
On Oct 25, 2011, at 9:37 AM, JACOBS Willy wrote:
> We discover on our own developed board based on a MPC8548, a FPGA =
connected
> through the PCIe bus which the PQ3, and running U-BOOT, Linux 2.6.33.7 =
(+ RT
> patches), and a Wind River 2.0 root file system on irregular =
occurrences that the
> PQ3 "freezes". The main application running on the PQ3 transfer data =
between the
> FPGA/PCIe (bi-directional over several PCIe lanes) and the MOTTSECs =
(at gigabit
> speed). =20
> With a Wind River Probe we can connected to the PQ3 JTAG, and to look
> into the PQ3 registers. In the erroneous state we always see:
>=20
> - all the CPU e500 core registers have the value 0
> - the L1 I/D caches are disabled
> - the L2 cache is still enabled
> - the DDR SDRAM logic is disabled (DDR_SDRAM_CFG[MEN_EN] =3D 0); the =
other DDR_SDRAM_CFG bits contains the programmed value
> - the contents of the remaining peripheral registers look OK
>=20
> We have already swapped boards, without any success.
> On the same boards we have also other applications running without =
this "freeze" problem.
> Because no exception are generated it's very difficult to catch the =
root cause.
> So any help is appreciated.
>=20
> U-Boot 2009.01.01 (Oct 08 2010 - 08:35:06)
>=20
> CPU: 8548, Version: 2.1, (0x80310021)
> Core: E500, Version: 2.2, (0x80210022)
> Clock Configuration:
> CPU:1333.333 MHz, CCB:533.333 MHz,
> DDR:266.667 MHz (533.333 MT/s data rate), LBC:66.667 MHz
> L1: D-cache 32 kB enabled
> I-cache 32 kB enabled
> I2C: ready
> Board: thales,payarapc8548, 12nc: 955683208506, snr: 0014
> DRAM: DDR: 2 GB
> FLASH: 128 MB
> L2: 512 KB enabled
> PCI: 32 bit, 66 MHz, async, host, arbiter
> Scanning PCI bus 00
> PCI on bus 00 - 00
>=20
> PCIE connected to slot as Root Complex (base address e000a000)
> PCIE on bus 1 - 1
> In: serial
> Out: serial
> Err: serial
> Net: tsec0, tsec1, tsec2 [PRIME]
You appear to be freezing in u-boot, should ask your question on that =
list.
- k=
^ permalink raw reply
* Re: IRQ2 and IRQ 3
From: Scott Wood @ 2011-10-25 16:14 UTC (permalink / raw)
To: Bhushan Bharat-R65777
Cc: Wood Scott-B07421, linuxppc-dev@lists.ozlabs.org,
smitha.vanga@wipro.com
In-Reply-To: <B8D6CA50DACE9E4AAADE9A4D56FBAAE623CED7@039-SN1MPN1-005.039d.mgd.msft.net>
On 10/18/2011 10:03 AM, Bhushan Bharat-R65777 wrote:
> Hi,
>
> For detail please look at ePAPR specification.
>
> Say i2c interrupt number is 21 then you can try
> "interrupts = <21 8>;" in device tree.
Please read the FSL MPIC binding. For internal interrupts, you need to
add 16 to the number in the manual.
-Scott
^ permalink raw reply
* Re: [PATCH 2/3] [44x] Enable CONFIG_RELOCATABLE for PPC44x
From: Scott Wood @ 2011-10-25 15:34 UTC (permalink / raw)
To: Dave Hansen
Cc: Michal Simek, tmarri, Mahesh Jagannath Salgaonkar, David Laight,
Suzuki Poulose, Paul Mackerras, linux ppc dev, Vivek Goyal
In-Reply-To: <1318428902.3782.9.camel@nimitz>
On 10/12/2011 09:15 AM, Dave Hansen wrote:
> On Tue, 2011-10-11 at 18:24 +0530, Suzuki Poulose wrote:
>> On 10/10/11 23:30, Scott Wood wrote:
>>> On 10/10/2011 04:56 AM, Suzuki K. Poulose wrote:
>>>> #if defined(CONFIG_RELOCATABLE)&& defined(CONFIG_44x)
>>>> #define __va(x) ((void *)(unsigned long)((phys_addr_t)(x) - PHYSICAL_START + (KERNELBASE + RELOC_OFFSET)))
>>>> #define __pa(x) ((unsigned long)(x) + PHYSICAL_START - (KERNELBASE + RELOC_OFFSET))
>>>> #endif
>>>
>>> Why is this 44x-specific?
>>
>> As of now, we compile with relocations only for the 44x. We could make this
>> generic once the approach is accepted by everyone and implemented on the other
>> platforms.
>
> This is not the place to enforce that kind of thing. If
> CONFIG_RELOCATABLE is only supported on one platform, then do:
>
> config RELOCATABLE
> depends on 44x
>
> and take the 44x reference out of the #ifdef.
...but please first rename the existing, different CONFIG_RELOCATABLE
behavior that is currently supported on e500.
-Scott
^ permalink raw reply
* MPC8548 core "freezes"
From: JACOBS Willy @ 2011-10-25 14:37 UTC (permalink / raw)
To: Linuxppc-dev@lists.ozlabs.org
We discover on our own developed board based on a MPC8548, a FPGA connected
through the PCIe bus which the PQ3, and running U-BOOT, Linux 2.6.33.7 (+ R=
T
patches), and a Wind River 2.0 root file system on irregular occurrences th=
at the
PQ3 "freezes". The main application running on the PQ3 transfer data betwee=
n the
FPGA/PCIe (bi-directional over several PCIe lanes) and the MOTTSECs (at gig=
abit
speed). =20
With a Wind River Probe we can connected to the PQ3 JTAG, and to look
into the PQ3 registers. In the erroneous state we always see:
- all the CPU e500 core registers have the value 0
- the L1 I/D caches are disabled
- the L2 cache is still enabled
- the DDR SDRAM logic is disabled (DDR_SDRAM_CFG[MEN_EN] =3D 0); the other =
DDR_SDRAM_CFG bits contains the programmed value
- the contents of the remaining peripheral registers look OK
We have already swapped boards, without any success.
On the same boards we have also other applications running without this "fr=
eeze" problem.
Because no exception are generated it's very difficult to catch the root ca=
use.
So any help is appreciated.
U-Boot 2009.01.01 (Oct 08 2010 - 08:35:06)
CPU: 8548, Version: 2.1, (0x80310021)
Core: E500, Version: 2.2, (0x80210022)
Clock Configuration:
CPU:1333.333 MHz, CCB:533.333 MHz,
DDR:266.667 MHz (533.333 MT/s data rate), LBC:66.667 MHz
L1: D-cache 32 kB enabled
I-cache 32 kB enabled
I2C: ready
Board: thales,payarapc8548, 12nc: 955683208506, snr: 0014
DRAM: DDR: 2 GB
FLASH: 128 MB
L2: 512 KB enabled
PCI: 32 bit, 66 MHz, async, host, arbiter
Scanning PCI bus 00
PCI on bus 00 - 00
PCIE connected to slot as Root Complex (base address e000a000)
PCIE on bus 1 - 1
In: serial
Out: serial
Err: serial
Net: tsec0, tsec1, tsec2 [PRIME]
--- willy
------------------------------------------------------------------------------------------------------------
Disclaimer:
If you are not the intended recipient of this email, please notify the sender and delete it.
Any unauthorized copying, disclosure or distribution of this email or its attachment(s) is forbidden.
Thales Nederland BV will not accept liability for any damage caused by this email or its attachment(s).
Thales Nederland BV is seated in Hengelo and is registered at the Chamber of Commerce under number 06061578.
------------------------------------------------------------------------------------------------------------
^ permalink raw reply
* Re: Kdump/kexec for mpc83xx
From: Suzuki Poulose @ 2011-10-25 12:14 UTC (permalink / raw)
To: radha krishna; +Cc: linuxppc-dev
In-Reply-To: <CAJ4m0g4TT3dNeRXqiU1oTa+tcjn+62jjrXJYTQjMoOaDAT48xg@mail.gmail.com>
On 10/24/11 18:05, radha krishna wrote:
> Hi Team,
>
> I am using Linux-3.0 on mpc8379 RDB. I have downloaded kexec-tools-2.0.2 package from open source and cross compiled for ppc_6xx.
> But, the kexec is not booting with kernel loaded with "kexec -l".
I am not familiar with mcp8379 RDB. AFAIK, the ppc32 port of kexec-tools work just fine. You may need to
check the kernel side to see if you are setting up the 'real mode' environment for the kernel copy step.
Thanks
Suzuki
^ permalink raw reply
* [PATCH v2 4/5] [44x] Enable CRASH_DUMP for 440x
From: Suzuki K. Poulose @ 2011-10-25 11:54 UTC (permalink / raw)
To: linuxppc-dev
Cc: Suzuki Poulose, Alan Modra, Scott Wood, Paul Mackerras,
Dave Hansen
In-Reply-To: <20111025114829.8183.1725.stgit@suzukikp.in.ibm.com>
Now that we have relocatable kernel, supporting CRASH_DUMP only requires
turning the switches on for UP machines.
We don't have kexec support on 47x yet. Enabling SMP support would be done
as part of enabling the PPC_47x support.
Signed-off-by: Suzuki K. Poulose <suzuki@in.ibm.com>
Cc: Josh Boyer <jwboyer@gmail.com>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: linuxppc-dev <linuxppc-dev@lists.ozlabs.org>
---
arch/powerpc/Kconfig | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index 1cedcda..4de7733 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -362,8 +362,8 @@ config KEXEC
config CRASH_DUMP
bool "Build a kdump crash kernel"
- depends on PPC64 || 6xx || FSL_BOOKE
- select RELOCATABLE if PPC64 || FSL_BOOKE
+ depends on PPC64 || 6xx || FSL_BOOKE || (44x && !SMP)
+ select RELOCATABLE if PPC64 || FSL_BOOKE || 44x
help
Build a kernel suitable for use as a kdump capture kernel.
The same kernel binary can be used as production kernel and dump
^ permalink raw reply related
* [PATCH v2 5/5] [boot] Change the load address for the wrapper to fit the kernel
From: Suzuki K. Poulose @ 2011-10-25 11:54 UTC (permalink / raw)
To: linuxppc-dev
Cc: Suzuki Poulose, Alan Modra, Scott Wood, Paul Mackerras,
Dave Hansen
In-Reply-To: <20111025114829.8183.1725.stgit@suzukikp.in.ibm.com>
The wrapper code which uncompresses the kernel in case of a 'ppc' boot
is by default loaded at 0x00400000 and the kernel will be uncompressed
to fit the location 0-0x00400000. But with dynamic relocations, the size
of the kernel may exceed 0x00400000(4M). This would cause an overlap
of the uncompressed kernel and the boot wrapper, causing a failure in
boot.
The message looks like :
zImage starting: loaded at 0x00400000 (sp: 0x0065ffb0)
Allocating 0x5ce650 bytes for kernel ...
Insufficient memory for kernel at address 0! (_start=00400000, uncompressed size=00591a20)
This patch shifts the load address of the boot wrapper code to the next higher MB,
according to the size of the uncompressed vmlinux.
Signed-off-by: Suzuki K. Poulose <suzuki@in.ibm.com>
---
arch/powerpc/boot/wrapper | 20 ++++++++++++++++++++
1 files changed, 20 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/boot/wrapper b/arch/powerpc/boot/wrapper
index c74531a..213a9fd 100755
--- a/arch/powerpc/boot/wrapper
+++ b/arch/powerpc/boot/wrapper
@@ -257,6 +257,8 @@ vmz="$tmpdir/`basename \"$kernel\"`.$ext"
if [ -z "$cacheit" -o ! -f "$vmz$gzip" -o "$vmz$gzip" -ot "$kernel" ]; then
${CROSS}objcopy $objflags "$kernel" "$vmz.$$"
+ strip_size=$(stat -c %s $vmz.$$)
+
if [ -n "$gzip" ]; then
gzip -n -f -9 "$vmz.$$"
fi
@@ -266,6 +268,24 @@ if [ -z "$cacheit" -o ! -f "$vmz$gzip" -o "$vmz$gzip" -ot "$kernel" ]; then
else
vmz="$vmz.$$"
fi
+else
+ # Calculate the vmlinux.strip size
+ ${CROSS}objcopy $objflags "$kernel" "$vmz.$$"
+ strip_size=$(stat -c %s $vmz.$$)
+ rm -f $vmz.$$
+fi
+
+# Round the size to next higher MB limit
+round_size=$(((strip_size + 0xfffff) & 0xfff00000))
+
+round_size=0x$(printf "%x\n" $round_size)
+link_addr=$(printf "%d\n" $link_address)
+
+if [ $link_addr -lt $strip_size ]; then
+ echo "WARN: Uncompressed kernel size(0x$(printf "%x\n" $strip_size))" \
+ " exceeds the address of the wrapper($link_address)"
+ echo "WARN: Fixing the link_address to ($round_size))"
+ link_address=$round_size
fi
vmz="$vmz$gzip"
^ permalink raw reply related
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