> > > cbe_cpufreq.c uses cbe_cpufreq_has_pmi which is provided by
> > > cbe_cpufreq_pmi.c. Hence CBE_CPUFREQ depends on CBE_CPUFREQ_PMI.
> > >=20
> > > Signed-off-by: Michael Neuling
> > > ---
> > > I'm not 100% sure is this the right fix. Should CBE_CPUFREQ really
> > > depend on CBE_CPUFREQ_PM
We currently place mmaps just below the stack on 32bit, but leave them
in the middle of the address space on 64bit:
0010-0012 r-xp 0010 00:00 0[vdso]
1000-1001 r-xp 08:06 179534 /tmp/sleep
1001-1002 rw-p 08:06 179534
Hi,
When I make zImage, the errors below came out. Any tips?
[linux-2.6-virtex]$ make zImage
CHK include/linux/version.h
CHK include/linux/utsrelease.h
CALLscripts/checksyscalls.sh
CHK include/linux/compile.h
dnsdomainname: Unknown host
CC arch/ppc/kernel/t
Hi Linus !
A few powerpc bits for you for 2.6.29. A few bug and regression fixes
(after this pull, it will be regressions only), a couple of board
device tree updates and some trivialities such as build breakage with
random config options due to missing includes.
Among others, this should solve t
> > cbe_cpufreq.c uses cbe_cpufreq_has_pmi which is provided by
> > cbe_cpufreq_pmi.c. Hence CBE_CPUFREQ depends on CBE_CPUFREQ_PMI.
> >=20
> > Signed-off-by: Michael Neuling
> > ---
> > I'm not 100% sure is this the right fix. Should CBE_CPUFREQ really
> > depend on CBE_CPUFREQ_PMI?
>
> No I d
Added a device tree that should be identical to mpc8572ds.dtb except
the physical addresses for all IO are above the 4G boundary.
Signed-off-by: Kumar Gala
---
arch/powerpc/boot/dts/mpc8572ds_36b.dts | 787 +++
1 files changed, 787 insertions(+), 0 deletions(-)
crea
The PCI IO region sizes where incorrectly set to 1M instead of 64k.
Signed-off-by: Kumar Gala
---
arch/powerpc/boot/dts/mpc8572ds.dts| 10 +-
arch/powerpc/boot/dts/mpc8572ds_camp_core0.dts |8
arch/powerpc/boot/dts/mpc8572ds_camp_core1.dts |4 ++--
3 files
Please pull from 'merge' branch of
master.kernel.org:/pub/scm/linux/kernel/git/galak/powerpc.git merge
to receive the following updates:
arch/powerpc/boot/dts/mpc8313erdb.dts | 11 ---
arch/powerpc/configs/83xx/mpc8313_rdb_defconfig |2 +-
arch/powerpc/mm/fsl_boo
Fixed v_mapped_by_tlbcam() and p_mapped_by_tlbcam() to use phys_addr_t
instead of unsigned long. In 36-bit physical mode we really need these
functions to deal with phys_addr_t when trying to match a physical
address or when returning one.
Signed-off-by: Kumar Gala
---
arch/powerpc/mm/fsl_booke
> > > cbe_cpufreq.c uses cbe_cpufreq_has_pmi which is provided by
> > > cbe_cpufreq_pmi.c. Hence CBE_CPUFREQ depends on CBE_CPUFREQ_PMI.
> > >=20
> > > Signed-off-by: Michael Neuling
> > > ---
> > > I'm not 100% sure is this the right fix. Should CBE_CPUFREQ really
> > > depend on CBE_CPUFREQ_PM
The EEH code disables and enables interrupts during the
device recovery process. This is unnecessary for MSI
and MSI-X interrupts because they are effectively disabled
by the DMA Stopped state when an EEH error occurs. The
current code is also incorrect for MSI-X interrupts. It
doesn't take i
On Tue, 2009-02-10 at 11:46 +1100, Michael Neuling wrote:
> cbe_cpufreq.c uses cbe_cpufreq_has_pmi which is provided by
> cbe_cpufreq_pmi.c. Hence CBE_CPUFREQ depends on CBE_CPUFREQ_PMI.
>
> Signed-off-by: Michael Neuling
> ---
> I'm not 100% sure is this the right fix. Should CBE_CPUFREQ reall
cbe_cpufreq.c uses cbe_cpufreq_has_pmi which is provided by
cbe_cpufreq_pmi.c. Hence CBE_CPUFREQ depends on CBE_CPUFREQ_PMI.
Signed-off-by: Michael Neuling
---
I'm not 100% sure is this the right fix. Should CBE_CPUFREQ really
depend on CBE_CPUFREQ_PMI?
arch/powerpc/platforms/cell/Kconfig |
On Monday 09 February 2009, Michael Neuling wrote:
> arch/powerpc/oprofile/cell/spu_profiler.c is missing a asm/time.h
> include which is required for ppc_proc_freq. This can cause compile
> failures for some config combinations.
>
> Signed-off-by: Michael Neuling
Acked-by: Arnd Bergmann
_
On Mon, 2009-02-09 at 10:40 +0100, Ingo Molnar wrote:
> * Steven Rostedt wrote:
>
> >
> > Paul,
> >
> > I found the bug that was causing large modules to fail in setting
> > up dynamic ftrace. It wound up being a simple math error. To calculate
> > the offset in the TOC, I had used an OR, but t
On Mon, 9 Feb 2009 16:01:19 -0500
Josh Boyer wrote:
> On Fri, Feb 06, 2009 at 11:49:47AM -0800, Andrew Morton wrote:
> >On Fri, 06 Feb 2009 11:40:41 -0800
> >Grant Erickson wrote:
> >
> >> On 1/30/09 2:05 PM, Andrew Morton wrote:
> >> > On Fri, 30 Jan 2009 09:54:42 -0700 dougthomp...@xmission.co
On Fri, Feb 06, 2009 at 11:49:47AM -0800, Andrew Morton wrote:
>On Fri, 06 Feb 2009 11:40:41 -0800
>Grant Erickson wrote:
>
>> On 1/30/09 2:05 PM, Andrew Morton wrote:
>> > On Fri, 30 Jan 2009 09:54:42 -0700 dougthomp...@xmission.com wrote:
>> >> From: Grant Erickson
>> >
>> > Perhaps a powerpc
Steven Rostedt wrote:
> I found the bug that was causing large modules to fail in setting
> up dynamic ftrace. It wound up being a simple math error. To calculate
> the offset in the TOC, I had used an OR, but the bottom half was
> a signed extended short, and it should have been an addition.
> The
I have just tried the patch here and everything worked great!
Very well done.
On Mon, Feb 9, 2009 at 10:40 AM, Ingo Molnar wrote:
>
> * Steven Rostedt wrote:
>
>>
>> Paul,
>>
>> I found the bug that was causing large modules to fail in setting
>> up dynamic ftrace. It wound up being a simple mat
On Feb 9, 2009, at 1:47 AM, Li Yang wrote:
It's a complex case for RDB boards. The revision A and revision B
boards DO always connect TSEC0 to Vitesse switch. While the latest
revision C board has one setting to connect TSEC0 to a Marvell PHY and
MDIO bus. In BSP we have several DTS's for e
* Steven Rostedt wrote:
>
> On Mon, 9 Feb 2009, Ingo Molnar wrote:
>
> >
> > * Steven Rostedt wrote:
> >
> > >
> > > Paul,
> > >
> > > I found the bug that was causing large modules to fail in setting
> > > up dynamic ftrace. It wound up being a simple math error. To calculate
> > > the o
On Mon, 9 Feb 2009, Ingo Molnar wrote:
>
> * Steven Rostedt wrote:
>
> >
> > Paul,
> >
> > I found the bug that was causing large modules to fail in setting
> > up dynamic ftrace. It wound up being a simple math error. To calculate
> > the offset in the TOC, I had used an OR, but the bottom
On Sun, 8 Feb 2009, Rafael J. Wysocki wrote:
> On Sunday 08 February 2009, Paul Collins wrote:
> > Paul Collins writes:
> >
> > > "Rafael J. Wysocki" writes:
> > >
> > >> On Wednesday 21 January 2009, Paul Collins wrote:
> > >>> Got a couple of these on a PowerBook running 2.6.29-rc2 either dur
* Steven Rostedt wrote:
>
> Paul,
>
> I found the bug that was causing large modules to fail in setting
> up dynamic ftrace. It wound up being a simple math error. To calculate
> the offset in the TOC, I had used an OR, but the bottom half was
> a signed extended short, and it should have been
Add support for:
- LXT phy
- AT24 eeprom
- RTC (DS1337)
- MTD partitioning based on OF description
Signed-off-by: Grzegorz Bernacki
---
arch/powerpc/configs/mpc5200_defconfig | 72
1 files changed, 64 insertions(+), 8 deletions(-)
diff --git a/arch/powerpc
25 matches
Mail list logo