Re: [PATCH RFC] [media] dib0700: remove redundant else

2016-10-10 Thread Patrick Boettcher
On Mon, 10 Oct 2016 06:30:35 -0300
Mauro Carvalho Chehab  wrote:
> >  drivers/media/usb/dvb-usb/dib0700_devices.c | 10 +++---
> >  1 file changed, 3 insertions(+), 7 deletions(-)
> > 
> > diff --git a/drivers/media/usb/dvb-usb/dib0700_devices.c
> > b/drivers/media/usb/dvb-usb/dib0700_devices.c index
> > 0857b56..3cd8566 100644 ---
> > a/drivers/media/usb/dvb-usb/dib0700_devices.c +++
> > b/drivers/media/usb/dvb-usb/dib0700_devices.c @@ -1736,13 +1736,9
> > @@ static int dib809x_tuner_attach(struct dvb_usb_adapter *adap)
> > struct dib0700_adapter_state *st = adap->priv; struct i2c_adapter
> > *tun_i2c = st->dib8000_ops.get_i2c_master(adap->fe_adap[0].fe,
> > DIBX000_I2C_INTERFACE_TUNER, 1); 
> > -   if (adap->id == 0) {
> > -   if (dvb_attach(dib0090_register,
> > adap->fe_adap[0].fe, tun_i2c, _dib0090_config) == NULL)
> > -   return -ENODEV;
> > -   } else {
> > -   if (dvb_attach(dib0090_register,
> > adap->fe_adap[0].fe, tun_i2c, _dib0090_config) == NULL)
> > -   return -ENODEV;
> > -   }
> > +   if (dvb_attach(dib0090_register, adap->fe_adap[0].fe,
> > +  tun_i2c, _dib0090_config) == NULL)
> > +   return -ENODEV;  
> 
> 
> I suspect that this patch is wrong. It should be, instead, using
> fe_adap[1] on the else.
> 
> Patrick,
> 
> Could you please take a look?

I think you're right, it should be fe_adap[1], but I have lost track of
these devices and don't know the correct answer.

However, this code was introduced by 

commit 91be260faaf8561dc51e72033c346f6ab28d40d8
Author: Nicolas Sugino 
Date:   Thu Nov 26 19:00:28 2015 -0200

[media] dib8000: Add support for Mygica/Geniatech S2870

MyGica/Geniatech S2870 is very similar to the S870 but with dual tuner. The 
card is recognised as Geniatech STK8096-PVR.

[mche...@osg.samsung.com: Fix some checkpatch.pl issues]
Signed-off-by: Nicolas Sugino 

Signed-off-by: Mauro Carvalho Chehab 

diff --git a/drivers/media/usb/dvb-usb/dib0700_devices.c 
b/drivers/media/usb/dvb-usb/dib0700_devices.c
index 7ed4964..ea0391e 100644
--- a/drivers/media/usb/dvb-usb/dib0700_devices.c
+++ b/drivers/media/usb/dvb-usb/dib0700_devices.c
@@ -1736,8 +1736,13 @@ static int dib809x_tuner_attach(struct dvb_usb_adapter 
*adap)
struct dib0700_adapter_state *st = adap->priv;
struct i2c_adapter *tun_i2c = 
st->dib8000_ops.get_i2c_master(adap->fe_adap[0].fe, 
DIBX000_I2C_INTERFACE_TUNER, 1);
 
-   if (dvb_attach(dib0090_register, adap->fe_adap[0].fe, tun_i2c, 
_dib0090_config) == NULL)
-   return -ENODEV;
+   if (adap->id == 0) {
+   if (dvb_attach(dib0090_register, adap->fe_adap[0].fe, tun_i2c, 
_dib0090_config) == NULL)
+   return -ENODEV;
+   } else {
+   if (dvb_attach(dib0090_register, adap->fe_adap[0].fe, tun_i2c, 
_dib0090_config) == NULL)
+   return -ENODEV;
+   }
 
st->set_param_save = adap->fe_adap[0].fe->ops.tuner_ops.set_params;
adap->fe_adap[0].fe->ops.tuner_ops.set_params = 
dib8096_set_param_override;

[..]

Maybe Nicolas can help (and test).

--
Patrick.
--
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 09/26] dibusb: don't do DMA on stack

2016-10-10 Thread Patrick Boettcher
>   sndbuf[1] = (addr << 1) | (wo ? 0 : 1);
>  
> - memcpy([2],wbuf,wlen);
> + memcpy([2], wbuf, wlen);
>  
>   if (!wo) {
> - sndbuf[wlen+2] = (rlen >> 8) & 0xff;
> - sndbuf[wlen+3] = rlen & 0xff;
> + sndbuf[wlen + 2] = (rlen >> 8) & 0xff;
> + sndbuf[wlen + 3] = rlen & 0xff;
>   }
>  
> - return dvb_usb_generic_rw(d,sndbuf,len,rbuf,rlen,0);
> + ret = dvb_usb_generic_rw(d, sndbuf, len, rbuf, rlen, 0);
> +
> +ret:
> + kfree(sndbuf);
> + return ret;
>  }
>  
>  /*
> @@ -320,11 +354,23 @@ EXPORT_SYMBOL(rc_map_dibusb_table);
>  
>  int dibusb_rc_query(struct dvb_usb_device *d, u32 *event, int *state)
>  {
> - u8 key[5],cmd = DIBUSB_REQ_POLL_REMOTE;
> - dvb_usb_generic_rw(d,,1,key,5,0);
> - dvb_usb_nec_rc_key_to_event(d,key,event,state);
> - if (key[0] != 0)
> - deb_info("key: %*ph\n", 5, key);
> + u8 *buf;
> +
> + buf = kmalloc(5, GFP_KERNEL);
> + if (!buf)
> + return -ENOMEM;
> +
> + buf[0] = DIBUSB_REQ_POLL_REMOTE;
> +
> + dvb_usb_generic_rw(d, buf, 1, buf, 5, 0);
> +
> + dvb_usb_nec_rc_key_to_event(d, buf, event, state);
> +
> + if (buf[0] != 0)
> + deb_info("key: %*ph\n", 5, buf);
> +
> + kfree(buf);
> +
>   return 0;
>  }
>  EXPORT_SYMBOL(dibusb_rc_query);
> diff --git a/drivers/media/usb/dvb-usb/dibusb.h
> b/drivers/media/usb/dvb-usb/dibusb.h index 3f82163d8ab8..42e9750393e5
> 100644 --- a/drivers/media/usb/dvb-usb/dibusb.h
> +++ b/drivers/media/usb/dvb-usb/dibusb.h
> @@ -96,10 +96,15 @@
>  #define DIBUSB_IOCTL_CMD_ENABLE_STREAM   0x01
>  #define DIBUSB_IOCTL_CMD_DISABLE_STREAM  0x02
>  
> +/* Max transfer size done by I2C transfer functions */
> +#define MAX_XFER_SIZE  64
> +
>  struct dibusb_state {
>   struct dib_fe_xfer_ops ops;
>   int mt2060_present;
>   u8 tuner_addr;
> +
> + unsigned char data[MAX_XFER_SIZE];
>  };
>  
>  struct dibusb_device_state {

Reviewed-By: Patrick Boettcher <patrick.boettc...@posteo.de>
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH 07/26] dib0700: be sure that dib0700_ctrl_rd() users can do DMA

2016-10-10 Thread Patrick Boettcher
On Fri,  7 Oct 2016 14:24:17 -0300
Mauro Carvalho Chehab <mche...@s-opensource.com> wrote:

