Re: [PULL] http://www.kernellabs.com/hg/~dheitmueller/hvr-1600-alsa-2
Devin Heitmueller wrote: On Wed, Jan 13, 2010 at 9:00 AM, Mauro Carvalho Chehab mche...@infradead.org wrote: Michael Krufky wrote: The same tree is also available using http instead of https: http://www.kernellabs.com/hg/~dheitmueller/em28xx-pal-vbi-2 This should work for you without issue. Ok. Applied, thanks! Sorry about that. I typically cut/paste the link from my browser (and we support both http and https for the HG repo). I will be sure that future PULL requests are http only. No problem. Also, I haven't had a chance to rebase this tree against the tip yet, as I burned too much time over the weekend tracking down the regression you introduced into the with the ir-sysfs rework. Did that one line patch get merged yet? It's pretty embarrassing to have a situation for nearly a month where the mainline v4l-dvb causes an OOPS just because they happen to have IR support. In my case, I couldn't even get my PC to boot until I pulled the card from the machine. Yes, it were applied already. I've tried to tactfully point this out in the past, but PLEASE STOP USING THE TRUNK AS YOUR PERSONAL DEVELOPMENT SANDBOX. These changes should have gone into a branch, and you should have solicited testers for that branch before any of this stuff went into the mainline. I know you're the maintainer so the rules don't apply to you, but the reality is that when talking about new development (not fixing merge conflicts), you should really be adhering to the same rules that all the other developers use. These rules are there for a reason - to provide an opportunity to catch regressions in new code before they hit the mainline. I know that you have made quite clear that you disagree that you should have to use branches for new development/refactoring. My only hope is that by pointing out every time one of your actions in the trunk causes a nasty regression, perhaps you will rethink your approach. What you call trunk, it not, really a trunk, but a tree where all patches got merged. I've been pointing it several times, but people doesn't seem to listen: that tree is were we'll expect problems to happen, since it is just an alpha staging before submitting things to linux-next, where all patches got merged. The bad thing is that people use it as if they were stable, when it weren't meant to be stable at all. That's why I decided to deprecate it. On the next few days, I intend to stop adding patches at -hg tree, passing its maintainance to another person. Douglas already offered to do it for us. The idea is that I'll apply patches directly into my git trees. And then, the hg maintainer will backport the patches into -hg. This also means that patch backports will need to be sent in separate, as those patches won't fit into -git. I'm finishing the details and I'll post an official announce about that soon. Cheers, Mauro. -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PULL] http://www.kernellabs.com/hg/~dheitmueller/hvr-1600-alsa-2
On Fri, Jan 15, 2010 at 3:00 PM, Mauro Carvalho Chehab mche...@infradead.org wrote: I've tried to tactfully point this out in the past, but PLEASE STOP USING THE TRUNK AS YOUR PERSONAL DEVELOPMENT SANDBOX. These changes should have gone into a branch, and you should have solicited testers for that branch before any of this stuff went into the mainline. I know you're the maintainer so the rules don't apply to you, but the reality is that when talking about new development (not fixing merge conflicts), you should really be adhering to the same rules that all the other developers use. These rules are there for a reason - to provide an opportunity to catch regressions in new code before they hit the mainline. I know that you have made quite clear that you disagree that you should have to use branches for new development/refactoring. My only hope is that by pointing out every time one of your actions in the trunk causes a nasty regression, perhaps you will rethink your approach. What you call trunk, it not, really a trunk, but a tree where all patches got merged. I've been pointing it several times, but people doesn't seem to listen: that tree is were we'll expect problems to happen, since it is just an alpha staging before submitting things to linux-next, where all patches got merged. The bad thing is that people use it as if they were stable, when it weren't meant to be stable at all. This is your *opinion* that you are stating. I think many (if not most) would disagree with you, in that the v4l-dvb tree should not be treated as alpha quality. It should be generally stable, and things should not be merged into it until they are of releasable quality. Every other developer operates this way *except you*. Every other developer does his work in a separate tree, and that tree is merged once the code is stable. You are the only one who is directly checking things into the trunk that are alpha quality. Many people rely on installing the v4l-dvb tree as a path to get new device support without having to wait for a full kernel to be released and for their distribution to incorporate that kernel. Your failure to work on a branch until code is stable like every other developer contributing to this project is damaging the project's reputation. As a project, we should be embarrassed when our trunk doesn't compile on every kernel version except one. And we should be embarrassed when for nearly a month it is in a state where every board that has IR support causes an OOPS on insertion. That's why I decided to deprecate it. On the next few days, I intend to stop adding patches at -hg tree, passing its maintainance to another person. Douglas already offered to do it for us. The idea is that I'll apply patches directly into my git trees. And then, the hg maintainer will backport the patches into -hg. This also means that patch backports will need to be sent in separate, as those patches won't fit into -git. I'm finishing the details and I'll post an official announce about that soon. Rather than making any announcement, I would strongly encourage you to consider actually soliciting the feedback on your proposed approach from all of the developers who are actually contributing the code to the project. There are many developers who have very strong feelings on how this project should operate, and would likely take considerable exception to any unilateral decision being thrust upon them that has serious implications to how developers will be expected to work in this project. Let's not forget that this is a community of volunteer developers working towards a common cause, and not a dictatorship. 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: [PULL] http://www.kernellabs.com/hg/~dheitmueller/hvr-1600-alsa-2
Am Freitag, den 15.01.2010, 17:22 -0500 schrieb Devin Heitmueller: On Fri, Jan 15, 2010 at 3:00 PM, Mauro Carvalho Chehab mche...@infradead.org wrote: I've tried to tactfully point this out in the past, but PLEASE STOP USING THE TRUNK AS YOUR PERSONAL DEVELOPMENT SANDBOX. These changes should have gone into a branch, and you should have solicited testers for that branch before any of this stuff went into the mainline. I know you're the maintainer so the rules don't apply to you, but the reality is that when talking about new development (not fixing merge conflicts), you should really be adhering to the same rules that all the other developers use. These rules are there for a reason - to provide an opportunity to catch regressions in new code before they hit the mainline. I know that you have made quite clear that you disagree that you should have to use branches for new development/refactoring. My only hope is that by pointing out every time one of your actions in the trunk causes a nasty regression, perhaps you will rethink your approach. What you call trunk, it not, really a trunk, but a tree where all patches got merged. I've been pointing it several times, but people doesn't seem to listen: that tree is were we'll expect problems to happen, since it is just an alpha staging before submitting things to linux-next, where all patches got merged. The bad thing is that people use it as if they were stable, when it weren't meant to be stable at all. This is your *opinion* that you are stating. I think many (if not most) would disagree with you, in that the v4l-dvb tree should not be treated as alpha quality. It should be generally stable, and things should not be merged into it until they are of releasable quality. Every other developer operates this way *except you*. Every other developer does his work in a separate tree, and that tree is merged once the code is stable. You are the only one who is directly checking things into the trunk that are alpha quality. Many people rely on installing the v4l-dvb tree as a path to get new device support without having to wait for a full kernel to be released and for their distribution to incorporate that kernel. Your failure to work on a branch until code is stable like every other developer contributing to this project is damaging the project's reputation. As a project, we should be embarrassed when our trunk doesn't compile on every kernel version except one. And we should be embarrassed when for nearly a month it is in a state where every board that has IR support causes an OOPS on insertion. That's why I decided to deprecate it. On the next few days, I intend to stop adding patches at -hg tree, passing its maintainance to another person. Douglas already offered to do it for us. The idea is that I'll apply patches directly into my git trees. And then, the hg maintainer will backport the patches into -hg. This also means that patch backports will need to be sent in separate, as those patches won't fit into -git. I'm finishing the details and I'll post an official announce about that soon. Rather than making any announcement, I would strongly encourage you to consider actually soliciting the feedback on your proposed approach from all of the developers who are actually contributing the code to the project. There are many developers who have very strong feelings on how this project should operate, and would likely take considerable exception to any unilateral decision being thrust upon them that has serious implications to how developers will be expected to work in this project. Let's not forget that this is a community of volunteer developers working towards a common cause, and not a dictatorship. Devin Oh my. Sometimes it is good to allow breakages for a while. At least after such, you know who really is or can still be around. Nice to see you there. But I also still wait for some Pinnacle LNA explanations ... Cheers, Hermann -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PULL] http://www.kernellabs.com/hg/~dheitmueller/hvr-1600-alsa-2
Devin Heitmueller wrote: Rather than making any announcement, I would strongly encourage you to consider actually soliciting the feedback on your proposed approach from all of the developers who are actually contributing the code to the project. The point here is as simple as I don't have enough time to keep maintaining both -hg and -git trees anymore. So, I'll focus on handling patches at -git, passing the task to maintain the -hg building system to someone else. I don't mind if some or all developers keep using the -hg building system to develop their patches. For patches that come to me via -hg, I'll simply run my scripts that convert an -hg patch into a -git patch, so the patches that will be developed with the build system can be sent to me directly (even pull requests). The only difference is that I won't apply them anymore at -hg, nor I'll apply backport there. So, your demand to not touch on what you call trunk will be satisfied: a separate process will backport the patches from -git and apply them at the master (trunk) -hg tree. In order to avoid troubles, the only rule here is that a patch should be added first on -git, before going to the master -hg. A bonus for the new process is that the several developers that already asked to use git trees can send -git pull requests also. Of course, suggestions to improve the process are always welcome. Cheers, Mauro. -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PULL] http://www.kernellabs.com/hg/~dheitmueller/hvr-1600-alsa-2
Devin Heitmueller wrote: You didn't forget about the em28xx PAL VBI tree, right? I'm just mentioning it because the PULL has been pending for several weeks and came long before the PULL for the HVR-1600 ALSA changes. I tried to, but the hgimport script doesn't like https trees: $ ./hgimport https://www.kernellabs.com/hg/~dheitmueller/em28xx-pal-vbi-2 Pushing from local directory https://www.kernellabs.com/hg/~dheitmueller/em28xx-pal-vbi-2, tree=em28xx-pal-vbi-2 abort: repository 'https://www.kernellabs.com/hg/~dheitmueller/em28xx-pal-vbi-2' is not local Number of patches: 0 Diffstat of the imported series: /tmp/newpatches/hg_em28xx-pal-vbi-2_*.patch: No such file or directory checkpatch.pl: /tmp/newpatches/*.patch: open failed - Arquivo ou diretório não encontrado To cherry pick all files, you can do something like: for i in /tmp/newpatches/*.patch; do ./mailimport $i || exit; done To review all files, you can do something like: for i in /tmp/newpatches/*.patch; do ./v4l/scripts/hghead.pl /tmp/newpatches/*.patch kompare /tmp/newpatches/*.patch; done To merge it, the better is to run the merge script: ./v4l/scripts/do_merge.pl https://www.kernellabs.com/hg/~dheitmueller/em28xx-pal-vbi-2 If you really want to submit https pull requests, please fix hgimport script to accept (I would fix if I had enough time, but I'm with a big backlog, so it is not my priority). Otherwise, please indicate me an http site for me to pull. Thanks, Mauro -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PULL] http://www.kernellabs.com/hg/~dheitmueller/hvr-1600-alsa-2
On Wed, Jan 13, 2010 at 8:44 AM, Mauro Carvalho Chehab mche...@infradead.org wrote: Devin Heitmueller wrote: You didn't forget about the em28xx PAL VBI tree, right? I'm just mentioning it because the PULL has been pending for several weeks and came long before the PULL for the HVR-1600 ALSA changes. I tried to, but the hgimport script doesn't like https trees: $ ./hgimport https://www.kernellabs.com/hg/~dheitmueller/em28xx-pal-vbi-2 Pushing from local directory https://www.kernellabs.com/hg/~dheitmueller/em28xx-pal-vbi-2, tree=em28xx-pal-vbi-2 abort: repository 'https://www.kernellabs.com/hg/~dheitmueller/em28xx-pal-vbi-2' is not local Number of patches: 0 Diffstat of the imported series: /tmp/newpatches/hg_em28xx-pal-vbi-2_*.patch: No such file or directory checkpatch.pl: /tmp/newpatches/*.patch: open failed - Arquivo ou diretório não encontrado To cherry pick all files, you can do something like: for i in /tmp/newpatches/*.patch; do ./mailimport $i || exit; done To review all files, you can do something like: for i in /tmp/newpatches/*.patch; do ./v4l/scripts/hghead.pl /tmp/newpatches/*.patch kompare /tmp/newpatches/*.patch; done To merge it, the better is to run the merge script: ./v4l/scripts/do_merge.pl https://www.kernellabs.com/hg/~dheitmueller/em28xx-pal-vbi-2 If you really want to submit https pull requests, please fix hgimport script to accept (I would fix if I had enough time, but I'm with a big backlog, so it is not my priority). Otherwise, please indicate me an http site for me to pull. Thanks, Mauro Mauro, The same tree is also available using http instead of https: http://www.kernellabs.com/hg/~dheitmueller/em28xx-pal-vbi-2 This should work for you without issue. Regards, Mike -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PULL] http://www.kernellabs.com/hg/~dheitmueller/hvr-1600-alsa-2
Michael Krufky wrote: The same tree is also available using http instead of https: http://www.kernellabs.com/hg/~dheitmueller/em28xx-pal-vbi-2 This should work for you without issue. Ok. Applied, thanks! Mauro. -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PULL] http://www.kernellabs.com/hg/~dheitmueller/hvr-1600-alsa-2
On Wed, Jan 13, 2010 at 9:00 AM, Mauro Carvalho Chehab mche...@infradead.org wrote: Michael Krufky wrote: The same tree is also available using http instead of https: http://www.kernellabs.com/hg/~dheitmueller/em28xx-pal-vbi-2 This should work for you without issue. Ok. Applied, thanks! Sorry about that. I typically cut/paste the link from my browser (and we support both http and https for the HG repo). I will be sure that future PULL requests are http only. Also, I haven't had a chance to rebase this tree against the tip yet, as I burned too much time over the weekend tracking down the regression you introduced into the with the ir-sysfs rework. Did that one line patch get merged yet? It's pretty embarrassing to have a situation for nearly a month where the mainline v4l-dvb causes an OOPS just because they happen to have IR support. In my case, I couldn't even get my PC to boot until I pulled the card from the machine. I've tried to tactfully point this out in the past, but PLEASE STOP USING THE TRUNK AS YOUR PERSONAL DEVELOPMENT SANDBOX. These changes should have gone into a branch, and you should have solicited testers for that branch before any of this stuff went into the mainline. I know you're the maintainer so the rules don't apply to you, but the reality is that when talking about new development (not fixing merge conflicts), you should really be adhering to the same rules that all the other developers use. These rules are there for a reason - to provide an opportunity to catch regressions in new code before they hit the mainline. I know that you have made quite clear that you disagree that you should have to use branches for new development/refactoring. My only hope is that by pointing out every time one of your actions in the trunk causes a nasty regression, perhaps you will rethink your approach. 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: [PULL] http://www.kernellabs.com/hg/~dheitmueller/hvr-1600-alsa-2
Devin Heitmueller wrote: Mauro, Please PULL from http://www.kernellabs.com/hg/~dheitmueller/hvr-1600-alsa-2 for the following: cx18-alsa: Fix the rates definition and move some buffer freeing code. cx18: address possible passing of NULL to snd_card_free cx18-alsa: codingstyle cleanup cx18-alsa: codingstyle cleanup cx18: codingstyle fixes cx18-alsa: codingstyle fixes cx18-alsa: fix codingstyle issue cx18-alsa: fix memory leak in error condition cx18-alsa: remove a couple of warnings cx18-alsa: name alsa device after the actual card cx18: cleanup cx18-alsa debug logging cx18: rework cx18-alsa module loading to support automatic loading cx18-alsa: remove unneeded debug line cx18: export more symbols required by cx18-alsa cx18: add cx18-alsa module to Makefile cx18: overhaul ALSA PCM device handling so it works cx18: export a couple of symbols so they can be shared with cx18-alsa cx18: make it so cx18-alsa-main.c compiles cx18: rename cx18-alsa.c cx18-alsa: Add non-working cx18-alsa-pcm.[ch] files to avoid data loss cx18-alsa: Initial non-working cx18-alsa files This includes the codingstyle fixes Mauro reported as well as the changes Takashi Iwai suggested for the ALSA config and buffer handling. Hi Devin, Unfortunately, I got some merge conflicts with cx18 code from Andy, due to the buffer handling changes. Could you please rebase your tree against tip, solving those conflicts? Cheers, Mauro. -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PULL] http://www.kernellabs.com/hg/~dheitmueller/hvr-1600-alsa-2
On Sun, Jan 10, 2010 at 7:33 AM, Mauro Carvalho Chehab mche...@infradead.org wrote: Hi Devin, Unfortunately, I got some merge conflicts with cx18 code from Andy, due to the buffer handling changes. Could you please rebase your tree against tip, solving those conflicts? Sure, I'll try to do that tonight. I should probably retest anyway to make sure that the buffer changes don't introduce any regressions in the audio code (not that I have any reason to suspect it will). You didn't forget about the em28xx PAL VBI tree, right? I'm just mentioning it because the PULL has been pending for several weeks and came long before the PULL for the HVR-1600 ALSA changes. Cheers, 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: [PULL] http://www.kernellabs.com/hg/~dheitmueller/hvr-1600-alsa-2
On Wed, 2010-01-06 at 23:00 -0500, Devin Heitmueller wrote: Mauro, Please PULL from http://www.kernellabs.com/hg/~dheitmueller/hvr-1600-alsa-2 for the following: In case it's needed: Acked-by: Andy Walls awa...@radix.net Regards, Andy cx18-alsa: Fix the rates definition and move some buffer freeing code. cx18: address possible passing of NULL to snd_card_free cx18-alsa: codingstyle cleanup cx18-alsa: codingstyle cleanup cx18: codingstyle fixes cx18-alsa: codingstyle fixes cx18-alsa: fix codingstyle issue cx18-alsa: fix memory leak in error condition cx18-alsa: remove a couple of warnings cx18-alsa: name alsa device after the actual card cx18: cleanup cx18-alsa debug logging cx18: rework cx18-alsa module loading to support automatic loading cx18-alsa: remove unneeded debug line cx18: export more symbols required by cx18-alsa cx18: add cx18-alsa module to Makefile cx18: overhaul ALSA PCM device handling so it works cx18: export a couple of symbols so they can be shared with cx18-alsa cx18: make it so cx18-alsa-main.c compiles cx18: rename cx18-alsa.c cx18-alsa: Add non-working cx18-alsa-pcm.[ch] files to avoid data loss cx18-alsa: Initial non-working cx18-alsa files This includes the codingstyle fixes Mauro reported as well as the changes Takashi Iwai suggested for the ALSA config and buffer handling. Devin -- To unsubscribe from this list: send the line unsubscribe 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] http://www.kernellabs.com/hg/~dheitmueller/hvr-1600-alsa-2
Mauro, Please PULL from http://www.kernellabs.com/hg/~dheitmueller/hvr-1600-alsa-2 for the following: cx18-alsa: Fix the rates definition and move some buffer freeing code. cx18: address possible passing of NULL to snd_card_free cx18-alsa: codingstyle cleanup cx18-alsa: codingstyle cleanup cx18: codingstyle fixes cx18-alsa: codingstyle fixes cx18-alsa: fix codingstyle issue cx18-alsa: fix memory leak in error condition cx18-alsa: remove a couple of warnings cx18-alsa: name alsa device after the actual card cx18: cleanup cx18-alsa debug logging cx18: rework cx18-alsa module loading to support automatic loading cx18-alsa: remove unneeded debug line cx18: export more symbols required by cx18-alsa cx18: add cx18-alsa module to Makefile cx18: overhaul ALSA PCM device handling so it works cx18: export a couple of symbols so they can be shared with cx18-alsa cx18: make it so cx18-alsa-main.c compiles cx18: rename cx18-alsa.c cx18-alsa: Add non-working cx18-alsa-pcm.[ch] files to avoid data loss cx18-alsa: Initial non-working cx18-alsa files This includes the codingstyle fixes Mauro reported as well as the changes Takashi Iwai suggested for the ALSA config and buffer handling. 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: [PULL] http://www.kernellabs.com/hg/~dheitmueller/hvr-1600-alsa-2
Em 22-12-2009 01:50, Devin Heitmueller escreveu: On Mon, Dec 21, 2009 at 10:24 PM, Mauro Carvalho Chehab mche...@infradead.org wrote: In the case of this patch series, the complains are not related to 80 cols: snip In this case, there was a mix of 80-column issues, as well as some other issues. Yes, there are a few 80-column warnings but those are minor issues. On several cases, fixing such warnings is bad. I did fix the issues other than the 80-column issues through patches added to the tree last night (and in fact I did fix all the 80 column issues in my actual changes - but did not fix 80 column issues that happened to appear in the diff but were pre-existing). Please let me know if you have any other issues. Provided that you've fixed the points that Takashi rised about the alsa part, I'm fine. Please send a separate pull request c/c him , in order to allow him to send his ack. Cheers, Mauro. -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PULL] http://www.kernellabs.com/hg/~dheitmueller/hvr-1600-alsa-2
At Mon, 21 Dec 2009 12:30:48 -0500, Devin Heitmueller wrote: On Mon, Dec 21, 2009 at 12:21 PM, Takashi Iwai ti...@suse.de wrote: Just a very quick look through the files, here are some comments: - snd_card_free() can't be called with NULL, but the error path in snd_cx18_init() may reach that (when snd_card_create() returns an error). - Specifying both SNDRV_PCM_RATE_CONTINOUS and _KNOT to snd_pcm_hw_info.rates doesn't make sense. In your case, if it's only 48kHz, SNDRV_PCM_RATE_48000 there instead. - vfree() should be called in hw_free callback rather than close callback. And, there are already global vmalloc-buffer helper functions in the latest ALSA tree for 2.6.34... - It'd be nice if you give TLV information for the mixer dB mapping. Hello Takashi, Thanks for taking the time to provide feedback. I will make these changes and add them to the tree. Out of curiosity, is there any sort of tool/code which exercises the driver to verify the advertised capabilities. Part of the problem here is that it is not really easy to find example applications which use all the features, which I suspect is one of the big headaches that the PulseAudio people are suffering from in that they are finding bugs in ALSA drivers because they are the first ones to actually attempt to use some of these capabilities. For me the card works, but then some user complains that their PulseAudio is broken because I didn't setup the config structures properly or only half-implemented some capability used by PulseAudio but not arecord/aplay. Yeah, the test suite is one of the biggest missing pieces. Due to its nature, the automatic test is a bit hard to achieve with the real hardwares. Some tools are found, however, in alsa-lib/test directory. For example, pcm.c can test different PCM access methods. Takashi -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PULL] http://www.kernellabs.com/hg/~dheitmueller/hvr-1600-alsa-2
On Tue, Dec 22, 2009 at 5:34 AM, Mauro Carvalho Chehab Provided that you've fixed the points that Takashi rised about the alsa part, I'm fine. Please send a separate pull request c/c him , in order to allow him to send his ack. Ok. With the holidays upon us and my being out of town, I will try to do this Sunday night. Thanks, 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: [PULL] http://www.kernellabs.com/hg/~dheitmueller/hvr-1600-alsa-2
At Sun, 13 Dec 2009 10:22:44 -0500, Devin Heitmueller wrote: On Sat, Dec 12, 2009 at 5:34 PM, Mauro Carvalho Chehab mche...@infradead.org wrote: Hi Devin, It is better to submit the RFC patches to alsa ML for they to take a look. Cheers, Mauro Is there something specific you want the ALSA people to review? There are no changes to the ALSA core and this is a pretty simple/straightforward PCM capture device modelled after the existing cx88/saa7134/em28xx-alsa drivers. The driver is complete, tested by both KernelLabs and the customer. As far as I know, we generally haven't bothered the ALSA people with devices in the /media tree in the past unless there was some specific issue. If there is something here out of the ordinary here that you felt the ALSA people would be able to offer some insight on, I would be more than happy to send it to them. Just a very quick look through the files, here are some comments: - snd_card_free() can't be called with NULL, but the error path in snd_cx18_init() may reach that (when snd_card_create() returns an error). - Specifying both SNDRV_PCM_RATE_CONTINOUS and _KNOT to snd_pcm_hw_info.rates doesn't make sense. In your case, if it's only 48kHz, SNDRV_PCM_RATE_48000 there instead. - vfree() should be called in hw_free callback rather than close callback. And, there are already global vmalloc-buffer helper functions in the latest ALSA tree for 2.6.34... - It'd be nice if you give TLV information for the mixer dB mapping. thanks, Takashi -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PULL] http://www.kernellabs.com/hg/~dheitmueller/hvr-1600-alsa-2
On Mon, Dec 21, 2009 at 12:21 PM, Takashi Iwai ti...@suse.de wrote: Just a very quick look through the files, here are some comments: - snd_card_free() can't be called with NULL, but the error path in snd_cx18_init() may reach that (when snd_card_create() returns an error). - Specifying both SNDRV_PCM_RATE_CONTINOUS and _KNOT to snd_pcm_hw_info.rates doesn't make sense. In your case, if it's only 48kHz, SNDRV_PCM_RATE_48000 there instead. - vfree() should be called in hw_free callback rather than close callback. And, there are already global vmalloc-buffer helper functions in the latest ALSA tree for 2.6.34... - It'd be nice if you give TLV information for the mixer dB mapping. Hello Takashi, Thanks for taking the time to provide feedback. I will make these changes and add them to the tree. Out of curiosity, is there any sort of tool/code which exercises the driver to verify the advertised capabilities. Part of the problem here is that it is not really easy to find example applications which use all the features, which I suspect is one of the big headaches that the PulseAudio people are suffering from in that they are finding bugs in ALSA drivers because they are the first ones to actually attempt to use some of these capabilities. For me the card works, but then some user complains that their PulseAudio is broken because I didn't setup the config structures properly or only half-implemented some capability used by PulseAudio but not arecord/aplay. 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: [PULL] http://www.kernellabs.com/hg/~dheitmueller/hvr-1600-alsa-2
Hi, Am Sonntag, den 20.12.2009, 22:44 -0500 schrieb Andy Walls: On Sun, 2009-12-20 at 22:33 -0500, Devin Heitmueller wrote: On Sun, Dec 20, 2009 at 10:28 PM, Andy Walls awa...@radix.net wrote: Hmmm on the current v4l-dvb tree, the command $ v4l/scripts/checkpatch.pl --no-tree --strict \ -f linux/drivers/media/video/cx18/cx18-driver.c yields warnings about pre-existing 80 column lines and LINUX_VERSION_CODE checks. Was there something else? No, that's what I'm talking about. I figured if you wanted to split the CX18_ERR messages to fit on 80 columns, that is really at your discretion, not mine. I can certainly do it, of course, but I personally believe it's one of those cases where it is better to not split them. Ah. No I wouldn't bother. The LKML has some churn on checkpatch's 80 column warning in the past few days: http://lkml.org/lkml/2009/12/17/208 In that thread Joe Perches posted a compromise: http://lkml.org/lkml/2009/12/18/3 I'll wait and see how it comes out. BTW I have got unsubscribe from the LKML - way too many emails in my inbox. Regards, Andy Devin just as a side note. IIRC, this took about two years to come through now. http://lkml.org/lkml/2009/12/18/276 Some people did stop to post patches at all and other patches were lost, because such last steps of bureaucrac(z)y were too much for more than a few ... Most annoying, since also lines in patch offsets were marked as errors, residing since many years in kernel and accepted once without complaints, now should be corrected by one just trying to add a new similar functional device. It is often hard enough to figure out some new unknown hardware. Then, given the back and forth on it and all, even with best will, one could trap into cases even a full weekend is not enough to add some five to eight lines of code correctly within some such minefield exposed/created by such rules for an average contributor ... Alone, that counted code lines in kernel can nearly double by doing so should be enough to make it never a strict rule, I thought ... Cheers, Hermann -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PULL] http://www.kernellabs.com/hg/~dheitmueller/hvr-1600-alsa-2
Em 21-12-2009 01:44, Andy Walls escreveu: On Sun, 2009-12-20 at 22:33 -0500, Devin Heitmueller wrote: On Sun, Dec 20, 2009 at 10:28 PM, Andy Walls awa...@radix.net wrote: Hmmm on the current v4l-dvb tree, the command $ v4l/scripts/checkpatch.pl --no-tree --strict \ -f linux/drivers/media/video/cx18/cx18-driver.c yields warnings about pre-existing 80 column lines and LINUX_VERSION_CODE checks. Was there something else? No, that's what I'm talking about. I figured if you wanted to split the CX18_ERR messages to fit on 80 columns, that is really at your discretion, not mine. I can certainly do it, of course, but I personally believe it's one of those cases where it is better to not split them. Ah. No I wouldn't bother. The LKML has some churn on checkpatch's 80 column warning in the past few days: The 80 cols is just a warning. It is useful basically to point places where perhaps the logic is being too complex (for example, cases where there are several loops inside). In the case of this patch series, the complains are not related to 80 cols: cx18-alsa: Initial non-working cx18-alsa files ERROR: need consistent spacing around '+' (ctx:WxV) #124: FILE: linux/drivers/media/video/cx18/cx18-alsa-mixer.c:95: + uinfo-value.integer.max = +8; ^ total: 1 errors, 0 warnings, 579 lines checked /tmp/newpatches/hg_hvr-1600-alsa-2_02.patch: cx18-alsa: Add non-working cx18-alsa-pcm.[ch] files to avoid data loss /tmp/newpatches/hg_hvr-1600-alsa-2_04.patch: cx18: make it so cx18-alsa-main.c compiles WARNING: line over 80 characters #44: FILE: linux/drivers/media/video/cx18/cx18-alsa-main.c:44: +#define CX18_DEBUG_ALSA_INFO(fmt, arg...) printk(KERN_INFO %s: fmt, cx18-alsa, ## arg) WARNING: printk() should include KERN_ facility level #89: FILE: linux/drivers/media/video/cx18/cx18-alsa-main.c:254: + printk(cx18-alsa: drv was null\n); total: 0 errors, 2 warnings, 74 lines checked /tmp/newpatches/hg_hvr-1600-alsa-2_06.patch: cx18: overhaul ALSA PCM device handling so it works WARNING: externs should be avoided in .c files #41: FILE: linux/drivers/media/video/cx18/cx18-alsa-pcm.c:40: +extern int cx18_alsa_debug; WARNING: externs should be avoided in .c files #50: FILE: linux/drivers/media/video/cx18/cx18-alsa-pcm.c:49: +void cx18_alsa_announce_pcm_data(struct snd_cx18_card *cxsc, u8 *pcm_data, WARNING: LINUX_VERSION_CODE should be avoided, code should be for the version to which it is merged #53: FILE: linux/drivers/media/video/cx18/cx18-alsa-pcm.c:52: +#if LINUX_VERSION_CODE = KERNEL_VERSION(2, 6, 16) WARNING: LINUX_VERSION_CODE should be avoided, code should be for the version to which it is merged #162: FILE: linux/drivers/media/video/cx18/cx18-alsa-pcm.c:164: +#if LINUX_VERSION_CODE = KERNEL_VERSION(2, 6, 16) WARNING: LINUX_VERSION_CODE should be avoided, code should be for the version to which it is merged #169: FILE: linux/drivers/media/video/cx18/cx18-alsa-pcm.c:171: +#if LINUX_VERSION_CODE = KERNEL_VERSION(2, 6, 16) WARNING: LINUX_VERSION_CODE should be avoided, code should be for the version to which it is merged #232: FILE: linux/drivers/media/video/cx18/cx18-alsa-pcm.c:240: +#if LINUX_VERSION_CODE = KERNEL_VERSION(2, 6, 16) WARNING: line over 80 characters #361: FILE: linux/drivers/media/video/cx18/cx18-alsa-pcm.c:389: + snd_pcm_set_ops(sp, SNDRV_PCM_STREAM_CAPTURE, snd_cx18_pcm_capture_ops); total: 0 errors, 7 warnings, 396 lines checked /tmp/newpatches/hg_hvr-1600-alsa-2_10.patch: cx18: rework cx18-alsa module loading to support automatic loading WARNING: EXPORT_SYMBOL(foo); should immediately follow its function/variable #100: FILE: linux/drivers/media/video/cx18/cx18-driver.c:52: +EXPORT_SYMBOL(cx18_ext_init); WARNING: LINUX_VERSION_CODE should be avoided, code should be for the version to which it is merged #131: FILE: linux/drivers/media/video/cx18/cx18-driver.c:1220: +#if LINUX_VERSION_CODE KERNEL_VERSION(2,6,20) ERROR: space required after that ',' (ctx:VxV) #131: FILE: linux/drivers/media/video/cx18/cx18-driver.c:1220: +#if LINUX_VERSION_CODE KERNEL_VERSION(2,6,20) ^ ERROR: space required after that ',' (ctx:VxV) #131: FILE: linux/drivers/media/video/cx18/cx18-driver.c:1220: +#if LINUX_VERSION_CODE KERNEL_VERSION(2,6,20) ^ ERROR: spaces required around that '=' (ctx:VxV) #138: FILE: linux/drivers/media/video/cx18/cx18-driver.c:1227: + struct cx18 *dev=container_of(work, struct cx18, request_module_wk); ^ WARNING: LINUX_VERSION_CODE should be avoided, code should be for the version to which it is merged #151: FILE: linux/drivers/media/video/cx18/cx18-driver.c:1240: +#if LINUX_VERSION_CODE KERNEL_VERSION(2,6,20) ERROR: space required after that ',' (ctx:VxV) #151: FILE: linux/drivers/media/video/cx18/cx18-driver.c:1240: +#if LINUX_VERSION_CODE
Re: [PULL] http://www.kernellabs.com/hg/~dheitmueller/hvr-1600-alsa-2
On Mon, Dec 21, 2009 at 10:24 PM, Mauro Carvalho Chehab mche...@infradead.org wrote: In the case of this patch series, the complains are not related to 80 cols: snip In this case, there was a mix of 80-column issues, as well as some other issues. I did fix the issues other than the 80-column issues through patches added to the tree last night (and in fact I did fix all the 80 column issues in my actual changes - but did not fix 80 column issues that happened to appear in the diff but were pre-existing). Please let me know if you have any other issues. 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: [PULL] http://www.kernellabs.com/hg/~dheitmueller/hvr-1600-alsa-2
On Mon, Dec 14, 2009 at 11:19 AM, Mauro Carvalho Chehab mche...@infradead.org wrote: Em Mon, 14 Dec 2009 11:10:50 -0500 Devin Heitmueller dheitmuel...@kernellabs.com escreveu: On Mon, Dec 14, 2009 at 11:09 AM, Mauro Carvalho Chehab mche...@infradead.org wrote: I can't pull. Your site is not responding. Hmm... it seems a temporary failure. It is working now. That is strange (works fine from here). You reported a similar issue trying to pull one of Michael Krufky's trees last week. I will have to keep an eye on it. Yep. Btw, there are a few CodingStyle issues. Please send later a patch fixing it. I'll be reviewing the patch series. Cheers, Mauro Sorry about the delay on this. I took a pass over the files and cleaned up the bulk of the codingstyle issues. The remaining issues on the cx18-driver.c were pre-existing and the change is not obvious (probably needs input from the maintainer). There is still one warning about an #if 0 case in cx18-alsa-main.c, but this is being left there because it is a hook into the mixer routines, which are currently not supported (there is a cx18-alsa-mixer.c file but none of the controls are implemented yet). I added the patches to the original hvr-1600-alsa-2 tree, since the tree has not been merged yet. 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: [PULL] http://www.kernellabs.com/hg/~dheitmueller/hvr-1600-alsa-2
On Sun, 2009-12-20 at 22:02 -0500, Devin Heitmueller wrote: On Mon, Dec 14, 2009 at 11:19 AM, Mauro Carvalho Chehab mche...@infradead.org wrote: Em Mon, 14 Dec 2009 11:10:50 -0500 Devin Heitmueller dheitmuel...@kernellabs.com escreveu: On Mon, Dec 14, 2009 at 11:09 AM, Mauro Carvalho Chehab mche...@infradead.org wrote: I can't pull. Your site is not responding. Hmm... it seems a temporary failure. It is working now. That is strange (works fine from here). You reported a similar issue trying to pull one of Michael Krufky's trees last week. I will have to keep an eye on it. Yep. Btw, there are a few CodingStyle issues. Please send later a patch fixing it. I'll be reviewing the patch series. Cheers, Mauro Sorry about the delay on this. I took a pass over the files and cleaned up the bulk of the codingstyle issues. The remaining issues on the cx18-driver.c were pre-existing and the change is not obvious (probably needs input from the maintainer). Hmmm on the current v4l-dvb tree, the command $ v4l/scripts/checkpatch.pl --no-tree --strict \ -f linux/drivers/media/video/cx18/cx18-driver.c yields warnings about pre-existing 80 column lines and LINUX_VERSION_CODE checks. Was there something else? Regards, Andy There is still one warning about an #if 0 case in cx18-alsa-main.c, but this is being left there because it is a hook into the mixer routines, which are currently not supported (there is a cx18-alsa-mixer.c file but none of the controls are implemented yet). I added the patches to the original hvr-1600-alsa-2 tree, since the tree has not been merged yet. Devin -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PULL] http://www.kernellabs.com/hg/~dheitmueller/hvr-1600-alsa-2
On Sun, Dec 20, 2009 at 10:28 PM, Andy Walls awa...@radix.net wrote: Hmmm on the current v4l-dvb tree, the command $ v4l/scripts/checkpatch.pl --no-tree --strict \ -f linux/drivers/media/video/cx18/cx18-driver.c yields warnings about pre-existing 80 column lines and LINUX_VERSION_CODE checks. Was there something else? No, that's what I'm talking about. I figured if you wanted to split the CX18_ERR messages to fit on 80 columns, that is really at your discretion, not mine. I can certainly do it, of course, but I personally believe it's one of those cases where it is better to not split them. 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: [PULL] http://www.kernellabs.com/hg/~dheitmueller/hvr-1600-alsa-2
On Sun, 2009-12-20 at 22:33 -0500, Devin Heitmueller wrote: On Sun, Dec 20, 2009 at 10:28 PM, Andy Walls awa...@radix.net wrote: Hmmm on the current v4l-dvb tree, the command $ v4l/scripts/checkpatch.pl --no-tree --strict \ -f linux/drivers/media/video/cx18/cx18-driver.c yields warnings about pre-existing 80 column lines and LINUX_VERSION_CODE checks. Was there something else? No, that's what I'm talking about. I figured if you wanted to split the CX18_ERR messages to fit on 80 columns, that is really at your discretion, not mine. I can certainly do it, of course, but I personally believe it's one of those cases where it is better to not split them. Ah. No I wouldn't bother. The LKML has some churn on checkpatch's 80 column warning in the past few days: http://lkml.org/lkml/2009/12/17/208 In that thread Joe Perches posted a compromise: http://lkml.org/lkml/2009/12/18/3 I'll wait and see how it comes out. BTW I have got unsubscribe from the LKML - way too many emails in my inbox. Regards, Andy Devin -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PULL] http://www.kernellabs.com/hg/~dheitmueller/hvr-1600-alsa-2
Em Sat, 12 Dec 2009 16:00:27 -0500 Devin Heitmueller dheitmuel...@kernellabs.com escreveu: Hello Mauro, Please pull from http://www.kernellabs.com/hg/~dheitmueller/hvr-1600-alsa-2 for the following: cx18-alsa: fix memory leak in error condition cx18-alsa: remove a couple of warnings cx18-alsa: name alsa device after the actual card cx18: cleanup cx18-alsa debug logging cx18: rework cx18-alsa module loading to support automatic loading cx18-alsa: remove unneeded debug line cx18: export more symbols required by cx18-alsa cx18: add cx18-alsa module to Makefile cx18: overhaul ALSA PCM device handling so it works cx18: export a couple of symbols so they can be shared with cx18-alsa cx18: make it so cx18-alsa-main.c compiles cx18: rename cx18-alsa.c cx18-alsa: Add non-working cx18-alsa-pcm.[ch] files to avoid data loss cx18-alsa: Initial non-working cx18-alsa files I would also like to take this opportunity to thank ONELAN Limited for their sponsoring of this work, as well as to Andy Walls for providing some initial code and guidance on how to best integrate the ALSA support with the rest of the cx18 driver. $ ./hgimport http://www.kernellabs.com/hg/~dheitmueller/hvr-1600-alsa-2 Pushing from remote site http://www.kernellabs.com/hg/~dheitmueller/hvr-1600-alsa-2, tree: hvr-1600-alsa-2 rm: imposível remover `/tmp/newpatches/*': Arquivo ou diretório não encontrado abort: error: Temporary failure in name resolution I can't pull. Your site is not responding. Cheers, Mauro -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PULL] http://www.kernellabs.com/hg/~dheitmueller/hvr-1600-alsa-2
Em Mon, 14 Dec 2009 14:07:42 -0200 Mauro Carvalho Chehab mche...@infradead.org escreveu: Em Sat, 12 Dec 2009 16:00:27 -0500 Devin Heitmueller dheitmuel...@kernellabs.com escreveu: Hello Mauro, Please pull from http://www.kernellabs.com/hg/~dheitmueller/hvr-1600-alsa-2 for the following: cx18-alsa: fix memory leak in error condition cx18-alsa: remove a couple of warnings cx18-alsa: name alsa device after the actual card cx18: cleanup cx18-alsa debug logging cx18: rework cx18-alsa module loading to support automatic loading cx18-alsa: remove unneeded debug line cx18: export more symbols required by cx18-alsa cx18: add cx18-alsa module to Makefile cx18: overhaul ALSA PCM device handling so it works cx18: export a couple of symbols so they can be shared with cx18-alsa cx18: make it so cx18-alsa-main.c compiles cx18: rename cx18-alsa.c cx18-alsa: Add non-working cx18-alsa-pcm.[ch] files to avoid data loss cx18-alsa: Initial non-working cx18-alsa files I would also like to take this opportunity to thank ONELAN Limited for their sponsoring of this work, as well as to Andy Walls for providing some initial code and guidance on how to best integrate the ALSA support with the rest of the cx18 driver. $ ./hgimport http://www.kernellabs.com/hg/~dheitmueller/hvr-1600-alsa-2 Pushing from remote site http://www.kernellabs.com/hg/~dheitmueller/hvr-1600-alsa-2, tree: hvr-1600-alsa-2 rm: imposível remover `/tmp/newpatches/*': Arquivo ou diretório não encontrado abort: error: Temporary failure in name resolution I can't pull. Your site is not responding. Hmm... it seems a temporary failure. It is working now. Cheers, Mauro Cheers, Mauro -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PULL] http://www.kernellabs.com/hg/~dheitmueller/hvr-1600-alsa-2
On Mon, Dec 14, 2009 at 11:09 AM, Mauro Carvalho Chehab mche...@infradead.org wrote: I can't pull. Your site is not responding. Hmm... it seems a temporary failure. It is working now. That is strange (works fine from here). You reported a similar issue trying to pull one of Michael Krufky's trees last week. I will have to keep an eye on it. 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: [PULL] http://www.kernellabs.com/hg/~dheitmueller/hvr-1600-alsa-2
Em Mon, 14 Dec 2009 11:10:50 -0500 Devin Heitmueller dheitmuel...@kernellabs.com escreveu: On Mon, Dec 14, 2009 at 11:09 AM, Mauro Carvalho Chehab mche...@infradead.org wrote: I can't pull. Your site is not responding. Hmm... it seems a temporary failure. It is working now. That is strange (works fine from here). You reported a similar issue trying to pull one of Michael Krufky's trees last week. I will have to keep an eye on it. Yep. Btw, there are a few CodingStyle issues. Please send later a patch fixing it. I'll be reviewing the patch series. Cheers, Mauro Pushing from remote site http://www.kernellabs.com/hg/~dheitmueller/hvr-1600-alsa-2, tree: hvr-1600-alsa-2 Number of patches: 14 /tmp/newpatches/hg_hvr-1600-alsa-2_01.patch with cs=878a34e7beac First patch. Patch against an older patch: changeset: 13370:7477df192a59 user:Mauro Carvalho Chehab mche...@redhat.com date:Wed Nov 18 05:12:04 2009 -0200 summary: Add a list of known issues to v4l2-apps /tmp/newpatches/hg_hvr-1600-alsa-2_02.patch with cs=a631e089c9d6 Ok. /tmp/newpatches/hg_hvr-1600-alsa-2_03.patch with cs=a20a6f8ebf42 Ok. /tmp/newpatches/hg_hvr-1600-alsa-2_04.patch with cs=f576485071d3 Ok. /tmp/newpatches/hg_hvr-1600-alsa-2_05.patch with cs=605c1f7fed3c Ok. /tmp/newpatches/hg_hvr-1600-alsa-2_06.patch with cs=cb267593943f Ok. /tmp/newpatches/hg_hvr-1600-alsa-2_07.patch with cs=749aa3ccbb84 Ok. /tmp/newpatches/hg_hvr-1600-alsa-2_08.patch with cs=4ea6a2a3b501 Ok. /tmp/newpatches/hg_hvr-1600-alsa-2_09.patch with cs=58c37088f6a6 Ok. /tmp/newpatches/hg_hvr-1600-alsa-2_10.patch with cs=7b6e737ddb79 Ok. /tmp/newpatches/hg_hvr-1600-alsa-2_11.patch with cs=6bc4dc4993f7 Ok. /tmp/newpatches/hg_hvr-1600-alsa-2_12.patch with cs=e47b8ea0c818 Ok. /tmp/newpatches/hg_hvr-1600-alsa-2_13.patch with cs=95df6a4cce66 Ok. /tmp/newpatches/hg_hvr-1600-alsa-2_14.patch with cs=355c08546c21 Ok. Diffstat of the imported series: linux/drivers/media/video/cx18/Kconfig | 11 linux/drivers/media/video/cx18/Makefile |2 linux/drivers/media/video/cx18/cx18-alsa-main.c | 370 - linux/drivers/media/video/cx18/cx18-alsa-mixer.c | 191 linux/drivers/media/video/cx18/cx18-alsa-mixer.h | 23 linux/drivers/media/video/cx18/cx18-alsa-pcm.c | 407 +- linux/drivers/media/video/cx18/cx18-alsa-pcm.h | 27 linux/drivers/media/video/cx18/cx18-alsa.c | 606 +++ linux/drivers/media/video/cx18/cx18-alsa.h | 59 + linux/drivers/media/video/cx18/cx18-driver.c | 44 + linux/drivers/media/video/cx18/cx18-driver.h | 10 linux/drivers/media/video/cx18/cx18-fileops.c|6 linux/drivers/media/video/cx18/cx18-fileops.h|3 linux/drivers/media/video/cx18/cx18-mailbox.c| 16 linux/drivers/media/video/cx18/cx18-streams.c|2 15 files changed, 1429 insertions(+), 348 deletions(-) /tmp/newpatches/hg_hvr-1600-alsa-2_01.patch: cx18-alsa: Initial non-working cx18-alsa files ERROR: need consistent spacing around '+' (ctx:WxV) #124: FILE: linux/drivers/media/video/cx18/cx18-alsa-mixer.c:95: + uinfo-value.integer.max = +8; ^ total: 1 errors, 0 warnings, 579 lines checked /tmp/newpatches/hg_hvr-1600-alsa-2_02.patch: cx18-alsa: Add non-working cx18-alsa-pcm.[ch] files to avoid data loss /tmp/newpatches/hg_hvr-1600-alsa-2_04.patch: cx18: make it so cx18-alsa-main.c compiles WARNING: line over 80 characters #44: FILE: linux/drivers/media/video/cx18/cx18-alsa-main.c:44: +#define CX18_DEBUG_ALSA_INFO(fmt, arg...) printk(KERN_INFO %s: fmt, cx18-alsa, ## arg) WARNING: printk() should include KERN_ facility level #89: FILE: linux/drivers/media/video/cx18/cx18-alsa-main.c:254: + printk(cx18-alsa: drv was null\n); total: 0 errors, 2 warnings, 74 lines checked /tmp/newpatches/hg_hvr-1600-alsa-2_06.patch: cx18: overhaul ALSA PCM device handling so it works WARNING: externs should be avoided in .c files #41: FILE: linux/drivers/media/video/cx18/cx18-alsa-pcm.c:40: +extern int cx18_alsa_debug; WARNING: externs should be avoided in .c files #50: FILE: linux/drivers/media/video/cx18/cx18-alsa-pcm.c:49: +void cx18_alsa_announce_pcm_data(struct snd_cx18_card *cxsc, u8 *pcm_data, WARNING: LINUX_VERSION_CODE should be avoided, code should be for the version to which it is merged #53: FILE: linux/drivers/media/video/cx18/cx18-alsa-pcm.c:52: +#if LINUX_VERSION_CODE = KERNEL_VERSION(2, 6, 16) WARNING: LINUX_VERSION_CODE should be avoided, code should be for the version to which it is merged #162: FILE: linux/drivers/media/video/cx18/cx18-alsa-pcm.c:164: +#if LINUX_VERSION_CODE = KERNEL_VERSION(2, 6, 16) WARNING: LINUX_VERSION_CODE should be avoided, code should be for the version to which it is merged #169: FILE: linux/drivers/media/video/cx18/cx18-alsa-pcm.c:171: +#if LINUX_VERSION_CODE = KERNEL_VERSION(2, 6, 16) WARNING: LINUX_VERSION_CODE should be avoided, code should be for the
Re: [PULL] http://www.kernellabs.com/hg/~dheitmueller/hvr-1600-alsa-2
On Mon, Dec 14, 2009 at 11:19 AM, Mauro Carvalho Chehab mche...@infradead.org wrote: Em Mon, 14 Dec 2009 11:10:50 -0500 Devin Heitmueller dheitmuel...@kernellabs.com escreveu: On Mon, Dec 14, 2009 at 11:09 AM, Mauro Carvalho Chehab mche...@infradead.org wrote: I can't pull. Your site is not responding. Hmm... it seems a temporary failure. It is working now. That is strange (works fine from here). You reported a similar issue trying to pull one of Michael Krufky's trees last week. I will have to keep an eye on it. Yep. Btw, there are a few CodingStyle issues. Please send later a patch fixing it. No problem. I will take care of these tonight (some of them are unrelated to my changes but happened to appear in the diff so they got flagged). Also, I am tempted to set the cx18 alsa driver to only work for kernels 2.6.25, so that I don't need any of the PCM lock changes, which are totally unvalidated and not needed by the customer. 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: [PULL] http://www.kernellabs.com/hg/~dheitmueller/hvr-1600-alsa-2
On Sat, Dec 12, 2009 at 5:34 PM, Mauro Carvalho Chehab mche...@infradead.org wrote: Hi Devin, It is better to submit the RFC patches to alsa ML for they to take a look. Cheers, Mauro Is there something specific you want the ALSA people to review? There are no changes to the ALSA core and this is a pretty simple/straightforward PCM capture device modelled after the existing cx88/saa7134/em28xx-alsa drivers. The driver is complete, tested by both KernelLabs and the customer. As far as I know, we generally haven't bothered the ALSA people with devices in the /media tree in the past unless there was some specific issue. If there is something here out of the ordinary here that you felt the ALSA people would be able to offer some insight on, I would be more than happy to send it to them. 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
[PULL] http://www.kernellabs.com/hg/~dheitmueller/hvr-1600-alsa-2
Hello Mauro, Please pull from http://www.kernellabs.com/hg/~dheitmueller/hvr-1600-alsa-2 for the following: cx18-alsa: fix memory leak in error condition cx18-alsa: remove a couple of warnings cx18-alsa: name alsa device after the actual card cx18: cleanup cx18-alsa debug logging cx18: rework cx18-alsa module loading to support automatic loading cx18-alsa: remove unneeded debug line cx18: export more symbols required by cx18-alsa cx18: add cx18-alsa module to Makefile cx18: overhaul ALSA PCM device handling so it works cx18: export a couple of symbols so they can be shared with cx18-alsa cx18: make it so cx18-alsa-main.c compiles cx18: rename cx18-alsa.c cx18-alsa: Add non-working cx18-alsa-pcm.[ch] files to avoid data loss cx18-alsa: Initial non-working cx18-alsa files I would also like to take this opportunity to thank ONELAN Limited for their sponsoring of this work, as well as to Andy Walls for providing some initial code and guidance on how to best integrate the ALSA support with the rest of the cx18 driver. 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: [PULL] http://www.kernellabs.com/hg/~dheitmueller/hvr-1600-alsa-2
Hi Devin, It is better to submit the RFC patches to alsa ML for they to take a look. Cheers, Mauro Devin Heitmueller wrote: Hello Mauro, Please pull from http://www.kernellabs.com/hg/~dheitmueller/hvr-1600-alsa-2 for the following: cx18-alsa: fix memory leak in error condition cx18-alsa: remove a couple of warnings cx18-alsa: name alsa device after the actual card cx18: cleanup cx18-alsa debug logging cx18: rework cx18-alsa module loading to support automatic loading cx18-alsa: remove unneeded debug line cx18: export more symbols required by cx18-alsa cx18: add cx18-alsa module to Makefile cx18: overhaul ALSA PCM device handling so it works cx18: export a couple of symbols so they can be shared with cx18-alsa cx18: make it so cx18-alsa-main.c compiles cx18: rename cx18-alsa.c cx18-alsa: Add non-working cx18-alsa-pcm.[ch] files to avoid data loss cx18-alsa: Initial non-working cx18-alsa files I would also like to take this opportunity to thank ONELAN Limited for their sponsoring of this work, as well as to Andy Walls for providing some initial code and guidance on how to best integrate the ALSA support with the rest of the cx18 driver. Devin -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
