* Re: [PATCH 09/15] [POWERPC] Promess Motion-PRO board support
From: Grant Likely @ 2007-10-08 6:45 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: linuxppc-dev, Marian Balakowicz
In-Reply-To: <20071007223219.932e3f8a.sfr@canb.auug.org.au>
On 10/7/07, Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> On Sun, 07 Oct 2007 13:28:48 +0200 Marian Balakowicz <m8@semihalf.com> wrote:
> >
> > +++ b/arch/powerpc/platforms/52xx/motionpro.c
>
> Same comments again.
Ditto.
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195
^ permalink raw reply
* Re: [PATCH 10/15] [POWERPC] Add mpc52xx_find_and_map_path(), refactor utility functions.
From: Grant Likely @ 2007-10-08 6:47 UTC (permalink / raw)
To: Marian Balakowicz; +Cc: linuxppc-dev
In-Reply-To: <4708C343.30104@semihalf.com>
On 10/7/07, Marian Balakowicz <m8@semihalf.com> wrote:
>
> Add helper routine mpc52xx_find_and_map_path(). Extract common code to
> mpc52xx_map_node() and refactor mpc52xx_find_and_map().
>
> Signed-off-by: Jan Wrobel <wrr@semihalf.com>
Looks good to me.
Reviewed-by: Grant Likely <grant.likely@secretlab.ca>
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195
^ permalink raw reply
* howto hibernate (suspend-to-disk) G4 PowerBook Titanium IV
From: Lixus Zoran @ 2007-10-08 7:08 UTC (permalink / raw)
To: Linuxppc-dev
Hello,
I own a Titanium PowerBook with a G4 processor.
It runs Ubuntu dapper 6.06 LTS.
Suspend to RAM works fine with pbbuttonsd.
But I would like to have hibernate (suspend-to-disk) working.
But if I replace "suspend-to-ram" by "suspend-to-disk" in
/etc/pbbuttonsd.conf and close the lid then it just blanks the screen,
even if X is not running.
I found a lot of approaches howto possible hibernate,
a) swsuspend http://suspend.sf.net
b) Suspend2 (this only works on i368 ?)
c) pbbuttonsd ?
d) uswsusp
e) pmdisk
but where should I put my effords in ?
TIA, Lixus
# cat /proc/cpuinfo
processor : 0
cpu : 7455, altivec supported
clock : 667.000000MHz
revision : 0.2 (pvr 8001 0302)
bogomips : 66.56
timebase : 33331380
machine : PowerBook3,5
motherboard : PowerBook3,5 MacRISC2 MacRISC Power Macintosh
detected as : 80 (PowerBook Titanium IV)
pmac flags : 0000001b
L2 cache : 256K unified
pmac-generation : NewWorld
^ permalink raw reply
* Re: [PATCH 11/15] [POWERPC] Motion-PRO: Add LED support.
From: Grant Likely @ 2007-10-08 7:10 UTC (permalink / raw)
To: Marian Balakowicz; +Cc: linuxppc-dev
In-Reply-To: <4708C380.3070707@semihalf.com>
On 10/7/07, Marian Balakowicz <m8@semihalf.com> wrote:
>
> Add LED driver for Promess Motion-PRO board.
>
> Signed-off-by: Jan Wrobel <wrr@semihalf.com>
> ---
>
> arch/powerpc/configs/motionpro_defconfig | 3
> arch/powerpc/platforms/52xx/motionpro.c | 38 +++++
> drivers/leds/Kconfig | 7
> drivers/leds/Makefile | 1
> drivers/leds/leds-motionpro.c | 221 +++++++++++++++++++++++++++++++
> include/asm-powerpc/mpc52xx.h | 5
> 6 files changed, 274 insertions(+), 1 deletion(-)
>
> diff --git a/arch/powerpc/configs/motionpro_defconfig b/arch/powerpc/configs/motionpro_defconfig
> index fcce47e..ce62123 100644
> --- a/arch/powerpc/configs/motionpro_defconfig
> +++ b/arch/powerpc/configs/motionpro_defconfig
> @@ -1,7 +1,7 @@
> #
> # Automatically generated make config: don't edit
> # Linux kernel version: 2.6.23-rc9
> -# Fri Oct 5 12:54:17 2007
> +# Fri Oct 5 15:18:42 2007
> #
> # CONFIG_PPC64 is not set
>
> @@ -610,6 +610,7 @@ CONFIG_LEDS_CLASS=y
> #
> # LED drivers
> #
> +CONFIG_LEDS_MOTIONPRO=y
>
> #
> # LED Triggers
> diff --git a/arch/powerpc/platforms/52xx/motionpro.c b/arch/powerpc/platforms/52xx/motionpro.c
> index 2cf8a47..c1bcfd2 100644
> --- a/arch/powerpc/platforms/52xx/motionpro.c
> +++ b/arch/powerpc/platforms/52xx/motionpro.c
> @@ -86,10 +86,48 @@ error:
> iounmap(gpio);
> }
>
> +
> +#ifdef CONFIG_LEDS_MOTIONPRO
> +
> +/* Initialize GPT register connected to LED. Turn off LED. */
> +static void motionpro_setup_led(const char *reg_path)
> +{
> + void __iomem *reg_addr;
> + u32 reg;
> +
> + reg_addr = mpc52xx_find_and_map_path(reg_path);
> + if (!reg_addr){
> + printk(KERN_ERR __FILE__ ": "
> + "LED setup error: can't map GPIO register %s\n",
> + reg_path);
> + return;
> + }
> +
> + reg = in_be32(reg_addr);
> + reg |= MPC52xx_GPT_ENABLE_OUTPUT;
> + reg &= ~MPC52xx_GPT_OUTPUT_1;
> + out_be32(reg_addr, reg);
Ideally, firmware should be doing this setup. Only do it here if
firmware cannot be updated to set these pins correctly.
> +
> + iounmap(reg_addr);
> +}
> +
> +/* Initialize Motionpro status and ready LEDs */
> +static void motionpro_setup_leds(void)
> +{
> + motionpro_setup_led("/soc5200@f0000000/gpt@660");
> + motionpro_setup_led("/soc5200@f0000000/gpt@670");
> +}
> +
> +#endif
> +
> static void __init motionpro_setup_arch(void)
> {
> struct device_node *np;
>
> +#ifdef CONFIG_LEDS_MOTIONPRO
> + motionpro_setup_leds();
> +#endif
Don't bother making this conditional (Unless the LED GPIO pins can
also have another function). This is a fixed property of the board,
so just set it up unconditionally.
> +
> if (ppc_md.progress)
> ppc_md.progress("motionpro_setup_arch()", 0);
>
> diff --git a/drivers/leds/Kconfig b/drivers/leds/Kconfig
> index 4468cb3..f027009 100644
> --- a/drivers/leds/Kconfig
> +++ b/drivers/leds/Kconfig
> @@ -55,6 +55,13 @@ config LEDS_TOSA
> This option enables support for the LEDs on Sharp Zaurus
> SL-6000 series.
>
> +config LEDS_MOTIONPRO
> + tristate "Motionpro LEDs Support"
> + depends on LEDS_CLASS
> + help
> + This option enables support for status and ready LEDs connected
> + to GPIO lines on Motionpro board.
> +
> config LEDS_S3C24XX
> tristate "LED Support for Samsung S3C24XX GPIO LEDs"
> depends on LEDS_CLASS && ARCH_S3C2410
> diff --git a/drivers/leds/Makefile b/drivers/leds/Makefile
> index f8995c9..6b45be1 100644
> --- a/drivers/leds/Makefile
> +++ b/drivers/leds/Makefile
> @@ -16,6 +16,7 @@ obj-$(CONFIG_LEDS_NET48XX) += leds-net48xx.o
> obj-$(CONFIG_LEDS_WRAP) += leds-wrap.o
> obj-$(CONFIG_LEDS_H1940) += leds-h1940.o
> obj-$(CONFIG_LEDS_COBALT) += leds-cobalt.o
> +obj-$(CONFIG_LEDS_MOTIONPRO) += leds-motionpro.o
> obj-$(CONFIG_LEDS_GPIO) += leds-gpio.o
>
> # LED Triggers
> diff --git a/drivers/leds/leds-motionpro.c b/drivers/leds/leds-motionpro.c
> new file mode 100644
> index 0000000..273e375
> --- /dev/null
> +++ b/drivers/leds/leds-motionpro.c
> @@ -0,0 +1,221 @@
> +/*
> + * LEDs driver for the Motionpro board.
> + *
> + * Copyright (C) 2007 Semihalf
> + *
> + * Author: Jan Wrobel <wrr@semihalf.com>
> + *
> + * This program is free software; you can redistribute it and/or modify it
> + * under the terms of the GNU General Public License version 2 as published by
> + * the Free Software Foundation.
> + *
> + * This program is distributed in the hope that it will be useful, but WITHOUT
> + * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
> + * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
> + * more details.
> + *
> + * You should have received a copy of the GNU General Public License along
> + * with this program; if not, write to the Free Software Foundation, Inc., 51
> + * Franklin St, Fifth Floor, Boston, MA 02110-1301 USA
> + *
> + *
> + * This driver enables control over Motionpro's status and ready LEDs through
> + * sysfs. LEDs can be controlled by writing to sysfs files:
> + * class/leds/motionpro-(ready|status)led/(brightness|delay_off|delay_on).
> + * See Documentation/leds-class.txt for more details
> + *
> + * Before user issues first control command via sysfs, LED blinking is
> + * controlled by the kernel. By default status LED is blinking fast and ready
> + * LED is turned off.
> + */
> +
> +#include <linux/module.h>
> +#include <linux/types.h>
> +#include <linux/kernel.h>
> +#include <linux/device.h>
> +#include <linux/leds.h>
> +
> +#include <asm/mpc52xx.h>
> +#include <asm/io.h>
> +
> +/* Led status */
> +#define LED_NOT_REGISTERED 0
> +#define LED_KERNEL_CONTROLLED 1
> +#define LED_USER_CONTROLLED 2
> +
> +
> +/* Led control bits */
> +#define LED_ON MPC52xx_GPT_OUTPUT_1
> +
> +static void mpled_set(struct led_classdev *led_cdev,
> + enum led_brightness brightness);
> +
> +static struct motionpro_led{
> + /* Protects the led data */
> + spinlock_t led_lock;
> +
> + /* Path to led's control register DTS node */
> + char *reg_path;
> +
> + /* Address to access led's register */
> + void __iomem *reg_addr;
> +
> + int status;
> +
> + /* Blinking timer used when led is controlled by the kernel */
> + struct timer_list kernel_mode_timer;
> +
> + /*
> + * Delay between blinks when led is controlled by the kernel.
> + * If set to 0 led blinking is off.
> + */
> + int kernel_mode_delay;
> +
> + struct led_classdev classdev;
> +}led[] = {
Split the structure definition and the table declaration. Easier to
follow if it is split.
> + {
> + .reg_path = "/soc5200@f0000000/gpt@660",
> + .reg_addr = 0,
> + .led_lock = SPIN_LOCK_UNLOCKED,
> + .status = LED_NOT_REGISTERED,
> + .kernel_mode_delay = HZ / 10,
> + .classdev = {
> + .name = "motionpro-statusled",
> + .brightness_set = mpled_set,
> + .default_trigger = "timer",
> + },
> + },
> + {
> + .reg_path = "/soc5200@f0000000/gpt@670",
> + .reg_addr = 0,
> + .led_lock = SPIN_LOCK_UNLOCKED,
> + .status = LED_NOT_REGISTERED,
> + .kernel_mode_delay = 0,
> + .classdev = {
> + .name = "motionpro-readyled",
> + .brightness_set = mpled_set,
> + .default_trigger = "timer",
> + }
> + }
> +};
> +
> +/* Timer event - blinks led before user takes control over it */
> +static void mpled_timer_toggle(unsigned long ptr)
> +{
> + struct motionpro_led *mled = (struct motionpro_led *) ptr;
> +
> + spin_lock_bh(&mled->led_lock);
> + if (mled->status == LED_KERNEL_CONTROLLED){
> + u32 reg = in_be32(mled->reg_addr);
> + reg ^= LED_ON;
> + out_be32(mled->reg_addr, reg);
> + led->kernel_mode_timer.expires = jiffies +
> + led->kernel_mode_delay;
> + add_timer(&led->kernel_mode_timer);
> + }
> + spin_unlock_bh(&mled->led_lock);
> +}
> +
> +
> +/*
> + * Turn on/off led according to user settings in sysfs.
> + * First call to this function disables kernel blinking.
> + */
> +static void mpled_set(struct led_classdev *led_cdev,
> + enum led_brightness brightness)
> +{
> + struct motionpro_led *mled;
> + u32 reg;
> +
> + mled = container_of(led_cdev, struct motionpro_led, classdev);
> +
> + spin_lock_bh(&mled->led_lock);
> + mled->status = LED_USER_CONTROLLED;
> +
> + reg = in_be32(mled->reg_addr);
> + if (brightness)
> + reg |= LED_ON;
> + else
> + reg &= ~LED_ON;
> + out_be32(mled->reg_addr, reg);
> +
> + spin_unlock_bh(&mled->led_lock);
> +}
> +
> +static void mpled_init_led(void __iomem *reg_addr)
> +{
> + u32 reg = in_be32(reg_addr);
> + reg |= MPC52xx_GPT_ENABLE_OUTPUT;
> + reg &= ~LED_ON;
> + out_be32(reg_addr, reg);
> +}
> +
> +static void mpled_clean(void)
> +{
> + int i;
> + for (i = 0; i < sizeof(led) / sizeof(struct motionpro_led); i++){
> + if (led[i].status != LED_NOT_REGISTERED){
> + spin_lock_bh(&led[i].led_lock);
> + led[i].status = LED_NOT_REGISTERED;
> + spin_unlock_bh(&led[i].led_lock);
> + led_classdev_unregister(&led[i].classdev);
> + }
> + if (led[i].reg_addr){
> + iounmap(led[i].reg_addr);
> + led[i].reg_addr = 0;
> + }
> + }
> +}
> +
> +static int __init mpled_init(void)
> +{
> + int i, error;
> +
> + for (i = 0; i < sizeof(led) / sizeof(struct motionpro_led); i++){
> + led[i].reg_addr = mpc52xx_find_and_map_path(led[i].reg_path);
> + if (!led[i].reg_addr){
> + printk(KERN_ERR __FILE__ ": "
> + "Error while mapping GPIO register for LED %s\n",
> + led[i].classdev.name);
> + error = -EIO;
> + goto err;
> + }
> +
> + mpled_init_led(led[i].reg_addr);
> + led[i].status = LED_KERNEL_CONTROLLED;
> + if (led[i].kernel_mode_delay){
> + init_timer(&led[i].kernel_mode_timer);
> + led[i].kernel_mode_timer.function = mpled_timer_toggle;
> + led[i].kernel_mode_timer.data = (unsigned long)&led[i];
> + led[i].kernel_mode_timer.expires =
> + jiffies + led[i].kernel_mode_delay;
> + add_timer(&led[i].kernel_mode_timer);
> + }
> +
> + if ((error = led_classdev_register(NULL, &led[i].classdev)) < 0){
> + printk(KERN_ERR __FILE__ ": "
> + "Error while registering class device for LED "
> + "%s\n",
> + led[i].classdev.name);
> + goto err;
> + }
> + }
> +
> + printk("Motionpro LEDs driver initialized\n");
> + return 0;
> +err:
> + mpled_clean();
> + return error;
> +}
What happens when a kernel is built with support for this board and
another platform? It looks like this init code tries to setup the
LEDs unconditionally.
You might be better off renaming the gpt nodes as 'led' nodes and
writing a driver which matches something like 'promess,mp-gpt-led' in
the compatible property. That way your driver setup code only gets
called with there is a match in the device tree.
It also makes your setup code simpler. You don't need to hardcode the
path to the gpt node. You just need to search for matching
'compatible' nodes. In this case, setting the gpt device into output
mode is probably simpler as part of the led driver initialization
(again, assuming that firware hasn't set it up correctly first).
Cheers,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195
^ permalink raw reply
* Re: [PATCH 12/15] [POWERPC] Add mpc52xx_restart(), mpc52xx_halt(), mpc52xx_power_off().
From: Grant Likely @ 2007-10-08 7:15 UTC (permalink / raw)
To: Marian Balakowicz; +Cc: linuxppc-dev
In-Reply-To: <4708C3B2.1050103@semihalf.com>
On 10/7/07, Marian Balakowicz <m8@semihalf.com> wrote:
>
> Add common MPC5200 helper routines: mpc52xx_restart(), mpc52xx_halt(),
> mpc52xx_power_off().
>
> This patch relies on Sascha Hauer's patch published in:
> http://patchwork.ozlabs.org/linuxppc/patch?id=8910.
>
> Signed-off-by: Marian Balakowicz <m8@semihalf.com>
> Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
> ---
>
> arch/powerpc/platforms/52xx/mpc52xx_common.c | 45 +++++++++++++++++++++++++++
> include/asm-powerpc/mpc52xx.h | 7 ++++
> 2 files changed, 52 insertions(+)
>
> diff --git a/arch/powerpc/platforms/52xx/mpc52xx_common.c b/arch/powerpc/platforms/52xx/mpc52xx_common.c
> index b1cd7b0..e7087d7 100644
> --- a/arch/powerpc/platforms/52xx/mpc52xx_common.c
> +++ b/arch/powerpc/platforms/52xx/mpc52xx_common.c
> @@ -88,6 +88,14 @@ mpc52xx_find_ipb_freq(struct device_node *node)
> }
> EXPORT_SYMBOL(mpc52xx_find_ipb_freq);
>
> +/*
> + * This variable is mapped in mpc52xx_setup_cpu() by a call to
> + * mpc52xx_find_and_map(), and used in mpc52xx_restart(). This is because
> + * mpc52xx_restart() can be called from interrupt context (e.g., watchdog
> + * interrupt handler), and mpc52xx_find_and_map() (ioremap() to be exact)
> + * can't be called from interrupt context.
> + */
> +volatile struct mpc52xx_gpt *mpc52xx_gpt0 = NULL;
>
> void __init
> mpc52xx_setup_cpu(void)
> @@ -95,6 +103,9 @@ mpc52xx_setup_cpu(void)
> struct mpc52xx_cdm __iomem *cdm;
> struct mpc52xx_xlb __iomem *xlb;
>
> + /* mpc52xx_gpt0 is mapped here and used in mpc52xx_restart */
> + mpc52xx_gpt0 = mpc52xx_find_and_map("mpc5200-gpt");
> +
> /* Map zones */
> cdm = mpc52xx_find_and_map("mpc5200-cdm");
> xlb = mpc52xx_find_and_map("mpc5200-xlb");
> @@ -138,3 +149,37 @@ mpc52xx_declare_of_platform_devices(void)
> "Error while probing of_platform bus\n");
> }
>
> +void
> +mpc52xx_restart(char *cmd)
> +{
> + local_irq_disable();
> +
> + /* Turn on the watchdog and wait for it to expire. It effectively
> + does a reset */
> + if (mpc52xx_gpt0) {
> + out_be32(&mpc52xx_gpt0->mode, 0x00000000);
> + out_be32(&mpc52xx_gpt0->count, 0x000000ff);
> + out_be32(&mpc52xx_gpt0->mode, 0x00009004);
> + } else
> + printk("mpc52xx_restart: Can't access gpt. "
> + "Restart impossible, system halted\n");
> +
> + while (1);
> +}
> +
> +void
> +mpc52xx_halt(void)
> +{
> + local_irq_disable();
> +
> + while (1);
> +}
> +
> +void
> +mpc52xx_power_off(void)
> +{
> + /* By default we don't have any way of shut down.
> + If a specific board wants to, it can set the power down
> + code to any hardware implementation dependent code */
> + mpc52xx_halt();
> +}
> diff --git a/include/asm-powerpc/mpc52xx.h b/include/asm-powerpc/mpc52xx.h
> index a431798..8dfb4de 100644
> --- a/include/asm-powerpc/mpc52xx.h
> +++ b/include/asm-powerpc/mpc52xx.h
> @@ -104,6 +104,9 @@ struct mpc52xx_gpt {
> u32 status; /* GPTx + 0X0c */
> };
>
> +/* Static instance of GPT0 */
> +extern volatile struct mpc52xx_gpt *mpc52xx_gpt0;
> +
No; don't make this a global symbol. Restrict it to the
mpc52xx_common file. Use a helper function if you need to too set the
value.
> /* GPIO */
> struct mpc52xx_gpio {
> u32 port_config; /* GPIO + 0x00 */
> @@ -257,6 +260,10 @@ extern unsigned int mpc52xx_get_irq(void);
>
> extern int __init mpc52xx_add_bridge(struct device_node *node);
>
> +extern void mpc52xx_restart(char *cmd);
> +extern void mpc52xx_halt(void);
> +extern void mpc52xx_power_off(void);
> +
> #endif /* __ASSEMBLY__ */
>
> #ifdef CONFIG_PM
>
>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
>
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195
^ permalink raw reply
* Re: [PATCH 00/15] [POWERPC] TQM5200, CM5200 and Motion-PRO support
From: Grant Likely @ 2007-10-08 7:16 UTC (permalink / raw)
To: Marian Balakowicz; +Cc: linuxppc-dev
In-Reply-To: <47075FA7.3030108@semihalf.com>
On 10/6/07, Marian Balakowicz <m8@semihalf.com> wrote:
> Hello,
>
> The following series of patches adds arch/powerpc support for three MPC5200 based boards:
> TQM5200, CM5200 and Motion-PRO.
Thanks for the patch series.
g.
>
> Included are also patches with modifications to common 52xx code. New helper
> routine mpc52xx_find_and_map_path() is added, and is being used in LED driver
> for Motion-PRO. Another patch adds mpc52xx_restart(), mpc52xx_halt()
> and mpc52xx_power_off(). This modification has been around for some time now
> and relies on Sascha Hauer's patch.
>
> 01/15 [POWERPC] TQM5200 DTS
> 02/15 [POWERPC] TQM5200 defconfig
> 03/15 [POWERPC] TQM5200 board support
> 04/15 [POWERPC] cm5200 DTS
> 05/15 [POWERPC] cm5200 defconfig
> 06/15 [POWERPC] cm5200 board support
> 07/15 [POWERPC] Promess motionpro DTS
> 08/15 [POWERPC] Promess motionpro defconfig
> 09/15 [POWERPC] Promess motionpro board support
> 10/15 [POWERPC] Add mpc52xx_find_and_map_path(), refactor utility functions.
> 11/15 [POWERPC] Motion-PRO: Add LED support.
> 12/15 [POWERPC] Add mpc52xx_restart(), mpc52xx_halt(), mpc52xx_power_off().
> 13/15 [POWERPC] Init restart/halt/power_off machine hooks for tqm5200.
> 14/15 [POWERPC] Init restart/halt/power_off machine hooks for cm5200.
> 15/15 [POWERPC] Init restart/halt/power_off machine hooks for motionpro.
>
> Comments and review notes are welcome.
>
> Cheers,
> Marian Balakowicz
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
>
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195
^ permalink raw reply
* [PATCH] Lite5200: Use comma delimiter format for lists in device tree
From: Grant Likely @ 2007-10-08 7:24 UTC (permalink / raw)
To: galak, linuxppc-dev
From: Grant Likely <grant.likely@secretlab.ca>
DTC now supports "foo","bar" format for lists of strings; use the new
format on the lite5200 device trees.
Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
---
arch/powerpc/boot/dts/lite5200.dts | 10 +++---
arch/powerpc/boot/dts/lite5200b.dts | 62 ++++++++++++++++++-----------------
2 files changed, 36 insertions(+), 36 deletions(-)
diff --git a/arch/powerpc/boot/dts/lite5200.dts b/arch/powerpc/boot/dts/lite5200.dts
index 324e1bd..bc45f5f 100644
--- a/arch/powerpc/boot/dts/lite5200.dts
+++ b/arch/powerpc/boot/dts/lite5200.dts
@@ -19,7 +19,7 @@
/ {
model = "fsl,lite5200";
// revision = "1.0";
- compatible = "fsl,lite5200\0generic-mpc5200";
+ compatible = "fsl,lite5200","generic-mpc5200";
#address-cells = <1>;
#size-cells = <1>;
@@ -192,7 +192,7 @@
usb@1000 {
device_type = "usb-ohci-be";
- compatible = "mpc5200-ohci\0ohci-be";
+ compatible = "mpc5200-ohci","ohci-be";
reg = <1000 ff>;
interrupts = <2 6 0>;
interrupt-parent = <&mpc5200_pic>;
@@ -293,7 +293,7 @@
i2c@3d00 {
device_type = "i2c";
- compatible = "mpc5200-i2c\0fsl-i2c";
+ compatible = "mpc5200-i2c","fsl-i2c";
cell-index = <0>;
reg = <3d00 40>;
interrupts = <2 f 0>;
@@ -303,7 +303,7 @@
i2c@3d40 {
device_type = "i2c";
- compatible = "mpc5200-i2c\0fsl-i2c";
+ compatible = "mpc5200-i2c","fsl-i2c";
cell-index = <1>;
reg = <3d40 40>;
interrupts = <2 10 0>;
@@ -312,7 +312,7 @@
};
sram@8000 {
device_type = "sram";
- compatible = "mpc5200-sram\0sram";
+ compatible = "mpc5200-sram","sram";
reg = <8000 4000>;
};
};
diff --git a/arch/powerpc/boot/dts/lite5200b.dts b/arch/powerpc/boot/dts/lite5200b.dts
index 3f74f73..a6bb1d0 100644
--- a/arch/powerpc/boot/dts/lite5200b.dts
+++ b/arch/powerpc/boot/dts/lite5200b.dts
@@ -19,7 +19,7 @@
/ {
model = "fsl,lite5200b";
// revision = "1.0";
- compatible = "fsl,lite5200b\0generic-mpc5200";
+ compatible = "fsl,lite5200b","generic-mpc5200";
#address-cells = <1>;
#size-cells = <1>;
@@ -56,7 +56,7 @@
system-frequency = <0>; // from bootloader
cdm@200 {
- compatible = "mpc5200b-cdm\0mpc5200-cdm";
+ compatible = "mpc5200b-cdm","mpc5200-cdm";
reg = <200 38>;
};
@@ -65,12 +65,12 @@
interrupt-controller;
#interrupt-cells = <3>;
device_type = "interrupt-controller";
- compatible = "mpc5200b-pic\0mpc5200-pic";
+ compatible = "mpc5200b-pic","mpc5200-pic";
reg = <500 80>;
};
gpt@600 { // General Purpose Timer
- compatible = "mpc5200b-gpt\0mpc5200-gpt";
+ compatible = "mpc5200b-gpt","mpc5200-gpt";
device_type = "gpt";
cell-index = <0>;
reg = <600 10>;
@@ -80,7 +80,7 @@
};
gpt@610 { // General Purpose Timer
- compatible = "mpc5200b-gpt\0mpc5200-gpt";
+ compatible = "mpc5200b-gpt","mpc5200-gpt";
device_type = "gpt";
cell-index = <1>;
reg = <610 10>;
@@ -89,7 +89,7 @@
};
gpt@620 { // General Purpose Timer
- compatible = "mpc5200b-gpt\0mpc5200-gpt";
+ compatible = "mpc5200b-gpt","mpc5200-gpt";
device_type = "gpt";
cell-index = <2>;
reg = <620 10>;
@@ -98,7 +98,7 @@
};
gpt@630 { // General Purpose Timer
- compatible = "mpc5200b-gpt\0mpc5200-gpt";
+ compatible = "mpc5200b-gpt","mpc5200-gpt";
device_type = "gpt";
cell-index = <3>;
reg = <630 10>;
@@ -107,7 +107,7 @@
};
gpt@640 { // General Purpose Timer
- compatible = "mpc5200b-gpt\0mpc5200-gpt";
+ compatible = "mpc5200b-gpt","mpc5200-gpt";
device_type = "gpt";
cell-index = <4>;
reg = <640 10>;
@@ -116,7 +116,7 @@
};
gpt@650 { // General Purpose Timer
- compatible = "mpc5200b-gpt\0mpc5200-gpt";
+ compatible = "mpc5200b-gpt","mpc5200-gpt";
device_type = "gpt";
cell-index = <5>;
reg = <650 10>;
@@ -125,7 +125,7 @@
};
gpt@660 { // General Purpose Timer
- compatible = "mpc5200b-gpt\0mpc5200-gpt";
+ compatible = "mpc5200b-gpt","mpc5200-gpt";
device_type = "gpt";
cell-index = <6>;
reg = <660 10>;
@@ -134,7 +134,7 @@
};
gpt@670 { // General Purpose Timer
- compatible = "mpc5200b-gpt\0mpc5200-gpt";
+ compatible = "mpc5200b-gpt","mpc5200-gpt";
device_type = "gpt";
cell-index = <7>;
reg = <670 10>;
@@ -143,7 +143,7 @@
};
rtc@800 { // Real time clock
- compatible = "mpc5200b-rtc\0mpc5200-rtc";
+ compatible = "mpc5200b-rtc","mpc5200-rtc";
device_type = "rtc";
reg = <800 100>;
interrupts = <1 5 0 1 6 0>;
@@ -152,7 +152,7 @@
mscan@900 {
device_type = "mscan";
- compatible = "mpc5200b-mscan\0mpc5200-mscan";
+ compatible = "mpc5200b-mscan","mpc5200-mscan";
cell-index = <0>;
interrupts = <2 11 0>;
interrupt-parent = <&mpc5200_pic>;
@@ -161,7 +161,7 @@
mscan@980 {
device_type = "mscan";
- compatible = "mpc5200b-mscan\0mpc5200-mscan";
+ compatible = "mpc5200b-mscan","mpc5200-mscan";
cell-index = <1>;
interrupts = <2 12 0>;
interrupt-parent = <&mpc5200_pic>;
@@ -169,14 +169,14 @@
};
gpio@b00 {
- compatible = "mpc5200b-gpio\0mpc5200-gpio";
+ compatible = "mpc5200b-gpio","mpc5200-gpio";
reg = <b00 40>;
interrupts = <1 7 0>;
interrupt-parent = <&mpc5200_pic>;
};
gpio-wkup@c00 {
- compatible = "mpc5200b-gpio-wkup\0mpc5200-gpio-wkup";
+ compatible = "mpc5200b-gpio-wkup","mpc5200-gpio-wkup";
reg = <c00 40>;
interrupts = <1 8 0 0 3 0>;
interrupt-parent = <&mpc5200_pic>;
@@ -184,7 +184,7 @@
spi@f00 {
device_type = "spi";
- compatible = "mpc5200b-spi\0mpc5200-spi";
+ compatible = "mpc5200b-spi","mpc5200-spi";
reg = <f00 20>;
interrupts = <2 d 0 2 e 0>;
interrupt-parent = <&mpc5200_pic>;
@@ -192,7 +192,7 @@
usb@1000 {
device_type = "usb-ohci-be";
- compatible = "mpc5200b-ohci\0mpc5200-ohci\0ohci-be";
+ compatible = "mpc5200b-ohci","mpc5200-ohci","ohci-be";
reg = <1000 ff>;
interrupts = <2 6 0>;
interrupt-parent = <&mpc5200_pic>;
@@ -200,7 +200,7 @@
bestcomm@1200 {
device_type = "dma-controller";
- compatible = "mpc5200b-bestcomm\0mpc5200-bestcomm";
+ compatible = "mpc5200b-bestcomm","mpc5200-bestcomm";
reg = <1200 80>;
interrupts = <3 0 0 3 1 0 3 2 0 3 3 0
3 4 0 3 5 0 3 6 0 3 7 0
@@ -210,13 +210,13 @@
};
xlb@1f00 {
- compatible = "mpc5200b-xlb\0mpc5200-xlb";
+ compatible = "mpc5200b-xlb","mpc5200-xlb";
reg = <1f00 100>;
};
serial@2000 { // PSC1
device_type = "serial";
- compatible = "mpc5200b-psc-uart\0mpc5200-psc-uart";
+ compatible = "mpc5200b-psc-uart","mpc5200-psc-uart";
port-number = <0>; // Logical port assignment
cell-index = <0>;
reg = <2000 100>;
@@ -227,7 +227,7 @@
// PSC2 in ac97 mode example
//ac97@2200 { // PSC2
// device_type = "sound";
- // compatible = "mpc5200b-psc-ac97\0mpc5200-psc-ac97";
+ // compatible = "mpc5200b-psc-ac97","mpc5200-psc-ac97";
// cell-index = <1>;
// reg = <2200 100>;
// interrupts = <2 2 0>;
@@ -247,7 +247,7 @@
// PSC4 in uart mode example
//serial@2600 { // PSC4
// device_type = "serial";
- // compatible = "mpc5200b-psc-uart\0mpc5200-psc-uart";
+ // compatible = "mpc5200b-psc-uart","mpc5200-psc-uart";
// cell-index = <3>;
// reg = <2600 100>;
// interrupts = <2 b 0>;
@@ -257,7 +257,7 @@
// PSC5 in uart mode example
//serial@2800 { // PSC5
// device_type = "serial";
- // compatible = "mpc5200b-psc-uart\0mpc5200-psc-uart";
+ // compatible = "mpc5200b-psc-uart","mpc5200-psc-uart";
// cell-index = <4>;
// reg = <2800 100>;
// interrupts = <2 c 0>;
@@ -267,7 +267,7 @@
// PSC6 in spi mode example
//spi@2c00 { // PSC6
// device_type = "spi";
- // compatible = "mpc5200b-psc-spi\0mpc5200-psc-spi";
+ // compatible = "mpc5200b-psc-spi","mpc5200-psc-spi";
// cell-index = <5>;
// reg = <2c00 100>;
// interrupts = <2 4 0>;
@@ -276,7 +276,7 @@
ethernet@3000 {
device_type = "network";
- compatible = "mpc5200b-fec\0mpc5200-fec";
+ compatible = "mpc5200b-fec","mpc5200-fec";
reg = <3000 800>;
mac-address = [ 02 03 04 05 06 07 ]; // Bad!
interrupts = <2 5 0>;
@@ -285,7 +285,7 @@
ata@3a00 {
device_type = "ata";
- compatible = "mpc5200b-ata\0mpc5200-ata";
+ compatible = "mpc5200b-ata","mpc5200-ata";
reg = <3a00 100>;
interrupts = <2 7 0>;
interrupt-parent = <&mpc5200_pic>;
@@ -293,7 +293,7 @@
i2c@3d00 {
device_type = "i2c";
- compatible = "mpc5200b-i2c\0mpc5200-i2c\0fsl-i2c";
+ compatible = "mpc5200b-i2c","mpc5200-i2c","fsl-i2c";
cell-index = <0>;
reg = <3d00 40>;
interrupts = <2 f 0>;
@@ -303,7 +303,7 @@
i2c@3d40 {
device_type = "i2c";
- compatible = "mpc5200b-i2c\0mpc5200-i2c\0fsl-i2c";
+ compatible = "mpc5200b-i2c","mpc5200-i2c","fsl-i2c";
cell-index = <1>;
reg = <3d40 40>;
interrupts = <2 10 0>;
@@ -312,7 +312,7 @@
};
sram@8000 {
device_type = "sram";
- compatible = "mpc5200b-sram\0mpc5200-sram\0sram";
+ compatible = "mpc5200b-sram","mpc5200-sram","sram";
reg = <8000 4000>;
};
};
@@ -322,7 +322,7 @@
#size-cells = <2>;
#address-cells = <3>;
device_type = "pci";
- compatible = "mpc5200b-pci\0mpc5200-pci";
+ compatible = "mpc5200b-pci","mpc5200-pci";
reg = <f0000d00 100>;
interrupt-map-mask = <f800 0 0 7>;
interrupt-map = <c000 0 0 1 &mpc5200_pic 0 0 3 // 1st slot
^ permalink raw reply related
* Re: [POWERPC 03/15] [POWERPC] TQM5200 board support
From: Wolfgang Denk @ 2007-10-08 7:44 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-dev, tech-denx, Detlev Zundel, Marian Balakowicz
In-Reply-To: <fa686aa40710072321g3494b243w341e2b09117c3695@mail.gmail.com>
In message <fa686aa40710072321g3494b243w341e2b09117c3695@mail.gmail.com> you wrote:
>
> > + port_config &= ~0x03000000; /* ATA CS is on csb_4/5 */
> > + port_config |= 0x01000000;
>
> Are you *sure* you want this? You should only be touching port_config
> if firmware fails to set it up correctly. Don't blindly copy what was
> done for the lite5200.
>
> Lite5200 touches it because firmware does *not* do the right thing at
> the moment.
Why don't we fix it in U-Boot, then, and get rid of this in Linux?
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
The average woman would rather have beauty than brains, because the
average man can see better than he can think.
^ permalink raw reply
* [PATCH] Device tree bindings for Xilinx devices
From: Grant Likely @ 2007-10-08 7:53 UTC (permalink / raw)
To: linuxppc-dev
From: Grant Likely <grant.likely@secretlab.ca>
Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
---
This is a first draft, please review and comment.
On a side node, I think booting-without-of.txt could get really unwieldly
in the near future. Perhaps the device tree bindings should be organized
differently and separated from the functional description of device tree
usage. Thoughts?
Cheers,
g.
Documentation/powerpc/booting-without-of.txt | 58 ++++++++++++++++++++++++++
1 files changed, 58 insertions(+), 0 deletions(-)
diff --git a/Documentation/powerpc/booting-without-of.txt b/Documentation/powerpc/booting-without-of.txt
index 20e0e6c..a6d6056 100644
--- a/Documentation/powerpc/booting-without-of.txt
+++ b/Documentation/powerpc/booting-without-of.txt
@@ -1850,6 +1850,64 @@ platforms are moved over to use the flattened-device-tree model.
More devices will be defined as this spec matures.
+ l) Xilinx ML300 Framebuffer
+
+ Simple framebuffer device from the ML300 reference design (also on the
+ ML403 reference design as well as others).
+
+ Required properties:
+ - compatible : Must include "xilinx,ml300-fb"
+ - reg : offset and length of the framebuffer register set
+
+ Optional properties:
+ - resolution : <xres yres> pixel resolution of framebuffer. Some
+ implementations use a different resolution. Default
+ is <d#640 d#480>
+ - virt-resolution : <xvirt yvirt> Size of framebuffer in memory.
+ Default is <d#1024 d#480>.
+ - rotate-display : rotate display 180 degrees.
+ - display-number : Logical number of display
+
+ m) Xilinx SystemACE
+
+ The Xilinx SystemACE device is used to program FPGAs from an FPGA
+ bitstream stored on a CF card. It can also be used as a generic CF
+ interface device.
+
+ Required properties:
+ - compatible : Must include "xilinx,sysace"
+ - reg : offset and length of SystemACE register set
+
+ Recommended properties:
+ - interrupt-parent, interrupts : Connection of device irq signal.
+
+ Optional properties:
+ - number : logical number of the SystemACE device based at 0.
+ - 8-bit (empty) : Set this property if the SystemACE must be in 8 bit mode
+
+ n) Xilinx EMAC and Xilinx TEMAC
+
+ Xilinx Ethernet devices. Uses common properties from other Ethernet
+ devices with the following constraints:
+
+ Required properties:
+ - compatible : Must include one of: "xilinx,plb-temac",
+ "xilinx,plb-emac", "xilinx-opb-emac"
+ - dma-mode : Must be one of "none", "simple", "sg" (sg == scatter gather)
+
+ o) Xilinx Uartlite
+
+ Xilinx uartlite devices are simple fixed speed serial ports. Uartlite
+ ports should be described in a node with the following properties.
+
+ Requred properties:
+ - compatible : Must include "xilinx,uartlite"
+ - reg : offset and length of uartlite register set
+
+ Recommended properties:
+ - port-number : logical port number of uartlite device based at 0.
+ - interrupt-parent, interrupts : Connection of device irq signal.
+
VII - Specifying interrupt information for devices
===================================================
^ permalink raw reply related
* Re: [POWERPC 03/15] [POWERPC] TQM5200 board support
From: Grant Likely @ 2007-10-08 7:54 UTC (permalink / raw)
To: Wolfgang Denk; +Cc: linuxppc-dev, tech-denx, Detlev Zundel, Marian Balakowicz
In-Reply-To: <20071008074409.5A6BE2486E@gemini.denx.de>
On 10/8/07, Wolfgang Denk <wd@denx.de> wrote:
> In message <fa686aa40710072321g3494b243w341e2b09117c3695@mail.gmail.com> you wrote:
> >
> > > + port_config &= ~0x03000000; /* ATA CS is on csb_4/5 */
> > > + port_config |= 0x01000000;
> >
> > Are you *sure* you want this? You should only be touching port_config
> > if firmware fails to set it up correctly. Don't blindly copy what was
> > done for the lite5200.
> >
> > Lite5200 touches it because firmware does *not* do the right thing at
> > the moment.
>
> Why don't we fix it in U-Boot, then, and get rid of this in Linux?
Mostly because I haven't gotten to it yet. :-/
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195
^ permalink raw reply
* Re: [PATCH 6/7] [POWERPC] mpc8568mds.dts: fix PCI/PCIe nodes
From: Vitaly Bordug @ 2007-10-08 8:08 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev
In-Reply-To: <EB9BE8E7-6437-403F-A7F4-953B393FDF51@kernel.crashing.org>
Hello Kumar,
On Fri, 5 Oct 2007 15:58:00 -0500
Kumar Gala wrote:
>=20
> On Oct 5, 2007, at 1:05 PM, Anton Vorontsov wrote:
>=20
> > On Fri, Oct 05, 2007 at 09:56:46PM +0400, Sergei Shtylyov wrote:
> >> Hello.
> >>
> >> Anton Vorontsov wrote:
> >>
> >>> Commit 5bece127f0666996ca90772229e00332a34e516c tried to fix
> >>> PCI/PCIe nodes, but actually it broke them even harder. ;-)
> >>
> >> Of course. But shouldn't those be the subnoses of the "soc" =20
> >> type node?
> >
> > Nope. PCI's ranges =3D <>; isn't in the SOC address space.
> >
> > Valentine Barshak posted a patch titled "[RFC] [PATCH] PowerPC: Add =20
> > 64-bit
> > phys addr support to 32-bit pci" that started using =20
> > of_translate_address()
> > for ranges, and of_translate_address() will not work if PCI placed =20
> > in the
> > SOC node. Not sure if that patch applied or not, though.
>=20
> I'm confused, what's the actual issue with PCI that this patch =20
> addresses?
>=20
=46rom what I can see, move of the PCI node out of the SoC node, inspired by =
the recent flame talk about it :)
I guess pretty soon, we'll have "proper" ranges parsing for pci, that does =
of_translate_address() and requires
either tuned-up parent ranges, or residing outside of the SoC node, this is=
the reason...
> - k
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
--=20
Sincerely, Vitaly
^ permalink raw reply
* Re: Where are inb/outb macros?
From: Benjamin Herrenschmidt @ 2007-10-08 8:11 UTC (permalink / raw)
To: Misbah khan; +Cc: linuxppc-dev
In-Reply-To: <13091078.post@talk.nabble.com>
On Mon, 2007-10-08 at 00:09 -0700, Misbah khan wrote:
> inb/outb could be used from the usr space on x86 class PC-computer to access
> to io ports this is what i assume that you are trying
>
> You need to compile the program with -O option (expantion of Inline function
> )
>
> To perform io operation on ports ioprem/iopl system call must be used (To
> get permissio to perform io operation)
>
> Program must run as root
>
> on non 86 platform try using /dev/port device file in the application
"io ports" don't mean much on non-x86 platforms (or rather can have
multiple meanings) which is why I'm asking what is he trying to od in
the first place.
Ben.
^ permalink raw reply
* Re: [patch 6/6] PS3: Add os-area database routines
From: Geert Uytterhoeven @ 2007-10-08 8:27 UTC (permalink / raw)
To: geoffrey.levand; +Cc: linuxppc-dev, paulus
In-Reply-To: <20071006213542.954029915@am.sony.com>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 3001 bytes --]
On Sat, 6 Oct 2007 geoffrey.levand@am.sony.com wrote:
> --- a/arch/powerpc/platforms/ps3/os-area.c
> +++ b/arch/powerpc/platforms/ps3/os-area.c
> @@ -112,10 +114,91 @@ struct os_area_params {
> u8 _reserved_5[8];
> };
>
> +/**
> + * struct os_area_db - Shared flash memory database.
> + * @magic_num: Always '-db-' = 0x2d64622d.
^^^^^^^^^^
#define?
> @@ -242,6 +325,303 @@ static int __init verify_header(const st
> return 0;
> }
>
> +static int db_verify(const struct os_area_db *db)
> +{
> + if (db->magic_num != 0x2d64622dU) {
^^^^^^^^^^^
#define?
> +static void os_area_db_init(struct os_area_db *db)
> +{
> + /*
> + * item | start | size
> + * ----------+-------+-------
> + * header | 0 | 24
> + * index_64 | 24 | 64
> + * values_64 | 88 | 57*8 = 456
> + * index_32 | 544 | 64
> + * values_32 | 609 | 57*4 = 228
> + * index_16 | 836 | 64
> + * values_16 | 900 | 57*2 = 114
> + * end | 1014 | -
> + */
Lots of #defines and calculations?
> +
> + memset(db, 0, sizeof(struct os_area_db));
> +
> + db->magic_num = 0x2d64622dU;
^^^^^^^^^^^
#define?
> + db->version = 1;
> + db->index_64 = 24;
^^
> + db->count_64 = 57;
^^
> + db->index_32 = 544;
^^^
> + db->count_32 = 57;
^^
> + db->index_16 = 836;
^^^
> + db->count_16 = 57;
^^
#defines?
> +static void update_flash_db(void)
> +{
> + int result;
> + int file;
> + off_t offset;
> + ssize_t count;
> + static const unsigned int buf_len = 8 * OS_AREA_SEGMENT_SIZE;
> + const struct os_area_header *header;
> + struct os_area_db* db;
> +
> + /* Read in header and db from flash. */
> +
> + file = sys_open("/dev/ps3flash", O_RDWR, 0);
Ah, file operations from kernel space...
> @@ -264,6 +644,9 @@ static void os_area_queue_work_handler(s
> pr_debug("%s:%d of_find_node_by_path failed\n",
> __func__, __LINE__);
>
> +#if defined(CONFIG_PS3_FLASH) || defined(CONFIG_PS3_FLASH_MODULE)
> + update_flash_db();
> +#endif
Is this #ifdef needed? You don't reference ps3flash symbols directly, only by
opening /dev/ps3flash. If you always call update_flash_db(), you can print an
error message and the user will notice things haven't been written to flash.
With kind regards,
Geert Uytterhoeven
Software Architect
Sony Network and Software Technology Center Europe
The Corporate Village · Da Vincilaan 7-D1 · B-1935 Zaventem · Belgium
Phone: +32 (0)2 700 8453
Fax: +32 (0)2 700 8622
E-mail: Geert.Uytterhoeven@sonycom.com
Internet: http://www.sony-europe.com/
Sony Network and Software Technology Center Europe
A division of Sony Service Centre (Europe) N.V.
Registered office: Technologielaan 7 · B-1840 Londerzeel · Belgium
VAT BE 0413.825.160 · RPR Brussels
Fortis Bank Zaventem · Swift GEBABEBB08A · IBAN BE39001382358619
^ permalink raw reply
* Re: [RFC PATCH v0.1] net driver: mpc52xx fec
From: Sascha Hauer @ 2007-10-08 8:48 UTC (permalink / raw)
To: Juergen Beisert; +Cc: linuxppc-embedded
In-Reply-To: <200709281112.18480.jbe@pengutronix.de>
Hi,
On Fri, Sep 28, 2007 at 11:12:17AM +0200, Juergen Beisert wrote:
> I tried with in_atomic(). The BUG report is gone, but the problem still
> exists.
>
> While network stress testing:
>
> [...]
> NETDEV WATCHDOG: eth0: transmit timed out
> net eth0: transmit timed out
> net eth0: queues didn't drain
> net eth0: tx: index: 35, outdex: 36
> net eth0: rx: index: 24, outdex: 25
> PHY: f0003000:00 - Link is Down
> PHY: f0003000:00 - Link is Up - 100/Full
>
> The link is up again, but any connection is dead (no answers to ping etc.).
> But the serial console is still working. I'm not sure if the RT-Preempt patch
> *causes* this behavior or only *discover* it. Any idea?
We finally solved this problem. It has nothing to do with locking
though. The problem is that the bcom engine was not reenabled after
resetting the fec. The following patch solves this.
Reenable the bestcom engine after resetting the mpc52xx fec
controller.
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
---
drivers/net/fec_mpc52xx/fec.c | 3 +++
1 file changed, 3 insertions(+)
Index: linux-2.6/drivers/net/fec_mpc52xx/fec.c
===================================================================
--- linux-2.6.orig/drivers/net/fec_mpc52xx/fec.c
+++ linux-2.6/drivers/net/fec_mpc52xx/fec.c
@@ -788,6 +788,9 @@ static void fec_reset(struct net_device
fec_alloc_rx_buffers(priv->rx_dmatsk);
+ bcom_enable(priv->rx_dmatsk);
+ bcom_enable(priv->tx_dmatsk);
+
fec_start(dev);
}
>
> Juergen
> --
> Dipl.-Ing. Juergen Beisert | http://www.pengutronix.de
> Pengutronix - Linux Solutions for Science and Industry
> Handelsregister: Amtsgericht Hildesheim, HRA 2686
> Vertretung Sued/Muenchen, Germany
> Phone: +49-8766-939 228 | Fax: +49-5121-206917-9
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
--
Pengutronix - Linux Solutions for Science and Industry
Entwicklungszentrum Nord http://www.pengutronix.de
^ permalink raw reply
* Re: [RFC PATCH v0.1] net driver: mpc52xx fec
From: Sascha Hauer @ 2007-10-08 9:01 UTC (permalink / raw)
To: Juergen Beisert; +Cc: linuxppc-embedded
In-Reply-To: <200709281112.18480.jbe@pengutronix.de>
On Fri, Sep 28, 2007 at 11:12:17AM +0200, Juergen Beisert wrote:
>
> While network stress testing:
>
> [...]
> NETDEV WATCHDOG: eth0: transmit timed out
> net eth0: transmit timed out
> net eth0: queues didn't drain
> net eth0: tx: index: 35, outdex: 36
> net eth0: rx: index: 24, outdex: 25
> PHY: f0003000:00 - Link is Down
> PHY: f0003000:00 - Link is Up - 100/Full
>
> The link is up again, but any connection is dead (no answers to ping etc.).
> But the serial console is still working. I'm not sure if the RT-Preempt patch
> *causes* this behavior or only *discover* it. Any idea?
While the previous patch I sent fixed the reset path for the fec
controller this patch makes sure the chip does not have to be resetted.
Problem was that we ran out of receive buffers when we nmapped our
board (nmap sends lots of small packages in a short period of time).
By increasing the number of rx buffers this problem does not appear
anymore.
This patch produces a significant memory overhead to the driver of about
340k, so we might want to have this configurable as a module parameter.
Let me know what the preferred way is, I can update the patch
accordingly.
Sascha
Increase the number of RX packets in the fec_mpc52xx driver. This is
necessary to no run out of rx packets when lots of small packets arrive
in short time (for example when nmapping the board)
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
---
drivers/net/fec_mpc52xx/fec.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Index: linux-2.6/drivers/net/fec_mpc52xx/fec.h
===================================================================
--- linux-2.6.orig/drivers/net/fec_mpc52xx/fec.h
+++ linux-2.6/drivers/net/fec_mpc52xx/fec.h
@@ -19,7 +19,7 @@
/* Tunable constant */
/* FEC_RX_BUFFER_SIZE includes 4 bytes for CRC32 */
#define FEC_RX_BUFFER_SIZE 1522 /* max receive packet size */
-#define FEC_RX_NUM_BD 64
+#define FEC_RX_NUM_BD 256
#define FEC_TX_NUM_BD 64
#define FEC_RESET_DELAY 50 /* uS */
--
Pengutronix - Linux Solutions for Science and Industry
Entwicklungszentrum Nord http://www.pengutronix.de
^ permalink raw reply
* [PATCH 0/3] [POWERPC] Add AMCC 405EX PPC and Kilauea eval board support
From: Stefan Roese @ 2007-10-08 9:04 UTC (permalink / raw)
To: linuxppc-dev
This series adds AMCC 405EX support including the Kilauea eval board to
arch/powerpc. Please review and comment.
Best regards,
Stefan
^ permalink raw reply
* [PATCH 3/3] [POWERPC] Kilauea DTS
From: Stefan Roese @ 2007-10-08 9:10 UTC (permalink / raw)
To: linuxppc-dev
Signed-off-by: Stefan Roese <sr@denx.de>
---
arch/powerpc/boot/dts/kilauea.dts | 253 +++++++++++++++++++++++++++++++++++++
1 files changed, 253 insertions(+), 0 deletions(-)
create mode 100644 arch/powerpc/boot/dts/kilauea.dts
diff --git a/arch/powerpc/boot/dts/kilauea.dts b/arch/powerpc/boot/dts/kilauea.dts
new file mode 100644
index 0000000..4683174
--- /dev/null
+++ b/arch/powerpc/boot/dts/kilauea.dts
@@ -0,0 +1,253 @@
+/*
+ * Device Tree Source for AMCC Kilauea (405EX)
+ *
+ * Copyright 2007 DENX Software Engineering, Stefan Roese <sr@denx.de>
+ *
+ * This file is licensed under the terms of the GNU General Public
+ * License version 2. This program is licensed "as is" without
+ * any warranty of any kind, whether express or implied.
+ */
+
+/ {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ model = "amcc,kilauea";
+ compatible = "amcc,kilauea";
+ dcr-parent = <&/cpus/PowerPC,405EX@0>;
+
+ cpus {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ PowerPC,405EX@0 {
+ device_type = "cpu";
+ reg = <0>;
+ clock-frequency = <0>; /* Filled in by U-Boot */
+ timebase-frequency = <0>; /* Filled in by U-Boot */
+ i-cache-line-size = <20>;
+ d-cache-line-size = <20>;
+ i-cache-size = <4000>; /* 16 kB */
+ d-cache-size = <4000>; /* 16 kB */
+ dcr-controller;
+ dcr-access-method = "native";
+ };
+ };
+
+ memory {
+ device_type = "memory";
+ reg = <0 0>; /* Filled in by U-Boot */
+ };
+
+ UIC0: interrupt-controller {
+ compatible = "ibm,uic-405ex", "ibm,uic";
+ interrupt-controller;
+ cell-index = <0>;
+ dcr-reg = <0c0 009>;
+ #address-cells = <0>;
+ #size-cells = <0>;
+ #interrupt-cells = <2>;
+ };
+
+ UIC1: interrupt-controller1 {
+ compatible = "ibm,uic-405ex","ibm,uic";
+ interrupt-controller;
+ cell-index = <1>;
+ dcr-reg = <0d0 009>;
+ #address-cells = <0>;
+ #size-cells = <0>;
+ #interrupt-cells = <2>;
+ interrupts = <1e 4 1f 4>; /* cascade */
+ interrupt-parent = <&UIC0>;
+ };
+
+ UIC2: interrupt-controller2 {
+ compatible = "ibm,uic-405ex","ibm,uic";
+ interrupt-controller;
+ cell-index = <2>;
+ dcr-reg = <0e0 009>;
+ #address-cells = <0>;
+ #size-cells = <0>;
+ #interrupt-cells = <2>;
+ interrupts = <1c 4 1d 4>; /* cascade */
+ interrupt-parent = <&UIC0>;
+ };
+
+ plb {
+ compatible = "ibm,plb-405ex", "ibm,plb4";
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges;
+ clock-frequency = <0>; /* Filled in by U-Boot */
+
+ SDRAM0: memory-controller {
+ compatible = "ibm,sdram-405ex";
+ dcr-reg = <010 2>;
+ };
+
+ MAL0: mcmal {
+ compatible = "ibm,mcmal-405ex", "ibm,mcmal2";
+ dcr-reg = <180 62>;
+ num-tx-chans = <2>;
+ num-rx-chans = <2>;
+ interrupt-parent = <&MAL0>;
+ interrupts = <0 1 2 3 4>;
+ #interrupt-cells = <1>;
+ #address-cells = <0>;
+ #size-cells = <0>;
+ interrupt-map = </*TXEOB*/ 0 &UIC0 a 4
+ /*RXEOB*/ 1 &UIC0 b 4
+ /*SERR*/ 2 &UIC1 0 4
+ /*TXDE*/ 3 &UIC1 1 4
+ /*RXDE*/ 4 &UIC1 2 4>;
+ interrupt-map-mask = <ffffffff>;
+ };
+
+ POB0: opb {
+ compatible = "ibm,opb-405ex", "ibm,opb";
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges = <ef600000 ef600000 a00000>;
+ dcr-reg = <0a0 5>;
+ clock-frequency = <0>; /* Filled in by U-Boot */
+
+ EBC0: ebc {
+ compatible = "ibm,ebc-405ex", "ibm,ebc";
+ dcr-reg = <012 2>;
+ #address-cells = <2>;
+ #size-cells = <1>;
+ clock-frequency = <0>; /* Filled in by U-Boot */
+ interrupts = <5 1>;
+ interrupt-parent = <&UIC1>;
+
+ nor_flash@0,0 {
+ compatible = "amd,s29gl256n", "cfi-flash";
+ bank-width = <2>;
+ reg = <0 000000 4000000>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ partition@0 {
+ label = "Kernel";
+ reg = <0 180000>;
+ };
+ partition@180000 {
+ label = "ramdisk";
+ reg = <180000 200000>;
+ };
+ partition@380000 {
+ label = "file system";
+ reg = <380000 3aa0000>;
+ };
+ partition@3e20000 {
+ label = "kozio";
+ reg = <3e20000 140000>;
+ };
+ partition@3f60000 {
+ label = "env";
+ reg = <3f60000 40000>;
+ };
+ partition@3fa0000 {
+ label = "u-boot";
+ reg = <3fa0000 60000>;
+ };
+ };
+ };
+
+ UART0: serial@ef600200 {
+ device_type = "serial";
+ compatible = "ns16550";
+ reg = <ef600200 8>;
+ virtual-reg = <ef600200>;
+ clock-frequency = <0>; /* Filled in by U-Boot */
+ current-speed = <0>;
+ interrupt-parent = <&UIC0>;
+ interrupts = <1a 4>;
+ };
+
+ UART1: serial@ef600300 {
+ device_type = "serial";
+ compatible = "ns16550";
+ reg = <ef600300 8>;
+ virtual-reg = <ef600300>;
+ clock-frequency = <0>; /* Filled in by U-Boot */
+ current-speed = <0>;
+ interrupt-parent = <&UIC0>;
+ interrupts = <1 4>;
+ };
+
+ IIC0: i2c@ef600400 {
+ device_type = "i2c";
+ compatible = "ibm,iic-405ex", "ibm,iic";
+ reg = <ef600400 14>;
+ interrupt-parent = <&UIC0>;
+ interrupts = <2 4>;
+ };
+
+ IIC1: i2c@ef600500 {
+ device_type = "i2c";
+ compatible = "ibm,iic-405ex", "ibm,iic";
+ reg = <ef600500 14>;
+ interrupt-parent = <&UIC0>;
+ interrupts = <7 4>;
+ };
+
+
+ RGMII0: emac-rgmii@ef600b00 {
+ device_type = "rgmii-interface";
+ compatible = "ibm,rgmii-405ex", "ibm,rgmii";
+ reg = <ef600b00 104>;
+ };
+
+ EMAC0: ethernet@ef600900 {
+ linux,network-index = <0>;
+ device_type = "network";
+ compatible = "ibm,emac-405ex", "ibm,emac4";
+ interrupt-parent = <&EMAC0>;
+ interrupts = <0 1>;
+ #interrupt-cells = <1>;
+ #address-cells = <0>;
+ #size-cells = <0>;
+ interrupt-map = </*Status*/ 0 &UIC0 18 4
+ /*Wake*/ 1 &UIC1 1d 4>;
+ reg = <ef600900 70>;
+ local-mac-address = [000000000000];
+ mal-device = <&MAL0>;
+ mal-tx-channel = <0>;
+ mal-rx-channel = <0>;
+ cell-index = <0>;
+ max-frame-size = <5dc>;
+ rx-fifo-size = <1000>;
+ tx-fifo-size = <800>;
+ phy-mode = "rgmii";
+ phy-map = <00000000>;
+ rgmii-device = <&RGMII0>;
+ rgmii-channel = <0>;
+ };
+
+ EMAC1: ethernet@ef600a00 {
+ linux,network-index = <1>;
+ device_type = "network";
+ compatible = "ibm,emac-405ex", "ibm,emac4";
+ interrupt-parent = <&EMAC1>;
+ interrupts = <0 1>;
+ #interrupt-cells = <1>;
+ #address-cells = <0>;
+ #size-cells = <0>;
+ interrupt-map = </*Status*/ 0 &UIC0 19 4
+ /*Wake*/ 1 &UIC1 1f 4>;
+ reg = <ef600a00 70>;
+ local-mac-address = [000000000000];
+ mal-device = <&MAL0>;
+ mal-tx-channel = <1>;
+ mal-rx-channel = <1>;
+ cell-index = <1>;
+ max-frame-size = <5dc>;
+ rx-fifo-size = <1000>;
+ tx-fifo-size = <800>;
+ phy-mode = "rgmii";
+ phy-map = <00000000>;
+ rgmii-device = <&RGMII0>;
+ rgmii-channel = <1>;
+ };
+ };
+ };
+};
--
1.5.3.4
^ permalink raw reply related
* [PATCH 1/3] [POWERPC] Add AMCC 405EX support to cputable.c
From: Stefan Roese @ 2007-10-08 9:07 UTC (permalink / raw)
To: linuxppc-dev
Signed-off-by: Stefan Roese <sr@denx.de>
---
arch/powerpc/kernel/cputable.c | 11 +++++++++++
1 files changed, 11 insertions(+)
diff --git a/arch/powerpc/kernel/cputable.c b/arch/powerpc/kernel/cputable.c
index b03a442..ea81d1e 100644
--- a/arch/powerpc/kernel/cputable.c
+++ b/arch/powerpc/kernel/cputable.c
@@ -1103,6 +1103,17 @@ static struct cpu_spec cpu_specs[] = {
.dcache_bsize = 32,
.platform = "ppc405",
},
+ { /* 405EX */
+ .pvr_mask = 0xffff0000,
+ .pvr_value = 0x12910000,
+ .cpu_name = "405EX",
+ .cpu_features = CPU_FTRS_40X,
+ .cpu_user_features = PPC_FEATURE_32 |
+ PPC_FEATURE_HAS_MMU | PPC_FEATURE_HAS_4xxMAC,
+ .icache_bsize = 32,
+ .dcache_bsize = 32,
+ .platform = "ppc405",
+ },
#endif /* CONFIG_40x */
#ifdef CONFIG_44x
--
1.5.3.4
^ permalink raw reply related
* [PATCH 2/3] [POWERPC] Add AMCC Kilauea eval board support to platforms/40x
From: Stefan Roese @ 2007-10-08 9:08 UTC (permalink / raw)
To: linuxppc-dev
This patch adds basic support for the new 405EX and the AMCC eval board
Kilauea to arch/powerpc.
Signed-off-by: Stefan Roese <sr@denx.de>
---
arch/powerpc/platforms/40x/Kconfig | 17 +++++++--
arch/powerpc/platforms/40x/Makefile | 5 ++-
arch/powerpc/platforms/40x/kilauea.c | 63 ++++++++++++++++++++++++++++++++++
3 files changed, 80 insertions(+), 5 deletions(-)
create mode 100644 arch/powerpc/platforms/40x/kilauea.c
diff --git a/arch/powerpc/platforms/40x/Kconfig b/arch/powerpc/platforms/40x/Kconfig
index a0a50b1..da8d02d 100644
--- a/arch/powerpc/platforms/40x/Kconfig
+++ b/arch/powerpc/platforms/40x/Kconfig
@@ -29,6 +29,14 @@
# help
# This option enables support for the extra features of the EP405PC board.
+config KILAUEA
+ bool "Kilauea"
+ depends on 40x
+ default y
+ select 405EX
+ help
+ This option enables support for the AMCC PPC405EX evaluation board.
+
#config REDWOOD_5
# bool "Redwood-5"
# depends on 40x
@@ -89,14 +97,17 @@ config 403GCX
#depends on OAK
select IBM405_ERR51
+config 405EP
+ bool
+
+config 405EX
+ bool
+
config 405GP
bool
select IBM405_ERR77
select IBM405_ERR51
-config 405EP
- bool
-
config 405GPR
bool
diff --git a/arch/powerpc/platforms/40x/Makefile b/arch/powerpc/platforms/40x/Makefile
index 0a3cfe9..51dadee 100644
--- a/arch/powerpc/platforms/40x/Makefile
+++ b/arch/powerpc/platforms/40x/Makefile
@@ -1,2 +1,3 @@
-obj-$(CONFIG_WALNUT) += walnut.o
-obj-$(CONFIG_XILINX_VIRTEX_GENERIC_BOARD) += virtex.o
+obj-$(CONFIG_KILAUEA) += kilauea.o
+obj-$(CONFIG_WALNUT) += walnut.o
+obj-$(CONFIG_XILINX_VIRTEX_GENERIC_BOARD) += virtex.o
diff --git a/arch/powerpc/platforms/40x/kilauea.c b/arch/powerpc/platforms/40x/kilauea.c
new file mode 100644
index 0000000..6cbd528
--- /dev/null
+++ b/arch/powerpc/platforms/40x/kilauea.c
@@ -0,0 +1,63 @@
+/*
+ * Kilauea board specific routines
+ *
+ * Copyright 2007 DENX Software Engineering, Stefan Roese <sr@denx.de>
+ *
+ * Based on the Walnut code by
+ * Josh Boyer <jwboyer@linux.vnet.ibm.com>
+ * Copyright 2007 IBM Corporation
+ *
+ * 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/init.h>
+#include <asm/machdep.h>
+#include <asm/prom.h>
+#include <asm/udbg.h>
+#include <asm/time.h>
+#include <asm/uic.h>
+#include <asm/of_platform.h>
+
+static struct of_device_id kilauea_of_bus[] = {
+ { .compatible = "ibm,plb4", },
+ { .compatible = "ibm,opb", },
+ { .compatible = "ibm,ebc", },
+ {},
+};
+
+static int __init kilauea_device_probe(void)
+{
+ if (!machine_is(kilauea))
+ return 0;
+
+ of_platform_bus_probe(NULL, kilauea_of_bus, NULL);
+
+ return 0;
+}
+device_initcall(kilauea_device_probe);
+
+static int __init kilauea_probe(void)
+{
+ unsigned long root = of_get_flat_dt_root();
+
+ if (!of_flat_dt_is_compatible(root, "amcc,kilauea"))
+ return 0;
+
+ return 1;
+}
+
+static void __init kilauea_setup_arch(void)
+{
+}
+
+define_machine(kilauea) {
+ .name = "Kilauea",
+ .probe = kilauea_probe,
+ .setup_arch = kilauea_setup_arch,
+ .progress = udbg_progress,
+ .init_IRQ = uic_init_tree,
+ .get_irq = uic_get_irq,
+ .calibrate_decr = generic_calibrate_decr,
+};
--
1.5.3.4
^ permalink raw reply related
* problem port linux to MPC860T
From: keng_629 @ 2007-10-08 9:34 UTC (permalink / raw)
To: linuxppc-embedded@ozlabs.org
[-- Attachment #1: Type: text/plain, Size: 292 bytes --]
recently i am working with porting the linux2.6.23 to MPC860T
i use the lighter to test where my kernel is now runing.
i find it out of control after the local_irq_enable() funciton in the asmlinkage void __init start_kernel(void) in init/main.c file.
Can somebody give me a hand?thank you
[-- Attachment #2: Type: text/html, Size: 858 bytes --]
^ permalink raw reply
* Re: [PATCH 2/3] [POWERPC] Add AMCC Kilauea eval board support to platforms/40x
From: Stephen Rothwell @ 2007-10-08 11:48 UTC (permalink / raw)
To: Stefan Roese; +Cc: linuxppc-dev
In-Reply-To: <200710081108.51625.sr@denx.de>
[-- Attachment #1: Type: text/plain, Size: 315 bytes --]
On Mon, 8 Oct 2007 11:08:51 +0200 Stefan Roese <sr@denx.de> wrote:
>
> +++ b/arch/powerpc/platforms/40x/kilauea.c
>
> +#include <asm/of_platform.h>
Here I go again :-)
linux/of_platform.h please
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH 2/3] [POWERPC] Add AMCC Kilauea eval board support to platforms/40x
From: Stefan Roese @ 2007-10-08 12:03 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Stephen Rothwell
In-Reply-To: <20071008214848.f6c6070d.sfr@canb.auug.org.au>
On Monday 08 October 2007, Stephen Rothwell wrote:
> > +#include <asm/of_platform.h>
>
> Here I go again :-)
>
> linux/of_platform.h please
Right. I was watching all your reviews lately and wanted not to make this
error. Didn't work out as it seems. :-)
I'll wait a while for further comments and send a fixed version soon.
Thanks.
Best regards,
Stefan
^ permalink raw reply
* Re: [PATCH 6/7] [POWERPC] mpc8568mds.dts: fix PCI/PCIe nodes
From: Anton Vorontsov @ 2007-10-08 12:08 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev
In-Reply-To: <EB9BE8E7-6437-403F-A7F4-953B393FDF51@kernel.crashing.org>
On Fri, Oct 05, 2007 at 03:58:00PM -0500, Kumar Gala wrote:
>
> On Oct 5, 2007, at 1:05 PM, Anton Vorontsov wrote:
>
>> On Fri, Oct 05, 2007 at 09:56:46PM +0400, Sergei Shtylyov wrote:
>>> Hello.
>>>
>>> Anton Vorontsov wrote:
>>>
>>>> Commit 5bece127f0666996ca90772229e00332a34e516c tried to fix
>>>> PCI/PCIe nodes, but actually it broke them even harder. ;-)
>>>
>>> Of course. But shouldn't those be the subnoses of the "soc" type node?
>>
>> Nope. PCI's ranges = <>; isn't in the SOC address space.
>>
>> Valentine Barshak posted a patch titled "[RFC] [PATCH] PowerPC: Add 64-bit
>> phys addr support to 32-bit pci" that started using of_translate_address()
>> for ranges, and of_translate_address() will not work if PCI placed in the
>> SOC node. Not sure if that patch applied or not, though.
>
> I'm confused, what's the actual issue with PCI that this patch addresses?
Which patch? Valentine's or mine under the subject? Don't know about the
former, but mine patch is pretty obvious: your commit
5bece127f0666996ca90772229e00332a34e516c moved PCI nodes out of soc node,
but you forgot to change regs = <>, thus instead of e000a000/e0008000,
kernel used a000/8000 for accessing PCI ccsr registers.
--
Anton Vorontsov
email: cbou@mail.ru
backup email: ya-cbou@yandex.ru
irc://irc.freenode.net/bd2
^ permalink raw reply
* Re: [PATCH respin 0/7] MPC8568E-MDS related patches
From: Anton Vorontsov @ 2007-10-08 12:16 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev
In-Reply-To: <27C7E568-B28A-4659-803F-9D271B2E1AF6@kernel.crashing.org>
On Fri, Oct 05, 2007 at 05:09:28PM -0500, Kumar Gala wrote:
>
> On Oct 5, 2007, at 12:40 PM, Anton Vorontsov wrote:
>
>> Hello Kumar,
>>
>> This is respin of MPC8568E-MDS patches, on top of master branch
>> as of today.
>>
>> If there are no objections against SPI patch, please Ack it, thus
>> David could pick it up.
>
> I've applied patches 1-5 however I'm not able to get UCC enet working on my
> board.
I wonder how you managed to boot it w/o sixth (PCI) patch in this patch set,
for me board hanged w/o it.
> Is there something special that has to be done? (I've got the card
> standalone, no MDS backplane).
Nothing special, from what I can remember. Though, double checking switches
on the board might help.
Also, .config and bootlog would help.
> I'm using the 1.3.0-rc2 u-boot w/o any modifications.
1.2.0-g60174746 here.
> Also, I tried a PCIe e1000 card w/the .dts that's in my tree and that works
> w/o any issue.
Strange enough. I'd say it's impossible with your current tree. Maybe you've
used some stale dtb? Because dts is seriously broken as now, and I can't
believe that it worked for you. ;-)
Thanks,
--
Anton Vorontsov
email: cbou@mail.ru
backup email: ya-cbou@yandex.ru
irc://irc.freenode.net/bd2
^ permalink raw reply
* Re: [patch 6/6] PS3: Add os-area database routines
From: Geert Uytterhoeven @ 2007-10-08 12:16 UTC (permalink / raw)
To: geoffrey.levand; +Cc: linuxppc-dev, paulus
In-Reply-To: <20071006213542.954029915@am.sony.com>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 1092 bytes --]
On Sat, 6 Oct 2007 geoffrey.levand@am.sony.com wrote:
> --- a/arch/powerpc/platforms/ps3/os-area.c
> +++ b/arch/powerpc/platforms/ps3/os-area.c
> +static int db_get_video_mode(const struct os_area_db *db,
> + unsigned int *video_mode)
^^^^^^^^^^^^^^
> +{
> + return db_get_64(db, &os_area_db_id_video_mode, (uint64_t*)video_mode);
^^^^^^^^^^^
> +}
Woops, memory corruption, when writing a 64-bit value to a 32-bit variable.
With kind regards,
Geert Uytterhoeven
Software Architect
Sony Network and Software Technology Center Europe
The Corporate Village · Da Vincilaan 7-D1 · B-1935 Zaventem · Belgium
Phone: +32 (0)2 700 8453
Fax: +32 (0)2 700 8622
E-mail: Geert.Uytterhoeven@sonycom.com
Internet: http://www.sony-europe.com/
Sony Network and Software Technology Center Europe
A division of Sony Service Centre (Europe) N.V.
Registered office: Technologielaan 7 · B-1840 Londerzeel · Belgium
VAT BE 0413.825.160 · RPR Brussels
Fortis Bank Zaventem · Swift GEBABEBB08A · IBAN BE39001382358619
^ 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