Re: [media-ctl][PATCH] libmediactl: engage udev to get devname

[Andy Shevchenko]

On Mon, 2011-08-15 at 16:52 +0200, Laurent Pinchart wrote: 
> Hi Andy,
> 
> Thank you for the patch.
> 
> What about making it a configuration option to still support systems that 
> don't provide libudev ? We could keep the current behaviour for those.
Good point.
Will do.


-- 
Andy Shevchenko 
Intel Finland Oy
--
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 05/11] drivers/media: do not use EXTRA_CFLAGS

[Laurent Pinchart]

Hi Arnaud,

On Monday 15 August 2011 07:07:08 Arnaud Lacombe wrote:
> Usage of these flags has been deprecated for nearly 4 years by:
> 
> commit f77bf01425b11947eeb3b5b54685212c302741b8
> Author: Sam Ravnborg 
> Date:   Mon Oct 15 22:25:06 2007 +0200
> 
> kbuild: introduce ccflags-y, asflags-y and ldflags-y
> 
> Moreover, these flags (at least EXTRA_CFLAGS) have been documented for
> command line use. By default, gmake(1) do not override command line
> setting, so this is likely to result in build failure or unexpected
> behavior.
> 
> Replace their usage by Kbuild's `{as,cc,ld}flags-y'.
> 
> Cc: Sam Ravnborg 
> Cc: Mauro Carvalho Chehab 
> Cc: linux-media@vger.kernel.org

For drivers/media/video/omap3isp/Makefile,

Acked-by: Laurent Pinchart 

-- 
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

[no subject]

[madloi...@gmx.net]

unsubscribe linux-media
--
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: vb2: dma-sg allocator: change scatterlist allocation method

[Laurent Pinchart]

Hi Marek,

On Tuesday 16 August 2011 07:35:05 Marek Szyprowski wrote:
> On Friday, August 12, 2011 11:55 PM Laurent Pinchart wrote:
> > On Wednesday 10 August 2011 10:23:37 Marek Szyprowski wrote:
> > > From: Andrzej Pietrasiewicz 
> > > 
> > > Scatter-gather lib provides a helper functions to allocate scatter
> > > list, so there is no need to use vmalloc for it. sg_alloc_table()
> > > splits allocation into page size chunks and links them together into a
> > > chain.
> > 
> > Last time I check ARM platforms didn't support SG list chaining. Has that
> > been fixed ?
> 
> DMA-mapping code for ARM platform use for_each_sg() macro which has no
> problems with chained SG lists.

for_each_sg() is fine, but sg_alloc_table() doesn't seem to be. 
__sg_alloc_table(), called from sg_alloc_table(), starts with

#ifndef ARCH_HAS_SG_CHAIN
BUG_ON(nents > max_ents);
#endif

It also calls sg_chain() internally, which starts with

#ifndef ARCH_HAS_SG_CHAIN
BUG();
#endif

ARCH_HAS_SG_CHAIN is defined on ARM if CONFIG_ARM_HAS_SG_CHAIN is set. That's 
a boolean Kconfig option that is currently never set.

-- 
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] Fix locking problem between em28xx and em28xx-dvb modules

[Chris Rankin]

Hi,

I've thought about this patch a bit more overnight, and it occurred to me that 
while  em28xx_init_extension() now takes the device mutex followed by the device 
list mutex, my original fix would have had em28xx_register_extension() taking 
the device list mutex followed by the device mutex. And that sounds suspiciously 
like a potential deadlock to me. So I was wondering: does 
em28xx_register_extension() actually need to lock the device if the device list 
has already been locked?


I've also moved two printk()s outside the region where we hold the device list 
mutex, because locked bits should be as brief as possible and neither printk() 
does anything that needs the lock.


A new patch is attached, for review.

Signed-off-by: Chris Rankin 

--- linux-3.0/drivers/media/video/em28xx/em28xx-core.c.orig	2011-08-16 09:15:46.0 +0100
+++ linux-3.0/drivers/media/video/em28xx/em28xx-core.c	2011-08-16 09:21:08.0 +0100
@@ -1193,8 +1193,8 @@
 	list_for_each_entry(dev, &em28xx_devlist, devlist) {
 		ops->init(dev);
 	}
-	printk(KERN_INFO "Em28xx: Initialized (%s) extension\n", ops->name);
 	mutex_unlock(&em28xx_devlist_mutex);
+	printk(KERN_INFO "Em28xx: Initialized (%s) extension\n", ops->name);
 	return 0;
 }
 EXPORT_SYMBOL(em28xx_register_extension);
@@ -1207,9 +1207,9 @@
 	list_for_each_entry(dev, &em28xx_devlist, devlist) {
 		ops->fini(dev);
 	}
-	printk(KERN_INFO "Em28xx: Removed (%s) extension\n", ops->name);
 	list_del(&ops->next);
 	mutex_unlock(&em28xx_devlist_mutex);
+	printk(KERN_INFO "Em28xx: Removed (%s) extension\n", ops->name);
 }
 EXPORT_SYMBOL(em28xx_unregister_extension);
 
--- linux-3.0/drivers/media/video/em28xx/em28xx-dvb.c.orig	2011-08-16 09:16:03.0 +0100
+++ linux-3.0/drivers/media/video/em28xx/em28xx-dvb.c	2011-08-16 09:17:06.0 +0100
@@ -542,7 +542,6 @@
 	dev->dvb = dvb;
 	dvb->fe[0] = dvb->fe[1] = NULL;
 
-	mutex_lock(&dev->lock);
 	em28xx_set_mode(dev, EM28XX_DIGITAL_MODE);
 	/* init frontend */
 	switch (dev->model) {
@@ -711,7 +710,6 @@
 	em28xx_info("Successfully loaded em28xx-dvb\n");
 ret:
 	em28xx_set_mode(dev, EM28XX_SUSPEND);
-	mutex_unlock(&dev->lock);
 	return result;
 
 out_free:

Re: [GIT PATCHES FOR 3.1] s5p-fimc and noon010pc30 driver updates

[Laurent Pinchart]

Hi Mauro,

On Tuesday 16 August 2011 02:13:00 Mauro Carvalho Chehab wrote:
> Em 15-08-2011 09:30, Laurent Pinchart escreveu:
> > On Tuesday 09 August 2011 22:05:47 Mauro Carvalho Chehab wrote:
> >> Em 29-07-2011 05:36, Laurent Pinchart escreveu:
> >>> On Friday 29 July 2011 06:02:54 Mauro Carvalho Chehab wrote:
>  Em 28-07-2011 19:57, Sylwester Nawrocki escreveu:
> > On 07/28/2011 03:20 PM, Mauro Carvalho Chehab wrote:
> >> Accumulating sub-dev controls at the video node is the right thing
> >> to do.
> >> 
> >> An MC-aware application will need to handle with that, but that
> >> doesn't sound to be hard. All such application would need to do is
> >> to first probe the subdev controls, and, when parsing the videodev
> >> controls, not register controls with duplicated ID's, or to mark
> >> them with some special attribute.
> > 
> > IMHO it's not a big issue in general. Still, both subdev and the host
> > device may support same control id. And then even though the control
> > ids are same on the subdev and the host they could mean physically
> > different controls (since when registering a subdev at the host
> > driver the host's controls take precedence and doubling subdev
> > controls are skipped).
>  
>  True, but, except for specific usecases, the host control is enough.
> >>> 
> >>> Not for embedded devices. In many case the control won't even be
> >>> implemented by the host. If your system has two sensors connected to
> >>> the same host, they will both expose an exposure time control. Which
> >>> one do you configure through the video node ? The two sensors will
> >>> likely have different bounds for the same control, how do you report
> >>> that ?
> >> 
> >> If the device has two sensors that are mutually exclusive, they should
> >> be mapped as two different inputs. The showed control should be the one
> >> used by the currently active input.
> >> 
> >> If the sensors aren't mutually exclusive, then two different video nodes
> >> will be shown in userspace.
> > 
> > It's more complex than that. The OMAP3 ISP driver exposes 7 video nodes
> > regardless of the number of sensors. Sensors can be mutually exclusive or
> > not, depending on the board. S_INPUT has its use cases, but is less
> > useful on embedded hardware.
> 
> Sorry, but exposing a video node that can't be used doesn't make sense.

All those 7 video nodes can be used, depending on userspace's needs.

> >>> Those controls are also quite useless for generic V4L2 applications,
> >>> which will want auto-exposure anyway. This needs to be implemented in
> >>> userspace in libv4l.
> >> 
> >> Several webcams export exposure controls. Why shouldn't those controls
> >> be exposed to userspace anymore?
> >> 
> >> Ok, if the hardware won't support 3A algorithm, libv4l will implement
> >> it, eventually using an extra hardware-aware code to get the best
> >> performance for that specific device, but this doesn't mean that the
> >> user should always use it.
> >> 
> >> Btw, the 3A algorithm is one of the things I don't like on my cell
> >> phone: while it works most of the time, sometimes I want to disable it
> >> and manually adjust, as it produces dark images, when there's a very
> >> bright light somewhere on the image background. Manually adjusting the
> >> exposure time and aperture is something relevant for some users.
> > 
> > It is, but on embedded devices that usually requires the application to
> > be hardware-aware. Exposure time limits depend on blanking, which in
> > turn influences the frame rate along with the pixel clock (often
> > configurable as well). Programming those settings wrong can exceed the
> > ISP available bandwidth.
> > 
> > The world unfortunately stopped being simple some time ago :-)
> > 
> > Also there might be some preference at user space, at which stage of
> > the pipeline to apply some controls. This is where the subdev API
> > helps, and plain video node API does not.
>  
>  Again, this is for specific usecases. On such cases, what is expected
>  is that the more generic control will be exported via V4L2 API.
>  
> >>> Thus it's a bit hard to imagine that we could do something like
> >>> "optionally not to inherit controls" as the subdev/MC API is
> >>> optional.
> >>> 
> >>> :)
> >> 
> >> This was actually implemented. There are some cases at ivtv/cx18
> >> driver where both the bridge and a subdev provides the same control
> >> (audio volume, for example). The idea is to allow the bridge driver
> >> to touch at the subdev control without exposing it to userspace,
> >> since the desire was that the bridge driver itself would expose such
> >> control, using a logic that combines changing the subdev and the
> >> bridge registers for volume.
> > 
> > This seem like hard coding a policy in the driver;) Then there is no
> > way (it might not be wort

Re: [GIT PATCHES FOR 3.1] s5p-fimc and noon010pc30 driver updates

[Laurent Pinchart]

Hi Mauro,

On Tuesday 16 August 2011 02:21:09 Mauro Carvalho Chehab wrote:
> Em 15-08-2011 05:45, Laurent Pinchart escreveu:
> >> After having it there properly working and tested independently, we may
> >> consider patches removing V4L2 interfaces that were obsoleted in favor
> >> of using the libv4l implementation, of course using the Kernel way of
> >> deprecating interfaces. But doing it before having it, doesn't make any
> >> sense.
> > 
> > Once again we're not trying to remove controls, but expose them
> > differently.
> 
> See the comments at the patch series, starting from the patches that
> removes support for S_INPUT. I'm aware that the controls will be exposed
> by both MC and V4L2 API, althrough having ways to expose/hide controls via
> V4L2 API makes patch review a way more complicated than it used to be
> before the MC patches.

The MC API doesn't expose controls. Controls are still exposed by the V4L2 API 
only, but V4L2 can then expose them on subdev nodes in addition to video 
nodes.

-- 
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 8/9] ARM: integrate CMA with DMA-mapping subsystem

[Marek Szyprowski]

Hello,

On Friday, August 12, 2011 5:01 PM Arnd Bergmann wrote:

> On Friday 12 August 2011, Marek Szyprowski wrote:
> > @@ -82,16 +103,16 @@ static struct page *__dma_alloc_buffer(struct device
*dev,
> size_t size, gfp_t gf
> > if (mask < 0xULL)
> > gfp |= GFP_DMA;
> >
> > -   page = alloc_pages(gfp, order);
> > -   if (!page)
> > -   return NULL;
> > -
> > /*
> > -* Now split the huge page and free the excess pages
> > +* Allocate contiguous memory
> >  */
> > -   split_page(page, order);
> > -   for (p = page + (size >> PAGE_SHIFT), e = page + (1 << order); p < e;
p++)
> > -   __free_page(p);
> > +   if (cma_available())
> > +   page = dma_alloc_from_contiguous(dev, count, order);
> > +   else
> > +   page = __dma_alloc_system_pages(count, gfp, order);
> > +
> > +   if (!page)
> > +   return NULL;
> 
> Why do you need the fallback here? I would assume that CMA now has to be
available
> on ARMv6 and up to work at all. When you allocate from
__dma_alloc_system_pages(),
> wouldn't that necessarily fail in the dma_remap_area() stage?

It is not a fallback - I've just merged 2 cases together (CMA case and
coheren/nommu
arch). I agree that such mixed code might be confusing.

> >
> > -   if (arch_is_coherent() || nommu()) {
> > +   if (arch_is_coherent() || nommu() ||
> > +  (cma_available() && !(gfp & GFP_ATOMIC))) {
> > +   /*
> > +* Allocate from system or CMA pages
> > +*/
> > struct page *page = __dma_alloc_buffer(dev, size, gfp);
> > if (!page)
> > return NULL;
> > +   dma_remap_area(page, size, area->prot);
> > pfn = page_to_pfn(page);
> > ret = page_address(page);
> 
> Similarly with coherent and nommu. It seems to me that lumping too
> many cases together creates extra complexity here.
> 
> How about something like
> 
>   if (arch_is_coherent() || nommu())
>   ret = alloc_simple_buffer();
>   else if (arch_is_v4_v5())
>   ret = alloc_remap();
>   else if (gfp & GFP_ATOMIC)
>   ret = alloc_from_pool();
>   else
>   ret = alloc_from_contiguous();
> 
> This also allows a natural conversion to dma_map_ops when we get there.

Ok. Is it ok to enable CMA permanently for ARMv6+? If CMA is left conditional
the dma pool code will be much more complicated, because it will need to support
both CMA and non-CMA cases.

> > /* reserve any platform specific memblock areas */
> > if (mdesc->reserve)
> > mdesc->reserve();
> >
> > +   dma_coherent_reserve();
> > +   dma_contiguous_reserve();
> > +
> > memblock_analyze();
> > memblock_dump_all();
> >  }
> 
> Since we can handle most allocations using CMA on ARMv6+, I would think
> that we can have a much smaller reserved area. Have you tried changing
> dma_coherent_reserve() to allocate out of the contiguous area instead of
> wasting a full 2MB section of memory?

I will move the reserved pool directly into CMA area, so it can be shrunk below
2MiB.

Best regards
-- 
Marek Szyprowski
Samsung Poland R&D Center


--
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/9] ARM: DMA: steal memory for DMA coherent mappings

[Marek Szyprowski]

Hello,

On Friday, August 12, 2011 2:53 PM Arnd Bergmann wrote:

> On Friday 12 August 2011, Marek Szyprowski wrote:
> >
> > From: Russell King 
> >
> > Steal memory from the kernel to provide coherent DMA memory to drivers.
> > This avoids the problem with multiple mappings with differing attributes
> > on later CPUs.
> >
> > Signed-off-by: Russell King 
> > [m.szyprowski: rebased onto 3.1-rc1]
> > Signed-off-by: Marek Szyprowski 
> 
> Hi Marek,
> 
> Is this the same patch that Russell had to revert because it didn't
> work on some of the older machines, in particular those using
> dmabounce?

Yes.
 
