Re: AverMedia HD Duet (White Box) A188WB drivers

2016-03-04 Thread Manu Abraham
Hi Olli,

Most of the work which went into the saa716x (saa7160xx and sa7162x)
I had pushed out to
http://git.linuxtv.org//manu/saa716x_new.git/
so that people were able to use it while it was being developed.
There were some issues over here (things went through a data recovery
process), which got sorted out. There are other changes that also needed
to be pushed out. It is just a matter of time, to get those changes out.

Regards,
Manu



On Fri, Mar 4, 2016 at 12:58 PM, Olli Salonen <olli.salo...@iki.fi> wrote:
> Hi Manu,
>
> How's it going with the SAA7160? I'd be really happy to see the driver
> being mainlined, but do not really understand if there is some major
> showstoppers still that keep this from happening.
>
> Luis has his personal media_tree here
> https://github.com/ljalves/linux_media/wiki that contains Manu's
> SAA7160 driver and as far as I understand many people are using that
> tree with good success. If that could integrated into the tree, I'm
> sure the community can help to iron out any possible issues existing
> there still.
>
> Cheers,
> -olli
>
> On 7 December 2015 at 14:06, Manu Abraham <abraham.m...@gmail.com> wrote:
>> Hi Jemma,
>>
>> I am having a downtime, the development machine in a recovery
>> process. If things go well, expecting the system next week.
>>
>> Regards,
>>
>> Manu
>>
>>
>> On Mon, Dec 7, 2015 at 3:52 PM, Jemma Denson <jden...@gmail.com> wrote:
>>> Hi Manu,
>>>
>>> On 08/10/15 17:28, Manu Abraham wrote:
>>>>
>>>> Hi,
>>>>
>>>> I just got back at work again. Will set things up this weekend/next week.
>>>
>>>
>>> Have you had a chance to make any more progress on this?
>>>
>>> As you're probably aware there are quite a few drivers waiting for saa716x
>>> to be integrated into the tree; if you need some help here is the work
>>> remaining to be done something that can be picked up by other people?
>>>
>>> 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
--
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: AverMedia HD Duet (White Box) A188WB drivers

2015-12-07 Thread Manu Abraham
Hi Jemma,

I am having a downtime, the development machine in a recovery
process. If things go well, expecting the system next week.

Regards,

Manu


On Mon, Dec 7, 2015 at 3:52 PM, Jemma Denson <jden...@gmail.com> wrote:
> Hi Manu,
>
> On 08/10/15 17:28, Manu Abraham wrote:
>>
>> Hi,
>>
>> I just got back at work again. Will set things up this weekend/next week.
>
>
> Have you had a chance to make any more progress on this?
>
> As you're probably aware there are quite a few drivers waiting for saa716x
> to be integrated into the tree; if you need some help here is the work
> remaining to be done something that can be picked up by other people?
>
> 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: AverMedia HD Duet (White Box) A188WB drivers

2015-10-08 Thread Manu Abraham
Hi,

I just got back at work again. Will set things up this weekend/next week.

On Thu, Oct 8, 2015 at 3:38 AM, David Nelson <nelson...@gmail.com> wrote:
> It's been a while since I originally asked you about this has there
> been any progress?
>
> On Fri, Jun 12, 2015 at 11:21 PM, Manu Abraham <abraham.m...@gmail.com> wrote:
>> Hi David,
>>
>> The saa7160 chipset is supported by the saa716x driver.
>> I wrote a driver for it, which is over here.
>> http://git.linuxtv.org/cgit.cgi/manu/saa716x_new.git
>>
>> I do have the A188 card and documentation also with me,
>> thanks to Avermedia.
>>
>> The card is not yet supported in the above tree, so cloning
>> that tree will not help much in your case. Though I have
>> some code related to that, it is only on my local testbox
>>
>> I've been with an accident and my other hand is in a restrictive
>> state with minimal movements. It will be a few weeks, before
>> I can do something in this area. It's not much help to you at
>> this point right now, but just fyi
>>
>> Manu
>>
>>
>>
>> On Sat, Jun 13, 2015 at 8:46 AM, David Nelson <nelson...@gmail.com> wrote:
>>> I have the AverMedia HD Duet (White Box) A188WB. Which has been
>>> working great for several years in Windows 7 Media Center. I just
>>> tried installing Mythbuntu but it does not appear to be recognized. I
>>> am a bit of a newbie but I managed to find some info about it.
>>>
>>> Does anyone know of a driver for it? lspci says it uses the Philips
>>> SAA7160 which does appear to be in a few other supported devices.
>>>
>>> Details follow
>>>
>>> I get the following from lspci -vvnnk
>>>
>>> 03:00.0 Multimedia controller [0480]: Philips Semiconductors SAA7160
>>> [1131:7160] (rev 01)
>>> Subsystem: Avermedia Technologies Inc Device [1461:1e55]
>>> Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
>>> Stepping- SERR- FastB2B- DisINTx-
>>> Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort-
>>> SERR- >> Latency: 0, Cache Line Size: 64 bytes
>>> Interrupt: pin A routed to IRQ 10
>>> Region 0: Memory at ef80 (64-bit, non-prefetchable) [size=1M]
>>> Capabilities: 
>>>
>>>
>>> I can see that there is a driver for a few other devices with this
>>> chip at http://www.linuxtv.org/wiki/index.php/NXP_SAA716x  (i.e.
>>> heading "As of (2014-06-07)"
>>>
>>>
>>> --
>>> -David Nelson
>>> --
>>> 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
>
>
>
> --
> -David Nelson
> Home: 801-302-1347
> Cell: 801-205-8248
--
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: AverMedia HD Duet (White Box) A188WB drivers

2015-06-12 Thread Manu Abraham
Hi David,

The saa7160 chipset is supported by the saa716x driver.
I wrote a driver for it, which is over here.
http://git.linuxtv.org/cgit.cgi/manu/saa716x_new.git

I do have the A188 card and documentation also with me,
thanks to Avermedia.

The card is not yet supported in the above tree, so cloning
that tree will not help much in your case. Though I have
some code related to that, it is only on my local testbox

I've been with an accident and my other hand is in a restrictive
state with minimal movements. It will be a few weeks, before
I can do something in this area. It's not much help to you at
this point right now, but just fyi

Manu



On Sat, Jun 13, 2015 at 8:46 AM, David Nelson nelson...@gmail.com wrote:
 I have the AverMedia HD Duet (White Box) A188WB. Which has been
 working great for several years in Windows 7 Media Center. I just
 tried installing Mythbuntu but it does not appear to be recognized. I
 am a bit of a newbie but I managed to find some info about it.

 Does anyone know of a driver for it? lspci says it uses the Philips
 SAA7160 which does appear to be in a few other supported devices.

 Details follow

 I get the following from lspci -vvnnk

 03:00.0 Multimedia controller [0480]: Philips Semiconductors SAA7160
 [1131:7160] (rev 01)
 Subsystem: Avermedia Technologies Inc Device [1461:1e55]
 Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
 Stepping- SERR- FastB2B- DisINTx-
 Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast TAbort-
 TAbort- MAbort- SERR- PERR- INTx-
 Latency: 0, Cache Line Size: 64 bytes
 Interrupt: pin A routed to IRQ 10
 Region 0: Memory at ef80 (64-bit, non-prefetchable) [size=1M]
 Capabilities: access denied


 I can see that there is a driver for a few other devices with this
 chip at http://www.linuxtv.org/wiki/index.php/NXP_SAA716x  (i.e.
 heading As of (2014-06-07)


 --
 -David Nelson
 --
 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: Upstreaming SAA716x driver to the media_tree

2014-02-26 Thread Manu Abraham
Hi Luis,

On Wed, Feb 26, 2014 at 3:57 AM, Luis Alves lja...@gmail.com wrote:
 Hi Manu,

 How's the progress going?
 Looking forward to finally see this driver in the tree :D

Just got back setting things back to normalcy.
This weekend, I have plans to do more work for that.

Regards,

Manu
--
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] stv090x: remove indent levels

2014-02-20 Thread Manu Abraham
On Thu, Feb 20, 2014 at 2:55 PM, Dan Carpenter dan.carpen...@oracle.com wrote:
 Guys, what Manu is saying is purest nonsense.  The lock variable is a
 stack variable, it's not a demodulator Read-modify-Write register.
 The implications of changing if (!lock) to if (lock) are simple and
 obvious.

Sorry, you mistook. By demodulator Read-modify-Write register,
I do really mean a register on the demodulator. If you do miss
a read when flipping a logic, it does indeed make a large difference.



 He's not reviewing patches, he's just NAKing them.  It's not helpful.


Uh !?

I said Ok, will have a look at it later, the second lock test might
be superfluous,
which will fix your static checker as well.

Where's the NAK in there ?

Just said that, I prefer a simplified version, rather than that logic flip.

Regards,

Manu
--
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] stv090x: remove indent levels

2014-02-19 Thread Manu Abraham
On Wed, Feb 19, 2014 at 1:14 PM, Dan Carpenter dan.carpen...@oracle.com wrote:
 On Wed, Feb 19, 2014 at 10:52:32AM +0530, Manu Abraham wrote:
 On Tue, Feb 18, 2014 at 2:26 PM, Dan Carpenter dan.carpen...@oracle.com 
 wrote:
  On Tue, Feb 18, 2014 at 09:25:36AM +0530, Manu Abraham wrote:
  Hi Dan,
 
  On Thu, Feb 6, 2014 at 2:58 PM, Dan Carpenter dan.carpen...@oracle.com 
  wrote:
   1) We can flip the if (!lock) check to if (lock) return lock; and
  then remove a big chunk of indenting.
   2) There is a redundant if (!lock) which we can remove since we
  already know that lock is zero.  This removes another indent level.
 
 
  The stv090x driver is a mature, but slightly complex driver supporting
  quite some
  different configurations. Is it that some bug you are trying to fix in 
  there ?
  I wouldn't prefer unnecessary code churn in such a driver for
  something as simple
  as gain in an indentation level.
 
  I thought the cleanup was jusitification enough, but the real reason I
  wrote this patch is that testing:
 
  if (!lock) {
  if (!lock) {
 
  sets off a static checker warning.  That kind of code is puzzling and if
  we don't clean it up then it wastes a lot of reviewer time.
 
  Also when you're reviewing these patches please consider that the
  original code might be buggy and not simply messy.  Perhaps something
  other than if (!lock) { was intended?
 

 I can't seem to find the possible bug in there..

 The code:

 lock = fn();
 if (!lock) {
  if (condition1) {
lock = fn()
  } else {
if (!lock) {
}
  }
 }

 looks harmless to me, AFAICS.

 Yes.  I thought so too.  It's just a messy, but not broken.  Let's just
 fix the static checker warning so that we don't have to keep reviewing
 it every several months.

 Also, please do note that, if the
 function coldlock exits due to some reason for not finding valid symbols,
 stv090x_search is again fired up from the kernel frontend thread.

 This sentence really scares me.  Are you trying to say that the second
 check on lock is valid for certain use cases?  That is not possibly
 true because it is a stack variable so (ignoring memory corruption)
 it can't be modified from outside the code.

No, the demodulator registers are Read-modify-Write. ie, if a read didn't
occur, possibly registers won't be updated as when required. This might
cause the demodulator and the driver to be in 2 different states. It's
actually a state machine in there. ie, the demodulator might be in a
warm state, while the driver might assume a cold state or vice versa.
Possibly, this would result in longer, lock acquisition periods. Since it is
doing a blind symbol rate search, a possibility of a faulty lock also
exists, if the initial state is screwed up. Hence, hesitant to flip the logic
involved.


 Hm...

 The code actually looks like this:

 lock = fn();
 if (!lock) {
  if (condition1) {
lock = fn()
  } else {
if (!lock) {
 while ((cur_step = steps)  (!lock)) {
 lock = stv090x_get_dmdlock(state, (timeout_dmd / 3));
 }
}
  }
 }

 Are you sure it's not buggy?  Maybe the if statement should be moved
 inside the while () condition?

 It is easy to make such cleanup patches and cause breakages, but a
 lot time consuming to fix such issues. My 2c.

 Greg K-H and I review more of these cleanup patches than any other
 kernel maintainers so I'm aware of the challenges.  If you want to write
 a smaller patch to fix the static checker warning then I will review it
 for you.  If you do that then please give me a:
 Reported-by: Dan Carpenter dan.carpen...@oracle.com

Ok, will have a look at it later, the second lock test might be superfluous,
which will fix your static checker as well.

Best Regards,

Manu
--
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] stv090x: remove indent levels

2014-02-18 Thread Manu Abraham
On Tue, Feb 18, 2014 at 2:26 PM, Dan Carpenter dan.carpen...@oracle.com wrote:
 On Tue, Feb 18, 2014 at 09:25:36AM +0530, Manu Abraham wrote:
 Hi Dan,

 On Thu, Feb 6, 2014 at 2:58 PM, Dan Carpenter dan.carpen...@oracle.com 
 wrote:
  1) We can flip the if (!lock) check to if (lock) return lock; and
 then remove a big chunk of indenting.
  2) There is a redundant if (!lock) which we can remove since we
 already know that lock is zero.  This removes another indent level.


 The stv090x driver is a mature, but slightly complex driver supporting
 quite some
 different configurations. Is it that some bug you are trying to fix in there 
 ?
 I wouldn't prefer unnecessary code churn in such a driver for
 something as simple
 as gain in an indentation level.

 I thought the cleanup was jusitification enough, but the real reason I
 wrote this patch is that testing:

 if (!lock) {
 if (!lock) {

 sets off a static checker warning.  That kind of code is puzzling and if
 we don't clean it up then it wastes a lot of reviewer time.

 Also when you're reviewing these patches please consider that the
 original code might be buggy and not simply messy.  Perhaps something
 other than if (!lock) { was intended?


I can't seem to find the possible bug in there..

The code:

lock = fn();
if (!lock) {
 if (condition1) {
   lock = fn()
 } else {
   if (!lock) {
   }
 }
}

looks harmless to me, AFAICS. Also, please do note that, if the
function coldlock exits due to some reason for not finding valid symbols,
stv090x_search is again fired up from the kernel frontend thread.
It is easy to make such cleanup patches and cause breakages, but a
lot time consuming to fix such issues. My 2c.

Best Regards,

Manu
--
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] stv090x: remove indent levels

2014-02-17 Thread Manu Abraham
Hi Dan,

On Thu, Feb 6, 2014 at 2:58 PM, Dan Carpenter dan.carpen...@oracle.com wrote:
 1) We can flip the if (!lock) check to if (lock) return lock; and
then remove a big chunk of indenting.
 2) There is a redundant if (!lock) which we can remove since we
already know that lock is zero.  This removes another indent level.


The stv090x driver is a mature, but slightly complex driver supporting
quite some
different configurations. Is it that some bug you are trying to fix in there ?
I wouldn't prefer unnecessary code churn in such a driver for
something as simple
as gain in an indentation level.


Thanks,

Manu
--
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: Upstreaming SAA716x driver to the media_tree

2014-02-11 Thread Manu Abraham
On Tue, Feb 11, 2014 at 7:14 PM, Luis Alves lja...@gmail.com wrote:
 Hi,

 Any update on this?

I need to address the issues Mauro pointed out, prior to the merge.
Will address the issues during the next week. Have been a bit busy
restoring the system at my end after a crash.

Regards,

Manu
--
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: Driver for KWorld UB435Q Version 3 (ATSC) USB id: 1b80:e34c

2014-02-07 Thread Manu Abraham
On Sat, Feb 8, 2014 at 12:09 AM, Steven Toth st...@kernellabs.com wrote:
 On Fri, Feb 7, 2014 at 1:23 PM, The Bit Pit thebit...@earthlink.net wrote:
 Last May I started writing a driver for a KWorld UB435Q Version 3
 tuner.  I was able to make the kernel recognize the device, light it's
 LED, and try to enable the decoder and tuner.

 Slightly related I added support for the KWorld UB445-U2
 ATSC/Analog stick the other day. It uses the cx231xx bridge, LG3305
 and TDA18272 tuner. It was fairly simple to get running. Analog and
 digital TV work OK, the baseband inputs and alsa are running. No great
 shakes.

 Manu has a TDA18272 Linux tree if you google a little.


If you need, I can push the 7231 tree up as well for upstream merge.
--
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] stb0899: Fix DVB-S2 support for TechniSat SkyStar 2 HD CI USB ID 14f7:0002

2014-02-07 Thread Manu Abraham
On Sat, Feb 8, 2014 at 1:19 AM, David Jedelsky david.jedel...@gmail.com wrote:
 That changes I2C functionality from STOP + START to repeated START.
 Current functionality looks also very weird, as there is 5 messages sent,
 all with STOP condition. I am not surprised if actually bug is still in
 adapter... Somehow it should be first resolved how those messages are send,
 with repeated START or STOP. And fix I2C client or adapter or both.

 regards
 Antti



 Manu, Antti,

 Thank you for your response. I agree that the code is somewhat peculiar and
 it could be worthy to review it using documentation before I leave it as bug
 in my hw. Unfortunately I don't own appropriate documentation. If you can
 supply it I can look at it.

I can assure you that the STB0899 driver works well for S2 with most
USB bridges and PCI bridges, which brings me to the fact that the issue
does not exist with the STB0899 driver.

Regarding the documentation, I don't have any wrt to the USB bridge, but
only for the demodulator, tuner. But my hands are tied on that front, due to
NDA's and agreements.

Looking further in my hardware museum, I did find a
Technisat Skystar USB2 HD CI REV 2.0

The information on a white sticker on the PCB states:
Model AD-SB301, Project ID: 6027
DVB-S2, CI, USB Box (on-line update)
H/W Ver: A1, PID/VID: 14F7 / 0002

manufactured and sent to me by Azurewave.

It has a broken ferrite cored inductor on it, which appears to be on the
power line to the demodulator/tuner.

The PID/VID looks exactly the same as yours. If you have a firmware bug,
maybe it helps to update the firmware online ? (I guess the windows driver
uses some stock Cypress driver, from what I can imagine ?)

I had similar problems as you state, when I worked with a prototype version
of the Mantis PCI chipset where it had some issues regarding repeated
starts. I can't really remember the exact issue back then, but I do remember
the issue being tuner related as well, since the write to the tuner would reach
the very first tuner register alone. The communications to the tuner are
through a repeater on the demodulator.

This issue was addressed with an ECO Metal fix for the PCI bridge, but that
did eventually result in a newer chip though.

The problem could likely be similar with your USB bridge. Maybe it is a
driver bug too .. I haven't looked deeply at the az6027 driver.
--
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] stb0899: Fix DVB-S2 support for TechniSat SkyStar 2 HD CI USB ID 14f7:0002

2014-02-07 Thread Manu Abraham
On Sat, Feb 8, 2014 at 2:41 AM, Antti Palosaari cr...@iki.fi wrote:
 On 07.02.2014 22:54, Manu Abraham wrote:

 On Sat, Feb 8, 2014 at 1:19 AM, David Jedelsky david.jedel...@gmail.com
 wrote:

 That changes I2C functionality from STOP + START to repeated START.
 Current functionality looks also very weird, as there is 5 messages
 sent,
 all with STOP condition. I am not surprised if actually bug is still in
 adapter... Somehow it should be first resolved how those messages are
 send,
 with repeated START or STOP. And fix I2C client or adapter or both.

 regards
 Antti




 Manu, Antti,

 Thank you for your response. I agree that the code is somewhat peculiar
 and
 it could be worthy to review it using documentation before I leave it as
 bug
 in my hw. Unfortunately I don't own appropriate documentation. If you can
 supply it I can look at it.


 I can assure you that the STB0899 driver works well for S2 with most
 USB bridges and PCI bridges, which brings me to the fact that the issue
 does not exist with the STB0899 driver.

 Regarding the documentation, I don't have any wrt to the USB bridge, but
 only for the demodulator, tuner. But my hands are tied on that front, due
 to
 NDA's and agreements.

 Looking further in my hardware museum, I did find a
 Technisat Skystar USB2 HD CI REV 2.0

 The information on a white sticker on the PCB states:
 Model AD-SB301, Project ID: 6027
 DVB-S2, CI, USB Box (on-line update)
 H/W Ver: A1, PID/VID: 14F7 / 0002

 manufactured and sent to me by Azurewave.

 It has a broken ferrite cored inductor on it, which appears to be on the
 power line to the demodulator/tuner.

 The PID/VID looks exactly the same as yours. If you have a firmware bug,
 maybe it helps to update the firmware online ? (I guess the windows driver
 uses some stock Cypress driver, from what I can imagine ?)

 I had similar problems as you state, when I worked with a prototype
 version
 of the Mantis PCI chipset where it had some issues regarding repeated
 starts. I can't really remember the exact issue back then, but I do
 remember
 the issue being tuner related as well, since the write to the tuner would
 reach
 the very first tuner register alone. The communications to the tuner are
 through a repeater on the demodulator.

 This issue was addressed with an ECO Metal fix for the PCI bridge, but
 that
 did eventually result in a newer chip though.

 The problem could likely be similar with your USB bridge. Maybe it is a
 driver bug too .. I haven't looked deeply at the az6027 driver.


 It is almost 100% sure I2C adapter or client bug. az6027 driver i2c adapter
 seems to have some weird looking things, it behaves differently according
 I2C slave address used. If I didn't read code wrong, in that case it does to
 branch if (msg[i].addr == 0xd0). And looking that logic reveals it
 supports only 2 I2C transfers:


ACK. I looked at the code, just now. The I2C interface code looks garbage!


 for reg read: START + write + REPEATED START + read + STOP
 for reg write: START + write + STOP

 So that read operation (START + read + STOP) used by STB0899 is not
 implemented at all.

To be a bit more specific; the STB0899 S2 part. The STB0899 has a
different (but standard) I2C interface for the DVB-S demodulator and a
different one with 16/32 bit registers for the DVB-S2 demodulator. The
USB-I2C interface code for the bridge doesn't implement this interface.

But I see some still more weirdness in there with comments;
/* demod 16 bit addr */. There's a knot in my head, right now.

AFAICS, the overall I2C communication with the STB0899 is very standard,
generic I2C according to the official I2C specifications and documentations.
All STB0899 specific handling is done within the demodulator read/write
routines. If the I2C host interface with the USB device works in a standard
way, then the device should work as-is with no changes to any frontend
drivers.

Regards,

Manu
--
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] stb0899: Fix DVB-S2 support for TechniSat SkyStar 2 HD CI USB ID 14f7:0002

2014-02-06 Thread Manu Abraham
Hi David,


On Thu, Feb 6, 2014 at 3:15 PM, David Jedelsky david.jedel...@gmail.com wrote:

 My TechniSat SkyStar 2 HD CI USB ID 14f7:0002 wasn't tuning DVB-S2 channels.
 Investigation revealed that it doesn't read DVB-S2 registers out of stb0899.
 Comparison with usb trafic of the Windows driver showed the correct
 communication scheme. This patch implements it.
 The question is, whether the changed communication doesn't break other 
 devices.
 But the read part of patched _stb0899_read_s2reg routine is now functinally
 same as (not changed) stb0899_read_regs which reads ordinrary DVB-S registers.
 Giving high chance that it should work correctly on other devices too.


The patch does not look correct. STB0899 has a well documented
I2C access method, which involves dummy reads, prior to any
other. Also, the S2 regs access are different from the standard
register access. That's the first part of the register access.

The second part,
According to 7914335A, the output buffer is not updated until a
new address is requested. The controller returns the same value
given in the first read operation. Thus the current code.

So, most likely, all your modified read_s2reg would be reading
incorrect data out of the registers that you requested; ie could
be likely reading a standard register, or could possibly be
returning data for some other read.

With the current code, Without any changes S2 access does work
correctly with most bridges. It's extremely strange such a change
can cause things to work for you. From what I can see, your
USB I2C interface has an incorrect or a bad implementation
(I have seen such weirdness with some I2C implementations),
which could be a likely explanation for your symptoms.

Generally, a bug with the USB host device firmware, or a bug with
USB-I2C driver is the most probable case.

Best Regards,

Manu
--
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: Upstreaming SAA716x driver to the media_tree

2014-01-22 Thread Manu Abraham
On Wed, Jan 22, 2014 at 3:29 AM, Steven Toth st...@kernellabs.com wrote:
 On Mon, Jan 13, 2014 at 10:35 PM, Manu Abraham abraham.m...@gmail.com wrote:
 On Tue, Jan 14, 2014 at 12:20 AM, Steven Toth st...@kernellabs.com wrote:
 Manu, do you see any inconvenience in sending your driver to the
 linux_media tree?
 I'm available to place some effort on this task.


 I can push the 716x driver and whatever additional changes that I have
 later on this weekend, if that's okay with you.

 I never saw a push.

 Spliiting and cleaning up the patches took up more time than expected.
 Please wait a few days.

 Any news on this?


I just pushed out a large chunk of the changes. There are a few
dependencies that need to be resolved with the rebased tree.
--
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: Upstreaming SAA716x driver to the media_tree

2014-01-13 Thread Manu Abraham
On Tue, Jan 14, 2014 at 12:20 AM, Steven Toth st...@kernellabs.com wrote:
 Manu, do you see any inconvenience in sending your driver to the
 linux_media tree?
 I'm available to place some effort on this task.


 I can push the 716x driver and whatever additional changes that I have
 later on this weekend, if that's okay with you.

 I never saw a push.

Spliiting and cleaning up the patches took up more time than expected.
Please wait a few days.
--
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: Upstreaming SAA716x driver to the media_tree

2014-01-07 Thread Manu Abraham
Hi Luis,


On Tue, Jan 7, 2014 at 5:28 PM, Luis Alves lja...@gmail.com wrote:
 Hi,

 I'm finishing a new frontend driver for one of my dvb cards, but the
 pcie bridge uses the (cursed) saa716x.
 As far as I know the progress to upstream Manu's driver to the
 media_tree has stalled.

 In CC I've placed some of the people that I found working on it
 lately, supporting a few dvb cards.

 It would be good if we could gather everything in one place and send a
 few patchs to get this upstreamed for once...

 Manu, do you see any inconvenience in sending your driver to the
 linux_media tree?
 I'm available to place some effort on this task.


I can push the 716x driver and whatever additional changes that I have
later on this weekend, if that's okay with you.


Regards,

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


Re: [PATCH 2/3] femon: Display SNR in dB

2013-11-24 Thread Manu Abraham
Hi Jean,

Sorry, that I came upon this patch quite late.

On Mon, Jun 3, 2013 at 8:51 PM, Jean Delvare kh...@linux-fr.org wrote:
 SNR is supposed to be reported by the frontend drivers in dB, so print
 it that way for drivers which implement it properly.


Not all frontends do report report the SNR in dB. Well, You can say quite
some frontends do report it that way. Making the application report it in
dB for frontends which do not will show up as incorrect results, from what
I can say.

Best Regards,

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


Re: [PATCH 2/3] femon: Display SNR in dB

2013-11-24 Thread Manu Abraham
On Sun, Nov 24, 2013 at 11:32 PM, Chris Lee update...@gmail.com wrote:
 This is a frustration of mine. Some report it in SNR others report it
 in terms of % (current snr / (max_snr-min_snr)) others its completely
 random.

 Seems many dvb-s report arbitrary % which is stupid and many atsc
 report snr by 123 would be 12.3db. But there isnt any standardization
 around.

 imo everything should be reported in terms of db, why % was ever
 chosen is beyond logic.


Because dB terminology did not fit all frontends. For some it does
fit, but again not all. Some frontends by default don't have a dB
specification; some reverse engineered ones unable to.
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCHv2 dvb-apps] Silence last warnings in dvbscan.c

2013-11-23 Thread Manu Abraham
On Sat, Nov 23, 2013 at 4:25 PM, Hans Verkuil hverk...@xs4all.nl wrote:
 Hi Mike,

 This is the revised version of the patch I mailed earlier. As you requested
 I now use #if 0 instead of commenting out line to silence the warnings.

 Regards,

 Hans

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

 diff -r 7161fa4a3e33 util/dvbscan/dvbscan.c
 --- a/util/dvbscan/dvbscan.cThu Nov 14 16:45:24 2013 -0500
 +++ b/util/dvbscan/dvbscan.cSat Nov 23 11:54:53 2013 +0100
 @@ -74,8 +74,8 @@
