1. 09 1月, 2014 1 次提交
    • 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
  2. 09 10月, 2013 1 次提交
    • D
      drm: kill ->gem_init_object() and friends · 16eb5f43
      David Herrmann 提交于
      All drivers embed gem-objects into their own buffer objects. There is no
      reason to keep drm_gem_object_alloc(), gem->driver_private and
      ->gem_init_object() anymore.
      
      New drivers are highly encouraged to do the same. There is no benefit in
      allocating gem-objects separately.
      
      Cc: Dave Airlie <airlied@gmail.com>
      Cc: Alex Deucher <alexdeucher@gmail.com>
      Cc: Daniel Vetter <daniel@ffwll.ch>
      Cc: Jerome Glisse <jglisse@redhat.com>
      Cc: Rob Clark <robdclark@gmail.com>
      Cc: Inki Dae <inki.dae@samsung.com>
      Cc: Ben Skeggs <skeggsb@gmail.com>
      Cc: Patrik Jakobsson <patrik.r.jakobsson@gmail.com>
      Signed-off-by: NDavid Herrmann <dh.herrmann@gmail.com>
      Acked-by: NAlex Deucher <alexander.deucher@amd.com>
      Signed-off-by: NDave Airlie <airlied@redhat.com>
      16eb5f43
  3. 19 8月, 2013 1 次提交
    • R
      drm/omap: use flip-work helper · 5833bd2f
      Rob Clark 提交于
      And simplify how we hold a ref+pin to what is being scanned out by using
      fb refcnt'ing.  The previous logic pre-dated fb refcnt, and as a result
      was less straightforward than it could have been.  By holding a ref to
      the fb, we don't have to care about how many plane's there are and
      holding a ref to each color plane's bo.
      Signed-off-by: NRob Clark <robdclark@gmail.com>
      Signed-off-by: NDave Airlie <airlied@redhat.com>
      5833bd2f
  4. 07 8月, 2013 1 次提交
  5. 17 6月, 2013 1 次提交
    • 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
  6. 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
  7. 17 2月, 2013 2 次提交
    • R
      drm/omap: move out of staging · 8bb0daff
      Rob Clark 提交于
      Now that the omapdss interface has been reworked so that omapdrm can use
      dispc directly, we have been able to fix the remaining functional kms
      issues with omapdrm.  And in the mean time the PM sequencing and many
      other of that open issues have been solved.  So I think it makes sense
      to finally move omapdrm out of staging.
      Signed-off-by: NRob Clark <robdclark@gmail.com>
      8bb0daff
    • A
      drm/omap: Add PM capabilities · 4836d157
      Andy Gross 提交于
      Added power management capabilities into the omapdrm and DMM drivers.
      During suspend, we don't need to do anything to maintain the state of
      the LUT.  We have all the necessary information to recreate the mappings
      of the GEM object list maintained by the omapdrm driver.
      
      On resume, the DMM resume handler will first reprogram the LUT to point
      to the dummy page.  The subsequent resume handler in the omapdrm will call
      into the DMM and reprogram each of the buffer objects.  This will ensure
      that all of the necessary objects will be pinned into the DMM properly.
      
      Order of suspend/resume handlers is done by device creation.  We create
      the DMM device before the omapdrm, so the correct order is maintained.
      Signed-off-by: NAndy Gross <andy.gross@ti.com>
      Signed-off-by: NRob Clark <rob@ti.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      4836d157
  8. 18 1月, 2013 1 次提交
    • A
      drm/omap: Add PM capabilities · e78edba1
      Andy Gross 提交于
      Added power management capabilities into the omapdrm and DMM drivers.
      During suspend, we don't need to do anything to maintain the state of
      the LUT.  We have all the necessary information to recreate the mappings
      of the GEM object list maintained by the omapdrm driver.
      
      On resume, the DMM resume handler will first reprogram the LUT to point
      to the dummy page.  The subsequent resume handler in the omapdrm will call
      into the DMM and reprogram each of the buffer objects.  This will ensure
      that all of the necessary objects will be pinned into the DMM properly.
      
      Order of suspend/resume handlers is done by device creation.  We create
      the DMM device before the omapdrm, so the correct order is maintained.
      Signed-off-by: NAndy Gross <andy.gross@ti.com>
      Signed-off-by: NRob Clark <rob@ti.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      e78edba1
  9. 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
  10. 15 11月, 2012 2 次提交
  11. 31 10月, 2012 1 次提交
  12. 16 8月, 2012 2 次提交
  13. 02 7月, 2012 1 次提交
  14. 17 5月, 2012 2 次提交
  15. 11 4月, 2012 1 次提交
  16. 14 3月, 2012 1 次提交
  17. 08 3月, 2012 4 次提交
  18. 09 2月, 2012 4 次提交
  19. 17 12月, 2011 1 次提交
  20. 13 12月, 2011 1 次提交
  21. 09 12月, 2011 1 次提交
    • R
      drm/omap: add GEM support for tiled/dmm buffers · f7f9f453
      Rob Clark 提交于
      TILER/DMM provides two features for omapdrm GEM objects:
      1) providing a physically contiguous view to discontiguous memory
         for hw initiators that cannot otherwise support discontiguous
         buffers (DSS scanout, IVAHD video decode/encode, etc)
      2) providing untiling for 2d tiled buffers, which are used in some
         cases to provide rotation and reduce memory bandwidth for hw
         initiators that tend to access data in 2d block patterns.
      
      For 2d tiled buffers, there are some additional complications when
      it comes to userspace mmap'ings.  For non-tiled buffers, the original
      (potentially physically discontiguous) pages are used to back the
      mmap.  For tiled buffers, we need to mmap via the tiler/dmm region to
      provide an unswizzled view of the buffer.  But (a) the buffer is not
      necessarily pinned in TILER all the time (it can be unmapped when
      there is no DMA access to the buffer), and (b) when they are they
      are pinned, they not necessarily page aligned from the perspective of
      the CPU.  And non-page aligned userspace buffer mapping is evil.
      
      To solve this, we reserve one or more small regions in each of the 2d
      containers when the driver is loaded to use as a "user-GART" where we
      can create a second page-aligned mapping of parts of the buffer being
      accessed from userspace.  Page faulting is used to evict and remap
      different regions of whichever buffers are being accessed from user-
      space.
      Signed-off-by: NRob Clark <rob@ti.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      f7f9f453
  22. 27 11月, 2011 1 次提交
    • R
      staging: add omapdrm DRM/KMS driver for TI OMAP platforms · cd5351f4
      Rob Clark 提交于
      A DRM display driver for TI OMAP platform.  Similar to omapfb (fbdev)
      and omap_vout (v4l2 display) drivers in the past, this driver uses the
      DSS2 driver to access the display hardware, including support for
      HDMI, DVI, and various types of LCD panels.  And it implements GEM
      support for buffer allocation (for KMS as well as offscreen buffers
      used by the xf86-video-omap userspace xorg driver).
      
      The driver maps CRTCs to overlays, encoders to overlay-managers, and
      connectors to dssdev's.  Note that this arrangement might change slightly
      when support for drm_plane overlays is added.
      
      For GEM support, non-scanout buffers are using the shmem backed pages
      provided by GEM core (In drm_gem_object_init()).  In the case of scanout
      buffers, which need to be physically contiguous, those are allocated
      with CMA and use drm_gem_private_object_init().
      
      See userspace xorg driver:
      git://github.com/robclark/xf86-video-omap.git
      
      Refer to this link for CMA (Continuous Memory Allocator):
      http://lkml.org/lkml/2011/8/19/302
      
      Links to previous versions of the patch:
      v1: http://lwn.net/Articles/458137/
      v2: http://patches.linaro.org/4156/
      v3: http://patches.linaro.org/4688/
      v4: http://patches.linaro.org/4791/
      
      History:
      
      v5: move headers from include/drm at Greg KH's request, minor rebasing
          on 3.2-rc1, pull in private copies of drm_gem_{get,put}_pages()
          because "drm/gem: add functions to get/put pages" patch is not
          merged yet
      v4: bit of rework of encoder/connector _dpms() code, modeset_init()
          rework to not use nested functions, update TODO.txt
      v3: minor cleanups, improved error handling for dev_load(), some minor
          API changes that will be needed later for tiled buffer support
      v2: replace omap_vram with CMA for scanout buffer allocation, remove
          unneeded functions, use dma_addr_t for physical addresses, error
          handling cleanup, refactor attach/detach pages into common drm
          functions, split non-userspace-facing API into omap_priv.h, remove
          plugin API
      
      v1: original
      Signed-off-by: NRob Clark <rob@ti.com>
      Acked-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      cd5351f4