If there is more than one PWM than generate a define with a trailing
index for the PWM. This matches what we do for GPIOs.
So something like:
DT_PWM_LEDS_RED_PWM_LED_PWMS_CONTROLLER_0
DT_PWM_LEDS_RED_PWM_LED_PWMS_CONTROLLER_1
...
DT_PWM_LEDS_RED_PWM_LED_PWMS_CONTROLLER_<N>
Fixes#18171
Signed-off-by: Kumar Gala <kumar.gala@linaro.org>
The callback might return more than length of data read.
It should return nothing more than read length requested.
Patch fixes this behavior.
Signed-off-by: Andrzej Puzdrowski <andrzej.puzdrowski@nordicsemi.no>
The callback typedef was not documented. This documentation
which explains what behavior is expected from any implementation.
Signed-off-by: Andrzej Puzdrowski <andrzej.puzdrowski@nordicsemi.no>
Related to #17997, move an include out of a extern "C" block
Background:
Declarations that use C linkage should be placed within extern "C"
so the language linkage is correct when the header is included by
a C++ compiler.
Similarly #include directives should be outside the extern "C" to
ensure the language-specific default linkage is applied to any
declarations provided by the included header.
See: https://en.cppreference.com/w/cpp/language/language_linkage
Signed-off-by: Alberto Escolar Piedras <alpi@oticon.com>
Related to #17997, for the POSIX arch:
* Remove some unnecessary extern "C" and ifdef blocks
* Move an include out of one of these blocks
* Add a missing extern "C" block
Background:
Declarations that use C linkage should be placed within extern "C"
so the language linkage is correct when the header is included by
a C++ compiler.
Similarly #include directives should be outside the extern "C" to
ensure the language-specific default linkage is applied to any
declarations provided by the included header.
See: https://en.cppreference.com/w/cpp/language/language_linkage
Signed-off-by: Alberto Escolar Piedras <alpi@oticon.com>
Package "hub" has been renamed some time ago to "git-spindle".
Recently package with the same name "hub" has been released on PyPi
page, which causes installing pip requirements.txt to fail since
it is trying to install different package.
Signed-off-by: Marcin Sloniewski <marcin.sloniewski@gmail.com>
* CONFIG_SMP can be enabled by smp application, e.g. tests/kernel/smp
* if application is not designed for smp, CONFIG_SMP can be disabled,
and the target works as a single processor.
Signed-off-by: Wayne Ren <wei.ren@synopsys.com>
Now when SMP support for ARC is available we may introduce a simulation
platform which might be used for testing & development for SMP setups.
One important note is stand-alone nSIM (as well as its "Free" flavour)
doesn't support SMP simulation so we have to switch to use of nSIM via
proprietary MetaWare debugger [1] and so:
1. We introduce new emulation target "mdb"
2. It's only possible to run that platform for those who
have MetaWare tools installed and valid license.
Though QEMU port for ARC is in work at the moment and once we
open that port and it has SMP support we'll switch to it and everybody
will be able to try ARC HS with SMP.
[1] https://www.synopsys.com/dw/ipdir.php?ds=sw_metaware
Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com>
Fix the pipeline prepare-resume implementation to correctly
handle multiple continuous events that request resume on
being pre-empted.
Symptoms of the bug being, when having continuous scanning,
and an active peripheral if a directed advertising is
started the peripheral event are not scheduled causing link
supervision timeout.
This is fixed by not having an enqueued resume event
prepared if there is an enqueued new non-resume event in the
pipeline.
Signed-off-by: Vinayak Kariappa Chettimada <vich@nordicsemi.no>
Increase pipeline size to accommodate probable multiple
prepare for directed advertising events, with reserved time
which are shorter than prepare duration, being enqueued.
Signed-off-by: Vinayak Kariappa Chettimada <vich@nordicsemi.no>
Increase the event start overhead time to accommodate for
processing time for dequeueing pipeline in Upper Link Layer.
Signed-off-by: Vinayak Kariappa Chettimada <vich@nordicsemi.no>
Reduce the maximum number of pending event done elements by
decoupling it from the maximum pipeline elements.
Signed-off-by: Vinayak Kariappa Chettimada <vich@nordicsemi.no>
Disable controller filtering feature not used on mesh stack.
This reduces some RAM usage.
Signed-off-by: Vinayak Kariappa Chettimada <vich@nordicsemi.no>
This commit includes the initial support of ARC HS Development Kit:
* hsdk soc support
* hsdk board support
* no mmu support, so no userspace
* smp support
Signed-off-by: Wayne Ren <wei.ren@synopsys.com>
In some hardware,e.g. ARC HS Development kit,the
peripheral space of ns16550 only allowes WORD
access, byte acess will raise bus error.
This commit adds support for this case
Signed-off-by: Wayne Ren <wei.ren@synopsys.com>
* this is a simple sample to show how
secure applicaiton and non-secure application work
together. More details are in README.rst
Signed-off-by: Wayne Ren <wei.ren@synopsys.com>
* it's based on ARC SecureShield
* add basic secure service in arch/arc/core/secureshield
* necesssary changes in arch level
* thread switch
* irq/exception handling
* initialization
* add secure time support
Signed-off-by: Wayne Ren <wei.ren@synopsys.com>
This adds support for SARA-U2 modems. They have different timings on
the PWR_ON pin, don't support AT+CESQ and require a manual GPRS
connection setup.
The VINT pin is used as a more reliable and faster way to power on the
modem.
Based on work by Göran Weinholt <goran.weinholt@endian.se>
Signed-off-by: Michael Scott <mike@foundries.io>
Let's convert the SARA modem to use the more generic modem context
layers so that we don't maintain a lot of what should be shared code.
This conversion includes:
- modem context as the helper umbrella
- uart modem interface layer
- generic command handler layer
- modem socket helper
- move from net_context offload API to socket offload API
Signed-off-by: Michael Scott <mike@foundries.io>
Many modems implement socket-based APIs to manage data connections.
This layer provides much of the groundwork for keeping track of
these "sockets" throughout their lifecycle (from the initial offload
API calls through the command handler call back layers):
- structure for holding socket data like IP protocol, destination,
source and incoming packet sizes
- configuration to note modem starting socket id and number of
sockets
- methods to get/put socket structs from/to the pool
- function to update the # and size of packets in the modem receive
queue
- prebuilt modem_socket_poll() method for socket offload poll() API
Example modem driver setup code looks like this:
/* socket data */
static struct modem_socket_config socket_config;
static struct modem_socket sockets[MDM_MAX_SOCKETS];
static int modem_init(struct device *dev)
{
...
/* setup socket config */
socket_config.sockets = &sockets[0];
socket_config.sockets_len = ARRAY_SIZE(sockets);
socket_config.base_socket_num = 0;
ret = modem_socket_init(&socket_config);
...
}
Signed-off-by: Michael Scott <mike@foundries.io>
This is a generic command handler implementation which uses the
supplied modem interface to process incoming data and hand it
back to the modem driver via callbacks defined for:
- modem responses
- unsolicited messages
- specified handlers for current operation
The individual modem drivers define functions as command handlers
via the MODEM_CMD_DEFINE() macro.
To use these handlers, a modem operation defines a series of
modem_cmd structures and passes them to the modem_cmd_send()
function. The modem_cmd includes data for:
- a matching string for when to execute the handler
- # of parameters to parse after the matching string
- delimeters for the parameters
Example modem driver setup code looks like this:
/* create modem context object */
static struct modem_context mctx;
/* net_buf receive pool */
NET_BUF_POOL_DEFINE(mdm_recv_pool, MDM_RECV_MAX_BUF,
MDM_RECV_BUF_SIZE, 0, NULL);
/* modem cmds */
static struct modem_cmd_handler_data cmd_handler_data;
static u8_t cmd_read_buf[MDM_RECV_BUF_SIZE];
static u8_t cmd_match_buf[MDM_RECV_BUF_SIZE];
/* modem response handlers */
static struct modem_cmd response_cmds[] = {
MODEM_CMD("OK", on_cmd_ok, 0U, ""),
MODEM_CMD("ERROR", on_cmd_error, 0U, ""),
MODEM_CMD("+CME ERROR: ", on_cmd_exterror, 1U, ""),
};
/* unsolicited handlers */
static struct modem_cmd unsol_cmds[] = {
MODEM_CMD("+UUSOCL: ", on_cmd_socknotifyclose, 1U, ""),
MODEM_CMD("+UUSORD: ", on_cmd_socknotifydata, 2U, ","),
MODEM_CMD("+UUSORF: ", on_cmd_socknotifydata, 2U, ","),
MODEM_CMD("+CREG: ", on_cmd_socknotifycreg, 1U, ""),
};
/* setup cmd handler data */
cmd_handler_data.cmds[CMD_RESP] = response_cmds;
cmd_handler_data.cmds_len[CMD_RESP] = ARRAY_SIZE(response_cmds);
cmd_handler_data.cmds[CMD_UNSOL] = unsol_cmds;
cmd_handler_data.cmds_len[CMD_UNSOL] = ARRAY_SIZE(unsol_cmds);
cmd_handler_data.read_buf = &cmd_read_buf[0];
cmd_handler_data.read_buf_len = sizeof(cmd_read_buf);
cmd_handler_data.match_buf = &cmd_match_buf[0];
cmd_handler_data.match_buf_len = sizeof(cmd_match_buf);
cmd_handler_data.buf_pool = &mdm_recv_pool;
cmd_handler_data.alloc_timeout = BUF_ALLOC_TIMEOUT;
ret = modem_cmd_handler_init(&mctx.cmd_handler, &cmd_handler_data);
Signed-off-by: Michael Scott <mike@foundries.io>
Initial support for modems in Zephyr use the following driver model:
- Main portions of code live in the modem specific driver.
This includes internal socket management, command parsing, etc.
- They leverage a UART-based modem receiver helper to gather data.
- Interface with Zephyr networking via net_context offload APIs.
This implementation was good enough to kick start interest in
supporting modem usage in Zephyr, but lacks future scalability:
- The net_context offload APIs don't allow for operations such
as offloaded DNS, SSL/TLS and other HW specific features.
- Since most of the code lives within the modem drivers, it's
very hard for the Zephyr community to improve the driver layer
over time. Bugs found in 1 driver probably affect others due
to copy/paste method of development.
- Lack of abstraction for different modem interfaces and command
handlers makes it impossible to write a "dummy" layer which
could be used for testing.
- Lack of centralized processing makes implementing low power modes
and other advanced topics more difficult.
Introducing the modem context helper driver and sub-layers:
- modem context helper acts as an umbrella for several configurable
layers and exposes this data to externals such as the modem shell.
Included in the helper is GPIO pin config functions which are
currently duplicated in most drivers.
- modem interface layer: this layer sits on the HW APIs for the
peripheral which communicates with the modem. Users of the modem
interface can handle data via read/write functions. Individual
modem drivers can select from (potentially) several modem
interfaces.
- modem command parser layer: this layer communicates with the
modem interface and processes the data for use by modem drivers.
Fixes: https://github.com/zephyrproject-rtos/zephyr/issues/17922
Signed-off-by: Michael Scott <mike@foundries.io>
The xlnx-zcu102 qemu machine is the only one that supports a Cortex-R
processor. However, its main CPUs are Cortex A53s which requires the
aarch64 qemu binary to run.
Signed-off-by: Bradley Bolen <bbolen@lexmark.com>
This commit adds support for the Zynq UltraScale+ MPSoC as a qemu based
platform for Cortex-R based testing. This SoC only supports an
interrupt controller and serial port for limited testing.
Signed-off-by: Bradley Bolen <bbolen@lexmark.com>
Cortex R has a write buffer that can cause reordering problems when
accessing memory mapped registers. Use memory barries to make sure that
these accesses are performed in the desired order.
Signed-off-by: Bradley Bolen <bbolen@lexmark.com>
The GIC400 is a common interrupt controller that can be used with the
Cortex A and R series processors. This patch adds basic interrupt
handling for the GIC, but does not handle multiple routing or
priorities.
Signed-off-by: Bradley Bolen <bbolen@lexmark.com>
Provide a path for irq controller drivers to change properties of an
individual irq using priority and flags fields that come from the device
tree.
Signed-off-by: Bradley Bolen <bbolen@lexmark.com>
When checking for total IP address counts, don't check
CONFIG_NET_IF_MAX_IPV6_COUNT twice. This was a typo for
CONFIG_NET_IF_MAX_IPV4_COUNT.
This was reported by IRC user: retfie
Signed-off-by: Michael Scott <mike@foundries.io>
Remove unused "system-clock-frequency" property, we don't have this
defined in various bindings and thus aren't using it.
Signed-off-by: Kumar Gala <kumar.gala@linaro.org>
Add "#address-cells" and "#size-cells" to the fixed-partition binding as
these are properties that may existing in the fixed-partition node.
Signed-off-by: Kumar Gala <kumar.gala@linaro.org>
* Change pwm device bindings to include both base and pwm.yaml. This
allow for flexibility for any nodes that might not need/utilize the
base binding.
* Added pwm.yaml to a few device bindings that were missing it.
Signed-off-by: Kumar Gala <kumar.gala@linaro.org>
Introduce a clock.yaml that clock controller bindings should inherit
from. clock.yaml defines the properties "#clock-cells" which all
clock controllers should have.
Signed-off-by: Kumar Gala <kumar.gala@linaro.org>
We don't want any defines generated for the boolean
'gpio-controller'. So skip it in write_props if we see it.
Signed-off-by: Kumar Gala <kumar.gala@linaro.org>
