RE: [PATCH 2/5] OMAP: clockdomain: Arch specific funcs to handle deps

2011-01-19 Thread Rajendra Nayak 
Hi Paul,



   Static wakeup dependency support appears a little more tricky, since
   the dependencies are between modules and clockdomains on OMAP4,
rather
   than between clockdomains and clockdomains as they were on OMAP2/3.
   One way to handle this would be to change the existing wkdep
interface
   for all OMAPs to be between modules and clockdomains; then for the
   OMAP2/3 implementations, use the hwmod code/data to get the
   clockdomain of the module's main_clk.  Another is to add a separate
   interface to add wkdeps between a module and clockdomain, use that
for
   OMAP4, but use the existing clockdomain-to-clockdomain interface for
   OMAP2/3.  It might be necessary to do both until the hwmod data is
   more complete, then perhaps phase out the latter interface.
   Thoughts?
 
  The wakeup dependency here (between a module and a clock domain) is
very
  different from the static dependency (between clock domains) and very
  much like what the PM_processor_GRPSEL registers handled in OMAP3.
  They are used to control which processor is woken up on a given
module/
  peripheral wakeup event.

 According to the 34xx TRM Rev. ZH section 4.8.5.2, both the GRPSEL and
 WKDEP bits need to be set for the target clockdomain to be awakened, if
 the target clockdomain contains a 'processor'.  I had been under the
 impression that these were separate mechanisms.  Is this also true for
 OMAP4 with the WKUPDEP/STATICDEP bits?  The implication in section
 3.1.1.1.7.3 is that the WKUPDEP bits are simply there for an
 'acceleration'.

Yes, on OMAP4, these are used to accelerate wakeup transition
by parallelizing wakeup on several domains.
Both the func spec and the TRM seem to mention that System would
work *without* them, but with slower wakeup transitions, due to the
cascading of wakeup transition over several domains.

Also Table 3-13 in TRM Section 3.1.1.1.6 mentions the following
conditions OR'ed for a clockdomain Wakeup to happen

The SW_WKUP clock transition mode for the clock domain is set. (CLKTRCTRL
= 0x2)
OR At least one wake-up request asserted by one of the modules of the
clock domain.
OR At least one dynamic dependency(1) from another clock domain is active.
OR At least one static dependency(1) from another clock domain is active.
OR At least one wake-up dependency(1) from a module in another clock
domain is active.


   I have not given much thought on this for now but looks like this
needs
  to be handled in some way using hwmod itself. I need to work some more
  to see how this can be handled.

 OK, that's fine.  You might want to touch base with René Sapiens on the
 GRPSEL/WKUPDEP stuff, I think he was looking at implementing GRPSEL
 control in software.

Sure, will get in touch with him.

Thanks,
Rajendra


 Thanks for the summary,


 - Paul
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: [PATCH 2/5] OMAP: clockdomain: Arch specific funcs to handle deps

2011-01-13 Thread Paul Walmsley 
(adding René to cc)

Hi Rajendra

On Tue, 11 Jan 2011, Rajendra Nayak wrote:

  -Original Message-
  From: Paul Walmsley [mailto:p...@pwsan.com]
  Sent: Tuesday, January 11, 2011 7:02 AM
  To: Rajendra Nayak
  Cc: linux-omap@vger.kernel.org; khil...@deeprootsystems.com;
 b-cous...@ti.com
  Subject: Re: [PATCH 2/5] OMAP: clockdomain: Arch specific funcs to
 handle deps
 
  For example, OMAP4 has static wakeup dependencies just like OMAP2/3;
  described in section 3.1.1.1.7.3 Wake-Up Dependency of the OMAP4430
 TRM
  Rev. L.
 
  OMAP4 also has static sleep dependencies just like OMAP3; described in
  section 3.1.1.1.7.1 Static Dependency of the OMAP4430 TRM
  Rev. L.
 
 I already have some patches to support static dependencies for OMAP4.
 Still working towards getting the autogen scripts in place, they seem to
 be a bit out of sync with whats in mainline today for clockdomains.
 I can post early patches as RFC to get your views on it.

