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.
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
Improve NXP CSI and MIPI_CSI2Rx drivers #76475
Improve NXP CSI and MIPI_CSI2Rx drivers #76475
Changes from all commits
31e9847
8507244
5af4c2b
ac2e131
36be625
95c31de
0732cf1
5a2ddea
e95d199
7528267
f4bb2da
9a61086
c957768
c9849af
aea820d
361c47f
d07370c
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
This file was deleted.
This file was deleted.
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.
Just to make sure I understand here, is the reason we want to use
remote-endpoint-label
overremote-endpoint
that it avoids the "chicken-and-egg" dependency problem we have with display and camera drivers? I primarily ask because this deviates from how Linux describes CSI devices in devicetree, right?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.
In this PR, we need the
video-interfaces
binding for the mipi csi2rx simply to be able to use thedata-lanes
property and for the ov5640 to be able to use thebus-type
(anddata-lanes
) property as the driver now supports both CSI2 and DVP modes. And thevideo-interfaces
binding requiresremote-endpoint-label
(required: true
) to be declared.If the question is for the
video-interfaces
binding (which is merged), replacingremote-endpoint
(phandle) byremote-endpoint-label
(string) is mandatory as we cannot introduce any binding forendpoint
without doing this because it simply does not compile (due to circular dependency).Apart from the above reason,
remote-endpoint-label
also helps to bypass the technical obstacle in Zephyr (circular dependency). My thinking is in the opposite, it helps to keep Zephyr does NOT deviates from Linux. As you can see in Linux, they don't directly reference the peer devices in DT with direct phandle like we did in Zephyr (with "source-dev
", "sensor-dev
", etc). All is done throughremote-endpoint
(some advantages : it's bidirectional, can connect elements at runtime, etc.). And now we can do the same in Zephyr withremote-endpoint-label
. Someday in the future, if Zephyr supports circular dependency, we can switch fromremote-endpoint-label
toremote-endpoint
easily as all the mechanisms will remain the same (it's much easier than the direct phandle reference withsource-dev
,sensor-dev
we did today).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.
This can be in the first commit where we touch the CSI file in this PR
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.
In fact, we touched the CSI driver several times in the past and I explictly added the NXP Copyright here when seeing that the driver is changed enough by NXP (although I don't know how much change is "enough" to add a copyright).