On Thu, 25 Apr 2013, Linus Walleij wrote:
> On Thu, Apr 25, 2013 at 3:20 PM, Lee Jones wrote:
> > On Thu, 25 Apr 2013, Linus Walleij wrote:
>
> >> As we may want to support DEV_TO_DEV at some point.
> >>
> >> Then no longer, and that is not related to $SUBJECT.
> >
> > That's not why I'm
On Thu, 25 Apr 2013, Linus Walleij wrote:
On Thu, Apr 25, 2013 at 3:20 PM, Lee Jones lee.jo...@linaro.org wrote:
On Thu, 25 Apr 2013, Linus Walleij wrote:
As we may want to support DEV_TO_DEV at some point.
Then no longer, and that is not related to $SUBJECT.
That's not why I'm
On Thu, Apr 25, 2013 at 3:20 PM, Lee Jones wrote:
> On Thu, 25 Apr 2013, Linus Walleij wrote:
>> As we may want to support DEV_TO_DEV at some point.
>>
>> Then no longer, and that is not related to $SUBJECT.
>
> That's not why I'm removing it. The statement can never be true due to
> the fact
On Thu, Apr 25, 2013 at 3:09 PM, Russell King - ARM Linux
wrote:
> There's a problem with device to device transfers though - you have to
> consider the rate at which the devices produce and consume data, and
> whether they both can cope with differing data rates.
>
> Take for instance your
On Thu, 25 Apr 2013, Linus Walleij wrote:
> On Thu, Apr 25, 2013 at 11:06 AM, Lee Jones wrote:
>
> >> Are we now sacrificing that ability on the altar of simplification?
> >>
> >> I actually think not, but that we should do periph-to-periph transfers
> >> in some other way, and that the .dir
On Thu, Apr 25, 2013 at 02:43:16PM +0200, Linus Walleij wrote:
> So while there is no active usecase, Linux surely has the ambition to do
> that as can be seen in:
>
> /**
> * enum dma_transfer_direction - dma transfer mode and direction indicator
> * @DMA_MEM_TO_MEM: Async/Memcpy mode
> *
On Thu, Apr 25, 2013 at 11:06 AM, Lee Jones wrote:
>> Are we now sacrificing that ability on the altar of simplification?
>>
>> I actually think not, but that we should do periph-to-periph transfers
>> in some other way, and that the .dir attribute should go away from
>> the struct
> > Devices which utilise DMA tend to use the same channel numbers for
> > transmitting and receiving. For this reason and the fact that it'll
> > decrease the burden of platform data passed to each device, we're
> > amalgamating source and destination device types.
>
> I don't think this
On Thu, Apr 25, 2013 at 10:36 AM, Arnd Bergmann wrote:
> On Thursday 25 April 2013, Linus Walleij wrote:
>> Are we now sacrificing that ability on the altar of simplification?
>>
>> I actually think not, but that we should do periph-to-periph transfers
>> in some other way, and that the .dir
On Thursday 25 April 2013, Linus Walleij wrote:
> Are we now sacrificing that ability on the altar of simplification?
>
> I actually think not, but that we should do periph-to-periph transfers
> in some other way, and that the .dir attribute should go away from
> the struct stedma40_chan_cfg as
On Thu, Apr 18, 2013 at 12:11 PM, Lee Jones wrote:
> Devices which utilise DMA tend to use the same channel numbers for
> transmitting and receiving. For this reason and the fact that it'll
> decrease the burden of platform data passed to each device, we're
> amalgamating source and destination
On Thu, Apr 18, 2013 at 12:11 PM, Lee Jones lee.jo...@linaro.org wrote:
Devices which utilise DMA tend to use the same channel numbers for
transmitting and receiving. For this reason and the fact that it'll
decrease the burden of platform data passed to each device, we're
amalgamating source
On Thursday 25 April 2013, Linus Walleij wrote:
Are we now sacrificing that ability on the altar of simplification?
I actually think not, but that we should do periph-to-periph transfers
in some other way, and that the .dir attribute should go away from
the struct stedma40_chan_cfg as well
On Thu, Apr 25, 2013 at 10:36 AM, Arnd Bergmann a...@arndb.de wrote:
On Thursday 25 April 2013, Linus Walleij wrote:
Are we now sacrificing that ability on the altar of simplification?
I actually think not, but that we should do periph-to-periph transfers
in some other way, and that the .dir
Devices which utilise DMA tend to use the same channel numbers for
transmitting and receiving. For this reason and the fact that it'll
decrease the burden of platform data passed to each device, we're
amalgamating source and destination device types.
I don't think this explains what the
On Thu, Apr 25, 2013 at 11:06 AM, Lee Jones lee.jo...@linaro.org wrote:
Are we now sacrificing that ability on the altar of simplification?
I actually think not, but that we should do periph-to-periph transfers
in some other way, and that the .dir attribute should go away from
the struct
On Thu, Apr 25, 2013 at 02:43:16PM +0200, Linus Walleij wrote:
So while there is no active usecase, Linux surely has the ambition to do
that as can be seen in:
/**
* enum dma_transfer_direction - dma transfer mode and direction indicator
* @DMA_MEM_TO_MEM: Async/Memcpy mode
*
On Thu, 25 Apr 2013, Linus Walleij wrote:
On Thu, Apr 25, 2013 at 11:06 AM, Lee Jones lee.jo...@linaro.org wrote:
Are we now sacrificing that ability on the altar of simplification?
I actually think not, but that we should do periph-to-periph transfers
in some other way, and that the
On Thu, Apr 25, 2013 at 3:09 PM, Russell King - ARM Linux
li...@arm.linux.org.uk wrote:
There's a problem with device to device transfers though - you have to
consider the rate at which the devices produce and consume data, and
whether they both can cope with differing data rates.
Take for
On Thu, Apr 25, 2013 at 3:20 PM, Lee Jones lee.jo...@linaro.org wrote:
On Thu, 25 Apr 2013, Linus Walleij wrote:
As we may want to support DEV_TO_DEV at some point.
Then no longer, and that is not related to $SUBJECT.
That's not why I'm removing it. The statement can never be true due to
Devices which utilise DMA tend to use the same channel numbers for
transmitting and receiving. For this reason and the fact that it'll
decrease the burden of platform data passed to each device, we're
amalgamating source and destination device types.
Cc: Vinod Koul
Cc: Dan Williams
Cc: Per
Devices which utilise DMA tend to use the same channel numbers for
transmitting and receiving. For this reason and the fact that it'll
decrease the burden of platform data passed to each device, we're
amalgamating source and destination device types.
Cc: Vinod Koul vinod.k...@intel.com
Cc: Dan
22 matches
Mail list logo
