Re: [PATCH] poplar: add myself as co-maintainer
On 03/02/24 17:45:42, Yang Xiwen wrote: > On 2/3/2024 4:32 PM, Jorge Ramirez-Ortiz, Gmail wrote: > > On 03/02/24 07:54:22, Shawn Guo wrote: > > > On Sat, Feb 3, 2024 at 5:44 AM Igor Opaniuk > > > wrote: > > > > > > > > Add myself as co-maintainer for Poplar board, as I'm currently > > > > working on it (re-testing releases, addressing issues etc). > > > > > > > > CC: Jorge Ramirez-Ortiz > > > > CC: Shawn Guo > > > > Signed-off-by: Igor Opaniuk > > > > > > Acked-by: Shawn Guo > > > > > > I'm not actively working on poplar any more, so maybe remove me in the > > > meantime. > > > > > > hi Igor, > > > > Yes please go ahead and thanks for offering. > > > > I'll sync with you later next week (I found my Poplar in storage, so maybe > > we cam improve things a little) > > Also it would be good if we knew there are still users. > > > > > > Acked-by: Jorge Ramirez-Ortiz > > > Hi, everyone. I'm working on a set-top box with a Hi3798MV200 SoC. It is > very similar to the Hi3798CV200 SoC and many peripherals and drivers can be > reused. I think you can try moving arch/arm/include/asm/arch-hi3798cv200 to > arch/arm/mach-histb and let's maintain all HiSTB series SoCs/boards under it > altogether? The same thing also applies to TF-A. Currently upstream code > refers to poplar everywhere but actually the port is portable enough to > handle a lot of other Hi3798-series SoCs such as Hi3798MV2x, Hi3798MV3x > etc.. Sure, if this is indeed a family we should do that (documentation was scarce back them when I did the initial port). maybe you'd like to take a stab Igor? > > > > > > Shawn >
Re: [PATCH] poplar: add myself as co-maintainer
On 03/02/24 07:54:22, Shawn Guo wrote: > On Sat, Feb 3, 2024 at 5:44 AM Igor Opaniuk wrote: > > > > Add myself as co-maintainer for Poplar board, as I'm currently > > working on it (re-testing releases, addressing issues etc). > > > > CC: Jorge Ramirez-Ortiz > > CC: Shawn Guo > > Signed-off-by: Igor Opaniuk > > Acked-by: Shawn Guo > > I'm not actively working on poplar any more, so maybe remove me in the > meantime. hi Igor, Yes please go ahead and thanks for offering. I'll sync with you later next week (I found my Poplar in storage, so maybe we cam improve things a little) Also it would be good if we knew there are still users. Acked-by: Jorge Ramirez-Ortiz > > Shawn
Re: [PATCH] arm: mach-snapdragon: pinctrl: Place pin_name in .data section
On 15/07/21, Jorge Ramirez-Ortiz, Gmail wrote: > On 06/07/21, Ramon Fried wrote: > > On Mon, Jul 5, 2021 at 3:19 PM Stephan Gerhold wrote: > > > > > > According to arch/arm/lib/crt0_64.S, the BSS section is "UNAVAILABLE" > > > and uninitialized before relocation. Also, it overlaps with the > > > appended DTB before relocation, so writing data into a variable > > > in the BSS section might corrupt the appended DTB. > > > > > > Unfortunately, pinctrl-apq8016.c and pinctrl-apq8096.c do place the > > > "pin_name" variable in the BSS section (since it's uninitialized). > > > It's also used before relocation, when setting up the pinctrl for > > > the serial driver. > > > > > > On DB410c this causes "GPIO_5" to be written into some part of an > > > appended DTB, e.g.: > > > > > > 80111820: edfe0dd0 9f10 3800 c00e...8 > > > 80111830: 2800 1100 1000 ...( > > > 80111840: 4f495047 8800355f GPIO_5.. > > > 80111850: 0100 > > > 80111860: 0300 0400 0200 > > > 80111870: 0300 0400 0f00 0200 > > > 80111880: 0300 2d00 1b00 6c617551...-Qual > > > 80111890: 6d6d6f63 63655420 6c6f6e68 6569676fcomm Technologie > > > > > > Depending on the part of the DTB that is corrupted this might not > > > cause any problems, but it can also result in strange reboots > > > without any serial output. > > > > > > Fortunately, in practice this does not cause issues on DB410c yet > > > because board_fdt_blob_setup() in dragonboard410c.c currently > > > overrides the appended DTB with the one passed by the previous > > > bootloader (LK) (which does not get corrupted). > > > > > > DB820c does not have board_fdt_blob_setup() so I would expect it to > > > be affected by this problem. Perhaps everyone was just fortunate to > > > not compile an U-Boot configuration where the pin_name corrupts an > > > important part of the DTB. > > I'll try to confirm during the week. > > After Ramon's pinctrl changes db820c did indeed break - was able to > test a few months back- but we didnt have a board to test back then > (and nobody complained) > > will come back to you on this but from what you are saying, this is > probably the fix we needed for db820c yep, all good. just tested it. thanks for the fix! U-Boot 2021.07-00467-gc11f5abce8 (Jul 15 2021 - 09:20:22 +0200) Qualcomm-DragonBoard 820C DRAM: 3 GiB PSCI: v1.0 MMC: sdhci@74a4900: 0 Loading Environment from EXT4... MMC: no card present In:serial@75b Out: serial@75b Err: serial@75b Net: Net Initialization Skipped No ethernet found. Hit any key to stop autoboot: 0 MMC: no card present dragonboard820c => dragonboard820c => bdinfo boot_params = 0x DRAM bank = 0x -> start= 0x8000 -> size = 0x6000 DRAM bank = 0x0001 -> start= 0x0001 -> size = 0x5ea4 flashstart = 0x flashsize = 0x flashoffset = 0x baudrate= 115200 bps relocaddr = 0x00013ff7 reloc off = 0xbfef Build = 64-bit current eth = unknown ethaddr = (not set) IP addr = fdt_blob= 0x00013f7673c0 new_fdt = 0x00013f7673c0 fdt_size= 0x0a20 lmb_dump_al
Re: [PATCH] arm: mach-snapdragon: pinctrl: Place pin_name in .data section
On 06/07/21, Ramon Fried wrote:
> On Mon, Jul 5, 2021 at 3:19 PM Stephan Gerhold wrote:
> >
> > According to arch/arm/lib/crt0_64.S, the BSS section is "UNAVAILABLE"
> > and uninitialized before relocation. Also, it overlaps with the
> > appended DTB before relocation, so writing data into a variable
> > in the BSS section might corrupt the appended DTB.
> >
> > Unfortunately, pinctrl-apq8016.c and pinctrl-apq8096.c do place the
> > "pin_name" variable in the BSS section (since it's uninitialized).
> > It's also used before relocation, when setting up the pinctrl for
> > the serial driver.
> >
> > On DB410c this causes "GPIO_5" to be written into some part of an
> > appended DTB, e.g.:
> >
> > 80111820: edfe0dd0 9f10 3800 c00e...8
> > 80111830: 2800 1100 1000 ...(
> > 80111840: 4f495047 8800355f GPIO_5..
> > 80111850: 0100
> > 80111860: 0300 0400 0200
> > 80111870: 0300 0400 0f00 0200
> > 80111880: 0300 2d00 1b00 6c617551...-Qual
> > 80111890: 6d6d6f63 63655420 6c6f6e68 6569676fcomm Technologie
> >
> > Depending on the part of the DTB that is corrupted this might not
> > cause any problems, but it can also result in strange reboots
> > without any serial output.
> >
> > Fortunately, in practice this does not cause issues on DB410c yet
> > because board_fdt_blob_setup() in dragonboard410c.c currently
> > overrides the appended DTB with the one passed by the previous
> > bootloader (LK) (which does not get corrupted).
> >
> > DB820c does not have board_fdt_blob_setup() so I would expect it to
> > be affected by this problem. Perhaps everyone was just fortunate to
> > not compile an U-Boot configuration where the pin_name corrupts an
> > important part of the DTB.
I'll try to confirm during the week.
After Ramon's pinctrl changes db820c did indeed break - was able to
test a few months back- but we didnt have a board to test back then
(and nobody complained)
will come back to you on this but from what you are saying, this is
probably the fix we needed for db820c
> >
> > Make sure "pin_name" is explicitly placed in the .data section
> > instead of .bss to fix this.
> >
> > Cc: Ramon Fried
> > Signed-off-by: Stephan Gerhold
> > ---
> >
> > arch/arm/mach-snapdragon/pinctrl-apq8016.c | 3 +--
> > arch/arm/mach-snapdragon/pinctrl-apq8096.c | 2 +-
> > 2 files changed, 2 insertions(+), 3 deletions(-)
> >
> > diff --git a/arch/arm/mach-snapdragon/pinctrl-apq8016.c
> > b/arch/arm/mach-snapdragon/pinctrl-apq8016.c
> > index 1042b564c3..70c0be0bca 100644
> > --- a/arch/arm/mach-snapdragon/pinctrl-apq8016.c
> > +++ b/arch/arm/mach-snapdragon/pinctrl-apq8016.c
> > @@ -10,7 +10,7 @@
> > #include
> >
> > #define MAX_PIN_NAME_LEN 32
> > -static char pin_name[MAX_PIN_NAME_LEN];
> > +static char pin_name[MAX_PIN_NAME_LEN] __section(".data");
> > static const char * const msm_pinctrl_pins[] = {
> > "SDC1_CLK",
> > "SDC1_CMD",
> > @@ -59,4 +59,3 @@ struct msm_pinctrl_data apq8016_data = {
> > .get_function_mux = apq8016_get_function_mux,
> > .get_pin_name = apq8016_get_pin_name,
> > };
> > -
> > diff --git a/arch/arm/mach-snapdragon/pinctrl-apq8096.c
> > b/arch/arm/mach-snapdragon/pinctrl-apq8096.c
> > index 20a71c319b..45462f01c2 100644
> > --- a/arch/arm/mach-snapdragon/pinctrl-apq8096.c
> > +++ b/arch/arm/mach-snapdragon/pinctrl-apq8096.c
> > @@ -10,7 +10,7 @@
> > #include
> >
> > #define MAX_PIN_NAME_LEN 32
> > -static char pin_name[MAX_PIN_NAME_LEN];
> > +static char pin_name[MAX_PIN_NAME_LEN] __section(".data");
> > static const char * const msm_pinctrl_pins[] = {
> > "SDC1_CLK",
> > "SDC1_CMD",
> > --
> > 2.32.0
> >
> Reviewed-by: Ramon Fried
Re: [PATCH] drivers: tpm2: update reset gpio semantics
On 27/05/21, Simon Glass wrote: > On Wed, 26 May 2021 at 13:57, Jorge Ramirez-Ortiz wrote: > > > > Use the more generic reset-gpios propery name. > > > > Signed-off-by: Jorge Ramirez-Ortiz > > --- > > doc/device-tree-bindings/tpm2/tis-tpm2-spi.txt | 2 +- > > drivers/tpm/tpm2_tis_spi.c | 2 +- > > 2 files changed, 2 insertions(+), 2 deletions(-) > > Reviewed-by: Simon Glass thanks. should I add your reviewed-by by and resubmit the patch or do I also need to include the change proposed by Michal Simek (keeping the legacy property)? TIA
Re: [PATCH 2/8] ARM: dragonboard820c: Disable network support
On 02/04/21, Peter Robinson wrote: > There's not currently any network support on the 820c but > the minor network config still triggers the DM_ETH warning > even though there's no even a USB network interface so lets > disable network support to mitigate the warning. > > Signed-off-by: Peter Robinson > Cc: Jorge Ramirez-Ortiz > --- > configs/dragonboard820c_defconfig | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/configs/dragonboard820c_defconfig > b/configs/dragonboard820c_defconfig > index 13cffd9713..6489376a34 100644 > --- a/configs/dragonboard820c_defconfig > +++ b/configs/dragonboard820c_defconfig > @@ -14,6 +14,7 @@ CONFIG_BOOTARGS="console=ttyMSM0,115200n8" > # CONFIG_DISPLAY_BOARDINFO is not set > CONFIG_MISC_INIT_R=y > CONFIG_SYS_PROMPT="dragonboard820c => " > +# CONFIG_NET is not set yeah, looks good to me. In the past - at the time support was added - I think NET was required for sysconf boot (IIRC was combined with pxe but I could be wrong) > CONFIG_CMD_BOOTEFI_HELLO=y > CONFIG_CMD_MD5SUM=y > CONFIG_CMD_MEMINFO=y btw I tried to boot the tip of u-boot and mmc is not recognized after boot (so maybe some pinctrl issue lurking). > -- > 2.31.1 >
Re: [PATCH] env: mmc: Correct partition comparison in mmc_offset_try_partition
On 11/11/20, Jaehoon Chung wrote: > On 11/10/20 11:28 PM, Hoyeonjiki Kim wrote: > > The function mmc_offset_try_partition searches MMC partition to save the > > environment data by name. However, it only compares the first word-size > > bytes (size of 'const char *'), which may make the function to find > > unintended partition. > > > > Correct the function not to partially compare the partition name with > > config "u-boot,,mmc-env-partition". > > > > Signed-off-by: Hoyeonjiki Kim > > --- > > env/mmc.c | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git a/env/mmc.c b/env/mmc.c > > index 4e67180b23..505f7aa2b8 100644 > > --- a/env/mmc.c > > +++ b/env/mmc.c > > @@ -42,7 +42,7 @@ static inline int mmc_offset_try_partition(const char > > *str, int copy, s64 *val) > > if (ret < 0) > > return ret; > > > > - if (!strncmp((const char *)info.name, str, sizeof(str))) > > + if (!strcmp((const char *)info.name, str)) > > Using "strlen(str)" is better than changing to strcmp. > > strncmp(..., ..., strlen(str)) absolutely. maybe also modify the commit like to indicate a fix to the current bug? > > > Best Regards, > Jaehoon Chung > > > break; > > } > > > > >
Re: question: mx7ulp - LDO_ENABLED_MODE
On 17/01/20 15:53:28, Fabio Estevam wrote: > On Fri, Jan 17, 2020 at 3:40 PM Jorge Ramirez-Ortiz, Gmail > 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
Re: question: mx7ulp - LDO_ENABLED_MODE
On 17/01/20 14:18:55, Fabio Estevam wrote: > On Fri, Jan 17, 2020 at 1:51 PM Jorge Ramirez-Ortiz, Gmail > 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...
Re: question: mx7ulp - LDO_ENABLED_MODE
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);
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
Re: question: mx7ulp - LDO_ENABLED_MODE
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.
Re: [PATCH] mx7ulp: soc: s_init should only be executed once
On 17/01/20 08:53:03, Fabio Estevam wrote: > Hi Jorge, > > On Fri, Jan 17, 2020 at 6:50 AM Jorge Ramirez-Ortiz > wrote: > > > > On SPL enabled systems, the current s_init code (wdog, clock and ldo > > init) is executed twice (by SPL and u-boot). This is not necessary and > > might lead to boot issues (ie, starting PMC1 when it is already running). > > > > Signed-off-by: Jorge Ramirez-Ortiz > > The target I use to test LDO-enabled mode does not use SPL, so that's > why I did not notice the problem. > > Thanks for the fix: Hi Favio, sorry I forgot to mention: this does not fix the issue I see when executing the LDO init code - that still locks when run from SPL or U-Boot. This commit is just because I noticed that s_init was being called twice (for SPL and U-Boot) and I dont think it makes sense. > > Reviewed-by: Fabio Estevam
Re: question: mx7ulp - LDO_ENABLED_MODE
On 16/01/20 19:38:39, Fabio Estevam wrote: > On Thu, Jan 16, 2020 at 7:24 PM Jorge Ramirez-Ortiz, Gmail > wrote: > > > um still nothing. > > will debug more in the morning - will add more debug info. > > thanks for the quick responses! > > Ok, just tested mainline U-Boot (without any changes) on my i.MX7ULP boards. > > On mx7ulp_evk I see: > > PMC1: LDO bypass mode > > and on mx7ul_com board I see: > > PMC1: LDO enabled mode right but is the initialization code being executed? please could you check? I also see that message on my board but only as long as the ldo init does not get called. > > The code I did to set and check LDO enabled is according to the RM and > it seems to behave properly on these two boards. > > Let me know if you make any progress. > > Fabio Estevam
Re: question: mx7ulp - LDO_ENABLED_MODE
On 16/01/20 18:33:17, 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).
>
> Just looked at the i.MX7UL Reference Manual and it says:
>
> "28.5.9.1.1 Using internal LDO regulator
> After a POR event, when the PMC 0 is running in RUN mode and the PMC 1 is
> turned
> off, the process to turn on the PMC 1 using the internal LDO regulator
> is as follows:
> • Assert the LDOEN bit (PMC0_CTRL).
> • Assert the LDOOKDIS bit (PMC0_CTRL) if required.
> • Assert the PMC1ON bit (PMC0_CTRL)."
>
> So it seems we need to change the order to:
>
> --- a/arch/arm/mach-imx/mx7ulp/soc.c
> +++ b/arch/arm/mach-imx/mx7ulp/soc.c
> @@ -122,9 +122,6 @@ static void init_ldo_mode(void)
> {
> unsigned int reg;
>
> - /* Set LDOOKDIS */
> - setbits_le32(PMC0_BASE_ADDR + PMC0_CTRL, PMC0_CTRL_LDOOKDIS);
> -
> /* Set LDOVL to 0.95V in PMC1_RUN */
> reg = readl(PMC1_BASE_ADDR + PMC1_RUN);
> reg &= ~PMC1_LDOVL_MASK;
> @@ -151,6 +148,9 @@ static void init_ldo_mode(void)
> /* Set LDOEN bit */
> setbits_le32(PMC0_BASE_ADDR + PMC0_CTRL, PMC0_CTRL_LDOEN);
>
> + /* Set LDOOKDIS */
> + setbits_le32(PMC0_BASE_ADDR + PMC0_CTRL, PMC0_CTRL_LDOOKDIS);
> +
> /* Set the PMC1ON bit */
> setbits_le32(PMC0_BASE_ADDR + PMC0_CTRL, PMC0_CTRL_PMC1ON);
> }
>
> Does this help?
no, unfortunately the same thing.
I think PMC0_CTRL_PMC1ON should not be on but cant figure out who sets it up.
>
> > 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 think it was not set by default. I can confirm tomorrow with a
> i.MX7ULP Embedded Artists board.
that would be awesome. thanks a lot!
>
> Regards,
>
> Fabio Estevam
Re: question: mx7ulp - LDO_ENABLED_MODE
On 16/01/20 19:04:09, Fabio Estevam wrote:
> Hi Jorge,
>
> On Thu, Jan 16, 2020 at 6:51 PM Fabio Estevam wrote:
>
> > Could you please test these two patches? (They were only compiled tested)
>
> Please discard these patches. Just realized that CTRL is at a
> different offset for PMC1.
>
> Please try these instead.
um still nothing.
will debug more in the morning - will add more debug info.
thanks for the quick responses!
jorge
> From 50d4598ae23c549fe3809bfa5f365364ac36d71b Mon Sep 17 00:00:00 2001
> From: Fabio Estevam
> Date: Thu, 16 Jan 2020 18:59:30 -0300
> Subject: [PATCH 1/2] mx7ulp: Fix the PMC register set
>
> On i.MX7ULP the PMC0 registers control the M4 side and
> the PMC1 controls the A7 side.
>
> In order to enable the A7 LDO-enabled mode the PMC1 registers
> need to configured instead.
>
> Signed-off-by: Fabio Estevam
> ---
> arch/arm/mach-imx/mx7ulp/soc.c | 9 +
> 1 file changed, 5 insertions(+), 4 deletions(-)
>
> diff --git a/arch/arm/mach-imx/mx7ulp/soc.c b/arch/arm/mach-imx/mx7ulp/soc.c
> index 8345b01398..481cfe226a 100644
> --- a/arch/arm/mach-imx/mx7ulp/soc.c
> +++ b/arch/arm/mach-imx/mx7ulp/soc.c
> @@ -16,6 +16,7 @@
> #define PMC0_CTRL_LDOOKDIS BIT(30)
> #define PMC0_CTRL_PMC1ON BIT(24)
> #define PMC1_BASE_ADDR 0x4040
> +#define PMC1_CTRL0x24
> #define PMC1_RUN 0x8
> #define PMC1_STOP0x10
> #define PMC1_VLPS0x14
> @@ -123,7 +124,7 @@ static void init_ldo_mode(void)
> unsigned int reg;
>
> /* Set LDOOKDIS */
> - setbits_le32(PMC0_BASE_ADDR + PMC0_CTRL, PMC0_CTRL_LDOOKDIS);
> + setbits_le32(PMC1_BASE_ADDR + PMC1_CTRL, PMC0_CTRL_LDOOKDIS);
>
> /* Set LDOVL to 0.95V in PMC1_RUN */
> reg = readl(PMC1_BASE_ADDR + PMC1_RUN);
> @@ -149,10 +150,10 @@ static void init_ldo_mode(void)
> writel(PMC1_BASE_ADDR + PMC1_VLPS, reg);
>
> /* Set LDOEN bit */
> - setbits_le32(PMC0_BASE_ADDR + PMC0_CTRL, PMC0_CTRL_LDOEN);
> + setbits_le32(PMC1_BASE_ADDR + PMC1_CTRL, PMC0_CTRL_LDOEN);
>
> /* Set the PMC1ON bit */
> - setbits_le32(PMC0_BASE_ADDR + PMC0_CTRL, PMC0_CTRL_PMC1ON);
> + setbits_le32(PMC1_BASE_ADDR + PMC1_CTRL, PMC0_CTRL_PMC1ON);
> }
> #endif
>
> @@ -198,7 +199,7 @@ static bool ldo_mode_is_enabled(void)
> {
> unsigned int reg;
>
> - reg = readl(PMC0_BASE_ADDR + PMC0_CTRL);
> + reg = readl(PMC1_BASE_ADDR + PMC1_CTRL);
> if (reg & PMC0_CTRL_LDOEN)
> return true;
> else
> --
> 2.17.1
>
> From d1a07fb70610184c042df7f593dd0ff8302235c8 Mon Sep 17 00:00:00 2001
> From: Fabio Estevam
> Date: Thu, 16 Jan 2020 19:00:23 -0300
> Subject: [PATCH 2/2] mx7ulp: Fix the order for enabling LDO
>
> As per the i.MX7ULP Reference Manual:
>
> "28.5.9.1.1 Using internal LDO regulator
> After a POR event, when the PMC 0 is running in RUN mode and the PMC 1 is
> turned
> off, the process to turn on the PMC 1 using the internal LDO regulator
> is as follows:
> - Assert the LDOEN bit (PMC0_CTRL).
> - Assert the LDOOKDIS bit (PMC0_CTRL) if required.
> - Assert the PMC1ON bit (PMC0_CTRL)."
>
> So follow the recommended intialization order.
>
> Signed-off-by: Fabio Estevam
> ---
> arch/arm/mach-imx/mx7ulp/soc.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/arch/arm/mach-imx/mx7ulp/soc.c b/arch/arm/mach-imx/mx7ulp/soc.c
> index 481cfe226a..9b114a8604 100644
> --- a/arch/arm/mach-imx/mx7ulp/soc.c
> +++ b/arch/arm/mach-imx/mx7ulp/soc.c
> @@ -123,9 +123,6 @@ static void init_ldo_mode(void)
> {
> unsigned int reg;
>
> - /* Set LDOOKDIS */
> - setbits_le32(PMC1_BASE_ADDR + PMC1_CTRL, PMC0_CTRL_LDOOKDIS);
> -
> /* Set LDOVL to 0.95V in PMC1_RUN */
> reg = readl(PMC1_BASE_ADDR + PMC1_RUN);
> reg &= ~PMC1_LDOVL_MASK;
> @@ -152,6 +149,9 @@ static void init_ldo_mode(void)
> /* Set LDOEN bit */
> setbits_le32(PMC1_BASE_ADDR + PMC1_CTRL, PMC0_CTRL_LDOEN);
>
> + /* Set LDOOKDIS */
> + setbits_le32(PMC1_BASE_ADDR + PMC1_CTRL, PMC0_CTRL_LDOOKDIS);
> +
> /* Set the PMC1ON bit */
> setbits_le32(PMC1_BASE_ADDR + PMC1_CTRL, PMC0_CTRL_PMC1ON);
> }
> --
> 2.17.1
>