> dib0700_ctrl_rd() takes a RX and a TX pointer. Be sure that
> both will point to a memory allocated via kmalloc().
> 
> Signed-off-by: Mauro Carvalho Chehab <mche...@s-opensource.com>
> ---
>  drivers/media/usb/dvb-usb/dib0700_core.c|  4 +++-
>  drivers/media/usb/dvb-usb/dib0700_devices.c | 25
> + 2 files changed, 16 insertions(+), 13
> deletions(-)
> 
> diff --git a/drivers/media/usb/dvb-usb/dib0700_core.c
> b/drivers/media/usb/dvb-usb/dib0700_core.c index
> f3196658fb70..515f89dba199 100644 ---
> a/drivers/media/usb/dvb-usb/dib0700_core.c +++
> b/drivers/media/usb/dvb-usb/dib0700_core.c @@ -292,13 +292,15 @@
> static int dib0700_i2c_xfer_legacy(struct i2c_adapter *adap, 
>   /* special thing in the current firmware:
> when length is zero the read-failed */ len = dib0700_ctrl_rd(d,
> st->buf, msg[i].len + 2,
> - msg[i+1].buf, msg[i+1].len);
> +   st->buf, msg[i +
> 1].len); if (len <= 0) {
>   deb_info("I2C read failed on address
> 0x%02x\n", msg[i].addr);
>   break;
>   }
>  
> + memcpy(msg[i + 1].buf, st->buf, msg[i +
> 1].len); +
>   msg[i+1].len = len;
>  
>   i++;
> diff --git a/drivers/media/usb/dvb-usb/dib0700_devices.c
> b/drivers/media/usb/dvb-usb/dib0700_devices.c index
> 0857b56e652c..ef1b8ee75c57 100644 ---
> a/drivers/media/usb/dvb-usb/dib0700_devices.c +++
> b/drivers/media/usb/dvb-usb/dib0700_devices.c @@ -508,8 +508,6 @@
> static int stk7700ph_tuner_attach(struct dvb_usb_adapter *adap) 
>  #define DEFAULT_RC_INTERVAL 50
>  
> -static u8 rc_request[] = { REQUEST_POLL_RC, 0 };
> -
>  /*
>   * This function is used only when firmware is < 1.20 version. Newer
>   * firmwares use bulk mode, with functions implemented at
> dib0700_core, @@ -517,7 +515,6 @@ static u8 rc_request[] =
> { REQUEST_POLL_RC, 0 }; */
>  static int dib0700_rc_query_old_firmware(struct dvb_usb_device *d)
>  {
> - u8 key[4];
>   enum rc_type protocol;
>   u32 scancode;
>   u8 toggle;
> @@ -532,39 +529,43 @@ static int dib0700_rc_query_old_firmware(struct
> dvb_usb_device *d) return 0;
>   }
>  
> - i = dib0700_ctrl_rd(d, rc_request, 2, key, 4);
> + st->buf[0] = REQUEST_POLL_RC;
> + st->buf[1] = 0;
> +
> + i = dib0700_ctrl_rd(d, st->buf, 2, st->buf, 4);
>   if (i <= 0) {
>   err("RC Query Failed");
> - return -1;
> + return -EIO;
>   }
>  
>   /* losing half of KEY_0 events from Philipps rc5 remotes.. */
> - if (key[0] == 0 && key[1] == 0 && key[2] == 0 && key[3] == 0)
> + if (st->buf[0] == 0 && st->buf[1] == 0
> + && st->buf[2] == 0 && st->buf[3] == 0)
>   return 0;
>  
> - /* info("%d: %2X %2X %2X
> %2X",dvb_usb_dib0700_ir_proto,(int)key[3-2],(int)key[3-3],(int)key[3-1],(int)key[3]);
> */
> + /* info("%d: %2X %2X %2X
> %2X",dvb_usb_dib0700_ir_proto,(int)st->buf[3 - 2],(int)st->buf[3 -
> 3],(int)st->buf[3 - 1],(int)st->buf[3]);  */ dib0700_rc_setup(d,
> NULL); /* reset ir sensor data to prevent false events */ 
>   switch (d->props.rc.core.protocol) {
>   case RC_BIT_NEC:
>   /* NEC protocol sends repeat code as 0 0 0 FF */
> - if ((key[3-2] == 0x00) && (key[3-3] == 0x00) &&
> - (key[3] == 0xff)) {
> + if ((st->buf[3 - 2] == 0x00) && (st->buf[3 - 3] ==
> 0x00) &&
> + (st->buf[3] == 0xff)) {
>   rc_repeat(d->rc_dev);
>   return 0;
>   }
>  
>   protocol = RC_TYPE_NEC;
> - scancode = RC_SCANCODE_NEC(key[3-2], key[3-3]);
> + scancode = RC_SCANCODE_NEC(st->buf[3 - 2], st->buf[3
> - 3]); toggle = 0;
>   break;
>  
>   default:
>   /* RC-5 protocol changes toggle bit on new keypress
> */ protocol = RC_TYPE_RC5;
> - scancode = RC_SCANCODE_RC5(key[3-2], key[3-3]);
> - toggle = key[3-1];
> + scancode = RC_SCANCODE_RC5(st->buf[3 - 2], st->buf[3
> - 3]);
> + toggle = st->buf[3 - 1];
>   break;
>   }
>  

Reviewed-By: Patrick Boettcher <patrick.boettc...@posteo.de>
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH 05/26] cinergyT2-fe: don't do DMA on stack

2016-10-10 Thread Patrick Boettcher
On Fri,  7 Oct 2016 14:24:15 -0300
Mauro Carvalho Chehab <mche...@s-opensource.com> wrote:

> The USB control messages require DMA to work. We cannot pass
> a stack-allocated buffer, as it is not warranted that the
> stack would be into a DMA enabled area.
> 
> Signed-off-by: Mauro Carvalho Chehab <mche...@s-opensource.com>
> ---
>  drivers/media/usb/dvb-usb/cinergyT2-fe.c | 45
>  1 file changed, 23 insertions(+), 22
> deletions(-)
> 
> diff --git a/drivers/media/usb/dvb-usb/cinergyT2-fe.c
> b/drivers/media/usb/dvb-usb/cinergyT2-fe.c index
> fd8edcb56e61..03ba66ef1f28 100644 ---
> a/drivers/media/usb/dvb-usb/cinergyT2-fe.c +++
> b/drivers/media/usb/dvb-usb/cinergyT2-fe.c @@ -139,6 +139,9 @@ static
> uint16_t compute_tps(struct dtv_frontend_properties *op) struct
> cinergyt2_fe_state { struct dvb_frontend fe;
>   struct dvb_usb_device *d;
> +
> + unsigned char data[64];
> +
>   struct dvbt_get_status_msg status;
>  };
>  
> @@ -146,28 +149,28 @@ static int cinergyt2_fe_read_status(struct
> dvb_frontend *fe, enum fe_status *status)
>  {
>   struct cinergyt2_fe_state *state = fe->demodulator_priv;
> - struct dvbt_get_status_msg result;
> - u8 cmd[] = { CINERGYT2_EP1_GET_TUNER_STATUS };
>   int ret;
>  
> - ret = dvb_usb_generic_rw(state->d, cmd, sizeof(cmd), (u8
> *),
> - sizeof(result), 0);
> + state->data[0] = CINERGYT2_EP1_GET_TUNER_STATUS;
> +
> + ret = dvb_usb_generic_rw(state->d, state->data, 1,
> +  state->data, sizeof(state->status),
> 0); if (ret < 0)
>   return ret;
>  
> - state->status = result;
> + memcpy(>status, state->data, sizeof(state->status));
>  
>   *status = 0;
>  
> - if (0x - le16_to_cpu(result.gain) > 30)
> + if (0x - le16_to_cpu(state->status.gain) > 30)
>   *status |= FE_HAS_SIGNAL;
> - if (result.lock_bits & (1 << 6))
> + if (state->status.lock_bits & (1 << 6))
>   *status |= FE_HAS_LOCK;
> - if (result.lock_bits & (1 << 5))
> + if (state->status.lock_bits & (1 << 5))
>   *status |= FE_HAS_SYNC;
> - if (result.lock_bits & (1 << 4))
> + if (state->status.lock_bits & (1 << 4))
>   *status |= FE_HAS_CARRIER;
> - if (result.lock_bits & (1 << 1))
> + if (state->status.lock_bits & (1 << 1))
>   *status |= FE_HAS_VITERBI;
>  
>   if ((*status & (FE_HAS_CARRIER | FE_HAS_VITERBI |
> FE_HAS_SYNC)) != @@ -232,31 +235,29 @@ static int
> cinergyt2_fe_set_frontend(struct dvb_frontend *fe) {
>   struct dtv_frontend_properties *fep =
> >dtv_property_cache; struct cinergyt2_fe_state *state =
> fe->demodulator_priv;
> - struct dvbt_set_parameters_msg param;
> - char result[2];
> + struct dvbt_set_parameters_msg *param = (void *)state->data;
>   int err;
>  
> - param.cmd = CINERGYT2_EP1_SET_TUNER_PARAMETERS;
> - param.tps = cpu_to_le16(compute_tps(fep));
> - param.freq = cpu_to_le32(fep->frequency / 1000);
> - param.flags = 0;
> + param->cmd = CINERGYT2_EP1_SET_TUNER_PARAMETERS;
> + param->tps = cpu_to_le16(compute_tps(fep));
> + param->freq = cpu_to_le32(fep->frequency / 1000);
> + param->flags = 0;
>  
>   switch (fep->bandwidth_hz) {
>   default:
>   case 800:
> - param.bandwidth = 8;
> + param->bandwidth = 8;
>   break;
>   case 700:
> - param.bandwidth = 7;
> + param->bandwidth = 7;
>   break;
>   case 600:
> - param.bandwidth = 6;
> + param->bandwidth = 6;
>   break;
>   }
>  
> - err = dvb_usb_generic_rw(state->d,
> - (char *), sizeof(param),
> - result, sizeof(result), 0);
> + err = dvb_usb_generic_rw(state->d, state->data,
> sizeof(*param),
> +  state->data, 2, 0);
>   if (err < 0)
>   err("cinergyt2_fe_set_frontend() Failed! err=%d\n",
> err); 

Reviewed-By: Patrick Boettcher <patrick.boettc...@posteo.de>
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH 06/26] cxusb: don't do DMA on stack

2016-10-10 Thread Patrick Boettcher
On Fri,  7 Oct 2016 14:24:16 -0300
Mauro Carvalho Chehab <mche...@s-opensource.com> wrote:

> The USB control messages require DMA to work. We cannot pass
> a stack-allocated buffer, as it is not warranted that the
> stack would be into a DMA enabled area.
> 
> Signed-off-by: Mauro Carvalho Chehab <mche...@s-opensource.com>
> ---
>  drivers/media/usb/dvb-usb/cxusb.c | 20 +++-
>  drivers/media/usb/dvb-usb/cxusb.h |  5 +
>  2 files changed, 12 insertions(+), 13 deletions(-)
> 
> diff --git a/drivers/media/usb/dvb-usb/cxusb.c
> b/drivers/media/usb/dvb-usb/cxusb.c index 907ac01ae297..f3615349de52
> 100644 --- a/drivers/media/usb/dvb-usb/cxusb.c
> +++ b/drivers/media/usb/dvb-usb/cxusb.c
> @@ -45,9 +45,6 @@
>  #include "si2168.h"
>  #include "si2157.h"
>  
> -/* Max transfer size done by I2C transfer functions */
> -#define MAX_XFER_SIZE  80
> -
>  /* debug */
>  static int dvb_usb_cxusb_debug;
>  module_param_named(debug, dvb_usb_cxusb_debug, int, 0644);
> @@ -61,23 +58,20 @@ DVB_DEFINE_MOD_OPT_ADAPTER_NR(adapter_nr);
>  static int cxusb_ctrl_msg(struct dvb_usb_device *d,
> u8 cmd, u8 *wbuf, int wlen, u8 *rbuf, int
> rlen) {
> + struct cxusb_state *st = d->priv;
>   int wo = (rbuf == NULL || rlen == 0); /* write-only */
> - u8 sndbuf[MAX_XFER_SIZE];
>  
> - if (1 + wlen > sizeof(sndbuf)) {
> - warn("i2c wr: len=%d is too big!\n",
> -  wlen);
> + if (1 + wlen > MAX_XFER_SIZE) {
> + warn("i2c wr: len=%d is too big!\n", wlen);
>   return -EOPNOTSUPP;
>   }
>  
> - memset(sndbuf, 0, 1+wlen);
> -
> - sndbuf[0] = cmd;
> - memcpy([1], wbuf, wlen);
> + st->data[0] = cmd;
> + memcpy(>data[1], wbuf, wlen);
>   if (wo)
> - return dvb_usb_generic_write(d, sndbuf, 1+wlen);
> + return dvb_usb_generic_write(d, st->data, 1 + wlen);
>   else
> - return dvb_usb_generic_rw(d, sndbuf, 1+wlen, rbuf,
> rlen, 0);
> + return dvb_usb_generic_rw(d, st->data, 1 + wlen,
> rbuf, rlen, 0); }
>  
>  /* GPIO */
> diff --git a/drivers/media/usb/dvb-usb/cxusb.h
> b/drivers/media/usb/dvb-usb/cxusb.h index 527ff7905e15..18acda19527a
> 100644 --- a/drivers/media/usb/dvb-usb/cxusb.h
> +++ b/drivers/media/usb/dvb-usb/cxusb.h
> @@ -28,10 +28,15 @@
>  #define CMD_ANALOG0x50
>  #define CMD_DIGITAL   0x51
>  
> +/* Max transfer size done by I2C transfer functions */
> +#define MAX_XFER_SIZE  80
> +
>  struct cxusb_state {
>   u8 gpio_write_state[3];
>   struct i2c_client *i2c_client_demod;
>   struct i2c_client *i2c_client_tuner;
> +
> + unsigned char data[MAX_XFER_SIZE];
>  };
>  
>  #endif

Reviewed-By: Patrick Boettcher <patrick.boettc...@posteo.de>
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH 02/26] cinergyT2-core: don't do DMA on stack

2016-10-10 Thread Patrick Boettcher
On Fri,  7 Oct 2016 14:24:12 -0300
Mauro Carvalho Chehab <mche...@s-opensource.com> wrote:

> The USB control messages require DMA to work. We cannot pass
> a stack-allocated buffer, as it is not warranted that the
> stack would be into a DMA enabled area.
> 
> Signed-off-by: Mauro Carvalho Chehab <mche...@s-opensource.com>
> ---
>  drivers/media/usb/dvb-usb/cinergyT2-core.c | 45
> ++ 1 file changed, 27 insertions(+), 18
> deletions(-)
> 
> diff --git a/drivers/media/usb/dvb-usb/cinergyT2-core.c
> b/drivers/media/usb/dvb-usb/cinergyT2-core.c index
> 9fd1527494eb..91640c927776 100644 ---
> a/drivers/media/usb/dvb-usb/cinergyT2-core.c +++
> b/drivers/media/usb/dvb-usb/cinergyT2-core.c @@ -41,6 +41,7 @@
> DVB_DEFINE_MOD_OPT_ADAPTER_NR(adapter_nr); 
>  struct cinergyt2_state {
>   u8 rc_counter;
> + unsigned char data[64];
>  };
>  
>  /* We are missing a release hook with usb_device data */
> @@ -50,29 +51,36 @@ static struct dvb_usb_device_properties
> cinergyt2_properties; 
>  static int cinergyt2_streaming_ctrl(struct dvb_usb_adapter *adap,
> int enable) {
> - char buf[] = { CINERGYT2_EP1_CONTROL_STREAM_TRANSFER,
> enable ? 1 : 0 };
> - char result[64];
> - return dvb_usb_generic_rw(adap->dev, buf, sizeof(buf),
> result,
> - sizeof(result), 0);
> + struct dvb_usb_device *d = adap->dev;
> + struct cinergyt2_state *st = d->priv;
> +
> + st->data[0] = CINERGYT2_EP1_CONTROL_STREAM_TRANSFER;
> + st->data[1] = enable ? 1 : 0;
> +
> + return dvb_usb_generic_rw(d, st->data, 2, st->data, 64, 0);
>  }
>  
>  static int cinergyt2_power_ctrl(struct dvb_usb_device *d, int enable)
>  {
> - char buf[] = { CINERGYT2_EP1_SLEEP_MODE, enable ? 0 : 1 };
> - char state[3];
> - return dvb_usb_generic_rw(d, buf, sizeof(buf), state,
> sizeof(state), 0);
> + struct cinergyt2_state *st = d->priv;
> +
> + st->data[0] = CINERGYT2_EP1_SLEEP_MODE;
> + st->data[1] = enable ? 0 : 1;
> +
> + return dvb_usb_generic_rw(d, st->data, 2, st->data, 3, 0);
>  }
>  
>  static int cinergyt2_frontend_attach(struct dvb_usb_adapter *adap)
>  {
> - char query[] = { CINERGYT2_EP1_GET_FIRMWARE_VERSION };
> - char state[3];
> + struct dvb_usb_device *d = adap->dev;
> + struct cinergyt2_state *st = d->priv;
>   int ret;
>  
>   adap->fe_adap[0].fe = cinergyt2_fe_attach(adap->dev);
>  
> - ret = dvb_usb_generic_rw(adap->dev, query, sizeof(query),
> state,
> - sizeof(state), 0);
> + st->data[0] = CINERGYT2_EP1_GET_FIRMWARE_VERSION;
> +
> + ret = dvb_usb_generic_rw(d, st->data, 1, st->data, 3, 0);
>   if (ret < 0) {
>   deb_rc("cinergyt2_power_ctrl() Failed to retrieve
> sleep " "state info\n");
> @@ -141,13 +149,14 @@ static int repeatable_keys[] = {
>  static int cinergyt2_rc_query(struct dvb_usb_device *d, u32 *event,
> int *state) {
>   struct cinergyt2_state *st = d->priv;
> - u8 key[5] = {0, 0, 0, 0, 0}, cmd =
> CINERGYT2_EP1_GET_RC_EVENTS; int i;
>  
>   *state = REMOTE_NO_KEY_PRESSED;
>  
> - dvb_usb_generic_rw(d, , 1, key, sizeof(key), 0);
> - if (key[4] == 0xff) {
> + st->data[0] = CINERGYT2_EP1_GET_RC_EVENTS;
> +
> + dvb_usb_generic_rw(d, st->data, 1, st->data, 5, 0);
> + if (st->data[4] == 0xff) {
>   /* key repeat */
>   st->rc_counter++;
>   if (st->rc_counter > RC_REPEAT_DELAY) {
> @@ -166,13 +175,13 @@ static int cinergyt2_rc_query(struct
> dvb_usb_device *d, u32 *event, int *state) }
>  
>   /* hack to pass checksum on the custom field */
> - key[2] = ~key[1];
> - dvb_usb_nec_rc_key_to_event(d, key, event, state);
> - if (key[0] != 0) {
> + st->data[2] = ~st->data[1];
> + dvb_usb_nec_rc_key_to_event(d, st->data, event, state);
> + if (st->data[0] != 0) {
>   if (*event != d->last_event)
>   st->rc_counter = 0;
>  
> - deb_rc("key: %*ph\n", 5, key);
> + deb_rc("key: %*ph\n", 5, st->data);
>   }
>   return 0;
>  }

Reviewed-By: Patrick Boettcher <patrick.boettc...@posteo.de>
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH 08/26] dib0700_core: don't use stack on I2C reads

2016-10-10 Thread Patrick Boettcher
On Fri,  7 Oct 2016 14:24:18 -0300
Mauro Carvalho Chehab <mche...@s-opensource.com> wrote:

> Be sure that I2C reads won't use stack by passing
> a pointer to the state buffer, that we know it was
> allocated via kmalloc, instead of relying on the buffer
> allocated by an I2C client.
> 
> Signed-off-by: Mauro Carvalho Chehab <mche...@s-opensource.com>
> ---
>  drivers/media/usb/dvb-usb/dib0700_core.c | 27
> ++- 1 file changed, 26 insertions(+), 1
> deletion(-)
> 
> diff --git a/drivers/media/usb/dvb-usb/dib0700_core.c
> b/drivers/media/usb/dvb-usb/dib0700_core.c index
> 515f89dba199..92d5408684ac 100644 ---
> a/drivers/media/usb/dvb-usb/dib0700_core.c +++
> b/drivers/media/usb/dvb-usb/dib0700_core.c @@ -213,7 +213,7 @@ static
> int dib0700_i2c_xfer_new(struct i2c_adapter *adap, struct i2c_msg
> *msg, usb_rcvctrlpipe(d->udev, 0), REQUEST_NEW_I2C_READ,
>USB_TYPE_VENDOR |
> USB_DIR_IN,
> -  value, index,
> msg[i].buf,
> +  value, index,
> st->buf, msg[i].len,
>USB_CTRL_GET_TIMEOUT);
>   if (result < 0) {
> @@ -221,6 +221,14 @@ static int dib0700_i2c_xfer_new(struct
> i2c_adapter *adap, struct i2c_msg *msg, break;
>   }
>  
> + if (msg[i].len > sizeof(st->buf)) {
> + deb_info("buffer too small to fit %d
> bytes\n",
> +  msg[i].len);
> + return -EIO;
> + }
> +
> + memcpy(msg[i].buf, st->buf, msg[i].len);
> +
>   deb_data("<<< ");
>   debug_dump(msg[i].buf, msg[i].len, deb_data);
>  
> @@ -238,6 +246,13 @@ static int dib0700_i2c_xfer_new(struct
> i2c_adapter *adap, struct i2c_msg *msg, /* I2C ctrl + FE bus; */
>   st->buf[3] = ((gen_mode << 6) & 0xC0) |
>((bus_mode << 4) & 0x30);
> +
> + if (msg[i].len > sizeof(st->buf) - 4) {
> + deb_info("i2c message to big: %d\n",
> +  msg[i].len);
> + return -EIO;
> + }
> +
>   /* The Actual i2c payload */
>   memcpy(>buf[4], msg[i].buf, msg[i].len);
>  
> @@ -283,6 +298,11 @@ static int dib0700_i2c_xfer_legacy(struct
> i2c_adapter *adap, /* fill in the address */
>   st->buf[1] = msg[i].addr << 1;
>   /* fill the buffer */
> + if (msg[i].len > sizeof(st->buf) - 2) {
> + deb_info("i2c xfer to big: %d\n",
> + msg[i].len);
> + return -EIO;
> + }
>   memcpy(>buf[2], msg[i].buf, msg[i].len);
>  
>   /* write/read request */
> @@ -299,6 +319,11 @@ static int dib0700_i2c_xfer_legacy(struct
> i2c_adapter *adap, break;
>   }
>  
> + if (msg[i + 1].len > sizeof(st->buf)) {
> + deb_info("i2c xfer buffer to small
> for %d\n",
> + msg[i].len);
> + return -EIO;
> + }
>   memcpy(msg[i + 1].buf, st->buf, msg[i +
> 1].len); 
>   msg[i+1].len = len;

Reviewed-By: Patrick Boettcher <patrick.boettc...@posteo.de>
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH 11/26] digitv: don't do DMA on stack

2016-10-10 Thread Patrick Boettcher
On Fri,  7 Oct 2016 14:24:21 -0300
Mauro Carvalho Chehab <mche...@s-opensource.com> wrote:

> The USB control messages require DMA to work. We cannot pass
> a stack-allocated buffer, as it is not warranted that the
> stack would be into a DMA enabled area.
> 
> Signed-off-by: Mauro Carvalho Chehab <mche...@s-opensource.com>
> ---
>  drivers/media/usb/dvb-usb/digitv.c | 20 +++-
>  drivers/media/usb/dvb-usb/digitv.h |  3 +++
>  2 files changed, 14 insertions(+), 9 deletions(-)
> 
> diff --git a/drivers/media/usb/dvb-usb/digitv.c
> b/drivers/media/usb/dvb-usb/digitv.c index 63134335c994..09f8c28bd4db
> 100644 --- a/drivers/media/usb/dvb-usb/digitv.c
> +++ b/drivers/media/usb/dvb-usb/digitv.c
> @@ -28,20 +28,22 @@ DVB_DEFINE_MOD_OPT_ADAPTER_NR(adapter_nr);
>  static int digitv_ctrl_msg(struct dvb_usb_device *d,
>   u8 cmd, u8 vv, u8 *wbuf, int wlen, u8 *rbuf, int
> rlen) {
> + struct digitv_state *st = d->priv;
>   int wo = (rbuf == NULL || rlen == 0); /* write-only */
> - u8 sndbuf[7],rcvbuf[7];
> - memset(sndbuf,0,7); memset(rcvbuf,0,7);
>  
> - sndbuf[0] = cmd;
> - sndbuf[1] = vv;
> - sndbuf[2] = wo ? wlen : rlen;
> + memset(st->sndbuf, 0, 7);
> + memset(st->rcvbuf, 0, 7);
> +
> + st->sndbuf[0] = cmd;
> + st->sndbuf[1] = vv;
> + st->sndbuf[2] = wo ? wlen : rlen;
>  
>   if (wo) {
> - memcpy([3],wbuf,wlen);
> - dvb_usb_generic_write(d,sndbuf,7);
> + memcpy(>sndbuf[3], wbuf, wlen);
> + dvb_usb_generic_write(d, st->sndbuf, 7);
>   } else {
> - dvb_usb_generic_rw(d,sndbuf,7,rcvbuf,7,10);
> - memcpy(rbuf,[3],rlen);
> + dvb_usb_generic_rw(d, st->sndbuf, 7, st->rcvbuf, 7,
> 10);
> + memcpy(rbuf, >rcvbuf[3], rlen);
>   }
>   return 0;
>  }
> diff --git a/drivers/media/usb/dvb-usb/digitv.h
> b/drivers/media/usb/dvb-usb/digitv.h index 908c09f4966b..cf104689bdff
> 100644 --- a/drivers/media/usb/dvb-usb/digitv.h
> +++ b/drivers/media/usb/dvb-usb/digitv.h
> @@ -6,6 +6,9 @@
>  
>  struct digitv_state {
>  int is_nxt6000;
> +
> +unsigned char sndbuf[7];
> +unsigned char rcvbuf[7];
>  };
>  
>  /* protocol (from usblogging and the SDK:

Reviewed-By: Patrick Boettcher <patrick.boettc...@posteo.de>
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH 14/26] dtt200u: don't do DMA on stack

2016-10-10 Thread Patrick Boettcher
0u_properties = { .usb_ctrl = CYPRESS_FX2,
>   .firmware = "dvb-usb-dtt200u-01.fw",
>  
> + .size_of_priv = sizeof(struct dtt200u_state),
> +
>   .num_adapters = 1,
>   .adapter = {
>   {
> @@ -190,6 +207,8 @@ static struct dvb_usb_device_properties
> wt220u_properties = { .usb_ctrl = CYPRESS_FX2,
>   .firmware = "dvb-usb-wt220u-02.fw",
>  
> + .size_of_priv = sizeof(struct dtt200u_state),
> +
>   .num_adapters = 1,
>   .adapter = {
>   {
> @@ -240,6 +259,8 @@ static struct dvb_usb_device_properties
> wt220u_fc_properties = { .usb_ctrl = CYPRESS_FX2,
>   .firmware = "dvb-usb-wt220u-fc03.fw",
>  
> + .size_of_priv = sizeof(struct dtt200u_state),
> +
>   .num_adapters = 1,
>   .adapter = {
>   {
> @@ -290,6 +311,8 @@ static struct dvb_usb_device_properties
> wt220u_zl0353_properties = { .usb_ctrl = CYPRESS_FX2,
>   .firmware = "dvb-usb-wt220u-zl0353-01.fw",
>  
> + .size_of_priv = sizeof(struct dtt200u_state),
> +
>   .num_adapters = 1,
>   .adapter = {
>   {
> @@ -340,6 +363,8 @@ static struct dvb_usb_device_properties
> wt220u_miglia_properties = { .usb_ctrl = CYPRESS_FX2,
>   .firmware = "dvb-usb-wt220u-miglia-01.fw",
>  
> + .size_of_priv = sizeof(struct dtt200u_state),
> +
>   .num_adapters = 1,
>   .generic_bulk_ctrl_endpoint = 0x01,
>  

Reviewed-By: Patrick Boettcher <patrick.boettc...@posteo.de>
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH 19/26] nova-t-usb2: don't do DMA on stack

2016-10-10 Thread Patrick Boettcher
On Fri,  7 Oct 2016 14:24:29 -0300
Mauro Carvalho Chehab <mche...@s-opensource.com> wrote:

> The USB control messages require DMA to work. We cannot pass
> a stack-allocated buffer, as it is not warranted that the
> stack would be into a DMA enabled area.
> 
> Signed-off-by: Mauro Carvalho Chehab <mche...@s-opensource.com>
> ---
>  drivers/media/usb/dvb-usb/nova-t-usb2.c | 18 +-
>  1 file changed, 13 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/media/usb/dvb-usb/nova-t-usb2.c
> b/drivers/media/usb/dvb-usb/nova-t-usb2.c index
> fc7569e2728d..26d7188a1163 100644 ---
> a/drivers/media/usb/dvb-usb/nova-t-usb2.c +++
> b/drivers/media/usb/dvb-usb/nova-t-usb2.c @@ -74,22 +74,29 @@ static
> struct rc_map_table rc_map_haupp_table[] = { */
>  static int nova_t_rc_query(struct dvb_usb_device *d, u32 *event, int
> *state) {
> - u8 key[5],cmd[2] = { DIBUSB_REQ_POLL_REMOTE, 0x35 },
> data,toggle,custom;
> + u8 *buf, data, toggle, custom;
>   u16 raw;
>   int i;
>   struct dibusb_device_state *st = d->priv;
>  
> - dvb_usb_generic_rw(d,cmd,2,key,5,0);
> + buf = kmalloc(5, GFP_KERNEL);
> + if (!buf)
> + return -ENOMEM;
> +
> + buf[0] = DIBUSB_REQ_POLL_REMOTE;
> + buf[1] = 0x35;
> + dvb_usb_generic_rw(d, buf, 2, buf, 5, 0);
>  
>   *state = REMOTE_NO_KEY_PRESSED;
> - switch (key[0]) {
> + switch (buf[0]) {
>   case DIBUSB_RC_HAUPPAUGE_KEY_PRESSED:
> - raw = ((key[1] << 8) | key[2]) >> 3;
> + raw = ((buf[1] << 8) | buf[2]) >> 3;
>   toggle = !!(raw & 0x800);
>   data = raw & 0x3f;
>   custom = (raw >> 6) & 0x1f;
>  
> - deb_rc("raw key code 0x%02x, 0x%02x, 0x%02x
> to c: %02x d: %02x toggle:
> %d\n",key[1],key[2],key[3],custom,data,toggle);
> + deb_rc("raw key code 0x%02x, 0x%02x, 0x%02x
> to c: %02x d: %02x toggle: %d\n",
> +buf[1], buf[2], buf[3], custom, data,
> toggle); 
>   for (i = 0; i <
> ARRAY_SIZE(rc_map_haupp_table); i++) { if
> (rc5_data(_map_haupp_table[i]) == data && @@ -117,6 +124,7 @@
> static int nova_t_rc_query(struct dvb_usb_device *d, u32 *event, int
> *state) break; }
>  
> + kfree(buf);
>   return 0;
>  }
>  

Reviewed-By: Patrick Boettcher <patrick.boettc...@posteo.de>
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH 20/26] pctv452e: don't do DMA on stack

2016-10-10 Thread Patrick Boettcher
 %02X %02X -> "
> -  "%02X %02X  %02X %02X %02X.",
> + err("I2C error %d; %02X %02X  %02X %02X %02X -> %*ph",
>ret, SYNC_BYTE_OUT, id, addr << 1, snd_len, rcv_len,
> -  buf[0], buf[1], buf[4], buf[5], buf[6]);
> -
> +  7, state->data);
>   return ret;
>  }
>  
> @@ -499,8 +497,7 @@ static u32 pctv452e_i2c_func(struct i2c_adapter
> *adapter) static int pctv452e_power_ctrl(struct dvb_usb_device *d,
> int i) {
>   struct pctv452e_state *state = (struct pctv452e_state
> *)d->priv;
> - u8 b0[] = { 0xaa, 0, PCTV_CMD_RESET, 1, 0 };
> - u8 rx[PCTV_ANSWER_LEN];
> + u8 *rx;
>   int ret;
>  
>   info("%s: %d\n", __func__, i);
> @@ -511,6 +508,10 @@ static int pctv452e_power_ctrl(struct
> dvb_usb_device *d, int i) if (state->initialized)
>   return 0;
>  
> + rx = kmalloc(PCTV_ANSWER_LEN, GFP_KERNEL);
> + if (!rx)
> + return -ENOMEM;
> +
>   /* hmm where shoud this should go? */
>   ret = usb_set_interface(d->udev, 0,
> ISOC_INTERFACE_ALTERNATIVE); if (ret != 0)
> @@ -518,57 +519,62 @@ static int pctv452e_power_ctrl(struct
> dvb_usb_device *d, int i) __func__, ret);
>  
>   /* this is a one-time initialization, dont know where to put
> */
> - b0[1] = state->c++;
> + state->data[0] = 0xaa;
> + state->data[1] = state->c++;
> + state->data[2] = PCTV_CMD_RESET;
> + state->data[3] = 1;
> + state->data[4] = 0;
>   /* reset board */
> - ret = dvb_usb_generic_rw(d, b0, sizeof(b0), rx,
> PCTV_ANSWER_LEN, 0);
> + ret = dvb_usb_generic_rw(d, state->data, 5, rx,
> PCTV_ANSWER_LEN, 0); if (ret)
> - return ret;
> + goto ret;
>  
> - b0[1] = state->c++;
> - b0[4] = 1;
> + state->data[1] = state->c++;
> + state->data[4] = 1;
>   /* reset board (again?) */
> - ret = dvb_usb_generic_rw(d, b0, sizeof(b0), rx,
> PCTV_ANSWER_LEN, 0);
> + ret = dvb_usb_generic_rw(d, state->data, 5, rx,
> PCTV_ANSWER_LEN, 0); if (ret)
> - return ret;
> + goto ret;
>  
>   state->initialized = 1;
>  
> - return 0;
> +ret:
> + kfree(rx);
> + return ret;
>  }
>  
>  static int pctv452e_rc_query(struct dvb_usb_device *d)
>  {
>   struct pctv452e_state *state = (struct pctv452e_state
> *)d->priv;
> - u8 b[CMD_BUFFER_SIZE];
> - u8 rx[PCTV_ANSWER_LEN];
>   int ret, i;
>   u8 id = state->c++;
>  
>   /* prepare command header  */
> - b[0] = SYNC_BYTE_OUT;
> - b[1] = id;
> - b[2] = PCTV_CMD_IR;
> - b[3] = 0;
> + state->data[0] = SYNC_BYTE_OUT;
> + state->data[1] = id;
> + state->data[2] = PCTV_CMD_IR;
> + state->data[3] = 0;
>  
>   /* send ir request */
> - ret = dvb_usb_generic_rw(d, b, 4, rx, PCTV_ANSWER_LEN, 0);
> + ret = dvb_usb_generic_rw(d, state->data, 4,
> +  state->data, PCTV_ANSWER_LEN, 0);
>   if (ret != 0)
>   return ret;
>  
>   if (debug > 3) {
> - info("%s: read: %2d: %*ph: ", __func__, ret, 3, rx);
> - for (i = 0; (i < rx[3]) && ((i+3) <
> PCTV_ANSWER_LEN); i++)
> - info(" %02x", rx[i+3]);
> + info("%s: read: %2d: %*ph: ", __func__, ret, 3,
> state->data);
> + for (i = 0; (i < state->data[3]) && ((i + 3) <
> PCTV_ANSWER_LEN); i++)
> + info(" %02x", state->data[i + 3]);
>  
>   info("\n");
>   }
>  
> - if ((rx[3] == 9) &&  (rx[12] & 0x01)) {
> + if ((state->data[3] == 9) &&  (state->data[12] & 0x01)) {
>   /* got a "press" event */
> - state->last_rc_key = RC_SCANCODE_RC5(rx[7], rx[6]);
> + state->last_rc_key = RC_SCANCODE_RC5(state->data[7],
> state->data[6]); if (debug > 2)
>   info("%s: cmd=0x%02x sys=0x%02x\n",
> - __func__, rx[6], rx[7]);
> + __func__, state->data[6],
> state->data[7]); 
>   rc_keydown(d->rc_dev, RC_TYPE_RC5,
> state->last_rc_key, 0); } else if (state->last_rc_key) {

Reviewed-By: Patrick Boettcher <patrick.boettc...@posteo.de>
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH 22/26] technisat-usb2: use DMA buffers for I2C transfers

2016-10-10 Thread Patrick Boettcher
On Fri,  7 Oct 2016 14:24:32 -0300
Mauro Carvalho Chehab <mche...@s-opensource.com> wrote:

> The USB control messages require DMA to work. We cannot pass
> a stack-allocated buffer, as it is not warranted that the
> stack would be into a DMA enabled area.
> 
> On this driver, most of the transfers are OK, but the I2C
> one was using stack.
> 
> Signed-off-by: Mauro Carvalho Chehab <mche...@s-opensource.com>
> ---
>  drivers/media/usb/dvb-usb/technisat-usb2.c | 16 +++-
>  1 file changed, 11 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/media/usb/dvb-usb/technisat-usb2.c
> b/drivers/media/usb/dvb-usb/technisat-usb2.c index
> d9f3262bf071..4706628a3ed5 100644 ---
> a/drivers/media/usb/dvb-usb/technisat-usb2.c +++
> b/drivers/media/usb/dvb-usb/technisat-usb2.c @@ -89,9 +89,13 @@
> struct technisat_usb2_state { static int
> technisat_usb2_i2c_access(struct usb_device *udev, u8 device_addr, u8
> *tx, u8 txlen, u8 *rx, u8 rxlen) {
> - u8 b[64];
> + u8 *b;
>   int ret, actual_length;
>  
> + b = kmalloc(64, GFP_KERNEL);
> + if (!b)
> + return -ENOMEM;
> +
>   deb_i2c("i2c-access: %02x, tx: ", device_addr);
>   debug_dump(tx, txlen, deb_i2c);
>   deb_i2c(" ");
> @@ -123,7 +127,7 @@ static int technisat_usb2_i2c_access(struct
> usb_device *udev, 
>   if (ret < 0) {
>   err("i2c-error: out failed %02x = %d", device_addr,
> ret);
> - return -ENODEV;
> + goto err;
>   }
>  
>   ret = usb_bulk_msg(udev,
> @@ -131,7 +135,7 @@ static int technisat_usb2_i2c_access(struct
> usb_device *udev, b, 64, _length, 1000);
>   if (ret < 0) {
>   err("i2c-error: in failed %02x = %d", device_addr,
> ret);
> - return -ENODEV;
> + goto err;
>   }
>  
>   if (b[0] != I2C_STATUS_OK) {
> @@ -140,7 +144,7 @@ static int technisat_usb2_i2c_access(struct
> usb_device *udev, if (!(b[0] == I2C_STATUS_NAK &&
>   device_addr == 0x60
>   /* && device_is_technisat_usb2 */))
> - return -ENODEV;
> + goto err;
>   }
>  
>   deb_i2c("status: %d, ", b[0]);
> @@ -154,7 +158,9 @@ static int technisat_usb2_i2c_access(struct
> usb_device *udev, 
>   deb_i2c("\n");
>  
> - return 0;
> +err:
> + kfree(b);
> + return ret;
>  }
>  
>  static int technisat_usb2_i2c_xfer(struct i2c_adapter *adap, struct
> i2c_msg *msg,

Reviewed-By: Patrick Boettcher <patrick.boettc...@posteo.de>

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


Re: RFC - unclear change in "[media] DiBxxxx: Codingstype updates"

2016-10-10 Thread Patrick Boettcher
Hi, der Herr Hofrat ;-)

On Sat, 8 Oct 2016 13:57:14 +
Nicholas Mc Guire  wrote:
> - lo6 |= (1 << 2) | 2;
> - else
> - lo6 |= (1 << 2) | 1;
> + lo6 |= (1 << 2) | 2;//SigmaDelta and Dither
> + else {
> + if (state->identity.in_soc)
> + lo6 |= (1 << 2) | 2;//SigmaDelta and
> Dither
> + else
> + lo6 |= (1 << 2) | 2;//SigmaDelta and
> Dither
> + }
> 
>  resulting in the current code-base of:
> 
>if (Rest > 0) {
>if (state->config->analog_output)
>lo6 |= (1 << 2) | 2;
>else {
>if (state->identity.in_soc)
>lo6 |= (1 << 2) | 2;
>else
>lo6 |= (1 << 2) | 2;
>}
>Den = 255;
>}
> 
>  The problem now is that the if and the else(if/else) are
>  all the same and thus the conditions have no effect. Further
>  the origninal code actually had different if/else - so I 
>  wonder if this is a cut bug here ?

I may answer on behalf of Olivier (didn't his address bounce?).

I don't remember the details, this patch must date from 2011 or
before, but at that time we generated the linux-driver from our/their
internal sources.

Updates in this area were achieved by a lot of thinking + a mix of trial
and error (after hours/days/weeks of RF hardware validation). 

This logic above has 3 possibilities: 

  - we use the analog-output, or 
  - we are using the digital one, then there is whether we are being in
a SoC or not (SIP or sinlge chip).

At some point in time all values have been different. In the end, they
aren't anymore, but in case someone wants to try a different value,
there are placeholders in the code to easily inject these values.

Now the device is stable, maybe even obsolete. We could remove all the
branches resulting in the same value for lo6.

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


dvb-usb stack-memory used for URB-buffers (was: Re: Problem with VMAP_STACK=y)

2016-10-05 Thread Patrick Boettcher
Hi,

On Tue, 4 Oct 2016 15:26:28 +0200 (CEST)
Jiri Kosina  wrote:

> On Tue, 4 Oct 2016, Jörg Otte wrote:
> 
> > With kernel 4.8.0-01558-g21f54dd I get thousands of
> > "dvb-usb: bulk message failed: -11 (1/0)"
> > messages in the logs and the DVB adapter is not working.
> > 
> > It tourned out the new config option VMAP_STACK=y (which is the
> > default) is the culprit.
> > No problems for me with VMAP_STACK=n.  
> 
> I'd guess that this is EAGAIN coming from usb_hcd_map_urb_for_dma()
> as the DVB driver is trying to perform on-stack DMA.

I really thought that this youngster-mistake of mien (these
drivers+framework date from 2004-2006 and there it worked just fine)
had been fixed some years ago. 

Seems not the be the case :-(.

However, I'm happy to see people using these devices now. Even
though I don't have them anymore (or never had them in the first place).

Mauro, could you please bring me up to speed or remind when and
where you did changes in this regard? I got a little bit rusty
regarding linux-media, but I'd be happy to help.

regards,
-- 
Patrick.
--
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: Problem with VMAP_STACK=y

2016-10-05 Thread Patrick Boettcher
On Wed, 5 Oct 2016 09:26:29 +0200 (CEST)
Jiri Kosina  wrote:

> On Tue, 4 Oct 2016, Jörg Otte wrote:
> 
> > Thanks for the quick response.
> > Drivers are:
> > dvb_core, dvb_usb, dbv_usb_cynergyT2  
> 
> This dbv_usb_cynergyT2 is not from Linus' tree, is it? I don't seem
> to be able to find it, and the only google hit I am getting is your
> very mail to LKML :)

It's a typo, it should say dvb_usb_cinergyT2.

-- 
Patrick.
--
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 13/19] dib0090: comment out the unused tables

2016-06-26 Thread Patrick Boettcher
Hi Mauro,

On Fri, 24 Jun 2016 12:31:54 -0300
Mauro Carvalho Chehab  wrote:

> Those tables are currently unused, so comment them out:

We actually could remove these tables. It is very, very unlikely that
this device will ever be used for S-Band in the future.
Extremely unlikely.

best regards,
-- 
Patrick.
--
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:

2015-11-13 Thread Patrick Boettcher
On Thu, 12 Nov 2015 15:41:50 -0200 Mauro Carvalho Chehab
 wrote:
> > Is putting the patch in an attachment OK?
> 
> No, because it doesn't make easy for people to reply with comments.

Except if you are using claws. With which you can select text in a text
attachment and click the reply button and it will create a response
with the selected text in the message body. But only this part, not the
rest of the message.

regards,
--
Patrick.
--
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: PCTV Triplestick and Raspberry Pi B+

2015-07-08 Thread Patrick Boettcher
On Tue, 7 Jul 2015 18:51:16 +0200 (SST) Peter Fassberg p...@leissner.se
wrote:

 On Tue, 7 Jul 2015, Patrick Boettcher wrote:
 
  Might be the RF frequency that is truncated on 32bit platforms
  somewhere. That could explain that there is no crash but simply not
  tuning.
 
 This is the current status:
 
 ARM 32-bit, kernel 4.0.6, updated media_tree: Works with DVB-T, no lock on 
 DVB-T2.
 
 Intel 32-bit, kernel 3.16.0, standard media_tree: Locks, but no PSIs detected.
 
 Intel 64-bit, kernel 3.16.0, standard media_tree: Works like a charm.
 
 
 So I don't think that en RF freq is truncated.

Yes, it was an assumption - not a right one as it turned out. I didn't
find any obvious 32/64-problem in the si*-drivers you are using.

I'm too afraid to look into the em*-drivers and I doubt that there is
any obvious 32/64-bit-problem.

If I were you, I would try to compare the usb-traffic (using
usbmon with wireshark) between a working tune on one frequency with one
standard on each of the 3 scenarios (maybe starting with the intel 32
and 64 platform).

For example

on each platform:

1) start wireshark-capture on the right USB-port,
2) plug the device, 
3) tune (tzap) a valid DVB-T frequency
4) stop capturing

Then compare the traffic log. Most outgoing data should be
identical. Incoming data (except monitoring values and TS) should be
equal as well.

If you see differences in data-buffer-sizes or during the
firmware-download-phase or anywhere else, we can try to find the code
which corresponds and place debug messages. You are lucky, your drivers
are using embedded firmwares which simplifies the communication between
the driver and the device.

regards,
--
Patrick.
--
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: PCTV Triplestick and Raspberry Pi B+

2015-07-07 Thread Patrick Boettcher
On Tue, 7 Jul 2015 17:33:01 +0200 (SST) Peter Fassberg p...@leissner.se
wrote:

 On Sun, 5 Jul 2015, Patrick Boettcher wrote:
 
  Your Intel platform is 64bit. I don't know the TripleStick nor the SI or
  the EM28xx-driver but _maybe_ there is a problem with it on 32-bit
  platforms. A long shot, I know, but you'll never know.
 
 That was a very good point.
 
 I installed the 32-bit version of the same OS (Debian 8, kernel 3.16.0, i386) 
 and the result was a bit suprising.
 
 In 32-bit I couldn't even scan a DVT-T transponder!  dvbv5-scan did Lock, but 
 it didn't find any PSI PIDs.  So there is for sure a problem with 32-bit 
 platforms.  And the DVT-T2 transponders didn't work either.
 
 Maybe the Raspberry problem can be a Endianess problem?

No, rpi (arm) is little-endian as Intel.

Which drivers is your device using again? 

regards,
--
Patrick.

--
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: PCTV Triplestick and Raspberry Pi B+

2015-07-07 Thread Patrick Boettcher
On Tue, 7 Jul 2015 17:38:25 +0200 (SST)
Peter Fassberg p...@leissner.se wrote:

 On Tue, 7 Jul 2015, Patrick Boettcher wrote:
 
  I installed the 32-bit version of the same OS (Debian 8, kernel 3.16.0, 
  i386) and the result was a bit suprising.
 
  In 32-bit I couldn't even scan a DVT-T transponder!  dvbv5-scan did Lock, 
  but it didn't find any PSI PIDs.  So there is for sure a problem with 
  32-bit platforms.  And the DVT-T2 transponders didn't work either.
 
  Maybe the Raspberry problem can be a Endianess problem?
 
  No, rpi (arm) is little-endian as Intel.
 
  Which drivers is your device using again?
 
 [7.245815] em28xx: New device PCTV PCTV 292e @ 480 Mbps (2013:025f, 
 interface 0, class 0)
 [7.256731] em28xx: DVB interface 0 found: isoc
 [7.262712] em28xx: chip ID is em28178
 [9.258341] em28178 #0: EEPROM ID = 26 00 01 00, EEPROM hash = 0x5110ff04
 [9.267163] em28178 #0: EEPROM info:
 [9.272644] em28178 #0:  microcode start address = 0x0004, boot 
 configuration = 0x01
 [9.291418] em28178 #0:  AC97 audio (5 sample rates)
 [9.298231] em28178 #0:  500mA max power
 [9.303993] em28178 #0:  Table at offset 0x27, strings=0x146a, 0x1888, 
 0x0a7e
 [9.313288] em28178 #0: Identified as PCTV tripleStick (292e) (card=94)
 [9.321852] em28178 #0: dvb set to isoc mode.
 [9.328536] usbcore: registered new interface driver em28xx
 [9.357476] em28178 #0: Binding DVB extension
 [9.380909] i2c i2c-1: Added multiplexed i2c bus 2
 [9.389469] si2168 1-0064: Silicon Labs Si2168 successfully attached
 [9.410263] si2157 2-0060: Silicon Labs Si2147/2148/2157/2158 successfully 
 attached
 [9.422419] DVB: registering new adapter (em28178 #0)
 [9.428929] usb 1-1.4: DVB: registering adapter 0 frontend 0 (Silicon Labs 
 Si2168)...
 [9.442954] em28178 #0: DVB extension successfully initialized
 [9.450692] em28xx: Registered (Em28xx dvb Extension) extension
 [9.482115] em28178 #0: Registering input extension
 [9.563907] em28178 #0: Input extension successfully initalized
 [9.571364] em28xx: Registered (Em28xx Input Extension) extension
 [  297.703612] si2168 1-0064: found a 'Silicon Labs Si2168-B40'
 [  300.998391] si2168 1-0064: downloading firmware from file 
 'dvb-demod-si2168-b40-01.fw'
 [  301.275434] si2168 1-0064: firmware version: 4.0.4 [  301.284625] si2157 
 2-0060: found a 'Silicon Labs Si2157-A30'
 [  301.340643] si2157 2-0060: firmware version: 3.0.5

Just reading quickly the changes made to the si2157 and si2168 driver
since 3.16 up to 4.1 makes me think that it is worth a try. 

Plenty of things have changed regarding buffers and memcpy. Though I
haven't found (yet) a 64bit and 32bit mix up yet in the 3.16 version.

Might be the RF frequency that is truncated on 32bit platforms
somewhere. That could explain that there is no crash but simply not
tuning.

Can you easily try more recent kernels or media_trees?
--
Patrick.



--
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: PCTV Triplestick and Raspberry Pi B+

2015-07-07 Thread Patrick Boettcher
On Tue, 7 Jul 2015 18:25:41 +0200
Patrick Boettcher patrick.boettc...@posteo.de wrote:

  [  301.275434] si2168 1-0064: firmware version: 4.0.4 [  301.284625] si2157 
  2-0060: found a 'Silicon Labs Si2157-A30'
  [  301.340643] si2157 2-0060: firmware version: 3.0.5

 Can you easily try more recent kernels or media_trees?

It seems you are already using a more recent version of the
si21xx-drivers than provided with 3.16. (in 3.16.0 there is no firmware
version-print in si2157)

--
Patrick.
--
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: PCTV Triplestick and Raspberry Pi B+

2015-07-05 Thread Patrick Boettcher
Hi,

On Sat, 4 Jul 2015 13:07:17 +0200 (SST)
Peter Fassberg p...@leissner.se wrote:

 Hi all!
 
 I'm trying to get PCTV TripleStick 292e working in a Raspberry Pi B+
 environment.
 
 I have no problem getting DVB-T to work, but I can't tune to any
 DVB-T2 channels. I have tried with three different kernels: 3.18.11,
 3.18.16 and 4.0.6.  Same problem.  I also cloned the media_build
 under 4.0.6 to no avail.
 
 The same physical stick works perfectly with DVB-T2 in an Intel
 platform using kernel 3.16.0.

Your Intel platform is 64bit. I don't know the TripleStick nor the SI or
the EM28xx-driver but _maybe_ there is a problem with it on 32-bit
platforms. A long shot, I know, but you'll never know.

--
Patrick.
--
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 1/4] b2c2: Add option to skip the first 6 pid filters

2015-06-01 Thread Patrick Boettcher
Hi all,

On Mon, 01 Jun 2015 09:08:03 +0100 Jemma Denson jden...@gmail.com
wrote:
 Yes, that might work, I hadn't though of just swapping them around - 
 thanks. It would however assume that the 0x PAT feed is requested 
 early on enough that it always sits within the bank of 32 and nothing 
 else is too bothered by the odd out of order packet.
 
 The only concern I have got is if there is any other oddness in the 
 first 6 - this card is the only flexcop based card with dvb-s2 and there 
 is a lack of stream with high bitrate transponders (approx. 45Mbps), 
 which we think might due to the hardware pid filter. The card apparently 
 works fine under the windows driver so it's a case of trying to work out 
 what that might be doing differently. It's quite speculative at the 
 moment but I'm hoping this patch might help with that and I'm waiting 
 for some feedback on that - I'm stuck with 28.2E which doesn't hold 
 anything interesting.
 
 At the moment it doesn't really matter too much having only 32 filters 
 rather than the full 38 - it does switch to full-TS once it runs out of 
 hardware filters, and the only issue with full-TS is that the flexcop 
 can't pass a TS with more than 45Mbps (but they aren't working at the 
 moment anyway)

I agree, if the 6 PID-filters are not working they should be used. The
worth is receiving PSI of a transponder/channel which is in fact from
the one previously tuned.

I think it is better to leave it as you suggested.

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


Re: [PATCH 3/4] cx24120: Take control of b2c2 receive stream

2015-05-26 Thread Patrick Boettcher
Hi Jemma,

On Fri, 22 May 2015 21:28:27 +0100 Jemma Denson jden...@gmail.com
wrote:

 Now that b2c2 has an option to allow us to do so, turn off the
 flexcop receive stream when we turn off mpeg output whilst tuning.

Does this not fix (and your '[PATCH 2/4]') the problem of receiving
PAT from the previously tuned transport-stream?

Then patch 1 and 4 should not be necessary, should they?!

--
Patrick.



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


[PULL v3] for 4.2: add support for cx24120/Technisat SkyStar S2

2015-05-20 Thread Patrick Boettcher
Hi Mauro,

This is an updated version (v3) of the pull-request for integrating the
cx24120-driver. 

Jemma (and partially me) addressed all strict-conding-style-issues and
fixed several things regarding signal-stats and demod-issues + some code
cleaning in general. 

Yesterday night Jemma implemented everything related to the UNC and
BER-stuff. I also integrated your smatch-patches on my branch.

In this mail you'll also find the complete patch, please feel free to
review it.

best regards,
--
Patrick.
 


The following changes since commit e183201b9e917daf2530b637b2f34f1d5afb934d:

  [media] uvcvideo: add support for VIDIOC_QUERY_EXT_CTRL (2015-04-10 10:29:27 
-0300)

are available in the git repository at:

  https://github.com/pboettch/linux.git cx24120-v2

for you to fetch changes up to ee97338cf3522c840256ece3ea5a6f29675f7604:

  cx24120: fix minor checkpatch-error (2015-05-20 09:58:49 +0200)


Jemma Denson (26):
  [media] Add support for TechniSat Skystar S2
  cx24120: Fix minor style typo in Kconfig
  cx24120: Move clock set to read_status
  cx24120: Add missing command to cx24120_check_cmd
  cx24120: Fix hexdump length in writeregs
  cx24120: Rework vco function to remove xxyyzz variable
  cx24120: Add DVBv5 signal strength stats
  cx24120: Enable DVBv5 signal strength stats
  cx24120: Remove additional calls to read_status
  cx24120: Return DVBv3 signal strength from cache
  cx24120: Tidy up signal strength code
  cx24120: Improve cooked signal strength value
  cx24120: More coding style fixes
  cx24120: Fix disecq_send_burst command
  cx24120: Move CNR to DVBv5 stats
  cx24120: Tidy up calls to dev_dbg
  cx24120: Remove unneccesary assignments in cx24120_init
  cx24120: Tidy cx24120_init
  cx24120: More tidying in cx24120_init
  b2c2: Reset no_base_addr on skystarS2 attach failure
  cx24120: Complete modfec_table
  cx24120: Add in dvbv5 stats for bit error rate
  cx24120: Convert read_ber to retreive from cache
  cx24120: Convert ucblocks to dvbv5 stats
  cx24120: Check for lock before updating BER  UCB
  cx24120: Update comment  fix typo

Mauro Carvalho Chehab (3):
  cx24120: don't initialize a var that won't be used
  cx24120: declare cx24120_init() as static
  cx24120: constify static data

Patrick Boettcher (6):
  [media] cx24120: minor checkpatch fixes
  cx24120: i2c-max-write-size is now configurable
  [media] MAINTAINERS: add cx24120-maintainer
  cx24120: fix codingstyle issue first round
  cx24120: fix strict checkpatch-errors
  cx24120: fix minor checkpatch-error

 MAINTAINERS  |9 +
 drivers/media/common/b2c2/Kconfig|1 +
 drivers/media/common/b2c2/flexcop-fe-tuner.c |   53 +-
 drivers/media/common/b2c2/flexcop-misc.c |1 +
 drivers/media/common/b2c2/flexcop-reg.h  |1 +
 drivers/media/dvb-frontends/Kconfig  |7 +
 drivers/media/dvb-frontends/Makefile |1 +
 drivers/media/dvb-frontends/cx24120.c| 1592 ++
 drivers/media/dvb-frontends/cx24120.h|   58 +
 9 files changed, 1716 insertions(+), 7 deletions(-)
 create mode 100644 drivers/media/dvb-frontends/cx24120.c
 create mode 100644 drivers/media/dvb-frontends/cx24120.h

diff --git a/MAINTAINERS b/MAINTAINERS
index 30e7e38..cdd4f23 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -2848,6 +2848,15 @@ S:   Maintained
 F: drivers/media/common/cx2341x*
 F: include/media/cx2341x*
 
+CX24120 MEDIA DRIVER
+M: Jemma Denson jden...@gmail.com
+M: Patrick Boettcher patrick.boettc...@posteo.de
+L: linux-media@vger.kernel.org
+W: http://linuxtv.org/
+Q: http://patchwork.linuxtv.org/project/linux-media/list/
+S: Maintained
+F: drivers/media/dvb-frontends/cx24120*
+
 CX88 VIDEO4LINUX DRIVER
 M: Mauro Carvalho Chehab mche...@osg.samsung.com
 L: linux-media@vger.kernel.org
diff --git a/drivers/media/common/b2c2/Kconfig 
b/drivers/media/common/b2c2/Kconfig
index a8c6cdf..e593638 100644
--- a/drivers/media/common/b2c2/Kconfig
+++ b/drivers/media/common/b2c2/Kconfig
@@ -14,6 +14,7 @@ config DVB_B2C2_FLEXCOP
select DVB_S5H1420 if MEDIA_SUBDRV_AUTOSELECT
select DVB_TUNER_ITD1000 if MEDIA_SUBDRV_AUTOSELECT
select DVB_ISL6421 if MEDIA_SUBDRV_AUTOSELECT
+   select DVB_CX24120 if MEDIA_SUBDRV_AUTOSELECT
select DVB_CX24123 if MEDIA_SUBDRV_AUTOSELECT
select MEDIA_TUNER_SIMPLE if MEDIA_SUBDRV_AUTOSELECT
select DVB_TUNER_CX24113 if MEDIA_SUBDRV_AUTOSELECT
diff --git a/drivers/media/common/b2c2/flexcop-fe-tuner.c 
b/drivers/media/common/b2c2/flexcop-fe-tuner.c
index 7e14e90..2426062 100644
--- a/drivers/media/common/b2c2/flexcop-fe-tuner.c
+++ b/drivers/media/common/b2c2/flexcop-fe-tuner.c
@@ -12,6 +12,7 @@
 #include cx24113.h
 #include cx24123.h

Re: [PULL v3] for 4.2: add support for cx24120/Technisat SkyStar S2

2015-05-20 Thread Patrick Boettcher
On Wed, 20 May 2015 09:07:27 -0300 Mauro Carvalho Chehab
mche...@osg.samsung.com wrote:

 Hi Patrick/Jemma,
 
 Em Wed, 20 May 2015 12:46:45 +0100
 Jemma Denson jden...@gmail.com escreveu:
 
  On 20/05/15 09:05, Patrick Boettcher wrote:
   Hi Mauro,
  
   This is an updated version (v3) of the pull-request for integrating the
   cx24120-driver.
  
   Jemma (and partially me) addressed all strict-conding-style-issues and
   fixed several things regarding signal-stats and demod-issues + some code
   cleaning in general.
  
   Yesterday night Jemma implemented everything related to the UNC and
   BER-stuff. I also integrated your smatch-patches on my branch.
  
   In this mail you'll also find the complete patch, please feel free to
   review it.
 
 Thank you! It is now in good shape on my eyes. Patches merged. 
 The only minor issue is that I had to fold two patches to avoid
 compilation breakage in the middle of the patch series, but I
 solved this myself.

Thank you for your help (and especially to Jemma).

(one big thing crossed off my eternal TODO-list.)

best regards,
--
Patrick.
--
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: [PULL] For 4.2 (or even 4.1?) add support for cx24120/Technisat SkyStar S2

2015-05-19 Thread Patrick Boettcher
On Tue, 19 May 2015 12:25:19 +0100 Jemma Denson jden...@gmail.com
wrote:

 On 19/05/15 11:57, Mauro Carvalho Chehab wrote:
 
  The only thing left now is moving UCB  BER over to DVBv5 stats - we
  haven't got anything close to any specs for this demod so I'm struggling
  to work out how to handle the counter increment.
  It's not helped by my signal not being marginal enough to see any errors
  anyway!
 
  What's the best course of action here - either leave those two out
  entirely or fudge something to get the numbers to about the right
  magnitude and worry about making it more accurate at a later date?
  I prefer to have something, even not 100% acurate, reported via DVBv5.
 
  Regards,
  Mauro
 
 I think I've managed to work it out now :) It's set to use a 16 bit BER 
 window and what I did manage to see suggests that the window is based on 
 packets. So it's just a case of calculating things from there.
 
 I implemented something for BER lastnight but it does need a little 
 tidying. UCB should be much more straightforward. I should be able to 
 find time during the week, or if not this weekend. I'll send the patches 
 through to Patrick to add to his tree and then we can have a v3 pull 
 request.

Great job. Let's do it so. I will check with Mauro about his patches.

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


Re: [PATCH 1/3] cx24120: don't initialize a var that won't be used

2015-05-19 Thread Patrick Boettcher
Hi Mauro, 

On Tue, 19 May 2015 08:23:36 -0300 Mauro Carvalho Chehab
mche...@osg.samsung.com wrote:

 As reported by smatch:
 drivers/media/dvb-frontends/cx24120.c: In function 'cx24120_message_send':
 drivers/media/dvb-frontends/cx24120.c:368:6: warning: variable 'ret' set but 
 not used [-Wunused-but-set-variable]
   int ret, ficus;
   ^
 
 The values written by cx24120 are never checked. So, remove the
 check here too. That's said, the best would be to do the reverse,
 but globally: to properly handle the error codes.
 
 Signed-off-by: Mauro Carvalho Chehab mche...@osg.samsung.com

Woudl you mind me integrating your patches on my tree which I then
will ask you to pull?

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


[PULL v2] for 4.2: add support for cx24120/Technisat SkyStar S2

2015-05-18 Thread Patrick Boettcher
Hi Mauro,

This is an updated version of the pull-request for integrating the
cx24120-driver. 

Jemma (and partially me) addressed all strict-conding-style-issues and
fixed several things regarding signal-stats and demod-issues + some code
cleaning in general.

The only thing missing is the UNC/BER-support in DVBv5-stats. As Jemma
pointed out, this is not trivial with the little information and
equipment available. Not sure when this issue can be addressed - if
ever.

In this mail you'll also find the complete patch, please feel free to
review it.

best regards,
--
Patrick.



The following changes since commit 0fae1997f09796aca8ada5edc028aef587f6716c:

  [media] dib0700: avoid the risk of forgetting to add the adapter's size 
(2015-05-14 19:31:34 -0300)

are available in the git repository at:

  https://github.com/pboettch/linux.git cx24120-v2

for you to fetch changes up to e2faa4d8b0b4d1efd68e9ea300ce47b3172a50cc:

  cx24120: Complete modfec_table (2015-05-18 12:08:09 +0200)


Jemma Denson (21):
  [media] Add support for TechniSat Skystar S2
  cx24120: Fix minor style typo in Kconfig
  cx24120: Move clock set to read_status
  cx24120: Add missing command to cx24120_check_cmd
  cx24120: Fix hexdump length in writeregs
  cx24120: Rework vco function to remove xxyyzz variable
  cx24120: Add DVBv5 signal strength stats
  cx24120: Enable DVBv5 signal strength stats
  cx24120: Remove additional calls to read_status
  cx24120: Return DVBv3 signal strength from cache
  cx24120: Tidy up signal strength code
  cx24120: Improve cooked signal strength value
  cx24120: More coding style fixes
  cx24120: Fix disecq_send_burst command
  cx24120: Move CNR to DVBv5 stats
  cx24120: Tidy up calls to dev_dbg
  cx24120: Remove unneccesary assignments in cx24120_init
  cx24120: Tidy cx24120_init
  cx24120: More tidying in cx24120_init
  b2c2: Reset no_base_addr on skystarS2 attach failure
  cx24120: Complete modfec_table

Patrick Boettcher (5):
  [media] cx24120: minor checkpatch fixes
  cx24120: i2c-max-write-size is now configurable
  [media] MAINTAINERS: add cx24120-maintainer
  cx24120: fix codingstyle issue first round
  cx24120: fix strict checkpatch-errors

 MAINTAINERS  |9 +
 drivers/media/common/b2c2/Kconfig|1 +
 drivers/media/common/b2c2/flexcop-fe-tuner.c |   53 +-
 drivers/media/common/b2c2/flexcop-misc.c |1 +
 drivers/media/common/b2c2/flexcop-reg.h  |1 +
 drivers/media/dvb-frontends/Kconfig  |7 +
 drivers/media/dvb-frontends/Makefile |1 +
 drivers/media/dvb-frontends/cx24120.c| 1489 ++
 drivers/media/dvb-frontends/cx24120.h|   58 +
 9 files changed, 1613 insertions(+), 7 deletions(-)
 create mode 100644 drivers/media/dvb-frontends/cx24120.c
 create mode 100644 drivers/media/dvb-frontends/cx24120.h

diff --git a/MAINTAINERS b/MAINTAINERS
index fafa912..5579b55 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -2873,6 +2873,15 @@ S:   Maintained
 F: drivers/media/common/cx2341x*
 F: include/media/cx2341x*
 
+CX24120 MEDIA DRIVER
+M: Jemma Denson jden...@gmail.com
+M: Patrick Boettcher patrick.boettc...@posteo.de
+L: linux-media@vger.kernel.org
+W: http://linuxtv.org/
+Q: http://patchwork.linuxtv.org/project/linux-media/list/
+S: Maintained
+F: drivers/media/dvb-frontends/cx24120*
+
 CX88 VIDEO4LINUX DRIVER
 M: Mauro Carvalho Chehab mche...@osg.samsung.com
 L: linux-media@vger.kernel.org
diff --git a/drivers/media/common/b2c2/Kconfig 
b/drivers/media/common/b2c2/Kconfig
index a8c6cdf..e593638 100644
--- a/drivers/media/common/b2c2/Kconfig
+++ b/drivers/media/common/b2c2/Kconfig
@@ -14,6 +14,7 @@ config DVB_B2C2_FLEXCOP
select DVB_S5H1420 if MEDIA_SUBDRV_AUTOSELECT
select DVB_TUNER_ITD1000 if MEDIA_SUBDRV_AUTOSELECT
select DVB_ISL6421 if MEDIA_SUBDRV_AUTOSELECT
+   select DVB_CX24120 if MEDIA_SUBDRV_AUTOSELECT
select DVB_CX24123 if MEDIA_SUBDRV_AUTOSELECT
select MEDIA_TUNER_SIMPLE if MEDIA_SUBDRV_AUTOSELECT
select DVB_TUNER_CX24113 if MEDIA_SUBDRV_AUTOSELECT
diff --git a/drivers/media/common/b2c2/flexcop-fe-tuner.c 
b/drivers/media/common/b2c2/flexcop-fe-tuner.c
index 7e14e90..2426062 100644
--- a/drivers/media/common/b2c2/flexcop-fe-tuner.c
+++ b/drivers/media/common/b2c2/flexcop-fe-tuner.c
@@ -12,6 +12,7 @@
 #include cx24113.h
 #include cx24123.h
 #include isl6421.h
+#include cx24120.h
 #include mt352.h
 #include bcm3510.h
 #include nxt200x.h
@@ -26,6 +27,16 @@
 #define FE_SUPPORTED(fe) (defined(CONFIG_DVB_##fe) || \
(defined(CONFIG_DVB_##fe##_MODULE)  defined(MODULE)))
 
+#if FE_SUPPORTED(BCM3510) || FE_SUPPORTED(CX24120)
+static int flexcop_fe_request_firmware(struct dvb_frontend *fe,
+   const struct

Re: [PULL] For 4.2 (or even 4.1?) add support for cx24120/Technisat SkyStar S2

2015-05-15 Thread Patrick Boettcher
Hi Mauro,

On Thu, 14 May 2015 18:40:40 -0300 Mauro Carvalho Chehab
mche...@osg.samsung.com wrote:

 Em Wed, 29 Apr 2015 08:55:26 -0300
 Mauro Carvalho Chehab mche...@osg.samsung.com escreveu:
 
  Em Wed, 29 Apr 2015 13:35:01 +0200
  Patrick Boettcher patrick.boettc...@posteo.de escreveu:
  
   Hi Mauro,
   
   On Mon, 27 Apr 2015 21:40:22 -0300 Mauro Carvalho Chehab
   mche...@osg.samsung.com wrote:
 Could we send an additional patch for coding-style or would you prefer
 a new patch which has everything inside? This would maintain the
 author-attribution of the initial commit.

An additional patch is fine.
   
   I fixed the files cx24120.[ch] in a --strict manner. 
  
  Thanks
  
   Do you want me to
   send each of these patches to the list? They are not really
   interesting. But if it might help to review for any obvious mistakes...
  
  Yes, please send to ML.
 
 Ping.

Thanks for the ping.

 
 I'll be marking the original patch at patchwork:
   http://patchwork.linuxtv.org/patch/29162/
 
 As changes requested.
 
 Please submit the new version of the pull request when ready.

Of course. Jemma and me (mainly Jemma) are progressing and might be
able to resubmit everything this weekend.

regards,
--
Patrick.

--
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: [PULL] For 4.2 (or even 4.1?) add support for cx24120/Technisat SkyStar S2

2015-04-29 Thread Patrick Boettcher
Hi Mauro,

On Mon, 27 Apr 2015 21:40:22 -0300 Mauro Carvalho Chehab
mche...@osg.samsung.com wrote:
  Could we send an additional patch for coding-style or would you prefer
  a new patch which has everything inside? This would maintain the
  author-attribution of the initial commit.
 
 An additional patch is fine.

I fixed the files cx24120.[ch] in a --strict manner. Do you want me to
send each of these patches to the list? They are not really
interesting. But if it might help to review for any obvious mistakes...

I rebased my tree on the media-tree of this morning.

I checked the fe_stat-stuff and I saw that you need to keep the old
unc, ber and snr functions anyway.

I doubt that the cx24120 in its current state reports anything useful
for statistical uses. Do you think there is an added value adding
it to a driver which is very simple in this regards?

Regarding the wait for channel-lock I think it could be written
differently using a state and checking in the get_status-function
whether it is locked for the first time. This will need testing. I
haven't done it yet.

regards,
--
Patrick.

--
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: [PULL] For 4.2 (or even 4.1?) add support for cx24120/Technisat SkyStar S2

2015-04-27 Thread Patrick Boettcher
Thank you for your review Mauro.

In total there are about 3-4 (it's a guess) users of this driver and
this, written-once read-never, code is for a hardware which is very
unlikely to be ever reused again ever. Sometimes I regret that there is
no carpet in OpenSource where you could hide the dirt under ;-).

This driver has been reverse-engineered from a binary-only release - so
looking for logic is not really useful - there will be sections which
are not understandable or would require a certain amount of
investigation and reverse-engineering (I'm thinking of the UNC and BER
reporting, maybe SNR too).

Tough not sure if it is worth the time. Anyone there to convince me?

I'm really surprised that checkpatch.pl hasn't seen any of the
coding-style problems you pointed out, except the printk-usage. I ran
it on the .c-file and not on the patch, is that the problem?

Could we send an additional patch for coding-style or would you prefer
a new patch which has everything inside? This would maintain the
author-attribution of the initial commit.

Sorry for the top-posting.

best regards,
--
Patrick.


On Mon, 27 Apr 2015 17:16:28 -0300
Mauro Carvalho Chehab mche...@osg.samsung.com wrote:

 Em Mon, 20 Apr 2015 09:27:20 +0200
 Patrick Boettcher patrick.boettc...@posteo.de escreveu:
 
  Hi Mauro,
  
  Would you please pull the following two patches for finally
  mainlining the Technisat SkyStar S2 (and its frontend cx24120).
  
  Ideally for 4.1, but I assume it is too late. So for 4.2.
 
 Hi Patrick,
 
 It was too late for 4.1. We typically close the merge for the next
 Kernel one week before the open of a merge window.
 
  Please also tell whether a pull-request is OK for you or whether you
  prefer patches.
 
 Pull requests work best for me, as it warrants that the patches
 will be applied in order. Also, I priorize pull requests over usual
 patches.
 
 However, if you send a pull request, don't forget to also post the
 patch series, as it helps people to review and comment about the code.
 
  I'm based on the current media-tree's master. But can rebase myself
  on anything you wish for your convenience.
 
 That's fine. You can base on it or on any tag at the Linus tree.
 
 My script will actually convert the pull request into a quilt series
 of patches, getting only the patches between the range specified at
 the pull request e-mail.
 
 It is slow, however, if the origin branch is not here, as it needs to
 download a larger amount of objects, and then use a somewhat complex
 heuristics to detect the origin branch. 
 
 That's why the best is to either base on media-tree master or on a 
 Linus tag.
 
  
  Thanks,
  --
  Patrick.
  
  
  The following changes since commit
  e183201b9e917daf2530b637b2f34f1d5afb934d:
  
[media] uvcvideo: add support for VIDIOC_QUERY_EXT_CTRL
  (2015-04-10 10:29:27 -0300)
  
  are available in the git repository at:
  
https://github.com/pboettch/linux.git cx24120-v2
  
  for you to fetch changes up to
  3a6500da369a632c9fd405b1191dcbf5e5e07504:
  
[media] cx24120: minor checkpatch fixes (2015-04-17 11:11:40
  +0200)
 
 As complained by checkpatch:
 
 WARNING: added, moved or deleted file(s), does MAINTAINERS need
 updating? #195: 
 new file mode 100644
 
 Please add an entry at MAINTAINERS for the one that will be
 maintaining it.
 
 Other comments follow.
 
  From c6c7a0454adacfda1ecbd62ae46b23d8af857539 Mon Sep 17 00:00:00
  2001 From: Jemma Denson jden...@gmail.com
  Date: Tue, 14 Apr 2015 14:04:50 +0200
  Subject: [media] Add support for TechniSat Skystar S2
  To: Linux Media Mailing List linux-media@vger.kernel.org
  Cc: Mauro Carvalho Chehab mche...@infradead.org
  
  This patch adds support for the Technisat Skystar S2 - this
  has been tried before but the cx24120 driver was a bit out of shape
  and it didn't got any further:
  
  https://patchwork.linuxtv.org/patch/10575/
  
  It is an old card, but currently being sold off for next to nothing,
  so it's proving quite popular of late. Noticing it's quite similar
  to the cx24116 and cx24117 I've rewritten the driver in a similar
  way.
  
  There were a few registers and commands from those drivers
  missing from this one I've tested out and found they do something so
  they've been added in to speed up tuning and to make get_frontend
  return something useful.
  
  Signed-off-by: Jemma Denson jden...@gmail.com
  Signed-off-by: Patrick.Boettcher patrick.boettc...@posteo.de
  ---
   drivers/media/common/b2c2/Kconfig|1 +
   drivers/media/common/b2c2/flexcop-fe-tuner.c |   51 +-
   drivers/media/common/b2c2/flexcop-misc.c |1 +
   drivers/media/common/b2c2/flexcop-reg.h  |1 +
   drivers/media/dvb-frontends/Kconfig  |7 +
   drivers/media/dvb-frontends/Makefile |1 +
   drivers/media/dvb-frontends/cx24120.c| 1577
  ++
  drivers/media/dvb-frontends/cx24120.h|   56 + 8 files
  changed, 1688 insertions(+), 7 deletions(-) create

Re: [media-workshop] [DRAFT 1] Linux Media Summit report - March, 26 2015 - San Jose - CA - USA

2015-04-23 Thread Patrick Boettcher
Hi Mauro,

On Thu, 23 Apr 2015 07:40:46 -0300 Mauro Carvalho Chehab
mche...@osg.samsung.com wrote:
  What about demod-diversity: demods of some manufacturers can be
  used to combine their demodulated symbols and, due to their
  different antennas and RF-paths, improve the overall reception
  quality.
  
  If we ever have someone contributing in this area with
  hardware-drivers, it would be nice to have the user-space possible
  to select demod-combinations. It should be possible to add and
  remove a demod to a diversity-chain when and when not being tuned
  to a channel.
 
 It makes sense to map demod diversity via the media controller.
 
 Not sure what would be the best way to map it though, as I don't have
 a clear understanding about how the hardware pipelines are set for
 demod diversity.
 
 The way the media controller currently is is that it maps only the
 data flow. There are discussions about how the control flow should
 happen.
 
 The data flow for a normal demod is:
 
   IF (or baseband) --- [demod] --- MPEG-TS
 
 
 From dib0700 demod drivers, I remember that several of the demods have
 a concept of a slave demod. Are those full demods that can get an
 IF/baseband input and produce a MPEG-TS output, or are those just
 IP blocks that have the IF/baseband input but doesn't produce an
 MPEG-TS output, but, instead, sends some sort of data into the master
 demod?
 
 In other words, would the dataflow be something like
 
  IF   TS
   [tuner] --- [master demod] -[  ]
 | IF   TS   [ combiner ] --- [demux]
 | [slave demod]  -[  ]
 
 or:
  IF  TS
   [tuner] --- [master demod] --- [demux]
 | IF ^
 || (what sort of data?)
 | [slave demod] |
 
 Or is it something else?

Let's define a demodulation object:

+---+
|RF tuner -- IF|baseband -- demod -- FEC-decoder |
+---+

RF-tuner: RF downconverter (to a low or zero-IF)
IF|baseband: ADC and digital filters
demod: synchonization and symbol extraction
FEC-decoder: viterbi/ldpc/turbo-code forward error correction

Let's call this object a frontend.

Now imagine a board which has 4 frontends:

 high-speed-data-bus
-
  ||||
 FE3  FE2  FE1  FE0


To create a diversity-chain, for simplicity, we can say we connect at
least 2 frontends in any order. Both frontends are tuned to the same
physical channel and then a combiner will combine symbols decoded at
demod-stage.

Any FE can be connected with any FE in any order. Per board different
standards can be demodulated at the same time. For example: FE3 and FE2
are doing DVB-T and FE1 and FE0 DVB-T2 .

--
Patrick.
--
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: [DRAFT 1] Linux Media Summit report - March, 26 2015 - San Jose - CA - USA

2015-04-23 Thread Patrick Boettcher
Hi Mauro,

I could not participate at your Summit, but may have an input to the
media-controller in DVB - see below.


On Wed, 22 Apr 2015 15:31:46 -0300 Mauro Carvalho Chehab
mche...@osg.samsung.com wrote:

 This is the first draft for the Linux Media Summit Report.
 
 Please note that the items 3 to 5 are not in good shape. In special,
 nobody took Etherpad notes on item 4.
 
 Please review. I'll publish a second (final?) draft after having some
 feedback.
 
 Regards,
 Mauro
 
 -
 
 Linux Media Summit - March, 26 2015 - San Jose - CA - USA
  
  
 Attendees:
 
 
 Angelos Manousaridis aman...@gmail.com
 Bob Moragues bob.morag...@lge.com
 Chris Kohn
 Guennadi Liakhovetski g.liakhovet...@gmx.de
 Hans Verkuil hverk...@xs4all.nl
 Hyun Kwon
 Karthik Poduval karthik.podu...@gmail.com
 Laurent Pinchart laurent.pinch...@ideasonboard.com
 Mauro Carvalho Chehab mche...@osg.samsung.com
 Michal Lebik
 Mohammed CHERIFI mcher...@cisco.com
 Rafael Chehab chehabraf...@gmail.com
 Ron Birkett
 Schuyler Patton
 Shuah Khan shua...@osg.samsung.com
 
 1) Media Controller support for DVB
 Mauro presented a set of slides (add link) showing how the DVB
 pipelines look like and underlined that several topics needs to be
 addressed by the Media controller:
 
 a) dynamic creation/removal of pipelines
 b) change media_entity_pipeline_start to also define the final entity
 c) how to setup pipelines that also envolve audio and DRM?
 d) how to lock the media controller pipeline between enabling a
 pipeline and starting it, in 
 
 How to do complex pipelines in DVB?
  
 - The DVB demux can filter MPEG-TS traffic (either in hardware or in
 software) and can send multiplexed TS to the dvr node, elementary
 streams to the demux node and can create network interfaces for
 elementary streams (ES) via the net node.
 - a given set of elementary streams can go to one of those three
 options only, or it can be sent directly to a GPU and/or an ALSA
 pipeline.
 - there is support for hardware PID filtering at the Kernel, but no
 support (yet) for a real hw demuxer that splits the MPEG TS into
 separate DMA MPEG-TS and/or ES streams.
 - frontend device node is to be attached to the demod entity and it
 will control the demod, the tuner and a possible LNA via the active
 Media Controller links.
 - dvr/net/demux device nodes are attached to the demux entity.
 - the net interfaces are not (yet) represented via MC: we need the
 ability to remove entities dynamically for that, and we are not
 really sure if we want this at all. So, it as agreed to wait for
 support for removing entities to arrive, then this need can be
 discussed again.
 - For now we can safely assume that there is only one Satellite
 Equipment Control (SEC) in each active data path that goes through a
 tuner/demod. So each frontend will control just one SEC. Should we
 encounter really complex scenarios, then we should consider having
 device nodes for SEC entities.

What about demod-diversity: demods of some manufacturers can be used to
combine their demodulated symbols and, due to their different antennas
and RF-paths, improve the overall reception quality.

If we ever have someone contributing in this area with hardware-drivers,
it would be nice to have the user-space possible to select
demod-combinations. It should be possible to add and remove a demod
to a diversity-chain when and when not being tuned to a channel.

regards,
--
--
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] Add support for TechniSat Skystar S2

2015-04-20 Thread Patrick Boettcher
Hi Johannes,

On Mon, 20 Apr 2015 10:20:47 +0200 Johannes Stezenbach j...@linuxtv.org
wrote:

 (add Mauro)
 
 On Sun, Apr 19, 2015 at 11:19:43PM +0200, Patrick Boettcher wrote:
  On Fri, 17 Apr 2015 11:06:30 +0200
  Patrick Boettcher patrick.boettc...@posteo.de wrote:
   http://git.linuxtv.org/cgit.cgi/pb/media_tree.git/ cx24120-v2
  
  Jannis pointed out, that my repository on linuxtv.org was not
  fetchable...
  
  I put one onto github, this should work:
  
  https://github.com/pboettch/linux.git cx24120-v2
  
  It is the same commits as I was pushing to the linuxtv.org .
 
 Patrick, can you point out why your repository is
 not fetchable?  Any error messages?

In the meantime I recreated it from scratch (using git-menu I did
delete - clone).

Before it was giving error like this:

remote: error: Could not read 28df73703e738d8ae7a958350f74b08b2e9fe9ed
remote: fatal: Failed to traverse parents of commit
6b9d03db027c532e509ad9064dd767f621b6e69a

This seems to me a problem of a git push not uploading all the missing
commits between my local repo's commit-base and the remote one.

My repo was very old (2010). I assume none has ever cloned from it and
the media_tree has itself been push forced several times.

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


[PULL] For 4.2 (or even 4.1?) add support for cx24120/Technisat SkyStar S2

2015-04-20 Thread Patrick Boettcher
Hi Mauro,

Would you please pull the following two patches for finally
mainlining the Technisat SkyStar S2 (and its frontend cx24120).

Ideally for 4.1, but I assume it is too late. So for 4.2.

Please also tell whether a pull-request is OK for you or whether you
prefer patches.

I'm based on the current media-tree's master. But can rebase myself
on anything you wish for your convenience.

Thanks,
--
Patrick.


The following changes since commit e183201b9e917daf2530b637b2f34f1d5afb934d:

  [media] uvcvideo: add support for VIDIOC_QUERY_EXT_CTRL (2015-04-10 10:29:27 
-0300)

are available in the git repository at:

  https://github.com/pboettch/linux.git cx24120-v2

for you to fetch changes up to 3a6500da369a632c9fd405b1191dcbf5e5e07504:

  [media] cx24120: minor checkpatch fixes (2015-04-17 11:11:40 +0200)


Jemma Denson (1):
  [media] Add support for TechniSat Skystar S2

Patrick Boettcher (1):
  [media] cx24120: minor checkpatch fixes

 drivers/media/common/b2c2/Kconfig|1 +
 drivers/media/common/b2c2/flexcop-fe-tuner.c |   51 +-
 drivers/media/common/b2c2/flexcop-misc.c |1 +
 drivers/media/common/b2c2/flexcop-reg.h  |1 +
 drivers/media/dvb-frontends/Kconfig  |7 +
 drivers/media/dvb-frontends/Makefile |1 +
 drivers/media/dvb-frontends/cx24120.c| 1574 ++
 drivers/media/dvb-frontends/cx24120.h|   56 +
 8 files changed, 1685 insertions(+), 7 deletions(-)
 create mode 100644 drivers/media/dvb-frontends/cx24120.c
 create mode 100644 drivers/media/dvb-frontends/cx24120.h
--
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] Add support for TechniSat Skystar S2

2015-04-20 Thread Patrick Boettcher
Hi Jemma,

On Fri, 17 Apr 2015 12:47:50 +0100 Jemma Denson jden...@gmail.com
wrote:

  To prepare an integration into 4.2 (or at least 4.3) I suggest
  using my media_tree on linuxtv.org .
 
  http://git.linuxtv.org/cgit.cgi/pb/media_tree.git/ cx24120-v2
 
  I added a checkpatch-patch on top of it. If you can, please base any
  future work of yours on this tree until is has been integrated.
 Will do! If I can work out the SNR scale I have got plans to have
 this work in the new way of doing this. Did you ever manage to obtain
 a datasheet for this demod? I have tried contacting NXP but haven't 
 received anything back.

What can I say: it works. I'm just using it as a DVB-S2 receiver for my
vdr-installation and I can successfully zap and vdr is doing its
background/epg scanning.

I consider it OK for inclusion. Any fixes, if any, can be later on.

regards,
--
Patrick.


--
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] Add support for TechniSat Skystar S2

2015-04-19 Thread Patrick Boettcher
Hi,

On Fri, 17 Apr 2015 11:06:30 +0200
Patrick Boettcher patrick.boettc...@posteo.de wrote:
 http://git.linuxtv.org/cgit.cgi/pb/media_tree.git/ cx24120-v2

Jannis pointed out, that my repository on linuxtv.org was not
fetchable...

I put one onto github, this should work:

https://github.com/pboettch/linux.git cx24120-v2

It is the same commits as I was pushing to the linuxtv.org .

regards,
--
Patrick.
--
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] Add support for TechniSat Skystar S2

2015-04-17 Thread Patrick Boettcher
Hi Jemma,

Thanks for taking this one. I had this on my list for years.

On Mon, 13 Apr 2015 07:32:15 +0100 Jemma Denson jden...@gmail.com
wrote:

 Oh, I was doing this the wrong way then. I did have some preamble to
 this but it seems to have been stripped.
 
 Anyway, this patch adds support for the Technisat Skystar S2 - this
 has been tried before but the cx24120 driver was a bit out of shape
 and it didn't got any further:
 https://patchwork.linuxtv.org/patch/10575/
 
 It is an old card, but currently being sold off for next to nothing,
 so it's proving quite popular of late.
 Noticing it's quite similar to the cx24116 and cx24117 I've rewritten
 the driver in a similar way. There were a few registers and commands
 from those drivers missing from this one I've tested out and found
 they do something so they've been added in to speed up tuning and to
 make get_frontend return something useful.

If time allows it I will try to install and test your driver this
weekend or, at the latest, next weekend.

 I've only got access to 28.2E, but everything I've tried seems to work
 OK, on both the v3 and v5 APIs. Assuming I've read the APIs and some
 of the modern drivers OK it should be doing things in the reasonably
 modern way, but if anything else needs doing let me know.

I have my Skystar S2 pointed to 19.2E.

To prepare an integration into 4.2 (or at least 4.3) I suggest using my
media_tree on linuxtv.org .

http://git.linuxtv.org/cgit.cgi/pb/media_tree.git/ cx24120-v2

I added a checkpatch-patch on top of it. If you can, please base any
future work of yours on this tree until is has been integrated.

Please also tell me, whether you are OK with the comment I added around
your commit or not.

Thanks,
--
Patrick.
--
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: technisat-usb2: i2c-error

2014-10-11 Thread Patrick Boettcher
On Fri, 10 Oct 2014 12:09:12 +0200
JPT j-...@gmx.net wrote:

 Hi Patrick,
 
 Am 09.10.2014 um 17:26 schrieb Patrick Boettcher:
  Hi Jan,
  
  What exactly do the i2c-errors mean? 
  
  I can't tell you exactly what happens in the device, but I can tell
  you that I have the same problem with my device on my PC sometimes. 
  
  In addition to this I2c-failures from time to time the box is quite
  sensitive regarding: repowering, replugging and host-rebooting.
  This is a USB-device-firmware problem which makes the device crash
  and all subsequent USB-transfers are failed. Reloading the module
  or replugging the device will make it work again.
 
 That's bad news. Could you please add this info on the Wikipage?
 http://www.linuxtv.org/wiki/index.php/Technisat_SkyStar_USB_HD
 
  How many days without interruption did you use the device?
 
 Well, this was about 2 days and 1.5 ;) recordings

Matches my experience.

  I was following quietly you're discussion with Antti. Has someone
  taken care of the your changes regarding the transfer-size?
 
 No. Since I don't understand anything about what I did ;)

Could you resent the changes figured out by you and Antti ? (ideally in
a form of a patch).

 And I don't know the process of officially working on the kernel...
 (Just wondered if I will ever learn that much about kernel
 programming;)

There you can be helped: http://eudyptula-challenge.org/

  I think it should included.
 
 Then someone with more insight should change the buffers and create a
 patch. o.O

Create the patch, I will try it with my box and when it's ok after some
time we'll get it in.

regards,
-- 
Patrick.
--
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: technisat-usb2: i2c-error

2014-10-09 Thread Patrick Boettcher
Hi Jan,

On Tue, 07 Oct 2014 19:27:07 +0200 JPT j-...@gmx.net wrote:
 01:14:52 VDR fails to start because there is no recording device.
 
 I was able to get things running by unloading the modules and loading
 them again. After that I started VDR.
 
 What exactly do the i2c-errors mean? Find attached a
 grep i2c-error syslog*

I can't tell you exactly what happens in the device, but I can tell you
that I have the same problem with my device on my PC sometimes. 

In addition to this I2c-failures from time to time the box is quite
sensitive regarding: repowering, replugging and host-rebooting. This is
a USB-device-firmware problem which makes the device crash and all
subsequent USB-transfers are failed. Reloading the module or replugging
the device will make it work again.

I lost contact with Technisat some time ago and wouldn't be able easily
to get the information (and I doubt they have a solution for this
problem - up to them to prove me wrong).

How many days without interruption did you use the device?

I was following quietly you're discussion with Antti. Has someone taken
care of the your changes regarding the transfer-size?

I think it should included.

regards,
-- 
Patrick.
--
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] 00/14] Fix ISDB-T tuning issues

2014-07-07 Thread Patrick Boettcher
Hi Mauro,

I like all of your changes. 

Acked-By: Patrick Boettcher pboettc...@kernellabs.com

regards,
Patrick.


On Fri,  4 Jul 2014 14:15:26 -0300 Mauro Carvalho Chehab
m.che...@samsung.com wrote:

 While testing two dvb devices:
   - Mygica S870 (dib8096 based);
   - Pixelview PV-D231U (RN-F)
 
 I noticed several bugs:
 - It doesn't lock on any layer with Interleave  2;
 - It doesn't lock in mode 2 (4 K FFT);
 - ADC OFF settings is wrong, with causes wrong ADC
   adjustments and cause locking issues;
 - the ADC gain table was not right;
 - There are some troubles when used with CONFIG_HZ = 1000.
 
 This patch series addresses the above bugs. While here, it also
 improves some debug messages and ad a few other improvements.
 
 For the patches that change the sleep time, I opted to be
 conservative, e. g. to reproduce the worse case (e. g.
 CONFIG_HZ = 100), so enforcing that the minimal state machine
 delays to be 10ms. That assures that no regression will be
 introduced, and that machines configured with HZ equal to
 250, 300 or 1000 will work just like the ones configured with
 HZ equal to 100.
 
 Please notice that the Windows driver for Mygica S870 does a
 different setup than what's there at the Linux driver. While
 I have a patch changing it, I opted to remove it from this patch
 series, as I didn't notice any improvements with the patch here.
 Such patch is already in patchwork:
   https://patchwork.linuxtv.org/patch/24586/
 and we might resurrect it latter if needed.
 
 Mauro Carvalho Chehab (14):
   dib8000: Fix handling of interleave bigger than 2
   dib8000: Fix ADC OFF settings
   dib8000: Fix alignments at dib8000_tune()
   dib8000: Fix: add missing 4K mode
   dib8000: remove a double call for dib8000_get_symbol_duration()
   dib8000: In auto-search, try first with partial reception enabled
   dib8000: Restart sad during dib8000_reset
   dib0700: better document struct init
   dib8000: Fix the sleep time at the state machine
   dib0090: Fix the sleep time at the state machine
   dib8000: use jifies instead of current_kernel_time()
   dib8000: Update the ADC gain table
   dib8000: improve debug messages
   dib8000: improve the message that reports per-layer locks
 
  drivers/media/dvb-frontends/dib0090.c   |  15 +-
  drivers/media/dvb-frontends/dib8000.c   | 645
 +++-
 drivers/media/usb/dvb-usb/dib0700_devices.c | 148 --- 3 files
 changed, 436 insertions(+), 372 deletions(-)
 
--
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: dib0700 NEC scancode question

2014-03-27 Thread Patrick Boettcher
Hi David,

On Thursday 27 March 2014 22:40:41 David Härdeman wrote:
 On Thu, Mar 27, 2014 at 01:07:28PM +0100, David Härdeman wrote:
 Hi Patrick,
 
 a quick question regarding the dib0700 driver:
 
 in ./media/usb/dvb-usb/dib0700_core.c the RC RX packet is defined as:
 ...
 
 The NEC protocol transmits in the order:
 ...
 
 Does the dib0700 fw really reorder the bytes, or could the order of
 not_system and system in struct dib0700_rc_response have been
 accidentally reversed?

It feels like a hundred years I haven't work on that. I'm not sure whether 
this knowledge can still be retrieved as of today or not. I would lie if I 
told you that I look the archives... and I can't want to do that (lying and 
looking).

However, I realize that your assumption might not be totally far-fetched. If 
you can find another IR-receiver just check whether the same remote control 
delivers swapped bytes or not (if I understood it correctly, that's your real 
question). Then you have you answer, haven't you? 

-- 
Patrick.
--
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: usb: b2c2: Kconfig: add PCI dependancy to DVB_B2C2_FLEXCOP_USB

2013-08-30 Thread Patrick Boettcher
Hi (sending again due to HTML-nonsense in Mail),

On Friday 30 August 2013 10:23:24 Chen Gang wrote:
 DVB_B2C2_FLEXCOP_USB need depend on PCI, or can not pass compiling with
 allmodconfig for h8300.
 
 The related error:
 
   drivers/media/usb/b2c2/flexcop-usb.c: In function
 'flexcop_usb_transfer_exit': drivers/media/usb/b2c2/flexcop-usb.c:393:3:
 error: implicit declaration of function 'pci_free_consistent'
 [-Werror=implicit-function-declaration] pci_free_consistent(NULL,
 
 [..]
 
  config DVB_B2C2_FLEXCOP_USB
   tristate Technisat/B2C2 Air/Sky/Cable2PC USB
 - depends on DVB_CORE  I2C
 + depends on DVB_CORE  I2C  PCI
   help
 Support for the Air/Sky/Cable2PC USB1.1 box (DVB/ATSC) by
 Technisat/B2C2,

Instead of selecting PCI we could/should use usb_alloc_coherent() and 
usb_free_cohrerent(), shouldn't we?

--
Patrick 
--
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: Diversity support?

2013-06-04 Thread Patrick Boettcher
On Tuesday 04 June 2013 13:17:49 Antti Palosaari wrote:
 On 06/04/2013 10:29 AM, Luca Olivetti wrote:
  Al 04/06/13 01:17, En/na Antti Palosaari ha escrit:
  I'm not easily discouraged :-) so here's the question again: is there
  some dvb-t usb stick (possibly available on the EU market) with
  diversity support under Linux?
  
  I have feeling AF9035/IT9135 dual devices could do that.
  
  Looking at the wiki, most devices based on those demodulators are either
  unsupported or have a dual tuner but not diversity.
 
 Because diversity is not interesting feature at all in normal use case.
 Whole DVB-T standard fits poorly for mobile usage and you cannot make
 situation that much better using diversity.

Well, I have to disagree on this statement.

Diversity does not do a lot in fixed reception. That's right, but depending 
on the TV-standard the diversity gain in mobile reception can be enormous.

Several field trials we did in the past years have shown that large parts of 
the trial route which have not worked at at all in single receiver work like 
a charm in diversity.

Maybe the route-selection in this cases was biased to show off the 
performance of diversity ... well, it worked - diversity showed off.

best regards,
--
Patrick
--
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: Diversity support?

2013-06-04 Thread Patrick Boettcher
On Monday 03 June 2013 17:14:18 Luca Olivetti wrote:
  So, what's the real status of diversity support?
  
  Nobody knows?
 
 I'm not easily discouraged :-) so here's the question again: is there
 some dvb-t usb stick (possibly available on the EU market) with
 diversity support under Linux?

There is some diversity support hidden in the dib8000-driver and in some 
board-drivers which use it. Basically it creates several instances of the 
dib8000-driver (one for each demod) but it exposes only one dvb-frontend to 
userspace via the API. When the user is tuning the frontend he is, in fact, 
tuning all of them in diversity.

IMO, the question which needs to be discussed is for diversity-support is an 
how to change the API-question and how does userspace can control it?

In my experience with multi-frontend-hardware, which can do diversity or 
dual/triple-reception or both at the same time, is that the question is the 
routing and the grouping of frontend and assigning them to their sinks 
(stream-interfaces).

Right now DVB-API can expose several frontends and dvrs and demuxes for one 
device, but there is no way to userspace telling the hardware to combine 
frontend0 and frontend1 to do diversity.

When looking at diversity/multi-frontend problems, IMHO, we should not limit 
ourselves to USB-devices. The real usage of those MFE-devices is in an 
embedded hardware (STB in a car or at home).

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


[GIT PULL FOR 3.10] DiBxxxx: fixes and improvements

2013-04-22 Thread Patrick Boettcher
Hi Mauro,

These patches contains some fixes and changes for the DiBcom demods and 
SIPs.

Please merge for 3.10 if possible.


The following changes since commit 60d509fa6a9c4653a86ad830e4c4b30360b23f0e:

  Linux 3.9-rc8 (2013-04-21 14:38:45 -0700)

are available in the git repository at:

  git://git.linuxtv.org/pb/media_tree.git/ master

for you to fetch changes up to 7e39d1958b186e5af259b9fde1a006853b4663ab:

  [media] dib8000: do not freeze AGCs by default (2013-04-22 10:06:48 +0200)


Olivier Grenie (6):
  [media] dib8000: enhancement
  [media] dib7000p: enhancement
  [media] dib0090: enhancement
  [media] dib8096: enhancement
  [media] dib7090p: remove the support for the dib7090E
  [media] dib7090p: improve the support of the dib7090 and dib7790

Patrick Boettcher (1):
  [media] dib8000: do not freeze AGCs by default

 drivers/media/dvb-core/dvb-usb-ids.h |3 +-
 drivers/media/dvb-frontends/dib0090.c|  438 ++---
 drivers/media/dvb-frontends/dib7000p.c   |   17 +-
 drivers/media/dvb-frontends/dib7000p.h   |7 +
 drivers/media/dvb-frontends/dib8000.c| 2239 +-
 drivers/media/dvb-frontends/dib8000.h|6 +-
 drivers/media/dvb-frontends/dibx000_common.h |3 +-
 drivers/media/usb/dvb-usb/dib0700_devices.c  |  465 +++--
 8 files changed, 1780 insertions(+), 1398 deletions(-)


regards,
--
Patrick
--
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: request for linux driver for Analogix ANX9804/ANX9805

2012-12-12 Thread Patrick Boettcher
On Wednesday 12 December 2012 13:20:46 Fricke, Silvio wrote:
 Hi,
 
 We have developed a prototype of an i.mx6 CPU-module connected to an
 ANALOGIX AN9804 chip. This is a DisplayPort/HDMI-Transmitter [1]. This is
 a converter for simple rgb-signals to DisplayPort and HDMI signals. The
 ANX is connected with the i.mx6 over i2c. Audio plays in this context
 also a role.
 
 The chip has these features:

  [..]
 
 I have checked it, and it does not exist any kind of linux driver for the
 ANX9804. My company doesn't have currently the skills (and manpower) to
 bring this device to mainline kernel. Have someone skills and courage to
 bring this hardware device to mainline kernel? I will offer one iMX6
 based development board for developing the device driver and after
 success of the project, for the developer as gift to dominate the world.

What do you call this then? http://members.efn.org/~rick/work/anx9804/

The development of such a driver basically driven by one thing: the 
information about how to program this device. Registers/firmwares/program-
flows.

In a second, yet important, step, you need to be know with which kind of 
(already existing or not) API you want to use this device.

In your Email there is no indication of both of this. Please clarify.

best regards,
--
Patrick

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


Re: Linux DVB Explained..

2012-11-19 Thread Patrick Boettcher
Hi Richard,

I can maybe answer some of your questions with semi-complete answers in the 
hope it helps you further.

On Saturday 17 November 2012 13:35:18 Richard wrote:
 struct dvb_demux :
 This has a start_feed and a stop feed.   What feed is this? ... the
 RAW 188 byte packets from the device perhaps?

start/stop_feed are callbacks in the dvb_demux-device (which is represented 
with dvb/adapterX/demuxX by your driver) which have to be filled in by the 
driver which implements and controls the HW-demux.

E.g: (from dmxdev.c) when a user is issuing the DMX_ADD_PID ioctl (which 
marks the request of a certain PID from the TS currently received) the 
start_feed-callback is called. It tells the driver that the TS-packets 
identified with PID are expected via e.g. the dvrX device. So the driver has 
to instruct its internal demux to have them pass the filter.

 What is the main purpose of this structure?
 
 struct dmx_demux :
 This structure holds the frontend device struct and contains the .fops
 for read/write.  Is this the main interface when using the
 /dev/dvb/adapterX/demux ? /dvr?

I'm not sure to get what you want to know here.

 adapter = dvb_register_adapter() : Register a new DVB device adapter
 (called once)
 dvb_dmx_init(dvbdemux);  // Called once per Demux chain?
 dvb_dmxdev_init();  // Called once per demux chain ? same as above
 
 ---
 The hardware I am using has 6 TS data inputs, 4 tuners (linked to TS
 inputs)  and hardware PID filters and I am trying to establish the
 relationship of dmx and dmxdev.

Before understanding the relationship you need to know where, in the end, 
you want your TS-packets. In user-space? Sent to a hardware-decoder? 
Somewhere else? All of that?

HTH a litte bit,
--
Patrick 

--
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: Sony PlayTV: tuning on second tuner causing reception issues on first tuner

2012-10-15 Thread Patrick Boettcher
Hi Torgeir,

On Sunday 14 October 2012 00:25:26 Torgeir Veimo wrote:
 When background EIT scanning is enabled on my VDR setup, I am getting
 signal disruption about every 20-21 seconds, with my sony playtv USB dual
 DVB-T tuner.

In the VDR-ML-thread you said that you have 2 of those devices?

I could get my hands on the information which is date 3-4 years ago when the 
device was designed and in fact the problem you're describing existed at 
that time. It was fixed by hardware and normally should not appear in end-
user's products. However as I understand the fix can easily fail if the 
production-site a) does not  know that this problem exists and thus does not 
test it or b) doesn't care. Rumors say, that the prod-site has been 
transferred from France to China. If that is true or if your device is 
simply a runner or anything else is not clear as of now.

When did you purchase this device? If it was recently, there is a fair 
chance that exchanging it will result in a working device.

 
 This seems to be caused by the second tuner retuning in the
 background. I've heard that the nova-t 500 cards can have issues with
 disruption when the second tuner on a card is tuning. Is this the same
 type of problem?

Most likely. No complete software-fix available.

regards,
--
Patrick 

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


[GIT PULL] for 3.7 (technisat-usb2)

2012-10-03 Thread Patrick Boettcher
Hi Mauro,

The following changes since commit 2425bb3d4016ed95ce83a90b53bd92c7f31091e4:

  em28xx: regression fix: use DRX-K sync firmware requests on em28xx 

are available in the git repository at:

  http://linuxtv.org/git/pb/media_tree.git staging/for_v3.7

for you to fetch changes up to e196a346d5d2e4695a587ca2f99da5e5491d4e95:

  [media]: add MODULE_DEVICE_TABLE to technisat-usb2 


Patrick Boettcher (1):
  [media]: add MODULE_DEVICE_TABLE to technisat-usb2

 drivers/media/usb/dvb-usb/technisat-usb2.c |1 +
 1 file changed, 1 insertion(+)

regards,

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


[media/usb] Trivial fix for 3.7 if not too late

2012-10-01 Thread Patrick Boettcher
Hi Mauro,


If it is not too late could you please incorporate the following patch to 3.7.

It fixed the autoloading of the technisat-ubs2-module when the device is 
actually detected.

- [PATCH] [media]: add MODULE_DEVICE_TABLE to technisat-usb2

best regards,

--
Patrick.
-
--
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]: add MODULE_DEVICE_TABLE to technisat-usb2

