Re: [PATCH v4l-utils] configure.ac: drop --disable-libv4l, disable plugin support instead

2017-09-02 Thread Thomas Petazzoni 
Hello,

On Wed, 23 Aug 2017 13:06:13 +0200, Hans Verkuil wrote:
> On 08/21/17 23:02, Thomas Petazzoni wrote:
> > In commit 2e604dfbcd09b93f0808cedb2a0b324c5569a599 ("configure.ac: add
> > --disable-libv4l option"), an option --disable-libv4l was added. As
> > part of this, libv4l is no longer built at all in static linking
> > configurations, just because libv4l uses dlopen() for plugin support.
> > 
> > However, plugin support is only a side feature of libv4l, and one may
> > need to use libv4l in static configurations, just without plugin
> > support.
> > 
> > Therefore, this commit:
> > 
> >  - Essentially reverts 2e604dfbcd09b93f0808cedb2a0b324c5569a599, so
> >that libv4l can be built in static linking configurations again.
> > 
> >  - Adjusts the compilation of libv4l2 so that the plugin support is
> >not compiled in when dlopen() in static linking configuration
> >(dlopen is not available).
> > 
> > Signed-off-by: Thomas Petazzoni <thomas.petazz...@free-electrons.com>
> > ---
> > NOTE: this was only build-time tested, not runtime tested.  
> 
> Hugues, can you test this to make sure this still does what you need?
> 
> It looks good to me, but I'd like to make sure it works for you as well
> before committing this.

Thanks for your feedback. Unfortunately, Hugues has not answered. What
can we do ?

Thanks,

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

[PATCH v4l-utils] configure.ac: drop --disable-libv4l, disable plugin support instead

2017-08-21 Thread Thomas Petazzoni 
In commit 2e604dfbcd09b93f0808cedb2a0b324c5569a599 ("configure.ac: add
--disable-libv4l option"), an option --disable-libv4l was added. As
part of this, libv4l is no longer built at all in static linking
configurations, just because libv4l uses dlopen() for plugin support.

However, plugin support is only a side feature of libv4l, and one may
need to use libv4l in static configurations, just without plugin
support.

Therefore, this commit:

 - Essentially reverts 2e604dfbcd09b93f0808cedb2a0b324c5569a599, so
   that libv4l can be built in static linking configurations again.

 - Adjusts the compilation of libv4l2 so that the plugin support is
   not compiled in when dlopen() in static linking configuration
   (dlopen is not available).

Signed-off-by: Thomas Petazzoni <thomas.petazz...@free-electrons.com>
---
NOTE: this was only build-time tested, not runtime tested.
---
 Makefile.am   | 11 ++-
 configure.ac  | 15 +++
 lib/libv4l2/Makefile.am   |  6 +-
 lib/libv4l2/libv4l2-priv.h| 14 ++
 utils/Makefile.am |  6 +-
 utils/v4l2-compliance/Makefile.am |  4 
 utils/v4l2-ctl/Makefile.am|  4 
 7 files changed, 25 insertions(+), 35 deletions(-)

diff --git a/Makefile.am b/Makefile.am
index 07c3ef8..e603472 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -1,17 +1,10 @@
 AUTOMAKE_OPTIONS = foreign
 ACLOCAL_AMFLAGS = -I m4
 
-SUBDIRS = v4l-utils-po libdvbv5-po
-
-if WITH_LIBV4L
-SUBDIRS += lib
-endif
+SUBDIRS = v4l-utils-po libdvbv5-po lib
 
 if WITH_V4LUTILS
-SUBDIRS += utils
-if WITH_LIBV4L
-SUBDIRS += contrib
-endif
+SUBDIRS += utils contrib
 endif
 
 EXTRA_DIST = android-config.h bootstrap.sh doxygen_libdvbv5.cfg include 
COPYING.libv4l \
diff --git a/configure.ac b/configure.ac
index 72c9421..af44663 100644
--- a/configure.ac
+++ b/configure.ac
@@ -375,14 +375,6 @@ AC_ARG_ENABLE(libdvbv5,
esac]
 )
 
-AC_ARG_ENABLE(libv4l,
-  AS_HELP_STRING([--disable-libv4l], [disable libv4l compilation]),
-  [case "${enableval}" in
- yes | no ) ;;
- *) AC_MSG_ERROR(bad value ${enableval} for --disable-libv4l) ;;
-   esac]
-)
-
 AC_ARG_ENABLE(dyn-libv4l,
   AS_HELP_STRING([--disable-dyn-libv4l], [disable dynamic libv4l support]),
   [case "${enableval}" in
@@ -448,7 +440,6 @@ AM_CONDITIONAL([WITH_LIBDVBV5], [test x$enable_libdvbv5 
 != xno -a x$have_li
 AM_CONDITIONAL([WITH_DVBV5_REMOTE], [test x$enable_libdvbv5  != xno -a 
x$have_libudev = xyes -a x$have_pthread = xyes])
 
 AM_CONDITIONAL([WITH_DYN_LIBV4L],   [test x$enable_dyn_libv4l != xno])
-AM_CONDITIONAL([WITH_LIBV4L],   [test x$enable_libv4l!= xno -a 
x$enable_shared != xno])
 AM_CONDITIONAL([WITH_V4LUTILS],[test x$enable_v4l_utils != xno -a 
x$linux_os = xyes])
 AM_CONDITIONAL([WITH_QV4L2],   [test x${qt_pkgconfig} = xtrue -a 
x$enable_qv4l2 != xno])
 AM_CONDITIONAL([WITH_V4L_PLUGINS],  [test x$enable_dyn_libv4l != xno -a 
x$enable_shared != xno])
@@ -477,11 +468,12 @@ AM_COND_IF([WITH_LIBDVBV5], [USE_LIBDVBV5="yes"], 
[USE_LIBDVBV5="no"])
 AM_COND_IF([WITH_DVBV5_REMOTE], [USE_DVBV5_REMOTE="yes"
 AC_DEFINE([HAVE_DVBV5_REMOTE], [1], [Usage of 
DVBv5 remote enabled])],
[USE_DVBV5_REMOTE="no"])
-AM_COND_IF([WITH_LIBV4L], [USE_LIBV4L="yes"], [USE_LIBV4L="no"])
 AM_COND_IF([WITH_DYN_LIBV4L], [USE_DYN_LIBV4L="yes"], [USE_DYN_LIBV4L="no"])
 AM_COND_IF([WITH_V4LUTILS], [USE_V4LUTILS="yes"], [USE_V4LUTILS="no"])
 AM_COND_IF([WITH_QV4L2], [USE_QV4L2="yes"], [USE_QV4L2="no"])
-AM_COND_IF([WITH_V4L_PLUGINS], [USE_V4L_PLUGINS="yes"], [USE_V4L_PLUGINS="no"])
+AM_COND_IF([WITH_V4L_PLUGINS], [USE_V4L_PLUGINS="yes"
+   AC_DEFINE([HAVE_V4L_PLUGINS], [1], [V4L plugin 
support enabled])],
+   [USE_V4L_PLUGINS="no"])
 AM_COND_IF([WITH_V4L_WRAPPERS], [USE_V4L_WRAPPERS="yes"], 
[USE_V4L_WRAPPERS="no"])
 AM_COND_IF([WITH_GCONV], [USE_GCONV="yes"], [USE_GCONV="no"])
 AM_COND_IF([WITH_V4L2_CTL_LIBV4L], [USE_V4L2_CTL_LIBV4L="yes"], 
[USE_V4L2_CTL_LIBV4L="no"])
@@ -513,7 +505,6 @@ compile time options summary
 
 gconv  : $USE_GCONV
 
-libv4l : $USE_LIBV4L
 dynamic libv4l : $USE_DYN_LIBV4L
 v4l_plugins: $USE_V4L_PLUGINS
 v4l_wrappers   : $USE_V4L_WRAPPERS
diff --git a/lib/libv4l2/Makefile.am b/lib/libv4l2/Makefile.am
index 811c45c..3a1bb90 100644
--- a/lib/libv4l2/Makefile.am
+++ b/lib/libv4l2/Makefile.am
@@ -15,7 +15,11 @@ else
 noinst_LTLIBRARIES = libv4l2.la
 endif
 
-libv4l2_la_SOURCES = libv4l2.c v4l2-plugin.c log.c libv4l2-priv.h
+libv4l2_la_SOURCES =

Re: [PATCH dtv-scan-tables] Rename pl-Krosno_Sucha_Gora with only ASCII characters

2016-11-18 Thread Thomas Petazzoni 
Hello,

On Fri, 18 Nov 2016 22:05:02 +0100, Olliver Schinagl wrote:

> I agree for consistency sake and ease of use, to use plain ascii for 
> pl-Krosno_Sucha_Gora as well. If someone feels that we should follow 
> proper spelling using UTF-8, someone should fix up and correct all names 
> in 1 rename patch.
> 
> Also there are various downstream users, which may simply not support 
> UTF-8. So by using ascii we also reduce the risk of trouble there.
> 
> Thank you for the patch and it has been merged.

Thanks a lot!

I think encoding the correct name of the city in the file name is not a
good idea. File name encoding is always problematic. Instead, what
would be better is to have the proper city name inside the file itself.
This way, you can specify that for the entire database, the files are
encoded in UTF-8.

Best regards,

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH dtv-scan-tables] Rename pl-Krosno_Sucha_Gora with only ASCII characters

2016-11-14 Thread Thomas Petazzoni 
The pl-Krosno_Sucha_Gora file, added in commit
4cb113fd15e562f0629000fcad9f41405595198d, is the only file that
contains non-ASCII characters in the tree. This causes a number of
build issues with other packages that don't necessarily handle very
well non-ASCII file name encodings.

Since no other file in the tree contain non-ASCII characters in their
name, this commit renames pl-Krosno_Sucha_Gora similarly.

Examples of files that are named with only ASCII characters even if
the city name really contains non-ASCII characters:

  - pl-Wroclaw should be written pl-Wrocław
  - se-Laxsjo should be written se-Laxsjö
  - de-Dusseldorf should be written de-Düsseldorf
  - vn-Thaibinh should be written vn-Thái_Bình

Since there is no real standardization on the encoding of file names,
we'd better be safe and use only ASCII characters.

Signed-off-by: Thomas Petazzoni <thomas.petazz...@free-electrons.com>
---
 "dvb-t/pl-Krosno_Sucha_G\303\263ra" => dvb-t/pl-Krosno_Sucha_Gora | 0
 1 file changed, 0 insertions(+), 0 deletions(-)
 rename "dvb-t/pl-Krosno_Sucha_G\303\263ra" => dvb-t/pl-Krosno_Sucha_Gora (100%)

diff --git "a/dvb-t/pl-Krosno_Sucha_G\303\263ra" b/dvb-t/pl-Krosno_Sucha_Gora
similarity index 100%
rename from "dvb-t/pl-Krosno_Sucha_G\303\263ra"
rename to dvb-t/pl-Krosno_Sucha_Gora
-- 
2.7.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

[v4l-utils 0/5] Misc build fixes

2015-11-03 Thread Thomas Petazzoni 
Hello,

Here is a small set of fixes against v4l-utils that we have
accumulated in the Buildroot project to fix a number of build
issues. Those build issues are related to linking with the musl C
library, or do linking with the libintl library when the gettext
functions are not provided by the C library (which is what happens the
uClibc C library is used).

Thanks,

Thomas

Peter Seiderer (1):
  dvb/keytable: fix missing libintl linking

Thomas Petazzoni (4):
  libv4lsyscall-priv.h: Use off_t instead of __off_t
  utils: Properly use ENABLE_NLS for locale related code
  utils/v4l2-compliance: Include  instead of 
  libv4lsyscall-priv.h: Only define SYS_mmap2 if needed

 lib/libv4l1/v4l1compat.c   |  3 +--
 lib/libv4l2/v4l2convert.c  |  5 ++---
 lib/libv4lconvert/libv4lsyscall-priv.h | 13 +
 utils/dvb/Makefile.am  |  8 
 utils/dvb/dvb-fe-tool.c|  2 ++
 utils/dvb/dvb-format-convert.c |  2 ++
 utils/dvb/dvbv5-scan.c |  2 ++
 utils/dvb/dvbv5-zap.c  |  2 ++
 utils/keytable/Makefile.am |  1 +
 utils/keytable/keytable.c  |  2 ++
 utils/v4l2-compliance/v4l-helpers.h|  2 +-
 11 files changed, 24 insertions(+), 18 deletions(-)

-- 
2.6.2

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

[v4l-utils 5/5] dvb/keytable: fix missing libintl linking

2015-11-03 Thread Thomas Petazzoni 
From: Peter Seiderer 

Signed-off-by: Peter Seiderer 
---
 utils/dvb/Makefile.am  | 8 
 utils/keytable/Makefile.am | 1 +
 2 files changed, 5 insertions(+), 4 deletions(-)

diff --git a/utils/dvb/Makefile.am b/utils/dvb/Makefile.am
index 6aae408..a96a1a2 100644
--- a/utils/dvb/Makefile.am
+++ b/utils/dvb/Makefile.am
@@ -2,19 +2,19 @@ bin_PROGRAMS = dvb-fe-tool dvbv5-zap dvbv5-scan 
dvb-format-convert
 man_MANS = dvb-fe-tool.1 dvbv5-zap.1 dvbv5-scan.1 dvb-format-convert.1
 
 dvb_fe_tool_SOURCES = dvb-fe-tool.c
-dvb_fe_tool_LDADD = ../../lib/libdvbv5/libdvbv5.la
+dvb_fe_tool_LDADD = ../../lib/libdvbv5/libdvbv5.la @LIBINTL@
 dvb_fe_tool_LDFLAGS = $(ARGP_LIBS) -lm
 
 dvbv5_zap_SOURCES = dvbv5-zap.c
-dvbv5_zap_LDADD = ../../lib/libdvbv5/libdvbv5.la
+dvbv5_zap_LDADD = ../../lib/libdvbv5/libdvbv5.la @LIBINTL@
 dvbv5_zap_LDFLAGS = $(ARGP_LIBS) -lm
 
 dvbv5_scan_SOURCES = dvbv5-scan.c
-dvbv5_scan_LDADD = ../../lib/libdvbv5/libdvbv5.la
+dvbv5_scan_LDADD = ../../lib/libdvbv5/libdvbv5.la @LIBINTL@
 dvbv5_scan_LDFLAGS = $(ARGP_LIBS) -lm
 
 dvb_format_convert_SOURCES = dvb-format-convert.c
-dvb_format_convert_LDADD = ../../lib/libdvbv5/libdvbv5.la
+dvb_format_convert_LDADD = ../../lib/libdvbv5/libdvbv5.la @LIBINTL@
 dvb_format_convert_LDFLAGS = $(ARGP_LIBS) -lm
 
 EXTRA_DIST = README
diff --git a/utils/keytable/Makefile.am b/utils/keytable/Makefile.am
index 925c8ea..8444ac2 100644
--- a/utils/keytable/Makefile.am
+++ b/utils/keytable/Makefile.am
@@ -5,6 +5,7 @@ keytablesystem_DATA = $(srcdir)/rc_keymaps/*
 udevrules_DATA = 70-infrared.rules
 
 ir_keytable_SOURCES = keytable.c parse.h
+ir_keytable_LDADD = @LIBINTL@
 ir_keytable_LDFLAGS = $(ARGP_LIBS)
 
 EXTRA_DIST = 70-infrared.rules rc_keymaps rc_keymaps_userspace 
gen_keytables.pl ir-keytable.1 rc_maps.cfg
-- 
2.6.2

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

[v4l-utils 3/5] utils/v4l2-compliance: Include instead of

2015-11-03 Thread Thomas Petazzoni 
Code should not be including  header, but instead it
should include the public  header.

On glibc and uClibc,  simply includes , but with
the musl C library, it spits out a warning telling you that you're not
doing the right thing:

In file included from ./v4l-helpers.h:12:0,
 from ./cv4l-helpers.h:5,
 from v4l2-compliance.h:36,
 from v4l2-test-controls.cpp:33:
.../sysroot/usr/include/sys/fcntl.h:1:2: warning: #warning redirecting 
incorrect #include  to  [-Wcpp]
 #warning redirecting incorrect #include  to 

Signed-off-by: Thomas Petazzoni <thomas.petazz...@free-electrons.com>
---
 utils/v4l2-compliance/v4l-helpers.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/utils/v4l2-compliance/v4l-helpers.h 
b/utils/v4l2-compliance/v4l-helpers.h
index d8a273d..9aafa34 100644
--- a/utils/v4l2-compliance/v4l-helpers.h
+++ b/utils/v4l2-compliance/v4l-helpers.h
@@ -9,7 +9,7 @@
 #include 
 #include 
 #include 
-#include 
+#include 
 #include 
 #include 
 
-- 
2.6.2

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

[v4l-utils 2/5] utils: Properly use ENABLE_NLS for locale related code

2015-11-03 Thread Thomas Petazzoni 
Various tools in utils/ use ENABLE_NLS to decide whether locale
support is available or not, and only include  if ENABLE_NLS
is defined. However, they unconditionally use functions defined in
 such as setlocale(), bindtextdomain() or textdomain(),
which causes build failures when the prototypes of such functions are
not available due to  not being included.

In order to fix this, we add ENABLE_NLS conditionals around the calls
to these functions.

Signed-off-by: Thomas Petazzoni <thomas.petazz...@free-electrons.com>
---
 utils/dvb/dvb-fe-tool.c| 2 ++
 utils/dvb/dvb-format-convert.c | 2 ++
 utils/dvb/dvbv5-scan.c | 2 ++
 utils/dvb/dvbv5-zap.c  | 2 ++
 utils/keytable/keytable.c  | 2 ++
 5 files changed, 10 insertions(+)

diff --git a/utils/dvb/dvb-fe-tool.c b/utils/dvb/dvb-fe-tool.c
index efc2ebf..ba01aa9 100644
--- a/utils/dvb/dvb-fe-tool.c
+++ b/utils/dvb/dvb-fe-tool.c
@@ -276,9 +276,11 @@ int main(int argc, char *argv[])
struct dvb_v5_fe_parms *parms;
int fe_flags = O_RDWR;
 
+#ifdef ENABLE_NLS
setlocale (LC_ALL, "");
bindtextdomain (PACKAGE, LOCALEDIR);
textdomain (PACKAGE);
+#endif
 
argp_parse(, argc, argv, ARGP_NO_HELP | ARGP_NO_EXIT, 0, 0);
 
diff --git a/utils/dvb/dvb-format-convert.c b/utils/dvb/dvb-format-convert.c
index e39df03..09451d4 100644
--- a/utils/dvb/dvb-format-convert.c
+++ b/utils/dvb/dvb-format-convert.c
@@ -132,9 +132,11 @@ int main(int argc, char **argv)
.args_doc = N_(" "),
};
 
+#ifdef ENABLE_NLS
setlocale (LC_ALL, "");
bindtextdomain (PACKAGE, LOCALEDIR);
textdomain (PACKAGE);
+#endif
 
memset(, 0, sizeof(args));
argp_parse(, argc, argv, ARGP_NO_HELP | ARGP_NO_EXIT, , );
diff --git a/utils/dvb/dvbv5-scan.c b/utils/dvb/dvbv5-scan.c
index be1586d..1bb0ced 100644
--- a/utils/dvb/dvbv5-scan.c
+++ b/utils/dvb/dvbv5-scan.c
@@ -461,9 +461,11 @@ int main(int argc, char **argv)
.args_doc = N_(""),
};
 
+#ifdef ENABLE_NLS
setlocale (LC_ALL, "");
bindtextdomain (PACKAGE, LOCALEDIR);
textdomain (PACKAGE);
+#endif
 
memset(, 0, sizeof(args));
args.sat_number = -1;
diff --git a/utils/dvb/dvbv5-zap.c b/utils/dvb/dvbv5-zap.c
index 2812166..848259b 100644
--- a/utils/dvb/dvbv5-zap.c
+++ b/utils/dvb/dvbv5-zap.c
@@ -758,9 +758,11 @@ int main(int argc, char **argv)
.args_doc = N_(" [or  if in monitor 
mode]"),
};
 
+#ifdef ENABLE_NLS
setlocale (LC_ALL, "");
bindtextdomain (PACKAGE, LOCALEDIR);
textdomain (PACKAGE);
+#endif
 
memset(, 0, sizeof(args));
args.sat_number = -1;
diff --git a/utils/keytable/keytable.c b/utils/keytable/keytable.c
index 63938b9..3922ad2 100644
--- a/utils/keytable/keytable.c
+++ b/utils/keytable/keytable.c
@@ -1467,9 +1467,11 @@ int main(int argc, char *argv[])
static struct sysfs_names *names;
struct rc_device  rc_dev;
 
+#ifdef ENABLE_NLS
setlocale (LC_ALL, "");
bindtextdomain (PACKAGE, LOCALEDIR);
textdomain (PACKAGE);
+#endif
 
argp_parse(, argc, argv, ARGP_NO_HELP | ARGP_NO_EXIT, 0, 0);
 
-- 
2.6.2

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

[v4l-utils 1/5] libv4lsyscall-priv.h: Use off_t instead of __off_t

2015-11-03 Thread Thomas Petazzoni 
__off_t is a kernel internal symbol, which happens to be user-visible
with glibc, but not necessarily with other C libraries such as
musl. In v4l-utils code, it's mainly used for the mmap() prototype,
but the mmap() manpage really uses off_t, not __off_t.

Switching from __off_t to off_t allows the code to build properly with
musl.

Signed-off-by: Thomas Petazzoni <thomas.petazz...@free-electrons.com>
---
 lib/libv4l1/v4l1compat.c   |  3 +--
 lib/libv4l2/v4l2convert.c  |  5 ++---
 lib/libv4lconvert/libv4lsyscall-priv.h | 11 +++
 3 files changed, 6 insertions(+), 13 deletions(-)

diff --git a/lib/libv4l1/v4l1compat.c b/lib/libv4l1/v4l1compat.c
index 393896c..cb79629 100644
--- a/lib/libv4l1/v4l1compat.c
+++ b/lib/libv4l1/v4l1compat.c
@@ -26,7 +26,6 @@
 #include 
 #include 
 #include 
-#include "../libv4lconvert/libv4lsyscall-priv.h" /* for __off_t */
 
 #include 
 #include 
@@ -116,7 +115,7 @@ LIBV4L_PUBLIC ssize_t read(int fd, void *buffer, size_t n)
 }
 
 LIBV4L_PUBLIC void *mmap(void *start, size_t length, int prot, int flags, int 
fd,
-   __off_t offset)
+   off_t offset)
 {
return v4l1_mmap(start, length, prot, flags, fd, offset);
 }
diff --git a/lib/libv4l2/v4l2convert.c b/lib/libv4l2/v4l2convert.c
index 0384c13..6abccbf 100644
--- a/lib/libv4l2/v4l2convert.c
+++ b/lib/libv4l2/v4l2convert.c
@@ -36,7 +36,6 @@
 #include 
 #include 
 #include 
-#include "../libv4lconvert/libv4lsyscall-priv.h"
 #include 
 #include 
 
@@ -148,14 +147,14 @@ LIBV4L_PUBLIC ssize_t read(int fd, void *buffer, size_t n)
 }
 
 LIBV4L_PUBLIC void *mmap(void *start, size_t length, int prot, int flags, int 
fd,
-   __off_t offset)
+   off_t offset)
 {
return v4l2_mmap(start, length, prot, flags, fd, offset);
 }
 
 #if defined(linux) && defined(__GLIBC__)
 LIBV4L_PUBLIC void *mmap64(void *start, size_t length, int prot, int flags, 
int fd,
-   __off64_t offset)
+   off64_t offset)
 {
return v4l2_mmap(start, length, prot, flags, fd, offset);
 }
