Hi Radhey,
On 2018-05-30 20:29, Radhey Shyam Pandey wrote:
>> In couple of days I can update the metadata patches I have atm and send
>> as RFC.
>>
>> Is there anything from your side I should take into account when doing that?
> I think a generic interface to attach/share metadata buffer b/w
Hi Radhey,
On 2018-05-30 20:29, Radhey Shyam Pandey wrote:
>> In couple of days I can update the metadata patches I have atm and send
>> as RFC.
>>
>> Is there anything from your side I should take into account when doing that?
> I think a generic interface to attach/share metadata buffer b/w
el.org;
> dan.j.willi...@intel.com; Appana Durga Kedareswara Rao
> ; linux-arm-ker...@lists.infradead.org
> Subject: Re: [RFC 2/6] dmaengine: xilinx_dma: Pass AXI4-Stream control words
> to netdev dma client
>
> Hi,
>
> On 2018-05-17 09:39, Radhey Shyam Pandey wrote:
> >
el.org;
> dan.j.willi...@intel.com; Appana Durga Kedareswara Rao
> ; linux-arm-ker...@lists.infradead.org
> Subject: Re: [RFC 2/6] dmaengine: xilinx_dma: Pass AXI4-Stream control words
> to netdev dma client
>
> Hi,
>
> On 2018-05-17 09:39, Radhey Shyam Pandey wrote:
> >
Hi,
On 2018-05-17 09:39, Radhey Shyam Pandey wrote:
>> Well, let's see where this is going to go when I can send the patches
>> for review.
> Thanks all. @Peter: If we have metadata patchset ready may be good
> to send an RFC?
Sorry for the delay, I got distracted by this:
Hi,
On 2018-05-17 09:39, Radhey Shyam Pandey wrote:
>> Well, let's see where this is going to go when I can send the patches
>> for review.
> Thanks all. @Peter: If we have metadata patchset ready may be good
> to send an RFC?
Sorry for the delay, I got distracted by this:
ichal.si...@xilinx.com; linux-
> ker...@vger.kernel.org; dmaeng...@vger.kernel.org;
> dan.j.willi...@intel.com; Appana Durga Kedareswara Rao
> <appa...@xilinx.com>; linux-arm-ker...@lists.infradead.org
> Subject: Re: [RFC 2/6] dmaengine: xilinx_dma: Pass AXI4-Stream control words
>
el.org;
> dan.j.willi...@intel.com; Appana Durga Kedareswara Rao
> ; linux-arm-ker...@lists.infradead.org
> Subject: Re: [RFC 2/6] dmaengine: xilinx_dma: Pass AXI4-Stream control words
> to netdev dma client
>
> On 2018-04-24 06:55, Vinod Koul wrote:
> > On Thu, Apr 19, 2
On 2018-04-24 06:55, Vinod Koul wrote:
> On Thu, Apr 19, 2018 at 02:40:26PM +0300, Peter Ujfalusi wrote:
>>
>> On 2018-04-18 16:06, Lars-Peter Clausen wrote:
Hrm, true, but it is hardly the metadata use case. It is more like
different DMA transfer type.
>>>
>>> When I look at this with
On 2018-04-24 06:55, Vinod Koul wrote:
> On Thu, Apr 19, 2018 at 02:40:26PM +0300, Peter Ujfalusi wrote:
>>
>> On 2018-04-18 16:06, Lars-Peter Clausen wrote:
Hrm, true, but it is hardly the metadata use case. It is more like
different DMA transfer type.
>>>
>>> When I look at this with
On Thu, Apr 19, 2018 at 02:40:26PM +0300, Peter Ujfalusi wrote:
>
> On 2018-04-18 16:06, Lars-Peter Clausen wrote:
> >> Hrm, true, but it is hardly the metadata use case. It is more like
> >> different DMA transfer type.
> >
> > When I look at this with my astronaut architect view from high high
On Thu, Apr 19, 2018 at 02:40:26PM +0300, Peter Ujfalusi wrote:
>
> On 2018-04-18 16:06, Lars-Peter Clausen wrote:
> >> Hrm, true, but it is hardly the metadata use case. It is more like
> >> different DMA transfer type.
> >
> > When I look at this with my astronaut architect view from high high
On 2018-04-18 16:06, Lars-Peter Clausen wrote:
>> Hrm, true, but it is hardly the metadata use case. It is more like
>> different DMA transfer type.
>
> When I look at this with my astronaut architect view from high high up above
> I do not see a difference between metadata and multi-planar
On 2018-04-18 16:06, Lars-Peter Clausen wrote:
>> Hrm, true, but it is hardly the metadata use case. It is more like
>> different DMA transfer type.
>
> When I look at this with my astronaut architect view from high high up above
> I do not see a difference between metadata and multi-planar
On 04/18/2018 08:31 AM, Peter Ujfalusi wrote:
>
> On 2018-04-17 18:54, Lars-Peter Clausen wrote:
>> On 04/17/2018 04:53 PM, Peter Ujfalusi wrote:
>>> On 2018-04-17 16:58, Lars-Peter Clausen wrote:
>> There are two options.
>>
>> Either you extend the generic interfaces so it can cover
On 04/18/2018 08:31 AM, Peter Ujfalusi wrote:
>
> On 2018-04-17 18:54, Lars-Peter Clausen wrote:
>> On 04/17/2018 04:53 PM, Peter Ujfalusi wrote:
>>> On 2018-04-17 16:58, Lars-Peter Clausen wrote:
>> There are two options.
>>
>> Either you extend the generic interfaces so it can cover
On 2018-04-18 09:39, Peter Ujfalusi wrote:
>
>
> On 2018-04-17 18:42, Vinod Koul wrote:
>> On Tue, Apr 17, 2018 at 04:46:43PM +0300, Peter Ujfalusi wrote:
>>
>>> @@ -709,6 +709,11 @@ struct dma_filter {
>>> * be called after period_len bytes have been transferred.
>>> *
On 2018-04-18 09:39, Peter Ujfalusi wrote:
>
>
> On 2018-04-17 18:42, Vinod Koul wrote:
>> On Tue, Apr 17, 2018 at 04:46:43PM +0300, Peter Ujfalusi wrote:
>>
>>> @@ -709,6 +709,11 @@ struct dma_filter {
>>> * be called after period_len bytes have been transferred.
>>> *
On 2018-04-17 18:42, Vinod Koul wrote:
> On Tue, Apr 17, 2018 at 04:46:43PM +0300, Peter Ujfalusi wrote:
>
>> @@ -709,6 +709,11 @@ struct dma_filter {
>> * be called after period_len bytes have been transferred.
>> * @device_prep_interleaved_dma: Transfer expression in a generic way.
>>
On 2018-04-17 18:42, Vinod Koul wrote:
> On Tue, Apr 17, 2018 at 04:46:43PM +0300, Peter Ujfalusi wrote:
>
>> @@ -709,6 +709,11 @@ struct dma_filter {
>> * be called after period_len bytes have been transferred.
>> * @device_prep_interleaved_dma: Transfer expression in a generic way.
>>
On 2018-04-17 18:54, Lars-Peter Clausen wrote:
> On 04/17/2018 04:53 PM, Peter Ujfalusi wrote:
>> On 2018-04-17 16:58, Lars-Peter Clausen wrote:
> There are two options.
>
> Either you extend the generic interfaces so it can cover your usecase in a
> generic way. E.g. the ability
On 2018-04-17 18:54, Lars-Peter Clausen wrote:
> On 04/17/2018 04:53 PM, Peter Ujfalusi wrote:
>> On 2018-04-17 16:58, Lars-Peter Clausen wrote:
> There are two options.
>
> Either you extend the generic interfaces so it can cover your usecase in a
> generic way. E.g. the ability
On 04/17/2018 04:53 PM, Peter Ujfalusi wrote:
> On 2018-04-17 16:58, Lars-Peter Clausen wrote:
There are two options.
Either you extend the generic interfaces so it can cover your usecase in a
generic way. E.g. the ability to attach meta data to transfer.
>>>
>>> Fwiw I have
On 04/17/2018 04:53 PM, Peter Ujfalusi wrote:
> On 2018-04-17 16:58, Lars-Peter Clausen wrote:
There are two options.
Either you extend the generic interfaces so it can cover your usecase in a
generic way. E.g. the ability to attach meta data to transfer.
>>>
>>> Fwiw I have
On 04/17/2018 05:42 PM, Vinod Koul wrote:
> On Tue, Apr 17, 2018 at 04:46:43PM +0300, Peter Ujfalusi wrote:
>
>> @@ -709,6 +709,11 @@ struct dma_filter {
>> * be called after period_len bytes have been transferred.
>> * @device_prep_interleaved_dma: Transfer expression in a generic way.
>>
On 04/17/2018 05:42 PM, Vinod Koul wrote:
> On Tue, Apr 17, 2018 at 04:46:43PM +0300, Peter Ujfalusi wrote:
>
>> @@ -709,6 +709,11 @@ struct dma_filter {
>> * be called after period_len bytes have been transferred.
>> * @device_prep_interleaved_dma: Transfer expression in a generic way.
>>
On Tue, Apr 17, 2018 at 04:46:43PM +0300, Peter Ujfalusi wrote:
> @@ -709,6 +709,11 @@ struct dma_filter {
> * be called after period_len bytes have been transferred.
> * @device_prep_interleaved_dma: Transfer expression in a generic way.
> * @device_prep_dma_imm_data: DMA's 8 byte
On Tue, Apr 17, 2018 at 04:46:43PM +0300, Peter Ujfalusi wrote:
> @@ -709,6 +709,11 @@ struct dma_filter {
> * be called after period_len bytes have been transferred.
> * @device_prep_interleaved_dma: Transfer expression in a generic way.
> * @device_prep_dma_imm_data: DMA's 8 byte
On 2018-04-17 16:58, Lars-Peter Clausen wrote:
>>> There are two options.
>>>
>>> Either you extend the generic interfaces so it can cover your usecase in a
>>> generic way. E.g. the ability to attach meta data to transfer.
>>
>> Fwiw I have this patch as part of a bigger work to achieve similar
On 2018-04-17 16:58, Lars-Peter Clausen wrote:
>>> There are two options.
>>>
>>> Either you extend the generic interfaces so it can cover your usecase in a
>>> generic way. E.g. the ability to attach meta data to transfer.
>>
>> Fwiw I have this patch as part of a bigger work to achieve similar
gt;>>> <radh...@xilinx.com>; l...@metafoo.de; dmaeng...@vger.kernel.org;
>>>> linux-arm-ker...@lists.infradead.org; linux-kernel@vger.kernel.org
>>>> Subject: Re: [RFC 2/6] dmaengine: xilinx_dma: Pass AXI4-Stream control
>>>> words
.kernel.org;
>>>> linux-arm-ker...@lists.infradead.org; linux-kernel@vger.kernel.org
>>>> Subject: Re: [RFC 2/6] dmaengine: xilinx_dma: Pass AXI4-Stream control
>>>> words to netdev dma client
>>>>
>>>> On Mon, Apr 02, 2018 at
>>> linux-arm-ker...@lists.infradead.org; linux-kernel@vger.kernel.org
>>> Subject: Re: [RFC 2/6] dmaengine: xilinx_dma: Pass AXI4-Stream control
>>> words to netdev dma client
>>>
>>> On Mon, Apr 02, 2018 at 04:09:02PM +0530, Radhey Sh
t;> To: Radhey Shyam Pandey
>>> Cc: dan.j.willi...@intel.com; michal.si...@xilinx.com; Appana Durga
>>> Kedareswara Rao ; Radhey Shyam Pandey
>>> ; l...@metafoo.de; dmaeng...@vger.kernel.org;
>>> linux-arm-ker...@lists.infradead.org; linux-kernel@vger.kernel.o
illi...@intel.com; michal.si...@xilinx.com; Appana Durga
>> Kedareswara Rao <appa...@xilinx.com>; Radhey Shyam Pandey
>> <radh...@xilinx.com>; l...@metafoo.de; dmaeng...@vger.kernel.org;
>> linux-arm-ker...@lists.infradead.org; linux-kernel@vger.kernel.org
>> S
ichal.si...@xilinx.com; Appana Durga
>> Kedareswara Rao ; Radhey Shyam Pandey
>> ; l...@metafoo.de; dmaeng...@vger.kernel.org;
>> linux-arm-ker...@lists.infradead.org; linux-kernel@vger.kernel.org
>> Subject: Re: [RFC 2/6] dmaengine: xilinx_dma: Pass AXI4-Stream control
>> words t
appa...@xilinx.com>; Radhey Shyam Pandey
> <radh...@xilinx.com>; l...@metafoo.de; dmaeng...@vger.kernel.org;
> linux-arm-ker...@lists.infradead.org; linux-kernel@vger.kernel.org
> Subject: Re: [RFC 2/6] dmaengine: xilinx_dma: Pass AXI4-Stream control
> words to netdev dma clie
..@metafoo.de; dmaeng...@vger.kernel.org;
> linux-arm-ker...@lists.infradead.org; linux-kernel@vger.kernel.org
> Subject: Re: [RFC 2/6] dmaengine: xilinx_dma: Pass AXI4-Stream control
> words to netdev dma client
>
> On Mon, Apr 02, 2018 at 04:09:02PM +0530, Radhey Shyam Pandey wrot
On Mon, Apr 02, 2018 at 04:09:02PM +0530, Radhey Shyam Pandey wrote:
> +
> + if (chan->xdev->has_axieth_connected) {
> + seg = list_first_entry(>segments,
> + struct xilinx_axidma_tx_segment, node);
> + if
On Mon, Apr 02, 2018 at 04:09:02PM +0530, Radhey Shyam Pandey wrote:
> +
> + if (chan->xdev->has_axieth_connected) {
> + seg = list_first_entry(>segments,
> + struct xilinx_axidma_tx_segment, node);
> + if
40 matches
Mail list logo