> I thought that our discussion ended with the plan to use this only
> for ARMv6+ (which has a problem with double mapping) but not on ARMv5
> and below (which don't have this problem but might need dmabounce).

Ok, my fault. I've forgot to mention that this patch was almost ready 
during Linaro meeting, but I didn't manage to post it that time. Of course 
it doesn't fulfill all the agreements from that discussion.

I was only unsure if we should care about the case where CMA is not enabled
for ARMv6+ or not. This patch was prepared in assumption that 
dma_alloc_coherent should work in both cases - with and without CMA.

Now I assume that for ARMv6+ the CMA should be enabled unconditionally.

Best regards
-- 
Marek Szyprowski
Samsung Poland R&D Center

--
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

[media-ctl][PATCHv2 1/4] libmediactl: restruct error path

[Andy Shevchenko]

Signed-off-by: Andy Shevchenko 
---
 src/media.c |   16 +---
 1 files changed, 9 insertions(+), 7 deletions(-)

diff --git a/src/media.c b/src/media.c
index e3cab86..050289e 100644
--- a/src/media.c
+++ b/src/media.c
@@ -255,7 +255,7 @@ static int media_enum_entities(struct media_device *media)
char target[1024];
char *p;
__u32 id;
-   int ret;
+   int ret = 0;
 
for (id = 0; ; id = entity->info.id) {
size = (media->entities_count + 1) * sizeof(*media->entities);
@@ -268,9 +268,9 @@ static int media_enum_entities(struct media_device *media)
 
ret = ioctl(media->fd, MEDIA_IOC_ENUM_ENTITIES, &entity->info);
if (ret < 0) {
-   if (errno == EINVAL)
-   break;
-   return -errno;
+   if (errno != EINVAL)
+   ret = -errno;
+   break;
}
 
/* Number of links (for outbound links) plus number of pads (for
@@ -281,8 +281,10 @@ static int media_enum_entities(struct media_device *media)
 
entity->pads = malloc(entity->info.pads * 
sizeof(*entity->pads));
entity->links = malloc(entity->max_links * 
sizeof(*entity->links));
-   if (entity->pads == NULL || entity->links == NULL)
-   return -ENOMEM;
+   if (entity->pads == NULL || entity->links == NULL) {
+   ret = -ENOMEM;
+   break;
+   }
 
media->entities_count++;
 
@@ -316,7 +318,7 @@ static int media_enum_entities(struct media_device *media)
strcpy(entity->devname, devname);
}
 
-   return 0;
+   return ret;
 }
 
 struct media_device *media_open(const char *name, int verbose)
-- 
1.7.5.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

[media-ctl][PATCHv2 2/4] libmediactl: split media_get_devname from media_enum_entities

[Andy Shevchenko]

Signed-off-by: Andy Shevchenko 
---
 src/media.c |   69 +-
 1 files changed, 39 insertions(+), 30 deletions(-)

diff --git a/src/media.c b/src/media.c
index 050289e..fc05a86 100644
--- a/src/media.c
+++ b/src/media.c
@@ -245,15 +245,50 @@ static int media_enum_links(struct media_device *media)
return ret;
 }
 
-static int media_enum_entities(struct media_device *media)
+static int media_get_devname(struct media_entity *entity)
 {
-   struct media_entity *entity;
struct stat devstat;
-   unsigned int size;
char devname[32];
char sysname[32];
char target[1024];
char *p;
+   int ret;
+
+   if (media_entity_type(entity) != MEDIA_ENT_T_DEVNODE &&
+   media_entity_type(entity) != MEDIA_ENT_T_V4L2_SUBDEV)
+   return 0;
+
+   sprintf(sysname, "/sys/dev/char/%u:%u", entity->info.v4l.major,
+   entity->info.v4l.minor);
+   ret = readlink(sysname, target, sizeof(target));
+   if (ret < 0)
+   return -errno;
+
+   target[ret] = '\0';
+   p = strrchr(target, '/');
+   if (p == NULL)
+   return -EINVAL;
+
+   sprintf(devname, "/dev/%s", p + 1);
+   ret = stat(devname, &devstat);
+   if (ret < 0)
+   return -errno;
+
+   /* Sanity check: udev might have reordered the device nodes.
+* Make sure the major/minor match. We should really use
+* libudev.
+*/
+   if (major(devstat.st_rdev) == entity->info.v4l.major &&
+   minor(devstat.st_rdev) == entity->info.v4l.minor)
+   strcpy(entity->devname, devname);
+
+   return 0;
+}
+
+static int media_enum_entities(struct media_device *media)
+{
+   struct media_entity *entity;
+   unsigned int size;
__u32 id;
int ret = 0;
 
@@ -289,33 +324,7 @@ static int media_enum_entities(struct media_device *media)
media->entities_count++;
 
/* Find the corresponding device name. */
-   if (media_entity_type(entity) != MEDIA_ENT_T_DEVNODE &&
-   media_entity_type(entity) != MEDIA_ENT_T_V4L2_SUBDEV)
-   continue;
-
-   sprintf(sysname, "/sys/dev/char/%u:%u", entity->info.v4l.major,
-   entity->info.v4l.minor);
-   ret = readlink(sysname, target, sizeof(target));
-   if (ret < 0)
-   continue;
-
-   target[ret] = '\0';
-   p = strrchr(target, '/');
-   if (p == NULL)
-   continue;
-
-   sprintf(devname, "/dev/%s", p + 1);
-   ret = stat(devname, &devstat);
-   if (ret < 0)
-   continue;
-
-   /* Sanity check: udev might have reordered the device nodes.
-* Make sure the major/minor match. We should really use
-* libudev.
-*/
-   if (major(devstat.st_rdev) == entity->info.v4l.major &&
-   minor(devstat.st_rdev) == entity->info.v4l.minor)
-   strcpy(entity->devname, devname);
+   media_get_devname(entity);
}
 
return ret;
-- 
1.7.5.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

[media-ctl][PATCHv2 3/4] libmediactl: use udev conditionally to get a devname

[Andy Shevchenko]

Signed-off-by: Andy Shevchenko 
---
 configure.in|   22 ++
 src/Makefile.am |2 ++
 src/media.c |   50 ++
 3 files changed, 74 insertions(+), 0 deletions(-)

diff --git a/configure.in b/configure.in
index fd4c70c..45e0663 100644
--- a/configure.in
+++ b/configure.in
@@ -13,6 +13,28 @@ AC_PROG_LIBTOOL
 
 # Checks for libraries.
 
+AC_ARG_WITH([libudev],
+AS_HELP_STRING([--without-libudev],
+[Ignore presence of libudev and disable it]))
+
+AS_IF([test "x$with_libudev" != "xno"],
+[PKG_CHECK_MODULES(libudev, libudev, have_libudev=yes, have_libudev=no)],
+[have_libudev=no])
+
+AS_IF([test "x$have_libudev" = "xyes"],
+[
+AC_DEFINE([HAVE_LIBUDEV], [], [Use libudev])
+LIBUDEV_CFLAGS="$lbudev_CFLAGS"
+LIBUDEV_LIBS="$libudev_LIBS"
+AC_SUBST(LIBUDEV_CFLAGS)
+AC_SUBST(LIBUDEV_LIBS)
+],
+[AS_IF([test "x$with_libudev" = "xyes"],
+[AC_MSG_ERROR([libudev requested but not found])
+])
+])
+
+
 # Kernel headers path.
 AC_ARG_WITH(kernel-headers,
 [AC_HELP_STRING([--with-kernel-headers=DIR],
diff --git a/src/Makefile.am b/src/Makefile.am
index 267ea83..52628d2 100644
--- a/src/Makefile.am
+++ b/src/Makefile.am
@@ -5,6 +5,8 @@ mediactl_includedir=$(includedir)/mediactl
 mediactl_include_HEADERS = media.h subdev.h
 
 bin_PROGRAMS = media-ctl
+media_ctl_CFLAGS = $(LIBUDEV_CFLAGS)
+media_ctl_LDFLAGS = $(LIBUDEV_LIBS)
 media_ctl_SOURCES = main.c options.c options.h tools.h
 media_ctl_LDADD = libmediactl.la libv4l2subdev.la
 
diff --git a/src/media.c b/src/media.c
index fc05a86..e159526 100644
--- a/src/media.c
+++ b/src/media.c
@@ -17,6 +17,8 @@
  * with this program; if not, write to the Free Software Foundation, Inc.,
  */
 
+#include "config.h"
+
 #include 
 #include 
 #include 
@@ -31,6 +33,10 @@
 #include 
 #include 
 
+#ifdef HAVE_LIBUDEV
+#include 
+#endif /* HAVE_LIBUDEV */
+
 #include "media.h"
 #include "tools.h"
 
@@ -245,6 +251,37 @@ static int media_enum_links(struct media_device *media)
return ret;
 }
 
+#ifdef HAVE_LIBUDEV
+
+static struct udev *udev;
+
+static int media_get_devname(struct media_entity *entity)
+{
+   dev_t devnum;
+   struct udev_device *device;
+   const char *p;
+   int ret = -ENODEV;
+
+   if (media_entity_type(entity) != MEDIA_ENT_T_DEVNODE &&
+   media_entity_type(entity) != MEDIA_ENT_T_V4L2_SUBDEV)
+   return 0;
+
+   devnum = makedev(entity->info.v4l.major, entity->info.v4l.minor);
+   printf("looking up device: %u:%u\n", major(devnum), minor(devnum));
+   device = udev_device_new_from_devnum(udev, 'c', devnum);
+   if (device) {
+   p = udev_device_get_devnode(device);
+   if (p)
+   snprintf(entity->devname, sizeof(entity->devname), 
"%s", p);
+   ret = 0;
+   }
+
+   udev_device_unref(device);
+   return ret;
+}
+
+#else  /* HAVE_LIBUDEV */
+
 static int media_get_devname(struct media_entity *entity)
 {
struct stat devstat;
@@ -284,6 +321,7 @@ static int media_get_devname(struct media_entity *entity)
 
return 0;
 }
+#endif /* HAVE_LIBUDEV */
 
 static int media_enum_entities(struct media_device *media)
 {
@@ -292,6 +330,14 @@ static int media_enum_entities(struct media_device *media)
__u32 id;
int ret = 0;
 
+#ifdef HAVE_LIBUDEV
+   udev = udev_new();
+   if (udev == NULL) {
+   printf("unable to allocate memory for context\n");
+   return -ENOMEM;
+   }
+#endif /* HAVE_LIBUDEV */
+
for (id = 0; ; id = entity->info.id) {
size = (media->entities_count + 1) * sizeof(*media->entities);
media->entities = realloc(media->entities, size);
@@ -327,6 +373,10 @@ static int media_enum_entities(struct media_device *media)
media_get_devname(entity);
}
 
+#ifdef HAVE_LIBUDEV
+   udev_unref(udev);
+   udev = NULL;
+#endif
return ret;
 }
 
-- 
1.7.5.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

[media-ctl][PATCHv2 4/4] libmediactl: pass verbose to media_get_devname

[Andy Shevchenko]

Signed-off-by: Andy Shevchenko 
---
 src/media.c |   13 +++--
 1 files changed, 7 insertions(+), 6 deletions(-)

diff --git a/src/media.c b/src/media.c
index e159526..e276df5 100644
--- a/src/media.c
+++ b/src/media.c
@@ -255,7 +255,7 @@ static int media_enum_links(struct media_device *media)
 
 static struct udev *udev;
 
-static int media_get_devname(struct media_entity *entity)
+static int media_get_devname(struct media_entity *entity, int verbose)
 {
dev_t devnum;
struct udev_device *device;
@@ -267,7 +267,8 @@ static int media_get_devname(struct media_entity *entity)
return 0;
 
devnum = makedev(entity->info.v4l.major, entity->info.v4l.minor);
-   printf("looking up device: %u:%u\n", major(devnum), minor(devnum));
+   if (verbose)
+   printf("looking up device: %u:%u\n", major(devnum), 
minor(devnum));
device = udev_device_new_from_devnum(udev, 'c', devnum);
if (device) {
p = udev_device_get_devnode(device);
@@ -282,7 +283,7 @@ static int media_get_devname(struct media_entity *entity)
 
 #else  /* HAVE_LIBUDEV */
 
-static int media_get_devname(struct media_entity *entity)
+static int media_get_devname(struct media_entity *entity, int verbose)
 {
struct stat devstat;
char devname[32];
@@ -323,7 +324,7 @@ static int media_get_devname(struct media_entity *entity)
 }
 #endif /* HAVE_LIBUDEV */
 
-static int media_enum_entities(struct media_device *media)
+static int media_enum_entities(struct media_device *media, int verbose)
 {
struct media_entity *entity;
unsigned int size;
@@ -370,7 +371,7 @@ static int media_enum_entities(struct media_device *media)
media->entities_count++;
 
/* Find the corresponding device name. */
-   media_get_devname(entity);
+   media_get_devname(entity, verbose);
}
 
 #ifdef HAVE_LIBUDEV
@@ -404,7 +405,7 @@ struct media_device *media_open(const char *name, int 
verbose)
if (verbose)
printf("Enumerating entities\n");
 
-   ret = media_enum_entities(media);
+   ret = media_enum_entities(media, verbose);
if (ret < 0) {
printf("%s: Unable to enumerate entities for device %s (%s)\n",
__func__, name, strerror(-ret));
-- 
1.7.5.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

Re: dvb-apps: update DVB-T intial tuning files for Finland (fi-*)

[Hein Rigolo]

On Mon, Aug 15, 2011 at 12:33 PM, Antti Palosaari  wrote:
> On 08/15/2011 12:56 PM, Hein Rigolo wrote:
>> On Mon, Aug 15, 2011 at 2:38 AM, Antti Palosaari  wrote:
>>> Updates all Finnish channels as today.
>>>
>>> Antti
>>
>> Do we still need to have separate initial tuning files per region in finland?
>>
>> For France it was decided that the auto-With167kHzOffsets file would
>> be enough to find all possible DVB-T transponders in France. It was
>> suggested to create a fr-All that would be symlinked to the
>> auto-With167kHzOffsets file, but that was not implemented yet (as far
>> as I can see from the dvb-apps repository)
>>
>> Can this approach also work for Finland?
>
> It was spoken ages for creation of EU-All, Taiwan-All, UK-All etc. but I
> don't remember which have been problem. For example many Windows
> channels scanner have such files. Finland uses standard EU channels,
> channels under 20 are VHF 7 MHz and channels over 20 are UHF 8 MHz. Just
> same used almost everywhere in EU.
>
Actually you already see the move the *-All happening in a lot of
countries. Looking at the latest dvb-t directory in the dvb-apps
repository i already see the following countries:

be-All
ch-All
cz-All
dk-All
hr-All
il-All
lt-All
lu-All
nl-All

Then there are single files for some countries without the All

ad-Andorra
at-Official
hk-HongKong

and then there are the country specific auto-* files
auto-Australia
auto-Italy
auto-Taiwan

For france it was decided that auto-With167kHzOffsets would be good
enough (but there is no fr-All that points to this file)

So the generic EU-All etc might not be there, but effectively they are
already somewhere in these other files.

So then we could just decide the make a generic file, and symlink the
country specific *-All files to this generic file where appropriate,
or have separate files for those countries that use a different
standard.

Hein
--
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: vb2: dma-sg allocator: change scatterlist allocation method

[Marek Szyprowski]

Hello,

On Tuesday, August 16, 2011 10:42 AM Laurent Pinchart wrote:

> On Tuesday 16 August 2011 07:35:05 Marek Szyprowski wrote:
> > On Friday, August 12, 2011 11:55 PM Laurent Pinchart wrote:
> > > On Wednesday 10 August 2011 10:23:37 Marek Szyprowski wrote:
> > > > From: Andrzej Pietrasiewicz 
> > > >
> > > > Scatter-gather lib provides a helper functions to allocate scatter
> > > > list, so there is no need to use vmalloc for it. sg_alloc_table()
> > > > splits allocation into page size chunks and links them together into a
> > > > chain.
> > >
> > > Last time I check ARM platforms didn't support SG list chaining. Has that
> > > been fixed ?
> >
> > DMA-mapping code for ARM platform use for_each_sg() macro which has no
> > problems with chained SG lists.
> 
> for_each_sg() is fine, but sg_alloc_table() doesn't seem to be.
> __sg_alloc_table(), called from sg_alloc_table(), starts with
> 
> #ifndef ARCH_HAS_SG_CHAIN
> BUG_ON(nents > max_ents);
> #endif
> 
> It also calls sg_chain() internally, which starts with
> 
> #ifndef ARCH_HAS_SG_CHAIN
> BUG();
> #endif
> 
> ARCH_HAS_SG_CHAIN is defined on ARM if CONFIG_ARM_HAS_SG_CHAIN is set. That's
> a boolean Kconfig option that is currently never set.

Right, I wasn't aware of that, but it still doesn't look like an issue. The only

client of dma-sg allocator is marvell-ccic, which is used on x86 systems. If one
needs dma-sg allocator on ARM, he should follow the suggestion from the 
74facffeca3795ffb5cf8898f5859fbb822e4c5d commit message.

Best regards
-- 
Marek Szyprowski
Samsung Poland R&D Center

--
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: [mythtv-users] Anyone tested the DVB-T2 dual tuner TBS6280?

[Harald Gustafsson]

On Mon, Aug 15, 2011 at 8:11 PM, Simon Hobson  wrote:
>>Date: Sat, 13 Aug 2011 22:08:30 +0300
>>From: Turbosight Europe 
...
>>also, in case of TBS 6280 there is something else you should know -
>>currently we keep two separate Linux drivers: one that support DVB-T
>>only and another that supports DVB-T2 only. that's because we want
>>more people to test those two drivers before we merge them and it's
>>more efficient to locate the problem in case a customer report such.
>>so, the driver for TBS 6280 you can find on our website supports
>>DVB-T only, but it can be switched to support DVB-T2 very easy. so,
>>single driver that supports DVB-T and DVB-T2 will be released after
>>we're sure both codes are bug-free. so, far feedback we received
>>doesn't reveal any serious bugs and reported problems were fixed -
>>as i mentioned we already have customers in UK that are Linux users
>>and use the card to watch DVB-T2 signal in UK.

OK so this states that the current drivers don't support both DVB-T
and -T2 simultaneously. This is good to know since this would be my
common usage, going to record DVB-T2 on one of the tuners while
recording DVB-T on the other.

/Harald
--
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: vb2: dma-sg allocator: change scatterlist allocation method

[Laurent Pinchart]

Hi Marek,

On Tuesday 16 August 2011 12:34:56 Marek Szyprowski wrote:
> On Tuesday, August 16, 2011 10:42 AM Laurent Pinchart wrote:
> > On Tuesday 16 August 2011 07:35:05 Marek Szyprowski wrote:
> > > On Friday, August 12, 2011 11:55 PM Laurent Pinchart wrote:
> > > > On Wednesday 10 August 2011 10:23:37 Marek Szyprowski wrote:
> > > > > From: Andrzej Pietrasiewicz 
> > > > > 
> > > > > Scatter-gather lib provides a helper functions to allocate scatter
> > > > > list, so there is no need to use vmalloc for it. sg_alloc_table()
> > > > > splits allocation into page size chunks and links them together
> > > > > into a chain.
> > > > 
> > > > Last time I check ARM platforms didn't support SG list chaining. Has
> > > > that been fixed ?
> > > 
> > > DMA-mapping code for ARM platform use for_each_sg() macro which has no
> > > problems with chained SG lists.
> > 
> > for_each_sg() is fine, but sg_alloc_table() doesn't seem to be.
> > __sg_alloc_table(), called from sg_alloc_table(), starts with
> > 
> > #ifndef ARCH_HAS_SG_CHAIN
> > 
> > BUG_ON(nents > max_ents);
> > 
> > #endif
> > 
> > It also calls sg_chain() internally, which starts with
> > 
> > #ifndef ARCH_HAS_SG_CHAIN
> > 
> > BUG();
> > 
> > #endif
> > 
> > ARCH_HAS_SG_CHAIN is defined on ARM if CONFIG_ARM_HAS_SG_CHAIN is set.
> > That's a boolean Kconfig option that is currently never set.
> 
> Right, I wasn't aware of that, but it still doesn't look like an issue. The
> only client of dma-sg allocator is marvell-ccic, which is used on x86
> systems. If one needs dma-sg allocator on ARM, he should follow the
> suggestion from the 74facffeca3795ffb5cf8898f5859fbb822e4c5d commit message.

Won't the dma-sg allocator be the right one for systems with an IOMMU ? If so 
we'll soon run into this issue. I'd like to port the OMAP3 ISP driver to 
videobuf2.

-- 
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] media: vb2: dma-sg allocator: change scatterlist allocation method

[Marek Szyprowski]

Hello,

On Tuesday, August 16, 2011 1:02 PM Laurent Pinchart wrote:

> On Tuesday 16 August 2011 12:34:56 Marek Szyprowski wrote:
> > On Tuesday, August 16, 2011 10:42 AM Laurent Pinchart wrote:
> > > On Tuesday 16 August 2011 07:35:05 Marek Szyprowski wrote:
> > > > On Friday, August 12, 2011 11:55 PM Laurent Pinchart wrote:
> > > > > On Wednesday 10 August 2011 10:23:37 Marek Szyprowski wrote:
> > > > > > From: Andrzej Pietrasiewicz 
> > > > > >
> > > > > > Scatter-gather lib provides a helper functions to allocate scatter
> > > > > > list, so there is no need to use vmalloc for it. sg_alloc_table()
> > > > > > splits allocation into page size chunks and links them together
> > > > > > into a chain.
> > > > >
> > > > > Last time I check ARM platforms didn't support SG list chaining. Has
> > > > > that been fixed ?
> > > >
> > > > DMA-mapping code for ARM platform use for_each_sg() macro which has no
> > > > problems with chained SG lists.
> > >
> > > for_each_sg() is fine, but sg_alloc_table() doesn't seem to be.
> > > __sg_alloc_table(), called from sg_alloc_table(), starts with
> > >
> > > #ifndef ARCH_HAS_SG_CHAIN
> > >
> > > BUG_ON(nents > max_ents);
> > >
> > > #endif
> > >
> > > It also calls sg_chain() internally, which starts with
> > >
> > > #ifndef ARCH_HAS_SG_CHAIN
> > >
> > > BUG();
> > >
> > > #endif
> > >
> > > ARCH_HAS_SG_CHAIN is defined on ARM if CONFIG_ARM_HAS_SG_CHAIN is set.
> > > That's a boolean Kconfig option that is currently never set.
> >
> > Right, I wasn't aware of that, but it still doesn't look like an issue. The
> > only client of dma-sg allocator is marvell-ccic, which is used on x86
> > systems. If one needs dma-sg allocator on ARM, he should follow the
> > suggestion from the 74facffeca3795ffb5cf8898f5859fbb822e4c5d commit message.
> 
> Won't the dma-sg allocator be the right one for systems with an IOMMU ? If so
> we'll soon run into this issue. I'd like to port the OMAP3 ISP driver to
> videobuf2.

Nope. The correct place for IOMMU is dma-contig allocator. In theory DMA-mapping
functions SHOULD hide the presence of the IOMMU from the driver. The driver
would
only need to get the 'dma_address' of the buffer and write it to the respective
multimedia device register.

The proof-of-concept of such solution for kernel allocated buffer has been 
presented in my first ARM dma-mapping patches: 
http://git.infradead.org/users/kmpark/linux-2.6-samsung/shortlog/refs/heads/dma-
mapping 

User pointer buffers will need a bit more work to get them working correctly for
both iommu and non-iommu cases. For IOMMU dma_map_sg() will just fill the
scatter
list with just one dma_addr entry and it will contain the address of the buffer
in driver's io address space. Non-IOMMU needs some more tweaking (also in the
DMA-mapping)

IMHO the best way to porting OMAP3 ISP to videobuf2 is to first create a custom
memory allocator that working with OMAP3 IOMMU directly and then
adapt/merge/port
it to DMA-mapping based approach.

You can also refer to our first approaches with videobuf2-dma-iommu allocator:
http://lwn.net/Articles/439175/ 
Especially the discussion in that thread is really important for understanding
how the IOMMU should be integrated in the Linux kernel.

Best regards
-- 
Marek Szyprowski
Samsung Poland R&D Center

--
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: [mythtv-users] Anyone tested the DVB-T2 dual tuner TBS6280?

[Simon Hobson]

Harald Gustafsson wrote:


OK so this states that the current drivers don't support both DVB-T
and -T2 simultaneously. This is good to know since this would be my
common usage, going to record DVB-T2 on one of the tuners while
recording DVB-T on the other.


Ditto - no point having two T2 tuners in the UK since we only have 
one T2 mux at the moment.


But I can see their point - keep things separate and simplify 
debugging. Definitely confirms my thoughts that this device is still 
too "bleeding edge" for most people (but then so were DVB-T tuners 
once !)


--
Simon Hobson

Visit http://www.magpiesnestpublishing.co.uk/ for books by acclaimed
author Gladys Hobson. Novels - poetry - short stories - ideal as
Christmas stocking fillers. Some available as e-books.
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 3/4] drivers/media/video/hexium_gemini.c: delete useless initialization

[Jean Delvare]

Hi Julia,

On Thu,  4 Aug 2011 12:29:33 +0200, Julia Lawall wrote:
> From: Julia Lawall 
> 
> Delete nontrivial initialization that is immediately overwritten by the
> result of an allocation function.
> (...)
> Signed-off-by: Julia Lawall 
> 
> ---
>  drivers/media/video/hexium_gemini.c |2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff -u -p a/drivers/media/video/hexium_gemini.c 
> b/drivers/media/video/hexium_gemini.c
> --- a/drivers/media/video/hexium_gemini.c
> +++ b/drivers/media/video/hexium_gemini.c
> @@ -352,7 +352,7 @@ static struct saa7146_ext_vv vv_data;
>  /* this function only gets called when the probing was successful */
>  static int hexium_attach(struct saa7146_dev *dev, struct 
> saa7146_pci_extension_data *info)
>  {
> - struct hexium *hexium = (struct hexium *) dev->ext_priv;
> + struct hexium *hexium;
>   int ret;
>  
>   DEB_EE((".\n"));
> 

Looks correct.

Acked-by: Jean Delvare 

-- 
Jean Delvare
--
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: Added extensive feature set to the OV5642 camera driver

[Bastian Hecht]

The driver now supports arbitray resolutions (width up to 2592, height
up to 720), automatic/manual gain, automatic/manual white balance,
automatic/manual exposure control, vertical flip, brightness control,
contrast control and saturation control. Additionally the following
effects are available now: rotating the hue in the colorspace, gray
scale image and solarize effect.

Signed-of-by: Bastian Hecht 

---
diff --git a/drivers/media/video/ov5642.c b/drivers/media/video/ov5642.c
index 6410bda..069a720 100644
--- a/drivers/media/video/ov5642.c
+++ b/drivers/media/video/ov5642.c
@@ -14,8 +14,10 @@
  * published by the Free Software Foundation.
  */
 
+#include 
 #include 
 #include 
+#include 
 #include 
 #include 
 
@@ -28,13 +30,25 @@
 #define REG_CHIP_ID_HIGH   0x300a
 #define REG_CHIP_ID_LOW0x300b
 
+#define REG_RED_GAIN_HIGH  0x3400
+#define REG_RED_GAIN_LOW   0x3401
+#define REG_BLUE_GAIN_HIGH 0x3404
+#define REG_BLUE_GAIN_LOW  0x3405
+#define REG_AWB_MANUAL 0x3406
+#define REG_EXP_HIGH   0x3500
+#define REG_EXP_MIDDLE 0x3501
+#define REG_EXP_LOW0x3502
+#define REG_EXP_GAIN_CTRL  0x3503
+#define REG_GAIN   0x350b
+#define REG_EXTEND_FRAME_TIME_HIGH 0x350c
+#define REG_EXTEND_FRAME_TIME_LOW  0x350d
 #define REG_WINDOW_START_X_HIGH0x3800
 #define REG_WINDOW_START_X_LOW 0x3801
 #define REG_WINDOW_START_Y_HIGH0x3802
 #define REG_WINDOW_START_Y_LOW 0x3803
 #define REG_WINDOW_WIDTH_HIGH  0x3804
 #define REG_WINDOW_WIDTH_LOW   0x3805
-#define REG_WINDOW_HEIGHT_HIGH 0x3806
+#define REG_WINDOW_HEIGHT_HIGH 0x3806
 #define REG_WINDOW_HEIGHT_LOW  0x3807
 #define REG_OUT_WIDTH_HIGH 0x3808
 #define REG_OUT_WIDTH_LOW  0x3809
@@ -44,19 +58,87 @@
 #define REG_OUT_TOTAL_WIDTH_LOW0x380d
 #define REG_OUT_TOTAL_HEIGHT_HIGH  0x380e
 #define REG_OUT_TOTAL_HEIGHT_LOW   0x380f
+#define REG_FLIP_SUBSAMPLE 0x3818
+#define REG_OUTPUT_FORMAT  0x4300
+#define REG_ISP_CTRL_010x5001
+#define REG_DIGITAL_EFFECTS0x5580
+#define REG_HUE_COS0x5581
+#define REG_HUE_SIN0x5582
+#define REG_BLUE_SATURATION0x5583
+#define REG_RED_SATURATION 0x5584
+#define REG_CONTRAST   0x5588
+#define REG_BRIGHTNESS 0x5589
+#define REG_D_E_AUXILLARY  0x558a
+#define REG_AVG_WINDOW_END_X_HIGH  0x5682
+#define REG_AVG_WINDOW_END_X_LOW   0x5683
+#define REG_AVG_WINDOW_END_Y_HIGH  0x5686
+#define REG_AVG_WINDOW_END_Y_LOW   0x5687
+
+/* default values in native space */
+#define DEFAULT_RBBALANCE  0x400
+#define DEFAULT_CONTRAST   0x20
+#define DEFAULT_SATURATION 0x40
+
+#define MAX_EXP_NATIVE 0x01
+#define MAX_GAIN_NATIVE0x1f
+#define MAX_RBBALANCE_NATIVE   0x0fff
+#define MAX_EXP0x
+#define MAX_GAIN   0xff
+#define MAX_RBBALANCE  0xff
+#define MAX_HUE_TRIG_NATIVE0x80
+
+#define OV5642_CONTROL_BLUE_SATURATION (V4L2_CID_PRIVATE_BASE + 0)
+#define OV5642_CONTROL_RED_SATURATION  (V4L2_CID_PRIVATE_BASE + 1)
+#define OV5642_CONTROL_GRAY_SCALE  (V4L2_CID_PRIVATE_BASE + 2)
+#define OV5642_CONTROL_SOLARIZE(V4L2_CID_PRIVATE_BASE + 3)
+
+#define EXP_V4L2_TO_NATIVE(x) ((x) << 4)
+#define EXP_NATIVE_TO_V4L2(x) ((x) >> 4)
+#define GAIN_V4L2_TO_NATIVE(x) ((x) * MAX_GAIN_NATIVE / MAX_GAIN)
+#define GAIN_NATIVE_TO_V4L2(x) ((x) * MAX_GAIN / MAX_GAIN_NATIVE)
+#define RBBALANCE_V4L2_TO_NATIVE(x) ((x) * MAX_RBBALANCE_NATIVE / 
MAX_RBBALANCE)
+#define RBBALANCE_NATIVE_TO_V4L2(x) ((x) * MAX_RBBALANCE / 
MAX_RBBALANCE_NATIVE)
+
+/* flaw in the datasheet. we need some extra lines */
+#define MANUAL_LONG_EXP_SAFETY_DISTANCE20
+
+/* active pixel array size */
+#define OV5642_SENSOR_SIZE_X   2592
+#define OV5642_SENSOR_SIZE_Y   1944
+
+/* current maximum working size */
+#define OV5642_MAX_WIDTH   OV5642_SENSOR_SIZE_X
+#define OV5642_MAX_HEIGHT  720
+
+/* default sizes */
+#define OV5642_DEFAULT_WIDTH   1280
+#define OV5642_DEFAULT_HEIGHT  OV5642_MAX_HEIGHT
+
+/* minimum extra blanking */
+#define BLANKING_EXTRA_WIDTH   500
+#define BLANKING_EXTRA_HEIGHT  20
 
 /*
- * define standard resolution.
- * Works currently only for up to 720 lines
- * eg. 320x240, 640x480, 800x600, 1280x720, 2048x720
+ * the sensor's autoexposure is buggy when setting total_height low.
+ * It tries to expose longer than 1 frame period without taking care of it
+ * and this leads to weird output. So we set 1000 lines as minimum.
  */
 
-#define OV5642_WIDTH   1280
-#define O

Re: [PATCH 1/6 v4] V4L: add two new ioctl()s for multi-size videobuffer management

[Guennadi Liakhovetski]

On Mon, 15 Aug 2011, Guennadi Liakhovetski wrote:

> On Mon, 15 Aug 2011, Hans Verkuil wrote:
> 
> > On Monday, August 15, 2011 13:28:23 Guennadi Liakhovetski wrote:
> > > Hi Hans
> > > 
> > > On Mon, 8 Aug 2011, Hans Verkuil wrote:

[snip]

> > > > but I've changed my mind: I think
> > > > this should use a struct v4l2_format after all.
> 
> While switching back, I have to change the struct vb2_ops::queue_setup() 
> operation to take a struct v4l2_create_buffers pointer. An earlier version 
> of this patch just added one more parameter to .queue_setup(), which is 
> easier - changes to videobuf2-core.c are smaller, but it is then 
> redundant. We could use the create pointer for both input and output. The 
> video plane configuration in frame format is the same as what is 
> calculated in .queue_setup(), IIUC. So, we could just let the driver fill 
> that one in. This would require then the videobuf2-core.c to parse struct 
> v4l2_format to decide which union member we need, depending on the buffer 
> type. Do we want this or shall drivers duplicate plane sizes in separate 
> .queue_setup() parameters?

Let me explain my question a bit. The current .queue_setup() method is

int (*queue_setup)(struct vb2_queue *q, unsigned int *num_buffers,
   unsigned int *num_planes, unsigned int sizes[],
   void *alloc_ctxs[]);

To support multiple-size buffers we also have to pass a pointer to struct 
v4l2_create_buffers to this function now. We can either do it like this:

int (*queue_setup)(struct vb2_queue *q,
   struct v4l2_create_buffers *create,
   unsigned int *num_buffers,
   unsigned int *num_planes, unsigned int sizes[],
   void *alloc_ctxs[]);

and let all drivers fill in respective fields in *create, e.g., either do

create->format.fmt.pix_mp.plane_fmt[i].sizeimage = ...;
create->format.fmt.pix_mp.num_planes = ...;

and also duplicate it in method parameters

*num_planes = create->format.fmt.pix_mp.num_planes;
sizes[i] = create->format.fmt.pix_mp.plane_fmt[i].sizeimage;

or with

create->format.fmt.pix.sizeimage = ...;

for single-plane. Alternatively we make the prototype

int (*queue_setup)(struct vb2_queue *q,
   struct v4l2_create_buffers *create,
   unsigned int *num_buffers,
   void *alloc_ctxs[]);

then drivers only fill in *create, and the videobuf2-core will have to 
check create->format.type to decide, which of create->format.fmt.* is 
relevant and extract plane sizes from there.

Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/
--
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 8/9] ARM: integrate CMA with DMA-mapping subsystem

[Arnd Bergmann]

On Tuesday 16 August 2011, Marek Szyprowski wrote:
> On Friday, August 12, 2011 5:01 PM Arnd Bergmann wrote:

> > How about something like
> > 
> >   if (arch_is_coherent() || nommu())
> >   ret = alloc_simple_buffer();
> >   else if (arch_is_v4_v5())
> >   ret = alloc_remap();
> >   else if (gfp & GFP_ATOMIC)
> >   ret = alloc_from_pool();
> >   else
> >   ret = alloc_from_contiguous();
> > 
> > This also allows a natural conversion to dma_map_ops when we get there.
> 
> Ok. Is it ok to enable CMA permanently for ARMv6+? If CMA is left conditional
> the dma pool code will be much more complicated, because it will need to 
> support
> both CMA and non-CMA cases.

I think that is ok, yes.

Arnd
--
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/9] ARM: DMA: steal memory for DMA coherent mappings

