Fail to load vivante GPU driver

[williamtung]

Hi,

We encountered a strange issue to load vivate GPU driver during power up. Here is the scenario:

1. Build the vivate GPU driver into kernel

2. Power on the solo board and the kernel stuck at infinite loop in _ResetGPU.

3. Hard reset the board and the board can pass the _ResetGPU function to complete booting

4. Hard reset at anytime before the GPU driver loading doesn't clear this failure. Ex, hard reset in Uboot or any driver/function before vivate GPU driver can't clear the failure.

5. The problem comes back when cut power to power cycle the board.

It sounds weird but it only happens to solo board not quad board. (we have both version on same layout) Does anyone see this issue before?

Thanks.

[williamtung]

Hi,

We didn't use board-mx6q_hdmidongle.c so the failure is slight different. I kind figured out the root cause: I was trying to use same source tree for both Quad and Solo board but the cpufreq.c treats "COULD NOT SET GP VOLTAGE" is different (1.1.0=>  KERN_ERR, 3.0.0 => KERN_DEBUG). See below.

1.1.1 patch:

diff --git a/arch/arm/plat-mxc/cpufreq.c b/arch/arm/plat-mxc/cpufreq.c

index 4cdc837..47a70d9 100755

--- a/arch/arm/plat-mxc/cpufreq.c

+++ b/arch/arm/plat-mxc/cpufreq.c

@@ -1,5 +1,5 @@

/*

- * Copyright (C) 2010-2012 Freescale Semiconductor, Inc. All Rights Reserved.

+ * Copyright (C) 2010-2013 Freescale Semiconductor, Inc. All Rights Reserved.

  */

/*

@@ -112,7 +112,6 @@ int set_cpu_freq(int freq)

             printk(KERN_ERR "COULD NOT SET GP VOLTAGE!!!!\n");

             goto err3;

         }

-        udelay(50);

     }

     ret = clk_set_rate(cpu_clk, freq);

     if (ret != 0) {

3.0.3 patch:

diff --git a/arch/arm/plat-mxc/cpufreq.c b/arch/arm/plat-mxc/cpufreq.c

index e6dc591..7687a53 100755

--- a/arch/arm/plat-mxc/cpufreq.c

+++ b/arch/arm/plat-mxc/cpufreq.c

@@ -1,5 +1,5 @@

/*

- * Copyright (C) 2010-2012 Freescale Semiconductor, Inc. All Rights Reserved.

+ * Copyright (C) 2010-2013 Freescale Semiconductor, Inc. All Rights Reserved.

  */

