* BDI2000 help needed:how to driver LH28F016SC flash?
From: zengshuai @ 2005-12-26 8:17 UTC (permalink / raw)
To: ppc
Our board is PQ2FADS_ZU,and we bought a BDI2000 to debug it.
There is a LH28F016SC flash in the PQ2FADS_ZU board.
I tested the default .cfg (for 8260ads) to driver LH28F016SC flash,but it didn't work.
How to modify the .cfg file? thanks.
------------------------------
我现在使用Sogou.com的2G邮箱了，你也来试试吧!
http://mail.sogou.com/recommend/sogoumail_invite_reg1.jsp?from=sogouinvitation&s_EMAIL=zengshuai%40sogou.com&username=linuxppc-embedded&FullName=linuxppc-embedded&Email=linuxppc-embedded%40ozlabs.org&verify=755eff4e640bdcfc57d93cbd8b0a9cb7
^ permalink raw reply
* Re: [PATCH/RFC?] usb/input: Add support for fn key on Apple PowerBooks
From: Benjamin Herrenschmidt @ 2005-12-26 5:46 UTC (permalink / raw)
To: Dmitry Torokhov
Cc: linux-kernel, linux-kernel, linuxppc-dev, Vojtech Pavlik,
linux-input
In-Reply-To: <200512252304.32830.dtor_core@ameritech.net>
On Sun, 2005-12-25 at 23:04 -0500, Dmitry Torokhov wrote:
> On Sunday 25 December 2005 16:20, Michael Hanselmann wrote:
> > This patch adds a basic input hook support to usbhid because the quirks
> > method is outrunning the available bits. A hook for the Fn and Numlock
> > keys on Apple PowerBooks is included.
>
> Well, we have used 11 out of 32 available bits so there still some
> reserves. My concern is that your implementation allows only one
> hook to be installed while with quirks you can have several of them
> active per device.
I haven't looked at the details so I can't comment much there, though
the hook has the interest of making it possible to have it in a module
that gets separately loaded if necessary, no ? Maybe the driver could
maintain a list of hooks ?
> As far as the hook itself - i have that feeling that it should not be
> done in kernel but via a keymap.
While I understand your feeling, it's a bit annoying in this specific
case because previous models did this in hardware and all mac keymaps
already account for that. Knowing how nasty it has been to get mac
keymaps updated and in a good shape, and to get distros to properly get
them, it makes a lot of sense to have this small hook in the kernel that
makes the USB keyboard behave exactly like the older ADB couterparts.
Ben.
^ permalink raw reply
* Re: [PATCH/RFC?] usb/input: Add support for fn key on Apple PowerBooks
From: Dmitry Torokhov @ 2005-12-26 4:04 UTC (permalink / raw)
To: Michael Hanselmann
Cc: linux-kernel, linux-kernel, linuxppc-dev, Vojtech Pavlik,
linux-input
In-Reply-To: <20051225212041.GA6094@hansmi.ch>
On Sunday 25 December 2005 16:20, Michael Hanselmann wrote:
> This patch adds a basic input hook support to usbhid because the quirks
> method is outrunning the available bits. A hook for the Fn and Numlock
> keys on Apple PowerBooks is included.
Well, we have used 11 out of 32 available bits so there still some
reserves. My concern is that your implementation allows only one
hook to be installed while with quirks you can have several of them
active per device.
As far as the hook itself - i have that feeling that it should not be
done in kernel but via a keymap.
--
Dmitry
^ permalink raw reply
* Re: [PATCH/RFC?] usb/input: Add support for fn key on Apple PowerBooks
From: Benjamin Herrenschmidt @ 2005-12-25 21:57 UTC (permalink / raw)
To: Michael Hanselmann; +Cc: linux-input, linuxppc-dev, linux-kernel, linux-kernel
In-Reply-To: <20051225212041.GA6094@hansmi.ch>
On Sun, 2005-12-25 at 22:20 +0100, Michael Hanselmann wrote:
> This patch adds a basic input hook support to usbhid because the quirks
> method is outrunning the available bits. A hook for the Fn and Numlock
> keys on Apple PowerBooks is included.
>
> 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>
Acked-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
This makes the keyboard useable on latest generations of Apple
PowerBooks, so please apply asap :)
Ben.
^ permalink raw reply
* [PATCH/RFC?] usb/input: Add support for fn key on Apple PowerBooks
From: Michael Hanselmann @ 2005-12-25 21:20 UTC (permalink / raw)
To: linux-kernel; +Cc: linux-input, linuxppc-dev, linux-kernel
This patch adds a basic input hook support to usbhid because the quirks
method is outrunning the available bits. A hook for the Fn and Numlock
keys on Apple PowerBooks is included.
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>
---
diff -rNup linux-2.6.15-rc6.orig/drivers/usb/input/Kconfig linux-2.6.15-rc6/drivers/usb/input/Kconfig
--- linux-2.6.15-rc6.orig/drivers/usb/input/Kconfig 2005-12-22 20:51:57.000000000 +0100
+++ linux-2.6.15-rc6/drivers/usb/input/Kconfig 2005-12-22 22:01:09.000000000 +0100
@@ -37,6 +37,16 @@ config USB_HIDINPUT
If unsure, say Y.
+config USB_HIDINPUT_POWERBOOK
+ bool "Enable support for iBook/PowerBook special keys"
+ default n
+ depends on USB_HIDINPUT
+ help
+ Say Y here if you want support for the special keys (Fn, Numlock) on
+ Apple iBooks and PowerBooks.
+
+ If unsure, say N.
+
config HID_FF
bool "Force feedback support (EXPERIMENTAL)"
depends on USB_HIDINPUT && EXPERIMENTAL
diff -rNup linux-2.6.15-rc6.orig/drivers/usb/input/Makefile linux-2.6.15-rc6/drivers/usb/input/Makefile
--- linux-2.6.15-rc6.orig/drivers/usb/input/Makefile 2005-12-22 20:51:57.000000000 +0100
+++ linux-2.6.15-rc6/drivers/usb/input/Makefile 2005-12-22 23:16:54.000000000 +0100
@@ -25,6 +25,9 @@ endif
ifeq ($(CONFIG_HID_FF),y)
usbhid-objs += hid-ff.o
endif
+ifeq ($(CONFIG_USB_HIDINPUT_POWERBOOK),y)
+ usbhid-objs += hid-input-powerbook.o
+endif
obj-$(CONFIG_USB_AIPTEK) += aiptek.o
obj-$(CONFIG_USB_ATI_REMOTE) += ati_remote.o
diff -rNup linux-2.6.15-rc6.orig/drivers/usb/input/hid-input-powerbook.c linux-2.6.15-rc6/drivers/usb/input/hid-input-powerbook.c
--- linux-2.6.15-rc6.orig/drivers/usb/input/hid-input-powerbook.c 1970-01-01 01:00:00.000000000 +0100
+++ linux-2.6.15-rc6/drivers/usb/input/hid-input-powerbook.c 2005-12-25 21:23:04.000000000 +0100
@@ -0,0 +1,226 @@
+/*
+ * Mapping for special keys on Apple iBook and PowerBook keyboards
+ *
+ * Copyright (C) 2005 Michael Hanselmann (linux-kernel@hansmi.ch)
+ *
+ * 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.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA
+ *
+ */
+
+#include <linux/input.h>
+#include <linux/usb.h>
+
+#include "hid.h"
+
+#define map_key(c) do { usage->code = c; usage->type = EV_KEY; bit = input->keybit; max = KEY_MAX; } while (0)
+#define map_key_clear(c) do { map_key(c); clear_bit(c, bit); } while (0)
+
+#define APPLE_VENDOR_ID 0x05AC
+#define PB_ENABLED_FN 0x0001
+#define PB_FLAG_FKEY 0x0001
+
+static struct hid_input_hook_device input_pb_devices[] = {
+ { APPLE_VENDOR_ID, 0x020E },
+ { APPLE_VENDOR_ID, 0x020F },
+ { APPLE_VENDOR_ID, 0x0214 },
+ { APPLE_VENDOR_ID, 0x0215 },
+ { APPLE_VENDOR_ID, 0x0216 },
+ { }
+};
+
+struct input_pb_data {
+ u8 enabled_keys;
+};
+
+struct input_pb_translation {
+ u16 from;
+ u16 to;
+ u8 flags;
+};
+
+static struct input_pb_translation fn_keys[] = {
+ { KEY_BACKSPACE, KEY_DELETE },
+ { KEY_F1, KEY_BRIGHTNESSDOWN, PB_FLAG_FKEY },
+ { KEY_F2, KEY_BRIGHTNESSUP, PB_FLAG_FKEY },
+ { KEY_F3, KEY_MUTE, PB_FLAG_FKEY },
+ { KEY_F4, KEY_VOLUMEDOWN, PB_FLAG_FKEY },
+ { KEY_F5, KEY_VOLUMEUP, PB_FLAG_FKEY },
+ { KEY_F6, KEY_NUMLOCK, PB_FLAG_FKEY },
+ { KEY_F7, KEY_SWITCHVIDEOMODE, PB_FLAG_FKEY },
+ { KEY_F8, KEY_KBDILLUMTOGGLE, PB_FLAG_FKEY },
+ { KEY_F9, KEY_KBDILLUMDOWN, PB_FLAG_FKEY },
+ { KEY_F10, KEY_KBDILLUMUP, PB_FLAG_FKEY },
+ { KEY_UP, KEY_PAGEUP },
+ { KEY_DOWN, KEY_PAGEDOWN },
+ { KEY_LEFT, KEY_HOME },
+ { KEY_RIGHT, KEY_END },
+ { }
+};
+
+static struct input_pb_translation numlock_keys[] = {
+ { KEY_J, KEY_KP1 },
+ { KEY_K, KEY_KP2 },
+ { KEY_L, KEY_KP3 },
+ { KEY_U, KEY_KP4 },
+ { KEY_I, KEY_KP5 },
+ { KEY_O, KEY_KP6 },
+ { KEY_7, KEY_KP7 },
+ { KEY_8, KEY_KP8 },
+ { KEY_9, KEY_KP9 },
+ { KEY_M, KEY_KP0 },
+ { KEY_DOT, KEY_KPDOT },
+ { KEY_SLASH, KEY_KPPLUS },
+ { KEY_SEMICOLON, KEY_KPMINUS },
+ { KEY_P, KEY_KPASTERISK },
+ { KEY_MINUS, KEY_KPEQUAL },
+ { KEY_0, KEY_KPSLASH },
+ { KEY_ENTER, KEY_KPENTER },
+ { }
+};
+
+static int fkeysfirst = 1;
+module_param_named(pb_fkeysfirst, fkeysfirst, bool, 0644);
+MODULE_PARM_DESC(fkeysfirst, "Use fn special keys only while pressing fn");
+
+static int enablefnkeys = 1;
+module_param_named(pb_enablefnkeys, enablefnkeys, bool, 0644);
+MODULE_PARM_DESC(enablefnkeys, "Enable fn special keys");
+
+static int enablekeypad = 1;
+module_param_named(pb_enablekeypad, enablekeypad, bool, 0644);
+MODULE_PARM_DESC(enablekeypad, "Enable keypad keys");
+
+static inline struct input_pb_translation *find_translation(
+ struct input_pb_translation *table, int from)
+{
+ struct input_pb_translation *trans;
+
+ /* Look for the translation */
+ for(trans = table; trans->from && !(trans->from == from); trans++);
+
+ return (trans->from?trans:NULL);
+}
+
+static int input_pb_init(struct hid_device* hid)
+{
+ hid->hook_private = kzalloc(sizeof(struct input_pb_data), GFP_KERNEL);
+
+ if (!hid->hook_private)
+ return -ENOMEM;
+
+ return 0;
+}
+
+static void input_pb_exit(struct hid_device* hid)
+{
+ kfree(hid->hook_private);
+
+ return;
+}
+
+static int input_pb_event(struct hid_device *hid, struct hid_field *field,
+ struct hid_usage *usage, __s32 value, struct pt_regs *regs)
+{
+ struct input_pb_data *private = hid->hook_private;
+ struct input_dev *input;
+ struct input_pb_translation *trans;
+
+ if (usage->type != EV_KEY)
+ return -1;
+
+ input = field->hidinput->input;
+
+ switch(usage->code) {
+ case KEY_FN:
+ if (value) private->enabled_keys |= PB_ENABLED_FN;
+ else private->enabled_keys &= ~PB_ENABLED_FN;
+
+ input_event(input, usage->type, usage->code, value);
+
+ return 0;
+ }
+
+ if (enablefnkeys) {
+ trans = find_translation(fn_keys, usage->code);
+
+ if (trans) {
+ int known_key;
+
+ if (trans->flags & PB_FLAG_FKEY)
+ known_key =
+ ( fkeysfirst && (private->enabled_keys & PB_ENABLED_FN)) ||
+ (!fkeysfirst && !(private->enabled_keys & PB_ENABLED_FN));
+ else
+ known_key = (private->enabled_keys & PB_ENABLED_FN);
+
+ if (known_key) {
+ input_event(input, usage->type, trans->to, value);
+ return 0;
+ }
+ }
+ }
+
+ if (enablekeypad && test_bit(LED_NUML, input->led)) {
+ trans = find_translation(numlock_keys, usage->code);
+ if (trans)
+ input_event(input, usage->type, trans->to, value);
+
+ return 0;
+ }
+
+ return -1;
+}
+
+static int input_pb_conf(struct hid_input *hidinput, struct hid_field *field,
+ struct hid_usage *usage)
+{
+ struct input_dev *input = hidinput->input;
+ struct input_pb_translation *trans;
+ int max = 0;
+ unsigned long *bit = NULL;
+
+ field->hidinput = hidinput;
+
+ switch (usage->hid & HID_USAGE_PAGE) {
+ case HID_UP_CUSTOM:
+ switch(usage->hid & HID_USAGE) {
+ /* The fn key on Apple PowerBooks */
+ case 0x003:
+ map_key_clear(KEY_FN);
+
+ set_bit(KEY_FN, input->keybit);
+ set_bit(KEY_NUMLOCK, input->keybit);
+
+ /* Enable all needed keys */
+ for(trans = fn_keys; trans->from; trans++)
+ set_bit(trans->to, input->keybit);
+
+ for(trans = numlock_keys; trans->from; trans++)
+ set_bit(trans->to, input->keybit);
+
+ return 0;
+ }
+ }
+
+ return -1;
+}
+
+struct hid_input_hook usbhid_input_powerbook = {
+ .devices = input_pb_devices,
+ .init = input_pb_init,
+ .conf = input_pb_conf,
+ .event = input_pb_event,
+ .exit = input_pb_exit,
+};
diff -rNup linux-2.6.15-rc6.orig/drivers/usb/input/hid-input.c linux-2.6.15-rc6/drivers/usb/input/hid-input.c
--- linux-2.6.15-rc6.orig/drivers/usb/input/hid-input.c 2005-12-22 20:51:57.000000000 +0100
+++ linux-2.6.15-rc6/drivers/usb/input/hid-input.c 2005-12-25 21:48:09.000000000 +0100
@@ -63,6 +63,16 @@ static struct {
__s32 y;
} hid_hat_to_axis[] = {{ 0, 0}, { 0,-1}, { 1,-1}, { 1, 0}, { 1, 1}, { 0, 1}, {-1, 1}, {-1, 0}, {-1,-1}};
+/*
+ * This table contains pointers to hook structures.
+ */
+static struct hid_input_hook* hooks[] = {
+#ifdef CONFIG_USB_HIDINPUT_POWERBOOK
+ &usbhid_input_powerbook,
+#endif
+ NULL /* Terminating entry */
+};
+
#define map_abs(c) do { usage->code = c; usage->type = EV_ABS; bit = input->absbit; max = ABS_MAX; } while (0)
#define map_rel(c) do { usage->code = c; usage->type = EV_REL; bit = input->relbit; max = REL_MAX; } while (0)
#define map_key(c) do { usage->code = c; usage->type = EV_KEY; bit = input->keybit; max = KEY_MAX; } while (0)
@@ -73,6 +83,33 @@ static struct {
#define map_key_clear(c) do { map_key(c); clear_bit(c, bit); } while (0)
#define map_ff_effect(c) do { set_bit(c, input->ffbit); } while (0)
+static int hidinput_hook_wants_device(struct hid_input_hook *hook, u16 idVendor, u16 idProduct)
+{
+ struct hid_input_hook_device *curdev;
+
+ if (!hook->devices)
+ return 0;
+
+ /* Try to find device */
+ for (curdev = hook->devices;
+ curdev->idVendor && !(curdev->idVendor == idVendor && curdev->idProduct == idProduct);
+ curdev++);
+
+ return !!curdev->idVendor;
+}
+
+static struct hid_input_hook *hid_input_get_hook(u16 idVendor, u16 idProduct)
+{
+ struct hid_input_hook **hook;
+
+ for (hook = hooks;
+ *hook && !hidinput_hook_wants_device(*hook, idVendor, idProduct);
+ hook++);
+
+ return *hook;
+}
+
+
static void hidinput_configure_usage(struct hid_input *hidinput, struct hid_field *field,
struct hid_usage *usage)
{
@@ -92,6 +129,12 @@ static void hidinput_configure_usage(str
if (field->flags & HID_MAIN_ITEM_CONSTANT)
goto ignore;
+ if(field->hidinput->hook) {
+ struct hid_input_hook *hook = field->hidinput->hook;
+ if(hook->conf && hook->conf(hidinput, field, usage) == 0)
+ return;
+ }
+
switch (usage->hid & HID_USAGE_PAGE) {
case HID_UP_UNDEFINED:
@@ -325,7 +368,6 @@ static void hidinput_configure_usage(str
set_bit(EV_REP, input->evbit);
switch(usage->hid & HID_USAGE) {
- case 0x003: map_key_clear(KEY_FN); break;
default: goto ignore;
}
break;
@@ -470,6 +512,12 @@ void hidinput_hid_event(struct hid_devic
if (!usage->type)
return;
+ if(field->hidinput->hook) {
+ struct hid_input_hook *hook = field->hidinput->hook;
+ if(hook->event && hook->event(hid, field, usage, value, regs) == 0)
+ return;
+ }
+
if (((hid->quirks & HID_QUIRK_2WHEEL_MOUSE_HACK_5) && (usage->hid == 0x00090005))
|| ((hid->quirks & HID_QUIRK_2WHEEL_MOUSE_HACK_7) && (usage->hid == 0x00090007))) {
if (value) hid->quirks |= HID_QUIRK_2WHEEL_MOUSE_HACK_ON;
@@ -648,6 +696,17 @@ int hidinput_connect(struct hid_device *
list_add_tail(&hidinput->list, &hid->inputs);
}
+ hidinput->hook = hid_input_get_hook(
+ le16_to_cpu(hid->dev->descriptor.idVendor),
+ le16_to_cpu(hid->dev->descriptor.idProduct));
+
+ if(hidinput->hook &&
+ hidinput->hook->init &&
+ hidinput->hook->init(hid) < 0) {
+ printk(KERN_ERR "input: Hook initialization failed.\n");
+ hidinput->hook = NULL;
+ }
+
for (i = 0; i < report->maxfield; i++)
for (j = 0; j < report->field[i]->maxusage; j++)
hidinput_configure_usage(hidinput, report->field[i],
@@ -681,6 +740,8 @@ void hidinput_disconnect(struct hid_devi
struct hid_input *hidinput, *next;
list_for_each_entry_safe(hidinput, next, &hid->inputs, list) {
+ if(hidinput->hook && hidinput->hook->exit)
+ hidinput->hook->exit(hid);
list_del(&hidinput->list);
input_unregister_device(hidinput->input);
kfree(hidinput);
diff -rNup linux-2.6.15-rc6.orig/drivers/usb/input/hid.h linux-2.6.15-rc6/drivers/usb/input/hid.h
--- linux-2.6.15-rc6.orig/drivers/usb/input/hid.h 2005-12-22 20:51:57.000000000 +0100
+++ linux-2.6.15-rc6/drivers/usb/input/hid.h 2005-12-25 21:50:33.000000000 +0100
@@ -368,10 +368,33 @@ struct hid_control_fifo {
#define HID_CTRL_RUNNING 1
#define HID_OUT_RUNNING 2
+struct hid_input_hook_device {
+ u16 idVendor;
+ u16 idProduct;
+};
+
+struct hid_input_hook {
+ struct list_head list;
+ struct hid_input_hook_device *devices;
+
+ int (*init)(struct hid_device*);
+ void (*exit)(struct hid_device*);
+ int (*event)(struct hid_device *hid, struct hid_field *field,
+ struct hid_usage *usage, __s32 value, struct pt_regs *regs);
+ int (*conf)(struct hid_input *hidinput, struct hid_field *field,
+ struct hid_usage *usage);
+};
+
+#ifdef CONFIG_USB_HIDINPUT_POWERBOOK
+extern struct hid_input_hook usbhid_input_powerbook;
+#endif
+
struct hid_input {
struct list_head list;
struct hid_report *report;
struct input_dev *input;
+
+ struct hid_input_hook *hook;
};
struct hid_device { /* device report descriptor */
@@ -431,6 +454,8 @@ struct hid_device { /* device repo
void (*ff_exit)(struct hid_device*); /* Called by hid_exit_ff(hid) */
int (*ff_event)(struct hid_device *hid, struct input_dev *input,
unsigned int type, unsigned int code, int value);
+
+ void *hook_private;
};
#define HID_GLOBAL_STACK_SIZE 4
^ permalink raw reply
* 'TIMER_MAGIC' undeclared in 2.6.15-rc5 kernel
From: KylongMu @ 2005-12-25 10:43 UTC (permalink / raw)
To: 'Wolfgang Denk'; +Cc: linuxppc-embedded
In-Reply-To: <20050728230853.B4C29352675@atlas.denx.de>
[-- Attachment #1.1: Type: text/plain, Size: 444 bytes --]
Mr. Denk
One of my module can build with old 2.6.13 kernel(from AMCC's recent
3.0 resource CD), but it
Can't build with recent 2.6.15-rc5 kernel. The attached is my build Commands
and echo.
Hardware platform : Yosemite AMCC 440EP
Kernel Version:
9a0f2aefb7fc6ece4b9dfed96f1d1dc515d2c7a1 Wolfgang Denk 2005-12-16 17:59
The CPM2 interrupt handler does not return success
ELDK 4.0:
Merry Christmas!
KylongMu
[-- Attachment #1.2: Type: text/html, Size: 6645 bytes --]
[-- Attachment #2: 'TIMER_MAGIC' undeclared.txt --]
[-- Type: text/plain, Size: 5170 bytes --]
dxp:~/drvsrc_Linux/Driver/drv # make
make -C /root/linux-2.6-denx M=/root/drvsrc_Linux/Driver/drv modules
make[1]: Entering directory `/root/linux-2.6-denx'
WARNING: Symbol version dump /root/linux-2.6-denx/Module.symvers
is missing; modules will have no dependencies and modversions.
CC [M] /root/drvsrc_Linux/Driver/drv/./os/linux32/Os_Shared_Funct_IF.o
CC [M] /root/drvsrc_Linux/Driver/drv/./os/linux32/Os_Wrp_Funct.o
CC [M] /root/drvsrc_Linux/Driver/drv/./os/linux32/allocator.o
CC [M] /root/drvsrc_Linux/Driver/drv/./os/linux32/meminit.o
CC [M] /root/drvsrc_Linux/Driver/drv/./h2m/fm.o
CC [M] /root/drvsrc_Linux/Driver/drv/./h2m/fmcfg.o
CC [M] /root/drvsrc_Linux/Driver/drv/./h2m/fmminiL.o
CC [M] /root/drvsrc_Linux/Driver/drv/./h2m/fmminiL16.o
CC [M] /root/drvsrc_Linux/Driver/drv/./h2m/fmproject_01002.o
CC [M] /root/drvsrc_Linux/Driver/drv/./h2m/fmwdm.o
CC [M] /root/drvsrc_Linux/Driver/drv/./h2m/h2m.o
CC [M] /root/drvsrc_Linux/Driver/drv/./h2m/mips.o
/root/drvsrc_Linux/Driver/drv/./h2m/mips.c: In function 'Process_Mips_Com_Buf':
/root/drvsrc_Linux/Driver/drv/./h2m/mips.c:1581: error: 'struct timer_list' has no member named 'magic'
/root/drvsrc_Linux/Driver/drv/./h2m/mips.c:1581: error: 'TIMER_MAGIC' undeclared (first use in this function)
/root/drvsrc_Linux/Driver/drv/./h2m/mips.c:1581: error: (Each undeclared identifier is reported only once
/root/drvsrc_Linux/Driver/drv/./h2m/mips.c:1581: error: for each function it appears in.)
make[2]: *** [/root/drvsrc_Linux/Driver/drv/./h2m/mips.o] Error 1
make[1]: *** [_module_/root/drvsrc_Linux/Driver/drv] Error 2
make[1]: Leaving directory `/root/linux-2.6-denx'
make: *** [all] Error 2
dxp:~/drvsrc_Linux/Driver/drv # echo $KERNEL_DIR
/root/linux-2.6-denx
dxp:~/drvsrc_Linux/Driver/drv # export KERNEL_DIR=/root/linux-2.6.13
dxp:~/drvsrc_Linux/Driver/drv # echo $KERNEL_DIR
/root/linux-2.6.13
dxp:~/drvsrc_Linux/Driver/drv # make
make -C /root/linux-2.6.13 M=/root/drvsrc_Linux/Driver/drv modules
make[1]: Entering directory `/root/linux-2.6.13'
WARNING: Symbol version dump /root/linux-2.6.13/Module.symvers
is missing; modules will have no dependencies and modversions.
CC [M] /root/drvsrc_Linux/Driver/drv/./os/linux32/Os_General.o
CC [M] /root/drvsrc_Linux/Driver/drv/./os/linux32/Os_Int_Wrp.o
CC [M] /root/drvsrc_Linux/Driver/drv/./os/linux32/Os_Linux_Exit.o
CC [M] /root/drvsrc_Linux/Driver/drv/./os/linux32/Os_Linux_Init.o
CC [M] /root/drvsrc_Linux/Driver/drv/./os/linux32/Os_Shared_Funct_IF.o
CC [M] /root/drvsrc_Linux/Driver/drv/./os/linux32/Os_Wrp_Funct.o
CC [M] /root/drvsrc_Linux/Driver/drv/./os/linux32/allocator.o
CC [M] /root/drvsrc_Linux/Driver/drv/./os/linux32/meminit.o
CC [M] /root/drvsrc_Linux/Driver/drv/./h2m/fm.o
CC [M] /root/drvsrc_Linux/Driver/drv/./h2m/fmcfg.o
CC [M] /root/drvsrc_Linux/Driver/drv/./h2m/fmminiL.o
CC [M] /root/drvsrc_Linux/Driver/drv/./h2m/fmminiL16.o
CC [M] /root/drvsrc_Linux/Driver/drv/./h2m/fmproject_01002.o
CC [M] /root/drvsrc_Linux/Driver/drv/./h2m/fmwdm.o
CC [M] /root/drvsrc_Linux/Driver/drv/./h2m/h2m.o
CC [M] /root/drvsrc_Linux/Driver/drv/./h2m/mips.o
CC [M] /root/drvsrc_Linux/Driver/drv/./dma/dma.o
CC [M] /root/drvsrc_Linux/Driver/drv/./i2c/i2c.o
CC [M] /root/drvsrc_Linux/Driver/drv/./gpio/gpio.o
CC [M] /root/drvsrc_Linux/Driver/drv/./spi/spi.o
CC [M] /root/drvsrc_Linux/Driver/drv/./sc/sc.o
CC [M] /root/drvsrc_Linux/Driver/drv/./txc/streamer.o
CC [M] /root/drvsrc_Linux/Driver/drv/./txc/txcbda.o
CC [M] /root/drvsrc_Linux/Driver/drv/./txc/txcclose.o
CC [M] /root/drvsrc_Linux/Driver/drv/./txc/txcdev.o
CC [M] /root/drvsrc_Linux/Driver/drv/./txc/txcentry.o
CC [M] /root/drvsrc_Linux/Driver/drv/./txc/txcfrm.o
/root/drvsrc_Linux/Driver/drv/./txc/txcfrm.c: In function 'txc_mips_data_ready':
/root/drvsrc_Linux/Driver/drv/./txc/txcfrm.c:560: warning: cast to pointer from integer of different size
CC [M] /root/drvsrc_Linux/Driver/drv/./txc/txcmisc.o
CC [M] /root/drvsrc_Linux/Driver/drv/./txc/txcread.o
CC [M] /root/drvsrc_Linux/Driver/drv/./txc/txcrsa.o
CC [M] /root/drvsrc_Linux/Driver/drv/./txc/txctime.o
CC [M] /root/drvsrc_Linux/Driver/drv/./txc/txcwrite.o
CC [M] /root/drvsrc_Linux/Driver/drv/./tsd/tsd.o
CC [M] /root/drvsrc_Linux/Driver/drv/./tsd/tsd_if.o
CC [M] /root/drvsrc_Linux/Driver/drv/./mpp/mpp.o
CC [M] /root/drvsrc_Linux/Driver/drv/./sha1/sha1.o
LD [M] /root/drvsrc_Linux/Driver/drv/xcode2drv.o
Building modules, stage 2.
MODPOST
CC /root/drvsrc_Linux/Driver/drv/xcode2drv.mod.o
LD [M] /root/drvsrc_Linux/Driver/drv/xcode2drv.ko
make[1]: Leaving directory `/root/linux-2.6.13'
dxp:~/drvsrc_Linux/Driver/drv #
9a0f2aefb7fc6ece4b9dfed96f1d1dc515d2c7a1 Wolfgang Denk 2005-12-16 17:59 The CPM2 interrupt handler does not return succes
415a890333bd39be6f3a7684de11191bd2d205a1 Wolfgang Denk 2005-12-13 17:04 Merge with /home/git/linux-2.6
d705b5443455208e2a59051d7823dec5ac115808 Wolfgang Denk 2005-12-13 10:46 Merge with /home/git/linux-2.6
^ permalink raw reply
* kernel hang on 'now booting the kernel'
From: Ali Paikan @ 2005-12-25 10:18 UTC (permalink / raw)
To: linuxppc-dev
Dear Sir,
I am a student and I tried to install Linux on ML300 board. I need that fo=
r
doing my final project but I have many problems.
I compiled the open source PowerPC kernel (linuxppc_2_4_devel) with a cross=
compiler which I built it by Dan Kegel cross tools. Before compiling, I
updated xparameters_ml300.h according to my base system design from Xilinx =
EDK.
Next, I tried to download kernel ELF file to board and every thing seen wel=
l.
But My kernel hanged up when it was going to load main kernel image with sh=
ow
this message on serial console:
loaded at: 00400000 004B01E4
board data at: 004AD13C 004AD154
relocated to: 00405648 00405660
zimage at: 00405C13 004AC65E
avail ram: 004B1000 08000000
Linux/PPC load: console=3DttyS0,9600 ip=3Doff root=3D/dev/xsysace/disc0/par=
t3 rw
Uncompressing Linux...done.
Now booting the kernel
I debugged the kernel and results showed memory initialized and load_kernel=
function decompressed image into address 0x0 as well. (I can see tree NOP
instructions from address 0x0).
But, I am not sure about next step in jumping to address 0x000C and running=
the main part of kernel.
I wondered more when I tried to make a Xilinx System ACE file with Impact. =
It failed too with showing this fatal error:
FATAL_ERROR:GuiUtilities:WinApp.c:710:$Revision - This application has
discovered an exceptional condition from which it cannot recover. Process
will terminate. To resolve this error, please consult the Answers Database=
and other online resources at http://support.xilinx.com. If you need furthe=
r
assistance, please open a Webcase by clicking on the "WebCase" link at http=
://support.xilinx.com.
I don't have any problem for making system ace from other ELF files.
Might it be for my bad compilation?
Is my base system building for FPGA not correct?
Where is my wrong?
For more information I attached my all configuration and log files at end o=
f
this mail.
I am too great if you help me in this case and I look forward to hearing fr=
om you.
Sorry my pure English!
Sincerely,
Ali Paikan
Cross compiler option:
CONFIG_TARGET=3D"powerpc-405-linux-gnu"
CONFIG_TARGET_CFLAGS=3D"-O -mcpu=3D405"
CONFIG_GCC_EXTRA_CONFIG=3D"--with-cpu=3D405 --enable-cxx-flags=3D-mcpu=3D40=
5"
CONFIG_GLIBC_EXTRA_CONFIG=3D"=97without-fp"
powerpc-405-linux-gnu-objdump -h:
zImage.: file format elf32-powerpc
Sections:
Idx Name Size VMA LMA File off Algn
0 .text 00004798 00400000 00400000 00010000 2**2
CONTENTS, ALLOC, LOAD, READONLY, CODE
1 .data 00095000 00405000 00405000 00015000 2**2
CONTENTS, ALLOC, LOAD, DATA
2 .bss 000031e0 0049a000 _u48 ?49a000 000aa000 2**2
ALLOC
3 .note.GNU-stack 00000000 00000000 00000000 000aa000 2**0
CONTENTS, READONLY
Xparameters_ml300.h :
/*********************************************************_u42 ?********
*
* CAUTION: This file is automatically generated by libgen.
* Version: Xilinx EDK 7.1 EDK_H.10.4
* DO NOT EDIT.
*
* Copyright (c) 2005 Xilinx, Inc. All rights reserved.
*
* Description: Driver parameters
*
*******************************************************************/
#define XPAR_XUARTLITE_NUM_INSTANCES 1
#define XPAR_RS232_UART_1_BASEADDR 0x40600000
#define XPAR_RS232_UART_1_HIGHADDR 0x4060FFFF
#define XPAR_RS232_UART_1_DEVICE_ID 0
#define XPAR_RS232_UART_1_BAUDRATE 9600
#define XPAR_RS232_UART_1_USE_PARITY 0
#define XPAR_RS232_UART_1_ODD_PARITY 0
#define XPAR_RS232_UART_1_DATA_BITS 8
/******************************************************************/
#define XPAR_XSYSACE_MEM_WIDTH 8
#define XPAR_XSYSACE_NUM_INSTANCES 1
#define XPAR_SYSACE_COMPACTFLASH_BASEADDR 0x41800000
#define XPAR_SYSACE_COMPACTFLASH_HIGHADDR 0x4180FFFF
#define XPAR_SYSACE_COMPACTFLASH_DEVICE_ID 0
#define XPAR_SYSACE_COMPACTFLASH_MEM_WIDTH 8
/******************************************************************/
#define XPAR_INTC_MAX_NUM_INTR_INPUTS 3
#define XPAR_XINTC_HAS_IPR 1
#define XPAR_XINTC_USE_DCR 0
#define XPAR_XINTC_NUM_INSTANCES 1
#define XPAR_OPB_INTC_0_BASEADDR 0x41200000
#define XPAR_OPB_INTC_0_HIGHADDR 0x4120FFFF
#define XPAR_OPB_INTC_0_DEVICE_ID 0
#define XPAR_OPB_INTC_0_KIND_OF_INTR 0x00000006
/******************************************************************/
#define XPAR_INTC_SINGLE_BASEADDR 0x41200000
#define XPAR_INTC_SINGLE_HIGHADDR 0x4120FFFF
#define XPAR_INTC_SINGLE_DEVICE_ID XPAR_OPB_INTC_0_DEVICE_ID
#define XPAR_SYSACE_COMPACTFLASH_SYSACE_IRQ_MASK 0X000001
#define XPAR_OPB_INTC_0_SYSACE_COMPACTFLASH_SYSACE_IRQ_INTR 0
#define XPAR_RS232_UART_1_INTERRUPT_MASK 0X000002
#define XPAR_OPB_INTC_0_RS232_UART_1_INTERRUPT_INTR 1
#define XPAR_DDR_SDRAM_32MX32_IP2INTC_IRPT_MASK 0X000004
#define XPAR_OPB_INTC_0_DDR_SDRAM_32MX32_IP2INTC_IRPT_INTR 2
/******************************************************************/
#define XPAR_XDDR_NUM_INSTANCES 1
#define XPAR_DDR_SDRAM_32MX32_ECC_BASEADDR 0xFFFFFFFF
#define XPAR_DDR_SDRAM_32MX32_ECC_HIGHADDR 0x00000000
#define XPAR_DDR_SDRAM_32MX32_DEVICE_ID 0
#define XPAR_DDR_SDRAM_32MX32_INCLUDE_ECC_INTR 0
/******************************************************************/
#define XPAR_DDR_SDRAM_32MX32_MEM0_BASEADDR 0x00000000
#define XPAR_DDR_SDRAM_32MX32_MEM0_HIGHADDR 0x07FFFFFF
/******************************************************************/
#define XPAR_PLB_BRAM_IF_CNTLR_1_BASEADDR 0xffffc000
#define XPAR_PLB_BRAM_IF_CNTLR_1_HIGHADDR 0xffffffff
/******************************************************************/
#define XPAR_CPU_PPC405_CORE_CLOCK_FREQ_HZ 300000000
/******************************************************************/
/******************************************************************/
/* Linux Redefines */
/******************************************************************/
#define XPAR_UARTLITE_0_BASEADDR XPAR_RS232_UART_1_BASEADDR
#define XPAR_UARTLITE_0_HIGHADDR XPAR_RS232_UART_1_HIGHADDR
#define XPAR_UARTLITE_0_DEVICE_ID XPAR_RS232_UART_1_DEVICE_ID
/******************************************************************/
#define XPAR_SYSACE_0_BASEADDR XPAR_SYSACE_COMPACTFLASH_BASEADDR
#define XPAR_SYSACE_0_HIGHADDR XPAR_SYSACE_COMPACTFLASH_HIGHADDR
#define XPAR_SYSACE_0_DEVICE_ID XPAR_SYSACE_COMP8CTFLASH_DEVICE_ID
/******************************************************************/
#define XPAR_INTC_0_BASEADDR XPAR_OPB_INTC_0_BASEADDR
#define XPAR_INTC_0_HIGHADDR XPAR_OPB_INTC_0_HIGHADDR
#define XPAR_INTC_0_KIND_OF_INTR XPAR_OPB_INTC_0_KIND_OF_INTR
#define XPAR_INTC_0_DEVICE_ID XPAR_OPB_INTC_0_DEVICE_ID
/******************************************************************/
#define XPAR_INTC_0_SYSACE_0_VEC_ID XPAR_OPB_INTC_0_SYSACE_COMPACTFLASH_SYS=
ACE_IRQ_INTR
#define XPAR_INTC_0_UARTLITE_0_VEC_ID XPAR_OPB_INTC_0_RS232_UART_1_INTERRUP=
T_INTR
#define XPAR_INTC_0_DDR_0_VEC_ID XPAR_OPB_INTC_0_DDR_SDRAM_32MX32_IP2INTC_I=
RPT_INTR
/******************************************************************/
#define XPAR_PLB_CLOCK_FREQ_HZ 100000000
#define XPAR_CORE_CLOCK_FREQ_HZ XPAR_CPU_PPC405_CORE_CLOCK_FREQ_HZ
#define XPAR_DDR_0_SIZE 8000000
/******************************************************************/
#define XPAR_PERSISTENT_0_IIC_0_BASEADDR 0x00000400
#define XPAR_PERSISTENT_0_IIC_0_HIGHADDR 0x000007FF
#define XPAR_PERSISTENT_0_IIC_0_EEPROMADDR 0xA0
/******************************************************************/
#define XPAR_PCI_0_CLOCK_FREQ_HZ 0
/******************************************************************/
^ permalink raw reply
* Re: Modifying u-boot
From: emre kara @ 2005-12-25 1:29 UTC (permalink / raw)
To: Mustafa Çayýr; +Cc: linuxppc-embedded
In-Reply-To: <003c01c607d0$eab72160$9e01120a@bilisim.local>
I dont have so much information on 74xx and marvell's
bridge chips but for an advice,investigating the
latest u-boot source that includes DB64360 (marvell
discovery II) DB64460(marvell discovery III) board
support may be helpful, DB64360 bridge chip is the
same as MVME6100,then find the differences of two
boards and start to modify them.
Regards
Emre Kara
Tubitak-UEKAE:)
--- Mustafa Çayýr <mustafa.cayir@bte.mam.gov.tr>
wrote:
> hi,
>
> Could you give me advice where i can start to modify
> u-boot for MVME6100 board?
>
> Regards
> Mustafa Çayýr>
_______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
>
https://ozlabs.org/mailman/listinfo/linuxppc-embedded
___________________________________________________________
To help you stay safe and secure online, we've developed the all new Yahoo! Security Centre. http://uk.security.yahoo.com
^ permalink raw reply
* Re: PowerBook5,8 - TrackPad update
From: Dmitry Torokhov @ 2005-12-25 0:52 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Parag Warudkar, linux-kernel, linuxppc-dev, debian-powerpc,
Pavel Machek
In-Reply-To: <1135470801.6387.1.camel@localhost.localdomain>
On Saturday 24 December 2005 19:33, Benjamin Herrenschmidt wrote:
>
> > It should be doable once in gpm, all other apps can use gpm's repeater
> > mode...
> >
> > > When it's in raw mode for use by the synaptics X driver, if course, it's
> > > expected that those things are to be done by that driver.
> >
> > ...but you are right, doing it in /dev/input/mice emulation layer
> > makes some sense. OTOH I thought we were moving away from
> > /dev/input/mice... Its Dmitry's call I guess.
>
> Heh, yes, it is. No hurry anyway, I finally got synaptics working
> properly in X ...
>
> Why would we move away from the mouse mux ? It's proven to be very
> useful to me at least :)
>
It is very limited - number of buttons, wheels, etc. Once X supports
hotplugging mouse multipexor outgrows its usefullness (GPM can simply
be restarted every time we detect new input device).
--
Dmitry
^ permalink raw reply
* Re: PowerBook5,8 - TrackPad update
From: Benjamin Herrenschmidt @ 2005-12-25 0:33 UTC (permalink / raw)
To: Pavel Machek; +Cc: linux-kernel, linuxppc-dev, debian-powerpc, Parag Warudkar
In-Reply-To: <20051224231928.GC2183@elf.ucw.cz>
> It should be doable once in gpm, all other apps can use gpm's repeater
> mode...
>
> > When it's in raw mode for use by the synaptics X driver, if course, it's
> > expected that those things are to be done by that driver.
>
> ...but you are right, doing it in /dev/input/mice emulation layer
> makes some sense. OTOH I thought we were moving away from
> /dev/input/mice... Its Dmitry's call I guess.
Heh, yes, it is. No hurry anyway, I finally got synaptics working
properly in X ...
Why would we move away from the mouse mux ? It's proven to be very
useful to me at least :)
Ben
^ permalink raw reply
* Re: PowerBook5,8 - TrackPad update
From: Pavel Machek @ 2005-12-24 23:19 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: linux-kernel, linuxppc-dev, debian-powerpc, Parag Warudkar
In-Reply-To: <1135463271.5611.3.camel@localhost.localdomain>
On Ne 25-12-05 09:27:51, Benjamin Herrenschmidt wrote:
> On Sat, 2005-12-24 at 21:17 +0100, Pavel Machek wrote:
> > Hi!
> >
> > > Ok, I finally received my new laptop (PowerBook5,8 15"). I tried the
> > > latest patch you posted, and while the kernel driver seem to work ok
> > > (though you can feel the lack of a proper acceleration curve), the
> > > synaptics driver in X doesn't work in any useable way. I updated the one
> > > that comes with breezy to whatever was the latest on the author web site
> > > (.44 I think) and while it detected the tracpkad, the result was soooooo
> > > slooooow that it was totally unseable. I've tried the config tool that
> > > comes with KDE for it but couldn't "boost" it to anything useful. Is
> > > that expected or is there still issues to be resolved in the driver ?
> > > I'm tempted to add some minimum support for a proper acceleration curve
> > > in the kernel driver in fact...
> >
> > I do not think you should add it inside *kernel*. Proper acceleration
> > support really belongs to X...
>
> X, fbdev apps, gpm ... acceleration curves are typically done in HW,
> thus it makes sense in this case to have it in the kernel driver
> (besides, it should be fairly simple anyway) when it's in normal
> mode.
It should be doable once in gpm, all other apps can use gpm's repeater
mode...
> When it's in raw mode for use by the synaptics X driver, if course, it's
> expected that those things are to be done by that driver.
...but you are right, doing it in /dev/input/mice emulation layer
makes some sense. OTOH I thought we were moving away from
/dev/input/mice... Its Dmitry's call I guess.
Pavel
--
Thanks, Sharp!
^ permalink raw reply
* Re: PowerBook5,8 - TrackPad update
From: Benjamin Herrenschmidt @ 2005-12-24 22:27 UTC (permalink / raw)
To: Pavel Machek; +Cc: linux-kernel, linuxppc-dev, debian-powerpc, Parag Warudkar
In-Reply-To: <20051224201753.GA26801@elf.ucw.cz>
On Sat, 2005-12-24 at 21:17 +0100, Pavel Machek wrote:
> Hi!
>
> > Ok, I finally received my new laptop (PowerBook5,8 15"). I tried the
> > latest patch you posted, and while the kernel driver seem to work ok
> > (though you can feel the lack of a proper acceleration curve), the
> > synaptics driver in X doesn't work in any useable way. I updated the one
> > that comes with breezy to whatever was the latest on the author web site
> > (.44 I think) and while it detected the tracpkad, the result was soooooo
> > slooooow that it was totally unseable. I've tried the config tool that
> > comes with KDE for it but couldn't "boost" it to anything useful. Is
> > that expected or is there still issues to be resolved in the driver ?
> > I'm tempted to add some minimum support for a proper acceleration curve
> > in the kernel driver in fact...
>
> I do not think you should add it inside *kernel*. Proper acceleration
> support really belongs to X...
X, fbdev apps, gpm ... acceleration curves are typically done in HW,
thus it makes sense in this case to have it in the kernel driver
(besides, it should be fairly simple anyway) when it's in normal mode.
When it's in raw mode for use by the synaptics X driver, if course, it's
expected that those things are to be done by that driver.
Ben.
^ permalink raw reply
* Re: PowerBook5,8 - TrackPad update
From: Pavel Machek @ 2005-12-24 20:17 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: linux-kernel, linuxppc-dev, debian-powerpc, Parag Warudkar
In-Reply-To: <1135382385.4542.8.camel@gaston>
Hi!
> Ok, I finally received my new laptop (PowerBook5,8 15"). I tried the
> latest patch you posted, and while the kernel driver seem to work ok
> (though you can feel the lack of a proper acceleration curve), the
> synaptics driver in X doesn't work in any useable way. I updated the one
> that comes with breezy to whatever was the latest on the author web site
> (.44 I think) and while it detected the tracpkad, the result was soooooo
> slooooow that it was totally unseable. I've tried the config tool that
> comes with KDE for it but couldn't "boost" it to anything useful. Is
> that expected or is there still issues to be resolved in the driver ?
> I'm tempted to add some minimum support for a proper acceleration curve
> in the kernel driver in fact...
I do not think you should add it inside *kernel*. Proper acceleration
support really belongs to X...
Pavel
--
Thanks, Sharp!
^ permalink raw reply
* Re: PowerBook5,8 - TrackPad update
From: René Nussbaumer @ 2005-12-24 11:52 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: linux-kernel, linuxppc-dev, debian-powerpc, Parag Warudkar
In-Reply-To: <1135382385.4542.8.camel@gaston>
[-- Attachment #1: Type: text/plain, Size: 709 bytes --]
Hello
On Sat, Dec 24, 2005 at 10:59:44AM +1100, Benjamin Herrenschmidt wrote:
[...]
> comes with KDE for it but couldn't "boost" it to anything useful. Is
> that expected or is there still issues to be resolved in the driver ?
> I'm tempted to add some minimum support for a proper acceleration curve
> in the kernel driver in fact...
I'd the same problem. A quick look into Xorg.0.log tells me, that the
event device was missing. I created it manually and the acceleration and
other feautres are working now. Maybe you've still the same problem?
René
--
Written on a Gentoo Linux-system by René
http://www.forkbomb.ch
«Das Leben ist hart. Forkbomb ist härter.», (c) 2004 by Frank.
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: PowerBook5,8 - TrackPad update
From: Benjamin Herrenschmidt @ 2005-12-23 23:59 UTC (permalink / raw)
To: Michael Hanselmann
Cc: Parag Warudkar, linux-kernel, linuxppc-dev, debian-powerpc
In-Reply-To: <20051204224221.GA28218@hansmi.ch>
Ok, I finally received my new laptop (PowerBook5,8 15"). I tried the
latest patch you posted, and while the kernel driver seem to work ok
(though you can feel the lack of a proper acceleration curve), the
synaptics driver in X doesn't work in any useable way. I updated the one
that comes with breezy to whatever was the latest on the author web site
(.44 I think) and while it detected the tracpkad, the result was soooooo
slooooow that it was totally unseable. I've tried the config tool that
comes with KDE for it but couldn't "boost" it to anything useful. Is
that expected or is there still issues to be resolved in the driver ?
I'm tempted to add some minimum support for a proper acceleration curve
in the kernel driver in fact...
Ben.
^ permalink raw reply
* Re: Modifying u-boot
From: Grant Likely @ 2005-12-23 15:23 UTC (permalink / raw)
To: Mustafa Çayır; +Cc: linuxppc-embedded
In-Reply-To: <003c01c607d0$eab72160$9e01120a@bilisim.local>
Mustafa Çayır wrote:
> hi,
>
> Could you give me advice where i can start to modify u-boot for MVME6100
> board?
http://www.denx.de/wiki/DULG/Manual
--
Grant Likely, B.Sc. P.Eng.
Secret Lab Technologies Ltd.
(403) 663-0761
^ permalink raw reply
* Modifying u-boot
From: Mustafa Çayır @ 2005-12-23 14:55 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 114 bytes --]
hi,
Could you give me advice where i can start to modify u-boot for MVME6100 board?
Regards
Mustafa Çayır
[-- Attachment #2: Type: text/html, Size: 661 bytes --]
^ permalink raw reply
* Compilation Error
From: Prabhat_Singh @ 2005-12-23 11:53 UTC (permalink / raw)
To: linuxppc-embedded; +Cc: Prabhat_Singh
[-- Attachment #1: Type: text/plain, Size: 3091 bytes --]
Hi all,
I am building linux-2.4.32 kernel using ELDK tool for
MPC8248(MPC8272 family) based target board. After configuring kernel as
follow:
1)Make xconfig ARCH=ppc
Platform support:MPC8260 CPM support -y
MPC8272 family Support -y
Machine type : ADS8272
And after saving configuration ..
2)Make dep ARCH=ppc
3)Make bzImage ARCH=ppc
Now I am getting error like this..............
************************************************************************
**************************************
m /home/sibi/vpnporting/linux-2.4.32/include/linux/blk.h:4,
from m8260_setup.c:31:
/home/sibi/vpnporting/linux-2.4.32/include/asm/mpc8260.h:32:1: warning:
"PCI_DRAM_OFFSET" redefined
In file included from
/home/sibi/vpnporting/linux-2.4.32/include/asm/mpc8260.h:24,
from
/home/sibi/vpnporting/linux-2.4.32/include/asm/io.h:31,
from
/home/sibi/vpnporting/linux-2.4.32/include/linux/blkdev.h:11,
from
/home/sibi/vpnporting/linux-2.4.32/include/linux/blk.h:4,
from m8260_setup.c:31:
/home/sibi/vpnporting/linux-2.4.32/arch/ppc/platforms/pq2ads.h:85:1:
warning: this is the location of the previous
definitionm8260_setup.c:68: warning: `abort' was declared `extern' and
later `static'
m8260_setup.c: In function `abort':
m8260_setup.c:70: error: conflicting types for `xmon'
/home/sibi/vpnporting/linux-2.4.32/include/asm/system.h:49: error:
previous declaration of `xmon'
m8260_setup.c:70: warning: extern declaration of `xmon' doesn't match
global one
m8260_setup.c: In function `m8260_restart':
m8260_setup.c:129: warning: passing arg 1 of `m8260_gorom' makes pointer
from integer without a cast
m8260_setup.c: In function `m8260_show_percpuinfo':
m8260_setup.c:157: warning: int format, long unsigned int arg (arg 3)
m8260_setup.c:157: warning: int format, long unsigned int arg (arg 4)
m8260_setup.c:157: warning: int format, long unsigned int arg (arg 5)
m8260_setup.c: At top level:
m8260_setup.c:68: warning: `abort' defined but not used
make[1]: *** [m8260_setup.o] Error 1
make[1]: Leaving directory
`/home/sibi/vpnporting/linux-2.4.32/arch/ppc/kernel'
make: *** [_dir_arch/ppc/kernel] Error 2
If anyone encountered this type of problem please through light on this.
Thanks in advance
Thanks & Regards
Prabhat Singh
SE
Satyam Computer Services Ltd.
DISCLAIMER:
This email (including any attachments) is intended for the sole use of the intended recipient/s and may contain material that is CONFIDENTIAL AND PRIVATE COMPANY INFORMATION. Any review or reliance by others or copying or distribution or forwarding of any or all of the contents in this message is STRICTLY PROHIBITED. If you are not the intended recipient, please contact the sender by email and delete all copies; your cooperation in this regard is appreciated.
[-- Attachment #2: Type: text/html, Size: 12025 bytes --]
^ permalink raw reply
* Re: [RFC] genalloc != generic DEVICE memory allocator
From: Jes Sorensen @ 2005-12-23 10:59 UTC (permalink / raw)
To: Andrey Volkov; +Cc: Andrew Morton, linux-kernel, linuxppc-embedded
In-Reply-To: <43AAEE12.5030009@varma-el.com>
>>>>> "Andrey" == Andrey Volkov <avolkov@varma-el.com> writes:
Andrey> Hi Jes,
Andrey> Jes Sorensen wrote:
>> This really is irrelevant, the space is only used within the
>> object when it's on the free list. Ie. if all memory is handed out
>> there's no space used for this purpose.
Andrey> I point out 2 reasons: ACCESS TIME was first :), let take very
Andrey> widespread case: PCI device with some onboard memory and any N
Andrey> GHz proc. - result may be terrible: each access to device mem
Andrey> (which usually uncached) will slowed down this super fast proc
Andrey> to 33 MHZ, i.e same as we made busy-wait with disabled
Andrey> interrupts after each read/write...
Andrey,
As I said in my response, you need the control blocks because you are
not allowed to directly access things on the other side of the PCI bus
without using the readl/writel equivalent macros. It's got nothing to
do with access speed.
>> For the case of more traditional devices, the control structures
>> will be allocated from one end of the block, the rest will be used
>> for packet descriptors which will be going in and out of the memory
>> pool on a regular basis.
Andrey> This was main reason why I try to modify genalloc: I needed in
Andrey> generic allocator for both short-live strictly aligned blocks
Andrey> and long-live blocks with restriction by size.
genalloc is perfectly adequate for that purpose. The long lived
allocations will just be taken out first, the rest will be used for
the short lived.
>> In most normal cases these will all be of the same size and it
>> doesn't matter where in the memory space they were allocated.
Andrey> And thats also why I consider that 'buddy' is not appropriate
Andrey> to be 'generic' (most cases == generic, isn't is :)?): when
Andrey> you're allocate mainly same sized blocks, 'buddy' degraded to
Andrey> the first-fit.
huh?
>> I honestly don't think the majority of your demands are valid.
>> genalloc was meant to be simple, not an ultra fast at any random
>> block size allocator. So far I don't see any reason for changing to
>> the allocation algorithm into anything much more complex - doesn't
>> mean there couldn't be a reason for doing so, but I don't think you
>> have described any so far.
Andrey> I disagree here, generic couldn't be very simple and slow,
Andrey> because in this case simply no one will be use it, and hence
Andrey> we'll get today's picture: reimplemented allocators in many
Andrey> drivers.
Of course it can. I will continue to claim that you are trying to turn
it into something it doesn't need to be. The allocator I used was
based on the allocator from the old sym2 driver, which is a perfect
example of it being used by a device driver.
>> You mentioned frame buffers, but what is the kernel supposed to do
>> with those allocation wise? If you have a frame buffer console, the
>> memory is allocated once and handed to the frame buffer driver.
>> Ie. you don't need a ton of on demand allocations for that and for
>> X, the memory management is handled in the X server, not by the
>> kernel.
Andrey> For video-only device this is true, but if device is a
Andrey> multifunctional, which is frequent case in embedded systems,
Andrey> then kernel must control of device memory
Andrey> allocation. Currently, however, even video cards for desktops
Andrey> become more and more multifunctional (VIVO/audio etc.).
For multi functional devices you still often split the memory up at
init time. Some memory is never going to be given back (like the frame
buffer itself), other blocks are like the network packet descriptors
in a network device.
>> The only thing I think would make sense to implement is to allow
>> it to use indirect descriptor blocks for the memory it
>> manages. This is not because it's wrong to use the memory for the
>> free list, as it will only be used for this when the chunk is not
>> in use, but because access to certain types of memory isn't always
>> valid through normal direct access. Ie. if one used descriptor
>> blocks residing in normal GFP_KERNEL memory, it would be possible
>> to use the allocator to manage memory sitting on the other side of
>> a PCI bus.
Andrey> I describe above, why we couldn't/wouldn't use onboard memory
Andrey> for allocator specific data.
As I pointed out, your description wasn't valid. You are not allowed
to directly dereference memory on the other side of a PCI bus.
Regards,
Jes
^ permalink raw reply
* Re: [RFC] genalloc != generic DEVICE memory allocator
From: Andrey Volkov @ 2005-12-23 10:17 UTC (permalink / raw)
To: Pantelis Antoniou
Cc: Andrew Morton, Jes Sorensen, linuxppc-embedded, linux-kernel
In-Reply-To: <43ABAB69.4060703@intracom.gr>
Pantelis Antoniou wrote:
>>
>
> [snip]
>
>>
>> Agree, I couldn't see nothing better for a basement of generic dev.
>> alloc.
>>
>> So, it will be much better if it will be moved to lib/.
>>
>> Anyone have some more comments about subj. ?
>>
>
> Sure, but the call has to be made be a core developer.
>
> Andrew?
Pantelis, what did you think about renaming rheap.c and rh_xxx, to
something like dev_xxx, since, for example, rh_alloc overlapped with
__rh_alloc (__RegionHach__alloc) in the drivers/md/dm-raid1.c.
--
Regards
Andrey Volkov
^ permalink raw reply
* Re: [RFC] genalloc != generic DEVICE memory allocator
From: Pantelis Antoniou @ 2005-12-23 7:46 UTC (permalink / raw)
To: Andrey Volkov
Cc: Andrew Morton, Jes Sorensen, linuxppc-embedded, linux-kernel
In-Reply-To: <43ABA972.4080701@varma-el.com>
>
[snip]
>
> Agree, I couldn't see nothing better for a basement of generic dev. alloc.
>
> So, it will be much better if it will be moved to lib/.
>
> Anyone have some more comments about subj. ?
>
Sure, but the call has to be made be a core developer.
Andrew?
Regards
Pantelis
^ permalink raw reply
* Re: [RFC] genalloc != generic DEVICE memory allocator
From: Andrey Volkov @ 2005-12-23 7:38 UTC (permalink / raw)
To: pantelis.antoniou
Cc: Andrew Morton, Jes Sorensen, linux-kernel, linuxppc-embedded
In-Reply-To: <200512222033.40156.pantelis.antoniou@gmail.com>
Pantelis Antoniou wrote:
> On Thursday 22 December 2005 20:18, Andrey Volkov wrote:
>
>>Hi Jes,
>>
>>Jes Sorensen wrote:
>>
>>>>>>>>"Andrey" == Andrey Volkov <avolkov@varma-el.com> writes:
>>>
>>>
>>>Andrey> Hello Jes and all I try to use your allocator (gen_pool_xxx),
>>>Andrey> idea of which is a cute nice thing. But current implementation
>>>Andrey> of it is inappropriate for a _device_ (aka onchip, like
>>>Andrey> framebuffer) memory allocation, by next reasons:
>>>
>>>Andrey,
>>>
>>>Keep in mind that genalloc was meant to be simple for basic memory
>>>allocations. It was never meant to be an over complex super high
>>>performance allocation mechanism.
>>>
>>>Andrey> 1) Device memory is expensive resource by access time and/or
>>>Andrey> size cost. So we couldn't use (usually) this memory for the
>>>Andrey> free blocks lists.
>>>
>>>This really is irrelevant, the space is only used within the object
>>>when it's on the free list. Ie. if all memory is handed out there's
>>>no space used for this purpose.
>>
>>I point out 2 reasons: ACCESS TIME was first :), let take very
>>widespread case: PCI device with some onboard memory and any
>>N GHz proc. - result may be terrible: each access to device mem (which
>>usually uncached) will slowed down this super fast proc to 33 MHZ, i.e
>>same as we made busy-wait with disabled interrupts after each read/write...
>>
>>I possible awry when use 'control structures' in 2), I've in view
>>allocator's control structures (size/next etc), not device specific
>>control structs.
>>
>>
>>>Andrey> 3) Obvious (IMHO) workflow of mem. allocator
>>>Andrey> look like: - at startup time, driver allocate some big
>>>Andrey> (almost) static mem. chunk(s) for a control/data structures.
>>>Andrey> - during work of the device, driver allocate many small
>>>Andrey> mem. blocks with almost identical size. such behavior lead to
>>>Andrey> degeneration of buddy method and transform it to the
>>>Andrey> first/best fit method (with long seek by the free node list).
>>>
>>>This is only really valid for network devices, and even then it's not
>>>quite so. For things like uncached allocations your observation is
>>>completely off.
>>
>>Could you give me some examples? Possible I overlooked something
>>significant.
>>
>>
>>>For the case of more traditional devices, the control structures will
>>>be allocated from one end of the block, the rest will be used for
>>>packet descriptors which will be going in and out of the memory pool
>>>on a regular basis.
>>
>>This was main reason why I try to modify genalloc: I needed in
>>generic allocator for both short-live strictly aligned blocks and
>>long-live blocks with restriction by size.
>>
>>
>>>In most normal cases these will all be of the same
>>>size and it doesn't matter where in the memory space they were
>>>allocated.
>>
>>And thats also why I consider that 'buddy' is not appropriate to be
>>'generic' (most cases == generic, isn't is :)?): when you're allocate
>>mainly same sized blocks, 'buddy' degraded to the first-fit.
>>
>>Possible solution I see in mixed first-fit with lazy coalescent for
>>short lived blocks and first-fit with immediately coalescent for
>>long-lived blocks. But, again, I may overlook something significant.
>>And, certainly, I could overlooked someone else allocator implementation
>>in some driver.
>>
>>
>>>Andrey> 4) The simple binary buddy method is far away from perfect for
>>>Andrey> a device due to a big internal fragmentation. Especially for a
>>>Andrey> network/mfd devices, for which, size of allocated data very
>>>Andrey> often is not a power of 2.
>>>
>>
>>snip
>>
>>>Andrey> I start to modify your code to satisfy above demands, but
>>>Andrey> firstly I wish to know your, or somebody else, opinion.
>>>
>>>I honestly don't think the majority of your demands are valid.
>>>genalloc was meant to be simple, not an ultra fast at any random
>>>block size allocator. So far I don't see any reason for changing to
>>>the allocation algorithm into anything much more complex - doesn't
>>>mean there couldn't be a reason for doing so, but I don't think you
>>>have described any so far.
>>
>>I disagree here, generic couldn't be very simple and slow, because in
>>this case simply no one will be use it, and hence we'll get today's
>>picture: reimplemented allocators in many drivers.
>>
>>
>>>You mentioned frame buffers, but what is the kernel supposed to do
>>>with those allocation wise? If you have a frame buffer console, the
>>>memory is allocated once and handed to the frame buffer driver.
>>>Ie. you don't need a ton of on demand allocations for that and for
>>>X, the memory management is handled in the X server, not by the
>>>kernel.
>>
>>For video-only device this is true, but if device is a multifunctional,
>>which is frequent case in embedded systems, then kernel must control of
>>device memory allocation. Currently, however, even video cards for
>>desktops become more and more multifunctional (VIVO/audio etc.).
>>
>>
>>>The only thing I think would make sense to implement is to allow it to
>>>use indirect descriptor blocks for the memory it manages. This is not
>>>because it's wrong to use the memory for the free list, as it will
>>>only be used for this when the chunk is not in use, but because access
>>>to certain types of memory isn't always valid through normal direct
>>>access. Ie. if one used descriptor blocks residing in normal
>>>GFP_KERNEL memory, it would be possible to use the allocator to manage
>>>memory sitting on the other side of a PCI bus.
>>
>>I describe above, why we couldn't/wouldn't use onboard memory for
>>allocator specific data.
>>
>>Pantelis, Am I answered to your question (...what are you trying to
>>do...) too?
>>
>
>
> Yes. rheap seems to cover your cases...
>
Agree, I couldn't see nothing better for a basement of generic dev. alloc.
So, it will be much better if it will be moved to lib/.
Anyone have some more comments about subj. ?
--
Regards
Andrey Volkov
^ permalink raw reply
* [PATCH] ppc32 8xx: last two 8MB D-TLB entries are incorrectly set
From: Marcelo Tosatti @ 2005-12-22 19:52 UTC (permalink / raw)
To: linux-ppc-embedded, Dan Malek
Hi,
The last two 8MB TLB entries are being incorrectly set by initial_mmu on 8xx.
The first entry is written with the same virtual/physical address, which
renders it invalid:
BDI>rms 792 0x00001e00
BDI>rms 824 1
BDI>rds 824
SPR 824 : 0xc08000c0 -1065353024
BDI>rds 825
SPR 825 : 0xc0800de0 -1065349664
BDI>rds 826
SPR 826 : 0x00000000 0
And the second entry, in addition, does not have its TLB index set
correctly.
Dan, I'm afraid that, with this problem fixed, the issue you mentioned
before with relation to conflicts with the vmalloc space becomes real.
* only pin available RAM at initial_mmu, the pinned mappings pointing
beyond the end of physical RAM cause conflicts with vmalloc() space.
Is there any way to know the RAM size at this point in boot? The bd_t
structure is board-specific, so no chance at offseting bd_t to reach the
"mem_size" field.
I see no improvements with the following patch on 128MB boxen, probably
because most referenced kernel data is above 24MB (SLAB caches, etc).
But lower mem machines should benefit significantly - anyone willing to
do some testing?
diff --git a/arch/ppc/kernel/head_8xx.S b/arch/ppc/kernel/head_8xx.S
index de09787..c67cb5c 100644
--- a/arch/ppc/kernel/head_8xx.S
+++ b/arch/ppc/kernel/head_8xx.S
@@ -733,13 +733,16 @@ initial_mmu:
mtspr SPRN_MD_TWC, r9
li r11, MI_BOOTINIT /* Create RPN for address 0 */
addis r11, r11, 0x0080 /* Add 8M */
- mtspr SPRN_MD_RPN, r8
+ mtspr SPRN_MD_RPN, r11
+
+ addi r10, r10, 0x0100
+ mtspr SPRN_MD_CTR, r10
addis r8, r8, 0x0080 /* Add 8M */
mtspr SPRN_MD_EPN, r8
mtspr SPRN_MD_TWC, r9
addis r11, r11, 0x0080 /* Add 8M */
- mtspr SPRN_MD_RPN, r8
+ mtspr SPRN_MD_RPN, r11
#endif
/* Since the cache is enabled according to the information we
^ permalink raw reply related
* Re: [RFC] genalloc != generic DEVICE memory allocator
From: Pantelis Antoniou @ 2005-12-22 18:33 UTC (permalink / raw)
To: linuxppc-embedded; +Cc: Andrew Morton, Jes Sorensen, linux-kernel
In-Reply-To: <43AAEE12.5030009@varma-el.com>
On Thursday 22 December 2005 20:18, Andrey Volkov wrote:
> Hi Jes,
>
> Jes Sorensen wrote:
> >>>>>>"Andrey" == Andrey Volkov <avolkov@varma-el.com> writes:
> >
> >
> > Andrey> Hello Jes and all I try to use your allocator (gen_pool_xxx),
> > Andrey> idea of which is a cute nice thing. But current implementation
> > Andrey> of it is inappropriate for a _device_ (aka onchip, like
> > Andrey> framebuffer) memory allocation, by next reasons:
> >
> > Andrey,
> >
> > Keep in mind that genalloc was meant to be simple for basic memory
> > allocations. It was never meant to be an over complex super high
> > performance allocation mechanism.
> >
> > Andrey> 1) Device memory is expensive resource by access time and/or
> > Andrey> size cost. So we couldn't use (usually) this memory for the
> > Andrey> free blocks lists.
> >
> > This really is irrelevant, the space is only used within the object
> > when it's on the free list. Ie. if all memory is handed out there's
> > no space used for this purpose.
>
> I point out 2 reasons: ACCESS TIME was first :), let take very
> widespread case: PCI device with some onboard memory and any
> N GHz proc. - result may be terrible: each access to device mem (which
> usually uncached) will slowed down this super fast proc to 33 MHZ, i.e
> same as we made busy-wait with disabled interrupts after each read/write...
>
> I possible awry when use 'control structures' in 2), I've in view
> allocator's control structures (size/next etc), not device specific
> control structs.
>
> >
> > Andrey> 3) Obvious (IMHO) workflow of mem. allocator
> > Andrey> look like: - at startup time, driver allocate some big
> > Andrey> (almost) static mem. chunk(s) for a control/data structures.
> > Andrey> - during work of the device, driver allocate many small
> > Andrey> mem. blocks with almost identical size. such behavior lead to
> > Andrey> degeneration of buddy method and transform it to the
> > Andrey> first/best fit method (with long seek by the free node list).
> >
> > This is only really valid for network devices, and even then it's not
> > quite so. For things like uncached allocations your observation is
> > completely off.
>
> Could you give me some examples? Possible I overlooked something
> significant.
>
> >
> > For the case of more traditional devices, the control structures will
> > be allocated from one end of the block, the rest will be used for
> > packet descriptors which will be going in and out of the memory pool
> > on a regular basis.
>
> This was main reason why I try to modify genalloc: I needed in
> generic allocator for both short-live strictly aligned blocks and
> long-live blocks with restriction by size.
>
> > In most normal cases these will all be of the same
> > size and it doesn't matter where in the memory space they were
> > allocated.
>
> And thats also why I consider that 'buddy' is not appropriate to be
> 'generic' (most cases == generic, isn't is :)?): when you're allocate
> mainly same sized blocks, 'buddy' degraded to the first-fit.
>
> Possible solution I see in mixed first-fit with lazy coalescent for
> short lived blocks and first-fit with immediately coalescent for
> long-lived blocks. But, again, I may overlook something significant.
> And, certainly, I could overlooked someone else allocator implementation
> in some driver.
>
> >
> > Andrey> 4) The simple binary buddy method is far away from perfect for
> > Andrey> a device due to a big internal fragmentation. Especially for a
> > Andrey> network/mfd devices, for which, size of allocated data very
> > Andrey> often is not a power of 2.
> >
> snip
> >
> > Andrey> I start to modify your code to satisfy above demands, but
> > Andrey> firstly I wish to know your, or somebody else, opinion.
> >
> > I honestly don't think the majority of your demands are valid.
> > genalloc was meant to be simple, not an ultra fast at any random
> > block size allocator. So far I don't see any reason for changing to
> > the allocation algorithm into anything much more complex - doesn't
> > mean there couldn't be a reason for doing so, but I don't think you
> > have described any so far.
> I disagree here, generic couldn't be very simple and slow, because in
> this case simply no one will be use it, and hence we'll get today's
> picture: reimplemented allocators in many drivers.
>
> >
> > You mentioned frame buffers, but what is the kernel supposed to do
> > with those allocation wise? If you have a frame buffer console, the
> > memory is allocated once and handed to the frame buffer driver.
> > Ie. you don't need a ton of on demand allocations for that and for
> > X, the memory management is handled in the X server, not by the
> > kernel.
>
> For video-only device this is true, but if device is a multifunctional,
> which is frequent case in embedded systems, then kernel must control of
> device memory allocation. Currently, however, even video cards for
> desktops become more and more multifunctional (VIVO/audio etc.).
>
> >
> > The only thing I think would make sense to implement is to allow it to
> > use indirect descriptor blocks for the memory it manages. This is not
> > because it's wrong to use the memory for the free list, as it will
> > only be used for this when the chunk is not in use, but because access
> > to certain types of memory isn't always valid through normal direct
> > access. Ie. if one used descriptor blocks residing in normal
> > GFP_KERNEL memory, it would be possible to use the allocator to manage
> > memory sitting on the other side of a PCI bus.
> I describe above, why we couldn't/wouldn't use onboard memory for
> allocator specific data.
>
> Pantelis, Am I answered to your question (...what are you trying to
> do...) too?
>
Yes. rheap seems to cover your cases...
> --
> Regards
> Andrey Volkov
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
Regards
Pantelis
^ permalink raw reply
* Re: [RFC] genalloc != generic DEVICE memory allocator
From: Andrey Volkov @ 2005-12-22 18:18 UTC (permalink / raw)
To: Jes Sorensen, Pantelis Antoniou
Cc: Andrew Morton, linux-kernel, linuxppc-embedded
In-Reply-To: <yq0d5jpuoqe.fsf@jaguar.mkp.net>
Hi Jes,
Jes Sorensen wrote:
>>>>>>"Andrey" == Andrey Volkov <avolkov@varma-el.com> writes:
>
>
> Andrey> Hello Jes and all I try to use your allocator (gen_pool_xxx),
> Andrey> idea of which is a cute nice thing. But current implementation
> Andrey> of it is inappropriate for a _device_ (aka onchip, like
> Andrey> framebuffer) memory allocation, by next reasons:
>
> Andrey,
>
> Keep in mind that genalloc was meant to be simple for basic memory
> allocations. It was never meant to be an over complex super high
> performance allocation mechanism.
>
> Andrey> 1) Device memory is expensive resource by access time and/or
> Andrey> size cost. So we couldn't use (usually) this memory for the
> Andrey> free blocks lists.
>
> This really is irrelevant, the space is only used within the object
> when it's on the free list. Ie. if all memory is handed out there's
> no space used for this purpose.
I point out 2 reasons: ACCESS TIME was first :), let take very
widespread case: PCI device with some onboard memory and any
N GHz proc. - result may be terrible: each access to device mem (which
usually uncached) will slowed down this super fast proc to 33 MHZ, i.e
same as we made busy-wait with disabled interrupts after each read/write...
I possible awry when use 'control structures' in 2), I've in view
allocator's control structures (size/next etc), not device specific
control structs.
>
> Andrey> 3) Obvious (IMHO) workflow of mem. allocator
> Andrey> look like: - at startup time, driver allocate some big
> Andrey> (almost) static mem. chunk(s) for a control/data structures.
> Andrey> - during work of the device, driver allocate many small
> Andrey> mem. blocks with almost identical size. such behavior lead to
> Andrey> degeneration of buddy method and transform it to the
> Andrey> first/best fit method (with long seek by the free node list).
>
> This is only really valid for network devices, and even then it's not
> quite so. For things like uncached allocations your observation is
> completely off.
Could you give me some examples? Possible I overlooked something
significant.
>
> For the case of more traditional devices, the control structures will
> be allocated from one end of the block, the rest will be used for
> packet descriptors which will be going in and out of the memory pool
> on a regular basis.
This was main reason why I try to modify genalloc: I needed in
generic allocator for both short-live strictly aligned blocks and
long-live blocks with restriction by size.
> In most normal cases these will all be of the same
> size and it doesn't matter where in the memory space they were
> allocated.
And thats also why I consider that 'buddy' is not appropriate to be
'generic' (most cases == generic, isn't is :)?): when you're allocate
mainly same sized blocks, 'buddy' degraded to the first-fit.
Possible solution I see in mixed first-fit with lazy coalescent for
short lived blocks and first-fit with immediately coalescent for
long-lived blocks. But, again, I may overlook something significant.
And, certainly, I could overlooked someone else allocator implementation
in some driver.
>
> Andrey> 4) The simple binary buddy method is far away from perfect for
> Andrey> a device due to a big internal fragmentation. Especially for a
> Andrey> network/mfd devices, for which, size of allocated data very
> Andrey> often is not a power of 2.
>
snip
>
> Andrey> I start to modify your code to satisfy above demands, but
> Andrey> firstly I wish to know your, or somebody else, opinion.
>
> I honestly don't think the majority of your demands are valid.
> genalloc was meant to be simple, not an ultra fast at any random
> block size allocator. So far I don't see any reason for changing to
> the allocation algorithm into anything much more complex - doesn't
> mean there couldn't be a reason for doing so, but I don't think you
> have described any so far.
I disagree here, generic couldn't be very simple and slow, because in
this case simply no one will be use it, and hence we'll get today's
picture: reimplemented allocators in many drivers.
>
> You mentioned frame buffers, but what is the kernel supposed to do
> with those allocation wise? If you have a frame buffer console, the
> memory is allocated once and handed to the frame buffer driver.
> Ie. you don't need a ton of on demand allocations for that and for
> X, the memory management is handled in the X server, not by the
> kernel.
For video-only device this is true, but if device is a multifunctional,
which is frequent case in embedded systems, then kernel must control of
device memory allocation. Currently, however, even video cards for
desktops become more and more multifunctional (VIVO/audio etc.).
>
> The only thing I think would make sense to implement is to allow it to
> use indirect descriptor blocks for the memory it manages. This is not
> because it's wrong to use the memory for the free list, as it will
> only be used for this when the chunk is not in use, but because access
> to certain types of memory isn't always valid through normal direct
> access. Ie. if one used descriptor blocks residing in normal
> GFP_KERNEL memory, it would be possible to use the allocator to manage
> memory sitting on the other side of a PCI bus.
I describe above, why we couldn't/wouldn't use onboard memory for
allocator specific data.
Pantelis, Am I answered to your question (...what are you trying to
do...) too?
--
Regards
Andrey Volkov
^ 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