Dual LO, 
 H:5150MHz, V:5750MHz.\n
 * One of the sec definitions from 
 the secfile if supplied\n
  -satpos positionSpecify DISEQC switch position for 
 DVB-S.\n
 --inversion on|off|auto Specify inversion (default: 
 auto).\n
 --uk-ordering  Use UK DVB-T channel ordering if 
 present.\n
 +-inversion on|off|auto Specify inversion (default: auto) 
 (note: this option is ignored).\n
 +-uk-ordering  Use UK DVB-T channel ordering if 
 present (note: this option is ignored).\n
  -timeout secs   Specify filter timeout to use 
 (standard specced values will be used by default)\n
  -filter filter  Specify service filter, a comma 
 seperated list of the following tokens:\n
 (If no filter is supplied, all 
 services will be output)\n
 @@ -83,10 +83,11 @@
 * radio - Output radio channels\n
 * other - Output other channels\n
 * encrypted - Output encrypted 
 channels\n
 --out raw filename|-  Output in raw format to filename 
 or stdout\n
 +-out raw filename|- Output in raw format to filename or 
 stdout\n
   channels filename|-  Output in channels.conf format 
 to filename or stdout.\n
   vdr12 filename|- Output in vdr 1.2.x format to 
 filename or stdout.\n
   vdr13 filename|- Output in vdr 1.3.x format to 
 filename or stdout.\n
 +  Note: this option is ignored.\n
  initial scan file\n;
 fprintf(stderr, %s\n, _usage);

 @@ -121,15 +122,17 @@
 char *secfile = NULL;
 char *secid = NULL;
 int satpos = 0;
 -   enum dvbfe_spectral_inversion inversion = DVBFE_INVERSION_AUTO;
 int service_filter = -1;
 -   int uk_ordering = 0;
 int timeout = 5;
 -   int output_type = OUTPUT_TYPE_RAW;
 -   char *output_filename = NULL;
 char *scan_filename = NULL;
 struct dvbsec_config sec;
 int valid_sec = 0;
 +#if 0
 +   char *output_filename = NULL;
 +   enum dvbfe_spectral_inversion inversion = DVBFE_INVERSION_AUTO;
 +   int output_type = OUTPUT_TYPE_RAW;
 +   int uk_ordering = 0;
 +#endif

 while(argpos != argc) {
 if (!strcmp(argv[argpos], -h)) {
 @@ -171,6 +174,7 @@
 } else if (!strcmp(argv[argpos], -inversion)) {
 if ((argc - argpos)  2)
 usage();
 +#if 0
 if (!strcmp(argv[argpos+1], off)) {
 inversion = DVBFE_INVERSION_OFF;
 } else if (!strcmp(argv[argpos+1], on)) {
 @@ -180,11 +184,14 @@
 } else {
 usage();
 }
 +#endif
 argpos+=2;
 } else if (!strcmp(argv[argpos], -uk-ordering)) {
 if ((argc - argpos)  1)
 usage();
 +#if 0
 uk_ordering = 1;
 +#endif
 } else if (!strcmp(argv[argpos], -timeout)) {
 if ((argc - argpos)  2)
 usage();
 @@ -211,6 +218,7 @@
 } else if (!strcmp(argv[argpos], -out)) {
 if ((argc - argpos)  3)
 usage();
 +#if 0
 if (!strcmp(argv[argpos+1], raw)) {
 output_type = OUTPUT_TYPE_RAW;
 } else if (!strcmp(argv[argpos+1], channels)) {
 @@ -225,6 +233,7 @@
 output_filename = argv[argpos+2];
 if (!strcmp(output_filename, -))
 output_filename = NULL;
 +#endif
 } else {
 if ((argc - argpos) != 1)
 usage();
 --

Sorry, I missed you earlier patch.

Please remove the obsolete flags and the #if 0. Those are pointless.

Regards,

Manu
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to 

Re: [PATCH 3/8] Montage M88DS3103 DVB-S/S2 demodulator driver

2013-11-08 Thread Manu Abraham
On Wed, Nov 6, 2013 at 11:27 PM, Antti Palosaari cr...@iki.fi wrote:
 ---
  drivers/media/dvb-frontends/Kconfig  |7 +
  drivers/media/dvb-frontends/Makefile |1 +
  drivers/media/dvb-frontends/m88ds3103.c  | 1293 
 ++
  drivers/media/dvb-frontends/m88ds3103.h  |  108 +++
  drivers/media/dvb-frontends/m88ds3103_priv.h |  218 +
  5 files changed, 1627 insertions(+)
  create mode 100644 drivers/media/dvb-frontends/m88ds3103.c
  create mode 100644 drivers/media/dvb-frontends/m88ds3103.h
  create mode 100644 drivers/media/dvb-frontends/m88ds3103_priv.h

 diff --git a/drivers/media/dvb-frontends/Kconfig 
 b/drivers/media/dvb-frontends/Kconfig
 index bddbab4..6c46caf 100644
 --- a/drivers/media/dvb-frontends/Kconfig
 +++ b/drivers/media/dvb-frontends/Kconfig
 @@ -35,6 +35,13 @@ config DVB_STV6110x
 help
   A Silicon tuner that supports DVB-S and DVB-S2 modes

 +config DVB_M88DS3103
 +   tristate Montage M88DS3103
 +   depends on DVB_CORE  I2C
 +   default m if !MEDIA_SUBDRV_AUTOSELECT
 +   help
 + Say Y when you want to support this frontend.
 +
  comment Multistandard (cable + terrestrial) frontends
 depends on DVB_CORE

 diff --git a/drivers/media/dvb-frontends/Makefile 
 b/drivers/media/dvb-frontends/Makefile
 index f9cb43d..0c75a6a 100644
 --- a/drivers/media/dvb-frontends/Makefile
 +++ b/drivers/media/dvb-frontends/Makefile
 @@ -85,6 +85,7 @@ obj-$(CONFIG_DVB_STV6110) += stv6110.o
  obj-$(CONFIG_DVB_STV0900) += stv0900.o
  obj-$(CONFIG_DVB_STV090x) += stv090x.o
  obj-$(CONFIG_DVB_STV6110x) += stv6110x.o
 +obj-$(CONFIG_DVB_M88DS3103) += m88ds3103.o
  obj-$(CONFIG_DVB_ISL6423) += isl6423.o
  obj-$(CONFIG_DVB_EC100) += ec100.o
  obj-$(CONFIG_DVB_HD29L2) += hd29l2.o
 diff --git a/drivers/media/dvb-frontends/m88ds3103.c 
 b/drivers/media/dvb-frontends/m88ds3103.c
 new file mode 100644
 index 000..91b3729
 --- /dev/null
 +++ b/drivers/media/dvb-frontends/m88ds3103.c
 @@ -0,0 +1,1293 @@
 +/*
 + * Montage M88DS3103 demodulator driver
 + *
 + * Copyright (C) 2013 Antti Palosaari cr...@iki.fi
 + *
 + *This program is free software; you can redistribute it and/or modify
 + *it under the terms of the GNU General Public License as published by
 + *the Free Software Foundation; either version 2 of the License, or
 + *(at your option) any later version.
 + *
 + *This program is distributed in the hope that it will be useful,
 + *but WITHOUT ANY WARRANTY; without even the implied warranty of
 + *MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
 + *GNU General Public License for more details.
 + *
 + *You should have received a copy of the GNU General Public License along
 + *with this program; if not, write to the Free Software Foundation, Inc.,
 + *51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA.
 + */
 +
 +#include m88ds3103_priv.h
 +
 +static struct dvb_frontend_ops m88ds3103_ops;
 +
 +/* write multiple registers */
 +static int m88ds3103_wr_regs(struct m88ds3103_priv *priv,
 +   u8 reg, const u8 *val, int len)
 +{
 +   int ret;
 +   u8 buf[1 + len];
 +   struct i2c_msg msg[1] = {
 +   {
 +   .addr = priv-cfg-i2c_addr,
 +   .flags = 0,
 +   .len = sizeof(buf),
 +   .buf = buf,
 +   }
 +   };
 +
 +   buf[0] = reg;
 +   memcpy(buf[1], val, len);
 +
 +   mutex_lock(priv-i2c_mutex);
 +   ret = i2c_transfer(priv-i2c, msg, 1);
 +   mutex_unlock(priv-i2c_mutex);
 +   if (ret == 1) {
 +   ret = 0;
 +   } else {
 +   dev_warn(priv-i2c-dev,
 +   %s: i2c wr failed=%d reg=%02x len=%d\n,
 +   KBUILD_MODNAME, ret, reg, len);
 +   ret = -EREMOTEIO;
 +   }
 +
 +   return ret;
 +}
 +
 +/* read multiple registers */
 +static int m88ds3103_rd_regs(struct m88ds3103_priv *priv,
 +   u8 reg, u8 *val, int len)
 +{
 +   int ret;
 +   u8 buf[len];
 +   struct i2c_msg msg[2] = {
 +   {
 +   .addr = priv-cfg-i2c_addr,
 +   .flags = 0,
 +   .len = 1,
 +   .buf = reg,
 +   }, {
 +   .addr = priv-cfg-i2c_addr,
 +   .flags = I2C_M_RD,
 +   .len = sizeof(buf),
 +   .buf = buf,
 +   }
 +   };
 +
 +   mutex_lock(priv-i2c_mutex);
 +   ret = i2c_transfer(priv-i2c, msg, 2);
 +   mutex_unlock(priv-i2c_mutex);
 +   if (ret == 2) {
 +   memcpy(val, buf, len);
 +   ret = 0;
 +   } else {
 +   dev_warn(priv-i2c-dev,
 +   %s: i2c rd failed=%d reg=%02x len=%d\n,
 +   KBUILD_MODNAME, ret, reg, len);
 +   

Re: [PATCH 3/8] Montage M88DS3103 DVB-S/S2 demodulator driver

2013-11-08 Thread Manu Abraham
On Sat, Nov 9, 2013 at 8:18 AM, Antti Palosaari cr...@iki.fi wrote:
 On 09.11.2013 04:35, Manu Abraham wrote:

 On Wed, Nov 6, 2013 at 11:27 PM, Antti Palosaari cr...@iki.fi wrote:



 +/*
 + * Driver implements own I2C-adapter for tuner I2C access. That's since
 chip
 + * has I2C-gate control which closes gate automatically after I2C
 transfer.
 + * Using own I2C adapter we can workaround that.
 + */



 Why should the demodulator implement it's own adapter for tuner access ?


 In order to implement it properly.



 DS3103 is identical to DS3002, DS3000 which is similar to all other
 dvb demodulators. Comparing datsheets of these demodulators
 with others, I can't see any difference in the repeater setup, except
 for an additional bit field to control the repeater block itself.

 Also, from what I see, the vendor; Montage has a driver, which appears
 to be more code complete looking at this url. http://goo.gl/biaPYu

 Do you still think the DS3103 is much different in comparison ?


DS3000 demodulator datasheet states:

To avoid unwanted noise disturbing the tuner performance, the
M88DS3000 offers a 2-wire bus repeater dedicated for tuner
control. The tuner is connected to the M88DS3000 through the
SCLT and SDAT pins. See Figure 11. Every time the 2-wire bus
master wants to access the tuner registers, it must enable the
repeater first. When the repeater is enabled, the SDAT and SCLT
pins are active. The messages on the SDA and SCL pins is
repeated on the SDAT and SCLT pins. The repeater will be
automatically disabled once the access times to the tuner
reaches the configured value. When disabled, the SCLT and
SDAT pins are completely isolated from the 2-wire bus and
become inactive (HIGH).

DS3002 demodulator datasheet states:

To avoid unwanted noise disturbing the tuner performance, the
M88DS3002B offers a 2-wire bus repeater dedicated for tuner
control. The tuner is connected to the M88DS3002B through
the SCLT and SDAT pins. See Figure 12. Every time the 2-wire
bus master wants to access the tuner registers, it must enable
the repeater first by configuring bit 2_WIRE_REP_EN (03H).
When the repeater is enabled, the SDAT and SCLT pins are
active. The messages on the SDA and SCL pins is repeated
on the SDAT and SCLT pins. The repeater will be automatically
disabled once the access times to the tuner reaches the
configured value set in bits 2_WIRE_REP_TM[2:0] (03H).
When disabled, the SCLT and SDAT pins are completely
isolated from the 2-wire bus and become inactive (HIGH).

DS3013 demodulator datasheet states:

To avoid unwanted noise disturbing the tuner performance, the
M88DS3103 offers a 2-wire bus repeater dedicated for tuner
control. The tuner is connected to the M88DS3103 through the
SCLT and SDAT pins. See Figure 12. Every time the 2-wire bus
master wants to access the tuner registers, it must enable the
repeater first by configuring bit 2_WIRE_REP_EN (03H). When
the repeater is enabled, the SDAT and SCLT pins are active.
The messages on the SDA and SCL pins is repeated on the
SDAT and SCLT pins. The repeater will be automatically
disabled once the access times to the tuner reaches the
configured value set in bits 2_WIRE_REP_TM[2:0] (03H).
When disabled, the SCLT and SDAT pins are completely
isolated from the 2-wire bus and become inactive (HIGH).

When you compare this with *almost* any other demodulator
that exists; This behaviour is much consistent with that which
exists in the mainline kernel source.


If you look at most DVB-S/S2 demodulator drivers almost all
of them do have an I2C repeater, which in some cases are
configurable for a) auto-manual close, b) auto close,
c) manual close. The majority of them do auto close,
unless bugs on the hardware implementation do exist.

What I don't understand why you need an I2C adapter to handle
the I2C repeater. All demodulator drivers use i2c_gate_ctl
to enable/disable the repeater.

ie, how is your i2c_adapter implementation for the ds3103
demodulator going to make things better than:

static int ds3103_i2c_gate_ctrl(struct dvb_frontend *fe, int enable)
{
struct ds3103_state *state = fe-demodulator_priv;

if (enable)
ds3103_writereg(state, 0x03, 0x12);
else
ds3103_writereg(state, 0x03, 0x02);

return 0;
}

which is more common to all other DVB demodulator drivers.
Please don't make weird implementations for straight forward
stuff.


 There was even some patches, maybe 2 years, ago in order to mainline that
 but it never happened.

??


 More complete is here 53 vs. 86 register writes, so yes it is more ~40 more
 complete if you like to compare it like that.

What I would stress more, is that the driver at this URL

http://goo.gl/biaPYu

is from Montage themselves rather than a reverse engineered one;
rather than the number of lines of code, or number of registers.
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org

Re: [PATCH 4/9] [media] pci: mantis: Remove redundant pci_set_drvdata

2013-09-30 Thread Manu Abraham
On Fri, Sep 20, 2013 at 2:06 PM, Sachin Kamat sachin.ka...@linaro.org wrote:
 Driver core sets driver data to NULL upon failure or remove.

 Signed-off-by: Sachin Kamat sachin.ka...@linaro.org
 Cc: Manu Abraham abraham.m...@gmail.com
Acked-by: Manu Abraham m...@linuxtv.org
 ---
  drivers/media/pci/mantis/mantis_pci.c |2 --
  1 file changed, 2 deletions(-)

 diff --git a/drivers/media/pci/mantis/mantis_pci.c 
 b/drivers/media/pci/mantis/mantis_pci.c
 index a846036..9e89e04 100644
 --- a/drivers/media/pci/mantis/mantis_pci.c
 +++ b/drivers/media/pci/mantis/mantis_pci.c
 @@ -143,7 +143,6 @@ fail1:

  fail0:
 dprintk(MANTIS_ERROR, 1, ERROR: %d exiting, ret);
 -   pci_set_drvdata(pdev, NULL);
 return ret;
  }
  EXPORT_SYMBOL_GPL(mantis_pci_init);
 @@ -161,7 +160,6 @@ void mantis_pci_exit(struct mantis_pci *mantis)
 }

 pci_disable_device(pdev);
 -   pci_set_drvdata(pdev, NULL);
  }
  EXPORT_SYMBOL_GPL(mantis_pci_exit);

 --
 1.7.9.5

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


Re: [PATCH 8/9] [media] pci: bt878: Remove redundant pci_set_drvdata

2013-09-30 Thread Manu Abraham
On Fri, Sep 20, 2013 at 2:06 PM, Sachin Kamat sachin.ka...@linaro.org wrote:
 Driver core sets driver data to NULL upon failure or remove.

 Signed-off-by: Sachin Kamat sachin.ka...@linaro.org
Acked-by: Manu Abraham m...@linuxtv.org
 ---
  drivers/media/pci/bt8xx/bt878.c |1 -
  1 file changed, 1 deletion(-)

 diff --git a/drivers/media/pci/bt8xx/bt878.c b/drivers/media/pci/bt8xx/bt878.c
 index 66eb0ba..2bd2483 100644
 --- a/drivers/media/pci/bt8xx/bt878.c
 +++ b/drivers/media/pci/bt8xx/bt878.c
 @@ -563,7 +563,6 @@ static void bt878_remove(struct pci_dev *pci_dev)
 bt-shutdown = 1;
 bt878_mem_free(bt);

 -   pci_set_drvdata(pci_dev, NULL);
 pci_disable_device(pci_dev);
 return;
  }
 --
 1.7.9.5

 --
 To unsubscribe from this list: send the line unsubscribe linux-media in
 the body of a message to majord...@vger.kernel.org
 More majordomo info at  http://vger.kernel.org/majordomo-info.html
--
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: Correct scan file format?

2013-09-11 Thread Manu Abraham
On Wed, Sep 11, 2013 at 6:19 PM, Simon Liddicott si...@liddicott.com wrote:
 What form should T2 multiplexes take in the DVB scan files?

 In the uk-CrystalPalace scan file
 http://git.linuxtv.org/dtv-scan-tables.git/blob/HEAD:/dvb-t/uk-CrystalPalace
 the PLP_ID and System_ID are included before the frequency but in
 ro-Krasnador scan file
 http://git.linuxtv.org/dtv-scan-tables.git/blob/HEAD:/dvb-t/ru-Krasnodar
 the PLP_ID is included at the end of the line and it has no System_ID.



PLP_ID should be the very last entity to preserve compatibility.



 I don't have a T2 tuner to test. Is a PLP_ID required in the scan file
 as in the UK we only have one?




If you have only a single stream, it wouldn't make any difference if you
have a PLP_ID or not.



 I presume the System_ID has been included in the Crystal Palace file
 because it was known by w_scan, but is it required for T2?



System ID is used for decryption with Conditional Access. If you don't
need to use a CA module, then you can ignore it.


Regards,

Manu
--
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] stv090x: on tuning lock return correct tuned paramaters like freq/sr/fec/rolloff/etc

2013-08-24 Thread Manu Abraham
On Wed, Jul 24, 2013 at 9:38 PM, Chris Lee update...@gmail.com wrote:

 If you need it broken up more just let me know, I look forward to comments, 
 thanks


Sorry about the late comments, have been a bit too busy ..

I have a bit hard time, understanding the need for some of the changes.
Comments, inline.


 Chris

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

 diff --git a/drivers/media/dvb-frontends/stv090x.c 
 b/drivers/media/dvb-frontends/stv090x.c
 index 56d470a..474584f 100644
 --- a/drivers/media/dvb-frontends/stv090x.c
 +++ b/drivers/media/dvb-frontends/stv090x.c
 @@ -1678,6 +1678,7 @@ static u32 stv090x_get_srate(struct stv090x_state 
 *state, u32 clk)
 ((int_1 * tmp_2)  16) +
 ((int_2 * tmp_1)  16);

 +   state-srate = srate;
 return srate;
  }

 @@ -2592,6 +2593,94 @@ static int stv090x_get_viterbi(struct stv090x_state 
 *state)
  static enum stv090x_signal_state stv090x_get_sig_params(struct stv090x_state 
 *state)
  {
 struct dvb_frontend *fe = state-frontend;
 +   struct dtv_frontend_properties *props = fe-dtv_property_cache;
 +
 +   int fe_stv0900_tracking_standard_return[] = {
 +   SYS_UNDEFINED,
 +   SYS_DVBS,
 +   SYS_DVBS2,
 +   SYS_DSS
 +   };
 +
 +   int fe_stv0900_rolloff_return[] = {
 +   ROLLOFF_35,
 +   ROLLOFF_25,
 +   ROLLOFF_20,
 +   ROLLOFF_AUTO
 +   };
 +
 +   int fe_stv0900_modulation_return[] = {
 +   QPSK,
 +   PSK_8,
 +   APSK_16,
 +   APSK_32
 +   };
 +
 +   int fe_stv0900_modcod_return_dvbs[] = {
 +   FEC_NONE,
 +   FEC_AUTO,
 +   FEC_AUTO,
 +   FEC_AUTO,
 +   FEC_1_2,
 +   FEC_3_5,
 +   FEC_2_3,
 +   FEC_3_4,
 +   FEC_4_5,
 +   FEC_5_6,
 +   FEC_6_7,
 +   FEC_7_8,
 +   FEC_3_5,
 +   FEC_2_3,
 +   FEC_3_4,
 +   FEC_5_6,
 +   FEC_8_9,
 +   FEC_9_10,
 +   FEC_2_3,
 +   FEC_3_4,
 +   FEC_4_5,
 +   FEC_5_6,
 +   FEC_8_9,
 +   FEC_9_10,
 +   FEC_3_4,
 +   FEC_4_5,
 +   FEC_5_6,
 +   FEC_8_9,
 +   FEC_9_10,
 +   FEC_AUTO
 +   };
 +
 +   int fe_stv0900_modcod_return_dvbs2[] = {
 +   FEC_NONE,
 +   FEC_AUTO,
 +   FEC_AUTO,
 +   FEC_AUTO,
 +   FEC_1_2,
 +   FEC_3_5,
 +   FEC_2_3,
 +   FEC_3_4,
 +   FEC_4_5,
 +   FEC_5_6,
 +   FEC_8_9,
 +   FEC_9_10,
 +   FEC_3_5,
 +   FEC_2_3,
 +   FEC_3_4,
 +   FEC_5_6,
 +   FEC_8_9,
 +   FEC_9_10,
 +   FEC_2_3,
 +   FEC_3_4,
 +   FEC_4_5,
 +   FEC_5_6,
 +   FEC_8_9,
 +   FEC_9_10,
 +   FEC_3_4,
 +   FEC_4_5,
 +   FEC_5_6,
 +   FEC_8_9,
 +   FEC_9_10,
 +   FEC_AUTO
 +   };

 u8 tmg;
 u32 reg;
 @@ -2631,10 +2720,71 @@ static enum stv090x_signal_state 
 stv090x_get_sig_params(struct stv090x_state *st
 state-modcod = STV090x_GETFIELD_Px(reg, DEMOD_MODCOD_FIELD);
 state-pilots = STV090x_GETFIELD_Px(reg, DEMOD_TYPE_FIELD)  0x01;
 state-frame_len = STV090x_GETFIELD_Px(reg, DEMOD_TYPE_FIELD)  1;
 -   reg = STV090x_READ_DEMOD(state, TMGOBS);
 -   state-rolloff = STV090x_GETFIELD_Px(reg, ROLLOFF_STATUS_FIELD);
 -   reg = STV090x_READ_DEMOD(state, FECM);
 -   state-inversion = STV090x_GETFIELD_Px(reg, IQINV_FIELD);
 +   reg = STV090x_READ_DEMOD(state, MATSTR1);
 +   state-rolloff = STV090x_GETFIELD_Px(reg, MATYPE_ROLLOFF_FIELD);
 +
 +   switch (state-delsys) {
 +   case STV090x_DVBS2:
 +   if (state-modcod = STV090x_QPSK_910)
 +   state-modulation = STV090x_QPSK;
 +   else if (state-modcod = STV090x_8PSK_910)
 +   state-modulation = STV090x_8PSK;
 +   else if (state-modcod = STV090x_16APSK_910)
 +   state-modulation = STV090x_16APSK;
 +   else if (state-modcod = STV090x_32APSK_910)
 +   state-modulation = STV090x_32APSK;
 +   else
 +   state-modulation = STV090x_UNKNOWN;
 +   reg = STV090x_READ_DEMOD(state, PLHMODCOD);


It is documented with Bug 6, that the demodulator may reject
the MODCOD being read out. As a result, it is 

Re: Proposed modifications to dvb_frontend_ops

2013-07-23 Thread Manu Abraham
On Sat, Jul 20, 2013 at 1:57 AM, Chris Lee update...@gmail.com wrote:
 In frontend.h we have a struct called dvb_frontend_ops, in there we
 have an element called delsys to show the delivery systems supported
 by the tuner, Id like to propose we add onto that with delmod and
 delfec.

 Its not a perfect solution as sometimes a specific modulation or fec
 is only availible on specific systems. But its better then what we
 have now. The struct fe_caps isnt really suited for this, its missing
 many systems, modulations, and fec's. Its just not expandable enough
 to get all the supported sys/mod/fec a tuner supports in there.

Question  Why should an application know all the modulations and
FEC's supported by a demodulator ?

Aren't demodulators compliant to their respective delivery systems ?

Or do you mean to state that, you are trying to work around some
demodulator quirks ?


Regards,

Manu
--
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: Proposed modifications to dvb_frontend_ops

2013-07-23 Thread Manu Abraham
On Tue, Jul 23, 2013 at 10:17 PM, Chris Lee update...@gmail.com wrote:
 Not all tuners support all fec's

Nitpick: tuner doesn't have anything to do with FEC, it just provides IQ
outputs to the demodulator. ;-)

That said;

Demods support all FEC's relevant to their delivery systems. It's just that
some devices likely do support some additional states.


 - genpix devices support an odd 5/11 fec for digicipher, pretty sure
 no one else does.

I think DCII FEC5/11 is standard, reading this URL
http://rickcaylor.websitetoolbox.com/post/DCII-Valid-SRFECModulation-Combinations-5827500

Also, according to the BCM4201 datasheet:
* DVB/DIRECTV/Digicipher II compliant FEC decoder
64 state viterbi decoder supports rates= 5/11, 1/2, 3/5, 2/3, 3/4.
4/5, 5/6, 6/7, 7/8

I would say, it is pretty much standard for DCII.

Given that it is pretty much standard, I would say that for DCII; for
the genpix
all you need is a SYS_DCII and or a SYS_DSS addition to the genpix driver,
rather than having a ton of delivery systems mixed with modulations as in
your patch with DCII_QPSK, ... _OQPSK etc. Actually, those are a bit too
superfluous. You shouldn't mix delivery systems and modulations. That was
the whole reason why the delivery system flag was introduced to make
things saner and proper for the frontend API.

If I am not mistaken, the genpix hardware is a hardware wrapper around the
BCM demodulator. So, it is quite likely that even if you don't set any FEC
parameter, the device could still acquire lock as expected. I am not holding
my breath on this. Maybe someone with a genpix device can prove me right
or wrong.


 - stv0899 supports 1/2, 2/3, 3/4, 5/6, 6/7, 7/8
 - stv0900 supports 1/2, 3/5, 2/3, 3/4, 4/5, 5/6, 8/9, 9/10


Ah

Though these devices support additional modes, the STB0899 (I don't know
whether you meant the STB0899 with stv0899, yet looking at the stb0899,
since there doesn't seem to be other references)

With the STB0899 driver, all you need to tune with it is Frequency,
Symbol Rate and Delivery system


With the STV090x driver all you need is Frequency and Symbol Rate.
(It will auto detect delivery system)



 Not all tuners support the entire range of fec's. I think this is more
 the norm then the exception.



I find it slightly hard to believe... ;-)


 If the userland application can poll the driver for a list of
 supported fec it allows them to have a list of valid tuning options
 for the user to choose from, vs listing everything and hoping it
 doesnt fail.


When a driver is not accepting those parameters as inputs, why
should the application/user burden himself with knowing parameters
of no relevance to him ?



 As stated Id much rather have a list made up from system - modulation - fec.

 ie genpix

 SYS_TURBO - QPSK/8PSK
 SYS_TURBO.QPSK - 1/2, 2/3, 3/4, 5/6, 7/8
 SYS_TURBO.8PSK - 2/3, 3/4, 5/6, 8/9

 but that could get more complicated to implement pretty quickly


Actually with all those redundant FEC bits gone away from relevance, things are
a bit more saner.

Regards,

Manu
--
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: Proposed modifications to dvb_frontend_ops

2013-07-23 Thread Manu Abraham
On Wed, Jul 24, 2013 at 2:57 AM, Chris Lee update...@gmail.com wrote:
 Nitpick: tuner doesn't have anything to do with FEC, it just provides IQ
 outputs to the demodulator. ;-)

 ya ya :) you knew what I meant, not what I said hehe

 Demods support all FEC's relevant to their delivery systems. It's just that
 some devices likely do support some additional states.

 This part I dont understand, what do you mean additional states ? and
 how would a userland application determine if a demod supports these
 additional states?


