Re: [PATCHv4 2/2] powerpc: implement arch_scale_smt_power for Power7
In message 11927.1267010...@neuling.org you wrote:
If there's less the group will normally be balanced and we fall out and
end up in check_asym_packing().
So what I tried doing with that loop is detect if there's a hole in the
packing before busiest. Now that I think about it, what we need to check
is if this_cpu (the removed cpu argument) is idle and less than busiest.
So something like:
static int check_asym_pacing(struct sched_domain *sd,
struct sd_lb_stats *sds,
int this_cpu, unsigned long *imbalance)
{
int busiest_cpu;
if (!(sd-flags SD_ASYM_PACKING))
return 0;
if (!sds-busiest)
return 0;
busiest_cpu = group_first_cpu(sds-busiest);
if (cpu_rq(this_cpu)-nr_running || this_cpu busiest_cpu)
return 0;
*imbalance = (sds-max_load * sds-busiest-cpu_power) /
SCHED_LOAD_SCALE;
return 1;
}
Does that make sense?
I think so.
I'm seeing check_asym_packing do the right thing with the simple SMT2
with 1 process case. It marks cpu0 as imbalanced when cpu0 is idle and
cpu1 is busy.
Unfortunately the process doesn't seem to be get migrated down though.
Do we need to give *imbalance a higher value?
So with ego help, I traced this down a bit more.
In my simple test case (SMT2, t0 idle, t1 active) if f_b_g() hits our
new case in check_asym_packing(), load_balance then runs f_b_q().
f_b_q() has this:
if (capacity rq-nr_running == 1 wl imbalance)
continue;
when check_asym_packing() hits, wl = 1783 and imbalance = 1024, so we
continue and busiest remains NULL.
load_balance then does goto out_balanced and it doesn't attempt to
move the task.
Based on this and on egos suggestion I pulled in Suresh Siddha patch
from: http://lkml.org/lkml/2010/2/12/352. This fixes the problem. The
process is moved down to t0.
I've only tested SMT2 so far.
I'm finding this SMT2 result to be unreliable. Sometimes it doesn't work
for the simple 1 process case. It seems to change boot to boot.
Sometimes it works as expected with t0 busy and t1 idle, but other times
it's the other way around.
When it doesn't work, check_asym_packing() is still marking processes to
be pulled down but only gets run about 1 in every 4 calls to
load_balance().
For 2 of the other calls to load_balance, idle is CPU_NEWLY_IDLE and
hence check_asym_packing() doesn't get called. This results in
sd-nr_balance_failed being reset. When load_balance is next called and
check_asym_packing() hits, need_active_balance() returns 0 as
sd-nr_balance_failed is too small. This means the migration thread on
t1 is not woken and the process remains there.
So why does thread0 change from NEWLY_IDLE to IDLE and visa versa, when
there is nothing running on it? Is this expected?
This is with next-20100225 which pulled in Ingos tip at
407b4844f2af416cd8c9edd7c44d1545c93a4938 (from 24/2/2010)
Mikey
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [net-next-2.6 PATCH v3 0/3] Support for MPC512x FEC
From: Anatolij Gustschin ag...@denx.de Date: Fri, 26 Feb 2010 23:00:46 +0100 These patches attempt to provide support for the Freescale MPC512x FEC in the fs_enet driver. The first cleanup patch replaces printk by dev_xxx. The second and third attemt to support MPC5121 FEC in the FEC driver. Applied, for real this time! :-) Thanks. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/4] 8xx: Optimze TLB Miss handlers
Scott Wood scottw...@freescale.com wrote on 2010/02/26 20:50:18: On Fri, Feb 26, 2010 at 09:29:40AM +0100, Joakim Tjernlund wrote: This removes a couple of insn's from the TLB Miss handlers whithout changing functionality. --- Did a quick test of the patchset, seems to work OK (without CONFIG_SWAP or CONFIG_MODULES). Didn't try with CONFIG_8xx_CPU6. Cool, thanks a lot! Not sure anyone is using 2.6 with CPU6 errata. Seems it was fixed years ago. Should I resend the whole series with SOB line or just include it here? Signed-off-by: Joakim Tjernlund joakim.tjernl...@transmode.se ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/4] 8xx: Optimze TLB Miss handlers
Kumar Gala ga...@kernel.crashing.org wrote on 2010/02/26 21:10:31: On Feb 26, 2010, at 2:29 AM, Joakim Tjernlund wrote: li r11, 0x00f0 - rlwimi r10, r11, 0, 24, 28 /* Set 24-27, clear 28 */ + rlwimi r10, r11, 0, 0x07f8 /* Set 24-27, clear 21-23,28 */ DO_8xx_CPU6(0x2d80, r3) mtspr SPRN_MI_RPN, r10 /* Update TLB entry */ Cool, didn't know 'as' supported this notation. Yeah, it was Scott who gave me the clue and from what I can tell it is an official syntax form. I find much easier to understand. Jocke ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] powerpc: Fix SMP build with disabled CPU hotplugging.
Compiling 2.6.33 with SMP enabled and HOTPLUG_CPU disabled gives me the
following link errors:
LD init/built-in.o
LD .tmp_vmlinux1
arch/powerpc/platforms/built-in.o: In function `.smp_xics_setup_cpu':
smp.c:(.devinit.text+0x88): undefined reference to `.set_cpu_current_state'
smp.c:(.devinit.text+0x94): undefined reference to `.set_default_offline_state'
arch/powerpc/platforms/built-in.o: In function `.smp_pSeries_kick_cpu':
smp.c:(.devinit.text+0x13c): undefined reference to
`.set_preferred_offline_state'
smp.c:(.devinit.text+0x148): undefined reference to `.get_cpu_current_state'
smp.c:(.devinit.text+0x1a8): undefined reference to `.get_cpu_current_state'
make: *** [.tmp_vmlinux1] Error 1
The following change fixes that for me and seems to work as expected.
Signed-off-by: Adam Lackorzynski a...@os.inf.tu-dresden.de
---
arch/powerpc/platforms/pseries/offline_states.h | 22 +-
1 files changed, 21 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/platforms/pseries/offline_states.h
b/arch/powerpc/platforms/pseries/offline_states.h
index 22574e0..202d869 100644
--- a/arch/powerpc/platforms/pseries/offline_states.h
+++ b/arch/powerpc/platforms/pseries/offline_states.h
@@ -9,10 +9,30 @@ enum cpu_state_vals {
CPU_MAX_OFFLINE_STATES
};
+#ifdef CONFIG_HOTPLUG_CPU
extern enum cpu_state_vals get_cpu_current_state(int cpu);
extern void set_cpu_current_state(int cpu, enum cpu_state_vals state);
-extern enum cpu_state_vals get_preferred_offline_state(int cpu);
extern void set_preferred_offline_state(int cpu, enum cpu_state_vals state);
extern void set_default_offline_state(int cpu);
+#else
+static inline enum cpu_state_vals get_cpu_current_state(int cpu)
+{
+ return CPU_STATE_ONLINE;
+}
+
+static inline void set_cpu_current_state(int cpu, enum cpu_state_vals state)
+{
+}
+
+static inline void set_preferred_offline_state(int cpu, enum cpu_state_vals
state)
+{
+}
+
+static inline void set_default_offline_state(int cpu)
+{
+}
+#endif
+
+extern enum cpu_state_vals get_preferred_offline_state(int cpu);
extern int start_secondary(void);
#endif
--
1.5.6.5
Adam
--
Adam a...@os.inf.tu-dresden.de
Lackorzynski http://os.inf.tu-dresden.de/~adam/
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 0/3] Rework MPC5121 DIU support (for 2.6.34)
This patch series rework DIU support patch submitted previously with the patch series for updating MPC5121 support in mainline. It doesn't add new panel timing data to the framebuffer driver anymore. Instead we now allow encoding this data in the device tree. First two patches add this support. The third patch for DIU support is rebased, but still depends on patches for adding MPC5121 USB support (because it touches shared platform code). It is intended for inclusion in 2.6.34, since without DIU support patch framebuffer doesn't work on mpc5121. Anatolij Gustschin (3): video: add support for getting video mode from device tree fbdev: fsl-diu-fb.c: allow setting panel video mode from DT powerpc/mpc5121: shared DIU framebuffer support arch/powerpc/platforms/512x/mpc5121_ads.c |7 + arch/powerpc/platforms/512x/mpc5121_generic.c | 13 ++ arch/powerpc/platforms/512x/mpc512x.h |3 + arch/powerpc/platforms/512x/mpc512x_shared.c | 282 + arch/powerpc/sysdev/fsl_soc.h |1 + drivers/video/Kconfig |6 + drivers/video/Makefile|1 + drivers/video/fsl-diu-fb.c| 88 +--- drivers/video/fsl-diu-fb.h| 223 --- drivers/video/ofmode.c| 95 + drivers/video/ofmode.h|6 + include/linux/fsl-diu-fb.h| 223 +++ 12 files changed, 693 insertions(+), 255 deletions(-) delete mode 100644 drivers/video/fsl-diu-fb.h create mode 100644 drivers/video/ofmode.c create mode 100644 drivers/video/ofmode.h create mode 100644 include/linux/fsl-diu-fb.h ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 1/3] video: add support for getting video mode from device tree
Framebuffer drivers may want to get panel timing info
from the device tree. This patch adds appropriate support.
Subsequent patch for FSL DIU frame buffer driver makes use
of this functionality.
Signed-off-by: Anatolij Gustschin ag...@denx.de
---
drivers/video/Kconfig |5 +++
drivers/video/Makefile |1 +
drivers/video/ofmode.c | 95
drivers/video/ofmode.h |6 +++
4 files changed, 107 insertions(+), 0 deletions(-)
create mode 100644 drivers/video/ofmode.c
create mode 100644 drivers/video/ofmode.h
diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig
index 5a5c303..dc1beb0 100644
--- a/drivers/video/Kconfig
+++ b/drivers/video/Kconfig
@@ -203,6 +203,11 @@ config FB_MACMODES
depends on FB
default n
+config FB_OF_MODE
+ tristate
+ depends on FB OF
+ default n
+
config FB_BACKLIGHT
bool
depends on FB
diff --git a/drivers/video/Makefile b/drivers/video/Makefile
index 4ecb30c..c4a912b 100644
--- a/drivers/video/Makefile
+++ b/drivers/video/Makefile
@@ -26,6 +26,7 @@ obj-$(CONFIG_FB_SVGALIB) += svgalib.o
obj-$(CONFIG_FB_MACMODES) += macmodes.o
obj-$(CONFIG_FB_DDC) += fb_ddc.o
obj-$(CONFIG_FB_DEFERRED_IO) += fb_defio.o
+obj-$(CONFIG_FB_OF_MODE) += ofmode.o
# Hardware specific drivers go first
obj-$(CONFIG_FB_AMIGA)+= amifb.o c2p_planar.o
diff --git a/drivers/video/ofmode.c b/drivers/video/ofmode.c
new file mode 100644
index 000..78caad1
--- /dev/null
+++ b/drivers/video/ofmode.c
@@ -0,0 +1,95 @@
+/*
+ * Get video mode settings from Flattened Device Tree.
+ *
+ * Copyright (C) 2010 DENX Software Engineering.
+ * Anatolij Gustschin ag...@denx.de
+ *
+ * This file is subject to the terms and conditions of the GNU General
+ * Public License version 2. See the file COPYING in the main directory
+ * of this archive for more details.
+ */
+
+#include linux/fb.h
+#include linux/of.h
+
+int __devinit of_get_video_mode(struct device_node *np,
+ struct fb_info *info)
+{
+ struct fb_videomode dt_mode;
+ const u32 *prop;
+ unsigned int len;
+
+ if (!np || !info)
+ return -EINVAL;
+
+ prop = of_get_property(np, width, len);
+ if (!prop || len != sizeof(u32))
+ goto err;
+ dt_mode.xres = *prop;
+
+ prop = of_get_property(np, height, len);
+ if (!prop || len != sizeof(u32))
+ goto err;
+ dt_mode.yres = *prop;
+
+ prop = of_get_property(np, depth, len);
+ if (!prop || len != sizeof(u32))
+ goto err;
+ info-var.bits_per_pixel = *prop;
+
+ prop = of_get_property(np, linebytes, len);
+ if (!prop || len != sizeof(u32))
+ goto err;
+ info-fix.line_length = *prop;
+
+ prop = of_get_property(np, refresh, len);
+ if (prop len == sizeof(u32))
+ dt_mode.refresh = *prop; /* optional */
+
+ prop = of_get_property(np, pixclock, len);
+ if (!prop || len != sizeof(u32))
+ goto err;
+ dt_mode.pixclock = *prop;
+
+ prop = of_get_property(np, left_margin, len);
+ if (!prop || len != sizeof(u32))
+ goto err;
+ dt_mode.left_margin = *prop;
+
+ prop = of_get_property(np, right_margin, len);
+ if (!prop || len != sizeof(u32))
+ goto err;
+ dt_mode.right_margin = *prop;
+
+ prop = of_get_property(np, upper_margin, len);
+ if (!prop || len != sizeof(u32))
+ goto err;
+ dt_mode.upper_margin = *prop;
+
+ prop = of_get_property(np, lower_margin, len);
+ if (!prop || len != sizeof(u32))
+ goto err;
+ dt_mode.lower_margin = *prop;
+
+ prop = of_get_property(np, hsync_len, len);
+ if (!prop || len != sizeof(u32))
+ goto err;
+ dt_mode.hsync_len = *prop;
+
+ prop = of_get_property(np, vsync_len, len);
+ if (!prop || len != sizeof(u32))
+ goto err;
+ dt_mode.vsync_len = *prop;
+
+ prop = of_get_property(np, sync, len);
+ if (!prop || len != sizeof(u32))
+ goto err;
+ dt_mode.sync = *prop;
+
+ fb_videomode_to_var(info-var, dt_mode);
+
+ return 0;
+err:
+ pr_err(%s: Can't find expected mode entry\n, np-full_name);
+ return -EINVAL;
+}
diff --git a/drivers/video/ofmode.h b/drivers/video/ofmode.h
new file mode 100644
index 000..9a13bec
--- /dev/null
+++ b/drivers/video/ofmode.h
@@ -0,0 +1,6 @@
+#ifndef _OFMODE_H
+#define _OFMODE_H
+
+extern int __devinit of_get_video_mode(struct device_node *np,
+ struct fb_info *info);
+#endif
--
1.6.3.3
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 2/3] fbdev: fsl-diu-fb.c: allow setting panel video mode from DT
Add support for specifying display panel data in the device
tree. If no panel data is provided in the device tree, default
video mode will be used as usual.
Signed-off-by: Anatolij Gustschin ag...@denx.de
---
drivers/video/Kconfig |1 +
drivers/video/fsl-diu-fb.c | 63 +---
2 files changed, 37 insertions(+), 27 deletions(-)
diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig
index dc1beb0..c805ecd 100644
--- a/drivers/video/Kconfig
+++ b/drivers/video/Kconfig
@@ -1850,6 +1850,7 @@ config FB_FSL_DIU
select FB_CFB_COPYAREA
select FB_CFB_IMAGEBLIT
select PPC_LIB_RHEAP
+ select FB_OF_MODE
---help---
Framebuffer driver for the Freescale SoC DIU
diff --git a/drivers/video/fsl-diu-fb.c b/drivers/video/fsl-diu-fb.c
index 4637bcb..19ca1da 100644
--- a/drivers/video/fsl-diu-fb.c
+++ b/drivers/video/fsl-diu-fb.c
@@ -36,6 +36,8 @@
#include sysdev/fsl_soc.h
#include fsl-diu-fb.h
+#include ofmode.h
+
/*
* These parameters give default parameters
* for video output 1024x768,
@@ -1168,7 +1170,7 @@ static int init_fbinfo(struct fb_info *info)
return 0;
}
-static int __devinit install_fb(struct fb_info *info)
+static int __devinit install_fb(struct device_node *np, struct fb_info *info)
{
int rc;
struct mfb_info *mfbi = info-par;
@@ -1177,33 +1179,40 @@ static int __devinit install_fb(struct fb_info *info)
if (init_fbinfo(info))
return -EINVAL;
- if (mfbi-index == 0) /* plane 0 */
- aoi_mode = fb_mode;
- else
+ if (mfbi-index == 0) { /* plane 0 */
+ /* use default mode for plane0 if there is no mode in DTB */
+ if (of_get_video_mode(np, info) 0)
+ aoi_mode = fb_mode;
+ else
+ aoi_mode = NULL;
+ } else
aoi_mode = init_aoi_mode;
- pr_debug(mode used = %s\n, aoi_mode);
- rc = fb_find_mode(info-var, info, aoi_mode, fsl_diu_mode_db,
-ARRAY_SIZE(fsl_diu_mode_db), fsl_diu_default_mode, default_bpp);
- switch (rc) {
- case 1:
- pr_debug(using mode specified in @mode\n);
- break;
- case 2:
- pr_debug(using mode specified in @mode
- with ignored refresh rate\n);
- break;
- case 3:
- pr_debug(using mode default mode\n);
- break;
- case 4:
- pr_debug(using mode from list\n);
- break;
- default:
- pr_debug(rc = %d\n, rc);
- pr_debug(failed to find mode\n);
- return -EINVAL;
- break;
+ if (aoi_mode) {
+ pr_debug(mode used = %s\n, aoi_mode);
+ rc = fb_find_mode(info-var, info, aoi_mode, fsl_diu_mode_db,
+ ARRAY_SIZE(fsl_diu_mode_db),
+ fsl_diu_default_mode, default_bpp);
+ switch (rc) {
+ case 1:
+ pr_debug(using mode specified in @mode\n);
+ break;
+ case 2:
+ pr_debug(using mode specified in @mode
+ with ignored refresh rate\n);
+ break;
+ case 3:
+ pr_debug(using mode default mode\n);
+ break;
+ case 4:
+ pr_debug(using mode from list\n);
+ break;
+ default:
+ pr_debug(rc = %d\n, rc);
+ pr_debug(failed to find mode\n);
+ return -EINVAL;
+ break;
+ }
}
pr_debug(xres_virtual %d\n, info-var.xres_virtual);
@@ -1521,7 +1530,7 @@ static int __devinit fsl_diu_probe(struct of_device
*ofdev,
mfbi-ad = (struct diu_ad *)((u32)pool.ad.vaddr
+ pool.ad.offset) + i;
mfbi-ad-paddr = pool.ad.paddr + i * sizeof(struct diu_ad);
- ret = install_fb(machine_data-fsl_diu_info[i]);
+ ret = install_fb(np, machine_data-fsl_diu_info[i]);
if (ret) {
dev_err(ofdev-dev,
Failed to register framebuffer %d\n,
--
1.6.3.3
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 3/3] powerpc/mpc5121: shared DIU framebuffer support
MPC5121 DIU configuration/setup as initialized by the boot
loader currently will get lost while booting Linux. As a
result displaying the boot splash is not possible through
the boot process.
To prevent this we reserve configured DIU frame buffer
address range while booting and preserve AOI descriptor
and gamma table so that DIU continues displaying through
the whole boot process. On first open from user space
DIU frame buffer driver releases the reserved frame
buffer area and continues to operate as usual.
The patch also moves drivers/video/fsl-diu-fb.h file to
include/linux as we use some DIU structures in platform
code.
'diu_ops' callbacks in platform code borrowed from John's
DIU code.
Signed-off-by: John Rigby jri...@gmail.com
Signed-off-by: Anatolij Gustschin ag...@denx.de
Cc: Grant Likely grant.lik...@secretlab.ca
---
arch/powerpc/platforms/512x/mpc5121_ads.c |7 +
arch/powerpc/platforms/512x/mpc5121_generic.c | 13 ++
arch/powerpc/platforms/512x/mpc512x.h |3 +
arch/powerpc/platforms/512x/mpc512x_shared.c | 282 +
arch/powerpc/sysdev/fsl_soc.h |1 +
drivers/video/fsl-diu-fb.c| 25 ++-
drivers/video/fsl-diu-fb.h| 223 ---
include/linux/fsl-diu-fb.h| 223 +++
8 files changed, 549 insertions(+), 228 deletions(-)
delete mode 100644 drivers/video/fsl-diu-fb.h
create mode 100644 include/linux/fsl-diu-fb.h
diff --git a/arch/powerpc/platforms/512x/mpc5121_ads.c
b/arch/powerpc/platforms/512x/mpc5121_ads.c
index ee6ae12..aa4d5a8 100644
--- a/arch/powerpc/platforms/512x/mpc5121_ads.c
+++ b/arch/powerpc/platforms/512x/mpc5121_ads.c
@@ -42,6 +42,7 @@ static void __init mpc5121_ads_setup_arch(void)
for_each_compatible_node(np, pci, fsl,mpc5121-pci)
mpc83xx_add_bridge(np);
#endif
+ mpc512x_setup_diu();
}
static void __init mpc5121_ads_init_IRQ(void)
@@ -60,11 +61,17 @@ static int __init mpc5121_ads_probe(void)
return of_flat_dt_is_compatible(root, fsl,mpc5121ads);
}
+void __init mpc5121_ads_init_early(void)
+{
+ mpc512x_init_diu();
+}
+
define_machine(mpc5121_ads) {
.name = MPC5121 ADS,
.probe = mpc5121_ads_probe,
.setup_arch = mpc5121_ads_setup_arch,
.init = mpc512x_init,
+ .init_early = mpc5121_ads_init_early,
.init_IRQ = mpc5121_ads_init_IRQ,
.get_irq= ipic_get_irq,
.calibrate_decr = generic_calibrate_decr,
diff --git a/arch/powerpc/platforms/512x/mpc5121_generic.c
b/arch/powerpc/platforms/512x/mpc5121_generic.c
index a6c0e3a..3aaa281 100644
--- a/arch/powerpc/platforms/512x/mpc5121_generic.c
+++ b/arch/powerpc/platforms/512x/mpc5121_generic.c
@@ -28,6 +28,7 @@
*/
static char *board[] __initdata = {
prt,prtlvt,
+ ifm,pdm360ng,
NULL
};
@@ -48,10 +49,22 @@ static int __init mpc5121_generic_probe(void)
return board[i] != NULL;
}
+void __init mpc512x_generic_init_early(void)
+{
+ mpc512x_init_diu();
+}
+
+void __init mpc512x_generic_setup_arch(void)
+{
+ mpc512x_setup_diu();
+}
+
define_machine(mpc5121_generic) {
.name = MPC5121 generic,
.probe = mpc5121_generic_probe,
.init = mpc512x_init,
+ .init_early = mpc512x_generic_init_early,
+ .setup_arch = mpc512x_generic_setup_arch,
.init_IRQ = mpc512x_init_IRQ,
.get_irq= ipic_get_irq,
.calibrate_decr = generic_calibrate_decr,
diff --git a/arch/powerpc/platforms/512x/mpc512x.h
b/arch/powerpc/platforms/512x/mpc512x.h
index d72b2c7..1cfe9d5 100644
--- a/arch/powerpc/platforms/512x/mpc512x.h
+++ b/arch/powerpc/platforms/512x/mpc512x.h
@@ -17,4 +17,7 @@ extern int __init mpc5121_clk_init(void);
void __init mpc512x_declare_of_platform_devices(void);
extern void mpc512x_restart(char *cmd);
extern void __init mpc5121_usb_init(void);
+extern void __init mpc512x_init_diu(void);
+extern void __init mpc512x_setup_diu(void);
+extern struct fsl_diu_shared_fb diu_shared_fb;
#endif /* __MPC512X_H__ */
diff --git a/arch/powerpc/platforms/512x/mpc512x_shared.c
b/arch/powerpc/platforms/512x/mpc512x_shared.c
index fbdf65f..a8c50a6 100644
--- a/arch/powerpc/platforms/512x/mpc512x_shared.c
+++ b/arch/powerpc/platforms/512x/mpc512x_shared.c
@@ -16,7 +16,11 @@
#include linux/io.h
#include linux/irq.h
#include linux/of_platform.h
+#include linux/fsl-diu-fb.h
+#include linux/bootmem.h
+#include sysdev/fsl_soc.h
+#include asm/cacheflush.h
#include asm/machdep.h
#include asm/ipic.h
#include asm/prom.h
@@ -53,6 +57,284 @@ void mpc512x_restart(char *cmd)
;
}
+struct fsl_diu_shared_fb {
+ chargamma[0x300];
Re: [PATCH v3 09/11] powerpc/mpc5121: shared DIU framebuffer support
On Tue, 16 Feb 2010 11:06:22 -0700
Grant Likely grant.lik...@secretlab.ca wrote:
[...]
diff --git a/drivers/video/fsl-diu-fb.c b/drivers/video/fsl-diu-fb.c
index 72d68b3..29c7f31 100644
--- a/drivers/video/fsl-diu-fb.c
+++ b/drivers/video/fsl-diu-fb.c
@@ -34,7 +34,7 @@
#include linux/of_platform.h
#include sysdev/fsl_soc.h
-#include fsl-diu-fb.h
+#include linux/fsl-diu-fb.h
/*
* These parameters give default parameters
@@ -178,6 +178,21 @@ static struct fb_videomode __devinitdata
fsl_diu_mode_db[] = {
.sync = FB_SYNC_COMP_HIGH_ACT |
FB_SYNC_VERT_HIGH_ACT,
.vmode = FB_VMODE_NONINTERLACED
},
+ {
+ .name = 800x480-60,
+ .refresh = 60,
+ .xres = 800,
+ .yres = 480,
+ .pixclock = 31250,
+ .left_margin = 86,
+ .right_margin = 42,
+ .upper_margin = 33,
+ .lower_margin = 10,
+ .hsync_len = 128,
+ .vsync_len = 2,
+ .sync = FB_SYNC_COMP_HIGH_ACT |
FB_SYNC_VERT_HIGH_ACT,
+ .vmode = FB_VMODE_NONINTERLACED
+ },
};
This hunk bothers me. It looks like the type of data that belongs
either in some common shared .c file, or encoded into the device tree.
It seems to be data about the display panel, instead of data about
the framebuffer driver. I know that the driver already uses this
pattern, but before I merge this patch and further rely on that
pattern, I think it is worth discussing.
In the updated DIU patches I don't add panel timing data to the
framebuffer driver. It is encoded in the device tree now. If this
is acceptable, I'll send another patch adding the documentation
for added bindings.
Thanks,
Anatolij
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
PCIe switch driver in Linux 2.6.29
Hi,
I am new to this mail list and this is my first post, I apologize if I break
some rules.
Description of the problem:
We incorporated Freescale MPC8548E CPU, PLX PEX8648 PCIe switch and Altera FPGA
into our solution.
FPGA has one prefetchable 64-bit BAR 0 and 32-bit non-prefetchable Bar2.It was
recognized successfully,as well as the PCIe switch.
But there are resources collisions on the upstream bridge and the downstream
bridge connected to FPGA.
the startup log, as well the device tree, is shown below.
My question is:
am I missing something in the device tree that standa for the PCIe switch?
Do I need to code in the Linux kernel to fix this problem?
startup log
===
pci :01:00.0: device not available because of BAR 0 [0xb000-0xb001]
collisions
pci :01:00.0: device not available because of BAR 8 [0xb000-0xb00f]
collisions
pci :01:00.0: device not available because of BAR 9 [0xa000-0xa0ff]
collisions
pci :02:08.0: device not available because of BAR 8 [0xb000-0xb00f]
collisions
pci :02:08.0: device not available because of BAR 9 [0xa000-0xa0ff]
collisions
device tree regarding PCIe
pci2: p...@e000a000 {
cell-index = 2;
interrupt-map-mask = 0xf800 0x0 0x0 0x7;
interrupt-map =
/* IDSEL 0x0 (PEX) */
0 0x0 0x0 0x1 mpic 0x0 0x1
0 0x0 0x0 0x2 mpic 0x1 0x1
0 0x0 0x0 0x3 mpic 0x2 0x1
0 0x0 0x0 0x4 mpic 0x3 0x1;
interrupt-parent = mpic;
interrupts = 26 2;
bus-range = 0 255;
ranges = 0x200 0x0 0x1000 0xb000 0x0 0x1000
0x4300 0x0 0x0 0xa000 0x0 0x1000
0x100 0x0 0x0 0xe300 0x0 0x10;
//ranges = empty;
clock-frequency = ;
#interrupt-cells = 1;
#size-cells = 2;
#address-cells = 3;
reg = 0xe000a000 0x1000;
compatible = fsl,mpc8548-pcie;
device_type = pci;
p...@0 {
reg = 0x0 0x0 0x0 0x0 0x0;
#size-cells = 2;
#address-cells = 3;
device_type = pci;
//ranges = empty;
ranges = 0x200 0x0 0x1000
0x2000 0x0 0x0
0x0 0x1000
0x4300 0x0 0xa000
0x4300 0x0 0xa000
0x0 0x1000
0x100 0x0 0x0
0x100 0x0 0x0
0x0 0x10;
};
};
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Proposal to move PCI out of arch/powerpc and into drivers/of
On Fri, 2010-02-26 at 16:07 -0700, John Linn wrote: Hi all, We are in the process of putting PCI/PCIe into the microblaze architecture. In order to not duplicate/fork the PCI code in Powerpc, we're proposing to move the PCI code from arch/powerpc into drivers/of such that it would be common code for Powerpc and MicroBlaze. This would be the 1st part of a refactoring that would occur with the PCI code. Ben H., would you mind if that happened (move arch/powerpc/kernel/pci* to drivers/of/*)? I don't think we should move the whole thing. I know Grant plans to move parts of it though. There's quite a few things in there that are still quite powerpc specific (and even different between ppc32 and ppc64). I wouldn't mind in the long run if we could make some of powerpc's PCI implementation bits more generic, such as struct pci_controller, and the MMIO/PIO remapping mechanisms, since many archs do more or less the same thing and all in subtely different ways. But that would have to go to drivers/pci. Then there's the whole deal with matching OF nodes with PCI devices. A lot of that is still different even between ppc32 and ppc64. I don't think any of that is ready to be moved to drivers/of, it's not generic enough by far. Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Proposal to move PCI out of arch/powerpc and into drivers/of
On Fri, 2010-02-26 at 15:44 -0800, Jesse Barnes wrote: Dave and Ben have been talking about this for awhile; seems like a good excuse to do it. IIRC they had even thought about just dumping the code directly into drivers/pci so that API updates won't get missed... Depends which part. Not -all- of our PCI code as John seems to want. The bits that generate PCI devices from the device-tree, for sure, though again, even there, there are quite a few dependencies on constructs and data structures that are powerpc specific, or even ppc64 specific in some cases, and that would have to be cleaned up and/or abstracted first. Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 44/66] arch/powerpc/sysdev/cpm2_pic.h: Checkpatch cleanup
arch/powerpc/sysdev/cpm2_pic.h:6: ERROR: (foo*) should be (foo *) Signed-off-by: Andrea Gelmini andrea.gelm...@gelma.net --- arch/powerpc/sysdev/cpm2_pic.h |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/arch/powerpc/sysdev/cpm2_pic.h b/arch/powerpc/sysdev/cpm2_pic.h index 30e5828..2c5f70c 100644 --- a/arch/powerpc/sysdev/cpm2_pic.h +++ b/arch/powerpc/sysdev/cpm2_pic.h @@ -3,6 +3,6 @@ extern unsigned int cpm2_get_irq(void); -extern void cpm2_pic_init(struct device_node*); +extern void cpm2_pic_init(struct device_node *); #endif /* _PPC_KERNEL_CPM2_H */ -- 1.7.0.90.g251a4 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/3] video: add support for getting video mode from device tree
Hi Anatolij,
[added cc: to devicetree-disc...@lists.ozlabs.org]
On Sat, Feb 27, 2010 at 2:58 PM, Anatolij Gustschin ag...@denx.de wrote:
Framebuffer drivers may want to get panel timing info
from the device tree. This patch adds appropriate support.
Subsequent patch for FSL DIU frame buffer driver makes use
of this functionality.
I think this is moving in the right direction, but there needs to
debate review over the binding before committing to anything.
Please write a patch that documents the new binding in
Documentation/powerpc/dts-bindings. All new bindings should be
documented and reviewed on devicetree-discuss before merging any
drivers that use them into mainline.
From what I can tell by reading your code, I suspect that the binding
you've designed will solve your immediate problem, but won't be able
to handle anything slightly more complex, but it also looks like the
binding has been designed to be generic, usable by any display device.
First off, I did a tiny amount of research, and I didn't find any
existing OpenFirmware bindings for describing video displays.
Otherwise, I'd suggest considering that.
From the little bit that I know, it seems that for most video devices
(ie. PCs) the video card discovers the capabilities of the screen by
reading the monitor's EDID data. However, in your particular case
embedded case, a fixed flat panel is attached, and there isn't any
EDID data provided. Therefore, you need an alternate method of
describing the display capabilities. Rather than designing something
entirely new, you may want to consider using the EDID data format
directly; or at least cover the same things that EDID describes. The
downside to using EDID directly is that it is a packed binary format
that isn't parseable by mere mortals; but the data contained in it
seems about right. The upside is the kernel already knows what to do
with EDID data.
Otherwise you risk designing something that won't be useful for
anything much outside of your own use case. For example, the binding
I see from the code cannot handle a display with multiple output
modes.
Also, since you're now in the realm of describing a video display,
which is separate from the display controller, you should consider
describing the display in a separate device tree node. Maybe
something like this...
video {
compatible = fsl,mpc5121-diu;
display {
compatible = vendor,model;
edid = [edid-data];
};
};
Cheers,
g.
Signed-off-by: Anatolij Gustschin ag...@denx.de
---
drivers/video/Kconfig | 5 +++
drivers/video/Makefile | 1 +
drivers/video/ofmode.c | 95
drivers/video/ofmode.h | 6 +++
4 files changed, 107 insertions(+), 0 deletions(-)
create mode 100644 drivers/video/ofmode.c
create mode 100644 drivers/video/ofmode.h
diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig
index 5a5c303..dc1beb0 100644
--- a/drivers/video/Kconfig
+++ b/drivers/video/Kconfig
@@ -203,6 +203,11 @@ config FB_MACMODES
depends on FB
default n
+config FB_OF_MODE
+ tristate
+ depends on FB OF
+ default n
+
config FB_BACKLIGHT
bool
depends on FB
diff --git a/drivers/video/Makefile b/drivers/video/Makefile
index 4ecb30c..c4a912b 100644
--- a/drivers/video/Makefile
+++ b/drivers/video/Makefile
@@ -26,6 +26,7 @@ obj-$(CONFIG_FB_SVGALIB) += svgalib.o
obj-$(CONFIG_FB_MACMODES) += macmodes.o
obj-$(CONFIG_FB_DDC) += fb_ddc.o
obj-$(CONFIG_FB_DEFERRED_IO) += fb_defio.o
+obj-$(CONFIG_FB_OF_MODE) += ofmode.o
# Hardware specific drivers go first
obj-$(CONFIG_FB_AMIGA) += amifb.o c2p_planar.o
diff --git a/drivers/video/ofmode.c b/drivers/video/ofmode.c
new file mode 100644
index 000..78caad1
--- /dev/null
+++ b/drivers/video/ofmode.c
@@ -0,0 +1,95 @@
+/*
+ * Get video mode settings from Flattened Device Tree.
+ *
+ * Copyright (C) 2010 DENX Software Engineering.
+ * Anatolij Gustschin ag...@denx.de
+ *
+ * This file is subject to the terms and conditions of the GNU General
+ * Public License version 2. See the file COPYING in the main directory
+ * of this archive for more details.
+ */
+
+#include linux/fb.h
+#include linux/of.h
+
+int __devinit of_get_video_mode(struct device_node *np,
+ struct fb_info *info)
+{
+ struct fb_videomode dt_mode;
+ const u32 *prop;
+ unsigned int len;
+
+ if (!np || !info)
+ return -EINVAL;
+
+ prop = of_get_property(np, width, len);
+ if (!prop || len != sizeof(u32))
+ goto err;
+ dt_mode.xres = *prop;
+
+ prop = of_get_property(np, height, len);
+ if (!prop || len != sizeof(u32))
+ goto err;
+ dt_mode.yres = *prop;
+
+ prop = of_get_property(np, depth, len);
+ if (!prop || len !=
Re: [PATCH 3/3] powerpc/mpc5121: shared DIU framebuffer support
On Sat, Feb 27, 2010 at 2:58 PM, Anatolij Gustschin ag...@denx.de wrote:
MPC5121 DIU configuration/setup as initialized by the boot
loader currently will get lost while booting Linux. As a
result displaying the boot splash is not possible through
the boot process.
To prevent this we reserve configured DIU frame buffer
address range while booting and preserve AOI descriptor
and gamma table so that DIU continues displaying through
the whole boot process. On first open from user space
DIU frame buffer driver releases the reserved frame
buffer area and continues to operate as usual.
The patch also moves drivers/video/fsl-diu-fb.h file to
include/linux as we use some DIU structures in platform
code.
'diu_ops' callbacks in platform code borrowed from John's
DIU code.
Signed-off-by: John Rigby jri...@gmail.com
Signed-off-by: Anatolij Gustschin ag...@denx.de
Cc: Grant Likely grant.lik...@secretlab.ca
On quick glance this patch seems mostly okay, but this patch should
probably be broken up a bit to simplify review and dissociate
unrelated changes. For example, the move of fsl-diu-fb.h is a
discrete change that should be split off. Some more comments
below
---
arch/powerpc/platforms/512x/mpc5121_ads.c | 7 +
arch/powerpc/platforms/512x/mpc5121_generic.c | 13 ++
arch/powerpc/platforms/512x/mpc512x.h | 3 +
arch/powerpc/platforms/512x/mpc512x_shared.c | 282
+
arch/powerpc/sysdev/fsl_soc.h | 1 +
drivers/video/fsl-diu-fb.c | 25 ++-
drivers/video/fsl-diu-fb.h | 223 ---
include/linux/fsl-diu-fb.h | 223 +++
8 files changed, 549 insertions(+), 228 deletions(-)
delete mode 100644 drivers/video/fsl-diu-fb.h
create mode 100644 include/linux/fsl-diu-fb.h
diff --git a/arch/powerpc/platforms/512x/mpc5121_ads.c
b/arch/powerpc/platforms/512x/mpc5121_ads.c
index ee6ae12..aa4d5a8 100644
--- a/arch/powerpc/platforms/512x/mpc5121_ads.c
+++ b/arch/powerpc/platforms/512x/mpc5121_ads.c
@@ -42,6 +42,7 @@ static void __init mpc5121_ads_setup_arch(void)
for_each_compatible_node(np, pci, fsl,mpc5121-pci)
mpc83xx_add_bridge(np);
#endif
+ mpc512x_setup_diu();
}
static void __init mpc5121_ads_init_IRQ(void)
@@ -60,11 +61,17 @@ static int __init mpc5121_ads_probe(void)
return of_flat_dt_is_compatible(root, fsl,mpc5121ads);
}
+void __init mpc5121_ads_init_early(void)
+{
+ mpc512x_init_diu();
+}
+
define_machine(mpc5121_ads) {
.name = MPC5121 ADS,
.probe = mpc5121_ads_probe,
.setup_arch = mpc5121_ads_setup_arch,
.init = mpc512x_init,
+ .init_early = mpc5121_ads_init_early,
.init_IRQ = mpc5121_ads_init_IRQ,
.get_irq = ipic_get_irq,
.calibrate_decr = generic_calibrate_decr,
diff --git a/arch/powerpc/platforms/512x/mpc5121_generic.c
b/arch/powerpc/platforms/512x/mpc5121_generic.c
index a6c0e3a..3aaa281 100644
--- a/arch/powerpc/platforms/512x/mpc5121_generic.c
+++ b/arch/powerpc/platforms/512x/mpc5121_generic.c
@@ -28,6 +28,7 @@
*/
static char *board[] __initdata = {
prt,prtlvt,
+ ifm,pdm360ng,
You're adding a new board here. This is completely unrelated.
NULL
};
@@ -48,10 +49,22 @@ static int __init mpc5121_generic_probe(void)
return board[i] != NULL;
}
+void __init mpc512x_generic_init_early(void)
+{
+ mpc512x_init_diu();
+}
+
+void __init mpc512x_generic_setup_arch(void)
+{
+ mpc512x_setup_diu();
+}
+
define_machine(mpc5121_generic) {
.name = MPC5121 generic,
.probe = mpc5121_generic_probe,
.init = mpc512x_init,
+ .init_early = mpc512x_generic_init_early,
+ .setup_arch = mpc512x_generic_setup_arch,
.init_IRQ = mpc512x_init_IRQ,
.get_irq = ipic_get_irq,
.calibrate_decr = generic_calibrate_decr,
diff --git a/arch/powerpc/platforms/512x/mpc512x.h
b/arch/powerpc/platforms/512x/mpc512x.h
index d72b2c7..1cfe9d5 100644
--- a/arch/powerpc/platforms/512x/mpc512x.h
+++ b/arch/powerpc/platforms/512x/mpc512x.h
@@ -17,4 +17,7 @@ extern int __init mpc5121_clk_init(void);
void __init mpc512x_declare_of_platform_devices(void);
extern void mpc512x_restart(char *cmd);
extern void __init mpc5121_usb_init(void);
+extern void __init mpc512x_init_diu(void);
+extern void __init mpc512x_setup_diu(void);
__init annotations do not belong in header files.
+extern struct fsl_diu_shared_fb diu_shared_fb;
H. I'm not fond of the global data structure. Especially
considering that the struct fsl_diu_shared_fb is defined in
mpc512x_shared.c, so nothing
Re: [PATCH 2/3] fbdev: fsl-diu-fb.c: allow setting panel video mode from DT
On Sat, Feb 27, 2010 at 2:58 PM, Anatolij Gustschin ag...@denx.de wrote:
Add support for specifying display panel data in the device
tree. If no panel data is provided in the device tree, default
video mode will be used as usual.
Signed-off-by: Anatolij Gustschin ag...@denx.de
This one seems okay, but the binding in the first patch first needs to
get resolved.
g.
---
drivers/video/Kconfig | 1 +
drivers/video/fsl-diu-fb.c | 63
+---
2 files changed, 37 insertions(+), 27 deletions(-)
diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig
index dc1beb0..c805ecd 100644
--- a/drivers/video/Kconfig
+++ b/drivers/video/Kconfig
@@ -1850,6 +1850,7 @@ config FB_FSL_DIU
select FB_CFB_COPYAREA
select FB_CFB_IMAGEBLIT
select PPC_LIB_RHEAP
+ select FB_OF_MODE
---help---
Framebuffer driver for the Freescale SoC DIU
diff --git a/drivers/video/fsl-diu-fb.c b/drivers/video/fsl-diu-fb.c
index 4637bcb..19ca1da 100644
--- a/drivers/video/fsl-diu-fb.c
+++ b/drivers/video/fsl-diu-fb.c
@@ -36,6 +36,8 @@
#include sysdev/fsl_soc.h
#include fsl-diu-fb.h
+#include ofmode.h
+
/*
* These parameters give default parameters
* for video output 1024x768,
@@ -1168,7 +1170,7 @@ static int init_fbinfo(struct fb_info *info)
return 0;
}
-static int __devinit install_fb(struct fb_info *info)
+static int __devinit install_fb(struct device_node *np, struct fb_info *info)
{
int rc;
struct mfb_info *mfbi = info-par;
@@ -1177,33 +1179,40 @@ static int __devinit install_fb(struct fb_info *info)
if (init_fbinfo(info))
return -EINVAL;
- if (mfbi-index == 0) /* plane 0 */
- aoi_mode = fb_mode;
- else
+ if (mfbi-index == 0) { /* plane 0 */
+ /* use default mode for plane0 if there is no mode in DTB */
+ if (of_get_video_mode(np, info) 0)
+ aoi_mode = fb_mode;
+ else
+ aoi_mode = NULL;
+ } else
aoi_mode = init_aoi_mode;
- pr_debug(mode used = %s\n, aoi_mode);
- rc = fb_find_mode(info-var, info, aoi_mode, fsl_diu_mode_db,
- ARRAY_SIZE(fsl_diu_mode_db), fsl_diu_default_mode, default_bpp);
- switch (rc) {
- case 1:
- pr_debug(using mode specified in @mode\n);
- break;
- case 2:
- pr_debug(using mode specified in @mode
- with ignored refresh rate\n);
- break;
- case 3:
- pr_debug(using mode default mode\n);
- break;
- case 4:
- pr_debug(using mode from list\n);
- break;
- default:
- pr_debug(rc = %d\n, rc);
- pr_debug(failed to find mode\n);
- return -EINVAL;
- break;
+ if (aoi_mode) {
+ pr_debug(mode used = %s\n, aoi_mode);
+ rc = fb_find_mode(info-var, info, aoi_mode, fsl_diu_mode_db,
+ ARRAY_SIZE(fsl_diu_mode_db),
+ fsl_diu_default_mode, default_bpp);
+ switch (rc) {
+ case 1:
+ pr_debug(using mode specified in @mode\n);
+ break;
+ case 2:
+ pr_debug(using mode specified in @mode
+ with ignored refresh rate\n);
+ break;
+ case 3:
+ pr_debug(using mode default mode\n);
+ break;
+ case 4:
+ pr_debug(using mode from list\n);
+ break;
+ default:
+ pr_debug(rc = %d\n, rc);
+ pr_debug(failed to find mode\n);
+ return -EINVAL;
+ break;
+ }
}
pr_debug(xres_virtual %d\n, info-var.xres_virtual);
@@ -1521,7 +1530,7 @@ static int __devinit fsl_diu_probe(struct of_device
*ofdev,
mfbi-ad = (struct diu_ad *)((u32)pool.ad.vaddr
+ pool.ad.offset) + i;
mfbi-ad-paddr = pool.ad.paddr + i * sizeof(struct diu_ad);
- ret = install_fb(machine_data-fsl_diu_info[i]);
+ ret = install_fb(np, machine_data-fsl_diu_info[i]);
if (ret) {
dev_err(ofdev-dev,
Failed to register framebuffer %d\n,
--
1.6.3.3
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 0/3] Rework MPC5121 DIU support (for 2.6.34)
Hi Anatolij, On Sat, Feb 27, 2010 at 2:58 PM, Anatolij Gustschin ag...@denx.de wrote: This patch series rework DIU support patch submitted previously with the patch series for updating MPC5121 support in mainline. It doesn't add new panel timing data to the framebuffer driver anymore. Instead we now allow encoding this data in the device tree. First two patches add this support. Thanks for this work. I've made specific comments on the individual patches. There are some details to be worked out, but I think it is moving in the right direction. It is intended for inclusion in 2.6.34, since without DIU support patch framebuffer doesn't work on mpc5121. It's actually late for 2.6.34. Unless it is a bug fix, I stop picking up new patches somewhere in the -rc7 or -rc8 timerframe, and I am definitely in bug-fix-only mode once the merge window has opened. I do this to ensure all patches receive a decent amount of linux-next exposure before I ask Linus to pull them. I'll being picking up new patches for 2.6.35 into my -next branch after 2.6.34-rc1 is released. g. -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
