| Age | Commit message (Collapse) | Author |
|---|
|
buffer on encoding"
This reverts commit 3192b2ca79b3f72fbc0eab9cd95432e3c317ab0d.
There are indications that this patch causes problems on some
platforms due to some hardware prefetch. Reverting this patch
for now until this is better understood.
Reported-by: Tomasz Figa <tfiga@chromium.org>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
|
|
The AD7292 is a 10-bit monitor and control system with ADC, DACs,
temperature sensor, and GPIOs.
Configure AD7292 devices in direct access mode, enabling single-ended
ADC readings.
Datasheet:
Link: https://www.analog.com/media/en/technical-documentation/data-sheets/ad7292.pdf
Signed-off-by: Marcelo Schmitt <marcelo.schmitt1@gmail.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
|
|
The FIELDPIC_FLAG_E bit should be set when field_pic_flag exists in stream,
it is currently set based on field_pic_flag of current frame.
The PIC_FIELDMODE_E bit is correctly set based on the field_pic_flag.
Fix this by setting the FIELDPIC_FLAG_E bit when frame_mbs_only is not set.
Fixes: dea0a82f3d22 ("media: hantro: Add support for H264 decoding on G1")
Signed-off-by: Jonas Karlman <jonas@kwiboo.se>
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
|
|
pic_size in hantro_h264_dec_hw_ctx struct is no longer used,
lets remove it.
Signed-off-by: Jonas Karlman <jonas@kwiboo.se>
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
|
|
Calculations for motion vector buffer offset is based on width and height
from the configured output format, lets use the same values for macroblock
width and height hw regs.
Signed-off-by: Jonas Karlman <jonas@kwiboo.se>
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
|
|
A decoded 8-bit 4:2:0 frame need memory for up to 448 bytes per
macroblock with additional 32 bytes on multi-core variants.
Memory layout is as follow:
+---------------------------+
| Y-plane 256 bytes x MBs |
+---------------------------+
| UV-plane 128 bytes x MBs |
+---------------------------+
| MV buffer 64 bytes x MBs |
+---------------------------+
| MC sync 32 bytes |
+---------------------------+
Reduce the extra space allocated now that motion vector buffer offset no
longer is based on the extra space.
Only allocate extra space for 64 bytes x MBs of motion vector buffer
and 32 bytes for multi-core sync.
Fixes: a9471e25629b ("media: hantro: Add core bits to support H264 decoding")
Signed-off-by: Jonas Karlman <jonas@kwiboo.se>
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
|
|
A decoded 8-bit 4:2:0 frame need memory for up to 448 bytes per
macroblock and is laid out in memory as follow:
+---------------------------+
| Y-plane 256 bytes x MBs |
+---------------------------+
| UV-plane 128 bytes x MBs |
+---------------------------+
| MV buffer 64 bytes x MBs |
+---------------------------+
The motion vector buffer offset is currently correct for 4:2:0 because
the extra space for motion vectors is overallocated with an extra
64 bytes x MBs.
Wrong offset for both destination and motion vector buffer are used
for the bottom field of field encoded content, wrong offset is
also used for 4:0:0 (monochrome) content.
Fix this by setting the motion vector address to the expected 384 bytes
x MBs offset for 4:2:0 and 256 bytes x MBs offset for 4:0:0 content.
Also use correct destination and motion vector buffer offset
for the bottom field of field encoded content.
While at it also extend the check for 4:0:0 (monochrome) to include an
additional check for High Profile (100).
Fixes: dea0a82f3d22 ("media: hantro: Add support for H264 decoding on G1")
Signed-off-by: Jonas Karlman <jonas@kwiboo.se>
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
|
|
Update the compatible string to match the updated bindings.
Signed-off-by: Benoit Parrot <bparrot@ti.com>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
|
|
|
|
The variable cable_type is being initialized with a value that
is never read and is being re-assigned a little later on. Replace
the redundant initializtion with the assignment that occurs a little
later. Also initialize frm too rather than have a later assignment.
Addresses-Coverity: ("Unused value")
Signed-off-by: Colin Ian King <colin.king@canonical.com>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
|
|
Commit 953aaa1492c53 ("media: rockchip/vpu: Prepare things to support decoders")
changed the conditions under S_FMT was allowed for OUTPUT
CAPTURE buffers.
However, and according to the mem-to-mem stateless decoder specification,
in order to support dynamic resolution changes, S_FMT should be allowed
even if OUTPUT buffers have been allocated.
Relax decoder S_FMT restrictions on OUTPUT buffers, allowing a
resolution modification, provided the pixel format stays the same.
Tested on RK3288 platforms using ChromiumOS Video Decode/Encode
Accelerator Unittests.
[hverkuil: fix typo: In other -> In order]
Fixes: 953aaa1492c53 ("media: rockchip/vpu: Prepare things to support decoders")
Signed-off-by: Ezequiel Garcia <ezequiel@collabora.com>
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Cc: <stable@vger.kernel.org> # for v5.4 and up
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
|
|
This patch corrects the SPDX License Identifier style
in header files related to I2C controlled media codec drivers.
For C header files Documentation/process/license-rules.rst
mandates C-like comments (opposed to C source files where
C++ style should be used)
Changes made by using a script provided by Joe Perches here:
https://lkml.org/lkml/2019/2/7/46
and some manual changes.
Suggested-by: Joe Perches <joe@perches.com>
Signed-off-by: Nishad Kamdar <nishadkamdar@gmail.com>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
|
|
This patch corrects the SPDX License Identifier style
in header file related to Siano Mobile Silicon Digital TV.
For C header files Documentation/process/license-rules.rst
mandates C-like comments (opposed to C source files where
C++ style should be used)
Changes made by using a script provided by Joe Perches here:
https://lkml.org/lkml/2019/2/7/46
Suggested-by: Joe Perches <joe@perches.com>
Signed-off-by: Nishad Kamdar <nishadkamdar@gmail.com>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
|
|
MPU6050 has two power supply pins: VDD and VLOGIC, but the
mpu6050 driver only supports enabling one of them at the moment.
In some cases, they may need to be enabled separately.
Add an additional "vdd-supply" that stays enabled for as long as
the driver is loaded. We cannot turn off the VDD regulator during
suspend as this would cause register settings (FSR, sampling rate, ...)
to be lost.
Signed-off-by: Stephan Gerhold <stephan@gerhold.net>
Reviewed-by: Jean-Baptiste Maneyrol <jmaneyrol@invensense.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
|
|
Field was already set for light/proximity and
accelerometer/gyroscope/magnetometer sensors.
Fixes: ae7b02ad2f32 ("iio: common: cros_ec_sensors: Expose cros_ec_sensors frequency range via iio sysfs")
Signed-off-by: Gwendal Grignou <gwendal@chromium.org>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
|
|
The AD5600 is a single channel, 16-bit resolution, voltage output digital
to analog converter (DAC). The AD5600 uses a 3-wire SPI interface. It is
part of the AD5541 family of DACs.
The ad5446 IIO driver implements support for some of these DACs (in the
AD5441 family), so the change is a simple entry in this driver.
Link: https://www.analog.com/media/en/technical-documentation/data-sheets/AD5600.pdf
Signed-off-by: Stefan Popa <stefan.popa@analog.com>
Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
|
|
The code in ghes_edac.c and edac_mc.c for grain_bits calculation and
calling trace_mc_event() is now the same. Move it to a single location
in edac_raw_mc_handle_error().
The only difference is the missing IS_ENABLED(CONFIG_RAS) switch, but
this is needed for ghes too.
Signed-off-by: Robert Richter <rrichter@marvell.com>
Signed-off-by: Borislav Petkov <bp@suse.de>
Reviewed-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
Cc: "linux-edac@vger.kernel.org" <linux-edac@vger.kernel.org>
Cc: James Morse <james.morse@arm.com>
Cc: Tony Luck <tony.luck@intel.com>
Link: https://lkml.kernel.org/r/20191106093239.25517-13-rrichter@marvell.com
|
|
detail_location[] is used to collect two location strings so they can
be passed as one to trace_mc_event(). Instead of having an extra copy
step, assemble the location string in other_detail[] from the
beginning.
Using other_detail[] to call trace_mc_event() is now the same as in
edac_mc.c and code can be unified.
Signed-off-by: Robert Richter <rrichter@marvell.com>
Signed-off-by: Borislav Petkov <bp@suse.de>
Reviewed-by: James Morse <james.morse@arm.com>
Reviewed-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
Cc: "linux-edac@vger.kernel.org" <linux-edac@vger.kernel.org>
Cc: Tony Luck <tony.luck@intel.com>
Link: https://lkml.kernel.org/r/20191106093239.25517-12-rrichter@marvell.com
|
|
The current code to convert a physical address mask to a grain
(defined as granularity in bytes) is:
e->grain = ~(mem_err->physical_addr_mask & ~PAGE_MASK);
This is broken in several ways:
1) It calculates to wrong grain values. E.g., a physical address mask
of ~0xfff should give a grain of 0x1000. Without considering
PAGE_MASK, there is an off-by-one. Things are worse when also
filtering it with ~PAGE_MASK. This will calculate to a grain with the
upper bits set. In the example it even calculates to ~0.
2) The grain does not depend on and is unrelated to the kernel's
page-size. The page-size only matters when unmapping memory in
memory_failure(). Smaller grains are wrongly rounded up to the
page-size, on architectures with a configurable page-size (e.g. arm64)
this could round up to the even bigger page-size of the hypervisor.
Fix this with:
e->grain = ~mem_err->physical_addr_mask + 1;
The grain_bits are defined as:
grain = 1 << grain_bits;
Change also the grain_bits calculation accordingly, it is the same
formula as in edac_mc.c now and the code can be unified.
The value in ->physical_addr_mask coming from firmware is assumed to
be contiguous, but this is not sanity-checked. However, in case the
mask is non-contiguous, a conversion to grain_bits effectively
converts the grain bit mask to a power of 2 by rounding it up.
Suggested-by: James Morse <james.morse@arm.com>
Signed-off-by: Robert Richter <rrichter@marvell.com>
Signed-off-by: Borislav Petkov <bp@suse.de>
Reviewed-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
Cc: "linux-edac@vger.kernel.org" <linux-edac@vger.kernel.org>
Cc: Tony Luck <tony.luck@intel.com>
Link: https://lkml.kernel.org/r/20191106093239.25517-11-rrichter@marvell.com
|
|
Use standard macros for page calculations.
Signed-off-by: Robert Richter <rrichter@marvell.com>
Signed-off-by: Borislav Petkov <bp@suse.de>
Reviewed-by: James Morse <james.morse@arm.com>
Reviewed-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
Cc: "linux-edac@vger.kernel.org" <linux-edac@vger.kernel.org>
Cc: Tony Luck <tony.luck@intel.com>
Link: https://lkml.kernel.org/r/20191106093239.25517-10-rrichter@marvell.com
|
|
Reduce the indentation level in edac_mc_handle_error() a bit.
No functional changes.
Signed-off-by: Robert Richter <rrichter@marvell.com>
Signed-off-by: Borislav Petkov <bp@suse.de>
Reviewed-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
Cc: "linux-edac@vger.kernel.org" <linux-edac@vger.kernel.org>
Cc: James Morse <james.morse@arm.com>
Cc: Tony Luck <tony.luck@intel.com>
Link: https://lkml.kernel.org/r/20191106093239.25517-7-rrichter@marvell.com
|
|
The e string to which this is pointing to has already been cleared
earlier in the function so remove the needless zero string termination.
[ bp: Correct the commit message. ]
Suggested-by: Joe Perches <joe@perches.com>
Signed-off-by: Robert Richter <rrichter@marvell.com>
Signed-off-by: Borislav Petkov <bp@suse.de>
Reviewed-by: Mauro Carvalho Chehab <mchehab@kernel.org>
Cc: "linux-edac@vger.kernel.org" <linux-edac@vger.kernel.org>
Cc: James Morse <james.morse@arm.com>
Cc: Tony Luck <tony.luck@intel.com>
Link: https://lkml.kernel.org/r/20191106093239.25517-6-rrichter@marvell.com
|
|
No need to crash the system in case edac_mc_alloc() is called with
invalid arguments, just warn and return. This would cause a checkpatch
warning when touching the code later, so just fix it.
Signed-off-by: Robert Richter <rrichter@marvell.com>
Signed-off-by: Borislav Petkov <bp@suse.de>
Reviewed-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
Cc: "linux-edac@vger.kernel.org" <linux-edac@vger.kernel.org>
Cc: James Morse <james.morse@arm.com>
Cc: Tony Luck <tony.luck@intel.com>
Link: https://lkml.kernel.org/r/20191106093239.25517-5-rrichter@marvell.com
|
|
Introduce an mci_for_each_dimm() iterator. It returns a pointer to
a struct dimm_info. This makes the declaration and use of an index
obsolete and avoids access to internal data of struct mci (direct array
access etc).
[ bp: push the struct dimm_info *dimm; declaration into the
CONFIG_EDAC_DEBUG block. ]
Signed-off-by: Robert Richter <rrichter@marvell.com>
Signed-off-by: Borislav Petkov <bp@suse.de>
Reviewed-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
Cc: "linux-edac@vger.kernel.org" <linux-edac@vger.kernel.org>
Cc: James Morse <james.morse@arm.com>
Cc: Tony Luck <tony.luck@intel.com>
Link: https://lkml.kernel.org/r/20191106093239.25517-4-rrichter@marvell.com
|
|
veml6030 is an ambient light sensor from Vishay semiconductors.
It has 16-bit resolution, supports both ambient light measurement
and white channel which is more responsive to wider wavelength
spectrum. It has flexible power saving, integration time and
gain options. Communication with host is over I2C.
Signed-off-by: Rishi Gupta <gupt21@gmail.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
|
|
Running the contrib/test/test-media script in v4l-utils with the vicodec argument
will cause this kernel warning:
[ 372.298824] ------------[ cut here ]------------
[ 372.298848] DEBUG_LOCKS_WARN_ON(lock->magic != lock)
[ 372.298896] WARNING: CPU: 11 PID: 2220 at kernel/locking/mutex.c:938 __mutex_lock+0x919/0xc10
[ 372.298907] Modules linked in: vicodec v4l2_mem2mem vivid rc_cec v4l2_tpg videobuf2_dma_contig cec rc_core v4l2_dv_timings videobuf2_vmalloc videobuf2_memops videobuf2_v4l2 videobuf2_common videodev mc vmw_balloon vmw_vmci button vmwgfx [last unloaded: vimc]
[ 372.298961] CPU: 11 PID: 2220 Comm: sleep Not tainted 5.4.0-rc1-test-no #150
[ 372.298970] Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 07/29/2019
[ 372.298983] RIP: 0010:__mutex_lock+0x919/0xc10
[ 372.298995] Code: 59 83 e8 9a fc 16 ff 44 8b 05 23 61 38 01 45 85 c0 0f 85 ef f7 ff ff 48 c7 c6 a0 1f 87 82 48 c7 c7 a0 1e 87 82 e8 cd bb f7 fe <0f> 0b e9 d5 f7 ff ff f6 c3 04 0f 84 3b fd ff ff 49 89 df 41 83 e7
[ 372.299004] RSP: 0018:ffff8881b400fb80 EFLAGS: 00010286
[ 372.299014] RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000
[ 372.299022] RDX: 0000000000000003 RSI: 0000000000000004 RDI: ffffed1036801f62
[ 372.299030] RBP: ffff8881b400fcf0 R08: ffffffff81217c91 R09: fffffbfff061c271
[ 372.299038] R10: fffffbfff061c270 R11: ffffffff830e1383 R12: ffff88814761dc80
[ 372.299046] R13: 0000000000000000 R14: ffff88814761cbf0 R15: ffff88814761d030
[ 372.299055] FS: 0000000000000000(0000) GS:ffff8881b68c0000(0000) knlGS:0000000000000000
[ 372.299063] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 372.299071] CR2: 00007f606d78aa20 CR3: 0000000003013002 CR4: 00000000001606e0
[ 372.299153] Call Trace:
[ 372.299176] ? __kasan_slab_free+0x12f/0x180
[ 372.299187] ? kmem_cache_free+0x9b/0x250
[ 372.299200] ? do_exit+0xcdf/0x1200
[ 372.299210] ? do_group_exit+0x85/0x130
[ 372.299220] ? __x64_sys_exit_group+0x23/0x30
[ 372.299231] ? do_syscall_64+0x5e/0x1c0
[ 372.299241] ? entry_SYSCALL_64_after_hwframe+0x44/0xa9
[ 372.299295] ? v4l2_release+0xed/0x190 [videodev]
[ 372.299309] ? mutex_lock_io_nested+0xb80/0xb80
[ 372.299323] ? find_held_lock+0x85/0xa0
[ 372.299335] ? fsnotify+0x5b0/0x600
[ 372.299351] ? locks_remove_file+0x78/0x2b0
[ 372.299363] ? __fsnotify_update_child_dentry_flags.part.0+0x170/0x170
[ 372.299383] ? vidioc_querycap+0x50/0x50 [vicodec]
[ 372.299426] ? v4l2_release+0xed/0x190 [videodev]
[ 372.299467] v4l2_release+0xed/0x190 [videodev]
[ 372.299484] __fput+0x15a/0x390
[ 372.299499] task_work_run+0xb2/0xe0
[ 372.299512] do_exit+0x4d0/0x1200
[ 372.299528] ? do_user_addr_fault+0x367/0x610
[ 372.299538] ? release_task+0x990/0x990
[ 372.299552] ? rwsem_spin_on_owner+0x170/0x170
[ 372.299567] ? vmacache_find+0xb2/0x100
[ 372.299580] do_group_exit+0x85/0x130
[ 372.299592] __x64_sys_exit_group+0x23/0x30
[ 372.299602] do_syscall_64+0x5e/0x1c0
[ 372.299614] entry_SYSCALL_64_after_hwframe+0x44/0xa9
[ 372.299624] RIP: 0033:0x7f606d74a9d6
[ 372.299640] Code: Bad RIP value.
[ 372.299648] RSP: 002b:00007fff65364468 EFLAGS: 00000246 ORIG_RAX: 00000000000000e7
[ 372.299658] RAX: ffffffffffffffda RBX: 00007f606d83b760 RCX: 00007f606d74a9d6
[ 372.299666] RDX: 0000000000000000 RSI: 000000000000003c RDI: 0000000000000000
[ 372.299673] RBP: 0000000000000000 R08: 00000000000000e7 R09: ffffffffffffff80
[ 372.299681] R10: 00007fff65364334 R11: 0000000000000246 R12: 00007f606d83b760
[ 372.299689] R13: 0000000000000002 R14: 00007f606d844428 R15: 0000000000000000
[ 372.299704] ---[ end trace add7d62ca4bc65e3 ]---
This is caused by media_device_cleanup() which destroys
v4l2_dev->mdev->req_queue_mutex. But v4l2_release() tries to lock
that mutex after media_device_cleanup() is called.
By moving media_device_cleanup() to the v4l2_device's release function it is
guaranteed that the mutex is valid whenever v4l2_release is called.
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
|
|
Running the contrib/test/test-media script in v4l-utils with the vim2m argument
will cause this kernel warning:
[ 554.430157] ------------[ cut here ]------------
[ 554.433034] DEBUG_LOCKS_WARN_ON(lock->magic != lock)
[ 554.433064] WARNING: CPU: 0 PID: 616 at kernel/locking/mutex.c:938 __mutex_lock+0xd7a/0x1380
[ 554.439736] Modules linked in: vim2m v4l2_mem2mem vivid rc_cec videobuf2_dma_contig v4l2_dv_timings cec videobuf2_vmalloc videobuf2_memops v4l2_tpg videobuf2_v4l2 videobuf2_common videodev mc rc_core [last unloaded: vivid]
[ 554.445794] CPU: 0 PID: 616 Comm: sleep Not tainted 5.4.0-rc1-virtme #1
[ 554.448481] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.12.0-0-ga698c8995f-prebuilt.qemu.org 04/01/2014
[ 554.453088] RIP: 0010:__mutex_lock+0xd7a/0x1380
[ 554.454955] Code: d2 0f 85 de 05 00 00 44 8b 05 82 d9 f7 00 45 85 c0 0f 85 bf f3 ff ff 48 c7 c6 e0 30 a6 b7 48 c7 c7 e0 2e a6 b7 e8 5c 76 36 fe <0f> 0b e9 a5 f3 ff ff 65 48 8b 1c 25 80 ef 01 00 be 08 00 00 00 48
[ 554.462836] RSP: 0018:ffff88803a4cfad0 EFLAGS: 00010282
[ 554.465129] RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffffffffb5a3d24f
[ 554.468143] RDX: 0000000000000000 RSI: 0000000000000004 RDI: ffffffffb85273f4
[ 554.471000] RBP: ffff88803a4cfc50 R08: fffffbfff701e681 R09: fffffbfff701e681
[ 554.473990] R10: fffffbfff701e680 R11: ffffffffb80f3403 R12: 0000000000000000
[ 554.476831] R13: dffffc0000000000 R14: ffffffffb9714f00 R15: ffff888053103fc8
[ 554.479622] FS: 00007fac6358a540(0000) GS:ffff88805d000000(0000) knlGS:0000000000000000
[ 554.482673] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 554.484949] CR2: 00007fac6343faf0 CR3: 0000000036c22000 CR4: 00000000003406f0
[ 554.487811] Call Trace:
[ 554.488860] ? v4l2_release+0x1b8/0x390 [videodev]
[ 554.490818] ? do_exit+0x946/0x2980
[ 554.492269] ? mutex_lock_io_nested+0x1250/0x1250
[ 554.494128] ? __lock_acquire+0xe90/0x3c30
[ 554.495774] ? fsnotify_first_mark+0x120/0x120
[ 554.497487] ? vim2m_device_release+0x50/0x50 [vim2m]
[ 554.499469] ? v4l2_release+0x1b8/0x390 [videodev]
[ 554.501493] v4l2_release+0x1b8/0x390 [videodev]
[ 554.503430] __fput+0x256/0x790
[ 554.504711] task_work_run+0x109/0x190
[ 554.506145] do_exit+0x95e/0x2980
[ 554.507421] ? vfs_lock_file+0x21/0xf0
[ 554.509013] ? find_held_lock+0x33/0x1c0
[ 554.510382] ? __close_fd+0xee/0x190
[ 554.511862] ? release_task.part.21+0x1310/0x1310
[ 554.513701] ? lock_downgrade+0x6d0/0x6d0
[ 554.515299] do_group_exit+0xeb/0x2d0
[ 554.516862] __x64_sys_exit_group+0x35/0x40
[ 554.518610] do_syscall_64+0x90/0x450
[ 554.520142] entry_SYSCALL_64_after_hwframe+0x49/0xbe
[ 554.522289] RIP: 0033:0x7fac6348ecf6
[ 554.523876] Code: Bad RIP value.
[ 554.525294] RSP: 002b:00007ffe6373dc58 EFLAGS: 00000246 ORIG_RAX: 00000000000000e7
[ 554.528555] RAX: ffffffffffffffda RBX: 00007fac6357f760 RCX: 00007fac6348ecf6
[ 554.531537] RDX: 0000000000000000 RSI: 000000000000003c RDI: 0000000000000000
[ 554.534709] RBP: 0000000000000000 R08: 00000000000000e7 R09: ffffffffffffff80
[ 554.536752] R10: 00007ffe6373db24 R11: 0000000000000246 R12: 00007fac6357f760
[ 554.538643] R13: 0000000000000002 R14: 00007fac63588428 R15: 0000000000000000
[ 554.540634] irq event stamp: 21731
[ 554.541618] hardirqs last enabled at (21731): [<ffffffffb75b3cd4>] _raw_spin_unlock_irq+0x24/0x30
[ 554.544145] hardirqs last disabled at (21730): [<ffffffffb75b3ada>] _raw_spin_lock_irq+0xa/0x40
[ 554.547027] softirqs last enabled at (20148): [<ffffffffb780064d>] __do_softirq+0x64d/0x906
[ 554.550385] softirqs last disabled at (19857): [<ffffffffb5926bd5>] irq_exit+0x175/0x1a0
[ 554.553668] ---[ end trace a389c80c2ca84244 ]---
This is caused by media_device_cleanup() which destroys
v4l2_dev->mdev->req_queue_mutex. But v4l2_release() tries to lock
that mutex after media_device_cleanup() is called.
By moving media_device_cleanup() to the video_device's release function it is
guaranteed that the mutex is valid whenever v4l2_release is called.
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
|
|
There are few variations of 4k resolutions. The biggest one is
4096x2304 which is also supported by HW. It has also nice property that
both width and size are divisible by maximum HEVC CTB size, which is 64.
Signed-off-by: Jernej Skrabec <jernej.skrabec@siol.net>
Acked-by: Paul Kocialkowski <paul.kocialkowski@bootlin.com>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
|
|
H264 decoder needs additional or bigger buffers in order to decode 4k
videos.
Signed-off-by: Jernej Skrabec <jernej.skrabec@siol.net>
Acked-by: Paul Kocialkowski <paul.kocialkowski@bootlin.com>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
|
|
Mode register also holds information if video width is bigger than 2048
and if it is equal to 4096.
Rework cedrus_engine_enable() to properly signal this properties.
Signed-off-by: Jernej Skrabec <jernej.skrabec@siol.net>
Acked-by: Paul Kocialkowski <paul.kocialkowski@bootlin.com>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
|
|
There's a race condition between the list_del_init in the
v4l2_ctrl_request_complete, and the list_add_tail in the
v4l2_ctrl_request_queue, since they can be called in different thread
and the requests_queued list is not protected by a lock. This can lead
to that the v4l2_ctrl_handler is still in the requests_queued list while
the request_is_queued is already set to false, which would cause
use-after-free if the v4l2_ctrl_handler is later released.
Fix this by locking the ->lock of main_hdl (which is the owner of the
requests_queued list) when doing list operations on the
->requests_queued list.
Signed-off-by: Pi-Hsun Shih <pihsun@chromium.org>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
|
|
The driver misses calling v4l2_ctrl_handler_free and
v4l2_device_unregister in remove like what is done in probe failure.
Add the calls to fix it.
Signed-off-by: Chuhong Yuan <hslester96@gmail.com>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
|
|
Disable output side crop selections for the decoder.
This fixes the following v4l2-compliance complaint:
fail: v4l2-test-formats.cpp(1576): IS_DECODER(node)
test Cropping: FAIL
Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
|
|
v4l2_vbi_format, v4l2_sliced_vbi_format and v4l2_sdr_format
have a reserved array at the end that should be zeroed by drivers
as per the V4L2 spec. Older drivers often do not do this, so just
handle this in the core.
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
|
|
Disable capture side compose selections for the encoder.
This fixes the following v4l2-compliance complaint:
fail: v4l2-test-formats.cpp(1662): IS_ENCODER(node)
test Composing: FAIL
Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
|
|
MediaTek encoder allocates non pixel data area for an input buffer every
plane. As the input buffer should be read-only, the driver should not write
anything in the buffer. Therefore, the extra data should be unnecessary.
Signed-off-by: Hirokazu Honda <hiroh@chromium.org>
Reviewed-by: Tomasz Figa <tfiga@chromium.org>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
|
|
Userspace can disable links and create pipelines that
do not start with a source entity. Trying to stream
from such a pipeline should fail with -EPIPE
currently this is not handled and cause kernel crash.
Reproducing the crash:
media-ctl -d0 -l "5:1->21:0[0]" -v
v4l2-ctl -z platform:vimc -d "RGB/YUV Capture" -v width=1920,height=1440
v4l2-ctl --stream-mmap --stream-count=100 -d /dev/video2
Panic message:
[ 39.078841][ T248] BUG: kernel NULL pointer dereference, address: 0000000000000000
[ 39.079338][ T248] #PF: supervisor read access in kernel mode
[ 39.079704][ T248] #PF: error_code(0x0000) - not-present page
[ 39.080071][ T248] PGD 0 P4D 0
[ 39.080279][ T248] Oops: 0000 [#1] SMP PTI
[ 39.080546][ T248] CPU: 0 PID: 248 Comm: vimc-streamer t Not tainted 5.4.0-rc1+ #17
[ 39.081030][ T248] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.12.0-0-ga698c8995f-prebuilt.qemu.org 04/01/2014
[ 39.081779][ T248] RIP: 0010:vimc_sca_process_frame+0xdb/0x210 [vimc]
[ 39.082191][ T248] Code: 44 8d 0c 28 8b 93 a4 01 00 00 48 8b 8b 98 01 00 00 85 d2 74 40 48 8b 74 24 10 8d 7a ff 4c 01 c9 31 d2 4c 01 fe eb 03 4c 89 c2 <44> 0f b6 04 16 44 88 04 11 4c 8d 42 01 48 39 fa 75 eb 8b 93 a4 01
[ 39.083436][ T248] RSP: 0018:ffffb15a005abe90 EFLAGS: 00010246
[ 39.083808][ T248] RAX: 0000000000000000 RBX: ffffa3fdc46d2e00 RCX: ffffb15a02579000
[ 39.084298][ T248] RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000002
[ 39.084792][ T248] RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000
[ 39.085280][ T248] R10: 0000000000000001 R11: 0000000000000000 R12: 0000000000000000
[ 39.085770][ T248] R13: ffffa3fdc46d2ee0 R14: 0000000000000000 R15: 0000000000000000
[ 39.086258][ T248] FS: 0000000000000000(0000) GS:ffffa3fdc7800000(0000) knlGS:0000000000000000
[ 39.086806][ T248] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 39.087217][ T248] CR2: 0000000000000000 CR3: 0000000003c92005 CR4: 0000000000360ef0
[ 39.087706][ T248] Call Trace:
[ 39.087909][ T248] ? vimc_streamer_pipeline_terminate+0x90/0x90 [vimc]
[ 39.088318][ T248] vimc_streamer_thread+0x7c/0xe0 [vimc]
[ 39.088663][ T248] kthread+0x10d/0x130
[ 39.088919][ T248] ? kthread_park+0x80/0x80
[ 39.089205][ T248] ret_from_fork+0x35/0x40
[ 39.089475][ T248] Modules linked in: vimc videobuf2_vmalloc videobuf2_memops v4l2_tpg videobuf2_v4l2 videobuf2_common videodev mc
[ 39.090208][ T248] CR2: 0000000000000000
[ 39.090463][ T248] ---[ end trace 697650fefbf78bee ]---
[ 39.090796][ T248] RIP: 0010:vimc_sca_process_frame+0xdb/0x210 [vimc]
[ 39.091209][ T248] Code: 44 8d 0c 28 8b 93 a4 01 00 00 48 8b 8b 98 01 00 00 85 d2 74 40 48 8b 74 24 10 8d 7a ff 4c 01 c9 31 d2 4c 01 fe eb 03 4c 89 c2 <44> 0f b6 04 16 44 88 04 11 4c 8d 42 01 48 39 fa 75 eb 8b 93 a4 01
[ 39.092417][ T248] RSP: 0018:ffffb15a005abe90 EFLAGS: 00010246
[ 39.092789][ T248] RAX: 0000000000000000 RBX: ffffa3fdc46d2e00 RCX: ffffb15a02579000
[ 39.093278][ T248] RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000002
[ 39.093766][ T248] RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000
[ 39.094254][ T248] R10: 0000000000000001 R11: 0000000000000000 R12: 0000000000000000
[ 39.094742][ T248] R13: ffffa3fdc46d2ee0 R14: 0000000000000000 R15: 0000000000000000
[ 39.095309][ T248] FS: 0000000000000000(0000) GS:ffffa3fdc7800000(0000) knlGS:0000000000000000
[ 39.095974][ T248] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 39.096372][ T248] CR2: 0000000000000000 CR3: 0000000003c92005 CR4: 0000000000360ef0
Signed-off-by: Dafna Hirschfeld <dafna.hirschfeld@collabora.com>
Acked-by: Helen Koike <helen.koike@collabora.com>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
|
|
In the implementation of aspeed_video_probe() the allocated memory for
video should be released if either devm_ioremap_resource()
or aspeed_video_init() or aspeed_video_setup_video() fails. Replace
kzalloc() with devm_kzalloc to avoid explicit release for video.
Fixes: d2b4387f3bdf ("media: platform: Add Aspeed Video Engine driver")
Signed-off-by: Navid Emamdoost <navid.emamdoost@gmail.com>
Reviewed-by: Jae Hyun Yoo <jae.hyun.yoo@linux.intel.com>
Reviewed-by: Eddie James <eajames@linux.ibm.com>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
|
|
It's more clear to use FIELD_SIZEOF instead of its implementation.
Signed-off-by: zhong jiang <zhongjiang@huawei.com>
Acked-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
|
|
rtl8168c_4_hw_phy_config() duplicates rtl8168c_3_hw_phy_config(),
so we can remove the function.
Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
Certain integrated PHY's from RTL8168d support extended pages. On page
0x0007 the number of the extended page is written to register 0x1e,
then the registers on the extended page can be accessed. Add a helper
for this to improve readability and simplify the code.
Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
Use the phylib MDIO access functions in more places to simplify
the code.
Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
Integrated PHY's from RTL8168d support an indirect access method for
PHY parameters. On page 0x0005 parameter number is written to register
0x05, then the parameter can be accessed via register 0x06.
Add a helper for this to improve readability and simplify the code.
Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
Integrated PHY's from RTL8168g support an indirect access method for
PHY parameters. On page 0x0a43 parameter number is written to register
0x13, then the parameter can be accessed via register 0x14.
Add a helper for this to improve readability and simplify the code.
Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
There is a race between driver code that does setup/cleanup of device
and devlink reload operation that in some drivers works with the same
code. Use after free could we easily obtained by running:
while true; do
echo "0000:00:10.0" >/sys/bus/pci/drivers/mlxsw_spectrum2/bind
devlink dev reload pci/0000:00:10.0 &
echo "0000:00:10.0" >/sys/bus/pci/drivers/mlxsw_spectrum2/unbind
done
Fix this by enabling reload only after setup of device is complete and
disabling it at the beginning of the cleanup process.
Reported-by: Ido Schimmel <idosch@mellanox.com>
Fixes: 2d8dc5bbf4e7 ("devlink: Add support for reload")
Signed-off-by: Jiri Pirko <jiri@mellanox.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
The current upstream interface is an all-or-nothing, which is
sub-optimal for future changes, as it doesn't allow the upstream driver
to prepare for the SFP module becoming available, as it is at boot.
Switch to a find-sfp-bus, add-upstream, del-upstream, put-sfp-bus
interface structure instead, which allows the upstream driver to
prepare for a module being available as soon as add-upstream is called.
Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-pinctrl
Pull pin control fixes from Linus Walleij:
- Fix glitch risks in the Intel GPIO
- Fix the Intel Cherryview valid irq mask calculation.
- Allocate the Intel Cherryview irqchip dynamically.
- Fix the valid mask init sequency on the ST STMFX driver.
* tag 'pinctrl-v5.4-3' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-pinctrl:
pinctrl: stmfx: fix valid_mask init sequence
pinctrl: cherryview: Allocate IRQ chip dynamic
pinctrl: cherryview: Fix irq_valid_mask calculation
pinctrl: intel: Avoid potential glitches if pin is in GPIO mode
|
|
One conflict in the BPF samples Makefile, some fixes in 'net' whilst
we were converting over to Makefile.target rules in 'net-next'.
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
The recent change (*) in the ALSA memalloc core allows us to drop the
special vmalloc-specific allocation and page handling. This patch
coverts to the common code.
(*) 1fe7f397cfe2: ALSA: memalloc: Add vmalloc buffer allocation
support
7e8edae39fd1: ALSA: pcm: Handle special page mapping in the
default mmap handler
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Link: https://lore.kernel.org/r/20191108164528.998-1-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
The recent change (commit 08422d2c559d: "ALSA: memalloc: Allow NULL
device for SNDRV_DMA_TYPE_CONTINUOUS type") made the PCM preallocation
helper accepting NULL as the device pointer for the default usage.
Drop the snd_dma_continuous_data() usage that became superfluous from
the callers.
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Link: https://lore.kernel.org/r/20191108164214.611-1-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
