Re: [GIT PULL FOR 3.9] Exynos SoC media drivers updates

2013-01-06 Thread Mauro Carvalho Chehab 
Em Fri, 04 Jan 2013 23:39:12 +0100
Sylwester Nawrocki sylvester.nawro...@gmail.com escreveu:


  Tomasz Stanislawski (1):
 s5p-tv: mixer: fix handling of VIDIOC_S_FMT

I'll drop this one for now. Devin raised a point: such changes would break
existing applications.

So, we'll need to revisit this topic before changing the drivers.

Btw, I failed to find the corresponding patch at patchwork:

http://patchwork.linuxtv.org/project/linux-media/list/?state=*q=VIDIOC_S_FMT

So, its status update may be wrong after flushing your pwclient commands.

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 PULL FOR 3.9] Exynos SoC media drivers updates

2013-01-06 Thread Mauro Carvalho Chehab 
Em Fri, 04 Jan 2013 23:39:12 +0100
Sylwester Nawrocki sylvester.nawro...@gmail.com escreveu:

 On 01/04/2013 08:01 PM, Sylwester Nawrocki wrote:
  Hi Mauro,
 
  Please pull the following for 3.9, it includes Exynos SoC drivers cleanups 
  and
  fixes. DMABUF exporting support for Exynos5 GScaler driver, device tree 
  support
  for Exynos MFC driver (platform bits for it got merged already for v3.8).
 
  There is also included a patch removing deprecated image centering controls.
 
  The following changes since commit 8cd7085ff460ead3aba6174052a408f4ad52ac36:
 
 [media] get_dvb_firmware: Fix the location of firmware for Terratec HTC
  (2013-01-01 11:18:26 -0200)
 
  are available in the git repository at:
 
 git://git.infradead.org/users/kmpark/linux-samsung media_for_v3.9
 
  for you to fetch changes up to 36073ee2f7b3b5ae91900cb992b292404614243b:
 
 V4L: Remove deprecated image centering controls (2013-01-04 11:35:43 
  +0100)
 
  
  Arun Kumar K (2):
 s5p-mfc: Add device tree support
 s5p-mfc: Flush DPB buffers during stream off
 
  Kamil Debski (4):
 s5p-mfc: Move firmware allocation point to avoid allocation problems
 s5p-mfc: Correct check of vb2_dma_contig_init_ctx return value
 s5p-mfc: Change internal buffer allocation from vb2 ops to 
  dma_alloc_coherent
 s5p-mfc: Context handling in open() bugfix
 
  Sachin Kamat (9):
 s5p-tv: Add missing braces around sizeof in sdo_drv.c
 s5p-tv: Add missing braces around sizeof in mixer_video.c
 s5p-tv: Add missing braces around sizeof in mixer_reg.c
 s5p-tv: Add missing braces around sizeof in mixer_drv.c
 s5p-tv: Add missing braces around sizeof in hdmiphy_drv.c
 s5p-tv: Add missing braces around sizeof in hdmi_drv.c
 s5p-mfc: Remove redundant 'break'
 s5p-mfc: Fix a typo in error message in s5p_mfc_pm.c
 s5p-mfc: Fix an error check
 
  Shaik Ameer Basha (1):
 exynos-gsc: Support dmabuf export buffer
 
  Sylwester Nawrocki (5):
 s5p-fimc: Avoid possible NULL pointer dereference in set_fmt op
 s5p-fimc: Prevent potential buffer overflow
 s5p-fimc: Prevent AB-BA deadlock during links reconfiguration
 s5p-tv: Fix return value in sdo_probe() on error paths
 V4L: Remove deprecated image centering controls
 
  Tomasz Stanislawski (1):
 s5p-tv: mixer: fix handling of VIDIOC_S_FMT
 
  Tony Prisk (3):
 s5p-fimc: Fix incorrect usage of IS_ERR_OR_NULL
 s5p-tv: Fix incorrect usage of IS_ERR_OR_NULL
 s5p-g2d: Fix incorrect usage of IS_ERR_OR_NULL
 
  Wei Yongjun (1):
 s5p-mfc: remove unused variable
 
 Related patchwork commands:
 
 pwclient update -s 'accepted' 15333
 pwclient update -s 'accepted' 15565
 pwclient update -s 'accepted' 16071
 pwclient update -s 'accepted' 16072
 pwclient update -s 'accepted' 16073
 pwclient update -s 'accepted' 15657
 pwclient update -s 'accepted' 15656
 pwclient update -s 'accepted' 15658
 pwclient update -s 'accepted' 15659
 pwclient update -s 'accepted' 15660
 pwclient update -s 'accepted' 15661
 pwclient update -s 'accepted' 16013
 pwclient update -s 'superseded' 16059
 pwclient update -s 'accepted' 16060
 pwclient update -s 'accepted' 16080
 pwclient update -s 'accepted' 16081
 pwclient update -s 'accepted' 16084
 pwclient update -s 'accepted' 15647
 pwclient update -s 'superseded' 16083
 pwclient update -s 'accepted' 15765

Those status updates were missing:

pwclient update -s 'superseded' 14608
pwclient update -s 'superseded' 15188
pwclient update -s 'accepted' 16058
pwclient update -s 'accepted' 16108

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


-- 

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

Re: [PATCH RFC 01/11] dvb_usb_v2: make remote controller optional

2013-01-06 Thread Mauro Carvalho Chehab 
Em Mon, 10 Dec 2012 02:45:25 +0200
Antti Palosaari cr...@iki.fi escreveu:

 Make it possible to compile dvb_usb_v2 driver without the remote
 controller (RC-core).
 
 Signed-off-by: Antti Palosaari cr...@iki.fi
 ---
  drivers/media/usb/dvb-usb-v2/Kconfig|  3 ++-
  drivers/media/usb/dvb-usb-v2/dvb_usb.h  |  9 +
  drivers/media/usb/dvb-usb-v2/dvb_usb_core.c | 12 
  3 files changed, 23 insertions(+), 1 deletion(-)
 
 diff --git a/drivers/media/usb/dvb-usb-v2/Kconfig 
 b/drivers/media/usb/dvb-usb-v2/Kconfig
 index 834bfec..60f4240 100644
 --- a/drivers/media/usb/dvb-usb-v2/Kconfig
 +++ b/drivers/media/usb/dvb-usb-v2/Kconfig
 @@ -1,6 +1,6 @@
  config DVB_USB_V2
   tristate Support for various USB DVB devices v2
 - depends on DVB_CORE  USB  I2C  RC_CORE
 + depends on DVB_CORE  USB  I2C
   help
 By enabling this you will be able to choose the various supported
 USB1.1 and USB2.0 DVB devices.
 @@ -113,6 +113,7 @@ config DVB_USB_IT913X
  config DVB_USB_LME2510
   tristate LME DM04/QQBOX DVB-S USB2.0 support
   depends on DVB_USB_V2
 + depends on RC_CORE
   select DVB_TDA10086 if MEDIA_SUBDRV_AUTOSELECT
   select DVB_TDA826X if MEDIA_SUBDRV_AUTOSELECT
   select DVB_STV0288 if MEDIA_SUBDRV_AUTOSELECT
 diff --git a/drivers/media/usb/dvb-usb-v2/dvb_usb.h 
 b/drivers/media/usb/dvb-usb-v2/dvb_usb.h
 index 059291b..e2678a7 100644
 --- a/drivers/media/usb/dvb-usb-v2/dvb_usb.h
 +++ b/drivers/media/usb/dvb-usb-v2/dvb_usb.h
 @@ -400,4 +400,13 @@ extern int dvb_usbv2_reset_resume(struct usb_interface 
 *);
  extern int dvb_usbv2_generic_rw(struct dvb_usb_device *, u8 *, u16, u8 *, 
 u16);
  extern int dvb_usbv2_generic_write(struct dvb_usb_device *, u8 *, u16);
  
 +/* stub implementations that will be never called when RC-core is disabled */
 +#if !defined(CONFIG_RC_CORE)  !defined(CONFIG_RC_CORE_MODULE)
 +#define rc_repeat(args...)
 +#define rc_keydown(args...)
 +#define rc_keydown_notimeout(args...)
 +#define rc_keyup(args...)
 +#define rc_g_keycode_from_table(args...) 0
 +#endif
 +

