On Mon, 25 Feb 2008 09:51:16 -0800
David Brownell <[EMAIL PROTECTED]> wrote:
> > > > > +static cycle_t tc_get_cycles(void)
> > > > > +{
> > > > > + unsigned long flags;
> > > > > + u32 lower, upper;
> > > > > +
> > > > > + raw_local_irq_save(flags);
> > > >
> > > > Why
On Mon, 25 Feb 2008 10:06:44 -0800
David Brownell <[EMAIL PROTECTED]> wrote:
> > > > Which reminds me...you were talking about a patch that adds oneshot
> > > > support for the count/compare clocksource and more cleanups, but I
> > > > don't think I've seen it...?
> > >
> > > I avoid sending
On Mon, 25 Feb 2008 10:06:44 -0800
David Brownell [EMAIL PROTECTED] wrote:
Which reminds me...you were talking about a patch that adds oneshot
support for the count/compare clocksource and more cleanups, but I
don't think I've seen it...?
I avoid sending non-working patches,
On Mon, 25 Feb 2008 09:51:16 -0800
David Brownell [EMAIL PROTECTED] wrote:
+static cycle_t tc_get_cycles(void)
+{
+ unsigned long flags;
+ u32 lower, upper;
+
+ raw_local_irq_save(flags);
Why do you need to use the raw version?
On Sun, 24 Feb 2008 17:03:10 -0800
David Brownell <[EMAIL PROTECTED]> wrote:
> > Which reminds me...you were talking about a patch that adds oneshot
> > support for the count/compare clocksource and more cleanups, but I
> > don't think I've seen it...?
>
> I avoid sending non-working patches,
On Sun, 24 Feb 2008 15:42:51 -0800
David Brownell <[EMAIL PROTECTED]> wrote:
> > On Fri, 22 Feb 2008 17:28:37 -0800
> > David Brownell <[EMAIL PROTECTED]> wrote:
> >
> > > +static cycle_t tc_get_cycles(void)
> > > +{
> > > + unsigned long flags;
> > > + u32 lower, upper;
> > > +
> >
On Sun, 24 Feb 2008 15:42:51 -0800
David Brownell [EMAIL PROTECTED] wrote:
On Fri, 22 Feb 2008 17:28:37 -0800
David Brownell [EMAIL PROTECTED] wrote:
+static cycle_t tc_get_cycles(void)
+{
+ unsigned long flags;
+ u32 lower, upper;
+
+
On Sun, 24 Feb 2008 17:03:10 -0800
David Brownell [EMAIL PROTECTED] wrote:
Which reminds me...you were talking about a patch that adds oneshot
support for the count/compare clocksource and more cleanups, but I
don't think I've seen it...?
I avoid sending non-working patches, and hadn't
On Sun, 24 Feb 2008 14:55:27 -0800
David Brownell <[EMAIL PROTECTED]> wrote:
> On Sun, 24 Feb 2008 18:45:54 +0100
> Haavard Skinnemoen <[EMAIL PROTECTED]> wrote:
> >
> > On Fri, 22 Feb 2008 17:23:23 -0800
> > David Brownell <[EMAIL PROTECTED]> wrote:
>
Again, sorry for the delay...it really sucks that I haven't been able
to look at this stuff closely until now. Hopefully a late review is
better than no review.
On Fri, 22 Feb 2008 17:28:37 -0800
David Brownell <[EMAIL PROTECTED]> wrote:
> +static cycle_t tc_get_cycles(void)
> +{
> +
On Fri, 22 Feb 2008 17:23:23 -0800
David Brownell <[EMAIL PROTECTED]> wrote:
> Create based on and the
> at91sam9263 and at32ap7000 datasheets. Most AT91 and AT32 SOCs have one
> or two of these TC blocks, which include three 16-bit timers that can be
> interconnected in various ways.
>
>
On Fri, 22 Feb 2008 17:23:23 -0800
David Brownell [EMAIL PROTECTED] wrote:
Create linux/atmel_tc.h based on asm-arm/arch-at91/at91-tc.h and the
at91sam9263 and at32ap7000 datasheets. Most AT91 and AT32 SOCs have one
or two of these TC blocks, which include three 16-bit timers that can be
Again, sorry for the delay...it really sucks that I haven't been able
to look at this stuff closely until now. Hopefully a late review is
better than no review.
On Fri, 22 Feb 2008 17:28:37 -0800
David Brownell [EMAIL PROTECTED] wrote:
+static cycle_t tc_get_cycles(void)
+{
+ unsigned
On Sun, 24 Feb 2008 14:55:27 -0800
David Brownell [EMAIL PROTECTED] wrote:
On Sun, 24 Feb 2008 18:45:54 +0100
Haavard Skinnemoen [EMAIL PROTECTED] wrote:
On Fri, 22 Feb 2008 17:23:23 -0800
David Brownell [EMAIL PROTECTED] wrote:
Note that this won't be usable until the AT91 and AT32
On Sat, 23 Feb 2008 00:05:07 -0800
Andrew Morton <[EMAIL PROTECTED]> wrote:
> I had it queued for 2.6.26 which I guess was wrong. I'll bump it into
> 2.6.25.
Thanks!
> Is it needed in 2.6.24.x?
I think so. The last time that code was changed was before 2.6.23
AFAICT, so perhaps 2.6.23.x as
On Sat, 23 Feb 2008 00:03:23 -0800
Andrew Morton <[EMAIL PROTECTED]> wrote:
> On Thu, 21 Feb 2008 17:41:05 +0100 Haavard Skinnemoen <[EMAIL PROTECTED]>
> wrote:
>
> > From: Atsushi Nemoto <[EMAIL PROTECTED]>
> >
> > Fix NCFGR.SPD setting on 10Mbp
On Sat, 23 Feb 2008 00:03:23 -0800
Andrew Morton [EMAIL PROTECTED] wrote:
On Thu, 21 Feb 2008 17:41:05 +0100 Haavard Skinnemoen [EMAIL PROTECTED]
wrote:
From: Atsushi Nemoto [EMAIL PROTECTED]
Fix NCFGR.SPD setting on 10Mbps. This bug was introduced by
conversion to generic PHY
On Sat, 23 Feb 2008 00:05:07 -0800
Andrew Morton [EMAIL PROTECTED] wrote:
I had it queued for 2.6.26 which I guess was wrong. I'll bump it into
2.6.25.
Thanks!
Is it needed in 2.6.24.x?
I think so. The last time that code was changed was before 2.6.23
AFAICT, so perhaps 2.6.23.x as well.
On Thu, 21 Feb 2008 17:41:05 +0100
Haavard Skinnemoen <[EMAIL PROTECTED]> wrote:
> From: Atsushi Nemoto <[EMAIL PROTECTED]>
>
> Fix NCFGR.SPD setting on 10Mbps. This bug was introduced by
> conversion to generic PHY layer in kernel 2.6.23.
>
> Signed-off-by: At
On Thu, 21 Feb 2008 17:41:05 +0100
Haavard Skinnemoen [EMAIL PROTECTED] wrote:
From: Atsushi Nemoto [EMAIL PROTECTED]
Fix NCFGR.SPD setting on 10Mbps. This bug was introduced by
conversion to generic PHY layer in kernel 2.6.23.
Signed-off-by: Atsushi Nemoto [EMAIL PROTECTED]
Signed-off
On Thu, 21 Feb 2008 19:46:20 +0100
Haavard Skinnemoen <[EMAIL PROTECTED]> wrote:
> In order to fix this problem, I think I need a way to tell the MMC core
> that the card really is gone and that there's no point trying to
> communicate with it. Is there any way I can do that?
Hi Pierre,
I've been trying to debug some card detection problems in the atmel-mci
driver. Sometimes, when I remove a card, the event doesn't seem to get
detected properly, and the MMC core thinks the card is still there.
When I re-insert the card, the MMC core thinks the card is gone.
I've
We should only return IRQ_HANDLED when we actually found something to
handle. This is important since the USART interrupt handler may be
shared with the timer interrupt on some chips.
Pointed-out-by: michael <[EMAIL PROTECTED]>
Signed-off-by: Haavard Skinnemoen <[EMAIL PROTECTED]>
From: Atsushi Nemoto <[EMAIL PROTECTED]>
Fix NCFGR.SPD setting on 10Mbps. This bug was introduced by
conversion to generic PHY layer in kernel 2.6.23.
Signed-off-by: Atsushi Nemoto <[EMAIL PROTECTED]>
Signed-off-by: Haavard Skinnemoen <[EMAIL PROTECTED]>
---
drivers/net/m
On Fri, 22 Feb 2008 00:07:31 +0900 (JST)
Atsushi Nemoto <[EMAIL PROTECTED]> wrote:
> > I'm willing to take your word for it, but some documentation would be
> > really nice...
>
> Well, simple grepping drivers/net/phy enlighten us ;)
Yeah, the patch certainly looks correct as far as I can
On Thu, 21 Feb 2008 22:50:54 +0900 (JST)
Atsushi Nemoto <[EMAIL PROTECTED]> wrote:
> Fix NCFGR.SPD setting on 10Mbps. This bug was introduced by
> conversion to generic PHY layer in kernel 2.6.23.
>
> Signed-off-by: Atsushi Nemoto <[EMAIL PROTECTED]>
> ---
> diff --git a/drivers/net/macb.c
On Thu, 21 Feb 2008 22:50:54 +0900 (JST)
Atsushi Nemoto [EMAIL PROTECTED] wrote:
Fix NCFGR.SPD setting on 10Mbps. This bug was introduced by
conversion to generic PHY layer in kernel 2.6.23.
Signed-off-by: Atsushi Nemoto [EMAIL PROTECTED]
---
diff --git a/drivers/net/macb.c
We should only return IRQ_HANDLED when we actually found something to
handle. This is important since the USART interrupt handler may be
shared with the timer interrupt on some chips.
Pointed-out-by: michael [EMAIL PROTECTED]
Signed-off-by: Haavard Skinnemoen [EMAIL PROTECTED]
---
drivers/serial
On Fri, 22 Feb 2008 00:07:31 +0900 (JST)
Atsushi Nemoto [EMAIL PROTECTED] wrote:
I'm willing to take your word for it, but some documentation would be
really nice...
Well, simple grepping drivers/net/phy enlighten us ;)
Yeah, the patch certainly looks correct as far as I can tell.
From: Atsushi Nemoto [EMAIL PROTECTED]
Fix NCFGR.SPD setting on 10Mbps. This bug was introduced by
conversion to generic PHY layer in kernel 2.6.23.
Signed-off-by: Atsushi Nemoto [EMAIL PROTECTED]
Signed-off-by: Haavard Skinnemoen [EMAIL PROTECTED]
---
drivers/net/macb.c |2 +-
1 files
Hi Pierre,
I've been trying to debug some card detection problems in the atmel-mci
driver. Sometimes, when I remove a card, the event doesn't seem to get
detected properly, and the MMC core thinks the card is still there.
When I re-insert the card, the MMC core thinks the card is gone.
I've
On Thu, 21 Feb 2008 19:46:20 +0100
Haavard Skinnemoen [EMAIL PROTECTED] wrote:
In order to fix this problem, I think I need a way to tell the MMC core
that the card really is gone and that there's no point trying to
communicate with it. Is there any way I can do that?
Never mind, I figured
On Wed, 20 Feb 2008 14:21:09 +0900 (JST)
Atsushi Nemoto <[EMAIL PROTECTED]> wrote:
> On Mon, 18 Feb 2008 15:31:58 +0100, Haavard Skinnemoen <[EMAIL PROTECTED]>
> wrote:
> > > Anyway, I will try your patch in a few days.
> >
> > Ok, thanks. If it wor
On Wed, 20 Feb 2008 14:21:09 +0900 (JST)
Atsushi Nemoto [EMAIL PROTECTED] wrote:
On Mon, 18 Feb 2008 15:31:58 +0100, Haavard Skinnemoen [EMAIL PROTECTED]
wrote:
Anyway, I will try your patch in a few days.
Ok, thanks. If it works, that would be great, but given your
description above
On Mon, 18 Feb 2008 11:57:56 -0800
David Brownell <[EMAIL PROTECTED]> wrote:
> On Monday 18 February 2008, Atsushi Nemoto wrote:
> > IIRC the clock state follows
> > CSRn.CPOL just before the real transfer.
>
> No ... clock state should be valid *before* chipselect goes
> active. So I'm
On Mon, 18 Feb 2008 23:12:43 +0900 (JST)
Atsushi Nemoto <[EMAIL PROTECTED]> wrote:
> T0-T1 was relatively longer then T1-T2. I suppose T1 is not the
> point of updating MR register, but the point of starting DMA transfer.
Aw. I see.
> Anyway, I will try your patch in a few days.
Ok, thanks.
On Fri, 15 Feb 2008 09:12:35 -0800
"Nelson, Shannon" <[EMAIL PROTECTED]> wrote:
> I'll jump in here briefly - I'm okay with the direction this is going,
> but I want to be protective of ioatdma performance. As used in struct
> ioat_desc_sw, the cookie and ack elements end up very close to the
On Sat, 16 Feb 2008 13:06:54 -0700
"Dan Williams" <[EMAIL PROTECTED]> wrote:
> I like the direction of the patch, i.e. splitting out separate
> functionality into separate structs. However, I do not want to break
> the model of clients sourcing the operations and drivers sinking them
> which
On Sat, 16 Feb 2008 22:32:52 +0900 (JST)
Atsushi Nemoto <[EMAIL PROTECTED]> wrote:
> Here is my quick workaround for this problem. It makes all CSRn.CPOL
> match for the transfer before activating chipselect. I'm not quite
> sure my analysis is correct, and there might be better solution.
>
On Sat, 16 Feb 2008 22:32:52 +0900 (JST)
Atsushi Nemoto [EMAIL PROTECTED] wrote:
Here is my quick workaround for this problem. It makes all CSRn.CPOL
match for the transfer before activating chipselect. I'm not quite
sure my analysis is correct, and there might be better solution.
Could you
On Sat, 16 Feb 2008 13:06:54 -0700
Dan Williams [EMAIL PROTECTED] wrote:
I like the direction of the patch, i.e. splitting out separate
functionality into separate structs. However, I do not want to break
the model of clients sourcing the operations and drivers sinking them
which
On Fri, 15 Feb 2008 09:12:35 -0800
Nelson, Shannon [EMAIL PROTECTED] wrote:
I'll jump in here briefly - I'm okay with the direction this is going,
but I want to be protective of ioatdma performance. As used in struct
ioat_desc_sw, the cookie and ack elements end up very close to the end
of a
On Mon, 18 Feb 2008 23:12:43 +0900 (JST)
Atsushi Nemoto [EMAIL PROTECTED] wrote:
T0-T1 was relatively longer then T1-T2. I suppose T1 is not the
point of updating MR register, but the point of starting DMA transfer.
Aw. I see.
Anyway, I will try your patch in a few days.
Ok, thanks. If it
On Mon, 18 Feb 2008 11:57:56 -0800
David Brownell [EMAIL PROTECTED] wrote:
On Monday 18 February 2008, Atsushi Nemoto wrote:
IIRC the clock state follows
CSRn.CPOL just before the real transfer.
No ... clock state should be valid *before* chipselect goes
active. So I'm thinking the
On Wed, 13 Feb 2008 20:24:02 +0100
Haavard Skinnemoen <[EMAIL PROTECTED]> wrote:
> But looking at your latest patch series, I guess we can use the new
> "next" field instead. It's not like we really need the full
> capabilities of list_head.
On second thought, if we d
On Wed, 13 Feb 2008 00:02:52 -0700
Dan Williams <[EMAIL PROTECTED]> wrote:
> Dan Williams (4):
> iop-adma: remove the workaround for missed interrupts on iop3xx
> async_tx: kill ->device_dependency_added
> async_tx: fix multiple dependency submission
> async_tx: checkpatch
On Wed, 13 Feb 2008 00:02:52 -0700
Dan Williams [EMAIL PROTECTED] wrote:
Dan Williams (4):
iop-adma: remove the workaround for missed interrupts on iop3xx
async_tx: kill -device_dependency_added
async_tx: fix multiple dependency submission
async_tx: checkpatch says
On Wed, 13 Feb 2008 20:24:02 +0100
Haavard Skinnemoen [EMAIL PROTECTED] wrote:
But looking at your latest patch series, I guess we can use the new
next field instead. It's not like we really need the full
capabilities of list_head.
On second thought, if we do this, we would be using the next
On Thu, 14 Feb 2008 11:34:03 -0700
"Dan Williams" <[EMAIL PROTECTED]> wrote:
> On Thu, Feb 14, 2008 at 1:36 AM, Haavard Skinnemoen
> <[EMAIL PROTECTED]> wrote:
> > It's ok to use PIO for small and/or odd transfers like "read 2 bytes
> > from this
[removing lots of people from Cc]
On Wed, 13 Feb 2008 19:30:51 +0100
Pierre Ossman <[EMAIL PROTECTED]> wrote:
> > +static int req_dbg_open(struct inode *inode, struct file *file)
> > +{
>
> And this should go into the core.
I've started working on this, but I've run into a problem: The mmc
On Wed, 13 Feb 2008 16:55:54 -0700
"Dan Williams" <[EMAIL PROTECTED]> wrote:
> Well, the other two possibilities are:
>
> 1/ Spin/sleep until a descriptor shows up
Won't work since the transfer hasn't been started yet, so it will spin
indefinitely.
I guess we could return, send the command and
On Wed, 13 Feb 2008 16:55:54 -0700
Dan Williams [EMAIL PROTECTED] wrote:
Well, the other two possibilities are:
1/ Spin/sleep until a descriptor shows up
Won't work since the transfer hasn't been started yet, so it will spin
indefinitely.
I guess we could return, send the command and use a
[removing lots of people from Cc]
On Wed, 13 Feb 2008 19:30:51 +0100
Pierre Ossman [EMAIL PROTECTED] wrote:
+static int req_dbg_open(struct inode *inode, struct file *file)
+{
And this should go into the core.
I've started working on this, but I've run into a problem: The mmc core
On Thu, 14 Feb 2008 11:34:03 -0700
Dan Williams [EMAIL PROTECTED] wrote:
On Thu, Feb 14, 2008 at 1:36 AM, Haavard Skinnemoen
[EMAIL PROTECTED] wrote:
It's ok to use PIO for small and/or odd transfers like read 2 bytes
from this SDIO register, something that the mmc-block driver would
On Wed, 13 Feb 2008 12:11:58 -0700
"Dan Williams" <[EMAIL PROTECTED]> wrote:
> > + desc = chan->device->device_prep_slave(chan,
> > + sg_dma_address(sg), direction,
> > + DMA_SLAVE_WIDTH_32BIT,
> > +
On Wed, 13 Feb 2008 12:07:26 -0700
"Dan Williams" <[EMAIL PROTECTED]> wrote:
> > +struct dma_slave_descriptor {
> > + struct dma_async_tx_descriptor txd;
> > + struct list_head client_node;
> > +};
>
> Can you explain a bit why client_node is needed? I do not think we
> need
On Wed, 13 Feb 2008 19:30:51 +0100
Pierre Ossman <[EMAIL PROTECTED]> wrote:
> I think this was meant to go away.
> And this should go into the core.
> I also pointed this out. mmc_remove_host() will synchronize this for
> you.
Right. Sorry. I focused so much on getting the driver to work
On Wed, 13 Feb 2008 08:42:15 -0800
"Andrew G. Morgan" <[EMAIL PROTECTED]> wrote:
> However, it is a warning and, for any existing app that doesn't care
> about newly added capabilities, the warning is benign.
Ok, I see. Thanks for explaining.
Haavard
--
To unsubscribe from this list: send the
e in lib/bug.c qualifies as "own
definition" these days? I think the patch below should take care of all
four...unless I've misunderstood something.
Signed-off-by: Haavard Skinnemoen <[EMAIL PROTECTED]>
diff --git a/lib/bug.c b/lib/bug.c
index 530f38f..0d67419 100644
--- a/
On Wed, 13 Feb 2008 05:54:12 -0500 (EST)
"Robert P. J. Day" <[EMAIL PROTECTED]> wrote:
> i've also updated the list of what i call "badref" CONFIG variables
> -- that is, tests of CONFIG_ variables that appear to be undefined
> anywhere in a Kconfig file (which typically represents a
On Wed, 13 Feb 2008 10:10:24 +0100
Haavard Skinnemoen <[EMAIL PROTECTED]> wrote:
> > > ip_tables: (C) 2000-2006 Netfilter Core Team
> > > nf_conntrack version 0.5.0 (1024 buckets, 4096 max)
> > > Unable to handle kernel paging request at virtual address d
On Wed, 13 Feb 2008 00:48:29 -0800
Andrew Morton <[EMAIL PROTECTED]> wrote:
> On Tue, 12 Feb 2008 22:46:01 +1100 Ben Nizette <[EMAIL PROTECTED]> wrote:
>
> >
> > On an AVR32, root over NFS, config attached, running (from a startup
> > script):
> >
> > iptables -t nat -A POSTROUTING -o eth0 -j
On Tue, 12 Feb 2008 15:27:29 -0700
"Dan Williams" <[EMAIL PROTECTED]> wrote:
> > > Or just let the subsystem always be available.
> >
> > It used to be always available, but then it was changed. Assuming there
> > was a reason for this change, I guess we don't want to change it back.
> >
>
>
On Wed, 13 Feb 2008 00:21:41 -0700
"Dan Williams" <[EMAIL PROTECTED]> wrote:
> On Feb 12, 2008 9:43 AM, Haavard Skinnemoen <[EMAIL PROTECTED]> wrote:
> [..]
> > +enum dma_slave_direction {
> > + DMA_SLAVE_TO_MEMORY,
> > + DMA_S
On Wed, 13 Feb 2008 00:21:41 -0700
Dan Williams [EMAIL PROTECTED] wrote:
On Feb 12, 2008 9:43 AM, Haavard Skinnemoen [EMAIL PROTECTED] wrote:
[..]
+enum dma_slave_direction {
+ DMA_SLAVE_TO_MEMORY,
+ DMA_SLAVE_FROM_MEMORY,
+};
Just reuse enum dma_data_direction from
On Tue, 12 Feb 2008 15:27:29 -0700
Dan Williams [EMAIL PROTECTED] wrote:
Or just let the subsystem always be available.
It used to be always available, but then it was changed. Assuming there
was a reason for this change, I guess we don't want to change it back.
Adrian had
On Wed, 13 Feb 2008 00:48:29 -0800
Andrew Morton [EMAIL PROTECTED] wrote:
On Tue, 12 Feb 2008 22:46:01 +1100 Ben Nizette [EMAIL PROTECTED] wrote:
On an AVR32, root over NFS, config attached, running (from a startup
script):
iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
On Wed, 13 Feb 2008 10:10:24 +0100
Haavard Skinnemoen [EMAIL PROTECTED] wrote:
ip_tables: (C) 2000-2006 Netfilter Core Team
nf_conntrack version 0.5.0 (1024 buckets, 4096 max)
Unable to handle kernel paging request at virtual address d76a7138
ptbr = 91d3b000 pgd = e5f3 pte
On Wed, 13 Feb 2008 05:54:12 -0500 (EST)
Robert P. J. Day [EMAIL PROTECTED] wrote:
i've also updated the list of what i call badref CONFIG variables
-- that is, tests of CONFIG_ variables that appear to be undefined
anywhere in a Kconfig file (which typically represents a meaningless
test,
definition these days? I think the patch below should take care of all
four...unless I've misunderstood something.
Signed-off-by: Haavard Skinnemoen [EMAIL PROTECTED]
diff --git a/lib/bug.c b/lib/bug.c
index 530f38f..0d67419 100644
--- a/lib/bug.c
+++ b/lib/bug.c
@@ -35,6 +35,7 @@
Jeremy
On Wed, 13 Feb 2008 08:42:15 -0800
Andrew G. Morgan [EMAIL PROTECTED] wrote:
However, it is a warning and, for any existing app that doesn't care
about newly added capabilities, the warning is benign.
Ok, I see. Thanks for explaining.
Haavard
--
To unsubscribe from this list: send the line
On Wed, 13 Feb 2008 19:30:51 +0100
Pierre Ossman [EMAIL PROTECTED] wrote:
I think this was meant to go away.
And this should go into the core.
I also pointed this out. mmc_remove_host() will synchronize this for
you.
Right. Sorry. I focused so much on getting the driver to work correctly
On Wed, 13 Feb 2008 12:07:26 -0700
Dan Williams [EMAIL PROTECTED] wrote:
+struct dma_slave_descriptor {
+ struct dma_async_tx_descriptor txd;
+ struct list_head client_node;
+};
Can you explain a bit why client_node is needed? I do not think we
need dma_slave_descriptor
On Wed, 13 Feb 2008 12:11:58 -0700
Dan Williams [EMAIL PROTECTED] wrote:
+ desc = chan-device-device_prep_slave(chan,
+ sg_dma_address(sg), direction,
+ DMA_SLAVE_WIDTH_32BIT,
+
On Tue, 12 Feb 2008 14:43:30 -0600
Olof Johansson <[EMAIL PROTECTED]> wrote:
> > - depends on (PCI && X86) || ARCH_IOP32X || ARCH_IOP33X || ARCH_IOP13XX
> > + depends on (PCI && X86) || ARCH_IOP32X || ARCH_IOP33X || ARCH_IOP13XX
> > || AVR32
>
> This is a slippery slope. Things should be
performance is
quite acceptable, so while I think the memcpy performance can be
improved, it's not very high priority right now.
Signed-off-by: Haavard Skinnemoen <[EMAIL PROTECTED]>
Changes since v2:
* Dequeue all pending transfers in terminate_all()
* Rename dw_dmac.h -> dw_dm
.
The driver has also been tested using the mmc_test module on the same
cards, with somewhat less convincing results. In particular, badly
aligned multiblock writes seem to confuse some of the cards.
Signed-off-by: Haavard Skinnemoen <[EMAIL PROTECTED]>
Changes since v2:
* Reset the controller
requesting the channel to the
driver's device_alloc_chan_resources hook so that it can pick the
necessary information from the dma_client struct by itself.
Signed-off-by: Haavard Skinnemoen <[EMAIL PROTECTED]>
---
drivers/dma/dmaengine.c |3 ++-
drivers/dma/ioat_dma.c|5 +++--
drive
, dma_chan and/or
dma_slave_descriptor structures to allow controller-specific
operations. The client driver can detect such extensions by looking at
the DMA Engine's struct device, or it can request a specific DMA
Engine device by setting the dma_dev field in struct dma_slave.
Signed-off-by: Haavard Skinnemo
understand the channel refcounting
logic at all... dma_chan_get() simply increments a per-cpu value. How
can we be sure that whatever CPU calls dma_chan_is_in_use() sees the
same value?
Signed-off-by: Haavard Skinnemoen <[EMAIL PROTECTED]>
---
drivers/dma/dmaengine.c | 12 +---
include
Set the 'parent' field of channel class devices to point to the
physical DMA device initialized by the DMA engine driver.
This allows drivers to use chan->dev.parent for syncing DMA buffers
and adds a 'device' symlink to the real device in
/sys/class/dma/dmaXchanY.
Signed-off-by: Haav
Signed-off-by: Haavard Skinnemoen <[EMAIL PROTECTED]>
---
drivers/dma/Kconfig |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/dma/Kconfig b/drivers/dma/Kconfig
index 893a3f8..1a727c1 100644
--- a/drivers/dma/Kconfig
+++ b/drivers/dma/Kconfig
@@ -4,
On Tue, 12 Feb 2008 14:43:30 -0600
Olof Johansson [EMAIL PROTECTED] wrote:
- depends on (PCI X86) || ARCH_IOP32X || ARCH_IOP33X || ARCH_IOP13XX
+ depends on (PCI X86) || ARCH_IOP32X || ARCH_IOP33X || ARCH_IOP13XX
|| AVR32
This is a slippery slope. Things should be the other way
performance is
quite acceptable, so while I think the memcpy performance can be
improved, it's not very high priority right now.
Signed-off-by: Haavard Skinnemoen [EMAIL PROTECTED]
Changes since v2:
* Dequeue all pending transfers in terminate_all()
* Rename dw_dmac.h - dw_dmac_regs.h
* Define
.
The driver has also been tested using the mmc_test module on the same
cards, with somewhat less convincing results. In particular, badly
aligned multiblock writes seem to confuse some of the cards.
Signed-off-by: Haavard Skinnemoen [EMAIL PROTECTED]
Changes since v2:
* Reset the controller after each
and/or
dma_slave_descriptor structures to allow controller-specific
operations. The client driver can detect such extensions by looking at
the DMA Engine's struct device, or it can request a specific DMA
Engine device by setting the dma_dev field in struct dma_slave.
Signed-off-by: Haavard Skinnemoen [EMAIL PROTECTED
understand the channel refcounting
logic at all... dma_chan_get() simply increments a per-cpu value. How
can we be sure that whatever CPU calls dma_chan_is_in_use() sees the
same value?
Signed-off-by: Haavard Skinnemoen [EMAIL PROTECTED]
---
drivers/dma/dmaengine.c | 12 +---
include/linux
Set the 'parent' field of channel class devices to point to the
physical DMA device initialized by the DMA engine driver.
This allows drivers to use chan-dev.parent for syncing DMA buffers
and adds a 'device' symlink to the real device in
/sys/class/dma/dmaXchanY.
Signed-off-by: Haavard
Signed-off-by: Haavard Skinnemoen [EMAIL PROTECTED]
---
drivers/dma/Kconfig |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/dma/Kconfig b/drivers/dma/Kconfig
index 893a3f8..1a727c1 100644
--- a/drivers/dma/Kconfig
+++ b/drivers/dma/Kconfig
@@ -4,7 +4,7
requesting the channel to the
driver's device_alloc_chan_resources hook so that it can pick the
necessary information from the dma_client struct by itself.
Signed-off-by: Haavard Skinnemoen [EMAIL PROTECTED]
---
drivers/dma/dmaengine.c |3 ++-
drivers/dma/ioat_dma.c|5 +++--
drivers/dma
On Thu, 07 Feb 2008 15:28:57 +1100
Ben Nizette <[EMAIL PROTECTED]> wrote:
> New-style I2C drivers require that motherboard-mounted I2C devices are
> registered with the I2C core, typically at arch_initcall time. This can be
> done nice and neat by passing the struct i2c_board_info[] through
>
On Thu, 07 Feb 2008 15:28:57 +1100
Ben Nizette [EMAIL PROTECTED] wrote:
New-style I2C drivers require that motherboard-mounted I2C devices are
registered with the I2C core, typically at arch_initcall time. This can be
done nice and neat by passing the struct i2c_board_info[] through
On Wed, 6 Feb 2008 14:08:35 -0700
"Dan Williams" <[EMAIL PROTECTED]> wrote:
> On Jan 30, 2008 5:26 AM, Haavard Skinnemoen <[EMAIL PROTECTED]> wrote:
> [..]
> > Right. I'll add a "unsigned int engine_type" field so that engine
> > drivers can go
On Wed, 6 Feb 2008 11:46:43 -0700
"Dan Williams" <[EMAIL PROTECTED]> wrote:
> > The client must somehow know when the transfer is complete -- after
> > all, it has to call async_tx_ack() at some point. So additional
> > callbacks shouldn't be needed.
> >
>
> The 'ack' only signifies that the
On Wed, 6 Feb 2008 11:46:43 -0700
Dan Williams [EMAIL PROTECTED] wrote:
The client must somehow know when the transfer is complete -- after
all, it has to call async_tx_ack() at some point. So additional
callbacks shouldn't be needed.
The 'ack' only signifies that the client is done
On Wed, 6 Feb 2008 14:08:35 -0700
Dan Williams [EMAIL PROTECTED] wrote:
On Jan 30, 2008 5:26 AM, Haavard Skinnemoen [EMAIL PROTECTED] wrote:
[..]
Right. I'll add a unsigned int engine_type field so that engine
drivers can go ahead and extend the standard dma_device structure.
Maybe we
On Wed, 06 Feb 2008 14:41:09 +0100
michael <[EMAIL PROTECTED]> wrote:
> I refer to this part of documentation:
>
> "The USART behavior when hardware handshaking is enabled is the same as
> the behavior in
> standard synchronous or asynchronous mode, except that the receiver
> drives the RTS
On Tue, 05 Feb 2008 13:29:35 +0100
michael <[EMAIL PROTECTED]> wrote:
> Just one question:
> Receiving with hardware handshake works without PDC?
I don't know...I haven't tried. These patches shouldn't change anything
though.
Haavard
--
To unsubscribe from this list: send the line "unsubscribe
On Tue, 05 Feb 2008 13:29:35 +0100
michael [EMAIL PROTECTED] wrote:
Just one question:
Receiving with hardware handshake works without PDC?
I don't know...I haven't tried. These patches shouldn't change anything
though.
Haavard
--
To unsubscribe from this list: send the line unsubscribe
On Wed, 06 Feb 2008 14:41:09 +0100
michael [EMAIL PROTECTED] wrote:
I refer to this part of documentation:
The USART behavior when hardware handshaking is enabled is the same as
the behavior in
standard synchronous or asynchronous mode, except that the receiver
drives the RTS pin as
1 - 100 of 617 matches
Mail list logo
