* [PATCH] powerpc/mm: Fix definitions of FORCE_MAX_ZONEORDER in Kconfig
From: Benjamin Herrenschmidt @ 2009-07-22 1:25 UTC (permalink / raw)
To: linuxppc-dev
The current definitions set ranges and defaults for 32 and 64-bit
only using "PPC_STD_MMU" which means hash based MMU. This uselessly
restrict the usefulness for the upcoming 64-bit BookE port, but more
than that, it's broken on 32-bit since the only 32-bit platform
supporting multiple page sizes currently is 44x which does -not-
have PPC_STD_MMU_32 set.
This fixes it by using PPC64 and PPC32 instead.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
---
arch/powerpc/Kconfig | 20 ++++++++++----------
1 file changed, 10 insertions(+), 10 deletions(-)
--- linux-work.orig/arch/powerpc/Kconfig 2009-07-22 11:22:16.000000000 +1000
+++ linux-work/arch/powerpc/Kconfig 2009-07-22 11:22:39.000000000 +1000
@@ -492,16 +492,16 @@ endchoice
config FORCE_MAX_ZONEORDER
int "Maximum zone order"
- range 9 64 if PPC_STD_MMU_64 && PPC_64K_PAGES
- default "9" if PPC_STD_MMU_64 && PPC_64K_PAGES
- range 13 64 if PPC_STD_MMU_64 && !PPC_64K_PAGES
- default "13" if PPC_STD_MMU_64 && !PPC_64K_PAGES
- range 9 64 if PPC_STD_MMU_32 && PPC_16K_PAGES
- default "9" if PPC_STD_MMU_32 && PPC_16K_PAGES
- range 7 64 if PPC_STD_MMU_32 && PPC_64K_PAGES
- default "7" if PPC_STD_MMU_32 && PPC_64K_PAGES
- range 5 64 if PPC_STD_MMU_32 && PPC_256K_PAGES
- default "5" if PPC_STD_MMU_32 && PPC_256K_PAGES
+ range 9 64 if PPC64 && PPC_64K_PAGES
+ default "9" if PPC64 && PPC_64K_PAGES
+ range 13 64 if PPC64 && !PPC_64K_PAGES
+ default "13" if PPC64 && !PPC_64K_PAGES
+ range 9 64 if PPC32 && PPC_16K_PAGES
+ default "9" if PPC32 && PPC_16K_PAGES
+ range 7 64 if PPC32 && PPC_64K_PAGES
+ default "7" if PPC32 && PPC_64K_PAGES
+ range 5 64 if PPC32 && PPC_256K_PAGES
+ default "5" if PPC32 && PPC_256K_PAGES
range 11 64
default "11"
help
^ permalink raw reply
* [PATCH v3] net: Rework mdio-ofgpio driver to use of_mdio infrastructure
From: Mark Ware @ 2009-07-21 22:24 UTC (permalink / raw)
To: Grant Likely, netdev, Linuxppc-dev Development
Changes to the fs_enet driver (aa73832c5a80d6c52c69b18af858d88fa595dd3c) cause kernel crashes when using the mdio-ofgpio driver.
This patch replicates similar changes made to the fs_enet mii-bitbang drivers. It has been tested on a custom mpc8280 based board using an NFS
mounted root.
Signed-off-by: Mark Ware <mware@elphinstone.net>
Acked-by: Grant Likely <grant.likely@secretlab.ca>
---
The only changes in v3 are to the commit message.
drivers/net/phy/mdio-gpio.c | 77 ++++++++++++++++++++-----------------------
1 files changed, 36 insertions(+), 41 deletions(-)
diff --git a/drivers/net/phy/mdio-gpio.c b/drivers/net/phy/mdio-gpio.c
index 33984b7..22cdd45 100644
--- a/drivers/net/phy/mdio-gpio.c
+++ b/drivers/net/phy/mdio-gpio.c
@@ -30,6 +30,7 @@
#ifdef CONFIG_OF_GPIO
#include <linux/of_gpio.h>
+#include <linux/of_mdio.h>
#include <linux/of_platform.h>
#endif
@@ -81,13 +82,12 @@ static struct mdiobb_ops mdio_gpio_ops = {
.get_mdio_data = mdio_get,
};
-static int __devinit mdio_gpio_bus_init(struct device *dev,
+static struct mii_bus * __devinit mdio_gpio_bus_init(struct device *dev,
struct mdio_gpio_platform_data *pdata,
int bus_id)
{
struct mii_bus *new_bus;
struct mdio_gpio_info *bitbang;
- int ret = -ENOMEM;
int i;
bitbang = kzalloc(sizeof(*bitbang), GFP_KERNEL);
@@ -104,8 +104,6 @@ static int __devinit mdio_gpio_bus_init(struct device *dev,
new_bus->name = "GPIO Bitbanged MDIO",
- ret = -ENODEV;
-
new_bus->phy_mask = pdata->phy_mask;
new_bus->irq = pdata->irqs;
new_bus->parent = dev;
@@ -129,15 +127,8 @@ static int __devinit mdio_gpio_bus_init(struct device *dev,
dev_set_drvdata(dev, new_bus);
- ret = mdiobus_register(new_bus);
- if (ret)
- goto out_free_all;
-
- return 0;
+ return new_bus;
-out_free_all:
- dev_set_drvdata(dev, NULL);
- gpio_free(bitbang->mdio);
out_free_mdc:
gpio_free(bitbang->mdc);
out_free_bus:
@@ -145,30 +136,47 @@ out_free_bus:
out_free_bitbang:
kfree(bitbang);
out:
- return ret;
+ return NULL;
}
-static void __devexit mdio_gpio_bus_destroy(struct device *dev)
+static void __devinit mdio_gpio_bus_deinit(struct device *dev)
{
struct mii_bus *bus = dev_get_drvdata(dev);
struct mdio_gpio_info *bitbang = bus->priv;
- mdiobus_unregister(bus);
- free_mdio_bitbang(bus);
dev_set_drvdata(dev, NULL);
- gpio_free(bitbang->mdc);
gpio_free(bitbang->mdio);
+ gpio_free(bitbang->mdc);
+ free_mdio_bitbang(bus);
kfree(bitbang);
}
+static void __devexit mdio_gpio_bus_destroy(struct device *dev)
+{
+ struct mii_bus *bus = dev_get_drvdata(dev);
+
+ mdiobus_unregister(bus);
+ mdio_gpio_bus_deinit(dev);
+}
+
static int __devinit mdio_gpio_probe(struct platform_device *pdev)
{
struct mdio_gpio_platform_data *pdata = pdev->dev.platform_data;
+ struct mii_bus *new_bus;
+ int ret;
if (!pdata)
return -ENODEV;
- return mdio_gpio_bus_init(&pdev->dev, pdata, pdev->id);
+ new_bus = mdio_gpio_bus_init(&pdev->dev, pdata, pdev->id);
+ if (!new_bus)
+ return -ENODEV;
+
+ ret = mdiobus_register(new_bus);
+ if (ret)
+ mdio_gpio_bus_deinit(&pdev->dev);
+
+ return ret;
}
static int __devexit mdio_gpio_remove(struct platform_device *pdev)
@@ -179,29 +187,12 @@ static int __devexit mdio_gpio_remove(struct platform_device *pdev)
}
#ifdef CONFIG_OF_GPIO
-static void __devinit add_phy(struct mdio_gpio_platform_data *pdata,
- struct device_node *np)
-{
- const u32 *data;
- int len, id, irq;
-
- data = of_get_property(np, "reg", &len);
- if (!data || len != 4)
- return;
-
- id = *data;
- pdata->phy_mask &= ~(1 << id);
-
- irq = of_irq_to_resource(np, 0, NULL);
- if (irq)
- pdata->irqs[id] = irq;
-}
static int __devinit mdio_ofgpio_probe(struct of_device *ofdev,
const struct of_device_id *match)
{
- struct device_node *np = NULL;
struct mdio_gpio_platform_data *pdata;
+ struct mii_bus *new_bus;
int ret;
pdata = kzalloc(sizeof(*pdata), GFP_KERNEL);
@@ -215,14 +206,18 @@ static int __devinit mdio_ofgpio_probe(struct of_device *ofdev,
ret = of_get_gpio(ofdev->node, 1);
if (ret < 0)
- goto out_free;
+ goto out_free;
pdata->mdio = ret;
- while ((np = of_get_next_child(ofdev->node, np)))
- if (!strcmp(np->type, "ethernet-phy"))
- add_phy(pdata, np);
+ new_bus = mdio_gpio_bus_init(&ofdev->dev, pdata, pdata->mdc);
+ if (!new_bus)
+ return -ENODEV;
- return mdio_gpio_bus_init(&ofdev->dev, pdata, pdata->mdc);
+ ret = of_mdiobus_register(new_bus, ofdev->node);
+ if (ret)
+ mdio_gpio_bus_deinit(&ofdev->dev);
+
+ return ret;
out_free:
kfree(pdata);
--
1.5.6.5
^ permalink raw reply related
* mpc5121 Power Managment errata.
From: Kenneth Johansson @ 2009-07-21 17:16 UTC (permalink / raw)
To: Linuxppc-dev Development
[-- Attachment #1: Type: text/plain, Size: 1800 bytes --]
I have a bit of a problem with arch/powerpc/platforms/512x/mpc512x_pm.c
Since this one is not included in mainline (yet) I have attached it
Now I have a number of questions and one mystery.
1: why relocate the code ?? is there a reason why the code must be
located at address 0
http://www.bitshrine.org/gpp/linux-2.6.24.6-mpc5121-99-PM-alternate-external-int-vector.patch
say that this is due to a bug in the PMC module with status bits. Could
this not be worked around by avoiding modifying the exception handler
and just taken care of by C code in ipic.c
2: does it work ???
I ask since it do self modifying code but no invalidation of the
instruction cache.
Mystery: If I fix the cache issue with the code and force store of data
with dcbst and invalidate with icbi. I get a very unreliable resume
function that often end up in machine check all over the place
This machine check also happens on unmodified version but much much more
seldom. I'm just now running some test on a system that only patch this
in once and thus always run with this workaround without constantly
modifying the exception handler . but I wont know if it makes a
difference until tomorrow.
I have inserted this code in the end of both
mpc5121_copy_pmcclr
mpc5121_reinstall_handler
Is there some reason why this would not work ??
-----------------------------------------
/*
dcbst |update memory
sync |wait for update
icbi |remove (invalidate) copy in instruction cache
isync |remove copy in own instruction buffer
*/
lis r3, CONFIG_KERNEL_START@h
ori r3, r3, CONFIG_KERNEL_START@l
/* flush and invalidate from 0 to 0x600 */
li r5, 0x0
li r4, 0x600/L1_CACHE_BYTES
mtctr r4
1:
dcbst r5,r3
sync
icbi r5,r3
isync
addi r5, r5, L1_CACHE_BYTES /* Next line, please */
bdnz 1b
sync
isync
[-- Attachment #2: mpc512x.S --]
[-- Type: text/x-csrc, Size: 2854 bytes --]
#include <asm/reg.h>
#include <asm/ppc_asm.h>
#include <asm/processor.h>
#include <asm/page.h>
#include <asm/cache.h>
#define NUM_CACHE_LINES (128*8)
/* this variable added to reserve 0x20*4 bytes.
* This value has been derived by counting the
* number of lines of the function "code_atzero".
* In case if the size of this function increases
* the number of bytes have to increased accordi-
* ngly.
*/
.data
mpc5121_data_temp:
.space 0x20*4
.text
.globl mpc5121_copy_pmcclr
mpc5121_copy_pmcclr:
/* Coming here with interrupts disabled */
/* storing the content at 0x0 location
* to mpc512_data_temp space */
lis r6, CONFIG_KERNEL_START@h
mr r4, r6
li r3, (code_atzero_end - code_atzero)/4
mtctr r3
lis r3, mpc5121_data_temp@h
ori r3, r3, mpc5121_data_temp@l
/* loops here till the counter is zero */
loop:
lwz r5, 0(r4)
stw r5, 0(r3)
addi r3, r3, 4
addi r4, r4, 4
bdnz loop
/* Copy code to Location 0x0 */
mr r4, r6
li r3, (code_atzero_end - code_atzero)/4
mtctr r3
lis r3, code_atzero@h
ori r3, r3, code_atzero@l
1:
lwz r5, 0(r3)
stw r5, 0(r4)
addi r3, r3, 4
addi r4, r4, 4
bdnz 1b
/* Copy the jump to 0x0 code at 0x500*/
lwz r5, 0x500(r6)
stw r5, 0(r6)
lwz r5, 8(r6)
stw r5, 0x500(r6)
/* Flush the cache */
lis r3, CONFIG_KERNEL_START@h
ori r3, r3, CONFIG_KERNEL_START@l
/* Let us load data starting from 0x600 loc */
addi r3, r3, 0x600
li r4, NUM_CACHE_LINES
mtctr r4
1:
lwz r4, 0(r3)
addi r3, r3, L1_CACHE_BYTES /* Next line, please */
bdnz 1b
sync; isync
blr
.globl mpc5121_reinstall_handler
mpc5121_reinstall_handler:
/* Rewrite original code at 0x500 */
lis r6, CONFIG_KERNEL_START@h
lwz r5, 0(r6)
stw r5, 0x500(r6)
/* restoring content at 0x0 location */
mr r4, r6
li r3, (code_atzero_end - code_atzero)/4
mtctr r3
lis r3, mpc5121_data_temp@h
ori r3, r3, mpc5121_data_temp@l
/* loops here till the counter is zero */
loop1:
lwz r5, 0(r3)
stw r5, 0(r4)
addi r3, r3, 4
addi r4, r4, 4
bdnz loop1
blr
code_atzero:
.long 0x0 /*Space reserved for copying first word of code from 0x500 */
ba 0x504
ba 0xc /* This code is not executed. This code is copied to 0x500 */
mtspr SPRN_SPRG0, r3
mtspr SPRN_SPRG1, r4
mfspr r3, 311
addi r3, r3, 0x1000 /* Assuming that MBAR is aligned to this size */
lwz r4, 0x4(r3)
stw r4, 0x4(r3)
/* clearing GPIO evnet registers */
mfspr r3, 311
/* getting offset of GPIO */
addi r3, r3,0x1100
lwz r4, 0xC(r3)
stw r4, 0xC(r3)
mfspr r3, SPRN_SPRG0
mfspr r4, SPRN_SPRG1
ba 0x0
code_atzero_end:
b code_atzero_end /* Should never reach here*/
^ permalink raw reply
* Re: [PATCH v2] net: Rework mdio-ofgpio driver to use of_mdio infrastructure
From: Grant Likely @ 2009-07-21 17:09 UTC (permalink / raw)
To: Mark Ware; +Cc: netdev, David Miller, linuxppc-dev
In-Reply-To: <4A658F69.7020002@elphinstone.net>
On Tue, Jul 21, 2009 at 3:50 AM, Mark Ware<mware@elphinstone.net> wrote:
> Changes to the fs_enet driver (aa73832c5a80d6c52c69b18af858d88fa595dd3c)
> cause kernel crashes when using the mdio-ofgpio driver.
>
> The following patch replicates similar changes made to the fs_enet
> mii-bitbang drivers.
This looks good to me. I've not tested it though (no hardware that
uses it). You should specify the testing you've done in the commit
log. Your signed-off-by: line is also missing.
Acked-by: Grant Likely <grant.likely@secretlab.ca>
David, once the above issues are solved, this one needs to be merged for 2.=
6.31.
Cheers,
g.
> ---
>
> This version attempts to address Grant's comments below:
>
> Grant Likely wrote:
>>
>> You should refactor mdio_gpio_bus_init() to not call
>> mdiobus_register() at all, and instead just return a pointer to the
>> unregistered new_bus. =A0Then mdio_gpio_probe() and mdio_ofgpio_probe()
>> can call the correct register variant directly. =A0Fewer ugly #ifdefs
>> this way. =A0It also eliminates the need to cast the void* pointer.
>>
>
> =A0drivers/net/phy/mdio-gpio.c | =A0 77
> ++++++++++++++++++++-----------------------
> =A01 files changed, 36 insertions(+), 41 deletions(-)
>
> diff --git a/drivers/net/phy/mdio-gpio.c b/drivers/net/phy/mdio-gpio.c
> index 33984b7..22cdd45 100644
> --- a/drivers/net/phy/mdio-gpio.c
> +++ b/drivers/net/phy/mdio-gpio.c
> @@ -30,6 +30,7 @@
>
> =A0#ifdef CONFIG_OF_GPIO
> =A0#include <linux/of_gpio.h>
> +#include <linux/of_mdio.h>
> =A0#include <linux/of_platform.h>
> =A0#endif
>
> @@ -81,13 +82,12 @@ static struct mdiobb_ops mdio_gpio_ops =3D {
> =A0 =A0 =A0 =A0.get_mdio_data =3D mdio_get,
> =A0};
>
> -static int __devinit mdio_gpio_bus_init(struct device *dev,
> +static struct mii_bus * __devinit mdio_gpio_bus_init(struct device *dev,
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0struct mdio_gpio_platform_data
> *pdata,
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0int bus_id)
> =A0{
> =A0 =A0 =A0 =A0struct mii_bus *new_bus;
> =A0 =A0 =A0 =A0struct mdio_gpio_info *bitbang;
> - =A0 =A0 =A0 int ret =3D -ENOMEM;
> =A0 =A0 =A0 =A0int i;
>
> =A0 =A0 =A0 =A0bitbang =3D kzalloc(sizeof(*bitbang), GFP_KERNEL);
> @@ -104,8 +104,6 @@ static int __devinit mdio_gpio_bus_init(struct device
> *dev,
>
> =A0 =A0 =A0 =A0new_bus->name =3D "GPIO Bitbanged MDIO",
>
> - =A0 =A0 =A0 ret =3D -ENODEV;
> -
> =A0 =A0 =A0 =A0new_bus->phy_mask =3D pdata->phy_mask;
> =A0 =A0 =A0 =A0new_bus->irq =3D pdata->irqs;
> =A0 =A0 =A0 =A0new_bus->parent =3D dev;
> @@ -129,15 +127,8 @@ static int __devinit mdio_gpio_bus_init(struct devic=
e
> *dev,
>
> =A0 =A0 =A0 =A0dev_set_drvdata(dev, new_bus);
>
> - =A0 =A0 =A0 ret =3D mdiobus_register(new_bus);
> - =A0 =A0 =A0 if (ret)
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 goto out_free_all;
> -
> - =A0 =A0 =A0 return 0;
> + =A0 =A0 =A0 return new_bus;
>
> -out_free_all:
> - =A0 =A0 =A0 dev_set_drvdata(dev, NULL);
> - =A0 =A0 =A0 gpio_free(bitbang->mdio);
> =A0out_free_mdc:
> =A0 =A0 =A0 =A0gpio_free(bitbang->mdc);
> =A0out_free_bus:
> @@ -145,30 +136,47 @@ out_free_bus:
> =A0out_free_bitbang:
> =A0 =A0 =A0 =A0kfree(bitbang);
> =A0out:
> - =A0 =A0 =A0 return ret;
> + =A0 =A0 =A0 return NULL;
> =A0}
>
> -static void __devexit mdio_gpio_bus_destroy(struct device *dev)
> +static void __devinit mdio_gpio_bus_deinit(struct device *dev)
> =A0{
> =A0 =A0 =A0 =A0struct mii_bus *bus =3D dev_get_drvdata(dev);
> =A0 =A0 =A0 =A0struct mdio_gpio_info *bitbang =3D bus->priv;
>
> - =A0 =A0 =A0 mdiobus_unregister(bus);
> - =A0 =A0 =A0 free_mdio_bitbang(bus);
> =A0 =A0 =A0 =A0dev_set_drvdata(dev, NULL);
> - =A0 =A0 =A0 gpio_free(bitbang->mdc);
> =A0 =A0 =A0 =A0gpio_free(bitbang->mdio);
> + =A0 =A0 =A0 gpio_free(bitbang->mdc);
> + =A0 =A0 =A0 free_mdio_bitbang(bus);
> =A0 =A0 =A0 =A0kfree(bitbang);
> =A0}
>
> +static void __devexit mdio_gpio_bus_destroy(struct device *dev)
> +{
> + =A0 =A0 =A0 struct mii_bus *bus =3D dev_get_drvdata(dev);
> +
> + =A0 =A0 =A0 mdiobus_unregister(bus);
> + =A0 =A0 =A0 mdio_gpio_bus_deinit(dev);
> +}
> +
> =A0static int __devinit mdio_gpio_probe(struct platform_device *pdev)
> =A0{
> =A0 =A0 =A0 =A0struct mdio_gpio_platform_data *pdata =3D pdev->dev.platfo=
rm_data;
> + =A0 =A0 =A0 struct mii_bus *new_bus;
> + =A0 =A0 =A0 int ret;
>
> =A0 =A0 =A0 =A0if (!pdata)
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0return -ENODEV;
>
> - =A0 =A0 =A0 return mdio_gpio_bus_init(&pdev->dev, pdata, pdev->id);
> + =A0 =A0 =A0 new_bus =3D mdio_gpio_bus_init(&pdev->dev, pdata, pdev->id)=
;
> + =A0 =A0 =A0 if (!new_bus)
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 return -ENODEV;
> +
> + =A0 =A0 =A0 ret =3D mdiobus_register(new_bus);
> + =A0 =A0 =A0 if (ret)
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 mdio_gpio_bus_deinit(&pdev->dev);
> +
> + =A0 =A0 =A0 return ret;
> =A0}
>
> =A0static int __devexit mdio_gpio_remove(struct platform_device *pdev)
> @@ -179,29 +187,12 @@ static int __devexit mdio_gpio_remove(struct
> platform_device *pdev)
> =A0}
>
> =A0#ifdef CONFIG_OF_GPIO
> -static void __devinit add_phy(struct mdio_gpio_platform_data *pdata,
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 struct device_n=
ode *np)
> -{
> - =A0 =A0 =A0 const u32 *data;
> - =A0 =A0 =A0 int len, id, irq;
> -
> - =A0 =A0 =A0 data =3D of_get_property(np, "reg", &len);
> - =A0 =A0 =A0 if (!data || len !=3D 4)
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 return;
> -
> - =A0 =A0 =A0 id =3D *data;
> - =A0 =A0 =A0 pdata->phy_mask &=3D ~(1 << id);
> -
> - =A0 =A0 =A0 irq =3D of_irq_to_resource(np, 0, NULL);
> - =A0 =A0 =A0 if (irq)
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 pdata->irqs[id] =3D irq;
> -}
>
> =A0static int __devinit mdio_ofgpio_probe(struct of_device *ofdev,
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 const struct of_device_id *match)
> =A0{
> - =A0 =A0 =A0 struct device_node *np =3D NULL;
> =A0 =A0 =A0 =A0struct mdio_gpio_platform_data *pdata;
> + =A0 =A0 =A0 struct mii_bus *new_bus;
> =A0 =A0 =A0 =A0int ret;
>
> =A0 =A0 =A0 =A0pdata =3D kzalloc(sizeof(*pdata), GFP_KERNEL);
> @@ -215,14 +206,18 @@ static int __devinit mdio_ofgpio_probe(struct
> of_device *ofdev,
>
> =A0 =A0 =A0 =A0ret =3D of_get_gpio(ofdev->node, 1);
> =A0 =A0 =A0 =A0if (ret < 0)
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0goto out_free;
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 goto out_free;
> =A0 =A0 =A0 =A0pdata->mdio =3D ret;
>
> - =A0 =A0 =A0 while ((np =3D of_get_next_child(ofdev->node, np)))
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 if (!strcmp(np->type, "ethernet-phy"))
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 add_phy(pdata, np);
> + =A0 =A0 =A0 new_bus =3D mdio_gpio_bus_init(&ofdev->dev, pdata, pdata->m=
dc);
> + =A0 =A0 =A0 if (!new_bus)
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 return -ENODEV;
>
> - =A0 =A0 =A0 return mdio_gpio_bus_init(&ofdev->dev, pdata, pdata->mdc);
> + =A0 =A0 =A0 ret =3D of_mdiobus_register(new_bus, ofdev->node);
> + =A0 =A0 =A0 if (ret)
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 mdio_gpio_bus_deinit(&ofdev->dev);
> +
> + =A0 =A0 =A0 return ret;
>
> =A0out_free:
> =A0 =A0 =A0 =A0kfree(pdata);
> --
> 1.5.6.5
>
--=20
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: [PATCH] PowerPC 440EPx: Sequoia bootwrapper
From: Stefan Roese @ 2009-07-21 16:52 UTC (permalink / raw)
To: Bob Burke; +Cc: linuxppc-dev
In-Reply-To: <2C7DE72B9BD00F44BAECA5B0CBB873956CDC46@hermes.terascala.com>
On Tuesday 21 July 2009 17:56:40 Bob Burke wrote:
> On Tue, 21 Jul 2009 16:06:53 Stefan Roese wrote:
> > Unfortunately it's not that easy. Earlier Sequoia board revisions are
> > equipped with an 33.333MHz oscillator. This can be detected via a
> > CPLD register though.
>
> Thanks, I didn't realize that. FYI our deployed platform is similar to
> Sequoia,
> but is a custom design. It has a 33 MHz system clock.
OK. Then you should add a new target for your custom board (cuboot-namexyz.c).
> > But why are you using the boot wrapper? If your U-Boot isn't too old,
> > you can boot uImage directly (with dtb of course). No need for the
> > wrapper.
>
> Since we have deployed product, using a non OF kernel, we have made the
> decision not to upgrade U-Boot in the field.
OK, understood.
Thanks,
Stefan
^ permalink raw reply
* RE: [PATCH] PowerPC 440EPx: Sequoia bootwrapper
From: Bob Burke @ 2009-07-21 15:56 UTC (permalink / raw)
To: Stefan Roese, linuxppc-dev
In-Reply-To: <200907211606.52572.sr@denx.de>
On Tue, 21 Jul 2009 16:06:53 Stefan Roese wrote:
> Unfortunately it's not that easy. Earlier Sequoia board revisions are
> equipped with an 33.333MHz oscillator. This can be detected via a
CPLD
> register though.
Thanks, I didn't realize that. FYI our deployed platform is similar to
Sequoia,
but is a custom design. It has a 33 MHz system clock.
> But why are you using the boot wrapper? If your U-Boot isn't too old,
you can
> boot uImage directly (with dtb of course). No need for the wrapper.
Since we have deployed product, using a non OF kernel, we have made the
decision
not to upgrade U-Boot in the field.
Thanks,
Bob
^ permalink raw reply
* Re: [PATCH] PowerPC 440EPx: Sequoia bootwrapper
From: Stefan Roese @ 2009-07-21 14:06 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Bob Burke
In-Reply-To: <2C7DE72B9BD00F44BAECA5B0CBB873956CDC2B@hermes.terascala.com>
On Tuesday 21 July 2009 15:33:20 Bob Burke wrote:
> The system clock frequency on the Sequoia board is 33.000000 MHz not
> 33.333333 MHz; this causes the system time to drift more than 30 seconds
> per hour.
>
> diff -ruN a/arch/powerpc/boot/cuboot-sequoia.c
> b/arch/powerpc/boot/cuboot-sequoia.c
> --- a/arch/powerpc/boot/cuboot-sequoia.c 2009-05-18
> 19:52:34.000000000 -0400
> +++ b/arch/powerpc/boot/cuboot-sequoia.c 2009-07-21
> 09:13:13.000000000 -0400
> @@ -37,7 +37,7 @@
>
> static void sequoia_fixups(void)
> {
> - unsigned long sysclk = 33333333;
> + unsigned long sysclk = 33000000;
>
> ibm440ep_fixup_clocks(sysclk, 11059200, 50000000);
> ibm4xx_fixup_ebc_ranges("/plb/opb/ebc");
Unfortunately it's not that easy. Earlier Sequoia board revisions are equipped
with an 33.333MHz oscillator. This can be detected via a CPLD register though.
Here the "code" from U-Boot (just as an example):
/* Detect Sequoia PLL input clock automatically via CPLD bit */
#define CONFIG_SYS_BCSR_BASE 0xc0000000
#define CONFIG_SYS_CLK_FREQ ((in8(CONFIG_SYS_BCSR_BASE + 3) & 0x80) ? \
33333333 : 33000000)
But why are you using the boot wrapper? If your U-Boot isn't too old, you can
boot uImage directly (with dtb of course). No need for the wrapper.
Thanks,
Stefan
^ permalink raw reply
* [PATCH] PowerPC 440EPx: Sequoia bootwrapper
From: Bob Burke @ 2009-07-21 13:33 UTC (permalink / raw)
To: linuxppc-dev
The system clock frequency on the Sequoia board is 33.000000 MHz not
33.333333 MHz; this causes the system time to drift more than 30 seconds
per hour.
diff -ruN a/arch/powerpc/boot/cuboot-sequoia.c
b/arch/powerpc/boot/cuboot-sequoia.c
--- a/arch/powerpc/boot/cuboot-sequoia.c 2009-05-18
19:52:34.000000000 -0400
+++ b/arch/powerpc/boot/cuboot-sequoia.c 2009-07-21
09:13:13.000000000 -0400
@@ -37,7 +37,7 @@
static void sequoia_fixups(void)
{
- unsigned long sysclk =3D 33333333;
+ unsigned long sysclk =3D 33000000;
ibm440ep_fixup_clocks(sysclk, 11059200, 50000000);
ibm4xx_fixup_ebc_ranges("/plb/opb/ebc");
^ permalink raw reply
* Re: Best hardware platform for native compiling...
From: David Jander @ 2009-07-21 13:07 UTC (permalink / raw)
To: Gabriel Paubert; +Cc: linuxppc-dev
In-Reply-To: <20090721120007.GA23164@iram.es>
On Tuesday 21 July 2009 14:00:07 you wrote:
> On Tue, Jul 21, 2009 at 12:31:36PM +0200, David Jander wrote:
> > On Tuesday 21 July 2009 11:52:51 you wrote:
> > > On Tue, Jul 21, 2009 at 11:16:52AM +0200, David Jander wrote:
> > > > For bigger systems we often run a debian-derived OS like Ubuntu, and
> > > > many pieces are compiled natively on the target... just because it is
> > > > easy and quick to do, and cross-compiling certain packages can be a
> > > > real pain. But, a 400 MHz e300 core is not really fast for compiling,
> > > > so I have been considering buying some sort of PowerPC-based system
> > > > with a faster processor, just as a "build-server" (a G5 would do
> > > > wonders I guess).
> > > >
> > > > It seems like the only real option is one of the smaller IBM Power
> > > > servers, but that seems overkill to me. We also don't feel like
> > > > buying some old second-hand Apple gear.
> > > >
> > > > Is there any other available and affordable platform that can be used
> > > > to run linux and compile software natively for 32-bit PowerPC?
> > >
> > > Have a look at the YDL PowerStation:
> > >
> > > http://us.fixstars.com/products/powerstation/
> > >
> > > It is more or less a quad G5.
> >
> > This looks great! Thanks a lot for the tip.
> > I still have to figure out how to get one of these delivered to Europe,
> > but that shouldn't be such a big deal...
>
> Well, I got one recently here in Spain. Shipping charges are fairly
> large (it's not exactly a light and compact machine). But the current
> dollar exchange rate helps ;-)
>
> Now I have not yet found the way to install Debian on it
> (it refuses to boot Debian's CDROM), but I have not had
> time to investigate either.
If nothing else helps, try (manually) installing debootstrap from ubuntu
sources and start from there with "debootstrap jaunty /mnt/partition" ;-)
Best regards,
--
David Jander
Protonic Holland.
^ permalink raw reply
* Re: Best hardware platform for native compiling...
From: Benjamin Herrenschmidt @ 2009-07-21 12:47 UTC (permalink / raw)
To: Gabriel Paubert; +Cc: linuxppc-dev, David Jander
In-Reply-To: <20090721120007.GA23164@iram.es>
On Tue, 2009-07-21 at 14:00 +0200, Gabriel Paubert wrote:
> Well, I got one recently here in Spain. Shipping charges are fairly
> large (it's not exactly a light and compact machine). But the current
> dollar exchange rate helps ;-)
>
> Now I have not yet found the way to install Debian on it
> (it refuses to boot Debian's CDROM), but I have not had
> time to investigate either.
It uses SLOF which should be capable of decent netbooting, so it should
be possible to either netboot yaboot and have it load the kernel and
initramfs, or maybe make a zImage with both included and netboot that.
Cheers,
Ben.
^ permalink raw reply
* Re: Best hardware platform for native compiling...
From: Gabriel Paubert @ 2009-07-21 12:00 UTC (permalink / raw)
To: David Jander; +Cc: linuxppc-dev
In-Reply-To: <200907211231.37299.david.jander@protonic.nl>
On Tue, Jul 21, 2009 at 12:31:36PM +0200, David Jander wrote:
> On Tuesday 21 July 2009 11:52:51 you wrote:
> > On Tue, Jul 21, 2009 at 11:16:52AM +0200, David Jander wrote:
> > > For bigger systems we often run a debian-derived OS like Ubuntu, and many
> > > pieces are compiled natively on the target... just because it is easy and
> > > quick to do, and cross-compiling certain packages can be a real pain.
> > > But, a 400 MHz e300 core is not really fast for compiling, so I have been
> > > considering buying some sort of PowerPC-based system with a faster
> > > processor, just as a "build-server" (a G5 would do wonders I guess).
> > >
> > > It seems like the only real option is one of the smaller IBM Power
> > > servers, but that seems overkill to me. We also don't feel like buying
> > > some old second-hand Apple gear.
> > >
> > > Is there any other available and affordable platform that can be used to
> > > run linux and compile software natively for 32-bit PowerPC?
> >
> > Have a look at the YDL PowerStation:
> >
> > http://us.fixstars.com/products/powerstation/
> >
> > It is more or less a quad G5.
>
> This looks great! Thanks a lot for the tip.
> I still have to figure out how to get one of these delivered to Europe, but
> that shouldn't be such a big deal...
Well, I got one recently here in Spain. Shipping charges are fairly
large (it's not exactly a light and compact machine). But the current
dollar exchange rate helps ;-)
Now I have not yet found the way to install Debian on it
(it refuses to boot Debian's CDROM), but I have not had
time to investigate either.
Regards,
Gabriel
^ permalink raw reply
* Re: Best hardware platform for native compiling...
From: David Jander @ 2009-07-21 10:31 UTC (permalink / raw)
To: Adrian Reber; +Cc: linuxppc-dev
In-Reply-To: <20090721095251.GG32034@lisas.de>
On Tuesday 21 July 2009 11:52:51 you wrote:
> On Tue, Jul 21, 2009 at 11:16:52AM +0200, David Jander wrote:
> > For bigger systems we often run a debian-derived OS like Ubuntu, and many
> > pieces are compiled natively on the target... just because it is easy and
> > quick to do, and cross-compiling certain packages can be a real pain.
> > But, a 400 MHz e300 core is not really fast for compiling, so I have been
> > considering buying some sort of PowerPC-based system with a faster
> > processor, just as a "build-server" (a G5 would do wonders I guess).
> >
> > It seems like the only real option is one of the smaller IBM Power
> > servers, but that seems overkill to me. We also don't feel like buying
> > some old second-hand Apple gear.
> >
> > Is there any other available and affordable platform that can be used to
> > run linux and compile software natively for 32-bit PowerPC?
>
> Have a look at the YDL PowerStation:
>
> http://us.fixstars.com/products/powerstation/
>
> It is more or less a quad G5.
This looks great! Thanks a lot for the tip.
I still have to figure out how to get one of these delivered to Europe, but
that shouldn't be such a big deal...
Best regards,
--
David Jander
Protonic Holland.
^ permalink raw reply
* [PATCH] powerpc/cell: replace strncpy by strlcpy
From: Roel Kluin @ 2009-07-21 10:17 UTC (permalink / raw)
To: Ken Kawakami; +Cc: linuxppc-dev, Andrew Morton, cbe-oss-dev, arnd
In-Reply-To: <4A607185.6020302@gmail.com>
Replace strncpy() and explicit null-termination by strlcpy()
Signed-off-by: Roel Kluin <roel.kluin@gmail.com>
---
Arnd-san, Ken-san,
Thanks for reviewing,
> We prefer to take the patch which is replacing the two lines with one.
Doozo.
diff --git a/arch/powerpc/platforms/cell/celleb_setup.c b/arch/powerpc/platforms/cell/celleb_setup.c
index 07c234f..e538455 100644
--- a/arch/powerpc/platforms/cell/celleb_setup.c
+++ b/arch/powerpc/platforms/cell/celleb_setup.c
@@ -80,8 +80,7 @@ static void celleb_show_cpuinfo(struct seq_file *m)
static int __init celleb_machine_type_hack(char *ptr)
{
- strncpy(celleb_machine_type, ptr, sizeof(celleb_machine_type));
- celleb_machine_type[sizeof(celleb_machine_type)-1] = 0;
+ strlcpy(celleb_machine_type, ptr, sizeof(celleb_machine_type));
return 0;
}
^ permalink raw reply related
* [PATCH v2] net: Rework mdio-ofgpio driver to use of_mdio infrastructure
From: Mark Ware @ 2009-07-21 9:50 UTC (permalink / raw)
To: Grant Likely, netdev, linuxppc-dev
In-Reply-To: <fa686aa40907200759h1e4ec8cfh8a35890127a899a1@mail.gmail.com>
Changes to the fs_enet driver (aa73832c5a80d6c52c69b18af858d88fa595dd3c) cause kernel crashes when using the mdio-ofgpio driver.
The following patch replicates similar changes made to the fs_enet mii-bitbang drivers.
---
This version attempts to address Grant's comments below:
Grant Likely wrote:
>
> You should refactor mdio_gpio_bus_init() to not call
> mdiobus_register() at all, and instead just return a pointer to the
> unregistered new_bus. Then mdio_gpio_probe() and mdio_ofgpio_probe()
> can call the correct register variant directly. Fewer ugly #ifdefs
> this way. It also eliminates the need to cast the void* pointer.
>
drivers/net/phy/mdio-gpio.c | 77 ++++++++++++++++++++-----------------------
1 files changed, 36 insertions(+), 41 deletions(-)
diff --git a/drivers/net/phy/mdio-gpio.c b/drivers/net/phy/mdio-gpio.c
index 33984b7..22cdd45 100644
--- a/drivers/net/phy/mdio-gpio.c
+++ b/drivers/net/phy/mdio-gpio.c
@@ -30,6 +30,7 @@
#ifdef CONFIG_OF_GPIO
#include <linux/of_gpio.h>
+#include <linux/of_mdio.h>
#include <linux/of_platform.h>
#endif
@@ -81,13 +82,12 @@ static struct mdiobb_ops mdio_gpio_ops = {
.get_mdio_data = mdio_get,
};
-static int __devinit mdio_gpio_bus_init(struct device *dev,
+static struct mii_bus * __devinit mdio_gpio_bus_init(struct device *dev,
struct mdio_gpio_platform_data *pdata,
int bus_id)
{
struct mii_bus *new_bus;
struct mdio_gpio_info *bitbang;
- int ret = -ENOMEM;
int i;
bitbang = kzalloc(sizeof(*bitbang), GFP_KERNEL);
@@ -104,8 +104,6 @@ static int __devinit mdio_gpio_bus_init(struct device *dev,
new_bus->name = "GPIO Bitbanged MDIO",
- ret = -ENODEV;
-
new_bus->phy_mask = pdata->phy_mask;
new_bus->irq = pdata->irqs;
new_bus->parent = dev;
@@ -129,15 +127,8 @@ static int __devinit mdio_gpio_bus_init(struct device *dev,
dev_set_drvdata(dev, new_bus);
- ret = mdiobus_register(new_bus);
- if (ret)
- goto out_free_all;
-
- return 0;
+ return new_bus;
-out_free_all:
- dev_set_drvdata(dev, NULL);
- gpio_free(bitbang->mdio);
out_free_mdc:
gpio_free(bitbang->mdc);
out_free_bus:
@@ -145,30 +136,47 @@ out_free_bus:
out_free_bitbang:
kfree(bitbang);
out:
- return ret;
+ return NULL;
}
-static void __devexit mdio_gpio_bus_destroy(struct device *dev)
+static void __devinit mdio_gpio_bus_deinit(struct device *dev)
{
struct mii_bus *bus = dev_get_drvdata(dev);
struct mdio_gpio_info *bitbang = bus->priv;
- mdiobus_unregister(bus);
- free_mdio_bitbang(bus);
dev_set_drvdata(dev, NULL);
- gpio_free(bitbang->mdc);
gpio_free(bitbang->mdio);
+ gpio_free(bitbang->mdc);
+ free_mdio_bitbang(bus);
kfree(bitbang);
}
+static void __devexit mdio_gpio_bus_destroy(struct device *dev)
+{
+ struct mii_bus *bus = dev_get_drvdata(dev);
+
+ mdiobus_unregister(bus);
+ mdio_gpio_bus_deinit(dev);
+}
+
static int __devinit mdio_gpio_probe(struct platform_device *pdev)
{
struct mdio_gpio_platform_data *pdata = pdev->dev.platform_data;
+ struct mii_bus *new_bus;
+ int ret;
if (!pdata)
return -ENODEV;
- return mdio_gpio_bus_init(&pdev->dev, pdata, pdev->id);
+ new_bus = mdio_gpio_bus_init(&pdev->dev, pdata, pdev->id);
+ if (!new_bus)
+ return -ENODEV;
+
+ ret = mdiobus_register(new_bus);
+ if (ret)
+ mdio_gpio_bus_deinit(&pdev->dev);
+
+ return ret;
}
static int __devexit mdio_gpio_remove(struct platform_device *pdev)
@@ -179,29 +187,12 @@ static int __devexit mdio_gpio_remove(struct platform_device *pdev)
}
#ifdef CONFIG_OF_GPIO
-static void __devinit add_phy(struct mdio_gpio_platform_data *pdata,
- struct device_node *np)
-{
- const u32 *data;
- int len, id, irq;
-
- data = of_get_property(np, "reg", &len);
- if (!data || len != 4)
- return;
-
- id = *data;
- pdata->phy_mask &= ~(1 << id);
-
- irq = of_irq_to_resource(np, 0, NULL);
- if (irq)
- pdata->irqs[id] = irq;
-}
static int __devinit mdio_ofgpio_probe(struct of_device *ofdev,
const struct of_device_id *match)
{
- struct device_node *np = NULL;
struct mdio_gpio_platform_data *pdata;
+ struct mii_bus *new_bus;
int ret;
pdata = kzalloc(sizeof(*pdata), GFP_KERNEL);
@@ -215,14 +206,18 @@ static int __devinit mdio_ofgpio_probe(struct of_device *ofdev,
ret = of_get_gpio(ofdev->node, 1);
if (ret < 0)
- goto out_free;
+ goto out_free;
pdata->mdio = ret;
- while ((np = of_get_next_child(ofdev->node, np)))
- if (!strcmp(np->type, "ethernet-phy"))
- add_phy(pdata, np);
+ new_bus = mdio_gpio_bus_init(&ofdev->dev, pdata, pdata->mdc);
+ if (!new_bus)
+ return -ENODEV;
- return mdio_gpio_bus_init(&ofdev->dev, pdata, pdata->mdc);
+ ret = of_mdiobus_register(new_bus, ofdev->node);
+ if (ret)
+ mdio_gpio_bus_deinit(&ofdev->dev);
+
+ return ret;
out_free:
kfree(pdata);
--
1.5.6.5
^ permalink raw reply related
* Best hardware platform for native compiling...
From: David Jander @ 2009-07-21 9:16 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Wolfgang Denk
Hi all,
This might sound as a stupid question (and maybe sligtly off-topic), but I
have not found an (easy) answer and I suspect many on this list will have a
good suggestion to make:
We are developing (and maintaining) different embedded linux systems based on
different PowerPC processors. From small MPC852T with little RAM and Flash,
up to 400MHz MPC5200- and MPC5121e based systems that resemble more a PC or
netbook than an embedded system in terms of RAM and storage.
For smaller systems we use a customized ELDK-based OS and cross-compile almost
everything on a PC.
For bigger systems we often run a debian-derived OS like Ubuntu, and many
pieces are compiled natively on the target... just because it is easy and
quick to do, and cross-compiling certain packages can be a real pain.
But, a 400 MHz e300 core is not really fast for compiling, so I have been
considering buying some sort of PowerPC-based system with a faster processor,
just as a "build-server" (a G5 would do wonders I guess).
It seems like the only real option is one of the smaller IBM Power servers,
but that seems overkill to me. We also don't feel like buying some old
second-hand Apple gear.
Is there any other available and affordable platform that can be used to run
linux and compile software natively for 32-bit PowerPC?
Any suggestion is welcome!
Best regards,
P.S.: I am writing this while running "dpkg-buildpackage -rfakeroot" on the
package "xserver-xfbdev" from ubuntu 9.04 on a MPC5121e.... it will take 40
minutes ;-)
--
David Jander
Protonic Holland.
^ permalink raw reply
* msgctl10 fails on Powerpc Linux-2.6.29.6
From: srikanth krishnakar @ 2009-07-21 9:33 UTC (permalink / raw)
To: Linuxppc-dev; +Cc: Ltp-list
[-- Attachment #1: Type: text/plain, Size: 2019 bytes --]
The LTP test case *msgctl10.c* fails on linux-2.6.29.6 for PowerPC
architecture (ppc440)
msgctl10 1 B------------[ cut here
]------------
kernel BUG at
arch/powerpc/kernel/traps.c:904!
Oops: Exception in kernel mode, sig: 5
[#9]
PREEMPT LTT NESTING LEVEL :
0
Virtex440
Modules linked
in:
NIP: c038178c LR: c0381640 CTR:
c02650bc
REGS: cafbbe70 TRAP: 0700 Tainted: G D
(2.6.29.6)
MSR: 00029000 <EE,ME,CE> CR: 48004224 XER:
20000008
TASK = cafa17f0[6435] 'msgctl10' THREAD:
cafba000
GPR00: 00000001 cafbbf20 cafa17f0 ffffffda 08000000 00000001 00000037
ffffffff
GPR08: cafa17f0 c04a0000 00021002 c0381594 28004222 1001f4bc bf93d950
100b0000
GPR16: 00000007 bf93d95c 100012a0 10005b84 00000067 100174e8 10017500
100174f8
GPR24: 00000000 00000001 103eaa50 00000000 00000000 00000000 08000000
cafbbf50
NIP [c038178c]
program_check_exception+0x1f8/0x5f4
LR [c0381640]
program_check_exception+0xac/0x5f4
Call
Trace:
[cafbbf20] [c0381640] program_check_exception+0xac/0x5f4
(unreliable)
[cafbbf40] [c000e78c]
ret_from_except_full+0x0/0x4c
Instruction
dump:
7d808120 4bc8ac20 2f830001 41beff38 2f83fff2 419e0024 77c00804
4182004c
3d20c04a 8809207c 2f800000 419e0080 <0fe00000> 48000000 80010024
3ca00003
---[ end trace fd0893c7d8cee1bd
]---
ROK : Unexpected signal 11
received.
msgctl10 1 FAIL : in read # = 21245,key =
533a
msgctl10 0 WARN : Verify error in child 13, *buf = f1, val = 6d, size
= 3
msgctl10 1 BROK : Unexpected signal 11
received.
msgctl10 1 BROK : Msgsnd error in child 14, key = d344 errno =
43
msgctl10 0 WARN : tst_rmdir(): rmobj(/tmp/msgNjyTEb) failed:
lstat(/tmp/msgNjyTEb) failed; errno=2: No such file or directory
msgctl10 0 WARN : tst_rmdir(): rmobj(/tmp/msgNjyTEb) failed:
lstat(/tmp/msgNjyTEb) failed; errno=2: No such file or directory
msgctl10 1 FAIL : in read # = 54260,key =
d46d
msgctl10 1 B------------[ cut here ]------------
Any clue ?
Thanks in Advance !
--
Srikanth Krishnakar
**********************
[-- Attachment #2: Type: text/html, Size: 4491 bytes --]
^ permalink raw reply
* RE: DMA Engine on MPC8270
From: Li Yang-R58472 @ 2009-07-21 9:32 UTC (permalink / raw)
To: Felix Radensky, linuxppc-dev
In-Reply-To: <4A65887B.8090103@embedded-sol.com>
>Hi,
>
>Can Freescale DMA engine driver can be used on MPC2870 ?
No, the driver is only used on 83xx and 85xx cpus.
- Leo
^ permalink raw reply
* Re: [PATCH] powerpc/cell: strncpy does not null terminate string
From: Ken Kawakami @ 2009-07-21 9:31 UTC (permalink / raw)
To: arnd; +Cc: linuxppc-dev, akpm, roel.kluin, cbe-oss-dev
In-Reply-To: <200907171756.22224.arnd@arndb.de>
Arnd-san, Roel-san,
Thanks for pointing us to the redundant cord portion.
> On Friday 17 July 2009, Roel Kluin wrote:
> >
> > static int __init celleb_machine_type_hack(char *ptr)
> > {
> > - strncpy(celleb_machine_type, ptr, sizeof(celleb_machine_type));
> > + strlcpy(celleb_machine_type, ptr, sizeof(celleb_machine_type));
> > celleb_machine_type[sizeof(celleb_machine_type)-1] = 0;
> > return 0;
>
> This still is pointless as long as you keep the explicit null-termination
> in the next line, the patch still doesn't change anything significant.
>
> The file is maintained by Ishizaki Kou, if he would prefer to take a
> patch replacing the two lines with one, that's fine with me, otherwise
> I just wouldn't bother. You still only gain a few bytes of inittext, but
> that is discarded at boot time.
We prefer to take the patch which is replacing the two lines with one.
- strncpy(celleb_machine_type, ptr, sizeof(celleb_machine_type));
+ strlcpy(celleb_machine_type, ptr, sizeof(celleb_machine_type));
- celleb_machine_type[sizeof(celleb_machine_type)-1] = 0;
Thanks,
Ken Kawakami
^ permalink raw reply
* DMA Engine on MPC8270
From: Felix Radensky @ 2009-07-21 9:20 UTC (permalink / raw)
To: linuxppc-dev
Hi,
Can Freescale DMA engine driver can be used on MPC2870 ?
If not, what driver should I use instead ? The goal to to speed up
transfers to some storage device (M-Systems DoC H3).
Thanks a lot.
Felix.
^ permalink raw reply
* Re: [RFC/PATCH] mm: Pass virtual address to [__]p{te, ud, md}_free_tlb()
From: Nick Piggin @ 2009-07-21 7:05 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Linux-Arch, Linux Memory Management, Hugh Dickins, linux-kernel,
linuxppc-dev
In-Reply-To: <1248134546.30899.27.camel@pasglop>
On Tue, Jul 21, 2009 at 10:02:26AM +1000, Benjamin Herrenschmidt wrote:
> On Mon, 2009-07-20 at 12:38 +0200, Nick Piggin wrote:
> > On Mon, Jul 20, 2009 at 08:00:41PM +1000, Benjamin Herrenschmidt wrote:
> > > On Mon, 2009-07-20 at 10:10 +0200, Nick Piggin wrote:
> > > >
> > > > Maybe I don't understand your description correctly. The TLB contains
> > > > PMDs, but you say the HW still logically performs another translation
> > > > step using entries in the PMD pages? If I understand that correctly,
> > > > then generic mm does not actually care and would logically fit better
> > > > if those entries were "linux ptes".
> > >
> > > They are :-)
> > >
> > > > The pte invalidation routines
> > > > give the virtual address, which you could use to invalidate the TLB.
> > >
> > > For PTEs, yes, but not for those PMD entries. IE. I need the virtual
> > > address when destroying PMDs so that I can invalidate those "indirect"
> > > pages. PTEs are already taken care of by existing mechanisms.
> >
> > Hmm, so even after having invalidated all the pte translations
> > then you still need to invalidate the empty indirect page? (or
> > maybe you don't even invalidate the ptes if they're not cached
> > in a TLB).
>
> The PTEs are cached in the TLB (ie, they turn into normal TLB entries).
>
> We need to invalidate the indirect entries when the PMD value change
> (ie, when the PTE page is freed) or the TLB would potentially continue
> loading PTEs from a stale PTE page :-)
>
> Hence my patch adding the virtual address to pte_free_tlb() which is the
> freeing of a PTE page. I'm adding it to the pmd/pud variants too for
> consistency and because I believe there's no cost.
Yes I think we're on the same page now. So as I said, the
patch is quite OK with me.
^ permalink raw reply
* Re: Simple question about powerpc kernel source.
From: Benjamin Herrenschmidt @ 2009-07-21 0:23 UTC (permalink / raw)
To: HongWoo Lee; +Cc: linuxppc-dev
In-Reply-To: <4A6508AD.6090207@gmail.com>
On Tue, 2009-07-21 at 09:15 +0900, HongWoo Lee wrote:
> First, I aleady understood about @highest, @higher, @h and @l.
> For now, what I want to know is about "##" in the below code.
>
> #define LOADADDR(rn,name) \
> lis rn,name##@highest; \
> ori rn,rn,name##@higher; \
> rldicr rn,rn,32,31; \
> oris rn,rn,name##@h; \
> ori rn,rn,name##@l
>
> And I don't want to ask every detail.
> So I want to know the manual or document which describes the detail.
Well, it's just concatenation...
Ie, if you do LOADADDR(rn, .myfunction) it will turn to
lis rn,.myfunction@highest;
ori rn,rn,.myfunction@higher;
rldicr rn,rn,32,31;
oris rn,rn,.myfunction@h;
ori rn,rn,.myfunction@l
>
Which means putting the address of .myfunction into register rn.
Cheers,
Ben.
^ permalink raw reply
* Re: Simple question about powerpc kernel source.
From: HongWoo Lee @ 2009-07-21 0:15 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev
In-Reply-To: <1248084158.30899.8.camel@pasglop>
[-- Attachment #1: Type: text/plain, Size: 1611 bytes --]
-------- Original Message --------
Subject: Re: Simple question about powerpc kernel source.
From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
To: HongWoo Lee <hongwoo7@gmail.com>
Cc: linuxppc-dev@lists.ozlabs.org
Date: Mon Jul 20 2009 19:02:38 GMT+0900
> On Mon, 2009-07-20 at 18:00 +0900, HongWoo Lee wrote:
>
>> Hi all,
>>
>> I have something to ask for the ppc kernel source.
>>
>> #define LOADADDR(rn,name) \
>> lis rn,name##@highest; \
>> ori rn,rn,name##@higher; \
>> rldicr rn,rn,32,31; \
>> oris rn,rn,name##@h; \
>> ori rn,rn,name##@l
>>
>> Is ## used for concatenation. I'm not sure because it is just meaningless.
>> If so what on earth is the result of concatenating ?
>>
>> And is there a good reference to understand powerpc asm ?
>> I'm reading Power ISA, but I can't find @highest, @higher and ##.
>> It would be good to know the reference book.
>>
>
> You already asked pretty much the same question with the subject "Simple
> question about powerpc asm" and it was already replied to.
>
> Cheers,
> Ben.
>
>
>
Thank you, Ben.
First, I aleady understood about @highest, @higher, @h and @l.
For now, what I want to know is about "##" in the below code.
#define LOADADDR(rn,name) \
lis rn,name##@highest; \
ori rn,rn,name##@higher; \
rldicr rn,rn,32,31; \
oris rn,rn,name##@h; \
ori rn,rn,name##@l
And I don't want to ask every detail.
So I want to know the manual or document which describes the detail.
Regards,
HongWoo.
[-- Attachment #2: Type: text/html, Size: 2319 bytes --]
^ permalink raw reply
* Re: [RFC/PATCH] mm: Pass virtual address to [__]p{te,ud,md}_free_tlb()
From: Benjamin Herrenschmidt @ 2009-07-21 0:02 UTC (permalink / raw)
To: Nick Piggin
Cc: Linux-Arch, Linux Memory Management, Hugh Dickins, linux-kernel,
linuxppc-dev
In-Reply-To: <20090720103835.GB7070@wotan.suse.de>
On Mon, 2009-07-20 at 12:38 +0200, Nick Piggin wrote:
> On Mon, Jul 20, 2009 at 08:00:41PM +1000, Benjamin Herrenschmidt wrote:
> > On Mon, 2009-07-20 at 10:10 +0200, Nick Piggin wrote:
> > >
> > > Maybe I don't understand your description correctly. The TLB contains
> > > PMDs, but you say the HW still logically performs another translation
> > > step using entries in the PMD pages? If I understand that correctly,
> > > then generic mm does not actually care and would logically fit better
> > > if those entries were "linux ptes".
> >
> > They are :-)
> >
> > > The pte invalidation routines
> > > give the virtual address, which you could use to invalidate the TLB.
> >
> > For PTEs, yes, but not for those PMD entries. IE. I need the virtual
> > address when destroying PMDs so that I can invalidate those "indirect"
> > pages. PTEs are already taken care of by existing mechanisms.
>
> Hmm, so even after having invalidated all the pte translations
> then you still need to invalidate the empty indirect page? (or
> maybe you don't even invalidate the ptes if they're not cached
> in a TLB).
The PTEs are cached in the TLB (ie, they turn into normal TLB entries).
We need to invalidate the indirect entries when the PMD value change
(ie, when the PTE page is freed) or the TLB would potentially continue
loading PTEs from a stale PTE page :-)
Hence my patch adding the virtual address to pte_free_tlb() which is the
freeing of a PTE page. I'm adding it to the pmd/pud variants too for
consistency and because I believe there's no cost.
> I believe x86 is also allowed to cache higher level page tables
> in non-cache coherent storage, and I think it just avoids this
> issue by flushing the entire TLB when potentially tearing down
> upper levels. So in theory I think your patch could allow x86 to
> use invlpg more often as well (in practice the flush-all case
> and TLB refills are so fast in comparison with invlpg that it
> probably doesn't gain much especially when talking about
> invalidating upper levels). So making the generic VM more
> flexible like that is no problem for me.
Ah that's good to know. I don't know that much about the x86 way of
doing these things :-)
Cheers,
Ben.
^ permalink raw reply
* [PATCH] powerpc/83xx: Fix PCI IO base address on MPC837xE-RDB boards
From: Anton Vorontsov @ 2009-07-20 21:36 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev
U-Boot maps PCI IO at 0xe0300000, while current dts files specify
0xe2000000. This leads to the following oops with CONFIG_8139TOO_PIO=y.
8139too Fast Ethernet driver 0.9.28
Machine check in kernel mode.
Caused by (from SRR1=41000): Transfer error ack signal
Oops: Machine check, sig: 7 [#1]
MPC837x RDB
[...]
NIP [00000900] 0x900
LR [c0439df8] rtl8139_init_board+0x238/0x524
Call Trace:
[cf831d90] [c0439dcc] rtl8139_init_board+0x20c/0x524 (unreliable)
[cf831de0] [c043a15c] rtl8139_init_one+0x78/0x65c
[cf831e40] [c0235250] pci_call_probe+0x20/0x30
[...]
This patch fixes the issue by specifying the correct PCI IO base
address.
Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
---
arch/powerpc/boot/dts/mpc8377_rdb.dts | 2 +-
arch/powerpc/boot/dts/mpc8378_rdb.dts | 2 +-
arch/powerpc/boot/dts/mpc8379_rdb.dts | 2 +-
3 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/boot/dts/mpc8377_rdb.dts b/arch/powerpc/boot/dts/mpc8377_rdb.dts
index 224b4f0..4f06dbc 100644
--- a/arch/powerpc/boot/dts/mpc8377_rdb.dts
+++ b/arch/powerpc/boot/dts/mpc8377_rdb.dts
@@ -410,7 +410,7 @@
bus-range = <0 0>;
ranges = <0x02000000 0x0 0x90000000 0x90000000 0x0 0x10000000
0x42000000 0x0 0x80000000 0x80000000 0x0 0x10000000
- 0x01000000 0x0 0x00000000 0xe2000000 0x0 0x00100000>;
+ 0x01000000 0x0 0x00000000 0xe0300000 0x0 0x00100000>;
sleep = <&pmc 0x00010000>;
clock-frequency = <66666666>;
#interrupt-cells = <1>;
diff --git a/arch/powerpc/boot/dts/mpc8378_rdb.dts b/arch/powerpc/boot/dts/mpc8378_rdb.dts
index 474ea2f..aabf343 100644
--- a/arch/powerpc/boot/dts/mpc8378_rdb.dts
+++ b/arch/powerpc/boot/dts/mpc8378_rdb.dts
@@ -394,7 +394,7 @@
bus-range = <0 0>;
ranges = <0x02000000 0x0 0x90000000 0x90000000 0x0 0x10000000
0x42000000 0x0 0x80000000 0x80000000 0x0 0x10000000
- 0x01000000 0x0 0x00000000 0xe2000000 0x0 0x00100000>;
+ 0x01000000 0x0 0x00000000 0xe0300000 0x0 0x00100000>;
sleep = <&pmc 0x00010000>;
clock-frequency = <66666666>;
#interrupt-cells = <1>;
diff --git a/arch/powerpc/boot/dts/mpc8379_rdb.dts b/arch/powerpc/boot/dts/mpc8379_rdb.dts
index d4838af..9b1da86 100644
--- a/arch/powerpc/boot/dts/mpc8379_rdb.dts
+++ b/arch/powerpc/boot/dts/mpc8379_rdb.dts
@@ -424,7 +424,7 @@
bus-range = <0x0 0x0>;
ranges = <0x02000000 0x0 0x90000000 0x90000000 0x0 0x10000000
0x42000000 0x0 0x80000000 0x80000000 0x0 0x10000000
- 0x01000000 0x0 0x00000000 0xe2000000 0x0 0x00100000>;
+ 0x01000000 0x0 0x00000000 0xe0300000 0x0 0x00100000>;
sleep = <&pmc 0x00010000>;
clock-frequency = <66666666>;
#interrupt-cells = <1>;
--
1.6.3.3
^ permalink raw reply related
* Re: PPCboot and latest kernel
From: Wolfgang Denk @ 2009-07-20 17:40 UTC (permalink / raw)
To: vijay sharma; +Cc: linuxppc-dev
In-Reply-To: <e571380d0907191136j37d341d7k514f46396a38abc3@mail.gmail.com>
Dear vijay sharma,
In message <e571380d0907191136j37d341d7k514f46396a38abc3@mail.gmail.com> you wrote:
>
> I have been woking on upgrading an embedded system based on MPC8241 from
> 2.4.17 linux to 2.6.30 kernel.
Wow, that's a big leap...
You should also consider to update to the latest version of U-Boot;
the time when it was still called PPCBoot is long, long past.
> I am currently struck one point.
>
> Here is the console output where I am struck:
> =================================
> cpboot> bootm
> ## Booting image at 08000000 ...
> Image Name: Linux-2.6.30
> Image Type: PowerPC Linux Kernel Image (gzip compressed)
> Data Size: 21729342 Bytes = 21220 kB = 20 MB
> Load Address: 01900000
> Entry Point: 01900570
> Verifying Checksum ... OK
> Uncompressing Kernel Image ... OK
> Memory <- <0x0 0x10000000> (256MB)
> CPU clock-frequency <- 0xbebc1fe (200MHz)
> CPU timebase-frequency <- 0x17d783f (25MHz)
> CPU bus-frequency <- 0x5f5e0ff (100MHz)
>
> zImage starting: loaded at 0x01900000 (sp: 0x0fdc3a08)
> Allocating 0x165ca04 bytes for kernel ...
> gunzipping (0x00000000 <- 0x0190c000:0x02f58efc)...done 0x1637b54 bytes
You loaded the image at 01900000, but the uncompr4essed image extends
until 02f58efc, i. e. there is a good chance that you will overwrite
parts of the still uncompressed image.
> Linux/PowerPC load:
> Finalizing device tree... flat tree at 0x2f65300 <== Beyond this point no
> output is available.
Your device tree might be wrong, too.
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
Any sufficiently advanced bug is indistinguishable from a feature.
- Rich Kulawiec
^ 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