-
Notifications
You must be signed in to change notification settings - Fork 7k
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
Add dts yaml support for same sensor on i2c or spi #11854
Changes from all commits
de4cffe
2524232
7a55bb2
ad40a6c
126a64f
b780774
4d08522
867c33e
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -19,11 +19,10 @@ class DTClocks(DTDirective): | |
def __init__(self): | ||
pass | ||
|
||
def _extract_consumer(self, node_address, yaml, clocks, def_label): | ||
def _extract_consumer(self, node_address, clocks, def_label): | ||
|
||
clock_consumer = reduced[node_address] | ||
clock_consumer_compat = get_compat(node_address) | ||
clock_consumer_bindings = yaml[clock_consumer_compat] | ||
clock_consumer_bindings = get_binding(node_address) | ||
clock_consumer_label = 'DT_' + get_node_label(node_address) | ||
|
||
clock_index = 0 | ||
|
@@ -42,8 +41,8 @@ def _extract_consumer(self, node_address, yaml, clocks, def_label): | |
str(clock_provider))) | ||
clock_provider_node_address = phandles[cell] | ||
clock_provider = reduced[clock_provider_node_address] | ||
clock_provider_compat = get_compat(clock_provider_node_address) | ||
clock_provider_bindings = yaml[clock_provider_compat] | ||
clock_provider_bindings = get_binding( | ||
clock_provider_node_address) | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Off topic but this sort of thing strengthens my belief that a strict 80-character limit on line length is decreasing code clarity more than increasing it. Especially when EOL escapes used to meet the requirement aren't consistent (see next line). There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. The 80 char limit is not enforced. |
||
clock_provider_label = get_node_label( \ | ||
clock_provider_node_address) | ||
nr_clock_cells = int(clock_provider['props'].get( | ||
|
@@ -86,7 +85,6 @@ def _extract_consumer(self, node_address, yaml, clocks, def_label): | |
if clock_cells_string == clock_cell_name: | ||
add_prop_aliases( | ||
node_address, | ||
yaml, | ||
lambda alias: | ||
self.get_label_string([ | ||
alias, | ||
|
@@ -97,7 +95,6 @@ def _extract_consumer(self, node_address, yaml, clocks, def_label): | |
else: | ||
add_prop_aliases( | ||
node_address, | ||
yaml, | ||
lambda alias: | ||
self.get_label_string([ | ||
alias, | ||
|
@@ -138,7 +135,6 @@ def _extract_consumer(self, node_address, yaml, clocks, def_label): | |
if node_address in aliases: | ||
add_prop_aliases( | ||
node_address, | ||
yaml, | ||
lambda alias: | ||
self.get_label_string([ | ||
alias, | ||
|
@@ -156,11 +152,10 @@ def _extract_consumer(self, node_address, yaml, clocks, def_label): | |
# @brief Extract clocks related directives | ||
# | ||
# @param node_address Address of node owning the clockxxx definition. | ||
# @param yaml YAML definition for the owning node. | ||
# @param prop clockxxx property name | ||
# @param def_label Define label string of node owning the directive. | ||
# | ||
def extract(self, node_address, yaml, prop, def_label): | ||
def extract(self, node_address, prop, def_label): | ||
|
||
properties = reduced[node_address]['props'][prop] | ||
|
||
|
@@ -172,7 +167,7 @@ def extract(self, node_address, yaml, prop, def_label): | |
|
||
if prop == 'clocks': | ||
# indicator for clock consumers | ||
self._extract_consumer(node_address, yaml, prop_list, def_label) | ||
self._extract_consumer(node_address, prop_list, def_label) | ||
else: | ||
raise Exception( | ||
"DTClocks.extract called with unexpected directive ({})." | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
IIUC, this whole change allows to have these bus related properties documented by the binding depending on the bus. Is that compatible with device tree usage in eg Linux?
I'm still not convinced how this would work at driver level. To me we should be able to build matching sensor driver using "compatible".
When "compatible" carried SPI/I2C inforamtion, we could have used #idef DT_COMPAT_ST_LSM6DL_SPI / DT_COMPAT_ST_LSM6DL_I2C to know if driver should be compiled with SPI or I2C fields.
Now this information is no more present we'll need to have a new piece of info to know how to build the driver with fields matching the bus.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actually in both cases the driver (e.g. LSM6DSL in this case) needs an extra configuration
parameter, say LSM6DSL_BUS_TYPE, to select spi/i2c bus case. The changes introduced
by @galak are somehow a cleaner solution, but what we would need instead is a way to
extract the bus type from the dts w/o the need for such configuration parameter.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
but then it should be available as a compilation input, not as a configuration input.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The bus type can be inferred by looking at the parent node, and the tooling generate the appropriate flags. The BME280 supports SPI and I2C, and the Linux binding documentation doesn't represent which is being used: it just provides two drivers, each of which are compatible with
bosch,bme280
.The inference would be simplified by marking all I2C bus nodes as compatible with
zephyr,i2c
and similarly for other generic Zephyr drivers. This is something I'd like done regardless.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, if you look at how various sensor drivers in linux you'll see they use the same compatible regardless of what bus the device is on.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't see us ever doing this, as we should be aiming for the device tree's to have less zephyr specific details not more. The intent would be to know that a bus is I2C or SPI via the binding YAML info.