RE: [PATCH] videobuf2-dma-sg: Support io userptr operations on io memory
@@ -180,7 +186,26 @@ static void *vb2_dma_sg_get_userptr(void
*alloc_ctx, unsigned long vaddr,
if (!buf-pages)
return NULL;
- num_pages_from_user = get_user_pages(current, current-mm,
+ buf-vma = find_vma(current-mm, vaddr);
+ if (!buf-vma) {
+ dprintk(1, no vma for address %lu\n, vaddr);
+ return NULL;
+ }
+
+ if (vma_is_io(buf-vma)) {
+ for (num_pages_from_user = 0;
+ num_pages_from_user buf-num_pages;
+ ++num_pages_from_user, vaddr += PAGE_SIZE) {
+ unsigned long pfn;
+
+ if (follow_pfn(buf-vma, vaddr, pfn)) {
+ dprintk(1, no page for address %lu\n, vaddr);
+ break;
+ }
+ buf-pages[num_pages_from_user] = pfn_to_page(pfn);
+ }
+ } else
+ num_pages_from_user = get_user_pages(current, current-mm,
vaddr PAGE_MASK,
buf-num_pages,
write,
Can you safely assume that your userptr will cover only one vma? At least,
get_user_pages (calling __get_user_pages) does not assume that and calls
find_vma() whenever vma-vm_end is reached.
– Matthias
CONFIDENTIALITY: The contents of this e-mail are confidential and intended only
for the above addressee(s). If you are not the intended recipient, or the
person responsible for delivering it to the intended recipient, copying or
delivering it to anyone else or using it in any unauthorized manner is
prohibited and may be unlawful. If you receive this e-mail by mistake, please
notify the sender and the systems administrator at straym...@tttech.com
immediately.
N�r��yb�X��ǧv�^�){.n�+{���bj)w* jg��� �ݢj/���z�ޖ��2�ޙ�)ߡ�a���� �G���h��j:+v���w��٥
I/O USERPTR for videobuf2-dma-sg
Hi everyone, I’m in the process of providing a driver for a camera input and have just finished SG DMA operation to work in hardware and driver. Now I’m quite surprised that videobuf2-dma-sg is lacking basic support for user pointers to I/O memory (i.e., to graphics card). However, videobuf2-dma-contig does have support for it, at least from reading the code I see that vb2_dc_get_userptr() can tell I/O memory from RAM and as such do the right thing for I/O. OTOH, vb2_dma_sg_get_userptr() just does plain get_user_pages() which is not returning any page information for I/O memory. Is this missing just because no-one has bothered to do it, or is there a known problem ? Right now it seems that only one driver in the kernel tree is actually using videobuf2-dma-sg, so maybe it hasn’t been worth the effort. Similarly, DMABUF has not been implemented in videobuf2-dma-sg. Would a patch for adding I/O USERPTR functionality similar to vb2_dc_get/put_userptr() be accepted? Any known problems with this task I’m going to face? Thanks, – Matthias -- To unsubscribe from this list: send the line unsubscribe linux-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 / STB0899 / STB6100 card ( Twinhan VP-1041): problems locking to transponder
Am 29.12.2009 10:38, schrieb Leszek Koltunski: Now , some more info: 1. I've connected a satellite set-top-box to the signal and the STB can tune to and watch channels from both transponders with no problems at all. That IMHO proves that the signal is all right and the problem lies in the drivers, or maybe in dvbstream. ( or hopefully between the chair and the keyboard ) 2. I can ONLY tune to the 'freq 1150 / sr 28125' transponder. All others fail. But with that one I have no problems at all, I tunes 100% of the time; I got it to stream for 4 days straight with no problems. 3. You can see that both transponders are C-BAND , H polarization, so theoretically, AFAIK, if I can tune to the '1150' transponder, I should be able to tune to the '1190' one with no magic at all, am I wrong here? The same combination of devices (Mantis, STB0899, STB6100) is used in various cards, and at my side they still have tuning issues. A few weeks ago, Austrian TV started to feed their transponder theirself instead by Astra, and from that moment on it was impossible to tune to that transponder. After some days they switched off spectral inversion, and the cards were now able to tune again. Furthermore, tuning is unstable here when signal quality is not optimal leading to driver lock-ups. After a reload, tuning is again possible. Beside some hard reboots caused by the xineliboutput/vdpau frontend, this is the one remaining major problem at my setup. Could anyone shed some light on this? – Matthias -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: no locking on dvb-s2 22000 2/3 8PSK transponder on Astra 19.2E with tt s2-3200
Am 15.12.2009 20:44, schrieb Newsy Paper: yes, this transponder is working again at blog.ors.at they say that they updated the modulator. It is working now again but driver still has this bug, so it's interesting what the update of the modulator changed exactly. Today I received an answer from Peter Knorr, ORS, where he told me that when they activated their modulator on 3 Dec 2009, it was set up to output an inverted spectrum. What they did to fix our issue was to switch off this inversion. For me, personally, the issue with 19.2°/11302.75h is closed. Maybe someone with knowledge about handling STB6100/STB0899 will be able to finally solve the issue with transponders that have an inverted spectrum. – Matthias -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: no locking on dvb-s2 22000 2/3 8PSK transponder on Astra 19.2E with tt s2-3200
Am 09.12.2009 21:15, schrieb Newsy Paper: no matter if I use Igors or Manus driver, there's no lock on 11303 h 22000 2/3 8psk. Other users at vdr-portal report same problem. The strange thing is that all other transponders that use 22000 2/3 8psk do work but this transponder doesn't. It worked fine until december 3rd when uplink moved to Vienna. I think they changed a parameter like rolloff or inversion and the dvb-s2 part of stb6100 is buggy. Reviewing the code and having enabled debugging options for stb6100, I am puzzled about the high bandwidth values. I thought that the bandwidth of the frontend would always be around the bandwidth of the transponder, plus some minimum locking range. 11303h is a 26 MHz transponder, so I wonder about the excess in bandwidth: 39.7 MHz is requested, 40 MHz bandwidth is the result. I would expect a value of 22 MSps * (1+0.35) Hz/S = 29.7 MHz (which is more than the transponder’s 26 MHz, though ?) but less than 40 MHz as in the example below. If too much bandwidth hits the decoder, it may be facing aliasing from neighbor channels, but I don’t know if that is the root cause of the problems. This is http://jusst.de/hg/v4l-dvb/ as advised by Manu. Tuning to a 27.500 MSps transponder results in a whoppin’ 62 MHz bandwidth setting. Is this reasonable? kernel: stb6100_set_bandwidth: set bandwidth to 3970 Hz kernel: stb6100_write_reg_range: Write @ 0x60: [9:1] kernel: stb6100_write_reg_range: FCCK: 0x4d kernel: stb6100_write_reg_range: Write @ 0x60: [6:1] kernel: stb6100_write_reg_range: F: 0xcf kernel: stb6100_write_reg_range: Write @ 0x60: [9:1] kernel: stb6100_write_reg_range: FCCK: 0x0d kernel: stb6100_read_regs: Read from 0x60 kernel: stb6100_read_regs: LD: 0x81 kernel: stb6100_read_regs: VCO: 0x64 kernel: stb6100_read_regs: NI: 0x34 kernel: stb6100_read_regs: NF: 0x2f kernel: stb6100_read_regs: K: 0x3d kernel: stb6100_read_regs: G: 0x39 kernel: stb6100_read_regs: F: 0xcf kernel: stb6100_read_regs: DLB: 0xdc kernel: stb6100_read_regs: TEST1: 0x8f kernel: stb6100_read_regs: FCCK: 0x0d kernel: stb6100_read_regs: LPEN: 0xfb kernel: stb6100_read_regs: TEST3: 0xde kernel: stb6100_get_bandwidth: bandwidth = 4000 Hz kernel: stb6100_read_regs: Read from 0x60 kernel: stb6100_read_regs: LD: 0x81 kernel: stb6100_read_regs: VCO: 0x64 kernel: stb6100_read_regs: NI: 0x34 kernel: stb6100_read_regs: NF: 0x2f kernel: stb6100_read_regs: K: 0x3d kernel: stb6100_read_regs: G: 0x39 kernel: stb6100_read_regs: F: 0xcf kernel: stb6100_read_regs: DLB: 0xdc kernel: stb6100_read_regs: TEST1: 0x8f kernel: stb6100_read_regs: FCCK: 0x0d kernel: stb6100_read_regs: LPEN: 0xfb kernel: stb6100_read_regs: TEST3: 0xde kernel: stb6100_set_frequency: Get frontend parameters kernel: stb6100_write_reg_range: Write @ 0x60: [1:11] kernel: stb6100_write_reg_range: VCO: 0x64 kernel: stb6100_write_reg_range: NI: 0x34 kernel: stb6100_write_reg_range: NF: 0x2f kernel: stb6100_write_reg_range: K: 0x3d kernel: stb6100_write_reg_range: G: 0x39 kernel: stb6100_write_reg_range: F: 0xcf kernel: stb6100_write_reg_range: DLB: 0xdc kernel: stb6100_write_reg_range: TEST1: 0x8f kernel: stb6100_write_reg_range: FCCK: 0x0d kernel: stb6100_write_reg_range: LPEN: 0xeb kernel: stb6100_write_reg_range: TEST3: 0xde kernel: stb6100_set_frequency: frequency = 1552000, srate = 2200, g = 9, odiv = 0, psd2 = 1, fxtal = 27000, osm = 6, fvco = 3104000, N(I) = 57, N(F) = 247 kernel: stb6100_write_reg_range: Write @ 0x60: [1:11] kernel: stb6100_write_reg_range: VCO: 0xe6 kernel: stb6100_write_reg_range: NI: 0x39 kernel: stb6100_write_reg_range: NF: 0xf7 kernel: stb6100_write_reg_range: K: 0x3c kernel: stb6100_write_reg_range: G: 0x39 kernel: stb6100_write_reg_range: F: 0xcf kernel: stb6100_write_reg_range: DLB: 0xdc kernel: stb6100_write_reg_range: TEST1: 0x8f kernel: stb6100_write_reg_range: FCCK: 0x4d kernel: stb6100_write_reg_range: LPEN: 0xeb kernel: stb6100_write_reg_range: TEST3: 0xde kernel: stb6100_write_reg_range: Write @ 0x60: [10:1] kernel: stb6100_write_reg_range: LPEN: 0xfb kernel: stb6100_write_reg_range: Write @ 0x60: [1:1] kernel: stb6100_write_reg_range: VCO: 0x86 kernel: stb6100_write_reg_range: Write @ 0x60: [1:1] kernel: stb6100_write_reg_range: VCO: 0x66 kernel: stb6100_write_reg_range: Write @ 0x60: [1:9] kernel: stb6100_write_reg_range: VCO: 0x66 kernel: stb6100_write_reg_range: NI: 0x39
Re: TBS 6980 Dual DVB-S2 PCIe card
Hallo Thomas! Am 02.12.2009 15:31, schrieb Thomas Kernen: Is someone already working on supporting the TBS 6980 Dual DVB-S2 PCIe card? http://www.tbsdtv.com/english/product/6980.html Have you seen/tried their all-in-one linux source package which was released 2009-12-03? http://www.tbsdtv.com/download/common/linux_tbs_all.rar – Matthias BTW: Where did you get yours? -- To unsubscribe from this list: send the line unsubscribe linux-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?
Hi Manu, Just to give you some feedback on the first issue as well: Am 06.12.2009 13:52, schrieb Matthias Wächter: • Can’t lock to 19.2/11303h (looks like something new, related to the change of the transponder’s feed, but other cards – e.g. TBS 6920 and Tevii 470 – do sync without a problem). Looks like a frontend issue to me (STB0899/STB6100), as mantis and budget-ci cards are affected in the same way. This correlates with perfect and quick lock of 19.2/11362h which is about the same frequency and has the same DVB parameters (22000/hC23M5O35S1). One guy on vdrportal.de tried his card under Windows, and he can there lock to that transponder. He tells that locking took quite some time, though, and it appears that transponder shows unexpected low signal strength, but I would take that with a grain of salt as it might be different frontend handling and value scaling. – Matthias -- To unsubscribe from this list: send the line unsubscribe linux-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?
Manu, Thanks for taking care. Please try http://jusst.de/hg/v4l-dvb and report the issues It looks as if dependencies and frontends are not in line. • dependencies for my card’s relevant frontends STB0899, STB6100, and LNBP21 are missing from Kconfig, • dependency for CU1216 is in, but frontend driver source missing. It’s neither in my kernel 2.6.32 sources nor in linuxtv’s v4l-dvb. So, mantis_core is automatically selected and compiled, hopper too, but not mantis. Worked around it by adding/replacing the dependencies (in fact, removing the dependency for CU1216 should have enabled build of mantis). Remaining issues for me: • Can’t lock to 19.2/11303h (looks like something new, related to the change of the transponder’s feed, but other cards – e.g. TBS 6920 and Tevii 470 – do sync without a problem). Looks like a frontend issue to me (STB0899/STB6100), as mantis and budget-ci cards are affected in the same way. This correlates with perfect and quick lock of 19.2/11362h which is about the same frequency and has the same DVB parameters (22000/hC23M5O35S1). • Sometimes very slow lock at transponder change, slow enough to trace it in femon. femon first shows high BER rates and the picture is blocky, reducing within 3 or 4 Seconds to BER=0 and perfect picture. I should be able to repeat that and give you some logs if you need it. • Sometimes lock to a transponder only in certain order of previous transponder. Hard to formalize, though. Verbose module output shows 1 to 2 unsuccessful locking attempts per second by the driver. • Still no 0x-0x SNR and STR range. • Currently no lock on 19.2/12693h either, but this may be a signal quality issue on my side. • Have not yet tried it with two mantis cards in a system, but there was a problem at least with ci handling in such a setup using s2-liplianin for a friend of mine. Will test that next week. • Have not tried IR (I use a radio RCU with lirc). – Matthias -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Mantis – anyone?
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? Cheers, – Matthias 1: http://linuxtv.org/wiki/index.php/Azurewave_AD_SP400_CI_%28VP-1041%29#Drivers -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
