* Re: muram in device tree for mpc8250 in arch/powerpc
From: James Black @ 2008-03-24 21:45 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-embedded
In-Reply-To: <47E7DC46.2010806@freescale.com>
I started from scratch and am trying to build the cuImage. I get this
compiler error.
arch/powerpc/boot/cuboot-pq2.c:14:20: error: bitops.h: No such file or directory
arch/powerpc/boot/cuboot-pq2.c: In function 'fixup_pci':
arch/powerpc/boot/cuboot-pq2.c:205: warning: implicit declaration of
function '__ilog2_u32'
I looks as though cuboot-pq2.c expects bitops.h to be in the same
directory, but it has moved to
linux/include/asm-powerpc/bitops.h
Did you run into this problem?
JB
On Mon, Mar 24, 2008 at 10:52 AM, Scott Wood <scottwood@freescale.com> wrote:
> James Black wrote:
> > Thanks much for the help Scott. Do you feel that the dts is correct
> > now and probably not the culprit? Do you have 2.6.24.2 running on
> > other boards?
>
> I just booted 2.6.24.2 on pq2fads (using cuImage, since I don't have a
> devtree-aware u-boot on this board).
>
>
> > localbus@f0010100 {
> > compatible = "fsl,mpc8250-localbus",
> > "fsl,pq2-localbus";
> >
> > #address-cells = <2>;
> > #size-cells = <1>;
> > reg = <f0010100 60>;
> > ranges = <0 0 fe000000 00200000>;
> >
> > flash@fe000000,0 {
> > compatible = "cfi-flash";
> > reg = <0 fe000000 00200000>;
> > bank-width = <2>;
> > device-width = <1>;
> > };
>
> This is wrong; the flash will not translate since you didn't provide a
> window at the address reg is at.
>
> The first cell of the reg should be the chipselect, and the second cell
> the offset.
>
>
> > brg@119f0 {
> > compatible = "fsl,mpc8250-brg",
> > "fsl,cpm2-brg",
> > "fsl,cpm-brg";
> > reg = <119f0 10>;
> > };
>
> BRG should be <119f0 10 115f0 10>.
>
> -Scott
>
>
^ permalink raw reply
* Re: [PATCH 1/2 v2] [POWERPC] Add PPC4xx L2-cache support (440GX)
From: Josh Boyer @ 2008-03-24 21:15 UTC (permalink / raw)
To: benh; +Cc: linuxppc-dev, Stefan Roese
In-Reply-To: <1206392355.7197.38.camel@pasglop>
On Tue, 25 Mar 2008 07:59:15 +1100
Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
>
> On Mon, 2008-03-24 at 08:39 -0500, Josh Boyer wrote:
> > > +
> > > + local_irq_save(flags);
> > > + asm volatile ("sync" ::: "memory");
> >
> > Perhaps just call iosync() for these instead of the open coded asm
> > volatile stuff?
>
> Not sure about that. iosync() will do a sync but it's not meant at being
> used for things unrelated to IOs (and who knows... we might make it do
> something else one day ?).
>
> In low level arch code like that, an open coded sync might be proper
> especially if it matches some documented sequence.
Either way, it doesn't matter to me.
josh
^ permalink raw reply
* Re: [PATCH 1/2 v2] [POWERPC] Add PPC4xx L2-cache support (440GX)
From: Benjamin Herrenschmidt @ 2008-03-24 20:59 UTC (permalink / raw)
To: Josh Boyer; +Cc: linuxppc-dev, Stefan Roese
In-Reply-To: <20080324083957.2945077c@zod.rchland.ibm.com>
On Mon, 2008-03-24 at 08:39 -0500, Josh Boyer wrote:
> > +
> > + local_irq_save(flags);
> > + asm volatile ("sync" ::: "memory");
>
> Perhaps just call iosync() for these instead of the open coded asm
> volatile stuff?
Not sure about that. iosync() will do a sync but it's not meant at being
used for things unrelated to IOs (and who knows... we might make it do
something else one day ?).
In low level arch code like that, an open coded sync might be proper
especially if it matches some documented sequence.
Cheers,
Ben.
^ permalink raw reply
* Re: [PATCH 1/2 v2] Driver for Freescale 8610 and 5121 DIU
From: Andrew Morton @ 2008-03-24 18:47 UTC (permalink / raw)
To: Timur Tabi
Cc: linux-fbdev-devel, a.p.zijlstra, linux-kernel, linuxppc-dev,
yorksun
In-Reply-To: <47E7C05C.2000001@freescale.com>
On Mon, 24 Mar 2008 09:53:16 -0500
Timur Tabi <timur@freescale.com> wrote:
> Andrew Morton wrote:
>
> >>> GFP_DMA implies GFP_ATOMIC, but it's appropriate for documentation purposes.
> >> So does that mean that "GFP_DMA | GFP_KERNEL" is always wrong?
> >
> > No, that's OK too. It's just that GFP_DMA|GFP_ATOMIC is a bit redundant
> > and misleading. GFP_DMA is already atomic; the only effect of adding
> > GFP_ATOMIC to GFP_DMA is to add __GFP_HIGH.
> >
> > Don't wory about it ;)
>
> Well, maybe we don't want GFP_ATOMIC then, because I don't think we want
> __GFP_HIGH. Looking at the code, it appears the __GFP_HIGH has nothing to do
> with HIGHMEM (which on PowerPC is the not 1-to-1 mapping memory from 0xF000000
> to 0xFFFFFFFF). Further examination of the cools shows the __GFP_HIGH says to
> try access the "emergency pool", and I see this code snippet:
>
> if (alloc_flags & ALLOC_HIGH)
> min -= min / 2;
>
> I guess this means that we reduce the amount of memory that can be available in
> order for the allocate to succeed.
>
> Considering that the amount of memory that we allocate is in the order of
> megabytes, and it really isn't that important, I would think that we don't want
> to touch the emergency pool. Does that sound right?
yup. The absence of __GFP_WAIT already causes the page allocator to try a
bit harder. Adding __GFP_HIGH would make it try harder still.
You do need to be sure that the driver will robustly and correctly recover
from an allocation failure here.
^ permalink raw reply
* Re: dtc: Simplify error handling for unparseable input
From: Scott Wood @ 2008-03-24 17:36 UTC (permalink / raw)
To: Jon Loeliger, linuxppc-dev
In-Reply-To: <20080324034424.GC29985@localhost.localdomain>
On Mon, Mar 24, 2008 at 02:44:24PM +1100, David Gibson wrote:
> Index: dtc/dtc.h
> ===================================================================
> --- dtc.orig/dtc.h 2008-03-24 14:33:33.000000000 +1100
> +++ dtc/dtc.h 2008-03-24 14:33:34.000000000 +1100
> @@ -232,7 +232,6 @@
> struct boot_info {
> struct reserve_info *reservelist;
> struct node *dt; /* the device tree */
> - int error;
> };
If you remove this, there'll be no way to indicate semantic errors other
than die() (the NULL approaches are no good, since they inhibit recovery),
which is suboptimal if the error is not immediately fatal.
-Scott
^ permalink raw reply
* Re: [PATCH 2/3] [POWERPC] Xilinx: of_serial support for Xilinx uart 16550.
From: Sergei Shtylyov @ 2008-03-24 17:03 UTC (permalink / raw)
To: Sergei Shtylyov; +Cc: linuxppc-dev, Paul Mackerras, John Linn
In-Reply-To: <47E7D3BB.1050403@ru.mvista.com>
Hi, I wrote:
> Oh, well... unfortunately, we can't use UPIO_MEM32 "register model"
> in 8250.c anyway since that makes use of readl()/writel() -- which treat
> the bus as bigendian on PPC... anyway, we would need at least a
I was going to write "as little-endian"... :-<
> "reg-size" property, if not new "compatible"...
WBR, Sergei
^ permalink raw reply
* Re: [POWERPC] mpc52xx: Amalgamated dts fixes and updates
From: Wolfgang Grandegger @ 2008-03-24 16:59 UTC (permalink / raw)
To: Bartlomiej Sieka; +Cc: linuxppc-dev, Anatolij Gustschin, Paul Mackerras
In-Reply-To: <20080321235633.GB345@frozen.semihalf.com>
Bartlomiej Sieka wrote:
> The bulk of this patch is taken from
> http://patchwork.ozlabs.org/linuxppc/patch?q=Balakowicz&id=16197, with few
> other updates, in particluar one posted by Anatolij Gustschin, which fixes
> an Oops during boot.
>
> Signed-off-by: Marian Balakowicz <m8@semihalf.com>
> ---
> Anatolij, would you like to add your S-O-B?
>
> diff --git a/arch/powerpc/boot/dts/cm5200.dts b/arch/powerpc/boot/dts/cm5200.dts
> index 30737ea..8b2e8e4 100644
> --- a/arch/powerpc/boot/dts/cm5200.dts
> +++ b/arch/powerpc/boot/dts/cm5200.dts
> @@ -159,6 +159,7 @@
> };
>
> dma-controller@1200 {
> + device_type = "dma-controller";
> compatible = "fsl,mpc5200b-bestcomm","fsl,mpc5200-bestcomm";
> reg = <1200 80>;
> interrupts = <3 0 0 3 1 0 3 2 0 3 3 0
> @@ -212,13 +213,31 @@
> ethernet@3000 {
> device_type = "network";
> compatible = "fsl,mpc5200b-fec","fsl,mpc5200-fec";
> - reg = <3000 800>;
> + reg = <3000 400>;
> local-mac-address = [ 00 00 00 00 00 00 ];
> interrupts = <2 5 0>;
> interrupt-parent = <&mpc5200_pic>;
> + phy-handle = <&phy0>;
> + };
> +
> + mdio@3000 {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + device_type = "mdio";
> + compatible = "fsl,mpc5200b-mdio";
> + reg = <3000 400>; // fec range, since we need to setup fec interrupts
> + interrupts = <2 5 0>; // these are for "mii command finished", not link changes & co.
> + interrupt-parent = <&mpc5200_pic>;
> +
> + phy0:ethernet-phy@0 {
> + device_type = "ethernet-phy";
> + reg = <0>;
> + };
> };
>
> i2c@3d40 {
> + #address-cells = <1>;
> + #size-cells = <0>;
> compatible = "fsl,mpc5200b-i2c","fsl,mpc5200-i2c","fsl-i2c";
> reg = <3d40 40>;
> interrupts = <2 10 0>;
> @@ -231,4 +250,22 @@
> reg = <8000 4000>;
> };
> };
> +
> + lpb {
> + model = "fsl,lpb";
> + compatible = "fsl,lpb";
> + #address-cells = <2>;
> + #size-cells = <1>;
> + ranges = <0 0 fc000000 2000000>;
> +
> + // 16-bit flash device at LocalPlus Bus CS0
> + flash@0,0 {
> + compatible = "cfi-flash";
> + reg = <0 0 2000000>;
> + bank-width = <2>;
> + device-width = <2>;
> + #size-cells = <1>;
> + #address-cells = <1>;
> + };
> + };
> };
> diff --git a/arch/powerpc/boot/dts/motionpro.dts b/arch/powerpc/boot/dts/motionpro.dts
> index 76951ab..9ca81ff 100644
> --- a/arch/powerpc/boot/dts/motionpro.dts
> +++ b/arch/powerpc/boot/dts/motionpro.dts
> @@ -127,6 +127,13 @@
> interrupt-parent = <&mpc5200_pic>;
> };
>
> + mscan@900 {
> + compatible = "mpc5200b-mscan\0mpc5200-mscan";
> + interrupts = <2 11 0>;
> + interrupt-parent = <&mpc5200_pic>;
> + reg = <900 80>;
> + };
> +
If I remember correctly, the motionpro board has only _one_ MSCAN port
wired. Therefore please discard the above hunk.
Wolfgang.
^ permalink raw reply
* Re: muram in device tree for mpc8250 in arch/powerpc
From: Scott Wood @ 2008-03-24 16:52 UTC (permalink / raw)
To: James Black; +Cc: linuxppc-embedded
In-Reply-To: <b77025b40803211435g25e8cee7w75bfe4ed9c13796@mail.gmail.com>
James Black wrote:
> Thanks much for the help Scott. Do you feel that the dts is correct
> now and probably not the culprit? Do you have 2.6.24.2 running on
> other boards?
I just booted 2.6.24.2 on pq2fads (using cuImage, since I don't have a
devtree-aware u-boot on this board).
> localbus@f0010100 {
> compatible = "fsl,mpc8250-localbus",
> "fsl,pq2-localbus";
>
> #address-cells = <2>;
> #size-cells = <1>;
> reg = <f0010100 60>;
> ranges = <0 0 fe000000 00200000>;
>
> flash@fe000000,0 {
> compatible = "cfi-flash";
> reg = <0 fe000000 00200000>;
> bank-width = <2>;
> device-width = <1>;
> };
This is wrong; the flash will not translate since you didn't provide a
window at the address reg is at.
The first cell of the reg should be the chipselect, and the second cell
the offset.
> brg@119f0 {
> compatible = "fsl,mpc8250-brg",
> "fsl,cpm2-brg",
> "fsl,cpm-brg";
> reg = <119f0 10>;
> };
BRG should be <119f0 10 115f0 10>.
-Scott
^ permalink raw reply
* Re: [PATCH 2/3] [POWERPC] Xilinx: of_serial support for Xilinx uart 16550.
From: Grant Likely @ 2008-03-24 16:48 UTC (permalink / raw)
To: Sergei Shtylyov; +Cc: linuxppc-dev, Paul Mackerras, John Linn
In-Reply-To: <47E7D3BB.1050403@ru.mvista.com>
On Mon, Mar 24, 2008 at 10:15 AM, Sergei Shtylyov
<sshtylyov@ru.mvista.com> wrote:
> Grant Likely wrote:
> >> Probably I misunderstood you: does it give the same result as offset 11?
>
> > er; typo; oops. A 32 bit read add offset 0 is the same as a byte read
> > at offset *3*.
>
> Oh, well... unfortunately, we can't use UPIO_MEM32 "register model" in
> 8250.c anyway since that makes use of readl()/writel() -- which treat the bus
> as bigendian on PPC... anyway, we would need at least a "reg-size" property,
> if not new "compatible"...
:-) ... and the *driver* itself isn't any sort of issue; it's just
figuring out the best way to describe the hardware
accurately/appropriately so the binding can decide how to configure
the driver.
> >> Have you considered using the existing "big-endian" property?
>
> > No I haven't, but that would work too. I'm happy with that if it
> > works for you. If the property was defined, then the byte offset to
> > the first reg would be adjusted by 1^(reg-shift) - 1
>
> You don't mean "xor" by ^, do you? :-O
> In fact, it should be <<...
heh; pseudocoding in the wrong language. You, of course, are right.
Cheers,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: [PATCH 2/3] [POWERPC] Xilinx: of_serial support for Xilinx uart 16550.
From: Sergei Shtylyov @ 2008-03-24 16:15 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-dev, Paul Mackerras, John Linn
In-Reply-To: <fa686aa40803240727p14c7e8c0r8575f7d5feb776dd@mail.gmail.com>
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 those.
>> >> Why do we need a reg-offset property when we can just add the offset
>> >> to the appropriate word(s) in the reg property?
>
>> > Primarily because the device creates 32 byte registers starting at 0;
>> > but they are also big-endian byte accessible so a byte read at offset
>> > 8 also works.
>> Probably I misunderstood you: does it give the same result as offset 11?
> er; typo; oops. A 32 bit read add offset 0 is the same as a byte read
> at offset *3*.
Oh, well... unfortunately, we can't use UPIO_MEM32 "register model" in
8250.c anyway since that makes use of readl()/writel() -- which treat the bus
as bigendian on PPC... anyway, we would need at least a "reg-size" property,
if not new "compatible"...
>> > reg-offset seems to be a better description of the hardware to me.
>> Have you considered using the existing "big-endian" property?
> No I haven't, but that would work too. I'm happy with that if it
> works for you. If the property was defined, then the byte offset to
> the first reg would be adjusted by 1^(reg-shift) - 1
You don't mean "xor" by ^, do you? :-O
In fact, it should be <<...
> Cheers,
> g.
WBR, Sergei
^ permalink raw reply
* Re: [PATCH 1/2 v2] Driver for Freescale 8610 and 5121 DIU
From: Timur Tabi @ 2008-03-24 14:53 UTC (permalink / raw)
To: Andrew Morton
Cc: linux-fbdev-devel, Peter Zijlstra, linux-kernel, linuxppc-dev,
York Sun
In-Reply-To: <20080321111228.95a7d9ab.akpm@linux-foundation.org>
Andrew Morton wrote:
>>> GFP_DMA implies GFP_ATOMIC, but it's appropriate for documentation purposes.
>> So does that mean that "GFP_DMA | GFP_KERNEL" is always wrong?
>
> No, that's OK too. It's just that GFP_DMA|GFP_ATOMIC is a bit redundant
> and misleading. GFP_DMA is already atomic; the only effect of adding
> GFP_ATOMIC to GFP_DMA is to add __GFP_HIGH.
>
> Don't wory about it ;)
Well, maybe we don't want GFP_ATOMIC then, because I don't think we want
__GFP_HIGH. Looking at the code, it appears the __GFP_HIGH has nothing to do
with HIGHMEM (which on PowerPC is the not 1-to-1 mapping memory from 0xF000000
to 0xFFFFFFFF). Further examination of the cools shows the __GFP_HIGH says to
try access the "emergency pool", and I see this code snippet:
if (alloc_flags & ALLOC_HIGH)
min -= min / 2;
I guess this means that we reduce the amount of memory that can be available in
order for the allocate to succeed.
Considering that the amount of memory that we allocate is in the order of
megabytes, and it really isn't that important, I would think that we don't want
to touch the emergency pool. Does that sound right?
--
Timur Tabi
Linux kernel developer at Freescale
^ permalink raw reply
* Re: [PATCH 2/3] [POWERPC] Xilinx: of_serial support for Xilinx uart 16550.
From: Grant Likely @ 2008-03-24 14:27 UTC (permalink / raw)
To: Sergei Shtylyov; +Cc: linuxppc-dev, Paul Mackerras, John Linn
In-Reply-To: <47E7B61B.70708@ru.mvista.com>
On Mon, Mar 24, 2008 at 8:09 AM, Sergei Shtylyov
<sshtylyov@ru.mvista.com> 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-offset property to
> >> > handle the +3 offset and then let the xilinx 16550 nodes use those.
>
> >> Why do we need a reg-offset property when we can just add the offset
> >> to the appropriate word(s) in the reg property?
>
> > Primarily because the device creates 32 byte registers starting at 0;
> > but they are also big-endian byte accessible so a byte read at offset
> > 8 also works.
>
> Probably I misunderstood you: does it give the same result as offset 11?
er; typo; oops. A 32 bit read add offset 0 is the same as a byte read
at offset *3*.
>
>
> > reg-offset seems to be a better description of the hardware to me.
>
> Have you considered using the existing "big-endian" property?
No I haven't, but that would work too. I'm happy with that if it
works for you. If the property was defined, then the byte offset to
the first reg would be adjusted by 1^(reg-shift) - 1
Cheers,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: [PATCH 2/3] [POWERPC] Xilinx: of_serial support for Xilinx uart 16550.
From: Sergei Shtylyov @ 2008-03-24 14:09 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-dev, Paul Mackerras, John Linn
In-Reply-To: <fa686aa40803220750h1d86589am9a26aeeb359178b7@mail.gmail.com>
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 those.
>> Why do we need a reg-offset property when we can just add the offset
>> to the appropriate word(s) in the reg property?
> Primarily because the device creates 32 byte registers starting at 0;
> but they are also big-endian byte accessible so a byte read at offset
> 8 also works.
Probably I misunderstood you: does it give the same result as offset 11?
> reg-offset seems to be a better description of the hardware to me.
Have you considered using the existing "big-endian" property?
> Cheers,
> g.
WBR, Sergei
^ permalink raw reply
* Please pull from 'for-2.6.25' branch
From: Kumar Gala @ 2008-03-24 13:58 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
Please pull from 'for-2.6.25' branch of
master.kernel.org:/pub/scm/linux/kernel/git/galak/powerpc.git for-2.6.25
to receive the following updates:
arch/powerpc/configs/ep8248e_defconfig | 74 +++++++---
arch/powerpc/configs/ep88xc_defconfig | 56 +++++--
arch/powerpc/configs/linkstation_defconfig | 131 +++++++++++------
arch/powerpc/configs/mpc7448_hpc2_defconfig | 119 ++++++++++++----
arch/powerpc/configs/mpc8272_ads_defconfig | 75 ++++++++--
arch/powerpc/configs/mpc8313_rdb_defconfig | 114 ++++++++++-----
arch/powerpc/configs/mpc8315_rdb_defconfig | 110 +++++++++------
arch/powerpc/configs/mpc832x_mds_defconfig | 101 +++++++++----
arch/powerpc/configs/mpc832x_rdb_defconfig | 106 +++++++++-----
arch/powerpc/configs/mpc834x_itx_defconfig | 111 +++++++++------
arch/powerpc/configs/mpc834x_itxgp_defconfig | 109 +++++++++-----
arch/powerpc/configs/mpc834x_mds_defconfig | 104 +++++++++-----
arch/powerpc/configs/mpc836x_mds_defconfig | 102 +++++++++----
arch/powerpc/configs/mpc837x_mds_defconfig | 197 ++++++++++++++-------------
arch/powerpc/configs/mpc837x_rdb_defconfig | 83 +++++++----
arch/powerpc/configs/mpc83xx_defconfig | 88 +++++++-----
arch/powerpc/configs/mpc8540_ads_defconfig | 121 ++++++++++++----
arch/powerpc/configs/mpc8544_ds_defconfig | 127 ++++++++++++-----
arch/powerpc/configs/mpc8560_ads_defconfig | 126 +++++++++++++----
arch/powerpc/configs/mpc8568mds_defconfig | 106 ++++++++++----
arch/powerpc/configs/mpc8572_ds_defconfig | 127 ++++++++++++-----
arch/powerpc/configs/mpc85xx_cds_defconfig | 131 +++++++++++++----
arch/powerpc/configs/mpc85xx_defconfig | 111 ++++++++++-----
arch/powerpc/configs/mpc8610_hpcd_defconfig | 131 ++++++++++++++---
arch/powerpc/configs/mpc8641_hpcn_defconfig | 115 ++++++++++-----
arch/powerpc/configs/mpc866_ads_defconfig | 112 +++++++++++----
arch/powerpc/configs/mpc885_ads_defconfig | 56 +++++--
arch/powerpc/configs/pq2fads_defconfig | 89 ++++++++----
arch/powerpc/configs/prpmc2800_defconfig | 160 ++++++++++++++++-----
arch/powerpc/configs/sbc834x_defconfig | 78 +++++++---
arch/powerpc/configs/sbc8548_defconfig | 115 ++++++++++++---
arch/powerpc/configs/sbc8560_defconfig | 124 +++++++++++++---
arch/powerpc/configs/storcenter_defconfig | 102 +++++++------
arch/powerpc/configs/stx_gp3_defconfig | 154 +++++++++++++++------
arch/powerpc/configs/tqm8540_defconfig | 133 +++++++++++++-----
arch/powerpc/configs/tqm8541_defconfig | 133 +++++++++++++-----
arch/powerpc/configs/tqm8555_defconfig | 133 +++++++++++++-----
arch/powerpc/configs/tqm8560_defconfig | 133 +++++++++++++-----
38 files changed, 3031 insertions(+), 1266 deletions(-)
Kumar Gala (1):
[POWERPC] Update some defconfigs
^ permalink raw reply
* Re: [PATCH 1/2 v2] [POWERPC] Add PPC4xx L2-cache support (440GX)
From: Josh Boyer @ 2008-03-24 13:39 UTC (permalink / raw)
To: Stefan Roese; +Cc: linuxppc-dev
In-Reply-To: <1206181736-21796-1-git-send-email-sr@denx.de>
On Sat, 22 Mar 2008 11:28:56 +0100
Stefan Roese <sr@denx.de> wrote:
> 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 arch/ppc
> with small modifications.
>
> Tested on AMCC Taishan 440GX.
>
> Signed-off-by: Stefan Roese <sr@denx.de>
Hi Stefan. Small, very minor issues below.
> diff --git a/arch/powerpc/sysdev/ppc4xx_soc.c b/arch/powerpc/sysdev/ppc4xx_soc.c
> new file mode 100644
> index 0000000..4847555
> --- /dev/null
> +++ b/arch/powerpc/sysdev/ppc4xx_soc.c
> @@ -0,0 +1,178 @@
> +/*
> + * IBM/AMCC PPC4xx SoC setup code
> + *
> + * Copyright 2008 DENX Software Engineering, Stefan Roese <sr@denx.de>
> + *
> + * L2 cache routines cloned from arch/ppc/syslib/ibm440gx_common.c which is:
> + * Eugene Surovegin <eugene.surovegin@zultys.com> or <ebs@ebshome.net>
> + * Copyright (c) 2003 - 2006 Zultys Technologies
> + *
> + * This program is free software; you can redistribute it and/or modify it
> + * under the terms of the GNU General Public License as published by the
> + * Free Software Foundation; either version 2 of the License, or (at your
> + * option) any later version.
> + */
> +
> +#include <linux/stddef.h>
> +#include <linux/kernel.h>
> +#include <linux/init.h>
> +#include <linux/errno.h>
> +#include <linux/interrupt.h>
> +#include <linux/irq.h>
> +#include <linux/of_platform.h>
> +
> +#include <asm/dcr.h>
> +#include <asm/dcr-regs.h>
> +
> +static u32 dcrbase;
If this file is really intended to have other miscellaneous stuff added
to it, perhaps this variable should be renamed l2_dcrbase. I know it's
minor, so perhaps we can wait until something else gets added.
> +
> +/*
> + * L2-cache
> + */
> +
> +/* Issue L2C diagnostic command */
> +static inline u32 l2c_diag(u32 addr)
> +{
> + mtdcr(dcrbase + DCRN_L2C0_ADDR, addr);
> + mtdcr(dcrbase + DCRN_L2C0_CMD, L2C_CMD_DIAG);
> + while (!(mfdcr(dcrbase + DCRN_L2C0_SR) & L2C_SR_CC))
> + ;
> +
> + return mfdcr(dcrbase + DCRN_L2C0_DATA);
> +}
> +
> +static irqreturn_t l2c_error_handler(int irq, void *dev)
> +{
> + u32 sr = mfdcr(dcrbase + DCRN_L2C0_SR);
> +
> + if (sr & L2C_SR_CPE) {
> + /* Read cache trapped address */
> + u32 addr = l2c_diag(0x42000000);
What is this magical hex number?
> + printk(KERN_EMERG "L2C: Cache Parity Error, addr[16:26] = 0x%08x\n",
> + addr);
> + }
> + if (sr & L2C_SR_TPE) {
> + /* Read tag trapped address */
> + u32 addr = l2c_diag(0x82000000) >> 16;
And here?
> + printk(KERN_EMERG "L2C: Tag Parity Error, addr[16:26] = 0x%08x\n",
> + addr);
> + }
> +
> + /* Clear parity errors */
> + if (sr & (L2C_SR_CPE | L2C_SR_TPE)){
> + mtdcr(dcrbase + DCRN_L2C0_ADDR, 0);
> + mtdcr(dcrbase + DCRN_L2C0_CMD, L2C_CMD_CCP | L2C_CMD_CTE);
> + } else {
> + printk(KERN_EMERG "L2C: LRU error\n");
> + }
> +
> + return IRQ_HANDLED;
> +}
> +
> +static int __init ppc4xx_l2c_probe(void)
> +{
> + struct device_node *np;
> + u32 r;
> + unsigned long flags;
> + int irq;
> + const u32 *dcrreg;
> + u32 dcrbase_isram;
> + int len;
> +
> + np = of_find_compatible_node(np, NULL, "ibm,l2-cache");
> + if (!np)
> + return 0;
> +
> + /* Map DCRs */
> + dcrreg = of_get_property(np, "dcr-reg", &len);
> + if (!dcrreg || (len != 4 * sizeof(u32))) {
> + printk(KERN_ERR "%s: Can't get DCR register base !",
> + np->full_name);
> + of_node_put(np);
> + return -ENODEV;
> + }
> + dcrbase_isram = dcrreg[0];
> + dcrbase = dcrreg[2];
> +
> + /* Get and map irq number from device tree */
> + irq = irq_of_parse_and_map(np, 0);
> + if (irq == NO_IRQ) {
> + printk(KERN_ERR "irq_of_parse_and_map failed\n");
> + of_node_put(np);
> + return -ENODEV;
> + }
> +
> + /* Install error handler */
> + if (request_irq(irq, l2c_error_handler, IRQF_DISABLED, "L2C", 0) < 0) {
> + printk(KERN_ERR "Cannot install L2C error handler"
> + ", cache is not enabled\n");
> + of_node_put(np);
> + return -ENODEV;
> + }
> +
> + local_irq_save(flags);
> + asm volatile ("sync" ::: "memory");
Perhaps just call iosync() for these instead of the open coded asm
volatile stuff?
> +
> + /* Disable SRAM */
> + mtdcr(dcrbase_isram + DCRN_SRAM0_DPC,
> + mfdcr(dcrbase_isram + DCRN_SRAM0_DPC) & ~SRAM_DPC_ENABLE);
> + mtdcr(dcrbase_isram + DCRN_SRAM0_SB0CR,
> + mfdcr(dcrbase_isram + DCRN_SRAM0_SB0CR) & ~SRAM_SBCR_BU_MASK);
> + mtdcr(dcrbase_isram + DCRN_SRAM0_SB1CR,
> + mfdcr(dcrbase_isram + DCRN_SRAM0_SB1CR) & ~SRAM_SBCR_BU_MASK);
> + mtdcr(dcrbase_isram + DCRN_SRAM0_SB2CR,
> + mfdcr(dcrbase_isram + DCRN_SRAM0_SB2CR) & ~SRAM_SBCR_BU_MASK);
> + mtdcr(dcrbase_isram + DCRN_SRAM0_SB3CR,
> + mfdcr(dcrbase_isram + DCRN_SRAM0_SB3CR) & ~SRAM_SBCR_BU_MASK);
> +
> + /* Enable L2_MODE without ICU/DCU */
> + r = mfdcr(dcrbase + DCRN_L2C0_CFG) &
> + ~(L2C_CFG_ICU | L2C_CFG_DCU | L2C_CFG_SS_MASK);
> + r |= L2C_CFG_L2M | L2C_CFG_SS_256;
> + mtdcr(dcrbase + DCRN_L2C0_CFG, r);
> +
> + mtdcr(dcrbase + DCRN_L2C0_ADDR, 0);
> +
> + /* Hardware Clear Command */
> + mtdcr(dcrbase + DCRN_L2C0_CMD, L2C_CMD_HCC);
> + while (!(mfdcr(dcrbase + DCRN_L2C0_SR) & L2C_SR_CC))
> + ;
> +
> + /* Clear Cache Parity and Tag Errors */
> + mtdcr(dcrbase + DCRN_L2C0_CMD, L2C_CMD_CCP | L2C_CMD_CTE);
> +
> + /* Enable 64G snoop region starting at 0 */
> + r = mfdcr(dcrbase + DCRN_L2C0_SNP0) &
> + ~(L2C_SNP_BA_MASK | L2C_SNP_SSR_MASK);
> + r |= L2C_SNP_SSR_32G | L2C_SNP_ESR;
> + mtdcr(dcrbase + DCRN_L2C0_SNP0, r);
> +
> + r = mfdcr(dcrbase + DCRN_L2C0_SNP1) &
> + ~(L2C_SNP_BA_MASK | L2C_SNP_SSR_MASK);
> + r |= 0x80000000 | L2C_SNP_SSR_32G | L2C_SNP_ESR;
> + mtdcr(dcrbase + DCRN_L2C0_SNP1, r);
> +
> + asm volatile ("sync" ::: "memory");
> +
> + /* Enable ICU/DCU ports */
> + r = mfdcr(dcrbase + DCRN_L2C0_CFG);
> + r &= ~(L2C_CFG_DCW_MASK | L2C_CFG_PMUX_MASK | L2C_CFG_PMIM
> + | L2C_CFG_TPEI | L2C_CFG_CPEI | L2C_CFG_NAM | L2C_CFG_NBRM);
> + r |= L2C_CFG_ICU | L2C_CFG_DCU | L2C_CFG_TPC | L2C_CFG_CPC | L2C_CFG_FRAN
> + | L2C_CFG_CPIM | L2C_CFG_TPIM | L2C_CFG_LIM | L2C_CFG_SMCM;
> +
> + /* Check for 460EX/GT special handling */
> + if (of_device_is_compatible(np, "ibm,l2-cache-460ex"))
> + r |= L2C_CFG_RDBW;
> +
> + mtdcr(dcrbase + DCRN_L2C0_CFG, r);
> +
> + asm volatile ("sync; isync" ::: "memory");
> + local_irq_restore(flags);
> +
> + printk(KERN_INFO "256k L2-cache enabled\n");
Should the cache size be derived from the device tree?
josh
^ permalink raw reply
* Re: [PATCH] [POWERPC] mpc5200: fix incorrect compatible string for the mdio node
From: Grant Likely @ 2008-03-24 13:34 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev, linux-kernel
In-Reply-To: <18407.22329.130304.645554@cargo.ozlabs.ibm.com>
On Mon, Mar 24, 2008 at 1:24 AM, Paul Mackerras <paulus@samba.org> wrote:
> Grant Likely writes:
>
> > The MDIO node in the lite5200b.dts file needs to also claim compatibility
> > with the older mpc5200 chip.
> >
> > Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
> > ---
> > Paul, this one should also go in for .26
>
> OK, I'll put it in the powerpc-next branch. Or did you mean it should
> go in .25?
er, oops. Yes, I really would like this one to go in for .25
Thanks,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: [RESEND] [PATCH 1/2 v2] [OF] Add of_device_is_available function
From: Josh Boyer @ 2008-03-24 11:45 UTC (permalink / raw)
To: Paul Mackerras; +Cc: sfr, linuxppc-dev
In-Reply-To: <18407.37606.990271.551578@cargo.ozlabs.ibm.com>
On Mon, 24 Mar 2008 22:39:18 +1100
Paul Mackerras <paulus@samba.org> wrote:
> Josh Boyer writes:
>
> > This adds a function called of_device_is_available that checks the state
> > of the status property of a device. If the property is absent or set to
> > either "okay" or "ok", it returns 1. Otherwise it returns 0.
>
> Well actually...
>
> > + if (statlen > 0) {
> > + if (!strncmp(status, "okay", 4) || !strncmp(status, "ok", 2))
> > + return 1;
>
> The second test will succeed for anything that starts with "ok", so
> the first test is redundant. I suspect you want strcmp instead of
> strncmp in both tests.
GRR! That's what I had in the original patch and you told me to use
strncmp instead.
If you want I can send out a v3. Otherwise, perhaps you could just
munge the patch?
josh
^ permalink raw reply
* Re: [RESEND] [PATCH 1/2 v2] [OF] Add of_device_is_available function
From: Paul Mackerras @ 2008-03-24 11:39 UTC (permalink / raw)
To: Josh Boyer; +Cc: sfr, linuxppc-dev
In-Reply-To: <20080301174825.57715d46@zod.rchland.ibm.com>
Josh Boyer writes:
> This adds a function called of_device_is_available that checks the state
> of the status property of a device. If the property is absent or set to
> either "okay" or "ok", it returns 1. Otherwise it returns 0.
Well actually...
> + if (statlen > 0) {
> + if (!strncmp(status, "okay", 4) || !strncmp(status, "ok", 2))
> + return 1;
The second test will succeed for anything that starts with "ok", so
the first test is redundant. I suspect you want strcmp instead of
strncmp in both tests.
Paul.
^ permalink raw reply
* Re: [PATCH 2/11] cell: generalize io-workarounds code
From: Benjamin Herrenschmidt @ 2008-03-24 10:44 UTC (permalink / raw)
To: Ishizaki Kou; +Cc: linuxppc-dev, paulus
In-Reply-To: <1206355309.7197.32.camel@pasglop>
On Mon, 2008-03-24 at 21:41 +1100, Benjamin Herrenschmidt wrote:
> On Fri, 2008-03-14 at 21:20 +0900, Ishizaki Kou wrote:
> > This patch splits cell io-workaround code into spider-pci dependent
> > code and a generic part, and also adds interfaces to the generic
> > io-workaround mechanism.
> >
> > Signed-off-by: Kou Ishizaki <kou.ishizaki@toshiba.co.jp>
> > ---
>
> Hi !
>
> I noticed that you add a second level of indirection. We already have
> one going to the workarounds in the first place, so that looks a bit too
> much to my taste.
>
> I may have missed something in your patch but if the workarounds are
> specific to a given bridge, they may as well set the top level
> indirections once straight to the right workarounds.
Looking more closely, I wonder if a good solution would be to move the
function pointers away from globals, to the dev_archdata structure,
and thus make them per-device (like the DMA ops)
That way, you can populate the workarounds differently for the PCI
devices and the PCI-E devices at probe time and still have only one
indirection.
Cheers,
Ben.
^ permalink raw reply
* Re: [PATCH 2/11] cell: generalize io-workarounds code
From: Benjamin Herrenschmidt @ 2008-03-24 10:41 UTC (permalink / raw)
To: Ishizaki Kou; +Cc: linuxppc-dev, paulus
In-Reply-To: <20080314.212034.-1625856941.kouish@swc.toshiba.co.jp>
On Fri, 2008-03-14 at 21:20 +0900, Ishizaki Kou wrote:
> This patch splits cell io-workaround code into spider-pci dependent
> code and a generic part, and also adds interfaces to the generic
> io-workaround mechanism.
>
> Signed-off-by: Kou Ishizaki <kou.ishizaki@toshiba.co.jp>
> ---
Hi !
I noticed that you add a second level of indirection. We already have
one going to the workarounds in the first place, so that looks a bit too
much to my taste.
I may have missed something in your patch but if the workarounds are
specific to a given bridge, they may as well set the top level
indirections once straight to the right workarounds.
Also, my understanding is that we are pretty much using the same bridge
on the cell blades, so is there any way that can be consolidated rather
than having function pointers ?
I'll try to have a closer look next week, but I'm a bit worried by
having all IO go through 2 level of function pointers, the PPE isn't
very good at it and this will slow things down more than they already
are.
Cheers,
Ben.
^ permalink raw reply
* [LMB]: Add lmb_alloc_nid()
From: David Miller @ 2008-03-24 9:50 UTC (permalink / raw)
To: linuxppc-dev; +Cc: linux-kernel
This function will be used by the NUMA setup code on sparc64, and also
it can be used by powerpc, replacing it's hand crafted
"careful_allocation()" function in arch/powerpc/mm/numa.c
If x86 ever converts it's NUMA support over to using the LMB helpers,
it can use this too as it has something entirely similar.
[LMB]: Add lmb_alloc_nid()
A variant of lmb_alloc() that tries to allocate memory on a specified
NUMA node 'nid' but falls back to normal lmb_alloc() if that fails.
The caller provides a 'nid_range' function pointer which assists the
allocator. It is given args 'start', 'end', and pointer to integer
'this_nid'.
It places at 'this_nid' the NUMA node id that corresponds to 'start',
and returns the end address within 'start' to 'end' at which memory
assosciated with 'nid' ends.
This callback allows a platform to use lmb_alloc_nid() in just
about any context, even ones in which early_pfn_to_nid() might
not be working yet.
Signed-off-by: David S. Miller <davem@davemloft.net>
---
include/linux/lmb.h | 2 +
lib/lmb.c | 86 +++++++++++++++++++++++++++++++++++++++++++++------
2 files changed, 78 insertions(+), 10 deletions(-)
diff --git a/include/linux/lmb.h b/include/linux/lmb.h
index 632717c..271153d 100644
--- a/include/linux/lmb.h
+++ b/include/linux/lmb.h
@@ -42,6 +42,8 @@ extern void __init lmb_init(void);
extern void __init lmb_analyze(void);
extern long __init lmb_add(u64 base, u64 size);
extern long __init lmb_reserve(u64 base, u64 size);
+extern u64 __init lmb_alloc_nid(u64 size, u64 align, int nid,
+ u64 (*nid_range)(u64, u64, int *));
extern u64 __init lmb_alloc(u64 size, u64 align);
extern u64 __init lmb_alloc_base(u64 size,
u64, u64 max_addr);
diff --git a/lib/lmb.c b/lib/lmb.c
index e3c8dcb..5e76b36 100644
--- a/lib/lmb.c
+++ b/lib/lmb.c
@@ -227,6 +227,82 @@ long __init lmb_overlaps_region(struct lmb_region *rgn, u64 base,
return (i < rgn->cnt) ? i : -1;
}
+static u64 lmb_align_down(u64 addr, u64 size)
+{
+ return addr & ~(size - 1);
+}
+
+static u64 lmb_align_up(u64 addr, u64 size)
+{
+ return (addr + (size - 1)) & ~(size - 1);
+}
+
+static u64 __init lmb_alloc_nid_unreserved(u64 start, u64 end,
+ u64 size, u64 align)
+{
+ u64 base;
+ long j;
+
+ base = lmb_align_down((end - size), align);
+ while (start <= base &&
+ ((j = lmb_overlaps_region(&lmb.reserved, base, size)) >= 0))
+ base = lmb_align_down(lmb.reserved.region[j].base - size,
+ align);
+
+ if (base != 0 && start <= base) {
+ if (lmb_add_region(&lmb.reserved, base,
+ lmb_align_up(size, align)) < 0)
+ base = ~(u64)0;
+ return base;
+ }
+
+ return ~(u64)0;
+}
+
+static u64 __init lmb_alloc_nid_region(struct lmb_property *mp,
+ u64 (*nid_range)(u64, u64, int *),
+ u64 size, u64 align, int nid)
+{
+ u64 start, end;
+
+ start = mp->base;
+ end = start + mp->size;
+
+ start = lmb_align_up(start, align);
+ while (start < end) {
+ u64 this_end;
+ int this_nid;
+
+ this_end = nid_range(start, end, &this_nid);
+ if (this_nid == nid) {
+ u64 ret = lmb_alloc_nid_unreserved(start, this_end,
+ size, align);
+ if (ret != ~(u64)0)
+ return ret;
+ }
+ start = this_end;
+ }
+
+ return ~(u64)0;
+}
+
+u64 __init lmb_alloc_nid(u64 size, u64 align, int nid,
+ u64 (*nid_range)(u64 start, u64 end, int *nid))
+{
+ struct lmb_region *mem = &lmb.memory;
+ int i;
+
+ for (i = 0; i < mem->cnt; i++) {
+ u64 ret = lmb_alloc_nid_region(&mem->region[i],
+ nid_range,
+ size, align, nid);
+ if (ret != ~(u64)0)
+ return ret;
+ }
+
+ return lmb_alloc(size, align);
+}
+
u64 __init lmb_alloc(u64 size, u64 align)
{
return lmb_alloc_base(size, align, LMB_ALLOC_ANYWHERE);
@@ -245,16 +321,6 @@ u64 __init lmb_alloc_base(u64 size, u64 align, u64 max_addr)
return alloc;
}
-static u64 lmb_align_down(u64 addr, u64 size)
-{
- return addr & ~(size - 1);
-}
-
-static u64 lmb_align_up(u64 addr, u64 size)
-{
- return (addr + (size - 1)) & ~(size - 1);
-}
-
u64 __init __lmb_alloc_base(u64 size, u64 align, u64 max_addr)
{
long i, j;
--
1.5.4.rc3.14.g44397
^ permalink raw reply related
* Please pull powerpc.git merge branch
From: Paul Mackerras @ 2008-03-24 8:05 UTC (permalink / raw)
To: torvalds; +Cc: linuxppc-dev, akpm, linux-kernel
Linus,
Please do:
git pull \
git://git.kernel.org/pub/scm/linux/kernel/git/paulus/powerpc.git merge
to get a few more bug-fixes for powerpc that should go in 2.6.25.
Thanks,
Paul.
arch/powerpc/mm/hash_utils_64.c | 11 ++++++++---
arch/powerpc/sysdev/bestcomm/bestcomm.c | 8 ++++++--
arch/powerpc/sysdev/ipic.c | 2 +-
drivers/net/fec_mpc52xx_phy.c | 3 ++-
4 files changed, 17 insertions(+), 7 deletions(-)
commit 7ea6fd7e2df041297298b5feb5b7b78a2b1a5310
Author: Anatolij Gustschin <agust@denx.de>
Date: Sat Mar 22 21:49:05 2008 +1100
[POWERPC] Fix Oops with TQM5200 on TQM5200
The "bestcomm-core" driver defines its of_match table as follows
static struct of_device_id mpc52xx_bcom_of_match[] = {
{ .type = "dma-controller", .compatible = "fsl,mpc5200-bestcomm", },
{ .type = "dma-controller", .compatible = "mpc5200-bestcomm", },
{},
};
so while registering the driver, the driver's probe function won't be
called, because the device tree node doesn't have a device_type
property. Thus the driver's bcom_engine structure won't be allocated.
Referencing this structure later causes observed Oops.
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 the compatible property exists and should match and so
the fec driver should work.
This removes .type = "dma-controller" from the bestcomm driver's
mpc52xx_bcom_of_match table to solve the problem.
Signed-off-by: Anatolij Gustschin <agust@denx.de>
Acked-by: Grant Likely <grant.likely@secretlab.ca>
Signed-off-by: Paul Mackerras <paulus@samba.org>
commit 9560aea4e9d17cb75113c6051e800222fd5c71a4
Author: Grant Likely <grant.likely@secretlab.ca>
Date: Sat Mar 22 14:41:05 2008 +1100
[POWERPC] mpc5200: Fix null dereference if bestcomm fails to initialize
If the bestcomm initialization fails, calls to the task allocate
function should fail gracefully instead of oopsing with a NULL deref.
Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
Signed-off-by: Paul Mackerras <paulus@samba.org>
commit b8c19eb16a7e6df57d0f6d67e42ce026e5d5930b
Author: Grant Likely <grant.likely@secretlab.ca>
Date: Sat Mar 22 14:20:29 2008 +1100
[POWERPC] mpc5200-fec: Fix possible NULL dereference in mdio driver
If the reg property is missing from the phy node (unlikely, but possible),
then the kernel will oops with a NULL pointer dereference. This fixes
it by checking the pointer first.
Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
Signed-off-by: Paul Mackerras <paulus@samba.org>
commit 1428a9fa586cb80acf98289f797f58b8bd662598
Author: Olaf Hering <olaf@aepfle.de>
Date: Tue Mar 18 06:53:05 2008 +1100
[POWERPC] Fix crash in init_ipic_sysfs on efika
The global primary_ipic in arch/powerpc/sysdev/ipic.c can remain NULL
if ipic_init() fails, which will happen on machines that don't have an
ipic interrupt controller. init_ipic_sysfs() will crash in that case.
Acked-by: Grant Likely <grant.likely@secretlab.ca>
Signed-off-by: Paul Mackerras <paulus@samba.org>
commit cfe666b145cecffe784d98e60ffe201a5dc57ac3
Author: Paul Mackerras <paulus@samba.org>
Date: Mon Mar 24 17:41:22 2008 +1100
[POWERPC] Don't use 64k pages for ioremap on pSeries
On pSeries, the hypervisor doesn't let us map in the eHEA ethernet
adapter using 64k pages, and thus the ehea driver will fail if 64k
pages are configured. This works around the problem by always
using 4k pages for ioremap on pSeries (but not on other platforms).
A better fix would be to check whether the partition could ever
have an eHEA adapter, and only force 4k pages if it could, but this
will do for 2.6.25.
This is based on an earlier patch by Tony Breeds.
Signed-off-by: Paul Mackerras <paulus@samba.org>
^ permalink raw reply
* Re: crash in init_ipic_sysfs on efika
From: Paul Mackerras @ 2008-03-24 8:02 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev, Olaf Hering
In-Reply-To: <Pine.LNX.4.64.0803210418170.8073@blarg.am.freescale.net>
Kumar Gala writes:
> since you are going to send something to linus let me update the fsl
> defconfigs and send you a pull request.
OK -- I'm about to send Linus a pull request now in case he feels like
releasing 2.6.25 this weekend. I'll send him another pull request
with your defconfig update and whatever else has turned up when I get
your pull request.
Paul.
^ permalink raw reply
* Re: [PATCH 4/8] powerpc ptrace: forced_successful_syscall_return()
From: Paul Mackerras @ 2008-03-24 7:55 UTC (permalink / raw)
To: Roland McGrath
Cc: linux-arch, tony.luck, linux-ia64, linux-kernel, David Miller,
linuxppc-dev, Thomas Gleixner, sparclinux, Andrew Morton,
Linus Torvalds, Ingo Molnar, Richard Henderson
In-Reply-To: <20080319211936.28E8B26F9A7@magilla.localdomain>
Roland McGrath writes:
> Define the forced_successful_syscall_return() macro to
> pair with our force_successful_syscall_return() definition.
>
> Signed-off-by: Roland McGrath <roland@redhat.com>
Looks OK to me, but what's it useful for?
Paul.
^ permalink raw reply
* Re: [PATCH] [POWERPC] mpc5200: fix incorrect compatible string for the mdio node
From: Paul Mackerras @ 2008-03-24 7:24 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-dev, linux-kernel
In-Reply-To: <1206156315-4734-1-git-send-email-grant.likely@secretlab.ca>
Grant Likely writes:
> The MDIO node in the lite5200b.dts file needs to also claim compatibility
> with the older mpc5200 chip.
>
> Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
> ---
> Paul, this one should also go in for .26
OK, I'll put it in the powerpc-next branch. Or did you mean it should
go in .25?
Paul.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox