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>
This is a new test and we have riscv32 failing on that all of the
sudden. Disabling while we look into it and identify if that is a
testcase issue or not.
Signed-off-by: Anas Nashif <anas.nashif@intel.com>
Add console harness support for USB mass storage test.
Also, using overlay config for DISK_ACCESS configuration
and accessing the different config file with different
method.
Signed-off-by: Ajay Kishore <ajay.kishore@intel.com>
Signed-off-by: Anas Nashif <anas.nashif@intel.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>
The first argument in DMA callback can be set to
arbitrary user data instead of DMA device pointer
so the user can pass its private context
in the callback function.
Signed-off-by: Jun Li <jun.r.li@intel.com>
For the 'app' build scripts to be able to do post-processing on the
elf file they need to know what the target name for the elf file is.
In zephyr this name varies depending on whether one does a single or
multiple link, so we export a variable with the name.
Signed-off-by: Sebastian Bøe <sebastian.boe@nordicsemi.no>
I committed a user error and edited a file named in the sphinx output
to correct an error. To my dismay later, I discovered my work had been
lost as that file is not versioned.
Warn the others.
Signed-off-by: Marti Bolivar <marti@foundries.io>
In a clean build, Ninja is creating copies of the extracted
documentation outputs regardless of whether they already exist or
not. I can't explain this behavior from the documentation of the build
command, but it's so, even if extract_content.py is patched to use
copyfile() instead of copy2() so that outputs (copied .rst files in
the build directory) have strictly newer mtimes than inputs (source
tree .rst files).
This extra copying doesn't happen for incremental builds, for some
reason.
To account for this behavior, add and use an extract_content.py option
that skips content extraction completely and leaves that all up to the
add_custom_command() which tracks each individual input->output build
command.
Reported-by: Carles Cufi <carles.cufi@nordicsemi.no>
Signed-off-by: Marti Bolivar <marti@foundries.io>
In tickless mode, not all elapsed ticks may have been announced yet,
so future z_time_slice() calls will include "extra" ticks that we have
to account for when setting up the slice count.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
Our funny convention holds that passing ticks==1 to _add_timeout()
means "at the next tick". But that means that 1, 0, and all negative
numbers are expected to behave the same. In ticked mode, that's fine
because it will, after all, expire at the next tick.
But in tickless, the next announcement may be for several ticks, and
that zero will appear to expire "before" the next tick in the
consumption loop.
Make sure all "next tick" expirations look the same.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
This test was written to assume that on idle the CPU would wake up on
the next tick boundary because of the timer interrupt. No such
interrupt arrives in tickless mode and it hangs forever.
A more whiteboxy test involving setting a clock timout will have to be
written for this feature if we want to keep it on tickless systems.
Alternatively we could move this test out of tests/kernel/context and
always disable tickless.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
When fetching the next timeout to expire, the value is relative to the
last announced tick, so you subtract the timer-provided elapsed time
to get the true delta from "now". When adding a new timeout, you
*have* a value relative to now, so you compute the delta vs. the last
announced tick by adding the elapsed() time. Duh.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
The theory behind this test seems to be that taking an IRQ lock should
prevent the advance of the kernel's tick counter. That works on
traditional timers only. In tickless mode the timer hardware/driver
is expected to be able to give us an answer for time independent of
interrupt delivery, so the test fails spuriously. The "bug" detected
is a feature of tickless!
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
This was wrong in subtle ways. In tickless mode it's possible to get
an announcement for multiple ticks at a time and have multiple
callbacks to execute that were technically scheduled at different
times. We want to fix the current tick at the value represented by
the currently-executing callback's EXPIRATION (even if we missed it!),
so that any new timeouts it sets (c.f. a k_timer period) happen at the
right point, in phase with the expected series. In single-tick mode
the code ends up the same always, so the bug wasn't visible.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
This wasn't explained correctly. The tick convention we use here
(owing to the way legacy code was written) is a little weird. Timeout
delays are passed in a "round down" sense, so that setting a timeout
in "one tick" means that the interrupt will arrive anywhere between
zero and one ticks in the future.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
The previous comment correctly and carefully explained why the 64 bit
value in curr_tick doesn't require locking when reading only the low
32 bits.
It completely missed the fact that the calculation of elapsed time and
the read of curr_tick ABSOLUTELY DO require locking, because the
former is expressed in terms of the latter. This was always bug, even
in the old code, but never witnessed because we ran so little software
in tickless mode.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
It's possible to interrupt a thread that has already scheduled a
timeout. Really this is a race against the usage of
_add_thread_timeout() and needs some design work to provide proper
locking (which is a distinct requirement from the scheduler lock and
timeout lock!), as the users of that API are spread around the kernel.
But existing usage always schedules the timeouts first, so this is
safe.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
The timeout APIs are properly synchronized now. This irq_lock() (and
the comment explaining it) isn't needed anymore.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
These options are rapidly becoming a default configuration, which is
complicated by having them be hidden inside of a SYS_POWER_MANAGEMENT
variable that has to be enabled first. Put them at the top level of
the kernel config.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
Clarify behavior of the ticks argument to z_clock_set_timeout() and
add an important note about expected behavior in SMP environments.
Signed-off-by: Andy Ross <andrew.j.ross@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>
This test needs just a tiny bit of extra stack. 512 bytes isn't
enough on x86 with the most recent set of timer patches.
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>
_timeout_remaining_get() was a function on a struct _timeout, doing
iteration on the timeout list, but it was defined in timer.c (the
higher level abstraction).
Move it to where it belongs. Also have it return ticks instead of ms
to conform to scheme in the rest of the timeout API. And rename it to
a more standard zephyr name.
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>
Add the callback parameter to add_timeout(), and remove the thread
argument. Now the "low level" timeout API can be expressed without
reference to threads.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
Now that this is known to be an unused value, remove it from the API.
Note that this caught a few spots where we were passing values (a
non-NULL wait_q with a NULL thread handle) that were always being
ignored before.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
The existing timeout API wants to store a wait_q on which the thread
is waiting, but it only uses that value in one spot (and there only as
a boolean flag indicating "this thread is waiting on a wait_q).
As it happens threads can already store their own backpointers to a
wait_q (needed for the SCALABLE scheduler backend), so we should use
that instead.
This patch doesn't actually perform that unification yet. It
reorgnizes things such that the pended_on field is always set at the
point of timeout interaction, and adds a bunch of asserts to make 100%
sure the logic is correct. The next patch will modify the API.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
The timeout_q.h scheme, where it declared real functions, but the
stubs for when there was no clock were in wait_q.h was senselessly
weird. Put them in the same file.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
Instead of checking every time we hit the low-level context switch
path to see if the new thread has a "partner" with which it needs to
share time, just run the slice timer always and reset it from the
scheduler at the points where it has already decided a switch needs to
happen. In TICKLESS_KERNEL situations, we pay the cost of extra timer
interrupts at ~10Hz or whatever, which is low (note also that this
kind of regular wakeup architecture is required on SMP anyway so the
scheduler can "notice" threads scheduled by other CPUs). Advantages:
1. Much simpler logic. Significantly smaller code. No variance or
dependence on tickless modes or timer driver (beyond setting a
simple timeout).
2. No arch-specific assembly integration with _Swap() needed
3. Better performance on many workloads, as the accounting now happens
at most once per timer interrupt (~5 Hz) and true rescheduling and
not on every unrelated context switch and interrupt return.
4. It's SMP-safe. The previous scheme kept the slice ticks as a
global variable, which was an unnoticed bug.
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>
This got broken. Add some #ifery to handle the case. Not clean, will
clean up in a future pass once the API is final.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
Not sure why this was here. The point to this API (which is poorly
explained) is to "round up" requested timeout values to an integer
number of ticks in the future, so the timeouts don't expire too soon.
There's no change of that requirement in tickless mode. While the
"tick" unit will typicaly be a much smaller time (and thus much less
likely to have this kind of aliasing bug), we STILL don't want early
expiration.
And as with everything else in tickless, changing this breaks no
tests. So remove it as a needless TICKLESS dependency.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
This feature was a useless noop based on mistaken API understanding.
The idea seems to have been that k_busy_wait() included guards to
ensure "clock_always_on" was true duing the loop, presumably because
the original author was afraid that "turning the clock off" would
affect the operation of k_cycle_get_32().
Then later someone came around and "optimized" this for Quark SE,
where the cycle counter is the RTC and unrelated to the timer driver
used by the clock_always_on feature. (Except even there it presumably
should have been done at the SoC level and not just in the C1000
devboard -- note that Arduino 101 never would have gotten this).
But it was all a mistake: "clock_always_on" has nothing to do with
en/disabling the system cycle timer (which never happens when the
system is active, that's a feature of idle), it's a control over the
delivery of timer interrupts. And needless to say we don't care about
timer interrupts when we're spinning on a cycle counter.
Yank the whole mess.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
