diff mbox series

[14/16] soc: imx: gpcv2: move reset assert after requesting domain power up

Message ID 20210429073050.21039-15-peng.fan@oss.nxp.com
State Superseded
Headers show
Series soc: imx: gpcv2: support i.MX8MM | expand

Commit Message

Peng Fan (OSS) April 29, 2021, 7:30 a.m. UTC
From: Peng Fan <peng.fan@nxp.com>


The i.MX8MM VPU power up sequence is a bit special, it must follow:
1. request power up
2. reset assert
3. reset deassert

This change in this patch will not affect other domains, because
the power domain default is in asserted state, unless bootloader
deassert the reset.

[Note: We expect bootloader leave the domain in asserted state,
but this may not always be true, so we might need another solution
to address the VPU domain requirements]

Signed-off-by: Peng Fan <peng.fan@nxp.com>

---
 drivers/soc/imx/gpcv2.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

-- 
2.30.0

Comments

Lucas Stach April 29, 2021, 2:28 p.m. UTC | #1
Am Donnerstag, dem 29.04.2021 um 15:30 +0800 schrieb Peng Fan (OSS):
> From: Peng Fan <peng.fan@nxp.com>

> 

> The i.MX8MM VPU power up sequence is a bit special, it must follow:

> 1. request power up

> 2. reset assert

> 3. reset deassert

> 

> This change in this patch will not affect other domains, because

> the power domain default is in asserted state, unless bootloader

> deassert the reset.

> 

> [Note: We expect bootloader leave the domain in asserted state,

> but this may not always be true, so we might need another solution

> to address the VPU domain requirements]


This is only about the VPU and GPU domain, where we need to handle the
SRC reset from the GPC driver right? In that case I think it's a sane
assumption that the bootloader does not touch those resets.

> Signed-off-by: Peng Fan <peng.fan@nxp.com>

> ---

>  drivers/soc/imx/gpcv2.c | 4 ++--

>  1 file changed, 2 insertions(+), 2 deletions(-)

> 

> diff --git a/drivers/soc/imx/gpcv2.c b/drivers/soc/imx/gpcv2.c

> index d2ce47a5ebad..072f519462a5 100644

> --- a/drivers/soc/imx/gpcv2.c

> +++ b/drivers/soc/imx/gpcv2.c

> @@ -217,8 +217,6 @@ static int imx_pgc_power_up(struct generic_pm_domain *genpd)

>  		goto out_regulator_disable;

>  	}

>  

> 

> 

> 

> 

> 

> 

> 

> -	reset_control_assert(domain->reset);

> -

>  	if (domain->bits.pxx) {

>  		/* request the domain to power up */

>  		regmap_update_bits(domain->regmap, GPC_PU_PGC_SW_PUP_REQ,

> @@ -241,6 +239,8 @@ static int imx_pgc_power_up(struct generic_pm_domain *genpd)

>  				   GPC_PGC_CTRL_PCR, 0);

>  	}

>  

> 

> 

> 

> 

> 

> 

> 

> +	reset_control_assert(domain->reset);

> +

>  	/* delay for reset to propagate */

>  	udelay(5);


As this is a pretty arbitrary delay added by me, can you please check
with the HW team or whoever knows, if this is sufficiently long for
both GPU and VPU domains?

Regards,
Lucas
Peng Fan (OSS) April 30, 2021, 4:51 a.m. UTC | #2
On 2021/4/29 22:28, Lucas Stach wrote:
> Am Donnerstag, dem 29.04.2021 um 15:30 +0800 schrieb Peng Fan (OSS):

>> From: Peng Fan <peng.fan@nxp.com>

>>

>> The i.MX8MM VPU power up sequence is a bit special, it must follow:

>> 1. request power up

>> 2. reset assert

>> 3. reset deassert

>>

>> This change in this patch will not affect other domains, because

>> the power domain default is in asserted state, unless bootloader

>> deassert the reset.

>>

>> [Note: We expect bootloader leave the domain in asserted state,

>> but this may not always be true, so we might need another solution

>> to address the VPU domain requirements]

> 

> This is only about the VPU and GPU domain, where we need to handle the

> SRC reset from the GPC driver right?


For GPU, I have not tried. From current ATF implementation, I think yes.

  In that case I think it's a sane
> assumption that the bootloader does not touch those resets.

> 

>> Signed-off-by: Peng Fan <peng.fan@nxp.com>

>> ---

>>   drivers/soc/imx/gpcv2.c | 4 ++--

>>   1 file changed, 2 insertions(+), 2 deletions(-)

>>

>> diff --git a/drivers/soc/imx/gpcv2.c b/drivers/soc/imx/gpcv2.c

>> index d2ce47a5ebad..072f519462a5 100644

>> --- a/drivers/soc/imx/gpcv2.c

>> +++ b/drivers/soc/imx/gpcv2.c

>> @@ -217,8 +217,6 @@ static int imx_pgc_power_up(struct generic_pm_domain *genpd)

>>   		goto out_regulator_disable;

>>   	}

>>   

>>

>>

>>

>>

>>

>>

>>

>> -	reset_control_assert(domain->reset);

>> -

>>   	if (domain->bits.pxx) {

>>   		/* request the domain to power up */

>>   		regmap_update_bits(domain->regmap, GPC_PU_PGC_SW_PUP_REQ,

>> @@ -241,6 +239,8 @@ static int imx_pgc_power_up(struct generic_pm_domain *genpd)

>>   				   GPC_PGC_CTRL_PCR, 0);

>>   	}

>>   

>>

>>

>>

>>

>>

>>

>>

>> +	reset_control_assert(domain->reset);

>> +

>>   	/* delay for reset to propagate */

>>   	udelay(5);

> 

> As this is a pretty arbitrary delay added by me, can you please check

> with the HW team or whoever knows, if this is sufficiently long for

> both GPU and VPU domains?


For VPU, from my test, it is enough. For GPU, ATF code use 10us, let me
try to enable GPU and do some test, I think 5us is long enough here.

Thanks,
Peng.

> 

> Regards,

> Lucas

>
diff mbox series

Patch

diff --git a/drivers/soc/imx/gpcv2.c b/drivers/soc/imx/gpcv2.c
index d2ce47a5ebad..072f519462a5 100644
--- a/drivers/soc/imx/gpcv2.c
+++ b/drivers/soc/imx/gpcv2.c
@@ -217,8 +217,6 @@  static int imx_pgc_power_up(struct generic_pm_domain *genpd)
 		goto out_regulator_disable;
 	}
 
-	reset_control_assert(domain->reset);
-
 	if (domain->bits.pxx) {
 		/* request the domain to power up */
 		regmap_update_bits(domain->regmap, GPC_PU_PGC_SW_PUP_REQ,
@@ -241,6 +239,8 @@  static int imx_pgc_power_up(struct generic_pm_domain *genpd)
 				   GPC_PGC_CTRL_PCR, 0);
 	}
 
+	reset_control_assert(domain->reset);
+
 	/* delay for reset to propagate */
 	udelay(5);