2012-10-01 Thread Patrick Boettcher
This patch adds a module-device-table-entry to the
technisat-usb2-driver which will help udev to on-demand load the
driver. This was obviously forgotten during initial commit.

Signed-off-by: Patrick Boettcher pboettc...@kernellabs.com
---
 drivers/media/usb/dvb-usb/technisat-usb2.c |1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/media/usb/dvb-usb/technisat-usb2.c 
b/drivers/media/usb/dvb-usb/technisat-usb2.c
index acefaa8..7a8c8c1 100644
--- a/drivers/media/usb/dvb-usb/technisat-usb2.c
+++ b/drivers/media/usb/dvb-usb/technisat-usb2.c
@@ -677,6 +677,7 @@ static struct usb_device_id technisat_usb2_id_table[] = {
{ USB_DEVICE(USB_VID_TECHNISAT, USB_PID_TECHNISAT_USB2_DVB_S2) },
{ 0 }   /* Terminating entry */
 };
+MODULE_DEVICE_TABLE(usb, technisat_usb2_id_table);
 
 /* device description */
 static struct dvb_usb_device_properties technisat_usb2_devices = {
-- 
1.7.9.5

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


Compiling v4l-dvb.git-modules for stock kernel without media_build

2012-08-25 Thread Patrick Boettcher
Hi list,

Not so long ago I used a special version of v4l-dvb.git (v3,2 + a patch) on 
my system together with a debian stock kernel. It worked. Now I update my 
system and thus the kernel and what I did last time doesn't seem to work any 
longer:

1) checkout v3.2 of v4l-dvb.git and apply my path
2) get .config, .kernelvariables and Module.symvers from linux-
headers-3.2.0-3-amd64 (which corresponds to my running kernel)
3) make oldconfig modules_prepare  in v4l-dvb.git
4) make M=drivers/media
5) install all the .ko into /lib/modules
6) depmod -a
7) reboot

