* Re: [RFC PATCH 16/19] powerpc: wii: hollywood interrupt controller support
From: Grant Likely @ 2009-11-22 23:40 UTC (permalink / raw)
To: Albert Herranz; +Cc: linuxppc-dev
In-Reply-To: <1258927311-4340-17-git-send-email-albert_herranz@yahoo.es>
On Sun, Nov 22, 2009 at 3:01 PM, Albert Herranz <albert_herranz@yahoo.es> w=
rote:
> Add support for the dual interrupt controller included in the "Hollywood"
> chipset of the Nintendo Wii video game console.
> This interrupt controller serves both the Broadway processor (as a cascad=
e)
> and the Starlet processor, and is used to manage interrupts for the
> non-classic hardware.
>
> Signed-off-by: Albert Herranz <albert_herranz@yahoo.es>
On brief glance...
Acked-by: Grant Likely <grant.likely@secretlab.ca>
> ---
> =A0arch/powerpc/platforms/embedded6xx/Kconfig =A0 =A0| =A0 =A05 +
> =A0arch/powerpc/platforms/embedded6xx/Makefile =A0 | =A0 =A01 +
> =A0arch/powerpc/platforms/embedded6xx/hlwd-pic.c | =A0238 +++++++++++++++=
++++++++++
> =A0arch/powerpc/platforms/embedded6xx/hlwd-pic.h | =A0 22 +++
> =A04 files changed, 266 insertions(+), 0 deletions(-)
> =A0create mode 100644 arch/powerpc/platforms/embedded6xx/hlwd-pic.c
> =A0create mode 100644 arch/powerpc/platforms/embedded6xx/hlwd-pic.h
>
> diff --git a/arch/powerpc/platforms/embedded6xx/Kconfig b/arch/powerpc/pl=
atforms/embedded6xx/Kconfig
> index efb2ea1..490f89e 100644
> --- a/arch/powerpc/platforms/embedded6xx/Kconfig
> +++ b/arch/powerpc/platforms/embedded6xx/Kconfig
> @@ -122,3 +122,8 @@ config GAMECUBE
> =A0 =A0 =A0 =A0 =A0Select GAMECUBE if configuring for the Nintendo GameCu=
be.
> =A0 =A0 =A0 =A0 =A0More information at: <http://gc-linux.sourceforge.net/=
>
>
> +config HLWD_PIC
> + =A0 =A0 =A0 bool
> + =A0 =A0 =A0 depends on STARLET_MINI
> + =A0 =A0 =A0 default y
> +
> diff --git a/arch/powerpc/platforms/embedded6xx/Makefile b/arch/powerpc/p=
latforms/embedded6xx/Makefile
> index b0324ed..c1dcc54 100644
> --- a/arch/powerpc/platforms/embedded6xx/Makefile
> +++ b/arch/powerpc/platforms/embedded6xx/Makefile
> @@ -10,3 +10,4 @@ obj-$(CONFIG_PPC_C2K) =A0 =A0 =A0 =A0 +=3D c2k.o
> =A0obj-$(CONFIG_USBGECKO_UDBG) =A0 =A0+=3D usbgecko_udbg.o
> =A0obj-$(CONFIG_FLIPPER_PIC) =A0 =A0 =A0+=3D flipper-pic.o
> =A0obj-$(CONFIG_GAMECUBE) =A0 =A0 =A0 =A0 +=3D gamecube.o gamecube_dev.o
> +obj-$(CONFIG_HLWD_PIC) =A0 =A0 =A0 =A0 +=3D hlwd-pic.o
> diff --git a/arch/powerpc/platforms/embedded6xx/hlwd-pic.c b/arch/powerpc=
/platforms/embedded6xx/hlwd-pic.c
> new file mode 100644
> index 0000000..b024800
> --- /dev/null
> +++ b/arch/powerpc/platforms/embedded6xx/hlwd-pic.c
> @@ -0,0 +1,238 @@
> +/*
> + * arch/powerpc/platforms/embedded6xx/hlwd-pic.c
> + *
> + * Nintendo Wii "Hollywood" interrupt controller support.
> + * Copyright (C) 2009 The GameCube Linux Team
> + * Copyright (C) 2009 Albert Herranz
> + *
> + * 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.
> + *
> + */
> +#define DRV_MODULE_NAME "hlwd-pic"
> +#define pr_fmt(fmt) DRV_MODULE_NAME ": " fmt
> +
> +#include <linux/kernel.h>
> +#include <linux/init.h>
> +#include <linux/irq.h>
> +#include <linux/of.h>
> +#include <asm/io.h>
> +
> +#include "hlwd-pic.h"
> +
> +#define HLWD_NR_IRQS =A0 32
> +
> +/*
> + * Each interrupt has a corresponding bit in both
> + * the Interrupt Cause (ICR) and Interrupt Mask (IMR) registers.
> + *
> + * Enabling/disabling an interrupt line involves asserting/clearing
> + * the corresponding bit in IMR. ACK'ing a request simply involves
> + * asserting the corresponding bit in ICR.
> + */
> +#define HW_BROADWAY_ICR =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A00x00
> +#define HW_BROADWAY_IMR =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A00x04
> +
> +
> +/*
> + * IRQ chip hooks.
> + *
> + */
> +
> +static void hlwd_pic_mask_and_ack(unsigned int virq)
> +{
> + =A0 =A0 =A0 int irq =3D virq_to_hw(virq);
> + =A0 =A0 =A0 void __iomem *io_base =3D get_irq_chip_data(virq);
> +
> + =A0 =A0 =A0 clear_bit(irq, io_base + HW_BROADWAY_IMR);
> + =A0 =A0 =A0 set_bit(irq, io_base + HW_BROADWAY_ICR);
> +}
> +
> +static void hlwd_pic_ack(unsigned int virq)
> +{
> + =A0 =A0 =A0 int irq =3D virq_to_hw(virq);
> + =A0 =A0 =A0 void __iomem *io_base =3D get_irq_chip_data(virq);
> +
> + =A0 =A0 =A0 set_bit(irq, io_base + HW_BROADWAY_ICR);
> +}
> +
> +static void hlwd_pic_mask(unsigned int virq)
> +{
> + =A0 =A0 =A0 int irq =3D virq_to_hw(virq);
> + =A0 =A0 =A0 void __iomem *io_base =3D get_irq_chip_data(virq);
> +
> + =A0 =A0 =A0 clear_bit(irq, io_base + HW_BROADWAY_IMR);
> +}
> +
> +static void hlwd_pic_unmask(unsigned int virq)
> +{
> + =A0 =A0 =A0 int irq =3D virq_to_hw(virq);
> + =A0 =A0 =A0 void __iomem *io_base =3D get_irq_chip_data(virq);
> +
> + =A0 =A0 =A0 set_bit(irq, io_base + HW_BROADWAY_IMR);
> +}
> +
> +
> +static struct irq_chip hlwd_pic =3D {
> + =A0 =A0 =A0 .typename =A0 =A0 =A0 =3D "hlwd-pic",
> + =A0 =A0 =A0 .ack =A0 =A0 =A0 =A0 =A0 =A0=3D hlwd_pic_ack,
> + =A0 =A0 =A0 .mask_ack =A0 =A0 =A0 =3D hlwd_pic_mask_and_ack,
> + =A0 =A0 =A0 .mask =A0 =A0 =A0 =A0 =A0 =3D hlwd_pic_mask,
> + =A0 =A0 =A0 .unmask =A0 =A0 =A0 =A0 =3D hlwd_pic_unmask,
> +};
> +
> +/*
> + * IRQ host hooks.
> + *
> + */
> +
> +static struct irq_host *hlwd_irq_host;
> +
> +static int hlwd_pic_map(struct irq_host *h, unsigned int virq,
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0irq_hw_number_t hwir=
q)
> +{
> + =A0 =A0 =A0 set_irq_chip_data(virq, h->host_data);
> + =A0 =A0 =A0 get_irq_desc(virq)->status |=3D IRQ_LEVEL;
> + =A0 =A0 =A0 set_irq_chip_and_handler(virq, &hlwd_pic, handle_level_irq)=
;
> + =A0 =A0 =A0 return 0;
> +}
> +
> +static void hlwd_pic_unmap(struct irq_host *h, unsigned int irq)
> +{
> + =A0 =A0 =A0 set_irq_chip_data(irq, NULL);
> + =A0 =A0 =A0 set_irq_chip(irq, NULL);
> +}
> +
> +static struct irq_host_ops hlwd_irq_host_ops =3D {
> + =A0 =A0 =A0 .map =3D hlwd_pic_map,
> + =A0 =A0 =A0 .unmap =3D hlwd_pic_unmap,
> +};
> +
> +static unsigned int __hlwd_pic_get_irq(struct irq_host *h)
> +{
> + =A0 =A0 =A0 void __iomem *io_base =3D h->host_data;
> + =A0 =A0 =A0 int irq;
> + =A0 =A0 =A0 u32 irq_status;
> +
> + =A0 =A0 =A0 irq_status =3D in_be32(io_base + HW_BROADWAY_ICR) &
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0in_be32(io_base + HW_BROADWAY_IM=
R);
> + =A0 =A0 =A0 if (irq_status =3D=3D 0)
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 return NO_IRQ_IGNORE; =A0 /* no more IRQs p=
ending */
> +
> + =A0 =A0 =A0 __asm__ __volatile__("cntlzw %0,%1" : "=3Dr"(irq) : "r"(irq=
_status));
> + =A0 =A0 =A0 return irq_linear_revmap(h, 31 - irq);
> +}
> +
> +static void hlwd_pic_irq_cascade(unsigned int cascade_virq,
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=
struct irq_desc *desc)
> +{
> + =A0 =A0 =A0 struct irq_host *irq_host =3D get_irq_data(cascade_virq);
> + =A0 =A0 =A0 unsigned int virq;
> +
> + =A0 =A0 =A0 spin_lock(&desc->lock);
> + =A0 =A0 =A0 desc->chip->mask(cascade_virq); /* IRQ_LEVEL */
> + =A0 =A0 =A0 spin_unlock(&desc->lock);
> +
> + =A0 =A0 =A0 virq =3D __hlwd_pic_get_irq(irq_host);
> + =A0 =A0 =A0 if (virq !=3D NO_IRQ_IGNORE)
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 generic_handle_irq(virq);
> + =A0 =A0 =A0 else
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 pr_err("spurious interrupt!\n");
> +
> + =A0 =A0 =A0 spin_lock(&desc->lock);
> + =A0 =A0 =A0 desc->chip->ack(cascade_virq); /* IRQ_LEVEL */
> + =A0 =A0 =A0 if (!(desc->status & IRQ_DISABLED) && desc->chip->unmask)
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 desc->chip->unmask(cascade_virq);
> + =A0 =A0 =A0 spin_unlock(&desc->lock);
> +}
> +
> +/*
> + * Platform hooks.
> + *
> + */
> +
> +static void __hlwd_quiesce(void __iomem *io_base)
> +{
> + =A0 =A0 =A0 /* mask and ack all IRQs */
> + =A0 =A0 =A0 out_be32(io_base + HW_BROADWAY_IMR, 0);
> + =A0 =A0 =A0 out_be32(io_base + HW_BROADWAY_ICR, ~0);
> +}
> +
> +struct irq_host *hlwd_pic_init(struct device_node *np)
> +{
> + =A0 =A0 =A0 struct irq_host *irq_host;
> + =A0 =A0 =A0 struct resource res;
> + =A0 =A0 =A0 void __iomem *io_base;
> + =A0 =A0 =A0 int retval;
> +
> + =A0 =A0 =A0 retval =3D of_address_to_resource(np, 0, &res);
> + =A0 =A0 =A0 if (retval) {
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 pr_err("no io memory range found\n");
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 return NULL;
> + =A0 =A0 =A0 }
> + =A0 =A0 =A0 io_base =3D ioremap(res.start, resource_size(&res));
> + =A0 =A0 =A0 if (!io_base) {
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 pr_err("ioremap failed\n");
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 return NULL;
> + =A0 =A0 =A0 }
> +
> + =A0 =A0 =A0 pr_info("controller at 0x%08x mapped to 0x%p\n", res.start,=
io_base);
> +
> + =A0 =A0 =A0 __hlwd_quiesce(io_base);
> +
> + =A0 =A0 =A0 irq_host =3D irq_alloc_host(np, IRQ_HOST_MAP_LINEAR, HLWD_N=
R_IRQS,
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 &hlwd_i=
rq_host_ops, NO_IRQ_IGNORE);
> + =A0 =A0 =A0 if (!irq_host) {
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 pr_err("failed to allocate irq_host\n");
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 return NULL;
> + =A0 =A0 =A0 }
> + =A0 =A0 =A0 irq_host->host_data =3D io_base;
> +
> + =A0 =A0 =A0 return irq_host;
> +}
> +
> +unsigned int hlwd_pic_get_irq(void)
> +{
> + =A0 =A0 =A0 return __hlwd_pic_get_irq(hlwd_irq_host);
> +}
> +
> +/*
> + * Probe function.
> + *
> + */
> +
> +void hlwd_pic_probe(void)
> +{
> + =A0 =A0 =A0 struct irq_host *host;
> + =A0 =A0 =A0 struct device_node *np;
> + =A0 =A0 =A0 const u32 *interrupts;
> + =A0 =A0 =A0 int cascade_virq;
> +
> + =A0 =A0 =A0 for_each_compatible_node(np, NULL, "nintendo,hollywood-pic"=
) {
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 interrupts =3D of_get_property(np, "interru=
pts", NULL);
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 if (interrupts) {
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 host =3D hlwd_pic_init(np);
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 BUG_ON(!host);
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 cascade_virq =3D irq_of_par=
se_and_map(np, 0);
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 set_irq_data(cascade_virq, =
host);
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 set_irq_chained_handler(cas=
cade_virq,
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=
=A0 =A0 =A0 =A0 =A0 hlwd_pic_irq_cascade);
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 }
> + =A0 =A0 =A0 }
> +}
> +
> +/**
> + * hlwd_quiesce() - quiesce hollywood irq controller
> + *
> + * Mask and ack all interrupt sources.
> + *
> + */
> +void hlwd_quiesce(void)
> +{
> + =A0 =A0 =A0 void __iomem *io_base =3D hlwd_irq_host->host_data;
> +
> + =A0 =A0 =A0 __hlwd_quiesce(io_base);
> +}
> +
> diff --git a/arch/powerpc/platforms/embedded6xx/hlwd-pic.h b/arch/powerpc=
/platforms/embedded6xx/hlwd-pic.h
> new file mode 100644
> index 0000000..d2e5a09
> --- /dev/null
> +++ b/arch/powerpc/platforms/embedded6xx/hlwd-pic.h
> @@ -0,0 +1,22 @@
> +/*
> + * arch/powerpc/platforms/embedded6xx/hlwd-pic.h
> + *
> + * Nintendo Wii "Hollywood" interrupt controller support.
> + * Copyright (C) 2009 The GameCube Linux Team
> + * Copyright (C) 2009 Albert Herranz
> + *
> + * 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.
> + *
> + */
> +
> +#ifndef __HLWD_PIC_H
> +#define __HLWD_PIC_H
> +
> +extern unsigned int hlwd_pic_get_irq(void);
> +extern void hlwd_pic_probe(void);
> +extern void hlwd_quiesce(void);
> +
> +#endif
> --
> 1.6.3.3
>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev
>
--=20
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: [RFC PATCH 18/19] powerpc: wii: platform support
From: Grant Likely @ 2009-11-22 23:45 UTC (permalink / raw)
To: Albert Herranz; +Cc: linuxppc-dev
In-Reply-To: <1258927311-4340-19-git-send-email-albert_herranz@yahoo.es>
On Sun, Nov 22, 2009 at 3:01 PM, Albert Herranz <albert_herranz@yahoo.es> w=
rote:
> Add platform support for the Nintendo Wii video game console.
>
> Signed-off-by: Albert Herranz <albert_herranz@yahoo.es>
> ---
> +static int wii_setup_hw_resets(void)
> +{
> + =A0 =A0 =A0 struct device_node *np;
> + =A0 =A0 =A0 struct resource res;
> + =A0 =A0 =A0 int error =3D -ENODEV;
> +
> + =A0 =A0 =A0 np =3D of_find_compatible_node(NULL, NULL, HW_RESETS_OF_COM=
PATIBLE);
> + =A0 =A0 =A0 if (!np) {
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 pr_err("no compatible node found for %s\n",
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0HW_RESETS_OF_COMPATIBLE);
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 goto out;
> + =A0 =A0 =A0 }
> + =A0 =A0 =A0 error =3D of_address_to_resource(np, 0, &res);
> + =A0 =A0 =A0 if (error) {
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 pr_err("no valid reg found for %s\n", np->n=
ame);
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 goto out_put;
> + =A0 =A0 =A0 }
> +
> + =A0 =A0 =A0 hw_resets =3D ioremap(res.start, res.end - res.start + 1);
Or you could use of_iomap() to cut out some code.
> + =A0 =A0 =A0 if (hw_resets) {
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 pr_info("hw_resets at 0x%08x mapped to 0x%p=
\n",
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 res.start, hw_resets);
> + =A0 =A0 =A0 }
> +
> +out_put:
> + =A0 =A0 =A0 of_node_put(np);
> +out:
> + =A0 =A0 =A0 return error;
> +}
> +
> +static int wii_setup_hw_gpio(void)
> +{
> + =A0 =A0 =A0 struct device_node *np;
> + =A0 =A0 =A0 struct resource res;
> + =A0 =A0 =A0 const char *path;
> + =A0 =A0 =A0 int error =3D -ENODEV;
> +
> + =A0 =A0 =A0 np =3D of_find_node_by_name(NULL, "aliases");
> + =A0 =A0 =A0 if (!np) {
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 pr_err("unable to find node %s\n", "aliases=
");
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 goto out;
> + =A0 =A0 =A0 }
> +
> + =A0 =A0 =A0 path =3D of_get_property(np, HW_GPIO_ALIAS, NULL);
> + =A0 =A0 =A0 of_node_put(np);
> + =A0 =A0 =A0 if (!path) {
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 pr_err("alias %s unknown\n", HW_GPIO_ALIAS)=
;
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 goto out;
> + =A0 =A0 =A0 }
> +
> + =A0 =A0 =A0 np =3D of_find_node_by_path(path);
> + =A0 =A0 =A0 if (!np) {
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 pr_err("node for alias %s unknown\n", HW_GP=
IO_ALIAS);
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 goto out;
> + =A0 =A0 =A0 }
> + =A0 =A0 =A0 error =3D of_address_to_resource(np, 0, &res);
> + =A0 =A0 =A0 if (error) {
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 pr_err("no valid reg found for %s\n", np->n=
ame);
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 goto out_put;
> + =A0 =A0 =A0 }
> +
> + =A0 =A0 =A0 hw_gpio =3D ioremap(res.start, res.end - res.start + 1);
> + =A0 =A0 =A0 if (hw_gpio) {
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 pr_info("hw_gpio at 0x%08x mapped to 0x%p\n=
",
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 res.start, hw_gpio);
> + =A0 =A0 =A0 }
> +
> +out_put:
> + =A0 =A0 =A0 of_node_put(np);
> +out:
> + =A0 =A0 =A0 return error;
> +}
> +
> +static void wii_setup(void)
> +{
> + =A0 =A0 =A0 wii_setup_hw_resets();
> + =A0 =A0 =A0 wii_setup_hw_gpio();
> +}
> +
> +static void wii_restart(char *cmd)
> +{
> + =A0 =A0 =A0 local_irq_disable();
> +
> + =A0 =A0 =A0 if (hw_resets) {
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 /* clear the system reset pin to cause a re=
set */
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 clear_bit(0, hw_resets);
> + =A0 =A0 =A0 }
> + =A0 =A0 =A0 wii_spin();
> +}
> +
> +static void wii_power_off(void)
> +{
> + =A0 =A0 =A0 local_irq_disable();
> +
> + =A0 =A0 =A0 if (hw_gpio) {
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 /* make sure that the poweroff GPIO is conf=
igured as output */
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 out_be32(hw_gpio + HW_GPIO_DIR,
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0in_be32(hw_gpio + HW_GPI=
O_DIR) | HW_GPIO_SHUTDOWN);
> +
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 /* drive the poweroff GPIO high */
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 out_be32(hw_gpio + HW_GPIO_OUT,
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0in_be32(hw_gpio + HW_GPI=
O_OUT) | HW_GPIO_SHUTDOWN);
> + =A0 =A0 =A0 }
> + =A0 =A0 =A0 wii_spin();
> +}
> +
> +#else
> +
> +static void wii_setup(void)
> +{
> +}
> +
> +static void wii_restart(char *cmd)
> +{
> + =A0 =A0 =A0 wii_spin();
> +}
> +
> +static void wii_power_off(void)
> +{
> + =A0 =A0 =A0 wii_spin();
> +}
> +
> +#endif /* CONFIG_STARLET_MINI */
> +
> +static void wii_halt(void)
> +{
> + =A0 =A0 =A0 if (ppc_md.restart)
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 ppc_md.restart(NULL);
> + =A0 =A0 =A0 wii_spin();
> +}
> +
> +static void wii_show_cpuinfo(struct seq_file *m)
> +{
> + =A0 =A0 =A0 seq_printf(m, "vendor\t\t: IBM\n");
> + =A0 =A0 =A0 seq_printf(m, "machine\t\t: Nintendo Wii\n");
> +}
Drop show_cpuinfo() hook.
> +static int wii_discover_ipc_flavour(void)
> +{
> + =A0 =A0 =A0 struct mipc_infohdr *hdrp;
> + =A0 =A0 =A0 int error;
> +
> + =A0 =A0 =A0 error =3D mipc_infohdr_get(&hdrp);
> + =A0 =A0 =A0 if (!error) {
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 mipc_infohdr_put(hdrp);
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 starlet_ipc_flavour =3D STARLET_IPC_MINI;
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 wii_setup();
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 ppc_md.restart =3D wii_restart;
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 ppc_md.power_off =3D wii_power_off;
> + =A0 =A0 =A0 }
> +
> + =A0 =A0 =A0 return 0;
> +}
> +
> +static void __init wii_setup_arch(void)
> +{
> + =A0 =A0 =A0 ug_udbg_init();
> + =A0 =A0 =A0 wii_discover_ipc_flavour();
> +}
> +
> +static void __init wii_init_early(void)
> +{
> +}
> +
> +static int __init wii_probe(void)
> +{
> + =A0 =A0 =A0 unsigned long dt_root;
> +
> + =A0 =A0 =A0 dt_root =3D of_get_flat_dt_root();
> + =A0 =A0 =A0 if (!of_flat_dt_is_compatible(dt_root, "nintendo,wii"))
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 return 0;
> +
> + =A0 =A0 =A0 return 1;
> +}
> +
> +static void wii_shutdown(void)
> +{
> + =A0 =A0 =A0 flipper_quiesce();
> +}
> +
> +#ifdef CONFIG_KEXEC
> +static int wii_machine_kexec_prepare(struct kimage *image)
> +{
> + =A0 =A0 =A0 return 0;
> +}
> +
> +static void wii_machine_kexec(struct kimage *image)
> +{
> + =A0 =A0 =A0 default_machine_kexec(image);
> +}
Drop unnecessary hooks. If no kexec hook it offered, then
default_machine_kexec() gets called anyway.
> +#endif /* CONFIG_KEXEC */
> +
> +define_machine(wii) {
> + =A0 =A0 =A0 .name =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =3D "wii",
> + =A0 =A0 =A0 .probe =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=3D wii_probe,
> + =A0 =A0 =A0 .setup_arch =A0 =A0 =A0 =A0 =A0 =A0 =3D wii_setup_arch,
> + =A0 =A0 =A0 .init_early =A0 =A0 =A0 =A0 =A0 =A0 =3D wii_init_early,
> + =A0 =A0 =A0 .show_cpuinfo =A0 =A0 =A0 =A0 =A0 =3D wii_show_cpuinfo,
> + =A0 =A0 =A0 .halt =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =3D wii_halt,
> + =A0 =A0 =A0 .init_IRQ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =3D flipper_pic_probe=
,
> + =A0 =A0 =A0 .get_irq =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=3D flipper_pic_get=
_irq,
> + =A0 =A0 =A0 .calibrate_decr =A0 =A0 =A0 =A0 =3D generic_calibrate_decr,
> + =A0 =A0 =A0 .progress =A0 =A0 =A0 =A0 =A0 =A0 =A0 =3D udbg_progress,
> + =A0 =A0 =A0 .machine_shutdown =A0 =A0 =A0 =3D wii_shutdown,
> +#ifdef CONFIG_KEXEC
> + =A0 =A0 =A0 .machine_kexec_prepare =A0=3D wii_machine_kexec_prepare,
> + =A0 =A0 =A0 .machine_kexec =A0 =A0 =A0 =A0 =A0=3D wii_machine_kexec,
> +#endif
> +};
> +
> diff --git a/arch/powerpc/platforms/embedded6xx/wii_dev.c b/arch/powerpc/=
platforms/embedded6xx/wii_dev.c
> new file mode 100644
> index 0000000..903063e
> --- /dev/null
> +++ b/arch/powerpc/platforms/embedded6xx/wii_dev.c
> @@ -0,0 +1,47 @@
> +/*
> + * arch/powerpc/platforms/embedded6xx/wii_dev.c
> + *
> + * Nintendo Wii platform device setup.
> + * Copyright (C) 2008-2009 The GameCube Linux Team
> + * Copyright (C) 2008,2009 Albert Herranz
> + *
> + * 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/kernel.h>
> +#include <linux/init.h>
> +#include <linux/of_platform.h>
> +
> +#include <asm/machdep.h>
> +
> +static struct of_device_id wii_of_bus[] =3D {
> + =A0 =A0 =A0 { .compatible =3D "nintendo,hollywood", },
> +#ifdef CONFIG_STARLET_MINI
> + =A0 =A0 =A0 { .compatible =3D "twiizers,starlet-mini-ipc", },
> +#endif
> + =A0 =A0 =A0 { },
> +};
> +
> +static int __init wii_device_probe(void)
> +{
> + =A0 =A0 =A0 struct device_node *np;
> +
> + =A0 =A0 =A0 if (!machine_is(wii))
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 return 0;
> +
> + =A0 =A0 =A0 of_platform_bus_probe(NULL, wii_of_bus, NULL);
> +
> + =A0 =A0 =A0 np =3D of_find_compatible_node(NULL, NULL, "nintendo,hollyw=
ood-mem2");
> + =A0 =A0 =A0 if (np) {
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 of_platform_device_create(np, NULL, NULL);
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 of_node_put(np);
> + =A0 =A0 =A0 }
> +
> + =A0 =A0 =A0 return 0;
> +}
> +device_initcall(wii_device_probe);
Why is this split into a separate file? (Same comment goes for the
Gamecube version). Just roll all the platform support into a single
file since there is no shared code.
g.
--=20
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: DTS for PowerPC 440 based board
From: Grant Likely @ 2009-11-23 3:32 UTC (permalink / raw)
To: David Gibson; +Cc: linuxppc-dev, Vinayak Kale
In-Reply-To: <20091121212047.GA29715@yookeroo>
On Sat, Nov 21, 2009 at 2:20 PM, David Gibson
<david@gibson.dropbear.id.au> wrote:
> On Sun, Nov 22, 2009 at 12:16:59AM +0530, Vinayak Kale wrote:
>> 2) If uboot passes BDInfo struct to kernel instead of DT blob, then in t=
his
>> case does kernel creates FDT at run time?
>
> Not exactly. =A0In this case the bootwrapper will be built with an FDT
> (compiled from a dts) built in. =A0It will however tweak the FDT with
> information from the BDInfo before booting the kernel proper.
...but if you have any sort of choice, save yourself some trouble and
enable FDT support in u-boot. Then you don't need to muck about with
problematic bd_info structures.
g.
--=20
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: [RFC PATCH 00/19] powerpc: nintendo gamecube and wii support
From: Wolfram Sang @ 2009-11-23 5:13 UTC (permalink / raw)
To: Albert Herranz; +Cc: linuxppc-dev
In-Reply-To: <1258927311-4340-1-git-send-email-albert_herranz@yahoo.es>
[-- Attachment #1: Type: text/plain, Size: 367 bytes --]
On Sun, Nov 22, 2009 at 11:01:31PM +0100, Albert Herranz wrote:
> The following patches add the base support for the Nintendo GameCube
> and Wii video game consoles on the powerpc arch.
Cool stuff! \o/
--
Pengutronix e.K. | Wolfram Sang |
Industrial Linux Solutions | http://www.pengutronix.de/ |
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: Fwd: Re: DTS for PowerPC 440 based board
From: vinayak.kale @ 2009-11-23 7:29 UTC (permalink / raw)
To: david, grant.likely, Vinayak Kale; +Cc: linuxppc-dev
In-Reply-To: <001636832accdcc8a40479024c96@google.com>
[-- Attachment #1: Type: text/plain, Size: 3191 bytes --]
Hi,
David, Grant thank you for providing the info.
From your reply and the other sources what I gather is as below. Please
confirm whether I am on the right track.
1) Bootloader passing BDInfo:
Here, I have to create a .dts file inside /arch/powerpc/boot/dts directory.
dtc compiles the .dts file and creates a dtb. The kernel, dtb and
boot-wrapper are then embedded in a cuImage.* file after make. We need to
write the platform-specific fix-ups in the cuboot-*.c file. The bootloader
will pass BDInfo struct to kernel. The kernel will also receive the dtb.
The only kernel changes we need to do here are fixups in cuboot-*.c and
creation of .dts file.
2) Bootloader passing DT:
Here, the booloader will directly pass the DT instead of BDInfo. The
platform-specific code in simpleboot.c will get excuted. We don't have to
do any fixups inside kernel here.
I have queries with this approach -
a) In this case, who creates DT? Do we need to use any tools to create a
DT? or it can be created the same way by compiling the .dts file using dtc?
b) From previous implementaions of other boards, I didn't see any platform
specific fix-ups inside kernel being done? Why is so that in case of BDInfo
we need fix-ups and here we don't?
Please confirm my understanding of above to approaches. Also please suggest
which way is better.
Regards,
Vinayak
----------------------------------------------------------------------------------------------------
From: David Gibson <david@gibson.dropbear.id.au>
Date: Sun, Nov 22, 2009 at 2:50 AM
Subject: Re: DTS for PowerPC 440 based board
To: Vinayak Kale <vinayak.kale@gmail.com>
Cc: linuxppc-dev@lists.ozlabs.org
On Sun, Nov 22, 2009 at 12:16:59AM +0530, Vinayak Kale wrote:
> Hi,
> I am porting 2.6.31 for a PowerPC 440 core based board. I have couple of
> queries. I would really appreciate if someone could answer since i
> couldn't
> find info from other places.
> 1) Is it mandatory to create a DTS file?
Roughly speaking, yes. You have to supply a device tree to the
kernel somehow, so if the firmware doesn't supply one itself, you will
need to create a DTS.
> 2) If uboot passes BDInfo struct to kernel instead of DT blob, then in
> this
> case does kernel creates FDT at run time?
Not exactly. In this case the bootwrapper will be built with an FDT
(compiled from a dts) built in. It will however tweak the FDT with
information from the BDInfo before booting the kernel proper.
> 3) I believe in case of DTS, the kernel picks up the h/w info from DTS
> blob
> so we need not hardcode any register addresses etc inside kernel other
> than
> in dts file. What happens in case of uboot passing just BDInfo struct. How
> do we specify the register addresses etc?
There's always a device tree which specifies register addresses. If
the firmware only supplies a BDInfo, then the kernel wrapper must have
a device tree built in. In practice that will always be built from a
dts, though it doesn't have to be in theory.
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
[-- Attachment #2: Type: text/html, Size: 3769 bytes --]
^ permalink raw reply
* Re: [PATCH] ppc440spe-adma: adds updated ppc440spe adma driver
From: Anatolij Gustschin @ 2009-11-23 10:23 UTC (permalink / raw)
To: Josh Boyer; +Cc: linux-raid, linuxppc-dev, dan.j.williams, wd, dzu
In-Reply-To: <20091120130026.GS30489@zod.rchland.ibm.com>
On Fri, 20 Nov 2009 08:00:26 -0500
Josh Boyer <jwboyer@linux.vnet.ibm.com> wrote:
> On Tue, Nov 17, 2009 at 03:17:05PM +0100, Anatolij Gustschin wrote:
> >This patch adds new version of the PPC440SPe ADMA driver.
> >
> >Signed-off-by: Anatolij Gustschin <agust@denx.de>
>
> The driver author is listed as Yuri Tikhonov <yur@emcraft.com>. Shouldn't
> this include a sign-off from Yuri, or perhaps even a From?
Yuri is the author of the previous driver version but he didn't
have time to rework the driver and prepare it for submission.
I will CC him and ask for his sign-off when submitting next
patch version.
> >Before applying this patch the following patch to katmai.dts
> >should be applied first: http://patchwork.ozlabs.org/patch/36768/
>
> For the linux-raid people's benefit, I have that patch queued up in my next
> branch.
Thanks!
> > arch/powerpc/include/asm/async_tx.h | 47 +
> > arch/powerpc/include/asm/ppc440spe_adma.h | 195 +
> > arch/powerpc/include/asm/ppc440spe_dma.h | 224 +
> > arch/powerpc/include/asm/ppc440spe_xor.h | 110 +
>
> Why are these header files in the asm directory? They seem to be only used
> by your new driver, so why not have them under the drivers/dma or if you want
> to be neat, drivers/dma/ppc440spe/ dirs? I really don't think they should
> be in asm at all.
async_tx layer expects async_tx.h to be in the asm directory if
the architecture provides async_tx_find_channel(). I will move
other header files and the driver file to drivers/dma/ppc440spe/
directory.
> >diff --git a/arch/powerpc/include/asm/dcr-regs.h b/arch/powerpc/include/asm/dcr-regs.h
> >index 828e3aa..67d4069 100644
> >--- a/arch/powerpc/include/asm/dcr-regs.h
> >+++ b/arch/powerpc/include/asm/dcr-regs.h
> >@@ -157,4 +157,30 @@
> > #define L2C_SNP_SSR_32G 0x0000f000
> > #define L2C_SNP_ESR 0x00000800
> >
> >+#define DCRN_SDR_CONFIG_ADDR 0xe
> >+#define DCRN_SDR_CONFIG_DATA 0xf
>
> These #defines already exist as DCRN_SDR0_CONFIG_{ADDR,DATA}. We don't need
> them defined again.
OK, I'll remove them.
<snip>
> >+ * Common initialisation for RAID engines; allocate memory for
> >+ * DMAx FIFOs, perform configuration common for all DMA engines.
> >+ * Further DMA engine specific configuration is done at probe time.
> >+ */
> >+static int ppc440spe_configure_raid_devices(void)
> >+{
> >+ struct device_node *np;
> >+ struct resource i2o_res;
> >+ i2o_regs_t __iomem *i2o_reg;
> >+ const u32 *dcrreg;
> >+ u32 dcrbase_i2o;
> >+ int i, len, ret;
> >+
> >+ np = of_find_compatible_node(NULL, NULL, "ibm,i2o-440spe");
> >+ if (!np) {
> >+ pr_err("%s: can't find I2O device tree node\n",
> >+ __func__);
> >+ return -ENODEV;
> >+ }
> >+
> >+ if (of_address_to_resource(np, 0, &i2o_res)) {
> >+ of_node_put(np);
> >+ return -EINVAL;
> >+ }
> >+
> >+ i2o_reg = of_iomap(np, 0);
> >+ if (!i2o_reg) {
> >+ pr_err("%s: failed to map I2O registers\n", __func__);
> >+ of_node_put(np);
> >+ return -EINVAL;
> >+ }
> >+
> >+ /* Get I2O DCRs base */
> >+ dcrreg = of_get_property(np, "dcr-reg", &len);
> >+ if (!dcrreg || (len != 2 * sizeof(u32))) {
> >+ pr_err("%s: can't get DCR register base!\n",
> >+ np->full_name);
> >+ of_node_put(np);
> >+ iounmap(i2o_reg);
> >+ return -ENODEV;
> >+ }
> >+ of_node_put(np);
> >+ dcrbase_i2o = dcrreg[0];
> >+
> >+ /* Provide memory regions for DMA's FIFOs: I2O, DMA0 and DMA1 share
> >+ * the base address of FIFO memory space.
> >+ * Actually we need twice more physical memory than programmed in the
> >+ * <fsiz> register (because there are two FIFOs for each DMA: CP and CS)
> >+ */
> >+ ppc440spe_dma_fifo_buf = kmalloc((DMA0_FIFO_SIZE + DMA1_FIFO_SIZE) << 1,
> >+ GFP_KERNEL);
> >+ if (!ppc440spe_dma_fifo_buf) {
> >+ pr_err("%s: DMA FIFO buffer allocation failed.\n", __func__);
> >+ iounmap(i2o_reg);
> >+ return -ENOMEM;
> >+ }
> >+v
> >+ /*
> >+ * Configure h/w
> >+ */
> >+ /* Reset I2O/DMA */
> >+ mtdcri(SDR, DCRN_SDR0_SRST, DCRN_SDR0_SRST_I2ODMA);
> >+ mtdcri(SDR, DCRN_SDR0_SRST, 0);
> >+
> >+ /* Setup the base address of mmaped registers */
> >+ mtdcr(dcrbase_i2o + DCRN_I2O0_IBAH, (u32)(i2o_res.start >> 32));
> >+ mtdcr(dcrbase_i2o + DCRN_I2O0_IBAL, (u32)(i2o_res.start) |
> >+ I2O_REG_ENABLE);
>
> It would be cleaner if you used the dcr_read/dcr_write functions instead
> of the open coded mtdcr/mfdcr. I don't think it's required though.
>
> >+
> >+ /* Setup FIFO memory space base address */
> >+ out_le32(&i2o_reg->ifbah, 0);
> >+ out_le32(&i2o_reg->ifbal, ((u32)__pa(ppc440spe_dma_fifo_buf)));
>
> Similarly ioread32/iowrite32 instead of {out,in}_.
OK, I'll fix this.
Thanks!
Anatolij
^ permalink raw reply
* [RESEND] [PATCH] Fix wrong error code from ppc32 select syscall
From: Josh Boyer @ 2009-11-23 13:25 UTC (permalink / raw)
To: benh; +Cc: linuxppc-dev, paulus, arnd
From: Arnd Bergmann <arnd@arndb.de>, Paul Mackerras <paulus@samba.org>
This patch was submitted, discussed, and eventually Acked by everyone, yet
still isn't in the tree. See:
http://patchwork.ozlabs.org/patch/1240/
Signed-off-by: Josh Boyer <jwboyer@linux.vnet.ibm.com>
Cc: Arnd Bergmann <arnd@anrdb.de>
Cc: Paul Mackerras <paulus@samba.org>
---
diff --git a/arch/powerpc/include/asm/systbl.h b/arch/powerpc/include/asm/systbl
index c7d671a..07d2d19 100644
--- a/arch/powerpc/include/asm/systbl.h
+++ b/arch/powerpc/include/asm/systbl.h
@@ -145,7 +145,7 @@ SYSCALL_SPU(setfsuid)
SYSCALL_SPU(setfsgid)
SYSCALL_SPU(llseek)
COMPAT_SYS_SPU(getdents)
-SYSX_SPU(sys_select,ppc32_select,ppc_select)
+SYSX_SPU(sys_select,ppc32_select,sys_select)
SYSCALL_SPU(flock)
SYSCALL_SPU(msync)
COMPAT_SYS_SPU(readv)
^ permalink raw reply related
* Re: [microblaze-uclinux] Re: [PATCH 0/4 v2] Merge OF dynamic patches
From: Michal Simek @ 2009-11-23 13:27 UTC (permalink / raw)
To: microblaze-uclinux; +Cc: devicetree-discuss, linuxppc-dev
In-Reply-To: <fa686aa40911201340i77bc4098ud866d103acaefd30@mail.gmail.com>
Grant Likely wrote:
> On Fri, Nov 20, 2009 at 8:01 AM, Nathan Fontenot <nfont@austin.ibm.com> wrote:
>> This set of patches merges the common dynamic device tree
>> updating routines of_attach_node() and of_detach_node() to
>> drivers/of/of_dynamic.c.
>>
>> Built and tested on powerpc, I have no access to build/test
>> this on microblaze.
>
> Heh. Actually, I've got a patch in my tree that does the same thing
> (except to a different location). I could pick up your version and
> drop mine, but you need to rework it to be bi-sectable. As the series
> exists right now, the build will fail if only part of the series is
> applied. This change is simple enough that you can do the whole thing
> in a single patch. Or, fix the Kconfig and include stuff in the first
> patch with the merge of of_attach_node, and then move of_detach_node
> in the second.
>
> But I'm really close to posting my 3rd series, so it may be better to
> wait until that is published and build a patch on top of that to move
> them into of_dynamic.c
ACK.
Michal
>
> Cheers,
> g.
>
>> ---
>>
>> 1/4 - Merge of_attach_node
>> 2/4 - Merge of_detach_node
>> 3/4 - Makefile/Kconfig updates
>> 4/4 - Update powerpc/pseries to include of_dynamic.h
>>
>> arch/microblaze/Kconfig | 1
>> arch/microblaze/include/asm/prom.h | 4 -
>> arch/microblaze/kernel/prom.c | 59 -----------------------
>> arch/powerpc/Kconfig | 1
>> arch/powerpc/include/asm/prom.h | 4 -
>> arch/powerpc/kernel/prom.c | 59 -----------------------
>> arch/powerpc/platforms/pseries/reconfig.c | 1 drivers/of/Kconfig
>> | 4 +
>> drivers/of/Makefile | 1 drivers/of/of_dynamic.c
>> | 75 ++++++++++++++++++++++++++++++
>> include/linux/of_dynamic.h | 27 ++++++++++
>> 11 files changed, 110 insertions(+), 126 deletions(-)
>>
>
>
>
--
Michal Simek, Ing. (M.Eng)
PetaLogix - Linux Solutions for a Reconfigurable World
w: www.petalogix.com p: +61-7-30090663,+42-0-721842854 f: +61-7-30090663
^ permalink raw reply
* Re: [PATCH 1/3] eLBC NAND: increase bus timeout to maximum
From: Artem Bityutskiy @ 2009-11-23 14:36 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev, dwmw2, linux-mtd
In-Reply-To: <20091113201216.GA8313@loki.buserror.net>
On Fri, 2009-11-13 at 14:12 -0600, Scott Wood wrote:
> When a NAND operation is in progress, all other localbus operations
> (including NOR flash) will have to wait for access to the bus. However, the
> NAND operation may take longer to complete than the default timeout. Thus,
> if NOR is accessed while a NAND operation is in progress, the NAND operation
> will fail.
>
> Signed-off-by: Scott Wood <scottwood@freescale.com>
Taken the patches to my l2-mtd-2.6 tree.
--
Best Regards,
Artem Bityutskiy (Артём Битюцкий)
^ permalink raw reply
* Re: [PATCH 0/4 v2] Merge OF dynamic patches
From: Nathan Fontenot @ 2009-11-23 15:38 UTC (permalink / raw)
To: Grant Likely; +Cc: microblaze-uclinux, devicetree-discuss, linuxppc-dev
In-Reply-To: <fa686aa40911201340i77bc4098ud866d103acaefd30@mail.gmail.com>
Grant Likely wrote:
>
> But I'm really close to posting my 3rd series, so it may be better to
> wait until that is published and build a patch on top of that to move
> them into of_dynamic.c
>
Works for me.
-Nathan Fontenot
^ permalink raw reply
* Re: DMA to User-Space
From: Sergey Temerkhanov @ 2009-11-23 17:11 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <BB99A6BA28709744BF22A68E6D7EB51F0330F9DC29@midas.usurf.usu.edu>
On Wednesday 04 November 2009 02:37:38 Jonathan Haws wrote:
> All,
>
> I have what may be an unconventional question:
>
> Our application consists of data being captured by an FPGA, processed, and
> transferred to SDRAM. I simply give the FPGA an address of where I want
> it stored in SDRAM and it simply DMAs the data over and interrupts me when
> finished. I then take that data and store it to disk.
>
> I have code in user space that handles all of the writing to disk nicely
> and fast enough for my application (I am capturing data at about 35-40
> Mbytes/sec).
>
> My question is this: is it possible to give a user-space pointer to the
> FPGA to DMA to? It seems like I would have problems with alignment,
> address manipulation, and a whole slew of other issues.
Well, it's possible: you'll have to use zero-copy I/O. Here's an article on
this subject: http://lwn.net/Articles/28548/.
Have a look at drivers/scsi/st.c at sgl_get_user_pages() or
drivers/infiniband/hw/ipath/ipath_user_pages.c for example of how to use that.
Regards, Sergey Temerkhanov.
^ permalink raw reply
* Re: Fwd: Re: DTS for PowerPC 440 based board
From: Grant Likely @ 2009-11-23 18:11 UTC (permalink / raw)
To: vinayak.kale; +Cc: linuxppc-dev, david
In-Reply-To: <0016e646923c937a80047904c936@google.com>
On Mon, Nov 23, 2009 at 12:29 AM, <vinayak.kale@gmail.com> wrote:
> Hi,
>
> David, Grant thank you for providing the info.
> From your reply and the other sources what I gather is as below. Please
> confirm whether I am on the right track.
>
> 1) Bootloader passing BDInfo:
> Here, I have to create a .dts file inside /arch/powerpc/boot/dts directory.
> dtc compiles the .dts file and creates a dtb. The kernel, dtb and
> boot-wrapper are then embedded in a cuImage.* file after make. We need to
> write the platform-specific fix-ups in the cuboot-*.c file. The bootloader
> will pass BDInfo struct to kernel.
The bootloader will pass bdinfo to the bootwrapper (the cuImage)
> The kernel will also receive the dtb.
The bootwrapper will pass the dtb to the kernel proper. bootloader
knows nothing about the dtb, and the kernel knows nothing about
bdinfo.
> The only kernel changes we need to do here are fixups in cuboot-*.c and
> creation of .dts file.
Correct. But if you're doing a new board and have control over your
bootloader, then don't choose this option. bdinfo structures
> 2) Bootloader passing DT:
> Here, the booloader will directly pass the DT instead of BDInfo. The
> platform-specific code in simpleboot.c will get excuted. We don't have to do
> any fixups inside kernel here.
simpleboot.c doesn't get run at all. In fact, the bootwrapper doesn't
get used at all in this case. The uImage is just the raw compressed
kernel image (vmlinux) with a uImage header on it.
> I have queries with this approach -
> a) In this case, who creates DT? Do we need to use any tools to create a DT?
The .dts file still lives in the kernel tree, and the kernel build
process still compiles it into a .dtb
> or it can be created the same way by compiling the .dts file using dtc?
yes
> b) From previous implementaions of other boards, I didn't see any platform
> specific fix-ups inside kernel being done? Why is so that in case of BDInfo
> we need fix-ups and here we don't?
because bdinfo is a horribly method of passing data to the kernel. So
the bdinfo data needs to be translated into a form the kernel can use
(the device tree). Fixups aren't needed with this approach because
the device tree passed by the bootloader already has all the correct
data in it. U-Boot has the ability to modify the .dtb blob at boot
time to update things like the kernel parameters line and the memory
size if it needs to.
> Please confirm my understanding of above to approaches. Also please suggest
> which way is better.
Pass the device tree from the bootloader. the bootwrapper method is
only to support firmware that cannot pass a device tree image, and
passing bdinfo is non-portable and can cause problems.
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: [PATCH] ppc440spe-adma: adds updated ppc440spe adma driver
From: Dan Williams @ 2009-11-23 18:10 UTC (permalink / raw)
To: Anatolij Gustschin
Cc: linux-raid@vger.kernel.org, linuxppc-dev@ozlabs.org, wd@denx.de,
dzu@denx.de
In-Reply-To: <1258467425-13968-1-git-send-email-agust@denx.de>
Anatolij Gustschin wrote:
> This patch adds new version of the PPC440SPe ADMA driver.
>
> Signed-off-by: Anatolij Gustschin <agust@denx.de>
As Josh said please don't drop attribution tags. If you borrowed from
Yuri's implementation you can forward his signed-off-by.
> ---
> Before applying this patch the following patch to katmai.dts
> should be applied first: http://patchwork.ozlabs.org/patch/36768/
>
> The driver was updated to work with extended async_tx API.
> Comments to previous PPC440SPe ADMA driver versions submitted to
> the linuxppc-dev list were addressed. Please review and consider
> for inclusion. Thanks.
>
> .../powerpc/dts-bindings/4xx/ppc440spe-adma.txt | 93 +
> arch/powerpc/boot/dts/katmai.dts | 52 +-
> arch/powerpc/include/asm/async_tx.h | 47 +
> arch/powerpc/include/asm/dcr-regs.h | 26 +
> arch/powerpc/include/asm/ppc440spe_adma.h | 195 +
> arch/powerpc/include/asm/ppc440spe_dma.h | 224 +
> arch/powerpc/include/asm/ppc440spe_xor.h | 110 +
> drivers/dma/Kconfig | 13 +
> drivers/dma/Makefile | 1 +
> drivers/dma/ppc440spe-adma.c | 4944 ++++++++++++++++++++
> 10 files changed, 5704 insertions(+), 1 deletions(-)
> create mode 100644 Documentation/powerpc/dts-bindings/4xx/ppc440spe-adma.txt
> create mode 100644 arch/powerpc/include/asm/async_tx.h
> create mode 100644 arch/powerpc/include/asm/ppc440spe_adma.h
> create mode 100644 arch/powerpc/include/asm/ppc440spe_dma.h
> create mode 100644 arch/powerpc/include/asm/ppc440spe_xor.h
> create mode 100644 drivers/dma/ppc440spe-adma.c
[..]
> diff --git a/arch/powerpc/include/asm/ppc440spe_dma.h b/arch/powerpc/include/asm/ppc440spe_dma.h
> new file mode 100644
> index 0000000..7cce63e
> --- /dev/null
> +++ b/arch/powerpc/include/asm/ppc440spe_dma.h
[..]
> +/*
> + * DMAx hardware registers (p.515 in 440SPe UM 1.22)
> + */
> +typedef struct {
> + u32 cpfpl;
> + u32 cpfph;
> + u32 csfpl;
> + u32 csfph;
> + u32 dsts;
> + u32 cfg;
> + u8 pad0[0x8];
> + u16 cpfhp;
> + u16 cpftp;
> + u16 csfhp;
> + u16 csftp;
> + u8 pad1[0x8];
> + u32 acpl;
> + u32 acph;
> + u32 s1bpl;
> + u32 s1bph;
> + u32 s2bpl;
> + u32 s2bph;
> + u32 s3bpl;
> + u32 s3bph;
> + u8 pad2[0x10];
> + u32 earl;
> + u32 earh;
> + u8 pad3[0x8];
> + u32 seat;
> + u32 sead;
> + u32 op;
> + u32 fsiz;
> +} dma_regs_t;
> +
> +/*
> + * I2O hardware registers (p.528 in 440SPe UM 1.22)
> + */
> +typedef struct {
> + u32 ists;
> + u32 iseat;
> + u32 isead;
> + u8 pad0[0x14];
> + u32 idbel;
> + u8 pad1[0xc];
> + u32 ihis;
> + u32 ihim;
> + u8 pad2[0x8];
> + u32 ihiq;
> + u32 ihoq;
> + u8 pad3[0x8];
> + u32 iopis;
> + u32 iopim;
> + u32 iopiq;
> + u8 iopoq;
> + u8 pad4[3];
> + u16 iiflh;
> + u16 iiflt;
> + u16 iiplh;
> + u16 iiplt;
> + u16 ioflh;
> + u16 ioflt;
> + u16 ioplh;
> + u16 ioplt;
> + u32 iidc;
> + u32 ictl;
> + u32 ifcpp;
> + u8 pad5[0x4];
> + u16 mfac0;
> + u16 mfac1;
> + u16 mfac2;
> + u16 mfac3;
> + u16 mfac4;
> + u16 mfac5;
> + u16 mfac6;
> + u16 mfac7;
> + u16 ifcfh;
> + u16 ifcht;
> + u8 pad6[0x4];
> + u32 iifmc;
> + u32 iodb;
> + u32 iodbc;
> + u32 ifbal;
> + u32 ifbah;
> + u32 ifsiz;
> + u32 ispd0;
> + u32 ispd1;
> + u32 ispd2;
> + u32 ispd3;
> + u32 ihipl;
> + u32 ihiph;
> + u32 ihopl;
> + u32 ihoph;
> + u32 iiipl;
> + u32 iiiph;
> + u32 iiopl;
> + u32 iioph;
> + u32 ifcpl;
> + u32 ifcph;
> + u8 pad7[0x8];
> + u32 iopt;
> +} i2o_regs_t;
I saw the use of "volatile" in the driver code which lead me back here.
I think it is a reasonable expectation that all drivers use the
accessors in asm/io.h to read/write mmio registers rather than volatile
structure pointers. PPC folks feel free to correct me if this is common
practice for PPC drivers.
A side note, checkpatch rightly says "do not add new typedefs".
[..]
> diff --git a/drivers/dma/Kconfig b/drivers/dma/Kconfig
> index 5903a88..854d594 100644
> --- a/drivers/dma/Kconfig
> +++ b/drivers/dma/Kconfig
> @@ -109,6 +109,19 @@ config SH_DMAE
> help
> Enable support for the Renesas SuperH DMA controllers.
>
> +config AMCC_PPC440SPE_ADMA
> + tristate "AMCC PPC440SPe ADMA support"
> + depends on 440SPe || 440SP
> + select DMA_ENGINE
> + select ASYNC_TX_DMA
The user should have the option to turn off dma support on a per dma
client basis, so please remove "select ASYNC_TX_DMA".
> + select ARCH_HAS_ASYNC_TX_FIND_CHANNEL
> + default y
New options should never default to y (except for backwards
compatibility). This is better left to a defconfig.
> + help
> + Enable support for the AMCC PPC440SPe RAID engines.
> +
> +config ARCH_HAS_ASYNC_TX_FIND_CHANNEL
> + bool
> +
> config DMA_ENGINE
> bool
>
[..]
> diff --git a/drivers/dma/ppc440spe-adma.c b/drivers/dma/ppc440spe-adma.c
> new file mode 100644
> index 0000000..40e5479
> --- /dev/null
> +++ b/drivers/dma/ppc440spe-adma.c
[..]
> +#ifdef ADMA_LL_DEBUG
> +static void print_cb(struct ppc440spe_adma_chan *chan, void *block)
> +{
> + struct dma_cdb *cdb;
> + xor_cb_t *cb;
> + int i;
> +
> + switch (chan->device->id) {
> + case 0:
> + case 1:
> + cdb = block;
> +
> + printk("CDB at %p [%d]:\n"
> + "\t attr 0x%02x opc 0x%02x cnt 0x%08x\n"
> + "\t sg1u 0x%08x sg1l 0x%08x\n"
> + "\t sg2u 0x%08x sg2l 0x%08x\n"
> + "\t sg3u 0x%08x sg3l 0x%08x\n",
> + cdb, chan->device->id,
> + cdb->attr, cdb->opc, le32_to_cpu(cdb->cnt),
> + le32_to_cpu(cdb->sg1u), le32_to_cpu(cdb->sg1l),
> + le32_to_cpu(cdb->sg2u), le32_to_cpu(cdb->sg2l),
> + le32_to_cpu(cdb->sg3u), le32_to_cpu(cdb->sg3l)
Debug ifdefs lead to code that does not get compile coverage and bitrots
until someone later tries to debug. Converting these printk() calls to
pr_debug() gets rid of most, but not all of print_cb(). Perhaps look
into the coh-dma driver's approach of wrapping calls to debug functions
with something like:
#ifdef VERBOSE_DEBUG
#define COH_DBG(x) ({ if (1) x; 0; })
#else
#define COH_DBG(x) ({ if (0) x; 0; })
#endif
Converting to pr_debug or dev_dbg will also make checkpatch happy:
"printk() should include KERN_ facility level".
> + );
> + break;
> + case 2:
> + cb = block;
> +
> + printk("CB at %p [%d]:\n"
> + "\t cbc 0x%08x cbbc 0x%08x cbs 0x%08x\n"
> + "\t cbtah 0x%08x cbtal 0x%08x\n"
> + "\t cblah 0x%08x cblal 0x%08x\n",
> + cb, chan->device->id,
> + cb->cbc, cb->cbbc, cb->cbs,
> + cb->cbtah, cb->cbtal,
> + cb->cblah, cb->cblal);
> + for (i = 0; i < 16; i++) {
> + if (i && !cb->ops[i].h && !cb->ops[i].l)
> + continue;
> + printk("\t ops[%2d]: h 0x%08x l 0x%08x\n",
> + i, cb->ops[i].h, cb->ops[i].l);
> + }
> + break;
> + }
> +}
> +#endif
> +
[..]
> +/******************************************************************************
> + * ADMA channel low-level routines
> + ******************************************************************************/
> +
> +static inline u32
> +ppc440spe_chan_get_current_descriptor(struct ppc440spe_adma_chan *chan);
> +static inline void ppc440spe_chan_append(struct ppc440spe_adma_chan *chan);
sparse says:
drivers/dma/ppc440spe-adma.c:1078:41: error: marked inline, but without
a definition
drivers/dma/ppc440spe-adma.c:1077:38: error: marked inline, but without
a definition
[..]
> +/**
> + * ppc440spe_adma_prep_dma_pqzero_sum - prepare CDB group for
> + * a PQ_ZERO_SUM operation
> + */
> +static struct dma_async_tx_descriptor *ppc440spe_adma_prep_dma_pqzero_sum(
> + struct dma_chan *chan, dma_addr_t *pq, dma_addr_t *src,
> + unsigned int src_cnt, const unsigned char *scf, size_t len,
> + enum sum_check_flags *pqres, unsigned long flags)
> +{
> + struct ppc440spe_adma_chan *ppc440spe_chan;
> + struct ppc440spe_adma_desc_slot *sw_desc, *iter;
> + dma_addr_t pdest, qdest;
> + int slot_cnt, slots_per_op, idst, dst_cnt;
> +
> + ppc440spe_chan = to_ppc440spe_adma_chan(chan);
> +
> + if (flags & DMA_PREP_PQ_DISABLE_P)
> + pdest = 0;
> + else
> + pdest = pq[0];
> +
> + if (flags & DMA_PREP_PQ_DISABLE_Q)
> + qdest = 0;
> + else
> + qdest = pq[1];
> +
> +#ifdef ADMA_LL_DEBUG
> + printk("\n%s(%d):\n\tsrc(coef): ", __func__,
> + ppc440spe_chan->device->id);
> + for (idst = 0; idst < src_cnt; idst++)
> + printk("0x%08x(0x%02x) ", src[idst], scf[idst]);
> +
> + printk("\n\tdst: ");
> + for (idst = 0; idst < 2; idst++)
> + printk("0x%08x ", src[src_cnt+idst]);
> + printk("\n");
> + printk("\n%s: src_cnt %d\n", __func__, src_cnt);
> +#endif
> +
> + /* Always use WXOR for P/Q calculations (two destinations).
> + * Need 1 or 2 extra slots to verify results are zero.
> + */
> + idst = dst_cnt = (pdest && qdest) ? 2 : 1;
> +
> + /* One additional slot per destination to clone P/Q
> + * before calculation (we have to preserve destinations).
> + */
> + slot_cnt = src_cnt + dst_cnt * 2;
> + slots_per_op = 1;
> +
> + spin_lock_bh(&ppc440spe_chan->lock);
> + sw_desc = ppc440spe_adma_alloc_slots(ppc440spe_chan, slot_cnt,
> + slots_per_op);
> + if (sw_desc) {
> + ppc440spe_desc_init_dma01pqzero_sum(sw_desc, dst_cnt, src_cnt);
It looks like you emulate pqzero_sum operations with PAGE_SIZE temporary
buffer. Be sure to check 'len' because users of the api are allowed to
submit > PAGE_SIZE requests.
[..]
> +static void ppc440spe_adma_init_capabilities(struct ppc440spe_adma_device *adev)
[..]
> + if (dma_has_cap(DMA_PQ, adev->common.cap_mask)) {
> + switch (adev->id) {
> + case PPC440SPE_DMA0_ID:
> + adev->common.max_pq = DMA0_FIFO_SIZE /
> + sizeof(dma_cdb_t);
> + break;
> + case PPC440SPE_DMA1_ID:
> + adev->common.max_pq = DMA1_FIFO_SIZE /
> + sizeof(dma_cdb_t);
> + break;
> + case PPC440SPE_XOR_ID:
> + adev->common.max_pq = XOR_MAX_OPS * 3;
> + break;
> + }
> + adev->common.device_prep_dma_pq =
> + ppc440spe_adma_prep_dma_pq;
> + }
> + if (dma_has_cap(DMA_PQ_VAL, adev->common.cap_mask)) {
> + switch (adev->id) {
> + case PPC440SPE_DMA0_ID:
> + adev->common.max_pq = DMA0_FIFO_SIZE /
> + sizeof(dma_cdb_t);
> + break;
> + case PPC440SPE_DMA1_ID:
> + adev->common.max_pq = DMA1_FIFO_SIZE /
> + sizeof(dma_cdb_t);
> + break;
> + }
> + adev->common.device_prep_dma_pq_val =
> + ppc440spe_adma_prep_dma_pqzero_sum;
> + }
Please use dma_set_maxpq() when setting 'max_pq' above to make it clear
whether this driver supports hardware continuation of pq operations.
Otherwise the async_tx api will chop the number of sources it passes for
operations larger than the hardware maximum.
^ permalink raw reply
* Re: RFC: Put printk buffer in video ram
From: Arnd Bergmann @ 2009-11-23 19:03 UTC (permalink / raw)
To: Chris Friesen
Cc: Maxim Levitsky, Frederic Weisbecker, linuxppc-dev, linux-kernel,
Steven Rostedt, Dave Jones, Ingo Molnar, Linus Torvalds,
Andrew Morton, Arjan van de Ven
In-Reply-To: <4B0ADA84.5050300@nortel.com>
On Monday 23 November 2009, Chris Friesen wrote:
> We've had a mechanism sort of like this for quite a while. Hasn't been
> pushed to mainline because it used board-specific hardware and we're
> usually multiple kernel versions behind mainline.
>
> Anyways, a couple things that we've found to be useful are:
> 1) The ability to allocate a chunk of this persistent memory area for a
> special purpose. This allows things like memory-mapped circular buffers
> for per-cpu binary data.
> 2) An API to log just to this persistent area and bypass the normal
> console completely. This can be useful when debugging issues where the
> normal logging paths result in a hang.
Some powerpc machines have a memory-mapped nvram, in which the kernel
can install persistant 'partitions'. Not all of them are memory mapped,
but for those that are (e.g. IBM QS22), your approach sounds perfect.
Arnd <><
^ permalink raw reply
* Re: [RFC PATCH 07/19] powerpc: gamecube/wii: declare as non-coherent platforms
From: Albert Herranz @ 2009-11-23 19:06 UTC (permalink / raw)
To: Arnd Bergmann; +Cc: linuxppc-dev
In-Reply-To: <200911222320.56871.arnd@arndb.de>
Arnd Bergmann wrote:
> On Sunday 22 November 2009, Albert Herranz wrote:
>> config NOT_COHERENT_CACHE
>> bool
>> - depends on 4xx || 8xx || E200 || PPC_MPC512x
>> + depends on 4xx || 8xx || E200 || PPC_MPC512x || GAMECUBE_COMMON
>> default y
>>
>> config CHECK_CACHE_COHERENCY
>> diff --git a/arch/powerpc/platforms/embedded6xx/Kconfig b/arch/powerpc/platforms/embedded6xx/Kconfig
>> index 97a2dbc..31487e4 100644
>> --- a/arch/powerpc/platforms/embedded6xx/Kconfig
>> +++ b/arch/powerpc/platforms/embedded6xx/Kconfig
>> @@ -93,4 +93,5 @@ config MPC10X_STORE_GATHERING
>>
>> config GAMECUBE_COMMON
>> bool
>> + select NOT_COHERENT_CACHE
>
> One of the two (depends and select) is enough. I'd just drop the 'select'
> line here.
>
> Arnd <><
>
Thanks, I'll fix that.
Cheers,
Albert
^ permalink raw reply
* Re: [RFC PATCH 10/19] powerpc: gamecube/wii: early debugging using usbgecko
From: Albert Herranz @ 2009-11-23 19:10 UTC (permalink / raw)
To: Arnd Bergmann; +Cc: linuxppc-dev
In-Reply-To: <200911222327.37949.arnd@arndb.de>
Arnd Bergmann wrote:
> On Sunday 22 November 2009, Albert Herranz wrote:
>> +#ifdef CONFIG_PPC_EARLY_DEBUG_USBGECKO
>> +setup_usbgecko_bat:
>> + /* prepare a BAT for early io */
>> + lis r8, 0x0c00
>> + ori r8, r8, 0x002a /* uncached, guarded ,rw */
>> + lis r11, 0xcc00
>> + ori r11, r11, 0x3 /* 128K */
>> +#ifdef CONFIG_WII
>> + oris r8, r8, 0x0100
>> + oris r11, r11, 0x0100
>> +#endif
>> + mtspr SPRN_DBAT1L, r8
>> + mtspr SPRN_DBAT1U, r11
>> + sync
>> + isync
>> + blr
>> +#endif
>
> This will probably break other platforms if CONFIG_PPC_EARLY_DEBUG_USBGECKO
> is set. In general, we try hard to make it possible to build generic
> kernels for multiple systems, so it would be better to also add a runtime
> check here.
>
Ok, I see the point.
But, what makes CONFIG_PPC_EARLY_DEBUG_USBGECKO case different from CONFIG_PPC_EARLY_DEBUG_CPM case here?
>> --- a/arch/powerpc/platforms/embedded6xx/usbgecko_udbg.h
>> +++ b/arch/powerpc/platforms/embedded6xx/usbgecko_udbg.h
>> @@ -27,4 +27,10 @@ static inline void __init ug_udbg_init(void)
>>
>> #endif /* CONFIG_USBGECKO_UDBG */
>>
>> +#ifdef CONFIG_PPC_EARLY_DEBUG_USBGECKO
>> +
>> +void __init udbg_init_usbgecko(void);
>> +
>> +#endif /* CONFIG_PPC_EARLY_DEBUG_USBGECKO */
>> +
>
> No need to enclose a declaration in #ifdef, better leave it there
> unconditionally, unless you have an alternative version, like
>
> #ifdef CONFIG_PPC_EARLY_DEBUG_USBGECKO
> void __init udbg_init_usbgecko(void);
> #else /* !CONFIG_PPC_EARLY_DEBUG_USBGECKO */
> static inline void udbg_init_usbgecko(void)
> {
> }
> #endif /* CONFIG_PPC_EARLY_DEBUG_USBGECKO */
>
> That style is now more common than having additional #ifdefs
> in the code using the function.
I'll fix that too. Thanks.
Cheers,
Albert
^ permalink raw reply
* Re: [RFC PATCH 17/19] powerpc: wii: bootmii starlet 'mini' firmware support
From: Albert Herranz @ 2009-11-23 19:21 UTC (permalink / raw)
To: Arnd Bergmann; +Cc: linuxppc-dev
In-Reply-To: <200911222348.20652.arnd@arndb.de>
Arnd Bergmann wrote:
> On Sunday 22 November 2009, Albert Herranz wrote:
>> + *
>> + */
>> +struct mipc_device {
>> + void __iomem *io_base;
>> + int irq;
>> +
>> + struct device *dev;
>> +
>> + spinlock_t call_lock; /* serialize firmware calls */
>> + spinlock_t io_lock; /* serialize access to io registers */
>> +
>> + struct mipc_infohdr *hdr;
>> +
>> + struct mipc_req *in_ring;
>> + size_t in_ring_size;
>> + volatile u16 intail_idx;
>> +
>> + struct mipc_req *out_ring;
>> + size_t out_ring_size;
>> + volatile u16 outhead_idx;
>> +
>> + u32 tag;
>> +};
>
> The 'volatile' here seems out of place. What are you trying to protect
> against?
Nothing. I'll get rid of it.
It slipped through from ancient versions of the patch.
> The rest of the patch seems to be made up of layers of wrappers. They
> are all well coded, but I got a feeling that the same could be achieved
> with less of it.
The code provides a complete emulation layer of hardware accessors via ipc calls to the firmware.
This was a requirement to access part of the hardware until a "magic" register was found allowing direct hardware access from the PowerPC side.
I can get rid of the currently unused infrastructure and leave the strictly needed code (i.e. code to make sure that the firmware SDHC driver is shutdown and that the ahbprot register is properly setup).
I'll look into that. Thanks.
Cheers,
Albert
^ permalink raw reply
* Re: [RFC PATCH 00/19] powerpc: nintendo gamecube and wii support
From: Albert Herranz @ 2009-11-23 19:22 UTC (permalink / raw)
To: Arnd Bergmann; +Cc: linuxppc-dev
In-Reply-To: <200911222349.15290.arnd@arndb.de>
Arnd Bergmann wrote:
>
> Very nice series, well done!
>
> Time for me to invest in some new hardware ;-)
>
> Arnd <><
>
Thanks for review :)
Cheers,
Albert
^ permalink raw reply
* Re: [RFC PATCH 02/19] powerpc: gamecube: device tree
From: Albert Herranz @ 2009-11-23 19:44 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-dev
In-Reply-To: <fa686aa40911221502g2de254d2o4341d9abed0cdf41@mail.gmail.com>
Grant Likely wrote:
> On Sun, Nov 22, 2009 at 3:01 PM, Albert Herranz <albert_herranz@yahoo.es> wrote:
>> Add a device tree source file for the Nintendo GameCube video game console.
>>
>> Signed-off-by: Albert Herranz <albert_herranz@yahoo.es>
>
> Mostly looks good. A few comments below. Biggest comment is you need
> to add a brief blurb for every new "compatible" property value that
> you've added to Documentation/powerpc/dts-bindings. General agreement
> is that we don't merge drivers with new OF tree bindings unless the
> binding is also documented. It doesn't need to be long, it just needs
> to state what the device is, and what properties are expected. If you
> define new properties, then you need to state what they are used for.
>
> Once the comments below are addressed...
>
> Acked-by: Grant Likely <grant.likely@secretlab.ca>
>
Thanks. I'll add the documentation for the new compatible properties.
>> ---
>> arch/powerpc/boot/dts/gamecube.dts | 135 ++++++++++++++++++++++++++++++++++++
>> 1 files changed, 135 insertions(+), 0 deletions(-)
>> create mode 100644 arch/powerpc/boot/dts/gamecube.dts
>>
>> diff --git a/arch/powerpc/boot/dts/gamecube.dts b/arch/powerpc/boot/dts/gamecube.dts
>> new file mode 100644
>> index 0000000..941a2c4
>> --- /dev/null
>> +++ b/arch/powerpc/boot/dts/gamecube.dts
>> @@ -0,0 +1,135 @@
>> +/*
>> + * arch/powerpc/boot/dts/gamecube.dts
>> + *
>> + * Nintendo GameCube platform device tree source
>> + * Copyright (C) 2007-2009 The GameCube Linux Team
>> + * Copyright (C) 2007,2008,2009 Albert Herranz
>> + *
>> + * 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.
>> + *
>> + */
>> +
>> +/dts-v1/;
>> +
>> +/ {
>> + model = "NintendoGameCube";
>> + compatible = "nintendo,gamecube";
>
> To date, we've been using the same form for both the model and
> compatible properties. Specifically the <vendor>,<model> form to
> maintain the namespace.
>
Ok, I'll change model to "nintendo,gamecube".
>> + #address-cells = <1>;
>> + #size-cells = <1>;
>> +
>> + chosen {
>> + bootargs = "root=/dev/gcnsda2 rootwait udbg-immortal";
>> + linux,stdout-path = &USBGECKO0;
>> + };
>> +
>> + aliases {
>> + ugecon = &USBGECKO0;
>> + };
>> +
>> + memory {
>> + device_type = "memory";
>> + /* 24M minus framebuffer memory area (640*576*2*2) */
>> + reg = <0x00000000 0x01698000>;
>> + };
>> +
>> + cpus {
>> + #address-cells = <1>;
>> + #size-cells = <0>;
>> +
>> + PowerPC,gekko@0 {
>> + device_type = "cpu";
>> + reg = <0>;
>> + clock-frequency = <486000000>; /* 486MHz */
>> + bus-frequency = <162000000>; /* 162MHz core-to-bus 3x */
>> + timebase-frequency = <40500000>; /* 162MHz / 4 */
>> + i-cache-line-size = <32>;
>> + d-cache-line-size = <32>;
>> + i-cache-size = <32768>;
>> + d-cache-size = <32768>;
>> + };
>> + };
>> +
>> + /* devices contained int the flipper chipset */
>> + soc {
>
> It would be better to rename this as IMMR or the bus type. This node
> doesn't actually describe the entire chip, but describes the internal
> memory mapped registers.
>
Can you please elaborate more on this or point me to documentation?
The soc node here tries to represent the big multi-function chip that integrates most of the devices of the video game consoles ("Flipper" on the Nintendo GameCube and "Hollywood" on the Wii).
>> + #address-cells = <1>;
>> + #size-cells = <1>;
>> + #interrupt-cells = <1>;
>> + model = "flipper";
>
> Drop the model property
>
Ok, I'll fix that.
>> + compatible = "nintendo,flipper";
>> + clock-frequency = <162000000>; /* 162MHz */
>> + ranges = <0x0c000000 0x0c000000 0x00010000>;
>
> Since you're only doing 1:1 mappings; you could replace this with an
> empty "ranges;" property instead.
>
Nice, didn't know about this. I'll do that.
>> +
>> + video@0c002000 {
>> + compatible = "nintendo,flipper-video";
>> + reg = <0x0c002000 0x100>;
>> + interrupts = <8>;
>> + interrupt-parent = <&pic>;
>
> Hint: If you move the interrupt-parent property up to the root node,
> then you don't need to specify it in every single device node; it will
> just inherit from the parent.
>
Got it. This makes a lot of sense here with a single interrupt controller.
>> + /* XFB is the eXternal FrameBuffer */
>> + xfb-start = <0x01698000>; /* end-of-ram - xfb-size */
>> + xfb-size = <0x168000>;
>
> Can 'xfb' be made a second tuple to the 'reg' property so that all the
> address mapping code works on it? ie:
>
> reg = <0x0c002000 0x100
> 0x01698000 0x168000>;
>
> At the very least, it is wise to adopt the same form as the reg
> property when describing address ranges instead of splitting it into
> multiple properties.
>
I'll look into moving xfb-* into the reg property.
>> + };
>> +
>> + pic: pic@0c003000 {
>> + #interrupt-cells = <1>;
>> + compatible = "nintendo,flipper-pic";
>> + reg = <0x0c003000 0x8>;
>> + interrupt-controller;
>> + };
>> +
>> + resetswitch@0c003000 {
>> + compatible = "nintendo,flipper-resetswitch";
>> + reg = <0x0c003000 0x4>;
>> + interrupts = <1>;
>> + interrupt-parent = <&pic>;
>> + };
>> +
>> + auxram@0c005000 {
>> + compatible = "nintendo,flipper-auxram";
>> + reg = <0x0c005000 0x200>; /* DSP */
>> + interrupts = <6>;
>> + interrupt-parent = <&pic>;
>> + };
>> +
>> + audio@0c005000 {
>> + compatible = "nintendo,flipper-audio";
>> + reg = <0x0c005000 0x200 /* DSP */
>> + 0x0c006c00 0x20>; /* AI */
>> + interrupts = <6>;
>> + interrupt-parent = <&pic>;
>> + };
>> +
>> + disk@0c006000 {
>> + compatible = "nintendo,flipper-disk";
>> + reg = <0x0c006000 0x40>;
>> + interrupts = <2>;
>> + interrupt-parent = <&pic>;
>> + };
>> +
>> + serial@0c006400 {
>> + compatible = "nintendo,flipper-serial";
>> + reg = <0x0c006400 0x100>;
>> + interrupts = <3>;
>> + interrupt-parent = <&pic>;
>> + };
>> +
>> + /* External Interface bus */
>> + exi@0c006800 {
>> + #address-cells = <1>;
>> + #size-cells = <1>;
>> + compatible = "nintendo,flipper-exi";
>> + reg = <0x0c006800 0x40>;
>> + interrupts = <4>;
>> + interrupt-parent = <&pic>;
>> +
>> + USBGECKO0: usbgecko@0c006814 {
>> + compatible = "usbgecko,usbgecko";
>> + reg = <0x0c006814 0x14>;
>> + virtual-reg = <0xcc006814>;
>> + };
>> + };
>> + };
>> +};
>> +
Cheers,
Albert
^ permalink raw reply
* Re: [RFC PATCH 04/19] powerpc: wii: device tree
From: Albert Herranz @ 2009-11-23 19:54 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-dev
In-Reply-To: <fa686aa40911221518s5d82d5b4i8402a297d52a46d1@mail.gmail.com>
Grant Likely wrote:
> On Sun, Nov 22, 2009 at 3:01 PM, Albert Herranz <albert_herranz@yahoo.es> wrote:
>> Add a device tree source file for the Nintendo Wii video game console.
>>
>> Signed-off-by: Albert Herranz <albert_herranz@yahoo.es>
>
> Same comments apply here as for the gamecube.dts file, plus a few more below.
>
Ok, I'll try to address them too here.
>> ---
>> arch/powerpc/boot/dts/wii.dts | 244 +++++++++++++++++++++++++++++++++++++++++
>> 1 files changed, 244 insertions(+), 0 deletions(-)
>> create mode 100644 arch/powerpc/boot/dts/wii.dts
>>
>> diff --git a/arch/powerpc/boot/dts/wii.dts b/arch/powerpc/boot/dts/wii.dts
>> new file mode 100644
>> index 0000000..a30a804
>> --- /dev/null
>> +++ b/arch/powerpc/boot/dts/wii.dts
>> @@ -0,0 +1,244 @@
>> +/*
>> + * arch/powerpc/boot/dts/wii.dts
>> + *
>> + * Nintendo Wii platform device tree source
>> + * Copyright (C) 2008-2009 The GameCube Linux Team
>> + * Copyright (C) 2008,2009 Albert Herranz
>> + *
>> + * 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.
>> + *
>> + */
>> +
>> +/dts-v1/;
>> +
>> +/memreserve/ 0x01800000 0xe800000; /* memory hole (includes I/O area) */
>> +/memreserve/ 0x10000000 0x0004000; /* DSP RAM */
>
> This bothers me... see below.
>
>> +
>> +/ {
>> + model = "NintendoWii";
>> + compatible = "nintendo,wii";
>> + #address-cells = <1>;
>> + #size-cells = <1>;
>> +
>> + chosen {
>> + /* root filesystem on 2nd partition of SD card */
>> + bootargs = "nobats root=/dev/mmcblk0p2 rootwait udbg-immortal";
>> + linux,stdout-path = &USBGECKO0;
>> + };
>> +
>> + aliases {
>> + ugecon = &USBGECKO0;
>> + hw_gpio = &gpio1;
>> + };
>> +
>> + /*
>> + * The Nintendo Wii has two discontiguous RAM memory areas called
>> + * MEM1 and MEM2.
>> + * MEM1 starts at 0x00000000 and contains 24MB of 1T-SRAM.
>> + * MEM2 starts at 0x10000000 and contains 64MB of DDR2 RAM.
>> + * Between both memory address ranges there is an address space
>> + * where memory-mapped I/O registers are found.
>> + *
>> + * Currently, Linux 32-bit PowerPC does not support RAM in
>> + * discontiguous memory address spaces. Thus, in order to use
>> + * both RAM areas, we declare as RAM the range from the start of
>> + * MEM1 to the end of useable MEM2 and exclude the needed parts
>> + * with /memreserve/ statements, at the expense of wasting a bit
>> + * of memory.
>
> Hmmm. It's not great practice to lie about hardware in the device
> tree. Better to describe the memory correctly here, and if you have
> to work around Linux deficiencies, then do so in the platform support
> code (arch/platforms/*). I won't NAK the patch over it (feel free to
> add my Acked-by line) because it doesn't impact other platforms, but
> it should be fixed.
>
I'll try to workaround the limitation via a fixups function in the bootwrapper instead.
>> + i2c-video {
>> + #address-cells = <1>;
>> + #size-cells = <0>;
>> + compatible = "virtual,i2c-gpio";
>
> There isn't a documented binding for this. Is there a driver for it?
>
I have a driver for it. But it isn't yet published.
This is the documentation I wrote so far for the bindings.
Is there a standard for this?
Documentation/powerpc/dts-bindings/gpio/i2c.txt
GPIO-based I2C
Required properties:
- compatible : should be "virtual,i2c-gpio".
- gpios : should specify GPIOs used for SDA and SCL lines, in that order.
- sda-is-open-drain : should be non-zero if SDA gpio is open-drain.
- sda-enforce-dir : should be non-zero if SDA gpio must be configured for
input before reading and for output before writing.
- scl-is-open-drain : should be non-zero if SCL gpio is open-drain.
- scl-is-output-only : should be non-zero if SCL is an output gpio only.
- udelay : signal toggle delay. SCL frequency is (500 / udelay) kHz
- timeout : clock stretching timeout in milliseconds.
Example:
gpio0: hollywood-gpio@0d8000c0 {
compatible = "nintendo,hollywood-gpio";
reg = <0x0d8000c0 0x20>;
gpio-controller;
#gpio-cells = <2>;
};
i2c-video {
#address-cells = <1>;
#size-cells = <0>;
compatible = "virtual,i2c-gpio";
gpios = <&gpio0 16 0 /* SDA line */
&gpio0 17 0 /* SCL line */
>;
sda-is-open-drain = <1>;
sda-enforce-dir = <1>;
scl-is-open-drain = <1>;
scl-is-output-only = <1>;
udelay = <2>;
audio-video-encoder {
compatible = "nintendo,wii-ave-rvl";
reg = <0x70>;
};
};
>> +
>> + gpios = <&gpio0 16 0 /* 31-15 */
>> + &gpio0 17 0 /* 31-14 */
>> + >;
>> + sda-is-open-drain = <1>;
>> + sda-enforce-dir = <1>;
>> + scl-is-open-drain = <1>;
>> + scl-is-output-only = <1>;
>> + udelay = <2>;
>> +
>> + audio-video-encoder {
>> + compatible = "nintendo,wii-ave-rvl";
>> + reg = <0x70>;
>> + };
>> + };
>> + };
>> +};
>> +
Cheers,
Albert
^ permalink raw reply
* Re: [RFC PATCH 06/19] powerpc: gamecube/wii: introduce GAMECUBE_COMMON
From: Albert Herranz @ 2009-11-23 19:56 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-dev
In-Reply-To: <fa686aa40911221520i22372282j6b619828c198d184@mail.gmail.com>
Grant Likely wrote:
> On Sun, Nov 22, 2009 at 3:01 PM, Albert Herranz <albert_herranz@yahoo.es> wrote:
>> Add a config option GAMECUBE_COMMON to be used as a dependency for all
>> options common to the Nintendo GameCube and Wii video game consoles.
>>
>> Signed-off-by: Albert Herranz <albert_herranz@yahoo.es>
>
> This could just be rolled into the first patch that uses it. But
> otherwise; ACK.
>
> g.
>
Thanks. This one I prefer in a separate patch as a logical step, if that's not a problem.
>> ---
>> arch/powerpc/platforms/embedded6xx/Kconfig | 4 ++++
>> 1 files changed, 4 insertions(+), 0 deletions(-)
>>
>> diff --git a/arch/powerpc/platforms/embedded6xx/Kconfig b/arch/powerpc/platforms/embedded6xx/Kconfig
>> index 291ac9d..97a2dbc 100644
>> --- a/arch/powerpc/platforms/embedded6xx/Kconfig
>> +++ b/arch/powerpc/platforms/embedded6xx/Kconfig
>> @@ -90,3 +90,7 @@ config MPC10X_OPENPIC
>> config MPC10X_STORE_GATHERING
>> bool "Enable MPC10x store gathering"
>> depends on MPC10X_BRIDGE
>> +
>> +config GAMECUBE_COMMON
>> + bool
>> +
Cheers,
Albert
^ permalink raw reply
* Re: [RFC PATCH 11/19] powerpc: gamecube/wii: flipper interrupt controller support
From: Albert Herranz @ 2009-11-23 19:59 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-dev
In-Reply-To: <fa686aa40911221528y1980a95bw1dc8aa75a86c061e@mail.gmail.com>
Grant Likely wrote:
> On Sun, Nov 22, 2009 at 3:01 PM, Albert Herranz <albert_herranz@yahoo.es> wrote:
>> Add support for the interrupt controller included in the "Flipper"
>> chipset of the Nintendo GameCube video game console.
>> The same interrupt controller is also present in the "Hollywood" chipset
>> of the Nintendo Wii.
>>
>> Signed-off-by: Albert Herranz <albert_herranz@yahoo.es>
>> ---
>> arch/powerpc/platforms/embedded6xx/Kconfig | 6 +
>> arch/powerpc/platforms/embedded6xx/Makefile | 1 +
>> arch/powerpc/platforms/embedded6xx/flipper-pic.c | 247 ++++++++++++++++++++++
>> arch/powerpc/platforms/embedded6xx/flipper-pic.h | 25 +++
>> 4 files changed, 279 insertions(+), 0 deletions(-)
>> create mode 100644 arch/powerpc/platforms/embedded6xx/flipper-pic.c
>> create mode 100644 arch/powerpc/platforms/embedded6xx/flipper-pic.h
>>
>> diff --git a/arch/powerpc/platforms/embedded6xx/Kconfig b/arch/powerpc/platforms/embedded6xx/Kconfig
>> index bfd88be..29a98c6 100644
>> --- a/arch/powerpc/platforms/embedded6xx/Kconfig
>> +++ b/arch/powerpc/platforms/embedded6xx/Kconfig
>> @@ -94,6 +94,7 @@ config MPC10X_STORE_GATHERING
>> config GAMECUBE_COMMON
>> bool
>> select NOT_COHERENT_CACHE
>> + select FLIPPER_PIC
>>
>> config USBGECKO_UDBG
>> bool "USB Gecko udbg console for the Nintendo GameCube/Wii"
>> @@ -108,3 +109,8 @@ config USBGECKO_UDBG
>>
>> If in doubt, say N here.
>>
>> +config FLIPPER_PIC
>> + bool
>> + depends on GAMECUBE_COMMON
>> + default y
>
> You'll always want this driver when GAMECUBE common is set. Don't add
> another Kconfig entry.
>
Ok.
>> +
>> diff --git a/arch/powerpc/platforms/embedded6xx/Makefile b/arch/powerpc/platforms/embedded6xx/Makefile
>> index 0ab7492..35258fd 100644
>> --- a/arch/powerpc/platforms/embedded6xx/Makefile
>> +++ b/arch/powerpc/platforms/embedded6xx/Makefile
>> @@ -8,3 +8,4 @@ obj-$(CONFIG_PPC_HOLLY) += holly.o
>> obj-$(CONFIG_PPC_PRPMC2800) += prpmc2800.o
>> obj-$(CONFIG_PPC_C2K) += c2k.o
>> obj-$(CONFIG_USBGECKO_UDBG) += usbgecko_udbg.o
>> +obj-$(CONFIG_FLIPPER_PIC) += flipper-pic.o
>
>> +unsigned int flipper_pic_get_irq(void)
>> +{
>> + void __iomem *io_base = flipper_irq_host->host_data;
>> + int irq;
>> + u32 irq_status;
>> +
>> + irq_status = in_be32(io_base + FLIPPER_ICR) &
>> + in_be32(io_base + FLIPPER_IMR);
>> + if (irq_status == 0)
>> + return -1; /* no more IRQs pending */
>
> NO_IRQ_IGNORE
>
I'll fix that. Thanks.
I did it in the other interrupt controller but forgot about this.
>> +
>> + __asm__ __volatile__("cntlzw %0,%1" : "=r"(irq) : "r"(irq_status));
>> + return irq_linear_revmap(flipper_irq_host, 31 - irq);
>> +}
>> +
>
Thanks.
Cheers,
Albert
^ permalink raw reply
* Re: [RFC PATCH 12/19] powerpc: gamecube: platform support
From: Albert Herranz @ 2009-11-23 20:02 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-dev
In-Reply-To: <fa686aa40911221534m6fcf14b3ted9dd181a0e264e4@mail.gmail.com>
Grant Likely wrote:
> On Sun, Nov 22, 2009 at 3:01 PM, Albert Herranz <albert_herranz@yahoo.es> wrote:
>> Add platform support for the Nintendo GameCube video game console.
>>
>> Signed-off-by: Albert Herranz <albert_herranz@yahoo.es>
>> ---
>> +static void gamecube_show_cpuinfo(struct seq_file *m)
>> +{
>> + seq_printf(m, "vendor\t\t: IBM\n");
>> + seq_printf(m, "machine\t\t: Nintendo GameCube\n");
>> +}
>
> show_cpuinfo hooks have been dropped on most platforms now.
>
I'll drop'em all. Thanks.
>> +static void gamecube_shutdown(void)
>> +{
>> + /* currently not used */
>> +}
>
> Then don't add the hook. Just drop it. Same for other empty
> functions in this file. If it is safe to drop them, then please do.
>
> Otherwise: Acked-by: Grant Likely <grant.likely@secretlab.ca>
>
I actually forgot to add a flipper_quiesce() call there.
That one will be used.
But I'll review the other cases. Thanks.
>> +define_machine(gamecube) {
>> + .name = "gamecube",
>> + .probe = gamecube_probe,
>> + .setup_arch = gamecube_setup_arch,
>> + .init_early = gamecube_init_early,
>> + .show_cpuinfo = gamecube_show_cpuinfo,
>> + .restart = gamecube_restart,
>> + .power_off = gamecube_power_off,
>> + .halt = gamecube_halt,
>> + .init_IRQ = flipper_pic_probe,
>> + .get_irq = flipper_pic_get_irq,
>> + .calibrate_decr = generic_calibrate_decr,
>> + .progress = udbg_progress,
>> + .machine_shutdown = gamecube_shutdown,
>> +#ifdef CONFIG_KEXEC
>> + .machine_kexec_prepare = gamecube_kexec_prepare,
>> + .machine_kexec = default_machine_kexec,
>> +#endif
>> +};
>> +
>> diff --git a/arch/powerpc/platforms/embedded6xx/gamecube_dev.c b/arch/powerpc/platforms/embedded6xx/gamecube_dev.c
>> new file mode 100644
>> index 0000000..13e1f73
>> --- /dev/null
>> +++ b/arch/powerpc/platforms/embedded6xx/gamecube_dev.c
>> @@ -0,0 +1,34 @@
>> +/*
>> + * arch/powerpc/platforms/embedded6xx/gamecube_dev.c
>> + *
>> + * Nintendo GameCube platform device setup.
>> + * Copyright (C) 2008-2009 The GameCube Linux Team
>> + * Copyright (C) 2008,2009 Albert Herranz
>> + *
>> + * 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/kernel.h>
>> +#include <linux/init.h>
>> +#include <linux/of_platform.h>
>> +
>> +#include <asm/machdep.h>
>> +
>> +static struct of_device_id gamecube_of_bus[] = {
>> + { .compatible = "nintendo,flipper", },
>> + { },
>> +};
>> +
>> +static int __init gamecube_device_probe(void)
>> +{
>> + if (!machine_is(gamecube))
>> + return 0;
>> +
>> + of_platform_bus_probe(NULL, gamecube_of_bus, NULL);
>> + return 0;
>> +}
>> +device_initcall(gamecube_device_probe);
Cheers,
Albert
^ permalink raw reply
* Re: [RFC PATCH 14/19] powerpc: allow ioremap within reserved fake ram regions
From: Albert Herranz @ 2009-11-23 20:16 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-dev
In-Reply-To: <fa686aa40911221536pf558b1fte36dc88bdf58e883@mail.gmail.com>
Grant Likely wrote:
> On Sun, Nov 22, 2009 at 3:01 PM, Albert Herranz <albert_herranz@yahoo.es> wrote:
>> The Nintendo Wii has two discontiguous RAM memory areas called
>> MEM1 and MEM2.
>> MEM1 starts at 0x00000000 and contains 24MB of 1T-SRAM.
>> MEM2 starts at 0x10000000 and contains 64MB of DDR2 RAM.
>> Between both memory address ranges there is an address space
>> where memory-mapped I/O registers are found.
>>
>> Currently, Linux 32-bit PowerPC does not support RAM in
>> discontiguous memory address spaces. Thus, in order to use
>> both RAM areas, we declare as RAM the range from the start of
>> MEM1 to the end of useable MEM2 and exclude the needed parts
>> with /memreserve/ statements, at the expense of wasting a bit
>> of memory.
>>
>> As a side effect, we need to allow ioremapping RAM areas
>> because the I/O address space sits within the memreserve'd part
>> of the declared RAM region.
>> Note that this is not safe if the region ioremapped is covered
>> by an existing BAT mapping used to map RAM, so this is
>> specifically banned here.
>>
>> Signed-off-by: Albert Herranz <albert_herranz@yahoo.es>
>> ---
>> arch/powerpc/mm/pgtable_32.c | 19 ++++++++++++++++---
>> 1 files changed, 16 insertions(+), 3 deletions(-)
>>
>> diff --git a/arch/powerpc/mm/pgtable_32.c b/arch/powerpc/mm/pgtable_32.c
>> index cb96cb2..ba00cb1 100644
>> --- a/arch/powerpc/mm/pgtable_32.c
>> +++ b/arch/powerpc/mm/pgtable_32.c
>> @@ -191,9 +191,22 @@ __ioremap_caller(phys_addr_t addr, unsigned long size, unsigned long flags,
>> * Don't allow anybody to remap normal RAM that we're using.
>> * mem_init() sets high_memory so only do the check after that.
>> */
>> - if (mem_init_done && (p < virt_to_phys(high_memory))) {
>> - printk("__ioremap(): phys addr 0x%llx is RAM lr %p\n",
>> - (unsigned long long)p, __builtin_return_address(0));
>> + if (mem_init_done && (p < virt_to_phys(high_memory))
>> +#ifdef CONFIG_WII
>> + /*
>> + * On some systems, though, we may want to remap an area
>> + * declared as normal RAM that we have memreserve'd at the
>> + * device tree. See wii.dts.
>> + * But we can't do that safely if we are using BATs to map
>> + * part of that area.
>> + */
>> + && !__map_without_bats
>> +#endif
>> + ) {
>> + printk(KERN_WARNING
>> + "__ioremap(): phys addr 0x%llx is RAM lr %p\n",
>> + (unsigned long long)p,
>> + __builtin_return_address(0));
>
> This could adversely affect multiplatform kernels. I'd rather get the
> RAM problem fixed and not hack up common code to work around the hack.
>
> g.
>
Would it be acceptable to create a global var __allow_ioremap_normal_ram that by default would have a value of 0 and would be set _only_ for those platforms needing it?
The other solutions I see is:
- add support for discontiguous memory to powerpc 32-bits (which is not something that I can look into now)
- don't use the precious second 64MB area (which is a waste)
Do you have any other suggestions?
Thanks,
Albert
^ permalink raw reply
* Re: [RFC PATCH 15/19] powerpc: broadway processor support
From: Albert Herranz @ 2009-11-23 20:16 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-dev
In-Reply-To: <fa686aa40911221538s46a81acal9b451bf48873b6be@mail.gmail.com>
Grant Likely wrote:
> On Sun, Nov 22, 2009 at 3:01 PM, Albert Herranz <albert_herranz@yahoo.es> wrote:
>> This patch extends the cputable entry of the 750CL to also match
>> the 750CL-based "Broadway" cpu found on the Nintendo Wii.
>>
>> As of this patch, the following "Broadway" design revision levels have
>> been seen in the wild:
>> - DD1.2 (87102)
>> - DD2.0 (87200)
>
> Please respin without the reordering of CPU table entries. If you
> want to reorder, then do it in a separate patch.
>
> g.
>
Ok. I'll look into that too. Thanks.
Cheers,
Albert
^ 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