diff --git a/lib/libv4lconvert/libv4lsyscall-priv.h 
b/lib/libv4lconvert/libv4lsyscall-priv.h
index f548fb2..f87eff4 100644
--- a/lib/libv4lconvert/libv4lsyscall-priv.h
+++ b/lib/libv4lconvert/libv4lsyscall-priv.h
@@ -59,11 +59,6 @@
 #define_IOC_SIZE(cmd) IOCPARM_LEN(cmd)
 #defineMAP_ANONYMOUS MAP_ANON
 #defineMMAP2_PAGE_SHIFT 0
-typedef off_t __off_t;
-#endif
-
-#if defined(ANDROID)
-typedef off_t __off_t;
 #endif
 
 #undef SYS_OPEN
@@ -95,15 +90,15 @@ typedef off_t __off_t;
 #if defined(__FreeBSD__)
 #define SYS_MMAP(addr, len, prot, flags, fd, off) \
__syscall(SYS_mmap, (void *)(addr), (size_t)(len), \
-   (int)(prot), (int)(flags), (int)(fd), (__off_t)(off))
+   (int)(prot), (int)(flags), (int)(fd), (off_t)(off))
 #elif defined(__FreeBSD_kernel__)
 #define SYS_MMAP(addr, len, prot, flags, fd, off) \
