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>

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: f90cf607 ("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>

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>

Instead, use the code from linux/fixp-arith.h.
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

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>

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>

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>

Those are needed for real applications to work with Satellite
systems.
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

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>

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>

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>

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>

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>

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>

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>

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>

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>

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>

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>

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>

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>

As this virtual driver is probed manually, add modaliases
for this driver.
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

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>

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>

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>

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>

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>

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>

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>

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>

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: 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>

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: 24fb190e ("media: vidtv: implement a tuner driver")
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

The current remove logic is broken and causes an OOPS.

Fix it.
Signed-off-by: Mauro 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: Daniel W. S. Almeida <dwlsalmeida@gmail.com>
Signed-off-by: Mauro 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: Daniel W. S. Almeida <dwlsalmeida@gmail.com>
Signed-off-by: Mauro 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: Daniel W. S. Almeida <dwlsalmeida@gmail.com>
Signed-off-by: Mauro 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: Daniel W. S. Almeida <dwlsalmeida@gmail.com>
Signed-off-by: Mauro 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: Randy Dunlap <rdunlap@infradead.org>
Acked-by: Randy Dunlap <rdunlap@infradead.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

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>

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>