Re: linux support for freescale e5500 core?
On 09/16/2010 11:33 PM, Benjamin Herrenschmidt wrote: > On Fri, 2010-09-17 at 00:17 -0500, Kumar Gala wrote: >> Not sure how the 970 bit worked, but this seems a bit problematic for >> switching between kernel and application for how we do this on >> e500mc/e5500. We'd have to touch the control bit on every exception >> path which seems ugly to me. > > Unless the kernel uses dcbzl (feature fixup replacement ?) > > In that case it's on context switch only. This is basically what we did. Kernel and system libraries (glibc and friends) always use dcbzl, process flag indicates compatibility, touch the control bit on task context switch if the prev and next processes have different compatibility modes. On the 970 you have to invalidate the entire icache whenever you change the control bit. This is a pain involving a loop that calls icbi on 512 cachelines. Chris -- Chris Friesen Software Developer GENBAND chris.frie...@genband.com www.genband.com ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: linux support for freescale e5500 core?
On Fri, 2010-09-17 at 00:17 -0500, Kumar Gala wrote: > Not sure how the 970 bit worked, but this seems a bit problematic for > switching between kernel and application for how we do this on > e500mc/e5500. We'd have to touch the control bit on every exception > path which seems ugly to me. Unless the kernel uses dcbzl (feature fixup replacement ?) In that case it's on context switch only. Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: linux support for freescale e5500 core?
On Sep 16, 2010, at 7:03 PM, Benjamin Herrenschmidt wrote: > On Thu, 2010-09-16 at 16:26 -0600, Chris Friesen wrote: >>> Sounds like a candidate for upstreaming the patch :-) >> >> As I recall we proposed upstreaming it a while back but there wasn't a >> lot of interest since it's most useful in supporting poorly-written >> legacy apps. :) > > Heh. Well as long as only 970 had that bit ... but with e5500 coming up > with that too, I suppose it makes -some- sense. Let's at least look at > the approach you took and we can decide based on how invasive/ugly it > is :-) Not sure how the 970 bit worked, but this seems a bit problematic for switching between kernel and application for how we do this on e500mc/e5500. We'd have to touch the control bit on every exception path which seems ugly to me. - k ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: linux-next: build failure after merge of the final tree (powerpc related)
Hi Ben,
On Fri, 3 Sep 2010 13:24:10 +1000 Stephen Rothwell
wrote:
>
> After merging the final tree, today's linux-next build
> (powerpc64 allnoconfig) failed like this:
>
> arch/powerpc/kernel/built-in.o: In function `.sys_call_table':
> (.text+0x8d48): undefined reference to `.compat_sys_recv'
>
> Caused by commit 86250b9d12caa1a3dee12a7cf638b7dd70eaadb6 ("powerpc: Wire
> up direct socket system calls").
>
> I have applied this patch for today:
>
> From: Stephen Rothwell
> Date: Fri, 3 Sep 2010 13:19:04 +1000
> Subject: [PATCH] powerpc: define a compat_sys_recv cond_syscall
>
> Signed-off-by: Stephen Rothwell
> ---
> kernel/sys_ni.c |1 +
> 1 files changed, 1 insertions(+), 0 deletions(-)
>
> diff --git a/kernel/sys_ni.c b/kernel/sys_ni.c
> index bad369e..c782fe9 100644
> --- a/kernel/sys_ni.c
> +++ b/kernel/sys_ni.c
> @@ -50,6 +50,7 @@ cond_syscall(compat_sys_sendmsg);
> cond_syscall(sys_recvmsg);
> cond_syscall(sys_recvmmsg);
> cond_syscall(compat_sys_recvmsg);
> +cond_syscall(compat_sys_recv);
> cond_syscall(compat_sys_recvfrom);
> cond_syscall(compat_sys_recvmmsg);
> cond_syscall(sys_socketcall);
> --
> 1.7.1
Ping?
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
pgp8yfN5UfJid.pgp
Description: PGP signature
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Generating elf kernel ?
Scott Wood wrote: > On Thu, 16 Sep 2010 10:37:32 +0800 > "tiejun.chen" wrote: > >> 1> can you load the Linux vmlinux directly to the physical address '0' on >> current bootloader? > > That depends on what bootloader we're talking about -- I don't know > what the original poster's custom loader can do. Obviously the > bootloader itself would have to be executing from some other address > (e.g. U-Boot runs from the top of RAM). > >> 2> additionally you have to find a way to pass dtb to the native vmlinux. > > Yes, of course. But that's a different issue. :-) > >> I believe the hypervisor can boot vmlinux directly. But your so-called >> vmlinux >> should be guest OS. And the hypervisor will handle/assit TLB exception for >> the >> guest OS on MMU. Right? So you can use the hypervisor to load vmlinux to any >> physical address as you expect. > > I was just using our hypervisor as an example, since it has an ELF > loader that can pass a device tree. > >> But the guest OS should not be same as the native Linux. > > The guest OS *is* the same as native Linux, as far as TLB handling is > concerned. Looks you means the TLB exception handler should be same between the native and the guest OS. Right? Here I assume we're talking about e500mc since as far as I know for Freescale only e500mc is designed to support virtual machine based on ISA 2.0.6. I also know all TLB exceptions can direct to the guest OS when we enable EPCR[DTLBGS|ITLBGS|DSIGS|ISIGS]. But some TLB instructions (i.e. tlbwe )are the privileged instructions. So the guest OS always trap into the hypervisor and then the hypervisor should complete the real action with appropriate physical address. And also the hypervisor can supervisor if the guest OS want to access the invalid physical space. So I don't think the guest OS is same as native Linux :) Cheers Tiejun > > -Scott > > ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: linux support for freescale e5500 core?
On Thu, 2010-09-16 at 16:26 -0600, Chris Friesen wrote: > > Sounds like a candidate for upstreaming the patch :-) > > As I recall we proposed upstreaming it a while back but there wasn't a > lot of interest since it's most useful in supporting poorly-written > legacy apps. :) Heh. Well as long as only 970 had that bit ... but with e5500 coming up with that too, I suppose it makes -some- sense. Let's at least look at the approach you took and we can decide based on how invasive/ugly it is :-) Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 3/4] powerpc/85xx: Minor fixups for kexec on 85xx
Make kexec_down_cpus atmoic since it will be incremented by all
cores as they are coming down
Remove duplicate calls to mpc85xx_smp_kexec_down, now it's called
by the crash and normal kexec pathway only once
Increase the timeout to wait for other cores to shutdown
Signed-off-by: Matthew McClintock
---
arch/powerpc/platforms/85xx/smp.c | 24 +++-
1 files changed, 11 insertions(+), 13 deletions(-)
diff --git a/arch/powerpc/platforms/85xx/smp.c
b/arch/powerpc/platforms/85xx/smp.c
index cb8ad3b..29416a9 100644
--- a/arch/powerpc/platforms/85xx/smp.c
+++ b/arch/powerpc/platforms/85xx/smp.c
@@ -114,17 +114,15 @@ struct smp_ops_t smp_85xx_ops = {
};
#ifdef CONFIG_KEXEC
-static int kexec_down_cpus = 0;
+atomic_t kexec_down_cpus = ATOMIC_INIT(0);
void mpc85xx_smp_kexec_cpu_down(int crash_shutdown, int secondary)
{
- /* When crashing, this gets called on all CPU's we only
-* take down the non-boot cpus */
- if (smp_processor_id() != boot_cpuid)
- {
- local_irq_disable();
- kexec_down_cpus++;
+ local_irq_disable();
+ if (secondary) {
+ atomic_inc(&kexec_down_cpus);
+ /* loop forever */
while (1);
}
}
@@ -137,14 +135,14 @@ static void mpc85xx_smp_kexec_down(void *arg)
static void mpc85xx_smp_machine_kexec(struct kimage *image)
{
- int timeout = 2000;
- int i;
+ int timeout = INT_MAX;
+ int i, num_cpus = num_present_cpus();
- set_cpus_allowed(current, cpumask_of_cpu(boot_cpuid));
- smp_call_function(mpc85xx_smp_kexec_down, NULL, 0);
+ if (image->type == KEXEC_TYPE_DEFAULT)
+ smp_call_function(mpc85xx_smp_kexec_down, NULL, 0);
- while ( (kexec_down_cpus != (num_online_cpus() - 1)) &&
+ while ( (atomic_read(&kexec_down_cpus) != (num_cpus - 1)) &&
( timeout > 0 ) )
{
timeout--;
@@ -153,7 +151,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_present_cpus(); i++)
+ for (i = 0; i < num_cpus; i++)
{
if ( i == smp_processor_id() ) continue;
mpic_reset_core(i);
--
1.6.6.1
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 4/4] powerpc/85xx: flush dcache before resetting cores
When we do an mpic_reset_core we need to make sure the dcache
is flushed
Signed-off-by: Matthew McClintock
---
arch/powerpc/platforms/85xx/smp.c | 50 +
1 files changed, 50 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/platforms/85xx/smp.c
b/arch/powerpc/platforms/85xx/smp.c
index 29416a9..c89a370 100644
--- a/arch/powerpc/platforms/85xx/smp.c
+++ b/arch/powerpc/platforms/85xx/smp.c
@@ -16,6 +16,7 @@
#include
#include
#include
+#include
#include
#include
@@ -133,11 +134,60 @@ static void mpc85xx_smp_kexec_down(void *arg)
ppc_md.kexec_cpu_down(0,1);
}
+static void map_and_flush(unsigned long paddr)
+{
+ struct page *page = pfn_to_page(paddr >> PAGE_SHIFT);
+ unsigned long kaddr = (unsigned long)kmap(page);
+
+ flush_dcache_range(kaddr, kaddr + PAGE_SIZE);
+ kunmap(page);
+}
+
+/**
+ * Before we reset the other cores, we need to flush relevant cache
+ * out to memory so we don't get anything corrupted, some of these flushes
+ * are performed out of an overabundance of caution as interrupts are not
+ * disabled yet and we can switch cores
+ */
+static void mpc85xx_smp_flush_dcache_kexec(struct kimage *image)
+{
+ kimage_entry_t *ptr, entry;
+ unsigned long paddr;
+ int i;
+
+ if (image->type == KEXEC_TYPE_DEFAULT) {
+ /* normal kexec images are stored in temporary pages */
+ for (ptr = &image->head; (entry = *ptr) && !(entry & IND_DONE);
+ptr = (entry & IND_INDIRECTION) ?
+ phys_to_virt(entry & PAGE_MASK) : ptr + 1) {
+ if (!(entry & IND_DESTINATION)) {
+ map_and_flush(entry);
+ }
+ }
+ /* flush out last IND_DONE page */
+ map_and_flush(entry);
+ } else {
+ /* crash type kexec images are copied to the crash region */
+ for (i = 0; i < image->nr_segments; i++) {
+ struct kexec_segment *seg = &image->segment[i];
+ for (paddr = seg->mem; paddr < seg->mem + seg->memsz;
+paddr += PAGE_SIZE) {
+ map_and_flush(paddr);
+ }
+ }
+ }
+
+ /* also flush the kimage struct to be passed in as well */
+ flush_dcache_range((unsigned long)image,
+ (unsigned long)image + sizeof(*image));
+}
+
static void mpc85xx_smp_machine_kexec(struct kimage *image)
{
int timeout = INT_MAX;
int i, num_cpus = num_present_cpus();
+ mpc85xx_smp_flush_dcache_kexec(image);
if (image->type == KEXEC_TYPE_DEFAULT)
smp_call_function(mpc85xx_smp_kexec_down, NULL, 0);
--
1.6.6.1
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 01/15] ppc: fix return type of BUID_{HI,LO} macros
On Thu, 16 Sep 2010 17:54:46 -0500 Linas Vepstas wrote: > Acked-by: Linas Vepstas > > I'm guessing this worked up til now because the rtas_call function prototype > was telling compiler to cast these to 32-bit before passing them as args. > (and since these would still get passed as one arg per 64-bit reg, it > still wouldn't go wrong.) > > What I'm wondering about is why there was no compiler warning about an > implicit cast of a 64-bit int to a 32-bit int? Surely, this is something that > should be warned about! -Wconversion enables this. There'd be a lot of false positives to squash with that enabled -- and it might not be worth the resulting explosion in casts. -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 01/15] ppc: fix return type of BUID_{HI,LO} macros
Acked-by: Linas Vepstas I'm guessing this worked up til now because the rtas_call function prototype was telling compiler to cast these to 32-bit before passing them as args. (and since these would still get passed as one arg per 64-bit reg, it still wouldn't go wrong.) What I'm wondering about is why there was no compiler warning about an implicit cast of a 64-bit int to a 32-bit int? Surely, this is something that should be warned about! -- Linas On 15 September 2010 13:13, Nishanth Aravamudan wrote: > BUID_HI and BUID_LO are used to pass data to call_rtas, which expects > ints or u32s. But the macro doesn't cast the return, so the result is > still u64. Use the upper_32_bits and lower_32_bits macros that have been > added to kernel.h. > > Found by getting printf format errors trying to debug print the args, no > actual code change for 64 bit kernels where the macros are actually > used. > > Signed-off-by: Milton Miller > Signed-off-by: Nishanth Aravamudan > --- > arch/powerpc/include/asm/ppc-pci.h | 4 ++-- > 1 files changed, 2 insertions(+), 2 deletions(-) > > diff --git a/arch/powerpc/include/asm/ppc-pci.h > b/arch/powerpc/include/asm/ppc-pci.h > index 42fdff0..43268f1 100644 > --- a/arch/powerpc/include/asm/ppc-pci.h > +++ b/arch/powerpc/include/asm/ppc-pci.h > @@ -28,8 +28,8 @@ extern void find_and_init_phbs(void); > extern struct pci_dev *isa_bridge_pcidev; /* may be NULL if no ISA bus > */ > > /** Bus Unit ID macros; get low and hi 32-bits of the 64-bit BUID */ > -#define BUID_HI(buid) ((buid) >> 32) > -#define BUID_LO(buid) ((buid) & 0x) > +#define BUID_HI(buid) upper_32_bits(buid) > +#define BUID_LO(buid) lower_32_bits(buid) > > /* PCI device_node operations */ > struct device_node; > -- > 1.7.0.4 > > ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 1/4] powerpc/kexec: make masking/disabling interrupts generic
Right now just the kexec crash pathway turns turns off the
interrupts. Pull that out and make a generic version for
use elsewhere
Signed-off-by: Matthew McClintock
---
arch/powerpc/include/asm/kexec.h |1 +
arch/powerpc/kernel/crash.c| 13 +
arch/powerpc/kernel/machine_kexec.c| 24
arch/powerpc/kernel/machine_kexec_32.c |4
4 files changed, 30 insertions(+), 12 deletions(-)
diff --git a/arch/powerpc/include/asm/kexec.h b/arch/powerpc/include/asm/kexec.h
index 076327f..f54408d 100644
--- a/arch/powerpc/include/asm/kexec.h
+++ b/arch/powerpc/include/asm/kexec.h
@@ -91,6 +91,7 @@ extern void machine_kexec_simple(struct kimage *image);
extern void crash_kexec_secondary(struct pt_regs *regs);
extern int overlaps_crashkernel(unsigned long start, unsigned long size);
extern void reserve_crashkernel(void);
+extern void machine_kexec_mask_interrupts(void);
#else /* !CONFIG_KEXEC */
static inline int kexec_sr_activated(int cpu) { return 0; }
diff --git a/arch/powerpc/kernel/crash.c b/arch/powerpc/kernel/crash.c
index 4457382..832c8c4 100644
--- a/arch/powerpc/kernel/crash.c
+++ b/arch/powerpc/kernel/crash.c
@@ -414,18 +414,7 @@ void default_machine_crash_shutdown(struct pt_regs *regs)
crash_kexec_wait_realmode(crashing_cpu);
#endif
- for_each_irq(i) {
- struct irq_desc *desc = irq_to_desc(i);
-
- if (!desc || !desc->chip || !desc->chip->eoi)
- continue;
-
- if (desc->status & IRQ_INPROGRESS)
- desc->chip->eoi(i);
-
- if (!(desc->status & IRQ_DISABLED))
- desc->chip->shutdown(i);
- }
+ machine_kexec_mask_interrupts();
/*
* Call registered shutdown routines savely. Swap out
diff --git a/arch/powerpc/kernel/machine_kexec.c
b/arch/powerpc/kernel/machine_kexec.c
index dd6c141..df7e20c 100644
--- a/arch/powerpc/kernel/machine_kexec.c
+++ b/arch/powerpc/kernel/machine_kexec.c
@@ -14,10 +14,34 @@
#include
#include
#include
+#include
+
#include
#include
#include
+void machine_kexec_mask_interrupts(void) {
+ unsigned int i;
+
+ for_each_irq(i) {
+ struct irq_desc *desc = irq_to_desc(i);
+
+ if (!desc || !desc->chip)
+ continue;
+
+ if (desc->chip->eoi &&
+ desc->status & IRQ_INPROGRESS)
+ desc->chip->eoi(i);
+
+ if (desc->chip->mask)
+ desc->chip->mask(i);
+
+ if (desc->chip->disable &&
+ !(desc->status & IRQ_DISABLED))
+ desc->chip->disable(i);
+ }
+}
+
void machine_crash_shutdown(struct pt_regs *regs)
{
if (ppc_md.machine_crash_shutdown)
diff --git a/arch/powerpc/kernel/machine_kexec_32.c
b/arch/powerpc/kernel/machine_kexec_32.c
index ae63a96..e63f2e7 100644
--- a/arch/powerpc/kernel/machine_kexec_32.c
+++ b/arch/powerpc/kernel/machine_kexec_32.c
@@ -39,6 +39,10 @@ void default_machine_kexec(struct kimage *image)
/* Interrupts aren't acceptable while we reboot */
local_irq_disable();
+ /* mask each interrupt so we are in a more sane state for the
+* kexec kernel */
+ machine_kexec_mask_interrupts();
+
page_list = image->head;
/* we need both effective and real address here */
--
1.6.6.1
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 2/4] powerpc/85xx: Remove call to mpic_teardown_this_cpu in kexec
We no longer need to call this explicitly as a generic version is
called by default
Signed-off-by: Matthew McClintock
---
arch/powerpc/platforms/85xx/smp.c |2 --
1 files changed, 0 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/platforms/85xx/smp.c
b/arch/powerpc/platforms/85xx/smp.c
index a6b1065..cb8ad3b 100644
--- a/arch/powerpc/platforms/85xx/smp.c
+++ b/arch/powerpc/platforms/85xx/smp.c
@@ -118,8 +118,6 @@ static int kexec_down_cpus = 0;
void mpc85xx_smp_kexec_cpu_down(int crash_shutdown, int secondary)
{
- mpic_teardown_this_cpu(1);
-
/* When crashing, this gets called on all CPU's we only
* take down the non-boot cpus */
if (smp_processor_id() != boot_cpuid)
--
1.6.6.1
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: linux support for freescale e5500 core?
On 09/16/2010 04:03 PM, Benjamin Herrenschmidt wrote: > On Thu, 2010-09-16 at 15:44 -0600, Chris Friesen wrote: >> Right. We currently use a 970-series cpu and have implemented a >> per-process flag to indicate whether 32-byte mode is needed or not. >> We'd have to do something similar with the new cpu. > > Sounds like a candidate for upstreaming the patch :-) As I recall we proposed upstreaming it a while back but there wasn't a lot of interest since it's most useful in supporting poorly-written legacy apps. :) Chris -- The author works for GENBAND Corporation (GENBAND) who is solely responsible for this email and its contents. All enquiries regarding this email should be addressed to GENBAND. Nortel has provided the use of the nortel.com domain to GENBAND in connection with this email solely for the purpose of connectivity and Nortel Networks Inc. has no liability for the email or its contents. GENBAND's web site is http://www.genband.com ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 4/7] wire up sys_time_change_notify() on powerpc
Signed-off-by: Alexander Shishkin CC: Benjamin Herrenschmidt CC: Paul Mackerras CC: Andrew Morton CC: Andreas Schwab CC: Alexander Shishkin CC: Christoph Hellwig CC: Jesper Nilsson CC: linuxppc-dev@lists.ozlabs.org CC: linux-ker...@vger.kernel.org --- arch/powerpc/include/asm/systbl.h |1 + arch/powerpc/include/asm/unistd.h |3 ++- 2 files changed, 3 insertions(+), 1 deletions(-) diff --git a/arch/powerpc/include/asm/systbl.h b/arch/powerpc/include/asm/systbl.h index 3d21266..124b610 100644 --- a/arch/powerpc/include/asm/systbl.h +++ b/arch/powerpc/include/asm/systbl.h @@ -329,3 +329,4 @@ COMPAT_SYS(rt_tgsigqueueinfo) SYSCALL(fanotify_init) COMPAT_SYS(fanotify_mark) SYSCALL_SPU(prlimit64) +SYSCALL(time_change_notify) diff --git a/arch/powerpc/include/asm/unistd.h b/arch/powerpc/include/asm/unistd.h index 597e6f9..6ab64da 100644 --- a/arch/powerpc/include/asm/unistd.h +++ b/arch/powerpc/include/asm/unistd.h @@ -348,10 +348,11 @@ #define __NR_fanotify_init 323 #define __NR_fanotify_mark 324 #define __NR_prlimit64 325 +#define __NR_time_change_notify326 #ifdef __KERNEL__ -#define __NR_syscalls 326 +#define __NR_syscalls 327 #define __NR__exit __NR_exit #define NR_syscalls__NR_syscalls -- 1.7.2.1.45.gb66c2 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: linux support for freescale e5500 core?
On Thu, 2010-09-16 at 15:44 -0600, Chris Friesen wrote: > On 09/16/2010 03:39 PM, Scott Wood wrote: > > On Thu, 16 Sep 2010 14:06:37 -0600 > > Chris Friesen wrote: > > > >> We're looking at maybe doing some work with an e5500-based system. Is > >> there any support existing/planned for this core? > > > > Check with whoever you'd be getting the hardware from about a BSP. > > > > And yes, it should be supported upstream at some point. > > We haven't settled on a vendor yet, so I was just wondering in general > what the story was around support. Well, the "core" support for 64-bit BookE is upstream (and has been for a little while) so +/- specific tweaks FSL may have done and the usual SoC/board support, it shouldn't be too far off. > Right. We currently use a 970-series cpu and have implemented a > per-process flag to indicate whether 32-byte mode is needed or not. > We'd have to do something similar with the new cpu. Sounds like a candidate for upstreaming the patch :-) > One last question--can you comment on the speed of an e5500 relative to > a 970 for integer operations? Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Reserved pages in PowerPC
On Thu, 2010-09-16 at 17:38 +0530, Ankita Garg wrote: > Thanks Ben for taking a look at this. So I checked the rtas messages > on > the serial console and see the following: > > instantiating rtas at 0x0f632000... done > > Which does not correspond to the higher addresses that I see as > reserved > (observation on a 16G machine). Well, I'd suggest you audit prom_init.c which builds the reserve map, and the various memblock_reserve() calls in prom.c Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: linux support for freescale e5500 core?
On 09/16/2010 03:39 PM, Scott Wood wrote: > On Thu, 16 Sep 2010 14:06:37 -0600 > Chris Friesen wrote: > >> We're looking at maybe doing some work with an e5500-based system. Is >> there any support existing/planned for this core? > > Check with whoever you'd be getting the hardware from about a BSP. > > And yes, it should be supported upstream at some point. We haven't settled on a vendor yet, so I was just wondering in general what the story was around support. >> Also, do we know what the cache line size is--we have some legacy apps >> that assume 32-byte. > > The cache line is 64 bytes. As with e500mc, there is a "dcbz32" mode > for compatibility, though you probably lose much of the performance > benefit of dcbz, and it might upset other software that properly checks > for the cache line size but doesn't use dcbzl. Right. We currently use a 970-series cpu and have implemented a per-process flag to indicate whether 32-byte mode is needed or not. We'd have to do something similar with the new cpu. One last question--can you comment on the speed of an e5500 relative to a 970 for integer operations? Thanks, Chris -- Chris Friesen Software Developer GENBAND chris.frie...@genband.com www.genband.com ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: linux support for freescale e5500 core?
On Thu, 16 Sep 2010 14:06:37 -0600 Chris Friesen wrote: > We're looking at maybe doing some work with an e5500-based system. Is > there any support existing/planned for this core? Check with whoever you'd be getting the hardware from about a BSP. And yes, it should be supported upstream at some point. > Also, do we know what the cache line size is--we have some legacy apps > that assume 32-byte. The cache line is 64 bytes. As with e500mc, there is a "dcbz32" mode for compatibility, though you probably lose much of the performance benefit of dcbz, and it might upset other software that properly checks for the cache line size but doesn't use dcbzl. -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 00/15] change default_llseek action
On Tue, 14 Sep 2010 22:22:28 +0200, Arnd Bergmann said: > This changes *all* instances of struct file_operations in > the kernel to have a .llseek operation and then changes > the default to no_llseek, which returns -ESPIPE, which > is what we had decided some time ago in a discussion > with Christoph Hellwig. I don't suppose there's any clean way to throw a build error or a printk_on_once() or something if we encounter an unconverted 'struct file_operations', is there? I have this creeping fear that this patch will go upstream during the merge window - as will 12 new staging/ drivers from authors who didn't get the memo yet. Other than the "missed converting a new usage" issue, it looks OK to me. pgpnRMUiAwHtj.pgp Description: PGP signature ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Can't find Ethernet PHY on MDIO bus
Hi.
I have 2 Ethernet PHYs connected to Powerpc MPC8313 TSEC1 and TSEC2
interfaces. The PHY I'm having trouble with is a Marvell 88E3015, and its
connected to TSEC2. I have mapped them in DTS file as follows:
m...@24520 {
#address-cells = <1>;
#size-cells = <0>;
compatible = "fsl,gianfar-mdio";
reg = <0x24520 0x20>;
phy3: ethernet-...@3 {
reg = <0x3>;
device_type = "ethernet-phy";
};
phy1: ethernet-...@1 {
interrupt-parent = <&ipic>;
interrupts = <24 0x8>;
reg = <0x1>;
device_type = "ethernet-phy";
};
};
enet0: ether...@24000 {
cell-index = <0>;
device_type = "network";
compatible = "gianfar";
reg = <0x24000 0x1000>;
model = "eTSEC";
local-mac-address = [ 00 00 00 00 00 00 ];
interrupts = <32 0x8 33 0x8 34 0x8>;
interrupt-parent = <&ipic>;
fixed-link = <3 1 100 1 0>;
linux,network-index = <0>;
};
enet1: ether...@25000 {
#address-cells = <1>;
#size-cells = <1>;
cell-index = <1>;
device_type = "network";
model = "eTSEC";
compatible = "gianfar";
reg = <0x25000 0x1000>;
local-mac-address = [ 00 a0 3e a8 a6 6E ];
interrupts = <35 0x8 36 0x8 37 0x8>;
interrupt-parent = <&ipic>;
phy-handle = < &phy1 >;
};
The problem is I'm not being able to set *ETH1* up. When i try, say "*ifconfig
eth1 up*" i got:
*vmunix: Trying to connect phy m...@e0024520:01
vmunix: eth1: Could not attach to PHY*
I've tried to track this error down and found that the it raises from *
bus_find_device_by_name* function at *bus.c*. For some reason ETH1 is never
added do *devices_kset* for MDIO bus. It only contains an entry for ETH0,
which is 00:3.
What could be wrong? In a hardware point of view, this PHY seems to be OK,
since I've made some tests from U-boot command line trying some MDIO
commands. I've also checked MDIO pins with oscilloscope and everything seems
to be fine. But during Linux initialization I could not see any activity in
MDIO pins. Is that normal? Is there any other files I should change (other
than DTS) to make PHYs work?
Thanks
--
Juliano Maia
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
linux support for freescale e5500 core?
Hi, We're looking at maybe doing some work with an e5500-based system. Is there any support existing/planned for this core? Also, do we know what the cache line size is--we have some legacy apps that assume 32-byte. Thanks, Chris -- Chris Friesen Software Developer GENBAND chris.frie...@genband.com www.genband.com ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] spi_mpc8xxx: fix buffer overrun when sending only/receiving only more than PAGE_SIZE bytes
On Thu, Sep 16, 2010 at 09:05:25AM +0200, christophe leroy wrote: > This patch applies to 2.6.34.7 and 2.6.35.4 > It fixes an issue when sending only or receiving only more than PAGE_SIZE > bytes > > Signed-off-by: christophe leroy applied to merge-spi branch, thanks. g. > > diff -urN c/drivers/spi/spi_mpc8xxx.c d/drivers/spi/spi_mpc8xxx.c > --- c/drivers/spi/spi_mpc8xxx.c 2010-09-08 16:44:03.0 +0200 > +++ d/drivers/spi/spi_mpc8xxx.c 2010-09-08 16:44:14.0 +0200 > @@ -393,11 +393,17 @@ > > xfer_ofs = mspi->xfer_in_progress->len - mspi->count; > > - out_be32(&rx_bd->cbd_bufaddr, mspi->rx_dma + xfer_ofs); > + if (mspi->rx_dma == mspi->dma_dummy_rx) > + out_be32(&rx_bd->cbd_bufaddr, mspi->rx_dma); > + else > + out_be32(&rx_bd->cbd_bufaddr, mspi->rx_dma + xfer_ofs); > out_be16(&rx_bd->cbd_datlen, 0); > out_be16(&rx_bd->cbd_sc, BD_SC_EMPTY | BD_SC_INTRPT | BD_SC_WRAP); > > - out_be32(&tx_bd->cbd_bufaddr, mspi->tx_dma + xfer_ofs); > + if (mspi->tx_dma == mspi->dma_dummy_tx) > + out_be32(&tx_bd->cbd_bufaddr, mspi->tx_dma); > + else > + out_be32(&tx_bd->cbd_bufaddr, mspi->tx_dma + xfer_ofs); > out_be16(&tx_bd->cbd_datlen, xfer_len); > out_be16(&tx_bd->cbd_sc, BD_SC_READY | BD_SC_INTRPT | BD_SC_WRAP | >BD_SC_LAST); ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Help with finding memory read performance problem
For our code we needed a fast memory compare of 5 buffers. I've implemented said routine in asm and it works fine and is very fast in the test bench. However when integrated with the app it is much less performant and we are trying to figure out why. The app in question gets the 5 4MB buffers in the kernel via kmalloc and then uses them for DMA. No other methods are being called for the memory besides kmalloc. This is an embedded system on the 460EX, so there is no drive, only RAM. Within the user code mmap is called on these buffers physical address and they are given to the compare routine. The result is slow. If I allocate buffers in user space then the performance is excellent. Next I implemented my compare routine within a kernel module so that it was using the kernel virtual addresses for each of the buffers. I did not see any change between this and the mmap approach. For comparison sake, using the kernel memory is about 19s whereas user memory is about 11s for the same size / configuration of buffer. In the test bench the algorithm is about 8s. The processor is not doing any other intensive tasks during these tests and the times are repeatable. Is something happening to mmap'd memory that causes the access to it to be slow? Is there a way to speed that up? Why are the kernel memory access slower than user memory? What is the best overall approach? Is it to DMA into user memory and then run the routines there? Is kmalloc not the best approach for kernel DMA memory? This is on linux 2.6.31.5 on 460EX thanks ayman ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] spi_mpc8xxx: fix writing to adress 0
On Thu, Sep 16, 2010 at 09:39:09AM +0200, Joakim Tjernlund wrote: > > From: christophe leroy > > To: David Brownell , Grant Likely > > , spi-devel-gene...@lists.sourceforge.net, linux- > > ker...@vger.kernel.org, linuxppc-dev@lists.ozlabs.org > > Date: 2010/09/16 09:06 > > Subject: [PATCH] spi_mpc8xxx: fix writing to adress 0 > > Sent by: linuxppc-dev-bounces+joakim.tjernlund=transmode...@lists.ozlabs.org > > > > This patch applies to 2.6.34.7 (already included in 2.6.35.4) > > It fixes an issue when sending only or receiving only (mspi->tx-dma was > > reset > > as when no tx_buf is defined, tx_dma is 0) > > > > Signed-off-by: christophe leroy > > Acked-by: Joakim Tjernlund > You need to send this to the linux-stable list and include the sha1 commit id that fixes it in mainline. Acked-by: Grant Likely g. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: 2.6.35-stable/ppc64/p7: suspicious rcu_dereference_check() usage detected during 2.6.35-stable boot
On Thu, 2010-09-16 at 09:12 -0700, Paul E. McKenney wrote:
> On Thu, Sep 16, 2010 at 05:50:31PM +0200, Peter Zijlstra wrote:
> > On Mon, 2010-08-09 at 09:12 -0700, Paul E. McKenney wrote:
> >
> > > > [0.051203] CPU0: AMD QEMU Virtual CPU version 0.12.4 stepping 03
> > > > [0.052999] lockdep: fixing up alternatives.
> > > > [0.054105]
> > > > [0.054106] ===
> > > > [0.054999] [ INFO: suspicious rcu_dereference_check() usage. ]
> > > > [0.054999] ---
> > > > [0.054999] kernel/sched.c:616 invoked rcu_dereference_check()
> > > > without protection!
> > > > [0.054999]
> > > > [0.054999] other info that might help us debug this:
> > > > [0.054999]
> > > > [0.054999]
> > > > [0.054999] rcu_scheduler_active = 1, debug_locks = 1
> > > > [0.054999] 3 locks held by swapper/1:
> > > > [0.054999] #0: (cpu_add_remove_lock){+.+.+.}, at:
> > > > [] cpu_up+0x42/0x6a
> > > > [0.054999] #1: (cpu_hotplug.lock){+.+.+.}, at:
> > > > [] cpu_hotplug_begin+0x2a/0x51
> > > > [0.054999] #2: (&rq->lock){-.-...}, at: []
> > > > init_idle+0x2f/0x113
> > > > [0.054999]
> > > > [0.054999] stack backtrace:
> > > > [0.054999] Pid: 1, comm: swapper Not tainted 2.6.35 #1
> > > > [0.054999] Call Trace:
> > > > [0.054999] [] lockdep_rcu_dereference+0x9b/0xa3
> > > > [0.054999] [] task_group+0x7b/0x8a
> > > > [0.054999] [] set_task_rq+0x13/0x40
> > > > [0.054999] [] init_idle+0xd2/0x113
> > > > [0.054999] [] fork_idle+0xb8/0xc7
> > > > [0.054999] [] ? mark_held_locks+0x4d/0x6b
> > > > [0.054999] [] do_fork_idle+0x17/0x2b
> > > > [0.054999] [] native_cpu_up+0x1c1/0x724
> > > > [0.054999] [] ? do_fork_idle+0x0/0x2b
> > > > [0.054999] [] _cpu_up+0xac/0x127
> > > > [0.054999] [] cpu_up+0x55/0x6a
> > > > [0.054999] [] kernel_init+0xe1/0x1ff
> > > > [0.054999] [] kernel_thread_helper+0x4/0x10
> > > > [0.054999] [] ? restore_args+0x0/0x30
> > > > [0.054999] [] ? kernel_init+0x0/0x1ff
> > > > [0.054999] [] ? kernel_thread_helper+0x0/0x10
> > > > [0.056074] Booting Node 0, Processors #1lockdep: fixing up
> > > > alternatives.
> > > > [0.130045] #2lockdep: fixing up alternatives.
> > > > [0.203089] #3 Ok.
> > > > [0.275286] Brought up 4 CPUs
> > > > [0.276005] Total of 4 processors activated (16017.17 BogoMIPS).
> > >
> > > This does look like a new one, thank you for reporting it!
> > >
> > > Here is my analysis, which should at least provide some humor value to
> > > those who understand the code better than I do. ;-)
> > >
> > > So the corresponding rcu_dereference_check() is in
> > > task_subsys_state_check(), and is fetching the cpu_cgroup_subsys_id
> > > element of the newly created task's task->cgroups->subsys[] array.
> > > The "git grep" command finds only three uses of cpu_cgroup_subsys_id,
> > > but no definition.
> > >
> > > Now, fork_idle() invokes copy_process(), which invokes cgroup_fork(),
> > > which sets the child process's ->cgroups pointer to that of the parent,
> > > also invoking get_css_set(), which increments the corresponding reference
> > > count, doing both operations under task_lock() protection (->alloc_lock).
> > > Because fork_idle() does not specify any of CLONE_NEWNS, CLONE_NEWUTS,
> > > CLONE_NEWIPC, CLONE_NEWPID, or CLONE_NEWNET, copy_namespaces() should
> > > not create a new namespace, and so there should be no ns_cgroup_clone().
> > > We should thus retain the parent's ->cgroups pointer. And copy_process()
> > > installs the new task in the various lists, so that the task is externally
> > > accessible upon return.
> > >
> > > After a non-error return from copy_process(), fork_init() invokes
> > > init_idle_pid(), which does not appear to affect the task's cgroup
> > > state. Next fork_init() invokes init_idle(), which in turn invokes
> > > __set_task_cpu(), which invokes set_task_rq(), which calls task_group()
> > > several times, which calls task_subsys_state_check(), which calls the
> > > rcu_dereference_check() that complained above.
> > >
> > > However, the result returns by rcu_dereference_check() is stored into
> > > the task structure:
> > >
> > > p->se.cfs_rq = task_group(p)->cfs_rq[cpu];
> > > p->se.parent = task_group(p)->se[cpu];
> > >
> > > This means that the corresponding structure must have been tied down with
> > > a reference count or some such. If such a reference has been taken, then
> > > this complaint is a false positive, and could be suppressed by putting
> > > rcu_read_lock() and rcu_read_unlock() around the call to init_idle()
> > > from fork_idle(). However, although, reference to the enclosing ->cgroups
> > > struct css_set is held, it is not clear to me that this reference applies
> > > to the structures pointed to by the ->subsys[] array, especially given
> > > that the cgroup_subsys
Re: Generating elf kernel ?
On Thu, 16 Sep 2010 10:37:32 +0800 "tiejun.chen" wrote: > 1> can you load the Linux vmlinux directly to the physical address '0' on > current bootloader? That depends on what bootloader we're talking about -- I don't know what the original poster's custom loader can do. Obviously the bootloader itself would have to be executing from some other address (e.g. U-Boot runs from the top of RAM). > 2> additionally you have to find a way to pass dtb to the native vmlinux. Yes, of course. But that's a different issue. :-) > I believe the hypervisor can boot vmlinux directly. But your so-called vmlinux > should be guest OS. And the hypervisor will handle/assit TLB exception for the > guest OS on MMU. Right? So you can use the hypervisor to load vmlinux to any > physical address as you expect. I was just using our hypervisor as an example, since it has an ELF loader that can pass a device tree. > But the guest OS should not be same as the native Linux. The guest OS *is* the same as native Linux, as far as TLB handling is concerned. -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 2/3 v3] P4080/mtd: Only make elbc nand driver detect nand flash partitions
On Thu, 16 Sep 2010 20:40:44 +0400 Anton Vorontsov wrote: > On Thu, Sep 16, 2010 at 11:14:48AM -0500, Scott Wood wrote: > > > > DEFINE_MUTEX(fsl_elbc_mutex); > > > > > > I'd place the mutex inside the fsl_lbc_ctrl_dev, > > > i.e. fsl_lbc_ctrl_dev->nand_lock. This is to avoid more > > > global variables. > > > > I wouldn't. If the lock is only meaningful to the NAND driver, it > > should be declared in the NAND driver. > > > > Besides, it's not any less of a global just because it's sitting inside > > a singleton struct. > > > > Perhaps it should be declared as a static local inside the probe > > function, if it's just to guard against this one race. > > OK, in that case better be persistent and not introduce > fsl_lbc_ctrl_dev->nand at all, as it isn't used outside > of the driver. We could, though it would be a step further away from being able to support multiple controllers if that ever does happen. Whereas sharing a mutex between multiple controllers isn't a problem (it's just init, not a performance-sensitive path where fine-grained locking is desireable). > Having fsl_lbc_ctrl_dev->nand and its lock elsewhere in > the code makes no sense. That depends on whether you see it as that field's lock or as the init code's lock, I guess. It's not that big of a deal either way. -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 2/3 v3] P4080/mtd: Only make elbc nand driver detect nand flash partitions
On Thu, Sep 16, 2010 at 11:14:48AM -0500, Scott Wood wrote: > > > DEFINE_MUTEX(fsl_elbc_mutex); > > > > I'd place the mutex inside the fsl_lbc_ctrl_dev, > > i.e. fsl_lbc_ctrl_dev->nand_lock. This is to avoid more > > global variables. > > I wouldn't. If the lock is only meaningful to the NAND driver, it > should be declared in the NAND driver. > > Besides, it's not any less of a global just because it's sitting inside > a singleton struct. > > Perhaps it should be declared as a static local inside the probe > function, if it's just to guard against this one race. OK, in that case better be persistent and not introduce fsl_lbc_ctrl_dev->nand at all, as it isn't used outside of the driver. Having fsl_lbc_ctrl_dev->nand and its lock elsewhere in the code makes no sense. > > Btw, even before this patch, it seems that the driver had > > all these bugs/races, i.e. ctrl->controller.lock was not > > used at all. Ugh. > > It is used, search nand_base.c for controller->lock. OK, now I see, the driver implements its own chip->controller (which is exactly what ctrl->controller is). Then we're fine. Thanks, -- Anton Vorontsov email: cbouatmai...@gmail.com irc://irc.freenode.net/bd2 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 2/3 v3] P4080/mtd: Only make elbc nand driver detect nand flash partitions
On Thu, 16 Sep 2010 15:26:24 +0400 Anton Vorontsov wrote: > On Thu, Sep 16, 2010 at 06:39:40PM +0800, Zang Roy-R61911 wrote: > [...] > > But my code has some assignment for "foo" instead of a simple > > allocation, how about this way for my code: > > This will surely work, and all the rest is just a matter of > taste. So, I'm fine with it. But see below, I think I found > some new, quite serious issues. > > > DEFINE_MUTEX(fsl_elbc_mutex); > > I'd place the mutex inside the fsl_lbc_ctrl_dev, > i.e. fsl_lbc_ctrl_dev->nand_lock. This is to avoid more > global variables. I wouldn't. If the lock is only meaningful to the NAND driver, it should be declared in the NAND driver. Besides, it's not any less of a global just because it's sitting inside a singleton struct. Perhaps it should be declared as a static local inside the probe function, if it's just to guard against this one race. > > elbc_fcm_ctrl->read_bytes = 0; > > elbc_fcm_ctrl->index = 0; > > elbc_fcm_ctrl->addr = NULL; > > I guess these variables should be per chip select, as > otherwise there will be tons of races when somebody try > to access two or more NAND chips simultaneously. The NAND layer has its own per-controller mutex that prevents this. > So, I'd suggest to redo the whole thing this way: don't allocate > elbc_fcm_ctrl in this driver, but make an array inside the > fsl_lbc_ctrl_dev. I.e. > fsl_lbc_ctrl_dev->nand_ctrl[MAX_CHIP_SELECTS] NACK. There is not a separate controller per chip select. > Btw, even before this patch, it seems that the driver had > all these bugs/races, i.e. ctrl->controller.lock was not > used at all. Ugh. It is used, search nand_base.c for controller->lock. -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: 2.6.35-stable/ppc64/p7: suspicious rcu_dereference_check() usage detected during 2.6.35-stable boot
On Thu, Sep 16, 2010 at 05:50:31PM +0200, Peter Zijlstra wrote:
> On Mon, 2010-08-09 at 09:12 -0700, Paul E. McKenney wrote:
>
> > > [0.051203] CPU0: AMD QEMU Virtual CPU version 0.12.4 stepping 03
> > > [0.052999] lockdep: fixing up alternatives.
> > > [0.054105]
> > > [0.054106] ===
> > > [0.054999] [ INFO: suspicious rcu_dereference_check() usage. ]
> > > [0.054999] ---
> > > [0.054999] kernel/sched.c:616 invoked rcu_dereference_check() without
> > > protection!
> > > [0.054999]
> > > [0.054999] other info that might help us debug this:
> > > [0.054999]
> > > [0.054999]
> > > [0.054999] rcu_scheduler_active = 1, debug_locks = 1
> > > [0.054999] 3 locks held by swapper/1:
> > > [0.054999] #0: (cpu_add_remove_lock){+.+.+.}, at:
> > > [] cpu_up+0x42/0x6a
> > > [0.054999] #1: (cpu_hotplug.lock){+.+.+.}, at: []
> > > cpu_hotplug_begin+0x2a/0x51
> > > [0.054999] #2: (&rq->lock){-.-...}, at: []
> > > init_idle+0x2f/0x113
> > > [0.054999]
> > > [0.054999] stack backtrace:
> > > [0.054999] Pid: 1, comm: swapper Not tainted 2.6.35 #1
> > > [0.054999] Call Trace:
> > > [0.054999] [] lockdep_rcu_dereference+0x9b/0xa3
> > > [0.054999] [] task_group+0x7b/0x8a
> > > [0.054999] [] set_task_rq+0x13/0x40
> > > [0.054999] [] init_idle+0xd2/0x113
> > > [0.054999] [] fork_idle+0xb8/0xc7
> > > [0.054999] [] ? mark_held_locks+0x4d/0x6b
> > > [0.054999] [] do_fork_idle+0x17/0x2b
> > > [0.054999] [] native_cpu_up+0x1c1/0x724
> > > [0.054999] [] ? do_fork_idle+0x0/0x2b
> > > [0.054999] [] _cpu_up+0xac/0x127
> > > [0.054999] [] cpu_up+0x55/0x6a
> > > [0.054999] [] kernel_init+0xe1/0x1ff
> > > [0.054999] [] kernel_thread_helper+0x4/0x10
> > > [0.054999] [] ? restore_args+0x0/0x30
> > > [0.054999] [] ? kernel_init+0x0/0x1ff
> > > [0.054999] [] ? kernel_thread_helper+0x0/0x10
> > > [0.056074] Booting Node 0, Processors #1lockdep: fixing up
> > > alternatives.
> > > [0.130045] #2lockdep: fixing up alternatives.
> > > [0.203089] #3 Ok.
> > > [0.275286] Brought up 4 CPUs
> > > [0.276005] Total of 4 processors activated (16017.17 BogoMIPS).
> >
> > This does look like a new one, thank you for reporting it!
> >
> > Here is my analysis, which should at least provide some humor value to
> > those who understand the code better than I do. ;-)
> >
> > So the corresponding rcu_dereference_check() is in
> > task_subsys_state_check(), and is fetching the cpu_cgroup_subsys_id
> > element of the newly created task's task->cgroups->subsys[] array.
> > The "git grep" command finds only three uses of cpu_cgroup_subsys_id,
> > but no definition.
> >
> > Now, fork_idle() invokes copy_process(), which invokes cgroup_fork(),
> > which sets the child process's ->cgroups pointer to that of the parent,
> > also invoking get_css_set(), which increments the corresponding reference
> > count, doing both operations under task_lock() protection (->alloc_lock).
> > Because fork_idle() does not specify any of CLONE_NEWNS, CLONE_NEWUTS,
> > CLONE_NEWIPC, CLONE_NEWPID, or CLONE_NEWNET, copy_namespaces() should
> > not create a new namespace, and so there should be no ns_cgroup_clone().
> > We should thus retain the parent's ->cgroups pointer. And copy_process()
> > installs the new task in the various lists, so that the task is externally
> > accessible upon return.
> >
> > After a non-error return from copy_process(), fork_init() invokes
> > init_idle_pid(), which does not appear to affect the task's cgroup
> > state. Next fork_init() invokes init_idle(), which in turn invokes
> > __set_task_cpu(), which invokes set_task_rq(), which calls task_group()
> > several times, which calls task_subsys_state_check(), which calls the
> > rcu_dereference_check() that complained above.
> >
> > However, the result returns by rcu_dereference_check() is stored into
> > the task structure:
> >
> > p->se.cfs_rq = task_group(p)->cfs_rq[cpu];
> > p->se.parent = task_group(p)->se[cpu];
> >
> > This means that the corresponding structure must have been tied down with
> > a reference count or some such. If such a reference has been taken, then
> > this complaint is a false positive, and could be suppressed by putting
> > rcu_read_lock() and rcu_read_unlock() around the call to init_idle()
> > from fork_idle(). However, although, reference to the enclosing ->cgroups
> > struct css_set is held, it is not clear to me that this reference applies
> > to the structures pointed to by the ->subsys[] array, especially given
> > that the cgroup_subsys_state structures referenced by this array have
> > their own reference count, which does not appear to me to be acquired
> > by this code path.
> >
> > Or are the cgroup_subsys_state structures referenced by idle tasks
> > never freed or s
Re: 2.6.35-stable/ppc64/p7: suspicious rcu_dereference_check() usage detected during 2.6.35-stable boot
On Mon, 2010-08-09 at 09:12 -0700, Paul E. McKenney wrote:
> > [0.051203] CPU0: AMD QEMU Virtual CPU version 0.12.4 stepping 03
> > [0.052999] lockdep: fixing up alternatives.
> > [0.054105]
> > [0.054106] ===
> > [0.054999] [ INFO: suspicious rcu_dereference_check() usage. ]
> > [0.054999] ---
> > [0.054999] kernel/sched.c:616 invoked rcu_dereference_check() without
> > protection!
> > [0.054999]
> > [0.054999] other info that might help us debug this:
> > [0.054999]
> > [0.054999]
> > [0.054999] rcu_scheduler_active = 1, debug_locks = 1
> > [0.054999] 3 locks held by swapper/1:
> > [0.054999] #0: (cpu_add_remove_lock){+.+.+.}, at:
> > [] cpu_up+0x42/0x6a
> > [0.054999] #1: (cpu_hotplug.lock){+.+.+.}, at: []
> > cpu_hotplug_begin+0x2a/0x51
> > [0.054999] #2: (&rq->lock){-.-...}, at: []
> > init_idle+0x2f/0x113
> > [0.054999]
> > [0.054999] stack backtrace:
> > [0.054999] Pid: 1, comm: swapper Not tainted 2.6.35 #1
> > [0.054999] Call Trace:
> > [0.054999] [] lockdep_rcu_dereference+0x9b/0xa3
> > [0.054999] [] task_group+0x7b/0x8a
> > [0.054999] [] set_task_rq+0x13/0x40
> > [0.054999] [] init_idle+0xd2/0x113
> > [0.054999] [] fork_idle+0xb8/0xc7
> > [0.054999] [] ? mark_held_locks+0x4d/0x6b
> > [0.054999] [] do_fork_idle+0x17/0x2b
> > [0.054999] [] native_cpu_up+0x1c1/0x724
> > [0.054999] [] ? do_fork_idle+0x0/0x2b
> > [0.054999] [] _cpu_up+0xac/0x127
> > [0.054999] [] cpu_up+0x55/0x6a
> > [0.054999] [] kernel_init+0xe1/0x1ff
> > [0.054999] [] kernel_thread_helper+0x4/0x10
> > [0.054999] [] ? restore_args+0x0/0x30
> > [0.054999] [] ? kernel_init+0x0/0x1ff
> > [0.054999] [] ? kernel_thread_helper+0x0/0x10
> > [0.056074] Booting Node 0, Processors #1lockdep: fixing up
> > alternatives.
> > [0.130045] #2lockdep: fixing up alternatives.
> > [0.203089] #3 Ok.
> > [0.275286] Brought up 4 CPUs
> > [0.276005] Total of 4 processors activated (16017.17 BogoMIPS).
>
> This does look like a new one, thank you for reporting it!
>
> Here is my analysis, which should at least provide some humor value to
> those who understand the code better than I do. ;-)
>
> So the corresponding rcu_dereference_check() is in
> task_subsys_state_check(), and is fetching the cpu_cgroup_subsys_id
> element of the newly created task's task->cgroups->subsys[] array.
> The "git grep" command finds only three uses of cpu_cgroup_subsys_id,
> but no definition.
>
> Now, fork_idle() invokes copy_process(), which invokes cgroup_fork(),
> which sets the child process's ->cgroups pointer to that of the parent,
> also invoking get_css_set(), which increments the corresponding reference
> count, doing both operations under task_lock() protection (->alloc_lock).
> Because fork_idle() does not specify any of CLONE_NEWNS, CLONE_NEWUTS,
> CLONE_NEWIPC, CLONE_NEWPID, or CLONE_NEWNET, copy_namespaces() should
> not create a new namespace, and so there should be no ns_cgroup_clone().
> We should thus retain the parent's ->cgroups pointer. And copy_process()
> installs the new task in the various lists, so that the task is externally
> accessible upon return.
>
> After a non-error return from copy_process(), fork_init() invokes
> init_idle_pid(), which does not appear to affect the task's cgroup
> state. Next fork_init() invokes init_idle(), which in turn invokes
> __set_task_cpu(), which invokes set_task_rq(), which calls task_group()
> several times, which calls task_subsys_state_check(), which calls the
> rcu_dereference_check() that complained above.
>
> However, the result returns by rcu_dereference_check() is stored into
> the task structure:
>
> p->se.cfs_rq = task_group(p)->cfs_rq[cpu];
> p->se.parent = task_group(p)->se[cpu];
>
> This means that the corresponding structure must have been tied down with
> a reference count or some such. If such a reference has been taken, then
> this complaint is a false positive, and could be suppressed by putting
> rcu_read_lock() and rcu_read_unlock() around the call to init_idle()
> from fork_idle(). However, although, reference to the enclosing ->cgroups
> struct css_set is held, it is not clear to me that this reference applies
> to the structures pointed to by the ->subsys[] array, especially given
> that the cgroup_subsys_state structures referenced by this array have
> their own reference count, which does not appear to me to be acquired
> by this code path.
>
> Or are the cgroup_subsys_state structures referenced by idle tasks
> never freed or some such?
I would hope so!, the idle tasks should be part of the root cgroup,
which is not removable.
The problem is that while we do in-fact hold rq->lock, the newly spawned
idle thread's cpu is not yet set to the correct cpu so the lockdep check
in t
Re: 2.6.35-stable/ppc64/p7: suspicious rcu_dereference_check() usage detected during 2.6.35-stable boot
On Thu, 2010-09-16 at 11:12 -0400, valdis.kletni...@vt.edu wrote: > > Ping? I just hit it on 2.6.36-rc4-mmotm0915. Just wanted to make sure the > issue hadn't been lost/forgotten. lost,.. thanks! ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: 2.6.35-stable/ppc64/p7: suspicious rcu_dereference_check() usage detected during 2.6.35-stable boot
On Mon, 09 Aug 2010 09:12:00 PDT, "Paul E. McKenney" said: > On Mon, Aug 02, 2010 at 02:22:12PM +0530, Subrata Modak wrote: > > Hi, > > > > The following suspicious rcu_dereference_check() usage is detected > > during 2.6.35-stable boot on my ppc64/p7 machine: > > > > = > > [ INFO: suspicious rcu_dereference_check() usage. ] > > --- > > kernel/sched.c:616 invoked rcu_dereference_check() without protection! > > other info that might help us debug this: > Thank you for locating this one! This looks like the same issue that > Ilia Mirkin located. Please see below for my analysis -- no fix yet, > as I need confirmation from cgroups experts. I can easily create a > patch that suppresses the warning, but I don't yet know whether this is > the right thing to do. Ping? I just hit it on 2.6.36-rc4-mmotm0915. Just wanted to make sure the issue hadn't been lost/forgotten. pgpV57f3JfD8P.pgp Description: PGP signature ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Reserved pages in PowerPC
Hi Ben, On Thu, Sep 16, 2010 at 08:04:24PM +1000, Benjamin Herrenschmidt wrote: > On Thu, 2010-09-16 at 10:53 +0530, Ankita Garg wrote: > > > > With some debugging I found that that section has reserved pages. On > > instrumenting the memblock_reserve() and reserve_bootmem() routines, I can > > see > > that many of the memory areas are reserved for kernel and initrd by the > > memblock reserve() itself. reserve_bootmem then looks at the pages already > > reserved and marks them reserved. However, for the very last section, I see > > that bootmem reserves it but I am unable to find a corresponding reservation > > by the memblock code. > > It's probably RTAS (firmware runtime services). I'ts instanciated at > boot from prom_init and we do favor high addresses for it below 1G iirc. > Thanks Ben for taking a look at this. So I checked the rtas messages on the serial console and see the following: instantiating rtas at 0x0f632000... done Which does not correspond to the higher addresses that I see as reserved (observation on a 16G machine). -- Regards, Ankita Garg (ank...@in.ibm.com) Linux Technology Center IBM India Systems & Technology Labs, Bangalore, India ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 2/3 v3] P4080/mtd: Only make elbc nand driver detect nand flash partitions
On Thu, Sep 16, 2010 at 06:39:40PM +0800, Zang Roy-R61911 wrote:
[...]
> But my code has some assignment for "foo" instead of a simple
> allocation, how about this way for my code:
This will surely work, and all the rest is just a matter of
taste. So, I'm fine with it. But see below, I think I found
some new, quite serious issues.
> DEFINE_MUTEX(fsl_elbc_mutex);
I'd place the mutex inside the fsl_lbc_ctrl_dev,
i.e. fsl_lbc_ctrl_dev->nand_lock. This is to avoid more
global variables.
> ...
> static int __devinit fsl_elbc_nand_probe(struct platform_device *dev)
> {
> ...
> mutex_lock(&fsl_lbc_mutex);
> if (!fsl_lbc_ctrl_dev->nand) {
> elbc_fcm_ctrl = kzalloc(sizeof(*elbc_fcm_ctrl), GFP_KERNEL);
> if (!elbc_fcm_ctrl) {
> dev_err(fsl_lbc_ctrl_dev->dev, "failed to allocate "
> "memory\n");
> ret = -ENOMEM;
> goto err;
> }
>
> elbc_fcm_ctrl->read_bytes = 0;
> elbc_fcm_ctrl->index = 0;
> elbc_fcm_ctrl->addr = NULL;
I guess these variables should be per chip select, as
otherwise there will be tons of races when somebody try
to access two or more NAND chips simultaneously.
(Plus, you don't need these = 0 and = NULL as you used
kzalloc() for allocation.)
>
> spin_lock_init(&elbc_fcm_ctrl->controller.lock);
> init_waitqueue_head(&elbc_fcm_ctrl->controller.wq);
Some of these may need to be per chip select too.
So, I'd suggest to redo the whole thing this way: don't allocate
elbc_fcm_ctrl in this driver, but make an array inside the
fsl_lbc_ctrl_dev. I.e.
fsl_lbc_ctrl_dev->nand_ctrl[MAX_CHIP_SELECTS]
or something like that.
Btw, even before this patch, it seems that the driver had
all these bugs/races, i.e. ctrl->controller.lock was not
used at all. Ugh.
> fsl_lbc_ctrl_dev->nand = elbc_fcm_ctrl;
> } else
> elbc_fcm_ctrl = fsl_lbc_ctrl_dev->nand;
Per coding style this should be
} else {
elbc_fcm_ctrl = fsl_lbc_ctrl_dev->nand;
}
> mutex_unlock(&fsl_lbc_mutex);
>
> elbc_fcm_ctrl->chips[bank] = priv;
> ...
> }
Thanks,
--
Anton Vorontsov
email: cbouatmai...@gmail.com
irc://irc.freenode.net/bd2
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 11/15] ppc/cell: beat dma ops cleanup
On Wednesday 15 September 2010, Nishanth Aravamudan wrote: > direct_dma_ops is the default pci dma ops. > > No need to call a function to get the pci dma ops, we know they are the > dma_direct_ops. > > Signed-off-by: Milton Miller > Signed-off-by: Nishanth Aravamudan Acked-by: Arnd Bergmann ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH 2/3 v3] P4080/mtd: Only make elbc nand driver detect nand flash partitions
> -Original Message-
> From: Anton Vorontsov [mailto:cbouatmai...@gmail.com]
> Sent: Thursday, September 16, 2010 18:14 PM
> To: Zang Roy-R61911
> Cc: Wood Scott-B07421; dedeki...@gmail.com; Lan Chunhe-B25806; linuxppc-
> d...@ozlabs.org; linux-...@lists.infradead.org; a...@linux-foundation.org;
> dw...@infradead.org; Gala Kumar-B11780
> Subject: Re: [PATCH 2/3 v3] P4080/mtd: Only make elbc nand driver detect nand
> flash partitions
>
> On Thu, Sep 16, 2010 at 06:08:14PM +0800, Zang Roy-R61911 wrote:
> [...]
> > Interesting.
> > How about this?
> > #include
> > #include
> >
> > char *foo;
> >
> > void probe(void)
> > {
> > char *bar = NULL;
> >
> > if (!foo) {
> > bar = malloc(sizeof(*bar));
> > if (!bar)
> > return;
> > foo = bar;
> > } else
> >bar = foo;
>
> This willl work of course; but I'd write it as
>
> foo_lock();
> if (!foo)
> foo = alloc();
> foo_unlock();
>
> bar = foo;
> bar->baz;
But my code has some assignment for "foo" instead of a simple
allocation, how about this way for my code:
DEFINE_MUTEX(fsl_elbc_mutex);
...
static int __devinit fsl_elbc_nand_probe(struct platform_device *dev)
{
...
mutex_lock(&fsl_lbc_mutex);
if (!fsl_lbc_ctrl_dev->nand) {
elbc_fcm_ctrl = kzalloc(sizeof(*elbc_fcm_ctrl), GFP_KERNEL);
if (!elbc_fcm_ctrl) {
dev_err(fsl_lbc_ctrl_dev->dev, "failed to allocate "
"memory\n");
ret = -ENOMEM;
goto err;
}
elbc_fcm_ctrl->read_bytes = 0;
elbc_fcm_ctrl->index = 0;
elbc_fcm_ctrl->addr = NULL;
spin_lock_init(&elbc_fcm_ctrl->controller.lock);
init_waitqueue_head(&elbc_fcm_ctrl->controller.wq);
fsl_lbc_ctrl_dev->nand = elbc_fcm_ctrl;
} else
elbc_fcm_ctrl = fsl_lbc_ctrl_dev->nand;
mutex_unlock(&fsl_lbc_mutex);
elbc_fcm_ctrl->chips[bank] = priv;
...
}
Any comment?
Thanks.
Roy
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 2/3 v3] P4080/mtd: Only make elbc nand driver detect nand flash partitions
On Thu, Sep 16, 2010 at 06:08:14PM +0800, Zang Roy-R61911 wrote:
[...]
> Interesting.
> How about this?
> #include
> #include
>
> char *foo;
>
> void probe(void)
> {
> char *bar = NULL;
>
> if (!foo) {
> bar = malloc(sizeof(*bar));
> if (!bar)
> return;
> foo = bar;
> } else
> bar = foo;
This willl work of course; but I'd write it as
foo_lock();
if (!foo)
foo = alloc();
foo_unlock();
bar = foo;
bar->baz;
--
Anton Vorontsov
email: cbouatmai...@gmail.com
irc://irc.freenode.net/bd2
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH 2/3 v3] P4080/mtd: Only make elbc nand driver detect nand flash partitions
> -Original Message-
> From: Anton Vorontsov [mailto:cbouatmai...@gmail.com]
> Sent: Thursday, September 16, 2010 17:26 PM
> To: Zang Roy-R61911
> Cc: linux-...@lists.infradead.org; dw...@infradead.org; dedeki...@gmail.com;
> a...@linux-foundation.org; Lan Chunhe-B25806; Wood Scott-B07421; Gala Kumar-
> B11780; linuxppc-...@ozlabs.org
> Subject: Re: [PATCH 2/3 v3] P4080/mtd: Only make elbc nand driver detect nand
> flash partitions
>
> On Thu, Sep 16, 2010 at 04:50:05PM +0800, Zang Roy-R61911 wrote:
> > > On Thu, Sep 16, 2010 at 02:41:23PM +0800, Roy Zang wrote:
> > > [...]
> > > > -static int __devinit fsl_elbc_chip_probe(struct fsl_elbc_ctrl *ctrl,
> > > > - struct device_node *node)
> > > > +/*
> > > > + * Currently only one elbc probe is supported.
> > > > + */
> > > > +static int __devinit fsl_elbc_nand_probe(struct platform_device *dev)
> > > > {
> > > > - struct fsl_lbc_regs __iomem *lbc = ctrl->regs;
> > > > + struct fsl_lbc_regs __iomem *lbc;
> > > > struct fsl_elbc_mtd *priv;
> > > > struct resource res;
> > > > + struct fsl_elbc_fcm_ctrl *elbc_fcm_ctrl = NULL;
> > > [...]
> > > > - ctrl->chips[bank] = priv;
> > > > + if (fsl_lbc_ctrl_dev->nand == NULL) {
> > > > + elbc_fcm_ctrl = kzalloc(sizeof(*elbc_fcm_ctrl),
> GFP_KERNEL);
> > > > + if (!elbc_fcm_ctrl) {
> > > [...]
> > > > + goto err;
> > > > + }
> > > > + fsl_lbc_ctrl_dev->nand = elbc_fcm_ctrl;
> > > > + }
> > > > +
> > > > + elbc_fcm_ctrl->chips[bank] = priv;
> > >
> > > Again, this will oops on the second probe.
> > Why?
>
> Because of a NULL dereference ("elbc_fcm_ctrl->").
>
> I understand that you don't have to believe me, but will you believe
> a compiler?
>
> oksana:~$ cat a.c
> #include
> #include
>
> char *foo;
>
> void probe(void)
> {
> char *bar = NULL;
>
> if (!foo) {
> bar = malloc(sizeof(*bar));
> if (!bar)
> return;
> foo = bar;
> }
> *bar = 'a';
> }
>
> int main(void)
> {
> probe();
> probe();
> return 0;
> }
> oksana:~$ gcc a.c && ./a.out
> Segmentation fault
Interesting.
How about this?
#include
#include
char *foo;
void probe(void)
{
char *bar = NULL;
if (!foo) {
bar = malloc(sizeof(*bar));
if (!bar)
return;
foo = bar;
} else
bar = foo;
*bar = 'a';
}
int main(void)
{
probe();
probe();
return 0;
}
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Reserved pages in PowerPC
On Thu, 2010-09-16 at 10:53 +0530, Ankita Garg wrote: > > With some debugging I found that that section has reserved pages. On > instrumenting the memblock_reserve() and reserve_bootmem() routines, I can see > that many of the memory areas are reserved for kernel and initrd by the > memblock reserve() itself. reserve_bootmem then looks at the pages already > reserved and marks them reserved. However, for the very last section, I see > that bootmem reserves it but I am unable to find a corresponding reservation > by the memblock code. It's probably RTAS (firmware runtime services). I'ts instanciated at boot from prom_init and we do favor high addresses for it below 1G iirc. Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 2/3 v3] P4080/mtd: Only make elbc nand driver detect nand flash partitions
On Thu, Sep 16, 2010 at 04:50:05PM +0800, Zang Roy-R61911 wrote:
> > On Thu, Sep 16, 2010 at 02:41:23PM +0800, Roy Zang wrote:
> > [...]
> > > -static int __devinit fsl_elbc_chip_probe(struct fsl_elbc_ctrl *ctrl,
> > > - struct device_node *node)
> > > +/*
> > > + * Currently only one elbc probe is supported.
> > > + */
> > > +static int __devinit fsl_elbc_nand_probe(struct platform_device *dev)
> > > {
> > > - struct fsl_lbc_regs __iomem *lbc = ctrl->regs;
> > > + struct fsl_lbc_regs __iomem *lbc;
> > > struct fsl_elbc_mtd *priv;
> > > struct resource res;
> > > + struct fsl_elbc_fcm_ctrl *elbc_fcm_ctrl = NULL;
> > [...]
> > > - ctrl->chips[bank] = priv;
> > > + if (fsl_lbc_ctrl_dev->nand == NULL) {
> > > + elbc_fcm_ctrl = kzalloc(sizeof(*elbc_fcm_ctrl), GFP_KERNEL);
> > > + if (!elbc_fcm_ctrl) {
> > [...]
> > > + goto err;
> > > + }
> > > + fsl_lbc_ctrl_dev->nand = elbc_fcm_ctrl;
> > > + }
> > > +
> > > + elbc_fcm_ctrl->chips[bank] = priv;
> >
> > Again, this will oops on the second probe.
> Why?
Because of a NULL dereference ("elbc_fcm_ctrl->").
I understand that you don't have to believe me, but will you believe
a compiler?
oksana:~$ cat a.c
#include
#include
char *foo;
void probe(void)
{
char *bar = NULL;
if (!foo) {
bar = malloc(sizeof(*bar));
if (!bar)
return;
foo = bar;
}
*bar = 'a';
}
int main(void)
{
probe();
probe();
return 0;
}
oksana:~$ gcc a.c && ./a.out
Segmentation fault
--
Anton Vorontsov
email: cbouatmai...@gmail.com
irc://irc.freenode.net/bd2
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH 2/3 v3] P4080/mtd: Only make elbc nand driver detect nand flash partitions
> -Original Message-
> From: Anton Vorontsov [mailto:cbouatmai...@gmail.com]
> Sent: Thursday, September 16, 2010 16:22 PM
> To: Zang Roy-R61911
> Cc: linux-...@lists.infradead.org; dw...@infradead.org; dedeki...@gmail.com;
> a...@linux-foundation.org; Lan Chunhe-B25806; Wood Scott-B07421; Gala Kumar-
> B11780; linuxppc-...@ozlabs.org
> Subject: Re: [PATCH 2/3 v3] P4080/mtd: Only make elbc nand driver detect nand
> flash partitions
>
> On Thu, Sep 16, 2010 at 02:41:23PM +0800, Roy Zang wrote:
> [...]
> > -static int __devinit fsl_elbc_chip_probe(struct fsl_elbc_ctrl *ctrl,
> > - struct device_node *node)
> > +/*
> > + * Currently only one elbc probe is supported.
> > + */
> > +static int __devinit fsl_elbc_nand_probe(struct platform_device *dev)
> > {
> > - struct fsl_lbc_regs __iomem *lbc = ctrl->regs;
> > + struct fsl_lbc_regs __iomem *lbc;
> > struct fsl_elbc_mtd *priv;
> > struct resource res;
> > + struct fsl_elbc_fcm_ctrl *elbc_fcm_ctrl = NULL;
> [...]
> > - ctrl->chips[bank] = priv;
> > + if (fsl_lbc_ctrl_dev->nand == NULL) {
> > + elbc_fcm_ctrl = kzalloc(sizeof(*elbc_fcm_ctrl), GFP_KERNEL);
> > + if (!elbc_fcm_ctrl) {
> [...]
> > + goto err;
> > + }
> > + fsl_lbc_ctrl_dev->nand = elbc_fcm_ctrl;
> > + }
> > +
> > + elbc_fcm_ctrl->chips[bank] = priv;
>
> Again, this will oops on the second probe.
Why?
> And you still don't
> lock fsl_lbc_ctrl_dev->nand during check-then-assignment, so
> with parallel probing there will be a race. :-(
>
> We do have boards with several NAND chips (e.g.
> arch/powerpc/boot/dts/mpc8610_hpcd.dts), so these issues
> are all legitimate.
OK. I can add a mutex here.
Thanks.
Roy
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 2/3 v3] P4080/mtd: Only make elbc nand driver detect nand flash partitions
On Thu, Sep 16, 2010 at 02:41:23PM +0800, Roy Zang wrote:
[...]
> -static int __devinit fsl_elbc_chip_probe(struct fsl_elbc_ctrl *ctrl,
> - struct device_node *node)
> +/*
> + * Currently only one elbc probe is supported.
> + */
> +static int __devinit fsl_elbc_nand_probe(struct platform_device *dev)
> {
> - struct fsl_lbc_regs __iomem *lbc = ctrl->regs;
> + struct fsl_lbc_regs __iomem *lbc;
> struct fsl_elbc_mtd *priv;
> struct resource res;
> + struct fsl_elbc_fcm_ctrl *elbc_fcm_ctrl = NULL;
[...]
> - ctrl->chips[bank] = priv;
> + if (fsl_lbc_ctrl_dev->nand == NULL) {
> + elbc_fcm_ctrl = kzalloc(sizeof(*elbc_fcm_ctrl), GFP_KERNEL);
> + if (!elbc_fcm_ctrl) {
[...]
> + goto err;
> + }
> + fsl_lbc_ctrl_dev->nand = elbc_fcm_ctrl;
> + }
> +
> + elbc_fcm_ctrl->chips[bank] = priv;
Again, this will oops on the second probe. And you still don't
lock fsl_lbc_ctrl_dev->nand during check-then-assignment, so
with parallel probing there will be a race. :-(
We do have boards with several NAND chips (e.g.
arch/powerpc/boot/dts/mpc8610_hpcd.dts), so these issues
are all legitimate.
Thanks,
--
Anton Vorontsov
email: cbouatmai...@gmail.com
irc://irc.freenode.net/bd2
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Generating elf kernel ?
Guillaume Dargaud wrote: Please use simpleImage..elf. >>> Great, that seems to be it... >>> Except that nothing happens when I jump to 0x4, no message from the >> 0x4? I recalled the entry point should be 0x40 for >> simepleImage.*.elf. So you have to change this on the file, >> arch/powerpc/boot/wrapper. > > Correct, I skipped a zero, the address is indeed 0x40 > >> And also you should confirm if the upstream kernel support your board. > > Our board is a custom derivative from a ML405. Understood. So I recommend you use the kernel tree from xilinx. You can refer to the following website: http://xilinx.wikidot.com/powerpc-linux I hope you can skip many issues to accelerate your progress based on the xilinx kernel. > My previous project uses ARCH=PPC and has been working fine for 2 years. > I'm currently trying to go to ARCH=PowerPC and understand dts files in order > to > boot my first kernel. > I assume I shouldn't have to change anything in my bootloader. > After I jump to the kernel address, I don't even get the usual: > loaded at: 0040 004F559C > board data at: 004F3520 004F359C > relocated to: 0040505C 004050D8 > zimage at: 00405E48 004F211C > avail ram: 004F6000 0800 > Linux/PPC load: console=ttyUL0,115200 rw root=/dev/nfs ip=bootp > Uncompressing Linux...done. > Now booting the kernel > > Something wrong with my serial console ? You have to check if you go the correct PC address. Note please check the real pc address according to the previous comments. If yes you can check where your kernel stop. Certainly if you have some tools, such as JTAG debug tools it's convenient to track this. But if no it will be difficult to go no next. But you still have ways to do, such as display LED, early printk, and dump __log_buf. > >> Additionally let's assume your bootloader create the map between the >> virtual address and the physical address as 1:1. If so you want to execute >> from 0x4. But the actual PC address should be the loader address + >> offset. You can get this by readelf. Here if your loader address is zero, >> the offset will be pc address, not 0x4. You can dump your memory to >> check this. > > The bootloader has no concept of virtual address, right ? This should be depend on the given PPC core. For example, we cannot disable MMU on e500. Bur for ML405 we can disable MMU to run real mode on 405. Cheers Tiejun > ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: cuImage and multi image?
> Try the following steps: > -- > 1. cp arch/powerpc/boot/ramdisk.image.gz > 2. make cuImage.initrd. > > You can get one Image, cuImage.initrd., including kernel and > ramdisk. Cool! Thanks a lot, Tiejun. -Shawn. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] spi_mpc8xxx: fix writing to adress 0
> From: christophe leroy > To: David Brownell , Grant Likely > , spi-devel-gene...@lists.sourceforge.net, linux- > ker...@vger.kernel.org, linuxppc-dev@lists.ozlabs.org > Date: 2010/09/16 09:06 > Subject: [PATCH] spi_mpc8xxx: fix writing to adress 0 > Sent by: linuxppc-dev-bounces+joakim.tjernlund=transmode...@lists.ozlabs.org > > This patch applies to 2.6.34.7 (already included in 2.6.35.4) > It fixes an issue when sending only or receiving only (mspi->tx-dma was reset > as when no tx_buf is defined, tx_dma is 0) > > Signed-off-by: christophe leroy Acked-by: Joakim Tjernlund ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] spi_mpc8xxx: fix buffer overrun when sending only/receiving only more than PAGE_SIZE bytes
> From: christophe leroy > To: David Brownell , Grant Likely > , spi-devel-gene...@lists.sourceforge.net, linux- > ker...@vger.kernel.org, linuxppc-dev@lists.ozlabs.org > Date: 2010/09/16 09:07 > Subject: [PATCH] spi_mpc8xxx: fix buffer overrun when sending only/receiving > only more than PAGE_SIZE bytes > Sent by: linuxppc-dev-bounces+joakim.tjernlund=transmode...@lists.ozlabs.org > > This patch applies to 2.6.34.7 and 2.6.35.4 > It fixes an issue when sending only or receiving only more than PAGE_SIZE > bytes > > Signed-off-by: christophe leroy Acked-by: Joakim Tjernlund ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH 3/3 v3] P4080/mtd: Fix the freescale lbc issue with 36bit mode
> -Original Message-
> From: Anton Vorontsov [mailto:cbouatmai...@gmail.com]
> Sent: Thursday, September 16, 2010 15:32 PM
> To: Zang Roy-R61911
> Cc: linux-...@lists.infradead.org; dw...@infradead.org; dedeki...@gmail.com;
> a...@linux-foundation.org; Lan Chunhe-B25806; Wood Scott-B07421; Gala Kumar-
> B11780; linuxppc-...@ozlabs.org
> Subject: Re: [PATCH 3/3 v3] P4080/mtd: Fix the freescale lbc issue with 36bit
> mode
>
> On Thu, Sep 16, 2010 at 02:41:24PM +0800, Roy Zang wrote:
> > From: Lan Chunhe-B25806
> >
> > When system uses 36bit physical address, res.start is 36bit
> > physical address. But the function of in_be32 returns 32bit
> > physical address. Then both of them compared each other is
> > wrong. So by converting the address of res.start into
> > the right format fixes this issue.
> >
> > Signed-off-by: Lan Chunhe-B25806
> > Signed-off-by: Roy Zang
> > ---
> > arch/powerpc/include/asm/fsl_lbc.h |1 +
> > arch/powerpc/sysdev/fsl_lbc.c | 23 ++-
> > drivers/mtd/nand/fsl_elbc_nand.c |2 +-
> > 3 files changed, 24 insertions(+), 2 deletions(-)
> >
> > diff --git a/arch/powerpc/include/asm/fsl_lbc.h
> b/arch/powerpc/include/asm/fsl_lbc.h
> > index db94698..5638b1e 100644
> > --- a/arch/powerpc/include/asm/fsl_lbc.h
> > +++ b/arch/powerpc/include/asm/fsl_lbc.h
> > @@ -246,6 +246,7 @@ struct fsl_upm {
> > int width;
> > };
> >
> > +extern unsigned int fsl_lbc_addr(phys_addr_t addr_base);
>
> u32 here.
>
> Other than that, the patch looks good.
>
> Reviewed-by: Anton Vorontsov
I will correct this together with previous patches.
Do you have any more comments for the previous two patches?
Thanks.
Roy
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 3/3 v3] P4080/mtd: Fix the freescale lbc issue with 36bit mode
On Thu, Sep 16, 2010 at 02:41:24PM +0800, Roy Zang wrote:
> From: Lan Chunhe-B25806
>
> When system uses 36bit physical address, res.start is 36bit
> physical address. But the function of in_be32 returns 32bit
> physical address. Then both of them compared each other is
> wrong. So by converting the address of res.start into
> the right format fixes this issue.
>
> Signed-off-by: Lan Chunhe-B25806
> Signed-off-by: Roy Zang
> ---
> arch/powerpc/include/asm/fsl_lbc.h |1 +
> arch/powerpc/sysdev/fsl_lbc.c | 23 ++-
> drivers/mtd/nand/fsl_elbc_nand.c |2 +-
> 3 files changed, 24 insertions(+), 2 deletions(-)
>
> diff --git a/arch/powerpc/include/asm/fsl_lbc.h
> b/arch/powerpc/include/asm/fsl_lbc.h
> index db94698..5638b1e 100644
> --- a/arch/powerpc/include/asm/fsl_lbc.h
> +++ b/arch/powerpc/include/asm/fsl_lbc.h
> @@ -246,6 +246,7 @@ struct fsl_upm {
> int width;
> };
>
> +extern unsigned int fsl_lbc_addr(phys_addr_t addr_base);
u32 here.
Other than that, the patch looks good.
Reviewed-by: Anton Vorontsov
Thanks!
--
Anton Vorontsov
email: cbouatmai...@gmail.com
irc://irc.freenode.net/bd2
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: cuImage and multi image?
Shawn Jin wrote: > Hi, > > I have a cuImage kernel in order to support legacy u-boot and a > ramdisk image. Kernel boots fine if these two images are separate and > "bootm $kernel $ramdisk" is used. But I can not make it to work using > a single multi image that contains the kernel and ramdisk images. Is > it even technically possible to boot a multi-image with cuboot > wrapper? Try the following steps: -- 1. cp arch/powerpc/boot/ramdisk.image.gz 2. make cuImage.initrd. You can get one Image, cuImage.initrd., including kernel and ramdisk. Cheers Tiejun > > On the cuImage kernel I have load address set to 0x40 and the > entry address set to 0x400554 due to the cuboot wrapper. But to make a > multi image, both the load and the entry addresses should be set to > zero. And u-boot (1.1.2) bootm takes the entry address of the multi > image (i.e. 0x0) as the kernel entry address. 0x0 is certainly not the > entry address for a cuImage kernel. > > Is there a possible workaround other than using two separate images? > > Thanks, > -Shawn. > ___ > Linuxppc-dev mailing list > Linuxppc-dev@lists.ozlabs.org > https://lists.ozlabs.org/listinfo/linuxppc-dev > ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/3 v3] P4080/eLBC: Make Freescale elbc interrupt common to elbc devices
On Thu, Sep 16, 2010 at 02:41:22PM +0800, Roy Zang wrote:
[...]
> +static const struct platform_device_id fsl_lbc_match[] = {
> + { "fsl,elbc", },
> + { "fsl,pq3-localbus", },
> + { "fsl,pq2-localbus", },
> + { "fsl,pq2pro-localbus", },
> + {},
> +};
> +
> +static struct platform_driver fsl_lbc_ctrl_driver = {
> + .driver = {
> + .name = "fsl-lbc",
> + },
> + .probe = fsl_lbc_ctrl_probe,
> + .id_table = fsl_lbc_match,
> +};
No, it won't work that way (at least not w/o a device constructor
somewhere in fsl_soc.c). Instead, you should write something like
static const struct of_device_id fsl_lbc_match[] = {
...
};
static struct platform_driver fsl_lbc_ctrl_driver = {
.driver = {
.name = "fsl-lbc",
.of_match_table = fsl_lbc_match;
}
...
};
(Note that platform_driver.driver has of_match_table nowadays --
that's what makes it possible to seamlessly transit from
of_platform_driver to platform_driver.)
The same applies for the second patch as well.
Thanks,
--
Anton Vorontsov
email: cbouatmai...@gmail.com
irc://irc.freenode.net/bd2
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Generating elf kernel ?
> >> Please use simpleImage..elf. > > > > Great, that seems to be it... > > Except that nothing happens when I jump to 0x4, no message from the > > 0x4? I recalled the entry point should be 0x40 for > simepleImage.*.elf. So you have to change this on the file, > arch/powerpc/boot/wrapper. Correct, I skipped a zero, the address is indeed 0x40 > And also you should confirm if the upstream kernel support your board. Our board is a custom derivative from a ML405. My previous project uses ARCH=PPC and has been working fine for 2 years. I'm currently trying to go to ARCH=PowerPC and understand dts files in order to boot my first kernel. I assume I shouldn't have to change anything in my bootloader. After I jump to the kernel address, I don't even get the usual: loaded at: 0040 004F559C board data at: 004F3520 004F359C relocated to: 0040505C 004050D8 zimage at: 00405E48 004F211C avail ram: 004F6000 0800 Linux/PPC load: console=ttyUL0,115200 rw root=/dev/nfs ip=bootp Uncompressing Linux...done. Now booting the kernel Something wrong with my serial console ? > Additionally let's assume your bootloader create the map between the > virtual address and the physical address as 1:1. If so you want to execute > from 0x4. But the actual PC address should be the loader address + > offset. You can get this by readelf. Here if your loader address is zero, > the offset will be pc address, not 0x4. You can dump your memory to > check this. The bootloader has no concept of virtual address, right ? -- Guillaume Dargaud http://www.gdargaud.net/ ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] spi_mpc8xxx: fix buffer overrun when sending only/receiving only more than PAGE_SIZE bytes
This patch applies to 2.6.34.7 and 2.6.35.4 It fixes an issue when sending only or receiving only more than PAGE_SIZE bytes Signed-off-by: christophe leroy diff -urN c/drivers/spi/spi_mpc8xxx.c d/drivers/spi/spi_mpc8xxx.c --- c/drivers/spi/spi_mpc8xxx.c 2010-09-08 16:44:03.0 +0200 +++ d/drivers/spi/spi_mpc8xxx.c 2010-09-08 16:44:14.0 +0200 @@ -393,11 +393,17 @@ xfer_ofs = mspi->xfer_in_progress->len - mspi->count; - out_be32(&rx_bd->cbd_bufaddr, mspi->rx_dma + xfer_ofs); + if (mspi->rx_dma == mspi->dma_dummy_rx) + out_be32(&rx_bd->cbd_bufaddr, mspi->rx_dma); + else + out_be32(&rx_bd->cbd_bufaddr, mspi->rx_dma + xfer_ofs); out_be16(&rx_bd->cbd_datlen, 0); out_be16(&rx_bd->cbd_sc, BD_SC_EMPTY | BD_SC_INTRPT | BD_SC_WRAP); - out_be32(&tx_bd->cbd_bufaddr, mspi->tx_dma + xfer_ofs); + if (mspi->tx_dma == mspi->dma_dummy_tx) + out_be32(&tx_bd->cbd_bufaddr, mspi->tx_dma); + else + out_be32(&tx_bd->cbd_bufaddr, mspi->tx_dma + xfer_ofs); out_be16(&tx_bd->cbd_datlen, xfer_len); out_be16(&tx_bd->cbd_sc, BD_SC_READY | BD_SC_INTRPT | BD_SC_WRAP | BD_SC_LAST); ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] spi_mpc8xxx: issue with using definition of pram in Device Tree
This patch applies to 2.6.34.7 and 2.6.35.4 It fixes an issue during the probe for CPM1 with definition of parameter ram from DTS Signed-off-by: christophe leroy diff -urN b/drivers/spi/spi_mpc8xxx.c c/drivers/spi/spi_mpc8xxx.c --- b/drivers/spi/spi_mpc8xxx.c 2010-09-08 16:43:50.0 +0200 +++ c/drivers/spi/spi_mpc8xxx.c 2010-09-08 16:44:03.0 +0200 @@ -822,7 +822,7 @@ if (!iprop || size != sizeof(*iprop) * 4) return -ENOMEM; - spi_base_ofs = cpm_muram_alloc_fixed(iprop[2], 2); + spi_base_ofs = iprop[2]; if (IS_ERR_VALUE(spi_base_ofs)) return -ENOMEM; @@ -844,7 +844,6 @@ return spi_base_ofs; } - cpm_muram_free(spi_base_ofs); return pram_ofs; } ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] spi_mpc8xxx: fix writing to adress 0
This patch applies to 2.6.34.7 (already included in 2.6.35.4)
It fixes an issue when sending only or receiving only (mspi->tx-dma was reset
as when no tx_buf is defined, tx_dma is 0)
Signed-off-by: christophe leroy
diff -urN a/drivers/spi/spi_mpc8xxx.c b/drivers/spi/spi_mpc8xxx.c
--- a/drivers/spi/spi_mpc8xxx.c 2010-09-08 16:42:30.0 +0200
+++ b/drivers/spi/spi_mpc8xxx.c 2010-09-08 16:43:50.0 +0200
@@ -438,7 +438,7 @@
dev_err(dev, "unable to map tx dma\n");
return -ENOMEM;
}
- } else {
+ } else if (t->tx_buf) {
mspi->tx_dma = t->tx_dma;
}
@@ -449,7 +449,7 @@
dev_err(dev, "unable to map rx dma\n");
goto err_rx_dma;
}
- } else {
+ } else if (t->rx_buf) {
mspi->rx_dma = t->rx_dma;
}
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 3/3 v3] P4080/mtd: Fix the freescale lbc issue with 36bit mode
From: Lan Chunhe-B25806
When system uses 36bit physical address, res.start is 36bit
physical address. But the function of in_be32 returns 32bit
physical address. Then both of them compared each other is
wrong. So by converting the address of res.start into
the right format fixes this issue.
Signed-off-by: Lan Chunhe-B25806
Signed-off-by: Roy Zang
---
arch/powerpc/include/asm/fsl_lbc.h |1 +
arch/powerpc/sysdev/fsl_lbc.c | 23 ++-
drivers/mtd/nand/fsl_elbc_nand.c |2 +-
3 files changed, 24 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/include/asm/fsl_lbc.h
b/arch/powerpc/include/asm/fsl_lbc.h
index db94698..5638b1e 100644
--- a/arch/powerpc/include/asm/fsl_lbc.h
+++ b/arch/powerpc/include/asm/fsl_lbc.h
@@ -246,6 +246,7 @@ struct fsl_upm {
int width;
};
+extern unsigned int fsl_lbc_addr(phys_addr_t addr_base);
extern int fsl_lbc_find(phys_addr_t addr_base);
extern int fsl_upm_find(phys_addr_t addr_base, struct fsl_upm *upm);
diff --git a/arch/powerpc/sysdev/fsl_lbc.c b/arch/powerpc/sysdev/fsl_lbc.c
index edd6d95..8a835ef 100644
--- a/arch/powerpc/sysdev/fsl_lbc.c
+++ b/arch/powerpc/sysdev/fsl_lbc.c
@@ -34,6 +34,27 @@ struct fsl_lbc_ctrl *fsl_lbc_ctrl_dev;
EXPORT_SYMBOL(fsl_lbc_ctrl_dev);
/**
+ * fsl_lbc_addr - convert the base address
+ * @addr_base: base address of the memory bank
+ *
+ * This function converts a base address of lbc into the right format for the
+ * BR register. If the SOC has eLBC then it returns 32bit physical address
+ * else it convers a 34bit local bus physical address to correct format of
+ * 32bit address for BR register (Example: MPC8641).
+ */
+u32 fsl_lbc_addr(phys_addr_t addr_base)
+{
+ struct device_node *np = fsl_lbc_ctrl_dev->dev->of_node;
+ u32 addr = addr_base & 0x8000;
+
+ if (of_device_is_compatible(np, "fsl,elbc"))
+ return addr;
+
+ return addr | ((addr_base & 0x3ull) >> 19);
+}
+EXPORT_SYMBOL(fsl_lbc_addr);
+
+/**
* fsl_lbc_find - find Localbus bank
* @addr_base: base address of the memory bank
*
@@ -55,7 +76,7 @@ int fsl_lbc_find(phys_addr_t addr_base)
__be32 br = in_be32(&lbc->bank[i].br);
__be32 or = in_be32(&lbc->bank[i].or);
- if (br & BR_V && (br & or & BR_BA) == addr_base)
+ if (br & BR_V && (br & or & BR_BA) == fsl_lbc_addr(addr_base))
return i;
}
diff --git a/drivers/mtd/nand/fsl_elbc_nand.c b/drivers/mtd/nand/fsl_elbc_nand.c
index 91c5c05..85858e3 100644
--- a/drivers/mtd/nand/fsl_elbc_nand.c
+++ b/drivers/mtd/nand/fsl_elbc_nand.c
@@ -865,7 +865,7 @@ static int __devinit fsl_elbc_nand_probe(struct
platform_device *dev)
(in_be32(&lbc->bank[bank].br) & BR_MSEL) == BR_MS_FCM &&
(in_be32(&lbc->bank[bank].br) &
in_be32(&lbc->bank[bank].or) & BR_BA)
-== res.start)
+== fsl_lbc_addr(res.start))
break;
if (bank >= MAX_BANKS) {
--
1.5.6.5
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 1/3 v3] P4080/eLBC: Make Freescale elbc interrupt common to elbc devices
From: Lan Chunhe-B25806
Move Freescale elbc interrupt from nand dirver to elbc driver.
Then all elbc devices can use the interrupt instead of ONLY nand.
Signed-off-by: Lan Chunhe-B25806
Signed-off-by: Roy Zang
---
Comparing with v2:
1. according to the feedback, add some decorations.
2. change of_platform_driver to platform_driver
3. rebase to 2.6.36-rc4
arch/powerpc/Kconfig |7 +-
arch/powerpc/include/asm/fsl_lbc.h | 31 +-
arch/powerpc/sysdev/fsl_lbc.c | 246 ++--
3 files changed, 242 insertions(+), 42 deletions(-)
diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index 631e5a0..44df1ba 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -687,9 +687,12 @@ config 4xx_SOC
bool
config FSL_LBC
- bool
+ bool "Freescale Local Bus support"
+ depends on FSL_SOC
help
- Freescale Localbus support
+ Enables reporting of errors from the Freescale local bus
+ controller. Also contains some common code used by
+ drivers for specific local bus peripherals.
config FSL_GTM
bool
diff --git a/arch/powerpc/include/asm/fsl_lbc.h
b/arch/powerpc/include/asm/fsl_lbc.h
index 1b5a210..db94698 100644
--- a/arch/powerpc/include/asm/fsl_lbc.h
+++ b/arch/powerpc/include/asm/fsl_lbc.h
@@ -1,9 +1,10 @@
/* Freescale Local Bus Controller
*
- * Copyright (c) 2006-2007 Freescale Semiconductor
+ * Copyright (c) 2006-2007, 2010 Freescale Semiconductor
*
* Authors: Nick Spence ,
* Scott Wood
+ * Jack Lan
*
* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License as published by
@@ -125,13 +126,23 @@ struct fsl_lbc_regs {
#define LTESR_ATMW 0x0080
#define LTESR_ATMR 0x0040
#define LTESR_CS 0x0008
+#define LTESR_UPM 0x0002
#define LTESR_CC 0x0001
#define LTESR_NAND_MASK (LTESR_FCT | LTESR_PAR | LTESR_CC)
+#define LTESR_MASK (LTESR_BM | LTESR_FCT | LTESR_PAR | LTESR_WP \
+| LTESR_ATMW | LTESR_ATMR | LTESR_CS | LTESR_UPM \
+| LTESR_CC)
+#define LTESR_CLEAR0x
+#define LTECCR_CLEAR 0x
+#define LTESR_STATUS LTESR_MASK
+#define LTEIR_ENABLE LTESR_MASK
+#define LTEDR_ENABLE 0x
__be32 ltedr; /**< Transfer Error Disable Register */
__be32 lteir; /**< Transfer Error Interrupt Register */
__be32 lteatr; /**< Transfer Error Attributes Register */
__be32 ltear; /**< Transfer Error Address Register */
- u8 res6[0xC];
+ __be32 lteccr; /**< Transfer Error ECC Register */
+ u8 res6[0x8];
__be32 lbcr;/**< Configuration Register */
#define LBCR_LDIS 0x8000
#define LBCR_LDIS_SHIFT31
@@ -265,7 +276,23 @@ static inline void fsl_upm_end_pattern(struct fsl_upm *upm)
cpu_relax();
}
+/* overview of the fsl lbc controller */
+
+struct fsl_lbc_ctrl {
+ /* device info */
+ struct device *dev;
+ struct fsl_lbc_regs __iomem *regs;
+ int irq;
+ wait_queue_head_t irq_wait;
+ spinlock_t lock;
+ void*nand;
+
+ /* status read from LTESR by irq handler */
+ unsigned intirq_status;
+};
+
extern int fsl_upm_run_pattern(struct fsl_upm *upm, void __iomem *io_base,
u32 mar);
+extern struct fsl_lbc_ctrl *fsl_lbc_ctrl_dev;
#endif /* __ASM_FSL_LBC_H */
diff --git a/arch/powerpc/sysdev/fsl_lbc.c b/arch/powerpc/sysdev/fsl_lbc.c
index dceb8d1..edd6d95 100644
--- a/arch/powerpc/sysdev/fsl_lbc.c
+++ b/arch/powerpc/sysdev/fsl_lbc.c
@@ -2,8 +2,11 @@
* Freescale LBC and UPM routines.
*
* Copyright (c) 2007-2008 MontaVista Software, Inc.
+ * Copyright (c) 2010 Freescale Semiconductor
*
* Author: Anton Vorontsov
+ * Author: Jack Lan
+ * Author: Roy Zang
*
* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License as published by
@@ -21,37 +24,14 @@
#include
#include
#include
+#include
+#include
+#include
+#include
static spinlock_t fsl_lbc_lock = __SPIN_LOCK_UNLOCKED(fsl_lbc_lock);
-static struct fsl_lbc_regs __iomem *fsl_lbc_regs;
-
-static char __initdata *compat_lbc[] = {
- "fsl,pq2-localbus",
- "fsl,pq2pro-localbus",
- "fsl,pq3-localbus",
- "fsl,elbc",
-};
-
-static int __init fsl_lbc_init(void)
-{
- struct device_node *lbus;
- int i;
-
- for (i = 0; i < ARRAY_SIZE(compat_lbc); i++) {
- lbus = of_find_compatible_node(NULL, NULL, compat_lbc[i]);
- if (lbus)
- goto found;
- }
- return -ENODEV;
-
-found:
- fsl_lbc_regs = of_iom
[PATCH 2/3 v3] P4080/mtd: Only make elbc nand driver detect nand flash partitions
From: Jack Lan
The former driver had the two functions:
1. detecting nand flash partitions;
2. registering elbc interrupt.
Now, second function is removed to fsl_lbc.c.
Signed-off-by: Lan Chunhe-B25806
Signed-off-by: Roy Zang
---
drivers/mtd/nand/Kconfig |1 +
drivers/mtd/nand/fsl_elbc_nand.c | 474 +++---
2 files changed, 190 insertions(+), 285 deletions(-)
diff --git a/drivers/mtd/nand/Kconfig b/drivers/mtd/nand/Kconfig
index 8b4b67c..4132c46 100644
--- a/drivers/mtd/nand/Kconfig
+++ b/drivers/mtd/nand/Kconfig
@@ -458,6 +458,7 @@ config MTD_NAND_ORION
config MTD_NAND_FSL_ELBC
tristate "NAND support for Freescale eLBC controllers"
depends on PPC_OF
+ select FSL_LBC
help
Various Freescale chips, including the 8313, include a NAND Flash
Controller Module with built-in hardware ECC capabilities.
diff --git a/drivers/mtd/nand/fsl_elbc_nand.c b/drivers/mtd/nand/fsl_elbc_nand.c
index 80de0bf..91c5c05 100644
--- a/drivers/mtd/nand/fsl_elbc_nand.c
+++ b/drivers/mtd/nand/fsl_elbc_nand.c
@@ -1,9 +1,10 @@
/* Freescale Enhanced Local Bus Controller NAND driver
*
- * Copyright (c) 2006-2007 Freescale Semiconductor
+ * Copyright (c) 2006-2007, 2010 Freescale Semiconductor
*
* Authors: Nick Spence ,
* Scott Wood
+ * Jack Lan
*
* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License as published by
@@ -27,6 +28,7 @@
#include
#include
#include
+#include
#include
#include
@@ -42,14 +44,12 @@
#define ERR_BYTE 0xFF /* Value returned for read bytes when read failed */
#define FCM_TIMEOUT_MSECS 500 /* Maximum number of mSecs to wait for FCM */
-struct fsl_elbc_ctrl;
-
/* mtd information per set */
struct fsl_elbc_mtd {
struct mtd_info mtd;
struct nand_chip chip;
- struct fsl_elbc_ctrl *ctrl;
+ struct fsl_lbc_ctrl *ctrl;
struct device *dev;
int bank; /* Chip select bank number */
@@ -58,18 +58,12 @@ struct fsl_elbc_mtd {
unsigned int fmr; /* FCM Flash Mode Register value */
};
-/* overview of the fsl elbc controller */
+/* Freescale eLBC FCM controller infomation */
-struct fsl_elbc_ctrl {
+struct fsl_elbc_fcm_ctrl {
struct nand_hw_control controller;
struct fsl_elbc_mtd *chips[MAX_BANKS];
- /* device info */
- struct device *dev;
- struct fsl_lbc_regs __iomem *regs;
- int irq;
- wait_queue_head_t irq_wait;
- unsigned int irq_status; /* status read from LTESR by irq handler */
u8 __iomem *addr;/* Address of assigned FCM buffer*/
unsigned int page; /* Last page written to / read from */
unsigned int read_bytes; /* Number of bytes read during command */
@@ -164,11 +158,12 @@ static void set_addr(struct mtd_info *mtd, int column,
int page_addr, int oob)
{
struct nand_chip *chip = mtd->priv;
struct fsl_elbc_mtd *priv = chip->priv;
- struct fsl_elbc_ctrl *ctrl = priv->ctrl;
+ struct fsl_lbc_ctrl *ctrl = priv->ctrl;
struct fsl_lbc_regs __iomem *lbc = ctrl->regs;
+ struct fsl_elbc_fcm_ctrl *elbc_fcm_ctrl = ctrl->nand;
int buf_num;
- ctrl->page = page_addr;
+ elbc_fcm_ctrl->page = page_addr;
out_be32(&lbc->fbar,
page_addr >> (chip->phys_erase_shift - chip->page_shift));
@@ -185,16 +180,18 @@ static void set_addr(struct mtd_info *mtd, int column,
int page_addr, int oob)
buf_num = page_addr & 7;
}
- ctrl->addr = priv->vbase + buf_num * 1024;
- ctrl->index = column;
+ elbc_fcm_ctrl->addr = priv->vbase + buf_num * 1024;
+ elbc_fcm_ctrl->index = column;
/* for OOB data point to the second half of the buffer */
if (oob)
- ctrl->index += priv->page_size ? 2048 : 512;
+ elbc_fcm_ctrl->index += priv->page_size ? 2048 : 512;
- dev_vdbg(ctrl->dev, "set_addr: bank=%d, ctrl->addr=0x%p (0x%p), "
+ dev_vdbg(priv->dev, "set_addr: bank=%d, "
+ "elbc_fcm_ctrl->addr=0x%p (0x%p), "
"index %x, pes %d ps %d\n",
-buf_num, ctrl->addr, priv->vbase, ctrl->index,
+buf_num, elbc_fcm_ctrl->addr, priv->vbase,
+elbc_fcm_ctrl->index,
chip->phys_erase_shift, chip->page_shift);
}
@@ -205,18 +202,19 @@ static int fsl_elbc_run_command(struct mtd_info *mtd)
{
struct nand_chip *chip = mtd->priv;
struct fsl_elbc_mtd *priv = chip->priv;
- struct fsl_elbc_ctrl *ctrl = priv->ctrl;
+ struct fsl_lbc_ctrl *ctrl = priv->ctrl;
+ struct fsl_elbc_fcm_ctrl *elbc_fcm_ctrl = ctrl->nand;
struct fsl_lbc_regs __iomem *lbc = ctrl->regs;
/* Setup the FMR[OP] to execute without write protection */
