drivers: build as static library #37512
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
github-actions
bot
added
area: Build System
area: CAN
area: I2C
area: Modem
area: Networking
area: Timer
dcpleung
force-pushed
the
drivers_use_zephyr_library
branch
5 times, most recently
from
de57cb1 to
f6e70fc
Compare
dcpleung
requested review from
alexanderwachter,
asbjornsabo,
avisconti,
carlocaione,
finikorg,
gmarull,
jfischer-no,
jhedberg,
joerchan,
Kludentwo,
loicpoulain,
Mani-Sadhasivam,
MaureenHelm,
mbolivar-nordic,
mniestroj,
nandojve and
nashif
as code owners
Instead of putting object files inside libzephyr.a, simply build a separate static library as most other driver types are doing this already. Signed-off-by: Daniel Leung <[email protected]>
Instead of putting object files inside libzephyr.a, simply build a separate static library as most other driver types are doing this already. Signed-off-by: Daniel Leung <[email protected]>
Instead of putting object files inside libzephyr.a, simply build a separate static library as most other driver types are doing this already. Signed-off-by: Daniel Leung <[email protected]>
Instead of putting object files inside libzephyr.a, simply build a separate static library as most other driver types are doing this already. Signed-off-by: Daniel Leung <[email protected]>
Instead of putting object files inside libzephyr.a, simply build a separate static library as most other driver types are doing this already. Signed-off-by: Daniel Leung <[email protected]>
Instead of putting object files inside libzephyr.a, simply build a separate static library as most other driver types are doing this already. Signed-off-by: Daniel Leung <[email protected]>
Instead of putting object files inside libzephyr.a, simply build a separate static library as most other driver types are doing this already. Signed-off-by: Daniel Leung <[email protected]>
Some display drivers may actually be initialized after LittlevGL as those drivers and LittlevGL's lvgl_init() all have SYS_INIT() at APPLICATION and init priority the same as application init priority. Depending on how the final binary is linked, these drivers may initialize after lvgl_init() resulting in it not able to find a display driver. This changes the value of CONFIG_DISPLAY_INIT_PRIORITY so that the display drivers that make use of this kconfig are initialized a bit earlier to ensure that they are actually initialized before lvgl_init(). Signed-off-by: Daniel Leung <[email protected]>
Instead of putting object files inside libzephyr.a, simply build a separate static library as most other driver types are doing this already. Also sort the entries alphabetically. Signed-off-by: Daniel Leung <[email protected]>
dcpleung
force-pushed
the
drivers_use_zephyr_library
branch
from
841660f to
2d4cefb
Compare
MaureenHelm
approved these changes
Aug 16, 2021
| @@ -237,6 +237,6 @@ static int arm64_smp_init(const struct device *dev) | |||
|
|
|||
| return 0; | |||
| } | |||
| SYS_INIT(arm64_smp_init, PRE_KERNEL_1, CONFIG_KERNEL_INIT_PRIORITY_DEFAULT); | |||
| SYS_INIT(arm64_smp_init, PRE_KERNEL_2, CONFIG_KERNEL_INIT_PRIORITY_DEFAULT); | |||
This was referenced Sep 9, 2021
tejlmand
added a commit
to tejlmand/zephyr
that referenced
this pull request
Sep 14, 2021
With the driver library cleanup in zephyrproject-rtos#37512 all drivers are now placed in dedicated zephyr libraries and not directly in libzephyr.a. This commit follows up on this by placing all pinmux.c files in a dedicated pinmux zephyr library. Signed-off-by: Torsten Rasmussen <[email protected]>
tejlmand
added a commit
to tejlmand/zephyr
that referenced
this pull request
Sep 14, 2021
With the driver library cleanup in zephyrproject-rtos#37512 all drivers are now placed in dedicated zephyr libraries and not directly in libzephyr.a. This commit follows up on this by placing all pinmux.c files in a dedicated pinmux zephyr library. Signed-off-by: Torsten Rasmussen <[email protected]>
tejlmand
added a commit
to tejlmand/zephyr
that referenced
this pull request
Sep 16, 2021
With the driver library cleanup in zephyrproject-rtos#37512 all drivers are now placed in dedicated zephyr libraries and not directly in libzephyr.a. This commit follows up on this by placing all pinmux.c files in a dedicated pinmux zephyr library. Signed-off-by: Torsten Rasmussen <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Most of the driver types are using
zephyr_library()andzephyr_library_sources*()already. This converts the remaining ones so driver builds are aligned. This avoids private include directories being spilled outside the driver build.