1. 03 4月, 2013 1 次提交
  2. 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
  3. 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
  4. 22 11月, 2012 1 次提交
  5. 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
  6. 29 10月, 2012 1 次提交
  7. 26 10月, 2012 1 次提交
  8. 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
  9. 17 10月, 2012 2 次提交
  10. 16 10月, 2012 1 次提交
  11. 12 10月, 2012 1 次提交
  12. 24 9月, 2012 3 次提交
  13. 08 9月, 2012 1 次提交
  14. 22 8月, 2012 2 次提交
  15. 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
  16. 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
  17. 08 7月, 2012 1 次提交
    • T
      OMAPDSS: fix warnings if CONFIG_PM_RUNTIME=n · 373b4365
      Tomi Valkeinen 提交于
      If runtime PM is not enabled in the kernel config, pm_runtime_get_sync()
      will always return 1 and pm_runtime_put_sync() will always return
      -ENOSYS. pm_runtime_get_sync() returning 1 presents no problem to the
      driver, but -ENOSYS from pm_runtime_put_sync() causes the driver to
      print a warning.
      
      One option would be to ignore errors returned by pm_runtime_put_sync()
      totally, as they only say that the call was unable to put the hardware
      into suspend mode.
      
      However, I chose to ignore the returned -ENOSYS explicitly, and print a
      warning for other errors, as I think we should get notified if the HW
      failed to go to suspend properly.
      Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
      Cc: Jassi Brar <jaswinder.singh@linaro.org>
      Cc: Grazvydas Ignotas <notasas@gmail.com>
      Signed-off-by: NArchit Taneja <archit@ti.com>
      Signed-off-by: NFlorian Tobias Schandinat <FlorianSchandinat@gmx.de>
      373b4365
  18. 29 6月, 2012 3 次提交
    • A
      OMAPDSS: Remove passive matrix LCD support (part 1) · 6d523e7b
      Archit Taneja 提交于
      Remove clock constraints related to passive matrix displays.
      
      There is a constraint (pcd_min should be 3) for passive matrix displays. Remove
      this constraint in clock divider calculations as we won't support passive
      matrix displays any more.
      
      This cleans up the functions which calculate the clock dividers with DSI's PLL
      or DSS_FCLK as the clock source.
      Signed-off-by: NArchit Taneja <archit@ti.com>
      6d523e7b
    • C
      OMAPDSS: Add LCD3 overlay manager and Clock and IRQ support · e86d456a
      Chandrabhanu Mahapatra 提交于
      The support for LCD3 manager has been added into the manager module. LCD3 panel
      has registers as DISPC_CONTROL3 and DISPC_CONFIG3 just like those in LCD and
      LCD2 panels. These registers control the Display Controller (DISPC) module for
      LCD3 output. The three LCDs support Display Serial Interface (DSI), Remote Frame
      Buffer Interface (RFBI) and Parallel CMOS Output Interface (DPI). These LCDs can
      be connected through parallel output interface using DISPC and RFBI or DPI. For
      serial interface DSS uses DSI.
      
      The LCD3 panel, just like LCD and LCD2 panels, has a clock switch in DSS_CTRL
      register which has been enabled. The clock switch chooses between DSS_CLK and
      DPLL_DSI1_C_CLK1 as source for LCD3_CLK. New IRQs as DISPC_IRQ_VSYNC3,
      DISPC_IRQ_FRAMEDONE3, DISPC_IRQ_ACBIAS_COUNT_STAT3 and DISPC_IRQ_SYNC_LOST3 have
      been added specific to the new manager.
      Signed-off-by: NChandrabhanu Mahapatra <cmahapatra@ti.com>
      Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
      e86d456a
    • T
      OMAPDSS: fix warnings if CONFIG_PM_RUNTIME=n · 5be3aebd
      Tomi Valkeinen 提交于
      If runtime PM is not enabled in the kernel config, pm_runtime_get_sync()
      will always return 1 and pm_runtime_put_sync() will always return
      -ENOSYS. pm_runtime_get_sync() returning 1 presents no problem to the
      driver, but -ENOSYS from pm_runtime_put_sync() causes the driver to
      print a warning.
      
      One option would be to ignore errors returned by pm_runtime_put_sync()
      totally, as they only say that the call was unable to put the hardware
      into suspend mode.
      
      However, I chose to ignore the returned -ENOSYS explicitly, and print a
      warning for other errors, as I think we should get notified if the HW
      failed to go to suspend properly.
      Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
      Cc: Jassi Brar <jaswinder.singh@linaro.org>
      Cc: Grazvydas Ignotas <notasas@gmail.com>
      5be3aebd
  19. 04 6月, 2012 1 次提交
    • T
      OMAPDSS: fix bogus WARN_ON in dss_runtime_put() · 5025ce07
      Tomi Valkeinen 提交于
      pm_runtime_put_sync() in dss_runtime_put() returns -EBUSY when any child
      of dss is still enabled. This happens, for example, when a display
      output is enabled and one dumps the clocks via debugfs. This causes
      dss_runtime_get & put to be called.
      
      While I couldn't find anything about this in the documentation and it
      wasn't immediately clear from runtime_pm code, it looks to me that
      pm_runtime_put_sync() returns -EBUSY to inform that things went fine,
      but the device could not be turned off as there are still child devices
      that are enabled. This is not a problem.
      
      This patch skips the WARN_ON if pm_runtime_put_sync() returns -EBUSY.
      Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
      5025ce07
  20. 22 5月, 2012 1 次提交
    • T
      OMAPDSS: remove compiler warnings when CONFIG_BUG=n · c6eee968
      Tomi Valkeinen 提交于
      If CONFIG_BUG is not enabled, BUG() does not stop the execution. Many
      places in code expect the execution to stop, and this causes compiler
      warnings about uninitialized variables and returning from a non-void
      function without a return value.
      
      This patch fixes the warnings by initializing the variables and
      returning properly after BUG() lines. However, the behaviour is still
      undefined after the BUG, but this is the choice the user makes when
      using CONFIG_BUG=n.
      Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
      c6eee968
  21. 11 5月, 2012 6 次提交
  22. 09 5月, 2012 1 次提交
  23. 23 4月, 2012 1 次提交
    • T
      OMAPDSS: Ensure OPP100 when DSS is operational · a8081d31
      Tomi Valkeinen 提交于
      Most of the DSS clocks have restrictions on their frequency based on the
      OPP in use. For example, maximum frequency for a clock may be 180MHz in
      OPP100, but 90MHz in OPP50. This means that when a high enough pixel
      clock or function clock is required, we need to use OPP100.
      
      However, there's currently no way in the PM framework to make that kind
      of request. The closest we get is to ask for very high bus throughput
      from the PM framework, which should effectively force OPP100.
      
      This patch is a simple version for handling the problem. Instead of
      asking for OPP100 only when needed, this patch asks for OPP100 whenever
      DSS is active. This obviously is not an optimal solution for cases with
      small displays where OPP50 would work just fine. However, a proper
      solution is a complex one, and this patch is a short term solution for
      the problem.
      Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
      Cc: Paul Walmsley <paul@pwsan.com>
      Acked-by: NKevin Hilman <khilman@ti.com>
      a8081d31
  24. 25 2月, 2012 1 次提交
  25. 21 2月, 2012 1 次提交
    • T
      OMAPDSS: cleanup probe functions · cd3b3449
      Tomi Valkeinen 提交于
      Now that dss is using devm_ functions for allocation in probe functions,
      small reordering of the allocations allows us to clean up the probe
      functions more.
      
      This patch moves "unmanaged" allocations after the managed ones, and
      uses plain returns instead of gotos where possible. This lets us remove
      a bunch of goto labels, simplifying the probe's error handling.
      Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
      cd3b3449
  26. 26 1月, 2012 1 次提交
    • T
      OMAPDSS: use sync versions of pm_runtime_put · 0eaf9f52
      Tomi Valkeinen 提交于
      omapdss doesn't work properly on system suspend. The problem seems to be
      the fact that omapdss uses pm_runtime_put() functions when turning off
      the hardware, and when system suspend is in process only sync versions
      are allowed.
      
      Using non-sync versions normally and sync versions when suspending would
      need rather ugly hacks to convey the information of
      suspending/not-suspending to different functions. Optimally the driver
      wouldn't even need to care about this, and the PM layer would handle
      syncing when suspend is in process.
      
      This patch changes all omapdss's pm_runtime_put calls to
      pm_runtime_put_sync. This fixes the suspend problem, and probably the
      performance penalty of always using sync versions is negligible.
      Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
      Acked-by: NKevin Hilman <khilman@ti.com>
      0eaf9f52
  27. 25 1月, 2012 1 次提交