1. 12 12月, 2012 2 次提交
    • T
      OMAPDSS: DISPC: remove dispc fck uses · 8105c94b
      Tomi Valkeinen 提交于
      The previous patch changes dispc to get the dispc fck rate from dss core
      driver. This was the only use of the dispc fck in dispc, and thus we can
      now remove the clock handling.
      Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
      8105c94b
    • T
      OMAPDSS: DISPC: get dss clock rate from dss driver · 5aaee69d
      Tomi Valkeinen 提交于
      Dispc currently gets dispc's fck with clk_get() and uses clk_get_rate()
      to get the rate for scaling calculations. This causes a problem with
      common clock framework, as omapdss uses the dispc functions inside a
      spinlock, and common clock framework uses a mutex in clk_get_rate().
      
      Looking at the DSS clock tree, the above use of the dispc fck is not
      quite correct. The DSS_FCLK from PRCM goes to DSS core block, which has
      a mux to select the clock for DISPC from various options, so the current
      use of dispc fck bypasses that. Fortunately we never change the dispc
      clock mux for now.
      
      To fix the issue with clk_get_rate(), this patch caches the dss clock
      rate in dss.c when it is set. Dispc will then ask for the clock rate
      from dss. While this is not very elegant, it does fix the issue, and
      it's not totally wrong when considering that the dispc fck actually
      comes via dss.
      
      In the future we should probably look into common clock framework and
      see if that could be used to represent the DSS clock tree properly.
      Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
      5aaee69d
  2. 10 12月, 2012 1 次提交
    • T
      Merge omapdss compat layer work · d10ecc58
      Tomi Valkeinen 提交于
      We have two separate, exclusive, users of omapdss: 1) omapfb + omap_vout and 2)
      omapdrm. Because omapfb and omap_vout are independent drivers, we've built
      layers in omapdss to manage the two simultaneous callers. These layers are not
      needed for omapdrm, as omapdrm is the sole user of omapdss, and these layers in
      fact only create trouble for omapdrm.
      
      The simple option to improve omapdrm situation would be to copy the omapdss
      code for omapdrm. We are trying to avoid this, as omapdss and the panel drivers
      are quite a lot of code together, and most of the code would be used without
      change.
      
      Thus this series helps the situation by moving the omapdss code required by
      omapfb + omap_vout to separate files, creating a distinct layer used only by
      omapfb + omap_vout. We call this layer "compat layer". This compat layer then
      uses the core omapdss driver to operate the hardware. omapdrm will use the core
      omapdss directly, without any layers in between.
      
      After this series, omapfb, omap_vout and omapdrm can all be compiled at the
      same time. Obviously omapdrm and omapfb+omap_vout cannot be run at the same
      time (the first one to start will "win"), so compiling them at the same time is
      only sensible as modules for testing purposes. Normal users should only compile
      one of those.
      
      This series does not make omapdrm use the core omapdss API, that will happen in
      a separate series for omapdrm.
      d10ecc58
  3. 07 12月, 2012 23 次提交
  4. 30 11月, 2012 3 次提交
  5. 29 11月, 2012 1 次提交
    • A
      OMAPDSS: Use only "omapdss_dss" platform device to get context lost count · bdb736ab
      Archit Taneja 提交于
      When enabling a hwmod, omap_hwmod refers to the register mentioned in the
      hwmod struct's member 'prcm.omap4.context_offs' to see whether context was
      lost or not. It increments the context lost count for the hwmod and then clears
      the register.
      
      All the DSS hwmods have the same register(RM_DSS_DSS_CONTEXT) as context_offs.
      When DSS is enabled, the first hwmod to be enabled is the "dss_core" hwmod since
      it's corresponding platform device is the parent platform device("omapdss_dss").
      The dss_core hwmod updates it's context lost count correctly and clears the
      register. When the hwmods corresponding to the children platform devices are
      enabled, they see that the register is clear, and don't increment their context
      lost count. Therefore, all the children platform devices never report a loss in
      context.
      
      The DISPC driver currently gets the context lost count for DSS power domain from
      it's corresponding platform device instance("omapdss_dispc"). The DISPC platform
      device is one of the child devices, and it's corresponding hwmod("dss_dispc")
      doesn't report the context lost count correctly.
      
      Modify dss_get_ctx_loss_count() such that it always takes the "omapdss_dss"
      platform device as it's input, move the function to dss.c so that it has access
      to that platform device.
      Signed-off-by: NArchit Taneja <archit@ti.com>
      Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
      bdb736ab
  6. 27 11月, 2012 10 次提交