from:"Andreas"

stk_start_stream can only be called successfully if stk_initialise and
stk_setup_format are called before. When using e.g. cheese it was observed
that stk_initialise and stk_setup_format have not been called before which
leads to no picture in that software whereas other tools like guvcview
worked flawlessly. This patch solves the issue when using e.g. cheese.

Signed-off-by: Andreas Pape 
---
 drivers/media/usb/stkwebcam/stk-webcam.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/media/usb/stkwebcam/stk-webcam.c 
b/drivers/media/usb/stkwebcam/stk-webcam.c
index e61427e50525..c64928e36a5a 100644
--- a/drivers/media/usb/stkwebcam/stk-webcam.c
+++ b/drivers/media/usb/stkwebcam/stk-webcam.c
@@ -1155,6 +1155,8 @@ static int stk_vidioc_streamon(struct file *filp,
if (dev->sio_bufs == NULL)
return -EINVAL;
dev->sequence = 0;
+   stk_initialise(dev);
+   stk_setup_format(dev);
return stk_start_stream(dev);
 }
 
-- 
2.17.1

[PATCH 1/3] media: stkwebcam: Support for ASUS A6VM notebook added.

The ASUS A6VM notebook has a built in stk11xx webcam which is mounted
in a way that the video is vertically and horizontally flipped.
Therefore this notebook is added to the special handling in the driver
to automatically flip the video into the correct orientation.

Signed-off-by: Andreas Pape 
---
 drivers/media/usb/stkwebcam/stk-webcam.c | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/drivers/media/usb/stkwebcam/stk-webcam.c 
b/drivers/media/usb/stkwebcam/stk-webcam.c
index e11d5d5b7c26..e61427e50525 100644
--- a/drivers/media/usb/stkwebcam/stk-webcam.c
+++ b/drivers/media/usb/stkwebcam/stk-webcam.c
@@ -116,6 +116,13 @@ static const struct dmi_system_id 
stk_upside_down_dmi_table[] = {
DMI_MATCH(DMI_PRODUCT_NAME, "T12Rg-H")
}
},
+   {
+   .ident = "ASUS A6VM",
+   .matches = {
+   DMI_MATCH(DMI_SYS_VENDOR, "ASUSTeK Computer Inc."),
+   DMI_MATCH(DMI_PRODUCT_NAME, "A6VM")
+   }
+   },
{}
 };
 
-- 
2.17.1

[PATCH 0/3] Fix for webcam issues with ASUS A6VM

This set of patches makes the Syntek USB webcam integrated into Asus A6VM
notebooks accessible again.

Andreas Pape (3):
  media: stkwebcam: Support for ASUS A6VM notebook added.
  media: stkwebcam: Bugfix for not correctly initialized camera
  media: stkwebcam: Bugfix for wrong return values

 drivers/media/usb/stkwebcam/stk-webcam.c | 15 ++-
 1 file changed, 14 insertions(+), 1 deletion(-)

-- 
2.17.1

[PATCH 3/3] media: stkwebcam: Bugfix for wrong return values

usb_control_msg returns in case of a successfully sent message the number
of sent bytes as a positive number. Don't use this value as a return value
for stk_camera_read_reg, as a non-zero return value is used as an error
condition in some cases when stk_camera_read_reg is called.

Signed-off-by: Andreas Pape 
---
 drivers/media/usb/stkwebcam/stk-webcam.c | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/drivers/media/usb/stkwebcam/stk-webcam.c 
b/drivers/media/usb/stkwebcam/stk-webcam.c
index c64928e36a5a..66a3665fc826 100644
--- a/drivers/media/usb/stkwebcam/stk-webcam.c
+++ b/drivers/media/usb/stkwebcam/stk-webcam.c
@@ -171,7 +171,11 @@ int stk_camera_read_reg(struct stk_camera *dev, u16 index, 
u8 *value)
*value = *buf;
 
kfree(buf);
-   return ret;
+
+   if (ret < 0)
+   return ret;
+   else
+   return 0;
 }
 
 static int stk_start_stream(struct stk_camera *dev)
-- 
2.17.1

Bug in stkwebcam?

2018-11-22 Thread Andreas Pape

Hello,

I recently updated my old 2006 Asus A6VM notebook with the latest 32bit
Ubuntu 18.04 LTS (kernel 4.15.0) and found out that the driver for the
webcam (Syntek USB2.0, USB ID 174f:a311) was not working. I only got error
messages like "Sensor resetting failed" in dmesg when starting guvcview
for example.

Far from being an expert for video devices, I tried to debug this and
figured out three patches to make the webcam work again on my old notebook
(at least I get a video again ;-).

I know the type of notebook and webcam is pretty old and the driver seems
not to be actively maintained anymore although still being part of actual
kernel versions.

Is there still an interest in getting patches for such an old device? If
yes, I could try to rebase my patches to the actual version of media_tree.git
and post them to the mailing list.

Kind regards,
Andreas

Re: [PATCH v1 1/6] DT bindings: add bindings for ov965x camera module

2017-06-23 Thread Andreas Färber

Am 23.06.2017 um 16:53 schrieb H. Nikolaus Schaller:
> Hi Laurent,
> 
>> Am 23.06.2017 um 13:58 schrieb Laurent Pinchart 
>> <laurent.pinch...@ideasonboard.com>:
>>
>> Hi Nikolaus,
>>
>> On Friday 23 Jun 2017 12:59:24 H. Nikolaus Schaller wrote:
>>> Am 23.06.2017 um 12:46 schrieb Andreas Färber <afaer...@suse.de>:
>>>> Am 23.06.2017 um 12:25 schrieb H. Nikolaus Schaller:
>>>>>> diff --git a/Documentation/devicetree/bindings/media/i2c/ov965x.txt
>>>>>> b/Documentation/devicetree/bindings/media/i2c/ov965x.txt new file mode
>>>>>> 100644
>>>>>> index 000..0e0de1f
>>>>>> --- /dev/null
>>>>>> +++ b/Documentation/devicetree/bindings/media/i2c/ov965x.txt
>>>>>> @@ -0,0 +1,37 @@
>>>>>> +* Omnivision OV9650/9652/9655 CMOS sensor
>>>>>> +
>>>>>> +The Omnivision OV965x sensor support multiple resolutions output, such
>>>>>> as
>>>>>> +CIF, SVGA, UXGA. It also can support YUV422/420, RGB565/555 or raw RGB
>>>>>> +output format.
>>>>>> +
>>>>>> +Required Properties:
>>>>>> +- compatible: should be one of
>>>>>> +"ovti,ov9650"
>>>>>> +"ovti,ov9652"
>>>>>> +"ovti,ov9655"
>>>>>> +- clocks: reference to the mclk input clock.
>>>>>
>>>>> I wonder why you have removed the clock-frequency property?
>>>>>
>>>>> In some situations the camera driver must be able to tell the clock
>>>>> source which frequency it wants to see.
>>>>
>>>> That's what assigned-clock-rates property is for:
>>>>
>>>> https://www.kernel.org/doc/Documentation/devicetree/bindings/clock/clock-b
>>>> indings.txt
>>>>
>>>> AFAIU clock-frequency on devices is deprecated and equivalent to having
>>>> a clocks property pointing to a fixed-clock, which is different from a
>>>> clock with varying rate.
>>>
>>> I am not sure if that helps here. The OMAP3-ISP does not have a fixed clock
>>> rate so we can only have the driver define what it wants to see.
>>>
>>> And common practise for OMAP3-ISP based camera modules (e.g. N900, N9) is
>>> that they do it in the driver.
>>>
>>> Maybe ISP developers can comment?
>>
>> The OMAP3 ISP is a variable-frequency clock provider. The clock frequency is 
>> controlled by the clock consumer. As such, it's up to the consumer to decide 
>> whether to compute and request the clock rate dynamically at runtime, or use 
>> the assigned-clock-rates property in DT.
>>
>> Some ISPs include a clock generator, others don't. It should make no 
>> difference whether the clock is provided by the ISP, by a dedicated clock 
>> source in the SoC or by a discrete on-board adjustable clock source.
> 
> Thanks for explaining the background.
> 
> Do you have an hint or example how to use the assigned-clock-rates property in
> a DT for a camera module connected to the omap3isp?
> 
> Or does it just mean that it defines the property name?

Please read the documentation link I sent - it's in the very bottom and
should have an example.

Regards,
Andreas

-- 
SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Felix Imendörffer, Jane Smithard, Graham Norton
HRB 21284 (AG Nürnberg)

Re: [PATCH v1 1/6] DT bindings: add bindings for ov965x camera module

2017-06-23 Thread Andreas Färber

Hi,

Am 23.06.2017 um 12:25 schrieb H. Nikolaus Schaller:
>> diff --git a/Documentation/devicetree/bindings/media/i2c/ov965x.txt 
>> b/Documentation/devicetree/bindings/media/i2c/ov965x.txt
>> new file mode 100644
>> index 000..0e0de1f
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/media/i2c/ov965x.txt
>> @@ -0,0 +1,37 @@
>> +* Omnivision OV9650/9652/9655 CMOS sensor
>> +
>> +The Omnivision OV965x sensor support multiple resolutions output, such as
>> +CIF, SVGA, UXGA. It also can support YUV422/420, RGB565/555 or raw RGB
>> +output format.
>> +
>> +Required Properties:
>> +- compatible: should be one of
>> +"ovti,ov9650"
>> +"ovti,ov9652"
>> +"ovti,ov9655"
>> +- clocks: reference to the mclk input clock.
> 
> I wonder why you have removed the clock-frequency property?
> 
> In some situations the camera driver must be able to tell the clock source
> which frequency it wants to see.

That's what assigned-clock-rates property is for:

https://www.kernel.org/doc/Documentation/devicetree/bindings/clock/clock-bindings.txt

AFAIU clock-frequency on devices is deprecated and equivalent to having
a clocks property pointing to a fixed-clock, which is different from a
clock with varying rate.

Regards,
Andreas

-- 
SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Felix Imendörffer, Jane Smithard, Graham Norton
HRB 21284 (AG Nürnberg)

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

2017-05-15 Thread Andreas Kemnade

Hi,

On Sun, 23 Apr 2017 15:19:21 +0300
Antti Palosaari <cr...@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 ff. 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-\x\x\x
> 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 0603c61201
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 0a240080ff5b02
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 08260080ff5901

here you see all the  from the device.



Regards,
Andreas


pgpDyMS3sfzP5.pgp
Description: OpenPGP digital signature

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

2017-05-04 Thread Andreas Kemnade

On Wed, 15 Mar 2017 23:22:09 +0100
Andreas Kemnade <andr...@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 <andr...@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


pgpF5dcxduV9N.pgp
Description: OpenPGP digital signature

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

2017-04-23 Thread Andreas Kemnade

On Sun, 23 Apr 2017 15:19:21 +0300
Antti Palosaari <cr...@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 ff. 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-\x\x\x
> 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 
  bcdDevice1.00
  iManufacturer   1 ITE Tech., Inc.
  iProduct2 TS Aggregator
  iSerial     3 AF010202071

if that may lead to some information.

Regards,
Andreas

pgpxIyxmq9Vjg.pgp
Description: OpenPGP digital signature

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

2017-04-10 Thread Andreas Kemnade

ping

On Wed, 15 Mar 2017 23:22:07 +0100
Andreas Kemnade <andr...@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(-)
> 



pgpWXfZ3ZwVSm.pgp
Description: OpenPGP digital signature

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

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 <andr...@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,
_props, "ITE 9303 Generic", NULL) },
+   { DVB_USB_DEVICE(USB_VID_DEXATEK, 0x0100,
+   _props, "Logilink VG0022A", NULL) },
{ }
 };
 MODULE_DEVICE_TABLE(usb, af9035_id_table);
-- 
2.1.4

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

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 ff. 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-\x\x\x

Signed-off-by: Andreas Kemnade <andr...@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(>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, );
-   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(>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(>ops.tuner_ops, _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, );
+   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, );
+   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(>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

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

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 2/3] [media] af9035: init i2c already in it930x_frontend_attach

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 <andr...@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(>dev, "adap->id=%d\n", adap->id);
+   dev_dbg(>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(_config, 0, sizeof(si2168_config));
si2168_config.i2c_adapter = 
si2168_config.fe = >fe[0];
-- 
2.1.4

Re: [PATCH RFC] dvb: af9035.c: Logilink vg0022a to device id table

2017-03-14 Thread Andreas Kemnade

On Thu,  9 Mar 2017 17:51:14 +0100
Andreas Kemnade <andr...@kemnade.info> wrote:

> Ths adds the logilink VG00022a dvb-t dongle to the device table.
> The dongle contains (checked by removing the case)
> IT9303
> SI2168
>   214730
> 
> The result is in cold state:
> 
>  usb 1-6: new high-speed USB device number 15 using xhci_hcd
>  usb 1-6: New USB device found, idVendor=1d19, idProduct=0100
>  usb 1-6: New USB device strings: Mfr=1, Product=2, SerialNumber=3
>  usb 1-6: Product: TS Aggregator
>  usb 1-6: Manufacturer: ITE Tech., Inc.
>  usb 1-6: SerialNumber: 
>  dvb_usb_af9035 1-6:1.0: prechip_version=83 chip_version=01 chip_type=9306
>  dvb_usb_af9035 1-6:1.0: ts mode=5 not supported, defaulting to single tuner 
> mode!
>  usb 1-6: dvb_usb_v2: found a 'Logilink VG0022A' in cold state
>  usb 1-6: dvb_usb_v2: downloading firmware from file 'dvb-usb-it9303-01.fw'
>  dvb_usb_af9035 1-6:1.0: firmware version=1.4.0.0
>  usb 1-6: dvb_usb_v2: found a 'Logilink VG0022A' in warm state
>  usb 1-6: dvb_usb_v2: will pass the complete MPEG2 transport stream to the 
> software demuxer
>  dvbdev: DVB: registering new adapter (Logilink VG0022A)
>  si2168: probe of 6-0067 failed with error -5
> 
> when warmed up by connecing it via  a powered usb hub to win7 and
> then attaching the same usb hub to a linux machine:
> 
with some fixes in af9035.c I already get the same state as with warm
up by win7. I just need to find out which changes are really necessary
and convert it into a clean patch.

> so firmware uploading to the si2168 somehow messes things up
> 
I experimented a lot here and I found this:
If 0101 is not sent to the si2168 you can get answers from the
Si2147-A30. 
After the 0101 is sent to the si2147-A30 it will still execute
commands but you will not get the answer back through the si2168.
You just get ff.

After moving the chip id readout from si2157_init to si2157_probe,
scanning for stations works. So the si2147-A30 seems to react on
commands. 

Regards,
Andreas Kemnade


pgp27dH4ipAAt.pgp
Description: OpenPGP digital signature

[PATCH RFC] dvb: af9035.c: Logilink vg0022a to device id table

2017-03-09 Thread 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

The result is in cold state:

 usb 1-6: new high-speed USB device number 15 using xhci_hcd
 usb 1-6: New USB device found, idVendor=1d19, idProduct=0100
 usb 1-6: New USB device strings: Mfr=1, Product=2, SerialNumber=3
 usb 1-6: Product: TS Aggregator
 usb 1-6: Manufacturer: ITE Tech., Inc.
 usb 1-6: SerialNumber: 
 dvb_usb_af9035 1-6:1.0: prechip_version=83 chip_version=01 chip_type=9306
 dvb_usb_af9035 1-6:1.0: ts mode=5 not supported, defaulting to single tuner 
mode!
 usb 1-6: dvb_usb_v2: found a 'Logilink VG0022A' in cold state
 usb 1-6: dvb_usb_v2: downloading firmware from file 'dvb-usb-it9303-01.fw'
 dvb_usb_af9035 1-6:1.0: firmware version=1.4.0.0
 usb 1-6: dvb_usb_v2: found a 'Logilink VG0022A' in warm state
 usb 1-6: dvb_usb_v2: will pass the complete MPEG2 transport stream to the 
software demuxer
 dvbdev: DVB: registering new adapter (Logilink VG0022A)
 si2168: probe of 6-0067 failed with error -5

when warmed up by connecing it via  a powered usb hub to win7 and
then attaching the same usb hub to a linux machine:

 usb 1-6.2: New USB device found, idVendor=1d19, idProduct=0100
 usb 1-6.2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
 usb 1-6.2: Product: TS Aggregator
 usb 1-6.2: Manufacturer: ITE Tech., Inc.
 usb 1-6.2: SerialNumber: 
 dvb_usb_af9035 1-6.2:1.0: prechip_version=83 chip_version=01 chip_type=9306
 dvb_usb_af9035 1-6.2:1.0: ts mode=5 not supported, defaulting to single tuner 
mode!
 usb 1-6.2: dvb_usb_v2: found a 'Logilink VG0022A' in warm state
 usb 1-6.2: dvb_usb_v2: will pass the complete MPEG2 transport stream to the 
software demuxer
 dvbdev: DVB: registering new adapter (Logilink VG0022A)
 i2c i2c-6: Added multiplexed i2c bus 7
 si2168 6-0067: Silicon Labs Si2168-B40 successfully identified
 si2168 6-0067: firmware version: B 4.0.2
 usb 1-6.2: DVB: registering adapter 0 frontend 0 (Silicon Labs Si2168)...
 si2157 7-0063: Silicon Labs Si2147/2148/2157/2158 successfully attached
 usb 1-6.2: dvb_usb_v2: 'Logilink VG0022A' successfully initialized and 
connected
 si2168 6-0067: Direct firmware load for dvb-demod-si2168-b40-01.fw failed with 
error -2
 si2168 6-0067: Direct firmware load for dvb-demod-si2168-02.fw failed with 
error -2
 si2168 6-0067: firmware file 'dvb-demod-si2168-02.fw' not found
 si2157 7-0063: found a 'Silicon Labs Si2147-A30'
 si2157 7-0063: firmware version: 3.0.5

same with the firmware for the si2168 available:
 usb 1-6.2: new high-speed USB device number 12 using xhci_hcd
 usb 1-6.2: New USB device found, idVendor=1d19, idProduct=0100
 usb 1-6.2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
 usb 1-6.2: Product: TS Aggregator
 usb 1-6.2: Manufacturer: ITE Tech., Inc.
 usb 1-6.2: SerialNumber: 
 dvb_usb_af9035 1-6.2:1.0: prechip_version=83 chip_version=01 chip_type=9306
 dvb_usb_af9035 1-6.2:1.0: ts mode=5 not supported, defaulting to single tuner 
mode!
 usb 1-6.2: dvb_usb_v2: found a 'Logilink VG0022A' in warm state
 usb 1-6.2: dvb_usb_v2: will pass the complete MPEG2 transport stream to the 
software demuxer
 dvbdev: DVB: registering new adapter (Logilink VG0022A)
 i2c i2c-6: Added multiplexed i2c bus 7
 si2168 6-0067: Silicon Labs Si2168-B40 successfully identified
 si2168 6-0067: firmware version: B 4.0.2
 usb 1-6.2: DVB: registering adapter 0 frontend 0 (Silicon Labs Si2168)...
 si2157 7-0063: Silicon Labs Si2147/2148/2157/2158 successfully attached
 usb 1-6.2: dvb_usb_v2: 'Logilink VG0022A' successfully initialized and 
connected
 si2168 6-0067: downloading firmware from file 'dvb-demod-si2168-b40-01.fw'
 si2168 6-0067: firmware version: B 4.0.11
 si2157 7-0063: unknown chip version Si21255-\x\x\x
 si2157 7-0063: unknown chip version Si21255-\x\x\x

so firmware uploading to the si2168 somehow messes things up

Signed-off-by: Andreas Kemnade <andr...@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 c673726..ed674b8 100644
--- a/drivers/media/usb/dvb-usb-v2/af9035.c
+++ b/drivers/media/usb/dvb-usb-v2/af9035.c
@@ -2141,6 +2141,8 @@ static const struct usb_device_id af9035_id_table[] = {
/* IT930x devices */
{ DVB_USB_DEVICE(USB_VID_ITETECH, USB_PID_ITETECH_IT9303,
_props, "ITE 9303 Generic", NULL) },
+   { DVB_USB_DEVICE(USB_VID_DEXATEK, 0x0100,
+   _props, "Logilink VG0022A", NULL) },
{ }
 };
 MODULE_DEVICE_TABLE(usb, af9035_id_table);
-- 
2.1.4

Re: [PATCH v2] Documentation: devicetree: meson-ir: "linux,rc-map-name" is supported

2017-02-02 Thread Andreas Färber

Am 01.02.2017 um 23:26 schrieb Martin Blumenstingl:
> On Wed, Feb 1, 2017 at 11:14 PM, Martin Blumenstingl
> <martin.blumensti...@googlemail.com> wrote:
>> The driver already parses the "linux,rc-map-name" property. Add this
>> information to the documentation so .dts maintainers don't have to look
>> it up in the source-code.
>>
>> Signed-off-by: Martin Blumenstingl <martin.blumensti...@googlemail.com>
>> Acked-by: Rob Herring <r...@kernel.org>
>> ---
>> Changes since v1:
>> - removed character which shows up as whitespace from subject
> I have verified that I really sent this without a whitespace (I'm
> using git send-email, so the patch is not mangled by some webmailer) -
> unfortunately it seems to appear again (maybe one of the receiving
> mail-servers or the mailing-list software does something weird here).

Shows up fine here now,

Reviewed-by: Andreas Färber <afaer...@suse.de>

Didn't expect a resend for that btw.

Thanks,
Andreas

-- 
SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Felix Imendörffer, Jane Smithard, Graham Norton
HRB 21284 (AG Nürnberg)
--
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] Documentation: devicetree: meson-ir: "linux, rc-map-name" is supported

2017-02-01 Thread Andreas Färber

Am 01.02.2017 um 18:47 schrieb Rob Herring:
> On Tue, Jan 31, 2017 at 10:21:12PM +0100, Martin Blumenstingl wrote:
>> The driver already parses the "linux,rc-map-name" property. Add this
>> information to the documentation so .dts maintainers don't have to look
>> it up in the source-code.
>>
>> Signed-off-by: Martin Blumenstingl <martin.blumensti...@googlemail.com>
>> ---
>>  Documentation/devicetree/bindings/media/meson-ir.txt | 3 +++
>>  1 file changed, 3 insertions(+)
> 
> Acked-by: Rob Herring <r...@kernel.org>

Note that the subject has a space in the property name that should be
dropped before applying.

Regards,
Andreas

-- 
SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Felix Imendörffer, Jane Smithard, Graham Norton
HRB 21284 (AG Nürnberg)
--
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: LinuxTv doesn't build anymore after upgrading Ubuntu to 3.13.0-88



Am 13.06.2016 um 21:01 schrieb Hans Verkuil:

On 06/13/2016 08:52 PM, Andreas Matthies wrote:

But now I get
...
CC [M]  /home/andreas/Downloads/media_build/v4l/uvc_v4l2.o
CC [M]  /home/andreas/Downloads/media_build/v4l/uvc_video.o
/home/andreas/Downloads/media_build/v4l/uvc_video.c: In function
'uvc_endpoint_max_bpi':
/home/andreas/Downloads/media_build/v4l/uvc_video.c:1473:7: error:
'USB_SPEED_SUPER_PLUS' undeclared (first use in this function)
case USB_SPEED_SUPER_PLUS:
 ^

When building for 4.6? I know this fails for older kernels but it should be fine
for the 4.6 kernel.

I'll make a patch fixing this some time this week though.


