If SPI 1 is selected and GPIO CS trick as well, then do not use
controller's CS but GPIO 0 instead as a CS.
Change-Id: Ifc17cdc44f47b9348f4c655d510349e3124dceea
Signed-off-by: Tomasz Bursztyka <tomasz.bursztyka@linux.intel.com>
PRIMARY, SECONDARY, NANOKERNEL, MICROKERNEL init levels are now
deprecated.
New init levels introduced: PRE_KERNEL_1, PRE_KERNEL_2, POST_KERNEL
to replace them.
Most existing code has instances of PRIMARY replaced with PRE_KERNEL_1,
SECONDARY with POST_KERNEL as SECONDARY has had a longstanding bug
where the documentation specified SECONDARY ran before the kernel started
up, but actually ran afterwards.
Change-Id: I771bc634e9caf7f17dbf214a270bc9967eed7d32
Signed-off-by: Andrew Boie <andrew.p.boie@intel.com>
The right flag to enable GPIO as SPI CS is SPI_CS_GPIO.
Change-Id: I06fc5e7e44f9aa6bad5867462c6c069d545bb0b7
Signed-off-by: Baohong Liu <baohong.liu@intel.com>
The SPI_0_CS_GPIO and SPI_0_CS_GPIO_PIN values were defaulting to
something not very usable, because of which e.g. the file system
test app was having to explicitly set the right values in its sample
configuration. Having a proper defaults in the board defconfig means
this isn't needed anymore.
Change-Id: I1399914451c1616588322e25304d40d3dd1151e7
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
These options were only needed for a MyNewt-based nRF51 firmware on
these boards (the MyNewt BLE stack is called Nimble, hence the
prj_nimble.conf sample config files). With a Zephyr-based nRF51
firmware these options are no-longer needed, so it's not appropriate
to have them default to enabled. Instead, if they are needed, require
the app-specific configuration to enable them.
Change-Id: Iefbee4d97590af4e11bcedea05fe61f32a147b83
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Those defined will be used in sample applications that deal with
on-board LEDs.
Change-Id: Ia447adfd33547e01206a9fd7ceeae420ba806f31
Signed-off-by: Anas Nashif <anas.nashif@intel.com>
Introduce an architecture sorting of boards. This is to allow for
easier maintenance going forward as the number of boards grows. It
will be easier for any scripts to know the board/arch mapping without
having to maintain an explicit list of what boards are associated with
which arch. We can also do things like have architecture maintainers
cover reviews and branches for arch/${ARCH} and boards/${ARCH} going
forward.
Change-Id: I02e0a30292b31fad58fb5dfab2682ad1c5a7d5a7
Signed-off-by: Kumar Gala <kumar.gala@linaro.org>
Tomasz Bursztyka