* Re: back trace when a SIGSEGV
From: Dustin Lang @ 2005-12-05 1:20 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev, Redondo Garcia, Roberto
In-Reply-To: <1133734477.6100.101.camel@gaston>
Hi,
> You don't need to play the cop on this list, nobody appointed you to
> that position.
Fair enough. But do you think my reply, over all, was unreasonable?[1] I
made an attempt to answer his question, pointing out two of the most
useful resources. I also told him that his question wasn't really suited
to the list - I would have listed some better resources but I'm not
familiar with any - but I tried to write a balanced,
gentle-push-in-the-right-direction, sort of message. Re-reading the
snippet you highlighted, it does sound rude. It wasn't meant to be.
(Roberto, please accept my apologies!)
Anyway, I'll go back to my lurking now.
Cheers,
dstn.
[1] Rhetorical question. If you feel like replying, can I suggest we take
it off-list? (Not trying to be a list-cop or anything, of course... :)
^ permalink raw reply
* Re: [PATCH 2.6.15-rc4] ppc32: Fixes for non-zero PPC_MEMSTART on PPC440
From: Benjamin Herrenschmidt @ 2005-12-05 0:22 UTC (permalink / raw)
To: Jason Gunthorpe; +Cc: linuxppc-embedded
In-Reply-To: <20051202080711.GA32759@obsidianresearch.com>
On Fri, 2005-12-02 at 01:07 -0700, Jason Gunthorpe wrote:
> I have a custom embedded system with a 440GP derived CPU that places the
> memory starting at 0xc0000000 which requires a non-zero PPC_MEMSTART. There
> are a couple of places that assume PPC_MEMSTART is 0. This results in
> various tricky crashing during booting. Most of the problems are
> not accounting for PPC_MEMSTART during va/pa translations. My fixes
> convert these places to use pre-existing macros instead of duplicating
> the calculation.
Just out of curiosity: why did you do such a bogus setup in the first
place ?
Ben.
^ permalink raw reply
* problem during kernel init with mmu_off
From: Saari, James @ 2005-12-04 22:39 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 2932 bytes --]
I would seem to be in much the same bad place; can you tell my how you
resolved your issue?
problem during kernel init with mmu_off
Stuart Yoder stuart.yoder at conformative.com
<mailto:linuxppc-embedded%40ozlabs.org?Subject=problem%20during%20kernel
%20init%20with%20mmu_off&In-Reply-To=>
Fri Mar 12 01:28:25 EST 2004
* Previous message: unable to input in u-boot at Lite5200
<http://ozlabs.org/pipermail/linuxppc-embedded/2004-March/013598.html>
* Next message: Can't set the schedual parameter of threads in
linux
<http://ozlabs.org/pipermail/linuxppc-embedded/2004-March/013592.html>
* Messages sorted by: [ date ]
<http://ozlabs.org/pipermail/linuxppc-embedded/2004-March/date.html#1359
1> [ thread ]
<http://ozlabs.org/pipermail/linuxppc-embedded/2004-March/thread.html#13
591> [ subject ]
<http://ozlabs.org/pipermail/linuxppc-embedded/2004-March/subject.html#1
3591> [ author ]
<http://ozlabs.org/pipermail/linuxppc-embedded/2004-March/author.html#13
591>
_____
I am trying to boot the 2.4 PPC kernel on a PPC750FX eval board. The
bootloader in the boards firmware has the mmu _on_ with block addr
translation enabled. It seems that all the BAT mappings are 1:1.
The kernel source as well as comments in the archive of this mailing
list
indicate that the mmu being on during kernel initialization should not
be an
issue.
However, I've determined through leds and uart that the kernel makes it
to
the RFI in mmu_off, but from that point goes into never-never land (I
can't
tell exactly what happened).
I've verified that the values in SRR0 and SRR1 are what is expected
prior to
the RFI which is supposed to turn the mmu off.
I also tried using MTMSR instead of RFI to turn the mmu off but the
processor seems to halt at that instruction.
I don't have a jtag debugger (yet) so I'm relying on leds and uart to
debug.
I really have no idea of the state of the chip after the RFI or MTMSR.
Anyone out there have any ideas? Anything about the 750FX that is
different than other processors?
Thanks,
Stuart Yoder
----------------------------------------------------------------
James E P Saari, Systems Engineer, Defense Electronics Group
Mercury Computer Systems, Inc. http://www.mc.com
<blocked::blocked::blocked::http://www.mc.com/>
1800 Alexander Bell Drive, Suite 100, Reston VA 20191
O: 703-673-2700 800-969-6702 D: 703-673-2717
F: 703-673-2727 800-969-8578
E-Mail mailto:jsaari@mc.com
<blocked::blocked::blocked::mailto:jsaari@mc.com> (Personal)
mailto:jamesepsaari@cox.net
<blocked::blocked::blocked::mailto:jamesepsaari@cox.net>
Internal: x2717 http://home.mc.com/~jsaari
<blocked::blocked::blocked::http://home.mc.com/~jsaari>
-- [ ] --
Website of the week: http://biz.yahoo.com/special/drucker05.html
"Exploit change as an opportunity, and don't view it as a threat." -
Peter Drucker
[-- Attachment #2: Type: text/html, Size: 4848 bytes --]
^ permalink raw reply
* Re: PowerBook5,8 - TrackPad update
From: Michael Hanselmann @ 2005-12-04 22:42 UTC (permalink / raw)
To: Stelian Pop
Cc: linuxppc-dev, johannes, debian-powerpc, linux-kernel,
Parag Warudkar
In-Reply-To: <1133533712.23129.25.camel@localhost.localdomain>
On Fri, Dec 02, 2005 at 03:28:31PM +0100, Stelian Pop wrote:
> Is this version really working well on the new Powerbooks ? From what
> I've seen in this thread there are still issues and it's still a work
> in progress, so it may be too early to integrate the changes in the
> kernel.
It works fine for the 15" PowerBooks (Oct 2005) and has been tested by
at least three people. 17" should work too, but I can't test that until
later this week.
> +#if defined(CONFIG_RELAYFS_FS) || defined(CONFIG_RELAYFS_FS_MODULE)
> +#include <linux/relayfs_fs.h>
> +#endif
> While the relayfs code is ok for debugging, I'm wondering if it should
> be left in the final version at all.
It doesn't hurt as it's not much code, it makes updating the driver for
newer devices easier and it's only enabled if requested. Because of
that, I would leave it in. However, I can split it into a separate patch
if wanted.
> + int overflowwarn; /* overflow warning printed? */
> I would use a static variable in the case -OVERFLOW: block here.
As there could be, due to whatever reason, multiple devices using the
same driver, one could overflow while another doesn't. Therefore, it
should be device specific.
> + dev->xy_cur[i++] = dev->data[19];
> + dev->xy_cur[i++] = dev->data[20];
> + dev->xy_cur[i++] = dev->data[22];
> + dev->xy_cur[i++] = dev->data[23];
> There is obviously a pattern here:
> for (i = 0; i < 15; i++)
> dev->xy_cur[i] = dev->data[ 19 + (i * 3) / 2 ]
It's not that easy. This code wouldn't work as it should.
I wrote a working loop into the patch below, but as the code's called
about 1'000 times a second I unrolled the loop myself. A friend of mine
calculated that the code would take at least twice the time to run when
written using a loop.
> I'm wondering if the same formula doesn't apply for more X and Y
> sensors (like 16 X and 16 Y sensors on the old Powerbooks, 26 for the
> 17" models)
It does and is addressed in the new patch below.
> What is the point in doing this since the dbg_dump is called a few lines
> later ?
Those were some leftovers from my debugging and would have been deleted
before submitting. I just didn't want to take everything out if someone
else wants to do some extensive debugging or so.
Here's an updated patch including support for the 17" PowerBooks (Oct
2005). The informations about the 17" one are from Alex Harper.
---
--- linux-2.6.15-rc5/drivers/usb/input/appletouch.c.orig 2005-12-04 20:25:21.000000000 +0100
+++ linux-2.6.15-rc5/drivers/usb/input/appletouch.c 2005-12-04 23:37:29.000000000 +0100
@@ -6,9 +6,19 @@
* 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 2005 - Michael Hanselmann
+ * o Compile relayfs support only if enabled in the kernel
+ * o Enable relayfs only if requested by the user
+ * o Added support for new October 2005 PowerBooks (Geyser 2)
+ *
* 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,8 +45,13 @@
#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
+#define GEYSER_2_PRODUCT_ID 0x0215
#define ATP_DEVICE(prod) \
.match_flags = USB_DEVICE_ID_MATCH_DEVICE | \
@@ -51,14 +66,17 @@
static struct usb_device_id atp_table [] = {
{ ATP_DEVICE(0x020E) },
{ ATP_DEVICE(0x020F) },
+ { ATP_DEVICE(GEYSER_2_PRODUCT_ID) }, /* PowerBooks Oct 2005 */
{ ATP_DEVICE(0x030A) },
{ ATP_DEVICE(0x030B) },
{ } /* Terminating entry */
};
MODULE_DEVICE_TABLE (usb, atp_table);
-/* size of a USB urb transfer */
-#define ATP_DATASIZE 81
+#if defined(CONFIG_RELAYFS_FS) || defined(CONFIG_RELAYFS_FS_MODULE)
+struct rchan* rch = NULL;
+struct rchan_callbacks* rcb = NULL;
+#endif
/*
* number of sensors. Note that only 16 instead of 26 X (horizontal)
@@ -73,6 +91,7 @@
/* 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
@@ -108,6 +127,8 @@
signed char xy_old[ATP_XSENSORS + ATP_YSENSORS];
/* accumulated sensors */
int xy_acc[ATP_XSENSORS + ATP_YSENSORS];
+ int overflowwarn; /* overflow warning printed? */
+ int datalen; /* size of an USB urb transfer */
};
#define dbg_dump(msg, tab) \
@@ -124,7 +145,11 @@
if (debug) printk(format, ##a); \
} while (0)
-MODULE_AUTHOR("Johannes Berg, Stelian Pop, Frank Arnold");
+/* Checks if the device a Geyser 2 */
+#define IS_GEYSER_2(dev) \
+ (le16_to_cpu(dev->udev->descriptor.idProduct) == GEYSER_2_PRODUCT_ID)
+
+MODULE_AUTHOR("Johannes Berg, Stelian Pop, Frank Arnold, Parag Warudkar, Michael Hanselmann");
MODULE_DESCRIPTION("Apple PowerBooks USB touchpad driver");
MODULE_LICENSE("GPL");
@@ -132,6 +157,10 @@
module_param(debug, int, 0644);
MODULE_PARM_DESC(debug, "Activate debugging output");
+static int relayfs = 0;
+module_param(relayfs, int, 0644);
+MODULE_PARM_DESC(relayfs, "Activate relayfs support");
+
static int atp_calculate_abs(int *xy_sensors, int nb_sensors, int fact,
int *z, int *fingers)
{
@@ -175,6 +204,13 @@
case 0:
/* success */
break;
+ case -EOVERFLOW:
+ if(!dev->overflowwarn) {
+ printk("appletouch: OVERFLOW with data "
+ "length %d, actual length is %d\n",
+ dev->datalen, dev->urb->actual_length);
+ dev->overflowwarn = 1;
+ }
case -ECONNRESET:
case -ENOENT:
case -ESHUTDOWN:
@@ -189,23 +225,83 @@
}
/* drop incomplete datasets */
- if (dev->urb->actual_length != ATP_DATASIZE) {
+ if (dev->urb->actual_length != dev->datalen) {
dprintk("appletouch: incomplete data package.\n");
goto exit;
}
+#if defined(CONFIG_RELAYFS_FS) || defined(CONFIG_RELAYFS_FS_MODULE)
+ if (relayfs && dev->data) {
+ relay_write(rch, dev->data, dev->urb->actual_length);
+ }
+#endif
+
/* reorder the sensors values */
- for (i = 0; i < 8; i++) {
+ if (IS_GEYSER_2(dev)) {
+ memset(dev->xy_cur, 0, sizeof(dev->xy_cur));
+
+ /*
+ * The values are laid out like this:
+ * Y1, Y2, -, Y3, Y4, -, ...
+ * '-' is an unused value.
+ *
+ * The logic in a loop:
+ * for (i = 0, j = 19; i < 20; i += 2, j += 3) {
+ * dev->xy_cur[i] = dev->data[j];
+ * dev->xy_cur[i + 1] = dev->data[j + 1];
+ * }
+ *
+ * This code is called about 1'000 times per second for each
+ * interrupt from the touchpad. Therefore it should be as fast
+ * as possible. Writing the following code in a loop would take
+ * about twice the time to run if not more.
+ */
+
/* X values */
- dev->xy_cur[i ] = dev->data[5 * i + 2];
- dev->xy_cur[i + 8] = dev->data[5 * i + 4];
- dev->xy_cur[i + 16] = dev->data[5 * i + 42];
- if (i < 2)
- dev->xy_cur[i + 24] = dev->data[5 * i + 44];
+ dev->xy_cur[0] = dev->data[19];
+ dev->xy_cur[1] = dev->data[20];
+ dev->xy_cur[2] = dev->data[22];
+ dev->xy_cur[3] = dev->data[23];
+ dev->xy_cur[4] = dev->data[25];
+ dev->xy_cur[5] = dev->data[26];
+ dev->xy_cur[6] = dev->data[28];
+ dev->xy_cur[7] = dev->data[29];
+ dev->xy_cur[8] = dev->data[31];
+ dev->xy_cur[9] = dev->data[32];
+ dev->xy_cur[10] = dev->data[34];
+ dev->xy_cur[11] = dev->data[35];
+ dev->xy_cur[12] = dev->data[37];
+ dev->xy_cur[13] = dev->data[38];
+ dev->xy_cur[14] = dev->data[40];
+ dev->xy_cur[15] = dev->data[41];
+ dev->xy_cur[16] = dev->data[43];
+ dev->xy_cur[17] = dev->data[44];
+ dev->xy_cur[18] = dev->data[46];
+ dev->xy_cur[19] = dev->data[47];
/* Y values */
- dev->xy_cur[i + 26] = dev->data[5 * i + 1];
- dev->xy_cur[i + 34] = dev->data[5 * i + 3];
+ dev->xy_cur[ATP_XSENSORS + 0] = dev->data[1];
+ dev->xy_cur[ATP_XSENSORS + 1] = dev->data[2];
+ dev->xy_cur[ATP_XSENSORS + 2] = dev->data[4];
+ dev->xy_cur[ATP_XSENSORS + 3] = dev->data[5];
+ dev->xy_cur[ATP_XSENSORS + 4] = dev->data[7];
+ dev->xy_cur[ATP_XSENSORS + 5] = dev->data[8];
+ dev->xy_cur[ATP_XSENSORS + 6] = dev->data[10];
+ dev->xy_cur[ATP_XSENSORS + 7] = dev->data[11];
+ dev->xy_cur[ATP_XSENSORS + 8] = dev->data[13];
+ } else {
+ for (i = 0; i < 8; i++) {
+ /* X values */
+ dev->xy_cur[i ] = dev->data[5 * i + 2];
+ dev->xy_cur[i + 8] = dev->data[5 * i + 4];
+ dev->xy_cur[i + 16] = dev->data[5 * i + 42];
+ if (i < 2)
+ dev->xy_cur[i + 24] = dev->data[5 * i + 44];
+
+ /* Y values */
+ dev->xy_cur[i + 26] = dev->data[5 * i + 1];
+ dev->xy_cur[i + 34] = dev->data[5 * i + 3];
+ }
}
dbg_dump("sample", dev->xy_cur);
@@ -216,16 +312,23 @@
dev->x_old = dev->y_old = -1;
memcpy(dev->xy_old, dev->xy_cur, sizeof(dev->xy_old));
- /* 17" Powerbooks have 10 extra X sensors */
- for (i = 16; i < ATP_XSENSORS; i++)
- if (dev->xy_cur[i]) {
- printk("appletouch: 17\" model detected.\n");
+ /* 17" Powerbooks have extra X sensors */
+ for (i = (IS_GEYSER_2(dev)?15:16); i < ATP_XSENSORS; i++) {
+ if (!dev->xy_cur[i]) continue;
+
+ printk("appletouch: 17\" model detected.\n");
+ if(IS_GEYSER_2(dev))
+ input_set_abs_params(dev->input, ABS_X, 0,
+ (20 - 1) *
+ ATP_XFACT - 1,
+ ATP_FUZZ, 0);
+ else
input_set_abs_params(dev->input, ABS_X, 0,
(ATP_XSENSORS - 1) *
ATP_XFACT - 1,
ATP_FUZZ, 0);
- break;
- }
+ break;
+ }
goto exit;
}
@@ -282,7 +385,8 @@
memset(dev->xy_acc, 0, sizeof(dev->xy_acc));
}
- input_report_key(dev->input, BTN_LEFT, !!dev->data[80]);
+ input_report_key(dev->input, BTN_LEFT,
+ !!dev->data[dev->datalen - 1]);
input_sync(dev->input);
@@ -323,7 +427,6 @@
int int_in_endpointAddr = 0;
int i, retval = -ENOMEM;
-
/* set up the endpoint information */
/* use only the first interrupt-in endpoint */
iface_desc = iface->cur_altsetting;
@@ -353,6 +456,8 @@
dev->udev = udev;
dev->input = input_dev;
+ dev->overflowwarn = 0;
+ dev->datalen = (IS_GEYSER_2(dev)?64:81);
dev->urb = usb_alloc_urb(0, GFP_KERNEL);
if (!dev->urb) {
@@ -360,7 +465,7 @@
goto err_free_devs;
}
- dev->data = usb_buffer_alloc(dev->udev, ATP_DATASIZE, GFP_KERNEL,
+ dev->data = usb_buffer_alloc(dev->udev, dev->datalen, GFP_KERNEL,
&dev->urb->transfer_dma);
if (!dev->data) {
retval = -ENOMEM;
@@ -369,7 +474,7 @@
usb_fill_int_urb(dev->urb, udev,
usb_rcvintpipe(udev, int_in_endpointAddr),
- dev->data, ATP_DATASIZE, atp_complete, dev, 1);
+ dev->data, dev->datalen, atp_complete, dev, 1);
usb_make_path(udev, dev->phys, sizeof(dev->phys));
strlcat(dev->phys, "/input0", sizeof(dev->phys));
@@ -385,14 +490,25 @@
set_bit(EV_ABS, input_dev->evbit);
- /*
- * 12" and 15" Powerbooks only have 16 x sensors,
- * 17" models are detected later.
- */
- input_set_abs_params(input_dev, ABS_X, 0,
- (16 - 1) * ATP_XFACT - 1, ATP_FUZZ, 0);
- input_set_abs_params(input_dev, ABS_Y, 0,
- (ATP_YSENSORS - 1) * ATP_YFACT - 1, ATP_FUZZ, 0);
+ if (IS_GEYSER_2(dev)) {
+ /*
+ * Oct 2005 15" PowerBooks have 15 X sensors, 17" are detected
+ * later.
+ */
+ input_set_abs_params(input_dev, ABS_X, 0,
+ ((15 - 1) * ATP_XFACT) - 1, ATP_FUZZ, 0);
+ input_set_abs_params(input_dev, ABS_Y, 0,
+ ((9 - 1) * ATP_YFACT) - 1, ATP_FUZZ, 0);
+ } else {
+ /*
+ * 12" and 15" Powerbooks only have 16 x sensors,
+ * 17" models are detected later.
+ */
+ input_set_abs_params(input_dev, ABS_X, 0,
+ (16 - 1) * ATP_XFACT - 1, ATP_FUZZ, 0);
+ input_set_abs_params(input_dev, ABS_Y, 0,
+ (ATP_YSENSORS - 1) * ATP_YFACT - 1, ATP_FUZZ, 0);
+ }
input_set_abs_params(input_dev, ABS_PRESSURE, 0, ATP_PRESSURE, 0, 0);
set_bit(EV_KEY, input_dev->evbit);
@@ -427,7 +543,7 @@
usb_kill_urb(dev->urb);
input_unregister_device(dev->input);
usb_free_urb(dev->urb);
- usb_buffer_free(dev->udev, ATP_DATASIZE,
+ usb_buffer_free(dev->udev, dev->datalen,
dev->data, dev->urb->transfer_dma);
kfree(dev);
}
@@ -463,11 +579,30 @@
static int __init atp_init(void)
{
+#if defined(CONFIG_RELAYFS_FS) || defined(CONFIG_RELAYFS_FS_MODULE)
+ if (relayfs) {
+ rcb = kmalloc(sizeof(struct rchan_callbacks), GFP_KERNEL);
+ rcb->subbuf_start = NULL;
+ rcb->buf_mapped = NULL;
+ rcb->buf_unmapped = NULL;
+ rch = relay_open("atpdata", NULL, 256, 256, NULL);
+ if (!rch) 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 (relayfs) {
+ relay_close(rch);
+ kfree(rcb);
+ }
+#endif
usb_deregister(&atp_driver);
}
^ permalink raw reply
* MPC8272ADS stability issues
From: Liechty Ronald-RAT109 @ 2005-12-04 22:36 UTC (permalink / raw)
To: linuxppc-embedded
Hello,
Please excuse my intrusion into this mail group. Usually I subscribe
and read the messages for a while before I post. However, it was
brought to Freescale's attention that there was a thread that needed
addressing.
I want to thank you all for reporting this stability issue with the
boards. We were aware of some problems and are working hard to
straighten them out, in particular problems with the Flash SIMMs. If
you have a board which you even question please contact Freescale for
new Flash SIMMs or to get a replacement for your board. =20
Freescale and Developer Technology group within Freescale strives for
the highest quality and anything less is unacceptable. I personally
wish to apologize for any inconvenience this has caused anyone. =20
Finally I will be monitory this message list and reporting to those who
can make differences all that I see here. If you wish to write to me
directly please do so.
I'm sorry for the delay in responding to this issue.
Ron
-- =20
Ron Liechty =20
Ombudsman Freescale Developer Technology
ron.liechty@freescale.com=20
^ permalink raw reply
* Re: back trace when a SIGSEGV
From: Benjamin Herrenschmidt @ 2005-12-04 22:16 UTC (permalink / raw)
To: Redondo Garcia, Roberto; +Cc: linuxppc-dev
In-Reply-To: <6A28467355D2AD478D1F51C479415AE77B47E9@MADTORMAIL.indra.es>
On Fri, 2005-12-02 at 11:33 +0100, Redondo Garcia, Roberto wrote:
> hello,
> I have a program that when it has been several hours running, it has a
> problem and falls and it produces a SIGSEGV. I would like to know to
> how debug this error, because I do not have ulimit for generate core
> dump o examine a back trace.
You can run your program under gdb, or you may want to have a look at
tridge' junk code directory for his segv_handler bit that you can put in
LD_PRELOAD
http://www.samba.org/junkcode/#segv_handler
Ben.
^ permalink raw reply
* Re: back trace when a SIGSEGV
From: Benjamin Herrenschmidt @ 2005-12-04 22:14 UTC (permalink / raw)
To: Dustin Lang; +Cc: linuxppc-dev, Redondo Garcia, Roberto
In-Reply-To: <Pine.LNX.4.60.0512020612540.4326@tin.icics.ubc.ca>
> However, this mailing list is for _development_ of the linux _kernel_ on
> PowerPC. Your question is not about kernel development so it doesn't
> belong here. (Unless you are sure that your program is correct and
> somehow the kernel is unfairly giving you a segfault - which doesn't seem
> to be the case, based on your message.) Find a mailing list or message
> board about userspace programming and ask your question there.
>
> .../...
You don't need to play the cop on this list, nobody appointed you to
that position.
Ben.
^ permalink raw reply
* Re: [PATCH] include/asm-ppc/btext.h: add prototype of btext_init function.
From: Geert Uytterhoeven @ 2005-12-04 21:13 UTC (permalink / raw)
To: Andrew Morton; +Cc: Linux/PPC Development, otavio
In-Reply-To: <20051203160020.42d1da3c.akpm@osdl.org>
On Sat, 3 Dec 2005, Andrew Morton wrote:
> Eugene Surovegin <ebs@ebshome.net> wrote:
> > > +extern void __init btext_init(boot_infos_t *bi);
> > > extern void btext_welcome(void);
> > > extern void btext_prepare_BAT(void);
> > > extern void btext_setup_display(int width, int height, int depth, int pitch,
> >
> > "__init" should be placed between closing brace and semicolon. For
> > more info, see include/linux/init.h
>
> I don't think it matters much. Often we just omit it from the declaration
> - it's only required at the definition site
IIRC, on Alpha it's needed/recommended on both, to allow the compiler to
optimize jumps to the same section?
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: 回复:Re: mfspr r0,638. Why 638 ?
From: Wolfgang Denk @ 2005-12-04 10:18 UTC (permalink / raw)
To: zengshuai; +Cc: ppc
In-Reply-To: <14801389.1133657729738.JavaMail.postfix@mx3.mail.sohu.com>
In message <14801389.1133657729738.JavaMail.postfix@mx3.mail.sohu.com> you wrote:
>
> but how we can get IMMR in PQ2 ? still "mfspr r0,638"?
Instead of asking here you should read the PQ2 User's Manual.
Best regards,
Wolfgang Denk
--
Software Engineering: Embedded and Realtime Systems, Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
If at first you don't succeed, you are running about average.
^ permalink raw reply
* Re: [PATCH] include/asm-ppc/btext.h: add prototype of btext_init function.
From: Paul Mackerras @ 2005-12-04 2:21 UTC (permalink / raw)
To: Eugene Surovegin; +Cc: akpm, linuxppc-dev, Otavio Salvador
In-Reply-To: <20051203212402.GA2821@gate.ebshome.net>
Eugene Surovegin writes:
> "__init" should be placed between closing brace and semicolon. For
> more info, see include/linux/init.h
Actually, there's no point putting __init in an extern declaration.
Paul.
^ permalink raw reply
* 回复:Re: mfspr r0,638. Why 638 ?
From: zengshuai @ 2005-12-04 0:55 UTC (permalink / raw)
To: Kumar Gala; +Cc: ppc
thanks.i have found it.
but how we can get IMMR in PQ2 ? still "mfspr r0,638"?
----- 原文 -----
From: Kumar Gala
Cc: ppc
Subject: Re: mfspr r0,638. Why 638 ?
Sent: Sun Dec 04 00:16:50 CST 2005
> This is 8xx (PQ1) SPR. If you look one of those user manuals you
> will see it.
>
> - kumar
>
> On Dec 3, 2005, at 4:38 AM, <zengshuai@sogou.com>
> <zengshuai@sogou.com> wrote:
>
> > We know "mfspr r0,638" can get the IMMR.
> > But why?
> > I checked "MPC82xx Reference Manual","G2 PowerPC™ Core
> > Reference Manual","Programming Environments Manual",
> > but I didn't find any word about that.How did the person who first
> > known know?
> >
> > "G2 PowerPC™ Core Reference Manual" where is the "SPR 638"?
> > Table 3-33. Implementation-Specific SPR Encodings (mfspr)
> > Decimal spr[5?9] spr[0?4] RegisterName Access
> > 58 00001 11010 CSRR0 Supervisor
> > 59 00001 11011 CSRR1 Supervisor
> > 276 01000 10100 SPRG4 Supervisor
> > 277 01000 10101 SPRG5 Supervisor
> > 278 01000 10110 SPRG6 Supervisor
> > 279 01000 10111 SPRG7 Supervisor
> > 286 01000 11110 SVR Supervisor
> > 309 01001 10101 IBCR Supervisor
> > 310 01001 10110 DBCR Supervisor
> > 311 01001 10111 MBAR Supervisor
> > 317 01001 11101 DABR2 Supervisor
> > 560 10001 10000 IBAT4U Supervisor
> > 561 10001 10001 IBAT4L Supervisor
> > 562 10001 10010 IBAT5U Supervisor
> > 563 10001 10011 IBAT5L Supervisor
> > 564 10001 10100 IBAT6U Supervisor
> > 565 10001 10101 IBAT6L Supervisor
> > 566 10001 10110 IBAT7U Supervisor
> > 567 10001 10111 IBAT7L Supervisor
> > 568 10001 11000 DBAT4U Supervisor
> > 569 10001 11001 DBAT4L Supervisor
> > 570 10001 11010 DBAT5U Supervisor
> > 571 10001 11011 DBAT5L Supervisor
> > 572 10001 11100 DBAT6U Supervisor
> > 573 10001 11101 DBAT6L Supervisor
> > 574 10001 11110 DBAT7U Supervisor
> > 575 10001 11111 DBAT7L Supervisor
> > 976 11110 10000 DMISS Supervisor
> > 977 11110 10001 DCMP Supervisor
> > 978 11110 10010 HASH1 Supervisor
> > 979 11110 10011 HASH2 Supervisor
> > 980 11110 10100 IMISS Supervisor
> > 981 11110 10101 ICMP Supervisor
> > 982 11110 10110 RPA Supervisor
> > 1008 11111 10000 HID0 Supervisor
> > 1009 11111 10001 HID1 Supervisor
> > 1010 11111 10010 IABR Supervisor
> > 1011 11111 10011 HID2 Supervisor
> > 1013 11111 10101 DABR Supervisor
> > 1018 11111 11010 IABR2 Supervisor
> >
> > ------------------------------
> > 我现在使用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
> >
> > _______________________________________________
> > Linuxppc-embedded mailing list
> > Linuxppc-embedded@ozlabs.org
> > https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
------------------------------
我现在使用Sogou.com的2G邮箱了，你也来试试吧!
http://mail.sogou.com/recommend/sogoumail_invite_reg1.jsp?from=sogouinvitation&s_EMAIL=zengshuai%40sogou.com&username=&FullName=&Email=&verify=e197bd6dbd1fc7f8d6a035729df08d63
^ permalink raw reply
* Re: [PATCH] include/asm-ppc/btext.h: add prototype of btext_init function.
From: Eugene Surovegin @ 2005-12-04 0:12 UTC (permalink / raw)
To: Andrew Morton; +Cc: linuxppc-dev, otavio
In-Reply-To: <20051203160020.42d1da3c.akpm@osdl.org>
On Sat, Dec 03, 2005 at 04:00:20PM -0800, Andrew Morton wrote:
> Eugene Surovegin <ebs@ebshome.net> wrote:
> >
> > > +extern void __init btext_init(boot_infos_t *bi);
> > > extern void btext_welcome(void);
> > > extern void btext_prepare_BAT(void);
> > > extern void btext_setup_display(int width, int height, int depth, int pitch,
> >
> > "__init" should be placed between closing brace and semicolon. For
> > more info, see include/linux/init.h
>
> I don't think it matters much. Often we just omit it from the declaration
> - it's only required at the definition site
Quite likely it doesn't matter, but I think we should follow existing
style, if not for correctness, but at least for consistency (it
actually caught my eye exactly because it _looked_ different). I'm
pretty sure original poster have tested original version :).
--
Eugene
^ permalink raw reply
* Re: [PATCH] include/asm-ppc/btext.h: add prototype of btext_init function.
From: Andrew Morton @ 2005-12-04 0:00 UTC (permalink / raw)
To: Eugene Surovegin; +Cc: linuxppc-dev, otavio
In-Reply-To: <20051203212402.GA2821@gate.ebshome.net>
Eugene Surovegin <ebs@ebshome.net> wrote:
>
> > +extern void __init btext_init(boot_infos_t *bi);
> > extern void btext_welcome(void);
> > extern void btext_prepare_BAT(void);
> > extern void btext_setup_display(int width, int height, int depth, int pitch,
>
> "__init" should be placed between closing brace and semicolon. For
> more info, see include/linux/init.h
I don't think it matters much. Often we just omit it from the declaration
- it's only required at the definition site
^ permalink raw reply
* [PATCH] include/asm-ppc/btext.h: add prototype of btext_init function.
From: Otavio Salvador @ 2005-12-03 21:33 UTC (permalink / raw)
To: linuxppc-dev, akpm, Eugene Surovegin; +Cc: Otavio Salvador
In-Reply-To: <20051203212402.GA2821@gate.ebshome.net>
The prototype of btext_init function was missing and then caused a compile
warning.
---
include/asm-ppc/btext.h | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
applies-to: 60e8ae37378de2772b6b0768b12a49f923710152
19174aa31fd85e4410e99deb82c3b7ff2424fa55
diff --git a/include/asm-ppc/btext.h b/include/asm-ppc/btext.h
index ccaefab..2cf437c 100644
--- a/include/asm-ppc/btext.h
+++ b/include/asm-ppc/btext.h
@@ -18,6 +18,7 @@ extern boot_infos_t disp_bi;
extern int boot_text_mapped;
extern void init_boot_display(void);
+extern void btext_init(boot_infos_t *bi) __init;
extern void btext_welcome(void);
extern void btext_prepare_BAT(void);
extern void btext_setup_display(int width, int height, int depth, int pitch,
---
0.99.9k
^ permalink raw reply related
* Re: [PATCH] include/asm-ppc/btext.h: add prototype of btext_init function.
From: Otavio Salvador @ 2005-12-03 21:31 UTC (permalink / raw)
To: linuxppc-dev; +Cc: akpm
In-Reply-To: <20051203212402.GA2821@gate.ebshome.net>
Eugene Surovegin <ebs@ebshome.net> writes:
...
>> +extern void __init btext_init(boot_infos_t *bi);
...
>
> "__init" should be placed between closing brace and semicolon. For
> more info, see include/linux/init.h
Ok. Thanks, I'll resend the patch.
--
O T A V I O S A L V A D O R
---------------------------------------------
E-mail: otavio@debian.org UIN: 5906116
GNU/Linux User: 239058 GPG ID: 49A5F855
Home Page: http://www.freedom.ind.br/otavio
---------------------------------------------
"Microsoft gives you Windows ... Linux gives
you the whole house."
^ permalink raw reply
* Re: [PATCH] include/asm-ppc/btext.h: add prototype of btext_init function.
From: Eugene Surovegin @ 2005-12-03 21:24 UTC (permalink / raw)
To: Otavio Salvador; +Cc: akpm, linuxppc-dev
In-Reply-To: <11336368261610-git-send-email-otavio@debian.org>
On Sat, Dec 03, 2005 at 05:07:06PM -0200, Otavio Salvador wrote:
> The prototype of btext_init function was missing and then caused a compile
> warning.
>
> ---
>
> include/asm-ppc/btext.h | 1 +
> 1 files changed, 1 insertions(+), 0 deletions(-)
>
> applies-to: 60e8ae37378de2772b6b0768b12a49f923710152
> 786b869f9cfd4c1f82fbc8b20fa8cafb9188e12f
> diff --git a/include/asm-ppc/btext.h b/include/asm-ppc/btext.h
> index ccaefab..2329331 100644
> --- a/include/asm-ppc/btext.h
> +++ b/include/asm-ppc/btext.h
> @@ -18,6 +18,7 @@ extern boot_infos_t disp_bi;
> extern int boot_text_mapped;
>
> extern void init_boot_display(void);
> +extern void __init btext_init(boot_infos_t *bi);
> extern void btext_welcome(void);
> extern void btext_prepare_BAT(void);
> extern void btext_setup_display(int width, int height, int depth, int pitch,
"__init" should be placed between closing brace and semicolon. For
more info, see include/linux/init.h
--
Eugene
^ permalink raw reply
* Re: [PATCH] arch/ppc/kernel/idle.c: don't declare cpu variable in non-SMP kernels
From: Nathan Lynch @ 2005-12-03 19:00 UTC (permalink / raw)
To: Otavio Salvador; +Cc: akpm, linuxppc-dev
In-Reply-To: <11336348593561-git-send-email-otavio@debian.org>
> diff --git a/arch/ppc/kernel/idle.c b/arch/ppc/kernel/idle.c
> index 821a75e..b23a979 100644
> --- a/arch/ppc/kernel/idle.c
> +++ b/arch/ppc/kernel/idle.c
> @@ -37,7 +37,9 @@
> void default_idle(void)
> {
> void (*powersave)(void);
> +#ifdef CONFIG_SMP
> int cpu = smp_processor_id();
> +#endif
Better to just move the declaration of cpu down to the ifdef'd else
block further down in the function as that's the only place it is
used.
^ permalink raw reply
* [PATCH] include/asm-ppc/btext.h: add prototype of btext_init function.
From: Otavio Salvador @ 2005-12-03 19:07 UTC (permalink / raw)
To: linuxppc-dev, akpm; +Cc: Otavio Salvador
The prototype of btext_init function was missing and then caused a compile
warning.
---
include/asm-ppc/btext.h | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
applies-to: 60e8ae37378de2772b6b0768b12a49f923710152
786b869f9cfd4c1f82fbc8b20fa8cafb9188e12f
diff --git a/include/asm-ppc/btext.h b/include/asm-ppc/btext.h
index ccaefab..2329331 100644
--- a/include/asm-ppc/btext.h
+++ b/include/asm-ppc/btext.h
@@ -18,6 +18,7 @@ extern boot_infos_t disp_bi;
extern int boot_text_mapped;
extern void init_boot_display(void);
+extern void __init btext_init(boot_infos_t *bi);
extern void btext_welcome(void);
extern void btext_prepare_BAT(void);
extern void btext_setup_display(int width, int height, int depth, int pitch,
---
0.99.9k
^ permalink raw reply related
* Re: [PATCH] arch/ppc/kernel/idle.c: don't declare cpu variable in non-SMP kernels
From: Andrew Morton @ 2005-12-03 18:46 UTC (permalink / raw)
To: Otavio Salvador; +Cc: linuxppc-dev
In-Reply-To: <11336348593561-git-send-email-otavio@debian.org>
Otavio Salvador <otavio@debian.org> wrote:
>
> Disable declaration of cpu variable in default_idle function when
> building non-SMP kernels.
>
> --- a/arch/ppc/kernel/idle.c
> +++ b/arch/ppc/kernel/idle.c
> @@ -37,7 +37,9 @@
> void default_idle(void)
> {
> void (*powersave)(void);
> +#ifdef CONFIG_SMP
> int cpu = smp_processor_id();
> +#endif
>
> powersave = ppc_md.power_save;
>
Surely this would be better?
--- devel/arch/ppc/kernel/idle.c~a 2005-12-03 10:45:37.000000000 -0800
+++ devel-akpm/arch/ppc/kernel/idle.c 2005-12-03 10:46:03.000000000 -0800
@@ -37,7 +37,6 @@
void default_idle(void)
{
void (*powersave)(void);
- int cpu = smp_processor_id();
powersave = ppc_md.power_save;
@@ -47,7 +46,8 @@ void default_idle(void)
#ifdef CONFIG_SMP
else {
set_thread_flag(TIF_POLLING_NRFLAG);
- while (!need_resched() && !cpu_is_offline(cpu))
+ while (!need_resched() &&
+ !cpu_is_offline(smp_processor_id()))
barrier();
clear_thread_flag(TIF_POLLING_NRFLAG);
}
_
^ permalink raw reply
* [PATCH] ppc/plataforms: removed unused variable i from code.
From: Otavio Salvador @ 2005-12-03 18:42 UTC (permalink / raw)
To: linuxppc-dev, akpm; +Cc: Otavio Salvador
---
arch/ppc/platforms/chrp_setup.c | 1 -
arch/ppc/platforms/prep_setup.c | 1 -
2 files changed, 0 insertions(+), 2 deletions(-)
applies-to: 8622c40782404c8fb13aa2a4dd4a7b0ebc44e896
66697dfc757179883127a3ae53bc486320b38374
diff --git a/arch/ppc/platforms/chrp_setup.c b/arch/ppc/platforms/chrp_setup.c
index f1b70ab..056ac2a 100644
--- a/arch/ppc/platforms/chrp_setup.c
+++ b/arch/ppc/platforms/chrp_setup.c
@@ -404,7 +404,6 @@ static struct irqaction xmon_irqaction =
void __init chrp_init_IRQ(void)
{
struct device_node *np;
- int i;
unsigned long chrp_int_ack = 0;
unsigned char init_senses[NR_IRQS - NUM_8259_INTERRUPTS];
#if defined(CONFIG_VT) && defined(CONFIG_INPUT_ADBHID) && defined(XMON)
diff --git a/arch/ppc/platforms/prep_setup.c b/arch/ppc/platforms/prep_setup.c
index 4415748..f4ef267 100644
--- a/arch/ppc/platforms/prep_setup.c
+++ b/arch/ppc/platforms/prep_setup.c
@@ -954,7 +954,6 @@ prep_calibrate_decr(void)
static void __init
prep_init_IRQ(void)
{
- int i;
unsigned int pci_viddid, pci_did;
if (OpenPIC_Addr != NULL) {
---
0.99.9k
^ permalink raw reply related
* (no subject)
From: Otavio Salvador @ 2005-12-03 18:40 UTC (permalink / raw)
To: linuxppc-dev, akpm
Cc: "code.", unused, "ppc/plataforms:removed", from,
"Subject:[PATCH]", variable, i
---
arch/ppc/platforms/chrp_setup.c | 1 -
arch/ppc/platforms/prep_setup.c | 1 -
2 files changed, 0 insertions(+), 2 deletions(-)
applies-to: 8622c40782404c8fb13aa2a4dd4a7b0ebc44e896
66697dfc757179883127a3ae53bc486320b38374
diff --git a/arch/ppc/platforms/chrp_setup.c b/arch/ppc/platforms/chrp_setup.c
index f1b70ab..056ac2a 100644
--- a/arch/ppc/platforms/chrp_setup.c
+++ b/arch/ppc/platforms/chrp_setup.c
@@ -404,7 +404,6 @@ static struct irqaction xmon_irqaction =
void __init chrp_init_IRQ(void)
{
struct device_node *np;
- int i;
unsigned long chrp_int_ack = 0;
unsigned char init_senses[NR_IRQS - NUM_8259_INTERRUPTS];
#if defined(CONFIG_VT) && defined(CONFIG_INPUT_ADBHID) && defined(XMON)
diff --git a/arch/ppc/platforms/prep_setup.c b/arch/ppc/platforms/prep_setup.c
index 4415748..f4ef267 100644
--- a/arch/ppc/platforms/prep_setup.c
+++ b/arch/ppc/platforms/prep_setup.c
@@ -954,7 +954,6 @@ prep_calibrate_decr(void)
static void __init
prep_init_IRQ(void)
{
- int i;
unsigned int pci_viddid, pci_did;
if (OpenPIC_Addr != NULL) {
---
0.99.9k
^ permalink raw reply related
* [PATCH] arch/ppc/kernel/idle.c: don't declare cpu variable in non-SMP kernels
From: Otavio Salvador @ 2005-12-03 18:34 UTC (permalink / raw)
To: linuxppc-dev, akpm; +Cc: Otavio Salvador
Disable declaration of cpu variable in default_idle function when
building non-SMP kernels.
Signed-off-by: Otavio Salvador <otavio@debian.org>
---
arch/ppc/kernel/idle.c | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
applies-to: 06378a021f5873003a07f0388aa0cb6e81a32c19
156ff805b4408c6831c7840c1ed1fe3d148bc3c8
diff --git a/arch/ppc/kernel/idle.c b/arch/ppc/kernel/idle.c
index 821a75e..b23a979 100644
--- a/arch/ppc/kernel/idle.c
+++ b/arch/ppc/kernel/idle.c
@@ -37,7 +37,9 @@
void default_idle(void)
{
void (*powersave)(void);
+#ifdef CONFIG_SMP
int cpu = smp_processor_id();
+#endif
powersave = ppc_md.power_save;
---
0.99.9k
^ permalink raw reply related
* Re: MPC85xx i2c interface bug
From: Dan Wilson @ 2005-12-03 17:22 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-embedded
In-Reply-To: <Pine.LNX.4.44.0511300013110.32230-100000@gate.crashing.org>
On 11/30/2005 at 12:14 AM Kumar Gala wrote:
> Dan,
>
> Did you see an issue this change fixed? If so can you provide more
> details. Also, can you provide your diff as a unified diff (diff -u) so
> its easier to see where the changes where.
>
> I'm trying to figure out if the same issue exists in the 2.6 driver (and
> if so, why we havent seen it)
>
> thanks
>
> - kumar
>
Kumar,
Did my last message provide all the information you needed? If you=
disagree with my proposed patch, I would greatly appreciate hearing your=
thoughts. If you need anything else, please let me know.
Regards,
Dan.
^ permalink raw reply
* Re: pq2_find_bridges hangs system
From: Alex BASTOS @ 2005-12-03 17:36 UTC (permalink / raw)
To: Vitaly Bordug; +Cc: linuxppc-embedded list
In-Reply-To: <4390604D.50002@ru.mvista.com>
Vitaly,
> Alex,
> please probe this. If it will not help, pq2ads_setup_pci should be digged for
> some board specifics.
>
I'll give it a try. Unfortunately (or fortunately), i won't be in the lab for
a week (i am on holidays). I will comment you then.
> Also, check if hose->set_cfg_type is 1 as done for ads8272.
>
Yes, it is.
Best regards,
Alex
> -------- Original Message --------
> Subject: [patch 01/34] ppc32: Fix incorrect PCI frequency value
> Date: Thu, 01 Dec 2005 00:51:15 -0800
> From: akpm@osdl.org
> To: torvalds@osdl.org
> CC: akpm@osdl.org, vbordug@ru.mvista.com, galak@kernel.crashing.org
>
>
> From: Vitaly Bordug <vbordug@ru.mvista.com>
>
> The time to wait after deasserting PCI_RST has been counted with incorrect
> value - this patch fixes the issue.
>
> Signed-off-by: Vitaly Bordug <vbordug@ru.mvista.com>
> Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
> Signed-off-by: Andrew Morton <akpm@osdl.org>
> ---
>
> arch/ppc/syslib/m82xx_pci.c | 3 ++-
> 1 files changed, 2 insertions(+), 1 deletion(-)
>
> diff -puN arch/ppc/syslib/m82xx_pci.c~ppc32-fix-incorrect-pci-frequency-value
> arch/ppc/syslib/m82xx_pci.c
> ---
>
devel/arch/ppc/syslib/m82xx_pci.c~ppc32-fix-incorrect-pci-frequency-value 2005-11-30
> 23:58:00.000000000 -0800
> +++ devel-akpm/arch/ppc/syslib/m82xx_pci.c 2005-11-30 23:58:00.000000000
> -0800
> @@ -248,7 +248,8 @@ pq2ads_setup_pci(struct pci_controller *
> pci_div = ( (sccr & SCCR_PCI_MODCK) ? 2 : 1) *
> ( ( (sccr & SCCR_PCIDF_MSK) >> SCCR_PCIDF_SHIFT) + 1);
> freq = (uint)((2*binfo->bi_cpmfreq)/(pci_div));
> - time = (int)666666/freq;
> + time = (int)66666666/freq;
> +
> /* due to PCI Local Bus spec, some devices needs to wait such a long
> time after RST deassertion. More specifically, 0.508s for 66MHz & twice
> more for 33 */
> printk("%s: The PCI bus is %d Mhz.\nWaiting %s after deasserting
> RST...\n",__FILE__,freq,
> _
>
>
>
> --
> Sincerely,
> Vitaly
>
^ permalink raw reply
* Re: mfspr r0,638. Why 638 ?
From: Kumar Gala @ 2005-12-03 16:16 UTC (permalink / raw)
To: zengshuai; +Cc: ppc
In-Reply-To: <7707540.1133606321114.JavaMail.postfix@mx3.mail.sohu.com>
This is 8xx (PQ1) SPR. If you look one of those user manuals you =20
will see it.
- kumar
On Dec 3, 2005, at 4:38 AM, <zengshuai@sogou.com> =20
<zengshuai@sogou.com> wrote:
> We know "mfspr r0,638" can get the IMMR.
> But why?
> I checked "MPC82xx Reference Manual","G2 PowerPC™ Core =20
> Reference Manual","Programming Environments Manual",
> but I didn't find any word about that.How did the person who first =20
> known know?
>
> "G2 PowerPC™ Core Reference Manual" where is the "SPR 638"?
> Table 3-33. Implementation-Specific SPR Encodings (mfspr)
> Decimal spr[5?9] spr[0?4] RegisterName Access
> 58 00001 11010 CSRR0 Supervisor
> 59 00001 11011 CSRR1 Supervisor
> 276 01000 10100 SPRG4 Supervisor
> 277 01000 10101 SPRG5 Supervisor
> 278 01000 10110 SPRG6 Supervisor
> 279 01000 10111 SPRG7 Supervisor
> 286 01000 11110 SVR Supervisor
> 309 01001 10101 IBCR Supervisor
> 310 01001 10110 DBCR Supervisor
> 311 01001 10111 MBAR Supervisor
> 317 01001 11101 DABR2 Supervisor
> 560 10001 10000 IBAT4U Supervisor
> 561 10001 10001 IBAT4L Supervisor
> 562 10001 10010 IBAT5U Supervisor
> 563 10001 10011 IBAT5L Supervisor
> 564 10001 10100 IBAT6U Supervisor
> 565 10001 10101 IBAT6L Supervisor
> 566 10001 10110 IBAT7U Supervisor
> 567 10001 10111 IBAT7L Supervisor
> 568 10001 11000 DBAT4U Supervisor
> 569 10001 11001 DBAT4L Supervisor
> 570 10001 11010 DBAT5U Supervisor
> 571 10001 11011 DBAT5L Supervisor
> 572 10001 11100 DBAT6U Supervisor
> 573 10001 11101 DBAT6L Supervisor
> 574 10001 11110 DBAT7U Supervisor
> 575 10001 11111 DBAT7L Supervisor
> 976 11110 10000 DMISS Supervisor
> 977 11110 10001 DCMP Supervisor
> 978 11110 10010 HASH1 Supervisor
> 979 11110 10011 HASH2 Supervisor
> 980 11110 10100 IMISS Supervisor
> 981 11110 10101 ICMP Supervisor
> 982 11110 10110 RPA Supervisor
> 1008 11111 10000 HID0 Supervisor
> 1009 11111 10001 HID1 Supervisor
> 1010 11111 10010 IABR Supervisor
> 1011 11111 10011 HID2 Supervisor
> 1013 11111 10101 DABR Supervisor
> 1018 11111 11010 IABR2 Supervisor
>
> ------------------------------
> =E6=88=91=E7=8E=B0=E5=9C=A8=E4=BD=BF=E7=94=A8Sogou.com=E7=9A=842G=E9=82=AE=
=E7=AE=B1=E4=BA=86=EF=BC=8C=E4=BD=A0=E4=B9=9F=E6=9D=A5=E8=AF=95=E8=AF=95=E5=
=90=A7!
> http://mail.sogou.com/recommend/sogoumail_invite_reg1.jsp?=20
> from=3Dsogouinvitation&s_EMAIL=3Dzengshuai%=20
> 40sogou.com&username=3Dlinuxppc-embedded&FullName=3Dlinuxppc-=20
> embedded&Email=3Dlinuxppc-embedded%=20
> 40ozlabs.org&verify=3D755eff4e640bdcfc57d93cbd8b0a9cb7
>
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
^ 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