Re: Problem with example program from https://gitlab.collabora.com/koike/v4l2-codec.git

[Hans Verkuil]

On 10/07/2018 10:39 AM, Dafna Hirschfeld wrote:
> Hi,
> As part of applying to the outreachy program,
> I compiled the code in https://gitlab.collabora.com/koike/v4l2-codec.git
> I get errors running it.
> When I install vicodec.ko I see in the kernel log:
> 
> [10752.727509] vicodec vicodec.0: Device registered as /dev/video2
> [10752.727534] vicodec vicodec.0: Device registered as /dev/video3
> 
> I think /dev/video0, /dev/video1 are already used by uvcvideo

Correct.

> 
> The dev file used in v4l2-decode.c is "/dev/video1"

A patch that adds support for an argument so you can pass the device name
are welcome.

> 
> When running the code as is, it prints:
> "mmap: Invalid argument"

Yes, since video1 isn't a memory-to-memory device.

> 
> Changing the code of v4l2-decode.c to use "/dev/video0" prints:
> "Driver didn't accept RGB24 format. Can't proceed."
> 
> Changing it to use "/dev/video2" prints:
> "Driver didn't accept FWHT format. Can't proceed."
> 
> Changing it to use "/dev/video3" prints:
> "Driver didn't accept RGB24 format. Can't proceed."

This is the right device node to use (the decoder).

I get this when I run it:

$ ./v4l2-decode
Warning: driver is sending image at 640x480

Helen, vicodec has a minimum height of 480, and v4l2-codec.c tries to select
360, hence the difference. How did you test this? I think vicodec always had
480 as minimum height. I'm a bit surprised about this message.

> 
> I tried it on both kernel and modules 4.19.0-rc4+ compiled from 
> https://git.linuxtv.org/linux.git
> and kenel and modules 4.19.0-rc1+ compiled from 
> git://linuxtv.org/media_tree.git <http://linuxtv.org/media_tree.git>

Use the master branch of media_tree,git. You should see files named 
codec-fwht.c,
codec-v4l2-fwht.c and vicodec-core.c in drivers/media/platform/vicodec/.

> 
> Any idea what is the problem or how to investigate ?

You can use v4l2-ctl to check this. Try:

v4l2-ctl -d3 --list-formats

You should see this:

$ v4l2-ctl -d3 --list-formats
ioctl: VIDIOC_ENUM_FMT
Type: Video Capture

[0]: 'YU12' (Planar YUV 4:2:0)
[1]: 'YV12' (Planar YVU 4:2:0)
[2]: '422P' (Planar YUV 4:2:2)
[3]: 'NV12' (Y/CbCr 4:2:0)
[4]: 'NV21' (Y/CrCb 4:2:0)
[5]: 'NV16' (Y/CbCr 4:2:2)
[6]: 'NV61' (Y/CrCb 4:2:2)
[7]: 'NV24' (Y/CbCr 4:4:4)
[8]: 'NV42' (Y/CrCb 4:4:4)
[9]: 'YUYV' (YUYV 4:2:2)
[10]: 'YVYU' (YVYU 4:2:2)
[11]: 'UYVY' (UYVY 4:2:2)
[12]: 'VYUY' (VYUY 4:2:2)
[13]: 'BGR3' (24-bit BGR 8-8-8)
[14]: 'RGB3' (24-bit RGB 8-8-8)
[15]: 'HSV3' (24-bit HSV 8-8-8)
[16]: 'BGR4' (32-bit BGRA/X 8-8-8-8)
[17]: 'XR24' (32-bit BGRX 8-8-8-8)
[18]: 'RGB4' (32-bit A/XRGB 8-8-8-8)
[19]: 'BX24' (32-bit XRGB 8-8-8-8)
[20]: 'HSV4' (32-bit XHSV 8-8-8-8)

Note the presence of RGB3 (i.e. V4L2_PIX_FMT_RGB24).

BTW, for questions like this just mail to Helen and myself and don't include the
linux-media mailinglist in the future. It's not relevant for the list.

Regards,

Hans

> Thanks,
> 
> Dafna Hirschfeld
> 
> 

Problem with example program from https://gitlab.collabora.com/koike/v4l2-codec.git

[Dafna Hirschfeld]

Hi,
As part of applying to the outreachy program,
I compiled the code in https://gitlab.collabora.com/koike/v4l2-codec.git
I get errors running it.
When I install vicodec.ko I see in the kernel log:

[10752.727509] vicodec vicodec.0: Device registered as /dev/video2
[10752.727534] vicodec vicodec.0: Device registered as /dev/video3

I think /dev/video0, /dev/video1 are already used by uvcvideo

The dev file used in v4l2-decode.c is "/dev/video1"

When running the code as is, it prints:
"mmap: Invalid argument"

Changing the code of v4l2-decode.c to use "/dev/video0" prints:
"Driver didn't accept RGB24 format. Can't proceed."

Changing it to use "/dev/video2" prints:
"Driver didn't accept FWHT format. Can't proceed."

Changing it to use "/dev/video3" prints:
"Driver didn't accept RGB24 format. Can't proceed."

I tried it on both kernel and modules 4.19.0-rc4+ compiled from
https://git.linuxtv.org/linux.git
and kenel and modules 4.19.0-rc1+ compiled from git://linuxtv.org/media_tree.git

Any idea what is the problem or how to investigate ?
Thanks,

Dafna Hirschfeld

[Solved] Problem retrieving zl10353 information: Resource temporarily unavailable (but signal =71% ?)

[mjs]

Solved.
See msg130325.

Thanks,
  Marcel

Re: [PATCH] media: s5p-jpeg: Fix off-by-one problem

[Andrzej Pietrasiewicz]

W dniu 06.12.2017 o 17:37, Flavio Ceolin pisze:

s5p_jpeg_runtime_resume() does not call clk_disable_unprepare() for
jpeg->clocks[0] when one of the clk_prepare_enable() fails.

Found by Linux Driver Verification project (linuxtesting.org).

Signed-off-by: Flavio Ceolin 


Acked-by: Andrzej Pietrasiewicz 



---
  drivers/media/platform/s5p-jpeg/jpeg-core.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/media/platform/s5p-jpeg/jpeg-core.c 
