Re: [PATCH/RFC v4 00/21] LED / flash API integration

[Jacek Anaszewski]

Hi Bryan,

On 07/16/2014 07:21 PM, Bryan Wu wrote:

On Wed, Jul 16, 2014 at 10:19 AM, Bryan Wu  wrote:

On Fri, Jul 11, 2014 at 7:04 AM, Jacek Anaszewski
 wrote:

This is is the fourth version of the patch series being a follow up
of the discussion on Media summit 2013-10-23, related to the
LED / flash API integration (the notes from the discussion were
enclosed in the message [1], paragraph 5).
The series is based on linux-next-20140707



I really apologize that I missed your discussion email in my Gmail
inbox, it was archived some where. Even in this series some of these
patches are archived in different tab.

I will start to review and help to push this.



In the mean time, could you please provide an git tree for me to pull?
It's much easier for me to review in my git.


Few days ago I sent to your private email the path to the git
repository to pull, but I am resending it through the lists to
make sure that it will not get filtered somehow again.

git://linuxtv.org/snawrocki/samsung.git
branch: led_flash_integration_v4

gitweb:
http://git.linuxtv.org/cgit.cgi/snawrocki/samsung.git/log/?h=led_flash_integration_v4

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

[PATCH 3/4 v3] support for DVBSky dvb-s2 usb: add dvb-usb-v2 driver for DVBSky dvb-s2 box, no ci support.

[nibble.max]

remove ci support part in v1 patch.
hook demod read status and set voltage operations.
add m88ts2022 select in Kconfig.

Signed-off-by: Nibble Max 
---
 drivers/media/usb/dvb-usb-v2/Kconfig  |   7 +
 drivers/media/usb/dvb-usb-v2/Makefile |   3 +
 drivers/media/usb/dvb-usb-v2/dvbsky.c | 455 ++
 3 files changed, 465 insertions(+)

diff --git a/drivers/media/usb/dvb-usb-v2/Kconfig 
b/drivers/media/usb/dvb-usb-v2/Kconfig
index 66645b0..5b34323 100644
--- a/drivers/media/usb/dvb-usb-v2/Kconfig
+++ b/drivers/media/usb/dvb-usb-v2/Kconfig
@@ -141,3 +141,10 @@ config DVB_USB_RTL28XXU
help
  Say Y here to support the Realtek RTL28xxU DVB USB receiver.
 
+config DVB_USB_DVBSKY
+   tristate "DVBSky USB support"
+   depends on DVB_USB_V2
+   select DVB_M88DS3103 if MEDIA_SUBDRV_AUTOSELECT
+   select MEDIA_TUNER_M88TS2022 if MEDIA_SUBDRV_AUTOSELECT
+   help
+ Say Y here to support the USB receivers from DVBSky.
diff --git a/drivers/media/usb/dvb-usb-v2/Makefile 
b/drivers/media/usb/dvb-usb-v2/Makefile
index bc38f03..f10d4df 100644
--- a/drivers/media/usb/dvb-usb-v2/Makefile
+++ b/drivers/media/usb/dvb-usb-v2/Makefile
@@ -37,6 +37,9 @@ obj-$(CONFIG_DVB_USB_MXL111SF) += mxl111sf-tuner.o
 dvb-usb-rtl28xxu-objs := rtl28xxu.o
 obj-$(CONFIG_DVB_USB_RTL28XXU) += dvb-usb-rtl28xxu.o
 
+dvb-usb-dvbsky-objs := dvbsky.o
+obj-$(CONFIG_DVB_USB_DVBSKY) += dvb-usb-dvbsky.o
+
 ccflags-y += -I$(srctree)/drivers/media/dvb-core
 ccflags-y += -I$(srctree)/drivers/media/dvb-frontends
 ccflags-y += -I$(srctree)/drivers/media/tuners
