linux-stable.git/drivers/media/platform, branch v5.1.2

Merge tag 'devicetree-for-5.1' of git://git.kernel.org/pub/scm/linux/kernel/git/robh/linux

2019-03-10T17:58:43+00:00

Pull Devicetree updates from Rob Herring:

 - Fix a unittest failure on UML. Preparation for converting to kunit
   test framework.

 - Add annotations to dtx_diff output

 - Fix unittest reporting of expected error

 - Move DMA configuration for virtual devices into the driver that needs
   it (s5p-mfc)

 - Vendor prefixes for feiyang and techstar

 - Convert ARM GIC, GICv3, and L2x0 to DT schema

 - Add r8a7778/9 HSCIF serial bindings

* tag 'devicetree-for-5.1' of git://git.kernel.org/pub/scm/linux/kernel/git/robh/linux:
  of: unittest: unflatten device tree on UML when testing
  dt-bindings: Add vendor prefix for feiyang
  dt-bindings: Add vendor prefix for techstar
  dt-bindings: display: add missing semicolon in example
  of: mark early_init_dt_alloc_reserved_memory_arch static
  of: add dtc annotations functionality to dtx_diff
  of: unittest: add caution to function header comment
  of: unittest: remove report of expected error
  dt-bindings: interrupt-controller: Convert ARM GICv3 to json-schema
  dt-bindings: interrupt-controller: Convert ARM GIC to json-schema
  dt-bindings: arm: l2x0: Convert L2 cache to json-schema
  media: s5p-mfc: Fix memdev DMA configuration
  dt-bindings: serial: sh-sci: Document r8a7778/9 HSCIF bindings

media: vim2m: Address some coding style issues

2019-03-01T16:51:23+00:00

As we did lots of change at vim2m driver, let's take the
opportunity and make checkpatch happier, addressing the
errors/warnings that makes sense.

While here, increment driver's version.

No functional changes.

Signed-off-by: Mauro Carvalho Chehab

media: vim2m: don't use BUG()

2019-03-01T16:48:56+00:00

There's no reason why this driver should use BUG(). Instead,
just properly handle issue, returning an error code where
pertinent.

Signed-off-by: Mauro Carvalho Chehab

media: vim2m: speedup passthrough copy

2019-03-01T16:31:07+00:00

When in passthrough mode, copy the entire line at once, in
order to make it faster (if not HFLIP).

Signed-off-by: Mauro Carvalho Chehab

media: vim2m: add an horizontal scaler

2019-03-01T16:25:05+00:00

Add an horizontal linear scaler using Breseham algorithm in
order to speep up its calculus.

Signed-off-by: Mauro Carvalho Chehab

media: vim2m: don't accept YUYV anymore as output format

2019-03-01T16:16:48+00:00

Handling any Y,Cr,Cb formats require some extra logic, as it
handles a group of two pixels. That's easy while we don't do
horizontal scaling.

However, doing horizontal scaling with such formats would require
a lot more code, in order to avoid distortions, as, if it scales
to two non-consecutive points, the logic would need to read 4
points in order to properly convert to RGB.

As this is just a test driver, and we want fast algorithms,
let's just get rid of this format as an output one.

Signed-off-by: Mauro Carvalho Chehab

media: vim2m: add vertical linear scaler

2019-03-01T16:16:21+00:00

When resolutions are different, the expected behavior is to
scale the image. Implement a vertical scaler as the first step.

Signed-off-by: Mauro Carvalho Chehab

media: vim2m: better handle cap/out buffers with different sizes

2019-03-01T16:12:23+00:00

The vim2m driver doesn't enforce that the capture and output
buffers would have the same size. Do the right thing if the
buffers are different, zeroing the buffer before writing,
ensuring that lines will be aligned and it won't write past
the buffer area.

This is a temporary fix.

A proper fix is to either implement a simple scaler at vim2m,
or to better define the behaviour of M2M transform drivers
at V4L2 API with regards to its capability of scaling the
image or not.

In any case, such changes would deserve a separate patch
anyway, as it would imply on some behavoral change.

Also, as we have an actual bug of writing data at wrong
places, let's fix this here, and add a mental note that
we need to properly address it.

Signed-off-by: Mauro Carvalho Chehab

media: vim2m: use different framesizes for bayer formats

2019-03-01T16:06:49+00:00

The only real restriction at vim2m is that width should be
multiple of two, as the copy routine always copy two pixels
each time.

However, Bayer formats are defined as having a 2x2 matrix.
So, odd vertical numbers would cause color distortions at the
last line. So, it makes sense to use step 2 for vertical alignment
on Bayer.

With this patch, the reported formats for video capture will
be:

	[0]: 'RGBP' (16-bit RGB 5-6-5)
		Size: Stepwise 32x32 - 640x480 with step 2/1
	[1]: 'RGBR' (16-bit RGB 5-6-5 BE)
		Size: Stepwise 32x32 - 640x480 with step 2/1
	[2]: 'RGB3' (24-bit RGB 8-8-8)
		Size: Stepwise 32x32 - 640x480 with step 2/1
	[3]: 'BGR3' (24-bit BGR 8-8-8)
		Size: Stepwise 32x32 - 640x480 with step 2/1
	[4]: 'YUYV' (YUYV 4:2:2)
		Size: Stepwise 32x32 - 640x480 with step 2/1
	[5]: 'BA81' (8-bit Bayer BGBG/GRGR)
		Size: Stepwise 32x32 - 640x480 with step 2/2
	[6]: 'GBRG' (8-bit Bayer GBGB/RGRG)
		Size: Stepwise 32x32 - 640x480 with step 2/2
	[7]: 'GRBG' (8-bit Bayer GRGR/BGBG)
		Size: Stepwise 32x32 - 640x480 with step 2/2
	[8]: 'RGGB' (8-bit Bayer RGRG/GBGB)
		Size: Stepwise 32x32 - 640x480 with step 2/2

Signed-off-by: Mauro Carvalho Chehab

media: vim2m: add support for VIDIOC_ENUM_FRAMESIZES

2019-03-01T16:05:23+00:00

As we do alignments for width, expose it via V4L2 API.

Signed-off-by: Mauro Carvalho Chehab