Re: [PATCH 3/3] media: omap3isp: ispvideo: use vb2_fop_mmap/poll
Hi Laurent,
Thanks for the review.
On Tue, Feb 24, 2015 at 12:23 AM, Laurent Pinchart
wrote:
> Hi Prabhakar,
>
> Thank you for the patch.
>
> On Monday 23 February 2015 20:19:33 Lad Prabhakar wrote:
>> From: "Lad, Prabhakar"
>>
>> No need to reinvent the wheel. Just use the already existing
>> functions provided v4l-core.
>>
>> Signed-off-by: Lad, Prabhakar
>> ---
>> drivers/media/platform/omap3isp/ispvideo.c | 30 --
>> 1 file changed, 4 insertions(+), 26 deletions(-)
>>
>> diff --git a/drivers/media/platform/omap3isp/ispvideo.c
>> b/drivers/media/platform/omap3isp/ispvideo.c index b648176..5dd5ffc 100644
>> --- a/drivers/media/platform/omap3isp/ispvideo.c
>> +++ b/drivers/media/platform/omap3isp/ispvideo.c
>> @@ -1277,37 +1277,13 @@ static int isp_video_release(struct file *file)
>> return ret;
>> }
>>
>> -static unsigned int isp_video_poll(struct file *file, poll_table *wait)
>> -{
>> - struct isp_video *video = video_drvdata(file);
>> - int ret;
>> -
>> - mutex_lock(&video->queue_lock);
>> - ret = vb2_poll(&video->queue, file, wait);
>> - mutex_unlock(&video->queue_lock);
>> -
>> - return ret;
>> -}
>
> This depends on patch 2/3, which can't be accepted as-is for now.
>
>> -static int isp_video_mmap(struct file *file, struct vm_area_struct *vma)
>> -{
>> - struct isp_video *video = video_drvdata(file);
>> - int ret;
>> -
>> - mutex_lock(&video->queue_lock);
>> - ret = vb2_mmap(&video->queue, vma);
>> - mutex_unlock(&video->queue_lock);
>> -
>> - return ret;
>> -}
>
> This should be good but has the side effect of removing locking in
> isp_video_mmap(). Now, I think that's the right thing to do, but it should be
> done in a separate patch first with a proper explanation. I can do so, or you
> can submit an additional patch.
>
I am fine you can go ahead posting the patch.
Cheers,
--Prabhakar Lad
>> static struct v4l2_file_operations isp_video_fops = {
>> .owner = THIS_MODULE,
>> .unlocked_ioctl = video_ioctl2,
>> .open = isp_video_open,
>> .release = isp_video_release,
>> - .poll = isp_video_poll,
>> - .mmap = isp_video_mmap,
>> + .poll = vb2_fop_poll,
>> + .mmap = vb2_fop_mmap,
>> };
>>
>> /*
>> @@ -1389,6 +1365,8 @@ int omap3isp_video_register(struct isp_video
>> *video, struct v4l2_device *vdev)
>>
>> video->video.v4l2_dev = vdev;
>>
>> + /* queue isnt initalized */
>> + video->video.queue = &video->queue;
>> ret = video_register_device(&video->video, VFL_TYPE_GRABBER, -1);
>> if (ret < 0)
>> dev_err(video->isp->dev,
>
> --
> Regards,
>
> Laurent Pinchart
>
--
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 v6 2/4] vb2: add allow_zero_bytesused flag to the vb2_queue struct
On 02/23/2015 01:26 PM, Kamil Debski wrote:
> The vb2: fix bytesused == 0 handling (8a75ffb) patch changed the behavior
> of __fill_vb2_buffer function, so that if bytesused is 0 it is set to the
> size of the buffer. However, bytesused set to 0 is used by older codec
> drivers as as indication used to mark the end of stream.
>
> To keep backward compatibility, this patch adds a flag passed to the
> vb2_queue_init function - allow_zero_bytesused. If the flag is set upon
> initialization of the queue, the videobuf2 keeps the value of bytesused
> intact in the OUTPUT queue and passes it to the driver.
>
> Reported-by: Nicolas Dufresne
> Signed-off-by: Kamil Debski
Acked-by: Hans Verkuil
Thanks!
Hans
> ---
> drivers/media/v4l2-core/videobuf2-core.c | 39
> +-
> include/media/videobuf2-core.h |2 ++
> 2 files changed, 35 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/media/v4l2-core/videobuf2-core.c
> b/drivers/media/v4l2-core/videobuf2-core.c
> index 5cd60bf..33a5d93 100644
> --- a/drivers/media/v4l2-core/videobuf2-core.c
> +++ b/drivers/media/v4l2-core/videobuf2-core.c
> @@ -1247,6 +1247,16 @@ static void __fill_vb2_buffer(struct vb2_buffer *vb,
> const struct v4l2_buffer *b
> {
> unsigned int plane;
>
> + if (V4L2_TYPE_IS_OUTPUT(b->type)) {
> + if (WARN_ON_ONCE(b->bytesused == 0)) {
> + pr_warn_once("use of bytesused == 0 is deprecated and
> will be removed in the future,\n");
> + if (vb->vb2_queue->allow_zero_bytesused)
> + pr_warn_once("use
> VIDIOC_DECODER_CMD(V4L2_DEC_CMD_STOP) instead.\n");
> + else
> + pr_warn_once("use the actual size instead.\n");
> + }
> + }
> +
> if (V4L2_TYPE_IS_MULTIPLANAR(b->type)) {
> if (b->memory == V4L2_MEMORY_USERPTR) {
> for (plane = 0; plane < vb->num_planes; ++plane) {
> @@ -1276,13 +1286,22 @@ static void __fill_vb2_buffer(struct vb2_buffer *vb,
> const struct v4l2_buffer *b
>* userspace clearly never bothered to set it and
>* it's a safe assumption that they really meant to
>* use the full plane sizes.
> + *
> + * Some drivers, e.g. old codec drivers, use bytesused
> == 0
> + * as a way to indicate that streaming is finished.
> + * In that case, the driver should use the
> + * allow_zero_bytesused flag to keep old userspace
> + * applications working.
>*/
> for (plane = 0; plane < vb->num_planes; ++plane) {
> struct v4l2_plane *pdst = &v4l2_planes[plane];
> struct v4l2_plane *psrc = &b->m.planes[plane];
>
> - pdst->bytesused = psrc->bytesused ?
> - psrc->bytesused : pdst->length;
> + if (vb->vb2_queue->allow_zero_bytesused)
> + pdst->bytesused = psrc->bytesused;
> + else
> + pdst->bytesused = psrc->bytesused ?
> + psrc->bytesused : pdst->length;
> pdst->data_offset = psrc->data_offset;
> }
> }
> @@ -1295,6 +1314,11 @@ static void __fill_vb2_buffer(struct vb2_buffer *vb,
> const struct v4l2_buffer *b
>*
>* If bytesused == 0 for the output buffer, then fall back
>* to the full buffer size as that's a sensible default.
> + *
> + * Some drivers, e.g. old codec drivers, use bytesused == 0 as
> + * a way to indicate that streaming is finished. In that case,
> + * the driver should use the allow_zero_bytesused flag to keep
> + * old userspace applications working.
>*/
> if (b->memory == V4L2_MEMORY_USERPTR) {
> v4l2_planes[0].m.userptr = b->m.userptr;
> @@ -1306,10 +1330,13 @@ static void __fill_vb2_buffer(struct vb2_buffer *vb,
> const struct v4l2_buffer *b
> v4l2_planes[0].length = b->length;
> }
>
> - if (V4L2_TYPE_IS_OUTPUT(b->type))
> - v4l2_planes[0].bytesused = b->bytesused ?
> - b->bytesused : v4l2_planes[0].length;
> - else
> + if (V4L2_TYPE_IS_OUTPUT(b->type)) {
> + if (vb->vb2_queue->allow_zero_bytesused)
> + v4l2_planes[0].bytesused = b->bytesused;
> + else
> + v4l2_planes[0].bytesused = b->bytesused ?
> +
Re: [PATCH] drivers: media: i2c : s5c73m3: Replace dev_err with pr_err
On Tue, 2015-02-24 at 10:17 +0530, Tapasweni Pathak wrote:
> Replace dev_err statement with pr_err to fix null dereference.
>
> Found by Coccinelle.
>
> Signed-off-by: Tapasweni Pathak
> ---
> drivers/media/i2c/s5c73m3/s5c73m3-spi.c |2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/media/i2c/s5c73m3/s5c73m3-spi.c
> b/drivers/media/i2c/s5c73m3/s5c73m3-spi.c
> index f60b265..63eb190 100644
> --- a/drivers/media/i2c/s5c73m3/s5c73m3-spi.c
> +++ b/drivers/media/i2c/s5c73m3/s5c73m3-spi.c
> @@ -52,7 +52,7 @@ static int spi_xmit(struct spi_device *spi_dev, void *addr,
> const int len,
> xfer.rx_buf = addr;
>
> if (spi_dev == NULL) {
> - dev_err(&spi_dev->dev, "SPI device is uninitialized\n");
> + pr_err("SPI device is uninitialized\n");
> return -ENODEV;
> }
It'd be better to move this above the if (dir...) block
and use ratelimit/once it too
static int spi_xmit(struct spi_device *spi_dev, void *addr, const int len,
enum spi_direction dir)
{
struct spi_message msg;
int r;
struct spi_transfer xfer = {
.len= len,
};
if (!spi_dev) {
pr_err_once("SPI device is uninitialized\n");
return -ENODEV;
}
if (dir == SPI_DIR_TX)
xfer.tx_buf = addr;
else
xfer.rx_buf = addr;
...
--
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] drivers: media: i2c : s5c73m3: Replace dev_err with pr_err
Replace dev_err statement with pr_err to fix null dereference.
Found by Coccinelle.
Signed-off-by: Tapasweni Pathak
---
drivers/media/i2c/s5c73m3/s5c73m3-spi.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/media/i2c/s5c73m3/s5c73m3-spi.c
b/drivers/media/i2c/s5c73m3/s5c73m3-spi.c
index f60b265..63eb190 100644
--- a/drivers/media/i2c/s5c73m3/s5c73m3-spi.c
+++ b/drivers/media/i2c/s5c73m3/s5c73m3-spi.c
@@ -52,7 +52,7 @@ static int spi_xmit(struct spi_device *spi_dev, void *addr,
const int len,
xfer.rx_buf = addr;
if (spi_dev == NULL) {
- dev_err(&spi_dev->dev, "SPI device is uninitialized\n");
+ pr_err("SPI device is uninitialized\n");
return -ENODEV;
}
--
1.7.9.5
--
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/3] media: Fix ALSA and DVB representation at media controller API
Em Tue, 24 Feb 2015 00:58:23 +0200
Laurent Pinchart escreveu:
> Hi Mauro and Hans,
>
> On Monday 26 January 2015 14:41:53 Hans Verkuil wrote:
> > On 01/26/2015 02:34 PM, Mauro Carvalho Chehab wrote:
> > > Em Mon, 26 Jan 2015 14:11:50 +0100 Hans Verkuil escreveu:
> > >> On 01/26/2015 01:47 PM, Mauro Carvalho Chehab wrote:
> > >>> The previous provision for DVB media controller support were to
> > >>> define an ID (likely meaning the adapter number) for the DVB
> > >>> devnodes.
> > >>>
> > >>> This is just plain wrong. Just like V4L, DVB devices (and ALSA,
> > >>> or whatever) are identified via a (major, minor) tuple.
> > >>>
> > >>> This is enough to uniquely identify a devnode, no matter what
> > >>> API it implements.
> > >>>
> > >>> So, before we go too far, let's mark the old v4l, dvb and alsa
> > >>> "devnode" info as deprecated, and just call it as "dev".
> > >>>
> > >>> As we don't want to break compilation on already existing apps,
> > >>> let's just keep the old definitions as-is, adding a note that
> > >>> those are deprecated at media-entity.h.
> > >>>
> > >>> Signed-off-by: Mauro Carvalho Chehab
>
> [snip]
>
> > >>> diff --git a/include/media/media-entity.h b/include/media/media-entity.h
> > >>> index e00459185d20..d6d74bcfe183 100644
> > >>> --- a/include/media/media-entity.h
> > >>> +++ b/include/media/media-entity.h
> > >>> @@ -87,17 +87,7 @@ struct media_entity {
> > >>> struct {
> > >>> u32 major;
> > >>> u32 minor;
> > >>> - } v4l;
> > >>> - struct {
> > >>> - u32 major;
> > >>> - u32 minor;
> > >>> - } fb;
> > >>> - struct {
> > >>> - u32 card;
> > >>> - u32 device;
> > >>> - u32 subdevice;
> > >>> - } alsa;
> > >>
> > >> I don't think the alsa entity information can be replaced by major/minor.
> > >> In particular you will loose the subdevice information which you need as
> > >> well. In addition, alsa devices are almost never referenced via major and
> > >> minor numbers, but always by card/device/subdevice numbers.
> > >
> > > For media-ctl, it is easier to handle major/minor, in order to identify
> > > the associated devnode name. Btw, media-ctl currently assumes that all
> > > devnode devices are specified by v4l.major/v4l.minor.
> > >
> > > Ok, maybe for alsa we'll need also card/device/subdevice, but I think this
> > > should be mapped elsewhere, if this can't be retrieved via its sysfs/udev
> > > interface (with seems to be doubtful).
> >
> > The card/device tuple can likely be mapped to major/minor, but not
> > subdevice. And since everything inside alsa is based on card/device I
> > wouldn't change that.
>
> I think we'll likely need changes for ALSA, but I don't think we know which
> ones yet. For that reason I'd avoid creating any ALSA-specific API for now
> until we implement proper support for ALSA devices. I'm fine, however, with
> deprecating the ALSA API we have now, before it gets (ab)used.
That's my opinion too: deprecate it before it gets (ab)used.
>
> > >>> - int dvb;
> > >>> + } dev;
> > >>>
> > >>> /* Sub-device specifications */
> > >>> /* Nothing needed yet */
> > >>> diff --git a/include/uapi/linux/media.h b/include/uapi/linux/media.h
> > >>> index d847c760e8f0..418f4fec391a 100644
> > >>> --- a/include/uapi/linux/media.h
> > >>> +++ b/include/uapi/linux/media.h
> > >>> @@ -78,6 +78,20 @@ struct media_entity_desc {
> > >>> struct {
> > >>> __u32 major;
> > >>> __u32 minor;
> > >>> + } dev;
> > >>> +
> > >>> +#if 1
> > >>> + /*
> > >>> +* DEPRECATED: previous node specifications. Kept just
> > >>> to
> > >>> +* avoid breaking compilation, but media_entity_desc.dev
> > >>> +* should be used instead. In particular, alsa and dvb
> > >>> +* fields below are wrong: for all devnodes, there
> > >>> should
> > >>> +* be just major/minor inside the struct, as this is
> > >>> enough
> > >>> +* to represent any devnode, no matter what type.
> > >>> +*/
> > >>> + struct {
> > >>> + __u32 major;
> > >>> + __u32 minor;
> > >>> } v4l;
> > >>> struct {
> > >>> __u32 major;
> > >>> @@ -89,6 +103,7 @@ struct media_entity_desc {
> > >>> __u32 subdevice;
> > >>> } alsa;
> > >>> int dvb;
> > >>
> > >> I wouldn't merge all the v4l/fb/etc. structs into one struct. That will
> > >> make it difficult in the future if you need to add a field for e.g. v4l
> > >> entities.
>
> This is something Ha
cron job: media_tree daily build: ERRORS
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: Tue Feb 24 04:00:18 CET 2015 git branch: test git hash: 8a26a258bdb82db241cdc35f332f88dd67bdb9c9 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.18.0-5.slh.1-amd64 linux-git-arm-at91: OK linux-git-arm-davinci: WARNINGS 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: WARNINGS linux-git-powerpc64: OK linux-git-sh: OK linux-git-x86_64: OK linux-2.6.32.27-i686: ERRORS linux-2.6.33.7-i686: ERRORS linux-2.6.34.7-i686: ERRORS linux-2.6.35.9-i686: ERRORS linux-2.6.36.4-i686: ERRORS linux-2.6.37.6-i686: ERRORS linux-2.6.38.8-i686: ERRORS linux-2.6.39.4-i686: ERRORS linux-3.0.60-i686: ERRORS linux-3.1.10-i686: ERRORS linux-3.2.37-i686: ERRORS linux-3.3.8-i686: ERRORS linux-3.4.27-i686: ERRORS linux-3.5.7-i686: ERRORS linux-3.6.11-i686: ERRORS linux-3.7.4-i686: ERRORS linux-3.8-i686: ERRORS linux-3.9.2-i686: ERRORS linux-3.10.1-i686: ERRORS linux-3.11.1-i686: ERRORS linux-3.12.23-i686: ERRORS linux-3.13.11-i686: ERRORS linux-3.14.9-i686: ERRORS linux-3.15.2-i686: ERRORS linux-3.16.7-i686: ERRORS linux-3.17.8-i686: ERRORS linux-3.18.7-i686: ERRORS linux-3.19-i686: ERRORS linux-2.6.32.27-x86_64: ERRORS linux-2.6.33.7-x86_64: ERRORS linux-2.6.34.7-x86_64: ERRORS linux-2.6.35.9-x86_64: ERRORS linux-2.6.36.4-x86_64: ERRORS linux-2.6.37.6-x86_64: ERRORS linux-2.6.38.8-x86_64: ERRORS linux-2.6.39.4-x86_64: ERRORS linux-3.0.60-x86_64: ERRORS linux-3.1.10-x86_64: ERRORS linux-3.2.37-x86_64: ERRORS linux-3.3.8-x86_64: ERRORS linux-3.4.27-x86_64: ERRORS linux-3.5.7-x86_64: ERRORS linux-3.6.11-x86_64: ERRORS linux-3.7.4-x86_64: ERRORS linux-3.8-x86_64: ERRORS linux-3.9.2-x86_64: ERRORS linux-3.10.1-x86_64: ERRORS linux-3.11.1-x86_64: ERRORS linux-3.12.23-x86_64: ERRORS linux-3.13.11-x86_64: ERRORS linux-3.14.9-x86_64: ERRORS linux-3.15.2-x86_64: ERRORS linux-3.16.7-x86_64: ERRORS linux-3.17.8-x86_64: ERRORS linux-3.18.7-x86_64: ERRORS linux-3.19-x86_64: ERRORS apps: OK spec-git: OK sparse: ERRORS smatch: ERRORS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Tuesday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Tuesday.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/3] media: Fix ALSA and DVB representation at media controller API
Em Mon, 23 Feb 2015 23:20:15 +0200
Laurent Pinchart escreveu:
> Hi Mauro,
>
> On Monday 23 February 2015 10:55:08 Mauro Carvalho Chehab wrote:
> > Em Mon, 26 Jan 2015 09:41:41 -0500 Devin Heitmueller escreveu:
> > >> It is actually trivial to get the device nodes once you have the
> > >> major/minor. The media-ctl library does that for you. See:
> > >
> > > No objection then.
> > >
> > > On a related note, you would be very well served to consider testing
> > > your dvb changes with a device that has more than one DVB tuner (such
> > > as the hvr-2200/2250). That will help you shake out any edge cases
> > > related to ensuring that the different DVB nodes appear in different
> > > groups.
> >
> > Hi Devin,
> >
> > I did some tests (and fixes) for WinTV Nova-TD, with has two adapters.
> >
> > I saw two alternatives for it:
> >
> > 1) to create a media controller device for each adapter;
> > 2) to create just one media controller.
> >
> > I actually implemented (1), as, in the case of this device, AFAIKT, the
> > two devices are indepentent, e. g. it is not possible to, for example,
> > share the same tuner with two demods:
> >
> > $ ls -la /dev/media?
> > crw-rw. 1 root video 249, 0 Fev 23 10:02 /dev/media0
> > crw-rw. 1 root video 249, 1 Fev 23 10:02 /dev/media1
> >
> > The adapter 0 corresponds to /dev/media0, and the adapter 1
> > to /dev/media1:
> >
> > $ media-ctl --print-dot -d /dev/media0
> > digraph board {
> > rankdir=TB
> > n0001 [label="dvb-demux\n/dev/dvb/adapter0/demux0", shape=box,
> > style=filled, fillcolor=yellow] n0001 -> n0002
> > n0002 [label="dvb-dvr\n/dev/dvb/adapter0/dvr0", shape=box,
> > style=filled, fillcolor=yellow] n0003
> > [label="dvb-net\n/dev/dvb/adapter0/net0", shape=box, style=filled,
> > fillcolor=yellow] n0004 [label="DiBcom
> > 7000PC\n/dev/dvb/adapter0/frontend0", shape=box, style=filled,
> > fillcolor=yellow] n0004 -> n0001
> > }
> >
> > $ media-ctl --print-dot -d /dev/media1
> > digraph board {
> > rankdir=TB
> > n0001 [label="dvb-demux\n/dev/dvb/adapter1/demux0", shape=box,
> > style=filled, fillcolor=yellow] n0001 -> n0002
> > n0002 [label="dvb-dvr\n/dev/dvb/adapter1/dvr0", shape=box,
> > style=filled, fillcolor=yellow] n0003
> > [label="dvb-net\n/dev/dvb/adapter1/net0", shape=box, style=filled,
> > fillcolor=yellow] n0004 [label="DiBcom
> > 7000PC\n/dev/dvb/adapter1/frontend0", shape=box, style=filled,
> > fillcolor=yellow] n0004 -> n0001
> > }
> >
> > On a more complex hardware where some components may be rewired
> > on a different way, however, using just one media controller
> > would be a better approach.
> >
> > Comments?
>
> A few, yes :-)
>
> There's surprisingly many "details" that are not fully specified in MC, and
> this is one of them. Historically the design idea was to create one media
> device per instance of master video device. For PCI devices that's roughly
> one
> media device per card, for platform devices one media device per master IP
> core (or group of IP cores) instance, and for USB devices one media device
> per
> USB control interface.
>
> We can depart from that model in two ways.
>
> As you mentioned above, it could make sense to create separate media device
> instances for a single master device (USB in this case) when the master
> device
> contains several completely independent pipelines. Completely independent
> means that no data link connects the two pipelines, and that no resource is
> shared between them in a way that affects the device's behaviour.
>
> In the example above the only shared hardware resource seems to be the USB
> bridge chip, which implements two independent DMA channels through the same
> USB interface. If the DMA channels are really independent, in the sense that
> they have no influence on each other such as e.g. bandwidth sharing, then two
> media devices could be created. Note that there's no requirement to do so,
> creating a single media device in this case is still perfectly valid.
Ok, so both ways can be applied on this case. I'll think a little bit more
about it.
> It should also be noted that split pipelines could be difficult to represent
> as independent media devices when an external chip is shared between the two
> pipelines, even if that chip is itself split in two independent parts. This
> is
> caused by how the kernel APIs used to manage composite devices (v4l2-async
> and
> the component framework) handle components. For instance, in the DT case, we
> can't use v4l2-async to bind to one of the subdevs create for a single I2C
> chip or IP core, as they would share the same hardware identifier (device
> name, DT node, ...) used to match subdevs. Arguably that's a framework issue
> that should be fixed, but it wouldn't be trivial.
>
> The second way to depart from the existing model is unrelated to the DVB
> examples above, but is still worth mentionin
Re: Can the patch adding support for the Tasco USB microscope be queued up?
Hi Steven, On Wednesday 18 February 2015 21:47:58 Steven Zakulec wrote: > Here are the results of running lsusb -v -d '1871:0516' on my system > that has the patch applied: Thank you. > Thanks for your help here! You're welcome. I'll include the device support patch in my v4.1 pull request. -- Regards, Laurent Pinchart -- 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 v4 1/2] media/v4l2-ctrls: Always run s_ctrl on volatile ctrls
Hello Hans and Laurent I understand volatile as a control that can change its value by the device. So in that sense I think that my control is volatile and writeable (ack by the user). The value written by the user is meaning-less in my usercase, but in another s it could be useful. I am outside the office and with no computer for the next two weeks. If you can wait until then I can implement Hans idea or another one and try it out with my hw. Thanks for consideing my usercase :) Regards (Sorry for duplicate, still trying to convince my phone to use plain text) On 24 February 2015 06:07:49 GMT+07:00, Laurent Pinchart wrote: >Hi Hans, > >On Monday 23 February 2015 10:06:10 Hans Verkuil wrote: >> On 02/17/2015 04:08 PM, Ricardo Ribalda Delgado wrote: >> > Volatile controls can change their value outside the v4l-ctrl >framework. >> > We should ignore the cached written value of the ctrl when >evaluating if >> > we should run s_ctrl. >> >> I've been thinking some more about this (also due to some comments >Laurent >> made on irc), and I think this should be done differently. >> >> What you want to do here is to signal that setting this control will >execute >> some action that needs to happen even if the same value is set twice. >> >> That's not really covered by VOLATILE. Interestingly, the WRITE_ONLY >flag is >> to be used for just that purpose, but this happens to be a R/W >control, so >> that can't be used either. >> >> What is needed is the following: >> >> 1) Add a new flag: V4L2_CTRL_FLAG_ACTION. >> 2) Any control that sets FLAG_WRITE_ONLY should OR it with >FLAG_ACTION (to >>keep the current meaning of WRITE_ONLY). >> 3) Any control with FLAG_ACTION set should return changed == true in >>cluster_changed. >> 4) Any control with FLAG_VOLATILE set should set ctrl->has_changed to >false >>to prevent generating the CH_VALUE control (that's a real bug). >> >> Your control will now set FLAG_ACTION and FLAG_VOLATILE and it will >do the >> right thing. > >I'm not sure about Ricardo's use case, is it the one we've discussed on >#v4l ? >If so, and if I recall correctly, the idea was to perform an action >with a >parameter, and didn't require volatility. > >> Basically what was missing was a flag to explicitly signal this >'writing >> executes an action' behavior. Trying to shoehorn that into the >volatile >> flag or the write_only flag is just not right. It's a flag in its own >right. > >Just for the sake of exploring all options, what did you think about >the idea >of making button controls accept a value ? > >Your proposal is interesting as well, but I'm not sure about the >V4L2_CTRL_FLAG_ACTION name. Aren't all controls supposed to have an >action of >some sort ? That's nitpicking of course. > >Also, should the action flag be automatically set for button controls ? >Button >controls would in a way become type-less controls with the action flag >set, >that's interesting. I suppose type-less controls without the action >flag don't >make sense. > >> > Signed-off-by: Ricardo Ribalda Delgado >> > --- >> > v4: Hans Verkuil: >> > >> > explicity set has_changed to false. and add comment >> > >> > drivers/media/v4l2-core/v4l2-ctrls.c | 11 +++ >> > 1 file changed, 11 insertions(+) -- Ricardo Ribalda Sent from my Android device with K-9 Mail. Please excuse my brevity. -- 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/3] media: omap3isp: ispvideo: drop driver specific isp_video_fh
Hi Prabhakar, Thank you for the patch. On Monday 23 February 2015 20:19:32 Lad Prabhakar wrote: > From: "Lad, Prabhakar" > > this patch drops driver specific isp_video_fh, as this > can be handled by core. I'm afraid it's not that simple. The omap3isp driver stores video queues per file handle for a reason. This was design to permit creating a high-resolution still image capture queue and prepare buffers ahead of time, to avoid the large delay due to cache management as prepare time when taking the snapshot. Now this use case has been partially solved by VIDIOC_CREATE_BUFS, but we're still missing a VIDIOC_DESTROY_BUFS to make it work completely. That needs to be solved first. > Signed-off-by: Lad, Prabhakar > --- > drivers/media/platform/omap3isp/ispvideo.c | 128 ++--- > drivers/media/platform/omap3isp/ispvideo.h | 13 +-- > 2 files changed, 49 insertions(+), 92 deletions(-) -- Regards, Laurent Pinchart -- 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/3] media: omap3isp: ispvideo: use vb2_fop_mmap/poll
Hi Prabhakar,
Thank you for the patch.
On Monday 23 February 2015 20:19:33 Lad Prabhakar wrote:
> From: "Lad, Prabhakar"
>
> No need to reinvent the wheel. Just use the already existing
> functions provided v4l-core.
>
> Signed-off-by: Lad, Prabhakar
> ---
> drivers/media/platform/omap3isp/ispvideo.c | 30 --
> 1 file changed, 4 insertions(+), 26 deletions(-)
>
> diff --git a/drivers/media/platform/omap3isp/ispvideo.c
> b/drivers/media/platform/omap3isp/ispvideo.c index b648176..5dd5ffc 100644
> --- a/drivers/media/platform/omap3isp/ispvideo.c
> +++ b/drivers/media/platform/omap3isp/ispvideo.c
> @@ -1277,37 +1277,13 @@ static int isp_video_release(struct file *file)
> return ret;
> }
>
> -static unsigned int isp_video_poll(struct file *file, poll_table *wait)
> -{
> - struct isp_video *video = video_drvdata(file);
> - int ret;
> -
> - mutex_lock(&video->queue_lock);
> - ret = vb2_poll(&video->queue, file, wait);
> - mutex_unlock(&video->queue_lock);
> -
> - return ret;
> -}
This depends on patch 2/3, which can't be accepted as-is for now.
> -static int isp_video_mmap(struct file *file, struct vm_area_struct *vma)
> -{
> - struct isp_video *video = video_drvdata(file);
> - int ret;
> -
> - mutex_lock(&video->queue_lock);
> - ret = vb2_mmap(&video->queue, vma);
> - mutex_unlock(&video->queue_lock);
> -
> - return ret;
> -}
This should be good but has the side effect of removing locking in
isp_video_mmap(). Now, I think that's the right thing to do, but it should be
done in a separate patch first with a proper explanation. I can do so, or you
can submit an additional patch.
> static struct v4l2_file_operations isp_video_fops = {
> .owner = THIS_MODULE,
> .unlocked_ioctl = video_ioctl2,
> .open = isp_video_open,
> .release = isp_video_release,
> - .poll = isp_video_poll,
> - .mmap = isp_video_mmap,
> + .poll = vb2_fop_poll,
> + .mmap = vb2_fop_mmap,
> };
>
> /*
> @@ -1389,6 +1365,8 @@ int omap3isp_video_register(struct isp_video
> *video, struct v4l2_device *vdev)
>
> video->video.v4l2_dev = vdev;
>
> + /* queue isnt initalized */
> + video->video.queue = &video->queue;
> ret = video_register_device(&video->video, VFL_TYPE_GRABBER, -1);
> if (ret < 0)
> dev_err(video->isp->dev,
--
Regards,
Laurent Pinchart
--
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/3] media: omap3isp: ispvideo: drop setting of vb2 buffer state to VB2_BUF_STATE_ACTIVE
Hi Prabhakar, Thank you for the patch. On Monday 23 February 2015 20:19:31 Lad Prabhakar wrote: > From: "Lad, Prabhakar" > > There isn't a need to assign the state of vb2_buffer to active > as this is already done by the core. > > Signed-off-by: Lad, Prabhakar Acked-by: Laurent Pinchart and queued to my tree. I still have to test the patch, I'll report any issue I can find. > --- > drivers/media/platform/omap3isp/ispvideo.c | 1 - > 1 file changed, 1 deletion(-) > > diff --git a/drivers/media/platform/omap3isp/ispvideo.c > b/drivers/media/platform/omap3isp/ispvideo.c index 3fe9047..837018d 100644 > --- a/drivers/media/platform/omap3isp/ispvideo.c > +++ b/drivers/media/platform/omap3isp/ispvideo.c > @@ -524,7 +524,6 @@ struct isp_buffer *omap3isp_video_buffer_next(struct > isp_video *video) > > buf = list_first_entry(&video->dmaqueue, struct isp_buffer, > irqlist); > - buf->vb.state = VB2_BUF_STATE_ACTIVE; > > spin_unlock_irqrestore(&video->irqlock, flags); -- Regards, Laurent Pinchart -- 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: Linux TV support Elgato EyeTV hybrid
On 02/23/2015 11:54 PM, Gilles Risch wrote: On 02/23/2015 09:36 PM, Benjamin Larsson wrote: On 02/23/2015 09:24 PM, Gilles Risch wrote: On 02/22/2015 10:29 PM, Antti Palosaari wrote: On 02/22/2015 10:04 PM, Benjamin Larsson wrote: On 02/22/2015 02:47 PM, Gilles Risch wrote: [...] Not sure if it helps, but I also tried: $ modprobe em28xx card=82 $ modprobe xc5000 $ echo 0fd9 0018 > /sys/bus/usb/drivers/em28xx/new_id $ dmesg [ 142.728289] usb 8-6: new high-speed USB device number 3 using ehci_hcd [ 142.862556] usb 8-6: New USB device found, idVendor=0fd9, idProduct=0018 [ 142.862565] usb 8-6: New USB device strings: Mfr=3, Product=1, SerialNumber=2 [ 142.862571] usb 8-6: Product: EyeTV Hybrid [ 142.862576] usb 8-6: Manufacturer: Elgato [ 142.862581] usb 8-6: SerialNumber: 100904010917 [ 142.863146] em28xx: New device Elgato EyeTV Hybrid @ 480 Mbps (0fd9:0018, interface 0, class 0) [ 142.863153] em28xx: Audio interface 0 found (Vendor Class) [ 142.863159] em28xx: Video interface 0 found: isoc [ 142.863163] em28xx: DVB interface 0 found: isoc [ 142.863993] em28xx: chip ID is em2884 [ 142.927681] em2884 #0: EEPROM ID = 26 00 01 00, EEPROM hash = 0x1a01bca5 [ 142.927688] em2884 #0: EEPROM info: [ 142.927694] em2884 #0: microcode start address = 0x0004, boot configuration = 0x01 [ 142.935299] em2884 #0: I2S audio, 5 sample rates [ 142.935306] em2884 #0: 500mA max power [ 142.935312] em2884 #0: Table at offset 0x27, strings=0x1a78, 0x1a92, 0x0e6a [ 142.935466] em2884 #0: Identified as Terratec Cinergy HTC Stick (card=82) [ 142.935474] em2884 #0: analog set to isoc mode. [ 142.935478] em2884 #0: dvb set to isoc mode. [ 142.975149] em2884 #0: Binding audio extension [ 142.975152] em28xx-audio.c: Copyright (C) 2006 Markus Rechberger [ 142.975153] em28xx-audio.c: Copyright (C) 2007-2014 Mauro Carvalho Chehab [ 142.975180] em2884 #0: Endpoint 0x83 high-speed on intf 0 alt 7 interval = 8, size 196 [ 142.975184] em2884 #0: Number of URBs: 1, with 64 packets and 192 size [ 142.975537] em2884 #0: Audio extension successfully initialized [ 142.975540] em28xx: Registered (Em28xx Audio Extension) extension [ 143.003553] WARNING: You are using an experimental version of the media stack. [ 143.003554] As the driver is backported to an older kernel, it doesn't offer [ 143.003555] enough quality for its usage in production. [ 143.003556] Use it with care. [ 143.003556] Latest git patches (needed if you report a bug to linux-media@vger.kernel.org): [ 143.003557] 135f9be9194cf7778eb73594aa55791b229cf27c [media] dvb_frontend: start media pipeline while thread is running [ 143.003558] 0f0fa90bd035fa15106799b813d4f0315d99f47e [media] cx231xx: enable tuner->decoder link at videobuf start [ 143.003560] 9239effd53d47e3cd9c653830c8465c0a3a427dc [media] dvb-frontend: enable tuner link when the FE thread starts [ 143.010977] em2884 #0: Binding DVB extension [ 143.567751] usb 8-6: firmware: agent loaded dvb-usb-terratec-htc-stick-drxk.fw into memory [ 143.585103] drxk: status = 0x639260d9 [ 143.585113] drxk: detected a drx-3926k, spin A3, xtal 20.250 MHz [ 147.656822] drxk: DRXK driver version 0.9.4300 [ 147.695203] drxk: frontend initialized. [ 147.764493] tda18271 11-0060: creating new instance [ 147.766552] TDA18271HD/C2 detected @ 11-0060 I am not sure how certain the TDA18271HD detection is but when I look at the images from here: http://www.linuxtv.org/wiki/index.php/Elgato_EyeTV_hybrid I don't see the tuner chip, so it could be a tda chip. [ 147.997562] DVB: registering new adapter (em2884 #0) [ 147.997571] usb 8-6: DVB: registering adapter 0 frontend 0 (DRXK DVB-C DVB-T)... This sounds good. [ 147.998567] em2884 #0: DVB extension successfully initialized [ 147.998571] em28xx: Registered (Em28xx dvb Extension) extension [ 148.023086] WARNING: You are using an experimental version of the media stack. [ 148.023087] As the driver is backported to an older kernel, it doesn't offer [ 148.023088] enough quality for its usage in production. [ 148.023089] Use it with care. [ 148.023089] Latest git patches (needed if you report a bug to linux-media@vger.kernel.org): [ 148.023090] 135f9be9194cf7778eb73594aa55791b229cf27c [media] dvb_frontend: start media pipeline while thread is running [ 148.023091] 0f0fa90bd035fa15106799b813d4f0315d99f47e [media] cx231xx: enable tuner->decoder link at videobuf start [ 148.023092] 9239effd53d47e3cd9c653830c8465c0a3a427dc [media] dvb-frontend: enable tuner link when the FE thread starts [ 148.034348] em2884 #0: Registering input extension [ 148.064107] Registered IR keymap rc-nec-terratec-cinergy-xs [ 148.064420] input: em28xx IR (em2884 #0) as /devices/pci:00/:00:1d.7/usb8/8-6/rc/rc0/input11 [ 148.064808] rc0: em28xx IR (em2884 #0) as /devices/pci:00/:00:1d.7/usb8/8-6/rc/rc0 [ 148.065325] em2884 #0: Input extension successfully inita
Re: [PATCH v4 1/2] media/v4l2-ctrls: Always run s_ctrl on volatile ctrls
Hi Hans, On Monday 23 February 2015 10:06:10 Hans Verkuil wrote: > On 02/17/2015 04:08 PM, Ricardo Ribalda Delgado wrote: > > Volatile controls can change their value outside the v4l-ctrl framework. > > We should ignore the cached written value of the ctrl when evaluating if > > we should run s_ctrl. > > I've been thinking some more about this (also due to some comments Laurent > made on irc), and I think this should be done differently. > > What you want to do here is to signal that setting this control will execute > some action that needs to happen even if the same value is set twice. > > That's not really covered by VOLATILE. Interestingly, the WRITE_ONLY flag is > to be used for just that purpose, but this happens to be a R/W control, so > that can't be used either. > > What is needed is the following: > > 1) Add a new flag: V4L2_CTRL_FLAG_ACTION. > 2) Any control that sets FLAG_WRITE_ONLY should OR it with FLAG_ACTION (to >keep the current meaning of WRITE_ONLY). > 3) Any control with FLAG_ACTION set should return changed == true in >cluster_changed. > 4) Any control with FLAG_VOLATILE set should set ctrl->has_changed to false >to prevent generating the CH_VALUE control (that's a real bug). > > Your control will now set FLAG_ACTION and FLAG_VOLATILE and it will do the > right thing. I'm not sure about Ricardo's use case, is it the one we've discussed on #v4l ? If so, and if I recall correctly, the idea was to perform an action with a parameter, and didn't require volatility. > Basically what was missing was a flag to explicitly signal this 'writing > executes an action' behavior. Trying to shoehorn that into the volatile > flag or the write_only flag is just not right. It's a flag in its own right. Just for the sake of exploring all options, what did you think about the idea of making button controls accept a value ? Your proposal is interesting as well, but I'm not sure about the V4L2_CTRL_FLAG_ACTION name. Aren't all controls supposed to have an action of some sort ? That's nitpicking of course. Also, should the action flag be automatically set for button controls ? Button controls would in a way become type-less controls with the action flag set, that's interesting. I suppose type-less controls without the action flag don't make sense. > > Signed-off-by: Ricardo Ribalda Delgado > > --- > > v4: Hans Verkuil: > > > > explicity set has_changed to false. and add comment > > > > drivers/media/v4l2-core/v4l2-ctrls.c | 11 +++ > > 1 file changed, 11 insertions(+) -- Regards, Laurent Pinchart -- 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/3] media: Fix ALSA and DVB representation at media controller API
Hi Mauro and Hans,
On Monday 26 January 2015 14:41:53 Hans Verkuil wrote:
> On 01/26/2015 02:34 PM, Mauro Carvalho Chehab wrote:
> > Em Mon, 26 Jan 2015 14:11:50 +0100 Hans Verkuil escreveu:
> >> On 01/26/2015 01:47 PM, Mauro Carvalho Chehab wrote:
> >>> The previous provision for DVB media controller support were to
> >>> define an ID (likely meaning the adapter number) for the DVB
> >>> devnodes.
> >>>
> >>> This is just plain wrong. Just like V4L, DVB devices (and ALSA,
> >>> or whatever) are identified via a (major, minor) tuple.
> >>>
> >>> This is enough to uniquely identify a devnode, no matter what
> >>> API it implements.
> >>>
> >>> So, before we go too far, let's mark the old v4l, dvb and alsa
> >>> "devnode" info as deprecated, and just call it as "dev".
> >>>
> >>> As we don't want to break compilation on already existing apps,
> >>> let's just keep the old definitions as-is, adding a note that
> >>> those are deprecated at media-entity.h.
> >>>
> >>> Signed-off-by: Mauro Carvalho Chehab
[snip]
> >>> diff --git a/include/media/media-entity.h b/include/media/media-entity.h
> >>> index e00459185d20..d6d74bcfe183 100644
> >>> --- a/include/media/media-entity.h
> >>> +++ b/include/media/media-entity.h
> >>> @@ -87,17 +87,7 @@ struct media_entity {
> >>> struct {
> >>> u32 major;
> >>> u32 minor;
> >>> - } v4l;
> >>> - struct {
> >>> - u32 major;
> >>> - u32 minor;
> >>> - } fb;
> >>> - struct {
> >>> - u32 card;
> >>> - u32 device;
> >>> - u32 subdevice;
> >>> - } alsa;
> >>
> >> I don't think the alsa entity information can be replaced by major/minor.
> >> In particular you will loose the subdevice information which you need as
> >> well. In addition, alsa devices are almost never referenced via major and
> >> minor numbers, but always by card/device/subdevice numbers.
> >
> > For media-ctl, it is easier to handle major/minor, in order to identify
> > the associated devnode name. Btw, media-ctl currently assumes that all
> > devnode devices are specified by v4l.major/v4l.minor.
> >
> > Ok, maybe for alsa we'll need also card/device/subdevice, but I think this
> > should be mapped elsewhere, if this can't be retrieved via its sysfs/udev
> > interface (with seems to be doubtful).
>
> The card/device tuple can likely be mapped to major/minor, but not
> subdevice. And since everything inside alsa is based on card/device I
> wouldn't change that.
I think we'll likely need changes for ALSA, but I don't think we know which
ones yet. For that reason I'd avoid creating any ALSA-specific API for now
until we implement proper support for ALSA devices. I'm fine, however, with
deprecating the ALSA API we have now, before it gets (ab)used.
> >>> - int dvb;
> >>> + } dev;
> >>>
> >>> /* Sub-device specifications */
> >>> /* Nothing needed yet */
> >>> diff --git a/include/uapi/linux/media.h b/include/uapi/linux/media.h
> >>> index d847c760e8f0..418f4fec391a 100644
> >>> --- a/include/uapi/linux/media.h
> >>> +++ b/include/uapi/linux/media.h
> >>> @@ -78,6 +78,20 @@ struct media_entity_desc {
> >>> struct {
> >>> __u32 major;
> >>> __u32 minor;
> >>> + } dev;
> >>> +
> >>> +#if 1
> >>> + /*
> >>> + * DEPRECATED: previous node specifications. Kept just to
> >>> + * avoid breaking compilation, but media_entity_desc.dev
> >>> + * should be used instead. In particular, alsa and dvb
> >>> + * fields below are wrong: for all devnodes, there should
> >>> + * be just major/minor inside the struct, as this is enough
> >>> + * to represent any devnode, no matter what type.
> >>> + */
> >>> + struct {
> >>> + __u32 major;
> >>> + __u32 minor;
> >>> } v4l;
> >>> struct {
> >>> __u32 major;
> >>> @@ -89,6 +103,7 @@ struct media_entity_desc {
> >>> __u32 subdevice;
> >>> } alsa;
> >>> int dvb;
> >>
> >> I wouldn't merge all the v4l/fb/etc. structs into one struct. That will
> >> make it difficult in the future if you need to add a field for e.g. v4l
> >> entities.
This is something Hans and I have discussed at the FOSDEM, and ended up
disagreeing.
I like the single struct dev here, but I believe it should be moved before the
union, or, as Hans proposed, that the reserved bytes should be moved after the
union. However, the reason why I like your proposal has probably nothing to do
with your intents.
To start directly with the big news, I believe the MC device node entity types
are bogus. They should never have been created in the first place, and your
proposal for DVB support in MC clearly shows it in my opinion.
The media controller model is supposed to describe
Re: Linux TV support Elgato EyeTV hybrid
On 02/23/2015 09:36 PM, Benjamin Larsson wrote: On 02/23/2015 09:24 PM, Gilles Risch wrote: On 02/22/2015 10:29 PM, Antti Palosaari wrote: On 02/22/2015 10:04 PM, Benjamin Larsson wrote: On 02/22/2015 02:47 PM, Gilles Risch wrote: [...] Not sure if it helps, but I also tried: $ modprobe em28xx card=82 $ modprobe xc5000 $ echo 0fd9 0018 > /sys/bus/usb/drivers/em28xx/new_id $ dmesg [ 142.728289] usb 8-6: new high-speed USB device number 3 using ehci_hcd [ 142.862556] usb 8-6: New USB device found, idVendor=0fd9, idProduct=0018 [ 142.862565] usb 8-6: New USB device strings: Mfr=3, Product=1, SerialNumber=2 [ 142.862571] usb 8-6: Product: EyeTV Hybrid [ 142.862576] usb 8-6: Manufacturer: Elgato [ 142.862581] usb 8-6: SerialNumber: 100904010917 [ 142.863146] em28xx: New device Elgato EyeTV Hybrid @ 480 Mbps (0fd9:0018, interface 0, class 0) [ 142.863153] em28xx: Audio interface 0 found (Vendor Class) [ 142.863159] em28xx: Video interface 0 found: isoc [ 142.863163] em28xx: DVB interface 0 found: isoc [ 142.863993] em28xx: chip ID is em2884 [ 142.927681] em2884 #0: EEPROM ID = 26 00 01 00, EEPROM hash = 0x1a01bca5 [ 142.927688] em2884 #0: EEPROM info: [ 142.927694] em2884 #0: microcode start address = 0x0004, boot configuration = 0x01 [ 142.935299] em2884 #0: I2S audio, 5 sample rates [ 142.935306] em2884 #0: 500mA max power [ 142.935312] em2884 #0: Table at offset 0x27, strings=0x1a78, 0x1a92, 0x0e6a [ 142.935466] em2884 #0: Identified as Terratec Cinergy HTC Stick (card=82) [ 142.935474] em2884 #0: analog set to isoc mode. [ 142.935478] em2884 #0: dvb set to isoc mode. [ 142.975149] em2884 #0: Binding audio extension [ 142.975152] em28xx-audio.c: Copyright (C) 2006 Markus Rechberger [ 142.975153] em28xx-audio.c: Copyright (C) 2007-2014 Mauro Carvalho Chehab [ 142.975180] em2884 #0: Endpoint 0x83 high-speed on intf 0 alt 7 interval = 8, size 196 [ 142.975184] em2884 #0: Number of URBs: 1, with 64 packets and 192 size [ 142.975537] em2884 #0: Audio extension successfully initialized [ 142.975540] em28xx: Registered (Em28xx Audio Extension) extension [ 143.003553] WARNING: You are using an experimental version of the media stack. [ 143.003554] As the driver is backported to an older kernel, it doesn't offer [ 143.003555] enough quality for its usage in production. [ 143.003556] Use it with care. [ 143.003556] Latest git patches (needed if you report a bug to linux-media@vger.kernel.org): [ 143.003557] 135f9be9194cf7778eb73594aa55791b229cf27c [media] dvb_frontend: start media pipeline while thread is running [ 143.003558] 0f0fa90bd035fa15106799b813d4f0315d99f47e [media] cx231xx: enable tuner->decoder link at videobuf start [ 143.003560] 9239effd53d47e3cd9c653830c8465c0a3a427dc [media] dvb-frontend: enable tuner link when the FE thread starts [ 143.010977] em2884 #0: Binding DVB extension [ 143.567751] usb 8-6: firmware: agent loaded dvb-usb-terratec-htc-stick-drxk.fw into memory [ 143.585103] drxk: status = 0x639260d9 [ 143.585113] drxk: detected a drx-3926k, spin A3, xtal 20.250 MHz [ 147.656822] drxk: DRXK driver version 0.9.4300 [ 147.695203] drxk: frontend initialized. [ 147.764493] tda18271 11-0060: creating new instance [ 147.766552] TDA18271HD/C2 detected @ 11-0060 [ 147.997562] DVB: registering new adapter (em2884 #0) [ 147.997571] usb 8-6: DVB: registering adapter 0 frontend 0 (DRXK DVB-C DVB-T)... [ 147.998567] em2884 #0: DVB extension successfully initialized [ 147.998571] em28xx: Registered (Em28xx dvb Extension) extension [ 148.023086] WARNING: You are using an experimental version of the media stack. [ 148.023087] As the driver is backported to an older kernel, it doesn't offer [ 148.023088] enough quality for its usage in production. [ 148.023089] Use it with care. [ 148.023089] Latest git patches (needed if you report a bug to linux-media@vger.kernel.org): [ 148.023090] 135f9be9194cf7778eb73594aa55791b229cf27c [media] dvb_frontend: start media pipeline while thread is running [ 148.023091] 0f0fa90bd035fa15106799b813d4f0315d99f47e [media] cx231xx: enable tuner->decoder link at videobuf start [ 148.023092] 9239effd53d47e3cd9c653830c8465c0a3a427dc [media] dvb-frontend: enable tuner link when the FE thread starts [ 148.034348] em2884 #0: Registering input extension [ 148.064107] Registered IR keymap rc-nec-terratec-cinergy-xs [ 148.064420] input: em28xx IR (em2884 #0) as /devices/pci:00/:00:1d.7/usb8/8-6/rc/rc0/input11 [ 148.064808] rc0: em28xx IR (em2884 #0) as /devices/pci:00/:00:1d.7/usb8/8-6/rc/rc0 [ 148.065325] em2884 #0: Input extension successfully initalized [ 148.065333] em28xx: Registered (Em28xx Input Extension) extension The dmesg shows that a TDA18271HD/C2 tuner has been detected. A w_scan produced a kernel Oops: [ 193.580994] BUG: unable to handle kernel NULL pointer dereference at 0
Re: DVB Simulcrypt
Op 23-02-15 om 22:29 schreef Rudy Zijlstra: On 23-02-15 20:56, Honza Petrouš wrote: 2015-02-23 16:51 GMT+01:00 Rudy Zijlstra : And yes, my CAM's are for Irdeto and do not support Nagra. To my knowledge no valid Nagra CAM do exist for DVB-C I'm a bit fossil regarding current status of CA in DVB but anyway I can say I know that some years ago existed CI-CAM modules for Nagra, it was in time of so-called Nagra2 introduction on Hispasat ;) Dunno how is the current situation. An second - it has no difference if it is for sattelite or cable variant of DVB. The CI-CAM standard is the same. The only problem can be if support for particular provider is "baked" inside (meaning only particular auth data are inserted). The point is that although from standard point of view you are right, no cable operator has ever wanted to support Nagra CAM. As a result the needed CAM authorization is not present. CI+ is a different story. Would need to check if CI+ is available in PC card form now. Kind of doubt that though. Do not expect Nagra wil support such development (refuse to validate). Cheers Rudy Spare your time: no CI for PC is available that supports the bogus CI+ standard. And thus no driver for that too. So all you need is a simple cardreader like the Smargo+ (but make sure you get an original one, not a cheap clone that seemingly is the real deal) Cheers, Tycho -- 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: DVB Simulcrypt
On 23-02-15 20:56, Honza Petrouš wrote: 2015-02-23 16:51 GMT+01:00 Rudy Zijlstra : And yes, my CAM's are for Irdeto and do not support Nagra. To my knowledge no valid Nagra CAM do exist for DVB-C I'm a bit fossil regarding current status of CA in DVB but anyway I can say I know that some years ago existed CI-CAM modules for Nagra, it was in time of so-called Nagra2 introduction on Hispasat ;) Dunno how is the current situation. An second - it has no difference if it is for sattelite or cable variant of DVB. The CI-CAM standard is the same. The only problem can be if support for particular provider is "baked" inside (meaning only particular auth data are inserted). The point is that although from standard point of view you are right, no cable operator has ever wanted to support Nagra CAM. As a result the needed CAM authorization is not present. CI+ is a different story. Would need to check if CI+ is available in PC card form now. Kind of doubt that though. Do not expect Nagra wil support such development (refuse to validate). Cheers Rudy -- 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/3] media: Fix ALSA and DVB representation at media controller API
Hi Mauro,
On Monday 23 February 2015 10:55:08 Mauro Carvalho Chehab wrote:
> Em Mon, 26 Jan 2015 09:41:41 -0500 Devin Heitmueller escreveu:
> >> It is actually trivial to get the device nodes once you have the
> >> major/minor. The media-ctl library does that for you. See:
> >
> > No objection then.
> >
> > On a related note, you would be very well served to consider testing
> > your dvb changes with a device that has more than one DVB tuner (such
> > as the hvr-2200/2250). That will help you shake out any edge cases
> > related to ensuring that the different DVB nodes appear in different
> > groups.
>
> Hi Devin,
>
> I did some tests (and fixes) for WinTV Nova-TD, with has two adapters.
>
> I saw two alternatives for it:
>
> 1) to create a media controller device for each adapter;
> 2) to create just one media controller.
>
> I actually implemented (1), as, in the case of this device, AFAIKT, the
> two devices are indepentent, e. g. it is not possible to, for example,
> share the same tuner with two demods:
>
> $ ls -la /dev/media?
> crw-rw. 1 root video 249, 0 Fev 23 10:02 /dev/media0
> crw-rw. 1 root video 249, 1 Fev 23 10:02 /dev/media1
>
> The adapter 0 corresponds to /dev/media0, and the adapter 1
> to /dev/media1:
>
> $ media-ctl --print-dot -d /dev/media0
> digraph board {
> rankdir=TB
> n0001 [label="dvb-demux\n/dev/dvb/adapter0/demux0", shape=box,
> style=filled, fillcolor=yellow] n0001 -> n0002
> n0002 [label="dvb-dvr\n/dev/dvb/adapter0/dvr0", shape=box,
> style=filled, fillcolor=yellow] n0003
> [label="dvb-net\n/dev/dvb/adapter0/net0", shape=box, style=filled,
> fillcolor=yellow] n0004 [label="DiBcom
> 7000PC\n/dev/dvb/adapter0/frontend0", shape=box, style=filled,
> fillcolor=yellow] n0004 -> n0001
> }
>
> $ media-ctl --print-dot -d /dev/media1
> digraph board {
> rankdir=TB
> n0001 [label="dvb-demux\n/dev/dvb/adapter1/demux0", shape=box,
> style=filled, fillcolor=yellow] n0001 -> n0002
> n0002 [label="dvb-dvr\n/dev/dvb/adapter1/dvr0", shape=box,
> style=filled, fillcolor=yellow] n0003
> [label="dvb-net\n/dev/dvb/adapter1/net0", shape=box, style=filled,
> fillcolor=yellow] n0004 [label="DiBcom
> 7000PC\n/dev/dvb/adapter1/frontend0", shape=box, style=filled,
> fillcolor=yellow] n0004 -> n0001
> }
>
> On a more complex hardware where some components may be rewired
> on a different way, however, using just one media controller
> would be a better approach.
>
> Comments?
A few, yes :-)
There's surprisingly many "details" that are not fully specified in MC, and
this is one of them. Historically the design idea was to create one media
device per instance of master video device. For PCI devices that's roughly one
media device per card, for platform devices one media device per master IP
core (or group of IP cores) instance, and for USB devices one media device per
USB control interface.
We can depart from that model in two ways.
As you mentioned above, it could make sense to create separate media device
instances for a single master device (USB in this case) when the master device
contains several completely independent pipelines. Completely independent
means that no data link connects the two pipelines, and that no resource is
shared between them in a way that affects the device's behaviour.
In the example above the only shared hardware resource seems to be the USB
bridge chip, which implements two independent DMA channels through the same
USB interface. If the DMA channels are really independent, in the sense that
they have no influence on each other such as e.g. bandwidth sharing, then two
media devices could be created. Note that there's no requirement to do so,
creating a single media device in this case is still perfectly valid.
It should also be noted that split pipelines could be difficult to represent
as independent media devices when an external chip is shared between the two
pipelines, even if that chip is itself split in two independent parts. This is
caused by how the kernel APIs used to manage composite devices (v4l2-async and
the component framework) handle components. For instance, in the DT case, we
can't use v4l2-async to bind to one of the subdevs create for a single I2C
chip or IP core, as they would share the same hardware identifier (device
name, DT node, ...) used to match subdevs. Arguably that's a framework issue
that should be fixed, but it wouldn't be trivial.
The second way to depart from the existing model is unrelated to the DVB
examples above, but is still worth mentioning for completeness. When several
master devices share resources (either on-chip or off-chip), a single media
device is required. I've discussed such a case with Jean-Michel Hautbois and
Hans Verkuil at the FOSDEM for the i.MX6 SoC. The chip includes two
independent IPUs (Image Processing Units), with two independent parallel
receivers but one shared
Si4745-C10-GM question
Hi all, i am actually in kernel 3.10, is there any support for this chip ? Thanks Best regards, Angelo -- 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: Linux TV support Elgato EyeTV hybrid
On 02/23/2015 09:24 PM, Gilles Risch wrote: On 02/22/2015 10:29 PM, Antti Palosaari wrote: On 02/22/2015 10:04 PM, Benjamin Larsson wrote: On 02/22/2015 02:47 PM, Gilles Risch wrote: [...] [ 141.423608] WARNING: You are using an experimental version of the media stack. [ 141.423609] As the driver is backported to an older kernel, it doesn't offer [ 141.423610] enough quality for its usage in production. [ 141.423611] Use it with care. [ 141.423612] Latest git patches (needed if you report a bug to linux-media@vger.kernel.org): [ 141.423613] 135f9be9194cf7778eb73594aa55791b229cf27c [media] dvb_frontend: start media pipeline while thread is running [ 141.423614] 0f0fa90bd035fa15106799b813d4f0315d99f47e [media] cx231xx: enable tuner->decoder link at videobuf start [ 141.423615] 9239effd53d47e3cd9c653830c8465c0a3a427dc [media] dvb-frontend: enable tuner link when the FE thread starts [ 141.424714] em2884 #0: Binding DVB extension [ 142.754917] usb 2-6: firmware: agent loaded dvb-usb-hauppauge-hvr930c-drxk.fw into memory [ 142.765420] drxk: status = 0x639260d9 [ 142.765430] drxk: detected a drx-3926k, spin A3, xtal 20.250 MHz [ 144.006316] drxk: DRXK driver version 0.9.4300 [ 144.023065] drxk: frontend initialized. The demod seems to initialize well. [ 144.042622] xc5000 11-0061: creating new instance [ 144.042938] xc5000: I2C read failed The tuner does not initialize. What could be wrong is that the tuner might need to be powered on (pulling some gpio pin) or it resides on another i2c address then what the HVR-930C has it. Or something else. MvH Benjamin Larsson -- 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: DVB Simulcrypt
Op 23-02-15 om 20:56 schreef Honza Petrouš: 2015-02-23 16:51 GMT+01:00 Rudy Zijlstra : On 23-02-15 15:21, Tycho Lürsen wrote: Op 23-02-15 om 13:44 schreef Rudy Zijlstra: On 23-02-15 12:21, Honza Petrouš wrote: 2015-02-23 11:31 GMT+01:00 Rudy Zijlstra : On 23-02-15 08:44, Honza Petrouš wrote: Hi Rudy. 2015-02-22 16:28 GMT+01:00 Rudy Zijlstra : Some more info On 21-02-15 22:30, Rudy Zijlstra wrote: Dears (Hans?) My setup, where the cable operator was using only irdeto, was working good. Then the cable operator merged with another, and now the networks are being merged. As a result, the encryption has moved from irdeto only to simulcyrpt with Irdeto and Nagra. Current status: - when i put the CA card in a STB, it works - when trying to record an encrypted channel from PC, it no longer works. Recording system has 3 tuners. All equal, all with same permissions on the smartcard. On cards 0 and 2 does not work, but card 1 does work, on all channels tested. Does it mean that descrambling is not working for you? If so, how do you manage descrambling? By CI-CAM module or by some "softcam" like oscam? Or do you record ENCRYPTED stream and decrypt the recordings later on? Each tuner has its own legal CI-CAM module. And yes, except for the second tuner descrambling no longer works I'm not much familiar with MythTV, so I'm guessing from the mux setup changes, but did you check to descramble the same channel on different tuners? To eliminate the particular change inside one service only. Of course there can be also software issue in CI-CAM module itself (fail in parsing PMT CA descriptors etc). TBH, I think it must be application layer issue, not kernel one. See above: Recording system has 3 tuners. All equal, all with same permissions on the smartcard. On cards 0 and 2 does not work, but card 1 does work, on all channels tested. additional finfo: i tested the same channel(s) on all 3 tuners. For now i have re-configured mythtv to use only the second tuner for encrypted channels. This does reduce scheduling flexibility though. Would to understand what makes the difference, so i can ask the right questions to MythTV developers. As the decryption does work with 1 tuner, i see 2 options: - depending on tuner id the default CA descriptor used is different, and this selection is not expoerted on API level (kernel issue) - application needs to select which CA to use (and currently does not do this) It should be the latter one. I'm also having Ziggo for provider, but always used FFdecsawrapper/Oscam for decryption (also legal in The Netherlands, providing you have a paid subscription) ECM CA system id's 0x604 or 0x602 (depending on your region) gets you Irdeto, while ECM CA system id's 0x1850 or 0x1801 get you Nagra. Correctly configured FFdecsa/Oscam can deal with it, MythTV probably cannot. Check it out at: http://www.dtvmonitor.com/nl/?guid=0BE90D25-BA46-7B93-FDCD-20EFC79691E0 That's a snapshot from today, monitored from Groningen. Tycho, thanks. looking at http://www.dtvmonitor.com/nl/ziggo-limburg the CA id for Iredeto are same in Limburg as in Groningen. And yes, my CAM's are for Irdeto and do not support Nagra. To my knowledge no valid Nagra CAM do exist for DVB-C I'm a bit fossil regarding current status of CA in DVB but anyway I can say I know that some years ago existed CI-CAM modules for Nagra, it was in time of so-called Nagra2 introduction on Hispasat ;) Dunno how is the current situation. An second - it has no difference if it is for sattelite or cable variant of DVB. The CI-CAM standard is the same. The only problem can be if support for particular provider is "baked" inside (meaning only particular auth data are inserted). /Honza Thanks for the input Honza, but where we live, we are forced to use Irdeto. Moreover, such a Nagra CAM would not eliminate the supposed inability of MythTV to point (while tuning&locking) to the right CA descriptor in a reliable way. Tycho -- 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: Linux TV support Elgato EyeTV hybrid
On 02/22/2015 10:29 PM, Antti Palosaari wrote: On 02/22/2015 10:04 PM, Benjamin Larsson wrote: On 02/22/2015 02:47 PM, Gilles Risch wrote: Hi, most of the used components are identified: - USB Controller: Empia EM2884 - Stereo A/V Decoder: Micronas AVF 49x0B - Hybrid Channel Decoder: Micronas DRX-K DRX3926K:A3 0.9.0 The only ambiguity is the tuner, but I think it could be a Xceive XC5000 This sounds like the Hauppauge WinTV HVR-930C: http://linuxtv.org/wiki/index.php/Hauppauge_WinTV-HVR-930C It is pretty similar than 930C but not same. Compare pictures from my blog and those on LinuxTV wiki. PCB is different. http://www.linuxtv.org/wiki/index.php/Elgato_EyeTV_hybrid http://blog.palosaari.fi/2013/06/naked-hardware-10-hauppauge-wintv-hvr.html I persuaded my laptop to identify the stick ass WinTV-HVR-930C: $ modprobe em28xx card=81 $ echo 0fd9 0018 > /sys/bus/usb/drivers/em28xx/new_id $ dmesg ... [ 128.893703] media: Linux media interface: v0.10 [ 128.910043] Linux video capture interface: v2.00 [ 128.910047] WARNING: You are using an experimental version of the media stack. [ 128.910048] As the driver is backported to an older kernel, it doesn't offer [ 128.910049] enough quality for its usage in production. [ 128.910049] Use it with care. [ 128.910050] Latest git patches (needed if you report a bug to linux-media@vger.kernel.org): [ 128.910051] 135f9be9194cf7778eb73594aa55791b229cf27c [media] dvb_frontend: start media pipeline while thread is running [ 128.910052] 0f0fa90bd035fa15106799b813d4f0315d99f47e [media] cx231xx: enable tuner->decoder link at videobuf start [ 128.910053] 9239effd53d47e3cd9c653830c8465c0a3a427dc [media] dvb-frontend: enable tuner link when the FE thread starts [ 128.942061] usbcore: registered new interface driver em28xx [ 141.148295] usb 2-6: new high-speed USB device number 3 using ehci_hcd [ 141.282672] usb 2-6: New USB device found, idVendor=0fd9, idProduct=0018 [ 141.282681] usb 2-6: New USB device strings: Mfr=3, Product=1, SerialNumber=2 [ 141.282688] usb 2-6: Product: EyeTV Hybrid [ 141.282693] usb 2-6: Manufacturer: Elgato [ 141.282697] usb 2-6: SerialNumber: 100904010917 [ 141.283585] em28xx: New device Elgato EyeTV Hybrid @ 480 Mbps (0fd9:0018, interface 0, class 0) [ 141.283593] em28xx: Audio interface 0 found (Vendor Class) [ 141.283599] em28xx: Video interface 0 found: isoc [ 141.283604] em28xx: DVB interface 0 found: isoc [ 141.283744] em28xx: chip ID is em2884 [ 141.343640] em2884 #0: EEPROM ID = 26 00 01 00, EEPROM hash = 0x1a01bca5 [ 141.343647] em2884 #0: EEPROM info: [ 141.343653] em2884 #0: microcode start address = 0x0004, boot configuration = 0x01 [ 141.351257] em2884 #0: I2S audio, 5 sample rates [ 141.351264] em2884 #0: 500mA max power [ 141.351271] em2884 #0: Table at offset 0x27, strings=0x1a78, 0x1a92, 0x0e6a [ 141.351416] em2884 #0: Identified as Hauppauge WinTV HVR 930C (card=81) [ 141.354712] tveeprom 11-0050: Encountered bad packet header [30]. Corrupt or not a Hauppauge eeprom. [ 141.354721] em2884 #0: analog set to isoc mode. [ 141.354726] em2884 #0: dvb set to isoc mode. [ 141.395223] em2884 #0: Binding audio extension [ 141.395226] em28xx-audio.c: Copyright (C) 2006 Markus Rechberger [ 141.395227] em28xx-audio.c: Copyright (C) 2007-2014 Mauro Carvalho Chehab [ 141.395256] em2884 #0: Endpoint 0x83 high-speed on intf 0 alt 7 interval = 8, size 196 [ 141.395258] em2884 #0: Number of URBs: 1, with 64 packets and 192 size [ 141.395458] em2884 #0: Audio extension successfully initialized [ 141.395460] em28xx: Registered (Em28xx Audio Extension) extension [ 141.423608] WARNING: You are using an experimental version of the media stack. [ 141.423609] As the driver is backported to an older kernel, it doesn't offer [ 141.423610] enough quality for its usage in production. [ 141.423611] Use it with care. [ 141.423612] Latest git patches (needed if you report a bug to linux-media@vger.kernel.org): [ 141.423613] 135f9be9194cf7778eb73594aa55791b229cf27c [media] dvb_frontend: start media pipeline while thread is running [ 141.423614] 0f0fa90bd035fa15106799b813d4f0315d99f47e [media] cx231xx: enable tuner->decoder link at videobuf start [ 141.423615] 9239effd53d47e3cd9c653830c8465c0a3a427dc [media] dvb-frontend: enable tuner link when the FE thread starts [ 141.424714] em2884 #0: Binding DVB extension [ 142.754917] usb 2-6: firmware: agent loaded dvb-usb-hauppauge-hvr930c-drxk.fw into memory [ 142.765420] drxk: status = 0x639260d9 [ 142.765430] drxk: detected a drx-3926k, spin A3, xtal 20.250 MHz [ 144.006316] drxk: DRXK driver version 0.9.4300 [ 144.023065] drxk: frontend initialized. [ 144.042622] xc5000 11-0061: creating new instance [ 144.042938] xc5000: I2C read failed [ 144.042946] xc5000 11-0061: destroying instance [ 144.042956] em28xx: Registered (Em28xx dvb Extension) extens
[PATCH 0/3] omap3isp trivial enhancements
From: "Lad, Prabhakar" Hi Laurent/Sakari, This patch series is intended to use the helpers provided by the v4l-core. Please note I have just compile tested them. Lad, Prabhakar (3): media: omap3isp: ispvideo: drop setting of vb2 buffer state to VB2_BUF_STATE_ACTIVE media: omap3isp: ispvideo: drop driver specific isp_video_fh media: omap3isp: ispvideo: use vb2_fop_mmap/poll drivers/media/platform/omap3isp/ispvideo.c | 153 + drivers/media/platform/omap3isp/ispvideo.h | 13 +-- 2 files changed, 50 insertions(+), 116 deletions(-) -- 2.1.0 -- 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/3] media: omap3isp: ispvideo: use vb2_fop_mmap/poll
From: "Lad, Prabhakar"
No need to reinvent the wheel. Just use the already existing
functions provided v4l-core.
Signed-off-by: Lad, Prabhakar
---
drivers/media/platform/omap3isp/ispvideo.c | 30 --
1 file changed, 4 insertions(+), 26 deletions(-)
diff --git a/drivers/media/platform/omap3isp/ispvideo.c
b/drivers/media/platform/omap3isp/ispvideo.c
index b648176..5dd5ffc 100644
--- a/drivers/media/platform/omap3isp/ispvideo.c
+++ b/drivers/media/platform/omap3isp/ispvideo.c
@@ -1277,37 +1277,13 @@ static int isp_video_release(struct file *file)
return ret;
}
-static unsigned int isp_video_poll(struct file *file, poll_table *wait)
-{
- struct isp_video *video = video_drvdata(file);
- int ret;
-
- mutex_lock(&video->queue_lock);
- ret = vb2_poll(&video->queue, file, wait);
- mutex_unlock(&video->queue_lock);
-
- return ret;
-}
-
-static int isp_video_mmap(struct file *file, struct vm_area_struct *vma)
-{
- struct isp_video *video = video_drvdata(file);
- int ret;
-
- mutex_lock(&video->queue_lock);
- ret = vb2_mmap(&video->queue, vma);
- mutex_unlock(&video->queue_lock);
-
- return ret;
-}
-
static struct v4l2_file_operations isp_video_fops = {
.owner = THIS_MODULE,
.unlocked_ioctl = video_ioctl2,
.open = isp_video_open,
.release = isp_video_release,
- .poll = isp_video_poll,
- .mmap = isp_video_mmap,
+ .poll = vb2_fop_poll,
+ .mmap = vb2_fop_mmap,
};
/*
-
@@ -1389,6 +1365,8 @@ int omap3isp_video_register(struct isp_video *video,
struct v4l2_device *vdev)
video->video.v4l2_dev = vdev;
+ /* queue isnt initalized */
+ video->video.queue = &video->queue;
ret = video_register_device(&video->video, VFL_TYPE_GRABBER, -1);
if (ret < 0)
dev_err(video->isp->dev,
--
2.1.0
--
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/3] media: omap3isp: ispvideo: drop setting of vb2 buffer state to VB2_BUF_STATE_ACTIVE
From: "Lad, Prabhakar" There isn't a need to assign the state of vb2_buffer to active as this is already done by the core. Signed-off-by: Lad, Prabhakar --- drivers/media/platform/omap3isp/ispvideo.c | 1 - 1 file changed, 1 deletion(-) diff --git a/drivers/media/platform/omap3isp/ispvideo.c b/drivers/media/platform/omap3isp/ispvideo.c index 3fe9047..837018d 100644 --- a/drivers/media/platform/omap3isp/ispvideo.c +++ b/drivers/media/platform/omap3isp/ispvideo.c @@ -524,7 +524,6 @@ struct isp_buffer *omap3isp_video_buffer_next(struct isp_video *video) buf = list_first_entry(&video->dmaqueue, struct isp_buffer, irqlist); - buf->vb.state = VB2_BUF_STATE_ACTIVE; spin_unlock_irqrestore(&video->irqlock, flags); -- 2.1.0 -- 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/3] media: omap3isp: ispvideo: drop driver specific isp_video_fh
From: "Lad, Prabhakar"
this patch drops driver specific isp_video_fh, as this
can be handled by core.
Signed-off-by: Lad, Prabhakar
---
drivers/media/platform/omap3isp/ispvideo.c | 128 +++--
drivers/media/platform/omap3isp/ispvideo.h | 13 +--
2 files changed, 49 insertions(+), 92 deletions(-)
diff --git a/drivers/media/platform/omap3isp/ispvideo.c
b/drivers/media/platform/omap3isp/ispvideo.c
index 837018d..b648176 100644
--- a/drivers/media/platform/omap3isp/ispvideo.c
+++ b/drivers/media/platform/omap3isp/ispvideo.c
@@ -294,22 +294,22 @@ __isp_video_get_format(struct isp_video *video, struct
v4l2_format *format)
}
static int
-isp_video_check_format(struct isp_video *video, struct isp_video_fh *vfh)
+isp_video_check_format(struct isp_video *video)
{
struct v4l2_format format;
int ret;
- memcpy(&format, &vfh->format, sizeof(format));
+ memcpy(&format, &video->format, sizeof(format));
ret = __isp_video_get_format(video, &format);
if (ret < 0)
return ret;
- if (vfh->format.fmt.pix.pixelformat != format.fmt.pix.pixelformat ||
- vfh->format.fmt.pix.height != format.fmt.pix.height ||
- vfh->format.fmt.pix.width != format.fmt.pix.width ||
- vfh->format.fmt.pix.bytesperline != format.fmt.pix.bytesperline ||
- vfh->format.fmt.pix.sizeimage != format.fmt.pix.sizeimage ||
- vfh->format.fmt.pix.field != format.fmt.pix.field)
+ if (video->format.fmt.pix.pixelformat != format.fmt.pix.pixelformat ||
+ video->format.fmt.pix.height != format.fmt.pix.height ||
+ video->format.fmt.pix.width != format.fmt.pix.width ||
+ video->format.fmt.pix.bytesperline != format.fmt.pix.bytesperline ||
+ video->format.fmt.pix.sizeimage != format.fmt.pix.sizeimage ||
+ video->format.fmt.pix.field != format.fmt.pix.field)
return -EINVAL;
return 0;
@@ -324,12 +324,11 @@ static int isp_video_queue_setup(struct vb2_queue *queue,
unsigned int *count, unsigned int *num_planes,
unsigned int sizes[], void *alloc_ctxs[])
{
- struct isp_video_fh *vfh = vb2_get_drv_priv(queue);
- struct isp_video *video = vfh->video;
+ struct isp_video *video = vb2_get_drv_priv(queue);
*num_planes = 1;
- sizes[0] = vfh->format.fmt.pix.sizeimage;
+ sizes[0] = video->format.fmt.pix.sizeimage;
if (sizes[0] == 0)
return -EINVAL;
@@ -342,9 +341,8 @@ static int isp_video_queue_setup(struct vb2_queue *queue,
static int isp_video_buffer_prepare(struct vb2_buffer *buf)
{
- struct isp_video_fh *vfh = vb2_get_drv_priv(buf->vb2_queue);
+ struct isp_video *video = vb2_get_drv_priv(buf->vb2_queue);
struct isp_buffer *buffer = to_isp_buffer(buf);
- struct isp_video *video = vfh->video;
dma_addr_t addr;
/* Refuse to prepare the buffer is the video node has registered an
@@ -363,7 +361,7 @@ static int isp_video_buffer_prepare(struct vb2_buffer *buf)
return -EINVAL;
}
- vb2_set_plane_payload(&buffer->vb, 0, vfh->format.fmt.pix.sizeimage);
+ vb2_set_plane_payload(&buffer->vb, 0, video->format.fmt.pix.sizeimage);
buffer->dma = addr;
return 0;
@@ -380,9 +378,8 @@ static int isp_video_buffer_prepare(struct vb2_buffer *buf)
*/
static void isp_video_buffer_queue(struct vb2_buffer *buf)
{
- struct isp_video_fh *vfh = vb2_get_drv_priv(buf->vb2_queue);
+ struct isp_video *video = vb2_get_drv_priv(buf->vb2_queue);
struct isp_buffer *buffer = to_isp_buffer(buf);
- struct isp_video *video = vfh->video;
struct isp_pipeline *pipe = to_isp_pipeline(&video->video.entity);
enum isp_pipeline_state state;
unsigned long flags;
@@ -573,7 +570,7 @@ void omap3isp_video_resume(struct isp_video *video, int
continuous)
if (continuous && video->type == V4L2_BUF_TYPE_VIDEO_CAPTURE) {
mutex_lock(&video->queue_lock);
- vb2_discard_done(video->queue);
+ vb2_discard_done(&video->queue);
mutex_unlock(&video->queue_lock);
}
@@ -615,14 +612,13 @@ isp_video_querycap(struct file *file, void *fh, struct
v4l2_capability *cap)
static int
isp_video_get_format(struct file *file, void *fh, struct v4l2_format *format)
{
- struct isp_video_fh *vfh = to_isp_video_fh(fh);
struct isp_video *video = video_drvdata(file);
if (format->type != video->type)
return -EINVAL;
mutex_lock(&video->mutex);
- *format = vfh->format;
+ *format = video->format;
mutex_unlock(&video->mutex);
return 0;
@@ -631,7 +627,6 @@ isp_video_get_format(struct file *file, void *fh, struct
v4l2_format *format)
static int
isp_video_set_format(struct file *file, void *fh, struc
Re: DVB Simulcrypt
2015-02-23 16:51 GMT+01:00 Rudy Zijlstra : > On 23-02-15 15:21, Tycho Lürsen wrote: >> >> >> Op 23-02-15 om 13:44 schreef Rudy Zijlstra: >>> >>> On 23-02-15 12:21, Honza Petrouš wrote: 2015-02-23 11:31 GMT+01:00 Rudy Zijlstra : > > On 23-02-15 08:44, Honza Petrouš wrote: > > Hi Rudy. > > 2015-02-22 16:28 GMT+01:00 Rudy Zijlstra > : >> >> Some more info >> >> On 21-02-15 22:30, Rudy Zijlstra wrote: >>> >>> Dears (Hans?) >>> >>> My setup, where the cable operator was using only irdeto, was working >>> good. Then the cable operator merged with another, and now the >>> networks are >>> being merged. As a result, the encryption has moved from irdeto only >>> to >>> simulcyrpt with Irdeto and Nagra. >>> >>> Current status: >>> - when i put the CA card in a STB, it works >>> - when trying to record an encrypted channel from PC, it no longer >>> works. >> >> Recording system has 3 tuners. All equal, all with same permissions on >> the >> smartcard. On cards 0 and 2 does not work, but card 1 does work, on >> all >> channels tested. >> > Does it mean that descrambling is not working for you? If so, > how do you manage descrambling? By CI-CAM module > or by some "softcam" like oscam? > > Or do you record ENCRYPTED stream and decrypt the recordings > later on? > > > Each tuner has its own legal CI-CAM module. And yes, except for the > second > tuner descrambling no longer works > I'm not much familiar with MythTV, so I'm guessing from the mux setup changes, but did you check to descramble the same channel on different tuners? To eliminate the particular change inside one service only. Of course there can be also software issue in CI-CAM module itself (fail in parsing PMT CA descriptors etc). TBH, I think it must be application layer issue, not kernel one. >>> See above: >>> >>> Recording system has 3 tuners. All equal, all with same permissions on >>> the >>> smartcard. On cards 0 and 2 does not work, but card 1 does work, on all >>> channels tested. >>> >>> additional finfo: i tested the same channel(s) on all 3 tuners. For now i >>> have re-configured mythtv to use only the second tuner for encrypted >>> channels. >>> This does reduce scheduling flexibility though. >>> >>> Would to understand what makes the difference, so i can ask the right >>> questions to MythTV developers. >>> >>> >>> As the decryption does work with 1 tuner, i see 2 options: >>> - depending on tuner id the default CA descriptor used is different, and >>> this selection is not expoerted on API level (kernel issue) >>> - application needs to select which CA to use (and currently does not do >>> this) >>> >> It should be the latter one. I'm also having Ziggo for provider, but >> always used FFdecsawrapper/Oscam for decryption (also legal in The >> Netherlands, providing you have a paid subscription) >> ECM CA system id's 0x604 or 0x602 (depending on your region) gets you >> Irdeto, while ECM CA system id's 0x1850 or 0x1801 get you Nagra. >> Correctly configured FFdecsa/Oscam can deal with it, MythTV probably >> cannot. >> Check it out at: >> http://www.dtvmonitor.com/nl/?guid=0BE90D25-BA46-7B93-FDCD-20EFC79691E0 >> That's a snapshot from today, monitored from Groningen. >> > Tycho, > > thanks. looking at http://www.dtvmonitor.com/nl/ziggo-limburg the CA id for > Iredeto are same in Limburg as in Groningen. > > And yes, my CAM's are for Irdeto and do not support Nagra. To my knowledge > no valid Nagra CAM do exist for DVB-C > I'm a bit fossil regarding current status of CA in DVB but anyway I can say I know that some years ago existed CI-CAM modules for Nagra, it was in time of so-called Nagra2 introduction on Hispasat ;) Dunno how is the current situation. An second - it has no difference if it is for sattelite or cable variant of DVB. The CI-CAM standard is the same. The only problem can be if support for particular provider is "baked" inside (meaning only particular auth data are inserted). /Honza -- 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: DVB Simulcrypt
Op 23-02-15 om 16:51 schreef Rudy Zijlstra: On 23-02-15 15:21, Tycho Lürsen wrote: Op 23-02-15 om 13:44 schreef Rudy Zijlstra: On 23-02-15 12:21, Honza Petrouš wrote: 2015-02-23 11:31 GMT+01:00 Rudy Zijlstra : On 23-02-15 08:44, Honza Petrouš wrote: Hi Rudy. 2015-02-22 16:28 GMT+01:00 Rudy Zijlstra : Some more info On 21-02-15 22:30, Rudy Zijlstra wrote: Dears (Hans?) My setup, where the cable operator was using only irdeto, was working good. Then the cable operator merged with another, and now the networks are being merged. As a result, the encryption has moved from irdeto only to simulcyrpt with Irdeto and Nagra. Current status: - when i put the CA card in a STB, it works - when trying to record an encrypted channel from PC, it no longer works. Recording system has 3 tuners. All equal, all with same permissions on the smartcard. On cards 0 and 2 does not work, but card 1 does work, on all channels tested. Does it mean that descrambling is not working for you? If so, how do you manage descrambling? By CI-CAM module or by some "softcam" like oscam? Or do you record ENCRYPTED stream and decrypt the recordings later on? Each tuner has its own legal CI-CAM module. And yes, except for the second tuner descrambling no longer works I'm not much familiar with MythTV, so I'm guessing from the mux setup changes, but did you check to descramble the same channel on different tuners? To eliminate the particular change inside one service only. Of course there can be also software issue in CI-CAM module itself (fail in parsing PMT CA descriptors etc). TBH, I think it must be application layer issue, not kernel one. See above: Recording system has 3 tuners. All equal, all with same permissions on the smartcard. On cards 0 and 2 does not work, but card 1 does work, on all channels tested. additional finfo: i tested the same channel(s) on all 3 tuners. For now i have re-configured mythtv to use only the second tuner for encrypted channels. This does reduce scheduling flexibility though. Would to understand what makes the difference, so i can ask the right questions to MythTV developers. As the decryption does work with 1 tuner, i see 2 options: - depending on tuner id the default CA descriptor used is different, and this selection is not expoerted on API level (kernel issue) - application needs to select which CA to use (and currently does not do this) It should be the latter one. I'm also having Ziggo for provider, but always used FFdecsawrapper/Oscam for decryption (also legal in The Netherlands, providing you have a paid subscription) ECM CA system id's 0x604 or 0x602 (depending on your region) gets you Irdeto, while ECM CA system id's 0x1850 or 0x1801 get you Nagra. Correctly configured FFdecsa/Oscam can deal with it, MythTV probably cannot. Check it out at: http://www.dtvmonitor.com/nl/?guid=0BE90D25-BA46-7B93-FDCD-20EFC79691E0 That's a snapshot from today, monitored from Groningen. Tycho, thanks. looking at http://www.dtvmonitor.com/nl/ziggo-limburg the CA id for Iredeto are same in Limburg as in Groningen. And yes, my CAM's are for Irdeto and do not support Nagra. To my knowledge no valid Nagra CAM do exist for DVB-C Can FFdecsawrapper/Oscam be used in combination with MythTV? Cheers Rudy Sure it can, I've been using it for many years with MythTV, up until now. Ziggo does not encrypt any channel that I'm actually using anymore. As for the setup, I do know what I'm talking about, I've been the maintainer of FFdecsawrapper for about 3 years now. For basic instructions (a how-to) look at my wiki pages: http://www.lursen.org/wiki/FFdecsawrapper_with_MythTV_and_Oscam_on_Debian/Ubuntu http://www.lursen.org/wiki/Speciaal:AllePaginas Aren't we lucky to live in The Netherlands? (I mean in the US we'd probably be imprisoned for even mentioning the subject) Tycho -- 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] media: fix gspca drivers build dependencies
From: Randy Dunlap Several (15) drivers in media/usb/gspca use IF_ENABLED(CONFIG_INPUT) to decide if they should call input* interfaces, but those drivers do not build successfully when CONFIG_INPUT=m and the gspca drivers are builtin (=y). Making USB_GSPCA depend on INPUT || INPUT=n fixes the build dependencies and allows all of them to build cleanly. Fixes these build errors (selections, not all are listed): drivers/built-in.o: In function `gspca_disconnect': (.text+0x32ed0f): undefined reference to `input_unregister_device' drivers/built-in.o: In function `sd_isoc_irq': konica.c:(.text+0x333098): undefined reference to `input_event' konica.c:(.text+0x3330ab): undefined reference to `input_event' drivers/built-in.o: In function `sd_stopN': konica.c:(.text+0x3338d3): undefined reference to `input_event' konica.c:(.text+0x3338e5): undefined reference to `input_event' drivers/built-in.o: In function `ov51x_handle_button': ov519.c:(.text+0x335ddb): undefined reference to `input_event' drivers/built-in.o:ov519.c:(.text+0x335ded): more undefined references to `input_event' follow pac7302.c:(.text+0x336ea1): undefined reference to `input_event' pac7302.c:(.text+0x336eb3): undefined reference to `input_event' drivers/built-in.o: In function `sd_pkt_scan': spca561.c:(.text+0x338fd8): undefined reference to `input_event' drivers/built-in.o:spca561.c:(.text+0x338feb): more undefined references to `input_event' follow t613.c:(.text+0x33a6fd): undefined reference to `input_event' drivers/built-in.o:t613.c:(.text+0x33a70f): more undefined references to `input_event' follow Signed-off-by: Randy Dunlap Cc: Hans de Goede --- drivers/media/usb/gspca/Kconfig |1 + 1 file changed, 1 insertion(+) --- linux-next-20150223.orig/drivers/media/usb/gspca/Kconfig +++ linux-next-20150223/drivers/media/usb/gspca/Kconfig @@ -1,6 +1,7 @@ menuconfig USB_GSPCA tristate "GSPCA based webcams" depends on VIDEO_V4L2 + depends on INPUT || INPUT=n default m ---help--- Say Y here if you want to enable selecting webcams based -- 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] media: am437x: Don't release OF node reference twice
Thanks for the patch.
Acked-by: Benoit Parrot
Laurent Pinchart wrote on Mon [2015-Feb-23
16:49:21 +0200]:
> The remote port reference is released both at the end of the OF graph
> parsing loop, and in the error code path at the end of the function.
> Those two calls will release the same reference, causing the reference
> count to go negative.
>
> Fix the problem by removing the second call.
>
> Signed-off-by: Laurent Pinchart
> ---
> drivers/media/platform/am437x/am437x-vpfe.c | 5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)
>
> I've found this issue while reading the code, the patch hasn't been tested.
>
> diff --git a/drivers/media/platform/am437x/am437x-vpfe.c
> b/drivers/media/platform/am437x/am437x-vpfe.c
> index 56a5cb0..ce273b2 100644
> --- a/drivers/media/platform/am437x/am437x-vpfe.c
> +++ b/drivers/media/platform/am437x/am437x-vpfe.c
> @@ -2425,7 +2425,7 @@ static int vpfe_async_complete(struct
> v4l2_async_notifier *notifier)
> static struct vpfe_config *
> vpfe_get_pdata(struct platform_device *pdev)
> {
> - struct device_node *endpoint = NULL, *rem = NULL;
> + struct device_node *endpoint = NULL;
> struct v4l2_of_endpoint bus_cfg;
> struct vpfe_subdev_info *sdinfo;
> struct vpfe_config *pdata;
> @@ -2443,6 +2443,8 @@ vpfe_get_pdata(struct platform_device *pdev)
> return NULL;
>
> for (i = 0; ; i++) {
> + struct device_node *rem;
> +
> endpoint = of_graph_get_next_endpoint(pdev->dev.of_node,
> endpoint);
> if (!endpoint)
> @@ -2513,7 +2515,6 @@ vpfe_get_pdata(struct platform_device *pdev)
>
> done:
> of_node_put(endpoint);
> - of_node_put(rem);
> return NULL;
> }
>
> --
> Regards,
>
> Laurent Pinchart
>
--
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 7/7] DocBook media: document the new 'which' field.
Hi Hans, Thank you for the patch. On Friday 13 February 2015 12:30:06 Hans Verkuil wrote: > From: Hans Verkuil > > The subdev enum ioctls now have a new 'which' field. Document this. > > Signed-off-by: Hans Verkuil Acked-by: Laurent Pinchart > --- > .../DocBook/media/v4l/vidioc-subdev-enum-frame-interval.xml | 13 ++ > .../DocBook/media/v4l/vidioc-subdev-enum-frame-size.xml | 13 ++ > .../DocBook/media/v4l/vidioc-subdev-enum-mbus-code.xml | 11 +++--- 3 files changed, 26 insertions(+), 11 deletions(-) > > diff --git > a/Documentation/DocBook/media/v4l/vidioc-subdev-enum-frame-interval.xml > b/Documentation/DocBook/media/v4l/vidioc-subdev-enum-frame-interval.xml > index 2f8f4f0..cff59f5 100644 > --- a/Documentation/DocBook/media/v4l/vidioc-subdev-enum-frame-interval.xml > +++ b/Documentation/DocBook/media/v4l/vidioc-subdev-enum-frame-interval.xml > @@ -67,9 +67,9 @@ > > To enumerate frame intervals applications initialize the > index, pad, > -code, width and > -height fields of > -&v4l2-subdev-frame-interval-enum; and call the > +which, code, > +width and height > +fields of &v4l2-subdev-frame-interval-enum; and call the > VIDIOC_SUBDEV_ENUM_FRAME_INTERVAL ioctl with a > pointer to this structure. Drivers fill the rest of the structure or return > an &EINVAL; if one of the input fields is invalid. All frame intervals are > @@ -123,7 +123,12 @@ > > > __u32 > - reserved[9] > + which > + Frame intervals to be enumerated, from > &v4l2-subdev-format-whence;. + > + > + __u32 > + reserved[8] > Reserved for future extensions. Applications and drivers must > set the array to zero. > > diff --git > a/Documentation/DocBook/media/v4l/vidioc-subdev-enum-frame-size.xml > b/Documentation/DocBook/media/v4l/vidioc-subdev-enum-frame-size.xml index > 79ce42b..abd545e 100644 > --- a/Documentation/DocBook/media/v4l/vidioc-subdev-enum-frame-size.xml > +++ b/Documentation/DocBook/media/v4l/vidioc-subdev-enum-frame-size.xml > @@ -61,9 +61,9 @@ > ioctl. > > To enumerate frame sizes applications initialize the > -pad, code and > -index fields of the > -&v4l2-subdev-mbus-code-enum; and call the > +pad, which , > +code and index > +fields of the &v4l2-subdev-mbus-code-enum; and call the > VIDIOC_SUBDEV_ENUM_FRAME_SIZE ioctl with a pointer > to the structure. Drivers fill the minimum and maximum frame sizes or > return an &EINVAL; if one of the input parameters is invalid. @@ > -127,7 +127,12 @@ > > > __u32 > - reserved[9] > + which > + Frame sizes to be enumerated, from > &v4l2-subdev-format-whence;. + > + > + __u32 > + reserved[8] > Reserved for future extensions. Applications and drivers must > set the array to zero. > > diff --git > a/Documentation/DocBook/media/v4l/vidioc-subdev-enum-mbus-code.xml > b/Documentation/DocBook/media/v4l/vidioc-subdev-enum-mbus-code.xml index > a6b3432..0bcb278 100644 > --- a/Documentation/DocBook/media/v4l/vidioc-subdev-enum-mbus-code.xml > +++ b/Documentation/DocBook/media/v4l/vidioc-subdev-enum-mbus-code.xml > @@ -56,8 +56,8 @@ > > > To enumerate media bus formats available at a given sub-device > pad -applications initialize the pad and - > index fields of &v4l2-subdev-mbus-code-enum; > and +applications initialize the pad, > which +and index > fields of &v4l2-subdev-mbus-code-enum; and call the > VIDIOC_SUBDEV_ENUM_MBUS_CODE ioctl with a pointer to > this structure. Drivers fill the rest of the structure or return an > &EINVAL; if either the pad or > @@ -93,7 +93,12 @@ > > > __u32 > - reserved[9] > + which > + Media bus format codes to be enumerated, from > &v4l2-subdev-format-whence;. + > + > + __u32 > + reserved[8] > Reserved for future extensions. Applications and drivers must > set the array to zero. > -- Regards, Laurent Pinchart -- 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 5/7] v4l2-subdev: add support for the new enum_frame_size 'which' field.
Hi Hans,
Thank you for the patch.
On Friday 13 February 2015 12:30:04 Hans Verkuil wrote:
> From: Hans Verkuil
>
> Support the new 'which' field in the enum_frame_size ops. Most drivers do
> not need to be changed since they always returns the same enumeration
> regardless of the 'which' field.
>
> Signed-off-by: Hans Verkuil
> Cc: Lad, Prabhakar
> Cc: Sylwester Nawrocki
For everything except s5c73m3,
Acked-by: Laurent Pinchart
Please see below for a small note.
> ---
> drivers/media/i2c/s5c73m3/s5c73m3-core.c | 23 +++
> drivers/media/platform/omap3isp/ispccdc.c | 4 ++--
> drivers/media/platform/omap3isp/ispccp2.c | 4 ++--
> drivers/media/platform/omap3isp/ispcsi2.c | 4 ++--
> drivers/media/platform/omap3isp/isppreview.c | 4 ++--
> drivers/media/platform/omap3isp/ispresizer.c | 4 ++--
> drivers/media/platform/vsp1/vsp1_hsit.c| 4 +++-
> drivers/media/platform/vsp1/vsp1_lif.c | 4 +++-
> drivers/media/platform/vsp1/vsp1_lut.c | 4 +++-
> drivers/media/platform/vsp1/vsp1_rwpf.c| 3 ++-
> drivers/media/platform/vsp1/vsp1_sru.c | 4 +++-
> drivers/media/platform/vsp1/vsp1_uds.c | 4 +++-
> drivers/staging/media/davinci_vpfe/dm365_ipipe.c | 6 ++
> drivers/staging/media/davinci_vpfe/dm365_ipipeif.c | 6 ++
> drivers/staging/media/davinci_vpfe/dm365_isif.c| 4 ++--
> drivers/staging/media/davinci_vpfe/dm365_resizer.c | 6 ++
> drivers/staging/media/omap4iss/iss_csi2.c | 4 ++--
> drivers/staging/media/omap4iss/iss_ipipe.c | 4 ++--
> drivers/staging/media/omap4iss/iss_ipipeif.c | 6 ++
> drivers/staging/media/omap4iss/iss_resizer.c | 6 ++
> 20 files changed, 62 insertions(+), 46 deletions(-)
[snip]
> diff --git a/drivers/media/platform/vsp1/vsp1_hsit.c
> b/drivers/media/platform/vsp1/vsp1_hsit.c index d226b3f..8ffb817 100644
> --- a/drivers/media/platform/vsp1/vsp1_hsit.c
> +++ b/drivers/media/platform/vsp1/vsp1_hsit.c
> @@ -76,9 +76,11 @@ static int hsit_enum_frame_size(struct v4l2_subdev
> *subdev, struct v4l2_subdev_pad_config *cfg,
> struct v4l2_subdev_frame_size_enum *fse)
> {
> + struct vsp1_hsit *hsit = to_hsit(subdev);
> struct v4l2_mbus_framefmt *format;
>
> - format = v4l2_subdev_get_try_format(subdev, cfg, fse->pad);
> + format = vsp1_entity_get_pad_format(&hsit->entity, cfg, fse->pad,
> + fse->which);
You could also have used to_vsp1_entity(subdev) to cast to an entity pointer
directly, but both are fine with me. Same comment for the rest of the driver.
>
> if (fse->index || fse->code != format->code)
> return -EINVAL;
> diff --git a/drivers/media/platform/vsp1/vsp1_lif.c
> b/drivers/media/platform/vsp1/vsp1_lif.c index 60f1bd8..39fa5ef 100644
> --- a/drivers/media/platform/vsp1/vsp1_lif.c
> +++ b/drivers/media/platform/vsp1/vsp1_lif.c
> @@ -109,9 +109,11 @@ static int lif_enum_frame_size(struct v4l2_subdev
> *subdev, struct v4l2_subdev_pad_config *cfg,
> struct v4l2_subdev_frame_size_enum *fse)
> {
> + struct vsp1_lif *lif = to_lif(subdev);
> struct v4l2_mbus_framefmt *format;
>
> - format = v4l2_subdev_get_try_format(subdev, cfg, LIF_PAD_SINK);
> + format = vsp1_entity_get_pad_format(&lif->entity, cfg, LIF_PAD_SINK,
> + fse->which);
>
> if (fse->index || fse->code != format->code)
> return -EINVAL;
> diff --git a/drivers/media/platform/vsp1/vsp1_lut.c
> b/drivers/media/platform/vsp1/vsp1_lut.c index 8aa8c11..656ec27 100644
> --- a/drivers/media/platform/vsp1/vsp1_lut.c
> +++ b/drivers/media/platform/vsp1/vsp1_lut.c
> @@ -117,9 +117,11 @@ static int lut_enum_frame_size(struct v4l2_subdev
> *subdev, struct v4l2_subdev_pad_config *cfg,
> struct v4l2_subdev_frame_size_enum *fse)
> {
> + struct vsp1_lut *lut = to_lut(subdev);
> struct v4l2_mbus_framefmt *format;
>
> - format = v4l2_subdev_get_try_format(subdev, cfg, fse->pad);
> + format = vsp1_entity_get_pad_format(&lut->entity, cfg,
> + fse->pad, fse->which);
>
> if (fse->index || fse->code != format->code)
> return -EINVAL;
> diff --git a/drivers/media/platform/vsp1/vsp1_rwpf.c
> b/drivers/media/platform/vsp1/vsp1_rwpf.c index a083d85..fa71f46 100644
> --- a/drivers/media/platform/vsp1/vsp1_rwpf.c
> +++ b/drivers/media/platform/vsp1/vsp1_rwpf.c
> @@ -48,7 +48,8 @@ int vsp1_rwpf_enum_frame_size(struct v4l2_subdev *subdev,
> struct vsp1_rwpf *rwpf = to_rwpf(subdev);
> struct v4l2_mbus_framefmt *format;
>
> - format = v4l2_subdev_get_try_format(subdev, cfg, fse->pad);
> + format = vsp1_entity_get_pad_format(&rwpf->entity, cfg, fse->pad,
> +
Re: [PATCH 4/7] v4l2-subdev: support new 'which' field in enum_mbus_code
Hi Hans,
Thank you for the patch.
On Friday 13 February 2015 12:30:03 Hans Verkuil wrote:
> From: Hans Verkuil
>
> Support the new 'which' field in the enum_mbus_code ops. Most drivers do not
> need to be changed since they always returns the same enumeration
> regardless of the 'which' field.
>
> Signed-off-by: Hans Verkuil
Acked-by: Laurent Pinchart
> ---
> drivers/media/platform/omap3isp/ispccdc.c| 4 ++--
> drivers/media/platform/omap3isp/ispccp2.c| 2 +-
> drivers/media/platform/omap3isp/ispcsi2.c| 2 +-
> drivers/media/platform/omap3isp/ispresizer.c | 2 +-
> drivers/media/platform/vsp1/vsp1_bru.c | 4 +++-
> drivers/media/platform/vsp1/vsp1_lif.c | 4 +++-
> drivers/media/platform/vsp1/vsp1_lut.c | 4 +++-
> drivers/media/platform/vsp1/vsp1_sru.c | 4 +++-
> drivers/media/platform/vsp1/vsp1_uds.c | 4 +++-
> drivers/staging/media/omap4iss/iss_csi2.c| 2 +-
> drivers/staging/media/omap4iss/iss_ipipeif.c | 2 +-
> drivers/staging/media/omap4iss/iss_resizer.c | 2 +-
> 12 files changed, 23 insertions(+), 13 deletions(-)
>
> diff --git a/drivers/media/platform/omap3isp/ispccdc.c
> b/drivers/media/platform/omap3isp/ispccdc.c index b0431a9..818aa52 100644
> --- a/drivers/media/platform/omap3isp/ispccdc.c
> +++ b/drivers/media/platform/omap3isp/ispccdc.c
> @@ -2133,7 +2133,7 @@ static int ccdc_enum_mbus_code(struct v4l2_subdev *sd,
>
> case CCDC_PAD_SOURCE_OF:
> format = __ccdc_get_format(ccdc, cfg, code->pad,
> -V4L2_SUBDEV_FORMAT_TRY);
> +code->which);
>
> if (format->code == MEDIA_BUS_FMT_YUYV8_2X8 ||
> format->code == MEDIA_BUS_FMT_UYVY8_2X8) {
> @@ -2164,7 +2164,7 @@ static int ccdc_enum_mbus_code(struct v4l2_subdev *sd,
> return -EINVAL;
>
> format = __ccdc_get_format(ccdc, cfg, code->pad,
> -V4L2_SUBDEV_FORMAT_TRY);
> +code->which);
>
> /* A pixel code equal to 0 means that the video port doesn't
>* support the input format. Don't enumerate any pixel code.
> diff --git a/drivers/media/platform/omap3isp/ispccp2.c
> b/drivers/media/platform/omap3isp/ispccp2.c index 3f10c3a..1d79368 100644
> --- a/drivers/media/platform/omap3isp/ispccp2.c
> +++ b/drivers/media/platform/omap3isp/ispccp2.c
> @@ -703,7 +703,7 @@ static int ccp2_enum_mbus_code(struct v4l2_subdev *sd,
> return -EINVAL;
>
> format = __ccp2_get_format(ccp2, cfg, CCP2_PAD_SINK,
> - V4L2_SUBDEV_FORMAT_TRY);
> + code->which);
> code->code = format->code;
> }
>
> diff --git a/drivers/media/platform/omap3isp/ispcsi2.c
> b/drivers/media/platform/omap3isp/ispcsi2.c index 12ca63f..bde734c 100644
> --- a/drivers/media/platform/omap3isp/ispcsi2.c
> +++ b/drivers/media/platform/omap3isp/ispcsi2.c
> @@ -909,7 +909,7 @@ static int csi2_enum_mbus_code(struct v4l2_subdev *sd,
> code->code = csi2_input_fmts[code->index];
> } else {
> format = __csi2_get_format(csi2, cfg, CSI2_PAD_SINK,
> -V4L2_SUBDEV_FORMAT_TRY);
> +code->which);
> switch (code->index) {
> case 0:
> /* Passthrough sink pad code */
> diff --git a/drivers/media/platform/omap3isp/ispresizer.c
> b/drivers/media/platform/omap3isp/ispresizer.c index 3ede27b..02549fa8
> 100644
> --- a/drivers/media/platform/omap3isp/ispresizer.c
> +++ b/drivers/media/platform/omap3isp/ispresizer.c
> @@ -1431,7 +1431,7 @@ static int resizer_enum_mbus_code(struct v4l2_subdev
> *sd, return -EINVAL;
>
> format = __resizer_get_format(res, cfg, RESZ_PAD_SINK,
> - V4L2_SUBDEV_FORMAT_TRY);
> + code->which);
> code->code = format->code;
> }
>
> diff --git a/drivers/media/platform/vsp1/vsp1_bru.c
> b/drivers/media/platform/vsp1/vsp1_bru.c index 31ad0b6..7dd7633 100644
> --- a/drivers/media/platform/vsp1/vsp1_bru.c
> +++ b/drivers/media/platform/vsp1/vsp1_bru.c
> @@ -190,6 +190,7 @@ static int bru_enum_mbus_code(struct v4l2_subdev
> *subdev, MEDIA_BUS_FMT_ARGB_1X32,
> MEDIA_BUS_FMT_AYUV8_1X32,
> };
> + struct vsp1_bru *bru = to_bru(subdev);
> struct v4l2_mbus_framefmt *format;
>
> if (code->pad == BRU_PAD_SINK(0)) {
> @@ -201,7 +202,8 @@ static int bru_enum_mbus_code(struct v4l2_subdev
> *subdev, if (code->index)
> return -EINVAL;
>
> - format = v4l2_subdev_get_try_format(subdev, cfg,
> BRU_PAD_SINK(0));
> + format = vsp1_entity_get_pad_format(&bru->entity, cfg,
> +
Re: [PATCH 3/7] v4l2-subdev.c: add 'which' checks for enum ops.
Hi Hans,
Thank you for the patch.
On Friday 13 February 2015 12:30:02 Hans Verkuil wrote:
> From: Hans Verkuil
>
> Return an error if an invalid 'which' valid is passed in.
>
> Signed-off-by: Hans Verkuil
Acked-by: Laurent Pinchart
> ---
> drivers/media/v4l2-core/v4l2-subdev.c | 12
> 1 file changed, 12 insertions(+)
>
> diff --git a/drivers/media/v4l2-core/v4l2-subdev.c
> b/drivers/media/v4l2-core/v4l2-subdev.c index 3c8b198..8bafb94 100644
> --- a/drivers/media/v4l2-core/v4l2-subdev.c
> +++ b/drivers/media/v4l2-core/v4l2-subdev.c
> @@ -321,6 +321,10 @@ static long subdev_do_ioctl(struct file *file, unsigned
> int cmd, void *arg) case VIDIOC_SUBDEV_ENUM_MBUS_CODE: {
> struct v4l2_subdev_mbus_code_enum *code = arg;
>
> + if (code->which != V4L2_SUBDEV_FORMAT_TRY &&
> + code->which != V4L2_SUBDEV_FORMAT_ACTIVE)
> + return -EINVAL;
> +
> if (code->pad >= sd->entity.num_pads)
> return -EINVAL;
>
> @@ -331,6 +335,10 @@ static long subdev_do_ioctl(struct file *file, unsigned
> int cmd, void *arg) case VIDIOC_SUBDEV_ENUM_FRAME_SIZE: {
> struct v4l2_subdev_frame_size_enum *fse = arg;
>
> + if (fse->which != V4L2_SUBDEV_FORMAT_TRY &&
> + fse->which != V4L2_SUBDEV_FORMAT_ACTIVE)
> + return -EINVAL;
> +
> if (fse->pad >= sd->entity.num_pads)
> return -EINVAL;
>
> @@ -359,6 +367,10 @@ static long subdev_do_ioctl(struct file *file, unsigned
> int cmd, void *arg) case VIDIOC_SUBDEV_ENUM_FRAME_INTERVAL: {
> struct v4l2_subdev_frame_interval_enum *fie = arg;
>
> + if (fie->which != V4L2_SUBDEV_FORMAT_TRY &&
> + fie->which != V4L2_SUBDEV_FORMAT_ACTIVE)
> + return -EINVAL;
> +
> if (fie->pad >= sd->entity.num_pads)
> return -EINVAL;
--
Regards,
Laurent Pinchart
--
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/7] v4l2-subdev.h: add 'which' field for the enum structs
Hi Hans,
Thank you for the patch.
On Friday 13 February 2015 12:30:01 Hans Verkuil wrote:
> From: Hans Verkuil
>
> While all other pad ops allow you to select whether to use the 'try' or
> the 'active' formats, the enum ops didn't have that option and always used
> 'try'.
>
> However, this will fail if a simple (e.g. PCI) bridge driver wants to use
> the enum pad op of a subdev that's also used in a complex platform driver
> like the omap3. Such a bridge driver generally wants to enum formats based
> on the active format.
>
> So add a new 'which' field to these structs. Note that
> V4L2_SUBDEV_FORMAT_TRY is 0, so the default remains TRY (applications need
> to set reserved to 0).
>
> Signed-off-by: Hans Verkuil
Acked-by: Laurent Pinchart
> ---
> include/uapi/linux/v4l2-subdev.h | 12 +---
> 1 file changed, 9 insertions(+), 3 deletions(-)
>
> diff --git a/include/uapi/linux/v4l2-subdev.h
> b/include/uapi/linux/v4l2-subdev.h index e0a7e3d..dbce2b5 100644
> --- a/include/uapi/linux/v4l2-subdev.h
> +++ b/include/uapi/linux/v4l2-subdev.h
> @@ -69,12 +69,14 @@ struct v4l2_subdev_crop {
> * @pad: pad number, as reported by the media API
> * @index: format index during enumeration
> * @code: format code (MEDIA_BUS_FMT_ definitions)
> + * @which: format type (from enum v4l2_subdev_format_whence)
> */
> struct v4l2_subdev_mbus_code_enum {
> __u32 pad;
> __u32 index;
> __u32 code;
> - __u32 reserved[9];
> + __u32 which;
> + __u32 reserved[8];
> };
>
> /**
> @@ -82,6 +84,7 @@ struct v4l2_subdev_mbus_code_enum {
> * @pad: pad number, as reported by the media API
> * @index: format index during enumeration
> * @code: format code (MEDIA_BUS_FMT_ definitions)
> + * @which: format type (from enum v4l2_subdev_format_whence)
> */
> struct v4l2_subdev_frame_size_enum {
> __u32 index;
> @@ -91,7 +94,8 @@ struct v4l2_subdev_frame_size_enum {
> __u32 max_width;
> __u32 min_height;
> __u32 max_height;
> - __u32 reserved[9];
> + __u32 which;
> + __u32 reserved[8];
> };
>
> /**
> @@ -113,6 +117,7 @@ struct v4l2_subdev_frame_interval {
> * @width: frame width in pixels
> * @height: frame height in pixels
> * @interval: frame interval in seconds
> + * @which: format type (from enum v4l2_subdev_format_whence)
> */
> struct v4l2_subdev_frame_interval_enum {
> __u32 index;
> @@ -121,7 +126,8 @@ struct v4l2_subdev_frame_interval_enum {
> __u32 width;
> __u32 height;
> struct v4l2_fract interval;
> - __u32 reserved[9];
> + __u32 which;
> + __u32 reserved[8];
> };
>
> /**
--
Regards,
Laurent Pinchart
--
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/7] v4l2-subdev: replace v4l2_subdev_fh by v4l2_subdev_pad_config
Hi Hans, Thank you for the patch. On Friday 13 February 2015 12:30:00 Hans Verkuil wrote: > From: Hans Verkuil > > If a subdevice pad op is called from a bridge driver, then there is > no v4l2_subdev_fh struct that can be passed to the subdevice. This > made it hard to use such subdevs from a bridge driver. > > This patch replaces the v4l2_subdev_fh pointer by a v4l2_subdev_pad_config > pointer in the pad ops. This allows bridge drivers to use the various > try_ pad ops by creating a v4l2_subdev_pad_config struct and passing it > along to the pad op. > > The v4l2_subdev_get_try_* macros had to be changed because of this, so > I also took the opportunity to use the full name of the > v4l2_subdev_get_try_* functions in the __V4L2_SUBDEV_MK_GET_TRY macro > arguments: if you now do 'git grep v4l2_subdev_get_try_format' you will > actually find the header where it is defined. > > One remark regarding the drivers/staging/media/davinci_vpfe patches: the > *_init_formats() functions assumed that fh could be NULL. However, that's > not true for this driver, it's always set. This is almost certainly a copy > and paste from the omap3isp driver. I've updated the code to reflect the > fact that fh is never NULL. > > Signed-off-by: Hans Verkuil > Cc: Lad, Prabhakar For the subdev core, the Aptina sensor drivers and the OMAP3 ISP, VSP1 and OMAP4 ISS drivers, Acked-by: Laurent Pinchart > --- > drivers/media/i2c/adv7180.c| 10 +-- > drivers/media/i2c/adv7511.c| 16 +++-- > drivers/media/i2c/adv7604.c| 12 ++-- > drivers/media/i2c/m5mols/m5mols_core.c | 16 ++--- > drivers/media/i2c/mt9m032.c| 34 - > drivers/media/i2c/mt9p031.c| 36 +- > drivers/media/i2c/mt9t001.c| 36 +- > drivers/media/i2c/mt9v032.c| 36 +- > drivers/media/i2c/noon010pc30.c| 17 ++--- > drivers/media/i2c/ov9650.c | 16 ++--- > drivers/media/i2c/s5c73m3/s5c73m3-core.c | 51 +++--- > drivers/media/i2c/s5k4ecgx.c | 16 ++--- > drivers/media/i2c/s5k5baf.c| 38 +- > drivers/media/i2c/s5k6a3.c | 18 ++--- > drivers/media/i2c/s5k6aa.c | 34 - > drivers/media/i2c/smiapp/smiapp-core.c | 80 +- > drivers/media/i2c/tvp514x.c| 12 ++-- > drivers/media/i2c/tvp7002.c| 14 ++-- > drivers/media/platform/exynos4-is/fimc-capture.c | 22 +++--- > drivers/media/platform/exynos4-is/fimc-isp.c | 28 > drivers/media/platform/exynos4-is/fimc-lite.c | 33 - > drivers/media/platform/exynos4-is/mipi-csis.c | 16 ++--- > drivers/media/platform/omap3isp/ispccdc.c | 82 ++- > drivers/media/platform/omap3isp/ispccp2.c | 44 ++-- > drivers/media/platform/omap3isp/ispcsi2.c | 40 +-- > drivers/media/platform/omap3isp/isppreview.c | 70 +- > drivers/media/platform/omap3isp/ispresizer.c | 78 ++- > drivers/media/platform/s3c-camif/camif-capture.c | 18 ++--- > drivers/media/platform/vsp1/vsp1_bru.c | 40 +-- > drivers/media/platform/vsp1/vsp1_entity.c | 16 ++--- > drivers/media/platform/vsp1/vsp1_entity.h | 4 +- > drivers/media/platform/vsp1/vsp1_hsit.c| 16 ++--- > drivers/media/platform/vsp1/vsp1_lif.c | 18 ++--- > drivers/media/platform/vsp1/vsp1_lut.c | 18 ++--- > drivers/media/platform/vsp1/vsp1_rwpf.c| 36 +- > drivers/media/platform/vsp1/vsp1_rwpf.h| 12 ++-- > drivers/media/platform/vsp1/vsp1_sru.c | 26 +++ > drivers/media/platform/vsp1/vsp1_uds.c | 26 +++ > drivers/media/v4l2-core/v4l2-subdev.c | 18 ++--- > drivers/staging/media/davinci_vpfe/dm365_ipipe.c | 49 +++-- > drivers/staging/media/davinci_vpfe/dm365_ipipeif.c | 47 ++--- > drivers/staging/media/davinci_vpfe/dm365_isif.c| 79 +- > drivers/staging/media/davinci_vpfe/dm365_resizer.c | 57 --- > drivers/staging/media/omap4iss/iss_csi2.c | 40 +-- > drivers/staging/media/omap4iss/iss_ipipe.c | 42 +-- > drivers/staging/media/omap4iss/iss_ipipeif.c | 48 ++--- > drivers/staging/media/omap4iss/iss_resizer.c | 42 +-- > include/media/v4l2-subdev.h| 50 +++-- > 48 files changed, 810 insertions(+), 797 deletions(-) -- Regards, Laurent Pinchart -- 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/majordo
Re: [PATCH] media: au0828: drop vbi_buffer_filled() and re-use buffer_filled()
Hi Prabhakar,
Thanks for getting to this before I could. Couple of comments,
mainly typos in commit log.
On 02/23/2015 08:06 AM, Lad Prabhakar wrote:
> From: "Lad, Prabhakar"
>
> The vbi_buffer_filled() and buffer_filled() did the same functionality
> except for incrementing the buffer sequence, this patch drops the
> vbi_buffer_filled() and re-uses buffer_filled() for vbi buffers
> aswell by adding the check for vb2-queue type while incrementing
as well
> the sequence numbers. Along side this patch aligns the code.
Not sure about this last line "aligns the code" - please elaborate.
I am guessing it is the input arguments in buffer_filled() function?
Otherwise looks good. You have my Acked-by once the commit log is fixed.
Acked-by: Shuah Khan
thanks,
-- Shuah
>
> Signed-off-by: Lad, Prabhakar
> ---
> drivers/media/usb/au0828/au0828-video.c | 36
> +
> 1 file changed, 14 insertions(+), 22 deletions(-)
>
> diff --git a/drivers/media/usb/au0828/au0828-video.c
> b/drivers/media/usb/au0828/au0828-video.c
> index a27cb5f..60012ec 100644
> --- a/drivers/media/usb/au0828/au0828-video.c
> +++ b/drivers/media/usb/au0828/au0828-video.c
> @@ -299,29 +299,23 @@ static int au0828_init_isoc(struct au0828_dev *dev, int
> max_packets,
> * Announces that a buffer were filled and request the next
> */
> static inline void buffer_filled(struct au0828_dev *dev,
> - struct au0828_dmaqueue *dma_q,
> - struct au0828_buffer *buf)
> + struct au0828_dmaqueue *dma_q,
> + struct au0828_buffer *buf)
> {
> - /* Advice that buffer was filled */
> - au0828_isocdbg("[%p/%d] wakeup\n", buf, buf->top_field);
> -
> - buf->vb.v4l2_buf.sequence = dev->frame_count++;
> - buf->vb.v4l2_buf.field = V4L2_FIELD_INTERLACED;
> - v4l2_get_timestamp(&buf->vb.v4l2_buf.timestamp);
> - vb2_buffer_done(&buf->vb, VB2_BUF_STATE_DONE);
> -}
> + struct vb2_buffer vb = buf->vb;
> + struct vb2_queue *q = vb.vb2_queue;
>
> -static inline void vbi_buffer_filled(struct au0828_dev *dev,
> - struct au0828_dmaqueue *dma_q,
> - struct au0828_buffer *buf)
> -{
> /* Advice that buffer was filled */
> au0828_isocdbg("[%p/%d] wakeup\n", buf, buf->top_field);
>
> - buf->vb.v4l2_buf.sequence = dev->vbi_frame_count++;
> - buf->vb.v4l2_buf.field = V4L2_FIELD_INTERLACED;
> - v4l2_get_timestamp(&buf->vb.v4l2_buf.timestamp);
> - vb2_buffer_done(&buf->vb, VB2_BUF_STATE_DONE);
> + if (q->type == V4L2_BUF_TYPE_VIDEO_CAPTURE)
> + vb.v4l2_buf.sequence = dev->frame_count++;
> + else
> + vb.v4l2_buf.sequence = dev->vbi_frame_count++;
> +
> + vb.v4l2_buf.field = V4L2_FIELD_INTERLACED;
> + v4l2_get_timestamp(&vb.v4l2_buf.timestamp);
> + vb2_buffer_done(&vb, VB2_BUF_STATE_DONE);
> }
>
> /*
> @@ -574,9 +568,7 @@ static inline int au0828_isoc_copy(struct au0828_dev
> *dev, struct urb *urb)
> if (fbyte & 0x40) {
> /* VBI */
> if (vbi_buf != NULL)
> - vbi_buffer_filled(dev,
> - vbi_dma_q,
> - vbi_buf);
> + buffer_filled(dev, vbi_dma_q, vbi_buf);
> vbi_get_next_buf(vbi_dma_q, &vbi_buf);
> if (vbi_buf == NULL)
> vbioutp = NULL;
> @@ -949,7 +941,7 @@ static void au0828_vbi_buffer_timeout(unsigned long data)
> if (buf != NULL) {
> vbi_data = vb2_plane_vaddr(&buf->vb, 0);
> memset(vbi_data, 0x00, buf->length);
> - vbi_buffer_filled(dev, dma_q, buf);
> + buffer_filled(dev, dma_q, buf);
> }
> vbi_get_next_buf(dma_q, &buf);
>
>
--
Shuah Khan
Sr. Linux Kernel Developer
Open Source Innovation 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: DVB Simulcrypt
On 23-02-15 15:21, Tycho Lürsen wrote: Op 23-02-15 om 13:44 schreef Rudy Zijlstra: On 23-02-15 12:21, Honza Petrouš wrote: 2015-02-23 11:31 GMT+01:00 Rudy Zijlstra : On 23-02-15 08:44, Honza Petrouš wrote: Hi Rudy. 2015-02-22 16:28 GMT+01:00 Rudy Zijlstra : Some more info On 21-02-15 22:30, Rudy Zijlstra wrote: Dears (Hans?) My setup, where the cable operator was using only irdeto, was working good. Then the cable operator merged with another, and now the networks are being merged. As a result, the encryption has moved from irdeto only to simulcyrpt with Irdeto and Nagra. Current status: - when i put the CA card in a STB, it works - when trying to record an encrypted channel from PC, it no longer works. Recording system has 3 tuners. All equal, all with same permissions on the smartcard. On cards 0 and 2 does not work, but card 1 does work, on all channels tested. Does it mean that descrambling is not working for you? If so, how do you manage descrambling? By CI-CAM module or by some "softcam" like oscam? Or do you record ENCRYPTED stream and decrypt the recordings later on? Each tuner has its own legal CI-CAM module. And yes, except for the second tuner descrambling no longer works I'm not much familiar with MythTV, so I'm guessing from the mux setup changes, but did you check to descramble the same channel on different tuners? To eliminate the particular change inside one service only. Of course there can be also software issue in CI-CAM module itself (fail in parsing PMT CA descriptors etc). TBH, I think it must be application layer issue, not kernel one. See above: Recording system has 3 tuners. All equal, all with same permissions on the smartcard. On cards 0 and 2 does not work, but card 1 does work, on all channels tested. additional finfo: i tested the same channel(s) on all 3 tuners. For now i have re-configured mythtv to use only the second tuner for encrypted channels. This does reduce scheduling flexibility though. Would to understand what makes the difference, so i can ask the right questions to MythTV developers. As the decryption does work with 1 tuner, i see 2 options: - depending on tuner id the default CA descriptor used is different, and this selection is not expoerted on API level (kernel issue) - application needs to select which CA to use (and currently does not do this) It should be the latter one. I'm also having Ziggo for provider, but always used FFdecsawrapper/Oscam for decryption (also legal in The Netherlands, providing you have a paid subscription) ECM CA system id's 0x604 or 0x602 (depending on your region) gets you Irdeto, while ECM CA system id's 0x1850 or 0x1801 get you Nagra. Correctly configured FFdecsa/Oscam can deal with it, MythTV probably cannot. Check it out at: http://www.dtvmonitor.com/nl/?guid=0BE90D25-BA46-7B93-FDCD-20EFC79691E0 That's a snapshot from today, monitored from Groningen. Tycho, thanks. looking at http://www.dtvmonitor.com/nl/ziggo-limburg the CA id for Iredeto are same in Limburg as in Groningen. And yes, my CAM's are for Irdeto and do not support Nagra. To my knowledge no valid Nagra CAM do exist for DVB-C Can FFdecsawrapper/Oscam be used in combination with MythTV? Cheers Rudy -- 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] media: am437x: Don't release OF node reference twice
Hi Laurent,
Thanks for the patch.
On Mon, Feb 23, 2015 at 2:49 PM, Laurent Pinchart
wrote:
> The remote port reference is released both at the end of the OF graph
> parsing loop, and in the error code path at the end of the function.
> Those two calls will release the same reference, causing the reference
> count to go negative.
>
> Fix the problem by removing the second call.
>
> Signed-off-by: Laurent Pinchart
Acked-by: Lad, Prabhakar
Thanks,
--Prabhakar Lad
> ---
> drivers/media/platform/am437x/am437x-vpfe.c | 5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)
>
> I've found this issue while reading the code, the patch hasn't been tested.
>
> diff --git a/drivers/media/platform/am437x/am437x-vpfe.c
> b/drivers/media/platform/am437x/am437x-vpfe.c
> index 56a5cb0..ce273b2 100644
> --- a/drivers/media/platform/am437x/am437x-vpfe.c
> +++ b/drivers/media/platform/am437x/am437x-vpfe.c
> @@ -2425,7 +2425,7 @@ static int vpfe_async_complete(struct
> v4l2_async_notifier *notifier)
> static struct vpfe_config *
> vpfe_get_pdata(struct platform_device *pdev)
> {
> - struct device_node *endpoint = NULL, *rem = NULL;
> + struct device_node *endpoint = NULL;
> struct v4l2_of_endpoint bus_cfg;
> struct vpfe_subdev_info *sdinfo;
> struct vpfe_config *pdata;
> @@ -2443,6 +2443,8 @@ vpfe_get_pdata(struct platform_device *pdev)
> return NULL;
>
> for (i = 0; ; i++) {
> + struct device_node *rem;
> +
> endpoint = of_graph_get_next_endpoint(pdev->dev.of_node,
> endpoint);
> if (!endpoint)
> @@ -2513,7 +2515,6 @@ vpfe_get_pdata(struct platform_device *pdev)
>
> done:
> of_node_put(endpoint);
> - of_node_put(rem);
> return NULL;
> }
>
> --
> Regards,
>
> Laurent Pinchart
>
--
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: [ANNOUNCE] media mini-summit on March, 26 in San Jose together with ELC
On 02/19/2015 09:05 PM, Mauro Carvalho Chehab wrote: > As discussed on our IRC #v4l channels and on the media ML, most of the > core developers will be again this year in San Jose - CA - USA for the > Embedded Linux Conference. > > There are several subjects that we've been discussing those days that > require a face to face meeting. > > So, We'll be doing a media mini-summit on March, 26 (Thursday) at the > Marriott San Jose. > > This time, Linux Foundation will be handling the subscriptions > for the event, via their registering site: > > https://www.regonline.com/register/login.aspx?eventID=1623927&MethodId=0&EventsessionId= > > So, you need to register for an "add-on" option as shown below: > > [ ] Linux Media Summit: > Please click here if you would like to attend Linux Media Summit. > Media Summit is the premier forum to discuss the Linux multimedia > development for webcams, audio and video streaming devices and > analog/digital TV support at the Linux Kernel and its userspace APIs. > > Date: Thursday, March 26, 2015 9:00 AM - 6:00 PM (Pacific Time) > > If you're already subscribed to the event, you can login using > the same URL, select your register and register for the Media > Summit. > > I hope to see you there! > > Ah, as usual, we'll be using the media-works...@linuxtv.org ML for > specific discussions about that, so the ones interested on participate > are requested to subscribe it, and to submit themes of interest to > the mailing lists. Please note that I posted a 'Request for topics' mail to the media-workshop mailinglist. If you are interested in attending the mini-summit, and if you have topics, then please subscribe to media-workshop mailinglist and post your suggestion there. You can subscribe to the media-workshop mailinglist here: http://www.linuxtv.org/cgi-bin/mailman/listinfo/media-workshop 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: [PATCH] [media] s5p-jpeg: Fix crash in jpeg isr due to multiple interrupts.
On 17/12/14 07:25, Tony K Nadackal wrote: > In case of corrupt images, multiple interrupts may occur > due to different error scenarios. > > Since we are removing the src and dest buffers in the first > interrupt itself, crash occurs in the second error interrupts. > > Disable the global interrupt before we start processing > the interrupt avoid the crash. > > Disable System interrupt in isr to avoid the crash below. Rather than disabling all interrupts, is there no way to check the interrupt reason from some status register and decide whether we return the buffers or just ignore the interrupt ? -- Thanks, Sylwester -- 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 04/12] [media] coda: bitstream payload is unsigned
kfifo_len is unsigned int, return it as such.
Signed-off-by: Philipp Zabel
---
drivers/media/platform/coda/coda.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/media/platform/coda/coda.h
b/drivers/media/platform/coda/coda.h
index 0c35cd5..499049f 100644
--- a/drivers/media/platform/coda/coda.h
+++ b/drivers/media/platform/coda/coda.h
@@ -284,7 +284,7 @@ const char *coda_product_name(int product);
int coda_check_firmware(struct coda_dev *dev);
-static inline int coda_get_bitstream_payload(struct coda_ctx *ctx)
+static inline unsigned int coda_get_bitstream_payload(struct coda_ctx *ctx)
{
return kfifo_len(&ctx->bitstream_fifo);
}
--
2.1.4
--
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 v2] [media] dvb core: only start media entity if not NULL
The logic there tries to start the media entity even if it
doesn't exist, causing this bug:
[ 314.356162] BUG: unable to handle kernel NULL pointer dereference at
0010
[ 314.356202] IP: []
media_entity_pipeline_start+0x1c/0x390 [media]
Reported-by: Gert-Jan van der Stroom
Signed-off-by: Mauro Carvalho Chehab
diff --git a/drivers/media/dvb-core/dvb_frontend.c
b/drivers/media/dvb-core/dvb_frontend.c
index d7d390c5c7c3..882ca417f328 100644
--- a/drivers/media/dvb-core/dvb_frontend.c
+++ b/drivers/media/dvb-core/dvb_frontend.c
@@ -714,7 +714,7 @@ static int dvb_frontend_thread(void *data)
/* FIXME: return an error if it fails */
dev_info(fe->dvb->device,
"proceeding with FE task\n");
- } else {
+ } else if (fepriv->pipe_start_entity) {
ret = media_entity_pipeline_start(fepriv->pipe_start_entity,
&fepriv->pipe);
if (ret)
@@ -832,7 +832,8 @@ restart:
}
#ifdef CONFIG_MEDIA_CONTROLLER_DVB
- media_entity_pipeline_stop(fepriv->pipe_start_entity);
+ if (fepriv->pipe_start_entity)
+ media_entity_pipeline_stop(fepriv->pipe_start_entity);
fepriv->pipe_start_entity = NULL;
#endif
--
2.1.0
--
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 09/12] [media] coda: remove duplicate error messages for buffer allocations
coda_alloc_aux_buf already prints an error, no need to print duplicate
error messages all over the place.
Signed-off-by: Philipp Zabel
---
drivers/media/platform/coda/coda-bit.c| 21 -
drivers/media/platform/coda/coda-common.c | 12 +++-
2 files changed, 7 insertions(+), 26 deletions(-)
diff --git a/drivers/media/platform/coda/coda-bit.c
b/drivers/media/platform/coda/coda-bit.c
index 0073f5a..2304158 100644
--- a/drivers/media/platform/coda/coda-bit.c
+++ b/drivers/media/platform/coda/coda-bit.c
@@ -402,10 +402,8 @@ static int coda_alloc_context_buffers(struct coda_ctx *ctx,
if (!ctx->parabuf.vaddr) {
ret = coda_alloc_context_buf(ctx, &ctx->parabuf,
CODA_PARA_BUF_SIZE, "parabuf");
- if (ret < 0) {
- v4l2_err(&dev->v4l2_dev, "failed to allocate parabuf");
+ if (ret < 0)
return ret;
- }
}
if (dev->devtype->product == CODA_DX6)
@@ -417,22 +415,15 @@ static int coda_alloc_context_buffers(struct coda_ctx
*ctx,
DIV_ROUND_UP(q_data->height, 16)) * 3200 / 8 + 512;
ret = coda_alloc_context_buf(ctx, &ctx->slicebuf, size,
"slicebuf");
- if (ret < 0) {
- v4l2_err(&dev->v4l2_dev,
-"failed to allocate %d byte slice buffer",
-ctx->slicebuf.size);
+ if (ret < 0)
goto err;
- }
}
if (!ctx->psbuf.vaddr && dev->devtype->product == CODA_7541) {
ret = coda_alloc_context_buf(ctx, &ctx->psbuf,
CODA7_PS_BUF_SIZE, "psbuf");
- if (ret < 0) {
- v4l2_err(&dev->v4l2_dev,
-"failed to allocate psmem buffer");
+ if (ret < 0)
goto err;
- }
}
if (!ctx->workbuf.vaddr) {
@@ -442,12 +433,8 @@ static int coda_alloc_context_buffers(struct coda_ctx *ctx,
size += CODA9_PS_SAVE_SIZE;
ret = coda_alloc_context_buf(ctx, &ctx->workbuf, size,
"workbuf");
- if (ret < 0) {
- v4l2_err(&dev->v4l2_dev,
-"failed to allocate %d byte context buffer",
-ctx->workbuf.size);
+ if (ret < 0)
goto err;
- }
}
return 0;
diff --git a/drivers/media/platform/coda/coda-common.c
b/drivers/media/platform/coda/coda-common.c
index 172805b..b42ccfc 100644
--- a/drivers/media/platform/coda/coda-common.c
+++ b/drivers/media/platform/coda/coda-common.c
@@ -1925,10 +1925,8 @@ static void coda_fw_callback(const struct firmware *fw,
void *context)
/* allocate auxiliary per-device code buffer for the BIT processor */
ret = coda_alloc_aux_buf(dev, &dev->codebuf, fw->size, "codebuf",
dev->debugfs_root);
- if (ret < 0) {
- dev_err(&pdev->dev, "failed to allocate code buffer\n");
+ if (ret < 0)
goto put_pm;
- }
/* Copy the whole firmware image to the code buffer */
memcpy(dev->codebuf.vaddr, fw->data, fw->size);
@@ -2166,20 +2164,16 @@ static int coda_probe(struct platform_device *pdev)
ret = coda_alloc_aux_buf(dev, &dev->workbuf,
dev->devtype->workbuf_size, "workbuf",
dev->debugfs_root);
- if (ret < 0) {
- dev_err(&pdev->dev, "failed to allocate work buffer\n");
+ if (ret < 0)
goto err_v4l2_register;
- }
}
if (dev->devtype->tempbuf_size) {
ret = coda_alloc_aux_buf(dev, &dev->tempbuf,
dev->devtype->tempbuf_size, "tempbuf",
dev->debugfs_root);
- if (ret < 0) {
- dev_err(&pdev->dev, "failed to allocate temp buffer\n");
+ if (ret < 0)
goto err_v4l2_register;
- }
}
dev->iram.size = dev->devtype->iram_size;
--
2.1.4
--
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 03/12] [media] coda: free decoder bitstream buffer
From: Peter Seiderer
Fixes resource leak preventing repeatedly decoding.
Signed-off-by: Peter Seiderer
Signed-off-by: Philipp Zabel
---
drivers/media/platform/coda/coda-bit.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/media/platform/coda/coda-bit.c
b/drivers/media/platform/coda/coda-bit.c
index 856b542..3801a37 100644
--- a/drivers/media/platform/coda/coda-bit.c
+++ b/drivers/media/platform/coda/coda-bit.c
@@ -36,6 +36,8 @@
#define CODA_DEFAULT_GAMMA 4096
#define CODA9_DEFAULT_GAMMA24576 /* 0.75 * 32768 */
+static void coda_free_bitstream_buffer(struct coda_ctx *ctx);
+
static inline int coda_is_initialized(struct coda_dev *dev)
{
return coda_read(dev, CODA_REG_BIT_CUR_PC) != 0;
@@ -1322,6 +1324,7 @@ static void coda_bit_release(struct coda_ctx *ctx)
mutex_lock(&ctx->buffer_mutex);
coda_free_framebuffers(ctx);
coda_free_context_buffers(ctx);
+ coda_free_bitstream_buffer(ctx);
mutex_unlock(&ctx->buffer_mutex);
}
--
2.1.4
--
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 02/12] [media] coda: fix double call to debugfs_remove
From: Peter Seiderer In coda_free_aux_buf() call debugfs_remove only if buffer entry is valid (and therfore dentry is valid), double protect by invalidating dentry value. Fixes erroneous prematurely dealloc of debugfs caused by incorrect reference count incrementing. Signed-off-by: Peter Seiderer Signed-off-by: Philipp Zabel --- drivers/media/platform/coda/coda-common.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/media/platform/coda/coda-common.c b/drivers/media/platform/coda/coda-common.c index c81af1b..37bbd57 100644 --- a/drivers/media/platform/coda/coda-common.c +++ b/drivers/media/platform/coda/coda-common.c @@ -1215,8 +1215,9 @@ void coda_free_aux_buf(struct coda_dev *dev, buf->vaddr, buf->paddr); buf->vaddr = NULL; buf->size = 0; + debugfs_remove(buf->dentry); + buf->dentry = NULL; } - debugfs_remove(buf->dentry); } static int coda_start_streaming(struct vb2_queue *q, unsigned int count) -- 2.1.4 -- 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 08/12] [media] coda: move parameter buffer in together with context buffer allocation
The parameter buffer is a per-context buffer, so we can allocate and free it
together with the other context buffers during REQBUFS.
Since this was the last context buffer allocated in coda-common.c, we can now
move coda_alloc_context_buf into coda-bit.c.
Signed-off-by: Philipp Zabel
---
drivers/media/platform/coda/coda-bit.c| 21 -
drivers/media/platform/coda/coda-common.c | 12
drivers/media/platform/coda/coda.h| 7 ---
3 files changed, 20 insertions(+), 20 deletions(-)
diff --git a/drivers/media/platform/coda/coda-bit.c
b/drivers/media/platform/coda/coda-bit.c
index 5aa8d87..0073f5a 100644
--- a/drivers/media/platform/coda/coda-bit.c
+++ b/drivers/media/platform/coda/coda-bit.c
@@ -31,6 +31,7 @@
#include "coda.h"
+#define CODA_PARA_BUF_SIZE (10 * 1024)
#define CODA7_PS_BUF_SIZE 0x28000
#define CODA9_PS_SAVE_SIZE (512 * 1024)
@@ -300,6 +301,14 @@ static void coda_parabuf_write(struct coda_ctx *ctx, int
index, u32 value)
p[index ^ 1] = value;
}
+static inline int coda_alloc_context_buf(struct coda_ctx *ctx,
+struct coda_aux_buf *buf, size_t size,
+const char *name)
+{
+ return coda_alloc_aux_buf(ctx->dev, buf, size, name,
ctx->debugfs_entry);
+}
+
+
static void coda_free_framebuffers(struct coda_ctx *ctx)
{
int i;
@@ -380,6 +389,7 @@ static void coda_free_context_buffers(struct coda_ctx *ctx)
coda_free_aux_buf(dev, &ctx->psbuf);
if (dev->devtype->product != CODA_DX6)
coda_free_aux_buf(dev, &ctx->workbuf);
+ coda_free_aux_buf(dev, &ctx->parabuf);
}
static int coda_alloc_context_buffers(struct coda_ctx *ctx,
@@ -389,6 +399,15 @@ static int coda_alloc_context_buffers(struct coda_ctx *ctx,
size_t size;
int ret;
+ if (!ctx->parabuf.vaddr) {
+ ret = coda_alloc_context_buf(ctx, &ctx->parabuf,
+CODA_PARA_BUF_SIZE, "parabuf");
+ if (ret < 0) {
+ v4l2_err(&dev->v4l2_dev, "failed to allocate parabuf");
+ return ret;
+ }
+ }
+
if (dev->devtype->product == CODA_DX6)
return 0;
@@ -402,7 +421,7 @@ static int coda_alloc_context_buffers(struct coda_ctx *ctx,
v4l2_err(&dev->v4l2_dev,
"failed to allocate %d byte slice buffer",
ctx->slicebuf.size);
- return ret;
+ goto err;
}
}
diff --git a/drivers/media/platform/coda/coda-common.c
b/drivers/media/platform/coda/coda-common.c
index b34a0db..172805b 100644
--- a/drivers/media/platform/coda/coda-common.c
+++ b/drivers/media/platform/coda/coda-common.c
@@ -46,7 +46,6 @@
#define CODADX6_MAX_INSTANCES 4
#define CODA_MAX_FORMATS 4
-#define CODA_PARA_BUF_SIZE (10 * 1024)
#define CODA_ISRAM_SIZE(2048 * 2)
#define MIN_W 176
@@ -1708,14 +1707,6 @@ static int coda_open(struct file *file)
ctx->fh.ctrl_handler = &ctx->ctrls;
- if (ctx->use_bit) {
- ret = coda_alloc_context_buf(ctx, &ctx->parabuf,
-CODA_PARA_BUF_SIZE, "parabuf");
- if (ret < 0) {
- v4l2_err(&dev->v4l2_dev, "failed to allocate parabuf");
- goto err_dma_alloc;
- }
- }
mutex_init(&ctx->bitstream_mutex);
mutex_init(&ctx->buffer_mutex);
INIT_LIST_HEAD(&ctx->buffer_meta_list);
@@ -1729,8 +1720,6 @@ static int coda_open(struct file *file)
return 0;
-err_dma_alloc:
- v4l2_ctrl_handler_free(&ctx->ctrls);
err_ctrls_setup:
v4l2_m2m_ctx_release(ctx->fh.m2m_ctx);
err_ctx_init:
@@ -1776,7 +1765,6 @@ static int coda_release(struct file *file)
if (ctx->dev->devtype->product == CODA_DX6)
coda_free_aux_buf(dev, &ctx->workbuf);
- coda_free_aux_buf(dev, &ctx->parabuf);
v4l2_ctrl_handler_free(&ctx->ctrls);
clk_disable_unprepare(dev->clk_ahb);
clk_disable_unprepare(dev->clk_per);
diff --git a/drivers/media/platform/coda/coda.h
b/drivers/media/platform/coda/coda.h
index 01d940c..2b59e16 100644
--- a/drivers/media/platform/coda/coda.h
+++ b/drivers/media/platform/coda/coda.h
@@ -249,13 +249,6 @@ int coda_alloc_aux_buf(struct coda_dev *dev, struct
coda_aux_buf *buf,
size_t size, const char *name, struct dentry *parent);
void coda_free_aux_buf(struct coda_dev *dev, struct coda_aux_buf *buf);
-static inline int coda_alloc_context_buf(struct coda_ctx *ctx,
-struct coda_aux_buf *buf, size_t size,
-const char *name)
-{
- return coda_alloc_aux_buf(ctx->dev, buf, size, name,
ctx->debugf
[PATCH 06/12] [media] coda: allocate per-context buffers from REQBUFS
Allocate the per-context buffers from REQBUFS instead in start_encoding or
start_decoding. This allows to stop and start streaming independently of
buffer (re)allocation
Signed-off-by: Philipp Zabel
---
drivers/media/platform/coda/coda-bit.c| 55 ---
drivers/media/platform/coda/coda-common.c | 22 -
drivers/media/platform/coda/coda.h| 1 +
3 files changed, 66 insertions(+), 12 deletions(-)
diff --git a/drivers/media/platform/coda/coda-bit.c
b/drivers/media/platform/coda/coda-bit.c
index 3801a37..ce64c91 100644
--- a/drivers/media/platform/coda/coda-bit.c
+++ b/drivers/media/platform/coda/coda-bit.c
@@ -711,6 +711,27 @@ err_clk_per:
* Encoder context operations
*/
+static int coda_encoder_reqbufs(struct coda_ctx *ctx,
+ struct v4l2_requestbuffers *rb)
+{
+ struct coda_q_data *q_data_src;
+ int ret;
+
+ if (rb->type != V4L2_BUF_TYPE_VIDEO_OUTPUT)
+ return 0;
+
+ if (rb->count) {
+ q_data_src = get_q_data(ctx, V4L2_BUF_TYPE_VIDEO_OUTPUT);
+ ret = coda_alloc_context_buffers(ctx, q_data_src);
+ if (ret < 0)
+ return ret;
+ } else {
+ coda_free_context_buffers(ctx);
+ }
+
+ return 0;
+}
+
static int coda_start_encoding(struct coda_ctx *ctx)
{
struct coda_dev *dev = ctx->dev;
@@ -727,11 +748,6 @@ static int coda_start_encoding(struct coda_ctx *ctx)
q_data_dst = get_q_data(ctx, V4L2_BUF_TYPE_VIDEO_CAPTURE);
dst_fourcc = q_data_dst->fourcc;
- /* Allocate per-instance buffers */
- ret = coda_alloc_context_buffers(ctx, q_data_src);
- if (ret < 0)
- return ret;
-
buf = v4l2_m2m_next_dst_buf(ctx->fh.m2m_ctx);
bitstream_buf = vb2_dma_contig_plane_dma_addr(buf, 0);
bitstream_size = q_data_dst->sizeimage;
@@ -1313,7 +1329,6 @@ static void coda_seq_end_work(struct work_struct *work)
ctx->bitstream.vaddr, ctx->bitstream.size);
coda_free_framebuffers(ctx);
- coda_free_context_buffers(ctx);
mutex_unlock(&dev->coda_mutex);
mutex_unlock(&ctx->buffer_mutex);
@@ -1330,6 +1345,7 @@ static void coda_bit_release(struct coda_ctx *ctx)
const struct coda_context_ops coda_bit_encode_ops = {
.queue_init = coda_encoder_queue_init,
+ .reqbufs = coda_encoder_reqbufs,
.start_streaming = coda_start_encoding,
.prepare_run = coda_prepare_encode,
.finish_run = coda_finish_encode,
@@ -1341,6 +1357,27 @@ const struct coda_context_ops coda_bit_encode_ops = {
* Decoder context operations
*/
+static int coda_decoder_reqbufs(struct coda_ctx *ctx,
+ struct v4l2_requestbuffers *rb)
+{
+ struct coda_q_data *q_data_src;
+ int ret;
+
+ if (rb->type != V4L2_BUF_TYPE_VIDEO_OUTPUT)
+ return 0;
+
+ if (rb->count) {
+ q_data_src = get_q_data(ctx, V4L2_BUF_TYPE_VIDEO_OUTPUT);
+ ret = coda_alloc_context_buffers(ctx, q_data_src);
+ if (ret < 0)
+ return ret;
+ } else {
+ coda_free_context_buffers(ctx);
+ }
+
+ return 0;
+}
+
static int __coda_start_decoding(struct coda_ctx *ctx)
{
struct coda_q_data *q_data_src, *q_data_dst;
@@ -1359,11 +1396,6 @@ static int __coda_start_decoding(struct coda_ctx *ctx)
src_fourcc = q_data_src->fourcc;
dst_fourcc = q_data_dst->fourcc;
- /* Allocate per-instance buffers */
- ret = coda_alloc_context_buffers(ctx, q_data_src);
- if (ret < 0)
- return ret;
-
coda_write(dev, ctx->parabuf.paddr, CODA_REG_BIT_PARA_BUF_ADDR);
/* Update coda bitstream read and write pointers from kfifo */
@@ -1909,6 +1941,7 @@ static void coda_finish_decode(struct coda_ctx *ctx)
const struct coda_context_ops coda_bit_decode_ops = {
.queue_init = coda_decoder_queue_init,
+ .reqbufs = coda_decoder_reqbufs,
.start_streaming = coda_start_decoding,
.prepare_run = coda_prepare_decode,
.finish_run = coda_finish_decode,
diff --git a/drivers/media/platform/coda/coda-common.c
b/drivers/media/platform/coda/coda-common.c
index 04130ea..0026e3a 100644
--- a/drivers/media/platform/coda/coda-common.c
+++ b/drivers/media/platform/coda/coda-common.c
@@ -696,6 +696,26 @@ static int coda_s_fmt_vid_out(struct file *file, void
*priv,
return coda_s_fmt(ctx, &f_cap);
}
+static int coda_reqbufs(struct file *file, void *priv,
+ struct v4l2_requestbuffers *rb)
+{
+ struct coda_ctx *ctx = fh_to_ctx(priv);
+ int ret;
+
+ ret = v4l2_m2m_reqbufs(file, ctx->fh.m2m_ctx, rb);
+ if (ret)
+ return ret;
+
+ /*
+* Allow to allocate instance specific per-context buffers, such as
+* bitstream ringbuffer, slice buffer, work b
[PATCH 07/12] [media] coda: allocate bitstream buffer from REQBUFS, size depends on the format
Allocating the bitstream buffer only when the format is set allows to guarantee
that at least two frames fit into the bitstream buffer. For small frame sizes
a smaller bitstream buffer can be allocated. Since the bitstream buffer size now
depends on the format, replace CODA_MAX_FRAME_SIZE with ctx->bitstream.size
where appropriate and remove the now unused constant.
Since REQBUFS can be called multiple times, but the format can't be changed
unless REQBUFS 0 was called before, we can just keep the allocated context and
bitstream buffers if REQBUFS is called multiple times with a non-zero buffer
count.
Signed-off-by: Philipp Zabel
---
drivers/media/platform/coda/coda-bit.c| 82 +--
drivers/media/platform/coda/coda-common.c | 22 -
drivers/media/platform/coda/coda.h| 1 -
3 files changed, 55 insertions(+), 50 deletions(-)
diff --git a/drivers/media/platform/coda/coda-bit.c
b/drivers/media/platform/coda/coda-bit.c
index ce64c91..5aa8d87 100644
--- a/drivers/media/platform/coda/coda-bit.c
+++ b/drivers/media/platform/coda/coda-bit.c
@@ -15,6 +15,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -391,21 +392,7 @@ static int coda_alloc_context_buffers(struct coda_ctx *ctx,
if (dev->devtype->product == CODA_DX6)
return 0;
- if (ctx->psbuf.vaddr) {
- v4l2_err(&dev->v4l2_dev, "psmembuf still allocated\n");
- return -EBUSY;
- }
- if (ctx->slicebuf.vaddr) {
- v4l2_err(&dev->v4l2_dev, "slicebuf still allocated\n");
- return -EBUSY;
- }
- if (ctx->workbuf.vaddr) {
- v4l2_err(&dev->v4l2_dev, "context buffer still allocated\n");
- ret = -EBUSY;
- return -ENOMEM;
- }
-
- if (q_data->fourcc == V4L2_PIX_FMT_H264) {
+ if (!ctx->slicebuf.vaddr && q_data->fourcc == V4L2_PIX_FMT_H264) {
/* worst case slice size */
size = (DIV_ROUND_UP(q_data->width, 16) *
DIV_ROUND_UP(q_data->height, 16)) * 3200 / 8 + 512;
@@ -419,7 +406,7 @@ static int coda_alloc_context_buffers(struct coda_ctx *ctx,
}
}
- if (dev->devtype->product == CODA_7541) {
+ if (!ctx->psbuf.vaddr && dev->devtype->product == CODA_7541) {
ret = coda_alloc_context_buf(ctx, &ctx->psbuf,
CODA7_PS_BUF_SIZE, "psbuf");
if (ret < 0) {
@@ -429,16 +416,19 @@ static int coda_alloc_context_buffers(struct coda_ctx
*ctx,
}
}
- size = dev->devtype->workbuf_size;
- if (dev->devtype->product == CODA_960 &&
- q_data->fourcc == V4L2_PIX_FMT_H264)
- size += CODA9_PS_SAVE_SIZE;
- ret = coda_alloc_context_buf(ctx, &ctx->workbuf, size, "workbuf");
- if (ret < 0) {
- v4l2_err(&dev->v4l2_dev,
-"failed to allocate %d byte context buffer",
-ctx->workbuf.size);
- goto err;
+ if (!ctx->workbuf.vaddr) {
+ size = dev->devtype->workbuf_size;
+ if (dev->devtype->product == CODA_960 &&
+ q_data->fourcc == V4L2_PIX_FMT_H264)
+ size += CODA9_PS_SAVE_SIZE;
+ ret = coda_alloc_context_buf(ctx, &ctx->workbuf, size,
+"workbuf");
+ if (ret < 0) {
+ v4l2_err(&dev->v4l2_dev,
+"failed to allocate %d byte context buffer",
+ctx->workbuf.size);
+ goto err;
+ }
}
return 0;
@@ -1357,6 +1347,38 @@ const struct coda_context_ops coda_bit_encode_ops = {
* Decoder context operations
*/
+static int coda_alloc_bitstream_buffer(struct coda_ctx *ctx,
+ struct coda_q_data *q_data)
+{
+ if (ctx->bitstream.vaddr)
+ return 0;
+
+ ctx->bitstream.size = roundup_pow_of_two(q_data->sizeimage * 2);
+ ctx->bitstream.vaddr = dma_alloc_writecombine(
+ &ctx->dev->plat_dev->dev, ctx->bitstream.size,
+ &ctx->bitstream.paddr, GFP_KERNEL);
+ if (!ctx->bitstream.vaddr) {
+ v4l2_err(&ctx->dev->v4l2_dev,
+"failed to allocate bitstream ringbuffer");
+ return -ENOMEM;
+ }
+ kfifo_init(&ctx->bitstream_fifo,
+ ctx->bitstream.vaddr, ctx->bitstream.size);
+
+ return 0;
+}
+
+static void coda_free_bitstream_buffer(struct coda_ctx *ctx)
+{
+ if (ctx->bitstream.vaddr == NULL)
+ return;
+
+ dma_free_writecombine(&ctx->dev->plat_dev->dev, ctx->bitstream.size,
+ ctx->bitstream.vaddr, ctx->bitstream.paddr);
+ ctx->bitstream.vaddr = NULL;
+
[PATCH 12/12] [media] coda: fix fill bitstream errors in nonstreaming case
From: Philipp Zabel
When queueing a buffer into the bitstream fails, it has to be requeued
in the videobuf2 queue before streaming starts, but while streaming it
should be returned to userspace with an error.
Signed-off-by: Philipp Zabel
---
drivers/media/platform/coda/coda-bit.c| 11 +++
drivers/media/platform/coda/coda-common.c | 6 +++---
drivers/media/platform/coda/coda.h| 2 +-
3 files changed, 11 insertions(+), 8 deletions(-)
diff --git a/drivers/media/platform/coda/coda-bit.c
b/drivers/media/platform/coda/coda-bit.c
index 2304158..d39789d 100644
--- a/drivers/media/platform/coda/coda-bit.c
+++ b/drivers/media/platform/coda/coda-bit.c
@@ -218,7 +218,7 @@ static bool coda_bitstream_try_queue(struct coda_ctx *ctx,
return true;
}
-void coda_fill_bitstream(struct coda_ctx *ctx)
+void coda_fill_bitstream(struct coda_ctx *ctx, bool streaming)
{
struct vb2_buffer *src_buf;
struct coda_buffer_meta *meta;
@@ -239,9 +239,12 @@ void coda_fill_bitstream(struct coda_ctx *ctx)
if (ctx->codec->src_fourcc == V4L2_PIX_FMT_JPEG &&
!coda_jpeg_check_buffer(ctx, src_buf)) {
v4l2_err(&ctx->dev->v4l2_dev,
-"dropping invalid JPEG frame\n");
+"dropping invalid JPEG frame %d\n",
+ctx->qsequence);
src_buf = v4l2_m2m_src_buf_remove(ctx->fh.m2m_ctx);
- v4l2_m2m_buf_done(src_buf, VB2_BUF_STATE_ERROR);
+ v4l2_m2m_buf_done(src_buf, streaming ?
+ VB2_BUF_STATE_ERROR :
+ VB2_BUF_STATE_QUEUED);
continue;
}
@@ -1648,7 +1651,7 @@ static int coda_prepare_decode(struct coda_ctx *ctx)
/* Try to copy source buffer contents into the bitstream ringbuffer */
mutex_lock(&ctx->bitstream_mutex);
- coda_fill_bitstream(ctx);
+ coda_fill_bitstream(ctx, true);
mutex_unlock(&ctx->bitstream_mutex);
if (coda_get_bitstream_payload(ctx) < 512 &&
diff --git a/drivers/media/platform/coda/coda-common.c
b/drivers/media/platform/coda/coda-common.c
index 54c972f..5e159da 100644
--- a/drivers/media/platform/coda/coda-common.c
+++ b/drivers/media/platform/coda/coda-common.c
@@ -1192,7 +1192,7 @@ static void coda_buf_queue(struct vb2_buffer *vb)
mutex_lock(&ctx->bitstream_mutex);
v4l2_m2m_buf_queue(ctx->fh.m2m_ctx, vb);
if (vb2_is_streaming(vb->vb2_queue))
- coda_fill_bitstream(ctx);
+ coda_fill_bitstream(ctx, true);
mutex_unlock(&ctx->bitstream_mutex);
} else {
v4l2_m2m_buf_queue(ctx->fh.m2m_ctx, vb);
@@ -1252,9 +1252,9 @@ static int coda_start_streaming(struct vb2_queue *q,
unsigned int count)
if (q_data_src->fourcc == V4L2_PIX_FMT_H264 ||
(q_data_src->fourcc == V4L2_PIX_FMT_JPEG &&
ctx->dev->devtype->product == CODA_7541)) {
- /* copy the buffers that where queued before streamon */
+ /* copy the buffers that were queued before streamon */
mutex_lock(&ctx->bitstream_mutex);
- coda_fill_bitstream(ctx);
+ coda_fill_bitstream(ctx, false);
mutex_unlock(&ctx->bitstream_mutex);
if (coda_get_bitstream_payload(ctx) < 512) {
diff --git a/drivers/media/platform/coda/coda.h
b/drivers/media/platform/coda/coda.h
index 2b59e16..970f0b3 100644
--- a/drivers/media/platform/coda/coda.h
+++ b/drivers/media/platform/coda/coda.h
@@ -256,7 +256,7 @@ int coda_decoder_queue_init(void *priv, struct vb2_queue
*src_vq,
int coda_hw_reset(struct coda_ctx *ctx);
-void coda_fill_bitstream(struct coda_ctx *ctx);
+void coda_fill_bitstream(struct coda_ctx *ctx, bool streaming);
void coda_set_gdi_regs(struct coda_ctx *ctx);
--
2.1.4
--
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 10/12] [media] coda: fail to start streaming if userspace set invalid formats
Signed-off-by: Philipp Zabel
---
drivers/media/platform/coda/coda-common.c | 13 -
1 file changed, 12 insertions(+), 1 deletion(-)
diff --git a/drivers/media/platform/coda/coda-common.c
b/drivers/media/platform/coda/coda-common.c
index b42ccfc..4441179 100644
--- a/drivers/media/platform/coda/coda-common.c
+++ b/drivers/media/platform/coda/coda-common.c
@@ -1282,12 +1282,23 @@ static int coda_start_streaming(struct vb2_queue *q,
unsigned int count)
if (!(ctx->streamon_out & ctx->streamon_cap))
return 0;
+ q_data_dst = get_q_data(ctx, V4L2_BUF_TYPE_VIDEO_CAPTURE);
+ if ((q_data_src->width != q_data_dst->width &&
+round_up(q_data_src->width, 16) != q_data_dst->width) ||
+ (q_data_src->height != q_data_dst->height &&
+round_up(q_data_src->height, 16) != q_data_dst->height)) {
+ v4l2_err(v4l2_dev, "can't convert %dx%d to %dx%d\n",
+q_data_src->width, q_data_src->height,
+q_data_dst->width, q_data_dst->height);
+ ret = -EINVAL;
+ goto err;
+ }
+
/* Allow BIT decoder device_run with no new buffers queued */
if (ctx->inst_type == CODA_INST_DECODER && ctx->use_bit)
v4l2_m2m_set_src_buffered(ctx->fh.m2m_ctx, true);
ctx->gopcounter = ctx->params.gop_size - 1;
- q_data_dst = get_q_data(ctx, V4L2_BUF_TYPE_VIDEO_CAPTURE);
ctx->codec = coda_find_codec(ctx->dev, q_data_src->fourcc,
q_data_dst->fourcc);
--
2.1.4
--
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 05/12] [media] coda: use strlcpy instead of snprintf
There is no need to take the detour through a "%s" format string to create a copy of a string. Signed-off-by: Philipp Zabel --- drivers/media/platform/coda/coda-common.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/drivers/media/platform/coda/coda-common.c b/drivers/media/platform/coda/coda-common.c index 37bbd57..04130ea 100644 --- a/drivers/media/platform/coda/coda-common.c +++ b/drivers/media/platform/coda/coda-common.c @@ -1908,8 +1908,7 @@ static int coda_register_device(struct coda_dev *dev, int i) if (i >= dev->devtype->num_vdevs) return -EINVAL; - snprintf(vfd->name, sizeof(vfd->name), "%s", -dev->devtype->vdevs[i]->name); + strlcpy(vfd->name, dev->devtype->vdevs[i]->name, sizeof(vfd->name)); vfd->fops = &coda_fops; vfd->ioctl_ops = &coda_ioctl_ops; vfd->release= video_device_release_empty, -- 2.1.4 -- 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 11/12] [media] coda: call SEQ_END when the first queue is stopped
This allows to stop and restart the output queue to start a new sequence
while keeping the capture queue running. Before, sequence end would only
be issued if both output and capture queue were stopped and the sequence
start issued when reenabling the output queue would fail.
Signed-off-by: Philipp Zabel
---
drivers/media/platform/coda/coda-common.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/media/platform/coda/coda-common.c
b/drivers/media/platform/coda/coda-common.c
index 4441179..54c972f 100644
--- a/drivers/media/platform/coda/coda-common.c
+++ b/drivers/media/platform/coda/coda-common.c
@@ -1339,6 +1339,9 @@ static void coda_stop_streaming(struct vb2_queue *q)
struct coda_ctx *ctx = vb2_get_drv_priv(q);
struct coda_dev *dev = ctx->dev;
struct vb2_buffer *buf;
+ bool stop;
+
+ stop = ctx->streamon_out && ctx->streamon_cap;
if (q->type == V4L2_BUF_TYPE_VIDEO_OUTPUT) {
v4l2_dbg(1, coda_debug, &dev->v4l2_dev,
@@ -1363,7 +1366,7 @@ static void coda_stop_streaming(struct vb2_queue *q)
v4l2_m2m_buf_done(buf, VB2_BUF_STATE_ERROR);
}
- if (!ctx->streamon_out && !ctx->streamon_cap) {
+ if (stop) {
struct coda_buffer_meta *meta;
if (ctx->ops->seq_end_work) {
--
2.1.4
--
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 01/12] [media] coda: check kasprintf return value in coda_open
From: Peter Seiderer
kasprintf might fail if free memory is low.
Signed-off-by: Peter Seiderer
Signed-off-by: Philipp Zabel
---
drivers/media/platform/coda/coda-common.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/media/platform/coda/coda-common.c
b/drivers/media/platform/coda/coda-common.c
index 6f32e6d..c81af1b 100644
--- a/drivers/media/platform/coda/coda-common.c
+++ b/drivers/media/platform/coda/coda-common.c
@@ -1621,6 +1621,11 @@ static int coda_open(struct file *file)
set_bit(idx, &dev->instance_mask);
name = kasprintf(GFP_KERNEL, "context%d", idx);
+ if (!name) {
+ ret = -ENOMEM;
+ goto err_coda_name_init;
+ }
+
ctx->debugfs_entry = debugfs_create_dir(name, dev->debugfs_root);
kfree(name);
@@ -1735,6 +1740,7 @@ err_pm_get:
v4l2_fh_del(&ctx->fh);
v4l2_fh_exit(&ctx->fh);
clear_bit(ctx->idx, &dev->instance_mask);
+err_coda_name_init:
err_coda_max:
kfree(ctx);
return ret;
--
2.1.4
--
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 00/12] CODA fixes and buffer allocation in REQBUFS
Hi, this is a series of various fixes and a move of the per-context buffer allocation into the REQBUFS call. Allocating the bitstream buffer only after S_FMT allows at the same time to guarantee that the bitstream buffer is always large enough to contain two worst-case compressed frames and doesn't waste memory if a small format is selected. Peter Seiderer (3): [media] coda: check kasprintf return value in coda_open [media] coda: fix double call to debugfs_remove [media] coda: free decoder bitstream buffer Philipp Zabel (9): [media] coda: bitstream payload is unsigned [media] coda: use strlcpy instead of snprintf [media] coda: allocate per-context buffers from REQBUFS [media] coda: allocate bitstream buffer from REQBUFS, size depends on the format [media] coda: move parameter buffer in together with context buffer allocation [media] coda: remove duplicate error messages for buffer allocations [media] coda: fail to start streaming if userspace set invalid formats [media] coda: call SEQ_END when the first queue is stopped [media] coda: fix fill bitstream errors in nonstreaming case drivers/media/platform/coda/coda-bit.c| 177 +- drivers/media/platform/coda/coda-common.c | 104 +- drivers/media/platform/coda/coda.h| 13 +-- 3 files changed, 180 insertions(+), 114 deletions(-) -- 2.1.4 -- 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] media: au0828: drop vbi_buffer_filled() and re-use buffer_filled()
From: "Lad, Prabhakar"
The vbi_buffer_filled() and buffer_filled() did the same functionality
except for incrementing the buffer sequence, this patch drops the
vbi_buffer_filled() and re-uses buffer_filled() for vbi buffers
aswell by adding the check for vb2-queue type while incrementing
the sequence numbers. Along side this patch aligns the code.
Signed-off-by: Lad, Prabhakar
---
drivers/media/usb/au0828/au0828-video.c | 36 +
1 file changed, 14 insertions(+), 22 deletions(-)
diff --git a/drivers/media/usb/au0828/au0828-video.c
b/drivers/media/usb/au0828/au0828-video.c
index a27cb5f..60012ec 100644
--- a/drivers/media/usb/au0828/au0828-video.c
+++ b/drivers/media/usb/au0828/au0828-video.c
@@ -299,29 +299,23 @@ static int au0828_init_isoc(struct au0828_dev *dev, int
max_packets,
* Announces that a buffer were filled and request the next
*/
static inline void buffer_filled(struct au0828_dev *dev,
- struct au0828_dmaqueue *dma_q,
- struct au0828_buffer *buf)
+struct au0828_dmaqueue *dma_q,
+struct au0828_buffer *buf)
{
- /* Advice that buffer was filled */
- au0828_isocdbg("[%p/%d] wakeup\n", buf, buf->top_field);
-
- buf->vb.v4l2_buf.sequence = dev->frame_count++;
- buf->vb.v4l2_buf.field = V4L2_FIELD_INTERLACED;
- v4l2_get_timestamp(&buf->vb.v4l2_buf.timestamp);
- vb2_buffer_done(&buf->vb, VB2_BUF_STATE_DONE);
-}
+ struct vb2_buffer vb = buf->vb;
+ struct vb2_queue *q = vb.vb2_queue;
-static inline void vbi_buffer_filled(struct au0828_dev *dev,
-struct au0828_dmaqueue *dma_q,
-struct au0828_buffer *buf)
-{
/* Advice that buffer was filled */
au0828_isocdbg("[%p/%d] wakeup\n", buf, buf->top_field);
- buf->vb.v4l2_buf.sequence = dev->vbi_frame_count++;
- buf->vb.v4l2_buf.field = V4L2_FIELD_INTERLACED;
- v4l2_get_timestamp(&buf->vb.v4l2_buf.timestamp);
- vb2_buffer_done(&buf->vb, VB2_BUF_STATE_DONE);
+ if (q->type == V4L2_BUF_TYPE_VIDEO_CAPTURE)
+ vb.v4l2_buf.sequence = dev->frame_count++;
+ else
+ vb.v4l2_buf.sequence = dev->vbi_frame_count++;
+
+ vb.v4l2_buf.field = V4L2_FIELD_INTERLACED;
+ v4l2_get_timestamp(&vb.v4l2_buf.timestamp);
+ vb2_buffer_done(&vb, VB2_BUF_STATE_DONE);
}
/*
@@ -574,9 +568,7 @@ static inline int au0828_isoc_copy(struct au0828_dev *dev,
struct urb *urb)
if (fbyte & 0x40) {
/* VBI */
if (vbi_buf != NULL)
- vbi_buffer_filled(dev,
- vbi_dma_q,
- vbi_buf);
+ buffer_filled(dev, vbi_dma_q, vbi_buf);
vbi_get_next_buf(vbi_dma_q, &vbi_buf);
if (vbi_buf == NULL)
vbioutp = NULL;
@@ -949,7 +941,7 @@ static void au0828_vbi_buffer_timeout(unsigned long data)
if (buf != NULL) {
vbi_data = vb2_plane_vaddr(&buf->vb, 0);
memset(vbi_data, 0x00, buf->length);
- vbi_buffer_filled(dev, dma_q, buf);
+ buffer_filled(dev, dma_q, buf);
}
vbi_get_next_buf(dma_q, &buf);
--
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
Re: [PATCH] [media] s5p-jpeg: Clear JPEG_CODEC_ON bits in sw reset function
Hi, On 17/12/14 07:22, Tony K Nadackal wrote: > Bits EXYNOS4_DEC_MODE and EXYNOS4_ENC_MODE do not get cleared > on software reset. These bits need to be cleared explicitly. > > Signed-off-by: Tony K Nadackal > --- > This patch is created and tested on top of linux-next-20141210. > It can be cleanly applied on media-next and kgene/for-next. > > > drivers/media/platform/s5p-jpeg/jpeg-hw-exynos4.c | 4 > 1 file changed, 4 insertions(+) > > diff --git a/drivers/media/platform/s5p-jpeg/jpeg-hw-exynos4.c > b/drivers/media/platform/s5p-jpeg/jpeg-hw-exynos4.c > index ab6d6f43..e53f13a 100644 > --- a/drivers/media/platform/s5p-jpeg/jpeg-hw-exynos4.c > +++ b/drivers/media/platform/s5p-jpeg/jpeg-hw-exynos4.c > @@ -21,6 +21,10 @@ void exynos4_jpeg_sw_reset(void __iomem *base) > unsigned int reg; > > reg = readl(base + EXYNOS4_JPEG_CNTL_REG); > + writel(reg & ~(EXYNOS4_DEC_MODE | EXYNOS4_ENC_MODE), > + base + EXYNOS4_JPEG_CNTL_REG); > + > + reg = readl(base + EXYNOS4_JPEG_CNTL_REG); Do we really need the second read? Wouldn't it also work as below ? reg = readl(base + EXYNOS4_JPEG_CNTL_REG); + reg &= ~(EXYNOS4_DEC_MODE | EXYNOS4_ENC_MODE); + writel(reg, base + EXYNOS4_JPEG_CNTL_REG); ? > writel(reg & ~EXYNOS4_SOFT_RESET_HI, base + EXYNOS4_JPEG_CNTL_REG); > > udelay(100); -- Thanks, Sylwester -- 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: DVB Simulcrypt
2015-02-23 13:44 GMT+01:00 Rudy Zijlstra : > On 23-02-15 12:21, Honza Petrouš wrote: >> >> 2015-02-23 11:31 GMT+01:00 Rudy Zijlstra : >>> >>> On 23-02-15 08:44, Honza Petrouš wrote: >>> >>> Hi Rudy. >>> >>> 2015-02-22 16:28 GMT+01:00 Rudy Zijlstra >>> : Some more info On 21-02-15 22:30, Rudy Zijlstra wrote: > > Dears (Hans?) > > My setup, where the cable operator was using only irdeto, was working > good. Then the cable operator merged with another, and now the networks > are > being merged. As a result, the encryption has moved from irdeto only to > simulcyrpt with Irdeto and Nagra. > > Current status: > - when i put the CA card in a STB, it works > - when trying to record an encrypted channel from PC, it no longer > works. Recording system has 3 tuners. All equal, all with same permissions on the smartcard. On cards 0 and 2 does not work, but card 1 does work, on all channels tested. >>> Does it mean that descrambling is not working for you? If so, >>> how do you manage descrambling? By CI-CAM module >>> or by some "softcam" like oscam? >>> >>> Or do you record ENCRYPTED stream and decrypt the recordings >>> later on? >>> >>> >>> Each tuner has its own legal CI-CAM module. And yes, except for the >>> second >>> tuner descrambling no longer works >>> >> I'm not much familiar with MythTV, so I'm guessing from the mux setup >> changes, >> but did you check to descramble the same channel on different tuners? >> To eliminate >> the particular change inside one service only. >> >> Of course there can be also software issue in CI-CAM module itself >> (fail in parsing >> PMT CA descriptors etc). >> >> TBH, I think it must be application layer issue, not kernel one. >> > See above: > > Recording system has 3 tuners. All equal, all with same permissions on the > smartcard. On cards 0 and 2 does not work, but card 1 does work, on all > channels tested. > > additional finfo: i tested the same channel(s) on all 3 tuners. For now i > have re-configured mythtv to use only the second tuner for encrypted > channels. > This does reduce scheduling flexibility though. > > Would to understand what makes the difference, so i can ask the right > questions to MythTV developers. > > > As the decryption does work with 1 tuner, i see 2 options: > - depending on tuner id the default CA descriptor used is different, and > this selection is not expoerted on API level (kernel issue) > - application needs to select which CA to use (and currently does not do > this) > The kernel has no any possibility to break descrambling by CI-CAM as CI-CAM (usually/in more cases) is connected BEFORE TS input. The kernel only talk with CI-CAM by driver, but the message payload sent to the Ci-CAM is controlled by application. I think it must be MythTV issue. Please check if PMT is parsed correctly and the correct CAId is used (as already noted Tycho, Irdeto CAId is 06xx and Nagra is 18xx). BTW, you can check which CAId is supported by your smartcard from CI-CAM menu. /Honza -- 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 v8 1/3] of: Decrement refcount of previous endpoint in of_graph_get_next_endpoint
Hi Philipp, Thank you for the patch. Benoit, please see below for a possible issue in the am437x-vpfe driver. On Monday 23 February 2015 11:54:04 Philipp Zabel wrote: > Decrementing the reference count of the previous endpoint node allows to > use the of_graph_get_next_endpoint function in a for_each_... style macro. > All current users of this function that pass a non-NULL prev parameter > (that is, soc_camera and imx-drm) are changed to not decrement the passed > prev argument's refcount themselves. > > Signed-off-by: Philipp Zabel > Acked-by: Mauro Carvalho Chehab > Acked-by: Mathieu Poirier > Acked-by: Laurent Pinchart > Acked-by: Tomi Valkeinen > --- > Changes since v7: > - Rebased onto v4.0-rc1 > - Added fix for am437x-vpfe > --- > drivers/coresight/of_coresight.c | 13 ++--- > drivers/gpu/drm/imx/imx-drm-core.c| 11 +-- > drivers/gpu/drm/rcar-du/rcar_du_kms.c | 15 --- > drivers/media/platform/am437x/am437x-vpfe.c | 1 - > drivers/media/platform/soc_camera/soc_camera.c| 3 ++- > drivers/of/base.c | 9 + > drivers/video/fbdev/omap2/dss/omapdss-boot-init.c | 7 +-- > 7 files changed, 11 insertions(+), 48 deletions(-) [snip] > diff --git a/drivers/media/platform/am437x/am437x-vpfe.c > b/drivers/media/platform/am437x/am437x-vpfe.c index 56a5cb0..0d07fca 100644 > --- a/drivers/media/platform/am437x/am437x-vpfe.c > +++ b/drivers/media/platform/am437x/am437x-vpfe.c > @@ -2504,7 +2504,6 @@ vpfe_get_pdata(struct platform_device *pdev) >GFP_KERNEL); > pdata->asd[i]->match_type = V4L2_ASYNC_MATCH_OF; > pdata->asd[i]->match.of.node = rem; > - of_node_put(endpoint); > of_node_put(rem); > } For the am47x-vpfe driver, Acked-by: Laurent Pinchart Benoit, there seems to be a refcount issue with rem. The node pointer is assigned to pdata->asd[i]->match.of.node, which should require a reference, but you then call of_node_put(rem), releasing the only reference held. Isn't that a problem ? Furthermore, on the next iteration, if an error occurs the goto done will result in of_node_put(rem) being called again, releasing a reference that you don't hold. I've sent a patch to fix that. -- Regards, Laurent Pinchart -- 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] media: am437x: Don't release OF node reference twice
The remote port reference is released both at the end of the OF graph
parsing loop, and in the error code path at the end of the function.
Those two calls will release the same reference, causing the reference
count to go negative.
Fix the problem by removing the second call.
Signed-off-by: Laurent Pinchart
---
drivers/media/platform/am437x/am437x-vpfe.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
I've found this issue while reading the code, the patch hasn't been tested.
diff --git a/drivers/media/platform/am437x/am437x-vpfe.c
b/drivers/media/platform/am437x/am437x-vpfe.c
index 56a5cb0..ce273b2 100644
--- a/drivers/media/platform/am437x/am437x-vpfe.c
+++ b/drivers/media/platform/am437x/am437x-vpfe.c
@@ -2425,7 +2425,7 @@ static int vpfe_async_complete(struct v4l2_async_notifier
*notifier)
static struct vpfe_config *
vpfe_get_pdata(struct platform_device *pdev)
{
- struct device_node *endpoint = NULL, *rem = NULL;
+ struct device_node *endpoint = NULL;
struct v4l2_of_endpoint bus_cfg;
struct vpfe_subdev_info *sdinfo;
struct vpfe_config *pdata;
@@ -2443,6 +2443,8 @@ vpfe_get_pdata(struct platform_device *pdev)
return NULL;
for (i = 0; ; i++) {
+ struct device_node *rem;
+
endpoint = of_graph_get_next_endpoint(pdev->dev.of_node,
endpoint);
if (!endpoint)
@@ -2513,7 +2515,6 @@ vpfe_get_pdata(struct platform_device *pdev)
done:
of_node_put(endpoint);
- of_node_put(rem);
return NULL;
}
--
Regards,
Laurent Pinchart
--
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: DVB Simulcrypt
Op 23-02-15 om 13:44 schreef Rudy Zijlstra: On 23-02-15 12:21, Honza Petrouš wrote: 2015-02-23 11:31 GMT+01:00 Rudy Zijlstra : On 23-02-15 08:44, Honza Petrouš wrote: Hi Rudy. 2015-02-22 16:28 GMT+01:00 Rudy Zijlstra : Some more info On 21-02-15 22:30, Rudy Zijlstra wrote: Dears (Hans?) My setup, where the cable operator was using only irdeto, was working good. Then the cable operator merged with another, and now the networks are being merged. As a result, the encryption has moved from irdeto only to simulcyrpt with Irdeto and Nagra. Current status: - when i put the CA card in a STB, it works - when trying to record an encrypted channel from PC, it no longer works. Recording system has 3 tuners. All equal, all with same permissions on the smartcard. On cards 0 and 2 does not work, but card 1 does work, on all channels tested. Does it mean that descrambling is not working for you? If so, how do you manage descrambling? By CI-CAM module or by some "softcam" like oscam? Or do you record ENCRYPTED stream and decrypt the recordings later on? Each tuner has its own legal CI-CAM module. And yes, except for the second tuner descrambling no longer works I'm not much familiar with MythTV, so I'm guessing from the mux setup changes, but did you check to descramble the same channel on different tuners? To eliminate the particular change inside one service only. Of course there can be also software issue in CI-CAM module itself (fail in parsing PMT CA descriptors etc). TBH, I think it must be application layer issue, not kernel one. See above: Recording system has 3 tuners. All equal, all with same permissions on the smartcard. On cards 0 and 2 does not work, but card 1 does work, on all channels tested. additional finfo: i tested the same channel(s) on all 3 tuners. For now i have re-configured mythtv to use only the second tuner for encrypted channels. This does reduce scheduling flexibility though. Would to understand what makes the difference, so i can ask the right questions to MythTV developers. As the decryption does work with 1 tuner, i see 2 options: - depending on tuner id the default CA descriptor used is different, and this selection is not expoerted on API level (kernel issue) - application needs to select which CA to use (and currently does not do this) It should be the latter one. I'm also having Ziggo for provider, but always used FFdecsawrapper/Oscam for decryption (also legal in The Netherlands, providing you have a paid subscription) ECM CA system id's 0x604 or 0x602 (depending on your region) gets you Irdeto, while ECM CA system id's 0x1850 or 0x1801 get you Nagra. Correctly configured FFdecsa/Oscam can deal with it, MythTV probably cannot. Check it out at: http://www.dtvmonitor.com/nl/?guid=0BE90D25-BA46-7B93-FDCD-20EFC79691E0 That's a snapshot from today, monitored from Groningen. Cheers, Tycho. -- 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/3] media: Fix ALSA and DVB representation at media controller API
Em Mon, 26 Jan 2015 09:41:41 -0500
Devin Heitmueller escreveu:
> > It is actually trivial to get the device nodes once you have the
> > major/minor. The media-ctl library does that for you. See:
>
> No objection then.
>
> On a related note, you would be very well served to consider testing
> your dvb changes with a device that has more than one DVB tuner (such
> as the hvr-2200/2250). That will help you shake out any edge cases
> related to ensuring that the different DVB nodes appear in different
> groups.
Hi Devin,
I did some tests (and fixes) for WinTV Nova-TD, with has two adapters.
I saw two alternatives for it:
1) to create a media controller device for each adapter;
2) to create just one media controller.
I actually implemented (1), as, in the case of this device, AFAIKT, the
two devices are indepentent, e. g. it is not possible to, for example,
share the same tuner with two demods:
$ ls -la /dev/media?
crw-rw. 1 root video 249, 0 Fev 23 10:02 /dev/media0
crw-rw. 1 root video 249, 1 Fev 23 10:02 /dev/media1
The adapter 0 corresponds to /dev/media0, and the adapter 1
to /dev/media1:
$ media-ctl --print-dot -d /dev/media0
digraph board {
rankdir=TB
n0001 [label="dvb-demux\n/dev/dvb/adapter0/demux0", shape=box,
style=filled, fillcolor=yellow]
n0001 -> n0002
n0002 [label="dvb-dvr\n/dev/dvb/adapter0/dvr0", shape=box,
style=filled, fillcolor=yellow]
n0003 [label="dvb-net\n/dev/dvb/adapter0/net0", shape=box,
style=filled, fillcolor=yellow]
n0004 [label="DiBcom 7000PC\n/dev/dvb/adapter0/frontend0",
shape=box, style=filled, fillcolor=yellow]
n0004 -> n0001
}
$ media-ctl --print-dot -d /dev/media1
digraph board {
rankdir=TB
n0001 [label="dvb-demux\n/dev/dvb/adapter1/demux0", shape=box,
style=filled, fillcolor=yellow]
n0001 -> n0002
n0002 [label="dvb-dvr\n/dev/dvb/adapter1/dvr0", shape=box,
style=filled, fillcolor=yellow]
n0003 [label="dvb-net\n/dev/dvb/adapter1/net0", shape=box,
style=filled, fillcolor=yellow]
n0004 [label="DiBcom 7000PC\n/dev/dvb/adapter1/frontend0",
shape=box, style=filled, fillcolor=yellow]
n0004 -> n0001
}
On a more complex hardware where some components may be rewired
on a different way, however, using just one media controller
would be a better approach.
Comments?
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: DVB Simulcrypt
On 23-02-15 12:21, Honza Petrouš wrote: 2015-02-23 11:31 GMT+01:00 Rudy Zijlstra : On 23-02-15 08:44, Honza Petrouš wrote: Hi Rudy. 2015-02-22 16:28 GMT+01:00 Rudy Zijlstra : Some more info On 21-02-15 22:30, Rudy Zijlstra wrote: Dears (Hans?) My setup, where the cable operator was using only irdeto, was working good. Then the cable operator merged with another, and now the networks are being merged. As a result, the encryption has moved from irdeto only to simulcyrpt with Irdeto and Nagra. Current status: - when i put the CA card in a STB, it works - when trying to record an encrypted channel from PC, it no longer works. Recording system has 3 tuners. All equal, all with same permissions on the smartcard. On cards 0 and 2 does not work, but card 1 does work, on all channels tested. Does it mean that descrambling is not working for you? If so, how do you manage descrambling? By CI-CAM module or by some "softcam" like oscam? Or do you record ENCRYPTED stream and decrypt the recordings later on? Each tuner has its own legal CI-CAM module. And yes, except for the second tuner descrambling no longer works I'm not much familiar with MythTV, so I'm guessing from the mux setup changes, but did you check to descramble the same channel on different tuners? To eliminate the particular change inside one service only. Of course there can be also software issue in CI-CAM module itself (fail in parsing PMT CA descriptors etc). TBH, I think it must be application layer issue, not kernel one. See above: Recording system has 3 tuners. All equal, all with same permissions on the smartcard. On cards 0 and 2 does not work, but card 1 does work, on all channels tested. additional finfo: i tested the same channel(s) on all 3 tuners. For now i have re-configured mythtv to use only the second tuner for encrypted channels. This does reduce scheduling flexibility though. Would to understand what makes the difference, so i can ask the right questions to MythTV developers. As the decryption does work with 1 tuner, i see 2 options: - depending on tuner id the default CA descriptor used is different, and this selection is not expoerted on API level (kernel issue) - application needs to select which CA to use (and currently does not do this) Cheers Rudy -- 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] [media] only start media entity if not NULL
The logic there tries to start the media entity even if it
doesn't exist, causing this bug:
[ 314.356162] BUG: unable to handle kernel NULL pointer dereference at
0010
[ 314.356202] IP: []
media_entity_pipeline_start+0x1c/0x390 [media]
Reported-by: Gert-Jan van der Stroom
Signed-off-by: Mauro Carvalho Chehab
diff --git a/drivers/media/dvb-core/dvb_frontend.c
b/drivers/media/dvb-core/dvb_frontend.c
index d7d390c5c7c3..477620bc993b 100644
--- a/drivers/media/dvb-core/dvb_frontend.c
+++ b/drivers/media/dvb-core/dvb_frontend.c
@@ -714,7 +714,7 @@ static int dvb_frontend_thread(void *data)
/* FIXME: return an error if it fails */
dev_info(fe->dvb->device,
"proceeding with FE task\n");
- } else {
+ } else if (fepriv->pipe_start_entity) {
ret = media_entity_pipeline_start(fepriv->pipe_start_entity,
&fepriv->pipe);
if (ret)
--
2.1.0
--
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 v6 2/4] vb2: add allow_zero_bytesused flag to the vb2_queue struct
The vb2: fix bytesused == 0 handling (8a75ffb) patch changed the behavior
of __fill_vb2_buffer function, so that if bytesused is 0 it is set to the
size of the buffer. However, bytesused set to 0 is used by older codec
drivers as as indication used to mark the end of stream.
To keep backward compatibility, this patch adds a flag passed to the
vb2_queue_init function - allow_zero_bytesused. If the flag is set upon
initialization of the queue, the videobuf2 keeps the value of bytesused
intact in the OUTPUT queue and passes it to the driver.
Reported-by: Nicolas Dufresne
Signed-off-by: Kamil Debski
---
drivers/media/v4l2-core/videobuf2-core.c | 39 +-
include/media/videobuf2-core.h |2 ++
2 files changed, 35 insertions(+), 6 deletions(-)
diff --git a/drivers/media/v4l2-core/videobuf2-core.c
b/drivers/media/v4l2-core/videobuf2-core.c
index 5cd60bf..33a5d93 100644
--- a/drivers/media/v4l2-core/videobuf2-core.c
+++ b/drivers/media/v4l2-core/videobuf2-core.c
@@ -1247,6 +1247,16 @@ static void __fill_vb2_buffer(struct vb2_buffer *vb,
const struct v4l2_buffer *b
{
unsigned int plane;
+ if (V4L2_TYPE_IS_OUTPUT(b->type)) {
+ if (WARN_ON_ONCE(b->bytesused == 0)) {
+ pr_warn_once("use of bytesused == 0 is deprecated and
will be removed in the future,\n");
+ if (vb->vb2_queue->allow_zero_bytesused)
+ pr_warn_once("use
VIDIOC_DECODER_CMD(V4L2_DEC_CMD_STOP) instead.\n");
+ else
+ pr_warn_once("use the actual size instead.\n");
+ }
+ }
+
if (V4L2_TYPE_IS_MULTIPLANAR(b->type)) {
if (b->memory == V4L2_MEMORY_USERPTR) {
for (plane = 0; plane < vb->num_planes; ++plane) {
@@ -1276,13 +1286,22 @@ static void __fill_vb2_buffer(struct vb2_buffer *vb,
const struct v4l2_buffer *b
* userspace clearly never bothered to set it and
* it's a safe assumption that they really meant to
* use the full plane sizes.
+*
+* Some drivers, e.g. old codec drivers, use bytesused
== 0
+* as a way to indicate that streaming is finished.
+* In that case, the driver should use the
+* allow_zero_bytesused flag to keep old userspace
+* applications working.
*/
for (plane = 0; plane < vb->num_planes; ++plane) {
struct v4l2_plane *pdst = &v4l2_planes[plane];
struct v4l2_plane *psrc = &b->m.planes[plane];
- pdst->bytesused = psrc->bytesused ?
- psrc->bytesused : pdst->length;
+ if (vb->vb2_queue->allow_zero_bytesused)
+ pdst->bytesused = psrc->bytesused;
+ else
+ pdst->bytesused = psrc->bytesused ?
+ psrc->bytesused : pdst->length;
pdst->data_offset = psrc->data_offset;
}
}
@@ -1295,6 +1314,11 @@ static void __fill_vb2_buffer(struct vb2_buffer *vb,
const struct v4l2_buffer *b
*
* If bytesused == 0 for the output buffer, then fall back
* to the full buffer size as that's a sensible default.
+*
+* Some drivers, e.g. old codec drivers, use bytesused == 0 as
+* a way to indicate that streaming is finished. In that case,
+* the driver should use the allow_zero_bytesused flag to keep
+* old userspace applications working.
*/
if (b->memory == V4L2_MEMORY_USERPTR) {
v4l2_planes[0].m.userptr = b->m.userptr;
@@ -1306,10 +1330,13 @@ static void __fill_vb2_buffer(struct vb2_buffer *vb,
const struct v4l2_buffer *b
v4l2_planes[0].length = b->length;
}
- if (V4L2_TYPE_IS_OUTPUT(b->type))
- v4l2_planes[0].bytesused = b->bytesused ?
- b->bytesused : v4l2_planes[0].length;
- else
+ if (V4L2_TYPE_IS_OUTPUT(b->type)) {
+ if (vb->vb2_queue->allow_zero_bytesused)
+ v4l2_planes[0].bytesused = b->bytesused;
+ else
+ v4l2_planes[0].bytesused = b->bytesused ?
+ b->bytesused : v4l2_planes[0].length;
+ } else
v4l2_planes[0].bytesused = 0;
}
diff --git a/include
Re: HDMI input on i.MX6 using IPU
Hi JM, I am trying the Philipp's code and I came to the same conclusion, it is not possible to setup the last link. Did you do some progress on this? Any idea? Maybe, between us we can fix this problem. Thanks for advice, 2015-01-14 18:11 GMT+01:00 Jean-Michel Hautbois : > Hi, > > 2015-01-08 17:53 GMT+01:00 Jean-Michel Hautbois > : >> Hi, >> >> I have modified both Steve's and Philipp's code, in order to get >> something able to get frames from an ADV7611. >> Right now, I am back to Philipp's base of code, rebased on top of >> media-tree, and everything works fine, except the very last link >> between SFMC and IDMAC (using media controller). >> Here is a status. >> >> The code is here : >> https://github.com/Vodalys/linux-2.6-imx/tree/media-tree-zabel > > Right now, I can go further. I added support for BT.1120 in order to > get the correct video format, and I am able to start a streaming, but > I can't get an interrupt on IDMAC. > > I am starting with setting DV timings on adv7611 input, and then, I am > using 4l2-compliance in order to test streaming. It has shown several > things, most of them are corrected, sometimes in a hacky way. > > Right now, I can do the following : > $> media-ctl --set-dv '"adv7611 1-004c":1 [fmt:YUYV/1280x720]' && > media-ctl --set-v4l2 '"adv7611 1-004c":1 [fmt:YUYV/1280x720]' > $> echo -n 'module imx_ipuv3_csi +p' > /sys/kernel/debug/dynamic_debug/control > $> v4l2-compliance -v -s > Driver Info: > Driver name : imx-ipuv3-csi > Card type : imx-ipuv3-camera > Bus info : platform:imx-ipuv3-csi > Driver version: 3.19.0 > Capabilities : 0x8421 > Video Capture > Streaming > Extended Pix Format > Device Capabilities > Device Caps : 0x0421 > Video Capture > Streaming > Extended Pix Format > > Compliance test for device /dev/video0 (not using libv4l2): > > Required ioctls: > test VIDIOC_QUERYCAP: OK > > Allow for multiple opens: > test second video open: OK > test VIDIOC_QUERYCAP: OK > test VIDIOC_G/S_PRIORITY: OK > > Debug ioctls: > test VIDIOC_DBG_G/S_REGISTER: OK > test VIDIOC_LOG_STATUS: OK > > Input ioctls: > test VIDIOC_G/S_TUNER/ENUM_FREQ_BANDS: OK (Not Supported) > test VIDIOC_G/S_FREQUENCY: OK (Not Supported) > test VIDIOC_S_HW_FREQ_SEEK: OK (Not Supported) > test VIDIOC_ENUMAUDIO: OK (Not Supported) > test VIDIOC_G/S/ENUMINPUT: OK (Not Supported) > test VIDIOC_G/S_AUDIO: OK (Not Supported) > Inputs: 0 Audio Inputs: 0 Tuners: 0 > > Output ioctls: > test VIDIOC_G/S_MODULATOR: OK (Not Supported) > test VIDIOC_G/S_FREQUENCY: OK (Not Supported) > test VIDIOC_ENUMAUDOUT: OK (Not Supported) > test VIDIOC_G/S/ENUMOUTPUT: OK (Not Supported) > test VIDIOC_G/S_AUDOUT: OK (Not Supported) > Outputs: 0 Audio Outputs: 0 Modulators: 0 > > Input/Output configuration ioctls: > test VIDIOC_ENUM/G/S/QUERY_STD: OK (Not Supported) > test VIDIOC_ENUM/G/S/QUERY_DV_TIMINGS: OK (Not Supported) > test VIDIOC_DV_TIMINGS_CAP: OK (Not Supported) > test VIDIOC_G/S_EDID: OK (Not Supported) > > Control ioctls: > info: checking v4l2_queryctrl of control 'User Controls' (0x00980001) > info: checking v4l2_queryctrl of control 'Brightness' (0x00980900) > info: checking v4l2_queryctrl of control 'Contrast' (0x00980901) > info: checking v4l2_queryctrl of control 'Saturation' (0x00980902) > info: checking v4l2_queryctrl of control 'Hue' (0x00980903) > info: checking v4l2_queryctrl of control 'Image Processing > Controls' (0x009f0001) > info: checking v4l2_queryctrl of control 'Test Pattern' (0x009f0903) > info: checking v4l2_queryctrl of control 'Brightness' (0x00980900) > info: checking v4l2_queryctrl of control 'Contrast' (0x00980901) > info: checking v4l2_queryctrl of control 'Saturation' (0x00980902) > info: checking v4l2_queryctrl of control 'Hue' (0x00980903) > test VIDIOC_QUERYCTRL/MENU: OK > info: checking control 'User Controls' (0x00980001) > info: checking control 'Brightness' (0x00980900) > info: checking control 'Contrast' (0x00980901) > info: checking control 'Saturation' (0x00980902) > info: checking control 'Hue' (0x00980903) > info: checking control 'Image Processing Controls' (0x009f0001) > info: checking control 'Test Pattern' (0x009f0903) > test VIDIOC_G/S_CTRL: OK > info: checking extended control 'User Controls' (0x00980001) > info: checking extended control 'Brightness' (0x00980900) > info: checking extended control 'Contrast' (0x00980901) > info: checking extended control 'Saturation' (0x00980902) > info: checking extended control 'Hue' (0x00980903) > info: checking extended control 'Image Processing Controls' > (0x009f0001) > info: checking extended control 'Test Pattern' (0x009
[PATCH v6 4/4] s5p-mfc: set allow_zero_bytesused flag for vb2_queue_init
The s5p-mfc driver interprets a buffer with bytesused equal to 0 as a special case indicating end-of-stream. After vb2: fix bytesused == 0 handling (8a75ffb) patch videobuf2 modified the value of bytesused if it was 0. The allow_zero_bytesused flag was added to videobuf2 to keep backward compatibility. Signed-off-by: Kamil Debski --- drivers/media/platform/s5p-mfc/s5p_mfc.c |7 +++ 1 file changed, 7 insertions(+) diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc.c b/drivers/media/platform/s5p-mfc/s5p_mfc.c index 8e44a59..9fe4d90 100644 --- a/drivers/media/platform/s5p-mfc/s5p_mfc.c +++ b/drivers/media/platform/s5p-mfc/s5p_mfc.c @@ -843,6 +843,13 @@ static int s5p_mfc_open(struct file *file) ret = -ENOENT; goto err_queue_init; } + /* One way to indicate end-of-stream for MFC is to set the +* bytesused == 0. However by default videobuf2 handles bytesused +* equal to 0 as a special case and changes its value to the size +* of the buffer. Set the allow_zero_bytesused flag so that videobuf2 +* will keep the value of bytesused intact. +*/ + q->allow_zero_bytesused = 1; q->mem_ops = &vb2_dma_contig_memops; q->timestamp_flags = V4L2_BUF_FLAG_TIMESTAMP_COPY; ret = vb2_queue_init(q); -- 1.7.9.5 -- 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 v6 3/4] coda: set allow_zero_bytesused flag for vb2_queue_init
The coda driver interprets a buffer with bytesused equal to 0 as a special case indicating end-of-stream. After vb2: fix bytesused == 0 handling (8a75ffb) patch videobuf2 modified the value of bytesused if it was 0. The allow_zero_bytesused flag was added to videobuf2 to keep backward compatibility. Signed-off-by: Kamil Debski --- drivers/media/platform/coda/coda-common.c |7 +++ 1 file changed, 7 insertions(+) diff --git a/drivers/media/platform/coda/coda-common.c b/drivers/media/platform/coda/coda-common.c index 6f32e6d..329c2a4 100644 --- a/drivers/media/platform/coda/coda-common.c +++ b/drivers/media/platform/coda/coda-common.c @@ -1541,6 +1541,13 @@ static int coda_queue_init(struct coda_ctx *ctx, struct vb2_queue *vq) vq->buf_struct_size = sizeof(struct v4l2_m2m_buffer); vq->timestamp_flags = V4L2_BUF_FLAG_TIMESTAMP_COPY; vq->lock = &ctx->dev->dev_mutex; + /* One way to indicate end-of-stream for coda is to set the +* bytesused == 0. However by default videobuf2 handles bytesused +* equal to 0 as a special case and changes its value to the size +* of the buffer. Set the allow_zero_bytesused flag, so +* that videobuf2 will keep the value of bytesused intact. +*/ + vq->allow_zero_bytesused = 1; return vb2_queue_init(vq); } -- 1.7.9.5 -- 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 v6 1/4] vb2: split the io_flags member of vb2_queue into a bit field
This patch splits the io_flags member of vb2_queue into a bit field.
Instead of an enum with flags separate bit fields were introduced.
Signed-off-by: Kamil Debski
Acked-by: Hans Verkuil
---
drivers/media/v4l2-core/videobuf2-core.c | 17 +
include/media/videobuf2-core.h | 18 +-
2 files changed, 14 insertions(+), 21 deletions(-)
diff --git a/drivers/media/v4l2-core/videobuf2-core.c
b/drivers/media/v4l2-core/videobuf2-core.c
index bc08a82..5cd60bf 100644
--- a/drivers/media/v4l2-core/videobuf2-core.c
+++ b/drivers/media/v4l2-core/videobuf2-core.c
@@ -2760,7 +2760,8 @@ struct vb2_fileio_data {
unsigned int initial_index;
unsigned int q_count;
unsigned int dq_count;
- unsigned int flags;
+ unsigned read_once:1;
+ unsigned write_immediately:1;
};
/**
@@ -2798,14 +2799,16 @@ static int __vb2_init_fileio(struct vb2_queue *q, int
read)
*/
count = 1;
- dprintk(3, "setting up file io: mode %s, count %d, flags %08x\n",
- (read) ? "read" : "write", count, q->io_flags);
+ dprintk(3, "setting up file io: mode %s, count %d, read_once %d,
write_immediately %d\n",
+ (read) ? "read" : "write", count, q->fileio_read_once,
+ q->fileio_write_immediately);
fileio = kzalloc(sizeof(struct vb2_fileio_data), GFP_KERNEL);
if (fileio == NULL)
return -ENOMEM;
- fileio->flags = q->io_flags;
+ fileio->read_once = q->fileio_read_once;
+ fileio->write_immediately = q->fileio_write_immediately;
/*
* Request buffers and use MMAP type to force driver
@@ -3028,13 +3031,11 @@ static size_t __vb2_perform_fileio(struct vb2_queue *q,
char __user *data, size_
/*
* Queue next buffer if required.
*/
- if (buf->pos == buf->size ||
- (!read && (fileio->flags & VB2_FILEIO_WRITE_IMMEDIATELY))) {
+ if (buf->pos == buf->size || (!read && fileio->write_immediately)) {
/*
* Check if this is the last buffer to read.
*/
- if (read && (fileio->flags & VB2_FILEIO_READ_ONCE) &&
- fileio->dq_count == 1) {
+ if (read && fileio->read_once && fileio->dq_count == 1) {
dprintk(3, "read limit reached\n");
return __vb2_cleanup_fileio(q);
}
diff --git a/include/media/videobuf2-core.h b/include/media/videobuf2-core.h
index bd2cec2..e49dc6b 100644
--- a/include/media/videobuf2-core.h
+++ b/include/media/videobuf2-core.h
@@ -134,17 +134,6 @@ enum vb2_io_modes {
};
/**
- * enum vb2_fileio_flags - flags for selecting a mode of the file io emulator,
- * by default the 'streaming' style is used by the file io emulator
- * @VB2_FILEIO_READ_ONCE: report EOF after reading the first buffer
- * @VB2_FILEIO_WRITE_IMMEDIATELY: queue buffer after each write() call
- */
-enum vb2_fileio_flags {
- VB2_FILEIO_READ_ONCE= (1 << 0),
- VB2_FILEIO_WRITE_IMMEDIATELY= (1 << 1),
-};
-
-/**
* enum vb2_buffer_state - current video buffer state
* @VB2_BUF_STATE_DEQUEUED:buffer under userspace control
* @VB2_BUF_STATE_PREPARING: buffer is being prepared in videobuf
@@ -346,7 +335,8 @@ struct v4l2_fh;
*
* @type: queue type (see V4L2_BUF_TYPE_* in linux/videodev2.h
* @io_modes: supported io methods (see vb2_io_modes enum)
- * @io_flags: additional io flags (see vb2_fileio_flags enum)
+ * @fileio_read_once: report EOF after reading the first buffer
+ * @fileio_write_immediately: queue buffer after each write() call
* @lock: pointer to a mutex that protects the vb2_queue struct. The
* driver can set this to a mutex to let the v4l2 core serialize
* the queuing ioctls. If the driver wants to handle locking
@@ -396,7 +386,9 @@ struct v4l2_fh;
struct vb2_queue {
enum v4l2_buf_type type;
unsigned intio_modes;
- unsigned intio_flags;
+ unsignedfileio_read_once:1;
+ unsignedfileio_write_immediately:1;
+
struct mutex*lock;
struct v4l2_fh *owner;
--
1.7.9.5
--
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 v5 2/4] vb2: add allow_zero_bytesused flag to the vb2_queue struct
On 02/23/2015 12:58 PM, Kamil Debski wrote:
> Hi,
>
> Thank you for the review :)
>
>> From: Hans Verkuil [mailto:hverk...@xs4all.nl]
>> Sent: Friday, February 20, 2015 5:52 PM
>>
>> Hi Kamil,
>>
>> One question and one typo below...
>>
>> On 02/20/2015 05:38 PM, Kamil Debski wrote:
>>> The vb2: fix bytesused == 0 handling (8a75ffb) patch changed the
>>> behavior of __fill_vb2_buffer function, so that if bytesused is 0 it
>>> is set to the size of the buffer. However, bytesused set to 0 is used
>>> by older codec drivers as as indication used to mark the end of
>> stream.
>>>
>>> To keep backward compatibility, this patch adds a flag passed to the
>>> vb2_queue_init function - allow_zero_bytesused. If the flag is set
>>> upon initialization of the queue, the videobuf2 keeps the value of
>>> bytesused intact in the OUTPUT queue and passes it to the driver.
>>>
>>> Reported-by: Nicolas Dufresne
>>> Signed-off-by: Kamil Debski
>>> ---
>>> drivers/media/v4l2-core/videobuf2-core.c | 39
>> +-
>>> include/media/videobuf2-core.h |2 ++
>>> 2 files changed, 35 insertions(+), 6 deletions(-)
>>>
>>> diff --git a/drivers/media/v4l2-core/videobuf2-core.c
>>> b/drivers/media/v4l2-core/videobuf2-core.c
>>> index 5cd60bf..5d77670 100644
>>> --- a/drivers/media/v4l2-core/videobuf2-core.c
>>> +++ b/drivers/media/v4l2-core/videobuf2-core.c
>>> @@ -1247,6 +1247,16 @@ static void __fill_vb2_buffer(struct
>> vb2_buffer
>>> *vb, const struct v4l2_buffer *b {
>>> unsigned int plane;
>>>
>>> + if (V4L2_TYPE_IS_OUTPUT(b->type)) {
>>> + if (WARN_ON_ONCE(b->bytesused == 0)) {
>>> + pr_warn_once("use of bytesused == 0 is deprecated
> and
>> will be
>>> +removed in 2017,\n");
>>
>> I wonder if we should give a specific year, or just say 'in the
>> future'.
>>
>> What do you think?
>
> I think I would prefer to use the phrase "in the future".
> If you are ok with that I will post an updated patch set soon.
I agree with that.
Regards,
Hans
>
>>
>>> + if (vb->vb2_queue->allow_zero_bytesused)
>>> + pr_warn_once("use
>> VIDIOC_DECODER_CMD(V4L2_DEC_CMD_STOP) instead.\n");
>>> + else
>>> + pr_warn_once("use the actual size
> instead.\n");
>>> + }
>>> + }
>>> +
>>> if (V4L2_TYPE_IS_MULTIPLANAR(b->type)) {
>>> if (b->memory == V4L2_MEMORY_USERPTR) {
>>> for (plane = 0; plane < vb->num_planes; ++plane) {
> @@
>> -1276,13
>>> +1286,22 @@ static void __fill_vb2_buffer(struct vb2_buffer *vb,
>> const struct v4l2_buffer *b
>>> * userspace clearly never bothered to set it and
>>> * it's a safe assumption that they really meant to
>>> * use the full plane sizes.
>>> +*
>>> +* Some drivers, e.g. old codec drivers, use
>> bytesused
>>> +* == 0 as a way to indicate that streaming is
>> finished.
>>> +* In that case, the driver should use the
>>> +* allow_zero_bytesused flag to keep old userspace
>>> +* applications working.
>>> */
>>> for (plane = 0; plane < vb->num_planes; ++plane) {
>>> struct v4l2_plane *pdst =
> &v4l2_planes[plane];
>>> struct v4l2_plane *psrc =
> &b->m.planes[plane];
>>>
>>> - pdst->bytesused = psrc->bytesused ?
>>> - psrc->bytesused : pdst->length;
>>> + if (vb->vb2_queue->allow_zero_bytesused)
>>> + pdst->bytesused = psrc->bytesused;
>>> + else
>>> + pdst->bytesused = psrc->bytesused ?
>>> + psrc->bytesused :
> pdst->length;
>>> pdst->data_offset = psrc->data_offset;
>>> }
>>> }
>>> @@ -1295,6 +1314,11 @@ static void __fill_vb2_buffer(struct
>> vb2_buffer *vb, const struct v4l2_buffer *b
>>> *
>>> * If bytesused == 0 for the output buffer, then fall back
>>> * to the full buffer size as that's a sensible default.
>>> +*
>>> +* Some drivers, e.g. old codec drivers, use bytesused * ==
>> 0 as
>>
>> Small typo:
>>
>> s/bytesused * == 0/bytesused == 0/
>>
>>> +* a way to indicate that streaming is finished. In that
>> case,
>>> +* the driver should use the allow_zero_bytesused flag to
>> keep
>>> +* old userspace applications working.
>>> */
>>> if (b->memory == V4L2_MEMORY_USERPTR) {
>>> v4l2_planes[0].m.userptr = b->m.userptr; @@ -1306,10
>> +1330,13 @@
>>> static void __fill_vb2_buffer(struct vb2_buffer *vb,
RE: [PATCH v5 2/4] vb2: add allow_zero_bytesused flag to the vb2_queue struct
Hi,
Thank you for the review :)
> From: Hans Verkuil [mailto:hverk...@xs4all.nl]
> Sent: Friday, February 20, 2015 5:52 PM
>
> Hi Kamil,
>
> One question and one typo below...
>
> On 02/20/2015 05:38 PM, Kamil Debski wrote:
> > The vb2: fix bytesused == 0 handling (8a75ffb) patch changed the
> > behavior of __fill_vb2_buffer function, so that if bytesused is 0 it
> > is set to the size of the buffer. However, bytesused set to 0 is used
> > by older codec drivers as as indication used to mark the end of
> stream.
> >
> > To keep backward compatibility, this patch adds a flag passed to the
> > vb2_queue_init function - allow_zero_bytesused. If the flag is set
> > upon initialization of the queue, the videobuf2 keeps the value of
> > bytesused intact in the OUTPUT queue and passes it to the driver.
> >
> > Reported-by: Nicolas Dufresne
> > Signed-off-by: Kamil Debski
> > ---
> > drivers/media/v4l2-core/videobuf2-core.c | 39
> +-
> > include/media/videobuf2-core.h |2 ++
> > 2 files changed, 35 insertions(+), 6 deletions(-)
> >
> > diff --git a/drivers/media/v4l2-core/videobuf2-core.c
> > b/drivers/media/v4l2-core/videobuf2-core.c
> > index 5cd60bf..5d77670 100644
> > --- a/drivers/media/v4l2-core/videobuf2-core.c
> > +++ b/drivers/media/v4l2-core/videobuf2-core.c
> > @@ -1247,6 +1247,16 @@ static void __fill_vb2_buffer(struct
> vb2_buffer
> > *vb, const struct v4l2_buffer *b {
> > unsigned int plane;
> >
> > + if (V4L2_TYPE_IS_OUTPUT(b->type)) {
> > + if (WARN_ON_ONCE(b->bytesused == 0)) {
> > + pr_warn_once("use of bytesused == 0 is deprecated
and
> will be
> > +removed in 2017,\n");
>
> I wonder if we should give a specific year, or just say 'in the
> future'.
>
> What do you think?
I think I would prefer to use the phrase "in the future".
If you are ok with that I will post an updated patch set soon.
>
> > + if (vb->vb2_queue->allow_zero_bytesused)
> > + pr_warn_once("use
> VIDIOC_DECODER_CMD(V4L2_DEC_CMD_STOP) instead.\n");
> > + else
> > + pr_warn_once("use the actual size
instead.\n");
> > + }
> > + }
> > +
> > if (V4L2_TYPE_IS_MULTIPLANAR(b->type)) {
> > if (b->memory == V4L2_MEMORY_USERPTR) {
> > for (plane = 0; plane < vb->num_planes; ++plane) {
@@
> -1276,13
> > +1286,22 @@ static void __fill_vb2_buffer(struct vb2_buffer *vb,
> const struct v4l2_buffer *b
> > * userspace clearly never bothered to set it and
> > * it's a safe assumption that they really meant to
> > * use the full plane sizes.
> > +*
> > +* Some drivers, e.g. old codec drivers, use
> bytesused
> > +* == 0 as a way to indicate that streaming is
> finished.
> > +* In that case, the driver should use the
> > +* allow_zero_bytesused flag to keep old userspace
> > +* applications working.
> > */
> > for (plane = 0; plane < vb->num_planes; ++plane) {
> > struct v4l2_plane *pdst =
&v4l2_planes[plane];
> > struct v4l2_plane *psrc =
&b->m.planes[plane];
> >
> > - pdst->bytesused = psrc->bytesused ?
> > - psrc->bytesused : pdst->length;
> > + if (vb->vb2_queue->allow_zero_bytesused)
> > + pdst->bytesused = psrc->bytesused;
> > + else
> > + pdst->bytesused = psrc->bytesused ?
> > + psrc->bytesused :
pdst->length;
> > pdst->data_offset = psrc->data_offset;
> > }
> > }
> > @@ -1295,6 +1314,11 @@ static void __fill_vb2_buffer(struct
> vb2_buffer *vb, const struct v4l2_buffer *b
> > *
> > * If bytesused == 0 for the output buffer, then fall back
> > * to the full buffer size as that's a sensible default.
> > +*
> > +* Some drivers, e.g. old codec drivers, use bytesused * ==
> 0 as
>
> Small typo:
>
> s/bytesused * == 0/bytesused == 0/
>
> > +* a way to indicate that streaming is finished. In that
> case,
> > +* the driver should use the allow_zero_bytesused flag to
> keep
> > +* old userspace applications working.
> > */
> > if (b->memory == V4L2_MEMORY_USERPTR) {
> > v4l2_planes[0].m.userptr = b->m.userptr; @@ -1306,10
> +1330,13 @@
> > static void __fill_vb2_buffer(struct vb2_buffer *vb, const struct
> v4l2_buffer *b
> > v4l2_planes[0].length = b->length;
> > }
> >
> > - if (V4L2_TYPE
Re: DVB Simulcrypt
2015-02-23 11:31 GMT+01:00 Rudy Zijlstra : > On 23-02-15 08:44, Honza Petrouš wrote: > > Hi Rudy. > > 2015-02-22 16:28 GMT+01:00 Rudy Zijlstra : >> >> Some more info >> >> On 21-02-15 22:30, Rudy Zijlstra wrote: >>> >>> Dears (Hans?) >>> >>> My setup, where the cable operator was using only irdeto, was working >>> good. Then the cable operator merged with another, and now the networks are >>> being merged. As a result, the encryption has moved from irdeto only to >>> simulcyrpt with Irdeto and Nagra. >>> >>> Current status: >>> - when i put the CA card in a STB, it works >>> - when trying to record an encrypted channel from PC, it no longer works. >> >> Recording system has 3 tuners. All equal, all with same permissions on the >> smartcard. On cards 0 and 2 does not work, but card 1 does work, on all >> channels tested. >> > > Does it mean that descrambling is not working for you? If so, > how do you manage descrambling? By CI-CAM module > or by some "softcam" like oscam? > > Or do you record ENCRYPTED stream and decrypt the recordings > later on? > > > Each tuner has its own legal CI-CAM module. And yes, except for the second > tuner descrambling no longer works > I'm not much familiar with MythTV, so I'm guessing from the mux setup changes, but did you check to descramble the same channel on different tuners? To eliminate the particular change inside one service only. Of course there can be also software issue in CI-CAM module itself (fail in parsing PMT CA descriptors etc). TBH, I think it must be application layer issue, not kernel one. /Honza -- 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 v8 3/3] of: Add of_graph_get_port_by_id function
This patch adds a function to get a port device tree node by port id,
or reg property value.
Signed-off-by: Philipp Zabel
Acked-by: Laurent Pinchart
---
drivers/of/base.c| 32
include/linux/of_graph.h | 7 +++
2 files changed, 39 insertions(+)
diff --git a/drivers/of/base.c b/drivers/of/base.c
index 05b20f1..6398b9c 100644
--- a/drivers/of/base.c
+++ b/drivers/of/base.c
@@ -2081,6 +2081,38 @@ int of_graph_parse_endpoint(const struct device_node
*node,
EXPORT_SYMBOL(of_graph_parse_endpoint);
/**
+ * of_graph_get_port_by_id() - get the port matching a given id
+ * @parent: pointer to the parent device node
+ * @id: id of the port
+ *
+ * Return: A 'port' node pointer with refcount incremented. The caller
+ * has to use of_node_put() on it when done.
+ */
+struct device_node *of_graph_get_port_by_id(struct device_node *parent, u32 id)
+{
+ struct device_node *node, *port;
+
+ node = of_get_child_by_name(parent, "ports");
+ if (node)
+ parent = node;
+
+ for_each_child_of_node(parent, port) {
+ u32 port_id = 0;
+
+ if (of_node_cmp(port->name, "port") != 0)
+ continue;
+ of_property_read_u32(port, "reg", &port_id);
+ if (id == port_id)
+ break;
+ }
+
+ of_node_put(node);
+
+ return port;
+}
+EXPORT_SYMBOL(of_graph_get_port_by_id);
+
+/**
* of_graph_get_next_endpoint() - get next endpoint node
* @parent: pointer to the parent device node
* @prev: previous endpoint node, or NULL to get first
diff --git a/include/linux/of_graph.h b/include/linux/of_graph.h
index e43442e..3c1c95a 100644
--- a/include/linux/of_graph.h
+++ b/include/linux/of_graph.h
@@ -40,6 +40,7 @@ struct of_endpoint {
#ifdef CONFIG_OF
int of_graph_parse_endpoint(const struct device_node *node,
struct of_endpoint *endpoint);
+struct device_node *of_graph_get_port_by_id(struct device_node *node, u32 id);
struct device_node *of_graph_get_next_endpoint(const struct device_node
*parent,
struct device_node *previous);
struct device_node *of_graph_get_remote_port_parent(
@@ -53,6 +54,12 @@ static inline int of_graph_parse_endpoint(const struct
device_node *node,
return -ENOSYS;
}
+static inline struct device_node *of_graph_get_port_by_id(
+ struct device_node *node, u32 id)
+{
+ return NULL;
+}
+
static inline struct device_node *of_graph_get_next_endpoint(
const struct device_node *parent,
struct device_node *previous)
--
2.1.4
--
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 v8 2/3] of: Add for_each_endpoint_of_node helper macro
Note that while of_graph_get_next_endpoint decrements the reference count
of the child node passed to it, of_node_put(child) still has to be called
manually when breaking out of the loop.
Signed-off-by: Philipp Zabel
Acked-by: Laurent Pinchart
---
include/linux/of_graph.h | 11 +++
1 file changed, 11 insertions(+)
diff --git a/include/linux/of_graph.h b/include/linux/of_graph.h
index befef42..e43442e 100644
--- a/include/linux/of_graph.h
+++ b/include/linux/of_graph.h
@@ -26,6 +26,17 @@ struct of_endpoint {
const struct device_node *local_node;
};
+/**
+ * for_each_endpoint_of_node - iterate over every endpoint in a device node
+ * @parent: parent device node containing ports and endpoints
+ * @child: loop variable pointing to the current endpoint node
+ *
+ * When breaking out of the loop, of_node_put(child) has to be called manually.
+ */
+#define for_each_endpoint_of_node(parent, child) \
+ for (child = of_graph_get_next_endpoint(parent, NULL); child != NULL; \
+child = of_graph_get_next_endpoint(parent, child))
+
#ifdef CONFIG_OF
int of_graph_parse_endpoint(const struct device_node *node,
struct of_endpoint *endpoint);
--
2.1.4
--
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 v8 0/3] Add of-graph helpers to loop over endpoints and find ports by id
Hi, Since there now is a merge conflict in imx-drm-core, I've rebased the series onto v4.0-rc1. Also a new driver touched by this change appeared, so the first patch now includes a fix for am437x-vfpe, too. I'd be happy to get an ack for that. This series converts all existing users of of_graph_get_next_endpoint that pass a non-NULL prev argument to the function and decrement its refcount themselves to stop doing that. The of_node_put is moved into of_graph_get_next_endpoint instead. This allows to add a for_each_endpoint_of_node helper macro to loop over all endpoints in a device tree node. Changes since v8: - Rebased onto v4.0-rc1 - Added fix to am437x-vpfe The previous version can be found here: https://lkml.org/lkml/2014/12/23/219 regards Philipp Philipp Zabel (3): of: Decrement refcount of previous endpoint in of_graph_get_next_endpoint of: Add for_each_endpoint_of_node helper macro of: Add of_graph_get_port_by_id function drivers/coresight/of_coresight.c | 13 ++- drivers/gpu/drm/imx/imx-drm-core.c| 11 +- drivers/gpu/drm/rcar-du/rcar_du_kms.c | 15 +++-- drivers/media/platform/am437x/am437x-vpfe.c | 1 - drivers/media/platform/soc_camera/soc_camera.c| 3 +- drivers/of/base.c | 41 ++- drivers/video/fbdev/omap2/dss/omapdss-boot-init.c | 7 +--- include/linux/of_graph.h | 18 ++ 8 files changed, 61 insertions(+), 48 deletions(-) -- 2.1.4 -- 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 v8 1/3] of: Decrement refcount of previous endpoint in of_graph_get_next_endpoint
Decrementing the reference count of the previous endpoint node allows to
use the of_graph_get_next_endpoint function in a for_each_... style macro.
All current users of this function that pass a non-NULL prev parameter
(that is, soc_camera and imx-drm) are changed to not decrement the passed
prev argument's refcount themselves.
Signed-off-by: Philipp Zabel
Acked-by: Mauro Carvalho Chehab
Acked-by: Mathieu Poirier
Acked-by: Laurent Pinchart
Acked-by: Tomi Valkeinen
---
Changes since v7:
- Rebased onto v4.0-rc1
- Added fix for am437x-vpfe
---
drivers/coresight/of_coresight.c | 13 ++---
drivers/gpu/drm/imx/imx-drm-core.c| 11 +--
drivers/gpu/drm/rcar-du/rcar_du_kms.c | 15 ---
drivers/media/platform/am437x/am437x-vpfe.c | 1 -
drivers/media/platform/soc_camera/soc_camera.c| 3 ++-
drivers/of/base.c | 9 +
drivers/video/fbdev/omap2/dss/omapdss-boot-init.c | 7 +--
7 files changed, 11 insertions(+), 48 deletions(-)
diff --git a/drivers/coresight/of_coresight.c b/drivers/coresight/of_coresight.c
index c3efa41..6f75e9d 100644
--- a/drivers/coresight/of_coresight.c
+++ b/drivers/coresight/of_coresight.c
@@ -52,15 +52,6 @@ of_coresight_get_endpoint_device(struct device_node
*endpoint)
endpoint, of_dev_node_match);
}
-static struct device_node *of_get_coresight_endpoint(
- const struct device_node *parent, struct device_node *prev)
-{
- struct device_node *node = of_graph_get_next_endpoint(parent, prev);
-
- of_node_put(prev);
- return node;
-}
-
static void of_coresight_get_ports(struct device_node *node,
int *nr_inport, int *nr_outport)
{
@@ -68,7 +59,7 @@ static void of_coresight_get_ports(struct device_node *node,
int in = 0, out = 0;
do {
- ep = of_get_coresight_endpoint(node, ep);
+ ep = of_graph_get_next_endpoint(node, ep);
if (!ep)
break;
@@ -140,7 +131,7 @@ struct coresight_platform_data
*of_get_coresight_platform_data(
/* Iterate through each port to discover topology */
do {
/* Get a handle on a port */
- ep = of_get_coresight_endpoint(node, ep);
+ ep = of_graph_get_next_endpoint(node, ep);
if (!ep)
break;
diff --git a/drivers/gpu/drm/imx/imx-drm-core.c
b/drivers/gpu/drm/imx/imx-drm-core.c
index a002f53..84cf99f 100644
--- a/drivers/gpu/drm/imx/imx-drm-core.c
+++ b/drivers/gpu/drm/imx/imx-drm-core.c
@@ -431,15 +431,6 @@ int imx_drm_encoder_parse_of(struct drm_device *drm,
}
EXPORT_SYMBOL_GPL(imx_drm_encoder_parse_of);
-static struct device_node *imx_drm_of_get_next_endpoint(
- const struct device_node *parent, struct device_node *prev)
-{
- struct device_node *node = of_graph_get_next_endpoint(parent, prev);
-
- of_node_put(prev);
- return node;
-}
-
/*
* @node: device tree node containing encoder input ports
* @encoder: drm_encoder
@@ -457,7 +448,7 @@ int imx_drm_encoder_get_mux_id(struct device_node *node,
return -EINVAL;
do {
- ep = imx_drm_of_get_next_endpoint(node, ep);
+ ep = of_graph_get_next_endpoint(node, ep);
if (!ep)
break;
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_kms.c
b/drivers/gpu/drm/rcar-du/rcar_du_kms.c
index cc9136e..68dab26 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_kms.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_kms.c
@@ -206,7 +206,7 @@ static int rcar_du_encoders_init_one(struct rcar_du_device
*rcdu,
enum rcar_du_encoder_type enc_type = RCAR_DU_ENCODER_NONE;
struct device_node *connector = NULL;
struct device_node *encoder = NULL;
- struct device_node *prev = NULL;
+ struct device_node *ep_node = NULL;
struct device_node *entity_ep_node;
struct device_node *entity;
int ret;
@@ -225,11 +225,7 @@ static int rcar_du_encoders_init_one(struct rcar_du_device
*rcdu,
entity_ep_node = of_parse_phandle(ep->local_node, "remote-endpoint", 0);
while (1) {
- struct device_node *ep_node;
-
- ep_node = of_graph_get_next_endpoint(entity, prev);
- of_node_put(prev);
- prev = ep_node;
+ ep_node = of_graph_get_next_endpoint(entity, ep_node);
if (!ep_node)
break;
@@ -300,7 +296,7 @@ static int rcar_du_encoders_init_one(struct rcar_du_device
*rcdu,
static int rcar_du_encoders_init(struct rcar_du_device *rcdu)
{
struct device_node *np = rcdu->dev->of_node;
- struct device_node *prev = NULL;
+ struct device_node *ep_node = NULL;
unsigned int num_encoders = 0;
Re: DVB Simulcrypt
On 23-02-15 08:44, Honza Petrouš wrote: Hi Rudy. 2015-02-22 16:28 GMT+01:00 Rudy Zijlstra mailto:r...@grumpydevil.homelinux.org>>: > > Some more info > > On 21-02-15 22:30, Rudy Zijlstra wrote: >> >> Dears (Hans?) >> >> My setup, where the cable operator was using only irdeto, was working good. Then the cable operator merged with another, and now the networks are being merged. As a result, the encryption has moved from irdeto only to simulcyrpt with Irdeto and Nagra. >> >> Current status: >> - when i put the CA card in a STB, it works >> - when trying to record an encrypted channel from PC, it no longer works. > > Recording system has 3 tuners. All equal, all with same permissions on the smartcard. On cards 0 and 2 does not work, but card 1 does work, on all channels tested. > Does it mean that descrambling is not working for you? If so, how do you manage descrambling? By CI-CAM module or by some "softcam" like oscam? Or do you record ENCRYPTED stream and decrypt the recordings later on? Each tuner has its own legal CI-CAM module. And yes, except for the second tuner descrambling no longer works Cheers Rudy /Honza > -- 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] uvcvideo: Don't call vb2 mmap and get_unmapped_area with queue lock held
Laurent Pinchart writes: > Bjørn, does this fix the circular locking dependency you have reported in > "[v3.19-rc7] possible circular locking dependency in uvc_queue_streamoff" ? > The report mentions involves locks, so I'm not 100% this patch will fix the > issue. Sorry, I forgot all about that report after firing it off... Should have followed it up with some more details. Grepping my logs now I cannot find this warning at all after the one I reported. I see it once before (while running 3.19-rc6). So it is definitely not easily reproducible. And I have a bad feeling the trigger might involve completely unrelated USB issues... In any case, thanks for the patch. I will test it for a while and let you know if the same warning shows ut with it. But based on the rare occurence, I don't think I ever will be able to positively confirm that the warning is gone. Bjørn -- 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: Mygica T230 DVB-T/T2/C Ubuntu 14.04 (kernel 3.13.0-45) using media_build
On 2/23/15, Vincent McIntyre wrote: > I saw this too, while working with Antti on adding support for > another rtl* device. > I should add how I triggered this - build --main-git, make install, halt - cold-boot, check modules loaded ok, check /dev/dvb/adapter* exist - try to tune with dvb-apps 'scan' and adapter0/tuner0. This is where the oops occurred. Vince -- 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 v4 1/2] media/v4l2-ctrls: Always run s_ctrl on volatile ctrls
Hi Ricardo,
On 02/17/2015 04:08 PM, Ricardo Ribalda Delgado wrote:
> Volatile controls can change their value outside the v4l-ctrl framework.
> We should ignore the cached written value of the ctrl when evaluating if
> we should run s_ctrl.
I've been thinking some more about this (also due to some comments Laurent
made on irc), and I think this should be done differently.
What you want to do here is to signal that setting this control will execute
some action that needs to happen even if the same value is set twice.
That's not really covered by VOLATILE. Interestingly, the WRITE_ONLY flag is
to be used for just that purpose, but this happens to be a R/W control, so
that can't be used either.
What is needed is the following:
1) Add a new flag: V4L2_CTRL_FLAG_ACTION.
2) Any control that sets FLAG_WRITE_ONLY should OR it with FLAG_ACTION (to
keep the current meaning of WRITE_ONLY).
3) Any control with FLAG_ACTION set should return changed == true in
cluster_changed.
4) Any control with FLAG_VOLATILE set should set ctrl->has_changed to false
to prevent generating the CH_VALUE control (that's a real bug).
Your control will now set FLAG_ACTION and FLAG_VOLATILE and it will do the
right thing.
Basically what was missing was a flag to explicitly signal this 'writing
executes an action' behavior. Trying to shoehorn that into the volatile
flag or the write_only flag is just not right. It's a flag in its own right.
Regards,
Hans
>
> Signed-off-by: Ricardo Ribalda Delgado
> ---
> v4: Hans Verkuil:
>
> explicity set has_changed to false. and add comment
>
> drivers/media/v4l2-core/v4l2-ctrls.c | 11 +++
> 1 file changed, 11 insertions(+)
>
> diff --git a/drivers/media/v4l2-core/v4l2-ctrls.c
> b/drivers/media/v4l2-core/v4l2-ctrls.c
> index 45c5b47..f34a689 100644
> --- a/drivers/media/v4l2-core/v4l2-ctrls.c
> +++ b/drivers/media/v4l2-core/v4l2-ctrls.c
> @@ -1609,6 +1609,17 @@ static int cluster_changed(struct v4l2_ctrl *master)
>
> if (ctrl == NULL)
> continue;
> +
> + if (ctrl->flags & V4L2_CTRL_FLAG_VOLATILE) {
> + /*
> + * Set has_changed to false to avoid generating
> + * the event V4L2_EVENT_CTRL_CH_VALUE
> + */
> + ctrl->has_changed = false;
> + changed = true;
> + continue;
> + }
> +
> for (idx = 0; !ctrl_changed && idx < ctrl->elems; idx++)
> ctrl_changed = !ctrl->type_ops->equal(ctrl, idx,
> ctrl->p_cur, ctrl->p_new);
>
--
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: Mygica T230 DVB-T/T2/C Ubuntu 14.04 (kernel 3.13.0-45) using media_build
I saw this too, while working with Antti on adding support for another rtl2832-based DVB card. The kernel version [0.00] Linux version 3.13.0-45-generic (buildd@kissel) (gcc version 4.8.2 (Ubuntu 4.8.2-19ubuntu1) ) #74-Ubuntu SMP Tue Jan 13 19:37:48 UTC 2015 (Ubuntu 3.13.0-45.74-generic 3.13.11-ckt13) This is what dmesg contained: [ 247.897962] BUG: unable to handle kernel NULL pointer dereference at 0008 [ 247.897971] IP: [] media_entity_pipeline_start+0x24/0x350 [media] [ 247.897982] *pdpt = 1c70f001 *pde = [ 247.897988] Oops: [#1] SMP [ 247.897992] Modules linked in: gpio_ich nvidia(POX) snd_hda_codec_hdmi bnep ir_lirc_codec(OX) rfcomm ir_xmp_decoder(OX) lirc_dev(OX) ir_sony_decoder(OX) ir_sharp_decoder(OX) ir_sanyo_decoder(OX) ir_rc6_decoder(OX) ir_rc5_decoder(OX) ir_nec_decoder(OX) ir_mce_kbd_decoder(OX) ir_jvc_decoder(OX) bluetooth rtl2832_sdr(OX) videobuf2_vmalloc(OX) snd_hda_intel videobuf2_memops(OX) snd_intel8x0 snd_ac97_codec snd_hda_codec videobuf2_core(OX) ac97_bus snd_hwdep v4l2_common(OX) snd_pcm videodev(OX) snd_page_alloc fc0013(OX) snd_seq_midi snd_seq_midi_event rtl2832(OX) snd_rawmidi i2c_mux snd_seq dvb_usb_rtl28xxu(OX) dvb_usb_v2(OX) dvb_core(OX) rc_core(OX) snd_seq_device media(OX) snd_timer dcdbas snd serio_raw drm soundcore lpc_ich shpchp ppdev parport_pc lp mac_hid parport hid_generic tg3 usbhid psmouse ptp e1000 pps_core pata_acpi floppy hid [ 247.898043] CPU: 0 PID: 2967 Comm: kdvb-ad-0-fe-0 Tainted: POX 3.13.0-45-generic #74-Ubuntu [ 247.898046] Hardware name: Dell Inc. OptiPlex GX280/0DG476, BIOS A07 11/29/2005 [ 247.898049] task: e5e9db00 ti: dbb8 task.ti: dbb8 [ 247.898052] EIP: 0060:[] EFLAGS: 00010286 CPU: 0 [ 247.898058] EIP is at media_entity_pipeline_start+0x24/0x350 [media] [ 247.898061] EAX: EBX: e0b26280 ECX: f7b8a580 EDX: f6aac614 [ 247.898063] ESI: f6aac400 EDI: EBP: dbb81f08 ESP: dbb81e30 [ 247.898066] DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068 [ 247.898069] CR0: 8005003b CR2: 0008 CR3: 1c70e000 CR4: 07f0 [ 247.898072] Stack: [ 247.898074] f7b8a5c8 0001 0006 b7de1fcc 0039 0001 [ 247.898081] f7b8a5c8 0001 dbb81eb4 c1089ef6 dbb81eb8 c108c7c9 [ 247.898086] f7b8a580 f7b8a5c8 f7b8a580 f261ea00 e5e9db00 dbb81eac c108a44a [ 247.898093] Call Trace: [ 247.898102] [] ? dequeue_task_fair+0x416/0x7c0 [ 247.898106] [] ? enqueue_task_fair+0x5d9/0x7e0 [ 247.898110] [] ? check_preempt_wakeup+0x1aa/0x250 [ 247.898115] [] ? set_next_entity+0xb1/0xe0 [ 247.898120] [] ? __switch_to+0xb0/0x340 [ 247.898126] [] ? __schedule+0x358/0x770 [ 247.898130] [] ? try_to_wake_up+0x150/0x240 [ 247.898143] [] dvb_frontend_thread+0x331/0x9a0 [dvb_core] [ 247.898154] [] ? dvb_frontend_thread+0x331/0x9a0 [dvb_core] [ 247.898158] [] ? default_wake_function+0x10/0x20 [ 247.898162] [] ? __wake_up_common+0x47/0x70 [ 247.898166] [] ? __wake_up_locked+0x1f/0x30 [ 247.898177] [] ? dvb_frontend_ioctl_legacy.isra.8+0xc20/0xc20 [dvb_core] [ 247.898182] [] kthread+0xa1/0xc0 [ 247.898187] [] ret_from_kernel_thread+0x1b/0x28 [ 247.898191] [] ? kthread_create_on_node+0x140/0x140 [ 247.898193] Code: 90 90 90 90 90 90 90 57 8d 7c 24 08 83 e4 f8 ff 77 fc 55 89 e5 57 56 53 81 ec cc 00 00 00 3e 8d 74 26 00 89 c7 89 85 48 ff ff ff <8b> 40 08 89 95 50 ff ff ff 89 85 60 ff ff ff 05 44 02 00 00 89 [ 247.898229] EIP: [] media_entity_pipeline_start+0x24/0x350 [media] SS:ESP 0068:dbb81e30 [ 247.898236] CR2: 0008 [ 247.898241] ---[ end trace 800df23615d3c02a ]--- The git commit for the media_build tree at the time I compiled everything was commit c40e87b410c9ed170e2ae6ca2aeef06a44621b20 Add writel_relaxed supportHEADmaster Signed-off-by: Hans Verkuil HTH Vince -- 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
