All of lore.kernel.org
 help / color / mirror / Atom feed
From: Peter Ujfalusi <peter.ujfalusi@ti.com>
To: Vinod Koul <vinod.koul@intel.com>
Cc: Lars-Peter Clausen <lars@metafoo.de>,
	Radhey Shyam Pandey <radheys@xilinx.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"michal.simek@xilinx.com" <michal.simek@xilinx.com>,
	"dmaengine@vger.kernel.org" <dmaengine@vger.kernel.org>,
	"dan.j.williams@intel.com" <dan.j.williams@intel.com>,
	Appana Durga Kedareswara Rao <appanad@xilinx.com>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>
Subject: [RFC,2/6] dmaengine: xilinx_dma: Pass AXI4-Stream control words to netdev dma client
Date: Wed, 18 Apr 2018 10:03:45 +0300	[thread overview]
Message-ID: <43634e42-a3fd-c189-ea2c-0d3b7e62fc46@ti.com> (raw)

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.
>>>   * @device_prep_interleaved_dma: Transfer expression in a generic way.
>>>   * @device_prep_dma_imm_data: DMA's 8 byte immediate data to the dst address
>>> + * @device_attach_metadata: Some DMA engines can send and receive side band
>>> + *	information, commands or parameters which is not transferred within the
>>> + *	data stream itself. In such case clients can set the metadata to the
>>> + *	given descriptor and it is going to be sent to the peripheral, or in
>>> + *	case of DEV_TO_MEM the provided buffer will receive the metadata.
>>>   * @device_config: Pushes a new configuration to a channel, return 0 or an error
>>>   *	code
>>>   * @device_pause: Pauses any transfer happening on a channel. Returns
>>> @@ -796,6 +801,9 @@ struct dma_device {
>>>  		struct dma_chan *chan, dma_addr_t dst, u64 data,
>>>  		unsigned long flags);
>>>  
>>> +	int (*device_attach_metadata)(struct dma_async_tx_descriptor *desc,
>>> +				      void *data, size_t len);
>>
>> while i am okay with the concept, I would not want to go again the custom
>> pointer route, this is a no-go for me.
>>
>> Instead lets add the vendor data, define that explicitly. We can use struct,
>> tokens or something else to define these. But lets try to stay away from
>> opaque objects please :-)
> 
> The DMA does not interpret the metadata, it is information which can be
> only understood by the client driver and the remote peripheral. It is
> just chunk of data (parameters, timestamps, keys, etc) that needs to
> travel along with the payload.
> 
> The content is not relevant for the DMA itself.

To add: different peripherals needs to send receive different metadata
and even the same peripheral might pass different information based on
their operating mode. The size of metadata can be different as well.

So it is not really vendor specific metadata, but peripheral, operating
mode and other factors affected chunk of data.

> 
> - Péter
> 
> Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
> Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
> 

- Péter

Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
---
To unsubscribe from this list: send the line "unsubscribe dmaengine" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

WARNING: multiple messages have this Message-ID (diff)
From: Peter Ujfalusi <peter.ujfalusi@ti.com>
To: Vinod Koul <vinod.koul@intel.com>
Cc: Lars-Peter Clausen <lars@metafoo.de>,
	Radhey Shyam Pandey <radheys@xilinx.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"michal.simek@xilinx.com" <michal.simek@xilinx.com>,
	"dmaengine@vger.kernel.org" <dmaengine@vger.kernel.org>,
	"dan.j.williams@intel.com" <dan.j.williams@intel.com>,
	Appana Durga Kedareswara Rao <appanad@xilinx.com>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>
