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>
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>
Added an overlay file for the LPC55S36 to demonstrate
the DMA Support with the loop_transfer test.
Signed-off-by: Emilio Benavente <emilio.benavente@nxp.com>
Show an example of the LPC DMA Kconfig to reduce RAM based on the number
of DMA channels expected to be used. In this test, only one DMA channel
is needed, so we can show an example of how to reduce RAM usage of the
driver by configuring this value appropriately.
Signed-off-by: Declan Snyder <declan.snyder@nxp.com>
Configure the tests/drivers/dma/loop_transfer
and the tests/drivers/dma//chan_blen_transfer
to run on the stm32h573i_dk : use gpdma1 or gpdma2.
Signed-off-by: Francois Ramu <francois.ramu@st.com>
Change this test to use the automatically generated linker section
to place the buffer in SRAM4, instead of using the manually created
region added in 088d38f. This is in preperation of removing the
manually created section.
Signed-off-by: Hein Wessels <heinwessels93@gmail.com>
Add DMA unit tests for BDMA driver.
Also requires adding additional kconfig options to allocate
the memory buffers in a specific SRAM section, because
the BDMA only has access to SRAM4.
Signed-off-by: Hein Wessels <heinwessels93@gmail.com>
The Microchip XEC family of microcontrollers includes a
simple DMA block implementing multiple channels. DMA supports
memory to memory, memory to peripheral, and peripheral to
memory transfers. Peripheral support is limited by each
chip to I2C and SPI controllers. DMA hardware does not support
scatter-gather or linked transactions.
Signed-off-by: Jay Vasanth <jay.vasanth@microchip.com>
Add the testcase to run on the stm32u5x5 disco kit
and nucleo_u575zi_q boards.
The DMA instance is the GPDMA (up to 16 channels).
Signed-off-by: Francois Ramu <francois.ramu@st.com>
Convert test to use DEVICE_DT_GET via a nodelabel.
Introduce a test_dma devicetree nodelabel to reference the DMA
controller the test should use.
Signed-off-by: Kumar Gala <galak@kernel.org>
This adds the configuration to pass the testcases
dma/loop_transfer and the dma/chan_blen_transfer
on the nucleo_f103rb board.
Signed-off-by: Francois Ramu <francois.ramu@st.com>
This adds the configuration and set the DTS to pass
the dma/loop_transfer and the dma/chan_blen_transfer
on the nucleo_f429zi board.
The DMA2 instance supports mem2mem transfers.
Signed-off-by: Francois Ramu <francois.ramu@st.com>
This adds the configuration to pass testcases
dma/loop_transfer and the dma/chan_blen_transfer
on the nucleo_l152re board.
Signed-off-by: Francois Ramu <francois.ramu@st.com>
This adds the configuration to pass testscases
dma/loop_transfer and the dma/chan_blen_transfer
on the nucleo_f091rc board.
Signed-off-by: Francois Ramu <francois.ramu@st.com>
This commit sets the below configuration when
tests/drivers/dma/loop_transfer is executed on stm32f3_disco
platform.
CONFIG_DMA_LOOP_TRANSFER_DRV_NAME="DMA_1"
CONFIG_DMA_LOOP_TRANSFER_CHANNEL_NR=4
Signed-off-by: Krishna Mohan Dani <krishnamohan.d@hcl.com>
This commit configures DMA to run tests/drivers/dma/loop_transfer
test on nucleo_l552ze_q platform.
Signed-off-by: Krishna Mohan Dani <krishnamohan.d@hcl.com>
This commit configures the required DMA parameters to run
tests/drivers/dma/loop_transfer test on stm32l562e_dk platform.
This has been tested and is working as expected.
Signed-off-by: Krishna Mohan Dani <krishnamohan.d@hcl.com>
This patch enables the DMA chan_blen_transfer and loop_transfer tests on
the nucleo_f070rb board.
Signed-off-by: Simon Guinot <simon.guinot@seagate.com>
Enables dma test cases loop_transfer and chan_blen_transfer
on stm32g03116_disco, nucleo_g071rb and nucleo_g0b1re.
Signed-off-by: Thomas Stranger <thomas.stranger@outlook.com>
The dma test applications for MEM-to-MEM transfers are modified
to run on the stm32l476 with a DMA.
The CONFIG_DMA_LOOP_TRANSFER_DRV_NAME is either DMA_1 or DMA_2
CONFIG_DMA_LOOP_TRANSFER_CHANNEL_NR from 1 to 7 for DMA_1
CONFIG_DMA_LOOP_TRANSFER_CHANNEL_NR from 1 to 5 for DMA_2
Signed-off-by: Francois Ramu <francois.ramu@st.com>
The dma test applications for MEM-to-MEM transfers are modified
to run on the stm32wb55 with a DMAMUX
loop_transfer on any CONFIG_DMA_LOOP_TRANSFER_CHANNEL_NR from 0 to 13
chan_blen_trasnfer on CONFIG_DMA_TRANSFER_CHANNEL_NR_0 from 0 to 13
and on CONFIG_DMA_TRANSFER_CHANNEL_NR_1 from 0 to 13
Signed-off-by: Francois Ramu <francois.ramu@st.com>
