1. 04 Aug, 2016 1 commit
    • Krzysztof Kozlowski's avatar
      dma-mapping: use unsigned long for dma_attrs · 00085f1e
      Krzysztof Kozlowski authored
      The dma-mapping core and the implementations do not change the DMA
      attributes passed by pointer.  Thus the pointer can point to const data.
      However the attributes do not have to be a bitfield.  Instead unsigned
      long will do fine:
      1. This is just simpler.  Both in terms of reading the code and setting
         attributes.  Instead of initializing local attributes on the stack
         and passing pointer to it to dma_set_attr(), just set the bits.
      2. It brings safeness and checking for const correctness because the
         attributes are passed by value.
      Semantic patches for this change (at least most of them):
          virtual patch
          virtual context
          identifier f, attrs;
          - struct dma_attrs *attrs
          + unsigned long attrs
          , ...)
          identifier r.f;
          - NULL
          + 0
          // Options: --all-includes
          virtual patch
          virtual context
          identifier f, attrs;
          type t;
          t f(..., struct dma_attrs *attrs);
          identifier r.f;
          - NULL
          + 0
      Link: http://lkml.kernel.org/r/1468399300-5399-2-git-send-email-k.kozlowski@samsung.comSigned-off-by: default avatarKrzysztof Kozlowski <k.kozlowski@samsung.com>
      Acked-by: default avatarVineet Gupta <vgupta@synopsys.com>
      Acked-by: default avatarRobin Murphy <robin.murphy@arm.com>
      Acked-by: default avatarHans-Christian Noren Egtvedt <egtvedt@samfundet.no>
      Acked-by: Mark Salter <msalter@redhat.com> [c6x]
      Acked-by: Jesper Nilsson <jesper.nilsson@axis.com> [cris]
      Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch> [drm]
      Reviewed-by: default avatarBart Van Assche <bart.vanassche@sandisk.com>
      Acked-by: Joerg Roedel <jroedel@suse.de> [iommu]
      Acked-by: Fabien Dessenne <fabien.dessenne@st.com> [bdisp]
      Reviewed-by: Marek Szyprowski <m.szyprowski@samsung.com> [vb2-core]
      Acked-by: David Vrabel <david.vrabel@citrix.com> [xen]
      Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> [xen swiotlb]
      Acked-by: Joerg Roedel <jroedel@suse.de> [iommu]
      Acked-by: Richard Kuo <rkuo@codeaurora.org> [hexagon]
      Acked-by: Geert Uytterhoeven <geert@linux-m68k.org> [m68k]
      Acked-by: Gerald Schaefer <gerald.schaefer@de.ibm.com> [s390]
      Acked-by: default avatarBjorn Andersson <bjorn.andersson@linaro.org>
      Acked-by: Hans-Christian Noren Egtvedt <egtvedt@samfundet.no> [avr32]
      Acked-by: Vineet Gupta <vgupta@synopsys.com> [arc]
      Acked-by: Robin Murphy <robin.murphy@arm.com> [arm64 and dma-iommu]
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
  2. 23 Jul, 2016 1 commit
  3. 17 Jul, 2016 1 commit
    • Mauro Carvalho Chehab's avatar
      [media] doc-rst: Fix conversion for v4l2 core functions · 89cb3ddb
      Mauro Carvalho Chehab authored
      The conversion from DocBook lead into some conversion issues,
      basically due to the lack of proper support at kernel-doc.
      So, address them:
      - Now, the C files with the exported symbols also need to be
        added. So, all headers need to be included twice: one to
        get the structs/enums/.. and another one for the functions;
      - Notes should use the ReST tag, as kernel-doc doesn't
        recognizes it anymore;
      - Identation needs to be fixed, as ReST uses it to identify
        when a format "tag" ends.
      - kernel-doc doesn't escape things like *pointer, so we
        need to manually add a escape char before it.
      - On some cases, kernel-doc conversion requires violating
        the 80-cols, as otherwise it won't properly parse the
        source code.
      Signed-off-by: default avatarMauro Carvalho Chehab <mchehab@s-opensource.com>
  4. 08 Jul, 2016 3 commits
  5. 25 Apr, 2016 1 commit
  6. 13 Apr, 2016 1 commit
  7. 04 Feb, 2016 1 commit
    • Hans Verkuil's avatar
      [media] vb2: fix nasty vb2_thread regression · fac710e4
      Hans Verkuil authored
      The vb2_thread implementation was made generic and was moved from
      videobuf2-v4l2.c to videobuf2-core.c in commit af3bac1a. Unfortunately
      that clearly was never tested since it broke read() causing NULL address
      The root cause was confused handling of vb2_buffer vs v4l2_buffer (the pb
      pointer in various core functions).
      The v4l2_buffer no longer exists after moving the code into the core and
      it is no longer needed. However, the vb2_thread code passed a pointer to
      a vb2_buffer to the core functions were a v4l2_buffer pointer was expected
      and vb2_thread expected that the vb2_buffer fields would be filled in
      This is obviously wrong since v4l2_buffer != vb2_buffer. Note that the
      pb pointer is a void pointer, so no type-checking took place.
      This patch fixes this problem:
      1) allow pb to be NULL for vb2_core_(d)qbuf. The vb2_thread code will use
         a NULL pointer here since they don't care about v4l2_buffer anyway.
      2) let vb2_core_dqbuf pass back the index of the received buffer. This is
         all vb2_thread needs: this index is the index into the q->bufs array
         and vb2_thread just gets the vb2_buffer from there.
      3) the fileio->b pointer (that originally contained a v4l2_buffer) is
         removed altogether since it is no longer needed.
      Tested with vivid and the cobalt driver.
      Cc: stable@vger.kernel.org # Kernel >= 4.3
      Signed-off-by: default avatarHans Verkuil <hans.verkuil@cisco.com>
      Reported-by: default avatarMatthias Schwarzott <zzam@gentoo.org>
      Signed-off-by: default avatarMauro Carvalho Chehab <mchehab@osg.samsung.com>
  8. 18 Dec, 2015 6 commits
  9. 20 Oct, 2015 4 commits
  10. 05 Oct, 2015 1 commit
  11. 01 Oct, 2015 3 commits
  12. 22 Aug, 2015 1 commit
  13. 17 Jul, 2015 1 commit
    • Sakari Ailus's avatar
      [media] vb2: Only requeue buffers immediately once streaming is started · 6d058c56
      Sakari Ailus authored
      Buffers can be returned back to videobuf2 in driver's streamon handler. In
      this case vb2_buffer_done() with buffer state VB2_BUF_STATE_QUEUED will
      cause the driver's buf_queue vb2 operation to be called, queueing the same
      buffer again only to be returned to videobuf2 using vb2_buffer_done() and so
      Add a new buffer state VB2_BUF_STATE_REQUEUEING which, when used as the
      state argument to vb2_buffer_done(), will result in buffers queued to the
      driver. Using VB2_BUF_STATE_QUEUED will leave the buffer to videobuf2, as it
      was before "[media] vb2: allow requeuing buffers while streaming".
      Fixes: ce0eff01 ("[media] vb2: allow requeuing buffers while streaming")
      [mchehab@osg.samsung.com: fix warning: enumeration value 'VB2_BUF_STATE_REQUEUEING' not handled in switch]
      Signed-off-by: default avatarSakari Ailus <sakari.ailus@linux.intel.com>
      Acked-by: default avatarHans Verkuil <hans.verkuil@cisco.com>
      Cc: stable@vger.kernel.org # for v4.1
      Signed-off-by: default avatarMauro Carvalho Chehab <mchehab@osg.samsung.com>
  14. 12 May, 2015 1 commit
  15. 10 Apr, 2015 2 commits
  16. 25 Nov, 2014 3 commits
  17. 23 Sep, 2014 1 commit
  18. 21 Sep, 2014 3 commits
  19. 21 Aug, 2014 1 commit
    • Hans Verkuil's avatar
      [media] videobuf2: fix lockdep warning · f035eb4e
      Hans Verkuil authored
      The following lockdep warning has been there ever since commit a517cca6
      one year ago:
      [  403.117947] ======================================================
      [  403.117949] [ INFO: possible circular locking dependency detected ]
      [  403.117953] 3.16.0-rc6-test-media #961 Not tainted
      [  403.117954] -------------------------------------------------------
      [  403.117956] v4l2-ctl/15377 is trying to acquire lock:
      [  403.117959]  (&dev->mutex#3){+.+.+.}, at: [<ffffffffa005a6c3>] vb2_fop_mmap+0x33/0x90 [videobuf2_core]
      [  403.117974]
      [  403.117974] but task is already holding lock:
      [  403.117976]  (&mm->mmap_sem){++++++}, at: [<ffffffff8118291f>] vm_mmap_pgoff+0x6f/0xc0
      [  403.117987]
      [  403.117987] which lock already depends on the new lock.
      [  403.117987]
      [  403.117990]
      [  403.117990] the existing dependency chain (in reverse order) is:
      [  403.117992]
      [  403.117992] -> #1 (&mm->mmap_sem){++++++}:
      [  403.117997]        [<ffffffff810d733c>] validate_chain.isra.39+0x5fc/0x9a0
      [  403.118006]        [<ffffffff810d8bc3>] __lock_acquire+0x4d3/0xd30
      [  403.118010]        [<ffffffff810d9da7>] lock_acquire+0xa7/0x160
      [  403.118014]        [<ffffffff8118c9ec>] might_fault+0x7c/0xb0
      [  403.118018]        [<ffffffffa0028a25>] video_usercopy+0x425/0x610 [videodev]
      [  403.118028]        [<ffffffffa0028c25>] video_ioctl2+0x15/0x20 [videodev]
      [  403.118034]        [<ffffffffa0022764>] v4l2_ioctl+0x184/0x1a0 [videodev]
      [  403.118040]        [<ffffffff811d77d0>] do_vfs_ioctl+0x2f0/0x4f0
      [  403.118307]        [<ffffffff811d7a51>] SyS_ioctl+0x81/0xa0
      [  403.118311]        [<ffffffff8199dc69>] system_call_fastpath+0x16/0x1b
      [  403.118319]
      [  403.118319] -> #0 (&dev->mutex#3){+.+.+.}:
      [  403.118324]        [<ffffffff810d6a96>] check_prevs_add+0x746/0x9f0
      [  403.118329]        [<ffffffff810d733c>] validate_chain.isra.39+0x5fc/0x9a0
      [  403.118333]        [<ffffffff810d8bc3>] __lock_acquire+0x4d3/0xd30
      [  403.118336]        [<ffffffff810d9da7>] lock_acquire+0xa7/0x160
      [  403.118340]        [<ffffffff81999664>] mutex_lock_interruptible_nested+0x64/0x640
      [  403.118344]        [<ffffffffa005a6c3>] vb2_fop_mmap+0x33/0x90 [videobuf2_core]
      [  403.118349]        [<ffffffffa0022122>] v4l2_mmap+0x62/0xa0 [videodev]
      [  403.118354]        [<ffffffff81197270>] mmap_region+0x3d0/0x5d0
      [  403.118359]        [<ffffffff8119778d>] do_mmap_pgoff+0x31d/0x400
      [  403.118363]        [<ffffffff81182940>] vm_mmap_pgoff+0x90/0xc0
      [  403.118366]        [<ffffffff81195cef>] SyS_mmap_pgoff+0x1df/0x2a0
      [  403.118369]        [<ffffffff810085c2>] SyS_mmap+0x22/0x30
      [  403.118376]        [<ffffffff8199dc69>] system_call_fastpath+0x16/0x1b
      [  403.118381]
      [  403.118381] other info that might help us debug this:
      [  403.118381]
      [  403.118383]  Possible unsafe locking scenario:
      [  403.118383]
      [  403.118385]        CPU0                    CPU1
      [  403.118387]        ----                    ----
      [  403.118388]   lock(&mm->mmap_sem);
      [  403.118391]                                lock(&dev->mutex#3);
      [  403.118394]                                lock(&mm->mmap_sem);
      [  403.118397]   lock(&dev->mutex#3);
      [  403.118400]
      [  403.118400]  *** DEADLOCK ***
      [  403.118400]
      [  403.118403] 1 lock held by v4l2-ctl/15377:
      [  403.118405]  #0:  (&mm->mmap_sem){++++++}, at: [<ffffffff8118291f>] vm_mmap_pgoff+0x6f/0xc0
      [  403.118411]
      [  403.118411] stack backtrace:
      [  403.118415] CPU: 0 PID: 15377 Comm: v4l2-ctl Not tainted 3.16.0-rc6-test-media #961
      [  403.118418] Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 07/31/2013
      [  403.118420]  ffffffff82a6c9d0 ffff8800af37fb00 ffffffff819916a2 ffffffff82a6c9d0
      [  403.118425]  ffff8800af37fb40 ffffffff810d5715 ffff8802308e4200 0000000000000000
      [  403.118429]  ffff8802308e4a48 ffff8802308e4a48 ffff8802308e4200 0000000000000001
      [  403.118433] Call Trace:
      [  403.118441]  [<ffffffff819916a2>] dump_stack+0x4e/0x7a
      [  403.118445]  [<ffffffff810d5715>] print_circular_bug+0x1d5/0x2a0
      [  403.118449]  [<ffffffff810d6a96>] check_prevs_add+0x746/0x9f0
      [  403.118455]  [<ffffffff8119c172>] ? find_vmap_area+0x42/0x70
      [  403.118459]  [<ffffffff810d733c>] validate_chain.isra.39+0x5fc/0x9a0
      [  403.118463]  [<ffffffff810d8bc3>] __lock_acquire+0x4d3/0xd30
      [  403.118468]  [<ffffffff810d9da7>] lock_acquire+0xa7/0x160
      [  403.118472]  [<ffffffffa005a6c3>] ? vb2_fop_mmap+0x33/0x90 [videobuf2_core]
      [  403.118476]  [<ffffffffa005a6c3>] ? vb2_fop_mmap+0x33/0x90 [videobuf2_core]
      [  403.118480]  [<ffffffff81999664>] mutex_lock_interruptible_nested+0x64/0x640
      [  403.118484]  [<ffffffffa005a6c3>] ? vb2_fop_mmap+0x33/0x90 [videobuf2_core]
      [  403.118488]  [<ffffffffa005a6c3>] ? vb2_fop_mmap+0x33/0x90 [videobuf2_core]
      [  403.118493]  [<ffffffff810d8055>] ? mark_held_locks+0x75/0xa0
      [  403.118497]  [<ffffffffa005a6c3>] vb2_fop_mmap+0x33/0x90 [videobuf2_core]
      [  403.118502]  [<ffffffffa0022122>] v4l2_mmap+0x62/0xa0 [videodev]
      [  403.118506]  [<ffffffff81197270>] mmap_region+0x3d0/0x5d0
      [  403.118510]  [<ffffffff8119778d>] do_mmap_pgoff+0x31d/0x400
      [  403.118513]  [<ffffffff81182940>] vm_mmap_pgoff+0x90/0xc0
      [  403.118517]  [<ffffffff81195cef>] SyS_mmap_pgoff+0x1df/0x2a0
      [  403.118521]  [<ffffffff810085c2>] SyS_mmap+0x22/0x30
      [  403.118525]  [<ffffffff8199dc69>] system_call_fastpath+0x16/0x1b
      The reason is that vb2_fop_mmap and vb2_fop_get_unmapped_area take the core lock
      while they are called with the mmap_sem semaphore held. But elsewhere in the code
      the core lock is taken first but calls to copy_to/from_user() can take the mmap_sem
      semaphore as well, potentially causing a classical A-B/B-A deadlock.
      However, the mmap/get_unmapped_area calls really shouldn't take the core lock
      at all. So what would happen if they don't take the core lock anymore?
      There are two situations that need to be taken into account: calling mmap while
      new buffers are being added and calling mmap while buffers are being deleted.
      The first case works almost fine without a lock: in all cases mmap relies on
      correctly filled-in q->num_buffers/q->num_planes values and those are only
      updated by reqbufs and create_buffers *after* any new buffers have been
      initialized completely. Except in one case: if an error occurred while allocating
      the buffers it will increase num_buffers and rely on __vb2_queue_free to
      decrease it again. So there is a short period where the buffer information
      may be wrong.
      The second case definitely does pose a problem: buffers may be in the process
      of being deleted, without the internal structure being updated.
      In order to fix this a new mutex is added to vb2_queue that is taken when
      buffers are allocated or deleted, and in vb2_mmap. That way vb2_mmap won't
      get stale buffer data. Note that this is a problem only for MEMORY_MMAP, so
      even though __qbuf_userptr and __qbuf_dmabuf also mess around with buffers
      (mem_priv in particular), this doesn't clash with vb2_mmap or
      vb2_get_unmapped_area since those are MMAP specific.
      As an additional bonus the hack in __buf_prepare, the USERPTR case, can be
      removed as well since mmap() no longer takes the core lock.
      All in all a much cleaner solution.
      Signed-off-by: default avatarHans Verkuil <hans.verkuil@cisco.com>
      Acked-by: default avatarLaurent Pinchart <laurent.pinchart@ideasonboard.com>
      Acked-by: default avatarMarek Szyprowski <m.szyprowski@samsung.com>
      Signed-off-by: default avatarMauro Carvalho Chehab <m.chehab@samsung.com>
  20. 25 Jul, 2014 1 commit
  21. 17 Jul, 2014 1 commit
    • Laurent Pinchart's avatar
      [media] v4l: vb2: Add fatal error condition flag · 4bb7267d
      Laurent Pinchart authored
      When a fatal error occurs that render the device unusable, the only
      options for a driver to signal the error condition to userspace is to
      set the V4L2_BUF_FLAG_ERROR flag when dequeuing buffers and to return an
      error from the buffer prepare handler when queuing buffers.
      The buffer error flag indicates a transient error and can't be used by
      applications to detect fatal errors. Returning an error from vb2_qbuf()
      is thus the only real indication that a fatal error occurred. However,
      this is difficult to handle for multithreaded applications that requeue
      buffers from a thread other than the control thread. In particular the
      poll() call in the control thread will not notify userspace of the
      This patch adds an explicit mechanism to report fatal errors to
      userspace. Drivers can call the vb2_queue_error() function to signal a
      fatal error. From this moment on, buffer preparation will return -EIO to
      userspace, and vb2_poll() will set the POLLERR flag and return
      immediately. The error flag is cleared when cancelling the queue, either
      at stream off time (through vb2_streamoff) or when releasing the queue
      with vb2_queue_release().
      Signed-off-by: default avatarLaurent Pinchart <laurent.pinchart@ideasonboard.com>
      Acked-by: default avatarHans Verkuil <hans.verkuil@cisco.com>
      Signed-off-by: default avatarMauro Carvalho Chehab <m.chehab@samsung.com>
  22. 25 May, 2014 1 commit
  23. 23 Apr, 2014 1 commit