2许世友、
尊敬的：linux-media@vger.kernel.org 本公司有：商业、广告业、服务业、建筑业、运输业、税务代开、行政事业及其它专用...等![发ˇˍˇ票]代理!! 承诺：正规途径不必担心真假问题!可使用后付款!需要不防一试！ 联系：13802918596 Q Q: 860181626 2011-10-16 13:53:57 2011/10/16
Re: [PATCH 2/9] mm: alloc_contig_freed_pages() added
On Sat, 15 Oct 2011 01:29:33 +0200, Andrew Morton a...@linux-foundation.org wrote: On Thu, 06 Oct 2011 15:54:42 +0200 Marek Szyprowski m.szyprow...@samsung.com wrote: From: KAMEZAWA Hiroyuki kamezawa.hir...@jp.fujitsu.com This commit introduces alloc_contig_freed_pages() function The freed seems redundant to me. Wouldn't alloc_contig_pages be a better name? The “freed” is there because the function operates on pages that are in buddy system, ie. it is given a range of PFNs that are to be removed from buddy system. There's also a alloc_contig_range() function (added by next patch) which frees pages in given range and then calls alloc_contig_free_pages() to allocate them. IMO, if there was an alloc_contig_pages() function, it would have to be one level up (ie. it would figure out where to allocate memory and then call alloc_contig_range()). (That's really what CMA is doing). Still, as I think of it now, maybe alloc_contig_free_range() would be better? -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/9] mm: alloc_contig_freed_pages() added
On Sun, 16 Oct 2011 10:01:36 +0200 Michal Nazarewicz min...@mina86.com wrote: Still, as I think of it now, maybe alloc_contig_free_range() would be better? Nope. Of *course* the pages were free. Otherwise we couldn't (re)allocate them. I still think the free part is redundant. What could be improved is the alloc part. This really isn't an allocation operation. The pages are being removed from buddy then moved into the free arena of a different memory manager from where they will _later_ be allocated. So we should move away from the alloc/free naming altogether for this operation and think up new terms. How about claim and release? claim_contig_pages, claim_contig_range, release_contig_pages, etc? Or we could use take/return. Also, if we have no expectation that anything apart from CMA will use these interfaces (?), the names could/should be prefixed with cma_. -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/7] Staging submission: PCTV 74e driver (as102)
On Oct 15 Piotr Chmura wrote: Staging submission: PCTV 74e driver (as102) From: Devin Heitmuellerdheitmuel...@kernellabs.com pull as102 driver from This is driver for PCTV 74e DVB-T USB tuner, taken from [1], written by Devin Heitmueller using the GPL reference driver provided by Abilis. The only change needed to compile it in current git tree [2] was changing calls usb_buffer_alloc() and usb_buffer_free() to usb_alloc_coherent() and usb_free_coherent(). It's included in this patch. Patch was tested by me on amd64. [1]http://kernellabs.com/hg/~dheitmueller/v4l-dvb-as102-2/ [2] git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git kernel-3.1.0-git9+ Signed-off-by: Piotr Chmurachmoor...@poczta.onet.pl Cc: Devin Heitmuellerdheitmuel...@kernellabs.com Cc: Greg HKgre...@suse.de diff -Nur linux.clean/drivers/staging/as102/as102_drv.c linux.as102_initial/drivers/staging/as102/as102_drv.c --- linux.clean/drivers/staging/as102/as102_drv.c 1970-01-01 01:00:00.0 +0100 +++ linux.as102_initial/drivers/staging/as102/as102_drv.c 2011-10-14 17:55:02.0 +0200 @@ -0,0 +1,360 @@ +/* + * Abilis Systems Single DVB-T Receiver + * Copyright (C) 2008 Pierrick Hascoetpierrick.hasc...@abilis.com + * Copyright (C) 2010 Devin Heitmuellerdheitmuel...@kernellabs.com Hi Piotr, thanks for getting this going again. - I have not yet looked through the source but have some small remarks on the patch format. - In your changelogs and in the diffs, somehow the space between real name and e-mail address got lost. - The repetition of the Subject: line as first line in the changelog is unnecessary (and would cause an undesired duplication e.g. when git-am is used, last time I checked). - AFAICT, author of patch 1/7 is not Devin but you. Hence the From: line right above the changelog is wrong. - The reference to the source hg tree is very helpful. However, since the as102 related history in there is very well laid out, it may be beneficial to quote some of this prior history. I suggest, include the changelog of as102: import initial as102 driver, http://kernellabs.com/hg/~dheitmueller/v4l-dvb-as102-2/rev/a78bda1e1a0b (but mark it clearly as a quote from the out-of-tree repo), and include a shortlog from this commit inclusive until the head commit inclusive. (Note, the hg author field appears to be wrong; some of the changes apparently need to be attributed to Pierrick Hascoet as author.) This would IMO improve the picture of who contributed what when this goes into mainline git history, even though the hg history needed to be discarded. - A diffstat is always very nice to have in a patch posting. Most tools for patch generation make it easy to add, and it helps the recipients of the patch posting. (Also, a diffstat of all patches combined would be good to have in the introductory PATCH 0/n posting, but not many developers take the time to do so.) Again, thanks for the effort and also thanks to Devin for making it possible. -- Stefan Richter -=-==-== =-=- = http://arcgraph.de/sr/ -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/9] mm: alloc_contig_freed_pages() added
On Sun, 16 Oct 2011 10:01:36 +0200 Michal Nazarewicz wrote: Still, as I think of it now, maybe alloc_contig_free_range() would be better? On Sun, 16 Oct 2011 10:31:16 +0200, Andrew Morton wrote: Nope. Of *course* the pages were free. Otherwise we couldn't (re)allocate them. I still think the free part is redundant. Makes sense. What could be improved is the alloc part. This really isn't an allocation operation. The pages are being removed from buddy then moved into the free arena of a different memory manager from where they will _later_ be allocated. Not quite. After alloc_contig_range() returns, the pages are passed with no further processing to the caller. Ie. the area is not later split into several parts nor kept in CMA's pool unused. alloc_contig_freed_pages() is a little different since it must be called on a buddy page boundary and may return more then requested (because of the way buddy system merges buddies) so there is a little processing after it returns (namely freeing of the excess pages). So we should move away from the alloc/free naming altogether for this operation and think up new terms. How about claim and release? claim_contig_pages, claim_contig_range, release_contig_pages, etc? Or we could use take/return. Personally, I'm not convinced about changing the names of alloc_contig_range() and free_contig_pages() but I see merit in changing alloc_contig_freed_pages() to something else. Since at the moment, it's used only by alloc_contig_range(), I'd lean towards removing it from page-isolation.h, marking as static and renaming to __alloc_contig_range(). Also, if we have no expectation that anything apart from CMA will use these interfaces (?), the names could/should be prefixed with cma_. In Kamezawa's original patchset, he used those for a bit different approach (IIRC, Kamezawa's patchset introduced a function that scanned memory and tried to allocate contiguous memory where it could), so I can imagine that someone will make use of those functions. It may be used in any situation where a range of pages is either free (ie. in buddy system) or movable and one wants to allocate them for some reason. -- Best regards, _ _ .o. | Liege of Serenely Enlightened Majesty of o' \,=./ `o ..o | Computer Science, Michal mina86 Nazarewicz(o o) ooo +--min...@mina86.com---min...@jabber.org---ooO--(_)--Ooo-- -- To unsubscribe from this list: send the line unsubscribe linux-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 6/9] drivers: add Contiguous Memory Allocator
On Fri, Oct 14, 2011 at 04:57:30PM -0700, Andrew Morton wrote: On Thu, 06 Oct 2011 15:54:46 +0200 Marek Szyprowski m.szyprow...@samsung.com wrote: +#ifdef phys_to_pfn +/* nothing to do */ +#elif defined __phys_to_pfn +# define phys_to_pfn __phys_to_pfn +#elif defined __va +# define phys_to_pfn(x) page_to_pfn(virt_to_page(__va(x))) +#else +# error phys_to_pfn implementation needed +#endif Yikes! This hackery should not be here, please. If we need a phys_to_pfn() then let's write a proper one which lives in core MM and arch, then get it suitably reviewed and integrated and then maintained. Another question is whether we have any arch where PFN != PHYS PAGE_SHIFT? We've used __phys_to_pfn() to implement that on ARM (with a corresponding __pfn_to_phys()). Catalin recently added a cast to __phys_to_pfn() for LPAE, which I don't think is required: -#define__phys_to_pfn(paddr)((paddr) PAGE_SHIFT) +#define__phys_to_pfn(paddr)((unsigned long)((paddr) PAGE_SHIFT)) since a phys_addr_t PAGE_SHIFT will be silently truncated if the passed in physical address was 64-bit anyway. (Note: we don't support 32-bit PFNs). So, I'd suggest CMA should just use PFN_DOWN() and be done with it. -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] TT CT-3650 i2c fix
This patch fix a bug in the i2c code of ttusb2 driver.
Signed-off-by: Jose Alberto Reguero jaregu...@telefonica.net
Jose Alberto
diff -ur linux/drivers/media/dvb/dvb-usb/ttusb2.c linux.new/drivers/media/dvb/dvb-usb/ttusb2.c
--- linux/drivers/media/dvb/dvb-usb/ttusb2.c 2011-09-24 05:45:14.0 +0200
+++ linux.new/drivers/media/dvb/dvb-usb/ttusb2.c 2011-10-01 19:42:46.715723308 +0200
@@ -384,7 +384,7 @@
memcpy(obuf[3], msg[i].buf, msg[i].len);
- if (ttusb2_msg(d, CMD_I2C_XFER, obuf, msg[i].len+3, ibuf, obuf[2] + 3) 0) {
+ if (ttusb2_msg(d, CMD_I2C_XFER, obuf, obuf[1]+3, ibuf, obuf[2] + 3) 0) {
err(i2c transfer failed.);
break;
}
Re: [PATCH 1/7] Staging submission: PCTV 74e driver (as102)
On Sun, Oct 16, 2011 at 4:57 AM, Stefan Richter stef...@s5r6.in-berlin.de wrote: Hi Piotr, thanks for getting this going again. - I have not yet looked through the source but have some small remarks on the patch format. - In your changelogs and in the diffs, somehow the space between real name and e-mail address got lost. - The repetition of the Subject: line as first line in the changelog is unnecessary (and would cause an undesired duplication e.g. when git-am is used, last time I checked). - AFAICT, author of patch 1/7 is not Devin but you. Hence the From: line right above the changelog is wrong. - The reference to the source hg tree is very helpful. However, since the as102 related history in there is very well laid out, it may be beneficial to quote some of this prior history. I suggest, include the changelog of as102: import initial as102 driver, http://kernellabs.com/hg/~dheitmueller/v4l-dvb-as102-2/rev/a78bda1e1a0b (but mark it clearly as a quote from the out-of-tree repo), and include a shortlog from this commit inclusive until the head commit inclusive. (Note, the hg author field appears to be wrong; some of the changes apparently need to be attributed to Pierrick Hascoet as author.) This would IMO improve the picture of who contributed what when this goes into mainline git history, even though the hg history needed to be discarded. - A diffstat is always very nice to have in a patch posting. Most tools for patch generation make it easy to add, and it helps the recipients of the patch posting. (Also, a diffstat of all patches combined would be good to have in the introductory PATCH 0/n posting, but not many developers take the time to do so.) Again, thanks for the effort and also thanks to Devin for making it possible. I think collapsing my entire patch series in to a single patch would not be acceptable, as it loses the entire history of what code was originally delivered by Abilis as well as what changes I made. The fact that it's from multiple authors (including a commercial entity contributing the code) makes this worse. I think the tree does need to be rebased, but I don't think the entire patch series would need to be reworked to be on staging from the beginning. You could probably import the first patch (as102: import initial as102 driver), fix the usb_alloc_coherent() so that it compiles (and put a note in it saying you did), apply the rest of the patch series, and then add a final patch that says something like moving to staging as code is not production ready. This would allow the history to be preserved without having to rebase every patch to deal with the files being moved to the staging tree. An alternative would be make a minor tweak to my first patch which removes the driver from the makefile. Then every patch in the patch series wouldn't actually have to compile successfully until the very end when you add it back into the Makefile. This is a luxury you can do when it's a brand new driver. When it's a brand new driver there is a bit more flexibility as long as you don't break git bisect. Both of the approaches described above accomplish that. Mauro, what do you think? Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-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 4/7] staging/as102: cleanup - formatting code
On Sat, Oct 15, 2011 at 10:54:43PM +0200, Piotr Chmura wrote:
staging as102: cleanup - formatting code
Cleanup code: change double spaces into single, put tabs instead of spaces
where they should be.
Signed-off-by: Piotr Chmurachmoor...@poczta.onet.pl
Cc: Devin Heitmuellerdheitmuel...@kernellabs.com
Cc: Greg HKgre...@suse.de
Just a few hints from my side. Most of my comments apply to multiple other parts
of the code, but I did not want to quote everything and you should be able to
find the other parts I did not mention explicitely as well.
I don't have much knowledge of kernel code style, but wanted to point out a few
things that seem to be obviously wrong or uncommon, and stuff I wouldn't do.
There
may be a few false positives and some things missing.
[And yes, I actually only wanted to comment on the two-space thing, but I
somehow
ended up reading the complete patch or the first half of it].
diff -Nur linux.as102.03-typedefs/drivers/staging/as102/as102_drv.c
linux.as102.04-tabs/drivers/staging/as102/as102_drv.c
--- linux.as102.03-typedefs/drivers/staging/as102/as102_drv.c 2011-10-14
17:55:02.0 +0200
+++ linux.as102.04-tabs/drivers/staging/as102/as102_drv.c 2011-10-14
23:20:05.0 +0200
@@ -10,7 +10,7 @@
*
* 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
+ * 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
For reference, the standard variant uses two spaces after the period (aka
English Spacing).
-failed:
+ failed:
LEAVE();
/* FIXME: free dvb_XXX */
return ret;
It's more common to have no indentation before labels (about
7 times more common).
@@ -332,7 +332,7 @@
/**
* \brief as102 driver exit point. This function is called when device has
- * to be removed.
+ * to be removed.
*/
Does it make sense to reindent that? If you intent to keep API documentation
comments, you want to convert them to kernel-doc style anyway.
dprintk(debug, min_delay_ms = %d - %d\n, settings-min_delay_ms,
- 1000);
+ 1000);
#endif
Seems to be more indentation than really required.
@@ -201,7 +201,7 @@
break;
case TUNE_STATUS_STREAM_TUNED:
*status = FE_HAS_SIGNAL | FE_HAS_CARRIER | FE_HAS_SYNC |
- FE_HAS_LOCK;
+ FE_HAS_LOCK;
break;
I think it looks better with indentation here. Otherwise you might not
read the | at the end of the previous line and think FE_HAS_LOCK is
a strange macro evaluating to a function call. Moving the operator
into the second line would also make this even more clear.
#else
- .release= as102_fe_release,
- .init = as102_fe_init,
+ .release= as102_fe_release,
+ .init = as102_fe_init,
#endif
};
Is there a reason why struct members are indented using
two tabs (here and elsewhere)?
@@ -393,7 +393,7 @@
}
int as102_dvb_register_fe(struct as102_dev_t *as102_dev,
- struct dvb_frontend *dvb_fe)
+ struct dvb_frontend *dvb_fe)
{
If there's still space to align further to the right, why not
use it? It makes the code look better if parameters are aligned
below each other (or at least nearly).
int errno;
struct dvb_adapter *dvb_adap;
@@ -407,7 +407,7 @@
/* init frontend callback ops */
memcpy(dvb_fe-ops,as102_fe_ops, sizeof(struct dvb_frontend_ops));
strncpy(dvb_fe-ops.info.name, as102_dev-name,
- sizeof(dvb_fe-ops.info.name));
+ sizeof(dvb_fe-ops.info.name));
It does not seem helpful to align like this, it certainly looks
much uglier than the old one which had sizeof aligned with dvb.
/* set frequency */
@@ -642,32 +642,32 @@
* if HP/LP are both set to FEC_NONE, HP will be selected.
*/
if ((tune_args-hierarchy != HIER_NONE)
Misses a space before the
dprintk(debug, \thierarchy: 0x%02x
selected: %s code_rate_%s: 0x%02x\n,
- tune_args-hierarchy,
- tune_args-hier_select == HIER_HIGH_PRIORITY ?
- HP : LP,
- tune_args-hier_select == HIER_HIGH_PRIORITY ?
- HP : LP,
- tune_args-code_rate);
+ tune_args-hierarchy,
+ tune_args-hier_select == HIER_HIGH_PRIORITY ?
+ HP : LP,
+ tune_args-hier_select ==
HIER_HIGH_PRIORITY ?
Re: [PATCH 4/7] staging/as102: cleanup - formatting code
On Sun, Oct 16, 2011 at 8:23 AM, Julian Andres Klode j...@jak-linux.org wrote: On Sat, Oct 15, 2011 at 10:54:43PM +0200, Piotr Chmura wrote: staging as102: cleanup - formatting code Cleanup code: change double spaces into single, put tabs instead of spaces where they should be. Signed-off-by: Piotr Chmurachmoor...@poczta.onet.pl Cc: Devin Heitmuellerdheitmuel...@kernellabs.com Cc: Greg HKgre...@suse.de Just a few hints from my side. Most of my comments apply to multiple other parts of the code, but I did not want to quote everything and you should be able to find the other parts I did not mention explicitely as well. I don't have much knowledge of kernel code style, but wanted to point out a few things that seem to be obviously wrong or uncommon, and stuff I wouldn't do. There may be a few false positives and some things missing. [And yes, I actually only wanted to comment on the two-space thing, but I somehow ended up reading the complete patch or the first half of it]. I think that rather than having Piotr rework the whitespace fifty times until everybody is satisfied, let's get a functional patch series into the staging tree and then people can submit whitespace cleanup patches to their hearts content. That said, Piotr, I would not spend effort reworking the existing patch per Julian's request. Fix the issues related to the history that I mentioned in my previous email (which would be required to get it into staging), and then the people who have nothing better to do than obsess about whitespace can submit incremental patches on top of yours which address their concerns. Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/7] Staging submission: PCTV 74e driver (as102)
Em 16-10-2011 09:45, Devin Heitmueller escreveu: On Sun, Oct 16, 2011 at 4:57 AM, Stefan Richter stef...@s5r6.in-berlin.de wrote: Hi Piotr, thanks for getting this going again. - I have not yet looked through the source but have some small remarks on the patch format. - In your changelogs and in the diffs, somehow the space between real name and e-mail address got lost. - The repetition of the Subject: line as first line in the changelog is unnecessary (and would cause an undesired duplication e.g. when git-am is used, last time I checked). - AFAICT, author of patch 1/7 is not Devin but you. Hence the From: line right above the changelog is wrong. - The reference to the source hg tree is very helpful. However, since the as102 related history in there is very well laid out, it may be beneficial to quote some of this prior history. I suggest, include the changelog of as102: import initial as102 driver, http://kernellabs.com/hg/~dheitmueller/v4l-dvb-as102-2/rev/a78bda1e1a0b (but mark it clearly as a quote from the out-of-tree repo), and include a shortlog from this commit inclusive until the head commit inclusive. (Note, the hg author field appears to be wrong; some of the changes apparently need to be attributed to Pierrick Hascoet as author.) This would IMO improve the picture of who contributed what when this goes into mainline git history, even though the hg history needed to be discarded. - A diffstat is always very nice to have in a patch posting. Most tools for patch generation make it easy to add, and it helps the recipients of the patch posting. (Also, a diffstat of all patches combined would be good to have in the introductory PATCH 0/n posting, but not many developers take the time to do so.) Again, thanks for the effort and also thanks to Devin for making it possible. I think collapsing my entire patch series in to a single patch would not be acceptable, as it loses the entire history of what code was originally delivered by Abilis as well as what changes I made. The fact that it's from multiple authors (including a commercial entity contributing the code) makes this worse. I think the tree does need to be rebased, but I don't think the entire patch series would need to be reworked to be on staging from the beginning. You could probably import the first patch (as102: import initial as102 driver), fix the usb_alloc_coherent() so that it compiles (and put a note in it saying you did), apply the rest of the patch series, and then add a final patch that says something like moving to staging as code is not production ready. This would allow the history to be preserved without having to rebase every patch to deal with the files being moved to the staging tree. Rebasing a changeset to move it to staging is not as complex as it seems. I did it with tm6000 at the time I merged it. A simple bash script could do that. Something like (untested): $ git export some_base_reference $ for i in 00*.patch; do sed s,/drivers/media/video,/drivers/staging,g $i a mv a $i; done $ mkdir patches/ $ mv 00*.patches patches/ $ (cd patches; ls *.patch series) $ git quiltimport Of course, the Makefike/Kconfig patch will need changes, but this is as easy as just dropping the hunks that are touching at /drivers/media/video/Makefile and /drivers/media/video/Kconfig, and then adding a final patch adding it to the /drivers/staging/*. An alternative would be make a minor tweak to my first patch which removes the driver from the makefile. Then every patch in the patch series wouldn't actually have to compile successfully until the very end when you add it back into the Makefile. This is a luxury you can do when it's a brand new driver. When it's a brand new driver there is a bit more flexibility as long as you don't break git bisect. Both of the approaches described above accomplish that. Mauro, what do you think? Didn't actually reviewed the changeset, but let me comment about the submission procedure. Folding patches from different authors generally is not a good idea. As Devin said, things like replacing foo by bar because foo core function were replaced by bar upstream is the kind of thing that you could fold, if you properly document it with: [john@john_email.com: replaced foo by bar to fix compilation] So, you should rebase the patchsets, instead of just folding everything. It is up to you to change the patches on each patch, or to do it only at a final patch. Both ways work for me. I suggest you to remove the Kconfig/Makefile hunks that enables the driver compilation from the original series, and apply it as a final patch at the end. This makes your rebasing work easier, as you won't need to test patch by patch if they are not breaking compilation. In any case, when analyzing a driver submission like that, I generally just apply everything from a quilt series, see
cron job: media_tree daily build: WARNINGS
This message is generated daily by a cron job that builds media_tree for the kernels and architectures in the list below. Results of the daily build of media_tree: date:Sun Oct 16 19:00:16 CEST 2011 git hash:a461e0ad3d27b6342140566909a80db30d151a91 gcc version: i686-linux-gcc (GCC) 4.6.1 host hardware:x86_64 host os: 3.0-4.slh.7-amd64 linux-git-armv5: WARNINGS linux-git-armv5-davinci: WARNINGS linux-git-armv5-ixp: WARNINGS linux-git-armv5-omap2: WARNINGS linux-git-i686: WARNINGS linux-git-m32r: OK linux-git-mips: WARNINGS linux-git-powerpc64: WARNINGS linux-git-x86_64: WARNINGS linux-2.6.31.12-i686: WARNINGS linux-2.6.32.6-i686: WARNINGS linux-2.6.33-i686: WARNINGS linux-2.6.34-i686: WARNINGS linux-2.6.35.3-i686: WARNINGS linux-2.6.36-i686: WARNINGS linux-2.6.37-i686: WARNINGS linux-2.6.38.2-i686: WARNINGS linux-2.6.39.1-i686: WARNINGS linux-3.0-i686: WARNINGS linux-3.1-rc1-i686: WARNINGS linux-2.6.31.12-x86_64: WARNINGS linux-2.6.32.6-x86_64: WARNINGS linux-2.6.33-x86_64: WARNINGS linux-2.6.34-x86_64: WARNINGS linux-2.6.35.3-x86_64: WARNINGS linux-2.6.36-x86_64: WARNINGS linux-2.6.37-x86_64: WARNINGS linux-2.6.38.2-x86_64: WARNINGS linux-2.6.39.1-x86_64: WARNINGS linux-3.0-x86_64: WARNINGS linux-3.1-rc1-x86_64: WARNINGS spec-git: WARNINGS sparse: ERRORS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Sunday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Sunday.tar.bz2 The V4L-DVB specification from this daily build is here: http://www.xs4all.nl/~hverkuil/spec/media.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: support for tv tuner tda18211 in Iconbit U100 analog stick
Hey guys, I'm having the same issue here. I bought a MSI Digi VOX Mini II Analog (which was documented as having RTL2832 or AF9016 chips) but mine is: 1f4d:0237 G-Tek Electronics Group Here's the syslog output when I plug it in: http://pastebin.com/fWc7hM18 As Ling, I can't get a tuner to work nor does /dev/dvb get created. I really need some help on this. Thank you very much ! On 13 Oct 2011, Antti Palosaari wrote: From: Antti Palosaari crope at iki.fi Subject: Re: support for tv tuner tda18211 in Iconbit U100 analog stick Date: 2011-10-13 13:21:41 GMT (3 days, 6 hours and 26 minutes ago) CX23102 + TDA18211 (== DVB-T only version of TDA18271) Maybe someone have better knowledge about that as I am not any familiar with CX23102 nor analog TV side. Antti On 10/09/2011 03:56 AM, Ling Sequera wrote: I try to post this at linux-media at vger.kernel.org mailto:linux-media at vger.kernel.org, but the system rejects the sending, Excuse me for send this to you, I have understood that you are one of the developers of the tda18271 module. I have a Mygica u719c usb analog tv stick, lsusb output identify this device as: ID 1f4d:0237 G-Tek Electronics Group. Googling, I found that this device is the same Iconbit Analog Stick U100 FM http://translate.google.es/translate?sl=rutl=enjs=nprev=_thl=esie=UTF-8layout=2eotf=1u=http%3A%2F%2Fwww.f1cd.ru%2Ftuners%2Freviews%2Ficonbit_u100_fm_iconbit_u500_fm_page_1%2F, which has support in the kernel since version 3.0 as shown here http://cateee.net/lkddb/web-lkddb/VIDEO_CX231XX.html. I opened the device to corfirm this information, and effectively, it has to chips, the demod Conexan CX23102 and the DVB-T tuner NPX TDA-18211. I installed the precompiled version of kernel 3.0.4, and the device was reconized, but only works in the modes: composite and s-video. I check the source code and I found that it don't support tv tuner mode (.tuner_type=TUNER_ABSENT in 513 line of the cx231xx-cards.c http://lxr.linux.no/#linux+v3.0.4/drivers/media/video/cx231xx/cx231xx-cards.c source file), I want to add support for this. The TDA-18211 tuner has support in the kernel in the module tda18271 according to the thread of this mailing list http://www.mail-archive.com/linux-dvb at linuxtv. -- To unsubscribe from this list: send the line unsubscribe linux-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] af9013 Extended monitoring in set_frontend.
On Tue, 2011-10-11 at 08:06 +1100, Jason Hecker wrote: Playing with Kaffeine or Mplayer all the devices are fine on the same system. Right, admittedly most of my testing has been done with MythTV. I recall about a month ago I could also get corruption with mplayer. At the moment, I am going step by step what Myth TV is sending to the devices. Great. If you want I can replicate your tests here to see what I get. Antti, my AF9015 chips are integrated on PCI so I can't swap cables (alas, if only this was my problem!) Jason, do you get firmware loading fails on boot with the PCI device? There needs to be a delay put in the firmware download of at least 250uS after each write, but this does not solve the corruption. I have tried everything, but all of them fail to get rid of the corruption on the first frontend when the second frontend starts and then corruptions every 5 seconds or so. These only come through demux on endpoint 84 and are not caused by any other frontend operations. Trouble is, on a Nvidia motherboard I have it does not do it at all and all applications work without any troubles. This seems to suggest a USB motherboard driver issue. However, the frontend lock does make it at least work on Myth TV. I am continuing to look into it. Regards Malcolm -- To unsubscribe from this list: send the line unsubscribe linux-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] af9013 Extended monitoring in set_frontend.
Trouble is, on a Nvidia motherboard I have it does not do it at all and all applications work without any troubles. This seems to suggest a USB motherboard driver issue. Right. Well, I can say with high confidence that my dual tuner worked flawlessly for 18 months using Ubuntu's kernel 2.6.32 up until some update around May. Some kernel (or other) update apparently made it all go pear shaped which prompted me to get another card then update the whole system to try fix the problem - I haven't gone back to an old 2.6.32 kernel. So I am wondering if some other non v4l related patch has affected us all. I am continuing to look into it. OK, well I am still running my system with your two patches, with corruptions alas, so if you'd like me to independently try stuff out let me know. Jason -- To unsubscribe from this list: send the line unsubscribe linux-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 4/7] staging/as102: cleanup - formatting code
On Sun, Oct 16, 2011 at 08:40:06AM -0400, Devin Heitmueller wrote: then the people who have nothing better to do than obsess about whitespace can submit incremental patches You're right that the white space changes aren't needed to get the driver into staging, but there is no need to get snarky about it. Julian was replying to problems that a specific patch introduced and everything he said was correct. Piotr was already going to redo the patches anyway. regards, dan carpenter -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