Now I have the following symptoms:
a) for the 3 PCI-cards I have the b2c2-flexcop-pci charged automatically but 
it fails to initialize the devices and bails out with -22
b) the USB-device is not triggering the loading of its driver and upon a 
modprobe it doesn't get claimed.

Something is wrong, but I don't know what.

Could it be the symbol versions? 

Thanks for any hints.

--
Patrick.

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


Re: DVB core enhancements - comments please?

2012-06-29 Thread Patrick Boettcher
On Friday 29 June 2012 13:24:52 Patrick Boettcher wrote:

 That said, IMO, the rtl-sdr driver should sit on the DVB-API. Maybe V4L2

*argl* I wanted to say, ... should _not_ sit on the DVB-API... 

--
Patrick.

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


Re: DVB USB issues we has currently

2012-05-03 Thread Patrick Boettcher
On Thursday 03 May 2012 16:20:23 Antti Palosaari wrote:
 Hello,
 Here we are, that's the first part I am going to fix as a GSoC
 project. Work is planned to start after two weeks but better to
 discuss beforehand.
 
 And wish-list is now open!
 
 I see two big DVB USB issues including multiple small issues;
 
 1)
 Current static structure is too limited as devices are more dynamics
 nowadays. Driver should be able to probe/read from eeprom device
 configuration.
 
 Fixing all of those means rather much work - I think new version of
 DVB USB is needed.

