On Sat, Feb 09, 2013 at 09:35:53PM +0530, Sekhar Nori wrote:
Hi Matt,
This version introduces build/bisect issues.
Ok, see later comment which addresses this...
On 2/1/2013 11:52 PM, Matt Porter wrote:
Move mach-davinci/dma.c to common/edma.c so it can be used
by OMAP (specifically
On Sat, Feb 09, 2013 at 08:08:50PM +, Russell King wrote:
On Sat, Feb 09, 2013 at 09:35:53PM +0530, Sekhar Nori wrote:
On 2/1/2013 11:52 PM, Matt Porter wrote:
+ ret = of_address_to_resource(node, 1, res);
of_address_to_resource() needs linux/of_address.h
+ if
Hi Matt,
This version introduces build/bisect issues.
On 2/1/2013 11:52 PM, Matt Porter wrote:
Move mach-davinci/dma.c to common/edma.c so it can be used
by OMAP (specifically AM33xx) as well.
Signed-off-by: Matt Porter mpor...@ti.com
Acked-by: Sekhar Nori nsek...@ti.com
diff --git
On Sat, Feb 09, 2013 at 09:35:53PM +0530, Sekhar Nori wrote:
On 2/1/2013 11:52 PM, Matt Porter wrote:
+ ret = of_address_to_resource(node, 1, res);
of_address_to_resource() needs linux/of_address.h
+ if (IS_ERR_VALUE(ret))
This needs linux/err.h
More importantly, is this the
On Mon, Feb 04, 2013 at 09:47:38PM +, Arnd Bergmann wrote:
On Monday 04 February 2013, Linus Walleij wrote:
So I think the above concerns are moot. The callback we can
set on cookies is entirely optional, and it's even implemented by
each DMA engine, and some may not even support it but
On Mon, Feb 04, 2013 at 04:54:45PM -0500, Cyril Chemparathy wrote:
You're assuming that cookies complete in order. That is not necessarily
true.
Under what circumstances is that not true?
--
Free Next-Gen Firewall
On Mon, Feb 4, 2013 at 10:54 PM, Cyril Chemparathy cy...@ti.com wrote:
On 02/04/2013 04:11 PM, Linus Walleij wrote:
Cyril, just stack up the cookies and take a sweep over them to see
which ones are baked when the NAPI poll comes in - problem
solved.
You're assuming that cookies complete in
On 02/05/2013 07:38 AM, Russell King - ARM Linux wrote:
On Mon, Feb 04, 2013 at 09:47:38PM +, Arnd Bergmann wrote:
On Monday 04 February 2013, Linus Walleij wrote:
So I think the above concerns are moot. The callback we can
set on cookies is entirely optional, and it's even implemented by
On 02/05/2013 07:41 AM, Russell King - ARM Linux wrote:
On Mon, Feb 04, 2013 at 04:54:45PM -0500, Cyril Chemparathy wrote:
You're assuming that cookies complete in order. That is not necessarily
true.
Under what circumstances is that not true?
Notably when hardware can prioritize certain
On Mon, Feb 4, 2013 at 11:30 PM, Cyril Chemparathy cy...@ti.com wrote:
NAPI needs to switch between polled and interrupt driven modes of operation.
Further, in a given poll, it needs to be able to limit the amount of traffic
processed to a specified budget.
I don't think any of this is a
On Tue, Feb 05, 2013 at 04:47:05PM +, Mark Brown wrote:
On Tue, Feb 05, 2013 at 05:21:48PM +0100, Linus Walleij wrote:
For IRQ mode, use the completion callback to push each cookie
to NAPI, and thus let the IRQ drive the traffic.
The whole purpose of NAPI is to avoid taking
On Tue, Feb 05, 2013 at 04:30:45PM +0100, Linus Walleij wrote:
On Mon, Feb 4, 2013 at 10:54 PM, Cyril Chemparathy cy...@ti.com wrote:
On 02/04/2013 04:11 PM, Linus Walleij wrote:
Cyril, just stack up the cookies and take a sweep over them to see
which ones are baked when the NAPI poll
* Felipe Balbi ba...@ti.com [130204 07:46]:
Current DMA abstraction is quite poor, for example there's no way to
compile support for multiple DMA engines. Code also makes certain, IMO
unnecessary, assumptions about the underlying DMA engine (abstraction is
poor, as said above but it we could
On Tue, Feb 5, 2013 at 5:47 PM, Mark Brown
broo...@opensource.wolfsonmicro.com wrote:
On Tue, Feb 05, 2013 at 05:21:48PM +0100, Linus Walleij wrote:
For IRQ mode, use the completion callback to push each cookie
to NAPI, and thus let the IRQ drive the traffic.
The whole purpose of NAPI is to
On Tue, Feb 5, 2013 at 6:14 PM, Russell King - ARM Linux
li...@arm.linux.org.uk wrote:
On Tue, Feb 05, 2013 at 04:30:45PM +0100, Linus Walleij wrote:
So put them on a wait list? Surely you will have a list of pending
cookies and pick from the front of the queue if there isn't a hole on
queue
On 02/05/2013 01:29 PM, Linus Walleij wrote:
On Tue, Feb 5, 2013 at 5:47 PM, Mark Brown
broo...@opensource.wolfsonmicro.com wrote:
On Tue, Feb 05, 2013 at 05:21:48PM +0100, Linus Walleij wrote:
For IRQ mode, use the completion callback to push each cookie
to NAPI, and thus let the IRQ drive
On Tuesday 05 February 2013, Tony Lindgren wrote:
* Felipe Balbi ba...@ti.com [130204 07:46]:
Current DMA abstraction is quite poor, for example there's no way to
compile support for multiple DMA engines. Code also makes certain, IMO
unnecessary, assumptions about the underlying DMA
On Saturday 02 February 2013 04:07:59 Sergei Shtylyov wrote:
On 02-02-2013 1:30, Russell King - ARM Linux wrote:
because it doesn't make sense to support multiple DMA APIs. We can check
from MUSB's registers if it was configured with Inventra DMA support and
based on that we can register
On Mon, Feb 04, 2013 at 05:41:53PM +0200, Felipe Balbi wrote:
Hi,
On Fri, Feb 01, 2013 at 09:30:03PM +, Russell King - ARM Linux wrote:
I guess to make the MUSB side simpler we would need musb-dma-engine
glue
to map dmaengine to the private MUSB API. Then we would have some
Hello.
On 02/04/2013 06:41 PM, Felipe Balbi wrote:
I guess to make the MUSB side simpler we would need musb-dma-engine glue
to map dmaengine to the private MUSB API. Then we would have some
starting point to also move inventra (and anybody else) to dmaengine
API.
Why? Inventra is a
Hello.
On 02/04/2013 07:47 PM, Felipe Balbi wrote:
On Mon, Feb 04, 2013 at 08:36:38PM +0300, Sergei Shtylyov wrote:
opted out of it. From the top of my head we have CPPI 3.x, CPPI 4.1,
Inventra DMA, OMAP sDMA and ux500 DMA engines supported by the driver.
Granted, CPPI 4.1 makes some
On Mon, Feb 04, 2013 at 06:47:12PM +0200, Felipe Balbi wrote:
Hi,
On Mon, Feb 04, 2013 at 08:36:38PM +0300, Sergei Shtylyov wrote:
In my eyes, getting rid of the mess doesn't justify breaking the rules
that
Russell formulated above.
MUSB is no PCI, there is no single, standard
Hello.
On 02/04/2013 08:02 PM, Felipe Balbi wrote:
On Mon, Feb 04, 2013 at 08:36:38PM +0300, Sergei Shtylyov wrote:
opted out of it. From the top of my head we have CPPI 3.x, CPPI 4.1,
Inventra DMA, OMAP sDMA and ux500 DMA engines supported by the driver.
Granted, CPPI 4.1 makes some
On 02/04/2013 12:02 PM, Felipe Balbi wrote:
Hi,
On Mon, Feb 04, 2013 at 08:54:17PM +0300, Sergei Shtylyov wrote:
On Mon, Feb 04, 2013 at 08:36:38PM +0300, Sergei Shtylyov wrote:
opted out of it. From the top of my head we have CPPI 3.x, CPPI 4.1,
Inventra DMA, OMAP sDMA and ux500 DMA engines
On Mon, Feb 4, 2013 at 8:22 PM, Cyril Chemparathy cy...@ti.com wrote:
Based on our experience with fitting multiple subsystems on top of this
DMA-Engine driver, I must say that the DMA-Engine interface has proven
to be a less than ideal fit for the network driver use case.
The first problem
On Mon, Feb 4, 2013 at 9:33 PM, Mark Brown
broo...@opensource.wolfsonmicro.com wrote:
On Mon, Feb 04, 2013 at 09:29:46PM +0100, Linus Walleij wrote:
On Mon, Feb 4, 2013 at 8:22 PM, Cyril Chemparathy cy...@ti.com wrote:
Based on our experience with fitting multiple subsystems on top of this
On Monday 04 February 2013, Linus Walleij wrote:
So I think the above concerns are moot. The callback we can
set on cookies is entirely optional, and it's even implemented by
each DMA engine, and some may not even support it but require
polling, and then it won't even be implemented by the
On 02/04/2013 04:11 PM, Linus Walleij wrote:
On Mon, Feb 4, 2013 at 9:33 PM, Mark Brown
broo...@opensource.wolfsonmicro.com wrote:
On Mon, Feb 04, 2013 at 09:29:46PM +0100, Linus Walleij wrote:
On Mon, Feb 4, 2013 at 8:22 PM, Cyril Chemparathy cy...@ti.com wrote:
Based on our experience with
On 02/04/2013 03:29 PM, Linus Walleij wrote:
On Mon, Feb 4, 2013 at 8:22 PM, Cyril Chemparathy cy...@ti.com wrote:
Based on our experience with fitting multiple subsystems on top of this
DMA-Engine driver, I must say that the DMA-Engine interface has proven
to be a less than ideal fit for the
On Sat, Feb 02, 2013 at 06:09:24AM +0400, Sergei Shtylyov wrote:
Hello.
On 02-02-2013 4:44, Russell King - ARM Linux wrote:
On Fri, Feb 01, 2013 at 11:49:11PM +0300, Sergei Shtylyov wrote:
good point, do you wanna send some patches ?
I have already sent them countless times and even
On Sat, Feb 02, 2013 at 10:18:51AM +, Russell King - ARM Linux wrote:
On Sat, Feb 02, 2013 at 06:09:24AM +0400, Sergei Shtylyov wrote:
Hello.
On 02-02-2013 4:44, Russell King - ARM Linux wrote:
On Fri, Feb 01, 2013 at 11:49:11PM +0300, Sergei Shtylyov wrote:
good point, do you
On Fri, Feb 01, 2013 at 01:59:59PM -0500, Matt Porter wrote:
On Fri, Feb 01, 2013 at 07:52:46PM +, Sergei Shtylyov wrote:
Hello.
On 02/01/2013 09:49 PM, Matt Porter wrote:
Move mach-davinci/dma.c to common/edma.c so it can be used
by OMAP (specifically AM33xx) as well.
I
On Fri, Feb 01, 2013 at 10:41:08AM -0800, Tony Lindgren wrote:
* Matt Porter mpor...@ti.com [130201 10:25]:
Move mach-davinci/dma.c to common/edma.c so it can be used
by OMAP (specifically AM33xx) as well.
I think this should rather go to drivers/dma/?
Yes, it should, but just like OMAP,
On Sat, Feb 02, 2013 at 12:49:06PM +, Russell King wrote:
On Fri, Feb 01, 2013 at 10:41:08AM -0800, Tony Lindgren wrote:
* Matt Porter mpor...@ti.com [130201 10:25]:
Move mach-davinci/dma.c to common/edma.c so it can be used
by OMAP (specifically AM33xx) as well.
I think this
Hello.
On 02-02-2013 14:18, Russell King - ARM Linux wrote:
On Fri, Feb 01, 2013 at 11:49:11PM +0300, Sergei Shtylyov wrote:
good point, do you wanna send some patches ?
I have already sent them countless times and even stuck CPPI 4.1
support (in
arch/arm/common/cppi41.c) in
On Sat, Feb 02, 2013 at 08:27:42PM +0400, Sergei Shtylyov wrote:
There are two people on this thread CC list who were also involved or
CC'd on the mails from the thread in 2010... Tony and Felipe.
Unfortunately, the person who agreed to do the work is no longer in the
land of the living. Yes
Hello.
On 02-02-2013 16:17, Russell King - ARM Linux wrote:
good point, do you wanna send some patches ?
I have already sent them countless times and even stuck CPPI 4.1
support (in
arch/arm/common/cppi41.c) in Russell's patch system. TI requested to
remove the
patch. :-(
Hello.
On 02-02-2013 20:45, Russell King - ARM Linux wrote:
There are two people on this thread CC list who were also involved or
CC'd on the mails from the thread in 2010... Tony and Felipe.
Unfortunately, the person who agreed to do the work is no longer in the
land of the living. Yes I
Hello.
On 02-02-2013 16:45, Russell King - ARM Linux wrote:
Now, CPPI is brand new code to arch/arm - always has been. It post-dates
the DMA engine API. And it's been said many times about moving it to
drivers/dma. The problem is Sergei doesn't want to do it - he's anti the
I *can't*
On Sat, Feb 02, 2013 at 12:01:37AM +, Sergei Shtylyov wrote:
Hello.
On 01-02-2013 22:59, Matt Porter wrote:
Move mach-davinci/dma.c to common/edma.c so it can be used
by OMAP (specifically AM33xx) as well.
I think this should rather go to drivers/dma/?
No, this is the private
Hello.
On 02-02-2013 22:07, Matt Porter wrote:
Move mach-davinci/dma.c to common/edma.c so it can be used
by OMAP (specifically AM33xx) as well.
I think this should rather go to drivers/dma/?
No, this is the private EDMA API. It's the analogous thing to
the private OMAP dma API that is in
On Sat, Feb 02, 2013 at 10:16:43AM -0800, Tony Lindgren wrote:
* Matt Porter mpor...@ti.com [130202 10:10]:
If it doesn't work, work with Vinod to fix the api. It's expected,
I'm working on dmaengine API changes right now to deal with a
limitation of EDMA that needs to be abstracted.
On Sat, Feb 02, 2013 at 07:06:06PM +, Sergei Shtylyov wrote:
Hello.
On 02-02-2013 22:07, Matt Porter wrote:
Move mach-davinci/dma.c to common/edma.c so it can be used
by OMAP (specifically AM33xx) as well.
I think this should rather go to drivers/dma/?
No, this is the private
Hello.
On 02-02-2013 23:55, Matt Porter wrote:
Move mach-davinci/dma.c to common/edma.c so it can be used
by OMAP (specifically AM33xx) as well.
I think this should rather go to drivers/dma/?
No, this is the private EDMA API. It's the analogous thing to
the private OMAP dma API that is in
* Matt Porter mpor...@ti.com [130202 11:51]:
On Sat, Feb 02, 2013 at 10:16:43AM -0800, Tony Lindgren wrote:
* Matt Porter mpor...@ti.com [130202 10:10]:
If it doesn't work, work with Vinod to fix the api. It's expected,
I'm working on dmaengine API changes right now to deal with a
Move mach-davinci/dma.c to common/edma.c so it can be used
by OMAP (specifically AM33xx) as well.
Signed-off-by: Matt Porter mpor...@ti.com
Acked-by: Sekhar Nori nsek...@ti.com
---
arch/arm/Kconfig |1 +
arch/arm/common/Kconfig|
* Matt Porter mpor...@ti.com [130201 10:25]:
Move mach-davinci/dma.c to common/edma.c so it can be used
by OMAP (specifically AM33xx) as well.
I think this should rather go to drivers/dma/?
Tony
--
Everyone hates slow
On Fri, Feb 01, 2013 at 06:41:08PM +, Tony Lindgren wrote:
* Matt Porter mpor...@ti.com [130201 10:25]:
Move mach-davinci/dma.c to common/edma.c so it can be used
by OMAP (specifically AM33xx) as well.
I think this should rather go to drivers/dma/?
No, this is the private EDMA API.
On Fri, Feb 01, 2013 at 07:52:46PM +, Sergei Shtylyov wrote:
Hello.
On 02/01/2013 09:49 PM, Matt Porter wrote:
Move mach-davinci/dma.c to common/edma.c so it can be used
by OMAP (specifically AM33xx) as well.
I think this should rather go to drivers/dma/?
No, this is the
Hello.
On 02/01/2013 09:49 PM, Matt Porter wrote:
Move mach-davinci/dma.c to common/edma.c so it can be used
by OMAP (specifically AM33xx) as well.
I think this should rather go to drivers/dma/?
No, this is the private EDMA API. It's the analogous thing to
the private OMAP dma API that is
Hello.
On 02/01/2013 09:58 PM, Felipe Balbi wrote:
Move mach-davinci/dma.c to common/edma.c so it can be used
by OMAP (specifically AM33xx) as well.
I think this should rather go to drivers/dma/?
No, this is the private EDMA API. It's the analogous thing to
the private OMAP dma API that
On Fri, Feb 01, 2013 at 10:56:00PM +0200, Felipe Balbi wrote:
hi,
On Fri, Feb 01, 2013 at 11:49:11PM +0300, Sergei Shtylyov wrote:
good point, do you wanna send some patches ?
I have already sent them countless times and even stuck CPPI 4.1 support
(in
arch/arm/common/cppi41.c)
Hello.
On 02-02-2013 0:56, Felipe Balbi wrote:
good point, do you wanna send some patches ?
I have already sent them countless times and even stuck CPPI 4.1 support
(in
arch/arm/common/cppi41.c) in Russell's patch system. TI requested to remove
the
patch. :-(
sticking into
Hello.
On 01-02-2013 22:59, Matt Porter wrote:
Move mach-davinci/dma.c to common/edma.c so it can be used
by OMAP (specifically AM33xx) as well.
I think this should rather go to drivers/dma/?
No, this is the private EDMA API. It's the analogous thing to
the private OMAP dma API that is in
Hello.
On 02-02-2013 1:30, Russell King - ARM Linux wrote:
On Fri, Feb 01, 2013 at 11:49:11PM +0300, Sergei Shtylyov wrote:
good point, do you wanna send some patches ?
I have already sent them countless times and even stuck CPPI 4.1
support (in
arch/arm/common/cppi41.c) in Russell's
Hello.
On 02-02-2013 1:30, Russell King - ARM Linux wrote:
On Fri, Feb 01, 2013 at 11:49:11PM +0300, Sergei Shtylyov wrote:
good point, do you wanna send some patches ?
I have already sent them countless times and even stuck CPPI 4.1
support (in
arch/arm/common/cppi41.c) in Russell's
On Sat, Feb 02, 2013 at 04:07:59AM +0400, Sergei Shtylyov wrote:
Hello.
On 02-02-2013 1:30, Russell King - ARM Linux wrote:
On Fri, Feb 01, 2013 at 11:49:11PM +0300, Sergei Shtylyov wrote:
good point, do you wanna send some patches ?
I have already sent them countless times and even
Hello.
On 02-02-2013 4:44, Russell King - ARM Linux wrote:
On Fri, Feb 01, 2013 at 11:49:11PM +0300, Sergei Shtylyov wrote:
good point, do you wanna send some patches ?
I have already sent them countless times and even stuck CPPI 4.1
support (in
arch/arm/common/cppi41.c) in Russell's
58 matches
Mail list logo