1. 13 Dec, 2012 5 commits
  2. 12 Dec, 2012 2 commits
    • Tomi Valkeinen's avatar
      OMAPDSS: DISPC: remove dispc fck uses · 8105c94b
      Tomi Valkeinen authored
      
      
      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: default avatarTomi Valkeinen <tomi.valkeinen@ti.com>
      8105c94b
    • Tomi Valkeinen's avatar
      OMAPDSS: DISPC: get dss clock rate from dss driver · 5aaee69d
      Tomi Valkeinen authored
      
      
      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: default avatarTomi Valkeinen <tomi.valkeinen@ti.com>
      5aaee69d
  3. 10 Dec, 2012 1 commit
    • Tomi Valkeinen's avatar
      Merge omapdss compat layer work · d10ecc58
      Tomi Valkeinen authored
      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
  4. 07 Dec, 2012 23 commits
  5. 30 Nov, 2012 1 commit
  6. 29 Nov, 2012 3 commits
  7. 27 Nov, 2012 5 commits