I'm looking forward to see RFCs about proposals for additions to dvb-
usb's structure. Especially the ugly device-usb-id-referencing. 

What do you mean by new version?

 2)
 Suspend/resume is not supported and crashes Kernel. I have no idea
 what is wrong here and what is needed. But as it has been long term
 known problem I suspect it is not trivial.

Are you sure that suspend/resume-crashes are related to dvb-usb?

Maybe the refactoring of some buffer-handling should be considered.

Also adding support for hybrid (analog+dvb-devices) is missing. Mike 
Krufky did some work somewhere which looked promising but was never 
merged.

best regards,
--
Patrick.
--
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 07/10] dvb-demux: add functionality to send raw payload to the dvr device

2012-05-02 Thread Patrick Boettcher
Hi Mike,

On Tuesday 01 May 2012 06:12:22 Michael Krufky wrote:
 From: Michael Krufky mkru...@kernellabs.com
 
 If your driver needs to deliver the raw payload to userspace without
 passing through the kernel demux, use function: dvb_dmx_swfilter_raw

I like this one very much. I had a background task sleeping in my head 
which was how to add non-Transport-Stream standards to Linux-dvb. This 
one I can now cancel, thanks to this change.

We now can add CMMB-support and DAB to linux-dvb (after more discussions 
on the API of course).

