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>
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>
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>
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>
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>
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: 55cd34524a ("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>
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: a0ec8d1dc4 ("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>
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>
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>
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: d747b806ab ("[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>
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>
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>
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>
When platform_get_irq() fails, we should release
vfd and unregister pcdev->v4l2_dev just like the
subsequent error paths.
Fixes: d4e192cc44 ("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>
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>
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>
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>
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>
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>
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>
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>