syscall(SYS_mmap, (void *)(addr), (size_t)(len), \
-   (int)(prot), (int)(flags), (int)(fd), (__off_t)(off))
+   (int)(prot), (int)(flags), (int)(fd), (off_t)(off))
 #else
 #define SYS_MMAP(addr, len, prot, flags, fd, off) \
syscall(SYS_mmap2, (void *)(addr), (size_t)(len), \
-   (int)(prot), (int)(flags), (int)(fd), (__off_t)((off) 
>> MMAP2_PAGE_SHIFT))
+   (int)(prot), (int)(flags), (int)(fd), (off_t)((off) >> 
MMAP2_PAGE_SHIFT))
 #endif
 
 #define SYS_MUNMAP(addr, len) \
-- 
2.6.2

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

[v4l-utils 4/5] libv4lsyscall-priv.h: Only define SYS_mmap2 if needed

2015-11-03 Thread Thomas Petazzoni 
The logic in libv4lsyscall-priv.h unconditionally defines SYS_mmap2 on
Linux systems, but with current versions of C libraries, SYS_mmap2 is
already defined, and therefore this additional definition causes some
build warnings:

In file included from processing/libv4lprocessing.h:24:0,
 from libv4lconvert-priv.h:37,
 from tinyjpeg.c:42:
