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
Am Freitag, den 15.01.2010, 17:22 -0500 schrieb Devin Heitmueller: > On Fri, Jan 15, 2010 at 3:00 PM, Mauro Carvalho Chehab > 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
On Fri, Jan 15, 2010 at 3:00 PM, Mauro Carvalho Chehab 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
Devin Heitmueller wrote: > On Wed, Jan 13, 2010 at 9:00 AM, Mauro Carvalho Chehab > 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 Wed, Jan 13, 2010 at 9:00 AM, Mauro Carvalho Chehab 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
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 8:44 AM, Mauro Carvalho Chehab 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
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 Sun, Jan 10, 2010 at 7:33 AM, Mauro Carvalho Chehab 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
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 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 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
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 Mon, 21 Dec 2009 12:30:48 -0500, Devin Heitmueller wrote: > > On Mon, Dec 21, 2009 at 12:21 PM, Takashi Iwai 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
Em 22-12-2009 01:50, Devin Heitmueller escreveu: > On Mon, Dec 21, 2009 at 10:24 PM, Mauro Carvalho Chehab > wrote: >> In the case of this patch series, the complains are not related to 80 cols: > > > 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
On Mon, Dec 21, 2009 at 10:24 PM, Mauro Carvalho Chehab wrote: > In the case of this patch series, the complains are not related to 80 cols: 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
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 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:
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 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
On Mon, Dec 21, 2009 at 12:21 PM, Takashi Iwai 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
At Sun, 13 Dec 2009 10:22:44 -0500, Devin Heitmueller wrote: > > On Sat, Dec 12, 2009 at 5:34 PM, Mauro Carvalho Chehab > 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 Sun, 2009-12-20 at 22:33 -0500, Devin Heitmueller wrote: > On Sun, Dec 20, 2009 at 10:28 PM, Andy Walls 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
On Sun, Dec 20, 2009 at 10:28 PM, Andy Walls 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:02 -0500, Devin Heitmueller wrote: > On Mon, Dec 14, 2009 at 11:19 AM, Mauro Carvalho Chehab > wrote: > > Em Mon, 14 Dec 2009 11:10:50 -0500 > > Devin Heitmueller escreveu: > > > >> On Mon, Dec 14, 2009 at 11:09 AM, Mauro Carvalho Chehab > >> 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 Mon, Dec 14, 2009 at 11:19 AM, Mauro Carvalho Chehab wrote: > Em Mon, 14 Dec 2009 11:10:50 -0500 > Devin Heitmueller escreveu: > >> On Mon, Dec 14, 2009 at 11:09 AM, Mauro Carvalho Chehab >> 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 Mon, Dec 14, 2009 at 11:19 AM, Mauro Carvalho Chehab wrote: > Em Mon, 14 Dec 2009 11:10:50 -0500 > Devin Heitmueller escreveu: > >> On Mon, Dec 14, 2009 at 11:09 AM, Mauro Carvalho Chehab >> 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
Em Mon, 14 Dec 2009 11:10:50 -0500
Devin Heitmueller escreveu:
> On Mon, Dec 14, 2009 at 11:09 AM, Mauro Carvalho Chehab
> 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
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 version
to which it is merged
#232: FILE: linu
Re: [PULL] http://www.kernellabs.com/hg/~dheitmueller/hvr-1600-alsa-2
On Mon, Dec 14, 2009 at 11:09 AM, Mauro Carvalho Chehab 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 14:07:42 -0200 Mauro Carvalho Chehab escreveu: > Em Sat, 12 Dec 2009 16:00:27 -0500 > Devin Heitmueller 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
Em Sat, 12 Dec 2009 16:00:27 -0500 Devin Heitmueller 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
On Sat, Dec 12, 2009 at 5:34 PM, Mauro Carvalho Chehab 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
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