Do you have user-space-tool ready which uses the new RAW-payload 
mechanism? Something which can be used as an example.

Thanks for this development.

--
Patrick 

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


Re: Module dvb-usb

2012-03-30 Thread Patrick Boettcher
Hi Matias,

On Friday 30 March 2012 09:42:14 Matias Aguirre wrote:
 My name is Matias and im a programmer. I need to ask some things to
 you about the creation of new modules into the kernel for TV
 adapters. I have a new TV adapter with the chipset DM1305.
 
 I have the firmware of this chipset.. can i start with that or i need
 more info?

First of all you should ask on the linux-media mailing list whether 
there is already someone working on a driver for this device. (CC'd)

If not having the firmware-binary is not enough, you also need to know 
how to communicate with it and what kind of messages have to be sent to 
the firmware to make it do something. If you do not have any 
documentation about it (and you cannot get hold of it from the vendor), 
you need to reverse-engineer the communication.

This is where the vp7045-example comes into the game: the vp7045 has a 
relatively simple firmware interface which can help you to quickly make 
a driver for you device.

But, there is two different dvb usb device types:

1) the USB-firmware contains the demod/tuner-drivers and the firmware 
interface is high-level. (this is the case for the vp7045)
or

2) the USB-firmware only implements a bridge for I2C/SPI or other 
control protocols and the demod/tuner-drivers have to be handled from 
the host. 

If your device is of the 2nd kind you should rather look at cxusb.c .

HTH
--
Patrick

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


Re: update to file fr-Paris for DVB-T

2012-03-28 Thread Patrick Boettcher
Hi Eric,

On Tuesday 27 March 2012 19:19:41 EricJCh.Aubert wrote:
 Hello,
 
 I have updated the file fr-Paris with the frequencies valid from
 march 8th 2011
 source
 http://www.tvnt.net/forum/tous-au-numerique-ile-de-france-le-8-
 mars-2011-mise-a-jour-le-26-02-2011-t24658.html
 
 file fr-Paris joined

Are you sure that the frequency you give for R8 is 700MHz? 

700 MHz is not a fitting into the 8MHz structured sprectrum. To make 
it fix it should be either 698 or 706.

best regards,

--
Patrick Boettcher

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


Re: SDR FM demodulation

2012-02-09 Thread Patrick Boettcher
On Thursday 09 February 2012 16:01:12 Antti Palosaari wrote:
 I have taken radio sniffs from FM capable Realtek DVB-T device. Looks
 like demodulator ADC samples IF frequency and pass all the sampled
 data to the application. Application is then responsible for
 decoding that. Device supports DVB-T, FM and DAB. I can guess  both
 FM and DAB are demodulated by software.
 
 Here is 17 second, 83 MB, FM radio sniff:
 http://palosaari.fi/linux/v4l-dvb/rtl2832u_fm/
 Decode it and listen some Finnish speak ;)
 
 Could someone help to decode it? I tried GNU Radio, but I failed
 likely because I didn't have enough knowledge... GNU Radio and
 Octave or Matlab are way to go.

For someone to decode it, you would need to give more information about 
the format of the stream. Like the sampling frequency, the sample-format 
and then the IF-frequency.

I never did something like myself, but from what I saw in gnuradio there 
should be everything to make a FM-demod based on the data.

regards,
--
Patrick Boettcher

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


Re: [PATCH 2/2] [media] dvb_frontend: Require FE_HAS_PARAMETERS for get_frontend()

2012-01-19 Thread Patrick Boettcher
Hi Mauro,

On Wednesday 18 January 2012 18:51:25 Mauro Carvalho Chehab wrote:
 Calling get_frontend() before having either the frontend locked
 or the network signaling carriers locked won't work. So, block
 it at the DVB core.

I like the idea and also the implementation.

But before merging this needs more comments from other on the list. 

Even though it does not break anything for any current frontend-driver 
it is important to have a wider base agreeing on that. Especially from 
some other frontend-driver-writers.

For example I could imagine that a frontend HAS_LOCK, but is still not 
able to report the parameters (USB-firmware-based frontends might be 
poorly implemented). 

And so on...

regards,

--
Patrick Boettcher

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


Re: v4l-utils migrated to autotools

2012-01-18 Thread Patrick Boettcher
On Wednesday 18 January 2012 13:31:01 Rémi Denis-Courmont wrote:
 On Wed, 18 Jan 2012 10:19:24 -0200, Mauro Carvalho Chehab
 
 mche...@redhat.com wrote:
  Not sure if it is possible, but it would be great if the build
  output would be less verbose. libtool adds a lot of additional
  (generally
 
 useless)
 
  messages, with makes harder to see the compilation warnings in the
  middle of all those garbage.
 
 These days, automake has a silent mode that looks much like a kernel
 compilation.

I missed the first message of this thread, that's why I hijacked it here 
and it is short:

I love cmake and can't understand why people are not preferring it over 
autotools for user-space applications and conditional+configurable 
builds. 

I hope my mail is not too off-topic.

regards,
--
Patrick Boettcher

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


Re: [PATCH] [RFC] dib8000: return an error if the TMCC is not locked

2012-01-18 Thread Patrick Boettcher
On Tuesday 17 January 2012 19:45:28 you wrote:
 On ISDB-T, a few carriers are reserved for TMCC decoding
 (1 to 20 carriers, depending on the mode). Those carriers
 use the DBPSK modulation, and contain the information about
 each of the three layers of carriers (modulation, partial
 reception, inner code, interleaving, and number of segments).
 
 If the TMCC carrier was not locked and decoded, no information
 would be provided by get_frontend(). So, instead of returning
 false values, return -EAGAIN.
 
 Another alternative for this patch would be to add a flag to
 fe_status (FE_HAS_GET_FRONTEND?), to indicate that the ISDB-T
 TMCC carriers (and DVB-T TPS?), required for get_frontend
 to work, are locked.
 
 Comments?

I think it changes the behaviour of get_frontend too much and in fact 
transmission parameter signaling (TPS for DVB-T, TMCC for ISDB-T) locks 
are already or should be if not integrated to the status locks.

Also those parameters can change over time and signal a 
reconfiguration of the transmission.

So, for me I would vote against this kind of implementation in favor a 
better one. Unfortunately I don't have a much better idea at hand right 
now.

--
Patrick Boettcher

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


Re: [PATCH] [RFC] dib8000: return an error if the TMCC is not locked

2012-01-18 Thread Patrick Boettcher
On Wednesday 18 January 2012 14:40:09 Mauro Carvalho Chehab wrote:
 Em 18-01-2012 10:49, Patrick Boettcher escreveu:
  On Tuesday 17 January 2012 19:45:28 you wrote:
  On ISDB-T, a few carriers are reserved for TMCC decoding
  (1 to 20 carriers, depending on the mode). Those carriers
  use the DBPSK modulation, and contain the information about
  each of the three layers of carriers (modulation, partial
  reception, inner code, interleaving, and number of segments).
  
  If the TMCC carrier was not locked and decoded, no information
  would be provided by get_frontend(). So, instead of returning
  false values, return -EAGAIN.
  
  Another alternative for this patch would be to add a flag to
  fe_status (FE_HAS_GET_FRONTEND?), to indicate that the ISDB-T
  TMCC carriers (and DVB-T TPS?), required for get_frontend
  to work, are locked.
  
  Comments?
  
  I think it changes the behaviour of get_frontend too much and in
  fact transmission parameter signaling (TPS for DVB-T, TMCC for
  ISDB-T) locks are already or should be if not integrated to the
  status locks.
  
  Also those parameters can change over time and signal a
  reconfiguration of the transmission.
  
  So, for me I would vote against this kind of implementation in
  favor a better one. Unfortunately I don't have a much better idea
  at hand right now.
 
 The current status are:
 
 typedef enum fe_status {
 FE_HAS_SIGNAL   = 0x01,   /* found something above the noise
 level */ FE_HAS_CARRIER  = 0x02,   /* found a DVB signal  */
 FE_HAS_VITERBI  = 0x04,   /* FEC is stable  */
 FE_HAS_SYNC = 0x08,   /* found sync bytes  */
 FE_HAS_LOCK = 0x10,   /* everything's working... */
 FE_TIMEDOUT = 0x20,   /* no lock within the last ~2
 seconds */ FE_REINIT  = 0x40/* frontend was reinitialized,  */ }
 fe_status_t;/* application is recommended to
 reset */
 
 There are a few options that can be done:
 
 1) only rise FE_HAS_LOCK if TPS/TMCC demod were locked. The
 description for FE_HAS_LOCK (everything's working) seems to
 indicate that TMCC lock/TPS lock is also part of everything.

HAS_LOCK includes TPS-lock, right. But TPS-lock can raise much before 
HAS_LOCK and at worse signal conditions. In DVB-T and ISDB-T we can have 
the parameters at -1 dB SNR (or below) whereas data reception at least 
needs  ~3 dB ( QPSK 1/2 in DVB-T)  and much more for the modulations 
used currently on earth.

 2) create a new status for it.

Maybe that's the way to go then. FE_HAS_PARAMETERS.

 With regards to dvb-core get_frontend() call, it only makes sense if
 the TPS/TMCC is locked. So, I think that such call needs to be
 limited to happen only when the lock were archived, like the
 enclosed patch.

OK.

--
Patrick Boettcher

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


Re: V4L/DVB (12892): DVB-API: add support for ISDB-T and ISDB-Tsb (version 5.1)

2012-01-17 Thread Patrick Boettcher
On Friday 13 January 2012 13:37:57 Dan Carpenter wrote:
 Hello Patrick Boettcher,
 
 I know this patch is really old but I was hoping you still might be
 able to take a look at it.
 
 The patch b6e760f30975: V4L/DVB (12892): DVB-API: add support for
 ISDB-T and ISDB-Tsb (version 5.1) from Aug 3, 2009, leads to the
 following warning:
 drivers/media/dvb/dvb-core/dvb_frontend.c:993:9: warning: Initializer
 entry defined twice
 drivers/media/dvb/dvb-core/dvb_frontend.c:1012:9:   also defined
 here

How does this thing has lived such a long time without being noticed by 
anyone? Very strange.

Of course this is wrong and it should be fixed by removing the second 
section. IOW, we should keep the section with the 1s. 

 drivers/media/dvb/dvb-core/dvb_frontend.c
 
 +   _DTV_CMD(DTV_ISDBT_PARTIAL_RECEPTION, 1, 0),
 +   _DTV_CMD(DTV_ISDBT_SOUND_BROADCASTING, 1, 0),
 +   _DTV_CMD(DTV_ISDBT_SB_SUBCHANNEL_ID, 1, 0),
 +   _DTV_CMD(DTV_ISDBT_SB_SEGMENT_IDX, 1, 0),
 +   _DTV_CMD(DTV_ISDBT_SB_SEGMENT_COUNT, 1, 0),
 +   _DTV_CMD(DTV_ISDBT_LAYERA_FEC, 1, 0),
 +   _DTV_CMD(DTV_ISDBT_LAYERA_MODULATION, 1, 0),
 +   _DTV_CMD(DTV_ISDBT_LAYERA_SEGMENT_COUNT, 1, 0),
 +   _DTV_CMD(DTV_ISDBT_LAYERA_TIME_INTERLEAVING, 1, 0),
 +   _DTV_CMD(DTV_ISDBT_LAYERB_FEC, 1, 0),
 +   _DTV_CMD(DTV_ISDBT_LAYERB_MODULATION, 1, 0),
 +   _DTV_CMD(DTV_ISDBT_LAYERB_SEGMENT_COUNT, 1, 0),
 +   _DTV_CMD(DTV_ISDBT_LAYERB_TIME_INTERLEAVING, 1, 0),
 +   _DTV_CMD(DTV_ISDBT_LAYERC_FEC, 1, 0),
 +   _DTV_CMD(DTV_ISDBT_LAYERC_MODULATION, 1, 0),
 +   _DTV_CMD(DTV_ISDBT_LAYERC_SEGMENT_COUNT, 1, 0),
 +   _DTV_CMD(DTV_ISDBT_LAYERC_TIME_INTERLEAVING, 1, 0),

I prepared a patch for this in my repo. I will send a pull-request right 
away.

Thanks for pointing this out.

regards,
--
Patrick.
--
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


PULL request: remove superfluous DTV_CMDs

2012-01-17 Thread Patrick Boettcher
Hi Mauro

I fixed a warning caused by a commit made a long time ago in 
dvb_frontend.c . 

Thanks to Dan Carpenter for pointing this one out.

-

The following changes since commit 
1e73fa5d56333230854ae9460579eb2fcee8af02:
  Mauro Carvalho Chehab (1):
[media] stb6100: Properly retrieve symbol rate

are available in the git repository at:

  http://linuxtv.org/git/pb/media_tree.git staging/for_v3.3

Patrick Boettcher (1):
  [media] DVB-CORE: remove superfluous DTV_CMDs

 drivers/media/dvb/dvb-core/dvb_frontend.c |   19 ---
 1 files changed, 0 insertions(+), 19 deletions(-)


best regards,
--
Patrick Boettcher

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


Re: [PATCH 1/4] DVB: dib0700, move Nova-TD Stick to a separate set

2012-01-17 Thread Patrick Boettcher
H Jiri,

On Tuesday 10 January 2012 18:11:22 Jiri Slaby wrote:
 To properly support the three LEDs which are on the stick, we need
 a special handling in the -frontend_attach function. Thus let's have
 a separate -frontend_attach instead of ifs in the common one.
 
 The hadnling itself will be added in further patches.
 
 Signed-off-by: Jiri Slaby jsl...@suse.cz
 ---
 [..]

Thanks. I reviewed and added those commits to my tree (apparently Mike 
did the same and asked Mauro to pull as well).

We will see how it turns out. :)

best regards,
--
Patrick Boettcher

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


Re: [PATCH RFCv2] add DTMB support for DVB API

