media: rcar-vin: Enable YDS bit depending on bus_width and data_shift

Enable YDS bit if bus_width and data_shift is set to 8 in parallel mode
for MEDIA_BUS_FMT_UYVY8_2X8 format.

Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
Reviewed-by: Biju Das <biju.das.jz@bp.renesas.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

media: rcar-vin: Enable support for R8A774E1

Add the SoC specific information for RZ/G2H (R8A774E1) SoC. Also add
the routing information between CSI2 and VIN (which is similar to
R-Car H3 except it lacks CSI41).

Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
Reviewed-by: Marian-Cristian Rotariu <marian-cristian.rotariu.rb@bp.renesas.com>
Reviewed-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

media: rcar-csi2: Enable support for R8A774E1

Add the MIPI CSI-2 driver support for RZ/G2H (R8A774E1) SoC.
The CSI-2 module of RZ/G2H is similar to R-Car H3.

Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
Reviewed-by: Marian-Cristian Rotariu <marian-cristian.rotariu.rb@bp.renesas.com>
Reviewed-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

media: dt-bindings: media: renesas,vin: Add R8A774E1 support

Document support for the VIN module in the Renesas RZ/G2H (R8A774E1) SoC.

Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
Reviewed-by: Marian-Cristian Rotariu <marian-cristian.rotariu.rb@bp.renesas.com>
Reviewed-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se>
Acked-by: Rob Herring <robh@kernel.org>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

media: dt-bindings: media: renesas,csi2: Add R8A774E1 support

Add the compatible string for RZ/G2H (R8A774E1) to the list of supported
SoCs.

Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
Reviewed-by: Marian-Cristian Rotariu <marian-cristian.rotariu.rb@bp.renesas.com>
Reviewed-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se>
Acked-by: Rob Herring <robh@kernel.org>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

media: media/pci: prevent memory leak in bttv_probe

In bttv_probe if some functions such as pci_enable_device,
pci_set_dma_mask and request_mem_region fails the allocated
 memory for btv should be released.

Signed-off-by: Xiaolong Huang <butterflyhuangxx@gmail.com>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

media: saa7134: use generic power management

With the support of generic PM callbacks, drivers no longer need to use
legacy .suspend() and .resume() in which they had to maintain PCI states
changes and device's power state themselves. The required operations are
done by PCI core.

Compile-tested only.

Signed-off-by: Vaibhav Gupta <vaibhavgupta40@gmail.com>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

media: rcar-vin: Kconfig: Update help description for VIDEO_RCAR_VIN config

The rcar-vin driver also supports RZ/G{1,2} SoC's, update the description
to reflect this.

Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
Reviewed-by: Chris Paterson <Chris.Paterson2@renesas.com>
Reviewed-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

media: rcar-vin: Kconfig: Update help description for VIDEO_RCAR_CSI2 config

The rcar-csi2 driver also supports RZ/G2 SoC's, update the description
to reflect this.

Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
Reviewed-by: Chris Paterson <Chris.Paterson2@renesas.com>
Reviewed-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

media: rcar-fcp: Update description for VIDEO_RENESAS_FCP Kconfig entry

The rcar-fcp driver is also used on Renesas RZ/G2 SoCs. Update the
Kconfig entry description to reflect this.

[hverkuil: incorporated Laurent's suggestions for subject and commit log]

Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
Reviewed-by: Chris Paterson <Chris.Paterson2@renesas.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

media: dt-bindings: media: renesas,vin: Add device tree support for r8a7742

Add compatible string for r8a7742. No driver change is needed as
"renesas,rcar-gen2-vin" will activate the right code.

Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
Reviewed-by: Biju Das <biju.das.jz@bp.renesas.com>
Acked-by: Rob Herring <robh@kernel.org>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

media: videobuf2: use sgtable-based scatterlist wrappers

Use recently introduced common wrappers operating directly on the struct
sg_table objects and scatterlist page iterators to make the code a bit
more compact, robust, easier to follow and copy/paste safe.

No functional change, because the code already properly did all the
scatterlist related calls.

Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
Reviewed-by: Robin Murphy <robin.murphy@arm.com>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

media: pci: fix common ALSA DMA-mapping related codes

The Documentation/DMA-API-HOWTO.txt states that dma_map_sg returns the
numer of the created entries in the DMA address space. However the
subsequent calls to dma_sync_sg_for_{device,cpu} and dma_unmap_sg must be
called with the original number of entries passed to dma_map_sg. The
sg_table->nents in turn holds the result of the dma_map_sg call as stated
in include/linux/scatterlist.h. Adapt the code to obey those rules.

While touching this code, update it to use the modern DMA_FROM_DEVICE
definitions.

Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

media: marvell-ccic: mmp: mark PM functions as __maybe_unused

The suspend/resume functions have no callers depending on
configuration, so they must be marked __maybe_unused to
avoid these harmless warnings:

drivers/media/platform/marvell-ccic/mmp-driver.c:347:12: warning:
 'mmpcam_resume' defined but not used [-Wunused-function]
  347 | static int mmpcam_resume(struct device *dev)
      |            ^~~~~~~~~~~~~
drivers/media/platform/marvell-ccic/mmp-driver.c:338:12: warning:
 'mmpcam_suspend' defined but not used [-Wunused-function]
  338 | static int mmpcam_suspend(struct device *dev)
      |            ^~~~~~~~~~~~~~

Fixes: 55cd34524aa3 ("media: marvell-ccic: add support for runtime PM")
Reported-by: Hulk Robot <hulkci@huawei.com>
Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

media: MAINTAINERS: media: cec: fix files location

Files have moved, fixes their paths.

Fixes: 4be5e8648b0c ("media: move CEC platform drivers to a separate directory")
Signed-off-by: Corentin Labbe <clabbe@baylibre.com>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

media: tc358743: cleanup tc358743_cec_isr

tc358743_cec_isr is misnammed, it is not the main isr.
So rename it to be consistent with its siblings,
tc358743_cec_handler.

It also does not check if its input parameter 'handled' is
is non NULL like its siblings, so add a check.

Fixes: a0ec8d1dc42e ("media: tc358743: add CEC support")
Signed-off-by: Tom Rix <trix@redhat.com>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

media: cec-adap.c: add 'unregistered' checks

Make the code a bit more robust by checking if the adapter has
been unregistered at the start of cec_transmit_msg_fh() and
cec_received_msg_ts(). If it is unregistered, then just return.

Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

media: cec-core.c: stop kthread_config before kthread

The kthread_config relies on the main kthread (message processing
loop) to be present, so stop kthread_config before kthread.

It's unlikely to be a problem (and I've never seen any issues), but
if nothing else it makes sense to stop the threads in this order.

Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

