[PATCH 0/3] support for Logilink VG0022a DVB-T2 stick

[PATCH 0/3] support for Logilink VG0022a DVB-T2 stick

[Andreas Kemnade]

Hi all,
here are some patches needed for supporting the
Logilink VG0022A DVB-T2 stick.
As the combination of chips in that stick is not
uncommon, the first two patches might also fix problems
for similar hardware.

Andreas Kemnade (3):
  [media] si2157: get chip id during probing
  [media] af9035: init i2c already in it930x_frontend_attach
  [media] af9035: add Logilink vg0022a to device id table

 drivers/media/tuners/si2157.c         | 54 +++++++++++++++++++++--------------
 drivers/media/tuners/si2157_priv.h    |  7 +++++
 drivers/media/usb/dvb-usb-v2/af9035.c | 45 ++++++++++++++++++++++++++++-
 3 files changed, 83 insertions(+), 23 deletions(-)

-- 
2.1.4

[PATCH 1/3] [media] si2157: get chip id during probing

[Andreas Kemnade]

If the si2157 is behind a e.g. si2168, the si2157 will
at least in some situations not be readable after the si268
got the command 0101. It still accepts commands but the answer
is just ffffff. So read the chip id before that so the
information is not lost.

The following line in kernel output is a symptome
of that problem:
si2157 7-0063: unknown chip version Si21255-\xffffffff\xffffffff\xffffffff

Signed-off-by: Andreas Kemnade <andreas@kemnade.info>
---
 drivers/media/tuners/si2157.c      | 54 ++++++++++++++++++++++----------------
 drivers/media/tuners/si2157_priv.h |  7 +++++
 2 files changed, 39 insertions(+), 22 deletions(-)

diff --git a/drivers/media/tuners/si2157.c b/drivers/media/tuners/si2157.c
index 57b2508..0da7a33 100644
--- a/drivers/media/tuners/si2157.c
+++ b/drivers/media/tuners/si2157.c
@@ -84,7 +84,7 @@ static int si2157_init(struct dvb_frontend *fe)
 	struct si2157_cmd cmd;
 	const struct firmware *fw;
 	const char *fw_name;
-	unsigned int uitmp, chip_id;
+	unsigned int uitmp;
 
 	dev_dbg(&client->dev, "\n");
 
@@ -115,24 +115,7 @@ static int si2157_init(struct dvb_frontend *fe)
 	if (ret)
 		goto err;
 