Subject: Re: [RFC 2/6] dmaengine: xilinx_dma: Pass AXI4-Stream control words to netdev dma client
Date: Wed, 18 Apr 2018 10:03:45 +0300	[thread overview]
Message-ID: <43634e42-a3fd-c189-ea2c-0d3b7e62fc46@ti.com> (raw)
In-Reply-To: <994c184c-e915-7735-5a8b-81a02c5449b0@ti.com>



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.
>>>   * @device_prep_interleaved_dma: Transfer expression in a generic way.
>>>   * @device_prep_dma_imm_data: DMA's 8 byte immediate data to the dst address
>>> + * @device_attach_metadata: Some DMA engines can send and receive side band
>>> + *	information, commands or parameters which is not transferred within the
>>> + *	data stream itself. In such case clients can set the metadata to the
>>> + *	given descriptor and it is going to be sent to the peripheral, or in
>>> + *	case of DEV_TO_MEM the provided buffer will receive the metadata.
>>>   * @device_config: Pushes a new configuration to a channel, return 0 or an error
>>>   *	code
>>>   * @device_pause: Pauses any transfer happening on a channel. Returns
>>> @@ -796,6 +801,9 @@ struct dma_device {
>>>  		struct dma_chan *chan, dma_addr_t dst, u64 data,
>>>  		unsigned long flags);
>>>  
>>> +	int (*device_attach_metadata)(struct dma_async_tx_descriptor *desc,
>>> +				      void *data, size_t len);
>>
>> while i am okay with the concept, I would not want to go again the custom
>> pointer route, this is a no-go for me.
>>
>> Instead lets add the vendor data, define that explicitly. We can use struct,
>> tokens or something else to define these. But lets try to stay away from
>> opaque objects please :-)
> 
> The DMA does not interpret the metadata, it is information which can be
> only understood by the client driver and the remote peripheral. It is
> just chunk of data (parameters, timestamps, keys, etc) that needs to
> travel along with the payload.
> 
> The content is not relevant for the DMA itself.

To add: different peripherals needs to send receive different metadata
and even the same peripheral might pass different information based on
their operating mode. The size of metadata can be different as well.

So it is not really vendor specific metadata, but peripheral, operating
mode and other factors affected chunk of data.

> 
> - Péter
> 
> Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
> Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
> 

- Péter

Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki

WARNING: multiple messages have this Message-ID (diff)
From: peter.ujfalusi@ti.com (Peter Ujfalusi)
To: linux-arm-kernel@lists.infradead.org
Subject: [RFC 2/6] dmaengine: xilinx_dma: Pass AXI4-Stream control words to netdev dma client
Date: Wed, 18 Apr 2018 10:03:45 +0300	[thread overview]
Message-ID: <43634e42-a3fd-c189-ea2c-0d3b7e62fc46@ti.com> (raw)
In-Reply-To: <994c184c-e915-7735-5a8b-81a02c5449b0@ti.com>



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.
>>>   * @device_prep_interleaved_dma: Transfer expression in a generic way.
>>>   * @device_prep_dma_imm_data: DMA's 8 byte immediate data to the dst address
>>> + * @device_attach_metadata: Some DMA engines can send and receive side band
>>> + *	information, commands or parameters which is not transferred within the
>>> + *	data stream itself. In such case clients can set the metadata to the
>>> + *	given descriptor and it is going to be sent to the peripheral, or in
>>> + *	case of DEV_TO_MEM the provided buffer will receive the metadata.
>>>   * @device_config: Pushes a new configuration to a channel, return 0 or an error
>>>   *	code
>>>   * @device_pause: Pauses any transfer happening on a channel. Returns
>>> @@ -796,6 +801,9 @@ struct dma_device {
>>>  		struct dma_chan *chan, dma_addr_t dst, u64 data,
>>>  		unsigned long flags);
>>>  
>>> +	int (*device_attach_metadata)(struct dma_async_tx_descriptor *desc,
>>> +				      void *data, size_t len);
>>
>> while i am okay with the concept, I would not want to go again the custom
>> pointer route, this is a no-go for me.
>>
>> Instead lets add the vendor data, define that explicitly. We can use struct,
>> tokens or something else to define these. But lets try to stay away from
>> opaque objects please :-)
> 
> The DMA does not interpret the metadata, it is information which can be
> only understood by the client driver and the remote peripheral. It is
> just chunk of data (parameters, timestamps, keys, etc) that needs to
> travel along with the payload.
> 
> The content is not relevant for the DMA itself.