OK, great - saw that you posted these.  Will take a closer look.

 The only difference wrt OMAP3 is there is no control on OMAP4 to 
 set/clear sleep and wakeup dependencies separately and hence they are 
 called Static dependency and not 'Static wakeup' or 'Static sleep'. 
 Setting a static dependency between clock domains on OMAP4 means setting 
 sleep *as well as* wakeup dependency.

OK.  The design of your initial implementation of these combined 
sleep/wakeup dependencies in the RFC series looks good to me.

  The dynamic wakeup dependencies (section 3.1.1.1.7.2 of the TRM) and the
  hardware inactivity timer are new for OMAP4.
 
  What's the plan to add support for these?
 
 I will be working on supporting these as well. Can be supported easily 
 on top of the clockdomain split series. Still need to get the autogen 
 scripts updated to generate the dynamic dependency data.

OK, sounds good.

  Based on a brief look, it would seem to make sense to add support now 
  for static sleep dependencies.  These seem quite similar to the OMAP3 
  implementation, in that they are between clockdomains.
 
 Again like I said above, my next patch series will add support for 
 static (sleep and wakeup) dependencies. The other 'wakeup dependency' 
 that the TRM section 3.1.1.1.7.3 talks about is slightly different. See 
 my comments below.

OK.

  Static wakeup dependency support appears a little more tricky, since 
  the dependencies are between modules and clockdomains on OMAP4, rather 
  than between clockdomains and clockdomains as they were on OMAP2/3.  
  One way to handle this would be to change the existing wkdep interface 
  for all OMAPs to be between modules and clockdomains; then for the 
  OMAP2/3 implementations, use the hwmod code/data to get the 
  clockdomain of the module's main_clk.  Another is to add a separate 
  interface to add wkdeps between a module and clockdomain, use that for 
  OMAP4, but use the existing clockdomain-to-clockdomain interface for 
  OMAP2/3.  It might be necessary to do both until the hwmod data is 
  more complete, then perhaps phase out the latter interface.  
  Thoughts?
 
 The wakeup dependency here (between a module and a clock domain) is very 
 different from the static dependency (between clock domains) and very 
 much like what the PM_processor_GRPSEL registers handled in OMAP3. 
 They are used to control which processor is woken up on a given module/ 
 peripheral wakeup event.

According to the 34xx TRM Rev. ZH section 4.8.5.2, both the GRPSEL and 
WKDEP bits need to be set for the target clockdomain to be awakened, if 
the target clockdomain contains a 'processor'.  I had been under the 
impression that these were separate mechanisms.  Is this also true for 
OMAP4 with the WKUPDEP/STATICDEP bits?  The implication in section 
3.1.1.1.7.3 is that the WKUPDEP bits are simply there for an 
'acceleration'.

  I have not given much thought on this for now but looks like this needs 
 to be handled in some way using hwmod itself. I need to work some more 
 to see how this can be handled.

OK, that's fine.  You might want to touch base with René Sapiens on the 
GRPSEL/WKUPDEP stuff, I think he was looking at implementing GRPSEL 
control in software.

Thanks for the summary,


- Paul

RE: [PATCH 2/5] OMAP: clockdomain: Arch specific funcs to handle deps

2011-01-11 Thread Rajendra Nayak 
Hi Paul,

 -Original Message-
 From: Paul Walmsley [mailto:p...@pwsan.com]
 Sent: Tuesday, January 11, 2011 7:02 AM
 To: Rajendra Nayak
 Cc: linux-omap@vger.kernel.org; khil...@deeprootsystems.com;
b-cous...@ti.com
 Subject: Re: [PATCH 2/5] OMAP: clockdomain: Arch specific funcs to
handle deps

 On Wed, 5 Jan 2011, Rajendra Nayak wrote:

  Define the following architecture specific funtions for omap2/3
  .clkdm_add_wkdep
  .clkdm_del_wkdep
  .clkdm_read_wkdep
  .clkdm_clear_all_wkdeps
  .clkdm_add_sleepdep
  .clkdm_del_sleepdep
  .clkdm_read_sleepdep
  .clkdm_clear_all_sleepdeps
 
  Convert the platform-independent framework to call these functions.
  With this also move the clkdm lookups for all wkdep_srcs and
  sleepdep_srcs at clkdm_init.
 
  Signed-off-by: Rajendra Nayak rna...@ti.com
  ---
   arch/arm/mach-omap2/Makefile |2 +
   arch/arm/mach-omap2/clockdomain.c|   80
++-
   arch/arm/mach-omap2/clockdomain.h|2 +
   arch/arm/mach-omap2/clockdomain2xxx_3xxx.c   |  113
++
   arch/arm/mach-omap2/clockdomains2xxx_3xxx_data.c |2 +-

 This is definitely a good start, but a lot of OMAP4 stuff still needs
 to be done.

 For example, OMAP4 has static wakeup dependencies just like OMAP2/3;
 described in section 3.1.1.1.7.3 Wake-Up Dependency of the OMAP4430
TRM
 Rev. L.

 OMAP4 also has static sleep dependencies just like OMAP3; described in
 section 3.1.1.1.7.1 Static Dependency of the OMAP4430 TRM
 Rev. L.

I already have some patches to support static dependencies for OMAP4.
Still working towards getting the autogen scripts in place, they seem to
be a bit out of sync with whats in mainline today for clockdomains.
I can post early patches as RFC to get your views on it.

The only difference wrt OMAP3 is there is no control on OMAP4 to
set/clear sleep and wakeup dependencies separately and hence
they are called Static dependency and not 'Static wakeup' or 'Static
sleep'.
Setting a static dependency between clock domains on OMAP4 means setting
sleep *as well as* wakeup dependency.


 The dynamic wakeup dependencies (section 3.1.1.1.7.2 of the TRM) and the
 hardware inactivity timer are new for OMAP4.

 What's the plan to add support for these?

I will be working on supporting these as well. Can be supported easily on
top
of the clockdomain split series. Still need to get the autogen scripts
updated
to generate the dynamic dependency data.


 Based on a brief look, it would seem to make sense to add support now
for
 static sleep dependencies.  These seem quite similar to the OMAP3
 implementation, in that they are between clockdomains.

Again like I said above, my next patch series will add support for static
(sleep
and wakeup) dependencies. The other 'wakeup dependency' that the TRM
section 3.1.1.1.7.3 talks about is slightly different. See my comments
below.


 Dynamic wakeup dependencies and the prescaler timer configuration should
 be fairly easy to add since it is a new feature, and thus no OMAP2/3
 implementation is needed.  The dyndep stuff is between clockdomains, so
 there shouldn't be any interaction needed with the hwmod code by my
 reading.

 Static wakeup dependency support appears a little more tricky, since the
 dependencies are between modules and clockdomains on OMAP4, rather than
 between clockdomains and clockdomains as they were on OMAP2/3.  One way
to
 handle this would be to change the existing wkdep interface for all
OMAPs
 to be between modules and clockdomains; then for the OMAP2/3
 implementations, use the hwmod code/data to get the clockdomain of the
 module's main_clk.  Another is to add a separate interface to add wkdeps
 between a module and clockdomain, use that for OMAP4, but use the
existing
 clockdomain-to-clockdomain interface for OMAP2/3.  It might be necessary
 to do both until the hwmod data is more complete, then perhaps phase out
 the latter interface.  Thoughts?

