* [PATCH 00/10] powerpc: Remove use of CONFIG_PPC_MERGE
From: Kumar Gala @ 2008-08-01 16:44 UTC (permalink / raw)
To: linuxppc-dev; +Cc: linux-kernel
This set of patches remove Kconfig and code related to CONFIG_PPC_MERGE
and !CONFIG_PPC_MERGE. There is some discussion about that one last
use of !PPC_MERGE with respect to the 4xx MTD_NAND_NDFC driver.
Paul, is this something you'd be willing to entertain for 2.6.27?
- k
^ permalink raw reply
* Re: [PATCH] powerpc: Remove use of CONFIG_PPC_MERGE
From: Kumar Gala @ 2008-08-01 16:35 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-dev
In-Reply-To: <fa686aa40808010930s286381c7ub354b9b98a40c07d@mail.gmail.com>
On Aug 1, 2008, at 11:30 AM, Grant Likely wrote:
> On Fri, Aug 1, 2008 at 9:50 AM, Kumar Gala
> <galak@kernel.crashing.org> wrote:
>> Now that arch/ppc is gone we don't need CONFIG_PPC_MERGE anymore
>> remove the dead code associated with !CONFIG_PPC_MERGE out of arch/
>> powerpc
>> and include/asm-powerpc.
>>
>> Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
>
> You need to remove references to it from drivers also
Old your horses (or should I say kilt).. patches are coming :)
- k
^ permalink raw reply
* Re: [PATCH] powerpc: Remove use of CONFIG_PPC_MERGE
From: Grant Likely @ 2008-08-01 16:30 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev
In-Reply-To: <Pine.LNX.4.64.0808011050370.2074@blarg.am.freescale.net>
On Fri, Aug 1, 2008 at 9:50 AM, Kumar Gala <galak@kernel.crashing.org> wrote:
> Now that arch/ppc is gone we don't need CONFIG_PPC_MERGE anymore
> remove the dead code associated with !CONFIG_PPC_MERGE out of arch/powerpc
> and include/asm-powerpc.
>
> Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
You need to remove references to it from drivers also
drivers/ata/pata_sil680.c
233:#ifdef CONFIG_PPC_MERGE
drivers/block/floppy.c
4168:#if defined(CONFIG_PPC_MERGE)
drivers/char/ipmi/ipmi_si_intf.c
2703:#ifdef CONFIG_PPC_MERGE
drivers/i2c/busses/i2c-pca-isa.c
116:#ifdef CONFIG_PPC_MERGE
drivers/input/serio/i8042-io.h
70:#if defined(CONFIG_PPC_MERGE)
drivers/usb/host/ehci-hcd.c
1017:#if defined(CONFIG_440EPX) && !defined(CONFIG_PPC_MERGE)
drivers/usb/host/ehci.h
748:#if defined(CONFIG_PPC) && !defined(CONFIG_PPC_MERGE)
drivers/usb/host/ohci.h
536:#if defined(CONFIG_PPC) && !defined(CONFIG_PPC_MERGE)
drivers/net/fs_enet/mac-fec.c
316:#ifndef CONFIG_PPC_MERGE
418:#ifndef CONFIG_PPC_MERGE
drivers/net/fs_enet/mac-scc.c
376:#ifndef CONFIG_PPC_MERGE
drivers/pnp/isapnp/core.c
1015:#ifdef CONFIG_PPC_MERGE
drivers/pnp/pnpbios/core.c
522:#if defined(CONFIG_PPC_MERGE)
580:#if defined(CONFIG_PPC_MERGE)
drivers/serial/mpc52xx_uart.c
76:#if defined(CONFIG_PPC_MERGE)
110:#if defined(CONFIG_PPC_MERGE)
258:#if defined(CONFIG_PPC_MERGE)
889:#if !defined(CONFIG_PPC_MERGE)
949:#if !defined(CONFIG_PPC_MERGE)
1056:#endif /* defined(CONFIG_PPC_MERGE) */
1075:#if defined(CONFIG_PPC_MERGE)
1104:#if !defined(CONFIG_PPC_MERGE)
1208:#endif /* !defined(CONFIG_PPC_MERGE) */
1211:#if defined(CONFIG_PPC_MERGE)
1405:#endif /* defined(CONFIG_PPC_MERGE) */
1426:#if defined(CONFIG_PPC_MERGE)
1453:#if defined(CONFIG_PPC_MERGE)
drivers/spi/mpc52xx_psc_spi.c
19:#if defined(CONFIG_PPC_MERGE)
474:#if !defined(CONFIG_PPC_MERGE)
519:#else /* defined(CONFIG_PPC_MERGE) */
589:#endif /* defined(CONFIG_PPC_MERGE) */
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: Board level compatibility matching
From: Grant Likely @ 2008-08-01 16:24 UTC (permalink / raw)
To: M. Warner Losh; +Cc: devicetree-discuss, linuxppc-dev
In-Reply-To: <20080801.100107.-1666252871.imp@bsdimp.com>
On Fri, Aug 1, 2008 at 10:01 AM, M. Warner Losh <imp@bsdimp.com> wrote:
> I'd float a radical definition of 'compatible' here.
>
> If the generic code can handle it with just changes to the device
> tree, then it is compatible. And by generic code, I wouldn't suggest
> a twisty maze of ifdefs or special case hacks. I'm talking truly
> generic code that is table driven entirely from the dtc. If you need
> special C code to initialize the board, then it isn't compatible.
When doing the initial board port, you don't *know* if you're going to
need special cases. Or, you don't know if the special case code
belongs in the platform code, or belongs somewhere else
(implementation detail). Or, the special code could get refactored in
the future and be moved into or out of the platform code.
Claiming one board is compatible with another tends to just encode a
Linux implementation detail into the device tree.
> This is exactly analogous to the pc-net driver supporting dozens of
> different cards that differ only in their ID. Are all these cards
> 100% the same: no. There's plenty of differences between them.
> However, the pc-net driver copes with the small differences so that
> one driver can handle most of the ne2000 class of network cards.
Yes, and we use lists of compatible values for devices. However, the
board level has much higher complexity. The likelyhood of getting it
wrong is much greater.
g.
^ permalink raw reply
* Re: [BUILD-FAILURE] 2.6.27-rc1-mm1 - allyesconfig build fails on powerpc
From: Kamalesh Babulal @ 2008-08-01 16:16 UTC (permalink / raw)
To: Tony Breeds
Cc: Peter Oberparleiter, linux-kernel, linuxppc-dev, Andrew Morton,
Kernel Testers List, Sam Ravnborg
In-Reply-To: <20080801052936.GZ20457@bakeyournoodle.com>
Tony Breeds wrote:
> On Thu, Jul 31, 2008 at 06:13:28PM +0530, Kamalesh Babulal wrote:
>> Hi Andrew,
>>
>> make allyesconfig with 2.6.27-rc1-mm1 kernel on powerpc fails with build error
>
> <snip>
>
> Turning off GCOV "fixes" this. Not really the best solution but at
> least it narrows doen the search effort.
Thanks, kernel compiles after turning off the GCOV profiling options.
>
> Peter,
> Can you have a look at how this can be fixed, if at all?
Peter,
kindly let me know if you want me to test any test patches/fixes.
>
> Yours Tony
>
> linux.conf.au http://www.marchsouth.org/
> Jan 19 - 24 2009 The Australian Linux Technical Conference!
>
--
Thanks & Regards,
Kamalesh Babulal,
Linux Technology Center,
IBM, ISTL.
^ permalink raw reply
* Re: [i2c] [PATCH] powerpc: i2c-mpc: make speed registers configurable via FDT
From: Jon Smirl @ 2008-08-01 16:05 UTC (permalink / raw)
To: Timur Tabi; +Cc: Trent Piepho, Linuxppc-dev, Linux I2C, Scott Wood
In-Reply-To: <48932579.3040705@freescale.com>
On 8/1/08, Timur Tabi <timur@freescale.com> wrote:
> Jon Smirl wrote:
>
>
> > What about the Efika which is mpc5200 based and doesn't use uboot?
> >
>
> How does the Efika handle the dozen other properties that U-Boot normally
> initializes in the device tree?
Efika is like the original OpenFirmware. It has a Forth interpreter
and builds the device tree itself. It doesn't use flat device trees
that get filled in by the boot firmware.
>
> --
> Timur Tabi
> Linux Kernel Developer @ Freescale
>
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* Re: floating point support in the driver.
From: M. Warner Losh @ 2008-08-01 15:54 UTC (permalink / raw)
To: misbah_khan; +Cc: linuxppc-embedded
In-Reply-To: <18772952.post@talk.nabble.com>
In message: <18772952.post@talk.nabble.com>
Misbah khan <misbah_khan@engineer.com> writes:
: I am not very clear Why floating point support in the Kernel should be
: avoided ?
Because saving the FPU state is expensive. The kernel multiplexes the
FPU hardware among all the userland processes that use it. For parts
of the kernel to effectively use the FPU, it would have to save the
state on traps into the kernel, and restore the state when returning
to userland. This is a big drag on performance of the system. There
are ways around this optimization where you save the fpu state
explicitly, but the expense si still there.
: We want our DSP algorithm to run at the boot time and since kernel thread
: having higher priority , i assume that it would be faster than user
: application.
Bad assumption. User threads can get boots in priority in certain
cases.
If it really is just at boot time, before any other threads are
started, you likely can get away with it.
: If i really have to speed up my application execution what mechanism will
: you suggest me to try ?
:
: After using Hardware VFP support also i am still laging the timing
: requirement by 800 ms in my case
This sounds like a classic case of putting 20 pounds in a 10 pound bag
and complaining that the bag rips out. You need a bigger bag.
If you are doing FPU intensive operations in userland, moving them to
the kernel isn't going to help anything but maybe latency. And if you
are almost a full second short, your quest to move things into the
kernel is almost certainly not going to help enough. Moving things
into the kernel only helps latency, and only when there's lots of
context switches (since doing stuff in the kernel avoids the domain
crossing that forces the save of the CPU state).
I don't know if the 800ms timing is relative to a task that must run
once a second, or once an hour. If the former, you're totally
screwed and need to either be more clever about your algorithm
(consider integer math, profiling the hot spots, etc), or you need
more powerful silicon. If you are trying to shave 800ms off a task
that runs for an hour, then you just might be able to do that with
tiny code tweaks.
Sorry to be so harsh, but really, there's no such thing as a free lunch.
Warner
: ---- Misbah <><
:
:
: Laurent Pinchart-4 wrote:
: >
: > On Friday 01 August 2008, Misbah khan wrote:
: >>
: >> Hi all,
: >>
: >> I have a DSP algorithm which i am running in the application even after
: >> enabling the VFP support it is taking a lot of time to get executed hence
: >>
: >> I want to transform the same into the driver insted of an user
: >> application.
: >> Can anybody suggest whether doing the same could be a better solution and
: >> what could be the chalenges that i have to face by implimenting such
: >> floating point support in the driver.
: >>
: >> Is there a way in the application itself to make it execute faster.
: >
: > Floating-point in the kernel should be avoided. FPU state save/restore
: > operations are costly and are not performed by the kernel when switching
: > from userspace to kernelspace context. You will have to protect
: > floating-point sections with kernel_fpu_begin/kernel_fpu_end which, if I'm
: > not mistaken, disables preemption. That's probably not something you want
: > to do. Why would the same code run faster in kernelspace then userspace ?
: >
: > --
: > Laurent Pinchart
: > CSE Semaphore Belgium
: >
: > Chaussee de Bruxelles, 732A
: > B-1410 Waterloo
: > Belgium
: >
: > T +32 (2) 387 42 59
: > F +32 (2) 387 42 75
: >
: >
: > _______________________________________________
: > Linuxppc-embedded mailing list
: > Linuxppc-embedded@ozlabs.org
: > https://ozlabs.org/mailman/listinfo/linuxppc-embedded
: >
:
: --
: View this message in context: http://www.nabble.com/floating-point-support-in-the-driver.-tp18772109p18772952.html
: Sent from the linuxppc-embedded mailing list archive at Nabble.com.
:
: _______________________________________________
: Linuxppc-embedded mailing list
: Linuxppc-embedded@ozlabs.org
: https://ozlabs.org/mailman/listinfo/linuxppc-embedded
:
:
^ permalink raw reply
* Re: Board level compatibility matching
From: M. Warner Losh @ 2008-08-01 16:01 UTC (permalink / raw)
To: jwboyer; +Cc: devicetree-discuss, linuxppc-dev
In-Reply-To: <20080801111141.3543e23b@zod.rchland.ibm.com>
I'd float a radical definition of 'compatible' here.
If the generic code can handle it with just changes to the device
tree, then it is compatible. And by generic code, I wouldn't suggest
a twisty maze of ifdefs or special case hacks. I'm talking truly
generic code that is table driven entirely from the dtc. If you need
special C code to initialize the board, then it isn't compatible.
This is exactly analogous to the pc-net driver supporting dozens of
different cards that differ only in their ID. Are all these cards
100% the same: no. There's plenty of differences between them.
However, the pc-net driver copes with the small differences so that
one driver can handle most of the ne2000 class of network cards.
Are there special drivers for ne2000-like cards that aren't quite
compatible enough or have extra features, sure.
That doesn't totally invalidate the utility. There are always
engineering trade offs to be made.
Warner
^ permalink raw reply
* Compact flash on mpc8349eITX
From: Sparks, Sam @ 2008-08-01 15:58 UTC (permalink / raw)
To: linuxppc-dev
I'm trying to get the compact flash up and running on an mpc8349eITX,
and am continually running into issues where the IRQ is not processed,
and the mmio commands are not getting response. At this point, I am
starting to suspect a HW issue, but I was hoping to verify that I am
using a known good kernel configuration.
Has anyone successfully communicated with a compact flash device in true
IDE mode on the MPC8349eITX? If so, do you happen to know the kernel
configuration and/or revision?
I appreciate any help, as I am really getting stuck here.
Regards,
Sam
^ permalink raw reply
* Re: platforms/44x/warp-nand.c bogosity
From: Sean MacLennan @ 2008-08-01 15:59 UTC (permalink / raw)
To: Josh Boyer; +Cc: linuxppc-dev, Adrian Bunk, Stefan Roese, paulus
In-Reply-To: <20080801112628.35fb0ff2@zod.rchland.ibm.com>
On Fri, 1 Aug 2008 11:26:28 -0400
"Josh Boyer" <jwboyer@linux.vnet.ibm.com> wrote:
> I don't believe it is intentional, no. Sean can you look at this and
> see what's up? I have a couple of fixes to queue up from you already
> and if you can get this one done in the next few days I'll included it
> as well.
So I went back in the archives. Somebody else, Thomas Gleixner I
believe, was already working on the ndfc port. So, since I *had* to
have a working ndfc, I put a local copy in my kernel and forgot about
it.
It looks like Thomas has dropped the port. I should probably resubmit
the patch with the arch/ppc code removed. However, I don't think this
would be for 2.6.27 timeframe since there will probably be discussion.
For one, my patch just gets it working... the warp-nand.c file shows
that it is not a complete solution ;) Second, there are some byte order
issues.
So could we just leave warp-nand.c "there but disabled" for now?
Cheers,
Sean
^ permalink raw reply
* [PATCH] powerpc: Remove use of CONFIG_PPC_MERGE
From: Kumar Gala @ 2008-08-01 15:50 UTC (permalink / raw)
To: linuxppc-dev
Now that arch/ppc is gone we don't need CONFIG_PPC_MERGE anymore
remove the dead code associated with !CONFIG_PPC_MERGE out of arch/powerpc
and include/asm-powerpc.
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
---
arch/powerpc/Kconfig.debug | 2 +-
arch/powerpc/kernel/Makefile | 14 --
arch/powerpc/kernel/cpu_setup_44x.S | 6 -
arch/powerpc/kernel/irq.c | 25 +---
arch/powerpc/kernel/process.c | 2 -
arch/powerpc/kernel/vdso.c | 2 -
arch/powerpc/lib/Makefile | 2 -
arch/powerpc/platforms/52xx/Makefile | 4 +-
arch/powerpc/platforms/Makefile | 6 -
arch/powerpc/platforms/powermac/Makefile | 3 +-
arch/powerpc/sysdev/Makefile | 2 -
include/asm-powerpc/dcr.h | 6 +-
include/asm-powerpc/i8259.h | 5 -
include/asm-powerpc/ipic.h | 7 -
include/asm-powerpc/irq.h | 288 ------------------------------
15 files changed, 6 insertions(+), 368 deletions(-)
diff --git a/arch/powerpc/Kconfig.debug b/arch/powerpc/Kconfig.debug
index 8c8aadb..4ebc52a 100644
--- a/arch/powerpc/Kconfig.debug
+++ b/arch/powerpc/Kconfig.debug
@@ -97,7 +97,7 @@ config IRQSTACKS
config VIRQ_DEBUG
bool "Expose hardware/virtual IRQ mapping via debugfs"
- depends on DEBUG_FS && PPC_MERGE
+ depends on DEBUG_FS
help
This option will show the mapping relationship between hardware irq
numbers and virtual irq numbers. The mapping is exposed via debugfs
diff --git a/arch/powerpc/kernel/Makefile b/arch/powerpc/kernel/Makefile
index 1a40947..64f5948 100644
--- a/arch/powerpc/kernel/Makefile
+++ b/arch/powerpc/kernel/Makefile
@@ -59,8 +59,6 @@ obj64-$(CONFIG_HIBERNATION) += swsusp_asm64.o
obj-$(CONFIG_MODULES) += module.o module_$(CONFIG_WORD_SIZE).o
obj-$(CONFIG_44x) += cpu_setup_44x.o
-ifeq ($(CONFIG_PPC_MERGE),y)
-
extra-$(CONFIG_PPC_STD_MMU) := head_32.o
extra-$(CONFIG_PPC64) := head_64.o
extra-$(CONFIG_40x) := head_40x.o
@@ -100,12 +98,6 @@ ifneq ($(CONFIG_PPC_INDIRECT_IO),y)
obj-y += iomap.o
endif
-else
-# stuff used from here for ARCH=ppc
-smpobj-$(CONFIG_SMP) += smp.o
-
-endif
-
obj-$(CONFIG_PPC64) += $(obj64-y)
extra-$(CONFIG_PPC_FPU) += fpu.o
@@ -121,9 +113,6 @@ PHONY += systbl_chk
systbl_chk: $(src)/systbl_chk.sh $(obj)/systbl_chk.i
$(call cmd,systbl_chk)
-
-ifeq ($(CONFIG_PPC_MERGE),y)
-
$(obj)/built-in.o: prom_init_check
quiet_cmd_prom_init_check = CALL $<
@@ -133,7 +122,4 @@ PHONY += prom_init_check
prom_init_check: $(src)/prom_init_check.sh $(obj)/prom_init.o
$(call cmd,prom_init_check)
-endif
-
-
clean-files := vmlinux.lds
diff --git a/arch/powerpc/kernel/cpu_setup_44x.S b/arch/powerpc/kernel/cpu_setup_44x.S
index 5465e8d..80cac98 100644
--- a/arch/powerpc/kernel/cpu_setup_44x.S
+++ b/arch/powerpc/kernel/cpu_setup_44x.S
@@ -39,12 +39,6 @@ _GLOBAL(__setup_cpu_440gx)
_GLOBAL(__setup_cpu_440spe)
b __fixup_440A_mcheck
- /* Temporary fixup for arch/ppc until we kill the whole thing */
-#ifndef CONFIG_PPC_MERGE
-_GLOBAL(__fixup_440A_mcheck)
- blr
-#endif
-
/* enable APU between CPU and FPU */
_GLOBAL(__init_fpu_44x)
mfspr r3,SPRN_CCR0
diff --git a/arch/powerpc/kernel/irq.c b/arch/powerpc/kernel/irq.c
index 6ac8612..d972dec 100644
--- a/arch/powerpc/kernel/irq.c
+++ b/arch/powerpc/kernel/irq.c
@@ -77,22 +77,12 @@ static int ppc_spurious_interrupts;
EXPORT_SYMBOL(__irq_offset_value);
atomic_t ppc_n_lost_interrupts;
-#ifndef CONFIG_PPC_MERGE
-#define NR_MASK_WORDS ((NR_IRQS + 31) / 32)
-unsigned long ppc_cached_irq_mask[NR_MASK_WORDS];
-#endif
-
#ifdef CONFIG_TAU_INT
extern int tau_initialized;
extern int tau_interrupts(int);
#endif
#endif /* CONFIG_PPC32 */
-#if defined(CONFIG_SMP) && !defined(CONFIG_PPC_MERGE)
-extern atomic_t ipi_recv;
-extern atomic_t ipi_sent;
-#endif
-
#ifdef CONFIG_PPC64
EXPORT_SYMBOL(irq_desc);
@@ -216,21 +206,14 @@ int show_interrupts(struct seq_file *p, void *v)
skip:
spin_unlock_irqrestore(&desc->lock, flags);
} else if (i == NR_IRQS) {
-#ifdef CONFIG_PPC32
-#ifdef CONFIG_TAU_INT
+#if defined(CONFIG_PPC32) && defined(CONFIG_TAU_INT)
if (tau_initialized){
seq_puts(p, "TAU: ");
for_each_online_cpu(j)
seq_printf(p, "%10u ", tau_interrupts(j));
seq_puts(p, " PowerPC Thermal Assist (cpu temp)\n");
}
-#endif
-#if defined(CONFIG_SMP) && !defined(CONFIG_PPC_MERGE)
- /* should this be per processor send/receive? */
- seq_printf(p, "IPI (recv/sent): %10u/%u\n",
- atomic_read(&ipi_recv), atomic_read(&ipi_sent));
-#endif
-#endif /* CONFIG_PPC32 */
+#endif /* CONFIG_PPC32 && CONFIG_TAU_INT*/
seq_printf(p, "BAD: %10u\n", ppc_spurious_interrupts);
}
return 0;
@@ -454,8 +437,6 @@ void do_softirq(void)
* IRQ controller and virtual interrupts
*/
-#ifdef CONFIG_PPC_MERGE
-
static LIST_HEAD(irq_hosts);
static DEFINE_SPINLOCK(irq_big_lock);
static DEFINE_PER_CPU(unsigned int, irq_radix_reader);
@@ -1114,8 +1095,6 @@ static int __init irq_debugfs_init(void)
__initcall(irq_debugfs_init);
#endif /* CONFIG_VIRQ_DEBUG */
-#endif /* CONFIG_PPC_MERGE */
-
#ifdef CONFIG_PPC64
static int __init setup_noirqdistrib(char *str)
{
diff --git a/arch/powerpc/kernel/process.c b/arch/powerpc/kernel/process.c
index e030f3b..957bded 100644
--- a/arch/powerpc/kernel/process.c
+++ b/arch/powerpc/kernel/process.c
@@ -276,10 +276,8 @@ int set_dabr(unsigned long dabr)
{
__get_cpu_var(current_dabr) = dabr;
-#ifdef CONFIG_PPC_MERGE /* XXX for now */
if (ppc_md.set_dabr)
return ppc_md.set_dabr(dabr);
-#endif
/* XXX should we have a CPU_FTR_HAS_DABR ? */
#if defined(CONFIG_PPC64) || defined(CONFIG_6xx)
diff --git a/arch/powerpc/kernel/vdso.c b/arch/powerpc/kernel/vdso.c
index f177c60..65639a4 100644
--- a/arch/powerpc/kernel/vdso.c
+++ b/arch/powerpc/kernel/vdso.c
@@ -788,9 +788,7 @@ static int __init vdso_init(void)
return 0;
}
-#ifdef CONFIG_PPC_MERGE
arch_initcall(vdso_init);
-#endif
int in_gate_area_no_task(unsigned long addr)
{
diff --git a/arch/powerpc/lib/Makefile b/arch/powerpc/lib/Makefile
index 2a88e8b..d69912c 100644
--- a/arch/powerpc/lib/Makefile
+++ b/arch/powerpc/lib/Makefile
@@ -6,12 +6,10 @@ ifeq ($(CONFIG_PPC64),y)
EXTRA_CFLAGS += -mno-minimal-toc
endif
-ifeq ($(CONFIG_PPC_MERGE),y)
obj-y := string.o alloc.o \
checksum_$(CONFIG_WORD_SIZE).o
obj-$(CONFIG_PPC32) += div64.o copy_32.o crtsavres.o
obj-$(CONFIG_HAS_IOMEM) += devres.o
-endif
obj-$(CONFIG_PPC64) += copypage_64.o copyuser_64.o \
memcpy_64.o usercopy_64.o mem_64.o string.o
diff --git a/arch/powerpc/platforms/52xx/Makefile b/arch/powerpc/platforms/52xx/Makefile
index daf0e15..b8a5206 100644
--- a/arch/powerpc/platforms/52xx/Makefile
+++ b/arch/powerpc/platforms/52xx/Makefile
@@ -1,10 +1,8 @@
#
# Makefile for 52xx based boards
#
-ifeq ($(CONFIG_PPC_MERGE),y)
obj-y += mpc52xx_pic.o mpc52xx_common.o
obj-$(CONFIG_PCI) += mpc52xx_pci.o
-endif
obj-$(CONFIG_PPC_MPC5200_SIMPLE) += mpc5200_simple.o
obj-$(CONFIG_PPC_EFIKA) += efika.o
@@ -15,4 +13,4 @@ ifeq ($(CONFIG_PPC_LITE5200),y)
obj-$(CONFIG_PM) += lite5200_sleep.o lite5200_pm.o
endif
-obj-$(CONFIG_PPC_MPC5200_GPIO) += mpc52xx_gpio.o
\ No newline at end of file
+obj-$(CONFIG_PPC_MPC5200_GPIO) += mpc52xx_gpio.o
diff --git a/arch/powerpc/platforms/Makefile b/arch/powerpc/platforms/Makefile
index 423a023..8079e0b 100644
--- a/arch/powerpc/platforms/Makefile
+++ b/arch/powerpc/platforms/Makefile
@@ -1,13 +1,7 @@
obj-$(CONFIG_FSL_ULI1575) += fsl_uli1575.o
-ifeq ($(CONFIG_PPC_MERGE),y)
obj-$(CONFIG_PPC_PMAC) += powermac/
-else
-ifeq ($(CONFIG_PPC64),y)
-obj-$(CONFIG_PPC_PMAC) += powermac/
-endif
-endif
obj-$(CONFIG_PPC_CHRP) += chrp/
obj-$(CONFIG_40x) += 40x/
obj-$(CONFIG_44x) += 44x/
diff --git a/arch/powerpc/platforms/powermac/Makefile b/arch/powerpc/platforms/powermac/Makefile
index 8977417..58ecdd7 100644
--- a/arch/powerpc/platforms/powermac/Makefile
+++ b/arch/powerpc/platforms/powermac/Makefile
@@ -7,7 +7,7 @@ endif
obj-y += pic.o setup.o time.o feature.o pci.o \
sleep.o low_i2c.o cache.o pfunc_core.o \
- pfunc_base.o
+ pfunc_base.o udbg_scc.o udbg_adb.o
obj-$(CONFIG_PMAC_BACKLIGHT) += backlight.o
obj-$(CONFIG_CPU_FREQ_PMAC) += cpufreq_32.o
obj-$(CONFIG_CPU_FREQ_PMAC64) += cpufreq_64.o
@@ -19,4 +19,3 @@ obj-$(CONFIG_NVRAM:m=y) += nvram.o
obj-$(CONFIG_PPC64) += nvram.o
obj-$(CONFIG_PPC32) += bootx_init.o
obj-$(CONFIG_SMP) += smp.o
-obj-$(CONFIG_PPC_MERGE) += udbg_scc.o udbg_adb.o
diff --git a/arch/powerpc/sysdev/Makefile b/arch/powerpc/sysdev/Makefile
index 16a0ed2..a90054b 100644
--- a/arch/powerpc/sysdev/Makefile
+++ b/arch/powerpc/sysdev/Makefile
@@ -25,7 +25,6 @@ obj-$(CONFIG_MV64X60) += $(mv64x60-y) mv64x60_pic.o mv64x60_dev.o \
obj-$(CONFIG_RTC_DRV_CMOS) += rtc_cmos_setup.o
obj-$(CONFIG_AXON_RAM) += axonram.o
-ifeq ($(CONFIG_PPC_MERGE),y)
obj-$(CONFIG_PPC_INDIRECT_PCI) += indirect_pci.o
obj-$(CONFIG_PPC_I8259) += i8259.o
obj-$(CONFIG_IPIC) += ipic.o
@@ -36,7 +35,6 @@ obj-$(CONFIG_OF_RTC) += of_rtc.o
ifeq ($(CONFIG_PCI),y)
obj-$(CONFIG_4xx) += ppc4xx_pci.o
endif
-endif
# Temporary hack until we have migrated to asm-powerpc
ifeq ($(ARCH),powerpc)
diff --git a/include/asm-powerpc/dcr.h b/include/asm-powerpc/dcr.h
index 53b2830..d13fb68 100644
--- a/include/asm-powerpc/dcr.h
+++ b/include/asm-powerpc/dcr.h
@@ -65,17 +65,13 @@ typedef dcr_host_mmio_t dcr_host_t;
#endif /* defined(CONFIG_PPC_DCR_NATIVE) && defined(CONFIG_PPC_DCR_MMIO) */
/*
- * On CONFIG_PPC_MERGE, we have additional helpers to read the DCR
- * base from the device-tree
+ * additional helpers to read the DCR * base from the device-tree
*/
-#ifdef CONFIG_PPC_MERGE
struct device_node;
extern unsigned int dcr_resource_start(struct device_node *np,
unsigned int index);
extern unsigned int dcr_resource_len(struct device_node *np,
unsigned int index);
-#endif /* CONFIG_PPC_MERGE */
-
#endif /* CONFIG_PPC_DCR */
#endif /* __ASSEMBLY__ */
#endif /* __KERNEL__ */
diff --git a/include/asm-powerpc/i8259.h b/include/asm-powerpc/i8259.h
index db1362f..105ade2 100644
--- a/include/asm-powerpc/i8259.h
+++ b/include/asm-powerpc/i8259.h
@@ -4,14 +4,9 @@
#include <linux/irq.h>
-#ifdef CONFIG_PPC_MERGE
extern void i8259_init(struct device_node *node, unsigned long intack_addr);
extern unsigned int i8259_irq(void);
extern struct irq_host *i8259_get_host(void);
-#else
-extern void i8259_init(unsigned long intack_addr, int offset);
-extern int i8259_irq(void);
-#endif
#endif /* __KERNEL__ */
#endif /* _ASM_POWERPC_I8259_H */
diff --git a/include/asm-powerpc/ipic.h b/include/asm-powerpc/ipic.h
index 8ff08be..a90242c 100644
--- a/include/asm-powerpc/ipic.h
+++ b/include/asm-powerpc/ipic.h
@@ -79,15 +79,8 @@ extern void ipic_disable_mcp(enum ipic_mcp_irq mcp_irq);
extern u32 ipic_get_mcp_status(void);
extern void ipic_clear_mcp_status(u32 mask);
-#ifdef CONFIG_PPC_MERGE
extern struct ipic * ipic_init(struct device_node *node, unsigned int flags);
extern unsigned int ipic_get_irq(void);
-#else
-extern void ipic_init(phys_addr_t phys_addr, unsigned int flags,
- unsigned int irq_offset,
- unsigned char *senses, unsigned int senses_count);
-extern int ipic_get_irq(void);
-#endif
#endif /* __ASM_IPIC_H__ */
#endif /* __KERNEL__ */
diff --git a/include/asm-powerpc/irq.h b/include/asm-powerpc/irq.h
index 1ef8e30..a372f76 100644
--- a/include/asm-powerpc/irq.h
+++ b/include/asm-powerpc/irq.h
@@ -25,8 +25,6 @@
extern atomic_t ppc_n_lost_interrupts;
-#ifdef CONFIG_PPC_MERGE
-
/* This number is used when no interrupt has been assigned */
#define NO_IRQ (0)
@@ -326,292 +324,6 @@ static __inline__ int irq_canonicalize(int irq)
return irq;
}
-
-#else /* CONFIG_PPC_MERGE */
-
-/* This number is used when no interrupt has been assigned */
-#define NO_IRQ (-1)
-#define NO_IRQ_IGNORE (-2)
-
-
-/*
- * These constants are used for passing information about interrupt
- * signal polarity and level/edge sensing to the low-level PIC chip
- * drivers.
- */
-#define IRQ_SENSE_MASK 0x1
-#define IRQ_SENSE_LEVEL 0x1 /* interrupt on active level */
-#define IRQ_SENSE_EDGE 0x0 /* interrupt triggered by edge */
-
-#define IRQ_POLARITY_MASK 0x2
-#define IRQ_POLARITY_POSITIVE 0x2 /* high level or low->high edge */
-#define IRQ_POLARITY_NEGATIVE 0x0 /* low level or high->low edge */
-
-
-#if defined(CONFIG_40x)
-#include <asm/ibm4xx.h>
-
-#ifndef NR_BOARD_IRQS
-#define NR_BOARD_IRQS 0
-#endif
-
-#ifndef UIC_WIDTH /* Number of interrupts per device */
-#define UIC_WIDTH 32
-#endif
-
-#ifndef NR_UICS /* number of UIC devices */
-#define NR_UICS 1
-#endif
-
-#if defined (CONFIG_403)
-/*
- * The PowerPC 403 cores' Asynchronous Interrupt Controller (AIC) has
- * 32 possible interrupts, a majority of which are not implemented on
- * all cores. There are six configurable, external interrupt pins and
- * there are eight internal interrupts for the on-chip serial port
- * (SPU), DMA controller, and JTAG controller.
- *
- */
-
-#define NR_AIC_IRQS 32
-#define NR_IRQS (NR_AIC_IRQS + NR_BOARD_IRQS)
-
-#elif !defined (CONFIG_403)
-
-/*
- * The PowerPC 405 cores' Universal Interrupt Controller (UIC) has 32
- * possible interrupts as well. There are seven, configurable external
- * interrupt pins and there are 17 internal interrupts for the on-chip
- * serial port, DMA controller, on-chip Ethernet controller, PCI, etc.
- *
- */
-
-
-#define NR_UIC_IRQS UIC_WIDTH
-#define NR_IRQS ((NR_UIC_IRQS * NR_UICS) + NR_BOARD_IRQS)
-#endif
-
-#elif defined(CONFIG_44x)
-#include <asm/ibm44x.h>
-
-#define NR_UIC_IRQS 32
-#define NR_IRQS ((NR_UIC_IRQS * NR_UICS) + NR_BOARD_IRQS)
-
-#elif defined(CONFIG_8xx)
-
-/* Now include the board configuration specific associations.
-*/
-#include <asm/mpc8xx.h>
-
-/* The MPC8xx cores have 16 possible interrupts. There are eight
- * possible level sensitive interrupts assigned and generated internally
- * from such devices as CPM, PCMCIA, RTC, PIT, TimeBase and Decrementer.
- * There are eight external interrupts (IRQs) that can be configured
- * as either level or edge sensitive.
- *
- * On some implementations, there is also the possibility of an 8259
- * through the PCI and PCI-ISA bridges.
- *
- * We are "flattening" the interrupt vectors of the cascaded CPM
- * and 8259 interrupt controllers so that we can uniquely identify
- * any interrupt source with a single integer.
- */
-#define NR_SIU_INTS 16
-#define NR_CPM_INTS 32
-#ifndef NR_8259_INTS
-#define NR_8259_INTS 0
-#endif
-
-#define SIU_IRQ_OFFSET 0
-#define CPM_IRQ_OFFSET (SIU_IRQ_OFFSET + NR_SIU_INTS)
-#define I8259_IRQ_OFFSET (CPM_IRQ_OFFSET + NR_CPM_INTS)
-
-#define NR_IRQS (NR_SIU_INTS + NR_CPM_INTS + NR_8259_INTS)
-
-/* These values must be zero-based and map 1:1 with the SIU configuration.
- * They are used throughout the 8xx I/O subsystem to generate
- * interrupt masks, flags, and other control patterns. This is why the
- * current kernel assumption of the 8259 as the base controller is such
- * a pain in the butt.
- */
-#define SIU_IRQ0 (0) /* Highest priority */
-#define SIU_LEVEL0 (1)
-#define SIU_IRQ1 (2)
-#define SIU_LEVEL1 (3)
-#define SIU_IRQ2 (4)
-#define SIU_LEVEL2 (5)
-#define SIU_IRQ3 (6)
-#define SIU_LEVEL3 (7)
-#define SIU_IRQ4 (8)
-#define SIU_LEVEL4 (9)
-#define SIU_IRQ5 (10)
-#define SIU_LEVEL5 (11)
-#define SIU_IRQ6 (12)
-#define SIU_LEVEL6 (13)
-#define SIU_IRQ7 (14)
-#define SIU_LEVEL7 (15)
-
-#define MPC8xx_INT_FEC1 SIU_LEVEL1
-#define MPC8xx_INT_FEC2 SIU_LEVEL3
-
-#define MPC8xx_INT_SCC1 (CPM_IRQ_OFFSET + CPMVEC_SCC1)
-#define MPC8xx_INT_SCC2 (CPM_IRQ_OFFSET + CPMVEC_SCC2)
-#define MPC8xx_INT_SCC3 (CPM_IRQ_OFFSET + CPMVEC_SCC3)
-#define MPC8xx_INT_SCC4 (CPM_IRQ_OFFSET + CPMVEC_SCC4)
-#define MPC8xx_INT_SMC1 (CPM_IRQ_OFFSET + CPMVEC_SMC1)
-#define MPC8xx_INT_SMC2 (CPM_IRQ_OFFSET + CPMVEC_SMC2)
-
-/* The internal interrupts we can configure as we see fit.
- * My personal preference is CPM at level 2, which puts it above the
- * MBX PCI/ISA/IDE interrupts.
- */
-#ifndef PIT_INTERRUPT
-#define PIT_INTERRUPT SIU_LEVEL0
-#endif
-#ifndef CPM_INTERRUPT
-#define CPM_INTERRUPT SIU_LEVEL2
-#endif
-#ifndef PCMCIA_INTERRUPT
-#define PCMCIA_INTERRUPT SIU_LEVEL6
-#endif
-#ifndef DEC_INTERRUPT
-#define DEC_INTERRUPT SIU_LEVEL7
-#endif
-
-/* Some internal interrupt registers use an 8-bit mask for the interrupt
- * level instead of a number.
- */
-#define mk_int_int_mask(IL) (1 << (7 - (IL/2)))
-
-#else /* CONFIG_40x + CONFIG_8xx */
-/*
- * this is the # irq's for all ppc arch's (pmac/chrp/prep)
- * so it is the max of them all
- */
-#define NR_IRQS 256
-#define __DO_IRQ_CANON 1
-
-#ifndef CONFIG_8260
-
-#define NUM_8259_INTERRUPTS 16
-
-#else /* CONFIG_8260 */
-
-/* The 8260 has an internal interrupt controller with a maximum of
- * 64 IRQs. We will use NR_IRQs from above since it is large enough.
- * Don't be confused by the 8260 documentation where they list an
- * "interrupt number" and "interrupt vector". We are only interested
- * in the interrupt vector. There are "reserved" holes where the
- * vector number increases, but the interrupt number in the table does not.
- * (Document errata updates have fixed this...make sure you have up to
- * date processor documentation -- Dan).
- */
-
-#ifndef CPM_IRQ_OFFSET
-#define CPM_IRQ_OFFSET 0
-#endif
-
-#define NR_CPM_INTS 64
-
-#define SIU_INT_ERROR ((uint)0x00 + CPM_IRQ_OFFSET)
-#define SIU_INT_I2C ((uint)0x01 + CPM_IRQ_OFFSET)
-#define SIU_INT_SPI ((uint)0x02 + CPM_IRQ_OFFSET)
-#define SIU_INT_RISC ((uint)0x03 + CPM_IRQ_OFFSET)
-#define SIU_INT_SMC1 ((uint)0x04 + CPM_IRQ_OFFSET)
-#define SIU_INT_SMC2 ((uint)0x05 + CPM_IRQ_OFFSET)
-#define SIU_INT_IDMA1 ((uint)0x06 + CPM_IRQ_OFFSET)
-#define SIU_INT_IDMA2 ((uint)0x07 + CPM_IRQ_OFFSET)
-#define SIU_INT_IDMA3 ((uint)0x08 + CPM_IRQ_OFFSET)
-#define SIU_INT_IDMA4 ((uint)0x09 + CPM_IRQ_OFFSET)
-#define SIU_INT_SDMA ((uint)0x0a + CPM_IRQ_OFFSET)
-#define SIU_INT_USB ((uint)0x0b + CPM_IRQ_OFFSET)
-#define SIU_INT_TIMER1 ((uint)0x0c + CPM_IRQ_OFFSET)
-#define SIU_INT_TIMER2 ((uint)0x0d + CPM_IRQ_OFFSET)
-#define SIU_INT_TIMER3 ((uint)0x0e + CPM_IRQ_OFFSET)
-#define SIU_INT_TIMER4 ((uint)0x0f + CPM_IRQ_OFFSET)
-#define SIU_INT_TMCNT ((uint)0x10 + CPM_IRQ_OFFSET)
-#define SIU_INT_PIT ((uint)0x11 + CPM_IRQ_OFFSET)
-#define SIU_INT_PCI ((uint)0x12 + CPM_IRQ_OFFSET)
-#define SIU_INT_IRQ1 ((uint)0x13 + CPM_IRQ_OFFSET)
-#define SIU_INT_IRQ2 ((uint)0x14 + CPM_IRQ_OFFSET)
-#define SIU_INT_IRQ3 ((uint)0x15 + CPM_IRQ_OFFSET)
-#define SIU_INT_IRQ4 ((uint)0x16 + CPM_IRQ_OFFSET)
-#define SIU_INT_IRQ5 ((uint)0x17 + CPM_IRQ_OFFSET)
-#define SIU_INT_IRQ6 ((uint)0x18 + CPM_IRQ_OFFSET)
-#define SIU_INT_IRQ7 ((uint)0x19 + CPM_IRQ_OFFSET)
-#define SIU_INT_FCC1 ((uint)0x20 + CPM_IRQ_OFFSET)
-#define SIU_INT_FCC2 ((uint)0x21 + CPM_IRQ_OFFSET)
-#define SIU_INT_FCC3 ((uint)0x22 + CPM_IRQ_OFFSET)
-#define SIU_INT_MCC1 ((uint)0x24 + CPM_IRQ_OFFSET)
-#define SIU_INT_MCC2 ((uint)0x25 + CPM_IRQ_OFFSET)
-#define SIU_INT_SCC1 ((uint)0x28 + CPM_IRQ_OFFSET)
-#define SIU_INT_SCC2 ((uint)0x29 + CPM_IRQ_OFFSET)
-#define SIU_INT_SCC3 ((uint)0x2a + CPM_IRQ_OFFSET)
-#define SIU_INT_SCC4 ((uint)0x2b + CPM_IRQ_OFFSET)
-#define SIU_INT_PC15 ((uint)0x30 + CPM_IRQ_OFFSET)
-#define SIU_INT_PC14 ((uint)0x31 + CPM_IRQ_OFFSET)
-#define SIU_INT_PC13 ((uint)0x32 + CPM_IRQ_OFFSET)
-#define SIU_INT_PC12 ((uint)0x33 + CPM_IRQ_OFFSET)
-#define SIU_INT_PC11 ((uint)0x34 + CPM_IRQ_OFFSET)
-#define SIU_INT_PC10 ((uint)0x35 + CPM_IRQ_OFFSET)
-#define SIU_INT_PC9 ((uint)0x36 + CPM_IRQ_OFFSET)
-#define SIU_INT_PC8 ((uint)0x37 + CPM_IRQ_OFFSET)
-#define SIU_INT_PC7 ((uint)0x38 + CPM_IRQ_OFFSET)
-#define SIU_INT_PC6 ((uint)0x39 + CPM_IRQ_OFFSET)
-#define SIU_INT_PC5 ((uint)0x3a + CPM_IRQ_OFFSET)
-#define SIU_INT_PC4 ((uint)0x3b + CPM_IRQ_OFFSET)
-#define SIU_INT_PC3 ((uint)0x3c + CPM_IRQ_OFFSET)
-#define SIU_INT_PC2 ((uint)0x3d + CPM_IRQ_OFFSET)
-#define SIU_INT_PC1 ((uint)0x3e + CPM_IRQ_OFFSET)
-#define SIU_INT_PC0 ((uint)0x3f + CPM_IRQ_OFFSET)
-
-#endif /* CONFIG_8260 */
-
-#endif /* Whatever way too big #ifdef */
-
-#define NR_MASK_WORDS ((NR_IRQS + 31) / 32)
-/* pedantic: these are long because they are used with set_bit --RR */
-extern unsigned long ppc_cached_irq_mask[NR_MASK_WORDS];
-
-/*
- * Because many systems have two overlapping names spaces for
- * interrupts (ISA and XICS for example), and the ISA interrupts
- * have historically not been easy to renumber, we allow ISA
- * interrupts to take values 0 - 15, and shift up the remaining
- * interrupts by 0x10.
- */
-#define NUM_ISA_INTERRUPTS 0x10
-extern int __irq_offset_value;
-
-static inline int irq_offset_up(int irq)
-{
- return(irq + __irq_offset_value);
-}
-
-static inline int irq_offset_down(int irq)
-{
- return(irq - __irq_offset_value);
-}
-
-static inline int irq_offset_value(void)
-{
- return __irq_offset_value;
-}
-
-#ifdef __DO_IRQ_CANON
-extern int ppc_do_canonicalize_irqs;
-#else
-#define ppc_do_canonicalize_irqs 0
-#endif
-
-static __inline__ int irq_canonicalize(int irq)
-{
- if (ppc_do_canonicalize_irqs && irq == 2)
- irq = 9;
- return irq;
-}
-#endif /* CONFIG_PPC_MERGE */
-
extern int distribute_irqs;
struct irqaction;
--
1.5.5.1
^ permalink raw reply related
* Re: [i2c] [PATCH] powerpc: i2c-mpc: make speed registers configurable via FDT
From: Scott Wood @ 2008-08-01 15:47 UTC (permalink / raw)
To: Timur Tabi; +Cc: Linuxppc-dev, Trent Piepho, Linux I2C
In-Reply-To: <ed82fe3e0808010617u101855f7x70d3cbd2bed31f8c@mail.gmail.com>
On Fri, Aug 01, 2008 at 08:17:25AM -0500, Timur Tabi wrote:
> On Thu, Jul 31, 2008 at 6:32 PM, Trent Piepho <xyzzy@speakeasy.org> wrote:
> > Sometimes the two i2c controllers don't even
> > have the same clock.
>
> On which platform is that the case? I thought I had all 8[356]xx
> boards covered. Did I miss some?
On 8313, i2c1 is driven by the encryption clock (whose divider from the
CSB clock is programmable as 1, 2, or 3), but i2c2 is driven directly by
the CSB clock.
-Scott
^ permalink raw reply
* Re: [BUILD-FAILURE] 2.6.27-rc1-mm1 - allyesconfig build fails on powerpc
From: Peter 1 Oberparleiter @ 2008-08-01 15:44 UTC (permalink / raw)
To: Tony Breeds
Cc: linux-kernel, Kamalesh Babulal, linuxppc-dev, Andrew Morton,
Kernel Testers List, Sam Ravnborg
In-Reply-To: <20080801052936.GZ20457@bakeyournoodle.com>
Tony Breeds <tony@bakeyournoodle.com> wrote on 01.08.2008 07:29:36:
> On Thu, Jul 31, 2008 at 06:13:28PM +0530, Kamalesh Babulal wrote:
> > Hi Andrew,
> >
> > make allyesconfig with 2.6.27-rc1-mm1 kernel on powerpc fails with
> build error
>
> <snip>
>
> Turning off GCOV "fixes" this. Not really the best solution but at
> least it narrows doen the search effort.
>
> Peter,
> Can you have a look at how this can be fixed, if at all?
I did some testing with a cross-compiler myself and I don't think
there is a general solution to this problem. It's not one particular
file that is causing the problem but seemingly the sheer size of the
resulting vmlinux file - even though the toal vmlinux.o size is
"merely" up about 100MiB (from around 1,03Gib to 1,13Gib).
I think I'll need help from people with knowledge of the powerpc
toolchain here.
Regards,
Peter
^ permalink raw reply
* Re: [BUILD-FAILURE] 2.6.27-rc1-mm1 - allyesconfig build fails on powerpc
From: Peter 1 Oberparleiter @ 2008-08-01 15:40 UTC (permalink / raw)
To: Andrew Morton
Cc: Kamalesh Babulal, linux-kernel, linuxppc-dev, Kernel Testers List,
Sam Ravnborg
In-Reply-To: <20080731231206.80940fba.akpm@linux-foundation.org>
Andrew Morton <akpm@linux-foundation.org> wrote on 01.08.2008 08:12:06:
> On Fri, 1 Aug 2008 15:29:36 +1000 Tony Breeds <tony@bakeyournoodle.com>
wrote:
> > On Thu, Jul 31, 2008 at 06:13:28PM +0530, Kamalesh Babulal wrote:
> > > Hi Andrew,
> > >
> > > make allyesconfig with 2.6.27-rc1-mm1 kernel on powerpc fails
> > > with build error
> >
> > <snip>
> >
> > Turning off GCOV "fixes" this. Not really the best solution but at
> > least it narrows doen the search effort.
>
> Thanks.
>
> > Peter,
> > Can you have a look at how this can be fixed, if at all?
> >
>
> Am not terribly happy with the state of the gcov patches. They STILL
> leave thousands of dead symlinks lying around after `make mrproper'
This is caused by patch
gcov-create-links-to-gcda-files-in-build-directory.patch
which can be simply removed as it is no longer needed since patch
gcov-add-gcov-profiling-infrastructure-revert-link-changes.patch
has been added to -mm.
> and
> generally seem to muck up the kbuild system a bit, although nothing
> that a bit of Sam love wouldn't fix.
Hm, by now the only change to kbuild is the addition of gcc options
-fprofile-arcs/-ftest-coverage depending on the respective config
symbols. If there is anything else that should be changed, please
let me know.
> Plus it breaks the build on a few architectures (branch out of range,
> mainly), but that's a fairly minor thing which could even be worked
> around in Kconfig (disable the offending code if gcov is enabled)
Some of the problems caused/uncovered by enabling gcov profiling for
a kernel build on some architectures simply cannot be fixed by a change
to the kernel patch itself. I'm wondering if it would be possible
to disable this configuration option when specifying allyesconfig. That
way at least generic testing wouldn't be affected.
Regards,
Peter
^ permalink raw reply
* Re: platforms/44x/warp-nand.c bogosity
From: Sean MacLennan @ 2008-08-01 15:41 UTC (permalink / raw)
To: Adrian Bunk; +Cc: linuxppc-dev, paulus, Stefan Roese
In-Reply-To: <20080801151401.GC24735@cs181140183.pp.htv.fi>
On Fri, 1 Aug 2008 18:14:01 +0300
"Adrian Bunk" <bunk@kernel.org> wrote:
> arch/powerpc/platforms/44x/warp-nand.c was added this year and
> updated quite recently.
>
> warp-nand.c is empty unless CONFIG_MTD_NAND_NDFC=y.
>
> MTD_NAND_NDFC depends on !PPC_MERGE.
>
> !PPC_MERGE can never be true on PPC now that arch/ppc/ got removed.
>
> So warp-nand.c is dead code, but that does not seem to be
> intentionally?
I use a local copy of ndfc.c that was modified to work with
arch/powerpc. I submitted the patch, but it was never accepted into the
kernel, and to be honest I don't remember why. I will look into this.
So the code is definitely not dead. You can't realistically run a warp
without the NAND.
Cheers,
Sean
^ permalink raw reply
* Re: platforms/44x/warp-nand.c bogosity
From: Valentine Barshak @ 2008-08-01 15:32 UTC (permalink / raw)
To: Josh Boyer
Cc: Adrian Bunk, linuxppc-dev, paulus, Sean MacLennan, Stefan Roese
In-Reply-To: <20080801112628.35fb0ff2@zod.rchland.ibm.com>
Josh Boyer wrote:
> On Fri, 1 Aug 2008 18:14:01 +0300
> Adrian Bunk <bunk@kernel.org> wrote:
>
>> arch/powerpc/platforms/44x/warp-nand.c was added this year and updated
>> quite recently.
>>
>> warp-nand.c is empty unless CONFIG_MTD_NAND_NDFC=y.
>>
>> MTD_NAND_NDFC depends on !PPC_MERGE.
>>
>> !PPC_MERGE can never be true on PPC now that arch/ppc/ got removed.
>>
>> So warp-nand.c is dead code, but that does not seem to be intentionally?
>
> I don't believe it is intentional, no. Sean can you look at this and
> see what's up? I have a couple of fixes to queue up from you already
> and if you can get this one done in the next few days I'll included it
> as well.
>
> josh
The current community ndfc driver won't build for arch/powerpc.
It still uses ioremap64 and includes <asm/ibm4xx.h> stuff.
Valentine.
^ permalink raw reply
* Re: platforms/44x/warp-nand.c bogosity
From: Josh Boyer @ 2008-08-01 15:26 UTC (permalink / raw)
To: Adrian Bunk; +Cc: linuxppc-dev, paulus, Sean MacLennan, Stefan Roese
In-Reply-To: <20080801151401.GC24735@cs181140183.pp.htv.fi>
On Fri, 1 Aug 2008 18:14:01 +0300
Adrian Bunk <bunk@kernel.org> wrote:
> arch/powerpc/platforms/44x/warp-nand.c was added this year and updated
> quite recently.
>
> warp-nand.c is empty unless CONFIG_MTD_NAND_NDFC=y.
>
> MTD_NAND_NDFC depends on !PPC_MERGE.
>
> !PPC_MERGE can never be true on PPC now that arch/ppc/ got removed.
>
> So warp-nand.c is dead code, but that does not seem to be intentionally?
I don't believe it is intentional, no. Sean can you look at this and
see what's up? I have a couple of fixes to queue up from you already
and if you can get this one done in the next few days I'll included it
as well.
josh
^ permalink raw reply
* platforms/44x/warp-nand.c bogosity
From: Adrian Bunk @ 2008-08-01 15:14 UTC (permalink / raw)
To: Sean MacLennan, Josh Boyer, Valentine Barshak, Stefan Roese,
mporter, paulus, benh
Cc: linuxppc-dev
arch/powerpc/platforms/44x/warp-nand.c was added this year and updated
quite recently.
warp-nand.c is empty unless CONFIG_MTD_NAND_NDFC=y.
MTD_NAND_NDFC depends on !PPC_MERGE.
!PPC_MERGE can never be true on PPC now that arch/ppc/ got removed.
So warp-nand.c is dead code, but that does not seem to be intentionally?
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
^ permalink raw reply
* Re: Board level compatibility matching
From: Josh Boyer @ 2008-08-01 15:11 UTC (permalink / raw)
To: Grant Likely; +Cc: devicetree-discuss, linuxppc-dev
In-Reply-To: <fa686aa40808010727v53fe3580q2813a12cb66f8f68@mail.gmail.com>
On Fri, 1 Aug 2008 08:27:41 -0600
"Grant Likely" <grant.likely@secretlab.ca> wrote:
> > NOT HAPPENING.
> >
> > Now, there are two approaches here that are possible:
> >
> > - Your board is really pretty much exactly the same as board XXX,
> > except maybe you have a different flash size or such, and the support
> > for board XXX can cope perfectly with it simply due to the device-tree
> > the right information.
> >
> > If that happens to be the case, make your board compatible with board
> > XXX. Make that entry -second- in your compatible list, because one day
> > you'll figure out that there -is- indeed a difference and I don't want
> > to see board XXX code start to grow code to recognise your other board
> > and work around the difference. So at that stage, copy board XXX.c file
> > and start over with your own board support that matches on your first
> > compatible propery entry.
>
> I agree with most of your argument, except I really have problems with
> boards claiming compatibility with an older board. My reason is
> exactly the reason you state; One day you'll figure out that there is
> indeed a difference. The problem is; when the original board (the one
> others are claiming compatibility with) gains additional code to fixup
> quirks or something, then that code will get changed with no
> visibility that it is borking up other boards that are currently
> depending on it.
There is that possibility yes. And it is even non-theoretical to a
degree, as the situation may occur with the existing Bamboo/Yosemite
scenario when we get around to fixing up the horror that is the EBC on
Bamboo. Admittedly, a single person did both those ports so the
inherent knowledge is already there, but that won't always be the case.
> I far prefer the solution I'm currently using in 5200-land where there
> is a simple (boring?) board port which *explicitly* states which
> boards it supports (see arch/powerpc/platforms/52xx/mpc5200_simple.c).
> When someone goes to modify that file, it is explicit that it
> currently supports multiple boards. If a board becomes 'non-boring',
> then it is removed from the simple platform; the simple platform is
> *not* extended to accommodate it.
To me, the solution you are using there seems like the best compromise
between the various options. It allows a common "board".c (or
platform) file in the kernel, while still adhering to a form of purity
in the device tree itself. The only slightly annoying issue is the
need to change the explicit list, but I don't consider that a burden
really.
If you haven't noticed, my primary reason for wanting to do _something_
is to prevent the proliferation of code duplication that we've seen.
Cleanup time is in order, and this is the most expedient and seemingly
correct way of doing things.
> I *fully* agree that it is insane for the code to grow detection logic
> and I've been explicit about not doing anything of the sort in 5200
> land. What I am suggesting is that if nothing else claims the board,
> then allow the simple platform to bind against it based on the fact
> that it uses the same SoC.
>
> However, if I can't get concensus on this approach, then I do /not/
> want to go to a boards compatible with other boards scheme. It will
> cause breakage and pain that is non-obvious to debug for many users.
I think there is too much momentum behind the old method, and not a
clear enough definition on how one would bind to a generic SoC without
dealing with things like link order, etc. Also, not every platform has
SoC nodes (as you already pointed out), and adding them to the DTS
files (or adding a new property or binding to the CPU node, etc) for
this purpose seems to be both overkill and contrary to not wanting to
break existing products out there that use the old DTS files and method.
They should be few in number, but they do exist (see PIKA Warp).
I'm growing very much of the opinion that the way you are _currently_
handling 52xx is more or less the way we should go.
josh
^ permalink raw reply
* Re: [i2c] [PATCH] powerpc: i2c-mpc: make speed registers configurable via FDT
From: Timur Tabi @ 2008-08-01 15:02 UTC (permalink / raw)
To: Jon Smirl; +Cc: Trent Piepho, Linuxppc-dev, Linux I2C, Scott Wood
In-Reply-To: <9e4733910807311844p142b26ffyb4105df3e136f65@mail.gmail.com>
Jon Smirl wrote:
> What about the Efika which is mpc5200 based and doesn't use uboot?
How does the Efika handle the dozen other properties that U-Boot normally
initializes in the device tree?
--
Timur Tabi
Linux Kernel Developer @ Freescale
^ permalink raw reply
* RE: Board is not booting - Please Help me
From: John Linn @ 2008-08-01 15:00 UTC (permalink / raw)
To: Grant Likely, Naresh Bhat; +Cc: linuxppc-embedded
In-Reply-To: <20080801023412.GA32426@secretlab.ca>
Hi Grant,
John Bonesio is working with Montavista to get these problems solved.
Thanks,
John
> -----Original Message-----
> From: linuxppc-embedded-bounces+john.linn=3Dxilinx.com@ozlabs.org
[mailto:linuxppc-embedded-
> bounces+john.linn=3Dxilinx.com@ozlabs.org] On Behalf Of Grant Likely
> Sent: Thursday, July 31, 2008 8:34 PM
> To: Naresh Bhat
> Cc: linuxppc-embedded@ozlabs.org
> Subject: Re: Board is not booting - Please Help me
> =
> On Wed, Jul 30, 2008 at 01:14:52PM +0530, Naresh Bhat wrote:
> > Hi Guys
> > I have ML507 board. By using "ml507_bsb_design_ppc440.zip"
> > I have created the "Base System Builder" project and also
> >
> > I am able to create the following files sucessfully.
> >
> > 1. My own "DTS" file (attached with the mail)
> > 2. My own "download.bit" file
> > 3. My own ACE file. (Used the Montavista Pro 5.0 kernel., Kernel is
compiled
> > with ARCH=3Dpowerpc, CROSS_COMPILE=3Dppc_440-, used the ml507_defconfig=
)
> =
> Unfortunately, I'm not able to help much with the Montavista kernel
> since I don't know anything about which version it is based on. Have
> you tried using the current mainline kernel source or Xilinx's
published
> git repo?
> =
> To use mainline, try copying your .dts file to
> arch/powerpc/boot/dts/virtex440-myml507.dts and then build the kernel
> with 'make simpleImage.virtex440-myml507'
> =
> g.
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
This email and any attachments are intended for the sole use of the named r=
ecipient(s) and contain(s) confidential information that may be proprietary=
, privileged or copyrighted under applicable law. If you are not the intend=
ed recipient, do not read, copy, or forward this email message or any attac=
hments. Delete this email message and any attachments immediately.
^ permalink raw reply
* Re: [i2c] [PATCH] powerpc: i2c-mpc: make speed registers configurable via FDT
From: Geert Uytterhoeven @ 2008-08-01 14:48 UTC (permalink / raw)
To: Trent Piepho; +Cc: Scott Wood, Timur Tabi, Linux I2C, Linuxppc-dev
In-Reply-To: <Pine.LNX.4.58.0807311742230.10341@shell4.speakeasy.net>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 713 bytes --]
On Thu, 31 Jul 2008, Trent Piepho wrote:
> The i2c controller just uses some system clock that was handy. For each
> chip, the designers consult tea leaves to choose a system clock at random
> to connect to the i2c controller.
Oh, they decided which clock to choose at design time, not at power-on time?
With kind regards,
Geert Uytterhoeven
Software Architect
Sony Techsoft Centre Europe
The Corporate Village · Da Vincilaan 7-D1 · B-1935 Zaventem · Belgium
Phone: +32 (0)2 700 8453
Fax: +32 (0)2 700 8622
E-mail: Geert.Uytterhoeven@sonycom.com
Internet: http://www.sony-europe.com/
A division of Sony Europe (Belgium) N.V.
VAT BE 0413.825.160 · RPR Brussels
Fortis 293-0376800-10 GEBA-BE-BB
^ permalink raw reply
* Re: [RFC][PATCH 0/8] kexec/kdump support for ppc32
From: Anton Vorontsov @ 2008-08-01 14:46 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <26A28837-B944-4CA6-83B5-5466CF1EDBF3@kernel.crashing.org>
On Fri, Aug 01, 2008 at 09:21:02AM -0500, Kumar Gala wrote:
>
> On Aug 1, 2008, at 9:13 AM, Anton Vorontsov wrote:
>
>> Hi all,
>>
>> I refreshed some Dale Farnsworth's kexec/kdump patches[1] against
>> the latest kernel, and here they are.
>>
>> There is a difference though. Dale's patches were using
>> kmap_atomic_pfn() to map oldmem memory, while for this patches
>> I took PPC64 approach to use ioremap(). This is done to be able
>> to support kdump on !HIGHMEM kernels.
>>
>> Also, please take a special look into 8/8 patch, there is a hunk
>> marked with "XXX:", which I don't quite understand for PPC64 case
>> (this hunk also persist in the original Dale's patch, and w/o it
>> the capturing kernel doesn't boot on ppc32).
>>
>> I'll try to refresh BookE support as soon as I'll find some BookE
>> board.
>>
>> The patchset includes:
>>
>> - Kexec support
>>
>> [PATCH 1/8] powerpc: set up OF properties for ppc32 kexec
>> [PATCH 2/8] powerpc: make default kexec/crash_kernel ops implicit
>> [PATCH 3/8] powerpc: remove default kexec/crash_kernel ops
>> assignments
>>
>> 2/8 and 3/8 patches are used to avoid adding lots of default ops
>> to the board files.
>>
>> - Kdump support
>>
>> [PATCH 4/8] powerpc: add the ability for a classic ppc kernel to be
>> loaded at 32M
>> [PATCH 5/8] powerpc: allow to ioremap RAM addresses for kdump kernel
>> on ppc32
>> [PATCH 6/8] powerpc: set up OF properties for ppc32 kdump
>> [PATCH 7/8] powerpc: implement crash_setup_regs for ppc32
>> [PATCH 8/8] powerpc: last bits to support kdump on ppc32
>>
>> [1] http://ozlabs.org/pipermail/linuxppc-dev/2007-November/046739.html
>
> What's the state of the kexec tools for ppc32?
Current kexec-tools has split arch support, and ppc32 is officially
broken.
I use some old (20070330), patched kexec-tools with ppc32/ and ppc64/
merged into powerpc (alike to Linux).
I hope one day I (or somebody else) will find time to cleanup or
re-do the patches for the recent kexec-tools, and merge them after
all.
Though, I didn't look into the patches themselves yet, so I can't
tell how much work is pending.
--
Anton Vorontsov
email: cbouatmailru@gmail.com
irc://irc.freenode.net/bd2
^ permalink raw reply
* Re: Board level compatibility matching
From: Grant Likely @ 2008-08-01 14:30 UTC (permalink / raw)
To: Josh Boyer; +Cc: devicetree-discuss, linuxppc-dev
In-Reply-To: <20080801080632.35edcb04@zod.rchland.ibm.com>
On Fri, Aug 1, 2008 at 6:06 AM, Josh Boyer <jwboyer@linux.vnet.ibm.com> wrote:
> On Fri, 01 Aug 2008 14:25:39 +1000
> Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
>
>> About this whole generic board mumbo-jumbo: not happening. It's a pipe
>> dream, it doesn't work, and it leads to the sort of mess we have in chrp
>> where we end up having hacks to identify what exact sort of chrp we have
>> and do things differently etc...
>>
>> NOT HAPPENING.
>>
>> Now, there are two approaches here that are possible:
>>
>> - Your board is really pretty much exactly the same as board XXX,
>> except maybe you have a different flash size or such, and the support
>> for board XXX can cope perfectly with it simply due to the device-tree
>> the right information.
>>
>> If that happens to be the case, make your board compatible with board
>> XXX. Make that entry -second- in your compatible list, because one day
>> you'll figure out that there -is- indeed a difference and I don't want
>> to see board XXX code start to grow code to recognise your other board
>> and work around the difference. So at that stage, copy board XXX.c file
>> and start over with your own board support that matches on your first
>> compatible propery entry.
>
> 44x does this today for a small number of boards. The "issue", if
> there really is one, is that there's no clear definition on what is
> acceptable to be called "compatible". If _Linux_ platform support for
> board FOO
As stated in my previous email; I dislike this approach. I far prefer
making the board support code provide an explicit list rather than
trying to define what it means for one board to be compatible with
another.
>> I have no objection of having something like for each ppc_md field
>> called X, having a utility file providing an mpc52xx_generic_X function.
>> Such a board could then basically have a small .c file whose ppc_md just
>> use the generic functions for all except the ones that need to be
>> hooked/wrapped/replaced/whatever.
>
> This is sort of the part that sucks. Look at 44x. There are 10
> board.c files there. There really only needs to be 3 or 4 (sam440ep,
> warp, virtex, and "generic") because the board files are identical in
> everything except name. By doing the library code approach, one still
> has to create a board.c file for a new board and plug in the library
> functions to ppc_md.
>
> Alternatively, you could do the:
>
> compatible = "specific-board", "similar-board"
>
> approach that has been done for e.g. Bamboo and Yosemite. Again, the
> issue is that is that OK? Is it OK for a board to claim compatibility
> with another board when it might not have all the devices of that
> board, or might have additional devices, etc. I was of the opinion
> it is, and the device tree handles this just fine, as does the platform
> code. But it can be confusing, hence the discussion here.
I say no [but you already know that. :-) ]
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: Board level compatibility matching
From: Grant Likely @ 2008-08-01 14:27 UTC (permalink / raw)
To: benh; +Cc: linuxppc-dev, devicetree-discuss
In-Reply-To: <1217564739.11188.482.camel@pasglop>
On Thu, Jul 31, 2008 at 10:25 PM, Benjamin Herrenschmidt
<benh@kernel.crashing.org> wrote:
> About this whole generic board mumbo-jumbo: not happening. It's a pipe
> dream, it doesn't work, and it leads to the sort of mess we have in chrp
> where we end up having hacks to identify what exact sort of chrp we have
> and do things differently etc...
I am fully aware of the hell and hacks that went along with chrp. I
am *not* suggesting a do everything platform that must figure out all
the quirks of a board in a single machine definition. I know too well
that is the way of pain.
>
> NOT HAPPENING.
>
> Now, there are two approaches here that are possible:
>
> - Your board is really pretty much exactly the same as board XXX,
> except maybe you have a different flash size or such, and the support
> for board XXX can cope perfectly with it simply due to the device-tree
> the right information.
>
> If that happens to be the case, make your board compatible with board
> XXX. Make that entry -second- in your compatible list, because one day
> you'll figure out that there -is- indeed a difference and I don't want
> to see board XXX code start to grow code to recognise your other board
> and work around the difference. So at that stage, copy board XXX.c file
> and start over with your own board support that matches on your first
> compatible propery entry.
I agree with most of your argument, except I really have problems with
boards claiming compatibility with an older board. My reason is
exactly the reason you state; One day you'll figure out that there is
indeed a difference. The problem is; when the original board (the one
others are claiming compatibility with) gains additional code to fixup
quirks or something, then that code will get changed with no
visibility that it is borking up other boards that are currently
depending on it.
I far prefer the solution I'm currently using in 5200-land where there
is a simple (boring?) board port which *explicitly* states which
boards it supports (see arch/powerpc/platforms/52xx/mpc5200_simple.c).
When someone goes to modify that file, it is explicit that it
currently supports multiple boards. If a board becomes 'non-boring',
then it is removed from the simple platform; the simple platform is
*not* extended to accommodate it.
I *fully* agree that it is insane for the code to grow detection logic
and I've been explicit about not doing anything of the sort in 5200
land. What I am suggesting is that if nothing else claims the board,
then allow the simple platform to bind against it based on the fact
that it uses the same SoC.
However, if I can't get concensus on this approach, then I do /not/
want to go to a boards compatible with other boards scheme. It will
cause breakage and pain that is non-obvious to debug for many users.
BTW, I am also not suggesting that the .dts files themselves try to
claim some kind of 'generic' compatibility. I'm proposing handling
any catch-all cases in the Linux code itself, where it is easy to
change because it is just an implementation detail. Trying to make
the dt 'generic' doesn't make any sense because doing so is almost
always wrong (or will become wrong in the future).
> - Once you figure out that really, those 5 boards here -do- share 99%
> of the code... it's just that one need a workaround at the IRQ fixup
> level, maybe one needs a tweak on a GPIO at boot and one has an issue on
> reboot that needs to be whacked a bit differently ... well, make
> -library- code.
>
> I have no objection of having something like for each ppc_md field
> called X, having a utility file providing an mpc52xx_generic_X function.
> Such a board could then basically have a small .c file whose ppc_md just
> use the generic functions for all except the ones that need to be
> hooked/wrapped/replaced/whatever.
I agree. 5200 code already does this.
g.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox