Fix usage of integration_platforms. Do not set it when the board is
excluded using some other filters.
Signed-off-by: Anas Nashif <anas.nashif@intel.com>
This platform requires a special setup and has its own workflow. Do not
list it as integration platform as it violates the rule of having to be
built which is not possible due to missing environment.
Signed-off-by: Anas Nashif <anas.nashif@intel.com>
Add implementation in Controller to set radio high voltage
to enable support for +3dBm Tx Power in nRF53 Series SoCs.
Signed-off-by: Vinayak Kariappa Chettimada <vich@nordicsemi.no>
Add radio_stop interface that will be called on radio event
done. This interface can be in turn used to perform H/w
dependent cleanup for every Radio event done.
Signed-off-by: Vinayak Kariappa Chettimada <vich@nordicsemi.no>
Log an error when allocating a network packet for transmission fails.
This is a problem which can be solved by increasing
`CONFIG_NET_PKT_TX_COUNT`, but is currently hard to diagnose.
Signed-off-by: Jordan Yates <jordan.yates@data61.csiro.au>
On multiprocessor systems, it's routine to enter sys_clock_announce()
in parallel (the driver will generally announce zero ticks on all but
one cpu).
When that happens, each call will independently enter the loop over
the timeout list. The access is correctly synchronized, so the list
handling is correct. But the lock is RELEASED around the invocation
of the callback, which means that the individual callbacks may
interleave between cpus. That means that individual
application-provided callbacks may be executed in parallel, which to
the app is indistinguishable from "out of order".
That's surprising and error-prone. Don't do it. Place a secondary
outer spinlock around the announce loop (but not the timeslicing
handling) to correctly serialize the timeout handling on a single cpu.
(It should be noted that this was discovered not because of a timeout
callback race, but because the resulting simultaneous calls to
sys_clock_set_timeout from separate cores seems to cause extremely
high latency excursions on intel_adsp hardware using the cavs_timer
driver. That hardware issue is still poorly understood, but this fix
is desirable regardless.)
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
Implement the blanking_on and blanking_off API functions for
NXP's MCUX ELCDIF display driver
Signed-off-by: Mahesh Mahadevan <mahesh.mahadevan@nxp.com>
In ARM parlance, the subroutine call return address is stored in the
"link register" or simply lr. Refer to it as lr which is clearer than
the anonymous x30 designation.
Signed-off-by: Nicolas Pitre <npitre@baylibre.com>
This configure and connect host /dev/pts/N to arm qemu uart-1. It can
use a real device like /dev/ttyS0. Just switch config between serial
and pty chardev options.
In addition, this update QEMU_EXTRA_FLAGS to use only variables instead
hard coded values.
Signed-off-by: Gerson Fernando Budke <gerson.budke@ossystems.com.br>
The I2C address of the VL53L0X distance sensor can only be programmed
over the I2C bus. To do this:
1. The sensor is powered off or in standby mode
2. Power up the sensor, it boots with a default I2C address (0x29)
3. The I2C master sends a configuration command to set the new address
4. The sensor now communicates at the new address
In case there are more than one such sensor on the bus, they all have
the same address when starting up. We therefore need to first apply
step 1. on all of them. Then, sensor by sensor apply steps 2. to 4.
Because simple designs may not need to reprogram the address, we
introduce a new configuration option CONFIG_VL53L0X_RECONFIGURE_ADDRESS
If this setting is disabled, then the driver behaves as before.
If CONFIG_VL53L0X_RECONFIGURE_ADDRESS is enabled, then the driver does
the following:
- In vl53l0x_init(), apply step 1. This is done when the driver is
brought up when starting the system
- in vl53l0x_start(), apply steps 2. to 4. This is done when fetching
a sample, if the sensor has not been started yet.
Also, as cosmetic changes:
- add parenthesis around sub conditions in call to __ASSERT_NO_MSG
- gracefully handle unknown sensor channels in vl53l0x_channel_get
Signed-off-by: Titouan Christophe <moiandme@gmail.com>
Up until now, the vl53l0x driver only supported a single device, ie.
the first entry st,vl53l0x in the device tree. To be able to use
multiple sensors at the same time, create one driver data instance per
vl53l0x node in the device tree. Also split the constant driver config
from the runtime data.
Because the vl53l0x address is only configurable with an I2C command,
and is not persisted if the sensor is rebooted, multiple sensors can
be handled only if either:
- They are on different I2C buses
- Their addresses are coonfigured (by some external code) before
vl53l0x_init is called
Also use the i2c_dt_spec and gpio_dt_spec APIs, as it makes
the code more concise and readable.
Finally, to distinguish the logs mesages from different sensors,
prefix the text with the sensor name.
Signed-off-by: Titouan Christophe <moiandme@gmail.com>
As per the VL53L0X datasheet, in 2.9.1 "Power up and boot sequence",
time to boot is 1.2ms max, so we only have to wait at most 2ms.
Signed-off-by: Titouan Christophe <moiandme@gmail.com>
Don't autoconnect EATT as this was confusing PTS and resulted in
multiple tests failures. When needed PTS will connect EATT bearer.
Signed-off-by: Szymon Janc <szymon.janc@codecoup.pl>
Add soc_secure_mem_read implementation for secure.
This simplifies users code so that ifdefs are not required.
Signed-off-by: Joakim Andersson <joakim.andersson@nordicsemi.no>
The limitation on HWINFO_NRF depending on not nonsecure was removed in
52be3030aa.
This caused problems when TF-M was not enabled.
This happens on the thingy53_nrf5340_cpuapp_ns board since this board
is not supported by TF-M.
Introduce proper dependency handling for the soc secure functions
to make HWINFO_NRF unavailable when no secure services exist in
nonsecure.
Signed-off-by: Joakim Andersson <joakim.andersson@nordicsemi.no>
Move last remaining items from reference section to the appropriate new
section in the new structure.
Signed-off-by: Anas Nashif <anas.nashif@intel.com>
