This is part of Intel VT-D and how to discover capabilities, base
addresses and so on in order to start taking advantage from it.
There is a lot to get from there, but currently we are interested only
by getting the remapping hardware base address. And more specifically
for interrupt remapping usage.
There might be more than one of such hardware so the exposed function is
made to retrieve all of them.
Signed-off-by: Tomasz Bursztyka <tomasz.bursztyka@linux.intel.com>
This will be used by MSI multi-vector implementation to connect the irq
and the vector prior to allocation.
Signed-off-by: Tomasz Bursztyka <tomasz.bursztyka@linux.intel.com>
This enables software MSI "multi-vector" feature, letting the user to
register an isr handler per-MSI message.
Signed-off-by: Tomasz Bursztyka <tomasz.bursztyka@linux.intel.com>
Though it was noted that pcie_get_cap() is only used by MSI code so far,
there is no need to put it in msi code. If unused, linker will nuke it.
So let's move things to where it belongs to.
Signed-off-by: Tomasz Bursztyka <tomasz.bursztyka@linux.intel.com>
Use of a printk that supports floating point changes the stack
requirements causing kernel.common.stack_protection_arm_fpu_sharing to
fail. The test doesn't need this capability so revert to nano
formatting.
Signed-off-by: Peter Bigot <peter.bigot@nordicsemi.no>
Add support for transmission modes that send a packet
at a specific time in the future.
Remove TXTIME, TXTIME_CCA, CSMA_CA capabilities and their calls when
they are not supported by selected drivers. Add TXTIME flag in
get_capabilites function.
Signed-off-by: Maciej Fabia <maciej.fabia@nordicsemi.no>
Signed-off-by: Pawel Kwiek <pawel.kwiek@nordicsemi.no>
Previously, when opening the Bluetooth driver on the app core of
nRF53, the application could hang forever. This would happen if
the network core was not flashed or flashed with the wrong firmware.
This commit improves the user experience timing out if the net core
is not replying. 3 seconds is considered to be more than enough to boot
the network core.
Signed-off-by: Rubin Gerritsen <rubin.gerritsen@nordicsemi.no>
These implemented a k_mem_pool in terms of the now universal k_heap
utility. That's no longer necessary now that the k_mem_pool API has
been removed.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
Use the core k_heap API pervasively within our tree instead of the
z_mem_pool wrapper that provided compatibility with the older mempool
implementation.
Almost all of this is straightforward swapping of one alloc/free call
for another. In a few cases where code was holding onto an old-style
"mem_block" a local compatibility struct with a single field has been
swapped in to keep the invasiveness of the changes down.
Note that not all the relevant changes in this patch have in-tree test
coverage, though I validated that it all builds.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
Remove test cases that exercise the deprecated mem_pool features of
the pipe utility.
Note that this leaves comparatively few cases left, we should probably
audit coverage after this merges and rewrite tests that aren't
interdependent.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
The mailbox and msgq utilities had API variants that could pass old
mem_pool blocks through the data structure. That API is being
deprected (and the features were obscure), so remove the internal
support.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
This tiny header uses non-builtin types but includes no headers that
would define them. Recent header motion seems to have exposed a case
where this file can get built before its dependencies are included.
Add the header directly.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
The sys_mem_pool data structure is going away. And this test case
didn't actually do much. All it did was create a sys_mem_pool in the
app data section (I guess that's the "mem_protect" part?) and validate
that it was usable. We have tests for sys_heap to do that already
elsewhere anyway; no point in porting.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
On userspace platforms, this test needs a little bit of kernel heap.
The old mem_pool number was specified without metadata overhead
(i.e. it reflected 128 bytes of actual data available and the metadata
was stored silently somewhere else), where the new heap specifies the
size of the contiguous buffer in memory that stores both data and
chunk headers, etc...
Increase to 256 bytes.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
This test was written to use a TINY system heap (64 bytes) from which
it has to allocate on behalf of a userspace process. The change in
convention from mem_pool (where the byte count now includes metadata
overhead) means it runs out of space. Bump to 192 bytes. Still tiny.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
These two test cases were making whitebox assumptions of both the
block header size and memory layout of an old-style k_mem_pool that
aren't honored by the k_heap allocator. They aren't testing anything
that isn't covered elsewhere.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
The kernel resource pool is now a k_heap. There is a compatibility
API still, but this is a core test that should be exercising the core
API.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
This code used a sys_mem_pool directly. Use a new-style heap instead
to do the same thing.
(Note that the usage is a little specious -- it allocates from the
heap but doesn't appear to fill or check any data therein, just that
the heap memory can be copied from the two memory domains. It's
unclear exactly what this is trying to demonstrate and we might want
to improve the sample to do something less trivial.)
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
Add an optimized realloc() implementation that can successfully expand
allocations in place if there exists enough free memory after the
supplied block.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
The k_mem_pool allocator is no more, and the z_mem_pool compatibility
API is going away. The internal allocator should be a k_heap always.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
These were implemented in terms of the mem_pool/block API directly
(for complicated reasons, the pointers returned from this API may have
been allocated from allocators other than the single system heap).
Have them use a k_heap instead.
Requires a tweak to one test which had hard-coded an assumption about
the header size.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
Mark all k_mem_pool APIs deprecated for future code. Remaining
internal usage now uses equivalent "z_mem_pool" symbols instead.
Fixes#24358
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
Remove the MEM_POOL_HEAP_BACKEND kconfig, treating it as true always.
Now the legacy mem_pool cannot be enabled and all usage uses the
k_heap/sys_heap backend.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
Defines partitions that can be used by mcuboot on nucleo_h743zi board.
Please note that mcuboot is not yet supported on stm32 h7 family as the
write-block-size is greater than 8.
Signed-off-by: Nicolas VINCENT <nicolas.vincent@vossloh.com>
Set rom offset to 0x400 if application is compiled with
CONFIG_BOOTLOADER_MCUBOOT.
Please note that mcuboot is not yet supported on stm32h7 devices
Signed-off-by: Nicolas VINCENT <nicolas.vincent@vossloh.com>
Fixes#29831: Implements flash driver for stm32h7 devices.
The driver is independant from the other stm32 families (flash_stm32.c),
only the header interface is (mainly) common.
Signed-off-by: Nicolas VINCENT <nicolas.vincent@vossloh.com>
Define write and erase block size for supported stm32h7 devices
Use a specific compatible string for stm32h7 devices for the flash
driver
Signed-off-by: Nicolas VINCENT <nicolas.vincent@vossloh.com>
This commit brings changes in nRF IEEE 802.15.4 radio driver's
handling of front-end modules.
Signed-off-by: Jedrzej Ciupis <jedrzej.ciupis@nordicsemi.no>
Do not include every single Kconfig file as part of this area, Kconfigs
in different areas are maintained by the repective component
maintainers.
Signed-off-by: Anas Nashif <anas.nashif@intel.com>
- Status is now orphaned.
- There has been a bit of activity in this area over the last
few months and I'm sure one or more of these new stake holders
would make a fine maintainer.
Signed-off-by: Michael Scott <mike@foundries.io>
