Sean Young [Sun, 23 Aug 2020 17:23:05 +0000 (19:23 +0200)]
media: rc: harmonize infrared durations to microseconds
rc-core kapi uses nanoseconds for infrared durations for receiving, and
microseconds for sending. The uapi already uses microseconds for both,
so this patch does not change the uapi.
Infrared durations do not need nanosecond resolution. IR protocols do not
have durations shorter than about 100 microseconds. Some IR hardware offers
250 microseconds resolution, which is sufficient for most protocols.
Better hardware has 50 microsecond resolution and is enough for every
protocol I am aware off.
Unify on microseconds everywhere. This simplifies the code since less
conversion between microseconds and nanoseconds needs to be done.
This affects:
- rx_resolution member of struct rc_dev
- timeout member of struct rc_dev
- duration member in struct ir_raw_event
Cc: "Bruno Prémont" <bonbons@linux-vserver.org> Cc: Hans Verkuil <hverkuil-cisco@xs4all.nl> Cc: Maxim Levitsky <maximlevitsky@gmail.com> Cc: Patrick Lerda <patrick9876@free.fr> Cc: Kevin Hilman <khilman@baylibre.com> Cc: Neil Armstrong <narmstrong@baylibre.com> Cc: Jerome Brunet <jbrunet@baylibre.com> Cc: Martin Blumenstingl <martin.blumenstingl@googlemail.com> Cc: Sean Wang <sean.wang@mediatek.com> Cc: Matthias Brugger <matthias.bgg@gmail.com> Cc: Patrice Chotard <patrice.chotard@st.com> Cc: Maxime Ripard <mripard@kernel.org> Cc: Chen-Yu Tsai <wens@csie.org> Cc: "David Härdeman" <david@hardeman.nu> Cc: Benjamin Valentin <benpicco@googlemail.com> Cc: Antti Palosaari <crope@iki.fi> Signed-off-by: Sean Young <sean@mess.org> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Alex Bee [Thu, 16 Jul 2020 21:33:03 +0000 (23:33 +0200)]
media: dvb_usb_pctv452e: use ISL6423 voltage regulator per default
Both TT-connect S2-3600 and Pinnacle PCTV Sat HDTV are using
Intersil ISL6423 as LNB voltage regulator. This makes
TT-connect S2-3650 CI the only device which uses STM LNBP22 regulator
which is currently used for all devices driven by pctv452e driver.
This patch fixes this by creating an exception for TT-connect S2-3650 CI
to continue to use STM LNBP22 while all others now using correct ISL6423
driver which makes DiSEqC/EN50494 comands which involve voltage changes
now working on the other devices (which didn't work before).
Signed-off-by: Alex Bee <knaerzche@gmail.com> Signed-off-by: Sean Young <sean@mess.org> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Jason Yan [Sun, 26 Apr 2020 09:43:16 +0000 (11:43 +0200)]
media: mxl5xx: remove unused including <linux/version.h>
Fix the following versioncheck warning:
drivers/media/dvb-frontends/mxl5xx.c:30:1: unused including
<linux/version.h>
Reported-by: Hulk Robot <hulkci@huawei.com> Signed-off-by: Jason Yan <yanaijie@huawei.com> Signed-off-by: Sean Young <sean@mess.org> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Don't need to declare those functions with extern:
drivers/staging/media/atomisp/pci/css_2401_system/host/isys_irq_private.h:51:35: warning: function 'isys_irqc_state_dump' with external linkage has definition
drivers/staging/media/atomisp/pci/css_2401_system/host/isys_irq_private.h:68:35: warning: function 'isys_irqc_reg_store' with external linkage has definition
drivers/staging/media/atomisp/pci/css_2401_system/host/isys_irq_private.h:85:39: warning: function 'isys_irqc_reg_load' with external linkage has definition
drivers/staging/media/atomisp/pci/css_2401_system/host/isys_irq.c:31:35: warning: function 'isys_irqc_status_enable' with external linkage has definition
Some of them are due to ifdefs. Get rid of them by either getting
a common code that would work for both ISP2400 and ISP2401 or
by creating separate functions, one for each ISP version.
media: atomisp: don't check for ISP version for includes
As there aren't duplicated names anymore, and the end goal
is to do runtime checks between ISP2400 and ISP2401,
remove the part of the Makefile which changes the include
places based on the compile-time version.
This shouldn't cause any effect, but it will make easier
for further patches meant to remove conditional compiler
decisions between ISP versions to be replaced by
runtime ones.
media: atomisp: get rid of version-dependent globals
Replace all occurrences along the atomisp tree for the conditional
compilation macros found at system_global.h, replacing them by
tests wheather ISP2401 is defined or not.
drivers/staging/media/atomisp/pci/css_2401_system/host/csi_rx.c:18:11: warning: symbol 'N_SHORT_PACKET_LUT_ENTRIES' was not declared. Should it be static?
drivers/staging/media/atomisp/pci/css_2401_system/host/csi_rx.c:24:11: warning: symbol 'N_LONG_PACKET_LUT_ENTRIES' was not declared. Should it be static?
drivers/staging/media/atomisp/pci/css_2401_system/host/csi_rx.c:30:11: warning: symbol 'N_CSI_RX_FE_CTRL_DLANES' was not declared. Should it be static?
drivers/staging/media/atomisp/pci/css_2401_system/host/csi_rx.c:37:11: warning: symbol 'N_CSI_RX_BE_SID_WIDTH' was not declared. Should it be static?
drivers/staging/media/atomisp/pci/css_2401_system/host/ibuf_ctrl.c:19:11: warning: symbol 'N_IBUF_CTRL_PROCS' was not declared. Should it be static?
media: atomisp: atomisp_gmin_platform: check before use
solve this smatch warning:
drivers/staging/media/atomisp/pci/atomisp_gmin_platform.c:842 gmin_v1p8_ctrl() warn: variable dereferenced before check 'gs' (see line 832)
media: dvb-ttusb-budget: don't use stack for USB transfers
As reported by smatch:
drivers/media/usb/ttusb-budget/dvb-ttusb-budget.c:311 ttusb_boot_dsp() error: doing dma on the stack (b)
drivers/media/usb/ttusb-budget/dvb-ttusb-budget.c:321 ttusb_boot_dsp() error: doing dma on the stack (b)
drivers/media/usb/ttusb-budget/dvb-ttusb-budget.c:330 ttusb_boot_dsp() error: doing dma on the stack (b)
drivers/media/usb/ttusb-budget/dvb-ttusb-budget.c:351 ttusb_set_channel() error: doing dma on the stack (b)
drivers/media/usb/ttusb-budget/dvb-ttusb-budget.c:361 ttusb_del_channel() error: doing dma on the stack (b)
drivers/media/usb/ttusb-budget/dvb-ttusb-budget.c:412 ttusb_init_controller() error: doing dma on the stack (b0)
drivers/media/usb/ttusb-budget/dvb-ttusb-budget.c:416 ttusb_init_controller() error: doing dma on the stack (b1)
drivers/media/usb/ttusb-budget/dvb-ttusb-budget.c:422 ttusb_init_controller() error: doing dma on the stack (b2)
drivers/media/usb/ttusb-budget/dvb-ttusb-budget.c:425 ttusb_init_controller() error: doing dma on the stack (b3)
drivers/media/usb/ttusb-budget/dvb-ttusb-budget.c:430 ttusb_init_controller() error: doing dma on the stack (get_version)
This driver still uses the USB stack for DMA transfers,
which is broken for a long time. I almost dropped this driver,
as there's a high chance that nobody is using it with upstream
Kernels, as we didn't receive any bug reports.
As fixing this won't be hard, I ended opting to fix.
While here, I dropped an ugly hack that implemented read via
a separate function that was just doing a memcpy().
It should be noticed that, during the init phase, there's
a "b4" register that were never initialized, as its buffer
were used just to store the results of "b3" initialization.
media: tda10021: avoid casts when using symbol_rate
The usage of castings and float point when checking for
the setup based at the symbol_rate cause those warnings
with smatch:
drivers/media/dvb-frontends/tda10021.c:153 tda10021_set_symbolrate() warn: unsigned 'symbolrate' is never less than zero.
drivers/media/dvb-frontends/tda10021.c:155 tda10021_set_symbolrate() warn: unsigned 'symbolrate' is never less than zero.
drivers/media/dvb-frontends/tda10021.c:157 tda10021_set_symbolrate() warn: unsigned 'symbolrate' is never less than zero.
drivers/media/dvb-frontends/tda10021.c:159 tda10021_set_symbolrate() warn: unsigned 'symbolrate' is never less than zero.
While the code should work with gcc, as it will evaluate the
values into a constant before compiling, other compilers
could do otherwise. So, get rid of float pointing math on it,
avoiding the need of doing typecasts.
While here, cleanup some coding style issues at the related
code.
drivers/media/pci/ttpci/av7110_v4l.c:163 ves1820_set_tv_freq() warn: unsigned 'freq' is never less than zero.
drivers/media/pci/ttpci/av7110_v4l.c:165 ves1820_set_tv_freq() warn: unsigned 'freq' is never less than zero.
The logic is actually fine. Yet, removing the typecast
shuts up smatch and makes the code more readable.
The original logic had an integer to unsigned integer
conversion, plus a float-point math. While gcc should be
able to do the match at compile time, other compilers might
not do the same. Also, those produce the following warnings
with static code analyzers:
drivers/media/dvb-frontends/tda10086.c:300 tda10086_set_symbol_rate() warn: unsigned 'symbol_rate' is never less than zero.
drivers/media/dvb-frontends/tda10086.c:303 tda10086_set_symbol_rate() warn: unsigned 'symbol_rate' is never less than zero.
drivers/media/dvb-frontends/tda10086.c:306 tda10086_set_symbol_rate() warn: unsigned 'symbol_rate' is never less than zero.
drivers/media/dvb-frontends/tda10086.c:309 tda10086_set_symbol_rate() warn: unsigned 'symbol_rate' is never less than zero.
drivers/media/dvb-frontends/tda10086.c:312 tda10086_set_symbol_rate() warn: unsigned 'symbol_rate' is never less than zero.
drivers/media/dvb-frontends/tda10086.c:315 tda10086_set_symbol_rate() warn: unsigned 'symbol_rate' is never less than zero.
drivers/media/dvb-frontends/tda10086.c:318 tda10086_set_symbol_rate() warn: unsigned 'symbol_rate' is never less than zero.
drivers/media/dvb-frontends/tda10086.c:321 tda10086_set_symbol_rate() warn: unsigned 'symbol_rate' is never less than zero.
drivers/media/dvb-frontends/tda10086.c:324 tda10086_set_symbol_rate() warn: unsigned 'symbol_rate' is never less than zero.
drivers/media/dvb-frontends/tda10086.c:327 tda10086_set_symbol_rate() warn: unsigned 'symbol_rate' is never less than zero.
Change the logic to declare the reference constant as unsigned
and to not use float point math.
Upon running Sparse, "warning: dubious: !x | !y" is brought to notice
for this file. Logical and bitwise OR are basically the same in this
context, so it doesn't cause a runtime bug. But let's change it to
logical OR to make it a little bit cleaner and silence the Sparse
warning.
Dinghao Liu [Fri, 21 Aug 2020 05:49:16 +0000 (07:49 +0200)]
media: atomisp: fix memleak in ia_css_stream_create
When aspect_ratio_crop_init() fails, curr_stream needs
to be freed just like what we've done in the following
error paths. However, current code is returning directly
and ends up leaking memory.
Signed-off-by: Dinghao Liu <dinghao.liu@zju.edu.cn> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
media: atomisp: mt9m114: replace fixed function names
There are a couple of debug messages using hardcoded function names
instead of the preferred __func__ magic constant.
Replace them:
WARNING: Prefer using '"%s...", __func__' to using 'misensor_rmw_reg', this function's name, in a string
215: FILE: ./media/atomisp/i2c/atomisp-mt9m114.c:215:
+ v4l2_err(client, "misensor_rmw_reg error exit, read failed\n");
WARNING: Prefer using '"%s...", __func__' to using 'misensor_rmw_reg', this function's name, in a string
236: FILE: ./media/atomisp/i2c/atomisp-mt9m114.c:236:
+ v4l2_err(client, "misensor_rmw_reg error exit, write failed\n");
Signed-off-by: Juan Antonio Aldea-Armenteros <juant.aldea@gmail.com> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Replace deprecated MSI IRQ enabler and disabler
with pci_alloc_irq_vectors and pci_free_irq_vectors respectively.
And as a result handle the returned error as appropriate.
Compile tested.
[mchehab: solved a merge conflict that renamed dev->pdev]
Removed braces in 'if else' condition as it only consists of
one line each and according to coding style rules , in this case
the braces are not required.
minor numbers use to range between 0 to 255, but that
was changed a long time ago. While it still applies when
CONFIG_VIDEO_FIXED_MINOR_RANGES, when the minor number is
dynamically allocated, this may not be true. In any case,
this is not relevant, as udev will take care of it.
So, remove this useless misinformation.
Acked-by: Hans Verkuil <hans.verkuil@cisco.com> Acked-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Right now, only kAPI documentation describes the device naming.
However, such description is needed at the uAPI too. Add it,
and describe how to get an unique identifier for a given device.
Acked-by: Hans Verkuil <hans.verkuil@cisco.com> Reviewed-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
media: venus: Make debug infrastructure more flexible
Here we introduce debug prefixes for dev_dbg groups by level of
importance - Venus{Low,Med,High,FW} Enabling the particular level
will be done by dynamic debug.
For example to enable debug messages with low level:
echo 'format "VenusLow" +p' > debugfs/dynamic_debug/control
If you want to enable all levels:
echo 'format "Venus" +p' > debugfs/dynamic_debug/control
All the features which dynamic debugging provide are preserved.
media: venus: venc: Add support for frame-skip mode v4l2 control
This adds support for frame-skip-mode standard v4l2 control in
encoder driver. The control is implemented based on the
combination of client selected bitrate-mode and frame-skip-mode.
Once The client selected bitrate-mode (constant or variable) and
the frame-skip-mode is not disabled we set variable framerate for
rate controller.
Maheshwar Ajja [Sat, 23 May 2020 01:05:26 +0000 (03:05 +0200)]
media: v4l2-ctrls: Add encoder constant quality control
When V4L2_CID_MPEG_VIDEO_BITRATE_MODE value is
V4L2_MPEG_VIDEO_BITRATE_MODE_CQ, encoder will produce
constant quality output indicated by
V4L2_CID_MPEG_VIDEO_CONSTANT_QUALITY control value.
Encoder will choose appropriate quantization parameter
and bitrate to produce requested frame quality level.
Presently the recovery mechanism is using two hfi functions
to destroy and create interface queues. For the purpose of
recovery we don't need to free and allocate the memory used
for interface message queues, that's why we introduce new
function which just reinit the queues. Also this will give
to the recovery procedure one less reason to fail (if for
some reason we couldn't allocate memory).
After power domains and clock restructuring the recovery for
sdm845 and v4 did not work properly. Fix that by reworking the
recovery function and the sequence.
media: venus: parser: Prepare parser for multiple invocations
Presently the hfi_parser has been called only once during driver
probe. To prepare the parser function to be called multiple times
from recovery we need to initialize few variables which are used
during parsing time.
Loic Poulain [Tue, 4 Aug 2020 12:21:57 +0000 (14:21 +0200)]
media: venus: Fix reported frame intervals
On dragonboard-410c (apq8016) with HFI_VERSION_1XX, the reported
framerate is in unit of 1/65535 fps (for fine grained control).
So the current reported supported frame intervals is wrong (max
is 1/65535 fps), leading to encoding issues or format negotiation
failures with gstreamer.
Fix that by setting the framerate denominator to coherent value
based on the the framerate factor.
The factor is not always the same, e.g. with db820c (apq8096) HFI
reports framerate in fps unit. So only apply that for HFI_VERSION_1XX.
Vikash Garodia [Tue, 4 Aug 2020 11:48:45 +0000 (13:48 +0200)]
media: venus: fixes for list corruption
There are few list handling issues while adding and deleting
node in the registered buf list in the driver.
1. list addition - buffer added into the list during buf_init
while not deleted during cleanup.
2. list deletion - In capture streamoff, the list was reinitialized.
As a result, if any node was present in the list, it would
lead to issue while cleaning up that node during buf_cleanup.
Ezequiel Garcia [Tue, 25 Aug 2020 03:52:45 +0000 (05:52 +0200)]
media: cedrus: Use H264_SCALING_MATRIX only when required
Baseline, Main and Extended profiles are specified to
not support a scaling matrix. Also, High profiles
can optionally specify a scaling matrix, using
SPS and PPS NAL units.
To meet this expectation, applications are required to
set the V4L2_CID_MPEG_VIDEO_H264_SCALING_MATRIX control
and set the V4L2_H264_PPS_FLAG_SCALING_MATRIX_PRESENT
flag only when a scaling matrix is specified for a picture.
Implement this on cedrus, which has hardware support for this
case.
Ezequiel Garcia [Tue, 25 Aug 2020 03:52:44 +0000 (05:52 +0200)]
media: hantro: Use H264_SCALING_MATRIX only when required
Baseline, Main and Extended profiles are specified to
not support a scaling matrix. Also, High profiles
can optionally specify a scaling matrix, using
SPS and PPS NAL units.
To meet this expectation, applications are required to
set the V4L2_CID_MPEG_VIDEO_H264_SCALING_MATRIX control
and set the V4L2_H264_PPS_FLAG_SCALING_MATRIX_PRESENT
flag only when a scaling matrix is specified for a picture.
Implement this on hantro, which has hardware support for this
case.
Signed-off-by: Ezequiel Garcia <ezequiel@collabora.com> Tested-by: Jonas Karlman <jonas@kwiboo.se> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Ezequiel Garcia [Tue, 25 Aug 2020 03:52:43 +0000 (05:52 +0200)]
media: rkvdec: Use H264_SCALING_MATRIX only when required
Baseline, Main and Extended profiles are specified to
not support a scaling matrix. Also, High profiles
can optionally specify a scaling matrix, using
SPS and PPS NAL units.
To meet this expectation, applications are required to
set the V4L2_CID_MPEG_VIDEO_H264_SCALING_MATRIX control
and set the V4L2_H264_PPS_FLAG_SCALING_MATRIX_PRESENT
flag only when a scaling matrix is specified for a picture.
Implement this on rkvdec, which has hardware support for this
case.
Signed-off-by: Ezequiel Garcia <ezequiel@collabora.com> Tested-by: Jonas Karlman <jonas@kwiboo.se> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Jernej Skrabec [Tue, 25 Aug 2020 03:52:41 +0000 (05:52 +0200)]
media: cedrus: h264: Fix frame list construction
Current frame list construction algorithm assumes that decoded image
will be output into its own buffer. That is true for progressive content
but not for interlaced where each field is decoded separately into same
buffer.
Fix that by checking if capture buffer is listed in DPB. If it is, reuse
it.
Jernej Skrabec [Tue, 25 Aug 2020 03:52:40 +0000 (05:52 +0200)]
media: cedrus: h264: Properly configure reference field
When interlaced H264 content is being decoded, references must indicate
which field is being referenced. Currently this was done by checking
capture buffer flags. However, that is not correct because capture
buffer may hold both fields.
Fix this by checking newly introduced flags in reference lists.
Signed-off-by: Jernej Skrabec <jernej.skrabec@siol.net> Reviewed-by: Nicolas Dufresne <nicolas.dufresne@collabora.com> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Ezequiel Garcia [Tue, 25 Aug 2020 03:52:37 +0000 (05:52 +0200)]
media: uapi: h264: Rename and clarify PPS_FLAG_SCALING_MATRIX_PRESENT
Applications are expected to fill V4L2_CID_MPEG_VIDEO_H264_SCALING_MATRIX
if a non-flat scaling matrix applies to the picture. This is the case if
SPS scaling_matrix_present_flag or PPS pic_scaling_matrix_present_flag
are set, and should be handled by applications.
On one hand, the PPS bitstream syntax element signals the presence of a
Picture scaling matrix modifying the Sequence (SPS) scaling matrix.
On the other hand, our flag should indicate if the scaling matrix
V4L2 control is applicable to this request.
Rename the flag from PPS_FLAG_PIC_SCALING_MATRIX_PRESENT to
PPS_FLAG_SCALING_MATRIX_PRESENT, to avoid mixing this flag with
bitstream syntax element pic_scaling_matrix_present_flag,
and clarify the meaning of our flag.
Signed-off-by: Ezequiel Garcia <ezequiel@collabora.com> Tested-by: Jonas Karlman <jonas@kwiboo.se> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
These bitstream fields are part of the slice header, and therefore
passed redundantly on each slice. The purpose of the redundancy
is to make the codec fault-tolerant in network scenarios.
This is of course not needed to be reflected in the V4L2 controls,
given the bitstream has already been parsed by applications.
Therefore, move the redundant fields to the per-frame decode
parameters control (DECODE_PARAMS).
Field 'pic_parameter_set_id' is simply removed in this case,
because the PPS control must currently contain the active PPS.
Syntax elements dec_ref_pic_marking() and those related
to pic order count, remain invariant as well, and therefore,
the fields dec_ref_pic_marking_bit_size and pic_order_cnt_bit_size
are also common to all slices.
Signed-off-by: Ezequiel Garcia <ezequiel@collabora.com> Reviewed-by: Nicolas Dufresne <nicolas.dufresne@collabora.com> Tested-by: Jonas Karlman <jonas@kwiboo.se> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Ezequiel Garcia [Tue, 25 Aug 2020 03:52:35 +0000 (05:52 +0200)]
media: uapi: h264: Clarify SLICE_BASED mode
Currently, the SLICE_BASED and FRAME_BASED modes documentation
is misleading and not matching the intended use-cases.
Drop non-required fields SLICE_PARAMS 'start_byte_offset' and
DECODE_PARAMS 'num_slices' and clarify the decoding modes in the
documentation.
On SLICE_BASED mode, a single slice is expected per OUTPUT buffer,
and therefore 'start_byte_offset' is not needed (since the offset
to the slice is the start of the buffer).
This mode requires the use of CAPTURE buffer holding, and so
the number of slices shall not be required.
On FRAME_BASED mode, the devices are expected to take care of slice
parsing. Neither SLICE_PARAMS are required (and shouldn't be
exposed by frame-based drivers), nor the number of slices.
Signed-off-by: Ezequiel Garcia <ezequiel@collabora.com> Tested-by: Jonas Karlman <jonas@kwiboo.se> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Ezequiel Garcia [Tue, 25 Aug 2020 03:52:34 +0000 (05:52 +0200)]
media: uapi: h264: Drop SLICE_PARAMS 'size' field
The SLICE_PARAMS control is intended for slice-based
devices. In this mode, the OUTPUT buffer contains
a single slice, and so the buffer's plane payload size
can be used to query the slice size.
To reduce the API surface drop the size from the
SLICE_PARAMS control.
A follow-up change will remove other members in SLICE_PARAMS
so we don't need to add padding fields here.
Signed-off-by: Ezequiel Garcia <ezequiel@collabora.com> Tested-by: Jonas Karlman <jonas@kwiboo.se> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Ezequiel Garcia [Tue, 25 Aug 2020 03:52:33 +0000 (05:52 +0200)]
media: uapi: h264: Increase size of DPB entry pic_num
DPB entry PicNum maximum value is 2*MaxFrameNum for interlaced
content (field_pic_flag=1).
As specified, MaxFrameNum is 2^(log2_max_frame_num_minus4 + 4)
and log2_max_frame_num_minus4 is in the range of 0 to 12,
which means pic_num should be a 32-bit field.
The v4l2_h264_dpb_entry struct needs to be padded to avoid a hole,
which might be also useful to allow future uAPI extensions.
Signed-off-by: Ezequiel Garcia <ezequiel@collabora.com> Tested-by: Jonas Karlman <jonas@kwiboo.se> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Ezequiel Garcia [Tue, 25 Aug 2020 03:52:31 +0000 (05:52 +0200)]
media: uapi: h264: Increase size of 'first_mb_in_slice' field
Slice header syntax element 'first_mb_in_slice' can point
to the last macroblock, currently the field can only reference
65536 macroblocks which is insufficient for 8K videos.
Although unlikely, a 8192x4320 video (where macroblocks are 16x16),
would contain 138240 macroblocks on a frame.
As per the H264 specification, 'first_mb_in_slice' can be up to
PicSizeInMbs - 1, so increase the size of the field to 32-bits.
Note that v4l2_ctrl_h264_slice_params struct will be modified
in a follow-up commit, and so we defer its 64-bit padding.
Signed-off-by: Ezequiel Garcia <ezequiel@collabora.com> Tested-by: Jonas Karlman <jonas@kwiboo.se> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Philipp Zabel [Tue, 25 Aug 2020 03:52:30 +0000 (05:52 +0200)]
media: uapi: h264: Clarify pic_order_cnt_bit_size field
Since pic_order_cnt_bit_size is not a syntax element itself, explicitly
state that it is the total size in bits of the pic_order_cnt_lsb,
delta_pic_order_cnt_bottom, delta_pic_order_cnt[0], and
delta_pic_order_cnt[1] syntax elements contained in the slice.
[Ezequiel: rebase]
Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de> Signed-off-by: Ezequiel Garcia <ezequiel@collabora.com> Reviewed-by: Nicolas Dufresne <nicolas.dufresne@collabora.com> Tested-by: Jonas Karlman <jonas@kwiboo.se> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Given its size, it makes sense to move this table to its control,
so applications can avoid passing it if the slice doesn't specify it.
Before this change struct v4l2_ctrl_h264_slice_params was 960 bytes.
With this change, it's 188 bytes and struct v4l2_ctrl_h264_pred_weight
is 772 bytes.
Signed-off-by: Ezequiel Garcia <ezequiel@collabora.com> Tested-by: Jonas Karlman <jonas@kwiboo.se> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Jernej Skrabec [Tue, 25 Aug 2020 03:52:27 +0000 (05:52 +0200)]
media: uapi: h264: Update reference lists
When dealing with interlaced frames, reference lists must tell if
each particular reference is meant for top or bottom field. This info
is currently not provided at all in the H264 related controls.
Change reference lists to hold a structure, which specifies
an index into the DPB array and the field/frame specification
for the picture.
Currently the only user of these lists is Cedrus which is just compile
fixed here. Actual usage of will come in a following commit.
Bingbu Cao [Fri, 21 Aug 2020 07:59:50 +0000 (09:59 +0200)]
media: ov5675: correct the maximum exposure value
The unit of exposure value is different from other OmniVision sensors,
driver will divide by 2 before set register, the exposure range exposed
by v4l2 ctrl to user should be same as others, so the calculation for
the maximum exposure value in current driver need be fixed.
Signed-off-by: Bingbu Cao <bingbu.cao@intel.com> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Sakari Ailus [Wed, 6 May 2020 13:28:20 +0000 (15:28 +0200)]
media: Documentation: media: Document how to write camera sensor drivers
While we have had some example drivers, there has been up to date no
formal documentation on how camera sensor drivers should be written; what
are the practices, why, and where they apply.
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Hans Verkuil [Fri, 3 Jul 2020 09:20:32 +0000 (11:20 +0200)]
media: imx274: fix frame interval handling
1) the numerator and/or denominator might be 0, in that case
fall back to the default frame interval. This is per the spec
and this caused a v4l2-compliance failure.
2) the updated frame interval wasn't returned in the s_frame_interval
subdev op.
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Reviewed-by: Luca Ceresoli <luca@lucaceresoli.net> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Tom Rix [Sun, 19 Jul 2020 15:34:47 +0000 (17:34 +0200)]
media: m5mols: Check function pointer in m5mols_sensor_power
clang static analysis reports this error
m5mols_core.c:767:4: warning: Called function pointer
is null (null dereference) [core.CallAndMessage]
info->set_power(&client->dev, 0);
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
In other places, the set_power ptr is checked.
So add a check.
Fixes: bc125106f8af ("[media] Add support for M-5MOLS 8 Mega Pixel camera ISP") Signed-off-by: Tom Rix <trix@redhat.com> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Colin Ian King [Mon, 20 Jul 2020 16:13:35 +0000 (18:13 +0200)]
media: i2c: fix error check on max9286_read call
Currently the error return from the call to max9286_read is masked
with 0xf0 so the following check for a negative error return is
never true. Fix this by checking for an error first, then masking
the return value for subsequent conflink_mask checking.
Addresses-Coverity: ("Logically dead code")
Fixes: 66d8c9d2422d ("media: i2c: Add MAX9286 driver") Signed-off-by: Colin Ian King <colin.king@canonical.com> Reviewed-by: Kieran Bingham <kieran.bingham+renesas@ideasonboard.com> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Rationale:
Reduces attack surface on kernel devs opening the links for MITM
as HTTPS traffic is much harder to manipulate.
Deterministic algorithm:
For each file:
If not .svg:
For each line:
If doesn't contain `\bxmlns\b`:
If neither `\bgnu\.org/license`, nor `\bmozilla\.org/MPL\b`:
If both the HTTP and HTTPS versions
return 200 OK and serve the same content:
Replace HTTP with HTTPS.
Signed-off-by: Alexander A. Klimov <grandmaster@al2klimov.de> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
media: ov5640: Correct Bit Div register in clock tree diagram
Although the code is correct and doing the right thing, the clock diagram
showed the wrong register for the bit divider, which had me doubting the
understanding of the tree. Fix this to avoid doubts in the future.
Signed-off-by: Paul Kocialkowski <paul.kocialkowski@bootlin.com> Fixes: aa2882481cada ("media: ov5640: Adjust the clock based on the expected rate") Acked-by: Jacopo Mondi <jacopo@jmondi.org> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Jordan Hand [Fri, 24 Jul 2020 17:37:38 +0000 (19:37 +0200)]
media: ipu3.rst: Format media-ctl and yavta commands as code blocks
Fix improper line breaks and format all example yavta and media-ctl
commands as code blocks to improve readability.
Signed-off-by: Jordan Hand <jorhand@linux.microsoft.com> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
projects / kernel.git / log