* 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: [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: [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: [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
* 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 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
* 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 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: 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 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: 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: [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: [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: 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 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: [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] [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: 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: muram in device tree for mpc8250 in arch/powerpc
From: Scott Wood @ 2008-03-24 21:53 UTC (permalink / raw)
To: James Black; +Cc: linuxppc-embedded
In-Reply-To: <b77025b40803241445w46aaf071k427df888b4597c4d@mail.gmail.com>
James Black wrote:
> 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
I don't see any reference to bitops.h in cuboot-pq2.c...
Line 14 includes "ops.h".
-Scott
^ permalink raw reply
* Re: muram in device tree for mpc8250 in arch/powerpc
From: James Black @ 2008-03-24 21:59 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-embedded
In-Reply-To: <47E822EC.9030408@freescale.com>
OK, you are right. I was looking at my old copy I was trying to fix.
The error is,
arch/powerpc/boot/cuboot-pq2.c: In function 'fixup_pci':
arch/powerpc/boot/cuboot-pq2.c:204: warning: implicit declaration of
function '__ilog2_u32'
On Mon, Mar 24, 2008 at 3:53 PM, Scott Wood <scottwood@freescale.com> wrote:
> James Black wrote:
> > 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
>
> I don't see any reference to bitops.h in cuboot-pq2.c...
> Line 14 includes "ops.h".
>
> -Scott
>
>
^ permalink raw reply
* Re: muram in device tree for mpc8250 in arch/powerpc
From: Scott Wood @ 2008-03-24 22:05 UTC (permalink / raw)
To: James Black; +Cc: linuxppc-embedded
In-Reply-To: <b77025b40803241459s4537b1f6rdcf85c59a4af6707@mail.gmail.com>
James Black wrote:
> OK, you are right. I was looking at my old copy I was trying to fix.
> The error is,
>
> arch/powerpc/boot/cuboot-pq2.c: In function 'fixup_pci':
> arch/powerpc/boot/cuboot-pq2.c:204: warning: implicit declaration of
> function '__ilog2_u32'
It's defined as an inline function in ops.h. Do you have an old ops.h?
-Scott
^ permalink raw reply
* RE: dcr stuff.
From: Benjamin Herrenschmidt @ 2008-03-24 21:59 UTC (permalink / raw)
To: Stephen Neuendorffer; +Cc: linuxppc-dev, git-dev
In-Reply-To: <20080324043416.3634316E007A@mail15-dub.bigfish.com>
On Sun, 2008-03-23 at 21:34 -0700, Stephen Neuendorffer wrote:
>
> Certainly, if it ain't broke don't fix it. What I'm really trying to
> do is figure out how to clean up alot of non-mainline drivers.
> At the moment, several cores use DCR, but the drivers for those cores
> have internal code for DCR, their own ifdefs, etc. This *is* broken.
> I'm looking at the available documentation to figure out the best way
> of approaching the problem.
>
> It might be nice if there was an extra layer of indirection which was
> only enabled if DCR_NATIVE and DCR_MMIO, and which was no cost
> otherwise,
> but the bigger problem I see in the short term is that we'll likely
> have to support ARCH ppc for at least some time into the future, and
> it would be
> nice if we used the same driver code to do it: it doesn't seem obvious
> how to achieve this.
It's not too hard to have the DCR code be common, it's harder to deal
with the lack of device-tree in arch/ppc tho.
As for enabling support for both native and MMIO, that's certainly
possible, patches welcome :-) You could make the dcr host structure
contain the type or even function pointers, as you see fit. But make is
so that when only native is enabled, it turns back into the inlines we
have now.
Cheers,
Ben.
^ permalink raw reply
* Re: muram in device tree for mpc8250 in arch/powerpc
From: James Black @ 2008-03-24 22:09 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-embedded
In-Reply-To: <47E82591.9050907@freescale.com>
I must have the old one. I don't see '__ilog2_u32' defined. This is
the kernel I got from denx eldk 4.2. I'll grab the kernel from
kernel.org and check there. Thanks.
JB
On Mon, Mar 24, 2008 at 4:05 PM, Scott Wood <scottwood@freescale.com> wrote:
> James Black wrote:
> > OK, you are right. I was looking at my old copy I was trying to fix.
> > The error is,
> >
> > arch/powerpc/boot/cuboot-pq2.c: In function 'fixup_pci':
> > arch/powerpc/boot/cuboot-pq2.c:204: warning: implicit declaration of
> > function '__ilog2_u32'
>
> It's defined as an inline function in ops.h. Do you have an old ops.h?
>
> -Scott
>
^ permalink raw reply
* RE: dcr stuff.
From: Stephen Neuendorffer @ 2008-03-24 22:18 UTC (permalink / raw)
To: benh; +Cc: linuxppc-dev, git-dev
In-Reply-To: <1206395973.7197.50.camel@pasglop>
> -----Original Message-----
> From: Benjamin Herrenschmidt [mailto:benh@kernel.crashing.org]
> Sent: Monday, March 24, 2008 3:00 PM
> To: Stephen Neuendorffer
> Cc: Josh Boyer; linuxppc-dev@ozlabs.org; git-dev
> Subject: RE: dcr stuff.
>=20
>=20
> On Sun, 2008-03-23 at 21:34 -0700, Stephen Neuendorffer wrote:
> >
> > Certainly, if it ain't broke don't fix it. What I'm really trying
to
> > do is figure out how to clean up alot of non-mainline drivers.
> > At the moment, several cores use DCR, but the drivers for those
cores
> > have internal code for DCR, their own ifdefs, etc. This *is*
broken.
> > I'm looking at the available documentation to figure out the best
way
> > of approaching the problem.
> >
> > It might be nice if there was an extra layer of indirection which
was
> > only enabled if DCR_NATIVE and DCR_MMIO, and which was no cost
> > otherwise,
> > but the bigger problem I see in the short term is that we'll likely
> > have to support ARCH ppc for at least some time into the future, and
> > it would be
> > nice if we used the same driver code to do it: it doesn't seem
obvious
> > how to achieve this.
>=20
> It's not too hard to have the DCR code be common, it's harder to deal
> with the lack of device-tree in arch/ppc tho.
My thoughts at the moment are to punt on map and unmap and at least
provide support for dcr_host_t and dcr_read and dcr_write. Any driver
code that wants to use this without a device tree will just have to do
the work itself. This will at least support the use cases we have
today: If people want something better, then they should switch to ARCH
powerpc.. :)
=20
> As for enabling support for both native and MMIO, that's certainly
> possible, patches welcome :-) You could make the dcr host structure
> contain the type or even function pointers, as you see fit. But make
is
> so that when only native is enabled, it turns back into the inlines we
> have now.
Working on it.. :)
Steve
^ permalink raw reply
* Re: muram in device tree for mpc8250 in arch/powerpc
From: James Black @ 2008-03-24 22:28 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-embedded
In-Reply-To: <b77025b40803241509p44162ebfg2728bec85efb5d7a@mail.gmail.com>
That was it. It seems that the eldk/4.2 is missing the ilog2_u32
declaration. Makes me wonder what else is missing. I'll start again
with the kernel.org version and see what happens.
I'll send an email when this work gets done. Good catch.
JB
On Mon, Mar 24, 2008 at 4:09 PM, James Black <jblack547@gmail.com> wrote:
> I must have the old one. I don't see '__ilog2_u32' defined. This is
> the kernel I got from denx eldk 4.2. I'll grab the kernel from
> kernel.org and check there. Thanks.
>
> JB
>
>
>
> On Mon, Mar 24, 2008 at 4:05 PM, Scott Wood <scottwood@freescale.com> wrote:
> > James Black wrote:
> > > OK, you are right. I was looking at my old copy I was trying to fix.
> > > The error is,
> > >
> > > arch/powerpc/boot/cuboot-pq2.c: In function 'fixup_pci':
> > > arch/powerpc/boot/cuboot-pq2.c:204: warning: implicit declaration of
> > > function '__ilog2_u32'
> >
> > It's defined as an inline function in ops.h. Do you have an old ops.h?
> >
> > -Scott
> >
>
^ 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