From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jorge Ramirez-Ortiz, Gmail Date: Fri, 17 Jan 2020 15:26:21 +0100 Subject: question: mx7ulp - LDO_ENABLED_MODE In-Reply-To: References: <20200116203000.GA21781@trex> Message-ID: <20200117142621.GB3054@trex> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de 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 > 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.