| Age | Commit message (Collapse) | Author |
|---|
|
We want the USB fixes in here as well.
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
udplite conflict is resolved by taking what 'net-next' did
which removed the backlog receive method assignment, since
it is no longer necessary.
Two entries were added to the non-priv ethtool operations
switch statement, one in 'net' and one in 'net-next, so
simple overlapping changes.
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
A recent cleanup had the right idea to remove the initialization
of the error variable, but missed the actual benefit of that,
which is that we get warnings if there is a bug in it. Now
we get a warning about a bug that was introduced by this cleanup:
drivers/media/platform/davinci/vpfe_capture.c: In function 'vpfe_probe':
drivers/media/platform/davinci/vpfe_capture.c:1992:9: error: 'ret' may be used uninitialized in this function [-Werror=maybe-uninitialized]
This adds the missing initialization that the warning is about,
and another one that was preexisting and that we did not get
a warning for. That second bug has existed since the driver
was first added.
Fixes: efb74461f5a6 ("[media] DaVinci-VPFE-Capture: Delete an unnecessary variable initialisation in vpfe_probe()")
Fixes: 7da8a6cb3e5b ("V4L/DVB (12248): v4l: vpfe capture bridge driver for DM355 and DM6446")
[mchehab@s-opensource.com: fix a merge conflict]
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
|
|
Usually, I don't like fixing coding style issues on non-staging
drivers, as it could be a mess pretty easy, and could become like
a snow ball. That's the case of recent changes on two changesets:
they disalign some statements. Yet, a care a lot with cx88 driver,
as it was the first driver I touched at the Kernel, and I've been
maintaining it since 2005. So, several of the coding style issues
were due to my code.
Per Andrey's suggestion, I ran checkpatch.pl in strict mode, with
fixed several other issues, did some function alinments, but broke
other alinments.
So, I had to manually apply another round of manual fixes to make
sure that everything is ok, and to make checkpatch happy with
this patch.
With this patch, checkpatch.pl is now happy when called with:
./scripts/checkpatch.pl -f --max-line-length=998 --ignore PREFER_PR_LEVEL
Also, the 80-cols violations that made sense were fixed.
Checkpatch would be happier if we convert it to use dev_foo(),
but this is a more complex change.
NOTE: there are some places with msleep(1). As this driver was
written at the time that the default was to sleep at least 10ms
on such calls (e. g. CONFIG_HZ=100), I replaced those calls by
usleep_range(10000, 20000), with should be safe to avoid breakages.
Fixes: 65bc2fe86e66 ("[media] cx88: convert it to use pr_foo() macros")
Fixes: 7b61ba8ff838 ("[media] cx88: make checkpatch happier")
Suggested-by: Andrey Utkin <andrey_utkin@fastmail.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
Reviewed-by: Andrey Utkin <andrey_utkin@fastmail.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
|
|
Commit 4710b752e029 ("[media] v4l: Add Renesas R-Car FDP1 Driver") in the
v4l-dvb tree adds CONFIG_VIDEO_RENESAS_FDP1.
It calls into the FCP driver, but when there is no dependency, FCP might
be a module while FDP1 is built-in.
We have the same logic in VIDEO_RENESAS_VSP1, which also depends on
FCP not being a module when it is built-in itself.
drivers/media/platform/rcar_fdp1.o: In function `fdp1_pm_runtime_resume':
rcar_fdp1.c:(.text.fdp1_pm_runtime_resume+0x78): undefined reference to `rcar_fcp_enable'
drivers/media/platform/rcar_fdp1.o: In function `fdp1_pm_runtime_suspend':
rcar_fdp1.c:(.text.fdp1_pm_runtime_suspend+0x14): undefined reference to `rcar_fcp_disable'
drivers/media/platform/rcar_fdp1.o: In function `fdp1_probe':
rcar_fdp1.c:(.text.fdp1_probe+0x15c): undefined reference to `rcar_fcp_get'
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
|
|
The new driver produces a warning when CONFIG_PM is disabled:
platform/rcar_fdp1.c:2408:12: error: 'fdp1_pm_runtime_resume' defined but not used [-Werror=unused-function]
platform/rcar_fdp1.c:2399:12: error: 'fdp1_pm_runtime_suspend' defined but not used [-Werror=unused-function]
This marks the two functions as __maybe_unused.
Fixes: 4710b752e029 ("[media] v4l: Add Renesas R-Car FDP1 Driver")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
|
|
Remove obsolete media_device_get_devres(), media_device_find_devres(),
and media_device_release_devres() interfaces. These interfaces are now
obsolete.
Signed-off-by: Shuah Khan <shuahkh@osg.samsung.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
|
|
This function is too big and too complex, making really hard
to understand what's there.
Split it into sub-routines, in order to make it easier to be
understood, and to allow gcc to better parse it.
As a bonus, it gets rid of a goto in the middle of a routine.
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
|
|
The dvb_net code has a really complex function, meant to handle
DVB network packages: it is long, has several loops and ifs
inside, and even cause warnings with gcc5.
Prepare it to be split into smaller functions by storing all
arguments and internal vars inside a struct.
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
|
|
The commit 8dfbcc4351a0 ("[media] xc2028: avoid use after free") tried
to address the reported use-after-free by clearing the reference.
However, it's clearing the wrong pointer; it sets NULL to
priv->ctrl.fname, but it's anyway overwritten by the next line
memcpy(&priv->ctrl, p, sizeof(priv->ctrl)).
OTOH, the actual code accessing the freed string is the strcmp() call
with priv->fname:
if (!firmware_name[0] && p->fname &&
priv->fname && strcmp(p->fname, priv->fname))
free_firmware(priv);
where priv->fname points to the previous file name, and this was
already freed by kfree().
For fixing the bug properly, this patch does the following:
- Keep the copy of firmware file name in only priv->fname,
priv->ctrl.fname isn't changed;
- The allocation is done only when the firmware gets loaded;
- The kfree() is called in free_firmware() commonly
Fixes: commit 8dfbcc4351a0 ('[media] xc2028: avoid use after free')
Cc: <stable@vger.kernel.org>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
|
|
Reuse existing functionality from memdup_user() instead of keeping
duplicate source code.
This issue was detected by using the Coccinelle software.
Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
|
|
Those formats are implemented by The DFK 23UP1300, DFK 23UX249 and
DFK 23UX250 USB 3.0 industrial cameras from The Imaging Source.
Signed-off-by: Edgar Thier <info@edgarthier.net>
Acked-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
|
|
The formats have been added without a description, fix that.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
|
|
The formats added by this patch are:
V4L2_PIX_FMT_SBGGR16
V4L2_PIX_FMT_SGBRG16
V4L2_PIX_FMT_SGRBG16
V4L2_PIX_FMT_SRGGB16 already existed before the patch. Rework the
documentation to match that of the other sample depths.
Also align the description of V4L2_PIX_FMT_SRGGB16 to match with other
similar formats.
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Acked-by: Lad, Prabhakar <prabhakar.csengg@gmail.com>
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
|
|
Fix this bug:
"[BUG] process stuck when closing saa7146 [dvb_ttpci]"
Release queued DMA buffers when ending streaming, so that
videobuf_waiton() doesn't block forever.
As reported, this fixes avoids occasional lockup of process reading from
video device, which manifests in such log:
INFO: task ffmpeg:9864 blocked for more than 120 seconds.
Tainted: P O 4.6.7 #3
"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
ffmpeg D ffff880177cc7b00 0 9864 1 0x00000000
ffff880177cc7b00 0000000000000202 0000000000000202 ffffffff8180b4c0
ffff88019d79e4c0 ffffffff81064050 ffff880177cc7ae0 ffff880177cc8000
ffff880177cc7b18 ffff8801fd41d648 ffff8802307acca0 ffff8802307acc70
Call Trace:
[<ffffffff81064050>] ? preempt_count_add+0x89/0xab
[<ffffffff81477215>] schedule+0x86/0x9e
[<ffffffff81477215>] ? schedule+0x86/0x9e
[<ffffffffa0fe1c96>] videobuf_waiton+0x131/0x15e [videobuf_core]
[<ffffffff8107727b>] ? wait_woken+0x6d/0x6d
[<ffffffffa1017be9>] saa7146_dma_free+0x39/0x5b [saa7146_vv]
[<ffffffffa10186c4>] buffer_release+0x2a/0x3e [saa7146_vv]
[<ffffffffa0fee4a8>] videobuf_vm_close+0xd8/0x103 [videobuf_dma_sg]
[<ffffffff8112049e>] remove_vma+0x25/0x4d
[<ffffffff81121a32>] exit_mmap+0xce/0xf7
[<ffffffff8104381d>] mmput+0x4e/0xe2
[<ffffffff810491fd>] do_exit+0x372/0x920
[<ffffffff81049813>] do_group_exit+0x3c/0x98
[<ffffffff810522ef>] get_signal+0x4e8/0x56e
[<ffffffff810710a5>] ? task_dead_fair+0xd/0xf
[<ffffffff81017020>] do_signal+0x23/0x521
[<ffffffff81479e82>] ? _raw_spin_unlock_irqrestore+0x13/0x25
[<ffffffff8109710d>] ? hrtimer_try_to_cancel+0xd7/0x104
[<ffffffff8109b306>] ? ktime_get+0x4c/0xa1
[<ffffffff81096ea6>] ? update_rmtp+0x46/0x5b
[<ffffffff81097ce0>] ? hrtimer_nanosleep+0xe4/0x10e
[<ffffffff81096e3c>] ? hrtimer_init+0xeb/0xeb
[<ffffffff810014f8>] exit_to_usermode_loop+0x4f/0x93
[<ffffffff810019fe>] syscall_return_slowpath+0x3b/0x46
[<ffffffff8147a355>] entry_SYSCALL_64_fastpath+0x8d/0x8f
Reported-by: Philipp Matthias Hahn <pmhahn+video@pmhahn.de>
Tested-by: Philipp Matthias Hahn <pmhahn+video@pmhahn.de>
Signed-off-by: Andrey Utkin <andrey_utkin@fastmail.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
|
|
This function just submits the urb much like mceusb_dev_resume; removing
it simplifies mce_request_packet.
Also add missing usb_kill_urb to mce_dev_probe.
Signed-off-by: Sean Young <sean@mess.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
|
|
Such debug message has a logic to track the IR status,
but it doesn't provide much info. So, get rid of it.
Signed-off-by: Sean Young <sean@mess.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
|
|
The current limit is too low for latest cards with 8+ tuners on a single slot.
IMHO, the most appropriate minimum default is 16.
Signed-off-by: Буди Романто, AreMa Inc <knightrider@are.ma>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
|
|
In randconfig builds that select VIDEO_EM28XX_V4L2 and
MEDIA_SUBDRV_AUTOSELECT, but not MEDIA_CAMERA_SUPPORT, we get
a Kconfig warning:
warning: (VIDEO_EM28XX_V4L2) selects VIDEO_MT9V011 which has unmet direct dependencies (MEDIA_SUPPORT && I2C && VIDEO_V4L2 && MEDIA_CAMERA_SUPPORT)
This avoids the warning by making that 'select' conditional on
MEDIA_CAMERA_SUPPORT. Alternatively we could mark EM28XX as
'depends on MEDIA_CAMERA_SUPPORT', but it does not seem to
have any real dependency on that itself.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
|
|
If MEDIA_SUBDRV_AUTOSELECT and VIDEO_GO7007 are both set, we
automatically select VIDEO_OV7640, but that depends on MEDIA_CAMERA_SUPPORT,
so we get a Kconfig warning if that is disabled:
warning: (VIDEO_GO7007) selects VIDEO_OV7640 which has unmet direct dependencies (MEDIA_SUPPORT && I2C && VIDEO_V4L2 && MEDIA_CAMERA_SUPPORT)
This adds another dependency so we don't accidentally select
it when it is unavailable.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
|
|
The systime function uses struct timespec, which we want to stop
using in the kernel because it overflows in 2038. Fortunately,
this use in dibx000_common is in a function that is never called,
so we can just remove it.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
|
|
The stv090x driver uses the lookup table for signal strength already,
with this patch we use the lookup tables for carrier/noise ratio as well.
This has the advantage, that values for DVB-S and DVB-S2 are now
corresponding, while before they were way off. The values are now
proportional to real carrier/noise ratio, while before they were
corresponding to register values. So now applications are able to give
the user real carrier/noise ratio.
Because the output has to be within 0x0000...0xFFFF the three negative
values for DVB-S2 are omitted. This is no significant loss, because
reception is lost at 7.5 dB already (TT S2-1600, Cine S2), so the
negative values are not really important, and also for DVB-S they don´t
exist.
Signed-off-by: Joerg Riechardt <j.riechardt@gmx.de>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
|
|
Use module_pci_driver() helper to simplify the code.
Signed-off-by: Geliang Tang <geliangtang@gmail.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
|
|
We pass an int pointer to stk_camera_read_reg() but only write to the
highest byte. It's a bug on big endian systems and generally a nasty
thing to do and doesn't match the write function either.
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
|
|
The clock of IR can be provided by the clock provider and controlled
by common clock framework APIs.
Signed-off-by: Ruqiang Ju <juruqiang@huawei.com>
Signed-off-by: Jiancheng Xue <xuejiancheng@hisilicon.com>
Acked-by: Rob Herring <robh@kernel.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
|
|
Remove DVB-T2 BER as it does not work at all and I didn't find
how to fix.
Fix DVB-T and DVB-C BER. It seems to return new some realistic
looking values.
Use (1 << 24) base for CNR calculations to keep it in line with
dvb logarithm functions.
Move all statistic logic to mn88473_read_status() function.
Use regmap_bulk_read() for reading multiple registers as a one go.
Many more and less minor changes.
Cc: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
Signed-off-by: Antti Palosaari <crope@iki.fi>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
|
|
Implement DVBv5 statistics support for DVB-T, DVB-T2 and DVB-C. All
information was taken from the LinuxTV wiki, where Benjamin Larsson has
documented all registers:
https://www.linuxtv.org/wiki/index.php/Panasonic_MN88472
Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
Signed-off-by: Antti Palosaari <crope@iki.fi>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
|
|
The address is 13 bits but it was stuffed in an u8, so 5 bits are
missing from the scancode.
Signed-off-by: Sean Young <sean@mess.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
|
|
get_v4l2_ext_controls32() is used to convert the 32-bit compat struct into
native 64-bit representation. The function multiplies the array length by
the entry length before validating size. Perform the size validation
first.
Also use unsigned values for size computation.
Make similar changes to get_v4l2_buffer32() for multi-plane buffers.
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
|
|
When compiled on i386, it produces several warnings:
./arch/x86/include/asm/bitops.h:457:22: warning: asm output is not an lvalue
./arch/x86/include/asm/bitops.h:457:22: warning: asm output is not an lvalue
./arch/x86/include/asm/bitops.h:457:22: warning: asm output is not an lvalue
./arch/x86/include/asm/bitops.h:457:22: warning: asm output is not an lvalue
./arch/x86/include/asm/bitops.h:457:22: warning: asm output is not an lvalue
./arch/x86/include/asm/bitops.h:457:22: warning: asm output is not an lvalue
I suspect that some gcc optimization could be causing the asm code to be
incorrectly generated. Splitting it into two macro calls fix the issues
and gets us rid of 6 smatch warnings, with is a good thing. As it should
not cause any troubles, as we're basically doing the same thing, let's
apply such change to vpe.c.
Cc: Benoit Parrot <bparrot@ti.com>
Cc: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
|
|
Despite being exported, there's no prototype for it at the
headers, as warned by sparse:
Fixes this sparse warning:
drivers/media/platform/ti-vpe/vpdma.c:1000:6: warning: no previous prototype for 'vpdma_enable_list_notify_irq' [-Wmissing-prototypes]
void vpdma_enable_list_notify_irq(struct vpdma_data *vpdma, int irq_num,
^~~~~~~~~~~~~~~~~~~~~~~~~~~~
Worse than that, it is not even used, as making it static it
would produce:
drivers/media/platform/ti-vpe/vpdma.c:1000:13: warning: 'vpdma_enable_list_notify_irq' defined but not used [-Wunused-function]
static void vpdma_enable_list_notify_irq(struct vpdma_data *vpdma, int irq_num,
^~~~~~~~~~~~~~~~~~~~~~~~~~~~
So, let's just get rid of the dead code. If needed in the future,
someone could re-add it.
Cc: Benoit Parrot <bparrot@ti.com>
Cc: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
|
|
davinci/vpfe_capture.c: In function 'vpfe_probe':
davinci/vpfe_capture.c:1992:9: warning: 'ret' may be used uninitialized
in this function [-Wmaybe-uninitialized]
return ret;
^~~
This is indeed correct, so if the kmalloc fails set ret to -ENOMEM.
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
|
|
The VPE was restricting the number of plane per buffer based on
the fact that if a particular format had color separation it was
meant to need 2 planes.
However NV12/NV16 are color separate format which are meant to be
presented in a single contiguous buffer/plane.
It could also be presented in a multi-plane as well if need be.
So we must support both modes for more flexibility.
The number of plane requested by user space was previously ignored
and was therefore always overwritten.
The driver now use the requested num plane as hint to calculate needed
offset when required.
Signed-off-by: Benoit Parrot <bparrot@ti.com>
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
|
|
Since there might be more then one instance it is better to
show the base address when dumping registers to help
with debugging.
Signed-off-by: Benoit Parrot <bparrot@ti.com>
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
|
|
In preparation to add colorspace conversion support to VIP,
we need to turn csc.c into its own kernel module.
Signed-off-by: Benoit Parrot <bparrot@ti.com>
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
|
|
Add RAW8 and RAW16 data type to VPDMA.
To handle RAW format we are re-using the YUV CBY422
vpdma data type so that we use the vpdma to re-order
the incoming bytes, as the VIP parser assumes that the
first byte presented on the bus is the MSB of a 2
bytes value.
RAW8 handles from 1 to 8 bits.
RAW16 handles from 9 to 16 bits.
Signed-off-by: Benoit Parrot <bparrot@ti.com>
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
|
|
When scaler is to be used we need to make sure that the input and
output frame size do not exceed the maximum frame sizes that the
scaler h/w can handle otherwise streaming stall as the scaler
cannot proceed.
The scaler buffer is limited to 2047 pixels (i.e. 11 bits) when
attempting anything larger (2048 for example) the scaler stalls.
Realistically in an mem2mem device we can only check for this type
of issue when start_streaming is called. We can't do it during the
try_fmt/s_fmt because we do not have all of the info needed at that
point. So instead when start_streaming is called we need to check
that the input and output frames size do not exceed the scaler's
capability. The only time larger frame size are allowed is when
the input frame szie is the same as the output frame size.
Now in the case where we need to fail, start_streaming must return
all previously queued buffer back otherwise the vb2 framework
will issue kernel WARN messages.
In this case we also give an error message.
Signed-off-by: Benoit Parrot <bparrot@ti.com>
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
|
|
Since there might be more then one instance it is better to
show the base address when dumping registers to help
with debugging.
Signed-off-by: Benoit Parrot <bparrot@ti.com>
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
|
|
In preparation to add scaler support into VIP we need to
turn sc.c into its own kernel module.
Add support for multiple SC memory block as VIP contains
2 scaler instances.
This is done by passing the resource name to sc_create() and
modify the vpe invocation accordingly.
Signed-off-by: Benoit Parrot <bparrot@ti.com>
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
|
|
Allow VPE to be able to export DMA buffer.
Signed-off-by: Benoit Parrot <bparrot@ti.com>
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
|
|
For deinterlacing operation, VPE hardware uses motion vectors.
MV calculated in the previous iteration are used for next interation.
Therefore driver allocates two motion vectors in ping-pong fashion.
For every transaction, one MV is DMAed in and one is DMAed out.
All the outbound DMAs (DMA to memory) use output parameters, but as
the motion vectors is generated purely out of input fields, it should
use the input parameters for DMA.
Fix the add_out_dtd to use source q_data for creating descriptor.
If the output size is greater than input stride, without this change,
MV DMA may overwrite the buffer causing memory corruption.
This CRITICAL fix ensures that the motion vector DMA descriptor is
created based on the attributes with which the buffer was allocated.
Signed-off-by: Nikhil Devshatwar <nikhil.nd@ti.com>
Signed-off-by: Ravikumar Kattekola <rk@ti.com>
Signed-off-by: Ravi Babu <ravibabu@ti.com>
Signed-off-by: Benoit Parrot <bparrot@ti.com>
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
|
|
VPDMA buffer will be used by CPU as well as by the VPDMA.
CPU will write/update the VPDMA descriptors containing data
about the video buffer DMA addresses.
VPDMA will write the "write descriptor" containing the
data about the DMA operation.
When mapping/unmapping the buffer, driver has to take care of
WriteBack and invalidation of the cache so that all the
coherency is maintained from both directions.
Use DMA_BIDIRECTIONAL to maintain coherency between CPU and VPDMA.
Signed-off-by: Nikhil Devshatwar <nikhil.nd@ti.com>
Signed-off-by: Benoit Parrot <bparrot@ti.com>
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
|
|
vpdma_create API is supposed to allocated the struct vpdma_data and
return it to the driver. Also, it would call the callback function
when the VPDMA firmware is loaded.
Typically, VPE driver have following function call:
dev->vpdma = vpdma_create(pdev, firmware_load_callback);
And the callback implementation would continue the probe further.
Also, the dev->vpdma is accessed from the callback implementation.
This may lead to race condition between assignment of dev->vpdma
and the callback function being triggered.
This would lead to kernel crash because of NULL pointer access.
Fix this by passing a driver wrapped &vpdma_data instead of allocating
inside vpdma_create.
Change the vpdma_create prototype accordingly and fix return paths.
Also, update the VPE driver to use the updated API and
initialize the dev->vpdma before hand so that the race condition
is avoided.
Signed-off-by: Nikhil Devshatwar <nikhil.nd@ti.com>
Signed-off-by: Benoit Parrot <bparrot@ti.com>
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
|
|
When stop_streaming is called we need to cleanup the queued
vb2 buffers properly.
This was not previously being done which caused kernel
warning when the application using the resources was killed.
Kernel warnings were also generated on successful completion
of a de-interlacing case as well as upon aborting a
conversion.
Make sure every vb2 buffers is properly handled in all cases.
Signed-off-by: Benoit Parrot <bparrot@ti.com>
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
|
|
Current scaler library implementation of sc_set_hs_coeffs and
sc_set_vs_coeffs tries to return immediately if the calculated
coefficient index is already being used.
As the same scaler block is going to be used for all the VPE contexts,
even if the calculated index is same, the parameters have to be
reconfigured for each of the context.
Because of this, when multiple contexts use the same coefficients,
all other contexts would have zero scaling coefficients.
Fix this and also remove the unnecessary hs_index and vs_index fields.
Signed-off-by: Nikhil Devshatwar <nikhil.nd@ti.com>
Signed-off-by: Benoit Parrot <bparrot@ti.com>
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
|
|
The VPDMA RGB data type definition have been updated
to match with Errata i839.
But some of the ARGB definition appeared to be wrong
in the document also. As they would yield RGBA instead.
They have been corrected based on experimentation.
Signed-off-by: Benoit Parrot <bparrot@ti.com>
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
|
|
The YUV data type definition below are taken from
both the TRM and i839 Errata information.
Use the correct data type considering byte
reordering of components.
Added the 2 missing YUV422 variant.
Also since the single use of "C" in the 422 case
to mean "Cr" (i.e. V component). It was decided
to explicitly label them CR to remove any confusion.
Bear in mind that the type label refer to the memory
packed order (LSB - MSB).
Signed-off-by: Benoit Parrot <bparrot@ti.com>
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
|
|
ti_vpe module currently does not get loaded automatically.
Added MODULE_DEVICE_TABLE hint to the driver to assist.
Signed-off-by: Benoit Parrot <bparrot@ti.com>
Reviewed-by: Javier Martinez Canillas <javier@osg.samsung.com>
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
|
|
VPDMA block used in ti-vip and ti-vpe modules have support for
up to 8 hardware descriptor lists. A descriptor list can be
submitted to any of the 8 lists (as long as it's not busy).
When multiple clients want to transfer data in parallel, its easier
to allocate one list per client and let it use it. This way, the
list numbers need not be hard-coded into the driver.
Add support for allocating hwlist and maintain them with a priv data.
Signed-off-by: Nikhil Devshatwar <nikhil.nd@ti.com>
Signed-off-by: Benoit Parrot <bparrot@ti.com>
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
|
|
VPE hardware can generate output in RGB565 or in RGB5551 format.
Add these formats in the supported format list for CAPTURE stream.
Also, for RGB5551 format, the alpha component is not processed,
so the alpha value is taken from the default color.
Set the default color to make alpha component full when the dst
format is of RGB color space.
Signed-off-by: Nikhil Devshatwar <nikhil.nd@ti.com>
Signed-off-by: Benoit Parrot <bparrot@ti.com>
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
|
