Add STMEMSC_CTX I2C/SPI/I3C macros that can be reused among all STMEMSC
based ST sensor drivers to populate the stmdev_ctx_t stucture.
Signed-off-by: Armando Visconti <armando.visconti@st.com>
Align all sensor drivers that are using stmemsc (STdC) HAL i/f
to new APIs of stmemsc v2.02. Please note that now a new function
callback, mdelay(), must be provided in case the stmemsc HAL requires
to wait for a certain amount of milliseconds before or after some
special operations.
Requires https://github.com/zephyrproject-rtos/hal_st/pull/13
(merged as 5948f7b3304f1628a45ee928cd607619a7f53bbb)
Signed-off-by: Armando Visconti <armando.visconti@st.com>
Fixes the iis2dlpc sensor driver to store the user-supplied sensor
trigger as a pointer rather than a copy. This enables the trigger
handler to use CONTAINER_OF to retrieve a context pointer when the
trigger is embedded in a larger struct.
Signed-off-by: Maureen Helm <maureen.helm@intel.com>
This commit adds the activity/inactivity recognition as well as the
stationary/motion detection as defined in the IIS2DLPC application
note.
For now, there is no possibility to configure this interrupt using
device tree binding, as I would like to keep the configuration updatable
and not set at boot time. This behaviour is fine for prototypes and
samples, but is too restrictive on products that may want to change the
interrupt configuration at run-time.
The interrupt is configured using the attributes SENSOR_ATTR_SLOPE_TH and
SENSOR_ATTR_SLOPE_DUR.
Signed-off-by: Giuliano Franchetto <giuliano.franchetto@intellinium.com>
Refactors all sensor drivers to use SENSOR_DEVICE_DT_INST_DEFINE, which
is a sensor-specific variant of DEVICE_DT_INST_DEFINE that provides a
common place to instantiate additional data structures for the future
sensor subsystem and/or sensor driver stats.
This approach was inspired by I2C_DEVICE_DT_INST_DEFINE to streamline
adding I2C stats support across all I2C drivers.
Signed-off-by: Maureen Helm <maureen.helm@intel.com>
This change in pattern is meant to address a misconfiguration issue
that can occur for sensors that support being on multiple busses
like I2C & SPI.
For example, you can have a configuration in which such a sensor is
on the I2C bus in the devicetree and the sensor is enabled. However
the application configuration enables CONFIG_SPI=y and CONFIG_I2C=n
and this will cause the sensor driver to be built by default, however
since we don't have the I2C bus enabled the driver will not compile
correctly.
Previously we had been adding to board Kconfig.defconfig something
like:
config I2C
default y if SENSOR
This pattern doesn't scale well and may differ from what an application
specific need/use is.
So instead move to a pattern in which we leave the default enablement
up to the devicetree "status" property for the sensor. We then have
the Kconfig move from 'depends on <BUS>' to 'select <BUS>' and in
the case of drivers that support multiple busses we have the Kconfig
be: 'select <BUS> if $(dt_compat_on_bus,$(<DT_COMPAT>),<BUS>) for
each bus type the sensor supports.
This removes the need to add Kconfig logic to each board and enables
the bus subsystem and bus controller driver if the sensor requires
it by default in the build system.
Fixes: #48518
Signed-off-by: Kumar Gala <galak@kernel.org>
Update sensor drivers to use DT_HAS_<compat>_ENABLED Kconfig symbol
to expose the driver and enable it by default based on devicetree.
Signed-off-by: Kumar Gala <galak@kernel.org>
In order to bring consistency in-tree, migrate all drivers to the new
prefix <zephyr/...>. Note that the conversion has been scripted, refer
to #45388 for more details.
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
Make use of the new DT facilities that introduced two new
bus structures, spi_dt_spec and i2c_dt_spec, as well as the
macros, SPI_DT_SPEC_INST_GET and I2C_DT_SPEC_INST_GET, to
retrieve info from DT.
Signed-off-by: Armando Visconti <armando.visconti@st.com>
In drivers/sensor/CMakeLists.txt, we have various lines like this:
add_subdirectory_ifdef(CONFIG_FOO foo)
Then drivers/sensor/foo/CMakeLists.txt says:
zephyr_library()
zephyr_library_sources_ifdef(CONFIG_FOO foo.c)
This is redundant; the foo/CMakeLists.txt won't be added to the build
system unless CONFIG_FOO=y in the first place, so there's no need for
extra boilerplate testing it again.
Remove all these unnecessary instances in each sensor driver's
CMakeLists.txt using this pattern:
zephyr_library()
zephyr_library_sources(foo.c)
In a couple of places, the '.c' extension is missing. Add them in for
consistency when that happens.
Signed-off-by: Martí Bolívar <marti.bolivar@nordicsemi.no>
This commit aligns iis2dlpc sensor driver to latest multi
instance sensor driver model.
In particular:
1. make use of some few DT helpers:
- get bus devices with DEVICE_DT_GET
- get SPI information with SPI_CONFIG_DT_INST
- get drdy gpios with GPIO_DT_SPEC_GET
2. make use of the stmemsc common routines and move ctx
handler inside struct config, so that the bus_init
routines can be totally avoided.
Signed-off-by: Armando Visconti <armando.visconti@st.com>
Currently there is no way to distinguish between a caller
explicitly asking for a semaphore with a limit that
happens to be `UINT_MAX` and a semaphore that just
has a limit "as large as possible".
Add `K_SEM_MAX_LIMIT`, currently defined to `UINT_MAX`, and akin
to `K_FOREVER` versus just passing some very large wait time.
In addition, the `k_sem_*` APIs were type-confused, where
the internal data structure was `uint32_t`, but the APIs took
and returned `unsigned int`. This changes the underlying data
structure to also use `unsigned int`, as changing the APIs
would be a (potentially) breaking change.
These changes are backwards-compatible, but it is strongly suggested
to take a quick scan for `k_sem_init` and `K_SEM_DEFINE` calls with
`UINT_MAX` (or `UINT32_MAX`) and replace them with `K_SEM_MAX_LIMIT`
where appropriate.
Signed-off-by: James Harris <james.harris@intel.com>
The ',' character was used as line terminator instead of ';'
in SPI routines. The three affected drivers were not showing
any issue, but the typo is fixed for clarity.
Signed-off-by: Armando Visconti <armando.visconti@st.com>
Move iis2dlpc trigger pulse configurations from Kconfigs to Device Tree.
Moreover the dts properties have been renamed as 'tap', which sounds a
better name to immediately catch the feature behind it. Since tap
threshold cannot be zero, this value (which is the default in dts
binding) is used to enable/disable the device feature per each axis.
The event can be generated on INT1 only.
Signed-off-by: Armando Visconti <armando.visconti@st.com>
Simplify the switch case on trigger types (SENSOR_TRIG_DRDY and
SENSOR_TRIG_TAP) inside iis2dlpc_enable_int().
Signed-off-by: Armando Visconti <armando.visconti@st.com>
The IIS2DLPC drdy interrupt can be routed to either INT1 or
INT2 pin. Currently the selection is done by Kconfig configuration.
This commit is instead moving it into Device Tree as 'drdy-int'.
Signed-off-by: Armando Visconti <armando.visconti@st.com>
Remove all odr values from Kconfig and always init it
at 12.5Hz. It is responsibility of application to set
the rate to a different value using SENSOR_ATTR_SAMPLING_FREQUENCY.
Signed-off-by: Armando Visconti <armando.visconti@st.com>
Align all sensor drivers that are using stmemsc (STdC) HAL i/f
to new APIs of stmemsc v1.03.
Requires https://github.com/zephyrproject-rtos/hal_st/pull/5
(merged as b52fdbf4b62439be9fab9bb4bae9690a42d2fb14)
Signed-off-by: Armando Visconti <armando.visconti@st.com>
HAS_DTS_I2C is now selected by I2C and
always used as I2C && HAS_DTS_I2C.
It could then be purely removed.
Signed-off-by: Erwan Gouriou <erwan.gouriou@linaro.org>
It is necessary to wrap the device pointer into data.
Which was done already on most of them when global trigger is enabled.
Fixes#27399
Signed-off-by: Tomasz Bursztyka <tomasz.bursztyka@linux.intel.com>
Now that device_api attribute is unmodified at runtime, as well as all
the other attributes, it is possible to switch all device driver
instance to be constant.
A coccinelle rule is used for this:
@r_const_dev_1
disable optional_qualifier
@
@@
-struct device *
+const struct device *
@r_const_dev_2
disable optional_qualifier
@
@@
-struct device * const
+const struct device *
Fixes#27399
Signed-off-by: Tomasz Bursztyka <tomasz.bursztyka@linux.intel.com>
Usually, we want to operate only on "available" device
nodes ("available" means "status is okay and a matching binding is
found"), but that's not true in all cases.
Sometimes we want to operate on special nodes without matching
bindings, such as those describing memory.
To handle the distinction, change various additional devicetree APIs
making it clear that they operate only on available device nodes,
adjusting gen_defines and devicetree.h implementation details
accordingly:
- emit macros for all existing nodes in gen_defines.py, regardless
of status or matching binding
- rename DT_NUM_INST to DT_NUM_INST_STATUS_OKAY
- rename DT_NODE_HAS_COMPAT to DT_NODE_HAS_COMPAT_STATUS_OKAY
- rename DT_INST_FOREACH to DT_INST_FOREACH_STATUS_OKAY
- rename DT_ANY_INST_ON_BUS to DT_ANY_INST_ON_BUS_STATUS_OKAY
- rewrite DT_HAS_NODE_STATUS_OKAY in terms of a new DT_NODE_HAS_STATUS
- resurrect DT_HAS_NODE in the form of DT_NODE_EXISTS
- remove DT_COMPAT_ON_BUS as a public API
- use the new default_prop_types edtlib parameter
Signed-off-by: Martí Bolívar <marti.bolivar@nordicsemi.no>
Some sensor drivers modify there struct's based on DT defines. In those
cases we need to make sure that DT_DRV_COMPAT is set on all the source
files associated with that driver. This updates any such files.
Signed-off-by: Kumar Gala <kumar.gala@linaro.org>
The IIS2DLPC is a 3D digital accelerometer ultra-low power sensor
for industrial applications, which can be interfaced through either
I2C or SPI bus.
https://www.st.com/resource/en/datasheet/iis2dlpc.pdf
This driver is based on stmemsc i/f v1.02
Signed-off-by: Armando Visconti <armando.visconti@st.com>
