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
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-
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
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 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)
> +{
> + unsigned
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.
>
> Thes
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 wel
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.
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 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
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 tried
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 tell
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 b/dri
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 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 thi
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
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
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 dma_
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.
> Coul
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
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 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
[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 co
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 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 dma_sl
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 correc
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 li
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
-
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
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 M
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 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 t
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 ->
bled.
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
the client 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|
han 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 Ski
eally 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 +---
in
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 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 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
> at3
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 ca
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 cl
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
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 l
On Tue, 5 Feb 2008 13:03:34 +0100
Sam Ravnborg <[EMAIL PROTECTED]> wrote:
> On Tue, Feb 05, 2008 at 12:11:26PM +0100, Haavard Skinnemoen wrote:
> > On Mon, 4 Feb 2008 20:46:26 +0100
> > Sam Ravnborg <[EMAIL PROTECTED]> wrote:
> >
> > > Sorry for not ca
On Mon, 4 Feb 2008 20:46:26 +0100
Sam Ravnborg <[EMAIL PROTECTED]> wrote:
> Sorry for not catching this.
> I just blow away my git tree at kernel.org to avoid getting it
> merged with the bug but Linus was too quick for me so he already
> merged kbuild.git and applied this patch afterwards.
Ok, t
On Mon, 04 Feb 2008 20:01:26 +0100
michael <[EMAIL PROTECTED]> wrote:
> I think the the atmel_interrupt handler
> must check the
> pass_counter before return IRQ_HANDLED.
I'm not sure if it helps in this particular case but yeah, since the
interrupt may be shared, it's definitely wrong to always
On Wed, 30 Jan 2008 10:39:47 -0700
"Dan Williams" <[EMAIL PROTECTED]> wrote:
> Agreed, the issue is how to do this without requiring an
> interrupt+callback sequence for each transaction or requiring the
> client to carry per transaction unmap-data. For example NET_DMA never
> sees a dma_addr_t a
On Thu, 31 Jan 2008 20:36:25 +0100
"Remy Bohmer" <[EMAIL PROTECTED]> wrote:
> A long shot, but can it be that the ringbuffer overflows, and that
> therefor characters are lost?
That's what I was thinking too. If this is indeed the cause, the
dev_err() added by the debug patch I posted should trig
hen the patch was submitted, I sent the avr32
pull request early as promised (more than a week ago), but it still
broke. Please apply the fix below. This fixes 2.6.24-mm1 too.
Signed-off-by: Haavard Skinnemoen <[EMAIL PROTECTED]>
---
arch/avr32/Kconfig |2 --
1 file changed, 2 deletions(-)
Index
[removed bogus @atmel.co address from Cc]
On Sun, 03 Feb 2008 14:22:18 +0300
Cyrill Gorcunov <[EMAIL PROTECTED]> wrote:
> Signed-off-by: Cyrill Gorcunov <[EMAIL PROTECTED]>
Applied, thanks.
I found myself having to grep through include/linux to figure out what
this _AC macro was really all abou
On Thu, 31 Jan 2008 02:53:50 +0100
michael <[EMAIL PROTECTED]> wrote:
> The overrun still remain. An lrz receive session is impossible using
> full preemption. I will try the dma patch too and test in iso mode for
> smart card.
Hmm. Seems to work reasonably well on a non-rt kernel -- I get quite
Introduced by atmel_serial-split-the-interrupt-handler.patch.
Thanks to michael <[EMAIL PROTECTED]> for spotting it.
Signed-off-by: Haavard Skinnemoen <[EMAIL PROTECTED]>
---
It was surprisingly difficult to actually provoke a crash without this
patch, but the system did start to b
On Thu, 31 Jan 2008 04:51:03 -0800
David Brownell <[EMAIL PROTECTED]> wrote:
> First steps are after all followed by second steps, and often
> by third steps. It's not "overengineering" to recognize when
> those steps necessarily have a direction.
But it might be considered overengineering to act
On Thu, 31 Jan 2008 00:27:24 -0800
David Brownell <[EMAIL PROTECTED]> wrote:
> On Wednesday 30 January 2008, Haavard Skinnemoen wrote:
> > So basically, you're asking for maximum flexibility with minimum
> > overhead.
>
> That's always a goal, but that's
On Wed, 30 Jan 2008 10:56:12 -0800
David Brownell <[EMAIL PROTECTED]> wrote:
> On Wednesday 30 January 2008, Haavard Skinnemoen wrote:
> > Yeah, although the nasty thing about UARTs is that you never know when
> > DMA really is idle.
>
> If the UART isn't
On Wed, 30 Jan 2008 16:26:27 +0100
michael <[EMAIL PROTECTED]> wrote:
> > I have no idea. Could you post some more specifics about what you
> > modified, for example a diff?
> >
> >
>
> ...
> /* The interrupt handler does not take the lock */
> spin_lock_irqsave(&port->lock, flags);
> atmel_
On Wed, 30 Jan 2008 12:05:40 +0100
"Remy Bohmer" <[EMAIL PROTECTED]> wrote:
> > > I believe I have to look at the latest set of patches, and try to find
> > > any regressions. Do you have a location somewhere where I can download
> > > the latest versions? Or do I need to dig through LKML to find
On Wed, 30 Jan 2008 11:29:59 +0100
michael <[EMAIL PROTECTED]> wrote:
> > Now, _that_ is strange. I can't see anything that needs protection
> > across that call; in fact, I think we can lock a lot less than what we
> > currently do.
> >
> >
> I explain it bad:
> - with spin_lock the system seem
On Wed, 30 Jan 2008 02:52:49 -0800
David Brownell <[EMAIL PROTECTED]> wrote:
> On Wednesday 30 January 2008, Haavard Skinnemoen wrote:
> > Descriptor-based vs. register-based transfers sounds like something the
> > DMA engine driver is free to decide on its own.
>
>
On Tue, 29 Jan 2008 19:44:53 -0800
David Brownell <[EMAIL PROTECTED]> wrote:
> On Monday 28 January 2008, Haavard Skinnemoen wrote:
> >
> > > What will AVR32 (AP7) need to do, when it supports system sleep states?
> >
> > Not sure. The PIOs seem to requ
On Wed, 30 Jan 2008 11:21:49 +0100
"Remy Bohmer" <[EMAIL PROTECTED]> wrote:
> > > * Drop the lock here since it might end up calling
> > > * uart_start(), which takes the lock.
> > >spin_unlock(&port->lock);
> > > */
> > > tty_flip_buffer_push(port->info->tty);
> > > /*
> > > spin_l
On Wed, 30 Jan 2008 00:12:23 +0100
michael <[EMAIL PROTECTED]> wrote:
> I'm testing this patch on an at91sam9260 on 2.6.24-rt. I'm using this
> patch with the tclib support for hrtimer and the clocksource pit_clk.
> These are the results:
>
> - Voluntary Kernel Preemption the system (crash)
> - P
On Tue, 29 Jan 2008 23:30:05 -0800
David Brownell <[EMAIL PROTECTED]> wrote:
> On Tuesday 29 January 2008, Haavard Skinnemoen wrote:
> > @@ -297,6 +356,13 @@ struct dma_device {
> > struct dma_async_tx_descriptor *(*device_prep_dma_interrupt)(
> >
On Tue, 29 Jan 2008 22:56:14 -0800
David Brownell <[EMAIL PROTECTED]> wrote:
> On Tuesday 29 January 2008, Haavard Skinnemoen wrote:
> >
> > Btw, there's one issue I forgot to mention: I believe the DMA Engine
> > framework is currently misusing the DMA mapping
On Tue, 29 Jan 2008 19:10:08 +0100
Haavard Skinnemoen <[EMAIL PROTECTED]> wrote:
> This patch series adds the necessary interfaces to the DMA Engine
> framework to use functionality found on most embedded DMA controllers:
> DMA from and to I/O registers with hardware handshaking
el sources
provided by Atmel, but this particular version uses the generic DMA
Engine framework (with the slave extensions) instead of an
avr32-only DMA controller framework.
Signed-off-by: Haavard Skinnemoen <[EMAIL PROTECTED]>
---
arch/avr32/boards/atngw100/setup.c |6 +
arch/avr32/
e DMA Engine framework. It also implements the
proposed extensions to the DMA Engine API for slave DMA operations.
Signed-off-by: Haavard Skinnemoen <[EMAIL PROTECTED]>
---
arch/avr32/mach-at32ap/at32ap700x.c| 29 +-
drivers/dma/Kconfig|9 +
drivers/d
ions to be terminated
prematurely.
Signed-off-by: Haavard Skinnemoen <[EMAIL PROTECTED]>
dmaslave interface changes since v1:
* Drop the set_direction and set_width descriptor hooks. Pass the
direction and width to the prep function instead.
* Declare a dma_slave struct with fixed inf
moen/dmaslave.git master
which contains everything you need to try it out.
Haavard Skinnemoen (5):
dmaengine: Add dma_client parameter to device_alloc_chan_resources
dmaengine: Add slave DMA interface
dmaengine: Make DMA Engine menu visible for AVR32 users
dmaengine: Driver fo
the client 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|
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 Mon, 28 Jan 2008 10:21:57 -0800
David Brownell <[EMAIL PROTECTED]> wrote:
> What will AVR32 (AP7) need to do, when it supports system sleep states?
Not sure. The PIOs seem to require a clock in order to detect a pin
change, so I don't think we can enter very deep sleep states if we want
to be
On Mon, 28 Jan 2008 12:15:00 +0100
michael <[EMAIL PROTECTED]> wrote:
> Hi,
> I implement a little patch (ndr just for a try) for the atmel serial
> driver atmel_serial.c to wakeup the system when it is in suspend-ram state.
> I reconfigure the RXD pin as a gpio in suspend function and restore it
ERIAL_XMIT_SIZE/UART_XMIT_SIZE/ since the latter is what the
serial core circ macros use.
Signed-off-by: Haavard Skinnemoen <[EMAIL PROTECTED]>
---
Please fold into atmel_serial-add-dma-support.patch, or let me know if
you want a replacement for that patch.
drivers/serial/
On Mon, 28 Jan 2008 02:20:00 -0800
Andrew Morton <[EMAIL PROTECTED]> wrote:
> On Mon, 28 Jan 2008 10:59:09 +0100 Haavard Skinnemoen <[EMAIL PROTECTED]>
> wrote:
>
> > > ho-hum. The generic uart buffer-handling code does ringbuffers the wrong
> > > way.
On Mon, 28 Jan 2008 11:22:49 +0100
"Francis Moreau" <[EMAIL PROTECTED]> wrote:
> > Please let me know if you think this will work for your hardware.
>
> Thanks for pointing this out. I currently can't look at this but I'll
> try to give it
> a deep look this week.
Great. I'll Cc you on the nex
On Sat, 26 Jan 2008 22:02:00 -0800
Andrew Morton <[EMAIL PROTECTED]> wrote:
> > On Thu, 24 Jan 2008 13:41:49 +0100 Haavard Skinnemoen <[EMAIL PROTECTED]>
> > wrote:
> > +#define PDC_RX_BUF(port) &(port)->pdc_rx[(port)->pdc_rx_idx]
> > +#define
On Mon, 28 Jan 2008 01:29:32 -0800
Andrew Morton <[EMAIL PROTECTED]> wrote:
> > - if (i > 0) {
> > - for (i = i - 1; i >= 0; i--) {
> > - led_classdev_unregister(&leds[i].cdev);
> > - pwm_channel_free(&leds[i].pwmc);
> > - }
> > + while (
On Mon, 28 Jan 2008 09:55:58 +0100
"Francis Moreau" <[EMAIL PROTECTED]> wrote:
> My DMA controller has very little in common with ISA DMA one. But I'd like to
> use it in a driver. This driver can do DMA but with the help of an external
> DMA
> controller. It's only implement the "slave" side. So
On Sun, 27 Jan 2008 21:32:32 -0800
Andrew Morton <[EMAIL PROTECTED]> wrote:
> On Thu, 24 Jan 2008 15:33:45 +0100 Haavard Skinnemoen <[EMAIL PROTECTED]>
> wrote:
>
> > + if (i > 0) {
> > + for (i = i - 1; i >= 0; i--) {
> > +
On Thu, 24 Jan 2008 12:53:13 -0800
David Brownell <[EMAIL PROTECTED]> wrote:
> On Thursday 24 January 2008, Haavard Skinnemoen wrote:
> > +config ATMEL_PWM
> > + tristate "Atmel AT32/AT91 PWM support"
> > + depends on (AVR32 || AT91) && E
architectures at the moment.
Please update your patch so that it also updates the avr32 Kconfig when
removing it.
David Brownell (1):
[AVR32] extint: change set_irq_type() handling
Haavard Skinnemoen (16):
[AVR32] Drop GFP_COMP for DMA memory allocations
[AVR32] Remove redundant
f629bbdab3a1c114f619bf1c
Author: Haavard Skinnemoen <[EMAIL PROTECTED]>
Date: Wed Oct 31 15:22:34 2007 +0100
[AVR32] Include instrumentation menu
Remove KPROBES option from Kconfig.debug and include
kernel/Kconfig.instrumentation.
Signed-off-by: Haavard Skinnemoe
On Thu, 24 Jan 2008 14:32:48 +0100
Marc Pignat <[EMAIL PROTECTED]> wrote:
> Tested and working on at91rm9200 using 2.6.24-rc8, in one word... ack.
Great! Thanks for testing!
Haavard
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROT
ess, while 244
to 248 is imperceptible.
This is mostly intended to be a simple example of PWM, although it's
realistic since LCD backlights are often driven with PWM to conserve
battery power (and offer brightness options).
Signed-off-by: David Brownell <[EMAIL PROTECTED]>
Signed-off-by
vice dynamically]
Signed-off-by: David Brownell <[EMAIL PROTECTED]>
Signed-off-by: Haavard Skinnemoen <[EMAIL PROTECTED]>
---
arch/avr32/mach-at32ap/at32ap700x.c | 54
drivers/misc/Kconfig |9
drivers/misc/Makefile |1
drivers/misc/atm
Two patches from David Brownell follow. The first one implements a
low-level driver/library for the PWM controller integrated on some
newer AVR32- and ARM-based chips from Atmel. The second one uses this
library to implement a LED driver with variable brightness.
There's currently no user of this
g, misc cleanups]
Signed-off-by: Remy Bohmer <[EMAIL PROTECTED]>
Signed-off-by: Haavard Skinnemoen <[EMAIL PROTECTED]>
---
drivers/serial/Kconfig| 15 ++
drivers/serial/atmel_serial.c | 393 ++---
2 files changed, 384 insertions(+), 24 deleti
When possible, pass the tty name to request_irq() so that the user can
easily distinguish the different serial ports in /proc/interrupts.
Signed-off-by: Haavard Skinnemoen <[EMAIL PROTECTED]>
---
drivers/serial/atmel_serial.c |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
ations]
Signed-off-by: Remy Bohmer <[EMAIL PROTECTED]>
Signed-off-by: Haavard Skinnemoen <[EMAIL PROTECTED]>
---
drivers/serial/atmel_serial.c | 245 +++-
1 files changed, 190 insertions(+), 55 deletions(-)
diff --git a/drivers/serial/atmel_serial.
atmel_serial") in /proc/interrupts
Chip Coldwell (1):
atmel_serial: Add DMA support
Haavard Skinnemoen (6):
MAINTAINERS: Add myself as maintainer of the atmel_serial driver
atmel_serial: Use cpu_relax() when busy-waiting
atmel_serial: Use existing console options only if B
Replace two instances of barrier() with cpu_relax() since that's the
right thing to do when busy-waiting. This does not actually change
anything since cpu_relax() is defined as barrier() on both ARM and
AVR32.
Signed-off-by: Haavard Skinnemoen <[EMAIL PROTECTED]>
Acked-by: Andrew Vic
From: Remy Bohmer <[EMAIL PROTECTED]>
This patch cleans up the atmel_serial driver to conform the coding rules.
It contains no functional change.
Signed-off-by: Remy Bohmer <[EMAIL PROTECTED]>
Signed-off-by: Haavard Skinnemoen <[EMAIL PROTECTED]>
---
drivers/serial/atm
1 - 100 of 309 matches
Mail list logo
