Re: SAA716x DVB driver

[Tycho Lürsen]

Hi Soeren


Op 25-01-18 om 20:56 schreef Soeren Moch:

Hi all,

I know anything about this driver. I'm still ready to maintain this, in
fact I'm doing this for years.
Why do you look for another maintainer instead of supporting my pull
request?

I did support your pull request, still do!
The reason for looking for another maintainer is that you said that it 
makes no sense maintaining this driver in-tree when your ff part is not 
supported. And Mauro still does not want to merge it as is, due to that 
ff part of the driver.

  In the long lasting discussion about this there was not a
single technical reason why this driver cannot be merged as is,
especially in staging as first step to do the required cleanup.

Regards,
Soeren

On 25.01.2018 18:08, Jemma Denson wrote:

Hi Tycho,

On 20/01/18 15:49, Tycho Lürsen wrote:

Right, but we still need a maintainer. Are you capable/willing to
volunteer for the job?

If no-one else will then yes I can, but I can't claim to know these devices
inside out. It would really depend on what's required of a maintainer, I'm
struggling to find this documented anywhere.

Cards I can't test with would really need someone to be able to add a
tested-by to verify they work.


I think that your proposal to use a stripped version of Luis Alves
repo is a no go, since it contains a couple of demod/tuner drivers
that are not upstreamed yet. That complicates the upstreaming process
too much, I think.

Oh, I would have stripped it *right* down and removed every card except
my TBS6280. The end result would probably be pretty close to Soeren's at
that point anyway, so I was starting to think like what you've done and
base it on that instead.

If you want, I can strip the driver down a lot more and ad back the
drivers you need. Just tell me what it is you need.

As above, it's really just a case of making it maintainable. If someone
can step forward and ack for them working then they could be included
but if not then I think it's best dropping them until that happens.


Jemma.

Cheers,
Tycho.

Re: SAA716x DVB driver

[Tycho Lürsen]

Hi Jemma,


Op 19-01-18 om 16:11 schreef Jemma Denson:

Hi Tycho,

On 19/01/18 13:59, Tycho Lürsen wrote:

Hi Jemma,

I'm with you: let's get merged at least something!

Did you find  a maintainer for this driver?
I can do simple stuff like in my fork of Soeren Moch's repo, but thats
where it ends. I dont have the knowledge needed to maintain a driver.

Not yet, but I can't really say I've been looking - unfortunately real
life got in the way of anything over christmas. I'm not sure I do
either, but it really depends on what's required. From what I can see
from maintaining another driver then as long as the driver is working
there's not a whole lot to do.
Right, but we still need a maintainer. Are you capable/willing to 
volunteer for the job?



I think that your proposal to use a stripped version of Luis Alves
repo is a no go, since it contains a couple of demod/tuner drivers
that are not upstreamed yet. That complicates the upstreaming process
too much, I think.

Oh, I would have stripped it *right* down and removed every card except
my TBS6280. The end result would probably be pretty close to Soeren's at
that point anyway, so I was starting to think like what you've done and
base it on that instead.
If you want, I can strip the driver down a lot more and ad back the 
drivers you need. Just tell me what it is you need.



I used a stripped version of Soeren Moch's repo to prove its stability
instead, adding the drivers I need so I can test it. You can see what
I did at :
https://github.com/bas-t/linux-saa716x/commits/for-media-stripped

This has been tested with linux 4.9.77, 4.14.14 and 4.15-rc8.
Works like a charm for me.


Looks like a good start, I'd be tempted to remove all the other cards
though unless you have them available to test with. Keeps the submission
simpler and less to worry about, they can be added back in later if
someone has an itch to scratch (and hardware to test with!).

Isn't that a bit drastic?
I mean: those few drivers have been there for ages, and I can't recall 
anyone complaining about them in a serious way.


I do have a few other tbs 716x cards available here at work so might be
able to test some others out, but we're a bit busy at the moment so
would have to be on my own time and there's not much of that available
at the moment either :(
As I said: give me the numbers of your tbs cards and I will add support 
for them (if they are supported by Luis Alves repo).
That way you are able to test the stability of the saa716x driver in 
it's present state.



Jemma.

Tycho.

SAA716x DVB driver

[Tycho Lürsen]

Hi Jemma,

I'm with you: let's get merged at least something!

Did you find  a maintainer for this driver?
I can do simple stuff like in my fork of Soeren Moch's repo, but thats 
where it ends. I dont have the knowledge needed to maintain a driver.


I think that your proposal to use a stripped version of Luis Alves repo 
is a no go, since it contains a couple of demod/tuner drivers that are 
not upstreamed yet. That complicates the upstreaming process too much, I 
think.


I used a stripped version of Soeren Moch's repo to prove its stability 
instead, adding the drivers I need so I can test it. You can see what I 
did at : https://github.com/bas-t/linux-saa716x/commits/for-media-stripped


This has been tested with linux 4.9.77, 4.14.14 and 4.15-rc8.
Works like a charm for me.

Re: [GIT PULL] SAA716x DVB driver

[Tycho Lürsen]

Hi Mauro,

afaik the last communication about submission of this driver was about 
two months ago.


This driver is important to me, because I own several TurboSight cards 
that are saa716x based. I want to submit a patch that supports my cards. 
Of course I can only do so when you accept this driver in the first place.


Any chance you and Sören agree about how to proceed about this driver 
anytime soon?


Regards,

Tycho


Op 25-09-17 om 00:17 schreef Soeren Moch:

On 16.09.2017 19:49, Mauro Carvalho Chehab wrote:

Em Sat, 16 Sep 2017 14:54:15 +0200
Soeren Moch  escreveu:


On 09.09.2017 23:20, Mauro Carvalho Chehab wrote:

Em Sat, 9 Sep 2017 14:52:18 +0200
Soeren Moch  escreveu:
  

You explicitly
want to discourage new driver and application implementations.

Me? It is just the opposite: sticking with a poorly documented API
that almost nobody knows seems to be what discouraged new drivers
and applications.

OK, then you are fine to keep the audio/video/osd API in this driver, great!

My current understanding is that keeping audio/video API doesn't make
any sense, for a couple of reasons:

For me, keeping this interface makes a lot of sense.

1. it was never fully documented;

Nothing what prevents existing drivers to work, and new drivers
to be written, as can be seen from this pull request.

2. the only upstream hardware that supports them was developed on
about 17 years ago;

But was sold for several years in lots of different versions,
even hardware modifications were developed and applied
by lots of users to improve the performance of these cards,
and most important, these cards are still in use.

3. the API is broken with regards to compat32 and Y2038 (see more
below);

Not unique for this driver and, since this API has no business
with wall clock time, not too complicated to fix.

4. almost all (if not all) features they support are also supported
by V4L2 and ALSA;

Here we come to the point. The DVB audio/video API just
works, there are working drivers, working applications (vdr)
and happy users.
The audio/video/osd device nodes are nicely grouped below
1 adapter, so it is immediately clear, which devices belong
together. It is very easy to implement the classic multimedia
set-top box use case (audio and video decoding with menu
overlays). For this use case it is the ideal interface.

You propose V4L2/ALSA instead, what has "almost all features".
May be, but "almost all" is not all, and a collection of features
does not give us a working system. /dev/videoX device names
are not stable across boots, it is even more complicated to
find matching devices for different hardware with otherwise
similar capabilities. With V4L2/ALSA there is no real A/V
synchronisation, selected ALSA devices are reassigned during
suspend or even HDMI hotplug. So audio gets lost when
switching the monitor off and on again.

So while audio/video/osd is an integrated multimedia
interface with working drivers and happy users, for me
V4L2/ALSA is not ready to immediately replace it.


5. V4L2 supports a lot more features that video decoders support
than video API, like H.264 and other newer video standards, plus
HDMI setup features.

The S2-6400 card also decodes H.264, and the API is not
limited to any set of video coding standards. This card
decodes frame synchronous audio and video and correctly
signals audio/video formats in HDMI AVI frames  (e.g.
AC3 / PCM audio, video aspect ratios,...). You did not explain
how this should work with V4L2/ALSA.

For other use cases other types of v4l2 devices could be
more appropriate. The two APIs coexist for years in
mainline linux without problems.

In the past, we tried a lot to get documentation for those
DVB APIs, but, unfortunately, nobody that worked on its development
sent us patches addressing the API documentation.

You probably know why the ttpci developers stopped
sending patches to linux-media.

With regards to OSD, as no other documented API emerged to
fulfill what it does, it could make sense to keep it, if
someone properly documents it.


With linux core APIs for FF you probably mean some new
API combination as successor of the audio/video/osd API.
The S2-6400 unfortunately directly implements the old API
in hardware and is therefore the worst possible match for
such new driver generation.

It sounds weird that the API is directly implemented in hardware.
I can't tell much, though, as I didn't see the code yet.

All the available code is in this pull request.

I know. I'll look on it if we reach an agreement.


I really don't understand your Kaffeine use case. Kaffeine is a media
player, which displays the decoded video on a KDE/Gnome desktop.
With the S2-6400 it is not possible to read the decoded video back,
so it is not possible to display something in a desktop window.
I cannot image what you want to do with this hardware and Kaffeine.

I see.


One alternative we could do would be to add the proper APIs for the

Re: cx23885: use pci_set_dma_mask insted of pci_dma_supported

[Tycho Lürsen]

Hi Christoph,
thanks, will do and report back shortly.

Op 18-11-15 om 16:08 schreef Christoph Hellwig:

Hi Tycho,

please try the patch below - Andrew should be sending it on to Linux soon.

---
 From 4c03a9f77104b04af45833e0424954191ca94a12 Mon Sep 17 00:00:00 2001
From: Christoph Hellwig 
Date: Wed, 11 Nov 2015 18:13:09 +0100
Subject: various: fix pci_set_dma_mask return value checking

pci_set_dma_mask returns a negative errno value, not a bool
like pci_dma_supported.  This of course was just a giant test
for attention :)

Reported-by: Jongman Heo 
Tested-by: Jongman Heo   [pcnet32]
Signed-off-by: Christoph Hellwig 
---
  drivers/media/pci/cx23885/cx23885-core.c   | 4 ++--
  drivers/media/pci/cx25821/cx25821-core.c   | 3 ++-
  drivers/media/pci/cx88/cx88-alsa.c | 4 ++--
  drivers/media/pci/cx88/cx88-mpeg.c | 3 ++-
  drivers/media/pci/cx88/cx88-video.c| 4 ++--
  drivers/media/pci/netup_unidvb/netup_unidvb_core.c | 2 +-
  drivers/media/pci/saa7134/saa7134-core.c   | 4 ++--
  drivers/media/pci/saa7164/saa7164-core.c   | 4 ++--
  drivers/media/pci/tw68/tw68-core.c | 4 ++--
  drivers/net/ethernet/amd/pcnet32.c | 5 +++--
  10 files changed, 20 insertions(+), 17 deletions(-)

diff --git a/drivers/media/pci/cx23885/cx23885-core.c 
b/drivers/media/pci/cx23885/cx23885-core.c
index 35759a9..e8f8472 100644
--- a/drivers/media/pci/cx23885/cx23885-core.c
+++ b/drivers/media/pci/cx23885/cx23885-core.c
@@ -1992,9 +1992,9 @@ static int cx23885_initdev(struct pci_dev *pci_dev,
(unsigned long long)pci_resource_start(pci_dev, 0));
  
  	pci_set_master(pci_dev);

