This patch adds support for the 256k L2 cache found on some IBM/AMCC
4xx PPC's. It introduces a common 4xx SoC file (sysdev/ppc4xx_soc.c)
which currently "only" adds the L2 cache init code. Other common 4xx
stuff can be added later here.
The L2 cache handling code is a copy of Eugene's code in arc
This patch adds the L2 cache node to the Taishan 440GX dts file.
Signed-off-by: Stefan Roese <[EMAIL PROTECTED]>
---
Unit address removed.
arch/powerpc/boot/dts/taishan.dts | 10 ++
1 files changed, 10 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/boot/dts/taishan.dts
b
Grant Likely wrote:
On Thu, Mar 20, 2008 at 10:17 AM, Bartlomiej Sieka <[EMAIL PROTECTED]> wrote:
Anatolij Gustschin wrote:
> Hello Wolfgang,
>
> Wolfgang Grandegger wrote:
>
>> I just tried Linux 2.6.25-rc6 on my TQM5200 module and got the attached
>> oops. Are there any known patches fix
On Sat, Mar 22, 2008 at 4:49 AM, Anatolij Gustschin <[EMAIL PROTECTED]> wrote:
> Checking bcom_eng pointer for NULL before referencing data pointed
> by it prevents oopsing, but fec driver still doesn't work (because
> of the lost bestcomm match and resulted task allocation failure).
> Actually
On Fri, Mar 21, 2008 at 3:21 AM, Paul Mackerras <[EMAIL PROTECTED]> wrote:
> Grant Likely writes:
>
> > Personally, I'm not fond of this approach. There is already some
> > traction to using the reg-shift property to specify spacing, and I
> > think it would be appropriate to also define a reg-
On Fri, Mar 21, 2008 at 7:00 AM, Sergei Shtylyov
<[EMAIL PROTECTED]> wrote:
> Grant Likely wrote:
> > Personally, I'm not fond of this approach. There is already some
> > traction to using the reg-shift property to specify spacing, and I
> > think it would be appropriate to also define a reg-o
On Fri, Mar 21, 2008 at 12:51:46PM -0600, Grant Likely wrote:
> On Fri, Mar 21, 2008 at 7:14 AM, Matt Sealey <[EMAIL PROTECTED]> wrote:
> > Is the MPC5200B PSC-AC97 driver in there?
>
> Audio drivers need to go in via one of the ALSA developers and I
> haven't been paying close enough attention to
Grant Likely wrote:
> Personally, I'm not fond of this approach. There is already some
> traction to using the reg-shift property to specify spacing, and I
> think it would be appropriate to also define a reg-offset property to
> handle the +3 offset and then let the xilinx 16550 nodes use thos
Grant Likely wrote:
> Personally, I'm not fond of this approach. There is already some
> traction to using the reg-shift property to specify spacing, and I
> think it would be appropriate to also define a reg-offset property to
> handle the +3 offset and then let the xilinx 16550 nodes use thos
Since a.out.h doesn't check the value of __KERNEL__, there's no point
in unifdef'ing it.
Signed-off-by: Robert P. J. Day <[EMAIL PROTECTED]>
---
diff --git a/include/asm-powerpc/Kbuild b/include/asm-powerpc/Kbuild
index 5f640e5..7381916 100644
--- a/include/asm-powerpc/Kbuild
+++ b/include/asm-
On Sat, 2008-01-26 at 12:55 +0100, Étienne Bersac wrote:
> From: Étienne Bersac <[EMAIL PROTECTED]>
>
> Implement a new driver named windfarm_pm121 which drive fans on PowerMac
> 12,1 machine : iMac G5 iSight (rev C) 17" and 20". It's based on
> windfarm_pm81 driver from Benjamin Herrenschmidt.
I
On Sat, 2008-03-22 at 19:35 +, David Woodhouse wrote:
> On Sat, 2008-01-26 at 12:55 +0100, Étienne Bersac wrote:
> > From: Étienne Bersac <[EMAIL PROTECTED]>
> >
> > Implement a new driver named windfarm_pm121 which drive fans on PowerMac
> > 12,1 machine : iMac G5 iSight (rev C) 17" and 20".
On Sun, 2008-03-23 at 09:13 +1100, Benjamin Herrenschmidt wrote:
> On Sat, 2008-03-22 at 19:35 +, David Woodhouse wrote:
> > On Sat, 2008-01-26 at 12:55 +0100, Étienne Bersac wrote:
> > > From: Étienne Bersac <[EMAIL PROTECTED]>
> > >
> > > Implement a new driver named windfarm_pm121 which dri
On Sat, 2008-03-22 at 23:02 +, David Woodhouse wrote:
>
> Yeah, there's weird shit going on with the sensor/control
> registration.
> I think GCC is be miscompiling it -- the sequence of
> all = all && pm121_register_control(foo...);
> all = all && pm121_register_control(bar...
On Sat, 2008-03-22 at 23:14 +, David Woodhouse wrote:
> On Sat, 2008-03-22 at 23:02 +, David Woodhouse wrote:
> >
> > Yeah, there's weird shit going on with the sensor/control
> > registration.
> > I think GCC is be miscompiling it -- the sequence of
> > all = all && pm121_registe
On Sat, 22 Mar 2008 23:02:46 + David Woodhouse <[EMAIL PROTECTED]> wrote:
>
> Yeah, there's weird shit going on with the sensor/control registration.
> I think GCC is be miscompiling it -- the sequence of
> all = all && pm121_register_control(foo...);
> all = all && pm121_register_c
On Sun, 2008-03-23 at 10:25 +1100, Stephen Rothwell wrote:
> Why would you expect otherwise (from the C standard):
>
> "Unlike the bitwise binary & operator, the && operator guarantees
> left-to-right evaluation; there is a sequence point after the evaluation
> of the first operand. If the first o
David Woodhouse <[EMAIL PROTECTED]> writes:
> - all = all && pm121_register_control(ct, "optical-driver-fan", FAN_OD);
> - all = all && pm121_register_control(ct, "hard-driver-fan", FAN_HD);
> - all = all && pm121_register_control(ct, "cpu-driver-fan", FAN_CPU);
> - all = all && pm
Hi Dave,
On Sat, 22 Mar 2008 23:31:13 + David Woodhouse <[EMAIL PROTECTED]> wrote:
>
> On Sun, 2008-03-23 at 10:25 +1100, Stephen Rothwell wrote:
> > Why would you expect otherwise (from the C standard):
> >
> > "Unlike the bitwise binary & operator, the && operator guarantees
> > left-to-rig
19 matches
Mail list logo