No, I'm running and (hopefully) building for 3.11:
andreas@andreas-xubuntu:~$ uname -a
Linux andreas-xubuntu 3.13.0-88-generic #135-Ubuntu SMP Wed Jun 8 
21:10:42 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux


I have worked around that bug just by deleting the line using 
USB_SPEED_SUPER_PLUS for now but a clean patch for that would be better.


. Andreas


--
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: LinuxTv doesn't build anymore after upgrading Ubuntu to 3.13.0-88


But now I get
...
  CC [M]  /home/andreas/Downloads/media_build/v4l/uvc_v4l2.o
  CC [M]  /home/andreas/Downloads/media_build/v4l/uvc_video.o
/home/andreas/Downloads/media_build/v4l/uvc_video.c: In function 
'uvc_endpoint_max_bpi':
/home/andreas/Downloads/media_build/v4l/uvc_video.c:1473:7: error: 
'USB_SPEED_SUPER_PLUS' undeclared (first use in this function)

  case USB_SPEED_SUPER_PLUS:
   ^
/home/andreas/Downloads/media_build/v4l/uvc_video.c:1473:7: note: each 
undeclared identifier is reported only once for each function it appears in

make[3]: *** [/home/andreas/Downloads/media_build/v4l/uvc_video.o] Fehler 1
make[2]: *** [_module_/home/andreas/Downloads/media_build/v4l] Error 2
...

Am 13.06.2016 um 19:55 schrieb Hans Verkuil:

On 06/13/2016 07:14 PM, Andreas Matthies wrote:

Hi.

Seems that there's a problem in v4.6_i2c_mux.patch. After Ubuntu was
upgraded to 3.13.0-88 I tried to rebuild the tv drivers and get

make[2]: Entering directory `/home/andreas/Downloads/media_build/linux'
Applying patches for kernel 3.13.0-88-generic
patch -s -f -N -p1 -i ../backports/api_version.patch
patch -s -f -N -p1 -i ../backports/pr_fmt.patch
patch -s -f -N -p1 -i ../backports/debug.patch
patch -s -f -N -p1 -i ../backports/drx39xxj.patch
patch -s -f -N -p1 -i ../backports/v4.6_i2c_mux.patch
2 out of 23 hunks FAILED
make[2]: *** [apply_patches] Error 1

Fixed. Thanks for reporting this.

Regards,

Hans


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

Re: LinuxTv doesn't build anymore after upgrading Ubuntu to 3.13.0-88




Am 13.06.2016 um 19:55 schrieb Hans Verkuil:

On 06/13/2016 07:14 PM, Andreas Matthies wrote:

Hi.

Seems that there's a problem in v4.6_i2c_mux.patch. After Ubuntu was
upgraded to 3.13.0-88 I tried to rebuild the tv drivers and get

make[2]: Entering directory `/home/andreas/Downloads/media_build/linux'
Applying patches for kernel 3.13.0-88-generic
patch -s -f -N -p1 -i ../backports/api_version.patch
patch -s -f -N -p1 -i ../backports/pr_fmt.patch
patch -s -f -N -p1 -i ../backports/debug.patch
patch -s -f -N -p1 -i ../backports/drx39xxj.patch
patch -s -f -N -p1 -i ../backports/v4.6_i2c_mux.patch
2 out of 23 hunks FAILED
make[2]: *** [apply_patches] Error 1

Fixed. Thanks for reporting this.


That was fast! Thanks.
--
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

LinuxTv doesn't build anymore after upgrading Ubuntu to 3.13.0-88


Hi.

Seems that there's a problem in v4.6_i2c_mux.patch. After Ubuntu was 
upgraded to 3.13.0-88 I tried to rebuild the tv drivers and get