-   if (!pci_set_dma_mask(pci_dev, 0x)) {
+   err = pci_set_dma_mask(pci_dev, 0x);
+   if (err) {
printk("%s/0: Oops: no 32bit PCI DMA ???\n", dev->name);
-   err = -EIO;
goto fail_context;
}
  
diff --git a/drivers/media/pci/cx25821/cx25821-core.c b/drivers/media/pci/cx25821/cx25821-core.c

index dbc695f..0042803 100644
--- a/drivers/media/pci/cx25821/cx25821-core.c
+++ b/drivers/media/pci/cx25821/cx25821-core.c
@@ -1319,7 +1319,8 @@ static int cx25821_initdev(struct pci_dev *pci_dev,
dev->pci_lat, (unsigned long long)dev->base_io_addr);
  
  	pci_set_master(pci_dev);

-   if (!pci_set_dma_mask(pci_dev, 0x)) {
+   err = pci_set_dma_mask(pci_dev, 0x);
+   if (err) {
pr_err("%s/0: Oops: no 32bit PCI DMA ???\n", dev->name);
err = -EIO;
goto fail_irq;
diff --git a/drivers/media/pci/cx88/cx88-alsa.c 
b/drivers/media/pci/cx88/cx88-alsa.c
index 0ed1b65..1b5268f 100644
--- a/drivers/media/pci/cx88/cx88-alsa.c
+++ b/drivers/media/pci/cx88/cx88-alsa.c
@@ -890,9 +890,9 @@ static int snd_cx88_create(struct snd_card *card, struct 
pci_dev *pci,
return err;
}
  
-	if (!pci_set_dma_mask(pci,DMA_BIT_MASK(32))) {

+   err = pci_set_dma_mask(pci,DMA_BIT_MASK(32));
+   if (err) {
dprintk(0, "%s/1: Oops: no 32bit PCI DMA ???\n",core->name);
-   err = -EIO;
cx88_core_put(core, pci);
return err;
}
diff --git a/drivers/media/pci/cx88/cx88-mpeg.c 
b/drivers/media/pci/cx88/cx88-mpeg.c
index 9db7767..f34c229 100644
--- a/drivers/media/pci/cx88/cx88-mpeg.c
+++ b/drivers/media/pci/cx88/cx88-mpeg.c
@@ -393,7 +393,8 @@ static int cx8802_init_common(struct cx8802_dev *dev)
if (pci_enable_device(dev->pci))
return -EIO;
pci_set_master(dev->pci);
-   if (!pci_set_dma_mask(dev->pci,DMA_BIT_MASK(32))) {
+   err = pci_set_dma_mask(dev->pci,DMA_BIT_MASK(32));
+   if (err) {
printk("%s/2: Oops: no 32bit PCI DMA ???\n",dev->core->name);
return -EIO;
}
diff --git a/drivers/media/pci/cx88/cx88-video.c 
b/drivers/media/pci/cx88/cx88-video.c
index 0de1ad5..aef9acf 100644
--- a/drivers/media/pci/cx88/cx88-video.c
+++ b/drivers/media/pci/cx88/cx88-video.c
@@ -1314,9 +1314,9 @@ static int cx8800_initdev(struct pci_dev *pci_dev,
   dev->pci_lat,(unsigned long long)pci_resource_start(pci_dev,0));
  
  	pci_set_master(pci_dev);

-   if (!pci_set_dma_mask(pci_dev,DMA_BIT_MASK(32))) {
+   err = pci_set_dma_mask(pci_dev,DMA_BIT_MASK(32));
+   if (err) {
printk("%s/0: Oops: no 32bit PCI DMA ???\n",core->name);
-   err = -EIO;
goto fail_core;
}
dev->alloc_ctx = vb2_dma_sg_init_ctx(_dev->dev);
diff --git a/drivers/media/pci/netup_unidvb/netup_unidvb_core.c 
b/drivers/media/pci/netup_unidvb/netup_unidvb_core.c
index 60b2d46..3fdbd81 100644
--- a/drivers/media/pci/netup_unidvb/netup_unidvb_core.c
+++ b/drivers/media/pci/netup_unidvb/netup_unidvb_core.c
@@ -810,7 +810,7 @@ static int 

Re: cx23885: use pci_set_dma_mask insted of pci_dma_supported

[Tycho Lürsen]

Hi Christoph,
that additional patch fixed the problem indeed.
Thanks again.

Regards, Tycho

Op 18-11-15 om 17:34 schreef Tycho Lürsen:

Hi Christoph,
thanks, will do and report back shortly.

Op 18-11-15 om 16:08 schreef Christoph Hellwig:

Hi Tycho,

please try the patch below - Andrew should be sending it on to Linux 
soon.


---
 From 4c03a9f77104b04af45833e0424954191ca94a12 Mon Sep 17 00:00:00 2001
From: Christoph Hellwig <h...@lst.de>
Date: Wed, 11 Nov 2015 18:13:09 +0100
Subject: various: fix pci_set_dma_mask return value checking

pci_set_dma_mask returns a negative errno value, not a bool
like pci_dma_supported.  This of course was just a giant test
for attention :)

Reported-by: Jongman Heo <jongman@samsung.com>
Tested-by: Jongman Heo <jongman@samsung.com> [pcnet32]
Signed-off-by: Christoph Hellwig <h...@lst.de>
---
  drivers/media/pci/cx23885/cx23885-core.c   | 4 ++--
  drivers/media/pci/cx25821/cx25821-core.c   | 3 ++-
  drivers/media/pci/cx88/cx88-alsa.c | 4 ++--
  drivers/media/pci/cx88/cx88-mpeg.c | 3 ++-
  drivers/media/pci/cx88/cx88-video.c| 4 ++--
  drivers/media/pci/netup_unidvb/netup_unidvb_core.c | 2 +-
  drivers/media/pci/saa7134/saa7134-core.c   | 4 ++--
  drivers/media/pci/saa7164/saa7164-core.c   | 4 ++--
  drivers/media/pci/tw68/tw68-core.c | 4 ++--
  drivers/net/ethernet/amd/pcnet32.c | 5 +++--
  10 files changed, 20 insertions(+), 17 deletions(-)

diff --git a/drivers/media/pci/cx23885/cx23885-core.c 
b/drivers/media/pci/cx23885/cx23885-core.c

index 35759a9..e8f8472 100644
--- a/drivers/media/pci/cx23885/cx23885-core.c
+++ b/drivers/media/pci/cx23885/cx23885-core.c
@@ -1992,9 +1992,9 @@ static int cx23885_initdev(struct pci_dev 
*pci_dev,

  (unsigned long long)pci_resource_start(pci_dev, 0));
pci_set_master(pci_dev);
-if (!pci_set_dma_mask(pci_dev, 0x)) {
+err = pci_set_dma_mask(pci_dev, 0x);
+if (err) {
  printk("%s/0: Oops: no 32bit PCI DMA ???\n", dev->name);
-err = -EIO;
  goto fail_context;
  }
  diff --git a/drivers/media/pci/cx25821/cx25821-core.c 
b/drivers/media/pci/cx25821/cx25821-core.c

index dbc695f..0042803 100644
--- a/drivers/media/pci/cx25821/cx25821-core.c
+++ b/drivers/media/pci/cx25821/cx25821-core.c
@@ -1319,7 +1319,8 @@ static int cx25821_initdev(struct pci_dev 
*pci_dev,

  dev->pci_lat, (unsigned long long)dev->base_io_addr);
pci_set_master(pci_dev);
-if (!pci_set_dma_mask(pci_dev, 0x)) {
+err = pci_set_dma_mask(pci_dev, 0x);
+if (err) {
  pr_err("%s/0: Oops: no 32bit PCI DMA ???\n", dev->name);
  err = -EIO;
  goto fail_irq;
diff --git a/drivers/media/pci/cx88/cx88-alsa.c 
b/drivers/media/pci/cx88/cx88-alsa.c

index 0ed1b65..1b5268f 100644
--- a/drivers/media/pci/cx88/cx88-alsa.c
+++ b/drivers/media/pci/cx88/cx88-alsa.c
@@ -890,9 +890,9 @@ static int snd_cx88_create(struct snd_card *card, 
struct pci_dev *pci,

  return err;
  }
  -if (!pci_set_dma_mask(pci,DMA_BIT_MASK(32))) {
+err = pci_set_dma_mask(pci,DMA_BIT_MASK(32));
+if (err) {
  dprintk(0, "%s/1: Oops: no 32bit PCI DMA ???\n",core->name);
-err = -EIO;
  cx88_core_put(core, pci);
  return err;
  }
diff --git a/drivers/media/pci/cx88/cx88-mpeg.c 
b/drivers/media/pci/cx88/cx88-mpeg.c

index 9db7767..f34c229 100644
--- a/drivers/media/pci/cx88/cx88-mpeg.c
+++ b/drivers/media/pci/cx88/cx88-mpeg.c
@@ -393,7 +393,8 @@ static int cx8802_init_common(struct cx8802_dev 
*dev)

  if (pci_enable_device(dev->pci))
  return -EIO;
  pci_set_master(dev->pci);
-if (!pci_set_dma_mask(dev->pci,DMA_BIT_MASK(32))) {
+err = pci_set_dma_mask(dev->pci,DMA_BIT_MASK(32));
+if (err) {
  printk("%s/2: Oops: no 32bit PCI DMA ???\n",dev->core->name);
  return -EIO;
  }
diff --git a/drivers/media/pci/cx88/cx88-video.c 
b/drivers/media/pci/cx88/cx88-video.c

index 0de1ad5..aef9acf 100644
--- a/drivers/media/pci/cx88/cx88-video.c
+++ b/drivers/media/pci/cx88/cx88-video.c
@@ -1314,9 +1314,9 @@ static int cx8800_initdev(struct pci_dev *pci_dev,
 dev->pci_lat,(unsigned long 
long)pci_resource_start(pci_dev,0));

pci_set_master(pci_dev);
-if (!pci_set_dma_mask(pci_dev,DMA_BIT_MASK(32))) {
+err = pci_set_dma_mask(pci_dev,DMA_BIT_MASK(32));
+if (err) {
  printk("%s/0: Oops: no 32bit PCI DMA ???\n",core->name);
-err = -EIO;
  goto fail_core;
  }
  dev->alloc_ctx = vb2_dma_sg_init_ctx(_dev->dev);
diff --git a/drivers/media/pci/netup_unidvb/netup_unidvb_core.c 
b/drivers/media/pci/netup_unidvb/netup_unidvb_core.c

index 60b2d46..3fdbd81 100644
--- a/drivers/media/pci/netup_unidvb/netup_uni

cx23885: use pci_set_dma_mask insted of pci_dma_supported

[Tycho Lürsen]

Hi Christoph,
I own a couple of DVBSky T982 cards, and with your latest patch I can't 
use them anymore.

When the driver loads, it spits this:

[   16.851869] cx23885 driver version 0.0.4 loaded
[   16.852012] CORE cx23885[0]: subsystem: 4254:0982, board: DVBSky T982 
[card=51,autodetected]
[   17.080771] cx25840 11-0044: cx23885 A/V decoder found @ 0x88 
(cx23885[0])
[   17.713272] cx25840 11-0044: loaded v4l-cx23885-avcore-01.fw firmware 
(16382 bytes)

[   17.728982] cx23885_dvb_register() allocating 1 frontend(s)
[   17.728986] cx23885[0]: cx23885 based dvb card
[   17.730007] i2c i2c-10: Added multiplexed i2c bus 12
[   17.730009] si2168 10-0064: Silicon Labs Si2168 successfully attached
[   17.731970] si2157 12-0060: Silicon Labs Si2147/2148/2157/2158 
successfully attached

[   17.731976] DVB: registering new adapter (cx23885[0])
[   17.731979] cx23885 :02:00.0: DVB: registering adapter 1 frontend 
0 (Silicon Labs Si2168)...

[   17.760401] DVBSky T982 port 1 MAC address: 00:17:42:54:09:87
[   17.760404] cx23885_dvb_register() allocating 1 frontend(s)
[   17.760406] cx23885[0]: cx23885 based dvb card
[   17.761028] i2c i2c-9: Added multiplexed i2c bus 13
[   17.761030] si2168 9-0064: Silicon Labs Si2168 successfully attached
[   17.762782] si2157 13-0060: Silicon Labs Si2147/2148/2157/2158 
successfully attached

[   17.762791] DVB: registering new adapter (cx23885[0])
[   17.762794] cx23885 :02:00.0: DVB: registering adapter 2 frontend 
0 (Silicon Labs Si2168)...

[   17.791455] DVBSky T982 port 2 MAC address: 00:17:42:54:09:88
[   17.791461] cx23885_dev_checkrevision() Hardware revision = 0xa5
[   17.791465] cx23885[0]/0: found at :02:00.0, rev: 4, irq: 19, 
latency: 0, mmio: 0xf780

[   17.791469] cx23885[0]/0: Oops: no 32bit PCI DMA ???
[   17.795970] cx23885: probe of :02:00.0 failed with error -5

I guess your patch is ok, so what could be going on?
Kind regards,
Tycho Lürsen

--
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: Hauppauge WinTV-HVR2205 driver feedback

[Tycho Lürsen]

Op 11-10-15 om 08:18 schreef Richard Tresidder:

Hi Again
  Yep that fixed pulling in the saa7164: si2168 frontends:

[ 6778.591548] i2c i2c-15: Added multiplexed i2c bus 16
[ 6778.591556] si2168 15-0064: Silicon Labs Si2168 successfully attached
[ 6778.596252] si2157 13-0060: Silicon Labs Si2147/2148/2157/2158
successfully attached
[ 6778.597229] DVB: registering new adapter (saa7164)
YAY!!

Bottoms up!


What a painful process... first time I built the kernel from the rpm
source I must have stuffed something up and the resultant installed
rpm didn't have the module turned on.. aaagggh...
Trying to rebuild the srpm again after tweaking the .config file and
copying it around to the various locations again just didn't work..
Eventually gave up and had to rip it all out and start afresh..
It's not that hard once you get the hang of it. I had to recompile 
anyway, as I need saa716x, dvbloopback and backported drivers for DVBSky 
T982, plus I need more then 8 dvb adapters. Semi-automated this of course:

https://github.com/bas-t/centos7-kernel


Well spotted on that one.. What a pain that the call to the i2c mux
create didn't result in a error :/

Now I just need to shutoff kernel updates..
Really need to push this up into the centos config.. I've noted that
it has been turned back on in other releases..
Will submit a bug.

Excellent idea. But as stated, I'll have to recompile anyway...


Regards
   Richard Tresidder

On 05/10/15 20:45, Tycho Lürsen wrote:

Hi, not sure if this is related.
I had to recompile the centos7 stock kernel with:
CONFIG_I2C_MUX=m

It was not enabled in the kernel config.

Op 04-10-15 om 06:55 schreef Richard Tresidder:

Sorry If I've posted this to the wrong section my first attempt..

Hi
   I'm attempting to get an HVR2205 up and going.
CORE saa7164[1]: subsystem: 0070:f120, board: Hauppauge
WinTV-HVR2205 [card=13,autodetected]
Distribution is CentOS7 so I've pulled the v4l from media_build.git
Had to change a couple of things..  and another macro issue
regarding clamp() ..
Seems the kzalloc(4 * 1048576, GFP_KERNEL) in saa7164-fw.c was
failing..
kept getting:  kernel: modprobe: page allocation failure: order:10,
mode:0x10c0d0
Have plenty of RAM free so surprised about that one.. tried some of
the tricks re increasing the vm.min_free_kbytes etc..

Any way I modified the routine to only allocate a single chunk
buffer based on dstsize and tweaked the chunk handling code..
seemed to fix that one.. fw downloaded and seemed to boot ok..

Next I'm running into a problem with the saa7164_dvb_register()
stage...

saa7164[1]: Hauppauge eeprom: model=151609
saa7164_dvb_register() Frontend/I2C initialization failed
saa7164_initdev() Failed to register dvb adapters on porta

I added some extra debug and identified that
client_demod->dev.driver is null..

However I'm now stuck as to what to tackle next..

I can provide more info, just didn't want to spam the list for my
first email..

Regards
   Richard Tresidder
--
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: Hauppauge WinTV-HVR2205 driver feedback

[Tycho Lürsen]

Hi, not sure if this is related.
I had to recompile the centos7 stock kernel with:
CONFIG_I2C_MUX=m

It was not enabled in the kernel config.

Op 04-10-15 om 06:55 schreef Richard Tresidder:

Sorry If I've posted this to the wrong section my first attempt..

Hi
   I'm attempting to get an HVR2205 up and going.
CORE saa7164[1]: subsystem: 0070:f120, board: Hauppauge WinTV-HVR2205 
[card=13,autodetected]

Distribution is CentOS7 so I've pulled the v4l from media_build.git
Had to change a couple of things..  and another macro issue regarding 
clamp() ..

Seems the kzalloc(4 * 1048576, GFP_KERNEL) in saa7164-fw.c  was failing..
kept getting:  kernel: modprobe: page allocation failure: order:10, 
mode:0x10c0d0
Have plenty of RAM free so surprised about that one.. tried some of 
the tricks re increasing the vm.min_free_kbytes etc..


Any way I modified the routine to only allocate a single chunk buffer 
based on dstsize and tweaked the chunk handling code..

seemed to fix that one.. fw downloaded and seemed to boot ok..

Next I'm running into a problem with the saa7164_dvb_register() stage...

saa7164[1]: Hauppauge eeprom: model=151609
saa7164_dvb_register() Frontend/I2C initialization failed
saa7164_initdev() Failed to register dvb adapters on porta

I added some extra debug and identified that client_demod->dev.driver 
is null..


However I'm now stuck as to what to tackle next..

I can provide more info, just didn't want to spam the list for my 
first email..


Regards
   Richard Tresidder
--
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: DVBSky T980C CI issues (kernel 4.0.x)

[Tycho Lürsen]

Op 11-09-15 om 22:01 schreef Torbjorn Jansson:


did you get it to work?

i got a dvbsky T980C too for dvb-t2 reception and so far the only 
drivers that have worked at all is the ones from dvbsky directly.


i was very happy when i noticed that recent kernels have support for 
it built in but unfortunately only the modules and firmware loads but 
then nothing actually works.
i use mythtv and it complains a lot about the signal, running femon 
also produces lots of errors.


so i had to switch back to kernel 4.0.4 with mediabuild from dvbsky.

if there were any other dvb-t2 card with ci support that had better 
drivers i would change right away.


one problem i have with the mediabuilt from dvbsky is that at boot the 
cam never works and i have to first tune a channel, then remove and 
reinstert the cam to get it to work.

without that nothing works.

and finally a problem i ran into when i tried mediabuilt from 
linuxtv.org.
fedora uses kernel modules with .ko.xz extension so when you install 
the mediabuilt modulels you get one modulename.ko and one modulename.ko.xz


before a make install from mediabuild overwrote the needed modules.
any advice on how to handle this now?

You could patch the Makefile with a patch from Oliver Endriss (attached).
This way all modules get installed in /lib/modules/`uname -r`/updates/media
If your kernel needs it, you can compress them afterwards.



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


--- v4l/Makefile	2013-11-27 16:15:21.528260850 +0100
+++ v4l/Makefile	2013-11-27 16:24:37.171815316 +0100
@@ -154,6 +154,7 @@
 PWD		:= $(shell pwd)
 DEST		:= /lib/modules/$(KERNELRELEASE)/v4l2
 KDIR26		:= /lib/modules/$(KERNELRELEASE)/kernel/drivers/media
+INSTDIR 	:= $(DESTDIR)/lib/modules/$(KERNELRELEASE)/updates/media
 
 #
 # Compiler fixup rules
@@ -202,9 +203,18 @@
 #
 # installation invocation rules
 
-modules_install install:: media-install firmware_install
-
-remove rminstall:: media-rminstall
+modules_install install:: rminstall firmware_install
+	install -d -v $(INSTDIR)
+	@for i in *.ko; do\
+		echo "install $$i -> $(INSTDIR)/";	\
+		install -p -m 644 $$i $(INSTDIR);	\
+	done;
+	strip --strip-debug $(INSTDIR)/*.ko
+	/sbin/depmod -a $(KERNELRELEASE) $(if $(DESTDIR),-b $(DESTDIR))
+
+remove rminstall::
+	@rm -Rfv $(INSTDIR)
+	/sbin/depmod -a $(KERNELRELEASE) $(if $(DESTDIR),-b $(DESTDIR))
 
 firmware_install::
 	make -C firmware install

Re: Adding support for three new Hauppauge HVR-1275 variants - testers reqd.

[Tycho Lürsen]

Op 22-07-15 om 14:55 schreef Steven Toth:

On Wed, Jul 22, 2015 at 3:15 AM, Tycho Lürsen tycholur...@gmail.com wrote:

Hi Steven,
I'm happy to inform you that all failures have vanished.

Thanks.


Summarizing:
I compiled 4.2-RC3 with your patch and with

/* Tri-state the TS bus */
  si2168_set_ts_mode(fe, 0);

What happens if you revert this back to the code from my original
patch, and include your changes listed below?

IE:
/* Tri-state the TS bus */
si2168_set_ts_mode(fe, 1);

1) Do you still lock no signal lock issues.

MythTV  says 'no lock' (though I don't know if such a message is reliable)

2) Do you see normal video as you'd typically expect?

Nope, just a black screen.
Did not test it with TVheadend.
However, in MythTV (0.27.4) the line

si2168_set_ts_mode(fe, 0);

makes it work.


Thanks for helping! :)


You're welcome.
--
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: Adding support for three new Hauppauge HVR-1275 variants - testers reqd.

[Tycho Lürsen]

Hi Steven,
I'm happy to inform you that all failures have vanished.

Summarizing:
I compiled 4.2-RC3 with your patch and with

/* Tri-state the TS bus */
 si2168_set_ts_mode(fe, 0);

changed the .delsys line in si2168.c to satisfy MythTV from

.delsys = {SYS_DVBT, SYS_DVBT2, SYS_DVBC_ANNEX_A},

to

.delsys = {SYS_DVBC_ANNEX_A, SYS_DVBT, SYS_DVBT2},

added the dvbloopback module (for descrambling with MythTV) and saa716x 
bridge driver (to support my TBS 6285 cards)


Result: lock and tune is just fine in both TVheadend and MythTV with TBS 
6285 as well as DVBSky T982 cards.


TBS 6285: saa716x+si2168+si2157
DVBSky T982: cx23885+si2168+si2157

Regards,
Tycho.

Op 21-07-15 om 21:00 schreef Steven Toth:

On Tue, Jul 21, 2015 at 2:07 PM, Tycho Lürsen tycholur...@gmail.com wrote:


Op 21-07-15 om 18:19 schreef Steven Toth:

On Tue, Jul 21, 2015 at 12:11 PM, Tycho Lürsen tycholur...@gmail.com
wrote:

Hi Steven,
I was too curious to wait for you and Antti to settle your differences,
so I
tested again against a 4.2-RC2
I did not disable DVB-T/T2, instead I reordered the lot. MythTV just sees
the first system in the .delsys line in si2168.c,
so when it looks like this:
SYS_DVBC_ANNEX_A, SYS_DVBT, SYS_DVBT2
I'm good.

We have no differences, its Antti's si2168 driver. If Antti doesn't
like the approach for tri-stating, he's free to suggest and
alternative. I suggested two alternatives yesterday.


Result:
With your patch both MythTV and Tvheadend still can't tune. Without it,
everything is ok.

I'm not very interested in czap results, only in real use cases. For me
that's MythTV, but just to be sure I also tested with TVheadend.

That's pretty bizarre results, although thank you for testing. :)

When you say it can't tune, do you mean the signal does not lock, or
that no video appears?


No lock, or partial lock.

Thanks.

That's even worse than expected, given that the patch adjusts the TS
interface, and has nothing to do with tuning, lock, rf or signal
status. It still feels like something else is going on, some other
unexpected race for example.

I can't reproduce that behavior, but given that you can Can you
please try this? in si2168.c, change:

  /* Tri-state the TS bus */
  si2168_set_ts_mode(fe, 1);

to

  /* Tri-state the TS bus */
  si2168_set_ts_mode(fe, 0);

... recompile and retest?

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: Adding support for three new Hauppauge HVR-1275 variants - testers reqd.

[Tycho Lürsen]

Hi Steven,
I was too curious to wait for you and Antti to settle your differences, 
so I tested again against a 4.2-RC2
I did not disable DVB-T/T2, instead I reordered the lot. MythTV just 
sees the first system in the .delsys line in si2168.c,

so when it looks like this:
SYS_DVBC_ANNEX_A, SYS_DVBT, SYS_DVBT2
I'm good.

Result:
With your patch both MythTV and Tvheadend still can't tune. Without it, 
everything is ok.


I'm not very interested in czap results, only in real use cases. For me 
that's MythTV, but just to be sure I also tested with TVheadend.


Regards,
Tycho.

Op 20-07-15 om 18:32 schreef Steven Toth:

On Mon, Jul 20, 2015 at 12:06 PM, Tycho Lürsen tycholur...@gmail.com wrote:

Hi Steven,
I was not aware of the fact that your patch depends on dvb-core as in
4.2-RC2 (and up, I guess)
I tested against 3.18.18 and 4.1.2. That might explain the failures.
Anyhow, as soon as Antti and you are on the same page regarding this patch,
I'll test again against a 4.2-RC1
Regards,
Tycho.

Thank you Tycho.

I specifically only tested on 4.2, with the entire tree. No attempt
was made to backport or otherwise test in environments outside on
prior kernels.

- Steve



--
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: Adding support for three new Hauppauge HVR-1275 variants - testers reqd.

[Tycho Lürsen]

Op 21-07-15 om 18:19 schreef Steven Toth:

On Tue, Jul 21, 2015 at 12:11 PM, Tycho Lürsen tycholur...@gmail.com wrote:

Hi Steven,
I was too curious to wait for you and Antti to settle your differences, so I
tested again against a 4.2-RC2
I did not disable DVB-T/T2, instead I reordered the lot. MythTV just sees
the first system in the .delsys line in si2168.c,
so when it looks like this:
SYS_DVBC_ANNEX_A, SYS_DVBT, SYS_DVBT2
I'm good.

We have no differences, its Antti's si2168 driver. If Antti doesn't
like the approach for tri-stating, he's free to suggest and
alternative. I suggested two alternatives yesterday.


Result:
With your patch both MythTV and Tvheadend still can't tune. Without it,
everything is ok.

I'm not very interested in czap results, only in real use cases. For me
that's MythTV, but just to be sure I also tested with TVheadend.

That's pretty bizarre results, although thank you for testing. :)

When you say it can't tune, do you mean the signal does not lock, or
that no video appears?


No lock, or partial lock.
--
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: Adding support for three new Hauppauge HVR-1275 variants - testers reqd.

[Tycho Lürsen]

Op 21-07-15 om 21:02 schreef Steven Toth:

On Tue, Jul 21, 2015 at 2:59 PM, Tycho Lürsen tycholur...@gmail.com wrote:


Op 21-07-15 om 20:07 schreef Tycho Lürsen:



Op 21-07-15 om 18:19 schreef Steven Toth:

On Tue, Jul 21, 2015 at 12:11 PM, Tycho Lürsen tycholur...@gmail.com
wrote:

Hi Steven,
I was too curious to wait for you and Antti to settle your differences,
so I
tested again against a 4.2-RC2
I did not disable DVB-T/T2, instead I reordered the lot. MythTV just
sees
the first system in the .delsys line in si2168.c,
so when it looks like this:
SYS_DVBC_ANNEX_A, SYS_DVBT, SYS_DVBT2
I'm good.

We have no differences, its Antti's si2168 driver. If Antti doesn't
like the approach for tri-stating, he's free to suggest and
alternative. I suggested two alternatives yesterday.


Result:
With your patch both MythTV and Tvheadend still can't tune. Without it,
everything is ok.

I'm not very interested in czap results, only in real use cases. For me
that's MythTV, but just to be sure I also tested with TVheadend.

That's pretty bizarre results, although thank you for testing. :)

When you say it can't tune, do you mean the signal does not lock, or
that no video appears?


No lock, or partial lock.

I've compiled a 4.2-RC3, this time without support for my TBS 6285 cards (so
no saa716x) and without dvbloopback kernel module (so no MythTV)


Result with your patch and only DVBSky T982 cards: TVheadend is fine with
it. Lock and tune are OK.
Going to test some more scenario's, I'll keep you informed.
Regards,
Tycho

Thank you sir.

In which case, please disregard my last email relating to changing:
  /* Tri-state the TS bus */
  si2168_set_ts_mode(fe, 1);

- Steve


I've screwed up, last test was without your patch, sorry.
I'll recompile with your suggested change.
--
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: Adding support for three new Hauppauge HVR-1275 variants - testers reqd.

[Tycho Lürsen]

Op 21-07-15 om 20:07 schreef Tycho Lürsen:



Op 21-07-15 om 18:19 schreef Steven Toth:
On Tue, Jul 21, 2015 at 12:11 PM, Tycho Lürsen 
tycholur...@gmail.com wrote:

Hi Steven,
I was too curious to wait for you and Antti to settle your 
differences, so I

tested again against a 4.2-RC2
I did not disable DVB-T/T2, instead I reordered the lot. MythTV just 
sees

the first system in the .delsys line in si2168.c,
so when it looks like this:
SYS_DVBC_ANNEX_A, SYS_DVBT, SYS_DVBT2
I'm good.

We have no differences, its Antti's si2168 driver. If Antti doesn't
like the approach for tri-stating, he's free to suggest and
alternative. I suggested two alternatives yesterday.


Result:
With your patch both MythTV and Tvheadend still can't tune. Without it,
everything is ok.

I'm not very interested in czap results, only in real use cases. For me
that's MythTV, but just to be sure I also tested with TVheadend.

That's pretty bizarre results, although thank you for testing. :)

When you say it can't tune, do you mean the signal does not lock, or
that no video appears?


No lock, or partial lock.
I've compiled a 4.2-RC3, this time without support for my TBS 6285 cards 
(so no saa716x) and without dvbloopback kernel module (so no MythTV)



Result with your patch and only DVBSky T982 cards: TVheadend is fine 
with it. Lock and tune are OK.

Going to test some more scenario's, I'll keep you informed.
Regards,
Tycho

--
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: Adding support for three new Hauppauge HVR-1275 variants - testers reqd.

[Tycho Lürsen]

Op 21-07-15 om 21:00 schreef Steven Toth:

On Tue, Jul 21, 2015 at 2:07 PM, Tycho Lürsen tycholur...@gmail.com wrote:


Op 21-07-15 om 18:19 schreef Steven Toth:

On Tue, Jul 21, 2015 at 12:11 PM, Tycho Lürsen tycholur...@gmail.com
wrote:

Hi Steven,
I was too curious to wait for you and Antti to settle your differences,
so I
tested again against a 4.2-RC2
I did not disable DVB-T/T2, instead I reordered the lot. MythTV just sees
the first system in the .delsys line in si2168.c,
so when it looks like this:
SYS_DVBC_ANNEX_A, SYS_DVBT, SYS_DVBT2
I'm good.

We have no differences, its Antti's si2168 driver. If Antti doesn't
like the approach for tri-stating, he's free to suggest and
alternative. I suggested two alternatives yesterday.


Result:
With your patch both MythTV and Tvheadend still can't tune. Without it,
everything is ok.

I'm not very interested in czap results, only in real use cases. For me
that's MythTV, but just to be sure I also tested with TVheadend.

That's pretty bizarre results, although thank you for testing. :)

When you say it can't tune, do you mean the signal does not lock, or
that no video appears?


No lock, or partial lock.

Thanks.

That's even worse than expected, given that the patch adjusts the TS
interface, and has nothing to do with tuning, lock, rf or signal
status. It still feels like something else is going on, some other
unexpected race for example.

I can't reproduce that behavior, but given that you can Can you
please try this? in si2168.c, change:

  /* Tri-state the TS bus */
  si2168_set_ts_mode(fe, 1);

to

  /* Tri-state the TS bus */
  si2168_set_ts_mode(fe, 0);

... recompile and retest?

Thx.

I recompiled and tested with this change (still without saa716x or 
dvbloopback) with TVheadend and all is well.
Going to test this with dvbloopback, and if all goes well with saa716x 
too. But not today.

Regards,
Tycho.
--
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: Adding support for three new Hauppauge HVR-1275 variants - testers reqd.

[Tycho Lürsen]

Hi Steven,
I was not aware of the fact that your patch depends on dvb-core as in 
4.2-RC2 (and up, I guess)

I tested against 3.18.18 and 4.1.2. That might explain the failures.
Anyhow, as soon as Antti and you are on the same page regarding this 
patch, I'll test again against a 4.2-RC1

Regards,
Tycho.

Op 20-07-15 om 15:13 schreef Steven Toth:

On Sun, Jul 19, 2015 at 3:34 AM, Tycho Lürsen tycholur...@gmail.com wrote:

Hi Steven,

Tested your si2186 patch with my DVBSky T982 and TBS 6285 cards using
European DVB-C
Since MythTV can't handle multistandard frontends (yet), I've disabled
DVB-T/T2 like this (I always do that):

sed -i 's/SYS_DVBT, SYS_DVBT2, SYS_DVBC_ANNEX_A/SYS_DVBC_ANNEX_A/'
drivers/media/dvb-frontends/si2168.c

Result: both DVBSky T982 and TBS 6285 drivers are broken, meaning no lock,
no tune.

Regards,
Tycho.

Op 19-07-15 om 00:21 schreef Steven Toth:

http://git.linuxtv.org/cgit.cgi/stoth/hvr1275.git/log/?h=hvr-1275

Patches above are available for test.

Antti, note the change to SI2168 to add support for enabling and
disabling the SI2168 transport bus dynamically.

I've tested with a combo card, switching back and forward between QAM
and DVB-T, this works fine, just remember to select a different
frontend as we have two frontends on the same adapter,
adapter0/frontend0 is QAM/8SVB, adapter0/frontend1 is DVB-T/T2.

If any testers have the ATSC or DVB-T, I'd expect these to work
equally well, replease report feedback here.

Thanks,

- Steve

Interesting, although I'm slightly confused.

My patch mere added the ability for dvb-core to tri-state the tsport
out bus, similar to other digital demodulator drivers in the tree
and testing with both azap and tzap (and dvbtraffic) showed no tuning,
lock or other issues.

What happens if you tzap/czap a known good frequency, before and after
my patch, without your sed replacement, leaving T/T2 and A fully
enabled?

- Steve



--
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: Adding support for three new Hauppauge HVR-1275 variants - testers reqd.

[Tycho Lürsen]

Hi Steven,

Tested your si2186 patch with my DVBSky T982 and TBS 6285 cards using 
European DVB-C
Since MythTV can't handle multistandard frontends (yet), I've disabled 
DVB-T/T2 like this (I always do that):


sed -i 's/SYS_DVBT, SYS_DVBT2, SYS_DVBC_ANNEX_A/SYS_DVBC_ANNEX_A/' 
drivers/media/dvb-frontends/si2168.c


Result: both DVBSky T982 and TBS 6285 drivers are broken, meaning no 
lock, no tune.


Regards,
Tycho.

Op 19-07-15 om 00:21 schreef Steven Toth:

http://git.linuxtv.org/cgit.cgi/stoth/hvr1275.git/log/?h=hvr-1275

Patches above are available for test.

Antti, note the change to SI2168 to add support for enabling and
disabling the SI2168 transport bus dynamically.

I've tested with a combo card, switching back and forward between QAM
and DVB-T, this works fine, just remember to select a different
frontend as we have two frontends on the same adapter,
adapter0/frontend0 is QAM/8SVB, adapter0/frontend1 is DVB-T/T2.

If any testers have the ATSC or DVB-T, I'd expect these to work
equally well, replease report feedback here.

Thanks,

- Steve



--
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: cx23885 risc op code error with DvbSKY T982

[Tycho Lürsen]

I've got a couple of T982 cards. Running Debian Jessie, with kernel 
4.1-rc8, I cannot reproduce your errors.

Only difference might be:
I synced the silabs drivers with upstream and used the patch from:

http://git.linuxtv.org/cgit.cgi/media_tree.git/patch/drivers/media/pci/cx23885/cx23885-dvb.c?id=ee3c3e46885946cc041f08ec68e7c5b91b087cbe

Cheers,
Tycho.

Op 22-06-15 om 11:43 schreef Jouni Karvo:

21.06.2015, 21:19, Jouni Karvo kirjoitti:
I have dvbsky T982.  The firmware is up to date from openelec site. 
Nothing on the CI slot



(actually, the empty CI-slot belongs to another card)

A couple of more of these for the same card.  Unless someone shows 
interest on these, this is the last one I'll send on the list on this 
card/error.


Jun 22 11:48:36 xpc kernel: [78360.929167] cx23885[0]: mpeg risc op 
code error
Jun 22 11:48:36 xpc kernel: [78360.929172] cx23885[0]: TS1 B - dma 
channel status dump
Jun 22 11:48:36 xpc kernel: [78360.929175] cx23885[0]:   cmds: init 
risc lo   : 0x06a26000
Jun 22 11:48:36 xpc kernel: [78360.929177] cx23885[0]:   cmds: init 
risc hi   : 0x
Jun 22 11:48:36 xpc kernel: [78360.929182] cx23885[0]:   cmds: cdt 
base   : 0x00010580
Jun 22 11:48:36 xpc kernel: [78360.929184] cx23885[0]:   cmds: cdt 
size   : 0x000a
Jun 22 11:48:36 xpc kernel: [78360.929187] cx23885[0]:   cmds: iq 
base: 0x00010400
Jun 22 11:48:36 xpc kernel: [78360.929189] cx23885[0]:   cmds: iq 
size: 0x0010
Jun 22 11:48:36 xpc kernel: [78360.929193] cx23885[0]:   cmds: risc pc 
lo : 0x06a26004
Jun 22 11:48:36 xpc kernel: [78360.929198] cx23885[0]:   cmds: risc pc 
hi : 0x
Jun 22 11:48:36 xpc kernel: [78360.929200] cx23885[0]:   cmds: iq wr 
ptr  : 0x4101
Jun 22 11:48:36 xpc kernel: [78360.929202] cx23885[0]:   cmds: iq rd 
ptr  : 0x4100
Jun 22 11:48:36 xpc kernel: [78360.929204] cx23885[0]:   cmds: cdt 
current: 0x00010598
Jun 22 11:48:36 xpc kernel: [78360.929207] cx23885[0]:   cmds: pci 
target lo  : 0x2e71c2f0
Jun 22 11:48:36 xpc kernel: [78360.929209] cx23885[0]:   cmds: pci 
target hi  : 0x
Jun 22 11:48:36 xpc kernel: [78360.929211] cx23885[0]:   cmds: line / 
byte: 0x0181
Jun 22 11:48:36 xpc kernel: [78360.929215] cx23885[0]:   risc0: 
0x1c0002f0 [ write sol eol count=752 ]
Jun 22 11:48:36 xpc kernel: [78360.929220] cx23885[0]:   risc1: 
0x2e71c2f0 [ skip sol eol irq2 22 21 20 cnt0 resync 14 count=752 ]
Jun 22 11:48:36 xpc kernel: [78360.929226] cx23885[0]:   risc2: 
0x [ INVALID count=0 ]
Jun 22 11:48:36 xpc kernel: [78360.929229] cx23885[0]:   risc3: 
0x1c0002f0 [ write sol eol count=752 ]
Jun 22 11:48:36 xpc kernel: [78360.929233] cx23885[0]: (0x00010400) iq 
0: 0x0660d080 [ INVALID eol irq2 22 21 resync 14 12 count=128 ]
Jun 22 11:48:36 xpc kernel: [78360.929238] cx23885[0]: (0x00010404) iq 
1: 0x2e71c2f0 [ skip sol eol irq2 22 21 20 cnt0 resync 14 count=752 ]
Jun 22 11:48:36 xpc kernel: [78360.929243] cx23885[0]: (0x00010408) iq 
2: 0x [ INVALID count=0 ]
Jun 22 11:48:36 xpc kernel: [78360.929246] cx23885[0]: (0x0001040c) iq 
3: 0x1c0002f0 [ write sol eol count=752 ]
Jun 22 11:48:36 xpc kernel: [78360.929251] cx23885[0]:   iq 4: 
0x2e71c5e0 [ arg #1 ]
Jun 22 11:48:36 xpc kernel: [78360.929253] cx23885[0]:   iq 5: 
0x [ arg #2 ]
Jun 22 11:48:36 xpc kernel: [78360.929256] cx23885[0]: (0x00010418) iq 
6: 0x1c0002f0 [ write sol eol count=752 ]
Jun 22 11:48:36 xpc kernel: [78360.929260] cx23885[0]:   iq 7: 
0x2e71c8d0 [ arg #1 ]
Jun 22 11:48:36 xpc kernel: [78360.929264] cx23885[0]:   iq 8: 
0x [ arg #2 ]
Jun 22 11:48:36 xpc kernel: [78360.929267] cx23885[0]: (0x00010424) iq 
9: 0x1c0002f0 [ write sol eol count=752 ]
Jun 22 11:48:36 xpc kernel: [78360.929270] cx23885[0]:   iq a: 
0x2e71cbc0 [ arg #1 ]
Jun 22 11:48:36 xpc kernel: [78360.929272] cx23885[0]:   iq b: 
0x [ arg #2 ]
Jun 22 11:48:36 xpc kernel: [78360.929274] cx23885[0]: (0x00010430) iq 
c: 0x7100 [ jump irq1 count=0 ]
Jun 22 11:48:36 xpc kernel: [78360.929278] cx23885[0]:   iq d: 
0x1c0002f0 [ arg #1 ]
Jun 22 11:48:36 xpc kernel: [78360.929280] cx23885[0]:   iq e: 
0x2e71c000 [ arg #2 ]
Jun 22 11:48:36 xpc kernel: [78360.929282] cx23885[0]: (0x0001043c) iq 
f: 0x [ INVALID count=0 ]
Jun 22 11:48:36 xpc kernel: [78360.929283] cx23885[0]: fifo: 
0x5000 - 0x6000
Jun 22 11:48:36 xpc kernel: [78360.929284] cx23885[0]: ctrl: 
0x00010400 - 0x10460
Jun 22 11:48:36 xpc kernel: [78360.929287] cx23885[0]:   ptr1_reg: 
0x5320
Jun 22 11:48:36 xpc kernel: [78360.929289] cx23885[0]:   ptr2_reg: 
0x00010598
Jun 22 11:48:36 xpc kernel: [78360.929291] cx23885[0]:   cnt1_reg: 
0x0003
Jun 22 11:48:36 xpc kernel: [78360.929293] cx23885[0]:   cnt2_reg: 
0x0007


Jun 22 12:28:30 xpc kernel: [80750.504214] cx23885[0]: mpeg risc op 
code error
Jun 22 12:28:30 xpc kernel: [80750.504219] cx23885[0]: TS1 B - dma 
channel status dump
Jun 22 12:28:30 xpc kernel: [80750.504221] cx23885[0]:   cmds: init 
risc lo   : 

media_tree log has not been updated for about a month

[Tycho Lürsen]

Hi all,
I don't know who is responsible for a functioning web frontend of your 
development tree in git.
The thing is: http://git.linuxtv.org/cgit.cgi/media_tree.git/log/ has 
not been updated for about a month.
It still shows   356484cabe44984d2dc66a90bd5e3465ba1f64fb ([media] 
dw2102: resync fifo when demod locks) as the last commit.

That is very inconvenient to me.
Can anyone fix this, please?

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

Re: [PATCH 02/12] dvbsky: use si2168 config option ts_clock_gapped

[Tycho Lürsen]

Hi Olli,
in saa716x_budget.c I've also got (for TBS6285)

si2168_config.i2c_adapter = i2cadapter;
si2168_config.fe = adapter-fe;
si2168_config.ts_mode = SI2168_TS_SERIAL;
memset(info, 0, sizeof(struct i2c_board_info));

Should I just add it like this?

si2168_config.ts_mode = SI2168_TS_SERIAL;
si2168_config.ts_clock_gapped = true;
memset(info, 0, sizeof(struct i2c_board_info));

Kind regards,
Tycho.

Op 23-04-15 om 23:11 schreef Olli Salonen:

Change the dvbsky driver to support gapped clock instead of the current
hack.

Signed-off-by: Olli Salonen olli.salo...@iki.fi
---
  drivers/media/usb/dvb-usb-v2/dvbsky.c | 3 ++-
  1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/media/usb/dvb-usb-v2/dvbsky.c 
b/drivers/media/usb/dvb-usb-v2/dvbsky.c
index cdf59bc..0f73b1d 100644
--- a/drivers/media/usb/dvb-usb-v2/dvbsky.c
+++ b/drivers/media/usb/dvb-usb-v2/dvbsky.c
@@ -615,7 +615,8 @@ static int dvbsky_t330_attach(struct dvb_usb_adapter *adap)
memset(si2168_config, 0, sizeof(si2168_config));
si2168_config.i2c_adapter = i2c_adapter;
si2168_config.fe = adap-fe[0];
-   si2168_config.ts_mode = SI2168_TS_PARALLEL | 0x40;
+   si2168_config.ts_mode = SI2168_TS_PARALLEL;
+   si2168_config.ts_clock_gapped = true;
memset(info, 0, sizeof(struct i2c_board_info));
strlcpy(info.type, si2168, I2C_NAME_SIZE);
info.addr = 0x64;


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

Re: [PATCH 02/12] dvbsky: use si2168 config option ts_clock_gapped

[Tycho Lürsen]

One more question:

cx23885-dvb.c (and maybe others) contains a couple of instances of

si2168_config.ts_mode = SI2168_TS_PARALLEL;
and
si2168_config.ts_mode = SI2168_TS_SERIAL;

But you don't patch them with

si2168_config.ts_clock_gapped = true;

Is this intentional?

Kind regards,
Tycho

Op 23-04-15 om 23:11 schreef Olli Salonen:

Change the dvbsky driver to support gapped clock instead of the current
hack.

Signed-off-by: Olli Salonen olli.salo...@iki.fi
---
  drivers/media/usb/dvb-usb-v2/dvbsky.c | 3 ++-
  1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/media/usb/dvb-usb-v2/dvbsky.c 
b/drivers/media/usb/dvb-usb-v2/dvbsky.c
index cdf59bc..0f73b1d 100644
--- a/drivers/media/usb/dvb-usb-v2/dvbsky.c
+++ b/drivers/media/usb/dvb-usb-v2/dvbsky.c
@@ -615,7 +615,8 @@ static int dvbsky_t330_attach(struct dvb_usb_adapter *adap)
memset(si2168_config, 0, sizeof(si2168_config));
si2168_config.i2c_adapter = i2c_adapter;
si2168_config.fe = adap-fe[0];
-   si2168_config.ts_mode = SI2168_TS_PARALLEL | 0x40;
+   si2168_config.ts_mode = SI2168_TS_PARALLEL;
+   si2168_config.ts_clock_gapped = true;
memset(info, 0, sizeof(struct i2c_board_info));
strlcpy(info.type, si2168, I2C_NAME_SIZE);
info.addr = 0x64;


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

Re: [PATCH] [media] use a function for DVB media controller register

[Tycho Lürsen]

Hi Mauro,
Op 02-03-15 om 15:31 schreef Mauro Carvalho Chehab:

This is really a simple function, but using it avoids to have
if's inside the drivers.

Also, the kABI becomes a little more clearer.

This shouldn't generate any overhead, and the type check
will happen when compiling with MC DVB enabled.

So, let's do it.

Signed-off-by: Mauro Carvalho Chehab mche...@osg.samsung.com

diff --git a/drivers/media/common/siano/smsdvb-main.c 
b/drivers/media/common/siano/smsdvb-main.c
index c739725ca7ee..367b8e77feb8 100644
--- a/drivers/media/common/siano/smsdvb-main.c
+++ b/drivers/media/common/siano/smsdvb-main.c
@@ -1104,9 +1104,7 @@ static int smsdvb_hotplug(struct smscore_device_t 
*coredev,
pr_err(dvb_register_adapter() failed %d\n, rc);
goto adapter_error;
}
-#ifdef CONFIG_MEDIA_CONTROLLER_DVB
-   client-adapter.mdev = coredev-media_dev;
-#endif
+   dvb_register_media_controller(client-adapter, coredev-media_dev);
  
  	/* init dvb demux */

client-demux.dmx.capabilities = DMX_TS_FILTERING;
diff --git a/drivers/media/dvb-core/dvbdev.h b/drivers/media/dvb-core/dvbdev.h
index 556c9e9d1d4e..12629b8ecb0c 100644
--- a/drivers/media/dvb-core/dvbdev.h
+++ b/drivers/media/dvb-core/dvbdev.h
@@ -125,8 +125,15 @@ extern void dvb_unregister_device (struct dvb_device 
*dvbdev);
  
  #ifdef CONFIG_MEDIA_CONTROLLER_DVB

  void dvb_create_media_graph(struct dvb_adapter *adap);
+static inline void dvb_register_media_controller(struct dvb_adapter *adap,
+struct media_device *mdev)
+{
+   adap-mdev = mdev;
+}
+
  #else
  static inline void dvb_create_media_graph(struct dvb_adapter *adap) {}
+#define dvb_register_media_controller(a, b) {}
  #endif
Does #define dvb_register_media_controller(a, b) {} restrict the 
number of registerd controllers in any way?
I mean, I've got a couple of TBS quad adapters, 4 tuner and 4 demod 
chips on each card. Will they still work with this change?
  
  extern int dvb_generic_open (struct inode *inode, struct file *file);

diff --git a/drivers/media/usb/cx231xx/cx231xx-dvb.c 
b/drivers/media/usb/cx231xx/cx231xx-dvb.c
index 8bf2baae387f..ff39bf22442d 100644
--- a/drivers/media/usb/cx231xx/cx231xx-dvb.c
+++ b/drivers/media/usb/cx231xx/cx231xx-dvb.c
@@ -465,9 +465,7 @@ static int register_dvb(struct cx231xx_dvb *dvb,
   dev-name, result);
goto fail_adapter;
}
-#ifdef CONFIG_MEDIA_CONTROLLER_DVB
-   dvb-adapter.mdev = dev-media_dev;
-#endif
+   dvb_register_media_controller(dvb-adapter, dev-media_dev);
  
  	/* Ensure all frontends negotiate bus access */

dvb-frontend-ops.ts_bus_ctrl = cx231xx_dvb_bus_ctrl;
diff --git a/drivers/media/usb/dvb-usb-v2/dvb_usb_core.c 
b/drivers/media/usb/dvb-usb-v2/dvb_usb_core.c
index 8bd08ba4f869..f5df9eaba04f 100644
--- a/drivers/media/usb/dvb-usb-v2/dvb_usb_core.c
+++ b/drivers/media/usb/dvb-usb-v2/dvb_usb_core.c
@@ -429,7 +429,7 @@ static void dvb_usbv2_media_device_register(struct 
dvb_usb_adapter *adap)
return;
}
  
-	adap-dvb_adap.mdev = mdev;

+   dvb_register_media_controller(adap-dvb_adap, mdev);
  
  	dev_info(d-udev-dev, media controller created\n);
  
diff --git a/drivers/media/usb/dvb-usb/dvb-usb-dvb.c b/drivers/media/usb/dvb-usb/dvb-usb-dvb.c

index 980d976960d9..7b7b834777b7 100644
--- a/drivers/media/usb/dvb-usb/dvb-usb-dvb.c
+++ b/drivers/media/usb/dvb-usb/dvb-usb-dvb.c
@@ -122,7 +122,7 @@ static void dvb_usb_media_device_register(struct 
dvb_usb_adapter *adap)
kfree(mdev);
return;
}
-   adap-dvb_adap.mdev = mdev;
+   dvb_register_media_controller(adap-dvb_adap, mdev);
  
  	dev_info(d-udev-dev, media controller created\n);

  #endif


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

Re: [PATCH] [media] use a function for DVB media controller register

[Tycho Lürsen]

Hi Mauro,
I tested this an I've got no issues to report.

If I was in the position to do so, I'd ack these patches.

Regards,
Tycho


Op 02-03-15 om 18:37 schreef Tycho Lürsen:

Hi Mauro,
Op 02-03-15 om 18:06 schreef Mauro Carvalho Chehab:

Em Mon, 02 Mar 2015 17:54:53 +0100
Tycho Lürsen tycholur...@gmail.com escreveu:


Hi Mauro,
Op 02-03-15 om 15:31 schreef Mauro Carvalho Chehab:

This is really a simple function, but using it avoids to have
if's inside the drivers.

Also, the kABI becomes a little more clearer.

This shouldn't generate any overhead, and the type check
will happen when compiling with MC DVB enabled.

So, let's do it.

Signed-off-by: Mauro Carvalho Chehab mche...@osg.samsung.com

diff --git a/drivers/media/common/siano/smsdvb-main.c 
b/drivers/media/common/siano/smsdvb-main.c

index c739725ca7ee..367b8e77feb8 100644
--- a/drivers/media/common/siano/smsdvb-main.c
+++ b/drivers/media/common/siano/smsdvb-main.c
@@ -1104,9 +1104,7 @@ static int smsdvb_hotplug(struct 
smscore_device_t *coredev,

   pr_err(dvb_register_adapter() failed %d\n, rc);
   goto adapter_error;
   }
-#ifdef CONFIG_MEDIA_CONTROLLER_DVB
-client-adapter.mdev = coredev-media_dev;
-#endif
+dvb_register_media_controller(client-adapter, 
coredev-media_dev);

  /* init dvb demux */
   client-demux.dmx.capabilities = DMX_TS_FILTERING;
diff --git a/drivers/media/dvb-core/dvbdev.h 
b/drivers/media/dvb-core/dvbdev.h

index 556c9e9d1d4e..12629b8ecb0c 100644
--- a/drivers/media/dvb-core/dvbdev.h
+++ b/drivers/media/dvb-core/dvbdev.h
@@ -125,8 +125,15 @@ extern void dvb_unregister_device (struct 
dvb_device *dvbdev);

  #ifdef CONFIG_MEDIA_CONTROLLER_DVB
   void dvb_create_media_graph(struct dvb_adapter *adap);
+static inline void dvb_register_media_controller(struct 
dvb_adapter *adap,

+ struct media_device *mdev)
+{
+adap-mdev = mdev;
+}
+
   #else
   static inline void dvb_create_media_graph(struct dvb_adapter 
*adap) {}

+#define dvb_register_media_controller(a, b) {}
   #endif

Does #define dvb_register_media_controller(a, b) {} restrict the
number of registerd controllers in any way?
I mean, I've got a couple of TBS quad adapters, 4 tuner and 4 demod
chips on each card. Will they still work with this change?
No. What the above define does is to replace the function call by 
nothing,

if MEDIA_CONTROLLER_DVB is not set.

Neither it or the current patches for the media controller on DVB should
affect the TBS quad adapters. If you're having some regressions with it,
please report.

Regards,
Mauro
Thanks for your reply, I will test this for regression as soon as it 
hits the master branch.


Regards,
Tycho.



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

Re: [PATCH] [media] use a function for DVB media controller register

[Tycho Lürsen]

Hi Mauro,
Op 02-03-15 om 18:06 schreef Mauro Carvalho Chehab:

Em Mon, 02 Mar 2015 17:54:53 +0100
Tycho Lürsen tycholur...@gmail.com escreveu:


Hi Mauro,
Op 02-03-15 om 15:31 schreef Mauro Carvalho Chehab:

This is really a simple function, but using it avoids to have
if's inside the drivers.

Also, the kABI becomes a little more clearer.

This shouldn't generate any overhead, and the type check
will happen when compiling with MC DVB enabled.

So, let's do it.

Signed-off-by: Mauro Carvalho Chehab mche...@osg.samsung.com

diff --git a/drivers/media/common/siano/smsdvb-main.c 
b/drivers/media/common/siano/smsdvb-main.c
index c739725ca7ee..367b8e77feb8 100644
--- a/drivers/media/common/siano/smsdvb-main.c
+++ b/drivers/media/common/siano/smsdvb-main.c
@@ -1104,9 +1104,7 @@ static int smsdvb_hotplug(struct smscore_device_t 
*coredev,
pr_err(dvb_register_adapter() failed %d\n, rc);
goto adapter_error;
}
-#ifdef CONFIG_MEDIA_CONTROLLER_DVB
-   client-adapter.mdev = coredev-media_dev;
-#endif
+   dvb_register_media_controller(client-adapter, coredev-media_dev);
   
   	/* init dvb demux */

client-demux.dmx.capabilities = DMX_TS_FILTERING;
diff --git a/drivers/media/dvb-core/dvbdev.h b/drivers/media/dvb-core/dvbdev.h
index 556c9e9d1d4e..12629b8ecb0c 100644
--- a/drivers/media/dvb-core/dvbdev.h
+++ b/drivers/media/dvb-core/dvbdev.h
@@ -125,8 +125,15 @@ extern void dvb_unregister_device (struct dvb_device 
*dvbdev);
   
   #ifdef CONFIG_MEDIA_CONTROLLER_DVB

   void dvb_create_media_graph(struct dvb_adapter *adap);
+static inline void dvb_register_media_controller(struct dvb_adapter *adap,
+struct media_device *mdev)
+{
+   adap-mdev = mdev;
+}
+
   #else
   static inline void dvb_create_media_graph(struct dvb_adapter *adap) {}
+#define dvb_register_media_controller(a, b) {}
   #endif

Does #define dvb_register_media_controller(a, b) {} restrict the
number of registerd controllers in any way?
I mean, I've got a couple of TBS quad adapters, 4 tuner and 4 demod
chips on each card. Will they still work with this change?

No. What the above define does is to replace the function call by nothing,
if MEDIA_CONTROLLER_DVB is not set.

Neither it or the current patches for the media controller on DVB should
affect the TBS quad adapters. If you're having some regressions with it,
please report.

Regards,
Mauro
Thanks for your reply, I will test this for regression as soon as it 
hits the master branch.


Regards,
Tycho.

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

Re: DVB Simulcrypt

[Tycho Lürsen]

Op 23-02-15 om 13:44 schreef Rudy Zijlstra:

On 23-02-15 12:21, Honza Petrouš wrote:
2015-02-23 11:31 GMT+01:00 Rudy Zijlstra 
r...@grumpydevil.homelinux.org:

On 23-02-15 08:44, Honza Petrouš wrote:

Hi Rudy.

2015-02-22 16:28 GMT+01:00 Rudy Zijlstra 
r...@grumpydevil.homelinux.org:

Some more info

On 21-02-15 22:30, Rudy Zijlstra wrote:

Dears (Hans?)

My setup, where the cable operator was using only irdeto, was working
good. Then the cable operator merged with another, and now the 
networks are
being merged. As a result, the encryption has moved from irdeto 
only to

simulcyrpt with Irdeto and Nagra.

Current status:
- when i put the CA card in a STB, it works
- when trying to record an encrypted channel from PC, it no longer 
works.
Recording system has 3 tuners. All equal, all with same permissions 
on the
smartcard. On cards 0 and 2 does not work, but card 1 does work, on 
all

channels tested.


Does it mean that descrambling is not working for you? If so,
how do you manage descrambling? By CI-CAM module
or by some softcam like oscam?

Or do you record ENCRYPTED stream and decrypt the recordings
later on?


Each tuner has its own legal CI-CAM module. And yes, except for the 
second

tuner descrambling no longer works

I'm not much familiar with MythTV, so I'm guessing from the mux setup 
changes,

but did you check to descramble the same channel on different tuners?
To eliminate
the particular change inside one service only.

Of course there can be also software issue in CI-CAM module itself
(fail in parsing
PMT CA descriptors etc).

TBH, I think it must be application layer issue, not kernel one.


See above:

Recording system has 3 tuners. All equal, all with same permissions on 
the

smartcard. On cards 0 and 2 does not work, but card 1 does work, on all
channels tested.

additional finfo: i tested the same channel(s) on all 3 tuners. For 
now i have re-configured mythtv to use only the second tuner for 
encrypted channels.

This does reduce scheduling flexibility though.

Would to understand what makes the difference, so i can ask the right 
questions to MythTV developers.



As the decryption does work with 1 tuner, i see 2 options:
- depending on tuner id the default CA descriptor used is different, 
and this selection is not expoerted on API level (kernel issue)
- application needs to select which CA to use (and currently does not 
do this)


It should be the latter one. I'm also having  Ziggo for provider, but 
always used FFdecsawrapper/Oscam for decryption (also legal in The 
Netherlands, providing you have a paid subscription)
ECM CA system id's 0x604 or 0x602 (depending on your region) gets you 
Irdeto, while ECM CA system id's 0x1850 or 0x1801 get you Nagra.

Correctly configured FFdecsa/Oscam can deal with it, MythTV probably cannot.
Check it out at: 
http://www.dtvmonitor.com/nl/?guid=0BE90D25-BA46-7B93-FDCD-20EFC79691E0

That's a snapshot from today, monitored from Groningen.

Cheers,

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

Re: DVB Simulcrypt

[Tycho Lürsen]

Op 23-02-15 om 16:51 schreef Rudy Zijlstra:

On 23-02-15 15:21, Tycho Lürsen wrote:


Op 23-02-15 om 13:44 schreef Rudy Zijlstra:

On 23-02-15 12:21, Honza Petrouš wrote:
2015-02-23 11:31 GMT+01:00 Rudy Zijlstra 
r...@grumpydevil.homelinux.org:

On 23-02-15 08:44, Honza Petrouš wrote:

Hi Rudy.

2015-02-22 16:28 GMT+01:00 Rudy Zijlstra 
r...@grumpydevil.homelinux.org:

Some more info

On 21-02-15 22:30, Rudy Zijlstra wrote:

Dears (Hans?)

My setup, where the cable operator was using only irdeto, was 
working
good. Then the cable operator merged with another, and now the 
networks are
being merged. As a result, the encryption has moved from irdeto 
only to

simulcyrpt with Irdeto and Nagra.

Current status:
- when i put the CA card in a STB, it works
- when trying to record an encrypted channel from PC, it no 
longer works.
Recording system has 3 tuners. All equal, all with same 
permissions on the
smartcard. On cards 0 and 2 does not work, but card 1 does work, 
on all

channels tested.


Does it mean that descrambling is not working for you? If so,
how do you manage descrambling? By CI-CAM module
or by some softcam like oscam?

Or do you record ENCRYPTED stream and decrypt the recordings
later on?


Each tuner has its own legal CI-CAM module. And yes, except for 
the second

tuner descrambling no longer works

I'm not much familiar with MythTV, so I'm guessing from the mux 
setup changes,

but did you check to descramble the same channel on different tuners?
To eliminate
the particular change inside one service only.

Of course there can be also software issue in CI-CAM module itself
(fail in parsing
PMT CA descriptors etc).

TBH, I think it must be application layer issue, not kernel one.


See above:

Recording system has 3 tuners. All equal, all with same permissions 
on the

smartcard. On cards 0 and 2 does not work, but card 1 does work, on all
channels tested.

additional finfo: i tested the same channel(s) on all 3 tuners. For 
now i have re-configured mythtv to use only the second tuner for 
encrypted channels.

This does reduce scheduling flexibility though.

Would to understand what makes the difference, so i can ask the 
right questions to MythTV developers.



As the decryption does work with 1 tuner, i see 2 options:
- depending on tuner id the default CA descriptor used is different, 
and this selection is not expoerted on API level (kernel issue)
- application needs to select which CA to use (and currently does 
not do this)


It should be the latter one. I'm also having  Ziggo for provider, but 
always used FFdecsawrapper/Oscam for decryption (also legal in The 
Netherlands, providing you have a paid subscription)
ECM CA system id's 0x604 or 0x602 (depending on your region) gets you 
Irdeto, while ECM CA system id's 0x1850 or 0x1801 get you Nagra.
Correctly configured FFdecsa/Oscam can deal with it, MythTV probably 
cannot.
Check it out at: 
http://www.dtvmonitor.com/nl/?guid=0BE90D25-BA46-7B93-FDCD-20EFC79691E0

That's a snapshot from today, monitored from Groningen.


Tycho,

thanks. looking at http://www.dtvmonitor.com/nl/ziggo-limburg the CA 
id for Iredeto are same in Limburg as in Groningen.


And yes, my CAM's are for Irdeto and do not support Nagra. To my 
knowledge no valid Nagra CAM do exist for DVB-C


Can FFdecsawrapper/Oscam be used in combination with MythTV?

Cheers


Rudy
Sure it can, I've been using it for many years with MythTV, up until 
now. Ziggo does not encrypt any channel that I'm actually using anymore.
As for the setup, I do know what I'm talking about, I've been the 
maintainer of FFdecsawrapper for about 3 years now.

For basic instructions (a how-to) look at my wiki pages:
http://www.lursen.org/wiki/FFdecsawrapper_with_MythTV_and_Oscam_on_Debian/Ubuntu
http://www.lursen.org/wiki/Speciaal:AllePaginas

Aren't we lucky to live in The Netherlands? (I mean in the US we'd 
probably be imprisoned for even mentioning the subject)


Tycho

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

Re: DVB Simulcrypt

[Tycho Lürsen]

Op 23-02-15 om 20:56 schreef Honza Petrouš:

2015-02-23 16:51 GMT+01:00 Rudy Zijlstra r...@grumpydevil.homelinux.org:

On 23-02-15 15:21, Tycho Lürsen wrote:


Op 23-02-15 om 13:44 schreef Rudy Zijlstra:

On 23-02-15 12:21, Honza Petrouš wrote:

2015-02-23 11:31 GMT+01:00 Rudy Zijlstra
r...@grumpydevil.homelinux.org:

On 23-02-15 08:44, Honza Petrouš wrote:

Hi Rudy.

2015-02-22 16:28 GMT+01:00 Rudy Zijlstra
r...@grumpydevil.homelinux.org:

Some more info

On 21-02-15 22:30, Rudy Zijlstra wrote:

Dears (Hans?)

My setup, where the cable operator was using only irdeto, was working
good. Then the cable operator merged with another, and now the
networks are
being merged. As a result, the encryption has moved from irdeto only
to
simulcyrpt with Irdeto and Nagra.

Current status:
- when i put the CA card in a STB, it works
- when trying to record an encrypted channel from PC, it no longer
works.

Recording system has 3 tuners. All equal, all with same permissions on
the
smartcard. On cards 0 and 2 does not work, but card 1 does work, on
all
channels tested.


Does it mean that descrambling is not working for you? If so,
how do you manage descrambling? By CI-CAM module
or by some softcam like oscam?

Or do you record ENCRYPTED stream and decrypt the recordings
later on?


Each tuner has its own legal CI-CAM module. And yes, except for the
second
tuner descrambling no longer works


I'm not much familiar with MythTV, so I'm guessing from the mux setup
changes,
but did you check to descramble the same channel on different tuners?
To eliminate
the particular change inside one service only.

Of course there can be also software issue in CI-CAM module itself
(fail in parsing
PMT CA descriptors etc).

TBH, I think it must be application layer issue, not kernel one.


See above:

Recording system has 3 tuners. All equal, all with same permissions on
the
smartcard. On cards 0 and 2 does not work, but card 1 does work, on all
channels tested.

additional finfo: i tested the same channel(s) on all 3 tuners. For now i
have re-configured mythtv to use only the second tuner for encrypted
channels.
This does reduce scheduling flexibility though.

Would to understand what makes the difference, so i can ask the right
questions to MythTV developers.


As the decryption does work with 1 tuner, i see 2 options:
- depending on tuner id the default CA descriptor used is different, and
this selection is not expoerted on API level (kernel issue)
- application needs to select which CA to use (and currently does not do
this)


It should be the latter one. I'm also having  Ziggo for provider, but
always used FFdecsawrapper/Oscam for decryption (also legal in The
Netherlands, providing you have a paid subscription)
ECM CA system id's 0x604 or 0x602 (depending on your region) gets you
Irdeto, while ECM CA system id's 0x1850 or 0x1801 get you Nagra.
Correctly configured FFdecsa/Oscam can deal with it, MythTV probably
cannot.
Check it out at:
http://www.dtvmonitor.com/nl/?guid=0BE90D25-BA46-7B93-FDCD-20EFC79691E0
That's a snapshot from today, monitored from Groningen.


Tycho,

thanks. looking at http://www.dtvmonitor.com/nl/ziggo-limburg the CA id for
Iredeto are same in Limburg as in Groningen.

And yes, my CAM's are for Irdeto and do not support Nagra. To my knowledge
no valid Nagra CAM do exist for DVB-C


I'm a bit fossil regarding current status of CA in DVB but anyway I can say
I know that some years ago existed CI-CAM modules for Nagra, it was
in time of so-called Nagra2 introduction on Hispasat ;)

Dunno how is the current situation.

An second - it has no difference if it is for sattelite or cable variant
of DVB. The CI-CAM standard is the same. The only problem
can be if support for particular provider is baked inside (meaning
only particular auth data are inserted).

/Honza
Thanks for the input Honza, but where we live, we are forced to use 
Irdeto. Moreover, such a Nagra CAM would not eliminate the supposed 
inability of MythTV to point (while tuninglocking) to the right CA 
descriptor in a reliable way.

Tycho


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

Re: DVB Simulcrypt

[Tycho Lürsen]

Op 23-02-15 om 22:29 schreef Rudy Zijlstra:

On 23-02-15 20:56, Honza Petrouš wrote:
2015-02-23 16:51 GMT+01:00 Rudy Zijlstra 
r...@grumpydevil.homelinux.org:
And yes, my CAM's are for Irdeto and do not support Nagra. To my 
knowledge no valid Nagra CAM do exist for DVB-C 
I'm a bit fossil regarding current status of CA in DVB but anyway I 
can say

I know that some years ago existed CI-CAM modules for Nagra, it was
in time of so-called Nagra2 introduction on Hispasat ;)

Dunno how is the current situation.

An second - it has no difference if it is for sattelite or cable variant
of DVB. The CI-CAM standard is the same. The only problem
can be if support for particular provider is baked inside (meaning
only particular auth data are inserted).


The point is that although from standard point of view you are right, 
no cable operator has ever wanted to support Nagra CAM. As a result 
the needed CAM authorization is not present.


CI+ is a different story. Would need to check if CI+ is available in 
PC card form now. Kind of doubt that though. Do not expect Nagra wil 
support such development (refuse to validate).


Cheers


Rudy
Spare your time: no CI for PC is available that supports the bogus CI+ 
standard. And thus no driver for that too. So all you need is a simple 
cardreader like the Smargo+ (but make sure you get an original one, not 
a cheap clone that seemingly is the real deal)


Cheers,
Tycho

--
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: [possible BUG, cx23885] Dual tuner TV card, works using one tuner only, doesn't work if both tuners are used

[Tycho Lürsen]

Tested with a couple of DVBSky T982 adapters against latest media 
master. No problems detected.
Moreover: even with earlier versions of the media tree (starting with 
the version in witch support for DVBSky t982 was added), I never 
encountered any problems.


Regards,
Tycho.

Op 04-02-15 om 16:14 schreef Antti Palosaari:

On 02/04/2015 09:54 AM, Hans Verkuil wrote:

On 02/03/2015 08:32 PM, Steven Toth wrote:

While I am the maintainer of the cx23885 driver, its currently
undergoing a significant amount of churn related to Han's recent VB2
and other changes. I consider the current driver broken until the
feedback on the mailing list dies down. I'm reluctant to work on the
driver while its considered unstable.


Any issues in the driver are all related to streaming. Tuning has not
been touched at all and there is some anecdotal evidence that if there
are tuning issues they were there already before the vb2 conversion.

To my knowledge the driver is now stable. There is still the occasional
kernel message that shouldn't be there which I am trying to track down,
but the driver crashes due to a vb2 race condition have been fixed.


Tested with Hauppauge WinTV-HVR5525 against latest media master and 
seems to work now. Earlier there was 2 problems:

1) lockdep splash
2) hangs when both adapters were streaming

regards
Antti



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

[saa716x] upstream request

[Tycho Lürsen]

Hello Mr Abraham,

Thank you very much for coding the saa716x driver. It's highly appreciated!

I own a couple of TBS DVB-T/T2/C cards that use those chips, so your 
driver is of great value to me.
Of course official drivers from TBS suck bigtime, but fortunately Luis 
Alves thinks so too.
So he coded support for many TBS cards that use saa716x supported chips. 
And I thank him very much for doing so too.


However, at some point even Luis is likely to stop supporting this 
development for some reason.

That brings me to you. You're the original coder and owner of the driver.
So my questions to you are:

Would you please please please upstream your driver?
What will it take you to upstream your driver?

Maybe others can be of some assistance, take some of the workload from 
your back.

That is, in the event that you are willing to upstream it. Are you?

You realize of course that if you honour my humble request, you will, to 
say the least, enter into the top level of the Eternal Hall of Fame, 
that most TBS card owners will send you flowers, burn candles for you 
and think of you in their prayers?
And as a bonus: TBS itself will probably be 'not amused', that's nice 
too, isn't it?
After all, as you said: they didn't even have the common courtesy to 
thank you..


Well, I do! And I do it also on behalf of the vast majority of the 
(future) owners of saa716x supported chips driven DVB adapters.


Kind regards,

Tycho Lürsen.

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

Re: [media_build] commit 26052b8e1 (SMIAPP needs kernel 3.20 or up.)

[Tycho Lürsen]

Tested again, works now.
Thanks!
Op 20-01-15 om 08:35 schreef Hans Verkuil:

On 01/19/2015 08:06 PM, Tycho Lürsen wrote:

Hi Hans,

tested this update in media_build against a Debian 3.16 kernel.
It still tries to build SMIAPP. So sadly it still gives the same error.

Try again. I missed a duplicate VIDEO_SMIAPP entry in versions.txt that is
now deleted. I just tried it and it now builds fine for me.

Regards,

Hans


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

[media_build] commit 26052b8e1 (SMIAPP needs kernel 3.20 or up.)

[Tycho Lürsen]

Hi Hans,

tested this update in media_build against a Debian 3.16 kernel.
It still tries to build SMIAPP. So sadly it still gives the same error.

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

Re: [PATCH] cx23885/vb2 regression: please test this patch

[Tycho Lürsen]

Hi Hans,

I doubt that there is an issue with multiple frontends, at least not in 
all cases.
I've got 4 DVBSky T982 adapters (2 frontends per card) runing without 
issues so far.

They have a cx23885 and 2x si2168/2157

Regards,
Tycho.

Op 17-01-15 om 12:09 schreef Hans Verkuil:

On 01/16/2015 08:05 PM, Raimonds Cicans wrote:

On 16.01.2015 16:54, Hans Verkuil wrote:


If you get the error again with a 3.18 or higher kernel and with my patch,
then please copy-and-paste that message again.

To be sure, I attached full dmesg.

Thanks. This was with one frontend? And what was the exact sequence of commands
used to replicate this?

Sorry, but I need precise details of how you reproduce this, especially since I
can't reproduce it.

I'm pretty sure there are multiple issues here, one of them is fixed by my vb2
patch, but this page fault is almost certainly a separate problem.

Based on past reports there is also a possible problem with multiple frontends,
but I don't have hardware like that and even if I had I am not sure I would be
able to test it properly. Besides, that issue seemed to be unrelated to the
vb2 conversion. It's all pretty vague, though.

Regards,

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


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

Re: [PATCH 2/2] si2168: add support for 1.7MHz bandwidth

[Tycho Lürsen]

Hi Olli,
did you commit this anywhere?
Regards,
Tycho.

Op 16-01-15 om 13:35 schreef Olli Salonen:

This patch is based on Antti's silabs branch.

Add support for 1.7 MHz bandwidth. Supported in all versions of Si2168 
according to short data sheets.

Signed-off-by: Olli Salonen olli.salo...@iki.fi
---
  drivers/media/dvb-frontends/si2168.c | 2 ++
  1 file changed, 2 insertions(+)

diff --git a/drivers/media/dvb-frontends/si2168.c 
b/drivers/media/dvb-frontends/si2168.c
index 7fef5ab..ec893ee 100644
--- a/drivers/media/dvb-frontends/si2168.c
+++ b/drivers/media/dvb-frontends/si2168.c
@@ -185,6 +185,8 @@ static int si2168_set_frontend(struct dvb_frontend *fe)
dev_err(client-dev, automatic bandwidth not supported);
goto err;
}
+   else if (c-bandwidth_hz = 200)
+   bandwidth = 0x02;
else if (c-bandwidth_hz = 500)
bandwidth = 0x05;
else if (c-bandwidth_hz = 600)


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