Now that we have a more generic ksdk pinmux driver that can be used
across multiple Kinetis SoCs, deprecate the specific k64 pinmux driver.
Jira: ZEP-1393
Change-Id: I11cfe9a53746a6e85eced2a7cecf0396d42a7a19
Signed-off-by: Maureen Helm <maureen.helm@nxp.com>
This commit replaces the nanokernel.h include by kernel.h.
Change-Id: Ib42fbf2d9f77a73c0831f569b3dbbfb342ea2e1d
Signed-off-by: Flavio Santes <flavio.santes@intel.com>
Pinmux driver almost certainly should be initialized before the
rest of hardware devices (which may need specific pins already
configured for them), and usually after generic GPIO drivers.
Thus, its priority should be between KERNEL_INIT_PRIORITY_DEFAULT
(default 40) and KERNEL_INIT_PRIORITY_DEVICE (default 50). Thus,
we set PINMUX_INIT_PRIORITY to 45.
There are exceptions to the rule above for particular boards. For
example, BOARD=galileo has GPIO and pinmuxer on I2C bus and thus
overrides PINMUX_INIT_PRIORITY to be much higher. Note that while
PINMUX_INIT_PRIORITY was defined previously (at 60), it was used
only for galileo, which overrides it anyway.
This fix was prompted by investigation why eth_ksdk driver was
non-functional after kernel priorities re-hashing: both eth_ksdk
and pinmux used the same priority, and eth_ksdk happened to run
before pinmux. While bumping eth_ksdk priority would help in the
particular case, the same would likely reoccur with other drivers
like I2C, SPI, etc.
Change-Id: Ie5ca3135c1ee2fe8d9cf48d5c12e62eac63487f7
Signed-off-by: Paul Sokolovsky <paul.sokolovsky@linaro.org>
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>
These pins are routed to the arduino header, and configuring them for
UART signals allows us to use the frdm_k64f with a frdm_kw40z shield
board for bluetooth.
Change-Id: Ie30916409844b1dc1c6e1280d5a755a6dc42e418
Signed-off-by: Maureen Helm <maureen.helm@nxp.com>
The hexiwear board has a k64 SoC, so we can reuse the k64 pinmux driver
and just add a new pinmux table for the board.
Jira: ZEP-716
Change-Id: I936691b3578db298014f44fe18433d7943b431f3
Signed-off-by: Maureen Helm <maureen.helm@nxp.com>
The k64 pinmux driver can be used for any k64 board, not just frdm_k64f,
therefore renaming the driver accordingly.
Change-Id: I45e96d4a5ff6aa859d0f57fe098e44a8ae5283d1
Signed-off-by: Maureen Helm <maureen.helm@nxp.com>
Maureen Helm