media: tegra-video: Fix compilation warning of unused variable

vi_pattern_strings is used only when CONFIG_VIDEO_TEGRA_TPG is
enabled and V4L2 control operations currently are used only in
TPG mode.

So when tegra-video is build for non TPG, warnings of unused
variable is reported for v4l2 control operation variable.

This patch fixes it.

Reported-by: kernel test robot <lkp@intel.com>
Signed-off-by: Sowjanya Komatineni <skomatineni@nvidia.com>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

media: tc358743: initialize variable

clang static analysis flags this error

tc358743.c:1468:9: warning: Branch condition evaluates
  to a garbage value
        return handled ? IRQ_HANDLED : IRQ_NONE;
               ^~~~~~~
handled should be initialized to false.

Fixes: d747b806abf4 ("[media] tc358743: add direct interrupt handling")
Signed-off-by: Tom Rix <trix@redhat.com>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

media: mtk-mdp: Fix Null pointer dereference when calling list_add

In list_add, the first variable is the new node and the second
is the list head. The function is called with a wrong order causing
NULL dereference:

[   15.527030] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000008
[   15.542317] Mem abort info:
[   15.545152]   ESR = 0x96000044
[   15.548248]   EC = 0x25: DABT (current EL), IL = 32 bits
[   15.553624]   SET = 0, FnV = 0
[   15.556715]   EA = 0, S1PTW = 0
[   15.559892] Data abort info:
[   15.562799]   ISV = 0, ISS = 0x00000044
[   15.566678]   CM = 0, WnR = 1
[   15.569683] user pgtable: 4k pages, 48-bit VAs, pgdp=00000001373f0000
[   15.576196] [0000000000000008] pgd=0000000000000000, p4d=0000000000000000
[   15.583101] Internal error: Oops: 96000044 [#1] PREEMPT SMP
[   15.588747] Modules linked in: mtk_mdp(+) cfg80211 v4l2_mem2mem videobuf2_vmalloc videobuf2_dma_contig videobuf2_memops videobuf2_v4l2 videobuf2_common vide
odev mt8173_rt5650 smsc95xx usbnet ecdh_generic ecc snd_soc_rt5645 mc mt8173_afe_pcm rfkill cros_ec_sensors snd_soc_mtk_common elan_i2c crct10dif_ce cros_ec_se
nsors_core snd_soc_rl6231 elants_i2c industrialio_triggered_buffer kfifo_buf mtk_vpu cros_ec_chardev cros_usbpd_charger cros_usbpd_logger sbs_battery display_c
onnector pwm_bl ip_tables x_tables ipv6
[   15.634295] CPU: 0 PID: 188 Comm: systemd-udevd Not tainted 5.9.0-rc2+ #69
[   15.641242] Hardware name: Google Elm (DT)
[   15.645381] pstate: 20000005 (nzCv daif -PAN -UAO BTYPE=--)
[   15.651022] pc : mtk_mdp_probe+0x134/0x3a8 [mtk_mdp]
[   15.656041] lr : mtk_mdp_probe+0x128/0x3a8 [mtk_mdp]
[   15.661055] sp : ffff80001255b910
[   15.669548] x29: ffff80001255b910 x28: 0000000000000000
[   15.679973] x27: ffff800009089bf8 x26: ffff0000fafde800
[   15.690347] x25: ffff0000ff7d2768 x24: ffff800009089010
[   15.700670] x23: ffff0000f01a7cd8 x22: ffff0000fafde810
[   15.710940] x21: ffff0000f01a7c80 x20: ffff0000f0c3c180
[   15.721148] x19: ffff0000ff7f1618 x18: 0000000000000010
[   15.731289] x17: 0000000000000000 x16: 0000000000000000
[   15.741375] x15: 0000000000aaaaaa x14: 0000000000000020
[   15.751399] x13: 00000000ffffffff x12: 0000000000000020
[   15.761363] x11: 0000000000000028 x10: 0101010101010101
[   15.771279] x9 : 0000000000000004 x8 : 7f7f7f7f7f7f7f7f
[   15.781148] x7 : 646bff6171606b2b x6 : 0000000000806d65
[   15.790981] x5 : ffff0000ff7f8360 x4 : 0000000000000000
[   15.800767] x3 : 0000000000000004 x2 : 0000000000000001
[   15.810501] x1 : 0000000000000005 x0 : 0000000000000000
[   15.820171] Call trace:
[   15.826944]  mtk_mdp_probe+0x134/0x3a8 [mtk_mdp]
[   15.835908]  platform_drv_probe+0x54/0xa8
[   15.844247]  really_probe+0xe4/0x3b0
[   15.852104]  driver_probe_device+0x58/0xb8
[   15.860457]  device_driver_attach+0x74/0x80
[   15.868854]  __driver_attach+0x58/0xe0
[   15.876770]  bus_for_each_dev+0x70/0xc0
[   15.884726]  driver_attach+0x24/0x30
[   15.892374]  bus_add_driver+0x14c/0x1f0
[   15.900295]  driver_register+0x64/0x120
[   15.908168]  __platform_driver_register+0x48/0x58
[   15.916864]  mtk_mdp_driver_init+0x20/0x1000 [mtk_mdp]
[   15.925943]  do_one_initcall+0x54/0x1b4
[   15.933662]  do_init_module+0x54/0x200
[   15.941246]  load_module+0x1cf8/0x22d0
[   15.948798]  __do_sys_finit_module+0xd8/0xf0
[   15.956829]  __arm64_sys_finit_module+0x20/0x30
[   15.965082]  el0_svc_common.constprop.0+0x6c/0x168
[   15.973527]  do_el0_svc+0x24/0x90
[   15.980403]  el0_sync_handler+0x90/0x198
[   15.987867]  el0_sync+0x158/0x180
[   15.994653] Code: 9400014b 2a0003fc 35000920 f9400280 (f9000417)
[   16.004299] ---[ end trace 76fee0203f9898e5 ]---

Fixes: 86698b9505bbc ("media: mtk-mdp: convert mtk_mdp_dev.comp array to list")
Signed-off-by: Dafna Hirschfeld <dafna.hirschfeld@collabora.com>
Reviewed-by: Matthias Brugger <matthias.bgg@gmail.com>
Tested-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

media: staging: rkisp1: rsz: set flags to 0 in enum_mbus_code cb

The resizer calls the enum_mbus_code cb on the source pad of
the isp entity since they support the same formats.
The only difference is that the isp entity allows setting the
quantization and sets the flag V4L2_SUBDEV_MBUS_CODE_CSC_QUANTIZATION.
The resizer should therefore set the flags to 0.

Signed-off-by: Dafna Hirschfeld <dafna.hirschfeld@collabora.com>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

media: staging: rkisp1: allow quantization setting by userspace on the isp source pad

The isp entity has hardware support to force full range quantization
for YUV formats. Use the subdev CSC API to allow userspace to set the
quantization for YUV formats on the isp entity.

- The flag V4L2_SUBDEV_MBUS_CODE_CSC_QUANTIZATION is set for
YUV formats during enumeration of the isp formats on the source pad.
- The full quantization is set on YUV formats if userspace asks it
on the isp entity using the flag V4L2_MBUS_FRAMEFMT_SET_CSC.

On the capture and the resizer, the quantization is read-only
and always set to the default quantization.

Signed-off-by: Dafna Hirschfeld <dafna.hirschfeld@collabora.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Acked-by: Helen Koike <helen.koike@collabora.com>
Reviewed-by: Tomasz Figa <tfiga@chromium.org>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

media: v4l2: extend the CSC API to subdevice.

This patch extends the CSC API in video devices to be supported
also on sub-devices. The flag V4L2_MBUS_FRAMEFMT_SET_CSC set by
the application when calling VIDIOC_SUBDEV_S_FMT ioctl.
The flags:

V4L2_SUBDEV_MBUS_CODE_CSC_COLORSPACE,
V4L2_SUBDEV_MBUS_CODE_CSC_XFER_FUNC,
V4L2_SUBDEV_MBUS_CODE_CSC_YCBCR_ENC/V4L2_SUBDEV_MBUS_CODE_CSC_HSV_ENC
V4L2_SUBDEV_MBUS_CODE_CSC_QUANTIZATION

are set by the driver in the VIDIOC_SUBDEV_ENUM_MBUS_CODE ioctl.

New 'flags' fields were added to the structs
v4l2_subdev_mbus_code_enum, v4l2_mbus_framefmt which are borrowed
from the 'reserved' field

The patch also replaces the 'ycbcr_enc' field in
'struct v4l2_mbus_framefmt' with a union that includes 'hsv_enc'

Signed-off-by: Dafna Hirschfeld <dafna.hirschfeld@collabora.com>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

media: vivid: Add support to the CSC API

The CSC API (Colorspace conversion) allows userspace to try
to configure the colorspace, transfer function, Y'CbCr/HSV encoding
and the quantization for capture devices. This patch adds support
to the CSC API in vivid.
Using the CSC API, userspace is allowed to do the following:

- Set the colorspace.
- Set the xfer_func.
- Set the ycbcr_enc function for YUV formats.
- Set the hsv_enc function for HSV formats
- Set the quantization for YUV and RGB formats.

Signed-off-by: Dafna Hirschfeld <dafna.hirschfeld@collabora.com>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

media: v4l2: add support for colorspace conversion API (CSC) for video capture

For video capture it is the driver that reports the colorspace,
transfer function, Y'CbCr/HSV encoding and quantization range
used by the video, and there is no way to request something
different, even though many HDTV receivers have some sort of
colorspace conversion capabilities.

For output video this feature already exists since the application
specifies this information for the video format it will send out, and
the transmitter will enable any available CSC if a format conversion has
to be performed in order to match the capabilities of the sink.

For video capture we propose adding new v4l2_pix_format flag:
V4L2_PIX_FMT_FLAG_SET_CSC. The flag is set by the application,
the driver will interpret the colorspace, xfer_func, ycbcr_enc/hsv_enc
and quantization fields as the requested colorspace information and will
attempt to do the conversion it supports.

Drivers set the flags
V4L2_FMT_FLAG_CSC_COLORSPACE,
V4L2_FMT_FLAG_CSC_XFER_FUNC,
V4L2_FMT_FLAG_CSC_YCBCR_ENC/V4L2_FMT_FLAG_CSC_HSV_ENC,
V4L2_FMT_FLAG_CSC_QUANTIZATION,
in the flags field of the struct v4l2_fmtdesc during enumeration to
indicate that they support colorspace conversion for the respective field.

Drivers do not have to actually look at the flags. If the flags are not
set, then the fields 'colorspace', 'xfer_func', 'ycbcr_enc/hsv_enc',
and 'quantization' are set to the default values by the core, i.e. just
pass on the received format without conversion.

Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
Signed-off-by: Dafna Hirschfeld <dafna.hirschfeld@collabora.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

media: v4l2-mem2mem: simplify poll logic

Factorize redundant checks into a single code block, remove unneeded
checks (a buffer in done_list is necessarily in the DONE or ERROR
state), and we end up with a much simpler version of this function.

Signed-off-by: Alexandre Courbot <gnurou@gmail.com>
Reviewed-by: Ezequiel Garcia <ezequiel@collabora.com>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

media: v4l2-mem2mem: always consider OUTPUT queue during poll

If poll() is called on a m2m device with the EPOLLOUT event after the
last buffer of the CAPTURE queue is dequeued, any buffer available on
OUTPUT queue will never be signaled because v4l2_m2m_poll_for_data()
starts by checking whether dst_q->last_buffer_dequeued is set and
returns EPOLLIN in this case, without looking at the state of the OUTPUT
queue.

Fix this by not early returning so we keep checking the state of the
OUTPUT queue afterwards.

Signed-off-by: Alexandre Courbot <gnurou@gmail.com>
Reviewed-by: Ezequiel Garcia <ezequiel@collabora.com>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

media: mx2_emmaprp: Fix memleak in emmaprp_probe

When platform_get_irq() fails, we should release
vfd and unregister pcdev->v4l2_dev just like the
subsequent error paths.

Fixes: d4e192cc44914 ("media: mx2_emmaprp: Check for platform_get_irq() error")
Signed-off-by: Dinghao Liu <dinghao.liu@zju.edu.cn>
Reviewed-by: Fabio Estevam <festevam@gmail.com>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

media: usb: uvc: no need to check return value of debugfs_create functions

When calling debugfs functions, there is no need to ever check the
return value.  The function can work or not, but the code logic should
never do something different based on this.

Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

media: mtk-vcodec: make IRQs disabled upon request

The driver requests IRQs to disable them immediately. This is
potentially racy, fix this by requesting the IRQs to come disabled
instead using the IRQ_NOAUTOEN flag of irq_set_status_flags().

Reported-by: Ezequiel Garcia <ezequiel@collabora.com>
Signed-off-by: Alexandre Courbot <acourbot@chromium.org>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

media: mtk-vcodec: venc: fix invalid time per frame in S_PARM

v4l2-compliance expects the driver to adjust the time per frame if it is
invalid (numerator or denominator set to 0). Adjust it to the default
value in these cases.

Signed-off-by: Alexandre Courbot <acourbot@chromium.org>
Acked-by: Tiffany Lin <tiffany.lin@mediatek.com>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

media: mtk-vcodec: venc: set default time per frame

The time per frame was left initialized to 0/0, which make the driver
fail v4l2-compliance, and also leaves it potentially exposed to doing a
division by zero.

Signed-off-by: Alexandre Courbot <acourbot@chromium.org>
Acked-by: Tiffany Lin <tiffany.lin@mediatek.com>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

media: mtk-vcodec: venc: support ENUM_FRAMESIZES on OUTPUT formats

v4l2-compliance requires ENUM_FRAMESIZES to support OUTPUT formats.
Reuse mtk_venc_find_format() to make sure both queues are considered
when serving an ENUM_FRAMESIZES.

[hverkuil: fixed some checkpatch alignment warnings]

Signed-off-by: Alexandre Courbot <acourbot@chromium.org>
Acked-by: Tiffany Lin <tiffany.lin@mediatek.com>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

media: mtk-vcodec: venc: use platform data for ENUM_FRAMESIZES

vidioc_enum_framesizes() assumes that all encoders support H.264 and VP8,
which is not necessarily true and requires to duplicate information about
the supported codecs which is already stored in the platform data.

Fix this by referring to the platform data to find out whether a given
format is supported. Since the supported sizes are all the same
regardless of the format, we can then return a copy of a static value if
the format is supported.

Signed-off-by: Alexandre Courbot <acourbot@chromium.org>
Acked-by: Tiffany Lin <tiffany.lin@mediatek.com>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

media: mtk-vcodec: venc: set OUTPUT buffers field to V4L2_FIELD_NONE

A default value of 0 means V4L2_FIELD_ANY, which is not correct.
Reported by v4l2-compliance.

Signed-off-by: Alexandre Courbot <acourbot@chromium.org>
Acked-by: Tiffany Lin <tiffany.lin@mediatek.com>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

media: mtk-vcodec: venc support MIN_OUTPUT_BUFFERS control

This control is required by v4l2-compliance for encoders. A value of 1
should be suitable for all scenarios.

Signed-off-by: Alexandre Courbot <acourbot@chromium.org>
Acked-by: Tiffany Lin <tiffany.lin@mediatek.com>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

media: Revert "media: mtk-vcodec: Remove extra area allocation in an input buffer on encoding"

This reverts commit 81735ecb62f882853a37a8c157407ec4aed44fd0.

The hardware needs data to follow the previous alignment, so this extra
space was not superfluous after all. Besides, this also made
v4l2-compliance's G_FMT and S_FMT tests regress.

Signed-off-by: Alexandre Courbot <acourbot@chromium.org>
Acked-by: Tiffany Lin <tiffany.lin@mediatek.com>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

media: mtk-vcodec: add support for MT8183 encoder

Now that all the supporting blocks are present, enable encoder for
MT8183.

[acourbot: refactor, cleanup and split]

Signed-off-by: Yunfei Dong <yunfei.dong@mediatek.com>
Co-developed-by: Alexandre Courbot <acourbot@chromium.org>
Signed-off-by: Alexandre Courbot <acourbot@chromium.org>
Acked-by: Tiffany Lin <tiffany.lin@mediatek.com>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

media: dt-bindings: media: document mediatek,mt8183-vcodec-enc

MT8183's encoder is similar to MT8173's.

Signed-off-by: Alexandre Courbot <acourbot@chromium.org>
Acked-by: Rob Herring <robh@kernel.org>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

media: mtk-vcodec: venc: specify supported formats per-chip

Different chips have different supported formats. Move the list of
supported formats to the platform data, and split the output and capture
formats into two lists to make it easier to find the default format for
each queue.

[hverkuil: fixed some checkpatch alignment warnings]

Signed-off-by: Alexandre Courbot <acourbot@chromium.org>
Acked-by: Tiffany Lin <tiffany.lin@mediatek.com>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

media: mtk-vcodec: venc: specify bitrate range per-chip

Different chips have different supported bitrate ranges. Move the min
and max supported bitrates to the platform data.

Signed-off-by: Alexandre Courbot <acourbot@chromium.org>
Acked-by: Tiffany Lin <tiffany.lin@mediatek.com>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

media: mtk-vcodec: venc: handle firmware version field

Firmwares for encoders newer than MT8173 will include an ABI version
number in their initialization ack message. Add the capacity to manage
it and make initialization fail if the firmware ABI is of a version that
we don't support.

For MT8173, this ABI version field is reserved and thus undefined ; thus
ignore it on this chip. There should only be one firmware version available
for it anyway.

Signed-off-by: Alexandre Courbot <acourbot@chromium.org>
Acked-by: Tiffany Lin <tiffany.lin@mediatek.com>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

media: mtk-vcodec: venc: support SCP firmware

Support the new extended firmware used by MT8183's encoder.

[acourbot: refactor, cleanup and split]
[hverkuil: fixed some checkpatch alignment warnings]

Signed-off-by: Yunfei Dong <yunfei.dong@mediatek.com>
Co-developed-by: Alexandre Courbot <acourbot@chromium.org>
Signed-off-by: Alexandre Courbot <acourbot@chromium.org>
Acked-by: Tiffany Lin <tiffany.lin@mediatek.com>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

media: mtk-vcodec: add SCP firmware ops

Add support for communicating with the SCP firmware, which will be used
by MT8183.

[acourbot: refactor, cleanup and split]
[hverkuil: fixed some checkpatch alignment warnings]

Signed-off-by: Yunfei Dong <yunfei.dong@mediatek.com>
Co-developed-by: Alexandre Courbot <acourbot@chromium.org>
Signed-off-by: Alexandre Courbot <acourbot@chromium.org>
Acked-by: Tiffany Lin <tiffany.lin@mediatek.com>
Reported-by: kernel test robot <lkp@intel.com>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

media: dt-bindings: media: mtk-vcodec: document SCP node

The mediatek codecs can use either the VPU or the SCP as their interface
to firmware. Reflect this in the DT bindings.

Signed-off-by: Alexandre Courbot <acourbot@chromium.org>
Acked-by: Tiffany Lin <tiffany.lin@mediatek.com>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

media: mtk-vcodec: abstract firmware interface

MT8183's codec firmware is run by a different remote processor from
MT8173. While the firmware interface is basically the same, the way to
invoke it differs. Abstract all firmware calls under a layer that will
allow us to handle both firmware types transparently.

[acourbot: refactor, cleanup and split]
[pihsun: fix error path and add mtk_vcodec_fw_release]
[hverkuil: fixed some checkpatch alignment warnings]
[hverkuil: fixed merge conflicts]

Signed-off-by: Yunfei Dong <yunfei.dong@mediatek.com>
Co-developed-by: Alexandre Courbot <acourbot@chromium.org>
Signed-off-by: Alexandre Courbot <acourbot@chromium.org>
Signed-off-by: Pi-Hsun Shih <pihsun@chromium.org>
Reviewed-by: Tiffany Lin <tiffany.lin@mediatek.com>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

remoteproc: scp: add COMPILE_TEST dependency

This will improve this driver's build coverage.

Reported-by: Ezequiel Garcia <ezequiel@collabora.com>
Signed-off-by: Alexandre Courbot <acourbot@chromium.org>
Acked-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

media: atomisp: cleanup __printf() atributes on printk messages

There are still some warnings produced by -Wsuggest-attribute=format,
like this one:

drivers/staging/media/atomisp/pci/runtime/debug/src/ia_css_debug.c: In function ‘dtrace_dot’:
drivers/staging/media/atomisp/pci/runtime/debug/src/ia_css_debug.c:2466:2: warning: function ‘dtrace_dot’ might be a candidate for ‘gnu_printf’ format attribute [-Wsuggest-attribute=format]
 2466 |  ia_css_debug_vdtrace(IA_CSS_DEBUG_INFO, fmt, ap);
      |  ^~~~~~~~~~~~~~~~~~~~

Also, on some places, is is using __atribute, while on others it
is using the __printf() macro.

Uniform those to always use the __printf() macro, placing it
before the function, and fix the logic in order to cleanup
all such warnings.

Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

media: atomisp: fix gcc warnings

Depending on the gcc version, after changeset
72a9ff3bf7fb ("media: atomisp: get rid of -Wsuggest-attribute=format warnings"),
we're now getting two warnings, which are breaking the Jenkins
CI instance at https://builder.linuxtv.org:

../drivers/staging/media/atomisp/pci/atomisp_compat_css20.c: In function ‘__set_css_print_env’:
../drivers/staging/media/atomisp/pci/atomisp_compat_css20.c:860:50: error: assignment to ‘int (*)(const char *, char *)’ from incompatible pointer type ‘int (__attribute__((regparm(0))) *)(const char *, char *)’ [-Werror=incompatible-pointer-types]
   isp->css_env.isp_css_env.print_env.debug_print = vprintk;
                                                  ^
../drivers/staging/media/atomisp/pci/atomisp_compat_css20.c: In function ‘atomisp_css_load_firmware’:
../drivers/staging/media/atomisp/pci/atomisp_compat_css20.c:893:49: error: assignment to ‘int (*)(const char *, char *)’ from incompatible pointer type ‘int (__attribute__((regparm(0))) *)(const char *, char *)’ [-Werror=incompatible-pointer-types]
  isp->css_env.isp_css_env.print_env.error_print = vprintk;
                                                 ^
cc1: some warnings being treated as errors

So, we need to partially revert the patch.

Fixes: 72a9ff3bf7fb ("media: atomisp: get rid of -Wsuggest-attribute=format warnings")
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

media: ipu3-imgu: Fixed some coding style issues in ipu3-css.c

Improved readability by fixing some issues related to maximum line length.

Signed-off-by: Felix Winkler <fxmw.tnt@gmail.com>
Signed-off-by: Niklas Witzel <nik.witzel@horsepower-hannover.de>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

media: atomisp/pci/atomisp_ioctl.c: strlcpy -> strscpy

strscpy is preferred over strlcpy and is the standard in the media subsystem.

Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

media: atomisp:pci/runtime/queue: modify the return error value

modify the return error value is -EDOM

Fixes: 2cac05dee6e30("drm/amd/powerplay: add the hw manager for vega12 (v4)")
Cc: Evan Quan <evan.quan@amd.com>
Signed-off-by: Xiaoliang Pang <dawning.pang@gmail.com>
Reviewed-by: Tianjia Zhang <tianjia.zhang@linux.alibaba.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

media: staging: atomisp: Remove unnecessary 'fallthrough'

commit df561f6688fe ("treewide: Use fallthrough pseudo-keyword") from
Gustavo A. R. Silva replaced and standardized /* fallthrough */ comments
with 'fallthrough' pseudo-keyword.

However, in one of the switch-case statements, Coverity Static Analyzer
throws a warning that 'fallthrough' is unreachable due to the adjacent
'return false' statement. (Coverity ID CID 1466511)

In order to fix the unreachable code warning, remove unnecessary
fallthrough keyword.

Signed-off-by: Cengiz Can <cengiz@kernel.wtf>
Reviewed-by: Gustavo A. R. Silva <gustavoars@kernel.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

media: staging: media: atomisp: Fix bool-related style issues

Address the following issues:
 * unnecessary comparison to true/false
 * use of 0/1 instead of bool values
 * unnecessary conversion to bool

These were fixed using the following Coccinelle scripts:
 * scripts/coccinelle/misc/bool{init,conv,return}.cocci

Build-tested with allmodconfig.

Signed-off-by: Alex Dewar <alex.dewar90@gmail.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

media: staging: media: atomisp: Don't do unnecessary zeroing of memory

In a few places in pci/sh_css_params.c, memset is used to zero memory
immediately before it is freed. As none of these structs appear to
contain sensitive information, just remove the calls to memset.

Suggested-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Alex Dewar <alex.dewar90@gmail.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

media: vidtv: remove an impossible condition

As warned by smatch:

drivers/media/test-drivers/vidtv/vidtv_psi.c:93 vidtv_psi_update_version_num() warn: impossible condition '(h->version > 32) => (0-31 > 32)'

h_version is declared as:

u8  version:5;

Meaning that its value ranges from 0 to 31. Incrementing 31 on such
data will overflow to zero, as expected.

So, just drop the uneeded overflow check.

While here, use "foo++" instead of "++foo", as this is a much
more common pattern.

Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

media: vidtv: cleanup the logic which estimates buffer size

There's no need to use u64 over there. In a matter of fact,
the div is not even needed, as it is multiplying by 1000 and
dividing by 1000.

So, simplify the logic.

While here, constrain the buffer size to a certain range
(between the current value and 10 times it)

Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

media: vidtv: fix build on 32bit architectures

Fix the following error for builds on 32bit architectures:

ERROR: modpost: "__udivdi3"
[drivers/media/test-drivers/vidtv/dvb-vidtv-bridge.ko] undefined!

Which is due to 64bit divisions that did not go through the helpers
in linux/math64.h

As vidtv_mux_check_mux_rate was not operational in its current form,
drop the entire function while it is not fixed properly.

For now, call vidtv_mux_pad_with_nulls with a constant number of packets
to avoid warnings due to unused functions when building this driver.

The 64bit division used in the s302m is not needed, remove them and use
a fixed number of frames and a constant PTS increment instead.

Fixes: f90cf6079bf67988 ("media: vidtv: add a bridge driver")
Signed-off-by: Daniel W. S. Almeida <dwlsalmeida@gmail.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

media: vidtv: Add a music instead of playing a single tone

Keep playing a single tone is not too nice, and prevents
checking some weird things.

So, instead, implement a simple tone generator, changing
the code to play a public domain song (5th Symphony of
Beethoven), using sinusoidal waves.

Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

media: vidtv: get rid of its own sinusoidal waveform

Instead, use the code from linux/fixp-arith.h.

Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

media: vidtv: add a poor guy's simulation to preBER stats

A typical digital TV stream has errors that are corrected
by Viterbi. While the error rate after Viterbi is usually
zero, with good signals, there are some chances of getting
random errors before that, which are auto-corrected by
the error code algorithm.

Add a poor guy's implementation that would show some
noise at the pre-BER part of the demod.

Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

media: vidtv.rst: update it to better describe the frequencies

The virtual driver has now a minimal set of frequencies for a
single transponder to be found by each DVB standard.

Document it, and update related information about the
simulated LNBf.

Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

media: vidtv: fix DVB-S/S2 tuning logic

Satellite setups are different than terrestrial and cable ones,
as there is a device coupled at the antenna, called LNBf, which
converts the frequency from a GHz range at C-Band or Ku-Band
into an intermediate frequency at S-Band (ranging up to ~2GHz).

There are several different models of LNBf, with different
IF conversions, but the most common nowadays is called
Universal LNBf. Those got their frequency ranges extended in the
past, when Astra 19.2E sattellite was launched.

The universal LNBf has two local oscilators:

- 9.75 GHz
- 10.6 GHz

The first one is used when the frequency is between 10.7 GHz
up to 11.7 GHz. The second one is for frequencies between
11.7 GHz to 12.75 GHz.

With that, the IF signal will be at 950 MHz to 2,150 MHz range.

Add support for doing the above math, and make clear that
the frequencies expected by the driver should be at Ku-Band
range.

Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

media: vidtv: add DiSEqC dummy ops

Those are needed for real applications to work with Satellite
systems.

Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

media: vidtv: don't initialize cnr2qual var

As reported by gcc:

drivers/media/test-drivers/vidtv/vidtv_demod.c: In function 'vidtv_demod_set_frontend':
drivers/media/test-drivers/vidtv/vidtv_demod.c:265:42: warning: variable 'cnr2qual' set but not used [-Wunused-but-set-variable]
  265 |  const struct vidtv_demod_cnr_to_qual_s *cnr2qual = NULL;
      |                                          ^~~~~~~~

It turns that the var is not needed at all. So, just drop it.

Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

media: vidtv: adjust signal strength range

On real devices, signal strength is always a negative
number when represented in dBm. A more interesting
range is to use dBmV (which is what Kaffeine does,
for example). The conversion from the two units are
simple:

dBmV = dBm - 108

Usually, signal strength ranges up to 100dBmV. Adjust the
maximum value to be around 74 dBmV, when there's no
frequency shift, which represents a good signal.

With that, Kaffeine displays it a lot better.

Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

media: vidtv: increment byte and block counters

Add support for incrementing DVBv5 stats for block counters
and post/pre BER byte counts.

For now, the errors won't be incremented yet.

Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

media: vidtv: get rid of the work queue

The dvb_frontend will already call status periodically, when
a channel is tuned. So, no need to have a work queue for
such purpose.

Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

media: vidtv: add basic support for DVBv5 stats

The current stats code is broken on so many ways. It ends
reporting 0 for signal strengh, and the work queue doesn't
run. If it would run, the code would crash.

Fix such issues and add the minimum stuff for DVBv5 stats.

Right now, only strength and cnr and UCB are implemented.
pre/post BER stats will always return zero.

Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

media: vidtv: properly initialize the internal state struct

Right now, the config data passed from the bridge driver is
just ignored.

Also, let's initialize the delayed work at probing time.

Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

media: vidtv: remove a wrong endiannes check from s302m generator

The code there is already doing the right thing, as it uses
value & 0xff, value & 0xff00, which already ensures the
expected endiannes.

So, it doesn't make any sense to touch the order depending on
the CPU endiannes.

Yet, as pointed by Daniel at the mailing list:
https://lore.kernel.org/linux-media/e614351c-215c-c048-52af-7c200b164f41@xs4all.nl/T/#m8d221684a151833966359c2ed8bdce0f0ee4e5fd

The reverse code is needed by the decoder. So, keep it
no matter the endiannes.

Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

media: vidtv: add an initial channel frequency

Use 474 MHz frequency for DVB-T/DVB-C, as this is the at the
channel range that it is valid on most places for DVB-T.

In the case of DVB-S, let's add Astra 19.2E initial
frequency at the scan files as the default, e. g. 12.5515 GHz.

Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

media: vidtv: fix frequency tuning logic

Right now, there are some issues at the tuning logic:

1) the config struct is not copied at the tuner driver.
   so, it won't use any frequency table at all;
