We have a new helper to set profile and level use it
instead.
Signed-off-by: NStanimir Varbanov <stanimir.varbanov@linaro.org>
Signed-off-by: NMauro Carvalho Chehab <mchehab+huawei@kernel.org>

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: NStanimir Varbanov <stanimir.varbanov@linaro.org>
Signed-off-by: NMauro Carvalho Chehab <mchehab+huawei@kernel.org>

Get and set VP9 codec profile and levels.
Signed-off-by: NStanimir Varbanov <stanimir.varbanov@linaro.org>
Signed-off-by: NMauro Carvalho Chehab <mchehab+huawei@kernel.org>

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: NStanimir Varbanov <stanimir.varbanov@linaro.org>
Signed-off-by: NMauro Carvalho Chehab <mchehab+huawei@kernel.org>

Add HFI defines for VP9 codec profile and levels.
Signed-off-by: NStanimir Varbanov <stanimir.varbanov@linaro.org>
Signed-off-by: NMauro Carvalho Chehab <mchehab+huawei@kernel.org>

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: NStanimir Varbanov <stanimir.varbanov@linaro.org>
Reviewed-by: NNicolas Dufresne <nicolas.dufresne@collabora.com>
Reviewed-by: NHans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: NMauro Carvalho Chehab <mchehab+huawei@kernel.org>

