From patchwork Fri Jan 17 13:26:11 2020
Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
X-Patchwork-Submitter: Fabio Estevam <festevam@gmail.com>
X-Patchwork-Id: 239739
List-Id: U-Boot discussion <u-boot.lists.denx.de>
From: festevam at gmail.com (Fabio Estevam)
Date: Fri, 17 Jan 2020 10:26:11 -0300
Subject: question: mx7ulp - LDO_ENABLED_MODE
In-Reply-To: <20200116203000.GA21781@trex>
References: <20200116203000.GA21781@trex>
Message-ID: <CAOMZO5BREwtHueLTzgZ=rsr+odxBVZDtfYf-F_KYi+HqK3pDjg@mail.gmail.com>

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);