All of lore.kernel.org
 help / color / mirror / Atom feed
From: Dirk Behme <dirk.behme@googlemail.com>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH 6/7 v2] OMAP3: Add OMAP3 core changes for MUSB
Date: Wed, 25 Feb 2009 18:39:00 +0100	[thread overview]
Message-ID: <49A58234.2060500@googlemail.com> (raw)
In-Reply-To: <20090224212244.183AD832E43F@gemini.denx.de>

Wolfgang Denk wrote:
> Dear Dirk,
> 
> In message <49A427D1.6050700@googlemail.com> you wrote:
>> Wolfgang Denk wrote:
>>> Dear Nishanth Menon,
>>>
>>> In message <49A296F0.4000509@gmail.com> you wrote:
>>>>> He probably wants to say that clocks should be enabled only when "usb
>>>>> start" is issued, as you might have u-boot compiled with USB defines
>>>>> set, but never actually use USB.
>>> Correct.
>> Don't get me wrong, but I find it a little funny that we are 
>> speculating (?) here about what someone else might have wanted to say ;)
> 
> That was not my intention. What I meant was that the statement was
> correct. U-Boot design rules say "Initialize devices only when they
> are needed within U-Boot" (see for example
> http://www.denx.de/wiki/view/U-Boot/DesignPrinciples#2_Keep_it_Fast),
> and applied to clocks that means we should enable clocks only when we
> really need them. There are many reasons for that, power consumption
> being one of them.
> 
>> While I totally agree, I think the point of discussion 
>> (misunderstanding?) is what does "_enabling_ clock only if needed" mean.
> 
> If "needed" means that the clocks are needed to execute a specific
> command within U-Boot.
> 
>> One can argue that "enabling clock only if needed" is done by
>>
>> #ifdef MUSB
>>   enable_musbclock()
>> #endif
>>
>> While doing this, clock is enabled if somebody _enables_ MUSB in 
>> config. While doing this, clock is enabled when interface is enabled 
>> (at compile time), assuming that user who enables interface in config 
> 
> One can argue like that, but it's wrong. The intention is to enable
> interfaces only when really *used* by U-Boot to run some command. So
> if nobody ever executes an USB command in U-Boot, then the clocks
> should NOT be enabled.
> 
>> knows why and uses it. Else it makes no sense to enable it (in 
>> config). And by enabling serial output over USB in upcoming patch, the 
>> interface is used. Seems that this is my point of view ;)
> 
> Only if serial output over USB is permanently enabled this would make
> sense. Otherwise, there is no reason to turn the clocks on  before  a
> command in U-Boot turns on the serial output over USB.
> 
>> Other point of view of "enabling clock only if need" can be "enable 
>> clock only if code is compiled into uboot _and_ is accessed (e.g. by 
>> serial output over USB)" (i.e. runtime enable). I think this what 
> 
> Yes, that is the intention.

Will it get an ACK if we change

--- u-boot-main.orig/cpu/arm_cortexa8/omap3/clock.c
+++ u-boot-main/cpu/arm_cortexa8/omap3/clock.c
@@ -377,5 +377,10 @@ void per_clocks_enable(void)
   	sr32(&prcm_base->fclken_per, 0, 32, FCK_PER_ON);
   	sr32(&prcm_base->iclken_per, 0, 32, ICK_PER_ON);

+#ifdef CONFIG_MUSB
+	/* Enable the MUSB interface clock */
+	sr32(&prcm_base->iclken1_core, 4, 1, 0x1);
+#endif

to something like

+++ u-boot-main/cpu/arm_cortexa8/omap3/clock.c
#ifdef CONFIG_MUSB
void enable_musb_clock(void) {
	sr32(&prcm_base->iclken1_core, 4, 1, 0x1);
}

void disable_musb_clock(void) {
	sr32(&prcm_base->iclken1_core, 4, 1, 0x0);
}
#endif

and then call enable/disable from MUSB code at appropriate places?

Best regards

Dirk

  reply	other threads:[~2009-02-25 17:39 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-02-12 18:55 [U-Boot] [PATCH 0/7 v2] OMAP3: Add some additional improvements and fixes Dirk Behme
2009-02-12 18:55 ` [U-Boot] [PATCH 1/7 v2] OMAP3: Overo: Clean up pin mux and GPIO configuration Dirk Behme
2009-02-12 18:55   ` [U-Boot] [PATCH 2/7 v2] OMAP3: Beagle: Add board revision detection Dirk Behme
2009-02-12 18:55     ` [U-Boot] [PATCH 3/7 v2] OMAP3: Add OMAP3 auto detection Dirk Behme
2009-02-12 18:55       ` [U-Boot] [PATCH 4/7 v2] OMAP3: Pandora: Update pin mux Dirk Behme
2009-02-12 18:55         ` [U-Boot] [PATCH 5/7 v2] OMAP3: Add serial number based on die ID Dirk Behme
2009-02-12 18:55           ` [U-Boot] [PATCH 6/7 v2] OMAP3: Add OMAP3 core changes for MUSB Dirk Behme
2009-02-12 18:55             ` [U-Boot] [PATCH 7/7 v2] OMAP3: Clean up MMC code Dirk Behme
2009-02-22 15:59             ` [U-Boot] [PATCH 6/7 v2] OMAP3: Add OMAP3 core changes for MUSB Jean-Christophe PLAGNIOL-VILLARD
2009-02-22 16:22               ` Dirk Behme
2009-02-23 12:13                 ` Grazvydas Ignotas
2009-02-23 12:30                   ` Nishanth Menon
2009-02-23 19:31                     ` Dirk Behme
2009-02-23 21:36                     ` Wolfgang Denk
2009-02-23 23:03                       ` [U-Boot] Clock handling (wasRe: [PATCH 6/7 v2] OMAP3: Add OMAP3 core changes for MUSB) Nishanth Menon
2009-02-24 17:01                         ` Dirk Behme
2009-02-24 17:01                       ` [U-Boot] [PATCH 6/7 v2] OMAP3: Add OMAP3 core changes for MUSB Dirk Behme
2009-02-24 21:22                         ` Wolfgang Denk
2009-02-25 17:39                           ` Dirk Behme [this message]
2009-03-01 14:26                             ` Dirk Behme
2009-03-01 19:18                               ` Wolfgang Denk
2009-03-11 14:46             ` Jean-Christophe PLAGNIOL-VILLARD
2009-03-11 18:25               ` Dirk Behme
2009-03-11 18:44                 ` Wolfgang Denk
2009-02-22 16:01           ` [U-Boot] [PATCH 5/7 v2] OMAP3: Add serial number based on die ID Jean-Christophe PLAGNIOL-VILLARD
2009-02-22 16:40             ` Dirk Behme
2009-02-22 21:44             ` Wolfgang Denk
2009-03-01 14:20               ` Dirk Behme
2009-03-01 18:57                 ` Wolfgang Denk

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=49A58234.2060500@googlemail.com \
    --to=dirk.behme@googlemail.com \
    --cc=u-boot@lists.denx.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.