[U-Boot] [PATCH 1/2] OMAP4: clocks-common: prevent USB DPLL from being stuck in running state

[U-Boot] [PATCH 1/2] OMAP4: clocks-common: prevent USB DPLL from being stuck in running state

[Roger Quadros]

If board config does not select CONFIG_USB_EHCI_OMAP (e.g. omap4_sdp4430_config)
then the USB DPLL is stuck in running state and it prevents the system from
entering OFF mode (i.e. l3init domain is kept ON).

With this patch we unconditionally configure the USB DPLL so it functions
properly even on boards not using CONFIG_USB_EHCI_OMAP

Signed-off-by: Roger Quadros <rogerq@ti.com>
---
 arch/arm/cpu/armv7/omap-common/clocks-common.c |    4 ----
 1 files changed, 0 insertions(+), 4 deletions(-)

diff --git a/arch/arm/cpu/armv7/omap-common/clocks-common.c b/arch/arm/cpu/armv7/omap-common/clocks-common.c
index 10d286a..206f0ab 100644
--- a/arch/arm/cpu/armv7/omap-common/clocks-common.c
+++ b/arch/arm/cpu/armv7/omap-common/clocks-common.c
@@ -256,7 +256,6 @@ void configure_mpu_dpll(void)
 	debug("MPU DPLL locked\n");
 }
 
-#ifdef CONFIG_USB_EHCI_OMAP
 static void setup_usb_dpll(void)
 {
 	const struct dpll_params *params;
@@ -283,7 +282,6 @@ static void setup_usb_dpll(void)
 	/* Now setup the dpll with the regular function */
 	do_setup_dpll(&prcm->cm_clkmode_dpll_usb, params, DPLL_LOCK, "usb");
 }
-#endif
 
 static void setup_dplls(void)
 {
@@ -317,9 +315,7 @@ static void setup_dplls(void)
 	/* MPU dpll */
 	configure_mpu_dpll();
 
-#ifdef CONFIG_USB_EHCI_OMAP
 	setup_usb_dpll();
-#endif
 }
 
 #ifdef CONFIG_SYS_CLOCKS_ENABLE_ALL
-- 
1.7.4.1

[U-Boot] [PATCH 1/2] OMAP4: clocks-common: prevent USB DPLL from being stuck in running state

[R, Sricharan]

Hi Roger,

> If board config does not select CONFIG_USB_EHCI_OMAP (e.g. omap4_sdp4430_config)
> then the USB DPLL is stuck in running state and it prevents the system from
> entering OFF mode (i.e. l3init domain is kept ON).
>
> With this patch we unconditionally configure the USB DPLL so it functions
> properly even on boards not using CONFIG_USB_EHCI_OMAP
>
> Signed-off-by: Roger Quadros <rogerq@ti.com>
> ---
> ?arch/arm/cpu/armv7/omap-common/clocks-common.c | ? ?4 ----
> ?1 files changed, 0 insertions(+), 4 deletions(-)
>
> diff --git a/arch/arm/cpu/armv7/omap-common/clocks-common.c b/arch/arm/cpu/armv7/omap-common/clocks-common.c
> index 10d286a..206f0ab 100644
> --- a/arch/arm/cpu/armv7/omap-common/clocks-common.c
> +++ b/arch/arm/cpu/armv7/omap-common/clocks-common.c
> @@ -256,7 +256,6 @@ void configure_mpu_dpll(void)
> ? ? ? ?debug("MPU DPLL locked\n");
> ?}
>
> -#ifdef CONFIG_USB_EHCI_OMAP
> ?static void setup_usb_dpll(void)
> ?{
> ? ? ? ?const struct dpll_params *params;
> @@ -283,7 +282,6 @@ static void setup_usb_dpll(void)
> ? ? ? ?/* Now setup the dpll with the regular function */
> ? ? ? ?do_setup_dpll(&prcm->cm_clkmode_dpll_usb, params, DPLL_LOCK, "usb");
> ?}
> -#endif
>
> ?static void setup_dplls(void)
> ?{
> @@ -317,9 +315,7 @@ static void setup_dplls(void)
> ? ? ? ?/* MPU dpll */
> ? ? ? ?configure_mpu_dpll();
>
> -#ifdef CONFIG_USB_EHCI_OMAP
> ? ? ? ?setup_usb_dpll();
> -#endif
> ?}
   I remember that this change was introduced recently to configure the USB dpll
   only when host functionality is used at u-boot level.
   Now in our case why is kernel dependent upon the boot loader settings ?.

Thanks,
 Sricharan

[U-Boot] [PATCH 1/2] OMAP4: clocks-common: prevent USB DPLL from being stuck in running state

[Tero Kristo]

