doc: extensions: boards: add ability to filter by hw capability #79754
Conversation
kartben
force-pushed
the
boards_filter_by_hw
branch
from
ca41f37 to
a399197
Compare
kartben
added
area: Boards
area: Documentation
area: DX
kartben
force-pushed
the
boards_filter_by_hw
branch
6 times, most recently
from
c5548a4 to
fb91d15
Compare
kartben
force-pushed
the
boards_filter_by_hw
branch
11 times, most recently
from
bfe774d to
413b7f1
Compare
| "watchdog": nodes.Text("Watchdog"), | ||
| "wifi": nodes.Text("Wi-Fi"), | ||
| "xen": nodes.Text("Xen"), | ||
| "xspi": nodes.abbreviation("XSPI", "XSPI", explanation="Expanded Serial Peripheral Interface"), |
There was a problem hiding this comment.
This large sorted list with some multiline blocks was the inspiration for #80444
Only check lines that match a regex, for example:
# zephyr-keep-sorted-start /^ "/
# ...
# zephyr-keep-sorted-stopThere was a problem hiding this comment.
Ahah yes, if this stays I will definitely flag it with the tags, thanks!
Right now I am actually very much interested in --although of course PR is still in draft, ... but since you're here 😄-- figuring out what makes for a "good" categorization of the supported HW feature. As you may have seen from the current implementation, this is making every directory under dts/bindings/ a category, but having ~120 categories doesn't seem right and there's probably a better way? Maybe we keep the approach but do some addition grouping? Like, dunno, off the top of my head, grouping fuel-gauge and battery ("Battery mgmt"), or usb and usb-c (USB), ... together ?
There was a problem hiding this comment.
Oopf, 120 is a lot, I think grouping would make sense, also to have some better names than for example mm.
kartben
force-pushed
the
boards_filter_by_hw
branch
from
413b7f1 to
606f465
Compare
kartben
force-pushed
the
boards_filter_by_hw
branch
2 times, most recently
from
ef845e8 to
05dd7ba
Compare
kartben
force-pushed
the
boards_filter_by_hw
branch
from
05dd7ba to
1103560
Compare
|
@kartben Would it be possible to add a way to see what features are supported for a given SoC series ? |
kartben
force-pushed
the
boards_filter_by_hw
branch
from
1103560 to
0b97af2
Compare
kartben
changed the title
kartben
force-pushed
the
boards_filter_by_hw
branch
2 times, most recently
from
612e066 to
0a61630
Compare
kartben
force-pushed
the
boards_filter_by_hw
branch
2 times, most recently
from
580d20a to
38cad6f
Compare
It is possible to fit the Hello World in 2K of RAM so update the sample.yaml file accordingly. It might not *run*, but then the console harness will catch that. Signed-off-by: Benjamin Cabé <benjamin@zephyrproject.org>
PoC for now Signed-off-by: Benjamin Cabé <benjamin@zephyrproject.org>
This is meant to be a PoC and will eventually be replaced with `.. zephyr:board-supported-features::` or something similar. Signed-off-by: Benjamin Cabé <benjamin@zephyrproject.org>
There is no such thing as associating a compatible to a child binding so remove this from the nxp,dmic binding definition and devicetree files that incorrectly set one. Signed-off-by: Benjamin Cabé <benjamin@zephyrproject.org>
kartben
force-pushed
the
boards_filter_by_hw
branch
from
38cad6f to
b387ef6
Compare
WIP - board catalog is pre-computed for the sake of showing off the UI/UX early before the full CI job is in place, so don't mind the ginormous yaml file in one of the commits, it will eventually be generated on the fly (ask Twister to build hello world sample for all boards --> extract supported features from generated zephyr.dts for each board --> generate relevant metadata for enabling search by feature in catalog and generating table in board's readme --> profit).