Re: AverMedia HD Duet (White Box) A188WB drivers
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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?
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
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
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
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
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
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
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
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)
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
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()
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)
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)
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)
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
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
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
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
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
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
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
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
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
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
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)
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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)
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
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
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
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
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
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
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
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
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)
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
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?
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
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)
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
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
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
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
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
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
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()
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
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
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 1/3] stv090x: Fix typo in register macros
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
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
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
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
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.
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
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
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
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
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
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
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
Re: v4 [PATCH 06/10] DVB: Use a unique delivery system identifier for DVBC_ANNEX_C
On Tue, Dec 13, 2011 at 1:09 AM, Thomas Kernen tker...@deckpoint.ch wrote: On 12/12/11 2:40 PM, Manu Abraham wrote: 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. AFAIK there is at least one card (TBS 6925) that is supporting DVB-S2 applications aimed normally at contribution markets and whereby the rolloff may need to be specified. As far as I am aware, that card uses a STV0900 or a 903, more likely it is a STV0903 being a single input device. The STV0900/903 chips are capable of auto detecting the rolloff. All it needs is frequency and symbol rate. Even if it is another different demodulator: All the devices that I have seen which support the advanced MODCOD's, they support auto detection of rolloff. AFAIK, this is readable of the BBHEADER: MATYPE1, represented by 2 bits, as specified as in the DVB-S2 specification. There are other fields along with such as Single/Multiple Input Streams etc. Therefore no user intervention is required to determine rolloff on such devices. (It is read directly off the BBHEADER by the demod) and is available to 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
