* [PATCH] via-mpu: compile without Power Management support
From: Kristian Mueller @ 2005-12-15 3:45 UTC (permalink / raw)
To: linuxppc-dev
[-- Attachment #1: Type: text/plain, Size: 77 bytes --]
Don't check for sleep_in_progress if there is no
Power Management support.
[-- Attachment #2: pmu-without-pm.patch --]
[-- Type: text/x-patch, Size: 817 bytes --]
--- linux/drivers/macintosh/via-pmu.c.orig 2005-12-15 11:28:28.000000000 +0800
+++ linux/drivers/macintosh/via-pmu.c 2005-12-15 10:04:53.000000000 +0800
@@ -2911,8 +2911,10 @@ pmu_ioctl(struct inode * inode, struct f
* the fbdev
*/
case PMU_IOC_GET_BACKLIGHT:
+#if defined(CONFIG_PM) && defined(CONFIG_PPC32)
if (sleep_in_progress)
return -EBUSY;
+#endif /* CONFIG_PM && CONFIG_PPC32 */
error = get_backlight_level();
if (error < 0)
return error;
@@ -2920,8 +2922,10 @@ pmu_ioctl(struct inode * inode, struct f
case PMU_IOC_SET_BACKLIGHT:
{
__u32 value;
+#if defined(CONFIG_PM) && defined(CONFIG_PPC32)
if (sleep_in_progress)
return -EBUSY;
+#endif /* CONFIG_PM && CONFIG_PPC32 */
error = get_user(value, argp);
if (!error)
error = set_backlight_level(value);
^ permalink raw reply
* Re: [PATCH 2.6 1/2] usb/input: Add relayfs support to appletouch driver
From: Dmitry Torokhov @ 2005-12-15 3:43 UTC (permalink / raw)
To: Michael Hanselmann; +Cc: kernel-stuff, linux-kernel, linuxppc-dev, linux-input
In-Reply-To: <20051214233108.GA20127@hansmi.ch>
On Wednesday 14 December 2005 18:31, Michael Hanselmann wrote:
> This patch adds support for relayfs to the appletouch driver to make debugging
> easier.
>
> Signed-off-by: Michael Hanselmann <linux-kernel@hansmi.ch>
> Acked-by: Rene Nussbaumer <linux-kernel@killerfox.forkbomb.ch>
> Acked-by: Johannes Berg <johannes@sipsolutions.net>
> ---
> > Initializing with 0/NULL adds to the size of the image for no reason.
>
> Does gcc automatically initialize them to that value?
Yes, global and static variables are guaranteed to be initialized with 0.
Couple of more comments:
1. I don't think that relayfs parameter worth an entry in sysfs.
2. We should not signal error condition in appletouch_open if
appletouch_relayfs_init fails - the devce is still functioning fine.
Just emit a warning.
3. I must be missing something but I do not see rcb being used anywhere...
The adjusted patch is below. I am still not sure if this really should be
in mainline. Was it ever used?
--
Dmitry
From: Michael Hanselmann <linux-kernel@hansmi.ch>
Input: appletouch - add relayfs support
This patch adds support for relayfs to the appletouch driver to make
debugging easier.
Signed-off-by: Michael Hanselmann <linux-kernel@hansmi.ch>
Acked-by: Rene Nussbaumer <linux-kernel@killerfox.forkbomb.ch>
Acked-by: Johannes Berg <johannes@sipsolutions.net>
Signed-off-by: Dmitry Torokhov <dtor@mail.ru>
---
Documentation/input/appletouch.txt | 2 +
drivers/usb/input/appletouch.c | 61 ++++++++++++++++++++++++++++++++++++-
2 files changed, 62 insertions(+), 1 deletion(-)
Index: work/Documentation/input/appletouch.txt
===================================================================
--- work.orig/Documentation/input/appletouch.txt
+++ work/Documentation/input/appletouch.txt
@@ -77,6 +77,8 @@ full tracing (each sample is being trace
or
echo "1" > /sys/module/appletouch/parameters/debug
+To make debugging easier, the driver also supports the relayfs filesystem.
+
Links:
------
Index: work/drivers/usb/input/appletouch.c
===================================================================
--- work.orig/drivers/usb/input/appletouch.c
+++ work/drivers/usb/input/appletouch.c
@@ -6,6 +6,8 @@
* Copyright (C) 2005 Stelian Pop (stelian@popies.net)
* Copyright (C) 2005 Frank Arnold (frank@scirocco-5v-turbo.de)
* Copyright (C) 2005 Peter Osterlund (petero2@telia.com)
+ * Copyright (C) 2005 Parag Warudkar (parag.warudkar@gmail.com)
+ * Copyright (C) 2005 Michael Hanselmann (linux-kernel@hansmi.ch)
*
* Thanks to Alex Harper <basilisk@foobox.net> for his inputs.
*
@@ -35,6 +37,10 @@
#include <linux/input.h>
#include <linux/usb_input.h>
+#if defined(CONFIG_RELAYFS_FS) || defined(CONFIG_RELAYFS_FS_MODULE)
+#include <linux/relayfs_fs.h>
+#endif
+
/* Apple has powerbooks which have the keyboard with different Product IDs */
#define APPLE_VENDOR_ID 0x05AC
@@ -73,6 +79,7 @@ MODULE_DEVICE_TABLE (usb, atp_table);
/* maximum pressure this driver will report */
#define ATP_PRESSURE 300
+
/*
* multiplication factor for the X and Y coordinates.
* We try to keep the touchpad aspect ratio while still doing only simple
@@ -124,7 +131,7 @@ struct atp {
if (debug) printk(format, ##a); \
} while (0)
-MODULE_AUTHOR("Johannes Berg, Stelian Pop, Frank Arnold");
+MODULE_AUTHOR("Johannes Berg, Stelian Pop, Frank Arnold, Parag Warudkar, Michael Hanselmann");
MODULE_DESCRIPTION("Apple PowerBooks USB touchpad driver");
MODULE_LICENSE("GPL");
@@ -132,6 +139,51 @@ static int debug = 1;
module_param(debug, int, 0644);
MODULE_PARM_DESC(debug, "Activate debugging output");
+#if defined(CONFIG_RELAYFS_FS) || defined(CONFIG_RELAYFS_FS_MODULE)
+static int relayfs;
+module_param(relayfs, int, 0);
+MODULE_PARM_DESC(relayfs, "Activate relayfs support");
+
+static struct rchan *rch;
+
+static inline void atp_relayfs_dump(struct atp *dev)
+{
+ /* "rch" is NULL if relayfs is disabled */
+ if (rch && dev->data)
+ relay_write(rch, dev->data, dev->urb->actual_length);
+}
+
+static int appletouch_relayfs_init(void)
+{
+ if (relayfs) {
+
+ rch = relay_open("atpdata", NULL, 256, 256, NULL);
+ if (!rch) {
+ printk(KERN_WARNING
+ "appletouch: Failed to enable Relayfs.\n");
+ return -ENOMEM;
+ }
+
+ printk(KERN_INFO "appletouch: Relayfs enabled.\n");
+ }
+
+ return 0;
+}
+
+static void appletouch_relayfs_exit(void)
+{
+ if (rch) {
+ printk(KERN_INFO "appletouch: Relayfs disabled\n");
+ relay_close(rch);
+ rch = NULL;
+ }
+}
+#else
+static inline void atp_relayfs_dump(struct atp *dev) { }
+static int appletouch_relayfs_init(void) { return 0; }
+static void appletouch_relayfs_exit(void) { }
+#endif
+
static int atp_calculate_abs(int *xy_sensors, int nb_sensors, int fact,
int *z, int *fingers)
{
@@ -194,6 +246,8 @@ static void atp_complete(struct urb* urb
goto exit;
}
+ atp_relayfs_dump(dev);
+
/* reorder the sensors values */
for (i = 0; i < 8; i++) {
/* X values */
@@ -301,7 +355,10 @@ static int atp_open(struct input_dev *in
if (usb_submit_urb(dev->urb, GFP_ATOMIC))
return -EIO;
+ appletouch_relayfs_init();
+
dev->open = 1;
+
return 0;
}
@@ -310,6 +367,8 @@ static void atp_close(struct input_dev *
struct atp *dev = input->private;
usb_kill_urb(dev->urb);
+ appletouch_relayfs_exit();
+
dev->open = 0;
}
^ permalink raw reply
* Re: [PATCH 2.6 1/2] usb/input: Add relayfs support to appletouch driver
From: Michael Hanselmann @ 2005-12-14 23:31 UTC (permalink / raw)
To: dtor_core; +Cc: kernel-stuff, linux-kernel, linuxppc-dev, linux-input
In-Reply-To: <d120d5000512141404wc86331fo124ebd29b713b07e@mail.gmail.com>
This patch adds support for relayfs to the appletouch driver to make debugging
easier.
Signed-off-by: Michael Hanselmann <linux-kernel@hansmi.ch>
Acked-by: Rene Nussbaumer <linux-kernel@killerfox.forkbomb.ch>
Acked-by: Johannes Berg <johannes@sipsolutions.net>
---
> Initializing with 0/NULL adds to the size of the image for no reason.
Does gcc automatically initialize them to that value?
> Haveing ifdefs in the middle of the code is not too nice. can we
> please have something like this:
> [...]
> Also, would not it be better to initialize relayfs only when device is
> opened because there won't be any data otehrwise?
Sure, both is done in this patch:
diff -rup linux-2.6.15-rc5.orig/Documentation/input/appletouch.txt b/Documentation/input/appletouch.txt
--- linux-2.6.15-rc5.orig/Documentation/input/appletouch.txt 2005-12-13 00:09:24.000000000 +0100
+++ b/Documentation/input/appletouch.txt 2005-12-15 00:09:33.000000000 +0100
@@ -77,6 +77,8 @@ full tracing (each sample is being trace
or
echo "1" > /sys/module/appletouch/parameters/debug
+To make debugging easier, the driver also supports the relayfs filesystem.
+
Links:
------
diff -rup linux-2.6.15-rc5.orig/drivers/usb/input/appletouch.c b/drivers/usb/input/appletouch.c
--- linux-2.6.15-rc5.orig/drivers/usb/input/appletouch.c 2005-12-13 22:44:24.000000000 +0100
+++ b/drivers/usb/input/appletouch.c 2005-12-15 00:25:09.000000000 +0100
@@ -6,6 +6,8 @@
* Copyright (C) 2005 Stelian Pop (stelian@popies.net)
* Copyright (C) 2005 Frank Arnold (frank@scirocco-5v-turbo.de)
* Copyright (C) 2005 Peter Osterlund (petero2@telia.com)
+ * Copyright (C) 2005 Parag Warudkar (parag.warudkar@gmail.com)
+ * Copyright (C) 2005 Michael Hanselmann (linux-kernel@hansmi.ch)
*
* Thanks to Alex Harper <basilisk@foobox.net> for his inputs.
*
@@ -35,6 +37,10 @@
#include <linux/input.h>
#include <linux/usb_input.h>
+#if defined(CONFIG_RELAYFS_FS) || defined(CONFIG_RELAYFS_FS_MODULE)
+#include <linux/relayfs_fs.h>
+#endif
+
/* Apple has powerbooks which have the keyboard with different Product IDs */
#define APPLE_VENDOR_ID 0x05AC
@@ -73,6 +79,7 @@ MODULE_DEVICE_TABLE (usb, atp_table);
/* maximum pressure this driver will report */
#define ATP_PRESSURE 300
+
/*
* multiplication factor for the X and Y coordinates.
* We try to keep the touchpad aspect ratio while still doing only simple
@@ -124,7 +131,7 @@ struct atp {
if (debug) printk(format, ##a); \
} while (0)
-MODULE_AUTHOR("Johannes Berg, Stelian Pop, Frank Arnold");
+MODULE_AUTHOR("Johannes Berg, Stelian Pop, Frank Arnold, Parag Warudkar, Michael Hanselmann");
MODULE_DESCRIPTION("Apple PowerBooks USB touchpad driver");
MODULE_LICENSE("GPL");
@@ -132,6 +139,68 @@ static int debug = 1;
module_param(debug, int, 0644);
MODULE_PARM_DESC(debug, "Activate debugging output");
+#if defined(CONFIG_RELAYFS_FS) || defined(CONFIG_RELAYFS_FS_MODULE)
+static int relayfs;
+module_param(relayfs, int, 0444);
+MODULE_PARM_DESC(relayfs, "Activate relayfs support");
+
+struct rchan *rch;
+struct rchan_callbacks *rcb;
+
+static inline void atp_relayfs_dump(struct atp *dev)
+{
+ /* "rch" is NULL if relayfs is disabled */
+ if (rch && dev->data) {
+ relay_write(rch, dev->data, dev->urb->actual_length);
+ }
+}
+
+static int appletouch_relayfs_init(void)
+{
+ // Make sure the variables aren't initialized to some bogus value when
+ // relayfs is disabled
+ rcb = NULL;
+ rch = NULL;
+
+ if (relayfs) {
+ rcb = kmalloc(sizeof(struct rchan_callbacks), GFP_KERNEL);
+ if (!rcb)
+ return -ENOMEM;
+
+ rcb->subbuf_start = NULL;
+ rcb->buf_mapped = NULL;
+ rcb->buf_unmapped = NULL;
+
+ rch = relay_open("atpdata", NULL, 256, 256, NULL);
+ if (!rch) {
+ kfree(rcb);
+ return -ENOMEM;
+ }
+
+ printk(KERN_INFO "appletouch: Relayfs enabled.\n");
+ }
+
+ return 0;
+}
+
+static void appletouch_relayfs_exit(void)
+{
+ if (rch) {
+ printk(KERN_INFO "appletouch: Relayfs disabled\n");
+ relay_close(rch);
+ rch = NULL;
+ }
+ if (rcb) {
+ kfree(rcb);
+ rcb = NULL;
+ }
+}
+#else
+static inline void atp_relayfs_dump(struct atp *dev) { }
+static int appletouch_relayfs_init(void) { return 0; }
+static void appletouch_relayfs_exit(void) { }
+#endif
+
static int atp_calculate_abs(int *xy_sensors, int nb_sensors, int fact,
int *z, int *fingers)
{
@@ -194,6 +263,8 @@ static void atp_complete(struct urb* urb
goto exit;
}
+ atp_relayfs_dump(dev);
+
/* reorder the sensors values */
for (i = 0; i < 8; i++) {
/* X values */
@@ -297,6 +368,11 @@ exit:
static int atp_open(struct input_dev *input)
{
struct atp *dev = input->private;
+ int result;
+
+ result = appletouch_relayfs_init();
+ if (result < 0)
+ return result;
if (usb_submit_urb(dev->urb, GFP_ATOMIC))
return -EIO;
@@ -310,6 +386,8 @@ static void atp_close(struct input_dev *
struct atp *dev = input->private;
usb_kill_urb(dev->urb);
+ appletouch_relayfs_exit();
+
dev->open = 0;
}
^ permalink raw reply
* Re: illegal instructions / irqs disabled warning
From: Kumar Gala @ 2005-12-14 22:29 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
In-Reply-To: <17312.38814.551675.906916@cargo.ozlabs.ibm.com>
On Dec 14, 2005, at 4:07 PM, Paul Mackerras wrote:
> Johannes Berg writes:
>
>> So I run across this warning:
>> [ 2724.595549] Debug: sleeping function called from invalid
>> context at arch/ppc/kernel/traps.c:528
>> [ 2724.595563] in_atomic():0, irqs_disabled():1
>
> Hmmm. What kernel version is this? I assume you are using ARCH=ppc,
> is that right?
>
>> But here's the actual question:
>> static inline unsigned long __copy_from_user(void *to,
>> const void __user *from, unsigned long size)
>>
>> might_sleep();
>> return __copy_from_user_inatomic(to, from, size);
>>
>>
>> Does that mean __copy_from_user_inatomic isn't actually valid to
>> call in
>> atomic context?
>
> No, it doesn't mean that. However, if the page isn't in memory,
> __copy_from_user_inatomic won't try to bring it in if it has been
> called from an atomic context (i.e. preempt or interrupts disabled).
>
> The real question is why we have interrupts disabled in the illegal
> instruction handler. There was a reason why I wanted interrupts
> disabled on entry to program_check_exception which I don't recall
> clearly at the moment, but I think program_check_exception should be
> doing a local_irq_enable() at some point (and it also shouldn't be
> trying to emulate instructions for the kernel).
I'm glad I'm not the only one thinking that interrupts disabled in
program_check_exception was a little odd. It looks like
AltiVecAssist is handling MSR[EE] properly.
The same issue existed in math-emu which is really just another case
of emulation.
- kumar
^ permalink raw reply
* Re: illegal instructions / irqs disabled warning
From: Paul Mackerras @ 2005-12-14 22:07 UTC (permalink / raw)
To: Johannes Berg; +Cc: linuxppc-dev
In-Reply-To: <1134569118.3875.9.camel@localhost>
Johannes Berg writes:
> So I run across this warning:
> [ 2724.595549] Debug: sleeping function called from invalid context at arch/ppc/kernel/traps.c:528
> [ 2724.595563] in_atomic():0, irqs_disabled():1
Hmmm. What kernel version is this? I assume you are using ARCH=ppc,
is that right?
> But here's the actual question:
> static inline unsigned long __copy_from_user(void *to,
> const void __user *from, unsigned long size)
>
> might_sleep();
> return __copy_from_user_inatomic(to, from, size);
>
>
> Does that mean __copy_from_user_inatomic isn't actually valid to call in
> atomic context?
No, it doesn't mean that. However, if the page isn't in memory,
__copy_from_user_inatomic won't try to bring it in if it has been
called from an atomic context (i.e. preempt or interrupts disabled).
The real question is why we have interrupts disabled in the illegal
instruction handler. There was a reason why I wanted interrupts
disabled on entry to program_check_exception which I don't recall
clearly at the moment, but I think program_check_exception should be
doing a local_irq_enable() at some point (and it also shouldn't be
trying to emulate instructions for the kernel).
Paul.
^ permalink raw reply
* Re: [PATCH 2.6 1/2] usb/input: Add relayfs support to appletouch driver
From: Dmitry Torokhov @ 2005-12-14 22:04 UTC (permalink / raw)
To: Michael Hanselmann; +Cc: kernel-stuff, linux-kernel, linuxppc-dev, linux-input
In-Reply-To: <20051214213923.GB17548@hansmi.ch>
Hi,
On 12/14/05, Michael Hanselmann <linux-kernel@hansmi.ch> wrote:
> *
> + * Nov 2005 - Parag Warudkar
> + * o Added ability to export data via relayfs
> + *
> + * Nov/Dec 2005 - Michael Hanselmann
> + * o Compile relayfs support only if enabled in the kernel
> + * o Enable relayfs only if requested by the user
> + *
We have an SCM, not need to have a changelog in the driver.
>
> +#if defined(CONFIG_RELAYFS_FS) || defined(CONFIG_RELAYFS_FS_MODULE)
> +struct rchan* rch =3D NULL;
> +struct rchan_callbacks* rcb =3D NULL;
Initializing with 0/NULL adds to the size of the image for no reason.
>
> +#if defined(CONFIG_RELAYFS_FS) || defined(CONFIG_RELAYFS_FS_MODULE)
> +static int relayfs =3D 0;
Same here.
> +module_param(relayfs, int, 0444);
> +MODULE_PARM_DESC(relayfs, "Activate relayfs support");
> +#endif
> +
> static int atp_calculate_abs(int *xy_sensors, int nb_sensors, int fact,
> int *z, int *fingers)
> {
> @@ -194,6 +219,13 @@ static void atp_complete(struct urb* urb
> goto exit;
> }
>
> +#if defined(CONFIG_RELAYFS_FS) || defined(CONFIG_RELAYFS_FS_MODULE)
> + /* "rch" is NULL if relayfs is not enabled */
> + if (rch && dev->data) {
> + relay_write(rch, dev->data, dev->urb->actual_length);
> + }
> +#endif
> +
Haveing ifdefs in the middle of the code is not too nice. can we
please have something like this:
#if defined(CONFIG_RELAYFS_FS) || defined(CONFIG_RELAYFS_FS_MODULE)
static inline void appletouch_relayfs_dump(...)
{
...
}
static int appletouch_relayfs_init(void)
{
...
}
static void appletouch_relayfs_exit()
{
...
}
#else
static inline void appletouch_relayfs_dump(...) { }
static int appletouch_relayfs_init(void) { return 0; }
static void appletouch_relayfs_exit() { }
#endif
Also, would not it be better to initialize relayfs only when device is
opened because there won't be any data otehrwise?
--
Dmitry
^ permalink raw reply
* Re: illegal instructions / irqs disabled warning
From: Andy Fleming @ 2005-12-14 21:46 UTC (permalink / raw)
To: Johannes Berg; +Cc: linuxppc-dev
In-Reply-To: <1134569118.3875.9.camel@localhost>
On Dec 14, 2005, at 08:05, Johannes Berg wrote:
>
> Does that mean __copy_from_user_inatomic isn't actually valid to
> call in
> atomic context? Or is this only so that kernel developers that use
> powerpc see the bugs their code would have on other platforms? The
> magic
> in get_user_asm thoroughly confuses me.
>
> [Somehow I got sidetracked. I only wanted to look at implementing
> backtrace support for oprofile...]
What platform is this on? The copy from user stuff is a bit out of
my area of expertise, but I've got an implementation of backtrace for
oprofile running on 85xx. Mostly, it's just a hacked up version of
the ppc64 patch that was floating around.
Andy
^ permalink raw reply
* Re: [PATCH 2.6 1/2] usb/input: Add relayfs support to appletouch driver
From: Michael Hanselmann @ 2005-12-14 21:39 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-input, linuxppc-dev, kernel-stuff, linux-kernel
In-Reply-To: <1134568620.3875.6.camel@localhost>
This patch adds support for relayfs to the appletouch driver to make
debugging easier.
Signed-off-by: Michael Hanselmann <linux-kernel@hansmi.ch>
Acked-by: Rene Nussbaumer <linux-kernel@killerfox.forkbomb.ch>
Acked-by: Johannes Berg <johannes@sipsolutions.net>
---
Updated to make the relayfs parameter readonly.
diff -Npur linux-2.6.15-rc5.orig/Documentation/input/appletouch.txt linux-2.6.15-rc5/Documentation/input/appletouch.txt
--- linux-2.6.15-rc5.orig/Documentation/input/appletouch.txt 2005-12-13 00:09:24.000000000 +0100
+++ linux-2.6.15-rc5/Documentation/input/appletouch.txt 2005-12-13 21:28:26.000000000 +0100
@@ -77,6 +78,8 @@ full tracing (each sample is being trace
or
echo "1" > /sys/module/appletouch/parameters/debug
+To make debugging easier, the driver also supports the relayfs filesystem.
+
Links:
------
diff -Npur linux-2.6.15-rc5.orig/drivers/usb/input/appletouch.txt linux-2.6.15-rc5/drivers/usb/input/appletouch.txt
--- linux-2.6.15-rc5.orig/drivers/usb/input/appletouch.c 2005-12-13 00:09:24.000000000 +0100
+++ linux-2.6.15-rc5/drivers/usb/input/appletouch.c 2005-12-13 22:41:28.000000000 +0100
@@ -6,9 +6,18 @@
* Copyright (C) 2005 Stelian Pop (stelian@popies.net)
* Copyright (C) 2005 Frank Arnold (frank@scirocco-5v-turbo.de)
* Copyright (C) 2005 Peter Osterlund (petero2@telia.com)
+ * Copyright (C) 2005 Parag Warudkar (parag.warudkar@gmail.com)
+ * Copyright (C) 2005 Michael Hanselmann (linux-kernel@hansmi.ch)
*
* Thanks to Alex Harper <basilisk@foobox.net> for his inputs.
*
+ * Nov 2005 - Parag Warudkar
+ * o Added ability to export data via relayfs
+ *
+ * Nov/Dec 2005 - Michael Hanselmann
+ * o Compile relayfs support only if enabled in the kernel
+ * o Enable relayfs only if requested by the user
+ *
* 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
@@ -35,6 +44,10 @@
#include <linux/input.h>
#include <linux/usb_input.h>
+#if defined(CONFIG_RELAYFS_FS) || defined(CONFIG_RELAYFS_FS_MODULE)
+#include <linux/relayfs_fs.h>
+#endif
+
/* Apple has powerbooks which have the keyboard with different Product IDs */
#define APPLE_VENDOR_ID 0x05AC
@@ -57,6 +70,11 @@ static struct usb_device_id atp_table []
};
MODULE_DEVICE_TABLE (usb, atp_table);
+#if defined(CONFIG_RELAYFS_FS) || defined(CONFIG_RELAYFS_FS_MODULE)
+struct rchan* rch = NULL;
+struct rchan_callbacks* rcb = NULL;
+#endif
+
/* size of a USB urb transfer */
#define ATP_DATASIZE 81
@@ -73,6 +91,7 @@ MODULE_DEVICE_TABLE (usb, atp_table);
/* maximum pressure this driver will report */
#define ATP_PRESSURE 300
+
/*
* multiplication factor for the X and Y coordinates.
* We try to keep the touchpad aspect ratio while still doing only simple
@@ -124,7 +143,7 @@ struct atp {
if (debug) printk(format, ##a); \
} while (0)
-MODULE_AUTHOR("Johannes Berg, Stelian Pop, Frank Arnold");
+MODULE_AUTHOR("Johannes Berg, Stelian Pop, Frank Arnold, Parag Warudkar, Michael Hanselmann");
MODULE_DESCRIPTION("Apple PowerBooks USB touchpad driver");
MODULE_LICENSE("GPL");
@@ -132,6 +151,12 @@ static int debug = 1;
module_param(debug, int, 0644);
MODULE_PARM_DESC(debug, "Activate debugging output");
+#if defined(CONFIG_RELAYFS_FS) || defined(CONFIG_RELAYFS_FS_MODULE)
+static int relayfs = 0;
+module_param(relayfs, int, 0444);
+MODULE_PARM_DESC(relayfs, "Activate relayfs support");
+#endif
+
static int atp_calculate_abs(int *xy_sensors, int nb_sensors, int fact,
int *z, int *fingers)
{
@@ -194,6 +219,13 @@ static void atp_complete(struct urb* urb
goto exit;
}
+#if defined(CONFIG_RELAYFS_FS) || defined(CONFIG_RELAYFS_FS_MODULE)
+ /* "rch" is NULL if relayfs is not enabled */
+ if (rch && dev->data) {
+ relay_write(rch, dev->data, dev->urb->actual_length);
+ }
+#endif
+
/* reorder the sensors values */
for (i = 0; i < 8; i++) {
/* X values */
@@ -463,11 +495,43 @@ static struct usb_driver atp_driver = {
static int __init atp_init(void)
{
+#if defined(CONFIG_RELAYFS_FS) || defined(CONFIG_RELAYFS_FS_MODULE)
+ rcb = NULL;
+ rch = NULL;
+
+ if (relayfs) {
+ rcb = kmalloc(sizeof(struct rchan_callbacks), GFP_KERNEL);
+ if (!rcb)
+ return -ENOMEM;
+
+ rcb->subbuf_start = NULL;
+ rcb->buf_mapped = NULL;
+ rcb->buf_unmapped = NULL;
+
+ rch = relay_open("atpdata", NULL, 256, 256, NULL);
+ if (!rch) {
+ kfree(rcb);
+ return -ENOMEM;
+ }
+
+ printk("appletouch: Relayfs enabled.\n");
+ } else {
+ printk("appletouch: Relayfs disabled.\n");
+ }
+#endif
+
return usb_register(&atp_driver);
}
static void __exit atp_exit(void)
{
+#if defined(CONFIG_RELAYFS_FS) || defined(CONFIG_RELAYFS_FS_MODULE)
+ if(rch)
+ relay_close(rch);
+ if(rcb)
+ kfree(rcb);
+#endif
+
usb_deregister(&atp_driver);
}
^ permalink raw reply
* Re: 8260 ethernet driver multicast problem
From: Andy Fleming @ 2005-12-14 20:13 UTC (permalink / raw)
To: Pantelis Antoniou; +Cc: Robin Mathew, linuxppc-embedded
In-Reply-To: <43A03821.6040206@intracom.gr>
On Dec 14, 2005, at 09:20, Pantelis Antoniou wrote:
> Robin Mathew wrote:
>> Hi,
>> I was encountering a problem with the receipt of multicast packets
>> from eth
>> interface in 8260 platform. The issue was traced to the fcc_enet.c
>> driver. A
>> stray return in the set_multicast_list function was the culprit.
>> The following is the changes that I have made-
>> Index: fcc_enet.c
>> @@ -1488,7 +1488,6 @@
>> cep = (struct fcc_enet_private *)dev->priv;
>> -return;
>> /* Get pointer to FCC area in parameter RAM.
>> */
>> ep = (fcc_enet_t *)dev->base_addr;
>> Can you please tell me whether there is any issue with setting the
>> driver in
>> multicast or promiscous mode. Was this change deliberately done or
>> is it
>> really a bug?
>> Thanks in advance,
>> Robin
>
> Robin, what's the kernel version you're using?
>
> If you're using 2.6 there's a brand new driver you can use.
Has 8260 platform support been pushed out yet?
^ permalink raw reply
* Re: 8260 ethernet driver multicast problem
From: Pantelis Antoniou @ 2005-12-14 15:20 UTC (permalink / raw)
To: Robin Mathew; +Cc: linuxppc-embedded
In-Reply-To: <5b74ec4d0512140628y42986bc0h2f107e788dd115b6@mail.gmail.com>
Robin Mathew wrote:
> Hi,
> I was encountering a problem with the receipt of multicast packets from eth
> interface in 8260 platform. The issue was traced to the fcc_enet.c driver. A
> stray return in the set_multicast_list function was the culprit.
>
> The following is the changes that I have made-
>
> Index: fcc_enet.c
> @@ -1488,7 +1488,6 @@
>
> cep = (struct fcc_enet_private *)dev->priv;
>
> -return;
> /* Get pointer to FCC area in parameter RAM.
> */
> ep = (fcc_enet_t *)dev->base_addr;
>
>
> Can you please tell me whether there is any issue with setting the driver in
> multicast or promiscous mode. Was this change deliberately done or is it
> really a bug?
>
> Thanks in advance,
> Robin
>
Robin, what's the kernel version you're using?
If you're using 2.6 there's a brand new driver you can use.
Regards
Pantelis
^ permalink raw reply
* Re: illegal instructions / irqs disabled warning
From: Johannes Berg @ 2005-12-14 15:13 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev
In-Reply-To: <D5163F2D-A7C9-47E2-BE8D-E291B6C98A40@kernel.crashing.org>
[-- Attachment #1: Type: text/plain, Size: 635 bytes --]
On Wed, 2005-12-14 at 09:07 -0600, Kumar Gala wrote:
> It is, we just need to ensure that the user page we are copying from
> is in memory.
So in the interrupt handler we need to ensure this and then call
__copy_from_user_inatomic instead?
> But, now that I go back and look at your log message, its odd. I
> didn't expect ProgramExceptions to be executed with the MSR[EE] = 0.
> Now, I'm wondering why that is.
Hm. I can tell you what I did: Something like
mtspr 940, r3
in userland :)
Not sure if it was 940, might have been one of the other registers
reserved for performance monitoring.
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 832 bytes --]
^ permalink raw reply
* Re: illegal instructions / irqs disabled warning
From: Kumar Gala @ 2005-12-14 15:07 UTC (permalink / raw)
To: Johannes Berg; +Cc: linuxppc-dev
In-Reply-To: <1134571773.3875.12.camel@localhost>
On Dec 14, 2005, at 8:49 AM, Johannes Berg wrote:
> On Wed, 2005-12-14 at 08:41 -0600, Kumar Gala wrote:
>
>> Its highly likely, but not guaranteed on all systems. In truth this
>> is most likely a bug.
>
> Ok.
>
>>> But here's the actual question:
>>> static inline unsigned long __copy_from_user(void *to,
>>> const void __user *from, unsigned long size)
>>> {
>>> might_sleep();
>>> return __copy_from_user_inatomic(to, from, size);
>>> }
>>>
>>> Does that mean __copy_from_user_inatomic isn't actually valid to
>>> call in
>>> atomic context? Or is this only so that kernel developers that use
>>> powerpc see the bugs their code would have on other platforms? The
>>> magic
>>> in get_user_asm thoroughly confuses me.
>>
>> What do you mean atomic context? Not exactly sure what your asking
>> about.
>
> Well, the above code loading the instruction that faulted is called
> from
> the interrupt context where the kernel tries to fix it up. If that
> instruction is not in memory for whatever reason, then it shouldn't
> try
> to fix it up bug kill the program with SIGILL or SIGSEGV or
> whatever...
> This is what I came from, and tried looking into how to implement
> that.
> But then I ran across the code in __copy_from_user which just calls
> __copy_from_user_inatomic so I'm wondering if it is actually
> possible to
> safely copy data (the instruction) from user space in an interrupt.
It is, we just need to ensure that the user page we are copying from
is in memory.
But, now that I go back and look at your log message, its odd. I
didn't expect ProgramExceptions to be executed with the MSR[EE] = 0.
Now, I'm wondering why that is.
- kumar
^ permalink raw reply
* Re: illegal instructions / irqs disabled warning
From: Johannes Berg @ 2005-12-14 14:49 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev
In-Reply-To: <66D10776-B8F2-48E4-9B96-CA37323B5799@kernel.crashing.org>
[-- Attachment #1: Type: text/plain, Size: 1407 bytes --]
On Wed, 2005-12-14 at 08:41 -0600, Kumar Gala wrote:
> Its highly likely, but not guaranteed on all systems. In truth this
> is most likely a bug.
Ok.
> > But here's the actual question:
> > static inline unsigned long __copy_from_user(void *to,
> > const void __user *from, unsigned long size)
> > {
> > might_sleep();
> > return __copy_from_user_inatomic(to, from, size);
> > }
> >
> > Does that mean __copy_from_user_inatomic isn't actually valid to
> > call in
> > atomic context? Or is this only so that kernel developers that use
> > powerpc see the bugs their code would have on other platforms? The
> > magic
> > in get_user_asm thoroughly confuses me.
>
> What do you mean atomic context? Not exactly sure what your asking
> about.
Well, the above code loading the instruction that faulted is called from
the interrupt context where the kernel tries to fix it up. If that
instruction is not in memory for whatever reason, then it shouldn't try
to fix it up bug kill the program with SIGILL or SIGSEGV or whatever...
This is what I came from, and tried looking into how to implement that.
But then I ran across the code in __copy_from_user which just calls
__copy_from_user_inatomic so I'm wondering if it is actually possible to
safely copy data (the instruction) from user space in an interrupt.
Thanks,
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 832 bytes --]
^ permalink raw reply
* Re: illegal instructions / irqs disabled warning
From: Kumar Gala @ 2005-12-14 14:41 UTC (permalink / raw)
To: Johannes Berg; +Cc: linuxppc-dev
In-Reply-To: <1134569118.3875.9.camel@localhost>
On Dec 14, 2005, at 8:05 AM, Johannes Berg wrote:
> So I run across this warning:
> [ 2724.595549] Debug: sleeping function called from invalid context
> at arch/ppc/kernel/traps.c:528
> [ 2724.595563] in_atomic():0, irqs_disabled():1
> [ 2724.595568] Call trace:
> [ 2724.595573] [c001fe54] __might_sleep+0xd4/0xf0
> [ 2724.595592] [c0005ad8] program_check_exception+0xb8/0x520
> [ 2724.595606] [c0004f04] ret_from_except_full+0x0/0x4c
>
> when I wrote a program calling illegal instructions. I then checked
> out
> why this happened and the cause is the might_sleep() here:
>
> #define __get_user_check(x, ptr,
> size) \
> ({
> \
> long __gu_err = -
> EFAULT; \
> unsigned long __gu_val =
> 0; \
> const __typeof__(*(ptr)) __user *__gu_addr =
> (ptr); \
> might_sleep
> (); \
> ...
>
> I then figured I could use __copy_from_user_inatomic to access the
> instruction word to fix this (as far as I can tell only the warning is
> annoying, because the instruction already failed at that point so it
> must be in memory, right?)
Its highly likely, but not guaranteed on all systems. In truth this
is most likely a bug.
> But here's the actual question:
> static inline unsigned long __copy_from_user(void *to,
> const void __user *from, unsigned long size)
> {
> might_sleep();
> return __copy_from_user_inatomic(to, from, size);
> }
>
> Does that mean __copy_from_user_inatomic isn't actually valid to
> call in
> atomic context? Or is this only so that kernel developers that use
> powerpc see the bugs their code would have on other platforms? The
> magic
> in get_user_asm thoroughly confuses me.
What do you mean atomic context? Not exactly sure what your asking
about.
- kumar
^ permalink raw reply
* Re: [SOLVED] Re: pq2_find_bridges hangs system
From: Kumar Gala @ 2005-12-14 14:30 UTC (permalink / raw)
To: Vitaly Bordug; +Cc: linuxppc-embedded list, Alex BASTOS
In-Reply-To: <43A028DB.5090906@ru.mvista.com>
On Dec 14, 2005, at 8:14 AM, Vitaly Bordug wrote:
> Alex BASTOS wrote:
>> Vitaly,
>>> Maybe, but I guess more correct is to deal with USB->PCI
>>> dependency..
>>> Is it really needed(I am not USB expert)?
>> Neither am I. I guess for this Host Controler it is not needed at
>> HW level, but I am not sure why it is still required by the SW.
>>>> 3) I have seen that from u-boot, a reset occurs when I read
>>>> Internal
>>>> Memory at offset 0x10904 (PCI CFG_DATA). From BDI, when I do the
>>>> same
>>>> all PCI section on IM becomes zero. Is this a known behaviour?
>>>> May this
>>>> reflect a hardware problem?
>>>>
>>> Sounds weird
>> Here is the problem. The cause for this weird behaviour is that I
>> had PCI_ARBITER_EN_ disabled. So, a HW problem at the end.
>> I had disabled it trying to reduce power compsumption due to the PCI,
>> as I am not going to use it. It seems it is not possible that way.
>> Any idea how to get this done?
I'm guessing you dont have anything else doing arbitration on the bus.
- kumar
^ permalink raw reply
* 8260 ethernet driver multicast problem
From: Robin Mathew @ 2005-12-14 14:28 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 685 bytes --]
Hi,
I was encountering a problem with the receipt of multicast packets from eth
interface in 8260 platform. The issue was traced to the fcc_enet.c driver. A
stray return in the set_multicast_list function was the culprit.
The following is the changes that I have made-
Index: fcc_enet.c
@@ -1488,7 +1488,6 @@
cep = (struct fcc_enet_private *)dev->priv;
-return;
/* Get pointer to FCC area in parameter RAM.
*/
ep = (fcc_enet_t *)dev->base_addr;
Can you please tell me whether there is any issue with setting the driver in
multicast or promiscous mode. Was this change deliberately done or is it
really a bug?
Thanks in advance,
Robin
[-- Attachment #2: Type: text/html, Size: 864 bytes --]
^ permalink raw reply
* Re: [SOLVED] Re: pq2_find_bridges hangs system
From: Vitaly Bordug @ 2005-12-14 14:14 UTC (permalink / raw)
To: Alex BASTOS; +Cc: linuxppc-embedded list
In-Reply-To: <1134569602.43a0288234662@webmail.televes.com:443>
Alex BASTOS wrote:
> Vitaly,
>
>> Maybe, but I guess more correct is to deal with USB->PCI dependency..
>> Is it really needed(I am not USB expert)?
>
> Neither am I. I guess for this Host Controler it is not needed at
> HW level, but I am not sure why it is still required by the SW.
>
>
>>> 3) I have seen that from u-boot, a reset occurs when I read Internal
>>> Memory at offset 0x10904 (PCI CFG_DATA). From BDI, when I do the same
>>> all PCI section on IM becomes zero. Is this a known behaviour? May this
>>> reflect a hardware problem?
>>>
>> Sounds weird
>
> Here is the problem. The cause for this weird behaviour is that I
> had PCI_ARBITER_EN_ disabled. So, a HW problem at the end.
> I had disabled it trying to reduce power compsumption due to the PCI,
> as I am not going to use it. It seems it is not possible that way.
> Any idea how to get this done?
>
Well, I guess the best you can do now - just use custom tree. I'll try to find
good solution for such a case (PCI required by deps but not hw) next time I'll touch PCI.
>>> In conclusion, 1) solves my "must", a working board (without PCI).
>>> But I still would like to know what am I doing so wrong with this.
>>>
>> IMHO ability to disable PCI_8260 while PCI is on might be confusing, at least
>> for upstream.
>
> You are right.
>
> Thanks so much for your help.
>
> Best regards,
>
> Alex
>
>
--
Sincerely,
Vitaly
^ permalink raw reply
* illegal instructions / irqs disabled warning
From: Johannes Berg @ 2005-12-14 14:05 UTC (permalink / raw)
To: linuxppc-dev
[-- Attachment #1: Type: text/plain, Size: 1832 bytes --]
So I run across this warning:
[ 2724.595549] Debug: sleeping function called from invalid context at arch/ppc/kernel/traps.c:528
[ 2724.595563] in_atomic():0, irqs_disabled():1
[ 2724.595568] Call trace:
[ 2724.595573] [c001fe54] __might_sleep+0xd4/0xf0
[ 2724.595592] [c0005ad8] program_check_exception+0xb8/0x520
[ 2724.595606] [c0004f04] ret_from_except_full+0x0/0x4c
when I wrote a program calling illegal instructions. I then checked out
why this happened and the cause is the might_sleep() here:
#define __get_user_check(x, ptr, size) \
({ \
long __gu_err = -EFAULT; \
unsigned long __gu_val = 0; \
const __typeof__(*(ptr)) __user *__gu_addr = (ptr); \
might_sleep(); \
...
I then figured I could use __copy_from_user_inatomic to access the
instruction word to fix this (as far as I can tell only the warning is
annoying, because the instruction already failed at that point so it
must be in memory, right?)
But here's the actual question:
static inline unsigned long __copy_from_user(void *to,
const void __user *from, unsigned long size)
{
might_sleep();
return __copy_from_user_inatomic(to, from, size);
}
Does that mean __copy_from_user_inatomic isn't actually valid to call in
atomic context? Or is this only so that kernel developers that use
powerpc see the bugs their code would have on other platforms? The magic
in get_user_asm thoroughly confuses me.
[Somehow I got sidetracked. I only wanted to look at implementing
backtrace support for oprofile...]
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 832 bytes --]
^ permalink raw reply
* Re: [PATCH 2.6 1/2] usb/input: Add relayfs support to appletouch driver
From: Johannes Berg @ 2005-12-14 13:57 UTC (permalink / raw)
To: Michael Hanselmann; +Cc: linux-input, linuxppc-dev, kernel-stuff, linux-kernel
In-Reply-To: <20051213223659.GB20017@hansmi.ch>
[-- Attachment #1: Type: text/plain, Size: 194 bytes --]
On Tue, 2005-12-13 at 23:36 +0100, Michael Hanselmann wrote:
> +module_param(relayfs, int, 0644);
Why do you make the parameter writable if writing it doesn't change
anything?
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 832 bytes --]
^ permalink raw reply
* [SOLVED] Re: pq2_find_bridges hangs system
From: Alex BASTOS @ 2005-12-14 14:13 UTC (permalink / raw)
To: Vitaly Bordug; +Cc: linuxppc-embedded list
In-Reply-To: <43A0021E.7030406@ru.mvista.com>
Vitaly,
> Maybe, but I guess more correct is to deal with USB->PCI dependency..
> Is it really needed(I am not USB expert)?
Neither am I. I guess for this Host Controler it is not needed at
HW level, but I am not sure why it is still required by the SW.
> > 3) I have seen that from u-boot, a reset occurs when I read Internal
> > Memory at offset 0x10904 (PCI CFG_DATA). From BDI, when I do the same
> > all PCI section on IM becomes zero. Is this a known behaviour? May this
> > reflect a hardware problem?
> >
> Sounds weird
Here is the problem. The cause for this weird behaviour is that I
had PCI_ARBITER_EN_ disabled. So, a HW problem at the end.
I had disabled it trying to reduce power compsumption due to the PCI,
as I am not going to use it. It seems it is not possible that way.
Any idea how to get this done?
> > In conclusion, 1) solves my "must", a working board (without PCI).
> > But I still would like to know what am I doing so wrong with this.
> >
> IMHO ability to disable PCI_8260 while PCI is on might be confusing, at least
> for upstream.
You are right.
Thanks so much for your help.
Best regards,
Alex
^ permalink raw reply
* Re: pq2_find_bridges hangs system
From: Vitaly Bordug @ 2005-12-14 11:29 UTC (permalink / raw)
To: Alex BASTOS; +Cc: linuxppc-embedded list
In-Reply-To: <1134555662.439ff20e6e812@webmail.televes.com:443>
Alex BASTOS wrote:
> Vitaly,
>
> So, I have arrived to some conclusions.
>
> 1) With my previous kernel version (2.6.11) I had no problems
> because it had CONFIG_PCI_8260 and CONFIG_PPC_INDIRECT_PCI unset.
> So I think no effective read/write operation was executed, and so
> that, no Machine Check.
>
> In fact, this is the configuration I would prefer for my board. I have
> to set CONFIG_PCI for enabling USB, but I don't want all the HW stuff
> of the PCI. I can get these also with 2.6.15 if I modify Kconfig, to
> allow me to unset PCI_8260 (and then PPC_INDIRECT_PCI) for my board.
> With that, the problem dissapears and I can boot 2.6.15.
>
> Shouldn't this (PCI_8260) be visible from xconfig for those like me
> who wants USB (=> CONFIG_PCI) but don't really have any PCI device?
>
Maybe, but I guess more correct is to deal with USB->PCI dependency..
Is it really needed(I am not USB expert)?
> 2) Although I am using Uboot 1.1.4, it is not top of git. I have
> found your changes to support PCI on 8272ADS for u-boot are not
> still applied on the version i am using. So, could this be causing
> the problem? Is there any configuration done in u-boot required by
> the PCI on the linux kernel to boot (BR3,OR3, EMR, ...)?
>
> I should say that, on ADS, I have an older version of u-boot, 1.1.2,
> and it boots OK.
>
My changes do not required for kernel to deal with PCI, that patch just allows access to PCI in
U-Boot. Hence I might be useful if you'll head for resolving this issue which I guess unlikely to happen
> 3) I have seen that from u-boot, a reset occurs when I read Internal
> Memory at offset 0x10904 (PCI CFG_DATA). From BDI, when I do the same
> all PCI section on IM becomes zero. Is this a known behaviour? May this
> reflect a hardware problem?
>
Sounds weird
> In conclusion, 1) solves my "must", a working board (without PCI).
> But I still would like to know what am I doing so wrong with this.
>
IMHO ability to disable PCI_8260 while PCI is on might be confusing, at least for upstream.
> Best regards,
>
> Alex
>
> Citando Alex BASTOS <alebas@televes.com>:
>
>> Vitaly,
>>
>> It didn't work. So I will check pq2ads_setup_pci to check if
>> some board specific issue is affected.
>>
>> I will say you if I find anything
>>
>> Thanks
>>
>> Alex.
>>
>
>
--
Sincerely,
Vitaly
^ permalink raw reply
* Re: pq2_find_bridges hangs system
From: Alex BASTOS @ 2005-12-14 10:21 UTC (permalink / raw)
To: Alex BASTOS; +Cc: linuxppc-embedded list
Vitaly,
So, I have arrived to some conclusions.
1) With my previous kernel version (2.6.11) I had no problems
because it had CONFIG_PCI_8260 and CONFIG_PPC_INDIRECT_PCI unset.
So I think no effective read/write operation was executed, and so
that, no Machine Check.
In fact, this is the configuration I would prefer for my board. I have
to set CONFIG_PCI for enabling USB, but I don't want all the HW stuff
of the PCI. I can get these also with 2.6.15 if I modify Kconfig, to
allow me to unset PCI_8260 (and then PPC_INDIRECT_PCI) for my board.
With that, the problem dissapears and I can boot 2.6.15.
Shouldn't this (PCI_8260) be visible from xconfig for those like me
who wants USB (=> CONFIG_PCI) but don't really have any PCI device?
2) Although I am using Uboot 1.1.4, it is not top of git. I have
found your changes to support PCI on 8272ADS for u-boot are not
still applied on the version i am using. So, could this be causing
the problem? Is there any configuration done in u-boot required by
the PCI on the linux kernel to boot (BR3,OR3, EMR, ...)?
I should say that, on ADS, I have an older version of u-boot, 1.1.2,
and it boots OK.
3) I have seen that from u-boot, a reset occurs when I read Internal
Memory at offset 0x10904 (PCI CFG_DATA). From BDI, when I do the same
all PCI section on IM becomes zero. Is this a known behaviour? May this
reflect a hardware problem?
In conclusion, 1) solves my "must", a working board (without PCI).
But I still would like to know what am I doing so wrong with this.
Best regards,
Alex
Citando Alex BASTOS <alebas@televes.com>:
> Vitaly,
>
> It didn't work. So I will check pq2ads_setup_pci to check if
> some board specific issue is affected.
>
> I will say you if I find anything
>
> Thanks
>
> Alex.
>
^ permalink raw reply
* SPI driver for 82xx
From: Dmytro Bablinyuk @ 2005-12-14 7:13 UTC (permalink / raw)
To: linuxppc-embedded
Is anywhere available SPI driver (SPI peripheral) for 82xx for 2.6.x
kernel?
I will appreciate any reference or suggestion.
Thank you
Dmytro
^ permalink raw reply
* Re: MPC8245 with its internal UART
From: HappyPhot @ 2005-12-14 6:36 UTC (permalink / raw)
To: hs, linuxppc-embedded
In-Reply-To: <AHEILKONAKAEJPHNMOPNIEDBCEAA.hs@denx.de>
Hi,
I've tried this (CPC45_config) on Denx Kernel 2.4.25,
and my serial console works now. Thank you very much.
Is there any similar platform for kernel 2.6 ? (i.e. MPC8245
with its internal UART )
thank you,
/HappyPhot
>
>> Who can tell me which flatform is similar to mine ? I've tried
>> "make sandpoint_defconfig", but seems not the right one.
>
> If you want to use Linux 2.4.25, you can try CPC45_defconfig
> from the Denx Kernel ...
^ permalink raw reply
* "make xconfig" error (2.4.25 devel)
From: HappyPhot @ 2005-12-14 3:41 UTC (permalink / raw)
To: linuxppc-embedded
Hello,
I am trying "linuxppc_2_4_devel-2005-10-25-1440".
The "make xconfig" seems not work. ("make menuconfig" is ok)
It shows :
======================================
....
./tkparse < ../arch/ppc/config.in >> kconfig.tk
arch/ppc/8xx_io/Config.in: 312: unknown define_bool value
make[1]: *** [kconfig.tk] Error 1
....
======================================
Does this version support "make xconfig" ?
thank you,
/HappyPhot
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox