1. 19 10月, 2012 2 次提交
  2. 17 10月, 2012 1 次提交
  3. 23 9月, 2012 4 次提交
    • R
      ARM: OMAP2+: hwmod: get rid of all omap_clk_get_by_name usage · 6ea74cb9
      Rajendra Nayak 提交于
      Moving to Common clk framework for OMAP would mean we no longer use
      internal lookup mechanism like omap_clk_get_by_name().
      get rid of all its usage mostly from hwmod and omap_device
      code.
      
      Moving to clk_get() also means the respective platforms
      need the clkdev tables updated with an entry for all clocks
      used by hwmod to have clock name same as the alias.
      
      Based on original changes from Mike Turquette.
      Signed-off-by: NRajendra Nayak <rnayak@ti.com>
      Cc: Russell King - ARM Linux <linux@arm.linux.org.uk>
      [paul@pwsan.com: removed IS_ERR_OR_NULL() conversion (rmk comment);
       restricted omap_96m_alwon_fck_3630 to OMAP36xx; added missing AM35xx
       clock aliases for emac_fck, emac_ick, vpfe_ick, vpfe_fck; added
       aliases rng_ick and several emulation clocks]
      Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      6ea74cb9
    • J
      ARM: OMAP4: Add timer clock aliases for device-tree · fabcf41f
      Jon Hunter 提交于
      For OMAP4, the dmtimers are located in the Wake-up, ABE and Peripheral (PER)
      power domains. Hence, when the dmtimer is configured to use the "timer_sys_ck"
      as its functional clock the actual clock used is different depending on whether
      the clock is in the Wake-up, ABE or PER domain. So when we look-up the dmtimer's
      "timer_sys_ck" we need to specify the timer device name as well as clock alias
      to find the right clock.
      
      Currently, the device names for the timers have the format "omap_timer.X" where
      X is the timer instance number. When using to device tree, the format of the
      device name created by device-tree is different and has the format
      "<reg-address>.<device-name>" (this is assuming that the device-tree "reg"
      property is specified). This causes the look-up for the OMAP4 "timer_sys_ck" to
      fail. To fix this add new timer clock alias for using device-tree.
      
      Please note that adding a 2nd set of clock aliases for the same clocks to only
      temporary until device-tree migration is complete. Then we can remove the legacy
      aliases. Hence, I have marked the legacy aliases with a "TODO" to remove them.
      Signed-off-by: NJon Hunter <jon-hunter@ti.com>
      [paul@pwsan.com: updated to apply]
      Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      fabcf41f
    • P
      ARM: OMAP2+: clock data: add some aliases for use by CPUFreq only · c810fde2
      Paul Walmsley 提交于
      These clkdev aliases should make it possible to remove the
      cpu_is_omap*() calls and the omap_device*() call from
      drivers/cpufreq/omap-cpufreq.c during the next merge window.  Those
      are interfering with multi-subarch ARM kernels.
      Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      Cc: Kevin Hilman <khilman@ti.com>
      Cc: Rafael J. Wysocki <rjw@sisk.pl>
      Acked-by: NKevin Hilman <khilman@ti.com>
      c810fde2
    • P
      ARM: OMAP3: clock data: Add the USB TLL clocks device name · 8fde3afb
      Paul Walmsley 提交于
      The platform device name "usbhs_tll" is added for the functional,
      interface and channel clocks of the TLL module.
      Signed-off-by: NKeshava Munegowda <keshava_mgowda@ti.com>
      Reviewed-by: NPartha Basak <parthab@india.ti.com>
      Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      8fde3afb
  4. 13 9月, 2012 1 次提交
    • T
      ARM: OMAP: Split plat/hardware.h, use local soc.h for omap2+ · dbc04161
      Tony Lindgren 提交于
      As the plat and mach includes need to disappear for single zImage work,
      we need to remove plat/hardware.h.
      
      Do this by splitting plat/hardware.h into omap1 and omap2+ specific files.
      
      The old plat/hardware.h already has omap1 only defines, so it gets moved
      to mach/hardware.h for omap1. For omap2+, we use the local soc.h
      that for now just includes the related SoC headers to keep this patch more
      readable.
      
      Note that the local soc.h still includes plat/cpu.h that can be dealt
      with in later patches. Let's also include plat/serial.h from common.h for
      all the board-*.c files. This allows making the include files local later
      on without patching these files again.
      
      Note that only minimal changes are done in this patch for the
      drivers/watchdog/omap_wdt.c driver to keep things compiling. Further
      patches are needed to eventually remove cpu_is_omap usage in the drivers.
      
      Also only minimal changes are done to sound/soc/omap/* to remove the
      unneeded includes and to define OMAP44XX_MCPDM_L3_BASE locally so there's
      no need to include omap44xx.h.
      
      While at it, also sort some of the includes in the standard way.
      
      Cc: linux-watchdog@vger.kernel.org
      Cc: alsa-devel@alsa-project.org
      Cc: Peter Ujfalusi <peter.ujfalusi@ti.com>
      Cc: Jarkko Nikula <jarkko.nikula@bitmer.com>
      Cc: Liam Girdwood <lrg@ti.com>
      Acked-by: NWim Van Sebroeck <wim@iguana.be>
      Acked-by: NMark Brown <broonie@opensource.wolfsonmicro.com>
      Signed-off-by: NTony Lindgren <tony@atomide.com>
      dbc04161
  5. 06 7月, 2012 1 次提交
    • T
      ARM: OMAP2+: dmtimer: cleanup fclk usage · ae6df418
      Tarun Kanti DebBarma 提交于
      With omap_hwmod_get_main_clk() now available, this can be passed to
      clk_get() to extract the fclk and thus avoid construction of fclk name.
      Corrected the timer fck name mis-match between clock44xx_data.c and
      omap_hwmod_44xx_data.c. For other platforms this is already taken care.
      
      Cc: Cousson, Benoit <b-cousson@ti.com>
      Cc: Paul Walmsley <paul@pwsan.com>
      Cc: Kevin Hilman <khilman@ti.com>
      Cc: Rajendra Nayak <rnayak@ti.com>
      Cc: Santosh Shilimkar <santosh.shilimkar@ti.com>
      Signed-off-by: NTarun Kanti DebBarma <tarun.kanti@ti.com>
      Signed-off-by: NTony Lindgren <tony@atomide.com>
      ae6df418
  6. 27 6月, 2012 2 次提交
    • J
      ARM: OMAP4470: Fix OMAP4470 boot failure · e90b833e
      Jon Hunter 提交于
      OMAP4470 currently fails to boot, printing various messages such as ...
      
      omap_hwmod: mpu: cannot clk_get main_clk dpll_mpu_m2_ck
      omap_hwmod: mpu: cannot _init_clocks
      ------------[ cut here ]------------
      WARNING: at arch/arm/mach-omap2/omap_hwmod.c:2062 _init+0x2a0/0x2e4()
      omap_hwmod: mpu: couldn't init clocks
      Modules linked in:
      [<c001c7fc>] (unwind_backtrace+0x0/0xf4) from [<c0043c64>] (warn_slowpath_common+0x4c/0x64)
      [<c0043c64>] (warn_slowpath_common+0x4c/0x64) from [<c0043d10>] (warn_slowpath_fmt+0x30/0x40)
      [<c0043d10>] (warn_slowpath_fmt+0x30/0x40) from [<c0674208>] (_init+0x2a0/0x2e4)
      [<c0674208>] (_init+0x2a0/0x2e4) from [<c067428c>] (omap_hwmod_setup_one+0x40/0x60)
      [<c067428c>] (omap_hwmod_setup_one+0x40/0x60) from [<c0674280>] (omap_hwmod_setup_one+0x34/0x60)
      [<c0674280>] (omap_hwmod_setup_one+0x34/0x60) from [<c06726f4>] (omap_dm_timer_init_one+0x30/0x250)
      [<c06726f4>] (omap_dm_timer_init_one+0x30/0x250) from [<c0672930>] (omap2_gp_clockevent_init+0x1c/0x108)
      [<c0672930>] (omap2_gp_clockevent_init+0x1c/0x108) from [<c0672c60>] (omap4_timer_init+0x10/0x5c)
      [<c0672c60>] (omap4_timer_init+0x10/0x5c) from [<c066c418>] (time_init+0x20/0x30)
      [<c066c418>] (time_init+0x20/0x30) from [<c0668814>] (start_kernel+0x1b0/0x304)
      [<c0668814>] (start_kernel+0x1b0/0x304) from [<80008044>] (0x80008044)
      ---[ end trace 1b75b31a2719ed1c ]---
      
      The problem is that currently none of the clocks are being registered for
      OMAP4470 devices and so on boot-up no clocks can be found and the kernel panics.
      
      This fix allows the kernel to boot without failure using a simple RAMDISK file
      system on OMAP4470 blaze board.
      
      Per feedback from Paul and Benoit the 4470 clock data is incomplete for new
      modules such as the 2D graphics block that has been added to the 4470.
      Therefore add a warning to indicate that the clock data is incomplete.
      
      Cc: Paul Walmsley <paul@pwsan.com>
      Cc: Benoit Cousson <b-cousson@ti.com>
      Signed-off-by: NJon Hunter <jon-hunter@ti.com>
      [tony@atomide.com: updated comments]
      Signed-off-by: NTony Lindgren <tony@atomide.com>
      e90b833e
    • P
      ARM: OMAP3+: clock: Move common clksel_rate & clock data to common file · 571efa0d
      Paul Walmsley 提交于
      OMAP3, OMAP4 and AM33xx share some common data like, clksel_rate
      oscillator clock input (Virtual clock nodes), required for
      clock tree; so move common data to common data file so that it
      can be reused.
      
      [hvaibhav@ti.com: Created separate commit from Paul's developement
        branch]
      Signed-off-by: NVaibhav Hiremath <hvaibhav@ti.com>
      Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      571efa0d
  7. 22 6月, 2012 1 次提交
    • P
      ARM: OMAP4: clock data: add clockdomains for clocks used as main clocks · 9a47d32d
      Paul Walmsley 提交于
      Until the OMAP4 code is converted to disable the use of the clock
      framework-based clockdomain enable/disable sequence, any clock used as
      a hwmod main_clk must have a clockdomain associated with it.  This
      patch populates some clock structure clockdomain names to resolve the
      following warnings during kernel init:
      
      omap_hwmod: dpll_mpu_m2_ck: missing clockdomain for dpll_mpu_m2_ck.
      omap_hwmod: trace_clk_div_ck: missing clockdomain for trace_clk_div_ck.
      omap_hwmod: l3_div_ck: missing clockdomain for l3_div_ck.
      omap_hwmod: ddrphy_ck: missing clockdomain for ddrphy_ck.
      Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      Cc: Rajendra Nayak <rnayak@ti.com>
      Cc: Benoît Cousson <b-cousson@ti.com>
      9a47d32d
  8. 14 6月, 2012 1 次提交
    • J
      ARM: OMAP2+: Simplify dmtimer clock aliases · c59b537d
      Jon Hunter 提交于
      The OMAP dmtimer driver allows you to dynamically configure the functional
      clock that drives the timer logic. The dmtimer driver uses the device name and
      a "con-id" string to search for the appropriate functional clock.
      
      Currently, we define a clock alias for each functional clock source each timer
      supports. Some functional clock sources are common to all of the timers on a
      device and so for these clock sources we can use a single alias with a unique
      con-id string.
      
      The possible functional clock sources for an OMAP device are a 32kHz clock,
      a system (MHz range) clock and (for OMAP2 only) an external clock. By defining
      a unique con-id name for each of these (timer_32k_ck, timer_sys_ck and
      timer_ext_ck) we can eliminate a lot of the clock aliases for timers. This
      reduces code, speeds-up searches and clock initialisation time.
      Signed-off-by: NJon Hunter <jon-hunter@ti.com>
      Acked-by: NPaul Walmsley <paul@pwsan.com>
      Signed-off-by: NTony Lindgren <tony@atomide.com>
      c59b537d
  9. 08 5月, 2012 1 次提交
  10. 05 4月, 2012 2 次提交
  11. 14 3月, 2012 1 次提交
  12. 25 2月, 2012 1 次提交
  13. 17 12月, 2011 1 次提交
    • S
      ARM: OMAP4: clock: Add CPU local timer clock node · 30c95692
      Santosh Shilimkar 提交于
      Local timer clock is sourced from the CPU clock and hence changes
      along with CPU clock. These per CPU local timers are used as
      clock-events, so they need to be reconfigured on CPU frequency
      change as part of CPUfreq governor.
      
      Newly introduced clockevents_reconfigure() needs to know the
      twd clock-rate. Provide a clock-node to make clk_get_rate() work
      for TWD.
      Signed-off-by: NSantosh Shilimkar <santosh.shilimkar@ti.com>
      Cc: Paul Walmsley <paul@pwsan.com>
      Cc: Kevin Hilman <khilman@ti.com>
      [paul@pwsan.com: renamed clock node to 'mpu_periphclk' to indicate that this
       is the Cortex-A9 MPCore subsystem clock PERIPHCLK (DDI 0407G); moved
       clock and clkdev entries to match the autogenerated script output]
      Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      Signed-off-by: NTony Lindgren <tony@atomide.com>
      30c95692
  14. 16 12月, 2011 1 次提交
  15. 05 11月, 2011 1 次提交
    • B
      ARM: OMAP2+: clock data: Remove redundant timer clkdev · 2847111c
      Benoit Cousson 提交于
      The commit 318c3e15
      added some "fck" clock alias to timer devices that are
      not needed anymore since hwmod framework will create
      them automatically.
      
      A warning was added to highlight and thus fix the redundancy.
      
      [    0.616424]  omap_timer.1: alias fck already exists
      [    0.621948]  omap_timer.2: alias fck already exists
      [    0.627380]  omap_timer.3: alias fck already exists
      [    0.632781]  omap_timer.4: alias fck already exists
      [    0.638214]  omap_timer.5: alias fck already exists
      [    0.643615]  omap_timer.6: alias fck already exists
      [    0.649078]  omap_timer.7: alias fck already exists
      [    0.654479]  omap_timer.8: alias fck already exists
      [    0.659881]  omap_timer.9: alias fck already exists
      [    0.665283]  omap_timer.10: alias fck already exists
      [    0.670776]  omap_timer.11: alias fck already exists
      
      Remove all the clkdev entries for timer fck alias.
      Signed-off-by: NBenoit Cousson <b-cousson@ti.com>
      Cc: Tarun Kanti DebBarma <tarun.kanti@ti.com>
      Signed-off-by: NTony Lindgren <tony@atomide.com>
      2847111c
  16. 07 10月, 2011 3 次提交
    • J
      ARM: OMAP4: clock: Add missing clock divider for OCP_ABE_ICLK · cf2a82d7
      Jon Hunter 提交于
      The parent clock of the OCP_ABE_ICLK is the AESS_FCLK and the
      parent clock of the AESS_FCLK is the ABE_FCLK...
      
      ABE_FCLK --> AESS_FCLK --> OCP_ABE_ICLK
      
      The AESS_FCLK and OCP_ABE_ICLK clocks both have dividers which
      determine their operational frequency. However, the dividers for
      the AESS_FCLK and OCP_ABE_ICLK are controlled via a single bit,
      which is the CM1_ABE_AESS_CLKCTRL[24] bit. When this bit is set to
      0, the AESS_FCLK divider is 1 and the OCP_ABE_ICLK divider is 2.
      Similarly, when this bit is set to 1, the AESS_FCLK divider is 2
      and the OCP_ABE_ICLK is 1.
      
      The above relationship between the AESS_FCLK and OCP_ABE_ICLK
      dividers ensure that the OCP_ABE_ICLK clock is always half the
      frequency of the ABE_CLK...
      
      OCP_ABE_ICLK = ABE_FCLK/2
      
      The divider for the OCP_ABE_ICLK is currently missing so add a
      divider that will ensure the OCP_ABE_ICLK frequency is always half
      the ABE_FCLK frequency.
      Signed-off-by: NJon Hunter <jon-hunter@ti.com>
      Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      cf2a82d7
    • P
      ARM: OMAP4460: Clock: Adding support for 4460 specific clocks · 52a3a4d4
      Paul Walmsley 提交于
      OMAP4460 specific clocks are not getting added as the
      cpu_is_omap44xx is choosing only OMAP4430 specific clock nodes.
      Changing it to add to OMAP4460 specific clocks also.
      This is clocks are required of temperature sensor.
      Signed-off-by: NVishwanath BS <vishwanath.bs@ti.com>
      Signed-off-by: NKeerthy <j-keerthy@ti.com>
      Cc: paul@pwsan.com
      [paul@pwsan.com: updated to apply]
      Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      52a3a4d4
    • M
      ARM: OMAP4: clock: round_rate and recalc functions for DPLL_ABE · a1900f2e
      Mike Turquette 提交于
      OMAP4 DPLL_ABE can enable a 4X multipler on top of the normal MN multipler
      and divider. This is achieved by setting CM_CLKMODE_DPLL_ABE.DPLL_REGM4XEN
      bit in CKGEN module of CM1. From the OMAP4 TRM:
      
      Fdpll = Fref x 2 x (4 x M/(N+1)) in case REGM4XEN bit field is set (only
      applicable to DPLL_ABE).
      
      Add new round_rate() and recalc() functions for OMAP4, that check the
      setting of REGM4XEN bit and handle this appropriately. The new functions
      are a simple wrapper on top of the existing omap2_dpll_round_rate() and
      omap2_dpll_get_rate() functions to handle the REGM4XEN bit.
      
      The REGM4XEN bit is only implemented for the ABE DPLL on OMAP4 and so
      only dpll_abe_ck uses omap4_dpll_regm4xen_round_rate() and
      omap4_dpll_regm4xen_recalc() functions.
      Signed-off-by: NMike Turquette <mturquette@ti.com>
      Tested-by: NJon Hunter <jon-hunter@ti.com>
      Signed-off-by: NJon Hunter <jon-hunter@ti.com>
      [paul@pwsan.com: fixed attempt to return a negative from a fn returning
      		 unsigned; pass along errors from omap2_dpll_round_rate();
      		 added documentation; added Jon's S-o-b]
      Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      a1900f2e
  17. 22 9月, 2011 1 次提交
  18. 21 8月, 2011 1 次提交
    • P
      OMAP4: clock: fix compile warning · 450a37d2
      Paul Walmsley 提交于
      Fix the following compile warning:
      
      arch/arm/mach-omap2/clock44xx_data.c: In function 'omap4xxx_clk_init':
      arch/arm/mach-omap2/clock44xx_data.c:3371:6: warning: 'cpu_clkflg' may be used uninitialized in this function
      
      The approach taken here is intended to work if omap4xxx_clk_init() is
      converted into an initcall.
      
      Thanks to Bjarne Steinsbo <bsteinsbo@gmail.com> for proposing another
      approach.
      Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      Cc: Bjarne Steinsbo <bsteinsbo@gmail.com>
      450a37d2
  19. 20 8月, 2011 1 次提交
    • P
      OMAP4: clock: re-enable previous clockdomain enable/disable sequence · 9c5f5601
      Paul Walmsley 提交于
      After commit 665d0013 ("OMAP2+: hwmod:
      Follow the recommended PRCM module enable sequence"), device drivers
      for OMAP IP blocks that do not use runtime PM can cause oopses or
      kernel instability[1][2].
      
      This is because those non-runtime PM drivers do not use the hwmod
      code, which implements the correct IP block enable and disable
      sequence.
      
      Several options for dealing with this problem have been proposed:
      
      1. Add a new field to the OMAP struct clk to mark clocks that are
         currently used by non-runtime PM drivers.  Modify the clock code to
         use the old clockdomain sequence for these marked clocks.  As
         drivers are converted to use runtime PM, remove the annotation from
         the clocks.
      
      2. Similar to #1, but associate the flag with the struct omap_clk
         instead.
      
      3. Add IDLEST wait support to the OMAP4 clock code, similar to the way
         it is implemented for OMAP2/3, and enable it in each struct clk
         currently used by non-runtime PM drivers.  As drivers are converted
         to use runtime PM, remove the annotation from the clocks.
      
      4. Do nothing; leave the problem to those responsible for the
         unconverted drivers.
      
      5. Re-enable clock-based clockdomain control in the OMAP4 clock code.
         This would revert back to the behavior of Linux 3.0, simply with a
         slightly longer module enable/disable latency.
      
      Unfortunately, no approach seemed particularly good.  Options 1
      through 3 seemed unwise due to the following reasons:
      
      A. The OMAP struct clks are intended primarily to describe hardware
         clock nodes, and the intention is that no driver-specific data
         should be stored there (applies to #1)
      
      B. The resulting patch would have been quite large for the -rc series
         (applies to #1, #2, #3)
      
      C. The patch would have been a new, yet temporary hack; and similar fixes
         have drawn negative comments in the recent past (see for example [3])
      
      Option 4 is undesirable because commit
      665d0013 ("OMAP2+: hwmod: Follow the
      recommended PRCM module enable sequence") has resulted in a less
      stable kernel; and kernel stability is more important than OMAP4 power
      management.
      
      Option 5 is the approach taken in this patch.  This seemed to be the
      least intrusive approach for 3.1-rc.
      
      The approach in this patch was originally proposed by Ohad Ben-Cohen
      <ohad@wizery.com>.  I'm simply writing the commit message and passing
      it along.
      
      ...
      
      Thanks to Luciano Coelho <coelho@ti.com> for reporting the problem.
      Thanks to Ohad Ben-Cohen <ohad@wizery.com> for tracking the problem
      down, generating a temporary workaround, and proposing a patch to deal
      with the problem.  Thanks to Rajendra Nayak <rnayak@ti.com> for
      proposing another patch to deal with the problem.  Thanks to Felipe
      Balbi <balbi@ti.com> for comments.
      
      1. Coelho, Luciano <coelho@ti.com>.  _Re: Oops on ehci_hcd when
         booting 3.0.0-rc2 on panda_.  Tue, 09 Aug 2011 14:26:08 +0300.
         Posted to the <linux-omap@vger.kernel.org> mailing list.  Available
         from (among others)
         http://www.spinics.net/linux/lists/linux-omap/msg55213.html
      
      2. Munegowda, Keshava <keshava_mgowda@ti.com>. _Re: Oops on ehci_hcd
         when booting 3.0.0-rc2 on panda_.  Thu, 11 Aug 2011 13:51:05 +0530.
         Posted to the <linux-omap@vger.kernel.org> mailing list.  Available
         from (among others)
         http://www.spinics.net/linux/lists/linux-omap/msg55371.html
      
      3. King, Russell <linux@arm.linux.org.uk>.  _Re: [PATCH 5/8] OMAP4:
         PM: TEMP: Prevent l3init from idling/force sleep_.  Thu, 23 Jun
         2011 16:22:49 +0100.  Posted to the <linux-omap@vger.kernel.org>
         mailing list.  Available from (among others)
         http://www.mail-archive.com/linux-omap@vger.kernel.org/msg51392.htmlSigned-off-by: NPaul Walmsley <paul@pwsan.com>
      Cc: Luciano Coelho <coelho@ti.com>
      Cc: Ohad Ben-Cohen <ohad@wizery.com>
      Cc: Rajendra Nayak <rnayak@ti.com>
      Cc: Benoît Cousson <b-cousson@ti.com>
      Acked-by: NSantosh Shilimkar <santosh.shilimkar@ti.com>
      
      9c5f5601
  20. 10 7月, 2011 11 次提交
  21. 08 7月, 2011 1 次提交
  22. 21 4月, 2011 1 次提交
    • T
      OMAP4: clock data: Change DSS clock aliases · 2df122f5
      Tomi Valkeinen 提交于
      DSS driver has used fck and ick clocks on OMAP2/3 to get DSS HW up and
      running, and also to get the pixel clock's source clock rate from the
      fck.
      
      On OMAP4 the clock data is set up in a different way, as there's no ick,
      dss_fck points to a fake clock which just affects DSS's MODULEMODE, and
      dss_dss_clk if the DSS_FCK.
      
      >From DSS driver's point of view the dss_fck sounds like an ick, and
      dss_dss_clk is the fck. While this is not entirely correct from HW point
      of view, especially for the ick, configuring the clock aliases that way
      makes DSS "just work" with OMAP4's clock setup.
      
      In the (hopefully near) future DSS driver will be reworked to use
      pm_runtime support which should clean up the clock code.
      Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
      Cc: Benoît Cousson <b-cousson@ti.com>
      Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      2df122f5