[Arnd Bergmann]

On Sunday 14 August 2011, Russell King - ARM Linux wrote:
> On Fri, Aug 12, 2011 at 02:53:05PM +0200, Arnd Bergmann wrote:
> > 
> > I thought that our discussion ended with the plan to use this only
> > for ARMv6+ (which has a problem with double mapping) but not on ARMv5
> > and below (which don't have this problem but might need dmabounce).
> 
> I thought we'd decided to have a pool of available CMA memory on ARMv6K
> to satisfy atomic allocations, which can grow and shrink in size, rather
> than setting aside a fixed amount of contiguous system memory.

Hmm, I don't remember the point about dynamically sizing the pool for
ARMv6K, but that can well be an oversight on my part.  I do remember the
part about taking that memory pool from the CMA region as you say.

> ARMv6 and ARMv7+ could use CMA directly, and <= ARMv5 can use the existing
> allocation method.
> 
> Has something changed?

Nothing has changed regarding <=ARMv5. There was a small side discussion
about ARMv6 and ARMv7+ based on the idea that they can either use CMA
directly (doing TLB flushes for every allocation) or they could use the
same method as ARMv6K by setting aside a pool of pages for atomic
allocation. The first approach would consume less memory because it
requires no special pool, the second approach would be simpler because
it unifies the ARMv6K and ARMv6/ARMv7+ cases and also would be slightly
more efficient for atomic allocations because it avoids the expensive
TLB flush.

I didn't have a strong opinion either way, so IIRC Marek said he'd try
out both approaches and then send out the one that looked better, leaning
towards the second for simplicity of having fewer compile-time options.

Arnd
--
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/9] ARM: DMA: steal memory for DMA coherent mappings