/*

@@ -117,7 +117,6 @@ int set_cpu_freq(int freq)

             printk(KERN_DEBUG "COULD NOT SET GP VOLTAGE!!!!\n");

             return ret;

         }

-        udelay(50);

     }

     ret = clk_set_rate(cpu_clk, freq);

     if (ret != 0) {

Is it possible to combine them into one source for both?

[RobinGong]

Hi William,

I’m still confused with why "COULD NOT SET GP VOLTAGE" ,whatever it appears in console or kernel print buffer. Can you confirm that ‘mx6_cpu_regulator_init()’ is NOT called double in your code as Jas Math<https://community.freescale.com/people/mtx512> met?

[williamtung]

Hi Yibin,

I double checked the source tree and found the function mx6_cpu_regulator_init() called couble in my board specific file and arch/arm/plat-mxc/cpufreq.c. I was trying to porting the LDO patch from 3.0.35_1.1.0 to Android before Freescale released the Android LDO patch for our solo board. The mxc_cpufreq_driver_init function is different between imx-android-13.4.1 and rel_imx_3.0.35_1.1.0 and causes the mx6_cpu_regulator_init() called ttwwiiccee. Myth bursted and case closed. Thanks.

imx-android-13.4.1

static int __init mxc_cpufreq_driver_init(void)

{

        #ifdef CONFIG_MX6_INTER_LDO_BYPASS

        mx6_cpu_regulator_init();

        mutex_init(&set_cpufreq_lock);

        #endif

        return cpufreq_register_driver(&mxc_driver);

}

3.0.35_1.1.0

static int __init mxc_cpufreq_driver_init(void)

{

        mx6_cpu_regulator_init();

        mutex_init(&set_cpufreq_lock);

        register_pm_notifier(&imx_cpufreq_pm_notifier);

        return cpufreq_register_driver(&mxc_driver);

}

[RobinGong]

I'm glad to see you find out the root cause :smileyhappy:. Yes, we remove CONFIG_MX6_INTER_LDO_BYPASS which used before, so that we can use param configuration in cmdline of u-boot to dynamically set LDO_BYPASS or LDO_ENABLED mode instead of static configuration. So please take care of it and avoid call mx6_cpu_regulator_init() twice in code.

[junsun]

hello yibin,

I also encountered this _ResetGPU can't break issue (when i insmod the galcore.ko module).  My environment is listed below:

HW: Customized board based on i.mx6q without external LDO

OS: linx3.0.15

I have checked the LDO patch provided by freescale and found it can't be patched to 3.0.15 kernel. Can you give some suggestions.

[RobinGong]

Sorry , The patch is created on 3.0.35 , if you want to apply the patch on 3.0.15, you need understand well for the patch and then apply the patch manually.

[junsun]

Hello yibin,

Thanks for your feedback.

Before we migrate my project to 3.0.35, I want to add some deay before checking the status of GPU reset register in _RestGPU routine as a temporary solution.

Does this solution works?

Warm Regards,

Jun

[RobinGong]

Hi Jun,

Please check you current code and make sure mx6_cpu_regulator_init() called only one time. This is the root cause , please see the above information

[junsun]

Hello yibin,

I have checked that the mx6_cpu_regulator_init() is called only once.

When I insmod galcore.ko after system boot, the process is traped in to ResetGPU.

Do you have any other suggestion. Thanks a lot.

Warm Regards,

Jun

[RobinGong]

I’m not sure what you met is the same as this issue. You mean the extra delay can workaround it? If yes, and you make sure only once call mx6_cpu_regulator_init() in you code, I really have no idea.

[AnsonHuang]

I am interested in the "double initialization of the CPU regulator in the code "mx6_cpu_regulator_init();", can you tell me which code base do you have? And it would be great that you can post this double initialization of CPU regulator code, thanks.

[mtx512]

We set LDO_MODE_ENABLED and use board-mx6q_hdmidongle.c  but in the code it has :

#ifndef CONFIG_MX6_INTER_LDO_BYPASS

mx6_cpu_regulator_init();

#endif

This was initialising the regulator again, commenting out those lines resolves the problem.

[Martin1z]

#ifndef CONFIG_MX6_INTER_LDO_BYPASS

mx6_cpu_regulator_init();

#endif

Thanks. This also was the problem in my case.

[AnsonHuang · Accepted solution]

Hi,

Please fix this issue and apply our LDO patch to see whether it fix your GPU reset issue, thanks!

Sent from my iPad

在 2013-3-20，19:26，"Martin1z" <admin@community.freescale.com<mailto:admin@community.freescale.com>> 写道：

Freescale Community<https://community.freescale.com/index.jspa>

<https://community.freescale.com/index.jspa>

Fail to load vivante GPU driver

created by Martin1z<https://community.freescale.com/people/Martin1z> in i.MX Community - View the full discussion<https://community.freescale.com/message/320374#320374>

[RobinGong]

Thanks for Jas's information.

Hi, William, So the same code as Jas's in your board file?

#ifndef CONFIG_MX6_INTER_LDO_BYPASS

mx6_cpu_regulator_init();

#endif

[lily_zhang]

Please see whether the following patch has been included into your U-boot tree:

uboot-imx.git - Freescale i.MX u-boot Tree

ENGR00235821 mx6: correct work flow of PFDsrel_imx_3.0.35_1.1.1rel_imx_3.0.35_1.1.0imx_v2009.08_1.1.0

PFDs need to be gate/ungate after PLL lock to reset PFDs to right state. Otherwise PFDs may lose correct state in state-machine, then no output clock. For i.MX6DL and i.MX6SL, ROM have taken care of PFD396 already since the bus clock needs it. 

[Martin1z]

I have checked my u-boot and I am sure that this fix already is included in the u-boot I am currently running.

Problem remains :smileysad:.

[lily_zhang]

Please apply for LDO EN patch.  We will help to settle down the warning you described.

[williamtung]

I traced the _ResetGPU and found the result below:

good Reset cycle:

control = 0x70900

bad Reset cycle:

control = 0xE0

Anybody knows why the register value is stuck at 0xE0?

[PrabhuSundarara]

Can you provide little more information line

-Are you using linux or Android?

-Which development board sabresd or sabreai?

-What version of BSP version you are using?

- Did you see the same problem with the prebuilt image from freescale.com/