* Re: [PATCH] ppc: Marvell mv64x60 drivers for ppc platforms fix
From: Dale Farnsworth @ 2007-06-24 22:46 UTC (permalink / raw)
To: yur, linuxppc-dev
In-Reply-To: <200706241552.31483.yur@emcraft.com>
In article <200706241552.31483.yur@emcraft.com> you write:
> This patch fixes the issue of erroneously involving the
> arch/powerpc/sysdev/mv64x60*.c files into the compilation
> process for ppc- (not powerpc-) based platforms (e.g.,
> P3M750).
>
> Signed-off-by: Yuri Tikhonov <yur@emcraft.com>
>
> --
>
> diff --git a/arch/powerpc/sysdev/Makefile b/arch/powerpc/sysdev/Makefile
> index c3ce0bd..25eaa14 100644
> --- a/arch/powerpc/sysdev/Makefile
> +++ b/arch/powerpc/sysdev/Makefile
> @@ -17,7 +17,9 @@ obj-$(CONFIG_FSL_PCIE) += fsl_pcie.o
> obj-$(CONFIG_TSI108_BRIDGE) += tsi108_pci.o tsi108_dev.o
> obj-$(CONFIG_QUICC_ENGINE) += qe_lib/
> mv64x60-$(CONFIG_PCI) += mv64x60_pci.o
Shouldn't the above line also be placed inside the of following ifeq ?
> +ifeq ($(CONFIG_PPC_MERGE),y)
> obj-$(CONFIG_MV64X60) += $(mv64x60-y) mv64x60_pic.o mv64x60_dev.o
> +endif
>
> # contains only the suspend handler for time
> obj-$(CONFIG_PM) += timer.o
Thanks,
-Dale
^ permalink raw reply
* [PATCH] pcmcia: ppc64 needs 32-bit ioaddr_t
From: Olof Johansson @ 2007-06-25 0:54 UTC (permalink / raw)
To: linux-kernel, linux-pcmcia; +Cc: akpm, linuxppc-dev, paulus
ppc64 really needs ioaddr_t to be 32-bit, since I/O addresses really are
MMIO addresses, and remapped at an offset that's well above 16 bits in
some cases.
While the type is exported to userspace, there hasn't been any platforms
with PCMCIA on 64-bit powerpc until now, so changing it won't regress
any existing users.
Signed-off-by: Olof Johansson <olof@lixom.net>
Acked-by: Paul Mackerras <paulus@samba.org>
Index: 2.6.21/include/pcmcia/cs_types.h
===================================================================
--- 2.6.21.orig/include/pcmcia/cs_types.h
+++ 2.6.21/include/pcmcia/cs_types.h
@@ -21,7 +21,7 @@
#include <sys/types.h>
#endif
-#if defined(__arm__) || defined(__mips__)
+#if defined(__arm__) || defined(__mips__) || defined(__powerpc64__)
/* This (ioaddr_t) is exposed to userspace & hence cannot be changed. */
typedef u_int ioaddr_t;
#else
^ permalink raw reply
* [PATCH] pcmcia: CompactFlash driver for PA Semi Electra boards
From: Olof Johansson @ 2007-06-25 1:03 UTC (permalink / raw)
To: linux-kernel, linux-pcmcia; +Cc: linuxppc-dev, Russell King
Driver for the CompactFlash slot on the PA Semi Electra eval board. It's
a simple device sitting on localbus, with interrupts and detect/voltage
control over GPIO.
The driver is implemented as an of_platform driver, and adds localbus
as a bus being probed by the of_platform framework.
Signed-off-by: Olof Johansson <olof@lixom.net>
Acked-by: Paul Mackerras <paulus@samba.org>
---
Fixed the comments from Russell on last post, this should be good to
merge now.
Index: powerpc/drivers/pcmcia/Kconfig
===================================================================
--- powerpc.orig/drivers/pcmcia/Kconfig
+++ powerpc/drivers/pcmcia/Kconfig
@@ -270,6 +270,13 @@ config AT91_CF
Say Y here to support the CompactFlash controller on AT91 chips.
Or choose M to compile the driver as a module named "at91_cf".
+config ELECTRA_CF
+ bool "Electra CompactFlash Controller"
+ depends on PCMCIA=y && PPC_PASEMI
+ help
+ Say Y here to support the CompactFlash controller on the
+ PA Semi Electra eval board.
+
config PCCARD_NONSTATIC
tristate
Index: powerpc/drivers/pcmcia/Makefile
===================================================================
--- powerpc.orig/drivers/pcmcia/Makefile
+++ powerpc/drivers/pcmcia/Makefile
@@ -37,6 +37,7 @@ obj-$(CONFIG_PCMCIA_VRC4171) += vrc417
obj-$(CONFIG_PCMCIA_VRC4173) += vrc4173_cardu.o
obj-$(CONFIG_OMAP_CF) += omap_cf.o
obj-$(CONFIG_AT91_CF) += at91_cf.o
+obj-$(CONFIG_ELECTRA_CF) += electra_cf.o
sa11xx_core-y += soc_common.o sa11xx_base.o
pxa2xx_core-y += soc_common.o pxa2xx_base.o
Index: powerpc/drivers/pcmcia/electra_cf.c
===================================================================
--- /dev/null
+++ powerpc/drivers/pcmcia/electra_cf.c
@@ -0,0 +1,382 @@
+/*
+ * Copyright (C) 2007 PA Semi, Inc
+ *
+ * Maintained by: Olof Johansson <olof@lixom.net>
+ *
+ * Based on drivers/pcmcia/omap_cf.c
+ *
+ * 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.
+ *
+ * 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., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+ */
+
+#include <linux/module.h>
+#include <linux/kernel.h>
+#include <linux/sched.h>
+#include <linux/platform_device.h>
+#include <linux/errno.h>
+#include <linux/init.h>
+#include <linux/delay.h>
+#include <linux/interrupt.h>
+
+#include <pcmcia/ss.h>
+#include <asm/of_platform.h>
+
+static const char driver_name[] = "electra-cf";
+
+struct electra_cf_socket {
+ struct pcmcia_socket socket;
+
+ struct timer_list timer;
+ unsigned present:1;
+ unsigned active:1;
+
+ struct of_device *ofdev;
+ unsigned long mem_phys;
+ void __iomem * mem_base;
+ unsigned long mem_size;
+ void __iomem * io_virt;
+ unsigned int io_base;
+ unsigned int io_size;
+ u_int irq;
+ struct resource iomem;
+ void __iomem * gpio_base;
+ int gpio_detect;
+ int gpio_vsense;
+ int gpio_3v;
+ int gpio_5v;
+};
+
+#define POLL_INTERVAL (2 * HZ)
+
+
+static int electra_cf_present(struct electra_cf_socket *cf)
+{
+ unsigned int gpio;
+
+ gpio = in_le32(cf->gpio_base+0x40);
+ return !(gpio & (1 << cf->gpio_detect));
+}
+
+static int electra_cf_ss_init(struct pcmcia_socket *s)
+{
+ return 0;
+}
+
+/* the timer is primarily to kick this socket's pccardd */
+static void electra_cf_timer(unsigned long _cf)
+{
+ struct electra_cf_socket *cf = (void *) _cf;
+ int present = electra_cf_present(cf);
+
+ if (present != cf->present) {
+ cf->present = present;
+ pcmcia_parse_events(&cf->socket, SS_DETECT);
+ }
+
+ if (cf->active)
+ mod_timer(&cf->timer, jiffies + POLL_INTERVAL);
+}
+
+static irqreturn_t electra_cf_irq(int irq, void *_cf)
+{
+ electra_cf_timer((unsigned long)_cf);
+ return IRQ_HANDLED;
+}
+
+static int electra_cf_get_status(struct pcmcia_socket *s, u_int *sp)
+{
+ struct electra_cf_socket *cf;
+
+ if (!sp)
+ return -EINVAL;
+
+ cf = container_of(s, struct electra_cf_socket, socket);
+
+ /* NOTE CF is always 3VCARD */
+ if (electra_cf_present(cf)) {
+ struct electra_cf_socket *cf;
+
+ *sp = SS_READY | SS_DETECT | SS_POWERON | SS_3VCARD;
+ cf = container_of(s, struct electra_cf_socket, socket);
+ s->pci_irq = cf->irq;
+ } else
+ *sp = 0;
+ return 0;
+}
+
+static int electra_cf_set_socket(struct pcmcia_socket *sock,
+ struct socket_state_t *s)
+{
+ unsigned int gpio;
+ unsigned int vcc;
+ struct electra_cf_socket *cf;
+
+ cf = container_of(sock, struct electra_cf_socket, socket);
+
+ /* "reset" means no power in our case */
+ vcc = (s->flags & SS_RESET) ? 0 : s->Vcc;
+
+ switch (vcc) {
+ case 0:
+ gpio = 0;
+ break;
+ case 33:
+ gpio = (1 << cf->gpio_3v);
+ break;
+ default:
+ /* CF is 3.3V only */
+ return -EINVAL;
+ }
+
+ gpio |= 1 << (cf->gpio_3v + 16); /* enwr */
+ gpio |= 1 << (cf->gpio_5v + 16); /* enwr */
+ out_le32(cf->gpio_base+0x90, gpio);
+
+ pr_debug("%s: Vcc %d, io_irq %d, flags %04x csc %04x\n",
+ driver_name, s->Vcc, s->io_irq, s->flags, s->csc_mask);
+
+ return 0;
+}
+
+static int electra_cf_set_io_map(struct pcmcia_socket *s,
+ struct pccard_io_map *io)
+{
+ return 0;
+}
+
+static int electra_cf_set_mem_map(struct pcmcia_socket *s,
+ struct pccard_mem_map *map)
+{
+ struct electra_cf_socket *cf;
+
+ if (map->card_start)
+ return -EINVAL;
+ cf = container_of(s, struct electra_cf_socket, socket);
+ map->static_start = cf->mem_phys;
+ map->flags &= MAP_ACTIVE|MAP_ATTRIB;
+ if (!(map->flags & MAP_ATTRIB))
+ map->static_start += 0x800;
+ return 0;
+}
+
+static struct pccard_operations electra_cf_ops = {
+ .init = electra_cf_ss_init,
+ .get_status = electra_cf_get_status,
+ .set_socket = electra_cf_set_socket,
+ .set_io_map = electra_cf_set_io_map,
+ .set_mem_map = electra_cf_set_mem_map,
+};
+
+static int __devinit electra_cf_probe(struct of_device *ofdev,
+ const struct of_device_id *match)
+{
+ struct device *device = &ofdev->dev;
+ struct device_node *np = ofdev->node;
+ struct electra_cf_socket *cf;
+ struct resource mem, io;
+ int status;
+ const unsigned int *prop;
+ int err;
+
+ err = of_address_to_resource(np, 0, &mem);
+ if (err)
+ return -EINVAL;
+
+ err = of_address_to_resource(np, 1, &io);
+ if (err)
+ return -EINVAL;
+
+ cf = kzalloc(sizeof *cf, GFP_KERNEL);
+ if (!cf)
+ return -ENOMEM;
+
+ init_timer(&cf->timer);
+ cf->timer.function = electra_cf_timer;
+ cf->timer.data = (unsigned long) cf;
+
+ cf->ofdev = ofdev;
+ cf->mem_phys = mem.start;
+ cf->mem_base = ioremap(mem.start, mem.end - mem.start);
+ cf->io_size = PAGE_ALIGN(io.end - io.start);
+
+ cf->io_virt = reserve_phb_iospace(cf->io_size);
+
+ cf->gpio_base = ioremap(0xfc103000, 0x1000);
+ dev_set_drvdata(device, cf);
+
+ if (!cf->mem_base || !cf->io_virt || !cf->gpio_base) {
+ dev_err(device, "can't ioremap ranges\n");
+ status = -ENOMEM;
+ goto fail1;
+ }
+
+ __ioremap_explicit(io.start, (unsigned long)cf->io_virt, cf->io_size,
+ _PAGE_NO_CACHE | _PAGE_GUARDED);
+
+ cf->io_base = (unsigned long)cf->io_virt - VMALLOC_END;
+
+ cf->iomem.start = (unsigned long)cf->mem_base;
+ cf->iomem.end = (unsigned long)cf->mem_base + (mem.end - mem.start);
+ cf->iomem.flags = IORESOURCE_MEM;
+
+ cf->irq = irq_of_parse_and_map(np, 0);
+
+ status = request_irq(cf->irq, electra_cf_irq, IRQF_SHARED,
+ driver_name, cf);
+ if (status < 0) {
+ dev_err(device, "request_irq failed\n");
+ goto fail1;
+ }
+
+ cf->socket.pci_irq = cf->irq;
+
+ prop = get_property(np, "card-detect-gpio", NULL);
+ cf->gpio_detect = *prop;
+ prop = get_property(np, "card-vsense-gpio", NULL);
+ cf->gpio_vsense = *prop;
+ prop = get_property(np, "card-3v-gpio", NULL);
+ cf->gpio_3v = *prop;
+ prop = get_property(np, "card-5v-gpio", NULL);
+ cf->gpio_5v = *prop;
+
+ cf->socket.io_offset = cf->io_base;
+
+ /* reserve chip-select regions */
+ if (!request_mem_region(mem.start, mem.end + 1 - mem.start,
+ driver_name)) {
+ status = -ENXIO;
+ dev_err(device, "Can't claim memory region\n");
+ goto fail1;
+ }
+
+ if (!request_region(cf->io_base, cf->io_size, driver_name)) {
+ status = -ENXIO;
+ dev_err(device, "Can't claim I/O region\n");
+ goto fail2;
+ }
+
+ cf->socket.owner = THIS_MODULE;
+ cf->socket.dev.parent = &ofdev->dev;
+ cf->socket.ops = &electra_cf_ops;
+ cf->socket.resource_ops = &pccard_static_ops;
+ cf->socket.features = SS_CAP_PCCARD | SS_CAP_STATIC_MAP |
+ SS_CAP_MEM_ALIGN;
+ cf->socket.map_size = 0x800;
+
+ status = pcmcia_register_socket(&cf->socket);
+ if (status < 0) {
+ dev_err(device, "pcmcia_register_socket failed\n");
+ goto fail3;
+ }
+
+ dev_info(device, "at mem 0x%lx io 0x%lx irq %d\n",
+ mem.start, io.start, cf->irq);
+
+ cf->active = 1;
+ electra_cf_timer((unsigned long)cf);
+ return 0;
+
+fail3:
+ release_mem_region(io.start, io.end + 1 - io.start);
+fail2:
+ release_mem_region(mem.start, mem.end + 1 - mem.start);
+fail1:
+ /* XXX No way to undo the io reservation at this time */
+ if (cf->mem_base)
+ iounmap(cf->mem_base);
+ if (cf->gpio_base)
+ iounmap(cf->gpio_base);
+ device_init_wakeup(&ofdev->dev, 0);
+ kfree(cf);
+ return status;
+
+}
+
+static int __devexit electra_cf_remove(struct of_device *ofdev)
+{
+ struct device *device = &ofdev->dev;
+ struct electra_cf_socket *cf;
+
+ cf = dev_get_drvdata(device);
+
+ cf->active = 0;
+ pcmcia_unregister_socket(&cf->socket);
+ free_irq(cf->irq, cf);
+ del_timer_sync(&cf->timer);
+
+ iounmap(cf->mem_base);
+ iounmap(cf->gpio_base);
+ release_mem_region(cf->mem_phys, cf->mem_size);
+ release_region(cf->io_base, cf->io_size);
+
+ kfree(cf);
+
+ return 0;
+}
+
+static int bus_notify(struct notifier_block *nb, unsigned long action,
+ void *data)
+{
+ struct device *dev = data;
+
+ printk("bus notify called\n");
+
+ /* We are only intereted in device addition */
+ if (action != BUS_NOTIFY_ADD_DEVICE)
+ return 0;
+
+ /* We use the direct ops for localbus */
+ dev->archdata.dma_ops = &dma_direct_ops;
+
+ return 0;
+}
+
+static struct notifier_block bus_notifier = {
+ .notifier_call = bus_notify,
+};
+
+static struct of_device_id electra_cf_match[] =
+{
+ {
+ .compatible = "electra-cf",
+ },
+ {},
+};
+
+static struct of_platform_driver electra_cf_driver =
+{
+ .name = (char *)driver_name,
+ .match_table = electra_cf_match,
+ .probe = electra_cf_probe,
+ .remove = electra_cf_remove,
+};
+
+static int __init electra_cf_init(void)
+{
+ bus_register_notifier(&pcmcia_bus_type, &bus_notifier);
+ return of_register_platform_driver(&electra_cf_driver);
+}
+module_init(electra_cf_init);
+
+static void __exit electra_cf_exit(void)
+{
+ bus_unregister_notifier(&pcmcia_bus_type, &bus_notifier);
+ of_unregister_platform_driver(&electra_cf_driver);
+}
+module_exit(electra_cf_exit);
+
+MODULE_LICENSE("GPL");
+MODULE_AUTHOR ("Olof Johansson <olof@lixom.net>");
+MODULE_DESCRIPTION("PA Semi Electra CF driver");
+
Index: powerpc/arch/powerpc/platforms/pasemi/setup.c
===================================================================
--- powerpc.orig/arch/powerpc/platforms/pasemi/setup.c
+++ powerpc/arch/powerpc/platforms/pasemi/setup.c
@@ -205,6 +205,7 @@ static void __init pas_init_early(void)
}
static struct of_device_id pasemi_bus_ids[] = {
+ { .type = "localbus", },
{ .type = "sdc", },
{},
};
^ permalink raw reply
* Re: [PATCH] pcmcia: ppc64 needs 32-bit ioaddr_t
From: Arnd Bergmann @ 2007-06-25 1:35 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Olof Johansson, akpm, linux-pcmcia, paulus, linux-kernel
In-Reply-To: <20070625005439.GA31289@lixom.net>
On Monday 25 June 2007, Olof Johansson wrote:
> ppc64 really needs ioaddr_t to be 32-bit, since I/O addresses really are
> MMIO addresses, and remapped at an offset that's well above 16 bits in
> some cases.
>
> While the type is exported to userspace, there hasn't been any platforms
> with PCMCIA on 64-bit powerpc until now, so changing it won't regress
> any existing users.
I just realized that this argument is bogus, because the user space tools
are probably, or at least potentially, built as 32 bit binaries, which
means that any interface using these _will_ break.
However, I could not find any actual user space interfaces in 2.6.22-rc
that are built around ioaddr_t. What are they, or have the been removed
by now?
Arnd <><
^ permalink raw reply
* Re: [Cbe-oss-dev] [patch 1/5] cell: pmi remove support for mutiple devices.
From: Akinobu Mita @ 2007-06-25 1:44 UTC (permalink / raw)
To: Christian Krafft
Cc: Akinobu Mita, cbe-oss-dev@ozlabs.org, linuxppc-dev@ozlabs.org
In-Reply-To: <20070622161039.2d863fd9@localhost>
>> > -kfree(dev->dev.driver_data);
>> > +kfree(data);
>>
>> Shouldn't it set data = NULL here?
>>
>> I guess we will get "pmi: driver has already been initialized" message
>> and -EBUSY on reloading pmi driver.
>>
>> >
>> > return 0;
>> > }
>
> That problem did actually not occur.
> Anyway, I added the line for completeness and consistency.
The data is located in module data. So unloading module clean up
the data, too. I missed it.
In order to test the problem I said, we need to re-probe pmi driver
without unloading pmi driver. (http://lwn.net/Articles/143397/)
I hope your updated version of patch fixes the problem.
^ permalink raw reply
* Re: [PATCH] ppc: Marvell mv64x60 drivers for ppc platforms fix
From: Kumar Gala @ 2007-06-25 1:49 UTC (permalink / raw)
To: Dale Farnsworth; +Cc: linuxppc-dev
In-Reply-To: <20070624224652.2950.qmail@farnsworth.org>
On Jun 24, 2007, at 5:46 PM, Dale Farnsworth wrote:
> In article <200706241552.31483.yur@emcraft.com> you write:
>> This patch fixes the issue of erroneously involving the
>> arch/powerpc/sysdev/mv64x60*.c files into the compilation
>> process for ppc- (not powerpc-) based platforms (e.g.,
>> P3M750).
>>
>> Signed-off-by: Yuri Tikhonov <yur@emcraft.com>
>>
>> --
>>
>> diff --git a/arch/powerpc/sysdev/Makefile b/arch/powerpc/sysdev/
>> Makefile
>> index c3ce0bd..25eaa14 100644
>> --- a/arch/powerpc/sysdev/Makefile
>> +++ b/arch/powerpc/sysdev/Makefile
>> @@ -17,7 +17,9 @@ obj-$(CONFIG_FSL_PCIE) += fsl_pcie.o
>> obj-$(CONFIG_TSI108_BRIDGE) += tsi108_pci.o tsi108_dev.o
>> obj-$(CONFIG_QUICC_ENGINE) += qe_lib/
>> mv64x60-$(CONFIG_PCI) += mv64x60_pci.o
>
> Shouldn't the above line also be placed inside the of following ifeq ?
>
>> +ifeq ($(CONFIG_PPC_MERGE),y)
>> obj-$(CONFIG_MV64X60) += $(mv64x60-y) mv64x60_pic.o mv64x60_dev.o
>> +endif
>>
>> # contains only the suspend handler for time
>> obj-$(CONFIG_PM) += timer.o
Also, lets just move these into the existing ifeq
($CONFIG_PPC_MERGE,y) block in that makefile rather than introducing
a new one.
- k
^ permalink raw reply
* Re: [PATCH] pcmcia: ppc64 needs 32-bit ioaddr_t
From: Olof Johansson @ 2007-06-25 2:42 UTC (permalink / raw)
To: Arnd Bergmann; +Cc: akpm, linuxppc-dev, linux-pcmcia, paulus, linux-kernel
In-Reply-To: <200706250335.56739.arnd@arndb.de>
On Mon, Jun 25, 2007 at 03:35:56AM +0200, Arnd Bergmann wrote:
> On Monday 25 June 2007, Olof Johansson wrote:
> > ppc64 really needs ioaddr_t to be 32-bit, since I/O addresses really are
> > MMIO addresses, and remapped at an offset that's well above 16 bits in
> > some cases.
> >
> > While the type is exported to userspace, there hasn't been any platforms
> > with PCMCIA on 64-bit powerpc until now, so changing it won't regress
> > any existing users.
>
> I just realized that this argument is bogus, because the user space tools
> are probably, or at least potentially, built as 32 bit binaries, which
> means that any interface using these _will_ break.
Fortunately, on the userspace ABI, it should just be the cardmgr
ioctls that are affected. In this case there are no current 64-bit PPC
platforms with PCMCIA, so there are no existing users to regress. New
users (with 32-bit userspace) shouldn't be using the cardmgr tools.
So yes, someone who takes an old 32-bit userspace with cardmgr, moves
it to a new 64-bit platform and expects the old 32-bit tools to work
will find that they don't. Not that they would have otherwise either.
> However, I could not find any actual user space interfaces in 2.6.22-rc
> that are built around ioaddr_t. What are they, or have the been removed
> by now?
Last time I posted this I got the answer from Christoph that it's cardmgr
and the ioctl interface it uses, and there's still users out there that
have been neglecting the error messages, etc.
Unfortunately, ioaddr_t is used both in the ioctl interface as well as
to pass around some of the same structures within the kernel. So I could
either do major overhaul of the PCMCIA stack, or change this type for
ppc64. I went for the latter given that MIPS and ARM obviously already
got away with doing it.
-Olof
^ permalink raw reply
* Re: [PATCH v3] Create add_rtc() function to enable the RTC CMOS driver
From: David Gibson @ 2007-06-25 3:33 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: linuxppc-dev, paulus
In-Reply-To: <ba34492532ac9dfd43bd9f2ae427deef@kernel.crashing.org>
On Fri, Jun 22, 2007 at 09:56:24AM +0200, Segher Boessenkool wrote:
> > Hrm. It seems rather specific. Can we do this more generally, by
> > creating an of_platform device which binds to rtc nodes, then
> > registers an appropriate platform device for each so that the generic
> > rtc drivers pick them up. Obviously we'd need some sort of table
> > mapping the device node compatible properties to the appropriate
> > platform device names.
>
> >> + * RTC_PORT(x) is hardcoded in asm/mc146818rtc.h. Verify that the
> >> + * address provided by the device node matches.
> >> + */
> >> + if (res.start != RTC_PORT(0)) {
> >> + of_node_put(np);
> >> + return -ENODEV;
> >> + }
> >
> > This looks totally bogus. If we have a device tree we should be using
> > the address information from there, not using hardcoded magic. Sounds
> > like asm/mc146818rtc.h needs some serious fixing.
>
> Both of your comments would be nice extensions (and the right
> way forwards), but Wade's patch is good as-is already.
True enough.
--
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
^ permalink raw reply
* Re: [PATCH] pcmcia: ppc64 needs 32-bit ioaddr_t
From: Christoph Hellwig @ 2007-06-25 5:53 UTC (permalink / raw)
To: Olof Johansson; +Cc: akpm, linuxppc-dev, linux-pcmcia, paulus, linux-kernel
In-Reply-To: <20070625005439.GA31289@lixom.net>
On Sun, Jun 24, 2007 at 07:54:39PM -0500, Olof Johansson wrote:
> ppc64 really needs ioaddr_t to be 32-bit, since I/O addresses really are
> MMIO addresses, and remapped at an offset that's well above 16 bits in
> some cases.
>
> While the type is exported to userspace, there hasn't been any platforms
> with PCMCIA on 64-bit powerpc until now, so changing it won't regress
> any existing users.
Drivers should be using kio_addr_t, please fix up the remaining drivers
to do this instead of chaning the user-visible type.
^ permalink raw reply
* Re: [PATCH] pcmcia: CompactFlash driver for PA Semi Electra boards
From: Christoph Hellwig @ 2007-06-25 5:56 UTC (permalink / raw)
To: Olof Johansson; +Cc: linuxppc-dev, Russell King, linux-pcmcia, linux-kernel
In-Reply-To: <20070625010311.GA31355@lixom.net>
> +static int bus_notify(struct notifier_block *nb, unsigned long action,
> + void *data)
> +{
> + struct device *dev = data;
> +
> + printk("bus notify called\n");
> +
> + /* We are only intereted in device addition */
> + if (action != BUS_NOTIFY_ADD_DEVICE)
> + return 0;
> +
> + /* We use the direct ops for localbus */
> + dev->archdata.dma_ops = &dma_direct_ops;
> +
> + return 0;
> +}
Sorry for not coming back to you after the last posting of the patch,
but I still really this bit of the code. We don't set dma ops from
a driver anywhere else in the tree, so I'd really prefer if you could
handle this in architecture code somewhere. Especially as dma_direct_ops
and the pcmcia_bug_type shouldn't really be something exported to users.
Also this code is unlogic if not buggy. Just because you have one
electra bridge it doesn't mean all pcmcia is driven by it. In fact I'm
pretty sure there are cardbus/pcmcia bridges that can be plugged into
plain pci slots.
^ permalink raw reply
* Fwd: PowerPC 8248
From: 张乐 @ 2007-06-25 6:23 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <be40b9670706242309y338390b6j1ff91d0c9d5e8995@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1341 bytes --]
Dear Sir：
I am a graduate student from Tsinghua University, China, I came to the
same problem that seems once you got and wrote on the PPC embeded forum,
that, with u-boot 1.1.1 from freesacle, I can not port my 8248/8272 from 2.4to
2.6 kernel.
I saw your answer is that to edit "arch/ppc/platforms/pq2ads.h" and
change the "#define BCSR_ADDR ((uint) 0xf4500000)" to match the u-boot
"u-boot/include/configs/MPC8260ADS.h".
I follow this, and it still no lucky, but there is a difference
between the two kernel, before I edited BCSR_ADDR, the new kernel just hang,
after I edit it, the new kernel is just restart the right place where it
hangs.
I got my kernel from kernel.org (2.6.13), and I wonder is there
something else I should pay attention, or got my kernel from someother
place?
I am looking forward to your reply and best regards!
--
张乐
Zhangle
CERNET, Tsinghua University
zhangyuting@gmail.com
Mobile: +861369-309-1200
Office: 010-62603928
Lab: 010-62603318
Addr: FIT 4-204, TSINGHUA UNIV., China
Lab Addr: FIT 1-210, TSINGHUA UNIV., China
Postcode: 100084
--
张乐
Zhangle
CERNET, Tsinghua University
zhangyuting@gmail.com
Mobile: +861369-309-1200
Office: 010-62603928
Lab: 010-62603318
Addr: FIT 4-204, TSINGHUA UNIV., China
Lab Addr: FIT 1-210, TSINGHUA UNIV., China
Postcode: 100084
[-- Attachment #2: Type: text/html, Size: 2366 bytes --]
^ permalink raw reply
* Re: [PATCH] powerpc: setup Marvell mv64x60 platform devices for EDAC
From: Paul Mackerras @ 2007-06-25 6:30 UTC (permalink / raw)
To: Dave Jiang; +Cc: linuxppc-dev, dfarnsworth
In-Reply-To: <20070522232432.GA26046@blade.az.mvista.com>
Dave Jiang writes:
> The mv64x60 EDAC driver can be found at:
> http://bluesmoke.sourceforge.net/
>
> It's in development to be pushed into the kernel.
Am I correct in thinking this patch is useless without that driver?
Is that driver being submitted for 2.6.23? If so, who is submitting
it and to whom? Does it look like it will be accepted?
Paul.
^ permalink raw reply
* Re: Mem-2-Mem DMA - Generalized API
From: Clifford Wolf @ 2007-06-25 8:03 UTC (permalink / raw)
To: Arnd Bergmann; +Cc: linuxppc-embedded
In-Reply-To: <200706242221.57507.arnd@arndb.de>
Hi,
On Sun, Jun 24, 2007 at 10:21:57PM +0200, Arnd Bergmann wrote:
> On Sunday 24 June 2007, Clifford Wolf wrote:
> > I'm working on an MPC8349E based project and as some of you might know this
> > chip has a four channel (bus-) memory-to-memory DMA controller.
> >
> > Unfortunately the linux kernel is atm lacking a generic interface for such
> > DMA controllers.
>
> So what's wrong with the include/linux/dmaengine.h API? I thought it was
> designed to cover this sort of DMA controller?
nothing. I was just to blind to find it.. ;-)
though there are some points:
on the first glimpse it seams like this api does not support scatter/gather
and fifo mode, right? in fact that's no problem at all for my project but
it would be a pity to lose that hardware functionality because of the api..
i have also had a quick look at the ioatdma driver and it apears to me that
it can only operate on address regions which are visible on the pci bus.
The MPC8349E dma can operate on everything which is visible on the coherent
local bus, i.e. everything that is also visible to the cpu. there seams to
be no way to specify the bus a dma channel is needed for when requesting a
channel thru this interface.
It also appears to me that the dmaengine.h API is not capable of
overcommiting. I.e. assigning a small pool of dma channels to a big pool of
drivers in the hope that not all of the drivers are doing dma transfers at
the same time (and schedule transfers if this assumtion turns out to be
wrong).
Wouldn't it be better to let the backend handle stuff like binding dma
channels to specific cpus and let the user just commit dma requests which
are then scheduled to the dma channel which fits the needs best (or done in
cpu if no dma channel exists which would be capable of doing this kind of
transfer)?
yours,
- clifford
--
"The generation of random numbers is too important to be left to chance."
- Robert R. Coveyou, Oak Ridge National Laboratory.
^ permalink raw reply
* Re: [patch] PS3: Fix USB return value
From: Greg KH @ 2007-06-25 7:30 UTC (permalink / raw)
To: Geoff Levand; +Cc: owen, gregkh, Paul Mackerras, linux-usb-devel, linuxppc-dev
In-Reply-To: <4669E4BD.7060002@am.sony.com>
On Fri, Jun 08, 2007 at 04:22:37PM -0700, Geoff Levand wrote:
> Fix a minor error on the return value of ps3_ehci_driver_register()
> and ps3_ohci_driver_register() when running on non-PS3 systems.
>
> Signed-off-by: Geoff Levand <geoffrey.levand@am.sony.com>
> ---
> Hi Greg,
>
> Testers found a problem with my latest PS3 USB patch. Please
> add it in.
I've merged this with your previous one so that no one hits the bug when
doing a 'git bisect'.
thanks,
greg k-h
^ permalink raw reply
* Re: [PATCH] ppc: Marvell mv64x60 drivers for ppc platforms fix
From: Yuri Tikhonov @ 2007-06-25 8:47 UTC (permalink / raw)
To: linuxppc-dev
Hi Dale, Kumar,
Thank you for your comments. All they make sense. Here is an update.
--
diff --git a/arch/powerpc/sysdev/Makefile b/arch/powerpc/sysdev/Makefile
index c3ce0bd..37c37a9 100644
--- a/arch/powerpc/sysdev/Makefile
+++ b/arch/powerpc/sysdev/Makefile
@@ -16,8 +16,6 @@ obj-$(CONFIG_FSL_SOC) += fsl_soc.o
obj-$(CONFIG_FSL_PCIE) += fsl_pcie.o
obj-$(CONFIG_TSI108_BRIDGE) += tsi108_pci.o tsi108_dev.o
obj-$(CONFIG_QUICC_ENGINE) += qe_lib/
-mv64x60-$(CONFIG_PCI) += mv64x60_pci.o
-obj-$(CONFIG_MV64X60) += $(mv64x60-y) mv64x60_pic.o mv64x60_dev.o
# contains only the suspend handler for time
obj-$(CONFIG_PM) += timer.o
@@ -26,6 +24,8 @@ ifeq ($(CONFIG_PPC_MERGE),y)
obj-$(CONFIG_PPC_I8259) += i8259.o
obj-$(CONFIG_PPC_83xx) += ipic.o
obj-$(CONFIG_4xx) += uic.o
+mv64x60-$(CONFIG_PCI) += mv64x60_pci.o
+obj-$(CONFIG_MV64X60) += $(mv64x60-y) mv64x60_pic.o mv64x60_dev.o
endif
# Temporary hack until we have migrated to asm-powerpc
^ permalink raw reply related
* Re: [PATCH] ppc: Marvell mv64x60 drivers for ppc platforms fix
From: Segher Boessenkool @ 2007-06-25 9:11 UTC (permalink / raw)
To: Yuri Tikhonov; +Cc: linuxppc-dev
In-Reply-To: <200706251247.51518.yur@emcraft.com>
> +mv64x60-$(CONFIG_PCI) += mv64x60_pci.o
> +obj-$(CONFIG_MV64X60) += $(mv64x60-y) mv64x60_pic.o
> mv64x60_dev.o
How about
mv64x60-pci-$(CONFIG_PCI) += mv64x60_pci.o
mv64x60-objs := $(mv64x60-pci-y) mv64x60_pic.o
mv64x60_dev.o
obj-$(CONFIG_MV64X60) += mv64x60.o
so you can build it is a module, too (although other things
might be preventing that right now)?
Segher
^ permalink raw reply
* Re: [PATCH] ppc: Marvell mv64x60 drivers for ppc platforms fix
From: Yuri Tikhonov @ 2007-06-25 9:51 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: linuxppc-dev
In-Reply-To: <c14777659bdfd350085cf8c3ae648b20@kernel.crashing.org>
Hi Segher,
The mv64x60 driver has no support for compiling as a module. Built-in only.
And I think there is no much sense in making the driver which provide you
with such a base stuff as a boot console, ethernet, etc. to be a LKM.
Regards, Yuri.
On Monday 25 June 2007 13:11, you wrote:
> > +mv64x60-$(CONFIG_PCI) += mv64x60_pci.o
> > +obj-$(CONFIG_MV64X60) += $(mv64x60-y) mv64x60_pic.o
> > mv64x60_dev.o
>
> How about
>
> mv64x60-pci-$(CONFIG_PCI) += mv64x60_pci.o
> mv64x60-objs := $(mv64x60-pci-y) mv64x60_pic.o
> mv64x60_dev.o
> obj-$(CONFIG_MV64X60) += mv64x60.o
>
> so you can build it is a module, too (although other things
> might be preventing that right now)?
>
>
> Segher
^ permalink raw reply
* RE: ML403 gigabit ethernet bandwidth - 2.6 kernel
From: Ming Liu @ 2007-06-25 10:03 UTC (permalink / raw)
To: mamsadegh; +Cc: akonovalov, linuxppc-embedded
In-Reply-To: <BAY115-W543A1618F5BCC720DEFE8B2150@phx.gbl>
Dear Mohammad,
>The results are as follows:
>PC-->ML403
>TCP_SENDFILE : 38Mbps
>
>ML403--->PC
>TCP_SENDFILE: 155Mbps
This result is unreasonable. Because PC is more powerful than your board,
so PC->board should be faster than board->PC.
>The transfer rate from ML403 to PC has improved by a factor of 2,
>I see on the posts here in the mailing list that you have reached a band
width of 301Mbps.
Yes, with all features which could improve performance enabled, we can get
around 300Mbps for TCP transfer. one more hint, did you enable caches on
your system? perhaps it will help. Anyway, double check your hardware
design to make sure all features are enabled.That's all I can suggest.
BR
Ming
>
>
>
>
>----------------------------------------
> > From: eemingliu@hotmail.com
> > To: mamsadegh@hotmail.com; akonovalov@ru.mvista.com;
linuxppc-embedded@ozlabs.org; grant.likely@secretlab.ca
> > Subject: RE: ML403 gigabit ethernet bandwidth - 2.6 kernel
> > Date: Sat, 23 Jun 2007 19:10:16 +0000
> >
> > Use the following command in Linux please:
> >
> > ifconfig eth0 mtu 8982
> >
> > As well you should do that on your PC in the measurement.
> >
> > Ming
> >
> >
> > >From: Mohammad Sadegh Sadri
> > >To: Ming Liu ,
> > ,,
> >
> > >Subject: RE: ML403 gigabit ethernet bandwidth - 2.6 kernel
> > >Date: Sat, 23 Jun 2007 19:08:29 +0000
> > >
> > >
> > >Dear Ming,
> > >
> > >Really thanks for reply,
> > >
> > >about thresholds and waitbound OK! I'll adjust them in adapter.c ,
> > >
> > >but what about enabling jumbo frames? should I do any thing special to
> > enable Jumbo fram support?
> > >
> > >we were thinking that it is enabled by default. Is it?
> > >
> > >thanks
> > >
> > >
> > >
> > >
> > >----------------------------------------
> > > > From: eemingliu@hotmail.com
> > > > To: mamsadegh@hotmail.com; akonovalov@ru.mvista.com;
> > linuxppc-embedded@ozlabs.org; grant.likely@secretlab.ca
> > > > Subject: RE: ML403 gigabit ethernet bandwidth - 2.6 kernel
> > > > Date: Sat, 23 Jun 2007 18:48:19 +0000
> > > >
> > > > Dear Mohammad,
> > > > There are some parameters which could be adjusted to improve the
> > > > performance. They are: TX and RX_Threshold TX and RX_waitbound. In
my
> > > > system, we use TX_Threshold=16 and Rx_Threshold=8 and both
waitbound=1.
> > > >
> > > > Also Jumbo frame of 8982 could be enable.
> > > >
> > > > Try those hints and share your improvement with us.
> > > >
> > > > BR
> > > > Ming
> > > >
> > > > >From: Mohammad Sadegh Sadri
> > > > >To: Andrei Konovalov , Linux PPC Linux
> > > > PPC, Grant Likely
> > > > >Subject: ML403 gigabit ethernet bandwidth - 2.6 kernel
> > > > >Date: Sat, 23 Jun 2007 12:19:12 +0000
> > > > >
> > > > >
> > > > >Dear all,
> > > > >
> > > > >Recently we did a set of tests on performance of virtex 4FX hard
TEMAC
> > > > module using ML403
> > > > >
> > > > >we studied all of the posts here carefully: these are the system
> > > > characteristics;
> > > > >
> > > > >Board : ML403
> > > > >EDK : EDK9.1SP2
> > > > >Hard TEMAC version and PLTEMAC version are both 3.0.a
> > > > >PPC clock frequency : 300MHz
> > > > >Kernel : 2.6.21-rc7 , downloaded from grant's git tree some thing
near
> > one
> > > > week ago
> > > > >DMA type: 3 (sg dma)
> > > > >DRE : enabled for TX and RX, (2)
> > > > >CSUM offload is enabled for both of TX and RX
> > > > >tx and rx fifo sizes : 131072 bits
> > > > >
> > > > >the board comes up over NFS root file system completely and
without
> > any
> > > > problems.
> > > > >
> > > > >PC system used for these tests is : CPU P4 Dual Core, 3.4GHz ,
> > 2Gigabytes
> > > > memory, Dual gigabit ethernet port, running linux 2.6.21.3
> > > > >We have tested the PC system band width and it can easily reach
> > 966mbits/s
> > > > when connected to the same PC. ( using the same cross cable used
for
> > ml403
> > > > test)
> > > > >
> > > > >Netperf is compiled with TCP SEND FILE enabled, ( -DHAVE_SENDFILE)
> > > > >
> > > > >(from board to PC)
> > > > >netperf -t TCP_SENDFILE -H 10.10.10.250 -F /boot/zImage.elf -- -m
> > 16384 -s
> > > > 87380 -S 87380
> > > > >
> > > > >the measured bandwidth for this test was just 40.66Mbits.
> > > > >It is also true for netperf from PC to board.
> > > > >
> > > > >we do not have any more idea about what we should do to improve
the
> > > > bandwidth.
> > > > >any help or ideas is appreciated...
> > > > >
> > > > >_________________________________________________________________
> > > > >Connect to the next generation of MSN
> > > >
> >
Messenger?>http://imagine-msn.com/messenger/launch80/default.aspx?locale=en-us&source=wlmailtagline
> >
> > > >
> > > > >_______________________________________________
> > > > >Linuxppc-embedded mailing list
> > > > >Linuxppc-embedded@ozlabs.org
> > > > >https://ozlabs.org/mailman/listinfo/linuxppc-embedded
> > > >
> > > > _________________________________________________________________
> > > > 免费下载 MSN Explorer: http://explorer.msn.com/lccn/
> > > >
> > >
> > >_________________________________________________________________
> > >News, entertainment and everything you care about at Live.com. Get it
now!
> > >http://www.live.com/getstarted.aspx
> >
> > _________________________________________________________________
> > 免费下载 MSN Explorer: http://explorer.msn.com/lccn/
> >
>
>_________________________________________________________________
>Discover the new Windows Vista
>http://search.msn.com/results.aspx?q=windows+vista&mkt=en-US&form=QBRE
_________________________________________________________________
免费下载 MSN Explorer: http://explorer.msn.com/lccn/
^ permalink raw reply
* Re: [PATCH] ppc: Marvell mv64x60 drivers for ppc platforms fix
From: Segher Boessenkool @ 2007-06-25 10:14 UTC (permalink / raw)
To: Yuri Tikhonov; +Cc: linuxppc-dev
In-Reply-To: <200706251351.55868.yur@emcraft.com>
> The mv64x60 driver has no support for compiling as a module. Built-in
> only.
Yeah I expected that that is the case right now. Could be
fixed later though.
> And I think there is no much sense in making the driver which provide
> you
> with such a base stuff as a boot console, ethernet, etc. to be a LKM.
That's orthogonal to expressing it as one "module" in Kbuild,
which is really just about grouping highly interdependent
stuff together.
But anyway, your patch looks good, I was just suggesting to
clean it up some more. You don't have to do it now if you
don't want to, I'm sure it will happen later :-)
[Oh, and don't top-post.]
>>> +mv64x60-$(CONFIG_PCI) += mv64x60_pci.o
>>> +obj-$(CONFIG_MV64X60) += $(mv64x60-y) mv64x60_pic.o
>>> mv64x60_dev.o
>>
>> How about
>>
>> mv64x60-pci-$(CONFIG_PCI) += mv64x60_pci.o
>> mv64x60-objs := $(mv64x60-pci-y) mv64x60_pic.o
>> mv64x60_dev.o
>> obj-$(CONFIG_MV64X60) += mv64x60.o
>>
>> so you can build it is a module, too (although other things
>> might be preventing that right now)?
Segher
^ permalink raw reply
* [PATCH] Fix VDSO gettimeofday() when called with NULL struct timeval.
From: Tony Breeds @ 2007-06-25 10:58 UTC (permalink / raw)
To: LinuxPPC-dev, Paul Mackerras
Hi Paul,
It'd be nice if this made it into 2.6.22, esp. now that more
distros are shipping glibc's that will use the VDSO.
I think I got the asm right, it works on pSerie, either way feedback
welcome.
From: Tony Breeds <tony@bakeyournoodle.com>
Fix VDSO gettimeofday() when called with NULL struct timeval.
Consider the prototype for gettimeofday():
int gettimofday(struct timeval *tv, struct timezone *tz);
AFAICT it is valid to call with /either/ tv or tz being NULL, the C version
of sys_gettimeofday() supports this, the current version of gettimeofday() in
the VDSO will SEGV if called with a NULL tv.
This patch fixes this.
Signed-off-by: Tony Breeds <tony@bakeyournoodle.com>
CC: Benjamin Herrenschmidt <benh@kernel.crashing.org>
---
arch/powerpc/kernel/vdso32/gettimeofday.S | 13 +++++++------
arch/powerpc/kernel/vdso64/gettimeofday.S | 8 +++++---
2 files changed, 12 insertions(+), 9 deletions(-)
Index: working/arch/powerpc/kernel/vdso32/gettimeofday.S
===================================================================
--- working.orig/arch/powerpc/kernel/vdso32/gettimeofday.S 2007-06-25 19:35:47.000000000 +1000
+++ working/arch/powerpc/kernel/vdso32/gettimeofday.S 2007-06-25 19:40:34.000000000 +1000
@@ -32,8 +32,10 @@ V_FUNCTION_BEGIN(__kernel_gettimeofday)
mr r11,r4 /* r11 saves tz */
bl __get_datapage@local /* get data page */
mr r9, r3 /* datapage ptr in r9 */
+ cmpli cr0,r10,0 /* check if tv is NULL */
+ beq 1f
bl __do_get_xsec@local /* get xsec from tb & kernel */
- bne- 2f /* out of line -> do syscall */
+ bne- 3f /* out of line -> do syscall */
/* seconds are xsec >> 20 */
rlwinm r5,r4,12,20,31
@@ -50,20 +52,19 @@ V_FUNCTION_BEGIN(__kernel_gettimeofday)
mulhwu r5,r5,r6
stw r5,TVAL32_TV_USEC(r10)
- cmpli cr0,r11,0 /* check if tz is NULL */
- beq 1f
+1: cmpli cr0,r11,0 /* check if tz is NULL */
+ beq 2f
lwz r4,CFG_TZ_MINUTEWEST(r9)/* fill tz */
lwz r5,CFG_TZ_DSTTIME(r9)
stw r4,TZONE_TZ_MINWEST(r11)
stw r5,TZONE_TZ_DSTTIME(r11)
-1: mtlr r12
+2: mtlr r12
crclr cr0*4+so
li r3,0
blr
-2:
- mtlr r12
+3: mtlr r12
mr r3,r10
mr r4,r11
li r0,__NR_gettimeofday
Index: working/arch/powerpc/kernel/vdso64/gettimeofday.S
===================================================================
--- working.orig/arch/powerpc/kernel/vdso64/gettimeofday.S 2007-06-25 19:35:52.000000000 +1000
+++ working/arch/powerpc/kernel/vdso64/gettimeofday.S 2007-06-25 19:42:45.000000000 +1000
@@ -32,6 +32,8 @@ V_FUNCTION_BEGIN(__kernel_gettimeofday)
mr r11,r3 /* r11 holds tv */
mr r10,r4 /* r10 holds tz */
bl V_LOCAL_FUNC(__get_datapage) /* get data page */
+ cmpldi cr0,r11,0 /* check if tv is NULL */
+ beq 1f
bl V_LOCAL_FUNC(__do_get_xsec) /* get xsec from tb & kernel */
lis r7,15 /* r7 = 1000000 = USEC_PER_SEC */
ori r7,r7,16960
@@ -43,14 +45,14 @@ V_FUNCTION_BEGIN(__kernel_gettimeofday)
* XSEC_PER_SEC
*/
rldicl r0,r0,44,20
- cmpldi cr0,r10,0 /* check if tz is NULL */
+1: cmpldi cr0,r10,0 /* check if tz is NULL */
std r0,TVAL64_TV_USEC(r11) /* store usec in tv */
- beq 1f
+ beq 2f
lwz r4,CFG_TZ_MINUTEWEST(r3)/* fill tz */
lwz r5,CFG_TZ_DSTTIME(r3)
stw r4,TZONE_TZ_MINWEST(r10)
stw r5,TZONE_TZ_DSTTIME(r10)
-1: mtlr r12
+2: mtlr r12
crclr cr0*4+so
li r3,0 /* always success */
blr
Yours Tony
linux.conf.au http://linux.conf.au/ || http://lca2008.linux.org.au/
Jan 28 - Feb 02 2008 The Australian Linux Technical Conference!
^ permalink raw reply
* Re: Mem-2-Mem DMA - Generalized API
From: Matt Sealey @ 2007-06-25 11:03 UTC (permalink / raw)
To: Arnd Bergmann; +Cc: linuxppc-embedded
In-Reply-To: <200706242221.57507.arnd@arndb.de>
IOAT and Intel's DMA engine driver is very IOAT specific in places..
I had a peek at it as I have a little interest in the concept; at least the
two platforms Genesi has been supporting (Pegasos and Efika) have quite
competant DMA engines which are woefully underused (i.e. not at all).
There exists a Marvell DMA driver somewhere (I have a copy, someone on
this list posted it about a year ago) and while the MPC5200B doesn't have
explicit support for DMA from memory to memory (although memory to SRAM
might work in chunks, or memory to a FIFO wired as a loopback like in
the docs..??)
There is so much you can do with most SoC DMA controllers, and it's not
even limited to PowerPC (most ARM/XScale SoCs have very capable devices
inside too). I can only imagine that nobody got excited over IOAT because
the entire programming interface stinks of "offloading gigabit ethernet"
and not much else.
--
Matt Sealey <matt@genesi-usa.com>
Genesi, Manager, Developer Relations
Arnd Bergmann wrote:
> On Sunday 24 June 2007, Clifford Wolf wrote:
>> I'm working on an MPC8349E based project and as some of you might know this
>> chip has a four channel (bus-) memory-to-memory DMA controller.
>>
>> Unfortunately the linux kernel is atm lacking a generic interface for such
>> DMA controllers.
>
> So what's wrong with the include/linux/dmaengine.h API? I thought it was
> designed to cover this sort of DMA controller?
>
> Arnd <><
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
^ permalink raw reply
* Re: ML403 gigabit ethernet bandwidth - 2.6 kernel
From: Bhupender Saharan @ 2007-06-25 11:52 UTC (permalink / raw)
To: Mohammad Sadegh Sadri; +Cc: Andrei Konovalov, Linux PPC Linux PPC
In-Reply-To: <BAY115-W1188529D49F71948165AF6B2160@phx.gbl>
[-- Attachment #1: Type: text/plain, Size: 2193 bytes --]
Hi,
We need to findout where is the bottlenect.
1. Run vmstat on the ML403 board and find out the percentage CPU is busy
when you are transferring the file. That will show if cpu is busy or not.
2. Run oprofile and find out which are the routines eating away the cpu
time.
Once we have data from both the above routines, we can find out the
bottlenecks.
Regards
Bhupi
On 6/23/07, Mohammad Sadegh Sadri <mamsadegh@hotmail.com> wrote:
>
>
> Dear all,
>
> Recently we did a set of tests on performance of virtex 4FX hard TEMAC
> module using ML403
>
> we studied all of the posts here carefully: these are the system
> characteristics;
>
> Board : ML403
> EDK : EDK9.1SP2
> Hard TEMAC version and PLTEMAC version are both 3.0.a
> PPC clock frequency : 300MHz
> Kernel : 2.6.21-rc7 , downloaded from grant's git tree some thing near one
> week ago
> DMA type: 3 (sg dma)
> DRE : enabled for TX and RX, (2)
> CSUM offload is enabled for both of TX and RX
> tx and rx fifo sizes : 131072 bits
>
> the board comes up over NFS root file system completely and without any
> problems.
>
> PC system used for these tests is : CPU P4 Dual Core, 3.4GHz , 2Gigabytes
> memory, Dual gigabit ethernet port, running linux 2.6.21.3
> We have tested the PC system band width and it can easily reach 966mbits/s
> when connected to the same PC. ( using the same cross cable used for ml403
> test)
>
> Netperf is compiled with TCP SEND FILE enabled, ( -DHAVE_SENDFILE)
>
> (from board to PC)
> netperf -t TCP_SENDFILE -H 10.10.10.250 -F /boot/zImage.elf -- -m 16384 -s
> 87380 -S 87380
>
> the measured bandwidth for this test was just 40.66Mbits.
> It is also true for netperf from PC to board.
>
> we do not have any more idea about what we should do to improve the
> bandwidth.
> any help or ideas is appreciated...
>
> _________________________________________________________________
> Connect to the next generation of MSN Messenger
>
> http://imagine-msn.com/messenger/launch80/default.aspx?locale=en-us&source=wlmailtagline
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
[-- Attachment #2: Type: text/html, Size: 2871 bytes --]
^ permalink raw reply
* Re: [PATCH] Fix VDSO gettimeofday() when called with NULL struct timeval.
From: Benjamin Herrenschmidt @ 2007-06-25 12:39 UTC (permalink / raw)
To: Tony Breeds; +Cc: LinuxPPC-dev, Paul Mackerras
In-Reply-To: <20070625105836.GE9768@bakeyournoodle.com>
> Index: working/arch/powerpc/kernel/vdso32/gettimeofday.S
> ===================================================================
> --- working.orig/arch/powerpc/kernel/vdso32/gettimeofday.S 2007-06-25 19:35:47.000000000 +1000
> +++ working/arch/powerpc/kernel/vdso32/gettimeofday.S 2007-06-25 19:40:34.000000000 +1000
> @@ -32,8 +32,10 @@ V_FUNCTION_BEGIN(__kernel_gettimeofday)
> mr r11,r4 /* r11 saves tz */
> bl __get_datapage@local /* get data page */
> mr r9, r3 /* datapage ptr in r9 */
> + cmpli cr0,r10,0 /* check if tv is NULL */
> + beq 1f
Please use cmplwi here.
> bl __do_get_xsec@local /* get xsec from tb & kernel */
> - bne- 2f /* out of line -> do syscall */
> + bne- 3f /* out of line -> do syscall */
>
> /* seconds are xsec >> 20 */
> rlwinm r5,r4,12,20,31
> @@ -50,20 +52,19 @@ V_FUNCTION_BEGIN(__kernel_gettimeofday)
> mulhwu r5,r5,r6
> stw r5,TVAL32_TV_USEC(r10)
>
> - cmpli cr0,r11,0 /* check if tz is NULL */
> - beq 1f
> +1: cmpli cr0,r11,0 /* check if tz is NULL */
> + beq 2f
And fix that one while at it :-) It's the same thing, but at least one
is explicit on the size of the comparison. Also, I don't think you need
to renumber the labels, or did I miss something ?
Cheers,
Ben.
^ permalink raw reply
* Re: [PATCH] powerpc: fix MAC address entries for 83xx, 85xx, and 86xx device trees
From: Josh Boyer @ 2007-06-25 12:50 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: linuxppc-dev, Timur Tabi
In-Reply-To: <70d005ce549921cc56481fe0b26faaa4@kernel.crashing.org>
On Sat, 2007-06-23 at 17:50 +0200, Segher Boessenkool wrote:
> > For the 83xx, 85xx, and 86xx device trees, add a "local-mac-address"
> > property
> > to every Ethernet node that didn't have one. Add a comment indicating
> > that
> > the "address" and/or "mac-address" properties are deprecated in DTS
> > files
> > and will be removed at a later time. Change all MAC address
> > properties to
> > have a zero MAC address value.
>
> Shouldn't you use the "??" notation instead, or is that
> still not implemented?
Not implemented.
josh
^ permalink raw reply
* Re: Mem-2-Mem DMA - Generalized API
From: Clemens Koller @ 2007-06-25 12:53 UTC (permalink / raw)
To: Matt Sealey; +Cc: Arnd Bergmann, linuxppc-embedded
In-Reply-To: <467FA0EA.3000607@genesi-usa.com>
Hello, Matt!
Matt Sealey schrieb:
> IOAT and Intel's DMA engine driver is very IOAT specific in places..
>
> I had a peek at it as I have a little interest in the concept; at least the
> two platforms Genesi has been supporting (Pegasos and Efika) have quite
> competant DMA engines which are woefully underused (i.e. not at all).
True.
> There exists a Marvell DMA driver somewhere (I have a copy, someone on
> this list posted it about a year ago) and while the MPC5200B doesn't have
> explicit support for DMA from memory to memory (although memory to SRAM
> might work in chunks, or memory to a FIFO wired as a loopback like in
> the docs..??)
>
> There is so much you can do with most SoC DMA controllers, and it's not
> even limited to PowerPC (most ARM/XScale SoCs have very capable devices
> inside too). I can only imagine that nobody got excited over IOAT because
> the entire programming interface stinks of "offloading gigabit ethernet"
> and not much else.
The main question remains: Is it possible to have a flexible cross platform
DMA API which handles even complex requests and does scheduling, prioritizing,
queuing, locking, (re-)building/caching of SG lists... automagically.
It could fall back to CPU's memcpy if the hardware doesn't have
the ability to use the DMA machine because all channels are already busy,
or the requested memory isn't DMAable or the request is just too small
that it doesn't make sense to setup a DMA channel.
Filling memory with zero is also a simple task for a DMA engine.
(Thinking about malloc() and memset())
The problem is IMHO similar to video acceleration. Within the
Xorg's XAA/EXA/whatever framework, the drivers accelerate certain
calls if the hardware has the capability to do so. Other calls fall back
to some default non accelerated memcpy() & friends.
Sounds like a lot of fun... replacing kernel's and libc's memcpy() with
memcpy_with_dma_if_possible(). :-)
Best regards,
--
Clemens Koller
__________________________________
R&D Imaging Devices
Anagramm GmbH
Rupert-Mayer-Straße 45/1
Linhof Werksgelände
D-81379 München
Tel.089-741518-50
Fax 089-741518-19
http://www.anagramm-technology.com
^ 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