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, wrote:
> From: Ian Campbell
>
> 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_de
From: Ian Campbell
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 time the irq_desc is
setu
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 the
On Wed, 2010-03-10 at 12:06 +, Yinghai Lu wrote:
> On Wed, Mar 10, 2010 at 2:55 AM, wrote:
> > From: Ian Campbell
> >
> > 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
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 W
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 ver
On Wed, 2010-03-10 at 17:18 +, Eric W. Biederman wrote:
> Ian Campbell 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
Ian Campbell writes:
> On Wed, 2010-03-10 at 12:06 +, Yinghai Lu wrote:
>> On Wed, Mar 10, 2010 at 2:55 AM, wrote:
>> > From: Ian Campbell
>> >
>> > 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_dat
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 wh
Ian Campbell writes:
> On Wed, 2010-03-10 at 17:18 +, Eric W. Biederman wrote:
>> Ian Campbell 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
Ian Campbell 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 architecturally
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)
[1.
On Wed, 2010-03-10 at 18:15 +, Eric W. Biederman wrote:
> Ian Campbell 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 d
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 implemen
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, wrote:
>>> From: Ian Campbell
>>>
>>> Move arch_init_copy_chip_data and arch_free_chip_data into function
>>> pointers in struct irq_chip since they operate on i
Ian Campbell 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 arch_init_irq_desc (
Yinghai Lu 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, wrote:
From: Ian Campbell
Move arch_init_copy_chip_data and arch_free_chip_data into function
pointers in struct irq
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
---
arch/p
On Sun, 2010-03-07 at 15:08 -0800, Hollis Blanchard wrote:
> On Fri, Mar 5, 2010 at 12:43 PM, Dave Kleikamp
> wrote:
> >
> > powerpc/476: Add isync after loading mmu and debug spr's
> >
> > From: Dave Kleikamp
> >
> > 476 requires an isync after loading MMU and debug related SPR's. Some of
> > t
From: Julia Lawall
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/)
//
@@
expression a,flag;
expression list args;
statement S;
@@
a =
- \(kmalloc\|kzalloc\)(...,flag
On Wed, 2010-03-10 at 10:55 +, i...@hellion.org.uk wrote:
> From: Ian Campbell
>
> 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
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
--
Pengu
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 'fsl_8548cd
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
---
arch/powerpc/include/asm/ppc-opcode.h |6 +++---
1 files cha
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 lock
Grant Likely wrote:
> 2010/3/9 Németh Márton :
>> Hi,
>> Grant Likely wrote:
>>> 2010/3/8 Németh Márton :
[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 need to create
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 {
> +
Hi Alex,
Resending, previous attempt was erroneously send as HTML.
Thanks a lot for replying.
Alex Chiang wrote:
* Felix Radensky :
The problem arises when device is plugged in after boot. After doing
echo 1 > /sys/bus/pci/rescan
the device is identified, but bridge memory window is not al
31 matches
Mail list logo