[Russell King - ARM Linux]

On Tue, Aug 16, 2011 at 03:28:48PM +0200, Arnd Bergmann wrote:
> On Sunday 14 August 2011, Russell King - ARM Linux wrote:
> > On Fri, Aug 12, 2011 at 02:53:05PM +0200, Arnd Bergmann wrote:
> > > 
> > > I thought that our discussion ended with the plan to use this only
> > > for ARMv6+ (which has a problem with double mapping) but not on ARMv5
> > > and below (which don't have this problem but might need dmabounce).
> > 
> > I thought we'd decided to have a pool of available CMA memory on ARMv6K
> > to satisfy atomic allocations, which can grow and shrink in size, rather
> > than setting aside a fixed amount of contiguous system memory.
> 
> Hmm, I don't remember the point about dynamically sizing the pool for
> ARMv6K, but that can well be an oversight on my part.  I do remember the
> part about taking that memory pool from the CMA region as you say.

If you're setting aside a pool of pages, then you have to dynamically
size it.  I did mention during our discussion about this.

The problem is that a pool of fixed size is two fold: you need it to be
sufficiently large that it can satisfy all allocations which come along
in atomic context.  Yet, we don't want the pool to be too large because
then it prevents the memory being used for other purposes.

Basically, the total number of pages in the pool can be a fixed size,
but as they are depleted through allocation, they need to be
re-populated from CMA to re-build the reserve for future atomic
allocations.  If the pool becomes larger via frees, then obviously
we need to give pages back.
--
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] DVB: increment minor version after addition of SYS_TURBO

[Andreas Oberritter]

Signed-off-by: Andreas Oberritter 
---
Depends on https://patchwork.kernel.org/patch/1045472/

 include/linux/dvb/version.h |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/include/linux/dvb/version.h b/include/linux/dvb/version.h
index 1421cc8..66594b1 100644
--- a/include/linux/dvb/version.h
+++ b/include/linux/dvb/version.h
@@ -24,6 +24,6 @@
 #define _DVBVERSION_H_
 
 #define DVB_API_VERSION 5
-#define DVB_API_VERSION_MINOR 3
+#define DVB_API_VERSION_MINOR 4
 
 #endif /*_DVBVERSION_H_*/
-- 
1.7.2.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] DVB: dvb_frontend: remove static assignments from dtv_property_cache_sync()

[Andreas Oberritter]

- Move all static assignments to a new function
  dtv_property_cache_init().
- Call dtv_property_cache_init() from FE_SET_FRONTEND, but not from
  dtv_property_process_get().
- This fixes a problem where 2G delivery system parameters would get
  overwritten with invalid values, leading to partially incorrect
  results when calling FE_GET_PROPERTY.

Signed-off-by: Andreas Oberritter 
---
 drivers/media/dvb/dvb-core/dvb_frontend.c |   29 -
 1 files changed, 24 insertions(+), 5 deletions(-)

diff --git a/drivers/media/dvb/dvb-core/dvb_frontend.c 
b/drivers/media/dvb/dvb-core/dvb_frontend.c
index d218fe2..a716627 100644
--- a/drivers/media/dvb/dvb-core/dvb_frontend.c
+++ b/drivers/media/dvb/dvb-core/dvb_frontend.c
@@ -1019,6 +1019,29 @@ static int 
is_legacy_delivery_system(fe_delivery_system_t s)
return 0;
 }
 
+/* Initialize the cache with some default values derived from the
+ * legacy frontend_info structure.
+ */
+static void dtv_property_cache_init(struct dvb_frontend *fe,
+   struct dtv_frontend_properties *c)
+{
+   switch (fe->ops.info.type) {
+   case FE_QPSK:
+   c->modulation = QPSK;   /* implied for DVB-S in legacy API */
+   c->rolloff = ROLLOFF_35;/* implied for DVB-S */
+   c->delivery_system = SYS_DVBS;
+   break;
+   case FE_QAM:
+   c->delivery_system = SYS_DVBC_ANNEX_AC;
+   break;
+   case FE_OFDM:
+   c->delivery_system = SYS_DVBT;
+   break;
+   case FE_ATSC:
+   break;
+   }
+}
+
 /* Synchronise the legacy tuning parameters into the cache, so that demodulator
  * drivers can use a single set_frontend tuning function, regardless of whether
  * it's being used for the legacy or new API, reducing code and complexity.
@@ -1032,17 +1055,13 @@ static void dtv_property_cache_sync(struct dvb_frontend 
*fe,
 
switch (fe->ops.info.type) {
case FE_QPSK:
-   c->modulation = QPSK;   /* implied for DVB-S in legacy API */
-   c->rolloff = ROLLOFF_35;/* implied for DVB-S */
c->symbol_rate = p->u.qpsk.symbol_rate;
c->fec_inner = p->u.qpsk.fec_inner;
-   c->delivery_system = SYS_DVBS;
break;
case FE_QAM:
c->symbol_rate = p->u.qam.symbol_rate;
c->fec_inner = p->u.qam.fec_inner;
c->modulation = p->u.qam.modulation;
-   c->delivery_system = SYS_DVBC_ANNEX_AC;
break;
case FE_OFDM:
if (p->u.ofdm.bandwidth == BANDWIDTH_6_MHZ)
@@ -1060,7 +1079,6 @@ static void dtv_property_cache_sync(struct dvb_frontend 
*fe,
c->transmission_mode = p->u.ofdm.transmission_mode;
c->guard_interval = p->u.ofdm.guard_interval;
c->hierarchy = p->u.ofdm.hierarchy_information;
-   c->delivery_system = SYS_DVBT;
break;
case FE_ATSC:
c->modulation = p->u.vsb.modulation;
@@ -1821,6 +1839,7 @@ static int dvb_frontend_ioctl_legacy(struct file *file,
 
memcpy (&fepriv->parameters_in, parg,
sizeof (struct dvb_frontend_parameters));
+   dtv_property_cache_init(fe, c);
dtv_property_cache_sync(fe, c, &fepriv->parameters_in);
}
 
-- 
1.7.2.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 7/9] ARM: DMA: steal memory for DMA coherent mappings

[Arnd Bergmann]

On Tuesday 16 August 2011, Russell King - ARM Linux wrote:
> On Tue, Aug 16, 2011 at 03:28:48PM +0200, Arnd Bergmann wrote:
> > Hmm, I don't remember the point about dynamically sizing the pool for
> > ARMv6K, but that can well be an oversight on my part.  I do remember the
> > part about taking that memory pool from the CMA region as you say.
> 
> If you're setting aside a pool of pages, then you have to dynamically
> size it.  I did mention during our discussion about this.
> 
> The problem is that a pool of fixed size is two fold: you need it to be
> sufficiently large that it can satisfy all allocations which come along
> in atomic context.  Yet, we don't want the pool to be too large because
> then it prevents the memory being used for other purposes.
> 
> Basically, the total number of pages in the pool can be a fixed size,
> but as they are depleted through allocation, they need to be
> re-populated from CMA to re-build the reserve for future atomic
> allocations.  If the pool becomes larger via frees, then obviously
> we need to give pages back.

Ok, thanks for the reminder. I must have completely missed this part
of the discussion.