processing/../libv4lsyscall-priv.h:44:0: warning: "SYS_mmap2" redefined
 #define SYS_mmap2 __NR_mmap2
 ^
In file included from .../sysroot/usr/include/sys/syscall.h:4:0,
 from processing/../libv4lsyscall-priv.h:39,
 from processing/libv4lprocessing.h:24,
 from libv4lconvert-priv.h:37,
 from tinyjpeg.c:42:
.../sysroot/usr/include/bits/syscall.h:504:0: note: this is the location of the 
previous definition
 #define SYS_mmap2 192

This commit fixes that by only defining SYS_mmap2 if not already
defined.

Signed-off-by: Thomas Petazzoni <thomas.petazz...@free-electrons.com>
---
 lib/libv4lconvert/libv4lsyscall-priv.h | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/lib/libv4lconvert/libv4lsyscall-priv.h 
b/lib/libv4lconvert/libv4lsyscall-priv.h
index f87eff4..bc18b21 100644
--- a/lib/libv4lconvert/libv4lsyscall-priv.h
+++ b/lib/libv4lconvert/libv4lsyscall-priv.h
@@ -41,7 +41,9 @@
 #include 
 /* On 32 bits archs we always use mmap2, on 64 bits archs there is no mmap2 */
 #ifdef __NR_mmap2
+#if !defined(SYS_mmap2)
 #defineSYS_mmap2 __NR_mmap2
+#endif
 #defineMMAP2_PAGE_SHIFT 12
 #else
 #defineSYS_mmap2 SYS_mmap
-- 
2.6.2

--
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 08/10] ARM: orion: use clkdev_create()

2015-03-03 Thread Thomas Petazzoni 
);
-   orion_clkdev_add(NULL, MV64XXX_I2C_CTLR_NAME .0, tclk);
+   clkdev_create(tclk, NULL, %s, orion_spi.0);
+   clkdev_create(tclk, NULL, %s, orion_spi.1);
+   clkdev_create(tclk, NULL, %s, MV643XX_ETH_NAME .0);
+   clkdev_create(tclk, NULL, %s, MV643XX_ETH_NAME .1);
+   clkdev_create(tclk, NULL, %s, MV643XX_ETH_NAME .2);
+   clkdev_create(tclk, NULL, %s, MV643XX_ETH_NAME .3);
+   clkdev_create(tclk, NULL, %s, orion_wdt);
+   clkdev_create(tclk, NULL, %s, MV64XXX_I2C_CTLR_NAME .0);
 }
 
 /* Fill in the resources structure and link it into the platform
diff --git a/arch/arm/plat-orion/include/plat/common.h 
b/arch/arm/plat-orion/include/plat/common.h
index d9a24f6..7a06b6b 100644
--- a/arch/arm/plat-orion/include/plat/common.h
+++ b/arch/arm/plat-orion/include/plat/common.h
@@ -106,8 +106,5 @@ void __init orion_crypto_init(unsigned long mapbase,
  unsigned long sram_size,
  unsigned long irq);
 
-void __init orion_clkdev_add(const char *con_id, const char *dev_id,
-struct clk *clk);
-
 void __init orion_clkdev_init(struct clk *tclk);
 #endif



-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 2/4] cx231xx: fix crash after load/unload/load of module

2012-01-07 Thread Thomas Petazzoni 
The following sequence of commands was triggering a kernel crash in
cdev_get():

 modprobe cx231xx
 rmmod cx231xx
 modprobe cx231xx
 v4l2grab -n 1

The problem was that cx231xx_usb_disconnect() was not doing anything
because the test:

if (!dev-udev)
return;

was reached (i.e, dev-udev was NULL).

This is due to the fact that the 'dev' pointer placed as intfdata into
the usb_interface structure had the wrong value, because
cx231xx_probe() was doing the usb_set_intfdata() on the wrong
usb_interface structure. For some reason, cx231xx_probe() was doing
the following:

static int cx231xx_usb_probe(struct usb_interface *interface,
 const struct usb_device_id *id)
{
struct usb_interface *lif = NULL;
[...]
/* store the current interface */
lif = interface;
[...]
/* store the interface 0 back */
lif = udev-actconfig-interface[0];
[...]
usb_set_intfdata(lif, dev);
[...]
retval = v4l2_device_register(interface-dev, dev-v4l2_dev);
[...]
}

So, the usb_set_intfdata() was done on udev-actconfig-interface[0]
and not on the 'interface' passed as argument to the -probe() and
-disconnect() hooks. Later on, v4l2_device_register() was
initializing the intfdata of the correct usb_interface structure as a
pointer to the v4l2_device structure.

Upon unregistration, the -disconnect() hook was getting the intfdata
of the usb_interface passed as argument... and casted it to a 'struct
cx231xx *' while it was in fact a 'struct v4l2_device *'.

The correct fix seems to just be to set the intfdata on the proper
interface from the beginning. Now, loading/unloading/reloading the
driver allows to use the device properly.

Signed-off-by: Thomas Petazzoni thomas.petazz...@free-electrons.com
---
 drivers/media/video/cx231xx/cx231xx-cards.c |4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/media/video/cx231xx/cx231xx-cards.c 
