Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Shields: Allow shields conditional configuration #20934

Merged
merged 17 commits into from
Jan 2, 2020

Conversation

erwango
Copy link
Member

@erwango erwango commented Nov 22, 2019

Today shields Kconfig configuration (set of Kconfig symbols defined in <shield>_defconfig files) is applied unconditionally when a specific shield is selected by user (or indirectly in a sample/test via cmake configuration or with a yaml configuration when running sanitycheck).

This must be changed. Indeed, for application portability matter, board default configuration guidelines states that features activation is application responsibility and should not be done on board side (and shields are on board side).
This is applied for boards and should then be aslo applied for shields, so applications can rely on the fact that a HW component can be configured the same way, either it is directly available on the board or added via a shield.

To make shield conditional configuration possible:

  • Get cmake variable SHIELD_AS_LIST (user selection of shields) available in Kconfig
  • Set a SHIELD_MY_SHIELDX symbol, matching the state of user activation of my_shieldx in boards/shields/my_shieldx/Kconfig.shield
  • Parse newly created Kconfig.shield in boards/Kconfig (which by the way enable the selection of shields in menuconfig)
  • Set Kconfig shield configuration in Kconfig.defconfig under feature condition
  • Parse shields/boards/*.defconfig to get boards secific shields configuration scaling in this new scheme
  • Convert shields x_nucleo_idb05a1 and wnc_m14a2a to this new scheme. Eventually all shields will be converted as part of this PR if RFC get positive feedback.

EDIT: 11-27-19: Pushed a new version using a more readable Kconfig function (shields_list_contains)

EDIT: 12-10-19: Pushed a new version which updates all shields

TODO:

  • Complete shields convertion
  • Update shields documentation

Fixes #17310

@erwango erwango added RFC Request For Comments: want input from the community area: Kconfig area: Shields Shields (add-on boards) labels Nov 22, 2019
@erwango erwango added this to the v2.2.0 milestone Nov 22, 2019
@erwango erwango requested a review from dbkinder as a code owner November 22, 2019 10:14
@zephyrbot
Copy link
Collaborator

zephyrbot commented Nov 22, 2019

All checks are passing now.

Tip: The bot edits this comment instead of posting a new one, so you can check the comment's history to see earlier messages.

@jfischer-no jfischer-no self-requested a review November 22, 2019 10:37
@@ -22,6 +22,8 @@ endmenu
# Note: $ARCH and $BOARD_DIR might be glob patterns.
source "$(BOARD_DIR)/Kconfig.defconfig"

source "boards/shields/*/Kconfig.defconfig"
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Are the enabled shields known pre-Kconfig?

If so we want to limit the sourced files to just those enabled.

Copy link
Member Author

@erwango erwango Nov 22, 2019

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Are the enabled shields known pre-Kconfig?

Yes and no.
When running a west build command this is known... But user can modify shields selection using menuconfig.

If so we want to limit the sourced files to just those enabled.

If we do so (need to figure it out how, though), we prevent the ability to select shields in menuconfig.
So we need to chose between this and build performance (which, I guess, is your point).

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

But user can modify shields selection using menuconfig.

Never mind then, thank you for the explanation.

For example, we can get the default value for a Kconfig symbol
from the devicetree.
See the Python docstrings in ``scripts/kconfig/kconfigfunctions.py`` for more
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

OK for now, but we can also use the sphinx autodoc capabilities (as done for west).

Copy link
Contributor

@dbkinder dbkinder left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

OK on the docs, but we should take advantage of the sphinx autodoc capabilities (as done with west), to extract and process docstrings.

@@ -335,6 +335,15 @@ def dt_compat_enabled(kconf, _, compat):
return "n"


def cmake_in_list(kconf, _, elem, list):
Copy link
Collaborator

@ulfalizer ulfalizer Nov 22, 2019

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could call it in_cmake_list() maybe. I read cmake_in_list as "CMake is in the list" at first and was a bit confused.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I though about it, but finally opted to use cmake as namespace to follow logic used for other dt functions (dt_foo, ..).
Up to you!

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

How about cmake_list_contains?

Copy link
Collaborator

@ulfalizer ulfalizer left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

For def_bool stuff.

@erwango
Copy link
Member Author

erwango commented Nov 25, 2019

@ulfalizer, Thanks for the review. I've pushed a new version fixing the points you reported. About:

Could call it in_cmake_list() maybe. I read cmake_in_list as "CMake is in the list" at first and was a bit confused.

I answered, let me know what you prefer.

Copy link
Contributor

@mbolivar mbolivar left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks like a much better way to do this. +1 from me for the approach, nice work!

@@ -335,6 +335,15 @@ def dt_compat_enabled(kconf, _, compat):
return "n"


def cmake_in_list(kconf, _, elem, list):
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

How about cmake_list_contains?

@erwango
Copy link
Member Author

erwango commented Nov 26, 2019

@mbolivar, @ulfalizer, thanks for reviews. For the remaining controversial point, what about cmake_shields_list_contains (less generic, but clearer and cleaner) ? So in Kconfig.shields files we'll use :

config SHIELD_WNC_M14A2A
	bool "WNC-M14A2A LTE-M Modem"
	default $(cmake_shields_list_contains,wnc_m14a2a)

We can even drop the cmake and use:

	default $(shields_list_contains,wnc_m14a2a)

@mbolivar
Copy link
Contributor

Either cmake_shields_list_contains or shields_list_contains sounds good to me.

Add Kconfig.shield file for x_nucleo_iks01ax shields.

