1. 13 6月, 2015 2 次提交
  2. 24 3月, 2015 5 次提交
    • T
      drm/omap: keep ref to old_fb · 223bfd69
      Tomi Valkeinen 提交于
      We store the fb being page-flipped to 'old_fb' field, but we don't
      increase the ref count of the fb when doing that. While I am not
      sure if it can cause problem in practice, it's still safer to keep a ref
      when storing a pointer to a fb.
      Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
      223bfd69
    • T
      drm/omap: only ignore DIGIT SYNC LOST for TV output · ef422283
      Tomi Valkeinen 提交于
      We need to ignore DIGIT SYNC LOST error when enabling/disabling TV
      output. The code does that, but it ignores the DIGI SYNC LOST when
      enabling any output. Normally this does no harm, but it could make us
      miss DIGIT SYNC LOST on some rare occasions.
      
      Fix the code to only ignore DIGIT SYNC LOST when enabling/disabling TV.
      Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
      ef422283
    • T
      drm/omap: fix race with error_irq · a36af73f
      Tomi Valkeinen 提交于
      omapdrm tries to avoid error floods by unregistering the error irq when
      an error happens, and then registering the error irq again later.
      However, the code is racy, as it sometimes tries to unregister the error
      irq when it's already unregistered, leading to WARN().
      
      Also, the code only registers the error irq again when something is done
      on that particular output, i.e. if only TV is used to flip the buffers,
      and LCD is showing a same buffer, an error on LCD will cause the LCD
      error irq to be unregistered and never registered again.
      
      To fix this, let's keep the error irqs always enabled and trust the
      DRM_ERROR_RATELIMITED to limit the flood.
      Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
      a36af73f
    • T
      drm/omap: use DRM_ERROR_RATELIMITED() for error irqs · 3b143fc8
      Tomi Valkeinen 提交于
      omapdrm uses normal DRM_ERROR() print when the HW reports an error. As
      we sometimes may get a flood of errors, let's rather use
      DRM_ERROR_RATELIMITED().
      Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
      3b143fc8
    • T
      drm/omap: page_flip: return -EBUSY if flip pending · 549a7549
      Tomi Valkeinen 提交于
      The DRM documentation says:
      
      "If a page flip is already pending, the page_flip operation must return
      -EBUSY."
      
      Currently omapdrm returns -EINVAL instead. Fix omapdrm by returning
      -EBUSY.
      Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
      549a7549
  3. 20 3月, 2015 8 次提交
  4. 05 11月, 2014 1 次提交
  5. 05 6月, 2014 1 次提交
    • R
      drm: convert crtc and connection_mutex to ww_mutex (v5) · 51fd371b
      Rob Clark 提交于
      For atomic, it will be quite necessary to not need to care so much
      about locking order.  And 'state' gives us a convenient place to stash a
      ww_ctx for any sort of update that needs to grab multiple crtc locks.
      
      Because we will want to eventually make locking even more fine grained
      (giving locks to planes, connectors, etc), split out drm_modeset_lock
      and drm_modeset_acquire_ctx to track acquired locks.
      
      Atomic will use this to keep track of which locks have been acquired
      in a transaction.
      
      v1: original
      v2: remove a few things not needed until atomic, for now
      v3: update for v3 of connection_mutex patch..
      v4: squash in docbook
      v5: doc tweaks/fixes
      Signed-off-by: NRob Clark <robdclark@gmail.com>
      Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      Signed-off-by: NDave Airlie <airlied@redhat.com>
      51fd371b
  6. 15 4月, 2014 4 次提交
  7. 14 4月, 2014 4 次提交
    • T
      drm/omap: fix enabling/disabling of video pipeline · 506096a1
      Tomi Valkeinen 提交于
      At the moment the omap_crtc_pre_apply() handles the enabling, disabling
      and configuring of encoders and panels separately from the CRTC (i.e.
      the overlay manager).
      
      However, this doesn't work correctly. The encoder driver has to be in
      control of its video input (i.e. the crtc) for correct operation.
      
      This problem causes bugs with (at least) HDMI: the HDMI encoder supplies
      pixel clock for DISPC, and DISPC supplies video stream for HDMI. The
      current code first enables the HDMI encoder, and CRTC after that.
      However, the encoder expects the video stream to start during the
      encoder's enable, and if it doesn't, there will be sync lost errors.
      
      The encoder enables its video source by calling src->enable(), and this
      call goes to omapdrm (omap_crtc_enable), but omapdrm doesn't do anything
      in that function. Similarly for disable, which goes to
      omap_crtc_disable().
      
      This patch moves the code to setup and enable/disable the crtc to
      omap_crtc_enable. and omap_crtc_disable().
      Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
      Reviewed-by: NRob Clark <robdclark@gmail.com>
      506096a1
    • T
      drm/omap: fix missing disable for unused encoder · c7aef12f
      Tomi Valkeinen 提交于
      When an encoder is no longer connected to a crtc, the driver will leave
      the encoder enabled.
      
      This patch adds code to track the encoder used for a crtc, and when the
      encoder changes, the old one is disabled.
      Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
      Reviewed-by: NRob Clark <robdclark@gmail.com>
      c7aef12f
    • T
      drm/omap: fix race issue when unloading omapdrm · e2f8fd74
      Tomi Valkeinen 提交于
      At module unload, omap_fbdev_free() gets called which releases the
      framebuffers. However, the framebuffers are still used by crtcs, and
      will be released only later at vsync. The driver doesn't wait for this,
      and goes on to release the rest of the resources, which often
      causes a crash.
      
      This patchs adds a omap_crtc_flush() function which waits until the crtc
      has finished with its apply queue and page flips.
      
      The function utilizes a simple polling while-loop, as the performance is
      not an issue here.
      Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
      Reviewed-by: NRob Clark <robdclark@gmail.com>
      e2f8fd74
    • T
      drm/omap: fix output enable/disable sequence · 2ec8e378
      Tomi Valkeinen 提交于
      At the moment it's quite easy to get the following errors when the HDMI
      output is enabled or disabled:
      
      [drm:omap_crtc_error_irq] *ERROR* tv: errors: 00008000
      
      The reason for the errors is that the omapdrm driver doesn't properly
      handle the sync-lost irqs that happen when enabling the DIGIT crtc,
      which is used for HDMI and analog TV. The driver does disable the
      sync-lost irq properly, but it fails to wait until the output has been
      fully enabled (i.e. the first vsync), so the sync-lost errors are still
      seen occasionally.
      
      This patch makes the omapdrm act the same way as the omapfb does:
      
      - When enabling a display, we'll wait for the first vsync.
      - When disabling a display, we'll wait for framedone if available, or
        odd and even vsyncs.
      
      These changes make sure the output is fully enabled or disabled at the
      end of the function.
      Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
      Reported-by: NSanjay Singh Rawat <sanjay.rawat@linaro.org>
      Reviewed-by: NRob Clark <robdclark@gmail.com>
      2ec8e378
  8. 02 4月, 2014 1 次提交
    • M
      drm: Replace crtc fb with primary plane fb (v3) · f4510a27
      Matt Roper 提交于
      Now that CRTC's have a primary plane, there's no need to track the
      framebuffer in the CRTC.  Replace all references to the CRTC fb with the
      primary plane's fb.
      
      This patch was generated by the Coccinelle semantic patching tool using
      the following rules:
      
              @@ struct drm_crtc C; @@
              -   (C).fb
              +   C.primary->fb
      
              @@ struct drm_crtc *C; @@
              -   (C)->fb
              +   C->primary->fb
      
      v3: Generate patch via coccinelle.  Actual removal of crtc->fb has been
          moved to a subsequent patch.
      
      v2: Fixup several lingering crtc->fb instances that were missed in the
          first patch iteration.  [Rob Clark]
      Signed-off-by: NMatt Roper <matthew.d.roper@intel.com>
      Reviewed-by: NRob Clark <robdclark@gmail.com>
      f4510a27
  9. 09 1月, 2014 2 次提交
    • A
      drm/omap: fix: Defer probe if an omapdss device requests for it at connect · 3a01ab25
      Archit Taneja 提交于
      With the omapdss device model changes. omapdrm is required to call dssdriver's
      connect() op to register a panel. This is currently done in omap_modeset_init()
      
      A call to connect() can fail if the omapdss panels or the encoders(HDMI/DPI)
      they connect to have some resource(like regulators, I2C adapter) missing. If
      this happens, the correct approach is to defer omapdrm's probe.
      
      omapdrm currently ignores those panels which return a non zero value when
      connected. This could result in omapdrm ignoring all panels on an omap board.
      
      The right approach would be for omapdrm to request for probe deferral when a
      panel's connect op returns -EPROBE_DEFER.
      
      In order to do this, we need to call connect() much earlier during omapdrm's
      probe to prevent too many things are already done by then. We now connect the
      panels during pdev_probe(), before anything else is initialized, so that we
      don't need to undo too many things if a defer was requested.
      
      Now when we enter omap_modeset_init(), we have a set of panels that have been
      connected. We now proceed with registering only those panels that are already
      connected.
      
      A special case has to be considered when no panels are available to connect when
      omapdrm probes. In this case too, we defer probe and expect that a panel will be
      available to connect the next time.
      
      Checking whether the panel has a driver or whether it has get_timing/read_edid
      ops in omap_modeset_init() are redundant with the new display model. These can
      be removed since a dssdev device will always have a driver associated with it,
      and all dssdev drivers have a get_timings op.
      
      This will mainly fix cases when omapdrm is built-in the kernel, since that's
      generally where resources like regulators or I2C are unavailable because of
      probe order dependencies.
      
      In particular this fixes boot with omapdrm built-in on an omap4 panda ES board.
      The regulators used by HDMI(provided by I2C based TWL regulators) aren't
      initialized because I2C isn't initialized, I2C isn't initialized as it's pins
      are not configured because pinctrl is yet to probe.
      Signed-off-by: NArchit Taneja <archit@ti.com>
      Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
      3a01ab25
    • T
      drm/omap: fix (un)registering irqs inside an irq handler · 6da9f891
      Tomi Valkeinen 提交于
      omapdrm (un)registers irqs inside an irq handler. The problem is that
      the (un)register function uses dispc_runtime_get/put() to enable the
      clocks, and those functions are not irq safe by default.
      
      This was kind of fixed in 48664b21
      (OMAPDSS: DISPC: set irq_safe for runtime PM), which makes dispc's
      runtime calls irq-safe.
      
      However, using pm_runtime_irq_safe in dispc makes the parent of dispc,
      dss, always enabled, effectively preventing PM for the whole DSS module.
      
      This patch makes omapdrm behave better by adding new irq (un)register
      functions that do not use dispc_runtime_get/put, and using those
      functions in interrupt context. Thus we can make dispc again
      non-irq-safe, allowing proper PM.
      Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
      Cc: Rob Clark <robdclark@gmail.com>
      6da9f891
  10. 30 8月, 2013 1 次提交
  11. 17 6月, 2013 4 次提交
    • 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: Implement display (dis)connect support · a7e71e7f
      Tomi Valkeinen 提交于
      We currently have two steps in panel initialization and startup: probing
      and enabling. After the panel has been probed, it's ready and can be
      configured and later enabled.
      
      This model is not enough with more complex display pipelines, where we
      may have, for example, two panels, of which only one can be used at a
      time, connected to the same video output.
      
      To support that kind of scenarios, we need to add new step to the
      initialization: connect.
      
      This patch adds support for connecting and disconnecting panels. After
      probe, but before connect, no panel ops should be called. When the
      connect is called, a proper video pipeline is established, and the panel
      is ready for use. If some part in the video pipeline is already
      connected (by some other panel), the connect call fails.
      
      One key difference with the old style setup is that connect() handles
      also connecting to the overlay manager. This means that the omapfb (or
      omapdrm) no longer needs to figure out which overlay manager to use, but
      it can just call connect() on the panel, and the proper overlay manager
      is connected by omapdss.
      
      This also allows us to add back the support for dynamic switching
      between two exclusive panels. However, the current panel device model is
      not changed to support this, as the new device model is implemented in
      the following patches and the old model will be removed. The new device
      model supports dynamic switching.
      Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
      a7e71e7f
    • T
      OMAPDRM: fix overlay manager handling · 04b1fc02
      Tomi Valkeinen 提交于
      Currently omapdrm creates crtcs, which map directly to DSS overlay
      managers, only on demand at init time. This would make it difficult to
      manage connecting the display entities in the future, as the code cannot
      just search for a suitable overlay manager.
      
      We cannot fix this the sane way, which would be to create crtcs for each
      overlay manager, because we need an overlay for each crtc. With limited
      number of overlays, that's not possible.
      
      So the solution for now is to detach the overlay manager from the crtc.
      crtcs are still created on demand at init time, but all overlay managers
      are always initialized by the omapdss.
      
      This way we can create and connect whole display pipelines from the
      overlay manager to the display, regardless of which crtcs omapdrm would
      create.
      Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
      04b1fc02
    • V
      drm: Drop all the stub gamma_get, gamma_set, load_lut functions from drivers · fb85ac4d
      Ville Syrjälä 提交于
      Many of the drivers didn't implement palette/gamma handling, but were forced
      to provide stubs for the hooks to avoid drm_fb_helper from oopsing. Now that
      the hooks are optional, we can eliminate all the stubs.
      Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
      Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      Signed-off-by: NDave Airlie <airlied@gmail.com>
      fb85ac4d
  12. 11 4月, 2013 1 次提交
    • A
      drm/omap: Fix and improve crtc and overlay manager correlation · 0d8f371f
      Archit Taneja 提交于
      The omapdrm driver currently takes a config/module arg to figure out the number
      of crtcs it needs to create. We could create as many crtcs as there are overlay
      managers in the DSS hardware, but we don't do that because each crtc eats up
      one DSS overlay, and that reduces the number of planes we can attach to a single
      crtc.
      
      Since the number of crtcs may be lesser than the number of hardware overlay
      managers, we need to figure out which overlay managers to use for our crtcs. The
      current approach is to use pipe2chan(), which returns a higher numbered manager
      for the crtc.
      
      The problem with this approach is that it assumes that the overlay managers we
      choose will connect to the encoders the platform's panels are going to use,
      this isn't true, an overlay manager connects only to a few outputs/encoders, and
      choosing any overlay manager for our crtc might lead to a situation where the
      encoder cannot connect to any of the crtcs we have chosen. For example, an
      omap5-panda board has just one hdmi output. If num_crtc is set to 1, with the
      current approach, pipe2chan will pick up the LCD2 overlay manager, which cannot
      connect to the hdmi encoder at all. The only manager that could have connected
      to hdmi was the TV overlay manager.
      
      Therefore, there is a need to choose our overlay managers keeping in mind the
      panels we have on that platform. The new approach iterates through all the
      available panels, creates encoders and connectors for them, and then tries to
      get a suitable overlay manager to create a crtc which can connect to the
      encoders.
      
      We use the dispc_channel field in omap_dss_output to retrieve the desired
      overlay manager's channel number, we then check whether the manager had already
      been assigned to a crtc or not. If it was already assigned to a crtc, we assume
      that out of all the encoders which intend use this crtc, only one will run at a
      time. If the overlay manager wan't assigned to a crtc till then, we create a
      new crtc and link it with the overlay manager.
      
      This approach just looks for the best dispc_channel for each encoder. On DSS HW,
      some encoders can connect to multiple overlay managers. Since we don't try
      looking for alternate overlay managers, there is a greater possibility that 2
      or more encoders end up asking for the same crtc, causing only one encoder to
      run at a time.
      
      Also, this approach isn't the most optimal one, it can do either good or bad
      depending on the sequence in which the panels/outputs are parsed. The optimal
      way would be some sort of back tracking approach, where we improve the set of
      managers we use as we iterate through the list of panels/encoders. That's
      something left for later.
      Signed-off-by: NArchit Taneja <archit@ti.com>
      Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
      0d8f371f
  13. 17 2月, 2013 2 次提交
  14. 12 2月, 2013 1 次提交
  15. 21 1月, 2013 1 次提交
    • D
      omapdrm: use modeset_lock_all · d5d2636e
      Daniel Vetter 提交于
      I've left the locking in the debugfs code as-is, it's essentially just
      used to keep the framebuffer object alive (which won't be necessary
      any more later on). We don't need fb refcounting either, since the new
      mode_config.fb_lock ensures that the framebuffers can't disappear
      (once mode_config.mutex doesn't guarantee this any more later on in
      the series).
      
      The fbcon restore needs all modeset locks. The crtc callbacks seem to
      only need the crtc locks, but I've quickly discussed things with Rob
      Clark and he's fine with just using modeset_lock_all for those, too.
      He'll look into converting things over later.
      Reviewed-by: NRob Clark <rob@ti.com>
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      d5d2636e
  16. 08 1月, 2013 1 次提交
    • R
      staging: drm/omap: use omapdss low level API · f5f9454c
      Rob Clark 提交于
      This patch changes the omapdrm KMS to bypass the omapdss "compat"
      layer and use the core omapdss API directly.  This solves some layering
      issues that would cause unpin confusion vs GO bit status, because we
      would not know whether a particular pageflip or overlay update has hit
      the screen or not.  Now instead we explicitly manage the GO bits in
      dispc and handle the vblank/framedone interrupts ourself so that we
      always know which buffers are being scanned out at any given time, and
      so on.
      
      As an added bonus, we no longer leave the last overlay buffer pinned
      when the display is disabled, and have been able to add the previously
      missing vblank event handling.
      
      v1: original
      v2: rebased on latest staging-next and omapdss patches from Tomi and
          review comments from Archit Taneja
      Signed-off-by: NRob Clark <robdclark@gmail.com>
      Reviewed-by: NArchit Taneja <archit@ti.com>
      Reviewed-by: NSumit Semwal <sumit.semwal@ti.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      f5f9454c
  17. 15 11月, 2012 1 次提交