From: Vinod Koul <vkoul@kernel.org> To: Peter Ujfalusi <peter.ujfalusi@ti.com> Cc: robh+dt@kernel.org, nm@ti.com, ssantosh@kernel.org, dan.j.williams@intel.com, dmaengine@vger.kernel.org, linux-arm-kernel@lists.infradead.org, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, grygorii.strashko@ti.com, lokeshvutla@ti.com, t-kristo@ti.com, tony@atomide.com, j-keerthy@ti.com, vigneshr@ti.com Subject: Re: [PATCH v7 03/12] dmaengine: doc: Add sections for per descriptor metadata support Date: Fri, 20 Dec 2019 15:44:56 +0530 [thread overview] Message-ID: <20191220101456.GO2536@vkoul-mobl> (raw) In-Reply-To: <4508bc1c-d424-3285-cb47-d32a4d25b2c9@ti.com> On 20-12-19, 11:52, Peter Ujfalusi wrote: > Hi Vinod, > > On 20/12/2019 10.28, Vinod Koul wrote: > > Hi Peter, > > > > On 09-12-19, 11:43, Peter Ujfalusi wrote: > > > >> + Optional: per descriptor metadata > >> + --------------------------------- > >> + DMAengine provides two ways for metadata support. > >> + > >> + DESC_METADATA_CLIENT > >> + > >> + The metadata buffer is allocated/provided by the client driver and it is > >> + attached to the descriptor. > >> + > >> + .. code-block:: c > >> + > >> + int dmaengine_desc_attach_metadata(struct dma_async_tx_descriptor *desc, > >> + void *data, size_t len); > >> + > >> + DESC_METADATA_ENGINE > >> + > >> + The metadata buffer is allocated/managed by the DMA driver. The client > > > > and when would it be freed? > > It is not defined as it could be driver dependent, but afaik we have > defined (which I'm not sure why it is not here or in the code) that in > DESC_METADATA_ENGINE case the metadata pointer is valid for the client > between the time it got the desc (via prep call) and the execution of > the completion callback. > Iow, DESC_METADATA_ENGINE does not make any sense if the client want to > receive metadata back and does not provide a callback. Make sense and once callback completes driver can free it up! > > I will extend the documentation and comment in the code to reflect this. makes sense, thanks! > > >> + driver can ask for the pointer, maximum size and the currently used size of > >> + the metadata and can directly update or read it. > >> + > >> + .. code-block:: c > >> + > >> + void *dmaengine_desc_get_metadata_ptr(struct dma_async_tx_descriptor *desc, > >> + size_t *payload_len, size_t *max_len); > >> + > >> + int dmaengine_desc_set_metadata_len(struct dma_async_tx_descriptor *desc, > >> + size_t payload_len); > >> + > >> + Client drivers can query if a given mode is supported with: > >> + > >> + .. code-block:: c > >> + > >> + bool dmaengine_is_metadata_mode_supported(struct dma_chan *chan, > >> + enum dma_desc_metadata_mode mode); > >> + > >> + Depending on the used mode client drivers must follow different flow. > >> + > >> + DESC_METADATA_CLIENT > >> + > >> + - DMA_MEM_TO_DEV / DEV_MEM_TO_MEM: > >> + 1. prepare the descriptor (dmaengine_prep_*) > >> + construct the metadata in the client's buffer > >> + 2. use dmaengine_desc_attach_metadata() to attach the buffer to the > >> + descriptor > >> + 3. submit the transfer > > > > This is simpler, txn finished the metadata would be freed up right? > > It is up to the client driver what it does with the provided buffer. As > for what the DMA driver does is not documented as it is not relevant and > can be different by different HW or SW implementation. yeah lets document that and the fact the dmaengine driver cant touch it after the callback -- ~Vinod
WARNING: multiple messages have this Message-ID (diff)
From: Vinod Koul <vkoul@kernel.org> To: Peter Ujfalusi <peter.ujfalusi@ti.com> Cc: nm@ti.com, devicetree@vger.kernel.org, grygorii.strashko@ti.com, vigneshr@ti.com, lokeshvutla@ti.com, j-keerthy@ti.com, linux-kernel@vger.kernel.org, t-kristo@ti.com, tony@atomide.com, robh+dt@kernel.org, ssantosh@kernel.org, dmaengine@vger.kernel.org, dan.j.williams@intel.com, linux-arm-kernel@lists.infradead.org Subject: Re: [PATCH v7 03/12] dmaengine: doc: Add sections for per descriptor metadata support Date: Fri, 20 Dec 2019 15:44:56 +0530 [thread overview] Message-ID: <20191220101456.GO2536@vkoul-mobl> (raw) In-Reply-To: <4508bc1c-d424-3285-cb47-d32a4d25b2c9@ti.com> On 20-12-19, 11:52, Peter Ujfalusi wrote: > Hi Vinod, > > On 20/12/2019 10.28, Vinod Koul wrote: > > Hi Peter, > > > > On 09-12-19, 11:43, Peter Ujfalusi wrote: > > > >> + Optional: per descriptor metadata > >> + --------------------------------- > >> + DMAengine provides two ways for metadata support. > >> + > >> + DESC_METADATA_CLIENT > >> + > >> + The metadata buffer is allocated/provided by the client driver and it is > >> + attached to the descriptor. > >> + > >> + .. code-block:: c > >> + > >> + int dmaengine_desc_attach_metadata(struct dma_async_tx_descriptor *desc, > >> + void *data, size_t len); > >> + > >> + DESC_METADATA_ENGINE > >> + > >> + The metadata buffer is allocated/managed by the DMA driver. The client > > > > and when would it be freed? > > It is not defined as it could be driver dependent, but afaik we have > defined (which I'm not sure why it is not here or in the code) that in > DESC_METADATA_ENGINE case the metadata pointer is valid for the client > between the time it got the desc (via prep call) and the execution of > the completion callback. > Iow, DESC_METADATA_ENGINE does not make any sense if the client want to > receive metadata back and does not provide a callback. Make sense and once callback completes driver can free it up! > > I will extend the documentation and comment in the code to reflect this. makes sense, thanks! > > >> + driver can ask for the pointer, maximum size and the currently used size of > >> + the metadata and can directly update or read it. > >> + > >> + .. code-block:: c > >> + > >> + void *dmaengine_desc_get_metadata_ptr(struct dma_async_tx_descriptor *desc, > >> + size_t *payload_len, size_t *max_len); > >> + > >> + int dmaengine_desc_set_metadata_len(struct dma_async_tx_descriptor *desc, > >> + size_t payload_len); > >> + > >> + Client drivers can query if a given mode is supported with: > >> + > >> + .. code-block:: c > >> + > >> + bool dmaengine_is_metadata_mode_supported(struct dma_chan *chan, > >> + enum dma_desc_metadata_mode mode); > >> + > >> + Depending on the used mode client drivers must follow different flow. > >> + > >> + DESC_METADATA_CLIENT > >> + > >> + - DMA_MEM_TO_DEV / DEV_MEM_TO_MEM: > >> + 1. prepare the descriptor (dmaengine_prep_*) > >> + construct the metadata in the client's buffer > >> + 2. use dmaengine_desc_attach_metadata() to attach the buffer to the > >> + descriptor > >> + 3. submit the transfer > > > > This is simpler, txn finished the metadata would be freed up right? > > It is up to the client driver what it does with the provided buffer. As > for what the DMA driver does is not documented as it is not relevant and > can be different by different HW or SW implementation. yeah lets document that and the fact the dmaengine driver cant touch it after the callback -- ~Vinod _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2019-12-20 10:15 UTC|newest] Thread overview: 72+ messages / expand[flat|nested] mbox.gz Atom feed top 2019-12-09 9:43 [PATCH v7 00/12] dmaengine/soc: Add Texas Instruments UDMA support Peter Ujfalusi 2019-12-09 9:43 ` Peter Ujfalusi 2019-12-09 9:43 ` [PATCH v7 01/12] bindings: soc: ti: add documentation for k3 ringacc Peter Ujfalusi 2019-12-09 9:43 ` Peter Ujfalusi 2019-12-09 9:43 ` [PATCH v7 02/12] soc: ti: k3: add navss ringacc driver Peter Ujfalusi 2019-12-09 9:43 ` Peter Ujfalusi 2019-12-09 9:43 ` [PATCH v7 03/12] dmaengine: doc: Add sections for per descriptor metadata support Peter Ujfalusi 2019-12-09 9:43 ` Peter Ujfalusi 2019-12-20 8:28 ` Vinod Koul 2019-12-20 8:28 ` Vinod Koul 2019-12-20 9:52 ` Peter Ujfalusi 2019-12-20 9:52 ` Peter Ujfalusi 2019-12-20 10:14 ` Vinod Koul [this message] 2019-12-20 10:14 ` Vinod Koul 2019-12-09 9:43 ` [PATCH v7 04/12] dmaengine: Add metadata_ops for dma_async_tx_descriptor Peter Ujfalusi 2019-12-09 9:43 ` Peter Ujfalusi 2019-12-20 8:32 ` Vinod Koul 2019-12-20 8:32 ` Vinod Koul 2019-12-20 8:48 ` Peter Ujfalusi 2019-12-20 8:48 ` Peter Ujfalusi 2019-12-09 9:43 ` [PATCH v7 05/12] dmaengine: Add support for reporting DMA cached data amount Peter Ujfalusi 2019-12-09 9:43 ` Peter Ujfalusi 2019-12-20 8:37 ` Vinod Koul 2019-12-20 8:37 ` Vinod Koul 2019-12-20 8:49 ` Peter Ujfalusi 2019-12-20 8:49 ` Peter Ujfalusi 2019-12-20 9:57 ` Vinod Koul 2019-12-20 9:57 ` Vinod Koul 2019-12-20 10:13 ` Peter Ujfalusi 2019-12-20 10:13 ` Peter Ujfalusi 2019-12-09 9:43 ` [PATCH v7 06/12] dmaengine: ti: Add cppi5 header for K3 NAVSS/UDMA Peter Ujfalusi 2019-12-09 9:43 ` Peter Ujfalusi 2019-12-20 9:54 ` Vinod Koul 2019-12-20 9:54 ` Vinod Koul 2019-12-20 10:42 ` Peter Ujfalusi 2019-12-20 10:42 ` Peter Ujfalusi 2019-12-23 7:11 ` Peter Ujfalusi 2019-12-23 7:11 ` Peter Ujfalusi 2019-12-09 9:43 ` [PATCH v7 07/12] dmaengine: ti: k3 PSI-L remote endpoint configuration Peter Ujfalusi 2019-12-09 9:43 ` Peter Ujfalusi 2019-12-09 9:43 ` [PATCH v7 08/12] dt-bindings: dma: ti: Add document for K3 UDMA Peter Ujfalusi 2019-12-09 9:43 ` Peter Ujfalusi 2019-12-23 6:53 ` Vinod Koul 2019-12-23 6:53 ` Vinod Koul 2019-12-09 9:43 ` [PATCH v7 09/12] dmaengine: ti: New driver " Peter Ujfalusi 2019-12-09 9:43 ` Peter Ujfalusi 2019-12-23 7:34 ` Vinod Koul 2019-12-23 7:34 ` Vinod Koul 2019-12-23 8:59 ` Peter Ujfalusi 2019-12-23 8:59 ` Peter Ujfalusi 2019-12-23 11:26 ` Vinod Koul 2019-12-23 11:26 ` Vinod Koul 2019-12-09 9:43 ` [PATCH v7 10/12] dmaengine: ti: k3-udma: Add glue layer for non DMAengine users Peter Ujfalusi 2019-12-09 9:43 ` Peter Ujfalusi 2019-12-09 9:43 ` [PATCH v7 11/12] firmware: ti_sci: rm: Add support for tx_tdtype parameter for tx channel Peter Ujfalusi 2019-12-09 9:43 ` Peter Ujfalusi 2019-12-11 10:24 ` Tero Kristo 2019-12-11 10:24 ` Tero Kristo 2019-12-09 9:43 ` [PATCH v7 12/12] dmaengine: ti: k3-udma: Wait for peer teardown completion if supported Peter Ujfalusi 2019-12-09 9:43 ` Peter Ujfalusi 2019-12-11 10:43 ` [PATCH v7 00/12] dmaengine/soc: Add Texas Instruments UDMA support Keerthy 2019-12-11 10:43 ` Keerthy 2019-12-12 8:46 ` Peter Ujfalusi 2019-12-12 8:46 ` Peter Ujfalusi 2019-12-12 10:55 ` Tero Kristo 2019-12-12 10:55 ` Tero Kristo 2019-12-12 10:57 ` Tero Kristo 2019-12-12 10:57 ` Tero Kristo 2019-12-16 10:05 ` Peter Ujfalusi 2019-12-16 10:05 ` Peter Ujfalusi 2019-12-12 18:01 ` Grygorii Strashko 2019-12-12 18:01 ` Grygorii Strashko
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=20191220101456.GO2536@vkoul-mobl \ --to=vkoul@kernel.org \ --cc=dan.j.williams@intel.com \ --cc=devicetree@vger.kernel.org \ --cc=dmaengine@vger.kernel.org \ --cc=grygorii.strashko@ti.com \ --cc=j-keerthy@ti.com \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux-kernel@vger.kernel.org \ --cc=lokeshvutla@ti.com \ --cc=nm@ti.com \ --cc=peter.ujfalusi@ti.com \ --cc=robh+dt@kernel.org \ --cc=ssantosh@kernel.org \ --cc=t-kristo@ti.com \ --cc=tony@atomide.com \ --cc=vigneshr@ti.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: linkBe 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.