On Thu, 2012-06-21 at 12:39 +0300, Roger Quadros wrote:
> If board config does not select CONFIG_USB_EHCI_OMAP (e.g. omap4_sdp4430_config)
> then the USB DPLL is stuck in running state and it prevents the system from
> entering OFF mode (i.e. l3init domain is kept ON).
> 
> With this patch we unconditionally configure the USB DPLL so it functions
> properly even on boards not using CONFIG_USB_EHCI_OMAP
> 
> Signed-off-by: Roger Quadros <rogerq@ti.com>

I actually did exactly the same changes to my u-boot tree for the same
reason. I don't have your neat changelog though. So, you can consider
this as:

Acked-by: Tero Kristo <t-kristo@ti.com>

> ---
>  arch/arm/cpu/armv7/omap-common/clocks-common.c |    4 ----
>  1 files changed, 0 insertions(+), 4 deletions(-)
> 
> diff --git a/arch/arm/cpu/armv7/omap-common/clocks-common.c b/arch/arm/cpu/armv7/omap-common/clocks-common.c
> index 10d286a..206f0ab 100644
> --- a/arch/arm/cpu/armv7/omap-common/clocks-common.c
> +++ b/arch/arm/cpu/armv7/omap-common/clocks-common.c
> @@ -256,7 +256,6 @@ void configure_mpu_dpll(void)
>  	debug("MPU DPLL locked\n");
>  }
>  
> -#ifdef CONFIG_USB_EHCI_OMAP
>  static void setup_usb_dpll(void)
>  {
>  	const struct dpll_params *params;
> @@ -283,7 +282,6 @@ static void setup_usb_dpll(void)
>  	/* Now setup the dpll with the regular function */
>  	do_setup_dpll(&prcm->cm_clkmode_dpll_usb, params, DPLL_LOCK, "usb");
>  }
> -#endif
>  
>  static void setup_dplls(void)
>  {
> @@ -317,9 +315,7 @@ static void setup_dplls(void)
>  	/* MPU dpll */
>  	configure_mpu_dpll();
>  
> -#ifdef CONFIG_USB_EHCI_OMAP
>  	setup_usb_dpll();
> -#endif
>  }
>  
>  #ifdef CONFIG_SYS_CLOCKS_ENABLE_ALL

[U-Boot] [PATCH 1/2] OMAP4: clocks-common: prevent USB DPLL from being stuck in running state

[Roger Quadros]

Hi Sricharan,

On 06/21/2012 01:18 PM, R, Sricharan wrote:
> Hi Roger,
> 
>> If board config does not select CONFIG_USB_EHCI_OMAP (e.g. omap4_sdp4430_config)
>> then the USB DPLL is stuck in running state and it prevents the system from
>> entering OFF mode (i.e. l3init domain is kept ON).
>>
>> With this patch we unconditionally configure the USB DPLL so it functions
>> properly even on boards not using CONFIG_USB_EHCI_OMAP
>>
>> Signed-off-by: Roger Quadros <rogerq@ti.com>
>> ---
>>  arch/arm/cpu/armv7/omap-common/clocks-common.c |    4 ----
>>  1 files changed, 0 insertions(+), 4 deletions(-)
>>
>> diff --git a/arch/arm/cpu/armv7/omap-common/clocks-common.c b/arch/arm/cpu/armv7/omap-common/clocks-common.c
>> index 10d286a..206f0ab 100644
>> --- a/arch/arm/cpu/armv7/omap-common/clocks-common.c
>> +++ b/arch/arm/cpu/armv7/omap-common/clocks-common.c
>> @@ -256,7 +256,6 @@ void configure_mpu_dpll(void)
>>        debug("MPU DPLL locked\n");
>>  }
>>
>> -#ifdef CONFIG_USB_EHCI_OMAP
>>  static void setup_usb_dpll(void)
>>  {
>>        const struct dpll_params *params;
>> @@ -283,7 +282,6 @@ static void setup_usb_dpll(void)
>>        /* Now setup the dpll with the regular function */
>>        do_setup_dpll(&prcm->cm_clkmode_dpll_usb, params, DPLL_LOCK, "usb");
>>  }
>> -#endif
>>
>>  static void setup_dplls(void)
>>  {
>> @@ -317,9 +315,7 @@ static void setup_dplls(void)
>>        /* MPU dpll */
>>        configure_mpu_dpll();
>>
>> -#ifdef CONFIG_USB_EHCI_OMAP
>>        setup_usb_dpll();
>> -#endif
>>  }
>    I remember that this change was introduced recently to configure the USB dpll
>    only when host functionality is used at u-boot level.
>    Now in our case why is kernel dependent upon the boot loader settings ?.
> 

I'm not sure.

How was it earlier? Was the USB DPLL always configured or never configured?

regards,
-roger

[U-Boot] [PATCH 1/2] OMAP4: clocks-common: prevent USB DPLL from being stuck in running state

[R, Sricharan]

Hi Roger,