Actually, the userland application shouldn't know about these.


 If I am not mistaken, the genpix hardware is a hardware wrapper around the
 BCM demodulator. So, it is quite likely that even if you don't set any FEC
 parameter, the device could still acquire lock as expected. I am not holding
 my breath on this. Maybe someone with a genpix device can prove me right
 or wrong.

 FEC_AUTO works for all but turbo-qpsk on genpix devices.



That was why the SYS_TURBO flag was introduced. IIRC, you needed one
flag alone for the turbo mode.


 I still think its important to have all the fec supported in the
 driver though even if FEC_AUTO did work 100% else why even have it as
 an option at all.

Maybe, FEC_AUTO is broken for some very old hardware.

If FEC_AUTO works just as expected, why would you have to take the
gigantic effort of specifying parameters by hand which is error prone which
you have mentioned later on ? I fail to understand your point.


 With the STB0899 driver, all you need to tune with it is Frequency,
 Symbol Rate and Delivery system


 With the STV090x driver all you need is Frequency and Symbol Rate.
 (It will auto detect delivery system)

 Same thing, I still think if we allow the user to send a fec value we
 should make sure its right, else why not just hard code all the
 drivers to fec-auto that support it and remove the option all
 together. I dont like that option.



This is why it was decided eventually that the FEC bits are redundant
and we decided not to create large lists and enumerations causing
insanity and not to mention ugliness. AFAIR, almost all drivers do
FEC_AUTO, except for the ones which have some known issues.



 When a driver is not accepting those parameters as inputs, why
 should the application/user burden himself with knowing parameters
 of no relevance to him ?

 But it will accept them as inputs. without complaint too. I can send
 DTV_INNER_FEC w/ FEC_5_11 to stv090x and it doesnt complain at all,
 even though it doesnt support it. It'll even acquire a lock just
 because the demod uses blind search. So the driver most definitely
 does accept fec that it cant use.



The driver will acquire a lock to the frequency/srate and return the
relevant FEC value for the user/application. This avoids pitfalls and
human errors in manually specifying FEC bits to tune configurations,
as I described above. Because some legacy application does set
a FEC value which might be wrong and the rest are correct, I wouldn't
fail that request.



 Actually with all those redundant FEC bits gone away from relevance, things 
 are
 a bit more saner.

 I dont understand this either. gone away from relevance are you
 meaning just how they really arent used much anymore or something?
 still though if the demod supports them I think we should too.


Yeah, they aren't really used at all. They exist for compatibility reasons.


Manu
--
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: [GIT PULL for v3.11] media patches for v3.11

2013-07-01 Thread Manu Abraham
Mauro,

On Mon, Jul 1, 2013 at 4:28 PM, Mauro Carvalho Chehab
mche...@redhat.com wrote:
 Hi Linus,

 Please pull from:
   git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media 
 v4l_for_linus

 For the media patches for Kernel v3.11.



 Zoran Turalija (2):
   [media] stb0899: allow minimum symbol rate of 100
   [media] stb0899: allow minimum symbol rate of 200


Somehow, I missed these patches; These are incorrect. Please revert
these changes.
Simply changing the advertized minima values don't change the search algorithm
behaviour, it simply leads to broken behaviour.

NACK for these changes.


Regards,

Manu
--
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: [GIT PULL for v3.11] media patches for v3.11

2013-07-01 Thread Manu Abraham
On Mon, Jul 1, 2013 at 9:05 PM, Mauro Carvalho Chehab
mche...@redhat.com wrote:
 Em Mon, 1 Jul 2013 16:37:58 +0530
 Manu Abraham abraham.m...@gmail.com escreveu:

 Mauro,

 On Mon, Jul 1, 2013 at 4:28 PM, Mauro Carvalho Chehab
 mche...@redhat.com wrote:
  Hi Linus,
 
  Please pull from:
git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media 
  v4l_for_linus
 
  For the media patches for Kernel v3.11.
 

 
  Zoran Turalija (2):
[media] stb0899: allow minimum symbol rate of 100
[media] stb0899: allow minimum symbol rate of 200


 Somehow, I missed these patches; These are incorrect. Please revert
 these changes.
 Simply changing the advertized minima values don't change the search 
 algorithm
 behaviour, it simply leads to broken behaviour.

 NACK for these changes.

 While this patch came from a sub-maintainer's tree, looking at its
 history, the patch was proposed here:
 https://linuxtv.org/patch/18341/



Wherever it came from, the patch is incorrect. Anyone can throw in
any patch as they want.


 From what it is said there, with this patch, 6 additional channels
 were discovered when using with Eutelsat 16A, that uses a symbol
 rate between 2MS/s to 5 MS/s. Without this patch, those channels won't
 be discovered, as the core won't try to use a symbol rate outside
 the range.

What you are stating is a hit and miss scenario, sometimes it might lock
and sometimes it wouldn't.

The scanning algorithm that I implemented for the demodulator works
with a symbol rate as low as 5 MSPS alone. Anything lower than that
is hit and miss.


 Of course, transponders with a symbol rate equal or upper than 5MS/s
 won't be affected by this patch.



How can you be sure ? I myself am not very sure. While we worked on
the demodulator in the early days, we had different situations where a
previous failed state could cause lockup of the demodulator, eventually
resulting tuning failures.


 Even if this is not a perfect patch and some changes would be
 needed to improve tuning for those low symbol rate transponders,
 it seems better than before, as at least now some channels are tuned.

 The only reason I can see to reverse this patch is that if setting
 the frontend to low bit ranges could damage the frontend or could
 hit some bug on the hardware (or internal firmware).

 Yet, from the datasheet pointed by the patch author, it seems that
 this frontend allows such low symbol rates:
 http://comtech.sg1002.myweb.hinet.net/pdf/dvbs2-6899.pdf


The frontend allows a different lower symbol rate with a different
scanning algorithm, not with this existing current one.

I am pretty sure, that author saw some specifications written some
place and simply copied those numbers in here. Also sure that he
has no idea about the algorithm in use.

According to ST itself, a 2MSPS algorithm was created for a very
specific customer requirement, which is not applicable to the existing
algorithm in use with the Linux STB0899 demodulator driver.


Regards,
Manu
--
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: [GIT PULL for v3.11] media patches for v3.11

2013-07-01 Thread Manu Abraham
On Mon, Jul 1, 2013 at 11:12 PM, Mauro Carvalho Chehab
mche...@redhat.com wrote:
 Em Mon, 1 Jul 2013 21:17:58 +0530
 Manu Abraham abraham.m...@gmail.com escreveu:

 On Mon, Jul 1, 2013 at 9:05 PM, Mauro Carvalho Chehab
 mche...@redhat.com wrote:
  Em Mon, 1 Jul 2013 16:37:58 +0530
  Manu Abraham abraham.m...@gmail.com escreveu:
 
  Mauro,
 
  On Mon, Jul 1, 2013 at 4:28 PM, Mauro Carvalho Chehab
  mche...@redhat.com wrote:
   Hi Linus,
  
   Please pull from:
 git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media 
   v4l_for_linus
  
   For the media patches for Kernel v3.11.
  
 
  
   Zoran Turalija (2):
 [media] stb0899: allow minimum symbol rate of 100
 [media] stb0899: allow minimum symbol rate of 200
 
 
  Somehow, I missed these patches; These are incorrect. Please revert
  these changes.
  Simply changing the advertized minima values don't change the search 
  algorithm
  behaviour, it simply leads to broken behaviour.
 
  NACK for these changes.
 
  While this patch came from a sub-maintainer's tree, looking at its
  history, the patch was proposed here:
  https://linuxtv.org/patch/18341/
 


 Wherever it came from, the patch is incorrect. Anyone can throw in
 any patch as they want.


  From what it is said there, with this patch, 6 additional channels
  were discovered when using with Eutelsat 16A, that uses a symbol
  rate between 2MS/s to 5 MS/s. Without this patch, those channels won't
  be discovered, as the core won't try to use a symbol rate outside
  the range.

 What you are stating is a hit and miss scenario, sometimes it might lock
 and sometimes it wouldn't.

 Well, before this change, it was a full miss scenario, as it will
 never lock on low symbol rate channels.

 The scanning algorithm that I implemented for the demodulator works
 with a symbol rate as low as 5 MSPS alone. Anything lower than that
 is hit and miss.

 Ok, so latter patches need to improve the algorithm to improve it
 for lower symbol rates. By getting feedback about this patch, we'll
 know more about how bad is the current algorithm, as people may now
 report and work on improve it.

  Of course, transponders with a symbol rate equal or upper than 5MS/s
  won't be affected by this patch.
 


 How can you be sure ? I myself am not very sure. While we worked on
 the demodulator in the early days, we had different situations where a
 previous failed state could cause lockup of the demodulator, eventually
 resulting tuning failures.

 If that happens, that would be a firmware or hardware issue.
 As I said before, ST can provide us an answer if the hardware has
 such bug.

  Even if this is not a perfect patch and some changes would be
  needed to improve tuning for those low symbol rate transponders,
  it seems better than before, as at least now some channels are tuned.
 
  The only reason I can see to reverse this patch is that if setting
  the frontend to low bit ranges could damage the frontend or could
  hit some bug on the hardware (or internal firmware).
 
  Yet, from the datasheet pointed by the patch author, it seems that
  this frontend allows such low symbol rates:
  http://comtech.sg1002.myweb.hinet.net/pdf/dvbs2-6899.pdf


 The frontend allows a different lower symbol rate with a different
 scanning algorithm, not with this existing current one.

 I am pretty sure, that author saw some specifications written some
 place and simply copied those numbers in here. Also sure that he
 has no idea about the algorithm in use.

 According to ST itself, a 2MSPS algorithm was created for a very
 specific customer requirement, which is not applicable to the existing
 algorithm in use with the Linux STB0899 demodulator driver.

 Ok, so let's wait for ST to provide us some feedback on this public
 thread, in order to be sure that we need to reverse it because of
 some hardware bug, or to get an improved algorithm that will better
 work with low symbol rates.

I don't think anyone is going to spend enough time to answer your
stupid comments.

As being the author of this driver, and the person who added support
for cards based on the chipset: NACK

Linus,

I NACK the patches for the said reasons.


Regards,

Manu



Regards,

Manu
--
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: Status of the patches under review at LMML (32 patches)

2013-04-01 Thread Manu Abraham
On Sun, Mar 24, 2013 at 11:41 PM, Mauro Carvalho Chehab
mche...@redhat.com wrote:
 This is the summary of the patches that are currently under review at
 Linux Media Mailing List linux-media@vger.kernel.org.

 Manu,

 Yet another patch adding IR support for mantis. It seems that this is
 is a long waited feature, as from time to time, people send patches fixing it.
 Please test and apply it, or otherwise fix and send us a patch properly
 implementing support for it.

 Feb, 7 2013: [media] mantis: add remote control support   
   http://patchwork.linuxtv.org/patch/16732  Jan Klötzke 
 j...@kloetzke.net

I will look into it after these two weeks. Just tied up these two weeks.

Regards,
Manu
--
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: linux-dvb: scan util fix

2013-03-02 Thread Manu Abraham
On 2/28/13, j.uzy...@elproma.com.pl j.uzy...@elproma.com.pl wrote:
 Hi.

 I found a problem with scan and DVBS. When I research the transponder
 S13E0, freq. ~11471MHz, polar. V, symrate 27500 (scan -c -a 3) I get
 WARNING: section too short: service_id == 0x669, section_length == 764,
 descriptors_loop_len == 0 (scan_notpatched.output). VLC shows more
 channels / services. The problem is null descriptors_loop_len inside of
 SDT. However no descriptors of a service do not mean end of service
 list. I didn't find nothing about it in the spec. So it seems a little
 bug.

 When I applied my simple patch scan_sdt_test.patch I got rest of names
 of the services (scan_patched_test.output).
 The final simplest patch is scan_sdt.patch (scan_patched.output
 corresponds).

 The patch is not signed-off because I don't know hg/Mercurial enough
 yet.

Thanks. Applied.

Manu
--
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] stv090x: do not unlock unheld mutex in stv090x_sleep()

2013-02-19 Thread Manu Abraham
Hi,

On Wed, Feb 20, 2013 at 12:28 AM, Alexey Khoroshilov
khoroshi...@ispras.ru wrote:
 goto err and goto err_gateoff before mutex_lock(state-internal-demod_lock)
 lead to unlock of unheld mutex in stv090x_sleep().

Out of curiosity, what happens when you try to unlock an unlocked mutex ?

Regards,
Manu
--
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_T2 Multistream support (PLP)

2013-02-15 Thread Manu Abraham
On Thu, Jan 31, 2013 at 7:57 PM, Michael Stilmant-Rovi
stilmant.michael.r...@gmail.com wrote:
 Hello,

 I would like to know the support status of Multiple PLPs in DVB-T2.
 Is someone know if tests were performed in a broadcast with an
 effective Multistream? (PLP Id: 0 and 1 for example)

 I'm out of range of such multiplex but I'm trying some tunes on London
 DVB-T2 (CrystalPalace tower)
 unfortunately that mux seems Single PLP and everything work well :-(
   ( yes tune always succeed :-D )

 I'm using DVB API 5.6.
 If I tune with FE_SET_PROPERTY without or with DTV_DVBT2_PLP_ID set to
 0, 1 or 15. the tune succeed.

 I'm not sure of the expected behavior, I was expecting if I tune with
 plp_id 1 that the tuner would fail somewhere finding that stream.

 So in short I don't understand what is the requirements to be able to
 use the DVB_T2 Multistream support proposed in APIs:
  o I see that the DVB API 5.8(?) had some patch at that level and so
 it is maybe requested?
  o How can I know if my driver support that feature on DVB API 5.6?
 (PCTV nanoStick T2 290e)?

 Thank you for all indications.


At least, according to Sony: the CXD2820 chipset maker (hardware) doesn't
support multiple PLP's.


Regards,
Manu
--
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: EOPNOTSUPP vs. ENOTTY in ioctl(FE_READ_UNCORRECTED_BLOCKS)

2013-02-14 Thread Manu Abraham
On Thu, Feb 14, 2013 at 9:22 PM, Antti Palosaari cr...@iki.fi wrote:
 On 02/14/2013 03:12 PM, Klaus Schmidinger wrote:

 In VDR I use an ioctl() call with FE_READ_UNCORRECTED_BLOCKS on a device
 (using stb0899).
 After this call I check 'errno' for EOPNOTSUPP to determine whether this
 device supports this call. This used to work just fine, until a few months
 ago I noticed that my devices using stb0899 didn't display their signal
 quality in VDR's OSD any more. After further investigation I found that
 ioctl(FE_READ_UNCORRECTED_BLOCKS) no longer returns EOPNOTSUPP, but rather
 ENOTTY. And since I stop getting the signal quality in case any unknown
 errno value appears, this broke my signal quality query function.

 Is there a reason why this has been changed?


 I changed it in order to harmonize error codes. ENOTTY is correct error code
 for the case IOCTL is not implemented. What I think it is Kernel wide
 practice.


By doing so, You BROKE User Space ABI. Whatever it is, we are not allowed to
break User ABI. https://lkml.org/lkml/2012/12/23/75


 Should a caller check against both EOPNOTSUPP *and* ENOTTY?


 Current situation is a big mess. All the drivers are returning what error
 codes they wish. You simply cannot trust any error code.


As you stated above, If a device doesn't have an IOCTL implemented, it
was returning EOPNOTSUPP for *any* driver that doesn't implement that
IOCTL. By changing it to ENOTTY, you broke existing applications.

How can a driver return an error code, for an IOCTL that is *not* implemented ?
AFAICS, your statement is bogus. :-)


Regards,
Manu
--
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: EOPNOTSUPP vs. ENOTTY in ioctl(FE_READ_UNCORRECTED_BLOCKS)

2013-02-14 Thread Manu Abraham
On Fri, Feb 15, 2013 at 12:46 AM, Antti Palosaari cr...@iki.fi wrote:
 On 02/14/2013 08:05 PM, Manu Abraham wrote:

 On Thu, Feb 14, 2013 at 9:22 PM, Antti Palosaari cr...@iki.fi wrote:

 On 02/14/2013 03:12 PM, Klaus Schmidinger wrote:


 In VDR I use an ioctl() call with FE_READ_UNCORRECTED_BLOCKS on a device
 (using stb0899).
 After this call I check 'errno' for EOPNOTSUPP to determine whether this
 device supports this call. This used to work just fine, until a few
 months
 ago I noticed that my devices using stb0899 didn't display their signal
 quality in VDR's OSD any more. After further investigation I found that
 ioctl(FE_READ_UNCORRECTED_BLOCKS) no longer returns EOPNOTSUPP, but
 rather
 ENOTTY. And since I stop getting the signal quality in case any unknown
 errno value appears, this broke my signal quality query function.

 Is there a reason why this has been changed?



 I changed it in order to harmonize error codes. ENOTTY is correct error
 code
 for the case IOCTL is not implemented. What I think it is Kernel wide
 practice.


 By doing so, You BROKE User Space ABI. Whatever it is, we are not allowed
 to
 break User ABI. https://lkml.org/lkml/2012/12/23/75


 Yes, it will change API, that's clear. But the hell, how you will get
 anything fixed unless you change it? Introduce totally new API every-time
 when bug is found? You should also understand that changing that single
 error code on that place will not change all the drivers and there will be
 still some other error statuses returned by individual drivers.

 It is about 100% clear that ENOTTY is proper error code for unimplemented
 IOCTL. I remember maybe more than one discussion about that unimplemented
 IOCTL error code. It seems to be defined by POSIX [1] standard.


It could be. But what I stated is thus:

There existed commonality where all unimplemented IOCTL's returned
EOPNOTSUPP when the corresponding callback wasn't implemented.
So, this was kind of standardized though it was not the ideal thing,
though it was not a big issue, it just stated socket additionally.

You changed it to ENOTTY to make it fit for the idealistic world.
All applications that depended for ages, on those error are now broken.


Some drivers, have callbacks which are dummy as you state which
return different error codes ? It would have been easier, or correct to
fix those drivers, rather than blowing up all user applications.


 There is a lot of drivers implementing stub callbacks and returning own
 values. Likely much more than those which does not implement it at all.


 How can a driver return an error code, for an IOCTL that is *not*
 implemented ?
 AFAICS, your statement is bogus. :-)


 Just implementing IOCTL and returning some value! Have you looked those
 drivers?) There is very many different errors returned, especially in cases
 where hardware is not able to provide asked value at the time, example
 sleeping.


When you implement an IOCTL callback, then you have an implemented
IOCTL. I still don't understand by what you state:

ENOTTY is correct error code for the case IOCTL is not implemented.

in comparison to your above statement.

As i stated just above, it would be sensible to fix the drivers, rather than
causing even more confusion.


 Maybe the most common status is just to return 0 as status and some random
 numbers as data - but there has been some discussion it is bad idea too.

 It is just easy to fix back these few cases by implementing missing
 callbacks and return EOPNOTSUPP. But it will not fix all the drivers, only
 those which were totally without a callback.

 And I ran RFC before started harmonizing error codes. There was not too many
 people commenting how to standardize these error codes


Just because no one commented, doesn't make it right to blow up userspace
applications.

Regards,
Manu
--
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 RFCv10 00/15] DVB QoS statistics API

2013-01-17 Thread Manu Abraham
On Thu, Jan 17, 2013 at 3:03 PM, Antti Palosaari cr...@iki.fi wrote:
 On 01/17/2013 05:40 AM, Manu Abraham wrote:

 On Thu, Jan 17, 2013 at 3:31 AM, Mauro Carvalho Chehab
 mche...@redhat.com wrote:

 Em Wed, 16 Jan 2013 19:29:28 +
 Simon Farnsworth simon.farnswo...@onelan.com escreveu:

 On Wednesday 16 January 2013 23:56:48 Manu Abraham wrote:

 On Wed, Jan 16, 2013 at 10:51 PM, Mauro Carvalho Chehab

 snip


 It is a common sense that the existing API is broken. If my proposal
 requires adjustments, please comment on each specific patchset,
 instead
 of filling this thread of destructive and useless complains.



 No, the concept of such a generalization is broken, as each new device
 will
 be different and trying to make more generalization is a waste of
 developer
 time and effort. The simplest approach would be to do a coarse
 approach,
 which is not a perfect world, but it will do some good results for all
 the
 people who use Linux-DVB. Still, repeating myself we are not dealing
 with
 high end professional devices. If we have such devices, then it makes
 sense
 to start such a discussion. Anyway professional devices will need a lot
 of
 other API extensions, so your arguments on the need for professional
 devices that do not exist are pointless and not agreeable to.

 Let's step back a bit. As a sophisticated API user, I want to be able to
 give
 my end-users the following information:

   * Signal strength in dBm
   * Signal quality as poor, OK and good.
   * Ideally, increase signal strength to improve things or attenuate
 signal
 to improve things

 In a DVBv3 world, poor equates to UNC != 0, OK is UNC == 0, BER !=
 0,
 and good is UNC == BER == 0. The idea is that a user seeing poor
 knows
 that they will see glitches in the output; a user seeing OK knows that
 there's no glitching right now, but that the setup is marginal and may
 struggle if anything changes, and a user seeing good knows that
 they've got
 high quality signal.

 VDR wants even simpler - it just wants strength and quality on a 0 to
 100
 scale, where 100 is perfect, and 0 is nothing present.

 In both cases, we want per-layer quality for ISDB-T, for the reasons
 you've
 already outlined.

 So, how do you provide such information? Is it enough to simply provide
 strength in dBm, and quality as 0 to 100, where anything under 33
 indicates
 uncorrected errors, and anything under 66 indicates that quality is
 marginal?


 Unfortunately, not all devices can provide strength in dBm.


 MB86A20 is not the only demodulator driver with the Linux DVB.
 And not all devices can output in dB scale proposed by you, But any device
 output can be scaled in a relative way. So I don't see any reason why
 userspace has to deal with cumbersome controls to deal with redundant
 statistics, which is nonsense.


 What goes to these units in general, dB conversion is done by the driver
 about always. It is quite hard or even impossible to find out that formula
 unless you has adjustable test signal generator.

 Also we could not offer always dBm as signal strength. This comes to fact
 that only recent silicon RF-tuners are able to provide RF strength. More
 traditionally that estimation is done by demod from IF/RF AGC, which leads
 very, very, rough estimation.

What I am saying is that, rather than sticking to a dB scale, it would be
better to fit it into a relative scale, ie loose dB altogether and use only the
relative scale. With that approach any device can be fit into that convention.
Even with an unknown device, it makes it pretty easy for anyone to fit
into that
scale. All you need is a few trial runs to get maxima/minima. When there
exists only a single convention that is simple, it makes it more easier for
people to stick to that convention, rather than for people to not support it.

Manu
--
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 RFCv10 00/15] DVB QoS statistics API

2013-01-17 Thread Manu Abraham
On Thu, Jan 17, 2013 at 11:57 PM, Antti Palosaari cr...@iki.fi wrote:



 Resetting counters when user tunes channel sounds the only correct option.


This might not be correct, especially when we have true Multiple Input Streams.
The tune might be single, but the filter setup would be different. In
which case it
wouldn't correct to do a reset of the counters ona tune. Resetting the counters
should be the responsibility of the driver. As I said in an earlier
post, anything
other than the driver handling any statistical event monitoring, such an API is
broken for sure, without even reading single line of code for that API for which
 it is written for.


 OK, maybe we will see in near future if that works well or not. I think that
 for calculating of PER it is required to start continuous polling to keep up
 total block counters. Maybe updating UCB counter continously needs that too,
 so it should work.


With multi-standard demodulators, some of them PER compute is a by-product
of some internal demodulator algorithmic operation. In some cases, it might
require a loop in the driver. As I said, again; It is very hard/wrong
to do basic
generalizations.

Manu
--
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 RFCv10 00/15] DVB QoS statistics API

2013-01-17 Thread Manu Abraham
On Fri, Jan 18, 2013 at 12:41 AM, Antti Palosaari cr...@iki.fi wrote:
 On 01/17/2013 08:50 PM, Mauro Carvalho Chehab wrote:

 Em Fri, 18 Jan 2013 00:07:17 +0530
 Manu Abraham abraham.m...@gmail.com escreveu:

 On Thu, Jan 17, 2013 at 11:57 PM, Antti Palosaari cr...@iki.fi wrote:



 Resetting counters when user tunes channel sounds the only correct
 option.


 This might not be correct, especially when we have true Multiple Input
 Streams.
 The tune might be single, but the filter setup would be different. In
 which case it
 wouldn't correct to do a reset of the counters ona tune. Resetting the
 counters
 should be the responsibility of the driver.


 I moved the counters reset to the driver's logic on v11. I'm posting the
 patches in a few.

 As I said in an earlier
 post, anything
 other than the driver handling any statistical event monitoring, such an
 API is
 broken for sure, without even reading single line of code for that API
 for which
   it is written for.


 Yes, driver should have full control on it.

 OK, maybe we will see in near future if that works well or not. I think
 that
 for calculating of PER it is required to start continuous polling to
 keep up
 total block counters. Maybe updating UCB counter continously needs that
 too,
 so it should work.



 With multi-standard demodulators, some of them PER compute is a
 by-product
 of some internal demodulator algorithmic operation. In some cases, it
 might
 require a loop in the driver. As I said, again; It is very hard/wrong
 to do basic
 generalizations.


 Agreed.


 I think we will have soon kinda consensus everyone could approve! Anyhow, I
 didn't liked that kind of PATCH RFC process. That change was too big for
 PATCH style RFC and it was hard to keep track what going on looking those
 patches. Maybe requirement specification RFCs first and when requirements
 are clear = PATCH RFC for implementation.

 What I know understand, requirements are:

 signal strength:
 ==
 Offer both discussed methods.
 Simple [0...n] scale and dB...
 Driver must support simple scale over dB.


What happens, if the hardware doesn't support any dB scale ?



 CNR (SNR)
 ==
 Offer both discussed methods.
 Simple [0...n] scale and dB...
 Driver must support simple scale over dB.


Same question here as well.


 BER
 ==
 Offer global BER and per layer BER.
 Measure is returned as two numbers, one for error bit count and one for
 total bit count.

 uncorrected packets/blocks
 ==
 Offer global UCB and per layer UCB.
 Measure is returned as two numbers, one for uncorrected packet count and one
 for total packet count.

 counter reset
 ==
 counters are reset when channel is tuned


Counter reset behaviour is a bit undefined, for the reason stated earlier.
ie, the driver should do the reset, as it sees fit rather than common code.
well, it would be correct to state at start of frame count after
stream is initialized.
Initialization of stream can happen on legacy systems: only after successful
synchronous viterbi is achieved. Tuning to a channel doesn't make any sense.

In some of the non-legacy systems, stream initialization would happen
on a filter
setup change as well. It is not dependent on a  channel switch/tune.


 And if we end up returning simple values over dB values, then I think
 driver could be simple and implement only dB and dvb-core is responsible to
 convert dB = simple. That should quite be possible as we know which dB
 value is good signal and which is bad signal.

Again, not all devices can output in dB.

Manu
--
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 RFCv10 00/15] DVB QoS statistics API