Since commit 9495b7e9 ("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: NRobin Murphy <robin.murphy@arm.com>
Signed-off-by: NStanimir Varbanov <stanimir.varbanov@linaro.org>
Signed-off-by: NMauro Carvalho Chehab <mchehab+huawei@kernel.org>

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: NHans Verkuil <hverkuil-cisco@xs4all.nl>
Fixes: 24fb190e ("media: vidtv: implement a tuner driver")
Signed-off-by: NMauro Carvalho Chehab <mchehab+huawei@kernel.org>

The current remove logic is broken and causes an OOPS.

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

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: NDaniel W. S. Almeida <dwlsalmeida@gmail.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab+huawei@kernel.org>

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: NDaniel W. S. Almeida <dwlsalmeida@gmail.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab+huawei@kernel.org>

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: NDaniel W. S. Almeida <dwlsalmeida@gmail.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab+huawei@kernel.org>

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: NDaniel W. S. Almeida <dwlsalmeida@gmail.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab+huawei@kernel.org>

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: NRandy Dunlap <rdunlap@infradead.org>
Acked-by: NRandy Dunlap <rdunlap@infradead.org>
Signed-off-by: NMauro Carvalho Chehab <mchehab+huawei@kernel.org>

OV8856 supports 3264x2448 @ 30 FPS, which is added
in this commit.
Signed-off-by: NRobert Foss <robert.foss@linaro.org>
Signed-off-by: NSakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab+huawei@kernel.org>

OV8856 supports 1632x1224 @ 60 FPS, which is added
in this commit.
Signed-off-by: NRobert Foss <robert.foss@linaro.org>
Signed-off-by: NSakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab+huawei@kernel.org>

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: NSakari Ailus <sakari.ailus@linux.intel.com>
Reviewed-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab+huawei@kernel.org>

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: NSakari Ailus <sakari.ailus@linux.intel.com>
Reviewed-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab+huawei@kernel.org>

The maximum is currently four (4). No short is needed.
Signed-off-by: NSakari Ailus <sakari.ailus@linux.intel.com>
Reviewed-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab+huawei@kernel.org>

v4l2_async_notifier_add_subdev() requires the asd to be allocated
dynamically, but the max9286 driver embeds it in the max9286_source
structure. This causes memory corruption when the notifier is destroyed
at remove time with v4l2_async_notifier_cleanup().

Fix this issue by registering the asd with
v4l2_async_notifier_add_fwnode_subdev(), which allocates it dynamically
internally. A new max9286_asd structure is introduced, to store a
pointer to the corresonding max9286_source that needs to be accessed
from bound and unbind callbacks. There's no need to take an extra
explicit reference to the fwnode anymore as
v4l2_async_notifier_add_fwnode_subdev() does so internally.

While at it, use %u instead of %d to print the unsigned index in the
error message from the v4l2_async_notifier_add_fwnode_subdev() error
path.

Fixes: 66d8c9d2 ("media: i2c: Add MAX9286 driver")
Signed-off-by: NLaurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Signed-off-by: NSakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab+huawei@kernel.org>

v4l2_async_notifier_add_subdev() requires the asd to be allocated
dynamically, but the rcar-csi2 driver embeds it in the rcar_csi2
structure. This causes memory corruption when the notifier is destroyed
at remove time with v4l2_async_notifier_cleanup().

Fix this issue by registering the asd with
v4l2_async_notifier_add_fwnode_subdev(), which allocates it dynamically
internally.

Fixes: 769afd21 ("media: rcar-csi2: add Renesas R-Car MIPI CSI-2 receiver driver")
Signed-off-by: NLaurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Signed-off-by: NSakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab+huawei@kernel.org>

v4l2_async_notifier_add_subdev() requires the asd to be allocated
dynamically, but the rcar-drif driver embeds it in the
rcar_drif_graph_ep structure. This causes memory corruption when the
notifier is destroyed at remove time with v4l2_async_notifier_cleanup().

Fix this issue by registering the asd with
v4l2_async_notifier_add_fwnode_subdev(), which allocates it dynamically
internally.

Fixes: d079f94c ("media: platform: Switch to v4l2_async_notifier_add_subdev")
Signed-off-by: NLaurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Signed-off-by: NSakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab+huawei@kernel.org>

The fwnode reference corresponding to the endpoint is leaked in an error
path of the rcar_drif_parse_subdevs() function. Fix it, and reorganize
fwnode reference handling in the function to release references early,
simplifying error paths.
Signed-off-by: NLaurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Signed-off-by: NSakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab+huawei@kernel.org>

The v4l2_async_notifier_add_subdev() function requires the asd pointer
it receives to be allocated dynamically, but doesn't explicitly say so.
Only one driver out of 13 get its right (atmel-sama5d2-isc.c, but with
memory leaks in the error paths), clearly showing we have an issue.

Update the v4l2_async_notifier_add_subdev() documentation to clearly
state the allocation requirement. Whether this will be enough to avoid
new offending code isn't certain, but it's a good first step
nonetheless.

Fixes: 9ca46531 ("media: v4l: fwnode: Support generic parsing of graph endpoints in a device")
Signed-off-by: NLaurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Signed-off-by: NSakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab+huawei@kernel.org>

Fail probe if unsupported bus_type is detected.
Signed-off-by: NLad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
Reviewed-by: NJacopo Mondi <jacopo@jmondi.org>
Signed-off-by: NSakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab+huawei@kernel.org>

Enable support for BT656 mode.
Signed-off-by: NLad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
Reviewed-by: NBiju Das <biju.das.jz@bp.renesas.com>
Reviewed-by: NJacopo Mondi <jacopo@jmondi.org>
Signed-off-by: NSakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab+huawei@kernel.org>

Configure HVP lines in s_power callback instead of configuring everytime
in ov5640_set_stream_dvp().

Alongside also disable MIPI in DVP mode.
Signed-off-by: NLad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
Reviewed-by: NBiju Das <biju.das.jz@bp.renesas.com>
Tested-by: NJacopo Mondi <jacopo@jmondi.org>
Signed-off-by: NSakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab+huawei@kernel.org>

During testing this sensor on iW-RainboW-G21D-Qseven platform in 8-bit DVP
mode with rcar-vin bridge noticed the capture worked fine for the first run
(with yavta), but for subsequent runs the bridge driver waited for the
frame to be captured. Debugging further noticed the data lines were
enabled/disabled in stream on/off callback and dumping the register
contents 0x3017/0x3018 in ov5640_set_stream_dvp() reported the correct
values, but yet frame capturing failed.

To get around this issue data lines are enabled in s_power callback.
(Also the sensor remains in power down mode if not streaming so power
consumption shouldn't be affected)

Fixes: f22996db ("media: ov5640: add support of DVP parallel interface")
Signed-off-by: NLad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
Reviewed-by: NBiju Das <biju.das.jz@bp.renesas.com>
Tested-by: NJacopo Mondi <jacopo@jmondi.org>
Signed-off-by: NSakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab+huawei@kernel.org>

In preparation for adding DVP configuration in s_power callback
move mipi configuration into separate function
Signed-off-by: NLad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
Reviewed-by: NBiju Das <biju.das.jz@bp.renesas.com>
Tested-by: NJacopo Mondi <jacopo@jmondi.org>
Signed-off-by: NSakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab+huawei@kernel.org>

Keep the sensor in software power down mode and wake up only in
ov5640_set_stream_dvp() callback.
Signed-off-by: NLad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
Reviewed-by: NBiju Das <biju.das.jz@bp.renesas.com>
Tested-by: NJacopo Mondi <jacopo@jmondi.org>
Signed-off-by: NSakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab+huawei@kernel.org>

pr_info() was accidentally used to print the link frequencies whereas the
rest of the information is printed on debug level. Fix that by using
pr_debug() also for link frequencies.
Signed-off-by: NSakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab+huawei@kernel.org>

Alan Chiang's e-mail address no longer works. Remove it.
Signed-off-by: NSakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab+huawei@kernel.org>

Update Copyright year to cover the previous changes and at the same time
address indentation issues.
Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: NSakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab+huawei@kernel.org>

There are assignments inside the functions which are useless.
Drop them for good.
Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: NSakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab+huawei@kernel.org>

pcim_iomap_table() won't fail if previous pcim_iomap_regions() hasn't.
Since we check pcim_iomap_regions() for failure the check close to
pcim_iomap_table() is bogus and not needed.
Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: NSakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab+huawei@kernel.org>

It's unclear why driver repeats the code from PCI core.
Drop it for good.
Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: NSakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab+huawei@kernel.org>

We may use special helper macro to poll IO till condition or timeout
occurs.
Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: NSakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab+huawei@kernel.org>

Refactor cio2_buffer_done() to get rid of infinite loop by replacing it by
one with clear exit condition. This change also allows to check for an
error ahead.
Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: NSakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab+huawei@kernel.org>

There are few nice macros in pfn.h, some of which we may use here.
Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: NSakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab+huawei@kernel.org>

It's quite unlikely that another page size will be supported,
but in any case there is still an inconsistency between custom
page size definition and generic macros used in the driver.

Switch over to the generic PAGE_SIZE for sake of the consistency.
Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: NSakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab+huawei@kernel.org>