The I2C shell allows a user to input "i2c scan i2c0" for instance, to
scan addresses on the i2c0 bus enabled in DT. This currently causes
an infinite loop when CONFIG_I2C_MAX32_INTERRUPT is enabled.
The infinite loops happens because 0-length transactions
(tx_len == rx_len == 0) not being handled both by the Async
i2c_max32_transfer and by the controller ISR.
This commit makes two changes:
1) [ISR] When an address ACK is received, if there is simply no data to
send or receive, then just give up the semaphore, preventing the
i2c_max32_transfer function from waiting infinitely.
2) [i2c_max32_transfer] After getting the semaphore back, if there is no
data to send or receive, then avoid waiting for the BUSY flag to clear
since clock stretching should not occur by definition for transactions
which merely contain an address ACK.
Signed-off-by: Brandon Hurst <brandon.hurst@analog.com>
Move MSPI NOR commands to rodata.
Replace array with empty padding (~1kB) with macro-based assignments.
Ref: NCSDK-32779
Signed-off-by: Tomasz Chyrowicz <tomasz.chyrowicz@nordicsemi.no>
Extend driver to support single lane and 1-4-4 IO modes.
Move flash chip quirks to a separate file.
Signed-off-by: Marcin Szymczyk <marcin.szymczyk@nordicsemi.no>
Added driver for the PAJ7620 gesture sensor. For now,
just added basic gesture mode, although sensor also
has other modes (proximity and cursor modes).
Signed-off-by: Paul Timke Contreras <ptimkec@live.com>
Add AndesTech Platforms section and add me jimmyzhe, kevinwang821020
as maintainer and collaborator.
Signed-off-by: Jimmy Zheng <jimmyzhe@andestech.com>
The wrong cortex M cores are described in the documentation. There is no
CM4. Describe the cores and memories assigned to them correctly.
Signed-off-by: Declan Snyder <declan.snyder@nxp.com>
Update the dual-core memory configuration documentation to use
symbolic references to flash regions and partitions instead of
hardcoded addresses. This makes the documentation more maintainable.
The updated documentation correctly reflects that CPU0 has access to
the full flash memory including the bootloader region, while CPU1 is
restricted to its dedicated slot1_partition region.
Signed-off-by: Tomas Galbicka <tomas.galbicka@nxp.com>
- Adds reference to the MIMXRT1170-EVKB Board Hardware User's Guide.
- Mentions that LinkServer is the default runner (not Jlink).
Signed-off-by: Andrej Butok <andrey.butok@nxp.com>
- The fsl_common_dsp driver needs to be loaded
when building xtensa projects and the fsl_common_arm
driver needs to be loaded when building arm projects.
- Add a condition to load power driver, because the power
driver is needed to build RT700 arm core project, but it
is not needed to build hifi core project.
Signed-off-by: Zhaoxiang Jin <Zhaoxiang.Jin_1@nxp.com>
As well described in a previous PR [1], the GNU ld and LLVM lld linkers
treat the location counter (`.`) differently. lld always inteprets the
location counter as an absolute address whereas ld interprets it as an
offset from the start of the current object.
The NXP boot header linker script files use `.` assignment to specify an
offset within the rom_start region (ld-style). This causes lld to error
out since it interprets this as the location counter moving backwards.
To fix this, re-use the idea from the previous PR [1]:
replace `. = FOO` with `. += FOO - (. - __rom_start_address)`
This sets the location counter in a way that works with both ld and lld.
[1] https://github.com/zephyrproject-rtos/zephyr/pull/58315
Signed-off-by: Kesavan Yogeswaran <hikes@google.com>
Commit 7e8ee25479 moved the tests for the
POSIX_RW_LOCKS Option Group from the tests/posix/common testsuite to
its own dedicated testsuite.
However, there was a copy-paste error. Previously, tests would have been
run only once when dynamic threads were enabled, and then skipped when
dynamic threads were disabled, since that follows the posix programming
model better. However, dynamic threads were never actually enabled after
moving to the new testsuite. So all tests were effectively skipped.
Add the necessary options to prj.conf in order to ensure that there are
sufficient dynamic threads available to run the testsuite.
Signed-off-by: Chris Friedt <cfriedt@tenstorrent.com>
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>