2013-01-16 Thread Manu Abraham
On Wed, Jan 16, 2013 at 7:26 PM, Mauro Carvalho Chehab
mche...@redhat.com wrote:
 Em Wed, 16 Jan 2013 09:56:12 +0530
 Manu Abraham abraham.m...@gmail.com escreveu:

 On Wed, Jan 16, 2013 at 2:07 AM, Antti Palosaari cr...@iki.fi wrote:
  On 01/15/2013 07:12 PM, Mauro Carvalho Chehab wrote:
 
  Em Tue, 15 Jan 2013 17:26:17 +0200
  Antti Palosaari cr...@iki.fi escreveu:
 
  On 01/15/2013 04:49 PM, Antti Palosaari wrote:
 
  I am a little bit lazy to read all those patches, but I assume it is
  possible:
  * return SNR (CNR) as both dB and linear?
  * return signal strength as both dBm and linear?
 
  And what happens when when multiple statistics are queried, but fronted
  cannot perform all those?
 
  Lets say SS, SNR, BER, UCB are queried, but only SS and SNR are ready to
  be returned, whilst rest are not possible? As I remember DVBv5 API is
  broken by design and cannot return error code per request.
 
 
  OK, I read that patch still. All these are OK as there is SCALE flag
  used to inform if there is measurement or not available.
  No anymore question about these.
 
  Issues what I still would like to raise now are:
 
  1) How about change unit from dB/10 to dB/100 or even dB/1000, just for
  the sure?
 
 
  I'm OK with that. I doubt that it would be practical, but we have 64
  bits for it, so db/1000 will fit.
 
  2) Counter are reset when DELIVERY SYSTEM is set, practically when
  tuning attempt is done. There is new callback for that, but no API
  command. Functionality is correct for my eyes, is that extra callback
  needed?
 
 
  Not sure. It should be noticed that, at least on ISDB, some sort of
  reset may happen, for example if one layer disappears. The global BER
  will (with the current code) reflect the lack of the layer, by not summing
  up the data from the removed layer.
 
  Perhaps it makes more sense to, instead, add a way for the driver to flag
  when a counter reset happened.
 
  3) Post-BER. I don't need it, but is there someone else who thinks there
  should be both pre-BER and post-BER? IMHO, just better to leave it out
  to keep it simple. In practice both pre-BER and post-BER are running
  relatively, lets say if pre-BER shows number 1000 then post-BER shows
  only 10. Or pre-BER 600, post-BER 6. Due to that, I don't see much
  interest to return it for userspace. Of course someone would like to
  know how much inner coder is working and fixing error bits and in that
  case both BERs are nice...
 
 
  I don't see any need for it. In the case of ISDB, I'll likely convert
  the post-BER error into per-layer CNR, as it might be useful for one.
 
  I don't have any strong opinion on that though.
 
  4) Returning bit counts as BER and UCB means also driver should start
  polling work in order to keep driver internal counters up to date.
  Returning BER as rate is cheaper in that mean, as driver could make
  decision how often to poll and in which condition (and return values
  from cache). Keeping track of total bit counts means continuous polling!
 
 
  The way it was specified, the bit count/block count is relative to the
  same period where bit error/block error count was taken, and are there
  to calculate BER and PER.
 
 
  Eh, then this is functionality is against 2) what I asked about
  functionality of the counter reset. You should make decision to increase
  counters continuously and reset only given condition (on channel tune as it
  is done now) OR leave whole counter reset and increase to responsibility of
  the driver.
 
  Do you see conflict here???
 
  My opinion is to remove counter reset callback and leave all to
  responsibility of the driver.


 This, Is exactly one of the arguments that I raised. All statistics
 measurements
 should be the responsibility of the driver. Anything other than that,
 such an API
 is broken.

 All statistics measurements are already driver's responsibility on the
 proposed patches. The question is when to reset the counters.




Maybe you should give more thoughts to what you say in comparison
to your patch. It looks like your comments contradict your patch.



  Not all frontends allow continuous measurement of BER and PER. In the
  case of mb86a20s, BER is currently not continuous. I think that there's
  a way to do continuous PER measurement, but I need to double-check
  it.
 
 
  Personally I am going to implement that way it returns those bit counts 
  from
  the driver cache. Driver makes decision when to make measurements, like 
  just
  after channel is tuned and after that maybe once per minute or so.


 No Error Rate measurement, ie BER, PER or FER measurement can/will be
 continuous on *any* demodulator.

 There's one of the above measure on mb86a20s that can be continuous (MER). On
 continuous mode, the demod will automatically start the next measure when the
 results got available. There's a lock bit that prevents the data to be
 overridden during the time the value is being read.


Please stop your bluffing of people.
MER

Re: [PATCH RFCv10 00/15] DVB QoS statistics API

2013-01-16 Thread Manu Abraham
On Wed, Jan 16, 2013 at 10:51 PM, Mauro Carvalho Chehab
mche...@redhat.com wrote:

 If you have sufficient documentation, you can scale your demodulator 
 statistics
 to fit in that window area. I had done something similarly with a MB86A16
 demodulator. IIRC, some effort was done on the STV0900 and STV0903
 demodulator support as well to fit into that convention.

 All you need to do is scale the output of your demodulator to fit into
 that window.

 To what scale? dB? linear? 0% to 100%?


It is in a db scale, scaled to the window, IIRC. In an application, you can
convert that window area, you can convert it into a linear scale as well.



 As there's no way to tell what's the used scale, if some scale is required,
 _all_ demods are required to be converted to that scale, otherwise, userspace
 can't rely on the scale.

 Are you capable of doing such change on _all demods? If not, please stop
 arguing that the existing API can be fixable.

 Besides that, changing the existing stats to whatever scale breaks
 userspace compatibility.

 BREAKING USERSPACE IS A BIG NO.


Consider this simple situation:
Your new API is using get_frontend and is polling the hardware, Now an
existing application is also doing monitoring of the statistics. So, now all
the decision box calculations are screwed.
Now, WHO BROKE USERSPACE ?

The same situation will happen for any new API that's going to be built.

Scaling the output values of a demodulator, which doesn't behave in
accordance to the specifications is NOT BREAKING USERSPACE.


 What you are stating are just excuses, that do not exist.

 The same issue will exist, even with a new API and newer drivers not 
 complying
 to that API. I don't understand, why you fail to accept that fact.

 Newer drivers that don't implement an API right (being the a new one or an
 existing one) need to be fixed before being merged.

 It is as simple as that.


Okay, so what happens when a device that doesn't fit into your QoS
API, or that the
outputs of it are broken because of your API ?
I don't think it is that simple.


  What is eventually wanted is a 0-100% scale, a self rotating counter etc 
  scaled
  to a maxima minima, rather than adding in complexities. This already 
  exists,
  all it needs to do is add some more devices to be scaled to that 
  convention.
  And more importantly, one is not going to get that real professional
  measurements
   from these *home segment* devices. One of the chipset manufacturers once 
  told
  me that the PC segment never was interested in any real world performance
  oriented devices, it is all about cost and hence it is stuck with such
  low devices.
 
  The DVB API should be able to fit on both home and professional segment.


 I don't see any professional hardware drivers being written for the
 Linux DVB API.

 From the feedbacks we're getting during the media mini-summits,
 there are vendors that seem to be working on it. Anyway, what I'm saying
 is that the API should not be bound to any specific market segment.

 If drivers will be submitted upstream for professional hardware or not
 is a separate issue.


You are the one who had been touting all along on many linux-media threads,
on linux-kernel threads and what not; that API changes should not be made
for hardware that is not submitted upstream. So, I don't buy your argument
at all. Why did you argue with nvidia people that they shouldn't use dma-buf,
unless their driver is upstream. The same should hold good for what you are
talking now as well.



 
  Anyway, the existing API will be kept. Userspace may opt to use the legacy
  API if they're not interested on a scaled value.


 That is simply stating, that whatever other people like it or not, you
 will whack
 nonsense in.

 No. I'm simply stating that removing the existing API is not an option.

 Also, plese stop with fallacy: it is not me saying that the existing API
 is broken. I'm just the poor guy that is trying to fix the already known
 issue. Several users, userspace developers and kernelspace developers
 complain about the existing stats API. Even _you_ submitted a proposal
 years ago for a new stats API to try solving those issues.


I submitted a proposal to distinguish between the various statistics modes
used by different devices. But eventually it was found that it wasn't possible
to fit *all* devices that do exist into any convention. That was why I didn't
pursue that proposal further.

From what I learned from that, such information provided should be the
simplest possible thing, if we were to generalize on a large set of devices.
When being generalized with a large set of devices, however clever you are
or whatever technical might you have, you will still have issues with some
devices or the other. The end thoughts gathered from many people was that
such a generalization is futile, unless it is made for a very specific usecase.
A home user targeted API gets too complex and unusable in such an
 approach, making it harder 

Re: [PATCH RFCv10 00/15] DVB QoS statistics API

2013-01-16 Thread Manu Abraham
On Thu, Jan 17, 2013 at 12:59 AM, Simon Farnsworth
simon.farnswo...@onelan.com wrote:
 On Wednesday 16 January 2013 23:56:48 Manu Abraham wrote:
 On Wed, Jan 16, 2013 at 10:51 PM, Mauro Carvalho Chehab
 snip
 
  It is a common sense that the existing API is broken. If my proposal
  requires adjustments, please comment on each specific patchset, instead
  of filling this thread of destructive and useless complains.


 No, the concept of such a generalization is broken, as each new device will
 be different and trying to make more generalization is a waste of developer
 time and effort. The simplest approach would be to do a coarse approach,
 which is not a perfect world, but it will do some good results for all the
 people who use Linux-DVB. Still, repeating myself we are not dealing with
 high end professional devices. If we have such devices, then it makes sense
 to start such a discussion. Anyway professional devices will need a lot of
 other API extensions, so your arguments on the need for professional
 devices that do not exist are pointless and not agreeable to.

 Let's step back a bit. As a sophisticated API user, I want to be able to give
 my end-users the following information:

  * Signal strength in dBm
  * Signal quality as poor, OK and good.
  * Ideally, increase signal strength to improve things or attenuate signal
 to improve things

 In a DVBv3 world, poor equates to UNC != 0, OK is UNC == 0, BER != 0,
 and good is UNC == BER == 0. The idea is that a user seeing poor knows
 that they will see glitches in the output; a user seeing OK knows that
 there's no glitching right now, but that the setup is marginal and may
 struggle if anything changes, and a user seeing good knows that they've got
 high quality signal.

 VDR wants even simpler - it just wants strength and quality on a 0 to 100
 scale, where 100 is perfect, and 0 is nothing present.

 In both cases, we want per-layer quality for ISDB-T, for the reasons you've
 already outlined.

 So, how do you provide such information? Is it enough to simply provide
 strength in dBm, and quality as 0 to 100, where anything under 33 indicates
 uncorrected errors, and anything under 66 indicates that quality is marginal?

With DVB v3 the stats are interpreted thus:

http://linuxtv.org/downloads/legacy/old/linux_dvb_api-20020304.pdf

But, I am also not a big fan of that, but nevertheless it would have worked if
the drivers complied to that specification. The important thing that we learn
from history is that with a multitude of devices with different topologies and
methodologies, it is too hard to achieve a rigid structure.

Given the following statistical information available:

status 0x1f --- The demodulator status bits. 0x1f means all bits set,
everything ok.

signal [0x...0x] --- Signal Strength.
snr [0x...0x] --- Signal/Noise Ratio.

ber [0...0x] --- Bit Error Rate. The less the better.
unc [0...0x] --- Number of Uncorrectable Blocks. Small numbers
are preferable.


With ISDB-T, with the 3 layers, you have BER/UNC for each of the layers, though
the rate difference could be very little.

For one layer, you could map the details as is, into the existing convention,
while the other 2 could be retrieved querying the details for each of
the layers.
This will keep it simple, to avoid calculating values to try to make a
global value.
Care should be taken, as to not change the current behaviour.
That way, all applications will be happy and still be working as is,
while you will
get detailed information on a per-layer basis.

Now, to achieve a common standard, the values need to be fit into the window,
what most drivers are trying to do. In most cases, it could be
difficult to convert
from one format to another one in it's current form, without causing
real breakage
to existing drivers. That said for each of the drivers, it couldn't be
difficult to
convert to a relative scale say something like a 0-100% scale, without dBuV,
or mV or dB/10, or dB/100. There can be a zillion reason why a demodulator
is using a scale in it's driver. It might not be easy or make sense to
change those
values to a newer scale. But it wouldn't be that hard to scale those
to a relative scale.
In fact many or quite a lot of drivers while providing the information
in some specific
form are also in that relative form.

Does everyone working on the DVB drivers posses a spectrum analyzer to do
calibration to dBwhatever ? At my side, I have had access to one some
time back,
but not anymore.

As Klaus said, any idiot will understand the relative scale clearly,
without much
after thought. This will also help that all the developers need to see are the
maxima / minima, which could be easy.

This is userspace requesting to make things simpler, not to make it even more
worser.

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

Re: [PATCH RFCv10 00/15] DVB QoS statistics API

2013-01-16 Thread Manu Abraham
On Thu, Jan 17, 2013 at 12:52 AM, Mauro Carvalho Chehab
mche...@redhat.com wrote:
 Em Wed, 16 Jan 2013 23:56:48 +0530
 Manu Abraham abraham.m...@gmail.com escreveu:

 Consider this simple situation:
 Your new API is using get_frontend and is polling the hardware, Now an
 existing application is also doing monitoring of the statistics. So, now all
 the decision box calculations are screwed.

 -EREADTHEFUCKINGPATCHES

 Patch 04/15:

 ...
 +static int mb86a20s_read_signal_strength_from_cache(struct dvb_frontend *fe,
 +   u16 *strength)
 +{
 +   struct dtv_frontend_properties *c = fe-dtv_property_cache;

 +
 +   *strength = c-strength.stat[0].uvalue;
 +
 +   return 0;
  }
 ...

 The returned value there is in the same range as before.

 Enough. If you don't read the patches, you're just making everybody
 loosing their time with your biased and incorrect comments.

-EFUCKEDUPMORON

The behaviour of the ioctls did change completely.

Manu
--
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 RFCv10 00/15] DVB QoS statistics API

2013-01-16 Thread Manu Abraham
On Thu, Jan 17, 2013 at 3:41 AM, Mauro Carvalho Chehab
mche...@redhat.com wrote:
 Em Thu, 17 Jan 2013 03:07:21 +0530
 Manu Abraham abraham.m...@gmail.com escreveu:

 With ISDB-T, with the 3 layers, you have BER/UNC for each of the layers, 
 though
 the rate difference could be very little.

 Where? There's no way to report per-layer report with DVBv3.


To retrieve on a per layer basis, you will need exactly one control for that.
Nothing more. You don't need such an intrusive patch.



 And no, the difference is not very little:

 $ dmesg|grep -e mb86a20s_get_main_CNR -e bit error before -e bit count 
 before


Maybe the difference is small or big. Honestly, I have little trust in
code output by you,
after all the antics in recent threads.


Manu
--
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 RFCv10 00/15] DVB QoS statistics API

2013-01-16 Thread Manu Abraham
On Thu, Jan 17, 2013 at 3:31 AM, Mauro Carvalho Chehab
mche...@redhat.com wrote:
 Em Wed, 16 Jan 2013 19:29:28 +
 Simon Farnsworth simon.farnswo...@onelan.com escreveu:

 On Wednesday 16 January 2013 23:56:48 Manu Abraham wrote:
  On Wed, Jan 16, 2013 at 10:51 PM, Mauro Carvalho Chehab
 snip
  
   It is a common sense that the existing API is broken. If my proposal
   requires adjustments, please comment on each specific patchset, instead
   of filling this thread of destructive and useless complains.
 
 
  No, the concept of such a generalization is broken, as each new device will
  be different and trying to make more generalization is a waste of developer
  time and effort. The simplest approach would be to do a coarse approach,
  which is not a perfect world, but it will do some good results for all the
  people who use Linux-DVB. Still, repeating myself we are not dealing with
  high end professional devices. If we have such devices, then it makes sense
  to start such a discussion. Anyway professional devices will need a lot of
  other API extensions, so your arguments on the need for professional
  devices that do not exist are pointless and not agreeable to.
 
 Let's step back a bit. As a sophisticated API user, I want to be able to give
 my end-users the following information:

  * Signal strength in dBm
  * Signal quality as poor, OK and good.
  * Ideally, increase signal strength to improve things or attenuate signal
 to improve things

 In a DVBv3 world, poor equates to UNC != 0, OK is UNC == 0, BER != 0,
 and good is UNC == BER == 0. The idea is that a user seeing poor knows
 that they will see glitches in the output; a user seeing OK knows that
 there's no glitching right now, but that the setup is marginal and may
 struggle if anything changes, and a user seeing good knows that they've got
 high quality signal.

 VDR wants even simpler - it just wants strength and quality on a 0 to 100
 scale, where 100 is perfect, and 0 is nothing present.

 In both cases, we want per-layer quality for ISDB-T, for the reasons you've
 already outlined.

 So, how do you provide such information? Is it enough to simply provide
 strength in dBm, and quality as 0 to 100, where anything under 33 indicates
 uncorrected errors, and anything under 66 indicates that quality is marginal?

 Unfortunately, not all devices can provide strength in dBm.

MB86A20 is not the only demodulator driver with the Linux DVB.
And not all devices can output in dB scale proposed by you, But any device
output can be scaled in a relative way. So I don't see any reason why
userspace has to deal with cumbersome controls to deal with redundant
statistics, which is nonsense.

Manu
--
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 RFCv10 00/15] DVB QoS statistics API

2013-01-15 Thread Manu Abraham
On Tue, Jan 15, 2013 at 8:00 AM, Mauro Carvalho Chehab
mche...@redhat.com wrote:
 Add DVBv5 methods to retrieve QoS statistics.

 Those methods allow per-layer and global statistics.

 Implemented 2 QoS statistics on mb86a20s, one global only
 (signal strengh), and one per layer (BER).

 Tested with a modified version of dvbv5-zap, that allows monitoring
 those stats. Test data follows

 Tested with 1-segment at layer A, and 12-segment at layer B:

 [ 3735.973058] i2c i2c-4: mb86a20s_layer_bitrate: layer A bitrate: 440 kbps; 
 counter = 196608 (0x03)
 [ 3735.976803] i2c i2c-4: mb86a20s_layer_bitrate: layer B bitrate: 16851 
 kbps; counter = 8257536 (0x7e)

 a) Global stats:

 Signal strength:
 QOS_SIGNAL_STRENGTH[0] = 4096

 BER (sum of BE count and bit counts for both layers):
 QOS_BIT_ERROR_COUNT[0] = 1087865
 QOS_TOTAL_BITS_COUNT[0] = 67043313

 b) Per-layer stats:

 Layer A BER:
 QOS_BIT_ERROR_COUNT[1] = 236
 QOS_TOTAL_BITS_COUNT[1] = 917490

 Layer B BER:
 QOS_BIT_ERROR_COUNT[2] = 1087629
 QOS_TOTAL_BITS_COUNT[2] = 66125823

 TODO:
 - add more statistics at mb86a20s;
 - implement support for DTV_QOS_ENUM;
 - some cleanups at get_frontend logic at dvb core, to avoid
   it to be called outside the DVB thread loop.

 All the above changes can be done a little later during this development
 cycle, so my plan is to merge it upstream at the beginning of the
 next week, to allow others to test.



An API should be simple. This is far from simple. This API looks horribly
complex and broken, for anyone to use it in a sane way.

Polling from within dvb-core is not a good idea, as it can cause acquisition
failures. Continuous polling is known to cause issues.

Adding counters to be controlled externally by a user is the most silliest
thing altogether.

All these things put together, makes it the most inconvenient thing to be used.
Eventually, it results in more broken applications than existing.

Not to forget that too much work has to be put into drivers, which aren't going
to make things better, but rather even more worser.


Manu
--
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: Status of the patches under review at LMML (35 patches)

2013-01-15 Thread Manu Abraham
On Sun, Jan 6, 2013 at 7:04 PM, Mauro Carvalho Chehab
mche...@redhat.com wrote:
 This is the summary of the patches that are currently under review at
 Linux Media Mailing List linux-media@vger.kernel.org.
 Each patch is represented by its submission date, the subject (up to 70
 chars) and the patchwork link (if submitted via email).




 == Manu Abraham abraham.m...@gmail.com ==

 Those patches are there for a long time. I think I'll simply apply all of
 them, if they're not reviewed on the next couple weeks:

 Mar,11 2012: [2/3] stv090x: use error counter 1 for BER estimation
   http://patchwork.linuxtv.org/patch/10301  Andreas Regel 
 andreas.re...@gmx.de


I am not at all sure on this patch. If there is a valid test result on this
patch, then I am all for it.


 Mar,11 2012: [3/3] stv090x: On STV0903 do not set registers of the second 
 path. http://patchwork.linuxtv.org/patch/10302  Andreas Regel 
 andreas.re...@gmx.de

Patch seems mostly correct, there are some unpleasantness in it.
But nevertheless it looks okay. Haven't tested it at all.

Acked-by: Manu Abraham m...@linuxtv.org


 Nov,29 2011: stv090x: implement function for reading uncorrected blocks count 
   http://patchwork.linuxtv.org/patch/8656   Mariusz Bia?o?czyk 
 ma...@skyboo.net


Comments within patchwork itself.



 Jun, 8 2011: Add remote control support for mantis
   http://patchwork.linuxtv.org/patch/7217   Christoph Pinkl 
 christoph.pi...@gmail.com


I did test this patch a while back. It didn't work as expected at all.


 Apr, 1 2012: [05/11] Slightly more friendly debugging output. 
   http://patchwork.linuxtv.org/patch/10520  Steinar H. Gunderson 
 se...@samfundet.no

Simply a cosmetic patch. Doesn't bring any advantage. Knowing what
 MMIO address failed doesn't help at all. If you have failures, then you
will have failures with the entire mapped addresses. So AFAICT, this
patch doesn't bring any advantage to help in additional debugging either.


 Apr, 1 2012: [06/11] Replace ca_lock by a slightly more general 
 int_stat_lock.  http://patchwork.linuxtv.org/patch/10521  Steinar H. 
 Gunderson se...@samfundet.no


This is actually sleeping in interrupt context. All it does is a cosmetic
name change and adding a mutex across the IRQ handler, which is
 not a valid thing to do.

 Apr, 1 2012: [07/11] Fix a ton of SMP-unsafe accesses.
   http://patchwork.linuxtv.org/patch/10523  Steinar H. Gunderson 
 se...@samfundet.no


Use of volatile .. I am not sure. It does need a lock someplace, but I am
not sure whether this patch is doing correctly at all.


 Apr, 1 2012: [08/11] Remove some unused structure members.
   http://patchwork.linuxtv.org/patch/10525  Steinar H. Gunderson 
 se...@samfundet.no


The enumeration holds the status of the SmartBuffer, currently it is not
being checked against. Deleting it might not be a useful thing.. ? Though
the gpif_status in the mantis_dev structure could be removed, thus
removing a dereference.


 Apr, 1 2012: [09/11] Correct wait_event_timeout error return check.   
   http://patchwork.linuxtv.org/patch/10526  Steinar H. Gunderson 
 se...@samfundet.no

Patch is correct, but likely needs to be regenerated, being dependant on
another patch


 Apr, 1 2012: [10/11] Ignore timeouts waiting for the IRQ0 flag.   
   http://patchwork.linuxtv.org/patch/10527  Steinar H. Gunderson 
 se...@samfundet.no

There is something really wrong going on. The CPU went into a loop and
hence reads do not return. Ignoring timeouts doesn't seem the proper way
to me.


 Apr, 1 2012: [11/11] Enable Mantis CA support.
   http://patchwork.linuxtv.org/patch/10524  Steinar H. Gunderson 
 se...@samfundet.no

Not yet there.
--
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 RFCv10 00/15] DVB QoS statistics API

2013-01-15 Thread Manu Abraham
On Wed, Jan 16, 2013 at 2:07 AM, Antti Palosaari cr...@iki.fi wrote:
 On 01/15/2013 07:12 PM, Mauro Carvalho Chehab wrote:

 Em Tue, 15 Jan 2013 17:26:17 +0200
 Antti Palosaari cr...@iki.fi escreveu:

 On 01/15/2013 04:49 PM, Antti Palosaari wrote:

 I am a little bit lazy to read all those patches, but I assume it is
 possible:
 * return SNR (CNR) as both dB and linear?
 * return signal strength as both dBm and linear?

 And what happens when when multiple statistics are queried, but fronted
 cannot perform all those?

 Lets say SS, SNR, BER, UCB are queried, but only SS and SNR are ready to
 be returned, whilst rest are not possible? As I remember DVBv5 API is
 broken by design and cannot return error code per request.


 OK, I read that patch still. All these are OK as there is SCALE flag
 used to inform if there is measurement or not available.
 No anymore question about these.

 Issues what I still would like to raise now are:

 1) How about change unit from dB/10 to dB/100 or even dB/1000, just for
 the sure?


 I'm OK with that. I doubt that it would be practical, but we have 64
 bits for it, so db/1000 will fit.

 2) Counter are reset when DELIVERY SYSTEM is set, practically when
 tuning attempt is done. There is new callback for that, but no API
 command. Functionality is correct for my eyes, is that extra callback
 needed?


 Not sure. It should be noticed that, at least on ISDB, some sort of
 reset may happen, for example if one layer disappears. The global BER
 will (with the current code) reflect the lack of the layer, by not summing
 up the data from the removed layer.

 Perhaps it makes more sense to, instead, add a way for the driver to flag
 when a counter reset happened.

 3) Post-BER. I don't need it, but is there someone else who thinks there
 should be both pre-BER and post-BER? IMHO, just better to leave it out
 to keep it simple. In practice both pre-BER and post-BER are running
 relatively, lets say if pre-BER shows number 1000 then post-BER shows
 only 10. Or pre-BER 600, post-BER 6. Due to that, I don't see much
 interest to return it for userspace. Of course someone would like to
 know how much inner coder is working and fixing error bits and in that
 case both BERs are nice...


 I don't see any need for it. In the case of ISDB, I'll likely convert
 the post-BER error into per-layer CNR, as it might be useful for one.

 I don't have any strong opinion on that though.

 4) Returning bit counts as BER and UCB means also driver should start
 polling work in order to keep driver internal counters up to date.
 Returning BER as rate is cheaper in that mean, as driver could make
 decision how often to poll and in which condition (and return values
 from cache). Keeping track of total bit counts means continuous polling!


 The way it was specified, the bit count/block count is relative to the
 same period where bit error/block error count was taken, and are there
 to calculate BER and PER.


 Eh, then this is functionality is against 2) what I asked about
 functionality of the counter reset. You should make decision to increase
 counters continuously and reset only given condition (on channel tune as it
 is done now) OR leave whole counter reset and increase to responsibility of
 the driver.

 Do you see conflict here???

 My opinion is to remove counter reset callback and leave all to
 responsibility of the driver.


This, Is exactly one of the arguments that I raised. All statistics
measurements
should be the responsibility of the driver. Anything other than that,
such an API
is broken.



 Not all frontends allow continuous measurement of BER and PER. In the
 case of mb86a20s, BER is currently not continuous. I think that there's
 a way to do continuous PER measurement, but I need to double-check
 it.


 Personally I am going to implement that way it returns those bit counts from
 the driver cache. Driver makes decision when to make measurements, like just
 after channel is tuned and after that maybe once per minute or so.


No Error Rate measurement, ie BER, PER or FER measurement can/will be
continuous on *any* demodulator. First, there should be the minimum number of
frames that should pass through the decision box, then for that number
of frames
to occur, depending upon the delivery system and the implementation type, the
time required for this to be calculated on the demodulator FPGA will vary and
cannot be expected that it will be available at this instance or at
another instance.
All demodulators vary from one to another the way it is implemented. On most
demodulators, while trying to do computations within the decision box
whil trying
to acquire, or in some case while it has not acquired Synchronous Viterbi will
result in acquisition failure, longer time for acquisition, or even sub-optimal
acquisition etc, depending on a variety of factors. In short, only the
algorithms
used in a driver for the demodulator when it is safe to do measurements and no
one else.

This API 

Re: [RFC] Initial scan files troubles and brainstorming

2013-01-10 Thread Manu Abraham
On 1/9/13, Mauro Carvalho Chehab mche...@redhat.com wrote:
 Em Wed, 9 Jan 2013 06:08:44 -0500
 Michael Krufky mkru...@linuxtv.org escreveu:

 On Wed, Jan 9, 2013 at 5:41 AM, Mauro Carvalho Chehab
 mche...@redhat.com wrote:
  Em Wed, 09 Jan 2013 10:43:23 +0100
  Oliver Schinagl oliver+l...@schinagl.nl escreveu:
 
  On 08-01-13 21:01, Johannes Stezenbach wrote:
   On Mon, Jan 07, 2013 at 01:48:29PM +0100, Oliver Schinagl wrote:
   On 07-01-13 11:46, Jiri Slaby wrote:
   On 12/18/2012 11:01 PM, Oliver Schinagl wrote:
   Unfortunatly, I have had zero replies.
   Hmm, it's sad there is a silence in this thread from linux-media
   guys :/.
   In their defense, they are very very busy people ;) chatter on this
   thread does bring it up however.
   This is such a nice thing to say :-)
   But it might be that Mauro thinks the dvb-apps maintainer should
   respond, but apparently there is no dvb-apps maintainer...
   Maybe you should ask Mauro directly to create an account for you
   to implement what you proposed.
  Mauro is CC'ed and I'd ask of course for this (I kinda did) but who
  decides what I suggested is a good idea? I personally obviously think
  it
  is ;) and even more so if dvb-apps are unmaintained.
 
  I guess the question now becomes 'who okay's this change? Who says
  'okay, lets do it this way. Once that is answered we can go from there
  ;)
 
  If I understood it right, you want to split the scan files into a
  separate
  git tree and maintain it, right?
 
  I'm ok with that.
 
  Regards,
  Mauro

 As a DVB maintainer, I am OK with this as well - It does indeed make
 sense to separate the c code sources from the regional frequency
 tables, and I'm sure we'll see much benefit from this change.

 Done. I created a tree for Oliver to maintain it and an account for him.
 I also created a new tree with just the DVB table commits to:
   http://git.linuxtv.org/dtv-scan-tables.git

 I kept there both szap and scan files, although maybe it makes sense to
 drop the szap table (channels-conf dir). It also makes sense to drop the
 tables from the dvb-apps tree, to avoid duplicated stuff, and to avoid

