On Oct 17, 2008, at 12:41 AM, Ed Swarthout wrote:
Swap pci1 and pci2 labels -
Per user manual, pcie1 is at a000 and pcie2 is at 9000.
the pcie labels are correct.. they DO NOT reflect the UMs. (as that
number is just silly).
- k
___
On Friday 17 October 2008, Benjamin Herrenschmidt wrote:
Ok, can you send me a full dmesg log with debug on the kernel command
line after adding a #define DEBUG 1 to the top of drivers/pci/probe.c
please ? (before the batch of #include).
The generic code is _supposed_ to somewhat figure out
Hi Wolfram,
On Thu, 16 Oct 2008 21:12:00 +0200, Wolfram Sang wrote:
Similar to commit 618b26d52843c0f85b8eb143cf2695d7f6fd072d, also remove
automatic probing for this i2c controller. Might need updates to dts files
using it.
Signed-off-by: Wolfram Sang [EMAIL PROTECTED]
Acked-by: Jochen
Hi Anton,
On Thu, 16 Oct 2008 21:12:53 +0400, Anton Vorontsov wrote:
If present the info-archdata is copied into the dev-archdata.
Some (OpenFirmware) platforms need it.
Signed-off-by: Anton Vorontsov [EMAIL PROTECTED]
---
drivers/i2c/i2c-core.c |3 +++
include/linux/i2c.h|2
Hi all,
This is a peculiar Oops we are encountering during the running of our board
(sh4) architecture
we are some times getting Oops messages like this
Unable to handle kernel NULL pointer dereference at virtual address 0004
pc = 844240f8
*pde =
Oops: 0001 [#1]
Pid : 529,
Hi,
It's been some days since I sent the patch below. I would appreciate if any
feedback was given.
Thanks, Rogério Brito.
On Oct 13 2008, Rogério Brito wrote:
From: Rogério Brito [EMAIL PROTECTED]
Since Linkstations and Kuroboxes often have *very* little memory (as
they are embedded
* David Miller [EMAIL PROTECTED] wrote:
net/dccp/options.c: In function 'dccp_parse_options':
net/dccp/options.c:67: warning: 'value' may be used uninitialized in
this function
Known issue, not trivial to fix, gcc is just being incredibly silly
here as it can't see all of the
Hi,
This other patch was also sent some days ago and I would appreciate some
feedback on it.
Regards, Rogério Brito.
On Oct 13 2008, Rogério Brito wrote:
The current defconfig for Linkstation/Kuroboxes has the Disable Heap
Randomization option enabled.
Since some of these machines are
Hi All,
I'm working on MPC860 with Montavista linux 2.4.18
We have a Linux kernel loadable module which on loading
panicks after some random time say 8 hours, 4 hours or so
the oops outputs say either machine check exception or
kernel stack overflow (randomly both show up) are as below:
On Thursday 16 October 2008, Josh Boyer wrote:
+#ifdef CONFIG_PPC_DCR_NATIVE
if (mal_has_feature(mal, MAL_FTR_CLEAR_ICINTSTAT))
mtdcri(SDR0, DCRN_SDR_ICINTSTAT,
(mfdcri(SDR0, DCRN_SDR_ICINTSTAT) |
ICINTSTAT_ICTX));
+#endif
So what
On Fri, 17 Oct 2008 14:56:52 +0200
Arnd Bergmann [EMAIL PROTECTED] wrote:
On Thursday 16 October 2008, Josh Boyer wrote:
+#ifdef CONFIG_PPC_DCR_NATIVE
if (mal_has_feature(mal, MAL_FTR_CLEAR_ICINTSTAT))
mtdcri(SDR0, DCRN_SDR_ICINTSTAT,
Ganesh Kumar N M wrote:
*Hi All,*
**
*I'm working on MPC860 with Montavista linux 2.4.18*
*We have a Linux kernel loadable module which on loading*
*panicks after some random time say 8 hours, 4 hours or so*
*the oops outputs say either machine check exception or *
*kernel stack overflow
On Wed, 2008-10-15 at 16:43 +0200, Sebastian Andrzej Siewior wrote:
With this patch it compiles and boots fine.
The option -mabi=no-spe is not required.
Please don't accept this patch yet. My past testing showed that
-mabi=no-spe was required for my toolchain. I'll go back and double
check
Benjamin Herrenschmidt wrote:
On Thu, 2008-10-16 at 10:01 -0500, Ayman El-Khashab wrote:
Benjamin Herrenschmidt wrote:
On Wed, 2008-10-15 at 10:47 -0500, Ayman El-Khashab wrote:
Note for people on CC: This is a problem on 460EX on a canyonland
using the 4x port.
Ok, can you send me a
* Nate Case | 2008-10-17 09:02:11 [-0500]:
On Wed, 2008-10-15 at 16:43 +0200, Sebastian Andrzej Siewior wrote:
With this patch it compiles and boots fine.
The option -mabi=no-spe is not required.
Please don't accept this patch yet. My past testing showed that
-mabi=no-spe was required for my
On Fri, Oct 17, 2008 at 03:49:12PM +0530, Sreejith wrote:
This is a peculiar Oops we are encountering during the running of our board
(sh4) architecture
So why are you posting to powerpc lists?
PC : 844240f8 SP : 88d1ff44 SR : 400080f0 TEA : c0169d64Tainted: P
With proprietary
On Wed, Oct 15, 2008 at 7:22 PM, Ilya Yanok [EMAIL PROTECTED] wrote:
This patch adds support for page sizes bigger than 4K (16K/64K) on
PPC 44x.
This patch looks good to me. Seems that all the review comments have
been incorporated.
Josh, it would be great if this patch is pulled into the
/*
Hi,
We have code in our product that produces stacktraces. Part of the
implementation of this code runs nm to find all of the entry points in
our libraries.
Using the 7.0 version of this compiler to compile the simple code below
xlC_r -c -q64 tt.cxx
nm -C tt.o
U
Anton Vorontsov wrote:
Hi all,
Recently there was a question about I2C GPIO controllers and how should
we handle them with the OpenFirmware and such.
Here is the attempt to connect I2C GPIO controllers to the
OpenFirmware device tree, without writing an OF-specific bindings
for each
Hi,
I get this following compile error on my ppc box.
Let me know if its a known issue. Otherwise, I can figure out
whats happening.
Thanks,
Badari
CC arch/powerpc/mm/slb.o
In file included from
/usr/src/linux-2.6.27/arch/powerpc/include/asm/mmu-hash64.h:16,
from
On Fri, 2008-10-17 at 10:47 -0700, Badari Pulavarty wrote:
Hi,
I get this following compile error on my ppc box.
Let me know if its a known issue. Otherwise, I can figure out
whats happening.
Thanks,
Badari
This is due to recent changes to move phys_add_t definition from
The RTC is sitting on the I2C2 bus at address 0x68. RTC interrupt signal
is connected to the IPIC's EXT2 interrupt line, the line is shared with
Vitesse 8201 Ethernet PHY.
Signed-off-by: Anton Vorontsov [EMAIL PROTECTED]
---
arch/powerpc/boot/dts/mpc8349emitx.dts |8
MCU is an external Freescale MC9S08QG8 microcontroller, mainly used to
provide soft power-off function, but also exports two GPIOs (wired to
the LEDs and also available from the external headers).
Signed-off-by: Anton Vorontsov [EMAIL PROTECTED]
---
arch/powerpc/boot/dts/mpc8315erdb.dts |8
Hi Kumar,
I'm resending the QE USB patches, the old ones started to cause
rejects.
Could you apply them for 2.6.28? Especially the first patch, since
it is holding the FHCI driver. I still hope that Greg would apply
the driver post -rc1. ;-)
Thanks!
--
Anton Vorontsov
email: [EMAIL
With this API we're able to set a QE pin to the GPIO mode or a dedicated
peripheral function.
The API relies on the fact that QE gpio controllers are registered. If
they aren't, the API won't work (gracefully though).
There is one caveat though: if anybody occupied the node-data before us,
or
- Update the device tree per QE USB bindings;
- Add timer (FSL GTM) node;
- Add gpio-controller node for BCSR13 bank (GPIOs on that bank
are used to control the USB transceiver);
- Set up other BCSR registers;
- Configure the QE Par IO.
The work is loosely based on Li Yang's patch[1], which is
The driver supports very simple GPIO controllers, that is, when a
controller provides just a 'data' register. Such controllers may be
found in various BCSRs (Board's FPGAs used to control board's
switches, LEDs, chip-selects, Ethernet/USB PHY power, etc).
So far we support only 1-byte GPIO banks.
Simply add the usb node to support USB host on the MPC8360E-RDK
boards.
Currently U-Boot doesn't fill the clock-frequency property for
timer nodes, so for now we have to fill it manually.
Signed-off-by: Anton Vorontsov [EMAIL PROTECTED]
---
arch/powerpc/boot/dts/mpc836x_rdk.dts | 19
I noticed, when trying to use, e.g.,
node = find_node_by_prop_value(prev, booleanprop, , 0))
to search for all nodes with a certain boolean property, that memcmp()
returns garbage when comparing zero bytes. It should return zero.
Index: arch/powerpc/boot/string.S
The current -git fails to build on 64-bit powerpc (failure log below) .
Initially I tried using my older toolchain, when I first saw the
problem I built a new toolchain with crosstool (gcc 4.1.2 and binutils
2.16.1) and tried again but got the same problem.
2.6.27 doesn't show this problem.
On Oct 17, 2008, at 1:11 PM, Badari Pulavarty wrote:
On Fri, 2008-10-17 at 10:47 -0700, Badari Pulavarty wrote:
Hi,
I get this following compile error on my ppc box.
Let me know if its a known issue. Otherwise, I can figure out
whats happening.
Thanks,
Badari
This is due to recent
On Thursday 16 October 2008, Anton Vorontsov wrote:
+/*
+ * Platforms can define their own __dev_ versions to glue gpio_chips with the
+ * architecture-specific code.
+ */
+#ifndef __dev_gpiochip_add
+#define __dev_gpiochip_add __dev_gpiochip_add
+static inline int __dev_gpiochip_add(struct
On Thursday 16 October 2008, Anton Vorontsov wrote:
+ if (of_gc-chip)
+ return of_gc-chip;
+ return of_gc-gc;
presumably there's a reason not to
of_gc-chip = of_gc-gc;
when this gets set up, so this can always be a simple
return of_gc-chip;
(and
On Fri, 2008-10-17 at 09:54 -0500, Ayman El-Khashab wrote:
Benjamin Herrenschmidt wrote:
On Thu, 2008-10-16 at 10:01 -0500, Ayman El-Khashab wrote:
Benjamin Herrenschmidt wrote:
On Wed, 2008-10-15 at 10:47 -0500, Ayman El-Khashab wrote:
Note for people on CC: This is a problem on 460EX
Add a bool IGB_DCA defined to y if IGB and DCA are enabled, but IGB isn't y
while DCA=m. And thus remove the need to select INTEL_IOATDMA when IGB is
enabled, so that non-x86 architectures can build the igb driver.
Based on work/patch from Brice Goglin [EMAIL PROTECTED]
Signed-off-by: Jeff
On Fri, Oct 17, 2008 at 01:25:01PM -0700, David Brownell wrote:
On Thursday 16 October 2008, Anton Vorontsov wrote:
+ if (of_gc-chip)
+ return of_gc-chip;
+ return of_gc-gc;
presumably there's a reason not to
of_gc-chip = of_gc-gc;
Yes, there are two
On Fri, 2008-10-17 at 09:54 -0500, Ayman El-Khashab wrote:
Benjamin Herrenschmidt wrote:
On Thu, 2008-10-16 at 10:01 -0500, Ayman El-Khashab wrote:
Benjamin Herrenschmidt wrote:
On Wed, 2008-10-15 at 10:47 -0500, Ayman El-Khashab wrote:
Note for people on CC: This is a problem on 460EX
On Fri, Oct 17, 2008 at 01:24:42PM -0700, David Brownell wrote:
On Thursday 16 October 2008, Anton Vorontsov wrote:
+/*
+ * Platforms can define their own __dev_ versions to glue gpio_chips with
the
+ * architecture-specific code.
+ */
+#ifndef __dev_gpiochip_add
+#define
On Fri, Oct 17, 2008 at 01:06:29PM -0500, Steven Munroe wrote:
Alan can you respond to this. This XLC but I suspect it is common with
GCC and the PPC64 ABI.
Indeed, this is due to the ABI.
Content-Description: Forwarded message - finding fuction names
To: linuxppc-dev@ozlabs.org
Subject:
We don't want to encourage the bogus device_type usage.
The device type isn't used in the code, so we can simply remove it from
the documentation and dts files.
Boards should specify proper compatible entries instead.
Suggested-by: David Gibson [EMAIL PROTECTED]
Signed-off-by: Anton Vorontsov
Hi All,
The follow patches have been added to the 4xx 'next' branch:
Josh Boyer (5):
powerpc/40x: AMCC PowerPC 405EZ Acadia DTS
powerpc/40x: Add AMCC PowerPC 405EZ to cputable
powerpc/40x: Add PowerPC 40x simple platform support
powerpc/40x: Add cuboot wrapper for Acadia
David Gibson wrote:
Deleting the irrelevant parts or picking a device tree to pass to
fdt_init() are both reasonable solutions. libfdt which is included in
the bootwrapper has functions for removing unwanted nodes: either
fdt_nop_node() or fdt_del_node() will suffice. There isn't currently
From: Grant Likely [EMAIL PROTECTED]
This target is needed to build cuImages with an embedded ramdisk image.
Signed-off-by: Grant Likely [EMAIL PROTECTED]
---
arch/powerpc/boot/Makefile |3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/boot/Makefile
The following changes since commit 6dc6472581f693b5fc95aebedf67b4960fb85cf0:
Benjamin Herrenschmidt (1):
Merge commit 'origin'
are available in the git repository at:
git://git.secretlab.ca/git/linux-2.6-mpc52xx merge
Grant Likely (1):
powerpc/52xx: Make cuImage more robust in
44 matches
Mail list logo