Signed-off-by: Erwan Gouriou <[email protected]>
@erwango
Copy link
Member Author

erwango commented Dec 16, 2019

@ulfalizer, can you review once more ?

Copy link
Collaborator

@jfischer-no jfischer-no left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks, just one comment.

default 250 if SHIELD_WAVESHARE_EPAPER_GDEH0213B72

config LVGL_VER_RES
default 128
Copy link
Collaborator

@jfischer-no jfischer-no Dec 16, 2019

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should be:

default 128 if SHIELD_WAVESHARE_EPAPER_GDEH029A1
default 120 if SHIELD_WAVESHARE_EPAPER_GDEH0213B1
default 120 if SHIELD_WAVESHARE_EPAPER_GDEH0213B72

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fixed, thanks

Move wavehare epaper shields to conditional Kconfig.
As part of this change, direct drivers Kconfig symbols enabling
(SPI, SSD16XX) are removed as they are application
responsibility. GPIO is removed as well as it should be 'y' by
default on  all boards according to Default board configuration
guidelines.

Signed-off-by: Erwan Gouriou <[email protected]>
Factorize definitions for ssd1306_128x32 and sd1306_128x64 shields
and move to conditional Kconfig.
As part of this change, direct drivers Kconfig symbols enabling
(I2C, SSD1306) are removed as they are application responsibility.
Also disabling SSD16XX is removed as SSD16XX should not be enabled
by default.

Signed-off-by: Erwan Gouriou <[email protected]>
Move sparkfun_sara_r4 to conditional Kconfig.
As part of this change, remove disco_l475_iot1 specific configuration
as it is already part of board default configuration.

Signed-off-by: Erwan Gouriou <[email protected]>
Move link_board_eth to conditional Kconfig.

Signed-off-by: Erwan Gouriou <[email protected]>
Move link_board_can to conditional Kconfig.
As part of this change, some board specific symbols are moved
to reel_board specific file.

Signed-off-by: Erwan Gouriou <[email protected]>
Add Kconfig.shield to frdm_kw41z.

Signed-off-by: Erwan Gouriou <[email protected]>
Move shield to Kconfig.shield format.

Signed-off-by: Erwan Gouriou <[email protected]>
Move dfrobot_can_bus_v2_0 to Kcondig.shield foramt and as part of
this change introduce nrf52_pca10040 board specific configuration.

Signed-off-by: Erwan Gouriou <[email protected]>
Move adafruit_2_8_tft_touch_v2 to Kconfig.defconfig format.
As part of this change Kconfig flags SPI and DISPLAY are removed
from the shield configuration as they are part of application
configuration.

Signed-off-by: Erwan Gouriou <[email protected]>
Update doc with new Kconfig.shield files.


Signed-off-by: Erwan Gouriou <[email protected]>
@erwango
Copy link
Member Author

erwango commented Dec 20, 2019

@ulfalizer, when you have some time, a new review would be welcome

Copy link
Collaborator

@ulfalizer ulfalizer left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Some nits.

Did you consider putting the shield stuff in the main board Kconfig.defconfig file by the way (e.g. after a # Shield configuration comment)? It's a bit confusing that we have so many Kconfig files.

@@ -23,6 +23,9 @@ source "$(BOARD_DIR)/Kconfig.board"

endchoice

# Parse shields references
# Don't do it as a menuconfig, as shield selection is a CMake feature.
rsource "shields/*/Kconfig.shield"
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

FWIW, I prefer source over rsource where rsource isn't needed, because it makes the path easier to grep for.

The globbing kinda breaks grepping already though.

# Copyright (c) 2019, NXP
# Copyright (c) 2019 Linaro Limited
# SPDX-License-Identifier: Apache-2.0
#
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Inconsistent header. Make it

# Copyright (c) 2019, NXP
# Copyright (c) 2019 Linaro Limited
# SPDX-License-Identifier: Apache-2.0

...

# Copyright (c) 2019 Linaro Limited
#
# SPDX-License-Identifier: Apache-2.0
#
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Make it

# Copyright (c) 2019, NXP
# Copyright (c) 2019 Linaro Limited
# SPDX-License-Identifier: Apache-2.0

# Copyright (c) 2019 Linaro Limited
#
# SPDX-License-Identifier: Apache-2.0
#
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ditto

@ulfalizer
Copy link
Collaborator

Also wondering if Kconfig.shield could be merged with the main board Kconfig file, to cut down on things a bit there.

@SebastianBoe
Copy link
Collaborator

SebastianBoe commented Dec 31, 2019

Also wondering if Kconfig.shield could be merged with the main board Kconfig file, to cut down on things a bit there.

Wouldn't that require O(boards*shields) snippets of shield code instead of O(shields) ?

@nashif nashif merged commit 9055cfe into zephyrproject-rtos:master Jan 2, 2020
vanwinkeljan added a commit to vanwinkeljan/zephyr that referenced this pull request Jan 4, 2020
Use conditional Kconfig, as introduced by PR zephyrproject-rtos#20934, for ST7789V
based shields.

Signed-off-by: Jan Van Winkel <[email protected]>
nashif pushed a commit that referenced this pull request Jan 6, 2020
Use conditional Kconfig, as introduced by PR #20934, for ST7789V
based shields.

Signed-off-by: Jan Van Winkel <[email protected]>
@erwango erwango deleted the shield_defKconfig branch January 27, 2022 13:39
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

boards: shields: use Kconfig.defconfig system for shields
10 participants