drivers: dma_mcux_lpc: Add host directions, integrate DMA driver context, implement dma_mcux_lpc_get_attribute #85742
Conversation
zephyrbot
added
platform: NXP Drivers
zephyrbot
requested review from
dbaluta,
decsny,
dleach02,
manuargue,
mmahadevan108,
Raymond0225 and
teburd
VitekST
force-pushed
the
bugfix/dma-mcux-lpc-compliant-context
branch
3 times, most recently
from
9e151f2 to
ebdbbc2
Compare
| @@ -825,11 +829,36 @@ static int dma_mcux_lpc_get_status(const struct device *dev, uint32_t channel, | |||
| return 0; | |||
| } | |||
|
|
|||
| static int dma_mcux_lpc_get_attribute(const struct device *dev, uint32_t type, uint32_t *value) | |||
There was a problem hiding this comment.
I don't think we need implement this API. As it is introduced for special HW:
"DMA API get attribute function added, added attributes for scatter/gather blocks available to Intel HDA and Intel GPDMA drivers"
Even we implement it, why these values are 4, not 1 ?
There was a problem hiding this comment.
@Raymond0225 That may be a commit message initially introducing this API, perhaps in a similar fashion like I extended the codec API to support features, at the moment, only utilised by the wm8904 driver (4b3fae8), but the documentation doesn't say anything about the API being specific to a particular piece of hardware (https://docs.zephyrproject.org/apidoc/latest/group__dma__interface.html#ga641f3fa492bfb17cf9f0a0361d429257). And why would it? My view is that it's a generic API for retrieving a selected set of attributes specific for each DMA controller/platform on which it is instantiated.
The change came into existence because SOF uses that API (specifically - host-zephyr.c). I made an attempt to get SOF to work on the RT685's DSP domain. While fully functional SOF on that target is somewhat of a distant goal, this function is groundwork for making SOF run.
About the values - I think it's best to keep data transferred being domains aligned to 4 byte boundaries because of data caches of the two domains. While I haven't touched on that topic, invalidation would be easier.
There was a problem hiding this comment.
@Raymond0225 So... any other arguments?
There was a problem hiding this comment.
@Raymond0225 Would like to gently nudge this.
VitekST
force-pushed
the
bugfix/dma-mcux-lpc-compliant-context
branch
from
ebdbbc2 to
bb1ec56
Compare
Add support for HOST_TO_MEMORY, MEMORY_TO_HOST directions (aliases of MEMORY_TO_MEMORY). Implement dma_mcux_lpc_get_attribute function. Fix missing DMA driver context. Signed-off-by: Vit Stanicek <[email protected]>
VitekST
force-pushed
the
bugfix/dma-mcux-lpc-compliant-context
branch
from
bb1ec56 to
8b241f3
Compare
|
This pull request has been marked as stale because it has been open (more than) 60 days with no activity. Remove the stale label or add a comment saying that you would like to have the label removed otherwise this pull request will automatically be closed in 14 days. Note, that you can always re-open a closed pull request at any time. |
|
Well... this PR is stale, but still relevant, at least to me. |
The
dma_mcux_lpcdriver doesn't integrate a valid Zephyr DMA driver context, implying undefined behaviour of some of the Zephyr's DMA functions that wrap around the DMA API and expect a valid context to be present (such asz_impl_dma_request_channelandz_impl_dma_release_channel). While not detrimental to the DMA functionality itself, some applications (such as SOF) are written against those wrapper functions, making the driver unusable.SOF also expects DMA drivers to support
HOST_TO_MEMORYandMEMORY_TO_HOSTdirections for transfers between domains. As domains on devices where this driver runs are closely intertwined (at the very least they share memory), I don't think that aliasing them toMEMORY_TO_MEMORYshould imply any sticky situations. Use case of this is on the i.MX RT685....thus add support for
HOST_TO_MEMORY,MEMORY_TO_HOSTdirections (aliases ofMEMORY_TO_MEMORY), implementdma_mcux_lpc_get_attributefunction and fix missing DMA driver context.Somewhat related to #77814, marking it as a prerequisite.