make[2]: Entering directory `/home/andreas/Downloads/media_build/linux'
Applying patches for kernel 3.13.0-88-generic
patch -s -f -N -p1 -i ../backports/api_version.patch
patch -s -f -N -p1 -i ../backports/pr_fmt.patch
patch -s -f -N -p1 -i ../backports/debug.patch
patch -s -f -N -p1 -i ../backports/drx39xxj.patch
patch -s -f -N -p1 -i ../backports/v4.6_i2c_mux.patch
2 out of 23 hunks FAILED
make[2]: *** [apply_patches] Error 1

Here's the reject file rtl2832.c.rej:
--- drivers/media/dvb-frontends/rtl2832.c
+++ drivers/media/dvb-frontends/rtl2832.c
@@ -1124,7 +1280,7 @@
 else
 u8tmp = 0x00;

-ret = regmap_update_bits(dev->regmap, 0x061, 0xc0, u8tmp);
+ret = rtl2832_update_bits(client, 0x061, 0xc0, u8tmp);
 if (ret)
 goto err;

@@ -1159,14 +1315,14 @@
 buf[1] = (dev->filters >>  8) & 0xff;
 buf[2] = (dev->filters >> 16) & 0xff;
 buf[3] = (dev->filters >> 24) & 0xff;
-ret = regmap_bulk_write(dev->regmap, 0x062, buf, 4);
+ret = rtl2832_bulk_write(client, 0x062, buf, 4);
 if (ret)
 goto err;

 /* add PID */
 buf[0] = (pid >> 8) & 0xff;
 buf[1] = (pid >> 0) & 0xff;
-ret = regmap_bulk_write(dev->regmap, 0x066 + 2 * index, buf, 2);
+ret = rtl2832_bulk_write(client, 0x066 + 2 * index, buf, 2);
 if (ret)
 goto err;

And here's what the source file contains for the first reject:
...
else
u8tmp = 0x00;

if (dev->slave_ts)
ret = regmap_update_bits(dev->regmap, 0x021, 0xc0, u8tmp);
else
ret = regmap_update_bits(dev->regmap, 0x061, 0xc0, u8tmp);
if (ret)
    goto err;
...

Hope you can make the drivers compile again soon.

. Andreas



--
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: [RFT PATCH] [media] exynos4-is: Fix fimc_is_parse_sensor_config() nodes handling

2016-03-23 Thread Andreas Färber

Hi Javier,

Am 23.03.2016 um 17:15 schrieb Javier Martinez Canillas:
> The same struct device_node * is used for looking up the I2C sensor, OF
> graph endpoint and port. So the reference count is incremented but not
> decremented for the endpoint and port nodes.
> 
> Fix this by having separate pointers for each node looked up.
> 
> Signed-off-by: Javier Martinez Canillas <jav...@osg.samsung.com>
[...]
> diff --git a/drivers/media/platform/exynos4-is/fimc-is.c 
> b/drivers/media/platform/exynos4-is/fimc-is.c
> index 979c388ebf60..0b04a5d25187 100644
> --- a/drivers/media/platform/exynos4-is/fimc-is.c
> +++ b/drivers/media/platform/exynos4-is/fimc-is.c
> @@ -165,6 +165,7 @@ static int fimc_is_parse_sensor_config(struct fimc_is 
> *is, unsigned int index,
>   struct device_node *node)
>  {
>   struct fimc_is_sensor *sensor = >sensor[index];
> + struct device_node *ep, *port;
>   u32 tmp = 0;
>   int ret;
>  
> @@ -175,16 +176,18 @@ static int fimc_is_parse_sensor_config(struct fimc_is 
> *is, unsigned int index,
>   return -EINVAL;
>   }
>  
> - node = of_graph_get_next_endpoint(node, NULL);
> - if (!node)
> + ep = of_graph_get_next_endpoint(node, NULL);
> + if (!ep)
>   return -ENXIO;
>  
> - node = of_graph_get_remote_port(node);
> - if (!node)
> + port = of_graph_get_remote_port(ep);
> + of_node_put(ep);
> + if (!port)
>   return -ENXIO;
>  
>   /* Use MIPI-CSIS channel id to determine the ISP I2C bus index. */
> - ret = of_property_read_u32(node, "reg", );
> + ret = of_property_read_u32(port, "reg", );
> + of_node_put(port);
>   if (ret < 0) {
>   dev_err(>pdev->dev, "reg property not found at: %s\n",
>node->full_name);

port->full_name. You'll need to defer the of_node_put(port) then.

Regards,
Andreas

-- 
SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Felix Imendörffer, Jane Smithard, Graham Norton; HRB 21284 (AG Nürnberg)
--
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/7] [media] dvb: use ktime_t for internal timeout

2015-09-15 Thread Andreas Oberritter

Hello Arnd,

On 15.09.2015 17:49, Arnd Bergmann wrote:
> The dvb demuxer code uses a 'struct timespec' to pass a timeout
> as absolute time. This will cause problems on 32-bit architectures
> in 2038 when time_t overflows, and it is racy with a concurrent
> settimeofday() call.
> 
> This patch changes the code to use ktime_get() instead, using
> the monotonic time base to avoid both the race and the overflow.
> 
> Signed-off-by: Arnd Bergmann <a...@arndb.de>
> ---
>  drivers/media/dvb-core/demux.h |  2 +-
>  drivers/media/dvb-core/dmxdev.c|  2 +-
>  drivers/media/dvb-core/dvb_demux.c | 17 ++---
>  drivers/media/dvb-core/dvb_demux.h |  4 ++--
>  drivers/media/dvb-core/dvb_net.c   |  2 +-
>  5 files changed, 11 insertions(+), 16 deletions(-)
> 
> diff --git a/drivers/media/dvb-core/demux.h b/drivers/media/dvb-core/demux.h
> index 833191bcd810..d8e2b1213bef 100644
> --- a/drivers/media/dvb-core/demux.h
> +++ b/drivers/media/dvb-core/demux.h
> @@ -92,7 +92,7 @@ struct dmx_ts_feed {
>   int type,
>   enum dmx_ts_pes pes_type,
>   size_t circular_buffer_size,
> - struct timespec timeout);
> + ktime_t timeout);
>   int (*start_filtering) (struct dmx_ts_feed* feed);
>   int (*stop_filtering) (struct dmx_ts_feed* feed);
>  };
> diff --git a/drivers/media/dvb-core/dmxdev.c b/drivers/media/dvb-core/dmxdev.c
> index d0e3f9d85f34..0d20b379eeec 100644
> --- a/drivers/media/dvb-core/dmxdev.c
> +++ b/drivers/media/dvb-core/dmxdev.c
> @@ -558,7 +558,7 @@ static int dvb_dmxdev_start_feed(struct dmxdev *dmxdev,
>struct dmxdev_filter *filter,
>struct dmxdev_feed *feed)
>  {
> - struct timespec timeout = { 0 };
> + ktime_t timeout = ktime_set(0, 0);
>   struct dmx_pes_filter_params *para = >params.pes;
>   dmx_output_t otype;
>   int ret;
> diff --git a/drivers/media/dvb-core/dvb_demux.c 
> b/drivers/media/dvb-core/dvb_demux.c
> index 6c7ff0cdcd32..d83dd0eb5757 100644
> --- a/drivers/media/dvb-core/dvb_demux.c
> +++ b/drivers/media/dvb-core/dvb_demux.c
> @@ -399,28 +399,23 @@ static void dvb_dmx_swfilter_packet(struct dvb_demux 
> *demux, const u8 *buf)
>   int dvr_done = 0;
>  
>   if (dvb_demux_speedcheck) {
> - struct timespec cur_time, delta_time;
> + ktime_t cur_time;
>   u64 speed_bytes, speed_timedelta;
>  
>   demux->speed_pkts_cnt++;
>  
>   /* show speed every SPEED_PKTS_INTERVAL packets */
>   if (!(demux->speed_pkts_cnt % SPEED_PKTS_INTERVAL)) {
> - cur_time = current_kernel_time();
> + cur_time = ktime_get();
>  
> - if (demux->speed_last_time.tv_sec != 0 &&
> - demux->speed_last_time.tv_nsec != 0) {
> - delta_time = timespec_sub(cur_time,
> -     demux->speed_last_time);
> + if (ktime_to_ns(demux->speed_last_time) == 0) {

if ktime_to_ns does what I think it does, then you should invert the logic.

Regards,
Andreas

>   speed_bytes = (u64)demux->speed_pkts_cnt
>   * 188 * 8;
>   /* convert to 1024 basis */
>   speed_bytes = 1000 * div64_u64(speed_bytes,
>   1024);
> - speed_timedelta =
> - (u64)timespec_to_ns(_time);
> - speed_timedelta = div64_u64(speed_timedelta,
> - 100); /* nsec -> usec */
> + speed_timedelta = ktime_ms_delta(cur_time,
> + demux->speed_last_time);
>   printk(KERN_INFO "TS speed %llu Kbits/sec \n",
>   div64_u64(speed_bytes,
>   speed_timedelta));
> @@ -667,7 +662,7 @@ out:
>  
>  static int dmx_ts_feed_set(struct dmx_ts_feed *ts_feed, u16 pid, int ts_type,
>  enum dmx_ts_pes pes_type,
> -size_t circular_buffer_size, struct timespec timeout)
> +size_t circular_buffer_size, ktime_t timeout)
>  {
>   struct dvb_demux_feed *feed = (struct dvb_demux_feed *)ts_feed;
>   struct dvb_demux *demux = feed->demux;
> diff --git a/drivers/media/dv

[PATCH] media: pci: smipcie: Fix dependency for DVB_SMIPCIE

2014-11-21 Thread Andreas Ruprecht

In smipcie.c, the function i2c_bit_add_bus() is called. This
function is defined by the I2C bit-banging interfaces enabled
with CONFIG_I2C_ALGOBIT.

As there was no dependency in Kconfig, CONFIG_I2C_ALGOBIT could
be set to m while CONFIG_DVB_SMIPCIE was set to y, resulting
in a build error due to an undefined reference. This patch adds
the dependency on CONFIG_I2C_ALGOBIT in Kconfig.

Signed-off-by: Andreas Ruprecht rup...@einserver.de
Reported-by: Jim Davis jim.ep...@gmail.com
---
 drivers/media/pci/smipcie/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/media/pci/smipcie/Kconfig 
b/drivers/media/pci/smipcie/Kconfig
index 75a2992..c728721 100644
--- a/drivers/media/pci/smipcie/Kconfig
+++ b/drivers/media/pci/smipcie/Kconfig
@@ -1,6 +1,6 @@
 config DVB_SMIPCIE
tristate SMI PCIe DVBSky cards
-   depends on DVB_CORE  PCI  I2C
+   depends on DVB_CORE  PCI  I2C  I2C_ALGOBIT
select DVB_M88DS3103 if MEDIA_SUBDRV_AUTOSELECT
select MEDIA_TUNER_M88TS2022 if MEDIA_SUBDRV_AUTOSELECT
select MEDIA_TUNER_M88RS6000T if MEDIA_SUBDRV_AUTOSELECT
-- 
1.9.1

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

Re: [PATCH] media: pci: smipcie: Fix dependency for DVB_SMIPCIE

2014-11-21 Thread Andreas Ruprecht

On 21.11.2014 19:13, Mauro Carvalho Chehab wrote:
 Em Fri, 21 Nov 2014 18:51:59 +0100
 Andreas Ruprecht rup...@einserver.de escreveu:
 
 In smipcie.c, the function i2c_bit_add_bus() is called. This
 function is defined by the I2C bit-banging interfaces enabled
 with CONFIG_I2C_ALGOBIT.

 As there was no dependency in Kconfig, CONFIG_I2C_ALGOBIT could
 be set to m while CONFIG_DVB_SMIPCIE was set to y, resulting
 in a build error due to an undefined reference. This patch adds
 the dependency on CONFIG_I2C_ALGOBIT in Kconfig.

 Signed-off-by: Andreas Ruprecht rup...@einserver.de
 Reported-by: Jim Davis jim.ep...@gmail.com
 ---
  drivers/media/pci/smipcie/Kconfig | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

 diff --git a/drivers/media/pci/smipcie/Kconfig 
 b/drivers/media/pci/smipcie/Kconfig
 index 75a2992..c728721 100644
 --- a/drivers/media/pci/smipcie/Kconfig
 +++ b/drivers/media/pci/smipcie/Kconfig
 @@ -1,6 +1,6 @@
  config DVB_SMIPCIE
  tristate SMI PCIe DVBSky cards
 -depends on DVB_CORE  PCI  I2C
 +depends on DVB_CORE  PCI  I2C  I2C_ALGOBIT
 
 IMHO, the best would be, instead, to select I2C_ALGOBIT.

Okay, I'll change that and submit a new version of this patch.

Regards,

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

[PATCH v2] media: pci: smipcie: Fix dependency for DVB_SMIPCIE

2014-11-21 Thread Andreas Ruprecht

In smipcie.c, the function i2c_bit_add_bus() is called. This
function is defined by the I2C bit-banging interfaces enabled
with CONFIG_I2C_ALGOBIT.

As there was no dependency in Kconfig, CONFIG_I2C_ALGOBIT could
be set to m while CONFIG_DVB_SMIPCIE was set to y, resulting
in a build error due to an undefined reference.

This patch adds the dependency on CONFIG_I2C_ALGOBIT in Kconfig
by selecting it when CONFIG_DVB_SMIPCIE is selected.

Signed-off-by: Andreas Ruprecht rup...@einserver.de
Reported-by: Jim Davis jim.ep...@gmail.com
---
 drivers/media/pci/smipcie/Kconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/media/pci/smipcie/Kconfig 
b/drivers/media/pci/smipcie/Kconfig
index 75a2992..57dd124 100644
--- a/drivers/media/pci/smipcie/Kconfig
+++ b/drivers/media/pci/smipcie/Kconfig
@@ -1,6 +1,7 @@
 config DVB_SMIPCIE
tristate SMI PCIe DVBSky cards
depends on DVB_CORE  PCI  I2C
+   select I2C_ALGOBIT
select DVB_M88DS3103 if MEDIA_SUBDRV_AUTOSELECT
select MEDIA_TUNER_M88TS2022 if MEDIA_SUBDRV_AUTOSELECT
select MEDIA_TUNER_M88RS6000T if MEDIA_SUBDRV_AUTOSELECT
-- 
1.9.1

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

Re: [RFC] adp1653: Add device tree bindings for LED controller

2014-11-16 Thread Andreas Färber

Hi Pavel,

Am 16.11.2014 um 08:59 schrieb Pavel Machek:
 For device tree people: Yes, I know I'll have to create file in
 documentation, but does the binding below look acceptable?
[...]
 diff --git a/arch/arm/boot/dts/omap3-n900.dts 
 b/arch/arm/boot/dts/omap3-n900.dts
 index 739fcf2..ed0bfc1 100644
 --- a/arch/arm/boot/dts/omap3-n900.dts
 +++ b/arch/arm/boot/dts/omap3-n900.dts
 @@ -553,6 +561,18 @@
  
   ti,usb-charger-detection = isp1704;
   };
 +
 + adp1653: adp1653@30 {

This should probably be led-controller@30 (a generic description not
specific to the model). The label name is fine.

 + compatible = ad,adp1653;
 + reg = 0x30;
 +
 + max-flash-timeout-usec = 50;
 + max-flash-intensity-uA= 32;
 + max-torch-intensity-uA = 5;
 + max-indicator-intensity-uA = 17500;
 +
 + gpios = gpio3 24 GPIO_ACTIVE_HIGH; /* Want 88 */

At least to me, the meaning of Want 88 is not clear - drop or clarify?

 + };
  };
  
  i2c3 {
[snip]

Regards,
Andreas

-- 
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 21284 AG Nürnberg
--
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: randconfig build error with next-20141020, in drivers/media/platform/marvell-ccic/mcam-core.c

2014-10-20 Thread Andreas Ruprecht

Hi,

after a lot of staring at the configuration it seems like this boils
down to an issue within the Kconfig constraint description.

Broken down to the important bits:

- CONFIG_VIDEO_TW68 and CONFIG_VIDEO_SAA7134 *select*
CONFIG_VIDEOBUF2_DMA_SG

- Both of these options are set to *m* in the configuration provided,
which means that CONFIG_VIDEOBUF2_DMA_SG will also be selected as m.
According to Documentation/kbuild/kconfig-language.txt, line 101, m is
set as the minimal value for CONFIG_VIDEOBUF2_DMA_SG by the selects, and
as no other options select it as y, it stays m.

- CONFIG_VIDEO_CAFE_CCIC is set to *y*.
The header file at drivers/media/platform/marvell-ccic/mcam-core.h then
sets an internal preprocessor variable in line 28:

#if IS_ENABLED(CONFIG_VIDEOBUF2_DMA_SG)
#define MCAM_MODE_DMA_SG 1
#endif

The source code right around line 1299 in
drivers/media/platform/marvell-ccic/mcam-core.c, where the undefined
reference occurs, depends on MCAM_MODE_DMA_SG.

This means that CONFIG_VIDEOBUF2_DMA_SG is compiled as an LKM, thus the
reference for vb2_dma_sg_memops from mcam-core.c (which is statically
compiled) can not be resolved in the builtin.o files and vmlinux.

Unfortunately, I haven't got a solution on how to resolve that, but
maybe this summary helps someone else to come up with one.

Best regards,
  Andreas

On 20.10.2014 19:52, Jim Davis wrote:
 Building with the attached random configuration file,
 
 drivers/built-in.o: In function `mcam_setup_vb2':
 /home/jim/linux/drivers/media/platform/marvell-ccic/mcam-core.c:1299: 
 undefined
 reference to `vb2_dma_sg_memops'
 make: *** [vmlinux] Error 1
 

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

[PATCH] drivers: media: platform: Makefile: Add build dependency for davinci/

2014-08-15 Thread Andreas Ruprecht

In the davinci/ subdirectory, all drivers but one depend on
CONFIG_ARCH_DAVINCI. The only exception, selected by CONFIG_VIDEO_DM6446_CCDC,
is also available on CONFIG_ARCH_OMAP3.

Thus, it is not necessary to always descend into davinci/. It is sufficient to
do this only if CONFIG_ARCH_OMAP3 or CONFIG_ARCH_DAVINCI is selected. While the
latter is already present, this patch changes the dependency from obj-y to
obj-$(CONFIG_ARCH_OMAP3).

Signed-off-by: Andreas Ruprecht rup...@einserver.de
---
 drivers/media/platform/Makefile | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/media/platform/Makefile b/drivers/media/platform/Makefile
index e5269da..d32e79a 100644
--- a/drivers/media/platform/Makefile
+++ b/drivers/media/platform/Makefile
@@ -47,7 +47,7 @@ obj-$(CONFIG_SOC_CAMERA)  += soc_camera/
 
 obj-$(CONFIG_VIDEO_RENESAS_VSP1)   += vsp1/
 
-obj-y  += davinci/
+obj-$(CONFIG_ARCH_OMAP3)   += davinci/
 
 obj-$(CONFIG_ARCH_OMAP)+= omap/
 
-- 
1.9.1

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

[PATCH] drivers: media: pci: Makefile: Remove duplicate subdirectory from obj-y

2014-08-10 Thread Andreas Ruprecht

In the list of subdirectories compiled, b2c2/ appears twice.

This patch removes one of the appearances.

Signed-off-by: Andreas Ruprecht rup...@einserver.de
---
 drivers/media/pci/Makefile | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/media/pci/Makefile b/drivers/media/pci/Makefile
index e5b53fb..dc2ebbe 100644
--- a/drivers/media/pci/Makefile
+++ b/drivers/media/pci/Makefile
@@ -10,7 +10,6 @@ obj-y+=   ttpci/  \
mantis/ \
ngene/  \
ddbridge/   \
-   b2c2/   \
saa7146/
 
 obj-$(CONFIG_VIDEO_IVTV) += ivtv/
-- 
1.9.1

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

Re: [PATCH] media: v4l2: make alloction alogthim more robust and flexible

2014-07-30 Thread Andreas Färber

Hi,

A few trivial typos:

s/alloction/allocation/

s/alogthim/algorithm/

Am 30.07.2014 05:55, schrieb Zhaowei Yuan:
 Current algothim relies on the fact that caller will align the

s/algothim/algorithm/

 size to PAGE_SIZE, otherwise order will be decreased to negative
 when remain size is less than PAGE_SIZE, it makes the function

s/remain/remaining/

 hard to be migrated.
 This patch sloves the hidden problem.

s/sloves/solves/

 
 Signed-off-by: Zhaowei Yuan zhaowei.y...@samsung.com

Regards,
Andreas

-- 
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg
--
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] DocBook media: fix number of bits filled with zeros for SRGBB12

2014-07-07 Thread Andreas Weber


From 4e0d586d6ff8019032d1c6771428ee25c4bbb755 Mon Sep 17 00:00:00 2001
From: Andreas Weber andy.weber...@gmail.com
Date: Mon, 7 Jul 2014 16:00:05 +0200
Subject: [PATCH] DocBook media: fix number of bits filled with zeros for
 SRGBB12

Signed-off-by: Andreas Weber andy.weber...@gmail.com
---
 Documentation/DocBook/media/v4l/pixfmt-srggb12.xml | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Documentation/DocBook/media/v4l/pixfmt-srggb12.xml b/Documentation/DocBook/media/v4l/pixfmt-srggb12.xml
index 9ba4fb6..96947f1 100644
--- a/Documentation/DocBook/media/v4l/pixfmt-srggb12.xml
+++ b/Documentation/DocBook/media/v4l/pixfmt-srggb12.xml
@@ -18,7 +18,7 @@
 	titleDescription/title
 
 	paraThe following four pixel formats are raw sRGB / Bayer formats with
-12 bits per colour. Each colour component is stored in a 16-bit word, with 6
+12 bits per colour. Each colour component is stored in a 16-bit word, with 4
 unused high bits filled with zeros. Each n-pixel row contains n/2 green samples
 and n/2 blue or red samples, with alternating red and blue rows. Bytes are
 stored in memory in little endian order. They are conventionally described
-- 
2.0.0

Help needed for TechniSat Skystar 2 HD

2014-05-02 Thread Andreas Pilz

Dear DVB-S2 Knowers!

I am trying to get with a new kernel my two TechniSat Skystar HD 2 working.

I have 3 cards:

05:00.0 0480: 1822:4e35 (rev 01)
Subsystem: 153b:1179
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium TAbort- 
TAbort+ MAbort- SERR- PERR- INTx-
Latency: 64 (2000ns min, 63750ns max)
Interrupt: pin A routed to IRQ 16
Region 0: Memory at fafff000 (32-bit, prefetchable) [size=4K]
Kernel driver in use: Mantis
Kernel modules: mantis

05:01.0 0480: 1822:4e35 (rev 01)
Subsystem: 1ae4:0003
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium TAbort- 
TAbort+ MAbort- SERR- PERR- INTx-
Latency: 64 (2000ns min, 63750ns max)
Interrupt: pin A routed to IRQ 17
Region 0: Memory at faffe000 (32-bit, prefetchable) [size=4K]
Kernel driver in use: Mantis
Kernel modules: mantis

05:02.0 0480: 1822:4e35 (rev 01)
Subsystem: 1ae4:0003
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium TAbort- 
TAbort+ MAbort- SERR- PERR- INTx-
Latency: 64 (2000ns min, 63750ns max)
Interrupt: pin A routed to IRQ 18
Region 0: Memory at faffd000 (32-bit, prefetchable) [size=4K]
Kernel driver in use: Mantis
Kernel modules: mantis

This is the kernel (from SuSE 13.1):

Linux godiva 3.11.10-7-desktop #1 SMP PREEMPT Mon Feb 3 09:41:24 UTC 
2014 (750023e) x86_64 x86_64 x86_64 GNU/Linux

I used the s2-liplianin-v39 drivers from here :

https://bitbucket.org/CrazyCat/s2-liplianin-v39

as these were the only ones I could compile under this kernel.

lsmod shows all fine, except that a dependency between mantis and stb0899 is 
missing.

Yet, with neither tool I can tune with the first card to Astra 19.2E. Yet, the 
other two cards always report no lock and a timeout of fronted in VDR.

Any hints? Much appreciated.

Thanks

Andi


--
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: [PATCHv2 1/3] phy: Add exynos-simple-phy driver

2014-04-09 Thread Andreas Oberritter

Hello Andrzej,

On 09.04.2014 10:37, Andrzej Hajda wrote:
 +static int exynos_phy_probe(struct platform_device *pdev)
 +{
 +const struct of_device_id *of_id = of_match_device(
 +of_match_ptr(exynos_phy_of_match), pdev-dev);
 +const u32 *offsets = of_id-data;
 +int count;
 +struct device *dev = pdev-dev;
 +struct phy **phys;
 +struct resource *res;
 +void __iomem *regs;
 +int i;
 +struct phy_provider *phy_provider;
 +
 +/* count number of phys to create */
 +for (count = 0; offsets[count] != ~0; ++count)
 +;
 
 count = ARRAY_SIZE(offsets) - 1;

u32 *offsets is not an array.

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

[PATCH 2/3] TBS USB drivers (DVB-S/S2) - add lock led hooks to frontends

2014-03-26 Thread Andreas Steinmetz

[Please CC me on replies, I'm not subscribed]

Based on GPLv2 code taken from:

https://bitbucket.org/CrazyCat/linux-tbs-drivers/

The patch adds lock led hooks to the stv090x, stv0288, cx24116 and
tda10071 frontends. Similar code already exists in the stv0900 frontend.
-- 
Andreas Steinmetz   SPAMmers use robot...@domdv.de
Signed-off-by: Andreas Steinmetz a...@domdv.de

diff -rNup v4l-dvb.orig/drivers/media/dvb-frontends/cx24116.c v4l-dvb/drivers/media/dvb-frontends/cx24116.c
--- v4l-dvb.orig/drivers/media/dvb-frontends/cx24116.c	2014-03-26 14:00:26.009338722 +0100
+++ v4l-dvb/drivers/media/dvb-frontends/cx24116.c	2014-03-26 19:30:42.561267100 +0100
@@ -703,6 +703,9 @@ static int cx24116_read_status(struct dv
 	if (lock  CX24116_HAS_SYNCLOCK)
 		*status |= FE_HAS_SYNC | FE_HAS_LOCK;
 
+	if (state-config-set_lock_led)
+		state-config-set_lock_led(fe, *status  FE_HAS_LOCK);
+
 	return 0;
 }
 
@@ -,6 +1114,8 @@ static void cx24116_release(struct dvb_f
 {
 	struct cx24116_state *state = fe-demodulator_priv;
 	dprintk(%s\n, __func__);
+	if (state-config-set_lock_led)
+		state-config-set_lock_led(fe, 0);
 	kfree(state);
 }
 
@@ -1196,6 +1201,9 @@ static int cx24116_sleep(struct dvb_fron
 
 	dprintk(%s()\n, __func__);
 
+	if (state-config-set_lock_led)
+		state-config-set_lock_led(fe, 0);
+
 	/* Firmware CMD 36: Power config */
 	cmd.args[0x00] = CMD_TUNERSLEEP;
 	cmd.args[0x01] = 1;
diff -rNup v4l-dvb.orig/drivers/media/dvb-frontends/cx24116.h v4l-dvb/drivers/media/dvb-frontends/cx24116.h
--- v4l-dvb.orig/drivers/media/dvb-frontends/cx24116.h	2014-03-26 14:00:26.009338722 +0100
+++ v4l-dvb/drivers/media/dvb-frontends/cx24116.h	2014-03-26 19:30:42.562267103 +0100
@@ -34,6 +34,9 @@ struct cx24116_config {
 	/* Need to reset device during firmware loading */
 	int (*reset_device)(struct dvb_frontend *fe);
 
+	/* Hook for Lock LED */
+	void (*set_lock_led)(struct dvb_frontend *fe, int offon);
+
 	/* Need to set MPEG parameters */
 	u8 mpg_clk_pos_pol:0x02;
 
diff -rNup v4l-dvb.orig/drivers/media/dvb-frontends/stv0288.c v4l-dvb/drivers/media/dvb-frontends/stv0288.c
--- v4l-dvb.orig/drivers/media/dvb-frontends/stv0288.c	2014-03-26 14:00:26.026338778 +0100
+++ v4l-dvb/drivers/media/dvb-frontends/stv0288.c	2014-03-26 19:30:52.361300077 +0100
@@ -381,6 +381,9 @@ static int stv0288_read_status(struct dv
 		dprintk(stv0288 has locked\n);
 	}
 
+	if (state-config-set_lock_led)
+		state-config-set_lock_led(fe, *status  FE_HAS_LOCK);
+
 	return 0;
 }
 
@@ -415,6 +418,9 @@ static int stv0288_sleep(struct dvb_fron
 {
 	struct stv0288_state *state = fe-demodulator_priv;
 
+	if (state-config-set_lock_led)
+		state-config-set_lock_led(fe, 0);
+
 	stv0288_writeregI(state, 0x41, 0x84);
 	state-initialised = 0;
 
@@ -532,6 +538,8 @@ static int stv0288_i2c_gate_ctrl(struct
 static void stv0288_release(struct dvb_frontend *fe)
 {
 	struct stv0288_state *state = fe-demodulator_priv;
+	if (state-config-set_lock_led)
+		state-config-set_lock_led(fe, 0);
 	kfree(state);
 }
 
diff -rNup v4l-dvb.orig/drivers/media/dvb-frontends/stv0288.h v4l-dvb/drivers/media/dvb-frontends/stv0288.h
--- v4l-dvb.orig/drivers/media/dvb-frontends/stv0288.h	2014-03-26 14:00:26.026338778 +0100
+++ v4l-dvb/drivers/media/dvb-frontends/stv0288.h	2014-03-26 19:30:52.361300077 +0100
@@ -41,6 +41,9 @@ struct stv0288_config {
 	int min_delay_ms;
 
 	int (*set_ts_params)(struct dvb_frontend *fe, int is_punctured);
+
+	/* Hook for Lock LED */
+	void (*set_lock_led)(struct dvb_frontend *fe, int offon);
 };
 
 #if IS_ENABLED(CONFIG_DVB_STV0288)
diff -rNup v4l-dvb.orig/drivers/media/dvb-frontends/stv090x.c v4l-dvb/drivers/media/dvb-frontends/stv090x.c
--- v4l-dvb.orig/drivers/media/dvb-frontends/stv090x.c	2014-03-26 14:00:26.029338788 +0100
+++ v4l-dvb/drivers/media/dvb-frontends/stv090x.c	2014-03-26 19:31:00.210326489 +0100
@@ -3546,6 +3546,9 @@ static int stv090x_read_status(struct dv
 		break;
 	}
 
+	if (state-config-set_lock_led)
+		state-config-set_lock_led(fe, *status  FE_HAS_LOCK);
+
 	return 0;
 }
 
@@ -3893,6 +3896,9 @@ static int stv090x_sleep(struct dvb_fron
 	u32 reg;
 	u8 full_standby = 0;
 
+	if (state-config-set_lock_led)
+		state-config-set_lock_led(fe, 0);
+
 	if (stv090x_i2c_gate_ctrl(state, 1)  0)
 		goto err;
 
@@ -4124,6 +4130,9 @@ static void stv090x_release(struct dvb_f
 {
 	struct stv090x_state *state = fe-demodulator_priv;
 
+	if (state-config-set_lock_led)
+		state-config-set_lock_led(fe, 0);
+
 	state-internal-num_used--;
 	if (state-internal-num_used = 0) {
 
diff -rNup v4l-dvb.orig/drivers/media/dvb-frontends/stv090x.h v4l-dvb/drivers/media/dvb-frontends/stv090x.h
--- v4l-dvb.orig/drivers/media/dvb-frontends/stv090x.h	2014-03-26 14:00:26.029338788 +0100
+++ v4l-dvb/drivers/media/dvb-frontends/stv090x.h	2014-03-26 19:31:00.212326496 +0100
@@ -101,6 +101,9 @@ struct stv090x_config {
 	int (*tuner_set_refclk)  (struct dvb_frontend *fe, u32 refclk);
 	int (*tuner_get_status) (struct dvb_frontend *fe, u32 *status);
 	void

[PATCH 1/3] TBS USB drivers (DVB-S/S2) - basic driver

2014-03-26 Thread Andreas Steinmetz

[Please CC me on replies, I'm not subscribed]

The patch adds a driver for TBS USB DVB-S/S2 devices for which complete
GPLv2 code exists. Code was taken from:

http://www.tbsdtv.com/download/
https://bitbucket.org/CrazyCat/linux-tbs-drivers/
https://bitbucket.org/updatelee/v4l-updatelee

Supported devices:
--

TBS5980 - complete open source by manufacturer, current device
TBS5928 - complete open source by manufacturer, old device
TBS5920 - complete open source by manufacturer, old device
TBS5910 - complete open source by manufacturer, old device
TBS5925 - open source by manufacturer except 13V/18V control,
  voltage switching of TBS5980 however works,
  current device
TBS5921 - open source from CrazyCat's bitbucket repository,
  old device

Unsupported devices:


TBS5922 - mostly closed source, current device
TBS5990 - mostly closed source, current device
TBS with USB PID 0x2601 - very old device for which the actual
hardware used couldn't be determined.

General:


I do not have any manufacturer relationship. I'm just a user of TBS5980
and TBS5925 which work quite well as far as the hardware is concerned.

I'm sufficiently annoyed, however, by the manufacturer's driver build
system which actually is an old v4l tree replacing the kernel's current
v4l tree. Thus I have reworked all available open source code for the
TBS USB DVB-S/S2 hardware into a combined driver that is working with
the current kernel.

Testing:


TBS5925 gets used daily and is working fine.
TBS5980 gets used daily minus an actual CAM and is working fine without
a CAM.

The old devices can't be tested by me, I don't own them and they are not
sold anymore.

Maintenance:


As a TBS5925/TBS5980 user I'm willing to maintain the driver as far as
this is possible (see below).

Regarding the older devices I'm willing to fix bugs for owners of these
devices as long as I did introduce them in my combined driver.

What I cannot do for any device is to fix any problems that would
require manufacturer support or manufacturer documentation.

As the TBS5980 manufacturer sources on which this driver is based didn't
change for more than one and a half years (since when I started to
collect manufacturer source archives) I'm quite confident that not much
maintenance will be necessary.

Firmware:
-

All required firmware except for the TBS5921 is available at
http://www.tbsdtv.com/download/ (manufacturer website). The tda10071
firmware required additionally for the TBS5921 is already supported by
the get_dvb_firmware script of the kernel.

Due to the way the manufacturer handles software distribution I can't
include the TBS firmware in the get_dvb_firmware script (no archive url,
archive files updated every few months under a different file name).

Notes:
--

The ifdefs in the driver will go away by a followup patch after a
necessary patch to some frontends.

Please go on easy with me. I'm usually not writing kernel drivers. And
I'm neither young nor healthy enough for flame wars.
-- 
Andreas Steinmetz   SPAMmers use robot...@domdv.de
Signed-off-by: Andreas Steinmetz a...@domdv.de

diff -rNup v4l-dvb.orig/drivers/media/dvb-core/dvb-usb-ids.h v4l-dvb/drivers/media/dvb-core/dvb-usb-ids.h
--- v4l-dvb.orig/drivers/media/dvb-core/dvb-usb-ids.h	2014-03-26 15:03:13.399501288 +0100
+++ v4l-dvb/drivers/media/dvb-core/dvb-usb-ids.h	2014-03-26 15:19:08.658682532 +0100
@@ -70,6 +70,7 @@
 #define USB_VID_EVOLUTEPC			0x1e59
 #define USB_VID_AZUREWAVE			0x13d3
 #define USB_VID_TECHNISAT			0x14f7
+#define USB_VID_TENOW0x734c
 
 /* Product IDs */
 #define USB_PID_ADSTECH_USB2_COLD			0xa333
@@ -375,4 +376,10 @@
 #define USB_PID_CTVDIGDUAL_V20xe410
 #define USB_PID_PCTV_2002E  0x025c
 #define USB_PID_PCTV_2002E_SE   0x025d
+#define USB_PID_TENOW_TBS59100x5910
+#define USB_PID_TENOW_TBS59200x5920
+#define USB_PID_TENOW_TBS59210x5921
+#define USB_PID_TENOW_TBS59250x5925
+#define USB_PID_TENOW_TBS59280x5928
+#define USB_PID_TENOW_TBS59800x5980
 #endif
diff -rNup v4l-dvb.orig/drivers/media/usb/dvb-usb/Kconfig v4l-dvb/drivers/media/usb/dvb-usb/Kconfig
--- v4l-dvb.orig/drivers/media/usb/dvb-usb/Kconfig	2014-03-26 14:00:26.134339135 +0100
+++ v4l-dvb/drivers/media/usb/dvb-usb/Kconfig	2014-03-26 15:23:38.585581745 +0100
@@ -317,3 +317,23 @@ config DVB_USB_TECHNISAT_USB2
 	select DVB_STV6110x if MEDIA_SUBDRV_AUTOSELECT
 	help
 	  Say Y here to support the Technisat USB2 DVB-S/S2 device
+
+config DVB_USB_TBS
+	tristate TurboSight DVB-S/S2 USB2.0 support
+	depends on DVB_USB
+	select DVB_PLL if MEDIA_SUBDRV_AUTOSELECT
+	select DVB_STV090x if MEDIA_SUBDRV_AUTOSELECT
+	select DVB_STB6100 if MEDIA_SUBDRV_AUTOSELECT
+	select DVB_CX24116 if MEDIA_SUBDRV_AUTOSELECT
+	select DVB_TDA10071 if MEDIA_SUBDRV_AUTOSELECT
+	select DVB_STV0299 if MEDIA_SUBDRV_AUTOSELECT
+	select DVB_STV0288

PCTV 200Xe Tuning (get a lock, but no data)

2014-02-01 Thread Andreas Witte

 | signal  | snr 00d1 | ber  | unc  |
FE_HAS_LOCK
status 1e | signal  | snr 00da | ber  | unc  |
FE_HAS_LOCK
status 1e | signal  | snr 00d1 | ber  | unc  |
FE_HAS_LOCK
status 1e | signal  | snr 00d6 | ber  | unc  |
FE_HAS_LOCK

Sometimes, the first tuning after un- and reloading the dvb-usb-dib0700
module
is succesfull, i got my videostream, but after a channelchange, all is at
the old 
state again. 

The different parameters in /etc/modprobe.d/options.conf i tried alrady in
all
combinations:

options dvb_usb disable_rc_polling=1
options dvb_usb_dib0700 force_lna_activation=1
#options usbcore autosuspend=1

The stick worked nicely before, on a 2.6.xx anything kernel, without any
hassle 
in the same antenna configuration like it is now. Except from the stick, i
also got
2 Avermedia 771 Cards inside this pc, they work flawless on the same
Antenna.

Is there anything i can do about? I nearly tried all. The normal kernel
drivers in
3.10.25, the media-build, nothing changes the behavior. Im at the end of my 
knowledge and wonder, what have changed in the meantime?

Hope anyone can help me with that?

Regards,
Andreas

(Sorry for the long post, but i tried to be as concrete as i can)

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

How to tell libv4l2 which src_fmt should be prefered?

2014-01-18 Thread Andreas Weber

Dear maintainer and user,

Is there a way to tell libv4l2 which native source format it should
prefer to convert from? For example my uvcvideo webcam supports natively
YUYV and MJPG (see output below) and when I request V4L2_PIX_FMT_RGB24 I
see in the logs:

...
VIDIOC_S_FMT app requesting: RGB3
VIDIOC_S_FMT converting from: YUYV
request == VIDIOC_S_FMT
  pixelformat: RGB3 640x480
  field: 1 bytesperline: 1920 imagesize921600
  colorspace: 8, priv: 0
...

So it picks up YUYV as source format. I had a look at
v4lconvert_try_format but can see no way how to do this.

Regards, Andy

$ v4l2-ctl --list-formats
ioctl: VIDIOC_ENUM_FMT
Index   : 0
Type: Video Capture
Pixel Format: 'YUYV'
Name: YUV 4:2:2 (YUYV)

Index   : 1
Type: Video Capture
Pixel Format: 'MJPG' (compressed)
Name: MJPEG

$ v4l2-ctl -w -D
Driver Info (using libv4l2):
Driver name   : uvcvideo
Card type : UVC Camera (046d:0825)
Bus info  : usb-:00:16.2-2
Driver version: 3.2.51
Capabilities  : 0x0501
Video Capture
Read/Write
Streaming

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

2 bugs (errno = EINTR) in v4l2grab.c and v4l2gl.c?

2014-01-16 Thread Andreas Weber

Dear maintainers,

I guess these are 2 bugs:
contrib/test/v4l2grab.c:132: } while ((r == -1  (errno = EINTR)));
contrib/test/v4l2gl.c:227:   } while ((r == -1  (errno = EINTR)));

please consider my attached patch if it's really a bug.
Regards, Andy
From 63d4fd18cb91852b64c81bf63d0d4100fc53d38d Mon Sep 17 00:00:00 2001
From: Andreas Weber andreas.we...@hs-offenburg.de
Date: Thu, 16 Jan 2014 18:43:31 +0100
Subject: [PATCH] bugfix for errno assignment in while loop

---
 contrib/test/v4l2gl.c   |2 +-
 contrib/test/v4l2grab.c |2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/contrib/test/v4l2gl.c b/contrib/test/v4l2gl.c
index e921212..4b549c1 100644
--- a/contrib/test/v4l2gl.c
+++ b/contrib/test/v4l2gl.c
@@ -224,7 +224,7 @@ static int capture(char *dev_name, int x_res, int y_res, int n_frames,
 			tv.tv_usec = 0;
 
 			r = select(fd + 1, fds, NULL, NULL, tv);
-		} while ((r == -1  (errno = EINTR)));
+		} while ((r == -1  (errno == EINTR)));
 		if (r == -1) {
 			perror(select);
 			return errno;
diff --git a/contrib/test/v4l2grab.c b/contrib/test/v4l2grab.c
index a93ad43..14d2a8f 100644
--- a/contrib/test/v4l2grab.c
+++ b/contrib/test/v4l2grab.c
@@ -129,7 +129,7 @@ static int capture(char *dev_name, int x_res, int y_res, int n_frames,
 			tv.tv_usec = 0;
 
 			r = select(fd + 1, fds, NULL, NULL, tv);
-		} while ((r == -1  (errno = EINTR)));
+		} while ((r == -1  (errno == EINTR)));
 		if (r == -1) {
 			perror(select);
 			return errno;
-- 
1.7.10.4

patch for display of readbuffers in v4l2-ctl-misc.cpp

2014-01-16 Thread Andreas Weber

Dear maintainers,
I think there is a bug in utils/v4l2-ctl/v4l2-ctl-misc.cpp:394
  printf(\tRead buffers : %d\n, parm.parm.output.writebuffers);
Please consider the attached patch.

-- Andy
From c3b6188d385dce46bed3e8803f661cf0e501522e Mon Sep 17 00:00:00 2001
From: Andreas Weber andreas.we...@hs-offenburg.de
Date: Thu, 16 Jan 2014 18:27:14 +0100
Subject: [PATCH] v4l2-ctl-misc.cpp: bugfix display #of readbuffers

---
 utils/v4l2-ctl/v4l2-ctl-misc.cpp |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/utils/v4l2-ctl/v4l2-ctl-misc.cpp b/utils/v4l2-ctl/v4l2-ctl-misc.cpp
index 6857fff..4d11ec8 100644
--- a/utils/v4l2-ctl/v4l2-ctl-misc.cpp
+++ b/utils/v4l2-ctl/v4l2-ctl-misc.cpp
@@ -391,7 +391,7 @@ void misc_get(int fd)
 printf(\tFrames per second: %.3f (%d/%d)\n,
 		(1.0 * tf.denominator) / tf.numerator,
 		tf.denominator, tf.numerator);
-			printf(\tRead buffers : %d\n, parm.parm.output.writebuffers);
+			printf(\tRead buffers : %d\n, parm.parm.capture.readbuffers);
 		}
 	}
 
-- 
1.7.10.4

Re: Upstreaming SAA716x driver to the media_tree

2014-01-07 Thread Andreas Regel

Hi Luis,

Am 07.01.2014 12:58, schrieb Luis Alves:
 Hi,
 
 I'm finishing a new frontend driver for one of my dvb cards, but the
 pcie bridge uses the (cursed) saa716x.
 As far as I know the progress to upstream Manu's driver to the
 media_tree has stalled.
 
 In CC I've placed some of the people that I found working on it
 lately, supporting a few dvb cards.
 
 It would be good if we could gather everything in one place and send a
 few patchs to get this upstreamed for once...
 
 Manu, do you see any inconvenience in sending your driver to the
 linux_media tree?
 I'm available to place some effort on this task.

which repository of the saa761x is your work based on?

Regards,
Andreas

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

[media-ctl PATCH] Fix linking of shared libraries

2013-02-19 Thread Andreas Bombe

When using libudev, it is actually libmediactl that uses it and not the
media-ctl executable. libv4l2subdev uses functions from libmediactl and
therefore needs to be linked against it.

Signed-off-by: Andreas Bombe a...@debian.org
---

In light of their relative simplicity as well as cross dependency, does
it make sense to keep libmediactl and libv4l2subdev as separate
libraries?

 src/Makefile.am |6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/src/Makefile.am b/src/Makefile.am
index 2583464..f754763 100644
--- a/src/Makefile.am
+++ b/src/Makefile.am
@@ -1,12 +1,12 @@
 lib_LTLIBRARIES = libmediactl.la libv4l2subdev.la
 libmediactl_la_SOURCES = mediactl.c
+libmediactl_la_CFLAGS = $(LIBUDEV_CFLAGS)
+libmediactl_la_LDFLAGS = $(LIBUDEV_LIBS)
 libv4l2subdev_la_SOURCES = v4l2subdev.c
+libv4l2subdev_la_LIBADD = libmediactl.la
 mediactl_includedir=$(includedir)/mediactl
 mediactl_include_HEADERS = mediactl.h v4l2subdev.h
 
 bin_PROGRAMS = media-ctl
-media_ctl_CFLAGS = $(LIBUDEV_CFLAGS)
-media_ctl_LDFLAGS = $(LIBUDEV_LIBS)
 media_ctl_SOURCES = main.c options.c options.h tools.h
 media_ctl_LDADD = libmediactl.la libv4l2subdev.la
-
-- 
1.7.10.4

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

[media-ctl PATCH] configure.ac: Respect CPPFLAGS from environment

2013-02-17 Thread Andreas Bombe

Signed-off-by: Andreas Bombe a...@debian.org
---
 configure.ac |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/configure.ac b/configure.ac
index 98459d4..a749794 100644
--- a/configure.ac
+++ b/configure.ac
@@ -48,7 +48,7 @@ AC_ARG_WITH(kernel-headers,
  esac],
 [KERNEL_HEADERS_DIR=/usr/src/kernel-headers])
 
-CPPFLAGS=-I$KERNEL_HEADERS_DIR/include
+CPPFLAGS=$CPPFLAGS -I$KERNEL_HEADERS_DIR/include
 
 # Checks for header files.
 AC_CHECK_HEADERS([linux/media.h \
-- 
1.7.10.4


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

[media-ctl PATCH] Add missing stdlib.h and ctype.h includes

2013-02-17 Thread Andreas Bombe

src/mediactl.c needs ctype.h for its use of isspace().

src/v4l2subdev.c needs stdlib.h for strtoul() and ctype.h for isspace()
and isupper().

Signed-off-by: Andreas Bombe a...@debian.org
---
 src/mediactl.c   |1 +
 src/v4l2subdev.c |2 ++
 2 files changed, 3 insertions(+)

diff --git a/src/mediactl.c b/src/mediactl.c
index 46562de..c2f985a 100644
--- a/src/mediactl.c
+++ b/src/mediactl.c
@@ -29,6 +29,7 @@
 #include stdbool.h
 #include stdio.h
 #include stdlib.h
+#include ctype.h
 #include string.h
 #include fcntl.h
 #include errno.h
diff --git a/src/v4l2subdev.c b/src/v4l2subdev.c
index d0c37f3..87d7eb7 100644
--- a/src/v4l2subdev.c
+++ b/src/v4l2subdev.c
@@ -26,6 +26,8 @@
 #include errno.h
 #include fcntl.h
 #include stdbool.h
+#include stdlib.h
+#include ctype.h
 #include stdio.h
 #include string.h
 #include unistd.h
-- 
1.7.10.4
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: How to configure resizer in ISP pipeline?

2013-01-05 Thread Andreas Nagel

Hi Sakari,

thanks for helping.

My sensor (TVP5146) already provides YUV data, so I can skip the
previewer. I tried setting the input and output pad of the resizer
subdevice to incoming resolution (input pad) and desired resolution
(output pad). For example: 720x576 -- 352x288. But it didn't work
out quite well.

How did it not work quite well? :)

Not sure, if I recall all the details. I haven't done much in this area
for a few weeks now.
Currently, I actually can configure the resizer, but then
VIDIOC_STREAMON fails with EINVAL when I configure the devnode. Don't
know why.
I do connect the resizer source to the resizer output (devnode) and then
capture from there. I think it is /dev/video6.
If I leave the resizer out and connect the ccdc source to the ccdc
output (/dev/video2), capturing works just fine.

One reason could be, that the resizer isn't supported right now. (You
remember, I have to use Technexion's TI kernel 2.6.37 with its exotic
ISP driver. ;-) )

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

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

Can someone explain how one properly configures the resizer in an
ISP pipeline (with Media Controller API) ? I spend some hours
researching, but this topic seems to be a well guarded secret...

There's nothing special about it. Really.

The resizing factor is chosen by setting the media bus format on the source
pad to the desired size.

Yes, that is what I figured out eventually.
--
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

How to configure resizer in ISP pipeline?

2012-12-11 Thread Andreas Nagel


Hello,

using Media Controller API, I can successfully configure a simple ISP 
pipeline on an OMAP3530 and capture video data. Now I want to include 
the resizer. So the pipeline would look like this (where MEM would be 
the devnode corresponding to resizer output):


Sensor -- CCDC -- Resizer -- MEM

My sensor (TVP5146) already provides YUV data, so I can skip the 
previewer. I tried setting the input and output pad of the resizer 
subdevice to incoming resolution (input pad) and desired resolution 
(output pad). For example: 720x576 -- 352x288. But it didn't work out 
quite well.


Can someone explain how one properly configures the resizer in an ISP 
pipeline (with Media Controller API) ? I spend some hours researching, 
but this topic seems to be a well guarded secret...


Kind regards,
Andreas
--
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

Not receiving any messages since 2012-11-04

2012-12-01 Thread Andreas Regel

Hi,

am I the only one that is receiveing no mails from linux-media since Nov 04, 
2012?

Best regards
Andreas
--
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: OMAP3 ISP: VIDIOC_STREAMON and VIDIOC_QBUF calls fail

2012-11-10 Thread Andreas Nagel


Sakari Ailus schrieb am 08.11.2012 10:29:

On Thu, Nov 08, 2012 at 10:26:11AM +0100, Laurent Pinchart wrote:

media-ctl doesn't show pad formats, that's a bit weird. Are you using a recent
version ?

This could as well be an issue with the kernel API --- I think that kernel
has a version which isn't in mainline. So the IOCTL used to access the media
bus formats are quite possibly different.

Regards,



Hi Sakari,
hi Laurent,


first, I could resolve my issues.

When I allocated buffers with the CMEM library from TI (provides aligned 
and contiguous memory buffers), I was able to use user pointers. And 
VIDIOC_STREAMON just failed because of a wrong but similar written 
pixelformat. Since yesterday, I am now able to capture frames and save 
them as YUV data in a file.


My Technexion kernel is based on the TI linux kernel and they 
(Technexion) probably backported some version of Media Controller into 
that kernel. In order to build Laurents media-ctl application, I had to 
rename all MEDIA_* constants in the source files (e.g. MEDIA_PAD_FL_SINK 
into MEDIA_PAD_FLAG_INPUT).
It's probably true, that this implementation is quite different from the 
one in mainline or other kernels. That might also be the reason, why 
media-ctl -p does not print pad formats.
But as long as Technexion keep board support for themselves, I cannot 
use another kernel. I already tried that with some mainline and 
linux-omap versions(3.2, 3.4, 3.6). They don't boot, or if they actually 
do, I don't see anything because network and tty is not available.


Lastly, the TVP5146 indeed generates interlaced frames.

All the best,
Andreas
--
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: OMAP3 ISP: VIDIOC_STREAMON and VIDIOC_QBUF calls fail

2012-11-07 Thread Andreas Nagel


Hi Sakari,

thanks for helping.


My code sets up the ISP pipeline, configures the format on all the
subdevices pads and the actual video device. Works fine so far.
Then I passed user pointers (aquired with malloc) to the device
driver for the capture buffers. Before issuing VIDIOC_STREAMON, I
enqueue my buffers with VIDIOC_QBUF, which fails with errno = EIO. I
don't know, why this is happening or where to got from here.
One possibility could be that mapping the buffer to ISP MMU fails for 
a reason or another. Do you set the length field in the buffer? 


Yes, the length was set when using userptr.



And am I missing something else?

The formats on the pads at different ends of the links in the pipeline must
match. In most cases, they have to be exactly the same.

Have you used the media-ctl test program here?

URL:http://git.ideasonboard.org/media-ctl.git

media-ctl -p gives you (and us) lots of information that helps figuring out
what could go wrong here.


All pads do indeed have the same format.
I ran media-ctl, as you suggested. You can see the topology in the 
attached textfile.




Kind regards,
Andreas
Opening media device /dev/media0
Enumerating entities
Found 16 entities
Enumerating pads and links
Media controller API version 0.0.0

Media device information

driver  omap3isp
model   TI OMAP3 ISP
serial  
bus info
hw revision 0x0
driver version  0.0.0

Device topology
- entity 1: OMAP3 ISP CCP2 (2 pads, 2 links)
type V4L2 subdev subtype Unknown
device node name /dev/v4l-subdev0
pad0: Sink
- OMAP3 ISP CCP2 input:0 []
pad1: Source
- OMAP3 ISP CCDC:0 []

- entity 2: OMAP3 ISP CCP2 input (1 pad, 1 link)
type Node subtype V4L
device node name /dev/video0
pad0: Source
- OMAP3 ISP CCP2:0 []

- entity 3: OMAP3 ISP CSI2a (2 pads, 2 links)
type V4L2 subdev subtype Unknown
device node name /dev/v4l-subdev1
pad0: Sink
pad1: Source
- OMAP3 ISP CSI2a output:0 []
- OMAP3 ISP CCDC:0 []

- entity 4: OMAP3 ISP CSI2a output (1 pad, 1 link)
type Node subtype V4L
device node name /dev/video1
pad0: Sink
- OMAP3 ISP CSI2a:1 []

- entity 5: OMAP3 ISP CCDC (3 pads, 9 links)
type V4L2 subdev subtype Unknown
device node name /dev/v4l-subdev2
pad0: Sink
- OMAP3 ISP CCP2:1 []
- OMAP3 ISP CSI2a:1 []
- tvp514x 2-005d:0 []
pad1: Source
- OMAP3 ISP CCDC output:0 []
- OMAP3 ISP resizer:0 []
pad2: Source
- OMAP3 ISP preview:0 []
- OMAP3 ISP AEWB:0 [ENABLED,IMMUTABLE]
- OMAP3 ISP AF:0 [ENABLED,IMMUTABLE]
- OMAP3 ISP histogram:0 [ENABLED,IMMUTABLE]

- entity 6: OMAP3 ISP CCDC output (1 pad, 1 link)
type Node subtype V4L
device node name /dev/video2
pad0: Sink
- OMAP3 ISP CCDC:1 []

- entity 7: OMAP3 ISP preview (2 pads, 4 links)
type V4L2 subdev subtype Unknown
device node name /dev/v4l-subdev3
pad0: Sink
- OMAP3 ISP CCDC:2 []
- OMAP3 ISP preview input:0 []
pad1: Source
- OMAP3 ISP preview output:0 []
- OMAP3 ISP resizer:0 []

- entity 8: OMAP3 ISP preview input (1 pad, 1 link)
type Node subtype V4L
device node name /dev/video3
pad0: Source
- OMAP3 ISP preview:0 []

- entity 9: OMAP3 ISP preview output (1 pad, 1 link)
type Node subtype V4L
device node name /dev/video4
pad0: Sink
- OMAP3 ISP preview:1 []

- entity 10: OMAP3 ISP resizer (2 pads, 4 links)
 type V4L2 subdev subtype Unknown
 device node name /dev/v4l-subdev4
pad0: Sink
- OMAP3 ISP CCDC:1 []
- OMAP3 ISP preview:1 []
- OMAP3 ISP resizer input:0 []
pad1: Source
- OMAP3 ISP resizer output:0 []

- entity 11: OMAP3 ISP resizer input (1 pad, 1 link)
 type Node subtype V4L
 device node name /dev/video5
pad0: Source
- OMAP3 ISP resizer:0 []

- entity 12: OMAP3 ISP resizer output (1 pad, 1 link)
 type Node subtype V4L
 device node name /dev/video6
pad0: Sink
- OMAP3 ISP resizer:1 []

- entity 13: OMAP3 ISP AEWB (1 pad, 1 link)
 type V4L2 subdev subtype Unknown
 device node name /dev/v4l-subdev5
pad0: Sink
- OMAP3 ISP CCDC:2 [ENABLED,IMMUTABLE]

- entity 14: OMAP3 ISP AF (1 pad, 1 link)
 type V4L2 subdev subtype Unknown
 device node name /dev/v4l-subdev6
pad0: Sink

OMAP3 ISP: VIDIOC_STREAMON and VIDIOC_QBUF calls fail

2012-11-05 Thread Andreas Nagel


Hello,

in order to familiarize myself with Media Controller and V4L2 I am 
creating a small example program for capturing some frames through the 
OMAP3 ISP.
The hardware used is a TAO-3530 on a Tsunami daughterboard from 
Technexion. My video source is a standard DVD player connected to the 
daughterboards S-VIDEO port. That port itself is wired to a TVP5146 
decoder chip from TI.
A precompiled Android image with a demo app proofs, that the hardware is 
working fine.


My example program is mostly based on the following wiki page and the 
capture example in the V4L2 documentation.

http://processors.wiki.ti.com/index.php/Writing_V4L2_Media_Controller_Applications_on_Dm36x_Video_Capture

My code sets up the ISP pipeline, configures the format on all the 
subdevices pads and the actual video device. Works fine so far.
Then I passed user pointers (aquired with malloc) to the device driver 
for the capture buffers. Before issuing VIDIOC_STREAMON, I enqueue my 
buffers with VIDIOC_QBUF, which fails with errno = EIO. I don't know, 
why this is happening or where to got from here.


When using memory-mapped buffers instead, mapping the addresses to 
userspace works fine as well as VIDIOC_QBUF calls. But then 
VIDIOC_STREAMON fails with EINVAL. According to V4L documentation, 
EINVAL means

a) buffertype (V4L2_BUF_TYPE_VIDEO_CAPTURE in this case) not supported
b) no buffers have been allocated (memory mapping)
c) or enqueued yet

Because I tested V4L2_CAP_VIDEO_CAPTURE capability, I guess option a) 
does not apply. Buffers have been enqueud, so c) doesn't apply either.
What about b) ? As I chose memory-mapped buffers here, the device 
drivers manages the buffers. How can I make sure, that buffers were 
actually allocated?


And am I missing something else?

I attached my example code. If you need more information, I will provide it.

Note: I have to use the Technexion 2.6.37 kernel, which is based on the 
TI kernel. It's the only kernel that comes with the ISP driver and Media 
Controller API onboard and I guess, TI or TN included this stuff 
somehow. Normally, this shouldn't be available until 2.6.39. Sadly, I 
cannot use another kernel, because Technexion doesn't push board support 
anywhere.



Best regards,
Andreas



/*
 * capture.c
 *
 *  Created on: 29.10.2012
 *  Author: andreas
 */

#include stdio.h
#include stdlib.h
#include fcntl.h
#include linux/media.h
#include linux/v4l2-subdev.h
#include string.h
#include errno.h
#include sys/ioctl.h
#include sys/mman.h


#include capture.h

#define CLEAR(x) memset(x, 0, sizeof(x))

int main(void) {

	/*
	 * Open media device.
	 */
	int media_fd = open(DEVNODE_ISP, O_RDWR);
	if (media_fd  0) {
		puts(Can't open media device.);
		return -1;
	}

	/*
	 * Get the required entities.
	 */
	entities_t entities;
	CLEAR(entities);

	if (get_entities(media_fd, entities) != 0) {
		puts(Required entity IDs could not be determined.);
		return -1;
	}

	/*
	 * Connect tvp -- ccdc
	 */
	struct media_link_desc link;
	CLEAR(link);

	link.flags |= MEDIA_LINK_FLAG_ENABLED;
	link.source.entity = entities.tvp514x;
	link.source.index = PAD_TVP514X;
	link.source.flags = MEDIA_PAD_FLAG_OUTPUT;
	link.sink.entity = entities.ccdc;
	link.sink.index = PAD_CCDC_SINK;
	link.sink.flags = MEDIA_PAD_FLAG_INPUT;

	if (ioctl(media_fd, MEDIA_IOC_SETUP_LINK, link) == 0) {
		puts(tvp -- ccdc: enabled);
	}
	else {
		printf(Error setting up link [tvp -- ccdc]. Error %d, %s.\n, errno, strerror(errno));
		return -1;
	}

	/*
	 * Connect ccdc -- ccdc_output
	 */
	CLEAR(link);

	link.flags |= MEDIA_LINK_FLAG_ENABLED;
	link.source.entity = entities.ccdc;
	link.source.index = PAD_CCDC_SOURCE;
	link.source.flags = MEDIA_PAD_FLAG_OUTPUT;
	link.sink.entity = entities.ccdc_out;
	link.sink.index = PAD_CCDC_OUTPUT;
	link.sink.flags = MEDIA_PAD_FLAG_INPUT;

	if (ioctl(media_fd, MEDIA_IOC_SETUP_LINK, link) == 0) {
		puts(ccdc -- ccdc-out: enabled);
	}
	else {
		printf(	Error setting up link [ccdc -- ccdc-out]. Error %d, %s.\n,
errno,
strerror(errno));
		return -1;
	}

	/*
	 * Open capture device
	 */
	int video_fd = open(DEVNODE_CCDC_OUT, O_RDWR | O_NONBLOCK, 0);
	if (video_fd  0) {
		puts(Can't open capture device.);
		return -1;
	}

	/*
	 * Check some capabilities.
	 */
	struct v4l2_capability cap;
	printf(Checking device capabilites...);
	if (ioctl(video_fd, VIDIOC_QUERYCAP, cap) != 0) {
		printf(failed. Error %d (%s).\n, errno, strerror(errno));
	}
	else {
		puts(ok.);
		printf(	Device %s is a video capture device... %s\n,
DEVNODE_CCDC_OUT,
cap.capabilities  V4L2_CAP_VIDEO_CAPTURE ? yes : no);

		printf(	Device %s supports streaming... %s\n,
DEVNODE_CCDC_OUT,
cap.capabilities  V4L2_CAP_STREAMING ? yes : no);
	}

	/*
	 * Setting camera as input
	 */
	struct v4l2_input input;
	CLEAR(input);
	input.type = V4L2_INPUT_TYPE_CAMERA;
	input.index = 70;		// required for the tvp514x decoder chip

	printf(Setting camera input... );
	if (-1 == ioctl(video_fd, VIDIOC_S_INPUT, input.index

Re: Integrate camera interface of OMAP3530 in Angstrom Linux

2012-10-01 Thread Andreas Nagel


Hi Laurent,

thanks for your reply.

Using a current mainline kernel is a little problematic. Recently I 
compiled the 2.6.39 and it wasn't able to boot at all. The reason for 
this are probably the chips, that are built on the CPU module. Usually, 
a working kernel for this module was undergoing some modifications by 
Technexion because of these chips.
Currently, Technexion only offers the 2.6.32. and 2.6.37 kernel. The 
latter one makes a new device node /dev/media0 available (after 
activating some 'experimental' marked options in the kernel config), but 
I wasn't able to capture any signal.


I'm going to try the latest mainline kernel, but I doubt it will work.

Kind regards,
Andreas


Am 26.09.2012 13:41, schrieb Laurent Pinchart:

Hi Andreas,

On Thursday 06 September 2012 20:00:04 Andreas Nagel wrote:

Hello,

I am using an embedded module called TAO-3530 from Technexion, which has
an OMAP3530 processor.
This processor has a camera interface, which is part of the ISP
submodule. For an ongoing project I want to capture a video signal from
this interface. After several days of excessive research I still don't
know, how to access it.
I configured the Angstrom kernel (2.6.32), so that the driver for OMAP 3
camera controller (and all other OMAP 3 related things) is integrated,
but I don't see any new device nodes in the filesystem.

You should upgrade to a much more recent kernel, as the driver for the OMAP3
ISP included in the Angstrom 2.6.32 kernel is just bad legacy code that should
be burried in a very deep cave.


I also found some rumors, that the Media Controller Framework or driver
provides the device node /dev/media0, but I was not able to install it.

You will need to upgrade your kernel for that. I'd advise going for the latest
mainline kernel.


I use OpenEmbedded, but I don't have a recipe for Media Controller. On
the Angstrom website ( http://www.angstrom-distribution.org/repo/ )
there's actually a package called media-ctl, but due to the missing
recipe, i can't install it. Can't say, I am an expert in OE.

Can you help me point out, what's necessary to make the camera interface
accessible?


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

bttv-i2c.c wrong printk() fix

2012-09-30 Thread Andreas Kool


Hi all,

since i am using Linux 3.x my syslog gets flooded with tons of

[67819.884660] 
[67819.885062] 
[67819.885466] 
...

Please add these patch to v4l:

--- v4l-dvb/drivers/media/pci/bt8xx/bttv-i2c.c.orig	2012-09-30 
12:54:09.611095929 +0200
+++ v4l-dvb/drivers/media/pci/bt8xx/bttv-i2c.c	2012-09-30 
12:59:40.797318140 +0200

@@ -173,7 +173,7 @@
if (i2c_debug)
pr_cont( %02x, msg-buf[cnt]);
}
-   if (!(xmit  BT878_I2C_NOSTOP))
+   if (i2c_debug  !(xmit  BT878_I2C_NOSTOP))
pr_cont(\n);
return msg-len;

Thanks and
Ciao,
Andreas
--
Andreas Kool (Dont send mail to: ubecac...@akool.de)
Transmission of this message via the Microsoft Network is prohibited

Das Wort WINDOWS stammt aus einem alten Sioux-Dialekt und bedeutet:
Weisser Mann starrt durch Glasscheibe auf Sanduhr. (anonym)
--
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

Integrate camera interface of OMAP3530 in Angstrom Linux

2012-09-06 Thread Andreas Nagel


Hello,

I am using an embedded module called TAO-3530 from Technexion, which has 
an OMAP3530 processor.
This processor has a camera interface, which is part of the ISP 
submodule. For an ongoing project I want to capture a video signal from 
this interface. After several days of excessive research I still don't 
know, how to access it.
I configured the Angstrom kernel (2.6.32), so that the driver for OMAP 3 
camera controller (and all other OMAP 3 related things) is integrated, 
but I don't see any new device nodes in the filesystem.


I also found some rumors, that the Media Controller Framework or driver 
provides the device node /dev/media0, but I was not able to install it.
I use OpenEmbedded, but I don't have a recipe for Media Controller. On 
the Angstrom website ( http://www.angstrom-distribution.org/repo/ ) 
there's actually a package called media-ctl, but due to the missing 
recipe, i can't install it. Can't say, I am an expert in OE.


Can you help me point out, what's necessary to make the camera interface 
accessible?


Best regards,
Andreas

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

Re: [PATCH 1/3] stv090x: Fix typo in register macros

2012-05-24 Thread Andreas Regel

Am 15.05.2012 14:43, schrieb Manu Abraham:
 Hi Andreas,
 
 Sorry about the late reply.
 
 Which datasheet revision are you using ? I looked at RevG and found that the
 register ERRCNT22 @ 0xF59D, 0xF39D do have bitfields by name Px_ERR_CNT2
 on Page 227.
 
 Did you overlook that by some chance ?
 
 Best Regards,
 Manu

Hi Manu,

I checked the datasheet. You are right, the actual bitfield of register 
Px_ERRCNT22 is named there Px_ERR_CNT2 but the same name is also used for the 
bitfields of registers Px_ERRCNT21 and Px_ERRCNT20. I think naming it CNT22 
better reflects its actual meaning of being the only a part of the counter 
value. It also would match the naming of ERRCNT12.

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

Re: [PATCH 1/3] stv090x: Fix typo in register macros

2012-03-11 Thread Andreas Regel

Hi Mauro,

it should be OK now.

---
 drivers/media/dvb/frontends/stv090x.c |2 +-
 drivers/media/dvb/frontends/stv090x_reg.h |4 ++--
 2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/media/dvb/frontends/stv090x.c 
b/drivers/media/dvb/frontends/stv090x.c
index 4aef187..6c3c095 100644
--- a/drivers/media/dvb/frontends/stv090x.c
+++ b/drivers/media/dvb/frontends/stv090x.c
@@ -3526,7 +3526,7 @@ static int stv090x_read_per(struct dvb_frontend *fe, u32 
*per)
} else {
/* Counter 2 */
reg = STV090x_READ_DEMOD(state, ERRCNT22);
-   h = STV090x_GETFIELD_Px(reg, ERR_CNT2_FIELD);
+   h = STV090x_GETFIELD_Px(reg, ERR_CNT22_FIELD);
 
reg = STV090x_READ_DEMOD(state, ERRCNT21);
m = STV090x_GETFIELD_Px(reg, ERR_CNT21_FIELD);
diff --git a/drivers/media/dvb/frontends/stv090x_reg.h 
b/drivers/media/dvb/frontends/stv090x_reg.h
index 93741ee..26c8885 100644
--- a/drivers/media/dvb/frontends/stv090x_reg.h
+++ b/drivers/media/dvb/frontends/stv090x_reg.h
@@ -2232,8 +2232,8 @@
 #define STV090x_P2_ERRCNT22STV090x_Px_ERRCNT22(2)
 #define STV090x_OFFST_Px_ERRCNT2_OLDVALUE_FIELD7
 #define STV090x_WIDTH_Px_ERRCNT2_OLDVALUE_FIELD1
-#define STV090x_OFFST_Px_ERR_CNT2_FIELD0
-#define STV090x_WIDTH_Px_ERR_CNT2_FIELD7
+#define STV090x_OFFST_Px_ERR_CNT22_FIELD   0
+#define STV090x_WIDTH_Px_ERR_CNT22_FIELD   7
 
 #define STV090x_Px_ERRCNT21(__x)   (0xF59E - (__x - 1) * 
0x200)
 #define STV090x_P1_ERRCNT21STV090x_Px_ERRCNT21(1)
-- 
1.7.2.5

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

Re: [PATCH 2/3] stv090x: use error counter 1 for BER estimation

2012-03-11 Thread Andreas Regel

---
 drivers/media/dvb/frontends/stv090x.c |   30 +-
 1 files changed, 29 insertions(+), 1 deletions(-)

diff --git a/drivers/media/dvb/frontends/stv090x.c 
b/drivers/media/dvb/frontends/stv090x.c
index 6c3c095..afbd50c 100644
--- a/drivers/media/dvb/frontends/stv090x.c
+++ b/drivers/media/dvb/frontends/stv090x.c
@@ -3512,6 +3512,33 @@ static int stv090x_read_status(struct dvb_frontend *fe, 
enum fe_status *status)
return 0;
 }
 
+static int stv090x_read_ber(struct dvb_frontend *fe, u32 *ber)
+{
+   struct stv090x_state *state = fe-demodulator_priv;
+
+   u32 reg, h, m, l;
+   enum fe_status status;
+
+   stv090x_read_status(fe, status);
+   if (!(status  FE_HAS_LOCK)) {
+   *ber = 1  23; /* Max BER */
+   } else {
+   /* Counter 1 */
+   reg = STV090x_READ_DEMOD(state, ERRCNT12);
+   h = STV090x_GETFIELD_Px(reg, ERR_CNT12_FIELD);
+
+   reg = STV090x_READ_DEMOD(state, ERRCNT11);
+   m = STV090x_GETFIELD_Px(reg, ERR_CNT11_FIELD);
+
+   reg = STV090x_READ_DEMOD(state, ERRCNT10);
+   l = STV090x_GETFIELD_Px(reg, ERR_CNT10_FIELD);
+
+   *ber = ((h  16) | (m  8) | l);
+   }
+   return 0;
+}
+
+#if 0
 static int stv090x_read_per(struct dvb_frontend *fe, u32 *per)
 {
struct stv090x_state *state = fe-demodulator_priv;
@@ -3562,6 +3589,7 @@ err:
dprintk(FE_ERROR, 1, I/O error);
return -1;
 }
+#endif
 
 static int stv090x_table_lookup(const struct stv090x_tab *tab, int max, int 
val)
 {
@@ -4740,7 +4768,7 @@ static struct dvb_frontend_ops stv090x_ops = {
 
.search = stv090x_search,
.read_status= stv090x_read_status,
-   .read_ber   = stv090x_read_per,
+   .read_ber   = stv090x_read_ber,
.read_signal_strength   = stv090x_read_signal_strength,
.read_snr   = stv090x_read_cnr,
 };
-- 
1.7.2.5
 
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 3/3] stv090x: On STV0903 do not set registers of the second path.

2012-03-11 Thread Andreas Regel

resend w/o line-wrapps.

---
 drivers/media/dvb/frontends/stv090x.c |  141 ++--
 1 files changed, 132 insertions(+), 9 deletions(-)

diff --git a/drivers/media/dvb/frontends/stv090x.c 
b/drivers/media/dvb/frontends/stv090x.c
index afbd50c..ce064a3 100644
--- a/drivers/media/dvb/frontends/stv090x.c
+++ b/drivers/media/dvb/frontends/stv090x.c
@@ -4268,7 +4268,7 @@ err:
return -1;
 }
 
-static int stv090x_set_tspath(struct stv090x_state *state)
+static int stv0900_set_tspath(struct stv090x_state *state)
 {
u32 reg;
 
@@ -4539,6 +4539,121 @@ err:
return -1;
 }
 
+static int stv0903_set_tspath(struct stv090x_state *state)
+{
+   u32 reg;
+
+   if (state-internal-dev_ver = 0x20) {
+   switch (state-config-ts1_mode) {
+   case STV090x_TSMODE_PARALLEL_PUNCTURED:
+   case STV090x_TSMODE_DVBCI:
+   stv090x_write_reg(state, STV090x_TSGENERAL, 0x00);
+   break;
+
+   case STV090x_TSMODE_SERIAL_PUNCTURED:
+   case STV090x_TSMODE_SERIAL_CONTINUOUS:
+   default:
+   stv090x_write_reg(state, STV090x_TSGENERAL, 0x0c);
+   break;
+   }
+   } else {
+   switch (state-config-ts1_mode) {
+   case STV090x_TSMODE_PARALLEL_PUNCTURED:
+   case STV090x_TSMODE_DVBCI:
+   stv090x_write_reg(state, STV090x_TSGENERAL1X, 0x10);
+   break;
+
+   case STV090x_TSMODE_SERIAL_PUNCTURED:
+   case STV090x_TSMODE_SERIAL_CONTINUOUS:
+   default:
+   stv090x_write_reg(state, STV090x_TSGENERAL1X, 0x14);
+   break;
+   }
+   }
+
+   switch (state-config-ts1_mode) {
+   case STV090x_TSMODE_PARALLEL_PUNCTURED:
+   reg = stv090x_read_reg(state, STV090x_P1_TSCFGH);
+   STV090x_SETFIELD_Px(reg, TSFIFO_SERIAL_FIELD, 0x00);
+   STV090x_SETFIELD_Px(reg, TSFIFO_DVBCI_FIELD, 0x00);
+   if (stv090x_write_reg(state, STV090x_P1_TSCFGH, reg)  0)
+   goto err;
+   break;
+
+   case STV090x_TSMODE_DVBCI:
+   reg = stv090x_read_reg(state, STV090x_P1_TSCFGH);
+   STV090x_SETFIELD_Px(reg, TSFIFO_SERIAL_FIELD, 0x00);
+   STV090x_SETFIELD_Px(reg, TSFIFO_DVBCI_FIELD, 0x01);
+   if (stv090x_write_reg(state, STV090x_P1_TSCFGH, reg)  0)
+   goto err;
+   break;
+
+   case STV090x_TSMODE_SERIAL_PUNCTURED:
+   reg = stv090x_read_reg(state, STV090x_P1_TSCFGH);
+   STV090x_SETFIELD_Px(reg, TSFIFO_SERIAL_FIELD, 0x01);
+   STV090x_SETFIELD_Px(reg, TSFIFO_DVBCI_FIELD, 0x00);
+   if (stv090x_write_reg(state, STV090x_P1_TSCFGH, reg)  0)
+   goto err;
+   break;
+
+   case STV090x_TSMODE_SERIAL_CONTINUOUS:
+   reg = stv090x_read_reg(state, STV090x_P1_TSCFGH);
+   STV090x_SETFIELD_Px(reg, TSFIFO_SERIAL_FIELD, 0x01);
+   STV090x_SETFIELD_Px(reg, TSFIFO_DVBCI_FIELD, 0x01);
+   if (stv090x_write_reg(state, STV090x_P1_TSCFGH, reg)  0)
+   goto err;
+   break;
+
+   default:
+   break;
+   }
+
+   if (state-config-ts1_clk  0) {
+   u32 speed;
+
+   switch (state-config-ts1_mode) {
+   case STV090x_TSMODE_PARALLEL_PUNCTURED:
+   case STV090x_TSMODE_DVBCI:
+   default:
+   speed = state-internal-mclk /
+   (state-config-ts1_clk / 4);
+   if (speed  0x08)
+   speed = 0x08;
+   if (speed  0xFF)
+   speed = 0xFF;
+   break;
+   case STV090x_TSMODE_SERIAL_PUNCTURED:
+   case STV090x_TSMODE_SERIAL_CONTINUOUS:
+   speed = state-internal-mclk /
+   (state-config-ts1_clk / 32);
+   if (speed  0x20)
+   speed = 0x20;
+   if (speed  0xFF)
+   speed = 0xFF;
+   break;
+   }
+   reg = stv090x_read_reg(state, STV090x_P1_TSCFGM);
+   STV090x_SETFIELD_Px(reg, TSFIFO_MANSPEED_FIELD, 3);
+   if (stv090x_write_reg(state, STV090x_P1_TSCFGM, reg)  0)
+   goto err;
+   if (stv090x_write_reg(state, STV090x_P1_TSSPEED, speed)  0)
+   goto err;
+   }
+
+   reg = stv090x_read_reg(state, STV090x_P1_TSCFGH);
+   STV090x_SETFIELD_Px(reg, RST_HWARE_FIELD, 0x01);
+   if (stv090x_write_reg(state, STV090x_P1_TSCFGH, reg)  0)
+   goto err;
+

[PATCH 1/2] stb0899: set FE_HAS_SIGNAL flag in read_status

2012-02-28 Thread Andreas Regel


In stb0899_read_status the FE_HAS_SIGNAL flag was not set in case of a
successful carrier lock. This change fixes that.

Signed-off-by: Andreas Regel andreas.re...@gmx.de
---
 drivers/media/dvb/frontends/stb0899_drv.c |4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/media/dvb/frontends/stb0899_drv.c 
b/drivers/media/dvb/frontends/stb0899_drv.c

index 38565be..4a58afc 100644
--- a/drivers/media/dvb/frontends/stb0899_drv.c
+++ b/drivers/media/dvb/frontends/stb0899_drv.c
@@ -1071,7 +1071,7 @@ static int stb0899_read_status(struct dvb_frontend 
*fe, enum fe_status *status)

reg  = stb0899_read_reg(state, STB0899_VSTATUS);
if (STB0899_GETFIELD(VSTATUS_LOCKEDVIT, reg)) {
 dprintk(state-verbose, FE_DEBUG, 1,  FE_HAS_CARRIER | 
FE_HAS_LOCK);

-   *status |= FE_HAS_CARRIER | FE_HAS_LOCK;
+   *status |= FE_HAS_SIGNAL | FE_HAS_CARRIER | 
FE_HAS_LOCK;
reg = stb0899_read_reg(state, STB0899_PLPARM);
if (STB0899_GETFIELD(VITCURPUN, reg)) {
@@ -1088,7 +1088,7 @@ static int stb0899_read_status(struct dvb_frontend 
*fe, enum fe_status *status)

if (internal-lock) {
reg = STB0899_READ_S2REG(STB0899_S2DEMOD, DMD_STAT2);
 			if (STB0899_GETFIELD(UWP_LOCK, reg)  STB0899_GETFIELD(CSM_LOCK, 
reg)) {

-   *status |= FE_HAS_CARRIER;
+   *status |= FE_HAS_SIGNAL | FE_HAS_CARRIER;
dprintk(state-verbose, FE_DEBUG, 1,
UWP  CSM Lock ! --- DVB-S2 
FE_HAS_CARRIER);
 -- 1.7.2.5

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

[PATCH 2/2] stb0899: fixed reading of IF_AGC_GAIN register

2012-02-28 Thread Andreas Regel


When reading IF_AGC_GAIN register a wrong value for the base address
register was used (STB0899_DEMOD instead of STB0899_S2DEMOD). That
lead to a wrong signal strength value on DVB-S2 transponders.

Signed-off-by: Andreas Regel andreas.re...@gmx.de
---
 drivers/media/dvb/frontends/stb0899_drv.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/drivers/media/dvb/frontends/stb0899_drv.c 
b/drivers/media/dvb/frontends/stb0899_drv.c

index 4a58afc..a2e9eba 100644
--- a/drivers/media/dvb/frontends/stb0899_drv.c
+++ b/drivers/media/dvb/frontends/stb0899_drv.c
@@ -983,7 +983,7 @@ static int stb0899_read_signal_strength(struct 
dvb_frontend *fe, u16 *strength)

break;
case SYS_DVBS2:
if (internal-lock) {
-   reg = STB0899_READ_S2REG(STB0899_DEMOD, IF_AGC_GAIN);
+   reg = STB0899_READ_S2REG(STB0899_S2DEMOD, IF_AGC_GAIN);
val = STB0899_GETFIELD(IF_AGC_GAIN, reg);
  			*strength = stb0899_table_lookup(stb0899_dvbs2rf_tab, 
ARRAY_SIZE(stb0899_dvbs2rf_tab) - 1, val);

--
1.7.2.5

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

[PATCH 1/3] stv090x: Fix typo in register macros

2012-02-27 Thread Andreas Regel


Fix typo in register macros of ERRCNT2.

Signed-off-by: Andreas Regel andreas.re...@gmx.de
---
 drivers/media/dvb/frontends/stv090x.c |2 +-
 drivers/media/dvb/frontends/stv090x_reg.h |4 ++--
 2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/media/dvb/frontends/stv090x.c 
b/drivers/media/dvb/frontends/stv090x.c

index 4aef187..6c3c095 100644
--- a/drivers/media/dvb/frontends/stv090x.c
+++ b/drivers/media/dvb/frontends/stv090x.c
@@ -3526,7 +3526,7 @@ static int stv090x_read_per(struct dvb_frontend 
*fe, u32 *per)

} else {
/* Counter 2 */
reg = STV090x_READ_DEMOD(state, ERRCNT22);
-   h = STV090x_GETFIELD_Px(reg, ERR_CNT2_FIELD);
+   h = STV090x_GETFIELD_Px(reg, ERR_CNT22_FIELD);
reg = STV090x_READ_DEMOD(state, ERRCNT21);
m = STV090x_GETFIELD_Px(reg, ERR_CNT21_FIELD);
diff --git a/drivers/media/dvb/frontends/stv090x_reg.h 
b/drivers/media/dvb/frontends/stv090x_reg.h

index 93741ee..26c8885 100644
--- a/drivers/media/dvb/frontends/stv090x_reg.h
+++ b/drivers/media/dvb/frontends/stv090x_reg.h
@@ -2232,8 +2232,8 @@
 #define STV090x_P2_ERRCNT22STV090x_Px_ERRCNT22(2)
 #define STV090x_OFFST_Px_ERRCNT2_OLDVALUE_FIELD7
 #define STV090x_WIDTH_Px_ERRCNT2_OLDVALUE_FIELD1
-#define STV090x_OFFST_Px_ERR_CNT2_FIELD0
-#define STV090x_WIDTH_Px_ERR_CNT2_FIELD7
+#define STV090x_OFFST_Px_ERR_CNT22_FIELD   0
+#define STV090x_WIDTH_Px_ERR_CNT22_FIELD   7
  #define STV090x_Px_ERRCNT21(__x)  (0xF59E - (__x - 1) * 
0x200)
 #define STV090x_P1_ERRCNT21STV090x_Px_ERRCNT21(1)
--
1.7.2.5

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

[PATCH 2/3] stv090x: use error counter 1 for BER estimation

2012-02-27 Thread Andreas Regel


Use error counter 1 of the STV090x to get a correct bit error rate value.

Signed-off-by: Andreas Regel andreas.re...@gmx.de
---
 drivers/media/dvb/frontends/stv090x.c |   30 
+-

 1 files changed, 29 insertions(+), 1 deletions(-)

diff --git a/drivers/media/dvb/frontends/stv090x.c 
b/drivers/media/dvb/frontends/stv090x.c

index 6c3c095..afbd50c 100644
--- a/drivers/media/dvb/frontends/stv090x.c
+++ b/drivers/media/dvb/frontends/stv090x.c
@@ -3512,6 +3512,33 @@ static int stv090x_read_status(struct 
dvb_frontend *fe, enum fe_status *status)

return 0;
 }
 +static int stv090x_read_ber(struct dvb_frontend *fe, u32 *ber)
+{
+   struct stv090x_state *state = fe-demodulator_priv;
+
+   u32 reg, h, m, l;
+   enum fe_status status;
+
+   stv090x_read_status(fe, status);
+   if (!(status  FE_HAS_LOCK)) {
+   *ber = 1  23; /* Max BER */
+   } else {
+   /* Counter 1 */
+   reg = STV090x_READ_DEMOD(state, ERRCNT12);
+   h = STV090x_GETFIELD_Px(reg, ERR_CNT12_FIELD);
+
+   reg = STV090x_READ_DEMOD(state, ERRCNT11);
+   m = STV090x_GETFIELD_Px(reg, ERR_CNT11_FIELD);
+
+   reg = STV090x_READ_DEMOD(state, ERRCNT10);
+   l = STV090x_GETFIELD_Px(reg, ERR_CNT10_FIELD);
+
+   *ber = ((h  16) | (m  8) | l);
+   }
+   return 0;
+}
+
+#if 0
 static int stv090x_read_per(struct dvb_frontend *fe, u32 *per)
 {
struct stv090x_state *state = fe-demodulator_priv;
@@ -3562,6 +3589,7 @@ err:
dprintk(FE_ERROR, 1, I/O error);
return -1;
 }
+#endif
  static int stv090x_table_lookup(const struct stv090x_tab *tab, int 
max, int val)

 {
@@ -4740,7 +4768,7 @@ static struct dvb_frontend_ops stv090x_ops = {
.search = stv090x_search,
.read_status= stv090x_read_status,
-   .read_ber   = stv090x_read_per,
+   .read_ber   = stv090x_read_ber,
.read_signal_strength   = stv090x_read_signal_strength,
.read_snr   = stv090x_read_cnr,
 };
--
1.7.2.5

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

[PATCH 3/3] stv090x: On STV0903 do not set registers of the second path.

2012-02-27 Thread Andreas Regel

Sometimes there is a problem when trying to access the non-existing 
registers of the second demodulator path on the STV0903.

This change removes the calls in case the driver is used on a STV0903.

Signed-off-by: Andreas Regel andreas.re...@gmx.de
---
 drivers/media/dvb/frontends/stv090x.c |  141 
++--

 1 files changed, 132 insertions(+), 9 deletions(-)

diff --git a/drivers/media/dvb/frontends/stv090x.c 
b/drivers/media/dvb/frontends/stv090x.c

index afbd50c..ce064a3 100644
--- a/drivers/media/dvb/frontends/stv090x.c
+++ b/drivers/media/dvb/frontends/stv090x.c
@@ -4268,7 +4268,7 @@ err:
return -1;
 }
 -static int stv090x_set_tspath(struct stv090x_state *state)
+static int stv0900_set_tspath(struct stv090x_state *state)
 {
u32 reg;
 @@ -4539,6 +4539,121 @@ err:
return -1;
 }
 +static int stv0903_set_tspath(struct stv090x_state *state)
+{
+   u32 reg;
+
+   if (state-internal-dev_ver = 0x20) {
+   switch (state-config-ts1_mode) {
+   case STV090x_TSMODE_PARALLEL_PUNCTURED:
+   case STV090x_TSMODE_DVBCI:
+   stv090x_write_reg(state, STV090x_TSGENERAL, 0x00);
+   break;
+
+   case STV090x_TSMODE_SERIAL_PUNCTURED:
+   case STV090x_TSMODE_SERIAL_CONTINUOUS:
+   default:
+   stv090x_write_reg(state, STV090x_TSGENERAL, 0x0c);
+   break;
+   }
+   } else {
+   switch (state-config-ts1_mode) {
+   case STV090x_TSMODE_PARALLEL_PUNCTURED:
+   case STV090x_TSMODE_DVBCI:
+   stv090x_write_reg(state, STV090x_TSGENERAL1X, 0x10);
+   break;
+
+   case STV090x_TSMODE_SERIAL_PUNCTURED:
+   case STV090x_TSMODE_SERIAL_CONTINUOUS:
+   default:
+   stv090x_write_reg(state, STV090x_TSGENERAL1X, 0x14);
+   break;
+   }
+   }
+
+   switch (state-config-ts1_mode) {
+   case STV090x_TSMODE_PARALLEL_PUNCTURED:
+   reg = stv090x_read_reg(state, STV090x_P1_TSCFGH);
+   STV090x_SETFIELD_Px(reg, TSFIFO_SERIAL_FIELD, 0x00);
+   STV090x_SETFIELD_Px(reg, TSFIFO_DVBCI_FIELD, 0x00);
+   if (stv090x_write_reg(state, STV090x_P1_TSCFGH, reg)  0)
+   goto err;
+   break;
+
+   case STV090x_TSMODE_DVBCI:
+   reg = stv090x_read_reg(state, STV090x_P1_TSCFGH);
+   STV090x_SETFIELD_Px(reg, TSFIFO_SERIAL_FIELD, 0x00);
+   STV090x_SETFIELD_Px(reg, TSFIFO_DVBCI_FIELD, 0x01);
+   if (stv090x_write_reg(state, STV090x_P1_TSCFGH, reg)  0)
+   goto err;
+   break;
+
+   case STV090x_TSMODE_SERIAL_PUNCTURED:
+   reg = stv090x_read_reg(state, STV090x_P1_TSCFGH);
+   STV090x_SETFIELD_Px(reg, TSFIFO_SERIAL_FIELD, 0x01);
+   STV090x_SETFIELD_Px(reg, TSFIFO_DVBCI_FIELD, 0x00);
+   if (stv090x_write_reg(state, STV090x_P1_TSCFGH, reg)  0)
+   goto err;
+   break;
+
+   case STV090x_TSMODE_SERIAL_CONTINUOUS:
+   reg = stv090x_read_reg(state, STV090x_P1_TSCFGH);
+   STV090x_SETFIELD_Px(reg, TSFIFO_SERIAL_FIELD, 0x01);
+   STV090x_SETFIELD_Px(reg, TSFIFO_DVBCI_FIELD, 0x01);
+   if (stv090x_write_reg(state, STV090x_P1_TSCFGH, reg)  0)
+   goto err;
+   break;
+
+   default:
+   break;
+   }
+
+   if (state-config-ts1_clk  0) {
+   u32 speed;
+
+   switch (state-config-ts1_mode) {
+   case STV090x_TSMODE_PARALLEL_PUNCTURED:
+   case STV090x_TSMODE_DVBCI:
+   default:
+   speed = state-internal-mclk /
+   (state-config-ts1_clk / 4);
+   if (speed  0x08)
+   speed = 0x08;
+   if (speed  0xFF)
+   speed = 0xFF;
+   break;
+   case STV090x_TSMODE_SERIAL_PUNCTURED:
+   case STV090x_TSMODE_SERIAL_CONTINUOUS:
+   speed = state-internal-mclk /
+   (state-config-ts1_clk / 32);
+   if (speed  0x20)
+   speed = 0x20;
+   if (speed  0xFF)
+   speed = 0xFF;
+   break;
+   }
+   reg = stv090x_read_reg(state, STV090x_P1_TSCFGM);
+   STV090x_SETFIELD_Px(reg, TSFIFO_MANSPEED_FIELD, 3);
+   if (stv090x_write_reg(state, STV090x_P1_TSCFGM, reg)  0)
+   goto err;
+   if (stv090x_write_reg(state, STV090x_P1_TSSPEED, speed)  0)
+   goto err

Mystique SaTiX-S2 Sky Xpress DUAL card

2011-12-29 Thread Andreas Mair

Hello,

I'm using that card in my Linux VDR box:
http://www.dvbshop.net/product_info.php/info/p2440_Mystique-SaTiX-S2-Sky-Xpress-DUAL--USALS--DiseqC-1-2--Win-Linux.html

That's the lspci output:
=== SNIP =
$ lspci -vvvnn
02:00.0 Multimedia video controller [0400]: Conexant Systems, Inc.
CX23885 PCI Video and Audio Decoder [14f1:8852] (rev 02)
Subsystem: Device [4254:0952]
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast TAbort-
TAbort- MAbort- SERR- PERR- INTx-
Latency: 0, Cache Line Size: 64 bytes
Interrupt: pin A routed to IRQ 16
Region 0: Memory at fe40 (64-bit, non-prefetchable) [size=2M]
Capabilities: [40] Express (v1) Endpoint, MSI 00
DevCap: MaxPayload 128 bytes, PhantFunc 0, Latency L0s
64ns, L1 1us
ExtTag- AttnBtn- AttnInd- PwrInd- RBE- FLReset-
DevCtl: Report errors: Correctable- Non-Fatal- Fatal-
Unsupported-
RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop+
MaxPayload 128 bytes, MaxReadReq 512 bytes
DevSta: CorrErr- UncorrErr+ FatalErr- UnsuppReq+
AuxPwr- TransPend-
LnkCap: Port #0, Speed 2.5GT/s, Width x1, ASPM L0s L1,
Latency L0 2us, L1 4us
ClockPM- Surprise- LLActRep- BwNot-
LnkCtl: ASPM Disabled; RCB 64 bytes Disabled- Retrain- CommClk+
ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
LnkSta: Speed 2.5GT/s, Width x1, TrErr- Train-
SlotClk+ DLActive- BWMgmt- ABWMgmt-
Capabilities: [80] Power Management version 2
Flags: PMEClk- DSI+ D1+ D2+ AuxCurrent=0mA
PME(D0+,D1+,D2+,D3hot+,D3cold-)
Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
Capabilities: [90] Vital Product Data
Product Name: 
End
Capabilities: [a0] MSI: Enable- Count=1/1 Maskable- 64bit+
Address:   Data: 
Capabilities: [100] Advanced Error Reporting
UESta:  DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt-
UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq+ ACSViol-
UEMsk:  DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt-
UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSViol-
UESvrt: DLP+ SDES- TLP- FCP+ CmpltTO- CmpltAbrt-
UnxCmplt- RxOF+ MalfTLP+ ECRC- UnsupReq- ACSViol-
CESta:  RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr-
CEMsk:  RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr-
AERCap: First Error Pointer: 14, GenCap- CGenEn- ChkCap- ChkEn-
Capabilities: [200] Virtual Channel ?
Kernel driver in use: cx23885
Kernel modules: cx23885
=== SNAP =

So this is different to what's written at
http://linuxtv.org/wiki/index.php/Mystique_SaTiX-S2_Dual
I guess it's more like that card: http://linuxtv.org/wiki/index.php/DVBSKY_S952

I'm using the drivers found at http://www.dvbsky.net/Support.html
(http://www.dvbsky.net/download/linux-3.0-media-20111024-bst-111205.tar.gz).
I didn't get that card running with kernel 3.0.6 and haven't seen
support for that card in any linuxtv.org repository I've looked into.

Now I wonder:
- Who is responsible for that drivers? Someone at DVBSky.net?
- Is there a chance to get that drivers into the kernel?
- Has anybody else on this list this card running?

Best regards,
Andreas
-- 
http://andreas.vdr-developer.org --- VDRAdmin-AM  EnigmaNG  VDRSymbols
VDR user #303
--
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 03/91] [media] dvb-core: add support for a DVBv5 get_frontend() callback

2011-12-27 Thread Andreas Oberritter

On 27.12.2011 02:07, Mauro Carvalho Chehab wrote:
 The old method is renamed to get_frontend_legacy(), while not all
 frontends are converted.
 
 Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com
 ---
  drivers/media/dvb/bt8xx/dst.c   |8 +-
  drivers/media/dvb/dvb-core/dvb_frontend.c   |  102 --
  drivers/media/dvb/dvb-core/dvb_frontend.h   |5 +-
  drivers/media/dvb/dvb-usb/af9005-fe.c   |4 +-
  drivers/media/dvb/dvb-usb/cinergyT2-fe.c|2 +-
  drivers/media/dvb/dvb-usb/dtt200u-fe.c  |2 +-
  drivers/media/dvb/dvb-usb/friio-fe.c|2 +-
  drivers/media/dvb/dvb-usb/mxl111sf-demod.c  |2 +-
  drivers/media/dvb/dvb-usb/vp702x-fe.c   |2 +-
  drivers/media/dvb/dvb-usb/vp7045-fe.c   |2 +-
  drivers/media/dvb/firewire/firedtv-fe.c |2 +-
  drivers/media/dvb/frontends/af9013.c|2 +-
  drivers/media/dvb/frontends/atbm8830.c  |2 +-
  drivers/media/dvb/frontends/au8522_dig.c|2 +-
  drivers/media/dvb/frontends/cx22700.c   |2 +-
  drivers/media/dvb/frontends/cx22702.c   |2 +-
  drivers/media/dvb/frontends/cx24110.c   |2 +-
  drivers/media/dvb/frontends/cx24123.c   |2 +-
  drivers/media/dvb/frontends/cxd2820r_core.c |4 +-
  drivers/media/dvb/frontends/dib3000mb.c |2 +-
  drivers/media/dvb/frontends/dib3000mc.c |2 +-
  drivers/media/dvb/frontends/dib7000m.c  |2 +-
  drivers/media/dvb/frontends/dib7000p.c  |2 +-
  drivers/media/dvb/frontends/dib8000.c   |4 +-
  drivers/media/dvb/frontends/dib9000.c   |4 +-
  drivers/media/dvb/frontends/drxd_hard.c |2 +-
  drivers/media/dvb/frontends/drxk_hard.c |4 +-
  drivers/media/dvb/frontends/dvb_dummy_fe.c  |6 +-
  drivers/media/dvb/frontends/it913x-fe.c |2 +-
  drivers/media/dvb/frontends/l64781.c|2 +-
  drivers/media/dvb/frontends/lgdt3305.c  |4 +-
  drivers/media/dvb/frontends/lgdt330x.c  |4 +-
  drivers/media/dvb/frontends/lgs8gl5.c   |2 +-
  drivers/media/dvb/frontends/lgs8gxx.c   |2 +-
  drivers/media/dvb/frontends/mb86a20s.c  |2 +-
  drivers/media/dvb/frontends/mt312.c |2 +-
  drivers/media/dvb/frontends/mt352.c |2 +-
  drivers/media/dvb/frontends/or51132.c   |2 +-
  drivers/media/dvb/frontends/s5h1409.c   |2 +-
  drivers/media/dvb/frontends/s5h1411.c   |2 +-
  drivers/media/dvb/frontends/s5h1420.c   |2 +-
  drivers/media/dvb/frontends/s5h1432.c   |2 +-
  drivers/media/dvb/frontends/s921.c  |2 +-
  drivers/media/dvb/frontends/stb0899_drv.c   |2 +-
  drivers/media/dvb/frontends/stb6100.c   |4 +-
  drivers/media/dvb/frontends/stv0297.c   |2 +-
  drivers/media/dvb/frontends/stv0299.c   |2 +-
  drivers/media/dvb/frontends/stv0367.c   |4 +-
  drivers/media/dvb/frontends/stv0900_core.c  |2 +-
  drivers/media/dvb/frontends/tda10021.c  |2 +-
  drivers/media/dvb/frontends/tda10023.c  |2 +-
  drivers/media/dvb/frontends/tda10048.c  |2 +-
  drivers/media/dvb/frontends/tda1004x.c  |4 +-
  drivers/media/dvb/frontends/tda10071.c  |2 +-
  drivers/media/dvb/frontends/tda10086.c  |2 +-
  drivers/media/dvb/frontends/tda8083.c   |2 +-
  drivers/media/dvb/frontends/ves1820.c   |2 +-
  drivers/media/dvb/frontends/ves1x93.c   |2 +-
  drivers/media/dvb/frontends/zl10353.c   |2 +-
  drivers/media/dvb/siano/smsdvb.c|2 +-
  drivers/media/video/tlg2300/pd-dvb.c|2 +-
  drivers/staging/media/as102/as102_fe.c  |2 +-
  62 files changed, 157 insertions(+), 100 deletions(-)
 
 diff --git a/drivers/media/dvb/bt8xx/dst.c b/drivers/media/dvb/bt8xx/dst.c
 index 4658bd6..6afc083 100644
 --- a/drivers/media/dvb/bt8xx/dst.c
 +++ b/drivers/media/dvb/bt8xx/dst.c
 @@ -1778,7 +1778,7 @@ static struct dvb_frontend_ops dst_dvbt_ops = {
   .init = dst_init,
   .tune = dst_tune_frontend,
   .set_frontend_legacy = dst_set_frontend,
 - .get_frontend = dst_get_frontend,
 + .get_frontend_legacy = dst_get_frontend,
   .get_frontend_algo = dst_get_tuning_algo,
   .read_status = dst_read_status,
   .read_signal_strength = dst_read_signal_strength,
 @@ -1804,7 +1804,7 @@ static struct dvb_frontend_ops dst_dvbs_ops = {
   .init = dst_init,
   .tune = dst_tune_frontend,
   .set_frontend_legacy = dst_set_frontend,
 - .get_frontend = dst_get_frontend,
 + .get_frontend_legacy = dst_get_frontend,
   .get_frontend_algo = dst_get_tuning_algo,
   .read_status = dst_read_status,
   .read_signal_strength = dst_read_signal_strength,
 @@ -1838,7 +1838,7 @@ static struct dvb_frontend_ops dst_dvbc_ops = {
   .init = dst_init,
   .tune = dst_tune_frontend,
   .set_frontend_legacy = dst_set_frontend,
 - .get_frontend = dst_get_frontend,
 +

Re: [PATCH RFC 01/91] [media] dvb-core: allow demods to specify the supported delivery systems supported standards.

2011-12-27 Thread Andreas Oberritter

On 27.12.2011 18:06, Mauro Carvalho Chehab wrote:
 On 27-12-2011 12:33, Andreas Oberritter wrote:
 On 27.12.2011 14:28, Mauro Carvalho Chehab wrote:
 On 27-12-2011 10:11, Andreas Oberritter wrote:
 On 27.12.2011 02:07, Mauro Carvalho Chehab wrote:
 DVB-S and DVB-T, as those were the standards supported by DVBv3.

 The description seems to be incomplete.

 New standards like DSS, ISDB and CTTB don't fit on any of the
 above types.

 while there's a way for the drivers to explicitly change whatever
 default DELSYS were filled inside the core, still a fake value is
 needed there, and a compat code to allow DVBv3 applications to
 work with those delivery systems is needed. This is good for a
 short term solution, while applications aren't using DVBv5 directly.

 However, at long term, this is bad, as the compat code runs even
 if the application is using DVBv5. Also, the compat code is not
 perfect, and only works when the frontend is capable of auto-detecting
 the parameters that aren't visible by the faked delivery systems.

 So, let the frontend fill the supported delivery systems at the
 device properties directly, and, in the future, let the core to use
 the delsys to fill the reported info::type based on the delsys.

 Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com
 ---
  drivers/media/dvb/dvb-core/dvb_frontend.c |   13 +
  drivers/media/dvb/dvb-core/dvb_frontend.h |8 
  2 files changed, 21 insertions(+), 0 deletions(-)

 diff --git a/drivers/media/dvb/dvb-core/dvb_frontend.c 
 b/drivers/media/dvb/dvb-core/dvb_frontend.c
 index 8dedff4..f17c411 100644
 --- a/drivers/media/dvb/dvb-core/dvb_frontend.c
 +++ b/drivers/media/dvb/dvb-core/dvb_frontend.c
 @@ -1252,6 +1252,19 @@ static void dtv_set_default_delivery_caps(const 
 struct dvb_frontend *fe, struct
   const struct dvb_frontend_info *info = fe-ops.info;
   u32 ncaps = 0;
  
 + /*
 +  * If the frontend explicitly sets a list, use it, instead of
 +  * filling based on the info-type
 +  */
 + if (fe-ops.delsys[ncaps]) {
 + while (fe-ops.delsys[ncaps]  ncaps  MAX_DELSYS) {
 + p-u.buffer.data[ncaps] = fe-ops.delsys[ncaps];
 + ncaps++;
 + }
 + p-u.buffer.len = ncaps;
 + return;
 + }
 +

 I don't understand what this is trying to solve. This is already handled
 by the get_property driver callback.

 dtv_set_default_delivery_caps() only sets some defaults for drivers not
 implementing get_property yet.

 dtv_set_default_delivery_caps() does the wrong thing for delivery systems
 like ISDB-T, ISDB-S, DSS, DMB-TH, as it fills data with a fake value that
 is there at fe-ops.info.type. 

 The fake values there should be used only for DVBv3 legacy calls emulation
 on those delivery systems that are not fully compatible with a DVBv3 call.

 That's right. Still, there's no need to introduce fe-ops.delsys,
 because the drivers in question could just implement get_property
 instead. At least that's what we discussed and AFAIR agreed upon when
 Manu recently submitted his patches regarding enumeration of delivery
 systems.
 
 Manu's patches were applied (well, except for two patches related to af9013
 driver that are/were under discussion between Manu and Antti).
 
 Manu's approach is good, as it provided a way to enumerate the 
 standards without much changes, offering a way for userspace to
 query the delivery system, at the expense of serializing a driver 
 call for each property. 
 
 Yet, it doesn't allow the DVB core to detect the supported
 delivery systems on a sane way [1].
 
 The addition of fe-ops.delsys is going one step further, as it will
 allow, at the long term, the removal of info.type.

You can't remove info.type, as it would break userspace. What you can do
is deprecate its use inside drivers.

 There are two reasons why we need to get rid of info.type:
 
 1) dvb_frontend core can be changed to use fe-ops.delsys
internally, instead of info.type, in order to fix some
bugs inside it, where it does the wrong assumption, because
the frontend is lying about the delivery system;
 
 2) There is no sane way to fill fe-ops.info.type for Multi delivery
system frontends, like DRX-K, that supports both DVB-T and DVB-C.
The type can be filled with either FE_QAM or FE_OFDM, not with both.
So, choosing either type will be plain wrong, and may cause bad
side effects inside dvb_frontend.
 
 [1] Ok, it would be possible to do a hack internally, for it to call
 get_property() but it is a way more sane to just read fe-ops.delsys.

I don't see why using the already defined interface to query the
possible delivery systems would be a hack.

I also don't see what the enumeration has to do with the deprecation of
fe-ops.info.type. If you want to replace fe-ops.info.type, then what
you need to know is the currently selected delivery system, not the
supported delivery systems. The currently selected system is available
from the property cache

Re: [PATCH RFC 03/91] [media] dvb-core: add support for a DVBv5 get_frontend() callback

2011-12-27 Thread Andreas Oberritter

On 27.12.2011 18:26, Mauro Carvalho Chehab wrote:
 On 27-12-2011 12:47, Andreas Oberritter wrote:
 On 27.12.2011 14:49, Mauro Carvalho Chehab wrote:
 On 27-12-2011 10:21, Andreas Oberritter wrote:
 On 27.12.2011 02:07, Mauro Carvalho Chehab wrote:
 The old method is renamed to get_frontend_legacy(), while not all
 frontends are converted.

 Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com
 ---
  drivers/media/dvb/bt8xx/dst.c   |8 +-
  drivers/media/dvb/dvb-core/dvb_frontend.c   |  102 
 --
  drivers/media/dvb/dvb-core/dvb_frontend.h   |5 +-
  drivers/media/dvb/dvb-usb/af9005-fe.c   |4 +-
  drivers/media/dvb/dvb-usb/cinergyT2-fe.c|2 +-
  drivers/media/dvb/dvb-usb/dtt200u-fe.c  |2 +-
  drivers/media/dvb/dvb-usb/friio-fe.c|2 +-
  drivers/media/dvb/dvb-usb/mxl111sf-demod.c  |2 +-
  drivers/media/dvb/dvb-usb/vp702x-fe.c   |2 +-
  drivers/media/dvb/dvb-usb/vp7045-fe.c   |2 +-
  drivers/media/dvb/firewire/firedtv-fe.c |2 +-
  drivers/media/dvb/frontends/af9013.c|2 +-
  drivers/media/dvb/frontends/atbm8830.c  |2 +-
  drivers/media/dvb/frontends/au8522_dig.c|2 +-
  drivers/media/dvb/frontends/cx22700.c   |2 +-
  drivers/media/dvb/frontends/cx22702.c   |2 +-
  drivers/media/dvb/frontends/cx24110.c   |2 +-
  drivers/media/dvb/frontends/cx24123.c   |2 +-
  drivers/media/dvb/frontends/cxd2820r_core.c |4 +-
  drivers/media/dvb/frontends/dib3000mb.c |2 +-
  drivers/media/dvb/frontends/dib3000mc.c |2 +-
  drivers/media/dvb/frontends/dib7000m.c  |2 +-
  drivers/media/dvb/frontends/dib7000p.c  |2 +-
  drivers/media/dvb/frontends/dib8000.c   |4 +-
  drivers/media/dvb/frontends/dib9000.c   |4 +-
  drivers/media/dvb/frontends/drxd_hard.c |2 +-
  drivers/media/dvb/frontends/drxk_hard.c |4 +-
  drivers/media/dvb/frontends/dvb_dummy_fe.c  |6 +-
  drivers/media/dvb/frontends/it913x-fe.c |2 +-
  drivers/media/dvb/frontends/l64781.c|2 +-
  drivers/media/dvb/frontends/lgdt3305.c  |4 +-
  drivers/media/dvb/frontends/lgdt330x.c  |4 +-
  drivers/media/dvb/frontends/lgs8gl5.c   |2 +-
  drivers/media/dvb/frontends/lgs8gxx.c   |2 +-
  drivers/media/dvb/frontends/mb86a20s.c  |2 +-
  drivers/media/dvb/frontends/mt312.c |2 +-
  drivers/media/dvb/frontends/mt352.c |2 +-
  drivers/media/dvb/frontends/or51132.c   |2 +-
  drivers/media/dvb/frontends/s5h1409.c   |2 +-
  drivers/media/dvb/frontends/s5h1411.c   |2 +-
  drivers/media/dvb/frontends/s5h1420.c   |2 +-
  drivers/media/dvb/frontends/s5h1432.c   |2 +-
  drivers/media/dvb/frontends/s921.c  |2 +-
  drivers/media/dvb/frontends/stb0899_drv.c   |2 +-
  drivers/media/dvb/frontends/stb6100.c   |4 +-
  drivers/media/dvb/frontends/stv0297.c   |2 +-
  drivers/media/dvb/frontends/stv0299.c   |2 +-
  drivers/media/dvb/frontends/stv0367.c   |4 +-
  drivers/media/dvb/frontends/stv0900_core.c  |2 +-
  drivers/media/dvb/frontends/tda10021.c  |2 +-
  drivers/media/dvb/frontends/tda10023.c  |2 +-
  drivers/media/dvb/frontends/tda10048.c  |2 +-
  drivers/media/dvb/frontends/tda1004x.c  |4 +-
  drivers/media/dvb/frontends/tda10071.c  |2 +-
  drivers/media/dvb/frontends/tda10086.c  |2 +-
  drivers/media/dvb/frontends/tda8083.c   |2 +-
  drivers/media/dvb/frontends/ves1820.c   |2 +-
  drivers/media/dvb/frontends/ves1x93.c   |2 +-
  drivers/media/dvb/frontends/zl10353.c   |2 +-
  drivers/media/dvb/siano/smsdvb.c|2 +-
  drivers/media/video/tlg2300/pd-dvb.c|2 +-
  drivers/staging/media/as102/as102_fe.c  |2 +-
  62 files changed, 157 insertions(+), 100 deletions(-)

 diff --git a/drivers/media/dvb/bt8xx/dst.c b/drivers/media/dvb/bt8xx/dst.c
 index 4658bd6..6afc083 100644
 --- a/drivers/media/dvb/bt8xx/dst.c
 +++ b/drivers/media/dvb/bt8xx/dst.c
 @@ -1778,7 +1778,7 @@ static struct dvb_frontend_ops dst_dvbt_ops = {
   .init = dst_init,
   .tune = dst_tune_frontend,
   .set_frontend_legacy = dst_set_frontend,
 - .get_frontend = dst_get_frontend,
 + .get_frontend_legacy = dst_get_frontend,
   .get_frontend_algo = dst_get_tuning_algo,
   .read_status = dst_read_status,
   .read_signal_strength = dst_read_signal_strength,
 @@ -1804,7 +1804,7 @@ static struct dvb_frontend_ops dst_dvbs_ops = {
   .init = dst_init,
   .tune = dst_tune_frontend,
   .set_frontend_legacy = dst_set_frontend,
 - .get_frontend = dst_get_frontend,
 + .get_frontend_legacy = dst_get_frontend,
   .get_frontend_algo = dst_get_tuning_algo,
   .read_status = dst_read_status,
   .read_signal_strength = dst_read_signal_strength,
 @@ -1838,7 +1838,7 @@ static struct dvb_frontend_ops dst_dvbc_ops = {
   .init = dst_init

[RFC] remove dtv_property_dump et al

2011-12-23 Thread Andreas Oberritter

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

Adding this twice is wrong.

Almost every time new commands were added in the recent past, either the
command was not added to this table at all or the command was added more
than once. How about removing this array instead? It's only purpose is
to output ioctl parameters, which can be done with strace as well.

Actually, I have two patches queued doing that (see attachments). They
are based on 3.0.

Regards,
Andreas
From 0f9294ce272a853bb0f4513bbd07048938c78db2 Mon Sep 17 00:00:00 2001
From: Andreas Oberritter o...@linuxtv.org
Date: Tue, 13 Sep 2011 11:48:14 +
Subject: [PATCH 1/2] [RFC] DVB: remove dtv_property_dump()

- dtv_property_dump is the only user of struct dtv_cmds_h,
  which mistakenly got exported to userspace.

- It is used to print ioctl parameters, if debugging is enabled.
  The array used to print parameters contains both unused (set)
  and invalid entries, i.e. DTV_CODE_RATE_HP and others are
  defined twice.

- When a new DTV command gets added, it's a common mistake to
  forget to add it to this array.

- It's possible to use strace instead or to write a simple
  LD_PRELOADable library.

Signed-off-by: Andreas Oberritter o...@linuxtv.org
---
 drivers/media/dvb/dvb-core/dvb_frontend.c |  116 -
 include/linux/dvb/frontend.h  |   11 ---
 2 files changed, 0 insertions(+), 127 deletions(-)

diff --git a/drivers/media/dvb/dvb-core/dvb_frontend.c b/drivers/media/dvb/dvb-core/dvb_frontend.c
index 521b695..8274a6d 100644
--- a/drivers/media/dvb/dvb-core/dvb_frontend.c
+++ b/drivers/media/dvb/dvb-core/dvb_frontend.c
@@ -895,119 +895,6 @@ static int dvb_frontend_clear_cache(struct dvb_frontend *fe)
 	return 0;
 }
 
-#define _DTV_CMD(n, s, b) \
-[n] = { \
-	.name = #n, \
-	.cmd  = n, \
-	.set  = s,\
-	.buffer = b \
-}
-
-static struct dtv_cmds_h dtv_cmds[DTV_MAX_COMMAND + 1] = {
-	_DTV_CMD(DTV_TUNE, 1, 0),
-	_DTV_CMD(DTV_CLEAR, 1, 0),
-
-	/* Set */
-	_DTV_CMD(DTV_FREQUENCY, 1, 0),
-	_DTV_CMD(DTV_BANDWIDTH_HZ, 1, 0),
-	_DTV_CMD(DTV_MODULATION, 1, 0),
-	_DTV_CMD(DTV_INVERSION, 1, 0),
-	_DTV_CMD(DTV_DISEQC_MASTER, 1, 1),
-	_DTV_CMD(DTV_SYMBOL_RATE, 1, 0),
-	_DTV_CMD(DTV_INNER_FEC, 1, 0),
-	_DTV_CMD(DTV_VOLTAGE, 1, 0),
-	_DTV_CMD(DTV_TONE, 1, 0),
-	_DTV_CMD(DTV_PILOT, 1, 0),
-	_DTV_CMD(DTV_ROLLOFF, 1, 0),
-	_DTV_CMD(DTV_DELIVERY_SYSTEM, 1, 0),
-	_DTV_CMD(DTV_HIERARCHY, 1, 0),
-	_DTV_CMD(DTV_CODE_RATE_HP, 1, 0),
-	_DTV_CMD(DTV_CODE_RATE_LP, 1, 0),
-	_DTV_CMD(DTV_GUARD_INTERVAL, 1, 0),
-	_DTV_CMD(DTV_TRANSMISSION_MODE, 1, 0),
-
-	_DTV_CMD(DTV_ISDBT_PARTIAL_RECEPTION, 1, 0),
-	_DTV_CMD(DTV_ISDBT_SOUND_BROADCASTING, 1, 0),
-	_DTV_CMD(DTV_ISDBT_SB_SUBCHANNEL_ID, 1, 0),
-	_DTV_CMD(DTV_ISDBT_SB_SEGMENT_IDX, 1, 0),
-	_DTV_CMD(DTV_ISDBT_SB_SEGMENT_COUNT, 1, 0),
-	_DTV_CMD(DTV_ISDBT_LAYER_ENABLED, 1, 0),
-	_DTV_CMD(DTV_ISDBT_LAYERA_FEC, 1, 0),
-	_DTV_CMD(DTV_ISDBT_LAYERA_MODULATION, 1, 0),
-	_DTV_CMD(DTV_ISDBT_LAYERA_SEGMENT_COUNT, 1, 0),
-	_DTV_CMD(DTV_ISDBT_LAYERA_TIME_INTERLEAVING, 1, 0),
-	_DTV_CMD(DTV_ISDBT_LAYERB_FEC, 1, 0),
-	_DTV_CMD(DTV_ISDBT_LAYERB_MODULATION, 1, 0),
-	_DTV_CMD(DTV_ISDBT_LAYERB_SEGMENT_COUNT, 1, 0),
-	_DTV_CMD(DTV_ISDBT_LAYERB_TIME_INTERLEAVING, 1, 0),
-	_DTV_CMD(DTV_ISDBT_LAYERC_FEC, 1, 0),
-	_DTV_CMD(DTV_ISDBT_LAYERC_MODULATION, 1, 0),
-	_DTV_CMD(DTV_ISDBT_LAYERC_SEGMENT_COUNT, 1, 0),
-	_DTV_CMD(DTV_ISDBT_LAYERC_TIME_INTERLEAVING, 1, 0),
-
-	_DTV_CMD(DTV_ISDBT_PARTIAL_RECEPTION, 0, 0),
-	_DTV_CMD(DTV_ISDBT_SOUND_BROADCASTING, 0

Re: [RFCv1] add DTMB support for DVB API

2011-12-23 Thread Andreas Oberritter

On 22.12.2011 22:30, Antti Palosaari wrote:
 @@ -201,6 +205,9 @@ typedef enum fe_guard_interval {
  GUARD_INTERVAL_1_128,
  GUARD_INTERVAL_19_128,
  GUARD_INTERVAL_19_256,
 +GUARD_INTERVAL_PN420,
 +GUARD_INTERVAL_PN595,
 +GUARD_INTERVAL_PN945,
  } fe_guard_interval_t;

What does PN mean in this context?

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

Re: [RFCv1] add DTMB support for DVB API

2011-12-23 Thread Andreas Oberritter

On 23.12.2011 22:54, Antti Palosaari wrote:
 On 12/23/2011 12:55 PM, Mauro Carvalho Chehab wrote:
 On 22-12-2011 19:30, Antti Palosaari wrote:
 Rename DMB-TH to DTMB.

 Patrick seems to believe that CTTB is a better name. In any case,
 whatever name we pick, I think that the DocBook specs (and
 maybe a comment at the header file) should point all the known
 ways to call this standard. So, I'm fine with any choice.
 
 I am not going to change it for CTTB unless there is no some document
 given says it is more correct than DTMB. I have looked very many papers
 over there and DTMB is absolutely more common as far as I gave seen.
 
 Add few new values for existing parameters.

 Add two new parameters, interleaving and carrier.
 DTMB supports interleavers: 240 and 720.
 DTMB supports carriers: 1 and 3780.

 The API change looks sane to my eyes. I have just a couple
 comments below.
 
 I think I will add carrier modes to enum fe_transmit_mode... I will send
 new propose soon.
 
 @@ -169,8 +170,11 @@ typedef enum fe_modulation {
   APSK_16,
   APSK_32,
   DQPSK,
 +QAM_4_NR,

 While the NR is generally associated with the modulation,
 this is a channel code, and not part of the modulation itself
 (btw, the DVBv3 API calls it as constellation).

 Ok, it is easier to add it here, but maybe it would be safer
 to add a separate field for channel coding that would be used
 to enable or disable the Nordstrom-Robinson code.

 This is currently used only with QAM-4, but nothing prevents this
 parity code to be added to other types of modulation.

   } fe_modulation_t;

 +#define QAM_4 QPSK

 IMHO, this is overkill, but I'm ok with that.
 
 Anyone else have comment about that?

I don't think we should create such defines unless needed for backwards
compatibility, which is not the case.

Regards,
Andreas
--
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: v4 [PATCH 09/10] CXD2820r: Query DVB frontend delivery capabilities

2011-12-12 Thread Andreas Oberritter

On 12.12.2011 05:28, Manu Abraham wrote:
 On Sat, Dec 10, 2011 at 5:17 PM, Antti Palosaari cr...@iki.fi wrote:
 On 12/10/2011 06:44 AM, Manu Abraham wrote:

  static int cxd2820r_set_frontend(struct dvb_frontend *fe,

 [...]

 +   switch (c-delivery_system) {
 +   case SYS_DVBT:
 +   ret = cxd2820r_init_t(fe);


 +   ret = cxd2820r_set_frontend_t(fe, p);



 Anyhow, I don't now like idea you have put .init() calls to .set_frontend().
 Could you move .init() happen in .init() callback as it was earlier?
 
 This was there in the earlier patch as well. Maybe you have a
 new issue now ? ;-)
 
 ok.
 
 The argument what you make doesn't hold well, Why ?
 
 int cxd2820r_init_t(struct dvb_frontend *fe)
 {
   ret = cxd2820r_wr_reg(priv, 0x00085, 0x07);
 }
 
 
 int cxd2820r_init_c(struct dvb_frontend *fe)
 {
   ret = cxd2820r_wr_reg(priv, 0x00085, 0x07);
 }
 
 
 Now, you might like to point that, the Base I2C address location
 is different comparing DVB-T/DVBT2 to DVB-C
 
 So, If you have the init as in earlier with a common init, then you
 will likely init the wrong device at .init(), as init is called open().
 So, this might result in an additional register write, which could
 be avoided altogether.  One register access is not definitely
 something to brag about, but is definitely a small incremental
 difference. Other than that this register write doesn't do anything
 more than an ADC_START. So starting the ADC at init doesn't
 make sense. But does so when you want to select the right ADC.
 So definitely, this change is an improvement. Also, you can
 compare the time taken for the device to tune now. It is quite
 a lot faster compared to without this patch. So you or any other
 user should be happy. :-)
 
 
 I don't think that in any way, the init should be used at init as
 you say, which sounds pretty much incorrect.

Maybe the function names should be modified to avoid confusion with the
init driver callback.

Regards,
Andreas
--
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: v4 [PATCH 06/10] DVB: Use a unique delivery system identifier for DVBC_ANNEX_C

2011-12-12 Thread Andreas Oberritter

On 12.12.2011 14:56, Mauro Carvalho Chehab wrote:
 On 12-12-2011 11:40, Manu Abraham wrote:
 On Mon, Dec 12, 2011 at 6:49 PM, Mauro Carvalho Chehab
 
 This also means that just doing an alias from FE_QAM and
 SYS_DVBC_ANNEX_AC
 to
 SYS_DVBC_ANNEX_A may break something, as, for most devices,
 SYS_DVBC_ANNEX_AC
 really means both Annex A and C.



 With the current approach, the application can determine whether
 the hardware supports through the DELSYS enumeration.

 So, if you have a device that needs to support both ANNEX_A and
 ANNEX_C, it should be rather doing

 case DTV_ENUM_DELSYS:
   buffer.data[0] = SYS_DVBC_ANNEX_A;
   buffer.data[1] = SYS_DVBC_ANNEX_C;
   break;
 
 Sure, but we'll need a logic to handle queries for SYS_DVBC_ANNEX_AC
 anyway, if any of the existing DVB-C drivers is currently prepared to
 support both.
 
 I'm not concerned with drx-k. The support for both standards are for
 kernel 3.3. So, no backward compatibility is needed here.
 
 While there is no explicit option, the code for stv0297, stv0367,
 tda10021 and tda10023 drivers are not clear if they support both
 (maybe roll-off might be auto-detected?) or just SYS_DVBC_ANNEX_A.

tda10021: Driver sets roll-off to 0.15. No auto-detection.
tda10023: Driver sets roll-off to 0.18. No auto-detection.

In general, auto-detection seems unlikely. Do you know any chip that
does it? Unless you do, we shouldn't expect it to exist. stv0297 doesn't
even detect IQ inversion.

 That's said, the difference between a 0.15 and a 0.13 rolloff is not big.
 I won't doubt that a demod set to 0.15 rolloff would be capable of working
 (non-optimized) with a 0.13 rolloff.
 
 What I'm saing is that, if any of the existing drivers currently works
 with both Annex A and Annex C, we'll need something equivalent to:
 
 if (delsys == SYS_DVBC_ANNEX_AC) {
 int ret = try_annex_a();
 if (ret  0)
 ret = try_annex_c();
 }

I'd prefer treating ANNEX_AC just like ANNEX_A. It won't break anything,
because register writes for ANNEX_A will be the same. i.e. applications
using SYS_DVBC_ANNEX_AC will still get the same result as before.

What may change for a user: An updated application may allow him to
select between A and C, if the frontend advertises both. In this case,
both A and C are supposed to work, depending on the location of the
user. Someone who successfully used his tuner in Japan before, and who's
frontend doesn't advertise C, will still be able to choose A and thus
use the same register settings as before.

 I didn't look inside the drivers for stv0297, stv0367, tda10021 and
 tda10023.
 I suspect that some will need an additional code to change the roll-off,
 based on
 the delivery system.



 Of course, yes this would need to make the change across multiple
 drivers.

 We can fix the drivers, that's no issue at all, as it is a small change.
 
 Indeed, it is a small change. Tuners are trivial to change, but, at the
 demod, we need to discover if roll-off is auto-detected somehow, or if
 they require manual settings, in order to fix the demod drivers.

tda10021: Register 0x3d  0x01: 0 - 0.15; 1 - 0.13
tda10023: Register 0x3d  0x03: 2 - 0.15; 3 - 0.13

Regards,
Andreas
--
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] DVB: dvb_frontend: fix delayed thread exit

2011-12-09 Thread Andreas Oberritter

On 10.12.2011 00:43, Mauro Carvalho Chehab wrote:
 On 09-12-2011 21:37, Mauro Carvalho Chehab wrote:
 On 09-12-2011 20:33, Devin Heitmueller wrote:
 On Fri, Dec 9, 2011 at 5:11 PM, Mauro Carvalho Chehab
 mche...@redhat.com wrote:
 Could someone explain reason for that?


 I dunno, but I think this needs to be fixed, at least when the frontend
 is opened with O_NONBLOCK.

 Are you doing the drx-k firmware load on dvb_init()? That could
 easily take 4 seconds.

 No. The firmware were opened previously.
 
 Maybe the delay is due to this part of dvb_frontend.c:
 
 static int dvb_mfe_wait_time = 5;
 ...
 int mferetry = (dvb_mfe_wait_time  1);
 
 mutex_unlock (adapter-mfe_lock);
 while (mferetry--  (mfedev-users != -1 ||
 mfepriv-thread != NULL)) {
 if(msleep_interruptible(500)) {
 if(signal_pending(current))
 return -EINTR;
 }
 }

I haven't looked at the mfe code, but in case it's waiting for the
frontend thread to exit, there's a problem that causes the thread
not to exit immediately. Here's a patch that's been sitting in my
queue for a while:

---

Signed-off-by: Andreas Oberritter o...@linuxtv.org

diff --git a/linux/drivers/media/dvb/dvb-core/dvb_frontend.c 
b/linux/drivers/media/dvb/dvb-core/dvb_frontend.c
index 7784d74..6823c2b 100644
--- a/linux/drivers/media/dvb/dvb-core/dvb_frontend.c   2011-09-07 
12:32:24.0 +0200
+++ a/linux/drivers/media/dvb/dvb-core/dvb_frontend.c   2011-09-13 
15:55:48.865742791 +0200
@@ -514,7 +514,7 @@
return 1;
 
if (fepriv-dvbdev-writers == 1)
-   if (time_after(jiffies, fepriv-release_jiffies +
+   if (time_after_eq(jiffies, fepriv-release_jiffies +
  dvb_shutdown_timeout * HZ))
return 1;
 
@@ -2070,12 +2070,15 @@
 
dprintk (%s\n, __func__);
 
-   if ((file-f_flags  O_ACCMODE) != O_RDONLY)
+   if ((file-f_flags  O_ACCMODE) != O_RDONLY) {
fepriv-release_jiffies = jiffies;
+   mb();
+   }
 
ret = dvb_generic_release (inode, file);
 
if (dvbdev-users == -1) {
+   wake_up(fepriv-wait_queue);
if (fepriv-exit != DVB_FE_NO_EXIT) {
fops_put(file-f_op);
file-f_op = NULL;
--
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] DVB: dvb_frontend: fix delayed thread exit

2011-12-09 Thread Andreas Oberritter

On 10.12.2011 02:59, Devin Heitmueller wrote:
 On Fri, Dec 9, 2011 at 8:37 PM, Andreas Oberritter o...@linuxtv.org wrote:
 On 10.12.2011 00:43, Mauro Carvalho Chehab wrote:
 On 09-12-2011 21:37, Mauro Carvalho Chehab wrote:
 On 09-12-2011 20:33, Devin Heitmueller wrote:
 On Fri, Dec 9, 2011 at 5:11 PM, Mauro Carvalho Chehab
 mche...@redhat.com wrote:
 Could someone explain reason for that?


 I dunno, but I think this needs to be fixed, at least when the frontend
 is opened with O_NONBLOCK.

 Are you doing the drx-k firmware load on dvb_init()? That could
 easily take 4 seconds.

 No. The firmware were opened previously.

 Maybe the delay is due to this part of dvb_frontend.c:

 static int dvb_mfe_wait_time = 5;
 ...
 int mferetry = (dvb_mfe_wait_time  1);

 mutex_unlock (adapter-mfe_lock);
 while (mferetry--  (mfedev-users != -1 ||
 mfepriv-thread != NULL)) {
 if(msleep_interruptible(500)) {
 if(signal_pending(current))
 return -EINTR;
 }
 }

 I haven't looked at the mfe code, but in case it's waiting for the
 frontend thread to exit, there's a problem that causes the thread
 not to exit immediately. Here's a patch that's been sitting in my
 queue for a while:

 ---

 Signed-off-by: Andreas Oberritter o...@linuxtv.org

 diff --git a/linux/drivers/media/dvb/dvb-core/dvb_frontend.c 
 b/linux/drivers/media/dvb/dvb-core/dvb_frontend.c
 index 7784d74..6823c2b 100644
 --- a/linux/drivers/media/dvb/dvb-core/dvb_frontend.c   2011-09-07 
 12:32:24.0 +0200
 +++ a/linux/drivers/media/dvb/dvb-core/dvb_frontend.c   2011-09-13 
 15:55:48.865742791 +0200
 @@ -514,7 +514,7 @@
return 1;

if (fepriv-dvbdev-writers == 1)
 -   if (time_after(jiffies, fepriv-release_jiffies +
 +   if (time_after_eq(jiffies, fepriv-release_jiffies +
  dvb_shutdown_timeout * HZ))
return 1;

 @@ -2070,12 +2070,15 @@

dprintk (%s\n, __func__);

 -   if ((file-f_flags  O_ACCMODE) != O_RDONLY)
 +   if ((file-f_flags  O_ACCMODE) != O_RDONLY) {
fepriv-release_jiffies = jiffies;
 +   mb();
 +   }

ret = dvb_generic_release (inode, file);

if (dvbdev-users == -1) {
 +   wake_up(fepriv-wait_queue);
if (fepriv-exit != DVB_FE_NO_EXIT) {
fops_put(file-f_op);
file-f_op = NULL;
 
 This patch needs to have a much better explanation of exactly what it
 does and what problem it solves.  We have a history of race conditions
 in dvb_frontend.c, and it's patches like this with virtually no
 details just makes it worse.
 
 I'm not arguing the actual merits of the code change - it *may* be
 correct.  But without the appropriate background there is no real way
 of knowing...
 
 Mauro, this patch should be NACK'd and resubmitted with a detailed
 explanation of the current behavior, what the problem is, and how the
 code changes proposed solve that problem.

WTF, Devin, you again? I haven't asked anyone to upstream it. Feel free
to analyze the code and resubmit it.
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

On 07.12.2011 14:49, Mark Brown wrote:
 On Tue, Dec 06, 2011 at 03:48:27PM +0100, Andreas Oberritter wrote:
 On 06.12.2011 15:19, Mark Brown wrote:
 
 Your assertatation that applications should ignore the underlying
 transport (which seems to be a big part of what you're saying) isn't
 entirely in line with reality.
 
 Did you notice that we're talking about a very particular application?
 
 *sigh*
 
 VoIP really is totally off-topic. The B in DVB stands for broadcast.
 There's only one direction in which MPEG payload is to be sent (using
 RTP for example). You can't just re-encode the data on the fly without
 loss of information.
 
 This is pretty much exactly the case for VoIP some of the time (though
 obviously bidirectional use cases are rather common there's things like
 conferencing).  I would really expect similar considerations to apply
 for video content as they certainly do in videoconferencing VoIP
 applications - if the application knows about the network it can tailor
 what it's doing to that network.  
 
 For example, if it is using a network with a guaranteed bandwidth it can
 assume that bandwidth.  If it knows something about the structure of the
 network it may be able to arrange to work around choke points.
 Depending on the situation even something lossy may be the answer - if
 it's the difference between working at all and not working then the cost
 may be worth it.

Once and for all: We have *not* discussed a generic video streaming
application. It's only, I repeat, only about accessing a remote DVB API
tuner *as if it was local*. No data received from a satellite, cable or
terrestrial DVB network shall be modified by this application!

Virtually *every* user of it will use it in a LAN.

It can't be so hard to understand.
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

On 07.12.2011 17:10, Mark Brown wrote:
 a simple loopback in the style of FUSE which
 bounces the kernel APIs up to userspace for virtual drivers would make
 sense.

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

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

On 07.12.2011 17:10, Mark Brown wrote:
 You're talking about a purely software defined thing that goes in the
 kernel - it pretty much has to be able to scale to other applications
 even if some of the implementation is left for later.  Once things like
 this get included in the kernel they become part of the ABI and having
 multiple specific things ends up being a recipie for confusion as users
 have to work out which of the options is most appropriate for their
 application.

And to repeat myself once more: No networking is to be perfomed by the
kernel in vtunerc.
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

On 07.12.2011 22:48, Patrick Dickey wrote:
 4 (and the reason I decided to chime in here).  This email sums
 everything up. Mark is pointing out that someone may want to use this in
 a non LAN setting, and they may/will have problems due to the Internet
 (and their specific way of accessing it). Andreas is arguing that it's
 not the case.

I'm sorry if I was unclear, but I'm not doing that. Contrary, I'm sure
that people using dreamtuner (which uses vtunerc from userspace) over
the Internet will run into problems if they can't provide the necessary
bandwidth.

What I'm trying to point out is that dreamtuner is not trying to solve
these problems, because it specifically has been designed for a
different purpose.

 I have to side with Mark on this one, solely because if I knew that it
 would work, I'd use it to watch television when I'm traveling (as some
 places don't carry the same channels that I have at home).

Yes, if you knew. But you wouldn't, because when travelling, it's
unlikely that you could guarantee the necessary bandwidth all the time.
I'd highly recommend you and Mark to use a different solution than
dreamtuner for your use cases.

 So, I would
 prove Mark's point.

I wonder how.

 Andreas, you said that virtually EVERY (emphasis mine) user of it will
 use it on a LAN. Virtually implies almost all-- NOT ALL. So, unless
 there's some restriction in the application, which prevents it from
 being used over the Internet, you can't guarantee that Mark's issues
 aren't valid.

It may or may not work for some people. There's no need to artificially
restrict dreamtuner to hosts on a LAN (which would be impossible anyway).

 If as HoP pointed out in another reply on this thread, there's no kernel
 patching required, then I suggest that you keep on developing it as a
 userspace application. There's no law/rule/anything that says you can't
 install your own driver in the kernel. It just won't be supported
 upstream.  That just means more work for you, if you want the
 application to continue working in the future. Truthfully, that has it's
 upsides also. If you find out about a way to improve the transmission,
 you don't have to wait (and hope) that it gets included in the kernel.
 You can include it in your driver.

FWIW, It's HoP's code. I'm not developing it.

Although you seem to have noticed that all networking happens in
userspace, you're still discussing networking issues, which may or may
not be issues of dreamtuner, but provably not of vtunerc, which just
relays DVB driver calls to userspace.

Since the topic is about the inclusion of vtunerc, not dreamtuner, such
stuff really is totally off-topic, but unfortunately got brought up
again and again.

You don't drive a formula one car or a truck if you want to have a
picnic with your family, do you? I guess you'd rather choose the right
tool for this task. So should you do if you want to stream television
over the net. People complaining that they can't transport their family
in a formula one car don't help anybody. Still both formula one cars and
trucks may be useful for other purposes.

You're free to replace dreamtuner with your superior tool solving all of
Mark's issues, even without the need to change vtunerc.

So far many people jumped into this discussion, but virtually(!) nobody
took the time to understand what vtunerc actually does by looking at the
code or at the various links HoP provided.

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

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

On 06.12.2011 12:18, Mark Brown wrote:
 On Mon, Dec 05, 2011 at 10:20:03PM +0100, Andreas Oberritter wrote:
 On 05.12.2011 21:55, Alan Cox wrote:
 The USB case is quite different because your latency is very tightly
 bounded, your dead device state is rigidly defined, and your loss of
 device is accurately and immediately signalled.
 
 Quite different.
 
 How can usbip work if networking and usb are so different and what's so
 different between vtunerc and usbip, that made it possible to put usbip
 into drivers/staging?
 
 USB-IP is a hack that will only work well on a tightly bounded set of
 networks - if you run it over a lightly loaded local network it can
 work adequately.  This starts to break down as you vary the network
 configuration.

I see. So it has problems that vtunerc doesn't have.
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

On 06.12.2011 12:21, Mark Brown wrote:
 On Mon, Dec 05, 2011 at 09:41:38PM +0100, Andreas Oberritter wrote:
 On 05.12.2011 18:39, Mauro Carvalho Chehab wrote:
 
 When you put someone via the network, issues like latency,  package
 drops, IP
 congestion, QoS issues, cryptography, tunneling, etc should be taken
 into account
 by the application, in order to properly address the network issues.
 
 Are you serious? Lower networking layers should be transparent to the
 upper layers. You don't implement VPN or say TCP in all of your
 applications, do you? These are just some more made-up arguments which
 don't have anything to do with the use cases I explained earlier.
 
 For real time applications it does make a big difference - decisions
 taken at the application level can greatly impact end application
 performance.  For example with VoIP on a LAN you can get great audio
 quality by using very little compression at the expense of high
 bandwidth and you can probably use a very small jitter buffer.  Try
 doing that over a longer distance or more congested network which drops
 packets and it becomes useful to use a more commpressed encoding for
 your data which may have better features for handling packet loss, or to
 increase your jitter buffer to cope with the less reliable transmit
 times.

Can you please explain how this relates to the topic we're discussing?
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

On 06.12.2011 14:10, Mauro Carvalho Chehab wrote:
 On 06-12-2011 10:01, Andreas Oberritter wrote:
 On 06.12.2011 12:18, Mark Brown wrote:
 On Mon, Dec 05, 2011 at 10:20:03PM +0100, Andreas Oberritter wrote:
 On 05.12.2011 21:55, Alan Cox wrote:
 The USB case is quite different because your latency is very tightly
 bounded, your dead device state is rigidly defined, and your loss of
 device is accurately and immediately signalled.

 Quite different.

 How can usbip work if networking and usb are so different and what's so
 different between vtunerc and usbip, that made it possible to put usbip
 into drivers/staging?

 USB-IP is a hack that will only work well on a tightly bounded set of
 networks - if you run it over a lightly loaded local network it can
 work adequately.  This starts to break down as you vary the network
 configuration.

 I see. So it has problems that vtunerc doesn't have.
 
 The vtunerc has the same issues. High latency (due to high loads,  high
 latency links or whatever) affects it badly, and may cause application
 breakages if if the device is opened are using O_NONBLOCK mode [1].

O_NONBLOCK doesn't mean that an ioctl must consume zero time. It just
means that it should return instead of waiting for (more) data to become
available or writeable.

Mauro, if the network is broken, any application using the network will
break. No specially designed protocol will fix that.

If you want to enforce strict maximum latencies, you can do that in the
userspace daemon using the vtunerc interface. It has all imaginable
possibilities to control data flow over the network and to return errors
to vtunerc. For a DVB API application it doesn't matter whether a tuning
request fails with EIO because a USB device has been removed, a PCI
device encountered an I2C error or because the vtuner userspace daemon
returned an error.

 [1] Btw, if some DVB ioctl currently waits in O_NONBLOCK, this is a POSIX
 violation that needs to be fixed.

To the best of my knowledge, this doesn't happen.

I think we all realized some days ago that the code is not going to be
merged upstream anytime in the foreseeable future. You can stop using
such pointless arguments.

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

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

On 06.12.2011 14:22, Mauro Carvalho Chehab wrote:
 On 05-12-2011 22:07, HoP wrote:
 I doubt that scan or w_scan would support it. Even if it supports, that
 would mean that,
 for each ioctl that would be sent to the remote server, the error
 code would
 take 480 ms
 to return. Try to calculate how many time w_scan would work with
 that. The
 calculus is easy:
 see how many ioctl's are called by each frequency and multiply by the
 number
 of frequencies
 that it would be seek. You should then add the delay introduced over
 streaming the data
 from the demux, using the same calculus. This is the additional time
 over a
 local w_scan.

 A grouch calculus with scandvb: to tune into a single DVB-C
 frequency, it
 used 45 ioctls.
 Each taking 480 ms round trip would mean an extra delay of 21.6 seconds.
 There are 155
 possible frequencies here. So, imagining that scan could deal with 21.6
 seconds of delay
 for each channel (with it doesn't), the extra delay added by it is 1
 hour
 (45 * 0.48 * 155).

 On the other hand, a solution like the one described by Florian would
 introduce a delay of
 480 ms for the entire scan to happen, as only one data packet would be
 needed to send a
 scan request, and one one stream of packets traveling at 10GB/s would
 bring
 the answer
 back.

 Andreas was excited by your imaginations and calculations, but not me.
 Now you again manifested you are not treating me as partner for
 discussion.
 Otherwise you should try to understand how-that-ugly-hack works.
 But you surelly didn't try to do it at all.

 How do you find those 45 ioctls for DVB-C tune?
 
 With strace. See how many ioctl's are called for each tune. Ok, perhaps
 scandvb
 is badly written, but if your idea is to support 100% of the
 applications, you
 should be prepared for badly written applications.
 
 $strace -e ioctl scandvb dvbc-teste
 scanning dvbc-teste
 using '/dev/dvb/adapter0/frontend0' and '/dev/dvb/adapter0/demux0'
 ioctl(3, FE_GET_INFO, 0x60a640) = 0
 initial transponder 57300 5217000 0 5
 tune to: 57300:INVERSION_AUTO:5217000:FEC_NONE:QAM_256
 ioctl(3, FE_SET_FRONTEND, 0x7fff5f7f2cd0) = 0
 ioctl(3, FE_READ_STATUS, 0x7fff5f7f2cfc) = 0
 ioctl(3, FE_READ_STATUS, 0x7fff5f7f2cfc) = 0
 ioctl(3, FE_READ_STATUS, 0x7fff5f7f2cfc) = 0
 ioctl(4, DMX_SET_FILTER, 0x7fff5f7f1ad0) = 0
 ioctl(5, DMX_SET_FILTER, 0x7fff5f7f1ad0) = 0
 ioctl(6, DMX_SET_FILTER, 0x7fff5f7f1ad0) = 0
 ioctl(7, DMX_SET_FILTER, 0x7fff5f7f1910) = 0
 ioctl(8, DMX_SET_FILTER, 0x7fff5f7f1910) = 0
 ioctl(9, DMX_SET_FILTER, 0x7fff5f7f1910) = 0
 ioctl(10, DMX_SET_FILTER, 0x7fff5f7f1910) = 0
 ioctl(11, DMX_SET_FILTER, 0x7fff5f7f1910) = 0
 ioctl(12, DMX_SET_FILTER, 0x7fff5f7f1910) = 0
 ioctl(13, DMX_SET_FILTER, 0x7fff5f7f1910) = 0
 ioctl(14, DMX_SET_FILTER, 0x7fff5f7f1910) = 0
 ioctl(15, DMX_SET_FILTER, 0x7fff5f7f1910) = 0
 ioctl(16, DMX_SET_FILTER, 0x7fff5f7f1910) = 0
 ioctl(17, DMX_SET_FILTER, 0x7fff5f7f1910) = 0
 ioctl(18, DMX_SET_FILTER, 0x7fff5f7f1910) = 0
 ioctl(19, DMX_SET_FILTER, 0x7fff5f7f1910) = 0
 ioctl(20, DMX_SET_FILTER, 0x7fff5f7f1910) = 0
 ioctl(21, DMX_SET_FILTER, 0x7fff5f7f1910) = 0
 ioctl(22, DMX_SET_FILTER, 0x7fff5f7f1910) = 0
 ioctl(23, DMX_SET_FILTER, 0x7fff5f7f1910) = 0
 ioctl(24, DMX_SET_FILTER, 0x7fff5f7f1910) = 0
 ioctl(4, DMX_STOP, 0x1) = 0
 ioctl(15, DMX_STOP, 0x1)= 0
 ioctl(11, DMX_STOP, 0x1)= 0
 ioctl(22, DMX_STOP, 0x1)= 0
 ioctl(17, DMX_STOP, 0x1)= 0
 ioctl(16, DMX_STOP, 0x1)= 0

You don't need to wait for write-only operations. Basically all demux
ioctls are write-only. Since vtunerc is using dvb-core's software demux
*locally*, errors for invalid arguments etc. will be returned as usual.

What's left is one call to FE_SET_FRONTEND for each frequency to tune
to, and one FE_READ_STATUS for each time the lock status is queried.
Note that one may use FE_GET_EVENT instead of FE_READ_STATUS to get
notified of status changes asynchronously if desired.

Btw.: FE_SET_FRONTEND doesn't block either, because the driver callback
is called from a dvb_frontend's *local* kernel thread.

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

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

On 06.12.2011 15:13, Mauro Carvalho Chehab wrote:
 O_NONBLOCK
 When opening a FIFO with O_RDONLY or O_WRONLY set:
  This does not apply.

[...]

 When opening a block special or character special file that supports
 non-blocking opens:
 
 If O_NONBLOCK is set, the open() function shall return without
 blocking for the device to be ready or available. Subsequent behavior of
 the device is device-specific.

This is the important part:
- It specifies the behaviour of open(), not ioctl(). I don't see a
reason why open should block with vtunerc.
- Read again: Subsequent behavior of the device is device-specific.

 If O_NONBLOCK is clear, the open() function shall block the
 calling thread until the device is ready or available before returning.
 
 Otherwise, the behavior of O_NONBLOCK is unspecified.
 
 Basically, syscall should not block waiting for some data to be read (or
 written).

That's because open() does not read or write.

 The ioctl definition defines [EAGAIN] error code, if, for any reason, an
 ioctl would block.

Fine.

 Btw, the vtunerc doesn't handle O_NONBLOCK flag. For each DVB ioctl, for
 example
 read_snr[1], it calls wait_event_interruptible()[2], even if the
 application opens
 it with O_NONBLOCK flag. So, it is likely that non-blocking-mode
 applications
 will break.

Of course, read operations must wait until the value read is available
or an error (e.g. timeout, i/o error) occurs. Whether it's an i2c
transfer, an usb transfer or a network transfer doesn't make a
difference. Every transfer takes a nonzero amount of time.

As Honza already demonstrated, in a typical LAN setup, this takes only
few milliseconds, which with fast devices may even be faster than some
slow local devices using many delays in their driver code.

If an application breaks because of that, then it's a bug in the
application which may as well be triggered by a local driver and thus
needs to be fixed anyway.

 Mauro, if the network is broken, any application using the network will
 break. No specially designed protocol will fix that.
 
 A high delay network (even a congested one) is not broken, if it can
 still provide the throughput required by the application, and a latency/QoS
 that would fit.

Then neither vtunerc nor any other application will break. Fine.

 If you want to enforce strict maximum latencies, you can do that in the
 userspace daemon using the vtunerc interface. It has all imaginable
 possibilities to control data flow over the network and to return errors
 to vtunerc.
 
 Yes, you can do anything you want at the userspace daemon, but the
 non-userspace daemon aware applications will know nothing about it, and
 this is the flaw on this design: Applications can't negotiate what network
 parameters are ok or not for its usecase.

How do you negotiate network parameters with your ISP and all involved
parties on the internet on the way from your DSL line to some other
peer? Let me answer it: You don't.

 For a DVB API application it doesn't matter whether a tuning
 request fails with EIO because a USB device has been removed, a PCI
 device encountered an I2C error or because the vtuner userspace daemon
 returned an error.
 
 When you go to network, there are several errors that are transitory.
 For example,
 a dropped link may cause the routing protocol (RIP, BGP or whatever) to
 re-direct
 several routes (or, on a LAN, a spanning-tree re-negotiation), causing a
 temporary
 failure to deliver a few packets. All network-based application are written
 to consider temporary failures.

I seriously doubt that, unless consider means print an error and
exit or all means some.

Anyway, such temporary failures can be handled by the userspace daemon.

 This is fundamentally different than an application designed to talk
 directly with
 the hardware, where an error is generally fatal.

Fatal or not, if you return a temporary error code like EAGAIN, for
example, that's not the case.

Do you recommend applications to just die if an ioctl fails?

Btw.: How do you handle firmware uploads via I2C in non-blocking mode?
Should applications always fail if a firmware upload that takes longer
than some ms, e.g. when tuning to a different delivery system or when
the firmware is yet to be loaded before the first ioctl may run?

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

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

On 06.12.2011 15:19, Mark Brown wrote:
 On Tue, Dec 06, 2011 at 01:01:43PM +0100, Andreas Oberritter wrote:
 On 06.12.2011 12:21, Mark Brown wrote:
 On Mon, Dec 05, 2011 at 09:41:38PM +0100, Andreas Oberritter wrote:
 
 Are you serious? Lower networking layers should be transparent to the
 upper layers. You don't implement VPN or say TCP in all of your
 applications, do you? These are just some more made-up arguments which
 don't have anything to do with the use cases I explained earlier.
 
 For real time applications it does make a big difference - decisions
 taken at the application level can greatly impact end application
 performance.  For example with VoIP on a LAN you can get great audio
 
 Can you please explain how this relates to the topic we're discussing?
 
 Your assertatation that applications should ignore the underlying
 transport (which seems to be a big part of what you're saying) isn't
 entirely in line with reality.

Did you notice that we're talking about a very particular application?

VoIP really is totally off-topic. The B in DVB stands for broadcast.
There's only one direction in which MPEG payload is to be sent (using
RTP for example). You can't just re-encode the data on the fly without
loss of information.
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

On 06.12.2011 15:20, Mauro Carvalho Chehab wrote:
 On 06-12-2011 11:49, Andreas Oberritter wrote:
 On 06.12.2011 14:22, Mauro Carvalho Chehab wrote:
 On 05-12-2011 22:07, HoP wrote:
 I doubt that scan or w_scan would support it. Even if it supports,
 that
 would mean that,
 for each ioctl that would be sent to the remote server, the error
 code would
 take 480 ms
 to return. Try to calculate how many time w_scan would work with
 that. The
 calculus is easy:
 see how many ioctl's are called by each frequency and multiply by the
 number
 of frequencies
 that it would be seek. You should then add the delay introduced over
 streaming the data
 from the demux, using the same calculus. This is the additional time
 over a
 local w_scan.

 A grouch calculus with scandvb: to tune into a single DVB-C
 frequency, it
 used 45 ioctls.
 Each taking 480 ms round trip would mean an extra delay of 21.6
 seconds.
 There are 155
 possible frequencies here. So, imagining that scan could deal with
 21.6
 seconds of delay
 for each channel (with it doesn't), the extra delay added by it is 1
 hour
 (45 * 0.48 * 155).

 On the other hand, a solution like the one described by Florian would
 introduce a delay of
 480 ms for the entire scan to happen, as only one data packet would be
 needed to send a
 scan request, and one one stream of packets traveling at 10GB/s would
 bring
 the answer
 back.

 Andreas was excited by your imaginations and calculations, but not me.
 Now you again manifested you are not treating me as partner for
 discussion.
 Otherwise you should try to understand how-that-ugly-hack works.
 But you surelly didn't try to do it at all.

 How do you find those 45 ioctls for DVB-C tune?

 With strace. See how many ioctl's are called for each tune. Ok, perhaps
 scandvb
 is badly written, but if your idea is to support 100% of the
 applications, you
 should be prepared for badly written applications.

 $strace -e ioctl scandvb dvbc-teste
 scanning dvbc-teste
 using '/dev/dvb/adapter0/frontend0' and '/dev/dvb/adapter0/demux0'
 ioctl(3, FE_GET_INFO, 0x60a640) = 0
 initial transponder 57300 5217000 0 5
 tune to: 57300:INVERSION_AUTO:5217000:FEC_NONE:QAM_256
 ioctl(3, FE_SET_FRONTEND, 0x7fff5f7f2cd0) = 0
 ioctl(3, FE_READ_STATUS, 0x7fff5f7f2cfc) = 0
 ioctl(3, FE_READ_STATUS, 0x7fff5f7f2cfc) = 0
 ioctl(3, FE_READ_STATUS, 0x7fff5f7f2cfc) = 0
 ioctl(4, DMX_SET_FILTER, 0x7fff5f7f1ad0) = 0
 ioctl(5, DMX_SET_FILTER, 0x7fff5f7f1ad0) = 0
 ioctl(6, DMX_SET_FILTER, 0x7fff5f7f1ad0) = 0
 ioctl(7, DMX_SET_FILTER, 0x7fff5f7f1910) = 0
 ioctl(8, DMX_SET_FILTER, 0x7fff5f7f1910) = 0
 ioctl(9, DMX_SET_FILTER, 0x7fff5f7f1910) = 0
 ioctl(10, DMX_SET_FILTER, 0x7fff5f7f1910) = 0
 ioctl(11, DMX_SET_FILTER, 0x7fff5f7f1910) = 0
 ioctl(12, DMX_SET_FILTER, 0x7fff5f7f1910) = 0
 ioctl(13, DMX_SET_FILTER, 0x7fff5f7f1910) = 0
 ioctl(14, DMX_SET_FILTER, 0x7fff5f7f1910) = 0
 ioctl(15, DMX_SET_FILTER, 0x7fff5f7f1910) = 0
 ioctl(16, DMX_SET_FILTER, 0x7fff5f7f1910) = 0
 ioctl(17, DMX_SET_FILTER, 0x7fff5f7f1910) = 0
 ioctl(18, DMX_SET_FILTER, 0x7fff5f7f1910) = 0
 ioctl(19, DMX_SET_FILTER, 0x7fff5f7f1910) = 0
 ioctl(20, DMX_SET_FILTER, 0x7fff5f7f1910) = 0
 ioctl(21, DMX_SET_FILTER, 0x7fff5f7f1910) = 0
 ioctl(22, DMX_SET_FILTER, 0x7fff5f7f1910) = 0
 ioctl(23, DMX_SET_FILTER, 0x7fff5f7f1910) = 0
 ioctl(24, DMX_SET_FILTER, 0x7fff5f7f1910) = 0
 ioctl(4, DMX_STOP, 0x1) = 0
 ioctl(15, DMX_STOP, 0x1)= 0
 ioctl(11, DMX_STOP, 0x1)= 0
 ioctl(22, DMX_STOP, 0x1)= 0
 ioctl(17, DMX_STOP, 0x1)= 0
 ioctl(16, DMX_STOP, 0x1)= 0

 You don't need to wait for write-only operations. Basically all demux
 ioctls are write-only. Since vtunerc is using dvb-core's software demux
 *locally*, errors for invalid arguments etc. will be returned as usual.

 What's left is one call to FE_SET_FRONTEND for each frequency to tune
 to, and one FE_READ_STATUS for each time the lock status is queried.
 Note that one may use FE_GET_EVENT instead of FE_READ_STATUS to get
 notified of status changes asynchronously if desired.

 Btw.: FE_SET_FRONTEND doesn't block either, because the driver callback
 is called from a dvb_frontend's *local* kernel thread.
 
 Still, vtunerc waits for write operations:
 
 http://code.google.com/p/vtuner/source/browse/vtunerc_proxyfe.c?repo=linux-driver#285

 No matter if they are read or write, all of them call this function:
 
 http://code.google.com/p/vtuner/source/browse/vtunerc_ctrldev.c?repo=linux-driver#390
 
 That has a wait_event inside that function, as everything is directed to
 the userspace.

Please, stop writing such bullshit! Just before the call to wait_event
there's code to return from the function if waiting has not been requested.

 This is probably the way Florian found to return the errors returned by
 the ioctls. This driver is synchronous, with simplifies it, at the lack of
 performance.

The fix is easy: set the third parameter to 0. A DVB

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