media: vb2: Allow reqbufs(0) with "in use" MMAP buffers

Upstream commit d644cca

Videobuf2 presently does not allow VIDIOC_REQBUFS to destroy outstanding
buffers if the queue is of type V4L2_MEMORY_MMAP, and if the buffers are
considered "in use".  This is different behavior than for other memory
types and prevents us from deallocating buffers in following two cases:

1) There are outstanding mmap()ed views on the buffer. However even if
   we put the buffer in reqbufs(0), there will be remaining references,
   due to vma .open/close() adjusting vb2 buffer refcount appropriately.
   This means that the buffer will be in fact freed only when the last
   mmap()ed view is unmapped.

2) Buffer has been exported as a DMABUF. Refcount of the vb2 buffer
   is managed properly by VB2 DMABUF ops, i.e. incremented on DMABUF
   get and decremented on DMABUF release. This means that the buffer
   will be alive until all importers release it.

Considering both cases above, there does not seem to be any need to
prevent reqbufs(0) operation, because buffer lifetime is already
properly managed by both mmap() and DMABUF code paths. Let's remove it
and allow userspace freeing the queue (and potentially allocating a new
one) even though old buffers might be still in processing.

To let userspace know that the kernel now supports orphaning buffers
that are still in use, add a new V4L2_BUF_CAP_SUPPORTS_ORPHANED_BUFS
to be set by reqbufs and create_bufs.

[[email protected]: added V4L2_BUF_CAP_SUPPORTS_ORPHANED_BUFS,
 updated documentation, and added back debug message]

Signed-off-by: John Sheu <[email protected]>
Reviewed-by: Pawel Osciak <[email protected]>
Signed-off-by: Tomasz Figa <[email protected]>
Signed-off-by: Philipp Zabel <[email protected]>
Acked-by: Sakari Ailus <[email protected]>
Signed-off-by: Hans Verkuil <[email protected]>
[[email protected]: added V4L2-BUF-CAP-SUPPORTS-ORPHANED-BUFS ref]
Signed-off-by: Mauro Carvalho Chehab <[email protected]>

drm/vc4: Limit fkms to modes <= 85Hz

Selecting 1080p100 and 120 has very limited gain, but don't want
to block VGA85 and similar.

Signed-off-by: Dave Stevenson <[email protected]>

Revert "smsc95xx: dynamically fix up TX buffer alignment with padding…

… bytes"

As reported in raspberrypi#2964 this
commit causes a regression corrupting non-option TCP ack packets.

This reverts commit 96b972d.

Merge remote-tracking branch 'stable/linux-4.14.y' into rpi-4.14.y

Merge remote-tracking branch 'stable/linux-4.14.y' into rpi-4.14.y

Merge remote-tracking branch 'stable/linux-4.14.y' into rpi-4.14.y

Merge remote-tracking branch 'stable/linux-4.14.y' into rpi-4.14.y

media: ov5647: Use gpiod_set_value_cansleep

All calls to the gpio library are in contexts that can sleep,
therefore there is no issue with having those GPIOs controlled
by controllers which require sleeping (eg I2C GPIO expanders).

Switch to using gpiod_set_value_cansleep instead of gpiod_set_value
to avoid triggering the warning in gpiolib should the GPIO
controller need to sleep.

Signed-off-by: Dave Stevenson <[email protected]>

Merge remote-tracking branch 'stable/linux-4.14.y' into rpi-4.14.y

media: cxd2880-spi: Bump to match 4.18.y version

Signed-off-by: popcornmix <[email protected]>