The LOG_* macros already print the module name and the function, printting
again the __func__ have no additional benefit.
The debug prints lack context which can be used to identify the channel
which the message was printed for.
For example:
<inf> dma_dw_common: dw_dma_stop: dw_dma_stop: dma 0 channel drain time out
when multiple channels from multiple controllers are used we don't know
the exact channel that has been stopped:
<inf> dma_dw_common: dw_dma_stop: dma@7c000: channel 0 drain time out
<inf> dma_dw_common: dw_dma_stop: dma@7d000: channel 0 drain time out
Convert all LOG prints to add usable context to them and use the following
pattern wherever it is possible:
dma_dw_common: <function name>: <DMA device name>: message
for example:
<inf> dma_dw_common: dw_dma_stop: dma@7c000: channel 0 config
The parameter list of dw_dma_avail_data_size() and dw_dma_free_data_size()
extended to pass the dev pointer.
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com>
A division by 0 has once been observed inside
intel_adsp_hda_dma_host_reload(). It is apparently caused by a
preceding logic or hardware error, but in any case values, read from
the hardware should be checked for 0 before being used as a divisor.
Signed-off-by: Guennadi Liakhovetski <guennadi.liakhovetski@linux.intel.com>
The point of this commit is to allow users to request specific
channels. The following code snippet shows how this may now be
achieved:
int requested_channel = 5;
int ret = dma_request_channel(dev, &requested_channel);
Signed-off-by: Laurentiu Mihalcea <laurentiu.mihalcea@nxp.com>
After #63289, multi-level interrupts are now encoded using
macro magic. This means that using the generic DT_INST_IRQ_BY_IDX()
to fetch the INTID is no longer an option as the queried INTID
will be the one specified through the node's `interrupts`
properties. To fix this, switch to using DT_INST_IRQN_BY_IDX()
which will return the correctly encoded INTID.
Signed-off-by: Laurentiu Mihalcea <laurentiu.mihalcea@nxp.com>
Currently, the number of channels supported by the controlled
is computed based on the size of the channel array. This
works well only if there's no gaps (i.e: "dma-channels" property
is used or "valid-channels" property is used with contiguous
channels) but will break if there are any gaps. For instance,
if the user wants to use channels 16 and 17 and specifies them
through the "valid-channels" property, they won't be allowed
to do so because dma_request_channels() will stop at channel 1.
As such, to fix this, simply use the number of channels from
the HAL configuration which is the maximum number of channels.
Signed-off-by: Laurentiu Mihalcea <laurentiu.mihalcea@nxp.com>
If the channel suspend with draining fails on stop because of reasons
outside of the scope of the DMA driver (the peripheral is powered off
before trying to drain for example) we must continue and disable the
channel.
The channel can be released by the client despite of it remained enabled.
A new DMA channel request can pick the channel (as it is released) but
re-configuration is going to be skipped and the use of the channel is going
to fail. Then we will see the same drain timeout on channel stop again
since the channel retained the configuration which resulted the first
timeout.
The drain timeout was made fatal by an earlier commit which fixed the
WAIT_FOR return value handling.
Fixes: 6226f9e6e4 ("dma: dw: fix the return value check")
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com>
Commit b2eaa6448076 ("drivers: dma: intel-adsp-hda: add delay to stop
host dma") added a wait on GBUSY state to host DMA stop.
This is problematic as in some case (like SOF chain-DMA usage),
the host DMA side RUN bit is not cleared when intel_adsp_hda_dma_stop()
is called. It is not possible to wait on GBUSY bit as there are
valid cases where it can remain set.
Address the original problem described in SOF bug #8686 and add a
polling check for intel_adsp_hda_is_enabled(). As per the bug
description, in some cases the GEN/FIFORDY bits are not cleared
immediately and if a new call to intel_adsp_hda_dma_stop() is made, the
PM refcounting will go haywire.
Link: https://github.com/thesofproject/sof/issues/8686
Signed-off-by: Kai Vehmanen <kai.vehmanen@linux.intel.com>
The STM32 DMA driver supports cyclic mode by setting source_reload_en
and dest_reload_en. This causes the dma_callback to be called twice per
buffer run-through, at half-time and when wrapping back to the start of
the buffer.
However, the current implementation only calls dma_callback twice. When
wrapping the first time, it sets stream->busy to false and ignores
subsequent interrupts.
With this change, the busy flag is only cleared in non-cyclic mode.
Signed-off-by: Marco Widmer <marco.widmer@bytesatwork.ch>
This commit introduces a driver for NXP's eDMA IP.
The main reasons for introducing a new driver are the following:
1) The HAL EDMA wrappers don't support well different
eDMA versions (e.g: i.MX93 and i.MX8QM). As such, a new
revision had to be introduced, thus requiring a new Zephyr
driver.
2) The eDMA versions found on i.MX93, i.MX8QM, and i.MX8QXP
don't use the DMAMUX IP (instead, channel MUX-ing is performed
through an eDMA register in the case of i.MX93).
Signed-off-by: Laurentiu Mihalcea <laurentiu.mihalcea@nxp.com>
According to hardware spec, host dma needs some delay to completely stop.
In the bug the host dma is disabled in different path in a few microseonds.
The first setting disabled the host dma and called pm_device_runtime_put
to power off it. The second setting found the host dma was still alive
and calle pm_device_runtime_put again. This results to pm->usage
checking failed.
BugLink: https://github.com/thesofproject/sof/issues/8686
Signed-off-by: Rander Wang <rander.wang@intel.com>
Update LPSS DMA init interface which is common and
independent of parent-node.
Signed-off-by: Anisetti Avinash Krishna <anisetti.avinash.krishna@intel.com>
Process dest_scatter_interval and source_gather_interval
configurations and accordingly set the source and destination
increment values.
Signed-off-by: Mahesh Mahadevan <mahesh.mahadevan@nxp.com>
The DMA interface allows start and stop to be called multiple
times and driver should ensure nothing bad happens if the calls
are not balanced.
Fix an issue where after a start-stop sequence the DMA would be
powered down, and then a subsequent stop would result in a crash
as driver accesses registers of a powered down hardware block.
Fix the issue by handling stop without actually reading the hw
registers to check channel status.
Link: https://github.com/thesofproject/sof/issues/8503
Signed-off-by: Kai Vehmanen <kai.vehmanen@linux.intel.com>
Use intA and intB fields of the DMA descriptor to decide when
the interrupt is per block versus when the transfer is complete.
This allows us to return the correct flag to the user.
Signed-off-by: Mahesh Mahadevan <mahesh.mahadevan@nxp.com>
Separating two new functions force and allow l1
to have the current state with separated functions
in the ipc file so that SOF can call these
functions via IPC DMI_FORCE_L1_EXIT. Change related
to the addition of a new parameter to force
DMI L1 exit on IPC request.
Signed-off-by: Fabiola Kwasowiec <fabiola.kwasowiec@intel.com>
The DMA channel data structure can retain config information.
We need to clear this everytime dma_configure is called on a
channel.
Signed-off-by: Mahesh Mahadevan <mahesh.mahadevan@nxp.com>
Add an emulated DMA driver. Emulation drivers are great to have
for each driver API for multiple reasons:
- providing an ideal / model driver for reference
- potential for configurable backend support
- seamless integration with device tree
- multi-instance, etc, for all supported boards
- fast regression testing of app and library code
Since many other drivers and lbraries depend on DMA, this might
help us to increase test coverage.
Signed-off-by: Christopher Friedt <cfriedt@meta.com>
The pm_policy_state_lock_put and pm_policy_state_lock_put functions
already become a no-op if CONFIG_PM is not enabled. Drop the guards
around it in few different drivers.
Signed-off-by: Fabio Baltieri <fabiobaltieri@google.com>
This commit introduces the SOF host DMA driver.
This driver is used by NXP platforms in the context of
SOF's host component to copy data from the host memory
to the firmware (local) memory. This is possible because
NXP platforms can access the host memory directly w/o
an actual DMA engine.
Signed-off-by: Laurentiu Mihalcea <laurentiu.mihalcea@nxp.com>
The existing S32K3 Kconfig options employ the `M7` suffix, which is
redundant given that all cores in this series utilize an Arm Cortex-M7
core. Therefore, we should remove it.
Signed-off-by: Manuel Argüelles <manuel.arguelles@nxp.com>
The LPC DMA IP offers hardware triggering via a series of SOC-specific
signals, often including sources like GPIO pins or hardware timers.
Support hardware triggers via the "dma_slot" field of the DMA
configuration structure. Currently support is offered for setting the
following:
- Trigger polarity
- Trigger level/edge mode
- burst mode
- burst length
- peripheral request
Signed-off-by: Daniel DeGrasse <daniel.degrasse@nxp.com>
Corrected comapare value of dma_is_enabled as it is compare with
wrong macro to check if channel is enabled or not.
Signed-off-by: Anisetti Avinash Krishna <anisetti.avinash.krishna@intel.com>
Enhance LPSS DMA to support UART and I2C DMA transfer by
enabling init priority of DMA based on dependency on
parent device.
Signed-off-by: Anisetti Avinash Krishna <anisetti.avinash.krishna@intel.com>
user dma config is not fully saved in dma_sedi_chan_config
function. When dma_sedi_start function it will check local
context, it will cause failure here.
Signed-off-by: Ning Yang <ning.yang@intel.com>
Move the syscall_handler.h header, used internally only to a dedicated
internal folder that should not be used outside of Zephyr.
Signed-off-by: Anas Nashif <anas.nashif@intel.com>
Disable power management for this particular test case as it expects a
particular pattern of pm get/puts that isn't matched by the driver and
usage in SoF.
Signed-off-by: Tom Burdick <thomas.burdick@intel.com>
If the channel was used for 16bit in the once, subsequent 32bit sample size
audio will be broken since the SCS bit remains set.
Example sequence with SOF:
normal audio playback with 16bit
ChainDMA audio playback with 16bit
normal audio playback with 16bit
The last playback results garbled audio.
Introduce intel_adsp_hda_set_sample_container_size() helper function
to handle the SCS bit and use it in the driver.
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com>
On S32K344, the offset in memory map between each channel
is 0x4000 for most channels, but there is specific case is
between channel 11 and 12 which is 0x1D4000 instead. As a
consequence, 32 channels are divided to two parts: one
starts from channel 0 -> 11. The other is from channel 128
to 145. The channel gap is from 12 -> 127.
For user and data structures in shim driver, the channel's
value comes from 0 --> 31. Above constraint will be counted
when interact with the mcux sdk
Beside that, the DMAMUX register in this platform is very
specific, not in identical with DMAMUX channel, so shim
driver is updated to cover this case
Signed-off-by: Dat Nguyen Duy <dat.nguyenduy@nxp.com>
Add new dt binding for edma v3 that inherits whole dt
properties from current version. One more property is
added for SoCs that don't have separate error interrupt
id, use same id with channel interrupt
Signed-off-by: Dat Nguyen Duy <dat.nguyenduy@nxp.com>
The current implementation iterates over all channels
even if only several channels share the same irq. This
introduces one more dt property to describe an offset
between two channels share the same interrupt id.
Beside that, the error interrupt must be put as last
element of "interrupt" dt property.
Signed-off-by: Dat Nguyen Duy <dat.nguyenduy@nxp.com>
The dma-channels devicetree value - 1 = maximum valid channel
The dma-requests devicetree value - 1 = maximum valid request
Signed-off-by: Dat Nguyen Duy <dat.nguyenduy@nxp.com>
Added usage of dma_parent phandle instead of using parent-child
method to get DMA base address.
Signed-off-by: Anisetti Avinash Krishna <anisetti.avinash.krishna@intel.com>
Introduce SMARTDMA dma driver. The SMARTDMA is a peripheral present on
some NXP SOCs, which implements a programmable DMA engine. The DMA
engine does not use channels, but rather provides a series of API
functions implemented by the firmware provided with MCUX SDK.
These API functions can be selected by the dma_config slot parameter. A
custom API is also provided to allow the user to install an alternate
firmware into the SMARTDMA.
Signed-off-by: Daniel DeGrasse <daniel.degrasse@nxp.com>