Those stub seem to be miss-placed: they belong to rc-core, and not to 
dvb-usb-v2.
So, those changes should be, instead, at: include/media/rc-core.h

  #endif
 diff --git a/drivers/media/usb/dvb-usb-v2/dvb_usb_core.c 
 b/drivers/media/usb/dvb-usb-v2/dvb_usb_core.c
 index 671b4fa..94f134c 100644
 --- a/drivers/media/usb/dvb-usb-v2/dvb_usb_core.c
 +++ b/drivers/media/usb/dvb-usb-v2/dvb_usb_core.c
 @@ -102,6 +102,7 @@ static int dvb_usbv2_i2c_exit(struct dvb_usb_device *d)
   return 0;
  }
  
 +#if defined(CONFIG_RC_CORE) || defined(CONFIG_RC_CORE_MODULE)
  static void dvb_usb_read_remote_control(struct work_struct *work)
  {
   struct dvb_usb_device *d = container_of(work,
 @@ -202,6 +203,17 @@ static int dvb_usbv2_remote_exit(struct dvb_usb_device 
 *d)
  
   return 0;
  }
 +#else
 +static int dvb_usbv2_remote_init(struct dvb_usb_device *d)
 +{
 + return 0;
 +}
 +
 +static int dvb_usbv2_remote_exit(struct dvb_usb_device *d)
 +{
 + return 0;
 +}
 +#endif
  
  static void dvb_usb_data_complete(struct usb_data_stream *stream, u8 *buf,
   size_t len)


-- 

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

Re: [PATCH RFC 01/11] dvb_usb_v2: make remote controller optional

2013-01-06 Thread Mauro Carvalho Chehab 
Em Sun, 6 Jan 2013 10:11:29 -0200
Mauro Carvalho Chehab mche...@redhat.com escreveu:

 Em Mon, 10 Dec 2012 02:45:25 +0200
 Antti Palosaari cr...@iki.fi escreveu:
 
  Make it possible to compile dvb_usb_v2 driver without the remote
  controller (RC-core).
  
  Signed-off-by: Antti Palosaari cr...@iki.fi
  ---
   drivers/media/usb/dvb-usb-v2/Kconfig|  3 ++-
   drivers/media/usb/dvb-usb-v2/dvb_usb.h  |  9 +
   drivers/media/usb/dvb-usb-v2/dvb_usb_core.c | 12 
   3 files changed, 23 insertions(+), 1 deletion(-)
  
  diff --git a/drivers/media/usb/dvb-usb-v2/Kconfig 
  b/drivers/media/usb/dvb-usb-v2/Kconfig
  index 834bfec..60f4240 100644
  --- a/drivers/media/usb/dvb-usb-v2/Kconfig
  +++ b/drivers/media/usb/dvb-usb-v2/Kconfig
  @@ -1,6 +1,6 @@
   config DVB_USB_V2
  tristate Support for various USB DVB devices v2
  -   depends on DVB_CORE  USB  I2C  RC_CORE
  +   depends on DVB_CORE  USB  I2C
  help
By enabling this you will be able to choose the various supported
USB1.1 and USB2.0 DVB devices.
  @@ -113,6 +113,7 @@ config DVB_USB_IT913X
   config DVB_USB_LME2510
  tristate LME DM04/QQBOX DVB-S USB2.0 support
  depends on DVB_USB_V2
  +   depends on RC_CORE
  select DVB_TDA10086 if MEDIA_SUBDRV_AUTOSELECT
  select DVB_TDA826X if MEDIA_SUBDRV_AUTOSELECT
  select DVB_STV0288 if MEDIA_SUBDRV_AUTOSELECT
  diff --git a/drivers/media/usb/dvb-usb-v2/dvb_usb.h 
  b/drivers/media/usb/dvb-usb-v2/dvb_usb.h
  index 059291b..e2678a7 100644
  --- a/drivers/media/usb/dvb-usb-v2/dvb_usb.h
  +++ b/drivers/media/usb/dvb-usb-v2/dvb_usb.h
  @@ -400,4 +400,13 @@ extern int dvb_usbv2_reset_resume(struct usb_interface 
  *);
   extern int dvb_usbv2_generic_rw(struct dvb_usb_device *, u8 *, u16, u8 *, 
  u16);
   extern int dvb_usbv2_generic_write(struct dvb_usb_device *, u8 *, u16);
   
  +/* stub implementations that will be never called when RC-core is disabled 
  */
  +#if !defined(CONFIG_RC_CORE)  !defined(CONFIG_RC_CORE_MODULE)
  +#define rc_repeat(args...)
  +#define rc_keydown(args...)
  +#define rc_keydown_notimeout(args...)
  +#define rc_keyup(args...)
  +#define rc_g_keycode_from_table(args...) 0
  +#endif
  +
 
 Those stub seem to be miss-placed: they belong to rc-core, and not to 
 dvb-usb-v2.
 So, those changes should be, instead, at: include/media/rc-core.h

Hmm.. you removed those later. Ok, I'll apply this series, but I'll then add an
additional patch at the end putting the above at rc-core.h, as it may help with
other drivers.

-- 

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

[PATCH] s5p-tv: mixer: fix handling of VIDIOC_S_FMT

2013-01-06 Thread Sylwester Nawrocki 
From: Tomasz Stanislawski t.stanisl...@samsung.com

The VIDIOC_S_FMT ioctl must not fail if 4cc is invalid.
It should adjust proposed 4cc to the available one.
The s5p-mixer fails on s_fmt if unsupported 4cc is used.
This patch fixes this issue by using the default format
for a given layer.

Signed-off-by: Tomasz Stanislawski t.stanisl...@samsung.com
Signed-off-by: Sylwester Nawrocki s.nawro...@samsung.com
---
 drivers/media/platform/s5p-tv/mixer_video.c |4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/media/platform/s5p-tv/mixer_video.c 
b/drivers/media/platform/s5p-tv/mixer_video.c
index 7379e77..405414f 100644
--- a/drivers/media/platform/s5p-tv/mixer_video.c
+++ b/drivers/media/platform/s5p-tv/mixer_video.c
@@ -324,10 +324,9 @@ static int mxr_s_fmt(struct file *file, void *priv,
pix = f-fmt.pix_mp;
fmt = find_format_by_fourcc(layer, pix-pixelformat);
if (fmt == NULL) {
-   mxr_warn(mdev, not recognized fourcc: %08x\n,
+   mxr_dbg(mdev, not recognized fourcc: %08x\n,
pix-pixelformat);
-   return -EINVAL;
+   fmt = layer-fmt_array[0];
}
layer-fmt = fmt;
/* set source size to highest accepted value */
--
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: [GIT PULL FOR 3.9] Exynos SoC media drivers updates

2013-01-06 Thread Sylwester Nawrocki 

On 01/06/2013 12:32 PM, Mauro Carvalho Chehab wrote:

Em Fri, 04 Jan 2013 23:39:12 +0100
Sylwester Nawrockisylvester.nawro...@gmail.com  escreveu:



Tomasz Stanislawski (1):
s5p-tv: mixer: fix handling of VIDIOC_S_FMT


I'll drop this one for now. Devin raised a point: such changes would break
existing applications.

So, we'll need to revisit this topic before changing the drivers.

Btw, I failed to find the corresponding patch at patchwork:

http://patchwork.linuxtv.org/project/linux-media/list/?state=*q=VIDIOC_S_FMT

So, its status update may be wrong after flushing your pwclient commands.


Hmm, I got this patch from Tomasz by e-mail and added it to the pull 
request.

I think it wasn't sent to the mailing list, but I noticed it only after
sending you the pull requests, when was preparing the pwclient commands.
I've just posted it now, sorry. The link is here:
http://patchwork.linuxtv.org/patch/16143

Tomasz created this patch specifically for the purpose of format negotiation
in video pipeline in the application we used to test various scenarios with
DMABUF. I agree this patch has a potential of breaking buggy user space
applications. I can't see other solution for it right now, there seems even
to be no possibility to return some flag in VIDIOC_S_FMT indicating that
format has been modified and is valid, when -EINVAL was returned. This 
sounds

ugly anyway, but could ensure backward compatibility for applications that
exppect EINVAL when format has been changed. BTW, I wonder if it is only 
fourcc,

or other format parameters as well - like width, height, some applications
expect to get EINVAL when those have changed.


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

[PATCH] ts2020: call get_rf_strength from frontend

2013-01-06 Thread Malcolm Priestley 
Restore ds3000.c read_signal_strength.

Call tuner get_rf_strength from frontend read_signal_strength.

We are able to do a NULL check and doesn't limit the tuner
attach to the frontend attach area.

At the moment the lmedm04 tuner attach is stuck in frontend
attach area.

Signed-off-by: Malcolm Priestley tvbox...@gmail.com
---
 drivers/media/dvb-frontends/ds3000.c| 10 ++
 drivers/media/dvb-frontends/m88rs2000.c |  4 +++-
 drivers/media/dvb-frontends/ts2020.c|  1 -
 3 files changed, 13 insertions(+), 2 deletions(-)

diff --git a/drivers/media/dvb-frontends/ds3000.c 
b/drivers/media/dvb-frontends/ds3000.c
index d128f85..1e344b0 100644
--- a/drivers/media/dvb-frontends/ds3000.c
+++ b/drivers/media/dvb-frontends/ds3000.c
@@ -533,6 +533,15 @@ static int ds3000_read_ber(struct dvb_frontend *fe, u32* 
ber)
return 0;
 }
 
+static int ds3000_read_signal_strength(struct dvb_frontend *fe,
+   u16 *signal_strength)
+{
+   if (fe-ops.tuner_ops.get_rf_strength)
+   fe-ops.tuner_ops.get_rf_strength(fe, signal_strength);
+
+   return 0;
+}
+
 /* calculate DS3000 snr value in dB */
 static int ds3000_read_snr(struct dvb_frontend *fe, u16 *snr)
 {
@@ -1102,6 +,7 @@ static struct dvb_frontend_ops ds3000_ops = {
.i2c_gate_ctrl = ds3000_i2c_gate_ctrl,
.read_status = ds3000_read_status,
.read_ber = ds3000_read_ber,
+   .read_signal_strength = ds3000_read_signal_strength,
.read_snr = ds3000_read_snr,
.read_ucblocks = ds3000_read_ucblocks,
.set_voltage = ds3000_set_voltage,
diff --git a/drivers/media/dvb-frontends/m88rs2000.c 
b/drivers/media/dvb-frontends/m88rs2000.c
index 283c90f..4da5272 100644
--- a/drivers/media/dvb-frontends/m88rs2000.c
+++ b/drivers/media/dvb-frontends/m88rs2000.c
@@ -446,7 +446,9 @@ static int m88rs2000_read_ber(struct dvb_frontend *fe, u32 
*ber)
 static int m88rs2000_read_signal_strength(struct dvb_frontend *fe,
u16 *strength)
 {
-   *strength = 0;
+   if (fe-ops.tuner_ops.get_rf_strength)
+   fe-ops.tuner_ops.get_rf_strength(fe, strength);
+
return 0;
 }
 
diff --git a/drivers/media/dvb-frontends/ts2020.c 
b/drivers/media/dvb-frontends/ts2020.c
index f50e237..ad7ad85 100644
--- a/drivers/media/dvb-frontends/ts2020.c
+++ b/drivers/media/dvb-frontends/ts2020.c
@@ -363,7 +363,6 @@ struct dvb_frontend *ts2020_attach(struct dvb_frontend *fe,
 
memcpy(fe-ops.tuner_ops, ts2020_tuner_ops,
sizeof(struct dvb_tuner_ops));
-   fe-ops.read_signal_strength = fe-ops.tuner_ops.get_rf_strength;
 
return fe;
 }
-- 
1.8.0


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

Re: [GIT PULL FOR 3.9] Exynos SoC media drivers updates

2013-01-06 Thread Mauro Carvalho Chehab 
Em Sun, 06 Jan 2013 13:34:53 +0100
Sylwester Nawrocki sylvester.nawro...@gmail.com escreveu:

 On 01/06/2013 12:32 PM, Mauro Carvalho Chehab wrote:
  Em Fri, 04 Jan 2013 23:39:12 +0100
  Sylwester Nawrockisylvester.nawro...@gmail.com  escreveu:
 
 
  Tomasz Stanislawski (1):
  s5p-tv: mixer: fix handling of VIDIOC_S_FMT
 
  I'll drop this one for now. Devin raised a point: such changes would break
  existing applications.
 
  So, we'll need to revisit this topic before changing the drivers.
 
  Btw, I failed to find the corresponding patch at patchwork:
  
  http://patchwork.linuxtv.org/project/linux-media/list/?state=*q=VIDIOC_S_FMT
 
  So, its status update may be wrong after flushing your pwclient commands.
 
 Hmm, I got this patch from Tomasz by e-mail and added it to the pull 
 request.
 I think it wasn't sent to the mailing list, but I noticed it only after
 sending you the pull requests, when was preparing the pwclient commands.
 I've just posted it now, sorry. The link is here:
 http://patchwork.linuxtv.org/patch/16143
 
 Tomasz created this patch specifically for the purpose of format negotiation
 in video pipeline in the application we used to test various scenarios with
 DMABUF. I agree this patch has a potential of breaking buggy user space
 applications. I can't see other solution for it right now, there seems even
 to be no possibility to return some flag in VIDIOC_S_FMT indicating that
 format has been modified and is valid, when -EINVAL was returned. This 
 sounds
 ugly anyway, but could ensure backward compatibility for applications that
 exppect EINVAL when format has been changed. BTW, I wonder if it is only 
 fourcc,
 or other format parameters as well - like width, height, some applications
 expect to get EINVAL when those have changed.

The patch makes the driver compliant to v4l-compilance, as its behavior asks
for such change, after some discussions we had this year in San Diego. At that
time, we all believed that such change were safe.

However, we can't do it like proposed there (and on other patches from Hans).

The fact is that tvtime and mythtv applications (maybe more) will fail 
if the returned format is different than the requested ones, as they 
don't check for the returned value.

As no regressions on userspace are allowed, we need to re-discuss this issue.

While this doesn't happen, I'll postpone such patches.

Comments/suggestions are welcome.

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 PULL FOR 3.9] Exynos SoC media drivers updates

2013-01-06 Thread Hans Verkuil 
On Sun January 6 2013 13:41:57 Mauro Carvalho Chehab wrote:
 Em Sun, 06 Jan 2013 13:34:53 +0100
 Sylwester Nawrocki sylvester.nawro...@gmail.com escreveu:
 
  On 01/06/2013 12:32 PM, Mauro Carvalho Chehab wrote:
   Em Fri, 04 Jan 2013 23:39:12 +0100
   Sylwester Nawrockisylvester.nawro...@gmail.com  escreveu:
  
  
   Tomasz Stanislawski (1):
   s5p-tv: mixer: fix handling of VIDIOC_S_FMT
  
   I'll drop this one for now. Devin raised a point: such changes would break
   existing applications.
  
   So, we'll need to revisit this topic before changing the drivers.
  
   Btw, I failed to find the corresponding patch at patchwork:
 
   http://patchwork.linuxtv.org/project/linux-media/list/?state=*q=VIDIOC_S_FMT
  
   So, its status update may be wrong after flushing your pwclient commands.
  
  Hmm, I got this patch from Tomasz by e-mail and added it to the pull 
  request.
  I think it wasn't sent to the mailing list, but I noticed it only after
  sending you the pull requests, when was preparing the pwclient commands.
  I've just posted it now, sorry. The link is here:
  http://patchwork.linuxtv.org/patch/16143
  
  Tomasz created this patch specifically for the purpose of format negotiation
  in video pipeline in the application we used to test various scenarios with
  DMABUF. I agree this patch has a potential of breaking buggy user space
  applications. I can't see other solution for it right now, there seems even
  to be no possibility to return some flag in VIDIOC_S_FMT indicating that
  format has been modified and is valid, when -EINVAL was returned. This 
  sounds
  ugly anyway, but could ensure backward compatibility for applications that
  exppect EINVAL when format has been changed. BTW, I wonder if it is only 
  fourcc,
  or other format parameters as well - like width, height, some applications
  expect to get EINVAL when those have changed.
 
 The patch makes the driver compliant to v4l-compilance, as its behavior asks
 for such change, after some discussions we had this year in San Diego. At that
 time, we all believed that such change were safe.
 
 However, we can't do it like proposed there (and on other patches from Hans).
 
 The fact is that tvtime and mythtv applications (maybe more) will fail 
 if the returned format is different than the requested ones, as they 
 don't check for the returned value.
 
 As no regressions on userspace are allowed, we need to re-discuss this issue.
 
 While this doesn't happen, I'll postpone such patches.

This is a video output device. So this patch will never affect 
tvtime/mythtv/etc.
I have no problem with this change being merged.

Regards,

Hans

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

Re: [GIT PULL FOR 3.9] Exynos SoC media drivers updates

2013-01-06 Thread Sylwester Nawrocki 

On 01/06/2013 01:05 PM, Mauro Carvalho Chehab wrote:

Related patchwork commands:

pwclient update -s 'accepted' 15333
pwclient update -s 'accepted' 15565
pwclient update -s 'accepted' 16071
pwclient update -s 'accepted' 16072
pwclient update -s 'accepted' 16073
pwclient update -s 'accepted' 15657
pwclient update -s 'accepted' 15656
pwclient update -s 'accepted' 15658
pwclient update -s 'accepted' 15659
pwclient update -s 'accepted' 15660
pwclient update -s 'accepted' 15661
pwclient update -s 'accepted' 16013
pwclient update -s 'superseded' 16059
pwclient update -s 'accepted' 16060
pwclient update -s 'accepted' 16080
pwclient update -s 'accepted' 16081
pwclient update -s 'accepted' 16084
pwclient update -s 'accepted' 15647
pwclient update -s 'superseded' 16083
pwclient update -s 'accepted' 15765


Those status updates were missing:

pwclient update -s 'superseded' 14608
pwclient update -s 'superseded' 15188
pwclient update -s 'accepted' 16058


OK, sorry. Just learning to use the tools, will try to do better
next time. :)


pwclient update -s 'accepted' 16108


And that's the pull request itself, I've obviously missed it.

--

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

Re: [PATCH] omap_vout: find_vma() needs -mmap_sem held

2013-01-06 Thread Mauro Carvalho Chehab 
Hi Viro,

Em Sat, 15 Dec 2012 20:38:29 +
Al Viro v...@zeniv.linux.org.uk escreveu:

 On Sat, Dec 15, 2012 at 08:12:37PM +, Al Viro wrote:
  Walking rbtree while it's modified is a Bad Idea(tm); besides,
  the result of find_vma() can be freed just as it's getting returned
  to caller.  Fortunately, it's easy to fix - just take -mmap_sem a bit
  earlier (and don't bother with find_vma() at all if virtp = PAGE_OFFSET -
  in that case we don't even look at its result).
 
   While we are at it, what prevents VIDIOC_PREPARE_BUF calling
 v4l_prepare_buf() - (e.g) vb2_ioctl_prepare_buf() - vb2_prepare_buf() -
 __buf_prepare() - __qbuf_userptr() - vb2_vmalloc_get_userptr() - 
 find_vma(),
 AFAICS without having taken -mmap_sem anywhere in process?  The code flow
 is bloody convoluted and depends on a bunch of things done by initialization,
 so I certainly might've missed something...

This driver is currently missing an active maintainer, as it is for an old
hardware (AFAIK, omap is now at version 4, and this is for the first one),
but I'm c/c a few developers that might help to test and analyze it.

In any case, /me is assuming that your patch is right (as nobody complained),
and I'm applying it right now on my tree. This will hopefully allow some
people to test.

Cheers,
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 PULL FOR 3.9] Exynos SoC media drivers updates

2013-01-06 Thread Mauro Carvalho Chehab 
Em Sun, 6 Jan 2013 13:53:52 +0100
Hans Verkuil hverk...@xs4all.nl escreveu:

 On Sun January 6 2013 13:41:57 Mauro Carvalho Chehab wrote:
  Em Sun, 06 Jan 2013 13:34:53 +0100
  Sylwester Nawrocki sylvester.nawro...@gmail.com escreveu:
  
   On 01/06/2013 12:32 PM, Mauro Carvalho Chehab wrote:
Em Fri, 04 Jan 2013 23:39:12 +0100
Sylwester Nawrockisylvester.nawro...@gmail.com  escreveu:
   
   
Tomasz Stanislawski (1):
s5p-tv: mixer: fix handling of VIDIOC_S_FMT
   
I'll drop this one for now. Devin raised a point: such changes would 
break
existing applications.
   
So, we'll need to revisit this topic before changing the drivers.
   
Btw, I failed to find the corresponding patch at patchwork:

http://patchwork.linuxtv.org/project/linux-media/list/?state=*q=VIDIOC_S_FMT
   
So, its status update may be wrong after flushing your pwclient 
commands.
   
   Hmm, I got this patch from Tomasz by e-mail and added it to the pull 
   request.
   I think it wasn't sent to the mailing list, but I noticed it only after
   sending you the pull requests, when was preparing the pwclient commands.
   I've just posted it now, sorry. The link is here:
   http://patchwork.linuxtv.org/patch/16143
   
   Tomasz created this patch specifically for the purpose of format 
   negotiation
   in video pipeline in the application we used to test various scenarios 
   with
   DMABUF. I agree this patch has a potential of breaking buggy user space
   applications. I can't see other solution for it right now, there seems 
   even
   to be no possibility to return some flag in VIDIOC_S_FMT indicating that
   format has been modified and is valid, when -EINVAL was returned. This 
   sounds
   ugly anyway, but could ensure backward compatibility for applications that
   exppect EINVAL when format has been changed. BTW, I wonder if it is only 
   fourcc,
   or other format parameters as well - like width, height, some applications
   expect to get EINVAL when those have changed.
  
  The patch makes the driver compliant to v4l-compilance, as its behavior asks
  for such change, after some discussions we had this year in San Diego. At 
  that
  time, we all believed that such change were safe.
  
  However, we can't do it like proposed there (and on other patches from 
  Hans).
  
  The fact is that tvtime and mythtv applications (maybe more) will fail 
  if the returned format is different than the requested ones, as they 
  don't check for the returned value.
  
  As no regressions on userspace are allowed, we need to re-discuss this 
  issue.
  
  While this doesn't happen, I'll postpone such patches.
 
 This is a video output device. So this patch will never affect 
 tvtime/mythtv/etc.
 I have no problem with this change being merged.

Ok. still, we need to double-check what happens on video output apps. I'll keep
it on hold for a while, tagged as under review at Sylwester's umbrella.

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

Re: [PATCH] omap3isp: Don't include plat/cpu.h

2013-01-06 Thread Mauro Carvalho Chehab 
Em Thu, 3 Jan 2013 14:55:41 -0800
Tony Lindgren t...@atomide.com escreveu:

 * Laurent Pinchart laurent.pinch...@ideasonboard.com [130103 13:24]:
  The plat/*.h headers are not available to drivers in multiplatform
  kernels. As the header isn't needed, just remove it.
 
 Please consider merging this for the -rc cycle, so I can make
 plat/cpu.h produce an error for omap2+ to prevent new drivers
 including it.

Ok, I'll add it to the list of patches for 3.8.

Regards,
Mauro
 
 Acked-by: Tony Lindgren t...@atomide.com
  
  Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
  ---
   drivers/media/platform/omap3isp/isp.c |2 --
   1 files changed, 0 insertions(+), 2 deletions(-)
  
  diff --git a/drivers/media/platform/omap3isp/isp.c 
  b/drivers/media/platform/omap3isp/isp.c
  index 50cea08..07eea5b 100644
  --- a/drivers/media/platform/omap3isp/isp.c
  +++ b/drivers/media/platform/omap3isp/isp.c
  @@ -71,8 +71,6 @@
   #include media/v4l2-common.h
   #include media/v4l2-device.h
   
  -#include plat/cpu.h
  -
   #include isp.h
   #include ispreg.h
   #include ispccdc.h
  -- 
  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


-- 

Cheers,
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 PULL FOR 3.9] Exynos SoC media drivers updates

2013-01-06 Thread Sylwester Nawrocki 

On 01/06/2013 01:53 PM, Hans Verkuil wrote:

Tomasz Stanislawski (1):
 s5p-tv: mixer: fix handling of VIDIOC_S_FMT


I'll drop this one for now. Devin raised a point: such changes would break
existing applications.

So, we'll need to revisit this topic before changing the drivers.

Btw, I failed to find the corresponding patch at patchwork:

http://patchwork.linuxtv.org/project/linux-media/list/?state=*q=VIDIOC_S_FMT

So, its status update may be wrong after flushing your pwclient commands.


Hmm, I got this patch from Tomasz by e-mail and added it to the pull
request.
I think it wasn't sent to the mailing list, but I noticed it only after
sending you the pull requests, when was preparing the pwclient commands.
I've just posted it now, sorry. The link is here:
http://patchwork.linuxtv.org/patch/16143

Tomasz created this patch specifically for the purpose of format negotiation
in video pipeline in the application we used to test various scenarios with
DMABUF. I agree this patch has a potential of breaking buggy user space
applications. I can't see other solution for it right now, there seems even
to be no possibility to return some flag in VIDIOC_S_FMT indicating that
format has been modified and is valid, when -EINVAL was returned. This
sounds
ugly anyway, but could ensure backward compatibility for applications that
exppect EINVAL when format has been changed. BTW, I wonder if it is only
fourcc,
or other format parameters as well - like width, height, some applications
expect to get EINVAL when those have changed.


The patch makes the driver compliant to v4l-compilance, as its behavior asks
for such change, after some discussions we had this year in San Diego. At that
time, we all believed that such change were safe.

However, we can't do it like proposed there (and on other patches from Hans).

The fact is that tvtime and mythtv applications (maybe more) will fail
if the returned format is different than the requested ones, as they
don't check for the returned value.

As no regressions on userspace are allowed, we need to re-discuss this issue.

While this doesn't happen, I'll postpone such patches.


This is a video output device. So this patch will never affect 
tvtime/mythtv/etc.
I have no problem with this change being merged.


TBH, I very much doubt anyone would complain in case of this driver. I'm not
certain if there is complete support for even one board in the mainline 
kernel,

likely only Origen A. AFAIK most applications use either Exynos DRM driver,
that has support for all features available in s5p-tv driver, or 
framebuffer
emulation on top of v4l2 output interface (there were in the past RFC 
patches

posted for vb2 adding FB emulation) is used. Although I agree with Mauro in
principle, I think chances of above patch causing any trouble to anyone are
close to zero.

--

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

Re: [GIT PULL FOR 3.9] Exynos SoC media drivers updates

2013-01-06 Thread Mauro Carvalho Chehab 
Em Sun, 06 Jan 2013 13:58:59 +0100
Sylwester Nawrocki sylvester.nawro...@gmail.com escreveu:

 On 01/06/2013 01:05 PM, Mauro Carvalho Chehab wrote:
  Related patchwork commands:
 
  pwclient update -s 'accepted' 15333
  pwclient update -s 'accepted' 15565
  pwclient update -s 'accepted' 16071
  pwclient update -s 'accepted' 16072
  pwclient update -s 'accepted' 16073
  pwclient update -s 'accepted' 15657
  pwclient update -s 'accepted' 15656
  pwclient update -s 'accepted' 15658
  pwclient update -s 'accepted' 15659
  pwclient update -s 'accepted' 15660
  pwclient update -s 'accepted' 15661
  pwclient update -s 'accepted' 16013
  pwclient update -s 'superseded' 16059
  pwclient update -s 'accepted' 16060
  pwclient update -s 'accepted' 16080
  pwclient update -s 'accepted' 16081
  pwclient update -s 'accepted' 16084
  pwclient update -s 'accepted' 15647
  pwclient update -s 'superseded' 16083
  pwclient update -s 'accepted' 15765
 
  Those status updates were missing:
 
  pwclient update -s 'superseded' 14608
  pwclient update -s 'superseded' 15188
  pwclient update -s 'accepted' 16058
 
 OK, sorry. Just learning to use the tools, will try to do better
 next time. :)

No problem.

  pwclient update -s 'accepted' 16108
 
 And that's the pull request itself, I've obviously missed it.

Yeah ;) Well, you shouldn't include it. Sorry to add it at the
list.

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 PULL FOR 3.9] Exynos SoC media drivers updates

2013-01-06 Thread Mauro Carvalho Chehab 
Em Sun, 06 Jan 2013 14:15:44 +0100
Sylwester Nawrocki sylvester.nawro...@gmail.com escreveu:

 On 01/06/2013 01:53 PM, Hans Verkuil wrote:
  Tomasz Stanislawski (1):
   s5p-tv: mixer: fix handling of VIDIOC_S_FMT
 
  I'll drop this one for now. Devin raised a point: such changes would 
  break
  existing applications.
 
  So, we'll need to revisit this topic before changing the drivers.
 
  Btw, I failed to find the corresponding patch at patchwork:
   
  http://patchwork.linuxtv.org/project/linux-media/list/?state=*q=VIDIOC_S_FMT
 
  So, its status update may be wrong after flushing your pwclient commands.
 
  Hmm, I got this patch from Tomasz by e-mail and added it to the pull
  request.
  I think it wasn't sent to the mailing list, but I noticed it only after
  sending you the pull requests, when was preparing the pwclient commands.
  I've just posted it now, sorry. The link is here:
  http://patchwork.linuxtv.org/patch/16143
 
  Tomasz created this patch specifically for the purpose of format 
  negotiation
  in video pipeline in the application we used to test various scenarios 
  with
  DMABUF. I agree this patch has a potential of breaking buggy user space
  applications. I can't see other solution for it right now, there seems 
  even
  to be no possibility to return some flag in VIDIOC_S_FMT indicating that
  format has been modified and is valid, when -EINVAL was returned. This
  sounds
  ugly anyway, but could ensure backward compatibility for applications that
  exppect EINVAL when format has been changed. BTW, I wonder if it is only
  fourcc,
  or other format parameters as well - like width, height, some applications
  expect to get EINVAL when those have changed.
 
  The patch makes the driver compliant to v4l-compilance, as its behavior 
  asks
  for such change, after some discussions we had this year in San Diego. At 
  that
  time, we all believed that such change were safe.
 
  However, we can't do it like proposed there (and on other patches from 
  Hans).
 
  The fact is that tvtime and mythtv applications (maybe more) will fail
  if the returned format is different than the requested ones, as they
  don't check for the returned value.
 
  As no regressions on userspace are allowed, we need to re-discuss this 
  issue.
 
  While this doesn't happen, I'll postpone such patches.
 
  This is a video output device. So this patch will never affect 
  tvtime/mythtv/etc.
  I have no problem with this change being merged.
 
 TBH, I very much doubt anyone would complain in case of this driver. I'm not
 certain if there is complete support for even one board in the mainline 
 kernel,
 likely only Origen A. AFAIK most applications use either Exynos DRM driver,
 that has support for all features available in s5p-tv driver, or 
 framebuffer
 emulation on top of v4l2 output interface (there were in the past RFC 
 patches
 posted for vb2 adding FB emulation) is used. Although I agree with Mauro in
 principle, I think chances of above patch causing any trouble to anyone are
 close to zero.

Yes, I see your point. Yet, it doesn't hurt to keep it on hold for a couple
weeks while we discuss it at the ML.

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

Status of the patches under review at LMML (35 patches)

2013-01-06 Thread Mauro Carvalho Chehab 
This is the summary of the patches that are currently under review at
Linux Media Mailing List linux-media@vger.kernel.org.
Each patch is represented by its submission date, the subject (up to 70
chars) and the patchwork link (if submitted via email).

P.S.: This email is c/c to the developers where some action is expected.
  If you were copied, please review the patches, acking/nacking or
  submitting an update.


== New patches == 

Those patches require some review from the community:

This one could break again DVB-S-DVB-S2 support, so, it needs to be
carefully reviewed and tested:

Jun,21 2012: [media] dvb frontend core: tuning in ISDB-T using DVB API v3   
http://patchwork.linuxtv.org/patch/12988  Olivier Grenie 
olivier.gre...@parrot.com

This one fix a code that, IMHO, should, instead be replaced by
something better:
Sep,17 2012: [3/3] cx25821: Cleanup filename assignment code
http://patchwork.linuxtv.org/patch/14445  Peter Senna Tschudin 
peter.se...@gmail.com

This one doesn't seem right for me. Anybody can test/work with it?
Sep, 2 2012: fix: iMon Knob event interpretation issues 
http://patchwork.linuxtv.org/patch/16030  Alexandre Lissy 
alexandreli...@free.fr

I'm not sure if we should apply this one or not, as it will increase
the probability of miss-interpreting a nec IR protocol. Comments?
Jul,26 2012: media: rc: Add support to decode Remotes using NECx IR protocol
http://patchwork.linuxtv.org/patch/13480  Ravi Kumar V 
kumar...@codeaurora.org


== Manu Abraham abraham.m...@gmail.com == 

Those patches are there for a long time. I think I'll simply apply all of
them, if they're not reviewed on the next couple weeks:

Mar,11 2012: [2/3] stv090x: use error counter 1 for BER estimation  
http://patchwork.linuxtv.org/patch/10301  Andreas Regel 
andreas.re...@gmx.de
Mar,11 2012: [3/3] stv090x: On STV0903 do not set registers of the second path. 
http://patchwork.linuxtv.org/patch/10302  Andreas Regel 
andreas.re...@gmx.de
Nov,29 2011: stv090x: implement function for reading uncorrected blocks count   
http://patchwork.linuxtv.org/patch/8656   Mariusz Bia?o?czyk 
ma...@skyboo.net
Jun, 8 2011: Add remote control support for mantis  
http://patchwork.linuxtv.org/patch/7217   Christoph Pinkl 
christoph.pi...@gmail.com
Apr, 1 2012: [05/11] Slightly more friendly debugging output.   
http://patchwork.linuxtv.org/patch/10520  Steinar H. Gunderson 
se...@samfundet.no
Apr, 1 2012: [06/11] Replace ca_lock by a slightly more general int_stat_lock.  
http://patchwork.linuxtv.org/patch/10521  Steinar H. Gunderson 
se...@samfundet.no
Apr, 1 2012: [07/11] Fix a ton of SMP-unsafe accesses.  
http://patchwork.linuxtv.org/patch/10523  Steinar H. Gunderson 
se...@samfundet.no
Apr, 1 2012: [08/11] Remove some unused structure members.  
http://patchwork.linuxtv.org/patch/10525  Steinar H. Gunderson 
se...@samfundet.no
Apr, 1 2012: [09/11] Correct wait_event_timeout error return check. 
http://patchwork.linuxtv.org/patch/10526  Steinar H. Gunderson 
se...@samfundet.no
Apr, 1 2012: [10/11] Ignore timeouts waiting for the IRQ0 flag. 
http://patchwork.linuxtv.org/patch/10527  Steinar H. Gunderson 
se...@samfundet.no
Apr, 1 2012: [11/11] Enable Mantis CA support.  
http://patchwork.linuxtv.org/patch/10524  Steinar H. Gunderson 
se...@samfundet.no

== Prabhakar Lad prabhakar@ti.com == 

Aug,24 2012: Corrected Oops on omap_vout when no manager is connected   
http://patchwork.linuxtv.org/patch/14033  Federico Fuga 
f...@studiofuga.com
Oct,22 2012: [media] davinci: vpbe: fix missing unlock on error in 
vpbe_initialize( http://patchwork.linuxtv.org/patch/15106  Wei Yongjun 
yongjun_...@trendmicro.com.cn
Oct,24 2012: [media] vpif_display: fix return value check in vpif_reqbufs() 
http://patchwork.linuxtv.org/patch/15167  Wei Yongjun 
yongjun_...@trendmicro.com.cn

== Maxim Levitsky maximlevit...@gmail.com == 

Oct,15 2012: [1/4,media] ene-ir: Fix cleanup on probe failure   
http://patchwork.linuxtv.org/patch/15024  Matthijs Kooijman 
matth...@stdin.nl

== Guennadi Liakhovetski g.liakhovet...@gmx.de == 

Oct,30 2012: [v2,2/4] media: mx2_camera: Add image size HW limits.  
http://patchwork.linuxtv.org/patch/15298  Javier Martin 
javier.mar...@vista-silicon.com
Nov,13 2012: sh_vou: Move from videobuf to videobuf2
http://patchwork.linuxtv.org/patch/15433  Laurent Pinchart 
laurent.pinchart+rene...@ideasonboard.com
Nov,16 2012: [05/14,media] atmel-isi: Update error check for unsigned variables 
http://patchwork.linuxtv.org/patch/15475  Tushar Behera 
tushar.beh...@linaro.org
Jan, 3

Re: [PATCH] ts2020: call get_rf_strength from frontend

2013-01-06 Thread Antti Palosaari 

On 01/06/2013 02:40 PM, Malcolm Priestley wrote:

Restore ds3000.c read_signal_strength.

Call tuner get_rf_strength from frontend read_signal_strength.

We are able to do a NULL check and doesn't limit the tuner
attach to the frontend attach area.

At the moment the lmedm04 tuner attach is stuck in frontend
attach area.


I would like to nack that, as I see some problems:
1) it changes deviation against normal procedures
2) interface driver (usb/pci) should have full control to make decision
3) you shoot to our own leg easily in power management

* actually bug 3) already happened some drivers, like rtl28xxu. Tuner is 
behind demod and demod is put sleep = no access to tuner. FE callback 
is overridden (just like you are trying to do as default) which means 
user-space could still make queries = I/O errors.


Antti




Signed-off-by: Malcolm Priestley tvbox...@gmail.com
---
  drivers/media/dvb-frontends/ds3000.c| 10 ++
  drivers/media/dvb-frontends/m88rs2000.c |  4 +++-
  drivers/media/dvb-frontends/ts2020.c|  1 -
  3 files changed, 13 insertions(+), 2 deletions(-)

diff --git a/drivers/media/dvb-frontends/ds3000.c 
b/drivers/media/dvb-frontends/ds3000.c
index d128f85..1e344b0 100644
--- a/drivers/media/dvb-frontends/ds3000.c
+++ b/drivers/media/dvb-frontends/ds3000.c
@@ -533,6 +533,15 @@ static int ds3000_read_ber(struct dvb_frontend *fe, u32* 
ber)
return 0;
  }

+static int ds3000_read_signal_strength(struct dvb_frontend *fe,
+   u16 *signal_strength)
+{
+   if (fe-ops.tuner_ops.get_rf_strength)
+   fe-ops.tuner_ops.get_rf_strength(fe, signal_strength);
+
+   return 0;
+}
+
  /* calculate DS3000 snr value in dB */
  static int ds3000_read_snr(struct dvb_frontend *fe, u16 *snr)
  {
@@ -1102,6 +,7 @@ static struct dvb_frontend_ops ds3000_ops = {
.i2c_gate_ctrl = ds3000_i2c_gate_ctrl,
.read_status = ds3000_read_status,
.read_ber = ds3000_read_ber,
+   .read_signal_strength = ds3000_read_signal_strength,
.read_snr = ds3000_read_snr,
.read_ucblocks = ds3000_read_ucblocks,
.set_voltage = ds3000_set_voltage,
diff --git a/drivers/media/dvb-frontends/m88rs2000.c 
b/drivers/media/dvb-frontends/m88rs2000.c
index 283c90f..4da5272 100644
--- a/drivers/media/dvb-frontends/m88rs2000.c
+++ b/drivers/media/dvb-frontends/m88rs2000.c
@@ -446,7 +446,9 @@ static int m88rs2000_read_ber(struct dvb_frontend *fe, u32 
*ber)
  static int m88rs2000_read_signal_strength(struct dvb_frontend *fe,
u16 *strength)
  {
-   *strength = 0;
+   if (fe-ops.tuner_ops.get_rf_strength)
+   fe-ops.tuner_ops.get_rf_strength(fe, strength);
+
return 0;
  }

diff --git a/drivers/media/dvb-frontends/ts2020.c 
b/drivers/media/dvb-frontends/ts2020.c
index f50e237..ad7ad85 100644
--- a/drivers/media/dvb-frontends/ts2020.c
+++ b/drivers/media/dvb-frontends/ts2020.c
@@ -363,7 +363,6 @@ struct dvb_frontend *ts2020_attach(struct dvb_frontend *fe,

memcpy(fe-ops.tuner_ops, ts2020_tuner_ops,
sizeof(struct dvb_tuner_ops));
-   fe-ops.read_signal_strength = fe-ops.tuner_ops.get_rf_strength;

return fe;
  }




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

Re: [PATCH 3/3] [media] s5p-mfc: Use of_match_ptr and CONFIG_OF

2013-01-06 Thread Sylwester Nawrocki 

Hi Sachin,

On 12/28/2012 11:18 AM, Sachin Kamat wrote:

This builds the code only if DT is enabled.


Since the driver this patch touches is for platforms that in (not distant)
future will be DT only I don't really see an advantage of applying it,
only to need to revert it after few kernel releases.

I realize this exynos_mfc_match[] array's size is ~400 B, but still I'd
prefer to avoid such #ifdefs.


Signed-off-by: Sachin Kamatsachin.ka...@linaro.org
---
  drivers/media/platform/s5p-mfc/s5p_mfc.c |4 +++-
  1 files changed, 3 insertions(+), 1 deletions(-)

diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc.c 
b/drivers/media/platform/s5p-mfc/s5p_mfc.c
index 3930177..65ed603 100644
--- a/drivers/media/platform/s5p-mfc/s5p_mfc.c
+++ b/drivers/media/platform/s5p-mfc/s5p_mfc.c
@@ -1405,6 +1405,7 @@ static struct platform_device_id mfc_driver_ids[] = {
  };
  MODULE_DEVICE_TABLE(platform, mfc_driver_ids);

+#ifdef CONFIG_OF
  static const struct of_device_id struct of_device_id[] = {
{
.compatible = samsung,mfc-v5,
@@ -1416,6 +1417,7 @@ static const struct of_device_id exynos_mfc_match[] = {
{},
  };
  MODULE_DEVICE_TABLE(of, exynos_mfc_match);
+#endif




  static void *mfc_get_drv_data(struct platform_device *pdev)
  {
@@ -1442,7 +1444,7 @@ static struct platform_driver s5p_mfc_driver = {
.name   = S5P_MFC_NAME,
.owner  = THIS_MODULE,
.pm =s5p_mfc_pm_ops,
-   .of_match_table = exynos_mfc_match,
+   .of_match_table = of_match_ptr(exynos_mfc_match),
},
  };



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

Re: How to configure resizer in ISP pipeline?

2013-01-06 Thread Sakari Ailus 
Hi Andreas,

Andreas Nagel wrote:
 Hi Sakari,
 
 thanks for helping.
 
 My sensor (TVP5146) already provides YUV data, so I can skip the
 previewer. I tried setting the input and output pad of the resizer
 subdevice to incoming resolution (input pad) and desired resolution
 (output pad). For example: 720x576 -- 352x288. But it didn't work
 out quite well.
 How did it not work quite well? :)
 
 Not sure, if I recall all the details. I haven't done much in this area
 for a few weeks now.
 Currently, I actually can configure the resizer, but then
 VIDIOC_STREAMON fails with EINVAL when I configure the devnode. Don't
 know why.
 I do connect the resizer source to the resizer output (devnode) and then
 capture from there. I think it is /dev/video6.
 If I leave the resizer out and connect the ccdc source to the ccdc
 output (/dev/video2), capturing works just fine.
 
 One reason could be, that the resizer isn't supported right now. (You
 remember, I have to use Technexion's TI kernel 2.6.37 with its exotic
 ISP driver. ;-) )

Ouch. There have been many bugfixes and improvements in the omap3isp
driver since it was merged to mainline in this area. I don't know what
TI has backported to their own kernel; it could be something is missing
there.

The fact the ABI and API are incompatible with what's now in mainline
suggests that quite a lot may be missing.

 That's, what one could interpret from this TI wiki page.
 http://processors.wiki.ti.com/index.php/UserGuideOmap35xCaptureDriver_PSP_04.02.00.07#Architecture
 
 Under the block diagram, there's a note saying, that only the path with
 the continuous line has been validated. So, the dotted lines are ISP
 paths that might not have been validated (supported?) yet.

That's very possible.

 (I might add, that all this is part of my master thesis and resizing
 would be a nice-to-have goal, but not a must-have. So I can live with it
 if it won't work.)

Good to hear that... I guess the best starting point to get things
working would definitely be the mainline kernel. The rest is at best
unsupported.

-- 
Kind regards,

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

[PATCH RFCv6] dvb: Add DVBv5 stats properties for Quality of Service

2013-01-06 Thread Mauro Carvalho Chehab 
The DVBv3 quality parameters are limited on several ways:

- Doesn't provide any way to indicate the used measure,
  so userspace need to guess how to calculate the measure;

- Only a limited set of stats are supported;

- Can't be called in a way to require them to be filled
  all at once (atomic reads from the hardware), with may
  cause troubles on interpreting them on userspace;

- On some OFDM delivery systems, the carriers can be
  independently modulated, having different properties.
  Currently, there's no way to report per-layer stats.

To address the above issues, adding a new DVBv5-based stats
API.

Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com

---

v6: Add DocBook documentation.

TODO:
- Add methods at the core to periodically collect, store
  the statistics and reset the counters;
- Add a driver implementation.
---
 Documentation/DocBook/media/dvb/dvbproperty.xml | 105 +++-
 include/uapi/linux/dvb/frontend.h   |  67 ++-
 2 files changed, 169 insertions(+), 3 deletions(-)

diff --git a/Documentation/DocBook/media/dvb/dvbproperty.xml 
b/Documentation/DocBook/media/dvb/dvbproperty.xml
index 957e3ac..5413775 100644
--- a/Documentation/DocBook/media/dvb/dvbproperty.xml
+++ b/Documentation/DocBook/media/dvb/dvbproperty.xml
@@ -7,16 +7,29 @@ the capability ioctls weren't implemented yet via the new 
way./para
 paraThe typical usage for the 
constantFE_GET_PROPERTY/FE_SET_PROPERTY/constant
 API is to replace the ioctl's were the link linkend=dvb-frontend-parameters
 struct constantdvb_frontend_parameters/constant/link were used./para
+section id=dtv-stats
+titleDTV stats type/title
+programlisting
+struct dtv_stats {
+__u16 value;
+__u8 scale;
+} __attribute__ ((packed));
+/programlisting
+/section
 section id=dtv-property
 titleDTV property type/title
 programlisting
 /* Reserved fields should be set to 0 */
+
 struct dtv_property {
__u32 cmd;
union {
__u32 data;
struct {
-   __u8 data[32];
+   union {
+   __u8 data[32];
+   __u16 data[16];
+   }
__u32 len;
__u32 reserved1[3];
void *reserved2;
@@ -850,6 +863,86 @@ enum fe_interleaving {
parause the special macro LNA_AUTO to set LNA auto/para
/section
 /section
+
+   section id=frontend-qos-properties
+   titleFrontend Quality of Service/Statistics indicators/title
+   paraExcept for link 
linkend=DTV-QOS-ENUMconstantDTV_QOS_ENUM/constant/link,
+   the values are returned via 
constantdtv_property.stat/constant./para
+   paraFor most delivery systems, this will return a single value for 
each parameter./para
+   paraIt should be noticed, however, that new OFDM delivery systems 
+   like ISDB can use different modulation types for each group of carriers.
+   On such standards, up to 8 groups of statistics can be provided, one
+   for each carrier group (called layer on ISDB).
+   In order to be consistent with other delivery systems, the first
+   value at link 
linkend=dtv-statsconstantdtv_property.stat.dtv_stats/constant/link 
array refers to
+   a global indicator, if any. The other elements of the array represent
+   each layer, starting from layer A(index 1), layer B (index 2) and so 
on/para
+   paraThe number of filled elements are stored at 
constantdtv_property.stat.len/constant./para
+   paraEach element of the 
constantdtv_property.stat.dtv_stats/constant array consists on two 
elements:/para
+   itemizedlist mark='opencircle'
+   listitemparaconstantvalue/constant - Value of the 
measure/para/listitem
+   listitemparaconstantscale/constant - Scale for the 
value. It can be:/para
+   section id = fecap-scale-params
+   itemizedlist mark='bullet'
+   
listitemparaconstantFE_SCALE_NOT_AVAILABLE/constant - If it is not 
possible to collect a given parameter (could be a transitory or permanent 
condition)/para/listitem
+   
listitemparaconstantFE_SCALE_DECIBEL/constant - parameter is a signed 
value, measured in 0.1 dB/para/listitem
+   
listitemparaconstantFE_SCALE_RELATIVE/constant - parameter is a 
unsigned value, where 0 means 0% and 65535 means 100%./para/listitem
+   /itemizedlist
+   /section
+   /listitem
+   /itemizedlist
+   section id=DTV-QOS-ENUM
+   titleconstantDTV_QOS_ENUM/constant/title
+   paraA frontend needs to advertise the statistics it provides. 
This property allows to enumerate all
+   link

Re: [linux-media] Re: [PATCH RFCv3] dvb: Add DVBv5 properties for quality parameters

2013-01-06 Thread Mauro Carvalho Chehab 
Em Thu, 03 Jan 2013 23:33:49 +0200
Antti Palosaari cr...@iki.fi escreveu:

 On 01/03/2013 06:29 PM, Mauro Carvalho Chehab wrote:
  Em Thu, 3 Jan 2013 14:14:29 -0200
  Mauro Carvalho Chehab mche...@redhat.com escreveu:
 
  Em Thu, 03 Jan 2013 16:18:26 +0100
  Klaus Schmidinger klaus.schmidin...@tvdr.de escreveu:
 
  On 03.01.2013 14:20, Mauro Carvalho Chehab wrote:
  Em Wed, 2 Jan 2013 00:38:50 +0530
  Manu Abraham abraham.m...@gmail.com escreveu:
 
  On Tue, Jan 1, 2013 at 10:59 PM, Mauro Carvalho Chehab
  mche...@redhat.com wrote:
  Em Tue, 1 Jan 2013 22:18:49 +0530
  Manu Abraham abraham.m...@gmail.com escreveu:
 
  On Tue, Jan 1, 2013 at 8:30 PM, Mauro Carvalho Chehab
  mche...@redhat.com wrote:
 
  [RFCv4] dvb: Add DVBv5 properties for quality parameters
 
  The DVBv3 quality parameters are limited on several ways:
- Doesn't provide any way to indicate the used measure;
- Userspace need to guess how to calculate the measure;
- Only a limited set of stats are supported;
- Doesn't provide QoS measure for the OFDM TPS/TMCC
  carriers, used to detect the network parameters for
  DVB-T/ISDB-T;
- Can't be called in a way to require them to be filled
  all at once (atomic reads from the hardware), with may
  cause troubles on interpreting them on userspace;
- On some OFDM delivery systems, the carriers can be
  independently modulated, having different properties.
  Currently, there's no way to report per-layer stats;
 
  per layer stats is a mythical bird, nothing of that sort does exist.
 
  Had you ever read or tried to get stats from an ISDB-T demod? If you
  had, you would see that it only provides per-layer stats. Btw, this is
  a requirement to follow the ARIB and ABNT ISDB specs.
 
  I understand you keep writing junk for ages, but nevertheless:
 
  Do you have any idea what's a BBHEADER (DVB-S2) or
  PLHEADER (DVB-T2) ? The headers do indicate what MODCOD
  (aka Modulation/Coding Standard follows, whatever mode ACM,
  VCM or CCM) follows. These MODCOD foolows a TDM approach
  with a hierarchial modulation principle. This is exactly what ISDB
  does too.
 
  No, I didn't check DVB-S2/T2 specs deeply enough to understand
  if they're doing the same thing as ISDB.
 
  Yet, ISDB-T doesn't use a TDM approach for hierarchical modulation.
  It uses a FDM (OFDM is a type of Frequency Division Multiplexing).
 
  So, if you're saying that DVB-S2 uses TDM, it is very different than
  ISDB-T. As DVB-T2 uses an FDM type of modulation (OFDM), it would
  be possible to segment the carriers there, just like ISDB, or to
  use TDM hierarchical modulation techniques.
 
 
  And for your info:
 
   The TMCC control information is
  common to all TMCC carriers and
  error correction is performed by using
  difference-set cyclic code.
 
  Yes, TMCC carriers are equal and they are always modulated using DBPSK.
  That is done to make it possible to receive the TMCC carriers even under
  worse SNR conditions, where it may not be possible to decode the segment
  groups.
 
  It seems that you completely missed the point though. On ISDB-T, the
  carriers that belong to each group of segments (except for the control
  carriers - carriers 1 to 107) uses a completely independent modulation.
  Also, as they're spaced in frequency, the interference of each segment
  is different. So, error indications are different on each segment.
 
  Btw, in any case, the datasheets of ISDB-T demods clearly shows that
  the BER measures are per segment group (layer).
 
  For example, for the BER measures before Viterbi, those are the register
  names for a certain demod:
 
   VBERSNUMA Bit count of BER measurement before Viterbi in A layer
   VBERSNUMB Bit count of BER measurement before Viterbi in B layer
   VBERSNUMC Bit count of BER measurement before Viterbi in C layer
 
  It has another set of registers for BER after Viterbi, and for PER after
  Viterbi and RS, for bit count errors, etc.
 
  There's no way to get any type of global BER measure, simply because
  ISDB-T demods don't provide.
 
  Maybe we should put all this theoretical discussion aside for the moment 
  and
  think about what is *really* needed by real world applications. As with 
  any
  receiver, VDR simply wants to have some measure of the signal's strength
  and quality. These are just two values that should be delivered by each
  frontend/demux, using the *same* defined and mandatory range. I don't care
  what exactly that is, but it needs to be the same for all devices.
  What values a particular driver uses internally to come up with these
  is of no interest to VDR. The signal strength might just be what is
  currently returned through FE_READ_SIGNAL_STRENGTH (however, normalized to
  the same range in all drivers, which currently is not the case). The 
  signal
  quality might use flags like FE_HAS_SIGNAL, FE_HAS_CARRIER,

Re: [PATCH v3 2/4] videobuf2-dma-streaming: new videobuf2 memory allocator

2013-01-06 Thread Federico Vaga 
 I have more information about DMA on the board that I'm using; probably, I
 can make dma-contig work with my device.

Ok, the driver STA2X11 now works with a patched dma-contig allocator. So, my 
streaming allocator it is not mandatory. 

I based my work on the previous work made by Windriver, but now I understand 
the DMA problem and the solution easy.
I investigated (asked to Alessandro Rubini who worked on this board) about 
this DMA issue. The problem is that on the sta2x11 architecture only the first 
512MB are available through the PCI bus, but the allocator can allocate memory 
for DMA above this limit. By using GFP_DMA flags the allocation take place 
under the 16MB so it works.

If you think that the streaming allocator can be useful for someone else (who 
has performance problem with uncached DMA like Jonathan when he did dma-nc 
allocator), I can resend the patch.
I cannot do performance test at the moment because I don't have the time, so I 
cannot personally justify the presence of a new allocator. I think that I will 
do some performance test with this driver; if I will find that dma-streaming 
works better I will propose it again.

I will propose V4 patches soon.

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

[PATCH 1/3] [media] winbond-cir: only enable higher sample resolution if needed

2013-01-06 Thread Sean Young 
A sample resolution of 2us generates more than 300 interrupts per key
and this resolution is not needed unless carrier reports are enabled.

Revert to a resolution of 10us unless carrier reports are needed. This
generates up to a fifth of the interrupts.

Signed-off-by: Sean Young s...@mess.org
---
 drivers/media/rc/winbond-cir.c | 27 +++
 1 file changed, 19 insertions(+), 8 deletions(-)

diff --git a/drivers/media/rc/winbond-cir.c b/drivers/media/rc/winbond-cir.c
index 553d1cd..66f543c 100644
--- a/drivers/media/rc/winbond-cir.c
+++ b/drivers/media/rc/winbond-cir.c
@@ -154,6 +154,8 @@
 #define WBCIR_CNTR_R   0x02
 /* Invert TX */
 #define WBCIR_IRTX_INV 0x04
+/* Receiver oversampling */
+#define WBCIR_RX_T_OV  0x40
 
 /* Valid banks for the SP3 UART */
 enum wbcir_bank {
@@ -394,7 +396,8 @@ wbcir_irq_rx(struct wbcir_data *data, struct pnp_dev 
*device)
if (data-rxstate == WBCIR_RXSTATE_ERROR)
continue;
 
-   duration = ((irdata  0x7F) + 1) * 2;
+   duration = ((irdata  0x7F) + 1) *
+   (data-carrier_report_enabled ? 2 : 10);
rawir.pulse = irdata  0x80 ? false : true;
rawir.duration = US_TO_NS(duration);
 
@@ -550,6 +553,17 @@ wbcir_set_carrier_report(struct rc_dev *dev, int enable)
wbcir_set_bits(data-ebase + WBCIR_REG_ECEIR_CCTL,
WBCIR_CNTR_EN, WBCIR_CNTR_EN | WBCIR_CNTR_R);
 
+   /* Set a higher sampling resolution if carrier reports are enabled */
+   wbcir_select_bank(data, WBCIR_BANK_2);
+   data-dev-rx_resolution = US_TO_NS(enable ? 2 : 10);
+   outb(enable ? 0x03 : 0x0f, data-sbase + WBCIR_REG_SP3_BGDL);
+   outb(0x00, data-sbase + WBCIR_REG_SP3_BGDH);
+
+   /* Enable oversampling if carrier reports are enabled */
+   wbcir_select_bank(data, WBCIR_BANK_7);
+   wbcir_set_bits(data-sbase + WBCIR_REG_SP3_RCCFG,
+   enable ? WBCIR_RX_T_OV : 0, WBCIR_RX_T_OV);
+
data-carrier_report_enabled = enable;
spin_unlock_irqrestore(data-spinlock, flags);
 
@@ -931,8 +945,8 @@ wbcir_init_hw(struct wbcir_data *data)
/* prescaler 1.0, tx/rx fifo lvl 16 */
outb(0x30, data-sbase + WBCIR_REG_SP3_EXCR2);
 
-   /* Set baud divisor to sample every 2 ns */
-   outb(0x03, data-sbase + WBCIR_REG_SP3_BGDL);
+   /* Set baud divisor to sample every 10 us */
+   outb(0x0f, data-sbase + WBCIR_REG_SP3_BGDL);
outb(0x00, data-sbase + WBCIR_REG_SP3_BGDH);
 
/* Set CEIR mode */
@@ -941,12 +955,9 @@ wbcir_init_hw(struct wbcir_data *data)
inb(data-sbase + WBCIR_REG_SP3_LSR); /* Clear LSR */
inb(data-sbase + WBCIR_REG_SP3_MSR); /* Clear MSR */
 
-   /*
-* Disable RX demod, enable run-length enc/dec, set freq span and
-* enable over-sampling
-*/
+   /* Disable RX demod, enable run-length enc/dec, set freq span */
wbcir_select_bank(data, WBCIR_BANK_7);
-   outb(0xd0, data-sbase + WBCIR_REG_SP3_RCCFG);
+   outb(0x90, data-sbase + WBCIR_REG_SP3_RCCFG);
 
/* Disable timer */
wbcir_select_bank(data, WBCIR_BANK_4);
-- 
1.7.11.7

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

[PATCH 2/3] [media] iguanair: ensure transmission mask is initialized

2013-01-06 Thread Sean Young 
Signed-off-by: Sean Young s...@mess.org
---
 drivers/media/rc/iguanair.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/media/rc/iguanair.c b/drivers/media/rc/iguanair.c
index 5a9163d..a569c69 100644
--- a/drivers/media/rc/iguanair.c
+++ b/drivers/media/rc/iguanair.c
@@ -512,6 +512,7 @@ static int __devinit iguanair_probe(struct usb_interface 
*intf,
rc-rx_resolution = RX_RESOLUTION;
 
iguanair_set_tx_carrier(rc, 38000);
+   iguanair_set_tx_mask(rc, 0);
 
ret = rc_register_device(rc);
if (ret  0) {
-- 
1.7.11.7

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

[PATCH 3/3] [media] iguanair: intermittent initialization failure

2013-01-06 Thread Sean Young 
Sometimes the first version request is sent before the device has fully
initialized. This seems to happen on some hardware during boot when the
iguanair is plugged into a root hub.

Signed-off-by: Sean Young s...@mess.org
---
 drivers/media/rc/iguanair.c | 19 ++-
 1 file changed, 10 insertions(+), 9 deletions(-)

diff --git a/drivers/media/rc/iguanair.c b/drivers/media/rc/iguanair.c
index a569c69..bc3557b 100644
--- a/drivers/media/rc/iguanair.c
+++ b/drivers/media/rc/iguanair.c
@@ -224,6 +224,14 @@ static int iguanair_get_features(struct iguanair *ir)
ir-packet-header.cmd = CMD_GET_VERSION;
 
rc = iguanair_send(ir, sizeof(ir-packet-header));
+
+   /*
+* We might have sent the command before the device had time to
+* initialize. Retry if we got no response.
+*/
+   if (rc == -ETIMEDOUT)
+   rc = iguanair_send(ir, sizeof(ir-packet-header));
+
if (rc) {
dev_info(ir-dev, failed to get version\n);
goto out;
@@ -255,19 +263,14 @@ static int iguanair_get_features(struct iguanair *ir)
ir-packet-header.cmd = CMD_GET_FEATURES;
 
rc = iguanair_send(ir, sizeof(ir-packet-header));
-   if (rc) {
+   if (rc)
dev_info(ir-dev, failed to get features\n);
-   goto out;
-   }
-
 out:
return rc;
 }
 
 static int iguanair_receiver(struct iguanair *ir, bool enable)
 {
-   int rc;
-
ir-packet-header.start = 0;
ir-packet-header.direction = DIR_OUT;
ir-packet-header.cmd = enable ? CMD_RECEIVER_ON : CMD_RECEIVER_OFF;
@@ -275,9 +278,7 @@ static int iguanair_receiver(struct iguanair *ir, bool 
enable)
if (enable)
ir_raw_event_reset(ir-rc);
 
-   rc = iguanair_send(ir, sizeof(ir-packet-header));
-
-   return rc;
+   return iguanair_send(ir, sizeof(ir-packet-header));
 }
 
 /*
-- 
1.7.11.7

--
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 v4 1/3] videobuf2-dma-contig: user can specify GFP flags

2013-01-06 Thread Federico Vaga 
This is useful when you need to specify specific GFP flags during memory
allocation (e.g. GFP_DMA).

Signed-off-by: Federico Vaga federico.v...@gmail.com
---
 drivers/media/v4l2-core/videobuf2-dma-contig.c | 7 ++-
 include/media/videobuf2-dma-contig.h   | 5 +
 2 file modificati, 7 inserzioni(+), 5 rimozioni(-)

diff --git a/drivers/media/v4l2-core/videobuf2-dma-contig.c 
b/drivers/media/v4l2-core/videobuf2-dma-contig.c
index 10beaee..bb411c0 100644
--- a/drivers/media/v4l2-core/videobuf2-dma-contig.c
+++ b/drivers/media/v4l2-core/videobuf2-dma-contig.c
@@ -21,10 +21,6 @@
 #include media/videobuf2-dma-contig.h
 #include media/videobuf2-memops.h
 
-struct vb2_dc_conf {
-   struct device   *dev;
-};
-
 struct vb2_dc_buf {
struct device   *dev;
void*vaddr;
@@ -165,7 +161,8 @@ static void *vb2_dc_alloc(void *alloc_ctx, unsigned long 
size)
/* align image size to PAGE_SIZE */
size = PAGE_ALIGN(size);
 
-   buf-vaddr = dma_alloc_coherent(dev, size, buf-dma_addr, GFP_KERNEL);
+   buf-vaddr = dma_alloc_coherent(dev, size, buf-dma_addr,
+   
GFP_KERNEL | conf-mem_flags);
if (!buf-vaddr) {
dev_err(dev, dma_alloc_coherent of size %ld failed\n, size);
kfree(buf);
diff --git a/include/media/videobuf2-dma-contig.h 
b/include/media/videobuf2-dma-contig.h
index 8197f87..22733f4 100644
--- a/include/media/videobuf2-dma-contig.h
+++ b/include/media/videobuf2-dma-contig.h
@@ -16,6 +16,11 @@
 #include media/videobuf2-core.h
 #include linux/dma-mapping.h
 
+struct vb2_dc_conf {
+   struct device   *dev;
+   gfp_t   mem_flags;
+};
+
 static inline dma_addr_t
 vb2_dma_contig_plane_dma_addr(struct vb2_buffer *vb, unsigned int plane_no)
 {
-- 
1.7.11.7

--
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 V4 2/3] sta2x11_vip: convert to videobuf2 and control framework

2013-01-06 Thread Federico Vaga 
This patch re-write the driver and use the videobuf2
interface instead of the old videobuf. Moreover, it uses also
the control framework which allows the driver to inherit
controls from its subdevice (ADV7180)

Signed-off-by: Federico Vaga federico.v...@gmail.com
Acked-by: Giancarlo Asnaghi giancarlo.asna...@st.com
---
 drivers/media/pci/sta2x11/Kconfig   |2 +-
 drivers/media/pci/sta2x11/sta2x11_vip.c | 1244 ++-
 2 file modificati, 414 inserzioni(+), 832 rimozioni(-)

diff --git a/drivers/media/pci/sta2x11/Kconfig 
b/drivers/media/pci/sta2x11/Kconfig
index 6749f67..a94ccad 100644
--- a/drivers/media/pci/sta2x11/Kconfig
+++ b/drivers/media/pci/sta2x11/Kconfig
@@ -2,7 +2,7 @@ config STA2X11_VIP
tristate STA2X11 VIP Video For Linux
depends on STA2X11
select VIDEO_ADV7180 if MEDIA_SUBDRV_AUTOSELECT
-   select VIDEOBUF_DMA_CONTIG
+   select VIDEOBUF2_DMA_CONTIG
depends on PCI  VIDEO_V4L2  VIRT_TO_BUS
help
  Say Y for support for STA2X11 VIP (Video Input Port) capture
diff --git a/drivers/media/pci/sta2x11/sta2x11_vip.c 
b/drivers/media/pci/sta2x11/sta2x11_vip.c
index ed1337a..e379e03 100644
--- a/drivers/media/pci/sta2x11/sta2x11_vip.c
+++ b/drivers/media/pci/sta2x11/sta2x11_vip.c
@@ -1,7 +1,11 @@
 /*
  * This is the driver for the STA2x11 Video Input Port.
  *
+ * Copyright (C) 2012   ST Microelectronics
+ * author: Federico Vaga federico.v...@gmail.com
  * Copyright (C) 2010   WindRiver Systems, Inc.
+ * authors: Andreas Kies andreas.k...@windriver.com
+ *  Vlad Lungu   vlad.lu...@windriver.com
  *
  * This program is free software; you can redistribute it and/or modify it
  * under the terms and conditions of the GNU General Public License,
@@ -19,36 +23,30 @@
  * The full GNU General Public License is included in this distribution in
  * the file called COPYING.
  *
- * Author: Andreas Kies andreas.k...@windriver.com
- * Vlad Lungu vlad.lu...@windriver.com
- *
  */
 
 #include linux/types.h
 #include linux/kernel.h
 #include linux/module.h
 #include linux/init.h
-#include linux/vmalloc.h
-
 #include linux/videodev2.h
-
 #include linux/kmod.h
-
 #include linux/pci.h
 #include linux/interrupt.h
-#include linux/mutex.h
 #include linux/io.h
 #include linux/gpio.h
 #include linux/i2c.h
 #include linux/delay.h
 #include media/v4l2-common.h
 #include media/v4l2-device.h
+#include media/v4l2-ctrls.h
 #include media/v4l2-ioctl.h
-#include media/videobuf-dma-contig.h
+#include media/v4l2-fh.h
+#include media/v4l2-event.h
+#include media/videobuf2-dma-contig.h
 
 #include sta2x11_vip.h
 
-#define DRV_NAME sta2x11_vip
 #define DRV_VERSION 1.3
 
 #ifndef PCI_DEVICE_ID_STMICRO_VIP
@@ -63,8 +61,8 @@
 #define DVP_TFS0x08
 #define DVP_BFO0x0C
 #define DVP_BFS0x10
-#define DVP_VTP 0x14
-#define DVP_VBP 0x18
+#define DVP_VTP0x14
+#define DVP_VBP0x18
 #define DVP_VMP0x1C
 #define DVP_ITM0x98
 #define DVP_ITS0x9C
@@ -84,43 +82,20 @@
 
 #define DVP_HLFLN_SD   0x0001
 
-#define REG_WRITE(vip, reg, value) iowrite32((value), (vip-iomem)+(reg))
-#define REG_READ(vip, reg) ioread32((vip-iomem)+(reg))
-
 #define SAVE_COUNT 8
 #define AUX_COUNT 3
 #define IRQ_COUNT 1
 
-/**
- * struct sta2x11_vip - All internal data for one instance of device
- * @v4l2_dev: device registered in v4l layer
- * @video_dev: properties of our device
- * @pdev: PCI device
- * @adapter: contains I2C adapter information
- * @register_save_area: All relevant register are saved here during suspend
- * @decoder: contains information about video DAC
- * @format: pixel format, fixed UYVY
- * @std: video standard (e.g. PAL/NTSC)
- * @input: input line for video signal ( 0 or 1 )
- * @users: Number of open of device ( max. 1 )
- * @disabled: Device is in power down state
- * @mutex: ensures exclusive opening of device
- * @slock: for excluse acces of registers
- * @vb_vidq: queue maintained by videobuf layer
- * @capture: linked list of capture buffer
- * @active: struct videobuf_buffer currently beingg filled
- * @started: device is ready to capture frame
- * @closing: device will be shut down
- * @tcount: Number of top frames
- * @bcount: Number of bottom frames
- * @overflow: Number of FIFO overflows
- * @mem_spare: small buffer of unused frame
- * @dma_spare: dma addres of mem_spare
- * @iomem: hardware base address
- * @config: I2C and gpio config from platform
- *
- * All non-local data is accessed via this structure.
- */
+
+struct vip_buffer {
+   struct vb2_buffer   vb;
+   struct list_headlist;
+   dma_addr_t  dma;
+};
+static inline struct vip_buffer *to_vip_buffer(struct vb2_buffer *vb2)
+{
+   return container_of(vb2, struct vip_buffer, vb);
+}
 
 struct sta2x11_vip {
struct v4l2_device v4l2_dev;
@@ -129,21 +104,27 @@ struct

[PATCH V4 3/3] adv7180: remove {query/g_/s_}ctrl

2013-01-06 Thread Federico Vaga 
All drivers which use this subdevice use also the control framework.
The v4l2_subdev_core_ops operations {query/g_/s_}ctrl are useless because
device drivers will inherit controls from this subdevice.

Signed-off-by: Federico Vaga federico.v...@gmail.com
---
 drivers/media/i2c/adv7180.c | 3 ---
 1 file modificato, 3 rimozioni(-)

diff --git a/drivers/media/i2c/adv7180.c b/drivers/media/i2c/adv7180.c
index 45ecf8d..43bc2b9 100644
--- a/drivers/media/i2c/adv7180.c
+++ b/drivers/media/i2c/adv7180.c
@@ -402,9 +402,6 @@ static const struct v4l2_subdev_video_ops adv7180_video_ops 
= {
 static const struct v4l2_subdev_core_ops adv7180_core_ops = {
.g_chip_ident = adv7180_g_chip_ident,
.s_std = adv7180_s_std,
-   .queryctrl = v4l2_subdev_queryctrl,
-   .g_ctrl = v4l2_subdev_g_ctrl,
-   .s_ctrl = v4l2_subdev_s_ctrl,
 };
 
 static const struct v4l2_subdev_ops adv7180_ops = {
-- 
1.7.11.7

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

Fw: [PATCH] drivers/media/usb/dvb-usb/dib0700_core.c: fix left shift

2013-01-06 Thread Mauro Carvalho Chehab 
Not sure what happened, but this patch didn't arrive linux-media.

Let me forward.

Regards,
Mauro

Forwarded message:

Date: Sat,  5 Jan 2013 14:13:05 -0500
From: Nickolai Zeldovich nicko...@csail.mit.edu
To: Mauro Carvalho Chehab mche...@redhat.com
Cc: Nickolai Zeldovich nicko...@csail.mit.edu, linux-ker...@vger.kernel.org, 
linux-media@vger.kernel.org
Subject: [PATCH] drivers/media/usb/dvb-usb/dib0700_core.c: fix left shift


Fix bug introduced in 7757ddda6f4febbc52342d82440dd4f7a7d4f14f, where
instead of bit-negating the bitmask, the bit position was bit-negated
instead.

Signed-off-by: Nickolai Zeldovich nicko...@csail.mit.edu
---
 drivers/media/usb/dvb-usb/dib0700_core.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/media/usb/dvb-usb/dib0700_core.c 
b/drivers/media/usb/dvb-usb/dib0700_core.c
index 19b5ed2..92e195a 100644
--- a/drivers/media/usb/dvb-usb/dib0700_core.c
+++ b/drivers/media/usb/dvb-usb/dib0700_core.c
@@ -587,7 +587,7 @@ int dib0700_streaming_ctrl(struct dvb_usb_adapter *adap, 
int onoff)
if (onoff)
st-channel_state |=1  (adap-id);
else
-   st-channel_state |=1  ~(adap-id);
+   st-channel_state =  ~(1  (adap-id));
} else {
if (onoff)
st-channel_state |=1  
(adap-fe_adap[0].stream.props.endpoint-2);
-- 
1.7.10.4



-- 

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

Fw: [PATCH] media: cx18, ivtv: do not dereference array before index check

2013-01-06 Thread Mauro Carvalho Chehab 
This one also didn't arrive.

I only noticed those two messages because I cleaned today my patchwork's
queue and didn't notice them arriving at patchwork on linuxtv.org.

Regards,
Mauro

Forwarded message:

Date: Sat,  5 Jan 2013 14:11:56 -0500
From: Nickolai Zeldovich nicko...@csail.mit.edu
To: Andy Walls awa...@md.metrocast.net,Mauro Carvalho Chehab 
mche...@redhat.com
Cc: Nickolai Zeldovich nicko...@csail.mit.edu, linux-ker...@vger.kernel.org, 
linux-media@vger.kernel.org
Subject: [PATCH] media: cx18, ivtv: do not dereference array before index check


Move dereferencing of hw_devicenames[], hw_bus[] arrays until after
checking that idx is within range.

Signed-off-by: Nickolai Zeldovich nicko...@csail.mit.edu
---
 drivers/media/pci/cx18/cx18-i2c.c |   10 +++---
 drivers/media/pci/ivtv/ivtv-i2c.c |5 -
 2 files changed, 11 insertions(+), 4 deletions(-)

diff --git a/drivers/media/pci/cx18/cx18-i2c.c 
b/drivers/media/pci/cx18/cx18-i2c.c
index 4908eb7..d164239 100644
--- a/drivers/media/pci/cx18/cx18-i2c.c
+++ b/drivers/media/pci/cx18/cx18-i2c.c
@@ -111,14 +111,18 @@ static int cx18_i2c_new_ir(struct cx18 *cx, struct 
i2c_adapter *adap, u32 hw,
 int cx18_i2c_register(struct cx18 *cx, unsigned idx)
 {
struct v4l2_subdev *sd;
-   int bus = hw_bus[idx];
-   struct i2c_adapter *adap = cx-i2c_adap[bus];
-   const char *type = hw_devicenames[idx];
+   int bus;
+   struct i2c_adapter *adap;
+   const char *type;
u32 hw = 1  idx;
 
if (idx = ARRAY_SIZE(hw_addrs))
return -1;
 
+   bus = hw_bus[idx];
+   adap = cx-i2c_adap[bus];
+   type = hw_devicenames[idx];
+
if (hw == CX18_HW_TUNER) {
/* special tuner group handling */
sd = v4l2_i2c_new_subdev(cx-v4l2_dev,
diff --git a/drivers/media/pci/ivtv/ivtv-i2c.c 
b/drivers/media/pci/ivtv/ivtv-i2c.c
index 46e262b..c6af94c 100644
--- a/drivers/media/pci/ivtv/ivtv-i2c.c
+++ b/drivers/media/pci/ivtv/ivtv-i2c.c
@@ -264,11 +264,14 @@ int ivtv_i2c_register(struct ivtv *itv, unsigned idx)
 {
struct v4l2_subdev *sd;
struct i2c_adapter *adap = itv-i2c_adap;
-   const char *type = hw_devicenames[idx];
+   const char *type;
u32 hw = 1  idx;
 
if (idx = ARRAY_SIZE(hw_addrs))
return -1;
+
+   type = hw_devicenames[idx];
+
if (hw == IVTV_HW_TUNER) {
/* special tuner handling */
sd = v4l2_i2c_new_subdev(itv-v4l2_dev, adap, type, 0,
-- 
1.7.10.4



-- 

Cheers,
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: [linux-media] Re: [PATCH RFCv3] dvb: Add DVBv5 properties for quality parameters

2013-01-06 Thread Antti Palosaari 

On 01/06/2013 07:03 PM, Mauro Carvalho Chehab wrote:

Em Thu, 03 Jan 2013 23:33:49 +0200
Antti Palosaari cr...@iki.fi escreveu:


On 01/03/2013 06:29 PM, Mauro Carvalho Chehab wrote:

Em Thu, 3 Jan 2013 14:14:29 -0200
Mauro Carvalho Chehab mche...@redhat.com escreveu:


Em Thu, 03 Jan 2013 16:18:26 +0100
Klaus Schmidinger klaus.schmidin...@tvdr.de escreveu:


On 03.01.2013 14:20, Mauro Carvalho Chehab wrote:

Em Wed, 2 Jan 2013 00:38:50 +0530
Manu Abraham abraham.m...@gmail.com escreveu:


On Tue, Jan 1, 2013 at 10:59 PM, Mauro Carvalho Chehab
mche...@redhat.com wrote:

Em Tue, 1 Jan 2013 22:18:49 +0530
Manu Abraham abraham.m...@gmail.com escreveu:


On Tue, Jan 1, 2013 at 8:30 PM, Mauro Carvalho Chehab
mche...@redhat.com wrote:


[RFCv4] dvb: Add DVBv5 properties for quality parameters

The DVBv3 quality parameters are limited on several ways:
   - Doesn't provide any way to indicate the used measure;
   - Userspace need to guess how to calculate the measure;
   - Only a limited set of stats are supported;
   - Doesn't provide QoS measure for the OFDM TPS/TMCC
 carriers, used to detect the network parameters for
 DVB-T/ISDB-T;
   - Can't be called in a way to require them to be filled
 all at once (atomic reads from the hardware), with may
 cause troubles on interpreting them on userspace;
   - On some OFDM delivery systems, the carriers can be
 independently modulated, having different properties.
 Currently, there's no way to report per-layer stats;


per layer stats is a mythical bird, nothing of that sort does exist.


Had you ever read or tried to get stats from an ISDB-T demod? If you
had, you would see that it only provides per-layer stats. Btw, this is
a requirement to follow the ARIB and ABNT ISDB specs.


I understand you keep writing junk for ages, but nevertheless:

Do you have any idea what's a BBHEADER (DVB-S2) or
PLHEADER (DVB-T2) ? The headers do indicate what MODCOD
(aka Modulation/Coding Standard follows, whatever mode ACM,
VCM or CCM) follows. These MODCOD foolows a TDM approach
with a hierarchial modulation principle. This is exactly what ISDB
does too.


No, I didn't check DVB-S2/T2 specs deeply enough to understand
if they're doing the same thing as ISDB.

Yet, ISDB-T doesn't use a TDM approach for hierarchical modulation.
It uses a FDM (OFDM is a type of Frequency Division Multiplexing).

So, if you're saying that DVB-S2 uses TDM, it is very different than
ISDB-T. As DVB-T2 uses an FDM type of modulation (OFDM), it would
be possible to segment the carriers there, just like ISDB, or to
use TDM hierarchical modulation techniques.



And for your info:

 The TMCC control information is
common to all TMCC carriers and
error correction is performed by using
difference-set cyclic code.


Yes, TMCC carriers are equal and they are always modulated using DBPSK.
That is done to make it possible to receive the TMCC carriers even under
worse SNR conditions, where it may not be possible to decode the segment
groups.

It seems that you completely missed the point though. On ISDB-T, the
carriers that belong to each group of segments (except for the control
carriers - carriers 1 to 107) uses a completely independent modulation.
Also, as they're spaced in frequency, the interference of each segment
is different. So, error indications are different on each segment.

Btw, in any case, the datasheets of ISDB-T demods clearly shows that
the BER measures are per segment group (layer).

For example, for the BER measures before Viterbi, those are the register
names for a certain demod:

VBERSNUMA Bit count of BER measurement before Viterbi in A layer
VBERSNUMB Bit count of BER measurement before Viterbi in B layer
VBERSNUMC Bit count of BER measurement before Viterbi in C layer

It has another set of registers for BER after Viterbi, and for PER after
Viterbi and RS, for bit count errors, etc.

There's no way to get any type of global BER measure, simply because
ISDB-T demods don't provide.


Maybe we should put all this theoretical discussion aside for the moment and
think about what is *really* needed by real world applications. As with any
receiver, VDR simply wants to have some measure of the signal's strength
and quality. These are just two values that should be delivered by each
frontend/demux, using the *same* defined and mandatory range. I don't care
what exactly that is, but it needs to be the same for all devices.
What values a particular driver uses internally to come up with these
is of no interest to VDR. The signal strength might just be what is
currently returned through FE_READ_SIGNAL_STRENGTH (however, normalized to
the same range in all drivers, which currently is not the case). The signal
quality might use flags like FE_HAS_SIGNAL, FE_HAS_CARRIER, FE_HAS_VITERBI,
FE_HAS_SYNC, as well as SNR, BER and UNC (if available) to form some
value where 0

Re: [RFC v2 0/5] Common Display Framework

2013-01-06 Thread Daniel Vetter 
On Thu, Dec 27, 2012 at 09:57:25AM -0600, Rob Clark wrote:
 On Mon, Dec 24, 2012 at 11:09 AM, Laurent Pinchart
 laurent.pinch...@ideasonboard.com wrote:
  On the topic of discussions, would anyone be interested in a
  BoF/brainstorming/whatever session during the FOSDEM ?
 
 I will be at FOSDEM.. and from http://wiki.x.org/wiki/fosdem2013 it
 looks like at least Daniel will be there.  If enough others are, it
 could be a good idea.

Seconded. Jesse should be there, too, and from the Helsinki guys Ville and
Andy should show up. Doesn't look like Jani will be able to make it. I
think something on Sunday (to not clash with the X devroom) would be good.

Should we apply for an offical BOF/Is there a process for tahat? Adding
Luc in case he knows ...
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
--
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] ts2020: call get_rf_strength from frontend

2013-01-06 Thread Malcolm Priestley 
On Sun, 2013-01-06 at 15:37 +0200, Antti Palosaari wrote:
 On 01/06/2013 02:40 PM, Malcolm Priestley wrote:
  Restore ds3000.c read_signal_strength.
 
  Call tuner get_rf_strength from frontend read_signal_strength.
 
  We are able to do a NULL check and doesn't limit the tuner
  attach to the frontend attach area.
 
  At the moment the lmedm04 tuner attach is stuck in frontend
  attach area.
 
 I would like to nack that, as I see some problems:
 1) it changes deviation against normal procedures
 2) interface driver (usb/pci) should have full control to make decision
 3) you shoot to our own leg easily in power management
 
This patch does not do any operational changes, and is a proper way to
call to another module with a run time NULL check. The same way as
another tuner function from demodulator is called.

 * actually bug 3) already happened some drivers, like rtl28xxu. Tuner is 
 behind demod and demod is put sleep = no access to tuner. FE callback 
 is overridden (just like you are trying to do as default) which means 
 user-space could still make queries = I/O errors.

In such cases, the tuner init/sleep should also be called.


Regards


Malcolm


 Antti
 
 
 
  Signed-off-by: Malcolm Priestley tvbox...@gmail.com
  ---
drivers/media/dvb-frontends/ds3000.c| 10 ++
drivers/media/dvb-frontends/m88rs2000.c |  4 +++-
drivers/media/dvb-frontends/ts2020.c|  1 -
3 files changed, 13 insertions(+), 2 deletions(-)
 
  diff --git a/drivers/media/dvb-frontends/ds3000.c 
  b/drivers/media/dvb-frontends/ds3000.c
  index d128f85..1e344b0 100644
  --- a/drivers/media/dvb-frontends/ds3000.c
  +++ b/drivers/media/dvb-frontends/ds3000.c
  @@ -533,6 +533,15 @@ static int ds3000_read_ber(struct dvb_frontend *fe, 
  u32* ber)
  return 0;
}
 
  +static int ds3000_read_signal_strength(struct dvb_frontend *fe,
  +   u16 *signal_strength)
  +{
  +   if (fe-ops.tuner_ops.get_rf_strength)
  +   fe-ops.tuner_ops.get_rf_strength(fe, signal_strength);
  +
  +   return 0;
  +}
  +
/* calculate DS3000 snr value in dB */
static int ds3000_read_snr(struct dvb_frontend *fe, u16 *snr)
{
  @@ -1102,6 +,7 @@ static struct dvb_frontend_ops ds3000_ops = {
  .i2c_gate_ctrl = ds3000_i2c_gate_ctrl,
  .read_status = ds3000_read_status,
  .read_ber = ds3000_read_ber,
  +   .read_signal_strength = ds3000_read_signal_strength,
  .read_snr = ds3000_read_snr,
  .read_ucblocks = ds3000_read_ucblocks,
  .set_voltage = ds3000_set_voltage,
  diff --git a/drivers/media/dvb-frontends/m88rs2000.c 
  b/drivers/media/dvb-frontends/m88rs2000.c
  index 283c90f..4da5272 100644
  --- a/drivers/media/dvb-frontends/m88rs2000.c
  +++ b/drivers/media/dvb-frontends/m88rs2000.c
  @@ -446,7 +446,9 @@ static int m88rs2000_read_ber(struct dvb_frontend *fe, 
  u32 *ber)
static int m88rs2000_read_signal_strength(struct dvb_frontend *fe,
  u16 *strength)
{
  -   *strength = 0;
  +   if (fe-ops.tuner_ops.get_rf_strength)
  +   fe-ops.tuner_ops.get_rf_strength(fe, strength);
  +
  return 0;
}
 
  diff --git a/drivers/media/dvb-frontends/ts2020.c 
  b/drivers/media/dvb-frontends/ts2020.c
  index f50e237..ad7ad85 100644
  --- a/drivers/media/dvb-frontends/ts2020.c
  +++ b/drivers/media/dvb-frontends/ts2020.c
  @@ -363,7 +363,6 @@ struct dvb_frontend *ts2020_attach(struct dvb_frontend 
  *fe,
 
  memcpy(fe-ops.tuner_ops, ts2020_tuner_ops,
  sizeof(struct dvb_tuner_ops));
  -   fe-ops.read_signal_strength = fe-ops.tuner_ops.get_rf_strength;
 
  return fe;
}
 
 
 


--
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] ts2020: call get_rf_strength from frontend

2013-01-06 Thread Antti Palosaari 

On 01/06/2013 08:14 PM, Malcolm Priestley wrote:

On Sun, 2013-01-06 at 15:37 +0200, Antti Palosaari wrote:

On 01/06/2013 02:40 PM, Malcolm Priestley wrote:

Restore ds3000.c read_signal_strength.

Call tuner get_rf_strength from frontend read_signal_strength.

We are able to do a NULL check and doesn't limit the tuner
attach to the frontend attach area.

At the moment the lmedm04 tuner attach is stuck in frontend
attach area.


I would like to nack that, as I see some problems:
1) it changes deviation against normal procedures
2) interface driver (usb/pci) should have full control to make decision
3) you shoot to our own leg easily in power management


This patch does not do any operational changes, and is a proper way to
call to another module with a run time NULL check. The same way as
another tuner function from demodulator is called.


uh, certainly I understand it does not change functionality in that 
case! I tried to point out it is logically insane and error proof. Ee 
should make this kind of direct calls between drivers as less as 
possible - just to make life easier in future. It could work for you, 
but for some other it could cause problems as hardware is designed 
differently.



* actually bug 3) already happened some drivers, like rtl28xxu. Tuner is
behind demod and demod is put sleep = no access to tuner. FE callback
is overridden (just like you are trying to do as default) which means
user-space could still make queries = I/O errors.


In such cases, the tuner init/sleep should also be called.


???
I think you don't understand functionality at all!

See that bug report, I was referring
http://permalink.gmane.org/gmane.linux.drivers.video-input-infrastructure/48216

It is not long time I added checks to DVB-core to avoid it calling 
statistics IOCTLs if frontend is not active.


But simply, it is situation your demod driver should not make decision 
whether statistics are asked from the tuner or not. It is decision that 
should be left to interface driver. It is single line of code to 
override that logic in interface driver - or add even some other logic 
how to perform measurement and in which condition. Interface driver is 
driver which knows best power-management etc. related stuff.



Antti






Regards


Malcolm



Antti




Signed-off-by: Malcolm Priestley tvbox...@gmail.com
---
   drivers/media/dvb-frontends/ds3000.c| 10 ++
   drivers/media/dvb-frontends/m88rs2000.c |  4 +++-
   drivers/media/dvb-frontends/ts2020.c|  1 -
   3 files changed, 13 insertions(+), 2 deletions(-)

diff --git a/drivers/media/dvb-frontends/ds3000.c 
b/drivers/media/dvb-frontends/ds3000.c
index d128f85..1e344b0 100644
--- a/drivers/media/dvb-frontends/ds3000.c
+++ b/drivers/media/dvb-frontends/ds3000.c
@@ -533,6 +533,15 @@ static int ds3000_read_ber(struct dvb_frontend *fe, u32* 
ber)
return 0;
   }

+static int ds3000_read_signal_strength(struct dvb_frontend *fe,
+   u16 *signal_strength)
+{
+   if (fe-ops.tuner_ops.get_rf_strength)
+   fe-ops.tuner_ops.get_rf_strength(fe, signal_strength);
+
+   return 0;
+}
+
   /* calculate DS3000 snr value in dB */
   static int ds3000_read_snr(struct dvb_frontend *fe, u16 *snr)
   {
@@ -1102,6 +,7 @@ static struct dvb_frontend_ops ds3000_ops = {
.i2c_gate_ctrl = ds3000_i2c_gate_ctrl,
.read_status = ds3000_read_status,
.read_ber = ds3000_read_ber,
+   .read_signal_strength = ds3000_read_signal_strength,
.read_snr = ds3000_read_snr,
.read_ucblocks = ds3000_read_ucblocks,
.set_voltage = ds3000_set_voltage,
diff --git a/drivers/media/dvb-frontends/m88rs2000.c 
b/drivers/media/dvb-frontends/m88rs2000.c
index 283c90f..4da5272 100644
--- a/drivers/media/dvb-frontends/m88rs2000.c
+++ b/drivers/media/dvb-frontends/m88rs2000.c
@@ -446,7 +446,9 @@ static int m88rs2000_read_ber(struct dvb_frontend *fe, u32 
*ber)
   static int m88rs2000_read_signal_strength(struct dvb_frontend *fe,
u16 *strength)
   {
-   *strength = 0;
+   if (fe-ops.tuner_ops.get_rf_strength)
+   fe-ops.tuner_ops.get_rf_strength(fe, strength);
+
return 0;
   }

diff --git a/drivers/media/dvb-frontends/ts2020.c 
b/drivers/media/dvb-frontends/ts2020.c
index f50e237..ad7ad85 100644
--- a/drivers/media/dvb-frontends/ts2020.c
+++ b/drivers/media/dvb-frontends/ts2020.c
@@ -363,7 +363,6 @@ struct dvb_frontend *ts2020_attach(struct dvb_frontend *fe,

memcpy(fe-ops.tuner_ops, ts2020_tuner_ops,
sizeof(struct dvb_tuner_ops));
-   fe-ops.read_signal_strength = fe-ops.tuner_ops.get_rf_strength;

return fe;
   }










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

cron job: media_tree daily build: ERRORS

2013-01-06 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:Sun Jan  6 19:00:16 CET 2013
git hash:73ec66c000e9816806c7380ca3420f4e0638c40e
gcc version:  i686-linux-gcc (GCC) 4.7.1
host hardware:x86_64
host os:  3.4.07-marune

linux-git-arm-eabi-davinci: ERRORS
linux-git-arm-eabi-exynos: ERRORS
linux-git-arm-eabi-omap: ERRORS
linux-git-i686: OK
linux-git-m32r: OK
linux-git-mips: ERRORS
linux-git-powerpc64: OK
linux-git-sh: ERRORS
linux-git-x86_64: OK
linux-2.6.31.12-i686: ERRORS
linux-2.6.32.6-i686: ERRORS
linux-2.6.33-i686: ERRORS
linux-2.6.34-i686: ERRORS
linux-2.6.35.3-i686: ERRORS
linux-2.6.36-i686: ERRORS
linux-2.6.37-i686: ERRORS
linux-2.6.38.2-i686: ERRORS
linux-2.6.39.1-i686: ERRORS
linux-3.0-i686: ERRORS
linux-3.1-i686: WARNINGS
linux-3.2.1-i686: WARNINGS
linux-3.3-i686: WARNINGS
linux-3.4-i686: WARNINGS
linux-3.5-i686: WARNINGS
linux-3.6-i686: WARNINGS
linux-3.7-i686: WARNINGS
linux-3.8-rc1-i686: WARNINGS
linux-2.6.31.12-x86_64: ERRORS
linux-2.6.32.6-x86_64: ERRORS
linux-2.6.33-x86_64: ERRORS
linux-2.6.34-x86_64: ERRORS
linux-2.6.35.3-x86_64: ERRORS
linux-2.6.36-x86_64: ERRORS
linux-2.6.37-x86_64: ERRORS
linux-2.6.38.2-x86_64: ERRORS
linux-2.6.39.1-x86_64: ERRORS
linux-3.0-x86_64: ERRORS
linux-3.1-x86_64: WARNINGS
linux-3.2.1-x86_64: WARNINGS
linux-3.3-x86_64: WARNINGS
linux-3.4-x86_64: WARNINGS
linux-3.5-x86_64: WARNINGS
linux-3.6-x86_64: WARNINGS
linux-3.7-x86_64: WARNINGS
linux-3.8-rc1-x86_64: WARNINGS
apps: WARNINGS
spec-git: OK
sparse: ERRORS

Detailed results are available here:

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

Full logs are available here:

http://www.xs4all.nl/~hverkuil/logs/Sunday.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: [PATCH 0/4] Some IR fixes for I2C devices on em28xx

2013-01-06 Thread Frank Schäfer 
Am 05.01.2013 16:06, schrieb Mauro Carvalho Chehab:
 Em Sat, 05 Jan 2013 14:22:08 +0100
 Frank Schäfer fschaefer@googlemail.com escreveu:

 Am 04.01.2013 22:15, schrieb Mauro Carvalho Chehab:
 Frank pointed that IR was not working with I2C devices. So, I took some
 time to fix them.

 Tested with Hauppauge WinTV USB2.

 Mauro Carvalho Chehab (4):
   [media] em28xx: initialize button/I2C IR earlier
   [media] em28xx: autoload em28xx-rc if the device has an I2C IR
   [media] em28xx: simplify IR names on I2C devices
   [media] em28xx: tell ir-kbd-i2c that WinTV uses an RC5 protocol

  drivers/media/usb/em28xx/em28xx-cards.c |  2 +-
  drivers/media/usb/em28xx/em28xx-input.c | 29 -
  2 files changed, 17 insertions(+), 14 deletions(-)

 While these patches make I2C IR remote controls working again, they
 leave several issues unaddressed which should really be fixed:
 1) the i2c client isn't unregistered on module unload. This was the
 reason for patch 2 in my series. There is also a FIXME comment about
 this in em28xx_release_resources() (although this is the wrong place to
 do it).
 AFAIKT, this is not really needed, as the I2C clients are unregistered
 when the I2C bus is unregistered.

 So, a device disconnect will release it. Also, an em28xx driver unload.

 The only difference might be if just ir-kbd-i2c and em28xx-rc are
 unloaded, but em28xx is still loaded, but I think that, even on this
 case, calling the .release code for an I2C bus will release it.

 So, I don't see any need for such patch. I might be wrong, of course, but,
 in order to proof that a release code is needed, you'll need to check if
 some memory are lost after module load/unload.

Mauro, just because code luckily 'works' in the current constellation,
it isn't necessarily good code.
It's this kind of issues that can easily cause regressions if the code
changes somewhere else.

em28xx-input registers the i2c device, so it should unregister it on
uninit/close/unload, too.
Pretty simple and easy to fix (+5 - 2 = 3 additional lines of code).

 2) there is no error checking in em28xx_register_i2c_ir().
 em28xx_ir_init should really bail out if no i2c device is found.
 A failure to initialize IR should not be fatal for the driver, as the
 rest of the hardware still works.

I'm talking about em28xx-input and the RC part only. Of course not the
whole driver.
Do you really want to load module ir-kbd-i2c even though there is no
device ?


 Also, there's no way to warrant that the I2C code is actually running,
 as ir-i2c-kbd may not even be compiled.

 So, returning 0 there doesn't mean that IR is working.

You can check the success of request_module.

The whole thing is really easy to fix, I fail to see why you don't want
to do it.

 3) All RC maps should be assigned at the same place, no matter if the
 receiver/demodulator is built in or external. Spreading them over the
 code is inconsistent and makes the code bug prone.
 I don't agree. It is better to keep RC maps for those devices together
 with the RC protocol setting, get_key config, etc. At boards config,
 it is very easy to identify I2C IR's, as there's an special field there
 to mark those devices (has_ir_i2c). So, if the board has_ir_i2c, the
 IR config is inside em28xx-input. 

... which is exactly what made it so easy to cause this regression !!!

It's not obvious for programmers that no RC map has to be specified for
i2c RCs in the board data.
It's also not obvious that em28xx-input silently overwrites the rc-map
assigned at board level.
In general, it's not obvious that two completely different code areas
have to be touched for these devices.
That's why we really should avoid those board specific code parts spread
all over the driver as much as possible.
In case of the RC map it's really easy.

I also fail to see what you would loose in em28xx-input. We would still
assign the RC map to dev-init_data.
If you prefer seeing the used RC map in the em28xx-input code directly,
then the same should apply for devices with built-in IR
recceiver/decoder (which means moving all rc-map assignments to
em28xx-input).
You could also get rid of field ir_codes this way.

 That's the same logic that it is
 there for has_dvb: if this field is true, the DVB specifics is inside
 em28xx-dvb.

Different case.
Avoiding board specific code parts there likely isn't possible (and
reasonable), although it should be the goal.

 4) the list of known i2c devices in em28xx-i2c.c misses client address
 0x3e  1 = 0x1f. See client list in em28xx_register_i2c_ir().
 Ok. Separate patch, please.

Coming soon.

 5) there should be a warning message for the case that we call
 ir-kbd-i2c with an unknown rc device.
 Why? All boards with has_ir_i2c have entries there. I double-checked.
 Adding will just bloat the code with no reason. We just need to take
 care if we get a patch adding I2C IR support for an old card, to be
 sure that data is filled on both places.

 Considering that we don't

Re: [PATCH 0/4] Some IR fixes for I2C devices on em28xx

2013-01-06 Thread Frank Schäfer 
Am 05.01.2013 16:35, schrieb Mauro Carvalho Chehab:
 Em Sat, 05 Jan 2013 14:42:10 +0100
 Frank Schäfer fschaefer@googlemail.com escreveu:

 Am 05.01.2013 14:22, schrieb Frank Schäfer:
 Am 04.01.2013 22:15, schrieb Mauro Carvalho Chehab:
 Frank pointed that IR was not working with I2C devices. So, I took some
 time to fix them.

 Tested with Hauppauge WinTV USB2.

 Mauro Carvalho Chehab (4):
   [media] em28xx: initialize button/I2C IR earlier
   [media] em28xx: autoload em28xx-rc if the device has an I2C IR
   [media] em28xx: simplify IR names on I2C devices
   [media] em28xx: tell ir-kbd-i2c that WinTV uses an RC5 protocol

  drivers/media/usb/em28xx/em28xx-cards.c |  2 +-
  drivers/media/usb/em28xx/em28xx-input.c | 29 -
  2 files changed, 17 insertions(+), 14 deletions(-)

 While these patches make I2C IR remote controls working again, they
 leave several issues unaddressed which should really be fixed:
 1) the i2c client isn't unregistered on module unload. This was the
 reason for patch 2 in my series. There is also a FIXME comment about
 this in em28xx_release_resources() (although this is the wrong place to
 do it).
 2) there is no error checking in em28xx_register_i2c_ir().
 em28xx_ir_init should really bail out if no i2c device is found.
 3) All RC maps should be assigned at the same place, no matter if the
 receiver/demodulator is built in or external. Spreading them over the
 code is inconsistent and makes the code bug prone.
 4) the list of known i2c devices in em28xx-i2c.c misses client address
 0x3e  1 = 0x1f. See client list in em28xx_register_i2c_ir().
 5) there should be a warning message for the case that we call
 ir-kbd-i2c with an unknown rc device.
 6) because we use our own key polling functions with ir-kbd-i2c, we
 should also select the polling interval value manually. That makes
 things consistent and avoids confusion.

 The rest is a matter of taste / prefered code layout. I'm fine with it.

 Regards,
 Frank
 It seems like already applied them... :(

 While I certainly appreciate patches beeing applied as soon as possible,
 I think there should really be a chance to review them before this happens.
 Especially when the changes are non-trivial and someone else has posted
 patches addressing the same issues before (other contributers might feel
 offended ;) ).
 All the 4 applied patches are really trivial:
   - patch 1: just reorder existing code;
   - patch 2: one-line patch adding another condition to an existing if;
   - patch 3: pure string rename;
   - patch 4: one line patch properly reporting the RC5 protocol on WinTV.

Just because a patch just reorders existing code or just changes a
single line it's not automatically trivial.
I'm sure you have seen more cases than me in which it were patches like
this who caused big trouble. ;)