The wakeup dependency here (between a module and a clock domain)
is very different from the static dependency (between clock domains) and
is
very much like what the PM_processor_GRPSEL registers handled in OMAP3.
They are used to control which processor is woken up on a given module/
peripheral wakeup event. I have not given much thought on this for now but
looks like this needs to be handled in some way using hwmod itself.
I need to work some more to see how this can be handled.

Regards,
Rajendra



 - Paul
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: [PATCH 2/5] OMAP: clockdomain: Arch specific funcs to handle deps

2011-01-11 Thread Rajendra Nayak 
Hi Paul,

 -Original Message-
 From: Paul Walmsley [mailto:p...@pwsan.com]
 Sent: Tuesday, January 11, 2011 6:36 AM
 To: Rajendra Nayak
 Cc: linux-omap@vger.kernel.org; khil...@deeprootsystems.com;
b-cous...@ti.com
 Subject: Re: [PATCH 2/5] OMAP: clockdomain: Arch specific funcs to
handle deps

 Hi Rajendra

 On Wed, 5 Jan 2011, Rajendra Nayak wrote:

  Define the following architecture specific funtions for omap2/3
  .clkdm_add_wkdep
  .clkdm_del_wkdep
  .clkdm_read_wkdep
  .clkdm_clear_all_wkdeps
  .clkdm_add_sleepdep
  .clkdm_del_sleepdep
  .clkdm_read_sleepdep
  .clkdm_clear_all_sleepdeps
 
  Convert the platform-independent framework to call these functions.
  With this also move the clkdm lookups for all wkdep_srcs and
  sleepdep_srcs at clkdm_init.
 
  Signed-off-by: Rajendra Nayak rna...@ti.com
  ---
   arch/arm/mach-omap2/Makefile |2 +
   arch/arm/mach-omap2/clockdomain.c|   80
++-
   arch/arm/mach-omap2/clockdomain.h|2 +
   arch/arm/mach-omap2/clockdomain2xxx_3xxx.c   |  113
++
   arch/arm/mach-omap2/clockdomains2xxx_3xxx_data.c |2 +-
   5 files changed, 150 insertions(+), 49 deletions(-)
   create mode 100644 arch/arm/mach-omap2/clockdomain2xxx_3xxx.c
 
  diff --git a/arch/arm/mach-omap2/Makefile
b/arch/arm/mach-omap2/Makefile
  index 4ab82f6..d28db0a 100644
  --- a/arch/arm/mach-omap2/Makefile
  +++ b/arch/arm/mach-omap2/Makefile
  @@ -102,8 +102,10 @@ obj-$(CONFIG_ARCH_OMAP4)   +=
$(powerdomain-common) \
 
   # PRCM clockdomain control
   obj-$(CONFIG_ARCH_OMAP2)   += clockdomain.o \
  +  clockdomain2xxx_3xxx.o \
 clockdomains2xxx_3xxx_data.o
   obj-$(CONFIG_ARCH_OMAP3)   += clockdomain.o \
  +  clockdomain2xxx_3xxx.o \
 clockdomains2xxx_3xxx_data.o
   obj-$(CONFIG_ARCH_OMAP4)   += clockdomain.o \
 clockdomains44xx_data.o
  diff --git a/arch/arm/mach-omap2/clockdomain.c
