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>
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>
This reverts commit 81735ecb62.
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>
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>
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>
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>
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>
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>
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>
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>
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>
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: f90cf6079b ("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>
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>
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>
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>
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>
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 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 9495b7e92f ("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: 24fb190e92 ("media: vidtv: implement a tuner driver")
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>
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: 66d8c9d242 ("media: i2c: Add MAX9286 driver")
Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: Mauro 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: 769afd212b ("media: rcar-csi2: add Renesas R-Car MIPI CSI-2 receiver driver")
Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