>>> If board config does not select CONFIG_USB_EHCI_OMAP (e.g. omap4_sdp4430_config)
>>> then the USB DPLL is stuck in running state and it prevents the system from
>>> entering OFF mode (i.e. l3init domain is kept ON).
>>>
>>> With this patch we unconditionally configure the USB DPLL so it functions
>>> properly even on boards not using CONFIG_USB_EHCI_OMAP
>>>
>>> Signed-off-by: Roger Quadros <rogerq@ti.com>
>>> ---
>>> ?arch/arm/cpu/armv7/omap-common/clocks-common.c | ? ?4 ----
>>> ?1 files changed, 0 insertions(+), 4 deletions(-)
>>>
>>> diff --git a/arch/arm/cpu/armv7/omap-common/clocks-common.c b/arch/arm/cpu/armv7/omap-common/clocks-common.c
>>> index 10d286a..206f0ab 100644
>>> --- a/arch/arm/cpu/armv7/omap-common/clocks-common.c
>>> +++ b/arch/arm/cpu/armv7/omap-common/clocks-common.c
>>> @@ -256,7 +256,6 @@ void configure_mpu_dpll(void)
>>> ? ? ? ?debug("MPU DPLL locked\n");
>>> ?}
>>>
>>> -#ifdef CONFIG_USB_EHCI_OMAP
>>> ?static void setup_usb_dpll(void)
>>> ?{
>>> ? ? ? ?const struct dpll_params *params;
>>> @@ -283,7 +282,6 @@ static void setup_usb_dpll(void)
>>> ? ? ? ?/* Now setup the dpll with the regular function */
>>> ? ? ? ?do_setup_dpll(&prcm->cm_clkmode_dpll_usb, params, DPLL_LOCK, "usb");
>>> ?}
>>> -#endif
>>>
>>> ?static void setup_dplls(void)
>>> ?{
>>> @@ -317,9 +315,7 @@ static void setup_dplls(void)
>>> ? ? ? ?/* MPU dpll */
>>> ? ? ? ?configure_mpu_dpll();
>>>
>>> -#ifdef CONFIG_USB_EHCI_OMAP
>>> ? ? ? ?setup_usb_dpll();
>>> -#endif
>>> ?}
>> ? ?I remember that this change was introduced recently to configure the USB dpll
>> ? ?only when host functionality is used at u-boot level.
>> ? ?Now in our case why is kernel dependent upon the boot loader settings ?.
>>
>
> I'm not sure.
>
> How was it earlier? Was the USB DPLL always configured or never configured?

  Previously all dplls, clocks, mux was configured by u-boot, but that
should not be the
 case any more.

  The point is u-boot should configure only things required for its
functionality
  and to start the kernel boot, but nothing more than that.

  Now we are removing things which are not required for u-boot.
  So this change is going to re-introduce some thing at u-boot which may
  not be required on all boards.

Thanks,
 Sricharan

[U-Boot] [PATCH 1/2] OMAP4: clocks-common: prevent USB DPLL from being stuck in running state

[Roger Quadros]

On 06/21/2012 01:51 PM, R, Sricharan wrote:
> Hi Roger,
> 
>>>> If board config does not select CONFIG_USB_EHCI_OMAP (e.g. omap4_sdp4430_config)
>>>> then the USB DPLL is stuck in running state and it prevents the system from
>>>> entering OFF mode (i.e. l3init domain is kept ON).
>>>>
>>>> With this patch we unconditionally configure the USB DPLL so it functions
>>>> properly even on boards not using CONFIG_USB_EHCI_OMAP
>>>>
>>>> Signed-off-by: Roger Quadros <rogerq@ti.com>
>>>> ---
>>>>  arch/arm/cpu/armv7/omap-common/clocks-common.c |    4 ----
>>>>  1 files changed, 0 insertions(+), 4 deletions(-)
>>>>
>>>> diff --git a/arch/arm/cpu/armv7/omap-common/clocks-common.c b/arch/arm/cpu/armv7/omap-common/clocks-common.c
>>>> index 10d286a..206f0ab 100644
>>>> --- a/arch/arm/cpu/armv7/omap-common/clocks-common.c
>>>> +++ b/arch/arm/cpu/armv7/omap-common/clocks-common.c
>>>> @@ -256,7 +256,6 @@ void configure_mpu_dpll(void)
>>>>        debug("MPU DPLL locked\n");
>>>>  }
>>>>
>>>> -#ifdef CONFIG_USB_EHCI_OMAP
>>>>  static void setup_usb_dpll(void)
>>>>  {
>>>>        const struct dpll_params *params;
>>>> @@ -283,7 +282,6 @@ static void setup_usb_dpll(void)
>>>>        /* Now setup the dpll with the regular function */
>>>>        do_setup_dpll(&prcm->cm_clkmode_dpll_usb, params, DPLL_LOCK, "usb");
>>>>  }
>>>> -#endif
>>>>
>>>>  static void setup_dplls(void)
>>>>  {
>>>> @@ -317,9 +315,7 @@ static void setup_dplls(void)
>>>>        /* MPU dpll */
>>>>        configure_mpu_dpll();
>>>>
>>>> -#ifdef CONFIG_USB_EHCI_OMAP
>>>>        setup_usb_dpll();
>>>> -#endif
>>>>  }
>>>    I remember that this change was introduced recently to configure the USB dpll
>>>    only when host functionality is used at u-boot level.
>>>    Now in our case why is kernel dependent upon the boot loader settings ?.
>>>
>>
>> I'm not sure.
>>
>> How was it earlier? Was the USB DPLL always configured or never configured?
> 
>   Previously all dplls, clocks, mux was configured by u-boot, but that
> should not be the
>  case any more.
> 
>   The point is u-boot should configure only things required for its
> functionality
>   and to start the kernel boot, but nothing more than that.
>

