Re: [Patch 2/6] Introduce PPC64 specific Hardware Breakpoint interfaces
On Wed, Jun 03, 2009 at 10:05:11PM +0530, K.Prasad wrote:
> Introduce PPC64 implementation for the generic hardware breakpoint interfaces
> defined in kernel/hw_breakpoint.c. Enable the HAVE_HW_BREAKPOINT flag and the
> Makefile.
[snip]
> +/*
> + * Install the debug register values for just the kernel, no thread.
This comment does seem to quite match the function below.
> + */
> +void arch_uninstall_thread_hw_breakpoint()
> +{
> + set_dabr(0);
> +}
> +
> +/*
> + * Store a breakpoint's encoded address, length, and type.
> + */
> +int arch_store_info(struct hw_breakpoint *bp, struct task_struct *tsk)
> +{
> + /*
> + * User-space requests will always have the address field populated
> + * Symbol names from user-space are rejected
> + */
> + if (tsk && bp->info.name)
> + return -EINVAL;
> + /*
> + * User-space requests will always have the address field populated
> + * For kernel-addresses, either the address or symbol name can be
> + * specified.
> + */
> + if (bp->info.name)
> + bp->info.address = (unsigned long)
> + kallsyms_lookup_name(bp->info.name);
Archs don't have to implement this name lookup stuff, but it looks
like most of them would - so it looks like there ought to be a helper
function in generic code that will do the check / name lookup stuff.
> + if (bp->info.address)
> + return 0;
Hrm.. you realise there's no theoretical reason a userspace program
couldn't put a breakpoint at address 0...?
> + return -EINVAL;
> +}
> +
> +/*
> + * Validate the arch-specific HW Breakpoint register settings
> + */
> +int arch_validate_hwbkpt_settings(struct hw_breakpoint *bp,
> + struct task_struct *tsk)
> +{
> + int is_kernel, ret = -EINVAL;
> +
> + if (!bp)
> + return ret;
> +
> + switch (bp->info.type) {
> + case HW_BREAKPOINT_READ:
> + case HW_BREAKPOINT_WRITE:
> + case HW_BREAKPOINT_RW:
> + break;
> + default:
> + return ret;
> + }
> +
> + if (bp->triggered)
> + ret = arch_store_info(bp, tsk);
> +
> + is_kernel = is_kernel_addr(bp->info.address);
> + if ((tsk && is_kernel) || (!tsk && !is_kernel))
> + return -EINVAL;
> +
> + return ret;
> +}
> +
> +void arch_update_user_hw_breakpoint(int pos, struct task_struct *tsk)
> +{
> + struct thread_struct *thread = &(tsk->thread);
> + struct hw_breakpoint *bp = thread->hbp[0];
> +
> + if (bp)
> + thread->dabr = (bp->info.address & ~HW_BREAKPOINT_ALIGN) |
> + bp->info.type | DABR_TRANSLATION;
> + else
> + thread->dabr = 0;
> +}
> +
> +void arch_flush_thread_hw_breakpoint(struct task_struct *tsk)
> +{
> + struct thread_struct *thread = &(tsk->thread);
> +
> + thread->dabr = 0;
> +}
> +
> +/*
> + * Handle debug exception notifications.
> + */
> +int __kprobes hw_breakpoint_handler(struct die_args *args)
> +{
> + int rc = NOTIFY_STOP;
> + struct hw_breakpoint *bp;
> + struct pt_regs *regs = args->regs;
> + unsigned long dar = regs->dar;
> + int cpu, is_one_shot, stepped = 1;
> +
> + /* Disable breakpoints during exception handling */
> + set_dabr(0);
> +
> + cpu = get_cpu();
> + /* Determine whether kernel- or user-space address is the trigger */
> + bp = (hbp_kernel_pos == HBP_NUM) ? current->thread.hbp[0] :
> + per_cpu(this_hbp_kernel[0], cpu);
> + /*
> + * bp can be NULL due to lazy debug register switching
> + * or due to the delay between updates of hbp_kernel_pos
> + * and this_hbp_kernel.
> + */
> + if (!bp)
> + goto out;
> +
> + if (dar == bp->info.address)
> + per_cpu(dabr_data, cpu) = (hbp_kernel_pos == HBP_NUM) ?
> + current->thread.dabr : kdabr;
> + else {
> + /*
> + * This exception is triggered not because of a memory access on
> + * the monitored variable but in the double-word address range
> + * in which it is contained. We will consume this exception,
> + * considering it as 'noise'.
> + */
> + rc = NOTIFY_STOP;
> + goto out;
> + }
> + is_one_shot = (bp->triggered == ptrace_triggered) ? 1 : 0;
Ouch, explicitly special-casing ptrace_triggered is pretty nasty.
Since the bp_info is already arch specific, maybe it should include a
flag to indicate whether the breakpoint is one-shot or not.
> + (bp->triggered)(bp, regs);
> + /*
> + * Ptrace expects the HW Breakpoints to be one-shot. We will return
> + * NOTIFY_DONE without restoring DABR with the breakpoint address. The
> + * downstream code will generate SIGTRAP to the process
> + */
> + if (is_one_shot) {
> + rc = N
Re: [Patch 3/6] Modify ptrace code to use Hardware Breakpoint interfaces
On Wed, Jun 03, 2009 at 10:05:24PM +0530, K.Prasad wrote:
> Modify the ptrace code to use the hardware breakpoint interfaces for
> user-space.
>
> Signed-off-by: K.Prasad
> ---
> arch/powerpc/kernel/ptrace.c | 47
> +++
> 1 file changed, 47 insertions(+)
>
> Index: linux-2.6-tip.hbkpt/arch/powerpc/kernel/ptrace.c
> ===
> --- linux-2.6-tip.hbkpt.orig/arch/powerpc/kernel/ptrace.c
> +++ linux-2.6-tip.hbkpt/arch/powerpc/kernel/ptrace.c
> @@ -37,6 +37,7 @@
> #include
> #include
> #include
> +#include
>
> /*
> * does not yet catch signals sent when the child dies.
> @@ -735,9 +736,26 @@ void user_disable_single_step(struct tas
> clear_tsk_thread_flag(task, TIF_SINGLESTEP);
> }
>
> +void ptrace_triggered(struct hw_breakpoint *bp, struct pt_regs *regs)
> +{
> + /*
> + * Unregister the breakpoint request here since ptrace has defined a
> + * one-shot behaviour for breakpoint exceptions in PPC64.
> + * The SIGTRAP signal is generated automatically for us in do_dabr().
> + * We don't have to do anything here
> + */
> + unregister_user_hw_breakpoint(current, bp);
> + kfree(bp);
Couldn't you also clear the saved dabr info here, to avoid having to
special case this in the actual breakpoint handler.
Also, I think you should be delivering the signal here - for gdb
compatibility I think we'll need to match the old behaviour which has
the TRAP delivered before executing the breakpointed instruction.
> +}
> +
> int ptrace_set_debugreg(struct task_struct *task, unsigned long addr,
> unsigned long data)
> {
> +#ifdef CONFIG_PPC64
> + struct thread_struct *thread = &(task->thread);
> + struct hw_breakpoint *bp;
> + int ret;
> +#endif
> /* For ppc64 we support one DABR and no IABR's at the moment (ppc64).
>* For embedded processors we support one DAC and no IAC's at the
>* moment.
> @@ -767,6 +785,35 @@ int ptrace_set_debugreg(struct task_stru
> if (data && !(data & DABR_TRANSLATION))
> return -EIO;
>
> +#ifdef CONFIG_PPC64
> + bp = thread->hbp[0];
> + if (data == 0) {
> + if (bp) {
> + unregister_user_hw_breakpoint(task, bp);
> + kfree(bp);
> + }
> + return 0;
> + }
> +
> + if (bp) {
> + bp->info.type = data & HW_BREAKPOINT_RW;
> + task->thread.dabr = bp->info.address = data;
> + return modify_user_hw_breakpoint(task, bp);
> + }
> + bp = kzalloc(sizeof(struct hw_breakpoint), GFP_KERNEL);
> + if (!bp)
> + return -ENOMEM;
> +
> + /* Store the type of breakpoint */
> + bp->info.type = data & HW_BREAKPOINT_RW;
> + bp->triggered = ptrace_triggered;
> + task->thread.dabr = bp->info.address = data;
> +
> + ret = register_user_hw_breakpoint(task, bp);
> + if (ret)
> + return ret;
> +#endif /* CONFIG_PPC64 */
> +
> /* Move contents to the DABR register */
> task->thread.dabr = data;
>
>
> ___
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
>
--
David Gibson| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] [POWERPC] 83xx: Add support for the Thecus N1200 NAS device
On Thu, Jun 04, 2009 at 09:59:04PM +0100, Byron Bradley wrote:
> The Thecus N1200 is a NAS device with a single internal SATA disk and
> an eSATA port based on an MPC8347 SoC.
Comments on a number of fairly minor device tree nits below:
[snip]
> + soc8...@e000 {
> + #address-cells = <1>;
> + #size-cells = <1>;
> + device_type = "soc";
> + compatible = "simple-bus";
The compatible value should have something more specific
(e.g. "fsl,mpc8340-soc") before listing "simple-bus".
> + ranges = <0x0 0xe000 0x0010
> + 0xfe00 0xfe00 0x080>;
> + reg = <0xe000 0x0200>;
> + bus-frequency = <0>;// from bootloader
> +
> + physmap-fl...@fe00 {
Calling this just "flash" would be more normal.
> + #address-cells = <1>;
> + #size-cells = <1>;
> + compatible = "cfi-flash";
Ideally this should list the actual model of flash chip, before the
generic "cfi-flash".
> + reg = <0xfe00 0x080>;
> + bank-width = <2>;
> + device-width = <1>;
> +
> + u-b...@0 {
> + reg = <0x0 0x04>;
> + read-only;
> + };
> +
> + u-boot-con...@4 {
> + reg = <0x04 0x04>;
> + label = "u-boot config";
> + };
> +
> + u...@08 {
> + reg = <0x08 0x10>;
> + };
> +
> + ker...@18 {
> + reg = <0x18 0x1a>;
> + };
> +
> + ramd...@32 {
> + reg = <0x32 0x4e>;
> + };
> + };
> +
> + w...@200 {
> + device_type = "watchdog";
No device_type here.
> + compatible = "mpc83xx_wdt";
> + reg = <0x200 0x100>;
> + };
> +
> + i...@3000 {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + cell-index = <0>;
> + compatible = "fsl-i2c";
> + reg = <0x3000 0x100>;
> + interrupts = <14 0x8>;
> + interrupt-parent = <&ipic>;
> + dfsrr;
> +
> + fanc...@32 {
A less abbreviated name, like "fan-control" would be more usual here.
> + device_type = "hwmon";
No device_type here either.
> + compatible = "fintek,f75375";
> + reg = <0x2e>;
> + };
> +
> + r...@32 {
> + device_type = "rtc";
Or here.
> + compatible = "ricoh,rs5c372a";
> + reg = <0x32>;
> + };
> +
> + boardc...@32 {
Again "board-control" would be preferable.
> + device_type = "misc";
Especially no device_type here.
[snip]
> + ipic: p...@700 {
> + interrupt-controller;
> + #address-cells = <0>;
> + #interrupt-cells = <2>;
> + reg = <0x700 0x100>;
> + device_type = "ipic";
This should have a compatible property. It shouldn't really have
device_type, but I suspect that's a bug in the ipic binding, rather
than your tree per-se.
> + };
> +
> + gpio1: gpio-control...@c00 {
> + #gpio-cells = <2>;
> + compatible = "fsl,mpc8347-gpio", "fsl,mpc8349-gpio";
This actually is an 8349 board, yes? Generally compatible should be
listed from most specific to least specific, so the 8349 entry should
go first.
--
David Gibson| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] [POWERPC] 83xx: Add support for the Thecus N1200 NAS device
On Thu, 4 Jun 2009, Kumar Gala wrote: > > On Jun 4, 2009, at 3:59 PM, Byron Bradley wrote: > > > The Thecus N1200 is a NAS device with a single internal SATA disk and > > an eSATA port based on an MPC8347 SoC. > > > > http://thecus.nas-central.org/index.php/Category:N1200 > > > > Signed-off-by: Byron Bradley > > Signed-off-by: Tim Ellis > > --- > > arch/powerpc/boot/Makefile |1 + > > arch/powerpc/boot/dts/thecus_n1200.dts | 352 + > > arch/powerpc/boot/wrapper|2 +- > > arch/powerpc/configs/83xx/thecus_n1200_defconfig | 1674 > > ++ > > arch/powerpc/platforms/83xx/Kconfig |7 + > > arch/powerpc/platforms/83xx/Makefile |1 + > > arch/powerpc/platforms/83xx/thecus_n1200.c | 160 ++ > > 7 files changed, 2196 insertions(+), 1 deletions(-) > > create mode 100644 arch/powerpc/boot/dts/thecus_n1200.dts > > create mode 100644 arch/powerpc/configs/83xx/thecus_n1200_defconfig > > create mode 100644 arch/powerpc/platforms/83xx/thecus_n1200.c > > > > diff --git a/arch/powerpc/boot/Makefile b/arch/powerpc/boot/Makefile > > index 9ae7b7e..7ea6aff 100644 > > --- a/arch/powerpc/boot/Makefile > > +++ b/arch/powerpc/boot/Makefile > > @@ -228,6 +228,7 @@ image-$(CONFIG_MPC834x_ITX) += > > cuImage.mpc8349emitx \ > >cuImage.mpc8349emitxgp > > image-$(CONFIG_MPC834x_MDS) += cuImage.mpc834x_mds > > image-$(CONFIG_MPC836x_MDS) += cuImage.mpc836x_mds > > +image-$(CONFIG_THECUS_N1200) += cuImage.thecus_n1200 > > image-$(CONFIG_ASP834x) += dtbImage.asp834x-redboot > > Is the u-boot for the board capable of dealing w/device trees or do you really > need cuImage? The u-boot on the board can't deal with device trees and we have no idea where the JTAG pins are so it will probably never be supported. Cheers, -- Byron Bradley ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] [POWERPC] 83xx: Support the MCU on the Thecus N1200 board
The Thecus N1200 has a board control PIC on the I2C bus. This controls
two of the LEDs, the buzzer and allows the board to poweroff.
Signed-off-by: Byron Bradley
---
arch/powerpc/configs/83xx/thecus_n1200_defconfig |3 +-
arch/powerpc/platforms/83xx/Makefile |1 +
arch/powerpc/platforms/83xx/mcu_thecus_n1200.c | 307 ++
arch/powerpc/platforms/Kconfig |9 +
4 files changed, 319 insertions(+), 1 deletions(-)
create mode 100644 arch/powerpc/platforms/83xx/mcu_thecus_n1200.c
diff --git a/arch/powerpc/configs/83xx/thecus_n1200_defconfig
b/arch/powerpc/configs/83xx/thecus_n1200_defconfig
index b0c3a15..a0731e6 100644
--- a/arch/powerpc/configs/83xx/thecus_n1200_defconfig
+++ b/arch/powerpc/configs/83xx/thecus_n1200_defconfig
@@ -1,7 +1,7 @@
#
# Automatically generated make config: don't edit
# Linux kernel version: 2.6.30-rc6
-# Fri May 22 18:36:51 2009
+# Fri May 22 19:01:15 2009
#
# CONFIG_PPC64 is not set
@@ -217,6 +217,7 @@ CONFIG_IPIC=y
CONFIG_MPC8xxx_GPIO=y
# CONFIG_SIMPLE_GPIO is not set
# CONFIG_MCU_MPC8349EMITX is not set
+CONFIG_MCU_THECUS_N1200=m
#
# Kernel options
diff --git a/arch/powerpc/platforms/83xx/Makefile
b/arch/powerpc/platforms/83xx/Makefile
index 2f2d522..682797c 100644
--- a/arch/powerpc/platforms/83xx/Makefile
+++ b/arch/powerpc/platforms/83xx/Makefile
@@ -15,4 +15,5 @@ obj-$(CONFIG_MPC837x_MDS) += mpc837x_mds.o
obj-$(CONFIG_SBC834x) += sbc834x.o
obj-$(CONFIG_MPC837x_RDB) += mpc837x_rdb.o
obj-$(CONFIG_THECUS_N1200) += thecus_n1200.o
+obj-$(CONFIG_MCU_THECUS_N1200) += mcu_thecus_n1200.o
obj-$(CONFIG_ASP834x) += asp834x.o
diff --git a/arch/powerpc/platforms/83xx/mcu_thecus_n1200.c
b/arch/powerpc/platforms/83xx/mcu_thecus_n1200.c
new file mode 100644
index 000..03384ce
--- /dev/null
+++ b/arch/powerpc/platforms/83xx/mcu_thecus_n1200.c
@@ -0,0 +1,307 @@
+/*
+ * Driver for the MCU on Thecus N1200 boards.
+ *
+ * Copyright (c) 2009 Byron Bradley
+ *
+ * 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.
+ */
+
+/*
+ * The Thecus N1200 boards have a board control PIC on the I2C bus. This
+ * provides control over two of the LEDs, buzzer and the power-off function.
+ * The behaviour of the power button changes depending on the power state so we
+ * tell the PIC we have booted when the module loads and tell it when we are
+ * rebooting.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+/* N1200 registers */
+#define N1200_REG_PWR_CTRL 0x0
+#define N1200_REG_LED_SATA 0x1
+#define N1200_REG_LED_SYSTEM 0x2
+#define N1200_REG_LED_BUSY 0x3
+#define N1200_REG_BUZZER 0x4
+#define N1200_REG_PWR_STATUS 0x5
+#define N1200_REG_VERSION 0x6
+
+/* for N1200_REG_PWR_CTRL */
+#define N1200_PWR_OFF 0x0
+#define N1200_PWR_RESET0x1
+
+/* for N1200_REG_PWR_STATUS */
+#define N1200_PWR_OFF 0x0
+#define N1200_PWR_BOOTED 0x2
+
+/* for N1200_REG_LED_* */
+#define N1200_LED_OFF 0x0
+#define N1200_LED_ON 0x1
+#define N1200_LED_BLINK0x2
+
+/* We need to store a pointer to the i2c_client for use during a poweroff */
+static struct i2c_client *n1200_i2c_client;
+
+struct mcu_n1200 {
+ struct led_classdev sata_led;
+ struct led_classdev system_led;
+ struct led_classdev busy_led;
+ struct input_dev*input_dev;
+};
+
+static inline int n1200_read(struct i2c_client *client, u8 reg)
+{
+ return i2c_smbus_read_byte_data(client, reg);
+}
+
+static inline void n1200_write(struct i2c_client *client, u8 reg, u8 value)
+{
+ i2c_smbus_write_byte_data(client, reg, value);
+}
+
+void n1200_power_off(void)
+{
+ if (n1200_i2c_client == NULL)
+ return;
+
+ n1200_write(n1200_i2c_client, N1200_REG_PWR_CTRL, N1200_PWR_OFF);
+}
+
+static int n1200_reboot_notify(struct notifier_block *nb, unsigned long event,
+ void *p)
+{
+ if (event != SYS_RESTART || n1200_i2c_client == NULL)
+ return NOTIFY_DONE;
+
+ n1200_write(n1200_i2c_client, N1200_REG_PWR_CTRL, N1200_PWR_RESET);
+
+ return NOTIFY_DONE;
+}
+
+struct notifier_block n1200_notifier = {
+ .notifier_call = n1200_reboot_notify,
+};
+
+#define N1200_NEW_LED(__name, __reg, __blinkable) \
+static void n1200_##__name##_set(struct led_classdev *led_cdev,
\
+ enum led_brightness value) \
+{ \
+ if (value == LED_OFF) \
+ n1200_write(n1200_i2c_client,
new
Just one (1) question... On my iMac (G4 1GHz, 1Gb Leo 10.5.7) I want to use a Linux version... Therefor I downloaded Ubuntu 8 (and 9 and 7). By Disk Utility I made a bootable partition on an external FireWire drive... Changed my startup disk to this partition, and rebooted... Did not work... although the startup disk appears... (By holding down Alt-key during rebooting) Diggin' around on the 'net, learned me in a some way I needed a boot- program, this is the reason why I'm writing this e-mail... My aim is to boot from a partition of my FW-drive and install a Linux version on another partition on that FW-drive... And now the question: is there an unambiguous manual for this newbie that will guide me through this? thanks in advance, Hubert ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] [POWERPC] 83xx: Add support for the Thecus N1200 NAS device
On Jun 4, 2009, at 3:59 PM, Byron Bradley wrote: The Thecus N1200 is a NAS device with a single internal SATA disk and an eSATA port based on an MPC8347 SoC. http://thecus.nas-central.org/index.php/Category:N1200 Signed-off-by: Byron Bradley Signed-off-by: Tim Ellis --- arch/powerpc/boot/Makefile |1 + arch/powerpc/boot/dts/thecus_n1200.dts | 352 + arch/powerpc/boot/wrapper|2 +- arch/powerpc/configs/83xx/thecus_n1200_defconfig | 1674 + + arch/powerpc/platforms/83xx/Kconfig |7 + arch/powerpc/platforms/83xx/Makefile |1 + arch/powerpc/platforms/83xx/thecus_n1200.c | 160 ++ 7 files changed, 2196 insertions(+), 1 deletions(-) create mode 100644 arch/powerpc/boot/dts/thecus_n1200.dts create mode 100644 arch/powerpc/configs/83xx/thecus_n1200_defconfig create mode 100644 arch/powerpc/platforms/83xx/thecus_n1200.c diff --git a/arch/powerpc/boot/Makefile b/arch/powerpc/boot/Makefile index 9ae7b7e..7ea6aff 100644 --- a/arch/powerpc/boot/Makefile +++ b/arch/powerpc/boot/Makefile @@ -228,6 +228,7 @@ image-$(CONFIG_MPC834x_ITX) += cuImage.mpc8349emitx \ cuImage.mpc8349emitxgp image-$(CONFIG_MPC834x_MDS) += cuImage.mpc834x_mds image-$(CONFIG_MPC836x_MDS) += cuImage.mpc836x_mds +image-$(CONFIG_THECUS_N1200) += cuImage.thecus_n1200 image-$(CONFIG_ASP834x) += dtbImage.asp834x-redboot Is the u-boot for the board capable of dealing w/device trees or do you really need cuImage? - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [BUILD FAILURE 01/04] Next June 04:PPC64 randconfig [drivers/staging/comedi/drivers.o]
On Thu, Jun 4, 2009 at 20:07, Greg KH wrote:
> On Thu, Jun 04, 2009 at 07:01:32PM +0530, Subrata Modak wrote:
>> CC [M] drivers/staging/comedi/drivers.o
>> drivers/staging/comedi/drivers.c: In function ‘comedi_buf_alloc’:
>> drivers/staging/comedi/drivers.c:496: error: ‘PAGE_KERNEL_NOCACHE’
>> undeclared (first use in this function)
>> drivers/staging/comedi/drivers.c:496: error: (Each undeclared identifier is
>> reported only once
>> drivers/staging/comedi/drivers.c:496: error: for each function it appears
>> in.)
>> make[3]: *** [drivers/staging/comedi/drivers.o] Error 1
>> make[2]: *** [drivers/staging/comedi] Error 2
>> make[1]: *** [drivers/staging] Error 2
>> make: *** [drivers] Error 2
>>
>> Is it still normal to expect this failure ?
>
> No.
>
>> I reported them long back during April:
>> http://www.gossamer-threads.com/lists/linux/kernel/1065227,
>
> Yes, and I took some patches that were supposed to fix this. I can't
> duplicate this here, care to send a patch that would fix it?
PAGE_KERNEL_NOCACHE is defined on a few architectures only, namely
frv, m32r, mn10300, sh, and x86[*]. On all others, it will fail.
[*] Interestingly, sparc refers to it in one of its include files,
without providing a
definition, Probably that code is unused.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [BUILD FAILURE 01/04] Next June 04:PPC64 randconfig [drivers/staging/comedi/drivers.o]
On Thu, Jun 04, 2009 at 07:01:32PM +0530, Subrata Modak wrote: > CC [M] drivers/staging/comedi/drivers.o > drivers/staging/comedi/drivers.c: In function ‘comedi_buf_alloc’: > drivers/staging/comedi/drivers.c:496: error: ‘PAGE_KERNEL_NOCACHE’ undeclared > (first use in this function) > drivers/staging/comedi/drivers.c:496: error: (Each undeclared identifier is > reported only once > drivers/staging/comedi/drivers.c:496: error: for each function it appears in.) > make[3]: *** [drivers/staging/comedi/drivers.o] Error 1 > make[2]: *** [drivers/staging/comedi] Error 2 > make[1]: *** [drivers/staging] Error 2 > make: *** [drivers] Error 2 > > Is it still normal to expect this failure ? No. > I reported them long back during April: > http://www.gossamer-threads.com/lists/linux/kernel/1065227, Yes, and I took some patches that were supposed to fix this. I can't duplicate this here, care to send a patch that would fix it? thanks, greg k-h ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [RFC PATCH] fsldma: Add DMA_SLAVE support
On Thu, Jun 04, 2009 at 07:20:26PM +0800, Li Yang-R58472 wrote: > > >> This is a request for comments on this patch. I hunch it is > >not quite > >> ready for inclusion, though it is certainly ready for > >review. Correct > >> functioning of this patch depends on the patches submitted earlier. > >> > >> As suggested by Dan Williams, I implemented DMA_SLAVE > >support for the > >> fsldma controller to allow me to use the hardware to > >transfer to/from > >> a scatterlist to a list of hardware address/length pairs. > >> > >> I implemented support for the extra features available in the DMA > >> controller, such as external pause and external start. I have not > >> tested the features yet. I am willing to drop the support if > >> everything else looks good. > >> > >> I have implemented helper functions for creating the list of > >hardware > >> address/length pairs as static inline functions in the > >linux/fsldma.h > >> header. Should I incorporate these into the driver itself and use > >> EXPORT_SYMBOL()? I've never done this before :) > >> > > > >Any comments on this patch? > > > > No comment for now. Didn't get the time to study the DMA_SLAVE thing. > :( > No problem, I just wanted to make sure that it had been noticed. The DMA_SLAVE thing is pretty simple: it uses chan->private to pass in arbitrary parameters to the device_prep_slave_sg() routine. The device_prep_slave_sg() routine takes a scatterlist and a DMA direction, then uses the private data to setup the transfer. When you're ready, submit the transfer and go, just like a normal memcpy operation. It is basically a way to have a device-specific function in the generic API. > >I've tested the external start feature, and it works great. I > > Good. Is it working with your custom board? Can I verify this with my > reference board? > Yes, I only tested it on my custom board. We use the external DMA control as part of the programming sequence for some FPGA's on the board. If I'm reading the eval board's schematic correctly, the pins for external DMA control aren't hooked to anything useful at the moment. If you really want to test it, you'll have to do some modifications to your board. On page 9 of the schematic (upper right corner) you'll see that the DMA pins are connected to the GPIO controller on the processor. You could solder some wires between the first and second three GPIO pins. Then you can configure SICRL so the first 3 pins are configured for GPIO, and the second 3 pins are configured for external DMA control. It is a bit of work, but not too bad. > >had to set the DMA Request Count (in the mode register) after > >the driver was in control. There is no interface for doing > >this in the existing driver. I just ioremap()ed the registers > >and added the value from my driver after claiming the channel > >with dma_request_channel(). > > > >There are ways to get the DMA controller into a state where > >the CB bit stays set no matter what you do. I have only seen > >this during an externally controlled transfer, when the > >external master does weird things. I would fix this state in > >terminate_all(), but I have been unsuccessful in getting the > >DMA controller working again after it has been messed up. > > What's the frequency for this to happen? Is the problem reproducable? I can only cause it to totally lock up when there is an error, and my FPGA programmer stops toggling the external DMA control pins in the middle of a transfer. Nothing I can do will get the DMASR[CB] bit to zero. I tried causing the problem with a memory-to-memory transfer, and was able to cause a similar problem. I programmed to the controller to read 32 bytes from 0xc000, which isn't part of the memory map. The DMA never completes, and the controller has the following bits set: DMAMR[CS]==1 DMASR[TE]==1 DMASR[CB]==1 The fsldma driver doesn't seem to detect the error at this point. I was able to re-start the DMA controller with the following sequence: DMAMR[CS]=0 DMASR[TE]=1 DMASR[CB]=1 (write 1's to set bits) DMACDAR=0 DMASAR=0 DMADAR=0 DMABCR=0 DMANDAR=0 (zero all registers) DMAMR[CS]=1 Now the fsldma driver tells me "transfer error!". The DMA channel is now in working order, and I can use it again. So, I can get something similar by doing a "bad" memory-to-memory transfer, but I cannot completely lock up the DMA controller. Thanks, Ira ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [BUILD FAILURE 02/04] Next June 04:PPC64 randconfig [drivers/usb/host/ohci-hcd.o]
On Thu, Jun 4, 2009 at 9:31 AM, Subrata Modak wrote: > CC drivers/usb/host/ohci-hcd.o > In file included from drivers/usb/host/ohci-hcd.c:1060: > drivers/usb/host/ohci-ppc-of.c:242:2: error: #error "No endianess selected > for ppc-of-ohci" > make[3]: *** [drivers/usb/host/ohci-hcd.o] Error 1 > make[2]: *** [drivers/usb/host] Error 2 > make[1]: *** [drivers/usb] Error 2 > make: *** [drivers] Error 2 > > I reported this earlier, and there were some discussions: > http://groups.google.co.kr/group/linux.kernel/browse_thread/thread/edff9d5572d3d225 Proposed patch by Arnd should fix this. It has not been merged. http://lkml.org/lkml/2009/4/22/49 -- Jon Smirl jonsm...@gmail.com ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[BUILD FAILURE 04/04] Next June 04:PPC64 randconfig [drivers/net/ucc_geth.o]
CC [M] drivers/net/ucc_geth.o drivers/net/ucc_geth.c: In function âucc_geth_probeâ: drivers/net/ucc_geth.c:3822: error: âphâ undeclared (first use in this function) drivers/net/ucc_geth.c:3822: error: (Each undeclared identifier is reported only once drivers/net/ucc_geth.c:3822: error: for each function it appears in.) drivers/net/ucc_geth.c:3832: error: âmdioâ undeclared (first use in this function) make[2]: *** [drivers/net/ucc_geth.o] Error 1 Regards-- Subrata ./config below: # # Automatically generated make config: don't edit # Linux kernel version: 2.6.30-rc8 # Thu Jun 4 05:27:50 2009 # # 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_BOOK3S=y 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_NOT_COHERENT_CACHE=y CONFIG_PPC32=y CONFIG_WORD_SIZE=32 # CONFIG_ARCH_PHYS_ADDR_T_64BIT is not set 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_GENERIC_HARDIRQS_NO__DO_IRQ=y # CONFIG_HAVE_SETUP_PER_CPU_AREA is not set CONFIG_IRQ_PER_CPU=y CONFIG_STACKTRACE_SUPPORT=y CONFIG_HAVE_LATENCYTOP_SUPPORT=y CONFIG_LOCKDEP_SUPPORT=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_GENERIC_GPIO=y # CONFIG_ARCH_NO_VIRT_TO_BUS is not set CONFIG_PPC=y CONFIG_EARLY_PRINTK=y CONFIG_GENERIC_NVRAM=y CONFIG_SCHED_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_DTC=y CONFIG_DEFAULT_UIMAGE=y # CONFIG_PPC_DCR_NATIVE is not set # CONFIG_PPC_DCR_MMIO is not set CONFIG_ARCH_SUPPORTS_DEBUG_PAGEALLOC=y 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 is not set # CONFIG_SWAP is not set CONFIG_SYSVIPC=y CONFIG_POSIX_MQUEUE=y CONFIG_BSD_PROCESS_ACCT=y # CONFIG_BSD_PROCESS_ACCT_V3 is not set CONFIG_TASKSTATS=y # CONFIG_TASK_DELAY_ACCT is not set # CONFIG_TASK_XACCT is not set CONFIG_AUDIT=y # CONFIG_AUDITSYSCALL is not set # # RCU Subsystem # CONFIG_CLASSIC_RCU=y # CONFIG_TREE_RCU is not set # CONFIG_PREEMPT_RCU is not set # CONFIG_TREE_RCU_TRACE is not set # CONFIG_PREEMPT_RCU_TRACE is not set CONFIG_IKCONFIG=m CONFIG_LOG_BUF_SHIFT=17 CONFIG_GROUP_SCHED=y # CONFIG_FAIR_GROUP_SCHED is not set CONFIG_RT_GROUP_SCHED=y # CONFIG_USER_SCHED is not set CONFIG_CGROUP_SCHED=y CONFIG_CGROUPS=y CONFIG_CGROUP_DEBUG=y # CONFIG_CGROUP_NS is not set # CONFIG_CGROUP_FREEZER is not set CONFIG_CGROUP_DEVICE=y # CONFIG_CPUSETS is not set CONFIG_CGROUP_CPUACCT=y # CONFIG_RESOURCE_COUNTERS is not set CONFIG_SYSFS_DEPRECATED=y CONFIG_SYSFS_DEPRECATED_V2=y CONFIG_RELAY=y CONFIG_NAMESPACES=y CONFIG_UTS_NS=y # CONFIG_IPC_NS is not set # CONFIG_USER_NS is not set CONFIG_PID_NS=y CONFIG_NET_NS=y CONFIG_BLK_DEV_INITRD=y CONFIG_INITRAMFS_SOURCE="" # CONFIG_RD_GZIP is not set CONFIG_RD_BZIP2=y CONFIG_RD_LZMA=y CONFIG_CC_OPTIMIZE_FOR_SIZE=y CONFIG_ANON_INODES=y CONFIG_EMBEDDED=y # CONFIG_SYSCTL_SYSCALL is not set CONFIG_KALLSYMS=y CONFIG_KALLSYMS_ALL=y # CONFIG_KALLSYMS_EXTRA_PASS is not set CONFIG_STRIP_ASM_SYMS=y CONFIG_HOTPLUG=y # CONFIG_PRINTK is not set CONFIG_BUG=y CONFIG_ELF_CORE=y CONFIG_PCSPKR_PLATFORM=y CONFIG_BASE_FULL=y # CONFIG_FUTEX is not set # CONFIG_EPOLL is not set # CONFIG_SIGNALFD is not set CONFIG_TIMERFD=y CONFIG_EVENTFD=y CONFIG_SHMEM=y CONFIG_AIO=y # CONFIG_VM_EVENT_COUNTERS is not set CONFIG_PCI_QUIRKS=y # CONFIG_COMPAT_BRK is not set # CONFIG_SLAB_ALLOCATOR is not set # CONFIG_SLUB_ALLOCATOR is not set # CONFIG_SLQB_ALLOCATOR is not set CONFIG_SLOB=y # CONFIG_PROFILING is not set CONFIG_TRACEPOINTS=y CONFIG_MARKERS=y CONFIG_HAVE_OPROFILE=y CONFIG_KPROBES=y CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS=y CONFIG_KRETPROBES=y CONFIG_HAVE_IOREMAP_PROT=y CONFIG_HAVE_KPROBES=y CONFIG_HAVE_KRETPROBES=y CONFIG_HAVE_ARCH_TRACEHOOK=y CONFIG_HAVE_CLK=y CONFIG_SLOW_WORK=y # CONFIG_HAVE_GENERIC_DMA_COHERENT is not set CONFIG_BASE_SMALL=0 CONFIG_MODULES=y CONFIG_MODULE_FORCE_LOAD=y CONFIG_MODULE_UNLOAD=y CONFIG_MODULE_FORCE_UNLOAD=y CONFIG_MODVERSIONS=y # CONFIG_MODULE_SRCVERSION_ALL is not set CONFIG_BLOCK=y CONFIG_LBD=y CONFIG_BLK_DEV_BSG=y CONFIG_BLK_DEV_INTEGRITY=y # # IO Schedulers # CONFIG_IOSCHED_NOOP=y # CONFIG_IOSCHED_AS is not set CONFIG_IOSCHED_DEADLINE=m 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" #
[BUILD FAILURE 02/04] Next June 04:PPC64 randconfig [drivers/usb/host/ohci-hcd.o]
CC drivers/usb/host/ohci-hcd.o In file included from drivers/usb/host/ohci-hcd.c:1060: drivers/usb/host/ohci-ppc-of.c:242:2: error: #error "No endianess selected for ppc-of-ohci" make[3]: *** [drivers/usb/host/ohci-hcd.o] Error 1 make[2]: *** [drivers/usb/host] Error 2 make[1]: *** [drivers/usb] Error 2 make: *** [drivers] Error 2 I reported this earlier, and there were some discussions: http://groups.google.co.kr/group/linux.kernel/browse_thread/thread/edff9d5572d3d225 Has the proposed patch made into the tree ? Regards-- Subrata == .config below: == # # Automatically generated make config: don't edit # Linux kernel version: 2.6.30-rc8 # Thu Jun 4 04:10:03 2009 # CONFIG_PPC64=y # # Processor support # CONFIG_PPC_BOOK3S=y # CONFIG_POWER4_ONLY is not set CONFIG_POWER3=y CONFIG_POWER4=y # CONFIG_TUNE_CELL is not set CONFIG_PPC_FPU=y CONFIG_ALTIVEC=y # CONFIG_VSX is not set CONFIG_PPC_STD_MMU=y CONFIG_PPC_STD_MMU_64=y CONFIG_PPC_MM_SLICES=y CONFIG_VIRT_CPU_ACCOUNTING=y CONFIG_SMP=y CONFIG_NR_CPUS=32 CONFIG_64BIT=y CONFIG_WORD_SIZE=64 CONFIG_ARCH_PHYS_ADDR_T_64BIT=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_GENERIC_HARDIRQS_NO__DO_IRQ=y CONFIG_HAVE_SETUP_PER_CPU_AREA=y CONFIG_IRQ_PER_CPU=y CONFIG_STACKTRACE_SUPPORT=y CONFIG_HAVE_LATENCYTOP_SUPPORT=y CONFIG_TRACE_IRQFLAGS_SUPPORT=y CONFIG_LOCKDEP_SUPPORT=y CONFIG_RWSEM_XCHGADD_ALGORITHM=y CONFIG_ARCH_HAS_ILOG2_U32=y CONFIG_ARCH_HAS_ILOG2_U64=y CONFIG_GENERIC_HWEIGHT=y CONFIG_GENERIC_CALIBRATE_DELAY=y CONFIG_GENERIC_FIND_NEXT_BIT=y CONFIG_GENERIC_GPIO=y CONFIG_ARCH_NO_VIRT_TO_BUS=y CONFIG_PPC=y CONFIG_EARLY_PRINTK=y CONFIG_COMPAT=y CONFIG_SYSVIPC_COMPAT=y CONFIG_SCHED_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_DTC=y # CONFIG_DEFAULT_UIMAGE is not set # CONFIG_PPC_DCR_NATIVE is not set CONFIG_PPC_DCR_MMIO=y CONFIG_PPC_DCR=y CONFIG_PPC_OF_PLATFORM_PCI=y CONFIG_ARCH_SUPPORTS_DEBUG_PAGEALLOC=y CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config" # # General setup # # CONFIG_EXPERIMENTAL is not set CONFIG_LOCK_KERNEL=y CONFIG_INIT_ENV_ARG_LIMIT=32 CONFIG_LOCALVERSION="" CONFIG_LOCALVERSION_AUTO=y CONFIG_SYSVIPC=y CONFIG_SYSVIPC_SYSCTL=y CONFIG_BSD_PROCESS_ACCT=y CONFIG_BSD_PROCESS_ACCT_V3=y # # RCU Subsystem # # CONFIG_CLASSIC_RCU is not set CONFIG_TREE_RCU=y # CONFIG_PREEMPT_RCU is not set # CONFIG_RCU_TRACE is not set CONFIG_RCU_FANOUT=64 CONFIG_RCU_FANOUT_EXACT=y # CONFIG_TREE_RCU_TRACE is not set # CONFIG_PREEMPT_RCU_TRACE is not set CONFIG_IKCONFIG=m CONFIG_LOG_BUF_SHIFT=17 CONFIG_CGROUPS=y # CONFIG_CGROUP_DEBUG is not set CONFIG_CGROUP_NS=y CONFIG_CGROUP_FREEZER=y CONFIG_CPUSETS=y # CONFIG_PROC_PID_CPUSET is not set CONFIG_CGROUP_CPUACCT=y CONFIG_RESOURCE_COUNTERS=y CONFIG_CGROUP_MEM_RES_CTLR=y CONFIG_MM_OWNER=y CONFIG_SYSFS_DEPRECATED=y CONFIG_SYSFS_DEPRECATED_V2=y # CONFIG_RELAY is not set CONFIG_NAMESPACES=y # CONFIG_UTS_NS is not set CONFIG_IPC_NS=y CONFIG_BLK_DEV_INITRD=y CONFIG_INITRAMFS_SOURCE="" # CONFIG_RD_GZIP is not set CONFIG_RD_BZIP2=y CONFIG_RD_LZMA=y CONFIG_CC_OPTIMIZE_FOR_SIZE=y CONFIG_SYSCTL=y CONFIG_ANON_INODES=y CONFIG_EMBEDDED=y CONFIG_SYSCTL_SYSCALL=y CONFIG_KALLSYMS=y CONFIG_KALLSYMS_ALL=y CONFIG_KALLSYMS_EXTRA_PASS=y CONFIG_STRIP_ASM_SYMS=y # CONFIG_HOTPLUG is not set CONFIG_PRINTK=y CONFIG_BUG=y CONFIG_ELF_CORE=y CONFIG_PCSPKR_PLATFORM=y # CONFIG_BASE_FULL is not set # CONFIG_FUTEX is not set CONFIG_EPOLL=y # CONFIG_SIGNALFD is not set # CONFIG_TIMERFD is not set # CONFIG_EVENTFD is not set CONFIG_SHMEM=y CONFIG_AIO=y CONFIG_VM_EVENT_COUNTERS=y # CONFIG_PCI_QUIRKS is not set CONFIG_COMPAT_BRK=y # CONFIG_SLAB_ALLOCATOR is not set # CONFIG_SLUB_ALLOCATOR is not set CONFIG_SLQB_ALLOCATOR=y CONFIG_SLQB=y # CONFIG_SLOB is not set CONFIG_PROFILING=y CONFIG_TRACEPOINTS=y CONFIG_MARKERS=y # CONFIG_OPROFILE is not set CONFIG_HAVE_OPROFILE=y CONFIG_KPROBES=y CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS=y CONFIG_HAVE_SYSCALL_WRAPPERS=y CONFIG_KRETPROBES=y CONFIG_HAVE_IOREMAP_PROT=y CONFIG_HAVE_KPROBES=y CONFIG_HAVE_KRETPROBES=y CONFIG_HAVE_ARCH_TRACEHOOK=y CONFIG_HAVE_DMA_ATTRS=y CONFIG_USE_GENERIC_SMP_HELPERS=y # CONFIG_SLOW_WORK is not set # CONFIG_HAVE_GENERIC_DMA_COHERENT is not set CONFIG_BASE_SMALL=1 CONFIG_MODULES=y CONFIG_MODULE_FORCE_LOAD=y # CONFIG_MODULE_UNLOAD is not set CONFIG_MODVERSIONS=y # CONFIG_MODULE_SRCVERSION_ALL is not set # CONFIG_BLOCK is not set CONFIG_FREEZER=y CONFIG_PPC_MSI_BITMAP=y # # Platform support # CONFIG_PPC_PSERIES=y # CONFIG_PPC_SPLPAR is not set # CONFIG_EEH is not set CONFIG_LPARCFG=y CONFIG_PPC_PSERIES_DEBUG=y CONFIG_PPC_SMLPAR=y CONFIG_PPC_ISERIES=y # # iSeries device drivers # CONFIG_VIOTAPE=m CONFIG_VIOPATH=y # CONFIG_PPC_PMAC is not set # CONFIG_PPC_MAPLE is not set CONFIG_PPC_PA
[BUILD FAILURE 01/04] Next June 04:PPC64 randconfig [drivers/staging/comedi/drivers.o]
CC [M] drivers/staging/comedi/drivers.o drivers/staging/comedi/drivers.c: In function âcomedi_buf_allocâ: drivers/staging/comedi/drivers.c:496: error: âPAGE_KERNEL_NOCACHEâ undeclared (first use in this function) drivers/staging/comedi/drivers.c:496: error: (Each undeclared identifier is reported only once drivers/staging/comedi/drivers.c:496: error: for each function it appears in.) make[3]: *** [drivers/staging/comedi/drivers.o] Error 1 make[2]: *** [drivers/staging/comedi] Error 2 make[1]: *** [drivers/staging] Error 2 make: *** [drivers] Error 2 Is it still normal to expect this failure ? I reported them long back during April: http://www.gossamer-threads.com/lists/linux/kernel/1065227, Regards-- Subrata = .config below: = # # Automatically generated make config: don't edit # Linux kernel version: 2.6.30-rc8 # Thu Jun 4 03:54:53 2009 # CONFIG_PPC64=y # # Processor support # CONFIG_PPC_BOOK3S=y CONFIG_POWER4_ONLY=y CONFIG_POWER4=y # CONFIG_TUNE_CELL is not set CONFIG_PPC_FPU=y CONFIG_ALTIVEC=y # CONFIG_VSX is not set CONFIG_PPC_STD_MMU=y CONFIG_PPC_STD_MMU_64=y CONFIG_PPC_MM_SLICES=y CONFIG_VIRT_CPU_ACCOUNTING=y CONFIG_SMP=y CONFIG_NR_CPUS=32 CONFIG_64BIT=y CONFIG_WORD_SIZE=64 CONFIG_ARCH_PHYS_ADDR_T_64BIT=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_GENERIC_HARDIRQS_NO__DO_IRQ=y CONFIG_HAVE_SETUP_PER_CPU_AREA=y CONFIG_IRQ_PER_CPU=y CONFIG_STACKTRACE_SUPPORT=y CONFIG_HAVE_LATENCYTOP_SUPPORT=y CONFIG_TRACE_IRQFLAGS_SUPPORT=y CONFIG_LOCKDEP_SUPPORT=y CONFIG_RWSEM_XCHGADD_ALGORITHM=y CONFIG_GENERIC_LOCKBREAK=y CONFIG_ARCH_HAS_ILOG2_U32=y CONFIG_ARCH_HAS_ILOG2_U64=y CONFIG_GENERIC_HWEIGHT=y CONFIG_GENERIC_CALIBRATE_DELAY=y CONFIG_GENERIC_FIND_NEXT_BIT=y CONFIG_GENERIC_GPIO=y CONFIG_ARCH_NO_VIRT_TO_BUS=y CONFIG_PPC=y CONFIG_EARLY_PRINTK=y CONFIG_COMPAT=y CONFIG_SCHED_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=y CONFIG_AUDIT_ARCH=y CONFIG_GENERIC_BUG=y CONFIG_DTC=y # CONFIG_DEFAULT_UIMAGE is not set # CONFIG_PPC_DCR_NATIVE is not set CONFIG_PPC_DCR_MMIO=y CONFIG_PPC_DCR=y CONFIG_PPC_OF_PLATFORM_PCI=y CONFIG_ARCH_SUPPORTS_DEBUG_PAGEALLOC=y CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config" # # General setup # CONFIG_EXPERIMENTAL=y CONFIG_LOCK_KERNEL=y CONFIG_INIT_ENV_ARG_LIMIT=32 CONFIG_LOCALVERSION="" CONFIG_LOCALVERSION_AUTO=y # CONFIG_SYSVIPC is not set CONFIG_BSD_PROCESS_ACCT=y CONFIG_BSD_PROCESS_ACCT_V3=y # # RCU Subsystem # # CONFIG_CLASSIC_RCU is not set # CONFIG_TREE_RCU is not set CONFIG_PREEMPT_RCU=y CONFIG_RCU_TRACE=y # CONFIG_TREE_RCU_TRACE is not set CONFIG_PREEMPT_RCU_TRACE=y # CONFIG_IKCONFIG is not set CONFIG_LOG_BUF_SHIFT=17 CONFIG_GROUP_SCHED=y CONFIG_FAIR_GROUP_SCHED=y CONFIG_RT_GROUP_SCHED=y CONFIG_USER_SCHED=y # CONFIG_CGROUP_SCHED is not set # CONFIG_CGROUPS is not set # CONFIG_SYSFS_DEPRECATED_V2 is not set CONFIG_RELAY=y CONFIG_NAMESPACES=y CONFIG_UTS_NS=y CONFIG_USER_NS=y CONFIG_PID_NS=y # CONFIG_BLK_DEV_INITRD is not set # CONFIG_CC_OPTIMIZE_FOR_SIZE is not set CONFIG_ANON_INODES=y CONFIG_EMBEDDED=y # CONFIG_SYSCTL_SYSCALL is not set CONFIG_KALLSYMS=y CONFIG_KALLSYMS_ALL=y CONFIG_KALLSYMS_EXTRA_PASS=y # CONFIG_STRIP_ASM_SYMS is not set CONFIG_HOTPLUG=y CONFIG_PRINTK=y CONFIG_BUG=y # CONFIG_ELF_CORE is not set CONFIG_PCSPKR_PLATFORM=y # CONFIG_BASE_FULL is not set CONFIG_FUTEX=y CONFIG_EPOLL=y # CONFIG_SIGNALFD is not set CONFIG_TIMERFD=y CONFIG_EVENTFD=y CONFIG_SHMEM=y CONFIG_AIO=y CONFIG_VM_EVENT_COUNTERS=y CONFIG_PCI_QUIRKS=y CONFIG_COMPAT_BRK=y # CONFIG_SLAB_ALLOCATOR is not set # CONFIG_SLUB_ALLOCATOR is not set # CONFIG_SLQB_ALLOCATOR is not set CONFIG_SLOB=y CONFIG_PROFILING=y CONFIG_TRACEPOINTS=y CONFIG_MARKERS=y CONFIG_OPROFILE=m CONFIG_HAVE_OPROFILE=y CONFIG_KPROBES=y CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS=y CONFIG_HAVE_SYSCALL_WRAPPERS=y CONFIG_KRETPROBES=y CONFIG_HAVE_IOREMAP_PROT=y CONFIG_HAVE_KPROBES=y CONFIG_HAVE_KRETPROBES=y CONFIG_HAVE_ARCH_TRACEHOOK=y CONFIG_HAVE_DMA_ATTRS=y CONFIG_USE_GENERIC_SMP_HELPERS=y CONFIG_SLOW_WORK=y # CONFIG_HAVE_GENERIC_DMA_COHERENT is not set CONFIG_RT_MUTEXES=y CONFIG_BASE_SMALL=1 CONFIG_MODULES=y CONFIG_MODULE_FORCE_LOAD=y # CONFIG_MODULE_UNLOAD is not set CONFIG_MODVERSIONS=y CONFIG_MODULE_SRCVERSION_ALL=y CONFIG_STOP_MACHINE=y # CONFIG_BLOCK is not set # CONFIG_FREEZER is not set # # Platform support # CONFIG_PPC_PSERIES=y # CONFIG_PPC_SPLPAR is not set CONFIG_EEH=y # CONFIG_SCANLOG is not set CONFIG_LPARCFG=y # CONFIG_PPC_PSERIES_DEBUG is not set CONFIG_PPC_SMLPAR=y # CONFIG_PPC_ISERIES is not set # CONFIG_PPC_PMAC is not set CONFIG_PPC_MAPLE=y CONFIG_PPC_PASEMI=y # # PA Semi PWRficient options # CONFIG_PPC_PASEMI_IOMMU=y # CONFIG_PPC_PASEMI_IOMMU_DMA_FORCE is not set CONFIG_PPC_PS3=y # # PS3 Platform Options # # CONFIG_PS3_ADVANCED is not set CONFIG_PS3_HTAB_SIZE=20 CONFIG
Re: [PATCH v4] zone_reclaim is always 0 by default
Acked-by: Robin Holt On Thu, Jun 04, 2009 at 07:23:15PM +0900, KOSAKI Motohiro wrote: ... > Actually, zone_reclaim_mode=1 mean "I dislike remote node allocation rather > than > disk access", it makes performance improvement to HPC workload. > but it makes performance degression to desktop, file server and web server. I still disagree with this statement, but I don't care that much. Why not something more to the effect of: Setting zone_reclaim_mode=1 causes memory allocations on a nearly exhausted node to do direct reclaim within that node before attempting off-node allocations. For work loads where most pages are clean in page cache and easily reclaimed, this can result excessive disk activity versus a more fair node memory balance. If you disagree, don't respond, just ignore. ... > --- a/include/linux/topology.h > +++ b/include/linux/topology.h > @@ -54,12 +54,7 @@ int arch_update_cpu_topology(void); > #define node_distance(from,to) ((from) == (to) ? LOCAL_DISTANCE : > REMOTE_DISTANCE) > #endif > #ifndef RECLAIM_DISTANCE > -/* > - * If the distance between nodes in a system is larger than RECLAIM_DISTANCE > - * (in whatever arch specific measurement units returned by node_distance()) > - * then switch on zone reclaim on boot. > - */ > -#define RECLAIM_DISTANCE 20 > +#define RECLAIM_DISTANCE INT_MAX Why remove this comment? It seems more-or-less a reasonable statement. Thanks, Robin ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: of_serial.c: adding UPF_FIXED_TYPE flag
On Wednesday 03 June 2009, David Mitchell wrote: > Hello, > > Are there any objections or concerns on adding UPF_FIXED_TYPE to the > port flags for the of_serial driver? Or maybe - are there any > implementations using of_serial that rely on the 8250's probing to > determine type? Based on the configs it looks like just the 4xx and 6xx > variants are using this driver. We also use the driver on ppc64/cell, which is what it was initially written for. Passing UPF_FIXED_TYPE sounds ok to me. Can you send a patch? Arnd <>< ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 0/2] Convert more boards to ppc40x_simple
On Thu, Jun 04, 2009 at 01:05:51PM +0200, Stefan Roese wrote: >Hi Josh, > >On Wednesday 03 June 2009 17:16:59 Josh Boyer wrote: >> Below are some patches to convert the Malaku and Kilauea/Halekala boards to >> the ppc40x_simple platform. I've tested the second patch on my Halekala >> board. The Malaku patch should work as well, but I don't have access to one >> of those boards. Feedback would be appreciated. > >Tested successfully on both Kilauea and Makalu. > >So, please add my: > >Tested-by: Stefan Roese Thanks! josh ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH v4] zone_reclaim is always 0 by default
On Thu, Jun 04, 2009 at 06:23:15PM +0800, KOSAKI Motohiro wrote:
>
> Current linux policy is, zone_reclaim_mode is enabled by default if the
> machine
> has large remote node distance. it's because we could assume that large
> distance
> mean large server until recently.
>
> Unfortunately, recent modern x86 CPU (e.g. Core i7, Opeteron) have P2P
> transport
> memory controller. IOW it's seen as NUMA from software view.
> Some Core i7 machine has large remote node distance.
>
> Yanmin reported zone_reclaim_mode=1 cause large apache regression.
>
> One Nehalem machine has 12GB memory,
> but there is always 2GB free although applications accesses lots of files.
> Eventually we located the root cause as zone_reclaim_mode=1.
>
> Actually, zone_reclaim_mode=1 mean "I dislike remote node allocation rather
> than
> disk access", it makes performance improvement to HPC workload.
> but it makes performance degression to desktop, file server and web server.
>
> In general, workload depended configration shouldn't put into default
> settings.
>
> However, current code is long standing about two year. Highest POWER and IA64
> HPC machine
> (only) use this setting.
>
> Thus, x86 and almost rest architecture change default setting, but Only power
> and ia64
> remain current configuration for backward-compatibility.
The above lines are too long. Limit to 72 cols in general could be
better as git-log may add additional leading white spaces.
Thank you for all the efforts!
Acked-by: Wu Fengguang
> Signed-off-by: KOSAKI Motohiro
> Cc: Christoph Lameter
> Cc: Rik van Riel
> Cc: Robin Holt
> Cc: "Zhang, Yanmin"
> Cc: Wu Fengguang
> Cc: linux-i...@vger.kernel.org
> Cc: linuxppc-dev@ozlabs.org
> ---
> arch/powerpc/include/asm/topology.h |6 ++
> include/linux/topology.h|7 +--
> 2 files changed, 7 insertions(+), 6 deletions(-)
>
> Index: b/include/linux/topology.h
> ===
> --- a/include/linux/topology.h
> +++ b/include/linux/topology.h
> @@ -54,12 +54,7 @@ int arch_update_cpu_topology(void);
> #define node_distance(from,to) ((from) == (to) ? LOCAL_DISTANCE :
> REMOTE_DISTANCE)
> #endif
> #ifndef RECLAIM_DISTANCE
> -/*
> - * If the distance between nodes in a system is larger than RECLAIM_DISTANCE
> - * (in whatever arch specific measurement units returned by node_distance())
> - * then switch on zone reclaim on boot.
> - */
> -#define RECLAIM_DISTANCE 20
> +#define RECLAIM_DISTANCE INT_MAX
> #endif
> #ifndef PENALTY_FOR_NODE_WITH_CPUS
> #define PENALTY_FOR_NODE_WITH_CPUS (1)
> Index: b/arch/powerpc/include/asm/topology.h
> ===
> --- a/arch/powerpc/include/asm/topology.h
> +++ b/arch/powerpc/include/asm/topology.h
> @@ -10,6 +10,12 @@ struct device_node;
>
> #include
>
> +/*
> + * Distance above which we begin to use zone reclaim
s/begin to/default to/ ?
> + */
> +#define RECLAIM_DISTANCE 20
> +
> +
> static inline int cpu_to_node(int cpu)
> {
> return numa_cpu_lookup_table[cpu];
>
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
RE: [RFC PATCH] fsldma: Add DMA_SLAVE support
>> This is a request for comments on this patch. I hunch it is >not quite >> ready for inclusion, though it is certainly ready for >review. Correct >> functioning of this patch depends on the patches submitted earlier. >> >> As suggested by Dan Williams, I implemented DMA_SLAVE >support for the >> fsldma controller to allow me to use the hardware to >transfer to/from >> a scatterlist to a list of hardware address/length pairs. >> >> I implemented support for the extra features available in the DMA >> controller, such as external pause and external start. I have not >> tested the features yet. I am willing to drop the support if >> everything else looks good. >> >> I have implemented helper functions for creating the list of >hardware >> address/length pairs as static inline functions in the >linux/fsldma.h >> header. Should I incorporate these into the driver itself and use >> EXPORT_SYMBOL()? I've never done this before :) >> > >Any comments on this patch? > No comment for now. Didn't get the time to study the DMA_SLAVE thing. :( >I've tested the external start feature, and it works great. I Good. Is it working with your custom board? Can I verify this with my reference board? >had to set the DMA Request Count (in the mode register) after >the driver was in control. There is no interface for doing >this in the existing driver. I just ioremap()ed the registers >and added the value from my driver after claiming the channel >with dma_request_channel(). > >There are ways to get the DMA controller into a state where >the CB bit stays set no matter what you do. I have only seen >this during an externally controlled transfer, when the >external master does weird things. I would fix this state in >terminate_all(), but I have been unsuccessful in getting the >DMA controller working again after it has been messed up. What's the frequency for this to happen? Is the problem reproducable? - Leo ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 0/2] Convert more boards to ppc40x_simple
Hi Josh, On Wednesday 03 June 2009 17:16:59 Josh Boyer wrote: > Below are some patches to convert the Malaku and Kilauea/Halekala boards to > the ppc40x_simple platform. I've tested the second patch on my Halekala > board. The Malaku patch should work as well, but I don't have access to one > of those boards. Feedback would be appreciated. Tested successfully on both Kilauea and Makalu. So, please add my: Tested-by: Stefan Roese Thanks. Best regards, Stefan ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH v4] zone_reclaim is always 0 by default
Current linux policy is, zone_reclaim_mode is enabled by default if the machine
has large remote node distance. it's because we could assume that large distance
mean large server until recently.
Unfortunately, recent modern x86 CPU (e.g. Core i7, Opeteron) have P2P transport
memory controller. IOW it's seen as NUMA from software view.
Some Core i7 machine has large remote node distance.
Yanmin reported zone_reclaim_mode=1 cause large apache regression.
One Nehalem machine has 12GB memory,
but there is always 2GB free although applications accesses lots of files.
Eventually we located the root cause as zone_reclaim_mode=1.
Actually, zone_reclaim_mode=1 mean "I dislike remote node allocation rather than
disk access", it makes performance improvement to HPC workload.
but it makes performance degression to desktop, file server and web server.
In general, workload depended configration shouldn't put into default settings.
However, current code is long standing about two year. Highest POWER and IA64
HPC machine
(only) use this setting.
Thus, x86 and almost rest architecture change default setting, but Only power
and ia64
remain current configuration for backward-compatibility.
Signed-off-by: KOSAKI Motohiro
Cc: Christoph Lameter
Cc: Rik van Riel
Cc: Robin Holt
Cc: "Zhang, Yanmin"
Cc: Wu Fengguang
Cc: linux-i...@vger.kernel.org
Cc: linuxppc-dev@ozlabs.org
---
arch/powerpc/include/asm/topology.h |6 ++
include/linux/topology.h|7 +--
2 files changed, 7 insertions(+), 6 deletions(-)
Index: b/include/linux/topology.h
===
--- a/include/linux/topology.h
+++ b/include/linux/topology.h
@@ -54,12 +54,7 @@ int arch_update_cpu_topology(void);
#define node_distance(from,to) ((from) == (to) ? LOCAL_DISTANCE :
REMOTE_DISTANCE)
#endif
#ifndef RECLAIM_DISTANCE
-/*
- * If the distance between nodes in a system is larger than RECLAIM_DISTANCE
- * (in whatever arch specific measurement units returned by node_distance())
- * then switch on zone reclaim on boot.
- */
-#define RECLAIM_DISTANCE 20
+#define RECLAIM_DISTANCE INT_MAX
#endif
#ifndef PENALTY_FOR_NODE_WITH_CPUS
#define PENALTY_FOR_NODE_WITH_CPUS (1)
Index: b/arch/powerpc/include/asm/topology.h
===
--- a/arch/powerpc/include/asm/topology.h
+++ b/arch/powerpc/include/asm/topology.h
@@ -10,6 +10,12 @@ struct device_node;
#include
+/*
+ * Distance above which we begin to use zone reclaim
+ */
+#define RECLAIM_DISTANCE 20
+
+
static inline int cpu_to_node(int cpu)
{
return numa_cpu_lookup_table[cpu];
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [RFC] powerpc/mpc85xx: add support for suspend mode
* Kumar Gala | 2009-06-03 16:31:42 [-0500]: >On Jun 3, 2009, at 2:54 PM, Sebastian Andrzej Siewior wrote: > >>This patch adds support for the MPC85xx boards to enter the SLEEP >>mode. >>The wake up is done via an external interrupt. >>mpc85xx_enter_sleep() does not clear HID0_SLEEP in resume but it may >>be >>okay since it gets cleared on next NAP/DOZE. >>mpc85xx_enter_sleep() is mostly copied from NAP/DOZE. It does not look >>like it is worth to merge into e500_idle(). I removed the feature >>check >>for NAP/DOZE because it does not look required. It is just there to >>work >>around the BDI. If it is required it could be moved to >>mpc85xx_init_suspend(). >>The suspend.c file contains a sample implementation. I need >>additionally >>to add hooks prio and after mpc85xx_enter_sleep() to toggle a few bits >>in my FPGA. Since the suspend.c is really short I'm not sure if it is >>worth to keep it here and add couple function prototypes or add the >>required bits directly into the board code. >> >>Signed-off-by: Sebastian Andrzej Siewior >>--- >>arch/powerpc/Kconfig |2 +- >>arch/powerpc/kernel/idle_e500.S | 43 >>+ >>arch/powerpc/platforms/85xx/Makefile |1 + >>arch/powerpc/platforms/85xx/suspend.c | 27 >>4 files changed, 72 insertions(+), 1 deletions(-) >>create mode 100644 arch/powerpc/platforms/85xx/suspend.c > >On what system did you test / develop this on? An mpc8544ds based custom board. Non-SMP machine. The only negative thing I've noticed is that the clock stops in SLEEP. The spec says that all clocks will halt so I thing it is okay :) I have no RTC directly on my board so I'm not sure if I have to call something to sync with a RTC or the suspend code is doing this on its own. > >- k Sebastian ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
