Re: [PATCH] mlx4_en: fix transmit of packages when blue frame is enabled
On Mon, 2011-10-03 at 17:53 -0300, Thadeu Lima de Souza Cascardo wrote: .../... > > Can you also send me the output of ethtool -i? > > It seems that there is a problem with write combining on Power processors, > > we will check this issue. > > > > Yevgeny > > Hello, Yevgeny. > > You will find the output of ethtool -i below. > > I am copying Ben and powerpc list, in case this is an issue with Power > processors. They can provide us some more insight into this. May I get some background please ? :-) I'm not aware of a specific issue with write combining but I'd need to know more about what you are doing and the code to do it to comment on whether it should work or not. Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] memory hotplug: Correct page reservation checking
On Mon, 26 Sep 2011 10:22:33 -0500 Nathan Fontenot wrote: > The check to ensure that pages of recently added memory sections are correctly > marked as reserved before trying to online the memory is broken. The request > to online the memory fails with the following: > > kernel: section number XXX page number 256 not reserved, was it already > online? > > This updates the page reservation checking to check the pages of each memory > section of the memory block being onlined individually. Why was this only noticed now? Is there something unusual about the way in which you're using it, or has nobody ever used this code, or...? ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] mlx4_en: fix transmit of packages when blue frame is enabled
On Mon, Oct 03, 2011 at 02:56:08PM +, Yevgeny Petrilin wrote: > > Hello, Yevgeny. > > > > We use a MT26448 (lspci -v output bellow) on a POWER7. Any other > > information, tests or debug patches you want me to try, just tell me. > > > > I expected this was really not the proper fix, but thought it would be > > better to send it than just guess. Any clues what the problem might be? > > Perhaps, we would have to disable blue frame for this particular device? > > > > Regards, > > Cascardo. > > > > --- > > lspci output > > 0006:01:00.0 Ethernet controller: Mellanox Technologies MT26448 [ConnectX > > EN 10GigE, PCIe 2.0 5GT/s] (rev b0) > > --- > > lspci -v output > > 0006:01:00.0 0200: 15b3:6750 (rev b0) > > Subsystem: 1014:0416 > > Flags: bus master, fast devsel, latency 0, IRQ 31 > > Memory at 3da47be0 (64-bit, non-prefetchable) [size=1M] > > Memory at 3da47c00 (64-bit, prefetchable) [size=32M] > > Expansion ROM at 3da47bf0 [disabled] [size=1M] > > Capabilities: [40] Power Management version 3 > > Capabilities: [48] Vital Product Data > > Capabilities: [9c] MSI-X: Enable+ Count=128 Masked- > > Capabilities: [60] Express Endpoint, MSI 00 > > Capabilities: [100] Alternative Routing-ID Interpretation (ARI) > > Capabilities: [148] Device Serial Number 00-02-c9-03-00-0f-50-be > > Kernel driver in use: mlx4_core > > Kernel modules: mlx4_en, mlx4_core > > --- > > Cascardo, > > Can you also send me the output of ethtool -i? > It seems that there is a problem with write combining on Power processors, we > will check this issue. > > Yevgeny Hello, Yevgeny. You will find the output of ethtool -i below. I am copying Ben and powerpc list, in case this is an issue with Power processors. They can provide us some more insight into this. Thanks, Cascardo. --- # ethtool -i eth10 driver: mlx4_en version: 1.5.4.1 (March 2011) firmware-version: 2.9.4130 bus-info: 0006:01:00.0 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v2] powerpc: book3e: WSP: Add Chroma as a new WSP/PowerEN platform.
On 09/29/2011 09:27 PM, Jimi Xenidis wrote: > diff --git a/arch/powerpc/platforms/wsp/Kconfig > b/arch/powerpc/platforms/wsp/Kconfig > index ea2811c..a3eef8e 100644 > --- a/arch/powerpc/platforms/wsp/Kconfig > +++ b/arch/powerpc/platforms/wsp/Kconfig > @@ -1,6 +1,7 @@ > config PPC_WSP > bool > select PPC_A2 > + select GENERIC_TBSYNC > select PPC_ICSWX > select PPC_SCOM > select PPC_XICS > @@ -8,14 +9,20 @@ config PPC_WSP > select PCI > select PPC_IO_WORKAROUNDS if PCI > select PPC_INDIRECT_PIO if PCI > + select PPC_WSP_COPRO > default n > > menu "WSP platform selection" > depends on PPC_BOOK3E_64 > > config PPC_PSR2 > - bool "PSR-2 platform" > - select GENERIC_TBSYNC > + bool "PowerEN System Reference Platform 2" > + select EPAPR_BOOT > + select PPC_WSP > + default y > + > +config PPC_CHROMA > + bool "PowerEN PCIe Chroma Card" > select EPAPR_BOOT > select PPC_WSP > default y This is an existing problem with PSR2, but please don't hide "default y" in a menu (at least make it a menuconfig). As is, it's not obvious from looking at the toplevel platforms menu that these platforms are enabled at all. Further, PPC_WSP doesn't build on non-SMP (undefined references to boot_cpuid and get_hard_smp_processor_id in ics.c), but the platforms that select it don't depend on SMP. -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: Request_irq fails for IRQ2
Hi Scott,
I try to request an IRQ (IRQ2 and IRQ3 which are ineterrupt no 20 and 21 in
mpc8247)in my driver . The
Call fails in setup_irq in Manage.c at /kernel/irq.
Setup _irq returns -ENOSYS
if (desc->irq_data.chip == &no_irq_chip)
return -ENOSYS;
I found that I need to pass the virtual interrupt number instead of hardware
interrupt number.
So I added below piece of code
Below is the call to request irq in my driver.
virq = irq_create_mapping(NULL, CPLD1_INTERRUPT);
if ((ret = request_irq(virq,cpld_irq_handler, 0, GPIO_CHAR_PATH, NULL))!=0)
{
printk(KERN_ERR "gpio_init: Could not grab IRQ line for CPLD ret =
%d\n",ret);
goto err1;
}
Now it fails in irq_create_mapping with NO_IRQ error.
if (controller == NULL)
host = irq_default_host;
else
host = irq_find_host(controller);
if (host == NULL) {
printk(KERN_WARNING "irq: no irq host found for %s !\n",
controller->full_name);
return NO_IRQ;
}
I just don't know what I should pass for host , also when I pass NULL for host
. I see the default host is NULL..
Could you please help me. My project delivery is near , I need help soon.
Regards,
Smitha
Please do not print this email unless it is absolutely necessary.
The information contained in this electronic message and any attachments to
this message are intended for the exclusive use of the addressee(s) and may
contain proprietary, confidential or privileged information. If you are not the
intended recipient, you should not disseminate, distribute or copy this e-mail.
Please notify the sender immediately and destroy all copies of this message and
any attachments.
WARNING: Computer viruses can be transmitted via email. The recipient should
check this email and any attachments for the presence of viruses. The company
accepts no liability for any damage caused by any virus transmitted by this
email.
www.wipro.com
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [RFC PATCH 2/2 -mm] RapidIO: TSI721 Add DMA Engine support
Andrew Morton wroye:
>
> On Fri, 30 Sep 2011 17:38:35 -0400
> Alexandre Bounine wrote:
>
> > Adds support for DMA Engine API.
> >
> > Includes following changes:
> > - Modifies BDMA register offset definitions to support per-channel
> handling
> > - Separates BDMA channel reserved for RIO Maintenance requests
> > - Adds DMA Engine callback routines
> >
> > ...
> >
> > 5 files changed, 1029 insertions(+), 90 deletions(-)
>
> hm, what a lot of code.
This is mostly new stuff for that driver.
>
> > +config TSI721_DMA
> > + bool "IDT Tsi721 RapidIO DMA support"
> > + depends on RAPIDIO_TSI721
> > + default "n"
> > + select RAPIDIO_DMA_ENGINE
> > + help
> > + Enable DMA support for IDT Tsi721 PCIe-to-SRIO controller.
>
> Do we really need to offer this decision to the user? If possible it
> would be better to always enable the feature where that makes sense.
> Better code coverage, less maintenance effort, more effective testing
> effort, possibly cleaner code.
Agree. Influence of dmaengine here ;)
But we still need RAPIDIO_DMA_ENGINE option to control DMA
configuration for devices that are RIO targets only.
>
> >
> > ...
> >
> > +static int tsi721_bdma_ch_init(struct tsi721_bdma_chan *chan)
> > +{
> > + struct tsi721_dma_desc *bd_ptr;
> > + struct device *dev = chan->dchan.device->dev;
> > + u64 *sts_ptr;
> > + dma_addr_t bd_phys;
> > + dma_addr_t sts_phys;
> > + int sts_size;
> > + int bd_num = chan->bd_num;
> > +
> > + dev_dbg(dev, "Init Block DMA Engine, CH%d\n", chan->id);
> > +
> > + /* Allocate space for DMA descriptors */
> > + bd_ptr = dma_alloc_coherent(dev,
> > + bd_num * sizeof(struct tsi721_dma_desc),
> > + &bd_phys, GFP_KERNEL);
> > + if (!bd_ptr)
> > + return -ENOMEM;
> > +
> > + chan->bd_phys = bd_phys;
> > + chan->bd_base = bd_ptr;
> > +
> > + memset(bd_ptr, 0, bd_num * sizeof(struct tsi721_dma_desc));
> > +
> > + dev_dbg(dev, "DMA descriptors @ %p (phys = %llx)\n",
> > + bd_ptr, (unsigned long long)bd_phys);
> > +
> > + /* Allocate space for descriptor status FIFO */
> > + sts_size = (bd_num >= TSI721_DMA_MINSTSSZ) ?
> > + bd_num : TSI721_DMA_MINSTSSZ;
> > + sts_size = roundup_pow_of_two(sts_size);
> > + sts_ptr = dma_alloc_coherent(dev,
> > +sts_size * sizeof(struct
tsi721_dma_sts),
> > +&sts_phys, GFP_KERNEL);
> > + if (!sts_ptr) {
> > + /* Free space allocated for DMA descriptors */
> > + dma_free_coherent(dev,
> > + bd_num * sizeof(struct
tsi721_dma_desc),
> > + bd_ptr, bd_phys);
> > + chan->bd_base = NULL;
> > + return -ENOMEM;
> > + }
> > +
> > + chan->sts_phys = sts_phys;
> > + chan->sts_base = sts_ptr;
> > + chan->sts_size = sts_size;
> > +
> > + memset(sts_ptr, 0, sts_size);
>
> You meant
I really need it here. That status block tracks progress by keeping
non-zero addresses of processed descriptors.
>
> --- a/drivers/rapidio/devices/tsi721.c~rapidio-tsi721-add-dma-engine-
> support-fix
> +++ a/drivers/rapidio/devices/tsi721.c
> @@ -1006,7 +1006,7 @@ static int tsi721_bdma_maint_init(struct
> priv->mdma.sts_base = sts_ptr;
> priv->mdma.sts_size = sts_size;
>
> - memset(sts_ptr, 0, sts_size);
> + memset(sts_ptr, 0, sts_size * sizeof(struct tsi721_dma_sts));
>
> dev_dbg(&priv->pdev->dev,
> "desc status FIFO @ %p (phys = %llx) size=0x%x\n",
>
> However that's at least two instances where you wanted a
> dma_zalloc_coherent(). How's about we give ourselves one?
Does this mean that I am on hook for it as a "most frequent user"?
>
>
> > + dev_dbg(dev,
> > + "desc status FIFO @ %p (phys = %llx) size=0x%x\n",
> > + sts_ptr, (unsigned long long)sts_phys, sts_size);
> > +
> > + /* Initialize DMA descriptors ring */
> > + bd_ptr[bd_num - 1].type_id = cpu_to_le32(DTYPE3 << 29);
> > + bd_ptr[bd_num - 1].next_lo = cpu_to_le32((u64)bd_phys &
> > +
TSI721_DMAC_DPTRL_MASK);
> > + bd_ptr[bd_num - 1].next_hi = cpu_to_le32((u64)bd_phys >> 32);
> > +
> > + /* Setup DMA descriptor pointers */
> > + iowrite32(((u64)bd_phys >> 32),
> > + chan->regs + TSI721_DMAC_DPTRH);
> > + iowrite32(((u64)bd_phys & TSI721_DMAC_DPTRL_MASK),
> > + chan->regs + TSI721_DMAC_DPTRL);
> > +
> > + /* Setup descriptor status FIFO */
> > + iowrite32(((u64)sts_phys >> 32),
> > + chan->regs + TSI721_DMAC_DSBH);
> > + iowrite32(((u64)sts_phys & TSI721_DMAC_DSBL_MASK),
> > + chan->regs + TSI721_DMAC_DSBL);
> > + iowrite32(TSI721_DMAC_DSSZ_SIZE(sts_size),
> > + chan->regs + TSI721_DMAC_DSSZ);
> > +
> > + /* Clear interrupt bits */
> > + iowrite32(TSI721_DMAC_INT_ALL,
> > + chan->regs + TSI721_DMAC_I
[PATCH] libata: Convert LED disk trigger from IDE to libata
This patch converts the trigger for the LED at the front of Apple's
iBooks to libata. It's merely a replacement of the string ide by disk.
The patch is taken from http://dev.gentoo.org/~josejx/ata.patch. I've
asked Joseph Jezak if he intends to send this patch upstream, but as he
did not reply I'll do so.
---
arch/powerpc/configs/pmac32_defconfig |2 +-
arch/powerpc/configs/ppc6xx_defconfig |2 +-
drivers/ata/libata-core.c |4 ++
drivers/ide/ide-disk.c|2 +-
drivers/leds/Kconfig | 10 +++---
drivers/leds/Makefile |2 +-
drivers/leds/ledtrig-disk.c | 64 +
drivers/leds/ledtrig-ide-disk.c | 64 -
drivers/macintosh/Kconfig | 11 +++---
drivers/macintosh/via-pmu-led.c |4 +-
include/linux/leds.h |6 ++--
11 files changed, 87 insertions(+), 84 deletions(-)
create mode 100644 drivers/leds/ledtrig-disk.c
delete mode 100644 drivers/leds/ledtrig-ide-disk.c
diff --git a/arch/powerpc/configs/pmac32_defconfig
b/arch/powerpc/configs/pmac32_defconfig
index f8b394a..cff5d4e 100644
--- a/arch/powerpc/configs/pmac32_defconfig
+++ b/arch/powerpc/configs/pmac32_defconfig
@@ -180,7 +180,7 @@ CONFIG_ADB=y
CONFIG_ADB_CUDA=y
CONFIG_ADB_PMU=y
CONFIG_ADB_PMU_LED=y
-CONFIG_ADB_PMU_LED_IDE=y
+CONFIG_ADB_PMU_LED_DISK=y
CONFIG_PMAC_APM_EMU=m
CONFIG_PMAC_MEDIABAY=y
CONFIG_PMAC_BACKLIGHT=y
diff --git a/arch/powerpc/configs/ppc6xx_defconfig
b/arch/powerpc/configs/ppc6xx_defconfig
index 04360f9..c56464d 100644
--- a/arch/powerpc/configs/ppc6xx_defconfig
+++ b/arch/powerpc/configs/ppc6xx_defconfig
@@ -471,7 +471,7 @@ CONFIG_ADB=y
CONFIG_ADB_CUDA=y
CONFIG_ADB_PMU=y
CONFIG_ADB_PMU_LED=y
-CONFIG_ADB_PMU_LED_IDE=y
+CONFIG_ADB_PMU_LED_DISK=y
CONFIG_PMAC_APM_EMU=y
CONFIG_PMAC_MEDIABAY=y
CONFIG_PMAC_BACKLIGHT=y
diff --git a/drivers/ata/libata-core.c b/drivers/ata/libata-core.c
index 4a3a5ae..d37e3a2 100644
--- a/drivers/ata/libata-core.c
+++ b/drivers/ata/libata-core.c
@@ -66,6 +66,7 @@
#include
#include
#include
+#include
#include "libata.h"
#include "libata-transport.h"
@@ -4823,6 +4824,9 @@ void ata_qc_complete(struct ata_queued_cmd *qc)
{
struct ata_port *ap = qc->ap;
+ /* Trigger the LED (if available) */
+ ledtrig_disk_activity();
+
/* XXX: New EH and old EH use different mechanisms to
* synchronize EH with regular execution path.
*
diff --git a/drivers/ide/ide-disk.c b/drivers/ide/ide-disk.c
index 2747980..cb25bd6 100644
--- a/drivers/ide/ide-disk.c
+++ b/drivers/ide/ide-disk.c
@@ -186,7 +186,7 @@ static ide_startstop_t ide_do_rw_disk(ide_drive_t *drive,
struct request *rq,
BUG_ON(drive->dev_flags & IDE_DFLAG_BLOCKED);
BUG_ON(rq->cmd_type != REQ_TYPE_FS);
- ledtrig_ide_activity();
+ ledtrig_disk_activity();
pr_debug("%s: %sing: block=%llu, sectors=%u, buffer=0x%08lx\n",
drive->name, rq_data_dir(rq) == READ ? "read" : "writ",
diff --git a/drivers/leds/Kconfig b/drivers/leds/Kconfig
index b591e72..1934d8a 100644
--- a/drivers/leds/Kconfig
+++ b/drivers/leds/Kconfig
@@ -404,12 +404,12 @@ config LEDS_TRIGGER_TIMER
If unsure, say Y.
-config LEDS_TRIGGER_IDE_DISK
- bool "LED IDE Disk Trigger"
- depends on IDE_GD_ATA
- depends on LEDS_TRIGGERS
+config LEDS_TRIGGER_DISK
+ bool "LED Disk Trigger"
+ depends on IDE_GD_ATA || ATA
+depends on LEDS_TRIGGERS
help
- This allows LEDs to be controlled by IDE disk activity.
+ This allows LEDs to be controlled by disk activity.
If unsure, say Y.
config LEDS_TRIGGER_HEARTBEAT
diff --git a/drivers/leds/Makefile b/drivers/leds/Makefile
index bbfd2e3..350cc89 100644
--- a/drivers/leds/Makefile
+++ b/drivers/leds/Makefile
@@ -49,7 +49,7 @@ obj-$(CONFIG_LEDS_DAC124S085) += leds-dac124s085.o
# LED Triggers
obj-$(CONFIG_LEDS_TRIGGER_TIMER) += ledtrig-timer.o
-obj-$(CONFIG_LEDS_TRIGGER_IDE_DISK)+= ledtrig-ide-disk.o
+obj-$(CONFIG_LEDS_TRIGGER_DISK)+= ledtrig-disk.o
obj-$(CONFIG_LEDS_TRIGGER_HEARTBEAT) += ledtrig-heartbeat.o
obj-$(CONFIG_LEDS_TRIGGER_BACKLIGHT) += ledtrig-backlight.o
obj-$(CONFIG_LEDS_TRIGGER_GPIO)+= ledtrig-gpio.o
diff --git a/drivers/leds/ledtrig-disk.c b/drivers/leds/ledtrig-disk.c
new file mode 100644
index 000..0ebb2eb
--- /dev/null
+++ b/drivers/leds/ledtrig-disk.c
@@ -0,0 +1,64 @@
+/*
+ * LED Disk Activity Trigger
+ *
+ * Copyright 2006 Openedhand Ltd.
+ *
+ * Author: Richard Purdie
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+static void ledtrig_disk_timerfunc(unsigned long d
Re: Request_irq fails for IRQ2
On 10/03/2011 09:27 AM, smitha.va...@wipro.com wrote: > I just don't know what I should pass for host , also when I pass NULL > for host . I see the default host is NULL.. > Could you please help me. My project delivery is near , I need help soon. Ideally you should just use the device tree to describe this device, then you wouldn't have to deal with finding the pointer to the controller. Otherwise, modify the cpm2_pic driver to either call irq_set_default_host() (in which case NULL should work) or to make cpm2_pic_host non-static (in which case you should pass that). -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [RFC PATCH 1/2] RapidIO: Add DMA Engine support for RIO data transfers
Vinod Koul wrote:
>
> On Fri, 2011-09-30 at 17:38 -0400, Alexandre Bounine wrote:
> Please CC *maintainers* on your patches, get_maintainers.pl will tell
> you who. Adding Dan here
Based on https://lkml.org/lkml/2011/2/14/67 and use of DMA_SLAVE in this
patch I decided that you are the best match among two and there is no reason
to disturb Dan ;)
> > Adds DMA Engine framework support into RapidIO subsystem.
> > Uses DMA Engine DMA_SLAVE interface to generate data transfers to/from
> > remote
> > RapidIO target devices. Uses scatterlist to describe local data buffer and
> > dma_chan.private member to pass target specific information. Supports flat
> > data buffer only for a remote side.
> The way dmaengine works today is that it doesn't know anything about
> client subsystem. But this brings in a subsystem details to dmaengine
> which I don't agree with yet.
> Why can't we abstract this out??
The only thing that brings subsystem knowledge into dmaengine is DMA_RAPIDIO
flag.
I am actually on the fence about this. From RapidIO side point of view I do not
need that flag at all.
RapidIO uses a filter routine that is sufficient to identify dmaengine channels
associated with specific RapidIO mport. Use of DMA_SLAVE flag is safe here.
Use of private member of dma_chan is "private" business of RapidIO and does
not break anything.
My concern here is that other subsystems may use/request DMA_SLAVE channel(s)
as well
and wrongfully acquire one that belongs to RapidIO. In this case separation
with another
flag may have a sense - it is possible to have a system that uses RapidIO
and other "traditional" DMA slave channel.
This is why I put that proposed interface for discussion instead of keeping
everything
inside of RapidIO.
If you think that situation above will not happen I will be happy to remove
that subsystem knowledge from dmaengine files.
My most recent test implementation runs without DMA_RAPIDIO flag though.
>
> After going thru the patch, I do not believe that this this is case of
> SLAVE transfers, Dan can you please take a look at this patch
I agree, this is not a case of "pure" slave transfers but existing DMA_SLAVE
interface fits well into the RapidIO operations.
First, we have only one memory mapped location on the host side. We transfer
data to/from location that is not mapped into memory on the same side.
Second, having ability to pass private target information allows me to pass
information about remote target device on per-transfer basis.
>
>
> > Signed-off-by: Alexandre Bounine
> > Cc: Vinod Koul
> > Cc: Kumar Gala
> > Cc: Matt Porter
> > Cc: Li Yang
> > ---
> > drivers/dma/dmaengine.c |4 ++
... skip ...
> > +#ifdef CONFIG_RAPIDIO_DMA_ENGINE
> > +
> > +#include
> > +
... skip ...
> > + */
> > +struct dma_async_tx_descriptor *rio_dma_prep_slave_sg(struct rio_dev *rdev,
> > + struct dma_chan *dchan, struct rio_dma_data *data,
> > + enum dma_data_direction direction, unsigned long flags)
> > +{
> > + struct dma_async_tx_descriptor *txd = NULL;
> > + struct rio_dma_ext rio_ext;
> > +
> > + rio_ext.destid = rdev->destid;
> > + rio_ext.rio_addr_u = data->rio_addr_u;
> > + rio_ext.rio_addr = data->rio_addr;
> > + rio_ext.wr_type = data->wr_type;
> > + dchan->private = &rio_ext;
> > +
> > + txd = dchan->device->device_prep_slave_sg(dchan, data->sg, data-
> >sg_len,
> > + direction, flags);
> > +
> > + return txd;
> > +}
> > +EXPORT_SYMBOL_GPL(rio_dma_prep_slave_sg);
> You should move the rdev and data to dma_slave_config, that way you
> should be able to use the existing _prep_slave_sg function.
RapidIO network usually has more than one device attached to it and
single DMA channel may service data transfers to/from several devices.
In this case device information should be passed on per-transfer basis.
> > +
> > +#endif /* CONFIG_RAPIDIO_DMA_ENGINE */
> > +
... skip ...
> > + *
> > + * Note: RapidIO specification defines write (NWRITE) and
> > + * write-with-response (NWRITE_R) data transfer operations.
> > + * Existing DMA controllers that service RapidIO may use one of these
> > operations
> > + * for entire data transfer or their combination with only the last data
> > packet
> > + * requires response.
> > + */
> > +enum rio_write_type {
> > + RDW_DEFAULT,/* default method used by DMA driver */
> > + RDW_ALL_NWRITE, /* all packets use NWRITE */
> > + RDW_ALL_NWRITE_R, /* all packets use NWRITE_R */
> > + RDW_LAST_NWRITE_R, /* last packet uses NWRITE_R, all other -
> > NWRITE */
> > +};
> Why not use the current mechanism of specifying callback or ACK flags
> if you want a response or not.
That response is handled by RapidIO hardware and ensures reliable
packet delivery when response is used. User may not need callback or ACK
for his operation (in terms of dmaengine) but error handling will be initiated
if there is no response from the target device.
>
> >
Request_irq fails for IRQ2
Hi Scott,
I try to request an IRQ (IRQ2 and IRQ3 which are ineterrupt no 20 and 21 in
mpc8247)in my driver . The
Call fails in setup_irq in Manage.c at /kernel/irq.
Setup _irq returns -ENOSYS
if (desc->irq_data.chip == &no_irq_chip)
return -ENOSYS;
I just want to know why it fails. Below is the call to request irq in my driver.
#define CPLD1_INTERRUPT 20
if (request_irq(CPLD1_INTERRUPT,cpld_irq_handler, 0, GPIO_CHAR_PATH, NULL))
{
printk(KERN_ERR "gpio_init: Could not grab IRQ line for CPLD\n");
goto err1;
}
Regards,
Smitha
Please do not print this email unless it is absolutely necessary.
The information contained in this electronic message and any attachments to
this message are intended for the exclusive use of the addressee(s) and may
contain proprietary, confidential or privileged information. If you are not the
intended recipient, you should not disseminate, distribute or copy this e-mail.
Please notify the sender immediately and destroy all copies of this message and
any attachments.
WARNING: Computer viruses can be transmitted via email. The recipient should
check this email and any attachments for the presence of viruses. The company
accepts no liability for any damage caused by any virus transmitted by this
email.
www.wipro.com
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
