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>
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>
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>
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>
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>
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 flag is an indication to the timer driver that the OS doesn't
care about rollover conditions of the tick count while idling, so the
system doesn't need to wake up once per counter flip[1]. Obviously in
that circumstance values returned from k_uptime_get_32() are going to
be wrong, so the implementation had an assert to check for misuse.
But no one understood that from the docs, so the only place these APIs
were used in practice were as "guards" around code that needed to call
k_uptime_get_32(), even though that's 100% wrong per docs!
Clarify the docs. Remove the incorrect guards. Change the flag to
initialize to true so that uptime isn't broken-by-default in tickless
mode. Also move the implemenations of the functions out of the
header, as there's no good reason for these to need to be inlined.
[1] Which can be significant. A 100MHz ARM using the 24 bit SysTick
counter rolls over at about 6 Hz, and if it had to come out of
idle at that rate it would be a significant power issue that would
swamp the gains from tickless. Obviously systems with slow
counters like nRF or 64 bit ones like RISC-V or x86's TSC aren't
as affected.
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>
This was only used in a few places just to indirect the already
perfectly valid SYS_CLOCK_TICKS_PER_SEC value. There's no reason for
these to ever have been kconfig units, and in fact the distinction
appears to have introduced a hidden/untested bug in the power
subsystem (the two variables were used interchangably, but they were
defined in reciprocal units!).
Just use "ticks" as our time unit pervasively, and clarify the docs to
explain that.
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>
The kernel.h file had a bunch of internal APIs for timeout/clock
handling mixed in. Move these to sys_clock.h, which it always
included (in a weird location, so move THAT to kernel_includes.h with
everything else).
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
Add monochrome character framebuffer for monochrome
graphic dot matrix displays and electrophoretic displays.
These displays are mostly monochrome and can only display
black and some other color, for example white. Typically,
a byte controls 8 pixels, arranged vertically or horizontally
depending on the controller or settings.
The API is not suitable to display graphics, the purpose is
to display text or symbols. It is possible to use several fonts.
A font can also consist of graphic symbols only and thus,
for example, enable the realization of a menu.
Signed-off-by: Johann Fischer <j.fischer@phytec.de>
posix_flush_stdout() must be provided by any board
using CONFIG_NATIVE_POSIX_CONSOLE, not just by those using
CONFIG_NATIVE_POSIX_STDOUT_CONSOLE
Signed-off-by: Alberto Escolar Piedras <alpi@oticon.com>
Update rel-sections.ld to use wildcards instead of
spelling out those sections one by one.
Also, for POSIX, don't include this and turns off
the warnings. With different host toolchain across
different OS, it would be maintanence nightmare
to account for all those combinations. So this reverts
the POSIX linker script to before the first orphan
section changes.
Fixes#10493
Signed-off-by: Daniel Leung <daniel.leung@intel.com>
* Add usbd_dc_nrfx shim
The shim is based on the previous one usbd_dc_nrf5.
For handling the USBD hardware, tested nrfx_usbd driver from nRF SDK
was used.
Briefly tested examples:
* usb/cdc_acm
* usb/dfu (USB communication only due to flash handling issues)
* usb/hid-mouse
* bluetooth/hci_usb
Signed-off-by: Paweł Zadrożniak <pawel.zadrozniak@nordicsemi.no>
There are sections defined in common-rom/ram.ld where they are
showing up as orphan sections. So add these as known sections.
Fixes#10493
Signed-off-by: Daniel Leung <daniel.leung@intel.com>
Even if we do not have wifi network offloading enabled, allow the
application to be compiled just fine. This allows easier
testing of the application even if the board does not support
wifi offloading.
Signed-off-by: Jukka Rissanen <jukka.rissanen@linux.intel.com>
Extended macro to accept flag indicating if given backend must be
initialized and enabled when log subsystem starts. Typically, simple
backends will have autostart flag set. More complex may require
explicit enabling (e.g. shell over BLE can only be enabled when
BLE connection is established).
Signed-off-by: Krzysztof Chruscinski <krzysztof.chruscinski@nordicsemi.no>
This patch adds Big Endian architecture support. Even if a compiler
generating big endian object files is used, our linker script, or
include/linker/linker-tool-gcc.h to be precise, has default output
format as little endian.
This patch adds a hidden config CONFIG_BIG_ENDIAN, which should be set
by big endian architectures or a SoC's, and adds an condition to
switch OUTPUT_FORMAT in our linker.cmd.
Signed-off-by: Yasushi SHOJI <y-shoji@ispace-inc.com>
usb_dc_status_callback() parameters are interface or configuration
numbers and should be const.
Signed-off-by: Andrei Emeltchenko <andrei.emeltchenko@intel.com>
Adding status callback allows to control report sending only when i.e.
device is connected or configured.
Signed-off-by: Andrei Emeltchenko <andrei.emeltchenko@intel.com>
Some terminals literally interprets shell output data. Hence to print
a message in new line shell needs to send `\r\n` each time. To minimize
flash usage user can now send `\n` as a line delimiter and shell will
automatically add missing CR character.
Signed-off-by: Jakub Rzeszutko <jakub.rzeszutko@nordicsemi.no>
In ARMv8-M MPU it is not possible to have the following access
permissions: Privileged RW / Unprivileged RO. So we define
K_MEM_PARTITION_IS_WRITABLE macro separately for v8M and v7M MPU
architectures (in the separate include files).
Signed-off-by: Ioannis Glaropoulos <Ioannis.Glaropoulos@nordicsemi.no>
Extended ring buffer to allow storing raw bytes in it. API has been
extended keeping 'data item' mode untouched.
Signed-off-by: Krzysztof Chruscinski <krzysztof.chruscinski@nordicsemi.no>
Deprecate API prefixed with sys_ring_buf_ and rename it
to ring_buf_item_ since this API is not a typical ring buffer
but ring buffer of data items (metadata + 32bit words).
Signed-off-by: Krzysztof Chruscinski <krzysztof.chruscinski@nordicsemi.no>
This adds a linker flag and necessary changes to linker scripts
so that linker will warn about orphan sections.
Relates to #5534.
Signed-off-by: Daniel Leung <daniel.leung@intel.com>
The Cypress PSoC6 specifies some input sections in the startup
scripts. These sections (.heap, .stack, etc.) need to be placed
at correct location.
Signed-off-by: Daniel Leung <daniel.leung@intel.com>
This allows the SoC to specify some additional linker script
fragments into the bss, data and read-only data sections.
For example, the Cypress PSOC6 has a few input sections that
must be put into bss and data sections. Without specifying
these in the linker script, they are consider orphan sections
and the placement is based on linker heuristic which is
arbitrary.
POSIX is not supported as the main linker script is
provided by the host system's binutils and we have no control
over it. Also, currently Xtensa SoCs have their own linker
scripts so there is no need to this feature.
Signed-off-by: Daniel Leung <daniel.leung@intel.com>