b/drivers/media/platform/s5p-jpeg/jpeg-core.c
index faac816..79b63da 100644
--- a/drivers/media/platform/s5p-jpeg/jpeg-core.c
+++ b/drivers/media/platform/s5p-jpeg/jpeg-core.c
@@ -3086,7 +3086,7 @@ static int s5p_jpeg_runtime_resume(struct device *dev)
for (i = 0; i < jpeg->variant->num_clocks; i++) {
ret = clk_prepare_enable(jpeg->clocks[i]);
if (ret) {
-   while (--i > 0)
+   while (--i >= 0)
clk_disable_unprepare(jpeg->clocks[i]);
return ret;
}

[PATCH] media: s5p-jpeg: Fix off-by-one problem

[Flavio Ceolin]

s5p_jpeg_runtime_resume() does not call clk_disable_unprepare() for
jpeg->clocks[0] when one of the clk_prepare_enable() fails.

Found by Linux Driver Verification project (linuxtesting.org).

Signed-off-by: Flavio Ceolin 
---
 drivers/media/platform/s5p-jpeg/jpeg-core.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/media/platform/s5p-jpeg/jpeg-core.c 
b/drivers/media/platform/s5p-jpeg/jpeg-core.c
index faac816..79b63da 100644
--- a/drivers/media/platform/s5p-jpeg/jpeg-core.c
+++ b/drivers/media/platform/s5p-jpeg/jpeg-core.c
@@ -3086,7 +3086,7 @@ static int s5p_jpeg_runtime_resume(struct device *dev)
for (i = 0; i < jpeg->variant->num_clocks; i++) {
ret = clk_prepare_enable(jpeg->clocks[i]);
if (ret) {
-   while (--i > 0)
+   while (--i >= 0)
clk_disable_unprepare(jpeg->clocks[i]);
return ret;
}
-- 
2.9.5

Re: adv7281m and rcar-vin problem

[Niklas Söderlund]

Hi Naman,

On 2017-08-23 00:15:41 +0530, Naman Jain wrote:
> Hi Niklas,
> 
> adv7281m driver powers up the CSI transmitter in s_power(), which is
> called before setting up of D-PHY layer of R-Car CSI-2 Receiver.
> I shifted the part of code which enables CSI transmitter in adv7281m
> (Low Power state to High Speed state) to s_stream() -
> 
> if (state->chip_info->flags & ADV7180_FLAG_MIPI_CSI2) {
>if (on) {
> adv7180_csi_write(state, 0xDE, 0x02);
> adv7180_csi_write(state, 0xD2, 0xF7);
> adv7180_csi_write(state, 0xD8, 0x65);
> adv7180_csi_write(state, 0xE0, 0x09);
> adv7180_csi_write(state, 0x2C, 0x00);
>if (state->field == V4L2_FIELD_NONE)
>adv7180_csi_write(state, 0x1D, 0x80);
> adv7180_csi_write(state, 0x00, 0x00);
>  } else {
> adv7180_csi_write(state, 0x00, 0x80);
>   }
> }
> 
> After this change, i am not getting timeout of reading the phy clock
> lane and capture starts but nothing is displayed on the screen.

I know nothing about the adv7281m driver, but if you define DEBUG in the 
rcar-vin and rcar-csi2 drivers it will provide you with a lot more 
information about how they behave and maybe it can help you in your 
troubleshooting. If you enable this and send me a console log of what 
happens when you try to start a stream I can try and help you.

> 
> On Wed, Jul 26, 2017 at 2:08 PM, Niklas Söderlund
>  wrote:
> > Hi Naman,
> >
> > On 2017-07-24 22:43:06 +0530, Naman Jain wrote:
> >> On Mon, Jul 24, 2017 at 3:11 PM, Niklas Söderlund
> >>  wrote:
> >> > Hi Naman,
> >> >
> >> > On 2017-07-24 14:30:52 +0530, Naman Jain wrote:
> >> >> i am using renesas soc with video decoder adv7281m
> >> >> i have done thr device tree configuration by following dt bindings
> >> >> i am getting timeout of reading the phy clock lane, after i start 
> >> >> streaming
> >> >> and nothing is displayed on the screen
> >> >> kindly help me in configuration
> >> >
> >> > To be able to try and help you I would need a lot more information. For
> >> > starters:
> >> >
> >> > - Which kernel version are you using?
> >> >
> >> > - How dose the device tree nodes for VIN and ADV7281m look like?
> >> >
> >> > --
> >> > Regards,
> >> > Niklas Söderlund
> >>
> >> Hi Niklas,
> >>
> >> I am using kernel version  - 4.9
> >
> > The VIN driver which supports CSI-2 and the R-Car CSI-2 driver is not a
> > part of the upstream kernel yet, and the latest patches with contains
> > the most fixes are based on newer kernels then v4.9. So I assume you are
> > using a BSP of some sort, if possible could you tell me which one?
> >
> > If you want to try with later increments of the VIN and CSI-2 patches
> > please see:
> >
> > http://elinux.org/R-Car/Tests:rcar-vin
> >
> >
> 
> Soc version is rcar-h3 (r8a7795).
> Can tell me dependency patches required?

The dependencies are documented in the wiki page mentioned above, you 
can also use the latest renesas-drivers master branch

git://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-drivers.git

> 
> >>
> >> following is the device tree configuration :
> >>
> >>  {
> >> status = "okay";
> >> clock-frequency = <40>;
> >> adv7281m@21{
> >>compatible = "adi,adv7281-m";
> >>reg = <0x20>;
> >>interrupt-parent = <>;
> >>interrupts = <4 IRQ_TYPE_LEVEL_LOW>
> >>adv7281m_out: endpoint {
> >> clock-lanes = <0>;
> >> data-lanes = <1>;
> >> remote-endpoint = <_in>;
> >>  };
> >>};
> >>
> >> }
> >>
> >>  {
> >>   status = "okay";
> >>   ports {
> >>  #address-cells = <1>;
> >>  #size-cells = <0>;
> >>
> >>  port@0 {
> >> reg = <0>;
> >> csi20_in: endpoint {
> >>clock-lanes = <0>;
> >>data-lanes = <1>;
> >> 
> >> virtual-channel-number=<0>;
> >
> > This is interesting for me, I have not worked with any driver for the
> > R-Car CSI-2 driver which understands the virtual-channel-number
> > property.
> >
> >>remote-endpoint =
> >> <_out>;
> >> };
> >>};
> >> };
> >> };
> >>
> >>  {
> >> status = "okay";
> >> };
> >>
> >>  {
> >> status = "okay";
> >> };
> >>
> >>  {
> >> status = "okay";
> >> };
> >>
> >>  {
> >> status = "okay";
> >> };
> >>
> >>  {
> >> status = "okay";
> 

Re: adv7281m and rcar-vin problem

[Naman Jain]

Hi Niklas,

adv7281m driver powers up the CSI transmitter in s_power(), which is
called before setting up of D-PHY layer of R-Car CSI-2 Receiver.
I shifted the part of code which enables CSI transmitter in adv7281m
(Low Power state to High Speed state) to s_stream() -

if (state->chip_info->flags & ADV7180_FLAG_MIPI_CSI2) {
   if (on) {
adv7180_csi_write(state, 0xDE, 0x02);
adv7180_csi_write(state, 0xD2, 0xF7);
adv7180_csi_write(state, 0xD8, 0x65);
adv7180_csi_write(state, 0xE0, 0x09);
adv7180_csi_write(state, 0x2C, 0x00);
   if (state->field == V4L2_FIELD_NONE)
   adv7180_csi_write(state, 0x1D, 0x80);
adv7180_csi_write(state, 0x00, 0x00);
 } else {
adv7180_csi_write(state, 0x00, 0x80);
  }
}

After this change, i am not getting timeout of reading the phy clock
lane and capture starts but nothing is displayed on the screen.

On Wed, Jul 26, 2017 at 2:08 PM, Niklas Söderlund
 wrote:
> Hi Naman,
>
> On 2017-07-24 22:43:06 +0530, Naman Jain wrote:
>> On Mon, Jul 24, 2017 at 3:11 PM, Niklas Söderlund
>>  wrote:
>> > Hi Naman,
>> >
>> > On 2017-07-24 14:30:52 +0530, Naman Jain wrote:
>> >> i am using renesas soc with video decoder adv7281m
>> >> i have done thr device tree configuration by following dt bindings
>> >> i am getting timeout of reading the phy clock lane, after i start 
>> >> streaming
>> >> and nothing is displayed on the screen
>> >> kindly help me in configuration
>> >
>> > To be able to try and help you I would need a lot more information. For
>> > starters:
>> >
>> > - Which kernel version are you using?
>> >
>> > - How dose the device tree nodes for VIN and ADV7281m look like?
>> >
>> > --
>> > Regards,
>> > Niklas Söderlund
>>
>> Hi Niklas,
>>
>> I am using kernel version  - 4.9
>
> The VIN driver which supports CSI-2 and the R-Car CSI-2 driver is not a
> part of the upstream kernel yet, and the latest patches with contains
> the most fixes are based on newer kernels then v4.9. So I assume you are
> using a BSP of some sort, if possible could you tell me which one?
>
> If you want to try with later increments of the VIN and CSI-2 patches
> please see:
>
> http://elinux.org/R-Car/Tests:rcar-vin
>
>

Soc version is rcar-h3 (r8a7795).
Can tell me dependency patches required?

>>
>> following is the device tree configuration :
>>
>>  {
>> status = "okay";
>> clock-frequency = <40>;
>> adv7281m@21{
>>compatible = "adi,adv7281-m";
>>reg = <0x20>;
>>interrupt-parent = <>;
>>interrupts = <4 IRQ_TYPE_LEVEL_LOW>
>>adv7281m_out: endpoint {
>> clock-lanes = <0>;
>> data-lanes = <1>;
>> remote-endpoint = <_in>;
>>  };
>>};
>>
>> }
>>
>>  {
>>   status = "okay";
>>   ports {
>>  #address-cells = <1>;
>>  #size-cells = <0>;
>>
>>  port@0 {
>> reg = <0>;
>> csi20_in: endpoint {
>>clock-lanes = <0>;
>>data-lanes = <1>;
>> 
>> virtual-channel-number=<0>;
>
> This is interesting for me, I have not worked with any driver for the
> R-Car CSI-2 driver which understands the virtual-channel-number
> property.
>
>>remote-endpoint =
>> <_out>;
>> };
>>};
>> };
>> };
>>
>>  {
>> status = "okay";
>> };
>>
>>  {
>> status = "okay";
>> };
>>
>>  {
>> status = "okay";
>> };
>>
>>  {
>> status = "okay";
>> };
>>
>>  {
>> status = "okay";
>> };
>>
>>  {
>> status = "okay";
>> };
>>
>>  {
>> status = "okay";
>> };
>>
>>  {
>> status = "okay";
>> };
>
> --
> Regards,
> Niklas Söderlund

Re: adv7281m and rcar-vin problem

[Niklas Söderlund]

Hi Naman,

On 2017-07-24 22:43:06 +0530, Naman Jain wrote:
> On Mon, Jul 24, 2017 at 3:11 PM, Niklas Söderlund
>  wrote:
> > Hi Naman,
> >
> > On 2017-07-24 14:30:52 +0530, Naman Jain wrote:
> >> i am using renesas soc with video decoder adv7281m
> >> i have done thr device tree configuration by following dt bindings
> >> i am getting timeout of reading the phy clock lane, after i start streaming
> >> and nothing is displayed on the screen
> >> kindly help me in configuration
> >
> > To be able to try and help you I would need a lot more information. For
> > starters:
> >
> > - Which kernel version are you using?
> >
> > - How dose the device tree nodes for VIN and ADV7281m look like?
> >
> > --
> > Regards,
> > Niklas Söderlund
> 
> Hi Niklas,
> 
> I am using kernel version  - 4.9

The VIN driver which supports CSI-2 and the R-Car CSI-2 driver is not a 
part of the upstream kernel yet, and the latest patches with contains 
the most fixes are based on newer kernels then v4.9. So I assume you are 
using a BSP of some sort, if possible could you tell me which one?

If you want to try with later increments of the VIN and CSI-2 patches 
please see:

http://elinux.org/R-Car/Tests:rcar-vin


> 
> following is the device tree configuration :
> 
>  {
> status = "okay";
> clock-frequency = <40>;
> adv7281m@21{
>compatible = "adi,adv7281-m";
>reg = <0x20>;
>interrupt-parent = <>;
>interrupts = <4 IRQ_TYPE_LEVEL_LOW>
>adv7281m_out: endpoint {
> clock-lanes = <0>;
> data-lanes = <1>;
> remote-endpoint = <_in>;
>  };
>};
> 
> }
> 
>  {
>   status = "okay";
>   ports {
>  #address-cells = <1>;
>  #size-cells = <0>;
> 
>  port@0 {
> reg = <0>;
> csi20_in: endpoint {
>clock-lanes = <0>;
>data-lanes = <1>;
> 
> virtual-channel-number=<0>;

This is interesting for me, I have not worked with any driver for the 
R-Car CSI-2 driver which understands the virtual-channel-number 
property.

>remote-endpoint =
> <_out>;
> };
>};
> };
> };
> 
>  {
> status = "okay";
> };
> 
>  {
> status = "okay";
> };
> 
>  {
> status = "okay";
> };
> 
>  {
> status = "okay";
> };
> 
>  {
> status = "okay";
> };
> 
>  {
> status = "okay";
> };
> 
>  {
> status = "okay";
> };
> 
>  {
> status = "okay";
> };

-- 
Regards,
Niklas Söderlund

Re: adv7281m and rcar-vin problem

[Naman Jain]

On Mon, Jul 24, 2017 at 3:11 PM, Niklas Söderlund
 wrote:
> Hi Naman,
>
> On 2017-07-24 14:30:52 +0530, Naman Jain wrote:
>> i am using renesas soc with video decoder adv7281m
>> i have done thr device tree configuration by following dt bindings
>> i am getting timeout of reading the phy clock lane, after i start streaming
>> and nothing is displayed on the screen
>> kindly help me in configuration
>
> To be able to try and help you I would need a lot more information. For
> starters:
>
> - Which kernel version are you using?
>
> - How dose the device tree nodes for VIN and ADV7281m look like?
>
> --
> Regards,
> Niklas Söderlund

Hi Niklas,

I am using kernel version  - 4.9

following is the device tree configuration :

 {
status = "okay";
clock-frequency = <40>;
adv7281m@21{
   compatible = "adi,adv7281-m";
   reg = <0x20>;
   interrupt-parent = <>;
   interrupts = <4 IRQ_TYPE_LEVEL_LOW>
   adv7281m_out: endpoint {
clock-lanes = <0>;
data-lanes = <1>;
remote-endpoint = <_in>;
 };
   };

}

 {
  status = "okay";
  ports {
 #address-cells = <1>;
 #size-cells = <0>;

 port@0 {
reg = <0>;
csi20_in: endpoint {
   clock-lanes = <0>;
   data-lanes = <1>;
virtual-channel-number=<0>;
   remote-endpoint =
<_out>;
};
   };
};
};

 {
status = "okay";
};

 {
status = "okay";
};

 {
status = "okay";
};

 {
status = "okay";
};

 {
status = "okay";
};

 {
status = "okay";
};

 {
status = "okay";
};

 {
status = "okay";
};

Re: adv7281m and rcar-vin problem

[Niklas Söderlund]

Hi Naman,

On 2017-07-24 14:30:52 +0530, Naman Jain wrote:
> i am using renesas soc with video decoder adv7281m
> i have done thr device tree configuration by following dt bindings
> i am getting timeout of reading the phy clock lane, after i start streaming
> and nothing is displayed on the screen
> kindly help me in configuration

To be able to try and help you I would need a lot more information. For 
starters:

- Which kernel version are you using?

- How dose the device tree nodes for VIN and ADV7281m look like?

-- 
Regards,
Niklas Söderlund

Adv7180 driver configuration problem

[Naman Jain]

I need to configure adv7281m in renesas SOC which uses rcar-csi as
bridge(csi receiver) and rcar- vin as dma engine.

I have done the configuration in device tree as mention in DT bindings.

When i start the streaming (continuous capture), i am getting

rcar.csi2: timeout reading the PHY clock lane

further probing the data lanes on adv7281m, i am seeing incorrect
voltages in HS mode.

Problem using libdvbv5

[Russel Winder]

I am having some issues with dvb_scan_transponder in the Debian Sid
distribution of libdvbv5. I am sure the arguments I am giving it are
fine, but a function called within dvb_scan_transponder is causing a
SIGSEGV. The Debian Sid package appears to be only of a production
version, there is no debug symbols and/or package.

I am guessing that the official line is to build from source to create
a debugging shared object. I have cloned the V4L_Utils Git repository
from https://git.linuxtv.org/v4l-utils.git 

What is the official sequence to get a build of libdvbv5.so and what
extra arguments are needed to get a version with all debug symbols in
place?
 
-- 
Russel.
=
Dr Russel Winder  t: +44 20 7585 2200   voip: sip:russel.win...@ekiga.net
41 Buckmaster Roadm: +44 7770 465 077   xmpp: rus...@winder.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder

signature.asc
Description: This is a digitally signed message part

Re: [PATCH] media: fix one code style problem

[Greg Kroah-Hartman]

On Fri, May 05, 2017 at 01:18:24PM -0700, Remco wrote:
> From: Remco Verhoef <re...@dutchcoders.io>
> 
> this patch will fix one code style problem (ctx:WxE), space
> prohibited before that

Your subject needs work :)

And why just one issue, is that the only place this type of problem is
needed in this file?

thanks,

greg k-h

[PATCH] staging: media: fix one code style problem

[Remco Verhoef]

this patch will fix one code style problem (ctx:WxE), space
prohibited before that

Signed-off-by: Remco Verhoef <re...@dutchcoders.io>
---
 .../staging/media/atomisp/platform/intel-mid/atomisp_gmin_platform.c| 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git 
a/drivers/staging/media/atomisp/platform/intel-mid/atomisp_gmin_platform.c 
b/drivers/staging/media/atomisp/platform/intel-mid/atomisp_gmin_platform.c
index 5b4506a..b0f9188 100644
--- a/drivers/staging/media/atomisp/platform/intel-mid/atomisp_gmin_platform.c
+++ b/drivers/staging/media/atomisp/platform/intel-mid/atomisp_gmin_platform.c
@@ -51,7 +51,7 @@ struct gmin_subdev {
 
 static struct gmin_subdev gmin_subdevs[MAX_SUBDEVS];
 
-static enum { PMIC_UNSET = 0, PMIC_REGULATOR, PMIC_AXP, PMIC_TI ,
+static enum { PMIC_UNSET = 0, PMIC_REGULATOR, PMIC_AXP, PMIC_TI,
PMIC_CRYSTALCOVE } pmic_id;
 
 /* The atomisp uses type==0 for the end-of-list marker, so leave space. */
-- 
1.9.1

[PATCH] media: fix one code style problem

[Remco]

From: Remco Verhoef <re...@dutchcoders.io>

this patch will fix one code style problem (ctx:WxE), space
prohibited before that

Signed-off-by: Remco Verhoef <re...@dutchcoders.io>
---
 .../staging/media/atomisp/platform/intel-mid/atomisp_gmin_platform.c| 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git 
a/drivers/staging/media/atomisp/platform/intel-mid/atomisp_gmin_platform.c 
b/drivers/staging/media/atomisp/platform/intel-mid/atomisp_gmin_platform.c
index 5b4506a..b0f9188 100644
--- a/drivers/staging/media/atomisp/platform/intel-mid/atomisp_gmin_platform.c
+++ b/drivers/staging/media/atomisp/platform/intel-mid/atomisp_gmin_platform.c
@@ -51,7 +51,7 @@ struct gmin_subdev {
 
 static struct gmin_subdev gmin_subdevs[MAX_SUBDEVS];
 
-static enum { PMIC_UNSET = 0, PMIC_REGULATOR, PMIC_AXP, PMIC_TI ,
+static enum { PMIC_UNSET = 0, PMIC_REGULATOR, PMIC_AXP, PMIC_TI,
PMIC_CRYSTALCOVE } pmic_id;
 
 /* The atomisp uses type==0 for the end-of-list marker, so leave space. */
-- 
1.9.1

Unknown symbol problem; em28xx (WinTV-soloHD)

[Klaus Eicheler]

Hi all,

compiling media_build on my openSUSE 13.1 machine worked without errors, but
issued some warnings, finally leading to (dmesg):

[97792.189678] usb 2-1.6: new high-speed USB device number 10 using ehci-pci
[97792.276140] usb 2-1.6: New USB device found, idVendor=2040,
idProduct=0264
[97792.276147] usb 2-1.6: New USB device strings: Mfr=3, Product=1,
SerialNumber=2
[97792.276151] usb 2-1.6: Product: soloHD
[97792.276154] usb 2-1.6: Manufacturer: HCW
[97792.276157] usb 2-1.6: SerialNumber: 0013813833
[97792.445273] em28xx: Unknown symbol v4l2_clk_unregister_fixed (err 0)
[97792.445319] em28xx: Unknown symbol __v4l2_clk_register_fixed (err 0)

The DVB stick seems to be well recognized (-> em28xx). The only reference to
v4l2_clk_unregister_fixed I could find was inside em28xx-camera.c.

modprobe em28xx yields the same results.

Do you have any hints how to solve the problem?

Cheers
Mit freundlichen Grüßen
Klaus Eicheler

Re: Problem: saa7113 (saa7115) vs. "conrad usb grabber usb-472"

[Bodo Eggert]

On Tue, 21 Feb 2017, Devin Heitmueller wrote:

> > lsusb:
> > Bus 003 Device 002: ID 0573:0400 Zoran Co. Personal Media Division 
> > (Nogatech) D-Link V100
> 
> The Zoran usbvision driver has been a mess for years, and it's not
> going to get better anytime soon.  It's a *really* old design and
> there hasn't been any interest from any of the developers to work on
> it.
> 
> In this particular case, you're probably way better off just throwing
> it away and buying a new $25 capture device.

Thanks.

Re: Problem: saa7113 (saa7115) vs. "conrad usb grabber usb-472"

[Devin Heitmueller]

> lsusb:
> Bus 003 Device 002: ID 0573:0400 Zoran Co. Personal Media Division (Nogatech) 
> D-Link V100

The Zoran usbvision driver has been a mess for years, and it's not
going to get better anytime soon.  It's a *really* old design and
there hasn't been any interest from any of the developers to work on
it.

In this particular case, you're probably way better off just throwing
it away and buying a new $25 capture device.

Devin

-- 
Devin J. Heitmueller - Kernel Labs
http://www.kernellabs.com

Problem: saa7113 (saa7115) vs. "conrad usb grabber usb-472"

[Bodo Eggert]

System: Debian Jessie x64. (Using qv4l2).

I've got a USB video grabber called "conrad usb grabber usb-472", 
essentially it's a no-name-branding. It's recognized as saa7113 by the 
saa7115 driver.

The device has one video input (chinch, yellow) and a stereo input (red 
and white). The driver does recognize three video inputs 
(green/yellow/red), neither of them works: No frame recognized. I verified 
the camera to supply a correct signal.

Trying to use MMIO, qv4l2 will hang and needs to be killed.
Trying to use read(), I get a black screen.

(Sorry if this isn't the correct list.

I'm OK with just throwing the thing away, but if fixing it is an option, 
I'll help.)

uname -a
Linux be10 3.16.0-4-amd64 #1 SMP Debian 3.16.39-1 (2016-12-30) x86_64 
GNU/Linux


lsusb:
Bus 003 Device 002: ID 0573:0400 Zoran Co. Personal Media Division (Nogatech) 
D-Link V100

dmesg:
[ 7518.194350] usb 3-2: new full-speed USB device number 2 using ohci-pci
[ 7518.371408] usb 3-2: New USB device found, idVendor=0573, idProduct=0400
[ 7518.371420] usb 3-2: New USB device strings: Mfr=0, Product=0, SerialNumber=0
[ 7519.217042] usbvision_probe: D-Link V100 found
[ 7519.217461] USBVision[0]: registered USBVision Video device video1 [v4l2]
[ 7519.217505] usbcore: registered new interface driver usbvision
[ 7519.217507] USBVision USB Video Device Driver for Linux : 0.9.11
[ 7519.902857] saa7115 5-0025: saa7113 found @ 0x4a (usbvision-3-2)

Re: Problem with Hauppauge WinTV-HVR-1250

[Justin Husted]

On Sat, Jan 14, 2017 at 8:01 AM, Michael Ira Krufky <mkru...@linuxtv.org> wrote:
>
> On Fri, Jan 13, 2017 at 11:56 PM, Justin Husted <valenti...@gmail.com> wrote:
> > Hi!
> >
> > I recently got one of these cards on ebay to do some analog video capturing,
> > and I'm having a few problems with it on the 4.4.0 kernel.
> >
> > I wasn't really sure who the maintainer is for this stuff, but I saw your
> > name in the Linux MAINTAINERS file for the tda18271, which seems to be one
> > of the relevant drivers. :-)
> >
> > Are you the person to talk to, or do you know who is?
>
> Justin,
>
> Better to email the linux-media mailing list on kernel.org with this
> type of question (cc added)

Ok, thanks!

> What is the problem that you're having in the 4.4.0 kernel?

There are two fundamental problems. Note that I'm just attempting to
use this card as an analog video capture card, using the RCA plug.

== Sleep / Reference Leak ==

The first problem is less important, but is clearly annoying: the card
does not work after sleep/resume, and I can't try the typical approach
of adding a special module unload/reload rule because it appears to
have a reference leak.

I'm seeing that there is (usually) one reference to cx25840 and
cx23885 at all times, plus extra references if a capture is actually
going on. However, it is also somewhat unreliable, so occasionally
there isn't a reference to the driver and I'm able to unload/reload it
(but it still doesn't work).

== Interlaced Video Capture ==

The second problem is the more important one: It seems like the
interlaced video capture I'm receiving via various tools has something
wrong with it. I'm not sure precisely how to characterize this.

Basically, what I first noticed was that after deinterlacing, it
looked as if each pair of lines in the output was reversed, leading to
an extremely vertically pixelated result. I attempted to investigate,
and basically what I'm seeing is that the interlaced video frames
(720x480 @ 29.97 fps) appear as if they're in an inverted pattern in
the output, like 214365

Ok! I think, maybe they're in bff rather than tff format. I then
attempted to change my capture settings (I've been using vlc, ffmpeg,
mplayer, and cheese to try to debug), and found that occasionally this
seemed to help, but it would invariably not work reliably.

I then attempted capturing with a variety of different deinterlacing
schemes. I found with a bob deinterlacer that it seemed like the video
would switch modes, jumping every few seconds up and down a little.

The next thing I tried was to extract the interlaced fields and
produce a 59.94 hz stream, so I could frame by frame it. What was most
notable about this was that it seemed like in high-motion scenes, the
motion would actually jump backwards in time by a few frames, instead
of the fields each showing an A-B-C-D-E-F or B-A-D-C-F-E pattern like
I expected.

So, basically, it seemed to me almost like this driver is mis-managing
its video buffers. I don't know how the internal hardware interface
works (I mean seriously, I wasn't even sure which driver programs the
analog video chip...), so I wasn't sure if it was plausible that
perhaps the driver is reading the video stream one field at a time and
then composing them in the wrong order or something crazy like that.

Regardless, the card doesn't really seem to be usable for NTSC video
capture with this driver.

> Which is the most recent kernel that works for you correctly?

I just picked up this card recently (I need to transfer old video
tape), and haven't tried it with any other kernel series. I did check
the kernel changelog to see if there had been commits recently to the
cx23885 or cx25840 drivers, and didn't see anything relevant.

> Do you have logs that illustrate your problem?

I've attached the result of lsmod, showing the refcounts. I'm not
really sure what the most useful data regarding the actual video
capture problem is.

Alternatively, do you know a good reliable PCIe or USB analog video
capture card that produces good results? It's seemed quite difficult
to find something these days given that it's basically a dead
technology... (and for the low end USB cards, we seem to be in
counterfeit hell).

Thanks,
Justin


hauppage_lsmod_pre2
Description: Binary data

Re: Problem with Hauppauge WinTV-HVR-1250

[Michael Ira Krufky]

On Fri, Jan 13, 2017 at 11:56 PM, Justin Husted <valenti...@gmail.com> wrote:
> Hi!
>
> I recently got one of these cards on ebay to do some analog video capturing,
> and I'm having a few problems with it on the 4.4.0 kernel.
>
> I wasn't really sure who the maintainer is for this stuff, but I saw your
> name in the Linux MAINTAINERS file for the tda18271, which seems to be one
> of the relevant drivers. :-)
>
> Are you the person to talk to, or do you know who is?
>
> Thanks!
> -Justin
>


Justin,

Better to email the linux-media mailing list on kernel.org with this
type of question (cc added)

What is the problem that you're having in the 4.4.0 kernel?

Which is the most recent kernel that works for you correctly?

Do you have logs that illustrate your problem?

Best regards,

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

Re: Problem with uvcvideo timestamps

[Laurent Pinchart]

Hi Niels,

On Monday 31 Oct 2016 14:42:54 Niels Möller wrote:
> Hi,
> 
> I'm tracking down a problem in Chrome, where video streams captured
> from a Logitech c930e camera get bogus timestamps. Chrome started
> using camera timestamps on linux a few months ago. I've noted commit
> 
>  
> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=
> 5d0fd3c806b9e932010931ae67dbb482020e0882
> 
>   "[media] uvcvideo: Disable hardware timestamps by default"
> 
> but I'm running with a kernel which doesn't have that change.
> 
> First, let me say that for our purposes, the hairy syncing to the
> "SOF" clock done by uvc_video_clock_update is not that useful.
> Ideally, I would prefer if the v4l2_buffer of a captured frame
> included both
> 
>   * untranslated pts timestamp from the camera device (if I've
> understood this correctly, and there is a pts sent over the wire),

There's a PTS sent over the wire, yes.

> and
> 
>   * the value of system monotonic clock at the point when the frame
> was received by the kernel.
> 
> Is there any reasonable way to get this information out from the
> driver?

The system monotonic clock timestamp is what the driver provides (with the 
above patch at least). We however have no field in the v4l2_buffer structure 
at the moment to provide the PTS.

> We could then do estimation of the camera's epoch and clock drift in the
> application.

Unless I'm mistaken, you can only do that if you get the SCR/PTS values in 
your application, and they're currently not provided. How do you plan to solve 
that ?

> The raw pts is the most important piece of information.

What do you want to use it for by the way ?

> Second, I'd like to try to provide some logs to help track down the
> bug. To reproduce, I'm using the example program at
> https://gist.github.com/maxlapshin/1253534, modified to print out
> camera timestamp and gettimeofday for each frame. Log attached as
> time-2.log.

Thank you. I have a device I can use to reproduce the problem, but haven't had 
time to fix it yet :-/ Performing the timestamp translation in userspace would 
allow for more precise calculation, so I'm not advocating for a kernel-only 
solution. However, I don't want every application to implement timestamp 
translation. A common implementation in libv4l2 could be a good solution.

> I also enabled tracing of the clock translation logic using
> 
>   echo 4096 > /sys/module/uvcvideo/parameters/trace
> 
> The corresponding kernel log messages are attached as trace-2.log.
> 
> In time-2.log (i.e., the application log), I see that camera
> timestamps move backwards in time,
> 
>   TIMESTAMP_MONOTONIC
>  cam: 2321521.085372
>  sys: 1477913910.983620
>   TIMESTAMP_MONOTONIC
>  cam: 2321520.879272
>  sys: 1477913911.051628
> 
> In trace-2.log (i.e., kernel log messages) I see
> 
>   uvcvideo: Logitech Webcam C930e: PTS 219483992 y 4084.798004 SOF
> 4084.798004 (x1 2064310082 x2 2148397132 y1 218759168 y2 268238848 SOF
> offset 170)
>   uvcvideo: Logitech Webcam C930e: SOF 4084.798004 y 3105900702 ts
> 2321520.879272 buf ts 2321521.153372 (x1 218759168/1546/1290 x2
> 274071552/1878/2045 y1 10 y2 3380001263)
>   uvcvideo: Logitech Webcam C930e: PTS 221480532 y 4156.709564 SOF
> 4156.709564 (x1 2079524156 x2 2148397450 y1 256376832 y2 272629760 SOF
> offset 170)
>   uvcvideo: Logitech Webcam C930e: SOF 4156.709564 y 2453257742 ts
> 2321520.378627 buf ts 2321521.217373 (x1 262275072/1698/1864 x2
> 278265856/1942/64 y1 10 y2 3292003672)
>   uvcvideo: Logitech Webcam C930e: PTS 223477044 y 4223.428085 SOF
> 4223.428085 (x1 2081269216 x2 2148397122 y1 264568832 y2 276955136 SOF
> offset 170)
>   uvcvideo: Logitech Webcam C930e: SOF 2175.428085 y 2158773894 ts
> 2321520.208143 buf ts 2321521.285373 (x1 136183808/1822/1989 x2
> 148504576/2010/130 y1 10 y2 3236003012)
> 
> I don't know the details of the usb protocol, but it looks like the
> "SOF" value is usually increasing. But close to the bogus output
> timestamp of 2321520.879272, it goes through some kind of wraparound,
> with the sequence of values
> 
>   4156.709564
>   4223.428085
>   2175.428085# 2048 less than previous value
>   2243.169921
> 
> I hope the attached logs provide enough information to analyze where
> uvc_video_clock_update gets this wrong.

-- 
Regards,

Laurent Pinchart

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

Problem: "transfer buffer not dma capable"

[bill murphy]

On Dec 17th Piotr Chmura reported an oops when trying to watch tv with 
his siano device, which uses smsusb, in Kaffeine.


I was recently seeing a very similar oops with Linux 4.9.0-rc6+, but 
upon plugging in a Geniatech SU3 device (vid,pid / 0x1f4d,0x3000)


which uses dw2102. Compiling the 4.9.0-rc6+ kernel with this config 
setting disabled for now, as suggested here


https://github.com/LibreELEC/LibreELEC.tv/pull/1076 got rid of the oops 
for me, and the Geniatech device no longer experiences the


"transfer buffer not dma capable" oops. http://pastebin.com/JWdHUDac

Hope that helps someone else as it helped me.



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

PROBLEM: siano "transfer buffer not dma capable" when trying to capture video in 4.9.0

[Piotr Chmura]

siano "transfer buffer not dma capable" when trying to capture video

On kernel 4.9.0 when trying to watch TV (in Kaffeine 1.0.5, libVLC) i 
get Oops instead of audio/video stream.

Kernel 4.8.X series works fine (currently using 4.8.13).

[   60.268359] [ cut here ]
[   60.268366] WARNING: CPU: 1 PID: 3558 at drivers/usb/core/hcd.c:1584 
usb_hcd_map_urb_for_dma+0x249/0x2f9

[   60.268366] transfer buffer not dma capable
[   60.268367] Modules linked in: nfsv3 nfs_acl auth_rpcgss oid_registry 
nfsv4 dns_resolver nfs lockd grace fscache sunrpc snd_usb_audio 
snd_usbmidi_lib snd_rawmidi gspca_zc3xx gspca_main v4l2_common videodev 
cdc_acm joydev btusb btrtl btbcm btintel bluetooth smsdvb dvb_core 
smsusb smsmdtv media usb_storage nvidia_modeset(PO) nvidia(PO) 
x86_pkg_temp_thermal drm xhci_pci xhci_hcd ehci_pci ehci_hcd 8250 
8250_base serial_core
[   60.268389] CPU: 1 PID: 3558 Comm: kdvb-ad-1-fe-0 Tainted: 
P   O4.9.0 #1
[   60.268390] Hardware name: Gigabyte Technology Co., Ltd. To be filled 
by O.E.M./Z77N-WIFI, BIOS F4a 07/29/2013
[   60.268391]   811e7617 c90008a83830 

[   60.268393]  8103a5a7 8803dca48780 c90008a83888 
0001
[   60.268395]   88040bed4780 c90008a83a58 
8103a606

[   60.268397] Call Trace:
[   60.268401]  [] ? dump_stack+0x46/0x59
[   60.268404]  [] ? __warn+0xc8/0xe1
[   60.268406]  [] ? warn_slowpath_fmt+0x46/0x4e
[   60.268408]  [] ? usb_hcd_map_urb_for_dma+0x249/0x2f9
[   60.268409]  [] ? usb_hcd_submit_urb+0x627/0x6f0
[   60.268412]  [] ? usb_start_wait_urb+0x54/0xc5
[   60.268415]  [] ? smsusb_sendrequest+0x4c/0x58 [smsusb]
[   60.268417]  [] ? 
smsdvb_sendrequest_and_wait.isra.4+0x9/0x29 [smsdvb]
[   60.268419]  [] ? smsdvb_set_frontend+0x2b9/0x2c9 
[smsdvb]
[   60.268422]  [] ? 
dvb_frontend_swzigzag_autotune+0x160/0x1b2 [dvb_core]
[   60.268426]  [] ? dvb_frontend_swzigzag+0x1ef/0x25a 
[dvb_core]

[   60.268428]  [] ? update_load_avg+0x25a/0x293
[   60.268429]  [] ? update_load_avg+0x25a/0x293
[   60.268431]  [] ? 
get_sd_balance_interval.isra.55+0x13/0x2e

[   60.268433]  [] ? update_next_balance+0x15/0x26
[   60.268435]  [] ? vtime_account_idle+0x5/0xd
[   60.268437]  [] ? vtime_common_task_switch+0x12/0x1f
[   60.268438]  [] ? finish_task_switch+0x130/0x19e
[   60.268440]  [] ? lock_timer_base+0x33/0x57
[   60.268442]  [] ? try_to_del_timer_sync+0x3f/0x49
[   60.268443]  [] ? del_timer_sync+0x20/0x3d
[   60.268446]  [] ? schedule_timeout+0xad/0xd0
[   60.268447]  [] ? del_timer_sync+0x3d/0x3d
[   60.268449]  [] ? dvb_frontend_thread+0x3fd/0x4bd 
[dvb_core]

[   60.268452]  [] ? wake_up_atomic_t+0x21/0x21
[   60.268454]  [] ? dtv_set_frontend+0x325/0x325 
[dvb_core]

[   60.268456]  [] ? kthread+0x96/0x9e
[   60.268457]  [] ? init_completion+0x1d/0x1d
[   60.268460]  [] ? ret_from_fork+0x22/0x30
[   60.268472] ---[ end trace f08e58646fa0507a ]---


System info:
$ ./ver_linux
Linux darkstar 4.9.0 #1 SMP PREEMPT Sat Dec 17 17:45:05 CET 2016 x86_64 
Intel(R) Core(TM) i5-2500K CPU @ 3.30GHz GenuineIntel GNU/Linux


GNU C   5.4.0
GNU Make4.1
Binutils2.27
Util-linux  2.29
Mount   2.29
Linux C Library 2.23
Dynamic linker (ldd)2.23
Procps  3.3.12
Net-tools   1.60
Kbd 2.0.3
Console-tools   2.0.3
Sh-utils8.25
Udev232
Modules Loaded  8250 8250_base auth_rpcgss bluetooth btbcm 
btintel btrtl btusb cdc_acm dns_resolver drm dvb_core ehci_hcd ehci_pci 
fscache grace gspca_main gspca_zc3xx joydev lockd media nfs nfs_acl 
nfsv3 nfsv4 nvidia nvidia_modeset oid_registry serial_core smsdvb 
smsmdtv smsusb snd_rawmidi snd_usb_audio snd_usbmidi_lib sunrpc 
usb_storage v4l2_common videodev x86_pkg_temp_thermal xhci_hcd xhci_pci



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

Re: Problem with uvcvideo timestamps

[Guennadi Liakhovetski]

Hi Niels,

Sorry for a late reply.

On Mon, 31 Oct 2016, Niels Möller wrote:

> Hi,
> 
> I'm tracking down a problem in Chrome, where video streams captured
> from a Logitech c930e camera get bogus timestamps. Chrome started
> using camera timestamps on linux a few months ago. I've noted commit
> 
>   
> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=5d0fd3c806b9e932010931ae67dbb482020e0882
> 
>   "[media] uvcvideo: Disable hardware timestamps by default"
> 
> but I'm running with a kernel which doesn't have that change.
> 
> First, let me say that for our purposes, the hairy syncing to the
> "SOF" clock done by uvc_video_clock_update is not that useful.
> Ideally, I would prefer if the v4l2_buffer of a captured frame
> included both
> 
>   * untranslated pts timestamp from the camera device (if I've
> understood this correctly, and there is a pts sent over the wire),
> and
> 
>   * the value of system monotonic clock at the point when the frame
> was received by the kernel.
> 
> Is there any reasonable way to get this information out from the
> driver? We could then do estimation of the camera's epoch and clock
> drift in the application. The raw pts is the most important piece of
> information.

I think these patches can help you;

http://www.mail-archive.com/linux-media@vger.kernel.org/msg106077.html

Note, that they require an additional patch from Laurent:

https://patchwork.linuxtv.org/patch/36810/

Thanks
Guennadi

> 
> Second, I'd like to try to provide some logs to help track down the
> bug. To reproduce, I'm using the example program at
> https://gist.github.com/maxlapshin/1253534, modified to print out
> camera timestamp and gettimeofday for each frame. Log attached as
> time-2.log.
> 
> I also enabled tracing of the clock translation logic using
> 
>   echo 4096 > /sys/module/uvcvideo/parameters/trace
> 
> The corresponding kernel log messages are attached as trace-2.log.
> 
> In time-2.log (i.e., the application log), I see that camera
> timestamps move backwards in time,
> 
>   TIMESTAMP_MONOTONIC
>  cam: 2321521.085372
>  sys: 1477913910.983620
>   TIMESTAMP_MONOTONIC
>  cam: 2321520.879272
>  sys: 1477913911.051628
> 
> In trace-2.log (i.e., kernel log messages) I see
> 
>   uvcvideo: Logitech Webcam C930e: PTS 219483992 y 4084.798004 SOF
> 4084.798004 (x1 2064310082 x2 2148397132 y1 218759168 y2 268238848 SOF
> offset 170)
>   uvcvideo: Logitech Webcam C930e: SOF 4084.798004 y 3105900702 ts
> 2321520.879272 buf ts 2321521.153372 (x1 218759168/1546/1290 x2
> 274071552/1878/2045 y1 10 y2 3380001263)
>   uvcvideo: Logitech Webcam C930e: PTS 221480532 y 4156.709564 SOF
> 4156.709564 (x1 2079524156 x2 2148397450 y1 256376832 y2 272629760 SOF
> offset 170)
>   uvcvideo: Logitech Webcam C930e: SOF 4156.709564 y 2453257742 ts
> 2321520.378627 buf ts 2321521.217373 (x1 262275072/1698/1864 x2
> 278265856/1942/64 y1 10 y2 3292003672)
>   uvcvideo: Logitech Webcam C930e: PTS 223477044 y 4223.428085 SOF
> 4223.428085 (x1 2081269216 x2 2148397122 y1 264568832 y2 276955136 SOF
> offset 170)
>   uvcvideo: Logitech Webcam C930e: SOF 2175.428085 y 2158773894 ts
> 2321520.208143 buf ts 2321521.285373 (x1 136183808/1822/1989 x2
> 148504576/2010/130 y1 10 y2 3236003012)
> 
> I don't know the details of the usb protocol, but it looks like the
> "SOF" value is usually increasing. But close to the bogus output
> timestamp of 2321520.879272, it goes through some kind of wraparound,
> with the sequence of values
> 
>   4156.709564
>   4223.428085
>   2175.428085# 2048 less than previous value
>   2243.169921
> 
> I hope the attached logs provide enough information to analyze where
> uvc_video_clock_update gets this wrong.
> 
> Best regards,
> /Niels Möller
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Problem with media_build install

[Mauro Carvalho Chehab]

Em Fri, 25 Nov 2016 20:02:57 +1100
Vincent McIntyre  escreveu:

> Hi list,
> 
> I sent a patch for this issue, could someone take a look?
> 
> http://www.mail-archive.com/linux-media@vger.kernel.org/msg105340.html

Patch applied. Next time, please add your Signed-off-by:


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

Re: Problem with media_build install

[Vincent McIntyre]

Hi list,

I sent a patch for this issue, could someone take a look?

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

Problem with media_build install

[Jose Alberto Reguero]

#make install
make -C /usr/src/media_build/v4l install
make[1]: Entering directory '/usr/src/media_build/v4l'
make[1]: *** No rule to make target 'mm-install' needed by 'install'. Alto.
make[1]: Leaving directory '/usr/src/media_build/v4l'
Makefile:15: recipe for target 'install' failed
make: *** [install] Error 2

Jose Alberto

Problem retrieving zl10353 information: Resource temporarily unavailable (but signal =71% ?)

[mjs]

Hello,

I'm trying to get a dvb-t usb-stick to work with debian.

 Components: em2882 - xc3028l (uses XC3028L-V36.fw) - ce6353 (zl10353) - 
tvp5150 - emp202
 Kernel: 4.7.0-0.bpo.1-686-pae - debian 8
 i2c device: eeprom @ 0xa0 - tvp5150 @ 0xb8 - tuner(analog) @0xc2 (from 
dmesg 2.6 kernel)

I got to this point:

 femon -H:
 FE: Zarlink ZL10353 DVB-T (DVBT)
 Problem retrieving frontend information: Resource temporarily unavailable
 status  C| signal  71% | snr  74% | ber -1080313980 | unc -1218616323 
| 


Using next (G)PIO settings, enable more did not improve anything:

static struct em28xx_reg_seq zolid_tuner[] = {
//  {EM2820_R08_GPIO_CTRL,  EM_GPIO_4,  EM_GPIO_4,   10},
//  {EM2820_R08_GPIO_CTRL,   0, EM_GPIO_4,   10},
//  {EM2820_R08_GPIO_CTRL,  EM_GPIO_4,  EM_GPIO_4,   10},
{   -1, -1, -1,  -1},
};
static struct em28xx_reg_seq zolid_digital[] = {
//  {EM2820_R08_GPIO_CTRL,  0x6e,   ~EM_GPIO_4, 100},
//  {EM2880_R04_GPO,0x04,   0xff,   100},   
/* zl10353 reset ? */
{EM2880_R04_GPO,0x08,   0xff,10},   
/* zl10353 to connect tuner (dmesg) */
//  {EM2880_R04_GPO,0x0c,   0xff,10},
{   -1, -1, -1,  -1},
};
static struct em28xx_reg_seq zolid_analog[] = {
{EM2820_R08_GPIO_CTRL,  0x6d,   ~EM_GPIO_4,  10},   
/* em202 (dmesg) */
//  {EM2880_R04_GPO,0x04,   0xff,   100},
//  {EM2880_R04_GPO,0x08,   0xff,10},
//  {EM2880_R04_GPO,0x0c,   0xff,10},
{   -1, -1, -1,  -1},

Two years ago I used snoop and perl tools on the ms-windows-driver and got next 
result:
40 00 00 00 04 00 01 00 >>> 04, 08 or 0c
19 times alternating 08 and 0c, and the last one was 04 followed by 0c
Also 40 00 00 00 08 00 01 00 >>>  6a, 6b, 6f, 7a, 7f, fd, fe or ff
I tried all of them in the second Coulomb zolid_digital as 
EM2820_R09_GPIO_CTRL, no improvement.

I do have a data-sheet em2882, did search trough linux-media and used 
duck-duck-go trying to get relevant info, no luck at this point.

Question:
Where to find knowledge about the em2882 GPIO and GPO ?
And naturally, any tips or advice is appreciated.

Thanks in advance.

Marcel Stork (Netherlands)





lsusb:
Bus 005 Device 002: ID eb1a:2883 eMPIA Technology, Inc. 
--
/dev/dvb/adapter0 with demux0, drv0, frontend0 and net0 is created.
--
dmesg:
[ 1897.124737] em28xx: New device  USB 2883 Device @ 480 Mbps (eb1a:2883, 
interface 0, class 0)
[ 1897.124745] em28xx: Audio interface 0 found (Vendor Class)
[ 1897.124750] em28xx: Video interface 0 found: isoc
[ 1897.124754] em28xx: DVB interface 0 found: isoc
[ 1897.124896] em28xx: chip ID is em2882/3
[ 1897.230009] em2882/3 #0: EEPROM ID = 1a eb 67 95, EEPROM hash = 0x85dd871e
[ 1897.230017] em2882/3 #0: EEPROM info:
[ 1897.230020] em2882/3 #0: AC97 audio (5 sample rates)
[ 1897.230024] em2882/3 #0: 500mA max power
[ 1897.230029] em2882/3 #0: Table at offset 0x24, strings=0x226a, 0x108c, 
0x
[ 1897.230035] em2882/3 #0: Identified as :ZOLID HYBRID TV STICK (card=100)
[ 1897.230040] em2882/3 #0: analog set to isoc mode.
[ 1897.230044] em2882/3 #0: dvb set to isoc mode.
[ 1897.230280] usbcore: registered new interface driver em28xx
[ 1897.291557] em2882/3 #0: Registering V4L2 extension
[ 1897.313877] tvp5150 7-005c: tvp5150 (4.0) chip found @ 0xb8 (em2882/3 #0)
[ 1897.313885] tvp5150 7-005c: tvp5150am1 detected.
[ 1897.327869] tuner 7-0061: Tuner -1 found with type(s) Radio TV.
[ 1897.376267] xc2028 7-0061: creating new instance
[ 1897.376277] xc2028 7-0061: type set to XCeive xc2028/xc3028 tuner
[ 1897.376495] em2882/3 #0: Config register raw data: 0xd0
  [ 1897.377246] em2882/3 #0: AC97 vendor ID = 0x
  [ 1897.377621] em2882/3 #0: AC97 features = 0x6a90
[ 1897.377626] em2882/3 #0: Empia 202 AC97 audio processor detected
[ 1897.399113] usb 5-3: firmware: direct-loading firmware xc3028L-v36.fw
[ 1897.399129] xc2028 7-0061: Loading 81 firmware images from xc3028L-v36.fw, 
type: xc2028 firmware, ver 3.6
[ 1897.524132] xc2028 7-0061: Loading firmware for type=BASE F8MHZ MTS (7), id 
.
  [ 1898.511621] MTS (4), id 00ff:
[ 1898.511630] xc2028 7-0061: Loading firmware for type=MTS (4), id 
0007.
[ 1898.809002] em2882/3 #0: V4L2 video device registered as video0
[ 1898.809009] em2882/3 #0: V4L2 VBI device registered as vbi0
[ 1898.809994] em2882/3 #0: V4L2 extension successfully initialized
[ 1898.81] em28xx: Registered (Em28xx v4l2 Extension) exten

Problem with uvcvideo timestamps

[Niels Möller]

Hi,

I'm tracking down a problem in Chrome, where video streams captured
from a Logitech c930e camera get bogus timestamps. Chrome started
using camera timestamps on linux a few months ago. I've noted commit

  
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=5d0fd3c806b9e932010931ae67dbb482020e0882

  "[media] uvcvideo: Disable hardware timestamps by default"

but I'm running with a kernel which doesn't have that change.

First, let me say that for our purposes, the hairy syncing to the
"SOF" clock done by uvc_video_clock_update is not that useful.
Ideally, I would prefer if the v4l2_buffer of a captured frame
included both

  * untranslated pts timestamp from the camera device (if I've
understood this correctly, and there is a pts sent over the wire),
and

  * the value of system monotonic clock at the point when the frame
was received by the kernel.

Is there any reasonable way to get this information out from the
driver? We could then do estimation of the camera's epoch and clock
drift in the application. The raw pts is the most important piece of
information.

Second, I'd like to try to provide some logs to help track down the
bug. To reproduce, I'm using the example program at
https://gist.github.com/maxlapshin/1253534, modified to print out
camera timestamp and gettimeofday for each frame. Log attached as
time-2.log.

I also enabled tracing of the clock translation logic using

  echo 4096 > /sys/module/uvcvideo/parameters/trace

The corresponding kernel log messages are attached as trace-2.log.

In time-2.log (i.e., the application log), I see that camera
timestamps move backwards in time,

  TIMESTAMP_MONOTONIC
 cam: 2321521.085372
 sys: 1477913910.983620
  TIMESTAMP_MONOTONIC
 cam: 2321520.879272
 sys: 1477913911.051628

In trace-2.log (i.e., kernel log messages) I see

  uvcvideo: Logitech Webcam C930e: PTS 219483992 y 4084.798004 SOF
4084.798004 (x1 2064310082 x2 2148397132 y1 218759168 y2 268238848 SOF
offset 170)
  uvcvideo: Logitech Webcam C930e: SOF 4084.798004 y 3105900702 ts
2321520.879272 buf ts 2321521.153372 (x1 218759168/1546/1290 x2
274071552/1878/2045 y1 10 y2 3380001263)
  uvcvideo: Logitech Webcam C930e: PTS 221480532 y 4156.709564 SOF
4156.709564 (x1 2079524156 x2 2148397450 y1 256376832 y2 272629760 SOF
offset 170)
  uvcvideo: Logitech Webcam C930e: SOF 4156.709564 y 2453257742 ts
2321520.378627 buf ts 2321521.217373 (x1 262275072/1698/1864 x2
278265856/1942/64 y1 10 y2 3292003672)
  uvcvideo: Logitech Webcam C930e: PTS 223477044 y 4223.428085 SOF
4223.428085 (x1 2081269216 x2 2148397122 y1 264568832 y2 276955136 SOF
offset 170)
  uvcvideo: Logitech Webcam C930e: SOF 2175.428085 y 2158773894 ts
2321520.208143 buf ts 2321521.285373 (x1 136183808/1822/1989 x2
148504576/2010/130 y1 10 y2 3236003012)

I don't know the details of the usb protocol, but it looks like the
"SOF" value is usually increasing. But close to the bogus output
timestamp of 2321520.879272, it goes through some kind of wraparound,
with the sequence of values

  4156.709564
  4223.428085
  2175.428085# 2048 less than previous value
  2243.169921

I hope the attached logs provide enough information to analyze where
uvc_video_clock_update gets this wrong.

Best regards,
/Niels Möller
TIMESTAMP_MONOTONIC
   cam: 2321518.773372
   sys: 1477913908.671607
TIMESTAMP_MONOTONIC
   cam: 2321518.925369
   sys: 1477913908.823594
TIMESTAMP_MONOTONIC
   cam: 2321519.049369
   sys: 1477913908.947600
TIMESTAMP_MONOTONIC
   cam: 2321519.173370
   sys: 1477913909.071610
TIMESTAMP_MONOTONIC
   cam: 2321519.297369
   sys: 1477913909.195603
TIMESTAMP_MONOTONIC
   cam: 2321519.421370
   sys: 1477913909.319607
TIMESTAMP_MONOTONIC
   cam: 2321519.489369
   sys: 1477913909.387594
TIMESTAMP_MONOTONIC
   cam: 2321519.553370
   sys: 1477913909.455586
TIMESTAMP_MONOTONIC
   cam: 2321519.621369
   sys: 1477913909.519601
TIMESTAMP_MONOTONIC
   cam: 2321519.689369
   sys: 1477913909.587594
TIMESTAMP_MONOTONIC
   cam: 2321519.753370
   sys: 1477913909.655587
TIMESTAMP_MONOTONIC
   cam: 2321519.821370
   sys: 1477913909.719600
TIMESTAMP_MONOTONIC
   cam: 2321519.889370
   sys: 1477913909.787594
TIMESTAMP_MONOTONIC
   cam: 2321519.953371
   sys: 1477913909.855585
TIMESTAMP_MONOTONIC
   cam: 2321520.021370
   sys: 1477913909.919602
TIMESTAMP_MONOTONIC
   cam: 2321520.089370
   sys: 1477913909.987594
TIMESTAMP_MONOTONIC
   cam: 2321520.153370
   sys: 1477913910.051609
TIMESTAMP_MONOTONIC
   cam: 2321520.221371
   sys: 1477913910.119597
TIMESTAMP_MONOTONIC
   cam: 2321520.289371
   sys: 1477913910.187599
TIMESTAMP_MONOTONIC
   cam: 2321520.353371
   sys: 1477913910.251609
TIMESTAMP_MONOTONIC
   cam: 2321520.421371
   sys: 1477913910.319597
TIMESTAMP_MONOTONIC
   cam: 2321520.485372
   sys: 1477913910.387588
TIMESTAMP_MONOTONIC
   cam: 2321520.553371
   sys: 1477913910.451604
TIMESTAMP_MONOTONIC
   cam: 2321520.621371
   sys: 1477913910.

Re: Problem with VMAP_STACK=y

[Mauro Carvalho Chehab]

Em Fri, 7 Oct 2016 09:52:56 +0200 (CEST)
Jiri Kosina <ji...@kernel.org> escreveu:

> On Thu, 6 Oct 2016, Mauro Carvalho Chehab wrote:
> 
> > I can't see any other obvious error on the conversion. You could try to 
> > enable debug options at DVB core/dvb-usb and/or add some printk's to the 
> > driver and see what's happening.
> 
> Mauro, also please don't forget that there are many more places in 
> drivers/media that still perform DMA on stack, and so have to be fixed for 
> 4.9 (as VMAP_STACK makes that to be immediately visible problem even on 
> x86_64, which it wasn't the case before).

Yes, I'm aware of that. I'm doing the conversion of drivers under dvb-usb,
at:

https://git.linuxtv.org/mchehab/experimental.git/log/?h=media_dmastack_fixes

I'll be sending the patches to the ML after ready.

I'll then take a look on other USB drivers that use the stack. I guess
the non-USB media drivers are safe from this issue.

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

Re: Problem with VMAP_STACK=y

[Jiri Kosina]

On Thu, 6 Oct 2016, Mauro Carvalho Chehab wrote:

> I can't see any other obvious error on the conversion. You could try to 
> enable debug options at DVB core/dvb-usb and/or add some printk's to the 
> driver and see what's happening.

Mauro, also please don't forget that there are many more places in 
drivers/media that still perform DMA on stack, and so have to be fixed for 
4.9 (as VMAP_STACK makes that to be immediately visible problem even on 
x86_64, which it wasn't the case before).

Thanks,

-- 
Jiri Kosina
SUSE Labs

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

Re: Problem with VMAP_STACK=y

[Mauro Carvalho Chehab]

Em Thu, 6 Oct 2016 10:30:15 +0200
Jörg Otte  escreveu:

> 2016-10-05 20:55 GMT+02:00 Mauro Carvalho Chehab :
> > Hi Johannes,
> >
> > Em Wed, 5 Oct 2016 20:29:45 +0200
> > Johannes Stezenbach  escreveu:
> >  
> >> On Wed, Oct 05, 2016 at 06:04:50AM -0300, Mauro Carvalho Chehab wrote:  
> >> >  static int cinergyt2_frontend_attach(struct dvb_usb_adapter *adap)
> >> >  {
> >> > -   char query[] = { CINERGYT2_EP1_GET_FIRMWARE_VERSION };
> >> > -   char state[3];
> >> > +   struct dvb_usb_device *d = adap->dev;
> >> > +   struct cinergyt2_state *st = d->priv;
> >> > int ret;
> >> >
> >> > adap->fe_adap[0].fe = cinergyt2_fe_attach(adap->dev);
> >> >
> >> > -   ret = dvb_usb_generic_rw(adap->dev, query, sizeof(query), state,
> >> > -   sizeof(state), 0);  
> >>
> >> it seems to miss this:
> >>
> >>   st->data[0] = CINERGYT2_EP1_GET_FIRMWARE_VERSION;
> >>  
> >> > +   ret = dvb_usb_generic_rw(d, st->data, 1, st->data, 3, 0);
> >> > if (ret < 0) {
> >> > deb_rc("cinergyt2_power_ctrl() Failed to retrieve sleep "
> >> > "state info\n");
> >> > @@ -141,13 +147,14 @@ static int repeatable_keys[] = {
> >> >  static int cinergyt2_rc_query(struct dvb_usb_device *d, u32 *event, int 
> >> > *state)
> >> >  {
> >> > struct cinergyt2_state *st = d->priv;
> >> > -   u8 key[5] = {0, 0, 0, 0, 0}, cmd = CINERGYT2_EP1_GET_RC_EVENTS;
> >> > int i;
> >> >
> >> > *state = REMOTE_NO_KEY_PRESSED;
> >> >
> >> > -   dvb_usb_generic_rw(d, , 1, key, sizeof(key), 0);
> >> > -   if (key[4] == 0xff) {
> >> > +   st->data[0] = CINERGYT2_EP1_SLEEP_MODE;  
> >>
> >> should probably be
> >>
> >>   st->data[0] = CINERGYT2_EP1_GET_RC_EVENTS;
> >>  
> >> > +
> >> > +   dvb_usb_generic_rw(d, st->data, 1, st->data, 5, 0);  
> >>
> >>
> >> HTH,
> >> Johannes  
> >
> >
> > Thanks for the review! Yeah, you're right: both firmware and remote
> > controller logic would be broken without the above fixes.
> >
> > Just sent a version 2 of this patch to the ML with the above fixes.
> >
> > Regards,
> > Mauro  
> 
> Applied V2 of the patch. Unfortunately no progress.
> No video, no error messages.

I can't see any other obvious error on the conversion. You could try
to enable debug options at DVB core/dvb-usb and/or add some printk's to
the driver and see what's happening.


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

Re: Problem with VMAP_STACK=y

[Jörg Otte]

2016-10-05 20:55 GMT+02:00 Mauro Carvalho Chehab :
> Hi Johannes,
>
> Em Wed, 5 Oct 2016 20:29:45 +0200
> Johannes Stezenbach  escreveu:
>
>> On Wed, Oct 05, 2016 at 06:04:50AM -0300, Mauro Carvalho Chehab wrote:
>> >  static int cinergyt2_frontend_attach(struct dvb_usb_adapter *adap)
>> >  {
>> > -   char query[] = { CINERGYT2_EP1_GET_FIRMWARE_VERSION };
>> > -   char state[3];
>> > +   struct dvb_usb_device *d = adap->dev;
>> > +   struct cinergyt2_state *st = d->priv;
>> > int ret;
>> >
>> > adap->fe_adap[0].fe = cinergyt2_fe_attach(adap->dev);
>> >
>> > -   ret = dvb_usb_generic_rw(adap->dev, query, sizeof(query), state,
>> > -   sizeof(state), 0);
>>
>> it seems to miss this:
>>
>>   st->data[0] = CINERGYT2_EP1_GET_FIRMWARE_VERSION;
>>
>> > +   ret = dvb_usb_generic_rw(d, st->data, 1, st->data, 3, 0);
>> > if (ret < 0) {
>> > deb_rc("cinergyt2_power_ctrl() Failed to retrieve sleep "
>> > "state info\n");
>> > @@ -141,13 +147,14 @@ static int repeatable_keys[] = {
>> >  static int cinergyt2_rc_query(struct dvb_usb_device *d, u32 *event, int 
>> > *state)
>> >  {
>> > struct cinergyt2_state *st = d->priv;
>> > -   u8 key[5] = {0, 0, 0, 0, 0}, cmd = CINERGYT2_EP1_GET_RC_EVENTS;
>> > int i;
>> >
>> > *state = REMOTE_NO_KEY_PRESSED;
>> >
>> > -   dvb_usb_generic_rw(d, , 1, key, sizeof(key), 0);
>> > -   if (key[4] == 0xff) {
>> > +   st->data[0] = CINERGYT2_EP1_SLEEP_MODE;
>>
>> should probably be
>>
>>   st->data[0] = CINERGYT2_EP1_GET_RC_EVENTS;
>>
>> > +
>> > +   dvb_usb_generic_rw(d, st->data, 1, st->data, 5, 0);
>>
>>
>> HTH,
>> Johannes
>
>
> Thanks for the review! Yeah, you're right: both firmware and remote
> controller logic would be broken without the above fixes.
>
> Just sent a version 2 of this patch to the ML with the above fixes.
>
> Regards,
> Mauro

Applied V2 of the patch. Unfortunately no progress.
No video, no error messages.

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

Re: Problem with VMAP_STACK=y

[Mauro Carvalho Chehab]

Hi Johannes,

Em Wed, 5 Oct 2016 20:29:45 +0200
Johannes Stezenbach  escreveu:

> On Wed, Oct 05, 2016 at 06:04:50AM -0300, Mauro Carvalho Chehab wrote:
> >  static int cinergyt2_frontend_attach(struct dvb_usb_adapter *adap)
> >  {
> > -   char query[] = { CINERGYT2_EP1_GET_FIRMWARE_VERSION };
> > -   char state[3];
> > +   struct dvb_usb_device *d = adap->dev;
> > +   struct cinergyt2_state *st = d->priv;
> > int ret;
> >  
> > adap->fe_adap[0].fe = cinergyt2_fe_attach(adap->dev);
> >  
> > -   ret = dvb_usb_generic_rw(adap->dev, query, sizeof(query), state,
> > -   sizeof(state), 0);  
> 
> it seems to miss this:
> 
>   st->data[0] = CINERGYT2_EP1_GET_FIRMWARE_VERSION;
> 
> > +   ret = dvb_usb_generic_rw(d, st->data, 1, st->data, 3, 0);
> > if (ret < 0) {
> > deb_rc("cinergyt2_power_ctrl() Failed to retrieve sleep "
> > "state info\n");
> > @@ -141,13 +147,14 @@ static int repeatable_keys[] = {
> >  static int cinergyt2_rc_query(struct dvb_usb_device *d, u32 *event, int 
> > *state)
> >  {
> > struct cinergyt2_state *st = d->priv;
> > -   u8 key[5] = {0, 0, 0, 0, 0}, cmd = CINERGYT2_EP1_GET_RC_EVENTS;
> > int i;
> >  
> > *state = REMOTE_NO_KEY_PRESSED;
> >  
> > -   dvb_usb_generic_rw(d, , 1, key, sizeof(key), 0);
> > -   if (key[4] == 0xff) {
> > +   st->data[0] = CINERGYT2_EP1_SLEEP_MODE;  
> 
> should probably be
> 
>   st->data[0] = CINERGYT2_EP1_GET_RC_EVENTS;
> 
> > +
> > +   dvb_usb_generic_rw(d, st->data, 1, st->data, 5, 0);  
> 
> 
> HTH,
> Johannes


Thanks for the review! Yeah, you're right: both firmware and remote
controller logic would be broken without the above fixes.

Just sent a version 2 of this patch to the ML with the above fixes.

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

Re: Problem with VMAP_STACK=y

[Johannes Stezenbach]

On Wed, Oct 05, 2016 at 06:04:50AM -0300, Mauro Carvalho Chehab wrote:
>  static int cinergyt2_frontend_attach(struct dvb_usb_adapter *adap)
>  {
> - char query[] = { CINERGYT2_EP1_GET_FIRMWARE_VERSION };
> - char state[3];
> + struct dvb_usb_device *d = adap->dev;
> + struct cinergyt2_state *st = d->priv;
>   int ret;
>  
>   adap->fe_adap[0].fe = cinergyt2_fe_attach(adap->dev);
>  
> - ret = dvb_usb_generic_rw(adap->dev, query, sizeof(query), state,
> - sizeof(state), 0);

it seems to miss this:

st->data[0] = CINERGYT2_EP1_GET_FIRMWARE_VERSION;

> + ret = dvb_usb_generic_rw(d, st->data, 1, st->data, 3, 0);
>   if (ret < 0) {
>   deb_rc("cinergyt2_power_ctrl() Failed to retrieve sleep "
>   "state info\n");
> @@ -141,13 +147,14 @@ static int repeatable_keys[] = {
>  static int cinergyt2_rc_query(struct dvb_usb_device *d, u32 *event, int 
> *state)
>  {
>   struct cinergyt2_state *st = d->priv;
> - u8 key[5] = {0, 0, 0, 0, 0}, cmd = CINERGYT2_EP1_GET_RC_EVENTS;
>   int i;
>  
>   *state = REMOTE_NO_KEY_PRESSED;
>  
> - dvb_usb_generic_rw(d, , 1, key, sizeof(key), 0);
> - if (key[4] == 0xff) {
> + st->data[0] = CINERGYT2_EP1_SLEEP_MODE;

should probably be

st->data[0] = CINERGYT2_EP1_GET_RC_EVENTS;

> +
> + dvb_usb_generic_rw(d, st->data, 1, st->data, 5, 0);


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

Re: Problem with VMAP_STACK=y

[Andy Lutomirski]

On Wed, Oct 5, 2016 at 9:45 AM, Jörg Otte <jrg.o...@gmail.com> wrote:
> 2016-10-05 17:53 GMT+02:00 Andy Lutomirski <l...@amacapital.net>:
>> On Wed, Oct 5, 2016 at 8:21 AM, Jörg Otte <jrg.o...@gmail.com> wrote:
>>> 2016-10-05 11:04 GMT+02:00 Mauro Carvalho Chehab <mche...@s-opensource.com>:
>>>> Em Wed, 5 Oct 2016 09:50:42 +0200 (CEST)
>>>> Jiri Kosina <ji...@kernel.org> escreveu:
>>>>
>>>>> On Wed, 5 Oct 2016, Patrick Boettcher wrote:
>>>>>
>>>>> > > > Thanks for the quick response.
>>>>> > > > Drivers are:
>>>>> > > > dvb_core, dvb_usb, dbv_usb_cynergyT2
>>>>> > >
>>>>> > > This dbv_usb_cynergyT2 is not from Linus' tree, is it? I don't seem
>>>>> > > to be able to find it, and the only google hit I am getting is your
>>>>> > > very mail to LKML :)
>>>>> >
>>>>> > It's a typo, it should say dvb_usb_cinergyT2.
>>>>>
>>>>> Ah, thanks. Same issues there in
>>>>>
>>>>>   cinergyt2_frontend_attach()
>>>>>   cinergyt2_rc_query()
>>>>>
>>>>> I think this would require more in-depth review of all the media drivers
>>>>> and having all this fixed for 4.9. It should be pretty straightforward;
>>>>> all the instances I've seen so far should be just straightforward
>>>>> conversion to kmalloc() + kfree(), as the buffer is not being embedded in
>>>>> any structure etc.
>>>>
>>>> What we're doing on most cases is to put a buffer (usually with 80
>>>> chars for USB drivers) inside the "state" struct (on DVB drivers),
>>>> in order to avoid doing kmalloc/kfree all the times. One such patch is
>>>> changeset c4a98793a63c4.
>>>>
>>>> I'm enclosing a non-tested patch fixing it for the cinergyT2-core.c
>>>> driver.
>>>>
>>>> Thanks,
>>>> Mauro
>>>>
>>>> [PATCH] cinergyT2-core: don't do DMA on stack
>>>>
>>>
>>> Tried the cinergyT2 patch. No success. When I select a TV channel
>>> just nothing happens. There are no error messages.
>>
>> Could you try compiling with CONFIG_DEBUG_VIRTUAL=y and seeing if you
>> get a nice error message?
>>
>> --Andy
>
> Done. Still no error messages in dmesg and syslog.
>
> DVB adapter signals it is tuned to the channel.
> For me it looks like there`s no data reaching the application
> (similar to if I forget to connect an antenna).

I'm surprised.  CONFIG_DEBUG_VIRTUAL=y really ought to have caught the
problem, whatever it is.  You could try CONFIG_DEBUG_SG as well, but I
admit I'm grasping at straws there.  Maybe the DVB people have a
better idea as to what's going on here.

It's plausible that the patch you're testing got rid of the DMA on the
stack but is otherwise buggy.

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

Re: Problem with VMAP_STACK=y

[Jörg Otte]

2016-10-05 17:53 GMT+02:00 Andy Lutomirski :
> On Wed, Oct 5, 2016 at 8:21 AM, Jörg Otte  wrote:
>> 2016-10-05 11:04 GMT+02:00 Mauro Carvalho Chehab :
>>> Em Wed, 5 Oct 2016 09:50:42 +0200 (CEST)
>>> Jiri Kosina  escreveu:
>>>
 On Wed, 5 Oct 2016, Patrick Boettcher wrote:

 > > > Thanks for the quick response.
 > > > Drivers are:
 > > > dvb_core, dvb_usb, dbv_usb_cynergyT2
 > >
 > > This dbv_usb_cynergyT2 is not from Linus' tree, is it? I don't seem
 > > to be able to find it, and the only google hit I am getting is your
 > > very mail to LKML :)
 >
 > It's a typo, it should say dvb_usb_cinergyT2.

 Ah, thanks. Same issues there in

   cinergyt2_frontend_attach()
   cinergyt2_rc_query()

 I think this would require more in-depth review of all the media drivers
 and having all this fixed for 4.9. It should be pretty straightforward;
 all the instances I've seen so far should be just straightforward
 conversion to kmalloc() + kfree(), as the buffer is not being embedded in
 any structure etc.
>>>
>>> What we're doing on most cases is to put a buffer (usually with 80
>>> chars for USB drivers) inside the "state" struct (on DVB drivers),
>>> in order to avoid doing kmalloc/kfree all the times. One such patch is
>>> changeset c4a98793a63c4.
>>>
>>> I'm enclosing a non-tested patch fixing it for the cinergyT2-core.c
>>> driver.
>>>
>>> Thanks,
>>> Mauro
>>>
>>> [PATCH] cinergyT2-core: don't do DMA on stack
>>>
>>
>> Tried the cinergyT2 patch. No success. When I select a TV channel
>> just nothing happens. There are no error messages.
>
> Could you try compiling with CONFIG_DEBUG_VIRTUAL=y and seeing if you
> get a nice error message?
>
> --Andy

Done. Still no error messages in dmesg and syslog.

DVB adapter signals it is tuned to the channel.
For me it looks like there`s no data reaching the application
(similar to if I forget to connect an antenna).

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

Re: Problem with VMAP_STACK=y

[Andy Lutomirski]

On Wed, Oct 5, 2016 at 8:21 AM, Jörg Otte  wrote:
> 2016-10-05 11:04 GMT+02:00 Mauro Carvalho Chehab :
>> Em Wed, 5 Oct 2016 09:50:42 +0200 (CEST)
>> Jiri Kosina  escreveu:
>>
>>> On Wed, 5 Oct 2016, Patrick Boettcher wrote:
>>>
>>> > > > Thanks for the quick response.
>>> > > > Drivers are:
>>> > > > dvb_core, dvb_usb, dbv_usb_cynergyT2
>>> > >
>>> > > This dbv_usb_cynergyT2 is not from Linus' tree, is it? I don't seem
>>> > > to be able to find it, and the only google hit I am getting is your
>>> > > very mail to LKML :)
>>> >
>>> > It's a typo, it should say dvb_usb_cinergyT2.
>>>
>>> Ah, thanks. Same issues there in
>>>
>>>   cinergyt2_frontend_attach()
>>>   cinergyt2_rc_query()
>>>
>>> I think this would require more in-depth review of all the media drivers
>>> and having all this fixed for 4.9. It should be pretty straightforward;
>>> all the instances I've seen so far should be just straightforward
>>> conversion to kmalloc() + kfree(), as the buffer is not being embedded in
>>> any structure etc.
>>
>> What we're doing on most cases is to put a buffer (usually with 80
>> chars for USB drivers) inside the "state" struct (on DVB drivers),
>> in order to avoid doing kmalloc/kfree all the times. One such patch is
>> changeset c4a98793a63c4.
>>
>> I'm enclosing a non-tested patch fixing it for the cinergyT2-core.c
>> driver.
>>
>> Thanks,
>> Mauro
>>
>> [PATCH] cinergyT2-core: don't do DMA on stack
>>
>
> Tried the cinergyT2 patch. No success. When I select a TV channel
> just nothing happens. There are no error messages.

Could you try compiling with CONFIG_DEBUG_VIRTUAL=y and seeing if you
get a nice error message?

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

Re: Problem with VMAP_STACK=y

[Jörg Otte]

2016-10-05 11:04 GMT+02:00 Mauro Carvalho Chehab :
> Em Wed, 5 Oct 2016 09:50:42 +0200 (CEST)
> Jiri Kosina  escreveu:
>
>> On Wed, 5 Oct 2016, Patrick Boettcher wrote:
>>
>> > > > Thanks for the quick response.
>> > > > Drivers are:
>> > > > dvb_core, dvb_usb, dbv_usb_cynergyT2
>> > >
>> > > This dbv_usb_cynergyT2 is not from Linus' tree, is it? I don't seem
>> > > to be able to find it, and the only google hit I am getting is your
>> > > very mail to LKML :)
>> >
>> > It's a typo, it should say dvb_usb_cinergyT2.
>>
>> Ah, thanks. Same issues there in
>>
>>   cinergyt2_frontend_attach()
>>   cinergyt2_rc_query()
>>
>> I think this would require more in-depth review of all the media drivers
>> and having all this fixed for 4.9. It should be pretty straightforward;
>> all the instances I've seen so far should be just straightforward
>> conversion to kmalloc() + kfree(), as the buffer is not being embedded in
>> any structure etc.
>
> What we're doing on most cases is to put a buffer (usually with 80
> chars for USB drivers) inside the "state" struct (on DVB drivers),
> in order to avoid doing kmalloc/kfree all the times. One such patch is
> changeset c4a98793a63c4.
>
> I'm enclosing a non-tested patch fixing it for the cinergyT2-core.c
> driver.
>
> Thanks,
> Mauro
>
> [PATCH] cinergyT2-core: don't do DMA on stack
>

Tried the cinergyT2 patch. No success. When I select a TV channel
just nothing happens. There are no error messages.

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

Re: Problem with VMAP_STACK=y

[Mauro Carvalho Chehab]

Em Wed, 5 Oct 2016 06:04:50 -0300
Mauro Carvalho Chehab  escreveu:

> Em Wed, 5 Oct 2016 09:50:42 +0200 (CEST)
> Jiri Kosina  escreveu:
> 
> > On Wed, 5 Oct 2016, Patrick Boettcher wrote:
> > 
> > > > > Thanks for the quick response.
> > > > > Drivers are:
> > > > > dvb_core, dvb_usb, dbv_usb_cynergyT2
> > > > 
> > > > This dbv_usb_cynergyT2 is not from Linus' tree, is it? I don't seem
> > > > to be able to find it, and the only google hit I am getting is your
> > > > very mail to LKML :)  
> > > 
> > > It's a typo, it should say dvb_usb_cinergyT2.  
> > 
> > Ah, thanks. Same issues there in
> > 
> > cinergyt2_frontend_attach()
> > cinergyt2_rc_query()
> > 
> > I think this would require more in-depth review of all the media drivers 
> > and having all this fixed for 4.9. It should be pretty straightforward; 
> > all the instances I've seen so far should be just straightforward 
> > conversion to kmalloc() + kfree(), as the buffer is not being embedded in 
> > any structure etc.
> 
> What we're doing on most cases is to put a buffer (usually with 80
> chars for USB drivers) inside the "state" struct (on DVB drivers),
> in order to avoid doing kmalloc/kfree all the times. One such patch is 
> changeset c4a98793a63c4.
> 
> I'm enclosing a non-tested patch fixing it for the cinergyT2-core.c
> driver.
> 
> Thanks,
> Mauro

And this is another such patch for af9005, also untested. If I
remember well, the firmware load and warm/cold state logic calls
happen before allocating space for struct state. So, it needs to
call of kmalloc on two places.

I may write similar patches for other drivers under drivers/media/usb,
if I have enough time for that.

Regards,
Mauro


[PATCH] af9005: don't do DMA on stack

The USB control messages require DMA to work. We cannot pass
a stack-allocated buffer, as it is not warranted that the
stack would be into a DMA enabled area.

Signed-off-by: Mauro Carvalho Chehab 

diff --git a/drivers/media/usb/dvb-usb/af9005.c 
b/drivers/media/usb/dvb-usb/af9005.c
index efa782ed6e2d..cc5815de1cfb 100644
--- a/drivers/media/usb/dvb-usb/af9005.c
+++ b/drivers/media/usb/dvb-usb/af9005.c
@@ -52,17 +52,15 @@ u8 regmask[8] = { 0x01, 0x03, 0x07, 0x0f, 0x1f, 0x3f, 0x7f, 
0xff };
 struct af9005_device_state {
u8 sequence;
int led_state;
+   unsigned char data[256];
 };
 
 static int af9005_generic_read_write(struct dvb_usb_device *d, u16 reg,
  int readwrite, int type, u8 * values, int len)
 {
struct af9005_device_state *st = d->priv;
-   u8 obuf[16] = { 0 };
-   u8 ibuf[17] = { 0 };
-   u8 command;
-   int i;
-   int ret;
+   u8 command, seq;
+   int i, ret;
 
if (len < 1) {
err("generic read/write, less than 1 byte. Makes no sense.");
@@ -73,16 +71,16 @@ static int af9005_generic_read_write(struct dvb_usb_device 
*d, u16 reg,
return -EINVAL;
}
 
-   obuf[0] = 14;   /* rest of buffer length low */
-   obuf[1] = 0;/* rest of buffer length high */
+   st->data[0] = 14;   /* rest of buffer length low */
+   st->data[1] = 0;/* rest of buffer length high */
 
-   obuf[2] = AF9005_REGISTER_RW;   /* register operation */
-   obuf[3] = 12;   /* rest of buffer length */
+   st->data[2] = AF9005_REGISTER_RW;   /* register operation */
+   st->data[3] = 12;   /* rest of buffer length */
 
-   obuf[4] = st->sequence++;   /* sequence number */
+   st->data[4] = seq = st->sequence++; /* sequence number */
 
-   obuf[5] = (u8) (reg >> 8);  /* register address */
-   obuf[6] = (u8) (reg & 0xff);
+   st->data[5] = (u8) (reg >> 8);  /* register address */
+   st->data[6] = (u8) (reg & 0xff);
 
if (type == AF9005_OFDM_REG) {
command = AF9005_CMD_OFDM_REG;
@@ -96,49 +94,43 @@ static int af9005_generic_read_write(struct dvb_usb_device 
*d, u16 reg,
command |= readwrite;
if (readwrite == AF9005_CMD_WRITE)
for (i = 0; i < len; i++)
-   obuf[8 + i] = values[i];
+   st->data[8 + i] = values[i];
else if (type == AF9005_TUNER_REG)
/* read command for tuner, the first byte contains the i2c 
address */
-   obuf[8] = values[0];
-   obuf[7] = command;
+   st->data[8] = values[0];
+   st->data[7] = command;
 
-   ret = dvb_usb_generic_rw(d, obuf, 16, ibuf, 17, 0);
+   ret = dvb_usb_generic_rw(d, st->data, 16, st->data, 17, 0);
if (ret)
return ret;
 
/* sanity check */
-   if (ibuf[2] != AF9005_REGISTER_RW_ACK) {
+   if (st->data[2] != AF9005_REGISTER_RW_ACK) {
err("generic read/write, wrong reply code.");
return -EIO;
}
-   if (ibuf[3] != 0x0d) {

Re: Problem with VMAP_STACK=y

[Mauro Carvalho Chehab]

Em Wed, 5 Oct 2016 09:50:42 +0200 (CEST)
Jiri Kosina  escreveu:

> On Wed, 5 Oct 2016, Patrick Boettcher wrote:
> 
> > > > Thanks for the quick response.
> > > > Drivers are:
> > > > dvb_core, dvb_usb, dbv_usb_cynergyT2
> > > 
> > > This dbv_usb_cynergyT2 is not from Linus' tree, is it? I don't seem
> > > to be able to find it, and the only google hit I am getting is your
> > > very mail to LKML :)  
> > 
> > It's a typo, it should say dvb_usb_cinergyT2.  
> 
> Ah, thanks. Same issues there in
> 
>   cinergyt2_frontend_attach()
>   cinergyt2_rc_query()
> 
> I think this would require more in-depth review of all the media drivers 
> and having all this fixed for 4.9. It should be pretty straightforward; 
> all the instances I've seen so far should be just straightforward 
> conversion to kmalloc() + kfree(), as the buffer is not being embedded in 
> any structure etc.

What we're doing on most cases is to put a buffer (usually with 80
chars for USB drivers) inside the "state" struct (on DVB drivers),
in order to avoid doing kmalloc/kfree all the times. One such patch is 
changeset c4a98793a63c4.

I'm enclosing a non-tested patch fixing it for the cinergyT2-core.c
driver.

Thanks,
Mauro

[PATCH] cinergyT2-core: don't do DMA on stack

The USB control messages require DMA to work. We cannot pass
a stack-allocated buffer, as it is not warranted that the
stack would be into a DMA enabled area.

Signed-off-by: Mauro Carvalho Chehab 

diff --git a/drivers/media/usb/dvb-usb/cinergyT2-core.c 
b/drivers/media/usb/dvb-usb/cinergyT2-core.c
index 9fd1527494eb..2787acc74fcc 100644
--- a/drivers/media/usb/dvb-usb/cinergyT2-core.c
+++ b/drivers/media/usb/dvb-usb/cinergyT2-core.c
@@ -41,6 +41,7 @@ DVB_DEFINE_MOD_OPT_ADAPTER_NR(adapter_nr);
 
 struct cinergyt2_state {
u8 rc_counter;
+   unsigned char data[64];
 };
 
 /* We are missing a release hook with usb_device data */
@@ -50,29 +51,34 @@ static struct dvb_usb_device_properties 
cinergyt2_properties;
 
 static int cinergyt2_streaming_ctrl(struct dvb_usb_adapter *adap, int enable)
 {
-   char buf[] = { CINERGYT2_EP1_CONTROL_STREAM_TRANSFER, enable ? 1 : 0 };
-   char result[64];
-   return dvb_usb_generic_rw(adap->dev, buf, sizeof(buf), result,
-   sizeof(result), 0);
+   struct dvb_usb_device *d = adap->dev;
+   struct cinergyt2_state *st = d->priv;
+
+   st->data[0] = CINERGYT2_EP1_CONTROL_STREAM_TRANSFER;
+   st->data[1] = enable ? 1 : 0;
+
+   return dvb_usb_generic_rw(d, st->data, 2, st->data, 64, 0);
 }
 
 static int cinergyt2_power_ctrl(struct dvb_usb_device *d, int enable)
 {
-   char buf[] = { CINERGYT2_EP1_SLEEP_MODE, enable ? 0 : 1 };
-   char state[3];
-   return dvb_usb_generic_rw(d, buf, sizeof(buf), state, sizeof(state), 0);
+   struct cinergyt2_state *st = d->priv;
+
+   st->data[0] = CINERGYT2_EP1_SLEEP_MODE;
+   st->data[1] = enable ? 1 : 0;
+
+   return dvb_usb_generic_rw(d, st->data, 2, st->data, 3, 0);
 }
 
 static int cinergyt2_frontend_attach(struct dvb_usb_adapter *adap)
 {
-   char query[] = { CINERGYT2_EP1_GET_FIRMWARE_VERSION };
-   char state[3];
+   struct dvb_usb_device *d = adap->dev;
+   struct cinergyt2_state *st = d->priv;
int ret;
 
adap->fe_adap[0].fe = cinergyt2_fe_attach(adap->dev);
 
-   ret = dvb_usb_generic_rw(adap->dev, query, sizeof(query), state,
-   sizeof(state), 0);
+   ret = dvb_usb_generic_rw(d, st->data, 1, st->data, 3, 0);
if (ret < 0) {
deb_rc("cinergyt2_power_ctrl() Failed to retrieve sleep "
"state info\n");
@@ -141,13 +147,14 @@ static int repeatable_keys[] = {
 static int cinergyt2_rc_query(struct dvb_usb_device *d, u32 *event, int *state)
 {
struct cinergyt2_state *st = d->priv;
-   u8 key[5] = {0, 0, 0, 0, 0}, cmd = CINERGYT2_EP1_GET_RC_EVENTS;
int i;
 
*state = REMOTE_NO_KEY_PRESSED;
 
-   dvb_usb_generic_rw(d, , 1, key, sizeof(key), 0);
-   if (key[4] == 0xff) {
+   st->data[0] = CINERGYT2_EP1_SLEEP_MODE;
+
+   dvb_usb_generic_rw(d, st->data, 1, st->data, 5, 0);
+   if (st->data[4] == 0xff) {
/* key repeat */
st->rc_counter++;
if (st->rc_counter > RC_REPEAT_DELAY) {
@@ -166,13 +173,13 @@ static int cinergyt2_rc_query(struct dvb_usb_device *d, 
u32 *event, int *state)
}
 
/* hack to pass checksum on the custom field */
-   key[2] = ~key[1];
-   dvb_usb_nec_rc_key_to_event(d, key, event, state);
-   if (key[0] != 0) {
+   st->data[2] = ~st->data[1];
+   dvb_usb_nec_rc_key_to_event(d, st->data, event, state);
+   if (st->data[0] != 0) {
if (*event != d->last_event)
st->rc_counter = 0;
 
-   deb_rc("key: %*ph\n", 5, key);
+   deb_rc("key: %*ph\n", 5, 

Re: Problem with VMAP_STACK=y

[Jiri Kosina]

On Wed, 5 Oct 2016, Patrick Boettcher wrote:

> > > Thanks for the quick response.
> > > Drivers are:
> > > dvb_core, dvb_usb, dbv_usb_cynergyT2  
> > 
> > This dbv_usb_cynergyT2 is not from Linus' tree, is it? I don't seem
> > to be able to find it, and the only google hit I am getting is your
> > very mail to LKML :)
> 
> It's a typo, it should say dvb_usb_cinergyT2.

Ah, thanks. Same issues there in

cinergyt2_frontend_attach()
cinergyt2_rc_query()

I think this would require more in-depth review of all the media drivers 
and having all this fixed for 4.9. It should be pretty straightforward; 
all the instances I've seen so far should be just straightforward 
conversion to kmalloc() + kfree(), as the buffer is not being embedded in 
any structure etc.

-- 
Jiri Kosina
SUSE Labs

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

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

[Patrick Boettcher]

Hi,

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

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

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

Seems not the be the case :-(.

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

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

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

Re: Problem with VMAP_STACK=y

[Patrick Boettcher]

On Wed, 5 Oct 2016 09:26:29 +0200 (CEST)
Jiri Kosina  wrote:

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

It's a typo, it should say dvb_usb_cinergyT2.

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

Re: Problem with VMAP_STACK=y

[Jiri Kosina]

On Tue, 4 Oct 2016, Jörg Otte wrote:

> Thanks for the quick response.
> Drivers are:
> dvb_core, dvb_usb, dbv_usb_cynergyT2

This dbv_usb_cynergyT2 is not from Linus' tree, is it? I don't seem to be 
able to find it, and the only google hit I am getting is your very mail to 
LKML :)

-- 
Jiri Kosina
SUSE Labs

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

Re: Problem with VMAP_STACK=y

[Jörg Otte]

2016-10-04 15:26 GMT+02:00 Jiri Kosina :
> On Tue, 4 Oct 2016, Jörg Otte wrote:
>
>> With kernel 4.8.0-01558-g21f54dd I get thousands of
>> "dvb-usb: bulk message failed: -11 (1/0)"
>> messages in the logs and the DVB adapter is not working.
>>
>> It tourned out the new config option VMAP_STACK=y (which is the default)
>> is the culprit.
>> No problems for me with VMAP_STACK=n.
>
> I'd guess that this is EAGAIN coming from usb_hcd_map_urb_for_dma() as the
> DVB driver is trying to perform on-stack DMA.
>
> Not really knowing which driver exactly you're using, I quickly skimmed
> through DVB sources, and it turns out this indeed seems to be rather
> common antipattern, and it should be fixed nevertheless. See
>
> cxusb_ctrl_msg()
> dibusb_power_ctrl()
> dibusb2_0_streaming_ctrl()
> dibusb2_0_power_ctrl()
> digitv_ctrl_msg()
> dtt200u_fe_init()
> dtt200u_fe_set_frontend()
> dtt200u_power_ctrl()
> dtt200u_streaming_ctrl()
> dtt200u_pid_filter()
>
> Adding relevant CCs.
>
> --
> Jiri Kosina
> SUSE Labs

Thanks for the quick response.
Drivers are:
dvb_core, dvb_usb, dbv_usb_cynergyT2


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

Re: Problem with VMAP_STACK=y

[Jiri Kosina]

On Tue, 4 Oct 2016, Jörg Otte wrote:

> With kernel 4.8.0-01558-g21f54dd I get thousands of
> "dvb-usb: bulk message failed: -11 (1/0)"
> messages in the logs and the DVB adapter is not working.
> 
> It tourned out the new config option VMAP_STACK=y (which is the default)
> is the culprit.
> No problems for me with VMAP_STACK=n.

I'd guess that this is EAGAIN coming from usb_hcd_map_urb_for_dma() as the 
DVB driver is trying to perform on-stack DMA.

Not really knowing which driver exactly you're using, I quickly skimmed 
through DVB sources, and it turns out this indeed seems to be rather 
common antipattern, and it should be fixed nevertheless. See

cxusb_ctrl_msg()
dibusb_power_ctrl()
dibusb2_0_streaming_ctrl()
dibusb2_0_power_ctrl()
digitv_ctrl_msg()
dtt200u_fe_init()
dtt200u_fe_set_frontend()
dtt200u_power_ctrl()
dtt200u_streaming_ctrl()
dtt200u_pid_filter()

Adding relevant CCs.

-- 
Jiri Kosina
SUSE Labs
--
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 problem: Terratec TV+ BT848 card: No composite input

[Bodo Eggert]

Hardware (short description): Terratec TV+ BT848 card "1.0", reactivated 
after several years. Video source is a camera (or a random DVB-T receiver 
displaying "no signal" text, just for testing).


Software used for testing: qv4l2, Debian Jessie. I assume neither they nor 
you changed something recently so I didn't try a git kernel.



Problem: No picture recognized on composite input.

The composite input did work previously (IIRC V4L 1). The video sources do 
work, I get a black & white picture when connecting the same source to the 
SVHS input (using an adapter).


On "Composite1", I get no picture at all, but a blue background. Sometimes 
I get a framecounter (25 FPS), but if I do, it keeps counting after I 
unplug the video source.


Using different card= values (1 .. 30), I get similar results.

I traced the input to the correct pin, according to the data sheet.

Off cause the card might just be broken, but maybe there is something else 
I might try?



Hardware (details):

#lspci -vnn
...
01:06.0 Multimedia video controller [0400]: Brooktree Corporation Bt848 
Video Capture [109e:0350] (rev 12)

...
Kernel driver in use: bttv

# modprobe -v bttv
insmod /lib/modules/3.16.0-4-amd64/kernel/drivers/media/pci/bt8xx/bttv.ko 
card=25 pll=2


On the card, there is a 35 MHz XTAL. Also I did test with pll=0, no 
obvious change.


The card is equipped with a radio connector - no radio connected.

# dmesg
[11861.804207] bttv: driver version 0.9.19 loaded
[11861.804220] bttv: using 8 buffers with 2080k (520 pages) each for 
capture

[11861.804309] bttv: Bt8xx card found (0)
[11861.804345] bttv: 0: Bt848 (rev 18) at :01:06.0, irq: 17, latency: 
16, mmio: 0xfdeff000
[11861.804376] bttv: 0: using: Terratec TerraTV+ Version 1.0 (Bt848)/ 
Terra TValue Version 1.0/ Vobis TV-Boostar [card=25,insmod option]

[11862.804023] bttv: 0: tea5757: read timeout
[11862.804029] bttv: 0: tuner type=5
[11862.813526] bttv: 0: audio absent, no audio device found!
[11862.819402] All bytes are equal. It is not a TEA5767
[11862.819414] tuner 2-0060: Tuner -1 found with type(s) Radio TV.
[11862.819694] tuner-simple 2-0060: creating new instance
[11862.819697] tuner-simple 2-0060: type set to 5 (Philips PAL_BG (FI1216 
and compatibles))

[11862.821013] bttv: 0: PLL can sleep, using XTAL (35468950)
[11862.821753] bttv: 0: registered device video0
[11862.821816] bttv: 0: registered device vbi0

# uname -a
Linux be12 3.16.0-4-amd64 #1 SMP Debian 3.16.7-ckt20-1+deb8u2 (2016-01-02) 
x86_64 GNU/Linux


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

Tuning problem with Pinnacle PCTV 2000e

[Guillaume Membré]

Hi,

I asked this question on the mythtv mailling but without success :'(
I know that my question may not be appropriate, forgive me if I'm at
the wrong place.

I had a working mythtv 0.27.5 installation with a Pinnacle PCTV 2000e
(dual dvb-t usb card)  and I recently replaced my motherboard. I had
to upgrade the kernel due to compatibility issue with the usb-3 driver
and switch from 3.2.0 to 4.6.0.

Now, I can't record anything, recordings file are empty. I also tried
livetv : just after a fresh start of the bakend, the first channel is
working ok (tuning and playing ok) but when i try to switch to another
one, log fills up with "Ignoring PAT not containing our desired
program...".

In the example below, PID 257, 260, 261, 287, 369 belongs to the
multiplex with the frequency 68200 Hz. The recording is on the
channel M6 which is on the multiplex with the frequency 73800. The
PID displayed in log correspond to the previous tuned channel.
According to dvbtune, the reception is good (and SNR is as the same
level as 2 months ago) :
$ dvbtune -c 0 -m -tm 8 -cr AUTO -gi 8 -f 73800
Using DVB card "DiBcom 7000PC"
tuning DVB-T (in United Kingdom) to 73800 Hz
polling
Getting frontend event
FE_STATUS:
polling
Getting frontend event
FE_STATUS: FE_HAS_SIGNAL FE_HAS_LOCK FE_HAS_CARRIER FE_HAS_VITERBI FE_HAS_SYNC
Event:  Frequency: 73800
SymbolRate: 0
FEC_inner:  3
Bit error rate: 0
Signal strength: 26253
SNR: 228
FE_STATUS: FE_HAS_SIGNAL FE_HAS_LOCK FE_HAS_CARRIER FE_HAS_VITERBI FE_HAS_SYNC
Signal=26254, Verror=0, SNR=224dB, BlockErrors=0, (S|L|C|V|SY|)
Signal=26213, Verror=0, SNR=232dB, BlockErrors=0, (S|L|C|V|SY|)
Signal=26205, Verror=0, SNR=231dB, BlockErrors=0, (S|L|C|V|SY|)
Signal=26206, Verror=0, SNR=229dB, BlockErrors=0, (S|L|C|V|SY|)
Signal=26207, Verror=0, SNR=227dB, BlockErrors=0, (S|L|C|V|SY|)
Signal=26146, Verror=0, SNR=232dB, BlockErrors=0, (S|L|C|V|SY|)
Signal=26092, Verror=0, SNR=236dB, BlockErrors=0, (S|L|C|V|SY|)

If I record directly with tzap + cp, everything is good.

I tried a full rescan while deleting multiplex and channels through
mythtv-setup, I also increase tuning timeout without success.

Here is my setup :
debian jessie updated yesterday
kernel : 4.6.0-0.bpo.1-686-pae
Tuner : usb pinnacle double DVB-T PCTV 2000e, using dvb_usb_dib0700 driver
Mythtv version : 0.27.6

Have you any idea ?
Thanks a lot for your help

Here is a log of a mythtv recording starting but failling :
2016-06-25 21:02:10.909647 C  mythbackend version: fixes/0.27
[v0.27.6-26-g28b7db2-dirty] www.mythtv.org
2016-06-25 21:02:10.909678 C  Qt version: compile: 4.8.6, runtime: 4.8.6
2016-06-25 21:02:10.909687 N  Enabled verbose msgs:  general record channel
2016-06-25 21:02:10.909704 N  Setting Log Level to LOG_INFO
2016-06-25 21:02:10.911076 I  Added logging to the console
2016-06-25 21:02:10.911390 I  Setup Interrupt handler
2016-06-25 21:02:10.911411 I  Setup Terminated handler
2016-06-25 21:02:10.911434 I  Setup Segmentation fault handler
2016-06-25 21:02:10.911452 I  Setup Aborted handler
2016-06-25 21:02:10.911474 I  Setup Bus error handler
2016-06-25 21:02:10.911497 I  Setup Floating point exception handler
2016-06-25 21:02:10.911516 I  Setup Illegal instruction handler
2016-06-25 21:02:10.911541 I  Setup Real-time signal 0 handler
2016-06-25 21:02:10.911563 I  Setup Hangup handler
2016-06-25 21:02:10.911670 N  Using runtime prefix = /usr
2016-06-25 21:02:10.911699 N  Using configuration directory =
/home/mythtv/.mythtv
2016-06-25 21:02:10.911872 I  Assumed character encoding: en_US.UTF-8
2016-06-25 21:02:10.912931 N  Empty LocalHostName.
2016-06-25 21:02:10.912953 I  Using localhost value of popeye
2016-06-25 21:02:10.997799 N  Setting QT default locale to FR_US
2016-06-25 21:02:10.998391 I  Current locale FR_US
2016-06-25 21:02:10.998599 E  No locale defaults file for FR_US, skipping
2016-06-25 21:02:11.044372 I  Current MythTV Schema Version (DBSchemaVer): 1317
2016-06-25 21:02:11.050614 I  Loading fr translation for module mythfrontend
2016-06-25 21:02:11.068623 N  MythBackend: Starting up as the master server.
2016-06-25 21:02:11.114050 I  TVRec[1]:
SetRecordingStatus(Inconnu->Inconnu) on line 157
2016-06-25 21:02:11.115839 I  TVRec[1]: GetStartChannel(1, 'DVBInput')
2016-06-25 21:02:11.123796 I  TVRec[1]: Start channel: 2.
2016-06-25 21:02:11.123912 I  TVRec[1]: CreateChannel(2)
2016-06-25 21:02:11.146557 I  Added logging to mythlogserver at TCP:35327
2016-06-25 21:02:11.201562 I  DVBChan[1](/dev/dvb/adapter0/frontend0):
Opening DVB channel
2016-06-25 21:02:11.252759 I  DVBChan[1](/dev/dvb/adapter0/frontend0):
Using DVB card /dev/dvb/adapter0/frontend0, with frontend 'DiBcom
7000PC'.
2016-06-25 21:02:11.272954 I  ChannelBase[1]: Input #10: 'DVBInput'
schan(2) sourceid(1) ccid(1)
2016-06-25 21:02:11.273000 I  ChannelBase[1]: Current Input #10: 'DVBInput'
2016-06-25 21:02:11.274438 I  DTVChan[1](/dev/dvb/adapter0/frontend0):
SetChannelByString(2):
2016-06-25 

Re: Digital Devices CI adapter problem

[Devin Heitmueller]

On Wed, Jun 8, 2016 at 4:10 PM, Marcin Kałuża
<marcin.kal...@trioptimum.com> wrote:
> Hello!
> I'm looking for someone who was able to successfully use Octopus Dual
> CI bridge by Digital Devices under Linux. We got it _almost_ working -
> we have a strange problem of the module dropping TS packets in sets of
> 30-33 packets rather randomly and this corrupts the whole stream.
>
> Their support ignored the ticket so far
> (http://support.digital-devices.eu/ticket.php?track=UG1-B42-NSGV=marcin.kaluza%40trioptimum.com=51010)
> and we're slowly running out of options.
>
> We've tried rebuilding the module using streaming dma api
> (DDB_ALT_DMA), we changed the kernel (our 3.18.22 and 4.2.3 from FC
> 23), disabled smp, still the same.
>
> Strange things happen when I call read() to get data back from CI, if
> I use any other buffer size then their internal dma buffer (672*188),
> I sometimes get the data not in order I wrote them (we use test TS
> stream with a counter inside ts payload), and the strangest of all -
> if I use bigger buffer (i.e. 1000*188), read() always returns that
> value (188000), but actual amount of content in my read buffer vary
> greatly (although never exeeds their buffer size of 672*188) - we
> clear the read buffer before each read so we know how much data was
> actually read. That's probably a bug, but I have no idea how can this
> even happen (their code
> (https://github.com/DigitalDevices/dddvb/blob/master/ddbridge/ddbridge-core.c#L772)
> looks quite ok as for my not so great knowledge of linux kernel driver
> coding). Has anyone encountered similar problems? It looks like a race
> condition of some sort, but I was unable find/fix it.
>
> I'll be most grateful for any reply/suggestions/help...
> Martin

This mailing list generally isn't for vendors' out-of-kernel drivers.
If Digital Devices wants to not be responsive to users who bought
their products and wants the community to provide free tech support
for their devices, they should get their drivers merged upstream.  :-)

That said, the math in ddb_input_read() looks pretty wonky.  The fact
that it always returns count (i.e. the size of the buffer provided
from userland), without taking into account how much data is actually
in the ring buffer certainly looks wrong.  If there isn't enough data
available, it should return the amount of data that *is* available,
not the size of the buffer passed in from userland.

I would add some more logging to that routine and see what's going on.
You'll probably have to take some time to understand what the actual
buffer filling algorithm is supposed to be for that hardware in order
to figure out what's going wrong.

Devin

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

Digital Devices CI adapter problem

[Marcin Kałuża]

Hello!
I'm looking for someone who was able to successfully use Octopus Dual
CI bridge by Digital Devices under Linux. We got it _almost_ working -
we have a strange problem of the module dropping TS packets in sets of
30-33 packets rather randomly and this corrupts the whole stream.

Their support ignored the ticket so far
(http://support.digital-devices.eu/ticket.php?track=UG1-B42-NSGV=marcin.kaluza%40trioptimum.com=51010)
and we're slowly running out of options.

We've tried rebuilding the module using streaming dma api
(DDB_ALT_DMA), we changed the kernel (our 3.18.22 and 4.2.3 from FC
23), disabled smp, still the same.

Strange things happen when I call read() to get data back from CI, if
I use any other buffer size then their internal dma buffer (672*188),
I sometimes get the data not in order I wrote them (we use test TS
stream with a counter inside ts payload), and the strangest of all -
if I use bigger buffer (i.e. 1000*188), read() always returns that
value (188000), but actual amount of content in my read buffer vary
greatly (although never exeeds their buffer size of 672*188) - we
clear the read buffer before each read so we know how much data was
actually read. That's probably a bug, but I have no idea how can this
even happen (their code
(https://github.com/DigitalDevices/dddvb/blob/master/ddbridge/ddbridge-core.c#L772)
looks quite ok as for my not so great knowledge of linux kernel driver
coding). Has anyone encountered similar problems? It looks like a race
condition of some sort, but I was unable find/fix it.

I'll be most grateful for any reply/suggestions/help...
Martin
--
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: netup_unidvb CI problem

[Saso Slavicic]

Another bug in the driver.
According to Netup 2014 drivers, the attributes should be read from _config
not _io

--- drivers/media/pci/netup_unidvb/netup_unidvb_ci.c.orig   2016-05-28
17:16:07.073608043 +0200
+++ drivers/media/pci/netup_unidvb/netup_unidvb_ci.c2016-05-28
17:16:33.970418997 +0200
@@ -147,7 +147,7 @@
 {
struct netup_ci_state *state = en50221->data;
struct netup_unidvb_dev *dev = state->dev;
-   u8 val = *((u8 __force *)state->membase8_io + addr);
+   u8 val = *((u8 __force *)state->membase8_config + addr);
 
dev_dbg(>pci_dev->dev,
"%s(): addr=0x%x val=0x%x\n", __func__, addr, val);
@@ -162,7 +162,7 @@
 
dev_dbg(>pci_dev->dev,
"%s(): addr=0x%x data=0x%x\n", __func__, addr, data);
-   *((u8 __force *)state->membase8_io + addr) = data;
+   *((u8 __force *)state->membase8_config + addr) = data;
return 0;
 }


# rmmod netup_unidvb
# insmod netup-unidvb-vanilla.ko
# dmesg | grep dvb_ca
[ 3997.014209] dvb_ca adapter 1: Invalid PC card inserted :(
[ 3997.691264] dvb_ca adapter 0: Invalid PC card inserted :(
# rmmod netup-unidvb
# insmod netup-unidvb-patched.ko
# dmesg | grep dvb_ca
[ 4030.205352] dvb_ca adapter 1: DVB CAM detected and initialised
successfully
[ 4030.476391] dvb_ca adapter 0: DVB CAM detected and initialised
successfully

Cheers,
Saso Slavicic

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

netup_unidvb CI problem

[Saso Slavicic]

Hi,

I have a problem with CI slots on NetUP Dual DVB Universal CI card.  Running
kernel-ml 4.4 on Centos 7 produces the following error:

[765846.415719] netup_unidvb :11:00.0: DVB init done, num=1
[765846.415721] dvb_ca_en50221_init
[765846.415804] DVB: register adapter0/ca0 @ minor: 24 (0x18)
[765846.415893] netup_unidvb :11:00.0: netup_unidvb_ci_register(): CI
adapter 0 init done
[765846.415895] dvb_ca_en50221_thread
[765846.415901] dvb_ca_en50221_init
[765846.416081] DVB: register adapter1/ca0 @ minor: 25 (0x19)
[765846.417708] netup_unidvb :11:00.0: netup_unidvb_ci_register(): CI
adapter 1 init done
[765846.417710] dvb_ca_en50221_thread
[765846.417719] netup_unidvb :11:00.0: netup_unidvb_dma_init(): starting
DMA0
[765846.417727] netup_unidvb :11:00.0: netup_unidvb_dma_init(): DMA0
buffer virt/phys 0x880073f0/0x73f0 size 192512
[765847.417870] netup_unidvb :11:00.0: netup_unidvb_dma_init(): starting
DMA1
[765847.417878] netup_unidvb :11:00.0: netup_unidvb_dma_init(): DMA1
buffer virt/phys 0x880073f2f000/0x73f2f000 size 192512
[765848.418819] netup_unidvb:netup_unidvb_dma_enable:190: netup_unidvb
:11:00.0: netup_unidvb_dma_enable(): DMA0 enable 0
[765848.418827] netup_unidvb:netup_unidvb_dma_enable:190: netup_unidvb
:11:00.0: netup_unidvb_dma_enable(): DMA1 enable 0
[765848.418831] netup_unidvb :11:00.0: netup_unidvb: device has been
initialized
[765851.415671] netup_unidvb:netup_unidvb_poll_ci_slot_status:132:
netup_unidvb :11:00.0: netup_unidvb_poll_ci_slot_status():
CAM_CTRLSTAT_READ_SET=0x1a1a
[765851.415682] netup_unidvb:netup_unidvb_poll_ci_slot_status:132:
netup_unidvb :11:00.0: netup_unidvb_poll_ci_slot_status():
CAM_CTRLSTAT_READ_SET=0x1a1a
[765851.415691] netup_unidvb:netup_unidvb_ci_slot_reset:100: netup_unidvb
:11:00.0: netup_unidvb_ci_slot_reset(): CAM_CTRLSTAT_READ_SET=0x1a1a
[765851.415695] netup_unidvb:netup_unidvb_ci_slot_reset:105: netup_unidvb
:11:00.0: netup_unidvb_ci_slot_reset(): waiting for reset
[765851.416651] netup_unidvb:netup_unidvb_poll_ci_slot_status:132:
netup_unidvb :11:00.0: netup_unidvb_poll_ci_slot_status():
CAM_CTRLSTAT_READ_SET=0x1a0e
[765851.416662] netup_unidvb:netup_unidvb_poll_ci_slot_status:132:
netup_unidvb :11:00.0: netup_unidvb_poll_ci_slot_status():
CAM_CTRLSTAT_READ_SET=0x1a0e
[765851.416671] netup_unidvb:netup_unidvb_ci_slot_reset:100: netup_unidvb
:11:00.0: netup_unidvb_ci_slot_reset(): CAM_CTRLSTAT_READ_SET=0x1a0e
[765851.416675] netup_unidvb:netup_unidvb_ci_slot_reset:105: netup_unidvb
:11:00.0: netup_unidvb_ci_slot_reset(): waiting for reset
[765851.536622] netup_unidvb:netup_unidvb_poll_ci_slot_status:132:
netup_unidvb :11:00.0: netup_unidvb_poll_ci_slot_status():
CAM_CTRLSTAT_READ_SET=0x1a8a
[765851.536631] netup_unidvb:netup_unidvb_ci_read_attribute_mem:153:
netup_unidvb :11:00.0: netup_unidvb_ci_read_attribute_mem(): addr=0x0
val=0x4
[765851.536636] netup_unidvb:netup_unidvb_ci_read_attribute_mem:153:
netup_unidvb :11:00.0: netup_unidvb_ci_read_attribute_mem(): addr=0x2
val=0x0
[765851.536638] TUPLE type:0x4 length:0
[765851.536642] netup_unidvb:netup_unidvb_poll_ci_slot_status:132:
netup_unidvb :11:00.0: netup_unidvb_poll_ci_slot_status():
CAM_CTRLSTAT_READ_SET=0x1a8a
[765851.536645] dvb_ca adapter 1: Invalid PC card inserted :(
[765851.636603] netup_unidvb:netup_unidvb_poll_ci_slot_status:132:
netup_unidvb :11:00.0: netup_unidvb_poll_ci_slot_status():
CAM_CTRLSTAT_READ_SET=0x1a8a
[765851.736601] netup_unidvb:netup_unidvb_poll_ci_slot_status:132:
netup_unidvb :11:00.0: netup_unidvb_poll_ci_slot_status():
CAM_CTRLSTAT_READ_SET=0x1a8a
[765851.836599] netup_unidvb:netup_unidvb_poll_ci_slot_status:132:
netup_unidvb :11:00.0: netup_unidvb_poll_ci_slot_status():
CAM_CTRLSTAT_READ_SET=0x1a8a
[765851.936590] netup_unidvb:netup_unidvb_poll_ci_slot_status:132:
netup_unidvb :11:00.0: netup_unidvb_poll_ci_slot_status():
CAM_CTRLSTAT_READ_SET=0x1a8a
[765852.036583] netup_unidvb:netup_unidvb_poll_ci_slot_status:132:
netup_unidvb :11:00.0: netup_unidvb_poll_ci_slot_status():
CAM_CTRLSTAT_READ_SET=0x1a8a
[765852.136611] netup_unidvb:netup_unidvb_poll_ci_slot_status:132:
netup_unidvb :11:00.0: netup_unidvb_poll_ci_slot_status():
CAM_CTRLSTAT_READ_SET=0x1a1a
[765852.210627] netup_unidvb:netup_unidvb_poll_ci_slot_status:132:
netup_unidvb :11:00.0: netup_unidvb_poll_ci_slot_status():
CAM_CTRLSTAT_READ_SET=0x1a1a
[765852.210635] netup_unidvb:netup_unidvb_ci_read_attribute_mem:153:
netup_unidvb :11:00.0: netup_unidvb_ci_read_attribute_mem(): addr=0x0
val=0x1d
[765852.210640] netup_unidvb:netup_unidvb_ci_read_attribute_mem:153:
netup_unidvb :11:00.0: netup_unidvb_ci_read_attribute_mem(): addr=0x2
val=0x0
[765852.210641] TUPLE type:0x1d length:0
[765852.210646] netup_unidvb:netup_unidvb_ci_read_attribute_mem:153:
netup_unidvb :11:00.0: netup_unidvb_ci_read_attribute_mem(): addr=0x4
val=0x0
[765852.210650

Re: Problem since commit c73bbaa4ec3e [rc-core: don't lock device at rc_register_device()]

[Mauro Carvalho Chehab]

Em Sat, 27 Feb 2016 22:42:24 +0100
Heiner Kallweit <hkallwe...@gmail.com> escreveu:

> Am 27.02.2016 um 20:50 schrieb Mauro Carvalho Chehab:
> > Em Sat, 27 Feb 2016 19:39:16 +0100
> > Heiner Kallweit <hkallwe...@gmail.com> escreveu:
> >   
> >> Am 27.02.2016 um 19:05 schrieb Mauro Carvalho Chehab:  
> >>> Em Sat, 27 Feb 2016 17:10:41 +0100
> >>> Heiner Kallweit <hkallwe...@gmail.com> escreveu:
> >>> 
> >>>> Am 27.02.2016 um 13:14 schrieb Heiner Kallweit:
> >>>>> Since this commit I see the following error when the Nuvoton RC driver 
> >>>>> is loaded:
> >>>>>
> >>>>> input: failed to attach handler kbd to device input3, error: -22
> >>>>>
> >>>>> Error 22 (EINVAL) comes from the new check in rc_open().
> >>>>>   
> >>>>
> >>>> Complete call chain seems to be:
> >>>>   rc_register_device
> >>>>   input_register_device
> >>>>   input_attach_handler
> >>>>   kbd_connect
> >>>>   input_open_device
> >>>>   ir_open
> >>>>   rc_open
> >>>>
> >>>> rc_register_device calls input_register_device before dev->initialized = 
> >>>> true,
> >>>> therefore the new check in rc_open fails. At a first glance I'd say that 
> >>>> we have
> >>>> to remove this check from rc_open.
> >>>
> >>> Hmm... maybe we could, instead, do:
> >>>
> >>>   if (!rdev->initialized) {
> >>>   rval = -ERESTARTSYS;
> >>>   goto unlock;
> >>>   }
> >>> 
> >> Looking at the source code of the functions in the call chain I see no 
> >> special
> >> handling of ERESTARTSYS. It's treated like any other error, therefore I 
> >> don't
> >> think this helps.  
> > 
> > The expected behavior is that the Kernel syscall code to handle ERESTARTSYS
> > internally, and either return EAGAIN to userspace, or try again until
> > it succeeds, depending on the open mode.
> >   
> I tested it and returning ERESTARTSYS instead of EINVAL doesn't help.
> The behavior is the same.
> As far as I can see no syscall code is involved in this call chain.
> 
> > So, it seems a worth trial.

Yeah, this didn't work. The problem is that rc_open can be called too
early, by the time the input device got registered.

I have a patch for it. Will send on a separate e-mail

Yet, there's something still not right: after removing nuvoton_cir, 
a new modprobe to the driver causes a dead lock:

[  242.151822] INFO: task modprobe:2599 blocked for more than 120 seconds.
[  242.151952]   Not tainted 4.5.0-rc3+ #49
[  242.151955] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this 
message.
[  242.151958] modprobeD 8803b1037610 0  2599   2598 0x
[  242.151964]  8803b1037610 82aa27f8 8803b10375c8 
812404fa
[  242.151970]  0282 8803bf076340 8803c689f258 

[  242.151975]  8803c2198000 8803bf076000 8803b103 
ed0076206001
[  242.151981] Call Trace:
[  242.151988]  [] ? trace_hardirqs_on_caller+0x40a/0x590
[  242.151992]  [] schedule+0x9c/0x1c0
[  242.151996]  [] __request_region+0x2c2/0x440
[  242.152002]  [] ? free_resource+0x180/0x180
[  242.152005]  [] ? is_module_address+0x15/0x30
[  242.152009]  [] ? static_obj+0x33/0x50
[  242.152012]  [] ? lockdep_init_map+0xf0/0x1470
[  242.152016]  [] ? wake_up_q+0xe0/0xe0
[  242.152023]  [] nvt_probe+0x518/0x26a0 [nuvoton_cir]
[  242.152031]  [] ? compare_pnp_id+0x90/0x210
[  242.152041]  [] ? nvt_tx_ir+0x3f0/0x3f0 [nuvoton_cir]
[  242.152047]  [] pnp_device_probe+0x125/0x1f0
[  242.152054]  [] driver_probe_device+0x21a/0xc30
[  242.152060]  [] ? driver_probe_device+0xc30/0xc30
[  242.152066]  [] __driver_attach+0x121/0x160
[  242.152072]  [] bus_for_each_dev+0x11f/0x1a0
[  242.152077]  [] ? subsys_dev_iter_exit+0x10/0x10
[  242.152083]  [] ? _raw_spin_unlock+0x27/0x40
[  242.152089]  [] driver_attach+0x3d/0x50
[  242.152095]  [] bus_add_driver+0x4c9/0x770
[  242.152101]  [] ? 0xa0cd
[  242.152107]  [] ? 0xa0cd
[  242.152112]  [] driver_register+0x18c/0x3b0
[  242.152119]  [] pnp_register_driver+0x75/0xa0
[  242.152126]  [] nvt_driver_init+0x10/0x1000 [nuvoton_cir]
[  242.152132]  [] do_one_initcall+0x141/0x300
[  242.152138]  [] ? try_to_run_init_process+0x40/0x40
[  242.152145]  [] ? kasan_unpoison_shadow+0x36/0x50
[  242.152150]  [] ? kasan_unpoison_shadow+0x36/0x50
[  242.152156]  [] ? __asan_r

Re: Sabrent (stk1160) / Easycap driver problem

[Ezequiel Garcia]

Hi Philippe,

On 20 December 2015 at 20:32, Philippe Desrochers
<desrochers.phili...@gmail.com> wrote:
> Hello Ezequiel,
>
> I tested with saa7115.c and the problem is in the "saa711x_detect_chip"
> function.
> In fact, the CJC7113 chip seems to returns all '1' when reading register 0.
>  ("" found @ 0x4a (stk1160)))
>
> I made a test by returning "SAA7113" without taking care of the value read
> from the CJC7113.
> By doing that, I was able to make the device work with VLC in Ubuntu 14.04.
>

That's good news, isn't it?

> I tried to find the datasheet of this CJC7113 chip but it does not seems to
> be available on the web.
>
> I will contact Sabrent for support and datasheet.
> If I get some positive response I think I will patch the driver otherwise I
> will select another dongle.
>

FWIW, I believe a patch to make CJC7113 detected as SAA7113 would
be acceptable.
-- 
Ezequiel García, VanguardiaSur
www.vanguardiasur.com.ar
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: problem with coda when running qt-gstreamer and video reaches its end (resending in plain text)

[Piotr Lewicki]

Thank you,
I updated GStreamer to version 1.6.1 and applied patches from Nicolas 
(https://bugzilla.gnome.org/show_bug.cgi?id=733864).

This resolved the issue witch "CODA PIC_RUN timeout".

At the moment situation looks a little bit different:
1. Playing flv videos (video codec: Sorenson Spark Video) allows me to 
play multiple videos and EOS message is received.


2. Playing h264 videos with lower resolution runs smoothly (no CODA 
PIC_RUN timeout) but when video reaches it's end - no message is 
reaching the qt application and thus I can only stop it manually.
* Is there a resolution of this problem with missing end-of-stream 
detection?


3. When playing h264 videos in HD resolution (tested with 
big_buck_bunny_1080p_h264.mov) the problem with "CODA PIC_RUN timeout" 
still occurs with small difference - when I press STOP "CODA PIC_RUN 
timeout" messages don't show up anymore while before they were showing 
up repeatedly (every second) until my qt application stopped.
- Another strange behaviour is that after I get "coda 204.vpu: 
failed to allocate bitstream ringbuffer" message -> the video starts 
running again (when I press PLAY) and it starts detecting end-of-stream 
(!) - see attached file



> # [ 3049.161708] coda 204.vpu: dma_alloc_coherent of size 3133440 failed
> # "Failed to allocate required memory."

That shouldn't happen anymore in recent kernels. In the past, repeated
reqbufs calls would leak buffers because the cleanup was only done on
close.


Dear Phillip,
Unfortunately I'm using i.MX6 device so kernel provided by Freescale is 
v3.14 and I am using kernel provided by Phytec company which is based on 
mainline but the newest version is 3.19 and I cannot upgrade it.


I have already came upon some patches you provided:
starting with 
https://www.mail-archive.com/linux-media@vger.kernel.org/msg77439.html 
and another pack starting with 
http://www.spinics.net/lists/linux-media/msg91575.html
but I think that some of these are dependent on other components like 
e.g. "[PATCH 07/10] [media] coda: drop custom list of pixel format 
descriptions".


* Is there a possibility for you to give me a list of patches to apply 
(and maybe dependent packages) so I can try to apply them manually?

I hope it's not too much too ask..

Best regards
Piotr Lewicki

On 16.12.2015 22:49, Nicolas Dufresne wrote:

Le mercredi 16 décembre 2015 à 15:49 +0100, Philipp Zabel a écrit :

# [ 1382.828875] coda 204.vpu: CODA PIC_RUN timeout
# [ 1383.938704] coda 204.vpu: CODA PIC_RUN timeout
  
The video is stopped but I can see last frame on the screen although in

qt application it should receive end-of-stream message and stop the
video (resulting with black screen).

Looks like the coda driver is constantly fed empty buffers, which don't
increase the bitstream payload level, and the PIC_RUN times out with a
bitstream buffer underflow. What GStreamer version is this?

I believe this is side effect of how the MFC driver worked in it's
early stage. We had to keep pushing empty buffer to drain the driver.
So GStreamer still poll/queue/poll/queue/... until all capture buffers
are received. I notice recently that this behaviour can induce high CPU
load with some other drivers that don't do any active wait when a empty
buffer is queued. I would therefor suggest to change this code to only
push one empty buffer for your use case. An submitted patch to support
CMD_STOP can be found here, though is pending a re-submition by it's
author.

https://bugzilla.gnome.org/show_bug.cgi?id=733864

For proper EOS detection with CODA driver (using EPIPE return value),
you indeed need GStreamer 1.6+.

cheers,
Nicolas


root@phyflex-imx6-2:~# qmlplayer2 file:///.videos/big_buck_bunny_1080p_h264.mov 
QML debugging is enabled. Only use this in a safe environment.ny_1080p_h264.mov  
QEglFSImx6Hooks will set environment variable FB_MULTI_BUFFER=2 to enable double buffering and vsync.
 If this is not desired, you can override this via: export QT_EGLFS_IMX6_NO_FB_MULTI_BUFFER=1
Unable to query physical screen size, defaulting to 100 dpi.
To override, set QT_QPA_EGLFS_PHYSICAL_WIDTH and QT_QPA_EGLFS_PHYSICAL_HEIGHT (in millimeters).
** PLAY **
** video runs **
[ 2022.118671] coda 204.vpu: CODA PIC_RUN timeout
[ 2023.118647] coda 204.vpu: CODA PIC_RUN timeout
[ 2024.118645] coda 204.vpu: CODA PIC_RUN timeout
[ 2025.118730] coda 204.vpu: CODA PIC_RUN timeout
[ 2026.118638] coda 204.vpu: CODA PIC_RUN timeout
[ 2027.118640] coda 204.vpu: CODA PIC_RUN timeout
[ 2028.118723] coda 204.vpu: CODA PIC_RUN timeout
[ 2029.118641] coda 204.vpu: CODA PIC_RUN timeout
[ 2030.118638] coda 204.vpu: CODA PIC_RUN timeout
[ 2031.118582] coda 204.vpu: CODA PIC_RUN timeout
[ 2032.118651] coda 204.vpu: CODA PIC_RUN timeout
[ 2033.118576] coda 204.vpu: CODA PIC_RUN timeout
[ 2034.118582] coda 204.vpu: CODA PIC_RUN timeout
[ 2035.11859

Re: problem with coda when running qt-gstreamer and video reaches its end (resending in plain text)

[Nicolas Dufresne]

Le mercredi 16 décembre 2015 à 15:49 +0100, Philipp Zabel a écrit :
> > # [ 1382.828875] coda 204.vpu: CODA PIC_RUN timeout
> > # [ 1383.938704] coda 204.vpu: CODA PIC_RUN timeout
> > 
> > The video is stopped but I can see last frame on the screen although in 
> > qt application it should receive end-of-stream message and stop the 
> > video (resulting with black screen).
> 
> Looks like the coda driver is constantly fed empty buffers, which don't
> increase the bitstream payload level, and the PIC_RUN times out with a
> bitstream buffer underflow. What GStreamer version is this?

I believe this is side effect of how the MFC driver worked in it's
early stage. We had to keep pushing empty buffer to drain the driver.
So GStreamer still poll/queue/poll/queue/... until all capture buffers
are received. I notice recently that this behaviour can induce high CPU
load with some other drivers that don't do any active wait when a empty
buffer is queued. I would therefor suggest to change this code to only
push one empty buffer for your use case. An submitted patch to support
CMD_STOP can be found here, though is pending a re-submition by it's
author.

https://bugzilla.gnome.org/show_bug.cgi?id=733864

For proper EOS detection with CODA driver (using EPIPE return value),
you indeed need GStreamer 1.6+.

cheers,
Nicolas

signature.asc
Description: This is a digitally signed message part

problem with coda when running qt-gstreamer and video reaches its end (resending in plain text)

[Piotr Lewicki]

Hello,
I'm running an application that plays video on an embedded device. It 
uses Qt5.4 and qt-gstreamer plugin and it runs on imx6q processor with 
yocto based linux (kernel version 3.19.5).
When I built a sample from this qt-gstreamer package called qmlplayer2 
and used it to play video I came across following problem:


1. When video reaches it's end I start receiving kernel ringbuffer message:
# [ 1371.618854] coda 204.vpu: CODA PIC_RUN timeout
# [ 1372.618713] coda 204.vpu: CODA PIC_RUN timeout
# [ 1373.618653] coda 204.vpu: CODA PIC_RUN timeout
# [ 1374.618872] coda 204.vpu: CODA PIC_RUN timeout
# [ 1375.618712] coda 204.vpu: CODA PIC_RUN timeout
# [ 1376.618707] coda 204.vpu: CODA PIC_RUN timeout
# [ 1377.618860] coda 204.vpu: CODA PIC_RUN timeout
# [ 1378.738700] coda 204.vpu: CODA PIC_RUN timeout
# [ 1379.738632] coda 204.vpu: CODA PIC_RUN timeout
# [ 1380.828872] coda 204.vpu: CODA PIC_RUN timeout
# [ 1381.828697] coda 204.vpu: CODA PIC_RUN timeout
# [ 1382.828875] coda 204.vpu: CODA PIC_RUN timeout
# [ 1383.938704] coda 204.vpu: CODA PIC_RUN timeout

The video is stopped but I can see last frame on the screen although in 
qt application it should receive end-of-stream message and stop the 
video (resulting with black screen).


2. If I don't terminate the application and several times press "stop" 
and "play" video I get message:


# [ 3041.650483] coda 204.vpu: dma_alloc_coherent of size 3133440 failed
# [ 3044.205362] coda 204.vpu: dma_alloc_coherent of size 3133440 failed
# [ 3044.214711] coda 204.vpu: dma_alloc_coherent of size 3133440 failed
# [ 3047.189317] coda 204.vpu: dma_alloc_coherent of size 3133440 failed
# [ 3047.196056] coda 204.vpu: dma_alloc_coherent of size 3133440 failed

and finally

# [ 3049.161708] coda 204.vpu: dma_alloc_coherent of size 3133440 failed
# "Failed to allocate required memory."

Video is not playing here and CODA PIC_RUN timeout message shows up 
every second.


- Depending on the type of video I'm playing the step 2 differs.
What I wrote above is true for playing matroska format (mkv) file.
When I use h264 I receive:

# [  322.610658] coda 204.vpu: Failed to allocate fb2 buffer of size 
537600

# [ 322.619083] coda 204.vpu: failed to allocate framebuffers

# [ 327.656542] coda 204.vpu: Failed to allocate fb0 buffer of size 
537600

# [ 327.663513] coda 204.vpu: failed to allocate framebuffers

Or

# [ 723.496813] coda 204.vpu: Failed to allocate workbuf buffer of 
size 606208

# [ 723.504122] coda 204.vpu: failed to allocate 0 byte context buffer

# [ 731.524607] coda 204.vpu: Failed to allocate slicebuf buffer of 
size 480512

# [ 731.532018] coda 204.vpu: failed to allocate 0 byte slice buffer

# [ 734.793931] coda 204.vpu: dma_alloc_coherent of size 462848 failed
# [ 734.800771] coda 204.vpu: dma_alloc_coherent of size 462848 failed
# "Failed to allocate required memory."

Or

# [ 2793.514984] coda 204.vpu: Failed to allocate fb0 buffer of size 
537600

# [ 2793.521961] coda 204.vpu: failed to allocate framebuffers
# [ 2793.596919] coda 204.vpu: failed to allocate bitstream ringbuffer

3. One more "stop" and "play" outputs with:
# [ 3050.530538] coda 204.vpu: failed to allocate bitstream ringbuffer

But here the video starts playing again and when it reaches the end- the 
end-of-stream message is received in the Qt application.


Ocasionally after playing many videos this way and shutting down the 
application I receive kernel oops or probable deadlock warning (both 
attached in this mail).




I'm pretty sure that the problem resides in the coda driver but 
unfortunately I'm newbie in kernel drivers development area and cannot 
resolve it myself.


Have you ever came across similar problem?
Do you think you could help me with that?

Best regards,
Piotr Lewicki


[ 1687.508917] ==
[ 1687.515103] [ INFO: possible circular locking dependency detected ]
[ 1687.521379] 3.19.5-iMX6-PD15.2.0 #1 Not tainted
[ 1687.525916] ---
[ 1687.532189] kworker/u8:2/74 is trying to acquire lock:
[ 1687.537333]  (>s_type->i_mutex_key){+.+.+.}, at: [<802748c8>] 
debugfs_remove+0x40/0x80
[ 1687.545691]
[ 1687.545691] but task is already holding lock:
[ 1687.551530]  (>coda_mutex){+.+.+.}, at: [<7f08903c>] 
coda_seq_end_work+0x38/0xf4 [coda]
[ 1687.560068]
[ 1687.560068] which lock already depends on the new lock.
[ 1687.560068]
[ 1687.568254]
[ 1687.568254] the existing dependency chain (in reverse order) is:
[ 1687.575742]
-> #3 (>coda_mutex){+.+.+.}:
[ 1687.580341][<806de3b8>] mutex_lock_nested+0x54/0x3e8
[ 1687.586037][<7f08b4cc>] coda_start_decoding+0x28/0x44 [coda]
[ 1687.592426][<7f08613c>] coda_start_st

Re: problem with coda when running qt-gstreamer and video reaches its end (resending in plain text)

[Philipp Zabel]

Hi Piotr,

thank you for the report.

Am Mittwoch, den 16.12.2015, 14:09 +0100 schrieb Piotr Lewicki:
> Hello,
> I'm running an application that plays video on an embedded device. It 
> uses Qt5.4 and qt-gstreamer plugin and it runs on imx6q processor with 
> yocto based linux (kernel version 3.19.5).

First, could you repeat this using current versions of the coda driver
and GStreamer? There are about 60 coda patches in mainline between v3.19
and v4.3, and some of them are quite relevant for the end-of-stream and
buffer handling. I think the relevant GStreamer EOS change went into
1.5.2.

> When I built a sample from this qt-gstreamer package called qmlplayer2 
> and used it to play video I came across following problem:
> 
> 1. When video reaches it's end I start receiving kernel ringbuffer message:
> # [ 1371.618854] coda 204.vpu: CODA PIC_RUN timeout
> # [ 1372.618713] coda 204.vpu: CODA PIC_RUN timeout
> # [ 1373.618653] coda 204.vpu: CODA PIC_RUN timeout
> # [ 1374.618872] coda 204.vpu: CODA PIC_RUN timeout
> # [ 1375.618712] coda 204.vpu: CODA PIC_RUN timeout
> # [ 1376.618707] coda 204.vpu: CODA PIC_RUN timeout
> # [ 1377.618860] coda 204.vpu: CODA PIC_RUN timeout
> # [ 1378.738700] coda 204.vpu: CODA PIC_RUN timeout
> # [ 1379.738632] coda 204.vpu: CODA PIC_RUN timeout
> # [ 1380.828872] coda 204.vpu: CODA PIC_RUN timeout
> # [ 1381.828697] coda 204.vpu: CODA PIC_RUN timeout
> # [ 1382.828875] coda 204.vpu: CODA PIC_RUN timeout
> # [ 1383.938704] coda 204.vpu: CODA PIC_RUN timeout
> 
> The video is stopped but I can see last frame on the screen although in 
> qt application it should receive end-of-stream message and stop the 
> video (resulting with black screen).

Looks like the coda driver is constantly fed empty buffers, which don't
increase the bitstream payload level, and the PIC_RUN times out with a
bitstream buffer underflow. What GStreamer version is this?

> 2. If I don't terminate the application and several times press "stop" 
> and "play" video I get message:
> 
> # [ 3041.650483] coda 204.vpu: dma_alloc_coherent of size 3133440 failed
> # [ 3044.205362] coda 204.vpu: dma_alloc_coherent of size 3133440 failed
> # [ 3044.214711] coda 204.vpu: dma_alloc_coherent of size 3133440 failed
> # [ 3047.189317] coda 204.vpu: dma_alloc_coherent of size 3133440 failed
> # [ 3047.196056] coda 204.vpu: dma_alloc_coherent of size 3133440 failed
> 
> and finally
> 
> # [ 3049.161708] coda 204.vpu: dma_alloc_coherent of size 3133440 failed
> # "Failed to allocate required memory."

That shouldn't happen anymore in recent kernels. In the past, repeated
reqbufs calls would leak buffers because the cleanup was only done on
close.

Please let me know if you can reproduce any of the issues with more
recent kernels and GStreamer 1.6.

regards
Philipp

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

[Fwd: Problem with avermedia Volar Black HD (af9015) : recognised but not scanning]

[Olivier Devaux]

Hello,

Any ideas on my problem ? Am I on the right mailing-list ?

Any help would be appreciated !

Thanks,
OD

 Message transféré 
> De: oddebian <oddeb...@gmail.com>
> À: linux-media@vger.kernel.org
> Objet: Problem with avermedia Volar Black HD (af9015) : recognised but
> not scanning
> Date: Thu, 03 Dec 2015 19:23:28 +0100
> 
> Hi,
> 
> I have an old avermedia Volar Black HD (af9015) that still works pretty
> well in windows 8 (it scans the whole dvb-t muxes in less than one
> minute and the image is perfect even in HD).
> When I try it on linux, it takes 12 minutes to scan with w_scan, and
> despite showing lines such as :
> updating transponder:
>(QAM_64   f = 4294967 kHz I999B8C999D0T8G32Y0) 0x405A
> to (QAM_64   f = 4294967 kHz I999B8C999D0T8G8Y0) 0x405A
> undefined coderate HP
> in the end, it says :
> 
> tune to: QAM_AUTO f = 482000 kHz I999B8C999D999T999G999Y999 
> (time: 12:13) --no signal--
> tune to: QAM_AUTO f = 482000 kHz I999B8C999D999T999G999Y999  (no signal)
> (time: 12:14) --no signal--
> tune to: QAM_64   f = 4294967 kHz I999B8C999D0T8G8Y0 
> (time: 12:16) skipped: (freq 4294967286 unsupported by driver)
> tune to: QAM_AUTO f = 482166 kHz I999B8C999D999T999G999Y999 
> (time: 12:16) --no signal--
> tune to: QAM_AUTO f = 482166 kHz I999B8C999D999T999G999Y999  (no signal)
> (time: 12:17) --no signal--
> 
> ERROR: Sorry - i couldn't get any working frequency/transponder
> Nothing to scan!!
> 
> 
> The problem is the same on my destop pc (debian 8, kernel
> 3.16.0-4-amd64) and on a Raspberry 1 (Linux osmc 4.2.3-3-osmc, or
> openelec).
> I tried also with tvheadend, but scan does not work either.
> 
> The firmware is correct and installed in /lib/firmware.
> Dmesg shows that the usb device is well detected, with no errors :
> [   13.846959] usb 1-5: dvb_usb_v2: found a 'AverMedia AVerTV Volar
> Black HD (A850)' in cold state
> [   13.847467] usb 1-5: firmware: direct-loading firmware
> dvb-usb-af9015.fw
> [   13.847474] usb 1-5: dvb_usb_v2: downloading firmware from file
> 'dvb-usb-af9015.fw'
> [   13.917176] usb 1-5: dvb_usb_v2: found a 'AverMedia AVerTV Volar
> Black HD (A850)' in warm state
> [   14.327175] usb 1-5: dvb_usb_v2: will pass the complete MPEG2
> transport stream to the software demuxer
> [   14.335086] usb 1-5: DVB: registering adapter 0 frontend 0 (Afatech
> AF9013)...
> [   14.345704] usb 1-5: dvb_usb_v2: 'AverMedia AVerTV Volar Black HD
> (A850)' successfully initialized and connected
> [   14.345795] usbcore: registered new interface driver dvb_usb_af9015
> 
> And lsusb :
> Bus 001 Device 003: ID 07ca:850a AVerMedia Technologies, Inc. AverTV
> Volar Black HD (A850)
> 
> I must say it is very frustrating to see a device still supported in
> windows 8, and working perfectly, but not working anymore in linux
> despite stated as supported in
> http://www.linuxtv.org/wiki/index.php/AVerTV_Volar_Black_HD_%28A850%29
> 
> Thanks in advance for any idea that could help !
> OD
> 


--
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: Sabrent (stk1160) / Easycap driver problem

[Ezequiel Garcia]

(shoot, we dropped the ML somewhere along the conversation)

>> On 7 December 2015 at 12:32, Philippe Desrochers
>>  wrote:
>> > Hello again,
>> >
>> > I open the device and I saw the following chips:
>> >
>> > SYNTEK:
>> > STK1160DLQG
>> > D7A155G-1513
>> >
>> > VIDEO DECODER:
>> > CJC7113
>> >
>> > AUDIO:
>> > ALC655
>> > 64231N1 L620D
>> >
>> > It seems the video decoder is a clone of the Philips SAA7113.
>> > Do you know if the CJC7113 is supported by the STK1160 linux driver ?
>> >
>>
>> It will probably work, being a clone of saa7113. But for some reason,
>> saa7115 is not detecting it. Maybe you can try to debug that and see
>> what's going on?


On 7 December 2015 at 14:45, Philippe Desrochers
 wrote:
> Yes, I will try. I'm still not very experienced with linux kernel/driver...
> I think I can manage that since I have a good background in embedded system
> (Microcontroller).
>
> In just few lines, can you tell me how the STK1160 and SA7115 are related to
> each other ?
> Can I see it as 2 independent modules ? (I mean with SA7115 loaded first and
> then STK1160 loaded after only if the first module is OK ?)
>

Sure. On the hardware side, stk1160 is the USB chipset, while the
saa7115-compatible IC is the analog video decoder chip. stk1160 and
saa7115 talk through a I2C bus that's in the capture card.

On the software side, we have a similar model: the stk1160 driver
deals with the USB data and the saa7115 driver talks to the decoder
chip (through the I2C bus). Since saa7115 talks through I2C, you'll
find it under drivers/media/i2c.

stk1160 creates a subdevice that is owned by saa7115 driver. The
latter knows there's a chip on some i2c address, and then probes for
the type if chip.

I believe probing is done on saa711x_detect_chip(). To support your
device, we may have to create a new supported model here:

enum saa711x_model {
SAA7111A,
SAA7111,
SAA7113,
GM7113C,
SAA7114,
SAA7115,
SAA7118,
};

If you grep GM7113C through the sources you'll be able to see how
differences between models are handled. Maybe your chip is not really
different from GM7113C or SAA7113 and all we need is to make sure it's
detected.

Don't hesitate to ask for more help over here.
-- 
Ezequiel García, VanguardiaSur
www.vanguardiasur.com.ar
--
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: Sabrent (stk1160) / Easycap driver problem

[Ezequiel Garcia]

On 5 December 2015 at 01:29, Philippe Desrochers
<desrochers.phili...@gmail.com> wrote:
> The difference seems to be around the "saa7113" chip. Maybe the Sabrent is
> using another video decoder chip ?

Yes, I believe that would explain the kernel log you sent.

> I will open one and check the chips on the PCB.
>

OK, that would help.

> Do you know if the stk1160 driver was working with this device (Sabrent
> USB-AVCPT) in the past ?
>

I've only seen generic "Easycap" labeled stk1160 devices
with either sa7115 or gm7113 decoder. Both of these are supported.c

See drivers/media/i2c/saa7115.c:saa711x_detect_chip for details on how
the decoder chip
is identified.

> Also, it seems the Sabrent USB-AVCPT is using the AC'97 Audio chip.
> Could it be the problem ?
>

Shouldn't affect.

> Do you know if there a firmware in the Syntek 1160 chip ?
>

There is not.
-- 
Ezequiel García, VanguardiaSur
www.vanguardiasur.com.ar
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: PROBLEM: UVC ioctl() freeze after device disconnection

[Laurent Pinchart]

Hi Matteo,

On Wednesday 02 December 2015 15:24:44 Matteo Foppiano wrote:
> Hi,
>  working with raspberry and UVC I've found this issue:
>   https://github.com/raspberrypi/linux/issues/1211
> 
> As you can see in the post, the problem seems to be upstream, so I'm
> writing directly to you. Hope this is correct.

That's fine. I've additionally CC'ed the linux-media mailing list.

When the device is disconnected the USB host controller driver is supposed to 
disable all endpoints, resulting in the URB completion handler 
uvc_video_complete() being called with the status set to -ESHUTDOWN. The 
driver will then call uvc_queue_cancel() to return all queued buffers to 
userspace. VIDIOC_DQBUF should then wake up and return.

>From the above link I assume you use an RPi kernel. The RPi USB host 
controller driver is known to be pretty unstable and buggy (at least the last 
time I checked) so it might not handle device disconnection properly.

The first step to debug this would be to check whether uvc_video_complete() 
gets called with a URB error status when you disconnect the device.

-- 
Regards,

Laurent Pinchart

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

Problem with avermedia Volar Black HD (af9015) : recognised but not scanning

[oddebian]

Hi,

I have an old avermedia Volar Black HD (af9015) that still works pretty
well in windows 8 (it scans the whole dvb-t muxes in less than one
minute and the image is perfect even in HD).
When I try it on linux, it takes 12 minutes to scan with w_scan, and
despite showing lines such as :
updating transponder:
   (QAM_64   f = 4294967 kHz I999B8C999D0T8G32Y0) 0x405A
to (QAM_64   f = 4294967 kHz I999B8C999D0T8G8Y0) 0x405A
undefined coderate HP
in the end, it says :

tune to: QAM_AUTO f = 482000 kHz I999B8C999D999T999G999Y999 
(time: 12:13) --no signal--
tune to: QAM_AUTO f = 482000 kHz I999B8C999D999T999G999Y999  (no signal)
(time: 12:14) --no signal--
tune to: QAM_64   f = 4294967 kHz I999B8C999D0T8G8Y0 
(time: 12:16) skipped: (freq 4294967286 unsupported by driver)
tune to: QAM_AUTO f = 482166 kHz I999B8C999D999T999G999Y999 
(time: 12:16) --no signal--
tune to: QAM_AUTO f = 482166 kHz I999B8C999D999T999G999Y999  (no signal)
(time: 12:17) --no signal--

ERROR: Sorry - i couldn't get any working frequency/transponder
Nothing to scan!!


The problem is the same on my destop pc (debian 8, kernel
3.16.0-4-amd64) and on a Raspberry 1 (Linux osmc 4.2.3-3-osmc, or
openelec).
I tried also with tvheadend, but scan does not work either.

The firmware is correct and installed in /lib/firmware.
Dmesg shows that the usb device is well detected, with no errors :
[   13.846959] usb 1-5: dvb_usb_v2: found a 'AverMedia AVerTV Volar
Black HD (A850)' in cold state
[   13.847467] usb 1-5: firmware: direct-loading firmware
dvb-usb-af9015.fw
[   13.847474] usb 1-5: dvb_usb_v2: downloading firmware from file
'dvb-usb-af9015.fw'
[   13.917176] usb 1-5: dvb_usb_v2: found a 'AverMedia AVerTV Volar
Black HD (A850)' in warm state
[   14.327175] usb 1-5: dvb_usb_v2: will pass the complete MPEG2
transport stream to the software demuxer
[   14.335086] usb 1-5: DVB: registering adapter 0 frontend 0 (Afatech
AF9013)...
[   14.345704] usb 1-5: dvb_usb_v2: 'AverMedia AVerTV Volar Black HD
(A850)' successfully initialized and connected
[   14.345795] usbcore: registered new interface driver dvb_usb_af9015

And lsusb :
Bus 001 Device 003: ID 07ca:850a AVerMedia Technologies, Inc. AverTV
Volar Black HD (A850)

I must say it is very frustrating to see a device still supported in
windows 8, and working perfectly, but not working anymore in linux
despite stated as supported in
http://www.linuxtv.org/wiki/index.php/AVerTV_Volar_Black_HD_%28A850%29

Thanks in advance for any idea that could help !
OD


--
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: Sabrent (stk1160) / Easycap driver problem

[Ezequiel Garcia]

On 2 December 2015 at 14:43, Philippe Desrochers
 wrote:
> I'm sending the email again (in plain text) since it seems it was blocked by
> the server.
>
> EASYCAP CHINA CLONE (OK):
> [ 8630.596236] usb 2-1: new high-speed USB device number 6 using ehci-pci
> [ 8630.729074] usb 2-1: New USB device found, idVendor=05e1, idProduct=0408
> [ 8630.729084] usb 2-1: New USB device strings: Mfr=1, Product=2,
> SerialNumber=0
> [ 8630.729091] usb 2-1: Product: USB 2.0 Video Capture Controller
> [ 8630.729097] usb 2-1: Manufacturer: Syntek Semiconductor
> [ 8630.729648] usb 2-1: New device Syntek Semiconductor USB 2.0 Video
> Capture Controller @ 480 Mbps (05e1:0408, interface 0, class 0)
> [ 8630.729656] usb 2-1: video interface 0 found
> [ 8631.242258] saa7115 7-0025: saa7113 found @ 0x4a (stk1160)

Hmm.. seems the bad device doesn't found a decoder chip. Let me
refresh my mind and get back to you.
-- 
Ezequiel García, VanguardiaSur
www.vanguardiasur.com.ar
--
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: Sabrent (stk1160) / Easycap driver problem

[Ezequiel Garcia]

Hi Philippe,

Ccing the linux-media ML. Please don't reply dropping the Cc!

2015-12-02 11:58 GMT-03:00 Philippe Desrochers :
> Hello Ezequiel,
>
> I'm using your stk1160 driver with some EasyCap (china) clone and it is
> working fine.
>
> However, a few days ago, I bought two Sabrent USB-AVCPT and both of them are
> not working with my Ubuntu 14.04 computer.
> http://www.sabrent.com/category/video-converters/USB-AVCPT/
>
> All of these devices have the Syntek 1160 chipset.
>
> Normally, I am using VLC to use these devices but with the Sabrent grabber I
> can't see the video/display window. (it just does not show)
>
> I also tried mplayer and it is giving me a "select timeout".
>
> See attached file for the "lsusb -vv" output.
>
> Can you give me some hint where to look for to fix this issue ?
> If needed, I can compile code or driver and do some tests.
>
> For now, I am a bit lost because I don't know where to start looking...
>

Can you paste the kernel log (dmesg output) in each case?


-- 
Ezequiel García, VanguardiaSur
www.vanguardiasur.com.ar
--
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: Mt9v024 gettting image problem

[Guennadi Liakhovetski]

Hi,

The reason for a lower framerate must not necessarily be in the program, 
it can be the hardware - either the clock frequency, your camera is driven 
by, or the slow CPU, or the camera host driver, or your frame processing.

Thanks
Guennadi

On Thu, 26 Nov 2015, Ayhan KÃ~\Ã~GÃ~\KMANÄ°SA wrote:

> Hi,
> 
> 
> I'm trying to get image from aptina mt9v024 sensor using v4l2 library. In
> sensor datasheet that is defined that sensor has 60 fps capability at
> default. But with my code which is below i could get images at 20 fps. How
> can i reach 60 fps? Could you give me an advice that where is my fault?
> 
> Thanks.
> 
> 
>  CODE 
> 
> 
> char *dev_name = "/dev/video0";
> int fd = v4l2_open(dev_name, O_RDWR | O_NONBLOCK, 0);
> if (fd < 0) {
> perror("Cannot open device");
> exit(EXIT_FAILURE);
> }
> cout << "camera init" << endl;
> CLEAR(fmt);
> fmt.type = V4L2_BUF_TYPE_VIDEO_CAPTURE;
> fmt.fmt.pix.width   = 752;
> fmt.fmt.pix.height  = 480;
> fmt.fmt.pix.pixelformat = V4L2_PIX_FMT_SBGGR16;
> fmt.fmt.pix.field   = V4L2_FIELD_ANY;
> xioctl(fd, VIDIOC_S_FMT, );
> 
> 
> CLEAR(req);
> req.count = 2;
> req.type = V4L2_BUF_TYPE_VIDEO_CAPTURE;
> req.memory = V4L2_MEMORY_MMAP;
> xioctl(fd, VIDIOC_REQBUFS, );
> 
> buffers = (buffer *)calloc(req.count, sizeof(*buffers));
> for (n_buffers = 0; n_buffers < req.count; ++n_buffers) {
> CLEAR(buf);
> 
> buf.type= V4L2_BUF_TYPE_VIDEO_CAPTURE;
> buf.memory  = V4L2_MEMORY_MMAP;
> buf.index   = n_buffers;
> 
> xioctl(fd, VIDIOC_QUERYBUF, );
> 
> buffers[n_buffers].length = buf.length;
> buffers[n_buffers].start = v4l2_mmap(NULL, buf.length,
>   PROT_READ | PROT_WRITE, MAP_SHARED,
>   fd, buf.m.offset);
> 
> if (MAP_FAILED == buffers[n_buffers].start) {
> perror("mmap");
> exit(EXIT_FAILURE);
> }
> }
> 
> for (i = 0; i < n_buffers; ++i) {
> CLEAR(buf);
> buf.type = V4L2_BUF_TYPE_VIDEO_CAPTURE;
> buf.memory = V4L2_MEMORY_MMAP;
> buf.index = i;
> xioctl(fd, VIDIOC_QBUF, );
> }
> type = V4L2_BUF_TYPE_VIDEO_CAPTURE;
> xioctl(fd, VIDIOC_STREAMON, );
> while(1)
> {
> do {
> FD_ZERO();
> FD_SET(fd, );
> 
> /* Timeout. */
> tv.tv_sec = 2;
> tv.tv_usec = 0;
> 
> r = select(fd + 1, , NULL, NULL, );
> } while ((r == -1 && (errno = EINTR)));
> if (r == -1) {
> perror("select");
> return errno;
> }
> 
> CLEAR(buf);
> buf.type = V4L2_BUF_TYPE_VIDEO_CAPTURE;
> buf.memory = V4L2_MEMORY_MMAP;
> xioctl(fd, VIDIOC_DQBUF, );
> /* Getting Image */
> Mat bayer16Bit = Mat(fmt.fmt.pix.height, fmt.fmt.pix.width, CV_8UC1, (void
> *)buffers[buf.index].start);
> }
> 
> 
> 
> 
> ---
> Arş. Gör. Ayhan KÜÇÜKMANİSA
> Kocaeli Üniversitesi, GömÃŒlÃŒ Sistemler ve GörÃŒntÃŒleme Sistemleri
> Laboratuvarı
> 
> Res. Asst. Ayhan KÜÇÜKMANİSA
> Kocaeli University, Laboratory of Embedded and Vision Systems
> 
--
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

[DVBT USB dongle] problem with Zolid Mini DVB-T Stick on linux mint 17.2

[Mark Croft]

hi

hope this is the correct list about trying to get linux to talk to
dvb-t usb stick?

check out all the logs etc here http://pastebin.com/V3RQ17hz

thx
--
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: [DVBT USB dongle] problem with Zolid Mini DVB-T Stick on linux mint 17.2

[Antti Palosaari]

On 11/26/2015 12:53 AM, Mark Croft wrote:

hi

hope this is the correct list about trying to get linux to talk to
dvb-t usb stick?

check out all the logs etc here http://pastebin.com/V3RQ17hz


and antenna is plugged and it is good antenna with strong signal? Test 
it first using windows. Logs says all is OK.


Antti



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



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

Re: [DVBT USB dongle] problem with Zolid Mini DVB-T Stick on linux mint 17.2

[Antti Palosaari]

On 11/26/2015 12:57 AM, Antti Palosaari wrote:

On 11/26/2015 12:53 AM, Mark Croft wrote:

hi

hope this is the correct list about trying to get linux to talk to
dvb-t usb stick?

check out all the logs etc here http://pastebin.com/V3RQ17hz


and antenna is plugged and it is good antenna with strong signal? Test
it first using windows. Logs says all is OK.


I started looking that initial tuning file and noticed I don't even have 
those old dvbv3 tuning files you are using.


You probably want use dvbv5 scan instead:
$ dvbv5-scan /usr/share/dvbv5/dvb-t/uk-BeaconHill

w_scan is also very good blind scanning app - no need for initial tuning 
files.

$ w_scan -c GB

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

Re: [BUG] TechniSat SkyStar S2 - problem tuning DVB-S2 channels

[Jemma Denson]

Hi Robert,

On 18/11/15 19:08, Robert wrote:

Normally i'm using kaffeine, but i have tried dvbv5-scan now.
Unfortunately it segfaults. I have attached the full output including
the backtrace [1]



I can't help with the segfault I'm afraid, but looking at that log it is 
definitely not managing to lock to any of the DVB-S2 transponders. The 
driver does work fine on S2 for me, but I am only able to test on 28.2E. 
Patrick did some testing on 19.2E so I'm going to cc him into this to 
confirm it does work there on S2.


In the meantime it might be worth checking that it is being tuned with 
the right parameters - I included some dynamic debug output to see what 
it was being asked to do when tuning:


echo 'file cx24120.c func cx24120_set_frontend +pf' > 
/sys/kernel/debug/dynamic_debug/control


This should output something like this in dmesg:

[2995692.044792] cx24120_set_frontend: i2c i2c-9: DVB-S2
[2995692.044799] cx24120_set_frontend: i2c i2c-9: delsys  = 6
[2995692.044802] cx24120_set_frontend: i2c i2c-9: modulation  = 9
[2995692.044805] cx24120_set_frontend: i2c i2c-9: frequency   = 1097000
[2995692.044808] cx24120_set_frontend: i2c i2c-9: pilot   = 0 (val = 
0x40)
[2995692.044811] cx24120_set_frontend: i2c i2c-9: symbol_rate = 2300 
(clkdiv/ratediv = 0x03/0x06)
[2995692.044814] cx24120_set_frontend: i2c i2c-9: FEC = 2 
(mask/val = 0x00/0x0d)
[2995692.044817] cx24120_set_frontend: i2c i2c-9: Inversion   = 2 (val = 
0x0c)


Hopefully from there it should be possible to see if it's being sent the 
correct parameters.


Regards,

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

Re: [BUG] TechniSat SkyStar S2 - problem tuning DVB-S2 channels

[Jemma Denson]

Hi Robert,

On 18/11/15 15:03, Robert wrote:

Hello,

I am using a "TechniSat SkyStar S2" DVB-S2 card. Drivers for this card
are included in the kernel tree since 4.2. Unfortunately, i can't tune
to ANY DVB-S2 channels with this new in-tree driver. DVB-S channels are
working fine. Id[1] of the commit which introduced support for this card.

Before 4.2 arrived i have used this[2] patch with which DVB-S2 channels
where tuneable without any problems. This patch works even with 4.3
after i have converted the fe_ structs to enums.

If you need anything to debug this behaviour, i will be at your disposal.




What program are you using to try and tune? Is it trying to tune in 
using DVB-S2? The "other" driver was done quite some while ago, and 
included some clunky code to fallback to S2 if DVB-S tuning failed as it 
was developed before the DVB API had support for supplying DVB-S2 as a 
delivery system and this was the only way of supporting S2 back then.
This was removed in the in-tree driver as it isn't needed anymore, but 
this does mean that the tuning program needs to supply the correct 
delivery system.


Have you tried it with dvbv5-scan & dvbv5-zap?

Regards,

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

Re: [BUG] TechniSat SkyStar S2 - problem tuning DVB-S2 channels

[Robert]

Hi Jemma,

On 18.11.2015 17:18, Jemma Denson wrote:
> What program are you using to try and tune? Is it trying to tune in
> using DVB-S2? The "other" driver was done quite some while ago, and
> included some clunky code to fallback to S2 if DVB-S tuning failed as it
> was developed before the DVB API had support for supplying DVB-S2 as a
> delivery system and this was the only way of supporting S2 back then.
> This was removed in the in-tree driver as it isn't needed anymore, but
> this does mean that the tuning program needs to supply the correct
> delivery system.
> 
> Have you tried it with dvbv5-scan & dvbv5-zap?

Normally i'm using kaffeine, but i have tried dvbv5-scan now.
Unfortunately it segfaults. I have attached the full output including
the backtrace [1]


Greetings,
Robert


[1]
https://paste.linuxlounge.net/?c3886ef444f9aa37#2ah2g19a9CfJMA/pBDikwoWj7S4AG2slhacWjXy8jEo=




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

Re: [BUG] TechniSat SkyStar S2 - problem tuning DVB-S2 channels

[David Jedelsky]

Robert,

I'm not sure whether it helps, but if your card is based on az6027, as
is my USB TechniSat SkyStar 2 HD CI, then attached patch could be
helpful. I had to create it to get DVB-S2 working on my device.
http://djed.cz/az6027-i2c.patch

Regards,
David

PS: trying to send once more with link instead of attachment (as
linuxmedia list rejected my previous mail)

On Wed, Nov 18, 2015 at 8:08 PM, Robert  wrote:
> Hi Jemma,
>
> On 18.11.2015 17:18, Jemma Denson wrote:
>> What program are you using to try and tune? Is it trying to tune in
>> using DVB-S2? The "other" driver was done quite some while ago, and
>> included some clunky code to fallback to S2 if DVB-S tuning failed as it
>> was developed before the DVB API had support for supplying DVB-S2 as a
>> delivery system and this was the only way of supporting S2 back then.
>> This was removed in the in-tree driver as it isn't needed anymore, but
>> this does mean that the tuning program needs to supply the correct
>> delivery system.
>>
>> Have you tried it with dvbv5-scan & dvbv5-zap?
>
> Normally i'm using kaffeine, but i have tried dvbv5-scan now.
> Unfortunately it segfaults. I have attached the full output including
> the backtrace [1]
>
>
> Greetings,
> Robert
>
>
> [1]
> https://paste.linuxlounge.net/?c3886ef444f9aa37#2ah2g19a9CfJMA/pBDikwoWj7S4AG2slhacWjXy8jEo=
>
>
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-media" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[BUG] TechniSat SkyStar S2 - problem tuning DVB-S2 channels

[Robert]

Hello,

I am using a "TechniSat SkyStar S2" DVB-S2 card. Drivers for this card
are included in the kernel tree since 4.2. Unfortunately, i can't tune
to ANY DVB-S2 channels with this new in-tree driver. DVB-S channels are
working fine. Id[1] of the commit which introduced support for this card.

Before 4.2 arrived i have used this[2] patch with which DVB-S2 channels
where tuneable without any problems. This patch works even with 4.3
after i have converted the fe_ structs to enums.

If you need anything to debug this behaviour, i will be at your disposal.

Thanks,
Robert

[1] 5afc9a25be8d4e627cf07aa8a7500eafe3664b94
[2] http://vdr-portal.de/index.php?page=Attachment=34585
--
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

[FWD] PROBLEM: there exists a wrong return value of function mantis_dma_init()

[Linus Torvalds]

It does seem like the error handling for mantis_dma_init() is insane..

   Linus

On Sun, Aug 9, 2015 at 5:12 PM, RUC_Soft_Sec zy900...@163.com wrote:
 Summary:
 there exists a wrong return value of function mantis_dma_init().It's a
 theoretical problem. we use static analysis method to detect this bug.
 Bug Description:

In function mantis_dma_init() at
 drivers/media/pci/mantis/mantis_dma.c：131, the call to
 mantis_alloc_buffers() in line 136 may return a negative error code, and
 thus function mantis_dma_init() will return the value of variable err. And,
 the function mantis_dma_init() will return 0 at last when it runs well.
 However, when the call to mantis_alloc_buffers() in line 136 return a
 negative error code, the value of err is 0. So the function
 mantis_dma_init() will return 0 to its caller functions when it runs error
 because of the failing call to mantis_alloc_buffers(), leading to a wrong
 return value of function mantis_dma_init().
 The related code snippets in mantis_dma_init() is as following.
 mantis_dma_init @@ drivers/media/pci/mantis/mantis_dma.c：131
  131int mantis_dma_init(struct mantis_pci *mantis)
  132{
  133int err = 0;
  134
  135dprintk(MANTIS_DEBUG, 1, Mantis DMA init);
  136if (mantis_alloc_buffers(mantis)  0) {
  137dprintk(MANTIS_ERROR, 1, Error allocating DMA buffer);
  138
  139/* Stop RISC Engine */
  140mmwrite(0, MANTIS_DMA_CTL);
  141
  142goto err;
  143}
  144
  145return 0;
  146err:
  147return err;
  148}

 Moreover, in the caller function of mantis_dma_init() the return value will
 be checked if it is a negative number. Now, the return value of
 mantis_dma_init() is always 0 and the check is useless.
 The related code snippets in mantis_core_init() is as following.
  137int mantis_core_init(struct mantis_pci *mantis)
  138{
 ...
  163err = mantis_dma_init(mantis);
  164if (err  0) {
  165dprintk(verbose, MANTIS_ERROR, 1, Mantis DMA init
 failed);
  166return err;
  167}
 ...
  179return 0;
  180}

 Kernel version:
 3.19.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

DMX_ADD_PID ioctl problem

[Marcin Kałuża]

Hi
I'm trying to use demuxX device for reading multiple PIDs and I have a
problem. I do

f-fd = dvb_dmx_open(inp-adapter, inp-demux);

unsigned short int pid;

res = dvb_set_pesfilter(f-fd, pid, DMX_PES_OTHER,
DMX_OUT_TSDEMUX_TAP, 128*1024);  //that works
pid = another_pid
res = ioctl(f-fd, DMX_ADD_PID, pid);//that doesn't res == -1, errno = ENOTTY

I'm using usb dongle with rtl2832 chip (it's supposed to have hardware
pid filters). I tried setting force_pid_filter_usage=1 on dvb-usb-v2
module but it doesn't help
dmesg (with force=1:
[ 3365.353154] usb 2-1.3: new high-speed USB device number 11 using ehci-pci
[ 3365.448694] usb 2-1.3: New USB device found, idVendor=1f4d, idProduct=c803
[ 3365.448699] usb 2-1.3: New USB device strings: Mfr=1, Product=2,
SerialNumber=3
[ 3365.448702] usb 2-1.3: Product: RTL2838UHIDIR
[ 3365.448704] usb 2-1.3: Manufacturer: Realtek
[ 3365.448706] usb 2-1.3: SerialNumber: 0001
[ 3365.463475] usb 2-1.3: dvb_usb_v2: found a 'Trekstor DVB-T Stick
Terres 2.0' in warm state
[ 3365.497626] usb 2-1.3: dvb_usb_v2: will pass the complete MPEG2
transport stream to the software demuxer
[ 3365.497631] usb 2-1.3: dvb_usb_v2: PID filter enabled by module option
[ 3365.497643] DVB: registering new adapter (Trekstor DVB-T Stick Terres 2.0)
[ 3365.506816] i2c i2c-10: Added multiplexed i2c bus 11
[ 3365.506820] rtl2832 10-0010: Realtek RTL2832 successfully attached
[ 3365.506829] usb 2-1.3: DVB: registering adapter 0 frontend 0
(Realtek RTL2832 (DVB-T))...
[ 3365.509961] fc0013: Fitipower FC0013 successfully attached.
[ 3365.516415] media: Linux media interface: v0.10
[ 3365.530762] Linux video capture interface: v2.00
[ 3365.542229] rtl2832_sdr rtl2832_sdr.0.auto: Registered as swradio0
[ 3365.542232] rtl2832_sdr rtl2832_sdr.0.auto: Realtek RTL2832 SDR attached
[ 3365.542234] rtl2832_sdr rtl2832_sdr.0.auto: SDR API is still
slightly experimental and functionality changes may follow
[ 3365.548824] Registered IR keymap rc-empty
[ 3365.548901] input: Trekstor DVB-T Stick Terres 2.0 as
/devices/pci:00/:00:1d.0/usb2/2-1/2-1.3/rc/rc0/input20
[ 3365.548938] rc0: Trekstor DVB-T Stick Terres 2.0 as
/devices/pci:00/:00:1d.0/usb2/2-1/2-1.3/rc/rc0
[ 3365.551458] IR NEC protocol handler initialized
[ 3365.552408] IR RC5(x/sz) protocol handler initialized
[ 3365.552868] usb 2-1.3: dvb_usb_v2: schedule remote query interval
to 200 msecs
[ 3365.554114] IR RC6 protocol handler initialized
[ 3365.555287] input: MCE IR Keyboard/Mouse (dvb_usb_rtl28xxu) as
/devices/virtual/input/input21
[ 3365.555419] IR MCE Keyboard/mouse protocol handler initialized
[ 3365.556299] IR JVC protocol handler initialized
[ 3365.556851] IR Sony protocol handler initialized
[ 3365.558365] IR SANYO protocol handler initialized
[ 3365.559217] IR Sharp protocol handler initialized
[ 3365.560860] IR XMP protocol handler initialized
[ 3365.561034] usb 2-1.3: dvb_usb_v2: 'Trekstor DVB-T Stick Terres
2.0' successfully initialized and connected

does the line
[ 3365.497626] usb 2-1.3: dvb_usb_v2: will pass the complete MPEG2
transport stream to the software demuxer
mean that it won't work and I have to filter in my application?
--
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: www.kernellabs.com Contact: Hauppauge hvr1275 TV Tuner card linux problem

[Steven Toth]

 Dear : Steven Toth
 Thanks for your professional answer
 Thanks a lot
 Best Regards

You are welcome!

 It looks like Hauppauge have released an updated HVR-1275 card, as
 indicated by the updated PCI-SubDevice ID 2A38. The hardware has
 changed and the driver needs to be modified to support these changes.

 Modprobing with option=19 isn't going to help.

 I've reached out to Hauppauge for comment on the new H/W. Stay tuned.

A sample HVR-1275 arrived yesterday, thank you Hauppauge.

I'll add driver support for this in the coming week, DTV only, its on
my todo list.

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

Re: www.kernellabs.com Contact: Hauppauge hvr1275 TV Tuner card linux problem

[Steven Toth]

 sorry I don’t know how can I do .. can you help me to fix the
 problem?

 Please ensure that all communication include the linux media mailing list.

 It looks like Hauppauge have released an updated HVR-1275 card, as
 indicated by the updated PCI-SubDevice ID 2A38. The hardware has
 changed and the driver needs to be modified to support these changes.

 Modprobing with option=19 isn't going to help.

I've reached out to Hauppauge for comment on the new H/W. Stay tuned.

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

Re: www.kernellabs.com Contact: Hauppauge hvr1275 TV Tuner card linux problem

[Steven Toth]

Adding in the linux-media mailing list

 Subject:
 Hauppauge hvr1275 TV Tuner card linux problem

 Message:
 I had one trouble about Hauppauge hvr1275 TV Tuner card

 Because of I want use tvtime app to play this TV Tuner card with ATI
 V4900 VGA Card under centos 6.5 linux 2.6.32-431.el6.i686

 First I have download Firmeare from:

 # wget
 http://steventoth.net/linux/hvr1200/HVR-12x0-14x0-17x0_1_25_25271_WHQL.zip

 # wget http://steventoth.net/linux/hvr1200/extract.sh

 # /bin/sh extract.sh

 # sudo cp v4l-cx23885-enc.fw v4l-cx23885-avcore-01.fw
 dvb-fe-tda10048-1.0.fw /lib/firmware

 Second create cx23885.conf in /etc/modprobe.d/

 Options cx23885 card=19

 Type modprobe cx23885 in terminal

 When I execute tvtime app always show can’t open /dev/video0

 When I use dmesg in terminal show below

 Linux video capture interface: v2.00

 cx23885 driver version 0.0.2 loaded

 cx23885 :04:00.0: PCI INT A -_ GSI 16 (level, low) -_ IRQ 16

 CORE cx23885[0]: subsystem: 0070:2a38, board: Hauppauge WinTV-HVR1275
 [card=19,insmod option]

 IR NEC protocol handler initialized

 IR RC5(x) protocol handler initialized

 IR RC6 protocol handler initialized

 IR JVC protocol handler initialized

 IR Sony protocol handler initialized

 lirc_dev: IR Remote Control driver registered, major 248

 IR LIRC bridge handler initialized

 tveeprom 11-0050: Hauppauge model 161100, rev A1I6, serial# 9140928

 tveeprom 11-0050: MAC address is 00:0d:fe:8b:7a:c0

 tveeprom 11-0050: tuner model is unknown (idx 186, type 4)

 tveeprom 11-0050: TV standards PAL(B/G) NTSC(M) PAL(I) SECAM(L/L')
 PAL(D/D1/K) ATSC/DVB Digital (eeprom 0xfc)

 tveeprom 11-0050: audio processor is CX23888 (idx 40)

 tveeprom 11-0050: decoder processor is CX23888 (idx 34)

 tveeprom 11-0050: has no radio, has IR receiver, has no IR
 transmitter

 cx23885[0]: warning: unknown hauppauge model #161100

 cx23885[0]: hauppauge eeprom: model=161100

 cx23885_dvb_register() allocating 1 frontend(s)

 cx23885[0]: cx23885 based dvb card

 lgdt3305_attach: unable to detect LGDT3305 hardware

 cx23885[0]: frontend initialization failed

 cx23885_dvb_register() dvb_register failed err = -1

 cx23885_dev_setup() Failed to register dvb on VID_C

 cx23885_dev_checkrevision() Hardware revision = 0xd0

 cx23885[0]/0: found at :04:00.0, rev: 4, irq: 16, latency: 0,
 mmio: 0xfbe0

 cx23885 :04:00.0: setting latency timer to 64

  alloc irq_desc for 34 on node -1

  alloc kstat_irqs on node -1

 if use dmesg | grep cx23885 in terminal show below

 cx23885 driver version 0.0.2 loaded

 cx23885 :05:00.0: PCI INT A -_ GSI 16 (level, low) -_ IRQ 16

 CORE cx23885[0]: subsystem: 0070:2a38, board: Hauppauge WinTV-HVR1275
 [card=19,insmod option]

 cx23885[0]: warning: unknown hauppauge model #161100

 cx23885[0]: hauppauge eeprom: model=161100

 cx23885_dvb_register() allocating 1 frontend(s)

 cx23885[0]: cx23885 based dvb card

 cx23885[0]: frontend initialization failed

 cx23885_dvb_register() dvb_register failed err = -1

 cx23885_dev_setup() Failed to register dvb on VID_C

 cx23885_dev_checkrevision() Hardware revision = 0xd0

 cx23885[0]/0: found at :05:00.0, rev: 4, irq: 16, latency: 0,
 mmio: 0xfbe0

 cx23885 :05:00.0: setting latency timer to 64

 cx23885 :05:00.0: irq 35 for MSI/MSI-X

 sorry I don’t know how can I do .. can you help me to fix the
 problem?

Please ensure that all communication include the linux media mailing list.

It looks like Hauppauge have released an updated HVR-1275 card, as
indicated by the updated PCI-SubDevice ID 2A38. The hardware has
changed and the driver needs to be modified to support these changes.

Modprobing with option=19 isn't going to help.

- Steve

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

RE: www.kernellabs.com Contact: Hauppauge hvr1275 TV Tuner card linux problem

[Tony Chang(Wincomm)]

Dear : Steven Toth
Thanks for your professional answer 
Thanks a lot
Best Regards
-Original Message-
From: Steven Toth [mailto:st...@kernellabs.com] 
Sent: Tuesday, July 14, 2015 8:56 PM
To: to...@wincomm.com.tw
Cc: Linux-Media
Subject: Re: www.kernellabs.com Contact: Hauppauge hvr1275 TV Tuner card
linux problem

 sorry I don't know how can I do .. can you help me to fix the
 problem?

 Please ensure that all communication include the linux media mailing list.

 It looks like Hauppauge have released an updated HVR-1275 card, as
 indicated by the updated PCI-SubDevice ID 2A38. The hardware has
 changed and the driver needs to be modified to support these changes.

 Modprobing with option=19 isn't going to help.

I've reached out to Hauppauge for comment on the new H/W. Stay tuned.

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

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

Re: em28xx problem with 3.10-4.0

[Gabor Z. Papp]

* Mauro Carvalho Chehab mche...@osg.samsung.com:

| Nothing. You just ran out of continuous memory. This driver
| requires long chunks of continuous memory for USB data transfer.

And there is no way to preset some mem?
Or do something to get the driver work again?
I don't think I'm using too much memory.

$ free
 total   used   free sharedbuffers cached
Mem:   2073656 6256961447960  0  21072 231096
-/+ buffers/cache: 3735281700128
Swap:  1004056  01004056
--
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: em28xx problem with 3.10-4.0

[Mauro Carvalho Chehab]

Em Wed, 17 Jun 2015 08:32:26 +0200
Gabor Z. Papp gzpapp.li...@gmail.com escreveu:

 * Mauro Carvalho Chehab mche...@osg.samsung.com:
 
 | Nothing. You just ran out of continuous memory. This driver
 | requires long chunks of continuous memory for USB data transfer.
 
 And there is no way to preset some mem?
 Or do something to get the driver work again?
 I don't think I'm using too much memory.
 
 $ free
  total   used   free sharedbuffers cached
 Mem:   2073656 6256961447960  0  21072 231096
 -/+ buffers/cache: 3735281700128
 Swap:  1004056  01004056

From your error logs, it failed to allocate the 3rd buffer (of a total of 5
buffers) with a continuous block of 165.120 bytes on the DMA range.

In order words, your system needs to have at least 5 non-fragmented buffers
with 256KB each, on a memory region where the CPU can do DMA (e. g. 
outside the high memory area).

I'm not a memory management specialist, but I guess you could try to change
some sysctl parameters or use a different memory allocator in order to avoid
memory fragmentation.

If you're a C programmer, an option would be to change the driver's code
to optimize it for low memory usage, for example, to reduce the buffer size
and increasing the number of buffers (at the cost of requiring more CPU
and/or reducing the maximum size of the image). Another alternative would be
to reserve the memory at the time the driver gets loaded.

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

Re: em28xx problem with 3.10-4.0

[Gabor Z. Papp]

* Gabor Z. Papp gzpapp.li...@gmail.com:

| I would like to use my Pinnacle Dazzle DVC usb encoder with kernels
| 3.10-4.0, but I'm getting the same error all the time.

| Latest working kernel is the 3.4 line.

| What happend with the driver?

Should I provide more details than the dmesg output?

Linux video capture interface: v2.00
em28xx: New device Pinnacle Systems GmbH DVC100 @ 480 Mbps (2304:021a, 
interface 0, class 0)
em28xx: Video interface 0 found: bulk isoc
em28xx: chip ID is em2710/2820
em2710/2820 #0: EEPROM ID = 1a eb 67 95, EEPROM hash = 0xe2ac7680
em2710/2820 #0: EEPROM info:
em2710/2820 #0: AC97 audio (5 sample rates)
em2710/2820 #0: 300mA max power
em2710/2820 #0: Table at offset 0x06, strings=0x1098, 0x2e6a, 0x
em2710/2820 #0: Identified as Pinnacle Dazzle DVC 90/100/101/107 / Kaiser Baas 
Video to DVD maker / Kworld DVD Maker 2 / Plextor ConvertX PX-AV100U (card=9)
em2710/2820 #0: analog set to isoc mode.
em28xx audio device (2304:021a): interface 1, class 1
em28xx audio device (2304:021a): interface 2, class 1
usbcore: registered new interface driver em28xx
em2710/2820 #0: Registering V4L2 extension
saa7115 1-0025: saa7113 found @ 0x4a (em2710/2820 #0)
em2710/2820 #0: Config register raw data: 0x12
em2710/2820 #0: AC97 vendor ID = 0x83847650
em2710/2820 #0: AC97 features = 0x6a90
em2710/2820 #0: Empia 202 AC97 audio processor detected
em2710/2820 #0: V4L2 video device registered as video0
em2710/2820 #0: V4L2 extension successfully initialized
em28xx: Registered (Em28xx v4l2 Extension) extension
Linux agpgart interface v0.103
tun: Universal TUN/TAP device driver, 1.6
tun: (C) 1999-2004 Max Krasnyansky m...@qualcomm.com
ffmpeg: page allocation failure: order:6, mode:0xd0
CPU: 0 PID: 3721 Comm: ffmpeg 4.0.5-gzp1 #1
Hardware name: System manufacturer System Product Name/P5W64 WS Pro, BIOS 1201  
  10/01/2008
  c12e214e 0001 c109221f c137382c f51ff478 0006 00d0
 0001 00d0 0040 00d0 c109419f 00d0 0006 
 0028 0040 0010 0028 0040  0050 f51ff1c0
Call Trace:
 [c12e214e] ? dump_stack+0x3e/0x4e
 [c109221f] ? warn_alloc_failed+0xaf/0xf0
 [c109419f] ? __alloc_pages_nodemask+0x39f/0x5a0
 [c10065ff] ? dma_generic_alloc_coherent+0x8f/0xd0
 [c1006570] ? via_no_dac+0x40/0x40
 [f8149a2b] ? hcd_buffer_alloc+0xbb/0x140 [usbcore]
 [f861f4e1] ? em28xx_alloc_urbs+0x191/0x410 [em28xx]
 [f8676ce6] ? saa711x_writeregs+0x36/0x90 [saa7115]
 [f861f842] ? em28xx_init_usb_xfer+0x52/0x160 [em28xx]
 [f86664f0] ? em28xx_start_analog_streaming+0x230/0x410 [em28xx_v4l]
 [f86640c0] ? em28xx_wake_i2c+0xc0/0xc0 [em28xx_v4l]
 [f8666123] ? buffer_queue+0x53/0xb0 [em28xx_v4l]
 [f864ee3e] ? __buf_prepare+0x28e/0x300 [videobuf2_core]
 [f864d1b2] ? vb2_start_streaming+0x52/0x130 [videobuf2_core]
 [f864f9fd] ? vb2_internal_qbuf+0xcd/0x200 [videobuf2_core]
 [f864f72f] ? vb2_internal_streamon+0x10f/0x150 [videobuf2_core]
 [f864f7cc] ? vb2_ioctl_streamon+0xc/0x40 [videobuf2_core]
 [f85e16e3] ? v4l_streamon+0x13/0x20 [videodev]
 [f85e3ea0] ? __video_do_ioctl+0x230/0x2d0 [videodev]
 [c10a748e] ? __pte_alloc+0x1e/0x80
 [f85e3a1f] ? video_usercopy+0x19f/0x3d0 [videodev]
 [c10de6f2] ? inode_to_bdi+0x12/0x40
 [c10ac4da] ? vma_wants_writenotify+0x6a/0x80
 [c10ac515] ? vma_set_page_prot+0x25/0x50
 [c10ad4c8] ? mmap_region+0x138/0x4f0
 [f85e3c5f] ? video_ioctl2+0xf/0x20 [videodev]
 [f85e3c70] ? video_ioctl2+0x20/0x20 [videodev]
 [f85e068d] ? v4l2_ioctl+0xdd/0x120 [videodev]
 [f85e05b0] ? v4l2_open+0xe0/0xe0 [videodev]
 [c10cdd3f] ? do_vfs_ioctl+0x31f/0x540
 [c10adb26] ? do_mmap_pgoff+0x2a6/0x330
 [c10a0766] ? vm_mmap_pgoff+0x56/0x80
 [c10cdf9c] ? SyS_ioctl+0x3c/0x70
 [c12e5ecc] ? sysenter_do_call+0x12/0x12
Mem-Info:
DMA per-cpu:
CPU0: hi:0, btch:   1 usd:   0
CPU1: hi:0, btch:   1 usd:   0
CPU2: hi:0, btch:   1 usd:   0
CPU3: hi:0, btch:   1 usd:   0
Normal per-cpu:
CPU0: hi:  186, btch:  31 usd:   0
CPU1: hi:  186, btch:  31 usd:   0
CPU2: hi:  186, btch:  31 usd: 167
CPU3: hi:  186, btch:  31 usd:   0
HighMem per-cpu:
CPU0: hi:  186, btch:  31 usd:   0
CPU1: hi:  186, btch:  31 usd:   0
CPU2: hi:  186, btch:  31 usd:   0
CPU3: hi:  186, btch:  31 usd:   0
active_anon:86766 inactive_anon:53673 isolated_anon:0
 active_file:67864 inactive_file:145211 isolated_file:0
 unevictable:0 dirty:3 writeback:0 unstable:0
 free:109849 slab_reclaimable:37567 slab_unreclaimable:4346
 mapped:20327 shmem:256 pagetables:748 bounce:0
 free_cma:0
DMA free:3504kB min:64kB low:80kB high:96kB active_anon:1448kB 
inactive_anon:1596kB active_file:5600kB inactive_file:2296kB unevictable:0kB 
isolated(anon):0kB isolated(file):0kB present:15992kB managed:15916kB 
mlocked:0kB dirty:0kB writeback:0kB mapped:824kB shmem:0kB 
slab_reclaimable:816kB slab_unreclaimable:164kB kernel_stack:0kB 
pagetables:24kB unstable:0kB bounce:0kB free_cma:0kB writeback_tmp:0kB 
pages_scanned:20 all_unreclaimable? no

Re: em28xx problem with 3.10-4.0

[Mauro Carvalho Chehab]

Em Tue, 16 Jun 2015 08:54:58 +0200
Gabor Z. Papp gzpapp.li...@gmail.com escreveu:

 * Gabor Z. Papp gzpapp.li...@gmail.com:
 
 | I would like to use my Pinnacle Dazzle DVC usb encoder with kernels
 | 3.10-4.0, but I'm getting the same error all the time.
 
 | Latest working kernel is the 3.4 line.
 
 | What happend with the driver?

Nothing. You just ran out of continuous memory. This driver
requires long chunks of continuous memory for USB data transfer.

Please see this thread:
http://www.spinics.net/lists/linux-media/msg43868.html

As far as I remember, some things changed from 3.4 on the part
that allocates memory there, reducing the risk of getting out
of memory, but can't remember the specific details anymore.

Regards,
Mauro


 
 Should I provide more details than the dmesg output?
 
 Linux video capture interface: v2.00
 em28xx: New device Pinnacle Systems GmbH DVC100 @ 480 Mbps (2304:021a, 
 interface 0, class 0)
 em28xx: Video interface 0 found: bulk isoc
 em28xx: chip ID is em2710/2820
 em2710/2820 #0: EEPROM ID = 1a eb 67 95, EEPROM hash = 0xe2ac7680
 em2710/2820 #0: EEPROM info:
 em2710/2820 #0: AC97 audio (5 sample rates)
 em2710/2820 #0: 300mA max power
 em2710/2820 #0: Table at offset 0x06, strings=0x1098, 0x2e6a, 0x
 em2710/2820 #0: Identified as Pinnacle Dazzle DVC 90/100/101/107 / Kaiser 
 Baas Video to DVD maker / Kworld DVD Maker 2 / Plextor ConvertX PX-AV100U 
 (card=9)
 em2710/2820 #0: analog set to isoc mode.
 em28xx audio device (2304:021a): interface 1, class 1
 em28xx audio device (2304:021a): interface 2, class 1
 usbcore: registered new interface driver em28xx
 em2710/2820 #0: Registering V4L2 extension
 saa7115 1-0025: saa7113 found @ 0x4a (em2710/2820 #0)
 em2710/2820 #0: Config register raw data: 0x12
 em2710/2820 #0: AC97 vendor ID = 0x83847650
 em2710/2820 #0: AC97 features = 0x6a90
 em2710/2820 #0: Empia 202 AC97 audio processor detected
 em2710/2820 #0: V4L2 video device registered as video0
 em2710/2820 #0: V4L2 extension successfully initialized
 em28xx: Registered (Em28xx v4l2 Extension) extension
 Linux agpgart interface v0.103
 tun: Universal TUN/TAP device driver, 1.6
 tun: (C) 1999-2004 Max Krasnyansky m...@qualcomm.com
 ffmpeg: page allocation failure: order:6, mode:0xd0
 CPU: 0 PID: 3721 Comm: ffmpeg 4.0.5-gzp1 #1
 Hardware name: System manufacturer System Product Name/P5W64 WS Pro, BIOS 
 120110/01/2008
   c12e214e 0001 c109221f c137382c f51ff478 0006 00d0
  0001 00d0 0040 00d0 c109419f 00d0 0006 
  0028 0040 0010 0028 0040  0050 f51ff1c0
 Call Trace:
  [c12e214e] ? dump_stack+0x3e/0x4e
  [c109221f] ? warn_alloc_failed+0xaf/0xf0
  [c109419f] ? __alloc_pages_nodemask+0x39f/0x5a0
  [c10065ff] ? dma_generic_alloc_coherent+0x8f/0xd0
  [c1006570] ? via_no_dac+0x40/0x40
  [f8149a2b] ? hcd_buffer_alloc+0xbb/0x140 [usbcore]
  [f861f4e1] ? em28xx_alloc_urbs+0x191/0x410 [em28xx]
  [f8676ce6] ? saa711x_writeregs+0x36/0x90 [saa7115]
  [f861f842] ? em28xx_init_usb_xfer+0x52/0x160 [em28xx]
  [f86664f0] ? em28xx_start_analog_streaming+0x230/0x410 [em28xx_v4l]
  [f86640c0] ? em28xx_wake_i2c+0xc0/0xc0 [em28xx_v4l]
  [f8666123] ? buffer_queue+0x53/0xb0 [em28xx_v4l]
  [f864ee3e] ? __buf_prepare+0x28e/0x300 [videobuf2_core]
  [f864d1b2] ? vb2_start_streaming+0x52/0x130 [videobuf2_core]
  [f864f9fd] ? vb2_internal_qbuf+0xcd/0x200 [videobuf2_core]
  [f864f72f] ? vb2_internal_streamon+0x10f/0x150 [videobuf2_core]
  [f864f7cc] ? vb2_ioctl_streamon+0xc/0x40 [videobuf2_core]
  [f85e16e3] ? v4l_streamon+0x13/0x20 [videodev]
  [f85e3ea0] ? __video_do_ioctl+0x230/0x2d0 [videodev]
  [c10a748e] ? __pte_alloc+0x1e/0x80
  [f85e3a1f] ? video_usercopy+0x19f/0x3d0 [videodev]
  [c10de6f2] ? inode_to_bdi+0x12/0x40
  [c10ac4da] ? vma_wants_writenotify+0x6a/0x80
  [c10ac515] ? vma_set_page_prot+0x25/0x50
  [c10ad4c8] ? mmap_region+0x138/0x4f0
  [f85e3c5f] ? video_ioctl2+0xf/0x20 [videodev]
  [f85e3c70] ? video_ioctl2+0x20/0x20 [videodev]
  [f85e068d] ? v4l2_ioctl+0xdd/0x120 [videodev]
  [f85e05b0] ? v4l2_open+0xe0/0xe0 [videodev]
  [c10cdd3f] ? do_vfs_ioctl+0x31f/0x540
  [c10adb26] ? do_mmap_pgoff+0x2a6/0x330
  [c10a0766] ? vm_mmap_pgoff+0x56/0x80
  [c10cdf9c] ? SyS_ioctl+0x3c/0x70
  [c12e5ecc] ? sysenter_do_call+0x12/0x12
 Mem-Info:
 DMA per-cpu:
 CPU0: hi:0, btch:   1 usd:   0
 CPU1: hi:0, btch:   1 usd:   0
 CPU2: hi:0, btch:   1 usd:   0
 CPU3: hi:0, btch:   1 usd:   0
 Normal per-cpu:
 CPU0: hi:  186, btch:  31 usd:   0
 CPU1: hi:  186, btch:  31 usd:   0
 CPU2: hi:  186, btch:  31 usd: 167
 CPU3: hi:  186, btch:  31 usd:   0
 HighMem per-cpu:
 CPU0: hi:  186, btch:  31 usd:   0
 CPU1: hi:  186, btch:  31 usd:   0
 CPU2: hi:  186, btch:  31 usd:   0
 CPU3: hi:  186, btch:  31 usd:   0
 active_anon:86766 inactive_anon:53673 isolated_anon:0
  active_file:67864 inactive_file:145211 isolated_file:0
  unevictable:0 

Re: em28xx problem with 3.10-4.0

[Andy Furniss]

Mauro Carvalho Chehab wrote:

Em Tue, 16 Jun 2015 08:54:58 +0200 Gabor Z. Papp
gzpapp.li...@gmail.com escreveu:


* Gabor Z. Papp gzpapp.li...@gmail.com:

| I would like to use my Pinnacle Dazzle DVC usb encoder with
kernels | 3.10-4.0, but I'm getting the same error all the time.

| Latest working kernel is the 3.4 line.

| What happend with the driver?


Nothing. You just ran out of continuous memory. This driver requires
long chunks of continuous memory for USB data transfer.

Please see this thread:
http://www.spinics.net/lists/linux-media/msg43868.html

As far as I remember, some things changed from 3.4 on the part that
allocates memory there, reducing the risk of getting out of memory,
but can't remember the specific details anymore.


Oh interesting - I only recently stopped using the low mem box in that
post. I think I ended up on kernel 3.9 and had uptimes of  200 days
without issue.

I still have the 290e but now on a box with 4 gig ram - haven't had time
to see if I'll hit it again with 4.1.

My use case was dvb not analogue.

If you just want to plug and cap something you may be able to workaround
by first, as root, doing -

sync;echo 3 /proc/sys/vm/drop_caches

to clean out men.



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

em28xx problem with 3.10-4.0

[Gabor Z. Papp]

lo lo,

I would like to use my Pinnacle Dazzle DVC usb encoder with kernels
3.10-4.0, but I'm getting the same error all the time.

Latest working kernel is the 3.4 line.

What happend with the driver?



dmesg
Description: Binary data

[PATCH] rc/Kconfig: fix indentation problem

[Hans Verkuil]

The RC_ST and IR_SUNXI entries have weird indentation, and the RC_ST
entry is actually malformed. Fix it.

Signed-off-by: Hans Verkuil hans.verk...@cisco.com

diff --git a/drivers/media/rc/Kconfig b/drivers/media/rc/Kconfig
index ddfab25..b6e1311 100644
--- a/drivers/media/rc/Kconfig
+++ b/drivers/media/rc/Kconfig
@@ -371,21 +371,21 @@ config RC_ST
tristate ST remote control receiver
depends on RC_CORE
depends on ARCH_STI || COMPILE_TEST
-   help
-Say Y here if you want support for ST remote control driver
-which allows both IR and UHF RX.
-The driver passes raw pulse and space information to the LIRC decoder.
+   ---help---
+  Say Y here if you want support for ST remote control driver
+  which allows both IR and UHF RX.
+  The driver passes raw pulse and space information to the LIRC 
decoder.

-If you're not sure, select N here.
+  If you're not sure, select N here.

 config IR_SUNXI
-tristate SUNXI IR remote control
-depends on RC_CORE
-depends on ARCH_SUNXI || COMPILE_TEST
----help---
-  Say Y if you want to use sunXi internal IR Controller
-
-  To compile this driver as a module, choose M here: the module will
-  be called sunxi-ir.
+   tristate SUNXI IR remote control
+   depends on RC_CORE
+   depends on ARCH_SUNXI || COMPILE_TEST
+   ---help---
+  Say Y if you want to use sunXi internal IR Controller
+
+  To compile this driver as a module, choose M here: the module will
+  be called sunxi-ir.

 endif #RC_DEVICES
--
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

Problem with SaTiX-S2 Sky V2 USB

[Steve]

I recently upgraded to Ubuntu 15.04 to get a 3.19 kernel because the 
Linux TV Wiki suggests that, from kernel version 3.18 onwards, my 
Mystique SaTiX-S2 Sky V2 USB (DVBSKY S960 clone) would work 'out of 
the box'.


I followed the MythTV instructions by installing dvb-apps and mplayer. 
Unfortunately, the next step - attempting to scan for channels - fails:



root# scan -x0 /usr/share/dvb/dvb-s/Astra-28.2E
scanning /usr/share/dvb/dvb-s/Astra-28.2E
using '/dev/dvb/adapter0/frontend0' and '/dev/dvb/adapter0/demux0'
main:2745: FATAL: failed to open '/dev/dvb/adapter0/frontend0': 2 No 
such file or directory


When I look in /dev/dvb/adapter0, I don't have a frontend0 device:


root# ls -l /dev/dvb/adapter0
total 0
crw-rw+ 1 root video 212, 0 Apr 24 13:57 demux0
crw-rw+ 1 root video 212, 1 Apr 24 13:57 dvr0
crw-rw+ 1 root video 212, 2 Apr 24 13:57 net0


Looking at the output from dmesg, I find evidence for a likely cause...



[   15.316027] usb 2-3: dvb_usb_v2: found a 'DVBSky S960/S860' in warm 
state
[   15.316147] usb 2-3: dvb_usb_v2: will pass the complete MPEG2 
transport stream to the software demuxer

[   15.316164] DVB: registering new adapter (DVBSky S960/S860)
[   15.317421] usb 2-3: dvb_usb_v2: MAC address: 00:17:42:54:96:0c
[   15.627310] i2c i2c-7: m88ds3103_attach: chip_id=70
[   15.631284] i2c i2c-7: Added multiplexed i2c bus 8
[   15.745707] BUG: unable to handle kernel NULL pointer dereference 
at 0040

[   15.745748] IP: [8126e6be] sysfs_remove_link+0xe/0x30
[   15.745774] PGD 0
[   15.745785] Oops:  [#1] SMP
[   15.745804] Modules linked in: m88ts2022 m88ds3103 i2c_mux 
dvb_usb_dvbsky(+) dvb_usb_v2 dvb_core rc_core snd_hda_codec_realtek 
snd_hda_codec_generic snd_hda_intel snd_usb_audio snd_hda_controller 
gpio_ich hp_wmi sparse_keymap snd_hda_codec snd_usbmidi_lib snd_hwdep 
snd_pcm i915 snd_seq_midi snd_seq_midi_event coretemp snd_rawmidi 
snd_seq joydev snd_seq_device drm_kms_helper drm snd_timer kvm mei_me 
snd mei serio_raw lpc_ich shpchp soundcore 8250_fintek video wmi 
i2c_algo_bit tpm_infineon mac_hid parport_pc ppdev lp parport autofs4 
hid_generic usbhid hid uas usb_storage psmouse ahci libahci e1000e ptp 
pps_core pata_acpi
[   15.746140] CPU: 0 PID: 295 Comm: systemd-udevd Not tainted 
3.19.0-15-generic #15-Ubuntu
[   15.746168] Hardware name: Hewlett-Packard HP Compaq 6000 Pro SFF 
PC/3048h, BIOS 786G2 v01.09 08/25/2009
[   15.746199] task: 880191ce93a0 ti: 880193648000 task.ti: 
880193648000
[   15.746224] RIP: 0010:[8126e6be] [8126e6be] 
sysfs_remove_link+0xe/0x30

[   15.746255] RSP: 0018:88019364ba78  EFLAGS: 00010202
[   15.746274] RAX:  RBX: 8800d5b4e000 RCX: 

[   15.746298] RDX: 88019364ba95 RSI: 88019364ba8c RDI: 
0010
[   15.746322] RBP: 88019364ba78 R08: 000a R09: 
fffb
[   15.746346] R10:  R11:  R12: 
8800d5b4e000
[   15.746369] R13: 880191cc4a78 R14: 880191cc4a80 R15: 
ffed
[   15.746393] FS:  7fe8946f3880() GS:88019bc0() 
knlGS:

[   15.746420] CS:  0010 DS:  ES:  CR0: 8005003b
[   15.746440] CR2: 0040 CR3: 00019367e000 CR4: 
000407f0

[   15.746463] Stack:
[   15.746473]  88019364bab8 c05481b3 6e616863d6a98838 
323000302d6c656e
[   15.746507]  0032 da2bae1e 8800d6a98800 
c054f680
[   15.746541]  88019364bad8 c054f6a1  
8800d6a98838

[   15.746575] Call Trace:
[   15.746588]  [c05481b3] 
i2c_del_mux_adapter+0x53/0x90 [i2c_mux]
[   15.746614]  [c054f680] ? 
m88ds3103_init+0x3f0/0x3f0 [m88ds3103]
[   15.746638]  [c054f6a1] 
m88ds3103_release+0x21/0x30 [m88ds3103]
[   15.746667]  [c05868a5] 
dvb_frontend_detach+0x75/0x90 [dvb_core]
[   15.746693]  [c059dfc6] 
dvb_usbv2_probe+0xc06/0x1200 [dvb_usb_v2]

[   15.746719]  [817c6e56] ? mutex_lock+0x16/0x40
[   15.746740]  [815c2b5b] usb_probe_interface+0x1bb/0x300
[   15.746763]  [815064f3] driver_probe_device+0xa3/0x410
[   15.746784]  [8150693b] __driver_attach+0x9b/0xa0
[   15.746805]  [815068a0] ? __device_attach+0x40/0x40
[   15.746826]  [815042bb] bus_for_each_dev+0x6b/0xb0
[   15.746847]  [81505f5e] driver_attach+0x1e/0x20
[   15.746866]  [81505b30] bus_add_driver+0x180/0x250
[   15.746887]  [81507134] driver_register+0x64/0xf0
[   15.746908]  [815c1342] usb_register_driver+0x82/0x160
[   15.746931]  [c0544000] ? 0xc0544000
[   15.746952]  [c054401e] 
dvbsky_usb_driver_init+0x1e/0x1000 [dvb_usb_dvbsky]

[   15.746980]  [81002148] do_one_initcall+0xd8/0x210
[   15.747002]  [811d5b49] ? 

Re: [BUG, workaround] HVR-2200/saa7164 problem with C7 power state

[Steven Toth]

On Wed, Feb 18, 2015 at 11:04 PM, David Harty d...@dharty.com wrote:
 On 02/17/2015 04:47 AM, dCrypt wrote:

 So the PCI Express change hasn't seemed to help either. Any other ideas?
 David --


 My system stops working at least once a day.  Does anyone have any
 suggestions to try? latest module builds? other firmwares?  I notice there
 are several up on the http://www.steventoth.net/linux/hvr22xx/ site, would
 any of those work better?

 Is there a better card to use?  the HVR-2200 and saa7164 are effectively
 unusable at this point.

I'm planning to release an updated saa7164 driver shortly, with
support for the HVR2205 and the HVR2255. Additionally, it contains a
fix (which for some people) has significantly reduced the I2C Timeout
related errors. (Technically the risc processor crashes on the card,
leading to all firmware commands timing out).

I'll post a notice to this list once the driver is ready for download.
Shortly, I hope.

- Steve

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

Re: [BUG, workaround] HVR-2200/saa7164 problem with C7 power state

[David Harty]

On 02/19/2015 05:22 AM, Steven Toth wrote:

I'll post a notice to this list once the driver is ready for download

That sounds great.  Let me know if/how I can help in any way.

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

Problem

[Jeffrey O'Hara]

I am trying to get my Hauppauge USB-Live2 to capture VHS recordings 
using VLC Player. My computer will recognize the USB-Live2 but nothing 
shows on the screen when using VLC Player. Any suggestions?

Thank You


jeffrey@jeffrey-HP-2000-Notebook-PC:~$ git clone 
git://linuxtv.org/media_build.git

Cloning into 'media_build'...
remote: Counting objects: 2699, done.
remote: Compressing objects: 100% (1082/1082), done.
remote: Total 2699 (delta 1895), reused 2258 (delta 1577)
Receiving objects: 100% (2699/2699), 526.94 KiB | 38.00 KiB/s, done.
Resolving deltas: 100% (1895/1895), done.
Checking connectivity... done.
jeffrey@jeffrey-HP-2000-Notebook-PC:~$ cd media_build
jeffrey@jeffrey-HP-2000-Notebook-PC:~/media_build$ ./build
Checking if the needed tools for Zorin OS 9 are available
ERROR: please install Proc::ProcessTable, otherwise, build won't work.
I don't know distro Zorin OS 9. So, I can't provide you a hint with the 
package names.
Be welcome to contribute with a patch for media-build, by submitting a 
distro-specific hint

to linux-media@vger.kernel.org
Build can't procceed as 1 dependency is missing at ./build line 266.
jeffrey@jeffrey-HP-2000-Notebook-PC:~/media_build$

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

Re: [BUG, workaround] HVR-2200/saa7164 problem with C7 power state

[David Harty]

On 02/17/2015 04:47 AM, dCrypt wrote:
So the PCI Express change hasn't seemed to help either. Any other 
ideas? David --


My system stops working at least once a day.  Does anyone have any 
suggestions to try? latest module builds? other firmwares?  I notice 
there are several up on the http://www.steventoth.net/linux/hvr22xx/ 
site, would any of those work better?


Is there a better card to use?  the HVR-2200 and saa7164 are effectively 
unusable at this point.


Thanks,

David

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

RE: [BUG, workaround] HVR-2200/saa7164 problem with C7 power state

[dCrypt]

Hi,

Forcing C-state to C6 doesn't help either. It's just the errors show up in the 
log later. Last reboot was the 12th of February, and I started getting errors 
this morning and VDR shutdown (five days working without issues). Find the log 
attached.

I am testing again with the next C-state bios option, C1, in order to check if 
the problem is related to the C-states or not.

Tested in Ubuntu 14.04 with 3.13.0-45-generic kernel, Asrock Q1900-M board.

BR 

 -Mensaje original-
 De: linux-media-ow...@vger.kernel.org [mailto:linux-media-
 ow...@vger.kernel.org] En nombre de catchall
 Enviado el: martes, 17 de febrero de 2015 4:58
 Para: v...@dharty.com; dcr...@telefonica.net; st...@kernellabs.com
 CC: linux-media@vger.kernel.org
 Asunto: Re: [BUG, workaround] HVR-2200/saa7164 problem with C7 power
 state
 
 On 02/12/2015 03:38 PM, David Harty wrote:
  I hadn't changed the PCI Express Configuration to Gen1 because per
 the
  http://whirlpool.net.au/wiki/n54l_all_in_one page it didn't appear to
  help reliably.  I've made that change now. I'll report to see if that
  improves anything, perhaps both changes have to be made in
 conjunction.
 
 So the PCI Express change hasn't seemed to help either.  Any other
 ideas?
 
 David
 
 --
 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


kern.log
Description: Binary data

Re: [BUG, workaround] HVR-2200/saa7164 problem with C7 power state

[catchall]

On 02/12/2015 03:38 PM, David Harty wrote:
I hadn't changed the PCI Express Configuration to Gen1 because per the 
http://whirlpool.net.au/wiki/n54l_all_in_one page it didn't appear to 
help reliably.  I've made that change now. I'll report to see if that 
improves anything, perhaps both changes have to be made in conjunction. 


So the PCI Express change hasn't seemed to help either.  Any other ideas?

David

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

Re: [BUG, workaround] HVR-2200/saa7164 problem with C7 power state

[David Harty]

On 02/03/2015 05:59 AM, dcr...@telefonica.net wrote:

 Mensaje original 
De : st...@kernellabs.com
Fecha : 02/02/2015 - 16:39 (GMT)
Para : dcr...@telefonica.net
CC : linux-media@vger.kernel.org
Asunto : Re: [BUG, workaround] HVR-2200/saa7164 problem with C7 power state


Basically, it starts working but after a while I get an Event timed out message and several i2c 
errors and VDR shuts down (some hours after reboot). As the web page mentions, I tested downgrading the PCIe 
bandwith from GEN2 to GEN1 without success. But after playing with different BIOS options, what did the trick 
was limiting the power-saving C-states. If I select C7 as the maximum C-state, the card fails as 
described. After limiting the maximum C-state to C6, it has been working for a whole weekend.

Good feedback on the C7 vs C6 power state, thanks.

You are welcome, Steve. Happy to be helpful.

I will be at your disposal for testing purposes, if you need.

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



Some additional input:

I made similar changes to the bios of my ASRock H87M Pro4.  There were 
multiple settings for CPU C state support.  I set the C7 state to 
disabled and forced selected C6 in the State support dropdown to further 
force it to C6.


Within 3 hours the dmesg was filling up with the no free sequences errors.

I hadn't changed the PCI Express Configuration to Gen1 because per the 
http://whirlpool.net.au/wiki/n54l_all_in_one page it didn't appear to 
help reliably.  I've made that change now. I'll report to see if that 
improves anything, perhaps both changes have to be made in conjunction.



Regards,

David

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

Re: [BUG] - Why anyone fix this problem?

[Francesco Other]

Ok, Doron Cohen solved the problem in 5 seconds.

There are 2 mode for DVB-T, we need to force mode 4 instead of mode 0.

Thanks to Roberto for trying to solve the problem and to Olli for the
e-mail of Doron Cohen.

Regards

Francesco


2015-02-03 11:57 GMT+01:00 Olli Salonen olli.salo...@iki.fi:
 Well, if you suspect that some other change broke the driver, then you
 can try an older kernel (the support was introduced in kernel 3.10) or
 an older media_tree to see if that's indeed the case.

 The firmware is just one small piece of the puzzle. Maybe you can just
 replace the firmware or maybe you need to write a lot of code or even
 both. All this is next to impossible to say without having a very
 strictly defined and pinpointed issue or alternatively the actual
 device to play around with. So far it seems you're the only one with
 that device here, so it would help a lot if you can narrow the scope
 down by saying: it worked fine in kernel xyz, but commit abc seems to
 break the support for the device or it seems it has never worked for
 DVB-T.

 Cheers,
 -olli



 On 3 February 2015 at 11:42, Francesco Other francesco.ot...@gmail.com 
 wrote:
 Maybe when Doron Cohen wrote the patch the device worked fine but now,
 after that someone change the code for their own enjoyment, it
 doesn't.

 If you read my question you will find that the device has signal lock
 but no data stream. There isn't need to write a code from scratch
 because I have the working firmware that kernel asks for.

 I don't know what the problem is, I'm an aerospace engineer not a
 software engineer.

 Best Regards

 Francesco


 2015-02-03 9:06 GMT+01:00 Olli Salonen olli.salo...@iki.fi:
 Hi Francesco,

 You need to understand that many people write code for their own
 enjoyment. In other words, they often write code to scratch an itch.
 Thus it can sometimes happen that there really is no-one here who
 could help you. The person who wrote the code originally might have
 stopped contributing and is more interested in gardening or
 kiteboarding these days. Maybe no-one here just has heard of the
 device you're talking about or owns one.

 Anyway, I did some digging for you. The support for your device was
 originally added based on this patch
 https://patchwork.linuxtv.org/patch/7881/ submitted by Doron Cohen
 dor...@siano-ms.com. It seems he's working for the Siano company
 itself. Have you tried contacting them already?

 Cheers,
 -olli

 On 2 February 2015 at 15:10, Francesco Other francesco.ot...@gmail.com 
 wrote:
 Is it possible that the problem I explained here isn't interesting for 
 anyone?

 The device is supported by kernel but obviously there is a bug with DVB-T.

 I have the working firmware (on Windows) for DVB-T if you need it.

 http://www.spinics.net/lists/linux-media/msg85505.html

 http://www.spinics.net/lists/linux-media/msg85478.html

 http://www.spinics.net/lists/linux-media/msg85432.html

 Regards

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

Re: [BUG] - Why anyone fix this problem?

[Olli Salonen]

Hi Francesco,

You need to understand that many people write code for their own
enjoyment. In other words, they often write code to scratch an itch.
Thus it can sometimes happen that there really is no-one here who
could help you. The person who wrote the code originally might have
stopped contributing and is more interested in gardening or
kiteboarding these days. Maybe no-one here just has heard of the
device you're talking about or owns one.

Anyway, I did some digging for you. The support for your device was
originally added based on this patch
https://patchwork.linuxtv.org/patch/7881/ submitted by Doron Cohen
dor...@siano-ms.com. It seems he's working for the Siano company
itself. Have you tried contacting them already?

Cheers,
-olli

On 2 February 2015 at 15:10, Francesco Other francesco.ot...@gmail.com wrote:
 Is it possible that the problem I explained here isn't interesting for anyone?

 The device is supported by kernel but obviously there is a bug with DVB-T.

 I have the working firmware (on Windows) for DVB-T if you need it.

 http://www.spinics.net/lists/linux-media/msg85505.html

 http://www.spinics.net/lists/linux-media/msg85478.html

 http://www.spinics.net/lists/linux-media/msg85432.html

 Regards

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

Re: Re: [BUG, workaround] HVR-2200/saa7164 problem with C7 power state

[dcr...@telefonica.net]

 Mensaje original 
De : st...@kernellabs.com
Fecha : 02/02/2015 - 16:39 (GMT)
Para : dcr...@telefonica.net
CC : linux-media@vger.kernel.org
Asunto : Re: [BUG, workaround] HVR-2200/saa7164 problem with C7 power state

Basically, it starts working but after a while I get an Event timed out 
message and several i2c errors and VDR shuts down (some hours after reboot). 
As the web page mentions, I tested downgrading the PCIe bandwith from GEN2 
to GEN1 without success. But after playing with different BIOS options, what 
did the trick was limiting the power-saving C-states. If I select C7 as 
the maximum C-state, the card fails as described. After limiting the maximum 
C-state to C6, it has been working for a whole weekend.

Good feedback on the C7 vs C6 power state, thanks.

You are welcome, Steve. Happy to be helpful.

I will be at your disposal for testing purposes, if you need.

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