diff mbox series

question: mx7ulp - LDO_ENABLED_MODE

Message ID CAOMZO5BREwtHueLTzgZ=rsr+odxBVZDtfYf-F_KYi+HqK3pDjg@mail.gmail.com
State New
Headers show
Series question: mx7ulp - LDO_ENABLED_MODE | expand

Commit Message

Fabio Estevam Jan. 17, 2020, 1:26 p.m. UTC
Hi Jorge,

On Thu, Jan 16, 2020 at 5:30 PM Jorge Ramirez-Ortiz, Foundries
<jorge at foundries.io> wrote:
>
> Hi Fabio,
>
> I am trying to enable LDO in an imx7ulp based board but somehow the
> board locks up as soon I  write to PMC1_RUN (using the init_ldo_mode
> sequence).
>
> I think it is interesting that bit PMC0_CTRL_PMC1ON is already set so
> I am wondering if you think it is possible - in your experience- that
> ROM might have already configured LDO? or was this also the case -
> this bit already set- when you tested the feature?
>
> I also noticed that if I dont execute the init_ldo_mode sequence and
> just check for the LODEN bit [see snipet below], this is already set
> which too seems strange.

On a i.MX7ULP Embedded Artists board I noticed that LDOEN bit comes
set after POR too.

Should we do something like this to avoid re-initializing the PMC1?

Comments