Being one of the maintainers:

I will keep the tables in the dvb-apps tree for the time being. Will decide to
drop the config files as needed from dvb-apps. It is necessary to keep a
copy of the config files for development purposes, rather than pulling from
different trees.


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


Re: [RFC] Initial scan files troubles and brainstorming

2013-01-10 Thread Manu Abraham
On 1/11/13, Jiri Slaby jirisl...@gmail.com wrote:
 On 01/10/2013 06:40 PM, Manu Abraham wrote:
 On 1/9/13, Mauro Carvalho Chehab mche...@redhat.com wrote:
 Em Wed, 9 Jan 2013 06:08:44 -0500
 Michael Krufky mkru...@linuxtv.org escreveu:

 On Wed, Jan 9, 2013 at 5:41 AM, Mauro Carvalho Chehab
 mche...@redhat.com wrote:
 Em Wed, 09 Jan 2013 10:43:23 +0100
 Oliver Schinagl oliver+l...@schinagl.nl escreveu:

 On 08-01-13 21:01, Johannes Stezenbach wrote:
 On Mon, Jan 07, 2013 at 01:48:29PM +0100, Oliver Schinagl wrote:
 On 07-01-13 11:46, Jiri Slaby wrote:
 On 12/18/2012 11:01 PM, Oliver Schinagl wrote:
 Unfortunatly, I have had zero replies.
 Hmm, it's sad there is a silence in this thread from linux-media
 guys :/.
 In their defense, they are very very busy people ;) chatter on this
 thread does bring it up however.
 This is such a nice thing to say :-)
 But it might be that Mauro thinks the dvb-apps maintainer should
 respond, but apparently there is no dvb-apps maintainer...
 Maybe you should ask Mauro directly to create an account for you
 to implement what you proposed.
 Mauro is CC'ed and I'd ask of course for this (I kinda did) but who
 decides what I suggested is a good idea? I personally obviously think
 it
 is ;) and even more so if dvb-apps are unmaintained.

 I guess the question now becomes 'who okay's this change? Who says
 'okay, lets do it this way. Once that is answered we can go from
 there
 ;)

 If I understood it right, you want to split the scan files into a
 separate
 git tree and maintain it, right?

 I'm ok with that.

 Regards,
 Mauro

 As a DVB maintainer, I am OK with this as well - It does indeed make
 sense to separate the c code sources from the regional frequency
 tables, and I'm sure we'll see much benefit from this change.

 Done. I created a tree for Oliver to maintain it and an account for him.
 I also created a new tree with just the DVB table commits to:
 http://git.linuxtv.org/dtv-scan-tables.git

 I kept there both szap and scan files, although maybe it makes sense to
 drop the szap table (channels-conf dir). It also makes sense to drop the
 tables from the dvb-apps tree, to avoid duplicated stuff, and to avoid

 Being one of the maintainers:

 I will keep the tables in the dvb-apps tree for the time being.

 That does not make sense at all -- why? Duplicated stuff always hurts.


The scan files and config files are very specific to dvb-apps, some
applications
do rely on these config files. It doesn't really make sense to have
split out config
files for these  small applications.



 Will decide to
 drop the config files as needed from dvb-apps. It is necessary to keep a
 copy of the config files for development purposes, rather than pulling
 from
 different trees.

 What development purposes, could you be more specific? You can still use
 git submodules if really needed. But as it stands I do not see a reason
 for that at all...


Did you think that the dvb-apps just came out of thin air ?

development of dvb-applications, implies eventually config files also
will be updated as necessary. Having them in separate repositories
makes such work harder for working.
while working with dvb-apps, it would make things saner if it is the
same SCM, rather
than having different SCM's. So according to you, you want to make it
still harder for someone to work with dvb-apps.


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


Re: [RFC] Initial scan files troubles and brainstorming

2013-01-10 Thread Manu Abraham
On 1/11/13, Michael Krufky mkru...@linuxtv.org wrote:
 On Thu, Jan 10, 2013 at 1:46 PM, Manu Abraham abraham.m...@gmail.com
 wrote:
 On 1/11/13, Jiri Slaby jirisl...@gmail.com wrote:
 On 01/10/2013 06:40 PM, Manu Abraham wrote:
 On 1/9/13, Mauro Carvalho Chehab mche...@redhat.com wrote:
 Em Wed, 9 Jan 2013 06:08:44 -0500
 Michael Krufky mkru...@linuxtv.org escreveu:

 On Wed, Jan 9, 2013 at 5:41 AM, Mauro Carvalho Chehab
 mche...@redhat.com wrote:
 Em Wed, 09 Jan 2013 10:43:23 +0100
 Oliver Schinagl oliver+l...@schinagl.nl escreveu:

 On 08-01-13 21:01, Johannes Stezenbach wrote:
 On Mon, Jan 07, 2013 at 01:48:29PM +0100, Oliver Schinagl wrote:
 On 07-01-13 11:46, Jiri Slaby wrote:
 On 12/18/2012 11:01 PM, Oliver Schinagl wrote:
 Unfortunatly, I have had zero replies.
 Hmm, it's sad there is a silence in this thread from linux-media
 guys :/.
 In their defense, they are very very busy people ;) chatter on
 this
 thread does bring it up however.
 This is such a nice thing to say :-)
 But it might be that Mauro thinks the dvb-apps maintainer should
 respond, but apparently there is no dvb-apps maintainer...
 Maybe you should ask Mauro directly to create an account for you
 to implement what you proposed.
 Mauro is CC'ed and I'd ask of course for this (I kinda did) but who
 decides what I suggested is a good idea? I personally obviously
 think
 it
 is ;) and even more so if dvb-apps are unmaintained.

 I guess the question now becomes 'who okay's this change? Who says
 'okay, lets do it this way. Once that is answered we can go from
 there
 ;)

 If I understood it right, you want to split the scan files into a
 separate
 git tree and maintain it, right?

 I'm ok with that.

 Regards,
 Mauro

 As a DVB maintainer, I am OK with this as well - It does indeed make
 sense to separate the c code sources from the regional frequency
 tables, and I'm sure we'll see much benefit from this change.

 Done. I created a tree for Oliver to maintain it and an account for
 him.
 I also created a new tree with just the DVB table commits to:
 http://git.linuxtv.org/dtv-scan-tables.git

 I kept there both szap and scan files, although maybe it makes sense
 to
 drop the szap table (channels-conf dir). It also makes sense to drop
 the
 tables from the dvb-apps tree, to avoid duplicated stuff, and to avoid

 Being one of the maintainers:

 I will keep the tables in the dvb-apps tree for the time being.

 That does not make sense at all -- why? Duplicated stuff always hurts.


 The scan files and config files are very specific to dvb-apps, some
 applications
 do rely on these config files. It doesn't really make sense to have
 split out config
 files for these  small applications.



 Will decide to
 drop the config files as needed from dvb-apps. It is necessary to keep
 a
 copy of the config files for development purposes, rather than pulling
 from
 different trees.

 What development purposes, could you be more specific? You can still use
 git submodules if really needed. But as it stands I do not see a reason
 for that at all...


 Did you think that the dvb-apps just came out of thin air ?

 development of dvb-applications, implies eventually config files also
 will be updated as necessary. Having them in separate repositories
 makes such work harder for working.
 while working with dvb-apps, it would make things saner if it is the
 same SCM, rather
 than having different SCM's. So according to you, you want to make it
 still harder for someone to work with dvb-apps.


 Manu

 Manu,

 I see great value in separating the history of the data files from the
 code files.  If you really think this is such a terrible task for a
 developer to have to pull from a second repository to fetch these data
 files, then I find no reason why we couldn't script it such that
 building the dvb-apps package would trigger the pull from the
 additional repository.

 I think that's a fair compromise.


 As someone who has long been working with dvb-apps, I see no value
in this, but just pain altogether. For people who have never worked with it,
they can say anything what they want, which makes no sense at all.


 Meanwhile, your argument is for developers.  Developers can handle
 pulling from a separated tree for data files who shouldn't be clouding
 the history of source code development, anyway.  Developers are indeed
 used to dealing with multiple repositories, and if any developer
 isn't, then now is the time to get with the program!


It isn't that way. Users have to deal with 2 repositories as well. Anyway,
the repository is not having that many developers to state that developers
can handle all the burden. It is just but the reverse.

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


Re: [RFC] Initial scan files troubles and brainstorming

2013-01-10 Thread Manu Abraham
On 1/11/13, Jiri Slaby jirisl...@gmail.com wrote:
 On 01/10/2013 07:46 PM, Manu Abraham wrote:
 The scan files and config files are very specific to dvb-apps, some
 applications
 do rely on these config files. It doesn't really make sense to have
 split out config
 files for these  small applications.

 I don't care where they are, really. However I'm strongly against
 duplicating them. Feel free to remove the newly created repository, I'll
 be fine with that.

I haven't duplicated anything at all. It is Mauro who has duplicated stuff,
by creating a new tree altogether.

if you need the scan files to be properly maintained then you need to
handle it in the same repository altogether. Not by separating out the
configuration files of a few applications.

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


Re: [RFC] Initial scan files troubles and brainstorming

2013-01-10 Thread Manu Abraham
On 1/11/13, Jiri Slaby jirisl...@gmail.com wrote:
 On 01/10/2013 08:08 PM, Manu Abraham wrote:
 On 1/11/13, Jiri Slaby jirisl...@gmail.com wrote:
 On 01/10/2013 07:46 PM, Manu Abraham wrote:
 The scan files and config files are very specific to dvb-apps, some
 applications
 do rely on these config files. It doesn't really make sense to have
 split out config
 files for these  small applications.

 I don't care where they are, really. However I'm strongly against
 duplicating them. Feel free to remove the newly created repository, I'll
 be fine with that.

 I haven't duplicated anything at all. It is Mauro who has duplicated
 stuff,
 by creating a new tree altogether.

 I didn't accuse you. This was a general comment to everybody. Whatever
 the consensus is at the end, do not duplicate the data.

Eventually what will happen is that, as applications do get developed,
the config files which are alongwith the applications will have proper
compatibility with the applications while, the split out config files will
be in a different state, providing nothing but pain for everyone.

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


Re: [RFC] Initial scan files troubles and brainstorming

2013-01-10 Thread Manu Abraham
On 1/11/13, Mauro Carvalho Chehab mche...@redhat.com wrote:
 Em Fri, 11 Jan 2013 00:38:18 +0530
 Manu Abraham abraham.m...@gmail.com escreveu:

 On 1/11/13, Jiri Slaby jirisl...@gmail.com wrote:
  On 01/10/2013 07:46 PM, Manu Abraham wrote:
  The scan files and config files are very specific to dvb-apps, some
  applications
  do rely on these config files. It doesn't really make sense to have
  split out config
  files for these  small applications.
 
  I don't care where they are, really. However I'm strongly against
  duplicating them. Feel free to remove the newly created repository,
  I'll
  be fine with that.

 I haven't duplicated anything at all. It is Mauro who has duplicated
 stuff,
 by creating a new tree altogether.

 I only did it by request, and after having some consensus at the ML, and
 after people explicitly asking me to do that.


Having consensus implies that the people involved with it are in that loop,
rather than having a superfluous one with no one of it in that loop.

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


Re: [RFC] Initial scan files troubles and brainstorming

2013-01-10 Thread Manu Abraham
On 1/11/13, Oliver Schinagl oliver+l...@schinagl.nl wrote:
 they can say anything what they want, which makes no sense at all.
 Well there are a few apps that do use the initial scanfile tree, but do
 not use any of the dvb-apps.

 (tvheadend, kaffeine appearantly, i'm guessing VDR and MythTV aswell?)

Only tvheadend and kaffeine AFAIK. VDR and MythTV have their own formats.




 Meanwhile, your argument is for developers.  Developers can handle
 pulling from a separated tree for data files who shouldn't be clouding
 the history of source code development, anyway.  Developers are indeed
 used to dealing with multiple repositories, and if any developer
 isn't, then now is the time to get with the program!


 It isn't that way. Users have to deal with 2 repositories as well.
 Anyway,
 the repository is not having that many developers to state that
 developers
 can handle all the burden. It is just but the reverse.
 Well one of the biggest issues was, that the scanfiles where ill
 maintained and projects where working around those shortcommings.

 The scanfiles are technically unrelated. They are data files, facts and
 can very logically live seperated :) Having commit messages pure for
 data files in a source tree just looks off.


The configuration files/data for dvb-apps.


 They simply have become a seperate entity as people (not developers)
 depend on them. (Yes there is wscan of course).

 Also, purely out of curiousity, how are the scanfiles used during
 development?

The scanfiles what you call them are the configuration files for dvb-apps,
rather than purely data files.

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


Re: [RFC] Initial scan files troubles and brainstorming

2013-01-10 Thread Manu Abraham
On 1/11/13, Mauro Carvalho Chehab mche...@redhat.com wrote:
 Em Fri, 11 Jan 2013 00:38:18 +0530
 Manu Abraham abraham.m...@gmail.com escreveu:

 On 1/11/13, Jiri Slaby jirisl...@gmail.com wrote:
  On 01/10/2013 07:46 PM, Manu Abraham wrote:
  The scan files and config files are very specific to dvb-apps, some
  applications
  do rely on these config files. It doesn't really make sense to have
  split out config
  files for these  small applications.
 
  I don't care where they are, really. However I'm strongly against
  duplicating them. Feel free to remove the newly created repository,
  I'll
  be fine with that.

 I haven't duplicated anything at all. It is Mauro who has duplicated
 stuff,
 by creating a new tree altogether.

 I only did it by request, and after having some consensus at the ML, and
 after people explicitly asking me to do that.

 I even tried to not express my opinion to anybody. But it seems I'm
 forced by you to give it. So, let it be.

 The last patches from you there were 11 months ago, and didn't bring any
 new functionality there... they are just indentation fixes:
   http://www.linuxtv.org/hg/dvb-apps/


The way you do things, it all ends up like this.

https://lkml.org/lkml/2012/12/23/75


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


Re: [RFC] Initial scan files troubles and brainstorming

2013-01-10 Thread Manu Abraham
On 1/11/13, Jiri Slaby jirisl...@gmail.com wrote:
 On 01/10/2013 09:25 PM, Manu Abraham wrote:
 Also, purely out of curiousity, how are the scanfiles used during
 development?

 The scanfiles what you call them are the configuration files for
 dvb-apps,
 rather than purely data files.

 But you cannot change their format, so what's the point? You can use
 them from a different directory or system ones...

The format can be definitely changed. There's no issue to it.

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


Re: [RFC] Initial scan files troubles and brainstorming

2013-01-10 Thread Manu Abraham
On 1/11/13, Mauro Carvalho Chehab mche...@redhat.com wrote:
 Em Fri, 11 Jan 2013 01:55:34 +0530
 Manu Abraham abraham.m...@gmail.com escreveu:

 On 1/11/13, Oliver Schinagl oliver+l...@schinagl.nl wrote:
  they can say anything what they want, which makes no sense at all.
  Well there are a few apps that do use the initial scanfile tree, but do
  not use any of the dvb-apps.
 
  (tvheadend, kaffeine appearantly, i'm guessing VDR and MythTV aswell?)

 Only tvheadend and kaffeine AFAIK. VDR and MythTV have their own formats.

 Both mplayer and vlc work with the channels-conf files.

True. they depend upon the output from dvbscan. So when scan changes format,
they will also need to update formats to acquire new functionality, else they
will be stuck with old functionality.

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


Re: [RFC] Initial scan files troubles and brainstorming

2013-01-10 Thread Manu Abraham
On 1/11/13, Jiri Slaby jirisl...@gmail.com wrote:
 On 01/10/2013 09:38 PM, Manu Abraham wrote:
 The format can be definitely changed. There's no issue to it.

 No you cannot. Applications depend on that, it's part of the dvb ABI. If
 you changed that, you would do the same mistake as Mauro let it flowing
 through his tree and it was pointed out by Linus in the link you sent...

I understand what you are thinking, but that's not exactly about it. The format
can simply be updated by adding newer params to it's end, thus not breaking
any of the applications.

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


Re: [RFC] Initial scan files troubles and brainstorming

2013-01-10 Thread Manu Abraham
On 1/11/13, Oliver Schinagl oliver+l...@schinagl.nl wrote:
 On 01/10/13 21:32, Manu Abraham wrote:
 On 1/11/13, Mauro Carvalho Chehab mche...@redhat.com wrote:
 Em Fri, 11 Jan 2013 00:38:18 +0530
 Manu Abraham abraham.m...@gmail.com escreveu:

 On 1/11/13, Jiri Slaby jirisl...@gmail.com wrote:
 On 01/10/2013 07:46 PM, Manu Abraham wrote:
 The scan files and config files are very specific to dvb-apps, some
 applications
 do rely on these config files. It doesn't really make sense to have
 split out config
 files for these  small applications.

 I don't care where they are, really. However I'm strongly against
 duplicating them. Feel free to remove the newly created repository,
 I'll
 be fine with that.

 I haven't duplicated anything at all. It is Mauro who has duplicated
 stuff,
 by creating a new tree altogether.

 I only did it by request, and after having some consensus at the ML, and
 after people explicitly asking me to do that.

 I even tried to not express my opinion to anybody. But it seems I'm
 forced by you to give it. So, let it be.

 The last patches from you there were 11 months ago, and didn't bring any
 new functionality there... they are just indentation fixes:
 http://www.linuxtv.org/hg/dvb-apps/


 The way you do things, it all ends up like this.

 https://lkml.org/lkml/2012/12/23/75
 That's just mean and below the belt.

 Anyway, I've brought this issue up on the 18th of oktober 2012 on this
 mailing list. I had zero replies until early december. Jonathan
 commented a little and said it was a good idea.

 Also a few comments about how their patches to scanfiles (data files,
 facts) where ignored for weeks to an end.



There was someone who was actively maintaining the config files.
One cannot simply state something different unless that person has to say
something. In this case as soon as Christoph talked about his stand,
I did express my opinion as well.



 Mauro didn't get involved to have everybody that is a maintainer etc get
 a good chance to respond.


Mauro doesn't do anything wrt dvb-apps. I don't understand, what you
are trying to state here.


 The only thing that came from this, is that someone actually stopped
 maintaining it.

 Then after everything actually was done (for the better imo), you come
 in and say it's a bad thing, but dont' really tell us why. Other than it
 makes development hard for you, which nobody really agree's to with.

At least you should have the courtesy to talk about it with the people
who are/were working with it, rather than the people who have no
connection to it.

I don't want to let go of the efforts that you would like to put into, and
hence stated that it would be appreciated if you would maintain the
config files within the dvb-apps tree.

Just like how you think it is bad for the applications to carry it's own
configuration files, I think that it is better for any application to carry
it's own configuration files.

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


Re: [RFC] Initial scan files troubles and brainstorming

2013-01-10 Thread Manu Abraham
On 1/11/13, Jiri Slaby jirisl...@gmail.com wrote:
 On 01/10/2013 09:49 PM, Manu Abraham wrote:
 On 1/11/13, Jiri Slaby jirisl...@gmail.com wrote:
 On 01/10/2013 09:38 PM, Manu Abraham wrote:
 The format can be definitely changed. There's no issue to it.

 No you cannot. Applications depend on that, it's part of the dvb ABI. If
 you changed that, you would do the same mistake as Mauro let it flowing
 through his tree and it was pointed out by Linus in the link you sent...

 I understand what you are thinking, but that's not exactly about it. The
 format
 can simply be updated by adding newer params to it's end, thus not
 breaking
 any of the applications.

 OK, but that still does not explain why it is requisite to have the data
 along with the sources. There is no problem in updating both the files
 and scandata separately, because it has to be compatible.


scenario1:

clone tree 1
make changes
update tree 1

scenario2:

clone tree 1
make changes
update tree 1

clone tree 2
make changes
update tree 2

It seems to me that scenario 2 is twice the work, to keep it updated. :-)
Simply no reason to do double the work.


 Also I'm not sure whether adding a column at the end wouldn't break the
 apps.


Don't worry. We have already done that in the past.

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


Re: [RFC] Initial scan files troubles and brainstorming

2013-01-07 Thread Manu Abraham
On Mon, Jan 7, 2013 at 6:23 PM, Christoph Pfister
christophpfis...@gmail.com wrote:
 Okay guys, I think this is a good time to discuss scan file
 maintenance [ should have taken care of it earlier, but well ...].

 I've been updating the scan data for the past few years, but found
 barely no time in the last (many!) months. This won't change in
 future, so I've decided to step down from the task; may others do what
 is necessary ...

Christoph, It's unfortunate that you decided to drop the ball.
I will try to take care of it in the meanwhile..

Regards,
Manu
--
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: Status of the patches under review at LMML (35 patches)

2013-01-07 Thread Manu Abraham
On Sun, Jan 6, 2013 at 7:04 PM, Mauro Carvalho Chehab
mche...@redhat.com wrote:
 This is the summary of the patches that are currently under review at
 Linux Media Mailing List linux-media@vger.kernel.org.
 Each patch is represented by its submission date, the subject (up to 70
 chars) and the patchwork link (if submitted via email).

 P.S.: This email is c/c to the developers where some action is expected.
   If you were copied, please review the patches, acking/nacking or
   submitting an update.


 == New patches ==

 Those patches require some review from the community:

 This one could break again DVB-S-DVB-S2 support, so, it needs to be
 carefully reviewed and tested:

 Jun,21 2012: [media] dvb frontend core: tuning in ISDB-T using DVB API v3 
   http://patchwork.linuxtv.org/patch/12988  Olivier Grenie 
 olivier.gre...@parrot.com

 This one fix a code that, IMHO, should, instead be replaced by
 something better:
 Sep,17 2012: [3/3] cx25821: Cleanup filename assignment code  
   http://patchwork.linuxtv.org/patch/14445  Peter Senna Tschudin 
 peter.se...@gmail.com

 This one doesn't seem right for me. Anybody can test/work with it?
 Sep, 2 2012: fix: iMon Knob event interpretation issues   
   http://patchwork.linuxtv.org/patch/16030  Alexandre Lissy 
 alexandreli...@free.fr

 I'm not sure if we should apply this one or not, as it will increase
 the probability of miss-interpreting a nec IR protocol. Comments?
 Jul,26 2012: media: rc: Add support to decode Remotes using NECx IR protocol  
   http://patchwork.linuxtv.org/patch/13480  Ravi Kumar V 
 kumar...@codeaurora.org


 == Manu Abraham abraham.m...@gmail.com ==

 Those patches are there for a long time. I think I'll simply apply all of
 them, if they're not reviewed on the next couple weeks:

 Mar,11 2012: [2/3] stv090x: use error counter 1 for BER estimation
   http://patchwork.linuxtv.org/patch/10301  Andreas Regel 
 andreas.re...@gmx.de
 Mar,11 2012: [3/3] stv090x: On STV0903 do not set registers of the second 
 path. http://patchwork.linuxtv.org/patch/10302  Andreas Regel 
 andreas.re...@gmx.de
 Nov,29 2011: stv090x: implement function for reading uncorrected blocks count 
   http://patchwork.linuxtv.org/patch/8656   Mariusz Bia?o?czyk 
 ma...@skyboo.net
 Jun, 8 2011: Add remote control support for mantis
   http://patchwork.linuxtv.org/patch/7217   Christoph Pinkl 
 christoph.pi...@gmail.com
 Apr, 1 2012: [05/11] Slightly more friendly debugging output. 
   http://patchwork.linuxtv.org/patch/10520  Steinar H. Gunderson 
 se...@samfundet.no
 Apr, 1 2012: [06/11] Replace ca_lock by a slightly more general 
 int_stat_lock.  http://patchwork.linuxtv.org/patch/10521  Steinar H. 
 Gunderson se...@samfundet.no
 Apr, 1 2012: [07/11] Fix a ton of SMP-unsafe accesses.
   http://patchwork.linuxtv.org/patch/10523  Steinar H. Gunderson 
 se...@samfundet.no
 Apr, 1 2012: [08/11] Remove some unused structure members.
   http://patchwork.linuxtv.org/patch/10525  Steinar H. Gunderson 
 se...@samfundet.no
 Apr, 1 2012: [09/11] Correct wait_event_timeout error return check.   
   http://patchwork.linuxtv.org/patch/10526  Steinar H. Gunderson 
 se...@samfundet.no
 Apr, 1 2012: [10/11] Ignore timeouts waiting for the IRQ0 flag.   
   http://patchwork.linuxtv.org/patch/10527  Steinar H. Gunderson 
 se...@samfundet.no
 Apr, 1 2012: [11/11] Enable Mantis CA support.
   http://patchwork.linuxtv.org/patch/10524  Steinar H. Gunderson 
 se...@samfundet.no


Somehow, these patches missed me. This weekend, I am traveling.
I will take a look at it during the weekend after that one.

Regards,
Manu
--
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 RFCv3] dvb: Add DVBv5 properties for quality parameters

2013-01-03 Thread Manu Abraham
Hi Antti,

On Thu, Jan 3, 2013 at 9:04 PM, Antti Palosaari cr...@iki.fi wrote:
 On 01/01/2013 06:48 PM, Manu Abraham wrote:

 On Tue, Jan 1, 2013 at 8:30 PM, Mauro Carvalho Chehab
 mche...@redhat.com wrote:

 [RFCv4] dvb: Add DVBv5 properties for quality parameters

 The DVBv3 quality parameters are limited on several ways:
  - Doesn't provide any way to indicate the used measure;
  - Userspace need to guess how to calculate the measure;
  - Only a limited set of stats are supported;
  - Doesn't provide QoS measure for the OFDM TPS/TMCC
carriers, used to detect the network parameters for
DVB-T/ISDB-T;
  - Can't be called in a way to require them to be filled
all at once (atomic reads from the hardware), with may
cause troubles on interpreting them on userspace;
  - On some OFDM delivery systems, the carriers can be
independently modulated, having different properties.
Currently, there's no way to report per-layer stats;


 per layer stats is a mythical bird, nothing of that sort does exist. If
 some
 driver states that it is simply due to lack of knowledge at the coding
 side.

 ISDB-T uses hierarchial modulation, just like DVB-S2 or DVB-T2


 Manu, you confused now two concept (which are aimed to resolve same real
 life problem) - hierarchical coding and multiple transport stream. Both are
 quite similar on lower level of radio channel, but differs on upper levels.

 Hierarchical is a little bit weird baby as it remuxes those lower lever
 radio channels (called layers in case of ISDB-T) to one single mux!

That is not really correct. There is one single OFDM channel, the layers
are processed via hierarchial separation. Stuffing exists, to maintain
constant rate.

http://farm9.staticflickr.com/8077/8343296328_e1e375b519_b_d.jpg

When rate is constant within the same channel..
(The only case what I can think parameters could be different with a
constant rate,
is that stuffing frames are unaccounted for. Most likely a bug ?)

Manu
--
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 RFCv3] dvb: Add DVBv5 properties for quality parameters

2013-01-03 Thread Manu Abraham
On Fri, Jan 4, 2013 at 12:57 AM, Mauro Carvalho Chehab
mche...@redhat.com wrote:
 Em Fri, 4 Jan 2013 00:39:25 +0530
 Manu Abraham abraham.m...@gmail.com escreveu:

 Hi Antti,

 On Thu, Jan 3, 2013 at 9:04 PM, Antti Palosaari cr...@iki.fi wrote:
  On 01/01/2013 06:48 PM, Manu Abraham wrote:
 
  On Tue, Jan 1, 2013 at 8:30 PM, Mauro Carvalho Chehab
  mche...@redhat.com wrote:
 
  [RFCv4] dvb: Add DVBv5 properties for quality parameters
 
  The DVBv3 quality parameters are limited on several ways:
   - Doesn't provide any way to indicate the used measure;
   - Userspace need to guess how to calculate the measure;
   - Only a limited set of stats are supported;
   - Doesn't provide QoS measure for the OFDM TPS/TMCC
 carriers, used to detect the network parameters for
 DVB-T/ISDB-T;
   - Can't be called in a way to require them to be filled
 all at once (atomic reads from the hardware), with may
 cause troubles on interpreting them on userspace;
   - On some OFDM delivery systems, the carriers can be
 independently modulated, having different properties.
 Currently, there's no way to report per-layer stats;
 
 
  per layer stats is a mythical bird, nothing of that sort does exist. If
  some
  driver states that it is simply due to lack of knowledge at the coding
  side.
 
  ISDB-T uses hierarchial modulation, just like DVB-S2 or DVB-T2
 
 
  Manu, you confused now two concept (which are aimed to resolve same real
  life problem) - hierarchical coding and multiple transport stream. Both are
  quite similar on lower level of radio channel, but differs on upper levels.
 
  Hierarchical is a little bit weird baby as it remuxes those lower lever
  radio channels (called layers in case of ISDB-T) to one single mux!

 That is not really correct. There is one single OFDM channel, the layers
 are processed via hierarchial separation. Stuffing exists, to maintain
 constant rate.

 http://farm9.staticflickr.com/8077/8343296328_e1e375b519_b_d.jpg

 When rate is constant within the same channel..
 (The only case what I can think parameters could be different with a
 constant rate,
 is that stuffing frames are unaccounted for. Most likely a bug ?)

 What did you smoke? That picture has nothing to do with ISDB!


