The nRF5x entropy driver does not depends on SOC_FAMILY_NRF is therefore
visible and selectable non-nRF5x SoCs. Fix that.
Signed-off-by: Aurelien Jarno <aurelien@aurel32.net>
There were several issues in the dts binding for the ssd1673 display:
* binding file mixed description & generation up together
* Use of BASE_LABEL
* orientation-flipped should have been of type boolean
Update the binding file to reflect these changes, and made associated
changes to dts_fixup.h and driver as needed.
Signed-off-by: Kumar Gala <kumar.gala@linaro.org>
Added support for SPI 1 available from the arduino connector (plus an
extra gpio). Tested against samples/sensor/bme280.
Signed-off-by: AJ Palmer <ajpcode@hotmail.com>
When users are configuring nRF applications they are given the option
to enable the DesignWare I2C driver. But they should not be given this
option because nRF SoCs do not have DesignWare I2C HW.
This commit hides the driver by default by introducing the config
option HAS_I2C_DW.
Signed-off-by: Sebastian Bøe <sebastian.boe@nordicsemi.no>
The logical NOT operator has a higher precedence than bitwise
AND operator. Therefore to make the test in if statement
correct, add parenthesis around the operands of bitwise
AND operator.
Found using Coccinelle.
Semantic Patch Language (SmPL) used:
<smpl>
@@
expression x;
constant C;
@@
- !x & C
+ !(x & C)
</smpl>
Signed-off-by: Himanshu Jha <himanshujha199640@gmail.com>
A few issues with the dts support for the SSD1306 display driver:
1. binding file mixed description & generation up together
- rename most uses of generation to description and add proper
generation field into yaml
2. Drop use of BASE_LABEL, this shouldn't be used by most bindings
3. dts defines that are being assumed in driver aren't correct. We
should be using a dts_fixup.h in the sample to map the generated
defines to those used in the driver. We remove the incorrect
defines that the driver assumes right now.
4. Fixup 'segment-remap' and 'com-invdir' properties that are booleans
in the binding file and associated code changes.
Signed-off-by: Kumar Gala <kumar.gala@linaro.org>
Change the default behaviour of the host network interface
setup. Now user needs to execute net-setup.sh script from
net-tools project to setup host ethernet interface. The script
needs to be run as a root user. Then zephyr.exe can be started
as a normal user.
Example:
cd net-tools
sudo ./net-setup.sh
This will create zeth network interface and set IP address and
routes properly. See other command line options by typing
./net-setup.sh --help
Old behaviour is still there if one enables
CONFIG_ETH_NATIVE_POSIX_STARTUP_AUTOMATIC=y
in which case one needs to use the command
sudo --preserve-env zephyr.exe
to start the Zephyr process.
Signed-off-by: Jukka Rissanen <jukka.rissanen@linux.intel.com>
Partially replaces Kinetis MCUX driver configuration from Kconfig to
Device Tree. Interrputs moved from defines configuration to DT.
Signed-off-by: Andrei Gansari <andrei.gansari@nxp.com>
Now that log processing happens in a separate thread, the
BT_STACK_EXTRA macro is not needed (since there's no significant
overhead), and therefore the BT_STACK macros become unnecessary as
well.
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
This shell command was tied to bluetooth and the bluetooth shell and
also had messages all related to nordic ICs.
Make it generic and put it under drivers/flash/ so it can be included by
anyone and independently of bluetooth.
Signed-off-by: Anas Nashif <anas.nashif@intel.com>
Provide basic commands for configuring/setting/reading GPIO ports.
> gpio conf ..
> gpio set ..
> gpio get ..
Signed-off-by: Anas Nashif <anas.nashif@intel.com>
Driver fxos8700 can also be used for the MMA8451
accelerometer and offers more functionality.
Revert the commit to avoid duplicate code.
This reverts commit 9c0d7813e5.
Signed-off-by: Johann Fischer <j.fischer@phytec.de>
Add basic verification of the supported devices.
Add IDs for MMA8451, MMA8652, MMA8653 and FXOS8700 and
remove Kconfig FXOS8700_WHOAMI option.
Signed-off-by: Johann Fischer <j.fischer@phytec.de>
The 'value' param in ACCESS_BY_PORT mode means the state of a port,
one bit represented one pin in param 'value'.
Signed-off-by: qianfan Zhao <qianfanguijin@163.com>
Add pin muxing for STM32F302x8 by sharing most of the definitions
of the STM32F303xC. Add USART3 for both the 302x8 and the 303xC.
Add a PWM that is specific to the 302x8.
Signed-off-by: Galen Seitz <galens@seitzassoc.com>
Introduces the location property and adds the ability to use values
generated by the device tree configuration.
Signed-off-by: Diego Sueiro <diego.sueiro@gmail.com>
Signed-off-by: Kumar Gala <kumar.gala@linaro.org>
Use user data to replace DMA's device pointer in
the callback function so that the user can retrieve
its context by that private data.
Signed-off-by: Jun Li <jun.r.li@intel.com>
I was pretty careful, but these snuck in. Most of them are due to
overbroad string replacements in comments. The pull request is very
large, and I'm too lazy to find exactly where to back-merge all of
these.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
Now that the API has been fixed up, replace the existing timeout queue
with a much smaller version. The basic algorithm is unchanged:
timeouts are stored in a sorted dlist with each node nolding a delta
time from the previous node in the list; the announce call just walks
this list pulling off the heads as needed. Advantages:
* Properly spinlocked and SMP-aware. The earlier timer implementation
relied on only CPU 0 doing timeout work, and on an irq_lock() being
taken before entry (something that was violated in a few spots).
Now any CPU can wake up for an event (or all of them) and everything
works correctly.
* The *_thread_timeout() API is now expressible as a clean wrapping
(just one liners) around the lower-level interface based on function
pointer callbacks. As a result the timeout objects no longer need
to store backpointers to the thread and wait_q and have shrunk by
33%.
* MUCH smaller, to the tune of hundreds of lines of code removed.
* Future proof, in that all operations on the queue are now fronted by
just two entry points (_add_timeout() and z_clock_announce()) which
can easily be augmented with fancier data structures.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
The current z_clock_uptime() call (recently renamed from
_get_elapsed_program_time) requires the driver to track a full 64 bit
uptime value in ticks, which is entirely separate from the one the
kernel is already keeping.
Don't do that. Just ask the drivers to track uptime since the last
call to z_clock_announce(), since that is going to map better to
built-in hardware capability.
Obviously existing drivers already have this feature, so they're
actually getting slightly larger in order to implement the new API in
terms of the old one. But future drivers will thank us.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
Useful for tick-only drivers like Pulpino that don't support this.
Ideally we'd have a header-level interface definition for individual
timer drivers to eliminate the noop function call, but this is clean
for now (even the Pulpino hardware looks like it should support
timeouts just fine, so effort would be better spent there than on a
clean "ticked" interface).
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
The tickless driver had a bunch of "hairy" APIs which forced the timer
drivers to do needless low-level accounting for the benefit of the
kernel, all of which then proceeded to implement them via cut and
paste. Specifically the "program_time" calls forced the driver to
expose to the kernel exactly when the next interrupt was due and how
much time had elapsed, in a parallel API to the existing "what time is
it" and "announce a tick" interrupts that carry the same information.
Remove these from the kernel, replacing them with synthesized logic
written in terms of the simpler APIs.
In some cases there will be a performance impact due to the use of the
64 bit uptime call, but that will go away soon.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
Rename timer driver API functions to be consistent. ADD DOCS TO THE
HEADER so implementations understand what the requirements are.
Remove some unused functions that don't need declarations here.
Also removes the per-platform #if's around the power control callback
in favor of a weak-linked noop function in the driver initialization
(adds a few bytes of code to default platforms -- we'll live, I
think).
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
The existing API had two almost identical functions: _set_time() and
_timer_idle_enter(). Both simply instruct the timer driver to set the
next timer interrupt expiration appropriately so that the call to
z_clock_announce() will be made at the requested number of ticks. On
most/all hardware, these should be implementable identically.
Unfortunately because they are specified differently, existing drivers
have implemented them in parallel.
Specify a new, unified, z_clock_set_timeout(). Document it clearly
for implementors. And provide a shim layer for legacy drivers that
will continue to use the old functions.
Note that this patch fixes an existing bug found by inspection: the
old call to _set_time() out of z_clock_announce() failed to test for
the "wait forever" case in the situation where clock_always_on is
true, meaning that a system that reached this point and then never set
another timeout would freeze its uptime clock incorrectly.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
There were three separate "announce ticks" entry points exposed for
use by drivers. Unify them to just a single z_clock_announce()
function, making the "final" tick announcement the business of the
driver only, not the kernel.
Note the oddness with "_sys_idle_elapsed_ticks": this was a global
variable exposed by the kernel. But it was never actually used by the
kernel. It was updated and inspected only within the timer drivers,
and only so that it could be passed back to the kernel as the default
(actually hidden) argument to the announce function. Break this false
dependency by putting this variable into each timer driver
individually.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
The system tick count is a 64 bit quantity that gets updated from
interrupt context, meaning that it's dangerously non-atomic and has to
be locked. The core kernel clock code did this right.
But the value was also exposed to the rest of the universe as a global
variable, and virtually nothing else was doing this correctly. Even
in the timer ISRs themselves, the interrupts may be themselves
preempted (most of our architectures support nested interrupts) by
code that wants to set timeouts and inspect system uptime.
Define a z_tick_{get,set}() API, eliminate the old variable, and make
sure everyone uses the right mechanism.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
This was another "global variable" API. Give it function syntax too.
Also add a warning, because on nRF devices (at least) the cycle clock
runs in kHz and is too slow to give a precise answer here.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
This just got turned into a function from a "variable" API, but
post-the-most-recent-patch it turns out to be degenerate anyway.
Everyone everywhere should always have been using the kconfig variable
directly, and it was only a weirdness in the tickless API that made it
confusing. Fix.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
The existing API defined sys_clock_{hw_cycles,ticks}_per_sec as simple
"variables" to be shared, except that they were only real storage in
certain modes (the HPET driver, basically) and everywhere else they
were a build constant.
Properly, these should be an API defined by the timer driver (who
controls those rates) and consumed by the clock subsystem. So give
them function syntax as a stepping stone to get there.
Note that this also removes the deprecated variable
_sys_clock_us_per_tick rather than give it the same treatment.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
