Re: Driver/module in kernel fault. Anyone expert to help me? Siano ID 187f:0600

2015-01-14 Thread Francesco Other 
Hi Roberto,

It doesn't record anything, the file is blank (0 bytes) :-(

$ dd if=/dev/dvb/adapter0/dvr0 of=test.ts

0+0 records in
0+0 records out
0 bytes (0 B) copied, 13,4642 s, 0,0 kB/s

Francesco


2015-01-14 16:58 GMT+01:00 Roberto Alcântara robe...@eletronica.org:
 Francesco,

 Seems very strange not work once you have lock (1f) and ber 0. not a
 real problem signal report.

 After tzap -r open another console and:

 dd if=/dev/dvb/adapter0/dvr0 of=test.ts

 Wait 10 seconds and stop it. Please check file size (try to open on
 vlc too if big enough...).

 Cheers,
  - Roberto

 On Tue, Jan 13, 2015 at 6:56 PM, Francesco Other
 francesco.ot...@gmail.com wrote:


 So, this is the output for tzap with the NOT-working-device:

 $ tzap -r -c ~/.tzap/channels.conf Italia1
 using '/dev/dvb/adapter0/frontend0' and '/dev/dvb/adapter0/demux0'
 reading channels from file '/home/ionic/.tzap/channels.conf'
 Version: 5.10   FE_CAN { DVB-T }
 tuning to 69800 Hz
 video pid 0x0654, audio pid 0x0655
 status 00 | signal  | snr  | ber  | unc  |
 status 1f | signal  | snr 0104 | ber  | unc  | 
 FE_HAS_LOCK
 status 1f | signal  | snr 0104 | ber  | unc  | 
 FE_HAS_LOCK
 status 1f | signal  | snr 0104 | ber  | unc  | 
 FE_HAS_LOCK
 status 1f | signal  | snr 0104 | ber  | unc  | 
 FE_HAS_LOCK
 status 1f | signal  | snr 0104 | ber  | unc  | 
 FE_HAS_LOCK
 status 1f | signal  | snr 010e | ber  | unc  | 
 FE_HAS_LOCK
 status 1f | signal  | snr 0104 | ber  | unc  | 
 FE_HAS_LOCK
 status 1f | signal  | snr 010e | ber  | unc  | 
 FE_HAS_LOCK
 status 1f | signal  | snr 0104 | ber  | unc  | 
 FE_HAS_LOCK




  - Roberto
--
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] staging: davinci_vpfe: fix space prohibited before semicolon warning

2015-01-14 Thread Aya Mahfouz 
This patch fixes the following checkpatch.pl warning:

space prohibited before semicolon

Signed-off-by: Aya Mahfouz mahfouz.saif.elya...@gmail.com
---
v1: This patch applies to Greg's tree.

 drivers/staging/media/davinci_vpfe/dm365_ipipe.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/staging/media/davinci_vpfe/dm365_ipipe.c 
b/drivers/staging/media/davinci_vpfe/dm365_ipipe.c
index 704fa20..a425f71 100644
--- a/drivers/staging/media/davinci_vpfe/dm365_ipipe.c
+++ b/drivers/staging/media/davinci_vpfe/dm365_ipipe.c
@@ -901,7 +901,7 @@ static int ipipe_set_gbce_params(struct vpfe_ipipe_device 
*ipipe, void *param)
struct device *dev = ipipe-subdev.v4l2_dev-dev;
 
