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, );
> >
> > of_address_to_resource() needs
> >
> > > + if (IS_ERR_VALUE(ret))
>
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
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
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, );
>
> of_address_to_resource() needs
>
> > + if (IS_ERR_VALUE(ret))
>
> This needs
More importantly, is this the correct way to check for
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
> Acked-by: Sekhar Nori
> diff --git
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 Tue, Feb 05, 2013 at 10:26:30PM +, Arnd Bergmann wrote:
> On Tuesday 05 February 2013, Tony Lindgren wrote:
> > * Felipe Balbi [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
On Tuesday 05 February 2013, Tony Lindgren wrote:
> * Felipe Balbi [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
On 02/05/2013 01:29 PM, Linus Walleij wrote:
On Tue, Feb 5, 2013 at 5:47 PM, 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
On Tue, Feb 5, 2013 at 6:14 PM, Russell King - ARM Linux
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 position 0.
>
>
On Tue, Feb 5, 2013 at 5:47 PM, 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 interrupts for
* Felipe Balbi [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 follow
On Tue, Feb 05, 2013 at 05:06:28PM +, Russell King - ARM Linux wrote:
> 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
On Tue, Feb 05, 2013 at 04:30:45PM +0100, Linus Walleij wrote:
> On Mon, Feb 4, 2013 at 10:54 PM, Cyril Chemparathy 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
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 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 interrupts for completion
of transfers. Anything that generates
On Mon, Feb 4, 2013 at 11:30 PM, Cyril Chemparathy 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 problem.
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 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 Mon, Feb 4, 2013 at 10:54 PM, Cyril Chemparathy 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 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?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
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
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?
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to
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 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 interrupts for completion
of transfers. Anything that generates interrupts
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
On Tue, Feb 05, 2013 at 05:06:28PM +, Russell King - ARM Linux wrote:
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
* 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 Tue, Feb 05, 2013 at 10:26:30PM +, Arnd Bergmann wrote:
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
On 02/04/2013 03:29 PM, Linus Walleij wrote:
On Mon, Feb 4, 2013 at 8:22 PM, Cyril Chemparathy 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
On 02/04/2013 04:11 PM, Linus Walleij wrote:
On Mon, Feb 4, 2013 at 9:33 PM, Mark Brown
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 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 Mon, Feb 4, 2013 at 9:33 PM, Mark Brown
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 wrote:
>
>> > Based on our experience with fitting multiple subsystems on top of this
>> > DMA-Engine driver, I must say that
On Mon, Feb 04, 2013 at 09:29:46PM +0100, Linus Walleij wrote:
> On Mon, Feb 4, 2013 at 8:22 PM, Cyril Chemparathy 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
On Mon, Feb 4, 2013 at 8:22 PM, Cyril Chemparathy 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 is that
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
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
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,
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 supported by the driver.
>
>
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
Hi,
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 assumptions about the fact that it's
> >
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.
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
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
> > > > starting point to also move inventra (and anybody else)
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
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
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
starting point to also move inventra (and anybody else) to dmaengine
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
Hi,
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 assumptions about the fact that it's
handling USB
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
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 supported by the driver.
Granted, CPPI
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 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
DMA-Engine driver, I must say that the DMA-Engine interface has proven
to be a less
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
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
* Matt Porter [130202 11:51]:
> On Sat, Feb 02, 2013 at 10:16:43AM -0800, Tony Lindgren wrote:
> > * Matt Porter [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
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
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/?
On Sat, Feb 02, 2013 at 10:16:43AM -0800, Tony Lindgren wrote:
> * Matt Porter [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.
>
>
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
* Matt Porter [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.
Regarding the DMA API limitations, I'm only aware of lack of capability
to
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/?
>
>
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*
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: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. :-(
sticking
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
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 12:49:06PM +, Russell King wrote:
> On Fri, Feb 01, 2013 at 10:41:08AM -0800, Tony Lindgren wrote:
> > * Matt Porter [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
On Fri, Feb 01, 2013 at 10:41:08AM -0800, Tony Lindgren wrote:
> * Matt Porter [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, there's
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
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:
> >>>
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
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. :-(
sticking
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
1 - 100 of 136 matches
Mail list logo