And especially in cases where the changes are under discussion (which I
would say is the case when someone else has posted patches addressing
the same issues before) there should be a minimum chance to react on them.
Isn't that what you would expect from others, too ? ;)

Apart from that, there are also lots of other 'trivial' patches rotting
at patchwork or bugzilla...

 Also, my time is very limited, especially when I need to test a driver, as
 I need to allocate a bigger time window. On such cases, I just reorder the
 patches to to apply all of them at the same time, to optimize my time.

Yeah, I understand your time problems and I really appreciate patches
beeing applied as soon as possible (after they have been reviewed).
But delaying a patch for a few days really shouldn't cause too much
extra work.

 Also, both Devin and you are working right now at the same driver, and you
 both have pending work. Merging the patches quicker helps to avoid merge
 conflicts.

100% agreement, although I don't think these patches are causing any
problems here.

Regards,
Frank

 Regards,
 Mauro

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

Re: [PATCH 6/6] ir-kbd-i2c: fix get_key_knc1()

2013-01-06 Thread Frank Schäfer 
Am 05.01.2013 16:25, schrieb Mauro Carvalho Chehab:
 Em Sat, 05 Jan 2013 14:32:30 +0100
 Frank Schäfer fschaefer@googlemail.com escreveu:

 Am 05.01.2013 03:39, schrieb Mauro Carvalho Chehab:
 Em Fri, 28 Dec 2012 00:02:48 +0100
 Frank Schäfer fschaefer@googlemail.com escreveu:

 - return valid key code when button is hold
 - debug: print key code only when a button is pressed

 Tested with device Terratec Cinergy 200 USB (em28xx).

 Signed-off-by: Frank Schäfer fschaefer@googlemail.com
 ---
  drivers/media/i2c/ir-kbd-i2c.c |   15 +--
  1 Datei geändert, 5 Zeilen hinzugefügt(+), 10 Zeilen entfernt(-)

 diff --git a/drivers/media/i2c/ir-kbd-i2c.c 
 b/drivers/media/i2c/ir-kbd-i2c.c
 index 08ae067..2984b7d 100644
 --- a/drivers/media/i2c/ir-kbd-i2c.c
 +++ b/drivers/media/i2c/ir-kbd-i2c.c
 @@ -184,18 +184,13 @@ static int get_key_knc1(struct IR_i2c *ir, u32 
 *ir_key, u32 *ir_raw)
