1. 12 Feb, 2019 10 commits
  2. 26 Jan, 2019 3 commits
    • Vivek Gautam's avatar
      media: venus: core: Set dma maximum segment size · 181aa135
      Vivek Gautam authored
      [ Upstream commit de2563bc ]
      
      Turning on CONFIG_DMA_API_DEBUG_SG results in the following error:
      
      [  460.308650] ------------[ cut here ]------------
      [  460.313490] qcom-venus aa00000.video-codec: DMA-API: mapping sg segment longer than device claims to support [len=4194304] [max=65536]
      [  460.326017] WARNING: CPU: 3 PID: 3555 at src/kernel/dma/debug.c:1301 debug_dma_map_sg+0x174/0x254
      [  460.338888] Modules linked in: venus_dec venus_enc videobuf2_dma_sg videobuf2_memops hci_uart btqca bluetooth venus_core v4l2_mem2mem videobuf2_v4l2 videobuf2_common ath10k_snoc ath10k_core ath lzo lzo_compress zramjoydev
      [  460.375811] CPU: 3 PID: 3555 Comm: V4L2DecoderThre Tainted: G        W         4.19.1 #82
      [  460.384223] Hardware name: Google Cheza (rev1) (DT)
      [  460.389251] pstate: 60400009 (nZCv daif +PAN -UAO)
      [  460.394191] pc : debug_dma_map_sg+0x174/0x254
      [  460.398680] lr : debug_dma_map_sg+0x174/0x254
      [  460.403162] sp : ffffff80200c37d0
      [  460.406583] x29: ffffff80200c3830 x28: 0000000000010000
      [  460.412056] x27: 00000000ffffffff x26: ffffffc0f785ea80
      [  460.417532] x25: 0000000000000000 x24: ffffffc0f4ea1290
      [  460.423001] x23: ffffffc09e700300 x22: ffffffc0f4ea1290
      [  460.428470] x21: ffffff8009037000 x20: 0000000000000001
      [  460.433936] x19: ffffff80091b0000 x18: 0000000000000000
      [  460.439411] x17: 0000000000000000 x16: 000000000000f251
      [  460.444885] x15: 0000000000000006 x14: 0720072007200720
      [  460.450354] x13: ffffff800af536e0 x12: 0000000000000000
      [  460.455822] x11: 0000000000000000 x10: 0000000000000000
      [  460.461288] x9 : 537944d9c6c48d00 x8 : 537944d9c6c48d00
      [  460.466758] x7 : 0000000000000000 x6 : ffffffc0f8d98f80
      [  460.472230] x5 : 0000000000000000 x4 : 0000000000000000
      [  460.477703] x3 : 000000000000008a x2 : ffffffc0fdb13948
      [  460.483170] x1 : ffffffc0fdb0b0b0 x0 : 000000000000007a
      [  460.488640] Call trace:
      [  460.491165]  debug_dma_map_sg+0x174/0x254
      [  460.495307]  vb2_dma_sg_alloc+0x260/0x2dc [videobuf2_dma_sg]
      [  460.501150]  __vb2_queue_alloc+0x164/0x374 [videobuf2_common]
      [  460.507076]  vb2_core_reqbufs+0xfc/0x23c [videobuf2_common]
      [  460.512815]  vb2_reqbufs+0x44/0x5c [videobuf2_v4l2]
      [  460.517853]  v4l2_m2m_reqbufs+0x44/0x78 [v4l2_mem2mem]
      [  460.523144]  v4l2_m2m_ioctl_reqbufs+0x1c/0x28 [v4l2_mem2mem]
      [  460.528976]  v4l_reqbufs+0x30/0x40
      [  460.532480]  __video_do_ioctl+0x36c/0x454
      [  460.536610]  video_usercopy+0x25c/0x51c
      [  460.540572]  video_ioctl2+0x38/0x48
      [  460.544176]  v4l2_ioctl+0x60/0x74
      [  460.547602]  do_video_ioctl+0x948/0x3520
      [  460.551648]  v4l2_compat_ioctl32+0x60/0x98
      [  460.555872]  __arm64_compat_sys_ioctl+0x134/0x20c
      [  460.560718]  el0_svc_common+0x9c/0xe4
      [  460.564498]  el0_svc_compat_handler+0x2c/0x38
      [  460.568982]  el0_svc_compat+0x8/0x18
      [  460.572672] ---[ end trace ce209b87b2f3af88 ]---
      
      >From above warning one would deduce that the sg segment will overflow
      the device's capacity. In reality, the hardware can accommodate larger
      sg segments.
      So, initialize the max segment size properly to weed out this warning.
      
      Based on a similar patch sent by Sean Paul for mdss:
      https://patchwork.kernel.org/patch/10671457/Signed-off-by: default avatarVivek Gautam <vivek.gautam@codeaurora.org>
      Acked-by: default avatarStanimir Varbanov <stanimir.varbanov@linaro.org>
      Signed-off-by: default avatarHans Verkuil <hverkuil-cisco@xs4all.nl>
      Signed-off-by: default avatarMauro Carvalho Chehab <mchehab+samsung@kernel.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      181aa135
    • Nathan Chancellor's avatar
      media: firewire: Fix app_info parameter type in avc_ca{,_app}_info · e6256cb1
      Nathan Chancellor authored
      [ Upstream commit b2e9a4ed ]
      
      Clang warns:
      
      drivers/media/firewire/firedtv-avc.c:999:45: warning: implicit
      conversion from 'int' to 'char' changes value from 159 to -97
      [-Wconstant-conversion]
              app_info[0] = (EN50221_TAG_APP_INFO >> 16) & 0xff;
                          ~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~
      drivers/media/firewire/firedtv-avc.c:1000:45: warning: implicit
      conversion from 'int' to 'char' changes value from 128 to -128
      [-Wconstant-conversion]
              app_info[1] = (EN50221_TAG_APP_INFO >>  8) & 0xff;
                          ~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~
      drivers/media/firewire/firedtv-avc.c:1040:44: warning: implicit
      conversion from 'int' to 'char' changes value from 159 to -97
      [-Wconstant-conversion]
              app_info[0] = (EN50221_TAG_CA_INFO >> 16) & 0xff;
                          ~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~
      drivers/media/firewire/firedtv-avc.c:1041:44: warning: implicit
      conversion from 'int' to 'char' changes value from 128 to -128
      [-Wconstant-conversion]
              app_info[1] = (EN50221_TAG_CA_INFO >>  8) & 0xff;
                          ~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~
      4 warnings generated.
      
      Change app_info's type to unsigned char to match the type of the
      member msg in struct ca_msg, which is the only thing passed into the
      app_info parameter in this function.
      
      Link: https://github.com/ClangBuiltLinux/linux/issues/105Signed-off-by: Nathan Chancellor's avatarNathan Chancellor <natechancellor@gmail.com>
      Signed-off-by: default avatarMauro Carvalho Chehab <mchehab+samsung@kernel.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      e6256cb1
    • Daniel Axtens's avatar
      media: uvcvideo: Refactor teardown of uvc on USB disconnect · 13e97606
      Daniel Axtens authored
      [ Upstream commit 10e1fdb9 ]
      
      Currently, disconnecting a USB webcam while it is in use prints out a
      number of warnings, such as:
      
      WARNING: CPU: 2 PID: 3118 at /build/linux-ezBi1T/linux-4.8.0/fs/sysfs/group.c:237 sysfs_remove_group+0x8b/0x90
      sysfs group ffffffffa7cd0780 not found for kobject 'event13'
      
      This has been noticed before. [0]
      
      This is because of the order in which things are torn down.
      
      If there are no streams active during a USB disconnect:
      
       - uvc_disconnect() is invoked via device_del() through the bus
         notifier mechanism.
      
       - this calls uvc_unregister_video().
      
       - uvc_unregister_video() unregisters the video device for each
         stream,
      
       - because there are no streams open, it calls uvc_delete()
      
       - uvc_delete() calls uvc_status_cleanup(), which cleans up the status
         input device.
      
       - uvc_delete() calls media_device_unregister(), which cleans up the
         media device
      
       - uvc_delete(), uvc_unregister_video() and uvc_disconnect() all
         return, and we end up back in device_del().
      
       - device_del() then cleans up the sysfs folder for the camera with
         dpm_sysfs_remove(). Because uvc_status_cleanup() and
         media_device_unregister() have already been called, this all works
         nicely.
      
      If, on the other hand, there *are* streams active during a USB disconnect:
      
       - uvc_disconnect() is invoked
      
       - this calls uvc_unregister_video()
      
       - uvc_unregister_video() unregisters the video device for each
         stream,
      
       - uvc_unregister_video() and uvc_disconnect() return, and we end up
         back in device_del().
      
       - device_del() then cleans up the sysfs folder for the camera with
         dpm_sysfs_remove(). Because the status input device and the media
         device are children of the USB device, this also deletes their
         sysfs folders.
      
       - Sometime later, the final stream is closed, invoking uvc_release().
      
       - uvc_release() calls uvc_delete()
      
       - uvc_delete() calls uvc_status_cleanup(), which cleans up the status
         input device. Because the sysfs directory has already been removed,
         this causes a WARNing.
      
       - uvc_delete() calls media_device_unregister(), which cleans up the
         media device. Because the sysfs directory has already been removed,
         this causes another WARNing.
      
      To fix this, we need to make sure the devices are always unregistered
      before the end of uvc_disconnect(). To this, move the unregistration
      into the disconnect path:
      
       - split uvc_status_cleanup() into two parts, one on disconnect that
         unregisters and one on delete that frees.
      
       - move v4l2_device_unregister() and media_device_unregister() into
         the disconnect path.
      
      [0]: https://lkml.org/lkml/2016/12/8/657
      
      [Renamed uvc_input_cleanup() to uvc_input_unregister()]
      Signed-off-by: default avatarDaniel Axtens <dja@axtens.net>
      Acked-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: Laurent Pinchart's avatarLaurent Pinchart <laurent.pinchart@ideasonboard.com>
      Signed-off-by: default avatarMauro Carvalho Chehab <mchehab+samsung@kernel.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      13e97606
  3. 22 Jan, 2019 6 commits
  4. 13 Jan, 2019 1 commit
  5. 09 Jan, 2019 11 commits
  6. 05 Dec, 2018 2 commits
  7. 03 Dec, 2018 7 commits