-	/* query chip revision */
-	memcpy(cmd.args, "\x02", 1);
-	cmd.wlen = 1;
-	cmd.rlen = 13;
-	ret = si2157_cmd_execute(client, &cmd);
-	if (ret)
-		goto err;
-
-	chip_id = cmd.args[1] << 24 | cmd.args[2] << 16 | cmd.args[3] << 8 |
-			cmd.args[4] << 0;
-
-	#define SI2158_A20 ('A' << 24 | 58 << 16 | '2' << 8 | '0' << 0)
-	#define SI2148_A20 ('A' << 24 | 48 << 16 | '2' << 8 | '0' << 0)
-	#define SI2157_A30 ('A' << 24 | 57 << 16 | '3' << 8 | '0' << 0)
-	#define SI2147_A30 ('A' << 24 | 47 << 16 | '3' << 8 | '0' << 0)
-	#define SI2146_A10 ('A' << 24 | 46 << 16 | '1' << 8 | '0' << 0)
-
-	switch (chip_id) {
+	switch (dev->chip_id) {
 	case SI2158_A20:
 	case SI2148_A20:
 		fw_name = SI2158_A20_FIRMWARE;
@@ -150,9 +133,6 @@ static int si2157_init(struct dvb_frontend *fe)
 		goto err;
 	}
 
-	dev_info(&client->dev, "found a 'Silicon Labs Si21%d-%c%c%c'\n",
-			cmd.args[2], cmd.args[1], cmd.args[3], cmd.args[4]);
-
 	if (fw_name == NULL)
 		goto skip_fw_download;
 
@@ -444,6 +424,36 @@ static int si2157_probe(struct i2c_client *client,
 
 	memcpy(&fe->ops.tuner_ops, &si2157_ops, sizeof(struct dvb_tuner_ops));
 	fe->tuner_priv = client;
+	/* power up */
+	if (dev->chiptype == SI2157_CHIPTYPE_SI2146) {
+		memcpy(cmd.args, "\xc0\x05\x01\x00\x00\x0b\x00\x00\x01", 9);
+		cmd.wlen = 9;
+	} else {
+		memcpy(cmd.args,
+		"\xc0\x00\x0c\x00\x00\x01\x01\x01\x01\x01\x01\x02\x00\x00\x01",
+		15);
+		cmd.wlen = 15;
+	}
+	cmd.rlen = 1;
+	ret = si2157_cmd_execute(client, &cmd);
+	if (ret)
+		goto err;
+	/* query chip revision */
+	/* hack: do it here because after the si2168 gets 0101, commands will
+	 * still be executed here but no result
+	 */
+	memcpy(cmd.args, "\x02", 1);
+	cmd.wlen = 1;
+	cmd.rlen = 13;
+	ret = si2157_cmd_execute(client, &cmd);
+	if (ret)
+		goto err_kfree;
+	dev->chip_id = cmd.args[1] << 24 |
+			cmd.args[2] << 16 |
+			cmd.args[3] << 8 |
+			cmd.args[4] << 0;
+	dev_info(&client->dev, "found a 'Silicon Labs Si21%d-%c%c%c'\n",
+			cmd.args[2], cmd.args[1], cmd.args[3], cmd.args[4]);
 
 #ifdef CONFIG_MEDIA_CONTROLLER
 	if (cfg->mdev) {
diff --git a/drivers/media/tuners/si2157_priv.h b/drivers/media/tuners/si2157_priv.h
index d6b2c7b..54c1a856 100644
--- a/drivers/media/tuners/si2157_priv.h
+++ b/drivers/media/tuners/si2157_priv.h
@@ -30,6 +30,7 @@ struct si2157_dev {
 	u8 chiptype;
 	u8 if_port;
 	u32 if_frequency;
+	u32 chip_id;
 	struct delayed_work stat_work;
 
 #if defined(CONFIG_MEDIA_CONTROLLER)
@@ -43,6 +44,12 @@ struct si2157_dev {
 #define SI2157_CHIPTYPE_SI2157 0
 #define SI2157_CHIPTYPE_SI2146 1
 
+#define SI2158_A20 ('A' << 24 | 58 << 16 | '2' << 8 | '0' << 0)
+#define SI2148_A20 ('A' << 24 | 48 << 16 | '2' << 8 | '0' << 0)
+#define SI2157_A30 ('A' << 24 | 57 << 16 | '3' << 8 | '0' << 0)
+#define SI2147_A30 ('A' << 24 | 47 << 16 | '3' << 8 | '0' << 0)
+#define SI2146_A10 ('A' << 24 | 46 << 16 | '1' << 8 | '0' << 0)
+
 /* firmware command struct */
 #define SI2157_ARGLEN      30
 struct si2157_cmd {
-- 
2.1.4

Re: [PATCH 1/3] [media] si2157: get chip id during probing

[Antti Palosaari]

On 03/16/2017 12:22 AM, Andreas Kemnade wrote:
> If the si2157 is behind a e.g. si2168, the si2157 will
> at least in some situations not be readable after the si268
> got the command 0101. It still accepts commands but the answer
> is just ffffff. So read the chip id before that so the
> information is not lost.
> 
> The following line in kernel output is a symptome
> of that problem:
> si2157 7-0063: unknown chip version Si21255-\xffffffff\xffffffff\xffffffff
That is hackish solution :( Somehow I2C reads should be get working 
rather than making this kind of work-around. Returning 0xff to i2c reads 
means that signal strength also shows some wrong static value?

regards
Antti

-- 
http://palosaari.fi/

Re: [PATCH 1/3] [media] si2157: get chip id during probing

[Andreas Kemnade]

[-- Attachment #1: Type: text/plain, Size: 1621 bytes --]

On Sun, 23 Apr 2017 15:19:21 +0300
Antti Palosaari <crope@iki.fi> wrote:

> On 03/16/2017 12:22 AM, Andreas Kemnade wrote:
> > If the si2157 is behind a e.g. si2168, the si2157 will
> > at least in some situations not be readable after the si268
> > got the command 0101. It still accepts commands but the answer
> > is just ffffff. So read the chip id before that so the
> > information is not lost.
> > 
> > The following line in kernel output is a symptome
> > of that problem:
> > si2157 7-0063: unknown chip version Si21255-\xffffffff\xffffffff\xffffffff
> That is hackish solution :( Somehow I2C reads should be get working 
> rather than making this kind of work-around. Returning 0xff to i2c reads 
> means that signal strength also shows some wrong static value?
> 
dvb-fe-tool -m is like this:

Lock   (0x1f) Signal= -1.00dBm C/N= 19.25dB UCB= 6061140 postBER= 40.0x10^-6

Signal strength is static.

Yes, I do not like my solution, too.
Also i2c reads from the windows driver from the si2157 after that 0101
command give such problems. I have checked my usb logs again.
So the question is where a better solution can come from.
I do not find a proper datasheet of the si2157 or the si2168.

Just for reference: the stick is labeled VG0022a.
The usb strings are like that:
  idVendor           0x1d19 Dexatek Technology Ltd.
  idProduct          0x0100 
  bcdDevice            1.00
  iManufacturer           1 ITE Tech., Inc.
  iProduct                2 TS Aggregator
  iSerial                 3 AF0102020700001

if that may lead to some information.

Regards,
Andreas

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: [PATCH 1/3] [media] si2157: get chip id during probing

[Andreas Kemnade]

[-- Attachment #1: Type: text/plain, Size: 1976 bytes --]

Hi,

On Sun, 23 Apr 2017 15:19:21 +0300
Antti Palosaari <crope@iki.fi> wrote:

> On 03/16/2017 12:22 AM, Andreas Kemnade wrote:
> > If the si2157 is behind a e.g. si2168, the si2157 will
> > at least in some situations not be readable after the si268
> > got the command 0101. It still accepts commands but the answer
> > is just ffffff. So read the chip id before that so the
> > information is not lost.
> > 
> > The following line in kernel output is a symptome
> > of that problem:
> > si2157 7-0063: unknown chip version Si21255-\xffffffff\xffffffff\xffffffff
> That is hackish solution :( Somehow I2C reads should be get working 
> rather than making this kind of work-around. Returning 0xff to i2c reads 
> means that signal strength also shows some wrong static value?
> 
Also this is needed for the Terratec CinergyTC2.
I see the ff even on windows. So it cannot be solved by usb-sniffing of
a working system, so, again how should we proceed?

a) not support dvb sticks which do not work with your preferred
   order of initialization.

b) change order of initialisation (maybe optionally add a flag like
   INIT_TUNER_BEFORE_DEMOD to avoid risk of breaking other things)

c) something like the current patch.

d) while(!i2c_readable(tuner)) {
     write_random_data_to_demod();
     write_random_data_it9306_bridge();
   }
   remember_random_data();


There was not much feedback here.

An excerpt from my windows sniff logs:
ep: 02 l:   15 GEN_I2C_WR 00 0603c6120100000000
ep: 02 l:    0
ep: 81 l:    0
ep: 81 l:    5 042300dcff
ep: 02 l:    9 GEN_I2C_RD 00 0603c6
ep: 02 l:    0
ep: 81 l:    0
ep: 81 l:   11 0a240080ffffffffff5b02
ep: 02 l:   15 GEN_I2C_WR 00 0603c6140011070300
ep: 02 l:    0
ep: 81 l:    0
ep: 81 l:    5 042500daff
ep: 02 l:    9 GEN_I2C_RD 00 0403c6
ep: 02 l:    0
ep: 81 l:    0
ep: 81 l:    9 08260080ffffff5901

here you see all the ffff from the device.



Regards,
Andreas

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: [PATCH 1/3] [media] si2157: get chip id during probing

[Antti Palosaari]

On 05/15/2017 11:28 PM, Andreas Kemnade wrote:
> Hi,
> 
> On Sun, 23 Apr 2017 15:19:21 +0300
> Antti Palosaari <crope@iki.fi> wrote:
> 
>> On 03/16/2017 12:22 AM, Andreas Kemnade wrote:
>>> If the si2157 is behind a e.g. si2168, the si2157 will
>>> at least in some situations not be readable after the si268
>>> got the command 0101. It still accepts commands but the answer
>>> is just ffffff. So read the chip id before that so the
>>> information is not lost.
>>>
>>> The following line in kernel output is a symptome
>>> of that problem:
>>> si2157 7-0063: unknown chip version Si21255-\xffffffff\xffffffff\xffffffff
>> That is hackish solution :( Somehow I2C reads should be get working
>> rather than making this kind of work-around. Returning 0xff to i2c reads
>> means that signal strength also shows some wrong static value?
>>
> Also this is needed for the Terratec CinergyTC2.
> I see the ff even on windows. So it cannot be solved by usb-sniffing of
> a working system, so, again how should we proceed?
> 
> a) not support dvb sticks which do not work with your preferred
>     order of initialization.
> 
> b) change order of initialisation (maybe optionally add a flag like
>     INIT_TUNER_BEFORE_DEMOD to avoid risk of breaking other things)
> 
> c) something like the current patch.
> 
> d) while(!i2c_readable(tuner)) {
>       write_random_data_to_demod();
>       write_random_data_it9306_bridge();
>     }
>     remember_random_data();
> 
> 
> There was not much feedback here.

If it is not possible to fix i2c communication then better to add some 
device specific logic to i2c adapter in order to meet demod/tuner 
requirements.


> 
> An excerpt from my windows sniff logs:
> ep: 02 l:   15 GEN_I2C_WR 00 0603c6120100000000
> ep: 02 l:    0
> ep: 81 l:    0
> ep: 81 l:    5 042300dcff
> ep: 02 l:    9 GEN_I2C_RD 00 0603c6
> ep: 02 l:    0
> ep: 81 l:    0
> ep: 81 l:   11 0a240080ffffffffff5b02
> ep: 02 l:   15 GEN_I2C_WR 00 0603c6140011070300
> ep: 02 l:    0
> ep: 81 l:    0
> ep: 81 l:    5 042500daff
> ep: 02 l:    9 GEN_I2C_RD 00 0403c6
> ep: 02 l:    0
> ep: 81 l:    0
> ep: 81 l:    9 08260080ffffff5901
> 
> here you see all the ffff from the device.
> 
> 
> 
> Regards,
> Andreas
> 

regards
Antti



-- 
http://palosaari.fi/

Re: [PATCH 1/3] [media] si2157: get chip id during probing

[Steven Toth]

>> ep: 81 l:    9 08260080ffffff5901
>>
>> here you see all the ffff from the device.

You need to be able to see the traffic on the physical I2C bus in
order to help diagnose issues like this. You're going to want to see
ACKS/NAKS, clocks and other I2C bus activity.

You'll need to solder down scl/sda/gnd wiring to the PCB, I generally
attached to the eeprom which tends to have larger pins (details on
their respective datasheets).

It's not hard to do, but does require a small investment in hardware.

One the actual bus behavior is documented and understood, you'll
likely get a better technical discussion going on.

Send me a detailed picture of the PCB and I can probably help spot the
I2C bus for you, if you have a low cost bus analyzer and a soldering
iron.

-- 
Steven Toth - Kernel Labs
http://www.kernellabs.com

[PATCH 2/3] [media] af9035: init i2c already in it930x_frontend_attach

[Andreas Kemnade]

i2c bus is already needed when the frontend is probed,
so init it already in it930x_frontend_attach
That prevents errors like
     si2168: probe of 6-0067 failed with error -5

Signed-off-by: Andreas Kemnade <andreas@kemnade.info>
---
 drivers/media/usb/dvb-usb-v2/af9035.c | 43 ++++++++++++++++++++++++++++++++++-
 1 file changed, 42 insertions(+), 1 deletion(-)

diff --git a/drivers/media/usb/dvb-usb-v2/af9035.c b/drivers/media/usb/dvb-usb-v2/af9035.c
index 4df9486..a95f4b2 100644
--- a/drivers/media/usb/dvb-usb-v2/af9035.c
+++ b/drivers/media/usb/dvb-usb-v2/af9035.c
@@ -1214,8 +1214,49 @@ static int it930x_frontend_attach(struct dvb_usb_adapter *adap)
 	struct si2168_config si2168_config;
 	struct i2c_adapter *adapter;
 
-	dev_dbg(&intf->dev, "adap->id=%d\n", adap->id);
+	dev_dbg(&intf->dev, "%s  adap->id=%d\n", __func__, adap->id);
+
+	/* I2C master bus 2 clock speed 300k */
+	ret = af9035_wr_reg(d, 0x00f6a7, 0x07);
+	if (ret < 0)
+		goto err;
+
+	/* I2C master bus 1,3 clock speed 300k */
+	ret = af9035_wr_reg(d, 0x00f103, 0x07);
+	if (ret < 0)
+		goto err;
+
+	/* set gpio11 low */
+	ret = af9035_wr_reg_mask(d, 0xd8d4, 0x01, 0x01);
+	if (ret < 0)
+		goto err;
+
+	ret = af9035_wr_reg_mask(d, 0xd8d5, 0x01, 0x01);
+	if (ret < 0)
+		goto err;
+
+	ret = af9035_wr_reg_mask(d, 0xd8d3, 0x01, 0x01);
+	if (ret < 0)
+		goto err;
 
+	/* Tuner enable using gpiot2_en, gpiot2_on and gpiot2_o (reset) */
+	ret = af9035_wr_reg_mask(d, 0xd8b8, 0x01, 0x01);
+	if (ret < 0)
+		goto err;
+
+	ret = af9035_wr_reg_mask(d, 0xd8b9, 0x01, 0x01);
+	if (ret < 0)
+		goto err;
+
+	ret = af9035_wr_reg_mask(d, 0xd8b7, 0x00, 0x01);
+	if (ret < 0)
+		goto err;
+
+	msleep(200);
+
+	ret = af9035_wr_reg_mask(d, 0xd8b7, 0x01, 0x01);
+	if (ret < 0)
+		goto err;
 	memset(&si2168_config, 0, sizeof(si2168_config));
 	si2168_config.i2c_adapter = &adapter;
 	si2168_config.fe = &adap->fe[0];
-- 
2.1.4

Re: [PATCH 2/3] [media] af9035: init i2c already in it930x_frontend_attach

[Andreas Kemnade]

[-- Attachment #1: Type: text/plain, Size: 1176 bytes --]

On Wed, 15 Mar 2017 23:22:09 +0100
Andreas Kemnade <andreas@kemnade.info> wrote:

> i2c bus is already needed when the frontend is probed,
> so init it already in it930x_frontend_attach
> That prevents errors like
>      si2168: probe of 6-0067 failed with error -5
> 
> Signed-off-by: Andreas Kemnade <andreas@kemnade.info>

seems to be also needed for the
CINERGY TC2 Stick
Quoting from 
https://www.linuxmintusers.de/index.php?topic=41074.30

Mar 26 12:44:14 minimoose kernel: [  732.884876] usb 1-3: dvb_usb_v2: found a 'TerraTec Cinergy TC2 Stick' in warm state
Mar 26 12:44:14 minimoose kernel: [  732.885012] usb 1-3: dvb_usb_v2: will pass the complete MPEG2 transport stream to the software demuxer
Mar 26 12:44:14 minimoose kernel: [  732.885245] dvbdev: DVB: registering new adapter (TerraTec Cinergy TC2 Stick)
Mar 26 12:44:14 minimoose kernel: [  732.885254] usb 1-3: media controller created
Mar 26 12:44:14 minimoose kernel: [  732.886117] dvbdev: dvb_create_media_entity: media entity 'dvb-demux' registered.
Mar 26 12:44:14 minimoose kernel: [  732.890589] si2168: probe of 8-0067 failed with error -5


Regards,
Andreas Kemnade

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

[PATCH 3/3] [media] af9035: add Logilink vg0022a to device id table

[Andreas Kemnade]

Ths adds the logilink VG00022a dvb-t dongle to the device table.
The dongle contains (checked by removing the case)
IT9303
SI2168
  214730

Signed-off-by: Andreas Kemnade <andreas@kemnade.info>
---
 drivers/media/usb/dvb-usb-v2/af9035.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/media/usb/dvb-usb-v2/af9035.c b/drivers/media/usb/dvb-usb-v2/af9035.c
index a95f4b2..db93e59 100644
--- a/drivers/media/usb/dvb-usb-v2/af9035.c
+++ b/drivers/media/usb/dvb-usb-v2/af9035.c
@@ -2165,6 +2165,8 @@ static const struct usb_device_id af9035_id_table[] = {
 	/* IT930x devices */
 	{ DVB_USB_DEVICE(USB_VID_ITETECH, USB_PID_ITETECH_IT9303,
 		&it930x_props, "ITE 9303 Generic", NULL) },
+	{ DVB_USB_DEVICE(USB_VID_DEXATEK, 0x0100,
+		&it930x_props, "Logilink VG0022A", NULL) },
 	{ }
 };
 MODULE_DEVICE_TABLE(usb, af9035_id_table);
-- 
2.1.4

Re: [PATCH 0/3] support for Logilink VG0022a DVB-T2 stick

[Andreas Kemnade]

[-- Attachment #1: Type: text/plain, Size: 804 bytes --]

ping

On Wed, 15 Mar 2017 23:22:07 +0100
Andreas Kemnade <andreas@kemnade.info> wrote:

> Hi all,
> here are some patches needed for supporting the
> Logilink VG0022A DVB-T2 stick.
> As the combination of chips in that stick is not
> uncommon, the first two patches might also fix problems
> for similar hardware.
> 
> Andreas Kemnade (3):
>   [media] si2157: get chip id during probing
>   [media] af9035: init i2c already in it930x_frontend_attach
>   [media] af9035: add Logilink vg0022a to device id table
> 
>  drivers/media/tuners/si2157.c         | 54 +++++++++++++++++++++--------------
>  drivers/media/tuners/si2157_priv.h    |  7 +++++
>  drivers/media/usb/dvb-usb-v2/af9035.c | 45 ++++++++++++++++++++++++++++-
>  3 files changed, 83 insertions(+), 23 deletions(-)
> 


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: [PATCH 0/3] support for Logilink VG0022a DVB-T2 stick

[Alois Fertl]

Hello All,

I'm responding to this thread because I have a Terretec CINERGY TC2 Stick, similar
chips, it9303/si2147/si2168, which shows the same problem.
Connecting a scope to the physical i2c bus between 2147 and 2168 gave some
suprising results.
With probe connected to the sda line, the i2c communication starts working reliable,
after disconnecting it failed again. Going further into it indicates that the
communication works up to the point where the loaded si2168 firmware starts executing,
guess this is after sending the \x01\x01 as already found by Andreas.
So probably the firmware configures something in the si2168 that makes
i2c bus weak? firmware issue? Even more I could imagine that some of these USB sticks
do work and others not.

I managed to fix the i2c bus by physically changing the pull-up on the sda line from 4k7
to 10k. So I have a working stick without probe being connected to test what Patches are needed.

No changes to current si2157.c and si2148.c sources are necessary in this configuration.

The only reqired changes are in af9035.c:
1st Add the Terratec to the IT903x device table.
2nd Put the it930x initialization stuff, baud rate, port etc. from it930x_tuner_attach
 also into it930x_frontend_attach. Actually it seems sufficient to have it only in
 frontend_attach.

With this I see the following and the device works fine with tvheadend:

[ 3728.290172] WARNING: You are using an experimental version of the media stack.
               	As the driver is backported to an older kernel, it doesn't offer
               	enough quality for its usage in production.
               	Use it with care.
               Latest git patches (needed if you report a bug to linux-media@vger.kernel.org):
               	61065fc3e32002ba48aa6bc3816c1f6f9f8daf55 Merge commit '3728e6a255b5' into patchwork
               	3728e6a255b50382591ee374c70e6f5276a47d0a Merge tag 'media/v4.14-2' of git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media
               	7571358dd22dc91dea560f0dde62ce23c033b6b6 media: dt: bindings: media: Document data lane numbering without lane reordering
[ 3728.319709] usbcore: registered new interface driver dvb_usb_af9035
[ 3808.368015] usb 7-6: new high-speed USB device number 2 using ehci-pci
[ 3808.519989] usb 7-6: New USB device found, idVendor=0ccd, idProduct=10b2
[ 3808.519992] usb 7-6: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[ 3808.519995] usb 7-6: Product: TS Aggregator
[ 3808.519997] usb 7-6: Manufacturer: CINERGY TC2 Stick
[ 3808.522239] dvb_usb_af9035 7-6:1.0: prechip_version=83 chip_version=01 chip_type=9306
[ 3808.522612] usb 7-6: dvb_usb_v2: found a 'TerraTec Cinergy TC2 Stick' in cold state
[ 3808.603993] usb 7-6: firmware: direct-loading firmware dvb-usb-it9303-01.fw
[ 3808.603999] usb 7-6: dvb_usb_v2: downloading firmware from file 'dvb-usb-it9303-01.fw'
[ 3808.644619] dvb_usb_af9035 7-6:1.0: firmware version=1.4.0.0
[ 3808.644631] usb 7-6: dvb_usb_v2: found a 'TerraTec Cinergy TC2 Stick' in warm state
[ 3808.644701] usb 7-6: dvb_usb_v2: will pass the complete MPEG2 transport stream to the software demuxer
[ 3808.644738] dvbdev: DVB: registering new adapter (TerraTec Cinergy TC2 Stick)
[ 3808.862180] i2c i2c-3: Added multiplexed i2c bus 4
[ 3808.862183] si2168 3-0067: Silicon Labs Si2168-B40 successfully identified
[ 3808.862186] si2168 3-0067: firmware version: B 4.0.2
[ 3808.862194] usb 7-6: DVB: registering adapter 0 frontend 0 (Silicon Labs Si2168)...
[ 3808.865004] si2157 4-0063: Silicon Labs Si2147/2148/2157/2158 successfully attached
[ 3808.885630] usb 7-6: dvb_usb_v2: 'TerraTec Cinergy TC2 Stick' successfully initialized and connected
[ 3818.832270] si2168 3-0067: firmware: direct-loading firmware dvb-demod-si2168-b40-01.fw
[ 3818.832273] si2168 3-0067: downloading firmware from file 'dvb-demod-si2168-b40-01.fw'
[ 3819.397099] si2168 3-0067: firmware version: B 4.0.11
[ 3819.409474] si2157 4-0063: found a 'Silicon Labs Si2147-A30'
[ 3819.462976] si2157 4-0063: firmware version: 3.0.5
[ 3819.462997] usb 7-6: DVB: adapter 0 frontend 0 frequency 0 out of range (42000000..870000000)

Regards,
Alois