2) the code that checks for frequency shifts is called
   at set_params. So, lock_status will never be zeroed;
3) the signal strength will also report a strong
   signal, even if not tuned;
4) the logic is not excluding non-set frequencies.

Fix those issues.

Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

media: vidtv: get rid of ENDIAN_BITFIELD nonsense

The two places where ENDIAN_BITFIELD is used is for a single
8-bits integer. No need to correct endiannes on such cases.

Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

media: vidtv: get rid of some endiannes nonsense

Genmask is always highest order to low order. It doesn't make
any sense to make it depends on endiannes.

Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

media: vidtv: fix 32-bit warnings

There are several warnings produced when the driver is built
for 32-bit archs. Solve them.

Reported-by: Hans Verkuil <hverkuil@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

media: vidtv: prefer using dev_foo() instead of pr_foo()

It is better to use the higher level dev_foo() than pr_foo()
for printks.

Change them at vidtv at the more trivial places.

Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

media: vidtv: add modaliases for the bridge driver

As this virtual driver is probed manually, add modaliases
for this driver.

Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

media: venus: firmware: Set virtual address ranges

In order to boot some of the new Venus firmware versions TZ call to set
virtual address ranges is needed. Add virtual address ranges for CP and
CP_NONPIX in resource structure and use them when loading and booting
the firmware on remote processor.

