Re: [PATCH] [POWERPC] Fix typo #ifdef - #ifndef
On Sat, 03 Nov 2007 20:16:36 +0100 Jochen Friedrich [EMAIL PROTECTED] wrote: Subject: [PATCH] [POWERPC] Fix typo #ifdef - #ifndef Please put the powerpc outside the []. Because things inside [] get removed when the receiver applies the patch, but the subsystem identification (powerpc) is useful information which we want to carry into the permanent git record. (Although Paul might add it anyway - some git tree maintainers do). User-Agent: Mozilla-Thunderbird 2.0.0.6 (X11/20071009) This seems to be setting a record for MUA vandalism. Leading spaces were removed and various esoteric whitespace transformations were made. The diffs were small so I fixed them by hand. Please strangle your email client. ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: [Bugme-new] [Bug 8778] New: Ocotea board: kernel reports access of bad area during boot with DEBUG_SLAB=y
On Wed, 18 Jul 2007 00:07:50 -0700 (PDT) [EMAIL PROTECTED] wrote: http://bugzilla.kernel.org/show_bug.cgi?id=8778 Summary: Ocotea board: kernel reports access of bad area during boot with DEBUG_SLAB=y Product: Platform Specific/Hardware Version: 2.5 KernelVersion: 2.6.22 Platform: All OS/Version: Linux Tree: Mainline Status: NEW Severity: normal Priority: P1 Component: PPC-32 AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] Most recent kernel where this bug did not occur: not known - was probably already an issue in 2.6.10 Distribution: not relevant for this issue. Hardware Environment: AMCC Ocotea board Software Environment: not relevant for this issue. Problem Description: see title. Steps to reproduce: 1. Compile the 2.6.22 kernel with the attached .config 2. Boot an Ocotea board with this kernel. 3. Observe the output that appears on the serial console. U-Boot 1.1.1 (Nov 10 2005 - 16:29:34) IBM PowerPC 440 GUNKNOWN (PVR=51b21892) Board: IBM 440GX Evaluation Board VCO: 1066 MHz CPU: 533 MHz PLB: 152 MHz OPB: 76 MHz EPB: 76 MHz I2C: ready DRAM: I2c read: failed 4 I2c read: failed 4 256 MB FLASH: 5 MB PCI: Bus Dev VenId DevId Class Int In:serial Out: serial Err: serial KGDB: kgdb ready ready Net: ppc_440x_eth0 BEDBUG:ready = boot Waiting for PHY auto negotiation to complete.. done ENET Speed is 100 Mbps - FULL duplex connection Using ppc_440x_eth0 device TFTP from server 172.30.36.154; our IP address is 172.30.39.77 Filename 'ocotea-vanassb'. Load address: 0x100 Loading: T # # # # # done Bytes transferred = 1415440 (159910 hex) Automatic boot of image at addr 0x0100 ... ## Booting image at 0100 ... Image Name: Linux-2.6.22 Created: 2007-07-18 6:53:56 UTC Image Type: PowerPC Linux Kernel Image (gzip compressed) Data Size:1415376 Bytes = 1.3 MB Load Address: Entry Point: Verifying Checksum ... OK Uncompressing Kernel Image ... OK Linux version 2.6.22 ([EMAIL PROTECTED]) (gcc version 3.4.3 (MontaVista 3.4.7 IBM Ocotea port (MontaVista Software, Inc. [EMAIL PROTECTED]) Zone PFN ranges: DMA 0 -65536 Normal 65536 -65536 early_node_map[1] active PFN ranges 0:0 -65536 Built 1 zonelists. Total pages: 65024 Kernel command line: root=/dev/nfs nfsroot=172.30.36.154:/nfs-export/RFS_MVL4-00 PID hash table entries: 1024 (order: 10, 4096 bytes) | Locking API testsuite: | spin |wlock |rlock |mutex | wsem | rsem | -- A-A deadlock:failed|failed| ok |failed|failed|failed| A-B-B-A deadlock:failed|failed| ok |failed|failed|failed| A-B-B-C-C-A deadlock:failed|failed| ok |failed|failed|failed| A-B-C-A-B-C deadlock:failed|failed| ok |failed|failed|failed| A-B-B-C-C-D-D-A deadlock:failed|failed| ok |failed|failed|failed| A-B-C-D-B-D-D-A deadlock:failed|failed| ok |failed|failed|failed| A-B-C-D-B-C-D-A deadlock:failed|failed| ok |failed|failed|failed| double unlock: ok | ok |failed| ok |failed|failed| initialize held:failed|failed|failed|failed|failed|failed| bad unlock order: ok | ok | ok | ok | ok | ok | -- recursive read-lock: | ok | |failed| recursive read-lock #2: | ok | |failed| mixed read-write-lock: |failed| |failed| mixed write-read-lock: |failed| |failed| -- hard-irqs-on + irq-safe-A/12:failed|failed| ok | soft-irqs-on + irq-safe-A/12:failed|failed| ok | hard-irqs-on + irq-safe-A/21:failed|failed| ok | soft-irqs-on + irq-safe-A/21:failed|failed| ok | sirq-safe-A = hirqs-on/12:failed|failed| ok | sirq-safe-A = hirqs-on/21:failed|failed| ok | hard-safe-A + irqs-on/12:failed|failed| ok | soft-safe-A + irqs-on/12:failed|failed| ok |
Re: [Bugme-new] [Bug 8778] New: Ocotea board: kernel reports access of bad area during boot with DEBUG_SLAB=y
On Wed, 18 Jul 2007 08:59:40 -0700 Eugene Surovegin [EMAIL PROTECTED] wrote: On Wed, Jul 18, 2007 at 08:41:10AM -0500, Josh Boyer wrote: On Wed, 2007-07-18 at 01:34 -0700, Eugene Surovegin wrote: On Wed, Jul 18, 2007 at 12:52:53AM -0700, Andrew Morton wrote: On Wed, 18 Jul 2007 00:07:50 -0700 (PDT) [EMAIL PROTECTED] wrote: http://bugzilla.kernel.org/show_bug.cgi?id=8778 Summary: Ocotea board: kernel reports access of bad area during boot with DEBUG_SLAB=y Slab debugging is probably the culprit here. I had similar problem couple of years ago, not sure something has changed since then, haven't checked. When slab debugging was enabled it made memory allocations non L1 cache line aligned. This is very bad for DMA on non-coherent cache arches (PPC440 is one of those archs). I have a hack for EMAC which tries to workaround this problem: http://kernel.ebshome.net/emac_slab_debug.diff which might help. Would you be opposed to including that patch in mainline? Yes. I don't think it's the right way to fix this issue. IMO, the right one is to fix slab allocator. You cannot change all drivers to do this kind of cache flushing, and yes, I saw the same problem with PCI based NIC I tried on Ocotea at the time. hm. It should be the case that providing SLAB_HWCACHE_ALIGN at kmem_cache_create() time will override slab-debugging's offsetting of the returned addresses. Or is the problem occurring with memory which is returned from kmalloc(), rather than from kmem_cache_alloc()? A complete description of the problem would help here, please. ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
[PATCH] ppc32: fix perf_irq extern on e500
Matt Porter mporter at kernel.crashing.org wrote:
Add an extern reference to perf_irq on e500.
Signed-off-by: Matt Porter mporter at kernel.crashing.org
diff --git a/arch/ppc/kernel/traps.c b/arch/ppc/kernel/traps.c
index 16adde6..ff1bdc2 100644
--- a/arch/ppc/kernel/traps.c
+++ b/arch/ppc/kernel/traps.c
@@ -888,6 +888,8 @@ void altivec_assist_exception(struct pt_
#endif /* CONFIG_ALTIVEC */
#ifdef CONFIG_E500
+extern perf_irq_t perf_irq;
+
void performance_monitor_exception(struct pt_regs *regs)
{
perf_irq(regs);
extern decls are placed in header files, please.
[PATCH] ppc32: Added support for the Book-E style Watchdog Timer
Kumar Gala galak at freescale.com wrote:
PowerPC 40x and Book-E processors support a watchdog timer at the processor
core level. The timer has implementation dependent timeout frequencies
that can be configured by software.
One the first Watchdog timeout we get a critical exception. It is left
to board specific code to determine what should happen at this point. If
nothing is done and another timeout period expires the processor may
attempt to reset the machine.
Command line parameters:
wdt=0 : disable watchdog (default)
wdt=1 : enable watchdog
wdt_period=N : N sets the value of the Watchdog Timer Period.
The Watchdog Timer Period meaning is implementation specific. Check
User Manual for the processor for more details.
This patch is based off of work done by Takeharu Kato.
...
+#ifdef CONFIG_BOOKE_WDT
+/* Checks wdt=x and wdt_period=xx command-line option */
+int __init early_parse_wdt(char *p)
+{
+ extern u32 wdt_enable;
+
+ if (p strncmp(p, 0, 1) != 0)
+wdt_enable = 1;
+
+ return 0;
+}
+early_param(wdt, early_parse_wdt);
+
+int __init early_parse_wdt_period (char *p)
+{
+ extern u32 wdt_period;
+
+ if (p)
+ wdt_period = simple_strtoul(p, NULL, 0);
+
+ return 0;
+}
Would prefer to see the declaration of wdt_period in a header file, please.
But beware that wdt_enable() is already a static symbol in a couple of
watchdog drivers. It might be best to rename the ppc global to something
less generic-sounding while you're there.
[PATCH] ppc32: fix ppc440 pagetable attributes
Matt Porter mporter at kernel.crashing.org wrote: This patch fixes a bug in the PPC440 pagetable attributes that breaks swap support. It also adds some notes on the PPC440 attribute fields. hm, that looks pretty serious, but it affects all ppc's, yes? Is this needed for 2.6.13? Are you super-sure it's safe?
[PATCH 00/14] ppc32: Remove board ports that are no longer maintained
Kumar Gala galak at freescale.com wrote: The following board ports are no longer maintained or have become obsolete: adir ash beech cedar ep405 k2 mcpn765 menf1 oak pcore rainier redwood sm850 spd823ts We are there for removing support for them. I'll merge all these into -mm for now, but will hold off sending any of them upstream pending confirmation of which patches we really want to proceed with.
[PATCH][1/3] ppc32: add 440ep support
Matt Porter mporter at kernel.crashing.org wrote: +static u64 dma_mask = 0xULL; I'm sure you're totally uninterested in this, but the above will probably generate warnings on (say) ppc64, where u64 is implemented as unsigned long. I usually chuck a simple `-1' in there and the compiler always gets it right, regardless of signedness and size and architecture.
[PATCH][1/3] ppc32: add 440ep support
Paul Mackerras paulus at samba.org wrote: Andrew Morton writes: Matt Porter mporter at kernel.crashing.org wrote: +static u64 dma_mask = 0xULL; I'm sure you're totally uninterested in this, but the above will probably generate warnings on (say) ppc64, where u64 is implemented as unsigned long. I usually chuck a simple `-1' in there and the compiler always gets it right, regardless of signedness and size and architecture. Umm, I think we actually want 2^32-1 not -1, don't we? Doh. Cant coun't.
[PATCH] ppc32: add 405EP cpu_spec entry
Linus Torvalds torvalds at osdl.org wrote: On Fri, 10 Jun 2005, Kumar Gala wrote: You have applied this patch twice now. Actually, looks like three times ;) Crap, sorry, that's happened three times now... hmm.. I think Andrew continually thinks it is dropped, because the patch ends up applying again, even though it got applied. So he keeps on re-sending it over and over again ;) Fault-tolerance!
[PATCH] cpm_uart: Route SCC2 pins for the STx GP3 board
Matt Porter mporter at kernel.crashing.org wrote:
+++ uncommitted/drivers/serial/cpm_uart/cpm_uart_cpm2.c (mode:100644)
@@ -134,12 +134,21 @@
void scc2_lineif(struct uart_cpm_port *pinfo)
{
+ /*
+ * STx GP3 uses the SCC2 secondary option pin assignment
+ * which this driver doesn't account for in the static
+ * pin assignments. This kind of board specific info
+ * really has to get out of the driver so boards can
+ * be supported in a sane fashion.
+ */
+#ifndef CONFIG_STX_GP3
volatile iop_cpm2_t *io = cpm2_immr-im_ioport;
io-iop_pparb |= 0x008b;
Silly question: why is this driver using a volatile pointer to
memory-mapped I/O rather than readl and writel?
[PATCH 2.6.12-rc2 2/2] ppc32: add rtc hooks in PPC7D platform file
Chris Elston chris.elston at radstone.co.uk wrote: This patch adds the hooks into the PPC7D platforms file to support the DS1337 RTC device as the clock device for the PPC7D board. The attachment has all sorts of binary microsofty gunk in it.
[PATCH] ppc32: Report chipset version in common /proc/cpuinfo handling
Kumar Gala galak at freescale.com wrote: Moved reporting of chipset revision from board specific to common handing of /proc/cpuinfo. In light of numerous PPC system-on-chip devices, we report both the cpu version (reflects the core version) and the chipset version (reflects the system-on-chip or bridge version). This breaks the ppc32 build with my .config. CC arch/ppc/kernel/setup.o In file included from arch/ppc/kernel/setup.c:43: include/asm/ppc_sys.h:29:2: #error need definition of ppc_sys_devices In file included from arch/ppc/kernel/setup.c:43: include/asm/ppc_sys.h:61: warning: parameter has incomplete type include/asm/ppc_sys.h:64: warning: parameter has incomplete type I'll include the patch in -mm anyway. Please send a fix. # # Automatically generated make config: don't edit # Linux kernel version: 2.6.12-rc1-mm2 # Thu Mar 24 02:18:29 2005 # CONFIG_MMU=y CONFIG_GENERIC_HARDIRQS=y CONFIG_RWSEM_XCHGADD_ALGORITHM=y CONFIG_GENERIC_CALIBRATE_DELAY=y CONFIG_HAVE_DEC_LOCK=y CONFIG_PPC=y CONFIG_PPC32=y CONFIG_GENERIC_NVRAM=y # # Code maturity level options # CONFIG_EXPERIMENTAL=y CONFIG_CLEAN_COMPILE=y CONFIG_LOCK_KERNEL=y # # General setup # CONFIG_LOCALVERSION= CONFIG_SWAP=y CONFIG_SYSVIPC=y CONFIG_POSIX_MQUEUE=y CONFIG_BSD_PROCESS_ACCT=y CONFIG_BSD_PROCESS_ACCT_V3=y CONFIG_SYSCTL=y CONFIG_AUDIT=y CONFIG_HOTPLUG=y CONFIG_KOBJECT_UEVENT=y CONFIG_IKCONFIG=y CONFIG_IKCONFIG_PROC=y # CONFIG_CPUSETS is not set CONFIG_EMBEDDED=y CONFIG_KALLSYMS=y CONFIG_KALLSYMS_ALL=y CONFIG_KALLSYMS_EXTRA_PASS=y CONFIG_BASE_FULL=y CONFIG_FUTEX=y CONFIG_EPOLL=y CONFIG_CC_OPTIMIZE_FOR_SIZE=y CONFIG_SHMEM=y CONFIG_CC_ALIGN_FUNCTIONS=0 CONFIG_CC_ALIGN_LABELS=0 CONFIG_CC_ALIGN_LOOPS=0 CONFIG_CC_ALIGN_JUMPS=0 # CONFIG_TINY_SHMEM is not set CONFIG_BASE_SMALL=0 # # Loadable module support # CONFIG_MODULES=y CONFIG_MODULE_UNLOAD=y CONFIG_MODULE_FORCE_UNLOAD=y CONFIG_OBSOLETE_MODPARM=y CONFIG_MODVERSIONS=y CONFIG_MODULE_SRCVERSION_ALL=y CONFIG_KMOD=y CONFIG_STOP_MACHINE=y # # Processor # CONFIG_6xx=y # CONFIG_40x is not set # CONFIG_44x is not set # CONFIG_POWER3 is not set # CONFIG_POWER4 is not set # CONFIG_8xx is not set # CONFIG_E500 is not set CONFIG_ALTIVEC=y CONFIG_TAU=y CONFIG_TAU_INT=y CONFIG_TAU_AVERAGE=y CONFIG_CPU_FREQ=y CONFIG_CPU_FREQ_TABLE=m CONFIG_CPU_FREQ_DEBUG=y CONFIG_CPU_FREQ_STAT=m CONFIG_CPU_FREQ_STAT_DETAILS=y CONFIG_CPU_FREQ_DEFAULT_GOV_PERFORMANCE=y # CONFIG_CPU_FREQ_DEFAULT_GOV_USERSPACE is not set CONFIG_CPU_FREQ_GOV_PERFORMANCE=y CONFIG_CPU_FREQ_GOV_POWERSAVE=m CONFIG_CPU_FREQ_GOV_USERSPACE=m CONFIG_CPU_FREQ_GOV_ONDEMAND=m # CONFIG_CPU_FREQ_PMAC is not set CONFIG_PPC601_SYNC_FIX=y CONFIG_PM=y CONFIG_PPC_STD_MMU=y # # Platform options # CONFIG_PPC_MULTIPLATFORM=y # CONFIG_APUS is not set # CONFIG_KATANA is not set # CONFIG_WILLOW is not set # CONFIG_CPCI690 is not set # CONFIG_PCORE is not set # CONFIG_POWERPMC250 is not set # CONFIG_CHESTNUT is not set # CONFIG_SPRUCE is not set # CONFIG_HDPU is not set # CONFIG_EV64260 is not set # CONFIG_LOPEC is not set # CONFIG_MCPN765 is not set # CONFIG_MVME5100 is not set # CONFIG_PPLUS is not set # CONFIG_PRPMC750 is not set # CONFIG_PRPMC800 is not set # CONFIG_SANDPOINT is not set # CONFIG_RADSTONE_PPC7D is not set # CONFIG_ADIR is not set # CONFIG_K2 is not set # CONFIG_PAL4 is not set # CONFIG_GEMINI is not set # CONFIG_EST8260 is not set # CONFIG_SBC82xx is not set # CONFIG_SBS8260 is not set # CONFIG_RPX8260 is not set # CONFIG_TQM8260 is not set # CONFIG_ADS8272 is not set # CONFIG_PQ2FADS is not set # CONFIG_LITE5200 is not set # CONFIG_MPC834x_SYS is not set CONFIG_PPC_CHRP=y CONFIG_PPC_PMAC=y CONFIG_PPC_PREP=y CONFIG_PPC_OF=y CONFIG_PPCBUG_NVRAM=y CONFIG_SMP=y CONFIG_IRQ_ALL_CPUS=y CONFIG_NR_CPUS=4 CONFIG_PREEMPT=y CONFIG_HIGHMEM=y CONFIG_BINFMT_ELF=y CONFIG_BINFMT_MISC=m CONFIG_PROC_DEVICETREE=y CONFIG_PREP_RESIDUAL=y CONFIG_PROC_PREPRESIDUAL=y CONFIG_CMDLINE_BOOL=y CONFIG_CMDLINE=console=ttyS0,9600 console=tty0 root=/dev/sda2 # CONFIG_PM_DEBUG is not set # CONFIG_SOFTWARE_SUSPEND is not set # # Bus options # CONFIG_ISA=y CONFIG_GENERIC_ISA_DMA=y CONFIG_PCI=y CONFIG_PCI_DOMAINS=y CONFIG_PCI_LEGACY_PROC=y CONFIG_PCI_NAMES=y # # PCCARD (PCMCIA/CardBus) support # CONFIG_PCCARD=m CONFIG_PCMCIA_DEBUG=y CONFIG_PCMCIA=m CONFIG_CARDBUS=y # # PC-card bridges # CONFIG_YENTA=m CONFIG_PD6729=m CONFIG_I82092=m CONFIG_I82365=m CONFIG_TCIC=m CONFIG_PCMCIA_PROBE=y CONFIG_PCCARD_NONSTATIC=m # # Advanced setup # CONFIG_ADVANCED_OPTIONS=y CONFIG_HIGHMEM_START_BOOL=y CONFIG_HIGHMEM_START=0xfe00 CONFIG_LOWMEM_SIZE_BOOL=y CONFIG_LOWMEM_SIZE=0x3000 CONFIG_KERNEL_START_BOOL=y CONFIG_KERNEL_START=0xc000 CONFIG_TASK_SIZE_BOOL=y CONFIG_TASK_SIZE=0x8000 CONFIG_BOOT_LOAD=0x0080 # # Device Drivers # # # Generic Driver Options # CONFIG_STANDALONE=y CONFIG_PREVENT_FIRMWARE_BUILD=y CONFIG_FW_LOADER=m CONFIG_DEBUG_DRIVER=y # # Connector - unified userspace - kernelspace linker # # CONFIG_CONNECTOR is not set # # Memory Technology
[PATCH 2.6.12] ppc32: Fix mv64x60 internal SRAM size
Mark A. Greer mgreer at mvista.com wrote: ppc32: Fix wrong size for mv64[34]60's internal SRAM. This got a reject against other ppc32 patches which I had (they've all just been flushed to Linus). The reject was in arch/ppc/Kconfig. Please check that I fixed it up correctly. From: Mark A. Greer [EMAIL PROTECTED] ppc32: Fix wrong size for mv64[34]60's internal SRAM. - Fix incorrect SRAM size - Minor Kconfig cleanups for mv64x60 platforms Signed-off-by: Mark A. Greer mgreer at mvista.com Signed-off-by: Andrew Morton akpm at osdl.org --- 25-akpm/arch/ppc/Kconfig | 10 ++ 25-akpm/arch/ppc/platforms/chestnut.h |4 ++-- 25-akpm/arch/ppc/platforms/katana.h|2 +- 25-akpm/include/asm-ppc/mv64x60_defs.h |2 +- 4 files changed, 6 insertions(+), 12 deletions(-) diff -puN arch/ppc/Kconfig~ppc32-fix-mv64x60-internal-sram-size arch/ppc/Kconfig --- 25/arch/ppc/Kconfig~ppc32-fix-mv64x60-internal-sram-size2005-03-18 13:41:27.0 -0800 +++ 25-akpm/arch/ppc/Kconfig2005-03-18 13:42:57.0 -0800 @@ -577,7 +577,6 @@ config SANDPOINT config RADSTONE_PPC7D bool Radstone Technology PPC7D board - select MV64360 config ADIR bool SBS-Adirondack @@ -753,16 +752,11 @@ config GT64260 depends on EV64260 || CPCI690 default y -config MV64360 +config MV64360 # Really MV64360 MV64460 bool - depends on KATANA || RADSTONE_PPC7D || HDPU + depends on CHESTNUT || KATANA || RADSTONE_PPC7D || HDPU default y -config MV64360 - bool - depends on CHESTNUT - default y - config MV64X60 bool depends on (GT64260 || MV64360) diff -puN arch/ppc/platforms/chestnut.h~ppc32-fix-mv64x60-internal-sram-size arch/ppc/platforms/chestnut.h --- 25/arch/ppc/platforms/chestnut.h~ppc32-fix-mv64x60-internal-sram-size 2005-03-18 13:41:27.0 -0800 +++ 25-akpm/arch/ppc/platforms/chestnut.h 2005-03-18 13:41:27.0 -0800 @@ -28,8 +28,8 @@ *0xffd0-0xffd4 - CPLD *0xffc0-0xffcf - UART *0xffb0-0xffb07fff - FRAM - *0xffa0-0xffaf - *** HOLE *** - *0xff80-0xff9f - MV64460 Integrated SRAM + *0xff84-0xffaf - *** HOLE *** + *0xff80-0xff83 - MV64460 Integrated SRAM *0xfe00-0xff8f - *** HOLE *** *0xfc00-0xfdff - 32bit Flash *0xf101-0xfbff - *** HOLE *** diff -puN arch/ppc/platforms/katana.h~ppc32-fix-mv64x60-internal-sram-size arch/ppc/platforms/katana.h --- 25/arch/ppc/platforms/katana.h~ppc32-fix-mv64x60-internal-sram-size 2005-03-18 13:41:27.0 -0800 +++ 25-akpm/arch/ppc/platforms/katana.h 2005-03-18 13:41:27.0 -0800 @@ -24,7 +24,7 @@ * on a boundary that is a multiple of the window size): * *0xff80-0x - Boot window - *0xf840-0xf85f - Internal SRAM + *0xf840-0xf843 - Internal SRAM *0xf820-0xf83f - CPLD *0xf810-0xf810 - MV64360 Registers (CONFIG_MV64X60_NEW_BASE) *0xf800-0xf80f - Socketed FLASH diff -puN include/asm-ppc/mv64x60_defs.h~ppc32-fix-mv64x60-internal-sram-size include/asm-ppc/mv64x60_defs.h --- 25/include/asm-ppc/mv64x60_defs.h~ppc32-fix-mv64x60-internal-sram-size 2005-03-18 13:41:27.0 -0800 +++ 25-akpm/include/asm-ppc/mv64x60_defs.h 2005-03-18 13:41:27.0 -0800 @@ -347,7 +347,7 @@ #defineMV64360_SRAM_ERR_DATA_HI0x03a0 #defineMV64360_SRAM_ERR_PARITY 0x03a8 -#defineMV64360_SRAM_SIZE 0x0020 /* 2 MB of SRAM */ +#defineMV64360_SRAM_SIZE 0x0004 /* 2Mb/256KB SRAM */ /* * _
[PATCH 2.6.11] ppc32: update Radstone ppc7d platform
Mark A. Greer mgreer at mvista.com wrote:
+ppc7d_fixup_i2c_pdata(struct platform_device *pdev)
+{
+struct mv64xxx_i2c_pdata *pdata;
+int i;
+
+pdata = pdev-dev.platform_data;
+if (pdata == NULL) {
+pdata = kmalloc(GFP_KERNEL, sizeof(*pdata));
I'll switch those kmalloc args around for you.
[PATCH][PPC32] Performance Monitor/Oprofile support for e500
Kumar Gala galak at linen.sps.mot.com wrote: Andrew, Adds oprofile support for the e500 PowerPC core. - arch/ppc/kernel/perfmon_fsl_booke.c has prototypes for init_pmc_stop() and friends, but those prototypes are already in include/asm-ppc/perfmon.h - please don't put prototypes and extern declarations in .c files. Ever. It defeats typechecking. Put them in a header file which is visible to all callers/users as well as to the implementation. - Do these need to be exported to modules? +EXPORT_SYMBOL(init_pmc_stop); +EXPORT_SYMBOL(set_pmc_event); +EXPORT_SYMBOL(set_pmc_user_kernel); +EXPORT_SYMBOL(set_pmc_marked); +EXPORT_SYMBOL(pmc_start_ctr); +EXPORT_SYMBOL(pmc_start_ctrs); +EXPORT_SYMBOL(pmc_stop_ctrs); +EXPORT_SYMBOL(dump_pmcs); and if so, does an EXPORT_SYMBOL_GPL() not suffice? - This: +extern void (*perf_irq)(struct pt_regs *); should be in a header file. I'll queue the patch up. Fixups relative to this patch would be appreciated, thanks.
[PATCH][PPC32] Marvell host bridge support (mv64x60)
Mark A. Greer mgreer at mvista.com wrote: Andrew Morton wrote: Anyway, I'll stick this as-is in -mm. Feel free to send an incremental patch, or a replacement. Here is an incremental patch [hopefully] with your concerns addressed. OK, thanks. I added this to the queue for post-2.6.10. I'll assume that silence means assent from the rest of the ppc team ;) (Patches are at ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.10-rc2/2.6.10-rc2-mm3/broken-out/ppc32-marvell-host-bridge-support-mv64x60.patch ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.10-rc2/2.6.10-rc2-mm3/broken-out/ppc32-support-for-marvell-ev-64260-bp-eval-platform.patch ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.10-rc2/2.6.10-rc2-mm3/broken-out/ppc32-support-for-artesyn-katana-cpci-boards.patch
[PATCH][PPC32] Marvell host bridge support (mv64x60)
Mark A. Greer mgreer at mvista.com wrote:
This patch adds core support for a line of host bridges from Marvell
(formerly Galileo). This code has been tested with a GT64260a,
GT64260b, MV64360, and MV64460. Patches for platforms that use these
bridges will be sent separately.
Shouldn't these guys:
+ u32 cpu2mem_tab[MV64x60_CPU2MEM_WINDOWS][2] = {
+ { MV64x60_CPU2MEM_0_BASE, MV64x60_CPU2MEM_0_SIZE },
+ { MV64x60_CPU2MEM_1_BASE, MV64x60_CPU2MEM_1_SIZE },
+ { MV64x60_CPU2MEM_2_BASE, MV64x60_CPU2MEM_2_SIZE },
+ { MV64x60_CPU2MEM_3_BASE, MV64x60_CPU2MEM_3_SIZE }
+ };
+ u32 com2mem_tab[MV64x60_CPU2MEM_WINDOWS][2] = {
+ { MV64360_MPSC2MEM_0_BASE, MV64360_MPSC2MEM_0_SIZE },
+ { MV64360_MPSC2MEM_1_BASE, MV64360_MPSC2MEM_1_SIZE },
+ { MV64360_MPSC2MEM_2_BASE, MV64360_MPSC2MEM_2_SIZE },
+ { MV64360_MPSC2MEM_3_BASE, MV64360_MPSC2MEM_3_SIZE }
+ };
+ u32 dram_selects[MV64x60_CPU2MEM_WINDOWS] = { 0xe, 0xd, 0xb, 0x7 };
be static, and maybe __devinitdata? Right now, the CPU has to populate
them by hand at runtime.
+wait_for_ownership(int chan)
+{
+ int i;
+
+ for (i=0; iMAX_TX_WAIT; i++) {
+ if ((MV64x60_REG_READ(sdma_regs[chan].sdcm)
+ SDMA_SDCM_TXD) == 0)
+ break;
+
+ udelay(1000);
ow, big busywait. Can't use a sleep in here? I guess not :(
+ * arch/ppc/boot/simple/mv64x60_tty.c
hm. Normally we put arch-specific drivers like this into drivers/serial
and do the appropriate Kconfig work. Is there a reason why this serial
driver is buried under arch/ppc?
+#include ../../../../drivers/serial/mpsc_defs.h
erk.
+struct mv64x60_rx_desc {
+ volatile u16 bufsize;
+ volatile u16 bytecnt;
+ volatile u32 cmd_stat;
+ volatile u32 next_desc_ptr;
+ volatile u32 buffer;
+};
+
+struct mv64x60_tx_desc {
+ volatile u16 bytecnt;
+ volatile u16 shadow;
+ volatile u32 cmd_stat;
+ volatile u32 next_desc_ptr;
+ volatile u32 buffer;
+};
Do these need to be volatile? If so, it indicates that the driver is doing
something wrong.
+gt64260_register_hdlrs(void)
+{
+ /* Register CPU interface error interrupt handler */
+ request_irq(MV64x60_IRQ_CPU_ERR, gt64260_cpu_error_int_handler,
+ SA_INTERRUPT, CPU_INTR_STR, 0);
request_irq() can fail.
+int
+mv64360_get_irq(struct pt_regs *regs)
+{
+ int irq;
+ int irq_gpp;
+
+#ifdef CONFIG_SMP
+ /*
+* Second CPU gets only doorbell (message) interrupts.
+* The doorbell interrupt is BIT28 in the main interrupt low cause reg.
+*/
+ int cpu_nr = smp_processor_id();
This function has no callers, so I am unable to determine whether it is
called from non-preemptible code. If it is called from preemptible code
then that smp_processor_id() is buggy, because you can switch CPUs at any
time.
+static struct platform_device mpsc_shared_device = { /* Shared device */
+ .name = MPSC_SHARED_NAME,
+ .id = 0,
+ .num_resources = ARRAY_SIZE(mv64x60_mpsc_shared_resources),
+ .resource = mv64x60_mpsc_shared_resources,
+ .dev = {
+ .driver_data = (void *)mv64x60_mpsc_shared_pd_dd,
+ },
+};
The cast to void* is unnecessary.
+ (void)mv64x60_setup_for_chip(bh);
how come you always stick that (void) in there?
+mv64x60_config_cpu2mem_windows(struct mv64x60_handle *bh,
+ struct mv64x60_setup_info *si,
+ u32 mem_windows[MV64x60_CPU2MEM_WINDOWS][2])
+{
+ u32 i, win;
+ u32 prot_tab[] = {
+ MV64x60_CPU_PROT_0_WIN, MV64x60_CPU_PROT_1_WIN,
+ MV64x60_CPU_PROT_2_WIN, MV64x60_CPU_PROT_3_WIN
+ };
+ u32 cpu_snoop_tab[] = {
+ MV64x60_CPU_SNOOP_0_WIN, MV64x60_CPU_SNOOP_1_WIN,
+ MV64x60_CPU_SNOOP_2_WIN, MV64x60_CPU_SNOOP_3_WIN
+ };
static initialisation?
+mv64x60_config_cpu2pci_windows(struct mv64x60_handle *bh,
+ struct mv64x60_pci_info *pi, u32 bus)
+{
+ int i;
+ u32 win_tab[2][4] = {
+ { MV64x60_CPU2PCI0_IO_WIN, MV64x60_CPU2PCI0_MEM_0_WIN,
+ MV64x60_CPU2PCI0_MEM_1_WIN,
+ MV64x60_CPU2PCI0_MEM_2_WIN },
+ { MV64x60_CPU2PCI1_IO_WIN, MV64x60_CPU2PCI1_MEM_0_WIN,
+ MV64x60_CPU2PCI1_MEM_1_WIN,
+ MV64x60_CPU2PCI1_MEM_2_WIN },
+ };
+ u32 remap_tab[2][4] = {
+ { MV64x60_CPU2PCI0_IO_REMAP_WIN,
+ MV64x60_CPU2PCI0_MEM_0_REMAP_WIN,
+ MV64x60_CPU2PCI0_MEM_1_REMAP_WIN,
+
[PATCH][PPC32] Added MPC8555/8541 security block infrastructure
Kumar Gala galak at somerset.sps.mot.com wrote: This patch adds OCP, interrupt, and memory offset details for the security block on MPC8555/8541 to support drivers. Your email client did space-stuffing on the message, so the patch gets 100% rejects. I fixed it up by hand and applied the patch locally, thanks. I think there's a way of telling Pine to stop doing this.
[PATCH][PPC32] Added MPC8555/8541 security block infrastructure
Kumar Gala kumar.gala at freescale.com wrote: Can you explain further what you mean by 'space-stuffing' Some madness cooked up by people who think they know better than you. See RFC2646.
[PATCH][PPC32] Fix ppc4xx_progress warnings
Matt Porter mporter at kernel.crashing.org wrote: --- arch/ppc/syslib/ppc4xx_setup.c.~1~2004-10-18 14:53:06.0 -0700 +++ arch/ppc/syslib/ppc4xx_setup.c 2004-10-28 15:24:59.0 -0700 Please ensure that future patches are in `patch -p1' form, thanks.