return -EIO;
}
  
 -  /* it seems that 0xFE indicates that a button is still hold
 - down, while 0xff indicates that no button is hold
 - down. 0xfe sequences are sometimes interrupted by 0xFF */
 -
 -  dprintk(2,key %02x\n, b);
 -
 -  if (b == 0xff)
 +  if (b == 0xff) /* no button */
return 0;
  
 -  if (b == 0xfe)
 -  /* keep old data */
 -  return 1;
 +  if (b == 0xfe) /* button is still hold */
 +  b = ir-rc-last_scancode; /* keep old data */
 +
 +  dprintk(2,key %02x\n, b);
  
*ir_key = b;
*ir_raw = b;
 Don't do that. This piece of code is old, and it was added there 
 before the em28xx driver. Originally, the ir-i2c-kbd were used by
 bttv and saa7134 drivers and the code there were auto-detecting the
 I2C IR hardware decoding chips that used to be very common on media
 devices. I'm almost sure that the original device that started using
 this code is this model:

 drivers/media/pci/bt8xx/bttv-cards.c: .name   = 
 Typhoon TView RDS + FM Stereo / KNC1 TV Station RDS,

 That's why it is called as KNC1, but there are other cards that use
 it as well. I think I have one bttv using it. Not sure.

 The routine on em28xx is a fork of the original one, that was changed
 to work with the devices there.
 Indeed, it's a fork, 100% identical:


 static int em28xx_get_key_terratec(struct IR_i2c *ir, u32 *ir_key, u32
 *ir_raw)
 {
 unsigned char b;

 /* poll IR chip */
 if (1 != i2c_master_recv(ir-c, b, 1)) {
 i2cdprintk(read error\n);
 return -EIO;
 }

 /* it seems that 0xFE indicates that a button is still hold
down, while 0xff indicates that no button is hold
down. 0xfe sequences are sometimes interrupted by 0xFF */

 i2cdprintk(key %02x\n, b);

 if (b == 0xff)
 return 0;

 if (b == 0xfe)
 /* keep old data */
 return 1;

 *ir_key = b;
 *ir_raw = b;
 return 1;
 }




 static int get_key_knc1(struct IR_i2c *ir, u32 *ir_key, u32 *ir_raw)
 {
 unsigned char b;

 /* poll IR chip */
 if (1 != i2c_master_recv(ir-c, b, 1)) {
 dprintk(1,read error\n);
 return -EIO;
 }

 /* it seems that 0xFE indicates that a button is still hold
down, while 0xff indicates that no button is hold
down. 0xfe sequences are sometimes interrupted by 0xFF */

 dprintk(2,key %02x\n, b);

 if (b == 0xff)
 return 0;

 if (b == 0xfe)
 /* keep old data */
 return 1;

 *ir_key = b;
 *ir_raw = b;
 return 1;
 }



 Why should we keep two 100% identical functions ? See patch 4/6.
 I'm 99% sure that both devices are absolutely identical.
 99% sure is not enough. A simple firmware difference at the microprocessor
 is enough to make the devices different.

