• Niklas Söderlund's avatar
    [media] rcar-vin: allow switch between capturing modes when stalling · 82ec4ca9
    Niklas Söderlund authored
    If userspace can't feed the driver with buffers as fast as the driver
    consumes them the driver will stop video capturing and wait for more
    buffers from userspace, the driver is stalled. Once it have been feed
    one or more free buffers it will recover from the stall and resume
    capturing.
    
    Instead of continue to capture using the same capture mode as before the
    stall allow the driver to choose between single and continuous mode
    based on free buffer availability. Do this by stopping capturing when
    the driver becomes stalled and restart capturing once it continues. By
    doing
    this the capture mode will be evaluated each time the driver is
    recovering from a stall.
    
    This behavior is needed to fix a bug where continuous capturing mode is
    used, userspace is about to stop the stream and is waiting for the last
    buffers to be returned from the driver and is not queuing any new
    buffers. In this case the driver becomes stalled when there are only 3
    buffers remaining streaming will never resume since the driver is
    waiting for userspace to feed it more buffers before it can continue
    streaming.  With this fix the driver will then switch to single capture
    mode for the last 3 buffers and a deadlock is avoided. The issue can be
    demonstrated using yavta.
    
    $ yavta -f RGB565 -s 640x480 -n 4 --capture=10  /dev/video22
    Device /dev/video22 opened.
    Device `R_Car_VIN' on `platform:e6ef1000.video' (driver 'rcar_vin') supports video, capture, without mplanes.
    Video format set: RGB565 (50424752) 640x480 (stride 1280) field interlaced buffer size 614400
    Video format: RGB565 (50424752) 640x480 (stride 1280) field interlaced buffer size 614400
    4 buffers requested.
    length: 614400 offset: 0 timestamp type/source: mono/EoF
    Buffer 0/0 mapped at address 0xb6cc7000.
    length: 614400 offset: 614400 timestamp type/source: mono/EoF
    Buffer 1/0 mapped at address 0xb6c31000.
    length: 614400 offset: 1228800 timestamp type/source: mono/EoF
    Buffer 2/0 mapped at address 0xb6b9b000.
    length: 614400 offset: 1843200 timestamp type/source: mono/EoF
    Buffer 3/0 mapped at address 0xb6b05000.
    0 (0) [-] interlaced 0 614400 B 38.240285 38.240303 12.421 fps ts mono/EoF
    1 (1) [-] interlaced 1 614400 B 38.282329 38.282346 23.785 fps ts mono/EoF
    2 (2) [-] interlaced 2 614400 B 38.322324 38.322338 25.003 fps ts mono/EoF
    3 (3) [-] interlaced 3 614400 B 38.362318 38.362333 25.004 fps ts mono/EoF
    4 (0) [-] interlaced 4 614400 B 38.402313 38.402328 25.003 fps ts mono/EoF
    5 (1) [-] interlaced 5 614400 B 38.442307 38.442321 25.004 fps ts mono/EoF
    6 (2) [-] interlaced 6 614400 B 38.482301 38.482316 25.004 fps ts mono/EoF
    7 (3) [-] interlaced 7 614400 B 38.522295 38.522312 25.004 fps ts mono/EoF
    8 (0) [-] interlaced 8 614400 B 38.562290 38.562306 25.003 fps ts mono/EoF
    <blocks forever, waiting for the last buffer>
    
    This fix also allow the driver to switch to single capture mode if
    userspace doesn't feed it buffers fast enough. Or the other way around,
    if userspace suddenly feeds the driver buffers faster it can switch to
    continues capturing mode.
    Signed-off-by: default avatarNiklas Söderlund <niklas.soderlund+renesas@ragnatech.se>
    Reviewed-by: default avatarLaurent Pinchart <laurent.pinchart@ideasonboard.com>
    Signed-off-by: default avatarHans Verkuil <hans.verkuil@cisco.com>
    Signed-off-by: default avatarMauro Carvalho Chehab <mchehab@s-opensource.com>
    82ec4ca9
rcar-dma.c 34.2 KB