Original-Nachricht
Datum: Wed, 14 Nov 2007 12:17:09 +1100
Von: Benjamin Herrenschmidt [EMAIL PROTECTED]
An: Gerhard Pircher [EMAIL PROTECTED]
CC: Jon Smirl [EMAIL PROTECTED], [EMAIL PROTECTED], linuxppc-dev@ozlabs.org
Betreff: Re: Hardware debuggers for PPC74xx G4 CPUs
On Wed, 2007-11-14 at 10:39 +0100, Gerhard Pircher wrote:
Yeah, the northbridge hates the M bit! Thus the AmigaOne platform code
masks out the CPU_FTR_NEED_COHERENT flag and disables the L2 cache
prefetch engines (I don't care about the performance loss).
I couldn't find any other code that
Original-Nachricht
Datum: Wed, 14 Nov 2007 10:37:52 +1100
Von: Benjamin Herrenschmidt [EMAIL PROTECTED]
An: Gerhard Pircher [EMAIL PROTECTED]
CC: linuxppc-dev@ozlabs.org
Betreff: Re: Kernel locks up after calling kernel_execve()
Add printk's to things :-) It's a UP kernel
Original-Nachricht
Datum: Wed, 14 Nov 2007 21:04:57 +1100
Von: Benjamin Herrenschmidt [EMAIL PROTECTED]
An: Gerhard Pircher [EMAIL PROTECTED]
CC: linuxppc-dev@ozlabs.org
Betreff: Re: Kernel locks up after calling kernel_execve()
On Wed, 2007-11-14 at 10:39 +0100, Gerhard
This patch adds support for 'mpc5200-simple-platform' compatible
boards which do not need a platform specific setup. Such boards
are supported assuming the following:
- GPIO pins are configured by the firmware,
- CDM configuration (clocking) is setup correctly by firmware,
- if the 'fsl,has-wdt'
Hi Andrew,
The kernel builds fails with following error, with randconfig
CC arch/powerpc/mm/stab.o
arch/powerpc/mm/stab.c: In function ‘stab_initialize’:
arch/powerpc/mm/stab.c:282: error: implicit declaration of function ‘HvCall1’
arch/powerpc/mm/stab.c:282: error: ‘HvCallBaseSetASR’
I am getting garbage on the screen. So, I presume this must be some
sort
of baud rate issue. Can some one help me out understand how this baud
is
set for serial drivers? I want to run at 115200.
console=ttyS0,115200
See Documentation/kernel-parameters.txt; depending on exactly what
early
This patch makes PowerPC 4xx UIC use generic edge and level irq handlers
instead of a custom handle_uic_irq() function. Acking a level irq on UIC
has no effect if the interrupt is still asserted by the device, even if
the interrupt is already masked. So, to really de-assert the interrupt
we need
Benjamin Herrenschmidt wrote:
On Wed, 2007-11-14 at 13:13 +1100, David Gibson wrote:
Hrm. I *think* I'm convinced this is safe, although acking in a
callback which doesn't say it acks is rather yucky. Essentially this
code is trading flow readability (because just reading
handle_level_irq
This patch adds sysfs attributes to the PMU to allow getting
the information on the PMU type and whether adb is present from
there instead of via the ioctl. The ioctl is made optional and
scheduled for removal.
Signed-off-by: Johannes Berg [EMAIL PROTECTED]
Acked-by: Benjamin Herrenschmidt [EMAIL
This adds platform_suspend_ops for PMU based machines, directly in
the PMU driver. This finally allows suspending via /sys/power/state
on powerbooks.
The patch also replaces the PMU ioctl with a simple call to
pm_suspend(PM_SUSPEND_MEM) and puts the sleep-related PMU ioctls onto
the
Some code in via-pmu.c is never compiled because of compile options
within the file. Remove the code completely.
Signed-off-by: Johannes Berg [EMAIL PROTECTED]
Acked-by: Benjamin Herrenschmidt [EMAIL PROTECTED]
---
drivers/macintosh/via-pmu.c | 42 +-
1
I see nothing that this lock_kernel() actually protects against
so remove it.
Signed-off-by: Johannes Berg [EMAIL PROTECTED]
Acked-by: Benjamin Herrenschmidt [EMAIL PROTECTED]
---
Please queue to whatever branch you feel appropriate.
drivers/macintosh/via-pmu.c |3 ---
1 file changed, 3
arch/powerpc/platforms/powermac/time.c:88: warning: ‘to_rtc_time’ defined but
not used
Somehow this warning has always bothered me. This patch fixes it by
making the relevant code depend on the users.
Signed-off-by: Johannes Berg [EMAIL PROTECTED]
---
arch/powerpc/platforms/powermac/time.c |
The patch updates the booting-without-of.txt-file.
There is a description for the case
if mdio data and clock pins are on different processor ports.
It extends the [PATCH v3] using mii-bitbang on different processor ports.
Signed-off-by: Sergej Stepanov [EMAIL PROTECTED]
Signed-off-by: Scott Wood
This patch makes PowerPC 4xx UIC use generic level irq handler instead
of a custom handle_uic_irq() function. We ack only edge irqs in mask_ack
callback, since acking a level irq on UIC has no effect if the interrupt
is still asserted by the device, even if the interrupt is already masked.
So, to
Hai,
We have designed a MPC8641D based AMC card. As part of our customer
requirement for a PCIe messaging driver for communicating between the
MPC8641D AMC card as the PCIe target and the MPC8548E AMC card as the Host.
We are using the DMA for transferring data between the boards thru' PCIe.
Does this patch support the cpm2 as well?
I get conflicting thoughts looking over the latest postings.
-Alan
On 11/13/07, Jon Smirl [EMAIL PROTECTED] wrote:
I am working on a patch for i2c and device tree. I attached the current
version.
DTC entry looks like this.
[EMAIL
[FWIW, my powerbook worked with -rc1]
2.6.24-rc2 works so lala :)
b43 doesn't authenticate via wpa (bluetooth isn't loaded):
WEXT auth param 4 value 0x0 - ioctl[SIOCSIWAUTH]: Operation not supported
WEXT auth param 5 value 0x1 - Internet Systems Consortium DHCP Client V3.1.0
Those error
The patch is orthogonal to your issue.
There is NOT a driver in the kernel tree for the i2c on CPM2 based
parts like the 8248 (from what I can tell).
- k
On Nov 14, 2007, at 9:31 AM, Alan Bennett wrote:
Does this patch support the cpm2 as well?
I get conflicting thoughts looking over the
ERk.
So if I needed to read values from four i2c devices (raw access would be
fine) and I need to get this working in a few days, how would you suggest I
proceed? Kernel = 2.6.23+.
Do I need to start from scratch?
Start by using Jon's patch (or are the 5200 i2c and the cpm2 i2c
On Wed, Nov 14, 2007 at 10:49:13AM -0700, Alan Bennett wrote:
ERk.
So if I needed to read values from four i2c devices (raw access would be
fine) and I need to get this working in a few days, how would you suggest I
proceed? Kernel = 2.6.23+.
Do I need to start from scratch?
Start
On (13/11/07 11:44), Stephen Rothwell didst pronounce:
On Mon, 12 Nov 2007 15:54:53 + [EMAIL PROTECTED] (Mel Gorman) wrote:
Ordinarily, the size of a pageblock is determined from the hugepage size.
On PPC64, the hugepage size is determined at runtime based on the ability
of the
From: Mark A. Greer [EMAIL PROTECTED]
Turn on the L2 cache on the prpmc2800 platform.
Signed-off-by: Mark A. Greer [EMAIL PROTECTED]
---
arch/powerpc/platforms/embedded6xx/prpmc2800.c |1 +
1 file changed, 1 insertion(+)
diff --git a/arch/powerpc/platforms/embedded6xx/prpmc2800.c
On 11/14/07, Scott Wood [EMAIL PROTECTED] wrote:
On Wed, Nov 14, 2007 at 10:49:13AM -0700, Alan Bennett wrote:
ERk.
So if I needed to read values from four i2c devices (raw access would be
fine) and I need to get this working in a few days, how would you suggest I
proceed? Kernel =
[POWERPC] vdso: Fixes for cache line sizes
Current VDSO implementation is hardcoded to 128 byte cachelines, which
only works on IBM's 64-bit processors.
Convert it to get the line sizes out of vdso_data instead, similar to
how the ppc64 in-kernel cache flush does it.
Signed-off-by: Olof
On Wed, Nov 14, 2007 at 03:07:39PM +1100, Stephen Rothwell wrote:
Signed-off-by: Stephen Rothwell [EMAIL PROTECTED]
Acked-by: Linas Vepstas [EMAIL PROTECTED]
---
arch/powerpc/platforms/pseries/Kconfig |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
--
Cheers,
Stephen
On Wed, 2007-11-14 at 13:24 -0600, Olof Johansson wrote:
[POWERPC] vdso: Fixes for cache line sizes
Current VDSO implementation is hardcoded to 128 byte cachelines, which
only works on IBM's 64-bit processors.
Convert it to get the line sizes out of vdso_data instead, similar to
how the
Fix presentation of the slot number in the /sys/bus/pci/slots
directory to match that used in the majority of other drivers.
Signed-off-by: Linas Vepstas [EMAIL PROTECTED]
--
On Tue, Nov 13, 2007 at 07:26:07PM -0800, Greg KH wrote:
We need a signed-off-by: to be able to apply this...
I've been asked to post the script again, might as well update with the
latest version.
See below. I normally use this as:
$ CROSS_COMPILE= ARCH=powerpc TARGET=vmlinux modules buildall
modules won't build on some of the embedded platforms though, so you'll
have to weed out those build errors by
[POWERPC] vdso: Fixes for cache line sizes
Current VDSO implementation is hardcoded to 128 byte cache blocks,
which are only used on IBM's 64-bit processors.
Convert it to get the blocks sizes out of vdso_data instead, similar
to how the ppc64 in-kernel cache flush does it.
Signed-off-by:
Gerhard Pircher writes:
Yeah, the northbridge hates the M bit! Thus the AmigaOne platform code
Wow.
masks out the CPU_FTR_NEED_COHERENT flag and disables the L2 cache
prefetch engines (I don't care about the performance loss).
I couldn't find any other code that sets the M bit, except for
Hi Marian,
On Wed, 14 Nov 2007 11:21:37 +0100 Marian Balakowicz [EMAIL PROTECTED] wrote:
+++ b/arch/powerpc/platforms/52xx/mpc5200_simple.c
+#include asm/time.h
+#include asm/machdep.h
+#include asm/mpc52xx.h
You still need asm/prom.h because you use of_get_flat_dt_root() and
Hello, I have a problem when using linux-2.6.14(download from
ftp.denx.de) for RTAI on ppc440EP. I use the ELDK4.1 and when boot the
uImage I compiled , I always have the problem as following:
## Booting image at 0050 ...
Image Name: Linux-2.6.14
Image Type: PowerPC Linux Kernel
Jon Smirl wrote:
On 11/13/07, Benjamin Herrenschmidt [EMAIL PROTECTED] wrote:
That's why Dominic wants to get OpenOCD running on the PowerPC. All we
need is the programming documentation for controlling the CPU via the
debug hardware.
Note that this is basically different for every CPU
Thanks Segher.
It was because of the BASE_BAUD value. We are working at 600MHz, not
18.432. After that change, it worked fine.
Thanks
Siva
-Original Message-
From: Segher Boessenkool [mailto:[EMAIL PROTECTED]
Sent: Wednesday, November 14, 2007 3:00 PM
To: Siva Prasad
Subject: Re:
On 11/14/07, Jerry Van Baren [EMAIL PROTECTED] wrote:
Jon Smirl wrote:
On 11/13/07, Benjamin Herrenschmidt [EMAIL PROTECTED] wrote:
That's why Dominic wants to get OpenOCD running on the PowerPC. All we
need is the programming documentation for controlling the CPU via the
debug hardware.
Hi Mel,
On Wed, 14 Nov 2007 18:10:45 + [EMAIL PROTECTED] (Mel Gorman) wrote:
libhugetlbfs test suite and boot test on iSeries is sufficient in this
case. However, the version I sent would break on IA-64 due to the lack of
a definition for HPAGE_SHIFT when CONFIG_HUGETLB_PAGE is not set.
On Wednesday 14 November 2007, zhangwei zhang wrote:
Hello, I have a problem when using linux-2.6.14(download from
ftp.denx.de) for RTAI on ppc440EP.
RTAI on PPC? I thought RTAI was dead for anything other than X86.
And 2.6.14 is quite old. I suggest you use a newer binary version or compile a
39 matches
Mail list logo