ARIB STD – B31
Version 1.6-E2
-17-
Fig. 3-2 shows the basic configuration of the channel coding.

It just shows, you understand crap.

Manu
--
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 RFCv3] dvb: Add DVBv5 properties for quality parameters

2013-01-03 Thread Manu Abraham
On Thu, Jan 3, 2013 at 6:50 PM, Mauro Carvalho Chehab
mche...@redhat.com wrote:
 Em Wed, 2 Jan 2013 00:38:50 +0530
 Manu Abraham abraham.m...@gmail.com escreveu:

 On Tue, Jan 1, 2013 at 10:59 PM, Mauro Carvalho Chehab
 mche...@redhat.com wrote:
  Em Tue, 1 Jan 2013 22:18:49 +0530
  Manu Abraham abraham.m...@gmail.com escreveu:
 
  On Tue, Jan 1, 2013 at 8:30 PM, Mauro Carvalho Chehab
  mche...@redhat.com wrote:
 
   [RFCv4] dvb: Add DVBv5 properties for quality parameters
  
   The DVBv3 quality parameters are limited on several ways:
   - Doesn't provide any way to indicate the used measure;
   - Userspace need to guess how to calculate the measure;
   - Only a limited set of stats are supported;
   - Doesn't provide QoS measure for the OFDM TPS/TMCC
 carriers, used to detect the network parameters for
 DVB-T/ISDB-T;
   - Can't be called in a way to require them to be filled
 all at once (atomic reads from the hardware), with may
 cause troubles on interpreting them on userspace;
   - On some OFDM delivery systems, the carriers can be
 independently modulated, having different properties.
 Currently, there's no way to report per-layer stats;
 
  per layer stats is a mythical bird, nothing of that sort does exist.
 
  Had you ever read or tried to get stats from an ISDB-T demod? If you
  had, you would see that it only provides per-layer stats. Btw, this is
  a requirement to follow the ARIB and ABNT ISDB specs.

 I understand you keep writing junk for ages, but nevertheless:

 Do you have any idea what's a BBHEADER (DVB-S2) or
 PLHEADER (DVB-T2) ? The headers do indicate what MODCOD
 (aka Modulation/Coding Standard follows, whatever mode ACM,
 VCM or CCM) follows. These MODCOD foolows a TDM approach
 with a hierarchial modulation principle. This is exactly what ISDB
 does too.

 No, I didn't check DVB-S2/T2 specs deeply enough to understand
 if they're doing the same thing as ISDB.

 Yet, ISDB-T doesn't use a TDM approach for hierarchical modulation.
 It uses a FDM (OFDM is a type of Frequency Division Multiplexing).

• ISDB‐T uses a modulation method referred to as Band
Segmented OFDM Transmission with Time Interleave.

Definition: Time Division Multiplexing (TDM) is the time interleaving of
samples from several sources so that the information from these sources
can be transmitted serially over a single communication channel.

Manu
--
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 RFCv3] dvb: Add DVBv5 properties for quality parameters

2013-01-03 Thread Manu Abraham
On Fri, Jan 4, 2013 at 2:09 AM, Antti Palosaari cr...@iki.fi wrote:


 Manu, here is manual of the professional ISDB-T signal analyzer. Look
 especially BER measurement picture from Slide 10.

Sure, it looks so. Just wondering what the TDM stuffing would do after
the hierarchial combiner.

Manu
--
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: [linux-media] Re: [PATCH RFCv3] dvb: Add DVBv5 properties for quality parameters

2013-01-03 Thread Manu Abraham
On Fri, Jan 4, 2013 at 10:33 AM, VDR User user@gmail.com wrote:
 On Thu, Jan 3, 2013 at 1:33 PM, Antti Palosaari cr...@iki.fi wrote:
 I would not like to define exact units for BER and USB as those are quite
 hard to implement and also non-sense. User would like just to see if there
 is some (random) numbers and if those numbers are rising or reducing when he
 changes antenna or adjusts gain. We are not making a professional signal
 analyzers - numbers does not need to be 100% correctly.

 Just a small comment here. Since this may finally be done, why not do
 it the best way? In the end I think that's better and I don't see any
 harm in having the capability to make a pro-grade signal analyzer.
 After years of waiting, I don't think half-assing is a good idea.

The problem is not in creating an API for such a thing. The problem arises
from the fact that all devices need to worked to comply to the API. It might
not factually possible to do that, since most drivers are reverse engineered
or written in a crude way.. In a lot many cases, there are not even the right
documents to do that. An API alone doesn't solve anything at all. Here we
are talking about making pro grade software based on home grade silicon,
for which most don't have proper documentation.

Manu
--
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 RFCv3] dvb: Add DVBv5 properties for quality parameters

2013-01-01 Thread Manu Abraham
On Tue, Jan 1, 2013 at 8:30 PM, Mauro Carvalho Chehab
mche...@redhat.com wrote:

 [RFCv4] dvb: Add DVBv5 properties for quality parameters

 The DVBv3 quality parameters are limited on several ways:
 - Doesn't provide any way to indicate the used measure;
 - Userspace need to guess how to calculate the measure;
 - Only a limited set of stats are supported;
 - Doesn't provide QoS measure for the OFDM TPS/TMCC
   carriers, used to detect the network parameters for
   DVB-T/ISDB-T;
 - Can't be called in a way to require them to be filled
   all at once (atomic reads from the hardware), with may
   cause troubles on interpreting them on userspace;
 - On some OFDM delivery systems, the carriers can be
   independently modulated, having different properties.
   Currently, there's no way to report per-layer stats;

per layer stats is a mythical bird, nothing of that sort does exist. If some
driver states that it is simply due to lack of knowledge at the coding side.

ISDB-T uses hierarchial modulation, just like DVB-S2 or DVB-T2

Once the Outer code is decoded, the OFDM segments are separated
using Hierarchial separation. This is well described by NHK.


To improve mobile reception and robustness to multipath
interference, the system performs, in symbol units, time
interleaving plus frequency interleaving according to the
arrangement of OFDM segments. Pilot signals for
demodulation and control symbols consisting of TMCC
information are combined with information symbols to an
OFDM frame. Here, information symbols are modulated
by Differential Binary Phase Shift Keying (DBPSK) and
guard intervals are added at the IFFT output.

[3] Hierarchical transmission
A mixture of fixed-reception programs and mobile reception
programs in the transmission system is made
possible through the application of hierarchical
transmission achieved by band division within a channel.
Hierarchical transmission means that the three elements
of channel coding, namely, the modulation system, the
coding rate of convolutional correction code, and the time
interleave length, can be independently set. Time and
frequency interleaving are each performed in their
respective hierarchical data segment.
As described earlier, the smallest hierarchical unit in a
frequency spectrum is one OFDM segment.


Please don't muck up existing working things with uber crap.

Manu
--
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 RFCv3] dvb: Add DVBv5 properties for quality parameters

2013-01-01 Thread Manu Abraham
On Tue, Jan 1, 2013 at 10:59 PM, Mauro Carvalho Chehab
mche...@redhat.com wrote:
 Em Tue, 1 Jan 2013 22:18:49 +0530
 Manu Abraham abraham.m...@gmail.com escreveu:

 On Tue, Jan 1, 2013 at 8:30 PM, Mauro Carvalho Chehab
 mche...@redhat.com wrote:

  [RFCv4] dvb: Add DVBv5 properties for quality parameters
 
  The DVBv3 quality parameters are limited on several ways:
  - Doesn't provide any way to indicate the used measure;
  - Userspace need to guess how to calculate the measure;
  - Only a limited set of stats are supported;
  - Doesn't provide QoS measure for the OFDM TPS/TMCC
carriers, used to detect the network parameters for
DVB-T/ISDB-T;
  - Can't be called in a way to require them to be filled
all at once (atomic reads from the hardware), with may
cause troubles on interpreting them on userspace;
  - On some OFDM delivery systems, the carriers can be
independently modulated, having different properties.
Currently, there's no way to report per-layer stats;

 per layer stats is a mythical bird, nothing of that sort does exist.

 Had you ever read or tried to get stats from an ISDB-T demod? If you
 had, you would see that it only provides per-layer stats. Btw, this is
 a requirement to follow the ARIB and ABNT ISDB specs.

I understand you keep writing junk for ages, but nevertheless:

Do you have any idea what's a BBHEADER (DVB-S2) or
PLHEADER (DVB-T2) ? The headers do indicate what MODCOD
(aka Modulation/Coding Standard follows, whatever mode ACM,
VCM or CCM) follows. These MODCOD foolows a TDM approach
with a hierarchial modulation principle. This is exactly what ISDB
does too.

And for your info:

 The TMCC control information is
common to all TMCC carriers and
error correction is performed by using
difference-set cyclic code.

Manu
--
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: [GIT PULL] Disintegrate UAPI for media

2012-10-11 Thread Manu Abraham
On Thu, Oct 11, 2012 at 1:53 PM, Oliver Endriss o.endr...@gmx.de wrote:
 Mauro Carvalho Chehab mche...@infradead.org wrote:
 Em Tue, 09 Oct 2012 14:30:24 +0100
 David Howells dhowe...@redhat.com escreveu:

  Can you merge the following branch into the media tree please.
 
  This is to complete part of the Userspace API (UAPI) disintegration for 
  which
  the preparatory patches were pulled recently.  After these patches, 
  userspace
  headers will be segregated into:
 
  include/uapi/linux/.../foo.h
 
  for the userspace interface stuff, and:
 
  include/linux/.../foo.h
 
  for the strictly kernel internal stuff.
 
  ---
  The following changes since commit 
  9e2d8656f5e8aa214e66b462680cf86b210b74a8:
 
Merge branch 'akpm' (Andrew's patch-bomb) (2012-10-09 16:23:15 +0900)
 
  are available in the git repository at:
 
 
git://git.infradead.org/users/dhowells/linux-headers.git 
  tags/disintegrate-media-20121009
 
  for you to fetch changes up to 1c436decd49665be131887b08d172a7989cdceee:
 
UAPI: (Scripted) Disintegrate include/linux/dvb (2012-10-09 09:48:42 
  +0100)
 
  
  UAPI Disintegration 2012-10-09
 
  
  David Howells (1):
UAPI: (Scripted) Disintegrate include/linux/dvb
 
   include/linux/dvb/Kbuild|   8 -
   include/linux/dvb/dmx.h | 130 +--
   include/linux/dvb/video.h   | 249 
  +
   include/uapi/linux/dvb/Kbuild   |   8 +
   include/{ = uapi}/linux/dvb/audio.h|   0
   include/{ = uapi}/linux/dvb/ca.h   |   0
   include/uapi/linux/dvb/dmx.h| 155 ++
   include/{ = uapi}/linux/dvb/frontend.h |   0
   include/{ = uapi}/linux/dvb/net.h  |   0
   include/{ = uapi}/linux/dvb/osd.h  |   0
   include/{ = uapi}/linux/dvb/version.h  |   0
   include/uapi/linux/dvb/video.h  | 274 
  
   12 files changed, 439 insertions(+), 385 deletions(-)
   rename include/{ = uapi}/linux/dvb/audio.h (100%)
   rename include/{ = uapi}/linux/dvb/ca.h (100%)
   create mode 100644 include/uapi/linux/dvb/dmx.h
   rename include/{ = uapi}/linux/dvb/frontend.h (100%)
   rename include/{ = uapi}/linux/dvb/net.h (100%)
   rename include/{ = uapi}/linux/dvb/osd.h (100%)
   rename include/{ = uapi}/linux/dvb/version.h (100%)
   create mode 100644 include/uapi/linux/dvb/video.h

 Hmm... last year, it was decided that we would be putting the DVB av7110-only
 API files on a separate place, as the API there conflicts with V4L/alsa APIs

 Wrong! Hans Verkuil and you tried to do it, without caring that it would
 break userspace, and it was NAKed.

 Btw, if there is an API conflict, you guys created it.

 Anyone, who is interested in the _true_ history, should have a look at
 the GIT changelog:
 - dvb/{video.h,audio.h,osd.h} was the original decoder API.
 - Then Hans extended this API, still using the same files.
 - Later the v4l guys decided to create a new API.
 - Now they want to (re)move the old one, breaking userspace.

 I explicitly NAK any attempt to break userspace applications and tools!
 There is no reason to do it!

 and are used only by one upstream driver (there were two drivers using them,
 at that time). As you might notice, av7110 hardware is really old, not
 manufactured anymore since maybe 10 years ago, and it is an unmaintained
 driver.

 The driver works fine, and it will continue to do so, unless someone
 tampers with it. It does not require maintenance.
 The hardware is old, but it is still in use, as it is easy to create a
 pc-based settopbox with it.


As of writing; the av7110 is the only driver in-kernel, but there is more to it:
Such drivers are hard to bring up and takes an awful amount of time. There
is already one driver which is nearing completion based on the same interface.



 Some developers complained, arguing that moving it to a separate file would
 be breaking the compilation on existing tools (they're basically concerned 
 with
 it due to out-of-tree drivers - mostly propietary ones, that use this API).

 It you move the API somewhere else, you will break userspace applications
 like VDR. This is not acceptable.

 Now that we're moving everything, it does make sense to do that, moving
 dvb/(audio|osd|video).h to someplace else (maybe linux/dvb/av7110.h or
 linux/dvb/legacy/*.h).

 As far as I understand the original patchset, it will not break
 userspace, as it will simply move all files somewhere else, preserving
 file names and the position of the files in the tree.

 Mauro is trying to the move the old decoder API somewhere else, possibly
 into a different file, which will definitely break userspace.
 NAK for this!


I completely agree with Oliver on this and NAK the suggestion put forward
by Mauro (and Hans)


Regards,
Manu
--
To unsubscribe from this list: send the line 

Re: [git:v4l-dvb/for_v3.7] [media] mantis: Terratec Cinergy C PCI HD (CI)

2012-08-14 Thread Manu Abraham
On Tue, Aug 14, 2012 at 12:55 AM, Mauro Carvalho Chehab
mche...@redhat.com wrote:
 Em 10-08-2012 20:55, Manu Abraham escreveu:
 Mauro,

 Please revert this patch. Patch is incorrect. There is the VP-20300,
 VP-20330, VP-2040, with differences in tuner types TDA10021, TDA10023,
 MK-I, MK-II and MK-III. I have detailed this issue in an earlier mail.
 Terratec Cinregy C is VP-2033 and not VP-2040.

 Well, as I don't have this board, you think that it is a VP-2033 while
 Igor thinks it is a VP-2040, I can't tell who is right on that.

You don't need all the cards to apply changes, that's how the Linux
patchland works.

I have all Mantis based devices here. So I can say with clarity that
Terratec Cinergy C is VP-2033. I authored the whole driver for the
chipset manufacturer and the card manufacturer and still in touch with
all of them and pretty sure what is what.

Any idiot can send any patch, that's why you need to ask the persons
who added particular changes in that area. Do you want me to add
myself to MAINTAINERS to make it a bit more clearer, if that's what
you prefer ?

Please revert this change.

Manu
--
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: Copyright issues, do not copy code and add your own copyrights

2012-08-14 Thread Manu Abraham
Hi,

On Tue, Aug 14, 2012 at 2:51 PM, Hans de Goede hdego...@redhat.com wrote:
 Hi,


 On 08/14/2012 11:10 AM, Manu Abraham wrote:

 Hi,

 The subject line says it.

 Please fix the offending Copyright header.

 Offending one.

 http://git.linuxtv.org/media_tree.git/blob/staging/for_v3.7:/drivers/media/dvb-frontends/stb6100_proc.h

 Original one.

 http://git.linuxtv.org/media_tree.git/blob/staging/for_v3.7:/drivers/media/dvb-frontends/stb6100_cfg.h


 Or even better, get rid of the offending one and add a i2c_gate_ctrl
 parameters to the inline
 functions defined in stb6100_cfg.h, as this seems a typical case of
 unnecessary code-duplication.


i2c_gate_ctrl is not provided by stb6100 hardware, but by the demodulator
used in conjunction such as a stb0899 as can be seen.


1473 /* enable tuner I/O */
1474 stb0899_i2c_gate_ctrl(state-frontend, 1);
1475
1476 if (state-config-tuner_set_bandwidth)
1477
state-config-tuner_set_bandwidth(fe, (13 *
(stb0899_carr_width(state) + SearchRange)) / 10);
1478 if (state-config-tuner_get_bandwidth)
1479
state-config-tuner_get_bandwidth(fe, internal-tuner_bw);


A sleep for a jiffie is needed after the gate is enabled, but any real life
sleep is pointless and causes unnecessary delays, causing noise to bleed
into the demodulator.

This improves tuning performance slightly. The user (demodulator) of the tuner
needs to enable/disable the gate, in this case as seen in

http://git.linuxtv.org/media_tree.git/blob/staging/for_v3.7:/drivers/media/dvb-frontends/stb0899_drv.c



 I would also like to point out that things like these are pretty much wrong:

   27 if (fe-ops)
   28 frontend_ops = fe-ops;
   29 if (frontend_ops-tuner_ops)
   30 tuner_ops = frontend_ops-tuner_ops;
   31 if (tuner_ops-get_state) {

 The last check de-references tuner_ops, which only is non-NULL if
 fe-ops and fe-ops-tuner_ops are non NULL. So either the last check
 needs to be:
  if (tuner_ops  tuner_ops-get_state) {

 Or we assume that fe-ops and fe-ops-tuner_ops are always non NULL
 when this helper gets called and all the previous checks can be removed.


fe-ops is not NULL in any case, when we reach here, but that conditionality
check causes a slight additional delay. The additional check you proposed
presents no harm, though not bringing any new advantage/disadvantage.

Regards,

Manu
--
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: STV0299: reading property DTV_FREQUENCY -- what am I expected to get?

2012-08-14 Thread Manu Abraham
Hi,

On Tue, Aug 14, 2012 at 2:23 PM, Reinhard Nissl rni...@gmx.de wrote:
 Hi,

 it seems that my 9 years old LNBs got some drift over time, as tuning takes
 quite a while until I get a lock. So I thought I could compensate this
 offset by adjusting VDR's diseqc.conf.

 Therefore I first hacked some logging into VDR's tuner code to read and
 output the above mentioned property once it got a lock after tuning. As
 VDR's EPG scanner travels over all transponders when idle, I get offset
 values for all transponders and can then try to find some average offset to
 put into diseqc.conf.

 So here are several travel results for a single transponder ordered by
 Delta:

 Sat.Pol.BandFreq (MHz) Set  Freq (MHz) Get  Delta (MHz)
 S13,0E  H   H   11938   11930,528   -7,472
 S13,0E  H   H   11938   11936,294   -1,706
 S13,0E  H   H   11938   11938,917   0,917
 S13,0E  H   H   11938   11939,158   1,158
 S13,0E  H   H   11938   11939,906   1,906
 S13,0E  H   H   11938   11939,965   1,965
 S13,0E  H   H   11938   11940,029   2,029
 S13,0E  H   H   11938   11940,032   2,032
 S13,0E  H   H   11938   11940,103   2,103
 S13,0E  H   H   11938   11940,112   2,112
 S13,0E  H   H   11938   11940,167   2,167
 S13,0E  H   H   11938   11941,736   3,736
 S13,0E  H   H   11938   11941,736   3,736
 S13,0E  H   H   11938   11941,736   3,736
 S13,0E  H   H   11938   11942,412   4,412
 S13,0E  H   H   11938   11943,604   5,604
 S13,0E  H   H   11938   11943,604   5,604
 S13,0E  H   H   11938   11943,604   5,604
 S13,0E  H   H   11938   11945,472   7,472
 S13,0E  H   H   11938   11945,472   7,472
 S13,0E  H   H   11938   11945,472   7,472
 S13,0E  H   H   11938   11945,472   7,472
 S13,0E  H   H   11938   11945,472   7,472
 S13,0E  H   H   11938   11945,472   7,472
 S13,0E  H   H   11938   11945,472   7,472
 S13,0E  H   H   11938   11945,777   7,777
 S13,0E  H   H   11938   11945,777   7,777
 S13,0E  H   H   11938   11945,777   7,777
 S13,0E  H   H   11938   11945,777   7,777

 I really wonder why Delta varies that much, and there are other transponders
 in the same band which have no larger deltas then 3 MHz.


The LNB drift is due to the cheap RC oscillator in standard LNB's which are
temperature dependant. So, the oscillator frequency that you might experience
at mid-day, might not be same as that at midnight. The capacitors are ceramic
capacitors, so there isn't likely the chance of the capacitor changing
it's value
too much over time, but there exists other issues such as parasitic
capacitances
when the LNB shell looses it's hermetic seal.

I have seen the drift overlapping another transponder with the stv0299 in some
scenarios, but don't see how this can be fixed reliably.


 So is it at all possible to determine LNB drift in that way?

 My other device, a STB0899, always reports the set frequency. So it seems
 driver dependent whether it reports the actually locked frequency found by
 the zig-zag-algorithm or just the set frequency to tune to.


The STV0299 blindly sets the value based on a software zigzag (due to simpler
hardware), but this might not be accurate enough. On the other hand, the
STB0899 internally does zig-zag in hardware for DVB-S2, and partly in
software for DVB-S.

In any event, the get_frontend callback should return the value that is read
from the demodulator registers, rather than the cached original value that
which was requested to be tuned.

The stb0899 returns only the cached value IIRC. Maybe I will fix this soon,
or maybe you can send a patch.

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


Re: [PATCH] DVB-S2 multistream support

2012-08-12 Thread Manu Abraham
On Mon, Aug 13, 2012 at 12:20 AM, Antti Palosaari cr...@iki.fi wrote:
 On 08/12/2012 09:33 PM, CrazyCat wrote:

 Ok, done :) Look like DTV_DVBT2_PLP_ID not implemented for CXD2820r ?


 yes, true. It uses always PLP 0. I didn't have signal source that uses
 multiple PLPs. I didn't even add that PLP ID to API.

CXD2820 works only with PLP Type 1 or Type A in some other terminology.
PLP Type Common and PLP Type 2 are not supported by the hardware.
ie, it fails to acquire a LOCK with anything else.

Issue confirmed by Sony as well.

Regards,
Manu
--
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: [git:v4l-dvb/for_v3.7] [media] mantis: Terratec Cinergy C PCI HD (CI)

2012-08-10 Thread Manu Abraham
Mauro,

Please revert this patch. Patch is incorrect. There is the VP-20300,
VP-20330, VP-2040, with differences in tuner types TDA10021, TDA10023,
MK-I, MK-II and MK-III. I have detailed this issue in an earlier mail.
Terratec Cinregy C is VP-2033 and not VP-2040.

Thanks!


On Sat, Aug 11, 2012 at 1:34 AM, Mauro Carvalho Chehab
mche...@redhat.com wrote:
 This is an automatic generated email to let you know that the following patch 
 were queued at the
 http://git.linuxtv.org/media_tree.git tree:

 Subject: [media] mantis: Terratec Cinergy C PCI HD (CI)
 Author:  Igor M. Liplianin liplia...@me.by
 Date:Wed May 9 07:23:14 2012 -0300

 This patch seems for rectifying a typo. But actually the difference between
 mantis_vp2040.c and mantis_vp2033.c code is a card name only.

 Signed-off-by: Igor M. Liplianin liplia...@me.by
 Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com

  drivers/media/dvb/mantis/mantis_cards.c |2 +-
  drivers/media/dvb/mantis/mantis_core.c  |2 +-
  2 files changed, 2 insertions(+), 2 deletions(-)

 ---

 http://git.linuxtv.org/media_tree.git?a=commitdiff;h=9fa4d6a102ebb06663a03554b57fb93ad618b72e

 diff --git a/drivers/media/dvb/mantis/mantis_cards.c 
 b/drivers/media/dvb/mantis/mantis_cards.c
 index 095cf3a..0207d1f 100644
 --- a/drivers/media/dvb/mantis/mantis_cards.c
 +++ b/drivers/media/dvb/mantis/mantis_cards.c
 @@ -275,7 +275,7 @@ static struct pci_device_id mantis_pci_table[] = {
 MAKE_ENTRY(TWINHAN_TECHNOLOGIES, MANTIS_VP_2033_DVB_C, 
 vp2033_config),
 MAKE_ENTRY(TWINHAN_TECHNOLOGIES, MANTIS_VP_2040_DVB_C, 
 vp2040_config),
 MAKE_ENTRY(TECHNISAT, CABLESTAR_HD2, vp2040_config),
 -   MAKE_ENTRY(TERRATEC, CINERGY_C, vp2033_config),
 +   MAKE_ENTRY(TERRATEC, CINERGY_C, vp2040_config),
 MAKE_ENTRY(TWINHAN_TECHNOLOGIES, MANTIS_VP_3030_DVB_T, 
 vp3030_config),
 { }
  };
 diff --git a/drivers/media/dvb/mantis/mantis_core.c 
 b/drivers/media/dvb/mantis/mantis_core.c
 index 22524a8..684d906 100644
 --- a/drivers/media/dvb/mantis/mantis_core.c
 +++ b/drivers/media/dvb/mantis/mantis_core.c
 @@ -121,7 +121,7 @@ static void mantis_load_config(struct mantis_pci *mantis)
 mantis-hwconfig = vp2033_mantis_config;
 break;
 case MANTIS_VP_2040_DVB_C:  /* VP-2040 */
 -   case TERRATEC_CINERGY_C_PCI:/* VP-2040 clone */
 +   case CINERGY_C: /* VP-2040 clone */
 case TECHNISAT_CABLESTAR_HD2:
 mantis-hwconfig = vp2040_mantis_config;
 break;

 ___
 linuxtv-commits mailing list
 linuxtv-comm...@linuxtv.org
 http://www.linuxtv.org/cgi-bin/mailman/listinfo/linuxtv-commits
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH] DVB-S2 multistream support

2012-08-10 Thread Manu Abraham
On Sat, Aug 11, 2012 at 3:42 AM, Mauro Carvalho Chehab
mche...@redhat.com wrote:
 Em 13-07-2012 20:15, CrazyCat escreveu:
 Now present DTV_DVBT2_PLP_ID property for DVB-T2, so i add alias 
 DTV_DVBS2_MIS_ID (same feature for advanced DVB-S2). Now DVB-S2 multistream 
 filtration supported for current STV090x demod cut 3.0, so i implement 
 support for stv090x demod driver. Additional fe-caps FE_CAN_MULTISTREAM also 
 added.


 frontend-mis.patch

 Please provide your Signed-off-by: (with your real name).



 diff --git a/include/linux/dvb/frontend.h b/include/linux/dvb/frontend.h
 index f50d405..f625f8d 100644
 --- a/include/linux/dvb/frontend.h
 +++ b/include/linux/dvb/frontend.h
 @@ -62,6 +62,7 @@ typedef enum fe_caps {
   FE_CAN_8VSB = 0x20,
   FE_CAN_16VSB= 0x40,
   FE_HAS_EXTENDED_CAPS= 0x80,   /* We need more bitspace 
 for newer APIs, indicate this. */
 + FE_CAN_MULTISTREAM  = 0x400,  /* frontend supports 
 DVB-S2 multistream filtering */

 Not sure if this is really needed. Are there any DVB-S2 frontends that
 don't support MIS, or they don't implement it just because this weren't
 defined yet? In the latter case, it would be better to not adding an
 special flag for it.

There are some demods that do not support Advanced Modes ..


   FE_CAN_TURBO_FEC= 0x800,  /* frontend supports 
 turbo fec modulation */
   FE_CAN_2G_MODULATION= 0x1000, /* frontend supports 
 2nd generation modulation (DVB-S2) */
   FE_NEEDS_BENDING= 0x2000, /* not supported 
 anymore, don't use (frontend requires frequency bending) */
 @@ -317,6 +318,7 @@ struct dvb_frontend_event {
  #define DTV_ISDBS_TS_ID  42

  #define DTV_DVBT2_PLP_ID 43
 +#define DTV_DVBS2_MIS_ID 43

 It would be better to define it as:

 #define DTV_DVBS2_MIS_IDDTV_DVBT2_PLP_ID

 Even better, we should instead find a better name that would cover both
 DVB-T2 and DVB-S2 program ID fields, like:

 #define DTV_DVB_MULT43
 #define DTV_DVBT2_PLP_IDDTV_DVB_MULT


In fact that is also incorrect.

DVB-S2 uses TS ID at Link Layer
at Physical layer there is BBHEADER.

DVB-T2 uses PLP ID at Physical Layer

ISDB-S uses Stream ID

ISDB-T uses Layer A, LayerB, Layer C



 And use the new symbol for both DVB-S2 and DVB-T2, deprecating the
 legacy symbol.

 Also, DocBook needs to be changed to reflect this change.


  #define DTV_ENUM_DELSYS  44

 diff --git a/drivers/media/dvb/dvb-core/dvb_frontend.c 
 b/drivers/media/dvb/dvb-core/dvb_frontend.c
 index aebcdf2..83e51f9 100644
 --- a/drivers/media/dvb/dvb-core/dvb_frontend.c
 +++ b/drivers/media/dvb/dvb-core/dvb_frontend.c
 @@ -947,7 +947,7 @@ static int dvb_frontend_clear_cache(struct dvb_frontend 
 *fe)
   }

   c-isdbs_ts_id = 0;
 - c-dvbt2_plp_id = 0;
 + c-dvbt2_plp_id = -1;

   switch (c-delivery_system) {
   case SYS_DVBS:
 diff --git a/drivers/media/dvb/frontends/stv090x.c 
 b/drivers/media/dvb/frontends/stv090x.c
 index ea86a56..eb6f1cf 100644
 --- a/drivers/media/dvb/frontends/stv090x.c
 +++ b/drivers/media/dvb/frontends/stv090x.c
 @@ -3425,6 +3425,33 @@ err:
   return -1;
  }

 +static int stv090x_set_mis(struct stv090x_state *state, int mis)
 +{
 + u32 reg;
 +
 + if (mis0 || mis255) {

 You should be checking your patch using scripts/checkpatch.pl.
 Due to Documentation/CodingStyle, the above should be written, instead, as:
 if (mis  0 || mis  255) {


 + dprintk(FE_DEBUG, 1, Disable MIS filtering);
 + reg = STV090x_READ_DEMOD(state, PDELCTRL1);
 + STV090x_SETFIELD_Px(reg, FILTER_EN_FIELD, 0x00);
 + if (STV090x_WRITE_DEMOD(state, PDELCTRL1, reg)  0)
 + goto err;
 + } else {
 + dprintk(FE_DEBUG, 1, Enable MIS filtering - %d, mis);
 + reg = STV090x_READ_DEMOD(state, PDELCTRL1);
 + STV090x_SETFIELD_Px(reg, FILTER_EN_FIELD, 0x01);
 + if (STV090x_WRITE_DEMOD(state, PDELCTRL1, reg)  0)
 + goto err;
 + if (STV090x_WRITE_DEMOD(state, ISIENTRY, mis)  0)
 + goto err;
 + if (STV090x_WRITE_DEMOD(state, ISIBITENA, 0xff)  0)
 + goto err;
 + }
 + return 0;
 +err:
 + dprintk(FE_ERROR, 1, I/O error);
 + return -1;
 +}
 +
  static enum dvbfe_search stv090x_search(struct dvb_frontend *fe)
  {
   struct stv090x_state *state = fe-demodulator_priv;
 @@ -3433,6 +3460,8 @@ static enum dvbfe_search stv090x_search(struct 
 dvb_frontend *fe)
   if (props-frequency == 0)
   return DVBFE_ALGO_SEARCH_INVALID;

 + stv090x_set_mis(state,props-dvbt2_plp_id);
 +
   state-delsys = props-delivery_system;
   state-frequency = props-frequency;
   state-srate = props-symbol_rate;
 @@ -3447,6 +3476,8 @@ static enum dvbfe_search 

Re: [PATCH] DVB-S2 multistream support

2012-08-10 Thread Manu Abraham
On Sat, Aug 11, 2012 at 5:44 AM, Antti Palosaari cr...@iki.fi wrote:
 On 08/11/2012 01:12 AM, Mauro Carvalho Chehab wrote:

 Em 13-07-2012 20:15, CrazyCat escreveu:


   #define DTV_ISDBS_TS_ID   42

   #define DTV_DVBT2_PLP_ID  43
 +#define DTV_DVBS2_MIS_ID   43


 It would be better to define it as:

 #define DTV_DVBS2_MIS_IDDTV_DVBT2_PLP_ID

 Even better, we should instead find a better name that would cover both
 DVB-T2 and DVB-S2 program ID fields, like:

 #define DTV_DVB_MULT43
 #define DTV_DVBT2_PLP_IDDTV_DVB_MULT

 And use the new symbol for both DVB-S2 and DVB-T2, deprecating the
 legacy symbol.


 Also DTV_ISDBS_TS_ID means same. All these three DTV_ISDBS_TS_ID,
 DTV_DVBT2_PLP_ID and DTV_DVBS2_MIS_ID are same thing - just named
 differently between standards. I vote for common name TS ID (I have said
 that already enough many times...).

I agree, but a still more generic term like STREAM_ID would be more
appropriate,
as it happens at different layers for different delivery
systems.DVB-S2 additionally
provides BBHEADER at Physical Layer. In any case setting PLP_ID for DVB-S2
is completely confusing.

Anyway, the demuxer part is also missing ..

If you look a bit more deeper, you will see that the framing structure
with ISDB-T
is exactly the same as with ISDB-S, which makes ISDB-T also no different, just
that the frontend userspace header is just fucked up with junk.

The major chunk for the ISDB-T stuff in the frontend header is
completely redundant.

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


Re: [PATCH] DVB-S2 multistream support

2012-08-10 Thread Manu Abraham
On Sat, Aug 11, 2012 at 6:37 AM, Antti Palosaari cr...@iki.fi wrote:
 On 08/11/2012 03:31 AM, Manu Abraham wrote:

 On Sat, Aug 11, 2012 at 5:44 AM, Antti Palosaari cr...@iki.fi wrote:

 On 08/11/2012 01:12 AM, Mauro Carvalho Chehab wrote:


 Em 13-07-2012 20:15, CrazyCat escreveu:



#define DTV_ISDBS_TS_ID   42

#define DTV_DVBT2_PLP_ID  43
 +#define DTV_DVBS2_MIS_ID   43



 It would be better to define it as:

 #define DTV_DVBS2_MIS_IDDTV_DVBT2_PLP_ID

 Even better, we should instead find a better name that would cover both
 DVB-T2 and DVB-S2 program ID fields, like:

 #define DTV_DVB_MULT43
 #define DTV_DVBT2_PLP_IDDTV_DVB_MULT

 And use the new symbol for both DVB-S2 and DVB-T2, deprecating the
 legacy symbol.



 Also DTV_ISDBS_TS_ID means same. All these three DTV_ISDBS_TS_ID,
 DTV_DVBT2_PLP_ID and DTV_DVBS2_MIS_ID are same thing - just named
 differently between standards. I vote for common name TS ID (I have said
 that already enough many times...).


 I agree, but a still more generic term like STREAM_ID would be more
 appropriate,


 Ack. Since this stream could be something else than MPEG2-TS better to give
 more generic name.


 as it happens at different layers for different delivery
 systems.DVB-S2 additionally
 provides BBHEADER at Physical Layer. In any case setting PLP_ID for DVB-S2
 is completely confusing.

 Anyway, the demuxer part is also missing ..


 Demuxer for MIS? I am not any familiar with MIS but I know there is raw
 demux payload used already for ATSC-M/H. It just passes all the data coming
 from demod TS.

Just grabbing and sending the DMA'd data to userspace is not nice.

With ATSC-M/H you don't simply have a TS. With an ATSC-M/H capable
demod, which supports ATSC (standard) outputs a TS. the M/H part is not
a TS at all.

Even with ATSC-M/H passing raw data causes all the IP (network) packets to
be parsed in userspace, which should have been properly done in kernel
space as a filter. If we were to do everything similarly, then we don't need
any API at all, just a simple read and let each application do whatever it
wants.

Regards,
Manu
--
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] mantis: merge both vp2033 and vp2040 drivers

2012-08-06 Thread Manu Abraham
On Tue, Aug 7, 2012 at 12:32 AM, Mauro Carvalho Chehab
mche...@redhat.com wrote:
 As noticed at:
 
 http://comments.gmane.org/gmane.linux.drivers.video-input-infrastructure/48034

 Both drivers are identical, except for the name. So, there's no
 sense on keeping both. Instead of forking the entire code, just
 fork the vp3033_config struct, saving some space, and cleaning
 up the Kernel.


 Reported-by: Igor M. Liplianin liplia...@me.by
 Cc: Manu Abraham abraham.m...@gmail.com
 Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com

Nack.

VP-2033 and 2040 are both different in terms of hardware. If someone
wants to add
in additional frontend characteristic differences, he shouldn't have
to add in this code
again.
--
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: tda18271 driver power consumption

2012-08-06 Thread Manu Abraham
On Tue, Aug 7, 2012 at 12:43 AM, Antti Palosaari cr...@iki.fi wrote:
..
 I ran thinking that recently when looked how to
 implement DVB SDR for V4L2 API...

If you try to fit an apple into an orange, you run into that sort of a problem.
If you are working with DVB, the Linux-DVB is the way to go, If you are
working with analog/webcams then V4L should be used. If you are mixing
both worlds, then you land into all sorts of nastiness.

You might need extensions to fit hardware needs as time passes by, but
still you have the same basic fundamental thing working in there ..

One comes across demodulators running on a DSP/FPGA or a DSP-FPGA
and so on ..

Regards,
Manu
--
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] mantis: merge both vp2033 and vp2040 drivers

2012-08-06 Thread Manu Abraham
On Tue, Aug 7, 2012 at 1:50 AM, Mauro Carvalho Chehab
mche...@redhat.com wrote:
 Em 06-08-2012 17:07, Manu Abraham escreveu:
 On Tue, Aug 7, 2012 at 12:32 AM, Mauro Carvalho Chehab
 mche...@redhat.com wrote:
 As noticed at:
 
 http://comments.gmane.org/gmane.linux.drivers.video-input-infrastructure/48034

 Both drivers are identical, except for the name. So, there's no
 sense on keeping both. Instead of forking the entire code, just
 fork the vp3033_config struct, saving some space, and cleaning
 up the Kernel.


 Reported-by: Igor M. Liplianin liplia...@me.by
 Cc: Manu Abraham abraham.m...@gmail.com
 Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com

 Nack.

 VP-2033 and 2040 are both different in terms of hardware. If someone
 wants to add
 in additional frontend characteristic differences, he shouldn't have
 to add in this code
 again.

 The code are just the same for both! If it ever become different, then
 it could be forked again, but for now, it is just duplicating the same
 code on both places and wasting 200 lines of useless code.


No, because you see the code that way, it doesn't necessarily mean that
you have to merge all code that look similar.

That's just peanuts you are talking about. The memory usage appears only
if you are using the module. 200 lines of .text is nothing. That exists to
differentiate between the 2 devices, not to make both hardware look the same.

I have explained why those 2 devices need to be differentiated.

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


Re: [PATCH 3/3] [media] tuner, xc2028: add support for get_afc()

2012-08-06 Thread Manu Abraham
On Fri, Jul 6, 2012 at 1:40 AM, Mauro Carvalho Chehab
mche...@redhat.com wrote:
 Em 05-07-2012 14:37, Bert Massop escreveu:
 On Thu, Jul 5, 2012 at 5:05 PM, Antti Palosaari cr...@iki.fi wrote:

 On 07/05/2012 05:16 PM, Mauro Carvalho Chehab wrote:

 Implement API support to return AFC frequency shift, as this device
 supports it. The only other driver that implements it is tda9887,
 and the frequency there is reported in Hz. So, use Hz also for this
 tuner.


 What is AFC and why it is needed?


 AFC is short for Automatic Frequency Control, by which a tuner
 automatically fine-tunes the frequency for the best reception,
 compensating for small offsets and oscillator frequency drift.
 This is however done automatically on the tuner, so its configuration
 is read-only. Aside from being a nice to know statistic, getting
 hold of the AFC frequency shift does as far as I know not have any
 practical uses related to properly operating the tuner.

 AFC might be useful on a few situations. For example, my CATV operator
 still broadcasts some channels in both analog and digital.


If you have really have hardware that does AFC Automatic Frequency Control,
then you shouldn't be exposing this value to userspace. It should be
held in the
driver alone.

Technically, hardware that do not have AFC alone should expose this value to
userspace, so that applications can control the dumb piece of hardware, that
doesn't lock to Fc aka Center frequency. All decent tuners do lock onto the
center of the step size in any given case, these days.

When the driver knows the offset, it needs to compute the offset and sum it
to the resultant, so that get_frequency() retrieves the recomputed value.


Manu
--
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] [V3] stv090x: variable 'no_signal' set but not used

2012-07-06 Thread Manu Abraham
On Thu, Jun 28, 2012 at 7:38 PM, Peter Senna Tschudin
peter.se...@gmail.com wrote:
 Remove variable and ignore return value of stv090x_chk_signal().

 Tested by compilation only.

 Signed-off-by: Peter Senna Tschudin peter.se...@gmail.com

Reviewed-by: Manu Abraham m...@linuxtv.org

 ---
  drivers/media/dvb/frontends/stv090x.c |4 ++--
  1 file changed, 2 insertions(+), 2 deletions(-)

 diff --git a/drivers/media/dvb/frontends/stv090x.c 
 b/drivers/media/dvb/frontends/stv090x.c
 index d79e69f..ea86a56 100644
 --- a/drivers/media/dvb/frontends/stv090x.c
 +++ b/drivers/media/dvb/frontends/stv090x.c
 @@ -3172,7 +3172,7 @@ static enum stv090x_signal_state stv090x_algo(struct 
 stv090x_state *state)
 enum stv090x_signal_state signal_state = STV090x_NOCARRIER;
 u32 reg;
 s32 agc1_power, power_iq = 0, i;
 -   int lock = 0, low_sr = 0, no_signal = 0;
 +   int lock = 0, low_sr = 0;

 reg = STV090x_READ_DEMOD(state, TSCFGH);
 STV090x_SETFIELD_Px(reg, RST_HWARE_FIELD, 1); /* Stop path 1 stream 
 merger */
 @@ -3413,7 +3413,7 @@ static enum stv090x_signal_state stv090x_algo(struct 
 stv090x_state *state)
 goto err;
 } else {
 signal_state = STV090x_NODATA;
 -   no_signal = stv090x_chk_signal(state);
 +   stv090x_chk_signal(state);
 }
 }
 return signal_state;
 --
 1.7.10.2

