On Wed, 2010-03-10 at 10:55 +, i...@hellion.org.uk wrote:
arch_init_chip_data cannot be moved into struct irq_chip at this time
because irq_desc-chip is not known at the time the irq_desc is
setup. For now rename arch_init_chip_data to arch_init_irq_desc (for
PowerPC, the only other
On Wed, Mar 10, 2010 at 2:55 AM, i...@hellion.org.uk wrote:
From: Ian Campbell ian.campb...@citrix.com
Move arch_init_copy_chip_data and arch_free_chip_data into function
pointers in struct irq_chip since they operate on irq_desc-chip_data.
arch_init_chip_data cannot be moved into struct
From: Ian Campbell ian.campb...@citrix.com
Move arch_init_copy_chip_data and arch_free_chip_data into function
pointers in struct irq_chip since they operate on irq_desc-chip_data.
arch_init_chip_data cannot be moved into struct irq_chip at this time
because irq_desc-chip is not known at the
Hi Ben,
I have cleaned up the code from the previous post:
http://lists.ozlabs.org/pipermail/linuxppc-dev/2010-February/080630.html
Changes from v1:
* Removed redundant return statements and rearranged code
Description:
A new hcall H_EM_GET_PARMS as been added to obtain power mode data
from
On Wed, 2010-03-10 at 12:06 +, Yinghai Lu wrote:
On Wed, Mar 10, 2010 at 2:55 AM, i...@hellion.org.uk wrote:
From: Ian Campbell ian.campb...@citrix.com
Move arch_init_copy_chip_data and arch_free_chip_data into function
pointers in struct irq_chip since they operate on
hi,
mv643xx_eth driver seems to be broken (and very often there is a kernel panic
too).
Last working kernel is 2.6.31.2
here a dmesg from 2.6.32.9:
memory = 1024MB; using 2048kB for hash table (at cfe0)
Linux version 2.6.32.9 (r...@pegasos2) (gcc version 4.3.4 (CRUX PPC) (GCC) ) #1
PREEMPT
On Wed, Mar 10, 2010 at 04:14:41PM +0100, acrux wrote:
hi,
mv643xx_eth driver seems to be broken (and very often there is a kernel panic
too).
Last working kernel is 2.6.31.2
here a dmesg from 2.6.32.9:
My Pegasos running a pristine 2.6.32 seems to disagree with you.
[...]
Linux version
On Wed, 2010-03-10 at 17:18 +, Eric W. Biederman wrote:
Ian Campbell ian.campb...@citrix.com writes:
On Wed, 2010-03-10 at 10:55 +, i...@hellion.org.uk wrote:
arch_init_chip_data cannot be moved into struct irq_chip at this time
because irq_desc-chip is not known at the time
Ian Campbell ian.campb...@citrix.com writes:
On Wed, 2010-03-10 at 12:06 +, Yinghai Lu wrote:
On Wed, Mar 10, 2010 at 2:55 AM, i...@hellion.org.uk wrote:
From: Ian Campbell ian.campb...@citrix.com
Move arch_init_copy_chip_data and arch_free_chip_data into function
pointers in
On Wed, 2010-03-10 at 17:42 +, Eric W. Biederman wrote:
Ian Xen in this sense is simply not x86. irq_cfg is not acpi or
ioapic or anything but x86 specific. It has everything to do with
having a per cpu vector table of 256 entries and architecturally
receiving a vector number when an
Ian Campbell ian.campb...@citrix.com writes:
On Wed, 2010-03-10 at 17:18 +, Eric W. Biederman wrote:
Ian Campbell ian.campb...@citrix.com writes:
On Wed, 2010-03-10 at 10:55 +, i...@hellion.org.uk wrote:
arch_init_chip_data cannot be moved into struct irq_chip at this time
Ian Campbell ian.campb...@citrix.com writes:
On Wed, 2010-03-10 at 17:42 +, Eric W. Biederman wrote:
Ian Xen in this sense is simply not x86. irq_cfg is not acpi or
ioapic or anything but x86 specific. It has everything to do with
having a per cpu vector table of 256 entries and
Hi all,
not sure if this is the right place to ask: When I boot a custom 5200B (more
or less Lite-based) board with Linus' git tree (2.6.34-rc1-dirty), I always get
the following bug:
[1.110693] i2c /dev entries driver
[1.117285] mpc-i2c f0003d00.i2c: clock 375000 Hz (fdr=137)
[
On Wed, 2010-03-10 at 18:15 +, Eric W. Biederman wrote:
Ian Campbell ian.campb...@citrix.com writes:
On Wed, 2010-03-10 at 17:42 +, Eric W. Biederman wrote:
Ian Xen in this sense is simply not x86. irq_cfg is not acpi or
ioapic or anything but x86 specific. It has
On 03/10/2010 09:42 AM, Eric W. Biederman wrote:
All we need between the Xen and the rest of x86 is a convention
so that we never manage the same irqs. At least for domU we are
in an either/or situation so I don't see even that being a problem.
Dom0 too. This is part of the work
On 03/10/2010 04:51 AM, Ian Campbell wrote:
On Wed, 2010-03-10 at 12:06 +, Yinghai Lu wrote:
On Wed, Mar 10, 2010 at 2:55 AM, i...@hellion.org.uk wrote:
From: Ian Campbell ian.campb...@citrix.com
Move arch_init_copy_chip_data and arch_free_chip_data into function
pointers in struct
Ian Campbell ian.campb...@citrix.com writes:
On Wed, 2010-03-10 at 10:55 +, i...@hellion.org.uk wrote:
arch_init_chip_data cannot be moved into struct irq_chip at this time
because irq_desc-chip is not known at the time the irq_desc is
setup. For now rename arch_init_chip_data to
Yinghai Lu ying...@kernel.org writes:
On 03/10/2010 04:51 AM, Ian Campbell wrote:
On Wed, 2010-03-10 at 12:06 +, Yinghai Lu wrote:
On Wed, Mar 10, 2010 at 2:55 AM, i...@hellion.org.uk wrote:
From: Ian Campbell ian.campb...@citrix.com
Move arch_init_copy_chip_data and
mpc52xx_gpt_wdt_setup is defined as 0, which causes the following build
failure with gcc 4.5, since it's built with -Werror.
arch/powerpc/platforms/52xx/mpc52xx_gpt.c:761:3: error: statement with no effect
Defining it as do { } while(0) fixes the problem.
Signed-off-by: Jeff Mahoney
On Sun, 2010-03-07 at 15:08 -0800, Hollis Blanchard wrote:
On Fri, Mar 5, 2010 at 12:43 PM, Dave Kleikamp
sha...@linux.vnet.ibm.com wrote:
powerpc/476: Add isync after loading mmu and debug spr's
From: Dave Kleikamp sha...@linux.vnet.ibm.com
476 requires an isync after loading MMU
From: Julia Lawall ju...@diku.dk
kasprintf combines kmalloc and sprintf, and takes care of the size
calculation itself.
The semantic patch that makes this change is as follows:
(http://coccinelle.lip6.fr/)
// smpl
@@
expression a,flag;
expression list args;
statement S;
@@
a =
-
On Wed, 2010-03-10 at 10:55 +, i...@hellion.org.uk wrote:
From: Ian Campbell ian.campb...@citrix.com
Move arch_init_copy_chip_data and arch_free_chip_data into function
pointers in struct irq_chip since they operate on irq_desc-chip_data.
arch_init_chip_data cannot be moved into struct
Hi Albrecht,
not sure if this is the right place to ask: When I boot a custom 5200B (more
Check MAINTAINERS for AT24 ;)
or less Lite-based) board with Linus' git tree (2.6.34-rc1-dirty), I always
get the following bug:
Will send a patch in some minutes...
Regards,
Wolfram
--
Hi all,
Okay, I'm putting on my asbestos underwear and hoping I don't sound too
stupid. Here's my sitch: we're seeing an illegal instruction exception,
but the tracks our diagnostic code we put into the kernel
program_check_exception() function claims the instruction is perfectly
good. So I
Hi Guys:
I have done several experiments on fsl_8548cds and fsl_p2020rdb, pinpointed
the commit: 864b9e6fd76489aab422bac62162f57c52e06ed8(powerpc: Use
lwarx/ldarx hint in bit locks) cause the bootup stalledd.
Filename 'fsl_8548cds/uImage'.
Load address: 0x100
Loading:
On Mar 10, 2010, at 9:20 PM, Andrew Liu wrote:
Hi Guys:
I have done several experiments on fsl_8548cds and fsl_p2020rdb, pinpointed
the commit: 864b9e6fd76489aab422bac62162f57c52e06ed8(powerpc: Use lwarx/ldarx
hint in bit locks) cause the bootup stalledd.
Filename
e500v1/v2 based chips will treat any reserved field being set in an
opcode as illegal. Thus always setting the hint in the opcode is
a bad idea.
Anton should be kept away from the powerpc opcode map.
Signed-off-by: Kumar Gala ga...@kernel.crashing.org
---
arch/powerpc/include/asm/ppc-opcode.h
On Mar 10, 2010, at 11:20 PM, Kumar Gala wrote:
On Mar 10, 2010, at 9:20 PM, Andrew Liu wrote:
Hi Guys:
I have done several experiments on fsl_8548cds and fsl_p2020rdb, pinpointed
the commit: 864b9e6fd76489aab422bac62162f57c52e06ed8(powerpc: Use
lwarx/ldarx hint in bit locks) cause
Grant Likely wrote:
2010/3/9 Németh Márton nm...@freemail.hu:
Hi,
Grant Likely wrote:
2010/3/8 Németh Márton nm...@freemail.hu:
[snip]
As far as I could find out I'll need to create a device tree as documented
in
the linux/Documentation/powerpc/booting-without-of.txt file.
Yes, you'll
On Thu, Mar 11, 2010 at 07:11:56AM +0100, Németh Márton wrote:
[snip]
+/dts-v1/;
+
+/ {
+ model = MPC5554;
+ compatible = fsl,MPC5554EVB; // Freescale MPC5554 Evaluation
Board
+ #address-cells = 1;
+ #size-cells = 1;
+
+ cpus {
+ #address-cells
Hi Alex,
Resending, previous attempt was erroneously send as HTML.
Thanks a lot for replying.
Alex Chiang wrote:
* Felix Radensky fe...@embedded-sol.com:
The problem arises when device is plugged in after boot. After doing
echo 1 /sys/bus/pci/rescan
the device is identified, but bridge
31 matches
Mail list logo
