So far, it has been assumed that only level 2 interrupts can be shared
via the `CONFIG_SHARED_INTERRUPTS` option, but this is not true. In the
case of i.MX95, for instance, level 1 interrupt 143 is shared among EDMA
channels 30 and 31.
Due to the previous assumption, the irqsteer driver currently performs
reference counting for all level 2 interrupts aggregated by each
dispatcher and, of course, for the level 1 interrupts the dispatchers are
attached to. For instance, assuming a machine with 100 level 1 interrupts
and 1 irqsteer dispatcher attached to line 50 this would mean reference
counting is performed solely for line 50 (and the level 2 interrupts MUX'd
into this line).
Going back to i.MX95, since there's no dispatcher attached to IRQ line 143
that means there's no reference counting for it. In turn, this means that
the IRQ line can be disabled accidentally on a channel release() operation
while the other channel is active.
To protect against such cases, refactor the level1 interrupt reference
counting. Now, reference counting is performed for _all_ level 1
interrupts.
Additionally, simplify the locking logic. Ideally, there would be a lock
for each dispatcher protecting the level 2 interrupts and 1 global lock
protecting the level 1 interrupts. Instead of this approach (which is a
bit more complex), simply use a global lock for all interrupts. If finer
granularity is required then it can be added later on.
Signed-off-by: Laurentiu Mihalcea <laurentiu.mihalcea@nxp.com>
Add the "_raw" suffix to the macros handling the level 1 IRQ enable and
disable operation to signify that these operations perform no refcounting.
Additionally, shorten some portions of the name.
Signed-off-by: Laurentiu Mihalcea <laurentiu.mihalcea@nxp.com>
The driver no longer requires a backlight enable GPIO pin to be defined,
which allows compatibility with displays that do not provide such a pin.
Signed-off-by: Isaev Denis <anelderlyfox@yahoo.com>
Add support for controls of menu types, standard menu and drivers'
defined menu.
Rework the ov5640's test pattern and power line frequency controls using
this new support.
Signed-off-by: Phi Bang Nguyen <phibang.nguyen@nxp.com>
For controls that are dependent from others, we need to "cluster" them.
Whenever one or more controls of the same cluster are set or gotten,
only the callback of the 1st control of the cluster, i.e. the master
control, is called. The master control is the one that represents the
whole cluster.
A common type of control cluster is "auto"-cluster, e.g. auto_gain/gain,
auto_exposure/exposure, auto_white_balance/red_balance/blue_balance,
etc. If the cluster is in automatic mode, then the manual controls are
marked inactive and volatile which are read via get_volatile_ctrl().
If the cluster is put in manual mode, then the manual controls should
become active again and the volatile flag is cleared.
Re-implement the ov5640's autogain/analogue_gain controls with the new
auto cluster mechanism so that it work correctly and fully.
Signed-off-by: Phi Bang Nguyen <phibang.nguyen@nxp.com>
Add get_volatile_ctrl() driver's API to retrieve the current value of a
control marked as volatile, e.g. gain, exposure. This function triggers
a hardware register reading instead of returning a cached value to ensure
that users always get a fresh value which is constantly updated by the HW.
Note that the driver is responsible for marking a control as volatile by
setting VIDEO_CTRL_FLAG_VOLATILE when registering a control because not
all hardwares work the same way for the same control.
Signed-off-by: Phi Bang Nguyen <phibang.nguyen@nxp.com>
Application can query information about a control given the control id,
the framework fill the rest of the structure. Application can also
enumerate all kinds of device's supported controls by iterating with
VIDEO_CTRL_FLAG_NEXT_CTRL on the same API.
Signed-off-by: Phi Bang Nguyen <phibang.nguyen@nxp.com>
Implement the video control framework with the following features:
- Drivers initialize the control with a valid value range at boot which
guides the application developer and the framework. Hence, the video
framework could do all common works for drivers e.g., sanity check.
- Controls need to be cached to memory. Video framework handles
get_ctrl(), drivers don't need to implement this API. It is because
reading control value directly from registers are not only inefficient
but also sometimes impossible, e.g. controls that scatter through
several registers. Only "volatile" control needs to be updated at
runtime.
- Only the devices (e.g., sensors) owning the controls need to
implement set_ctrl(). Other devices of the pipeline do not need to
propagate set_ctrl() and hence, do not need to implement this API
Signed-off-by: Phi Bang Nguyen <phibang.nguyen@nxp.com>
Introduce a new video device structure representing a device in a
video pipeline. Each video device embeds a pointer to its "source"
device and other "video" characteristics.
This structure give the video framework an access to all video features
of the device and a hierachical view of the video pipeline that the
device belongs to.
Signed-off-by: Phi Bang Nguyen <phibang.nguyen@nxp.com>
The local device shall only set the MITM protection required flag if
the local device itself requires MITM protection.
Only set MITM flag when the required security level is more than 2 and
pairing method is not `JUST_WORKS`.
Signed-off-by: Lyle Zhu <lyle.zhu@nxp.com>
PMCI conveys a stack of specifications from DMTF including MCTP (a
transport layer protocol), PLDM (request/response messaging protocol),
and ancillary SPDM messaging. Placing all these libraries under PMCI
subsystem makes more sense than simply adding MCTP as its own subsystem.
Signed-off-by: Tom Burdick <thomas.burdick@intel.com>
Also trigger the bluetooth tests if tests/bluetooth/common/testlib/
is changed.
Signed-off-by: Alberto Escolar Piedras <alberto.escolar.piedras@nordicsemi.no>
The `nocache` is not loadable, thus data stored therein cannot be
initialized by the startup code. This might be needed in special
cases. E.g. One might have a buffer which one wants to DMA into,
and which is a member of a struct. Other members of the struct one
may want to have initialized by the startup code.
The buffer thus should be placed in the `nocache` region, but for
the other members of the buffer to be initialized by the startup
code, the `nocache` region needs to be loadable.
Fix it by making the `nocache` region loadable. Adding a KConfig
symbol to do this optionally was considered, but deemed unnecessary
during the PR.
Signed-off-by: Julian Achatzi <mail@achatzi.pro>
The logic of clock initialization for i2c fast mode (FM) and fast
mode plus (FMP) is as follows:
1 compute how many system clock cycles for SCL to be low
2 compute how many system clock cycles for SCL to be high by
subtracting the low duration computed above from the SCL period
3 verify the high duration computed in 2 is larger than a minimum
The bug is that the step 3 for the FMP is compared with the
minimum value for FM, and causes it to fail.
The fix corrects the bug.
Signed-off-by: Hu Dou <hugh.dou@gmail.com>
Two issues:
- is_condition_met() was missing proper code for The
K_POLL_TYPE_PIPE_DATA_AVAILABLE case
- z_handle_obj_poll_events() was misplaced in z_impl_k_pipe_write()
Note: I added support for the deprecated pipe implementation to
is_condition_met() but that is untested.
Signed-off-by: Nicolas Pitre <npitre@baylibre.com>
Intel Audio DSP ACE needs to use arch_spin_relax() to give
the bus more time to propagate the RCW transactions among
CPUs, and to avoid sending too many requests to the bus
after failing to lock spinlocks. However, the number of
NOPs results in a very big arch_spin_relax() that spans
multiple instruction cache lines, and requires evicting
them just for NOPs. With 5 CPUs, it can span 6 cache
lines (if using nop.n instead of nop). That's a waste of
space and cache. So instead, we do a tight loop instead.
Since the SoC supports zero-overhead loops, this should
have minimal performance impact.
Signed-off-by: Daniel Leung <daniel.leung@intel.com>
For some weird unknown reasons, the simulator really do not
like the cpuhold_* variables to be tightly packed together.
This results in cpuhold_spawned not being updated, and we
will be stuck in the while loop for it to be set.
Workaround this by explicitly aligning these variables on
16 byte boundary. This seems to work for now.
Signed-off-by: Daniel Leung <daniel.leung@intel.com>
Update power state selection. Previously, it was iterating over states
starting from the last one so the most common short sleep periods were
taking the longest time to select. Order is now swapped so that short
sleeps will get power state as quick as possible.
Signed-off-by: Krzysztof Chruściński <krzysztof.chruscinski@nordicsemi.no>
When all states are locked or latency requirement cannot be met
by any power state it is important to be able to quickly exit
suspend procedure because that usually means that application
requires high performance. Add function for detecting if any
power state is available.
Additionally, add function pm_policy_state_is_available for
checking if given state is available which means that it is not
locked and fulfills current latency requirement.
Signed-off-by: Krzysztof Chruściński <krzysztof.chruscinski@nordicsemi.no>
Update the HW models module to:
d5b95fdd0260e8189e788d40d2863d1e2d4be159
Including the following:
d5b95fd grtc hal replacement: Fix bug in nrf_grtc_int_group_enable/
disable()
5f3641d GRTC: With a CC in the past evaluate immediately
Signed-off-by: Alberto Escolar Piedras <alberto.escolar.piedras@nordicsemi.no>
- Remove duplicated conf/.overlay configuration for
mimmxrt1170_evk A and B revisions that have the same content.
- No change if .conf/.overlay have different content.
Signed-off-by: Andrej Butok <andrey.butok@nxp.com>
Provide proper adaptions as bootloader ROM offset, flash load
offset and dts definitions for the nRF54H20 iron board to make it
ready for the MCUBoot bootloader.
Signed-off-by: Michal Kozikowski <michal.kozikowski@nordicsemi.no>
In the default configuration, cv32a6 does not have an FPU and does not
implement RISC-V's F and D extensions.
Hence, the FPU flags should not be added.
In the future, a second SoC for cv32a6 systems with FPU can be added.
Signed-off-by: Eric Ackermann <eric.ackermann@cispa.de>
The nullpointer address (0x0) is mapped to the debug module in cva6,
making it a valid address.
Thus, in the coredump test, trigger an exception using k_panic()
instead.
Signed-off-by: Eric Ackermann <eric.ackermann@cispa.de>
The original commit uses the incorrect value 42 for
CONFIG_MAX_IRQ_PER_AGGREGATOR for the cva6 family of SoCs,
which is the total number of IRQs in the system.
This commit corrects this to 30, the number of IRQs for the PLIC.
Signed-off-by: Eric Ackermann <eric.ackermann@cispa.de>
This commit adds the necessary configurations for building and testing
cva6 boards (cv64a6_genesys_2, cv32a6_genesys_2) with twister.
This has been validated against commit
8a9d7a832b7121dd6f9be61a380d1d89ebf2a5f3 of the cva6 hardware project.
Signed-off-by: Eric Ackermann <eric.ackermann@cispa.de>
In hardware, cva6 currently only provides global disable/enable
functions for the Dcache and Icache. Disabling and re-enabling them also
has the effect of flushing and invalidating the cache.
Future cva6 SoCs will add support RISC-V's standardized cache management
operations.
This commit provides a default implementation for all methods currently
part of the cache API. These implementations can be overwritten at board
or SoC level, as they use weak linking.
Signed-off-by: Eric Ackermann <eric.ackermann@cispa.de>
The device tree entry for cva6 is currently missing a device tree node
for the mtime and mtimecmp registers in the core-local interrupt
controllers.
This causes the RISC-V machine timer driver not to be built, causing
build failures as the system clock is missing.
This commit rectifies this by adding the corresponding device tree
entry.
Signed-off-by: Eric Ackermann <eric.ackermann@cispa.de>
