Re: [PATCH] Fix possible memory leak in dvbca.c
On Tue, Jul 27, 2010 at 6:28 PM, Tomer Barletz barl...@gmail.com wrote: 2010/7/25 Tomer Barletz barl...@gmail.com: Allocated memory will never get free when read fails. See attached patch. Tomer Attached a better patch... :) Ok, thanks. Will apply. 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: How to handle independent CA devices
Hi Ralph, On Wed, Sep 15, 2010 at 5:26 AM, rjkm r...@metzlerbros.de wrote: Hi Johannes, Johannes Stezenbach writes: So, I would like to hear your opinions about how to handle such CA devices regarding device names/types, the DVB API and user libraries. it looks like there isn't much interest from DVB developers in that topic... I'll try... IMHO there are three sub topics: 1. be compatible with existing applications (I guess this means: feed stream from frontend through CI transparently) 2. create an API which would also work for CI-only devices like this Hauppauge WinTV-CI USB thingy 3. how to switch between these modes? This sec0 device is history (unused and deprecated for years), right? Yes, the former DiSEqC, etc. device. I only use it because it is is unused and I do not have to change anything in dvb-core this way. But trivial to change it or add ci0. How about the following: Rename it to ci0. When ci0 is closed the stream is routed transparently from frontend through CI, if it's opened one needs to read/write the stream from userspace. You still need a mechanism to decide which tuner gets it. First one which opens its own ca device? Sharing the CI (multi-stream decoding) in such an automatic way would also be complicated. I think I will only add such a feature if there is very high demand and rather look into the separate API solution. It would be advantageous, if we do have just a simple input path, where it is not restricted for CA/CI alone. I have some hardware over here, where it has a DMA_TO_DEVICE channel (other than for the SG table), where it can write a TS to any post-processor connected to it, such as a CA/CI device, or even a decoder, for example. In short, it could be anything, to put short. In this case, the device can accept processed stream (muxed TS for multi-TP TS) for CA, or a single TS/PS for decode on a decoder. You can flip some registers for the device, for it to read from userspace, or for that DMA channel to read from the hardware page tables of another DMA channel which is coming from the tuner. Maybe, we just need a simple mechanism/ioctl to select the CA/CI input for the stream to the bridge. ie like a MUX: a 1:n select per adapter, where the CA/CI device has 1 input and there are 'n' sources. 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: How to handle independent CA devices
On Sat, Sep 18, 2010 at 6:17 AM, rjkm r...@metzlerbros.de wrote: Manu Abraham writes: You still need a mechanism to decide which tuner gets it. First one which opens its own ca device? Sharing the CI (multi-stream decoding) in such an automatic way would also be complicated. I think I will only add such a feature if there is very high demand and rather look into the separate API solution. It would be advantageous, if we do have just a simple input path, where it is not restricted for CA/CI alone. I have some hardware over here, where it has a DMA_TO_DEVICE channel (other than for the SG table), where it can write a TS to any post-processor connected to it, such as a CA/CI device, or even a decoder, for example. In short, it could be anything, to put short. In this case, the device can accept processed stream (muxed TS for multi-TP TS) for CA, or a single TS/PS for decode on a decoder. You can flip some registers for the device, for it to read from userspace, or for that DMA channel to read from the hardware page tables of another DMA channel which is coming from the tuner. Maybe, we just need a simple mechanism/ioctl to select the CA/CI input for the stream to the bridge. ie like a MUX: a 1:n select per adapter, where the CA/CI device has 1 input and there are 'n' sources. It would be nice to have a more general output device. But I have currently no plans to support something like transparent streaming from one input to the output and back inside the driver. Maybe it wasn't very clear ... (Streaming from one input to the output and back inside the driver what you are implementing is not what I had in mind.) Currently for any independant CA device what you need is a stream to the bridge where it can route the same to the CI slot. For a generic device capable of doing any other gimmicks also, what you need is an input to the bridge. So, what I was trying to say is that, let's not limit the input path to CA alone. For explanation sale let's term in as TS_IN The TS_In interface is a simple interface where an application can just write to the TS_IN interface, which goes to the DVB_ringbuffer and hence to the bridge. I think, this is all what it should do. We have 3 application uses cases here, based on different hardware types. 1. Bridge is reading from TS_IN (from a user space application, streams from a single TS) for sending stream to CA, the normal way (All things are fine) 2. Bridge is reading from TS_IN (from a user space application, streams from multiple TS's) for sending to CA. This is also same as (1) but just that the user space application is writing a remuxed stream to TS_IN 3. Bridge is reading from TS_IN (from a userspace application) The bridge has multiple DMA channels. The bridge driver can load page tables from another channel, whereby the bridge is routing to another interface itself completely. This is a hardware feature, so we don't need to get data manually in software from one interface to the other. All this just needs the input path to be generic. An input interface such as TS_IN can feed the stream to an onboard decoder or any other post-processor as described with (3) Only in the case of (2) the application really needs to do some thing in real life, ie to Remux. But you can omit out the application to handle (2). Where somebody can implement it any later stage of time, if there's any interest. I guess nGene can do (1) and (2) So, I wonder whether we should name the interface CA itself, where otherwise it can suit other application use cases as well. In such a case it becomes not limited to CA alone, to put short. Implementing a simple buffering alone (the rest of the necessities with the driver), will make the interface generic. 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
hg pull http://202.88.242.108:8000/hg/var/www/hg/v4l-dvb/
Mauro, Please pull from http://202.88.242.108:8000/hg/var/www/hg/v4l-dvb/ for the following changes. changeset 15168:baa4e8008db5 Mantis, hopper: use MODULE_DEVICE_TABLE http://202.88.242.108:8000/hg/var/www/hg/v4l-dvb/rev/baa4e8008db5 changeset 15169:f04605948fdc Mantis: append tasklet maintenance for DVB stream delivery http://202.88.242.108:8000/hg/var/www/hg/v4l-dvb/rev/f04605948fdc changeset 15170:ee7a63d70f94 Mantis: use dvb_attach to avoid double dereferencing on module removal http://202.88.242.108:8000/hg/var/www/hg/v4l-dvb/rev/ee7a63d70f94 changeset 15171:3a2ece3bf184 Mantis: Rename gpio_set_bits to mantis_gpio_set_bits http://202.88.242.108:8000/hg/var/www/hg/v4l-dvb/rev/3a2ece3bf184 changeset 15172:56c20de4f697 stb6100: Improve tuner performance http://202.88.242.108:8000/hg/var/www/hg/v4l-dvb/rev/56c20de4f697 changeset 15173:5cc010e3a803 stb0899: fix diseqc messages getting lost http://202.88.242.108:8000/hg/var/www/hg/v4l-dvb/rev/5cc010e3a803 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] USALS support for TechniSat SkyStar HD/TechnoTrend TT-Budget S2-3200
Hi, On Mon, Nov 8, 2010 at 2:26 AM, xhake...@o2.pl wrote: Hello, I have SkyStar HD card with SG2100 positioner but USALS is not working with vdr and mythtv. I am using gentoo Linux and checked vdr: 1.6,(gotox patch) 1.7.9(vdr-rotor), 1.7.12, 1.7.13, 1.7.14(gotox patch) and mythtv 0.22 with no success. Positioner works good with my old card(bt878). What can I do to help you to solve this problem? Vdr-rotor hangs when entering in rotor menu, with patch it simply does not work. I can move my rotor with xdipo but have no idea how to check usals with it. It is my third whole day(and half of the night) with no success, please help me:( Please try again but from here; http://202.88.242.108:8000/hg/var/www/hg/v4l-dvb/ 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] faster DVB-S lock with cards using stb0899 demod
On Mon, Sep 20, 2010 at 8:03 AM, Emmanuel eall...@gmail.com wrote: SE a écrit : hi list v4l-dvb still lacks fast and reliable dvb-s lock for stb08899 chipsets. Can you please try again from here; http://202.88.242.108:8000/hg/var/www/hg/v4l-dvb/ 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: hg pull http://202.88.242.108:8000/hg/var/www/hg/v4l-dvb/
On Wed, Nov 17, 2010 at 7:48 AM, Mauro Carvalho Chehab mche...@redhat.com wrote: Em 14-11-2010 18:48, Manu Abraham escreveu: Mauro, Please pull from http://202.88.242.108:8000/hg/var/www/hg/v4l-dvb/ for the following changes. changeset 15168:baa4e8008db5 Mantis, hopper: use MODULE_DEVICE_TABLE http://202.88.242.108:8000/hg/var/www/hg/v4l-dvb/rev/baa4e8008db5 changeset 15169:f04605948fdc Mantis: append tasklet maintenance for DVB stream delivery http://202.88.242.108:8000/hg/var/www/hg/v4l-dvb/rev/f04605948fdc changeset 15170:ee7a63d70f94 Mantis: use dvb_attach to avoid double dereferencing on module removal http://202.88.242.108:8000/hg/var/www/hg/v4l-dvb/rev/ee7a63d70f94 changeset 15171:3a2ece3bf184 Mantis: Rename gpio_set_bits to mantis_gpio_set_bits http://202.88.242.108:8000/hg/var/www/hg/v4l-dvb/rev/3a2ece3bf184 changeset 15172:56c20de4f697 stb6100: Improve tuner performance http://202.88.242.108:8000/hg/var/www/hg/v4l-dvb/rev/56c20de4f697 changeset 15173:5cc010e3a803 stb0899: fix diseqc messages getting lost http://202.88.242.108:8000/hg/var/www/hg/v4l-dvb/rev/5cc010e3a803 Applied, thanks. A new warning appeared: drivers/media/dvb/frontends/stb6100.c:120: warning: ‘stb6100_normalise_regs’ defined but not used Can you please enclose the function in a #if 0.since it is not being used. 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: hg pull http://202.88.242.108:8000/hg/var/www/hg/v4l-dvb/
On Mon, Nov 22, 2010 at 9:55 PM, Mauro Carvalho Chehab
mche...@redhat.com wrote:
Em 17-11-2010 10:28, Manu Abraham escreveu:
On Wed, Nov 17, 2010 at 7:48 AM, Mauro Carvalho Chehab
mche...@redhat.com wrote:
Em 14-11-2010 18:48, Manu Abraham escreveu:
Mauro,
Please pull from http://202.88.242.108:8000/hg/var/www/hg/v4l-dvb/
for the following changes.
changeset 15168:baa4e8008db5 Mantis, hopper: use MODULE_DEVICE_TABLE
http://202.88.242.108:8000/hg/var/www/hg/v4l-dvb/rev/baa4e8008db5
changeset 15169:f04605948fdc Mantis: append tasklet maintenance for
DVB stream delivery
http://202.88.242.108:8000/hg/var/www/hg/v4l-dvb/rev/f04605948fdc
changeset 15170:ee7a63d70f94 Mantis: use dvb_attach to avoid double
dereferencing on module removal
http://202.88.242.108:8000/hg/var/www/hg/v4l-dvb/rev/ee7a63d70f94
changeset 15171:3a2ece3bf184 Mantis: Rename gpio_set_bits to
mantis_gpio_set_bits
http://202.88.242.108:8000/hg/var/www/hg/v4l-dvb/rev/3a2ece3bf184
changeset 15172:56c20de4f697 stb6100: Improve tuner performance
http://202.88.242.108:8000/hg/var/www/hg/v4l-dvb/rev/56c20de4f697
changeset 15173:5cc010e3a803 stb0899: fix diseqc messages getting lost
http://202.88.242.108:8000/hg/var/www/hg/v4l-dvb/rev/5cc010e3a803
Applied, thanks.
A new warning appeared:
drivers/media/dvb/frontends/stb6100.c:120: warning:
‘stb6100_normalise_regs’ defined but not used
Can you please enclose the function in a #if 0.since it is not being used.
The enclosed patch should fix the warning.
---
[media] stb6100: warning cleanup
drivers/media/dvb/frontends/stb6100.c:120: warning: ‘stb6100_normalise_regs’
defined but not used
Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com
Acked-by: Manu Abraham m...@linuxtv.org
diff --git a/drivers/media/dvb/frontends/stb6100.c
b/drivers/media/dvb/frontends/stb6100.c
index db66248..64673b8 100644
--- a/drivers/media/dvb/frontends/stb6100.c
+++ b/drivers/media/dvb/frontends/stb6100.c
@@ -117,7 +117,10 @@ static const struct stb6100_regmask stb6100_template[] =
{
[STB6100_TEST3] = { 0x00, 0xde },
};
-static void stb6100_normalise_regs(u8 regs[])
+/*
+ * Currently unused. Some boards might need it in the future
+ */
+static inline void stb6100_normalise_regs(u8 regs[])
{
int i;
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: technisat cablestar hd2, cinergy C pci hd, 2.6.35, no remote (VP2040)
On Wed, Dec 15, 2010 at 4:15 PM, Debarshi Ray debarshi@gmail.com wrote: AFAIR, the code originated from these changesets: http://jusst.de/hg/mantis-v4l-dvb.old/rev/9cb8ffc573a2 http://jusst.de/hg/mantis-v4l-dvb.old/rev/c2391fa88112 later on, it was moved to another repository http://jusst.de/hg/mantis-v4l-dvb/rev/ad8b00c9edc2 But the code in Igor's s2-liplianin tree has evolved further than the one in the mantis-v4l-dvb tree. eg., the keymaps are now split into separate files in drivers/media/IR/keymaps. Is there any Git tree with the latest state of the code or is the s2-liplianin tree the one I am looking for? The latest changes are in here http://202.88.242.108:8000/hg/var/www/hg/v4l-dvb/ the IR related changes are not yet there, after the IR rework. 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: TT-budget S2-3200 cannot tune on HB13E DVBS2 transponder
Mauro, On Wed, Sep 21, 2011 at 10:14 PM, Mauro Carvalho Chehab mche...@redhat.com wrote: Em 04-05-2011 08:27, Lutz Sammer escreveu: On 05/04/11 01:16, Mauro Carvalho Chehab wrote: Em 13-04-2011 21:05, Lutz Sammer escreveu: On 05/04/11 21:07, Steffen Barszus wrote: On Tue, 05 Apr 2011 13:00:14 +0200 Issa Gorissen flop.m@xxx wrote: Hi, Eutelsat made a recent migration from DVB-S to DVB-S2 (since 31/3/2011) on two transponders on HB13E - HOT BIRD 6 13° Est TP 159 Freq 11,681 Ghz DVB-S2 FEC 3/4 27500 Msymb/s 0.2 Pilot off Polar H - HOT BIRD 9 13° Est TP 99 Freq 12,692 Ghz DVB-S2 FEC 3/4 27500 Msymb/s 0.2 Pilot off Polar H Before those changes, with my TT S2 3200, I was able to watch TV on those transponders. Now, I cannot even tune on those transponders. I have tried with scan-s2 and w_scan and the latest drivers from git. They both find the transponders but cannot tune onto it. Something noteworthy is that my other card, a DuoFlex S2 can tune fine on those transponders. My question is; can someone try this as well with a TT S2 3200 and post the results ? i read something about it lately here (german!): http://www.vdr-portal.de/board16-video-disk-recorder/board85-hdtv-dvb-s2/p977938-stb0899-fec-3-4-tester-gesucht/#post977938 It says in stb0899_drv.c function: static void stb0899_set_iterations(struct stb0899_state *state) This: reg = STB0899_READ_S2REG(STB0899_S2DEMOD, MAX_ITER); STB0899_SETFIELD_VAL(MAX_ITERATIONS, reg, iter_scale); stb0899_write_s2reg(state, STB0899_S2DEMOD, STB0899_BASE_MAX_ITER, STB0899_OFF0_MAX_ITER, reg); should be replaced with this: reg = STB0899_READ_S2REG(STB0899_S2FEC, MAX_ITER); STB0899_SETFIELD_VAL(MAX_ITERATIONS, reg, iter_scale); stb0899_write_s2reg(state, STB0899_S2FEC, STB0899_BASE_MAX_ITER, STB0899_OFF0_MAX_ITER, reg); Basically replace STB0899_S2DEMOD with STB0899_S2FEC in this 2 lines affected. Kind Regards Steffen Hi Steffen, Unfortunately, it does not help in my case. Thx anyway. Try my locking fix. With above patch I can lock the channels without problem. Can someone confirm that such patch would fix the issue? If so, please forward it in a way that it could be applied (patch is currently line-wrapped), and submit with some comments/description and your SOB. As the patch is currently broken, I'm just marking it as rejected at patchwork. Manu, Please take a look on this trouble report. Sorry, the things are mixed here. My patch (resend and hopefully this time not broken) handles only DVB-S transponders. The FEC fix patch fixed locking on 11,681 Ghz, but not on 12,692 Ghz for me. But I have very weak receiption, Johns Manu, We're still missing your review on this patch[1], or it were eventually missed. Please review it. Thanks, Mauro [1] http://patchwork.linuxtv.org/patch/6511/ Patch is good and correct. Thanks. Reviewed-by: Manu Abraham m...@linuxtv.org -- To unsubscribe from this list: send the line unsubscribe linux-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 (28 patches)
On Sat, Sep 24, 2011 at 6:04 PM, Mauro Carvalho Chehab mche...@redhat.com wrote: Everything at patchwork were reviewed by me, and I've applied all patches that I didn't notice any review by the drivers maintainers. Driver maintainers: Please review the remaining patches. == Patches for Manu Abraham abraham.m...@gmail.com review == Jun,11 2010: stb0899: Removed an extra byte sent at init on DiSEqC bus http://patchwork.linuxtv.org/patch/3639 Florent AUDEBERT florent.audeb...@anevia.com A single byte doesn't make much of a difference, but well it is still a difference. The DiSEqC has some known issues and has some tricky workarounds for different Silicon cuts. This patch *might* be good on some chips while have an adverse effect. But that said I have not tested this patch. If general users would like to have this patch and is proven good on different versions, I have no objection for this patch to go in. In which case; Acked-by: Manu Abraham m...@linuxtv.org -- To unsubscribe from this list: send the line unsubscribe linux-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 (28 patches)
On Sat, Sep 24, 2011 at 6:04 PM, Mauro Carvalho Chehab mche...@redhat.com wrote: Everything at patchwork were reviewed by me, and I've applied all patches that I didn't notice any review by the drivers maintainers. Driver maintainers: Please review the remaining patches. == Patches for Manu Abraham abraham.m...@gmail.com review == Aug, 7 2010: Refactor Mantis DMA transfer to deliver 16Kb TS data per interrupt http://patchwork.linuxtv.org/patch/4104 Marko Ristola marko.rist...@kolumbus.fi I did test this patch. It doesn't bring in any side effects in general. It increases the latency, which it is expected. On some PCI-PCI chipset the patch makes the TS handling worser. But in other cases, it looks okay. Reviewed-by: Manu Abraham m...@linuxtv.org -- To unsubscribe from this list: send the line unsubscribe linux-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 (28 patches)
On Sat, Sep 24, 2011 at 6:04 PM, Mauro Carvalho Chehab mche...@redhat.com wrote: Everything at patchwork were reviewed by me, and I've applied all patches that I didn't notice any review by the drivers maintainers. Driver maintainers: Please review the remaining patches. == Patches for Manu Abraham abraham.m...@gmail.com review == May,23 2011: Increase a timeout, so that bad scheduling does not accidentially caus http://patchwork.linuxtv.org/patch/7178 Hans Petter Selasky hsela...@c2i.net Haven't heard timeout issues recently though ... but still; Acked-by: Manu Abraham m...@linuxtv.org -- To unsubscribe from this list: send the line unsubscribe linux-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 (28 patches)
On Sat, Sep 24, 2011 at 6:04 PM, Mauro Carvalho Chehab mche...@redhat.com wrote: Everything at patchwork were reviewed by me, and I've applied all patches that I didn't notice any review by the drivers maintainers. Driver maintainers: Please review the remaining patches. == Patches for Manu Abraham abraham.m...@gmail.com review == Jun, 8 2011: Add remote control support for mantis http://patchwork.linuxtv.org/patch/7217 Christoph Pinkl christoph.pi...@gmail.com Haven't tested this patch. Please hold on with this patch. 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: Status of the patches under review at LMML (28 patches)
On Sat, Sep 24, 2011 at 6:04 PM, Mauro Carvalho Chehab mche...@redhat.com wrote: Everything at patchwork were reviewed by me, and I've applied all patches that I didn't notice any review by the drivers maintainers. Driver maintainers: Please review the remaining patches. == Patches for Manu Abraham abraham.m...@gmail.com review == May,24 2011: Fix the derot zig-zag to work with TT-USB2.0 TechnoTrend. http://patchwork.linuxtv.org/patch/6777 Hans Petter Selasky hsela...@c2i.net Patch doesn't make any sense. -- To unsubscribe from this list: send the line unsubscribe linux-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 (28 patches)
On Sat, Sep 24, 2011 at 6:04 PM, Mauro Carvalho Chehab mche...@redhat.com wrote: Everything at patchwork were reviewed by me, and I've applied all patches that I didn't notice any review by the drivers maintainers. Driver maintainers: Please review the remaining patches. == Patches for Manu Abraham abraham.m...@gmail.com review == Jun, 1 2011: stv090x: set status bits when there is no lock http://patchwork.linuxtv.org/patch/6804 Guy Martin gms...@tuxicoman.be Patch looks okay, but untested at my side. Acked-by: Manu Abraham m...@linuxtv.org -- To unsubscribe from this list: send the line unsubscribe linux-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 v2] stb0899: Fix slow and not locking DVB-S transponder(s)
Mauro,
comments in-line.
On Sat, Oct 1, 2011 at 12:28 AM, Mauro Carvalho Chehab
mche...@redhat.com wrote:
Em 30-09-2011 15:41, Lutz Sammer escreveu:
On 09/30/11 19:07, Mauro Carvalho Chehab wrote:
Em 29-09-2011 18:22, Lutz Sammer escreveu:
Another version of
http://patchwork.linuxtv.org/patch/6307
http://patchwork.linuxtv.org/patch/6510
which was superseded or rejected, but I don't know why.
Probably because of the same reason of this patch [1]:
patch -p1 -i
patches/lmml_8023_v2_stb0899_fix_slow_and_not_locking_dvb_s_transponder_s.patch
--dry-run -t -N
patching file drivers/media/dvb/frontends/stb0899_algo.c
Hunk #1 FAILED at 358.
1 out of 1 hunk FAILED -- saving rejects to file
drivers/media/dvb/frontends/stb0899_algo.c.rej
drivers/media/dvb/frontends/stb0899_algo.c | 1 +
1 file changed, 1 insertion(+)
I'll mark this one as rejected, as it doesn't apply upstream[2].
[1] http://patchwork.linuxtv.org/patch/8023/
[2] at tree/branch: git://linuxtv.org/media_tree.git staging/for_v3.2
Please test if the changes made upstream to solve a similar trouble fixes
your issue.
If not, please rebase your patch on the top of it and resend.
Thanks,
Mauro
In stb0899_status stb0899_check_data the first read of STB0899_VSTATUS
could read old (from previous search) status bits and the search fails
on a good frequency.
With the patch more transponder could be locked and locks about 2* faster.
Manu,
Could you please review this one-line patch?
Signed-off-by: Lutz Sammerjohn...@gmx.net
---
drivers/media/dvb/frontends/stb0899_algo.c | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/drivers/media/dvb/frontends/stb0899_algo.c
b/drivers/media/dvb/frontends/stb0899_algo.c
index d70eee0..8eca419 100644
--- a/drivers/media/dvb/frontends/stb0899_algo.c
+++ b/drivers/media/dvb/frontends/stb0899_algo.c
@@ -358,6 +358,7 @@ static enum stb0899_status stb0899_check_data(struct
stb0899_state *state)
else
dataTime = 500;
+ stb0899_read_reg(state, STB0899_VSTATUS); /* clear old status bits
*/
stb0899_write_reg(state, STB0899_DSTATUS2, 0x00); /* force search
loop */
while (1) {
/* WARNING! VIT LOCKED has to be tested before
VIT_END_LOOOP */
Please add in these comments, in case you want to apply the change. I
am neither for the patch, nor against it.
- In fact, it doesn't hurt to read STATUS just before LOCK test.
- I wasn't able to find any noticeable difference in LOCK acquisition.
- Nowhere, I was able to find that reading VSTATUS, clears the
Read-Only bits set by the onchip microcontroller. The above comment
could be wrong at least, as far as I can say.
But that said, if the change does really help (thinking of strange
issues with some Silicon cuts)
Acked-by: Manu Abraham m...@linuxtv.org
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: [RFC] Merge v4l-utils. dvb-apps and mediactl to media-utils.git
On Thu, Oct 6, 2011 at 5:53 PM, Hans Verkuil hverk...@xs4all.nl wrote: Currently we have three repositories containing libraries and utilities that are relevant to the media drivers: dvb-apps (http://linuxtv.org/hg/dvb-apps/) v4l-utils (http://git.linuxtv.org/v4l-utils.git) media-ctl (git://git.ideasonboard.org/media-ctl.git) It makes no sense to me to have three separate repositories, one still using mercurial and one that isn't even on linuxtv.org. We had a discussion earlier on the same subject wrt dvb-apps and the decision at that time was against a merge. That decision still holds. 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 v2] stb0899: Fix slow and not locking DVB-S transponder(s)
On Fri, Oct 7, 2011 at 10:31 PM, Lutz Sammer john...@gmx.net wrote:
On 10/06/11 20:56, Manu Abraham wrote:
Mauro,
comments in-line.
On Sat, Oct 1, 2011 at 12:28 AM, Mauro Carvalho Chehab
mche...@redhat.com wrote:
Em 30-09-2011 15:41, Lutz Sammer escreveu:
On 09/30/11 19:07, Mauro Carvalho Chehab wrote:
Em 29-09-2011 18:22, Lutz Sammer escreveu:
Another version of
http://patchwork.linuxtv.org/patch/6307
http://patchwork.linuxtv.org/patch/6510
which was superseded or rejected, but I don't know why.
Probably because of the same reason of this patch [1]:
patch -p1 -i
patches/lmml_8023_v2_stb0899_fix_slow_and_not_locking_dvb_s_transponder_s.patch
--dry-run -t -N
patching file drivers/media/dvb/frontends/stb0899_algo.c
Hunk #1 FAILED at 358.
1 out of 1 hunk FAILED -- saving rejects to file
drivers/media/dvb/frontends/stb0899_algo.c.rej
drivers/media/dvb/frontends/stb0899_algo.c | 1 +
1 file changed, 1 insertion(+)
I'll mark this one as rejected, as it doesn't apply upstream[2].
[1] http://patchwork.linuxtv.org/patch/8023/
[2] at tree/branch: git://linuxtv.org/media_tree.git staging/for_v3.2
Please test if the changes made upstream to solve a similar trouble
fixes your issue.
If not, please rebase your patch on the top of it and resend.
Thanks,
Mauro
In stb0899_status stb0899_check_data the first read of STB0899_VSTATUS
could read old (from previous search) status bits and the search fails
on a good frequency.
With the patch more transponder could be locked and locks about 2*
faster.
Manu,
Could you please review this one-line patch?
Signed-off-by: Lutz Sammerjohn...@gmx.net
---
drivers/media/dvb/frontends/stb0899_algo.c | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/drivers/media/dvb/frontends/stb0899_algo.c
b/drivers/media/dvb/frontends/stb0899_algo.c
index d70eee0..8eca419 100644
--- a/drivers/media/dvb/frontends/stb0899_algo.c
+++ b/drivers/media/dvb/frontends/stb0899_algo.c
@@ -358,6 +358,7 @@ static enum stb0899_status
stb0899_check_data(struct stb0899_state *state)
else
dataTime = 500;
+ stb0899_read_reg(state, STB0899_VSTATUS); /* clear old status
bits */
stb0899_write_reg(state, STB0899_DSTATUS2, 0x00); /* force
search loop */
while (1) {
/* WARNING! VIT LOCKED has to be tested before
VIT_END_LOOOP */
Please add in these comments, in case you want to apply the change. I
am neither for the patch, nor against it.
- In fact, it doesn't hurt to read STATUS just before LOCK test.
- I wasn't able to find any noticeable difference in LOCK acquisition.
- Nowhere, I was able to find that reading VSTATUS, clears the
Read-Only bits set by the onchip microcontroller. The above comment
could be wrong at least, as far as I can say.
But that said, if the change does really help (thinking of strange
issues with some Silicon cuts)
Acked-by: Manu Abrahamm...@linuxtv.org
Regards,
Manu
To be exact only the loop bit is reset by the read:
kernel: [62791.427869] stb0899: vstatus 40 00 40 00
kernel: [62791.597609] stb0899: vstatus 00 00 18 18
Printed twice before and after the loop. I tested this with the
tt-3600 and tt-3650.
Ok, reading VSTATUS might force the VIT_END_LOOP to be refreshed
(cached copy) in some cases where it probably never cleared due to
some internal error. In fact, actually it should be automatically be
cleared, surprised that it didn't.
Can you please adjust the comment to state: Clear previous failed END_LOOPVIT ?
Mauro,
The following patch can be applied, with a modified comment similar to
the above.
Reviewed-by: Manu Abraham m...@linuxtv.org
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: [RFC] Merge v4l-utils. dvb-apps and mediactl to media-utils.git
On Sat, Oct 8, 2011 at 5:42 PM, Mauro Carvalho Chehab mche...@redhat.com wrote: Em 07-10-2011 15:08, Manu Abraham escreveu: On Thu, Oct 6, 2011 at 5:53 PM, Hans Verkuilhverk...@xs4all.nl wrote: Currently we have three repositories containing libraries and utilities that are relevant to the media drivers: dvb-apps (http://linuxtv.org/hg/dvb-apps/) v4l-utils (http://git.linuxtv.org/v4l-utils.git) media-ctl (git://git.ideasonboard.org/media-ctl.git) It makes no sense to me to have three separate repositories, one still using mercurial and one that isn't even on linuxtv.org. We had a discussion earlier on the same subject wrt dvb-apps and the decision at that time was against a merge. That decision still holds. Yes, years ago when v4l-utils tree were created. Since them, there was several major releases of it, and not a single release of dvb-apps, with, btw, still lacks proper support for DVB APIv5. So, why not discuss it again? - dvb-apps is a repository consisting of simple stand-alone utils, basically meant for raw tests alone. (these tiny test apps don't have any external dependencies, so there exists no issues regarding packaging. for such a development model, a merge with a repository having other dependencies, this merge concept doesn't work well) In fact your own example repository with --disable this --enable that implies that, one needs to download the whole thing, altogether. I don't need to download things that's irrelevant to me. - a repository and how it works depends on the people working with it. (It depends on the comfortability of the people working with/maintaining it. It was found that the existing model works well and needs no change) - just simply making a release number, doesn't make a new release. (That said, a release is very near) - I don't see any significant contributions either from Hans V, the proposer for the merger of dvb-apps, or from you. - API v5 is severely broken in many senses and unusable in the way it is supposed to be used, it is still worked around using the v3 API (I will address this broken issue and try to have a fix in another mail) -- To unsubscribe from this list: send the line unsubscribe linux-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] dabusb: Move it to staging to be deprecated
On Wed, Dec 29, 2010 at 4:07 PM, Hans Verkuil hverk...@xs4all.nl wrote: On Tuesday, December 28, 2010 20:10:17 Felipe Sanches wrote: Wait! It supports the DRBox1 DAB sold by Terratec: http://www.baycom.de/wiki/index.php/Products::dabusbhw No, it doesn't. The driver in the kernel only supports the prototype board. The driver on baycom.de *does* support the Terratec product, but that's not in the kernel. I've been working on a free firmware for this device: http://libreplanet.org/wiki/LinuxLibre:USB_DABUSB I don't mind having support for DAB in the kernel, but any DAB API needs to be properly discussed, designed and documented. And it should probably be a part of the V4L2 API (since that already supports analog radio and RDS). By removing this driver from the kernel we open the way for a new DAB API without breaking support for any existing end-users since the current driver doesn't support any sold products. Frankly, I'm quite interested to see support for this and I'd be happy to work with someone on designing an API for it. Sounds interesting :-) Quite unlikely that you need to design a new API for it. The ETSI DAB page says: DAB system specifications Digital Audio Broadcasting (DAB) uses Orthogonal Frequency Division Multiplexing (OFDM) offering superior sound quality ... ETSI is working with the WorldDAB Forum to develop standards for DMB: these include the DMB Video Service (video carried by DAB) and MPEG-2 Transport streaming. now TS102427 states: The DAB system EN 300 401 [1] defines the way that audio (programme) and data services may be carried. However, in MSC stream mode, the error protection scheme is optimised for audio services. Data services carried in stream mode (for example video services) require additional error protection and this can be achieved by applying an outer coding to the data packets before insertion into a DAB MSC stream mode sub-channel. In order to provide as much commonality in transmission and reception equipment as possible, the outer coding is taken directly from DVB-T EN 300 744 [2], The system is defined as a functional block that performs the addition of outer coding (Reed-Solomon code) and outer interleaving (convolutional interleaving). This functional block sits between the output of the MPEG-2 transport multiplexer and the input to a stream sub-channel of a DAB multiplexer, 5 Error Protection for DAB MSC stream data sub-channels and transport packets of 188 bytes 5.1 General considerations Each input transport packet is 188 bytes long and starts with a synchronizing byte of value 0x47. The transport packet may contain any data. See ISO/IEC 13818 [3] for more details of the format of transport packets. 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: Patches an media build tree
Hi Steffen, On Sat, Mar 5, 2011 at 9:13 PM, Steffen Barszus steffenbpu...@googlemail.com wrote: On Sun, 16 Jan 2011 16:37:38 -0200 Mauro Carvalho Chehab mche...@redhat.com wrote: Em 15-01-2011 11:46, Helmut Auer escreveu: Hello List How long does it usually take til patches are integrated into the media build tree ( after posting these here ) ? I'm just wondering because I miss some patches posted here. It takes as much it needs for the driver maintainer to look into it, and for me to have time to handle them. The pending patches are always at: https://patchwork.kernel.org/project/linux-media/list/ Please note that, by default, Patchwork filters the patches to display only the ones marked as New or Under Review. If you want to see all patches, you need to change the state filter to show all patches: https://patchwork.kernel.org/project/linux-media/list/?state=* If the patch you're waiting are marked as Under Review, you should ping the driver maintainer, as I'm waiting for his review. If it is new, that means that I didn't have time yet to dig into it. Can you please check these patches ? What is missing ? Something to be corrected ? What happens to orphaned drivers ? Manu are you still working on this ? Manu , Mauro please comment ! Thanks ! Avoid unnecessary data copying inside dvb_dmx_swfilter_204() function 2010-08-07 Marko Ristola Under Review Refactor Mantis DMA transfer to deliver 16Kb TS data per interrupt 2010-08-07 Marko Ristola Under Review I had tried this patch a while back, but due to some reason it was causing a complete freeze at my side: it could have been due to a different version of the bridge or so, But it wasn't really easy on my side to ascertain that. That time looking at the patch it wasn't easy to identify the reason as well. I need to retry the same again, with a cooler head as to see what happens. [v2] V4L/DVB: faster DVB-S lock for mantis cards using stb0899 demod 2010-10-10 Tuxoholic Under Review I was under the assumption that this issue was fixed in the right way, with the fix being applied to the stb6100 driver sometime back. Was your test with that fix in ? 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: S2-3200 switching-timeouts on 2.6.38
Hello Rico, On Tue, Mar 22, 2011 at 5:03 PM, Rico Tzschichholz ric...@t-online.de wrote: Hello Manu, Actually, quite a lot of effort was put in to get that part right. It does the reverse thing that's to be done. The revamped version is here [1] If the issue persists still, then it needs to be investigated further. [1] http://www.mail-archive.com/linuxtv-commits@linuxtv.org/msg09214.html I am not sure how this is related to stb6100? Does that mean the current stb0899 patch [2] isnt ready to be proposed for 2.6.39 yet? Or does the stb6100 patch has a better design to solve this issue which should be adapted for stb0899 then? I was hoping to see it included before the merge window is closed again. [2] https://patchwork.kernel.org/patch/244201/ stb0899 is a channel decoder (or demodulator in other words) while the stb6100 is a tuner which provides I-Q components to the demod. When a tuner locks to a transponder, in the spectrum in the absence of a signal, it will be contain White (Gaussian) noise. In such a case the demod has a hard time to lock to the signal. In this particular case, we had a bit of luck additionally, ie we found a case where the stb0899 demodulator functioned perfectly well with another tuner, but with the same hardware configuration. This helped in narrowing the bug to the tuner and hence the fix. The one in patchwork, does modify the step size but that doesn't reduce the white noise, which is something like a lucky dip. (similar to what Bjorn pointed out in another post.) I am not really sure whether modifying the step size of any benefit/disadvantage, but need to do some research on that aspect. 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] mantis: trivial module parameter documentation fix
2011/3/22 Bjørn Mork bj...@mork.no: The default for verbose is 0. Update description to match. Signed-off-by: Bjørn Mork bj...@mork.no --- drivers/media/dvb/mantis/hopper_cards.c | 2 +- drivers/media/dvb/mantis/mantis_cards.c | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/media/dvb/mantis/hopper_cards.c b/drivers/media/dvb/mantis/hopper_cards.c index 70e73af..1402062 100644 --- a/drivers/media/dvb/mantis/hopper_cards.c +++ b/drivers/media/dvb/mantis/hopper_cards.c @@ -44,7 +44,7 @@ static unsigned int verbose; module_param(verbose, int, 0644); -MODULE_PARM_DESC(verbose, verbose startup messages, default is 1 (yes)); +MODULE_PARM_DESC(verbose, verbose startup messages, default is 0 (no)); #define DRIVER_NAME Hopper diff --git a/drivers/media/dvb/mantis/mantis_cards.c b/drivers/media/dvb/mantis/mantis_cards.c index 40da225..05cbb9d 100644 --- a/drivers/media/dvb/mantis/mantis_cards.c +++ b/drivers/media/dvb/mantis/mantis_cards.c @@ -52,7 +52,7 @@ static unsigned int verbose; module_param(verbose, int, 0644); -MODULE_PARM_DESC(verbose, verbose startup messages, default is 1 (yes)); +MODULE_PARM_DESC(verbose, verbose startup messages, default is 0 (no)); static int devs; -- 1.7.2.5 -- Thanks. Acked-by: Manu Abraham m...@linuxtv.org -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: S2-3200 switching-timeouts on 2.6.38
On Fri, Mar 25, 2011 at 8:31 PM, Paul Franke paul.fra...@uni-rostock.de wrote: Hi list, Follow up to: [1] I did testing with a TechniSat SkyStar HD 2 (1ae4:0003). - without a patch: card unuseable, gets locks only rarely - with Manu's patch: card useable, gets locks, but sometimes this still needs some seconds - with the mentioned stb0899 patch: card useable, gets locks, most time or nearly always fast (and faster as with Manu's patch) In practice the stb0899 patch does a better job for zap frenzies, so I kindly ask to include this patch. Can you guys, (who seem to really need the said patch) please provide me the STB0899 chipset version on your card ? For eg: what I have here 3 different silicon versions C6L STB0899 VQ940KDA12 22 9BS VQ MLT 22 012 C2L STB0899 VQ636DSK22 09C VQ MLT 22 656 C1L STB0899 VQ608FSD22 OPD VQ MLT 22 628 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: TT-budget S2-3200 cannot tune on HB13E DVBS2 transponder
On Wed, May 4, 2011 at 3:16 AM, Mauro Carvalho Chehab mche...@redhat.com wrote: Em 13-04-2011 21:05, Lutz Sammer escreveu: On 05/04/11 21:07, Steffen Barszus wrote: On Tue, 05 Apr 2011 13:00:14 +0200 Issa Gorissen flop.m@xxx wrote: Hi, Eutelsat made a recent migration from DVB-S to DVB-S2 (since 31/3/2011) on two transponders on HB13E - HOT BIRD 6 13° Est TP 159 Freq 11,681 Ghz DVB-S2 FEC 3/4 27500 Msymb/s 0.2 Pilot off Polar H - HOT BIRD 9 13° Est TP 99 Freq 12,692 Ghz DVB-S2 FEC 3/4 27500 Msymb/s 0.2 Pilot off Polar H Before those changes, with my TT S2 3200, I was able to watch TV on those transponders. Now, I cannot even tune on those transponders. I have tried with scan-s2 and w_scan and the latest drivers from git. They both find the transponders but cannot tune onto it. Something noteworthy is that my other card, a DuoFlex S2 can tune fine on those transponders. My question is; can someone try this as well with a TT S2 3200 and post the results ? i read something about it lately here (german!): http://www.vdr-portal.de/board16-video-disk-recorder/board85-hdtv-dvb-s2/p977938-stb0899-fec-3-4-tester-gesucht/#post977938 It says in stb0899_drv.c function: static void stb0899_set_iterations(struct stb0899_state *state) This: reg = STB0899_READ_S2REG(STB0899_S2DEMOD, MAX_ITER); STB0899_SETFIELD_VAL(MAX_ITERATIONS, reg, iter_scale); stb0899_write_s2reg(state, STB0899_S2DEMOD, STB0899_BASE_MAX_ITER, STB0899_OFF0_MAX_ITER, reg); should be replaced with this: reg = STB0899_READ_S2REG(STB0899_S2FEC, MAX_ITER); STB0899_SETFIELD_VAL(MAX_ITERATIONS, reg, iter_scale); stb0899_write_s2reg(state, STB0899_S2FEC, STB0899_BASE_MAX_ITER, STB0899_OFF0_MAX_ITER, reg); Basically replace STB0899_S2DEMOD with STB0899_S2FEC in this 2 lines affected. Kind Regards Steffen Hi Steffen, Unfortunately, it does not help in my case. Thx anyway. Try my locking fix. With above patch I can lock the channels without problem. Can someone confirm that such patch would fix the issue? If so, please forward it in a way that it could be applied (patch is currently line-wrapped), and submit with some comments/description and your SOB. As the patch is currently broken, I'm just marking it as rejected at patchwork. Manu, Please take a look on this trouble report. Thanks! Mauro. I am out of station currently. I will take a deeper look at it during the weekend or next week. 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] stb0899: Removed an extra byte sent at init on DiSEqC bus
On 6/1/11, Mauro Carvalho Chehab mche...@redhat.com wrote: Em 19-10-2010 14:05, Mauro Carvalho Chehab escreveu: Em 19-10-2010 10:55, Florent AUDEBERT escreveu: On 06/11/2010 06:01 PM, Florent AUDEBERT wrote: I noticed a stray 0x00 at init on DiSEqC bus (KNC1 DVB-S2) with a DiSEqC tool analyzer. I removed the register from initialization table and all seem to go well (at least for my KNC board). Hi, This old small patch had been marked superseded on patchwork[1]. Is there an non-obvious case when patches go superseded ? Perhaps I missed something but it seems to me no other patch replaced it. This is one of the bad things with patchwork: there's no reason field associated to a status change, nor it marks when the status were changed. A search on my linux-media box, showed that this patch were there, waiting for Manu review, at the email I sent on Jul, 6 2010. The patch still applies, and I didn't find any reply from Manu giving any feedback about it. So, I'm re-tagging it as under review. Manu, any comments about this patch (and the other remaining patches that we're waiting fro your review) ? Manu, Please ack or nack this patch. It was sent about 1,5 years ago! if you don't comment, I'll assume that this patch is ok and I'll apply it. Thanks, Mauro. Mauro, I have been away from home and not yet back due to a nasty back sprain, but expect to return mid next week. Please hold off on the patches that you need inputs from my side. I will get back on these, the following weekend. Sorry about any inconvenience caused. 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: [PATCH 00/13] Reduce the gap between DVBv5 API and the specs
On 6/9/11, Mauro Carvalho Chehab mche...@redhat.com wrote: There's a huge gap between the DVB specs and the current implementation. This were caused by years of changes that happened at the code but no updates to the specs were done. This patch series tries to reduce this gap. Basically, the headers at include/linux/dvb were included at the API. The Makefile scripting auto-generate references for structs, typedefs and ioctls. With this, it is now easy to identify when something is missing. After adding such logic, I've manually synchronized the specs with the header file and updated the data structures. The work is not complete yet: there are still several ioctl's not documented at the specs: While here, I noticed that one audio ioctl is not used anyware (AUDIO_GET_PTS). There is just the ioctl definition and that's it. I just removed this definition, as removing it won't cause any regression, as no in-kernel driver or dvb-core uses it. Please do not apply this patch; the SAA716x FF DVB driver uses the same ioctl. 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 00/13] Reduce the gap between DVBv5 API and the specs
On 6/9/11, Mauro Carvalho Chehab mche...@redhat.com wrote: Em 09-06-2011 10:06, Manu Abraham escreveu: On 6/9/11, Mauro Carvalho Chehab mche...@redhat.com wrote: There's a huge gap between the DVB specs and the current implementation. This were caused by years of changes that happened at the code but no updates to the specs were done. This patch series tries to reduce this gap. Basically, the headers at include/linux/dvb were included at the API. The Makefile scripting auto-generate references for structs, typedefs and ioctls. With this, it is now easy to identify when something is missing. After adding such logic, I've manually synchronized the specs with the header file and updated the data structures. The work is not complete yet: there are still several ioctl's not documented at the specs: While here, I noticed that one audio ioctl is not used anyware (AUDIO_GET_PTS). There is just the ioctl definition and that's it. I just removed this definition, as removing it won't cause any regression, as no in-kernel driver or dvb-core uses it. Please do not apply this patch; the SAA716x FF DVB driver uses the same ioctl. I'll revert this patch for now, in order to wait for driver submissions that use this ioctl (and the other ioctl's that are not used anywhere inside the Kernel). Thanks! 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: The right way to interpret the content of SNR, signal strength and BER from HVR 4000 Lite
Devin Heitmueller wrote: On Wed, Mar 25, 2009 at 6:02 PM, Manu Abraham abraham.m...@gmail.com wrote: Sure, of course. Here is an updated list based on the information that you accumulated. I have corrected some of them, which were not accurate. Before I comment any further on your email, could you please clarify what you mean by Relative, confirms to API. The current DVB API specification does not specify any units of measure for the content of the field, so I am not sure what you mean by this. Sorry about not responding earlier, wasn't feeling well at all and hence. By Relative, i meant dimensionless, but still it makes some sense based on some documented references. What i mean relative is that the API expects something like this. http://linuxtv.org/hg/dvb-apps/file/5fbdd3f898b1/util/szap/README 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] Remove debug output from stb6100_cfg.h
Mauro Carvalho Chehab wrote: Manu, If ok to you, please ack. On Thu, 26 Mar 2009 10:45:53 +0100 Artem Makhutov ar...@makhutov.org wrote: This patch removes the debug output from stb6100_cfg.h as it is flooding the syslog with tuning data during normal operation. Signed-off-by: Artem Makhutov ar...@makhutov.org Looks okay, Acked-by: Manu Abraham abraham.m...@linuxtv.org --- linux.old/drivers/media/dvb/frontends/stb6100_cfg.h 2009-03-26 10:28:57.0 +0100 +++ linux/drivers/media/dvb/frontends/stb6100_cfg.h 2009-03-26 10:29:52.0 +0100 @@ -36,7 +36,6 @@ return err; } *frequency = t_state.frequency; - printk(%s: Frequency=%d\n, __func__, t_state.frequency); } return 0; } @@ -59,7 +58,6 @@ return err; } } - printk(%s: Frequency=%d\n, __func__, t_state.frequency); return 0; } @@ -81,7 +79,6 @@ } *bandwidth = t_state.bandwidth; } - printk(%s: Bandwidth=%d\n, __func__, t_state.bandwidth); return 0; } @@ -103,6 +100,5 @@ return err; } } - printk(%s: Bandwidth=%d\n, __func__, t_state.bandwidth); return 0; } -- To unsubscribe from this list: send the line unsubscribe linux-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] SkyStar HD2 issues, signal sensitivity, etc.
Manu Abraham wrote: Dave Lister wrote: 2009/4/12 VDR User user@gmail.com: On Sat, Apr 11, 2009 at 5:47 AM, Dave Lister foc...@gmail.com wrote: 2009/4/11 VDR User user@gmail.com: There is a new mantis tree being uploaded at: http://jusst.de/hg/mantis-v4l Please try this tree. The upload should finish within 2 hours and is using DVB api 5 (aka s2api). RESULTS (using s2 dvb-apps): - scanning DVB-S works - scanning DVB-S2 doesn't work - zapping DVB-S is fast Can you please try a fresh clone of the tree? I believe the fixes have now been applied. Thanks! Ok, I did and it seems fine. I mean for a Linux DVB-S2 card. :) Compared to liplianin driver, only minus is non-working DiSEqC. Because I am using a multiswitch, I had to switch to liplianin. I am sorry, but I'm definitely keeping an eye on your driver as well and will be testing it as it gets updated! For other SkyStar HD2 users, this is a summary as of 2009.04.14: - kernel 2.6.29 + mantis-v4l works (except DiSEqC as far as I can tell) Diseqc works fine over here, with the VP-1041 and other cards, using the mantis-v4l tree. - kernel 2.6.29 + s2-liplianin works just as reliably + DiSEqC The s2-liplianin tree doesn't use an updated tree for the mantis based devices unfortunately. It is stuck with older changesets of the mantis tree. The s2-liplianin tree contains (ed) ? some clock related changes which were not favourable for the STB0899 demodulator, which is capable of causing potential hardware damage. Common issues: - zapping DVB-S2 channel causes tuner HW lockup (loss of signal until reboot) - zap DVB-S2 channel = AWFUL ultra-high pitched noise emitted from the card (capacitors or coils?) - makes your head hurt in about 30mins - very poor TS (picture data) quality; signal = 95%, SNR = 70%, STB/TV gives superb picture, but SkyStar/PC picture is corrupted every few seconds, sound glitches, etc. (as if the signal was like 40% on STB) - confirmed in VDR (Xine), MythTV, mplayer. These issues are present with both of my two SkyStar cards, which hopefully eliminates faulty HW. To be frank, The cards what i have don't have the issues whatsoever you mention. There could be multiple causes, since the cards that i have don't have the troubles whatsoever you mention. * If you had those changes on your hardware and your card was susceptible to such issues, then that could be a possible reason. * There are quite some hardware pirates, as noted here .. Added the missing link. http://www.twinhan.com/news_071011-1.asp In any of your cases, If you have hardware related issues please contact to your supplier to have it checked/replaced by them. NOTE: Always try to stick with a tree that's a mainline tree or the development tree, rather than tree's with unknown 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 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
TT S2 1600 status
Hi all, Support for the TT S2-1600 has been updated. Please do test. The 903 demodulator officially supports 45MSPS, with an unofficial max up to 63MSPS with 8PSK DVB-S2. (standard DVB-S2 demodulators support upto 30MSPS) Support is found on the v4l-dvb hg tree on jusst.de Testers, Feedback welcome. 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] Most stable DVB-S2 PCI Card?
On Fri, May 22, 2009 at 11:42 PM, Goga777 goga...@bk.ru wrote:
What is the most stable DVB-S2 PCI card?
I use hvr4000 without any problem.
Yes, no issues. Just that it is based a Generation 1 demodulator which
are limited in capabilities even for a Generation 1 demodulator. Also that the
statistics are just home made empirical values, rather than real ones.
In short, the Hauppauge NOVA-HD-S2 is the one to buy. Yes, it's somewhat
more expensive but it's the best DVB-S2 based PCI card concerning
stability and usability with for example VDR.
Unfortunately, the Nova HD-S2 won't support any DVB-S2 stream with
symbol rates 30 MSPS, also it supports only DVB-S2 NBC mode
is there any dvb-s2 channels with sr 30 msps ??
Of course, Generation 2 transmissions there are quite a lot of new things.
There are are some broadcasts on Intelsat 903 with 45 MSPS.
That's what i know for now, There could be more though.
There will be more of it, as broadcaster goes the 2nd generation path, as
well as broadcasters who don't want PC users to capture the stream on
Home PC's. (Till vendors come up with new hardware to do that)
of operation, being based on an older generation demodulator.
what about quality indicators - snr and ber in your drivers ? do they work
correctly ?
Yes, they do, currently it is on a dBm/10 scale.
(The statistics on the Nova HD are just crude just based on empirical
home tests,
not real statistics though.)
If you need statistics normalized to the current API (TT S2 1600),
attached is a
patch that fixes STR and SNR calculation and normalizes the value into the
0..0x range.
If you find any issues with the driver, please do report it over here.
Currently haven't
seen any issues by any of the testers.
diff -r b301def35098 linux/drivers/media/dvb/frontends/stv090x.c
--- a/linux/drivers/media/dvb/frontends/stv090x.c Thu May 21 17:18:15 2009 +0200
+++ b/linux/drivers/media/dvb/frontends/stv090x.c Thu May 21 23:22:28 2009 +0200
@@ -4227,14 +4227,10 @@
int res = 0;
int min = 0, med;
- if (val tab[min].read)
- res = tab[min].real;
- else if (val = tab[max].read)
- res = tab[max].real;
- else {
+ if ((val = tab[min].read val tab[max].read) || (val = tab[max].read val tab[min].read)) {
while ((max - min) 1) {
med = (max + min) / 2;
- if (val = tab[min].read val tab[med].read)
+ if ((val = tab[min].read val tab[med].read) || (val = tab[med].read val tab[min].read))
max = med;
else
min = med;
@@ -4243,6 +4239,18 @@
(tab[max].real - tab[min].real) /
(tab[max].read - tab[min].read)) +
tab[min].real;
+ } else {
+ if (tab[min].read tab[max].read) {
+ if (val tab[min].read)
+res = tab[min].real;
+ else if (val = tab[max].read)
+res = tab[max].real;
+ } else {
+ if (val = tab[min].read)
+res = tab[min].real;
+ else if (val tab[max].read)
+res = tab[max].real;
+ }
}
return res;
@@ -4252,16 +4260,21 @@
{
struct stv090x_state *state = fe-demodulator_priv;
u32 reg;
- s32 agc;
+ s32 agc_0, agc_1, agc;
+ s32 str;
reg = STV090x_READ_DEMOD(state, AGCIQIN1);
- agc = STV090x_GETFIELD_Px(reg, AGCIQ_VALUE_FIELD);
-
- *strength = stv090x_table_lookup(stv090x_rf_tab, ARRAY_SIZE(stv090x_rf_tab) - 1, agc);
+ agc_1 = STV090x_GETFIELD_Px(reg, AGCIQ_VALUE_FIELD);
+ reg = STV090x_READ_DEMOD(state, AGCIQIN0);
+ agc_0 = STV090x_GETFIELD_Px(reg, AGCIQ_VALUE_FIELD);
+ agc = MAKEWORD16(agc_1, agc_0);
+
+ str = stv090x_table_lookup(stv090x_rf_tab, ARRAY_SIZE(stv090x_rf_tab) - 1, agc);
if (agc stv090x_rf_tab[0].read)
- *strength = 5;
+ str = 0;
else if (agc stv090x_rf_tab[ARRAY_SIZE(stv090x_rf_tab) - 1].read)
- *strength = -100;
+ str = -100;
+ *strength = (str + 100) * 0x / 100;
return 0;
}
@@ -4272,6 +4285,7 @@
u32 reg_0, reg_1, reg, i;
s32 val_0, val_1, val = 0;
u8 lock_f;
+ s32 snr;
switch (state-delsys) {
case STV090x_DVBS2:
@@ -4283,14 +4297,13 @@
reg_1 = STV090x_READ_DEMOD(state, NNOSPLHT1);
val_1 = STV090x_GETFIELD_Px(reg_1, NOSPLHT_NORMED_FIELD);
reg_0 = STV090x_READ_DEMOD(state, NNOSPLHT0);
-val_0 = STV090x_GETFIELD_Px(reg_1, NOSPLHT_NORMED_FIELD);
+val_0 = STV090x_GETFIELD_Px(reg_0, NOSPLHT_NORMED_FIELD);
val += MAKEWORD16(val_1, val_0);
msleep(1);
}
val /= 16;
- *cnr = stv090x_table_lookup(stv090x_s2cn_tab, ARRAY_SIZE(stv090x_s2cn_tab) - 1, val);
- if (val stv090x_s2cn_tab[ARRAY_SIZE(stv090x_s2cn_tab) - 1].read)
-*cnr = 1000;
+ snr = stv090x_table_lookup(stv090x_s2cn_tab, ARRAY_SIZE(stv090x_s2cn_tab) - 1, val);
+ *cnr = snr * 0x / stv090x_s2cn_tab[ARRAY_SIZE(stv090x_s2cn_tab) - 1].real;
}
break;
@@ -4304,14 +4317,13 @@
reg_1 = STV090x_READ_DEMOD(state, NOSDATAT1);
val_1 = STV090x_GETFIELD_Px(reg_1, NOSDATAT_UNNORMED_FIELD);
reg_0 = STV090x_READ_DEMOD(state, NOSDATAT0);
-val_0 = STV090x_GETFIELD_Px(reg_1, NOSDATAT_UNNORMED_FIELD);
+val_0 = STV090x_GETFIELD_Px(reg_0,
Re: [linux-dvb] Most stable DVB-S2 PCI Card?
On Sat, May 23, 2009 at 1:30 AM, David Lister foc...@gmail.com wrote: Manu Abraham wrote: On Fri, May 22, 2009 at 11:42 PM, Goga777 goga...@bk.ru wrote: Unfortunately, the Nova HD-S2 won't support any DVB-S2 stream with symbol rates 30 MSPS, also it supports only DVB-S2 NBC mode is there any dvb-s2 channels with sr 30 msps ?? Of course, Generation 2 transmissions there are quite a lot of new things. There are are some broadcasts on Intelsat 903 with 45 MSPS. That's what i know for now, There could be more though. Actually, there are many DVB-S2 cards supporting 45 MS/s, even TeVii S460 can do 2-45 MS/s. I spoke with a fellow TeVii owner, who confirmed the card is working with a 45 MS/s transponder on Express AM2 without *any* issues. All this aside, there aren't any transponders with higher rates than this and there won't be for many years. Who knows how stable would TT even be with such rates? For now, it's irrelevant anyway. I have no problem upgrading to a new card in 3-4 years, providing there will be a stable, fully supported card for Linux with as many satisfied owners as e.g. Nova S2 HD has. You are talking about a 45 MSPS DVB-S stream on a DVB-S2 demodulator, while i was talking about a 45 MSPS DVB-S2 stream on a DVB-S2 demodulator. Big difference ! -- To unsubscribe from this list: send the line unsubscribe linux-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] Most stable DVB-S2 PCI Card?
On Sat, May 23, 2009 at 9:51 AM, David Lister foc...@gmail.com wrote: Manu Abraham wrote: On Sat, May 23, 2009 at 1:30 AM, David Lister foc...@gmail.com wrote: Actually, there are many DVB-S2 cards supporting 45 MS/s, even TeVii S460 can do 2-45 MS/s. I spoke with a fellow TeVii owner, who confirmed the card is working with a 45 MS/s transponder on Express AM2 without *any* issues. All this aside, there aren't any transponders with higher rates than this and there won't be for many years. Who knows how stable would TT even be with such rates? For now, it's irrelevant anyway. I have no problem upgrading to a new card in 3-4 years, providing there will be a stable, fully supported card for Linux with as many satisfied owners as e.g. Nova S2 HD has. You are talking about a 45 MSPS DVB-S stream on a DVB-S2 demodulator, while i was talking about a 45 MSPS DVB-S2 stream on a DVB-S2 demodulator. Big difference ! This point is moot in the first place, mate. Especially in USA (original poster), where it'll take twice the time to reach those rates on DVB-S2. All current 45 MS/s transponders are QPSK, at least as far as I can tell. Even if that technology preview 8PSK transponder of yours existed (somewhere above Asia), it's hardly a reason to buy Linux-unstable cards in EU or USA. Have you tried the card, to state that it is unstable ? I would like to know the basis for your comments to state that it is unstable. Especially considering OP's quest for super-stable HW. HD is pretty much beginning and none of it goes over 30 MS/p. Why hurry, I ask? In 2-3 years time, when your driver is finished and stable, we'll all happily switch to generation 2 HW (your term), if need be. Don't get me wrong, I have nothing against TT, -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Question about driver for Mantis
On Sat, May 23, 2009 at 10:10 AM, Jarosław Huba jarhu...@poczta.onet.pl wrote: Hi. Is driver for Mantis chipset are currently developed somewhere? I'm owner of Azurewave AD SP400 CI (VP-1041) and I'm waiting for support for this card for quite long time. Even partly working driver in mainline kernel would be great (without remote, CI, S2 support, with some tuning bugs). This question is mainly for Manu Abraham who developed this driver some time ago. The latest development snapshot for the mantis based devices can be found here: http://jusst.de/hg/mantis-v4l Currently CI is unsupported, though very preliminary code support for it exists in it. S2 works, pretty much. Or do you have other results ? 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] Most stable DVB-S2 PCI Card?
On Sat, May 23, 2009 at 2:03 PM, David Lister foc...@gmail.com wrote: Manu Abraham wrote: On Sat, May 23, 2009 at 9:51 AM, David Lister foc...@gmail.com wrote: This point is moot in the first place, mate. Especially in USA (original poster), where it'll take twice the time to reach those rates on DVB-S2. All current 45 MS/s transponders are QPSK, at least as far as I can tell. Even if that technology preview 8PSK transponder of yours existed (somewhere above Asia), it's hardly a reason to buy Linux-unstable cards in EU or USA. Have you tried the card, to state that it is unstable ? I would like to know the basis for your comments to state that it is unstable. I was not talking specifically about TT-1600, but with your drivers being relatively young, not in wide use, and you being the only developer (right?), it's common sense to assume that they are not as stable as e.g. cx88. LOL, As stable as CX88, you must be joking. As far as the number of developers on the card, if you are as capable of reading what you claim, you can see that from the changelogs, in the main tree itself. You mean the SAA7146 driver is young ? Hmm.. pretty ignorant comments, you seem to make. The 7146 is one of the oldest driver that exists. Exception is bttv which is still older. Also considering the fact that none of these drivers even report signal stats properly. Then, of course, there's my recent experience with your SkyStar HD2 driver. :) Which card are you talking about ? Your experience with the Skystar HD driver == USER Error, that's what some people would think. The mantis driver is a driver which is very much in development. You should've read it on the ML's itself. It's really sad that you are pretty much ignorant. A driver which is in development, you expect all sorts of issues. That's why it is in an external tree. Now, you managed to get hold of the wrong tree, burned your demodulator, inspite of me warning users on the ML's many times. So you are still ignorant on that. You decided to do, what it pleased you. Not my fault. I guess, you don't understand the term Development, Stable etc either. The TT S2-1600 support is much different, support for it exist in the mainline tree, which is verified. The SAA7146 bridge which the S2-1600 is based on, is the most mature PCI multimedia bridge that exists under Linux. Also you seem completely ignorant about how Linux development goes on. You have to understand that me, in this case just a common user, do not wish to invest into a product with an unfinished driver. If it was for me, I wouldn't really care, but with the whole family using the HTPC... I didn't want to write a long mail, but here goes: The TechnoTrend company, as of Februay 2009, doesn't exists any more. *It is bankrupt*. First, its owner Novabase sold as many of its shares as it could in 2007, in hope that the proceeds would allow TechnoTrend to get back on track. No such luck. A few months back this year, the company was finally dumped and sold as a whole to some German telco company in the Kathrein Group for liquidation, because of the tremendous drop in it's market value and forthcoming bankruptcy. This might also be of some interest to prospective buyers of it's former products. :) I don't want to search for all the press releases, but you can verify this claim here: http://www.euronext.com/fic/000/044/480/444806.pdf I don't work for Technotrend, neither have i till now. My opinions are my own. I don't care about your completely non-technical or trolling posts. Whether Technotrend is having a new ownership/management is as well nothing of concern to me. There seems to be people buying thedead product that you claim and hence the support for it is in. Nevertheless, I tried to get the data-sheet for this dead product from their closed down discontinued sites. Google cache is a great thing, I managed to find TechnoTrend's S2-1600 data-sheet PDF: http://www.pt.technotrend.com/Dokumente/87/Manuals_PC/specs_eng/TechSpec_S2-1600_engl.pdf As much as I'd like to believe your S2-1600 supports 63 MS/s, I cannot ignore the fact that the manufacturer disagrees with you: DVB-S: 2 - 45 MS/s DVB-S2: 10 - 30 MS/s It's not a card manufacturer that do make the chip specifications. You can look at the STV0903 specification, or the announcement that i made earlier on the list about the same. From the Cut 2.0 chips onwards, The STV0900/903 demodulators do support 45 MSPS officially and unofficially 60 MSPS with 8PSK modulation. Anything predating Cut 2.0 you don't find on any PC related products. http://linuxtv.org/hg/v4l-dvb/rev/4882c97b0540 Pretty standard specs, if you ask me. Obviously, you must have proven the *manufacturer* wrong by verifying your claim in practice. I just wonder how you did it, when no existing DVB-S2 transponder uses rates over 30 MS/s. Wasn't it perhaps just some dry testing without any signal, like gradually raising the HW
Re: Question about driver for Mantis
2009/5/23 Jarosław Huba jarhu...@poczta.onet.pl: The latest development snapshot for the mantis based devices can be found here: http://jusst.de/hg/mantis-v4l Currently CI is unsupported, though very preliminary code support for it exists in it. S2 works, pretty much. Or do you have other results ? Regards, Manu I will test it soon. Do I need to compile my own pathed kernel? Or Is there some info on wiki about how to do that in easier way? I'm using Kubuntu Karmic with kernel 2.6.30. Just clone the tree on to your machine hg clone http://jusst.de/hg/mantis-v4l Clean stal remnants if any. make distclean Build the tree make Load the modules one by one, or have a script of your own to load it, or you can do a make install In case you are sending me debug output, please do load the mantis.ko and stb0899.ko modules with the verbose=5 module parameter, so that the debug messages are verbosed out. Otherwise you can forget about the module parameters. 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] Most stable DVB-S2 PCI Card?
As soon as the new S2API mantis tree was mentioned on the list, I used it. But most importantly, your only explanation that it still doesn't work, because I burned my demodulator using the current s2-liplianin tree is *absolutely* ridiculous. You might work it out with Liplianin himself, No, you happened to be a complete idiot inspite of doing sane things, being repeatedly warned with posts on the Mailing List. If you can't read, you suffer from it. s2-liplianin was created with some cause for promoting the hardware what you were trying to promote. So definitely it is that way. I can't help that you ran arbitrary code on your computer and got screwed. I did not expect everything rosy, I have my share of Linux HW experiences. I've also written a complete Linux driver for a device I had, which wasn't supported - that driver is now part of the kernel. So believe me, not only I know how open source development works, I even know how kernel driver development works. half baked one's are the usual problematic one's. There used to be one crying loud over documentation patches. This is true, but do you know how the chips are integrated in TT-1600. Final consumer product using certain chipsets usually does miss some features or parameter ranges of the integrated chips (especially SoC chips). Have you ever seen a PC motherboard? Well, now that you know how I meant what I said, it is perhaps time to acknowledge that the *card* manufacturer usually knows what their product is capable of. You know, they being the people who actually design all the circuitry on the PCB... First of all i had completely no clue on it. That's why i was able to write a driver for it. (with sarcasm) Mate you have no clue. The S2-1600 is based on a reference design and hence. You have a lot to understand. I don't give it a damn which way to take it to heart. 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: Question about driver for Mantis
2009/5/23 Gernot Pansy ger...@pansy.at: hy, On Saturday 23 May 2009 08:41:48 Manu Abraham wrote: On Sat, May 23, 2009 at 10:10 AM, Jarosław Huba jarhu...@poczta.onet.pl wrote: Hi. Is driver for Mantis chipset are currently developed somewhere? I'm owner of Azurewave AD SP400 CI (VP-1041) and I'm waiting for support for this card for quite long time. Even partly working driver in mainline kernel would be great (without remote, CI, S2 support, with some tuning bugs). This question is mainly for Manu Abraham who developed this driver some time ago. The latest development snapshot for the mantis based devices can be found here: http://jusst.de/hg/mantis-v4l Currently CI is unsupported, though very preliminary code support for it exists in it. S2 works, pretty much. Or do you have other results ? will CI be supported and are you willing to finish development and merge it to mainline anytime? The CI code is out there in it itself commented out, but is a bit unstable. I haven't spent too much time on it these last 2 months, due to lack of time i think i was one of the first SP400 owner but i had to sold my card for a Nova HD2 because the driver was not reliable (some i2c errors, slow tunning, sometimes tunning failed). And now i need a dvb-s2 card with ci working. so i'm searching again for a new card. their seems to be only the tt-3200 out, which seems to work - no newer card. The issue with the I2C errors have been fixed in the jusst.de/hg/mantis-v4l tree. It had been a bit hard to fix, but i am almost certain, that issue is gone for good. There were quite a lot of fixes to the stb0899 module, so maybe some of the issues what you looked at might've been fixed. 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: Question about driver for Mantis
2009/5/23 David Lister foc...@gmail.com: Gernot Pansy wrote: will CI be supported and are you willing to finish development and merge it to mainline anytime? i think i was one of the first SP400 owner but i had to sold my card for a Nova HD2 because the driver was not reliable (some i2c errors, slow tunning, sometimes tunning failed). And now i need a dvb-s2 card with ci working. so i'm searching again for a new card. their seems to be only the tt-3200 out, which seems to work - no newer card. Not sure if you didn't get this email already, I had a slip-up while sending it. :) Anyway, there's also another supported card with a CI. A friend of mine has it, so I guess it works quite well with Linux. It's Mystique SaTiX-S2 (AFAIK, similar to KNC1+). Mystiques have rather quality finish and the CI module is ready for 3.5 drive installation. Some pictures from google: http://www.cesarex.com/images/Mystique-CI-1.jpg http://www.sat-servis.cz/data/eshop/fotky/produkty/velke/619.jpg Others might be able to tell you more details, I just know it works - friend has a Cryptoworks CAM in it. Take a look around, bye. The Mystique is just a rebranded KNC1+ which just uses the same STB0899 module, FYI. :-) 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: Question about driver for Mantis
2009/5/23 Jarosław Huba jarhu...@poczta.onet.pl Just clone the tree on to your machine hg clone http://jusst.de/hg/mantis-v4l Clean stal remnants if any. make distclean Build the tree make I got this error: ja...@jarek-desktop:~/mantis-v4l$ make make -C /home/jarek/mantis-v4l/v4l make[1]: Wejście do katalogu `/home/jarek/mantis-v4l/v4l' No version yet, using 2.6.30-6-generic make[1]: Opuszczenie katalogu `/home/jarek/mantis-v4l/v4l' make[1]: Wejście do katalogu `/home/jarek/mantis-v4l/v4l' scripts/make_makefile.pl Updating/Creating .config Preparing to compile for kernel version 2.6.30 ***WARNING:*** You do not have the full kernel sources installed. This does not prevent you from building the v4l-dvb tree if you have the kernel headers, but the full kernel source may be required in order to use make menuconfig / xconfig / qconfig. If you are experiencing problems building the v4l-dvb tree, please try building against a vanilla kernel before reporting a bug. Vanilla kernels are available at http://kernel.org. On most distros, this will compile a newly downloaded kernel: cp /boot/config-`uname -r` your kernel dir/.config cd your kernel dir make all modules_install install Please see your distro's web site for instructions to build a new kernel. Created default (all yes) .config file ./scripts/make_myconfig.pl make[1]: Opuszczenie katalogu `/home/jarek/mantis-v4l/v4l' make[1]: Wejście do katalogu `/home/jarek/mantis-v4l/v4l' perl scripts/make_config_compat.pl /lib/modules/2.6.30-6-generic/build ./.myconfig ./config-compat.h creating symbolic links... ln -sf . oss Kernel build directory is /lib/modules/2.6.30-6-generic/build make -C /lib/modules/2.6.30-6-generic/build SUBDIRS=/home/jarek/mantis-v4l/v4l modules make[2]: Entering directory `/usr/src/linux-headers-2.6.30-6-generic' CC [M] /home/jarek/mantis-v4l/v4l/tuner-xc2028.o CC [M] /home/jarek/mantis-v4l/v4l/tuner-simple.o CC [M] /home/jarek/mantis-v4l/v4l/tuner-types.o CC [M] /home/jarek/mantis-v4l/v4l/mt20xx.o CC [M] /home/jarek/mantis-v4l/v4l/tda8290.o CC [M] /home/jarek/mantis-v4l/v4l/tea5767.o CC [M] /home/jarek/mantis-v4l/v4l/tea5761.o CC [M] /home/jarek/mantis-v4l/v4l/tda9887.o CC [M] /home/jarek/mantis-v4l/v4l/tda827x.o CC [M] /home/jarek/mantis-v4l/v4l/au0828-core.o CC [M] /home/jarek/mantis-v4l/v4l/au0828-i2c.o CC [M] /home/jarek/mantis-v4l/v4l/au0828-cards.o In file included from /home/jarek/mantis-v4l/v4l/dmxdev.h:33, from /home/jarek/mantis-v4l/v4l/au0828.h:29, from /home/jarek/mantis-v4l/v4l/au0828-cards.c:22: /home/jarek/mantis-v4l/v4l/compat.h:396: error: redefinition of 'usb_endpoint_type' include/linux/usb/ch9.h:376: note: previous definition of 'usb_endpoint_type' was here Quick fix, do a make menuconfig: navigate through the menus, disable au0828 support and try again. 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: Question about driver for Mantis
On Sat, May 23, 2009 at 9:42 PM, David Lister foc...@gmail.com wrote: Manu Abraham wrote: 2009/5/23 David Lister foc...@gmail.com: Not sure if you didn't get this email already, I had a slip-up while sending it. :) Anyway, there's also another supported card with a CI. A friend of mine has it, so I guess it works quite well with Linux. It's Mystique SaTiX-S2 (AFAIK, similar to KNC1+). Mystiques have rather quality finish and the CI module is ready for 3.5 drive installation. Some pictures from google: http://www.cesarex.com/images/Mystique-CI-1.jpg http://www.sat-servis.cz/data/eshop/fotky/produkty/velke/619.jpg Others might be able to tell you more details, I just know it works - friend has a Cryptoworks CAM in it. Take a look around, bye. The Mystique is just a rebranded KNC1+ which just uses the same STB0899 module, FYI. :-) Not exactly. People usually say it is a rebrand/clone of KNC1+, but it's not. :) There are couple of differences -- Mystique is a lighter version missing these features: 1) Signal passthrough via loop-out connector 2) Video input port for analogue capture I'm glad you reminded me of this misconception, the differences might be important for somebody. I was considering Mystique for myself, but chose CX24116 over STB0899, because this time, I wanted official support. I don't need analogue capture and CI anyway (I use softcam and for analog, much better Hauppauge PVR-500). I suggest Mystique instead of KNC1+ for purely practical reasons - it's more available, cheaper and nicer. :) No misconceptions: So support for it just appeared like magic ? There are 2 card variants: 1. KNC1 a) KNC1 DVB-S2+ (With analog support) b) KNC1 DVB-S2 (without analog support, the board has the place to solder the SAA7113, just that no chip and connectors) 2. Satelco Satelco DVB-S2 KNC1 (OEM clone of b) 3. Mystique CI uses polling model in all the above 3. Mystique (clone of KNC1 either A or B, even subsystem ID's itself aren't different, AFAICS) Now, there are other STB0899 based cards: 4. TT S2 3200 Very similar to the ST reference design. Uses a SAA7146 for the PCI bridge CI uses an interrupt driven model. 5. VP-1041 Very similar to the ST reference design. Uses a Mantis PCI bridge. CI is using a much different model. CI slot supports raw PCMCIA devices as well. currently CI support is very preliminary and not much functional. HTH -- To unsubscribe from this list: send the line unsubscribe linux-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] Most stable DVB-S2 PCI Card?
On Sat, May 23, 2009 at 10:16 PM, David Lister foc...@gmail.com wrote: Andreas Regel wrote: David Lister schrieb: I didn't want to write a long mail, but here goes: The TechnoTrend company, as of Februay 2009, doesn't exists any more. *It is bankrupt*. First, its owner Novabase sold as many of its shares as it could in 2007, in hope that the proceeds would allow TechnoTrend to get back on track. No such luck. A few months back this year, the company was finally dumped and sold as a whole to some German telco company in the Kathrein Group for liquidation, because of the tremendous drop in it's market value and forthcoming bankruptcy. This might also be of some interest to prospective buyers of it's former products. :) I don't want to search for all the press releases, but you can verify this claim here: http://www.euronext.com/fic/000/044/480/444806.pdf As written there the Görler Telekom bought the business and stock of TT, that includes the brand name, all products and most of the developers. They formed a new Company called TechnoTrend Görler GmbH, that will continue development, production and sales. See here: http://www.kathrein.de//en/press/cont/texte2009/pi0910.htm Even if not explicitely mentioned there, PC products are included in that deal. New web site is still under construction: http://www.ttgoerler.de/ That is good news, thanks for the update! Everything falling apart last time I checked was a rather disturbing experience, even though I've never been their greatest fan. There's just a handful of companies making usable PC tuners and TT was one of the bigger ones. If KG are serious, I am quite relieved. Kathrein not only has extensive know-how and capital, it seems to like Linux. We might even see official Linux support for their new products. That would be cool! :) I'd definitely support such a manufacturer. *OT* I just remembered in connection with Linux DVB-S2 cards: in case some of you also heard about that new dual DVB-S2-CI tuner for PC's with full Linux support, you can forget about it. Or at least I can. When I pre-ordered directly from the Russian manufacturer (NetUP), they said the price for one would be $1000. What a rip-off... Indeed it is. Maybe you will get a DVB card with dual DVB-S2 and CI with hardware H.264 decoder and HDMI out for a better deal. You might need to wait for the hardware to be available though. -- To unsubscribe from this list: send the line unsubscribe linux-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] New utility program atsc_epg added to dvb-apps utility suite.
2009/6/18 Yufei Yuan yfy...@gmail.com: Hi, I am not sure if this is the correct mailing list to send this patch. From the LinuxTV website, it seems that currently dvb-apps project has no owner. A new utility atsc_epg is added into the dvb-apps utility suite. It parses PSIP information carried in OTA ATSC channels, and constructs a basic EPG in a terminal window. Changes were also made to files to please GCC4.4. The patch is against latest revision 1278 from the dvb-apps repository. Please do send the patch with tabs instead of spaces for indentation. 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] New utility program atsc_epg added to dvb-apps utility suite.
On Thu, Jun 18, 2009 at 12:32 PM, Manu Abrahamabraham.m...@gmail.com wrote: 2009/6/18 Yufei Yuan yfy...@gmail.com: Hi, I am not sure if this is the correct mailing list to send this patch. From the LinuxTV website, it seems that currently dvb-apps project has no owner. A new utility atsc_epg is added into the dvb-apps utility suite. It parses PSIP information carried in OTA ATSC channels, and constructs a basic EPG in a terminal window. Changes were also made to files to please GCC4.4. The patch is against latest revision 1278 from the dvb-apps repository. Please do send the patch with tabs instead of spaces for indentation. Also: * please cleanup the white spaces in the patch, if any. * please use the unified format, diff -u option. 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] New utility program atsc_epg added to dvb-apps utility suite.
On Fri, Jun 19, 2009 at 5:55 AM, Yufei Yuanyfy...@gmail.com wrote:
Not sure how to make it look right in gmail, but the inline patch does
not look right to my eyes. I have the patch attached behind as a
backup.
You can attach the patch, no worries.
I have applied the patch, but the CodingStyle is not very nice, mostly
the wrapping to 80 cols is done in a bad way. It makes the code not
easy to read.
Also have made some comments inline from your patch. Please do fix the
mentioned ones against the dvb-apps head
diff -uprN dvb-apps/util/atsc_epg/atsc_epg.c
dvb-apps_new/util/atsc_epg/atsc_epg.c
--- dvb-apps/util/atsc_epg/atsc_epg.c 1969-12-31 18:00:00.0 -0600
+++ dvb-apps_new/util/atsc_epg/atsc_epg.c 2009-06-18 20:17:24.527925142
-0500
@@ -0,0 +1,1249 @@
+/*
+ * atsc_epg utility
+ *
+ * Copyright (C) 2009 Yufei Yuan yfy...@gmail.com
+ * 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., 675 Mass Ave, Cambridge, MA 02139, USA.
+ */
+
+#include stdio.h
+#include stdlib.h
+#include unistd.h
+#include string.h
+#include time.h
+#include signal.h
+#include sys/types.h
+#include sys/stat.h
+#include fcntl.h
+#include sys/ioctl.h
+#include sys/poll.h
+#include errno.h
+#include getopt.h
+#include stdarg.h
+#include libdvbapi/dvbfe.h
+#include libdvbapi/dvbdemux.h
+#include libucsi/dvb/section.h
+#include libucsi/atsc/section.h
+#include libucsi/atsc/types.h
+
+#define TIMEOUT60
+#define RRT_TIMEOUT60
+#define MAX_NUM_EVENT_TABLES 128
+#define TITLE_BUFFER_LEN 4096
+#define MESSAGE_BUFFER_LEN (16 * 1024)
+#define MAX_NUM_CHANNELS 16
+#define MAX_NUM_EVENTS_PER_CHANNEL (4 * 24 * 7)
+
+static int atsc_scan_table(int dmxfd, uint16_t pid, enum atsc_section_tag tag,
+ void **table_section);
+
+static const char *program;
+static int adapter = 0;
+static int period = 12; /* hours */
+static int frequency;
+static int enable_ett = 0;
+static int ctrl_c = 0;
+static const char *modulation = NULL;
+static char separator[80];
+void (*old_handler)(int);
+
+struct atsc_string_buffer {
+ int buf_len;
+ int buf_pos;
+ char *string;
+};
+
+struct atsc_event_info {
+ uint16_t id;
+ struct tm start;
+ struct tm end;
+ int title_pos;
+ int title_len;
+ int msg_pos;
+ int msg_len;
+};
+
+struct atsc_eit_section_info {
+ uint8_t section_num;
+ uint8_t num_events;
+ uint8_t num_etms;
+ uint8_t num_received_etms;
+ struct atsc_event_info **events;
+};
+
+struct atsc_eit_info {
+ int num_eit_sections;
+ struct atsc_eit_section_info *section;
+};
+
+struct atsc_channel_info {
+ uint8_t num_eits;
+ uint8_t service_type;
+ char short_name[8];
+ uint16_t major_num;
+ uint16_t minor_num;
+ uint16_t tsid;
+ uint16_t prog_num;
+ uint16_t src_id;
+ struct atsc_eit_info *eit;
+ struct atsc_event_info *last_event;
+ int event_info_index;
+ struct atsc_event_info e[MAX_NUM_EVENTS_PER_CHANNEL];
+ struct atsc_string_buffer title_buf;
+ struct atsc_string_buffer msg_buf;
+};
+
+struct atsc_virtual_channels_info {
+ int num_channels;
+ uint16_t eit_pid[MAX_NUM_EVENT_TABLES];
+ uint16_t ett_pid[MAX_NUM_EVENT_TABLES];
+ struct atsc_channel_info ch[MAX_NUM_CHANNELS];
+} guide;
+
+struct mgt_table_name {
+ uint16_t range;
+ const char *string;
+};
+
+struct mgt_table_name mgt_tab_name_array[] = {
+ {0x, terrestrial VCT with current_next_indictor=1},
+ {0x0001, terrestrial VCT with current_next_indictor=0},
+ {0x0002, cable VCT with current_next_indictor=1},
+ {0x0003, cable VCT with current_next_indictor=0},
+ {0x0004, channel ETT},
+ {0x0005, DCCSCT},
+ {0x00FF, reserved for future ATSC use},
+ {0x017F, EIT},
+ {0x01FF, reserved for future ATSC use},
+ {0x027F, event ETT},
+ {0x02FF, reserved for future ATSC use}, /* FIXME */
+ {0x03FF, RRT with rating region},
+ {0x0FFF, user private},
+ {0x13FF, reserved for future ATSC use},
+ {0x14FF, DCCT with dcc_id},
+ {0x, reserved for future ATSC use}
+};
+
+const char *channel_modulation_mode[] = {
+ ,
+ analog,
+ SCTE mode 1,
+
Re: Details about DVB frontend API
On Fri, Oct 23, 2009 at 12:10 AM, Mauro Carvalho Chehab
mche...@infradead.org wrote:
Em Thu, 22 Oct 2009 21:13:30 +0200
Jean Delvare kh...@linux-fr.org escreveu:
Hi folks,
I am looking for details regarding the DVB frontend API. I've read
linux-dvb-api-1.0.0.pdf, it roughly explains what the FE_READ_BER,
FE_READ_SNR, FE_READ_SIGNAL_STRENGTH and FE_READ_UNCORRECTED_BLOCKS
commands return, however it does not give any information about how the
returned values should be interpreted (or, seen from the other end, how
the frontend kernel drivers should encode these values.) If there
documentation available that would explain this?
For example, the signal strength. All I know so far is that this is a
16-bit value. But then what? Do greater values represent stronger
signal or weaker signal? Are 0x and 0x special values? Is the
returned value meaningful even when FE_HAS_SIGNAL is 0? When
FE_HAS_LOCK is 0? Is the scale linear, or do some values have
well-defined meanings, or is it arbitrary and each driver can have its
own scale? What are the typical use cases by user-space application for
this value?
That's the kind of details I'd like to know, not only for the signal
strength, but also for the SNR, BER and UB. Without this information,
it seems a little difficult to have consistent frontend drivers.
We all want to know about that ;)
Seriously, the lack of a description of the meaning of the ranges for those
read values were already widely discussed at LMML and at the legacy dvb ML.
We should return this discussion again and decide what would be the better
way to describe those values.
My suggestion is that someone summarize the proposals we had and give some
time
for people vote. After that, we just commit the most voted one, and commit the
patches for it. A pending question that should also be discussed is what we
will
do with those dvb devices where we simply don't know what scale it uses. There
are several of them.
Sometime back, (some time in April) i proposed a patch which addressed
the issue to scale even those devices which have a weird scale or
none. Though based on an older tree of mine, here is the patch again.
If it looks good enough, i can port the patch to accomodate other
devices as well.
Regards,
Manu
diff -r b5505a985f24 linux/drivers/media/dvb/dvb-core/dvb_frontend.c
--- a/linux/drivers/media/dvb/dvb-core/dvb_frontend.c Sat Feb 21 01:12:09 2009 +0400
+++ b/linux/drivers/media/dvb/dvb-core/dvb_frontend.c Tue Apr 07 18:19:22 2009 +0400
@@ -1004,8 +1004,8 @@
*/
/* Legacy */
if (fe-legacy) {
- if ((fepriv-state FESTATE_LOSTLOCK)
- (fe-ops.info.caps FE_CAN_RECOVER)
+ if ((fepriv-state FESTATE_LOSTLOCK)
+ (fe-ops.info.caps FE_CAN_RECOVER)
(fepriv-max_drift == 0)) {
dvb_frontend_swzigzag_update_delay(fepriv, s FE_HAS_LOCK);
@@ -1487,6 +1487,13 @@
break;
}
+ case FE_STATISTICS_CAPS: {
+ struct fecap_statistics *stats_cap = parg;
+ memcpy(stats_cap, fe-ops.statistics_caps, sizeof (struct fecap_statistics));
+ err = 0;
+ break;
+ }
+
case FE_READ_STATUS: {
fe_status_t* status = parg;
@@ -1502,6 +1509,17 @@
err = fe-ops.read_status(fe, status);
break;
}
+
+ case FE_SIGNAL_LEVEL:
+ if (fe-ops.read_level)
+ err = fe-ops.read_level(fe, (__u32 *) parg);
+ break;
+
+ case FE_SIGNAL_STATS:
+ if (fe-ops.read_stats)
+ err = fe-ops.read_stats(fe, (struct fesignal_stat *) parg);
+ break;
+
case FE_READ_BER:
if (fe-ops.read_ber)
err = fe-ops.read_ber(fe, (__u32*) parg);
@@ -1645,7 +1663,7 @@
break;
}
- memcpy(fepriv-parameters, parg, sizeof (struct dvb_frontend_parameters));
+ memcpy(fepriv-parameters, parg, sizeof (struct dvb_frontend_parameters));
memset(fetunesettings, 0, sizeof(struct dvb_frontend_tune_settings));
memcpy(fetunesettings.parameters, parg, sizeof (struct dvb_frontend_parameters));
diff -r b5505a985f24 linux/drivers/media/dvb/dvb-core/dvb_frontend.h
--- a/linux/drivers/media/dvb/dvb-core/dvb_frontend.h Sat Feb 21 01:12:09 2009 +0400
+++ b/linux/drivers/media/dvb/dvb-core/dvb_frontend.h Tue Apr 07 18:19:22 2009 +0400
@@ -72,7 +72,7 @@
unsigned int audmode;
u64 std;
};
-
+
enum dvbfe_modcod {
DVBFE_MODCOD_DUMMY_PLFRAME = 0,
DVBFE_MODCOD_QPSK_1_4,
@@ -250,6 +250,7 @@
struct dvb_frontend_ops {
struct dvb_frontend_info info;
+ struct fecap_statistics statistics_caps;
void (*release)(struct dvb_frontend* fe);
void (*release_sec)(struct dvb_frontend* fe);
@@ -304,6 +305,9 @@
enum dvbfe_search (*search)(struct dvb_frontend *fe, struct dvbfe_params *fe_params);
int (*track)(struct dvb_frontend *fe, struct dvbfe_params *fe_params, int *delay);
+ int (*read_level)(struct dvb_frontend *fe, u32 *signal); /* Raw AGC level */
+ int (*read_stats)(struct dvb_frontend *fe, struct fesignal_stat *stat);
+
struct dvb_tuner_ops tuner_ops;
struct analog_demod_ops analog_ops;
};
diff -r b5505a985f24
Re: Details about DVB frontend API
On Fri, Oct 23, 2009 at 4:12 AM, Markus Rechberger
mrechber...@gmail.com wrote:
On Thu, Oct 22, 2009 at 10:29 PM, Manu Abraham abraham.m...@gmail.com wrote:
On Fri, Oct 23, 2009 at 12:10 AM, Mauro Carvalho Chehab
mche...@infradead.org wrote:
Em Thu, 22 Oct 2009 21:13:30 +0200
Jean Delvare kh...@linux-fr.org escreveu:
Hi folks,
I am looking for details regarding the DVB frontend API. I've read
linux-dvb-api-1.0.0.pdf, it roughly explains what the FE_READ_BER,
FE_READ_SNR, FE_READ_SIGNAL_STRENGTH and FE_READ_UNCORRECTED_BLOCKS
commands return, however it does not give any information about how the
returned values should be interpreted (or, seen from the other end, how
the frontend kernel drivers should encode these values.) If there
documentation available that would explain this?
For example, the signal strength. All I know so far is that this is a
16-bit value. But then what? Do greater values represent stronger
signal or weaker signal? Are 0x and 0x special values? Is the
returned value meaningful even when FE_HAS_SIGNAL is 0? When
FE_HAS_LOCK is 0? Is the scale linear, or do some values have
well-defined meanings, or is it arbitrary and each driver can have its
own scale? What are the typical use cases by user-space application for
this value?
That's the kind of details I'd like to know, not only for the signal
strength, but also for the SNR, BER and UB. Without this information,
it seems a little difficult to have consistent frontend drivers.
We all want to know about that ;)
Seriously, the lack of a description of the meaning of the ranges for those
read values were already widely discussed at LMML and at the legacy dvb ML.
We should return this discussion again and decide what would be the better
way to describe those values.
My suggestion is that someone summarize the proposals we had and give some
time
for people vote. After that, we just commit the most voted one, and commit
the
patches for it. A pending question that should also be discussed is what we
will
do with those dvb devices where we simply don't know what scale it uses.
There
are several of them.
Sometime back, (some time in April) i proposed a patch which addressed
the issue to scale even those devices which have a weird scale or
none. Though based on an older tree of mine, here is the patch again.
If it looks good enough, i can port the patch to accomodate other
devices as well.
A few of our customers were requiring additional statistic
information, so we added follwing
command to our DVB API:
FE_GET_SIGQUALITY
struct media_sigquality {
uint16_t MER; /** in steps of 0.1 dB
*/
uint32_t preViterbiBER ; /** in steps of 1/scaleFactorBER
*/
uint32_t postViterbiBER ; /** in steps of 1/scaleFactorBER
*/
uint32_t scaleFactorBER; /** scale factor for BER
*/
uint32_t packetError ; /** number of packet errors
*/
uint32_t postReedSolomonBER ; /** in steps of 1/scaleFactorBER
*/
uint32_t indicator; /** indicative signal quality
low=0..100=high */
}
It's a one shot request.
it might be good to standardize this, although we can live with that
additional command too.
Based on the above data structure, since UNC is calculated from pre -
post viterbi, any good reason why you need it explicit ? Which
otherwise is redundant. Still when simplified, it looks exactly the
same as the version 3.2 frontend statistic information alone except
for the BER scale, isn't 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
pull from http://jusst.de/hg/v4l-dvb
Mauro, Please pull from http://jusst.de/hg/v4l-dvb for the following changeset: 13339:b8eb9e860545 changeset: 13338:bababbc9ddfc changeset: 13337:27db3dcc12a9 changeset: 13336:3f3113d2ead1 changeset: 13335:e9b90fb35417 changeset: 13334:4e9c155206ba changeset: 1:ac7ac94ccbd2 changeset: 13332:de4f36566dd0 changeset: 13331:4dc0da1d5d50 changeset: 13330:6f84240eaa1b changeset: 13329:48ff458badf2 The High Symbol Rate related Transport Stream corruption issue on the STB0899 based cards is hopefully fixed. Additionally, it contains the STV090x related fixes for the TT S2-1600 from Andreas Regel. 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: Details about DVB frontend API
On Tue, Nov 17, 2009 at 11:46 PM, Mauro Carvalho Chehab
mche...@infradead.org wrote:
Manu Abraham escreveu:
On Fri, Oct 23, 2009 at 12:10 AM, Mauro Carvalho Chehab
mche...@infradead.org wrote:
Em Thu, 22 Oct 2009 21:13:30 +0200
Jean Delvare kh...@linux-fr.org escreveu:
Hi folks,
I am looking for details regarding the DVB frontend API. I've read
linux-dvb-api-1.0.0.pdf, it roughly explains what the FE_READ_BER,
FE_READ_SNR, FE_READ_SIGNAL_STRENGTH and FE_READ_UNCORRECTED_BLOCKS
commands return, however it does not give any information about how the
returned values should be interpreted (or, seen from the other end, how
the frontend kernel drivers should encode these values.) If there
documentation available that would explain this?
For example, the signal strength. All I know so far is that this is a
16-bit value. But then what? Do greater values represent stronger
signal or weaker signal? Are 0x and 0x special values? Is the
returned value meaningful even when FE_HAS_SIGNAL is 0? When
FE_HAS_LOCK is 0? Is the scale linear, or do some values have
well-defined meanings, or is it arbitrary and each driver can have its
own scale? What are the typical use cases by user-space application for
this value?
That's the kind of details I'd like to know, not only for the signal
strength, but also for the SNR, BER and UB. Without this information,
it seems a little difficult to have consistent frontend drivers.
We all want to know about that ;)
Seriously, the lack of a description of the meaning of the ranges for those
read values were already widely discussed at LMML and at the legacy dvb ML.
We should return this discussion again and decide what would be the better
way to describe those values.
My suggestion is that someone summarize the proposals we had and give some
time
for people vote. After that, we just commit the most voted one, and commit
the
patches for it. A pending question that should also be discussed is what
we will
do with those dvb devices where we simply don't know what scale it uses.
There
are several of them.
Sometime back, (some time in April) i proposed a patch which addressed
the issue to scale even those devices which have a weird scale or
none. Though based on an older tree of mine, here is the patch again.
If it looks good enough, i can port the patch to accomodate other
devices as well.
Regards,
Manu
Manu,
Sorry for not answering earlier. Due to my travels, I had a very big backlog
here
to handle.
I prefer a solution like you've proposed of creating a new set of API calls
for
it, instead of re-defining the current calls.
I have been unable to respond earlier on this, being out of station.
Sorry, my previous mail failed to reach the Mailing list due to HTML
part being existant. Hopefully it is fixed this time.
Yet, I have a few comments:
diff -r b5505a985f24 linux/include/linux/dvb/frontend.h
--- a/linux/include/linux/dvb/frontend.h Sat Feb 21 01:12:09 2009 +0400
+++ b/linux/include/linux/dvb/frontend.h Tue Apr 07 18:19:22 2009 +0400
@@ -645,4 +645,118 @@
};
#define DVBFE_GET_EVENT _IOR('o', 86, struct
dvbfe_event)
+/* Frontend General Statistics
+ * General parameters
+ * FE_*_UNKNOWN:
+ * Parameter is unknown to the frontend and doesn't really
+ * make any sense for an application.
+ *
+ * FE_*_RELATIVE:
+ * Parameter is relative on the basis of a ceil - floor basis
+ * Format is based on empirical test to determine
+ * the floor and ceiling values. This format is exactly the
+ * same format as the existing statistics implementation.
+ */
+enum fecap_quality_params {
+ FE_QUALITY_UNKNOWN = 0,
+ FE_QUALITY_SNR = (1 0),
+ FE_QUALITY_CNR = (1 1),
+ FE_QUALITY_EsNo = (1 2),
+ FE_QUALITY_EbNo = (1 3),
+ FE_QUALITY_RELATIVE = (1 31),
+};
+
+enum fecap_scale_params {
+ FE_SCALE_UNKNOWN = 0,
+ FE_SCALE_dB = (1 0),
+ FE_SCALE_RELATIVE = (1 31),
+};
+
+enum fecap_error_params {
+ FE_ERROR_UNKNOWN = 0,
+ FE_ERROR_BER = (1 0),
+ FE_ERROR_PER = (1 1),
+ FE_ERROR_RELATIVE = (1 31),
+};
+
+enum fecap_unc_params {
+ FE_UNC_UNKNOWN = 0,
+ FE_UNC_RELATIVE = (1 31),
+};
+
+/* General parameters
+ * width:
+ * Specifies the width of the field
+ *
+ * exponent:
+ * Specifies the multiplier for the respective field
+ * MSB:1bit indicates the signdness of the parameter
+ */
+struct fecap_quality {
+ enum fecap_quality_params params;
+ enum fecap_scale_params scale
Re: Details about DVB frontend API
On Fri, Nov 20, 2009 at 3:37 PM, Julian Scheel jul...@jusst.de wrote: Am Freitag, 20. November 2009 10:29:34 schrieb Manu Abraham: Let me explain a bit. The current issue that persists as Devin explained in another email explains things to a certain extend, but still i think it might be better to detail further. Generally a request can be classified to 3 basic types. 1. Request to acquire, retrieve acquisition details 2. Get information (device state, device info) 3. Get information (channel statistics) The first one for example is a request to say tune to a channel, get tuned channel details, or even other frontend specific commands such as SEC operations. These operations are not very critical with regards on a time scale, just that things could be shifted all along on the time scale, the worser the implementation, the larger the time taken to carry around a larger set of information to handle the operation. Currently, the V3.x and the V5 implementation handles this. The V3 implementation is small and fast, while the V5 implementation is sluggish. The second one gets basic device information. The V3 implementation handled this to a certain extend, but the V5 implementation hardly handles this and the implementation is rather crude rather than being sophisticated. The third aspect which is basically needed in most cases for debugging the channel properties. If all things were ideal, one wouldn't need to know the details on what's going on inside. So being in the far from ideal thing, the requisite to know what happens internally is very much a need in all cases. Another point to be noted is that this category of information is very much critical on a timescale as these parameters are valid for a very certain instances of time only. The more this information gets out of sync, the more these values are meaningless. Also another point to be noted is that all these values when read back together at the very same instance only does make sense. It is indeed very hard to achieve this very short timespan between each of the values being monitored. The larger the bandwidth associated, the larger the error introduced in the readback of the values within the same timeframe in between the reads. So the timeframe has to be the very least possible in between this operation to the device driver internals too.. Although, i have pointed out with this patch what happens at the driver level and at the userspace level, There needs additions to the libdvb parts to handle whatever conversions from format x to y. This needs to be handled since it might not be very easy to be handled consistsently by all applications. So in this concept, the application can choose the format conversion from the library as well, such that the application can provide the statistics in either the the driver native format, or a unified format (conversion done by the library) if the user prefers it. We are already redefining some existing ioctls there, so it would be clearer for the userspace developers what would be the new way to retrieve frontend stats, as we can simply say that DVBS2API features superseeds the equivalent DVB v3 ioctls. As i have noted above, the statistics related calls have a meaning, if and only if it is hanled very fast and properly with no caching. Having a genarlized datastructure to handle this event, breaks up the whole meaning of having this call itself in this position. What an API generally does is to make things generalized. When one makes things the most generalized way an overhead is also associated with it in terms of performance. If things were possible, i would directly read from memory from an application from the hardware itself for processing data in such a scenario, rather than to make things very generalized. This is an area where concepts like data caching can be ruled out completely. We are already at a disadvantage with the kernel driver doing a copy_to_user itself. Ideally, a memory mapped to userspace would have been the ideal thing over here. It is just the question of having yet another set of statistics calls that handles the information properly or not. Hi Manu, thanks for the detailed explanation of your point. Actually I am not completely familiar with how the S2API calls are handled internally. Still are there any proven measurements about the timeframe the calls are being executed within? - I absolutely see that reading signal statistics is a time critical process, at least it is important to be able to assign the data to a specific moment so it can be interpreted in conjunction with the data which is being received in that moment. Not only is it time critical, but it should also be atomic, ie it should be all in one go, ie one single snapshot of an event, not events bunched together serially. Things wont seem that atomic on a system with a large load. Latency will have a significant effect
Re: DIY Satellite Web Radio
On Mon, Nov 30, 2009 at 11:13 PM, OrazioPirataDelloSpazio (Lorenzo) ziducai...@autistici.org wrote: Hi all, I'm not a DVB expert but I'm wondering if this idea is feasible: For an amateur web radio, for what I know, it is really hard to being listened in cars, like people do with commercial satellite radio [1] . Basically this is unaffortable for private user and this is probably the most relevant factor that penalize web radios againt terrestrial one. My question is: is there any way to use the current, cheap, satellite internet connections to stream some data above all the coverage of a geo satellite? and make the receiver handy (so without any dishes) ? FWIW, you wont need a satellite dish (some of them operate in the L Band), unless you are very much out of the footprint, with a weak signal. Nevertheless, a parabolic reflector will give you a higher gain, but again that's not the choice for a receiving aerial in a moving vehicle. Such use cases use in some cases a flat panel antenna or an antenna array. DVB-RCS wouldn't work as it needs to be really pointed to the satellite, nor any Ku or C band transponders. The lower you are in the spectrum, the more likely to have a better reception with a lower gain reflector. http://en.wikipedia.org/wiki/1worldspace http://www.worldspace.com/howitworks/receivers/AGFwssr.html http://www.worldspace.com/coveragemaps/antennaguide.html http://www.satdirectory.com/--worldspace.html 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: DIY Satellite Web Radio
On Tue, Dec 1, 2009 at 12:42 AM, Mauro Carvalho Chehab mche...@redhat.com wrote: Em 30-11-2009 17:13, OrazioPirataDelloSpazio (Lorenzo) escreveu: Hi all, I'm not a DVB expert but I'm wondering if this idea is feasible: For an amateur web radio, for what I know, it is really hard to being listened in cars, like people do with commercial satellite radio [1] . Basically this is unaffortable for private user and this is probably the most relevant factor that penalize web radios againt terrestrial one. My question is: is there any way to use the current, cheap, satellite internet connections to stream some data above all the coverage of a geo satellite? and make the receiver handy (so without any dishes) ? Receiving sat signals without dishes? From some trials we had on a telco I used to work, You would need to use a network of low-orbit satellites, carefully choosing the better frequencies and it will provide you low bandwidth. This will likely cost a lot of money, if you find someone providing a service like that. One trial for such network were the Iridum project. AFAIK, the original company bankrupted due to the very high costs of launching and managing about a hundred satellite network. Low orbital satellites aren't geo-stationary. Technically speaking, a broadcaster would use only geo-stationary satellites for broadcast services. The basic reason: A broadcaster simply would have rented out a transponder on an existing satellite from a satellite operator, or still: if the broadcaster is a major player, they would have a few satellites of their own to provide coverage over multiple regions, but still: they are indeed geo-stationary satellites (you will need a very large number of satellites to provide services in a low orbital position, similar to the Iridium network, which is not practically feasible for a broadcaster. Even the Iridium network had a hard time taking off!) 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] Skystar HD2 and s2-liplianin/mantis driver
On Sun, Nov 29, 2009 at 7:31 PM, Albert Gall ss3...@gmail.com wrote: Hello list I try to build latest s2-liplianin drivers but make shows severals warnings and module not load after build driver: WARNING: ir_input_keydown [s2-liplianin/v4l/mantis.ko] undefined! WARNING: ir_codes_mantis_vp1041_table [s2-liplianin/v4l/mantis.ko] undefined! WARNING: ir_input_nokey [s2-liplianin/v4l/mantis.ko] undefined! WARNING: ir_input_init [s2-liplianin/v4l/mantis.ko] undefined! WARNING: ir_codes_mantis_vp2040_table [s2-liplianin/v4l/mantis.ko] undefined! WARNING: ir_codes_mantis_vp2033_table [s2-liplianin/v4l/mantis.ko] undefined! My kernel is 2.6.31.4. The attached is full driver build log. Any idea to fix this problem ? Please try it from here: http://jusst.de/hg/v4l-dvb 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: Mantis – anyone?
2009/11/26 Matthias Wächter matth...@waechter.wiz.at: I am now playing around with the available code for quite some time now with mixed success, but no solution comes near the term “stable”. • kernel: nothing in there. Well, reasonable. • v4l-dvb: nothing in there. • s2-liplianin: mantis available, but obviously not under development/bugfixing. IR seems to work, CI handling looks quite broken, hangups/lockups are the rule, additional problems with more than one of these cards in the system. • mantis-v4l: does not compile out of the box for recent kernels. When hand-knitting the files into a kernel source directory (2.6.31), works quite unstable, module reloading frequently segfaults. IR does not work (at least for VDR), CI handling looks better than s2-liplianin. Conclusion: Stability is way below a level for reasonable usage while bug fixing. [1] gives an overview of the current state of (non-)development. Does this still apply? My questions are: • Is there someone feeling responsible for that baby? • What is the main part of the mantis stuff not working – mantis itself, the frontend, or adaptions from multiproto to s2api? • What can someone owning some of these cards (one Terratec, two Technisat) do to help the (former) authors to continue their work? • Is there some documentation available which would enable ‘the community’ to work on that further? Please try http://jusst.de/hg/v4l-dvb and report the issues 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: New DVB-Statistics API
On Tue, Dec 8, 2009 at 5:22 PM, Mauro Carvalho Chehab
mche...@redhat.com wrote:
Hi Julian,
Let me add some corrections to your technical analysis.
Julian Scheel wrote:
Hello together,
after the last thread which asked about signal statistics details
degenerated into a discussion about the technical possibilites for
implementing an entirely new API, which lead to nothing so far, I wanted
to open a new thread to bring this forward. Maybe some more people can
give their votes for the different options
Actually Manu did propose a new API for fetching enhanced statistics. It
uses new IOCTL to directly fetch the statistical data in one go from the
frontend. This propose was so far rejected by Mauro who wants to use the
S2API get/set calls instead.
Now to give everyone a quick overview about the advantages and
disadvantages of both approaches I will try to summarize it up:
1st approach: Introduce new IOCTL
Pros:
- Allows a quick fetch of the entire dataset, which ensures that:
1. all values are fetched in one go (as long as possible) from the
frontend, so that they can be treated as one united and be valued in
conjunction
2. the requested values arrive the caller in an almost constant
timeframe, as the ioctl is directly executed by the driver
- It does not interfere with the existing statistics API, which has to
be kept alive as it is in use for a long time already. (unifying it's
data is not the approach of this new API)
Cons:
- Forces the application developers to interact with two APIs. The S2API
for tuning on the one hand and the Statistics API for reading signal
values on the other hand.
2nd approach: Set up S2API calls for reading statistics
Pros:
- Continous unification of the linuxtv API, allowing all calls to be
made through one API. - easy for application developers
- Scaling values can be retrieved/negotiated (if we implement the set
mode) before requesting the stats, using the same API;
- API can be easily extended to support other statistics that may be needed
by newer DTV standards.
Cons:
- Due to the key/value pairs used for S2API getters the statistical
values can't be read as a unique block, so we loose the guarantee, that
all of the values can be treatend as one unit expressing the signals
state at a concrete time.
You missed the point here. The proposal patch groups all S2API
pairs into a _single_ call into the driver:
+ for (i = 0; i tvps-num; i++)
+ need_get_ops += dtv_property_prepare_get_stats(fe,
+ tvp + i, inode, file);
+
+ if (!fe-dtv_property_cache.need_stats) {
+ need_get_ops++;
+ } else {
+ if (fe-ops.get_stats) {
+ err = fe-ops.get_stats(fe);
+ if (err 0)
+ return err;
+ }
+ }
The dtv_property_prepare_get_stats will generate a bitmap field (need_stats)
that
will describe all value pairs that userspace is expecting. After doing it,
a single call is done to get_stats() callback.
All the driver need to do is to fill all values at dtv_property_cache. If the
driver
fills more values than requested by the user, the extra values will simply be
discarded.
In order to reduce latency, the driver may opt to not read the register
values for the
data that aren't requested by the user, like I did on cx24123 driver.
Those values will all be returned at the same time to userspace by a single
copy_to_user()
operation.
- Due to the general architecture of the S2API the delay between
requesting and receiving the actual data could become too big to allow
realtime interpretation of the data (as it is needed for applications
like satellite finders, etc.)
Not true. As pointed at the previous answer, the difference between a new
ioctl
and S2API is basically the code at dtv_property_prepare_get_stats() and
dtv_property_process_get(). This is a pure code that uses a continuous struct
that will likely be at L3 cache, inside the CPU chip. So, this code will run
really quickly.
AFAIK, cache eviction occurs with syscalls: where content in the
caches near the CPU cores is pushed to the outer cores, resulting in
cache misses. Not all CPU's are equipped with L3 caches. Continuous
syscalls can result in TLB cache misses from what i understand, which
is expensive.
These are the numbers Intel lists for a Pentium M:
To Cycles
Register= 1
L1d ~3
L2 ~14
Main Memory ~240
As current CPU's runs at the order of Teraflops (as the CPU clocks are at
gigahertz
order, and CPU's can handle multiple instructions per clock cycle), the added
delay
is in de order of nanosseconds.
Consider STB's where DVB is generally deployed rather than the small
segment of home users running a stack on
Re: New DVB-Statistics API
On Wed, Dec 9, 2009 at 3:43 AM, Mauro Carvalho Chehab
mche...@redhat.com wrote:
Manu Abraham wrote:
Not true. As pointed at the previous answer, the difference between a new
ioctl
and S2API is basically the code at dtv_property_prepare_get_stats() and
dtv_property_process_get(). This is a pure code that uses a continuous
struct
that will likely be at L3 cache, inside the CPU chip. So, this code will run
really quickly.
AFAIK, cache eviction occurs with syscalls: where content in the
caches near the CPU cores is pushed to the outer cores, resulting in
cache misses. Not all CPU's are equipped with L3 caches. Continuous
syscalls can result in TLB cache misses from what i understand, which
is expensive.
It is very likely that the contents of struct fe to go into the cache during
the
syscall. I was conservative when I talked about L3. Depending on the cache
sizes,
I won't doubt that the needed fields of the fe struct will go to L1 cache.
Ah, so the data structure which is there in the ioctl approach as well
and less likely to get cache hits since the calls are lesser.
As current CPU's runs at the order of Teraflops (as the CPU clocks are at
gigahertz
order, and CPU's can handle multiple instructions per clock cycle), the
added delay
is in de order of nanosseconds.
Consider STB's where DVB is generally deployed rather than the small
segment of home users running a stack on a generic PC.
Even with STB, let's assume a very slow cpu that runs at 100
Megabytes/second. So, the clock
speed is 10 nanoseconds. Assuming that this CPU doesn't have a good pipeline,
being
capable of handling only one instruction per second, you'll have one
instruction at executed
at each 10 nanoseconds (as a reference, a Pentium 1, running at 133 Mbps is
faster than this).
Incorrect.
A CPU doesn't execute instruction per clock cycle. Clock cycles
required to execute an instruction do vary from 2 cycles 12 cycles
varying from CPU to CPU.
An I/O operation at i2c is of the order of 10^-3. Assuming that an additional
delay of 10%
(10 ^ -4) will deadly affect realtime capability (with it is very doubtful),
this means that
the CPU can run up to 10,000 (!!!) instructions to generate such delay. If
you compile that code
and check the number or extra instructions I bet it will be shorter enough to
not cause any
practical effect.
So, even on such bad hardware that is at least 20x slower than a netbook
running at 1Gbps,
what determines the delay is the amount of I/O you're doing, and not the
number of extra
code.
The I/O overhead required to read 4 registers from hardware is the
same whether you use the ioctl approach or s2api.
Hardware I/O is the most expensive operation involved.
True. That's what I said.
Case #1: the ioctl approach
code stripped
Now Case #2: based on s2api
code stripped
Now that we can see the actual code flow, we can see the s2api
approach requires an unnecessary large tokenizer/serializer, involving
multiple function calls.
Are you seeing there 10.000 assembler instructions or so? If not, the size of
the code is
not relevant.
Also: gcc optimizer transforms switches into a binary tree. So, if you have 64
cases on switch, it will require 7 comparations (log2(64)) to get a match.
For example, a quick look at the code you've presented, let's just calculate
the number of operations on the dtv_property_proccess_get() routine, without
debug stuff:
static int dtv_property_process_get() {
CMP (if fe-ops.get_property)
CMP (if r 0) This if only happens if the
first one is executed. On my patch, it is not executed
(the code you posted is the
one before my patch)
SWITCH (7 CMP's) due to binary tree optimization
done by gcc
MOV
}
So, that entire code (that has about 200 lines) has, in fact
9 comparations and one move instruction.
At dtv_property_prepare_get_stats(), the code is even cheaper: just a switch
with 8
elements (log2(8) = 3), so 3 comparations, and one move instruction.
The additional cost on dvb_frontend_ioctl_properties is:
2 MOVs
One loop calling dtv_property_prepare_get_stats() - up to 4 times to
retrieve
all quality values
one INC
one CMP and function CALL (the same cost exists also with the struct)
One loop calling dtv_property_get_stats() - up to 4 times to retrieve
all quality values
So, if I've calculated it right, we're talking about 2+1+16+1+2+1+40 = 63
instructions.
2) the userspace-kernelspace payload.
Case #1: The size of S2API structs. It will range from 24 to 84 (depending on
what
you want to get, from one to 4 different value pairs).
Case #2: The size of the ioctl struct: about 30 bytes (If I summed the size
of all structs correctly).
payload of S2API is generally bigger, except if just one
Re: Anyone capable of fixing inverted spectrum issue on tt s2-3200?
On Wed, Dec 16, 2009 at 4:15 PM, Newsy Paper newspaperman_germ...@yahoo.com wrote: Hi, as the problem with the ORF HD transponder on Astra is now figured out and ORF switched inversion off again, we know know where the bug in the driver is. I don't know if the problem also occours on dvb-s(1) transponders but I'll try to figure that out. Is anyone able to fix that dvb-s2 problem? Perhaps it would also solve the problem with some transponders on 1° west? To verify whether an inversion will solve the issue: Please try changing line: #1313 .inversion = IQ_SWAP_ON, /* 1 */ to IQ_SWAP_OFF in http://linuxtv.org/hg/v4l-dvb/file/79fc32bba0a0/linux/drivers/media/dvb/ttpci/budget-ci.c and check whether that solves your inversion issue. Please report your findings. 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-next: Tree for December 19 (media/mantis)
On Sat, Dec 19, 2009 at 7:18 AM, Randy Dunlap randy.dun...@oracle.com wrote: On Sat, 19 Dec 2009 11:04:57 +1100 Stephen Rothwell wrote: Hi all, I said: News: there will be no linux-next releases until at least Dec 24 and, more likely, Dec 29. Have a Merry Christmas and take a break. :-) Well, I decided I had time for one more so it will be based in -rc1). This one has not had the build testing *between* merges, but has had all the normal build testing at the end. Since the latter testing showed no problems, this just means that there may be more unbisectable points in the tree (but that is unlikely). ERROR: ir_input_register [drivers/media/dvb/mantis/mantis_core.ko] undefined! ERROR: ir_input_unregister [drivers/media/dvb/mantis/mantis_core.ko] undefined! ERROR: ir_input_init [drivers/media/dvb/mantis/mantis_core.ko] undefined! ERROR: input_free_device [drivers/media/dvb/mantis/mantis_core.ko] undefined! ERROR: input_allocate_device [drivers/media/dvb/mantis/mantis_core.ko] undefined! CONFIG_INPUT=n Attached patch to fix the issue. Fix Input dependency for Mantis From: Manu Abraham abraham.m...@gmail.com Signed-off-by: Manu Abraham m...@linuxtv.org Regards, Manu diff --git a/drivers/media/dvb/mantis/Kconfig b/drivers/media/dvb/mantis/Kconfig index f9219cd..f7b72a3 100644 --- a/drivers/media/dvb/mantis/Kconfig +++ b/drivers/media/dvb/mantis/Kconfig @@ -1,6 +1,6 @@ config MANTIS_CORE tristate Mantis/Hopper PCI bridge based devices - depends on PCI I2C + depends on PCI I2C INPUT help Support for PCI cards based on the Mantis and Hopper PCi bridge.
Re: Which modules for the VP-2033? Where is the module mantis.ko?
Hello Ruediger, On Wed, Dec 23, 2009 at 11:04 PM, Ruediger Dohmhardt ruediger.dohmha...@freenet.de wrote: Aljaž Prusnik schrieb: If using the http://jusst.de/hg/v4l-dvb tree, everything compiles ok, module loads, but there is no remote anywhere (there is an IR folder with the ir-common.ko file, under common there is not). Aljaz, do you have the module mantis.ko? Ruediger There was a build issue when i posted the link originally, but it had been fixed.. m...@manu-04:/stor/work/merge/v4l-dvb/v4l ls *.ko |grep mantis mantis_core.ko mantis.ko Dec 12 01:18:25 manu-04 kernel: [168362.291827] found a VP-2033 PCI DVB-C device on (06:01.0), Dec 12 01:18:25 manu-04 kernel: [168362.291842] Mantis :06:01.0: PCI INT A - GSI 17 (level, low) - IRQ 17 Dec 12 01:18:25 manu-04 kernel: [168362.291848] Mantis :06:01.0: enabling bus mastering Dec 12 01:18:25 manu-04 kernel: [168362.291876] Mantis Rev 1 [1822:0008], irq: 17, latency: 64 Dec 12 01:18:25 manu-04 kernel: [168362.291881] memory: 0x0, mmio: 0xf875e000 Dec 12 01:18:25 manu-04 kernel: [168362.292577] i2c-adapter i2c-7: adapter [Mantis I2C] registered Dec 12 01:18:25 manu-04 kernel: [168362.292586] i2c-adapter i2c-7: master_xfer[0] W, addr=0x50, len=1 Dec 12 01:18:25 manu-04 kernel: [168362.292590] i2c-adapter i2c-7: master_xfer[1] R, addr=0x50, len=6 Dec 12 01:18:25 manu-04 kernel: [168362.292593] mantis_i2c_write: Address=[0x50] W[ 08 ] Dec 12 01:18:25 manu-04 kernel: [168362.292813] mantis_i2c_read: Address=[0x50] R[ 00 08 ca 19 ea ee ] Dec 12 01:18:25 manu-04 kernel: [168362.293539] MAC Address=[00:08:ca:19:ea:ee] Dec 12 01:18:25 manu-04 kernel: [168362.293565] mantis_alloc_buffers (0): DMA=0x2c5 cpu=0xc2c5 size=65536 Dec 12 01:18:25 manu-04 kernel: [168362.293571] mantis_alloc_buffers (0): RISC=0x31e36000 cpu=0xf1e36000 size=1000 Dec 12 01:18:25 manu-04 kernel: [168362.293575] DVB: registering new adapter (Mantis DVB adapter) Dec 12 01:18:26 manu-04 kernel: [168363.172508] vp2033_frontend_init (0): Probing for CU1216 (DVB-C) Dec 12 01:18:26 manu-04 kernel: [168363.172515] i2c-adapter i2c-7: master_xfer[0] W, addr=0x50, len=1 Dec 12 01:18:26 manu-04 kernel: [168363.172519] i2c-adapter i2c-7: master_xfer[1] R, addr=0x50, len=1 Dec 12 01:18:26 manu-04 kernel: [168363.172522] mantis_i2c_write: Address=[0x50] W[ ff ] Dec 12 01:18:26 manu-04 kernel: [168363.172741] mantis_i2c_read: Address=[0x50] R[ 22 ] Dec 12 01:18:26 manu-04 kernel: [168363.172967] i2c-adapter i2c-7: master_xfer[0] W, addr=0x0c, len=1 Dec 12 01:18:26 manu-04 kernel: [168363.172970] i2c-adapter i2c-7: master_xfer[1] R, addr=0x0c, len=1 Dec 12 01:18:26 manu-04 kernel: [168363.172973] mantis_i2c_write: Address=[0x0c] W[ 1a ] Dec 12 01:18:26 manu-04 kernel: [168363.173194] mantis_i2c_read: Address=[0x0c] R[ 7c ] Dec 12 01:18:26 manu-04 kernel: [168363.173416] TDA10021: i2c-addr = 0x0c, id = 0x7c Dec 12 01:18:26 manu-04 kernel: [168363.173419] vp2033_frontend_init (0): found Philips CU1216 DVB-C frontend (TDA10021) @ 0x0c Dec 12 01:18:26 manu-04 kernel: [168363.173422] vp2033_frontend_init (0): Mantis DVB-C Philips CU1216 frontend attach success Dec 12 01:18:26 manu-04 kernel: [168363.173428] DVB: registering adapter 0 frontend 0 (Philips TDA10021 DVB-C)... Dec 12 01:18:26 manu-04 kernel: [168363.173549] mantis_uart_init (0): Initializing UART @ 9600 bps NONE parity Dec 12 01:18:26 manu-04 kernel: [168363.175459] mantis_uart_work (0): UART BUF:0 3f The IR stuff needs a bit more work, which I will be pushing out, later .. 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: Which modules for the VP-2033? Where is the module mantis.ko?
On Thu, Dec 24, 2009 at 12:01 AM, Ruediger Dohmhardt ruediger.dohmha...@freenet.de wrote: Manu Abraham schrieb: Hello Ruediger, On Wed, Dec 23, 2009 at 11:04 PM, Ruediger Dohmhardt ruediger.dohmha...@freenet.de wrote: Aljaž Prusnik schrieb: If using the http://jusst.de/hg/v4l-dvb tree, everything compiles ok, module loads, but there is no remote anywhere (there is an IR folder with the ir-common.ko file, under common there is not). Aljaz, do you have the module mantis.ko? Ruediger There was a build issue when i posted the link originally, but it had been fixed.. Yupp, it works now! I just downloaded version 2315248f648c. It compiles fine on Suse 11.1 and it works here with vdr-1.7.10 and xineliboutput (from CVS). However, as Aljaž also noted, the driver does not autoload. I need to do modprobe mantis.ko. Manu, this used to work, but I do not remember when the autoload was lost. Have you run depmod ? 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: Mantis driver on TechniSat CableStar HD 2
Hello Wolfgang, On Sun, Dec 27, 2009 at 8:37 PM, Wolfgang Denk w...@denx.de wrote: I have problems getting a TechniSat CableStar HD 2 DVB-C card running with the latest Mantis driver on a Fedora 12 system (using their current standard 2.6.31.9-174.fc12.i686.PAE kernel in combination with the drivers from the http://linuxtv.org/hg/v4l-dvb repository). Tests have been done on two different mainboards. I can run a channel scan (using kaffeine) perfectly fine, also tuning to channels appears to work. I see a load of some 1,300 interrupts per sec when I have kaffeine running and tuned, and it seems there is data transferred between the card and the application. From what i understand without much deeper look is that you have a successful LOCK and hence the transfer. The problem is: there is no video nor sound. The generic budget DVB cards do not have an onboard hardware decoder and what we have is a DVR device from which the Transport stream is being read out. A Software decoder is used to process the TS. I have bought this card second-hand on, so I am not really sure if it is a software issue, or if eventually the hardware is broken. Can anybody recommend a way how to verify the driver or the hardware? Or can you recommend a specific kernel version the Mantis driver has been tested against? If you can successfully tune and get a valid TS from the DVR device, you can rule out issues with the card and the driver. You can verify the functionality of the hardware and driver with the command line applications from the dvb-apps repository. 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: Which modules for the VP-2033? Where is the module mantis.ko?
Hello Aljaz, On Thu, Dec 24, 2009 at 8:51 PM, Aljaž Prusnik prus...@gmail.com wrote: On čet, 2009-12-24 at 17:45 +0100, Ruediger Dohmhardt wrote: Aljaž, thanks for the reply. As Manu said above there was a build problem. As said already in this Thread, I downloaded version 2315248f648c, which compiles fine and has all modules for the 2033 DVB-C. I have the same version and it doesn't work for me. I have a 2040 module. Can you please do a lspci -vn for the Mantis card you have ? Also try loading the mantis.ko module with verbose=5 module parameter, to get more debug information. 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] Acoustical mode for femon
On Thu, Dec 24, 2009 at 1:20 AM, Maximilian Seesslen m...@seesslen.net wrote: Hi List, find attached a patch that adds a Acoustical mode to femon. The monitoring application produces a sound indicating the signal quality. The higher the beep the better the signal quality. This is useful while mounting the antenna for finding the best position without having to look at the monitor or without even having a monitor. Thanks, applied. 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: [RFC] dvb-apps ported for ISDB-T
On Fri, Jan 1, 2010 at 2:23 AM, Mauro Carvalho Chehab mche...@redhat.com wrote: Patrick Boettcher wrote: Hi Mauro, On Fri, 25 Dec 2009, Mauro Carvalho Chehab wrote: Em 24-12-2009 00:17, Mauro Carvalho Chehab escreveu: I wrote several patches those days in order to allow dvb-apps to properly parse ISDB-T channel.conf. On ISDB-T, there are several new parameters, so the parsing is more complex than all the other currently supported video standards. I've added the changes at: http://linuxtv.org/hg/~mchehab/dvb-apps-isdbt/ I've merged there Patrick's dvb-apps-isdbt tree. While there, I fixed a few bugs I noticed on the parser and converted it to work with the DVB API v5 headers that are bundled together with dvb-apps. This helps to avoid adding lots of extra #if DVB_ABI_VERSION tests. The ones there can now be removed. TODO: = The new ISDB-T parameters are parsed, but I haven't add yet a code to make them to be used; There are 3 optional parameters with ISDB-T, related to 1seg/3seg: the segment parameters. Currently, the parser will fail if those parameters are found. gnutv is still reporting ISDB-T as DVB-T. I've just fixed the issues on the TODO list. The DVB v5 code is now working fine for ISDB-T. Pending stuff (patches are welcome): - Implement v5 calls for other video standards; - Remove the duplicated DVBv5 code on /util/scan/scan.c (the code for calling DVBv5 is now at /lib/libdvbapi/v5api.c); - Test/use the functions to retrieve values via DVBv5 API. The function is already there, but I haven't tested. With the DVBv5 API implementation, zap is now working properly with ISDB-T. gnutv also works (although some outputs - like decoder - may need some changes, in order to work with mpeg4/AAC video/audio codecs). Very good job! Have you had a look here on this one http://www.mail-archive.com/v...@linuxtv.org/msg11125.html ? I had this on my list because I wanted to spent some time on DVB-S2 myself and it seemed to be a good step to merge it (back) into dvb-apps. Though I haven't yet looked at it in detail. I will check your changes soon, but after the holidays. So, now you should have some quiet time for yourself! ;-) Ok, I've added a version 2 of the isdbt-aware dvb-apps scan tools. Basically, this version: - checks if v5 API is available on a driver. If not, it falls back to v3 API; - v5api.c is now fully internal to libdvbfe. For library clients, it is fully transparent if it is using v5 or v3 calls; - scan now uses libdvbfe, instead of directly implementing the ioctls for v3 and v5. The code were simplified by the removal of lots of if's for v5 API; - scan now supports a few parameters present on DVB-S2, but there are still a few missing bits to fully support DVB-S2; - as my previous tree, dvb-apps has a copy of the dvb headers, since the headers are stable enough to work with older drivers and since the API version check is done by an ioctl call; - it addresses the pertinent issues that Manu pointed. It still remains the same, however. I had a quick look at it again: - dvb-apps/libs stopped using a separate copy of the kernel headers; ie kernel headers are expected to be at the default system locations, ie the kernel headers package. Because you added it in again, a test app szap2 had to be disabled for compilation. Changesets: 1332, 1334, 1348, 1357 - the library is falling on an expected operation for V5. This can fail if the API is V3 or something else. It should check the header version and if it is known to be greater than V3, then only it should issue the new V5 ioctl to test for version. This frees from an unnecessary test in the case of the V3 API. Changeset 1336 - Please do not apply partial features. Either apply it, or don't. Changeset 1341 - ATSC Cable is not DVB-C, even though it has some similiarities. Let's not get things mixed up. Changeset 1344 - Let the application send the number of properties, not the library to do memory allocation and deallocation. I mentioned about this one in my previous reply to your post. fill_sys_v5_params() -- count_props() Changeset: 1350, 1359, 1360 sizeof applies to a data structure, not the pointer, Changeset 1360 - maintain Backward compatibility with V3. Changeset 1351 Yet, this version is not properly tested, but, as I intend to be on vacations next week, I wanted to post what I have, even without all tests, to avoid the risk of someone to be working on DVB-S2 or other improvements to do a similar work. - Memory management needs string.h v5api.c:512: warning: implicit declaration of function ‘memset’ v5api.c:512: warning: incompatible implicit declaration of built-in function ‘memset v5api.c:567: warning: incompatible implicit declaration of built-in function ‘memset’ Maybe, it would simplify things, if I would pull in the changes till where it looks mostly right, the others
Re: [RFC] Serialization flag example
On Thu, Apr 1, 2010 at 10:24 PM, Mauro Carvalho Chehab mche...@redhat.com wrote: You'll have issues also with -alsa and -dvb parts that are present on the drivers. Also, drivers like cx88 have another PCI device for mpeg-encoded streams. It behaves like two separate drivers (each with its own bind code at V4L core), but, as there's just one PCI bridge, and just one analog video decoder/analog audio decoder, the lock should cross between the different drivers. So, binding videobuf to v4l2_device won't solve the issue with most videobuf-aware drivers, nor the lock will work as expected, at least with most of the devices. Also, although this is not a real problem, your lock is too pedantic: it is blocking access to several ioctl's that don't need to be locked. For example, there are several ioctl's that just returns static: information: capabilities, supported video standards, etc. There are even some cases where dynamic ioctl's are welcome, like accepting QBUF/DQBUF without locking (or with a minimum lock), to allow different threads to handle the buffers. The big issue I see with this approach is that developers will become lazy on checking the locks inside the drivers: they'll just apply the flag and trust that all of their locking troubles were magically solved by the core. Maybe a better alternative would be to pass to the V4L2 core, optionally, some lock, used internally on the driver. This approach will still be pedantic, as all ioctls will keep being serialized, but at least the driver will need to explicitly handle the lock, and the same lock can be used on other parts of the driver. IMO, A framework shouldn't lock. Why ? Different devices require different locking schemes, each and every device require it in different ways. Some drivers might not even require it, since they may be able to handle different systems asynchronously. Locking and such device management, will be known to the driver alone and not to any framework. While, this may benefit some few devices the other set of devices will eventually be broken. 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] Serialization flag example
Hi Devin, Hello Manu, The argument I am trying to make is that there are numerous cases where you should not be able to use both a particular DVB and V4L device at the same time. The implementation of such locking should be handled by the v4l-dvb core, but the definition of the relationships dictating which devices cannot be used in parallel is still the responsibility of the driver. This way, a bridge driver can say this DVB device cannot be used at the same time as this V4L device but the actual enforcement of the locking is done in the core. For cases where the devices can be used in parallel, the bridge driver doesn't have to do anything. I follow what you mean. Why I emphasized that it shouldn't be at the core, but basically in the bridge driver: Case 1 - there is a 1:n relation, In this case there is only 1 path and 3 users sharing that path In such a case, You can use such a mentioned scheme, where things do look okay, since it is only about locking a single path. Case 2 - there is a n:n relation, in this case there are n paths and n users In such a case, it is hard to make the core aware of all the details, since there could be more than 1 resource of the same category; Mapping each of them properly won't be easy, as for the same chip driver Resource A on Card A, would mean different for Resource A on Card B. Case 3 - there is a m:n relation, in this case, there are m paths and n users This case is even more painful than the previous ones. In cases 2 3, the option to handle such cases is using a configuration scheme based on the card type. I guess handling such would be quite daunting and hard to get right. I guess it would be much more efficient and useful to have such a feature to be made available in the bridge driver as it is a resource of the card configuration, rather than a common bridge resource. 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: s2-liplianin, mantis: sysfs: cannot create duplicate filename '/devices/virtual/irrcv'
On Mon, Apr 5, 2010 at 1:55 AM, MartinG grons...@gmail.com wrote: Thanks, I've pulled the linuxtv tree, and it compiled, installed and seems to work just fine. No more mantis_ack_wait (0): Slave RACK Fail ! I hope ;). That error is from the older version of my driver. You don't find that error in the updated version. Always try to use a stabler tree[1], or a development version[2], rather than one having unknown changes, unless you know what you are doing: which might not be what happened to you. Use the stabler version if you are faint hearted, or the development version, if you like to be on the bleeding edge of development. Anything other than that, who knows .. Manu [1] http://linuxtv.org/hg/v4l-dvb [2] http://jusst.de/hg/mantis-v4l-dvb -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: STV6110 vs STV6110x
Hi Patrick, On Mon, Apr 5, 2010 at 5:21 PM, Patrick Boettcher pboettc...@kernellabs.com wrote: Hi Igor, hi Manu, I'm currently adding support for a device based on STV0903+STV6110 frontend combination. Early investigation have shown that for both devices there is a driver - now looking in more detail because I'm doing the actual coding, I'm finding out that there is actually 2 drivers for STV6110. Which one I need to/can use for my hardware? From a first glance the actual code is identical (not the coding itself, but the things done). Please advise me what to do? stv090x supports both the STV0900 and STV0903 demodulators. TT S2-1600 (Budget card) uses STV0903 (stv090x)+STV6110A(stv6110x) with budget.c Most likely, you can copy the configuration from budget.c as well for your card. 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] Add FE_CAN_PSK_8 to allow apps to identify PSK_8 capable DVB devices
Hi Klaus, On Sun, Apr 11, 2010 at 1:12 PM, Klaus Schmidinger klaus.schmidin...@tvdr.de wrote: The enum fe_caps provides flags that allow an application to detect whether a device is capable of handling various modulation types etc. A flag for detecting PSK_8, however, is missing. This patch adds the flag FE_CAN_PSK_8 to frontend.h and implements it for the gp8psk-fe.c and cx24116.c driver (apparently the only ones with PSK_8). Only the gp8psk-fe.c has been explicitly tested, though. The FE_CAN_PSK_8 is a misnomer. In fact what you are looking for is FE_CAN_TURBO_FEC FE_CAN_8PSK will be matched by any DVB-S2 capable frontend, so that name is very likely to cause a very large confusion. Another thing I am not entirely sure though ... The cx24116 requires a separate firmware and maybe some necessary code changes (?) for Turbo FEC to be supported, so I wonder whether applying the flag to the cx24116 driver would be any relevant With regards to the Genpix driver, i guess the flag would be necessary. Signed-off-by: Klaus Schmidinger klaus.schmidin...@tvdr.de Tested-by: Derek Kelly user@gmail.com Other than for the naming of the Flag (which i suggest strongly to update the patch) and the application to the cx24116 driver, it looks appropriate; Acked-by: Manu Abraham m...@linuxtv.org --- linux/include/linux/dvb/frontend.h.001 2010-04-05 16:13:08.0 +0200 +++ linux/include/linux/dvb/frontend.h 2010-04-10 12:08:47.0 +0200 @@ -62,6 +62,7 @@ FE_CAN_8VSB = 0x20, FE_CAN_16VSB = 0x40, FE_HAS_EXTENDED_CAPS = 0x80, /* We need more bitspace for newer APIs, indicate this. */ + FE_CAN_PSK_8 = 0x800, /* frontend supports 8psk 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) */ FE_CAN_RECOVER = 0x4000, /* frontend can recover from a cable unplug automatically */ --- linux/drivers/media/dvb/dvb-usb/gp8psk-fe.c.001 2010-04-05 16:13:08.0 +0200 +++ linux/drivers/media/dvb/dvb-usb/gp8psk-fe.c 2010-04-10 12:18:37.0 +0200 @@ -349,7 +349,7 @@ * FE_CAN_QAM_16 is for compatibility * (Myth incorrectly detects Turbo-QPSK as plain QAM-16) */ - FE_CAN_QPSK | FE_CAN_QAM_16 + FE_CAN_QPSK | FE_CAN_QAM_16 | FE_CAN_PSK_8 }, .release = gp8psk_fe_release, --- linux/drivers/media/dvb/frontends/cx24116.c.001 2010-04-05 16:13:08.0 +0200 +++ linux/drivers/media/dvb/frontends/cx24116.c 2010-04-10 13:40:32.0 +0200 @@ -1496,7 +1496,7 @@ FE_CAN_FEC_4_5 | FE_CAN_FEC_5_6 | FE_CAN_FEC_6_7 | FE_CAN_FEC_7_8 | FE_CAN_FEC_AUTO | FE_CAN_2G_MODULATION | - FE_CAN_QPSK | FE_CAN_RECOVER + FE_CAN_QPSK | FE_CAN_RECOVER | FE_CAN_PSK_8 }, .release = cx24116_release, -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 5/8] ir-core: convert mantis from ir-functions.c
On Fri, Apr 16, 2010 at 1:46 AM, David Härdeman da...@hardeman.nu wrote: Convert drivers/media/dvb/mantis/mantis_input.c to not use ir-functions.c (The driver is anyway not complete enough to actually use the subsystem yet). Huh ? I don't follow what you imply here .. -- To unsubscribe from this list: send the line unsubscribe linux-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 5/8] ir-core: convert mantis from ir-functions.c
On Sat, Apr 17, 2010 at 12:56 AM, David Härdeman da...@hardeman.nu wrote: On Fri, Apr 16, 2010 at 03:17:35AM +0400, Manu Abraham wrote: On Fri, Apr 16, 2010 at 1:46 AM, David Härdeman da...@hardeman.nu wrote: Convert drivers/media/dvb/mantis/mantis_input.c to not use ir-functions.c (The driver is anyway not complete enough to actually use the subsystem yet). Huh ? I don't follow what you imply here .. The mantis_input.c file seems to be a skeleton as far as I could tell...not actually in use yet. Or am I mistaken? Only the input related parts of the IR stuff is there in mantis_input.c, the hardware handling is done by mantis_uart.c/h. There is a small bit which has not gone upstream yet, which is pending; http://jusst.de/hg/mantis-v4l-dvb/rev/ad8b00c9edc2 -- To unsubscribe from this list: send the line unsubscribe linux-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: [linux-media] Re: [PATCH] Add FE_CAN_PSK_8 to allow apps to identify PSK_8 capable DVB devices
On Sun, Apr 18, 2010 at 10:34 PM, Klaus Schmidinger klaus.schmidin...@tvdr.de wrote: Eventually, it implies that, all DVB-S2 devices are 8PSK capable, but not all 8PSK capable devices are DVB-S2 capable. Since there are already FE_CAN_* flags for all but PSK_8, I guess it would make sense that all devices that support PSK_8 set the related FE_CAN_PSK_8 flag (or FE_CAN_8PSK, if you insist in continuing the suboptimal naming scheme), independent of the Turbo FEC thing. Now, assume the FE_CAN_PSK8 or FE_CAN8PSK flag; Does it really make any sense, when it is applied to the whole group of 8PSK frontends ? I guess not. You would require a flag that is capable of distinguishing between the S2 8PSK category and the other category. There already is such a flag: FE_CAN_2G_MODULATION. I guess, in the long run, FE_CAN_8PSK or FE_CAN_PSK8 or whatever scheme; might not make any difference between FE_CAN_2G_MODULATION for a satellite delivery system in the long run. Additionally, Turbo FEC is not restricted to 8PSK modulation scheme alone .. http://www.comtechefdata.com/datasheets/ds-cdm600-600L.pdf http://www.datasheetdir.com/CX24114+download That said, I don't really care about the exact naming of the flag, was just a logical thought that came to me between the difference in the error correction mode alone, with no difference to the modulation schema ... Looking back at history, originally France Telecom introduced the superior Error Correction scheme called Turbo Mode or so called Concatenated FEC mode on a 8PSK modulated carrier. This was a great approach, but they wanted to people to pay them a royalty and hence the general acceptance for it went down. In the initial phase, it was implemented in the Americas and for small clients alone. Eventually, the rest of the world wanted a royalty free approach and thus came LDPC which is just as good. So eventually while the difference between these 2 carriers is that while both are 8PSK modulated stream, the Error correction used with France Telecom's proprietary stream is Concatenated Codes, while for S2 and DVB.org it became LDPC. As you can see, the discriminating factor is the FEC, in this condition and nothing else. You will need a flag to discriminate between the FEC types, rather than the modulation, if things were to look more logical. I guess the problem, as I can see now, is that there is now way of telling from the SI data that a transponder uses 8psk turbo fec, or is there? Would it make sense to differentiate this in the following way: - an 8psk transponder on DVB-S is turbo fec - an 8psk transponder on DVB-S2 is *not* turbo fec ? So an 8psk/DVB-S transpoder will require a device that has FE_CAN_TURBO_FEC set, while an 8psk/DVB-S2 transpoder simply requires a DVB-S2 device (since there is no FE_CAN_PSK_8). (I have no real life experience with the Turbo FEC stream), with regards to the satellite_delivrey_system_descriptor: modulation_system will be always DVB-S with regards to Turbo FEC streams and not DVB-S2 while modulation_type will be 8PSK or QPSK for the Turbo FEC capable devices. Maybe someone having a Turbo FEC device can verify this ? Eventually, you would be able to use the flags or a combination of it at the driver side; and with regards to the SI: modulation_system and modulation_type it's possible to handle a 8PSK Turbo FEC stream, but it might be a bit more trickier to handle a QPSK Turbo FEC stream. 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] TT S2-1600 allow more current for diseqc
On Wed, Apr 28, 2010 at 12:33 PM, Guy Martin gms...@tuxicoman.be wrote: On Wed, 28 Apr 2010 09:45:39 +0200 André Weidemann andre.weidem...@web.de wrote: I advise not to pull this change into the kernel sources. The card has only been testet with the a maximum current of 515mA. Anything above is outside the specification for this card. I'm currently running two of these cards in the same box with this patch. Actually, later on I've even set curlim = SEC_CURRENT_LIM_OFF because sometimes diseqc wasn't working fine and that seemed to solve the problem. I would advise to not do this: since disabling current limiting etc will cause a large problem in the case of a short circuit thereby no protection to the hardware. In such an event, it could probably damage the tracks carrying power on the card as well as the tracks on the motherboard, and in some cases the gold finches themselves and or the PCI connector. Generally, there are only a few devices capable of sourcing 0.5A, So I wonder 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 (85 patches) and some misc notes about the devel procedures
On Fri, May 7, 2010 at 4:39 PM, Mauro Carvalho Chehab mche...@redhat.com wrote: Hi, This is the summary of the patches that are currently under review. 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 that some review action is expected. May, 7 2010: [v2] stv6110x Fix kernel null pointer deref when plugging two TT s2-16 http://patchwork.kernel.org/patch/97612 How is this patch going to fix a NULL ptr dereference when more than 1 card is plugged in ? The patch doesn't seem to do what the patch title implies. At least the patch title seems to be wrong. Maybe the patch is supposed to check for a possible NULL ptr dereference when put to sleep ? -- To unsubscribe from this list: send the line unsubscribe linux-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 (85 patches) and some misc notes about the devel procedures
On Fri, May 7, 2010 at 4:39 PM, Mauro Carvalho Chehab mche...@redhat.com wrote: Hi, This is the summary of the patches that are currently under review. Each patch is represented by its submission date, the subject (up to 70 chars) and the patchwork link (if submitted via email). == Port mantis IR to the new API - waiting for Manu Abraham abraham.m...@gmail.com ack or alternative patch == Apr,15 2010: [5/8] ir-core: convert mantis from ir-functions.c This needs to wait for an alternate patch, which depends on linuxtv.org/hg/v4l-dvb proper build -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Status of the patches under review (85 patches) and some misc notes about the devel procedures
On Fri, May 7, 2010 at 4:39 PM, Mauro Carvalho Chehab mche...@redhat.com wrote: Hi, This is the summary of the patches that are currently under review. Each patch is represented by its submission date, the subject (up to 70 chars) and the patchwork link (if submitted via email). May, 2 2010: Add FE_CAN_TURBO_FEC (was: Add FE_CAN_PSK_8 to allow apps to identify http://patchwork.kernel.org/patch/96341 Reviewed-by: Manu Abraham m...@linuxtv.org Acked-by: Manu Abraham m...@linuxtv.org -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: stv090x vs stv0900
2010/5/9 Igor M. Liplianin liplia...@me.by: Also, are they both maintained ? I wrote a patch to add get_frontend to stv090x but stv0900 also does not have it and I don't know which one should get new code. And stv6110x seems to also handle stv6110 which also exists as a separate module... In time when I commit stv0900(stv6110 as well) there wasn't any driver for stv0900/stv0903. Now I'm wondering like you. Quite strange indeed.. http://www.linuxtv.org/pipermail/linux-dvb/2008-November/030492.html http://www.mail-archive.com/linux-media@vger.kernel.org/msg13353.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: stv090x vs stv0900
On Sun, May 9, 2010 at 11:06 PM, Abylai Ospan aos...@netup.ru wrote: Hello, On Thu, 2010-05-06 at 10:46 +0200, Pascal Terjan wrote: Also, are they both maintained ? I wrote a patch to add get_frontend to stv090x but stv0900 also does not have it and I don't know which one should get new code. I have added get_frontend to stv0900 two months ago - http://linuxtv.org/hg/v4l-dvb/rev/a3e28fbefdc3 I'm trying to describe my point of view about two drivers for stv6110 +stv0900. History: I have anounced our card on November 2008 - http://www.linuxtv.org/pipermail/linux-dvb/2008-November/030439.html As you can see I have mentioned that we developing code and will be publish it under GPL. All people in ML received this message. This should be prevent of duplicate work. Also we have obtained permission (signed letter) from STM to publish resulting code under GPL. We have send pull request at Feb 2009 - http://www.mail-archive.com/linux-media@vger.kernel.org/msg02180.html (stv090x commit requested later - in May 2009 - http://www.mail-archive.com/linux-media@vger.kernel.org/msg04978.html ). Solution: Ideally two drivers should be combined into one. stv0900 driver can be used as starting point. We (NetUP Inc.) can initiaite this job. But we need approval from Manu and all community who using stv090x. Manu what do you think about this ? The STV090x driver supports both the STV0900 and STV0903 broadcast demodulators very well and in multiple configurations on couple of bridges (SAA7146, nGene, SAA7160, some USB bridges, some others also in the process) and is quite a generic one. Currently, the STV090x driver handles a lot of quirks which has been documented as well as undocumented by STM, basically being actively supported by STM themselves and by a few card vendors as well, other than for this community to a very great extend. Currently, since the driver has been fine tuned to this great extend and so many users of it, I have no plans of migrating to the STV0900 driver, which was developed later on and tested to a much lesser extend, by developers and vendors alike. So, I am much less inclined to go the STV0900 way. At the behest of STM themselves, I have withheld from adding support for the AAB/AAC chips initially, due to the basic reasons that these advanced features are not really well tested in the field, due to the lack of that many users and the highly unlikely chance that the advanced stuff (ACM/VCM) is yet to be deployed for a home user segment. In the chance that there are more likely users for the advanced stuff, these can be added quite easily to the STV090x/STV6110x driver. Also, interesting point to be noted is that there are no users for ACM/VCM in the Linux userspace for the driver to be supported for any broadcast purposes. The only case in where the Advanced chips are being sold (that too at a higher price) is where card manufacturers who cannot commit themselves to that volume, not that it adds any value to the general user as it is, at the this time. Simply adding in code and making it unmaintainable makes no sense to me at least. -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [hg:v4l-dvb] Add FE_CAN_PSK_8 to allow apps to identify PSK_8 capable DVB devices
On Mon, May 10, 2010 at 9:45 PM, Klaus Schmidinger klaus.schmidin...@tvdr.de wrote: On 10.05.2010 06:40, Patch from Klaus Schmidinger wrote: The patch number 14692 was added via Douglas Schilling Landgraf dougsl...@redhat.com to http://linuxtv.org/hg/v4l-dvb master development tree. Kernel patches in this development tree may be modified to be backward compatible with older kernels. Compatibility modifications will be removed before inclusion into the mainstream Kernel If anyone has any objections, please let us know by sending a message to: Linux Media Mailing List linux-media@vger.kernel.org This patch should not have been applied, as was decided in the original thread. I'm still waiting for any response to my new patch, posted in [PATCH] Add FE_CAN_TURBO_FEC (was: Add FE_CAN_PSK_8 to allow apps to identify PSK_8 capable DVB devices) which replaces my original suggestion. I did a reply but that happened to be on another thread on patchwork, but here it is again. Reviewed-by: Manu Abraham manu at linuxtv.org Acked-by: Manu Abraham manu at linuxtv.org -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: What ever happened to standardizing signal level?
On Mon, Jun 7, 2010 at 2:01 AM, hermann pitton hermann-pit...@arcor.de wrote: Am Donnerstag, den 03.06.2010, 22:18 -0700 schrieb VDR User: hermann pitton hermann-pit...@arcor.de, you are contributing absolutely nothing to this thread aside of annoying people with your by trolling and half incoherent nonsense. It's quite ironic you suggest _I_ am the one trolling when this is a thread _I_ created. And further, several people have posted legitimate responses to -- clearly you are the only one suffering from your delusion. Dream on. The question never was, if you are trolling from time to time, but only if you are a duplicate of another troll or on your own. I have talked with Mauro about that and since then I ask you to provide your full name or point at least to a patch from you, where you have to agree to provide your real name in your SOB line. There was none and you also did not point to somebody else, to confirm for us, that you are known and on kernel development not only as a troll. You did not give an sufficient answer during the last two years. Additionally you've been stalking me in email as well. Your behavior is not only uncalled for, it's abusive of both this mailing list and the people willingly participating in the discussion. As I understand it, this is not the first time you've been the source of harassment. The opposite again is true, you stalked me by private e-mail and therefor my reply went as copy also to Mauro and Manu. If even Manu does not have your contact data, who else? Please provide them at least to him or someone else you trust and you are free for rants, within limitations. Sorry, that I could not reply in-time. I had been traveling and hence. Also, with little free time in between additionally. Hermann, what's going on ? I don't see the reason for such a long thread, nor can't believe that time is so cheap .. Anyway ... He doesn't do much of coding, or maybe next to nothing. But he does test hardware and drivers, from what I know, for quite a long time from the time of the FF cards. I know his real name as Derek Kelly and on IRC as hotwings. Well, I do appreciate the time he puts into testing, as it helps to make realize code better, or identify hardware bugs etc. At least a couple of times, I was able to find bugs in my own code, thanks to him. But the other side, unlike most people, he seemed to not have a taste for taking credits at all (don't know why, eventhough I had pointed out to him a few times) .. 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
buffer management
Hi All, While working on a driver, i stumbled up on this question. I have a driver where the driver allocates it's buffers (maybe it's better to term that the hardware requires it that way) in the following fashion: Buffer 1: SG list 1 Buffer 2: SG list 2 Buffer 3: SG list 3 Buffer 4: SG list 4 Buffer 5: SG list 5 Buffer 6: SG list 6 Buffer 7: SG list 7 Buffer 8: SG list 8 Now, on each video interrupt, I know which SG list i need to read from. At this stage i do need to copy the buffers associated with each of the SG lists at once. In this scenario, I don't see how videobuf could be used, while I keep getting this feeling that a simple copy_to_user of the entire buffer could do the whole job in a better way, since the buffers themselves are already managed and initialized already. Am I correct in thinking so, or is it that I am overlooking something ? Comments ? 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: saa716x compile warnings
Jan Engelhardt wrote: Hi, I noticed in a forum post that the saa716x driver spews warnings on x86_64: http://www.linux-club.de/viewtopic.php?f=41t=100240 /home/johnny/Documents/saa716x-e9cc5826649c/v4l/saa716x_dma.c:129: warning: cast from pointer to integer of different size as I look into the code (tip just moments ago), that seems to be largely true: /* align memory to page */ dmabuf-mem_virt = (void *) PAGE_ALIGN (((u32) dmabuf-mem_virt_noalign)); I always recommend building it not only on x86 to catch such errors. Truncating to (u32) is likely to be wrong for 64-bit systems! Fixed now. 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: [linux-dvb] S2API (pctv452e) artefacts in video stream
da...@gmx.de wrote: Hi again, has anybody an idea what's going wrong here? I'm still having this problem. Is there anything I can do to help here? Thanks in advance, darav P.S.: now posting on the new mailinglist. Sorry for double-post. Jan 28 12:03:09 vdr ttusb2: i2c transfer failed. Jan 28 12:03:11 vdr dvb-usb: bulk message failed: -110 (9/0) Jan 28 12:03:11 vdr ttusb2: there might have been an error during control message transfer. (rlen = 3, was 0) Jan 28 12:03:11 vdr ttusb2: i2c transfer failed. Jan 28 12:03:13 vdr dvb-usb: bulk message failed: -110 (9/0) Jan 28 12:03:13 vdr ttusb2: there might have been an error during control message transfer. (rlen = 3, was 0) Jan 28 12:03:13 vdr ttusb2: i2c transfer failed. Looks like the demodulator did not respond at all, maybe it went bad. Does your device work in a windows environment ? 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: Re : [linux-dvb] Technotrend Budget S2-3200 Digital artefacts on HDchannels
crow wrote: Hi, I have also TT-3200 and would like to have driver which are not able to burn anything, but to WORK as they should. I am currently using liplianindvb repository, because it seems only one working with my card. To bad that they have code which can burn demodulator in some case, as i don't wanna that. Well till now i have had luck then seems so, but I can use multiproto driver to but they should work OK with tt-3200 (i can test them to if needed) have only Astra 19.2E and Hotbird 13.0. You can use either multiproto or S2API according to your desire. The S2API based driver is found here: http://jusst.de/hg/v4l-dvb If you want to try the multiproto version the driver is found here: http://jusst.de/hg/multiproto Please do a vanilla test of the v4l-dvb tree (from jusst.de), whether you see any further difference. Please try the changes that which i posted on top of the multiproto or the v4l-dvb tree and test your changes. You can test with loading the modules with the verbose=5 option, such that you can see what's happening internally. To test, rather than doing a scan, you should try doing a szap, since it is better for testing and to find issues. Testing with scan will not help much as there will be other issues involved in it 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: [linuxtv-commits] [hg:v4l-dvb] DVB: negative internal-sub_range won't get noticed
Mauro,
Please revert this patch as it is incorrect. A correct version is
available at http://jusst.de/hg/v4l-dvb which is undergoing tests.
http://jusst.de/hg/v4l-dvb/rev/368dc6078295
Why did you have to hastily apply this patch, especially when i
mentioned this earlier ?
Regards,
Manu
Patch from Roel Kluin wrote:
The patch number 10393 was added via Mauro Carvalho Chehab
mche...@redhat.com
to http://linuxtv.org/hg/v4l-dvb master development tree.
Kernel patches in this development tree may be modified to be backward
compatible with older kernels. Compatibility modifications will be
removed before inclusion into the mainstream Kernel
If anyone has any objections, please let us know by sending a message to:
Linux Media Mailing List linux-media@vger.kernel.org
--
From: Roel Kluin roel.kl...@gmail.com
DVB: negative internal-sub_range won't get noticed
internal-sub_range is unsigned, a negative won't get noticed.
Signed-off-by: Roel Kluin roel.kl...@gmail.com
Signed-off-by: Andrew Morton a...@linux-foundation.org
Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com
---
linux/drivers/media/dvb/frontends/stb0899_algo.c |9 +
1 file changed, 5 insertions(+), 4 deletions(-)
diff -r 6ca70bcb4972 -r d3bfc53d0b67
linux/drivers/media/dvb/frontends/stb0899_algo.c
--- a/linux/drivers/media/dvb/frontends/stb0899_algo.cWed Jan 14
16:17:59 2009 +
+++ b/linux/drivers/media/dvb/frontends/stb0899_algo.cSun Jan 18
23:31:26 2009 +
@@ -467,12 +467,13 @@ static void next_sub_range(struct stb089
if (internal-sub_dir 0) {
old_sub_range = internal-sub_range;
- internal-sub_range = MIN((internal-srch_range / 2) -
+ if (internal-tuner_offst + internal-sub_range / 2 =
+ internal-srch_range / 2)
+ internal-sub_range = 0;
+ else
+ internal-sub_range = MIN((internal-srch_range / 2) -
(internal-tuner_offst +
internal-sub_range / 2),
internal-sub_range);
-
- if (internal-sub_range 0)
- internal-sub_range = 0;
internal-tuner_offst += (old_sub_range + internal-sub_range)
/ 2;
}
---
Patch is available at:
http://linuxtv.org/hg/v4l-dvb/rev/d3bfc53d0b678da495fd2b559e154c5e95584079
___
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: Re : [linux-dvb] Re : Technotrend Budget S2-3200 Digital artefacts on HDchannels
Manu wrote: Le 02.02.2009 18:43:33, Chris Silva a écrit : On Tue, Jan 27, 2009 at 9:13 PM, Manu Abraham abraham.m...@gmail.com wrote: Alex Betis wrote: On Tue, Jan 27, 2009 at 9:56 PM, Manu Abraham abraham.m...@gmail.comwrote: Hmm OK, but is there by any chance a fix for those issues somewhere or in the pipe at least? I am willing to test (as I already offered), I can compile the drivers, spread printk or whatever else is needed to get useful reports. Let me know if I can help sort this problem. BTW in my case it is DVB-S2 3 SR and FEC 5/6. It was quite not appreciable on my part to provide a fix or reply in time nor spend much time on it earlier, but that said i was quite stuck up with some other things. Can you please pull a copy of the multiproto tree http://jusst.de/hg/multiproto or the v4l-dvb tree from http://jusst.de/hg/v4l-dvb and apply the following patch and comment what your result is ? Before applying please do check whether you still have the issues. Manu, I've tried to increase those timers long ago when played around with my card (Twinhan 1041) and scan utility. I must say that I've concentrated mostly on DVB-S channels that wasn't always locking. I didn't notice much improvements. The thing that did help was increasing the resolution of scan zigzags. With regards to the zig-zag, one bug is fixed in the v4l-dvb tree. Most likely you haven't tried that change. I've sent a patch on that ML and people were happy with the results. I did look at your patch, but that was completely against the tuning algorithm. [..] I believe DVB-S2 lock suffer from the same problem, but in that case the zigzag is done in the chip and not in the driver. Along with the patch i sent, does the attached patch help you in anyway (This works out for DVB-S2 only)? Manu, I've tried both multiproto branches you indicated above, *with* and *without* the patches you sent to the ML (fix_iterations.patch and increase timeout.patch) on this thread. Sadly, same behavior as S2API V4L-DVB current branch. No lock on 3 3/4 channels. It achieves a 0.5 second jittery sound but no image. It seems the driver is struggling to correctly lock on that channel, but doesn't get there in time... Or maybe the hardware... Dunno... Can you please send me a complete trace with the stb6100 and stb0899 modules loaded with verbose=5 for the 30MSPS transponder what you are trying ? One simple szap would be enough (no scan please) based on the http://jusst.de/hg/v4l-dvb tree. Before you start testing, start clean from a cold boot after a powerdown. This makes it a bit more easier identify things. 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] Mantis Update was Re: Twinhan DTV Ter-CI (3030 Mantis) ???
Carl Oscar Ejwertz wrote: Hi Manu! Tried the new drivers but it doesn't work.. I get errors in dmesg. [ 1304.254458] Mantis :01:06.0: PCI INT A - Link[APC1] - GSI 16 (level, low) - IRQ 16 [ 1304.258997] DVB: registering new adapter (Mantis DVB adapter) [ 1304.676816] Mantis :01:06.0: PCI INT A disabled [ 1304.678509] Mantis: probe of :01:06.0 failed with error -1 Is it something easy to fix? Please try again with a fresh clone/update. 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] 2033 not working with changeset 9143
Bob Deblier wrote: On Sat, 2009-02-07 at 23:03 +0100, Ruediger Dohmhardt wrote: Manu Abraham schrieb: Ruediger Dohmhardt wrote: Manu Abraham schrieb: Have added initial support for this card, as well as a large overhaul of the driver for a couple of performance impacts. Please do test with the latest updates from http://jusst.de/hg/mantis. Hi Manu the versions from January and February 2009 compile fine on the SUSE-11.1 kernel 2.6.27.7-9-default x86_64. The modules for my Twinhan AD-CP300 (2033) load fine, too. However, the devices below /dev/dvb are NOT created, and hence vdr-1.7 does not work. The card works with the s2-liplianin driver. I assume it is interrupt related as listed in the lines from /var/log/messages Feb 7 21:03:38 mt40 su: (to root) rudi on /dev/pts/1 Feb 7 21:03:48 mt40 kernel: vendor=1002 device=4371 Feb 7 21:03:48 mt40 kernel: Mantis :02:01.0: PCI INT A - GSI 21 (level, low) - IRQ 21 Feb 7 21:03:48 mt40 kernel: DVB: registering new adapter (Mantis DVB adapter) Feb 7 21:03:48 mt40 kernel: vendor=1002 device=4371 Feb 7 21:03:48 mt40 kernel: Mantis :02:01.0: PCI INT A disabled Feb 7 21:03:48 mt40 kernel: Mantis: probe of :02:01.0 failed with error -1 Feb 7 21:05:03 mt40 vdr: [4320] cTimeMs: using monotonic clock (resolution is 1 ns) Feb 7 21:05:03 mt40 vdr: [4320] VDR version 1.7.0 started Feb 7 21:05:03 mt40 vdr: [4320] codeset is 'UTF-8' - known Feb 7 21:05:03 mt40 vdr: [4320] ERROR: ./locale: Datei oder Verzeichnis nicht gefunden Feb 7 21:05:03 mt40 vdr: [4320] no locale for language code 'deu,ger' Feb 7 21:05:03 mt40 vdr: [4320] no locale for language code 'slv,slo' Feb 7 21:05:03 mt40 vdr: [4320] no locale for language code 'ita' Feb 7 21:05:05 mt40 vdr: [4320] no DVB device found I wonder whether I can check something more to get your driver back to work Can you please load the mantis module with the verbose=5 module parameter and try again ? At least it will show what's failing. Regards, Manu Yupp, here is /var/log/messages with the line options mantis verbose=5 in /etc/modprobe.conf.local Feb 7 22:56:41 mt40 kernel: found a VP-2033 PCI DVB-C device on (02:01.0), Feb 7 22:56:41 mt40 kernel: vendor=1002 device=4371 Feb 7 22:56:41 mt40 kernel: Mantis :02:01.0: PCI INT A - GSI 21 (level, low) - IRQ 21 Feb 7 22:56:41 mt40 kernel: Mantis Rev 1 [1822:0008], irq: 21, latency: 64 Feb 7 22:56:41 mt40 kernel: memory: 0x0, mmio: 0xc2366000 Feb 7 22:56:41 mt40 kernel: mantis_stream_control (0): Set stream to HIF Feb 7 22:56:41 mt40 kernel: mantis_i2c_init (0): Initializing I2C .. Feb 7 22:56:41 mt40 kernel: mantis_i2c_init (0): Disabling I2C interrupt Feb 7 22:56:41 mt40 kernel: mantis_i2c_xfer (0): Messages:2 Feb 7 22:56:41 mt40 kernel: mantis_i2c_write: Address=[0x50] W[ 08 ] Feb 7 22:56:41 mt40 kernel: mantis_i2c_read: Address=[0x50] R[ 00 08 ca 19 e9 b6 ] Feb 7 22:56:41 mt40 kernel: MAC Address=[00:08:ca:19:e9:b6] Feb 7 22:56:41 mt40 kernel: mantis_dma_init (0): Mantis DMA init Feb 7 22:56:41 mt40 kernel: mantis_alloc_buffers (0): DMA=0x60df cpu=0x880060df size=65536 Feb 7 22:56:41 mt40 kernel: mantis_alloc_buffers (0): RISC=0x60dba000 cpu=0x880060dba000 size=1000 Feb 7 22:56:41 mt40 kernel: mantis_calc_lines (0): Mantis RISC block bytes=[4096], line bytes=[2048], line count=[32] Feb 7 22:56:41 mt40 kernel: mantis_dvb_init (0): dvb_register_adapter Feb 7 22:56:41 mt40 kernel: DVB: registering new adapter (Mantis DVB adapter) Feb 7 22:56:41 mt40 kernel: mantis_dvb_init (0): dvb_dmx_init Feb 7 22:56:41 mt40 kernel: mantis_dvb_init (0): dvb_dmxdev_init Feb 7 22:56:41 mt40 kernel: vp2033_frontend_init (0): Probing for CU1216 (DVB-C) Feb 7 22:56:41 mt40 kernel: mantis_i2c_xfer (0): Messages:2 Feb 7 22:56:41 mt40 kernel: Byte MODE: Feb 7 22:56:41 mt40 kernel: Byte 0 RXD=0xa1ff2280 [22] Feb 7 22:56:41 mt40 kernel: mantis_i2c_xfer (0): Messages:2 Feb 7 22:56:41 mt40 kernel: Byte MODE: Feb 7 22:56:41 mt40 kernel: mantis_i2c_xfer (0): I/O error, LINE:155 Feb 7 22:56:41 mt40 kernel: mantis_i2c_xfer (0): Messages:2 Feb 7 22:56:41 mt40 kernel: Byte MODE: Feb 7 22:56:41 mt40 kernel: Byte 0 RXD=0xa1ff2280 [22] Feb 7 22:56:41 mt40 kernel: mantis_i2c_xfer (0): Messages:1 Feb 7 22:56:41 mt40 kernel: mantis_i2c_write: Address=[0x0c] W[ 00 33 ] Feb 7 22:56:41 mt40 kernel: mantis_i2c_xfer (0): Messages:2 Feb 7 22:56:42 mt40 kernel: Byte MODE: Feb 7 22:56:42 mt40 kernel: mantis_i2c_xfer (0): I/O error, LINE:155 Feb 7 22:56:42 mt40 kernel: mantis_dvb_init (0): !!! NO Frontends found !!! Feb 7 22:56:42 mt40 kernel: mantis_pci_probe (0): ERROR: Mantis DVB initialization failed -1 Feb 7 22:56:42 mt40 kernel: mantis_pci_probe (0): ERROR: Mantis DMA exit! -1 Feb 7 22:56:42 mt40 kernel
Re: [linux-dvb] Mantis Update was Re: Twinhan DTV Ter-CI (3030 Mantis) ???
Carl Oscar Ejwertz wrote: Sad to say that I still get the same error after a fresh clone and compile. Is there any info that I can supply that can help getting this card working? What's the error that you see ? Did a quick test on the following cards: VP-1041, VP-2033, VP-3030 The logs look as follows, do you see any different ? Regards, Manu found a VP-1041 PCI DSS/DVB-S/DVB-S2 device on (04:04.0), ACPI: PCI Interrupt :04:04.0[A] - GSI 22 (level, low) - IRQ 22 Mantis Rev 1 [1822:0031], irq: 22, latency: 32 memory: 0x0, mmio: 0xf93aa000 mantis_stream_control (0): Set stream to HIF mantis_i2c_init (0): Initializing I2C .. mantis_i2c_init (0): Disabling I2C interrupt mantis_i2c_xfer (0): Messages:2 mantis_i2c_write: Address=[0x50] W[ 08 ] mantis_i2c_read: Address=[0x50] R[ 00 08 ca 1c 42 c9 ] MAC Address=[00:08:ca:1c:42:c9] mantis_dma_init (0): Mantis DMA init mantis_alloc_buffers (0): DMA=0x325c cpu=0xf25c size=65536 mantis_alloc_buffers (0): RISC=0x32463000 cpu=0xf2463000 size=1000 mantis_calc_lines (0): Mantis RISC block bytes=[4096], line bytes=[2048], line count=[32] mantis_dvb_init (0): dvb_register_adapter DVB: registering new adapter (Mantis DVB adapter) mantis_dvb_init (0): dvb_dmx_init mantis_dvb_init (0): dvb_dmxdev_init mantis_frontend_power (0): Power ON gpio_set_bits (0): Set Bit 12 to 1 gpio_set_bits (0): GPIO Value 1000 gpio_set_bits (0): Set Bit 12 to 1 gpio_set_bits (0): GPIO Value 1000 mantis_frontend_soft_reset (0): Frontend RESET gpio_set_bits (0): Set Bit 13 to 0 gpio_set_bits (0): GPIO Value 1000 gpio_set_bits (0): Set Bit 13 to 0 gpio_set_bits (0): GPIO Value 1000 gpio_set_bits (0): Set Bit 13 to 1 gpio_set_bits (0): GPIO Value 3000 gpio_set_bits (0): Set Bit 13 to 1 gpio_set_bits (0): GPIO Value 3000 stb0899_write_regs [0xf1b6]: 02 mantis_i2c_xfer (0): Messages:1 mantis_i2c_write: Address=[0x68] W[ f1 b6 02 ] stb0899_write_regs [0xf1c2]: 00 mantis_i2c_xfer (0): Messages:1 mantis_i2c_write: Address=[0x68] W[ f1 c2 00 ] stb0899_write_regs [0xf1c3]: 00 mantis_i2c_xfer (0): Messages:1 mantis_i2c_write: Address=[0x68] W[ f1 c3 00 ] mantis_i2c_xfer (0): Messages:2 mantis_i2c_write: Address=[0x68] W[ f0 00 ] mantis_i2c_read: Address=[0x68] R[ 82 ] _stb0899_read_reg: Reg=[0xf000], data=82 stb0899_get_dev_id: ID reg=[0x82] stb0899_get_dev_id: Device ID=[8], Release=[2] mantis_i2c_xfer (0): Messages:1 mantis_i2c_write: Address=[0x68] W[ f3 fc 00 04 00 00 ] mantis_i2c_xfer (0): Messages:1 mantis_i2c_write: Address=[0x68] W[ f3 34 ] mantis_i2c_xfer (0): Messages:1 mantis_i2c_read: Address=[0x68] R[ 31 44 4d 44 ] mantis_i2c_xfer (0): Messages:1 mantis_i2c_write: Address=[0x68] W[ f3 34 ] mantis_i2c_xfer (0): Messages:1 mantis_i2c_read: Address=[0x68] R[ 31 44 4d 44 ] _stb0899_read_s2reg Device=[0xf3fc], Base address=[0x0400], Offset=[0xf334], Data=[0x444d4431] mantis_i2c_xfer (0): Messages:1 mantis_i2c_write: Address=[0x68] W[ f3 fc 00 04 00 00 ] mantis_i2c_xfer (0): Messages:1 mantis_i2c_write: Address=[0x68] W[ f3 00 ] mantis_i2c_xfer (0): Messages:1 mantis_i2c_read: Address=[0x68] R[ 01 00 00 00 ] mantis_i2c_xfer (0): Messages:1 mantis_i2c_write: Address=[0x68] W[ f3 3c ] mantis_i2c_xfer (0): Messages:1 mantis_i2c_read: Address=[0x68] R[ 01 00 00 00 ] _stb0899_read_s2reg Device=[0xf3fc], Base address=[0x0400], Offset=[0xf33c], Data=[0x0001] stb0899_get_dev_id: Demodulator Core ID=[DMD1], Version=[1] mantis_i2c_xfer (0): Messages:1 mantis_i2c_write: Address=[0x68] W[ fa fc 00 08 00 00 ] mantis_i2c_xfer (0): Messages:1 mantis_i2c_write: Address=[0x68] W[ fa 00 ] mantis_i2c_xfer (0): Messages:1 mantis_i2c_read: Address=[0x68] R[ 4c 00 00 00 ] mantis_i2c_xfer (0): Messages:1 mantis_i2c_write: Address=[0x68] W[ fa 2c ] mantis_i2c_xfer (0): Messages:1 mantis_i2c_read: Address=[0x68] R[ 31 43 45 46 ] _stb0899_read_s2reg Device=[0xfafc], Base address=[0x0800], Offset=[0xfa2c], Data=[0x46454331] mantis_i2c_xfer (0): Messages:1 mantis_i2c_write: Address=[0x68] W[ fa fc 00 08 00 00 ] mantis_i2c_xfer (0): Messages:1 mantis_i2c_write: Address=[0x68] W[ fa 34 ] mantis_i2c_xfer (0): Messages:1 mantis_i2c_read: Address=[0x68] R[ 01 00 00 00 ] mantis_i2c_xfer (0): Messages:1 mantis_i2c_write: Address=[0x68] W[ fa 34 ] mantis_i2c_xfer (0): Messages:1 mantis_i2c_read: Address=[0x68] R[ 01 00 00 00 ] _stb0899_read_s2reg Device=[0xfafc], Base address=[0x0800], Offset=[0xfa34], Data=[0x0001] stb0899_get_dev_id: FEC Core ID=[FEC1], Version=[1] stb0899_attach: Attaching STB0899 vp1041_frontend_init (0): found STB0899 DVB-S/DVB-S2 frontend @0x68 stb6100_attach: Attaching STB6100 mantis_i2c_xfer (0): Messages:1 mantis_i2c_write: Address=[0x08] W[ 40 ] vp1041_frontend_init (0): Done! DVB: registering frontend 0 (STB0899
Re: The right way to interpret the content of SNR, signal strength and BER from HVR 4000 Lite
Devin Heitmueller wrote:
On Thu, Mar 19, 2009 at 6:17 PM, Trent Piepho xy...@speakeasy.org wrote:
On Thu, 19 Mar 2009, Trent Piepho wrote:
Since the driver often needs to use a logarithm from dvb-math to find SNR,
you have code like this in the driver (from lgdt3305.c):
/* report SNR in dB * 10 */
*snr = (state-snr / ((1 24) / 10));
The SNR(dB) will be given by:
SNR(dB) = driver_SNR_measure / 256;
For the driver side, also from lgdt3305 which has both formats with an
ifdef:
/* convert from 8.24 fixed-point to 8.8 */
*snr = (state-snr) 16;
FWIW, converting to decimal to print using only integer math:
/* decimal fixed point */
printf(%d.%d dB\n, snr / 10, snr % 10);
/* binary fixed point */
printf(%d.%02d dB\n, snr 8, (snr 0xff) * 100 8);
One more example, converting SNR into a 32-bit floating point number using
only integer operations. These don't do negative numbers but if the SNR
format used a sign bit it would be very easy to add, as IEEE 754 floating
point uses a sign bit too. I would need to think about it more to do 2's
complement.
For binary fixed point the conversion to a float is exact. For decimal
fixed point it's not. For example 334 (33.4 dB) will become 33.42 dB
when converted to floating point.
/* For 8.8 binary fixed point, this is the no-float version of:
* float snr_to_float(u16 snr) { return snr / 256.0 } */
u32 snr_to_float(u16 snr)
{
unsigned int e = 23 - __fls(snr);
return snr ? ((snr e) 0x7f) | ((142 - e) 23) : 0;
}
/* For .1 decimal fixed point. NOTE: This will overflow the 32-bit
* intermediate value if SNR is above 1638.3 dB! This is the no-float
* version of:
* float snr_to_float(u16 snr) { return snr / 10.0 } */
u32 snr10_to_float(u16 snr)
{
unsigned int e = 23 - __fls(snr / 10);
return snr ? snr e) + 5) / 10) 0x7f) | (150 - e) 23 :
0;
}
You'd use the function like this:
float f;
*(u32 *)f = snr_to_float(snr);
== rant mode on ==
Wow, I think we have lost our minds!
The argument being put forth is based on the relative efficiency of
the multiply versus divide opcodes on modern CPU architectures?? And
that you're going to be able to get an SNR with a higher level of
precision than 0.1 dB?? (if the hardware suggests that it can then
it's LYING to you)
If that is the extent of the compelling argument that can be made,
then so be it. But after reading this, I'm kind of dumbfounded that
this is the basis for proposing 8.8 format over just sending it back
in 0.1dB increments. We have officially entered the realm of
ridiculous.
I have been going through this thread with much interest to see
where it was going.
In fact, what i found after reading the emails in this thread:
People would like to see standardized Signal stats in whatever apps
they like.
* Some users prefer a dB scale
* Some users prefer a percent scale
* Some prefer a relative scale.
Some need a signal monitor to do specific activity.
All this needs one to require the existing format into one common
format as required, which needs all drivers to be converted.
The Pros:
* Application can just read the value from the IOCTL and be happy
dispalying the value.
The Cons:
* Converting all drivers is no joke. Many drivers are Reverse
Engineered, Some are written from specs, Some are written from
sample code.
* Assuming that everything is alright, many do think that statistics
can be just used in a 1:1 proportion depending on some sample code.
But it has to be borne in mind that it is for a very specific
reference platform that it is. Lot of things do affect it directly.
Eventually what you consider statistics from a demod driver, from
where you get statistics, depends on other frontend components.
* Now assume that it is correct for the reference platform too..
Just think how many users are really conversant with all those units
and how to interpret it .. ? I would say hardly few ...
* Doing format/protocol conversions in kernel is not something
that's appreciated.
* Different types of conversions would be needed. All the conersions
need to be foolproof, else you shoot your foot, with some odd values
as well..
* This concept provides a single format with little or no flexibility.
I had been thinking a bit on this in the large view. My idea was
that it would be better not not to modify any driver as it is, but
get that value out to userspace with that exact representation.
The current existing API does the statistics correctly, but all it
needs is that the user/application needs to be told what units it
expects the statistics in.
That said, i did a small implementation, with almost all parctical
possible combinations.
The Pros:
* Application can choose whether it wants to display the statistics
in a specific way the application would like
* Application can also choose what format the driver
Re: The right way to interpret the content of SNR, signal strength and BER from HVR 4000 Lite
Manu Abraham wrote:
Devin Heitmueller wrote:
On Thu, Mar 19, 2009 at 6:17 PM, Trent Piepho xy...@speakeasy.org wrote:
On Thu, 19 Mar 2009, Trent Piepho wrote:
Since the driver often needs to use a logarithm from dvb-math to find SNR,
you have code like this in the driver (from lgdt3305.c):
/* report SNR in dB * 10 */
*snr = (state-snr / ((1 24) / 10));
The SNR(dB) will be given by:
SNR(dB) = driver_SNR_measure / 256;
For the driver side, also from lgdt3305 which has both formats with an
ifdef:
/* convert from 8.24 fixed-point to 8.8 */
*snr = (state-snr) 16;
FWIW, converting to decimal to print using only integer math:
/* decimal fixed point */
printf(%d.%d dB\n, snr / 10, snr % 10);
/* binary fixed point */
printf(%d.%02d dB\n, snr 8, (snr 0xff) * 100 8);
One more example, converting SNR into a 32-bit floating point number using
only integer operations. These don't do negative numbers but if the SNR
format used a sign bit it would be very easy to add, as IEEE 754 floating
point uses a sign bit too. I would need to think about it more to do 2's
complement.
For binary fixed point the conversion to a float is exact. For decimal
fixed point it's not. For example 334 (33.4 dB) will become 33.42 dB
when converted to floating point.
/* For 8.8 binary fixed point, this is the no-float version of:
* float snr_to_float(u16 snr) { return snr / 256.0 } */
u32 snr_to_float(u16 snr)
{
unsigned int e = 23 - __fls(snr);
return snr ? ((snr e) 0x7f) | ((142 - e) 23) : 0;
}
/* For .1 decimal fixed point. NOTE: This will overflow the 32-bit
* intermediate value if SNR is above 1638.3 dB! This is the no-float
* version of:
* float snr_to_float(u16 snr) { return snr / 10.0 } */
u32 snr10_to_float(u16 snr)
{
unsigned int e = 23 - __fls(snr / 10);
return snr ? snr e) + 5) / 10) 0x7f) | (150 - e) 23
: 0;
}
You'd use the function like this:
float f;
*(u32 *)f = snr_to_float(snr);
== rant mode on ==
Wow, I think we have lost our minds!
The argument being put forth is based on the relative efficiency of
the multiply versus divide opcodes on modern CPU architectures?? And
that you're going to be able to get an SNR with a higher level of
precision than 0.1 dB?? (if the hardware suggests that it can then
it's LYING to you)
If that is the extent of the compelling argument that can be made,
then so be it. But after reading this, I'm kind of dumbfounded that
this is the basis for proposing 8.8 format over just sending it back
in 0.1dB increments. We have officially entered the realm of
ridiculous.
I have been going through this thread with much interest to see
where it was going.
In fact, what i found after reading the emails in this thread:
People would like to see standardized Signal stats in whatever apps
they like.
* Some users prefer a dB scale
* Some users prefer a percent scale
* Some prefer a relative scale.
Some need a signal monitor to do specific activity.
All this needs one to require the existing format into one common
format as required, which needs all drivers to be converted.
The Pros:
* Application can just read the value from the IOCTL and be happy
dispalying the value.
The Cons:
* Converting all drivers is no joke. Many drivers are Reverse
Engineered, Some are written from specs, Some are written from
sample code.
* Assuming that everything is alright, many do think that statistics
can be just used in a 1:1 proportion depending on some sample code.
But it has to be borne in mind that it is for a very specific
reference platform that it is. Lot of things do affect it directly.
Eventually what you consider statistics from a demod driver, from
where you get statistics, depends on other frontend components.
* Now assume that it is correct for the reference platform too..
Just think how many users are really conversant with all those units
and how to interpret it .. ? I would say hardly few ...
* Doing format/protocol conversions in kernel is not something
that's appreciated.
* Different types of conversions would be needed. All the conersions
need to be foolproof, else you shoot your foot, with some odd values
as well..
* This concept provides a single format with little or no flexibility.
I had been thinking a bit on this in the large view. My idea was
that it would be better not not to modify any driver as it is, but
get that value out to userspace with that exact representation.
The current existing API does the statistics correctly, but all it
needs is that the user/application needs to be told what units it
expects the statistics in.
That said, i did a small implementation, with almost all parctical
possible combinations.
The Pros:
* Application can choose whether it wants to display the statistics
in a specific way
Re: The right way to interpret the content of SNR, signal strength and BER from HVR 4000 Lite
Andy Walls wrote:
On Fri, 2009-03-20 at 10:55 +0400, Manu Abraham wrote:
Manu Abraham wrote:
I have been going through this thread with much interest to see
where it was going.
In fact, what i found after reading the emails in this thread:
People would like to see standardized Signal stats in whatever apps
they like.
* Some users prefer a dB scale
* Some users prefer a percent scale
* Some prefer a relative scale.
Some need a signal monitor to do specific activity.
All this needs one to require the existing format into one common
format as required, which needs all drivers to be converted.
The Pros:
* Application can just read the value from the IOCTL and be happy
dispalying the value.
The Cons:
* Converting all drivers is no joke. Many drivers are Reverse
Engineered, Some are written from specs, Some are written from
sample code.
* Assuming that everything is alright, many do think that statistics
can be just used in a 1:1 proportion depending on some sample code.
But it has to be borne in mind that it is for a very specific
reference platform that it is. Lot of things do affect it directly.
Eventually what you consider statistics from a demod driver, from
where you get statistics, depends on other frontend components.
* Now assume that it is correct for the reference platform too..
Just think how many users are really conversant with all those units
and how to interpret it .. ? I would say hardly few ...
* Doing format/protocol conversions in kernel is not something
that's appreciated.
* Different types of conversions would be needed. All the conersions
need to be foolproof, else you shoot your foot, with some odd values
as well..
* This concept provides a single format with little or no flexibility.
I had been thinking a bit on this in the large view. My idea was
that it would be better not not to modify any driver as it is, but
get that value out to userspace with that exact representation.
The current existing API does the statistics correctly, but all it
needs is that the user/application needs to be told what units it
expects the statistics in.
That said, i did a small implementation, with almost all parctical
possible combinations.
The Pros:
* Application can choose whether it wants to display the statistics
in a specific way the application would like
* Application can also choose what format the driver provides too..
* Format conversions are simple at userspace
* The driver just mentions what format it is using and sends out the
values are being read and calculated for the hardware requirements.
No conversions are done in the driver.
The Cons:
* The application has to do the format conversion. ie the driver
does not force the application to use a specific format. In other
words, it is more flexibility to the application.
That said, my thoughts follow thus. I guess it hardly needs any
explanation. But if any queries, i am here around.
/* Frontend General Statistics
* General parameters
* FE_*_UNKNOWN:
* Parameter is unknown to the frontend and doesn't really
* make any sense for an application.
*
* FE_*_RELATIVE:
* Parameter is relative on the basis of a ceil - floor basis
* Format is based on empirical test to determine
* the floor and ceiling values. This format is exactly the
* same format as the existing statistics implementation.
*
* FE_*_PAD:
* Parameter is used as a Pad variable, not of any use to the
* userspace world.
*/
/* Statistics format
* FE_FORMAT_S32:Signed 32 bits
* FE_FORMAT_U32:Unsigned 32 bits
* FE_FORMAT_U24:Unsigned 24 bits
* FE_FORMAT_S24:Signed 24 bits
* FE_FORMAT_S16:Signed 16 bits
* FE_FORMAT_U16:Unsigned 16 bits
* FE_FORMAT_S08:Signed 8 bits
* FE_FORMAT_U08:Unsigned 8 bits
*/
enum fecap_format {
FE_FORMAT_UNKNOWN = 0,
FE_FORMAT_S32,
FE_FORMAT_S24,
FE_FORMAT_S16,
FE_FORMAT_S08,
FE_FORMAT_U32,
FE_FORMAT_U24,
FE_FORMAT_U16,
FE_FORMAT_U08,
FE_FORMAT_PAD = 0x
};
/* Quality format
* FE_QUALITY_SNR_dB_100:SNR in dB/100
* FE_QUALITY_SNR_dB_10 :SNR in dB/10
* FE_QUALITY_SNR_dB:SNR in dB
* FE_QUALITY_CNR_dB_100:CNR in dB/100
* FE_QUALITY_CNR_dB_10 :CNR in dB/10
* FE_QUALITY_CNR_dB:CNR in dB
* FE_QUALITY_EsNo :Es/No
* FE_QUALITY_EbNo :Eb/No
*/
enum fecap_quality {
/* Unknown */
FE_QUALITY_UNKNOWN = 0,
/* SNR */
FE_QUALITY_SNR_dB_100,
FE_QUALITY_SNR_dB_10,
FE_QUALITY_SNR_dB,
/* CNR */
FE_QUALITY_CNR_dB_100,
FE_QUALITY_CNR_dB_10,
FE_QUALITY_CNR_dB,
/* Es/No */
FE_QUALITY_EsNo,
/* Eb/No */
FE_QUALITY_EbNo,
/* Relative */
FE_QUALITY_RELATIVE = 0x,
};
/* Strength
Re: The right way to interpret the content of SNR, signal strength and BER from HVR 4000 Lite
Devin Heitmueller wrote:
On Sun, Mar 22, 2009 at 9:00 PM, Devin Heitmueller
devin.heitmuel...@gmail.com wrote:
Wow, well this literally kept me up all night pondering the various options.
Manu's idea has alot of merit - providing a completely new API that
provides the raw data without translation as well as a way to query
for what that format is for the raw data, provides a great deal more
flexibility for applications that want to perform advanced analysis
and interpretation of the data.
That said, the solution takes the approach of revolutionary as
opposed to evolutionary, which always worries me. While providing a
much more powerful interface, it also means all of the applications
will have to properly support all of the various possible
representations of the data, increasing the responsibility in userland
considerably.
Not necessarily, the application can simply chose to support what
the driver provides as is, thereby doing no translations at all.
The change to the application is rather quite small, as you can see
from the quick patch and a modified femon.
From what you see, it should be that simple.
Let me ask this rhetorical question: if we did nothing more than just
normalize the SNR to provide a consistent value in dB, and did nothing
more than normalize the existing strength field to be 0-100%, leaving
it up to the driver author to decide the actual heuristic, what
percentage of user's needs would be fulfilled?
I bet the answer would be something like 99%.
You can really scale values to dB only if it is in some dB scale.
Looking at the drivers there are hardly a few drivers that do in dB.
If it were to be standardized in to one standard format i would
rather prefer to have the format what the API currently suggests:
That is to have a floor - ceiling value, without any units, rather
than one which forces all drivers to dB (in this case the drivers
which do not will be considered broken), the reason being this
hardly helps a few drivers, while the reverse holds true for all.
Regards,
Manu
diff -r 421de709288e linux/drivers/media/dvb/dvb-core/dvb_frontend.c
--- a/linux/drivers/media/dvb/dvb-core/dvb_frontend.c Wed Mar 18 23:42:34 2009 +0400
+++ b/linux/drivers/media/dvb/dvb-core/dvb_frontend.c Wed Mar 25 01:22:31 2009 +0400
-1607,6 +1607,13 @@
break;
}
+ case FE_STATISTICS_CAPS: {
+ struct fecap_statistics *stats_cap = parg;
+ memcpy(stats_cap, fe-ops.statistics_caps, sizeof (struct fecap_statistics));
+ err = 0;
+ break;
+ }
+
case FE_READ_STATUS: {
fe_status_t* status = parg;
-1622,6 +1629,17 @@
err = fe-ops.read_status(fe, status);
break;
}
+
+ case FE_SIGNAL_LEVEL:
+ if (fe-ops.read_level)
+ err = fe-ops.read_level(fe, (__u32 *) parg);
+ break;
+
+ case FE_SIGNAL_STATS:
+ if (fe-ops.read_stats)
+ err = fe-ops.read_stats(fe, (struct fesignal_stat *) parg);
+ break;
+
case FE_READ_BER:
if (fe-ops.read_ber)
err = fe-ops.read_ber(fe, (__u32*) parg);
diff -r 421de709288e linux/drivers/media/dvb/dvb-core/dvb_frontend.h
--- a/linux/drivers/media/dvb/dvb-core/dvb_frontend.h Wed Mar 18 23:42:34 2009 +0400
+++ b/linux/drivers/media/dvb/dvb-core/dvb_frontend.h Wed Mar 25 01:22:31 2009 +0400
-252,6 +252,7 @@
struct dvb_frontend_ops {
struct dvb_frontend_info info;
+ struct fecap_statistics statistics_caps;
void (*release)(struct dvb_frontend* fe);
void (*release_sec)(struct dvb_frontend* fe);
-298,6 +299,9 @@
*/
enum dvbfe_search (*search)(struct dvb_frontend *fe, struct dvb_frontend_parameters *p);
int (*track)(struct dvb_frontend *fe, struct dvb_frontend_parameters *p);
+
+ int (*read_level)(struct dvb_frontend *fe, u32 *signal); /* Raw AGC level */
+ int (*read_stats)(struct dvb_frontend *fe, struct fesignal_stat *stat);
struct dvb_tuner_ops tuner_ops;
struct analog_demod_ops analog_ops;
diff -r 421de709288e linux/drivers/media/dvb/frontends/stb0899_drv.c
--- a/linux/drivers/media/dvb/frontends/stb0899_drv.c Wed Mar 18 23:42:34 2009 +0400
+++ b/linux/drivers/media/dvb/frontends/stb0899_drv.c Wed Mar 25 01:22:31 2009 +0400
-1226,6 +1226,29 @@
return 0;
}
+static int stb0899_read_level(struct dvb_frontend *fe, u32 *signal)
+{
+ /* TODO! */
+ return 0;
+}
+
+static int stb0899_read_stats(struct dvb_frontend *fe, struct fesignal_stat *stats)
+{
+ u16 snr, strength;
+ u32 ber;
+
+ stb0899_read_snr(fe, snr);
+ stb0899_read_signal_strength(fe, strength);
+ stb0899_read_ber(fe, ber);
+
+ stats-quality = snr;
+ stats-strength = strength;
+ stats-error = ber;
+ stats-unc = 0;
+
+ return 0;
+}
+
static int stb0899_set_voltage(struct dvb_frontend *fe, fe_sec_voltage_t voltage)
{
struct stb0899_state *state = fe-demodulator_priv;
-1917,6 +1940,27 @@
FE_CAN_QPSK
},
+ .statistics_caps = {
+ .quality = {
+ .params = FE_QUALITY_CNR,
+ .scale = FE_SCALE_dB,
+ .exponent = -4,
+ },
+
+ .strength = {
+ .params = FE_SCALE_dB,
+ .exponent = -4,
+ },
+
+ .error = {
+ .params =
Re: The right way to interpret the content of SNR, signal strength and BER from HVR 4000 Lite
Devin Heitmueller wrote: On Tue, Mar 24, 2009 at 7:46 PM, Manu Abraham abraham.m...@gmail.com wrote: Mika Laitio wrote: That said, the solution takes the approach of revolutionary as opposed to evolutionary, which always worries me. While providing a much more powerful interface, it also means all of the applications will have to properly support all of the various possible representations of the data, increasing the responsibility in userland considerably. Not necessarily, the application can simply chose to support what the driver provides as is, thereby doing no translations at all. From the end user point of view it is not very usefull if he has 2 different cards and application can not show any usefull signal goodness info in a way that would be easy to compare. So I think the attempt to standardize to db is good. The first part: For comparison having a standardized value is good. True. But the problem that surrounds it: To do this, a driver should support statistics in dB. For a device which doesn't show statistics in dB, for reasons (a) device uses a different format (b) enough information is not available to do a conversion (too less information, or a reverse engineered driver) (c) the conversion to be done makes things too complex in kernel land. So you have very less devices to do a comparison between. The other way to do this: Suppose, the driver that doesn't support a dB format (relative doesn't mean unknown) provides the information in a relative format. And the driver that provides the information in dB format, but that information you get, can be converted in to a relative floor - ceiling format (conversion handled by application, or by a library) This is a quick way. Now, which all devices do provide a scale in dB, which is really comparable ? There are many different parameters, quickly hacked together to be called SNR. In the terms you mention, you will be comparing things like SNR to CNR etc based on the device type. So eventually your comparison is wrong. Maybe there could then in addition be some other optional method for also getting data in some hw specific format in a way that Manu suggested. But there should anyway be mandatory to have this one standard goodness value in a way that does not require apps to make any complicate comparisons... (I bet half of those apps would be broken for years) In the way i mentioned, it leaves to the application to choose from different styles such as (1) display parameters from the drivers, in their own native format (This is a completely human readable format, in which you can see the real scales) (2) convert parameters to a specific format. (The very important part here is that the application is free to convert from format A with driver X and format B with driver Y, to get it into a unified format. if you really need the feature what you mentioned, you need this feature, rather than have all drivers being modified to provide one standard format) To make things look simple, i have a sample application which does (1) to make things look simple. If you choose to do (2) It will be just doing the conversion one time in a library or application, once rather than doing it multiple times in unknown ways and formats. Hello Manu, Hi Devin, First off, a large part of your argument lies in the notion that many of the devices do not support representing the SNR in dB. My comment has some few points, of which the dB scale thing is just one among them. It could be a major aspect, depending on how you perceive it. However, when I sent around the list in an attempt to do an inventory of what formats were used by different demods, you didn't provide any actual information. Being on the lists for quite a while and following the developments with some amount of information, i was under the belief that it would have been obvious and did not give much importance to the same. Could you please look at the following list, and if you know of how unknown demods do their SNR, provide the information? http://www.devinheitmueller.com/snr.txt Sure, of course. Here is an updated list based on the information that you accumulated. I have corrected some of them, which were not accurate. af9013.c0.1 dB at76c651.c unknown au8522.c0.1 dB bcm3510.c unknown (vals 1000) cinergyT2.c dB * 256 cx22700.c unknown cx22702.c unknown cx24110.c ESN0 cx24116.c percent scaled to 0-0x, support for ESN0 cx24123.c Inverted ESN0 dib3000mb.c unknown dib3000mc.c always zero (0.1dB possible [pboettch]) dib7000m.c always zero (0.1dB possible [pboettch]) dib7000p.c always zero (0.1dB possible [pboettch]) drx397xD.c always zero dst(s/c/t) (Inverted relative, if scaled confirms to API) dvb_dummy_fe.c always zero l64781.c(Relative, confirms to API) lgdt330x.c dB * 256 lgdt3304.c always
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: 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: [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
