1. 09 9月, 2016 2 次提交
  2. 24 8月, 2016 1 次提交
  3. 04 8月, 2016 1 次提交
    • K
      dma-mapping: use unsigned long for dma_attrs · 00085f1e
      Krzysztof Kozlowski 提交于
      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
      
          @r@
          identifier f, attrs;
      
          @@
          f(...,
          - struct dma_attrs *attrs
          + unsigned long attrs
          , ...)
          {
          ...
          }
      
          @@
          identifier r.f;
          @@
          f(...,
          - NULL
          + 0
           )
      
      and
      
          // Options: --all-includes
          virtual patch
          virtual context
      
          @r@
          identifier f, attrs;
          type t;
      
          @@
          t f(..., struct dma_attrs *attrs);
      
          @@
          identifier r.f;
          @@
          f(...,
          - NULL
          + 0
           )
      
      Link: http://lkml.kernel.org/r/1468399300-5399-2-git-send-email-k.kozlowski@samsung.comSigned-off-by: NKrzysztof Kozlowski <k.kozlowski@samsung.com>
      Acked-by: NVineet Gupta <vgupta@synopsys.com>
      Acked-by: NRobin Murphy <robin.murphy@arm.com>
      Acked-by: NHans-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: NBart 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: NBjorn 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: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      00085f1e
  4. 23 7月, 2016 1 次提交
  5. 18 7月, 2016 1 次提交
    • M
      [media] doc-rst: Fix conversion for v4l2 core functions · 89cb3ddb
      Mauro Carvalho Chehab 提交于
      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: NMauro Carvalho Chehab <mchehab@s-opensource.com>
      89cb3ddb
  6. 09 7月, 2016 3 次提交
  7. 25 4月, 2016 1 次提交
  8. 14 4月, 2016 1 次提交
  9. 04 2月, 2016 1 次提交
    • H
      [media] vb2: fix nasty vb2_thread regression · fac710e4
      Hans Verkuil 提交于
      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
      references.
      
      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
      correctly.
      
      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: NHans Verkuil <hans.verkuil@cisco.com>
      Reported-by: NMatthias Schwarzott <zzam@gentoo.org>
      Signed-off-by: NMauro Carvalho Chehab <mchehab@osg.samsung.com>
      fac710e4
  10. 19 12月, 2015 2 次提交
  11. 18 12月, 2015 4 次提交
  12. 21 10月, 2015 4 次提交
  13. 05 10月, 2015 1 次提交
  14. 02 10月, 2015 1 次提交
    • M
      [media] DocBook: fix most of warnings at videobuf2-core.h · 32d81b41
      Mauro Carvalho Chehab 提交于
      	include/media/videobuf2-core.h:112: warning: No description found for parameter 'get_dmabuf'
      	include/media/videobuf2-core.h:146: warning: No description found for parameter 'm'
      	include/media/videobuf2-core.h:146: warning: Excess struct/union/enum/typedef member 'mem_offset' description in 'vb2_plane'
      
      There are still several warnings, but those are hard to fix,
      as they're actually a bug at DocBook. Those should be fixed on
      separate patches.
      Signed-off-by: NMauro Carvalho Chehab <mchehab@osg.samsung.com>
      32d81b41
  15. 01 10月, 2015 2 次提交
  16. 22 8月, 2015 1 次提交
  17. 17 7月, 2015 1 次提交
    • S
      [media] vb2: Only requeue buffers immediately once streaming is started · 6d058c56
      Sakari Ailus 提交于
      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
      on.
      
      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: NSakari Ailus <sakari.ailus@linux.intel.com>
      Acked-by: NHans Verkuil <hans.verkuil@cisco.com>
      Cc: stable@vger.kernel.org # for v4.1
      Signed-off-by: NMauro Carvalho Chehab <mchehab@osg.samsung.com>
      6d058c56
  18. 12 5月, 2015 1 次提交
  19. 10 4月, 2015 2 次提交
  20. 25 11月, 2014 3 次提交
  21. 24 9月, 2014 1 次提交
  22. 22 9月, 2014 3 次提交
  23. 22 8月, 2014 1 次提交
    • H
      [media] videobuf2: fix lockdep warning · f035eb4e
      Hans Verkuil 提交于
      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: NHans Verkuil <hans.verkuil@cisco.com>
      Acked-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
      Acked-by: NMarek Szyprowski <m.szyprowski@samsung.com>
      Signed-off-by: NMauro Carvalho Chehab <m.chehab@samsung.com>
      f035eb4e
  24. 26 7月, 2014 1 次提交