--
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: [git:v4l-dvb/for_v3.6] [media] stv090x: variable 'no_signal' set but not used

2012-06-28 Thread Manu Abraham
Hi,

On Wed, Jun 27, 2012 at 8:57 PM, Peter Senna Tschudin
peter.se...@gmail.com wrote:

 Manu,

 On Wed, Jun 27, 2012 at 9:59 AM, Manu Abraham abraham.m...@gmail.com wrote:
  Wonderful, instead of ignoring the return value, you ignored the whole
  function
  itself. Most of the demodulator registers are R-M-x registers. The patch
  brings
  in unwanted side-effects of R-M-x.

 Sorry for that. I'll send V2 of this patch just ignoring the return
 value. Can you please send me some reference about R-M-x registers?



Unfortunately public versions of the document do not exist. But, basically the
demodulator is a device that has microcontrollers, memory banks FPGA/DSP
on it.  Specifically, this demodulator is a bit complex device in all
aspects. The
registers what you see externally have different operating modes associated
with it, such as Read-Only, Write-Only, Read-Modify-Write and some others
where they shouldn't be accessed during certain operations and some others
should be updated, such as simple read to update the interface registers, or
in some cases a write of the same value to trigger some states. Even more
complex are the updates which are triggered based on bit-order-significance.
To summarize, the interface registers are shadowed by the on-chip
microcontroller to implement a Wait Free Synchronization method.

I was able to find a related description elsewhere on the Internet.

http://www.patentstorm.us/patents/4342079.html

Hope it helps,

Regards,
Manu
--
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] Terratec Cinergy C PCI HD (CI)

2012-05-15 Thread Manu Abraham
On Wed, May 9, 2012 at 4:53 PM, Igor M. Liplianin liplia...@me.by wrote:
 This patch seems for rectifying a typo. But actually the difference between
 mantis_vp2040.c and mantis_vp2033.c code is a card name only.

 Signed-off-by: Igor M. Liplianin liplia...@me.by

Do you have a card with the tda10021 or the tda10023 ?
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


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

2012-05-15 Thread Manu Abraham
Hi Andreas,

Sorry about the late reply.

Which datasheet revision are you using ? I looked at RevG and found that the
register ERRCNT22 @ 0xF59D, 0xF39D do have bitfields by name Px_ERR_CNT2
on Page 227.

Did you overlook that by some chance ?

Best Regards,
Manu


On Tue, Feb 28, 2012 at 2:12 AM, Andreas Regel andreas.re...@gmx.de wrote:
 Fix typo in register macros of ERRCNT2.

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

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

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


Re: HVR 4000 hybrid card still producing multiple frontends for single adapter

2012-01-24 Thread Manu Abraham
On Tue, Jan 24, 2012 at 8:28 PM, Antti Palosaari cr...@iki.fi wrote:
 On 01/24/2012 04:49 PM, Devin Heitmueller wrote:

 On Tue, Jan 24, 2012 at 6:48 AM, Antti Palosaaricr...@iki.fi  wrote:

 On 01/24/2012 06:41 AM, Hawes, Mark wrote:


 Hi,

 I have a HVR 4000 hybrid card  which provides both DVB-S2 and DVB-T
 capabilities on the one adapter. Using the current media tree build
 updated
 with the contents of the linux media drivers tarball dated 22/01/2012
 the
 drivers for this card are still generating two frontends on the adapter
 as
 below:

 Jan 23 12:16:44 Nutrigrain kernel: [    9.346240] DVB: registering
 adapter 1 frontend 0 (Conexant CX24116/CX24118)...
 Jan 23 12:16:44 Nutrigrain kernel: [    9.349110] DVB: registering
 adapter 1 frontend 1 (Conexant CX22702 DVB-T)...



 I understand that this behaviour is now deprecated and that the correct
 behaviour should be to generate one front end with multiple
 capabilities.
 Can this please be corrected.



 Same applies for many other devices too. For example some older Anysee E7
 models have two chip and two frontends whilst new one have only one. Also
 TechnoTrend CT3650 and Hauppauge WinTV.

 Maybe it those are implemented later as one frontend, it not clear for
 me.


 The merging of frontends is something that is only done if there are
 multiple modulation types on the same demodulator chip.  As the
 HVR-4000 has separate demods for DVB-T versus DVB-S2, they will always
 be represented by two separate frontends (for the foreseeable future).

 In other words, the recent work doesn't apply to this card (and others
 like it).


 So what was the actual benefit then just introduce one way more to implement
 same thing. As I sometime understood from Manu's talk there will not be
 difference if my device is based of DVB-T + DVB-C demod combination or just
 single chip that does same. Now there is devices that have same
 characteristics but different interface.

Yes, you are right. I had a very preliminary patch to handle this,
Will post it soon.

Regards,
Manu
--
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 0/9] dvb_frontend: Don't rely on drivers filling ops-info.type

2012-01-02 Thread Manu Abraham
On Mon, Jan 2, 2012 at 4:25 PM, Mauro Carvalho Chehab
mche...@redhat.com wrote:
 On 02-01-2012 05:31, Manu Abraham wrote:
 On Mon, Jan 2, 2012 at 1:41 AM, Mauro Carvalho Chehab
 mche...@redhat.com wrote:
 This is likely the last patch series from my series of DVB cleanups.
 I still intend to work on DRX-K frontend merge patch, but this will
 need to wait until my return to my home town. Of course, if you're
 hurry with this, patches are welcome.

 This series changes dvb_frontend to use ops-delsys instead of 
 ops-info.type,
 as the source for the frontend support. With this series:

 1) the first delivery system is reported as info.type for DVBv3 apps;
 2) all subsequent checks are made against the current delivery system
   (c-delivery_system);
 3) An attempt to use an un-suported delivery system will either return
   an error, or enter into the emulation mode, if the frontend is
   using a newer delivery system.
 4) Lots of cleanup at the cache sync logic. Now, a pure DVBv5 call
   shouldn't fill the DVBv3 structs. Still, as events are generated,
   the event will dynamically generate a DVBv3 compat struct.

 The emulation logic is not perfect (but it were not perfect before this
 patch series). The emulation will work worse for devices that have
 support for different ops-info.type, as there's no way for a DVBv3
 application to work properly with those devices.

 TODO:

 There are a few things left to do, with regards to DVB frontend cleanup.
 They're more related to the DVBv5 API, so they were out of the scope
 of this series. Maybe some work for this upcoming year!

 They are:

        1) Fix the capabilities flags. There are several capabilities
 not reported, like several modulations, etc. There are not enough flags
 for them. It was suggested that the delivery system (DTV_ENUM_DELSYS)
 would be enough, but it doesn't seem so. For example, there are several
 SYS_ATSC devices that only support VSB_8. So, we'll end by needing to
 either extend the current way (but we lack bits) or to implement a DVBv5
 way for that;


 If an ATSC device supports fewer modulations, things should be
 even simpler. Just return INVALID Frontend setup if it is trying to
 setup something invalid, that which is not supported. Advertising
 the available modulations doesn't help in any sense.
 A53 spec talks about devices supporting 2 modes, Terrestrial
 mode and High data rate mode. It is unlikely and yet maybe
 some devices don't adhere to specifications supporting only
 8VSB, but even in those cases, just returning -EINVAL would be
 sufficient for 16VSB.

 What you suggest, just adds confusion alone to applications as
 to what to do with all the exported fields/flags.

 Returning -EINVAL works from kernel POV, but at least one userpsace
 application developer sent me an email those days complaining that
 applications need to know what are the supported capabilities, in order
 to provide a proper userspace gui.


FWIW, userapps shouldn't really bother about all the
hardware details. If user application were to really
bother about all the tiny intricacies (I can point out
a large amount of tiny intricacies that which might
sound pretty, as you are stating) then there wouldn't
be the need for a driver API -- the application itself
can contain the driver code. In short, providing too
much information to application is also not nice.

The user application should simply set the parameters
and try to demodulate, return error if it cannot.
Having unnecessary fields just causes confusion alone.
I don't see how providing all the modulations under a
delivery system can improve a GUI application
especially when it is according to the specifications.


        2) The DVBv3 events call (FE_GET_EVENT) is not ok for
 newer delivery system. We'll likely need to replace it by a DVBv5 way;



 It should be noted that there is no DVBv5 way, If you are implying
 to replace ioctl calls with a get/set interface, it doesn't make sense
 at all.

 By DVBv5 way, I'm meaning to say that it should be replaced by some way
 that allow reporting events not only for the 4 delivery systems supported
 by DVBv3 API.

 This could be as easy as adding a DTV_GET_EVENT command for FE_GET_PROPERTY.

 Alternatively, events could be reported via a poll() ops at the frontend
 node.


I am unable to see the advantage in adding a
new DTV_GET_EVENT call instead of FE_GET_PROPERTY
improve anything at all.



        3) The stats API needs to be extended. Delivery systems like
 ISDB can report a per-layer set of statistics. This is currently not
 supported. Also, it is desirable to get the stats together with a
 set of other properties.

 The per layer statistics is a myth and can be ignored. Each of the
 layers are much higher above and simply RF/demodulation
 parameters don't exist/layer; Even if you argue that they do exist,
 it would be exactly sufficient to read stats after setting up the
 relevant layer for filtering (since you cannot read demodulation
 statistics

Re: [PATCH 0/9] dvb_frontend: Don't rely on drivers filling ops-info.type

2012-01-02 Thread Manu Abraham
On Mon, Jan 2, 2012 at 8:03 PM, Mauro Carvalho Chehab
mche...@redhat.com wrote:
 On 02-01-2012 09:48, Manu Abraham wrote:
 On Mon, Jan 2, 2012 at 4:25 PM, Mauro Carvalho Chehab
 mche...@redhat.com wrote:
 On 02-01-2012 05:31, Manu Abraham wrote:
 On Mon, Jan 2, 2012 at 1:41 AM, Mauro Carvalho Chehab
 mche...@redhat.com wrote:
 This is likely the last patch series from my series of DVB cleanups.
 I still intend to work on DRX-K frontend merge patch, but this will
 need to wait until my return to my home town. Of course, if you're
 hurry with this, patches are welcome.

 This series changes dvb_frontend to use ops-delsys instead of 
 ops-info.type,
 as the source for the frontend support. With this series:

 1) the first delivery system is reported as info.type for DVBv3 apps;
 2) all subsequent checks are made against the current delivery system
   (c-delivery_system);
 3) An attempt to use an un-suported delivery system will either return
   an error, or enter into the emulation mode, if the frontend is
   using a newer delivery system.
 4) Lots of cleanup at the cache sync logic. Now, a pure DVBv5 call
   shouldn't fill the DVBv3 structs. Still, as events are generated,
   the event will dynamically generate a DVBv3 compat struct.

 The emulation logic is not perfect (but it were not perfect before this
 patch series). The emulation will work worse for devices that have
 support for different ops-info.type, as there's no way for a DVBv3
 application to work properly with those devices.

 TODO:

 There are a few things left to do, with regards to DVB frontend cleanup.
 They're more related to the DVBv5 API, so they were out of the scope
 of this series. Maybe some work for this upcoming year!

 They are:

        1) Fix the capabilities flags. There are several capabilities
 not reported, like several modulations, etc. There are not enough flags
 for them. It was suggested that the delivery system (DTV_ENUM_DELSYS)
 would be enough, but it doesn't seem so. For example, there are several
 SYS_ATSC devices that only support VSB_8. So, we'll end by needing to
 either extend the current way (but we lack bits) or to implement a DVBv5
 way for that;


 If an ATSC device supports fewer modulations, things should be
 even simpler. Just return INVALID Frontend setup if it is trying to
 setup something invalid, that which is not supported. Advertising
 the available modulations doesn't help in any sense.
 A53 spec talks about devices supporting 2 modes, Terrestrial
 mode and High data rate mode. It is unlikely and yet maybe
 some devices don't adhere to specifications supporting only
 8VSB, but even in those cases, just returning -EINVAL would be
 sufficient for 16VSB.

 What you suggest, just adds confusion alone to applications as
 to what to do with all the exported fields/flags.

 Returning -EINVAL works from kernel POV, but at least one userpsace
 application developer sent me an email those days complaining that
 applications need to know what are the supported capabilities, in order
 to provide a proper userspace gui.


 FWIW, userapps shouldn't really bother about all the
 hardware details. If user application were to really
 bother about all the tiny intricacies (I can point out
 a large amount of tiny intricacies that which might
 sound pretty, as you are stating) then there wouldn't
 be the need for a driver API -- the application itself
 can contain the driver code. In short, providing too
 much information to application is also not nice.

 The user application should simply set the parameters
 and try to demodulate, return error if it cannot.

 -EINVAL could mean an error on any parameter, not just on
 modulation.

This suggestion of FE_CAN_MODULATION_X/Y/Z just follows
an earlier discussion about the FE_CAN_ bits where almost
everyone came to the conclusion and eventually agreed
that those are superfluous and such fine grained-ness is
not useful.
--
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 0/9] dvb_frontend: Don't rely on drivers filling ops-info.type

