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>
This is the final step in making the `zephyr,memory-attr` property
actually useful.
The problem with the current implementation is that `zephyr,memory-attr`
is an enum type, this is making very difficult to use that to actually
describe the memory capabilities. The solution proposed in this PR is to
use the `zephyr,memory-attr` property as an OR-ed bitmask of memory
attributes.
With the change proposed in this PR it is possible in the DeviceTree to
mark the memory regions with a bitmask of attributes by using the
`zephyr,memory-attr` property. This property and the related memory
region can then be retrieved at run-time by leveraging a provided helper
library or the usual DT helpers.
The set of general attributes that can be specified in the property are
defined and explained in
`include/zephyr/dt-bindings/memory-attr/memory-attr.h` (the list can be
extended when needed).
For example, to mark a memory region in the DeviceTree as volatile,
non-cacheable, out-of-order:
mem: memory@10000000 {
compatible = "mmio-sram";
reg = <0x10000000 0x1000>;
zephyr,memory-attr = <( DT_MEM_VOLATILE |
DT_MEM_NON_CACHEABLE |
DT_MEM_OOO )>;
};
The `zephyr,memory-attr` property can also be used to set
architecture-specific custom attributes that can be interpreted at run
time. This is leveraged, among other things, to create MPU regions out
of DeviceTree defined memory regions on ARM, for example:
mem: memory@10000000 {
compatible = "mmio-sram";
reg = <0x10000000 0x1000>;
zephyr,memory-region = "NOCACHE_REGION";
zephyr,memory-attr = <( DT_ARM_MPU(ATTR_MPU_RAM_NOCACHE) )>;
};
See `include/zephyr/dt-bindings/memory-attr/memory-attr-mpu.h` to see
how an architecture can define its own special memory attributes (in
this case ARM MPU).
The property can also be used to set custom software-specific
attributes. For example we can think of marking a memory region as
available to be used for memory allocation (not yet implemented):
mem: memory@10000000 {
compatible = "mmio-sram";
reg = <0x10000000 0x1000>;
zephyr,memory-attr = <( DT_MEM_NON_CACHEABLE |
DT_MEM_SW_ALLOCATABLE )>;
};
Or maybe we can leverage the property to specify some alignment
requirements for the region:
mem: memory@10000000 {
compatible = "mmio-sram";
reg = <0x10000000 0x1000>;
zephyr,memory-attr = <( DT_MEM_CACHEABLE |
DT_MEM_SW_ALIGN(32) )>;
};
The conventional and recommended way to deal and manage with memory
regions marked with attributes is by using the provided `mem-attr`
helper library by enabling `CONFIG_MEM_ATTR` (or by using the usual DT
helpers).
When this option is enabled the list of memory regions and their
attributes are compiled in a user-accessible array and a set of
functions is made available that can be used to query, probe and act on
regions and attributes, see `include/zephyr/mem_mgmt/mem_attr.h`
Note that the `zephyr,memory-attr` property is only a descriptive
property of the capabilities of the associated memory region, but it
does not result in any actual setting for the memory to be set. The
user, code or subsystem willing to use this information to do some work
(for example creating an MPU region out of the property) must use either
the provided `mem-attr` library or the usual DeviceTree helpers to
perform the required work / setting.
Signed-off-by: Carlo Caione <ccaione@baylibre.com>
the sam xdmac driver does not yet implement the
get_status() function. with this commit the function
will be implemented. Fixes#62003
Signed-off-by: Sven Ginka <sven.ginka@gmail.com>
Only statements can be labeled in C, a declaration is not valid. This is
an FAQ.
While compilers currently in use don't seem to care, the "sparse" static
analyzer complains loudly (and cryptically):
https://github.com/thesofproject/sof/actions/runs/6052920348/job/16427323549
```
drivers/dma/dma_intel_adsp_hda.c:190:17: error: typename in expression
drivers/dma/dma_intel_adsp_hda.c:190:26: error: Expected ; at end of stmt
drivers/dma/dma_intel_adsp_hda.c:190:26: error: got rp
```
Add an empty ";" statement after each label makes `sparse` and probably
others happy.
Also add missing `const` to constants for clarity.
Fixes commit a026370461 ("drivers: hda: use interrupt for timing L1
exit on host DMA")
Signed-off-by: Marc Herbert <marc.herbert@intel.com>
To properly setup L1 exit timing this patch will use buffer interrupt
for HOST DMA and wait for Host HDA to actually start
First interrupt will clear all others.
Signed-off-by: Adrian Bonislawski <adrian.bonislawski@intel.com>
Signed-off-by: Kai Vehmanen <kai.vehmanen@linux.intel.com>
the dev pointer is already dereferenced before this function is
called, so this check does not make any sense.
Signed-off-by: Jacob Siverskog <jacob@teenage.engineering>
In case of HDA Link DMA FIFORDY bit is RO according
to HW specification thus should be managed by HDA controller.
Add a logic to set FIFORDY for HDA Host DMA only
Signed-off-by: Ievgen Ganakov <ievgen.ganakov@intel.com>
After boot the channel used for loading the basefw might be left enabled
by ROM.
Make sure that all channels are in stopped state to have consistency.
On TGL during Zephyr boot one channel is left running:
0:0x0x72800: Channel 0 of host out DMA (used for bassefw loading)
dgcs: 0x4800100,
dgbba 0x6000,
dgbs 32768,
dgbrp 8192,
dgbwp 8192,
dgbsp 0,
dgmbs 0,
dgbllpi 0x0,
dglpibi 0x0
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com>
On ACE a seperate, soc specific, interrupt mask needs to be enabled
to unmask the interrupt. Do so for GPDMA.
Signed-off-by: Tom Burdick <thomas.burdick@intel.com>
Refactor the ESP32 target SOCs together with
all related boards. Most braking changes includes:
- changing the CONFIG_SOC_ESP32* to refer to
the actual soc line (esp32,esp32s2,esp32s3,esp32c3)
- replacing CONFIG_SOC with the CONFIG_SOC_SERIES
- creating CONFIG_SOC_FAMILY_ESP32 to embrace all
the ESP32 across all used architectures
- introducing CONFIG_SOC_PART_NUMBER_* to
provide a SOC model config
- introducing the 'common' folder to hide all
commonly used configs and files.
- updating west.yml to reflect previous changes in hal
Signed-off-by: Marek Matej <marek.matej@espressif.com>
The NXP Pixel pipeline engine (PXP) is a 2D DMA engine capable of
accelerating display rotation, color space conversion, and limited
2D blending operations. This DMA driver only supports rotation of a
framebuffer, via a set of custom dma_slot values. Only DMA channel 0
is supported or utilized.
Signed-off-by: Daniel DeGrasse <daniel.degrasse@nxp.com>
Added a parameter inside the Channel Number macro since
the LPC55S36 expects an address rather than a static number.
Signed-off-by: Emilio Benavente <emilio.benavente@nxp.com>
The Broadcom pcie setup has a devicetree dependency like:
/pcie/paxdma -> /pcie/pcie -> /soc/pl330
Add a separate init symbol for iproc_pax_v2 so that these gets
initialized in order, fixes this error:
$ west build -p -b bcm958402m2_m7 tests/kernel/common \
-DCONFIG_CHECK_INIT_PRIORITIES=y
...
ERROR: /pcie/paxdma@4e100800 POST_KERNEL 40 < \
/pcie/pcie@4e100000 POST_KERNEL 50
Signed-off-by: Fabio Baltieri <fabiobaltieri@google.com>
Fix for bug:
https://github.com/zephyrproject-rtos/zephyr/issues/59802
The DMA controller only supports one transfer size, but
the Zephyr DMA driver api allows specifying a source_data_size
and dest_data_size which might be different. An old
version was always using dest_data_size for the transfer
size (variable is called "width"), but a recent change
made the driver use the MIN for the source and dest data
sizes. The MIN choice breaks the I2S driver because it
always set source_data_size to 1, but dest_data_size was
typically 4 for like two-channel 16-bit PCM data. So the
old driver worked using dest_data_size, but the new driver
broke I2S using MIN since source_data_size was 1.
To prevent confusion, change the DMA driver to assert that
source_data_size and dest_data_size are the same.
Also assert that the source_address and dest_address for
each block_config are properly aligned for the transfer size,
since that is a documentated requirement for the DMA controller.
Also rename max_xfer to max_xfer-bytes to be more clear what
the units are, and use this value in many places that
are comparing block_size in bytes rather than converting
block_size to words by dividing by width and
then comparing to NXP_LPC_DMA_MAX_XFER.
Signed-off-by: Mike J. Chen <mjchen@google.com>
Fixes a bug in intel_adsp_gpdma_release_ownership(). Before fix, this
function actually did nothing for ACE platform and the ownership was
not released. Now ownership is released to host CPU + DSP.
Signed-off-by: Serhiy Katsyuba <serhiy.katsyuba@intel.com>
Add a Kconfig to have the ability to fine tune the amount of RAM that
the driver uses based on the number of channels expected to be used.
Most of the code is already there but just need this Kconfig to get the
benefit of it by reducing the size of the statically created arrays.
Also change the number of channels field in the configuration to a byte
instead of a 32 bit integer because that should be sufficient to
describe the number of DMA channels.
Rename LPC DMA Driver Kconfigs with namespace to MCUX_LPC
Signed-off-by: Declan Snyder <declan.snyder@nxp.com>
remove the sdk based TOTAL_DMA_CHANNELS macro and instead just use the
zephyr driver's num_of_channels field
Signed-off-by: Declan Snyder <declan.snyder@nxp.com>
The block data length field should be in bytes. Setting this to a value
that is not a multiple of the data size results in a user setting error.
Running the ADC DMA test prior to this commit:
west build -p -b nucleo_u575zi_q zephyr/tests/drivers/adc/adc_dma
E: Transfer Error.
I: tc: 0, ht: 0, dte: 0, ule: 0, use: 1
E: DMA sampling complete, but DMA reported error -5
Existing tests using DMA on the nucleo_u575zi_q were not effected
because they only use a data size of one and continue to function
as expected:
west build -p -b nucleo_u575zi_q zephyr/tests/drivers/spi/spi_loopback \
-DOVERLAY_CONFIG="overlay-stm32-spi-dma.conf"
SUITE PASS - 100.00% [spi_loopback]: pass = 1, fail = 0, ...
west build -p -b nucleo_u575zi_q zephyr/tests/drivers/dma/loop_transfer
SUITE PASS - 100.00% [dma_m2m_loop]: pass = 3, fail = 0, ...
Signed-off-by: Brett Witherspoon <brett@witherspoon.engineering>
The tables for the dest and src data width constants were incorrectly
swapped. This commit uses the correct constants and renames the tables.
This change is only cosmetic for the stm32u5 since these constants are
the same but the existing names were probably inherited from another
driver where the p_*/m_* prefix was more appropriate.
Signed-off-by: Brett Witherspoon <brett@witherspoon.engineering>
Enable DMA error interrupts so that transfer errors are logged and
reported to the callback.
Signed-off-by: Brett Witherspoon <brett@witherspoon.engineering>
A "switch" statement in intel_adsp_hda_dma_status() seems to be
missing a "break". The second "break" is unneeded but seems to be a
part of the coding style.
Signed-off-by: Guennadi Liakhovetski <guennadi.liakhovetski@linux.intel.com>
Add specific init priority for the stm32 DMAMUX device higher
than the CONFIG_DMA_INIT_PRIORITY, to be sure that the DMAMUX
initialization always comes after the stm32 DMA device init.
Its default value is set to 41 when the DMA_INIT_PRIORITY is
KERNEL_INIT_PRIORITY_DEFAULT (=40).
Signed-off-by: Francois Ramu <francois.ramu@st.com>
