-
Notifications
You must be signed in to change notification settings - Fork 7.7k
Power domain: NRFS SWEXT driver #90754
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
base: main
Are you sure you want to change the base?
Power domain: NRFS SWEXT driver #90754
Conversation
afa9528
to
87e9f3a
Compare
f737ae0
to
8654ac9
Compare
|
||
dev_data->synced = true; | ||
|
||
if (dev_data->off) { |
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 expects domains to be by default requested after reset right? Can you leave a comment about this, otherwise it seems strange why you wouldn't just do unconditional manager_set_domain_locked(dev_config->domain, !dev_data->off);
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.
Yep, will leave a note about this :)
manager_lock(); | ||
|
||
if (dev_data->synced) { | ||
ret = manager_set_domain_locked(dev_config->domain, 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.
Why aren't you maintaining and comparing the state in domain_data.off? What happens if the power domain gets resumed multiple times or won't that happen?
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 off
variable is only used to track whether or not the power domain should be suspended once the kernel is ready to request power domain state change, once we can send requests, we request power domain off if off
is true, after that , we are "synced", so every resume and suspend will result in an actual request sent, so off
is no longer relevant :)
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.
Could you also leave a comment regarding this then? I kinda got this from reading the whole thing but feel it could be simplified but just saying its meant to track pre sync state.
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.
Didn't look at SWEXT changes, but the gpio port/pad power domain handling looks good.
Will this trigger more power domain requests/releases?
drivers/serial/uart_nrfx_uarte.c
Outdated
nrf_uarte_disable(get_uarte_instance(dev)); | ||
|
||
(void)pinctrl_apply_state(config->pcfg, PINCTRL_STATE_SLEEP); |
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.
Don't we need to move this up to avoid glitching the pin? Assuming UART tx is idle high then this might disable the uart (release pin from uart) and then drive it high here if PINCTRL_STATE_SLEEP is high
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, it shall be moved :)
95015ed
to
1de2f64
Compare
0bcedf6
to
14436f8
Compare
Introduce the NRFS GDPWR (Global Domain Power Request) device driver and devicetree binding. Signed-off-by: Bjarki Arge Andreasen <bjarki.andreasen@nordicsemi.no>
Introduce NRFS SWEXT (Switch External) device driver and devicetree binding. Signed-off-by: Bjarki Arge Andreasen <bjarki.andreasen@nordicsemi.no>
Introduce the NRF GPIO Pad Group device driver and binding. The pad group device represents the GPIO pads (pins), contrary to a GPIO controller, which is one of the many devices which can be muxed to pads in the pad group. The pad group belong to a power domain, which is not neccesarily the same power domain as devices being muxed to the pads, like GPIO or UART. If no ACTIVE device is using any of the pads in the pad group, the pad groups power domain may be SUSPENDED. Before the pad groups power domain is SUSPENDED, pad config retention must be enabled to prevent the pads from loosing their state. That's what this device driver manages. Once retained, the pad configs and outputs are locked, even when their power domain is SUSPENDED. Signed-off-by: Bjarki Arge Andreasen <bjarki.andreasen@nordicsemi.no>
9163316
to
126e8cb
Compare
Transition nrf54h away from the soc specific gpd (global power domain) driver which mixed power domains, pinctrl and gpio pin retention into a non scalable solution, forcing soc specific logic to bleed into nrf drivers. The new solution uses zephyrs PM_DEVICE based power domains to properly model the hardware layout of device and pin power domains, and moves pin retention logic out of drivers into pinctrl and gpio, which are the components which manage pins (pads). Signed-off-by: Bjarki Arge Andreasen <bjarki.andreasen@nordicsemi.no>
Remove the deprecated GPD (Global Power Domain) driver. Signed-off-by: Bjarki Arge Andreasen <bjarki.andreasen@nordicsemi.no>
126e8cb
to
3e4dca4
Compare
Update manifest to include changes which align mcuboot with the nrf54 power domain refactor. Signed-off-by: Bjarki Arge Andreasen <bjarki.andreasen@nordicsemi.no>
The following west manifest projects have changed revision in this Pull Request:
⛔ DNM label due to: 1 project with PR revision Note: This message is automatically posted and updated by the Manifest GitHub Action. |
|
Add driver for NRFS SWEXT power domain device.