b/drivers/media/video/cx231xx/cx231xx-cards.c
index 53dae2a..bfcc8ab 100644
--- a/drivers/media/video/cx231xx/cx231xx-cards.c
+++ b/drivers/media/video/cx231xx/cx231xx-cards.c
@@ -1135,7 +1135,7 @@ static int cx231xx_usb_probe(struct usb_interface 
*interface,
cx231xx_info(registering interface %d\n, ifnum);
 
/* save our data pointer in this interface device */
-   usb_set_intfdata(lif, dev);
+   usb_set_intfdata(interface, dev);
 
/*
 * AV device initialization - only done at the last interface
@@ -1157,7 +1157,7 @@ static int cx231xx_usb_probe(struct usb_interface 
*interface,
v4l2_device_unregister(dev-v4l2_dev);
kfree(dev);
dev = NULL;
-   usb_set_intfdata(lif, NULL);
+   usb_set_intfdata(interface, NULL);
 
return retval;
}
-- 
1.7.4.1

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

[PATCH 3/4] cx231xx: remove useless 'lif' variable in cx231xx_usb_probe()

2012-01-07 Thread Thomas Petazzoni 
Now that we set the intfdata on the right interface, the 'lif'
variable is useless.

Signed-off-by: Thomas Petazzoni thomas.petazz...@free-electrons.com
---
 drivers/media/video/cx231xx/cx231xx-cards.c |7 ---
 1 files changed, 0 insertions(+), 7 deletions(-)

diff --git a/drivers/media/video/cx231xx/cx231xx-cards.c 
b/drivers/media/video/cx231xx/cx231xx-cards.c
index bfcc8ab..2a28882 100644
--- a/drivers/media/video/cx231xx/cx231xx-cards.c
+++ b/drivers/media/video/cx231xx/cx231xx-cards.c
@@ -1016,7 +1016,6 @@ static int cx231xx_usb_probe(struct usb_interface 
*interface,
int i, isoc_pipe = 0;
char *speed;
char descr[255] = ;
-   struct usb_interface *lif = NULL;
struct usb_interface_assoc_descriptor *assoc_desc;
 
udev = usb_get_dev(interface_to_usbdev(interface));
@@ -1071,9 +1070,6 @@ static int cx231xx_usb_probe(struct usb_interface 
*interface,
 
/* init CIR module TBD */
 
-   /* store the current interface */
-   lif = interface;
-
/*mode_tv: digital=1 or analog=0*/
dev-mode_tv = 0;
 
@@ -1113,9 +1109,6 @@ static int cx231xx_usb_probe(struct usb_interface 
*interface,
 le16_to_cpu(udev-descriptor.idProduct),
 dev-max_iad_interface_count);
 
-   /* store the interface 0 back */
-   lif = udev-actconfig-interface[0];
-
/* increment interface count */
dev-interface_count++;
 
-- 
1.7.4.1

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

[PATCH 4/4] cx231xx: simplify argument passing to cx231xx_init_dev()

2012-01-07 Thread Thomas Petazzoni 
The 'struct cx231xx *' pointer was passed by reference to the
cx231xx_init_dev() function, for no reason. Instead, just pass it by
value, which is much more logical and simple.

Signed-off-by: Thomas Petazzoni thomas.petazz...@free-electrons.com
---
 drivers/media/video/cx231xx/cx231xx-cards.c |5 ++---
 1 files changed, 2 insertions(+), 3 deletions(-)

diff --git a/drivers/media/video/cx231xx/cx231xx-cards.c 
b/drivers/media/video/cx231xx/cx231xx-cards.c
index 2a28882..6dbf2da 100644
--- a/drivers/media/video/cx231xx/cx231xx-cards.c
+++ b/drivers/media/video/cx231xx/cx231xx-cards.c
@@ -858,10 +858,9 @@ void cx231xx_release_resources(struct cx231xx *dev)
  * cx231xx_init_dev()
  * allocates and inits the device structs, registers i2c bus and v4l device
  */
-static int cx231xx_init_dev(struct cx231xx **devhandle, struct usb_device 
*udev,
+static int cx231xx_init_dev(struct cx231xx *dev, struct usb_device *udev,
int minor)
 {
-   struct cx231xx *dev = *devhandle;
int retval = -ENOMEM;
int errCode;
unsigned int maxh, maxw;
@@ -1144,7 +1143,7 @@ static int cx231xx_usb_probe(struct usb_interface 
*interface,
return -EIO;
}
/* allocate device struct */
-   retval = cx231xx_init_dev(dev, udev, nr);
+   retval = cx231xx_init_dev(dev, udev, nr);
if (retval) {
cx231xx_devused = ~(1  dev-devno);
v4l2_device_unregister(dev-v4l2_dev);
-- 
1.7.4.1

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

[PATCH 1/4] cx231xx: use URB_NO_TRANSFER_DMA_MAP on URBs allocated with usb_alloc_urb()

2012-01-07 Thread Thomas Petazzoni 
URBs allocated with usb_alloc_urb() are allocated from DMA-coherent
areas, and therefore it is not necessary to call dma_map_single() on
such buffers. Worst, on ARM, calling dma_map_single() on a
DMA-coherent buffer will trigger a BUG_ON() in
arch/arm/mm/dma-mapping.c.

Therefore, we mark all URBs allocated with usb_alloc_urb() with the
URB_NO_TRANSFER_DMA_MAP transfer_flags, so that the USB core does not
do dma_map_single()/dma_unmap_single() on those buffers.

This is similar to 882787ff8fdeb0be790547ee9b22b281095e95da for the
gspca driver, and has already been discussed on the linux-media list
in the past:
http://www.mail-archive.com/linux-media@vger.kernel.org/msg37086.html.

Signed-off-by: Thomas Petazzoni thomas.petazz...@free-electrons.com
---
 drivers/media/video/cx231xx/cx231xx-audio.c |4 ++--
 drivers/media/video/cx231xx/cx231xx-core.c  |4 ++--
 drivers/media/video/cx231xx/cx231xx-vbi.c   |2 +-
 3 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/media/video/cx231xx/cx231xx-audio.c 
b/drivers/media/video/cx231xx/cx231xx-audio.c
index 30d13c1..e0b2d5c 100644
--- a/drivers/media/video/cx231xx/cx231xx-audio.c
+++ b/drivers/media/video/cx231xx/cx231xx-audio.c
@@ -298,7 +298,7 @@ static int cx231xx_init_audio_isoc(struct cx231xx *dev)
urb-context = dev;
urb-pipe = usb_rcvisocpipe(dev-udev,
dev-adev.end_point_addr);
-   urb-transfer_flags = URB_ISO_ASAP;
+   urb-transfer_flags = URB_ISO_ASAP | URB_NO_TRANSFER_DMA_MAP;
urb-transfer_buffer = dev-adev.transfer_buffer[i];
urb-interval = 1;
urb-complete = cx231xx_audio_isocirq;
@@ -356,7 +356,7 @@ static int cx231xx_init_audio_bulk(struct cx231xx *dev)
urb-context = dev;
urb-pipe = usb_rcvbulkpipe(dev-udev,
dev-adev.end_point_addr);
-   urb-transfer_flags = 0;
+   urb-transfer_flags = URB_NO_TRANSFER_DMA_MAP;
urb-transfer_buffer = dev-adev.transfer_buffer[i];
urb-complete = cx231xx_audio_bulkirq;
urb-transfer_buffer_length = sb_size;
diff --git a/drivers/media/video/cx231xx/cx231xx-core.c 
b/drivers/media/video/cx231xx/cx231xx-core.c
index d4457f9..d4527f2 100644
--- a/drivers/media/video/cx231xx/cx231xx-core.c
+++ b/drivers/media/video/cx231xx/cx231xx-core.c
@@ -1071,7 +1071,7 @@ int cx231xx_init_isoc(struct cx231xx *dev, int 
max_packets,
 sb_size, cx231xx_isoc_irq_callback, dma_q, 1);
 
urb-number_of_packets = max_packets;
-   urb-transfer_flags = URB_ISO_ASAP;
+   urb-transfer_flags = URB_ISO_ASAP | URB_NO_TRANSFER_DMA_MAP;
 
k = 0;
for (j = 0; j  max_packets; j++) {
@@ -1182,7 +1182,7 @@ int cx231xx_init_bulk(struct cx231xx *dev, int 
max_packets,
return -ENOMEM;
}
dev-video_mode.bulk_ctl.urb[i] = urb;
-   urb-transfer_flags = 0;
+   urb-transfer_flags = URB_NO_TRANSFER_DMA_MAP;
 
dev-video_mode.bulk_ctl.transfer_buffer[i] =
usb_alloc_coherent(dev-udev, sb_size, GFP_KERNEL,
diff --git a/drivers/media/video/cx231xx/cx231xx-vbi.c 
b/drivers/media/video/cx231xx/cx231xx-vbi.c
index 1c7a4da..852878d 100644
--- a/drivers/media/video/cx231xx/cx231xx-vbi.c
+++ b/drivers/media/video/cx231xx/cx231xx-vbi.c
@@ -452,7 +452,7 @@ int cx231xx_init_vbi_isoc(struct cx231xx *dev, int 
max_packets,
return -ENOMEM;
}
dev-vbi_mode.bulk_ctl.urb[i] = urb;
-   urb-transfer_flags = 0;
+   urb-transfer_flags = URB_NO_TRANSFER_DMA_MAP;
 
dev-vbi_mode.bulk_ctl.transfer_buffer[i] =
kzalloc(sb_size, GFP_KERNEL);
-- 
1.7.4.1

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

[PATCH] em28xx: simplify argument passing to em28xx_init_dev()

2012-01-07 Thread Thomas Petazzoni 
The 'struct em28xx *' pointer was passed by reference to the
em28xx_init_dev() function, for no reason. Instead, just pass it by
value, which is much more logical and simple.

Signed-off-by: Thomas Petazzoni thomas.petazz...@free-electrons.com
---
 drivers/media/video/em28xx/em28xx-cards.c |5 ++---
 1 files changed, 2 insertions(+), 3 deletions(-)

diff --git a/drivers/media/video/em28xx/em28xx-cards.c 
b/drivers/media/video/em28xx/em28xx-cards.c
index 9b747c2..789054d 100644
--- a/drivers/media/video/em28xx/em28xx-cards.c
+++ b/drivers/media/video/em28xx/em28xx-cards.c
@@ -2832,11 +2832,10 @@ void em28xx_release_resources(struct em28xx *dev)
  * em28xx_init_dev()
  * allocates and inits the device structs, registers i2c bus and v4l device
  */
-static int em28xx_init_dev(struct em28xx **devhandle, struct usb_device *udev,
+static int em28xx_init_dev(struct em28xx *dev, struct usb_device *udev,
   struct usb_interface *interface,
   int minor)
 {
-   struct em28xx *dev = *devhandle;
int retval;
 
dev-udev = udev;
@@ -3226,7 +3225,7 @@ static int em28xx_usb_probe(struct usb_interface 
*interface,
/* allocate device struct */
mutex_init(dev-lock);
mutex_lock(dev-lock);
-   retval = em28xx_init_dev(dev, udev, interface, nr);
+   retval = em28xx_init_dev(dev, udev, interface, nr);
if (retval) {
mutex_unlock(dev-lock);
kfree(dev-alt_max_pkt_size);
-- 
1.7.4.1

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

Re: cx231xx: possible circular locking dependency detected on 3.2

2012-01-07 Thread Thomas Petazzoni 
Le Fri, 6 Jan 2012 22:42:31 +0100,
Thomas Petazzoni thomas.petazz...@free-electrons.com a écrit :

 Hello,
 
 I'm running the Hauppauge USB-Live 2 device on an ARM OMAP3 platform.
 After loading the cx231xx driver and launching v4l2grab, I immediately
 get:
 
 [  407.087158] cx231xx #0:  setPowerMode::mode = 48, No Change req.
 [  407.145477] 
 [  407.147064] ==
 [  407.153533] [ INFO: possible circular locking dependency detected ]
 [  407.160095] 3.2.0-7-gb928298 #18
 [  407.163848] ---

One code path is (mmap_sem taken before, video_device lock taken
afterwards) :

 - sys_mmap_pgoff()
grabs current-mm-mmap_sem at
http://lxr.free-electrons.com/source/mm/mmap.c#L

- do_mmap_pgoff()

   - mmap_region()

  - v4l2_mmap()
 grabs struct video_device-lock at 
 
http://lxr.free-electrons.com/source/drivers/media/video/v4l2-dev.c#L396

The other code path is (video_device taken first, mmap_sem taken
afterwards) :

 - v4l2_ioctl()
grabs video_device-lock at
http://lxr.free-electrons.com/source/drivers/media/video/v4l2-dev.c#L327

- video_ioctl2()

   - video_usercopy()

  - __video_do_ioctl()

 - videobuf_qbuf()
grabs current-mm-mmap_sem at

http://lxr.free-electrons.com/source/drivers/media/video/videobuf-core.c#L537

Regards,

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.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

cx231xx: possible circular locking dependency detected on 3.2

2012-01-06 Thread Thomas Petazzoni 
Hello,

I'm running the Hauppauge USB-Live 2 device on an ARM OMAP3 platform.
After loading the cx231xx driver and launching v4l2grab, I immediately
get:

[  407.087158] cx231xx #0:  setPowerMode::mode = 48, No Change req.
[  407.145477] 
[  407.147064] ==
[  407.153533] [ INFO: possible circular locking dependency detected ]
[  407.160095] 3.2.0-7-gb928298 #18
[  407.163848] ---
[  407.170410] v4l2grab/680 is trying to acquire lock:
[  407.175537]  (mm-mmap_sem){++}, at: [bf03e10c] 
videobuf_qbuf+0x298/0x48c [videobuf_core]
[  407.184783] 
[  407.184783] but task is already holding lock:
[  407.190887]  (dev-lock#2){+.+.+.}, at: [bf00e47c] v4l2_ioctl+0xec/0x150 
[videodev]
[  407.199249] 
[  407.199249] which lock already depends on the new lock.
[  407.199249] 
[  407.207824] 
[  407.207824] the existing dependency chain (in reverse order) is:
[  407.215667] 
[  407.215667] - #1 (dev-lock#2){+.+.+.}:
[  407.221435][c008bac8] lock_acquire+0x98/0x100
[  407.226928][c0471594] mutex_lock_interruptible_nested+0x4c/0x37c
[  407.234161][bf00e378] v4l2_mmap+0x94/0xac [videodev]
[  407.240295][c00eee5c] mmap_region+0x2d4/0x468
[  407.245788][c00ef3a0] sys_mmap_pgoff+0x78/0xc0
[  407.251342][c0013b00] ret_fast_syscall+0x0/0x3c
[  407.257019] 
[  407.257019] - #0 (mm-mmap_sem){++}:
[  407.262878][c008b3f0] __lock_acquire+0x1d04/0x1d94
[  407.268829][c008bac8] lock_acquire+0x98/0x100
[  407.274291][c04726cc] down_read+0x2c/0x3c
[  407.279418][bf03e10c] videobuf_qbuf+0x298/0x48c [videobuf_core]
[  407.286529][bf00fbf4] __video_do_ioctl+0x500/0x55a8 [videodev]
[  407.293579][bf00f2d0] video_usercopy+0x128/0x4d8 [videodev]
[  407.300354][bf00e418] v4l2_ioctl+0x88/0x150 [videodev]
[  407.306671][c0112cd4] do_vfs_ioctl+0x7c/0x584
[  407.312164][c0113250] sys_ioctl+0x74/0x7c
[  407.317260][c0013b00] ret_fast_syscall+0x0/0x3c
[  407.322937] 
[  407.322937] other info that might help us debug this:
[  407.322937] 
[  407.331329]  Possible unsafe locking scenario:
[  407.331329] 
[  407.337524]CPU0CPU1
[  407.342285]
[  407.347015]   lock(dev-lock);
[  407.350311]lock(mm-mmap_sem);
[  407.356536]lock(dev-lock);
[  407.362457]   lock(mm-mmap_sem);
[  407.366027] 
[  407.366027]  *** DEADLOCK ***
[  407.366027] 
[  407.372253] 1 lock held by v4l2grab/680:
[  407.376342]  #0:  (dev-lock#2){+.+.+.}, at: [bf00e47c] 
v4l2_ioctl+0xec/0x150 [videodev]
[  407.385162] 
[  407.385162] stack backtrace:
[  407.389739] [c001b3b0] (unwind_backtrace+0x0/0xf0) from [c0087c04] 
(print_circular_bug+0x1d4/0x2f0)
[  407.399597] [c0087c04] (print_circular_bug+0x1d4/0x2f0) from [c008b3f0] 
(__lock_acquire+0x1d04/0x1d94)
[  407.409729] [c008b3f0] (__lock_acquire+0x1d04/0x1d94) from [c008bac8] 
(lock_acquire+0x98/0x100)
[  407.419219] [c008bac8] (lock_acquire+0x98/0x100) from [c04726cc] 
(down_read+0x2c/0x3c)
[  407.427886] [c04726cc] (down_read+0x2c/0x3c) from [bf03e10c] 
(videobuf_qbuf+0x298/0x48c [videobuf_core])
[  407.438201] [bf03e10c] (videobuf_qbuf+0x298/0x48c [videobuf_core]) from 
[bf00fbf4] (__video_do_ioctl+0x500/0x55a8 [videodev])
[  407.450469] [bf00fbf4] (__video_do_ioctl+0x500/0x55a8 [videodev]) from 
[bf00f2d0] (video_usercopy+0x128/0x4d8 [videodev])
[  407.462341] [bf00f2d0] (video_usercopy+0x128/0x4d8 [videodev]) from 
[bf00e418] (v4l2_ioctl+0x88/0x150 [videodev])
[  407.473480] [bf00e418] (v4l2_ioctl+0x88/0x150 [videodev]) from 
[c0112cd4] (do_vfs_ioctl+0x7c/0x584)
[  407.483337] [c0112cd4] (do_vfs_ioctl+0x7c/0x584) from [c0113250] 
(sys_ioctl+0x74/0x7c)
[  407.492004] [c0113250] (sys_ioctl+0x74/0x7c) from [c0013b00] 
(ret_fast_syscall+0x0/0x3c)
[  407.500915] cx231xx #0: cx231xx_stop_stream():: ep_mask = 8

Best regards,

Thomas Petazzoni
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.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: EasyCAP with identifiers

2011-12-22 Thread Thomas Petazzoni 
Hello,

Le Wed, 21 Dec 2011 13:14:55 -0500,
Full Name danew...@excite.com a écrit :

 I just got an EasyCAP usb device with component and S-video inputs, and it 
 doesn't match what I was expecting from reading lists about drivers.

Be careful, there are several devices that the commercial name
EasyCAP but that internally aren't the same thing. We had the
experience of a device labelled EasyCAP, which was working fine with
the easycap driver in drivers/staging. We bought another one from
Amazon, also labeled EasyCAP, and even though it looked exactly the
same externally, the hardware inside is completely different and is not
supported by the easycap driver in drivers/staging.

Regards,

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.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: cx231xx: DMA problem on ARM

2011-09-26 Thread Thomas Petazzoni 
Hello Mauro,

Le Fri, 23 Sep 2011 23:15:54 -0300,
Mauro Carvalho Chehab mche...@redhat.com a écrit :

  And still the result is the same: we get a first frame, and then
  nothing more, and we have a large number of error messages in the
  kernel logs.
 
 I don't think that this is related to the power manager anymore. It can
 be related to cache coherency and/or to iommu support.

As you suspected, increasing PWR_SLEEP_INTERVAL didn't change anything.
What do you suggest to track down the potential cache coherency issues ?

Best regards,

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.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: cx231xx: DMA problem on ARM

2011-09-26 Thread Thomas Petazzoni 
Hello Laurent,

Le Mon, 26 Sep 2011 21:02:48 +0200,
Laurent Pinchart laurent.pinch...@ideasonboard.com a écrit :

 Are you using the MMAP or USERPTR capture method ? If using MMAP, can
 you try (as a test only) to unmap the buffer before queueing it and
 to remap it after dequeuing it ?

So far, we have used VLC, Cheese, or a simple OpenCV based application
to test the V4L2 device on our ARM platform, and I have no idea which
capture method those are using. Is there a very simple V4L test
application that we could use to hack the buffer unmap/remap trick
you're suggesting as a test ?

Regards,

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.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: cx231xx: DMA problem on ARM

2011-09-23 Thread Thomas Petazzoni 
Hello Devin,

Le Thu, 22 Sep 2011 17:29:29 +0200,
Thomas Petazzoni thomas.petazz...@free-electrons.com a écrit :

 I guess you're talking about 44ecf1df9493e6684cd1bb34abb107a0ffe1078a,
 which ensures a 10ms msleep call. We don't have this patch, but as with
 CONFIG_HZ=100, msleep() calls are anyway rounded up to 10ms, so I'm not
 sure this patch will have a huge impact. But we will try.
 
 Then, there is also de99d5328c6d54694471da28711a05adec708c3b, but it
 doesn't seem to be related to our problem. But we will also try with
 that one.

So, we have now tried with Linux 3.0 and the following additional
patches:

 * 992299e84a4891275ea5924e30b66ce39a701e5e (Fix regression
   introduced which broke the Hauppauge USBLive 2)
 * 44ecf1df9493e6684cd1bb34abb107a0ffe1078a (cx231xx: Fix power ramping
   issue)
 * de99d5328c6d54694471da28711a05adec708c3b (cx231xx: Provide
   signal lock status in G_INPUT)
 * the DMA fix

And still the result is the same: we get a first frame, and then
nothing more, and we have a large number of error messages in the
kernel logs.

[   18.833587] cx231xx v4l2 driver loaded.
[   18.833831] cx231xx #0: New device Hauppauge Hauppauge Device @ 480 Mbps 
(2040:c200) with 5 interfaces
[   18.833862] cx231xx #0: registering interface 1
[   18.854492] cx231xx #0: can't change interface 3 alt no. to 3: Max. Pkt size 
= 0
[   19.185943] cx231xx #0: can't change interface 4 alt no. to 1: Max. Pkt size 
= 0
[   19.405700] cx231xx #0: Identified as Hauppauge USB Live 2 (card=9)
[   19.692993] cx231xx #0: cx231xx_dif_set_standard: setStandard to 
[   20.238159] cx25840 4-0044: cx23102 A/V decoder found @ 0x88 (cx231xx #0)
[   20.333740] cx25840 4-0044:  Firmware download size changed to 16 bytes max 
length
[   21.783569] smsc95xx 1-2.1:1.0: eth0: link up, 100Mbps, full-duplex, lpa 
0xC5E1
[   22.921936] cx25840 4-0044: loaded v4l-cx231xx-avcore-01.fw firmware (16382 
bytes)
[   22.960815] cx231xx #0: cx231xx #0: v4l2 driver version 0.0.1
[   22.989715] cx231xx #0: cx231xx_dif_set_standard: setStandard to 
[   23.042663] cx231xx #0: video_mux : 0
[   23.042694] cx231xx #0: do_mode_ctrl_overrides : 0xb000
[   23.043548] cx231xx #0: do_mode_ctrl_overrides NTSC
[   23.056213] cx231xx #0: cx231xx #0/0: registered device video0 [v4l2]
[   23.061035] cx231xx #0: cx231xx #0/0: registered device vbi0
[   23.061065] cx231xx #0: V4L2 device registered as video0 and vbi0
[   23.061096] cx231xx #0: EndPoint Addr 0x84, Alternate settings: 5
[   23.061096] cx231xx #0: Alternate setting 0, max size= 512
[   23.061126] cx231xx #0: Alternate setting 1, max size= 184
[   23.061126] cx231xx #0: Alternate setting 2, max size= 728
[   23.061157] cx231xx #0: Alternate setting 3, max size= 2892
[   23.061157] cx231xx #0: Alternate setting 4, max size= 1800
[   23.061187] cx231xx #0: EndPoint Addr 0x85, Alternate settings: 2
[   23.061187] cx231xx #0: Alternate setting 0, max size= 512
[   23.061218] cx231xx #0: Alternate setting 1, max size= 512
[   23.061218] cx231xx #0: EndPoint Addr 0x86, Alternate settings: 2
[   23.061248] cx231xx #0: Alternate setting 0, max size= 512
[   23.061248] cx231xx #0: Alternate setting 1, max size= 576
[   23.067108] usbcore: registered new interface driver cx231xx
[   23.360412] cx231xx #0:  setPowerMode::mode = 48, No Change req.
[   23.365905] cx231xx #0: cx231xx_stop_stream():: ep_mask = 8
[   23.367156] cx231xx #0: cx231xx_stop_stream():: ep_mask = 8
[   23.872253] cx231xx #0: cx231xx-audio.c: probing for cx231xx non standard 
usbaudio
[   23.875762] cx231xx #0: EndPoint Addr 0x83, Alternate settings: 3
[   23.875793] cx231xx #0: Alternate setting 0, max size= 512
[   23.875793] cx231xx #0: Alternate setting 1, max size= 28
[   23.875823] cx231xx #0: Alternate setting 2, max size= 52
[   23.875823] cx231xx: Cx231xx Audio Extension initialized
[   24.794891] lp: driver loaded but no devices found
[   24.880157] ppdev: user-space parallel port driver
[   30.872589] eth0: no IPv6 routers present
[  183.789154] omap_device: omap-mcbsp.2: new worst case activate latency 0: 
30517
[  183.829803] omap_device: omap-mcbsp.2: new worst case deactivate latency 0: 
30517
[  184.355712] omap_device: omap-mcbsp.2: new worst case deactivate latency 0: 
61035
[  186.400878] cx231xx #0: cx231xx_start_stream():: ep_mask = 4
[  186.401855] cx231xx #0: cx231xx_stop_stream():: ep_mask = 4
[  186.404571] cx231xx #0: cx231xx_start_stream():: ep_mask = 4
[  186.405578] cx231xx #0: cx231xx_stop_stream():: ep_mask = 4
[  186.408050] cx231xx #0: cx231xx_start_stream():: ep_mask = 4
[  186.409332] cx231xx #0: cx231xx_stop_stream():: ep_mask = 4
[  186.412109] cx231xx #0: cx231xx_start_stream():: ep_mask = 4
[  186.414306] cx231xx #0: cx231xx_stop_stream():: ep_mask = 4
[  186.416961] cx231xx #0: cx231xx_start_stream():: ep_mask = 4
[  186.418060] cx231xx #0: cx231xx_stop_stream():: ep_mask = 4
[  186.427520] cx231xx #0: cx231xx_start_stream():: ep_mask = 4
[  186.498504] cx231xx #0

Re: cx231xx: DMA problem on ARM

2011-09-22 Thread Thomas Petazzoni 
Le Thu, 22 Sep 2011 11:09:22 -0400,
Devin Heitmueller dheitmuel...@kernellabs.com a écrit :

 Ok, that is a good start.  I would definitely submit that as a patch
 (including your Signed-off-by line).

Sure, we will definitely do this.

 Regarding the outstanding issue, I believe I did see that and fixed
 it.  Please look the history for the various cx231xx files surrounding
 the time of the .dont_use_port_3 = 1 fix.  If I recall, that patch
 was actually part of a series of two or three patches which were
 required for that device to work properly.  I believe the other patch
 needed included an extra 10ms msleep call to ensure the hardware is
 powered up fully before issuing certain i2c commands (which are what
 are causing the -71 errors).

I guess you're talking about 44ecf1df9493e6684cd1bb34abb107a0ffe1078a,
which ensures a 10ms msleep call. We don't have this patch, but as with
CONFIG_HZ=100, msleep() calls are anyway rounded up to 10ms, so I'm not
sure this patch will have a huge impact. But we will try.

Then, there is also de99d5328c6d54694471da28711a05adec708c3b, but it
doesn't seem to be related to our problem. But we will also try with
that one.

 If you cannot find it, let me know and I will dig around my archives
 and find it for you (I'm actually at work right now so it would be
 inopportune for me to do it right this minute).

 :-)

Thanks for your very quick feedback!

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.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

cx231xx: DMA problem on ARM

2011-09-21 Thread Thomas Petazzoni 
Hello,

On an x86 platform, we have managed to use a Hauppauge USB Live 2
capture device with the cx231xx on a 3.0 kernel with the patch at [1].
Things work nicely.

However, using a similar 3.0 kernel with the exact same device on an
ARM platform (BeagleBoard-XM), starting a V4L application to capture
the video immediately triggers the following BUG_ON in
arch/arm/mm/dma-mapping.c:

429 void ___dma_single_cpu_to_dev(const void *kaddr, size_t size,
430 enum dma_data_direction dir)
431 {
432 unsigned long paddr;
433 
434 BUG_ON(!virt_addr_valid(kaddr) || !virt_addr_valid(kaddr + size - 
1));

This problem looks similar to the problem fixed on the gspca driver by:

commit 882787ff8fdeb0be790547ee9b22b281095e95da
Author: Jason Wang jason77.w...@gmail.com
Date:   Fri Sep 3 06:57:19 2010 -0300

V4L/DVB: gspca - main: Fix a crash of some webcams on ARM arch

When plugging some webcams on ARM, the system crashes.
This is because we alloc buffer for an urb through usb_buffer_alloc,
the alloced buffer is already in DMA coherent region, so we should
set the flag of this urb to URB_NO_TRANSFER_DMA_MAP, otherwise when
we submit this urb, the hcd core will handle this address as an
non-DMA address and call dma_map_single/sg to map it. On arm
architecture, dma_map_single a DMA coherent address will be catched
by a BUG_ON().

Signed-off-by: Jason Wang jason77.w...@gmail.com
Signed-off-by: Jean-François Moine moin...@free.fr
Cc: sta...@kernel.org
Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com

I guess the cx231xx driver is trying to DMA-map buffers whose location
is not appropriate for DMA-mapping, because they are already in an DMA
coherent region. Is the fix just to add the same
URB_NO_TRANSFER_DMA_MAP to the urb-transfer_flags ? Or is it something
completely different ?

Thanks!

Thomas

[1]
https://github.com/torvalds/linux/commit/992299e84a4891275ea5924e30b66ce39a701e5e#drivers/media/video/cx231xx
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.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: cx231xx: DMA problem on ARM

2011-09-21 Thread Thomas Petazzoni 
Hello Devin,

Thanks for your quick reply.

Le Wed, 21 Sep 2011 08:04:52 -0400,
Devin Heitmueller dheitmuel...@kernellabs.com a écrit :

 I ran into the same issue on em28xx in the past (which is what those
 parts of cx231xx are based on).  Yes, just adding
 URB_NO_TRANSFER_DMA_MAP should result in it starting to work.  Please
 try that out, and assuming it works feel free to submit a patch which
 can be included upstream.

Ok, we'll try this out and report the results, and if those are
positive, the corresponding patch.

Regards,

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.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: Using atmel-isi for direct output on framebuffer ?

2011-09-02 Thread Thomas Petazzoni 
Hello Josh,

Le Fri, 2 Sep 2011 17:08:32 +0800,
Wu, Josh josh...@atmel.com a écrit :

 My understanding is that you want to use Atmel ISI to output RGB data
 then work with framebuffer. So yes, it is possible.

Good.

 Since current atmel_isi.c only uses its codec path to output YUV
 data. So first need add RGB format support in
 isi_camera_get_formats(). Then you have two choices to enable RGB
 output of ISI: 1. Enable isi's preview path(DMA, interrupts) to
 convert YUV to RGB. 2. Or still use codec path but don't need add
 much ISI code, just set camera sensor(if it support RGB565 output) to
 output RGB565 data for ISI, then what the data ISI output now should
 be RGB565 format. But in this way you cannot do any scale.

Doing the YUV - RGB within the V4L2 driver is something I understand
quite well. The part I miss is how the V4L2 driver interacts with the
framebuffer driver to output the camera image into the framebuffer.

 For V4L2_CAP_VIDEO_OVERLAY type driver, I don't know much about that.

Hum, ok, found http://v4l2spec.bytesex.org/spec/x6570.htm which seems
to explain a bit the userspace interface for this.

Thanks for your feedback!

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.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: Using atmel-isi for direct output on framebuffer ?

2011-09-02 Thread Thomas Petazzoni 
Hi Laurent,

Le Fri, 2 Sep 2011 13:42:03 +0200,
Laurent Pinchart laurent.pinch...@ideasonboard.com a écrit :

 I'm not sure if V4L2_CAP_VIDEO_OVERLAY is a good solution for this.
 This driver type (or rather buffer type) was used on old systems to
 capture directly to the PCI graphics card memory. Nowadays I would
 advice using USERPTR with framebuffer memory.

Could you give a short summary of how the USERPTR mechanism works?

Thanks,

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.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

Using atmel-isi for direct output on framebuffer ?

2011-09-01 Thread Thomas Petazzoni 
Hello Josh,

I am currently looking at V4L2 and your atmel-isi driver for an AT91
based platform on which I would like the ISI interface to capture the
image from a camera and have this image directly output in RGB format
at a specific location on the screen (so that it can be nicely
integrated into a Qt application for example).

At the moment, I grab frames from the V4L2 device to userspace, do the
YUV - RGB conversion manually in my application, and then displays the
converted frame on the framebuffer thanks to normal Qt painting
mechanisms. This works, but obviously consumes a lot of CPU.

From the AT91 datasheet, I understand that the ISI interface is capable
of doing the YUV - RGB conversion and is also capable of outputting
the frame at some location in the framebuffer, but I don't see how to
use this capability with the Linux V4L2 and framebuffer infrastructures.

Is this possible ? If so, could you provide some pointers or starting
points to get me started ? If not, what is missing in the driver ?

Thanks a lot,

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.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