I agree, but that's irrelevant. What counts is that the _code_ ist 100%
identical.

 Also, this was widely discussed several years ago, when we decided to cleanup
 the I2C code. We then invested lot of efforts to move those get_keys away
 from ir-i2c-kbd. The only things left there are the ones we identified that
 were needed by auto-detection mode on old devices that we don't have.

 What was decided is to move everything that we know to the *-input driver,
 keeping there only the legacy stuff.

Uhm... ok.
My assumption was, that the goal is the opposite (move as much common
code as possible to i2c-ir-kbd).
I'm a bit puzzled about this decision...

Okay but then... why do we still use ir-kbd-i2c in em28xx ?
We can easily get rid of it. Everything we need is already on board.

I can send a patch if you want.


 Concerning the fix I'm suggesting here:
 First of all, I have to say that the Terratec RC works even without this
 patch.
 Nevertheless, I think the function should really return valid values for
 ir_key and ir_raw when 0xfe=button hold is received. Especially because
 the function succeeds.
 This also allows us to make u32 ir_key, ir_raw in ir_key_poll() in
 ir-kbd-i2c.c non-static.
 While I agree that we should be

Re: [PATCH] ts2020: call get_rf_strength from frontend

2013-01-06 Thread Malcolm Priestley 
On Sun, 2013-01-06 at 20:45 +0200, Antti Palosaari wrote:
 On 01/06/2013 08:14 PM, Malcolm Priestley wrote:
  On Sun, 2013-01-06 at 15:37 +0200, Antti Palosaari wrote:
  On 01/06/2013 02:40 PM, Malcolm Priestley wrote:
  Restore ds3000.c read_signal_strength.
 
  Call tuner get_rf_strength from frontend read_signal_strength.
 
  We are able to do a NULL check and doesn't limit the tuner
  attach to the frontend attach area.
 
  At the moment the lmedm04 tuner attach is stuck in frontend
  attach area.
 
  I would like to nack that, as I see some problems:
  1) it changes deviation against normal procedures
  2) interface driver (usb/pci) should have full control to make decision
  3) you shoot to our own leg easily in power management
 
  This patch does not do any operational changes, and is a proper way to
  call to another module with a run time NULL check. The same way as
  another tuner function from demodulator is called.
 
 uh, certainly I understand it does not change functionality in that 
 case! I tried to point out it is logically insane and error proof. Ee 
 should make this kind of direct calls between drivers as less as 
 possible - just to make life easier in future. It could work for you, 
 but for some other it could cause problems as hardware is designed 
 differently.
 
  * actually bug 3) already happened some drivers, like rtl28xxu. Tuner is
  behind demod and demod is put sleep = no access to tuner. FE callback
  is overridden (just like you are trying to do as default) which means
  user-space could still make queries = I/O errors.
 
  In such cases, the tuner init/sleep should also be called.
 
 ???
 I think you don't understand functionality at all!
 