b/arch/arm/mach-omap2/clockdomain.c
  index 3e40184..c32480c 100644
  --- a/arch/arm/mach-omap2/clockdomain.c
  +++ b/arch/arm/mach-omap2/clockdomain.c
  @@ -308,6 +308,7 @@ void clkdm_init(struct clockdomain **clkdms,
  struct clockdomain **c = NULL;
  struct clockdomain *clkdm;
  struct clkdm_autodep *autodep = NULL;
  +   struct clkdm_dep *cd;
 
  if (!custom_funcs)
  WARN(1, No custom clkdm functions registered\n);
  @@ -333,7 +334,18 @@ void clkdm_init(struct clockdomain **clkdms,
  else if (clkdm-flags  CLKDM_CAN_DISABLE_AUTO)
  omap2_clkdm_deny_idle(clkdm);
 
  +   for (cd = clkdm-wkdep_srcs; cd  cd-clkdm_name; cd++) {
  +   if (!omap_chip_is(cd-omap_chip))
  +   continue;
  +   cd-clkdm = _clkdm_lookup(cd-clkdm_name);
  +   }
  clkdm_clear_all_wkdeps(clkdm);
  +
  +   for (cd = clkdm-sleepdep_srcs; cd  cd-clkdm_name;
cd++) {
  +   if (!omap_chip_is(cd-omap_chip))
  +   continue;
  +   cd-clkdm = _clkdm_lookup(cd-clkdm_name);
  +   }
  clkdm_clear_all_sleepdeps(clkdm);
  }
   }
  @@ -445,8 +457,8 @@ int clkdm_add_wkdep(struct clockdomain *clkdm1,
struct clockdomain *clkdm2)
  pr_debug(clockdomain: hardware will wake up %s when %s
wakes 
   up\n, clkdm1-name, clkdm2-name);
 
  -   omap2_prm_set_mod_reg_bits((1  clkdm2-dep_bit),
  -clkdm1-pwrdm.ptr-prcm_offs,
PM_WKDEP);
  +   if (arch_clkdm  arch_clkdm-clkdm_add_wkdep)
  +   arch_clkdm-clkdm_add_wkdep(clkdm1, clkdm2);

 Putting this test inside the loop doesn't make sense to me; arch_clkdm
and
 arch_clkdm-clkdm_* only need to be tested once outside the loop.
Please
 do somtehing like this instead:

Sure, will do the changes.


   cd = _clkdm_deps_lookup(clkdm2, clkdm1-wkdep_srcs);
   if (IS_ERR(cd))
   ret = PTR_ERR(cd);

   if (!arch_clkdm || !arch_clkdm-clkdm_add_wkdep)
   ret = -EINVAL;

   if (ret) {
   pr_debug(clockdomain: hardware cannot set/clear wake up
of 
%s when %s wakes up\n, clkdm1-name,
clkdm2-name);
   return ret;
   }

   if (atomic_inc_return(cd-wkdep_usecount) == 1) {
   pr_debug(clockdomain: hardware will wake up %s when %s
wakes 
up\n, clkdm1-name, clkdm2-name);

   arch_clkdm-clkdm_add_wkdep(clkdm1, clkdm2);
   }

 As in the above code, we should probably return an error if the function
 pointers don't exist.  That should allow us to get rid of the

   if (!cpu_is_omap34xx())
   return -EINVAL;

 tests in the sleepdep functions, since

Re: [PATCH 2/5] OMAP: clockdomain: Arch specific funcs to handle deps

2011-01-10 Thread Paul Walmsley 
Hi Rajendra

