1. 29 12月, 2015 1 次提交
  2. 17 12月, 2015 1 次提交
  3. 02 7月, 2015 1 次提交
    • T
      OMAPDSS: fix probing if rfbi device is enabled · 0438ec90
      Tomi Valkeinen 提交于
      After the commit 736e60dd ("OMAPDSS:
      componentize omapdss") the dss core device will wait until all the
      subdevices have been successfully probed. However, we don't have a
      working driver for RFBI, so if RFBI device exists, omapdss will never
      get probed.
      
      All the .dtsi files set RFBI as disabled, except am4372.dtsi. This
      causes omapdss probe to not finish on AM4 devices.
      
      This patch makes omapdss driver skip adding rfbi device as a
      subcomponent, solving the issue.
      
      This should be reverted when we have a working RFBI driver.
      Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
      Reported-by: NFelipe Balbi <balbi@ti.com>
      0438ec90
  4. 17 6月, 2015 5 次提交
    • T
      OMAPDSS: componentize omapdss · 736e60dd
      Tomi Valkeinen 提交于
      omapdss kernel module contains drivers for multiple devices, one for
      each DSS submodule. The probing we have at the moment is a mess, and
      doesn't give us proper deferred probing nor ensure that all the devices
      are probed before omapfb/omapdrm start using omapdss.
      
      This patch solves the mess by using the component system for DSS
      submodules.
      
      The changes to all DSS submodules (dispc, dpi, dsi, hdmi4/5, rfbi, sdi,
      venc) are the same: probe & remove functions are changed to bind &
      unbind, and new probe & remove functions are added which call
      component_add/del.
      
      The dss_core driver (dss.c) acts as a component master. Adding and
      matching the components is simple: all dss device's child devices are
      added as components.
      
      However, we do have some dependencies between the drivers. The order in
      which they should be probed is reflected by the list in core.c
      (dss_output_drv_reg_funcs). The drivers are registered in that order,
      which causes the components to be added in that order, which makes the
      components to be bound in that order. This feels a bit fragile, and we
      probably should improve the code to manage binds in random order.
      However, for now, this works fine.
      Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
      Acked-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
      736e60dd
    • T
      OMAPDSS: remove uses of __init/__exit · ede92695
      Tomi Valkeinen 提交于
      The following patches will add component handling to omapdss, improving
      the handling of deferred probing. However, at the moment we're using
      quite a lot of __inits and __exits in the driver, which prevent normal
      dynamic probing and removal.
      
      This patch removes most of the uses of __init and __exit, so that we can
      register drivers after module init, and so that we can unregister
      drivers even if the module is built-in.
      Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
      Acked-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
      ede92695
    • T
      OMAPDSS: fix dss_init_ports error handling · f5a1a1f8
      Tomi Valkeinen 提交于
      The return value of dss_init_ports() is not handled at all, causing
      crashes later if the call failed.
      
      This patch adds the error handling, and we also move the call to a
      slightly earlier place to make bailing out easier.
      Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
      Acked-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
      f5a1a1f8
    • T
      OMAPDSS: refactor dss probe function · 7e328f5a
      Tomi Valkeinen 提交于
      Refactor dss probe function by extracting the setup for video plls into
      a separate function. The call to this function is also moved to a
      slightly earlier phase, so that in error case we can bail out more
      easily.
      Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
      Acked-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
      7e328f5a
    • T
      OMAPDSS: move 'dss_initialized' to dss driver · f99467b3
      Tomi Valkeinen 提交于
      We have a flag, 'dss_initialized', which tells omapfb and omapdrm if
      omapdss is available. At the moment it can be set even if the dss
      submodules are not all ready, in case something gets deferred.
      
      Move the flag to dss_core driver so that it'll signal the availability
      of the dss drivers move accurately.
      
      For now, it'll signal that dss_core is ready, which is not quite correct
      but still better than previously.  The following patches will add
      component system to omapdss, and after those patches 'dss_initialized'
      will signal that all the submodules are ready.
      Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
      Acked-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
      f99467b3
  5. 20 4月, 2015 1 次提交
  6. 04 2月, 2015 4 次提交
  7. 12 11月, 2014 5 次提交
    • T
      OMAPDSS: DSI: remove unused hsdiv wait funcs · d845600e
      Tomi Valkeinen 提交于
      With the previous patch "OMAPDSS: DSI: wait for hsdiv clocks when
      enabling PLL",  dsi_wait_pll_hsdiv_dispc_active and
      dsi_wait_pll_hsdiv_dsi_active are no longer needed, so they and the
      callers can be removed.
      Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
      d845600e
    • A
      OMAPDSS: DSS: add a param to dpi_select_source which specifies it's port number · 064c2a47
      Archit Taneja 提交于
      Add a 'port' parameter in dpi_select_source. The param tells the port
      number of the DPI instance that we want to configure. We use this number
      to select the overlay manager for that DPI instance.
      Signed-off-by: NArchit Taneja <archit@ti.com>
      Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
      064c2a47
    • A
      OMAPDSS: DSS: init dss ports cleanly · 387ce9f2
      Archit Taneja 提交于
      The init/uninit port functions are used to set up the DPI and SDI outputs under
      the dss platform device. A 'reg' property is used to determine the port number
      of the output. This tells us whether the port is DPI or SDI for OMAP34xx DSS
      revision. For other DSS revisions, we only have DPI outputs under the dss
      platform device.
      
      For multiple DPI output instances(introduced in DRA7xx DSS), we will use the
      the port number to specify which DPI output instance is being inited.
      
      The current functions work fine if there is only one DPI output instance in
      DSS. For multiple DPI instances, it would get complicated to figure out whether
      port number was used to specify whether the output is SDI, or another DPI
      instance.
      
      We create a list of port types supported for each DSS rev, with the index of the
      port in the list specifying the port number of the output for that DSS revision.
      This allows us to have a more generic way to init/uninit ports within DSS, and
      also support multiple DPI ports.
      
      We make the uninit_port functions iterative since we will have multiple DPI
      ports to uninit in the future.
      Signed-off-by: NArchit Taneja <archit@ti.com>
      Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
      387ce9f2
    • A
      OMAPDSS: DPI: Store dpi_data pointer in the DT port's data · 80eb6751
      Archit Taneja 提交于
      DPI and SDI ports are backed by only one parent DSS device. We don't have a
      corresponding platform_device for ports under DSS. In order to support multiple
      instances of DPI, we need to pass the driver data pointer through the DPI port's
      private data ('data' member in device_node struct).
      
      dpi_init_output/dpi_uninit_output are untouched and only used for non-DT case,
      these are called when the DPI platform device probed/removed. These funcs will
      be removed when non-DT mode is removed.
      
      dpi_init_output_port/dpi_uninit_output_port are created and used for the DT
      path, called when DSS inits/uninits it's ports. These new functions retrieve
      the dpi_data pointer from 'port->data', and not from the platform device's
      data(pdev->dev) like in the non-DT path.
      
      We add some code in dss_uninit_ports() to pass a pointer to the DPI port in
      dpi_uninit_port().
      Signed-off-by: NArchit Taneja <archit@ti.com>
      Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
      80eb6751
    • A
      OMAPDSS: DPI: Allocate driver data · 2ac6a1aa
      Archit Taneja 提交于
      Allocate driver data(dpi_data) for each DPI instance. It's allocated in
      omap_dpi_probe() when DT isn't used, and in dpi_init_port() when DT is used.
      The dpi_data struct instance is no longer global. In the case of DPI ops, it's
      retrieved from dpi_get_data_from_dssdev(). 'dssdev' passed by the connected
      encoder/panel driver is a pointer to the 'output' member in dpi_data, and thus
      can be used to get the DPI instance's driver data. In the case of probe/ini_port
      functions, it's set as DPI/DSS device's private data embedded in the
      platform_device struct.
      
      Having dpi_data as private data of the platform device will not work for
      multiple DPI instances in the DT case. This is because there is no corresponding
      platform_device for DPI or SDI, they exist only as ports under the parent DSS
      platform_device in the DT case. The DPI port's private data('data' member in
      device_node struct) will later be used to store dpi_data.
      Signed-off-by: NArchit Taneja <archit@ti.com>
      Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
      2ac6a1aa
  8. 22 10月, 2014 1 次提交
    • T
      OMAPDSS: set suppress_bind_attrs · 422ccbd5
      Tomi Valkeinen 提交于
      omapdss drivers cannot handle devices being unbound while the devices
      are part of a connected display pipeline. Module refcounts are used to
      prevent unloading the modules, but one can still manually unbind the
      devices via sysfs, causing crash.
      
      Set suppress_bind_attrs to disable the bind/unbind support via sysfs.
      Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
      422ccbd5
  9. 20 10月, 2014 1 次提交
  10. 09 5月, 2014 4 次提交
  11. 17 4月, 2014 1 次提交
  12. 14 4月, 2014 1 次提交
  13. 04 4月, 2014 1 次提交
  14. 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
  15. 28 2月, 2014 1 次提交
  16. 18 11月, 2013 7 次提交
  17. 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
  18. 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
  19. 10 4月, 2013 1 次提交
  20. 03 4月, 2013 1 次提交