1. 11 5月, 2012 4 次提交
    • T
      OMAPDSS: handle output-driver reg/unreg more dynamically · 461395c4
      Tomi Valkeinen 提交于
      Initialize and uninitialize the output drivers by using arrays of
      pointers to the init/uninit functions. This simplifies the code
      slightly.
      Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
      461395c4
    • T
      OMAPDSS: create DPI & SDI drivers · a57dd4fe
      Tomi Valkeinen 提交于
      We currently have separate device/driver for each DSS HW module. The DPI
      and SDI outputs are more or less parts of the DSS or DISPC hardware
      modules, but in SW it makes sense to represent them as device/driver
      pairs similarly to all the other outputs. This also makes sense for
      device tree, as each node under dss will be a platform device, and
      handling DPI & SDI somehow differently than the rest would just make the
      code more complex.
      
      This patch modifies the dpi.c and sdi.c to create drivers for the
      platform devices.
      Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
      a57dd4fe
    • T
      OMAPDSS: use platform_driver_probe for core/dispc/dss · 11436e1d
      Tomi Valkeinen 提交于
      The platform devices for omapdss, dss and dispc drivers are always
      present, so we can use platform_driver_probe instead of
      platform_driver_register.
      Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
      11436e1d
    • T
      OMAPDSS: clean up the omapdss platform data mess · 00928eaf
      Tomi Valkeinen 提交于
      The omapdss pdata handling is a mess. This is more evident when trying
      to use device tree for DSS, as we don't have platform data anymore in
      that case. This patch cleans the pdata handling by:
      
      - Remove struct omap_display_platform_data. It was used just as a
        wrapper for struct omap_dss_board_info.
      - Pass the platform data only to omapdss device. The drivers for omap
        dss hwmods do not need the platform data. This should also work better
        for DT, as we can create omapdss device programmatically in generic omap
        boot code, and thus we can pass the pdata to it.
      - Create dss functions for get_ctx_loss_count and dsi_enable/disable_pads
        that the dss hwmod drivers can call.
      Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
      00928eaf
  2. 23 4月, 2012 2 次提交
    • G
      OMAPDSS: provide default get_timings function for panels · 4b6430fc
      Grazvydas Ignotas 提交于
      With this we can eliminate some duplicate code in panel drivers.
      Also lgphilips-lb035q02, nec-nl8048hl11-01b, picodlp and
      tpo-td043mtea1 gain support of reading timings over sysfs.
      Signed-off-by: NGrazvydas Ignotas <notasas@gmail.com>
      Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
      4b6430fc
    • 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
  3. 21 3月, 2012 1 次提交
    • T
      OMAPDSS: register dss drivers in module init · dc7e57fa
      Tomi Valkeinen 提交于
      We do the dss driver registration in a rather strange way: we have the
      higher level omapdss driver, and we use that driver's probe function to
      register the drivers for the rest of the dss devices.
      
      There doesn't seem to be any reason for that, and additionally the
      soon-to-be-merged patch "ARM: OMAP: omap_device: remove
      omap_device_parent" will break omapdss initialization with the current
      registration model.
      
      This patch changes the registration for all drivers to happen at the
      same place, in the init of the module.
      Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
      Signed-off-by: NFlorian Tobias Schandinat <FlorianSchandinat@gmx.de>
      dc7e57fa
  4. 13 1月, 2012 1 次提交
  5. 02 12月, 2011 1 次提交
    • T
      OMAPDSS: create apply.c · 58f25548
      Tomi Valkeinen 提交于
      Create a new file, apply.c, and move code about handling the
      apply-mechanism and configuration of the managers and overlays from
      manager.c to apply.c.
      
      Not all related code is moved in this patch, but only the core
      apply/configure functions. The later patches move rest of the code from
      overlay.c and manager.c, adding necessary locking at the same time.
      Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
      58f25548
  6. 30 9月, 2011 1 次提交
  7. 25 7月, 2011 2 次提交
  8. 13 5月, 2011 1 次提交
  9. 11 5月, 2011 2 次提交
  10. 16 3月, 2011 1 次提交
  11. 11 3月, 2011 13 次提交
  12. 23 10月, 2010 1 次提交
  13. 18 5月, 2010 3 次提交
  14. 24 2月, 2010 2 次提交
  15. 18 2月, 2010 2 次提交
  16. 15 2月, 2010 2 次提交
  17. 12 2月, 2010 1 次提交
    • T
      OMAP: DSS2: enable VDDS_DSI when using DPI · 8a2cfea8
      Tomi Valkeinen 提交于
      It looks like on OMAP3 some DSS pins need VDDS_DSI to function properly.
      
      This has not been confirmed from TI, but looking at figure 15-1 "Display
      subsystem highlight" from the TRM, some data pins come near the DSI and SDI
      blocks. This is not very hard evidence, but the fact remains that with the
      power on, pixels are ok, and with the power off, pixels are not ok.
      
      It may also be that VDDS_SDI is needed to power some pins, but as normally
      both VDDS_SDI and VDDS_DSI come from the same power source, this hasn't
      been shown.
      
      It seems that a single driver can only get a regulator once. This patch
      solves it by getting all the required regulators in one place, and from
      which the submodules then get the regulators they need.
      Signed-off-by: NTomi Valkeinen <tomi.valkeinen@nokia.com>
      8a2cfea8