Please, I have been working with the I2C bus in the electronics field
for the last 20 years.

If you are really worried about the the tuner being a sleep. You add
fe variable check this in it's own init/sleep and define the function
something like this.

static int fe_foo_read_signal_strength(struct dvb_frontend *fe,
u16 *strength)
{
struct fe_foo_state *state = fe-demodulator_priv;

if (state-fe_inactive) {
... any extra commands to restore tuner power
if (fe-ops.tuner_ops.init)
fe-ops.tuner_ops.init(fe);

}   

if (fe-ops.tuner_ops.get_rf_strength)
fe-ops.tuner_ops.get_rf_strength(fe, strength);

if (state-fe_inactive) {
if (fe-ops.tuner_ops.sleep)
fe-ops.tuner_ops.sleep(fe);
... any extra commands to remove tuner power
}

return 0;
}

However, I think this is unnecessary in the rs2000 and ds3000.

Regards


Malcolm








--
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] ngene: Use newly created function

2013-01-06 Thread Emil Goode 
The function demod_attach_drxd was split into two by commit 36a495a3.
This resulted in a new function tuner_attach_dtt7520x that is not used.
We should register tuner_attach_dtt7520x as a callback in the ngene_info
struct in the same way as done with the other part of the split function.

Sparse warning:

drivers/media/pci/ngene/ngene-cards.c:333:12: warning:
‘tuner_attach_dtt7520x’ defined but not used [-Wunused-function]

