[RFC] Add mipi_dsi_detach API #64997
Merged
Conversation
This file contains hidden or 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
danieldegrasse
requested review from
MaureenHelm,
carlescufi,
dleach02,
erwango,
galak,
mmahadevan108 and
nashif
as code owners
zephyrbot
added
platform: NXP
zephyrbot
requested review from
DerekSnell,
EmilioCBen,
PetervdPerk-NXP,
bperseghetti,
dbaluta,
decsny,
manuargue and
yvanderv
gmarull
reviewed
Nov 9, 2023
Member
gmarull
left a comment
gmarull
left a comment
There was a problem hiding this comment.
API lgtm, no objections, just a nitpick. I haven't checked the PM part, as I no longer review PM related code.
soc/arm/nxp_imx/rt5xx/soc.c
Outdated
Contributor
Author
There was a problem hiding this comment.
This is following the pattern established in ca19b40. Since our clock management on these SOCs is currently so inflexible, the idea is that a customer board can bypass the clock setup entirely in their custom board if needed. I've done some initial work to attempt to correct this with #62946, but this is currently the short-term solution we're using for this SOC.
Member
There was a problem hiding this comment.
Ok, thanks for the attempt to fix this hack in #62946 :-)
Add MIPI DSI detach API. This API allows the DSI controller to detach from the DSI device, and power down the DSI PHY. The primary goal of this API is to provide power savings for DSI devices when the display they are driving is not active. Signed-off-by: Daniel DeGrasse <[email protected]>
Add support for mipi_dsi_detach API to dsi_mcux_2l driver, and update RT5xx SOC interface to enable halting clocks for the MIPI DPHY. Signed-off-by: Daniel DeGrasse <[email protected]>
Add device level power management to rm67162 display. Device level power management for this controller calls the MIPI DSI detach API, in order to power down the MIPI DPHY when the display is not active. Signed-off-by: Daniel DeGrasse <[email protected]>
Add support for low power mode on the G1120B0MIPI using the RT595. This configuration is tested via a testcase in samples/drivers/display, which should validate that the display can be driven by the RT595 when CONFIG_PM and CONFIG_PM_DEVICE are set. Signed-off-by: Daniel DeGrasse <[email protected]>
dleach02
approved these changes
Nov 13, 2023
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
5 participants
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.
This PR proposes a new
mipi_dsi_detachAPI for the MIPI subsystem, very similar to themipi_dsi_detachAPI currently present in Linux. The primary goal of this API is to provide power savings, by allowing the MIPI DPHY to power off when not in use. An implementation is provided for the DSI_MCUX_2L driver. Detaching the MIPI saves roughly 2mA of current consumption on the VDDCORE voltage rail in my tests.The PR also includes the following changes:
blanking_onandblanking_offfunctions for the display.An alternative to this approach would be to use device level runtime power management for the MIPI DSI driver. The reason I did not take this approach was that the display controller driver itself will likely have the best awareness of when the MIPI DSI can be detached and the DPHY can be powered down, so exposing the functionality to the display controller made the most sense