if (!gbce_param) {
-   memset(gbce, 0 , sizeof(struct vpfe_ipipe_gbce));
+   memset(gbce, 0, sizeof(struct vpfe_ipipe_gbce));
} else {
memcpy(gbce, gbce_param, sizeof(struct vpfe_ipipe_gbce));
if (ipipe_validate_gbce_params(gbce)  0) {
@@ -1086,7 +1086,7 @@ static int ipipe_set_car_params(struct vpfe_ipipe_device 
*ipipe, void *param)
struct vpfe_ipipe_car *car = ipipe-config.car;
 
if (!car_param) {
-   memset(car , 0, sizeof(struct vpfe_ipipe_car));
+   memset(car, 0, sizeof(struct vpfe_ipipe_car));
} else {
memcpy(car, car_param, sizeof(struct vpfe_ipipe_car));
if (ipipe_validate_car_params(car)  0) {
-- 
1.9.3

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

[GIT PULL] rtl28xxu / rtl2830 / rtl2832 / rtl2832_sdr changes

2015-01-14 Thread Antti Palosaari 

The following changes since commit cb9564e133f4f790920d715714790512085bb2e3:

  [media] rc: img-ir: add philips rc6 decoder module (2014-12-23 
15:17:31 -0200)


are available in the git repository at:

  git://linuxtv.org/anttip/media_tree.git rtl28xx

for you to fetch changes up to 6fbbe5eee8bda5642a884180216ef498bc46d18f:

  rtl2832: implement own lock for regmap (2014-12-23 22:48:29 +0200)


Antti Palosaari (66):
  dvb-usb-v2: add pointer to 'struct usb_interface' for driver usage
  rtl2832: convert driver to I2C binding
  rtl28xxu: switch rtl2832 demod attach to I2C binding
  rtl28xxu: change module unregister order
  rtl2830: convert driver to kernel I2C model
  rtl28xxu: use I2C binding for RTL2830 demod driver
  rtl2830: get rid of legacy DVB driver binding
  rtl2830: rename 'priv' to 'dev'
  rtl2830: carry pointer to I2C client for every function
  rtl2830: fix logging
  rtl2830: get rid of internal config data
  rtl2830: style related changes
  rtl2830: implement DVBv5 CNR statistic
  rtl2830: implement DVBv5 signal strength statistics
  rtl2830: implement DVBv5 BER statistic
  rtl2830: wrap DVBv5 signal strength to DVBv3
  rtl2830: wrap DVBv5 BER to DVBv3
  rtl2830: wrap DVBv5 CNR to DVBv3 SNR
  rtl2830: implement PID filter
  rtl28xxu: add support for RTL2831U/RTL2830 PID filter
  rtl2830: implement own I2C locking
  rtl2830: convert to regmap API
  rtl2832: add platform data callbacks for exported resources
  rtl28xxu: use rtl2832 demod callbacks accessing its resources
  rtl2832: remove exported resources
  rtl2832: rename driver state variable from 'priv' to 'dev'
  rtl2832: enhance / fix logging
  rtl2832: move all configuration to platform data struct
  rtl28xxu: use platform data config for rtl2832 demod
  rtl2832: convert to regmap API
  rtl2832: implement DVBv5 CNR statistic
  rtl2832: implement DVBv5 BER statistic
  rtl2832: wrap DVBv5 CNR to DVBv3 SNR
  rtl2832: wrap DVBv5 BER to DVBv3
  rtl2832: implement DVBv5 signal strength statistics
  rtl28xxu: use demod mux I2C adapter for every tuner
  rtl2832: drop FE i2c gate control support
  rtl2832: define more demod lock statuses
  rtl2832: implement PID filter
  rtl28xxu: add support for RTL2832U/RTL2832 PID filter
  rtl2832: use regmap reg cache
  rtl2832: remove unneeded software reset from init()
  rtl2832: merge reg page as a part of reg address
  rtl2832: provide register IO callbacks
  rtl2832_sdr: rename state variable from 's' to 'dev'
  rtl2832_sdr: convert to platform driver
  rtl28xxu: switch SDR module to platform driver
  rtl28xxu: use master I2C adapter for slave demods
  rtl2832_sdr: fix logging
  rtl2832_sdr: cleanups
  rtl2832: cleanups and minor changes
  rtl2832: claim copyright and module author
  rtl2832: implement sleep
  rtl28xxu: fix DVB FE callback
  rtl28xxu: simplify FE callback handling
  rtl28xxu: do not refcount rtl2832_sdr module
  rtl2832_sdr: refcount to rtl28xxu
  rtl2832: remove internal mux I2C adapter
  rtl28xxu: rename state variable 'priv' to 'dev'
  rtl28xxu: fix logging
  rtl28xxu: move usb buffers to state
  rtl28xxu: add heuristic to detect chip type
  rtl28xxu: merge chip type specific all callbacks
  rtl28xxu: merge rtl2831u and rtl2832u properties
  rtl28xxu: correct reg access routine name prefixes
  rtl2832: implement own lock for regmap

 drivers/media/dvb-frontends/Kconfig |4 +-
 drivers/media/dvb-frontends/rtl2830.c   |  944 
---

 drivers/media/dvb-frontends/rtl2830.h   |   54 ++-
 drivers/media/dvb-frontends/rtl2830_priv.h  |   24 +--
 drivers/media/dvb-frontends/rtl2832.c   | 1341 
+++---

 drivers/media/dvb-frontends/rtl2832.h   |   88 +++
 drivers/media/dvb-frontends/rtl2832_priv.h  |   32 ++--
 drivers/media/dvb-frontends/rtl2832_sdr.c   | 1189 
++--

 drivers/media/dvb-frontends/rtl2832_sdr.h   |   51 +++---
 drivers/media/usb/dvb-usb-v2/dvb_usb.h  |2 +
 drivers/media/usb/dvb-usb-v2/dvb_usb_core.c |1 +
 drivers/media/usb/dvb-usb-v2/rtl28xxu.c |  939 
+-

 drivers/media/usb/dvb-usb-v2/rtl28xxu.h |   27 +++-
 13 files changed, 2499 insertions(+), 2197 deletions(-)

--
http://palosaari.fi/
--
To

cron job: media_tree daily build: ERRORS

2015-01-14 Thread Hans Verkuil 
This message is generated daily by a cron job that builds media_tree for
the kernels and architectures in the list below.

Results of the daily build of media_tree:

date:   Thu Jan 15 04:00:14 CET 2015
git branch: test
git hash:   99f3cd52aee21091ce62442285a68873e3be833f
gcc version:i686-linux-gcc (GCC) 4.9.1
sparse version: v0.5.0-41-g6c2d743
smatch version: 0.4.1-3153-g7d56ab3
host hardware:  x86_64
host os:3.18.0-1.slh.1-amd64

linux-git-arm-at91: OK
linux-git-arm-davinci: OK
linux-git-arm-exynos: OK
linux-git-arm-mx: OK
linux-git-arm-omap: OK
linux-git-arm-omap1: OK
linux-git-arm-pxa: OK
linux-git-blackfin: OK
linux-git-i686: OK
linux-git-m32r: OK
linux-git-mips: OK
linux-git-powerpc64: OK
linux-git-sh: OK
linux-git-x86_64: OK
linux-2.6.32.27-i686: OK
linux-2.6.33.7-i686: OK
linux-2.6.34.7-i686: OK
linux-2.6.35.9-i686: OK
linux-2.6.36.4-i686: OK
linux-2.6.37.6-i686: OK
linux-2.6.38.8-i686: OK
linux-2.6.39.4-i686: OK
linux-3.0.60-i686: OK
linux-3.1.10-i686: OK
linux-3.2.37-i686: OK
linux-3.3.8-i686: OK
linux-3.4.27-i686: OK
linux-3.5.7-i686: OK
linux-3.6.11-i686: OK
linux-3.7.4-i686: OK
linux-3.8-i686: OK
linux-3.9.2-i686: ERRORS
linux-3.10.1-i686: ERRORS
linux-3.11.1-i686: ERRORS
linux-3.12.23-i686: ERRORS
linux-3.13.11-i686: ERRORS
linux-3.14.9-i686: ERRORS
linux-3.15.2-i686: OK
linux-3.16-i686: OK
linux-3.17-i686: OK
linux-3.18-i686: OK
linux-2.6.32.27-x86_64: OK
linux-2.6.33.7-x86_64: OK
linux-2.6.34.7-x86_64: OK
linux-2.6.35.9-x86_64: OK
linux-2.6.36.4-x86_64: OK
linux-2.6.37.6-x86_64: OK
linux-2.6.38.8-x86_64: OK
linux-2.6.39.4-x86_64: OK
linux-3.0.60-x86_64: OK
linux-3.1.10-x86_64: OK
linux-3.2.37-x86_64: OK
linux-3.3.8-x86_64: OK
linux-3.4.27-x86_64: OK
linux-3.5.7-x86_64: OK
linux-3.6.11-x86_64: OK
linux-3.7.4-x86_64: OK
linux-3.8-x86_64: OK
linux-3.9.2-x86_64: ERRORS
linux-3.10.1-x86_64: ERRORS
linux-3.11.1-x86_64: ERRORS
linux-3.12.23-x86_64: ERRORS
linux-3.13.11-x86_64: ERRORS
linux-3.14.9-x86_64: ERRORS
linux-3.15.2-x86_64: ERRORS
linux-3.16-x86_64: ERRORS
linux-3.17-x86_64: ERRORS
linux-3.18-x86_64: ERRORS
apps: OK
spec-git: OK
sparse: ERRORS
smatch: ERRORS

Detailed results are available here:

http://www.xs4all.nl/~hverkuil/logs/Thursday.log

Full logs are available here:

http://www.xs4all.nl/~hverkuil/logs/Thursday.tar.bz2

The Media Infrastructure API from this daily build is here:

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

[PATCH] [media] dvb-core: Fix frontend thread serialization

2015-01-14 Thread Byeong-ki Shin 
From 2384c119d04b54e6e6c282a8693246c4e7d1347e Mon Sep 17 00:00:00 2001
From: bk0121.shin bk0121.s...@samsung.com
Date: Wed, 14 Jan 2015 20:35:57 +0900
Subject: [PATCH] [media] dvb-core: Fix frontend thread serialization

dvb_frontend_thread's life cycle is controlled by dvb_frontend_start
and dvb_frontend_release.
But, if user opens frontend device before the thread exits completely,
dvb_frontend_start doesn't create a new thread.

When exit condition of thread that is jiffies is triggered
by dvb_frontend_release, dvb_frontend_thread wakes up and checks
exit condition without semaphore acquiring.
In this case, if user context checks existence of thread(fepriv-thread),
it is true, and exit flage has DVB_FE_NO_EXIT.
Therefore, dvb_frontend_start doesn't make a new thread,
previous old thread is going to terminate.

To fix this problem, semaphore should preserve thread exit condition and
checking it, which are dvb_frontend_is_exiting and fe-exit.

Signed-off-by: bk0121.shin bk0121.s...@samsung.com
---
 drivers/media/dvb-core/dvb_frontend.c | 22 +++---
 1 file changed, 15 insertions(+), 7 deletions(-)

diff --git a/drivers/media/dvb-core/dvb_frontend.c 
b/drivers/media/dvb-core/dvb_frontend.c
index 2cf3057..a8e8d44 100644
--- a/drivers/media/dvb-core/dvb_frontend.c
+++ b/drivers/media/dvb-core/dvb_frontend.c
@@ -620,14 +620,17 @@ restart:
|| freezing(current),
fepriv-delay);
 
+   if (down_interruptible(fepriv-sem))
+   break;
+
if (kthread_should_stop() || dvb_frontend_is_exiting(fe)) {
/* got signal or quitting */
-   if (!down_interruptible(fepriv-sem))
-   semheld = true;
+   semheld = true;
fe-exit = DVB_FE_NORMAL_EXIT;
break;
}
 
+   up(fepriv-sem);
if (try_to_freeze())
goto restart;
 
@@ -821,17 +824,22 @@ static int dvb_frontend_start(struct dvb_frontend *fe)
 
dev_dbg(fe-dvb-device, %s:\n, __func__);
 
+   if (down_interruptible(fepriv-sem))
+   return -EINTR;
+
if (fepriv-thread) {
-   if (fe-exit == DVB_FE_NO_EXIT)
+   if (fe-exit == DVB_FE_NO_EXIT) {
+   up(fepriv-sem);
return 0;
-   else
+   } else {
dvb_frontend_stop (fe);
+   }
}
 
-   if (signal_pending(current))
-   return -EINTR;
-   if (down_interruptible (fepriv-sem))
+   if (signal_pending(current)) {
+   up(fepriv-sem);
return -EINTR;
+   }
 
fepriv-state = FESTATE_IDLE;
fe-exit = DVB_FE_NO_EXIT;
-- 
1.9.1





---
Byeongki Shin 
Senior Engineer 

Office:
Mobile: +82-10-3268-8201
E-Mail: bk0121.s...@samsung.com

0001-media-dvb-core-Fix-frontend-thread-serialization.patch
Description: Binary data

Re: Driver/module in kernel fault. Anyone expert to help me? Siano ID 187f:0600

2015-01-14 Thread Roberto Alcântara 
Francesco,

Seems very strange not work once you have lock (1f) and ber 0. not a
real problem signal report.

After tzap -r open another console and:

dd if=/dev/dvb/adapter0/dvr0 of=test.ts

Wait 10 seconds and stop it. Please check file size (try to open on
vlc too if big enough...).

Cheers,
 - Roberto

On Tue, Jan 13, 2015 at 6:56 PM, Francesco Other
francesco.ot...@gmail.com wrote:


 So, this is the output for tzap with the NOT-working-device:

 $ tzap -r -c ~/.tzap/channels.conf Italia1
 using '/dev/dvb/adapter0/frontend0' and '/dev/dvb/adapter0/demux0'
 reading channels from file '/home/ionic/.tzap/channels.conf'
 Version: 5.10   FE_CAN { DVB-T }
 tuning to 69800 Hz
 video pid 0x0654, audio pid 0x0655
 status 00 | signal  | snr  | ber  | unc  |
 status 1f | signal  | snr 0104 | ber  | unc  | FE_HAS_LOCK
 status 1f | signal  | snr 0104 | ber  | unc  | FE_HAS_LOCK
 status 1f | signal  | snr 0104 | ber  | unc  | FE_HAS_LOCK
 status 1f | signal  | snr 0104 | ber  | unc  | FE_HAS_LOCK
 status 1f | signal  | snr 0104 | ber  | unc  | FE_HAS_LOCK
 status 1f | signal  | snr 010e | ber  | unc  | FE_HAS_LOCK
 status 1f | signal  | snr 0104 | ber  | unc  | FE_HAS_LOCK
 status 1f | signal  | snr 010e | ber  | unc  | FE_HAS_LOCK
 status 1f | signal  | snr 0104 | ber  | unc  | FE_HAS_LOCK




 - Roberto
--
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: HDMI input on i.MX6 using IPU

2015-01-14 Thread Jean-Michel Hautbois 
Hi,

2015-01-08 17:53 GMT+01:00 Jean-Michel Hautbois
jean-michel.hautb...@vodalys.com:
 Hi,

 I have modified both Steve's and Philipp's code, in order to get
 something able to get frames from an ADV7611.
 Right now, I am back to Philipp's base of code, rebased on top of
 media-tree, and everything works fine, except the very last link
 between SFMC and IDMAC (using media controller).
 Here is a status.

 The code is here :
 https://github.com/Vodalys/linux-2.6-imx/tree/media-tree-zabel

Right now, I can go further. I added support for BT.1120 in order to
get the correct video format, and I am able to start a streaming, but
I can't get an interrupt on IDMAC.

I am starting with setting DV timings on adv7611 input, and then, I am
using 4l2-compliance in order to test streaming. It has shown several
things, most of them are corrected, sometimes in a hacky way.

Right now, I can do the following :
$ media-ctl --set-dv 'adv7611 1-004c:1 [fmt:YUYV/1280x720]' 
media-ctl --set-v4l2 'adv7611 1-004c:1 [fmt:YUYV/1280x720]'
$ echo -n 'module imx_ipuv3_csi +p'  /sys/kernel/debug/dynamic_debug/control
$ v4l2-compliance -v -s
Driver Info:
Driver name   : imx-ipuv3-csi
Card type : imx-ipuv3-camera
Bus info  : platform:imx-ipuv3-csi
Driver version: 3.19.0
Capabilities  : 0x8421
Video Capture
Streaming
Extended Pix Format
Device Capabilities
Device Caps   : 0x0421
Video Capture
Streaming
Extended Pix Format

Compliance test for device /dev/video0 (not using libv4l2):

Required ioctls:
test VIDIOC_QUERYCAP: OK

Allow for multiple opens:
test second video open: OK
test VIDIOC_QUERYCAP: OK
test VIDIOC_G/S_PRIORITY: OK

Debug ioctls:
test VIDIOC_DBG_G/S_REGISTER: OK
test VIDIOC_LOG_STATUS: OK

Input ioctls:
test VIDIOC_G/S_TUNER/ENUM_FREQ_BANDS: OK (Not Supported)
test VIDIOC_G/S_FREQUENCY: OK (Not Supported)
test VIDIOC_S_HW_FREQ_SEEK: OK (Not Supported)
test VIDIOC_ENUMAUDIO: OK (Not Supported)
test VIDIOC_G/S/ENUMINPUT: OK (Not Supported)
test VIDIOC_G/S_AUDIO: OK (Not Supported)
Inputs: 0 Audio Inputs: 0 Tuners: 0

Output ioctls:
test VIDIOC_G/S_MODULATOR: OK (Not Supported)
test VIDIOC_G/S_FREQUENCY: OK (Not Supported)
test VIDIOC_ENUMAUDOUT: OK (Not Supported)
test VIDIOC_G/S/ENUMOUTPUT: OK (Not Supported)
test VIDIOC_G/S_AUDOUT: OK (Not Supported)
Outputs: 0 Audio Outputs: 0 Modulators: 0

Input/Output configuration ioctls:
test VIDIOC_ENUM/G/S/QUERY_STD: OK (Not Supported)
test VIDIOC_ENUM/G/S/QUERY_DV_TIMINGS: OK (Not Supported)
test VIDIOC_DV_TIMINGS_CAP: OK (Not Supported)
test VIDIOC_G/S_EDID: OK (Not Supported)

Control ioctls:
info: checking v4l2_queryctrl of control 'User Controls' (0x00980001)
info: checking v4l2_queryctrl of control 'Brightness' (0x00980900)
info: checking v4l2_queryctrl of control 'Contrast' (0x00980901)
info: checking v4l2_queryctrl of control 'Saturation' (0x00980902)
info: checking v4l2_queryctrl of control 'Hue' (0x00980903)
info: checking v4l2_queryctrl of control 'Image Processing
Controls' (0x009f0001)
info: checking v4l2_queryctrl of control 'Test Pattern' (0x009f0903)
info: checking v4l2_queryctrl of control 'Brightness' (0x00980900)
info: checking v4l2_queryctrl of control 'Contrast' (0x00980901)
info: checking v4l2_queryctrl of control 'Saturation' (0x00980902)
info: checking v4l2_queryctrl of control 'Hue' (0x00980903)
test VIDIOC_QUERYCTRL/MENU: OK
info: checking control 'User Controls' (0x00980001)
info: checking control 'Brightness' (0x00980900)
info: checking control 'Contrast' (0x00980901)
info: checking control 'Saturation' (0x00980902)
info: checking control 'Hue' (0x00980903)
info: checking control 'Image Processing Controls' (0x009f0001)
info: checking control 'Test Pattern' (0x009f0903)
test VIDIOC_G/S_CTRL: OK
info: checking extended control 'User Controls' (0x00980001)
info: checking extended control 'Brightness' (0x00980900)
info: checking extended control 'Contrast' (0x00980901)
info: checking extended control 'Saturation' (0x00980902)
info: checking extended control 'Hue' (0x00980903)
info: checking extended control 'Image Processing Controls' (0x009f0001)
info: checking extended control 'Test Pattern' (0x009f0903)
test VIDIOC_G/S/TRY_EXT_CTRLS: OK
info: checking control event 'User Controls' (0x00980001)
fail: 
/run/media/jm/SSD_JM/Projets/vodabox3/poky/build/tmp/work/cortexa9hf-vfp-neon-poky-linux-gnueabi/v4l-utils/git-r0/git/utils/v4l2-compliance/v4l2-test-controls.cpp(721):
subscribe event for control 'User Controls' failed
test VIDIOC_(UN)SUBSCRIBE_EVENT/DQEVENT: FAIL
test VIDIOC_G/S_JPEGCOMP: OK (Not Supported)

Re: [RFC PATCH 0/3] Introduce IIO interface for fingerprint sensors

2015-01-14 Thread Baluta, Teodora 
On Vi, 2014-12-26 at 11:13 +, Jonathan Cameron wrote:
 On 18/12/14 16:51, Lars-Peter Clausen wrote:
  Adding V4L folks to Cc for more input.
 Thanks Lars - we definitely would need the v4l guys to agree to a driver like
 this going in IIO. (not that I'm convinced it should!)
  
  On 12/08/2014 03:10 PM, Baluta, Teodora wrote:
  Hello,
 
  On Vi, 2014-12-05 at 02:15 +, Jonathan Cameron wrote:
  On 04/12/14 13:00, Teodora Baluta wrote:
  This patchset adds support for fingerprint sensors through the IIO 
  interface.
  This way userspace applications collect information in a uniform way. All
  processing would be done in the upper layers as suggested in [0].
 
  In order to test out this proposal, a minimal implementation for UPEK's
  TouchChip Fingerprint Sensor via USB is also available. Although there 
  is an
  existing implementation in userspace for USB fingerprint devices, 
  including this
  particular device, the driver represents a proof of concept of how 
  fingerprint
  sensors could be integrated in the IIO framework regardless of the used 
  bus. For
  lower power requirements, the SPI bus is preferred and a kernel driver
  implementation makes more sense.
 
  So why not v4l?  These are effectively image sensors..
 
  Well, here's why I don't think v4l would be the best option:
 
  - an image scanner could be implemented in the v4l subsystem, but it
  seems far more complicated for a simple fingerprint scanner - it usually
  has drivers for webcams, TVs or video streaming devices. The v4l
  subsystem (with all its support for colorspace, decoders, image
  compression, frame control) seems a bit of an overkill for a very
  straightforward fingerprint imaging sensor.
 Whilst those are there, I would doubt the irrelevant bits would put much
 burden on a fingerprint scanning driver.  Been a while since I did
 anything in that area though so I could be wrong!
 
  - a fingerprint device could also send out a processed information, not
  just the image of a fingerprint. This means that the processing is done
  in hardware - the UPEK TouchStrip chipset in libfprint has this behavior
  (see [0]). So, the IIO framework would support a uniform way of handling
  fingerprint devices that either do processing in software or in
  hardware.
 This is more interesting, but does that map well to IIO style
 channels anyway?  If not we are going to end up with a whole new
 interface which ever subsystem is used for the image side of things.
 
  The way I see it now, for processed fingerprint information, an IIO
  device could have an IIO_FINGERPRINT channel with a modifier and only
  the sensitivity threshold attribute set. We would also need two
  triggers: one for enrollment and one for the verification mode to
  control the device from a userspace application.
 Sure - what you proposed would work.  The question is whether it is
 the best way to do it.

Any thoughts on this from the v4l community?

Thanks,
Teodora

 
 
 
  Thanks,
  Teodora
 
  [0] http://www.freedesktop.org/wiki/Software/fprint/libfprint/upekts/
 
 
 
  A sysfs trigger is enabled and the device starts scanning. As soon as an 
  image
  is available it is written in the character device /dev/iio:deviceX.
 
  Userspace applications will be able to calculate the expected image size 
  using
  the fingerprint attributes height, width and bit depth. Other attributes
  introduced for the fingerprint channel in IIO represent information that 
  aids in
  the fingerprint image processing. Besides these, the proposed interface 
  offers
  userspace a way to read a feedback after a scan (like the swipe was too 
  slow or
  too fast) through a modified fingerprint_status channel.
 
  [0] http://www.spinics.net/lists/linux-iio/msg11463.html
 
  Teodora Baluta (3):
 iio: core: add support for fingerprint devices
 iio: core: change channel's storagebits/realbits to u32
 iio: fingerprint: add fingerprint sensor via USB
 
Documentation/ABI/testing/sysfs-bus-iio |  51 +++
drivers/iio/Kconfig |   1 +
drivers/iio/Makefile|   1 +
drivers/iio/fingerprint/Kconfig |  15 +
drivers/iio/fingerprint/Makefile|   5 +
drivers/iio/fingerprint/fp_tc.c | 162 +
drivers/iio/fingerprint/fp_tc.h |  22 ++
drivers/iio/fingerprint/fp_tc_usb.c | 618 
  
drivers/iio/fingerprint/fp_tc_usb.h | 144 
drivers/iio/industrialio-core.c |   9 +
include/linux/iio/iio.h |  11 +-
include/linux/iio/types.h   |  10 +
12 files changed, 1047 insertions(+), 2 deletions(-)
create mode 100644 drivers/iio/fingerprint/Kconfig
create mode 100644 drivers/iio/fingerprint/Makefile
create mode 100644 drivers/iio/fingerprint/fp_tc.c
create mode 100644 drivers/iio/fingerprint/fp_tc.h
create mode 100644 drivers/iio/fingerprint/fp_tc_usb.c
create mode 100644

Re: [PATCH v2 0/8] ARM: at91: dts: sama5d3: add dt support for atmel isi and ov2640 sensor

2015-01-14 Thread Alexandre Belloni 
Hi Nicolas,

BTW, you can add my ack on the remaining patches (5-7).

On 13/01/2015 at 16:05:57 +0100, Nicolas Ferre wrote :
 Le 04/01/2015 10:02, Josh Wu a écrit :
  This patch series add ISI and ov2640 support on dts files.
  
  As the ov2640 driver dt is still in review. The patch is in: 
  https://patchwork.linuxtv.org/patch/27554/
  So I want to send this dt patch early for a review.
  
  v1 - v2:
1. add one more patch to change the pin name of ISI_MCK
2. rewrite the commit [4/8] ARM: at91: dts: sama5d3: change name of 
  pinctrl_isi_{power,reset}.
3. move the common chip parts of ISI node to sama5d3.dtsi.
  
  Bo Shen (3):
ARM: at91: dts: sama5d3: split isi pinctrl
ARM: at91: dts: sama5d3: add missing pins of isi
ARM: at91: dts: sama5d3: move the isi mck pin to mb
  
  Josh Wu (5):
ARM: at91: dts: sama5d3: add isi clock
ARM: at91: dts: sama5d3: change name of pinctrl_isi_{power,reset}
ARM: at91: dts: sama5d3: change name of pinctrl of ISI_MCK
ARM: at91: dts: sama5d3: add ov2640 camera sensor support
ARM: at91: sama5: enable atmel-isi and ov2640 in defconfig
 
 Josh,
 
 It seems that this patch doesn't show up in the series: I only received
 up to 6/8 patches (2 missing?). Can you please send it(them?)?
 
 Bye,
 
   arch/arm/boot/dts/sama5d3.dtsi| 24 ++-
   arch/arm/boot/dts/sama5d3xmb.dtsi | 40 
  +++
   arch/arm/configs/sama5_defconfig  |  6 ++
   3 files changed, 61 insertions(+), 9 deletions(-)
  
 
 
 -- 
 Nicolas Ferre

-- 
Alexandre Belloni, 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

Re: [PATCH 1/2] V4L: remove clock name from v4l2_clk API

2015-01-14 Thread Josh Wu 

On 1/12/2015 6:38 PM, Laurent Pinchart wrote:

Hi Josh,

On Monday 12 January 2015 17:14:33 Josh Wu wrote:

On 1/9/2015 6:47 AM, Laurent Pinchart wrote:

On Thursday 08 January 2015 23:37:58 Guennadi Liakhovetski wrote:

On Wed, 7 Jan 2015, Josh Wu wrote:

On 1/7/2015 6:17 AM, Guennadi Liakhovetski wrote:

On Tue, 6 Jan 2015, Josh Wu wrote:

Hi, Guennadi

After look deep into this patch, I found you miss one line that should
be changed as well.
It's In function v4l2_clk_get(), there still has one line code called
v4l2_clk_find(dev_id, id).
You need to change it to v4l2_clk_find(dev_id, NULL) as well.
Otherwise the code that many sensor used: v4l2_clk_get(client-dev,
mclk) cannot acquired the mclk clock.

After above changes, this patch works for me.

I think you're right, in fact, since we now don't store CCF-based
v4l2_clk wrappers on the list, this can be simplified even further,
I'll update the patch. Did you only test this patch or both?

I tested both patches with Atmel-isi driver. For the 2/2 patch I applied
the modification Laurent suggested.
Those patches works for me.

The only concern is in ov2640 I still need to acquired two v4l2 clocks:
 xvclk  that will get the xvclk CCF clock directly.
 mclk  that make ISI driver call his clock_start()/stop() to
 enable/disable ISI's peripheral clock.

If I only get xvclk clock, then the camera capture will be failed with a
ISI timeout error.

No, this doesn't look right to me. The camera sensor has only one clock
input, so, it should only request one clock. Where does the clock signal
to the camera come from on your system?

That's correct, the sensor driver only has one clock input, so it should
just request the xvclk clock.


If it comes from the ISI itself, you don't need to specify the clock in
the DT, since the ISI doesn't produce a clock from DT. If you do want to
have your clock consumer (ov2640) and the supplier (ISI) properly
described in DT, you'll have to teach the ISI to register a CCF clock
source, which then will be connected to from the ov2640. If you choose
not to show your clock in the DT, you can just use v4l2_clk_get(dev,
xvclk) and it will be handled by v4l2_clk / soc-camera / isi-atmel.

If the closk to ov2640 is supplied by a separate clock source, then you
v4l2_clk_get() will connect ov2640 to it directly and soc-camera will
enable and disable it on power-on / -off as required.

The ISI has no way to supply a sensor clock, the clock is supplied by a
separate clock source.


 From your above description it looks like the clock to ov2640 is
supplied by a separate source, but atmel-isi's .clock_start() /
.clock_stop() functions still need to be called? By looking at those
functions it looks like they turn on and off clocks, supplying the ISI
itself... Instead of only turning on and off clocks, provided by the ISI
to a camera sensor. If my understanding is right, then this is a bug in
atmel-isi and it has to be fixed.

That's correct as well, the ISI driver needs to be fixed.

Thanks both of you for the details. Now I got it.
Indeed, I need fix this in atmel-isi driver not in ov2640 driver.
So I will send a new patch for this, which should move the ISI
peripheral clock enable/disable() from clock_start/stop() to
isi_camera_add_device/remove_device().

Shouldn't you move it to the start_streaming() and stop_streaming() functions
instead ? An even better solution would be to use runtime PM to enable/disable
the ISI clock in the runtime PM resume and suspend handlers, and call
pm_runtime_get_sync() and pm_runtime_put() when you need the ISI to be
operational.


Okay, I'll try to add the PM functions for atmel-isi in the meantime.

Best Regards,
Josh Wu




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

HELP: tzap, signal 1f, FE_HAS_LOCK, no demux on Ubuntu 14.04 LTS, Device Siano ID 187f:0600, DVB-T

2015-01-14 Thread Francesco Other 
Hi to all,

I have this output from tzap

Version: 5.10   FE_CAN { DVB-T }
tuning to 69800 Hz
video pid 0x0654, audio pid 0x0655
status 00 | signal  | snr  | ber  | unc  |
status 1f | signal  | snr 0104 | ber  | unc  | FE_HAS_LOCK
status 1f | signal  | snr 0104 | ber  | unc  | FE_HAS_LOCK
status 1f | signal  | snr 0104 | ber  | unc  | FE_HAS_LOCK
status 1f | signal  | snr 0104 | ber  | unc  | FE_HAS_LOCK
status 1f | signal  | snr 0104 | ber  | unc  | FE_HAS_LOCK
...
...

and I can't receive the channel (no video, no audio, no service from multiplex).

Maybe a demux problem?

Ubuntu 14.04 LTS, Device Siano ID 187f:0600, DVB-T

Thanks for any help

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