1. 09 5月, 2014 2 次提交
  2. 17 4月, 2014 1 次提交
  3. 14 4月, 2014 1 次提交
  4. 04 4月, 2014 1 次提交
  5. 19 3月, 2014 1 次提交
    • T
      OMAPDSS: Add DT support to DSS · 2ecef246
      Tomi Valkeinen 提交于
      Add DT support for DSS. Contrary to the non-DT version, the DSS in DT
      mode contains DPI and SDI outputs, which better reflects the hardware.
      The non-DT code will be removed after all boards have been converted to
      DT, so there's no need to change the non-DT code to act the same way.
      
      The code for DPI and SDI needs to be refined later to make it possible
      to add multiple DPI ports. For now, handling just a single DPI port is
      enough for all the boards.
      Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
      Reviewed-by: NArchit Taneja <archit@ti.com>
      2ecef246
  6. 28 2月, 2014 1 次提交
  7. 18 11月, 2013 7 次提交
  8. 17 6月, 2013 1 次提交
    • T
      OMAPDSS: fix dss_get_ctx_loss_count for DT · 679852db
      Tomi Valkeinen 提交于
      When using DT, dss device does not have platform data. However,
      dss_get_ctx_loss_count() uses dss device's platform data to find the
      get_ctx_loss_count function pointer.
      
      To fix this, dss_get_ctx_loss_count() needs to be changed to get the
      platform data from the omapdss device, which is a "virtual" device and
      always has platform data.
      Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
      679852db
  9. 11 4月, 2013 1 次提交
    • T
      OMAPDSS: fix dss_fck clock rate rounding · 648a55e1
      Tomi Valkeinen 提交于
      DSS func clock is calculated with prate / div * m. However, the current
      omapdss code calculates it with prate * m / div, which yields a slightly
      different result when there's a remainder. For example, 432000000 / 14 *
      2 = 61714284, but 432000000 * 2 / 14 = 61714285.
      
      In addition to that, the clock framework wants the clock rate given with
      clk_set_rate to be higher than the actual (truncated) end result. So, if
      prate is 432000000, and div is 14, the real result is 30857142.8571...
      We need to call clk_set_rate with 30857143, which gives us a clock of
      30857142. That's why we need to use DIV_ROUND_UP() when calling
      clk_set_rate.
      
      This patch fixes the clock calculation.
      Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
      648a55e1
  10. 10 4月, 2013 1 次提交
  11. 03 4月, 2013 2 次提交
  12. 12 12月, 2012 1 次提交
    • 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
  13. 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
  14. 22 11月, 2012 1 次提交
  15. 05 11月, 2012 3 次提交
    • T
      OMAPDSS: hide dss_select_dispc_clk_source() · a5b8399f
      Tomi Valkeinen 提交于
      dss.c currently exposes functions to configure the dispc source clock
      and lcd source clock. There are configured separately from the output
      drivers.
      
      However, there is no safe way for the output drivers to handle dispc
      clock, as it's shared between the outputs. Thus, if, say, the DSI driver
      sets up DSI PLL and configures both the dispc and lcd clock sources to
      that DSI PLL, the resulting dispc clock could be too low for, say, HDMI.
      
      Thus the output drivers should really only be concerned about the lcd
      clock, which is what the output drivers actually use. There's lot to do
      to clean up the dss clock handling, but this patch takes one step
      forward and removes the use of dss_select_dispc_clk_source() from the
      output drivers.
      
      After this patch, the output drivers only configure the lcd source
      clock. On omap4+ the dispc src clock is never changed from the default
      PRCM source. On omap3, where the dispc and lcd clocks are actually the
      same, setting the lcd clock source sets the dispc clock source.
      Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
      a5b8399f
    • T
      OMAPDSS: setup default dss fck · 13a1a2b2
      Tomi Valkeinen 提交于
      We don't currently set the dss fck when starting up. This is not a
      problem, as we setup the fck later when configuring the pixel clocks. Or
      this is how it was for omap2, for the rest of the omaps this may not be
      so.
      
      For DSI, HDMI and also for DPI when using DSI PLL, we don't need to
      change the dss fck, and thus it may be left unconfigured. Usually the
      dss fck is already setup fine by default, but we can't trust this.
      
      This patch sets the dss fck to maximum at probe time.
      Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
      13a1a2b2
    • T
      OMAPDSS: add dss_calc_clock_rates() back · 930b027e
      Tomi Valkeinen 提交于
      dss_calc_clock_rates() was removed earlier as it was not used, but it is
      needed for DSI PLL calculations, so this patch adds it back.
      Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
      930b027e
  16. 29 10月, 2012 1 次提交
  17. 26 10月, 2012 1 次提交
  18. 24 10月, 2012 1 次提交
    • T
      OMAPDSS: get the dss version from core pdev · b2c7d54f
      Tomi Valkeinen 提交于
      The output drivers get the omapdss hw version from the platform data for
      their respective output device. This doesn't work with DT, as there's no
      platform data for them.
      
      Add a new function, omapdss_get_version(), which returns the dss version
      from the core device, which will have platform data on DT also. The
      function is exported so that users of omapdss can also use it.
      Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
      b2c7d54f
  19. 17 10月, 2012 2 次提交
  20. 16 10月, 2012 1 次提交
  21. 12 10月, 2012 1 次提交
  22. 24 9月, 2012 3 次提交
  23. 08 9月, 2012 1 次提交
  24. 22 8月, 2012 2 次提交
  25. 16 8月, 2012 1 次提交
    • A
      OMAPDSS: SDI: Maintain copy of data pairs in driver data · 889b4fd7
      Archit Taneja 提交于
      The SDI driver currently relies on the omap_dss_device struct to configure the
      number of data pairs as specified by the panel. This makes the SDI interface
      driver dependent on the omap_dss_device struct.
      
      Make the SDI driver data maintain it's own data lines field. A panel driver
      is expected to call omapdss_sdi_set_datapairs() before enabling the interface.
      Even though we configure the number of data pairs here, this function would be
      finally mapped to a generic interface op called set_data_lines. The datapairs
      argument type has been changed from u8 to int at some places to be in sync with
      the 'set_data_lines' ops of other interfaces.
      Signed-off-by: NArchit Taneja <archit@ti.com>
      889b4fd7
  26. 10 8月, 2012 1 次提交
    • R
      OMAPDSS: DISPC: Improvements to DIGIT sync signal selection · 8aa2eed1
      Ricardo Neri 提交于
      DSS code wrongly assumes that VENC is always available as source for the external
      sync signal for the display controller DIGIT channel. One cannot blindly write/read
      the value of DSS_CONTROL[15] as in certain processors (e.g., OMAP5) this operation
      may not be valid. If the the sync source is not read correctly, the callers of
      dss_get_hdmi_venc_clk_source might make wrong assumptions about, for instance,
      video timings.
      
      Logic is added to correctly get the sync signal based on the available displays
      in the DIGIT channel. The source is set only if both VENC and HDMI are supported.
      Signed-off-by: NRicardo Neri <ricardo.neri@ti.com>
      Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
      8aa2eed1