On Fri, Oct 17, 2008 at 01:32:59PM -0600, Chris Friesen wrote:
> 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 trie
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
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 b/
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 currentl
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 b
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
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:
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
> > +#de
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
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
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 Ki
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
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
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(
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 changes
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.
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
=
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
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.
- 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 u
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 ov
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 PROTECTED]
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
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
arch/powerpc
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
arch/
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 /usr/s
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
> fo
/*
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 __
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
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 modul
* 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 require
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,
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
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 (r
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,
> >
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
Because ehca adapters can differ in the maximum number of QPs and CQs
we have to save the maximum number of these ressources per adapter and not
globally per ehca driver. This fix introduces 2 new members to the shca
structure to store the maximum value for QPs and CQs per adapter.
The module param
* 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
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, Com
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:
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 ar
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
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
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: Jo
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
45 matches
Mail list logo