diff --git a/drivers/media/usb/dvb-usb-v2/dvbsky.c 
b/drivers/media/usb/dvb-usb-v2/dvbsky.c
new file mode 100644
index 000..2db363e
--- /dev/null
+++ b/drivers/media/usb/dvb-usb-v2/dvbsky.c
@@ -0,0 +1,455 @@
+/*
+ * Driver for DVBSky USB2.0 receiver
+ *
+ * Copyright (C) 2013 Max nibble 
+ *
+ *This program is free software; you can redistribute it and/or modify
+ *it under the terms of the GNU General Public License as published by
+ *the Free Software Foundation; either version 2 of the License, or
+ *(at your option) any later version.
+ *
+ *This program is distributed in the hope that it will be useful,
+ *but WITHOUT ANY WARRANTY; without even the implied warranty of
+ *MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ *GNU General Public License for more details.
+ *
+ *You should have received a copy of the GNU General Public License
+ *along with this program; if not, write to the Free Software
+ *Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
+ */
+
+#include "dvb_usb.h"
+#include "m88ds3103.h"
+#include "m88ts2022.h"
+
+static int dvbsky_debug;
+module_param(dvbsky_debug, int, 0644);
+MODULE_PARM_DESC(dvbsky_debug, "Activates dvbsky usb debugging (default:0)");
+
+#define DVBSKY_MSG_DELAY   0/*2000*/
+
+#define dprintk(args...) \
+   do { \
+   if (dvbsky_debug) \
+   printk(KERN_INFO "dvbsky_usb: " args); \
+   } while (0)
+
+DVB_DEFINE_MOD_OPT_ADAPTER_NR(adapter_nr);
+
+struct dvbsky_state {
+   struct mutex stream_mutex;
+   u8 last_lock;
+   struct i2c_client *i2c_client_tuner;
+   int (*fe_set_voltage)(struct dvb_frontend *fe,
+   fe_sec_voltage_t voltage);
+   int (*fe_read_status)(struct dvb_frontend *fe,
+   fe_status_t *status);
+};
+
+static int dvbsky_stream_ctrl(struct dvb_usb_device *d, u8 onoff)
+{
+   struct dvbsky_state *state = d_to_priv(d);
+   int ret;
+   u8 obuf_pre[3] = { 0x37, 0, 0 };
+   u8 obuf_post[3] = { 0x36, 3, 0 };
+   dprintk("%s() -off \n", __func__);
+   mutex_lock(&state->stream_mutex);
+   ret = dvb_usbv2_generic_write(d, obuf_pre, 3);
+   if (!ret && onoff) {
+   msleep(10);
+   ret = dvb_usbv2_generic_write(d, obuf_post, 3);
+   dprintk("%s() -on \n", __func__);
+   }
+   mutex_unlock(&state->stream_mutex);
+   return ret;
+}
+
+static int dvbsky_streaming_ctrl(struct dvb_frontend *fe, int onoff)
+{
+   struct dvb_usb_device *d = fe_to_d(fe);
+   /*dprintk("%s() %d\n", __func__, onoff);*/
+   return dvbsky_stream_ctrl(d, (onoff == 0) ? 0 : 1);
+}
+
+/* GPIO */
+static int dvbsky_gpio_ctrl(struct dvb_usb_device *d, u8 gport, u8 value)
+{
+   int ret;
+   u8 obuf[64], ibuf[64];
+   obuf[0] = 0x0e;
+   obuf[1] = gport;
+   obuf[2] = value;
+   ret = dvb_usbv2_generic_rw(d, obuf, 3, ibuf, 1);
+   if (ret)
+   dev_err(&d->udev->dev, "%s: %s() " \
+   "failed=%d\n", KBUILD_MODNAME, __func__, ret);
+   return ret;
+}
+
+/* I2C */
+static int dvbsky_i2c_xfer(struct i2c_adapter *adap, struct i2c_msg msg[],
+   int num)
+{
+   struct dvb_usb_device *d = i2c_get_adapdata(adap);
+   int ret = 0;
+   u8 ibuf[64], obuf[64];
+
+   if (mutex_lock_interruptible(&d->i2c_mu

Re: Re: [PATCH 3/4] support for DVBSky dvb-s2 usb: add dvb-usb-v2 driver for DVBSky dvb-s2 box

[nibble.max]

Hello Olli,
>Hi Max,
>
>nibble.max  gmail.com> writes:
>> diff --git a/drivers/media/usb/dvb-usb-v2/Kconfig
>b/drivers/media/usb/dvb-usb-v2/Kconfig
>> index 66645b0..8107c8d 100644
>> --- a/drivers/media/usb/dvb-usb-v2/Kconfig
>> +++ b/drivers/media/usb/dvb-usb-v2/Kconfig
>>  -141,3 +141,9  config DVB_USB_RTL28XXU
>>  help
>>Say Y here to support the Realtek RTL28xxU DVB USB receiver.
>> 
>> +config DVB_USB_DVBSKY
>> +tristate "DVBSky USB support"
>> +depends on DVB_USB_V2
>> +select DVB_M88DS3103 if MEDIA_SUBDRV_AUTOSELECT
>> +help
>> +  Say Y here to support the USB receivers from DVBSky.
>
>Shouldn't the MEDIA_TUNER_M88TS2022 also be selected in Kconfig?
Yes, I miss it. It should be selected in Kconfig.
Thanks.
>
>Cheers,
>-olli
>
>
>
>--
>To unsubscribe from this list: send the line "unsubscribe linux-media" in
>the body of a message to majord...@vger.kernel.org
>More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

Re: [PATCH 3/4] support for DVBSky dvb-s2 usb: add dvb-usb-v2 driver for DVBSky dvb-s2 box

[Olli Salonen]

Hi Max,

nibble.max  gmail.com> writes:
> diff --git a/drivers/media/usb/dvb-usb-v2/Kconfig
b/drivers/media/usb/dvb-usb-v2/Kconfig
> index 66645b0..8107c8d 100644
> --- a/drivers/media/usb/dvb-usb-v2/Kconfig
> +++ b/drivers/media/usb/dvb-usb-v2/Kconfig
>  -141,3 +141,9  config DVB_USB_RTL28XXU
>   help
> Say Y here to support the Realtek RTL28xxU DVB USB receiver.
> 
> +config DVB_USB_DVBSKY
> + tristate "DVBSky USB support"
> + depends on DVB_USB_V2
> + select DVB_M88DS3103 if MEDIA_SUBDRV_AUTOSELECT
> + help
> +   Say Y here to support the USB receivers from DVBSky.

Shouldn't the MEDIA_TUNER_M88TS2022 also be selected in Kconfig?

Cheers,
-olli



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

[PATCH 3/4 v2] support for DVBSky dvb-s2 usb: add dvb-usb-v2 driver for DVBSky dvb-s2 box, no ci support.

[nibble.max]

remove ci support part in v1 patch.
hook demod read status and set voltage operations.

Signed-off-by: Nibble Max 
---
 drivers/media/usb/dvb-usb-v2/Kconfig  |   6 +
 drivers/media/usb/dvb-usb-v2/Makefile |   3 +
 drivers/media/usb/dvb-usb-v2/dvbsky.c | 455 ++
 3 files changed, 464 insertions(+)

diff --git a/drivers/media/usb/dvb-usb-v2/Kconfig 
b/drivers/media/usb/dvb-usb-v2/Kconfig
index 66645b0..8107c8d 100644
--- a/drivers/media/usb/dvb-usb-v2/Kconfig
+++ b/drivers/media/usb/dvb-usb-v2/Kconfig
@@ -141,3 +141,9 @@ config DVB_USB_RTL28XXU
help
  Say Y here to support the Realtek RTL28xxU DVB USB receiver.
 
+config DVB_USB_DVBSKY
+   tristate "DVBSky USB support"
+   depends on DVB_USB_V2
+   select DVB_M88DS3103 if MEDIA_SUBDRV_AUTOSELECT
+   help
+ Say Y here to support the USB receivers from DVBSky.
diff --git a/drivers/media/usb/dvb-usb-v2/Makefile 
b/drivers/media/usb/dvb-usb-v2/Makefile
index bc38f03..f10d4df 100644
--- a/drivers/media/usb/dvb-usb-v2/Makefile
+++ b/drivers/media/usb/dvb-usb-v2/Makefile
@@ -37,6 +37,9 @@ obj-$(CONFIG_DVB_USB_MXL111SF) += mxl111sf-tuner.o
 dvb-usb-rtl28xxu-objs := rtl28xxu.o
 obj-$(CONFIG_DVB_USB_RTL28XXU) += dvb-usb-rtl28xxu.o
 
+dvb-usb-dvbsky-objs := dvbsky.o
+obj-$(CONFIG_DVB_USB_DVBSKY) += dvb-usb-dvbsky.o
+
 ccflags-y += -I$(srctree)/drivers/media/dvb-core
 ccflags-y += -I$(srctree)/drivers/media/dvb-frontends
 ccflags-y += -I$(srctree)/drivers/media/tuners
diff --git a/drivers/media/usb/dvb-usb-v2/dvbsky.c 
b/drivers/media/usb/dvb-usb-v2/dvbsky.c
new file mode 100644
index 000..2db363e
--- /dev/null
+++ b/drivers/media/usb/dvb-usb-v2/dvbsky.c
@@ -0,0 +1,455 @@
+/*
+ * Driver for DVBSky USB2.0 receiver
+ *
+ * Copyright (C) 2013 Max nibble 
+ *
+ *This program is free software; you can redistribute it and/or modify
+ *it under the terms of the GNU General Public License as published by
+ *the Free Software Foundation; either version 2 of the License, or
+ *(at your option) any later version.
+ *
+ *This program is distributed in the hope that it will be useful,
+ *but WITHOUT ANY WARRANTY; without even the implied warranty of
+ *MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ *GNU General Public License for more details.
+ *
+ *You should have received a copy of the GNU General Public License
+ *along with this program; if not, write to the Free Software
+ *Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
+ */
+
+#include "dvb_usb.h"
+#include "m88ds3103.h"
+#include "m88ts2022.h"
+
+static int dvbsky_debug;
+module_param(dvbsky_debug, int, 0644);
+MODULE_PARM_DESC(dvbsky_debug, "Activates dvbsky usb debugging (default:0)");
+
+#define DVBSKY_MSG_DELAY   0/*2000*/
+
+#define dprintk(args...) \
+   do { \
+   if (dvbsky_debug) \
+   printk(KERN_INFO "dvbsky_usb: " args); \
+   } while (0)
+
+DVB_DEFINE_MOD_OPT_ADAPTER_NR(adapter_nr);
+
+struct dvbsky_state {
+   struct mutex stream_mutex;
+   u8 last_lock;
+   struct i2c_client *i2c_client_tuner;
+   int (*fe_set_voltage)(struct dvb_frontend *fe,
+   fe_sec_voltage_t voltage);
+   int (*fe_read_status)(struct dvb_frontend *fe,
+   fe_status_t *status);
+};
+
+static int dvbsky_stream_ctrl(struct dvb_usb_device *d, u8 onoff)
+{
+   struct dvbsky_state *state = d_to_priv(d);
+   int ret;
+   u8 obuf_pre[3] = { 0x37, 0, 0 };
+   u8 obuf_post[3] = { 0x36, 3, 0 };
+   dprintk("%s() -off \n", __func__);
+   mutex_lock(&state->stream_mutex);
+   ret = dvb_usbv2_generic_write(d, obuf_pre, 3);
+   if (!ret && onoff) {
+   msleep(10);
+   ret = dvb_usbv2_generic_write(d, obuf_post, 3);
+   dprintk("%s() -on \n", __func__);
+   }
+   mutex_unlock(&state->stream_mutex);
+   return ret;
+}
+
+static int dvbsky_streaming_ctrl(struct dvb_frontend *fe, int onoff)
+{
+   struct dvb_usb_device *d = fe_to_d(fe);
+   /*dprintk("%s() %d\n", __func__, onoff);*/
+   return dvbsky_stream_ctrl(d, (onoff == 0) ? 0 : 1);
+}
+
+/* GPIO */
+static int dvbsky_gpio_ctrl(struct dvb_usb_device *d, u8 gport, u8 value)
+{
+   int ret;
+   u8 obuf[64], ibuf[64];
+   obuf[0] = 0x0e;
+   obuf[1] = gport;
+   obuf[2] = value;
+   ret = dvb_usbv2_generic_rw(d, obuf, 3, ibuf, 1);
+   if (ret)
+   dev_err(&d->udev->dev, "%s: %s() " \
+   "failed=%d\n", KBUILD_MODNAME, __func__, ret);
+   return ret;
+}
+
+/* I2C */
+static int dvbsky_i2c_xfer(struct i2c_adapter *adap, struct i2c_msg msg[],
+   int num)
+{
+   struct dvb_usb_device *d = i2c_get_adapdata(adap);
+   int ret = 0;
+   u8 ibuf[64], obuf[64];
+
+   if (mutex_lock_interruptible(&d->i2c_mutex) < 0)
+   return -EAGAIN;
+
+   if (num > 2) {
+   printk(KERN_ERR

[PATCH 1/4 v2] support for DVBSky dvb-s2 usb: Add ts clock and clock polarity, lnb set voltage for m88ds3103

[nibble.max]

Add ts clock and clock polarity, lnb set voltage.

Signed-off-by: Nibble Max 
---
 drivers/media/dvb-frontends/m88ds3103.c | 77 +
 drivers/media/dvb-frontends/m88ds3103.h | 25 ---
 2 files changed, 70 insertions(+), 32 deletions(-)

diff --git a/drivers/media/dvb-frontends/m88ds3103.c 
b/drivers/media/dvb-frontends/m88ds3103.c
index dfe0c2f..142f9a6 100644
--- a/drivers/media/dvb-frontends/m88ds3103.c
+++ b/drivers/media/dvb-frontends/m88ds3103.c
@@ -247,7 +247,7 @@ static int m88ds3103_set_frontend(struct dvb_frontend *fe)
u8 u8tmp, u8tmp1, u8tmp2;
u8 buf[2];
u16 u16tmp, divide_ratio;
-   u32 tuner_frequency, target_mclk, ts_clk;
+   u32 tuner_frequency, target_mclk;
s32 s32tmp;
dev_dbg(&priv->i2c->dev,
"%s: delivery_system=%d modulation=%d frequency=%d 
symbol_rate=%d inversion=%d pilot=%d rolloff=%d\n",
@@ -316,9 +316,6 @@ static int m88ds3103_set_frontend(struct dvb_frontend *fe)
target_mclk = 144000;
break;
case M88DS3103_TS_PARALLEL:
-   case M88DS3103_TS_PARALLEL_12:
-   case M88DS3103_TS_PARALLEL_16:
-   case M88DS3103_TS_PARALLEL_19_2:
case M88DS3103_TS_CI:
if (c->symbol_rate < 1800)
target_mclk = 96000;
@@ -352,33 +349,17 @@ static int m88ds3103_set_frontend(struct dvb_frontend *fe)
switch (priv->cfg->ts_mode) {
case M88DS3103_TS_SERIAL:
u8tmp1 = 0x00;
-   ts_clk = 0;
-   u8tmp = 0x46;
+   u8tmp = 0x06;
break;
case M88DS3103_TS_SERIAL_D7:
u8tmp1 = 0x20;
-   ts_clk = 0;
-   u8tmp = 0x46;
+   u8tmp = 0x06;
break;
case M88DS3103_TS_PARALLEL:
-   ts_clk = 24000;
-   u8tmp = 0x42;
-   break;
-   case M88DS3103_TS_PARALLEL_12:
-   ts_clk = 12000;
-   u8tmp = 0x42;
-   break;
-   case M88DS3103_TS_PARALLEL_16:
-   ts_clk = 16000;
-   u8tmp = 0x42;
-   break;
-   case M88DS3103_TS_PARALLEL_19_2:
-   ts_clk = 19200;
-   u8tmp = 0x42;
+   u8tmp = 0x02;
break;
case M88DS3103_TS_CI:
-   ts_clk = 6000;
-   u8tmp = 0x43;
+   u8tmp = 0x03;
break;
default:
dev_dbg(&priv->i2c->dev, "%s: invalid ts_mode\n", __func__);
@@ -386,6 +367,9 @@ static int m88ds3103_set_frontend(struct dvb_frontend *fe)
goto err;
}
 
+   if (priv->cfg->ts_clk_pol)
+   u8tmp |= 0x40;
+
/* TS mode */
ret = m88ds3103_wr_reg(priv, 0xfd, u8tmp);
if (ret)
@@ -399,8 +383,8 @@ static int m88ds3103_set_frontend(struct dvb_frontend *fe)
goto err;
}
 
-   if (ts_clk) {
-   divide_ratio = DIV_ROUND_UP(target_mclk, ts_clk);
+   if (priv->cfg->ts_clk) {
+   divide_ratio = DIV_ROUND_UP(target_mclk, priv->cfg->ts_clk);
u8tmp1 = divide_ratio / 2;
u8tmp2 = DIV_ROUND_UP(divide_ratio, 2);
} else {
@@ -411,7 +395,7 @@ static int m88ds3103_set_frontend(struct dvb_frontend *fe)
 
dev_dbg(&priv->i2c->dev,
"%s: target_mclk=%d ts_clk=%d divide_ratio=%d\n",
-   __func__, target_mclk, ts_clk, divide_ratio);
+   __func__, target_mclk, priv->cfg->ts_clk, divide_ratio);
 
u8tmp1--;
u8tmp2--;
@@ -1053,6 +1037,44 @@ err:
return ret;
 }
 
+static int m88ds3103_set_voltage(struct dvb_frontend *fe,
+   fe_sec_voltage_t voltage)
+{
+   struct m88ds3103_priv *priv = fe->demodulator_priv;
+   u8 data;
+
+   dev_dbg(&priv->i2c->dev, "%s: pin_ctrl = (%02x)\n",
+   __func__, priv->cfg->pin_ctrl);
+
+   m88ds3103_rd_reg(priv, 0xa2, &data);
+
+   if (priv->cfg->pin_ctrl & 0x80) { /*If control pin is assigned.*/
+   data &= ~0x03; /* bit0 V/H, bit1 off/on */
+   if (priv->cfg->pin_ctrl & 0x02)
+   data |= 0x02;
+
+   switch (voltage) {
+   case SEC_VOLTAGE_18:
+if ((priv->cfg->pin_ctrl & 0x01) == 0)
+   data |= 0x01;
+break;
+   case SEC_VOLTAGE_13:
+if (priv->cfg->pin_ctrl & 0x01)
+   data |= 0x01;
+break;
+   case SEC_VOLTAGE_OFF:
+if (priv->cfg->pin_ctrl & 0x02)
+   data &= ~0x02;
+else
+   data |= 0x02;
+break;
+   }
+   }
+   m88ds3103_wr_reg(p

3.15.8 USB issue with uvc cam

[Udo van den Heuvel]

Hello,

I get WARNINGs when trying to use a Logitech C615 cam.
See attachment for full dmesg of errors but excerpt below:

[80346.835015] xhci_hcd :02:00.0: ERROR: unexpected command
completion code 0x11.
[80346.835027] usb 6-2: Not enough bandwidth for altsetting 11
[80346.835137] [ cut here ]
[80346.835155] WARNING: CPU: 3 PID: 20594 at
drivers/media/v4l2-core/videobuf2-core.c:2011
__vb2_queue_cancel+0x102/0x170 [videobuf2_core]()
[80346.835158] Modules linked in: uvcvideo cdc_acm bnep bluetooth fuse
edac_core cpufreq_userspace ipt_REJECT nf_conntrack_netbios_ns
nf_conntrack_broadcast iptable_filter ip6t_REJECT ipt_MASQUERADE
xt_tcpudp nf_conntrack_ipv6 iptable_nat nf_defrag_ipv6 nf_conntrack_ipv4
nf_defrag_ipv4 nf_nat_ipv4 nf_nat xt_conntrack nf_conntrack ip_tables
ip6table_filter ip6_tables x_tables eeprom it87 hwmon_vid ext2
snd_usb_audio snd_usbmidi_lib snd_hwdep snd_rawmidi ppdev pwc
videobuf2_vmalloc videobuf2_memops kvm_amd kvm v4l2_common
videobuf2_core snd_hda_codec_realtek snd_hda_codec_generic videodev
snd_hda_intel snd_hda_controller cp210x snd_hda_codec usbserial snd_seq
snd_seq_device microcode snd_pcm parport_serial parport_pc parport
snd_timer k10temp snd evdev i2c_piix4 button acpi_cpufreq nfsd
auth_rpcgss oid_registry
[80346.835218]  nfs_acl lockd sunrpc binfmt_misc autofs4 hid_generic
usbhid ohci_pci ehci_pci ehci_hcd ohci_hcd radeon sr_mod cdrom fbcon
bitblit cfbfillrect softcursor cfbimgblt cfbcopyarea font i2c_algo_bit
xhci_hcd backlight drm_kms_helper ttm drm fb fbdev
[80346.835250] CPU: 3 PID: 20594 Comm: skype Tainted: GW
3.15.8 #6
[80346.835254] Hardware name: Gigabyte Technology Co., Ltd. To be filled
by O.E.M./F2A85X-UP4, BIOS F5a 04/30/2013
[80346.835257]   79d580f4 814f2373

[80346.835262]  81069fe1  88040ec532e8

[80346.835267]  88040ec530d8 8803f0c46f00 a041d832
88040ec530d8
[80346.835272] Call Trace:
[80346.835283]  [] ? dump_stack+0x4a/0x75
[80346.835289]  [] ? warn_slowpath_common+0x81/0xb0
[80346.835299]  [] ? __vb2_queue_cancel+0x102/0x170
[videobuf2_core]
[80346.835307]  [] ? vb2_internal_streamoff+0x1d/0x50
[videobuf2_core]
[80346.835314]  [] ? uvc_queue_enable+0x75/0xb0 [uvcvideo]
[80346.835321]  [] ? uvc_video_enable+0x141/0x1a0
[uvcvideo]
[80346.835327]  [] ? uvc_v4l2_do_ioctl+0xd6f/0x1580
[uvcvideo]
[80346.835339]  [] ? video_usercopy+0x1f0/0x490 [videodev]
[80346.835345]  [] ?
uvc_v4l2_set_streamparm.isra.12+0x1c0/0x1c0 [uvcvideo]
[80346.835352]  [] ? preempt_count_add+0x3f/0x90
[80346.835356]  [] ? _raw_spin_lock+0xe/0x30
[80346.835360]  [] ? _raw_spin_unlock+0xd/0x30
[80346.835367]  [] ? __pte_alloc+0xce/0x170
[80346.835376]  [] ? v4l2_ioctl+0x11f/0x160 [videodev]
[80346.835386]  [] ? do_video_ioctl+0x246/0x1330
[videodev]
[80346.835392]  [] ? mmap_region+0x15a/0x5a0
[80346.835402]  [] ? v4l2_compat_ioctl32+0x82/0xb8
[videodev]
[80346.835408]  [] ? compat_SyS_ioctl+0x132/0x1120
[80346.835414]  [] ? vm_mmap_pgoff+0xe3/0x120
[80346.835421]  [] ? cstar_dispatch+0x7/0x1a
[80346.835424] ---[ end trace 44e3d272b6c91a71 ]---
[80346.835427] [ cut here ]


What is wrong here?

Kind regards,
Udo


[80346.835015] xhci_hcd :02:00.0: ERROR: unexpected command completion code 
0x11.
[80346.835027] usb 6-2: Not enough bandwidth for altsetting 11
[80346.835137] [ cut here ]
[80346.835155] WARNING: CPU: 3 PID: 20594 at 
drivers/media/v4l2-core/videobuf2-core.c:2011 __vb2_queue_cancel+0x102/0x170 
[videobuf2_core]()
[80346.835158] Modules linked in: uvcvideo cdc_acm bnep bluetooth fuse 
edac_core cpufreq_userspace ipt_REJECT nf_conntrack_netbios_ns 
nf_conntrack_broadcast iptable_filter ip6t_REJECT ipt_MASQUERADE xt_tcpudp 
nf_conntrack_ipv6 iptable_nat nf_defrag_ipv6 nf_conntrack_ipv4 nf_defrag_ipv4 
nf_nat_ipv4 nf_nat xt_conntrack nf_conntrack ip_tables ip6table_filter 
ip6_tables x_tables eeprom it87 hwmon_vid ext2 snd_usb_audio snd_usbmidi_lib 
snd_hwdep snd_rawmidi ppdev pwc videobuf2_vmalloc videobuf2_memops kvm_amd kvm 
v4l2_common videobuf2_core snd_hda_codec_realtek snd_hda_codec_generic videodev 
snd_hda_intel snd_hda_controller cp210x snd_hda_codec usbserial snd_seq 
snd_seq_device microcode snd_pcm parport_serial parport_pc parport snd_timer 
k10temp snd evdev i2c_piix4 button acpi_cpufreq nfsd auth_rpcgss oid_registry
[80346.835218]  nfs_acl lockd sunrpc binfmt_misc autofs4 hid_generic usbhid 
ohci_pci ehci_pci ehci_hcd ohci_hcd radeon sr_mod cdrom fbcon bitblit 
cfbfillrect softcursor cfbimgblt cfbcopyarea font i2c_algo_bit xhci_hcd 
backlight drm_kms_helper ttm drm fb fbdev
[80346.835250] CPU: 3 PID: 20594 Comm: skype Tainted: GW 3.15.8 #6
[80346.835254] Hardware name: Gigabyte Technology Co., Ltd. To be filled by 
O.E.M./F2A85X-UP4, BIOS F5a 04/30/2013
[80346.835257]   79d580f4 814f2373 

[80346.835262]  f

Re: Re: [PATCH 3/4] support for DVBSky dvb-s2 usb: add dvb-usb-v2 driverfor DVBSky dvb-s2 box

[nibble.max]

Moikka!
>Moikka!
>Biggest issue is that CIMax2 SP2 driver. Olli put all that stuff to own
>I2C driver recently. Could you took SP2 from patchwork and use it instead:
>https://patchwork.linuxtv.org/patch/25206/
>https://patchwork.linuxtv.org/patch/25210/
Yes, the CIMax2 SP2 code here is the same as Olli's.
But Olli comes to make a standard i2c driver, so I will remove the ci code from 
dvbsky usb driver.
As Olli finish the code ready, I will use his code for ci part.
>
>It is not yet in mainline, but there should not be any big changes
>coming to that driver.
>
>regards
>Antti
>
>On 08/06/2014 07:36 AM, nibble.max wrote:
>> add dvb-usb-v2 driver for DVBSky dvb-s2 box
>> 
>> Signed-off-by: Nibble Max 
>> ---
>>   drivers/media/usb/dvb-usb-v2/Kconfig  |   6 +
>>   drivers/media/usb/dvb-usb-v2/Makefile |   3 +
>>   drivers/media/usb/dvb-usb-v2/dvbsky.c | 872 
>> ++
>>   3 files changed, 881 insertions(+)
>> 
>> diff --git a/drivers/media/usb/dvb-usb-v2/Kconfig 
>> b/drivers/media/usb/dvb-usb-v2/Kconfig
>> index 66645b0..8107c8d 100644
>> --- a/drivers/media/usb/dvb-usb-v2/Kconfig
>> +++ b/drivers/media/usb/dvb-usb-v2/Kconfig
>> @@ -141,3 +141,9 @@ config DVB_USB_RTL28XXU
>>  help
>>Say Y here to support the Realtek RTL28xxU DVB USB receiver.
>>   
>> +config DVB_USB_DVBSKY
>> +tristate "DVBSky USB support"
>> +depends on DVB_USB_V2
>> +select DVB_M88DS3103 if MEDIA_SUBDRV_AUTOSELECT
>> +help
>> +  Say Y here to support the USB receivers from DVBSky.
>> diff --git a/drivers/media/usb/dvb-usb-v2/Makefile 
>> b/drivers/media/usb/dvb-usb-v2/Makefile
>> index bc38f03..f10d4df 100644
>> --- a/drivers/media/usb/dvb-usb-v2/Makefile
>> +++ b/drivers/media/usb/dvb-usb-v2/Makefile
>> @@ -37,6 +37,9 @@ obj-$(CONFIG_DVB_USB_MXL111SF) += mxl111sf-tuner.o
>>   dvb-usb-rtl28xxu-objs := rtl28xxu.o
>>   obj-$(CONFIG_DVB_USB_RTL28XXU) += dvb-usb-rtl28xxu.o
>>   
>> +dvb-usb-dvbsky-objs := dvbsky.o
>> +obj-$(CONFIG_DVB_USB_DVBSKY) += dvb-usb-dvbsky.o
>> +
>>   ccflags-y += -I$(srctree)/drivers/media/dvb-core
>>   ccflags-y += -I$(srctree)/drivers/media/dvb-frontends
>>   ccflags-y += -I$(srctree)/drivers/media/tuners
>> diff --git a/drivers/media/usb/dvb-usb-v2/dvbsky.c 
>> b/drivers/media/usb/dvb-usb-v2/dvbsky.c
>> new file mode 100644
>> index 000..c86927f
>> --- /dev/null
>> +++ b/drivers/media/usb/dvb-usb-v2/dvbsky.c
>> @@ -0,0 +1,872 @@
>> +/*
>> + * Driver for DVBSky USB2.0 receiver
>> + *
>> + * Copyright (C) 2013 Max nibble 
>> + *
>> + * CIMax code is copied and modified from:
>> + * CIMax2(R) SP2 driver in conjunction with NetUp Dual DVB-S2 CI card
>> + * Copyright (C) 2009 NetUP Inc.
>> + * Copyright (C) 2009 Igor M. Liplianin 
>> + * Copyright (C) 2009 Abylay Ospan 
>> + *
>> + *This program is free software; you can redistribute it and/or modify
>> + *it under the terms of the GNU General Public License as published by
>> + *the Free Software Foundation; either version 2 of the License, or
>> + *(at your option) any later version.
>> + *
>> + *This program is distributed in the hope that it will be useful,
>> + *but WITHOUT ANY WARRANTY; without even the implied warranty of
>> + *MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
>> + *GNU General Public License for more details.
>> + *
>> + *You should have received a copy of the GNU General Public License
>> + *along with this program; if not, write to the Free Software
>> + *Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
>> + */
>> +
>> +#include "dvb_ca_en50221.h"
>> +#include "dvb_usb.h"
>> +#include "m88ds3103.h"
>> +#include "m88ts2022.h"
>> +
>> +static int dvbsky_debug;
>> +module_param(dvbsky_debug, int, 0644);
>> +MODULE_PARM_DESC(dvbsky_debug, "Activates dvbsky usb debugging 
>> (default:0)");
>> +
>> +#define DVBSKY_MSG_DELAY0/*2000*/
>> +#define DVBSKY_CI_CTL   0x04
>> +#define DVBSKY_CI_RD1
>> +
>> +#define dprintk(args...) \
>> +do { \
>> +if (dvbsky_debug) \
>> +printk(KERN_INFO "dvbsky_usb: " args); \
>> +} while (0)
>> +
>> +DVB_DEFINE_MOD_OPT_ADAPTER_NR(adapter_nr);
>> +
>> +struct dvbsky_state {
>> +struct mutex stream_mutex;
>> +u8 has_ci;
>> +u8 ci_attached;
>> +struct dvb_ca_en50221 ci;
>> +unsigned long next_status_checked_time;
>> +u8 ci_i2c_addr;
>> +u8 current_ci_flag;
>> +int ci_status;
>> +struct i2c_client *i2c_client_tuner;
>> +};
>> +
>> +static int dvbsky_stream_ctrl(struct dvb_usb_device *d, u8 onoff)
>> +{
>> +struct dvbsky_state *state = d_to_priv(d);
>> +int ret;
>> +u8 obuf_pre[3] = { 0x37, 0, 0 };
>> +u8 obuf_post[3] = { 0x36, 3, 0 };
>> +dprintk("%s() -off \n", __func__);
>> +mutex_lock(&state->stream_mutex);
>> +ret = dvb_usbv2_generic_write(d, obuf_pre, 3);
>> +if (!ret && onoff) {
>> +msleep(10);
>> +ret = dvb_usbv2_generic_write(d

cron job: media_tree daily build: WARNINGS

[Hans Verkuil]

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

Results of the daily build of media_tree:

date:   Fri Aug  8 04:00:28 CEST 2014
git branch: test
git hash:   0f3bf3dc1ca394a8385079a5653088672b65c5c4
gcc version:i686-linux-gcc (GCC) 4.9.1
sparse version: v0.5.0-16-g1db35d0
host hardware:  x86_64
host os:3.15-7.slh.3-amd64

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

Detailed results are available here:

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

Full logs are available here:

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

The Media Infrastructure API from this daily build is here:

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

Re: [media:v4l_for_linus 393/499] tuner-core.c:undefined reference to `xc5000_attach'

[Antti Palosaari]

Mauro,
could you look that one? There is now multiple reports for ~all those 
silicon tuners which are used by tuner.ko module (CONFIG MEDIA_TUNER). 
Even it blames SDR Kconfig tuner patch I made, it is not the real issue. 
In my understanding issue is that tuner.ko is build-in and those tuner 
drivers it uses are build as a module. I think those used tuners 
(xc5000, xc4000, etc.) should be defaulted to same as MEDIA_TUNER when 
!MEDIA_SUBDRV_AUTOSELECT.



regards
Antti



On 08/06/2014 09:04 AM, kbuild test robot wrote:

tree:   git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media 
v4l_for_linus
head:   0f3bf3dc1ca394a8385079a5653088672b65c5c4
commit: f5b44da1ac4146e06147a5df3058f4c265c932ec [393/499] [media] Kconfig: fix 
tuners build warnings
config: x86_64-randconfig-s1-08061342 (attached as .config)

All error/warnings:

drivers/built-in.o: In function `set_type':

tuner-core.c:(.text+0x32ed52): undefined reference to `xc5000_attach'
tuner-core.c:(.text+0x32f123): undefined reference to `xc5000_attach'

tuner-core.c:(.text+0x32f1e6): undefined reference to `xc4000_attach'

---
0-DAY kernel build testing backend  Open Source Technology Center
http://lists.01.org/mailman/listinfo/kbuild Intel Corporation



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

Re: [PATCH 3/4] support for DVBSky dvb-s2 usb: add dvb-usb-v2 driver for DVBSky dvb-s2 box

[Antti Palosaari]

Moikka!
Biggest issue is that CIMax2 SP2 driver. Olli put all that stuff to own
I2C driver recently. Could you took SP2 from patchwork and use it instead:
https://patchwork.linuxtv.org/patch/25206/
https://patchwork.linuxtv.org/patch/25210/

It is not yet in mainline, but there should not be any big changes
coming to that driver.

regards
Antti

On 08/06/2014 07:36 AM, nibble.max wrote:
> add dvb-usb-v2 driver for DVBSky dvb-s2 box
> 
> Signed-off-by: Nibble Max 
> ---
>   drivers/media/usb/dvb-usb-v2/Kconfig  |   6 +
>   drivers/media/usb/dvb-usb-v2/Makefile |   3 +
>   drivers/media/usb/dvb-usb-v2/dvbsky.c | 872 
> ++
>   3 files changed, 881 insertions(+)
> 
> diff --git a/drivers/media/usb/dvb-usb-v2/Kconfig 
> b/drivers/media/usb/dvb-usb-v2/Kconfig
> index 66645b0..8107c8d 100644
> --- a/drivers/media/usb/dvb-usb-v2/Kconfig
> +++ b/drivers/media/usb/dvb-usb-v2/Kconfig
> @@ -141,3 +141,9 @@ config DVB_USB_RTL28XXU
>   help
> Say Y here to support the Realtek RTL28xxU DVB USB receiver.
>   
> +config DVB_USB_DVBSKY
> + tristate "DVBSky USB support"
> + depends on DVB_USB_V2
> + select DVB_M88DS3103 if MEDIA_SUBDRV_AUTOSELECT
> + help
> +   Say Y here to support the USB receivers from DVBSky.
> diff --git a/drivers/media/usb/dvb-usb-v2/Makefile 
> b/drivers/media/usb/dvb-usb-v2/Makefile
> index bc38f03..f10d4df 100644
> --- a/drivers/media/usb/dvb-usb-v2/Makefile
> +++ b/drivers/media/usb/dvb-usb-v2/Makefile
> @@ -37,6 +37,9 @@ obj-$(CONFIG_DVB_USB_MXL111SF) += mxl111sf-tuner.o
>   dvb-usb-rtl28xxu-objs := rtl28xxu.o
>   obj-$(CONFIG_DVB_USB_RTL28XXU) += dvb-usb-rtl28xxu.o
>   
> +dvb-usb-dvbsky-objs := dvbsky.o
> +obj-$(CONFIG_DVB_USB_DVBSKY) += dvb-usb-dvbsky.o
> +
>   ccflags-y += -I$(srctree)/drivers/media/dvb-core
>   ccflags-y += -I$(srctree)/drivers/media/dvb-frontends
>   ccflags-y += -I$(srctree)/drivers/media/tuners
> diff --git a/drivers/media/usb/dvb-usb-v2/dvbsky.c 
> b/drivers/media/usb/dvb-usb-v2/dvbsky.c
> new file mode 100644
> index 000..c86927f
> --- /dev/null
> +++ b/drivers/media/usb/dvb-usb-v2/dvbsky.c
> @@ -0,0 +1,872 @@
> +/*
> + * Driver for DVBSky USB2.0 receiver
> + *
> + * Copyright (C) 2013 Max nibble 
> + *
> + * CIMax code is copied and modified from:
> + * CIMax2(R) SP2 driver in conjunction with NetUp Dual DVB-S2 CI card
> + * Copyright (C) 2009 NetUP Inc.
> + * Copyright (C) 2009 Igor M. Liplianin 
> + * Copyright (C) 2009 Abylay Ospan 
> + *
> + *This program is free software; you can redistribute it and/or modify
> + *it under the terms of the GNU General Public License as published by
> + *the Free Software Foundation; either version 2 of the License, or
> + *(at your option) any later version.
> + *
> + *This program is distributed in the hope that it will be useful,
> + *but WITHOUT ANY WARRANTY; without even the implied warranty of
> + *MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + *GNU General Public License for more details.
> + *
> + *You should have received a copy of the GNU General Public License
> + *along with this program; if not, write to the Free Software
> + *Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
> + */
> +
> +#include "dvb_ca_en50221.h"
> +#include "dvb_usb.h"
> +#include "m88ds3103.h"
> +#include "m88ts2022.h"
> +
> +static int dvbsky_debug;
> +module_param(dvbsky_debug, int, 0644);
> +MODULE_PARM_DESC(dvbsky_debug, "Activates dvbsky usb debugging (default:0)");
> +
> +#define DVBSKY_MSG_DELAY 0/*2000*/
> +#define DVBSKY_CI_CTL0x04
> +#define DVBSKY_CI_RD 1
> +
> +#define dprintk(args...) \
> + do { \
> + if (dvbsky_debug) \
> + printk(KERN_INFO "dvbsky_usb: " args); \
> + } while (0)
> +
> +DVB_DEFINE_MOD_OPT_ADAPTER_NR(adapter_nr);
> +
> +struct dvbsky_state {
> + struct mutex stream_mutex;
> + u8 has_ci;
> + u8 ci_attached;
> + struct dvb_ca_en50221 ci;
> + unsigned long next_status_checked_time;
> + u8 ci_i2c_addr;
> + u8 current_ci_flag;
> + int ci_status;
> + struct i2c_client *i2c_client_tuner;
> +};
> +
> +static int dvbsky_stream_ctrl(struct dvb_usb_device *d, u8 onoff)
> +{
> + struct dvbsky_state *state = d_to_priv(d);
> + int ret;
> + u8 obuf_pre[3] = { 0x37, 0, 0 };
> + u8 obuf_post[3] = { 0x36, 3, 0 };
> + dprintk("%s() -off \n", __func__);
> + mutex_lock(&state->stream_mutex);
> + ret = dvb_usbv2_generic_write(d, obuf_pre, 3);
> + if (!ret && onoff) {
> + msleep(10);
> + ret = dvb_usbv2_generic_write(d, obuf_post, 3);
> + dprintk("%s() -on \n", __func__);
> + }
> + mutex_unlock(&state->stream_mutex);
> + return ret;
> +}
> +
> +/* CI opertaions */
> +static int dvbsky_ci_read_i2c(struct i2c_adapter *i2c_adap, u8 addr, u8 reg,
> + u8 *buf, int len)
> +{
> + int

Re: [PATCH 1/3] sp2: Add I2C driver for CIMaX SP2 common interface module

[Olli Salonen]

Thank you Antti for the review. I'll submit another version of the
patch in the coming days.

Cheers,
-olli

On 7 August 2014 19:28, Antti Palosaari  wrote:
> Reviewed-by: Antti Palosaari 
>
> None of those findings are critical. However I hope you double check and fix
> if there is any relevant enough.
>
> regards
> Antti
>
> --
> http://palosaari.fi/
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] em28xx: fix compiler warnings

[Frank Schäfer]

Am 07.08.2014 um 08:45 schrieb Hans Verkuil:
> On 08/05/2014 05:18 PM, Frank Schäfer wrote:
>> Hi Hans,
>>
>> Am 05.08.2014 um 09:00 schrieb Hans Verkuil:
>>> Fix three compiler warnings:
>>>
>>> drivers/media/usb/em28xx/em28xx-input.c: In function 
>>> ‘em28xx_i2c_ir_handle_key’:
>>> drivers/media/usb/em28xx/em28xx-input.c:318:1: warning: the frame size of 
>>> 1096 bytes is larger than 1024 bytes [-Wframe-larger-than=]
>>>  }
>>>  ^
>>>   CC [M]  drivers/media/usb/em28xx/em28xx-dvb.o
>>> drivers/media/usb/em28xx/em28xx-camera.c: In function 
>>> ‘em28xx_probe_sensor_micron’:
>>> drivers/media/usb/em28xx/em28xx-camera.c:199:1: warning: the frame size of 
>>> 1096 bytes is larger than 1024 bytes [-Wframe-larger-than=]
>>>  }
>>>  ^
>>> drivers/media/usb/em28xx/em28xx-camera.c: In function 
>>> ‘em28xx_probe_sensor_omnivision’:
>>> drivers/media/usb/em28xx/em28xx-camera.c:304:1: warning: the frame size of 
>>> 1088 bytes is larger than 1024 bytes [-Wframe-larger-than=]
>>>  }
>>>  ^
>> Hmmm... I don't get these weird warnings.
>> How can I reproduce them ?
> I'm using gcc 4.9.1 and I'm compiling the kernel using just a regular make 
> command.
> In my .config I have CONFIG_FRAME_WARN=1024.
Weird. With gcc version 4.8.1 20130909 [gcc-4_8-branch revision 202388]
I get much smaller frame sizes:

...
drivers/media/usb/em28xx/em28xx-input.c: In function
‘em28xx_i2c_ir_handle_key’:
drivers/media/usb/em28xx/em28xx-input.c:318:1: warning: the frame size
of 424 bytes is larger than 256 bytes [-Wframe-larger-than=]
 }
 ^
...
drivers/media/usb/em28xx/em28xx-camera.c: In function
‘em28xx_probe_sensor_micron’:
drivers/media/usb/em28xx/em28xx-camera.c:199:1: warning: the frame size
of 432 bytes is larger than 256 bytes [-Wframe-larger-than=]
 }
 ^
...
drivers/media/usb/em28xx/em28xx-camera.c: In function
‘em28xx_probe_sensor_omnivision’:
drivers/media/usb/em28xx/em28xx-camera.c:304:1: warning: the frame size
of 428 bytes is larger than 256 bytes [-Wframe-larger-than=]
 }
 ^
...


Anyway, I really don't think a framesize of 1096 is a problem.

>>> Note: there is no way the code in em28xx_i2c_ir_handle_key() is correct: 
>>> it's
>>> using an almost completely uninitialized i2c_client struct with random 
>>> flags,
>>> dev and name fields. Can't this turned into a proper i2c_client struct in
>>> struct em28xx? At least with this patch it's no longer random data.
>> Why do you think the client setup is random ?
> Well, this is the code:
>
>   struct i2c_client client;
>  
>   client.adapter = &ir->dev->i2c_adap[dev->def_i2c_bus];
>   client.addr = ir->i2c_dev_addr;
>
> All other fields of the client struct are undefined, but it is used as is. 
> That
> can't be right. With my patch the i2c_client is either that that was used by 
> the
> probe, or it is all zero. Which is still better than having random values.
Take a closer look at the code:

1.) sensor probing:

struct i2c_client client = dev->i2c_client[dev->def_i2c_bus];

dev->i2c_client[bus] is initialized on bus registration in
em28xx_i2c_register():

dev->i2c_client[bus] = em28xx_client_template;
dev->i2c_client[bus].adapter = &dev->i2c_adap[bus];

em28xx_client_template is defined static:

static struct i2c_client em28xx_client_template = {
.name = "em28xx internal",
};

So nothing is random or undefined here.


2.) i2c rc key polling:

em28xx_i2c_ir_handle_key() passes the client structure to one of the 4
get_key functions

rc = ir->get_key_i2c(&client, &protocol, &scancode);

which either call

i2c_transfer(client->adapter, msg, len)

directly or the helper function

i2c_master_recv(client, buf, len))

which creates an i2c message before calling i2c_transfer().
The only members used from the i2c_client struct are

msg.addr = client->addr;
msg.flags = client->flags & I2C_M_TEN;

So the only fields from struct i2c_client which need to be setup are
"adapter" and "addr" and "flags".
Adapter an addres are initialized properly to

client.adapter = &ir->dev->i2c_adap[dev->def_i2c_bus];
client.addr = ir->i2c_dev_addr;

The only thing which is indeed missing here and needs to be fixed is

client.flags = 0;


>> Which fields do you think are wrong ? AFAICS this patch doesn't change
>> any fields.
>>
>> What's wrong with using local i2c_client variables ?
> Nothing, except that they take a lot of stack space which the compiler 
> complains about.
Well, it warns because you are forcing a warning.

> The stack in the kernel is limited, so this should be avoided.
Limited to what ? 8k ? So what's the problem ?

>> Indeed, the way the driver currently tracks i2c clients / subdevices is
>> ... let's say "improvable".
>> But IMHO, we should go the opposite direction and get rid of the
>> i2c_clients in the main device struct.
>> They are in fact just temporary helpers and dangerous to use with
>> devices with multiple i2c clients on the same bus.
> Feel free to find another solution, but allocating i2c_client structs on th

Re: [PATCH 1/3] sp2: Add I2C driver for CIMaX SP2 common interface module

[Antti Palosaari]

On 08/06/2014 10:05 AM, Olli Salonen wrote:

Driver for the CIMaX SP2 common interface chip. It is very much based on
the existing cimax2 driver for cx23885, but should be more reusable. The
product has been sold with name Atmel T90FJR as well and the data sheets
for that chip seem to be publicly available.

It seems that the USB device that I have and the cx23885 based devices will
need to interact differently with the chip for the CAM operations. Thus
there is one callback function that is passed on to the sp2 driver
(see function sp2_ci_op_cam for that one).

IRQ functionality is not included currently (not needed by USB devices
and I don't have a PCIe device for development).

Signed-off-by: Olli Salonen 
---
  drivers/media/dvb-frontends/Makefile   |   1 +
  drivers/media/dvb-frontends/sp2.c  | 411 +
  drivers/media/dvb-frontends/sp2.h  |  54 +
  drivers/media/dvb-frontends/sp2_priv.h |  49 
  4 files changed, 515 insertions(+)
  create mode 100644 drivers/media/dvb-frontends/sp2.c
  create mode 100644 drivers/media/dvb-frontends/sp2.h
  create mode 100644 drivers/media/dvb-frontends/sp2_priv.h

diff --git a/drivers/media/dvb-frontends/Makefile 
b/drivers/media/dvb-frontends/Makefile
index edf103d..3498b95 100644
--- a/drivers/media/dvb-frontends/Makefile
+++ b/drivers/media/dvb-frontends/Makefile
@@ -107,6 +107,7 @@ obj-$(CONFIG_DVB_DRXK) += drxk.o
  obj-$(CONFIG_DVB_TDA18271C2DD) += tda18271c2dd.o
  obj-$(CONFIG_DVB_SI2165) += si2165.o
  obj-$(CONFIG_DVB_A8293) += a8293.o
+obj-$(CONFIG_DVB_SP2) += sp2.o
  obj-$(CONFIG_DVB_TDA10071) += tda10071.o
  obj-$(CONFIG_DVB_RTL2830) += rtl2830.o
  obj-$(CONFIG_DVB_RTL2832) += rtl2832.o
diff --git a/drivers/media/dvb-frontends/sp2.c 
b/drivers/media/dvb-frontends/sp2.c
new file mode 100644
index 000..c1b4d7e
--- /dev/null
+++ b/drivers/media/dvb-frontends/sp2.c
@@ -0,0 +1,411 @@
+/*
+ * CIMaX SP2/SP2HF (Atmel T90FJR) CI driver
+ *
+ * Copyright (C) 2014 Olli Salonen 
+ *
+ * Heavily based on CIMax2(R) SP2 driver in conjunction with NetUp Dual
+ * DVB-S2 CI card (cimax2) with following copyrights:
+ *
+ *  Copyright (C) 2009 NetUP Inc.
+ *  Copyright (C) 2009 Igor M. Liplianin 
+ *  Copyright (C) 2009 Abylay Ospan 
+ *
+ *This program is free software; you can redistribute it and/or modify
+ *it under the terms of the GNU General Public License as published by
+ *the Free Software Foundation; either version 2 of the License, or
+ *(at your option) any later version.
+ *
+ *This program is distributed in the hope that it will be useful,
+ *but WITHOUT ANY WARRANTY; without even the implied warranty of
+ *MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ *GNU General Public License for more details.
+ */
+
+#include "sp2_priv.h"
+
+static int sp2_read_i2c(struct sp2 *s, u8 reg, u8 *buf, int len)
+{
+   int ret;
+   struct i2c_client *client = s->client;
+   struct i2c_adapter *adap = client->adapter;
+   struct i2c_msg msg[] = {
+   {
+   .addr = client->addr,
+   .flags = 0,
+   .buf = ®,
+   .len = 1
+   }, {
+   .addr = client->addr,
+   .flags  = I2C_M_RD,
+   .buf = buf,
+   .len = len
+   }
+   };
+
+   ret = i2c_transfer(adap, msg, 2);
+
+   if (ret != 2) {
+   dev_err(&client->dev, "i2c read error, reg = 0x%02x, status = 
%d\n",
+   reg, ret);
+   return -1;
+   }


Could you define error code here? I know a lot of old drivers were using 
just -1, but for new driver we could try do better. Return possible 
error from i2c_transfer() and if it returns wrong amount of messages (0 
or 1 in that case) then change -EIO.


I looked from I2C documentation and I think -EIO fits best

Documentation/i2c/fault-codes

EIO
This rather vague error means something went wrong when
performing an I/O operation.  Use a more specific fault
code when you can.



+
+   dev_dbg(&s->client->dev, "addr=0x%04x, reg = 0x%02x, data = %02x\n",
+   client->addr, reg, buf[0]);
+
+   return 0;
+}
+
+static int sp2_write_i2c(struct sp2 *s, u8 reg, u8 *buf, int len)
+{
+   int ret;
+   u8 buffer[35];
+   struct i2c_client *client = s->client;
+   struct i2c_adapter *adap = client->adapter;
+   struct i2c_msg msg = {
+   .addr = client->addr,
+   .flags = 0,
+   .buf = &buffer[0],
+   .len = len + 1
+   };
+
+   if ((len + 1) > sizeof(buffer)) {
+   dev_err(&client->dev, "i2c wr reg=%02x: len=%d is too big!\n",
+   reg, len);
+   return -EINVAL;
+   }
+
+   buffer[0] = reg;
+   memcpy(&buffer[1], buf, len);
+
+   ret

[PATCH 2/3] au0828: add an option to disable IR via modprobe parameter

[Mauro Carvalho Chehab]

The IR code increases the power consumption of the device.
Allow to disable it via modprobe parameter.

Signed-off-by: Mauro Carvalho Chehab 
---
 drivers/media/usb/au0828/au0828-input.c | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/drivers/media/usb/au0828/au0828-input.c 
b/drivers/media/usb/au0828/au0828-input.c
index 53d2c59355f2..94d29c2a6fcf 100644
--- a/drivers/media/usb/au0828/au0828-input.c
+++ b/drivers/media/usb/au0828/au0828-input.c
@@ -25,6 +25,10 @@
 #include 
 #include 
 
+static int disable_ir;
+module_param(disable_ir,int, 0444);
+MODULE_PARM_DESC(disable_ir, "disable infrared remote support");
+
 #include "au0828.h"
 
 struct au0828_rc {
@@ -274,7 +278,7 @@ int au0828_rc_register(struct au0828_dev *dev)
int err = -ENOMEM;
u16 i2c_rc_dev_addr = 0;
 
-   if (!dev->board.has_ir_i2c)
+   if (!dev->board.has_ir_i2c || disable_ir)
return 0;
 
i2c_rc_dev_addr = au0828_probe_i2c_ir(dev);
-- 
1.9.3

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

[PATCH 1/3] au0828: no need to sleep at the IR code.

[Mauro Carvalho Chehab]

This sleep was doing some debouncing on the original driver.
This is not needed on Linux, because the RC core and the input
layer already takes care of it.

Signed-off-by: Mauro Carvalho Chehab 
---
 drivers/media/usb/au0828/au0828-input.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/media/usb/au0828/au0828-input.c 
b/drivers/media/usb/au0828/au0828-input.c
index d527446d008f..53d2c59355f2 100644
--- a/drivers/media/usb/au0828/au0828-input.c
+++ b/drivers/media/usb/au0828/au0828-input.c
@@ -136,8 +136,6 @@ static int au0828_get_key_au8522(struct au0828_rc *ir)
/* Disable IR */
au8522_rc_clear(ir, 0xe0, 1 << 4);
 
-   usleep_range(45000, 46000);
-
/* Enable IR */
au8522_rc_set(ir, 0xe0, 1 << 4);
 
-- 
1.9.3

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

[PATCH 3/3] au0828: Enable IR for HVR-850.

[Mauro Carvalho Chehab]

HVR-850 also has a remote. Enable it.

Signed-off-by: Mauro Carvalho Chehab 
---
 drivers/media/usb/au0828/au0828-cards.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/media/usb/au0828/au0828-cards.c 
b/drivers/media/usb/au0828/au0828-cards.c
index 2c6b7da137ed..b6c9d1f466bd 100644
--- a/drivers/media/usb/au0828/au0828-cards.c
+++ b/drivers/media/usb/au0828/au0828-cards.c
@@ -46,6 +46,7 @@ struct au0828_board au0828_boards[] = {
.name   = "Hauppauge HVR850",
.tuner_type = TUNER_XC5000,
.tuner_addr = 0x61,
+   .has_ir_i2c = 1,
.i2c_clk_divider = AU0828_I2C_CLK_250KHZ,
.input = {
{
-- 
1.9.3

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

Re: 3.15.6 USB issue with pwc cam

[Udo van den Heuvel]

On 2014-08-04 11:17, Laurent Pinchart wrote:
> (CC'ing Hans de Goede, the pwc maintainer, and the linux-media mailing list)
> 
> On Saturday 02 August 2014 15:10:01 Udo van den Heuvel wrote:
>> Hello,
>>
>> I moved a PWC webcam to a USB3 port, and this happened:

I get similar stuff when trying to use a Logitech C615 cam.
See attachment for full dmesg of errors but excerpt below:

[80346.835015] xhci_hcd :02:00.0: ERROR: unexpected command
completion code 0x11.
[80346.835027] usb 6-2: Not enough bandwidth for altsetting 11
[80346.835137] [ cut here ]
[80346.835155] WARNING: CPU: 3 PID: 20594 at
drivers/media/v4l2-core/videobuf2-core.c:2011
__vb2_queue_cancel+0x102/0x170 [videobuf2_core]()
[80346.835158] Modules linked in: uvcvideo cdc_acm bnep bluetooth fuse
edac_core cpufreq_userspace ipt_REJECT nf_conntrack_netbios_ns
nf_conntrack_broadcast iptable_filter ip6t_REJECT ipt_MASQUERADE
xt_tcpudp nf_conntrack_ipv6 iptable_nat nf_defrag_ipv6 nf_conntrack_ipv4
nf_defrag_ipv4 nf_nat_ipv4 nf_nat xt_conntrack nf_conntrack ip_tables
ip6table_filter ip6_tables x_tables eeprom it87 hwmon_vid ext2
snd_usb_audio snd_usbmidi_lib snd_hwdep snd_rawmidi ppdev pwc
videobuf2_vmalloc videobuf2_memops kvm_amd kvm v4l2_common
videobuf2_core snd_hda_codec_realtek snd_hda_codec_generic videodev
snd_hda_intel snd_hda_controller cp210x snd_hda_codec usbserial snd_seq
snd_seq_device microcode snd_pcm parport_serial parport_pc parport
snd_timer k10temp snd evdev i2c_piix4 button acpi_cpufreq nfsd
auth_rpcgss oid_registry
[80346.835218]  nfs_acl lockd sunrpc binfmt_misc autofs4 hid_generic
usbhid ohci_pci ehci_pci ehci_hcd ohci_hcd radeon sr_mod cdrom fbcon
bitblit cfbfillrect softcursor cfbimgblt cfbcopyarea font i2c_algo_bit
xhci_hcd backlight drm_kms_helper ttm drm fb fbdev
[80346.835250] CPU: 3 PID: 20594 Comm: skype Tainted: GW
3.15.8 #6
[80346.835254] Hardware name: Gigabyte Technology Co., Ltd. To be filled
by O.E.M./F2A85X-UP4, BIOS F5a 04/30/2013
[80346.835257]   79d580f4 814f2373

[80346.835262]  81069fe1  88040ec532e8

[80346.835267]  88040ec530d8 8803f0c46f00 a041d832
88040ec530d8
[80346.835272] Call Trace:
[80346.835283]  [] ? dump_stack+0x4a/0x75
[80346.835289]  [] ? warn_slowpath_common+0x81/0xb0
[80346.835299]  [] ? __vb2_queue_cancel+0x102/0x170
[videobuf2_core]
[80346.835307]  [] ? vb2_internal_streamoff+0x1d/0x50
[videobuf2_core]
[80346.835314]  [] ? uvc_queue_enable+0x75/0xb0 [uvcvideo]
[80346.835321]  [] ? uvc_video_enable+0x141/0x1a0
[uvcvideo]
[80346.835327]  [] ? uvc_v4l2_do_ioctl+0xd6f/0x1580
[uvcvideo]
[80346.835339]  [] ? video_usercopy+0x1f0/0x490 [videodev]
[80346.835345]  [] ?
uvc_v4l2_set_streamparm.isra.12+0x1c0/0x1c0 [uvcvideo]
[80346.835352]  [] ? preempt_count_add+0x3f/0x90
[80346.835356]  [] ? _raw_spin_lock+0xe/0x30
[80346.835360]  [] ? _raw_spin_unlock+0xd/0x30
[80346.835367]  [] ? __pte_alloc+0xce/0x170
[80346.835376]  [] ? v4l2_ioctl+0x11f/0x160 [videodev]
[80346.835386]  [] ? do_video_ioctl+0x246/0x1330
[videodev]
[80346.835392]  [] ? mmap_region+0x15a/0x5a0
[80346.835402]  [] ? v4l2_compat_ioctl32+0x82/0xb8
[videodev]
[80346.835408]  [] ? compat_SyS_ioctl+0x132/0x1120
[80346.835414]  [] ? vm_mmap_pgoff+0xe3/0x120
[80346.835421]  [] ? cstar_dispatch+0x7/0x1a
[80346.835424] ---[ end trace 44e3d272b6c91a71 ]---
[80346.835427] [ cut here ]


What is wrong here?

Kind regards,
Udo

[80346.835015] xhci_hcd :02:00.0: ERROR: unexpected command completion code 
0x11.
[80346.835027] usb 6-2: Not enough bandwidth for altsetting 11
[80346.835137] [ cut here ]
[80346.835155] WARNING: CPU: 3 PID: 20594 at 
drivers/media/v4l2-core/videobuf2-core.c:2011 __vb2_queue_cancel+0x102/0x170 
[videobuf2_core]()
[80346.835158] Modules linked in: uvcvideo cdc_acm bnep bluetooth fuse 
edac_core cpufreq_userspace ipt_REJECT nf_conntrack_netbios_ns 
nf_conntrack_broadcast iptable_filter ip6t_REJECT ipt_MASQUERADE xt_tcpudp 
nf_conntrack_ipv6 iptable_nat nf_defrag_ipv6 nf_conntrack_ipv4 nf_defrag_ipv4 
nf_nat_ipv4 nf_nat xt_conntrack nf_conntrack ip_tables ip6table_filter 
ip6_tables x_tables eeprom it87 hwmon_vid ext2 snd_usb_audio snd_usbmidi_lib 
snd_hwdep snd_rawmidi ppdev pwc videobuf2_vmalloc videobuf2_memops kvm_amd kvm 
v4l2_common videobuf2_core snd_hda_codec_realtek snd_hda_codec_generic videodev 
snd_hda_intel snd_hda_controller cp210x snd_hda_codec usbserial snd_seq 
snd_seq_device microcode snd_pcm parport_serial parport_pc parport snd_timer 
k10temp snd evdev i2c_piix4 button acpi_cpufreq nfsd auth_rpcgss oid_registry
[80346.835218]  nfs_acl lockd sunrpc binfmt_misc autofs4 hid_generic usbhid 
ohci_pci ehci_pci ehci_hcd ohci_hcd radeon sr_mod cdrom fbcon bitblit 
cfbfillrect softcursor cfbimgblt cfbcopyarea font i2c_algo_bit xhci_hcd 
backlight drm_kms_helper ttm drm fb fbdev
[80346.835250] CPU: 3 PID: 20594 Comm

Re: omap3isp device tree support

[Alaganraj Sandhanam]

Hi Sakari,

Thanks for the patches. I'll try this...

Thanks&Regards,
Alagan

On Thu, Aug 7, 2014 at 5:48 AM, Sakari Ailus  wrote:
> Hi Alaganraj,
>
> On Wed, Aug 06, 2014 at 04:07:58AM +0530, alaganraj sandhanam wrote:
>> Hi Laurent,
>>
>> Thanks for the info. what about git://linuxtv.org/pinchartl/media.git
>> omap3isp/dt branch?
>> I took 3 patches from this branch, fixed
>> error: implicit declaration of function ‘v4l2_of_get_next_endpoint’
>> by changing to "of_graph_get_next_endpoint".
>>
>> while booting i'm getting below msg
>> [1.558471] of_graph_get_next_endpoint(): no port node found in
>> /ocp/omap3_isp@480bc000
>> [1.567169] omap3isp 480bc000.omap3_isp: no port node at
>> /ocp/omap3_isp@480bc000
>>
>> omap3isp/dt is not working branch?
>
> My patches, while experimental, may be helpful for you. Perhaps. At the
> moment the issue is IOMMU; Hiroshi Doyu had some patches to get that
> attached to the ISP but for various reasons they didn't make it to the
> mainline kernel.
>
> You can find my patches here:
>
> http://vihersipuli.retiisi.org.uk/cgi-bin/gitweb.cgi?p=~sailus/linux.git;a=shortlog;h=refs/heads/rm696-041-dt>
>
> PLEASE do no clone the entire tree, but add that as a remote to an existing
> tree. The patches are on top of the linux-omap master branch.
>
> I think I've gotten through to sensor sub-device registration with these and
> the smiapp driver. I'll try to send some of the omap3isp and possibly also
> smiapp patches for review soon. It's unlikely to be a complete set, though.
>
> --
> Kind regards,
>
> Sakari Ailus
> e-mail: sakari.ai...@iki.fi XMPP: sai...@retiisi.org.uk
--
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] au0828-input: Be sure that IR is enabled at polling

[Mauro Carvalho Chehab]

Em Thu, 07 Aug 2014 10:14:45 -0400
Devin Heitmueller  escreveu:

> > Well, au8522_rc_set is defined as:
> >
> > #define au8522_rc_set(ir, reg, bit) au8522_rc_andor(ir, (reg), 
> > (bit), (bit))
> 
> Ah, ok.  It's just a really poorly named macro.  Nevermind then.

Yep. calling it au8522_rc_setbits would likely be better. I tried to
stick with the same name convention as this macro:

drivers/media/usb/au0828/au0828.h:#define au0828_set(dev, reg, bit) 
au0828_andor(dev, (reg), (bit), (bit))

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

Multiple devices with same SMBus address

[Jean-Michel Hautbois]

Hi,

I have a custom board which has two LMH0303 SDI drivers on the same
i2c bus. They are connected in some daisy chain form, like on the
schematics in the datasheet on page 9 :
http://www.ti.com/lit/ds/symlink/lmh0303.pdf

My problem is how to declare these devices in the DT in order to set
the new adress of the first one when probed.

I thought that something like that could do the trick but it seems crappy :

lmh0303@17 {
new-addr = <0x16>;
rsti_n = <&gpio1_17>; /* GPIO signal connected to the RSTI signal
of the first LMH0303 */
};
lmh0303@17 {
/* Nothing to do right now */
};

This is a draft thought :).

Maybe would it also be possible do define a "super device" like this :
lmh0303@17 {
lmh0303_1 {
new-addr = <0x16>;
rsti_n = <&gpio1_17>; /* GPIO signal connected to the RSTI
signal of the first LMH0303 */
};
lmh0303_2 {
};
};

This would be something like the gpio-leds binding...
But there is probably already a nice way to do that :-) ?

Thanks for your advices !
JM
--
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] au0828-input: Be sure that IR is enabled at polling

[Devin Heitmueller]

> Well, au8522_rc_set is defined as:
>
> #define au8522_rc_set(ir, reg, bit) au8522_rc_andor(ir, (reg), (bit), 
> (bit))

Ah, ok.  It's just a really poorly named macro.  Nevermind then.

Devin

-- 
Devin J. Heitmueller - 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] au0828-input: Be sure that IR is enabled at polling

[Mauro Carvalho Chehab]

Em Thu, 07 Aug 2014 10:00:31 -0400
Devin Heitmueller  escreveu:

> On Thu, Aug 7, 2014 at 9:46 AM, Mauro Carvalho Chehab
>  wrote:
> > When the DVB code sets the frontend, it disables the IR
> > INT, probably due to some hardware bug, as there's no code
> > there at au8522 frontend that writes on register 0xe0.
> >
> > Fixing it at au8522 code is hard, as it doesn't know if the
> > IR is enabled or disabled, and just restoring the value of
> > register 0xe0 could cause other nasty effects. So, better
> > to add a hack at au0828-input polling interval to enable int,
> > if disabled.
> >
> > Signed-off-by: Mauro Carvalho Chehab 
> > ---
> >  drivers/media/usb/au0828/au0828-input.c | 12 ++--
> >  1 file changed, 10 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/media/usb/au0828/au0828-input.c 
> > b/drivers/media/usb/au0828/au0828-input.c
> > index 94d29c2a6fcf..b4475706dfd2 100644
> > --- a/drivers/media/usb/au0828/au0828-input.c
> > +++ b/drivers/media/usb/au0828/au0828-input.c
> > @@ -94,14 +94,19 @@ static int au8522_rc_read(struct au0828_rc *ir, u16 
> > reg, int val,
> >  static int au8522_rc_andor(struct au0828_rc *ir, u16 reg, u8 mask, u8 
> > value)
> >  {
> > int rc;
> > -   char buf;
> > +   char buf, oldbuf;
> >
> > rc = au8522_rc_read(ir, reg, -1, &buf, 1);
> > if (rc < 0)
> > return rc;
> >
> > +   oldbuf = buf;
> > buf = (buf & ~mask) | (value & mask);
> >
> > +   /* Nothing to do, just return */
> > +   if (buf == oldbuf)
> > +   return 0;
> > +
> > return au8522_rc_write(ir, reg, buf);
> >  }
> >
> > @@ -127,8 +132,11 @@ static int au0828_get_key_au8522(struct au0828_rc *ir)
> >
> > /* Check IR int */
> > rc = au8522_rc_read(ir, 0xe1, -1, buf, 1);
> > -   if (rc < 0 || !(buf[0] & (1 << 4)))
> > +   if (rc < 0 || !(buf[0] & (1 << 4))) {
> > +   /* Be sure that IR is enabled */
> > +   au8522_rc_set(ir, 0xe0, 1 << 4);
> 
> Shouldn't this be a call to au8522_rc_andor()  rather than au8522_rc_set()?

Well, au8522_rc_set is defined as:

#define au8522_rc_set(ir, reg, bit) au8522_rc_andor(ir, (reg), (bit), 
(bit))

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

Re: [PATCH] au0828-input: Be sure that IR is enabled at polling

[Devin Heitmueller]

On Thu, Aug 7, 2014 at 9:46 AM, Mauro Carvalho Chehab
 wrote:
> When the DVB code sets the frontend, it disables the IR
> INT, probably due to some hardware bug, as there's no code
> there at au8522 frontend that writes on register 0xe0.
>
> Fixing it at au8522 code is hard, as it doesn't know if the
> IR is enabled or disabled, and just restoring the value of
> register 0xe0 could cause other nasty effects. So, better
> to add a hack at au0828-input polling interval to enable int,
> if disabled.
>
> Signed-off-by: Mauro Carvalho Chehab 
> ---
>  drivers/media/usb/au0828/au0828-input.c | 12 ++--
>  1 file changed, 10 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/media/usb/au0828/au0828-input.c 
> b/drivers/media/usb/au0828/au0828-input.c
> index 94d29c2a6fcf..b4475706dfd2 100644
> --- a/drivers/media/usb/au0828/au0828-input.c
> +++ b/drivers/media/usb/au0828/au0828-input.c
> @@ -94,14 +94,19 @@ static int au8522_rc_read(struct au0828_rc *ir, u16 reg, 
> int val,
>  static int au8522_rc_andor(struct au0828_rc *ir, u16 reg, u8 mask, u8 value)
>  {
> int rc;
> -   char buf;
> +   char buf, oldbuf;
>
> rc = au8522_rc_read(ir, reg, -1, &buf, 1);
> if (rc < 0)
> return rc;
>
> +   oldbuf = buf;
> buf = (buf & ~mask) | (value & mask);
>
> +   /* Nothing to do, just return */
> +   if (buf == oldbuf)
> +   return 0;
> +
> return au8522_rc_write(ir, reg, buf);
>  }
>
> @@ -127,8 +132,11 @@ static int au0828_get_key_au8522(struct au0828_rc *ir)
>
> /* Check IR int */
> rc = au8522_rc_read(ir, 0xe1, -1, buf, 1);
> -   if (rc < 0 || !(buf[0] & (1 << 4)))
> +   if (rc < 0 || !(buf[0] & (1 << 4))) {
> +   /* Be sure that IR is enabled */
> +   au8522_rc_set(ir, 0xe0, 1 << 4);

Shouldn't this be a call to au8522_rc_andor()  rather than au8522_rc_set()?

Devin

-- 
Devin J. Heitmueller - 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

[PATCH] au0828-input: Be sure that IR is enabled at polling

[Mauro Carvalho Chehab]

When the DVB code sets the frontend, it disables the IR
INT, probably due to some hardware bug, as there's no code
there at au8522 frontend that writes on register 0xe0.

Fixing it at au8522 code is hard, as it doesn't know if the
IR is enabled or disabled, and just restoring the value of
register 0xe0 could cause other nasty effects. So, better
to add a hack at au0828-input polling interval to enable int,
if disabled.

Signed-off-by: Mauro Carvalho Chehab 
---
 drivers/media/usb/au0828/au0828-input.c | 12 ++--
 1 file changed, 10 insertions(+), 2 deletions(-)

diff --git a/drivers/media/usb/au0828/au0828-input.c 
b/drivers/media/usb/au0828/au0828-input.c
index 94d29c2a6fcf..b4475706dfd2 100644
--- a/drivers/media/usb/au0828/au0828-input.c
+++ b/drivers/media/usb/au0828/au0828-input.c
@@ -94,14 +94,19 @@ static int au8522_rc_read(struct au0828_rc *ir, u16 reg, 
int val,
 static int au8522_rc_andor(struct au0828_rc *ir, u16 reg, u8 mask, u8 value)
 {
int rc;
-   char buf;
+   char buf, oldbuf;
 
rc = au8522_rc_read(ir, reg, -1, &buf, 1);
if (rc < 0)
return rc;
 
+   oldbuf = buf;
buf = (buf & ~mask) | (value & mask);
 
+   /* Nothing to do, just return */
+   if (buf == oldbuf)
+   return 0;
+
return au8522_rc_write(ir, reg, buf);
 }
 
@@ -127,8 +132,11 @@ static int au0828_get_key_au8522(struct au0828_rc *ir)
 
/* Check IR int */
rc = au8522_rc_read(ir, 0xe1, -1, buf, 1);
-   if (rc < 0 || !(buf[0] & (1 << 4)))
+   if (rc < 0 || !(buf[0] & (1 << 4))) {
+   /* Be sure that IR is enabled */
+   au8522_rc_set(ir, 0xe0, 1 << 4);
return 0;
+   }
 
/* Something arrived. Get the data */
rc = au8522_rc_read(ir, 0xe3, 0x11, buf, sizeof(buf));
-- 
1.9.3

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

Re: Re: [PATCH 1/4] support for DVBSky dvb-s2 usb: add some config andset_voltagefor m88ds3103

[nibble.max]

>Moikka!
>
>On 08/07/2014 12:31 PM, nibble.max wrote:
 @@ -523,6 +508,17 @@ static int m88ds3103_set_frontend(struct dvb_frontend 
 *fe)

priv->delivery_system = c->delivery_system;

 +  if (priv->cfg->start_ctrl) {
 +  for (len = 0; len < 30 ; len++) {
 +  m88ds3103_read_status(fe, &status);
 +  if (status & FE_HAS_LOCK) {
 +  priv->cfg->start_ctrl(fe);
 +  break;
 +  }
 +  msleep(20);
 +  }
 +  }
 +
>>>
>>> What is idea of that start_ctrl logic? It looks ugly. Why it is needed?
>>> What is wrong with default DVB-core implementation? You should not need
>>> to poll demod lock here and then call streaming control callback from
>>> USB driver. If you implement .streaming_ctrl() callback to DVB USB
>>> driver, it is called automatically for you.
>> It is nothing with streaming_ctrl of DVB USB driver.
>> It relates with the hardware chip problem.
>> The m88ds3103 will not output ts clock when it powers up at the first time.
>> It starts to output ts clock as soon as it locks the signal.
>> But the slave fifo of Cypress usb chip really need this clock to work.
>> If there is no this clock, the salve fifo will stop.
>> start_ctrl logic is used to restart the salve fifo when the ts clock is 
>> valid.
>
>OK. Then we have to find out some solution... Is there anyone who has a
>nice idea how to signal USB interface driver when demod gains a lock?
>Sure USB driver could poll read_status() too, but it does not sound good
>solution neither.
>
>How about overriding FE .read_status() callback. It is called all the
>time by DVB-core when frontend is open. Hook .read_status() to USB
>interface driver, then call original .read_status() (implemented by
>m88ds3103 driver), and after each call check if status is LOCKED or NOT
>LOCKED. When status changes from NOT LOCKED to LOCKED call that board
>specific routine which restarts TS FIFO. No change for demod driver
>needed at all.
>
It sounds a good idea.
Try to remove start_ctrl() and set_voltage() callback from demod driver
and send the patch for m88ds3103 later.
>regards
>Antto
>
>-- 
>http://palosaari.fi/

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

Re: [PATCH/RFC v4 06/21] leds: add API for setting torch brightness

[Jacek Anaszewski]

Hi Sakari,

On 08/04/2014 02:50 PM, Sakari Ailus wrote:

Hi Jacek,

Thank you for your continued efforts on this!

On Mon, Aug 04, 2014 at 02:35:26PM +0200, Jacek Anaszewski wrote:

On 07/16/2014 11:54 PM, Sakari Ailus wrote:

Hi Jacek,

Jacek Anaszewski wrote:
...

diff --git a/include/linux/leds.h b/include/linux/leds.h
index 1a130cc..9bea9e6 100644
--- a/include/linux/leds.h
+++ b/include/linux/leds.h
@@ -44,11 +44,21 @@ struct led_classdev {
  #define LED_BLINK_ONESHOT_STOP(1 << 18)
  #define LED_BLINK_INVERT(1 << 19)
  #define LED_SYSFS_LOCK(1 << 20)
+#define LED_DEV_CAP_TORCH(1 << 21)

  /* Set LED brightness level */
  /* Must not sleep, use a workqueue if needed */
  void(*brightness_set)(struct led_classdev *led_cdev,
enum led_brightness brightness);
+/*
+ * Set LED brightness immediately - it is required for flash led
+ * devices as they require setting torch brightness to have
immediate
+ * effect. brightness_set op cannot be used for this purpose because
+ * the led drivers schedule a work queue task in it to allow for
+ * being called from led-triggers, i.e. from the timer irq context.
+ */


Do we need to classify actual devices based on this? I think it's rather
a different API behaviour between the LED and the V4L2 APIs.

On devices that are slow to control, the behaviour should be asynchronous
over the LED API and synchronous when accessed through the V4L2 API. How
about implementing the work queue, as I have suggested, in the
framework, so
that individual drivers don't need to care about this and just implement
the
synchronous variant of this op? A flag could be added to distinguish
devices
that are fast so that the work queue isn't needed.

It'd be nice to avoid individual drivers having to implement multiple
ops to
do the same thing, just for differing user space interfacs.



It is not only the matter of a device controller speed. If a flash
device is to be made accessible from the LED subsystem, then it
should be also compatible with led-triggers. Some of led-triggers
call brightness_set op from the timer irq context and thus no
locking in the callback can occur. This requirement cannot be
met i.e. if i2c bus is to be used. This is probably the primary
reason for scheduling work queue tasks in brightness_set op.

Having the above in mind, setting a brightness in a work queue
task must be possible for all LED Class Flash drivers, regardless
whether related devices have fast or slow controller.

Let's recap the cost of possible solutions then:

1) Moving the work queues to the LED framework

   - it would probably require extending led_set_brightness and
 __led_set_brightness functions by a parameter indicating whether it
 should call brightness_set op in the work queue task or directly;
   - all existing triggers would have to be updated accordingly;
   - work queues would have to be removed from all the LED drivers;

2) adding led_set_torch_brightness API

   - no modifications in existing drivers and triggers would be required
   - instead, only the modifications from the discussed patch would
 be required

Solution 1 looks cleaner but requires much more modifications.


How about a combination of the two, i.e. option 1 with the old op remaining
there for compatibility with the old drivers (with a comment telling it's
deprecated)?

This way new drivers will benefit from having to implement this just once,
and modifications to the existing drivers could be left for later.


It's OK for me, but the opinion from the LED side guys is needed here
as well.


The downside is that any old drivers wouldn't get V4L2 flash API but that's
entirely acceptable in my opinion since these would hardly be needed in use
cases that would benefit from V4L2 flash API.


In the version 4 of the patch set I changed the implementation, so that
a flash led driver must call led_classdev_flash_register to get
registered as a LED Flash Class device and v4l2_flash_init to get
V4L2 Flash API. In effect old drivers will have no chance to get V4L2
Flash API either way.

Best Regards,
Jacek Anaszewski
--
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

Casino

[Herbert Meadows]

Casino International
http://michelle-cash-money.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] support for DVBSky dvb-s2 usb: add some config andset_voltage for m88ds3103

[Antti Palosaari]

Moikka!

On 08/07/2014 12:31 PM, nibble.max wrote:
>>> @@ -523,6 +508,17 @@ static int m88ds3103_set_frontend(struct dvb_frontend 
>>> *fe)
>>>
>>> priv->delivery_system = c->delivery_system;
>>>
>>> +   if (priv->cfg->start_ctrl) {
>>> +   for (len = 0; len < 30 ; len++) {
>>> +   m88ds3103_read_status(fe, &status);
>>> +   if (status & FE_HAS_LOCK) {
>>> +   priv->cfg->start_ctrl(fe);
>>> +   break;
>>> +   }
>>> +   msleep(20);
>>> +   }
>>> +   }
>>> +
>>
>> What is idea of that start_ctrl logic? It looks ugly. Why it is needed?
>> What is wrong with default DVB-core implementation? You should not need
>> to poll demod lock here and then call streaming control callback from
>> USB driver. If you implement .streaming_ctrl() callback to DVB USB
>> driver, it is called automatically for you.
> It is nothing with streaming_ctrl of DVB USB driver.
> It relates with the hardware chip problem.
> The m88ds3103 will not output ts clock when it powers up at the first time.
> It starts to output ts clock as soon as it locks the signal.
> But the slave fifo of Cypress usb chip really need this clock to work.
> If there is no this clock, the salve fifo will stop.
> start_ctrl logic is used to restart the salve fifo when the ts clock is valid.

OK. Then we have to find out some solution... Is there anyone who has a
nice idea how to signal USB interface driver when demod gains a lock?
Sure USB driver could poll read_status() too, but it does not sound good
solution neither.

How about overriding FE .read_status() callback. It is called all the
time by DVB-core when frontend is open. Hook .read_status() to USB
interface driver, then call original .read_status() (implemented by
m88ds3103 driver), and after each call check if status is LOCKED or NOT
LOCKED. When status changes from NOT LOCKED to LOCKED call that board
specific routine which restarts TS FIFO. No change for demod driver
needed at all.

regards
Antto

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

Re: Re: [PATCH 1/4] support for DVBSky dvb-s2 usb: add some config andset_voltage for m88ds3103

[nibble.max]

Moikka!
Thanks for your review.
>Moikka!
>
>That patch contains (too) many changes:
>1) TS clock config option
>2) TS clock polarity config option
>3) start_ctrl() callback
>4) set_voltage implementation
>5) set_voltage() callback
>
>Generally I am fine with 1, 2 and 4.
>
>When you do that many different logical changes for existing driver, you
>should split it is one patch per change.
>
>Rest of the comments are between the code.
>
>
>On 08/06/2014 07:27 AM, nibble.max wrote:
>> Add some config parameters and set_voltage function for m88ds3103.
>> 
>> Signed-off-by: Nibble Max 
>> ---
>>   drivers/media/dvb-frontends/m88ds3103.c | 91 
>> +++--
>>   drivers/media/dvb-frontends/m88ds3103.h | 37 --
>>   2 files changed, 96 insertions(+), 32 deletions(-)
>> 
>> diff --git a/drivers/media/dvb-frontends/m88ds3103.c 
>> b/drivers/media/dvb-frontends/m88ds3103.c
>> index dfe0c2f..df2f89c 100644
>> --- a/drivers/media/dvb-frontends/m88ds3103.c
>> +++ b/drivers/media/dvb-frontends/m88ds3103.c
>> @@ -247,8 +247,9 @@ static int m88ds3103_set_frontend(struct dvb_frontend 
>> *fe)
>>  u8 u8tmp, u8tmp1, u8tmp2;
>>  u8 buf[2];
>>  u16 u16tmp, divide_ratio;
>> -u32 tuner_frequency, target_mclk, ts_clk;
>> +u32 tuner_frequency, target_mclk;
>>  s32 s32tmp;
>> +fe_status_t status;
>>  dev_dbg(&priv->i2c->dev,
>>  "%s: delivery_system=%d modulation=%d frequency=%d 
>> symbol_rate=%d inversion=%d pilot=%d rolloff=%d\n",
>>  __func__, c->delivery_system,
>> @@ -316,9 +317,6 @@ static int m88ds3103_set_frontend(struct dvb_frontend 
>> *fe)
>>  target_mclk = 144000;
>>  break;
>>  case M88DS3103_TS_PARALLEL:
>> -case M88DS3103_TS_PARALLEL_12:
>> -case M88DS3103_TS_PARALLEL_16:
>> -case M88DS3103_TS_PARALLEL_19_2:
>>  case M88DS3103_TS_CI:
>>  if (c->symbol_rate < 1800)
>>  target_mclk = 96000;
>> @@ -352,33 +350,17 @@ static int m88ds3103_set_frontend(struct dvb_frontend 
>> *fe)
>>  switch (priv->cfg->ts_mode) {
>>  case M88DS3103_TS_SERIAL:
>>  u8tmp1 = 0x00;
>> -ts_clk = 0;
>> -u8tmp = 0x46;
>> +u8tmp = 0x06;
>>  break;
>>  case M88DS3103_TS_SERIAL_D7:
>>  u8tmp1 = 0x20;
>> -ts_clk = 0;
>> -u8tmp = 0x46;
>> +u8tmp = 0x06;
>>  break;
>>  case M88DS3103_TS_PARALLEL:
>> -ts_clk = 24000;
>> -u8tmp = 0x42;
>> -break;
>> -case M88DS3103_TS_PARALLEL_12:
>> -ts_clk = 12000;
>> -u8tmp = 0x42;
>> -break;
>> -case M88DS3103_TS_PARALLEL_16:
>> -ts_clk = 16000;
>> -u8tmp = 0x42;
>> -break;
>> -case M88DS3103_TS_PARALLEL_19_2:
>> -ts_clk = 19200;
>> -u8tmp = 0x42;
>> +u8tmp = 0x02;
>>  break;
>>  case M88DS3103_TS_CI:
>> -ts_clk = 6000;
>> -u8tmp = 0x43;
>> +u8tmp = 0x03;
>>  break;
>>  default:
>>  dev_dbg(&priv->i2c->dev, "%s: invalid ts_mode\n", __func__);
>> @@ -386,6 +368,9 @@ static int m88ds3103_set_frontend(struct dvb_frontend 
>> *fe)
>>  goto err;
>>  }
>>   
>> +if (priv->cfg->ts_clk_pol)
>> +u8tmp |= 0x40;
>> +
>>  /* TS mode */
>>  ret = m88ds3103_wr_reg(priv, 0xfd, u8tmp);
>>  if (ret)
>> @@ -399,8 +384,8 @@ static int m88ds3103_set_frontend(struct dvb_frontend 
>> *fe)
>>  goto err;
>>  }
>>   
>> -if (ts_clk) {
>> -divide_ratio = DIV_ROUND_UP(target_mclk, ts_clk);
>> +if (priv->cfg->ts_clk) {
>> +divide_ratio = DIV_ROUND_UP(target_mclk, priv->cfg->ts_clk);
>>  u8tmp1 = divide_ratio / 2;
>>  u8tmp2 = DIV_ROUND_UP(divide_ratio, 2);
>>  } else {
>> @@ -411,7 +396,7 @@ static int m88ds3103_set_frontend(struct dvb_frontend 
>> *fe)
>>   
>>  dev_dbg(&priv->i2c->dev,
>>  "%s: target_mclk=%d ts_clk=%d divide_ratio=%d\n",
>> -__func__, target_mclk, ts_clk, divide_ratio);
>> +__func__, target_mclk, priv->cfg->ts_clk, divide_ratio);
>>   
>>  u8tmp1--;
>>  u8tmp2--;
>> @@ -523,6 +508,17 @@ static int m88ds3103_set_frontend(struct dvb_frontend 
>> *fe)
>>   
>>  priv->delivery_system = c->delivery_system;
>>   
>> +if (priv->cfg->start_ctrl) {
>> +for (len = 0; len < 30 ; len++) {
>> +m88ds3103_read_status(fe, &status);
>> +if (status & FE_HAS_LOCK) {
>> +priv->cfg->start_ctrl(fe);
>> +break;
>> +}
>> +msleep(20);
>> +}
>> +}
>> +
>
>What

Re: [PATCH/RFC v4 00/21] LED / flash API integration

[Jacek Anaszewski]

On 08/07/2014 10:21 AM, Jacek Anaszewski wrote:

Hi Sakari,

On 08/06/2014 08:53 AM, Sakari Ailus wrote:

Hi Jacek,

On Fri, Jul 11, 2014 at 04:04:03PM +0200, Jacek Anaszewski wrote:
...

1) Who should register V4L2 Flash sub-device?

LED Flash Class devices, after introduction of the Flash Manager,
are not tightly coupled with any media controller. They are maintained
by the Flash Manager and made available for dynamic assignment to
any media system they are connected to through multiplexing devices.

In the proposed rough solution, when support for V4L2 Flash sub-devices
is enabled, there is a v4l2_device created for them to register in.
This however implies that V4L2 Flash device will not be available
in any media controller, which calls its existence into question.

Therefore I'd like to consult possible ways of solving this issue.
The option I see is implementing a mechanism for moving V4L2 Flash
sub-devices between media controllers. A V4L2 Flash sub-device
would initially be assigned to one media system in the relevant
device tree binding, but it could be dynamically reassigned to
the other one. However I'm not sure if media controller design
is prepared for dynamic modifications of its graph and how many
modifications in the existing drivers this solution would require.


Do you have a use case where you would need to strobe a flash from
multiple
media devices at different times, or is this entirely theoretical?
Typically
flash controllers are connected to a single source of hardware strobe (if
there's one) since the flash LEDs are in fact mounted next to a specific
camera sensor.


I took into account such arrangements in response to your message [1],
where you were considering configurations like "one flash but two
cameras", "one camera and two flashes". And you also called for
proposing generic solution.

One flash and two (or more) cameras case is easily conceivable -
You even mentioned stereo cameras. One camera and many flashes
arrangement might be useful in case of some professional devices which
might be designed so that they would be able to apply different scene
lighting. I haven't heard about such devices, but as you said
such a configuration isn't unthinkable.


If this is a real issue the way to solve it would be to have a single
media
device instead of many.


I was considering adding media device, that would be a representation
of a flash manager, gathering all the registered flashes. Nonetheless,
finally I came to conclusion that a v4l2-device alone should suffice,
just to provide a Flash Manager representation allowing for v4l2-flash
sub-devices to register in.
All the features provided by the media device are useless in case
of a set of V4L2 Flash sub-devices. They couldn't have any linkage
in such a device. The only benefit from having media device gathering
V4L2 Flash devices would be possibility of listing them.


2) Consequences of locking the Flash Manager during flash strobe

In case a LED Flash Class device depends on muxes involved in
routing the other LED Flash Class device's strobe signals,
the Flash Manager must be locked for the time of strobing
to prevent reconfiguration of the strobe signal routing
by the other device.


I wouldn't be concerned of this in particular. It's more important we do
actully have V4L2 flash API supported by LED flash drivers and that
they do
implement the API correctly.

It's at least debatable whether you should try to prevent user space from
doing silly things or not. With complex devices it may relatively easily
lead to wrecking havoc with actual use cases which we certainly do not
want.

In this case, if you just prevent changing the routing (do you have a use
case for it?) while strobing, someone else could still change the routing
just before you strobe.


Originally I started to implementing this so that strobe signal routing
was altered upon setting strobe source. With such an implementation the
use case would be as follows:

1. Process 1 sets strobe source to external
2. Process 2 sets strobe source to software
3. Process 1 strobes the flash, unaware that strobe source setting has
been changed


It is of course too generic use case. The more specific one could
be the situation when there are many users in the system that
want to take the picture in the same time. It is not valid in
case of mobile devices though.


To avoid such problems I changed the implementation so that the
routing is set in the led_flash_manager_setup_strobe function called
from led_set_flash_strobe and led_set_external_strobe functions.
led_flash_manager_setup_strobe sets strobe signal routing
and strobes the flash under lock and holds it for the flash timeout
period, which prevents spurious reconfiguration.

Nonetheless, I agree that trying to handle this problem is troublesome,
and would affect current V4L2 Flash SPI semantics. If you don't share
my concerns I am happy to leave this locking solution out :)

Best Regards,
Jacek Anaszewski

[1] http://www.

Re: [PATCH/RFC v4 00/21] LED / flash API integration

[Jacek Anaszewski]

Hi Sakari,

On 08/06/2014 08:53 AM, Sakari Ailus wrote:

Hi Jacek,

On Fri, Jul 11, 2014 at 04:04:03PM +0200, Jacek Anaszewski wrote:
...

1) Who should register V4L2 Flash sub-device?

LED Flash Class devices, after introduction of the Flash Manager,
are not tightly coupled with any media controller. They are maintained
by the Flash Manager and made available for dynamic assignment to
any media system they are connected to through multiplexing devices.

In the proposed rough solution, when support for V4L2 Flash sub-devices
is enabled, there is a v4l2_device created for them to register in.
This however implies that V4L2 Flash device will not be available
in any media controller, which calls its existence into question.

Therefore I'd like to consult possible ways of solving this issue.
The option I see is implementing a mechanism for moving V4L2 Flash
sub-devices between media controllers. A V4L2 Flash sub-device
would initially be assigned to one media system in the relevant
device tree binding, but it could be dynamically reassigned to
the other one. However I'm not sure if media controller design
is prepared for dynamic modifications of its graph and how many
modifications in the existing drivers this solution would require.


Do you have a use case where you would need to strobe a flash from multiple
media devices at different times, or is this entirely theoretical? Typically
flash controllers are connected to a single source of hardware strobe (if
there's one) since the flash LEDs are in fact mounted next to a specific
camera sensor.


I took into account such arrangements in response to your message [1], 
where you were considering configurations like "one flash but two
cameras", "one camera and two flashes". And you also called for 
proposing generic solution.


One flash and two (or more) cameras case is easily conceivable -
You even mentioned stereo cameras. One camera and many flashes
arrangement might be useful in case of some professional devices which
might be designed so that they would be able to apply different scene
lighting. I haven't heard about such devices, but as you said
such a configuration isn't unthinkable.


If this is a real issue the way to solve it would be to have a single media
device instead of many.


I was considering adding media device, that would be a representation
of a flash manager, gathering all the registered flashes. Nonetheless,
finally I came to conclusion that a v4l2-device alone should suffice,
just to provide a Flash Manager representation allowing for v4l2-flash 
sub-devices to register in.

All the features provided by the media device are useless in case
of a set of V4L2 Flash sub-devices. They couldn't have any linkage
in such a device. The only benefit from having media device gathering
V4L2 Flash devices would be possibility of listing them.


2) Consequences of locking the Flash Manager during flash strobe

In case a LED Flash Class device depends on muxes involved in
routing the other LED Flash Class device's strobe signals,
the Flash Manager must be locked for the time of strobing
to prevent reconfiguration of the strobe signal routing
by the other device.


I wouldn't be concerned of this in particular. It's more important we do
actully have V4L2 flash API supported by LED flash drivers and that they do
implement the API correctly.

It's at least debatable whether you should try to prevent user space from
doing silly things or not. With complex devices it may relatively easily
lead to wrecking havoc with actual use cases which we certainly do not want.

In this case, if you just prevent changing the routing (do you have a use
case for it?) while strobing, someone else could still change the routing
just before you strobe.


Originally I started to implementing this so that strobe signal routing
was altered upon setting strobe source. With such an implementation the 
use case would be as follows:


1. Process 1 sets strobe source to external
2. Process 2 sets strobe source to software
3. Process 1 strobes the flash, unaware that strobe source setting has
   been changed

To avoid such problems I changed the implementation so that the
routing is set in the led_flash_manager_setup_strobe function called
from led_set_flash_strobe and led_set_external_strobe functions.
led_flash_manager_setup_strobe sets strobe signal routing
and strobes the flash under lock and holds it for the flash timeout
period, which prevents spurious reconfiguration.

Nonetheless, I agree that trying to handle this problem is troublesome,
and would affect current V4L2 Flash SPI semantics. If you don't share
my concerns I am happy to leave this locking solution out :)

Best Regards,
Jacek Anaszewski

[1] http://www.spinics.net/lists/linux-leds/msg01617.html
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/4] support for DVBSky dvb-s2 usb: add some config and set_voltage for m88ds3103

[Antti Palosaari]

Moikka!

That patch contains (too) many changes:
1) TS clock config option
2) TS clock polarity config option
3) start_ctrl() callback
4) set_voltage implementation
5) set_voltage() callback

Generally I am fine with 1, 2 and 4.

When you do that many different logical changes for existing driver, you
should split it is one patch per change.

Rest of the comments are between the code.


On 08/06/2014 07:27 AM, nibble.max wrote:
> Add some config parameters and set_voltage function for m88ds3103.
> 
> Signed-off-by: Nibble Max 
> ---
>   drivers/media/dvb-frontends/m88ds3103.c | 91 
> +++--
>   drivers/media/dvb-frontends/m88ds3103.h | 37 --
>   2 files changed, 96 insertions(+), 32 deletions(-)
> 
> diff --git a/drivers/media/dvb-frontends/m88ds3103.c 
> b/drivers/media/dvb-frontends/m88ds3103.c
> index dfe0c2f..df2f89c 100644
> --- a/drivers/media/dvb-frontends/m88ds3103.c
> +++ b/drivers/media/dvb-frontends/m88ds3103.c
> @@ -247,8 +247,9 @@ static int m88ds3103_set_frontend(struct dvb_frontend *fe)
>   u8 u8tmp, u8tmp1, u8tmp2;
>   u8 buf[2];
>   u16 u16tmp, divide_ratio;
> - u32 tuner_frequency, target_mclk, ts_clk;
> + u32 tuner_frequency, target_mclk;
>   s32 s32tmp;
> + fe_status_t status;
>   dev_dbg(&priv->i2c->dev,
>   "%s: delivery_system=%d modulation=%d frequency=%d 
> symbol_rate=%d inversion=%d pilot=%d rolloff=%d\n",
>   __func__, c->delivery_system,
> @@ -316,9 +317,6 @@ static int m88ds3103_set_frontend(struct dvb_frontend *fe)
>   target_mclk = 144000;
>   break;
>   case M88DS3103_TS_PARALLEL:
> - case M88DS3103_TS_PARALLEL_12:
> - case M88DS3103_TS_PARALLEL_16:
> - case M88DS3103_TS_PARALLEL_19_2:
>   case M88DS3103_TS_CI:
>   if (c->symbol_rate < 1800)
>   target_mclk = 96000;
> @@ -352,33 +350,17 @@ static int m88ds3103_set_frontend(struct dvb_frontend 
> *fe)
>   switch (priv->cfg->ts_mode) {
>   case M88DS3103_TS_SERIAL:
>   u8tmp1 = 0x00;
> - ts_clk = 0;
> - u8tmp = 0x46;
> + u8tmp = 0x06;
>   break;
>   case M88DS3103_TS_SERIAL_D7:
>   u8tmp1 = 0x20;
> - ts_clk = 0;
> - u8tmp = 0x46;
> + u8tmp = 0x06;
>   break;
>   case M88DS3103_TS_PARALLEL:
> - ts_clk = 24000;
> - u8tmp = 0x42;
> - break;
> - case M88DS3103_TS_PARALLEL_12:
> - ts_clk = 12000;
> - u8tmp = 0x42;
> - break;
> - case M88DS3103_TS_PARALLEL_16:
> - ts_clk = 16000;
> - u8tmp = 0x42;
> - break;
> - case M88DS3103_TS_PARALLEL_19_2:
> - ts_clk = 19200;
> - u8tmp = 0x42;
> + u8tmp = 0x02;
>   break;
>   case M88DS3103_TS_CI:
> - ts_clk = 6000;
> - u8tmp = 0x43;
> + u8tmp = 0x03;
>   break;
>   default:
>   dev_dbg(&priv->i2c->dev, "%s: invalid ts_mode\n", __func__);
> @@ -386,6 +368,9 @@ static int m88ds3103_set_frontend(struct dvb_frontend *fe)
>   goto err;
>   }
>   
> + if (priv->cfg->ts_clk_pol)
> + u8tmp |= 0x40;
> +
>   /* TS mode */
>   ret = m88ds3103_wr_reg(priv, 0xfd, u8tmp);
>   if (ret)
> @@ -399,8 +384,8 @@ static int m88ds3103_set_frontend(struct dvb_frontend *fe)
>   goto err;
>   }
>   
> - if (ts_clk) {
> - divide_ratio = DIV_ROUND_UP(target_mclk, ts_clk);
> + if (priv->cfg->ts_clk) {
> + divide_ratio = DIV_ROUND_UP(target_mclk, priv->cfg->ts_clk);
>   u8tmp1 = divide_ratio / 2;
>   u8tmp2 = DIV_ROUND_UP(divide_ratio, 2);
>   } else {
> @@ -411,7 +396,7 @@ static int m88ds3103_set_frontend(struct dvb_frontend *fe)
>   
>   dev_dbg(&priv->i2c->dev,
>   "%s: target_mclk=%d ts_clk=%d divide_ratio=%d\n",
> - __func__, target_mclk, ts_clk, divide_ratio);
> + __func__, target_mclk, priv->cfg->ts_clk, divide_ratio);
>   
>   u8tmp1--;
>   u8tmp2--;
> @@ -523,6 +508,17 @@ static int m88ds3103_set_frontend(struct dvb_frontend 
> *fe)
>   
>   priv->delivery_system = c->delivery_system;
>   
> + if (priv->cfg->start_ctrl) {
> + for (len = 0; len < 30 ; len++) {
> + m88ds3103_read_status(fe, &status);
> + if (status & FE_HAS_LOCK) {
> + priv->cfg->start_ctrl(fe);
> + break;
> + }
> + msleep(20);
> + }
> + }
> +

What is idea of that start_ctrl logic? It looks ugly. Why it is needed?
What is wrong with default DVB-core