Re: [PATCH] media: au0828 - convert to use videobuf2
On 12/11/2014 01:28 AM, Shuah Khan wrote: Convert au0828 to use videobuf2. Tested with NTSC. Tested video and vbi devices with xawtv, tvtime, and vlc. Ran v4l2-compliance to ensure there are no new regressions in video and vbi now has 3 fewer failures. video before: test VIDIOC_DBG_G/S_REGISTER: OK (Not Supported) test VIDIOC_G_FMT: FAIL 3 failures Total: 72, Succeeded: 69, Failed: 3, Warnings: 0 Video after: test VIDIOC_DBG_G/S_REGISTER: OK test VIDIOC_G_FMT: FAIL 3 failures Total: 72, Succeeded: 69, Failed: 3, Warnings: 0 vbi before: test VIDIOC_DBG_G/S_REGISTER: OK (Not Supported) test VIDIOC_REQBUFS/CREATE_BUFS/QUERYBUF: FAIL test VIDIOC_EXPBUF: FAIL test USERPTR: FAIL Total: 72, Succeeded: 66, Failed: 6, Warnings: 0 vbi after: test VIDIOC_DBG_G/S_REGISTER: OK test VIDIOC_REQBUFS/CREATE_BUFS/QUERYBUF: OK test VIDIOC_EXPBUF: OK (Not Supported) test USERPTR: OK Total: 72, Succeeded: 69, Failed: 3, Warnings: 0 Signed-off-by: Shuah Khan shua...@osg.samsung.com FYI: since it is so hard to comment on vb2 conversion patches, I'm going to comment on the vbi.c and video.c sources with your patch applied. I'll do that in two separate posts. Regards, Hans -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: VPU on iMX51 babbage board
On 11/12/2014 15:03, Philipp Zabel wrote:
Am Mittwoch, den 10.12.2014, 22:04 -0200 schrieb Fabio Estevam:
On Wed, Dec 10, 2014 at 7:54 PM, Pierluigi Passaro
pierluigi.pass...@phoenixsoftware.it wrote:
Hi all,
I'm trying to use VPU code driver on iMX51 with kernel 3.18, following these
steps:
- disabled DVI interface
- enabled LCD interface
- configured and enabled VPU
- copied iMX51 vpu firmware without header and renamed
v4l-coda7541-imx53.bin in /lib/firmware
Attached you can find the patch and the defconfig I used.
The boot process hangs after loading the firmware at the first attempt of
writing in VPU address space in the function coda_write of file
driver/media/platform/coda/coda-common.c
Is there anything preventing the coda driver to work with iMX51?
Could anyone provide any suggestion on how investigate the problem?
I have only tested the coda driver on mx6, but looking at the
mx51.dtsi you would need this:
--- a/arch/arm/boot/dts/imx51.dtsi
+++ b/arch/arm/boot/dts/imx51.dtsi
@@ -121,6 +121,7 @@
iram: iram@1ffe {
compatible = mmio-sram;
reg = 0x1ffe 0x2;
+clocks = clks IMX5_CLK_OCRAM;
};
ipu: ipu@4000 {
@@ -584,6 +585,18 @@
clock-names = ipg, ahb, ptp;
status = disabled;
};
+
+vpu: vpu@83ff4000 {
+compatible = fsl,imx53-vpu;
This should be fsl,imx51-vpu, and add a cnm,codahx14.
According to the old imx-vpu-lib code and the vpu_fw_imx51.bin firmware
file, the i.MX51 has a CodaHx14 (0xF00A) as opposed to the i.MX53's
Coda7541 (0xF012).
Thanks for the hint, I'm now going through the old imx-vpu-lib to
understand the CodaHX14 behaviour.
In old imx-vpu-lib, file vpu_util.c, there is a comment that make me
doubtful: i.MX51 has no secondary AXI memory, but use on chip RAM.
As far as I understood, the portion of coda driver affected from this
comment should be around the function coda_setup_iram in coda-bit.c.
How am I supposed to manage this information?
Have I to avoid to use iram for iMX51 (and return on !dev-iram.vaddr)
or go through the function without managing any CodaHX14 specific behaviour?
+reg = 0x83ff4000 0x1000;
+interrupts = 9;
+clocks = clks IMX5_CLK_VPU_REFERENCE_GATE,
+ clks IMX5_CLK_VPU_GATE;
+clock-names = per, ahb;
+resets = src 1;
+iram = iram;
+};
};
+
};
};
Also, not sure if all the required coda patches are available in
3.18, so I tried it on linux-next 20141210 on a imx51-babbage (I had
to disable USB, otherwise linux-next will hang on this board):
[1.368454] coda 83ff4000.vpu: Initialized CODA7541.
[1.373572] coda 83ff4000.vpu: Firmware version: 1.4.50
[1.396695] coda 83ff4000.vpu: codec registered as /dev/video[0-3]
Also, no sure if we need to distinguish mx51 versus mx53 in the coda driver.
Adding Philipp in case he can comment.
Yes, the i.MX51 and i.MX53 firmware files are different. So at least an
entry for i.MX51 with the correct firmware file name has to be added.
regards
Philipp
Thanks
Regards
Pierluigi
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[REVIEW] au0828-vbi.c
Hi Shuah,
This is my review for au0828-vbi.c with your patch applied.
/*
au0828-vbi.c - VBI driver for au0828
Copyright (C) 2010 Devin Heitmueller dheitmuel...@kernellabs.com
This work was sponsored by GetWellNetwork Inc.
This program is free software; you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
the Free Software Foundation; either version 2 of the License, or
(at your option) any later version.
This program is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
GNU General Public License for more details.
You should have received a copy of the GNU General Public License
along with this program; if not, write to the Free Software
Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA
02110-1301, USA.
*/
#include au0828.h
#include linux/kernel.h
#include linux/module.h
#include linux/init.h
#include linux/slab.h
static unsigned int vbibufs = 5;
module_param(vbibufs, int, 0644);
MODULE_PARM_DESC(vbibufs, number of vbi buffers, range 2-32);
Drop this vbibufs argument. It's bogus.
/* -- */
static int vbi_queue_setup(struct vb2_queue *vq, const struct v4l2_format
*fmt,
unsigned int *nbuffers, unsigned int *nplanes,
unsigned int sizes[], void *alloc_ctxs[])
{
struct au0828_dev *dev = vb2_get_drv_priv(vq);
unsigned long size;
if (fmt)
size = fmt-fmt.pix.sizeimage;
It's a VBI format, so the size is
fmt-fmt.vbi.samples_per_line *
(fmt-fmt.vbi.count[0] + fmt-fmt.vbi.count[1]);
else
size = dev-vbi_width * dev-vbi_height * 2;
if (0 == *nbuffers)
*nbuffers = 32;
if (*nbuffers 2)
*nbuffers = 2;
if (*nbuffers 32)
*nbuffers = 32;
Remove these checks, they are not needed.
But if a fmt is passed in, then you *do* need to check if the new format size
is enough to store the vbi data. If not, return -EINVAL.
Test with v4l2-compliance -V0 -s.
*nplanes = 1;
sizes[0] = size;
return 0;
}
static int vbi_buffer_prepare(struct vb2_buffer *vb)
{
struct au0828_dev *dev = vb2_get_drv_priv(vb-vb2_queue);
struct au0828_buffer *buf = container_of(vb, struct au0828_buffer, vb);
unsigned long size;
size = dev-vbi_width * dev-vbi_height * 2;
if (vb2_plane_size(vb, 0) size) {
pr_err(%s data will not fit into plane (%lu %lu)\n,
__func__, vb2_plane_size(vb, 0), size);
return -EINVAL;
}
vb2_set_plane_payload(buf-vb, 0, size);
return 0;
}
static void
vbi_buffer_queue(struct vb2_buffer *vb)
{
struct au0828_dev *dev = vb2_get_drv_priv(vb-vb2_queue);
struct au0828_buffer *buf = container_of(vb, struct au0828_buffer, vb);
struct au0828_dmaqueue *vbiq = dev-vbiq;
unsigned long flags = 0;
buf-mem = vb2_plane_vaddr(vb, 0);
buf-length = vb2_plane_size(vb, 0);
spin_lock_irqsave(dev-slock, flags);
list_add_tail(buf-list, vbiq-active);
spin_unlock_irqrestore(dev-slock, flags);
}
struct vb2_ops au0828_vbi_qops = {
.queue_setup = vbi_queue_setup,
.buf_prepare = vbi_buffer_prepare,
.buf_queue = vbi_buffer_queue,
.start_streaming = au0828_start_analog_streaming,
.stop_streaming = au0828_stop_vbi_streaming,
.wait_prepare= vb2_ops_wait_prepare,
.wait_finish = vb2_ops_wait_finish,
};
Regards,
Hans
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[REVIEW] au0828-video.c
Hi Shuah,
This is the video.c review with your patch applied.
/*
* Auvitek AU0828 USB Bridge (Analog video support)
*
* Copyright (C) 2009 Devin Heitmueller dheitmuel...@linuxtv.org
* Copyright (C) 2005-2008 Auvitek International, Ltd.
*
* This program is free software; you can redistribute it and/or
* modify it under the terms of the GNU General Public License
* As published by the Free Software Foundation; either version 2
* of the License, or (at your option) any later version.
*
* This program is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
* GNU General Public License for more details.
*
* You should have received a copy of the GNU General Public License
* along with this program; if not, write to the Free Software
* Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA
* 02110-1301, USA.
*/
/* Developer Notes:
*
* VBI support is not yet working
I'll see if I can get this to work quickly. If not, then we should
probably just strip the VBI support from this driver. It's pointless to
have non-functioning VBI support.
* The hardware scaler supported is unimplemented
* AC97 audio support is unimplemented (only i2s audio mode)
*
*/
#include au0828.h
#include linux/module.h
#include linux/slab.h
#include linux/init.h
#include linux/device.h
#include media/v4l2-common.h
#include media/v4l2-ioctl.h
#include media/v4l2-event.h
#include media/tuner.h
#include au0828-reg.h
snip
static int queue_setup(struct vb2_queue *vq, const struct v4l2_format *fmt,
unsigned int *nbuffers, unsigned int *nplanes,
unsigned int sizes[], void *alloc_ctxs[])
{
struct au0828_dev *dev = vb2_get_drv_priv(vq);
unsigned long size;
if (fmt)
size = fmt-fmt.pix.sizeimage;
else
size =
(dev-width * dev-height * dev-bytesperline + 7) 3;
This is wrong. It should be 'size = dev-bytesperline * dev-height;'
If fmt is set, then you need to check if the fmt size is large enough for
the current format.
if (size == 0)
This should be 'size img_size'.
return -EINVAL;
if (0 == *nbuffers)
*nbuffers = 32;
Bogus check.
*nplanes = 1;
sizes[0] = size;
return 0;
}
I would rewrite this function as:
{
struct au0828_dev *dev = vb2_get_drv_priv(vq);
unsigned img_size = dev-bytesperline * dev-height;
unsigned long size;
size = fmt ? fmt-fmt.pix.sizeimage : img_size;
if (size img_size)
return -EINVAL;
*nplanes = 1;
sizes[0] = size;
return 0;
}
static int
buffer_prepare(struct vb2_buffer *vb)
{
struct au0828_buffer *buf = container_of(vb, struct au0828_buffer, vb);
struct au0828_dev*dev = vb2_get_drv_priv(vb-vb2_queue);
buf-length = (dev-width * dev-height * 16 + 7) 3;
Use buf-length = dev-bytesperline * dev-height;
if (vb2_plane_size(vb, 0) buf-length) {
pr_err(%s data will not fit into plane (%lu %lu)\n,
__func__, vb2_plane_size(vb, 0), buf-length);
return -EINVAL;
}
vb2_set_plane_payload(buf-vb, 0, buf-length);
return 0;
}
static void
buffer_queue(struct vb2_buffer *vb)
{
struct au0828_buffer*buf = container_of(vb,
struct au0828_buffer,
vb);
struct au0828_dev *dev = vb2_get_drv_priv(vb-vb2_queue);
struct au0828_dmaqueue *vidq= dev-vidq;
unsigned long flags = 0;
buf-mem = vb2_plane_vaddr(vb, 0);
buf-length = vb2_plane_size(vb, 0);
spin_lock_irqsave(dev-slock, flags);
list_add_tail(buf-list, vidq-active);
spin_unlock_irqrestore(dev-slock, flags);
}
static int au0828_i2s_init(struct au0828_dev *dev)
{
/* Enable i2s mode */
au0828_writereg(dev, AU0828_AUDIOCTRL_50C, 0x01);
return 0;
}
/*
* Auvitek au0828 analog stream enable
*/
static int au0828_analog_stream_enable(struct au0828_dev *d)
{
struct usb_interface *iface;
int ret, h, w;
dprintk(1, au0828_analog_stream_enable called\n);
iface = usb_ifnum_to_if(d-usbdev, 0);
if (iface iface-cur_altsetting-desc.bAlternateSetting != 5) {
dprintk(1, Changing intf#0 to alt 5\n);
/* set au0828 interface0 to AS5 here again */
ret = usb_set_interface(d-usbdev, 0, 5);
if (ret 0) {
pr_info(Au0828 can't set alt setting to 5!\n);
return -EBUSY;
}
}
h = d-height / 2 + 2;
w =
Re: [PATCH 3/5] rc: img-ir: biphase enabled with workaround
Hi Sifan,
On 11/12/14 18:54, Sifan Naeem wrote:
+/*
+ * Timer function to re-enable the current protocol after it had been
+ * cleared when invalid interrupts were generated due to a quirk in
+the
+ * img-ir decoder.
+ */
+static void img_ir_suspend_timer(unsigned long arg) {
+ struct img_ir_priv *priv = (struct img_ir_priv *)arg;
+
+ img_ir_write(priv, IMG_IR_IRQ_CLEAR,
+ IMG_IR_IRQ_ALL ~IMG_IR_IRQ_EDGE);
+
+ /* Don't set IRQ if it has changed in a different context. */
Should you even be clearing IRQs in that case? Maybe safer to just treat that
case as a return immediately without touching anything sort of situation.
don't have to clear it for this work around to work, so will remove.
+ if ((priv-hw.suspend_irqen IMG_IR_IRQ_EDGE) ==
+ img_ir_read(priv, IMG_IR_IRQ_ENABLE))
+ img_ir_write(priv, IMG_IR_IRQ_ENABLE, priv-
hw.suspend_irqen);
+ /* enable */
+ img_ir_write(priv, IMG_IR_CONTROL, priv-hw.reg_timings.ctrl); }
To clarify, I was only referring to the case where the irq mask has
changed unexpectedly. If it hasn't changed then it would seem to make
sense to clear pending interrupts (i.e. the ones we've been
intentionally ignoring) before re-enabling them.
When you say it works without, do you mean there never are pending
interrupts (if you don't press any other buttons on the remote)?
Cheers
James
signature.asc
Description: OpenPGP digital signature
Re: [PATCH v2 3/5] rc: img-ir: biphase enabled with workaround
Hi Sifan,
On 11/12/14 20:06, Sifan Naeem wrote:
Biphase decoding in the current img-ir has got a quirk, where multiple
Interrupts are generated when an incomplete IR code is received by the
decoder.
Patch adds a work around for the quirk and enables biphase decoding.
Changes from v1:
* rebased due to conflict with img-ir/hw: Fix potential deadlock stopping
timer
* spinlock taken in img_ir_suspend_timer
* check for hw-stopping before handling quirks in img_ir_isr_hw
* new memeber added to img_ir_priv_hw to save irq status over suspend
For future reference, the list of changes between patchset versions is
usually put after a --- so that it doesn't get included in the final
git commit message. You can also add any Acked-by/Reviewed-by tags
you've been given to new versions of patchset, assuming nothing
significant has changed in that patch (maintainers generally add
relevant tags for you, that are sent in response to the patches being
applied).
Anyway, the whole patchset looks okay to me, aside from the one question
I just asked on patch 3 of v1, which I'm not so sure about. I'll let you
decide whether that needs changing since you have the hardware to verify it.
So for the whole patchset feel free to add my:
Acked-by: James Hogan james.ho...@imgtec.com
Thanks
James
Signed-off-by: Sifan Naeem sifan.na...@imgtec.com
---
drivers/media/rc/img-ir/img-ir-hw.c | 60
+--
drivers/media/rc/img-ir/img-ir-hw.h |4 +++
2 files changed, 61 insertions(+), 3 deletions(-)
diff --git a/drivers/media/rc/img-ir/img-ir-hw.c
b/drivers/media/rc/img-ir/img-ir-hw.c
index 9cecda7..5c32f05 100644
--- a/drivers/media/rc/img-ir/img-ir-hw.c
+++ b/drivers/media/rc/img-ir/img-ir-hw.c
@@ -52,6 +52,11 @@ static struct img_ir_decoder *img_ir_decoders[] = {
#define IMG_IR_QUIRK_CODE_BROKEN 0x1 /* Decode is broken */
#define IMG_IR_QUIRK_CODE_LEN_INCR 0x2 /* Bit length needs increment */
+/*
+ * The decoder generates rapid interrupts without actually having
+ * received any new data after an incomplete IR code is decoded.
+ */
+#define IMG_IR_QUIRK_CODE_IRQ0x4
/* functions for preprocessing timings, ensuring max is set */
@@ -542,6 +547,7 @@ static void img_ir_set_decoder(struct img_ir_priv *priv,
*/
spin_unlock_irq(priv-lock);
del_timer_sync(hw-end_timer);
+ del_timer_sync(hw-suspend_timer);
spin_lock_irq(priv-lock);
hw-stopping = false;
@@ -861,6 +867,29 @@ static void img_ir_end_timer(unsigned long arg)
spin_unlock_irq(priv-lock);
}
+/*
+ * Timer function to re-enable the current protocol after it had been
+ * cleared when invalid interrupts were generated due to a quirk in the
+ * img-ir decoder.
+ */
+static void img_ir_suspend_timer(unsigned long arg)
+{
+ struct img_ir_priv *priv = (struct img_ir_priv *)arg;
+
+ spin_lock_irq(priv-lock);
+ /*
+ * Don't overwrite enabled valid/match IRQs if they have already been
+ * changed by e.g. a filter change.
+ */
+ if ((priv-hw.quirk_suspend_irq IMG_IR_IRQ_EDGE) ==
+ img_ir_read(priv, IMG_IR_IRQ_ENABLE))
+ img_ir_write(priv, IMG_IR_IRQ_ENABLE,
+ priv-hw.quirk_suspend_irq);
+ /* enable */
+ img_ir_write(priv, IMG_IR_CONTROL, priv-hw.reg_timings.ctrl);
+ spin_unlock_irq(priv-lock);
+}
+
#ifdef CONFIG_COMMON_CLK
static void img_ir_change_frequency(struct img_ir_priv *priv,
struct clk_notifier_data *change)
@@ -926,15 +955,38 @@ void img_ir_isr_hw(struct img_ir_priv *priv, u32
irq_status)
if (!hw-decoder)
return;
+ ct = hw-decoder-control.code_type;
+
ir_status = img_ir_read(priv, IMG_IR_STATUS);
- if (!(ir_status (IMG_IR_RXDVAL | IMG_IR_RXDVALD2)))
+ if (!(ir_status (IMG_IR_RXDVAL | IMG_IR_RXDVALD2))) {
+ if (!(priv-hw.ct_quirks[ct] IMG_IR_QUIRK_CODE_IRQ) ||
+ hw-stopping)
+ return;
+ /*
+ * The below functionality is added as a work around to stop
+ * multiple Interrupts generated when an incomplete IR code is
+ * received by the decoder.
+ * The decoder generates rapid interrupts without actually
+ * having received any new data. After a single interrupt it's
+ * expected to clear up, but instead multiple interrupts are
+ * rapidly generated. only way to get out of this loop is to
+ * reset the control register after a short delay.
+ */
+ img_ir_write(priv, IMG_IR_CONTROL, 0);
+ hw-quirk_suspend_irq = img_ir_read(priv, IMG_IR_IRQ_ENABLE);
+ img_ir_write(priv, IMG_IR_IRQ_ENABLE,
+ hw-quirk_suspend_irq
Re: [GIT PULL] soc-camera: 1st set for 3.19
Em Fri, 05 Dec 2014 15:53:11 +0100
Guennadi Liakhovetski g.liakhovet...@gmx.de escreveu:
Hi Mauro,
On Fri, 5 Dec 2014, Mauro Carvalho Chehab wrote:
Em Fri, 05 Dec 2014 08:07:07 +0100
Guennadi Liakhovetski g.liakhovet...@gmx.de escreveu:
Hi Mauro,
On Mon, 1 Dec 2014, Mauro Carvalho Chehab wrote:
Em Fri, 28 Nov 2014 23:15:32 +0100 (CET)
Guennadi Liakhovetski g.liakhovet...@gmx.de escreveu:
Hi Mauro,
IIUC, this coming Sunday might be the last -rc, so, postponing pull
requests to subsystem maintainers even further isn't a good idea, so,
here
goes an soc-camera request. I know it isn't complete, there are a few
more
patches waiting to be pushed upstream, but I won't have time this
coming
weekend and next two weeks I'm traveling, which won't simplify things
either. Some more patches are being reworked, if they arrive soon and
we
do get another -rc, I might try to push them too, but I don't want to
postpone these ones, while waiting. One of these patches has also
been
modified by me and hasn't been tested yet. But changes weren't too
complex. If however I did break something, we'll have to fix it in an
incremental patch.
The following changes since commit
d298a59791fad3a707c1dadbef0935ee2664a10e:
Merge branch 'patchwork' into to_next (2014-11-21 17:01:46 -0200)
are available in the git repository at:
git://linuxtv.org/gliakhovetski/v4l-dvb.git for-3.19-1
for you to fetch changes up to
d8f5c144e57d99d2a7325bf8877812bf560e22dd:
rcar_vin: Fix interrupt enable in progressive (2014-11-23 12:08:19
+0100)
Koji Matsuoka (4):
rcar_vin: Add YUYV capture format support
rcar_vin: Add scaling support
Hmm...
WARNING: DT compatible string renesas,vin-r8a7794 appears
un-documented -- check ./Documentation/devicetree/bindings/
#38: FILE: drivers/media/platform/soc_camera/rcar_vin.c:1406:
+ { .compatible = renesas,vin-r8a7794, .data = (void
*)RCAR_GEN2 },
WARNING: DT compatible string renesas,vin-r8a7793 appears
un-documented -- check ./Documentation/devicetree/bindings/
#39: FILE: drivers/media/platform/soc_camera/rcar_vin.c:1407:
+ { .compatible = renesas,vin-r8a7793, .data = (void
*)RCAR_GEN2 },
Where are the DT binding documentation for this?
You should be adding a patch to:
Documentation/devicetree/bindings/media/rcar_vin.txt
before this one.
Sure, documentation is in the same patch
http://git.linuxtv.org/cgit.cgi/gliakhovetski/v4l-dvb.git/commit/?h=for-3.19-1id=aa1f7651acbe222948f43e239eda15362c9e274c
Is it because you cannot push it via your tree or what's happened, why
this warning?
I see. It seems that you've added the documentation changes after the
patch using it. As I run checkpatch patch by patch, at the same order
as they're found at the tree, checkpatch complained.
It's not after, it is added in that very same patch.
Yeah, right. It seems to be a checkpatch bug. You should be reporting it
to checkpatch maintainers.
And I do remember a
discussion, where I was told, that it's up to specific maintainers,
whether to accept patches, adding DT properties and documentation together
or only separately. Now once again checkpatch has singlehandedly decided
this for us... It's really becoming kernel's blind police.
It is not a kernel's blind police, but a bug at the tool. As I told
you, if you replied earlier, I would be able to send this together
with the pull request.
Anyway, I'm planning to send a late pull request moving some really old
drivers to staging. If I end by doing that, I'll add your patches at
the late pull request.
I reviewed the series already, and it looks good.
Unofortunately, you answered too late. I closed the final set of patches
to 3.19 yesterday. I won't be able to handle it today, and I'll be traveling
all weekend, without access to my build server.
IC, it's a pity, yes.
Thanks
Guennadi
Regards,
Mauro
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 3/5] rc: img-ir: biphase enabled with workaround
-Original Message-
From: James Hogan
Sent: 12 December 2014 10:56
To: Sifan Naeem; mche...@osg.samsung.com
Cc: linux-ker...@vger.kernel.org; linux-media@vger.kernel.org; James
Hartley; Ezequiel Garcia
Subject: Re: [PATCH 3/5] rc: img-ir: biphase enabled with workaround
Hi Sifan,
On 11/12/14 18:54, Sifan Naeem wrote:
+/*
+ * Timer function to re-enable the current protocol after it had
+been
+ * cleared when invalid interrupts were generated due to a quirk in
+the
+ * img-ir decoder.
+ */
+static void img_ir_suspend_timer(unsigned long arg) {
+ struct img_ir_priv *priv = (struct img_ir_priv *)arg;
+
+ img_ir_write(priv, IMG_IR_IRQ_CLEAR,
+ IMG_IR_IRQ_ALL ~IMG_IR_IRQ_EDGE);
+
+ /* Don't set IRQ if it has changed in a different context. */
Should you even be clearing IRQs in that case? Maybe safer to just
treat that case as a return immediately without touching anything sort
of situation.
don't have to clear it for this work around to work, so will remove.
+ if ((priv-hw.suspend_irqen IMG_IR_IRQ_EDGE) ==
+ img_ir_read(priv, IMG_IR_IRQ_ENABLE))
+ img_ir_write(priv, IMG_IR_IRQ_ENABLE, priv-
hw.suspend_irqen);
+ /* enable */
+ img_ir_write(priv, IMG_IR_CONTROL, priv-hw.reg_timings.ctrl); }
To clarify, I was only referring to the case where the irq mask has changed
unexpectedly. If it hasn't changed then it would seem to make sense to clear
pending interrupts (i.e. the ones we've been intentionally ignoring) before
re-enabling them.
When you say it works without, do you mean there never are pending
interrupts (if you don't press any other buttons on the remote)?
Nope, with the change I submitted in v2 (removed the clearing IRQ) there are no
pending interrupts at the end.
But as before it goes through the workaround couple of times for each interrupt
before settling down.
Thanks,
Sifan
Cheers
James
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [REVIEW] au0828-video.c
Em Fri, 12 Dec 2014 11:16:01 +0100 Hans Verkuil hverk...@xs4all.nl escreveu: Hi Shuah, This is the video.c review with your patch applied. /* * Auvitek AU0828 USB Bridge (Analog video support) * * Copyright (C) 2009 Devin Heitmueller dheitmuel...@linuxtv.org * Copyright (C) 2005-2008 Auvitek International, Ltd. * * This program is free software; you can redistribute it and/or * modify it under the terms of the GNU General Public License * As published by the Free Software Foundation; either version 2 * of the License, or (at your option) any later version. * * This program is distributed in the hope that it will be useful, * but WITHOUT ANY WARRANTY; without even the implied warranty of * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the * GNU General Public License for more details. * * You should have received a copy of the GNU General Public License * along with this program; if not, write to the Free Software * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA * 02110-1301, USA. */ /* Developer Notes: * * VBI support is not yet working I'll see if I can get this to work quickly. If not, then we should probably just strip the VBI support from this driver. It's pointless to have non-functioning VBI support. This is a left-over. VBI support works on this driver. I tested. Probably, the patches that added VBI support forgot to remove the above notice. /* This function ensures that video frames continue to be delivered even if the ITU-656 input isn't receiving any data (thereby preventing applications such as tvtime from hanging) */ Why would tvtime be hanging? Make a separate patch that just removes all this timeout nonsense. If there are no frames, then tvtime (and any other app) should just wait for frames to arrive. And ctrl-C should always be able to break the app (or they can timeout themselves). It's not the driver's responsibility to do this and it only makes the code overly complex. Well, we should not cause regressions on userspace. If removing this check will cause tvtime to hang, we should keep it. Btw, the same kind of test used to be at vivi and other drivers. I think we removed it there some time ago, so maybe either it was a VB1 bug or this got fixed at tvtime. Regards, Mauro -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [REVIEW] au0828-video.c
On 12/12/2014 01:49 PM, Mauro Carvalho Chehab wrote: Em Fri, 12 Dec 2014 11:16:01 +0100 Hans Verkuil hverk...@xs4all.nl escreveu: Hi Shuah, This is the video.c review with your patch applied. /* * Auvitek AU0828 USB Bridge (Analog video support) * * Copyright (C) 2009 Devin Heitmueller dheitmuel...@linuxtv.org * Copyright (C) 2005-2008 Auvitek International, Ltd. * * This program is free software; you can redistribute it and/or * modify it under the terms of the GNU General Public License * As published by the Free Software Foundation; either version 2 * of the License, or (at your option) any later version. * * This program is distributed in the hope that it will be useful, * but WITHOUT ANY WARRANTY; without even the implied warranty of * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the * GNU General Public License for more details. * * You should have received a copy of the GNU General Public License * along with this program; if not, write to the Free Software * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA * 02110-1301, USA. */ /* Developer Notes: * * VBI support is not yet working I'll see if I can get this to work quickly. If not, then we should probably just strip the VBI support from this driver. It's pointless to have non-functioning VBI support. This is a left-over. VBI support works on this driver. I tested. Oh wait, now I get it. You are only capturing line 21, not the whole vbi area. That's why vbi_height = 1. Never mind then. Although that comment should indeed be removed. Probably, the patches that added VBI support forgot to remove the above notice. /* This function ensures that video frames continue to be delivered even if the ITU-656 input isn't receiving any data (thereby preventing applications such as tvtime from hanging) */ Why would tvtime be hanging? Make a separate patch that just removes all this timeout nonsense. If there are no frames, then tvtime (and any other app) should just wait for frames to arrive. And ctrl-C should always be able to break the app (or they can timeout themselves). It's not the driver's responsibility to do this and it only makes the code overly complex. Well, we should not cause regressions on userspace. If removing this check will cause tvtime to hang, we should keep it. Obviously if it hangs (i.e. tvtime can't be killed anymore) it is a bug in the driver. But the driver shouldn't start generating bogus frames just because no new frames are arriving, that's just nuts. Btw, the same kind of test used to be at vivi and other drivers. I think we removed it there some time ago, so maybe either it was a VB1 bug or this got fixed at tvtime. Most likely. Regards, Hans -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [REVIEW] au0828-video.c
Em Fri, 12 Dec 2014 13:55:14 +0100 Hans Verkuil hverk...@xs4all.nl escreveu: On 12/12/2014 01:49 PM, Mauro Carvalho Chehab wrote: Em Fri, 12 Dec 2014 11:16:01 +0100 Hans Verkuil hverk...@xs4all.nl escreveu: Hi Shuah, This is the video.c review with your patch applied. /* * Auvitek AU0828 USB Bridge (Analog video support) * * Copyright (C) 2009 Devin Heitmueller dheitmuel...@linuxtv.org * Copyright (C) 2005-2008 Auvitek International, Ltd. * * This program is free software; you can redistribute it and/or * modify it under the terms of the GNU General Public License * As published by the Free Software Foundation; either version 2 * of the License, or (at your option) any later version. * * This program is distributed in the hope that it will be useful, * but WITHOUT ANY WARRANTY; without even the implied warranty of * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the * GNU General Public License for more details. * * You should have received a copy of the GNU General Public License * along with this program; if not, write to the Free Software * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA * 02110-1301, USA. */ /* Developer Notes: * * VBI support is not yet working I'll see if I can get this to work quickly. If not, then we should probably just strip the VBI support from this driver. It's pointless to have non-functioning VBI support. This is a left-over. VBI support works on this driver. I tested. Oh wait, now I get it. You are only capturing line 21, not the whole vbi area. That's why vbi_height = 1. Never mind then. Although that comment should indeed be removed. Probably, the patches that added VBI support forgot to remove the above notice. /* This function ensures that video frames continue to be delivered even if the ITU-656 input isn't receiving any data (thereby preventing applications such as tvtime from hanging) */ Why would tvtime be hanging? Make a separate patch that just removes all this timeout nonsense. If there are no frames, then tvtime (and any other app) should just wait for frames to arrive. And ctrl-C should always be able to break the app (or they can timeout themselves). It's not the driver's responsibility to do this and it only makes the code overly complex. Well, we should not cause regressions on userspace. If removing this check will cause tvtime to hang, we should keep it. Obviously if it hangs (i.e. tvtime can't be killed anymore) it is a bug in the driver. But the driver shouldn't start generating bogus frames just because no new frames are arriving, that's just nuts. If I remember the bug well, what used to happen is that tvtime would wait for a certain amount of time for a frame. If nothing arrives, it stops capturing. The net effect is that tvtime shows no picture. This used to be so bad that tvtime didn't work with vivi at all. The bug used also to manifest there if lots of frames got dropped when, for example, changing from one channel to another. Btw, on a quick look, I'm not seeing any patch at tvtime since we took it over that would be fixing it. So, it was either a VB bug or the bug is still there. Btw, the same kind of test used to be at vivi and other drivers. I think we removed it there some time ago, so maybe either it was a VB1 bug or this got fixed at tvtime. Most likely. Regards, Hans -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 1/8] v4l2 subdevs: replace get/set_crop by get/set_selection
On Thu, Dec 04, 2014 at 10:54:52AM +0100, Hans Verkuil wrote: From: Hans Verkuil hans.verk...@cisco.com The crop and selection pad ops are duplicates. Replace all uses of get/set_crop by get/set_selection. This will make it possible to drop get/set_crop altogether. Signed-off-by: Hans Verkuil hans.verk...@cisco.com Acked-by: Sylwester Nawrocki s.nawro...@samsung.com Acked-by: Laurent Pinchart laurent.pinch...@ideasonboard.com Cc: Prabhakar Lad prabhakar.cse...@gmail.com Cc: Philipp Zabel p.za...@pengutronix.de Acked-by: Sakari Ailus sakari.ai...@linux.intel.com -- Sakari Ailus e-mail: sakari.ai...@iki.fi XMPP: sai...@retiisi.org.uk -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/7] cx25821: convert to vb2
This patch series converts this driver to the vb2 framework. I have tested video capture with my cx25821 board. Audio capture DMA works as well, but since my board doesn't have an audio line-in I couldn't test it with actual audio. This patch series also removes the last case of btcx-risc abuse, so that module can now be merged again with bttv, which is where it belongs. Regards, Hans -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 4/7] cx28521: drop videobuf abuse in cx25821-alsa
From: Hans Verkuil hans.verk...@cisco.com
The alsa driver uses videobuf low-level functions that are not
available in vb2, so replace them by driver-specific functions.
Signed-off-by: Hans Verkuil hans.verk...@cisco.com
---
drivers/media/pci/cx25821/cx25821-alsa.c | 107 ++-
1 file changed, 90 insertions(+), 17 deletions(-)
diff --git a/drivers/media/pci/cx25821/cx25821-alsa.c
b/drivers/media/pci/cx25821/cx25821-alsa.c
index 27e6493..24f964b 100644
--- a/drivers/media/pci/cx25821/cx25821-alsa.c
+++ b/drivers/media/pci/cx25821/cx25821-alsa.c
@@ -64,7 +64,10 @@ static int devno;
struct cx25821_audio_buffer {
unsigned int bpl;
struct cx25821_riscmem risc;
- struct videobuf_dmabuf dma;
+ void*vaddr;
+ struct scatterlist *sglist;
+ int sglen;
+ int nr_pages;
};
struct cx25821_audio_dev {
@@ -87,8 +90,6 @@ struct cx25821_audio_dev {
unsigned int period_size;
unsigned int num_periods;
- struct videobuf_dmabuf *dma_risc;
-
struct cx25821_audio_buffer *buf;
struct snd_pcm_substream *substream;
@@ -142,6 +143,83 @@ MODULE_PARM_DESC(debug, enable debug messages);
#define PCI_MSK_AUD_EXT (1 4)
#define PCI_MSK_AUD_INT (1 3)
+
+static int cx25821_alsa_dma_init(struct cx25821_audio_dev *chip, int nr_pages)
+{
+ struct cx25821_audio_buffer *buf = chip-buf;
+ struct page *pg;
+ int i;
+
+ buf-vaddr = vmalloc_32(nr_pages PAGE_SHIFT);
+ if (NULL == buf-vaddr) {
+ dprintk(1, vmalloc_32(%d pages) failed\n, nr_pages);
+ return -ENOMEM;
+ }
+
+ dprintk(1, vmalloc is at addr 0x%08lx, size=%d\n,
+ (unsigned long)buf-vaddr,
+ nr_pages PAGE_SHIFT);
+
+ memset(buf-vaddr, 0, nr_pages PAGE_SHIFT);
+ buf-nr_pages = nr_pages;
+
+ buf-sglist = vzalloc(buf-nr_pages * sizeof(*buf-sglist));
+ if (NULL == buf-sglist)
+ goto vzalloc_err;
+
+ sg_init_table(buf-sglist, buf-nr_pages);
+ for (i = 0; i buf-nr_pages; i++) {
+ pg = vmalloc_to_page(buf-vaddr + i * PAGE_SIZE);
+ if (NULL == pg)
+ goto vmalloc_to_page_err;
+ sg_set_page(buf-sglist[i], pg, PAGE_SIZE, 0);
+ }
+ return 0;
+
+vmalloc_to_page_err:
+ vfree(buf-sglist);
+ buf-sglist = NULL;
+vzalloc_err:
+ vfree(buf-vaddr);
+ buf-vaddr = NULL;
+ return -ENOMEM;
+}
+
+static int cx25821_alsa_dma_map(struct cx25821_audio_dev *dev)
+{
+ struct cx25821_audio_buffer *buf = dev-buf;
+
+ buf-sglen = dma_map_sg(dev-pci-dev, buf-sglist,
+ buf-nr_pages, PCI_DMA_FROMDEVICE);
+
+ if (0 == buf-sglen) {
+ pr_warn(%s: cx25821_alsa_map_sg failed\n, __func__);
+ return -ENOMEM;
+ }
+ return 0;
+}
+
+static int cx25821_alsa_dma_unmap(struct cx25821_audio_dev *dev)
+{
+ struct cx25821_audio_buffer *buf = dev-buf;
+
+ if (!buf-sglen)
+ return 0;
+
+ dma_unmap_sg(dev-pci-dev, buf-sglist, buf-sglen,
PCI_DMA_FROMDEVICE);
+ buf-sglen = 0;
+ return 0;
+}
+
+static int cx25821_alsa_dma_free(struct cx25821_audio_buffer *buf)
+{
+ vfree(buf-sglist);
+ buf-sglist = NULL;
+ vfree(buf-vaddr);
+ buf-vaddr = NULL;
+ return 0;
+}
+
/*
* BOARD Specific: Sets audio DMA
*/
@@ -335,12 +413,12 @@ static int dsp_buffer_free(struct cx25821_audio_dev *chip)
BUG_ON(!chip-dma_size);
dprintk(2, Freeing buffer\n);
- videobuf_dma_unmap(chip-pci-dev, chip-dma_risc);
- videobuf_dma_free(chip-dma_risc);
+ cx25821_alsa_dma_unmap(chip);
+ cx25821_alsa_dma_free(chip-buf);
pci_free_consistent(chip-pci, risc-size, risc-cpu, risc-dma);
kfree(chip-buf);
- chip-dma_risc = NULL;
+ chip-buf = NULL;
chip-dma_size = 0;
return 0;
@@ -432,8 +510,6 @@ static int snd_cx25821_hw_params(struct snd_pcm_substream
*substream,
struct snd_pcm_hw_params *hw_params)
{
struct cx25821_audio_dev *chip = snd_pcm_substream_chip(substream);
- struct videobuf_dmabuf *dma;
-
struct cx25821_audio_buffer *buf;
int ret;
@@ -457,19 +533,18 @@ static int snd_cx25821_hw_params(struct snd_pcm_substream
*substream,
chip-period_size = AUDIO_LINE_SIZE;
buf-bpl = chip-period_size;
+ chip-buf = buf;
- dma = buf-dma;
- videobuf_dma_init(dma);
- ret = videobuf_dma_init_kernel(dma, PCI_DMA_FROMDEVICE,
+ ret = cx25821_alsa_dma_init(chip,
(PAGE_ALIGN(chip-dma_size) PAGE_SHIFT));
if (ret 0)
goto error;
- ret = videobuf_dma_map(chip-pci-dev, dma);
+ ret =
Re: [RFC PATCH 3/8] v4l2-subdev: drop unused op enum_mbus_fmt
On Thu, Dec 04, 2014 at 10:54:54AM +0100, Hans Verkuil wrote: From: Hans Verkuil hans.verk...@cisco.com Weird, this op isn't used at all. Seems to be orphaned code. Remove it. Signed-off-by: Hans Verkuil hans.verk...@cisco.com Acked-by: Sakari Ailus sakari.ai...@linux.intel.com -- Sakari Ailus e-mail: sakari.ai...@iki.fi XMPP: sai...@retiisi.org.uk -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 5/7] cx25821: convert to vb2
From: Hans Verkuil hans.verk...@cisco.com
This patch converts the cx25821 driver from the old videobuf framework to
the new vb2 framework.
Signed-off-by: Hans Verkuil hans.verk...@cisco.com
---
drivers/media/pci/cx25821/Kconfig | 2 +-
drivers/media/pci/cx25821/cx25821-core.c | 76 ++--
drivers/media/pci/cx25821/cx25821-video.c | 682 --
drivers/media/pci/cx25821/cx25821.h | 24 +-
4 files changed, 207 insertions(+), 577 deletions(-)
diff --git a/drivers/media/pci/cx25821/Kconfig
b/drivers/media/pci/cx25821/Kconfig
index 0e69cab..1755d3d 100644
--- a/drivers/media/pci/cx25821/Kconfig
+++ b/drivers/media/pci/cx25821/Kconfig
@@ -2,7 +2,7 @@ config VIDEO_CX25821
tristate Conexant cx25821 support
depends on VIDEO_DEV PCI I2C
select I2C_ALGOBIT
- select VIDEOBUF_DMA_SG
+ select VIDEOBUF2_DMA_SG
---help---
This is a video4linux driver for Conexant 25821 based
TV cards.
diff --git a/drivers/media/pci/cx25821/cx25821-core.c
b/drivers/media/pci/cx25821/cx25821-core.c
index c8c65b7..c1ea24e 100644
--- a/drivers/media/pci/cx25821/cx25821-core.c
+++ b/drivers/media/pci/cx25821/cx25821-core.c
@@ -874,10 +874,9 @@ static int cx25821_dev_setup(struct cx25821_dev *dev)
if (dev-pci-device != 0x8210) {
pr_info(%s(): Exiting. Incorrect Hardware device = 0x%02x\n,
__func__, dev-pci-device);
- return -1;
- } else {
- pr_info(Athena Hardware device = 0x%02x\n, dev-pci-device);
+ return -ENODEV;
}
+ pr_info(Athena Hardware device = 0x%02x\n, dev-pci-device);
/* Apply a sensible clock frequency for the PCIe bridge */
dev-clk_freq = 2800;
@@ -1003,11 +1002,17 @@ EXPORT_SYMBOL(cx25821_riscmem_alloc);
static __le32 *cx25821_risc_field(__le32 * rp, struct scatterlist *sglist,
unsigned int offset, u32 sync_line,
unsigned int bpl, unsigned int padding,
- unsigned int lines)
+ unsigned int lines, bool jump)
{
struct scatterlist *sg;
unsigned int line, todo;
+ if (jump) {
+ *(rp++) = cpu_to_le32(RISC_JUMP);
+ *(rp++) = cpu_to_le32(0);
+ *(rp++) = cpu_to_le32(0); /* bits 63-32 */
+ }
+
/* sync instruction */
if (sync_line != NO_SYNC_LINE)
*(rp++) = cpu_to_le32(RISC_RESYNC | sync_line);
@@ -1073,13 +1078,13 @@ int cx25821_risc_buffer(struct pci_dev *pci, struct
cx25821_riscmem *risc,
fields++;
/* estimate risc mem: worst case is one write per page border +
- one write per scan line + syncs + jump (all 2 dwords). Padding
+ one write per scan line + syncs + jump (all 3 dwords). Padding
can cause next bpl to start close to a page border. First DMA
region may be smaller than PAGE_SIZE */
/* write and jump need and extra dword */
instructions = fields * (1 + ((bpl + padding) * lines) / PAGE_SIZE +
lines);
- instructions += 2;
+ instructions += 5;
rc = cx25821_riscmem_alloc(pci, risc, instructions * 12);
if (rc 0)
@@ -1090,17 +1095,17 @@ int cx25821_risc_buffer(struct pci_dev *pci, struct
cx25821_riscmem *risc,
if (UNSET != top_offset) {
rp = cx25821_risc_field(rp, sglist, top_offset, 0, bpl, padding,
- lines);
+ lines, true);
}
if (UNSET != bottom_offset) {
rp = cx25821_risc_field(rp, sglist, bottom_offset, 0x200, bpl,
- padding, lines);
+ padding, lines, UNSET == top_offset);
}
/* save pointer to jmp instruction address */
risc-jmp = rp;
- BUG_ON((risc-jmp - risc-cpu + 2) * sizeof(*risc-cpu) risc-size);
+ BUG_ON((risc-jmp - risc-cpu + 3) * sizeof(*risc-cpu) risc-size);
return 0;
}
@@ -1200,41 +1205,14 @@ int cx25821_risc_databuffer_audio(struct pci_dev *pci,
}
EXPORT_SYMBOL(cx25821_risc_databuffer_audio);
-int cx25821_risc_stopper(struct pci_dev *pci, struct cx25821_riscmem *risc,
-u32 reg, u32 mask, u32 value)
+void cx25821_free_buffer(struct cx25821_dev *dev, struct cx25821_buffer *buf)
{
- __le32 *rp;
- int rc;
-
- rc = cx25821_riscmem_alloc(pci, risc, 4 * 16);
-
- if (rc 0)
- return rc;
-
- /* write risc instructions */
- rp = risc-cpu;
-
- *(rp++) = cpu_to_le32(RISC_WRITECR | RISC_IRQ1);
- *(rp++) = cpu_to_le32(reg);
- *(rp++) = cpu_to_le32(value);
- *(rp++) = cpu_to_le32(mask);
- *(rp++) = cpu_to_le32(RISC_JUMP);
- *(rp++) =
[PATCH 3/7] btcx-risc: move to bt8xx
From: Hans Verkuil hans.verk...@cisco.com
The btcx-risc module is no longer used by other drivers except for bttv.
So move it from common to bt8xx and make it part of the bttv driver instead
of as a separate module.
This module should never have been a common module since most of the code
has always been bttv specific.
Signed-off-by: Hans Verkuil hans.verk...@cisco.com
---
drivers/media/common/Kconfig| 4 ---
drivers/media/common/Makefile | 1 -
drivers/media/pci/bt8xx/Kconfig | 1 -
drivers/media/pci/bt8xx/Makefile| 2 +-
drivers/media/{common = pci/bt8xx}/btcx-risc.c | 36 ++---
drivers/media/{common = pci/bt8xx}/btcx-risc.h | 8 --
6 files changed, 9 insertions(+), 43 deletions(-)
rename drivers/media/{common = pci/bt8xx}/btcx-risc.c (90%)
rename drivers/media/{common = pci/bt8xx}/btcx-risc.h (92%)
diff --git a/drivers/media/common/Kconfig b/drivers/media/common/Kconfig
index b85f88c..21154dd 100644
--- a/drivers/media/common/Kconfig
+++ b/drivers/media/common/Kconfig
@@ -8,10 +8,6 @@ comment common driver options
config VIDEO_CX2341X
tristate
-config VIDEO_BTCX
- depends on PCI
- tristate
-
config VIDEO_TVEEPROM
tristate
depends on I2C
diff --git a/drivers/media/common/Makefile b/drivers/media/common/Makefile
index d208de3..89b795d 100644
--- a/drivers/media/common/Makefile
+++ b/drivers/media/common/Makefile
@@ -1,5 +1,4 @@
obj-y += b2c2/ saa7146/ siano/
obj-$(CONFIG_VIDEO_CX2341X) += cx2341x.o
-obj-$(CONFIG_VIDEO_BTCX) += btcx-risc.o
obj-$(CONFIG_VIDEO_TVEEPROM) += tveeprom.o
obj-$(CONFIG_CYPRESS_FIRMWARE) += cypress_firmware.o
diff --git a/drivers/media/pci/bt8xx/Kconfig b/drivers/media/pci/bt8xx/Kconfig
index 61d09e0..496cf6b 100644
--- a/drivers/media/pci/bt8xx/Kconfig
+++ b/drivers/media/pci/bt8xx/Kconfig
@@ -2,7 +2,6 @@ config VIDEO_BT848
tristate BT848 Video For Linux
depends on VIDEO_DEV PCI I2C VIDEO_V4L2
select I2C_ALGOBIT
- select VIDEO_BTCX
select VIDEOBUF_DMA_SG
depends on RC_CORE
select VIDEO_TUNER
diff --git a/drivers/media/pci/bt8xx/Makefile b/drivers/media/pci/bt8xx/Makefile
index f9fe7c4..2d4c3dd 100644
--- a/drivers/media/pci/bt8xx/Makefile
+++ b/drivers/media/pci/bt8xx/Makefile
@@ -1,6 +1,6 @@
bttv-objs := bttv-driver.o bttv-cards.o bttv-if.o \
bttv-risc.o bttv-vbi.o bttv-i2c.o bttv-gpio.o \
- bttv-input.o bttv-audio-hook.o
+ bttv-input.o bttv-audio-hook.o btcx-risc.o
obj-$(CONFIG_VIDEO_BT848) += bttv.o
obj-$(CONFIG_DVB_BT8XX) += bt878.o dvb-bt8xx.o dst.o dst_ca.o
diff --git a/drivers/media/common/btcx-risc.c
b/drivers/media/pci/bt8xx/btcx-risc.c
similarity index 90%
rename from drivers/media/common/btcx-risc.c
rename to drivers/media/pci/bt8xx/btcx-risc.c
index ac1b268..00f0880 100644
--- a/drivers/media/common/btcx-risc.c
+++ b/drivers/media/pci/bt8xx/btcx-risc.c
@@ -32,13 +32,9 @@
#include btcx-risc.h
-MODULE_DESCRIPTION(some code shared by bttv and cx88xx drivers);
-MODULE_AUTHOR(Gerd Knorr);
-MODULE_LICENSE(GPL);
-
-static unsigned int debug;
-module_param(debug, int, 0644);
-MODULE_PARM_DESC(debug,debug messages, default is 0 (no));
+static unsigned int btcx_debug;
+module_param(btcx_debug, int, 0644);
+MODULE_PARM_DESC(btcx_debug,debug messages, default is 0 (no));
/* -- */
/* allocate/free risc memory */
@@ -50,7 +46,7 @@ void btcx_riscmem_free(struct pci_dev *pci,
{
if (NULL == risc-cpu)
return;
- if (debug) {
+ if (btcx_debug) {
memcnt--;
printk(btcx: riscmem free [%d] dma=%lx\n,
memcnt, (unsigned long)risc-dma);
@@ -75,7 +71,7 @@ int btcx_riscmem_alloc(struct pci_dev *pci,
risc-cpu = cpu;
risc-dma = dma;
risc-size = size;
- if (debug) {
+ if (btcx_debug) {
memcnt++;
printk(btcx: riscmem alloc [%d] dma=%lx cpu=%p
size=%d\n,
memcnt, (unsigned long)dma, cpu, size);
@@ -141,7 +137,7 @@ btcx_align(struct v4l2_rect *win, struct v4l2_clip *clips,
unsigned int n, int m
dx = nx - win-left;
win-left = nx;
win-width = nw;
- if (debug)
+ if (btcx_debug)
printk(KERN_DEBUG btcx: window align %dx%d+%d+%d [dx=%d]\n,
win-width, win-height, win-left, win-top, dx);
@@ -153,7 +149,7 @@ btcx_align(struct v4l2_rect *win, struct v4l2_clip *clips,
unsigned int n, int m
nw += mask+1;
clips[i].c.left = nx;
clips[i].c.width = nw;
- if (debug)
+ if (btcx_debug)
printk(KERN_DEBUG btcx:
[PATCH 6/7] cx25821: add create_bufs support
From: Hans Verkuil hans.verk...@cisco.com
Add support for the VIDIOC_CREATE_BUFS ioctl. This was missing in this
driver and in vb2 it's trivial to add.
Signed-off-by: Hans Verkuil hans.verk...@cisco.com
---
drivers/media/pci/cx25821/cx25821-video.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/drivers/media/pci/cx25821/cx25821-video.c
b/drivers/media/pci/cx25821/cx25821-video.c
index 3497946..827c3c0 100644
--- a/drivers/media/pci/cx25821/cx25821-video.c
+++ b/drivers/media/pci/cx25821/cx25821-video.c
@@ -146,9 +146,13 @@ static int cx25821_queue_setup(struct vb2_queue *q, const
struct v4l2_format *fm
unsigned int sizes[], void *alloc_ctxs[])
{
struct cx25821_channel *chan = q-drv_priv;
+ unsigned size = (chan-fmt-depth * chan-width * chan-height) 3;
+
+ if (fmt fmt-fmt.pix.sizeimage size)
+ return -EINVAL;
*num_planes = 1;
- sizes[0] = (chan-fmt-depth * chan-width * chan-height) 3;
+ sizes[0] = fmt ? fmt-fmt.pix.sizeimage : size;
alloc_ctxs[0] = chan-dev-alloc_ctx;
return 0;
}
@@ -610,6 +614,7 @@ static const struct v4l2_ioctl_ops video_ioctl_ops = {
.vidioc_s_fmt_vid_cap = vidioc_s_fmt_vid_cap,
.vidioc_reqbufs = vb2_ioctl_reqbufs,
.vidioc_prepare_buf = vb2_ioctl_prepare_buf,
+ .vidioc_create_bufs = vb2_ioctl_create_bufs,
.vidioc_querybuf = vb2_ioctl_querybuf,
.vidioc_qbuf = vb2_ioctl_qbuf,
.vidioc_dqbuf = vb2_ioctl_dqbuf,
--
2.1.3
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 2/8] v4l2-subdev: drop get/set_crop pad ops
On Thu, Dec 04, 2014 at 10:54:53AM +0100, Hans Verkuil wrote: From: Hans Verkuil hans.verk...@cisco.com Drop the duplicate get/set_crop pad ops and only use get/set_selection. It makes no sense to have two duplicate ops in the internal subdev API. Signed-off-by: Hans Verkuil hans.verk...@cisco.com Acked-by: Laurent Pinchart laurent.pinch...@ideasonboard.com Acked-by: Sakari Ailus sakari.ai...@linux.intel.com -- Sakari Ailus e-mail: sakari.ai...@iki.fi XMPP: sai...@retiisi.org.uk -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 7/7] cx25821: remove video output support
From: Hans Verkuil hans.verk...@cisco.com
The video output functionality never worked for this driver. Now remove the
creation of the output video nodes as well to prevent users from thinking
that video output is available, when it isn't.
To correctly implement this the video output should use vb2 as well, and
that requires rewriting the output DMA setup. But without hardware to test
I am not able to do that.
Signed-off-by: Hans Verkuil hans.verk...@cisco.com
---
drivers/media/pci/cx25821/Makefile| 2 +-
drivers/media/pci/cx25821/cx25821-core.c | 6 +-
drivers/media/pci/cx25821/cx25821-video.c | 2 +-
drivers/media/pci/cx25821/cx25821.h | 7 +++
4 files changed, 14 insertions(+), 3 deletions(-)
diff --git a/drivers/media/pci/cx25821/Makefile
b/drivers/media/pci/cx25821/Makefile
index 5872feb..c8f8598 100644
--- a/drivers/media/pci/cx25821/Makefile
+++ b/drivers/media/pci/cx25821/Makefile
@@ -1,6 +1,6 @@
cx25821-y := cx25821-core.o cx25821-cards.o cx25821-i2c.o \
cx25821-gpio.o cx25821-medusa-video.o \
- cx25821-video.o cx25821-video-upstream.o
+ cx25821-video.o
obj-$(CONFIG_VIDEO_CX25821) += cx25821.o
obj-$(CONFIG_VIDEO_CX25821_ALSA) += cx25821-alsa.o
diff --git a/drivers/media/pci/cx25821/cx25821-core.c
b/drivers/media/pci/cx25821/cx25821-core.c
index c1ea24e..559f829 100644
--- a/drivers/media/pci/cx25821/cx25821-core.c
+++ b/drivers/media/pci/cx25821/cx25821-core.c
@@ -965,11 +965,15 @@ void cx25821_dev_unregister(struct cx25821_dev *dev)
release_mem_region(dev-base_io_addr, pci_resource_len(dev-pci, 0));
- for (i = 0; i MAX_VID_CHANNEL_NUM - 1; i++) {
+ for (i = 0; i MAX_VID_CAP_CHANNEL_NUM - 1; i++) {
if (i == SRAM_CH08) /* audio channel */
continue;
+ /*
+* TODO: enable when video output is properly
+* supported.
if (i == SRAM_CH09 || i == SRAM_CH10)
cx25821_free_mem_upstream(dev-channels[i]);
+*/
cx25821_video_unregister(dev, i);
}
diff --git a/drivers/media/pci/cx25821/cx25821-video.c
b/drivers/media/pci/cx25821/cx25821-video.c
index 827c3c0..7bc495e 100644
--- a/drivers/media/pci/cx25821/cx25821-video.c
+++ b/drivers/media/pci/cx25821/cx25821-video.c
@@ -692,7 +692,7 @@ int cx25821_video_register(struct cx25821_dev *dev)
spin_lock_init(dev-slock);
- for (i = 0; i MAX_VID_CHANNEL_NUM - 1; ++i) {
+ for (i = 0; i MAX_VID_CAP_CHANNEL_NUM - 1; ++i) {
struct cx25821_channel *chan = dev-channels[i];
struct video_device *vdev = chan-vdev;
struct v4l2_ctrl_handler *hdl = chan-hdl;
diff --git a/drivers/media/pci/cx25821/cx25821.h
b/drivers/media/pci/cx25821/cx25821.h
index 34c5ff1..d81a08a 100644
--- a/drivers/media/pci/cx25821/cx25821.h
+++ b/drivers/media/pci/cx25821/cx25821.h
@@ -88,6 +88,13 @@
#define CX25821_BOARD_CONEXANT_ATHENA10 1
#define MAX_VID_CHANNEL_NUM 12
+
+/*
+ * Maximum capture-only channels. This can go away once video/audio output
+ * is fully supported in this driver.
+ */
+#define MAX_VID_CAP_CHANNEL_NUM 10
+
#define VID_CHANNEL_NUM 8
struct cx25821_fmt {
--
2.1.3
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/7] cx231xx: remove btcx_riscmem reference
From: Hans Verkuil hans.verk...@cisco.com
Remove this comment block, it's unused. This removes the btcx_riscmem
reference as well, since that will no longer be available to other
drivers except bttv.
Signed-off-by: Hans Verkuil hans.verk...@cisco.com
---
drivers/media/usb/cx231xx/cx231xx.h | 10 +-
1 file changed, 1 insertion(+), 9 deletions(-)
diff --git a/drivers/media/usb/cx231xx/cx231xx.h
b/drivers/media/usb/cx231xx/cx231xx.h
index f9e262eb..6d6f3ee 100644
--- a/drivers/media/usb/cx231xx/cx231xx.h
+++ b/drivers/media/usb/cx231xx/cx231xx.h
@@ -532,15 +532,7 @@ struct cx231xx_video_mode {
unsigned int *alt_max_pkt_size; /* array of wMaxPacketSize */
u16 end_point_addr;
};
-/*
-struct cx23885_dmaqueue {
- struct list_head active;
- struct list_head queued;
- struct timer_list timeout;
- struct btcx_riscmemstopper;
- u32count;
-};
-*/
+
struct cx231xx_tsport {
struct cx231xx *dev;
--
2.1.3
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/7] cx25821: remove bogus btcx_risc dependency
From: Hans Verkuil hans.verk...@cisco.com
Those btcx_risc functions are meant for use with bttv, other drivers
should just allocate the memory themselves.
Signed-off-by: Hans Verkuil hans.verk...@cisco.com
---
drivers/media/pci/cx25821/Kconfig | 1 -
drivers/media/pci/cx25821/Makefile| 1 -
drivers/media/pci/cx25821/cx25821-alsa.c | 6 --
drivers/media/pci/cx25821/cx25821-core.c | 36 +--
drivers/media/pci/cx25821/cx25821-video.c | 6 --
drivers/media/pci/cx25821/cx25821.h | 21 --
6 files changed, 52 insertions(+), 19 deletions(-)
diff --git a/drivers/media/pci/cx25821/Kconfig
b/drivers/media/pci/cx25821/Kconfig
index 6439a84..0e69cab 100644
--- a/drivers/media/pci/cx25821/Kconfig
+++ b/drivers/media/pci/cx25821/Kconfig
@@ -2,7 +2,6 @@ config VIDEO_CX25821
tristate Conexant cx25821 support
depends on VIDEO_DEV PCI I2C
select I2C_ALGOBIT
- select VIDEO_BTCX
select VIDEOBUF_DMA_SG
---help---
This is a video4linux driver for Conexant 25821 based
diff --git a/drivers/media/pci/cx25821/Makefile
b/drivers/media/pci/cx25821/Makefile
index fb76c3d..5872feb 100644
--- a/drivers/media/pci/cx25821/Makefile
+++ b/drivers/media/pci/cx25821/Makefile
@@ -6,4 +6,3 @@ obj-$(CONFIG_VIDEO_CX25821) += cx25821.o
obj-$(CONFIG_VIDEO_CX25821_ALSA) += cx25821-alsa.o
ccflags-y += -Idrivers/media/i2c
-ccflags-y += -Idrivers/media/common
diff --git a/drivers/media/pci/cx25821/cx25821-alsa.c
b/drivers/media/pci/cx25821/cx25821-alsa.c
index 2dd5bca..27e6493 100644
--- a/drivers/media/pci/cx25821/cx25821-alsa.c
+++ b/drivers/media/pci/cx25821/cx25821-alsa.c
@@ -63,7 +63,7 @@ static int devno;
struct cx25821_audio_buffer {
unsigned int bpl;
- struct btcx_riscmem risc;
+ struct cx25821_riscmem risc;
struct videobuf_dmabuf dma;
};
@@ -330,12 +330,14 @@ out:
static int dsp_buffer_free(struct cx25821_audio_dev *chip)
{
+ struct cx25821_riscmem *risc = chip-buf-risc;
+
BUG_ON(!chip-dma_size);
dprintk(2, Freeing buffer\n);
videobuf_dma_unmap(chip-pci-dev, chip-dma_risc);
videobuf_dma_free(chip-dma_risc);
- btcx_riscmem_free(chip-pci, chip-buf-risc);
+ pci_free_consistent(chip-pci, risc-size, risc-cpu, risc-dma);
kfree(chip-buf);
chip-dma_risc = NULL;
diff --git a/drivers/media/pci/cx25821/cx25821-core.c
b/drivers/media/pci/cx25821/cx25821-core.c
index 389fffd..c8c65b7 100644
--- a/drivers/media/pci/cx25821/cx25821-core.c
+++ b/drivers/media/pci/cx25821/cx25821-core.c
@@ -979,6 +979,27 @@ void cx25821_dev_unregister(struct cx25821_dev *dev)
}
EXPORT_SYMBOL(cx25821_dev_unregister);
+int cx25821_riscmem_alloc(struct pci_dev *pci,
+ struct cx25821_riscmem *risc,
+ unsigned int size)
+{
+ __le32 *cpu;
+ dma_addr_t dma = 0;
+
+ if (NULL != risc-cpu risc-size size)
+ pci_free_consistent(pci, risc-size, risc-cpu, risc-dma);
+ if (NULL == risc-cpu) {
+ cpu = pci_zalloc_consistent(pci, size, dma);
+ if (NULL == cpu)
+ return -ENOMEM;
+ risc-cpu = cpu;
+ risc-dma = dma;
+ risc-size = size;
+ }
+ return 0;
+}
+EXPORT_SYMBOL(cx25821_riscmem_alloc);
+
static __le32 *cx25821_risc_field(__le32 * rp, struct scatterlist *sglist,
unsigned int offset, u32 sync_line,
unsigned int bpl, unsigned int padding,
@@ -1035,7 +1056,7 @@ static __le32 *cx25821_risc_field(__le32 * rp, struct
scatterlist *sglist,
return rp;
}
-int cx25821_risc_buffer(struct pci_dev *pci, struct btcx_riscmem *risc,
+int cx25821_risc_buffer(struct pci_dev *pci, struct cx25821_riscmem *risc,
struct scatterlist *sglist, unsigned int top_offset,
unsigned int bottom_offset, unsigned int bpl,
unsigned int padding, unsigned int lines)
@@ -1059,7 +1080,7 @@ int cx25821_risc_buffer(struct pci_dev *pci, struct
btcx_riscmem *risc,
instructions = fields * (1 + ((bpl + padding) * lines) / PAGE_SIZE +
lines);
instructions += 2;
- rc = btcx_riscmem_alloc(pci, risc, instructions * 12);
+ rc = cx25821_riscmem_alloc(pci, risc, instructions * 12);
if (rc 0)
return rc;
@@ -1146,7 +1167,7 @@ static __le32 *cx25821_risc_field_audio(__le32 * rp,
struct scatterlist *sglist,
}
int cx25821_risc_databuffer_audio(struct pci_dev *pci,
- struct btcx_riscmem *risc,
+ struct cx25821_riscmem *risc,
struct scatterlist *sglist,
unsigned int bpl,
unsigned int lines, unsigned int lpi)
@@
Re: [PATCH] solo6x10: just pass frame motion flag from hardware, drop additional handling as complicated and unstable
On 11/05/2014 09:11 PM, Andrey Utkin wrote:
Dropping code (introduced in 316d9e84a72069e04e483de0d5934c1d75f6a44c)
which intends to make raising of motion events more smooth(?).
It made motion event never appear in my installation.
That code is complicated, so I couldn't figure out quickly how to fix
it, so dropping it seems better to me.
Another justification is that anyway application would implement
motion signal stabilization if required, it is not necessarily kernel
driver's job.
Signed-off-by: Andrey Utkin andrey.ut...@corp.bluecherry.net
Acked-by: Hans Verkuil hans.verk...@cisco.com
I have tested this and it looks good. I am not sure what problems I had
originally that caused me to write that code, since it is now functioning
as expected.
So you can expect this patch to be part of the next 3.20 pull request I'll
post.
Sorry for the delay.
Regards,
Hans
---
drivers/media/pci/solo6x10/solo6x10-v4l2-enc.c | 30
+-
drivers/media/pci/solo6x10/solo6x10.h | 2 --
2 files changed, 1 insertion(+), 31 deletions(-)
diff --git a/drivers/media/pci/solo6x10/solo6x10-v4l2-enc.c
b/drivers/media/pci/solo6x10/solo6x10-v4l2-enc.c
index 30e09d9..866f7b3 100644
--- a/drivers/media/pci/solo6x10/solo6x10-v4l2-enc.c
+++ b/drivers/media/pci/solo6x10/solo6x10-v4l2-enc.c
@@ -239,8 +239,6 @@ static int solo_enc_on(struct solo_enc_dev *solo_enc)
if (solo_enc-bw_weight solo_dev-enc_bw_remain)
return -EBUSY;
solo_enc-sequence = 0;
- solo_enc-motion_last_state = false;
- solo_enc-frames_since_last_motion = 0;
solo_dev-enc_bw_remain -= solo_enc-bw_weight;
if (solo_enc-type == SOLO_ENC_TYPE_EXT)
@@ -555,36 +553,12 @@ static int solo_enc_fillbuf(struct solo_enc_dev
*solo_enc,
}
if (!ret) {
- bool send_event = false;
-
vb-v4l2_buf.sequence = solo_enc-sequence++;
vb-v4l2_buf.timestamp.tv_sec = vop_sec(vh);
vb-v4l2_buf.timestamp.tv_usec = vop_usec(vh);
/* Check for motion flags */
- if (solo_is_motion_on(solo_enc)) {
- /* It takes a few frames for the hardware to detect
- * motion. Once it does it clears the motion detection
- * register and it takes again a few frames before
- * motion is seen. This means in practice that when the
- * motion field is 1, it will go back to 0 for the next
- * frame. This leads to motion detection event being
- * sent all the time, which is not what we want.
- * Instead wait a few frames before deciding that the
- * motion has halted. After some experimentation it
- * turns out that waiting for 5 frames works well.
- */
- if (enc_buf-motion == 0
- solo_enc-motion_last_state
- solo_enc-frames_since_last_motion++ 5)
- send_event = true;
- else if (enc_buf-motion) {
- solo_enc-frames_since_last_motion = 0;
- send_event = !solo_enc-motion_last_state;
- }
- }
-
- if (send_event) {
+ if (solo_is_motion_on(solo_enc) enc_buf-motion) {
struct v4l2_event ev = {
.type = V4L2_EVENT_MOTION_DET,
.u.motion_det = {
@@ -594,8 +568,6 @@ static int solo_enc_fillbuf(struct solo_enc_dev *solo_enc,
},
};
- solo_enc-motion_last_state = enc_buf-motion;
- solo_enc-frames_since_last_motion = 0;
v4l2_event_queue(solo_enc-vfd, ev);
}
}
diff --git a/drivers/media/pci/solo6x10/solo6x10.h
b/drivers/media/pci/solo6x10/solo6x10.h
index 72017b7..dc503fd 100644
--- a/drivers/media/pci/solo6x10/solo6x10.h
+++ b/drivers/media/pci/solo6x10/solo6x10.h
@@ -159,8 +159,6 @@ struct solo_enc_dev {
u16 motion_thresh;
boolmotion_global;
boolmotion_enabled;
- boolmotion_last_state;
- u8 frames_since_last_motion;
u16 width;
u16 height;
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[GIT FIXES FOR v3.19] Fixes/deprecated drivers
Hi Mauro,
The first 9 patches are all fixes that need to go to kernel 3.19.
The last three patches deprecate drivers. Since I haven't seen a reply from
Ondrej yet regarding the parport drivers, I will leave it up to you whether
you will apply the last patch to 3.19 or not. I pinged him again, so I hope
he'll clarify his email soon.
I am OK with that last one being postponed to 3.20 if there is no alternative.
Regards,
Hans
The following changes since commit 71947828caef0c83d4245f7d1eaddc799b4ff1d1:
[media] mn88473: One function call less in mn88473_init() after error
(2014-12-04 16:00:47 -0200)
are available in the git repository at:
git://linuxtv.org/hverkuil/media_tree.git for-v3.19m
for you to fetch changes up to a7222ae6b6a303aa2377dc0e58fea6715bf41890:
bq/c-qcam, w9966, pms: move to staging in preparation for removal (2014-12-12
14:42:50 +0100)
Hans Verkuil (12):
v4l2-mediabus.h: use two __u16 instead of two __u32
DocBook media: add missing ycbcr_enc and quantization fields
vivid.txt: document new controls
DocBook media: update version number and document changes.
vivid: fix CROP_BOUNDS typo for video output
v4l2-ioctl: WARN_ON if querycap didn't fill device_caps
cx88: add missing alloc_ctx support
cx88: remove leftover start_video_dma() call
MAINTAINERS: vivi - vivid
vino/saa7191: move to staging in preparation for removal
tlg2300: move to staging in preparation for removal
bq/c-qcam, w9966, pms: move to staging in preparation for removal
Documentation/DocBook/media/v4l/compat.xml| 12
Documentation/DocBook/media/v4l/pixfmt.xml| 36
++--
Documentation/DocBook/media/v4l/subdev-formats.xml| 18
+-
Documentation/DocBook/media/v4l/v4l2.xml | 11 ++-
Documentation/video4linux/vivid.txt | 15 +++
MAINTAINERS | 4 ++--
drivers/media/Kconfig | 1 -
drivers/media/Makefile| 2 +-
drivers/media/i2c/Kconfig | 9 -
drivers/media/i2c/Makefile| 1 -
drivers/media/pci/cx88/cx88-blackbird.c | 4 +---
drivers/media/pci/cx88/cx88-dvb.c | 4 +---
drivers/media/pci/cx88/cx88-mpeg.c| 11 +++
drivers/media/pci/cx88/cx88-vbi.c | 9 +
drivers/media/pci/cx88/cx88-video.c | 18
+-
drivers/media/pci/cx88/cx88.h | 2 ++
drivers/media/platform/Kconfig| 8
drivers/media/platform/Makefile | 3 ---
drivers/media/platform/vivid/vivid-vid-out.c | 2 +-
drivers/media/usb/Kconfig | 1 -
drivers/media/usb/Makefile| 1 -
drivers/media/v4l2-core/v4l2-ioctl.c | 6 ++
drivers/staging/media/Kconfig | 6 ++
drivers/staging/media/Makefile| 3 +++
drivers/{ = staging}/media/parport/Kconfig | 24
drivers/{ = staging}/media/parport/Makefile | 0
drivers/{ = staging}/media/parport/bw-qcam.c | 0
drivers/{ = staging}/media/parport/c-qcam.c | 0
drivers/{ = staging}/media/parport/pms.c | 0
drivers/{ = staging}/media/parport/w9966.c | 0
drivers/{media/usb = staging/media}/tlg2300/Kconfig | 6 +-
drivers/{media/usb = staging/media}/tlg2300/Makefile | 0
drivers/{media/usb = staging/media}/tlg2300/pd-alsa.c| 0
drivers/{media/usb = staging/media}/tlg2300/pd-common.h | 0
drivers/{media/usb = staging/media}/tlg2300/pd-dvb.c | 0
drivers/{media/usb = staging/media}/tlg2300/pd-main.c| 0
drivers/{media/usb = staging/media}/tlg2300/pd-radio.c | 0
drivers/{media/usb = staging/media}/tlg2300/pd-video.c | 0
drivers/{media/usb = staging/media}/tlg2300/vendorcmds.h | 0
drivers/staging/media/vino/Kconfig| 24
drivers/staging/media/vino/Makefile | 3 +++
drivers/{media/platform = staging/media/vino}/indycam.c | 0
drivers/{media/platform = staging/media/vino}/indycam.h | 0
drivers/{media/i2c = staging/media/vino}/saa7191.c | 0
drivers/{media/i2c = staging/media/vino}/saa7191.h | 0
drivers/{media/platform = staging/media/vino}/vino.c | 0
drivers/{media/platform = staging/media/vino}/vino.h | 0
include/uapi/linux/v4l2-mediabus.h| 6 +++---
48 files changed, 183
Re: [PATCH] solo6x10: just pass frame motion flag from hardware, drop additional handling as complicated and unstable
On Fri, Dec 12, 2014 at 3:30 PM, Hans Verkuil hverk...@xs4all.nl wrote: Acked-by: Hans Verkuil hans.verk...@cisco.com I have tested this and it looks good. I am not sure what problems I had originally that caused me to write that code, since it is now functioning as expected. So you can expect this patch to be part of the next 3.20 pull request I'll post. Sorry for the delay. Thanks. -- Bluecherry developer. -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 3/5] rc: img-ir: biphase enabled with workaround
On 12/12/14 12:07, James Hogan wrote: Hi Sifan, On 11/12/14 20:06, Sifan Naeem wrote: Biphase decoding in the current img-ir has got a quirk, where multiple Interrupts are generated when an incomplete IR code is received by the decoder. Patch adds a work around for the quirk and enables biphase decoding. Changes from v1: * rebased due to conflict with img-ir/hw: Fix potential deadlock stopping timer * spinlock taken in img_ir_suspend_timer * check for hw-stopping before handling quirks in img_ir_isr_hw * new memeber added to img_ir_priv_hw to save irq status over suspend For future reference, the list of changes between patchset versions is usually put after a --- so that it doesn't get included in the final git commit message. You can also add any Acked-by/Reviewed-by tags you've been given to new versions of patchset, assuming nothing significant has changed in that patch (maintainers generally add relevant tags for you, that are sent in response to the patches being applied). Anyway, the whole patchset looks okay to me, aside from the one question I just asked on patch 3 of v1, which I'm not so sure about. I'll let you decide whether that needs changing since you have the hardware to verify it. So for the whole patchset feel free to add my: Acked-by: James Hogan james.ho...@imgtec.com Mauro: Assuming no other changes are requested in this patchset, do you want these resent with the moving of changelogs out of the main commit messages? Cheers James signature.asc Description: OpenPGP digital signature
Re: [PATCH 0/3] Deprecate drivers
On Wednesday 10 December 2014, Hans Verkuil wrote: On 12/02/14 23:42, Ondrej Zary wrote: On Tuesday 02 December 2014 16:40:30 Hans Verkuil wrote: This patch series deprecates the vino/saa7191 video driver (ancient SGI Indy computer), the parallel port webcams bw-qcam, c-qcam and w9966, the ISA video capture driver pms and the USB video capture tlg2300 driver. Hardware for these devices is next to impossible to obtain, these drivers haven't seen any development in ages, they often use deprecated APIs and without hardware that's very difficult to port. And cheap alternative products are easily available today. Just bought a QuickCam Pro parallel and some unknown parallel port webcam. Will you accept patches? :) OK, so there is some confusion here. You aren't offering to work on any of the deprecated drivers, are you? I'm sure you meant this email as a joke, but before the drivers are deprecated it is good to get that confirmed. (Sorry for the delay, I somehow missed this e-mail.) I'll try to fix c-qcam driver (I suppose that it should work with QuickCam Pro). The webcams are still on the way so I don't know what's inside the unknown one. -- Ondrej Zary -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/3] Deprecate drivers
On 12/12/2014 03:29 PM, Ondrej Zary wrote: On Wednesday 10 December 2014, Hans Verkuil wrote: On 12/02/14 23:42, Ondrej Zary wrote: On Tuesday 02 December 2014 16:40:30 Hans Verkuil wrote: This patch series deprecates the vino/saa7191 video driver (ancient SGI Indy computer), the parallel port webcams bw-qcam, c-qcam and w9966, the ISA video capture driver pms and the USB video capture tlg2300 driver. Hardware for these devices is next to impossible to obtain, these drivers haven't seen any development in ages, they often use deprecated APIs and without hardware that's very difficult to port. And cheap alternative products are easily available today. Just bought a QuickCam Pro parallel and some unknown parallel port webcam. Will you accept patches? :) OK, so there is some confusion here. You aren't offering to work on any of the deprecated drivers, are you? I'm sure you meant this email as a joke, but before the drivers are deprecated it is good to get that confirmed. (Sorry for the delay, I somehow missed this e-mail.) I'll try to fix c-qcam driver (I suppose that it should work with QuickCam Pro). The webcams are still on the way so I don't know what's inside the unknown one. I'm pretty sure the QuickCam Pro won't work with the c-qcam driver, but I'll postpone moving these drivers to staging for the moment. Regards, Hans -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [REVIEW] au0828-vbi.c
On 12/12/2014 02:42 AM, Hans Verkuil wrote:
Hi Shuah,
This is my review for au0828-vbi.c with your patch applied.
Thanks. Will fix all of these.
-- Shuah
/*
au0828-vbi.c - VBI driver for au0828
Copyright (C) 2010 Devin Heitmueller dheitmuel...@kernellabs.com
This work was sponsored by GetWellNetwork Inc.
This program is free software; you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
the Free Software Foundation; either version 2 of the License, or
(at your option) any later version.
This program is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
GNU General Public License for more details.
You should have received a copy of the GNU General Public License
along with this program; if not, write to the Free Software
Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA
02110-1301, USA.
*/
#include au0828.h
#include linux/kernel.h
#include linux/module.h
#include linux/init.h
#include linux/slab.h
static unsigned int vbibufs = 5;
module_param(vbibufs, int, 0644);
MODULE_PARM_DESC(vbibufs, number of vbi buffers, range 2-32);
Drop this vbibufs argument. It's bogus.
/* -- */
static int vbi_queue_setup(struct vb2_queue *vq, const struct v4l2_format
*fmt,
unsigned int *nbuffers, unsigned int *nplanes,
unsigned int sizes[], void *alloc_ctxs[])
{
struct au0828_dev *dev = vb2_get_drv_priv(vq);
unsigned long size;
if (fmt)
size = fmt-fmt.pix.sizeimage;
It's a VBI format, so the size is
fmt-fmt.vbi.samples_per_line *
(fmt-fmt.vbi.count[0] + fmt-fmt.vbi.count[1]);
else
size = dev-vbi_width * dev-vbi_height * 2;
if (0 == *nbuffers)
*nbuffers = 32;
if (*nbuffers 2)
*nbuffers = 2;
if (*nbuffers 32)
*nbuffers = 32;
Remove these checks, they are not needed.
But if a fmt is passed in, then you *do* need to check if the new format size
is enough to store the vbi data. If not, return -EINVAL.
Test with v4l2-compliance -V0 -s.
*nplanes = 1;
sizes[0] = size;
return 0;
}
static int vbi_buffer_prepare(struct vb2_buffer *vb)
{
struct au0828_dev *dev = vb2_get_drv_priv(vb-vb2_queue);
struct au0828_buffer *buf = container_of(vb, struct au0828_buffer, vb);
unsigned long size;
size = dev-vbi_width * dev-vbi_height * 2;
if (vb2_plane_size(vb, 0) size) {
pr_err(%s data will not fit into plane (%lu %lu)\n,
__func__, vb2_plane_size(vb, 0), size);
return -EINVAL;
}
vb2_set_plane_payload(buf-vb, 0, size);
return 0;
}
static void
vbi_buffer_queue(struct vb2_buffer *vb)
{
struct au0828_dev *dev = vb2_get_drv_priv(vb-vb2_queue);
struct au0828_buffer *buf = container_of(vb, struct au0828_buffer, vb);
struct au0828_dmaqueue *vbiq = dev-vbiq;
unsigned long flags = 0;
buf-mem = vb2_plane_vaddr(vb, 0);
buf-length = vb2_plane_size(vb, 0);
spin_lock_irqsave(dev-slock, flags);
list_add_tail(buf-list, vbiq-active);
spin_unlock_irqrestore(dev-slock, flags);
}
struct vb2_ops au0828_vbi_qops = {
.queue_setup = vbi_queue_setup,
.buf_prepare = vbi_buffer_prepare,
.buf_queue = vbi_buffer_queue,
.start_streaming = au0828_start_analog_streaming,
.stop_streaming = au0828_stop_vbi_streaming,
.wait_prepare= vb2_ops_wait_prepare,
.wait_finish = vb2_ops_wait_finish,
};
Regards,
Hans
--
Shuah Khan
Sr. Linux Kernel Developer
Samsung Open Source Group
Samsung Research America (Silicon Valley)
shua...@osg.samsung.com | (970) 217-8978
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [REVIEW] au0828-video.c
Hi Hans,
Thanks for a quick review.
On 12/12/2014 03:16 AM, Hans Verkuil wrote:
Hi Shuah,
This is the video.c review with your patch applied.
/*
* Auvitek AU0828 USB Bridge (Analog video support)
*
* Copyright (C) 2009 Devin Heitmueller dheitmuel...@linuxtv.org
* Copyright (C) 2005-2008 Auvitek International, Ltd.
*
* This program is free software; you can redistribute it and/or
* modify it under the terms of the GNU General Public License
* As published by the Free Software Foundation; either version 2
* of the License, or (at your option) any later version.
*
* This program is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
* GNU General Public License for more details.
*
* You should have received a copy of the GNU General Public License
* along with this program; if not, write to the Free Software
* Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA
* 02110-1301, USA.
*/
/* Developer Notes:
*
* VBI support is not yet working
I'll see if I can get this to work quickly. If not, then we should
probably just strip the VBI support from this driver. It's pointless to
have non-functioning VBI support.
* The hardware scaler supported is unimplemented
* AC97 audio support is unimplemented (only i2s audio mode)
*
*/
#include au0828.h
#include linux/module.h
#include linux/slab.h
#include linux/init.h
#include linux/device.h
#include media/v4l2-common.h
#include media/v4l2-ioctl.h
#include media/v4l2-event.h
#include media/tuner.h
#include au0828-reg.h
snip
static int queue_setup(struct vb2_queue *vq, const struct v4l2_format *fmt,
unsigned int *nbuffers, unsigned int *nplanes,
unsigned int sizes[], void *alloc_ctxs[])
{
struct au0828_dev *dev = vb2_get_drv_priv(vq);
unsigned long size;
if (fmt)
size = fmt-fmt.pix.sizeimage;
else
size =
(dev-width * dev-height * dev-bytesperline + 7) 3;
This is wrong. It should be 'size = dev-bytesperline * dev-height;'
Will fix it.
If fmt is set, then you need to check if the fmt size is large enough for
the current format.
if (size == 0)
This should be 'size img_size'.
return -EINVAL;
if (0 == *nbuffers)
*nbuffers = 32;
Bogus check.
Will fix it.
*nplanes = 1;
sizes[0] = size;
return 0;
}
I would rewrite this function as:
{
struct au0828_dev *dev = vb2_get_drv_priv(vq);
unsigned img_size = dev-bytesperline * dev-height;
unsigned long size;
size = fmt ? fmt-fmt.pix.sizeimage : img_size;
if (size img_size)
return -EINVAL;
*nplanes = 1;
sizes[0] = size;
return 0;
}
That simplifies it a lot.
static int
buffer_prepare(struct vb2_buffer *vb)
{
struct au0828_buffer *buf = container_of(vb, struct au0828_buffer, vb);
struct au0828_dev*dev = vb2_get_drv_priv(vb-vb2_queue);
buf-length = (dev-width * dev-height * 16 + 7) 3;
Use buf-length = dev-bytesperline * dev-height;
Yes. Will do.
if (vb2_plane_size(vb, 0) buf-length) {
pr_err(%s data will not fit into plane (%lu %lu)\n,
__func__, vb2_plane_size(vb, 0), buf-length);
return -EINVAL;
}
vb2_set_plane_payload(buf-vb, 0, buf-length);
return 0;
}
static void
buffer_queue(struct vb2_buffer *vb)
{
struct au0828_buffer*buf = container_of(vb,
struct au0828_buffer,
vb);
struct au0828_dev *dev = vb2_get_drv_priv(vb-vb2_queue);
struct au0828_dmaqueue *vidq= dev-vidq;
unsigned long flags = 0;
buf-mem = vb2_plane_vaddr(vb, 0);
buf-length = vb2_plane_size(vb, 0);
spin_lock_irqsave(dev-slock, flags);
list_add_tail(buf-list, vidq-active);
spin_unlock_irqrestore(dev-slock, flags);
}
static int au0828_i2s_init(struct au0828_dev *dev)
{
/* Enable i2s mode */
au0828_writereg(dev, AU0828_AUDIOCTRL_50C, 0x01);
return 0;
}
/*
* Auvitek au0828 analog stream enable
*/
static int au0828_analog_stream_enable(struct au0828_dev *d)
{
struct usb_interface *iface;
int ret, h, w;
dprintk(1, au0828_analog_stream_enable called\n);
iface = usb_ifnum_to_if(d-usbdev, 0);
if (iface iface-cur_altsetting-desc.bAlternateSetting != 5) {
dprintk(1, Changing intf#0 to alt 5\n);
/* set au0828 interface0 to AS5 here again */
ret = usb_set_interface(d-usbdev, 0, 5);
if (ret 0) {
pr_info(Au0828 can't set
Re: [REVIEW] au0828-video.c
On 12/12/2014 08:28 AM, Hans Verkuil wrote: On 12/12/2014 04:26 PM, Shuah Khan wrote: On 12/12/2014 06:14 AM, Mauro Carvalho Chehab wrote: Em Fri, 12 Dec 2014 13:55:14 +0100 Hans Verkuil hverk...@xs4all.nl escreveu: On 12/12/2014 01:49 PM, Mauro Carvalho Chehab wrote: Em Fri, 12 Dec 2014 11:16:01 +0100 Hans Verkuil hverk...@xs4all.nl escreveu: Hi Shuah, This is the video.c review with your patch applied. /* * Auvitek AU0828 USB Bridge (Analog video support) * * Copyright (C) 2009 Devin Heitmueller dheitmuel...@linuxtv.org * Copyright (C) 2005-2008 Auvitek International, Ltd. * * This program is free software; you can redistribute it and/or * modify it under the terms of the GNU General Public License * As published by the Free Software Foundation; either version 2 * of the License, or (at your option) any later version. * * This program is distributed in the hope that it will be useful, * but WITHOUT ANY WARRANTY; without even the implied warranty of * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the * GNU General Public License for more details. * * You should have received a copy of the GNU General Public License * along with this program; if not, write to the Free Software * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA * 02110-1301, USA. */ /* Developer Notes: * * VBI support is not yet working I'll see if I can get this to work quickly. If not, then we should probably just strip the VBI support from this driver. It's pointless to have non-functioning VBI support. This is a left-over. VBI support works on this driver. I tested. Oh wait, now I get it. You are only capturing line 21, not the whole vbi area. That's why vbi_height = 1. Never mind then. Although that comment should indeed be removed. Want me to remove the comment with this work or as a separate patch?? Separate, I think. Probably, the patches that added VBI support forgot to remove the above notice. /* This function ensures that video frames continue to be delivered even if the ITU-656 input isn't receiving any data (thereby preventing applications such as tvtime from hanging) */ Why would tvtime be hanging? Make a separate patch that just removes all this timeout nonsense. If there are no frames, then tvtime (and any other app) should just wait for frames to arrive. And ctrl-C should always be able to break the app (or they can timeout themselves). It's not the driver's responsibility to do this and it only makes the code overly complex. Well, we should not cause regressions on userspace. If removing this check will cause tvtime to hang, we should keep it. Obviously if it hangs (i.e. tvtime can't be killed anymore) it is a bug in the driver. But the driver shouldn't start generating bogus frames just because no new frames are arriving, that's just nuts. If I remember the bug well, what used to happen is that tvtime would wait for a certain amount of time for a frame. If nothing arrives, it stops capturing. The net effect is that tvtime shows no picture. This used to be so bad that tvtime didn't work with vivi at all. The bug used also to manifest there if lots of frames got dropped when, for example, changing from one channel to another. Btw, on a quick look, I'm not seeing any patch at tvtime since we took it over that would be fixing it. So, it was either a VB bug or the bug is still there. Btw, the same kind of test used to be at vivi and other drivers. I think we removed it there some time ago, so maybe either it was a VB1 bug or this got fixed at tvtime. I take it that we decided to keep the timeout handling for now. No, tvtime no longer hangs if no frames arrive, so there is no need for this timeout handling. I'd strip it out, which can be done in a separate patch. Will do. This will reduce the complexity other drives don't have. -- Shuah -- Shuah Khan Sr. Linux Kernel Developer Samsung Open Source Group Samsung Research America (Silicon Valley) shua...@osg.samsung.com | (970) 217-8978 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Help required for TVP5151 on Overo
Hi Laurent, I'll check the patches you indicated on git://linuxtv.org/pinchartl/media.git omap3isp/tvp5151 Which version of the kernel are these patches for? Regards Francesco Il giorno Tue, 02 Dec 2014 01:41:23 +0200 Laurent Pinchart laurent.pinch...@ideasonboard.com ha scritto: Hi Francesco, On Wednesday 19 November 2014 10:33:06 Francesco Marletta wrote: Hi Carlos, thanks for your response. I've read your message on permalink. I'm not sure the ISP is broken, or at least it may be broken but it can be fixed. I'm trying to work the tvp5151 board described in [1], the author states (and told me) that it was successfull in using that board, using a patch that he also publish, but my board is not working (using the same patch set). Maybe there is something different in my kernel, even if the version is the same? For what it's worth, I've successfully used that tvp5151 board with a Gumstix Overo using the mainline kernel. Changes required to the OAMP3 ISP driver have been pushed to mainline. Some changes were required to the tvp5151 driver too, some have made it upstream, but I haven't had time to clean up and submit the rest of the tvp5151 modifications. I've pushed the patches to git://linuxtv.org/pinchartl/media.git omap3isp/tvp5151 I'm going to try applying the patch by hand, to check if there is something different respect the source that the patch is made from. It will be useful to me to have a kernel (with modules) that works with that board, this way I could check if the problem is in the hw or in the sw. I'll continue to try. [1] http://www.sleepyrobot.com/?p=253 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [REVIEW] au0828-video.c
No, tvtime no longer hangs if no frames arrive, so there is no need for this timeout handling. I'd strip it out, which can be done in a separate patch. Did you actually try it? Do you have some patches to tvtime which aren't upstream? I wrote the comment in question (and added the associated code). The issue is that tvtime does *everything* in a single thread (except the recent ALSA audio work), that includes servicing the video/vbi devices as well as the user interface. That thread blocks on a DQBUF ioctl until data arrives, and thus if frames are not being delivered it will hang the entire tvtime user interface. Now you can certainly argue that is a bad design decision, but it's been that way for 15+ years, so we can't break it now. Hence why I generate dummy frames on a timeout if the decoder isn't delivering video. Unfortunately the au8522 doesn't have a free running mode (i.e. blue screen if no video), which is why most of the other devices work fine (decoders by Conexant, NXP, Trident, etc all have such functionality). Don't get me wrong - I *hate* that I had to put that timer crap in the driver, but it was necessary to be compatible with one of the most popular applications out there. In short, that code cannot be removed. Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [REVIEW] au0828-video.c
On 12/12/2014 04:52 PM, Devin Heitmueller wrote: No, tvtime no longer hangs if no frames arrive, so there is no need for this timeout handling. I'd strip it out, which can be done in a separate patch. Did you actually try it? Mauro tried it, not me. I'm not sure if he looked at whether the user interface is blocked when waiting for a frame. Do you have some patches to tvtime which aren't upstream? I wrote the comment in question (and added the associated code). The issue is that tvtime does *everything* in a single thread (except the recent ALSA audio work), that includes servicing the video/vbi devices as well as the user interface. That thread blocks on a DQBUF ioctl until data arrives, and thus if frames are not being delivered it will hang the entire tvtime user interface. Now you can certainly argue that is a bad design decision, but it's been that way for 15+ years, so we can't break it now. Hence why I generate dummy frames on a timeout if the decoder isn't delivering video. Unfortunately the au8522 doesn't have a free running mode (i.e. blue screen if no video), which is why most of the other devices work fine (decoders by Conexant, NXP, Trident, etc all have such functionality). Don't get me wrong - I *hate* that I had to put that timer crap in the driver, but it was necessary to be compatible with one of the most popular applications out there. In short, that code cannot be removed. Sure it can. I just tried tvtime and you are right, it blocks the GUI. But the fix is very easy as well. So now I've updated tvtime so that it timeouts and gives the GUI time to update itself. No more need for such an ugly hack in au0828. The au0828 isn't the only driver that can block, others do as well. Admittedly, they aren't very common, but they do exist. So it is much better to fix the application than adding application workarounds in the kernel. Regards, Hans -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [REVIEW] au0828-video.c
In short, that code cannot be removed. Sure it can. I just tried tvtime and you are right, it blocks the GUI. But the fix is very easy as well. So now I've updated tvtime so that it timeouts and gives the GUI time to update itself. That's a nice change to tvtime and I'm sure it will make it more robust. No more need for such an ugly hack in au0828. The au0828 isn't the only driver that can block, others do as well. Admittedly, they aren't very common, but they do exist. So it is much better to fix the application than adding application workarounds in the kernel. You're breaking the ABI. You're making a change to the kernel that causes existing applications to stop working. Sure you can make the argument that applications probably never should have expected such behavior (even if it's relied on that behavior for 15+ years). And sure, you can make a change to the application in some random git repository that avoids the issue, and that change might get sucked in to the major distributions over the next couple of years. That doesn't change the fact that you're breaking the ABI and everybody who has the existing application that updates their kernel will stop working. Please don't do this. Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] Add LVDS RGB media bus formats
This patch adds three new RGB media bus formats that describe 18-bit or 24-bit samples transferred over an LVDS bus with three or four differential data pairs, serialized into 7 time slots, using standard SPWG/PSWG/VESA or JEIDA data ordering. Signed-off-by: Philipp Zabel p.za...@pengutronix.de --- Documentation/DocBook/media/v4l/subdev-formats.xml | 253 + include/uapi/linux/media-bus-format.h | 5 +- 2 files changed, 257 insertions(+), 1 deletion(-) diff --git a/Documentation/DocBook/media/v4l/subdev-formats.xml b/Documentation/DocBook/media/v4l/subdev-formats.xml index 0d6f731..6d59a0e 100644 --- a/Documentation/DocBook/media/v4l/subdev-formats.xml +++ b/Documentation/DocBook/media/v4l/subdev-formats.xml @@ -89,6 +89,14 @@ constantMEDIA_BUS_FMT_RGB555_2X8_PADHI_BE/constant. /para + paraOn LVDS buses, usually each sample is transferred serialized in seven + time slots per pixel clock, on three (18-bit) or four (24-bit) differential + data pairs at the same time. The remaining bits are used for control signals + as defined by SPWG/PSWG/VESA or JEIDA standards. The 24-bit RGB format serialized + in seven time slots on four lanes using JEIDA defined bit mapping will be + named constantMEDIA_BUS_FMT_RGB888_1X7X3_JEIDA/constant, for example. + /para + paraThe following tables list existing packed RGB formats./para table pgwide=0 frame=none id=v4l2-mbus-pixelcode-rgb @@ -606,6 +614,251 @@ /tbody /tgroup /table + table pgwide=0 frame=none id=v4l2-mbus-pixelcode-rgb-lvds + titleLVDS RGB formats/title + tgroup cols=8 + colspec colname=id align=left / + colspec colname=code align=center / + colspec colname=slot align=center / + colspec colname=lane / + colspec colnum=5 colname=l03 align=center / + colspec colnum=6 colname=l02 align=center / + colspec colnum=7 colname=l01 align=center / + colspec colnum=8 colname=l00 align=center / + spanspec namest=l03 nameend=l00 spanname=l0 / + thead + row + entryIdentifier/entry + entryCode/entry + entry/entry + entry/entry + entry spanname=l0Data organization/entry + /row + row + entry/entry + entry/entry + entryTimeslot/entry + entryLane/entry + entry3/entry + entry2/entry + entry1/entry + entry0/entry + /row + /thead + tbody valign=top + row id=MEDIA-BUS-FMT-RGB666-1X7X3-SPWG + entryMEDIA_BUS_FMT_RGB666_1X7X3_SPWG/entry + entry0x1010/entry + entry0/entry + entry/entry + entry-/entry + entryd/entry + entrybsubscript1/subscript/entry + entrygsubscript0/subscript/entry + /row + row + entry/entry + entry/entry + entry1/entry + entry/entry + entry-/entry + entryd/entry + entrybsubscript0/subscript/entry + entryrsubscript5/subscript/entry + /row + row + entry/entry + entry/entry + entry2/entry + entry/entry + entry-/entry + entryd/entry + entrygsubscript5/subscript/entry + entryrsubscript4/subscript/entry + /row + row + entry/entry + entry/entry + entry3/entry + entry/entry + entry-/entry + entrybsubscript5/subscript/entry + entrygsubscript4/subscript/entry + entryrsubscript3/subscript/entry + /row + row + entry/entry + entry/entry + entry4/entry + entry/entry + entry-/entry + entrybsubscript4/subscript/entry + entrygsubscript3/subscript/entry + entryrsubscript2/subscript/entry + /row + row + entry/entry + entry/entry + entry5/entry + entry/entry + entry-/entry + entrybsubscript3/subscript/entry + entrygsubscript2/subscript/entry + entryrsubscript1/subscript/entry + /row + row + entry/entry + entry/entry + entry6/entry + entry/entry + entry-/entry + entrybsubscript2/subscript/entry + entrygsubscript1/subscript/entry + entryrsubscript0/subscript/entry + /row + row id=MEDIA-BUS-FMT-RGB888-1X7X4-SPWG + entryMEDIA_BUS_FMT_RGB888_1X7X4_SPWG/entry + entry0x1011/entry + entry0/entry + entry/entry +
Re: VPU on iMX51 babbage board
Am Freitag, den 12.12.2014, 10:15 +0100 schrieb Pierluigi Passaro:
On 11/12/2014 15:03, Philipp Zabel wrote:
Am Mittwoch, den 10.12.2014, 22:04 -0200 schrieb Fabio Estevam:
On Wed, Dec 10, 2014 at 7:54 PM, Pierluigi Passaro
pierluigi.pass...@phoenixsoftware.it wrote:
Hi all,
I'm trying to use VPU code driver on iMX51 with kernel 3.18, following
these
steps:
- disabled DVI interface
- enabled LCD interface
- configured and enabled VPU
- copied iMX51 vpu firmware without header and renamed
v4l-coda7541-imx53.bin in /lib/firmware
Attached you can find the patch and the defconfig I used.
The boot process hangs after loading the firmware at the first attempt of
writing in VPU address space in the function coda_write of file
driver/media/platform/coda/coda-common.c
Is there anything preventing the coda driver to work with iMX51?
Could anyone provide any suggestion on how investigate the problem?
I have only tested the coda driver on mx6, but looking at the
mx51.dtsi you would need this:
--- a/arch/arm/boot/dts/imx51.dtsi
+++ b/arch/arm/boot/dts/imx51.dtsi
@@ -121,6 +121,7 @@
iram: iram@1ffe {
compatible = mmio-sram;
reg = 0x1ffe 0x2;
+clocks = clks IMX5_CLK_OCRAM;
};
ipu: ipu@4000 {
@@ -584,6 +585,18 @@
clock-names = ipg, ahb, ptp;
status = disabled;
};
+
+vpu: vpu@83ff4000 {
+compatible = fsl,imx53-vpu;
This should be fsl,imx51-vpu, and add a cnm,codahx14.
According to the old imx-vpu-lib code and the vpu_fw_imx51.bin firmware
file, the i.MX51 has a CodaHx14 (0xF00A) as opposed to the i.MX53's
Coda7541 (0xF012).
Thanks for the hint, I'm now going through the old imx-vpu-lib to
understand the CodaHX14 behaviour.
In old imx-vpu-lib, file vpu_util.c, there is a comment that make me
doubtful: i.MX51 has no secondary AXI memory, but use on chip RAM.
As far as I understood, the portion of coda driver affected from this
comment should be around the function coda_setup_iram in coda-bit.c.
How am I supposed to manage this information?
Have I to avoid to use iram for iMX51 (and return on !dev-iram.vaddr)
or go through the function without managing any CodaHX14 specific behaviour?
I think for CodaHx14 on i.MX51 the CODA7_USE_HOST_xyz_ENABLE bits should
be set in coda_setup_iram, but the CODA7_USE_xyz_ENABLE should not.
regards
Philipp
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [REVIEW] au0828-video.c
Em Fri, 12 Dec 2014 11:46:13 -0500 Devin Heitmueller dheitmuel...@kernellabs.com escreveu: In short, that code cannot be removed. Sure it can. I just tried tvtime and you are right, it blocks the GUI. But the fix is very easy as well. So now I've updated tvtime so that it timeouts and gives the GUI time to update itself. That's a nice change to tvtime and I'm sure it will make it more robust. No more need for such an ugly hack in au0828. The au0828 isn't the only driver that can block, others do as well. Admittedly, they aren't very common, but they do exist. So it is much better to fix the application than adding application workarounds in the kernel. You're breaking the ABI. You're making a change to the kernel that causes existing applications to stop working. Sure you can make the argument that applications probably never should have expected such behavior (even if it's relied on that behavior for 15+ years). And sure, you can make a change to the application in some random git repository that avoids the issue, and that change might get sucked in to the major distributions over the next couple of years. That doesn't change the fact that you're breaking the ABI and everybody who has the existing application that updates their kernel will stop working. Please don't do this. I agree. We should not break the ABI, except if we're 100% sure that all apps that rely on the old behavior got fixed at the distros. That means that we'll need to keep holding such timeout code for years, until all distros update to a new tvtime, of course assuming that this is the only one application with such issue. With regards to tvtime, I think we need to bump version there and update it at the distros. I added myself a few patches today, in order to fix it to work with vivid driver on webcam mode. My proposal is to wait for one extra week for people to review it. As we've discussed on IRC channel, it would be good to add support for format enumeration on it, but the changes don't seem to be trivial. I'm not willing to do it, due to my lack of time, but, if someone steps up for doing that, then we can wait for those patches before bumping the version. In anycase, if everything is ok after ~1 week of waiting for tests, we can bump to version 1.0.5 and I can port the latest version to Fedora. I dunno who maintains it on other distros. Regards, Mauro -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [REVIEW] au0828-video.c
As we've discussed on IRC channel, it would be good to add support for format enumeration on it, but the changes don't seem to be trivial. I'm not willing to do it, due to my lack of time, but, if someone steps up for doing that, then we can wait for those patches before bumping the version. I agree that format enumeration will be a PITA - I looked at doing it myself a couple of years ago. Much of the problems are related to limitations in the home-grown widget toolkit that tvtime uses. I've also got patches to support HD resolutions (i.e. HDMI capture) which we use internally, but haven't felt they were worthwhile to upstream since they don't depend on the ENUM_FRAMESIZES/FRAMEINTERVALS. If somebody feels the urge to put some time into it, I can make available the patches. Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/4] mn88472: elaborate debug printout
Signed-off-by: Benjamin Larsson benja...@southpole.se --- drivers/staging/media/mn88472/mn88472.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/drivers/staging/media/mn88472/mn88472.c b/drivers/staging/media/mn88472/mn88472.c index 4d80046..746cc94 100644 --- a/drivers/staging/media/mn88472/mn88472.c +++ b/drivers/staging/media/mn88472/mn88472.c @@ -33,6 +33,7 @@ static int mn88472_set_frontend(struct dvb_frontend *fe) u64 tmp; u8 delivery_system_val, if_val[3], bw_val[7], bw_val2; + dev_dbg(client-dev, %s:\n, __func__); dev_dbg(client-dev, delivery_system=%d modulation=%d frequency=%d symbol_rate=%d inversion=%d\n, c-delivery_system, c-modulation, @@ -288,7 +289,7 @@ static int mn88472_init(struct dvb_frontend *fe) u8 *fw_file = MN88472_FIRMWARE; unsigned int csum; - dev_dbg(client-dev, \n); + dev_dbg(client-dev, %s:\n, __func__); /* set cold state by default */ dev-warm = false; @@ -371,7 +372,7 @@ static int mn88472_sleep(struct dvb_frontend *fe) struct mn88472_dev *dev = i2c_get_clientdata(client); int ret; - dev_dbg(client-dev, \n); + dev_dbg(client-dev, %s:\n, __func__); /* power off */ ret = regmap_write(dev-regmap[2], 0x0b, 0x30); -- 1.9.1 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/4] mn88472: implement dvb-t signal lock
Signed-off-by: Benjamin Larsson benja...@southpole.se
---
drivers/staging/media/mn88472/mn88472.c | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/drivers/staging/media/mn88472/mn88472.c
b/drivers/staging/media/mn88472/mn88472.c
index 107552a..4d80046 100644
--- a/drivers/staging/media/mn88472/mn88472.c
+++ b/drivers/staging/media/mn88472/mn88472.c
@@ -238,6 +238,7 @@ static int mn88472_read_status(struct dvb_frontend *fe,
fe_status_t *status)
struct dtv_frontend_properties *c = fe-dtv_property_cache;
int ret;
unsigned int utmp;
+ int lock = 0;
*status = 0;
@@ -248,6 +249,12 @@ static int mn88472_read_status(struct dvb_frontend *fe,
fe_status_t *status)
switch (c-delivery_system) {
case SYS_DVBT:
+ ret = regmap_read(dev-regmap[0], 0x7F, utmp);
+ if (ret)
+ goto err;
+ if ((utmp0xF) 8)
+ lock = 1;
+ break;
case SYS_DVBT2:
/* FIXME: implement me */
utmp = 0x08; /* DVB-C lock value */
@@ -262,7 +269,7 @@ static int mn88472_read_status(struct dvb_frontend *fe,
fe_status_t *status)
goto err;
}
- if (utmp == 0x08)
+ if (lock)
*status = FE_HAS_SIGNAL | FE_HAS_CARRIER | FE_HAS_VITERBI |
FE_HAS_SYNC | FE_HAS_LOCK;
--
1.9.1
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/4] rtl28xxu: swap frontend order for devices with slave demodulators
Signed-off-by: Benjamin Larsson benja...@southpole.se
---
drivers/media/usb/dvb-usb-v2/rtl28xxu.c | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/drivers/media/usb/dvb-usb-v2/rtl28xxu.c
b/drivers/media/usb/dvb-usb-v2/rtl28xxu.c
index ab48b5f..cdc342a 100644
--- a/drivers/media/usb/dvb-usb-v2/rtl28xxu.c
+++ b/drivers/media/usb/dvb-usb-v2/rtl28xxu.c
@@ -863,6 +863,7 @@ static int rtl2832u_frontend_attach(struct dvb_usb_adapter
*adap)
/* attach slave demodulator */
if (priv-slave_demod == SLAVE_DEMOD_MN88472) {
+ struct dvb_frontend *tmp_fe;
struct mn88472_config mn88472_config = {};
mn88472_config.fe = adap-fe[1];
@@ -887,6 +888,12 @@ static int rtl2832u_frontend_attach(struct dvb_usb_adapter
*adap)
}
priv-i2c_client_slave_demod = client;
+
+ /* Swap frontend order */
+ tmp_fe = adap-fe[0];
+ adap-fe[0] = adap-fe[1];
+ adap-fe[1] = tmp_fe;
+
} else {
struct mn88473_config mn88473_config = {};
@@ -1373,7 +1380,7 @@ static int rtl2832u_frontend_ctrl(struct dvb_frontend
*fe, int onoff)
/* bypass slave demod TS through master demod */
if (fe-id == 1 onoff) {
- ret = rtl2832_enable_external_ts_if(adap-fe[0]);
+ ret = rtl2832_enable_external_ts_if(adap-fe[1]);
if (ret)
goto err;
}
--
1.9.1
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
cron job: media_tree daily build: OK
This message is generated daily by a cron job that builds media_tree for the kernels and architectures in the list below. Results of the daily build of media_tree: date: Sat Dec 13 04:00:22 CET 2014 git branch: test git hash: e272d95f8c0544cff55c485a10828b063c8e417c gcc version:i686-linux-gcc (GCC) 4.9.1 sparse version: v0.5.0-41-g6c2d743 smatch version: 0.4.1-3153-g7d56ab3 host hardware: x86_64 host os:3.17-3.slh.2-amd64 linux-git-arm-at91: OK linux-git-arm-davinci: OK linux-git-arm-exynos: OK linux-git-arm-mx: OK linux-git-arm-omap: OK linux-git-arm-omap1: OK linux-git-arm-pxa: OK linux-git-blackfin: OK linux-git-i686: OK linux-git-m32r: OK linux-git-mips: OK linux-git-powerpc64: OK linux-git-sh: OK linux-git-x86_64: OK linux-2.6.32.27-i686: OK linux-2.6.33.7-i686: OK linux-2.6.34.7-i686: OK linux-2.6.35.9-i686: OK linux-2.6.36.4-i686: OK linux-2.6.37.6-i686: OK linux-2.6.38.8-i686: OK linux-2.6.39.4-i686: OK linux-3.0.60-i686: OK linux-3.1.10-i686: OK linux-3.2.37-i686: OK linux-3.3.8-i686: OK linux-3.4.27-i686: OK linux-3.5.7-i686: OK linux-3.6.11-i686: OK linux-3.7.4-i686: OK linux-3.8-i686: OK linux-3.9.2-i686: OK linux-3.10.1-i686: OK linux-3.11.1-i686: OK linux-3.12.23-i686: OK linux-3.13.11-i686: OK linux-3.14.9-i686: OK linux-3.15.2-i686: OK linux-3.16-i686: OK linux-3.17-i686: OK linux-3.18-i686: OK linux-2.6.32.27-x86_64: OK linux-2.6.33.7-x86_64: OK linux-2.6.34.7-x86_64: OK linux-2.6.35.9-x86_64: OK linux-2.6.36.4-x86_64: OK linux-2.6.37.6-x86_64: OK linux-2.6.38.8-x86_64: OK linux-2.6.39.4-x86_64: OK linux-3.0.60-x86_64: OK linux-3.1.10-x86_64: OK linux-3.2.37-x86_64: OK linux-3.3.8-x86_64: OK linux-3.4.27-x86_64: OK linux-3.5.7-x86_64: OK linux-3.6.11-x86_64: OK linux-3.7.4-x86_64: OK linux-3.8-x86_64: OK linux-3.9.2-x86_64: OK linux-3.10.1-x86_64: OK linux-3.11.1-x86_64: OK linux-3.12.23-x86_64: OK linux-3.13.11-x86_64: OK linux-3.14.9-x86_64: OK linux-3.15.2-x86_64: OK linux-3.16-x86_64: OK linux-3.17-x86_64: OK linux-3.18-x86_64: OK apps: OK spec-git: OK sparse: WARNINGS smatch: ERRORS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Saturday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Saturday.tar.bz2 The Media Infrastructure API from this daily build is here: http://www.xs4all.nl/~hverkuil/spec/media.html -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/4] mn88472: implement dvb-t signal lock
That breaks DVB-C lock check as old utmp = 0x08 was set according to
DVB-C lock check, right?
Antti
On 12/13/2014 02:18 AM, Benjamin Larsson wrote:
Signed-off-by: Benjamin Larsson benja...@southpole.se
---
drivers/staging/media/mn88472/mn88472.c | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/drivers/staging/media/mn88472/mn88472.c
b/drivers/staging/media/mn88472/mn88472.c
index 107552a..4d80046 100644
--- a/drivers/staging/media/mn88472/mn88472.c
+++ b/drivers/staging/media/mn88472/mn88472.c
@@ -238,6 +238,7 @@ static int mn88472_read_status(struct dvb_frontend *fe,
fe_status_t *status)
struct dtv_frontend_properties *c = fe-dtv_property_cache;
int ret;
unsigned int utmp;
+ int lock = 0;
*status = 0;
@@ -248,6 +249,12 @@ static int mn88472_read_status(struct dvb_frontend *fe,
fe_status_t *status)
switch (c-delivery_system) {
case SYS_DVBT:
+ ret = regmap_read(dev-regmap[0], 0x7F, utmp);
+ if (ret)
+ goto err;
+ if ((utmp0xF) 8)
+ lock = 1;
+ break;
case SYS_DVBT2:
/* FIXME: implement me */
utmp = 0x08; /* DVB-C lock value */
@@ -262,7 +269,7 @@ static int mn88472_read_status(struct dvb_frontend *fe,
fe_status_t *status)
goto err;
}
- if (utmp == 0x08)
+ if (lock)
*status = FE_HAS_SIGNAL | FE_HAS_CARRIER | FE_HAS_VITERBI |
FE_HAS_SYNC | FE_HAS_LOCK;
--
http://palosaari.fi/
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/4] rtl28xxu: swap frontend order for devices with slave demodulators
I am not sure even idea of that. You didn't add even commit description,
like all the other patches too :( You should really start adding commit
messages explaining why and how commit is.
So the question is why that patch should be applied?
On the other-hand, how there is
if (fe-id == 1 onoff) {
... as I don't remember any patch changing it to 0. I look my tree FE ID
is 0. Do you have some unpublished hacks?
Antti
On 12/13/2014 02:18 AM, Benjamin Larsson wrote:
Signed-off-by: Benjamin Larsson benja...@southpole.se
---
drivers/media/usb/dvb-usb-v2/rtl28xxu.c | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/drivers/media/usb/dvb-usb-v2/rtl28xxu.c
b/drivers/media/usb/dvb-usb-v2/rtl28xxu.c
index ab48b5f..cdc342a 100644
--- a/drivers/media/usb/dvb-usb-v2/rtl28xxu.c
+++ b/drivers/media/usb/dvb-usb-v2/rtl28xxu.c
@@ -863,6 +863,7 @@ static int rtl2832u_frontend_attach(struct dvb_usb_adapter
*adap)
/* attach slave demodulator */
if (priv-slave_demod == SLAVE_DEMOD_MN88472) {
+ struct dvb_frontend *tmp_fe;
struct mn88472_config mn88472_config = {};
mn88472_config.fe = adap-fe[1];
@@ -887,6 +888,12 @@ static int rtl2832u_frontend_attach(struct dvb_usb_adapter
*adap)
}
priv-i2c_client_slave_demod = client;
+
+ /* Swap frontend order */
+ tmp_fe = adap-fe[0];
+ adap-fe[0] = adap-fe[1];
+ adap-fe[1] = tmp_fe;
+
} else {
struct mn88473_config mn88473_config = {};
@@ -1373,7 +1380,7 @@ static int rtl2832u_frontend_ctrl(struct dvb_frontend
*fe, int onoff)
/* bypass slave demod TS through master demod */
if (fe-id == 1 onoff) {
- ret = rtl2832_enable_external_ts_if(adap-fe[0]);
+ ret = rtl2832_enable_external_ts_if(adap-fe[1]);
if (ret)
goto err;
}
--
http://palosaari.fi/
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/4] mn88472: elaborate debug printout
That patch is simply wrong. Kernel logging system is able to add function name automatically - it should not be defined manually for debug logging. See kernel documentation: Documentation/dynamic-debug-howto.txt around the line 213. -- The flags are: penables the pr_debug() callsite. fInclude the function name in the printed message lInclude line number in the printed message mInclude module name in the printed message tInclude thread ID in messages not generated from interrupt context _No flags are set. (Or'd with others on input) -- Antti On 12/13/2014 02:18 AM, Benjamin Larsson wrote: Signed-off-by: Benjamin Larsson benja...@southpole.se --- drivers/staging/media/mn88472/mn88472.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/drivers/staging/media/mn88472/mn88472.c b/drivers/staging/media/mn88472/mn88472.c index 4d80046..746cc94 100644 --- a/drivers/staging/media/mn88472/mn88472.c +++ b/drivers/staging/media/mn88472/mn88472.c @@ -33,6 +33,7 @@ static int mn88472_set_frontend(struct dvb_frontend *fe) u64 tmp; u8 delivery_system_val, if_val[3], bw_val[7], bw_val2; + dev_dbg(client-dev, %s:\n, __func__); dev_dbg(client-dev, delivery_system=%d modulation=%d frequency=%d symbol_rate=%d inversion=%d\n, c-delivery_system, c-modulation, @@ -288,7 +289,7 @@ static int mn88472_init(struct dvb_frontend *fe) u8 *fw_file = MN88472_FIRMWARE; unsigned int csum; - dev_dbg(client-dev, \n); + dev_dbg(client-dev, %s:\n, __func__); /* set cold state by default */ dev-warm = false; @@ -371,7 +372,7 @@ static int mn88472_sleep(struct dvb_frontend *fe) struct mn88472_dev *dev = i2c_get_clientdata(client); int ret; - dev_dbg(client-dev, \n); + dev_dbg(client-dev, %s:\n, __func__); /* power off */ ret = regmap_write(dev-regmap[2], 0x0b, 0x30); -- http://palosaari.fi/ -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 4/4] mn88472: implemented ber reporting
On 12/13/2014 02:18 AM, Benjamin Larsson wrote:
Signed-off-by: Benjamin Larsson benja...@southpole.se
Reviewed-by: Antti Palosaari cr...@iki.fi
Even I could accept that, as a staging driver, I see there some issues:
* missing commit message (ok, it is trivial and patch subject says)
* it is legacy DVBv3 API BER reporting, whilst driver is DVBv5 mostly
due to DVB-T2... So DVBv5 statistics are preferred.
* dynamic debugs has unneded __func__, see
Documentation/dynamic-debug-howto.txt
* there should be spaces used around binary and ternary calculation
operators, see Documentation/CodingStyle for more info how it should be.
Could you read overall these two docs before make new patches:
Documentation/CodingStyle
Documentation/dynamic-debug-howto.txt
also use scripts/checkpatch.pl to verify patch, like that
git diff | ./scripts/checkpatch.pl -
regards
Antti
---
drivers/staging/media/mn88472/mn88472.c | 31 +++
1 file changed, 31 insertions(+)
diff --git a/drivers/staging/media/mn88472/mn88472.c
b/drivers/staging/media/mn88472/mn88472.c
index 746cc94..8b35639 100644
--- a/drivers/staging/media/mn88472/mn88472.c
+++ b/drivers/staging/media/mn88472/mn88472.c
@@ -392,6 +392,36 @@ err:
return ret;
}
+static int mn88472_read_ber(struct dvb_frontend *fe, u32 *ber)
+{
+ struct i2c_client *client = fe-demodulator_priv;
+ struct mn88472_dev *dev = i2c_get_clientdata(client);
+ int ret, err, len;
+ u8 data[3];
+
+ dev_dbg(client-dev, %s:\n, __func__);
+
+ ret = regmap_bulk_read(dev-regmap[0], 0x9F , data, 3);
+ if (ret)
+ goto err;
+ err = data[0]16 | data[1]8 | data[2];
+
+ ret = regmap_bulk_read(dev-regmap[0], 0xA2 , data, 2);
+ if (ret)
+ goto err;
+ len = data[0]8 | data[1];
+
+ if (len)
+ *ber = (err*100)/len;
+ else
+ *ber = 0;
+
+ return 0;
+err:
+ dev_dbg(client-dev, %s: failed=%d\n, __func__, ret);
+ return ret;
+}
+
static struct dvb_frontend_ops mn88472_ops = {
.delsys = {SYS_DVBT, SYS_DVBT2, SYS_DVBC_ANNEX_A},
.info = {
@@ -425,6 +455,7 @@ static struct dvb_frontend_ops mn88472_ops = {
.set_frontend = mn88472_set_frontend,
.read_status = mn88472_read_status,
+ .read_ber = mn88472_read_ber,
};
static int mn88472_probe(struct i2c_client *client,
--
http://palosaari.fi/
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