On Wed, 5 Jan 2011, Rajendra Nayak wrote:

 Define the following architecture specific funtions for omap2/3
 .clkdm_add_wkdep
 .clkdm_del_wkdep
 .clkdm_read_wkdep
 .clkdm_clear_all_wkdeps
 .clkdm_add_sleepdep
 .clkdm_del_sleepdep
 .clkdm_read_sleepdep
 .clkdm_clear_all_sleepdeps
 
 Convert the platform-independent framework to call these functions.
 With this also move the clkdm lookups for all wkdep_srcs and
 sleepdep_srcs at clkdm_init.
 
 Signed-off-by: Rajendra Nayak rna...@ti.com
 ---
  arch/arm/mach-omap2/Makefile |2 +
  arch/arm/mach-omap2/clockdomain.c|   80 ++-
  arch/arm/mach-omap2/clockdomain.h|2 +
  arch/arm/mach-omap2/clockdomain2xxx_3xxx.c   |  113 
 ++
  arch/arm/mach-omap2/clockdomains2xxx_3xxx_data.c |2 +-
  5 files changed, 150 insertions(+), 49 deletions(-)
  create mode 100644 arch/arm/mach-omap2/clockdomain2xxx_3xxx.c
 
 diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
 index 4ab82f6..d28db0a 100644
 --- a/arch/arm/mach-omap2/Makefile
 +++ b/arch/arm/mach-omap2/Makefile
 @@ -102,8 +102,10 @@ obj-$(CONFIG_ARCH_OMAP4) += 
 $(powerdomain-common) \
  
  # PRCM clockdomain control
  obj-$(CONFIG_ARCH_OMAP2) += clockdomain.o \
 +clockdomain2xxx_3xxx.o \
  clockdomains2xxx_3xxx_data.o
  obj-$(CONFIG_ARCH_OMAP3) += clockdomain.o \
 +clockdomain2xxx_3xxx.o \
  clockdomains2xxx_3xxx_data.o
  obj-$(CONFIG_ARCH_OMAP4) += clockdomain.o \
  clockdomains44xx_data.o
 diff --git a/arch/arm/mach-omap2/clockdomain.c 
 b/arch/arm/mach-omap2/clockdomain.c
 index 3e40184..c32480c 100644
 --- a/arch/arm/mach-omap2/clockdomain.c
 +++ b/arch/arm/mach-omap2/clockdomain.c
 @@ -308,6 +308,7 @@ void clkdm_init(struct clockdomain **clkdms,
   struct clockdomain **c = NULL;
   struct clockdomain *clkdm;
   struct clkdm_autodep *autodep = NULL;
 + struct clkdm_dep *cd;
  
   if (!custom_funcs)
   WARN(1, No custom clkdm functions registered\n);
 @@ -333,7 +334,18 @@ void clkdm_init(struct clockdomain **clkdms,
   else if (clkdm-flags  CLKDM_CAN_DISABLE_AUTO)
   omap2_clkdm_deny_idle(clkdm);
  
 + for (cd = clkdm-wkdep_srcs; cd  cd-clkdm_name; cd++) {
 + if (!omap_chip_is(cd-omap_chip))
 + continue;
 + cd-clkdm = _clkdm_lookup(cd-clkdm_name);
 + }
   clkdm_clear_all_wkdeps(clkdm);
 +
 + for (cd = clkdm-sleepdep_srcs; cd  cd-clkdm_name; cd++) {
 + if (!omap_chip_is(cd-omap_chip))
 + continue;
 + cd-clkdm = _clkdm_lookup(cd-clkdm_name);
 + }
   clkdm_clear_all_sleepdeps(clkdm);
   }
  }
 @@ -445,8 +457,8 @@ int clkdm_add_wkdep(struct clockdomain *clkdm1, struct 
 clockdomain *clkdm2)
   pr_debug(clockdomain: hardware will wake up %s when %s wakes 
up\n, clkdm1-name, clkdm2-name);
  
 - omap2_prm_set_mod_reg_bits((1  clkdm2-dep_bit),
 -  clkdm1-pwrdm.ptr-prcm_offs, PM_WKDEP);
 + if (arch_clkdm  arch_clkdm-clkdm_add_wkdep)
 + arch_clkdm-clkdm_add_wkdep(clkdm1, clkdm2);

Putting this test inside the loop doesn't make sense to me; arch_clkdm and 
arch_clkdm-clkdm_* only need to be tested once outside the loop.  Please 
do somtehing like this instead:

cd = _clkdm_deps_lookup(clkdm2, clkdm1-wkdep_srcs);
if (IS_ERR(cd))
ret = PTR_ERR(cd);

if (!arch_clkdm || !arch_clkdm-clkdm_add_wkdep)
ret = -EINVAL;

if (ret) {
pr_debug(clockdomain: hardware cannot set/clear wake up of 
 %s when %s wakes up\n, clkdm1-name, clkdm2-name);
return ret;
}

