1. 02 11月, 2016 15 次提交
  2. 03 6月, 2016 1 次提交
  3. 03 3月, 2016 1 次提交
  4. 29 12月, 2015 2 次提交
  5. 17 6月, 2015 2 次提交
    • 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
  6. 26 2月, 2015 1 次提交
    • T
      OMAPDSS: DISPC: remove OMAPDSS_DRIVE_SIG_OPPOSITE_EDGES · 7a16360d
      Tomi Valkeinen 提交于
      DISPC can drive data lines either on rising or falling pixel clock edge,
      which can be configured by the user.
      
      Sync lines can also be driven on rising or falling pixel clock edge, but
      additionally the HW can be configured to drive the sync lines on
      opposite clock edge from the data lines.
      
      This opposite edge setting does not make any sense, as the same effect
      can be achieved by just setting the sync lines to be driven on the other
      edge compared to the data lines. It feels like some kind of backward
      compatibility option, even if all DSS versions seem to have the same
      implementation.
      
      To simplify the code and configuration of the signals, and to make the
      dispc timings more compatible with what is used on other platforms,
      let's just remove the whole opposite-edge support.
      
      The drivers that used OMAPDSS_DRIVE_SIG_OPPOSITE_EDGES setting are
      changed so that they use the opposite setting from the data edge.
      Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
      7a16360d
  7. 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
  8. 20 10月, 2014 1 次提交
  9. 17 4月, 2014 1 次提交
  10. 29 8月, 2013 1 次提交
  11. 17 6月, 2013 6 次提交
    • T
      OMAPDSS: public omapdss_register_output() · 5d47dbc8
      Tomi Valkeinen 提交于
      In order to allow multiple display block in a video pipeline, we need to
      give the drivers way to register themselves. For now we have
      the omapdss_register_display() which is used to register panels, and
      dss_register_output() which is used to register DSS encoders.
      
      This patch makes dss_register_output() public (with the name of
      omapdss_register_output), which can be used to register also external
      encoders. The distinction between register_output and register_display
      is that a "display" is an entity at the end of the videopipeline, and
      "output" is something inside the pipeline.
      
      The registration and naming will be made saner in the future, but the
      current names and functions are kept to minimize changes during the dss
      device model transition.
      Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
      5d47dbc8
    • T
      OMAPDSS: add THIS_MODULE owner to DSS outputs · b7328e14
      Tomi Valkeinen 提交于
      Setup the owner field for DSS output's omap_dss_device so that module
      refcounting works.
      Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
      b7328e14
    • T
      OMAPDSS: combine omap_dss_output into omap_dss_device · 1f68d9c4
      Tomi Valkeinen 提交于
      We currently have omap_dss_device, which represents an external display
      device, sometimes an external encoder, sometimes a panel. Then we have
      omap_dss_output, which represents DSS's output encoder.
      
      In the future with new display device model, we construct a video
      pipeline from the display blocks. To accomplish this, all the blocks
      need to be presented by the same entity.
      
      Thus, this patch combines omap_dss_output into omap_dss_device. Some of
      the fields in omap_dss_output are already found in omap_dss_device, but
      some are not. This means we'll have DSS output specific fields in
      omap_dss_device, which is not very nice. However, it is easier to just
      keep those output specific fields there for now, and after transition to
      new display device model is made, they can be cleaned up easier than
      could be done now.
      Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
      1f68d9c4
    • T
      OMAPDSS: remove omap_dss_start/stop_device() · d3923933
      Tomi Valkeinen 提交于
      The omap_dss_start_device() and omap_dss_stop_device(), called by the
      DSS output drivers, are old relics. They originally did something
      totally else, but nowadays they increase the module ref count for panels
      that are enabled.
      
      This model is quite broken: the panel modules may be used even before
      they are enabled. For example, configuring the panel requires calls to
      functions located in the panel modules.
      
      In the following patches we try to improve the ref count management for
      the modules and display devices. The first step, however, is to remove
      the omap_dss_start/stop_device() totally.
      Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
      d3923933
    • T
      OMAPDSS: remove dssdev uses in trivial cases · 7ae9a71e
      Tomi Valkeinen 提交于
      In the future the "dssdev" parameter passed to output drivers will
      change its meaning. Instead of being a pointer to the panel device, it's
      a pointer to the output instance.
      
      To make the transition easier, some of the uses for this dssdev
      parameter can be easily removed.
      Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
      7ae9a71e
    • T
      OMAPDSS: only probe pdata if there's one · c6ca5b22
      Tomi Valkeinen 提交于
      omapdss output drivers always read the platform data. This crashes when
      there's no platform data when using DT.
      
      Add a check to read the platform data only if it exists.
      Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
      c6ca5b22
  12. 02 5月, 2013 2 次提交
  13. 03 4月, 2013 2 次提交
    • T
      OMAPDSS: add output->dispc_channel · 2eea5ae6
      Tomi Valkeinen 提交于
      The DISPC channel used for each output is currently passed in panel
      platform data from the board files.
      
      To simplify this, and to make the panel drivers less dependent on OMAP,
      this patch changes omapdss to resolve the channel independently. The
      channel is resolved based on the OMAP version and, in case of DSI, the
      DSI module id. This resolved channel is stored into a new field in
      output, dispc_channel.
      
      The few places where dssdev->channel was used are changed to use
      output->recommended_channel. After this patch, dssdev->channel is
      obsolete.
      Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
      Reviewed-by: NArchit Taneja <archit@ti.com>
      2eea5ae6
    • T
      OMAPDSS: add output->name · 7286a08f
      Tomi Valkeinen 提交于
      Add name field to omapdss's outputs so that in the following patches
      panels refer to the output by their name. The name also helps debugging.
      Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
      Reviewed-by: NArchit Taneja <archit@ti.com>
      7286a08f
  14. 07 12月, 2012 2 次提交
    • T
      OMAPDSS: manage framedone irq with mgr ops · 1550202d
      Tomi Valkeinen 提交于
      Some of the output drivers need to handle FRAMEDONE interrupt from
      DISPC. This creates a direct dependency to dispc code, and we need to
      avoid this to make the compat code to work.
      
      Instead of the output drivers registering for dispc interrupts, we
      create new mgr-ops that are used to register a framedone handler. The
      code implementing the mgr-ops is responsible for calling the handler
      when DISPC FRAMEDONE interrupt happens. The compat layer is improved
      accordingly to do the call to the framedone handler.
      Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
      1550202d
    • T
      OMAPDSS: manage output-dssdev connection in output drivers · 486c0e17
      Tomi Valkeinen 提交于
      We currently attach an output to a dssdev in the initialization code for
      dssdevices in display.c. This works, but doesn't quite make sense: an
      output entity represents (surprisingly) an output of DSS, which is
      managed by an output driver. The output driver also handles adding new
      dssdev's for that particular output.
      
      It makes more sense to make the output-dssdev connection in the output
      driver. This is also in line with common display framework.
      Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
      486c0e17
  15. 29 10月, 2012 1 次提交
  16. 26 9月, 2012 1 次提交