08 Feb, 2019

19 commits

  • This function is no longer used, so drop it.

    Signed-off-by: Hans Verkuil
    Acked-by: Sakari Ailus
    Signed-off-by: Mauro Carvalho Chehab

    Hans Verkuil
     
  • Just like vb2 does, use u64 internally to store the timestamps
    of the buffers. Only convert to timeval when interfacing with
    userspace.

    Signed-off-by: Hans Verkuil
    Acked-by: Sakari Ailus
    Signed-off-by: Mauro Carvalho Chehab

    Hans Verkuil
     
  • Just like vb2 does, use u64 internally to store the timestamps
    of the buffers. Only convert to timeval when interfacing with
    userspace.

    Signed-off-by: Hans Verkuil
    Acked-by: Sakari Ailus
    Signed-off-by: Mauro Carvalho Chehab

    Hans Verkuil
     
  • Just like vb2 does, use u64 internally to store the timestamps
    of the buffers. Only convert to timeval when interfacing with
    userspace.

    Signed-off-by: Hans Verkuil
    Acked-by: Sakari Ailus
    Signed-off-by: Mauro Carvalho Chehab

    Hans Verkuil
     
  • Just like vb2 does, use u64 internally to store the timestamps
    of the buffers. Only convert to timeval when interfacing with
    userspace.

    Signed-off-by: Hans Verkuil
    Acked-by: Sakari Ailus
    Signed-off-by: Mauro Carvalho Chehab

    Hans Verkuil
     
  • Just like vb2 does, use u64 internally to store the timestamps
    of the buffers. Only convert to timeval when interfacing with
    userspace.

    Signed-off-by: Hans Verkuil
    Acked-by: Sakari Ailus
    Signed-off-by: Mauro Carvalho Chehab

    Hans Verkuil
     
  • Just like vb2 does, use u64 internally to store the timestamps
    of the buffers. Only convert to timeval when interfacing with
    userspace.

    Signed-off-by: Hans Verkuil
    Acked-by: Sakari Ailus
    Signed-off-by: Mauro Carvalho Chehab

    Hans Verkuil
     
  • Internally use ktime_get_ns() to get the timestamp of the event.
    Only convert to timespec when interfacing with userspace.

    Signed-off-by: Hans Verkuil
    Acked-by: Sakari Ailus
    Signed-off-by: Mauro Carvalho Chehab

    Hans Verkuil
     
  • The comparison css->pipes[pipe].bindex < 0 is always false because
    bindex is an unsigned int. Fix this by using a signed integer for
    the comparison.

    Detected by CoverityScan, CID#1476023 ("Unsigned compared against 0")

    Fixes: f5f2e4273518 ("media: staging/intel-ipu3: Add css pipeline programming")

    Signed-off-by: Colin Ian King
    Signed-off-by: Sakari Ailus
    Signed-off-by: Mauro Carvalho Chehab

    Colin Ian King
     
  • Since ipu3_css_buf_dequeue() never returns NULL, remove the
    dead code to fix static checker warning:

    drivers/staging/media/ipu3/ipu3.c:493 imgu_isr_threaded()
    warn: 'b' is an error pointer or valid

    Reported-by: Dan Carpenter
    [Bug report: https://lore.kernel.org/linux-media/20190104122856.GA1169@kadam/]
    Signed-off-by: Yong Zhi
    Reviewed-by: Tomasz Figa
    Signed-off-by: Sakari Ailus
    Signed-off-by: Mauro Carvalho Chehab

    Yong Zhi
     
  • This addresses the below TODO item.
    - Use V4L2_CTRL_TYPE_MENU for dual-pipe mode control. (Sakari)

    Signed-off-by: Yong Zhi
    Reviewed-by: Tomasz Figa
    Signed-off-by: Sakari Ailus
    Signed-off-by: Mauro Carvalho Chehab

    Yong Zhi
     
  • The UVC video driver converts the timestamp from hardware specific unit
    to one known by the kernel at the time when the buffer is dequeued. This
    is fine in general, but the streamoff operation consists of the
    following steps (among other things):

    1. uvc_video_clock_cleanup --- the hardware clock sample array is
    released and the pointer to the array is set to NULL,

    2. buffers in active state are returned to the user and

    3. buf_finish callback is called on buffers that are prepared.
    buf_finish includes calling uvc_video_clock_update that accesses the
    hardware clock sample array.

    The above is serialised by a queue specific mutex. Address the problem
    by skipping the clock conversion if the hardware clock sample array is
    already released.

    Fixes: 9c0863b1cc48 ("[media] vb2: call buf_finish from __queue_cancel")

    Reported-by: Chiranjeevi Rapolu
    Tested-by: Chiranjeevi Rapolu
    Signed-off-by: Sakari Ailus
    Cc: stable@vger.kernel.org
    Signed-off-by: Laurent Pinchart
    Signed-off-by: Mauro Carvalho Chehab

    Sakari Ailus
     
  • When initially testing the Camera Terminal Descriptor wTerminalType
    field (buffer[4]), no mask is used. Later in the function, the MSB is
    overloaded to store the descriptor subtype, and so a mask of 0x7fff
    is used to check the type.

    If a descriptor is specially crafted to set this overloaded bit in the
    original wTerminalType field, the initial type check will fail (falling
    through, without adjusting the buffer size), but the later type checks
    will pass, assuming the buffer has been made suitably large, causing an
    overflow.

    Avoid this problem by checking for the MSB in the wTerminalType field.
    If the bit is set, assume the descriptor is bad, and abort parsing it.

    Originally reported here:
    https://groups.google.com/forum/#!topic/syzkaller/Ot1fOE6v1d8
    A similar (non-compiling) patch was provided at that time.

    Reported-by: syzbot
    Signed-off-by: Alistair Strachan
    Signed-off-by: Laurent Pinchart
    Signed-off-by: Mauro Carvalho Chehab

    Alistair Strachan
     
  • The SOURCE_CHANGE event is decoder specific, so don't allow it for
    encoders.

    Signed-off-by: Hans Verkuil
    Signed-off-by: Mauro Carvalho Chehab

    Hans Verkuil
     
  • It is good practice to fill in the bus_info.

    Signed-off-by: Hans Verkuil
    Signed-off-by: Mauro Carvalho Chehab

    Hans Verkuil
     
  • It is good practice to fill in bus_info.

    Signed-off-by: Hans Verkuil
    Signed-off-by: Mauro Carvalho Chehab

    Hans Verkuil
     
  • Check that the selection buf_type is valid before calling get_q_data() to
    avoid hitting the WARN(1) in that function if the buffer type is not valid.

    Signed-off-by: Hans Verkuil
    Reported-by: syzbot+44b24cff6bf96006ecfa@syzkaller.appspotmail.com
    Signed-off-by: Mauro Carvalho Chehab

    Hans Verkuil
     
  • Fix a copy&paste error to make RGB -> BT.2020 YUV conversion actually
    selectable. Fixes the following warning:

    drivers/media/platform/imx-pxp.c:683:24: warning: duplicated ‘if’ condition [-Wduplicated-cond]

    Fixes: 51abcf7fdb70 ("media: imx-pxp: add i.MX Pixel Pipeline driver")

    Reported-by: David Binderman
    Signed-off-by: Philipp Zabel
    Signed-off-by: Hans Verkuil
    Signed-off-by: Mauro Carvalho Chehab

    Philipp Zabel
     
  • Commit 2cc1802f62e5 ("media: vb2: Keep dma-buf buffers mapped until
    they are freed") removed code leaving a local variable unused.

    Remove it to avoid a compiler warning.

    Fixes: 2cc1802f62e5 ("media: vb2: Keep dma-buf buffers mapped until they are freed")

    Signed-off-by: Hans Verkuil
    Signed-off-by: Mauro Carvalho Chehab

    Hans Verkuil
     

01 Feb, 2019

3 commits

  • While there's a control to allow setting it at runtime, as the
    control handler is per file handler, only the application setting
    the m2m device can change it. As this is a custom control, it is
    unlikely that existing apps would be able to set it.

    Due to that, and due to the fact that v4l2-mem2mem serializes all
    accesses to a m2m device, trying to setup two GStreamer
    v4l2videoconvert instance at the same time will cause frame drops.

    So, add an alternate way of setting its default via a modprobe parameter.

    Signed-off-by: Mauro Carvalho Chehab

    Mauro Carvalho Chehab
     
  • It doesn't make sense to have a per-device work queue, as the
    scheduler should be called per file handler. Having a single
    one causes failures if multiple streams are filtered by vim2m.

    So, move it to be inside the context structure.

    Signed-off-by: Mauro Carvalho Chehab

    Mauro Carvalho Chehab
     
  • Despite vim2m is reporting that it supports RGB565BE and YUYV,
    that's not true.

    Right now, it just says that it supports both format, but it
    doesn't actually support them.

    Also, horizontal flip is not properly implemented. It sounds
    that it was designed to do a pseudo-horizontal flip using 8
    tiles. Yet, as it doesn't do format conversion, the result
    is a mess.

    I suspect that it was done this way in order to save CPU time,
    at the time of OMAP2 days.

    That's messy and doesn't really help if someone wants to
    use vim2m to test a pipeline.

    Worse than that, the unique RGB format it says it supports is
    RGB565BE, with is not supported by Gstreamer. That prevents
    practical usage of it, even for tests.

    So, instead, properly implement fourcc format conversions,
    adding a few more RGB formats:

    - RGB and BGR with 24 bits
    - RGB565LE (known as RGB16 at gstreamer)

    Also allows using any of the 5 supported formats as either
    capture or output.

    Note: The YUYV conversion routines are based on the conversion code
    written by Hans de Goede inside libv4lconvert (part of v4l-utils),
    released under LGPGL 2.1 (GPL 2.0 compatible).

    Tested all possible format combinations except for RGB565BE,
    as Gstreamer currently doesn't support it.

    Signed-off-by: Mauro Carvalho Chehab

    Mauro Carvalho Chehab
     

31 Jan, 2019

15 commits

  • The wrong size check was performed for output formats like NV24 which
    set vfmt->buffers to 1, but vfmt->planes is 2. It was incorrectly
    checking the payload size for plane 1, which doesn't exist.

    Note: vfmt->buffers refers to the number of per-plane-buffers that
    should be allocated. vfmt->planes refers to the number of planes
    that make up an image. vfmt->planes may be > vfmt->buffers.

    Signed-off-by: Hans Verkuil
    Signed-off-by: Mauro Carvalho Chehab

    Hans Verkuil
     
  • The buf_out_validate is required for output queues in combination
    with requests. Check this.

    Signed-off-by: Hans Verkuil
    Signed-off-by: Mauro Carvalho Chehab

    Hans Verkuil
     
  • Validate the field for an output buffer. This ensures that the
    field is validated when the buffer is queued to a request, and
    not when the request itself is queued, which is too late.

    Signed-off-by: Hans Verkuil
    Signed-off-by: Mauro Carvalho Chehab

    Hans Verkuil
     
  • Validate the field for an output buffer. This ensures that the
    field is validated when the buffer is queued to a request, and
    not when the request itself is queued, which is too late.

    Signed-off-by: Hans Verkuil
    Signed-off-by: Mauro Carvalho Chehab

    Hans Verkuil
     
  • Validate the field for an output buffer. This ensures that the
    field is validated when the buffer is queued to a request, and
    not when the request itself is queued, which is too late.

    Signed-off-by: Hans Verkuil
    Signed-off-by: Mauro Carvalho Chehab

    Hans Verkuil
     
  • When queueing a buffer to a request the 'field' value is not validated.
    That field is only validated when the _buf_prepare() is called,
    which happens when the request is queued.

    However, this validation should happen at QBUF time, since you want
    to know about this as soon as possible. Also, the spec requires that
    the 'field' value is validated at QBUF time.

    This patch adds a new buf_out_validate callback to validate the
    output buffer at buf_prepare time or when QBUF queues an unprepared
    buffer to a request. This callback is mandatory for output queues
    that support requests.

    This issue was found by v4l2-compliance since it failed to replace
    V4L2_FIELD_ANY by a proper field value when testing the vivid video
    output in combination with requests.

    Signed-off-by: Hans Verkuil
    Signed-off-by: Mauro Carvalho Chehab

    Hans Verkuil
     
  • Access to reference frames that were imported from dma-buf was taken
    care of and is no longer a pending item on the driver's TODO list.

    Signed-off-by: Paul Kocialkowski
    Signed-off-by: Hans Verkuil
    Signed-off-by: Mauro Carvalho Chehab

    Paul Kocialkowski
     
  • When using vb2 for video decoding, dequeued capture buffers may still
    be accessed by the hardware: this is the case when they are used as
    reference frames for decoding subsequent frames.

    When the buffer is imported with dma-buf, it needs to be mapped before
    access. Until now, it was mapped when queuing and unmapped when
    dequeuing, which doesn't work for access as a reference frames.

    One way to solve this would be to map the buffer again when it is
    needed as a reference, but the mapping/unmapping operations can
    seriously impact performance. As a result, map the buffer once (when it
    is first needed when queued) and keep it mapped until it is freed.

    Reviewed-on: https://chromium-review.googlesource.com/334103
    [Paul: Updated for mainline and changed commit message]

    Signed-off-by: Pawel Osciak
    Signed-off-by: Paul Kocialkowski
    Signed-off-by: Hans Verkuil
    Signed-off-by: Mauro Carvalho Chehab

    Pawel Osciak
     
  • This reverts commit cf20ae1535eb690a87c29b9cc7af51881384e967.

    The vb2_find_timestamp helper was modified to allow finding buffers
    regardless of their current state in the queue. This means that we
    no longer have to take particular care of references to the current
    capture buffer.

    Signed-off-by: Paul Kocialkowski
    Signed-off-by: Hans Verkuil
    Signed-off-by: Mauro Carvalho Chehab

    Paul Kocialkowski
     
  • There really is no reason why vb2_find_timestamp can't just find
    buffers in any state. Drop that part of the test.

    This also means that vb->timestamp should only be set to 0 when
    the driver doesn't copy timestamps.

    This change allows for more efficient pipelining (i.e. you can use
    a buffer for a reference frame even when it is queued).

    Signed-off-by: Hans Verkuil
    Reviewed-by: Tomasz Figa
    Reviewed-by: Alexandre Courbot
    Reviewed-by: Paul Kocialkowski
    Signed-off-by: Mauro Carvalho Chehab

    Hans Verkuil
     
  • Vdec: Using standard CCF interface to set parent clock and
    clock rate in dtsi and using common interface to open/close
    video decoder clock.
    Venc: Using standard CCF interface to set parent clock in dtsi
    and using common interface to open/close video encoder clock.

    Signed-off-by: Yunfei Dong
    Signed-off-by: Qianqian Yan
    Signed-off-by: Hans Verkuil
    Signed-off-by: Mauro Carvalho Chehab

    Yunfei Dong
     
  • Fix MTK binding document for MT8173 dtsi changed in order
    to use standard CCF interface.
    MT8173 SoC from Mediatek.

    Signed-off-by: Yunfei Dong
    Signed-off-by: Qianqian Yan
    Reviewed-by: Rob Herring
    Signed-off-by: Hans Verkuil
    Signed-off-by: Mauro Carvalho Chehab

    Yunfei Dong
     
  • Upstream must be stopped immediately after receiving the last EOF and
    before disabling the IDMA channel. This can be accomplished by moving
    upstream stream off to just after receiving the last EOF completion in
    prp_stop(). For symmetry also move upstream stream on to end of
    prp_start().

    This fixes a complete system hard lockup on the SabreAuto when streaming
    from the ADV7180, by repeatedly sending a stream off immediately followed
    by stream on:

    while true; do v4l2-ctl -d1 --stream-mmap --stream-count=3; done

    Eventually this either causes the system lockup or EOF timeouts at all
    subsequent stream on, until a system reset.

    The lockup occurs when disabling the IDMA channel at stream off. Stopping
    the video data stream entering the IDMA channel before disabling the
    channel itself appears to be a reliable fix for the hard lockup.

    Fixes: f0d9c8924e2c3 ("[media] media: imx: Add IC subdev drivers")

    Reported-by: Gaël PORTAY
    Tested-by: Gaël PORTAY
    Signed-off-by: Steve Longerbeam
    Cc: stable@vger.kernel.org # for 4.13 and up
    Signed-off-by: Hans Verkuil
    Signed-off-by: Mauro Carvalho Chehab

    Steve Longerbeam
     
  • Move upstream stream off to just after receiving the last EOF completion
    and disabling the CSI (and thus before disabling the IDMA channel) in
    csi_stop(). For symmetry also move upstream stream on to beginning of
    csi_start().

    Doing this makes csi_s_stream() more symmetric with prp_s_stream() which
    will require the same change to fix a hard lockup.

    Signed-off-by: Steve Longerbeam
    Cc: stable@vger.kernel.org # for 4.13 and up
    Signed-off-by: Hans Verkuil
    Signed-off-by: Mauro Carvalho Chehab

    Steve Longerbeam
     
  • Disable the CSI immediately after receiving the last EOF before stream
    off (and thus before disabling the IDMA channel). Do this by moving the
    wait for EOF completion into a new function csi_idmac_wait_last_eof().

    This fixes a complete system hard lockup on the SabreAuto when streaming
    from the ADV7180, by repeatedly sending a stream off immediately followed
    by stream on:

    while true; do v4l2-ctl -d4 --stream-mmap --stream-count=3; done

    Eventually this either causes the system lockup or EOF timeouts at all
    subsequent stream on, until a system reset.

    The lockup occurs when disabling the IDMA channel at stream off. Disabling
    the CSI before disabling the IDMA channel appears to be a reliable fix for
    the hard lockup.

    Fixes: 4a34ec8e470cb ("[media] media: imx: Add CSI subdev driver")

    Reported-by: Gaël PORTAY
    Signed-off-by: Steve Longerbeam
    Cc: stable@vger.kernel.org # for 4.13 and up
    Signed-off-by: Hans Verkuil
    Signed-off-by: Mauro Carvalho Chehab

    Steve Longerbeam
     

26 Jan, 2019

3 commits

  • drivers/media/platform/vicodec/vicodec-core.c:drivers/media/platform/vicodec/vicodec-core.c:210:23: warning: symbol 'get_next_header' was not declared. Should it be static?
    drivers/media/platform/vicodec/vicodec-core.c:210:23: warning: no previous prototype for 'get_next_header' [-Wmissing-prototypes]
    enum vb2_buffer_state get_next_header(struct vicodec_ctx *ctx, u8 **pp, u32 sz)
    ^~~~~~~~~~~~~~~

    Signed-off-by: Mauro Carvalho Chehab

    Mauro Carvalho Chehab
     
  • Make sure that the pointer to the compressed frame does not
    get out of the buffer.

    Signed-off-by: Dafna Hirschfeld
    Signed-off-by: Hans Verkuil
    Signed-off-by: Mauro Carvalho Chehab

    Dafna Hirschfeld
     
  • If the the queues are not streaming then the first resolution
    change is handled in the buf_queue callback.
    The following resolution change events are handled in job_ready.

    Signed-off-by: Dafna Hirschfeld
    Signed-off-by: Hans Verkuil
    [hverkuil-cisco@xs4all.nl: wrap info_from_header prototype]
    Signed-off-by: Mauro Carvalho Chehab

    Dafna Hirschfeld