Signed-off-by: Stanimir Varbanov <stanimir.varbanov@linaro.org>
Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

media: firmware: qcom_scm: Add memory protect virtual address ranges

This adds a new SCM memprotect command to set virtual address ranges.

Signed-off-by: Stanimir Varbanov <stanimir.varbanov@linaro.org>
Reviewed-by: Elliot Berman <eberman@codeaurora.org>
Acked-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

media: venus: venc: Use helper to set profile and level

We have a new helper to set profile and level use it
instead.

Signed-off-by: Stanimir Varbanov <stanimir.varbanov@linaro.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

media: venus: vdec: Use helper to get profile and level

Currently the returned profile and level is not aligned with
v4l2 ctrl id. Correct that by use the helpers which translate
the v4l2 <-> hfi mapping internally.

Signed-off-by: Stanimir Varbanov <stanimir.varbanov@linaro.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

media: venus: vdec: Set/Get VP9 profile/level

Get and set VP9 codec profile and levels.

Signed-off-by: Stanimir Varbanov <stanimir.varbanov@linaro.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

media: venus: helpers: Add a helper to map v4l2 ids to HFI ids

Introduce a helper to set and get profile and levels which
includes the translation between v4l2 ctrl ids and HFI ids.
The input arguments are always in v4l2 ids space.