When I briefly considered this problem, my own conclusion was that
the number of atomic DMA allocations would always be very low
because they tend to be short-lived (e.g. incoming network packets),
so we could ignore this problem and just use a smaller reservation
size. While this seems to be true in general (see "git grep -w -A3 
dma_alloc_coherent | grep ATOMIC"), there is one very significant
case that we cannot ignore, which is pci_alloc_consistent.

This function is still called by hundreds of PCI drivers and always
does dma_alloc_coherent(..., GFP_ATOMIC), even for long-lived
allocations and those that are too large to be ignored.

So at least for the case where we have PCI devices, I agree that
we need to have the dynamic pool.

Arnd
--
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: [GIT PATCHES FOR 3.1] s5p-fimc and noon010pc30 driver updates

[Mauro Carvalho Chehab]

Em 16-08-2011 01:59, Laurent Pinchart escreveu:
> Hi Mauro,
> 
> On Tuesday 16 August 2011 02:21:09 Mauro Carvalho Chehab wrote:
>> Em 15-08-2011 05:45, Laurent Pinchart escreveu:
 After having it there properly working and tested independently, we may
 consider patches removing V4L2 interfaces that were obsoleted in favor
 of using the libv4l implementation, of course using the Kernel way of
 deprecating interfaces. But doing it before having it, doesn't make any
 sense.
>>>
>>> Once again we're not trying to remove controls, but expose them
>>> differently.
>>
>> See the comments at the patch series, starting from the patches that
>> removes support for S_INPUT. I'm aware that the controls will be exposed
>> by both MC and V4L2 API, althrough having ways to expose/hide controls via
>> V4L2 API makes patch review a way more complicated than it used to be
>> before the MC patches.
> 
> The MC API doesn't expose controls. Controls are still exposed by the V4L2 
> API 
> only, but V4L2 can then expose them on subdev nodes in addition to video 
> nodes.

To be clear, when I'm talking about MC, I'm meaning also the subdev nodes API,
as a pure V4L2 api application doesn't know anything about them.

Regards,
Mauro
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [GIT PATCHES FOR 3.1] s5p-fimc and noon010pc30 driver updates

[Mauro Carvalho Chehab]

Em 16-08-2011 01:57, Laurent Pinchart escreveu:
> Hi Mauro,
 
>>> My point is that the ISP driver developer can't know in advance which
>>> sensor will be used systems that don't exist yet.
>>
>> As far as such hardware is projected, someone will know. It is a simple
>> trivial patch to associate a new hardware with a hardware profile at the
>> platform data.
> 
> Platform data must contain hardware descriptions only, not policies. This is 
> even clearer now that ARM is moving away from board code to the Device Tree.

Again, a cell phone with one frontal camera and one hear camera has two
sensor inputs only. This is not a "policy". It is a hardware constraint.
The driver should allow setting the pipeline for both sensors via S_INPUT,
otherwise a V4L2 only userspace application won't work.

It is as simple as that.

>> Also, on most cases, probing a sensor is as trivial as reading a sensor
>> ID during device probe. This applies, for example, for all Omnivision
>> sensors.
>>
>> We do things like that all the times for PC world, as nobody knows what
>> webcam someone would plug on his PC.
> 
> Sorry, but that's not related. You simply can't decide in an embedded ISP 
> driver how to deal with sensor controls, as the system will be used in a too 
> wide variety of applications and hardware configurations. All controls need 
> to 
> be exposed, period.

We're not talking about controls. We're talking about providing the needed
V4L2 support to allow an userspace application to access the hardware
sensor.

 I never saw an embedded hardware that allows physically changing the
 sensor.
>>>
>>> Beagleboard + pluggable sensor board.
>>
>> Development systems like beagleboard, pandaboard, Exynos SMDK, etc, aren't
>> embeeded hardware. They're development kits.
> 
> People create end-user products based on those kits. That make them first-
> class embedded hardware like any other.

No doubt they should be supported, but it doesn't make sense to create tons
of input pipelines to be used for S_INPUT for each different type of possible
sensor. Somehow, userspace needs to tell what's the sensor that he attached
to the hardware, or the driver should suport auto-detecting it.

In other words, I see 2 options for that:
1) add hardware auto-detection at the sensor logic. At driver probe,
try to probe all sensors, if it is a hardware development kit;
2) add one new parameter at the driver: "sensors". If the hardware
is one of those kits, this parameter will allow the developer to specify
the used sensors. It is the same logic as we do with userspace TV and
grabber cards without eeprom or any other way to auto-detect the hardware.

>> I don't mind if, for those kits the developer that is playing with it has to
>> pass a mode parameter and/or run some open harware-aware small application
>> that makes the driver to select the sensor type he is using, but, if the
>> hardware is, instead, a N9 or a Galaxy Tab (or whatever embedded hardware),
>> the driver should expose just the sensors that exists on such hardware. It
>> shouldn't be ever allowed to change it on userspace, using whatever API on
>> those hardware.
> 
> Who talked about changing sensors from userspace on those systems ? Platform 
> data (regardless of whether it comes from board code, device tree, or 
> something else) will contain a hardware description, and the kernel will 
> create the right devices and load the right drivers. The issue we're 
> discussing is how to expose controls for those devices to userspace, and that 
> needs to be done through subdev nodes.

The issue that is under discussion is the removal of S_INPUT from the samsung 
driver, and the comments at the patches that talks about removing V4L2 API
support in favor of using a MC-only API for some fundamental things.

For example, with a patch like this one, only one sensor will be supported
without the MC API (either the front or back sensor on a multi-sensor camera):

http://git.infradead.org/users/kmpark/linux-2.6-samsung/commit/47751733a322a241927f9238b8ab1441389c9c41

Look at the comment on this patch also:

http://git.infradead.org/users/kmpark/linux-2.6-samsung/commit/c6fb462c38be60a45d16a29a9e56c886ee0aa08c

What is called "API compatibility mode" is not clear, but it transmitted
me that the idea is to expose the controls only via subnodes.

Those are the rationale for those discussions: V4L2 API is not being deprecated
in favor of MC API, e. g. controls shouldn't be hidden from the V4L2 API without
a good reason.

> Even if you did, fine image quality tuning requires accessing pretty
> much all controls individually anyway.

 The same is also true for non-embedded hardware. The only situation
 where V4L2 API is not enough is when there are two controls of the same
 type active. For example, 2 active volume controls, one at the audio
 demod, and another at the bridge. There may have some cases where you
 can do the s

Re: [GIT PATCHES FOR 3.1] s5p-fimc and noon010pc30 driver updates

[Laurent Pinchart]

Hi Mauro,

On Tuesday 16 August 2011 17:30:47 Mauro Carvalho Chehab wrote:
> Em 16-08-2011 01:57, Laurent Pinchart escreveu:
> >>> My point is that the ISP driver developer can't know in advance which
> >>> sensor will be used systems that don't exist yet.
> >> 
> >> As far as such hardware is projected, someone will know. It is a simple
> >> trivial patch to associate a new hardware with a hardware profile at the
> >> platform data.
> > 
> > Platform data must contain hardware descriptions only, not policies. This
> > is even clearer now that ARM is moving away from board code to the
> > Device Tree.
> 
> Again, a cell phone with one frontal camera and one hear camera has two
> sensor inputs only. This is not a "policy". It is a hardware constraint.
> The driver should allow setting the pipeline for both sensors via S_INPUT,
> otherwise a V4L2 only userspace application won't work.
> 
> It is as simple as that.

When capturing from the main sensor on the OMAP3 ISP you need to capture raw 
data to memory on a video node, feed it back to the hardware through another 
video node, and finally capture it on a third video node. A V4L2-only 
userspace application won't work. That's how the hardware is, we can't do much 
about that.

> >> Also, on most cases, probing a sensor is as trivial as reading a sensor
> >> ID during device probe. This applies, for example, for all Omnivision
> >> sensors.
> >> 
> >> We do things like that all the times for PC world, as nobody knows what
> >> webcam someone would plug on his PC.
> > 
> > Sorry, but that's not related. You simply can't decide in an embedded ISP
> > driver how to deal with sensor controls, as the system will be used in a
> > too wide variety of applications and hardware configurations. All
> > controls need to be exposed, period.
> 
> We're not talking about controls. We're talking about providing the needed
> V4L2 support to allow an userspace application to access the hardware
> sensor.

OK, so we're discussing S_INPUT. Let's discuss controls later :-)

>  I never saw an embedded hardware that allows physically changing the
>  sensor.
> >>> 
> >>> Beagleboard + pluggable sensor board.
> >> 
> >> Development systems like beagleboard, pandaboard, Exynos SMDK, etc,
> >> aren't embeeded hardware. They're development kits.
> > 
> > People create end-user products based on those kits. That make them
> > first- class embedded hardware like any other.
> 
> No doubt they should be supported, but it doesn't make sense to create tons
> of input pipelines to be used for S_INPUT for each different type of
> possible sensor. Somehow, userspace needs to tell what's the sensor that
> he attached to the hardware, or the driver should suport auto-detecting
> it.

We're not creating tons of input pipelines. Look at 
http://www.ideasonboard.org/media/omap3isp.ps , every video node (in yellow) 
has its purpose.

> In other words, I see 2 options for that:
>   1) add hardware auto-detection at the sensor logic. At driver probe,
> try to probe all sensors, if it is a hardware development kit;

We've worked quite hard to remove I2C device probing from the kernel, let's 
not add it back.

>   2) add one new parameter at the driver: "sensors". If the hardware
> is one of those kits, this parameter will allow the developer to specify
> the used sensors. It is the same logic as we do with userspace TV and
> grabber cards without eeprom or any other way to auto-detect the hardware.

This will likely be done through the Device Tree.

> >> I don't mind if, for those kits the developer that is playing with it
> >> has to pass a mode parameter and/or run some open harware-aware small
> >> application that makes the driver to select the sensor type he is
> >> using, but, if the hardware is, instead, a N9 or a Galaxy Tab (or
> >> whatever embedded hardware), the driver should expose just the sensors
> >> that exists on such hardware. It shouldn't be ever allowed to change it
> >> on userspace, using whatever API on those hardware.
> > 
> > Who talked about changing sensors from userspace on those systems ?
> > Platform data (regardless of whether it comes from board code, device
> > tree, or something else) will contain a hardware description, and the
> > kernel will create the right devices and load the right drivers. The
> > issue we're discussing is how to expose controls for those devices to
> > userspace, and that needs to be done through subdev nodes.
> 
> The issue that is under discussion is the removal of S_INPUT from the
> samsung driver, and the comments at the patches that talks about removing
> V4L2 API support in favor of using a MC-only API for some fundamental
> things.
> 
> For example, with a patch like this one, only one sensor will be supported
> without the MC API (either the front or back sensor on a multi-sensor
> camera):
> http://git.infradead.org/users/kmpark/linux-2.6-samsung/commit/47751733a32
> 2a241927f9238b8ab1441389c9c41
> 
> Look at the comme

Re: [mythtv-users] Anyone tested the DVB-T2 dual tuner TBS6280?

[Jarod Wilson]

On Aug 14, 2011, at 11:50 AM, Harald Gustafsson wrote:

> Thanks for sharing your experience.
> 
> On Sat, Aug 13, 2011 at 11:08 AM, Lawrence Rust  wrote:
>> The stock v4l sources supplied are old (from around 2.6.35) and don't
>> contain many current fixes.  This isn't a problem per-se unless you
>> intend to use the card with another v4l card.  In this case your brand
>> new, bug fixed drivers are replaced by TBS's version which may or, as in
>> my case, may not work.
> I have 2 other older cards that I intend to use it with, but currently
> I'm using Ubuntu 10.04 LTS which have a 2.6.32 kernel, so this would
> not be a problem, but later when I upgrade to 12.04 LTS and a newer
> kernel this will be problematic. Since I can't trust that TBS will
> deliver newer drivers.
> 
>> I repeatedly mailed TBS support at supp...@tbsdtv.com to ask how I could
>> only install the 6981 driver but never got an answer.  In desperation I
>> setup a git tree of 2.6.35 and merged it with the TBS drivers in order
>> to separate their changes.  Finally after many hours I have a set of
>> patches that I can apply to 2.6.39 that produce a working driver.
> Is it possible to mix modules based on different versions of v4l? To
> me that looks like it will work as long as the core infrastructure is
> the same, but as soon as some common data structure that is used by
> the obj files is changed it will break and you might not notice
> directly. Just as you say with the IR changes, but also more subtle
> changes by adding/removing elements in structures.
> 
>> Be warned that if you run a 2.6.38 or later kernel then the IR RC won't
>> work because of significant changes to the RC architecture that TBS
>> don't like (see http://www.tbsdtv.com/forum/viewtopic.php?f=22&t=929 and
>> http://www.tbsdtv.com/forum/viewtopic.php?f=22&t=110&start=90#p2693 )
> 
> In the links you refer to the driver author (at least he seems to be
> the author) states that he has not upgraded to the latest IR code due
> to compatibility issues between the CX23885 and IR.

Someone please inform TBS that it would nice if they'd actually report
issues upstream. Nobody from TBS every said boo about their issues,
which, I'm 99% certain, have *absolutely* nothing to do with supposedly
rewriting ir-core to rc-core. (It was a transition to a new name of the
same code). This probably fixed all their issues:

http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=d7515b8866b60c9526d2d7af37ebcd16c3c5ed97

Similarly, just booting with pci=nomsi on an unpatched kernel should
achieve the same effect. Sigh.

-- 
Jarod Wilson
ja...@wilsonet.com



--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/6 v4] V4L: add two new ioctl()s for multi-size videobuffer management

[Pawel Osciak]

Hi Guennadi,

On Tue, Aug 16, 2011 at 06:13, Guennadi Liakhovetski
 wrote:
> On Mon, 15 Aug 2011, Guennadi Liakhovetski wrote:
>
>> On Mon, 15 Aug 2011, Hans Verkuil wrote:
>>
>> > On Monday, August 15, 2011 13:28:23 Guennadi Liakhovetski wrote:
>> > > Hi Hans
>> > >
>> > > On Mon, 8 Aug 2011, Hans Verkuil wrote:
>
> [snip]
>
>> > > > but I've changed my mind: I think
>> > > > this should use a struct v4l2_format after all.
>>
>> While switching back, I have to change the struct vb2_ops::queue_setup()
>> operation to take a struct v4l2_create_buffers pointer. An earlier version
>> of this patch just added one more parameter to .queue_setup(), which is
>> easier - changes to videobuf2-core.c are smaller, but it is then
>> redundant. We could use the create pointer for both input and output. The
>> video plane configuration in frame format is the same as what is
>> calculated in .queue_setup(), IIUC. So, we could just let the driver fill
>> that one in. This would require then the videobuf2-core.c to parse struct
>> v4l2_format to decide which union member we need, depending on the buffer
>> type. Do we want this or shall drivers duplicate plane sizes in separate
>> .queue_setup() parameters?
>
> Let me explain my question a bit. The current .queue_setup() method is
>
>int (*queue_setup)(struct vb2_queue *q, unsigned int *num_buffers,
>   unsigned int *num_planes, unsigned int sizes[],
>   void *alloc_ctxs[]);
>
> To support multiple-size buffers we also have to pass a pointer to struct
> v4l2_create_buffers to this function now. We can either do it like this:
>
>int (*queue_setup)(struct vb2_queue *q,
>   struct v4l2_create_buffers *create,
>   unsigned int *num_buffers,
>   unsigned int *num_planes, unsigned int sizes[],
>   void *alloc_ctxs[]);
>
> and let all drivers fill in respective fields in *create, e.g., either do
>
>create->format.fmt.pix_mp.plane_fmt[i].sizeimage = ...;
>create->format.fmt.pix_mp.num_planes = ...;
>
> and also duplicate it in method parameters
>
>*num_planes = create->format.fmt.pix_mp.num_planes;
>sizes[i] = create->format.fmt.pix_mp.plane_fmt[i].sizeimage;
>
> or with
>
>create->format.fmt.pix.sizeimage = ...;
>
> for single-plane. Alternatively we make the prototype
>
>int (*queue_setup)(struct vb2_queue *q,
>   struct v4l2_create_buffers *create,
>   unsigned int *num_buffers,
>   void *alloc_ctxs[]);
>
> then drivers only fill in *create, and the videobuf2-core will have to
> check create->format.type to decide, which of create->format.fmt.* is
> relevant and extract plane sizes from there.


Could we try exploring an alternative idea?
The queue_setup callback was added to decouple formats from vb2 (and
add some asynchronousness). But now we are doing the opposite, adding
format awareness to vb2. Does vb2 really need to know about formats? I
really believe it doesn't. It only needs sizes and counts. Also, we
are actually complicating things I think. The proposal, IIUC, would
look like this:

driver_queue_setup(..., create, num_buffers, [num_planes], ...)
{
if (create != NULL && create->format != NULL) {
/* use create->fmt to fill sizes */
} else if (create != NULL) { /* this assumes we have both format or sizes */
/* use create->sizes to fill sizes */
} else {
/* use currently selected format to fill sizes */
}
}

driver_s_fmt(format)
{
/* ... */
driver_fill_format(&create->fmt);
/* ... */
}

driver_create_bufs(create)
{
vb2_create_bufs(create);
}

vb2_create_bufs(create)
{
driver_queue_setup(..., create, ...);
vb2_fill_format(&create->fmt); /* note different from
driver_fill_format(), but both needed */
}

