Re: crash in kmem_cache_init
Hi Christoph, On Jan 23, 2008 1:18 AM, Christoph Lameter [EMAIL PROTECTED] wrote: My patch is useless (fascinating history of the changelog there through). fallback_alloc calls kmem_getpages without GFP_THISNODE. This means that alloc_pages_node() will try to allocate on the current node but fallback to neighboring node if nothing is there Sure, but I was referring to the scenario where current node _has_ pages available but no -nodelists. Olaf, did you try it? Pekka ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: crash in kmem_cache_init
On Wed, Jan 23, Pekka Enberg wrote: Hi Christoph, On Jan 23, 2008 1:18 AM, Christoph Lameter [EMAIL PROTECTED] wrote: My patch is useless (fascinating history of the changelog there through). fallback_alloc calls kmem_getpages without GFP_THISNODE. This means that alloc_pages_node() will try to allocate on the current node but fallback to neighboring node if nothing is there Sure, but I was referring to the scenario where current node _has_ pages available but no -nodelists. Olaf, did you try it? Does not help. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [MPC5200] problem running FEC and ATA
Wolfgang, On Wednesday 23 January 2008 01:20, Wolfgang Denk wrote: In message [EMAIL PROTECTED] you wrote: Is anybody out there with more MPC5200B experience? Can someone tell me why some MPC5200B are need this patch and others not? We have two different systems here (cards from different vendors) with the same processor, one needs this BSDIS-patch and the other not. ??? Is it really exactly the same CPU revision? My guess is that one is rev. B and the other one is older... The one who needs this patch (CPU card vendor 1): MPC5200CVR400B, M62C REV 1, QCW0723T The CPUs who do not need this patch (CPU card vendor 2): SPC5200CBV400B, M62C REV 1, QAG0610C MPC5200CVR400B, M62C REV 1, QAJ0613F Best regards Juergen Beisert -- Dipl.-Ing. Juergen Beisert | http://www.pengutronix.de Pengutronix - Linux Solutions for Science and Industry Handelsregister: Amtsgericht Hildesheim, HRA 2686 Vertretung Sued/Muenchen, Germany Phone: +49-8766-939 228 | Fax: +49-5121-206917-9 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH POWERPC] i2c: adds support for i2c bus on Frescale CPM1/CPM2 controllers
On Sat, 22 Dec 2007 00:11:12 +0300, Vitaly Bordug wrote: On Fri, 21 Dec 2007 20:36:28 +0100 Jochen Friedrich wrote: Using the port of 2.4 code from Vitaly Bordug [EMAIL PROTECTED] and the actual algorithm used by the i2c driver of the DBox code on cvs.tuxboc.org from Tmbinc, Gillem ([EMAIL PROTECTED]). Renamed i2c-rpx.c and i2c-algo-8xx.c to i2c-cpm.c and converted the driver to an of_platform_driver. I had an attempt a while ago to do this but haven't had enough time to get it completed, so I am glad to see it finally picked up. There was some sort of discussion that time, you seem to have some of those points addressed but something not, please check: http://lkml.org/lkml/2007/5/8/45 (for instance, cpm_i2c_shutdown() and i2c_cpm_del_bus() are void because they cant' fail) Also, why this was directed to Scott? This is lm-sensors stuff and is Jean Delvare [EMAIL PROTECTED] material... This is _i2c_ stuff and doesn't have _anything_ to do with lm-sensors. (Don't let the i2c list address fool you.) As the i2c subsystem maintainer, I am very pleased when contributors get their patches reviewed and tested by people with the knowledge and access to the target architecture and hardware. So Jochen did the right thing by sending this patch to Scott at first. -- Jean Delvare ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCHv2] i2c: adds support for i2c bus on Frescale CPM1/CPM2 controllers
Hi Jochen,
Sorry for the late answer.
On Thu, 3 Jan 2008 10:41:21 +1100, Stephen Rothwell wrote:
Hi Jochen,
Just a few trivial things.
On Wed, 02 Jan 2008 20:52:00 +0100 Jochen Friedrich [EMAIL PROTECTED] wrote:
+++ b/drivers/i2c/busses/i2c-cpm.c
+
+static irqreturn_t cpm_i2c_interrupt(int irq, void *dev_id)
+{
+ struct i2c_adapter *adap;
+ struct cpm_i2c *cpm;
+ struct i2c_reg __iomem *i2c_reg;
+ int i;
+
+ adap = (struct i2c_adapter *) dev_id;
This cast is unnecessary. In fact, you could just pass dev_id to the
following call to i2c_get_adapdata() and eliminate adap completely.
+ /* Get 'me going again.
+*/
For short comments, just make them one line. Similarly later as well.
+ /* This chip can't do zero length writes. However, the i2c core uses
+ them to scan for devices. The best we can do is to convert them
+ into 1 byte reads */
For multiline comments, we normally do
/*
* blah ...
* more blah
*/
+static int cpm_i2c_xfer(struct i2c_adapter *adap, struct i2c_msg *msgs,
int num)
+{
+
+ while (tptr num) {
+ /* Check for outstanding messages */
+ dev_dbg(adap-dev, test ready.\n);
+ if (!(tbdf[tptr].cbd_sc BD_SC_READY)) {
+ dev_dbg(adap-dev, ready.\n);
+ rmsg = msgs[tptr];
+ ret = cpm_i2c_check_message(adap, rmsg, tptr, rptr);
+ tptr++;
+ if (rmsg-flags I2C_M_RD)
+ rptr++;
+ if (ret) {
+ cpm_i2c_force_close(adap);
+ mutex_unlock(cpm-i2c_mutex);
+ return ret;
+ }
+ } else {
+ dev_dbg(adap-dev, not ready.\n);
+ ret = wait_event_interruptible_timeout(cpm-i2c_wait,
+ !(tbdf[tptr].cbd_sc BD_SC_READY), 1 * HZ);
+ if (ret == 0) {
+ cpm_i2c_force_close(adap);
+ dev_dbg(adap-dev, I2C read: timeout!\n);
+ mutex_unlock(cpm-i2c_mutex);
+ return -EREMOTEIO;
+ }
You might want to consolidate the two error paths above using gotos to an
error return section below.
+static void of_register_i2c_devices(struct i2c_adapter *adap,
+ struct device_node *adap_node)
+{
+ struct device_node *node = NULL;
+
+ while ((node = of_get_next_child(adap_node, node))) {
Use
for_each_child_of_node(adap_node, node) {
instead and you don't need to initialise node above.
+static struct of_device_id cpm_i2c_match[] = {
const?
Do you have an updated patch addressing Stephen's comment?
Note: you'd rather send updates of this patch to the i2c list rather
than LKML.
Thanks,
--
Jean Delvare
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: crash in kmem_cache_init
On (23/01/08 08:58), Olaf Hering didst pronounce:
On Tue, Jan 22, Christoph Lameter wrote:
0xc00fe018 is in setup_cpu_cache
(/home/olaf/kernel/git/linux-2.6-numa/mm/slab.c:2111).
2106BUG_ON(!cachep-nodelists[node]);
2107
kmem_list3_init(cachep-nodelists[node]);
2108}
2109}
2110}
if (cachep-nodelists[numa_node_id()])
return;
Does not help.
Sorry this is dragging out. Can you post the full dmesg with loglevel=8 of the
following patch against 2.6.24-rc8 please? It contains the debug information
that helped me figure out what was going wrong on the PPC64 machine here,
the revert and the !l3 checks (i.e. the two patches that made machines I
have access to work). Thanks
diff -rup -X /usr/src/patchset-0.6/bin//dontdiff
linux-2.6.24-rc8-clean/mm/slab.c linux-2.6.24-rc8-015_debug_slab/mm/slab.c
--- linux-2.6.24-rc8-clean/mm/slab.c2008-01-16 04:22:48.0 +
+++ linux-2.6.24-rc8-015_debug_slab/mm/slab.c 2008-01-23 10:44:36.0
+
@@ -348,6 +348,7 @@ static int slab_early_init = 1;
static void kmem_list3_init(struct kmem_list3 *parent)
{
+ printk( o kmem_list3_init\n);
INIT_LIST_HEAD(parent-slabs_full);
INIT_LIST_HEAD(parent-slabs_partial);
INIT_LIST_HEAD(parent-slabs_free);
@@ -1236,6 +1237,7 @@ static int __cpuinit cpuup_prepare(long
* kmem_list3 and not this cpu's kmem_list3
*/
+ printk(cpuup_prepare %ld\n, cpu);
list_for_each_entry(cachep, cache_chain, next) {
/*
* Set up the size64 kmemlist for cpu before we can
@@ -1243,6 +1245,7 @@ static int __cpuinit cpuup_prepare(long
* node has not already allocated this
*/
if (!cachep-nodelists[node]) {
+ printk( o allocing %s %d\n, cachep-name, node);
l3 = kmalloc_node(memsize, GFP_KERNEL, node);
if (!l3)
goto bad;
@@ -1256,6 +1259,7 @@ static int __cpuinit cpuup_prepare(long
* protection here.
*/
cachep-nodelists[node] = l3;
+ printk( o l3 setup\n);
}
spin_lock_irq(cachep-nodelists[node]-list_lock);
@@ -1320,6 +1324,7 @@ static int __cpuinit cpuup_prepare(long
}
return 0;
bad:
+ printk( o bad\n);
cpuup_canceled(cpu);
return -ENOMEM;
}
@@ -1405,6 +1410,7 @@ static void init_list(struct kmem_cache
spin_lock_init(ptr-list_lock);
MAKE_ALL_LISTS(cachep, ptr, nodeid);
+ printk(init_list RESETTING %s node %d\n, cachep-name, nodeid);
cachep-nodelists[nodeid] = ptr;
local_irq_enable();
}
@@ -1427,10 +1433,23 @@ void __init kmem_cache_init(void)
numa_platform = 0;
}
+ printk(Online nodes\n);
+ for_each_online_node(node)
+ printk(o %d\n, node);
+ printk(Nodes with regular memory\n);
+ for_each_node_state(node, N_NORMAL_MEMORY)
+ printk(o %d\n, node);
+ printk(Current running CPU %d is associated with node %d\n,
+ smp_processor_id(),
+ cpu_to_node(smp_processor_id()));
+ printk(Current node is %d\n,
+ numa_node_id());
+
for (i = 0; i NUM_INIT_LISTS; i++) {
kmem_list3_init(initkmem_list3[i]);
if (i MAX_NUMNODES)
cache_cache.nodelists[i] = NULL;
+ printk(kmem_cache_init Setting %s NULL %d\n,
cache_cache.name, i);
}
/*
@@ -1468,6 +1487,8 @@ void __init kmem_cache_init(void)
cache_cache.colour_off = cache_line_size();
cache_cache.array[smp_processor_id()] = initarray_cache.cache;
cache_cache.nodelists[node] = initkmem_list3[CACHE_CACHE];
+ printk(kmem_cache_init Setting %s NULL %d\n, cache_cache.name, node);
+ printk(kmem_cache_init Setting %s initkmem_list3 %d\n,
cache_cache.name, node);
/*
* struct kmem_cache size depends on nr_node_ids, which
@@ -1590,7 +1611,7 @@ void __init kmem_cache_init(void)
/* Replace the static kmem_list3 structures for the boot cpu */
init_list(cache_cache, initkmem_list3[CACHE_CACHE], node);
- for_each_node_state(nid, N_NORMAL_MEMORY) {
+ for_each_online_node(nid) {
init_list(malloc_sizes[INDEX_AC].cs_cachep,
initkmem_list3[SIZE_AC + nid], nid);
@@ -1968,11 +1989,13 @@ static void __init set_up_list3s(struct
{
int node;
- for_each_node_state(node, N_NORMAL_MEMORY) {
+ printk(set_up_list3s %s index %d\n, cachep-name, index);
+ for_each_online_node(node) {
Re: [PATCHv2] i2c: adds support for i2c bus on Frescale CPM1/CPM2 controllers
Hi Jean, Do you have an updated patch addressing Stephen's comment? Note: you'd rather send updates of this patch to the i2c list rather than LKML. I'm currently looking at that last patches from Jon and try to make this driver fit in there (+ the class override stuff). Note: will do. I just subscribed to this list. Thanks, Jochen ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] [POWERPC] Update TQM5200, CM5200 and Motion-PRO _defconfig and .dts files
Olof Johansson wrote: ... I disagree, I have one defconfig for all our boards to date. It means I only have one kernel to build to test on all boards, instead of having to build a number of different kernels. Keeping it fairly generic also means a customer can start out using the generic kernel in case they want to, and later on add their own drivers and prune out what is not needed. Well, I just prefer separate defconfigs but I can live with the common one as well, feel free to merge it as you see it fit. Cheers, m. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH v6] [POWERPC] Add LED driver for Promess Motion-PRO board.
Add support for two Motion-PRO board custom LEDs:
- motionpro-statusled
- motionpro-readyled
Signed-off-by: Jan Wrobel [EMAIL PROTECTED]
Signed-off-by: Marian Balakowicz [EMAIL PROTECTED]
---
Updated static struct of_device_id mpled_match[] definition
to static const struct of_device_id mpled_match[].
drivers/leds/Kconfig |7 +
drivers/leds/Makefile |3
drivers/leds/leds-motionpro.c | 250 +
include/asm-powerpc/mpc52xx.h |5 +
4 files changed, 264 insertions(+), 1 deletions(-)
create mode 100644 drivers/leds/leds-motionpro.c
diff --git a/drivers/leds/Kconfig b/drivers/leds/Kconfig
index ec568fa..1567ed6 100644
--- a/drivers/leds/Kconfig
+++ b/drivers/leds/Kconfig
@@ -55,6 +55,13 @@ config LEDS_TOSA
This option enables support for the LEDs on Sharp Zaurus
SL-6000 series.
+config LEDS_MOTIONPRO
+ tristate Motion-PRO LEDs Support
+ depends on LEDS_CLASS PPC_MPC5200
+ help
+ This option enables support for status and ready LEDs connected
+ to GPIO lines on Motion-PRO board.
+
config LEDS_S3C24XX
tristate LED Support for Samsung S3C24XX GPIO LEDs
depends on LEDS_CLASS ARCH_S3C2410
diff --git a/drivers/leds/Makefile b/drivers/leds/Makefile
index a60de1b..a56d399 100644
--- a/drivers/leds/Makefile
+++ b/drivers/leds/Makefile
@@ -18,7 +18,8 @@ obj-$(CONFIG_LEDS_H1940) += leds-h1940.o
obj-$(CONFIG_LEDS_COBALT_QUBE) += leds-cobalt-qube.o
obj-$(CONFIG_LEDS_COBALT_RAQ) += leds-cobalt-raq.o
obj-$(CONFIG_LEDS_GPIO)+= leds-gpio.o
-obj-$(CONFIG_LEDS_CM_X270) += leds-cm-x270.o
+obj-$(CONFIG_LEDS_CM_X270) += leds-cm-x270.o
+obj-$(CONFIG_LEDS_MOTIONPRO) += leds-motionpro.o
# LED Triggers
obj-$(CONFIG_LEDS_TRIGGER_TIMER) += ledtrig-timer.o
diff --git a/drivers/leds/leds-motionpro.c b/drivers/leds/leds-motionpro.c
new file mode 100644
index 000..cad7ccd
--- /dev/null
+++ b/drivers/leds/leds-motionpro.c
@@ -0,0 +1,250 @@
+/*
+ * LEDs driver for the Motion-PRO board.
+ *
+ * Copyright (C) 2007 Semihalf
+ * Jan Wrobel [EMAIL PROTECTED]
+ * Marian Balakowicz [EMAIL PROTECTED]
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License version 2 as published by
+ * the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
+ * more details.
+ *
+ * You should have received a copy of the GNU General Public License along
+ * with this program; if not, write to the Free Software Foundation, Inc., 51
+ * Franklin St, Fifth Floor, Boston, MA 02110-1301 USA
+ *
+ *
+ * Decription:
+ * This driver enables control over Motion-PRO status and ready LEDs through
+ * sysfs. LEDs can be controlled by writing to sysfs files:
+ * class/leds/led-name/(brightness|delay_off|delay_on).
+ * See Documentation/leds-class.txt for more details.
+ * led-name is the set to the value of 'label' property of the
+ * corresponding GPT node.
+ *
+ * Before user issues first control command via sysfs, LED blinking is
+ * controlled by the kernel ('blink-delay' property of the GPT node
+ * in the device tree blob).
+ *
+ */
+
+#define DEBUG
+
+#include linux/module.h
+#include linux/leds.h
+#include linux/of_platform.h
+#include asm/mpc52xx.h
+
+/* LED control bits */
+#define LED_ON MPC52xx_GPT_OUTPUT_1
+
+/* LED mode */
+#define LED_MODE_KERNEL1
+#define LED_MODE_USER 2
+
+struct motionpro_led {
+ spinlock_t led_lock;/* Protects the LED data */
+ struct mpc52xx_gpt __iomem *gpt;/* LED registers */
+ struct timer_list blink_timer; /* Used if blink_delay is nonzero */
+ unsigned int blink_delay; /* [ms], if set to 0 blinking is off */
+ unsigned int mode; /* kernel/user */
+ struct led_classdev mpled_cdev; /* LED class */
+};
+
+/*
+ * Timer event - blinks LED before user takes control over it
+ * with the first access via sysfs.
+ */
+static void mpled_timer_toggle(unsigned long data)
+{
+ struct motionpro_led *mpled = (struct motionpro_led *)data;
+
+ spin_lock_bh(mpled-led_lock);
+ if (mpled-mode == LED_MODE_KERNEL) {
+ u32 val = in_be32(mpled-gpt-mode);
+ val ^= LED_ON;
+ out_be32(mpled-gpt-mode, val);
+
+ mod_timer(mpled-blink_timer,
+ jiffies + msecs_to_jiffies(mpled-blink_delay));
+ }
+ spin_unlock_bh(mpled-led_lock);
+}
+
+/*
+ * Turn on/off led according to user settings in sysfs.
+ * First call to this function disables kernel blinking.
+ */
+static void mpled_set(struct led_classdev *led_cdev,
+ enum
Re: crash in kmem_cache_init
On Wed, Jan 23, Mel Gorman wrote: Sorry this is dragging out. Can you post the full dmesg with loglevel=8 of the following patch against 2.6.24-rc8 please? It contains the debug information that helped me figure out what was going wrong on the PPC64 machine here, the revert and the !l3 checks (i.e. the two patches that made machines I have access to work). Thanks It boots with your change. boot: x Please wait, loading kernel... Allocated 00a0 bytes for kernel @ 0020 Elf64 kernel loaded... OF stdout device is: /vdevice/[EMAIL PROTECTED] Hypertas detected, assuming LPAR ! command line: debug xmon=on panic=1 loglevel=8 memory layout at init: alloc_bottom : 00ac1000 alloc_top: 1000 alloc_top_hi : da00 rmo_top : 1000 ram_top : da00 Looking for displays found display : /[EMAIL PROTECTED]/[EMAIL PROTECTED]/[EMAIL PROTECTED]/[EMAIL PROTECTED], opening ... done instantiating rtas at 0x0f6a1000 ... done : boot cpu 0002 : starting cpu hw idx 0002... done 0004 : starting cpu hw idx 0004... done 0006 : starting cpu hw idx 0006... done copying OF device tree ... Building dt strings... Building dt structure... Device tree strings 0x00cc2000 - 0x00cc34e4 Device tree struct 0x00cc4000 - 0x00cd6000 Calling quiesce ... returning from prom_init Partition configured for 8 cpus. Starting Linux PPC64 #52 SMP Wed Jan 23 13:05:38 CET 2008 - ppc64_pft_size= 0x1c physicalMemorySize= 0xda00 htab_hash_mask= 0x1f - Linux version 2.6.24-rc8-ppc64 ([EMAIL PROTECTED]) (gcc version 4.1.2 20070115 (prerelease) (SUSE Linux)) #52 SMP Wed Jan 23 13:05:38 CET 2008 [boot]0012 Setup Arch EEH: PCI Enhanced I/O Error Handling Enabled PPC64 nvram contains 8192 bytes Zone PFN ranges: DMA 0 - 892928 Normal 892928 - 892928 Movable zone start PFN for each node early_node_map[1] active PFN ranges 1:0 - 892928 Could not find start_pfn for node 0 [boot]0015 Setup Done Built 2 zonelists in Node order, mobility grouping on. Total pages: 880720 Policy zone: DMA Kernel command line: debug xmon=on panic=1 loglevel=8 [boot]0020 XICS Init xics: no ISA interrupt controller [boot]0021 XICS Done PID hash table entries: 4096 (order: 12, 32768 bytes) time_init: decrementer frequency = 275.07 MHz time_init: processor frequency = 2197.80 MHz clocksource: timebase mult[e8ab05] shift[22] registered clockevent: decrementer mult[466a] shift[16] cpu[0] Console: colour dummy device 80x25 console handover: boot [udbg-1] - real [hvc0] Dentry cache hash table entries: 524288 (order: 10, 4194304 bytes) Inode-cache hash table entries: 262144 (order: 9, 2097152 bytes) freeing bootmem node 1 Memory: 3496632k/3571712k available (6188k kernel code, 75080k reserved, 1324k data, 1220k bss, 304k init) Online nodes o 0 o 1 Nodes with regular memory o 1 Current running CPU 0 is associated with node 0 Current node is 0 o kmem_list3_init kmem_cache_init Setting kmem_cache NULL 0 o kmem_list3_init kmem_cache_init Setting kmem_cache NULL 1 o kmem_list3_init kmem_cache_init Setting kmem_cache NULL 2 o kmem_list3_init kmem_cache_init Setting kmem_cache NULL 3 o kmem_list3_init kmem_cache_init Setting kmem_cache NULL 4 o kmem_list3_init kmem_cache_init Setting kmem_cache NULL 5 o kmem_list3_init kmem_cache_init Setting kmem_cache NULL 6 o kmem_list3_init kmem_cache_init Setting kmem_cache NULL 7 o kmem_list3_init kmem_cache_init Setting kmem_cache NULL 8 o kmem_list3_init kmem_cache_init Setting kmem_cache NULL 9 o kmem_list3_init kmem_cache_init Setting kmem_cache NULL 10 o kmem_list3_init kmem_cache_init Setting kmem_cache NULL 11 o kmem_list3_init kmem_cache_init Setting kmem_cache NULL 12 o kmem_list3_init kmem_cache_init Setting kmem_cache NULL 13 o kmem_list3_init kmem_cache_init Setting kmem_cache NULL 14 o kmem_list3_init kmem_cache_init Setting kmem_cache NULL 15 o kmem_list3_init kmem_cache_init Setting kmem_cache NULL 16 o kmem_list3_init kmem_cache_init Setting kmem_cache NULL 17 o kmem_list3_init kmem_cache_init Setting kmem_cache NULL 18 o kmem_list3_init kmem_cache_init Setting kmem_cache NULL 19 o kmem_list3_init kmem_cache_init Setting kmem_cache NULL 20 o kmem_list3_init kmem_cache_init Setting kmem_cache NULL 21 o kmem_list3_init kmem_cache_init Setting kmem_cache NULL 22 o kmem_list3_init kmem_cache_init Setting kmem_cache NULL 23 o kmem_list3_init kmem_cache_init Setting kmem_cache NULL 24 o kmem_list3_init kmem_cache_init Setting kmem_cache NULL 25 o kmem_list3_init kmem_cache_init Setting kmem_cache NULL 26 o kmem_list3_init kmem_cache_init Setting kmem_cache NULL 27 o kmem_list3_init
Re: ppc32: Weird process scheduling behaviour with 2.6.24-rc
On Tue, 2008-01-22 at 15:56 +0100, Michel Dänzer wrote:
On Fri, 2008-01-18 at 13:34 +0100, Michel Dänzer wrote:
This is on a PowerBook5,8.
In a nutshell, things seem more sluggish in general than with 2.6.23.
But in particular, processes running at nice levels 0 can get most of
the CPU cycles available, slowing down processes running at nice level
0.
The canonical test case I've come up with is to run an infinite loop
with
sudo -u nobody nice -n 19 sh -c 'while true; do true; done'
This makes my X session (X server running at nice level -1, clients at
0) unusably sluggish (it can even take several seconds to process ctrl-c
to interrupt the infinite loop) with 2.6.24-rc but works as expected
with 2.6.23.
Anybody else seeing this?
I've seen this since .24-rc5 (the first .24-rc I tried), and it's still
there with -rc8. I'd be surprised if this kind of behaviour remained
unfixed for that long if it affected x86, so I presume it's powerpc
specific.
Or maybe not... I've bisected this down to the scheduler changes
between
df3d80f5a5c74168be42788364d13cf6c83c7b9c/23fd50450a34f2558070ceabb0bfebc1c9604af5
and b5869ce7f68b233ceb81465a7644be0d9a5f3dbb .
Finished bisecting now. And the winner is...
810e95ccd58d91369191aa4ecc9e6d4a10d8d0c8 is first bad commit
commit 810e95ccd58d91369191aa4ecc9e6d4a10d8d0c8
Author: Peter Zijlstra [EMAIL PROTECTED]
Date: Mon Oct 15 17:00:14 2007 +0200
sched: another wakeup_granularity fix
unit mis-match: wakeup_gran was used against a vruntime
Signed-off-by: Peter Zijlstra [EMAIL PROTECTED]
Signed-off-by: Ingo Molnar [EMAIL PROTECTED]
:04 04 61242d589b0082a417657807ed6329321340f7f3
bff39e49275324e15f37d2163157733580b7df1a M kernel
Unfortunately, I don't understand how that can cause the misbehaviour
described above, and 2.6.24-rc8
(667984d9e481e43a930a478c588dced98cb61fea) with the patch below still
shows the problem. Any ideas Peter or Ingo (or anyone, really :)?
diff --git a/kernel/sched_fair.c b/kernel/sched_fair.c
index da7c061..a7cc22a 100644
--- a/kernel/sched_fair.c
+++ b/kernel/sched_fair.c
@@ -843,7 +843,6 @@ static void check_preempt_wakeup(struct rq *rq, struct
task_struct *p)
struct task_struct *curr = rq-curr;
struct cfs_rq *cfs_rq = task_cfs_rq(curr);
struct sched_entity *se = curr-se, *pse = p-se;
- unsigned long gran;
if (unlikely(rt_prio(p-prio))) {
update_rq_clock(rq);
@@ -866,11 +865,8 @@ static void check_preempt_wakeup(struct rq *rq, struct
task_struct *p)
pse = parent_entity(pse);
}
- gran = sysctl_sched_wakeup_granularity;
- if (unlikely(se-load.weight != NICE_0_LOAD))
- gran = calc_delta_fair(gran, se-load);
- if (pse-vruntime + gran se-vruntime)
+ if (pse-vruntime + sysctl_sched_wakeup_granularity se-vruntime)
resched_task(curr);
}
--
Earthling Michel Dänzer | http://tungstengraphics.com
Libre software enthusiast | Debian, X and DRI developer
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] ppc: fix #ifdef-s in mediabay driver
On Wednesday 23 January 2008, Benjamin Herrenschmidt wrote: On Wed, 2008-01-23 at 01:58 +0100, Bartlomiej Zolnierkiewicz wrote: I'm more worried about breaking automatic build checking (make randconfig) than a few extra bytes so if you remove all #ifdefs you'll have to either make BLK_DEV_IDE_PMAC select PMAC_MEDIABAY or make PMAC_MEDIABAY depend on BLK_DEV_IDE_PMAC (otherwise BLK_DEV_IDE=n PMAC_MEDIABAY=y will fail since mediabay.c is referencing IDE code). I was thinking about having the pmac arch code provide an exported function pointer to put the hook in to avoid that problem. BTW the other pending IDE patches (yet to posted) include rework of IDE hot-plug support for PMAC media-bay so ide_init_hwif_ports()/ide_register_hw() /ide_unregister() calls in mediabay.c will be replaced by something else. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: ppc32: Weird process scheduling behaviour with 2.6.24-rc
On Wed, 2008-01-23 at 13:18 +0100, Michel Dänzer wrote:
On Tue, 2008-01-22 at 15:56 +0100, Michel Dänzer wrote:
On Fri, 2008-01-18 at 13:34 +0100, Michel Dänzer wrote:
This is on a PowerBook5,8.
In a nutshell, things seem more sluggish in general than with 2.6.23.
But in particular, processes running at nice levels 0 can get most of
the CPU cycles available, slowing down processes running at nice level
0.
The canonical test case I've come up with is to run an infinite loop
with
sudo -u nobody nice -n 19 sh -c 'while true; do true; done'
This makes my X session (X server running at nice level -1, clients at
0) unusably sluggish (it can even take several seconds to process ctrl-c
to interrupt the infinite loop) with 2.6.24-rc but works as expected
with 2.6.23.
Anybody else seeing this?
I've seen this since .24-rc5 (the first .24-rc I tried), and it's still
there with -rc8. I'd be surprised if this kind of behaviour remained
unfixed for that long if it affected x86, so I presume it's powerpc
specific.
Or maybe not... I've bisected this down to the scheduler changes
between
df3d80f5a5c74168be42788364d13cf6c83c7b9c/23fd50450a34f2558070ceabb0bfebc1c9604af5
and b5869ce7f68b233ceb81465a7644be0d9a5f3dbb .
Finished bisecting now. And the winner is...
810e95ccd58d91369191aa4ecc9e6d4a10d8d0c8 is first bad commit
commit 810e95ccd58d91369191aa4ecc9e6d4a10d8d0c8
Author: Peter Zijlstra [EMAIL PROTECTED]
Date: Mon Oct 15 17:00:14 2007 +0200
sched: another wakeup_granularity fix
unit mis-match: wakeup_gran was used against a vruntime
Signed-off-by: Peter Zijlstra [EMAIL PROTECTED]
Signed-off-by: Ingo Molnar [EMAIL PROTECTED]
:04 04 61242d589b0082a417657807ed6329321340f7f3
bff39e49275324e15f37d2163157733580b7df1a M kernel
Unfortunately, I don't understand how that can cause the misbehaviour
described above, and 2.6.24-rc8
(667984d9e481e43a930a478c588dced98cb61fea) with the patch below still
shows the problem. Any ideas Peter or Ingo (or anyone, really :)?
diff --git a/kernel/sched_fair.c b/kernel/sched_fair.c
index da7c061..a7cc22a 100644
--- a/kernel/sched_fair.c
+++ b/kernel/sched_fair.c
@@ -843,7 +843,6 @@ static void check_preempt_wakeup(struct rq *rq, struct
task_struct *p)
struct task_struct *curr = rq-curr;
struct cfs_rq *cfs_rq = task_cfs_rq(curr);
struct sched_entity *se = curr-se, *pse = p-se;
- unsigned long gran;
if (unlikely(rt_prio(p-prio))) {
update_rq_clock(rq);
@@ -866,11 +865,8 @@ static void check_preempt_wakeup(struct rq *rq, struct
task_struct *p)
pse = parent_entity(pse);
}
- gran = sysctl_sched_wakeup_granularity;
- if (unlikely(se-load.weight != NICE_0_LOAD))
- gran = calc_delta_fair(gran, se-load);
- if (pse-vruntime + gran se-vruntime)
+ if (pse-vruntime + sysctl_sched_wakeup_granularity se-vruntime)
resched_task(curr);
}
Most curious; are you sure its not a bisection problem?
Does ppc32 (or your instance thereof) have a high resolution
sched_clock()?
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] [RAPIDIO] Fix compile error and warning
drivers/rapidio/rio.c: In function 'rio_get_asm':
drivers/rapidio/rio.c:413: error: implicit declaration of function
'in_interrupt'
drivers/rapidio/rio.c: In function 'rio_init_mports':
drivers/rapidio/rio.c:480: warning: format '%8.8lx' expects type 'long unsigned
int', but argument 2 has type 'resource_size_t'
drivers/rapidio/rio.c:480: warning: format '%8.8lx' expects type 'long unsigned
int', but argument 3 has type 'resource_size_t'
---
drivers/rapidio/rio.c |5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/rapidio/rio.c b/drivers/rapidio/rio.c
index f644807..80c5f1b 100644
--- a/drivers/rapidio/rio.c
+++ b/drivers/rapidio/rio.c
@@ -23,6 +23,7 @@
#include linux/module.h
#include linux/spinlock.h
#include linux/slab.h
+#include linux/interrupt.h
#include rio.h
@@ -476,8 +477,8 @@ int rio_init_mports(void)
port-iores.end - port-iores.start,
port-name)) {
printk(KERN_ERR
- RIO: Error requesting master port region
%8.8lx-%8.8lx\n,
- port-iores.start, port-iores.end - 1);
+ RIO: Error requesting master port region
0x%016llx-0x%016llx\n,
+ (u64)port-iores.start, (u64)port-iores.end -
1);
rc = -ENOMEM;
goto out;
}
--
1.5.3.7
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] [POWERPC] Fix compile error if CONFIG_STX_GP3 is defined
cpmux is need in all cases, having wrapped by the ifndef CONFIG_STX_GP3 was causing a compile error. --- drivers/serial/cpm_uart/cpm_uart_cpm2.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/serial/cpm_uart/cpm_uart_cpm2.c b/drivers/serial/cpm_uart/cpm_uart_cpm2.c index def0158..d9af06a 100644 --- a/drivers/serial/cpm_uart/cpm_uart_cpm2.c +++ b/drivers/serial/cpm_uart/cpm_uart_cpm2.c @@ -165,9 +165,9 @@ void scc2_lineif(struct uart_cpm_port *pinfo) * really has to get out of the driver so boards can * be supported in a sane fashion. */ + volatile cpmux_t *cpmux = cpm2_map(im_cpmux); #ifndef CONFIG_STX_GP3 volatile iop_cpm2_t *io = cpm2_map(im_ioport); - volatile cpmux_t *cpmux = cpm2_map(im_cpmux); io-iop_pparb |= 0x008b; io-iop_pdirb |= 0x0088; -- 1.5.3.7 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: ppc32: Weird process scheduling behaviour with 2.6.24-rc
Another question, do you have: CONFIG_FAIR_GROUP_SCHED=y if so, does flipping that off have any effect? ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] [POWERPC] Update TQM5200, CM5200 and Motion-PRO _defconfig and .dts files
In message [EMAIL PROTECTED] you wrote: Olof Johansson wrote: ... I disagree, I have one defconfig for all our boards to date. It means I only have one kernel to build to test on all boards, instead of having to build a number of different kernels. Keeping it fairly generic also means a customer can start out using the generic kernel in case they want to, and later on add their own drivers and prune out what is not needed. Well, I just prefer separate defconfigs but I can live with the common one as well, feel free to merge it as you see it fit. Well, it may make sense to use common defconfig files for boards of the same breed (different configurations of one board family from one vendor for example). But please note that TQM5200, CM5200 and Motion-PRO are boards from 3 different vendors, used by different projects with differing needs. IMO it makes very much sense to provide 3 separate default configurations that match the specific requirements of each of these boards. In this case I vote for separate defconfig files, please. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: [EMAIL PROTECTED] Be careful what you wish for. You never know who will be listening. - Terry Pratchett, _Soul Music_ ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: crash in kmem_cache_init
On Wed, Jan 23, Olaf Hering wrote:
On Wed, Jan 23, Mel Gorman wrote:
Sorry this is dragging out. Can you post the full dmesg with loglevel=8 of
the
following patch against 2.6.24-rc8 please? It contains the debug information
that helped me figure out what was going wrong on the PPC64 machine here,
the revert and the !l3 checks (i.e. the two patches that made machines I
have access to work). Thanks
It boots with your change.
This version of the patch boots ok for me:
Maybe I made a mistake with earlier patches, no idea.
---
mm/slab.c | 17 +
1 file changed, 13 insertions(+), 4 deletions(-)
--- a/mm/slab.c
+++ b/mm/slab.c
@@ -1590,7 +1590,7 @@ void __init kmem_cache_init(void)
/* Replace the static kmem_list3 structures for the boot cpu */
init_list(cache_cache, initkmem_list3[CACHE_CACHE], node);
- for_each_node_state(nid, N_NORMAL_MEMORY) {
+ for_each_online_node(nid) {
init_list(malloc_sizes[INDEX_AC].cs_cachep,
initkmem_list3[SIZE_AC + nid], nid);
@@ -1968,7 +1968,7 @@ static void __init set_up_list3s(struct
{
int node;
- for_each_node_state(node, N_NORMAL_MEMORY) {
+ for_each_online_node(node) {
cachep-nodelists[node] = initkmem_list3[index + node];
cachep-nodelists[node]-next_reap = jiffies +
REAPTIMEOUT_LIST3 +
@@ -2099,7 +2099,7 @@ static int __init_refok setup_cpu_cache(
g_cpucache_up = PARTIAL_L3;
} else {
int node;
- for_each_node_state(node, N_NORMAL_MEMORY) {
+ for_each_online_node(node) {
cachep-nodelists[node] =
kmalloc_node(sizeof(struct kmem_list3),
GFP_KERNEL, node);
@@ -2775,6 +2775,11 @@ static int cache_grow(struct kmem_cache
/* Take the l3 list lock to change the colour_next on this node */
check_irq_off();
l3 = cachep-nodelists[nodeid];
+ if (!l3) {
+ nodeid = numa_node_id();
+ l3 = cachep-nodelists[nodeid];
+ }
+ BUG_ON(!l3);
spin_lock(l3-list_lock);
/* Get colour for the slab, and cal the next value. */
@@ -3317,6 +3322,10 @@ static void *cache_alloc_node(struct
int x;
l3 = cachep-nodelists[nodeid];
+ if (!l3) {
+ nodeid = numa_node_id();
+ l3 = cachep-nodelists[nodeid];
+ }
BUG_ON(!l3);
retry:
@@ -3815,7 +3824,7 @@ static int alloc_kmemlist(struct kmem_ca
struct array_cache *new_shared;
struct array_cache **new_alien = NULL;
- for_each_node_state(node, N_NORMAL_MEMORY) {
+ for_each_online_node(node) {
if (use_alien_caches) {
new_alien = alloc_alien_cache(node, cachep-limit);
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] [POWERPC] Move RapidIO support code from arch/ppc
Do just enough to move the RapidIO support code for 85xx over from arch/ppc
into arch/powerpc and make it still build.
Signed-off-by: Kumar Gala [EMAIL PROTECTED]
---
arch/powerpc/kernel/Makefile |1 +
arch/{ppc = powerpc}/kernel/rio.c |0
arch/powerpc/sysdev/Makefile |1 +
.../ppc85xx_rio.c = powerpc/sysdev/fsl_rio.c} |0
.../ppc85xx_rio.h = powerpc/sysdev/fsl_rio.h} |0
arch/ppc/kernel/Makefile |1 -
arch/ppc/platforms/85xx/mpc85xx_ads_common.c |3 +--
arch/ppc/platforms/85xx/stx_gp3.c |2 +-
arch/ppc/platforms/85xx/tqm85xx.c |2 +-
arch/ppc/syslib/Makefile |1 -
10 files changed, 5 insertions(+), 6 deletions(-)
rename arch/{ppc = powerpc}/kernel/rio.c (100%)
rename arch/{ppc/syslib/ppc85xx_rio.c = powerpc/sysdev/fsl_rio.c} (100%)
rename arch/{ppc/syslib/ppc85xx_rio.h = powerpc/sysdev/fsl_rio.h} (100%)
diff --git a/arch/powerpc/kernel/Makefile b/arch/powerpc/kernel/Makefile
index d9b3770..58dbfef 100644
--- a/arch/powerpc/kernel/Makefile
+++ b/arch/powerpc/kernel/Makefile
@@ -70,6 +70,7 @@ pci64-$(CONFIG_PPC64) += pci_dn.o isa-bridge.o
obj-$(CONFIG_PCI) += pci_$(CONFIG_WORD_SIZE).o $(pci64-y) \
pci-common.o
obj-$(CONFIG_PCI_MSI) += msi.o
+obj-$(CONFIG_RAPIDIO) += rio.o
obj-$(CONFIG_KEXEC)+= machine_kexec.o crash.o \
machine_kexec_$(CONFIG_WORD_SIZE).o
obj-$(CONFIG_AUDIT)+= audit.o
diff --git a/arch/ppc/kernel/rio.c b/arch/powerpc/kernel/rio.c
similarity index 100%
rename from arch/ppc/kernel/rio.c
rename to arch/powerpc/kernel/rio.c
diff --git a/arch/powerpc/sysdev/Makefile b/arch/powerpc/sysdev/Makefile
index 66fe39c..f17e7b8 100644
--- a/arch/powerpc/sysdev/Makefile
+++ b/arch/powerpc/sysdev/Makefile
@@ -12,6 +12,7 @@ obj-$(CONFIG_U3_DART) += dart_iommu.o
obj-$(CONFIG_MMIO_NVRAM) += mmio_nvram.o
obj-$(CONFIG_FSL_SOC) += fsl_soc.o
obj-$(CONFIG_FSL_PCI) += fsl_pci.o
+obj-$(CONFIG_RAPIDIO) += fsl_rio.o
obj-$(CONFIG_TSI108_BRIDGE)+= tsi108_pci.o tsi108_dev.o
obj-$(CONFIG_QUICC_ENGINE) += qe_lib/
obj-$(CONFIG_PPC_BESTCOMM) += bestcomm/
diff --git a/arch/ppc/syslib/ppc85xx_rio.c b/arch/powerpc/sysdev/fsl_rio.c
similarity index 100%
rename from arch/ppc/syslib/ppc85xx_rio.c
rename to arch/powerpc/sysdev/fsl_rio.c
diff --git a/arch/ppc/syslib/ppc85xx_rio.h b/arch/powerpc/sysdev/fsl_rio.h
similarity index 100%
rename from arch/ppc/syslib/ppc85xx_rio.h
rename to arch/powerpc/sysdev/fsl_rio.h
diff --git a/arch/ppc/kernel/Makefile b/arch/ppc/kernel/Makefile
index 6b4f022..5da0ca7 100644
--- a/arch/ppc/kernel/Makefile
+++ b/arch/ppc/kernel/Makefile
@@ -13,7 +13,6 @@ obj-y := entry.o traps.o time.o
misc.o \
ppc_htab.o
obj-$(CONFIG_MODULES) += ppc_ksyms.o
obj-$(CONFIG_PCI) += pci.o
-obj-$(CONFIG_RAPIDIO) += rio.o
obj-$(CONFIG_KGDB) += ppc-stub.o
obj-$(CONFIG_SMP) += smp.o smp-tbsync.o
obj-$(CONFIG_KEXEC)+= machine_kexec.o relocate_kernel.o
diff --git a/arch/ppc/platforms/85xx/mpc85xx_ads_common.c
b/arch/ppc/platforms/85xx/mpc85xx_ads_common.c
index 674806e..0706dca 100644
--- a/arch/ppc/platforms/85xx/mpc85xx_ads_common.c
+++ b/arch/ppc/platforms/85xx/mpc85xx_ads_common.c
@@ -42,8 +42,6 @@
#include mm/mmu_decl.h
-#include syslib/ppc85xx_rio.h
-
#include platforms/85xx/mpc85xx_ads_common.h
#ifndef CONFIG_PCI
@@ -190,6 +188,7 @@ mpc85xx_exclude_device(u_char bus, u_char devfn)
#endif /* CONFIG_PCI */
#ifdef CONFIG_RAPIDIO
+extern void mpc85xx_rio_setup(int law_start, int law_size);
void platform_rio_init(void)
{
/* 512MB RIO LAW at 0xc000 */
diff --git a/arch/ppc/platforms/85xx/stx_gp3.c
b/arch/ppc/platforms/85xx/stx_gp3.c
index 731b40e..8748da3 100644
--- a/arch/ppc/platforms/85xx/stx_gp3.c
+++ b/arch/ppc/platforms/85xx/stx_gp3.c
@@ -54,7 +54,6 @@
#include syslib/cpm2_pic.h
#include syslib/ppc85xx_common.h
-#include syslib/ppc85xx_rio.h
unsigned char __res[sizeof(bd_t)];
@@ -270,6 +269,7 @@ int mpc85xx_exclude_device(u_char bus, u_char devfn)
#endif /* CONFIG_PCI */
#ifdef CONFIG_RAPIDIO
+extern void mpc85xx_rio_setup(int law_start, int law_size);
void
platform_rio_init(void)
{
diff --git a/arch/ppc/platforms/85xx/tqm85xx.c
b/arch/ppc/platforms/85xx/tqm85xx.c
index 4ee2bd1..2a863a8 100644
--- a/arch/ppc/platforms/85xx/tqm85xx.c
+++ b/arch/ppc/platforms/85xx/tqm85xx.c
@@ -54,7 +54,6 @@
#include syslib/ppc85xx_setup.h
#include syslib/cpm2_pic.h
#include syslib/ppc85xx_common.h
-#include syslib/ppc85xx_rio.h
#ifndef CONFIG_PCI
unsigned long isa_io_base = 0;
@@ -309,6 +308,7 @@ int mpc85xx_exclude_device(u_char bus, u_char devfn)
#endif /*
Re: [PATCHv2] i2c: adds support for i2c bus on Frescale CPM1/CPM2 controllers
Hallo Jochen, On Wed, 23 Jan 2008 12:23:58 +0100, Jochen Friedrich wrote: Hi Jean, Do you have an updated patch addressing Stephen's comment? Note: you'd rather send updates of this patch to the i2c list rather than LKML. I'm currently looking at that last patches from Jon and try to make this driver fit in there (+ the class override stuff). I'm not sure what patches exactly you're talking about, but the aliasing stuff Jon and myself have been working on are still under debate. Your patch shouldn't assume that any of these patches will go upstream immediately, so your patch adding the i2c-cpm driver can ignore them. I'll update the patches before merging them as needed, do not worry too much about that. Note: will do. I just subscribed to this list. Note hat you do not need to be subscribed to post to the i2c list (but of course, if you have some interest in Linux i2c development, subscribing was a good idea anyway.) -- Jean Delvare ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: ppc32: Weird process scheduling behaviour with 2.6.24-rc
On Wed, 2008-01-23 at 13:36 +0100, Peter Zijlstra wrote:
On Wed, 2008-01-23 at 13:18 +0100, Michel Dänzer wrote:
810e95ccd58d91369191aa4ecc9e6d4a10d8d0c8 is first bad commit
commit 810e95ccd58d91369191aa4ecc9e6d4a10d8d0c8
Author: Peter Zijlstra [EMAIL PROTECTED]
Date: Mon Oct 15 17:00:14 2007 +0200
sched: another wakeup_granularity fix
unit mis-match: wakeup_gran was used against a vruntime
Signed-off-by: Peter Zijlstra [EMAIL PROTECTED]
Signed-off-by: Ingo Molnar [EMAIL PROTECTED]
:04 04 61242d589b0082a417657807ed6329321340f7f3
bff39e49275324e15f37d2163157733580b7df1a M kernel
Unfortunately, I don't understand how that can cause the misbehaviour
described above, and 2.6.24-rc8
(667984d9e481e43a930a478c588dced98cb61fea) with the patch below still
shows the problem. Any ideas Peter or Ingo (or anyone, really :)?
diff --git a/kernel/sched_fair.c b/kernel/sched_fair.c
index da7c061..a7cc22a 100644
--- a/kernel/sched_fair.c
+++ b/kernel/sched_fair.c
@@ -843,7 +843,6 @@ static void check_preempt_wakeup(struct rq *rq, struct
task_struct *p)
struct task_struct *curr = rq-curr;
struct cfs_rq *cfs_rq = task_cfs_rq(curr);
struct sched_entity *se = curr-se, *pse = p-se;
- unsigned long gran;
if (unlikely(rt_prio(p-prio))) {
update_rq_clock(rq);
@@ -866,11 +865,8 @@ static void check_preempt_wakeup(struct rq *rq, struct
task_struct *p)
pse = parent_entity(pse);
}
- gran = sysctl_sched_wakeup_granularity;
- if (unlikely(se-load.weight != NICE_0_LOAD))
- gran = calc_delta_fair(gran, se-load);
- if (pse-vruntime + gran se-vruntime)
+ if (pse-vruntime + sysctl_sched_wakeup_granularity se-vruntime)
resched_task(curr);
}
Most curious; are you sure its not a bisection problem?
Quite sure.
Does ppc32 (or your instance thereof) have a high resolution
sched_clock()?
I'm not sure (FWIW, we did get support for NO_HZ and HIGH_RES_TIMERS in
2.6.24-rc as well, but playing with these config options and even
reverting the code didn't seem to have any effect), can someone from the
linuxppc-dev list answer this?
Another question, do you have:
CONFIG_FAIR_GROUP_SCHED=y
if so, does flipping that off have any effect?
I tried both, no difference that I could tell.
Is there any debugging information I could provide from running the test
on kernels built from at and before the change in question?
Thanks,
--
Earthling Michel Dänzer | http://tungstengraphics.com
Libre software enthusiast | Debian, X and DRI developer
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: crash in kmem_cache_init
On (23/01/08 13:14), Olaf Hering didst pronounce: On Wed, Jan 23, Mel Gorman wrote: Sorry this is dragging out. Can you post the full dmesg with loglevel=8 of the following patch against 2.6.24-rc8 please? It contains the debug information that helped me figure out what was going wrong on the PPC64 machine here, the revert and the !l3 checks (i.e. the two patches that made machines I have access to work). Thanks It boots with your change. ... Nice one! As the only addition here is debugging output, I can only assume that the two patches were being booted in isolation instead of combination earlier. The two threads have been a little confused with hand waving so that can easily happen. Looking at your log; early_node_map[1] active PFN ranges 1:0 - 892928 All memory on node 1 Online nodes o 0 o 1 Nodes with regular memory o 1 Current running CPU 0 is associated with node 0 Current node is 0 Running CPU associated with node 0 so other than being node 1 instead of node 2, your machine is similar to the one I had the problem on in terms of memoryless nodes and CPU configuration. VFS: Cannot open root device NULL or unknown-block(0,0) Please append a correct root= boot option; here are the available partitions: Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0) Rebooting in 1 seconds.. I see it failed to complete boot but I'm going to assume this is a relatively normal commane-line, .config or initrd problem and not a regression of some type. I'll post a patch suitable for pick-up shortly. The two patches ran in combination with CONFIG_DEBUG_SLAB a compile-based stress tests without difficulty so hopefully there is not new surprises hiding in the corners. Thanks Olaf. -- Mel Gorman Part-time Phd Student Linux Technology Center University of Limerick IBM Dublin Software Lab ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] Fix boot problem in situations where the boot CPU is running on a memoryless node
This patch in combination with a partial revert of commit
04231b3002ac53f8a64a7bd142fde3fa4b6808c6 fixes a regression between 2.6.23
and 2.6.24-rc8 where a PPC64 machine with all CPUS on a memoryless node fails
to boot. If approved by the SLAB maintainers, it should be merged for 2.6.24.
With memoryless-node configurations, it is possible that all the CPUs are
associated with a node with no memory. Early in the boot process, nodelists
are not setup that allow fallback_alloc to work, an Oops occurs and the
machine fails to boot.
This patch adds the necessary checks to make sure a kmem_list3 exists for
the preferred node used when growing the cache. If the preferred node has
no nodelist then the currently running node is used instead. This
problem only affects the SLAB allocator, SLUB appears to work fine.
Signed-off-by: Mel Gorman [EMAIL PROTECTED]
---
mm/slab.c |9 +
1 file changed, 9 insertions(+)
diff -rup -X /usr/src/patchset-0.6/bin//dontdiff
linux-2.6.24-rc8-005-revert-memoryless-slab/mm/slab.c
linux-2.6.24-rc8-010_handle_missing_l3/mm/slab.c
--- linux-2.6.24-rc8-005-revert-memoryless-slab/mm/slab.c 2008-01-22
17:46:32.0 +
+++ linux-2.6.24-rc8-010_handle_missing_l3/mm/slab.c2008-01-22
18:42:53.0 +
@@ -2775,6 +2775,11 @@ static int cache_grow(struct kmem_cache
/* Take the l3 list lock to change the colour_next on this node */
check_irq_off();
l3 = cachep-nodelists[nodeid];
+ if (!l3) {
+ nodeid = numa_node_id();
+ l3 = cachep-nodelists[nodeid];
+ }
+ BUG_ON(!l3);
spin_lock(l3-list_lock);
/* Get colour for the slab, and cal the next value. */
@@ -3317,6 +3322,10 @@ static void *cache_alloc_node(struct
int x;
l3 = cachep-nodelists[nodeid];
+ if (!l3) {
+ nodeid = numa_node_id();
+ l3 = cachep-nodelists[nodeid];
+ }
BUG_ON(!l3);
retry:
--
Mel Gorman
Part-time Phd Student Linux Technology Center
University of Limerick IBM Dublin Software Lab
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 2/3 v3] Add initial iomega StorCenter board port.
Stephen Rothwell wrote: Hi Jon, On Tue, 22 Jan 2008 16:37:59 -0600 Jon Loeliger [EMAIL PROTECTED] wrote: +++ b/arch/powerpc/platforms/embedded6xx/storcenter.c +extern void _nmask_and_or_msr(unsigned long nmask, unsigned long or_val); This clearly needs to be decalred in some header file. (I know you did not introduce it.) In arch/ppc, it was declared in asm/system.h (but I don't know if that is appropriate for arch/powerpc). Maybe you could do a preceeding patch that does this and fixes the other user. I hear my Janitorial Karmic Duty calling. +static void __init storcenter_init_IRQ(void) +prop = of_get_property(dnp, reg, size); +paddr = (phys_addr_t)of_translate_address(dnp, prop); What happens of prop is NULL? Someone should fix that case too. :-) Kumar, I'll respin this trio for you. jdl ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] Fix boot problem in situations where the boot CPU is running on a memoryless node
Hi Mel,
On Wed, 23 Jan 2008, Mel Gorman wrote:
diff -rup -X /usr/src/patchset-0.6/bin//dontdiff
linux-2.6.24-rc8-005-revert-memoryless-slab/mm/slab.c
linux-2.6.24-rc8-010_handle_missing_l3/mm/slab.c
--- linux-2.6.24-rc8-005-revert-memoryless-slab/mm/slab.c 2008-01-22
17:46:32.0 +
+++ linux-2.6.24-rc8-010_handle_missing_l3/mm/slab.c 2008-01-22
18:42:53.0 +
@@ -2775,6 +2775,11 @@ static int cache_grow(struct kmem_cache
/* Take the l3 list lock to change the colour_next on this node */
check_irq_off();
l3 = cachep-nodelists[nodeid];
+ if (!l3) {
+ nodeid = numa_node_id();
+ l3 = cachep-nodelists[nodeid];
+ }
+ BUG_ON(!l3);
spin_lock(l3-list_lock);
/* Get colour for the slab, and cal the next value. */
@@ -3317,6 +3322,10 @@ static void *cache_alloc_node(struct
int x;
l3 = cachep-nodelists[nodeid];
+ if (!l3) {
+ nodeid = numa_node_id();
+ l3 = cachep-nodelists[nodeid];
+ }
What guarantees that current node -nodelists is never NULL?
I still think Christoph's kmem_getpages() patch is correct (to fix
cache_grow() oops) but I overlooked the fact that none the callers of
cache_alloc_node() deal with bootstrapping (with the exception of
__cache_alloc_node() that even has a comment about it).
But what I am really wondering about is, why wasn't the
N_NORMAL_MEMORY revert enough? I assume this used to work before so what
more do we need to revert for 2.6.24?
Pekka
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] Fix boot problem in situations where the boot CPU is running on a memoryless node
On Wed, Jan 23, Mel Gorman wrote:
This patch in combination with a partial revert of commit
04231b3002ac53f8a64a7bd142fde3fa4b6808c6 fixes a regression between 2.6.23
and 2.6.24-rc8 where a PPC64 machine with all CPUS on a memoryless node fails
to boot. If approved by the SLAB maintainers, it should be merged for 2.6.24.
This change alone does not help, its not the version I tested.
Will all the changes below go into 2.6.24 as well, in a seperate patch?
- for_each_node_state(node, N_NORMAL_MEMORY) {
+ for_each_online_node(node) {
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 2/3] Convert PowerPC MPC i2c to of_platform_driver from platform_driver
So, like, the other day Jon Smirl mumbled: Convert MPC i2c driver from a platform_driver to a of_platform_driver. Add the ability to dynamically load i2c drivers based on device tree names. Routine names were changed from fsl_ to mpc_ to make them match the file name. Common code moved to powerpc-common.* Orginal ppc driver left intact for deletion when ppc arch is removed. This seems backwards to me. I was under the impression that our trend was _toward_ Freescale and fsl names...? And aren't the drivers also already using fsl-i2c in the DTS files as called out in the b-w-o.txt too? Grumble long lines not hard-limited to 70-ish columns, yes, even in log messages... :-) jdl ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] Fix boot problem in situations where the boot CPU is running on a memoryless node
On Wed, 23 Jan 2008, Pekka J Enberg wrote:
I still think Christoph's kmem_getpages() patch is correct (to fix
cache_grow() oops) but I overlooked the fact that none the callers of
cache_alloc_node() deal with bootstrapping (with the exception of
__cache_alloc_node() that even has a comment about it).
So something like this (totally untested) patch on top of current git:
---
mm/slab.c | 18 +-
1 file changed, 9 insertions(+), 9 deletions(-)
Index: linux-2.6/mm/slab.c
===
--- linux-2.6.orig/mm/slab.c
+++ linux-2.6/mm/slab.c
@@ -1668,7 +1668,11 @@ static void *kmem_getpages(struct kmem_c
if (cachep-flags SLAB_RECLAIM_ACCOUNT)
flags |= __GFP_RECLAIMABLE;
- page = alloc_pages_node(nodeid, flags, cachep-gfporder);
+ if (nodeid == -1)
+ page = alloc_pages(flags, cachep-gfporder);
+ else
+ page = alloc_pages_node(nodeid, flags, cachep-gfporder);
+
if (!page)
return NULL;
@@ -2976,8 +2980,9 @@ retry:
batchcount = BATCHREFILL_LIMIT;
}
l3 = cachep-nodelists[node];
+ if (!l3)
+ return NULL;
- BUG_ON(ac-avail 0 || !l3);
spin_lock(l3-list_lock);
/* See if we can refill from the shared array */
@@ -3317,7 +3322,8 @@ static void *cache_alloc_node(struct
int x;
l3 = cachep-nodelists[nodeid];
- BUG_ON(!l3);
+ if (!l3)
+ return fallback_alloc(cachep, flags);
retry:
check_irq_off();
@@ -3394,12 +3400,6 @@ __cache_alloc_node(struct kmem_cache *ca
if (unlikely(nodeid == -1))
nodeid = numa_node_id();
- if (unlikely(!cachep-nodelists[nodeid])) {
- /* Node not bootstrapped yet */
- ptr = fallback_alloc(cachep, flags);
- goto out;
- }
-
if (nodeid == numa_node_id()) {
/*
* Use the locally cached objects if possible.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCHv2] i2c: adds support for i2c bus on Frescale CPM1/CPM2 controllers
On 1/23/08, Jean Delvare [EMAIL PROTECTED] wrote: Hallo Jochen, On Wed, 23 Jan 2008 12:23:58 +0100, Jochen Friedrich wrote: Hi Jean, Do you have an updated patch addressing Stephen's comment? Note: you'd rather send updates of this patch to the i2c list rather than LKML. I'm currently looking at that last patches from Jon and try to make this driver fit in there (+ the class override stuff). I'm not sure what patches exactly you're talking about, but the aliasing stuff Jon and myself have been working on are still under debate. Your patch shouldn't assume that any of these patches will go upstream immediately, so your patch adding the i2c-cpm driver can ignore them. I'll update the patches before merging them as needed, do not worry too much about that. He wants the module name translation support I split out into powerpc-common.c. Note: will do. I just subscribed to this list. Note hat you do not need to be subscribed to post to the i2c list (but of course, if you have some interest in Linux i2c development, subscribing was a good idea anyway.) -- Jean Delvare -- Jon Smirl [EMAIL PROTECTED] ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 2/3] Convert PowerPC MPC i2c to of_platform_driver from platform_driver
On 1/23/08, Jon Loeliger [EMAIL PROTECTED] wrote: So, like, the other day Jon Smirl mumbled: Convert MPC i2c driver from a platform_driver to a of_platform_driver. Add the ability to dynamically load i2c drivers based on device tree names. Routine names were changed from fsl_ to mpc_ to make them match the file name. Common code moved to powerpc-common.* Orginal ppc driver left intact for deletion when ppc arch is removed. This seems backwards to me. I was under the impression that our trend was _toward_ Freescale and fsl names...? And aren't the drivers also already using fsl-i2c in the DTS files as called out in the b-w-o.txt too? The routine names should match the file name which then determines the module name. I didn't want to change the module name so I made the routines names match the module name. Grumble long lines not hard-limited to 70-ish columns, yes, even in log messages... :-) jdl -- Jon Smirl [EMAIL PROTECTED] ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] Fix boot problem in situations where the boot CPU is running on a memoryless node
Hi,
On Wed, 23 Jan 2008, Pekka J Enberg wrote:
I still think Christoph's kmem_getpages() patch is correct (to fix
cache_grow() oops) but I overlooked the fact that none the callers of
cache_alloc_node() deal with bootstrapping (with the exception of
__cache_alloc_node() that even has a comment about it).
So something like this (totally untested) patch on top of current git:
Sorry, removed a BUG_ON() from cache_alloc_refill() by mistake, here's a
better one:
[PATCH] slab: fix allocation on memoryless nodes
From: Pekka Enberg [EMAIL PROTECTED]
As memoryless nodes do not have a nodelist, change cache_alloc_refill() to bail
out for those and let cache_alloc_node() always deal with that by resorting
to fallback_alloc().
Furthermore, don't let kmem_getpages() call alloc_pages_node() if nodeid passed
to it is -1 as the latter will always translate that to numa_node_id() which
might not have -nodelist that caused the invocation of fallback_alloc() in the
first place (for example, during bootstrap).
Signed-off-by: Pekka Enberg [EMAIL PROTECTED]
---
mm/slab.c | 19 ++-
1 file changed, 10 insertions(+), 9 deletions(-)
Index: linux-2.6/mm/slab.c
===
--- linux-2.6.orig/mm/slab.c
+++ linux-2.6/mm/slab.c
@@ -1668,7 +1668,11 @@ static void *kmem_getpages(struct kmem_c
if (cachep-flags SLAB_RECLAIM_ACCOUNT)
flags |= __GFP_RECLAIMABLE;
- page = alloc_pages_node(nodeid, flags, cachep-gfporder);
+ if (nodeid == -1)
+ page = alloc_pages(flags, cachep-gfporder);
+ else
+ page = alloc_pages_node(nodeid, flags, cachep-gfporder);
+
if (!page)
return NULL;
@@ -2975,9 +2979,11 @@ retry:
*/
batchcount = BATCHREFILL_LIMIT;
}
+ BUG_ON(ac-avail 0);
l3 = cachep-nodelists[node];
+ if (!l3)
+ return NULL;
- BUG_ON(ac-avail 0 || !l3);
spin_lock(l3-list_lock);
/* See if we can refill from the shared array */
@@ -3317,7 +3323,8 @@ static void *cache_alloc_node(struct
int x;
l3 = cachep-nodelists[nodeid];
- BUG_ON(!l3);
+ if (!l3)
+ return fallback_alloc(cachep, flags);
retry:
check_irq_off();
@@ -3394,12 +3401,6 @@ __cache_alloc_node(struct kmem_cache *ca
if (unlikely(nodeid == -1))
nodeid = numa_node_id();
- if (unlikely(!cachep-nodelists[nodeid])) {
- /* Node not bootstrapped yet */
- ptr = fallback_alloc(cachep, flags);
- goto out;
- }
-
if (nodeid == numa_node_id()) {
/*
* Use the locally cached objects if possible.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] Fix boot problem in situations where the boot CPU is running on a memoryless node
On (23/01/08 15:27), Olaf Hering didst pronounce:
On Wed, Jan 23, Mel Gorman wrote:
This patch in combination with a partial revert of commit
04231b3002ac53f8a64a7bd142fde3fa4b6808c6 fixes a regression between 2.6.23
and 2.6.24-rc8 where a PPC64 machine with all CPUS on a memoryless node
fails
to boot. If approved by the SLAB maintainers, it should be merged for
2.6.24.
This change alone does not help, its not the version I tested.
Will all the changes below go into 2.6.24 as well, in a seperate patch?
- for_each_node_state(node, N_NORMAL_MEMORY) {
+ for_each_online_node(node) {
Those changes are already in a separate patch and have been sent. I don't
see it in git yet but it should be on the way.
--
Mel Gorman
Part-time Phd Student Linux Technology Center
University of Limerick IBM Dublin Software Lab
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] Fix boot problem in situations where the boot CPU is running on a memoryless node
On (23/01/08 16:49), Pekka J Enberg didst pronounce: Hi, On Wed, 23 Jan 2008, Pekka J Enberg wrote: I still think Christoph's kmem_getpages() patch is correct (to fix cache_grow() oops) but I overlooked the fact that none the callers of cache_alloc_node() deal with bootstrapping (with the exception of __cache_alloc_node() that even has a comment about it). So something like this (totally untested) patch on top of current git: Sorry, removed a BUG_ON() from cache_alloc_refill() by mistake, here's a better one: Applied in combination with the N_NORMAL_MEMORY revert and it fails to boot. Console is as follows; Linux version 2.6.24-rc8-autokern1 ([EMAIL PROTECTED]) (gcc version 3.4.6 20060404 (Red Hat 3.4.6-3)) #2 SMP Wed Jan 23 10:37:36 EST 2008 [boot]0012 Setup Arch EEH: PCI Enhanced I/O Error Handling Enabled PPC64 nvram contains 7168 bytes Zone PFN ranges: DMA 0 - 1048576 Normal1048576 - 1048576 Movable zone start PFN for each node early_node_map[1] active PFN ranges 2:0 - 1048576 Could not find start_pfn for node 0 [boot]0015 Setup Done Built 2 zonelists in Node order, mobility grouping on. Total pages: 1034240 Policy zone: DMA Kernel command line: ro console=hvc0 autobench_args: root=/dev/sda6 ABAT:1201101591 loglevel=8 [boot]0020 XICS Init xics: no ISA interrupt controller [boot]0021 XICS Done PID hash table entries: 4096 (order: 12, 32768 bytes) time_init: decrementer frequency = 238.059000 MHz time_init: processor frequency = 1904.472000 MHz clocksource: timebase mult[10cd746] shift[22] registered clockevent: decrementer mult[3cf1] shift[16] cpu[0] Console: colour dummy device 80x25 console handover: boot [udbg0] - real [hvc0] Dentry cache hash table entries: 524288 (order: 10, 4194304 bytes) Inode-cache hash table entries: 262144 (order: 9, 2097152 bytes) freeing bootmem node 2 Memory: 4105560k/4194304k available (5004k kernel code, 88744k reserved, 876k data, 559k bss, 272k init) Unable to handle kernel paging request for data at address 0x0040 Faulting instruction address: 0xc03c8ae8 cpu 0x0: Vector: 300 (Data Access) at [c05c3840] pc: c03c8ae8: __lock_text_start+0x20/0x88 lr: c00dadb4: .cache_grow+0x7c/0x338 sp: c05c3ac0 msr: 80009032 dar: 40 dsisr: 4000 current = 0xc0500f10 paca= 0xc0501b80 pid = 0, comm = swapper enter ? for help [c05c3b40] c00dadb4 .cache_grow+0x7c/0x338 [c05c3c00] c00db518 .fallback_alloc+0x1c0/0x224 [c05c3cb0] c00db920 .kmem_cache_alloc+0xe0/0x14c [c05c3d50] c00dcbd0 .kmem_cache_create+0x230/0x4cc [c05c3e30] c04c049c .kmem_cache_init+0x1ec/0x51c [c05c3ee0] c049f8d8 .start_kernel+0x304/0x3fc [c05c3f90] c0008594 .start_here_common+0x54/0xc0 0xc00dadb4 is in cache_grow (mm/slab.c:2782). 2777local_flags = flags (GFP_CONSTRAINT_MASK|GFP_RECLAIM_MASK); 2778 2779/* Take the l3 list lock to change the colour_next on this node */ 2780check_irq_off(); 2781l3 = cachep-nodelists[nodeid]; 2782spin_lock(l3-list_lock); 2783 2784/* Get colour for the slab, and cal the next value. */ 2785offset = l3-colour_next; 2786l3-colour_next++; -- Mel Gorman Part-time Phd Student Linux Technology Center University of Limerick IBM Dublin Software Lab ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCHv2 0/8] [POWERPC] 8xx cleanups
Hi, this is a series against paulus for-2.6.25 tree to clean up various 8xx related stuff. The series can be pulled from git://git.bocc.de/dbox2.git cleanup. Patch 6 has been modified to remove the #ifdefs as suggested by Arndt Bergmann. Patch 8 is a new one. [POWERPC] Remove unused m8xx_cpm_hostalloc/free/dump() [POWERPC] Rename m8xx_pic_init to mpc8xx_pics_init [POWERPC] Remove unneeded and misspelled prototype m8xx_calibrate_decr [POWERPC] Remove declaration of m8xx_pic_init. [POWERPC] Remove sysdev/commproc.h [POWERPC] Get rid of conditional includes of board specific setup [POWERPC] Rename commproc to cpm1 and cpm2_common.c to cpm2.c [POWERPC] Move definition of buffer descriptor to cpm.h Thanks, Jochen ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCHv2 1/8] [POWERPC] Remove unused m8xx_cpm_hostalloc/free/dump()
m8xx_cpm_hostalloc is still defined in commproc.c, but no users are left
in the kernel tree. m8xx_cpm_hostfree and m8xx_cpm_hostdump are only
defined in the headers. Remove this dead code.
Signed-off-by: Jochen Friedrich [EMAIL PROTECTED]
---
arch/powerpc/sysdev/commproc.c | 37 -
arch/ppc/8xx_io/commproc.c | 38 --
include/asm-powerpc/commproc.h |4
include/asm-ppc/commproc.h |4
4 files changed, 0 insertions(+), 83 deletions(-)
diff --git a/arch/powerpc/sysdev/commproc.c b/arch/powerpc/sysdev/commproc.c
index 621bc6c..818d4b0 100644
--- a/arch/powerpc/sysdev/commproc.c
+++ b/arch/powerpc/sysdev/commproc.c
@@ -48,8 +48,6 @@
#ifndef CONFIG_PPC_CPM_NEW_BINDING
static void m8xx_cpm_dpinit(void);
#endif
-static uint host_buffer; /* One page of host buffer */
-static uint host_end;/* end + 1 */
cpm8xx_t __iomem *cpmp; /* Pointer to comm processor space */
immap_t __iomem *mpc8xx_immr;
static cpic8xx_t __iomem *cpic_reg;
@@ -268,41 +266,6 @@ out:
}
EXPORT_SYMBOL(cpm_command);
-/* We used to do this earlier, but have to postpone as long as possible
- * to ensure the kernel VM is now running.
- */
-static void
-alloc_host_memory(void)
-{
- dma_addr_t physaddr;
-
- /* Set the host page for allocation.
- */
- host_buffer = (uint)dma_alloc_coherent(NULL, PAGE_SIZE, physaddr,
- GFP_KERNEL);
- host_end = host_buffer + PAGE_SIZE;
-}
-
-/* We also own one page of host buffer space for the allocation of
- * UART fifos and the like.
- */
-uint
-m8xx_cpm_hostalloc(uint size)
-{
- uintretloc;
-
- if (host_buffer == 0)
- alloc_host_memory();
-
- if ((host_buffer + size) = host_end)
- return(0);
-
- retloc = host_buffer;
- host_buffer += size;
-
- return(retloc);
-}
-
/* Set a baud rate generator. This needs lots of work. There are
* four BRGs, any of which can be wired to any channel.
* The internal baud rate clock is the system clock divided by 16.
diff --git a/arch/ppc/8xx_io/commproc.c b/arch/ppc/8xx_io/commproc.c
index 9da880b..3f93af8 100644
--- a/arch/ppc/8xx_io/commproc.c
+++ b/arch/ppc/8xx_io/commproc.c
@@ -55,8 +55,6 @@
})
static void m8xx_cpm_dpinit(void);
-static uinthost_buffer;/* One page of host buffer */
-static uinthost_end; /* end + 1 */
cpm8xx_t *cpmp; /* Pointer to comm processor space */
/* CPM interrupt vector functions.
@@ -68,7 +66,6 @@ structcpm_action {
staticstruct cpm_action cpm_vecs[CPMVEC_NR];
staticirqreturn_t cpm_interrupt(int irq, void * dev);
staticirqreturn_t cpm_error_interrupt(int irq, void *dev);
-static voidalloc_host_memory(void);
/* Define a table of names to identify CPM interrupt handlers in
* /proc/interrupts.
*/
@@ -158,21 +155,6 @@ m8xx_cpm_reset(void)
cpmp = (cpm8xx_t *)commproc;
}
-/* We used to do this earlier, but have to postpone as long as possible
- * to ensure the kernel VM is now running.
- */
-static void
-alloc_host_memory(void)
-{
- dma_addr_t physaddr;
-
- /* Set the host page for allocation.
- */
- host_buffer = (uint)dma_alloc_coherent(NULL, PAGE_SIZE, physaddr,
- GFP_KERNEL);
- host_end = host_buffer + PAGE_SIZE;
-}
-
/* This is called during init_IRQ. We used to do it above, but this
* was too early since init_IRQ was not yet called.
*/
@@ -319,26 +301,6 @@ cpm_free_handler(int cpm_vec)
cpm_vecs[cpm_vec].dev_id = NULL;
}
-/* We also own one page of host buffer space for the allocation of
- * UART fifos and the like.
- */
-uint
-m8xx_cpm_hostalloc(uint size)
-{
- uintretloc;
-
- if (host_buffer == 0)
- alloc_host_memory();
-
- if ((host_buffer + size) = host_end)
- return(0);
-
- retloc = host_buffer;
- host_buffer += size;
-
- return(retloc);
-}
-
/* Set a baud rate generator. This needs lots of work. There are
* four BRGs, any of which can be wired to any channel.
* The internal baud rate clock is the system clock divided by 16.
diff --git a/include/asm-powerpc/commproc.h b/include/asm-powerpc/commproc.h
index 9e3b864..9757521 100644
--- a/include/asm-powerpc/commproc.h
+++ b/include/asm-powerpc/commproc.h
@@ -87,10 +87,6 @@ extern uint cpm_dpram_phys(u8* addr);
extern void cpm_setbrg(uint brg, uint rate);
-extern uint m8xx_cpm_hostalloc(uint size);
-extern int m8xx_cpm_hostfree(uint start);
-extern void m8xx_cpm_hostdump(void);
-
extern void cpm_load_patch(cpm8xx_t *cp);
/* Buffer descriptors used by many of the CPM protocols.
diff --git a/include/asm-ppc/commproc.h b/include/asm-ppc/commproc.h
index 462abb1..5418d6d 100644
--- a/include/asm-ppc/commproc.h
+++ b/include/asm-ppc/commproc.h
@@ -75,10 +75,6 @@ extern void
[PATCHv2 3/8] [POWERPC] Remove unneeded and misspelled prototype m8xx_calibrate_decr
m8xx_calibrate_decr seems to be a misspelled prototype for mpc8xx_calibrate_decr. As it's not needed anyways, just remove it. Signed-off-by: Jochen Friedrich [EMAIL PROTECTED] --- arch/powerpc/platforms/8xx/m8xx_setup.c |1 - 1 files changed, 0 insertions(+), 1 deletions(-) diff --git a/arch/powerpc/platforms/8xx/m8xx_setup.c b/arch/powerpc/platforms/8xx/m8xx_setup.c index 1337457..85abd61 100644 --- a/arch/powerpc/platforms/8xx/m8xx_setup.c +++ b/arch/powerpc/platforms/8xx/m8xx_setup.c @@ -31,7 +31,6 @@ struct mpc8xx_pcmcia_ops m8xx_pcmcia_ops; #endif -void m8xx_calibrate_decr(void); extern int cpm_pic_init(void); extern int cpm_get_irq(void); -- 1.5.3.8 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCHv2 4/8] [POWERPC] Remove declaration of m8xx_pic_init.
m8xx_pic_init is declared in ppc8xx_pic.h but defined nowhere in the ppc tree. Remove it. Signed-off-by: Jochen Friedrich [EMAIL PROTECTED] --- arch/ppc/syslib/ppc8xx_pic.h |1 - 1 files changed, 0 insertions(+), 1 deletions(-) diff --git a/arch/ppc/syslib/ppc8xx_pic.h b/arch/ppc/syslib/ppc8xx_pic.h index d7d9f65..53bcd97 100644 --- a/arch/ppc/syslib/ppc8xx_pic.h +++ b/arch/ppc/syslib/ppc8xx_pic.h @@ -6,7 +6,6 @@ extern struct hw_interrupt_type ppc8xx_pic; -void m8xx_pic_init(void); void m8xx_do_IRQ(struct pt_regs *regs, intcpu); int m8xx_get_irq(struct pt_regs *regs); -- 1.5.3.8 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCHv2 5/8] [POWERPC] Remove sysdev/commproc.h
Move cpm1 specific prototypes to asm/commproc.h and mpc8xx specific
prototypes to asm/mpc8xx.h. Adjust includes accordingly. Remove now
unneeded sysdev/commproc.h.
Signed-off-by: Jochen Friedrich [EMAIL PROTECTED]
---
arch/powerpc/platforms/8xx/ep88xc.c |3 +--
arch/powerpc/platforms/8xx/m8xx_setup.c |1 -
arch/powerpc/platforms/8xx/mpc86xads_setup.c |2 --
arch/powerpc/platforms/8xx/mpc885ads_setup.c |2 --
arch/powerpc/sysdev/commproc.c |1 -
arch/powerpc/sysdev/commproc.h | 12
arch/powerpc/sysdev/mpc8xx_pic.c |1 -
drivers/net/fs_enet/mac-scc.c|1 -
include/asm-powerpc/commproc.h |2 ++
include/asm-powerpc/mpc8xx.h |7 +++
10 files changed, 10 insertions(+), 22 deletions(-)
delete mode 100644 arch/powerpc/sysdev/commproc.h
diff --git a/arch/powerpc/platforms/8xx/ep88xc.c
b/arch/powerpc/platforms/8xx/ep88xc.c
index c883c31..9365f07 100644
--- a/arch/powerpc/platforms/8xx/ep88xc.c
+++ b/arch/powerpc/platforms/8xx/ep88xc.c
@@ -16,8 +16,7 @@
#include asm/io.h
#include asm/udbg.h
#include asm/commproc.h
-
-#include sysdev/commproc.h
+#include asm/mpc8xx.h
struct cpm_pin {
int port, pin, flags;
diff --git a/arch/powerpc/platforms/8xx/m8xx_setup.c
b/arch/powerpc/platforms/8xx/m8xx_setup.c
index 85abd61..c6a4663 100644
--- a/arch/powerpc/platforms/8xx/m8xx_setup.c
+++ b/arch/powerpc/platforms/8xx/m8xx_setup.c
@@ -25,7 +25,6 @@
#include mm/mmu_decl.h
#include sysdev/mpc8xx_pic.h
-#include sysdev/commproc.h
#ifdef CONFIG_PCMCIA_M8XX
struct mpc8xx_pcmcia_ops m8xx_pcmcia_ops;
diff --git a/arch/powerpc/platforms/8xx/mpc86xads_setup.c
b/arch/powerpc/platforms/8xx/mpc86xads_setup.c
index dea1df1..7389590 100644
--- a/arch/powerpc/platforms/8xx/mpc86xads_setup.c
+++ b/arch/powerpc/platforms/8xx/mpc86xads_setup.c
@@ -27,8 +27,6 @@
#include asm/fs_pd.h
#include asm/udbg.h
-#include sysdev/commproc.h
-
#include mpc86xads.h
struct cpm_pin {
diff --git a/arch/powerpc/platforms/8xx/mpc885ads_setup.c
b/arch/powerpc/platforms/8xx/mpc885ads_setup.c
index 8f2aa04..ae69e93 100644
--- a/arch/powerpc/platforms/8xx/mpc885ads_setup.c
+++ b/arch/powerpc/platforms/8xx/mpc885ads_setup.c
@@ -40,8 +40,6 @@
#include asm/fs_pd.h
#include asm/udbg.h
-#include sysdev/commproc.h
-
static u32 __iomem *bcsr, *bcsr5;
#ifdef CONFIG_PCMCIA_M8XX
diff --git a/arch/powerpc/sysdev/commproc.c b/arch/powerpc/sysdev/commproc.c
index 818d4b0..ef82587 100644
--- a/arch/powerpc/sysdev/commproc.c
+++ b/arch/powerpc/sysdev/commproc.c
@@ -30,7 +30,6 @@
#include linux/interrupt.h
#include linux/irq.h
#include linux/module.h
-#include asm/mpc8xx.h
#include asm/page.h
#include asm/pgtable.h
#include asm/8xx_immap.h
diff --git a/arch/powerpc/sysdev/commproc.h b/arch/powerpc/sysdev/commproc.h
deleted file mode 100644
index f481adf..000
--- a/arch/powerpc/sysdev/commproc.h
+++ /dev/null
@@ -1,12 +0,0 @@
-#ifndef _POWERPC_SYSDEV_COMMPROC_H
-#define _POWERPC_SYSDEV_COMMPROC_H
-
-extern void cpm_reset(void);
-extern void mpc8xx_restart(char *cmd);
-extern void mpc8xx_calibrate_decr(void);
-extern int mpc8xx_set_rtc_time(struct rtc_time *tm);
-extern void mpc8xx_get_rtc_time(struct rtc_time *tm);
-extern void mpc8xx_pics_init(void);
-extern unsigned int mpc8xx_get_irq(void);
-
-#endif
diff --git a/arch/powerpc/sysdev/mpc8xx_pic.c b/arch/powerpc/sysdev/mpc8xx_pic.c
index 7aa4ff5..0e74a4b 100644
--- a/arch/powerpc/sysdev/mpc8xx_pic.c
+++ b/arch/powerpc/sysdev/mpc8xx_pic.c
@@ -10,7 +10,6 @@
#include asm/irq.h
#include asm/io.h
#include asm/8xx_immap.h
-#include asm/mpc8xx.h
#include mpc8xx_pic.h
diff --git a/drivers/net/fs_enet/mac-scc.c b/drivers/net/fs_enet/mac-scc.c
index fe3d8a6..1502dbf 100644
--- a/drivers/net/fs_enet/mac-scc.c
+++ b/drivers/net/fs_enet/mac-scc.c
@@ -39,7 +39,6 @@
#ifdef CONFIG_8xx
#include asm/8xx_immap.h
#include asm/pgtable.h
-#include asm/mpc8xx.h
#include asm/commproc.h
#endif
diff --git a/include/asm-powerpc/commproc.h b/include/asm-powerpc/commproc.h
index 9757521..ec87b8f 100644
--- a/include/asm-powerpc/commproc.h
+++ b/include/asm-powerpc/commproc.h
@@ -89,6 +89,8 @@ extern void cpm_setbrg(uint brg, uint rate);
extern void cpm_load_patch(cpm8xx_t *cp);
+extern void cpm_reset(void);
+
/* Buffer descriptors used by many of the CPM protocols.
*/
typedef struct cpm_buf_desc {
diff --git a/include/asm-powerpc/mpc8xx.h b/include/asm-powerpc/mpc8xx.h
index 2be014b..2af9fcb 100644
--- a/include/asm-powerpc/mpc8xx.h
+++ b/include/asm-powerpc/mpc8xx.h
@@ -11,6 +11,13 @@
#ifdef CONFIG_8xx
+extern void mpc8xx_restart(char *cmd);
+extern void mpc8xx_calibrate_decr(void);
+extern int mpc8xx_set_rtc_time(struct rtc_time *tm);
+extern void mpc8xx_get_rtc_time(struct rtc_time *tm);
+extern void mpc8xx_pics_init(void);
+extern unsigned int mpc8xx_get_irq(void);
+
#ifdef CONFIG_FADS
[PATCHv2 6/8] [POWERPC] Get rid of conditional includes of board specific setup
Directly include mpc885ads.h from mpc885ads_setup.c. Now we can get rid of the arch dependent includes in mpc8xx.h. Signed-off-by: Jochen Friedrich [EMAIL PROTECTED] --- arch/powerpc/platforms/8xx/mpc885ads_setup.c |2 + include/asm-powerpc/mpc8xx.h | 34 +++--- 2 files changed, 11 insertions(+), 25 deletions(-) diff --git a/arch/powerpc/platforms/8xx/mpc885ads_setup.c b/arch/powerpc/platforms/8xx/mpc885ads_setup.c index ae69e93..426b897 100644 --- a/arch/powerpc/platforms/8xx/mpc885ads_setup.c +++ b/arch/powerpc/platforms/8xx/mpc885ads_setup.c @@ -40,6 +40,8 @@ #include asm/fs_pd.h #include asm/udbg.h +#include mpc885ads.h + static u32 __iomem *bcsr, *bcsr5; #ifdef CONFIG_PCMCIA_M8XX diff --git a/include/asm-powerpc/mpc8xx.h b/include/asm-powerpc/mpc8xx.h index 2af9fcb..70fd8a7 100644 --- a/include/asm-powerpc/mpc8xx.h +++ b/include/asm-powerpc/mpc8xx.h @@ -1,16 +1,16 @@ -/* This is the single file included by all MPC8xx build options. - * Since there are many different boards and no standard configuration, - * we have a unique include file for each. Rather than change every - * file that has to include MPC8xx configuration, they all include - * this one and the configuration switching is done here. +/* + * Prototypes, etc. for the Freescale MPC8xx embedded cpu chips + * May need to be cleaned as the port goes on ... + * + * Copyright (C) 2008 Jochen Friedrich [EMAIL PROTECTED] + * + * This file is licensed under the terms of the GNU General Public License + * version 2. This program is licensed as is without any warranty of any + * kind, whether express or implied. */ -#ifdef __KERNEL__ #ifndef __CONFIG_8xx_DEFS #define __CONFIG_8xx_DEFS - -#ifdef CONFIG_8xx - extern void mpc8xx_restart(char *cmd); extern void mpc8xx_calibrate_decr(void); extern int mpc8xx_set_rtc_time(struct rtc_time *tm); @@ -18,22 +18,6 @@ extern void mpc8xx_get_rtc_time(struct rtc_time *tm); extern void mpc8xx_pics_init(void); extern unsigned int mpc8xx_get_irq(void); -#ifdef CONFIG_FADS -#include platforms/fads.h -#endif - -#if defined(CONFIG_MPC86XADS) -#include platforms/8xx/mpc86xads.h -#endif - -#if defined(CONFIG_MPC885ADS) -#include platforms/8xx/mpc885ads.h -#endif - -#ifdef CONFIG_PCMCIA_M8XX extern struct mpc8xx_pcmcia_ops m8xx_pcmcia_ops; -#endif -#endif /* CONFIG_8xx */ #endif /* __CONFIG_8xx_DEFS */ -#endif /* __KERNEL__ */ -- 1.5.3.8 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCHv2 7/8] [POWERPC] Rename commproc to cpm1 and cpm2_common.c to cpm2.c
Rename commproc.[ch] to cpm1.[ch] to be more consistent with cpm2. Also
rename cpm2_common.c to cpm2.c as suggested by Scott Wood. Adjust the
includes accordingly.
Signed-off-by: Jochen Friedrich [EMAIL PROTECTED]
---
arch/powerpc/platforms/8xx/ep88xc.c |2 +-
arch/powerpc/platforms/8xx/mpc86xads_setup.c |2 +-
arch/powerpc/platforms/8xx/mpc885ads_setup.c |2 +-
arch/powerpc/sysdev/Makefile |4 ++--
arch/powerpc/sysdev/{commproc.c = cpm1.c}|4 ++--
arch/powerpc/sysdev/{cpm2_common.c = cpm2.c} |3 +--
arch/powerpc/sysdev/micropatch.c |2 +-
arch/ppc/8260_io/enet.c |2 +-
arch/ppc/8xx_io/commproc.c|2 +-
arch/ppc/8xx_io/enet.c|6 +++---
arch/ppc/8xx_io/fec.c |2 +-
arch/ppc/8xx_io/micropatch.c |2 +-
arch/ppc/boot/simple/iic.c|2 +-
arch/ppc/boot/simple/m8xx_tty.c |2 +-
arch/ppc/kernel/ppc_ksyms.c |2 +-
arch/ppc/platforms/mpc866ads_setup.c |2 +-
arch/ppc/platforms/mpc885ads_setup.c |2 +-
arch/ppc/syslib/mpc8xx_devices.c |2 +-
arch/ppc/xmon/start_8xx.c |2 +-
drivers/net/fec.c |2 +-
drivers/net/fec.h |2 +-
drivers/net/fec_8xx/fec_8xx-netta.c |2 +-
drivers/net/fec_8xx/fec_main.c|2 +-
drivers/net/fec_8xx/fec_mii.c |2 +-
drivers/net/fs_enet/fs_enet.h |2 +-
drivers/net/fs_enet/mac-fec.c |2 +-
drivers/net/fs_enet/mac-scc.c |2 +-
drivers/serial/68360serial.c |2 +-
drivers/serial/cpm_uart/cpm_uart_cpm1.h |2 +-
include/asm-powerpc/{commproc.h = cpm1.h}|8
include/asm-ppc/{commproc.h = cpm1.h}|8
31 files changed, 41 insertions(+), 42 deletions(-)
rename arch/powerpc/sysdev/{commproc.c = cpm1.c} (99%)
rename arch/powerpc/sysdev/{cpm2_common.c = cpm2.c} (99%)
rename include/asm-powerpc/{commproc.h = cpm1.h} (99%)
rename include/asm-ppc/{commproc.h = cpm1.h} (99%)
diff --git a/arch/powerpc/platforms/8xx/ep88xc.c
b/arch/powerpc/platforms/8xx/ep88xc.c
index 9365f07..d300576 100644
--- a/arch/powerpc/platforms/8xx/ep88xc.c
+++ b/arch/powerpc/platforms/8xx/ep88xc.c
@@ -15,7 +15,7 @@
#include asm/machdep.h
#include asm/io.h
#include asm/udbg.h
-#include asm/commproc.h
+#include asm/cpm1.h
#include asm/mpc8xx.h
struct cpm_pin {
diff --git a/arch/powerpc/platforms/8xx/mpc86xads_setup.c
b/arch/powerpc/platforms/8xx/mpc86xads_setup.c
index 7389590..a68509d 100644
--- a/arch/powerpc/platforms/8xx/mpc86xads_setup.c
+++ b/arch/powerpc/platforms/8xx/mpc86xads_setup.c
@@ -23,7 +23,7 @@
#include asm/time.h
#include asm/mpc8xx.h
#include asm/8xx_immap.h
-#include asm/commproc.h
+#include asm/cpm1.h
#include asm/fs_pd.h
#include asm/udbg.h
diff --git a/arch/powerpc/platforms/8xx/mpc885ads_setup.c
b/arch/powerpc/platforms/8xx/mpc885ads_setup.c
index 426b897..f39447b 100644
--- a/arch/powerpc/platforms/8xx/mpc885ads_setup.c
+++ b/arch/powerpc/platforms/8xx/mpc885ads_setup.c
@@ -36,7 +36,7 @@
#include asm/time.h
#include asm/mpc8xx.h
#include asm/8xx_immap.h
-#include asm/commproc.h
+#include asm/cpm1.h
#include asm/fs_pd.h
#include asm/udbg.h
diff --git a/arch/powerpc/sysdev/Makefile b/arch/powerpc/sysdev/Makefile
index 9a20ef4..61f2604 100644
--- a/arch/powerpc/sysdev/Makefile
+++ b/arch/powerpc/sysdev/Makefile
@@ -35,8 +35,8 @@ endif
# Temporary hack until we have migrated to asm-powerpc
ifeq ($(ARCH),powerpc)
obj-$(CONFIG_CPM) += cpm_common.o
-obj-$(CONFIG_CPM2) += cpm2_common.o cpm2_pic.o
+obj-$(CONFIG_CPM2) += cpm2.o cpm2_pic.o
obj-$(CONFIG_PPC_DCR) += dcr.o
-obj-$(CONFIG_8xx) += mpc8xx_pic.o commproc.o
+obj-$(CONFIG_8xx) += mpc8xx_pic.o cpm1.o
obj-$(CONFIG_UCODE_PATCH) += micropatch.o
endif
diff --git a/arch/powerpc/sysdev/commproc.c b/arch/powerpc/sysdev/cpm1.c
similarity index 99%
rename from arch/powerpc/sysdev/commproc.c
rename to arch/powerpc/sysdev/cpm1.c
index ef82587..df8bd2b 100644
--- a/arch/powerpc/sysdev/commproc.c
+++ b/arch/powerpc/sysdev/cpm1.c
@@ -33,7 +33,7 @@
#include asm/page.h
#include asm/pgtable.h
#include asm/8xx_immap.h
-#include asm/commproc.h
+#include asm/cpm1.h
#include asm/io.h
#include asm/tlbflush.h
#include asm/rheap.h
@@ -290,7 +290,7 @@ cpm_setbrg(uint brg, uint rate)
out_be32(bp, (((BRG_UART_CLK / rate) - 1) 1) | CPM_BRG_EN);
else
out_be32(bp, (((BRG_UART_CLK_DIV16 / rate) - 1) 1) |
-CPM_BRG_EN | CPM_BRG_DIV16);
+ CPM_BRG_EN | CPM_BRG_DIV16);
[PATCHv2 8/8] [POWERPC] Move definition of buffer descriptor to cpm.h
Buffer descriptors are used by both CPM1 and CPM2. Move the definitions
from the cpm dependent include file to common cpm.h
Signed-off-by: Jochen Friedrich [EMAIL PROTECTED]
---
include/asm-powerpc/cpm.h | 73
include/asm-powerpc/cpm1.h | 65 ---
include/asm-powerpc/cpm2.h | 64 --
3 files changed, 73 insertions(+), 129 deletions(-)
diff --git a/include/asm-powerpc/cpm.h b/include/asm-powerpc/cpm.h
index fae83b1..77e39da 100644
--- a/include/asm-powerpc/cpm.h
+++ b/include/asm-powerpc/cpm.h
@@ -4,6 +4,79 @@
#include linux/compiler.h
#include linux/types.h
+/* Buffer descriptors used by many of the CPM protocols. */
+typedef struct cpm_buf_desc {
+ ushort cbd_sc; /* Status and Control */
+ ushort cbd_datlen; /* Data length in buffer */
+ uintcbd_bufaddr;/* Buffer address in host memory */
+} cbd_t;
+
+/* Buffer descriptor control/status used by serial
+ */
+
+#define BD_SC_EMPTY(0x8000)/* Receive is empty */
+#define BD_SC_READY(0x8000)/* Transmit is ready */
+#define BD_SC_WRAP (0x2000)/* Last buffer descriptor */
+#define BD_SC_INTRPT (0x1000)/* Interrupt on change */
+#define BD_SC_LAST (0x0800)/* Last buffer in frame */
+#define BD_SC_TC (0x0400)/* Transmit CRC */
+#define BD_SC_CM (0x0200)/* Continous mode */
+#define BD_SC_ID (0x0100)/* Rec'd too many idles */
+#define BD_SC_P(0x0100)/* xmt preamble */
+#define BD_SC_BR (0x0020)/* Break received */
+#define BD_SC_FR (0x0010)/* Framing error */
+#define BD_SC_PR (0x0008)/* Parity error */
+#define BD_SC_NAK (0x0004)/* NAK - did not respond */
+#define BD_SC_OV (0x0002)/* Overrun */
+#define BD_SC_UN (0x0002)/* Underrun */
+#define BD_SC_CD (0x0001)/* */
+#define BD_SC_CL (0x0001)/* Collision */
+
+/* Buffer descriptor control/status used by Ethernet receive.
+ * Common to SCC and FCC.
+ */
+#define BD_ENET_RX_EMPTY (0x8000)
+#define BD_ENET_RX_WRAP(0x2000)
+#define BD_ENET_RX_INTR(0x1000)
+#define BD_ENET_RX_LAST(0x0800)
+#define BD_ENET_RX_FIRST (0x0400)
+#define BD_ENET_RX_MISS(0x0100)
+#define BD_ENET_RX_BC (0x0080)/* FCC Only */
+#define BD_ENET_RX_MC (0x0040)/* FCC Only */
+#define BD_ENET_RX_LG (0x0020)
+#define BD_ENET_RX_NO (0x0010)
+#define BD_ENET_RX_SH (0x0008)
+#define BD_ENET_RX_CR (0x0004)
+#define BD_ENET_RX_OV (0x0002)
+#define BD_ENET_RX_CL (0x0001)
+#define BD_ENET_RX_STATS (0x01ff)/* All status bits */
+
+/* Buffer descriptor control/status used by Ethernet transmit.
+ * Common to SCC and FCC.
+ */
+#define BD_ENET_TX_READY (0x8000)
+#define BD_ENET_TX_PAD (0x4000)
+#define BD_ENET_TX_WRAP(0x2000)
+#define BD_ENET_TX_INTR(0x1000)
+#define BD_ENET_TX_LAST(0x0800)
+#define BD_ENET_TX_TC (0x0400)
+#define BD_ENET_TX_DEF (0x0200)
+#define BD_ENET_TX_HB (0x0100)
+#define BD_ENET_TX_LC (0x0080)
+#define BD_ENET_TX_RL (0x0040)
+#define BD_ENET_TX_RCMASK (0x003c)
+#define BD_ENET_TX_UN (0x0002)
+#define BD_ENET_TX_CSL (0x0001)
+#define BD_ENET_TX_STATS (0x03ff)/* All status bits */
+
+/* Buffer descriptor control/status used by Transparent mode SCC.
+ */
+#define BD_SCC_TX_LAST (0x0800)
+
+/* Buffer descriptor control/status used by I2C.
+ */
+#define BD_I2C_START (0x0400)
+
int cpm_muram_init(void);
unsigned long cpm_muram_alloc(unsigned long size, unsigned long align);
int cpm_muram_free(unsigned long offset);
diff --git a/include/asm-powerpc/cpm1.h b/include/asm-powerpc/cpm1.h
index 901a00b..b2ebd6a 100644
--- a/include/asm-powerpc/cpm1.h
+++ b/include/asm-powerpc/cpm1.h
@@ -91,32 +91,6 @@ extern void cpm_load_patch(cpm8xx_t *cp);
extern void cpm_reset(void);
-/* Buffer descriptors used by many of the CPM protocols.
-*/
-typedef struct cpm_buf_desc {
- ushort cbd_sc; /* Status and Control */
- ushort cbd_datlen; /* Data length in buffer */
- uintcbd_bufaddr;/* Buffer address in host memory */
-} cbd_t;
-
-#define BD_SC_EMPTY((ushort)0x8000)/* Receive is empty */
-#define BD_SC_READY((ushort)0x8000)/* Transmit is ready */
-#define BD_SC_WRAP ((ushort)0x2000)/* Last buffer descriptor */
-#define BD_SC_INTRPT ((ushort)0x1000)/* Interrupt on change */
-#define BD_SC_LAST ((ushort)0x0800)/* Last buffer in frame */
-#define BD_SC_TC ((ushort)0x0400)/* Transmit CRC */
-#define BD_SC_CM
Re: [PATCHv2 5/8] [POWERPC] Remove sysdev/commproc.h
On Jan 23, 2008, at 10:00 AM, Jochen Friedrich wrote: Move cpm1 specific prototypes to asm/commproc.h and mpc8xx specific prototypes to asm/mpc8xx.h. Adjust includes accordingly. Remove now unneeded sysdev/commproc.h. Signed-off-by: Jochen Friedrich [EMAIL PROTECTED] --- arch/powerpc/platforms/8xx/ep88xc.c |3 +-- arch/powerpc/platforms/8xx/m8xx_setup.c |1 - arch/powerpc/platforms/8xx/mpc86xads_setup.c |2 -- arch/powerpc/platforms/8xx/mpc885ads_setup.c |2 -- arch/powerpc/sysdev/commproc.c |1 - arch/powerpc/sysdev/commproc.h | 12 arch/powerpc/sysdev/mpc8xx_pic.c |1 - drivers/net/fs_enet/mac-scc.c|1 - include/asm-powerpc/commproc.h |2 ++ include/asm-powerpc/mpc8xx.h |7 +++ Do we really need the prototypes you moved into asm/mpc8xx.h here? can they just live in platforms/8xx/8xx.h or something like that? - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCHv2 4/8] [POWERPC] Remove declaration of m8xx_pic_init.
On Jan 23, 2008, at 10:00 AM, Jochen Friedrich wrote: m8xx_pic_init is declared in ppc8xx_pic.h but defined nowhere in the ppc tree. Remove it. Signed-off-by: Jochen Friedrich [EMAIL PROTECTED] if we respin the patches, merge this with 2/8 - Rename m8xx_pic_init to mpc8xx_pics_init. (otherwise i'll merge when I commit). - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCHv2 0/8] [POWERPC] 8xx cleanups
On Jan 23, 2008, at 9:58 AM, Jochen Friedrich wrote: Hi, this is a series against paulus for-2.6.25 tree to clean up various 8xx related stuff. The series can be pulled from git://git.bocc.de/dbox2.git cleanup. Patch 6 has been modified to remove the #ifdefs as suggested by Arndt Bergmann. Patch 8 is a new one. [POWERPC] Remove unused m8xx_cpm_hostalloc/free/dump() [POWERPC] Rename m8xx_pic_init to mpc8xx_pics_init [POWERPC] Remove unneeded and misspelled prototype m8xx_calibrate_decr [POWERPC] Remove declaration of m8xx_pic_init. [POWERPC] Remove sysdev/commproc.h [POWERPC] Get rid of conditional includes of board specific setup [POWERPC] Rename commproc to cpm1 and cpm2_common.c to cpm2.c [POWERPC] Move definition of buffer descriptor to cpm.h These roughly look good, had a few comments. Don't see any reason why they can't go in. What impact do the have on boards in arch/ppc being able to build? - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCHv2 2/8] [POWERPC] Rename m8xx_pic_init to mpc8xx_pics_init
m8xx_pic_init calls both mpc8xx_pic_init and cpm_pic_init. Renaming the
function to use the same name space as the rest of the mpc8xx
specific funtions and to be more meaningful.
Signed-off-by: Jochen Friedrich [EMAIL PROTECTED]
---
arch/powerpc/platforms/8xx/ep88xc.c |2 +-
arch/powerpc/platforms/8xx/m8xx_setup.c |4 ++--
arch/powerpc/platforms/8xx/mpc86xads_setup.c |2 +-
arch/powerpc/platforms/8xx/mpc885ads_setup.c |2 +-
arch/powerpc/sysdev/commproc.h |2 +-
5 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/arch/powerpc/platforms/8xx/ep88xc.c
b/arch/powerpc/platforms/8xx/ep88xc.c
index c518b6c..c883c31 100644
--- a/arch/powerpc/platforms/8xx/ep88xc.c
+++ b/arch/powerpc/platforms/8xx/ep88xc.c
@@ -166,7 +166,7 @@ define_machine(ep88xc) {
.name = Embedded Planet EP88xC,
.probe = ep88xc_probe,
.setup_arch = ep88xc_setup_arch,
- .init_IRQ = m8xx_pic_init,
+ .init_IRQ = mpc8xx_pics_init,
.get_irq= mpc8xx_get_irq,
.restart = mpc8xx_restart,
.calibrate_decr = mpc8xx_calibrate_decr,
diff --git a/arch/powerpc/platforms/8xx/m8xx_setup.c
b/arch/powerpc/platforms/8xx/m8xx_setup.c
index ba645c2..1337457 100644
--- a/arch/powerpc/platforms/8xx/m8xx_setup.c
+++ b/arch/powerpc/platforms/8xx/m8xx_setup.c
@@ -237,13 +237,13 @@ static void cpm_cascade(unsigned int irq, struct irq_desc
*desc)
desc-chip-eoi(irq);
}
-/* Initialize the internal interrupt controller. The number of
+/* Initialize the internal interrupt controllers. The number of
* interrupts supported can vary with the processor type, and the
* 82xx family can have up to 64.
* External interrupts can be either edge or level triggered, and
* need to be initialized by the appropriate driver.
*/
-void __init m8xx_pic_init(void)
+void __init mpc8xx_pics_init(void)
{
int irq;
diff --git a/arch/powerpc/platforms/8xx/mpc86xads_setup.c
b/arch/powerpc/platforms/8xx/mpc86xads_setup.c
index d2927a4..dea1df1 100644
--- a/arch/powerpc/platforms/8xx/mpc86xads_setup.c
+++ b/arch/powerpc/platforms/8xx/mpc86xads_setup.c
@@ -139,7 +139,7 @@ define_machine(mpc86x_ads) {
.name = MPC86x ADS,
.probe = mpc86xads_probe,
.setup_arch = mpc86xads_setup_arch,
- .init_IRQ = m8xx_pic_init,
+ .init_IRQ = mpc8xx_pics_init,
.get_irq= mpc8xx_get_irq,
.restart= mpc8xx_restart,
.calibrate_decr = mpc8xx_calibrate_decr,
diff --git a/arch/powerpc/platforms/8xx/mpc885ads_setup.c
b/arch/powerpc/platforms/8xx/mpc885ads_setup.c
index 2cf1b6a..8f2aa04 100644
--- a/arch/powerpc/platforms/8xx/mpc885ads_setup.c
+++ b/arch/powerpc/platforms/8xx/mpc885ads_setup.c
@@ -275,7 +275,7 @@ define_machine(mpc885_ads) {
.name = Freescale MPC885 ADS,
.probe = mpc885ads_probe,
.setup_arch = mpc885ads_setup_arch,
- .init_IRQ = m8xx_pic_init,
+ .init_IRQ = mpc8xx_pics_init,
.get_irq= mpc8xx_get_irq,
.restart= mpc8xx_restart,
.calibrate_decr = mpc8xx_calibrate_decr,
diff --git a/arch/powerpc/sysdev/commproc.h b/arch/powerpc/sysdev/commproc.h
index 9155ba4..f481adf 100644
--- a/arch/powerpc/sysdev/commproc.h
+++ b/arch/powerpc/sysdev/commproc.h
@@ -6,7 +6,7 @@ extern void mpc8xx_restart(char *cmd);
extern void mpc8xx_calibrate_decr(void);
extern int mpc8xx_set_rtc_time(struct rtc_time *tm);
extern void mpc8xx_get_rtc_time(struct rtc_time *tm);
-extern void m8xx_pic_init(void);
+extern void mpc8xx_pics_init(void);
extern unsigned int mpc8xx_get_irq(void);
#endif
--
1.5.3.8
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] [POWERPC] Update TQM5200, CM5200 and Motion-PRO _defconfig and .dts files
On 1/23/08, Wolfgang Denk [EMAIL PROTECTED] wrote: In message [EMAIL PROTECTED] you wrote: Olof Johansson wrote: ... I disagree, I have one defconfig for all our boards to date. It means I only have one kernel to build to test on all boards, instead of having to build a number of different kernels. Keeping it fairly generic also means a customer can start out using the generic kernel in case they want to, and later on add their own drivers and prune out what is not needed. Well, I just prefer separate defconfigs but I can live with the common one as well, feel free to merge it as you see it fit. Well, it may make sense to use common defconfig files for boards of the same breed (different configurations of one board family from one vendor for example). But please note that TQM5200, CM5200 and Motion-PRO are boards from 3 different vendors, used by different projects with differing needs. IMO it makes very much sense to provide 3 separate default configurations that match the specific requirements of each of these boards. In this case I vote for separate defconfig files, please. I think I'm going to go with a single defconfig for all 5200 boards for the time being. We can revisit later if it turns out not to be working. Here are my reasons: - mpc5200 is intended to be multiplatform. Using a common defconfig increases the likelyhood that a kernel with support for all 5200 platforms will actually get tested. - Reduces the time cost required to build all powerpc defconfigs (only 1 needed instead of 5 and growing) - defconfigs are intended to be the known working configuration; not necessarily an optimized for deployment configuration. The system/kernel engineer is still responsible to tailor the configuration for a shippable distribution. Cheers, g. -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [patch v4 0/4] Cypress c67x00 (EZ-Host/EZ-OTG) support
On 1/21/08, Peter Korsgaard [EMAIL PROTECTED] wrote: Grant == Grant Likely [EMAIL PROTECTED] writes: Grant Personally, I'd prefer to see the v3 series picked up now (as I Grant believe all outstanding comments from the list have been addressed) Grant and have new patches build on top of that, but that's just my Grant preference. Here's the v3-v4 without gadget diff: Okay, I've had a chance to read through this. I haven't tested it, but I don't see anything I strongly disagree with. I've just got a few editorial comments below and a question. The question is about the device structure which used to be provided by the platform device instances and now there just uses the c67x00's device struct. I was under the impression that each USB HCD needs to have it's own struct device. I take it that's not true? Otherwise: Acked-by: Grant Likely [EMAIL PROTECTED] Cheers, g. diff --git a/drivers/usb/c67x00/c67x00-drv.c b/drivers/usb/c67x00/c67x00-drv.c index 0f0720a..c2ea3b6 100644 --- a/drivers/usb/c67x00/c67x00-drv.c +++ b/drivers/usb/c67x00/c67x00-drv.c @@ -203,19 +175,19 @@ static int __devinit c67x00_drv_probe(struct platform_device *pdev) } for (i = 0; i C67X00_SIES; i++) - c67x00_probe_sie(c67x00-sie[i]); + c67x00_probe_sie(c67x00-sie[i], c67x00, i); platform_set_drvdata(pdev, c67x00); return 0; - reset_failed: +reset_failed: free_irq(res2-start, c67x00); - request_irq_failed: +request_irq_failed: iounmap(c67x00-hpi.base); - map_failed: +map_failed: release_mem_region(res-start, res-end - res-start + 1); - request_mem_failed: +request_mem_failed: A single space should be preserved in front of the labels. Doing so means that git-diff picks up the function name instead of the label when generating output. diff --git a/drivers/usb/c67x00/c67x00-hcd.c b/drivers/usb/c67x00/c67x00-hcd.c index 3d0b77e..4afb291 100644 --- a/drivers/usb/c67x00/c67x00-hcd.c +++ b/drivers/usb/c67x00/c67x00-hcd.c @@ -368,23 +383,26 @@ int c67x00_hcd_probe(struct c67x00_sie *sie) goto err2; } + spin_lock_irqsave(sie-lock, flags); + sie-private_data = c67x00; + sie-irq = c67x00_hcd_irq; + spin_unlock_irqrestore(sie-lock, flags); + return retval; - err2: +err2: c67x00_sched_stop_scheduler(c67x00); - err1: +err1: usb_put_hcd(hcd); - err0: +err0: Ditto on the labels diff --git a/drivers/usb/c67x00/c67x00-hcd.h b/drivers/usb/c67x00/c67x00-hcd.h index 5b35f01..daee4cd 100644 --- a/drivers/usb/c67x00/c67x00-hcd.h +++ b/drivers/usb/c67x00/c67x00-hcd.h @@ -132,6 +147,6 @@ void c67x00_sched_kick(struct c67x00_hcd *c67x00); int c67x00_sched_start_scheduler(struct c67x00_hcd *c67x00); void c67x00_sched_stop_scheduler(struct c67x00_hcd *c67x00); -#define c67x00_hcd_dev(x) (c67x00_hcd_to_hcd(x)-self.controller) +#define c67x00_dev(x) (c67x00_hcd_to_hcd(x)-self.controller) Can the name c67x00_hcd_dev() be used instead? This macro is used with 'struct c67x00_hcd', not 'struct c67x00' and I find the code less confusing if the macro name reflects that. #endif /* _USB_C67X00_HCD_H */ diff --git a/drivers/usb/c67x00/c67x00-sched.c b/drivers/usb/c67x00/c67x00-sched.c index 35d7318..3140d89 100644 --- a/drivers/usb/c67x00/c67x00-sched.c +++ b/drivers/usb/c67x00/c67x00-sched.c - /* Something went wrong; unwind the allocations */ - err_epdata: +err_epdata: kfree(urbp); - err_urbp: +err_urbp: usb_hcd_unlink_urb_from_ep(hcd, urb); - err_not_linked: +err_not_linked: ditto Cheers, g. -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCHv2 0/8] [POWERPC] 8xx cleanups
What impact do the have on boards in arch/ppc being able to build? Byt the way what are the plans for powerpc? We have: arch/ppc arch/ppc64 arch/powerpc It was my understanding that arch/powerpc was supposed to be the future unified powerpc architecture but it does not even provide a defconfig. And I do not see too much happening to do so - but that maybe because I looked at a wrong place. Sam ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] Fix boot problem in situations where the boot CPU is running on a memoryless node
Hi,
On Wed, 23 Jan 2008, Mel Gorman wrote:
Applied in combination with the N_NORMAL_MEMORY revert and it fails to
boot. Console is as follows;
Thanks for testing!
On Wed, 23 Jan 2008, Mel Gorman wrote:
[c05c3b40] c00dadb4 .cache_grow+0x7c/0x338
[c05c3c00] c00db518 .fallback_alloc+0x1c0/0x224
[c05c3cb0] c00db920 .kmem_cache_alloc+0xe0/0x14c
[c05c3d50] c00dcbd0 .kmem_cache_create+0x230/0x4cc
[c05c3e30] c04c049c .kmem_cache_init+0x1ec/0x51c
[c05c3ee0] c049f8d8 .start_kernel+0x304/0x3fc
[c05c3f90] c0008594 .start_here_common+0x54/0xc0
0xc00dadb4 is in cache_grow (mm/slab.c:2782).
2777local_flags = flags (GFP_CONSTRAINT_MASK|GFP_RECLAIM_MASK);
2778
2779/* Take the l3 list lock to change the colour_next on this
node */
2780check_irq_off();
2781l3 = cachep-nodelists[nodeid];
2782spin_lock(l3-list_lock);
2783
2784/* Get colour for the slab, and cal the next value. */
2785offset = l3-colour_next;
2786l3-colour_next++;
Ok, so it's too early to fallback_alloc() because in kmem_cache_init() we
do:
for (i = 0; i NUM_INIT_LISTS; i++) {
kmem_list3_init(initkmem_list3[i]);
if (i MAX_NUMNODES)
cache_cache.nodelists[i] = NULL;
}
Fine. But, why are we hitting fallback_alloc() in the first place? It's
definitely not because of missing -nodelists as we do:
cache_cache.nodelists[node] = initkmem_list3[CACHE_CACHE];
before attempting to set up kmalloc caches. Now, if I understood
correctly, we're booting off a memoryless node so kmem_getpages() will
return NULL thus forcing us to fallback_alloc() which is unavailable at
this point.
As far as I can tell, there are two ways to fix this:
(1) don't boot off a memoryless node (why are we doing this in the first
place?)
(2) initialize cache_cache.nodelists with initmem_list3 equivalents
for *each node hat has normal memory*
I am still wondering why this worked before, though.
Pekka
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] Fix boot problem in situations where the boot CPU is running on a memoryless node
On Wed, 23 Jan 2008, Pekka J Enberg wrote:
As far as I can tell, there are two ways to fix this:
[snip]
(2) initialize cache_cache.nodelists with initmem_list3 equivalents
for *each node hat has normal memory*
An untested patch follows:
---
mm/slab.c | 39 ---
1 file changed, 20 insertions(+), 19 deletions(-)
Index: linux-2.6/mm/slab.c
===
--- linux-2.6.orig/mm/slab.c
+++ linux-2.6/mm/slab.c
@@ -304,11 +304,11 @@ struct kmem_list3 {
/*
* Need this for bootstrapping a per node allocator.
*/
-#define NUM_INIT_LISTS (2 * MAX_NUMNODES + 1)
+#define NUM_INIT_LISTS (3 * MAX_NUMNODES)
struct kmem_list3 __initdata initkmem_list3[NUM_INIT_LISTS];
#defineCACHE_CACHE 0
-#defineSIZE_AC 1
-#defineSIZE_L3 (1 + MAX_NUMNODES)
+#defineSIZE_AC MAX_NUMNODES
+#defineSIZE_L3 (2 * MAX_NUMNODES)
static int drain_freelist(struct kmem_cache *cache,
struct kmem_list3 *l3, int tofree);
@@ -1410,6 +1410,22 @@ static void init_list(struct kmem_cache
}
/*
+ * For setting up all the kmem_list3s for cache whose buffer_size is same as
+ * size of kmem_list3.
+ */
+static void __init set_up_list3s(struct kmem_cache *cachep, int index)
+{
+ int node;
+
+ for_each_node_state(node, N_NORMAL_MEMORY) {
+ cachep-nodelists[node] = initkmem_list3[index + node];
+ cachep-nodelists[node]-next_reap = jiffies +
+ REAPTIMEOUT_LIST3 +
+ ((unsigned long)cachep) % REAPTIMEOUT_LIST3;
+ }
+}
+
+/*
* Initialisation. Called after the page allocator have been initialised and
* before smp_init().
*/
@@ -1432,6 +1448,7 @@ void __init kmem_cache_init(void)
if (i MAX_NUMNODES)
cache_cache.nodelists[i] = NULL;
}
+ set_up_list3s(cache_cache, CACHE_CACHE);
/*
* Fragmentation resistance on low memory - only use bigger
@@ -1964,22 +1981,6 @@ static void slab_destroy(struct kmem_cac
}
}
-/*
- * For setting up all the kmem_list3s for cache whose buffer_size is same as
- * size of kmem_list3.
- */
-static void __init set_up_list3s(struct kmem_cache *cachep, int index)
-{
- int node;
-
- for_each_node_state(node, N_NORMAL_MEMORY) {
- cachep-nodelists[node] = initkmem_list3[index + node];
- cachep-nodelists[node]-next_reap = jiffies +
- REAPTIMEOUT_LIST3 +
- ((unsigned long)cachep) % REAPTIMEOUT_LIST3;
- }
-}
-
static void __kmem_cache_destroy(struct kmem_cache *cachep)
{
int i;
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [patch v4 0/4] Cypress c67x00 (EZ-Host/EZ-OTG) support
On Wednesday 23 January 2008, Grant Likely wrote: The question is about the device structure which used to be provided by the platform device instances and now there just uses the c67x00's device struct. I was under the impression that each USB HCD needs to have it's own struct device. I take it that's not true? Each root hub necessarily is a unique device, representing a set of downstream links. Unless Peter didn't test something relevant, it would seem we have observational proof that two root hubs can share the same device node for an upstream link. I can't think of a reason to demand multiple upstream links, though sharing them between root hubs like that isn't a common structure. - Dave ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCHv2 0/8] [POWERPC] 8xx cleanups
Sam Ravnborg wrote: What impact do the have on boards in arch/ppc being able to build? Byt the way what are the plans for powerpc? We have: arch/ppc arch/ppc64 arch/powerpc It was my understanding that arch/powerpc was supposed to be the future unified powerpc architecture but it does not even provide a defconfig. And I do not see too much happening to do so - but that maybe because I looked at a wrong place. You must have looked in the wrong place. :-) arch/ppc is scheduled for removal from mainline in June. arch/powerpc is under significant development, with lots of defconfigs in arch/powerpc/configs. arch/ppc64 is long dead. jdl ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCHv2 0/8] [POWERPC] 8xx cleanups
On Wed, Jan 23, 2008 at 11:31:46AM -0600, Jon Loeliger wrote: Sam Ravnborg wrote: What impact do the have on boards in arch/ppc being able to build? Byt the way what are the plans for powerpc? We have: arch/ppc arch/ppc64 arch/powerpc It was my understanding that arch/powerpc was supposed to be the future unified powerpc architecture but it does not even provide a defconfig. And I do not see too much happening to do so - but that maybe because I looked at a wrong place. You must have looked in the wrong place. :-) arch/ppc is scheduled for removal from mainline in June. Good to hear. arch/powerpc is under significant development, with lots of defconfigs in arch/powerpc/configs. Double checked - it was my build script that used ARCH=ppc Now I just need to build another toolchain as the ppc750 could not build the defconfig. crosstool is my friend here. Sam ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCHv2 5/8] [POWERPC] Remove sysdev/commproc.h
Hi Kumar, Do we really need the prototypes you moved into asm/mpc8xx.h here? can they just live in platforms/8xx/8xx.h or something like that? At least drivers/pcmcia/m8xx_pcmcia.c uses the symbol m8xx_pcmcia_ops which is conditionally defined in platforms/8xx/m8xx_setup.c. However, this driver currently seems to be broken (doesn't compile neither as built-in nor as module). Other drivers that include asm/mpc8xx.c are: drivers/net/fec.c (the include seems to be obsolete, as according to Kconfig the driver is only built on MPC52xx platforms) drivers/net/fec_8xx (unused, depends on non-existant CONFIG_8XX) drivers/net/fs_enet (i need to check if the include is needed, at all) I'll have a closer look at this. Thanks, Jochen ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] Fix boot problem in situations where the boot CPU is running on a memoryless node
On Wed, 23 Jan 2008, Pekka J Enberg wrote: I still think Christoph's kmem_getpages() patch is correct (to fix cache_grow() oops) but I overlooked the fact that none the callers of cache_alloc_node() deal with bootstrapping (with the exception of __cache_alloc_node() that even has a comment about it). My patch is useless. kmem_getpages called with nodeid == -1 falls back correctly to the available node. The problem is that the node structures for the page does not exist. But what I am really wondering about is, why wasn't the N_NORMAL_MEMORY revert enough? I assume this used to work before so what more do we need to revert for 2.6.24? I think that is because SLUB relaxed the requirements on having regular memory on the boot node. Now the expectation is that SLAB can do the same. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] Fix boot problem in situations where the boot CPU is running on a memoryless node
On Wed, 23 Jan 2008, Pekka J Enberg wrote: Furthermore, don't let kmem_getpages() call alloc_pages_node() if nodeid passed to it is -1 as the latter will always translate that to numa_node_id() which might not have -nodelist that caused the invocation of fallback_alloc() in the first place (for example, during bootstrap). kmem_getpages is called without GFP_THISNODE. This alloc_pages_node(numa_node_id(), ...) will fall back to the next node with memory. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 0/4 v4] Add StorCenter port
Kumar, Here is the StorCenter port with the MTD partitions re-written to be hard-coded PHYSMAP partitions for now. Addressed list and private commentary as well. Janitorial Karma has now caussed it to be 4 patches instead of the original 3. Please pick up for 2.6.25! Thanks, jdl ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] Fix boot problem in situations where the boot CPU is running on a memoryless node
On Wed, 23 Jan 2008, Mel Gorman wrote: This patch adds the necessary checks to make sure a kmem_list3 exists for the preferred node used when growing the cache. If the preferred node has no nodelist then the currently running node is used instead. This problem only affects the SLAB allocator, SLUB appears to work fine. That is a dangerous thing to do. SLAB per cpu queues will contain foreign objects which may cause troubles when pushing the objects back. I think we may be lucky that these objects are consumed at boot. If all of the foreign objects are consumed at boot then we are fine. At least an explanation as to this issue should be added to the patch. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 1/4 v4] POWERPC: Add _nmask_and_or_msr() declartion to asm-powerpc/system.h
Prevents miscellaneous users from declaring it locally.
Signed-off-by: Jon Loeliger [EMAIL PROTECTED]
---
arch/powerpc/platforms/embedded6xx/mpc7448_hpc2.c |2 --
include/asm-powerpc/system.h |2 ++
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/platforms/embedded6xx/mpc7448_hpc2.c
b/arch/powerpc/platforms/embedded6xx/mpc7448_hpc2.c
index a2c04b9..d4f8bf5 100644
--- a/arch/powerpc/platforms/embedded6xx/mpc7448_hpc2.c
+++ b/arch/powerpc/platforms/embedded6xx/mpc7448_hpc2.c
@@ -53,8 +53,6 @@
#define MPC7448HPC2_PCI_CFG_PHYS 0xfb00
-extern void _nmask_and_or_msr(unsigned long nmask, unsigned long or_val);
-
int mpc7448_hpc2_exclude_device(struct pci_controller *hose,
u_char bus, u_char devfn)
{
diff --git a/include/asm-powerpc/system.h b/include/asm-powerpc/system.h
index 87be8c3..bc9739d 100644
--- a/include/asm-powerpc/system.h
+++ b/include/asm-powerpc/system.h
@@ -169,6 +169,8 @@ extern int do_page_fault(struct pt_regs *, unsigned long,
unsigned long);
extern void bad_page_fault(struct pt_regs *, unsigned long, int);
extern int die(const char *, struct pt_regs *, long);
extern void _exception(int, struct pt_regs *, int, unsigned long);
+extern void _nmask_and_or_msr(unsigned long nmask, unsigned long or_val);
+
#ifdef CONFIG_BOOKE_WDT
extern u32 booke_wdt_enabled;
extern u32 booke_wdt_period;
--
1.5.4.rc0
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 2/4 v4] POWERPC: Add StorCenter DTS first draft.
Based on the Kurobox DTS files.
Signed-off-by: Jon Loeliger [EMAIL PROTECTED]
Acked-by: Andy Wilcox [EMAIL PROTECTED]
---
arch/powerpc/boot/dts/storcenter.dts | 138 ++
1 files changed, 138 insertions(+), 0 deletions(-)
create mode 100644 arch/powerpc/boot/dts/storcenter.dts
diff --git a/arch/powerpc/boot/dts/storcenter.dts
b/arch/powerpc/boot/dts/storcenter.dts
new file mode 100644
index 000..6aa1d69
--- /dev/null
+++ b/arch/powerpc/boot/dts/storcenter.dts
@@ -0,0 +1,138 @@
+/*
+ * Device Tree Source for IOMEGA StorCenter
+ *
+ * Copyright 2007 Oyvind Repvik
+ * Copyright 2007 Jon Loeliger
+ *
+ * Based on the Kurobox DTS by G. Liakhovetski [EMAIL PROTECTED]
+ *
+ * This file is licensed under the terms of the GNU General Public
+ * License version 2. This program is licensed as is without any
+ * warranty of any kind, whether express or implied.
+ */
+
+/ {
+ model = StorCenter;
+ compatible = storcenter;
+ #address-cells = 1;
+ #size-cells = 1;
+
+ aliases {
+ serial0 = serial0;
+ serial1 = serial1;
+ pci0 = pci0;
+ };
+
+ cpus {
+ #address-cells = 1;
+ #size-cells = 0;
+
+ PowerPC,[EMAIL PROTECTED] {
+ device_type = cpu;
+ reg = 0;
+ clock-frequency = d# 2; /* Hz */
+ timebase-frequency = d# 2500; /* Hz */
+ bus-frequency = 0;/* from bootwrapper */
+ i-cache-line-size = d# 32;/* bytes */
+ d-cache-line-size = d# 32;/* bytes */
+ i-cache-size = 4000;
+ d-cache-size = 4000;
+ };
+ };
+
+ memory {
+ device_type = memory;
+ reg = 0400; /* 64MB @ 0x0 */
+ };
+
+ [EMAIL PROTECTED] {
+ #address-cells = 1;
+ #size-cells = 1;
+ device_type = soc;
+ compatible = fsl,mpc8241, mpc10x;
+ store-gathering = 0; /* 0 == off, !0 == on */
+ ranges = 0 fc00 10;
+ reg = fc00 10;/* EUMB */
+ bus-frequency = 0;/* fixed by loader */
+
+ [EMAIL PROTECTED] {
+ #address-cells = 1;
+ #size-cells = 0;
+ compatible = fsl-i2c;
+ reg = 3000 100;
+ interrupts = 5 2;
+ interrupt-parent = mpic;
+
+ [EMAIL PROTECTED] {
+ compatible = dallas,ds1337;
+ reg = 68;
+ };
+ };
+
+ serial0: [EMAIL PROTECTED] {
+ cell-index = 0;
+ device_type = serial;
+ compatible = ns16550;
+ reg = 4500 20;
+ clock-frequency = d# 97553800; /* Hz */
+ current-speed = d# 115200;
+ interrupts = 9 2;
+ interrupt-parent = mpic;
+ };
+
+ serial1: [EMAIL PROTECTED] {
+ cell-index = 1;
+ device_type = serial;
+ compatible = ns16550;
+ reg = 4600 20;
+ clock-frequency = d# 97553800; /* Hz */
+ current-speed = d# 9600;
+ interrupts = a 2;
+ interrupt-parent = mpic;
+ };
+
+ mpic: [EMAIL PROTECTED] {
+ #interrupt-cells = 2;
+ device_type = open-pic;
+ compatible = chrp,open-pic;
+ interrupt-controller;
+ reg = 4 4;
+ };
+
+ };
+
+ pci0: [EMAIL PROTECTED] {
+ #address-cells = 3;
+ #size-cells = 2;
+ #interrupt-cells = 1;
+ device_type = pci;
+ compatible = mpc10x-pci;
+ reg = fe80 1000;
+ ranges = 0100 00 fe00 0 00c0
+ 0200 0 8000 8000 0 7000;
+ bus-range = 0 ff;
+ clock-frequency = d# 97553800; /* Hz */
+ interrupt-parent = mpic;
+ interrupt-map-mask = f800 0 0 7;
+ interrupt-map =
+ /* IDSEL 13 - IDE */
+ 6800 0 0 1 mpic 0 1
+ 6800 0 0 2 mpic 0 1
+ 6800 0 0 3 mpic 0 1
+ /* IDSEL 14 - USB */
+ 7000 0 0 1 mpic 0 1
+ 7000 0 0 2 mpic 0 1
+
[PATCH 3/4 v4] POWERPC: Add initial iomega StorCenter board port.
Use cuImage bootwrapper until U-Boot port is completed.
Derived heavily from Linkstation port.
Signed-off-by: Jon Loeliger [EMAIL PROTECTED]
Acked-by: Andy Wilcox [EMAIL PROTECTED]
---
arch/powerpc/boot/Makefile |3 +-
arch/powerpc/boot/cuboot-824x.c | 53 +++
arch/powerpc/platforms/embedded6xx/Kconfig | 23 ++-
arch/powerpc/platforms/embedded6xx/Makefile |1 +
arch/powerpc/platforms/embedded6xx/storcenter.c | 190 +++
5 files changed, 263 insertions(+), 7 deletions(-)
create mode 100644 arch/powerpc/boot/cuboot-824x.c
create mode 100644 arch/powerpc/platforms/embedded6xx/storcenter.c
diff --git a/arch/powerpc/boot/Makefile b/arch/powerpc/boot/Makefile
index d1e625c..a59b176 100644
--- a/arch/powerpc/boot/Makefile
+++ b/arch/powerpc/boot/Makefile
@@ -57,7 +57,7 @@ src-wlib := string.S crt0.S stdio.c main.c \
4xx.c ebony.c mv64x60.c mpsc.c mv64x60_i2c.c cuboot.c bamboo.c \
cpm-serial.c stdlib.c mpc52xx-psc.c planetcore.c uartlite.c \
fsl-soc.c mpc8xx.c pq2.c
-src-plat := of.c cuboot-52xx.c cuboot-83xx.c cuboot-85xx.c holly.c \
+src-plat := of.c cuboot-52xx.c cuboot-824x.c cuboot-83xx.c cuboot-85xx.c
holly.c \
cuboot-ebony.c treeboot-ebony.c prpmc2800.c \
ps3-head.S ps3-hvcall.S ps3.c treeboot-bamboo.c cuboot-8xx.c \
cuboot-pq2.c cuboot-sequoia.c treeboot-walnut.c cuboot-bamboo.c
\
@@ -196,6 +196,7 @@ image-$(CONFIG_PPC_EP88XC) += zImage.ep88xc
image-$(CONFIG_EP405) += zImage.ep405
image-$(CONFIG_8260) += cuImage.pq2
image-$(CONFIG_PPC_MPC52xx)+= cuImage.52xx
+image-$(CONFIG_STORCENTER) += cuImage.824x
image-$(CONFIG_PPC_83xx) += cuImage.83xx
image-$(CONFIG_PPC_85xx) += cuImage.85xx
image-$(CONFIG_MPC7448HPC2)+= cuImage.hpc2
diff --git a/arch/powerpc/boot/cuboot-824x.c b/arch/powerpc/boot/cuboot-824x.c
new file mode 100644
index 000..ced90c5
--- /dev/null
+++ b/arch/powerpc/boot/cuboot-824x.c
@@ -0,0 +1,53 @@
+/*
+ * Old U-boot compatibility for 824x
+ *
+ * Copyright (c) 2007 Freescale Semiconductor, Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License version 2 as published
+ * by the Free Software Foundation.
+ */
+
+#include ops.h
+#include stdio.h
+#include cuboot.h
+
+#define TARGET_824x
+#include ppcboot.h
+
+static bd_t bd;
+
+
+static void platform_fixups(void)
+{
+ void *soc;
+
+ dt_fixup_memory(bd.bi_memstart, bd.bi_memsize);
+ dt_fixup_mac_addresses(bd.bi_enetaddr);
+ dt_fixup_cpu_clocks(bd.bi_intfreq, bd.bi_busfreq / 4, bd.bi_busfreq);
+
+ soc = find_node_by_devtype(NULL, soc);
+ if (soc) {
+ void *serial = NULL;
+
+ setprop(soc, bus-frequency, bd.bi_busfreq,
+ sizeof(bd.bi_busfreq));
+
+ while ((serial = find_node_by_devtype(serial, serial))) {
+ if (get_parent(serial) != soc)
+ continue;
+
+ setprop(serial, clock-frequency, bd.bi_busfreq,
+ sizeof(bd.bi_busfreq));
+ }
+ }
+}
+
+void platform_init(unsigned long r3, unsigned long r4, unsigned long r5,
+ unsigned long r6, unsigned long r7)
+{
+ CUBOOT_INIT();
+ fdt_init(_dtb_start);
+ serial_console_init();
+ platform_ops.fixups = platform_fixups;
+}
diff --git a/arch/powerpc/platforms/embedded6xx/Kconfig
b/arch/powerpc/platforms/embedded6xx/Kconfig
index 8924095..6c80837 100644
--- a/arch/powerpc/platforms/embedded6xx/Kconfig
+++ b/arch/powerpc/platforms/embedded6xx/Kconfig
@@ -9,6 +9,8 @@ config LINKSTATION
select FSL_SOC
select PPC_UDBG_16550 if SERIAL_8250
select DEFAULT_UIMAGE
+ select MPC10X_OPENPIC
+ select MPC10X_BRIDGE
help
Select LINKSTATION if configuring for one of PPC- (MPC8241)
based NAS systems from Buffalo Technology. So far only
@@ -16,6 +18,19 @@ config LINKSTATION
Linkstation-I HD-HLAN and HD-HGLAN versions, and PPC-based
Terastation systems should be supported too.
+config STORCENTER
+ bool IOMEGA StorCenter
+ depends on EMBEDDED6xx
+ select MPIC
+ select FSL_SOC
+ select PPC_UDBG_16550 if SERIAL_8250
+ select WANT_DEVICE_TREE
+ select MPC10X_OPENPIC
+ select MPC10X_BRIDGE
+ help
+ Select STORCENTER if configuring for the iomega StorCenter
+ with an 8241 CPU in it.
+
config MPC7448HPC2
bool Freescale MPC7448HPC2(Taiga)
depends on EMBEDDED6xx
@@ -23,6 +38,7 @@ config MPC7448HPC2
select DEFAULT_UIMAGE
select PPC_UDBG_16550
select WANT_DEVICE_TREE
+ select TSI108_BRIDGE
help
[PATCH 4/4 v4] POWERPC: Add initial storcenter config file.
Signed-off-by: Jon Loeliger [EMAIL PROTECTED] Acked-by: Andy Wilcox [EMAIL PROTECTED] --- arch/powerpc/configs/storcenter_defconfig | 1174 + 1 files changed, 1174 insertions(+), 0 deletions(-) create mode 100644 arch/powerpc/configs/storcenter_defconfig diff --git a/arch/powerpc/configs/storcenter_defconfig b/arch/powerpc/configs/storcenter_defconfig new file mode 100644 index 000..a034a5e --- /dev/null +++ b/arch/powerpc/configs/storcenter_defconfig @@ -0,0 +1,1174 @@ +# +# Automatically generated make config: don't edit +# Linux kernel version: 2.6.24-rc6 +# Tue Jan 8 09:33:54 2008 +# +# CONFIG_PPC64 is not set + +# +# Processor support +# +CONFIG_6xx=y +# CONFIG_PPC_85xx is not set +# CONFIG_PPC_8xx is not set +# CONFIG_40x is not set +# CONFIG_44x is not set +# CONFIG_E200 is not set +CONFIG_PPC_FPU=y +# CONFIG_ALTIVEC is not set +CONFIG_PPC_STD_MMU=y +CONFIG_PPC_STD_MMU_32=y +# CONFIG_PPC_MM_SLICES is not set +# CONFIG_SMP is not set +CONFIG_PPC32=y +CONFIG_WORD_SIZE=32 +CONFIG_PPC_MERGE=y +CONFIG_MMU=y +CONFIG_GENERIC_CMOS_UPDATE=y +CONFIG_GENERIC_TIME=y +CONFIG_GENERIC_TIME_VSYSCALL=y +CONFIG_GENERIC_CLOCKEVENTS=y +CONFIG_GENERIC_HARDIRQS=y +CONFIG_IRQ_PER_CPU=y +CONFIG_RWSEM_XCHGADD_ALGORITHM=y +CONFIG_ARCH_HAS_ILOG2_U32=y +CONFIG_GENERIC_HWEIGHT=y +CONFIG_GENERIC_CALIBRATE_DELAY=y +CONFIG_GENERIC_FIND_NEXT_BIT=y +# CONFIG_ARCH_NO_VIRT_TO_BUS is not set +CONFIG_PPC=y +CONFIG_EARLY_PRINTK=y +CONFIG_GENERIC_NVRAM=y +CONFIG_SCHED_NO_NO_OMIT_FRAME_POINTER=y +CONFIG_ARCH_MAY_HAVE_PC_FDC=y +CONFIG_PPC_OF=y +CONFIG_OF=y +CONFIG_PPC_UDBG_16550=y +# CONFIG_GENERIC_TBSYNC is not set +CONFIG_AUDIT_ARCH=y +CONFIG_GENERIC_BUG=y +# CONFIG_DEFAULT_UIMAGE is not set +# CONFIG_PPC_DCR_NATIVE is not set +# CONFIG_PPC_DCR_MMIO is not set +CONFIG_DEFCONFIG_LIST=/lib/modules/$UNAME_RELEASE/.config + +# +# General setup +# +CONFIG_EXPERIMENTAL=y +CONFIG_BROKEN_ON_SMP=y +CONFIG_INIT_ENV_ARG_LIMIT=32 +CONFIG_LOCALVERSION= +CONFIG_LOCALVERSION_AUTO=y +CONFIG_SWAP=y +CONFIG_SYSVIPC=y +CONFIG_SYSVIPC_SYSCTL=y +# CONFIG_POSIX_MQUEUE is not set +# CONFIG_BSD_PROCESS_ACCT is not set +# CONFIG_TASKSTATS is not set +# CONFIG_USER_NS is not set +# CONFIG_PID_NS is not set +# CONFIG_AUDIT is not set +# CONFIG_IKCONFIG is not set +CONFIG_LOG_BUF_SHIFT=14 +# CONFIG_CGROUPS is not set +CONFIG_FAIR_GROUP_SCHED=y +CONFIG_FAIR_USER_SCHED=y +# CONFIG_FAIR_CGROUP_SCHED is not set +CONFIG_SYSFS_DEPRECATED=y +# CONFIG_RELAY is not set +# CONFIG_BLK_DEV_INITRD is not set +CONFIG_CC_OPTIMIZE_FOR_SIZE=y +CONFIG_SYSCTL=y +CONFIG_EMBEDDED=y +CONFIG_SYSCTL_SYSCALL=y +# CONFIG_KALLSYMS is not set +CONFIG_HOTPLUG=y +CONFIG_PRINTK=y +CONFIG_BUG=y +CONFIG_ELF_CORE=y +CONFIG_BASE_FULL=y +CONFIG_FUTEX=y +CONFIG_ANON_INODES=y +CONFIG_EPOLL=y +CONFIG_SIGNALFD=y +CONFIG_EVENTFD=y +CONFIG_SHMEM=y +CONFIG_VM_EVENT_COUNTERS=y +CONFIG_SLUB_DEBUG=y +# CONFIG_SLAB is not set +CONFIG_SLUB=y +# CONFIG_SLOB is not set +CONFIG_RT_MUTEXES=y +# CONFIG_TINY_SHMEM is not set +CONFIG_BASE_SMALL=0 +CONFIG_MODULES=y +CONFIG_MODULE_UNLOAD=y +# CONFIG_MODULE_FORCE_UNLOAD is not set +# CONFIG_MODVERSIONS is not set +# CONFIG_MODULE_SRCVERSION_ALL is not set +CONFIG_KMOD=y +CONFIG_BLOCK=y +CONFIG_LBD=y +# CONFIG_BLK_DEV_IO_TRACE is not set +# CONFIG_LSF is not set +# CONFIG_BLK_DEV_BSG is not set + +# +# IO Schedulers +# +CONFIG_IOSCHED_NOOP=y +CONFIG_IOSCHED_AS=y +CONFIG_IOSCHED_DEADLINE=y +CONFIG_IOSCHED_CFQ=y +# CONFIG_DEFAULT_AS is not set +# CONFIG_DEFAULT_DEADLINE is not set +CONFIG_DEFAULT_CFQ=y +# CONFIG_DEFAULT_NOOP is not set +CONFIG_DEFAULT_IOSCHED=cfq + +# +# Platform support +# +CONFIG_PPC_MULTIPLATFORM=y +# CONFIG_PPC_82xx is not set +# CONFIG_PPC_83xx is not set +# CONFIG_PPC_86xx is not set +CONFIG_CLASSIC32=y +# CONFIG_PPC_CHRP is not set +# CONFIG_PPC_MPC52xx is not set +# CONFIG_PPC_MPC5200 is not set +# CONFIG_PPC_EFIKA is not set +# CONFIG_PPC_LITE5200 is not set +# CONFIG_PPC_PMAC is not set +# CONFIG_PPC_CELL is not set +# CONFIG_PPC_CELL_NATIVE is not set +# CONFIG_PQ2ADS is not set +CONFIG_EMBEDDED6xx=y +# CONFIG_LINKSTATION is not set +CONFIG_STORCENTER=y +# CONFIG_MPC7448HPC2 is not set +# CONFIG_PPC_HOLLY is not set +# CONFIG_PPC_PRPMC2800 is not set +CONFIG_MPC10X_BRIDGE=y +CONFIG_MPC10X_OPENPIC=y +# CONFIG_MPC10X_STORE_GATHERING is not set +CONFIG_MPIC=y +# CONFIG_MPIC_WEIRD is not set +# CONFIG_PPC_I8259 is not set +# CONFIG_PPC_RTAS is not set +# CONFIG_MMIO_NVRAM is not set +# CONFIG_PPC_MPC106 is not set +# CONFIG_PPC_970_NAP is not set +# CONFIG_PPC_INDIRECT_IO is not set +# CONFIG_GENERIC_IOMAP is not set +# CONFIG_CPU_FREQ is not set +# CONFIG_TAU is not set +# CONFIG_CPM2 is not set +# CONFIG_FSL_ULI1575 is not set + +# +# Kernel options +# +# CONFIG_HIGHMEM is not set +# CONFIG_TICK_ONESHOT is not set +# CONFIG_NO_HZ is not set +# CONFIG_HIGH_RES_TIMERS is not set +CONFIG_GENERIC_CLOCKEVENTS_BUILD=y +CONFIG_HZ_100=y +# CONFIG_HZ_250 is not set +# CONFIG_HZ_300 is not set +# CONFIG_HZ_1000 is not set
Re: [PATCH] Fix boot problem in situations where the boot CPU is running on a memoryless node
On Wed, 23 Jan 2008, Pekka J Enberg wrote: Fine. But, why are we hitting fallback_alloc() in the first place? It's definitely not because of missing -nodelists as we do: cache_cache.nodelists[node] = initkmem_list3[CACHE_CACHE]; before attempting to set up kmalloc caches. Now, if I understood correctly, we're booting off a memoryless node so kmem_getpages() will return NULL thus forcing us to fallback_alloc() which is unavailable at this point. As far as I can tell, there are two ways to fix this: (1) don't boot off a memoryless node (why are we doing this in the first place?) Right. That is the solution that I would prefer. (2) initialize cache_cache.nodelists with initmem_list3 equivalents for *each node hat has normal memory* Or simply do it for all. SLAB bootstrap is very complex thing though. I am still wondering why this worked before, though. I doubt it did ever work for SLAB. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Section mismatch warnings om powerpc defconfig build:wq
Hi Powerpc. Just a heads up. When building the provided defconfig for powerpc I get the following bunch of section mismatch warnings: WARNING: vmlinux.o(.text+0x83c0): Section mismatch: reference to .devinit.text:.start_secondary in '.start_secondary_prolog' WARNING: vmlinux.o(.text+0xe878): Section mismatch: reference to .init.text:.find_symbol64 in '.vdso_do_func_patch64' WARNING: vmlinux.o(.text+0xe8a4): Section mismatch: reference to .init.text:.find_symbol64 in '.vdso_do_func_patch64' WARNING: vmlinux.o(.text+0xe944): Section mismatch: reference to .init.text:.find_symbol32 in '.vdso_do_func_patch32' WARNING: vmlinux.o(.text+0xe970): Section mismatch: reference to .init.text:.find_symbol32 in '.vdso_do_func_patch32' WARNING: vmlinux.o(.text+0x25b10): Section mismatch: reference to .init.text:.lmb_alloc_base in '.move_device_tree' WARNING: vmlinux.o(.text+0x2bc98): Section mismatch: reference to .devinit.text:.fixup_resource in '.pci_parse_of_addrs' WARNING: vmlinux.o(.text+0x2c428): Section mismatch: reference to .devinit.text:.update_dn_pci_info in '.pci_dn_reconfig_notifier' WARNING: vmlinux.o(.text+0x2c9ec): Section mismatch: reference to .devinit.text:.pci_setup_pci_controller in '.pcibios_alloc_controller' WARNING: vmlinux.o(.text+0x4db6c): Section mismatch: reference to .devinit.text:.pcibios_setup_new_device in '.pcibios_fixup_new_pci_devices' WARNING: vmlinux.o(.text+0x4db84): Section mismatch: reference to .devinit.text:.pcibios_fixup_device_resources in '.pcibios_fixup_new_pci_devices' WARNING: vmlinux.o(.text+0x4de28): Section mismatch: reference to .devinit.text:.of_scan_bus in '.pcibios_add_pci_devices' WARNING: vmlinux.o(.text+0x55474): Section mismatch: reference to .init.text:.free_property in '.free_node' WARNING: vmlinux.o(.text+0x559d0): Section mismatch: reference to .devinit.text:.vio_register_device_node in '.vio_create_viodasd' WARNING: vmlinux.o(.text+0xe73c0): Section mismatch: reference to .init.text:.__alloc_bootmem_node in '.sparse_early_usemap_alloc' WARNING: vmlinux.o(.text+0xe74b4): Section mismatch: reference to .meminit.text:.sparse_index_init in '.sparse_add_one_section' WARNING: vmlinux.o(.text+0xe74d4): Section mismatch: reference to .meminit.text:.sparse_mem_map_populate in '.sparse_add_one_section' WARNING: vmlinux.o(.text+0xe7548): Section mismatch: reference to .meminit.text:.sparse_init_one_section in '.sparse_add_one_section' WARNING: vmlinux.o(.text+0xf1c90): Section mismatch: reference to .devinit.text:.arch_add_memory in '.add_memory' WARNING: vmlinux.o(.text+0xf1eac): Section mismatch: reference to .meminit.text:.init_currently_empty_zone in '.__add_zone' WARNING: vmlinux.o(.text+0xf1ee0): Section mismatch: reference to .meminit.text:.memmap_init_zone in '.__add_zone' WARNING: vmlinux.o(.text+0x279f08): Section mismatch: reference to .devinit.text:.pci_alloc_child_bus in '.pci_add_new_bus' WARNING: vmlinux.o(.text+0x27a95c): Section mismatch: reference to .devinit.text:.pci_scan_device in '.pci_scan_single_device' WARNING: vmlinux.o(.text+0x27af44): Section mismatch: reference to .devinit.text:.pcibios_fixup_bus in '.pci_scan_child_bus' WARNING: vmlinux.o(.text+0x2849a4): Section mismatch: reference to .devinit.text:.pci_setup_bridge in '.pci_bus_assign_resources' WARNING: vmlinux.o(.text+0x284ca8): Section mismatch: reference to .devinit.text:.pci_bus_size_cardbus in '.pci_bus_size_bridges' WARNING: vmlinux.o(.text+0x2f649c): Section mismatch: reference to .devinit.text:.hvc_alloc in '.hvc_rtas_init' WARNING: vmlinux.o(.text+0x30d99c): Section mismatch: reference to .cpuinit.text:.cpu_up in '.store_online' WARNING: vmlinux.o(.text+0x38c724): Section mismatch: reference to .devinit.text:.olympic_init in '.olympic_open' WARNING: vmlinux.o(.text+0x3b5630): Section mismatch: reference to .init.text:.pmac_ide_setup_dma in '.pmac_ide_setup_device' WARNING: vmlinux.o(.text+0x3daa04): Section mismatch: reference to .devexit.text:.sym2_remove in '.sym2_io_error_detected' WARNING: vmlinux.o(.text+0x4da38c): Section mismatch: reference to .cpuinit.text:.register_cpu_notifier in '.cpufreq_register_driver' AS .tmp_kallsyms2.o LD vmlinux SYSMAP System.map SYSMAP .tmp_System.map Building modules, stage 2. WRAParch/powerpc/boot/zImage.pseries WRAParch/powerpc/boot/zImage.pmac powerpc64-unknown-linux-gnu-strip -s -R .comment vmlinux -o arch/powerpc/boot/zImage.iseries MODPOST 263 modules WARNING: drivers/cdrom/viocd.o(.text+0x504): Section mismatch: reference to .init.text:.find_capability in '.viocd_probe' WARNING: drivers/net/iseries_veth.o(.text+0x113c): Section mismatch: reference to .init.text:.veth_probe_one in '.veth_probe' Some of these are powerpc specific and you ought to take a look at these. It is planned to let section mismatches become fatal in the build process during 2.6.25 so now is a good time to fix them. The above list is generatd from kbuild.git which is included in -mm. So
mpc8568e-mds: pci-e is broken
Hello Benjamin, Kumar,
Using galak/powerpc.git's e4a0d8a1f7e6a9741ec46 head, MPC8568E-MDS
is oopsing during PCI-E probe, like this:
- - - -
Found FSL PCI host bridge at 0xe0008000. Firmware bus number: 0-255
PCI host bridge /[EMAIL PROTECTED] (primary) ranges:
MEM 0x8000..0x9fff - 0x8000
IO 0xe200..0xe27f - 0x
Found FSL PCI host bridge at 0xe000a000. Firmware bus number: 0-255
PCI host bridge /[EMAIL PROTECTED] ranges:
MEM 0xa000..0xafff - 0xa000
IO 0xe280..0xe2ff - 0x
[...]
PCI: Probing PCI hardware
PCI: 0001:01:00.0: class b20 doesn't match header type 01. Ignoring class.
PCI: Closing bogus Apple Firmware region 1 on bus 0x02
PCI: Closing bogus Apple Firmware region 2 on bus 0x02
Unable to handle kernel paging request for data at address 0x
Faulting instruction address: 0xc0142760
Oops: Kernel access of bad area, sig: 11 [#1]
MPC85xx MDS
Modules linked in:
NIP: c0142760 LR: c01427a8 CTR:
REGS: df823dc0 TRAP: 0300 Not tainted (2.6.24-rc8-g146f2dc2-dirty)
MSR: 00029000 EE,ME CR: 42044082 XER:
DEAR: , ESR:
TASK = df82[1] 'swapper' THREAD: df822000
GPR00: df823e70 df82 df800380 00d0 0200 0004 c028aa6c
GPR08: df81c200 0007 df809a44 22044024 48fdafc9 1fff4e00 c02276ec
GPR16: c0227760 df823f98 c0227748 c0284efc c0227774 c0227788 c023e5b0 c02a9200
GPR24: df8098d8 df823eac df809800 b6db6db7 0008 df8098e0
Call Trace:
[df823e70] [c01427a8] (unreliable)
[df823ea0] [c0143c9c]
[df823f00] [c027a338]
[df823f20] [c026e38c]
[df823f30] [c026df08]
[df823f60] [c02641ec]
[df823ff0] [c000dc08]
Instruction dump:
39290001 2f9d0006 7d4a4f5e 7f3ccb78 4820 812b0004 800b 39290001
7c004850 7f805040 419c0044 7fdcf378 83dc 3800 2f9e 41beffe8
---[ end trace 8640abe69a316dee ]---
Kernel panic - not syncing: Attempted to kill init!
Rebooting in 180 seconds..
- - - -
It seems like be8cbcd8896670a01ead7a29e33ff is at fault.
static void __devinit __pcibios_fixup_bus(struct pci_bus *bus)
{
...
if (i = 3 bus-self-transparent)
continue;
...
}
That new check doesn't work, here bus-self-transparent == 0.
Could it be that the message below is the root cause?
PCI: 0001:01:00.0: class b20 doesn't match header type 01. Ignoring class.
I.e. drivers/pci/probe.c just don't setting transparent flag.
I wonder if we need use quirk_transparent_bridge() here or
we can fix it other way?
Just in case, I'm observing that message for a long long time, and
it didn't tell upon any functionality till now.
Thanks,
--
Anton Vorontsov
email: [EMAIL PROTECTED]
backup email: [EMAIL PROTECTED]
irc://irc.freenode.net/bd2
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCHv2 0/8] [POWERPC] 8xx cleanups
On Wed, 23 Jan 2008 19:00:12 +0100 Sam Ravnborg [EMAIL PROTECTED] wrote: On Wed, Jan 23, 2008 at 11:31:46AM -0600, Jon Loeliger wrote: Sam Ravnborg wrote: What impact do the have on boards in arch/ppc being able to build? Byt the way what are the plans for powerpc? We have: arch/ppc arch/ppc64 arch/powerpc It was my understanding that arch/powerpc was supposed to be the future unified powerpc architecture but it does not even provide a defconfig. And I do not see too much happening to do so - but that maybe because I looked at a wrong place. You must have looked in the wrong place. :-) arch/ppc is scheduled for removal from mainline in June. Good to hear. arch/powerpc is under significant development, with lots of defconfigs in arch/powerpc/configs. Double checked - it was my build script that used ARCH=ppc Now I just need to build another toolchain as the ppc750 could not build the defconfig. crosstool is my friend here. You'll need mkimage if you ever venture into some of the embedded board configs. Just an FYI. josh ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: mpc8568e-mds: pci-e is broken
On Jan 23, 2008, at 1:37 PM, Anton Vorontsov wrote:
Hello Benjamin, Kumar,
Using galak/powerpc.git's e4a0d8a1f7e6a9741ec46 head, MPC8568E-MDS
is oopsing during PCI-E probe, like this:
- - - -
Found FSL PCI host bridge at 0xe0008000. Firmware bus
number: 0-255
PCI host bridge /[EMAIL PROTECTED] (primary) ranges:
MEM 0x8000..0x9fff - 0x8000
IO 0xe200..0xe27f - 0x
Found FSL PCI host bridge at 0xe000a000. Firmware bus
number: 0-255
PCI host bridge /[EMAIL PROTECTED] ranges:
MEM 0xa000..0xafff - 0xa000
IO 0xe280..0xe2ff - 0x
[...]
PCI: Probing PCI hardware
PCI: 0001:01:00.0: class b20 doesn't match header type 01. Ignoring
class.
PCI: Closing bogus Apple Firmware region 1 on bus 0x02
PCI: Closing bogus Apple Firmware region 2 on bus 0x02
odd, you shouldn't see these anymore w/my git tree.
Unable to handle kernel paging request for data at address 0x
Faulting instruction address: 0xc0142760
Oops: Kernel access of bad area, sig: 11 [#1]
MPC85xx MDS
Modules linked in:
NIP: c0142760 LR: c01427a8 CTR:
REGS: df823dc0 TRAP: 0300 Not tainted (2.6.24-rc8-g146f2dc2-dirty)
MSR: 00029000 EE,ME CR: 42044082 XER:
DEAR: , ESR:
TASK = df82[1] 'swapper' THREAD: df822000
GPR00: df823e70 df82 df800380 00d0 0200
0004 c028aa6c
GPR08: df81c200 0007 df809a44 22044024 48fdafc9
1fff4e00 c02276ec
GPR16: c0227760 df823f98 c0227748 c0284efc c0227774 c0227788
c023e5b0 c02a9200
GPR24: df8098d8 df823eac df809800 b6db6db7 0008
df8098e0
Call Trace:
[df823e70] [c01427a8] (unreliable)
[df823ea0] [c0143c9c]
[df823f00] [c027a338]
[df823f20] [c026e38c]
[df823f30] [c026df08]
[df823f60] [c02641ec]
[df823ff0] [c000dc08]
Instruction dump:
39290001 2f9d0006 7d4a4f5e 7f3ccb78 4820 812b0004 800b
39290001
7c004850 7f805040 419c0044 7fdcf378 83dc 3800 2f9e
41beffe8
---[ end trace 8640abe69a316dee ]---
Kernel panic - not syncing: Attempted to kill init!
Rebooting in 180 seconds..
- - - -
It seems like be8cbcd8896670a01ead7a29e33ff is at fault.
static void __devinit __pcibios_fixup_bus(struct pci_bus *bus)
{
...
if (i = 3 bus-self-transparent)
continue;
...
}
That new check doesn't work, here bus-self-transparent == 0.
Could it be that the message below is the root cause?
PCI: 0001:01:00.0: class b20 doesn't match header type 01. Ignoring
class.
this is expected but of how FSL hw reports itself.
I.e. drivers/pci/probe.c just don't setting transparent flag.
I wonder if we need use quirk_transparent_bridge() here or
we can fix it other way?
Just in case, I'm observing that message for a long long time, and
it didn't tell upon any functionality till now.
Is this with the 8568 MDS in standalone or plugged into the back pane?
- k
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: mpc8568e-mds: pci-e is broken
On Wed, Jan 23, 2008 at 01:42:56PM -0600, Kumar Gala wrote:
[...]
PCI: Probing PCI hardware
PCI: 0001:01:00.0: class b20 doesn't match header type 01. Ignoring
class.
PCI: Closing bogus Apple Firmware region 1 on bus 0x02
PCI: Closing bogus Apple Firmware region 2 on bus 0x02
odd, you shouldn't see these anymore w/my git tree.
Yup, I noticed few commits that are trying to fix this. And these
fixes do work for PCI, but not for PCI-E...
[...]
static void __devinit __pcibios_fixup_bus(struct pci_bus *bus)
{
...
if (i = 3 bus-self-transparent)
continue;
...
}
That new check doesn't work, here bus-self-transparent == 0.
Could it be that the message below is the root cause?
PCI: 0001:01:00.0: class b20 doesn't match header type 01. Ignoring
class.
this is expected but of how FSL hw reports itself.
Well. I see only two places were transparent flag is applied:
drivers/pci/quirks.c:quirk_transparent_bridge()
and
drivers/pci/probe.c:pci_setup_device() in the PCI_HEADER_TYPE_BRIDGE.
So, obviously probe.c is skipping our PCI-E, thus not setting
transparent flag, no?
I.e. drivers/pci/probe.c just don't setting transparent flag.
I wonder if we need use quirk_transparent_bridge() here or
we can fix it other way?
Just in case, I'm observing that message for a long long time, and
it didn't tell upon any functionality till now.
Is this with the 8568 MDS in standalone or plugged into the back pane?
This is standalone setup.
Thanks,
--
Anton Vorontsov
email: [EMAIL PROTECTED]
backup email: [EMAIL PROTECTED]
irc://irc.freenode.net/bd2
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCHv2 0/8] [POWERPC] 8xx cleanups
On Wed, Jan 23, 2008 at 01:35:41PM -0600, Josh Boyer wrote: On Wed, 23 Jan 2008 19:00:12 +0100 Sam Ravnborg [EMAIL PROTECTED] wrote: On Wed, Jan 23, 2008 at 11:31:46AM -0600, Jon Loeliger wrote: Sam Ravnborg wrote: What impact do the have on boards in arch/ppc being able to build? Byt the way what are the plans for powerpc? We have: arch/ppc arch/ppc64 arch/powerpc It was my understanding that arch/powerpc was supposed to be the future unified powerpc architecture but it does not even provide a defconfig. And I do not see too much happening to do so - but that maybe because I looked at a wrong place. You must have looked in the wrong place. :-) arch/ppc is scheduled for removal from mainline in June. Good to hear. arch/powerpc is under significant development, with lots of defconfigs in arch/powerpc/configs. Double checked - it was my build script that used ARCH=ppc Now I just need to build another toolchain as the ppc750 could not build the defconfig. crosstool is my friend here. You'll need mkimage if you ever venture into some of the embedded board configs. Just an FYI. I known - for now I'm 120% occupied getting modpost in shape and will return to the mkimage thread when below 100%. Sam ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 3/3] Add device tree compatible aliases to i2c drivers
Jon Smirl wrote:
--- a/drivers/i2c/chips/tps65010.c
+++ b/drivers/i2c/chips/tps65010.c
@@ -571,6 +571,10 @@ static const struct i2c_device_id tps65010_id[] = {
{ tps65011, TPS65011 },
{ tps65012, TPS65012 },
{ tps65013, TPS65013 },
+ OF_ID(ti,tps65010, TPS65010)
+ OF_ID(ti,tps65011, TPS65011)
+ OF_ID(ti,tps65012, TPS65012)
+ OF_ID(ri,tps65013, TPS65013)
{ },
ti, ti, ti, ri?
--- a/drivers/rtc/rtc-ds1307.c
+++ b/drivers/rtc/rtc-ds1307.c
@@ -129,6 +129,12 @@ static const struct i2c_device_id ds1307_id[] = {
{ ds1339, ds_1339 },
{ ds1340, ds_1340 },
{ m41t00, m41t00 },
+ OF_ID(dallas,ds1307, ds_1307)
+ OF_ID(dallas,ds1337, ds_1337)
+ OF_ID(dallas,ds1338, ds_1338)
+ OF_ID(dallas,ds1339, ds_1339)
+ OF_ID(dallas,ds1340, ds_1340)
+ OF_ID(stm,m41t00, m41t00)
{},
};
The convention is to use the stock ticker, capitalized, if a company
has one, I guess dallas is MXIM these days, but dallas is a good
substitute based on the fact that most people still remember Dallas
clock chips and so on from the Ancient Days. STMicroelectronics is STM.
I couldn't care less about case sensitivity, but the stock ticker
thing was always a good idea.. it gives a sort of grounding in reality
for the manufacturer names.
Are we still following this convention or are the names of devices
simply arbitrarily defined by Linux kernel developers now?
--
Matt Sealey [EMAIL PROTECTED]
Genesi, Manager, Developer Relations
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 3/3] Add device tree compatible aliases to i2c drivers
On 1/23/08, Matt Sealey [EMAIL PROTECTED] wrote:
Jon Smirl wrote:
--- a/drivers/i2c/chips/tps65010.c
+++ b/drivers/i2c/chips/tps65010.c
@@ -571,6 +571,10 @@ static const struct i2c_device_id tps65010_id[] = {
{ tps65011, TPS65011 },
{ tps65012, TPS65012 },
{ tps65013, TPS65013 },
+ OF_ID(ti,tps65010, TPS65010)
+ OF_ID(ti,tps65011, TPS65011)
+ OF_ID(ti,tps65012, TPS65012)
+ OF_ID(ri,tps65013, TPS65013)
{ },
ti, ti, ti, ri?
--- a/drivers/rtc/rtc-ds1307.c
+++ b/drivers/rtc/rtc-ds1307.c
@@ -129,6 +129,12 @@ static const struct i2c_device_id ds1307_id[] = {
{ ds1339, ds_1339 },
{ ds1340, ds_1340 },
{ m41t00, m41t00 },
+ OF_ID(dallas,ds1307, ds_1307)
+ OF_ID(dallas,ds1337, ds_1337)
+ OF_ID(dallas,ds1338, ds_1338)
+ OF_ID(dallas,ds1339, ds_1339)
+ OF_ID(dallas,ds1340, ds_1340)
+ OF_ID(stm,m41t00, m41t00)
{},
};
The convention is to use the stock ticker, capitalized, if a company
has one, I guess dallas is MXIM these days, but dallas is a good
substitute based on the fact that most people still remember Dallas
clock chips and so on from the Ancient Days. STMicroelectronics is STM.
I couldn't care less about case sensitivity, but the stock ticker
thing was always a good idea.. it gives a sort of grounding in reality
for the manufacturer names.
I'll put in whatever the Open Firmware police tell me to. We just all
need to come to an agreement.
Are we still following this convention or are the names of devices
simply arbitrarily defined by Linux kernel developers now?
--
Matt Sealey [EMAIL PROTECTED]
Genesi, Manager, Developer Relations
--
Jon Smirl
[EMAIL PROTECTED]
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] [POWERPC] MPC8360E-RDK: device tree, board file and defconfig
This is new board made by Freescale Semiconductor Inc. and
Logic Product Development.
Currently supported:
1. UEC{1,2,7,4};
2. I2C;
3. SPI;
4. NS16550 serial;
5. PCI and miniPCI;
6. Intel NOR StrataFlash X16 64Mbit PC28F640P30T85;
7. Graphics controller, Fujitsu MB86277.
Not supported so far:
1. StMICRO NAND512W3A2BN6E, 512 Mbit (supported with FSL UPM patches);
2. QE Serial UCCs (tested to not work with ucc_uart driver, reason
unknown, yet);
3. ADC AD7843 (tested to work, but support via device tree depends on
major SPI rework, GPIO API, etc);
4. FHCI USB (will send RFC patches soon).
Signed-off-by: Anton Vorontsov [EMAIL PROTECTED]
---
Hello Kumar,
...if there will no further comments regarding this board, it would
be great if you will merge it for 2.6.25. I've reworked that patch so
today it doesn't depend on the cleanup queue. That is, the device tree
includes device_type and other cruft that will be removed along with
other boards.
Another change is: display node addition. It could be not fully
correct regarding device_type etc, but that's what offb driver
understands for today.
Thanks,
arch/powerpc/boot/dts/mpc836x_rdk.dts | 380 ++
arch/powerpc/configs/mpc836x_rdk_defconfig | 1054
arch/powerpc/platforms/83xx/Kconfig| 11 +-
arch/powerpc/platforms/83xx/Makefile |1 +
arch/powerpc/platforms/83xx/mpc836x_rdk.c | 114 +++
5 files changed, 1559 insertions(+), 1 deletions(-)
create mode 100644 arch/powerpc/boot/dts/mpc836x_rdk.dts
create mode 100644 arch/powerpc/configs/mpc836x_rdk_defconfig
create mode 100644 arch/powerpc/platforms/83xx/mpc836x_rdk.c
diff --git a/arch/powerpc/boot/dts/mpc836x_rdk.dts
b/arch/powerpc/boot/dts/mpc836x_rdk.dts
new file mode 100644
index 000..b8f87ac
--- /dev/null
+++ b/arch/powerpc/boot/dts/mpc836x_rdk.dts
@@ -0,0 +1,380 @@
+/*
+ * MPC8360E RDK Device Tree Source
+ *
+ * Copyright 2006 Freescale Semiconductor Inc.
+ * Copyright 2007 MontaVista Software, Inc.
+ * Anton Vorontsov [EMAIL PROTECTED]
+ *
+ * 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 the
+ * Free Software Foundation; either version 2 of the License, or (at your
+ * option) any later version.
+ */
+
+/dts-v1/;
+
+/ {
+ #address-cells = 1;
+ #size-cells = 1;
+ compatible = MPC8360ERDK, MPC836xRDK, MPC83xxRDK;
+ model = MPC8360RDK;
+
+ aliases {
+ serial0 = serial0;
+ serial1 = serial1;
+ serial2 = serial2;
+ serial3 = serial3;
+ ethernet0 = enet0;
+ ethernet1 = enet1;
+ ethernet2 = enet2;
+ ethernet3 = enet3;
+ pci0 = pci0;
+ };
+
+ cpus {
+ #address-cells = 1;
+ #size-cells = 0;
+
+ PowerPC,[EMAIL PROTECTED] {
+ device_type = cpu;
+ reg = 0;
+ d-cache-line-size = 32;
+ i-cache-line-size = 32;
+ d-cache-size = 32768;
+ i-cache-size = 32768;
+ /* filled by u-boot */
+ timebase-frequency = 0;
+ bus-frequency = 0;
+ clock-frequency = 0;
+ };
+ };
+
+ memory {
+ device_type = memory;
+ /* filled by u-boot */
+ reg = 0 0;
+ };
+
+ [EMAIL PROTECTED] {
+ #address-cells = 1;
+ #size-cells = 1;
+ device_type = soc;
+ compatible = fsl,mpc8360-soc, fsl,soc, soc;
+ ranges = 0 0xe000 0x10;
+ reg = 0xe000 0x200;
+ /* filled by u-boot */
+ bus-frequency = 0;
+
+ [EMAIL PROTECTED] {
+ compatible = mpc83xx_wdt;
+ reg = 0x200 0x100;
+ };
+
+ [EMAIL PROTECTED] {
+ #address-cells = 1;
+ #size-cells = 0;
+ cell-index = 0;
+ compatible = fsl-i2c;
+ reg = 0x3000 0x100;
+ interrupts = 14 8;
+ interrupt-parent = ipic;
+ dfsrr;
+ };
+
+ [EMAIL PROTECTED] {
+ #address-cells = 1;
+ #size-cells = 0;
+ cell-index = 1;
+ compatible = fsl-i2c;
+ reg = 0x3100 0x100;
+ interrupts = 16 8;
+ interrupt-parent = ipic;
+ dfsrr;
+ };
+
+ serial0: [EMAIL PROTECTED] {
+ device_type = serial;
+
Re: [PATCH] Fix boot problem in situations where the boot CPU is running on a memoryless node
Hi, On Jan 23, 2008 9:52 PM, Nishanth Aravamudan [EMAIL PROTECTED] wrote: On at least one of the machines in question, wasn't it the case that node 0 had all the memory and node 1 had all the CPUs? In that case, you would have to boot off a memoryless node? And as long as that is a physically valid configuration, the kernel should handle it. Agreed. Here's the patch that should fix it: http://lkml.org/lkml/2008/1/23/332 On Jan 23, 2008 9:52 PM, Nishanth Aravamudan [EMAIL PROTECTED] wrote: I bet we didn't notice this breaking because SLUB became the default and SLAB isn't on in the test.kernel.org testing, for instance. Perhaps we should add a second set of runs for some of the boxes there to run with CONFIG_SLAB on? Sure. On Jan 23, 2008 9:52 PM, Nishanth Aravamudan [EMAIL PROTECTED] wrote: I'm curious if we know, for sure, of a kernel with CONFIG_SLAB=y that has booted all of the boxes reporting issues? That is, did they all work with 2.6.23? I think Mel said that their configuration did work with 2.6.23 although I also wonder how that's possible. AFAIK there has been some changes in the page allocator that might explain this. That is, if kmem_getpages() returned pages for memoryless node before, bootstrap would have worked. Pekka ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] Fix boot problem in situations where the boot CPU is running on a memoryless node
On Wed, 23 Jan 2008, Pekka Enberg wrote: I think Mel said that their configuration did work with 2.6.23 although I also wonder how that's possible. AFAIK there has been some changes in the page allocator that might explain this. That is, if kmem_getpages() returned pages for memoryless node before, bootstrap would have worked. Regular kmem_getpages is called with GFP_THISNODE set. There was some breakage in 2.6.22 and before with GFP_THISNODE returning pages from the wrong node if a node had no memory. So it may have worked accidentally and in an unsafe manner because the pages would have been associated with the wrong node which could trigger bug ons and locking troubles. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [patch v4 0/4] Cypress c67x00 (EZ-Host/EZ-OTG) support
Grant == Grant Likely [EMAIL PROTECTED] writes: Grant Okay, I've had a chance to read through this. I haven't Grant tested it, but I don't see anything I strongly disagree with. Grant I've just got a few editorial comments below and a question. Ok, great. Grant The question is about the device structure which used to be provided Grant by the platform device instances and now there just uses the c67x00's Grant device struct. I was under the impression that each USB HCD needs to Grant have it's own struct device. I take it that's not true? Not afaik. In fact, I changed this based on feedback from David back when I first time posted the patch series: http://article.gmane.org/gmane.linux.usb.devel/53496 But I don't have a board with host connectors on both SIEs, so I haven't actually been able to test it. Grant Otherwise: Grant Acked-by: Grant Likely [EMAIL PROTECTED] Grant Cheers, Grant g. diff --git a/drivers/usb/c67x00/c67x00-drv.c b/drivers/usb/c67x00/c67x00-drv.c index 0f0720a..c2ea3b6 100644 --- a/drivers/usb/c67x00/c67x00-drv.c +++ b/drivers/usb/c67x00/c67x00-drv.c @@ -203,19 +175,19 @@ static int __devinit c67x00_drv_probe(struct platform_device *pdev) } for (i = 0; i C67X00_SIES; i++) - c67x00_probe_sie(c67x00-sie[i]); + c67x00_probe_sie(c67x00-sie[i], c67x00, i); platform_set_drvdata(pdev, c67x00); return 0; - reset_failed: +reset_failed: free_irq(res2-start, c67x00); - request_irq_failed: +request_irq_failed: iounmap(c67x00-hpi.base); - map_failed: +map_failed: release_mem_region(res-start, res-end - res-start + 1); - request_mem_failed: +request_mem_failed: Grant A single space should be preserved in front of the labels. Doing so Grant means that git-diff picks up the function name instead of the label Grant when generating output. Ok. Emacs doesn't seem to do this by default. diff --git a/drivers/usb/c67x00/c67x00-hcd.c b/drivers/usb/c67x00/c67x00-hcd.c index 3d0b77e..4afb291 100644 --- a/drivers/usb/c67x00/c67x00-hcd.c +++ b/drivers/usb/c67x00/c67x00-hcd.c @@ -368,23 +383,26 @@ int c67x00_hcd_probe(struct c67x00_sie *sie) goto err2; } + spin_lock_irqsave(sie-lock, flags); + sie-private_data = c67x00; + sie-irq = c67x00_hcd_irq; + spin_unlock_irqrestore(sie-lock, flags); + return retval; - err2: +err2: c67x00_sched_stop_scheduler(c67x00); - err1: +err1: usb_put_hcd(hcd); - err0: +err0: Grant Ditto on the labels diff --git a/drivers/usb/c67x00/c67x00-hcd.h b/drivers/usb/c67x00/c67x00-hcd.h index 5b35f01..daee4cd 100644 --- a/drivers/usb/c67x00/c67x00-hcd.h +++ b/drivers/usb/c67x00/c67x00-hcd.h @@ -132,6 +147,6 @@ void c67x00_sched_kick(struct c67x00_hcd *c67x00); int c67x00_sched_start_scheduler(struct c67x00_hcd *c67x00); void c67x00_sched_stop_scheduler(struct c67x00_hcd *c67x00); -#define c67x00_hcd_dev(x) (c67x00_hcd_to_hcd(x)-self.controller) +#define c67x00_dev(x) (c67x00_hcd_to_hcd(x)-self.controller) Grant Can the name c67x00_hcd_dev() be used instead? This macro is used Grant with 'struct c67x00_hcd', not 'struct c67x00' and I find the code less Grant confusing if the macro name reflects that. Well, we can. I didn't copy your name change over as the hcds don't have their own struct device in my series, but I don't feel strongly about the issue. #endif /* _USB_C67X00_HCD_H */ diff --git a/drivers/usb/c67x00/c67x00-sched.c b/drivers/usb/c67x00/c67x00-sched.c index 35d7318..3140d89 100644 --- a/drivers/usb/c67x00/c67x00-sched.c +++ b/drivers/usb/c67x00/c67x00-sched.c - /* Something went wrong; unwind the allocations */ - err_epdata: +err_epdata: kfree(urbp); - err_urbp: +err_urbp: usb_hcd_unlink_urb_from_ep(hcd, urb); - err_not_linked: +err_not_linked: Grant ditto Grant Cheers, Grant g. Thanks for the feedback, I'll post an updated series. -- Bye, Peter Korsgaard ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [patch v4 0/4] Cypress c67x00 (EZ-Host/EZ-OTG) support
David == David Brownell [EMAIL PROTECTED] writes: David On Wednesday 23 January 2008, Grant Likely wrote: The question is about the device structure which used to be provided by the platform device instances and now there just uses the c67x00's device struct. I was under the impression that each USB HCD needs to have it's own struct device. I take it that's not true? David Each root hub necessarily is a unique device, representing a set David of downstream links. Unless Peter didn't test something relevant, David it would seem we have observational proof that two root hubs can David share the same device node for an upstream link. I haven't actually tested a setup with HCDs on both SIEs as I don't have a board with host connectors on both, but I've done the change based on your feedback: http://article.gmane.org/gmane.linux.usb.devel/53496 David I can't think of a reason to demand multiple upstream links, though David sharing them between root hubs like that isn't a common structure. David - Dave -- Bye, Peter Korsgaard ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] Fix boot problem in situations where the boot CPU is running on a memoryless node
On 23.01.2008 [13:14:26 -0800], Christoph Lameter wrote: On Wed, 23 Jan 2008, Pekka Enberg wrote: I think Mel said that their configuration did work with 2.6.23 although I also wonder how that's possible. AFAIK there has been some changes in the page allocator that might explain this. That is, if kmem_getpages() returned pages for memoryless node before, bootstrap would have worked. Regular kmem_getpages is called with GFP_THISNODE set. There was some breakage in 2.6.22 and before with GFP_THISNODE returning pages from the wrong node if a node had no memory. So it may have worked accidentally and in an unsafe manner because the pages would have been associated with the wrong node which could trigger bug ons and locking troubles. Right, so it might have functioned before, but the correctness was wobbly at best... Certainly the memoryless patch series has tightened that up, but we missed these SLAB issues. I see that your patch fixed Olaf's machine, Pekka. Nice work on everyone's part tracking this stuff down. Thanks, Nish ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: mpc8568e-mds: pci-e is broken
On Jan 23, 2008, at 1:50 PM, Anton Vorontsov wrote:
On Wed, Jan 23, 2008 at 01:42:56PM -0600, Kumar Gala wrote:
[...]
PCI: Probing PCI hardware
PCI: 0001:01:00.0: class b20 doesn't match header type 01. Ignoring
class.
PCI: Closing bogus Apple Firmware region 1 on bus 0x02
PCI: Closing bogus Apple Firmware region 2 on bus 0x02
odd, you shouldn't see these anymore w/my git tree.
Yup, I noticed few commits that are trying to fix this. And these
fixes do work for PCI, but not for PCI-E...
I see these now.. I think I'm too lazy to think of a way to fix this.
[...]
static void __devinit __pcibios_fixup_bus(struct pci_bus *bus)
{
...
if (i = 3 bus-self-transparent)
continue;
...
}
That new check doesn't work, here bus-self-transparent == 0.
Could it be that the message below is the root cause?
PCI: 0001:01:00.0: class b20 doesn't match header type 01. Ignoring
class.
this is expected but of how FSL hw reports itself.
Well. I see only two places were transparent flag is applied:
drivers/pci/quirks.c:quirk_transparent_bridge()
and
drivers/pci/probe.c:pci_setup_device() in the PCI_HEADER_TYPE_BRIDGE.
So, obviously probe.c is skipping our PCI-E, thus not setting
transparent flag, no?
I.e. drivers/pci/probe.c just don't setting transparent flag.
I wonder if we need use quirk_transparent_bridge() here or
we can fix it other way?
Just in case, I'm observing that message for a long long time, and
it didn't tell upon any functionality till now.
Is this with the 8568 MDS in standalone or plugged into the back
pane?
This is standalone setup.
do you have a card plugged in?
- k
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH v6] [POWERPC] Add LED driver for Promess Motion-PRO board.
Hi Marian,
On Wed, 23 Jan 2008 13:12:19 +0100 Marian Balakowicz [EMAIL PROTECTED] wrote:
+ label = of_get_property(op-node, label, NULL);
+ if (label == NULL) {
+ printk(KERN_ERR __FILE__ :
+ No label property provided for LED %s\n,
+ op-node-full_name);
+ err = -EINVAL;
+ goto err_free;
You need an iounmap(mpled-gpt) here - or preferably jump to the one in
the error path below.
--
Cheers,
Stephen Rothwell[EMAIL PROTECTED]
http://www.canb.auug.org.au/~sfr/
pgpdgjBoJsTsf.pgp
Description: PGP signature
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] [POWERPC] Move RapidIO support code from arch/ppc
Hi Kumar, On Wed, 23 Jan 2008 06:38:29 -0600 (CST) Kumar Gala [EMAIL PROTECTED] wrote: +++ b/arch/ppc/platforms/85xx/mpc85xx_ads_common.c @@ -190,6 +188,7 @@ mpc85xx_exclude_device(u_char bus, u_char devfn) #endif /* CONFIG_PCI */ #ifdef CONFIG_RAPIDIO +extern void mpc85xx_rio_setup(int law_start, int law_size); Ooops! This should be in a header file, of course. +++ b/arch/ppc/platforms/85xx/stx_gp3.c @@ -270,6 +269,7 @@ int mpc85xx_exclude_device(u_char bus, u_char devfn) #endif /* CONFIG_PCI */ #ifdef CONFIG_RAPIDIO +extern void mpc85xx_rio_setup(int law_start, int law_size); And again. I guess this is just temporary in which case we can probably live with it. But do not forget to fix it up. +++ b/arch/ppc/platforms/85xx/tqm85xx.c @@ -309,6 +308,7 @@ int mpc85xx_exclude_device(u_char bus, u_char devfn) #endif /* CONFIG_PCI */ #ifdef CONFIG_RAPIDIO +extern void mpc85xx_rio_setup(int law_start, int law_size); Third time lucky? :-) -- Cheers, Stephen Rothwell[EMAIL PROTECTED] http://www.canb.auug.org.au/~sfr/ pgpltRwAeOY7S.pgp Description: PGP signature ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [MPC5200] problem running FEC and ATA
In message [EMAIL PROTECTED] you wrote: Is it really exactly the same CPU revision? My guess is that one is rev. B and the other one is older... The processor on my board which needs the BSDIS-patch has following label: MPC5200CVR400B And the one which doesn't need it is a ...? Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: [EMAIL PROTECTED] I'd rather be led to hell than managed to heaven. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [MPC5200] problem running FEC and ATA
In message [EMAIL PROTECTED] you wrote: The one who needs this patch (CPU card vendor 1): MPC5200CVR400B, M62C REV 1, QCW0723T The CPUs who do not need this patch (CPU card vendor 2): SPC5200CBV400B, M62C REV 1, QAG0610C MPC5200CVR400B, M62C REV 1, QAJ0613F This is all Rev. B stuff, and the patch should be applied to all of them (actually the patch can always be applied - it will be activated depending on the PVR reading). Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: [EMAIL PROTECTED] It is impractical for the standard to attempt to constrain the behavior of code that does not obey the constraints of the standard. - Doug Gwyn ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH][ppc] logical/bitand typo in powerpc/boot/4xx.c
logical/bitand typo
Signed-off-by: Roel Kluin [EMAIL PROTECTED]
---
diff --git a/arch/powerpc/boot/4xx.c b/arch/powerpc/boot/4xx.c
index ebf9e21..dcfb459 100644
--- a/arch/powerpc/boot/4xx.c
+++ b/arch/powerpc/boot/4xx.c
@@ -104,7 +104,7 @@ void ibm4xx_denali_fixup_memsize(void)
val = DDR_GET_VAL(val, DDR_CS_MAP, DDR_CS_MAP_SHIFT);
cs = 0;
while (val) {
- if (val 0x1)
+ if (val 0x1)
cs++;
val = val 1;
}
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] [POWERPC] Move RapidIO support code from arch/ppc
On Jan 23, 2008, at 4:40 PM, Stephen Rothwell wrote: Hi Kumar, On Wed, 23 Jan 2008 06:38:29 -0600 (CST) Kumar Gala [EMAIL PROTECTED] wrote: +++ b/arch/ppc/platforms/85xx/mpc85xx_ads_common.c @@ -190,6 +188,7 @@ mpc85xx_exclude_device(u_char bus, u_char devfn) #endif /* CONFIG_PCI */ #ifdef CONFIG_RAPIDIO +extern void mpc85xx_rio_setup(int law_start, int law_size); Ooops! This should be in a header file, of course. +++ b/arch/ppc/platforms/85xx/stx_gp3.c @@ -270,6 +269,7 @@ int mpc85xx_exclude_device(u_char bus, u_char devfn) #endif /* CONFIG_PCI */ #ifdef CONFIG_RAPIDIO +extern void mpc85xx_rio_setup(int law_start, int law_size); And again. I guess this is just temporary in which case we can probably live with it. But do not forget to fix it up. +++ b/arch/ppc/platforms/85xx/tqm85xx.c @@ -309,6 +308,7 @@ int mpc85xx_exclude_device(u_char bus, u_char devfn) #endif /* CONFIG_PCI */ #ifdef CONFIG_RAPIDIO +extern void mpc85xx_rio_setup(int law_start, int law_size); Third time lucky? :-) They were in a header file, however in moving the code over the header ends up in arch/powerpc/sysdev/fsl_rio.h. I don't think there is a simple way to include that in arch/ppc code today (and I don't want to invent one). My goal is to just kill 85xx for arch/ppc. - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH v2] Fix handling of memreserve if the range lands in highmem
Kumar Gala writes: There were several issues if a memreserve range existed and happened to be in highmem: * The bootmem allocator is only aware of lowmem so calling reserve_bootmem with a highmem address would cause a BUG_ON * All highmem pages were provided to the buddy allocator Added a lmb_is_reserved() api that we now use to determine if a highem page should continue to be PageReserved or provided to the buddy allocator. Also, we incorrectly reported the amount of pages reserved since all highmem pages are initally marked reserved and we clear the PageReserved flag as we free up the highmem pages. This patch breaks all the 64-bit configs since 64-bit doesn't have total_lowmem. The extra complexity is only needed in the CONFIG_HIGHMEM case, so an ifdef would be one solution, though an ugly one. We do already have an ifdef just above the place you changed in arch/powerpc/mm/mem.c which you could just enlarge rather than adding a new ifdef. And clearly I can't pull your tree until this is sorted somehow... Paul. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH][ppc] logical/bitand typo in powerpc/boot/4xx.c
On Wed, 2008-01-23 at 23:37 +0100, Roel Kluin wrote:
Signed-off-by: Roel Kluin [EMAIL PROTECTED]
---
diff --git a/arch/powerpc/boot/4xx.c b/arch/powerpc/boot/4xx.c
index ebf9e21..dcfb459 100644
--- a/arch/powerpc/boot/4xx.c
+++ b/arch/powerpc/boot/4xx.c
@@ -104,7 +104,7 @@ void ibm4xx_denali_fixup_memsize(void)
val = DDR_GET_VAL(val, DDR_CS_MAP, DDR_CS_MAP_SHIFT);
cs = 0;
while (val) {
- if (val 0x1)
+ if (val 0x1)
cs++;
val = val 1;
I think this pattern should be added to checkpatch
Signed-off-by: Joe Perches [EMAIL PROTECTED]
diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
index 579f50f..147e573 100755
--- a/scripts/checkpatch.pl
+++ b/scripts/checkpatch.pl
@@ -1337,6 +1337,11 @@ sub process {
}
}
+# Check for bitwise tests written as boolean
+ if ($line =~ /\\\s*0[xX]/) {
+ WARN(boolean test with hexadecimal, perhaps just 1
\?\n . $herecurr);
+ }
+
# if and else should not have general statements after it
if ($line =~ /^.\s*(?:}\s*)?else\b(.*)/
$1 !~ /^\s*(?:\sif|{|\\|$)/) {
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 3/4 v4] POWERPC: Add initial iomega StorCenter board port.
Hi Jon,
On Wed, 23 Jan 2008 12:42:50 -0600 Jon Loeliger [EMAIL PROTECTED] wrote:
+++ b/arch/powerpc/platforms/embedded6xx/storcenter.c
+static void __init storcenter_init_IRQ(void)
+{
+ struct mpic *mpic;
+ struct device_node *dnp;
+ const void *prop;
+ int size;
+ phys_addr_t paddr;
+
+ dnp = of_find_node_by_type(NULL, open-pic);
+ if (dnp == NULL)
+ return;
+
+ prop = of_get_property(dnp, reg, size);
+ if (prop == NULL)
+ return;
You need an of_node_put(dnp) before you return.
--
Cheers,
Stephen Rothwell[EMAIL PROTECTED]
http://www.canb.auug.org.au/~sfr/
pgpd4vhBbH8XK.pgp
Description: PGP signature
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH][ppc] logical/bitand typo in powerpc/boot/4xx.c
On Thu, 2008-01-24 at 01:18 +0100, Roel Kluin wrote:
when you use git-grep -n \(\|||\)${s}0x\([A-Z0-9]*\|[a-z0-9]*\),
(with s=[[:space:]]*) there will be false positives []
so i'd propose to change that to
+# Check for bitwise tests written as boolean
+ if ($line =~ /(?:(?:\(|\\|\|\|)\s*0[xX]\s*(?:|\|\|)|
+ (?:\\|\|\|)\s*0[xX]\s*(?:\)||\|\|))/) {
+ WARN(boolean test with hexadecimal, perhaps just 1 \
or \|?\n . $herecurr);
+ }
+
All 13 false positives are hex_constant logical_test variable.
I think that Linus would say that they are all poor style.
Still, fine by me. cheers, Joe
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH][ppc] logical/bitand typo in powerpc/boot/4xx.c
On Wed, 23 Jan 2008 23:37:33 +0100
Roel Kluin [EMAIL PROTECTED] wrote:
logical/bitand typo
Signed-off-by: Roel Kluin [EMAIL PROTECTED]
---
diff --git a/arch/powerpc/boot/4xx.c b/arch/powerpc/boot/4xx.c
index ebf9e21..dcfb459 100644
--- a/arch/powerpc/boot/4xx.c
+++ b/arch/powerpc/boot/4xx.c
@@ -104,7 +104,7 @@ void ibm4xx_denali_fixup_memsize(void)
val = DDR_GET_VAL(val, DDR_CS_MAP, DDR_CS_MAP_SHIFT);
cs = 0;
while (val) {
- if (val 0x1)
+ if (val 0x1)
cs++;
val = val 1;
}
Hm, good catch.
Stefan, have you had problems with this code at all?
josh
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 1/2] [POWERPC] 8xx: Use machine_*_initcall() hooks in platform code
On Mon, 21 Jan 2008, Grant Likely wrote: From: Grant Likely [EMAIL PROTECTED] Signed-off-by: Grant Likely [EMAIL PROTECTED] --- arch/powerpc/platforms/8xx/ep88xc.c |5 ++--- arch/powerpc/platforms/8xx/mpc86xads_setup.c |5 ++--- arch/powerpc/platforms/8xx/mpc885ads_setup.c |5 ++--- 3 files changed, 6 insertions(+), 9 deletions(-) applied. - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] [POWERPC] Add fixed-phy support for fs_enet
On Tue, 18 Dec 2007, Jochen Friedrich wrote: This patch adds support to use the fixed-link property of an ethernet node to fs_enet for the CONFIG_PPC_CPM_NEW_BINDING case. Signed-off-by: Jochen Friedrich [EMAIL PROTECTED] Acked-by: Jeff Garzik [EMAIL PROTECTED] Acked-by: Vitali Bordug [EMAIL PROTECTED] --- drivers/net/fs_enet/fs_enet-main.c |9 - 1 files changed, 8 insertions(+), 1 deletions(-) applied. - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 3/4 v4] POWERPC: Add initial iomega StorCenter board port.
On Jan 23, 2008, at 6:50 PM, Stephen Rothwell wrote:
Hi Jon,
On Wed, 23 Jan 2008 12:42:50 -0600 Jon Loeliger [EMAIL PROTECTED] wrote:
+++ b/arch/powerpc/platforms/embedded6xx/storcenter.c
+static void __init storcenter_init_IRQ(void)
+{
+struct mpic *mpic;
+struct device_node *dnp;
+const void *prop;
+int size;
+phys_addr_t paddr;
+
+dnp = of_find_node_by_type(NULL, open-pic);
+if (dnp == NULL)
+return;
+
+prop = of_get_property(dnp, reg, size);
+if (prop == NULL)
+return;
You need an of_node_put(dnp) before you return.
Fixed up by your friendly maintainer.
- k
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Please pull from 'for-2.6.25' branch
Please pull from 'for-2.6.25' branch of master.kernel.org:/pub/scm/linux/kernel/git/galak/powerpc.git for-2.6.25 to receive the following updates: (I fixed up the memreserve patch, it builds for me on ppc64) Documentation/powerpc/00-INDEX|3 Documentation/powerpc/booting-without-of.txt | 91 + Documentation/powerpc/qe_firmware.txt | 295 arch/powerpc/Kconfig |3 arch/powerpc/boot/.gitignore |1 arch/powerpc/boot/Makefile| 10 arch/powerpc/boot/cuboot-824x.c | 53 arch/powerpc/boot/cuboot-83xx.c |3 arch/powerpc/boot/cuboot-85xx.c |5 arch/powerpc/boot/devtree.c | 14 arch/powerpc/boot/dts/adder875-redboot.dts| 184 ++ arch/powerpc/boot/dts/adder875-uboot.dts | 183 ++ arch/powerpc/boot/dts/ep8248e.dts | 207 +++ arch/powerpc/boot/dts/mpc8313erdb.dts | 49 arch/powerpc/boot/dts/mpc832x_mds.dts | 51 arch/powerpc/boot/dts/mpc8349emitx.dts| 30 arch/powerpc/boot/dts/mpc8349emitxgp.dts |1 arch/powerpc/boot/dts/mpc834x_mds.dts |2 arch/powerpc/boot/dts/mpc836x_mds.dts |1 arch/powerpc/boot/dts/mpc8377_mds.dts | 279 arch/powerpc/boot/dts/mpc8378_mds.dts | 265 +++ arch/powerpc/boot/dts/mpc8379_mds.dts | 293 arch/powerpc/boot/dts/mpc8544ds.dts |6 arch/powerpc/boot/dts/mpc8572ds.dts |7 arch/powerpc/boot/dts/mpc8610_hpcd.dts| 113 + arch/powerpc/boot/dts/mpc8641_hpcn.dts| 48 arch/powerpc/boot/dts/storcenter.dts | 138 ++ arch/powerpc/boot/ep8248e.c | 55 arch/powerpc/boot/ops.h | 14 arch/powerpc/boot/redboot-8xx.c | 58 arch/powerpc/boot/redboot.h | 56 arch/powerpc/boot/wrapper |2 arch/powerpc/configs/adder875-redboot_defconfig | 798 +++ arch/powerpc/configs/adder875-uboot_defconfig | 798 +++ arch/powerpc/configs/ep8248e_defconfig| 821 +++ arch/powerpc/configs/mpc8313_rdb_defconfig| 46 arch/powerpc/configs/mpc834x_itx_defconfig|3 arch/powerpc/configs/mpc8610_hpcd_defconfig | 171 ++ arch/powerpc/configs/storcenter_defconfig | 1174 + arch/powerpc/kernel/Makefile |1 arch/powerpc/kernel/head_fsl_booke.S | 20 arch/powerpc/kernel/pci-common.c |8 arch/powerpc/kernel/pci_32.c | 58 arch/powerpc/kernel/rio.c | 52 arch/powerpc/math-emu/op-4.h | 40 arch/powerpc/mm/fsl_booke_mmu.c |6 arch/powerpc/mm/lmb.c | 13 arch/powerpc/mm/mem.c | 21 arch/powerpc/platforms/82xx/Kconfig | 13 arch/powerpc/platforms/82xx/Makefile |1 arch/powerpc/platforms/82xx/ep8248e.c | 324 arch/powerpc/platforms/83xx/mpc8313_rdb.c | 13 arch/powerpc/platforms/83xx/mpc832x_mds.c |5 arch/powerpc/platforms/83xx/mpc832x_rdb.c | 10 arch/powerpc/platforms/83xx/mpc834x_itx.c | 12 arch/powerpc/platforms/83xx/mpc834x_mds.c |5 arch/powerpc/platforms/83xx/mpc836x_mds.c |5 arch/powerpc/platforms/83xx/mpc837x_mds.c | 56 arch/powerpc/platforms/83xx/mpc83xx.h |3 arch/powerpc/platforms/83xx/usb.c | 46 arch/powerpc/platforms/85xx/mpc85xx_ads.c | 18 arch/powerpc/platforms/85xx/mpc85xx_cds.c |6 arch/powerpc/platforms/85xx/mpc85xx_mds.c |7 arch/powerpc/platforms/86xx/mpc8610_hpcd.c| 15 arch/powerpc/platforms/86xx/mpc86xx_hpcn.c| 14 arch/powerpc/platforms/8xx/Kconfig|9 arch/powerpc/platforms/8xx/Makefile |1 arch/powerpc/platforms/8xx/adder875.c | 118 + arch/powerpc/platforms/8xx/ep88xc.c |5 arch/powerpc/platforms/8xx/mpc86xads_setup.c |5 arch/powerpc/platforms/8xx/mpc885ads_setup.c |5 arch/powerpc/platforms/Kconfig|6 arch/powerpc/platforms/embedded6xx/Kconfig| 23 arch/powerpc/platforms/embedded6xx/Makefile |1 arch/powerpc/platforms/embedded6xx/mpc7448_hpc2.c |2 arch/powerpc/platforms/embedded6xx/storcenter.c | 192 ++ arch/powerpc/sysdev/Makefile |3 arch/powerpc/sysdev/fsl_pci.c | 150 -- arch/powerpc/sysdev/fsl_rio.c | 932 + arch/powerpc/sysdev/fsl_rio.h | 20
Re: patches for 2.6.25
On Jan 23, 2008, at 7:51 PM, Liu Yu wrote: How about this one? http://patchwork.ozlabs.org/linuxppc/patch?id=15942 I've been trying to get some feedback from the glibc guys. The code is pretty common and if the issues exists in one it exists in the other.. I'm not sure if they have solved it some other way already. - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] [POWERPC] MPC8360E-RDK: device tree, board file and defconfig
On Wed, 23 Jan 2008 23:45:07 +0300 Anton Vorontsov [EMAIL PROTECTED] wrote:
+++ b/arch/powerpc/platforms/83xx/mpc836x_rdk.c
+static int __init mpc836x_rdk_declare_of_platform_devices(void)
+{
+ const struct of_device_id mpc836x_rdk_ids[] = {
Please change this to static, __initdata and not const, thanks. These
arrays are usually defined outside a function, but that is not really a
problem.
+static void __init mpc836x_rdk_setup_arch(void)
+{
+ struct device_node *np;
!defined(CONFIG_PCI) !defined(CONFIG_QUICC_ENGINE) will produce a
warning here.
+ if (ppc_md.progress)
+ ppc_md.progress(mpc836x_rdk_setup_arch(), 0);
+
+#ifdef CONFIG_PCI
+ for_each_compatible_node(np, pci, fsl,mpc8349-pci)
+ mpc83xx_add_bridge(np);
+#endif
+
+#ifdef CONFIG_QUICC_ENGINE
+ qe_reset();
+
+ np = of_find_compatible_node(NULL, NULL, fsl,qe-pario);
+ if (!np) {
+ pr_warning(QE PIO not initialized!\n);
+ return;
You need an of_node_put(np) before the return.
--
Cheers,
Stephen Rothwell[EMAIL PROTECTED]
http://www.canb.auug.org.au/~sfr/
pgpdavOHvOtLk.pgp
Description: PGP signature
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 0/6] PS3: gelic: gelic updates for 2.6.25
On Tue, Jan 22, 2008 at 07:12:44PM -0800, Geoff Levand wrote: On 01/22/2008 04:58 PM, John W. Linville wrote: I thought Geert's had been applied, but I guess I was looking at it wrong. Is there a powerpc tree that has them? Not yet, they are now only in ps3-linux.git. I sent them out to Paul last Friday the 18th for inclusion in 2.6.25. Here is a link to the message: http://ozlabs.org/pipermail/linuxppc-dev/2008-January/050213.html Perhaps 1-6 above and the wireless patch should just be applied to that tree (if there is one) and all merged together? I think Paul will accept them if they have the Sign-off-by's of the proper network maintainers. Feel free to add: Signed-off-by: John W. Linville [EMAIL PROTECTED] (Or Acked-by if you would prefer) to the wireless bits. FWIW, the wired bits seemed OK to me as well, but I didn't look too closely... Thanks, John -- John W. Linville [EMAIL PROTECTED] ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] Fix boot problem in situations where the boot CPU is running on a memoryless node
On Wed, 23 Jan 2008, Nishanth Aravamudan wrote: Right, so it might have functioned before, but the correctness was wobbly at best... Certainly the memoryless patch series has tightened that up, but we missed these SLAB issues. I see that your patch fixed Olaf's machine, Pekka. Nice work on everyone's part tracking this stuff down. Another important result is that I found that GFP_THISNODE is actually required for proper SLAB operation and not only an optimization. Fallback can lead to very bad results. I have two customer reported instances of SLAB corruption here that can be explained now due to fallback to another node. Foreign objects enter the per cpu queue. The wrong node lock is taken during cache_flusharray(). Fields in the struct slab can become corrupted. It typically hits the list field and the inuse field. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 1/4 v4] POWERPC: Add _nmask_and_or_msr() declartion to asm-powerpc/system.h
Jon Loeliger writes: +extern void _nmask_and_or_msr(unsigned long nmask, unsigned long or_val); Hmmm, I wish someone would think of a better name for it. In fact I have tended to avoid using it, and instead done things like mtmsr((mfmsr() ~x) | y); where necessary instead. Paul. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH UCC TDM 0/3] UCC based TDM driver for QE based MPC83xx platforms
Reworked patches after incorporating comments of Andrew, Stephen and
Tabi and Kumar.
Kumar could you please consider them for linux-2.6.25.
There are three patches
[PATCH 1/3] drivers/misc : UCC TDM driver for mpc83xx platforms. This
driver is usable in VoIP iind of applications to interface with SLIC
kind of devices to exchange TDM voice samples.
The driver is right now in misc category and exposes a kind of non
standard interface to the clients.
TDM Driver Interface Details
The TDM driver right now is a misc driver with no subsystem as such.
The dts file keeps a track of the TDM devices present on the board.
Depending on them the TDM driver initializes those many driver instances
while coming up.
The driver on the upper level can plug to more than one tdm clients
depending on the availablity of TDM devices.
At every new request of the TDM client to bind with a TDM device, a free
driver instance is allocated to the client.
The interface can be described as follows.
tdm_register_client(struct tdm_client *)
This API returns a pointer to the structure tdm_client which is
of type
struct tdm_client {
u32 client_id;
u32 (*tdm_read)(u32 client_id, short chn_id, short
*pcm_buffer, short len);
u32 (*tdm_write)(u32 client_id, short chn_id, short
*pcm_buffer, short len);
wait_queue_head_t *wakeup_event;
}
It consists of:
- driver_handle: It is basically to identify the particular TDM
device/driver instance.
- tdm_read: It is a function pointer returned by the TDM driver to be
used to read TDM data from a particular TDM channel.
- tdm_write: It is a function pointer returned by the TDM driver to
be used to write TDM data to a particular TDM channel.
- wakeup_event: It is address of a wait_queue event on which the
client keeps on sleeping, and the TDM driver wakes it up periodically.
The driver is configured to wake up the client after every 10ms.
Once the TDM client gets registered to a TDM driver instance and a TDM
device, it interfaces with the driver using tdm_read, tdm_write and
wakeup_event.
Note: The TDM driver can be used by only kernel level modules. The
driver does not expose any file interface for User Applications. Can be
compared to the spi driver which interfaces with the SPI clients(kernel
mode clients) through some APIs.
This interface can be improved by writing a platform independent TDM
layer. Then all the TDM platforms can be supported below this wrapper
layer. This is planned to be done later.
[PATCH 2/3] arch/ : Platform changes
- device tree entries for UCC TDM driver for MPC8323ERDB platform.
- QE changes related to TDM , like,
1) Modified ucc_fast_init so that it can be used by fast UCC
based TDM driver. Mainly changes have been made to configure TDM clocks
and Fsyncs.
2) Modified get_brg_clk so that it can return the input frequncy
and input source of any BRG by reading the corresponding entries from
device tree.
3) Added new nodes brg and clocks in the device tree which
represent input clocks for different BRGs.
4) Modified qe_setbrg accordingly.
- new device tree entries added for clocks and brg
[PATCH 3/3] Documentation
- Modified Documentation to explain the device tree entries related to
UCC TDM driver and the new nodes added(clocks and brg)
The patch applies over a merge of galak's for-2.6.25 plus for-2.6.24
plus of_doc_update branches.
In brief the steps were
git clone
git://git.kernel.org/pub/scm/linux/kernel/git/galak/powerpc.git
powerpc-galak
git checkout -b for-2.6.25 origin/for-2.6.25 git checkout -b for-2.6.24
origin/for-2.6.24 git checkout -b of_doc_update origin/of_doc_update
git pull . for-2.6.24# merge the other two
git pull . for-2.6.25
git checkout -b tdm # clean slate for tdm rebase work
Also after applying the patches changes have to be made corresponding to
Tabi's patch qe: add function qe_clock_source.
The driver has been tested with a VoIP stack and application on
MPC8323ERDB.
With Regards
Poonam
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] UCC TDM driver for QE based MPC83xx platforms.
From: Poonam Agarwal-b10812 [EMAIL PROTECTED]
The UCC TDM driver basically multiplexes and demultiplexes data from
different channels. It can interface with for example SLIC kind of devices
to receive TDM data demultiplex it and send to upper modules. At the
transmit end it receives data for different channels multiplexes it and
sends them on the TDM channel. It internally uses TSA( Time Slot Assigner)
which does multiplexing and demultiplexing, UCC to perform SDMA between
host buffers and the TSA, CMX to connect TSA to UCC.
It can be used by a kernel module which can call tdm_register_client to
get access to a TDM device.
The driver is right now a misc driver with no subsystem as such.
There can be a platform independent TDM layer which is planned to be
done after this. TDM bus sort of thing.
The dts file keeps a track of the TDM devices present on the board.
Depending on them the TDM driver initializes those many driver instances
while coming up.
The driver on the upper level can plug to more than one tdm clients
depending on the availablity of TDM devices. At every new request of a TDM
client to bind with a TDM device, a free driver instance is allocated to
the client.
The interface can be described as follows.
tdm_register_client(struct tdm_client *)
This API returns a pointer to the structure tdm_client which is of
type
struct tdm_client {
u32 client_id;
u32 (*tdm_read)(u32 client_id, short chn_id, short
*pcm_buffer, short len);
u32 (*tdm_write)(u32 client_id, short chn_id, short
*pcm_buffer, short len);
wait_queue_head_t *wakeup_event;
}
It consists of:
- client_id: It is basically to identify the particular TDM
device/driver instance.
- tdm_read: It is a function pointer returned by the TDM driver to be
used to read TDM data from a particular TDM channel.
- tdm_write: It is a function pointer returned by the TDM driver to be
used to write TDM data to a particular TDM channel.
- wakeup_event: It is address of a wait_queue event on which the client
keeps on sleeping, and the TDM driver wakes it up periodically. The driver
is configured to
wake up the client after every 10ms.
Once the TDM client gets registered to a TDM driver instance and a TDM
device, it interfaces with the driver using tdm_read, tdm_write and
wakeup_event.
This driver will run on MPC8323E-RDB platforms.
Signed-off-by: Poonam Aggrwal [EMAIL PROTECTED]
Signed-off-by: Ashish Kalra [EMAIL PROTECTED]
Signed-off-by: Kim Phillips [EMAIL PROTECTED]
Signed-off-by: Michael Barkowski [EMAIL PROTECTED]
---
drivers/misc/Kconfig | 14 +
drivers/misc/Makefile |1 +
drivers/misc/ucc_tdm.c | 1000
drivers/misc/ucc_tdm.h | 221 +++
4 files changed, 1236 insertions(+), 0 deletions(-)
create mode 100644 drivers/misc/ucc_tdm.c
create mode 100644 drivers/misc/ucc_tdm.h
diff --git a/drivers/misc/Kconfig b/drivers/misc/Kconfig
index b5e67c0..628b14b 100644
--- a/drivers/misc/Kconfig
+++ b/drivers/misc/Kconfig
@@ -232,4 +232,18 @@ config ATMEL_SSC
If unsure, say N.
+config UCC_TDM
+ bool Freescale UCC TDM Driver
+ depends on QUICC_ENGINE UCC_FAST
+ default n
+ ---help---
+ The TDM driver is for UCC based TDM devices for example, TDM device on
+ MPC832x RDB. Select it to run PowerVoIP on MPC832x RDB board.
+ The TDM driver can interface with SLIC kind of devices to transmit
+ and receive TDM samples. The TDM driver receives Time Division
+ multiplexed samples(for different channels) from the SLIC device,
+ demutiplexes them and sends them to the upper layers. At the transmit
+ end the TDM drivers receives samples for different channels, it
+ multiplexes them and sends them to the SLIC device.
+
endif # MISC_DEVICES
diff --git a/drivers/misc/Makefile b/drivers/misc/Makefile
index 87f2685..6f0c49d 100644
--- a/drivers/misc/Makefile
+++ b/drivers/misc/Makefile
@@ -17,3 +17,4 @@ obj-$(CONFIG_SONY_LAPTOP) += sony-laptop.o
obj-$(CONFIG_THINKPAD_ACPI)+= thinkpad_acpi.o
obj-$(CONFIG_FUJITSU_LAPTOP) += fujitsu-laptop.o
obj-$(CONFIG_EEPROM_93CX6) += eeprom_93cx6.o
+obj-$(CONFIG_UCC_TDM) += ucc_tdm.o
diff --git a/drivers/misc/ucc_tdm.c b/drivers/misc/ucc_tdm.c
new file mode 100644
index 000..98e7c72
--- /dev/null
+++ b/drivers/misc/ucc_tdm.c
@@ -0,0 +1,1000 @@
+/*
+ * drivers/misc/ucc_tdm.c
+ *
+ * UCC Based Linux TDM Driver
+ * This driver is designed to support UCC based TDM for PowerPC processors.
+ * This driver can interface with SLIC device to run VOIP kind of
+ * applications.
+ *
+ * Author: Ashish Kalra Poonam Aggrwal
+ *
+ * Copyright (c) 2007 Freescale Semiconductor, Inc.
+ *
+ * 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 the
+ * Free