2012-01-02 Thread Manu Abraham
On Mon, Jan 2, 2012 at 8:03 PM, Mauro Carvalho Chehab
mche...@redhat.com wrote:
 On 02-01-2012 09:48, Manu Abraham wrote:
 On Mon, Jan 2, 2012 at 4:25 PM, Mauro Carvalho Chehab
 mche...@redhat.com wrote:
 On 02-01-2012 05:31, Manu Abraham wrote:
 On Mon, Jan 2, 2012 at 1:41 AM, Mauro Carvalho Chehab
 mche...@redhat.com wrote:
 This is likely the last patch series from my series of DVB cleanups.
 I still intend to work on DRX-K frontend merge patch, but this will
 need to wait until my return to my home town. Of course, if you're
 hurry with this, patches are welcome.

 This series changes dvb_frontend to use ops-delsys instead of 
 ops-info.type,
 as the source for the frontend support. With this series:

 1) the first delivery system is reported as info.type for DVBv3 apps;
 2) all subsequent checks are made against the current delivery system
   (c-delivery_system);
 3) An attempt to use an un-suported delivery system will either return
   an error, or enter into the emulation mode, if the frontend is
   using a newer delivery system.
 4) Lots of cleanup at the cache sync logic. Now, a pure DVBv5 call
   shouldn't fill the DVBv3 structs. Still, as events are generated,
   the event will dynamically generate a DVBv3 compat struct.

 The emulation logic is not perfect (but it were not perfect before this
 patch series). The emulation will work worse for devices that have
 support for different ops-info.type, as there's no way for a DVBv3
 application to work properly with those devices.

 TODO:

 There are a few things left to do, with regards to DVB frontend cleanup.
 They're more related to the DVBv5 API, so they were out of the scope
 of this series. Maybe some work for this upcoming year!

 They are:

        1) Fix the capabilities flags. There are several capabilities
 not reported, like several modulations, etc. There are not enough flags
 for them. It was suggested that the delivery system (DTV_ENUM_DELSYS)
 would be enough, but it doesn't seem so. For example, there are several
 SYS_ATSC devices that only support VSB_8. So, we'll end by needing to
 either extend the current way (but we lack bits) or to implement a DVBv5
 way for that;


 If an ATSC device supports fewer modulations, things should be
 even simpler. Just return INVALID Frontend setup if it is trying to
 setup something invalid, that which is not supported. Advertising
 the available modulations doesn't help in any sense.
 A53 spec talks about devices supporting 2 modes, Terrestrial
 mode and High data rate mode. It is unlikely and yet maybe
 some devices don't adhere to specifications supporting only
 8VSB, but even in those cases, just returning -EINVAL would be
 sufficient for 16VSB.

 What you suggest, just adds confusion alone to applications as
 to what to do with all the exported fields/flags.

 Returning -EINVAL works from kernel POV, but at least one userpsace
 application developer sent me an email those days complaining that
 applications need to know what are the supported capabilities, in order
 to provide a proper userspace gui.


 FWIW, userapps shouldn't really bother about all the
 hardware details. If user application were to really
 bother about all the tiny intricacies (I can point out
 a large amount of tiny intricacies that which might
 sound pretty, as you are stating) then there wouldn't
 be the need for a driver API -- the application itself
 can contain the driver code. In short, providing too
 much information to application is also not nice.

 The user application should simply set the parameters
 and try to demodulate, return error if it cannot.

 -EINVAL could mean an error on any parameter, not just on
 modulation.

 Having unnecessary fields just causes confusion alone.
 I don't see how providing all the modulations under a
 delivery system can improve a GUI application
 especially when it is according to the specifications.




        2) The DVBv3 events call (FE_GET_EVENT) is not ok for
 newer delivery system. We'll likely need to replace it by a DVBv5 way;



 It should be noted that there is no DVBv5 way, If you are implying
 to replace ioctl calls with a get/set interface, it doesn't make sense
 at all.

 By DVBv5 way, I'm meaning to say that it should be replaced by some way
 that allow reporting events not only for the 4 delivery systems supported
 by DVBv3 API.

 This could be as easy as adding a DTV_GET_EVENT command for FE_GET_PROPERTY.

 Alternatively, events could be reported via a poll() ops at the frontend
 node.


 I am unable to see the advantage in adding a
 new DTV_GET_EVENT call instead of FE_GET_PROPERTY
 improve anything at all.

 Huh? DTV_foo is the name of the properties used by FE_GET_PROPERTY.

 What I'm meaning is that:

        1) in order to have just one ioctl providing both FE status and
           DTV properties, some new properties are needed there (status
           and likely stats);

        2) It makes sense to have something that will only return

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

2012-01-01 Thread Manu Abraham
On Tue, Dec 27, 2011 at 10:36 PM, Mauro Carvalho Chehab
mche...@infradead.org wrote:
 On 27-12-2011 12:33, Andreas Oberritter wrote:
 On 27.12.2011 14:28, Mauro Carvalho Chehab wrote:
 On 27-12-2011 10:11, Andreas Oberritter wrote:
 On 27.12.2011 02:07, Mauro Carvalho Chehab wrote:
 DVB-S and DVB-T, as those were the standards supported by DVBv3.

 The description seems to be incomplete.

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

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

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

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

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

 diff --git a/drivers/media/dvb/dvb-core/dvb_frontend.c 
 b/drivers/media/dvb/dvb-core/dvb_frontend.c
 index 8dedff4..f17c411 100644
 --- a/drivers/media/dvb/dvb-core/dvb_frontend.c
 +++ b/drivers/media/dvb/dvb-core/dvb_frontend.c
 @@ -1252,6 +1252,19 @@ static void dtv_set_default_delivery_caps(const 
 struct dvb_frontend *fe, struct
    const struct dvb_frontend_info *info = fe-ops.info;
    u32 ncaps = 0;

 +  /*
 +   * If the frontend explicitly sets a list, use it, instead of
 +   * filling based on the info-type
 +   */
 +  if (fe-ops.delsys[ncaps]) {
 +          while (fe-ops.delsys[ncaps]  ncaps  MAX_DELSYS) {
 +                  p-u.buffer.data[ncaps] = fe-ops.delsys[ncaps];
 +                  ncaps++;
 +          }
 +          p-u.buffer.len = ncaps;
 +          return;
 +  }
 +

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

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

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

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

 That's right. Still, there's no need to introduce fe-ops.delsys,
 because the drivers in question could just implement get_property
 instead. At least that's what we discussed and AFAIR agreed upon when
 Manu recently submitted his patches regarding enumeration of delivery
 systems.

 Manu's patches were applied (well, except for two patches related to af9013
 driver that are/were under discussion between Manu and Antti).

 Manu's approach is good, as it provided a way to enumerate the
 standards without much changes, offering a way for userspace to
 query the delivery system, at the expense of serializing a driver
 call for each property.

 Yet, it doesn't allow the DVB core to detect the supported
 delivery systems on a sane way [1].

 The addition of fe-ops.delsys is going one step further, as it will
 allow, at the long term, the removal of info.type.

 There are two reasons why we need to get rid of info.type:

 1) dvb_frontend core can be changed to use fe-ops.delsys
   internally, instead of info.type, in order to fix some
   bugs inside it, where it does the wrong assumption, because
   the frontend is lying about the delivery system;


The frontend doesn't lie about the delivery system, but just announces
the delivery system to which the device is initialized by default.



 2) There is no sane way to fill fe-ops.info.type for Multi delivery
   system frontends, like DRX-K, that supports both DVB-T and DVB-C.
   The type can be filled with either FE_QAM or FE_OFDM, not with both.
   So, choosing either type will be plain wrong, and may cause bad
   side effects inside dvb_frontend.


for any multi-standard demodulator, you cannot
announce 2 or more delivery systems as the default
initialized one. Logically, also it doesn't make sense
to announce 2 delivery systems as default. You have
now introduced an ambiguity as to what mode it is
now initialized.

for any multi-standard device, the device is initialized
to only 1 single delivery system and only that should
be announced and available through info.type
for the same reason fe-ops.info.type shouldn't be
filled by anybody else other 

Re: [PATCH 0/9] dvb_frontend: Don't rely on drivers filling ops-info.type

2012-01-01 Thread Manu Abraham
On Mon, Jan 2, 2012 at 1:41 AM, Mauro Carvalho Chehab
mche...@redhat.com wrote:
 This is likely the last patch series from my series of DVB cleanups.
 I still intend to work on DRX-K frontend merge patch, but this will
 need to wait until my return to my home town. Of course, if you're
 hurry with this, patches are welcome.

 This series changes dvb_frontend to use ops-delsys instead of ops-info.type,
 as the source for the frontend support. With this series:

 1) the first delivery system is reported as info.type for DVBv3 apps;
 2) all subsequent checks are made against the current delivery system
   (c-delivery_system);
 3) An attempt to use an un-suported delivery system will either return
   an error, or enter into the emulation mode, if the frontend is
   using a newer delivery system.
 4) Lots of cleanup at the cache sync logic. Now, a pure DVBv5 call
   shouldn't fill the DVBv3 structs. Still, as events are generated,
   the event will dynamically generate a DVBv3 compat struct.

 The emulation logic is not perfect (but it were not perfect before this
 patch series). The emulation will work worse for devices that have
 support for different ops-info.type, as there's no way for a DVBv3
 application to work properly with those devices.

 TODO:

 There are a few things left to do, with regards to DVB frontend cleanup.
 They're more related to the DVBv5 API, so they were out of the scope
 of this series. Maybe some work for this upcoming year!

 They are:

        1) Fix the capabilities flags. There are several capabilities
 not reported, like several modulations, etc. There are not enough flags
 for them. It was suggested that the delivery system (DTV_ENUM_DELSYS)
 would be enough, but it doesn't seem so. For example, there are several
 SYS_ATSC devices that only support VSB_8. So, we'll end by needing to
 either extend the current way (but we lack bits) or to implement a DVBv5
 way for that;


If an ATSC device supports fewer modulations, things should be
even simpler. Just return INVALID Frontend setup if it is trying to
setup something invalid, that which is not supported. Advertising
the available modulations doesn't help in any sense.
A53 spec talks about devices supporting 2 modes, Terrestrial
mode and High data rate mode. It is unlikely and yet maybe
some devices don't adhere to specifications supporting only
8VSB, but even in those cases, just returning -EINVAL would be
sufficient for 16VSB.

What you suggest, just adds confusion alone to applications as
to what to do with all the exported fields/flags.


        2) The DVBv3 events call (FE_GET_EVENT) is not ok for
 newer delivery system. We'll likely need to replace it by a DVBv5 way;



It should be noted that there is no DVBv5 way, If you are implying
to replace ioctl calls with a get/set interface, it doesn't make sense
at all.


        3) The stats API needs to be extended. Delivery systems like
 ISDB can report a per-layer set of statistics. This is currently not
 supported. Also, it is desirable to get the stats together with a
 set of other properties.


The per layer statistics is a myth and can be ignored. Each of the
layers are much higher above and simply RF/demodulation
parameters don't exist/layer; Even if you argue that they do exist,
it would be exactly sufficient to read stats after setting up the
relevant layer for filtering (since you cannot read demodulation
statistics, without setting up proper demodulation parameters).
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: v4 [PATCH 09/10] CXD2820r: Query DVB frontend delivery capabilities

2011-12-12 Thread Manu Abraham
On Mon, Dec 12, 2011 at 6:13 PM, Andreas Oberritter o...@linuxtv.org wrote:
 On 12.12.2011 05:28, Manu Abraham wrote:
 On Sat, Dec 10, 2011 at 5:17 PM, Antti Palosaari cr...@iki.fi wrote:
 On 12/10/2011 06:44 AM, Manu Abraham wrote:

  static int cxd2820r_set_frontend(struct dvb_frontend *fe,

 [...]

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


 +               ret = cxd2820r_set_frontend_t(fe, p);



 Anyhow, I don't now like idea you have put .init() calls to .set_frontend().
 Could you move .init() happen in .init() callback as it was earlier?

 This was there in the earlier patch as well. Maybe you have a
 new issue now ? ;-)

 ok.

 The argument what you make doesn't hold well, Why ?

 int cxd2820r_init_t(struct dvb_frontend *fe)
 {
       ret = cxd2820r_wr_reg(priv, 0x00085, 0x07);
 }


 int cxd2820r_init_c(struct dvb_frontend *fe)
 {
       ret = cxd2820r_wr_reg(priv, 0x00085, 0x07);
 }


 Now, you might like to point that, the Base I2C address location
 is different comparing DVB-T/DVBT2 to DVB-C

 So, If you have the init as in earlier with a common init, then you
 will likely init the wrong device at .init(), as init is called open().
 So, this might result in an additional register write, which could
 be avoided altogether.  One register access is not definitely
 something to brag about, but is definitely a small incremental
 difference. Other than that this register write doesn't do anything
 more than an ADC_START. So starting the ADC at init doesn't
 make sense. But does so when you want to select the right ADC.
 So definitely, this change is an improvement. Also, you can
 compare the time taken for the device to tune now. It is quite
 a lot faster compared to without this patch. So you or any other
 user should be happy. :-)


 I don't think that in any way, the init should be used at init as
 you say, which sounds pretty much incorrect.

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


On another tangential thought, Is it really worth to wrap that single
register write with another function name ?

instead of the current usage; ie,

ret = cxd2820r_wr_reg(priv, 0x00085, 0x07); /* Start ADC */

within set_frontend()

in set_frontend(), another thing that's wrapped up similarly is
the set_frontend() within the search() callback, which causes
another set of confusions within the driver.


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


Re: v4 [PATCH 06/10] DVB: Use a unique delivery system identifier for DVBC_ANNEX_C

2011-12-12 Thread Manu Abraham
On Mon, Dec 12, 2011 at 6:49 PM, Mauro Carvalho Chehab
mche...@redhat.com wrote:
 On 12-12-2011 01:59, Manu Abraham wrote:

 On Sat, Dec 10, 2011 at 5:59 PM, Mauro Carvalho Chehab
 mche...@redhat.com  wrote:

 On 10-12-2011 02:43, Manu Abraham wrote:


  From 92a79a1e0a1b5403f06f60661f00ede365b10108 Mon Sep 17 00:00:00 2001
 From: Manu Abrahamabraham.m...@gmail.com
 Date: Thu, 24 Nov 2011 17:09:09 +0530
 Subject: [PATCH 06/10] DVB: Use a unique delivery system identifier for
 DVBC_ANNEX_C,
  just like any other. DVBC_ANNEX_A and DVBC_ANNEX_C have slightly
  different parameters and used in 2 geographically different
  locations.

 Signed-off-by: Manu Abrahamabraham.m...@gmail.com
 ---
  include/linux/dvb/frontend.h |    7 ++-
  1 files changed, 6 insertions(+), 1 deletions(-)

 diff --git a/include/linux/dvb/frontend.h b/include/linux/dvb/frontend.h
 index f80b863..a3c7623 100644
 --- a/include/linux/dvb/frontend.h
 +++ b/include/linux/dvb/frontend.h
 @@ -335,7 +335,7 @@ typedef enum fe_rolloff {

  typedef enum fe_delivery_system {
        SYS_UNDEFINED,
 -       SYS_DVBC_ANNEX_AC,
 +       SYS_DVBC_ANNEX_A,
        SYS_DVBC_ANNEX_B,
        SYS_DVBT,
        SYS_DSS,
 @@ -352,8 +352,13 @@ typedef enum fe_delivery_system {
        SYS_DAB,
        SYS_DVBT2,
        SYS_TURBO,
 +       SYS_DVBC_ANNEX_C,
  } fe_delivery_system_t;

 +
 +#define SYS_DVBC_ANNEX_AC      SYS_DVBC_ANNEX_A
 +
 +
  struct dtv_cmds_h {
        char    *name;          /* A display name for debugging purposes
 */



 This patch conflicts with the approach given by this patch:


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

 merged as commit 39ce61a846c8e1fa00cb57ad5af021542e6e8403.


 - For correct delivery system handling, the delivery system identifier
 should be unique. Otherwise patch 01/10 is meaningless for devices
 with DVBC_ANNEX_C, facing the same situations.


 This is a good point.


 - Rolloff is provided only in the SI table and is not known prior to a
 tune. So users must struggle to find the correct rolloff. So users
 must know beforehand their experience what rolloff it is rather than
 reading Service Information, which is broken by approach. It is much
 easier for a user to state that he is living in Japan or some other
 place which is using ANNEX_C, rather than creating confusion that
 he has to use DVBC and rolloff of 0.15


 Userspace can present it as Japan and hide the technical details. Most
 applications do that already: kaffeine, w_scan, ...

 The dvb-apps utils don't do it, but the scan file format it produces
 doesn't support anything besides DVB-C/DVB-S/DVB-T/ATSC anyway.


 or is it multiplied by a factor
 of 10 or was it 100 ? (Oh, my god my application Y uses a factor
 of 10, the X application uses 100 and the Z application uses 1000).
 What a lovely confusing scenario. ;-) (Other than for the mentioned
 issue that the rolloff can be read from the SI, which is available after
 tuning; for tuning you need rolloff).


 Sorry, but this argument doesn't make any sense to me. The same problem
 exists on DVB-S2 already, where several rolloffs are supported. Except
 if someone would code a channels.conf line in hand, the roll-off is not
 visible by the end user.



DVB-S2 as what we see as broadcast has just a single rolloff. The same
rolloff is used in the SI alone. It's a mistake to handle rollolff as a user
input field. The other rolloff's are used for very specific applications,
such as DSNG, DVB-RCS etc, where bandwidth has to be really
conserved considering uplinks from trucks, vans etc; for which we don't
even have applications or users.




 Really sexy setup indeed. ;-)

 One thing that I should warn/mention to you is the lack of clarity on
 what you say. You say that you want more discussion, but you
 whack in patches which is never discussed, breaking many logical
 concepts and ideas and broken by nature. How do you justify
 yourself ? I don't think you can justify yourself.


 If we have a consensus around your approach, I'm OK to move for it,
 provided that it doesn't cause regressions upstream.

 As I said, this requires reviewing all DVB frontends to be sure that
 they won't break, especially if is there any that it is capable of
 auto-detecting the roll-off factor.

 Both approaches have advantages and disadvantages.

 The main advantage of my approach is that it is coherent with the current
 DVBv5 API (e. g. SYS_DVBC_ANNEX_AC). So, the only changes are at the
 frontends that need to decide between Annex A and Annex C (currently, only
 drx-k - and the tuners used with it).

 Advantages on your approach:
        - Cleaner for the userspace API;
        - It is possible to add Annex C only devices.
 Disadvantages:
        - Need to deprecate the existing SYS_DVBC_ANNEX_AC;
        - The alias that SYS_DVBC_ANNEX_AC means only SYS_DVBC_ANNEX_A might
          break some thing;
        - Requires further changes at the DocBook API description;
        - Need

Re: v4 [PATCH 09/10] CXD2820r: Query DVB frontend delivery capabilities

2011-12-12 Thread Manu Abraham
On Mon, Dec 12, 2011 at 7:11 PM, Antti Palosaari cr...@iki.fi wrote:
 On 12/12/2011 02:55 PM, Manu Abraham wrote:

 On Mon, Dec 12, 2011 at 6:13 PM, Andreas Oberrittero...@linuxtv.org
  wrote:

 On 12.12.2011 05:28, Manu Abraham wrote:

 On Sat, Dec 10, 2011 at 5:17 PM, Antti Palosaaricr...@iki.fi  wrote:

 On 12/10/2011 06:44 AM, Manu Abraham wrote:


  static int cxd2820r_set_frontend(struct dvb_frontend *fe,


 [...]


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



 +               ret = cxd2820r_set_frontend_t(fe, p);




 Anyhow, I don't now like idea you have put .init() calls to
 .set_frontend().
 Could you move .init() happen in .init() callback as it was earlier?


 This was there in the earlier patch as well. Maybe you have a
 new issue now ? ;-)


 You mean I didn't mentioned it when you send first version? Sorry, I didn't
 looked it very carefully since I first meet stuff that was not related whole
 thing, I mean there was that code changing from .set_params() to
 .set_state(). And I stopped reading rest of the patch.




 ok.

 The argument what you make doesn't hold well, Why ?

 int cxd2820r_init_t(struct dvb_frontend *fe)
 {
       ret = cxd2820r_wr_reg(priv, 0x00085, 0x07);
 }


 int cxd2820r_init_c(struct dvb_frontend *fe)
 {
       ret = cxd2820r_wr_reg(priv, 0x00085, 0x07);
 }


 Now, you might like to point that, the Base I2C address location
 is different comparing DVB-T/DVBT2 to DVB-C

 So, If you have the init as in earlier with a common init, then you
 will likely init the wrong device at .init(), as init is called open().
 So, this might result in an additional register write, which could
 be avoided altogether.  One register access is not definitely
 something to brag about, but is definitely a small incremental
 difference. Other than that this register write doesn't do anything
 more than an ADC_START. So starting the ADC at init doesn't
 make sense. But does so when you want to select the right ADC.
 So definitely, this change is an improvement. Also, you can
 compare the time taken for the device to tune now. It is quite
 a lot faster compared to without this patch. So you or any other
 user should be happy. :-)


 I don't think that in any way, the init should be used at init as
 you say, which sounds pretty much incorrect.


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



 On another tangential thought, Is it really worth to wrap that single
 register write with another function name ?

 instead of the current usage; ie,

 ret = cxd2820r_wr_reg(priv, 0x00085, 0x07); /* Start ADC */

 within set_frontend()

 in set_frontend(), another thing that's wrapped up similarly is
 the set_frontend() within the search() callback, which causes
 another set of confusions within the driver.


 Actually there was was a lot more code first but because I ran problems
 selsys needed for T/T2 init was not known at the time .init() was called I
 moved those set_frontend. I left that in a hope I can later fix properly
 adding more stuff back to init.

 That is not functionality issue, it is issue about naming callbacks and what
 is functionality of each callback.
 As for these days it have been in my understanding initialization stuff are
 done in .init() and leave as less as possible code to .set_frontend().
 Leaving set_frontend() handle only tuning requests and reconfigure IF
 control etc. And if you look most demod drivers there is rather similar
 logic used.

 So I would like to ask what is meaning of:
 .attach()
 * create FE
 * no HW init
 * as less as possible HW I/O, mainly reading chip ID and nothing more

Generally it should be simply create a DVB frontend data structure,
if it finds a valid device.

In some clunky cases, the demodulator clock would be from the tuner,
in which case the tuner has to be attached prior to the demod; and
then later on read device details, once clocks are setup.



 .init()
 * do nothing here?
 * download firmware?


init should simply initialize the device in the lowest power
mode, where it is ready to do a tune. (in some cases tuner also
might need an init. In such cases, the tuner_ops.init can be just
called).

 .set_frontend()
 * program tuner
 * init demod?
 * tune demod
 * download firmware?

Ideally set_frontend should just setup the frontend as a whole
(tuner, demod, or maybe more devices) and return status.

In some clunky cases, there could be cases where each tune
needs a firmware download. Maybe this download can be
optimized in some paths. This depends on the device.


 .sleep()
 * put device sleep mode
 * powersave

Yep.



 After all it is just fine for me apply that patch, but I would like to get
 clear idea what is meaning of every single callback we have. And if we
 really end up .init() is not needed and all should be put to .set_frontend()
 when possible it means I have to change all my demod drivers and maybe tuner
 drivers

Re: v4 [PATCH 06/10] DVB: Use a unique delivery system identifier for DVBC_ANNEX_C

2011-12-12 Thread Manu Abraham
On Mon, Dec 12, 2011 at 7:26 PM, Mauro Carvalho Chehab
mche...@redhat.com wrote:
 On 12-12-2011 11:40, Manu Abraham wrote:

 On Mon, Dec 12, 2011 at 6:49 PM, Mauro Carvalho Chehab


 This also means that just doing an alias from FE_QAM and
 SYS_DVBC_ANNEX_AC
 to
 SYS_DVBC_ANNEX_A may break something, as, for most devices,
 SYS_DVBC_ANNEX_AC
 really means both Annex A and C.




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

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

 case DTV_ENUM_DELSYS:
          buffer.data[0] = SYS_DVBC_ANNEX_A;
          buffer.data[1] = SYS_DVBC_ANNEX_C;
          break;


 Sure, but we'll need a logic to handle queries for SYS_DVBC_ANNEX_AC
 anyway, if any of the existing DVB-C drivers is currently prepared to
 support both.

 I'm not concerned with drx-k. The support for both standards are for
 kernel 3.3. So, no backward compatibility is needed here.

 While there is no explicit option, the code for stv0297, stv0367,
 tda10021 and tda10023 drivers are not clear if they support both
 (maybe roll-off might be auto-detected?) or just SYS_DVBC_ANNEX_A.

 That's said, the difference between a 0.15 and a 0.13 rolloff is not big.
 I won't doubt that a demod set to 0.15 rolloff would be capable of working
 (non-optimized) with a 0.13 rolloff.

 What I'm saing is that, if any of the existing drivers currently works
 with both Annex A and Annex C, we'll need something equivalent to:

 if (delsys == SYS_DVBC_ANNEX_AC) {
        int ret = try_annex_a();
        if (ret  0)
                ret = try_annex_c();
 }

 For FE_SET_FRONTEND (and the corresponding v5 logic), in order to avoid
 regressions.


What I was implying:

set_frontend/search()
{
 case SYS_DVBC_ANNEX_A:
  // do whatever you need to do for annex A tuning and return
  break;
 case SYS_DVBC_ANNEX_C:
  // do whatever you need to do for annex C tuning and return
  break;
}


ANNEX_AC is a link to ANNEX_A; We never had any ? users to ANNEX_C, so
that issue might be simple to ignore.
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: v4 [PATCH 06/10] DVB: Use a unique delivery system identifier for DVBC_ANNEX_C

2011-12-12 Thread Manu Abraham
On Mon, Dec 12, 2011 at 9:52 PM, Mauro Carvalho Chehab
mche...@redhat.com wrote:
 On 12-12-2011 13:00, Manu Abraham wrote:

 On Mon, Dec 12, 2011 at 7:26 PM, Mauro Carvalho Chehab
 mche...@redhat.com  wrote:

 On 12-12-2011 11:40, Manu Abraham wrote:


 On Mon, Dec 12, 2011 at 6:49 PM, Mauro Carvalho Chehab



 This also means that just doing an alias from FE_QAM and
 SYS_DVBC_ANNEX_AC
 to
 SYS_DVBC_ANNEX_A may break something, as, for most devices,
 SYS_DVBC_ANNEX_AC
 really means both Annex A and C.





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

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

 case DTV_ENUM_DELSYS:
          buffer.data[0] = SYS_DVBC_ANNEX_A;
          buffer.data[1] = SYS_DVBC_ANNEX_C;
          break;



 Sure, but we'll need a logic to handle queries for SYS_DVBC_ANNEX_AC
 anyway, if any of the existing DVB-C drivers is currently prepared to
 support both.

 I'm not concerned with drx-k. The support for both standards are for
 kernel 3.3. So, no backward compatibility is needed here.

 While there is no explicit option, the code for stv0297, stv0367,
 tda10021 and tda10023 drivers are not clear if they support both
 (maybe roll-off might be auto-detected?) or just SYS_DVBC_ANNEX_A.

 That's said, the difference between a 0.15 and a 0.13 rolloff is not big.
 I won't doubt that a demod set to 0.15 rolloff would be capable of
 working
 (non-optimized) with a 0.13 rolloff.

 What I'm saing is that, if any of the existing drivers currently works
 with both Annex A and Annex C, we'll need something equivalent to:

 if (delsys == SYS_DVBC_ANNEX_AC) {
        int ret = try_annex_a();
        if (ret  0)
                ret = try_annex_c();
 }

 For FE_SET_FRONTEND (and the corresponding v5 logic), in order to avoid
 regressions.



 What I was implying:

 set_frontend/search()
 {
      case SYS_DVBC_ANNEX_A:
               // do whatever you need to do for annex A tuning and return
               break;
      case SYS_DVBC_ANNEX_C:
               // do whatever you need to do for annex C tuning and return
               break;
 }


 ANNEX_AC is a link to ANNEX_A;


 Yes, I saw your approach.


 We never had any ? users to ANNEX_C, so
 that issue might be simple to ignore.


 This is hard to say. What I'm saying is that, if any of the current
 drivers works as-is with Annex C, we should assume that someone is using,
 as we don't have any evidence otherwise.

 I'm sure there are lots of people running Linux in Japan.

 How many of them are using the DVB subsystem is hard to say. The low message
 traffic at the ML for people *.jp is not a good measure, as due to language
 barriers, people may not be posting things there.

 A quick grep here on my local copy of the ML traffic (it currently has
 stored
 about 380 days of email, as I moved the older ones to a separate storage
 space)
 still shows 90 messages that has .jp inside:

 $ grep -l \.jp * |wc -l
     90

 41 of them has the word DVB inside. Ok, there are some false positives there
 too (due to *.jpg), but there are some valid hits also,

 Including a commit on this changeset:
 e38030f3ff02684eb9e25e983a03ad318a10a2ea.
 As the cx23885 driver does support DVB-C with stv0367, maybe the committer
 might be using it for DVB-C.

 Even if not, I suspect that it is likely to have some DVB-C Annex C users
 out there.


As far as I am aware, most of the services use BCAS2 encryption. There
is no BCAS2 support available as Open Source, other than with sundtek.


Regards,
Manu
--
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


  1   2   3   4   >