soc: nrf54h20: fix some power consumption issues by managing GD domains on certain scenarios #80291
Conversation
zephyrbot
added
area: GPIO
area: Pinctrl
area: Power Management
platform: nRF
zephyrbot
requested review from
JordanYates,
ceolin,
henrikbrixandersen,
jaz1-nordic,
kl-cruz,
magp-nordic,
masz-nordic,
mnkp,
nashif,
nika-nordic,
teburd and
tmleman
gmarull
changed the title
hubertmis
left a comment
hubertmis
left a comment
There was a problem hiding this comment.
I think we also need something in pinctrl similar to what is implemented in gpio_nrfx.c. We need to safely control fast pins when fast peripherals get deactivated. It requires GPIO RETAIN feature
drivers/gpio/gpio_nrfx.c
Outdated
There was a problem hiding this comment.
This retention bit still needs to be cleared again at some point when the pin is going back into active use either via the gpio peripheral or the peripheral owning the pin e.g. spim.
There was a problem hiding this comment.
Yes, the retention should be cleared between ret = nrf_gpd_request(NRF_GPD_FAST_ACTIVE1); gets applied and the first attempt to reconfigure pins (if (flags & GPIO_OUTPUT_INIT_HIGH) { nrf_gpio_port_out_set(cfg->port, BIT(pin));).
If pins are reconfigured in any other function in this module, it should handle retention in a similar way.
Add binding for Global Power Domain found in nRF54Hx SoCs. Signed-off-by: Gerard Marull-Paretas <[email protected]>
Add the global power domain entry. This domain is not memory-mapped but controlled using NRFS services. Signed-off-by: Gerard Marull-Paretas <[email protected]>
So that it can be used to manually control certain power domains. Signed-off-by: Gerard Marull-Paretas <[email protected]>
gmarull
dismissed stale reviews from karstenkoenig, bjarki-andreasen, and anangl
via
6cdd0e2
Add a new soc-level API that allows to manually request/release global power domains. Signed-off-by: Gerard Marull-Paretas <[email protected]>
This patch introduces a new flag to indicate if a peripheral belongs to FAST_ACTIVE1 domain. This way, pinctrl knows when to request the SLOW_ACTIVE domain (where CTRLSEL multiplexer resides). Signed-off-by: Gerard Marull-Paretas <[email protected]>
It is required for some pinctrl changes. Signed-off-by: Gerard Marull-Paretas <[email protected]>
This patch allows to _safely_ configure GPIO ports that have their pad on FAST_ACTIVE1 domain. Signed-off-by: Gerard Marull-Paretas <[email protected]>
So that we do not get false warnings about consistent spacing around '*'. Signed-off-by: Gerard Marull-Paretas <[email protected]>
This API needs to be called by FAST peripherals before/after disabling/enabling them. Signed-off-by: Gerard Marull-Paretas <[email protected]>
When GPD is managed by pinctrl, pins retention needs to be controlled by the driver to avoid glitches. Signed-off-by: Gerard Marull-Paretas <[email protected]>
It is enabled by default if we enable device PM, but we do not want this, otherwise we get linker errors (PM subsys, fun guaranteed!). Signed-off-by: Gerard Marull-Paretas <[email protected]>
hubertmis
left a comment
hubertmis
left a comment
There was a problem hiding this comment.
The GPIO IN is most probably not handled yet. But I think we can add it in a next PR.
drivers/gpio/gpio_nrfx.c
Outdated
There was a problem hiding this comment.
I'm not sure how RETAIN works with input pins. It's safer to apply it to output for now. We can figure out later how to correctly handle input
There was a problem hiding this comment.
I'm trying to figure out the power domain management required for the input pins.
It seems that gpio_nrfx_pin_interrupt_configure() should be enhanced:
If the
if (!(BIT(pin) & cfg->edge_sense) &&
(mode == GPIO_INT_MODE_EDGE) &&
(nrf_gpio_pin_dir_get(abs_pin) == NRF_GPIO_PIN_DIR_INPUT))
is met and the driver uses event IN, the relevant power domain should be kept powered up (nrf_gpd_request()). Alternatively, if the driver uses event SENSE, the GPIO.RETAIN should be applied to the pin (cfg->port->RETAINSET = mask).
However, I'm not sure in which procedure this configuration should be cleared. @nordic-krch, could you help to identify the correct place?
karstenkoenig
left a comment
karstenkoenig
left a comment
There was a problem hiding this comment.
This wouldn't work for pins defined as input on the fast ports, but that was broken before so probably easier to sort in follow up PR as suggest by Hubert to avoid complicating this any further
11 participants
This PR adds a new API to request/release GD domains, so that some identified issues can be handled.
WIP, subject to change. This also requires a new nrf-regtool release.