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
> >
> > > + 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 (specifical
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
>
> > + if (IS_ERR_VALUE(ret))
>
> This needs
More importantly, is this the correct way to check fo
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 a/arch/arm/mach-davinci/dma.
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 ce
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 N
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 let
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 in
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 interrupt
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.
Poll
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 c
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
e
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 ord
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-mmc" in
the body of a message to maj
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 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 drive
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
DMA
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 the
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 id
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 s
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, st
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 so
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
> > hand
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 w
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) t
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 r
* 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 th
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
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.
>
> Regarding
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
* 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 configure
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* do
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 kno
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 livin
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 Russell'
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 shoul
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 AM33xx
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 coun
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
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 t
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 pa
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 pa
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 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 arch/arm/co
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/com
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) in Russell's patch system. TI requested to remove
> the
> patch
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
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
Hi,
On Fri, Feb 01, 2013 at 10:52:46PM +0300, 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/?
>
>
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 AP
On Fri, Feb 01, 2013 at 06:41:08PM +, 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/?
No, this is the private EDMA API. It's the a
* 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/?
Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
the body of a message to majord...@vg
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
---
arch/arm/Kconfig |1 +
arch/arm/common/Kconfig|3 +
arch/arm/common/Makefi
68 matches
Mail list logo