Signed-off-by: Emil Goode emilgo...@gmail.com
---
This patch is a guess at what was intended. I'm not familiar with this code
and I don't have the hardware to test it.

 drivers/media/pci/ngene/ngene-cards.c |1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/media/pci/ngene/ngene-cards.c 
b/drivers/media/pci/ngene/ngene-cards.c
index c99f779..60605c8 100644
--- a/drivers/media/pci/ngene/ngene-cards.c
+++ b/drivers/media/pci/ngene/ngene-cards.c
@@ -732,6 +732,7 @@ static struct ngene_info ngene_info_terratec = {
.name   = Terratec Integra/Cinergy2400i Dual DVB-T,
.io_type= {NGENE_IO_TSIN, NGENE_IO_TSIN},
.demod_attach   = {demod_attach_drxd, demod_attach_drxd},
+   .tuner_attach   = {tuner_attach_dtt7520x, tuner_attach_dtt7520x},
.fe_config  = {fe_terratec_dvbt_0, fe_terratec_dvbt_1},
.i2c_access = 1,
 };
-- 
1.7.10.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: [PATCH] [media] ngene: Use newly created function

2013-01-06 Thread Patrice Chotard 
Hi Emil,

You are right, there was a missing piece of code.

During merge, part of the orignal patch was missing. I have signaled it
to Mauro who have fixed it in media_tree.

Regards.

Le 06/01/2013 21:59, Emil Goode a écrit :
 The function demod_attach_drxd was split into two by commit 36a495a3.
 This resulted in a new function tuner_attach_dtt7520x that is not used.
 We should register tuner_attach_dtt7520x as a callback in the ngene_info
 struct in the same way as done with the other part of the split function.
 
 Sparse warning:
 
 drivers/media/pci/ngene/ngene-cards.c:333:12: warning:
 ‘tuner_attach_dtt7520x’ defined but not used [-Wunused-function]
 
 Signed-off-by: Emil Goode emilgo...@gmail.com
 ---
 This patch is a guess at what was intended. I'm not familiar with this code
 and I don't have the hardware to test it.
 
  drivers/media/pci/ngene/ngene-cards.c |1 +
  1 file changed, 1 insertion(+)
 
 diff --git a/drivers/media/pci/ngene/ngene-cards.c 
 b/drivers/media/pci/ngene/ngene-cards.c
 index c99f779..60605c8 100644
 --- a/drivers/media/pci/ngene/ngene-cards.c
 +++ b/drivers/media/pci/ngene/ngene-cards.c
 @@ -732,6 +732,7 @@ static struct ngene_info ngene_info_terratec = {
   .name   = Terratec Integra/Cinergy2400i Dual DVB-T,
   .io_type= {NGENE_IO_TSIN, NGENE_IO_TSIN},
   .demod_attach   = {demod_attach_drxd, demod_attach_drxd},
 + .tuner_attach   = {tuner_attach_dtt7520x, tuner_attach_dtt7520x},
   .fe_config  = {fe_terratec_dvbt_0, fe_terratec_dvbt_1},
   .i2c_access = 1,
  };
 
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH RFC 2/2] V4L: Add V4L2_CID_AUTO_FOCUS_AREA control

2013-01-06 Thread Sakari Ailus 
Hi Sylwester,

My apologies for the delayed answer.

Sylwester Nawrocki wrote:
 On 12/16/2012 04:00 PM, Sakari Ailus wrote:
 diff --git a/Documentation/DocBook/media/v4l/controls.xml
 b/Documentation/DocBook/media/v4l/controls.xml
 index 7fe5be1..9d4af8a 100644
 --- a/Documentation/DocBook/media/v4l/controls.xml
 +++ b/Documentation/DocBook/media/v4l/controls.xml
 @@ -3347,6 +3347,51 @@ use its minimum possible distance for auto
 focus./entry
   /row
   rowentry/entry/row
 +row id=v4l2-auto-focus-area
 +entry spanname=id
 +constantV4L2_CID_AUTO_FOCUS_AREA/constantnbsp;/entry
 +entryenumnbsp;v4l2_auto_focus_area/entry
 +/row
 +rowentry spanname=descrDetermines the area of the frame
 that
 +the camera uses for automatic focus. The corresponding coordinates
 of the
 +focusing spot or rectangle can be specified and queried using the
 selection API.
 +To change the auto focus region of interest applications first
 select required
 +mode of this control and then set the rectangle or spot
 coordinates by means
 +of theVIDIOC-SUBDEV-S-SELECTION; orVIDIOC-S-SELECTION; ioctl. In
 order to
 +trigger again a one shot auto focus with same coordinates
 applications should
 +use theconstantV4L2_CID_AUTO_FOCUS_START/constant  control. Or
 alternatively
 Extra space above.^

 +invoke aVIDIOC-SUBDEV-S-SELECTION; or aVIDIOC-S-SELECTION; ioctl
 again.
 How about requiring explicit V4L2_CID_AUTO_FOCUS_START? If you need to
 specify several AF selection windows, then on which one do you start
 the
 algorithm? A bitmask control explicitly telling which ones are
 active would
 also be needed --- but that's for the future. I think now we just
 need to
 ascertain we don't make that difficult. :-)
 Do you mean only V4L2_CID_AUTO_FOCUS_START should start AF?
 What about continuous auto-focus (CAF)? In case of the sensor I am
 working on, face detection can work in both AF and CAF.

 Continuous AF needs to be an exception to that. It's controlled by
 V4L2_CID_FOCUS_AUTO, which interestingly doesn't even mention
 continuous AF.
 
 I think it does, maybe not exactly in these words, but continuous
 automatic focus
 adjustments doesn't sound like a difference thing to me.

Oh. I must have missed that. It's ok then.

 Should CAF be restarted (ie stopped and started again), to use face
 detection?

 I wonder if V4L2_CID_AUTO_FOCUS_START should be defined to restart CAF
 when
 V4L2_CID_FOCUS_AUTO is enabled. I don't think we currently have a way
 to do
 that; the current definition says that using V4L2_CID_AUTO_FOCUS_START is
 undefined then. What do you think?
 
 Yes, it might be worth to reconsider this. However, I would like to see
 real
 use cases first where V4L2_CID_AUTO_FOCUS_START control is needed in
 continuous
 AF mode.

If the CAF focus window is changed, I think it may make sense to tell
the CAF algorithm this. If the window moves around based on e.g. output
from face detection algorithm it's unlikely there's a need to perform a
full search every time this happens.

 All in all, we have V4L2_AUTO_FOCUS_STATUS_FAILED AF status control
 value and
 I can't see anything preventing it to be applicable to CAF. So it might
 make
 sense to define in the API what needs to be done to bring CAF out of
 this state.

How would CAF fail? Would this mean that a pre-defined amount of time
has been spent on searching focus and none has been found? Shouldn't it
be application's decision to tell how long is too long, rather than
driver's?

 +In the latter case the new pixel coordinates are applied to
 hardware only when
 +the focus area control was set to
 +constantV4L2_AUTO_FOCUS_AREA_RECTANGLE/constant./entry
 +/row
 +row
 +entrytbl spanname=descr cols=2
 +tbody valign=top
 +row
 +   
 entryconstantV4L2_AUTO_FOCUS_AREA_ALL/constantnbsp;/entry
 +entryNormal auto focus, the focusing area extends over the
 +entire frame./entry
 Does this need to be explicitly specified? Shouldn't the user just
 choose
 the largest possible AF window instead? I'd even expect that the AF
 window
 might span the whole frame by default (up to driver, hardware etc.).
 Yes it could be removed. There are two reasons I have left it:
 1. If hardware support only AF on spots, V4L2_AUTO_FOCUS_AREA_ALL
 seems to be more
 natural than focusing on the whole image.

 If the hardware only supports spots, then wouldn't
 V4L2_AUTO_FOCUS_AREA_ALL
 give false information to the user, suggesting the focus area is actually
 the whole image?
 
 I think Andrzej meant to say that there can be hardware that supports:
 
 a. AF where region of interest is whole frame,
 b. AF where region of interest is some rectangle of size that may be not
known exactly, and position (center) of that rectangle only is defined
through AF selections.
 
 So you would be really switching AF algorithms by manipulating AF selection
 rectangle only.

I would keep the two separate: selecting the algorithm and the

Re: [PATCH v3 2/4] videobuf2-dma-streaming: new videobuf2 memory allocator

2013-01-06 Thread Alessandro Rubini 
 The problem is that on the sta2x11 architecture only the first 
 512MB are available through the PCI bus, but the allocator can allocate 
 memory 
 for DMA above this limit. By using GFP_DMA flags the allocation take place 
 under the 16MB so it works.

Still, you are not running the upstream allocator.  IIUC, you added a
gfp_t field in the platform data or somewhere, so the sta2x11 can
request GFP_DMA to be OR'd, while other users remain unaffected.  Will
you please submit the patch to achieve that?

 I cannot do performance test at the moment because I don't have the time, so 
 I 
 cannot personally justify the presence of a new allocator.

I don't expect you'll see serious performance differences on the PC. I
think ARM users will have better benefits, due to the different cache
architecture.  You told me Jon measured meaningful figures on a Marvel
CPU.

 I will propose V4 patches soon.

thanks
/alessandro
--
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] ivtv: ivtv-driver: Replace 'flush_work_sync()'

2013-01-06 Thread Andy Walls 
On Thu, 2012-12-20 at 15:18 -0200, Mauro Carvalho Chehab wrote:
 Em Wed, 21 Nov 2012 15:28:09 -0200
 Mauro Carvalho Chehab mche...@redhat.com escreveu:
 
  Hi Andy,
  
  I'm understanding that you'll be reviewing this patch. So, I'm marking it as
  under_review at patchwork.
 
 -ENOANSWER. Let me apply it, in order to fix the warning.

Ooops.  Sorry about that.

Strictly speaking, I think the patch introduces a race condition that is
extremely unlikely to be encountered, and it likely wouldn't have
terrible consequences anyway.

For the normal end-user, it will never be a problem.

FWIW:
Acked-by: Andy Walls awa...@md.metrocast.net

Regards,
Andy
  
  Thanks,
  Mauro
  
  Forwarded message:
  
  Date: Wed, 24 Oct 2012 10:14:16 -0200
  From: Fabio Estevam feste...@gmail.com
  To: awa...@md.metrocast.net
  Cc: mche...@infradead.org, linux-media@vger.kernel.org, t...@kernel.org, 
  Fabio Estevam fabio.este...@freescale.com
  Subject: [PATCH] [media] ivtv: ivtv-driver: Replace 'flush_work_sync()'
  
  
  From: Fabio Estevam fabio.este...@freescale.com
  
  Since commit 43829731d (workqueue: deprecate flush[_delayed]_work_sync()),
  flush_work() should be used instead of flush_work_sync().
  
  Signed-off-by: Fabio Estevam fabio.este...@freescale.com
  ---
   drivers/media/pci/ivtv/ivtv-driver.c |2 +-
   1 file changed, 1 insertion(+), 1 deletion(-)
  
  diff --git a/drivers/media/pci/ivtv/ivtv-driver.c 
  b/drivers/media/pci/ivtv/ivtv-driver.c
  index 74e9a50..5d0a5df 100644
  --- a/drivers/media/pci/ivtv/ivtv-driver.c
  +++ b/drivers/media/pci/ivtv/ivtv-driver.c
  @@ -304,7 +304,7 @@ static void request_modules(struct ivtv *dev)
   
   static void flush_request_modules(struct ivtv *dev)
   {
  -   flush_work_sync(dev-request_module_wk);
  +   flush_work(dev-request_module_wk);
   }
   #else
   #define request_modules(dev)
 
 


--
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: cx18, ivtv: do not dereference array before index check

2013-01-06 Thread Andy Walls 
On Sat, 2013-01-05 at 14:11 -0500, Nickolai Zeldovich wrote:
 Move dereferencing of hw_devicenames[], hw_bus[] arrays until after
 checking that idx is within range.
 
 Signed-off-by: Nickolai Zeldovich nicko...@csail.mit.edu

Hi Nickolai,