Jorge Ramirez-Ortiz, Gmail Jan. 17, 2020, 2:26 p.m. UTC | #1
On 17/01/20 10:26:11, Fabio Estevam wrote:
> Hi Jorge,
> 
> On Thu, Jan 16, 2020 at 5:30 PM Jorge Ramirez-Ortiz, Foundries
> <jorge at foundries.io> wrote:
> >
> > Hi Fabio,
> >
> > I am trying to enable LDO in an imx7ulp based board but somehow the
> > board locks up as soon I  write to PMC1_RUN (using the init_ldo_mode
> > sequence).
> >
> > I think it is interesting that bit PMC0_CTRL_PMC1ON is already set so
> > I am wondering if you think it is possible - in your experience- that
> > ROM might have already configured LDO? or was this also the case -
> > this bit already set- when you tested the feature?
> >
> > I also noticed that if I dont execute the init_ldo_mode sequence and
> > just check for the LODEN bit [see snipet below], this is already set
> > which too seems strange.
> 
> On a i.MX7ULP Embedded Artists board I noticed that LDOEN bit comes
> set after POR too.
> 
> Should we do something like this to avoid re-initializing the PMC1?
> 
> --- a/arch/arm/mach-imx/mx7ulp/soc.c
> +++ b/arch/arm/mach-imx/mx7ulp/soc.c
> @@ -122,6 +122,9 @@ static void init_ldo_mode(void)
>  {
>         unsigned int reg;
> 
> +       if (ldo_mode_is_enabled())
> +               return;
> +
>         /* Set LDOOKDIS */
>         setbits_le32(PMC0_BASE_ADDR + PMC0_CTRL, PMC0_CTRL_LDOOKDIS);

not sure about this but I guess it makes sense (btw have you checked in your boards if the init_ldo_mode code executes all the write steps?)

when I check the voltage configuration for PMC1_RUN it does not show 0.95V but the default (1.0V - ie: 0x28 at offset 0x08 bits 21-16).
I still havent figured out who might be configuring/enabling it for the A7 though.
Jorge Ramirez-Ortiz, Gmail Jan. 17, 2020, 4:51 p.m. UTC | #2
On 17/01/20 10:26:11, Fabio Estevam wrote:
> Hi Jorge,
> 
> On Thu, Jan 16, 2020 at 5:30 PM Jorge Ramirez-Ortiz, Foundries
> <jorge at foundries.io> wrote:
> >
> > Hi Fabio,
> >
> > I am trying to enable LDO in an imx7ulp based board but somehow the
> > board locks up as soon I  write to PMC1_RUN (using the init_ldo_mode
> > sequence).
> >
> > I think it is interesting that bit PMC0_CTRL_PMC1ON is already set so
> > I am wondering if you think it is possible - in your experience- that
> > ROM might have already configured LDO? or was this also the case -
> > this bit already set- when you tested the feature?
> >
> > I also noticed that if I dont execute the init_ldo_mode sequence and
> > just check for the LODEN bit [see snipet below], this is already set
> > which too seems strange.
> 
> On a i.MX7ULP Embedded Artists board I noticed that LDOEN bit comes
> set after POR too.
> 
> Should we do something like this to avoid re-initializing the PMC1?
> 
> --- a/arch/arm/mach-imx/mx7ulp/soc.c
> +++ b/arch/arm/mach-imx/mx7ulp/soc.c
> @@ -122,6 +122,9 @@ static void init_ldo_mode(void)
>  {
>         unsigned int reg;
> 
> +       if (ldo_mode_is_enabled())
> +               return;
> +
>         /* Set LDOOKDIS */
>         setbits_le32(PMC0_BASE_ADDR + PMC0_CTRL, PMC0_CTRL_LDOOKDIS);

btw was checking the TRM manual (Chapter 28, PMC - page 1172)

[..]
PMC1 power mode[LDOVL] fields don’t necessarily satisfy the operation voltage levels
required by the system. Such operation voltage requirements can be found on i.MX 7ULP
Data Sheet. In this sense, no power transition should be performed before ensuring the
mentioned register fields are matching the required operation voltage levels expressed on
the data sheet.

=>  0.95V in the ldt_init function, is it in the data sheet?
I just cant find that particular document
Fabio Estevam Jan. 17, 2020, 5:18 p.m. UTC | #3
On Fri, Jan 17, 2020 at 1:51 PM Jorge Ramirez-Ortiz, Gmail
<jorge.ramirez.ortiz at gmail.com> wrote:

> btw was checking the TRM manual (Chapter 28, PMC - page 1172)
>
> [..]
> PMC1 power mode[LDOVL] fields don’t necessarily satisfy the operation voltage levels
> required by the system. Such operation voltage requirements can be found on i.MX 7ULP
> Data Sheet. In this sense, no power transition should be performed before ensuring the
> mentioned register fields are matching the required operation voltage levels expressed on
> the data sheet.
>
> =>  0.95V in the ldt_init function, is it in the data sheet?
> I just cant find that particular document

Yes, please take a look at https://www.nxp.com/docs/en/data-sheet/IMX7ULPCEC.pdf

(Table 5 - Search for PMC1_STOP[LDOVL] where it shows 0.95V as the
typical value)
Jorge Ramirez-Ortiz, Gmail Jan. 17, 2020, 6:40 p.m. UTC | #4
On 17/01/20 14:18:55, Fabio Estevam wrote:
> On Fri, Jan 17, 2020 at 1:51 PM Jorge Ramirez-Ortiz, Gmail
> <jorge.ramirez.ortiz at gmail.com> wrote:
> 
> > btw was checking the TRM manual (Chapter 28, PMC - page 1172)
> >
> > [..]
> > PMC1 power mode[LDOVL] fields don’t necessarily satisfy the operation voltage levels
> > required by the system. Such operation voltage requirements can be found on i.MX 7ULP
> > Data Sheet. In this sense, no power transition should be performed before ensuring the
> > mentioned register fields are matching the required operation voltage levels expressed on
> > the data sheet.
> >
> > =>  0.95V in the ldt_init function, is it in the data sheet?
> > I just cant find that particular document
> 
> Yes, please take a look at https://www.nxp.com/docs/en/data-sheet/IMX7ULPCEC.pdf
> 
> (Table 5 - Search for PMC1_STOP[LDOVL] where it shows 0.95V as the
> typical value)

thanks a lot Favio. The part I am working with is 08SC. (not 05 or 07).
Is that the same as yours?

wondering if something is different for this part...
Fabio Estevam Jan. 17, 2020, 6:53 p.m. UTC | #5
On Fri, Jan 17, 2020 at 3:40 PM Jorge Ramirez-Ortiz, Gmail
<jorge.ramirez.ortiz at gmail.com> wrote:

> thanks a lot Favio. The part I am working with is 08SC. (not 05 or 07).
> Is that the same as yours?

On the Embedded Artists board there is a 08SC i.MX7ULP version.

On the i.MX7ULP EVK that I have access to there is a 05SC.

On the 08SC part I do see that it comes with LDOEN turned on by default.

On the 05SC part it comes with LDOEN turned off by default.

I wondering if we should go ahead with this fix:
http://code.bulix.org/5gfb8t-1094747

In case LDO is already enabled, then we use the LDO settings that were
configured by the ROM.

Does this fix the hang problem?
Jorge Ramirez-Ortiz, Gmail Jan. 17, 2020, 7:02 p.m. UTC | #6
On 17/01/20 15:53:28, Fabio Estevam wrote:
> On Fri, Jan 17, 2020 at 3:40 PM Jorge Ramirez-Ortiz, Gmail
> <jorge.ramirez.ortiz at gmail.com> wrote:
> 
> > thanks a lot Favio. The part I am working with is 08SC. (not 05 or 07).
> > Is that the same as yours?
> 
> On the Embedded Artists board there is a 08SC i.MX7ULP version.
> 
> On the i.MX7ULP EVK that I have access to there is a 05SC.
> 
> On the 08SC part I do see that it comes with LDOEN turned on by default.
> 
> On the 05SC part it comes with LDOEN turned off by default.
> 
> I wondering if we should go ahead with this fix:
> http://code.bulix.org/5gfb8t-1094747

yes I think so.

> 
> In case LDO is already enabled, then we use the LDO settings that were
> configured by the ROM.

yeah sounds good to me. I triple check in case the M4 was setting the
LDO (who knows) but is not being done by my firmware. So it must be
the ROM

> 
> Does this fix the hang problem?

yes
diff mbox series

Patch

--- a/arch/arm/mach-imx/mx7ulp/soc.c
+++ b/arch/arm/mach-imx/mx7ulp/soc.c
@@ -122,6 +122,9 @@  static void init_ldo_mode(void)
 {
        unsigned int reg;

+       if (ldo_mode_is_enabled())
+               return;
+
        /* Set LDOOKDIS */
        setbits_le32(PMC0_BASE_ADDR + PMC0_CTRL, PMC0_CTRL_LDOOKDIS);