To add: different peripherals needs to send receive different metadata
and even the same peripheral might pass different information based on
their operating mode. The size of metadata can be different as well.

So it is not really vendor specific metadata, but peripheral, operating
mode and other factors affected chunk of data.

> 
> - P?ter
> 
> Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
> Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
> 

- P?ter

Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki

             reply	other threads:[~2018-04-18  7:03 UTC|newest]

Thread overview: 128+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-04-18  7:03 Peter Ujfalusi [this message]
2018-04-18  7:03 ` [RFC 2/6] dmaengine: xilinx_dma: Pass AXI4-Stream control words to netdev dma client Peter Ujfalusi
2018-04-18  7:03 ` Peter Ujfalusi
  -- strict thread matches above, loose matches on Subject: below --
2018-07-31  4:29 [RFC] dmaengine: Add metadat_ops for dma_async_tx_descriptor Vinod Koul
2018-07-31  4:29 ` Vinod
2018-07-31  4:29 ` Vinod
2018-07-30  9:46 Peter Ujfalusi
2018-07-30  9:46 ` Peter Ujfalusi
2018-07-30  9:46 ` Peter Ujfalusi
2018-07-24 11:14 Vinod Koul
2018-07-24 11:14 ` Vinod
2018-07-24 11:14 ` Vinod
2018-07-20 13:42 Peter Ujfalusi
2018-07-20 13:42 ` Peter Ujfalusi
2018-07-20 13:42 ` Peter Ujfalusi
2018-07-19  9:22 Vinod Koul
2018-07-19  9:22 ` Vinod
2018-07-19  9:22 ` Vinod
2018-07-18 10:06 Peter Ujfalusi
2018-07-18 10:06 ` Peter Ujfalusi
2018-07-18 10:06 ` Peter Ujfalusi
2018-07-10  5:52 Vinod Koul
2018-07-10  5:52 ` Vinod
2018-07-10  5:52 ` Vinod
2018-07-02  6:59 Radhey Shyam Pandey
2018-07-02  6:59 ` Radhey Shyam Pandey
2018-07-02  6:59 ` Radhey Shyam Pandey
2018-06-01 10:24 Peter Ujfalusi
2018-06-01 10:24 ` Peter Ujfalusi
2018-06-01 10:24 ` Peter Ujfalusi
2018-06-01 10:17 [RFC,2/6] dmaengine: xilinx_dma: Pass AXI4-Stream control words to netdev dma client Peter Ujfalusi
2018-06-01 10:17 ` [RFC 2/6] " Peter Ujfalusi
2018-06-01 10:17 ` Peter Ujfalusi
2018-05-30 17:29 [RFC,2/6] " Radhey Shyam Pandey
2018-05-30 17:29 ` [RFC 2/6] " Radhey Shyam Pandey
2018-05-30 17:29 ` Radhey Shyam Pandey
2018-05-29 15:04 [RFC,2/6] " Peter Ujfalusi
2018-05-29 15:04 ` [RFC 2/6] " Peter Ujfalusi
2018-05-29 15:04 ` Peter Ujfalusi
2018-05-17  6:39 [RFC,2/6] " Radhey Shyam Pandey
2018-05-17  6:39 ` [RFC 2/6] " Radhey Shyam Pandey
2018-05-17  6:39 ` Radhey Shyam Pandey
2018-04-24  9:50 [RFC,2/6] " Peter Ujfalusi
2018-04-24  9:50 ` [RFC 2/6] " Peter Ujfalusi
2018-04-24  9:50 ` Peter Ujfalusi
2018-04-24  3:55 [RFC,2/6] " Vinod Koul
2018-04-24  3:55 ` [RFC 2/6] " Vinod Koul
2018-04-24  3:55 ` Vinod Koul
2018-04-23  5:23 [RFC,4/6] dmaengine: xilinx_dma: Freeup active list based on descriptor completion bit Vinod Koul
2018-04-23  5:23 ` [RFC 4/6] " Vinod Koul
2018-04-23  5:23 ` Vinod Koul
2018-04-19 11:40 [RFC,2/6] dmaengine: xilinx_dma: Pass AXI4-Stream control words to netdev dma client Peter Ujfalusi
2018-04-19 11:40 ` [RFC 2/6] " Peter Ujfalusi
2018-04-19 11:40 ` Peter Ujfalusi
2018-04-18 13:06 [RFC,2/6] " Lars-Peter Clausen
2018-04-18 13:06 ` [RFC 2/6] " Lars-Peter Clausen
2018-04-18 13:06 ` Lars-Peter Clausen
2018-04-18  6:39 [RFC,2/6] " Peter Ujfalusi
2018-04-18  6:39 ` [RFC 2/6] " Peter Ujfalusi
2018-04-18  6:39 ` Peter Ujfalusi
2018-04-18  6:31 [RFC,2/6] " Peter Ujfalusi
2018-04-18  6:31 ` [RFC 2/6] " Peter Ujfalusi
2018-04-18  6:31 ` Peter Ujfalusi
2018-04-17 15:54 [RFC,2/6] " Lars-Peter Clausen
2018-04-17 15:54 ` [RFC 2/6] " Lars-Peter Clausen
2018-04-17 15:54 ` Lars-Peter Clausen
2018-04-17 15:44 [RFC,2/6] " Lars-Peter Clausen
2018-04-17 15:44 ` [RFC 2/6] " Lars-Peter Clausen
2018-04-17 15:44 ` Lars-Peter Clausen
2018-04-17 15:42 [RFC,2/6] " Vinod Koul
2018-04-17 15:42 ` [RFC 2/6] " Vinod Koul
2018-04-17 15:42 ` Vinod Koul
2018-04-17 14:53 [RFC,2/6] " Peter Ujfalusi
2018-04-17 14:53 ` [RFC 2/6] " Peter Ujfalusi
2018-04-17 14:53 ` Peter Ujfalusi
2018-04-17 13:58 [RFC,2/6] " Lars-Peter Clausen
2018-04-17 13:58 ` [RFC 2/6] " Lars-Peter Clausen
2018-04-17 13:58 ` Lars-Peter Clausen
2018-04-17 13:46 [RFC,2/6] " Peter Ujfalusi
2018-04-17 13:46 ` [RFC 2/6] " Peter Ujfalusi
2018-04-17 13:46 ` Peter Ujfalusi
2018-04-17 12:54 [RFC,2/6] " Lars-Peter Clausen
2018-04-17 12:54 ` [RFC 2/6] " Lars-Peter Clausen
2018-04-17 12:54 ` Lars-Peter Clausen
2018-04-17 12:48 [RFC,5/6] dmaengine: xilinx_dma: Program interrupt delay timeout Radhey Shyam Pandey
2018-04-17 12:48 ` [RFC 5/6] " Radhey Shyam Pandey
2018-04-17 12:48 ` Radhey Shyam Pandey
2018-04-17 12:28 [RFC,4/6] dmaengine: xilinx_dma: Freeup active list based on descriptor completion bit Radhey Shyam Pandey
2018-04-17 12:28 ` [RFC 4/6] " Radhey Shyam Pandey
2018-04-17 12:28 ` Radhey Shyam Pandey
2018-04-17 11:43 [RFC,2/6] dmaengine: xilinx_dma: Pass AXI4-Stream control words to netdev dma client Radhey Shyam Pandey
2018-04-17 11:43 ` [RFC 2/6] " Radhey Shyam Pandey
2018-04-17 11:43 ` Radhey Shyam Pandey
2018-04-17 10:54 [RFC,1/6] dt-bindings: dma: xilinx_dma: Add optional property has_axieth_connected Radhey Shyam Pandey
2018-04-17 10:54 ` [RFC 1/6] " Radhey Shyam Pandey
2018-04-17 10:54 ` Radhey Shyam Pandey
2018-04-11  9:11 [RFC,5/6] dmaengine: xilinx_dma: Program interrupt delay timeout Vinod Koul
2018-04-11  9:11 ` [RFC 5/6] " Vinod Koul
2018-04-11  9:11 ` Vinod Koul
2018-04-11  9:11 [RFC,4/6] dmaengine: xilinx_dma: Freeup active list based on descriptor completion bit Vinod Koul
2018-04-11  9:11 ` [RFC 4/6] " Vinod Koul
2018-04-11  9:11 ` Vinod Koul
2018-04-11  9:08 [RFC,2/6] dmaengine: xilinx_dma: Pass AXI4-Stream control words to netdev dma client Vinod Koul
2018-04-11  9:08 ` [RFC 2/6] " Vinod Koul
2018-04-11  9:08 ` Vinod Koul
2018-04-11  9:05 [RFC,1/6] dt-bindings: dma: xilinx_dma: Add optional property has_axieth_connected Vinod Koul
2018-04-11  9:05 ` [RFC 1/6] " Vinod Koul
2018-04-11  9:05 ` Vinod Koul
2018-04-02 10:39 [RFC,6/6] dmaengine: xilinx_dma: Use tasklet_hi_schedule for timing critical usecase Radhey Shyam Pandey
2018-04-02 10:39 ` [RFC 6/6] " Radhey Shyam Pandey
2018-04-02 10:39 ` Radhey Shyam Pandey
2018-04-02 10:39 [RFC,5/6] dmaengine: xilinx_dma: Program interrupt delay timeout Radhey Shyam Pandey
2018-04-02 10:39 ` [RFC 5/6] " Radhey Shyam Pandey
2018-04-02 10:39 ` Radhey Shyam Pandey
2018-04-02 10:39 [RFC,4/6] dmaengine: xilinx_dma: Freeup active list based on descriptor completion bit Radhey Shyam Pandey
2018-04-02 10:39 ` [RFC 4/6] " Radhey Shyam Pandey
2018-04-02 10:39 ` Radhey Shyam Pandey
2018-04-02 10:39 [RFC,3/6] dmaengine: xilinx_dma: Increase AXI DMA transaction segment count Radhey Shyam Pandey
2018-04-02 10:39 ` [RFC 3/6] " Radhey Shyam Pandey
2018-04-02 10:39 ` Radhey Shyam Pandey
2018-04-02 10:39 [RFC,2/6] dmaengine: xilinx_dma: Pass AXI4-Stream control words to netdev dma client Radhey Shyam Pandey
2018-04-02 10:39 ` [RFC 2/6] " Radhey Shyam Pandey
2018-04-02 10:39 ` Radhey Shyam Pandey
2018-04-02 10:39 [RFC,1/6] dt-bindings: dma: xilinx_dma: Add optional property has_axieth_connected Radhey Shyam Pandey
2018-04-02 10:39 ` [RFC 1/6] " Radhey Shyam Pandey
2018-04-02 10:39 ` Radhey Shyam Pandey
2018-04-02 10:39 [RFC 0/6] Xilinx DMA enhancements and optimization Radhey Shyam Pandey
2018-04-02 10:39 ` Radhey Shyam Pandey

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=43634e42-a3fd-c189-ea2c-0d3b7e62fc46@ti.com \
    --to=peter.ujfalusi@ti.com \
    --cc=appanad@xilinx.com \
    --cc=dan.j.williams@intel.com \
    --cc=dmaengine@vger.kernel.org \
    --cc=lars@metafoo.de \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=michal.simek@xilinx.com \
    --cc=radheys@xilinx.com \
    --cc=vinod.koul@intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.