vb2_reqbufs(reqbufs)
{
   driver_queue_setup(..., NULL, ...);
}

The queue_setup not only becomes unnecessarily complicated, but I'm
starting to question the convenience of it. And we are teaching vb2
how to interpret format structs, even though vb2 only needs sizes, and
even though the driver has to do it anyway and knows better how.

As for the idea to fill fmt in vb2, even if vb2 was to do it in
create_bufs, some code to parse and fill the format fields would need
to be in the driver anyway, because it still has to support s_fmt and
friends. So adding that code to vb2 would duplicate it, and if the
driver wanted to be non-standard in a way it filled the format fields,
we'd not be allowing that.

My suggestion would be to remove queue_setup callback and instead
modify vb2_reqbufs and vb2_create_bufs to accept sizes and number of
buffers. I think it should simplify things both for drivers and vb2,
would keep vb2 format-unaware and save us some round trips between vb2
and driver:

driver_create_bufs(...) /* optional */
{
/* use cr

Re: Afatech AF9013

[Josu Lazkano]

Thanks again, I edit /etc/modprobe.d/options.conf

options dvb_usb_af9015 adapter_nr=4,5
options dvb-usb disable_rc_polling=1
options dvb-usb force_pid_filter_usage=1

I change the signal timeout and tuning timeout and now it works perfect!

I can watch two HD channels, thanks for your help.

I really don't understand what force_pid_filter_usage do on the
module, is there any documentation?

Thanks and best regards.

2011/8/16 Jose Alberto Reguero :
> On Martes, 16 de Agosto de 2011 00:22:05 Josu Lazkano escribió:
>> 2011/8/16 Jose Alberto Reguero :
>> > I have problems with a dual usb tuner. I limit the bandwith using pid
>> > filters and the problem was gone.
>> >
>> > Jose alberto
>> >
>> > On Lunes, 15 de Agosto de 2011 15:34:20 Josu Lazkano escribió:
>> >> Hello, I have a problem with the KWorld USB Dual DVB-T TV Stick (DVB-T
>> >> 399U):
>> >> http://www.linuxtv.org/wiki/index.php/KWorld_USB_Dual_DVB-T_TV_Stick_(DV
>> >> B- T_399U)
>> >>
>> >> I am using it on MythTV with Debian Squeeze (2.6.32). It is a dual
>> >> device, sometimes the second adapter works great, but sometimes has a
>> >> pixeled images. The first adapter always has pixeled images, I don't
>> >> know how to describe the pixeled images, so here is a mobile record:
>> >> http://dl.dropbox.com/u/1541853/kworld.3gp
>> >>
>> >> I have this firmware:
>> >> http://palosaari.fi/linux/v4l-dvb/firmware/af9015/5.1.0.0/dvb-usb-af9015
>> >> .fw
>> >>
>> >> I read on the linuxtv wiki and there are some problems with dual mode,
>> >> there is some links for how to patch the similar driver (Afatech/ITE
>> >> IT9135), but I am not good enough to understand the code.
>> >>
>> >> I check the kernel messages:
>> >>
>> >> Aug 15 13:53:58 htpc kernel: [ 516.285369] af9013: I2C read failed
>> >> reg:d2e6 Aug 15 13:54:29 htpc kernel: [  547.407504] af9013: I2C read
>> >> failed reg:d330 Aug 15 13:54:44 htpc kernel: [  561.902710] af9013: I2C
>> >> read failed reg:d2e6
>> >>
>> >> It looks I2C problem, but I don't know how to debug it deeper.
>> >>
>> >> I don't know if this is important, but I compile the s2-liplianin for
>> >> other devices this way:
>> >>
>> >> apt-get install linux-headers-`uname -r` build-essential
>> >> mkdir /usr/local/src/dvb
>> >> cd /usr/local/src/dvb
>> >> wget http://mercurial.intuxication.org/hg/s2-liplianin/archive/tip.zip
>> >> unzip s2-liplianin-0b7d3cc65161.zip
>> >> cd s2-liplianin-0b7d3cc65161
>> >> make CONFIG_DVB_FIREDTV:=n
>> >> make install
>> >>
>> >> Can you help with this? This hardware is a very cheap and works well
>> >> for HD channels but, I don't know why sometimes has pixeled images.
>> >>
>> >> Thanks for your help, best regards.
>>
>> Thanks Jose Alberto, I search on google for pid filters but I don't
>> find any interesting info.
>>
>> How can I limit bandwidth on dvb?
>>
>> Thanks for your help, I have two dual devices waiting for this fix on my
>> HTPC.
>>
>> Best regards.
>
> If  the driver has pid filters you can enable it with the parameter
> force_pid_filter_usage=1 of dvb-usb.
>
> Jose Alberto
>



-- 
Josu Lazkano
--
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: Added extensive feature set to the OV5642 camera driver

[Laurent Pinchart]

Hi Bastian,

On Tuesday 16 August 2011 14:58:58 Bastian Hecht wrote:
> The driver now supports arbitray resolutions (width up to 2592, height
> up to 720), automatic/manual gain, automatic/manual white balance,
> automatic/manual exposure control, vertical flip, brightness control,
> contrast control and saturation control. Additionally the following
> effects are available now: rotating the hue in the colorspace, gray
> scale image and solarize effect.

That's a big patch, thus quite hard to review. What about splitting it in one 
patch per feature (or group of features, at least separating format 
configuration and controls) ? :-)

-- 
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: [mythtv-users] Anyone tested the DVB-T2 dual tuner TBS6280?

[Andy Walls]

Jarod Wilson  wrote:

>On Aug 14, 2011, at 11:50 AM, Harald Gustafsson wrote:
>
>> Thanks for sharing your experience.
>> 
>> On Sat, Aug 13, 2011 at 11:08 AM, Lawrence Rust
> wrote:
>>> The stock v4l sources supplied are old (from around 2.6.35) and
>don't
>>> contain many current fixes.  This isn't a problem per-se unless you
>>> intend to use the card with another v4l card.  In this case your
>brand
>>> new, bug fixed drivers are replaced by TBS's version which may or,
>as in
>>> my case, may not work.
>> I have 2 other older cards that I intend to use it with, but
>currently
>> I'm using Ubuntu 10.04 LTS which have a 2.6.32 kernel, so this would
>> not be a problem, but later when I upgrade to 12.04 LTS and a newer
>> kernel this will be problematic. Since I can't trust that TBS will
>> deliver newer drivers.
>> 
>>> I repeatedly mailed TBS support at supp...@tbsdtv.com to ask how I
>could
>>> only install the 6981 driver but never got an answer.  In
>desperation I
>>> setup a git tree of 2.6.35 and merged it with the TBS drivers in
>order
>>> to separate their changes.  Finally after many hours I have a set of
>>> patches that I can apply to 2.6.39 that produce a working driver.
>> Is it possible to mix modules based on different versions of v4l? To
>> me that looks like it will work as long as the core infrastructure is
>> the same, but as soon as some common data structure that is used by
>> the obj files is changed it will break and you might not notice
>> directly. Just as you say with the IR changes, but also more subtle
>> changes by adding/removing elements in structures.
>> 
>>> Be warned that if you run a 2.6.38 or later kernel then the IR RC
>won't
>>> work because of significant changes to the RC architecture that TBS
>>> don't like (see http://www.tbsdtv.com/forum/viewtopic.php?f=22&t=929
>and
>>> http://www.tbsdtv.com/forum/viewtopic.php?f=22&t=110&start=90#p2693
>)
>> 
>> In the links you refer to the driver author (at least he seems to be
>> the author) states that he has not upgraded to the latest IR code due
>> to compatibility issues between the CX23885 and IR.
>
>Someone please inform TBS that it would nice if they'd actually report
>issues upstream. Nobody from TBS every said boo about their issues,
>which, I'm 99% certain, have *absolutely* nothing to do with supposedly
>rewriting ir-core to rc-core. (It was a transition to a new name of the
>same code). This probably fixed all their issues:
>
>http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=d7515b8866b60c9526d2d7af37ebcd16c3c5ed97
>
>Similarly, just booting with pci=nomsi on an unpatched kernel should
>achieve the same effect. Sigh.
>
>-- 
>Jarod Wilson
>ja...@wilsonet.com
>
>
>
>--
>To unsubscribe from this list: send the line "unsubscribe linux-media"
>in
>the body of a message to majord...@vger.kernel.org
>More majordomo info at  http://vger.kernel.org/majordomo-info.html

Jarod,

Well that might not solve the problem for genuine CX23885 chips in 
non-Hauppauge designs.  Long before the patch that enabled MSI in the cx23885 
driver, Igor had an unclearable IR interrupt with his TeVii S470 that I could 
never figure out.

(Reliably clearing the interrupt from the I2C connected Mako A/V core on  those 
chips is a real pain without detailed engineering data on the chip and the 
board.)

I've never had a problem with the IR interrupt on CX23888 based boards with MSI 
disabled though. 


Regards,
Andy
--
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: [regression] uvcvideo: BUG at drivers/media/media-entity.c:346 for compaq presario cq56 (laptop) built-in webcam

[Laurent Pinchart]

Hi Jonathan and Daniel,

On Sunday 14 August 2011 18:31:31 Jonathan Nieder wrote:
> Daniel Dickinson wrote[1]:
> > New in 3.0.0:
> > 
> > webcam oopses and then spams syslog.  Didn't happen in .39 so is a
> > regression.
> > 
> > uvcvideo: Found UVC 1.00 device HP Webcam-101 (0bda:58e0)
> > 
> > From syslog:
> > 
> > [  428.117889] Linux video capture interface: v2.00
> > [  428.161164] uvcvideo: Found UVC 1.00 device HP Webcam-101 (0bda:58e0)
> > [  428.167520] [ cut here ]
> > [  428.167562] kernel BUG at [...]/drivers/media/media-entity.c:346!
> > [  428.167605] invalid opcode:  [#1] SMP
> > [  428.167705] CPU 1
> > [  428.167739] Modules linked in: uvcvideo(+) snd_seq_midi joydev
> > videodev media v4l2_compat_ioctl32 snd_rawmidi snd_seq_midi_event
> > snd_seq arc4 snd_timer snd_seq_device ath9k radeon(+) mac80211
> > ath9k_common ath9k_hw ttm ath drm_kms_helper drm snd hp_wmi cfg80211
> > sparse_keymap sp5100_tco edac_core soundcore rfkill i2c_algo_bit evdev
> > snd_page_alloc edac_mce_amd psmouse k10temp shpchp i2c_piix4 serio_raw
> > ac battery video i2c_core power_supply pci_hotplug pcspkr wmi button
> > processor ext4 mbcache jbd2 crc16 sha256_generic cryptd aes_x86_64
> > aes_generic cbc dm_crypt dm_mod raid10 raid456 async_raid6_recov
> > async_pq raid6_pq async_xor xor async_memcpy async_tx raid1 raid0
> > multipath linear md_mod usbhid hid sg sr_mod sd_mod cdrom crc_t10dif
> > ohci_hcd thermal thermal_sys ahci libahci r8169 ehci_hcd mii libata
> > scsi_mod usbcore [last unloaded: scsi_wait_scan] [  428.170836]
> > [  428.170872] Pid: 659, comm: modprobe Not tainted 3.0.0-1-amd64 #1
> > Hewlett-Packard Presario CQ56 Notebook PC/1604 [  428.171010] RIP:
> > 0010:[]  []
> > media_entity_create_link+0x2c/0xd4 [media] [  428.171088] RSP:
> > 0018:8801093c5c28  EFLAGS: 00010246
> > [  428.171125] RAX: 88010861f800 RBX: 88010861f870 RCX:
> >  [  428.171163] RDX: 880108603870 RSI:
> >  RDI: 88010861f870 [  428.171201] RBP:
> > 880108603870 R08: 0003 R09: 81756440 [ 
> > 428.171238] R10: 00012800 R11: 00015670 R12:
> >  [  428.171276] R13: 880108603870 R14:
> >  R15:  [  428.171315] FS: 
> > 7f6831cb3700() GS:88010fc8() knlGS:
> > [  428.171355] CS:  0010 DS:  ES:  CR0: 8005003b [ 
> > 428.171360] CR2: 01858008 CR3: 000109eaa000 CR4:
> > 06e0 [  428.171360] DR0:  DR1:
> >  DR2:  [  428.171360] DR3:
> >  DR6: 0ff0 DR7: 0400 [ 
> > 428.171360] Process modprobe (pid: 659, threadinfo 8801093c4000,
> > task 880107a70300) [  428.171360] Stack:
> > [  428.171360]  0002 0002 
> > 880108603800 [  428.171360]  88010a0eac40 
> > 880108603870 88010a0eac58 [  428.171360]  
> > a04fefb1 8801099c1408 88010a0eac48 [  428.171360] Call
> > Trace:
> > [  428.171360]  [] ?
> > uvc_mc_register_entities+0x160/0x1eb [uvcvideo] [  428.171360] 
> > [] ? uvc_probe+0x1ee7/0x1f18 [uvcvideo] [  428.171360]
> >  [] ? usb_probe_interface+0xfc/0x16f [usbcore] [ 
> > 428.171360]  [] ? driver_probe_device+0xb2/0x142 [ 
> > 428.171360]  [] ? __driver_attach+0x4f/0x6f [ 
> > 428.171360]  [] ? driver_probe_device+0x142/0x142 [ 
> > 428.171360]  [] ? bus_for_each_dev+0x47/0x72 [ 
> > 428.171360]  [] ? bus_add_driver+0xa2/0x1f2 [ 
> > 428.171360]  [] ? driver_register+0x8d/0xf5 [ 
> > 428.171360]  [] ? usb_register_driver+0x80/0x128
> > [usbcore] [  428.171360]  [] ? 0xa0507fff
> > [  428.171360]  [] ? uvc_init+0x1b/0x1000 [uvcvideo]
> > [  428.171360]  [] ? do_one_initcall+0x78/0x132
> > [  428.171360]  [] ? sys_init_module+0xbc/0x245
> > [  428.171360]  [] ? system_call_fastpath+0x16/0x1b
> > [  428.171360] Code: 57 41 89 cf 41 56 41 89 f6 41 55 41 54 55 48 89 d5
> > 53 48 89 fb 48 83 ec 18 48 85 d2 74 05 48 85 ff 75 02 0f 0b 66 3b 77 3c
> > 72 02 <0f> 0b 66 3b 4a 3c 72 02 0f 0b 44 89 44 24 08 41 bd f4 ff ff ff [
> >  428.171360] RIP  []
> > media_entity_create_link+0x2c/0xd4 [media] [  428.171360]  RSP
> > 
> > [  428.175002] ---[ end trace 3db524e10ad1aec0 ]---
> > 
> > and then:
> > 
> > udevd[420]: timeout: killing 'usb_id --export
> > /devices/pci:00/:00:12.2/usb1/1-3/1-3:1.0/video4linux/video0'
> > [712]
> 
> Known problem?  Any hints for tracking it down?

No it's not a know issue. I've answered (or at least tried to answer) the 
original bug report. Daniel, could you please send me the output of

lsusb -v -d 0bda:58e0

(running as root if possible) ?

-- 
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

[cron job] v4l-dvb daily build: WARNINGS

[Hans Verkuil]

This message is generated daily by a cron job that builds v4l-dvb for
the kernels and architectures in the list below.

Results of the daily build of v4l-dvb:

date:Tue Aug 16 19:00:53 CEST 2011
git hash:9bed77ee2fb46b74782d0d9d14b92e9d07f3df6e
gcc version:  i686-linux-gcc (GCC) 4.6.1
host hardware:x86_64
host os:  2.6.32.5

linux-git-armv5: WARNINGS
linux-git-armv5-davinci: WARNINGS
linux-git-armv5-ixp: WARNINGS
linux-git-armv5-omap2: WARNINGS
linux-git-i686: WARNINGS
linux-git-m32r: OK
linux-git-mips: WARNINGS
linux-git-powerpc64: WARNINGS
linux-git-x86_64: WARNINGS
linux-2.6.31.12-i686: WARNINGS
linux-2.6.32.6-i686: WARNINGS
linux-2.6.33-i686: WARNINGS
linux-2.6.34-i686: WARNINGS
linux-2.6.35.3-i686: WARNINGS
linux-2.6.36-i686: WARNINGS
linux-2.6.37-i686: WARNINGS
linux-2.6.38.2-i686: WARNINGS
linux-2.6.39.1-i686: WARNINGS
linux-3.0-i686: WARNINGS
linux-3.1-rc1-i686: WARNINGS
linux-2.6.31.12-x86_64: WARNINGS
linux-2.6.32.6-x86_64: WARNINGS
linux-2.6.33-x86_64: WARNINGS
linux-2.6.34-x86_64: WARNINGS
linux-2.6.35.3-x86_64: WARNINGS
linux-2.6.36-x86_64: WARNINGS
linux-2.6.37-x86_64: WARNINGS
linux-2.6.38.2-x86_64: WARNINGS
linux-2.6.39.1-x86_64: WARNINGS
linux-3.0-x86_64: WARNINGS
linux-3.1-rc1-x86_64: WARNINGS
spec-git: WARNINGS
sparse: 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 V4L-DVB specification 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: Afatech AF9013

[Jose Alberto Reguero]

On Martes, 16 de Agosto de 2011 18:37:49 Josu Lazkano escribió:
> Thanks again, I edit /etc/modprobe.d/options.conf
> 
> options dvb_usb_af9015 adapter_nr=4,5
> options dvb-usb disable_rc_polling=1
> options dvb-usb force_pid_filter_usage=1
> 
> I change the signal timeout and tuning timeout and now it works perfect!
> 
> I can watch two HD channels, thanks for your help.
> 
> I really don't understand what force_pid_filter_usage do on the
> module, is there any documentation?
> 
> Thanks and best regards.
> 

For usb devices with usb 2.0 when tunned to a channel there is enought usb 
bandwith to deliver the whole transponder. With pid filters they only deliver 
the pids needed for the channel. The only limit is that the pid filters is 
limited normaly to 32 pids.

Jose Alberto

> 2011/8/16 Jose Alberto Reguero :
> > On Martes, 16 de Agosto de 2011 00:22:05 Josu Lazkano escribió:
> >> 2011/8/16 Jose Alberto Reguero :
> >> > I have problems with a dual usb tuner. I limit the bandwith using pid
> >> > filters and the problem was gone.
> >> > 
> >> > Jose alberto
> >> > 
> >> > On Lunes, 15 de Agosto de 2011 15:34:20 Josu Lazkano escribió:
> >> >> Hello, I have a problem with the KWorld USB Dual DVB-T TV Stick
> >> >> (DVB-T 399U):
> >> >> http://www.linuxtv.org/wiki/index.php/KWorld_USB_Dual_DVB-T_TV_Stick_
> >> >> (DV B- T_399U)
> >> >> 
> >> >> I am using it on MythTV with Debian Squeeze (2.6.32). It is a dual
> >> >> device, sometimes the second adapter works great, but sometimes has a
> >> >> pixeled images. The first adapter always has pixeled images, I don't
> >> >> know how to describe the pixeled images, so here is a mobile record:
> >> >> http://dl.dropbox.com/u/1541853/kworld.3gp
> >> >> 
> >> >> I have this firmware:
> >> >> http://palosaari.fi/linux/v4l-dvb/firmware/af9015/5.1.0.0/dvb-usb-af9
> >> >> 015 .fw
> >> >> 
> >> >> I read on the linuxtv wiki and there are some problems with dual
> >> >> mode, there is some links for how to patch the similar driver
> >> >> (Afatech/ITE IT9135), but I am not good enough to understand the
> >> >> code.
> >> >> 
> >> >> I check the kernel messages:
> >> >> 
> >> >> Aug 15 13:53:58 htpc kernel: [ 516.285369] af9013: I2C read failed
> >> >> reg:d2e6 Aug 15 13:54:29 htpc kernel: [  547.407504] af9013: I2C read
> >> >> failed reg:d330 Aug 15 13:54:44 htpc kernel: [  561.902710] af9013:
> >> >> I2C read failed reg:d2e6
> >> >> 
> >> >> It looks I2C problem, but I don't know how to debug it deeper.
> >> >> 
> >> >> I don't know if this is important, but I compile the s2-liplianin for
> >> >> other devices this way:
> >> >> 
> >> >> apt-get install linux-headers-`uname -r` build-essential
> >> >> mkdir /usr/local/src/dvb
> >> >> cd /usr/local/src/dvb
> >> >> wget
> >> >> http://mercurial.intuxication.org/hg/s2-liplianin/archive/tip.zip
> >> >> unzip s2-liplianin-0b7d3cc65161.zip
> >> >> cd s2-liplianin-0b7d3cc65161
> >> >> make CONFIG_DVB_FIREDTV:=n
> >> >> make install
> >> >> 
> >> >> Can you help with this? This hardware is a very cheap and works well
> >> >> for HD channels but, I don't know why sometimes has pixeled images.
> >> >> 
> >> >> Thanks for your help, best regards.
> >> 
> >> Thanks Jose Alberto, I search on google for pid filters but I don't
> >> find any interesting info.
> >> 
> >> How can I limit bandwidth on dvb?
> >> 
> >> Thanks for your help, I have two dual devices waiting for this fix on my
> >> HTPC.
> >> 
> >> Best regards.
> > 
> > If  the driver has pid filters you can enable it with the parameter
> > force_pid_filter_usage=1 of dvb-usb.
> > 
> > Jose Alberto
--
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: Afatech AF9013

[Antti Palosaari]

On 08/16/2011 11:27 PM, Jose Alberto Reguero wrote:
>> options dvb-usb force_pid_filter_usage=1
>>
>> I change the signal timeout and tuning timeout and now it works perfect!
>>
>> I can watch two HD channels, thanks for your help.
>>
>> I really don't understand what force_pid_filter_usage do on the
>> module, is there any documentation?
>>
>> Thanks and best regards.
>>
> 
> For usb devices with usb 2.0 when tunned to a channel there is enought usb 
> bandwith to deliver the whole transponder. With pid filters they only deliver 
> the pids needed for the channel. The only limit is that the pid filters is 
> limited normaly to 32 pids.

May I ask how wide DVB-T streams you have? Here in Finland it is about
22 Mbit/sec and I think two such streams should be too much for one USB
bus. I suspect there is some other bug in back of this.

regards
Antti

-- 
http://palosaari.fi/
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [GIT PATCHES FOR 3.1] s5p-fimc and noon010pc30 driver updates

[Sylwester Nawrocki]

Hello,

On 08/16/2011 05:30 PM, Mauro Carvalho Chehab wrote:
> Em 16-08-2011 01:57, Laurent Pinchart escreveu:
>> Hi Mauro,
> 
 My point is that the ISP driver developer can't know in advance which
 sensor will be used systems that don't exist yet.
>>>
>>> As far as such hardware is projected, someone will know. It is a simple
>>> trivial patch to associate a new hardware with a hardware profile at the
>>> platform data.

My question here would be whether we want to have a kernel patch fixing up
the configuration for each H/W case or rather a user space script that will
set up a data processing chain ?

>>
>> Platform data must contain hardware descriptions only, not policies. This is
>> even clearer now that ARM is moving away from board code to the Device Tree.
> 
> Again, a cell phone with one frontal camera and one hear camera has two
> sensor inputs only. This is not a "policy". It is a hardware constraint.

There is a policy because you have to tweak the device configuration for a 
specific
board and sensor. It seems impossible to have fully functional drivers in the 
mainline
with such a simplistic approach.


> The driver should allow setting the pipeline for both sensors via S_INPUT,
> otherwise a V4L2 only userspace application won't work.
> 
> It is as simple as that.
> 
>>> Also, on most cases, probing a sensor is as trivial as reading a sensor
>>> ID during device probe. This applies, for example, for all Omnivision
>>> sensors.
>>>
>>> We do things like that all the times for PC world, as nobody knows what
>>> webcam someone would plug on his PC.
>>
>> Sorry, but that's not related. You simply can't decide in an embedded ISP
>> driver how to deal with sensor controls, as the system will be used in a too
>> wide variety of applications and hardware configurations. All controls need 
>> to
>> be exposed, period.
> 
> We're not talking about controls. We're talking about providing the needed
> V4L2 support to allow an userspace application to access the hardware
> sensor.

Which involves the controls as well.

> 
> I never saw an embedded hardware that allows physically changing the
> sensor.

 Beagleboard + pluggable sensor board.
>>>
>>> Development systems like beagleboard, pandaboard, Exynos SMDK, etc, aren't
>>> embeeded hardware. They're development kits.
>>
>> People create end-user products based on those kits. That make them first-
>> class embedded hardware like any other.
> 
> No doubt they should be supported, but it doesn't make sense to create tons
> of input pipelines to be used for S_INPUT for each different type of possible
> sensor. Somehow, userspace needs to tell what's the sensor that he attached
> to the hardware, or the driver should suport auto-detecting it.
> 
> In other words, I see 2 options for that:
>   1) add hardware auto-detection at the sensor logic. At driver probe,
> try to probe all sensors, if it is a hardware development kit;

Isn't it better to let the application discover what type of sensor
the kernel exposes and apply a pre-defined ISP configuration for it ? 
If I am not mistaken, this is what happens currently in OMAP3 ISP systems.
Should the base parameters for the I2C client registration be taken from
platform_data/the flatted device tree.

>   2) add one new parameter at the driver: "sensors". If the hardware
> is one of those kits, this parameter will allow the developer to specify
> the used sensors. It is the same logic as we do with userspace TV and
> grabber cards without eeprom or any other way to auto-detect the hardware.

Sorry, this does not look sane to me.. What is the driver supposed to do
with such a list of sensors ? Hard code the pipeline configurations for them ?

> 
>>> I don't mind if, for those kits the developer that is playing with it has to
>>> pass a mode parameter and/or run some open harware-aware small application
>>> that makes the driver to select the sensor type he is using, but, if the
>>> hardware is, instead, a N9 or a Galaxy Tab (or whatever embedded hardware),
>>> the driver should expose just the sensors that exists on such hardware. It
>>> shouldn't be ever allowed to change it on userspace, using whatever API on
>>> those hardware.
>>
>> Who talked about changing sensors from userspace on those systems ? Platform
>> data (regardless of whether it comes from board code, device tree, or
>> something else) will contain a hardware description, and the kernel will
>> create the right devices and load the right drivers. The issue we're
>> discussing is how to expose controls for those devices to userspace, and that
>> needs to be done through subdev nodes.
> 
> The issue that is under discussion is the removal of S_INPUT from the samsung
> driver, and the comments at the patches that talks about removing V4L2 API
> support in favor of using a MC-only API for some fundamental things.
> 
> For example, with a patch like this one, only one sensor will be supported
> without the MC API (eithe

Locking problem between em28xx and em28xx-dvb modules - Part 2

[Chris Rankin]

Hi,

I've been looking deeper into the em28xx and em28xx-dvb modules, and I'm 
concerned that there are some races and resource leaks inherent in the current code:


a) Shouldn't em28xx_init_extension() and em28xx_add_into_devlist() be unified 
into a single function? Otherwise, consider someone plugging a DVB adapter into 
a host when the em28xx-dvb module is not yet loaded:


- em28xx_init_dev() adds new device to list.
- em28xx-dvb module registers itself, and initialises every device in the list 
(including our new one).
- em28xx_init_dev() iterates over the list of extensions (including em28xx-dvb) 
with the new device.


At this point, dvb_init() has been called twice for our new device, resulting in 
a leaked struct em28xx_dvb.


b) When em28xx_init_dev() returns something != 0, em28xx_usb_probe() frees the 
struct em28xx and exits without calling usb_put_dev().


c) There are many ways that em28xx_init_dev() can return something != 0, and not 
all of them release the V4L2 device or I2C device.


Am I understanding this code correctly, please? I can obviously extend my patch 
accordingly - it is currently running without any obvious problems, but I only 
have one DVB adapter and none that uses the ALSA extension.


Cheers,
Chris

--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: RFC: Negotiating frame buffer size between sensor subdevs and bridge devices

[Sakari Ailus]

On Thu, Jul 28, 2011 at 07:04:11PM +0200, Sylwester Nawrocki wrote:
> Hello,

Hi Sylwester,

> Trying to capture images in JPEG format with regular "image sensor -> 
> mipi-csi receiver -> host interface" H/W configuration I've found there
> is no standard way to communicate between the sensor subdev and the host
> driver what is exactly a required maximum buffer size to capture a frame.
> 
> For the raw formats there is no issue as the buffer size can be easily
> determined from the pixel format and resolution (or sizeimage set on
> a video node). 
> However compressed data formats are a bit more complicated, the required
> memory buffer size depends on multiple factors, like compression ratio,
> exact file header structure etc.
> 
> Often it is at the sensor driver where all information required to 
> determine size of the allocated memory is present. Bridge/host devices
> just do plain DMA without caring much what is transferred. I know of
> hardware which, for some pixel formats, once data capture is started,
> writes to memory whatever amount of data the sensor is transmitting,
> without any means to interrupt on the host side. So it is critical
> to assure the buffer allocation is done right, according to the sensor
> requirements, to avoid buffer overrun.
> 
> 
> Here is a link to somehow related discussion I could find:
> [1] http://www.mail-archive.com/linux-media@vger.kernel.org/msg27138.html
> 
> 
> In order to let the host drivers query or configure subdevs with required
> frame buffer size one of the following changes could be done at V4L2 API:
> 
> 1. Add a 'sizeimage' field in struct v4l2_mbus_framefmt and make subdev
>  drivers optionally set/adjust it when setting or getting the format with
>  set_fmt/get_fmt pad level ops (and s/g_mbus_fmt ?)
>  There could be two situations:
>  - effective required frame buffer size is specified by the sensor and the
>host driver relies on that value when allocating a buffer;
>  - the host driver forces some arbitrary buffer size and the sensor performs
>any required action to limit transmitted amount of data to that amount
>of data;
> Both cases could be covered similarly as it's done with VIDIOC_S_FMT. 
> 
> Introducing 'sizeimage' field is making the media bus format struct looking
> more similar to struct v4l2_pix_format and not quite in line with media bus
> format meaning, i.e. describing data on a physical bus, not in the memory.
> The other option I can think of is to create separate subdev video ops.
> 2. Add new s/g_sizeimage subdev video operations 
> 
> The best would be to make this an optional callback, not sure if it makes 
> sense
> though. It has an advantage of not polluting the user space API. Although 
> 'sizeimage' in user space might be useful for some purposes I rather tried to
> focus on "in-kernel" calls.

I prefer this second approach over the first once since the maxiumu size of
the image in bytes really isn't a property of the bus.

How about a regular V4L2 control? You would also have minimum and maximum
values, I'm not quite sure whather this is a plus, though. :)

Btw. how does v4l2_mbus_framefmt suit for compressed formats in general?

-- 
Sakari Ailus
sakari.ai...@iki.fi
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [GIT PATCHES FOR 3.1] s5p-fimc and noon010pc30 driver updates

[Mauro Carvalho Chehab]

Em 16-08-2011 08:44, Laurent Pinchart escreveu:
> Hi Mauro,
> 
> On Tuesday 16 August 2011 17:30:47 Mauro Carvalho Chehab wrote:
>> Em 16-08-2011 01:57, Laurent Pinchart escreveu:
> My point is that the ISP driver developer can't know in advance which
> sensor will be used systems that don't exist yet.

 As far as such hardware is projected, someone will know. It is a simple
 trivial patch to associate a new hardware with a hardware profile at the
 platform data.
>>>
>>> Platform data must contain hardware descriptions only, not policies. This
>>> is even clearer now that ARM is moving away from board code to the
>>> Device Tree.
>>
>> Again, a cell phone with one frontal camera and one hear camera has two
>> sensor inputs only. This is not a "policy". It is a hardware constraint.
>> The driver should allow setting the pipeline for both sensors via S_INPUT,
>> otherwise a V4L2 only userspace application won't work.
>>
>> It is as simple as that.
> 
> When capturing from the main sensor on the OMAP3 ISP you need to capture raw 
> data to memory on a video node, feed it back to the hardware through another 
> video node, and finally capture it on a third video node. A V4L2-only 
> userspace application won't work. That's how the hardware is, we can't do 
> much 
> about that.

The raw data conversion is one of the functions that libv4l should do. So, if
you've already submitted the patches for libv4l to do the hardware loopback
trick, or add a function there to convert the raw data into a common format,
that should be ok. Otherwise, we have a problem, that needs to be fixed.

> 
 Also, on most cases, probing a sensor is as trivial as reading a sensor
 ID during device probe. This applies, for example, for all Omnivision
 sensors.

 We do things like that all the times for PC world, as nobody knows what
 webcam someone would plug on his PC.
>>>
>>> Sorry, but that's not related. You simply can't decide in an embedded ISP
>>> driver how to deal with sensor controls, as the system will be used in a
>>> too wide variety of applications and hardware configurations. All
>>> controls need to be exposed, period.
>>
>> We're not talking about controls. We're talking about providing the needed
>> V4L2 support to allow an userspace application to access the hardware
>> sensor.
> 
> OK, so we're discussing S_INPUT. Let's discuss controls later :-)
> 
>> I never saw an embedded hardware that allows physically changing the
>> sensor.
>
> Beagleboard + pluggable sensor board.

 Development systems like beagleboard, pandaboard, Exynos SMDK, etc,
 aren't embeeded hardware. They're development kits.
>>>
>>> People create end-user products based on those kits. That make them
>>> first- class embedded hardware like any other.
>>
>> No doubt they should be supported, but it doesn't make sense to create tons
>> of input pipelines to be used for S_INPUT for each different type of
>> possible sensor. Somehow, userspace needs to tell what's the sensor that
>> he attached to the hardware, or the driver should suport auto-detecting
>> it.
> 
> We're not creating tons of input pipelines. Look at 
> http://www.ideasonboard.org/media/omap3isp.ps , every video node (in yellow) 
> has its purpose.

Not sure if I it understood well. The subdevs 8-11 are the sensors, right?

>> In other words, I see 2 options for that:
>>  1) add hardware auto-detection at the sensor logic. At driver probe,
>> try to probe all sensors, if it is a hardware development kit;
> 
> We've worked quite hard to remove I2C device probing from the kernel, let's 
> not add it back.

We do I2C probing on several drivers. It is there for devices where
the cards entry is not enough to identify the hardware. For example,
two different devices with the same USB ID generally uses that.
If the hardware information is not enough, there's nothing wrong
on doing that.

>>  2) add one new parameter at the driver: "sensors". If the hardware
>> is one of those kits, this parameter will allow the developer to specify
>> the used sensors. It is the same logic as we do with userspace TV and
>> grabber cards without eeprom or any other way to auto-detect the hardware.
> 
> This will likely be done through the Device Tree.

I don't mind much about the way it is implemented, but it should be there
on a place where people can find it and use it.

Devices that requires the user to pass some parameters to the Kernel in order
for the driver to find the hardware are economic class devices. A first
class device should work as-is, after the driver is loaded.

 I don't mind if, for those kits the developer that is playing with it
 has to pass a mode parameter and/or run some open harware-aware small
 application that makes the driver to select the sensor type he is
 using, but, if the hardware is, instead, a N9 or a Galaxy Tab (or
 whatever embedded hardware), the driver should expose just the

Re: Afatech AF9013

[Jose Alberto Reguero]

On Martes, 16 de Agosto de 2011 22:57:24 Antti Palosaari escribió:
> On 08/16/2011 11:27 PM, Jose Alberto Reguero wrote:
> >> options dvb-usb force_pid_filter_usage=1
> >> 
> >> I change the signal timeout and tuning timeout and now it works perfect!
> >> 
> >> I can watch two HD channels, thanks for your help.
> >> 
> >> I really don't understand what force_pid_filter_usage do on the
> >> module, is there any documentation?
> >> 
> >> Thanks and best regards.
> > 
> > For usb devices with usb 2.0 when tunned to a channel there is enought
> > usb bandwith to deliver the whole transponder. With pid filters they
> > only deliver the pids needed for the channel. The only limit is that the
> > pid filters is limited normaly to 32 pids.
> 
> May I ask how wide DVB-T streams you have? Here in Finland it is about
> 22 Mbit/sec and I think two such streams should be too much for one USB
> bus. I suspect there is some other bug in back of this.
> 
> regards
> Antti

Here the transport stream is like yours. About 4 Mbit/sec by channel, and 
about 5 channels by transport stream. The problem I have is that when I have 
the two tuners working I have a few packets lost, and I have some TS 
discontinuitys. With pid filters the stream is perfect. Perhaps Josu have 
another problem.

Jose Alberto
--
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] Fix locking problem, race conditions and resource leaks in em28xx, em28xx-dvb

[Chris Rankin]

Hi,

Here's the latest draft of my patch (against 3.0). Any feedback greatly 
appreciated.

Cheers,
Chris

--- linux-3.0/drivers/media/video/em28xx/em28xx-core.c.orig	2011-08-16 19:49:58.0 +0100
+++ linux-3.0/drivers/media/video/em28xx/em28xx-core.c	2011-08-16 21:46:35.0 +0100
@@ -1160,10 +1160,9 @@
 static DEFINE_MUTEX(em28xx_devlist_mutex);
 
 /*
- * em28xx_realease_resources()
- * unregisters the v4l2,i2c and usb devices
- * called when the device gets disconected or at module unload
-*/
+ * em28xx_remove_from_devlist()
+ * Removes the device from the list of active devices.
+ */
 void em28xx_remove_from_devlist(struct em28xx *dev)
 {
 	mutex_lock(&em28xx_devlist_mutex);
@@ -1171,13 +1170,6 @@
 	mutex_unlock(&em28xx_devlist_mutex);
 };
 
-void em28xx_add_into_devlist(struct em28xx *dev)
-{
-	mutex_lock(&em28xx_devlist_mutex);
-	list_add_tail(&dev->devlist, &em28xx_devlist);
-	mutex_unlock(&em28xx_devlist_mutex);
-};
-
 /*
  * Extension interface
  */
@@ -1193,8 +1185,8 @@
 	list_for_each_entry(dev, &em28xx_devlist, devlist) {
 		ops->init(dev);
 	}
-	printk(KERN_INFO "Em28xx: Initialized (%s) extension\n", ops->name);
 	mutex_unlock(&em28xx_devlist_mutex);
+	printk(KERN_INFO "Em28xx: Initialized (%s) extension\n", ops->name);
 	return 0;
 }
 EXPORT_SYMBOL(em28xx_register_extension);