2012-01-16 Thread Patrick Boettcher
On Saturday 14 January 2012 16:31:16 Antti Palosaari wrote:
 Version 2. I have made some changes from feedback got and
 what I myself found better. I will add documentation later
 after API issues are resolved.
 Thanks to Andreas, Patrick and Mauro.
 
 Cc: Patrick Boettcher pboettc...@kernellabs.com
 Cc: Andreas Oberritter o...@linuxtv.org
 Cc: Mauro Carvalho Chehab mche...@redhat.com
 Signed-off-by: Antti Palosaari cr...@iki.fi
 ---
   drivers/media/dvb/dvb-core/dvb_frontend.c |   14 +++---
   drivers/media/dvb/dvb-core/dvb_frontend.h |2 ++
   drivers/media/dvb/frontends/atbm8830.c|2 +-
   drivers/media/dvb/frontends/lgs8gl5.c |2 +-
   drivers/media/dvb/frontends/lgs8gxx.c |2 +-
   include/linux/dvb/frontend.h  |   22
 +++--- include/linux/dvb/version.h   |  
  2 +-
   7 files changed, 36 insertions(+), 10 deletions(-)
 
 diff --git a/drivers/media/dvb/dvb-core/dvb_frontend.c
 b/drivers/media/dvb/dvb-core/dvb_frontend.c
 index b15db4f..abdc203 100644
 --- a/drivers/media/dvb/dvb-core/dvb_frontend.c
 +++ b/drivers/media/dvb/dvb-core/dvb_frontend.c
 @@ -177,7 +177,7 @@ static enum dvbv3_emulation_type dvbv3_type(u32
 delivery_system)
   case SYS_DVBT:
   case SYS_DVBT2:
   case SYS_ISDBT:
 - case SYS_DMBTH:
 + case SYS_DTMB:
   return DVBV3_OFDM;
   case SYS_ATSC:
   case SYS_DVBC_ANNEX_B:
 @@ -989,6 +989,7 @@ static struct dtv_cmds_h dtv_cmds[DTV_MAX_COMMAND
 + 1] = {
   _DTV_CMD(DTV_CODE_RATE_LP, 1, 0),
   _DTV_CMD(DTV_GUARD_INTERVAL, 1, 0),
   _DTV_CMD(DTV_TRANSMISSION_MODE, 1, 0),
 + _DTV_CMD(DTV_INTERLEAVING, 1, 0),
 
   _DTV_CMD(DTV_ISDBT_PARTIAL_RECEPTION, 1, 0),
   _DTV_CMD(DTV_ISDBT_SOUND_BROADCASTING, 1, 0),
 @@ -1039,6 +1040,7 @@ static struct dtv_cmds_h
 dtv_cmds[DTV_MAX_COMMAND + 1] = {
   _DTV_CMD(DTV_GUARD_INTERVAL, 0, 0),
   _DTV_CMD(DTV_TRANSMISSION_MODE, 0, 0),
   _DTV_CMD(DTV_HIERARCHY, 0, 0),
 + _DTV_CMD(DTV_INTERLEAVING, 0, 0),
 
   _DTV_CMD(DTV_ENUM_DELSYS, 0, 0),
   };
 @@ -1316,6 +1318,9 @@ static int dtv_property_process_get(struct
 dvb_frontend *fe,
   case DTV_HIERARCHY:
   tvp-u.data = c-hierarchy;
   break;
 + case DTV_INTERLEAVING:
 + tvp-u.data = c-interleaving;
 + break;
 
   /* ISDB-T Support here */
   case DTV_ISDBT_PARTIAL_RECEPTION:
 @@ -1503,7 +1508,7 @@ static int set_delivery_system(struct
 dvb_frontend *fe, u32 desired_system)
* The DVBv3 or DVBv5 call is requesting a different system. So,
* emulation is needed.
*
 -  * Emulate newer delivery systems like ISDBT, DVBT and DMBTH
 +  * Emulate newer delivery systems like ISDBT, DVBT and DTMB
* for older DVBv5 applications. The emulation will try to use
* the auto mode for most things, and will assume that the desired
* delivery system is the last one at the ops.delsys[] array
 @@ -1625,6 +1630,9 @@ static int dtv_property_process_set(struct
 dvb_frontend *fe,
   case DTV_HIERARCHY:
   c-hierarchy = tvp-u.data;
   break;
 + case DTV_INTERLEAVING:
 + c-interleaving = tvp-u.data;
 + break;
 
   /* ISDB-T Support here */
   case DTV_ISDBT_PARTIAL_RECEPTION:
 @@ -1896,7 +1904,7 @@ static int dtv_set_frontend(struct dvb_frontend
 *fe) case SYS_DVBT:
   case SYS_DVBT2:
   case SYS_ISDBT:
 - case SYS_DMBTH:
 + case SYS_DTMB:
   fepriv-min_delay = HZ / 20;
   fepriv-step_size = fe-ops.info.frequency_stepsize * 2;
   fepriv-max_drift = (fe-ops.info.frequency_stepsize * 
 2) + 
1;
 diff --git a/drivers/media/dvb/dvb-core/dvb_frontend.h
 b/drivers/media/dvb/dvb-core/dvb_frontend.h
 index d63a821..fb2d57c 100644
 --- a/drivers/media/dvb/dvb-core/dvb_frontend.h
 +++ b/drivers/media/dvb/dvb-core/dvb_frontend.h
 @@ -353,6 +353,8 @@ struct dtv_frontend_properties {
 
   fe_delivery_system_tdelivery_system;
 
 + fe_interleaving_t   interleaving;
 +
   /* ISDB-T specifics */
   u8  isdbt_partial_reception;
   u8  isdbt_sb_mode;
 diff --git a/drivers/media/dvb/frontends/atbm8830.c
 b/drivers/media/dvb/frontends/atbm8830.c
 index a2261ea..4e11dc4 100644
 --- a/drivers/media/dvb/frontends/atbm8830.c
 +++ b/drivers/media/dvb/frontends/atbm8830.c
 @@ -428,7 +428,7 @@ static int atbm8830_i2c_gate_ctrl(struct
 dvb_frontend *fe, int enable)
   }
 
   static struct dvb_frontend_ops atbm8830_ops = {
 - .delsys = { SYS_DMBTH },
 + .delsys = { SYS_DTMB },
   .info = {
   .name = AltoBeam ATBM8830/8831 DMB-TH,
   .frequency_min = 47400,
 diff --git a/drivers/media/dvb/frontends/lgs8gl5.c
 b/drivers/media/dvb/frontends/lgs8gl5.c
 index 2cec804..416cce3 100644
 --- a/drivers/media/dvb/frontends/lgs8gl5

Re: [RFCv1] add DTMB support for DVB API

2011-12-25 Thread Patrick Boettcher
On Friday, December 23, 2011 02:38:59 PM Andreas Oberritter wrote:
 On 22.12.2011 22:30, Antti Palosaari wrote:
  @@ -201,6 +205,9 @@ typedef enum fe_guard_interval {
  
   GUARD_INTERVAL_1_128,
   GUARD_INTERVAL_19_128,
   GUARD_INTERVAL_19_256,
  
  +GUARD_INTERVAL_PN420,
  +GUARD_INTERVAL_PN595,
  +GUARD_INTERVAL_PN945,
  
   } fe_guard_interval_t;
 
 What does PN mean in this context?

While I (right now) cannot remember what the PN abbreviation stands for, the 
numbers are the guard time in micro-seconds. At least if I remember 
correctly.

I can confirm that Tuesday next week if no one else corrects me before.

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


Re: [RFCv1] add DTMB support for DVB API

2011-12-25 Thread Patrick Boettcher
Hi Antti,

On Thursday, December 22, 2011 10:30:25 PM Antti Palosaari wrote:
 Rename DMB-TH to DTMB.
 
 Add few new values for existing parameters.
 
 Add two new parameters, interleaving and carrier.
 DTMB supports interleavers: 240 and 720.
 DTMB supports carriers: 1 and 3780.
 
 Signed-off-by: Antti Palosaari cr...@iki.fi
 ---
   drivers/media/dvb/dvb-core/dvb_frontend.c |   19 ++-
   drivers/media/dvb/dvb-core/dvb_frontend.h |3 +++
   include/linux/dvb/frontend.h  |   13 +++--
   include/linux/dvb/version.h   |2 +-
   4 files changed, 33 insertions(+), 4 deletions(-)
 
 diff --git a/drivers/media/dvb/dvb-core/dvb_frontend.c
 b/drivers/media/dvb/dvb-core/dvb_frontend.c
 index 821b225..ec2cbae 100644
 --- a/drivers/media/dvb/dvb-core/dvb_frontend.c
 +++ b/drivers/media/dvb/dvb-core/dvb_frontend.c
 @@ -924,6 +924,8 @@ static struct dtv_cmds_h dtv_cmds[DTV_MAX_COMMAND +
 1] = {
   _DTV_CMD(DTV_CODE_RATE_LP, 1, 0),
   _DTV_CMD(DTV_GUARD_INTERVAL, 1, 0),
   _DTV_CMD(DTV_TRANSMISSION_MODE, 1, 0),
 + _DTV_CMD(DTV_CARRIER, 1, 0),

What would you think if instead of adding DTV_CARRIER (which indicates 
whether we are using single carrier or multi carrier, if I understand it 
correctly) we add a TRANSMISSION_MODE_SC.

Then TRANSMISSION_MODE_4K is the multi-carrier mode and TRANSMISSION_MODE_SC 
is the single-carrier mode. We save a new DTV-command.

I'm not making a secret of it, this is how we handled this inside DiBcom and 
it would simplify the integration of our drivers for this standard. This is 
planned to be done during the first half of 2012.

Comments?

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


Re: Add support for new Terratec DVB USB IDs

2011-12-25 Thread Patrick Boettcher
On Friday, December 23, 2011 12:44:46 AM Jonathan Nieder wrote:
 Hi,
 
 Eduard Bloch wrote[1]:
  current revision of the Cinergy S2 USB box from Terratec seems to use
  another USB-IDs. The manufacturer provides patches at
  http://linux.terratec.de/tv_en.html and it seems like the only
  difference is really just the new ID and a couple of init flag changes.
  
  Their patch is not exactly for the linux-3.x tree but for the current
  s2-liplianin drivers, OTOH they still look similar enough and porting
  the patch was straight-forward. I also added the patch for Terratec S7
  which is not tested yet but shouldn't do any harm.
 
 [...]
 
 Eduard, meet the LinuxTV project.  linux-media folks, meet Eduard.
 Patch follows.
 
 Eduard: may we have your sign-off?  Please see
 Documentation/SubmittingPatches, section 12 Sign your work for what
 this means.
 
 My only other hint is that it would be better to add the new device
 IDs in some logical place in the list near the older ones, instead of
 at the end where it is more likely to collide with other patches in
 flight.  So if rerolling the patches, it might be useful to do that.

Due to the use of the reference in the USB-id table adding the new set at 
the end of the list is actually the best way. Adding them in the middle will 
cause a lot of changes and bugs.

Except the Signed-off-by everything is fine to my eyes.

--
Patrick
--
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.3] HDIC HD29L2 DMB-TH demodulator driv

2011-12-21 Thread Patrick Boettcher
On Tuesday 20 December 2011 19:09:14 Mauro Carvalho Chehab wrote:
 On 20-12-2011 16:01, Antti Palosaari wrote:
  On 12/20/2011 07:16 PM, Antti Palosaari wrote:
  On 12/20/2011 06:25 PM, Patrick Boettcher wrote:
  Hi all,
  
  On Tuesday 20 December 2011 16:42:53 Antti Palosaari wrote:
  Adding those to API is not mission impossible. Interleaver is
  only new parameter and all the rest are just extending values.
  But my time is limited... and I really would like to finally
  got Anysee smart card reader integrated to USB serial first.
  
  And if it is added we should not forget to discuess whether
  DMB-TH is the right name. (If this has already been addressed
  in another thread please point me to it).
  
  I know this standard under at least 2 different names: CTTB and
  DTMB.
  
  Which is the one to choose?
  
  Yes, there is many names and it is not even clear for me what are
  differences between names. I called it DMB-TH since existing
  Kernel drivers have selected that name.
  
  http://en.wikipedia.org/wiki/CMMB
  http://en.wikipedia.org/wiki/DTMB
  http://en.wikipedia.org/wiki/Digital_Multimedia_Broadcasting
  http://en.wikipedia.org/wiki/Digital_Terrestrial_Multimedia_Broadc
  ast
  
  CMMB
  CTTB
  DTMB (DTMB-T/H, DMB-T/H)
  DMB (T-DMB)
  
  DMB seems to be much different so drop it out. DTMB seems to be
  official term for DMB-T/H. CMMB seems to be for small devices
  (mobile), maybe subset of DTMB. Finally I have CTTB and DTMB which
  seems to be equivalents. DTMB is more common.
  
  So I end up for the DTMB. I give my vote for that.

CMMB has nothing to do with DTMB/CTTB. It modulations parameters and 
physical/link layers are completely different compared to CMMB.

I'll vote for CTTB as this is the (latest) official name. At least this 
is what DiBcom's Chinese representatives state.

Maybe there are some Chinese on this list to enlighten this situation?

--
Patrick Boettcher

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


Re: [GIT PULL FOR 3.3] HDIC HD29L2 DMB-TH demodulator driver

2011-12-20 Thread Patrick Boettcher
Hi all,

On Tuesday 20 December 2011 16:42:53 Antti Palosaari wrote:
 Adding those to API is not mission impossible. Interleaver is only
 new parameter and all the rest are just extending values. But my
 time is limited... and I really would like to finally got Anysee
 smart card reader integrated to USB serial first.

And if it is added we should not forget to discuess whether DMB-TH is 
the right name. (If this has already been addressed in another thread 
please point me to it).

I know this standard under at least 2 different names: CTTB and DTMB. 

Which is the one to choose?

best regards,
--
Patrick

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


Communication misunderstanding? (was: Re: [RFC] vtunerc: virtual DVB device - is it ok to NACK driver because of worrying about possible misusage?)

2011-12-01 Thread Patrick Boettcher
(stripped LKML)

On Thursday 01 December 2011 01:09:28 Andreas Oberritter wrote:
 [..]
 Regarding the kernellabs.com people[3] lobbying against your
 contribution: 
 [..]

KernelLabs is not a collections of politicians who want to change the 
world together whatever the costs. We are professional individuals in 
our decisions and views. 

I think it's better to limit public discussions in a professional 
technical environment to technical problems - saying that I would want 
to encourage you discuss with us off-list or in our blog what makes you 
generalize in such a way?


--
Patrick Boettcher

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


Re: PULL request for 3.2 (fixes 'n' features)

2011-11-24 Thread Patrick Boettcher

Hi Mauro,

On Tue, 4 Oct 2011, Patrick Boettcher wrote:


Hi Mauro,

if it's not too late for 3.2 could you please pull from

git://linuxtv.org/pb/media_tree.git staging/for_v3.2

for

[media] dib9090: limit the I2C speed [media] dib8096P: add the reference 
board [media] add the support for DiBcom [media] dib7090: add the reference 
board [media] DiB8000: improve the tuning and the SNR monitoring

[media] DiBcom: correct warnings
[media] dib7090: add the reference board TFE7090E
[media] dib7000p/dib0090: update the driver


I think this PULL request got lost. (as usual for my pull-requests :( ).

It was meant for 3.2 and was sent in advance.

Do you think you will get it in?

regards,
--

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


Re: Nova-T Stick 2 on kernel 3.0

2011-11-21 Thread Patrick Boettcher
Hi Jos,

On Monday 21 November 2011 14:14:25 Jos Lemmens wrote:
 Hello Patrick,
 
 I have a Device 008: ID 2040:7060 Hauppauge Nova-T Stick 2 dvb
 adapter. It worked great with your driver in Linux kernel 2. But
 since kernel 3.0 it doesn't work anymore. When I try to start the tv
 with the tzap tool, I get this message:
 
dib0700: tx buffer length is larger than 4. Not supported.

Oh, I wasn't aware that this problem exists (or I forgot). If you can 
please try a newer version of the kernel. Or try the media_build + the 
v4l-dvb-repository to track down (via git bisect, for example) which 
commit broke it. What was the latest version you have tried?

Anyone else confirms this problem?

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


FE_CAN-bits (was: Re: PATCH: Query DVB frontend capabilities)

2011-11-11 Thread Patrick Boettcher
Hi,

On Thursday, November 10, 2011 10:20:46 PM Mauro Carvalho Chehab wrote:
 
 We should also think on a way to enumerate the supported values for each
 DVB properties, the enum fe_caps is not enough anymore to store
 everything. It currently has 30 bits filled (of a total of 32 bits), and
 we currently have:
   12 code rates (including AUTO/NONE);
   13 modulation types;
   7 transmission modes;
   7 bandwidths;
   8 guard intervals (including AUTO);
   5 hierarchy names;
   4 rolloff's (probably, we'll need to add 2 more, to distinguish between
 DVB-C Annex A and Annex C).
 
 So, if we would need to add one CAN_foo for each of the above, we would
 need 56 to 58 bits, plus 5-6 bits to the other capabilities that
 currently exists there. So, even 64 bits won't be enough for the current
 needs (even having the delivery system caps addressed by something
 else).

IMHO, we don't need such a fine FE_CAN_-bit distinguishing for most 
standards. A well defined sub-standard definition is sufficient, which can be 
handled with a delivery-system-like query as proposed in the original patch. 
This also will be much simpler for most user-space applications and users.

DVB-T means: 
- 8K or 2K, 
- 1/4-1/32 Guard, 
- 1/2, 2/3, 3/4, 5/6 and 7/8 coderate, 
- QPSK, 64QAM or 16QAM

DVB-H (RIP as Remi wrote somewhere) would have meant:
- DVB-T + 4K + in-depth-interleaver mode

The same applies to ISDB-T and ISDB-T 1seg. And for CMMB, CTTB, DVB-SH. 

If there are demods which can't do one particular thing, we should forget 
about them. At least this is what almost all applications I have seen so far 
are doing implicitly. 

Though, I see at least one inconvenience is if someone is using linux-dvb 
for developping dsp-software and wants to deliver things which aren't done. 
But is this a case we want to support within the official API.

regards,
--
Patrick Boettcher - KernelLabs
http://www.kernellabs.com/
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: FX2 FW: conversion from Intel HEX to DVB USB hexline

2011-11-06 Thread Patrick Boettcher
Hi Antti,

On Sunday, November 06, 2011 03:26:20 PM Antti Palosaari wrote:
 Is there any simple tool (or one liner script :) to convert normal Intel
 HEX firmware to format used by DVB USB Cypress firmware loader?
 
 Or is there some other way those are created?
 
 Loader is here:
 dvb-usb-firmware.c
 int usb_cypress_load_firmware()

I'm sure that you have found something yourself in the meantime, but I used 
the attached script to convert .hex to binaries.

HTH,

--
Patrick Boettcher - KernelLabs
http://www.kernellabs.com/


hex2bin.pl
Description: Perl program


Re: FX2 FW: conversion from Intel HEX to DVB USB hexline

2011-11-06 Thread Patrick Boettcher
On Sunday, November 06, 2011 07:07:31 PM Antti Palosaari wrote:
 Many thanks!
 
 Actually, I was just started to write similar Python script! You got
 maybe 15min late but still 15min before mine was ready :)
 
 Format was nothing more than convert ASCII hex values to binary bytes
 and stripping out all white spaces and Intel HEX start code :.
 
 Why it was initially converted to binary and not used Intel HEX as it
 is? I think you know, as a original author, history about that decision?

Because doing string-parsing and evaluation in the kernel is something I 
usually  avoid. And it can't sure be done within 300 bytes (the size of the 
perl script). Also the .bin is smaller in term of size compared to the .hex.


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


Re: MediaController support in LinuxDVB demux

2011-11-04 Thread Patrick Boettcher
Hi Alain,

On Thursday 03 November 2011 10:16:25 Alain VOLMAT wrote:
 Hi
 
 Last week we started the discussion about having a MediaController
 aware LinuxDVB demux and I would like to proceed on this discussion.
 Then, the discussion rapidly moved to having the requirement for
 dynamic pads in order to be able to add / remove then in the same
 way as demux filters are created for each open of the demux device
 node.
 
 I am not really sure dynamic pads is really a MUST for MC aware demux
 device. The demux entity could work with a predefined number of
 output pads, determined by the vendor, depending on the demux
 capacity of the device. Of course it is probably better to have only
 pads when needed but it requires quite a lot of change to the
 overall MC framework and such modification could be done afterward,
 when the MC support for LinuxDVB is much better understood.

I insert my comments and questions here, because the last words are 
reflecting my thoughts very well I think. I'm talking about ... when 
the MC support for LinuxDVB is much better understood:

I, for myself, haven't had yet the opportunity to look very closely to 
the MC-implementation in V4l until now. From what I understand it is 
flexible framework which enables precise abstractions of data-flows and 
data-routing between hard- and software components of a multimedia-
device.

Extending such a thing to LinuxDVB seems of course a good idea, because 
as of today we are missing some flexibility in this area. One problem 
for example I faced in the past was the correct (from user-space) 
support for multiple frontends which can either do diversity to improve 
reception quality or be standalone receivers (each frontend decodes the 
MPEG2-TS). 

I'm sure that there are other examples which are more common which 
express the need to have MC in DVB.

Would it be a problem for you to elaborate a little bit more around the 
why and how and what around MC in DVB? Before starting to implement it 
like Mauro suggested. Could you go more in detail for you actual problem 
(like what is missing in the current dvb-demux)? 

I think it is absolutely necessary to know more about the reasoning 
around MC - as it has a big potential - before any implementation.

Maybe there are some block-diagrams and presentations around somewhere. 
Until now I only saw this Email-thread and this: 
http://www.linuxtv.org/events.php (at the very bottom).

Thanks in advance.

best regards
--
Patrick Boettcher

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


PULL request for 3.2 (fixes 'n' features)

2011-10-04 Thread Patrick Boettcher

Hi Mauro,

if it's not too late for 3.2 could you please pull from

git://linuxtv.org/pb/media_tree.git staging/for_v3.2

for

[media] dib9090: limit the I2C speed 
[media] dib8096P: add the reference board 
[media] add the support for DiBcom 
[media] dib7090: add the reference board 
[media] DiB8000: improve the tuning and the SNR monitoring

[media] DiBcom: correct warnings
[media] dib7090: add the reference board TFE7090E
[media] dib7000p/dib0090: update the driver

Thanks a lot in advance,

--

Patrick
--
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: DiBxxxx: fixes for 3.1/3.0

2011-09-05 Thread Patrick Boettcher

On Mon, 5 Sep 2011, Mauro Carvalho Chehab wrote:


Em 05-09-2011 05:11, Olivier Grenie escreveu:

Hello Mauro,
I agree with you but when I wrote this patch, my concern was  that the read 
register function (dib0070_read_reg)
returns a u16 and so I could not propagate the error. That's why I decided to 
return 0 and not change the API.
But if you have a better idea, I will have no problem to implement it.


Ok, I'll pull from it for 3.0/3.1. For 3.2, the better is to fix it.

What other drivers do when they need to read a 16 bit register is to declare 
the function as
returning an 'int'. As you know, on Linux, int has 32 bits, so it returns an 
u16 properly.
It will also return properly the errors.

So, all you need to do is to convert it to something like:

static int dib0070_read_reg(struct dib0070_state *state, u8 reg)
{
int ret;

ret = mutex_lock_interruptible(...);
if (ret  0)
return ret;
...
ret = i2c_transfer(state-i2c, state-msg, 2);
if (ret  0)
goto error;
if (ret != 2) {
ret = -EIO;
goto error;
}
ret = (state-i2c_read_buffer[0]  8)
| state-i2c_read_buffer[1];

error:
mutex_unlock(...);
return ret;
}

You'll need to add a check on all places that calls dib0070_read_reg() (and 
dib070_write_reg) to do
the right thing when a negative number is returned, like:

static int dib0070_set_bandwidth(struct dvb_frontend *fe, struct 
dvb_frontend_parameters *ch)
{
struct dib0070_state *state = fe-tuner_priv;
int tmp = dib0070_read_reg(state, 0x02);
if (tmp  0)
return tmp;
tmp | = 0x3fff;

...
}


For the write register function (dib0070_write_reg), in case of problem with 
the mutex lock, an error code is returned.


Userspace applications in general handle EAGAIN on a different way, especially 
if the application
is opening the device on non-blocking mode, as POSIX require that applications 
should re-try
the ioctl, if EAGAIN is returned, on non-blocking mode. They might also handle 
EINTR case as well.
So, using it instead of EINVAL is better.


While I agree with you in principle I think the time we would need and the 
risk we would take to do what you're asking here is too high.


I agree the drivers are quite huge and ugly but now adding hundreds of 
if's and returns won't make them better.


Right now if a read fails it returns 0 which in some cases might be even 
correct.


Fixing the error-handling in the drivers will most likely break things 
unless it is not done automagically - IOW not by a human being.


I quickly checked some other sources in dvb/frontends/ and the Dibbies are 
not the only ones where the error-path would need to be fixed.


I'd appreciate if we could restrict this requirement to new drivers which 
certainly will arrive. Of course, if there is a volunteer I'm ready to 
have a look.


What do you think?

regards,

--
Patrick
--
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: Bug#639161: linux-image-3.0.0-1-686-pae: Upgrade 2.6.39 - 3.0.0 breaks playback on DiBcom 7000PC

2011-08-25 Thread Patrick Boettcher
Hi,

Afaik, this is fixed with those commits:

[media] dib0700: correct error message for_v3.0
[media] dib0700: protect the dib0700 buffer access
[media] DiBcom: protect the I2C bufer access

from

http://git.linuxtv.org/pb/media_tree.git/shortlog/refs/heads/for_v3.0

A pull request has been sent to the media-maintainer, but it seems he is
busy.

--
Patrick.

On Thursday 25 August 2011 00:50:37 Ben Hutchings wrote:

Patrick,

Please could you take a look at the following bug report on Linux 3.0 as
packaged in Debian.

Ben.

On Wed, 2011-08-24 at 18:59 +0200, Soeren D. Schulze wrote:
 Package: linux-2.6
 Version: 3.0.0-1
 Severity: normal

 I usually use tzap/mplayer for TV playback.

 After the upgrade to Linux 3.0.0, tzap command line output still looks
 fine, but mplayer does not seem to receive any data (its cache does not
 fill up).

 syslog/dmesg output looks the same as in 2.6.39.  On the first try to
 tune, dmesg receives:

 dib0700: tx buffer length is larger than 4. Not supported.
 (for which I find various non-Debian bug reports)

 But that does not seem to be the issue, because the same message appears
 in 2.6.39, where everything is fine.
 So I do not really have an idea what the problem is, but I certainly
 know that it's a regression, because simply booting Linux 2.6.39 rather
 than 3.0.0 on the same system avoids the problem.

 -- Package-specific info:
 ** Version:
 Linux version 3.0.0-1-686-pae (Debian 3.0.0-1) (b...@decadent.org.uk)
 (gcc version 4.5.3 (Debian 4.5.3-3) ) #1 SMP Sun Jul 24 14:27:32 UTC 2011

 ** Command line:
 BOOT_IMAGE=/vmlinuz-3.0.0-1-686-pae
 root=UUID=3aa0a731-df46-486e-9c1e-258723e14f8f ro

 ** Not tainted

 ** Kernel log:
 [   11.031446] saa7134:   card=172 - RoverMedia TV Link Pro FM
19d1:0138
 [   11.031580] saa7134:   card=173 - Zolid Hybrid TV Tuner PCI
1131:2004
 [   11.031713] saa7134:   card=174 - Asus Europa Hybrid OEM
1043:4847
 [   11.031847] saa7134:   card=175 - Leadtek Winfast DTV1000S
107d:6655
 [   11.031982] saa7134:   card=176 - Beholder BeholdTV 505 RDS
:5051
 [   11.032126] saa7134:   card=177 - Hawell HW-404M7

 [   11.032217] saa7134:   card=178 - Beholder BeholdTV H7
5ace:7190
 [   11.032351] saa7134:   card=179 - Beholder BeholdTV A7
5ace:7090
 [   11.032485] saa7134:   card=180 - Avermedia PCI M733A
1461:4155 1461:4255
 [   11.032656] saa7134:   card=181 - TechoTrend TT-budget T-3000
13c2:2804
 [   11.032789] saa7134:   card=182 - Kworld PCI SBTVD/ISDB-T Full-Seg
 Hybrid  17de:b136
 [   11.032923] saa7134:   card=183 - Compro VideoMate Vista M1F
185b:c900
 [   11.033057] saa7134:   card=184 - Encore ENLTV-FM 3
1a7f:2108
 [   11.033192] saa7134:   card=185 - MagicPro ProHDTV Pro2
 DMB-TH/Hybrid  17de:d136
 [   11.033326] saa7134:   card=186 - Beholder BeholdTV 501
5ace:5010
 [   11.033460] saa7134:   card=187 - Beholder BeholdTV 503 FM
5ace:5030
 [   11.033596] saa7134[0]: subsystem: 1131:, board: UNKNOWN/GENERIC
 [card=0,autodetected]
 [   11.075242] IR NEC protocol handler initialized
 [   11.265597] saa7134[0]: board init: gpio is 10020
 [   11.368582] saa7134[0]: Huh, no eeprom present (err=-5)?
 [   11.381924] saa7134[0]: registered device video0 [v4l2]
 [   11.382055] saa7134[0]: registered device vbi0
 [   11.417515] IR RC5(x) protocol handler initialized
 [   11.607051] cfg80211: Calling CRDA to update world regulatory domain
 [   11.995773] IR RC6 protocol handler initialized
 [   12.191500] IR JVC protocol handler initialized
 [   12.263839] dib0700: loaded with support for 20 different device-types
 [   12.264209] dvb-usb: found a 'Hauppauge Nova-T Stick' in warm state.
 [   12.265499] dvb-usb: will pass the complete MPEG2 transport stream to
 the software demuxer.
 [   12.266158] DVB: registering new adapter (Hauppauge Nova-T Stick)
 [   12.517093] DVB: registering adapter 0 frontend 0 (DiBcom 7000PC)...
 [   12.609760] IR Sony protocol handler initialized
 [   12.790869] DiB0070: successfully identified
 [   12.907896] ACPI: PCI Interrupt Link [ALKC] enabled at IRQ 22
 [   12.907988] VIA 82xx Audio :00:11.5: PCI INT C - Link[ALKC] -
 GSI 22 (level, low) - IRQ 22
 [   12.908316] VIA 82xx Audio :00:11.5: setting latency timer to 64
 [   12.932675] saa7134 ALSA driver for DMA sound loaded
 [   12.932807] saa7134[0]/alsa: saa7134[0] at 0xfdffc000 irq 16
 registered as card -1
 [   12.948789] lirc_dev: IR Remote Control driver registered, major 249
 [   12.952109] IR LIRC bridge handler initialized
 [   13.380033] Registered IR keymap rc-dib0700-rc5
 [   13.380514] input: IR-receiver inside an USB DVB receiver as
 /devices/pci:00/:00:10.4/usb1/1-1/1-1.3/rc/rc0/input6
 [   13.380749] rc0: IR-receiver inside an USB DVB receiver as
 /devices/pci:00/:00:10.4/usb1/1-1/1-1.3/rc/rc0
 [   13.382312] dvb-usb: schedule remote query interval to 50 msecs.
 [   13.382385] dvb-usb: Hauppauge Nova-T Stick 

Re: DiBxxxx: fixes for 3.1/3.0

2011-08-05 Thread Patrick Boettcher

Hi Mauro,

On Wed, 3 Aug 2011, Patrick Boettcher wrote:

Would you please pull from

git://linuxtv.org/pb/media_tree.git for_v3.0

for the following to changesets:

[media] dib0700: protect the dib0700 buffer access
[media] DiBcom: protect the I2C bufer access


I added a patch from Olivier which fixes wrongly used dprintks and 
replaces them by err()-calls.


[media] dib0700: correct error message

I herewith renew my PULL-request. The request now contains 3 changesets.

best regards,
--
Patrick
--
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: vp702x

2011-08-03 Thread Patrick Boettcher

Hi Florian,

On Tue, 2 Aug 2011, Florian Mickler wrote:


Hi Mauro! Hi Patrick!

I realized this morning, that I broke vp702x (if it was working before)
with my last patchseries. Sorry. :(

I'm gonna follow up on this mail with a patch to hopefully fix it, but
if nobody can test it, I'd say to rather revert my patchseries
for v3.1 . It will then still use on-stack dma buffers and will
produce a WARN() in the dmesg if it does so, but hopefully nothing bad
happens.

Patrick, do you still have the hardware to test this? I'm semi
confident that I did not make any silly mistakes. :| (it compiles)


I'm not sure whether I still have exactly this box. There were two 
versions and I got rid of at least one of them.


I moved recently into a new house and right now a lot of things are hidden 
in some boxes somewhere... I'll try to find some time to check it. Don't 
ask me when that will be :).


regards,
--

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


DiBxxxx: fixes for 3.1/3.0

2011-08-03 Thread Patrick Boettcher

Hi Mauro,

Would you please pull from

git://linuxtv.org/pb/media_tree.git for_v3.0

for the following to changesets:

[media] dib0700: protect the dib0700 buffer access
[media] DiBcom: protect the I2C bufer access

?

Those two changesets are fixing the remaining problems regarding the 
dma-on-stack-buffer-fix applied for the first time in 2.6.39, IIRC.


They should go to stable 3.0 (as they are in my tree) and they can be 
cherry-picked to 3.1.


We are preparing the same thing for 2.6.39 as the patches don't apply 
cleanly.


Thanks to Javier Marcet for his help during the debug-phase.

thanks and best regards,
--

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


Re: [PATCH 2/3] dvb-usb: multi-frontend support (MFE)

2011-07-31 Thread Patrick Boettcher
On Thursday 28 July 2011 00:23:06 Antti Palosaari wrote:
 On 07/28/2011 01:07 AM, Malcolm Priestley wrote:
  On Wed, 2011-07-27 at 16:06 -0300, Mauro Carvalho Chehab wrote:
  Em 25-07-2011 21:17, Antti Palosaari escreveu:
  Signed-off-by: Antti Palosaaricr...@iki.fi
  
  +adap-fe[i] = NULL;
  +/* In error case, do not try register more FEs,
  + * still leaving already registered FEs alive. */
  
  I think that the proper thing to do is to detach everything, if one of
  the attach fails. There isn't much sense on keeping the device
  partially initialized.
  
  From memory, I recall the existing code doesn't detach the frontend
  even
  
  if the device driver forces an error. So, the device driver must detach
  the frontend first.
 
 Yes, if you return for example error (or fe == NULL) for .tuner_attach()
 it does not detach or deregister it - just silently discard all. I
 thought very many times those when implementing this and keep very
 careful not to change old functionality.
 
  The trouble is that dvb-usb is becoming dated as new drivers tend to
  work around it. No one likes to touch it, out of fear of breaking
  existing drivers.
 
 Yes, so true. I have thought that too. There is a lot of things I want
 to change but those are very hard without massive work.
 
 * We should have priv at the very first. No priv for FW DL example.
 * Remote keytable should be property of certain device model not adapter
 * There should be way to set count of adapter (and fe) in runtime (this
 is why I allowed to fail 2nd FE attach silently)
 * no probe (read eeprom etc) callback (I think read MAC could be renamed
 for probe)
 * no FE power control (GPIOs etc) that MFE patch adds this too
 * maybe probe1 and probe2 callbacks needed. sequence something like plug
 device = probe1 = download FW = probe2 = attach demod

If I had more time I'd add 

* handle suspend/resume calls properly for buggy USB firmwares (iow: all 
devices I saw)

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


Re: [media] dib0700: get rid of on-stack dma buffers

2011-04-04 Thread Patrick Boettcher

Hi Florian,

On Sun, 3 Apr 2011, Florian Mickler wrote:


Hi,

since I got no reaction[1] on the vp702x driver, I proceed with the
dib0700.

There are multiple drivers in drivers/media/dvb/dvb-usb/ which use
usb_control_msg to perform dma to stack-allocated buffers. This is a bad idea
because of cache-coherency issues and on some platforms the stack is mapped
virtually and also lib/dma-debug.c warn's about it at runtime.

Patches to ec168, ce6230, au6610 and lmedm04 were already tested and reviewed
and submitted for inclusion [2]. Patches to a800, vp7045, friio, dw2102, m920x
and opera1 are still waiting for for review and testing [3].

This patch to dib0700 is a fix for a warning seen and reported by Zdenek
Kabalec in Bug #15977 [4].

Florian Mickler (2):
 [media] dib0700: get rid of on-stack dma buffers


For this one we implemented an alternative. See here:

http://git.linuxtv.org/pb/media_tree.git?a=commit;h=16b54de2d8b46e48c5c8bdf9b350eac04e8f6b46

which I pushed, but obviously forgot to send the pull-request.

This is done now.

For the second patch I will incorperate it as soon as I find the time.

best regards,
--

Patrick
--
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: dibusb device with lock problems

2011-04-03 Thread Patrick Boettcher
Hi Mr Tux,

On Saturday 02 April 2011 15:45:22 Mr Tux wrote:
 Hi list, hello Patrick,
 
 A locking problem with specific dib3000mb devices is still present in
 kernel 2.6.38.
 
 Now people upgrading from lenny to squeeze are also affected - see: [1]
 
 Please have a look at my previous post in [2] for a detailed description
 and links to this bug's history.
 
 I'm sending a cc of this to the people who once where affected by this
 bug or involved with the code change that introduced it.
 
 Anyone can confirm this is fixed/pending for his device and what
 dib3000mb device he is using out of the linuxtv wiki list of 14
 dib3000mb devices [3]?
 
 I have 3 devices of the hama usb 1.1 series: [4], that's number 66 in the
 wiki listing - they all are affected by this bug with kernels  2.6.31
 
 Thanks for some feedback. Can we fix this for good for the pending
 devices?
 
 
 [1] http://www.vdr-portal.de/index.php?page=ThreadpostID=991041

In the post on vdr-portal you're showing the kernel-output of 2.6.32 I 
guess, do you still have the kernel output of 2.6.26 (or any before 2.6.32)?

I think this line is not normal in your case:

 dibusb: This device has the Thomson Cable onboard. Which is default.

But to be sure I need you to test. TUning the device is not needed with the 
old kernel, just plugging it and checking that line should be enough.

--
Patrick.
--
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: Skystar 2 2.6 broken in kernel 2.6.38

2011-04-03 Thread Patrick Boettcher
Hi,

On Saturday 02 April 2011 21:30:53 Steffen Barszus wrote:
 Hi
 
 I just installed natty and found that one of the drivers i use is
 broken. Is this a known issue ?
 
 
 [6.115925] [ cut here ]
 [6.115931] WARNING: at
 /build/buildd/linux-2.6.38/fs/proc/generic.c:323
 __xlate_proc_name+0xbb/0xd0() [6.115933] Hardware name: EP45T-UD3LR

Actually the driver is not broken as it still works. This is a warning 
issued by the core because the driver is using a bad string. There have been 
a lot of attempts to fix it in the past, but they have been lost somewhere on 
the road. 

I hope this time it will make it.

best regards,
--
Patrick Boettcher - KernelLabs
http://www.kernellabs.com/
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH] [media] dib0700: fix possible NULL pointer dereference

2011-04-03 Thread Patrick Boettcher
On Saturday 26 March 2011 19:23:56 Mariusz Kozlowski wrote:
 Seems like 'adap-fe' test for NULL was meant to be before we dereference
 that pointer.
 
 Signed-off-by: Mariusz Kozlowski m...@lab.zgora.pl

Thanks, applied.

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


[2.6.39] fixes - pull request

2011-04-03 Thread Patrick Boettcher
Hi Mauro,

I cleaned my mailbox and collected some small fixes for 2.6.39 and for other 
version (stable is Cc'd in that case).

Please pull from (sorry for the wrong branch name)

http://git.linuxtv.org/pb/media_tree.git staging/for_v2.6.39

for 

[PATCH] Fix dependencies for Technisat USB2.0 DVB-S/S2
[PATCH] [media] dib0700: fix possible NULL pointer...
FLEXCOP-PCI: fix __xlate_proc_name-warning for flexcop-pci
DIB0700: fix typo in dib0700_devices.c

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


Re: Dib7000/mt2266 help

2011-03-12 Thread Patrick Boettcher
Hi Peter,

(adding back the list to CC)

On Saturday 12 March 2011 11:48:38 Peter Tilley wrote:
 Hi Patrick,
 My sincerest apologies for coming to you directly but I have tried the
 Linux mailing list and received no response and noticed you seem to have
 been heavily involved with much of the Dibcom driver development.
 
 I have an issue with a dual tuner which is sold under the brand of Kaiser
 Baas KBA01004 but identifies itself as 1164:1e8c which is a Yaun device
 and this device seems to have already been included in the driver files.
 
 It loads ok and reports not problems.  It tunes ok and reports FE lock on
 all channels however on all but one channel upon receiving FE lock the
 BER stays at 1 instead of dropping to a low number which would
 indicate I am not getting viterbi.
 
 The device is fitted with pairs of MT2266 and DIB7000 which I have
 positive identified by opening the USB stick.
 
  am more than happy to try and work this out myself however the amount of
 detail around in support of the Linux drivers is extremely low and a
 search for manufacturers data sheets finds next to nothing.There
 seems to be lots of what I would call magic numbers in the drivers and
 little to determine what they are doing.

Are you sure it is a driver problem?

If the BER stays at this value it could also mean that the channel-
configuration is wrong.

Are you using a channels.conf which has all parameters set, or are you doing 
a channel-scan-like tune (all values are set to AUTO).
 
 My question to you is are you able to offer either any pointers to solve
 the problem or help me find detailed information about the devices so I
 can help myself.
 
 I should point out that the device works perfectly under windows on the
 same antenna and indeed I have even successfully extracted the firmware
 from the supplied windows driver, renamed it so it loads and the problem
 still remains.

There are usually some adaptations board-designing companies do to improve 
reception quality (adding external LNAs and things like that) that are of 
course handled by the Window-driver, because it is created by the 
manufacturer and not by the Linux-driver, because (in this case) the driver 
was released by the chip-manufacturer.

Is the device toggling between FE_HAS_LOCK and no FE_HAS_LOCK or does it 
stay constantly at 

Please try whether you can achieve the BER lowering by moving the antenna or 
using a better one. If this helps, it really means that the windows-driver 
does something more the board.

I doubt that the chip-driver needs to be changed, more likely the GPIOs of 
the dib0700 (in dib0700_core.c) or of the dib7000 are used to turn on or off 
a frequency switch or a LNA.

Good point, what are the frequencies you're tuning ?

regards,

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


Re: [PULL] request for 2.6.38-rc1

2011-01-19 Thread Patrick Boettcher

Hi Mauro,

On Sun, 16 Jan 2011, Mauro Carvalho Chehab wrote:


Em 14-01-2011 12:51, Patrick Boettcher escreveu:

Hi Mauro,

if it is not too late, here is a pull request for some new devices from DiBcom. 
It would be nice to have it in 2.6.38-rc1.

Pull from

git://linuxtv.org/pb/media_tree.git staging/for_2.6.38-rc1.dibcom

for

DiB: Codingstype updates



Not sure if this is by purpose, but you're changing all
msleep(10) into msleep(20). This sounds very weird for a
CodingStyle fix:

-   msleep(10);
+   msleep(20);


I was as surprised as you when I saw that changed, but in fact it is a 
checkpatch-fix: it seems that checkpatch is warning about msleep or less 
than 20ms.


Maybe it is not the right fix to put them to msleep(20), but I think this 
is better than to do udelay(1).


What do you think?



+   if (request_firmware(state-frontend_firmware, dib9090.fw, 
adap-dev-udev-dev)) {

Where's dib9090.fw firmware is available? The better is to submit a patch to 
linux-firmware
with the firmware binary, with some license that allows end-users to use it 
with your device
and distros/distro partners to re-distribute it. While here, please add also 
the other
dibcom firmwares.


The dib0700-firmware is already available through a license. The 
dib9090-firmware will come later. It'll take a moment before everything is 
ready.




Vendors are free to use their own legal text for it. There are several examples 
for it
at:

http://git.kernel.org/?p=linux/kernel/git/dwmw2/linux-firmware.git;a=blob_plain;f=WHENCE;hb=HEAD


Btw, there are two alignment errors (one at dib7000p, for some cases, aligned 
with 4 chars),
and another at dib8000, where all statements after an if are aligned with 3 
tabs plus one space.
I'm fixing those issues, c/c you at the fix patches.


Nice, thank you.

best regards,
--

Patrick
--
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] dib7000m/p: struct alignment fix

2011-01-14 Thread Patrick Boettcher

Hi,

On Wed, 12 Jan 2011, Robin Humble wrote:

Ubuntu has a bug open for the issue:
 https://bugs.launchpad.net/ubuntu/+source/linux/+bug/654791
but the disable pid filtering workaround one person uses there doesn't
work for me.


Sorry for the delay, but I only realized today that this bug exists.

We are currently creating a proper fix for it.

best regards,
--

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


Re: [PATCH] dib7000m/p: struct alignment fix

2011-01-14 Thread Patrick Boettcher

Hi again,

On Wed, 12 Jan 2011, Mauro Carvalho Chehab wrote:


Em 12-01-2011 11:17, Robin Humble escreveu:

Hi,

this is basically a re-post of
  http://www.linuxtv.org/pipermail/linux-dvb/2010-September/032744.html
which fixes an Oops when tuning eg. AVerMedia DVB-T Volar, Hauppauge
Nova-T, Winfast DTV. it seems to be quite commonly reported on this list.

 [  809.128579] BUG: unable to handle kernel NULL pointer dereference at 
0012
 [  809.128586] IP: [a0013702] i2c_transfer+0x16/0x124 [i2c_core]
 [  809.128598] PGD 669a7067 PUD 79e5f067 PMD 0
 [  809.128604] Oops:  [#1] SMP
 [  809.128608] last sysfs file: 
/sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq
 [  809.128612] CPU 0
 [  809.128614] Modules linked in: tcp_lp fuse coretemp hwmon_vid 
cpufreq_ondemand acpi_cpufreq freq_table mperf ip6t_REJECT nf_conntrack_ipv6 
ip6table_filter ip6_tables ipv6 xfs exportfs uinput mt2060 mxl5005s af9013 
dvb_usb_dib0700 ir_lirc_codec lirc_dev ir_sony_decoder ir_jvc_decoder dib7000p 
dib0090 dib7000m dvb_usb_af9015 dib0070 dvb_usb dib8000 dvb_core dib3000mc 
ir_rc6_decoder dibx000_common snd_hda_codec_intelhdmi ir_rc5_decoder 
snd_hda_codec_realtek snd_hda_intel ir_nec_decoder snd_hda_codec ldusb i2c_i801 
snd_hwdep snd_seq snd_seq_device rc_core atl1 asus_atk0110 snd_pcm snd_timer 
mii snd soundcore snd_page_alloc iTCO_wdt iTCO_vendor_support microcode raid456 
async_raid6_recov async_pq raid6_pq async_xor xor async_memcpy async_tx raid1 
ata_generic firewire_ohci pata_acpi firewire_core crc_itu_t pata_jmicron i915 
drm_kms_helper drm i2c_algo_bit i2c_core video output [last unloaded: 
scsi_wait_scan]
 [  809.128692]
 [  809.128696] Pid: 2525, comm: tzap Not tainted 2.6.35.10-72.fc14.x86_64 #1 
P5E-VM HDMI/P5E-VM HDMI
 [  809.128700] RIP: 0010:[a0013702]  [a0013702] 
i2c_transfer+0x16/0x124 [i2c_core]
 [  809.128708] RSP: 0018:880064a83ae8  EFLAGS: 00010296
 [  809.128712] RAX: 880064a83b58 RBX: 00eb RCX: 

 [  809.128715] RDX: 0002 RSI: 880064a83b38 RDI: 
0002
 [  809.128718] RBP: 880064a83b28 R08: 880079bcf7c0 R09: 
5d80
 [  809.128721] R10: 0005 R11: 4a38 R12: 
0001
 [  809.128725] R13:  R14: c900237e8000 R15: 
c90023907000
 [  809.128729] FS:  7f2ff2dd3720() GS:88000200() 
knlGS:
 [  809.128732] CS:  0010 DS:  ES:  CR0: 80050033
 [  809.128736] CR2: 0012 CR3: 7830d000 CR4: 
06f0
 [  809.128739] DR0:  DR1:  DR2: 

 [  809.128743] DR3:  DR6: 0ff0 DR7: 
0400
 [  809.128746] Process tzap (pid: 2525, threadinfo 880064a82000, task 
8800379745c0)
 [  809.128749] Stack:
 [  809.128751]  880064a83af8 8103c142 880079c41a90 
00eb
 [  809.128757] 0 0001  c900237e8000 
c90023907000
 [  809.128762] 0 880064a83b88 a0407124 00020030 
880064a83b68
 [  809.128768] Call Trace:
 [  809.128776]  [8103c142] ? need_resched+0x23/0x2d
 [  809.128783]  [a0407124] dib7000p_read_word+0x6d/0xbc [dib7000p]
 [  809.128789]  [813360eb] ? usb_submit_urb+0x2f8/0x33a
 [  809.128795]  [a0407ae5] dib7000p_pid_filter_ctrl+0x2d/0x90 
[dib7000p]
 [  809.128802]  [a044f35f] stk70x0p_pid_filter_ctrl+0x19/0x1e 
[dvb_usb_dib0700]
 [  809.128809]  [a03b4ef9] dvb_usb_ctrl_feed+0xd7/0x123 [dvb_usb]
 [  809.128815]  [a03b4f6a] dvb_usb_start_feed+0x13/0x15 [dvb_usb]
 [  809.128825]  [a035585c] dmx_ts_feed_start_filtering+0x7d/0xd1 
[dvb_core]
 [  809.128833]  [a03539fc] dvb_dmxdev_start_feed.clone.1+0xbd/0xeb 
[dvb_core]
 [  809.128841]  [a0353cf9] dvb_dmxdev_filter_start+0x2cf/0x31b 
[dvb_core]
 [  809.128847]  [81469b66] ? _raw_spin_lock_irq+0x1f/0x21
 [  809.128854]  [a035444b] dvb_demux_do_ioctl+0x27b/0x4c0 [dvb_core]
 [  809.128859]  [8103c15a] ? should_resched+0xe/0x2e
 [  809.128867]  [a03528f3] dvb_usercopy+0xe4/0x16b [dvb_core]
 [  809.128874]  [a03541d0] ? dvb_demux_do_ioctl+0x0/0x4c0 [dvb_core]
 [  809.128881]  [811e3718] ? inode_has_perm.clone.20+0x79/0x8f
 [  809.128886]  [810668ec] ? remove_wait_queue+0x35/0x41
 [  809.128891]  [81469b7f] ? _raw_spin_unlock_irqrestore+0x17/0x19
 [  809.128898]  [a0352fd1] dvb_demux_ioctl+0x15/0x19 [dvb_core]
 [  809.128903]  [8112419b] vfs_ioctl+0x36/0xa7
 [  809.128908]  [81124afc] do_vfs_ioctl+0x468/0x49b
 [  809.128912]  [81124b85] sys_ioctl+0x56/0x79
 [  809.128917]  [81009cf2] system_call_fastpath+0x16/0x1b
 [  809.128920] Code: 89 55 f8 48 83 c7 58 48 c7 c2 47 32 01 a0 e8 92 09 2c e1 c9 c3 
55 48 89 e5 41 57 41 56 41 55 41 54 53 48 83 ec 18 0f 1f 44 00 00 48 8b 47 10 
48 89 

[FIX for 2.6.37]

2010-11-28 Thread Patrick Boettcher
Hi Mauro,

please pull from

git://github.com/pboettch/linux-2.6.git  v2.6.37-fixes

for

flexcop-pci: sanitize driver name to avoid warning on load 


It fixes https://bugzilla.kernel.org/show_bug.cgi?id=15826 .

thanks and best regards,
--
Patrick Boettcher - KernelLabs
http://www.kernellabs.com/
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: tuner demodulator: Montage versus STMicroelectronics

2010-11-27 Thread Patrick Boettcher
On Saturday 27 November 2010 03:12:32 Zbigniew Luszpinski wrote:
 Hello,
 
 I'm going to buy my first DVB-S2 USB tuner.
 I see that there are two best demod/tuner solutions:
 1. Montage Technology M88TS2020/2 tuner and M88DS3000/2 demodulator
 2. STMicroelectronics STB6100 tuner and STV0903BAC demodulator
 Can you please tell me which is better for Linux user like me (STM or
 Montage)?

I haven't seen a driver for Montage in v4l-dvb.git, so your best choise is to 
go with the STV0903. But then it also depends whether the USB part of your 
device is supported already or not. 

What device are you think about?

regards,

--
Patrick
--
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 request for 2.6.37] Add Technisat SkyStar HD USB driver

2010-10-31 Thread Patrick Boettcher
On Sunday 17 October 2010 14:23:03 Mauro Carvalho Chehab wrote:
 Em 17-10-2010 10:50, Patrick Boettcher escreveu:
  Hi Mauro,
  
  please
  
  git pull git://github.com/pboettch/linux-2.6.git for_mauro
  
  for the following changes:
  
  technisat-usb2: added driver for Technisat's USB2.0 DVB-S/S2 receiver
  stv090x: add tei-field to config-structure
  stv090x: added function to control GPIOs from the outside
 
 Both stv090x patches seem ok to me.
 
  Thanks in advance for pulling and commenting,
 
 I have a few comments for the technisat-usb2:

Thanks for your comments, they were appreciated.

 [...]
  +static int technisat_usb2_debug;
  +module_param_named(debug, technisat_usb2_debug, int, 0644);
 
 As this is static, you could just name it as:
 
   static int debug;
 
 and use module_param() instead.

OK.

 
  +static struct i2c_algorithm technisat_usb2_i2c_algo = {
  +   .master_xfer   = technisat_usb2_i2c_xfer,
  +   .functionality = technisat_usb2_i2c_func,
  +
  +#ifdef NEED_ALGO_CONTROL
  +   .algo_control = dummy_algo_control,
  +#endif
 
 You don't need it. This is always false upstream.

OK.

 [...]
 Don't implement your own IR RC5 decoding logic. We have it already at IR
 core, and it is able to handle several protocols. Instead, just sent the
 raw events to RC core.
 
 See drivers/media/dvb/siano/smsir.c for an example on how to do it.

 [...]
 
 Also, don't put the RC tables at the driver. Move it to a separate file, at
 drivers/media/IR/keymaps/. This allows importing the RC keycodes by
 ir-keytable userspace tool (from v4l-utils.git).

Everythings' done. Ported to use ir-rc5-decoder. Rebased and squashed.

So, please pull now from:

git pull git://github.com/pboettch/linux-2.6.git for_mauro

thanks in advance and best regards,

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


[GIT PULL request for 2.6.37] Add Technisat SkyStar HD USB driver

2010-10-17 Thread Patrick Boettcher
Hi Mauro,

please 

git pull git://github.com/pboettch/linux-2.6.git for_mauro

for the following changes:

technisat-usb2: added driver for Technisat's USB2.0 DVB-S/S2 receiver
stv090x: add tei-field to config-structure
stv090x: added function to control GPIOs from the outside

Those are intended for 2.6.37 and have been rebased today on linuxtv's 
staging/2.6.37-branch.

The development of the new technisat-usb2-driver has been sponsored by 
Technisat UK.


Thanks in advance for pulling and commenting,
--
Patrick Boettcher - KernelLabs
http://www.kernellabs.com/
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


  1   2   >