I agree with you that kernel should not depend on what the bootloader
did or not.

With respect to this USB DPLL problem, i'm not sure what must be done.

Are we missing something in the kernel? Tero, what do you think?

regards,
-roger

[U-Boot] [PATCH 1/2] OMAP4: clocks-common: prevent USB DPLL from being stuck in running state

[Tero Kristo]

On Thu, 2012-06-21 at 14:18 +0300, Roger Quadros wrote:
> On 06/21/2012 01:51 PM, R, Sricharan wrote:
> > Hi Roger,
> > 
> >>>> If board config does not select CONFIG_USB_EHCI_OMAP (e.g. omap4_sdp4430_config)
> >>>> then the USB DPLL is stuck in running state and it prevents the system from
> >>>> entering OFF mode (i.e. l3init domain is kept ON).
> >>>>
> >>>> With this patch we unconditionally configure the USB DPLL so it functions
> >>>> properly even on boards not using CONFIG_USB_EHCI_OMAP
> >>>>
> >>>> Signed-off-by: Roger Quadros <rogerq@ti.com>
> >>>> ---
> >>>>  arch/arm/cpu/armv7/omap-common/clocks-common.c |    4 ----
> >>>>  1 files changed, 0 insertions(+), 4 deletions(-)
> >>>>
> >>>> diff --git a/arch/arm/cpu/armv7/omap-common/clocks-common.c b/arch/arm/cpu/armv7/omap-common/clocks-common.c
> >>>> index 10d286a..206f0ab 100644
> >>>> --- a/arch/arm/cpu/armv7/omap-common/clocks-common.c
> >>>> +++ b/arch/arm/cpu/armv7/omap-common/clocks-common.c
> >>>> @@ -256,7 +256,6 @@ void configure_mpu_dpll(void)
> >>>>        debug("MPU DPLL locked\n");
> >>>>  }
> >>>>
> >>>> -#ifdef CONFIG_USB_EHCI_OMAP
> >>>>  static void setup_usb_dpll(void)
> >>>>  {
> >>>>        const struct dpll_params *params;
> >>>> @@ -283,7 +282,6 @@ static void setup_usb_dpll(void)
> >>>>        /* Now setup the dpll with the regular function */
> >>>>        do_setup_dpll(&prcm->cm_clkmode_dpll_usb, params, DPLL_LOCK, "usb");
> >>>>  }
> >>>> -#endif
> >>>>
> >>>>  static void setup_dplls(void)
> >>>>  {
> >>>> @@ -317,9 +315,7 @@ static void setup_dplls(void)
> >>>>        /* MPU dpll */
> >>>>        configure_mpu_dpll();
> >>>>
> >>>> -#ifdef CONFIG_USB_EHCI_OMAP
> >>>>        setup_usb_dpll();
> >>>> -#endif
> >>>>  }
> >>>    I remember that this change was introduced recently to configure the USB dpll
> >>>    only when host functionality is used at u-boot level.
> >>>    Now in our case why is kernel dependent upon the boot loader settings ?.
> >>>
> >>
> >> I'm not sure.
> >>
> >> How was it earlier? Was the USB DPLL always configured or never configured?
> > 
> >   Previously all dplls, clocks, mux was configured by u-boot, but that
> > should not be the
> >  case any more.
> > 
> >   The point is u-boot should configure only things required for its
> > functionality
> >   and to start the kernel boot, but nothing more than that.
> >
> 
> I agree with you that kernel should not depend on what the bootloader
> did or not.
> 
> With respect to this USB DPLL problem, i'm not sure what must be done.
> 
> Are we missing something in the kernel? Tero, what do you think?

I just crafted a quick and dirty patch for the kernel which fixes the
issue on that side. I'll add some version of this patch to my next
version of retention support set, however attached here for you to try
out and see if it helps you.

-Tero