@@ -1207,9 +1199,9 @@
 	list_for_each_entry(dev, &em28xx_devlist, devlist) {
 		ops->fini(dev);
 	}
-	printk(KERN_INFO "Em28xx: Removed (%s) extension\n", ops->name);
 	list_del(&ops->next);
 	mutex_unlock(&em28xx_devlist_mutex);
+	printk(KERN_INFO "Em28xx: Removed (%s) extension\n", ops->name);
 }
 EXPORT_SYMBOL(em28xx_unregister_extension);
 
@@ -1218,11 +1210,10 @@
 	struct em28xx_ops *ops = NULL;
 
 	mutex_lock(&em28xx_devlist_mutex);
-	if (!list_empty(&em28xx_extension_devlist)) {
-		list_for_each_entry(ops, &em28xx_extension_devlist, next) {
-			if (ops->init)
-ops->init(dev);
-		}
+	list_add_tail(&dev->devlist, &em28xx_devlist);
+	list_for_each_entry(ops, &em28xx_extension_devlist, next) {
+		if (ops->init)
+			ops->init(dev);
 	}
 	mutex_unlock(&em28xx_devlist_mutex);
 }
--- linux-3.0/drivers/media/video/em28xx/em28xx-cards.c.orig	2011-08-16 21:28:25.0 +0100
+++ linux-3.0/drivers/media/video/em28xx/em28xx-cards.c	2011-08-16 23:10:06.0 +0100
@@ -2738,9 +2738,9 @@
 #endif /* CONFIG_MODULES */
 
 /*
- * em28xx_realease_resources()
+ * em28xx_release_resources()
  * unregisters the v4l2,i2c and usb devices
- * called when the device gets disconected or at module unload
+ * called when the device gets disconnected or at module unload
 */
 void em28xx_release_resources(struct em28xx *dev)
 {
@@ -2776,7 +2776,6 @@
 {
 	struct em28xx *dev = *devhandle;
 	int retval;
-	int errCode;
 
 	dev->udev = udev;
 	mutex_init(&dev->ctrl_urb_lock);
@@ -2872,12 +2871,11 @@
 	}
 
 	/* register i2c bus */
-	errCode = em28xx_i2c_register(dev);
-	if (errCode < 0) {
-		v4l2_device_unregister(&dev->v4l2_dev);
+	retval = em28xx_i2c_register(dev);
+	if (retval < 0) {
 		em28xx_errdev("%s: em28xx_i2c_register - errCode [%d]!\n",
-			__func__, errCode);
-		return errCode;
+			__func__, retval);
+		goto fail_reg_i2c;
 	}
 
 	/*
@@ -2891,11 +2889,11 @@
 	em28xx_card_setup(dev);
 
 	/* Configure audio */
-	errCode = em28xx_audio_setup(dev);
-	if (errCode < 0) {
-		v4l2_device_unregister(&dev->v4l2_dev);
+	retval = em28xx_audio_setup(dev);
+	if (retval < 0) {
 		em28xx_errdev("%s: Error while setting audio - errCode [%d]!\n",
-			__func__, errCode);
+			__func__, retval);
+		goto fail_setup_audio;
 	}
 
 	/* wake i2c devices */
@@ -2909,31 +2907,28 @@
 
 	if (dev->board.has_msp34xx) {
 		/* Send a reset to other chips via gpio */
-		errCode = em28xx_write_reg(dev, EM28XX_R08_GPIO, 0xf7);
-		if (errCode < 0) {
-			em28xx_errdev("%s: em28xx_write_regs_req - "
+		retval = em28xx_write_reg(dev, EM28XX_R08_GPIO, 0xf7);
+		if (retval < 0) {
+			em28xx_errdev("%s: em28xx_write_reg - "
   "msp34xx(1) failed! errCode [%d]\n",
-  __func__, errCode);
-			return errCode;
+  __func__, retval);
+			goto fail_write_reg;
 		}
 		msleep(3);
 
-		errCode = em28xx_write_reg(dev, EM28XX_R08_GPIO, 0xff);
-		if (errCode < 0) {
-			em28xx_errdev("%s: em28xx_write_regs_req - "
+		retval = em28xx_write_reg(dev, EM28XX_R08_GPIO, 0xff);
+		if (retval < 0) {
+			em28xx_errdev("%s: em28xx_write_reg - "
   "msp34xx(2) failed! errCode [%d]\n",
-  __func__, errCode);
-			return errCode;
+  __func__, retval);
+			goto fail_write_reg;
 		}
 		msleep(3);
 	}
 
-	em28xx_add_into_devlist(dev);
-
 	retval = em28xx_register_analog_devices(dev);
 	if (retval < 0) {
-		em28xx_release_resources(dev);
-		goto fail_reg_devices;
+		goto fail_reg_analog_devices;
 	}
 
 	em28xx_init_extension(dev);
@@ -2943,7 +2938,14 @@
 
 	return 0;
 
-fail_reg_devices:
+fail_setup_audio:
+fail_write_reg:
+fail_reg_analog_devices:
+	em28xx_i2c_unregister(dev);
+
+fail_reg_i2c:
+	v4l2_device_unregister(&dev->v4l2_dev);
+
 	return

Re: [PATCH] media: vb2: dma-sg allocator: change scatterlist allocation method

[Jonathan Corbet]

On Tue, 16 Aug 2011 12:34:56 +0200
Marek Szyprowski  wrote:

> Right, I wasn't aware of that, but it still doesn't look like an issue. The 
> only
> 
> client of dma-sg allocator is marvell-ccic, which is used on x86 systems. If 
> one
> needs dma-sg allocator on ARM, he should follow the suggestion from the 
> 74facffeca3795ffb5cf8898f5859fbb822e4c5d commit message.

Um...that driver runs on ARM, actually - the controller is part of the
ARMADA 610 SoC...

For the OLPC 1.75 there will never be a scatterlist longer than one
page, I don't think.  That controller can do HD, though, so longer
lists are possible in the future.

jon
--
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

Embedded device and the V4L2 API support - Was: [GIT PATCHES FOR 3.1] s5p-fimc and noon010pc30 driver updates

[Mauro Carvalho Chehab]

It seems that there are too many miss understandings or maybe we're just
talking the same thing on different ways.

So, instead of answering again, let's re-start this discussion on a
different way.

One of the requirements that it was discussed a lot on both mailing
lists and on the Media Controllers meetings that we had (or, at least
in the ones where I've participated) is that:

"A pure V4L2 userspace application, knowing about video device
 nodes only, can still use the driver. Not all advanced features 
 will be available."

This is easily said than done. Also, different understandings can be
obtained by a simple phrase like that.

The solution for this problem is to make a compliance profile that
drivers need to implement. We should define such profile, change
the existing drivers to properly implement it and enforce it for the
newcoming drivers.

Btw, I think we should also work on a profile for other kinds of hardware
as well, but the thing is that, as some things can now be implemented
using two different API's, we need to define the minimal requirements
for the V4L2 implementation.


For me, the above requirement means that, at least, the following features
need to be present:

1) The media driver should properly detect the existing hardware and
should expose the available sensors for capture via the V4L2 API.

For hardware development kits, it should be possible to specify the
hardware sensor(s) at runtime via some tool at the v4l-utils tree 
(or on another tree hosted at linuxtv.org or clearly indicated at
the Kernel tree Documentation files) or via a modprobe parameter.

2) Different sensors present at the hardware may be exposed either
via S_INPUT or, if they're completely independent, via two different
node interface;

3) The active sensor basic controls to adjust color, bright, aperture time
and exposition time, if the hardware directly supports them;

4) The driver should implement the streaming ioctls and/or the read() method;

5) It should be possible to configure the frame rate, if the sensor supports it;

6) It should be possible to configure the crap area, if the sensor supports it.

7) It should be possible to configure the format standard and resolution

...
(the above list is not exhaustive. It is just a few obvious things that are
clear to me - I'm almost sure that I've forgot something).

We'll also end by having some optional requirements, like the DV timings ioctls
that also needs to be covered by the SoC hardware profile.

In practice, the above requirements should be converted into a list of features
and ioctl's that needs to be implemented on every SoC driver that implements
a capture or output video streaming device.

My suggestion is that we should start the discussions by filling the macro
requirements. Once we agree on that, we can make a list of the V4L and MC
ioctl's and convert them into a per-ioctl series of requirements.

Regards,
Mauro


--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html