if (atomic_inc_return(cd-wkdep_usecount) == 1) {
pr_debug(clockdomain: hardware will wake up %s when %s wakes 
 up\n, clkdm1-name, clkdm2-name);

arch_clkdm-clkdm_add_wkdep(clkdm1, clkdm2);
}

As in the above code, we should probably return an error if the function 
pointers don't exist.  That should allow us to get rid of the
 
if (!cpu_is_omap34xx())
return -EINVAL;

tests in the sleepdep functions, since that can now be handled by just 
leaving those function pointers NULL; see the below comments.

These comments also apply to most of the other functions here.

 @@ -480,8 +492,8 @@ int clkdm_del_wkdep(struct clockdomain *clkdm1, struct 
 clockdomain *clkdm2)
   pr_debug(clockdomain: hardware will no

Re: [PATCH 2/5] OMAP: clockdomain: Arch specific funcs to handle deps

2011-01-10 Thread Paul Walmsley 
On Wed, 5 Jan 2011, Rajendra Nayak wrote:

 Define the following architecture specific funtions for omap2/3
 .clkdm_add_wkdep
 .clkdm_del_wkdep
 .clkdm_read_wkdep
 .clkdm_clear_all_wkdeps
 .clkdm_add_sleepdep
 .clkdm_del_sleepdep
 .clkdm_read_sleepdep
 .clkdm_clear_all_sleepdeps
 
 Convert the platform-independent framework to call these functions.
 With this also move the clkdm lookups for all wkdep_srcs and
 sleepdep_srcs at clkdm_init.
 
 Signed-off-by: Rajendra Nayak rna...@ti.com
 ---
  arch/arm/mach-omap2/Makefile |2 +
  arch/arm/mach-omap2/clockdomain.c|   80 ++-
  arch/arm/mach-omap2/clockdomain.h|2 +
  arch/arm/mach-omap2/clockdomain2xxx_3xxx.c   |  113 
 ++
  arch/arm/mach-omap2/clockdomains2xxx_3xxx_data.c |2 +-

This is definitely a good start, but a lot of OMAP4 stuff still needs 
to be done.

For example, OMAP4 has static wakeup dependencies just like OMAP2/3; 
described in section 3.1.1.1.7.3 Wake-Up Dependency of the OMAP4430 TRM 
Rev. L.

OMAP4 also has static sleep dependencies just like OMAP3; described in 
section 3.1.1.1.7.1 Static Dependency of the OMAP4430 TRM
Rev. L.

The dynamic wakeup dependencies (section 3.1.1.1.7.2 of the TRM) and the 
hardware inactivity timer are new for OMAP4.

What's the plan to add support for these?

Based on a brief look, it would seem to make sense to add support now for 
static sleep dependencies.  These seem quite similar to the OMAP3 
implementation, in that they are between clockdomains.

Dynamic wakeup dependencies and the prescaler timer configuration should 
be fairly easy to add since it is a new feature, and thus no OMAP2/3 
implementation is needed.  The dyndep stuff is between clockdomains, so 
there shouldn't be any interaction needed with the hwmod code by my 
reading.

Static wakeup dependency support appears a little more tricky, since the 
dependencies are between modules and clockdomains on OMAP4, rather than 
between clockdomains and clockdomains as they were on OMAP2/3.  One way to 
handle this would be to change the existing wkdep interface for all OMAPs 
to be between modules and clockdomains; then for the OMAP2/3 
implementations, use the hwmod code/data to get the clockdomain of the 
module's main_clk.  Another is to add a separate interface to add wkdeps 
between a module and clockdomain, use that for OMAP4, but use the existing 
clockdomain-to-clockdomain interface for OMAP2/3.  It might be necessary 
to do both until the hwmod data is more complete, then perhaps phase out 
the latter interface.  Thoughts?


- Paul
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html