My comments are in line below.

 ---
  drivers/media/pci/cx18/cx18-i2c.c |   10 +++---
  drivers/media/pci/ivtv/ivtv-i2c.c |5 -
  2 files changed, 11 insertions(+), 4 deletions(-)
 
 diff --git a/drivers/media/pci/cx18/cx18-i2c.c 
 b/drivers/media/pci/cx18/cx18-i2c.c
 index 4908eb7..d164239 100644
 --- a/drivers/media/pci/cx18/cx18-i2c.c
 +++ b/drivers/media/pci/cx18/cx18-i2c.c
 @@ -111,14 +111,18 @@ static int cx18_i2c_new_ir(struct cx18 *cx, struct 
 i2c_adapter *adap, u32 hw,
  int cx18_i2c_register(struct cx18 *cx, unsigned idx)
  {
   struct v4l2_subdev *sd;
 - int bus = hw_bus[idx];
 - struct i2c_adapter *adap = cx-i2c_adap[bus];
 - const char *type = hw_devicenames[idx];
 + int bus;
 + struct i2c_adapter *adap;
 + const char *type;
   u32 hw = 1  idx;
  
   if (idx = ARRAY_SIZE(hw_addrs))
   return -1;

 + bus = hw_bus[idx];
 + adap = cx-i2c_adap[bus];
 + type = hw_devicenames[idx];
 +

It would be better to simply remove the if (idx = ARRAY_SIZE(...))
check.  That change would result in fewer lines of code instead of more
lines of code.  It is statically provable that cx18_i2c_register() is
never called with a bad idx value.


   if (hw == CX18_HW_TUNER) {
   /* special tuner group handling */
   sd = v4l2_i2c_new_subdev(cx-v4l2_dev,
 diff --git a/drivers/media/pci/ivtv/ivtv-i2c.c 
 b/drivers/media/pci/ivtv/ivtv-i2c.c
 index 46e262b..c6af94c 100644
 --- a/drivers/media/pci/ivtv/ivtv-i2c.c
 +++ b/drivers/media/pci/ivtv/ivtv-i2c.c
 @@ -264,11 +264,14 @@ int ivtv_i2c_register(struct ivtv *itv, unsigned idx)
  {
   struct v4l2_subdev *sd;
   struct i2c_adapter *adap = itv-i2c_adap;
 - const char *type = hw_devicenames[idx];
 + const char *type;
   u32 hw = 1  idx;
  
   if (idx = ARRAY_SIZE(hw_addrs))
   return -1;
 +
 + type = hw_devicenames[idx];
 +

It would be better to simply remove the if (idx = ARRAY_SIZE(...))
check.  That change would result in fewer lines of code instead of more
lines of code.  It is statically provable that ivtv_i2c_register() is
never called with a bad idx value.

Regards,
Andy

   if (hw == IVTV_HW_TUNER) {
   /* special tuner handling */
   sd = v4l2_i2c_new_subdev(itv-v4l2_dev, adap, type, 0,


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

Re: [PATCH] omap3isp: Don't include plat/cpu.h

2013-01-06 Thread Laurent Pinchart 
Hi Mauro,

On Sunday 06 January 2013 11:10:39 Mauro Carvalho Chehab wrote:
 Em Thu, 3 Jan 2013 14:55:41 -0800 Tony Lindgren escreveu:
  * Laurent Pinchart laurent.pinch...@ideasonboard.com [130103 13:24]:
   The plat/*.h headers are not available to drivers in multiplatform
   kernels. As the header isn't needed, just remove it.
  
  Please consider merging this for the -rc cycle, so I can make
  plat/cpu.h produce an error for omap2+ to prevent new drivers
  including it.
 
 Ok, I'll add it to the list of patches for 3.8.

Thank you.

Could you please also add omap3isp: Don't include deleted OMAP plat/ header 
files to that list ? And Sakari, could you please ack it ?

  Acked-by: Tony Lindgren t...@atomide.com
  
   Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
   ---
   
drivers/media/platform/omap3isp/isp.c |2 --
1 files changed, 0 insertions(+), 2 deletions(-)
   
   diff --git a/drivers/media/platform/omap3isp/isp.c
   b/drivers/media/platform/omap3isp/isp.c index 50cea08..07eea5b 100644
   --- a/drivers/media/platform/omap3isp/isp.c
   +++ b/drivers/media/platform/omap3isp/isp.c
   @@ -71,8 +71,6 @@
   
#include media/v4l2-common.h
#include media/v4l2-device.h
   
   -#include plat/cpu.h
   -
   
#include isp.h
#include ispreg.h
#include ispccdc.h

-- 
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 v2] media: cx18, ivtv: eliminate unnecessary array index checks

2013-01-06 Thread Andy Walls 
Nickolai Zeldovich nicko...@csail.mit.edu wrote:

The idx values passed to cx18_i2c_register() and ivtv_i2c_register()
by cx18_init_subdevs() and ivtv_load_and_init_modules() respectively
are always in-range, based on how the hw_all bitmask is populated.
Previously, the checks were already ineffective because arrays were
being dereferenced using the index before the check.

Signed-off-by: Nickolai Zeldovich nicko...@csail.mit.edu
---
Thanks to Andy Walls for suggesting that instead of moving the checks
before array dereference, a better fix is to remove the checks
altogether,
since they are superfluous.

 drivers/media/pci/cx18/cx18-i2c.c |3 ---
 drivers/media/pci/ivtv/ivtv-i2c.c |2 --
 2 files changed, 5 deletions(-)

diff --git a/drivers/media/pci/cx18/cx18-i2c.c
b/drivers/media/pci/cx18/cx18-i2c.c
index 4908eb7..ccb1d15 100644
--- a/drivers/media/pci/cx18/cx18-i2c.c
+++ b/drivers/media/pci/cx18/cx18-i2c.c
@@ -116,9 +116,6 @@ int cx18_i2c_register(struct cx18 *cx, unsigned
idx)
   const char *type = hw_devicenames[idx];
   u32 hw = 1  idx;
 
-  if (idx = ARRAY_SIZE(hw_addrs))
-  return -1;
-
   if (hw == CX18_HW_TUNER) {
   /* special tuner group handling */
   sd = v4l2_i2c_new_subdev(cx-v4l2_dev,
diff --git a/drivers/media/pci/ivtv/ivtv-i2c.c
b/drivers/media/pci/ivtv/ivtv-i2c.c
index 46e262b..bc984af 100644
--- a/drivers/media/pci/ivtv/ivtv-i2c.c
+++ b/drivers/media/pci/ivtv/ivtv-i2c.c
@@ -267,8 +267,6 @@ int ivtv_i2c_register(struct ivtv *itv, unsigned
idx)
   const char *type = hw_devicenames[idx];
   u32 hw = 1  idx;
 
-  if (idx = ARRAY_SIZE(hw_addrs))
-  return -1;
   if (hw == IVTV_HW_TUNER) {
   /* special tuner handling */
   sd = v4l2_i2c_new_subdev(itv-v4l2_dev, adap, type, 0,
-- 
1.7.10.4

Acked-by: Andy Walls awa...@md.metrocast.net
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2] media: cx18, ivtv: eliminate unnecessary array index checks

2013-01-06 Thread Nickolai Zeldovich 
The idx values passed to cx18_i2c_register() and ivtv_i2c_register()
by cx18_init_subdevs() and ivtv_load_and_init_modules() respectively
are always in-range, based on how the hw_all bitmask is populated.
Previously, the checks were already ineffective because arrays were
being dereferenced using the index before the check.

Signed-off-by: Nickolai Zeldovich nicko...@csail.mit.edu
---
Thanks to Andy Walls for suggesting that instead of moving the checks
before array dereference, a better fix is to remove the checks altogether,
since they are superfluous.

 drivers/media/pci/cx18/cx18-i2c.c |3 ---
 drivers/media/pci/ivtv/ivtv-i2c.c |2 --
 2 files changed, 5 deletions(-)

diff --git a/drivers/media/pci/cx18/cx18-i2c.c 
b/drivers/media/pci/cx18/cx18-i2c.c
index 4908eb7..ccb1d15 100644
--- a/drivers/media/pci/cx18/cx18-i2c.c
+++ b/drivers/media/pci/cx18/cx18-i2c.c
@@ -116,9 +116,6 @@ int cx18_i2c_register(struct cx18 *cx, unsigned idx)
const char *type = hw_devicenames[idx];
u32 hw = 1  idx;
 
-   if (idx = ARRAY_SIZE(hw_addrs))
-   return -1;
-
if (hw == CX18_HW_TUNER) {
/* special tuner group handling */
sd = v4l2_i2c_new_subdev(cx-v4l2_dev,
diff --git a/drivers/media/pci/ivtv/ivtv-i2c.c 
b/drivers/media/pci/ivtv/ivtv-i2c.c
index 46e262b..bc984af 100644
--- a/drivers/media/pci/ivtv/ivtv-i2c.c
+++ b/drivers/media/pci/ivtv/ivtv-i2c.c
@@ -267,8 +267,6 @@ int ivtv_i2c_register(struct ivtv *itv, unsigned idx)
const char *type = hw_devicenames[idx];
u32 hw = 1  idx;
 
-   if (idx = ARRAY_SIZE(hw_addrs))
-   return -1;
if (hw == IVTV_HW_TUNER) {
/* special tuner handling */
sd = v4l2_i2c_new_subdev(itv-v4l2_dev, adap, type, 0,
-- 
1.7.10.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: [PATCH] [media] davinci: vpbe: fix missing unlock on error in vpbe_initialize()

2013-01-06 Thread Prabhakar Lad 
Hi Wei,

Thanks for the patch.

On Mon, Oct 22, 2012 at 11:06 AM, Wei Yongjun weiyj...@gmail.com wrote:
 From: Wei Yongjun yongjun_...@trendmicro.com.cn

 Add the missing unlock on the error handling path in function
 vpbe_initialize().

 Signed-off-by: Wei Yongjun yongjun_...@trendmicro.com.cn

Acked-by: Prabhakar Lad prabhakar@ti.com

 ---
 no test
 ---
  drivers/media/platform/davinci/vpbe.c | 6 --
  1 file changed, 4 insertions(+), 2 deletions(-)

 diff --git a/drivers/media/platform/davinci/vpbe.c 
 b/drivers/media/platform/davinci/vpbe.c
 index 69d7a58..875e63d 100644
 --- a/drivers/media/platform/davinci/vpbe.c
 +++ b/drivers/media/platform/davinci/vpbe.c
 @@ -632,8 +632,10 @@ static int vpbe_initialize(struct device *dev, struct 
 vpbe_device *vpbe_dev)

 err = bus_for_each_dev(platform_bus_type, NULL, vpbe_dev,
platform_device_get);
 -   if (err  0)
 -   return err;
 +   if (err  0) {
 +   ret = err;
 +   goto fail_dev_unregister;
 +   }

 vpbe_dev-venc = venc_sub_dev_init(vpbe_dev-v4l2_dev,
vpbe_dev-cfg-venc.module_name);


 --
 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
--
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: Status of the patches under review at LMML (35 patches)

2013-01-06 Thread Prabhakar Lad 
Hi,

On Sun, Jan 6, 2013 at 7:04 PM, Mauro Carvalho Chehab
mche...@redhat.com wrote:
 This is the summary of the patches that are currently under review at
 Linux Media Mailing List linux-media@vger.kernel.org.
 Each patch is represented by its submission date, the subject (up to 70
 chars) and the patchwork link (if submitted via email).

Snip


 == Prabhakar Lad prabhakar@ti.com ==

 Aug,24 2012: Corrected Oops on omap_vout when no manager is connected 
   http://patchwork.linuxtv.org/patch/14033  Federico Fuga 
 f...@studiofuga.com

Tomi can you take care of this patch ?

 Oct,22 2012: [media] davinci: vpbe: fix missing unlock on error in 
 vpbe_initialize( http://patchwork.linuxtv.org/patch/15106  Wei Yongjun 
 yongjun_...@trendmicro.com.cn
This can be marked as 'Accepted'.

 Oct,24 2012: [media] vpif_display: fix return value check in vpif_reqbufs()   
   http://patchwork.linuxtv.org/patch/15167  Wei Yongjun 
 yongjun_...@trendmicro.com.cn
This patch can be marked as 'Superseded'.

Regards,
--Prabhakar

 == Maxim Levitsky maximlevit...@gmail.com ==

 Oct,15 2012: [1/4,media] ene-ir: Fix cleanup on probe failure 
   http://patchwork.linuxtv.org/patch/15024  Matthijs Kooijman 
 matth...@stdin.nl

 == Guennadi Liakhovetski g.liakhovet...@gmx.de ==

 Oct,30 2012: [v2,2/4] media: mx2_camera: Add image size HW limits.
   http://patchwork.linuxtv.org/patch/15298  Javier Martin 
 javier.mar...@vista-silicon.com
 Nov,13 2012: sh_vou: Move from videobuf to videobuf2  
   http://patchwork.linuxtv.org/patch/15433  Laurent Pinchart 
 laurent.pinchart+rene...@ideasonboard.com
 Nov,16 2012: [05/14,media] atmel-isi: Update error check for unsigned 
 variables http://patchwork.linuxtv.org/patch/15475  Tushar Behera 
 tushar.beh...@linaro.org
 Jan, 3 2013: [1/3] sh_vou: Don't modify const variable in sh_vou_s_crop() 
   http://patchwork.linuxtv.org/patch/16095  Laurent Pinchart 
 laurent.pinchart+rene...@ideasonboard.com
 Jan, 3 2013: [2/3] sh_vou: Use video_drvdata()
   http://patchwork.linuxtv.org/patch/16097  Laurent Pinchart 
 laurent.pinchart+rene...@ideasonboard.com
 Jan, 3 2013: [3/3] sh_vou: Use vou_dev instead of vou_file wherever possible  
   http://patchwork.linuxtv.org/patch/16096  Laurent Pinchart 
 laurent.pinchart+rene...@ideasonboard.com

 == Laurent Pinchart laurent.pinch...@ideasonboard.com ==

 Dec,12 2012: [v2] ad5820: Voice coil motor controller driver  
   http://patchwork.linuxtv.org/patch/15881  Florian Neuhaus 
 florian.neuh...@reberinformatik.ch
 Jan, 4 2013: omap3isp: Add support for interlaced input data  
   http://patchwork.linuxtv.org/patch/16133  William Swanson 
 william.swan...@fuel7.com
 Sep, 4 2012: [5/5] drivers/media/platform/omap3isp/isp.c: fix error return 
 code http://patchwork.linuxtv.org/patch/14169  Peter Senna Tschudin 
 peter.se...@gmail.com

 == Sylwester Nawrocki s.nawro...@samsung.com ==

 Dec,28 2012: [1/3,media] s5p-mfc: use mfc_err instead of printk   
   http://patchwork.linuxtv.org/patch/16012  Sachin Kamat 
 sachin.ka...@linaro.org
 Jan, 6 2013: s5p-tv: mixer: fix handling of VIDIOC_S_FMT  
   http://patchwork.linuxtv.org/patch/16143  Tomasz Stanislawski 
 t.stanisl...@samsung.com

 == Marek Szyprowski m.szyprow...@samsung.com ==

 Nov,12 2012: [media] videobuf2-core: print current state of buffer in 
 vb2_buffer_do http://patchwork.linuxtv.org/patch/15420  Tushar Behera 
 tushar.beh...@linaro.org

 == Sascha Hauer s.ha...@pengutronix.de ==

 Sacha is returing next week. He should be addressing this issue
 by them:
 Nov,14 2012: [media] coda: Fix build due to iram.h rename 
   http://patchwork.linuxtv.org/patch/15447  Fabio Estevam 
 fabio.este...@freescale.com

 == Mauro Carvalho Chehab mche...@redhat.com ==

 Those are my own RFC patches. I should rework the QoS patches next
 week/weekend:

 Dec,28 2012: [RFCv3] dvb: Add DVBv5 properties for quality parameters 
   http://patchwork.linuxtv.org/patch/16026  Mauro Carvalho Chehab 
 mche...@redhat.com
 Dec,28 2012: [RFC, media] dvb: frontend API: Add a flag to indicate that 
 get_fronte http://patchwork.linuxtv.org/patch/16024  Mauro Carvalho Chehab 
 mche...@redhat.com
 Jan, 1 2013: [RFCv3] dvb: Add DVBv5 properties for quality parameters 
   http://patchwork.linuxtv.org/patch/16053  Mauro Carvalho Chehab 
 mche...@redhat.com


 Number of pending patches per reviewer:
   Manu Abraham abraham.m...@gmail.com : 11
   Guennadi Liakhovetski g.liakhovet...@gmx.de : 6
   LinuxTV community : 4
   Laurent Pinchart

RE: [PATCHv16 5/7] fbmon: add of_videomode helpers

2013-01-06 Thread Mohammed, Afzal 
Hi Steffen,

On Tue, Dec 18, 2012 at 22:34:14, Steffen Trumtrar wrote:
 Add helper to get fb_videomode from devicetree.

  drivers/video/fbmon.c |   42 ++
  include/linux/fb.h|4 

This breaks DaVinci (da8xx_omapl_defconfig), following change was
required to get it build if OF_VIDEOMODE or/and FB_MODE_HELPERS
is not defined. There may be better solutions, following was the
one that was used by me to test this series.

---8--

diff --git a/include/linux/fb.h b/include/linux/fb.h
index 58b9860..0ce30d1 100644
--- a/include/linux/fb.h
+++ b/include/linux/fb.h
@@ -716,9 +716,19 @@ extern void fb_destroy_modedb(struct fb_videomode *modedb);
 extern int fb_find_mode_cvt(struct fb_videomode *mode, int margins, int rb);
 extern unsigned char *fb_ddc_read(struct i2c_adapter *adapter);

+#if defined(CONFIG_OF_VIDEOMODE)  defined(CONFIG_FB_MODE_HELPERS)
 extern int of_get_fb_videomode(struct device_node *np,
   struct fb_videomode *fb,
   int index);
+#else
+static inline int of_get_fb_videomode(struct device_node *np,
+ struct fb_videomode *fb,
+ int index)
+{
+   return -EINVAL;
+}
+#endif
+
 extern int fb_videomode_from_videomode(const struct videomode *vm,
   struct fb_videomode *fbmode);

---8--


 +#if IS_ENABLED(CONFIG_OF_VIDEOMODE)

As _OF_VIDEOMODE is a bool type CONFIG, isn't,

#ifdef CONFIG_OF_VIDEOMODE

sufficient ?

Regards
Afzal

RE: [PATCHv16 0/7] of: add display helper

2013-01-06 Thread Mohammed, Afzal 
Hi Steffen,

On Tue, Dec 18, 2012 at 22:34:09, Steffen Trumtrar wrote:

 Finally, right in time before the end of the world on friday, v16 of the
 display helpers.

After another big bang, your series in the previous world was tried ;)

This series has been tested on DA850 EVM, AM335x EVM, EVM-SK along
with the fix mentioned in 5/7, there was a build breakage on default
config on DaVinci boards with this series, fix as well as more
details are mentioned as reply to 5/7.

With those changes or equivalent to achieve the same,

Tested-by: Afzal Mohammed af...@ti.com

Regards
Afzal
N�r��yb�X��ǧv�^�)޺{.n�+{���bj)w*jg����ݢj/���z�ޖ��2�ޙ�)ߡ�a�����G���h��j:+v���w��٥

[PATCH] s5p-g2d: Add support for G2D H/W Rev.4.1

2013-01-06 Thread Sachin Kamat 
Modified the G2D driver (which initially supported only H/W Rev.3)
to support H/W Rev.4.1 present on Exynos4x12 and Exynos52x0 SOCs.

-- Set the SRC and DST type to 'memory' instead of using reset values.
-- FIMG2D v4.1 H/W uses different logic for stretching(scaling).
-- Use CACHECTL_REG only with FIMG2D v3.

Signed-off-by: Ajay Kumar ajaykumar...@samsung.com
Signed-off-by: Sachin Kamat sachin.ka...@linaro.org
Cc: Kamil Debski k.deb...@samsung.com
---
Earlier attempts at adding this support can be found at:
http://patchwork.linuxtv.org/patch/10833/
This version addresses all the previous comments.
---
 drivers/media/platform/s5p-g2d/g2d-hw.c   |   16 ---
 drivers/media/platform/s5p-g2d/g2d-regs.h |8 +
 drivers/media/platform/s5p-g2d/g2d.c  |   43 +++-
 drivers/media/platform/s5p-g2d/g2d.h  |   13 ++---
 4 files changed, 70 insertions(+), 10 deletions(-)

diff --git a/drivers/media/platform/s5p-g2d/g2d-hw.c 
b/drivers/media/platform/s5p-g2d/g2d-hw.c
index 5b86cbe..e87bd93 100644
--- a/drivers/media/platform/s5p-g2d/g2d-hw.c
+++ b/drivers/media/platform/s5p-g2d/g2d-hw.c
@@ -28,6 +28,7 @@ void g2d_set_src_size(struct g2d_dev *d, struct g2d_frame *f)
 {
u32 n;
 
+   w(0, SRC_SELECT_REG);
w(f-stride  0x, SRC_STRIDE_REG);
 
n = f-o_height  0xFFF;
@@ -52,6 +53,7 @@ void g2d_set_dst_size(struct g2d_dev *d, struct g2d_frame *f)
 {
u32 n;
 
+   w(0, DST_SELECT_REG);
w(f-stride  0x, DST_STRIDE_REG);
 
n = f-o_height  0xFFF;
@@ -82,10 +84,14 @@ void g2d_set_flip(struct g2d_dev *d, u32 r)
w(r, SRC_MSK_DIRECT_REG);
 }
 
-u32 g2d_cmd_stretch(u32 e)
+void g2d_set_v41_stretch(struct g2d_dev *d, struct g2d_frame *src,
+   struct g2d_frame *dst)
 {
-   e = 1;
-   return e  4;
+   w(DEFAULT_SCALE_MODE, SRC_SCALE_CTRL_REG);
+
+   /* inversed scaling factor: src is numerator */
+   w((src-c_width  16) / dst-c_width, SRC_XSCALE_REG);
+   w((src-c_height  16) / dst-c_height, SRC_YSCALE_REG);
 }
 
 void g2d_set_cmd(struct g2d_dev *d, u32 c)
@@ -96,7 +102,9 @@ void g2d_set_cmd(struct g2d_dev *d, u32 c)
 void g2d_start(struct g2d_dev *d)
 {
/* Clear cache */
-   w(0x7, CACHECTL_REG);
+   if (d-variant-hw_rev == TYPE_G2D_3X)
+   w(0x7, CACHECTL_REG);
+
/* Enable interrupt */
w(1, INTEN_REG);
/* Start G2D engine */
diff --git a/drivers/media/platform/s5p-g2d/g2d-regs.h 
b/drivers/media/platform/s5p-g2d/g2d-regs.h
index 02e1cf5..950c742 100644
--- a/drivers/media/platform/s5p-g2d/g2d-regs.h
+++ b/drivers/media/platform/s5p-g2d/g2d-regs.h
@@ -35,6 +35,9 @@
 #define SRC_COLOR_MODE_REG 0x030C  /* Src Image Color Mode reg */
 #define SRC_LEFT_TOP_REG   0x0310  /* Src Left Top Coordinate reg */
 #define SRC_RIGHT_BOTTOM_REG   0x0314  /* Src Right Bottom Coordinate reg */
+#define SRC_SCALE_CTRL_REG 0x0328  /* Src Scaling type select */
+#define SRC_XSCALE_REG 0x032c  /* Src X Scaling ratio */
+#define SRC_YSCALE_REG 0x0330  /* Src Y Scaling ratio */
 
 /* Parameter Setting Registers (Dest) */
 #define DST_SELECT_REG 0x0400  /* Dest Image Selection reg */
@@ -113,3 +116,8 @@
 #define DEFAULT_WIDTH  100
 #define DEFAULT_HEIGHT 100
 
+#define DEFAULT_SCALE_MODE (2  0)
+
+/* Command mode register values */
+#define CMD_V3_ENABLE_STRETCH  (1  4)
+
diff --git a/drivers/media/platform/s5p-g2d/g2d.c 
b/drivers/media/platform/s5p-g2d/g2d.c
index 1bfbc32..6c9a589 100644
--- a/drivers/media/platform/s5p-g2d/g2d.c
+++ b/drivers/media/platform/s5p-g2d/g2d.c
@@ -604,8 +604,13 @@ static void device_run(void *prv)
g2d_set_flip(dev, ctx-flip);
 
if (ctx-in.c_width != ctx-out.c_width ||
-   ctx-in.c_height != ctx-out.c_height)
-   cmd |= g2d_cmd_stretch(1);
+   ctx-in.c_height != ctx-out.c_height) {
+   if (dev-variant-hw_rev == TYPE_G2D_3X)
+   cmd |= CMD_V3_ENABLE_STRETCH;
+   else
+   g2d_set_v41_stretch(dev, ctx-in, ctx-out);
+   }
+
g2d_set_cmd(dev, cmd);
g2d_start(dev);
 
@@ -690,6 +695,8 @@ static struct v4l2_m2m_ops g2d_m2m_ops = {
.unlock = g2d_unlock,
 };
 
+static void *g2d_get_drv_data(struct platform_device *pdev);
+
 static int g2d_probe(struct platform_device *pdev)
 {
struct g2d_dev *dev;
@@ -791,6 +798,7 @@ static int g2d_probe(struct platform_device *pdev)
}
 
def_frame.stride = (def_frame.width * def_frame.fmt-depth)  3;
+   dev-variant = g2d_get_drv_data(pdev);
 
return 0;
 
@@ -830,9 +838,40 @@ static int g2d_remove(struct platform_device *pdev)
return 0;
 }
 
+static void *g2d_get_drv_data(struct platform_device *pdev)
+{
+   struct g2d_variant *driver_data = NULL;
+
+   driver_data = (struct g2d_variant *)
+

Re: [PATCHv16 0/7] of: add display helper

2013-01-06 Thread Steffen Trumtrar 
On Mon, Jan 07, 2013 at 06:23:54AM +, Mohammed, Afzal wrote:
 Hi Steffen,
 
 On Tue, Dec 18, 2012 at 22:34:09, Steffen Trumtrar wrote:
 
  Finally, right in time before the end of the world on friday, v16 of the
  display helpers.
 
 After another big bang, your series in the previous world was tried ;)
 
 This series has been tested on DA850 EVM, AM335x EVM, EVM-SK along
 with the fix mentioned in 5/7, there was a build breakage on default
 config on DaVinci boards with this series, fix as well as more
 details are mentioned as reply to 5/7.
 
 With those changes or equivalent to achieve the same,
 
 Tested-by: Afzal Mohammed af...@ti.com


Thanks.

Steffen

-- 
Pengutronix e.K.   | |
Industrial Linux Solutions | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686   | Fax:   +49-5121-206917- |
--
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