Signed-off-by: Stanimir Varbanov <stanimir.varbanov@linaro.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

media: venus: hfi_helper: Add VP9 profile and levels

Add HFI defines for VP9 codec profile and levels.

Signed-off-by: Stanimir Varbanov <stanimir.varbanov@linaro.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

media: v4l2-ctrl: Add VP9 codec levels

Add menu control for VP9 codec levels. A total of 14 levels are
defined for Profile 0 (8bit) and Profile 2 (10bit). Each level
is a set of constrained bitstreams coded with targeted resolutions,
frame rates, and bitrates.

The definitions have been taken from webm project [1].

[1] https://www.webmproject.org/vp9/levels/

Signed-off-by: Stanimir Varbanov <stanimir.varbanov@linaro.org>
Reviewed-by: Nicolas Dufresne <nicolas.dufresne@collabora.com>
Reviewed-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

media: venus: core: Drop local dma_parms

Since commit 9495b7e92f71 ("driver core: platform: Initialize dma_parms
for platform devices"), struct platform_device already provides a
dma_parms structure, so we can save allocating another one.

Also the DMA segment size is simply a size, not a bitmask.

Signed-off-by: Robin Murphy <robin.murphy@arm.com>
Signed-off-by: Stanimir Varbanov <stanimir.varbanov@linaro.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

media: media/test-drivers/Kconfig: fix broken Kconfig

menuconfig DVB_TEST_DRIVERS should be added after the V4L_TEST_DRIVERS,
otherwise there are no drivers listed in these two menus.

Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Fixes: 24fb190e92e0 ("media: vidtv: implement a tuner driver")
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

media: vidtv: fix driver unbind/remove

The current remove logic is broken and causes an OOPS.

Fix it.

Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

media: Documentation: vidtv: Add ReST documentation for vidtv

Add documentation for the Virtual Digital TV driver (vidtv) in the
Restructured Text (ReST) format.

This discusses:
- What is vidtv
- Why vidtv is needed
- How to build and run vidtv
- How vidtv is structured
- How to test vidtv
- How to improve vidtv

[mchehab: fixed bad whitespaces]

Signed-off-by: Daniel W. S. Almeida <dwlsalmeida@gmail.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

media: vidtv: add a bridge driver

Digital TV devices consist of several independent hardware components
which are controlled by different drivers.
Each media device is controlled by a group of cooperating drivers with the
bridge driver as the main driver.

This patch adds a bridge driver for the Virtual Digital TV driver [vidtv].

The bridge driver binds to the other drivers, that is, vidtv_tuner and
vidtv_demod and implements the digital demux logic, providing userspace
with a MPEG Transport Stream.

The MPEG related code is split in the following way:

- vidtv_ts: code to work with MPEG TS packets, such as TS headers,
adaptation fields, PCR packets and NULL packets.

- vidtv_psi: this is the PSI generator.
PSI packets contain general information about a MPEG Transport Stream.
A PSI generator is needed so userspace apps can retrieve information
about the Transport Stream and eventually tune into a (dummy) channel.

Because the generator is implemented in a separate file, it can be
reused elsewhere in the media subsystem.

Currently vidtv supports working with 3 PSI tables:
PAT, PMT and SDT.

- vidtv_pes: implements the PES logic to convert encoder data into
MPEG TS packets. These can then be fed into a TS multiplexer and
eventually into userspace.

- vidtv_s302m: implements a S302M encoder to make it possible to
insert PCM audio data in the generated MPEG Transport Stream.

This shall enable passing an audio signal into userspace so it can be
decoded and played by media software.

- vidtv_channels: Implements a 'channel' abstraction

When vidtv boots, it will create some hardcoded channels:

Their services will be concatenated to populate the SDT.
Their programs will be concatenated to populate the PAT
For each program in the PAT, a PMT section will be created
The PMT section for a channel will be assigned its streams.
Every stream will have its corresponding encoder polled to produce TS
packets
These packets may be interleaved by the mux and then delivered to the
bridge

- vidtv_mux - Implements a MPEG TS mux, loosely based on the ffmpeg
implementation

The multiplexer is responsible for polling encoders,
interleaving packets, padding the resulting stream with NULL packets if
necessary and then delivering the resulting TS packets to the bridge
driver so it can feed the demux.

Signed-off-by: Daniel W. S. Almeida <dwlsalmeida@gmail.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

media: vidtv: implement a demodulator driver

Implement a I2C demodulator driver, simulating support for DVB-T, DVB-C
and DVB-S.

This demodulator will periodically check the signal quality against a table
and drop the TS lock if it drops below a threshold value, regaining it in
the event that the signal improves.

Signed-off-by: Daniel W. S. Almeida <dwlsalmeida@gmail.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

media: vidtv: implement a tuner driver

The virtual DVB test driver serves as a reference DVB driver and helps
validate the existing APIs in the media subsystem. It can also aid
developers working on userspace applications.

This dummy tuner should support common TV standards such as DVB-T/T2/S/S2,
ISDB-T and ATSC when completed.

Signed-off-by: Daniel W. S. Almeida <dwlsalmeida@gmail.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

media: av7110: don't do float point math

It sounds that earlier versions of GCC have troubles when
doing const math at compile time, if no typecast is used:

on i386:
ERROR: modpost: "__floatunsidf" [drivers/media/pci/ttpci/dvb-ttpci.ko] undefined!
ERROR: modpost: "__ltdf2" [drivers/media/pci/ttpci/dvb-ttpci.ko] undefined!

The warning was generated on gcc (SUSE Linux) 7.5.0.
Gcc 9.2 compiles it fine.

As an added bonus, it also fixes this objtool warning:

drivers/media/pci/ttpci/av7110_v4l.c:163:11: error: SSE register return with SSE disabled

Reported-by: Randy Dunlap <rdunlap@infradead.org>
Acked-by: Randy Dunlap <rdunlap@infradead.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

media: ov8856: Add support for 3264x2448 mode

OV8856 supports 3264x2448 @ 30 FPS, which is added
in this commit.

Signed-off-by: Robert Foss <robert.foss@linaro.org>
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

media: ov8856: Add support for 1632x1224 mode

OV8856 supports 1632x1224 @ 60 FPS, which is added
in this commit.

Signed-off-by: Robert Foss <robert.foss@linaro.org>
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

media: v4l2-fwnode: Document new usage patterns of v4l2_fwnode_endpoint_parse

Document that it is possible to provide defaults for multiple bus types to
v4l2_fwnode_endpoint_parse and v4l2_fwnode_endpoint_alloc_parse. Also
underline the fact that detecting the bus type without bus-type property
is only for the old drivers.

Also correct capitalisation of BT.656.

Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

media: v4l2-fwnode: Make bus configuration a struct

The bus specific parameters were a union. This made providing bus specific
defaults impossible as the memory used to store the defaults for multiple
different busses was the same.

Make it struct instead. It's not large so the size isn't really an issue.

Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

media: v4l2-fwnode: Make number of data lanes a character

The maximum is currently four (4). No short is needed.

Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>