Re: [linux-dvb] [PATCH] Userspace tuner
Am Donnerstag, den 13.09.2007, 16:36 -0400 schrieb Steven Toth: > > > >> Also there is to consider a non technical aspect, whether vendors will > >> misuse this interface for binary only, undermining the efforts put in > >> for OSS drivers. > >> > >> > > > > What holds companies for using the current available code putting it > > into an rpm or deb package and releasing such code now? > > > > The Avermedia example I pointed out to is a good example already. > > As from my side I won't release binary drivers. > > Although on the other side: > > * are drivers from vendors which work through several kernel versions > > that bad? > > * Why did someone duallicense videodev2 with BSD/GPL? > > > > I would appreciate if someone else on the list could also comment > > the reason that drivers should all be included in the linuxkernel just > > because forcing the companies to release binary drivers because > > of that. My opinion about that is if a company wants to go opensource > > they will do so, if not they will either not release a driver or release > > nothing. > > > > > > > I know for certain that adding a userland API tuner/demod interface to > the kernel, allowing non-caring opportunistic silicon or board vendors > to developer closed source proprietary drivers, will have a negative > effect on the community and we'd set back linuxtv 3-5 years. > > I know for certain that it would happen. Trust me. > > I've told you this countless times and you're not hearing me. > > Hauppauge have some leverage with Conexant and NXP to release public > datasheets. If they just have to release a demod.so (or similar) > loadable, they'll defer to the board vendors and we'll see the certain > board vendors 'locking other board vendors' out of their drivers. We'll > see embedded firmware, not shared between drivers. > > Except, it won't stop at demod.so. It will extend into unfixable bugs > for VendorB's board, because VendorA doesn't want to release a new > demod.so, and VendorB has no linux resources. What happens next? For > financial reasons - demod.so will begin to include checks to see if > specific PCI or USB devices are present in the system, and will fail to > work properly (if at all) when they're not being used with the preferred > products. > > Read my lips: For commercial reasons, this enables driver components > that only work if specific boards are present. > > - Steve > I do confirn that I have all this, Steve mentions, really have seen already! Markus, sorry, they did abuse it and will do it again. Hermann - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-dvb] [PATCH] Userspace tuner
Am Donnerstag, den 13.09.2007, 16:36 -0400 schrieb Steven Toth: Also there is to consider a non technical aspect, whether vendors will misuse this interface for binary only, undermining the efforts put in for OSS drivers. What holds companies for using the current available code putting it into an rpm or deb package and releasing such code now? The Avermedia example I pointed out to is a good example already. As from my side I won't release binary drivers. Although on the other side: * are drivers from vendors which work through several kernel versions that bad? * Why did someone duallicense videodev2 with BSD/GPL? I would appreciate if someone else on the list could also comment the reason that drivers should all be included in the linuxkernel just because forcing the companies to release binary drivers because of that. My opinion about that is if a company wants to go opensource they will do so, if not they will either not release a driver or release nothing. I know for certain that adding a userland API tuner/demod interface to the kernel, allowing non-caring opportunistic silicon or board vendors to developer closed source proprietary drivers, will have a negative effect on the community and we'd set back linuxtv 3-5 years. I know for certain that it would happen. Trust me. I've told you this countless times and you're not hearing me. Hauppauge have some leverage with Conexant and NXP to release public datasheets. If they just have to release a demod.so (or similar) loadable, they'll defer to the board vendors and we'll see the certain board vendors 'locking other board vendors' out of their drivers. We'll see embedded firmware, not shared between drivers. Except, it won't stop at demod.so. It will extend into unfixable bugs for VendorB's board, because VendorA doesn't want to release a new demod.so, and VendorB has no linux resources. What happens next? For financial reasons - demod.so will begin to include checks to see if specific PCI or USB devices are present in the system, and will fail to work properly (if at all) when they're not being used with the preferred products. Read my lips: For commercial reasons, this enables driver components that only work if specific boards are present. - Steve I do confirn that I have all this, Steve mentions, really have seen already! Markus, sorry, they did abuse it and will do it again. Hermann - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [v4l-dvb-maintainer] [PATCH] [534/2many] MAINTAINERS - VIDEO FOR LINUX
Am Dienstag, den 14.08.2007, 18:02 +0400 schrieb Manu Abraham: > On 8/14/07, Mauro Carvalho Chehab <[EMAIL PROTECTED]> wrote: > > > > > > > > > F: drivers/media/* > > > > > > > > > This is NOT OK ! > > > > This IS ok. You just need to read the definition of the 'F' tag: > > > > F: Files and directories with wildcard patterns. > >A trailing slash includes all files and subdirectory files. > > F: drivers/net/all files in and below drivers/net > > F: drivers/net/* all files in drivers/net, but not below > > F: */net/* all files in "any top level directory"/net > >One pattern per line. Multiple F: lines acceptable. > > > > This tag just includes Kconfig and Makefile. > > > Just as much as you state that, the reverse is as well true for > Kconfig and Makefile. > Please explain what you still want and why. After two almost wasted years, you should be able to do so. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [v4l-dvb-maintainer] [PATCH] [534/2many] MAINTAINERS - VIDEO FOR LINUX
Am Dienstag, den 14.08.2007, 18:02 +0400 schrieb Manu Abraham: On 8/14/07, Mauro Carvalho Chehab [EMAIL PROTECTED] wrote: F: drivers/media/* This is NOT OK ! This IS ok. You just need to read the definition of the 'F' tag: F: Files and directories with wildcard patterns. A trailing slash includes all files and subdirectory files. F: drivers/net/all files in and below drivers/net F: drivers/net/* all files in drivers/net, but not below F: */net/* all files in any top level directory/net One pattern per line. Multiple F: lines acceptable. This tag just includes Kconfig and Makefile. Just as much as you state that, the reverse is as well true for Kconfig and Makefile. Please explain what you still want and why. After two almost wasted years, you should be able to do so. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: NDAs - ANY KNOWN RULES?
Am Dienstag, den 26.06.2007, 19:37 -0700 schrieb Arjan van de Ven: > > Thanks for your explanations, > > > > but I know for sure it does't work. > > then.. do you have an actual question or are you just trying to troll? > > and yes there have been several such trolls lately on this list, and so > far your postings have all the signs of being just another one.. > > > DO NOT FEED THE TROLLS > > Hello, thanks ;), you might help me to decide if somebody abuses a list already for free advertising or is still contributing. http://marc.info/?l=linux-video=118289479416612=2 Sorry, my question is, where one can look up if the pinning of a newer chip we support is also only under NDA available. Previously often at least that was public. (examples now saa7131e, tda10046a, tda8275ac1) If I don't find anything on the web, whom I have to ask that question, the NDA holder, the manufacturer or do we have a list, because everybody knows that this can be helpful to identify hardware differences and this question is always asked already? Thanks, Hermann - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: NDAs - ANY KNOWN RULES?
Am Dienstag, den 26.06.2007, 19:37 -0700 schrieb Arjan van de Ven: Thanks for your explanations, but I know for sure it does't work. then.. do you have an actual question or are you just trying to troll? and yes there have been several such trolls lately on this list, and so far your postings have all the signs of being just another one.. DO NOT FEED THE TROLLS Hello, thanks ;), you might help me to decide if somebody abuses a list already for free advertising or is still contributing. http://marc.info/?l=linux-videom=118289479416612w=2 Sorry, my question is, where one can look up if the pinning of a newer chip we support is also only under NDA available. Previously often at least that was public. (examples now saa7131e, tda10046a, tda8275ac1) If I don't find anything on the web, whom I have to ask that question, the NDA holder, the manufacturer or do we have a list, because everybody knows that this can be helpful to identify hardware differences and this question is always asked already? Thanks, Hermann - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: NDAs - ANY KNOWN RULES?
Am Dienstag, den 26.06.2007, 20:24 -0400 schrieb Daniel Barkalow: > On Wed, 27 Jun 2007, hermann pitton wrote: > > > Hi, > > > > such stuff causes a lot of troubles since long. > > > > Are there any rules, or can everybody go on as some sort of freelancer > > exclusively on such? I don't like it! > > http://www.linux-foundation.org/en/NDA_program > > In short, the Linux Foundation can negotiate a reasonable NDA for you to > sign, and they may be able to show you relevant documents as a freelancer > under a reasonable and standardized contract. > > -Daniel > *This .sig left intentionally blank* Thanks for your explanations, but I know for sure it does't work. Cheers, Hermann - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
NDAs - ANY KNOWN RULES?
Hi, such stuff causes a lot of troubles since long. Are there any rules, or can everybody go on as some sort of freelancer exclusively on such? I don't like it! Cheers, Hermann - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
NDAs - ANY KNOWN RULES?
Hi, such stuff causes a lot of troubles since long. Are there any rules, or can everybody go on as some sort of freelancer exclusively on such? I don't like it! Cheers, Hermann - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: NDAs - ANY KNOWN RULES?
Am Dienstag, den 26.06.2007, 20:24 -0400 schrieb Daniel Barkalow: On Wed, 27 Jun 2007, hermann pitton wrote: Hi, such stuff causes a lot of troubles since long. Are there any rules, or can everybody go on as some sort of freelancer exclusively on such? I don't like it! http://www.linux-foundation.org/en/NDA_program In short, the Linux Foundation can negotiate a reasonable NDA for you to sign, and they may be able to show you relevant documents as a freelancer under a reasonable and standardized contract. -Daniel *This .sig left intentionally blank* Thanks for your explanations, but I know for sure it does't work. Cheers, Hermann - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-dvb] dst customization patchset
Am Freitag, den 01.06.2007, 00:03 +0200 schrieb Markus Rechberger: > On 5/31/07, Uwe Bugla <[EMAIL PROTECTED]> wrote: > > Am Donnerstag, 31. Mai 2007 07:01 schrieb Bill Eldridge: > > > timecop wrote: > > > >> Guys, it's GPL code. Fork the project and stop your bitching. > > > >> If you do a better job, people will use and contribute to your > > version. > > > >> If you do a worse job, people will use and contribute to Manu's. > > > >> Some will use and contribute to both. Life's good, eh? > > > > > > > > This is exactly why Linux is shit. > > > > You have 100s of "forked projects" because some guy named Uwe thought > > > > he could do better than some guy named Manu and now you have two > > > > projects to contribute to, both suck in various ways, of course some > > > > idiot is going to be "backporting" from one to another, introducing > > > > weird bugs, etc etc etc. > > > > > > > > Make a fucking decision and stick with it. Stop wasting everyone's > > > > time. It's no secret that current Linux-DVB/V4L/whatever system is a > > > > pile of steaming feces. Every one of you admitted to it on this list > > > > at some point in the past. So get to it, make a fucking decision, > > > > "fire" (loool) retards who are slowing the project down, and get shit > > > > moving. I vote for Uwe as Linux-DVB maintainer. > > > > Regards, > > > > tc > > > > > > I nominate Timecop to be maintainer/top cop to figure out which version > > > sucks in which area > > > and do his best to get the best approach used. Sometimes a good strong > > > and outspoken > > > manager is more important than technical prowess (and I have no idea as > > > to your technical > > > abilities, just saying it looks like a management issue). > > > > I am not a fan of "strong men" or "strong managers" of whatever kind. We in > > Germany have very bad experiences concerning this kind of human desire / > > call > > regarding our history. > > Instead there should be one responsible code reviewer for v4l stuff, and at > > least one responsible code reviewer for DVB stuff. > > This is a minimum adequate demand to make things work. > > > > Inactivity on future projects in connection with Nacks of activities to > > optimize the stock kernel are no fair play or helpful behaviour at all, but > > they are just counterproductive. Who likes small kings? Well, I do not! > > > > > > > > For Uwe, it's not that I don't "want" to understand anything - I just > > > showed up 2 days ago and > > > simply want a workable driver for my machine, and instead had to switch > > > cards to something > > > else. Usually I assume if the code was forked the fork would be > > > somewhere else and you wouldn't > > > be complaining to this list, but I understand there are different ways. > > > (Samba did it this way for > > > quite some time). > > > > Forking may be OK for different Linux distros. But v4l-DVB is not a distro, > > it > > should be a common project instead. > > > > What you find is some 20 developers with a multiplicity of repositories. > > You do not even know who is maintainer and who is not. > > What you also find is the blocking gesture of that person who once threw his > > hat into the ring wanting to become maintainer. > > As the whole situation is one big mess you do not even know whether becoming > > a > > maintainer or not is product of a democtratic vote. > > > > Above that there is no team structure at all, but instead there is a big > > chaos, mess. > > And if some code, may it be humble or mature, is not even pulled into the > > mm-tree (its basic role has always been testing, nothing else) I would call > > that a catastrophe. > > > > Uwe writes alot insulting crap (which is a fact), YES. > even if the DVB > subsystem has no maintainer the code should be managed appropriately > and stopping the development is no way to do it. > At the moment we have __tonns of critical bugs__ in the drivers and > the video4linux and dvb framework; both frameworks are incomplete and > don't provide the necessary flexibility to support an infrastructure > for devices which could already be supported at the moment. > > We have several (technical) good people which which work on the > framework on different parts but who don't cooperate at all and who > cannot work together at all. > We have alot code which is managed in separated repositories where > different developers spent several years of development (including > reverse engineering, hacking and so on) it's a shame that the whole > project is stuck where it is. New developers who fundamentally want to > change something are not welcome at all, even if they have valuable > ideas. > > Some developers are also sick of contributing since the whole > community is flawed at the moment. I propose a few ways to go YES. > * stopping that signed off by madness that every driver developer has > to sign off changes which happened at the core which will definitelly > never happen because people _do not like each other_.
Re: [linux-dvb] dst customization patchset
Am Freitag, den 01.06.2007, 00:03 +0200 schrieb Markus Rechberger: On 5/31/07, Uwe Bugla [EMAIL PROTECTED] wrote: Am Donnerstag, 31. Mai 2007 07:01 schrieb Bill Eldridge: timecop wrote: Guys, it's GPL code. Fork the project and stop your bitching. If you do a better job, people will use and contribute to your version. If you do a worse job, people will use and contribute to Manu's. Some will use and contribute to both. Life's good, eh? This is exactly why Linux is shit. You have 100s of forked projects because some guy named Uwe thought he could do better than some guy named Manu and now you have two projects to contribute to, both suck in various ways, of course some idiot is going to be backporting from one to another, introducing weird bugs, etc etc etc. Make a fucking decision and stick with it. Stop wasting everyone's time. It's no secret that current Linux-DVB/V4L/whatever system is a pile of steaming feces. Every one of you admitted to it on this list at some point in the past. So get to it, make a fucking decision, fire (loool) retards who are slowing the project down, and get shit moving. I vote for Uwe as Linux-DVB maintainer. Regards, tc I nominate Timecop to be maintainer/top cop to figure out which version sucks in which area and do his best to get the best approach used. Sometimes a good strong and outspoken manager is more important than technical prowess (and I have no idea as to your technical abilities, just saying it looks like a management issue). I am not a fan of strong men or strong managers of whatever kind. We in Germany have very bad experiences concerning this kind of human desire / call regarding our history. Instead there should be one responsible code reviewer for v4l stuff, and at least one responsible code reviewer for DVB stuff. This is a minimum adequate demand to make things work. Inactivity on future projects in connection with Nacks of activities to optimize the stock kernel are no fair play or helpful behaviour at all, but they are just counterproductive. Who likes small kings? Well, I do not! For Uwe, it's not that I don't want to understand anything - I just showed up 2 days ago and simply want a workable driver for my machine, and instead had to switch cards to something else. Usually I assume if the code was forked the fork would be somewhere else and you wouldn't be complaining to this list, but I understand there are different ways. (Samba did it this way for quite some time). Forking may be OK for different Linux distros. But v4l-DVB is not a distro, it should be a common project instead. What you find is some 20 developers with a multiplicity of repositories. You do not even know who is maintainer and who is not. What you also find is the blocking gesture of that person who once threw his hat into the ring wanting to become maintainer. As the whole situation is one big mess you do not even know whether becoming a maintainer or not is product of a democtratic vote. Above that there is no team structure at all, but instead there is a big chaos, mess. And if some code, may it be humble or mature, is not even pulled into the mm-tree (its basic role has always been testing, nothing else) I would call that a catastrophe. Uwe writes alot insulting crap (which is a fact), YES. even if the DVB subsystem has no maintainer the code should be managed appropriately and stopping the development is no way to do it. At the moment we have __tonns of critical bugs__ in the drivers and the video4linux and dvb framework; both frameworks are incomplete and don't provide the necessary flexibility to support an infrastructure for devices which could already be supported at the moment. We have several (technical) good people which which work on the framework on different parts but who don't cooperate at all and who cannot work together at all. We have alot code which is managed in separated repositories where different developers spent several years of development (including reverse engineering, hacking and so on) it's a shame that the whole project is stuck where it is. New developers who fundamentally want to change something are not welcome at all, even if they have valuable ideas. Some developers are also sick of contributing since the whole community is flawed at the moment. I propose a few ways to go YES. * stopping that signed off by madness that every driver developer has to sign off changes which happened at the core which will definitelly never happen because people _do not like each other_. We are forced to it. * change the maintainership and push it over to me, even if it sounds selfish at the moment _every_ code which provides additional features and where noone expects further improvements within the next few weeks (without
Re: [linux-dvb] DST/BT878 module customization (.. was: Critical points about ...)
Am Freitag, den 04.05.2007, 02:31 +0400 schrieb Manu Abraham: > Markus Rechberger wrote: > > > I mean the mail from Helge Hafting (thread [linux-dvb] Critical > > points about kernel 2.6.21 and pseudo-authorities) at the very first > > beginning. > > > > I am replying to this mail, just because someone's spreading lies all > around. > On the mentioned thread, what i wrote (and that was the only mail from > my side): > > There is a saying: "He who lives by the sword, dies by the sword." > Within the last six years there was in the end exactly one, never asked for, private mail with worst *bullshit* about another person, Mauro in this case. It came from you, out of any feasible arguments for me anymore. I'm stupid, but not stupid enough to allow such stuff coming in rule. But I still say you have been first and are waiting longest to get your work in, please try again to get your ACKs and rant about not enough replies. Cheers, Hermann - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-dvb] DST/BT878 module customization (.. was: Critical points about ...)
Am Freitag, den 04.05.2007, 02:31 +0400 schrieb Manu Abraham: Markus Rechberger wrote: I mean the mail from Helge Hafting (thread [linux-dvb] Critical points about kernel 2.6.21 and pseudo-authorities) at the very first beginning. I am replying to this mail, just because someone's spreading lies all around. On the mentioned thread, what i wrote (and that was the only mail from my side): There is a saying: He who lives by the sword, dies by the sword. Within the last six years there was in the end exactly one, never asked for, private mail with worst *bullshit* about another person, Mauro in this case. It came from you, out of any feasible arguments for me anymore. I'm stupid, but not stupid enough to allow such stuff coming in rule. But I still say you have been first and are waiting longest to get your work in, please try again to get your ACKs and rant about not enough replies. Cheers, Hermann - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-dvb] Re: Critical points about kernel 2.6.21 and pseudo-authorities
Am Dienstag, den 01.05.2007, 01:05 +0200 schrieb Uwe Bugla: > Original-Nachricht > Datum: Mon, 30 Apr 2007 15:41:03 -0700 (PDT) > Von: Trent Piepho <[EMAIL PROTECTED]> > An: Linus Torvalds <[EMAIL PROTECTED]> > CC: Linux Kernel Mailing list , Michael Krufky > <[EMAIL PROTECTED]>, [EMAIL PROTECTED], Linux DVB <[EMAIL PROTECTED]> > Betreff: Re: [linux-dvb] Re: Critical points about kernel 2.6.21 and > pseudo-authorities > > > On Mon, 30 Apr 2007, Linus Torvalds wrote: > > > Anyway, I'll get out of the discussion. There's clearly some personality > > > issues in the DVB area, and I don't know quite _why_ that is, but Uwe, > > > you're definitely not helping. > > > > There isn't a problem here, just a lot of noise coming from one source. I > > have no problem with Mauro and think he does a good job and is an > > extremely > > reasonable person. He is just getting Uwe's thesaurus thrown at him > > because he's the closest target. > > > > Sure there are disagreements sometimes, but this is always the case. I > > can > > think of plenty of lists far more full of flames and personality conflicts > > than linux-dvb. > > > > The issue with dst is just a minor missing feature to fully support the > > dvb > > helper module customization system. So nobody needs to worry about this > > anymore, the last two patches in this repository will fix it correctly. > > > > http://linuxtv.org/hg/~tap/dst-new?cmd=summary;style=gitweb > > > > Making dvb-pll work fully with this same system is a little more complex. > > It's on the virtual todo list, but not at the top. > > > > I'll finish with this completely unrelated quote. > > > > > >"Especially important is the warning to avoid conversations with the > > demon. > >We may ask what is relevant but anything beyond that is dangerous. He > > is a > >liar. The demon is a liar. He will lie to confuse us. But he will > > also > >mix lies with the truth to attack us. The attack is psychological, > > Damien, > >and powerful. So don't listen to him. Remember that - do not listen." > > - from "The Exorcist" > > > > ___ > > linux-dvb mailing list > > [EMAIL PROTECTED] > > http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb > > Piepho, you are a devil, and your links do not work at all! > Uwe > Try again, this devil's stuff almost always works :) Cheers, Hermann - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-dvb] Re: Critical points about kernel 2.6.21 and pseudo-authorities
Am Dienstag, den 01.05.2007, 01:05 +0200 schrieb Uwe Bugla: Original-Nachricht Datum: Mon, 30 Apr 2007 15:41:03 -0700 (PDT) Von: Trent Piepho [EMAIL PROTECTED] An: Linus Torvalds [EMAIL PROTECTED] CC: Linux Kernel Mailing list linux-kernel@vger.kernel.org, Michael Krufky [EMAIL PROTECTED], [EMAIL PROTECTED], Linux DVB [EMAIL PROTECTED] Betreff: Re: [linux-dvb] Re: Critical points about kernel 2.6.21 and pseudo-authorities On Mon, 30 Apr 2007, Linus Torvalds wrote: Anyway, I'll get out of the discussion. There's clearly some personality issues in the DVB area, and I don't know quite _why_ that is, but Uwe, you're definitely not helping. There isn't a problem here, just a lot of noise coming from one source. I have no problem with Mauro and think he does a good job and is an extremely reasonable person. He is just getting Uwe's thesaurus thrown at him because he's the closest target. Sure there are disagreements sometimes, but this is always the case. I can think of plenty of lists far more full of flames and personality conflicts than linux-dvb. The issue with dst is just a minor missing feature to fully support the dvb helper module customization system. So nobody needs to worry about this anymore, the last two patches in this repository will fix it correctly. http://linuxtv.org/hg/~tap/dst-new?cmd=summary;style=gitweb Making dvb-pll work fully with this same system is a little more complex. It's on the virtual todo list, but not at the top. I'll finish with this completely unrelated quote. Especially important is the warning to avoid conversations with the demon. We may ask what is relevant but anything beyond that is dangerous. He is a liar. The demon is a liar. He will lie to confuse us. But he will also mix lies with the truth to attack us. The attack is psychological, Damien, and powerful. So don't listen to him. Remember that - do not listen. - from The Exorcist ___ linux-dvb mailing list [EMAIL PROTECTED] http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb Piepho, you are a devil, and your links do not work at all! Uwe Try again, this devil's stuff almost always works :) Cheers, Hermann - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-dvb] Re: Critical points about kernel 2.6.21 and pseudo-authorities
Am Montag, den 30.04.2007, 01:00 +0200 schrieb Uwe Bugla: > Original-Nachricht > Datum: Sun, 29 Apr 2007 14:19:22 -0700 (PDT) > Von: Linus Torvalds <[EMAIL PROTECTED]> > An: Uwe Bugla <[EMAIL PROTECTED]> > CC: [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], > linux-kernel@vger.kernel.org, [EMAIL PROTECTED] > Betreff: Re: Critical points about kernel 2.6.21 and pseudo-authorities > > > > > > > On Sun, 29 Apr 2007, Uwe Bugla wrote: > > > > > > I have been trying diff and other tools in various variants (except > > > git-bisect that I cannot handle because I do not understand the practice > > > of it). > > > > git bisect is _really_ simple if you already have a git tree anyway. And > > even if you don't, getting one isn't really hard either. Just do > > > > git clone > > git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git > > linux-2.6 > > > > and you have a tree (it will take a little while - it's going to dowload > > about 170MB or so of stuff, so the initial clone is going to be a bit > > painful unless you have a fast internet connection). > > > > Once you have the git tree, assuming that 2.6.21-rc7 worked for you, it's > > really as easy as just saying > > > > git bisect start > > git bisect good v2.6.21-rc7 > > git bisect bad v2.6.21 > > > > and git will think for a short while (most of the time is going to be > > checking out the new tree) and give you a tree to test. > > > > Just build, boot, and test that tree. > > > > If it was fine, do > > > > git bisect good > > > > and git will pick a new tree to test. And if it wasn't, instead just do > > "git bisect bad", and git will pick _another_ version to test. Do this a > > few times, and git will tell you which commit introduced them. > > > > There were just 125 commits in between 2.6.21-rc7 and the final one, so it > > should be quite quick - bisection basically does a binary search, so doing > > seven reboots should have you with the result. > > > > The fact that it already works in 2.6.21-git2 obviously means that _I_ end > > up being less interested, but the -stable tree people would love to hear > > what broke! > > Hi again Linus, > my deep thanks for your excellent explication of git-bisect. > But I unfortunately owe a 100Kbit flatrate, and so downloading some 170 MB > git tree will need the time amount of one entire night (11.5 kb /s if I am > lucky - no more). > Just to take up a different approach: > > The difference between 2.6.21-rc7 and 2.6.21 official does not play any role > at all. > > On the other hand I found out that: > 2.6.21-rc7 made my AMD K7 router work fine > 2.6.21 official hung my AMD K7 router up > 2.6.21-git1 hung my AMD K7 router up > 2.6.21-git2 made my AMD K7 router work. > > In so far the diff between 2.6.21-git1 and 2.6.21-git2 obviously solves the > problem. > Or am I saying something wrong as far as logical terms are concerned? > > > > > > I like small and effective kernels instead of blown up RAM waste. > > > This is no Windoze, man, this is Linux! > > > > Yes. But if you cannot be polite and *RESPECTFUL*, you won't get anywhere > > at all. > > > > This is Linux, not Windows. But that also means that those developers that > > you denigrate aren't getting paid by you, and if you don't show them > > respect, they'll totally ignore you. > > > > Linus > > Now this is the old problem about it all: the hypocricy factor, the utmost > small, if not to say pre-pubertarian character plus some other obviously > counter-productive character traits in those so-called "maintainers" who > behave like kids, but not like grown-ups at all! > Not only you, but also Andrew perfectly and willingly step into the > hypocritic trap and do not even feel that they are trapped! > > For the majority of all cases of the so-called "maintainer personnel" at > linuxtv.org the statement of some missing "politeness" or some missing > "respect" is nothing but an utmost dumb, kiddish, human mediocre and utmost > stupid and utmost hypocritic excuse for bare naked incompatibility, dumbness, > wrong solidarity, kiddishness and technical incompetence. > > They are building up pseudo-authorities to hide their lack of competence, no > matter if their lack of competence funds on technical or human lacks. > And at least the Brazilian Mauro Carvalho Chehab does go even so far to soap > in Andrew Morton's face with this enourmous threat of incompetence, > kiddishness, incompatibility, hypocricy, lies, stigmatisations, stubbornness, > lack of experience, pre-pubertarian behaviour, fascistoid opinion > dictatorship as part of a deep immature anti-democratic and reactionary > personality structure. > > Would you call Mauro Carvalho Chehab a maintainer! > I can certify you that I cannot, even if I try. And I want him to be > substituted as quick as possible as he is the biggest mismatch of gatekeeper > one can ever imagine. > > And
Re: [linux-dvb] Re: Critical points about kernel 2.6.21 and pseudo-authorities
Am Montag, den 30.04.2007, 01:00 +0200 schrieb Uwe Bugla: Original-Nachricht Datum: Sun, 29 Apr 2007 14:19:22 -0700 (PDT) Von: Linus Torvalds [EMAIL PROTECTED] An: Uwe Bugla [EMAIL PROTECTED] CC: [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], linux-kernel@vger.kernel.org, [EMAIL PROTECTED] Betreff: Re: Critical points about kernel 2.6.21 and pseudo-authorities On Sun, 29 Apr 2007, Uwe Bugla wrote: I have been trying diff and other tools in various variants (except git-bisect that I cannot handle because I do not understand the practice of it). git bisect is _really_ simple if you already have a git tree anyway. And even if you don't, getting one isn't really hard either. Just do git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git linux-2.6 and you have a tree (it will take a little while - it's going to dowload about 170MB or so of stuff, so the initial clone is going to be a bit painful unless you have a fast internet connection). Once you have the git tree, assuming that 2.6.21-rc7 worked for you, it's really as easy as just saying git bisect start git bisect good v2.6.21-rc7 git bisect bad v2.6.21 and git will think for a short while (most of the time is going to be checking out the new tree) and give you a tree to test. Just build, boot, and test that tree. If it was fine, do git bisect good and git will pick a new tree to test. And if it wasn't, instead just do git bisect bad, and git will pick _another_ version to test. Do this a few times, and git will tell you which commit introduced them. There were just 125 commits in between 2.6.21-rc7 and the final one, so it should be quite quick - bisection basically does a binary search, so doing seven reboots should have you with the result. The fact that it already works in 2.6.21-git2 obviously means that _I_ end up being less interested, but the -stable tree people would love to hear what broke! Hi again Linus, my deep thanks for your excellent explication of git-bisect. But I unfortunately owe a 100Kbit flatrate, and so downloading some 170 MB git tree will need the time amount of one entire night (11.5 kb /s if I am lucky - no more). Just to take up a different approach: The difference between 2.6.21-rc7 and 2.6.21 official does not play any role at all. On the other hand I found out that: 2.6.21-rc7 made my AMD K7 router work fine 2.6.21 official hung my AMD K7 router up 2.6.21-git1 hung my AMD K7 router up 2.6.21-git2 made my AMD K7 router work. In so far the diff between 2.6.21-git1 and 2.6.21-git2 obviously solves the problem. Or am I saying something wrong as far as logical terms are concerned? I like small and effective kernels instead of blown up RAM waste. This is no Windoze, man, this is Linux! Yes. But if you cannot be polite and *RESPECTFUL*, you won't get anywhere at all. This is Linux, not Windows. But that also means that those developers that you denigrate aren't getting paid by you, and if you don't show them respect, they'll totally ignore you. Linus Now this is the old problem about it all: the hypocricy factor, the utmost small, if not to say pre-pubertarian character plus some other obviously counter-productive character traits in those so-called maintainers who behave like kids, but not like grown-ups at all! Not only you, but also Andrew perfectly and willingly step into the hypocritic trap and do not even feel that they are trapped! For the majority of all cases of the so-called maintainer personnel at linuxtv.org the statement of some missing politeness or some missing respect is nothing but an utmost dumb, kiddish, human mediocre and utmost stupid and utmost hypocritic excuse for bare naked incompatibility, dumbness, wrong solidarity, kiddishness and technical incompetence. They are building up pseudo-authorities to hide their lack of competence, no matter if their lack of competence funds on technical or human lacks. And at least the Brazilian Mauro Carvalho Chehab does go even so far to soap in Andrew Morton's face with this enourmous threat of incompetence, kiddishness, incompatibility, hypocricy, lies, stigmatisations, stubbornness, lack of experience, pre-pubertarian behaviour, fascistoid opinion dictatorship as part of a deep immature anti-democratic and reactionary personality structure. Would you call Mauro Carvalho Chehab a maintainer! I can certify you that I cannot, even if I try. And I want him to be substituted as quick as possible as he is the biggest mismatch of gatekeeper one can ever imagine. And it is not only me personally perceiving this that there are people missing who can go upright and offer sophisticated and good work. Plus a real sophisticated discussion behaviour, in
Re: [linux-dvb] Re: [video4linux-cvs] [hg:v4l-dvb] Add support for Opera S1- DVB-USB
Am Freitag, den 20.04.2007, 03:42 +0400 schrieb Manu Abraham: > hermann pitton wrote: > > Am Freitag, den 20.04.2007, 03:19 +0400 schrieb Manu Abraham: > >> hermann pitton wrote: > >>> Am Freitag, den 20.04.2007, 02:51 +0400 schrieb Manu Abraham: > >>>> Markus Rechberger wrote: > >>>>> On 4/20/07, Manu Abraham <[EMAIL PROTECTED]> wrote: > >>>>>> hermann pitton wrote: > >>>>>>> Am Freitag, den 20.04.2007, 00:55 +0400 schrieb Manu Abraham: > >>>>>>>> Mauro Carvalho Chehab wrote: > >>>>>>>>> Em Qui, 2007-04-19 às 16:41 -0400, Michael Krufky escreveu: > >>>>>>>>>> Marco Gittler wrote: > >>>>>>>>>>> this patch has applied the hints from mkrufky (dvb_attach, > >>>>>>>>>>> firmware-naming) > >>>>>>>>>>> and also one working rewrite of the i2c addresses stuff to fit the > >>>>>>>>>>> kernel i2c reqs. > >>>>>>>>>>> > >>>>>>>>>>> Signed-off-by: Marco Gittler<[EMAIL PROTECTED]> > >>>>>>>>>>> diff -r c8b73ec18b42 linux/drivers/media/dvb/dvb-usb/opera1.c > >>>>>>>>>>> --- a/linux/drivers/media/dvb/dvb-usb/opera1.cThu Apr 19 > >>>>>> 12:04:50 > >>>>>> 2007 -0300 > >>>>>>>>>>> +++ b/linux/drivers/media/dvb/dvb-usb/opera1.cThu Apr 19 > >>>>>> 20:38:01 > >>>>>> 2007 +0200 > >>>>>>>>>>> @@ -25,6 +25,13 @@ > >>>>>>>>>>> #define REG_20_SYMBOLRATE_BYTE1 0x20 > >>>>>>>>>>> #define REG_21_SYMBOLRATE_BYTE2 0x21 > >>>>>>>>>>> > >>>>>>>>>>> +#define ADDR_C0_TUNER (0xc0>>1) > >>>>>>>>>>> +#define ADDR_D0_PLL (0xd0>>1) > >>>>>>>>>>> > >>>>>>>>>> I don't like these two #define's. These i2c addresses need only be > >>>>>>>>>> specified once, in the config structs / frontendfoo_attach calls > >>>>>>>>>> for > >>>>>> the > >>>>>>>>>> tuner / demod. > >>>>>>>>>> > >>>>>>>>>> Better to just put them in as constants like all of the other dvb > >>>>>> drivers. > >>>>>>>>> I prefer the way it is. We should really avoid having magic numbers > >>>>>>>>> inside the code. The alias here helps to know that 0x60 is tuner > >>>>>> addres > >>>>>>>>> and 0x68 the pll. > >>>>>>>> Following a project's coding styles and conventions is "respecting" a > >>>>>>>> project > >>>>>>>> > >>>>>>>> Manu > >>>>>>>> > >>>>>>> Hi, > >>>>>>> > >>>>>>> the other natural place for this should be the LKML to get more _good_ > >>>>>>> arguments, instead of hanging soon in some "respect" stuff again. > >>>>>> DVB drivers generally have device addresses such as tuner_addresses and > >>>>>> demod_adresses defined in a config struct least to prevent them from > >>>>>> being global, wherever the header is included, since the very same > >>>>>> device can have multiple addresses and so on, which are non-probable > >>>>>> since being behind a repeater which is switched by a demod (private) > >>>>>> and > >>>>>> hence. > >>>>>> > >>>>>> Those are some of the reasons to follow a certain coding > >>>>>> style/conventions. They are _not_ for fun. > >>>>>> > >>>>> cat *priv.h says something else too... > >>>>> there are also many global register defines in DVB drivers, they just > >>>>> don't include the register value in the define name. > >>>> *_priv.h from what i understand means private .. i don't know what you > >>>> make out from that. > >>>> > >>>> > >>>> HTH, > >>>> Manu > >>> ;) > >>> > >>> That means that I had to post the actual headers to every single tester > >> If you use a private header as a public header, of course yes. But that > >> is not what private explicitly means. > >> It _is_ indeed wrong to use a private header as a public header _even_ > >> for workarounds. > >> > >> HTH, > >> Manu > > > > Forget it. > > > > That is as wrong as older Fedora distros were shipping v4l2 apps like > > tvtime, but only providing v4l1 headers on the user level. > > > > I don't know about Fedora shipping v4l2 apps. Forgive my ignorance. But > it is really hopeless to include a private header for a device into > another device. Anyway not talking about V4L1/2/n headers, but about DVB > device (demod/tuner) private headers being included publicly. Private > means private, i don't understand how the notion comes around that a > private header is a public header. > > It is _not_ named private for no reason. > The GPL was also not named GPL for no reason. HTH, Hermann - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-dvb] Re: [video4linux-cvs] [hg:v4l-dvb] Add support for Opera S1- DVB-USB
Am Freitag, den 20.04.2007, 03:19 +0400 schrieb Manu Abraham: > hermann pitton wrote: > > Am Freitag, den 20.04.2007, 02:51 +0400 schrieb Manu Abraham: > >> Markus Rechberger wrote: > >>> On 4/20/07, Manu Abraham <[EMAIL PROTECTED]> wrote: > >>>> hermann pitton wrote: > >>>>> Am Freitag, den 20.04.2007, 00:55 +0400 schrieb Manu Abraham: > >>>>>> Mauro Carvalho Chehab wrote: > >>>>>>> Em Qui, 2007-04-19 às 16:41 -0400, Michael Krufky escreveu: > >>>>>>>> Marco Gittler wrote: > >>>>>>>>> this patch has applied the hints from mkrufky (dvb_attach, > >>>>>>>>> firmware-naming) > >>>>>>>>> and also one working rewrite of the i2c addresses stuff to fit the > >>>>>>>>> kernel i2c reqs. > >>>>>>>>> > >>>>>>>>> Signed-off-by: Marco Gittler<[EMAIL PROTECTED]> > >>>>>>>>> diff -r c8b73ec18b42 linux/drivers/media/dvb/dvb-usb/opera1.c > >>>>>>>>> --- a/linux/drivers/media/dvb/dvb-usb/opera1.cThu Apr 19 > >>>> 12:04:50 > >>>> 2007 -0300 > >>>>>>>>> +++ b/linux/drivers/media/dvb/dvb-usb/opera1.cThu Apr 19 > >>>> 20:38:01 > >>>> 2007 +0200 > >>>>>>>>> @@ -25,6 +25,13 @@ > >>>>>>>>> #define REG_20_SYMBOLRATE_BYTE1 0x20 > >>>>>>>>> #define REG_21_SYMBOLRATE_BYTE2 0x21 > >>>>>>>>> > >>>>>>>>> +#define ADDR_C0_TUNER (0xc0>>1) > >>>>>>>>> +#define ADDR_D0_PLL (0xd0>>1) > >>>>>>>>> > >>>>>>>> I don't like these two #define's. These i2c addresses need only be > >>>>>>>> specified once, in the config structs / frontendfoo_attach calls for > >>>> the > >>>>>>>> tuner / demod. > >>>>>>>> > >>>>>>>> Better to just put them in as constants like all of the other dvb > >>>> drivers. > >>>>>>> I prefer the way it is. We should really avoid having magic numbers > >>>>>>> inside the code. The alias here helps to know that 0x60 is tuner > >>>> addres > >>>>>>> and 0x68 the pll. > >>>>>> Following a project's coding styles and conventions is "respecting" a > >>>>>> project > >>>>>> > >>>>>> Manu > >>>>>> > >>>>> Hi, > >>>>> > >>>>> the other natural place for this should be the LKML to get more _good_ > >>>>> arguments, instead of hanging soon in some "respect" stuff again. > >>>> > >>>> DVB drivers generally have device addresses such as tuner_addresses and > >>>> demod_adresses defined in a config struct least to prevent them from > >>>> being global, wherever the header is included, since the very same > >>>> device can have multiple addresses and so on, which are non-probable > >>>> since being behind a repeater which is switched by a demod (private) and > >>>> hence. > >>>> > >>>> Those are some of the reasons to follow a certain coding > >>>> style/conventions. They are _not_ for fun. > >>>> > >>> cat *priv.h says something else too... > >>> there are also many global register defines in DVB drivers, they just > >>> don't include the register value in the define name. > >> > >> *_priv.h from what i understand means private .. i don't know what you > >> make out from that. > >> > >> > >> HTH, > >> Manu > > > > ;) > > > > That means that I had to post the actual headers to every single tester > > If you use a private header as a public header, of course yes. But that > is not what private explicitly means. > It _is_ indeed wrong to use a private header as a public header _even_ > for workarounds. > > HTH, > Manu Forget it. That is as wrong as older Fedora distros were shipping v4l2 apps like tvtime, but only providing v4l1 headers on the user level. If people would not have helped themselves out, all would be nice you seem to say ... I still pray, maybe it might happen soon ... Cheers, Hermann - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-dvb] Re: [video4linux-cvs] [hg:v4l-dvb] Add support for Opera S1- DVB-USB
Am Freitag, den 20.04.2007, 02:51 +0400 schrieb Manu Abraham: > Markus Rechberger wrote: > > On 4/20/07, Manu Abraham <[EMAIL PROTECTED]> wrote: > >> hermann pitton wrote: > >> > Am Freitag, den 20.04.2007, 00:55 +0400 schrieb Manu Abraham: > >> >> Mauro Carvalho Chehab wrote: > >> >>> Em Qui, 2007-04-19 às 16:41 -0400, Michael Krufky escreveu: > >> >>>> Marco Gittler wrote: > >> >>>>> this patch has applied the hints from mkrufky (dvb_attach, > >> >>>>> firmware-naming) > >> >>>>> and also one working rewrite of the i2c addresses stuff to fit the > >> >>>>> kernel i2c reqs. > >> >>>>> > >> >>>>> Signed-off-by: Marco Gittler<[EMAIL PROTECTED]> > >> >>>>> diff -r c8b73ec18b42 linux/drivers/media/dvb/dvb-usb/opera1.c > >> >>>>> --- a/linux/drivers/media/dvb/dvb-usb/opera1.cThu Apr 19 > >> 12:04:50 > >> 2007 -0300 > >> >>>>> +++ b/linux/drivers/media/dvb/dvb-usb/opera1.cThu Apr 19 > >> 20:38:01 > >> 2007 +0200 > >> >>>>> @@ -25,6 +25,13 @@ > >> >>>>> #define REG_20_SYMBOLRATE_BYTE1 0x20 > >> >>>>> #define REG_21_SYMBOLRATE_BYTE2 0x21 > >> >>>>> > >> >>>>> +#define ADDR_C0_TUNER (0xc0>>1) > >> >>>>> +#define ADDR_D0_PLL (0xd0>>1) > >> >>>>> > >> >>>> I don't like these two #define's. These i2c addresses need only be > >> >>>> specified once, in the config structs / frontendfoo_attach calls for > >> the > >> >>>> tuner / demod. > >> >>>> > >> >>>> Better to just put them in as constants like all of the other dvb > >> drivers. > >> >>> I prefer the way it is. We should really avoid having magic numbers > >> >>> inside the code. The alias here helps to know that 0x60 is tuner > >> addres > >> >>> and 0x68 the pll. > >> >> > >> >> Following a project's coding styles and conventions is "respecting" a > >> >> project > >> >> > >> >> Manu > >> >> > >> > > >> > Hi, > >> > > >> > the other natural place for this should be the LKML to get more _good_ > >> > arguments, instead of hanging soon in some "respect" stuff again. > >> > >> > >> DVB drivers generally have device addresses such as tuner_addresses and > >> demod_adresses defined in a config struct least to prevent them from > >> being global, wherever the header is included, since the very same > >> device can have multiple addresses and so on, which are non-probable > >> since being behind a repeater which is switched by a demod (private) and > >> hence. > >> > >> Those are some of the reasons to follow a certain coding > >> style/conventions. They are _not_ for fun. > >> > > > > cat *priv.h says something else too... > > there are also many global register defines in DVB drivers, they just > > don't include the register value in the define name. > > > *_priv.h from what i understand means private .. i don't know what you > make out from that. > > > HTH, > Manu ;) That means that I had to post the actual headers to every single tester on a distro kernel, and we got them only rarely on hybrid devices for several years and that for I always did it. Thanks again ;) Hermann - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-dvb] Re: [video4linux-cvs] [hg:v4l-dvb] Add support for Opera S1- DVB-USB
Am Freitag, den 20.04.2007, 00:55 +0400 schrieb Manu Abraham: > Mauro Carvalho Chehab wrote: > > Em Qui, 2007-04-19 às 16:41 -0400, Michael Krufky escreveu: > >> Marco Gittler wrote: > >>> this patch has applied the hints from mkrufky (dvb_attach, > >>> firmware-naming) > >>> and also one working rewrite of the i2c addresses stuff to fit the > >>> kernel i2c reqs. > >>> > >>> Signed-off-by: Marco Gittler<[EMAIL PROTECTED]> > >>> diff -r c8b73ec18b42 linux/drivers/media/dvb/dvb-usb/opera1.c > >>> --- a/linux/drivers/media/dvb/dvb-usb/opera1.cThu Apr 19 12:04:50 > >>> 2007 -0300 > >>> +++ b/linux/drivers/media/dvb/dvb-usb/opera1.cThu Apr 19 20:38:01 > >>> 2007 +0200 > >>> @@ -25,6 +25,13 @@ > >>> #define REG_20_SYMBOLRATE_BYTE1 0x20 > >>> #define REG_21_SYMBOLRATE_BYTE2 0x21 > >>> > >>> +#define ADDR_C0_TUNER (0xc0>>1) > >>> +#define ADDR_D0_PLL (0xd0>>1) > >>> > >> I don't like these two #define's. These i2c addresses need only be > >> specified once, in the config structs / frontendfoo_attach calls for the > >> tuner / demod. > >> > >> Better to just put them in as constants like all of the other dvb drivers. > > > > I prefer the way it is. We should really avoid having magic numbers > > inside the code. The alias here helps to know that 0x60 is tuner addres > > and 0x68 the pll. > > > Following a project's coding styles and conventions is "respecting" a > project > > Manu > Hi, the other natural place for this should be the LKML to get more _good_ arguments, instead of hanging soon in some "respect" stuff again. Cheers, Hermann - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-dvb] Re: [video4linux-cvs] [hg:v4l-dvb] Add support for Opera S1- DVB-USB
Am Freitag, den 20.04.2007, 00:55 +0400 schrieb Manu Abraham: Mauro Carvalho Chehab wrote: Em Qui, 2007-04-19 às 16:41 -0400, Michael Krufky escreveu: Marco Gittler wrote: this patch has applied the hints from mkrufky (dvb_attach, firmware-naming) and also one working rewrite of the i2c addresses stuff to fit the kernel i2c reqs. Signed-off-by: Marco Gittler[EMAIL PROTECTED] diff -r c8b73ec18b42 linux/drivers/media/dvb/dvb-usb/opera1.c --- a/linux/drivers/media/dvb/dvb-usb/opera1.cThu Apr 19 12:04:50 2007 -0300 +++ b/linux/drivers/media/dvb/dvb-usb/opera1.cThu Apr 19 20:38:01 2007 +0200 @@ -25,6 +25,13 @@ #define REG_20_SYMBOLRATE_BYTE1 0x20 #define REG_21_SYMBOLRATE_BYTE2 0x21 +#define ADDR_C0_TUNER (0xc01) +#define ADDR_D0_PLL (0xd01) I don't like these two #define's. These i2c addresses need only be specified once, in the config structs / frontendfoo_attach calls for the tuner / demod. Better to just put them in as constants like all of the other dvb drivers. I prefer the way it is. We should really avoid having magic numbers inside the code. The alias here helps to know that 0x60 is tuner addres and 0x68 the pll. Following a project's coding styles and conventions is respecting a project Manu Hi, the other natural place for this should be the LKML to get more _good_ arguments, instead of hanging soon in some respect stuff again. Cheers, Hermann - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-dvb] Re: [video4linux-cvs] [hg:v4l-dvb] Add support for Opera S1- DVB-USB
Am Freitag, den 20.04.2007, 02:51 +0400 schrieb Manu Abraham: Markus Rechberger wrote: On 4/20/07, Manu Abraham [EMAIL PROTECTED] wrote: hermann pitton wrote: Am Freitag, den 20.04.2007, 00:55 +0400 schrieb Manu Abraham: Mauro Carvalho Chehab wrote: Em Qui, 2007-04-19 às 16:41 -0400, Michael Krufky escreveu: Marco Gittler wrote: this patch has applied the hints from mkrufky (dvb_attach, firmware-naming) and also one working rewrite of the i2c addresses stuff to fit the kernel i2c reqs. Signed-off-by: Marco Gittler[EMAIL PROTECTED] diff -r c8b73ec18b42 linux/drivers/media/dvb/dvb-usb/opera1.c --- a/linux/drivers/media/dvb/dvb-usb/opera1.cThu Apr 19 12:04:50 2007 -0300 +++ b/linux/drivers/media/dvb/dvb-usb/opera1.cThu Apr 19 20:38:01 2007 +0200 @@ -25,6 +25,13 @@ #define REG_20_SYMBOLRATE_BYTE1 0x20 #define REG_21_SYMBOLRATE_BYTE2 0x21 +#define ADDR_C0_TUNER (0xc01) +#define ADDR_D0_PLL (0xd01) I don't like these two #define's. These i2c addresses need only be specified once, in the config structs / frontendfoo_attach calls for the tuner / demod. Better to just put them in as constants like all of the other dvb drivers. I prefer the way it is. We should really avoid having magic numbers inside the code. The alias here helps to know that 0x60 is tuner addres and 0x68 the pll. Following a project's coding styles and conventions is respecting a project Manu Hi, the other natural place for this should be the LKML to get more _good_ arguments, instead of hanging soon in some respect stuff again. DVB drivers generally have device addresses such as tuner_addresses and demod_adresses defined in a config struct least to prevent them from being global, wherever the header is included, since the very same device can have multiple addresses and so on, which are non-probable since being behind a repeater which is switched by a demod (private) and hence. Those are some of the reasons to follow a certain coding style/conventions. They are _not_ for fun. cat *priv.h says something else too... there are also many global register defines in DVB drivers, they just don't include the register value in the define name. *_priv.h from what i understand means private .. i don't know what you make out from that. HTH, Manu ;) That means that I had to post the actual headers to every single tester on a distro kernel, and we got them only rarely on hybrid devices for several years and that for I always did it. Thanks again ;) Hermann - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-dvb] Re: [video4linux-cvs] [hg:v4l-dvb] Add support for Opera S1- DVB-USB
Am Freitag, den 20.04.2007, 03:19 +0400 schrieb Manu Abraham: hermann pitton wrote: Am Freitag, den 20.04.2007, 02:51 +0400 schrieb Manu Abraham: Markus Rechberger wrote: On 4/20/07, Manu Abraham [EMAIL PROTECTED] wrote: hermann pitton wrote: Am Freitag, den 20.04.2007, 00:55 +0400 schrieb Manu Abraham: Mauro Carvalho Chehab wrote: Em Qui, 2007-04-19 às 16:41 -0400, Michael Krufky escreveu: Marco Gittler wrote: this patch has applied the hints from mkrufky (dvb_attach, firmware-naming) and also one working rewrite of the i2c addresses stuff to fit the kernel i2c reqs. Signed-off-by: Marco Gittler[EMAIL PROTECTED] diff -r c8b73ec18b42 linux/drivers/media/dvb/dvb-usb/opera1.c --- a/linux/drivers/media/dvb/dvb-usb/opera1.cThu Apr 19 12:04:50 2007 -0300 +++ b/linux/drivers/media/dvb/dvb-usb/opera1.cThu Apr 19 20:38:01 2007 +0200 @@ -25,6 +25,13 @@ #define REG_20_SYMBOLRATE_BYTE1 0x20 #define REG_21_SYMBOLRATE_BYTE2 0x21 +#define ADDR_C0_TUNER (0xc01) +#define ADDR_D0_PLL (0xd01) I don't like these two #define's. These i2c addresses need only be specified once, in the config structs / frontendfoo_attach calls for the tuner / demod. Better to just put them in as constants like all of the other dvb drivers. I prefer the way it is. We should really avoid having magic numbers inside the code. The alias here helps to know that 0x60 is tuner addres and 0x68 the pll. Following a project's coding styles and conventions is respecting a project Manu Hi, the other natural place for this should be the LKML to get more _good_ arguments, instead of hanging soon in some respect stuff again. DVB drivers generally have device addresses such as tuner_addresses and demod_adresses defined in a config struct least to prevent them from being global, wherever the header is included, since the very same device can have multiple addresses and so on, which are non-probable since being behind a repeater which is switched by a demod (private) and hence. Those are some of the reasons to follow a certain coding style/conventions. They are _not_ for fun. cat *priv.h says something else too... there are also many global register defines in DVB drivers, they just don't include the register value in the define name. *_priv.h from what i understand means private .. i don't know what you make out from that. HTH, Manu ;) That means that I had to post the actual headers to every single tester If you use a private header as a public header, of course yes. But that is not what private explicitly means. It _is_ indeed wrong to use a private header as a public header _even_ for workarounds. HTH, Manu Forget it. That is as wrong as older Fedora distros were shipping v4l2 apps like tvtime, but only providing v4l1 headers on the user level. If people would not have helped themselves out, all would be nice you seem to say ... I still pray, maybe it might happen soon ... Cheers, Hermann - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-dvb] Re: [video4linux-cvs] [hg:v4l-dvb] Add support for Opera S1- DVB-USB
Am Freitag, den 20.04.2007, 03:42 +0400 schrieb Manu Abraham: hermann pitton wrote: Am Freitag, den 20.04.2007, 03:19 +0400 schrieb Manu Abraham: hermann pitton wrote: Am Freitag, den 20.04.2007, 02:51 +0400 schrieb Manu Abraham: Markus Rechberger wrote: On 4/20/07, Manu Abraham [EMAIL PROTECTED] wrote: hermann pitton wrote: Am Freitag, den 20.04.2007, 00:55 +0400 schrieb Manu Abraham: Mauro Carvalho Chehab wrote: Em Qui, 2007-04-19 às 16:41 -0400, Michael Krufky escreveu: Marco Gittler wrote: this patch has applied the hints from mkrufky (dvb_attach, firmware-naming) and also one working rewrite of the i2c addresses stuff to fit the kernel i2c reqs. Signed-off-by: Marco Gittler[EMAIL PROTECTED] diff -r c8b73ec18b42 linux/drivers/media/dvb/dvb-usb/opera1.c --- a/linux/drivers/media/dvb/dvb-usb/opera1.cThu Apr 19 12:04:50 2007 -0300 +++ b/linux/drivers/media/dvb/dvb-usb/opera1.cThu Apr 19 20:38:01 2007 +0200 @@ -25,6 +25,13 @@ #define REG_20_SYMBOLRATE_BYTE1 0x20 #define REG_21_SYMBOLRATE_BYTE2 0x21 +#define ADDR_C0_TUNER (0xc01) +#define ADDR_D0_PLL (0xd01) I don't like these two #define's. These i2c addresses need only be specified once, in the config structs / frontendfoo_attach calls for the tuner / demod. Better to just put them in as constants like all of the other dvb drivers. I prefer the way it is. We should really avoid having magic numbers inside the code. The alias here helps to know that 0x60 is tuner addres and 0x68 the pll. Following a project's coding styles and conventions is respecting a project Manu Hi, the other natural place for this should be the LKML to get more _good_ arguments, instead of hanging soon in some respect stuff again. DVB drivers generally have device addresses such as tuner_addresses and demod_adresses defined in a config struct least to prevent them from being global, wherever the header is included, since the very same device can have multiple addresses and so on, which are non-probable since being behind a repeater which is switched by a demod (private) and hence. Those are some of the reasons to follow a certain coding style/conventions. They are _not_ for fun. cat *priv.h says something else too... there are also many global register defines in DVB drivers, they just don't include the register value in the define name. *_priv.h from what i understand means private .. i don't know what you make out from that. HTH, Manu ;) That means that I had to post the actual headers to every single tester If you use a private header as a public header, of course yes. But that is not what private explicitly means. It _is_ indeed wrong to use a private header as a public header _even_ for workarounds. HTH, Manu Forget it. That is as wrong as older Fedora distros were shipping v4l2 apps like tvtime, but only providing v4l1 headers on the user level. I don't know about Fedora shipping v4l2 apps. Forgive my ignorance. But it is really hopeless to include a private header for a device into another device. Anyway not talking about V4L1/2/n headers, but about DVB device (demod/tuner) private headers being included publicly. Private means private, i don't understand how the notion comes around that a private header is a public header. It is _not_ named private for no reason. The GPL was also not named GPL for no reason. HTH, Hermann - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [v4l-dvb-maintainer] [GIT PATCHES] V4L/DVB updates
Am Montag, den 16.04.2007, 12:25 -0400 schrieb Michael Krufky: > CIJOML wrote: > > Dne pondělí 16 duben 2007 17:34 Michael Krufky napsal(a): > > > >> Adrian Bunk wrote: > >> > >>> On Sun, Apr 15, 2007 at 08:33:38PM -0400, Michael Krufky wrote: > >>> > Mauro, > > I've been out of town for the past few days... I just got home and saw > this: > > Mauro Carvalho Chehab wrote: > > >- Fix 1/3 for bug 7819: fixed frontend hotplug issue > >- Fix 2/3 for bug 7819: demux and dvr > >- Fix 3/3 for bug 7819: fixed hotplugging for dvbnet > > > I don't think that this is 2.6.21 material. These patches have not yet > received > enough testing to be sent to mainline. > > I have tested them, and they seem to work for my cxusb device, but we > have yet to hear test results from users of usb dvb devices that do not > use the dvb-usb framework. (ttusb, flexcop-usb, cinergyT2, for example) > > The bug that these patches fix has been around throughout the entire > kernel history of the dvb subsystem. The bug is not a regression -- it > has always been > there. In my opinion, it is too late in 2.6.21 development to apply > this change. > Because these fixes are not obvious, I think we should let them get some > more testing, and have them queued for 2.6.22 . > > >>> Unless I misunderstand anything, this should fix [1]. > >>> > >>> And this is a bug that was reported to be present in 2.6.21-rc but not > >>> in 2.6.20 (and it's therefore a regression, no matter whether the > >>> underlying problem was older and only exposed by some other change). > >>> > >> Not true. The DVB subsystem has NEVER been hot-unpluggable. I confirm > >> that the patches SEEM to be correct, but this has not yet been verified. > >> None of the authors of dvb-core gave their ACK on these changesets. > >> > >> The DVB hotplug issue has been around since the very beginning. I assure > >> you, that I consider this fix to be very important, and I really would love > >> to see it hit mainline. However, given the situation, it is not > >> appropriate to push these in during -rc7 > >> > >> I have doubts on CIJOML's testing method -- there is no way he could have > >> unplugged the device while in use, while running 2.6.20.y and not receive > >> an OOPS. CIJOML, please see the bottom of this email for > >> > >> Sure, this will prevent an OOPS on some, and hopefully all devices... but > >> what if it causes a regression for those untested? > >> > >> Why do we have a merge window, if new changesets are going to be rushed > >> into late -rc kernels without proper testing, and without the ack of a dvb > >> subsystem maintainer? > >> > >> Are we prepared to go for another -rc and 3 or 4 weeks of testing to > >> confirm that this fix doesn't cause new regressions? I don't think so. > >> > >> Markus Rechberger wrote: > >> > >>> The patch has been around on the dvb mailinglist ([PATCH][RFC] DVB > >>> Hotplug Fix, 5. April 2007), > >>> > >> The patch was merged into the development repository at the same time the > >> pull request was issued to Linus. This has NOT been tested on a wide > >> scale. It should go to -mm for a while before being merged to mainline. > >> > >> Mauro Carvalho Chehab wrote: > >> > >>> I also explicitly warned at DVB ML that I were about to send this patch, > >>> together with other fixes, asking the community for more tests. After > >>> that, I received two positive answers on my mailbox from people that > >>> tested and noticed that this really fixed the issue. > >>> > >> One of those positive answers was me - I explained that it worked for me, > >> but we need others to test. > >> > >> You waited ONE DAY after sending this "warning" to the dvb mailing list? ( > >> http://linuxtv.org/pipermail/linux-dvb/2007-April/017204.html ) I saw that > >> email after seeing the pull request to Linus. We dont have users testing > >> the repositories after each commit -- you _really_ need to give some more > >> time to allow for such testing. > >> > >> CIJOML wrote: > >> > >>> Hi, > >>> > >>> I have tested these patches with: > >>> > >>> Freecom DVB-T dongle > >>> Pluto2 pcmcia card > >>> Leadtek WinFast DTV dongle 1st generation > >>> Leadtek WinFast DTV dongle 2nd generation > >>> > >>> These are 4 different devices with 4 different hw and modules. > >>> All works. Please apply. > >>> > >> Well, that helps... But it would still be nice to hear test results on a > >> CinergyT2 or flexcop-usb. > >> > >> Which driver supports those Winfast dongles? We already know for sure that > >> the patches work correctly for any driver based on the dvb-usb framework. > >> > >> If you had the device open, and then disconnect it from the usb bus, no > >> matter what kernel version you're running, you should hit the OOPS. I > >>
Re: [v4l-dvb-maintainer] [GIT PATCHES] V4L/DVB updates
Am Montag, den 16.04.2007, 12:25 -0400 schrieb Michael Krufky: CIJOML wrote: Dne pondělí 16 duben 2007 17:34 Michael Krufky napsal(a): Adrian Bunk wrote: On Sun, Apr 15, 2007 at 08:33:38PM -0400, Michael Krufky wrote: Mauro, I've been out of town for the past few days... I just got home and saw this: Mauro Carvalho Chehab wrote: - Fix 1/3 for bug 7819: fixed frontend hotplug issue - Fix 2/3 for bug 7819: demux and dvr - Fix 3/3 for bug 7819: fixed hotplugging for dvbnet I don't think that this is 2.6.21 material. These patches have not yet received enough testing to be sent to mainline. I have tested them, and they seem to work for my cxusb device, but we have yet to hear test results from users of usb dvb devices that do not use the dvb-usb framework. (ttusb, flexcop-usb, cinergyT2, for example) The bug that these patches fix has been around throughout the entire kernel history of the dvb subsystem. The bug is not a regression -- it has always been there. In my opinion, it is too late in 2.6.21 development to apply this change. Because these fixes are not obvious, I think we should let them get some more testing, and have them queued for 2.6.22 . Unless I misunderstand anything, this should fix [1]. And this is a bug that was reported to be present in 2.6.21-rc but not in 2.6.20 (and it's therefore a regression, no matter whether the underlying problem was older and only exposed by some other change). Not true. The DVB subsystem has NEVER been hot-unpluggable. I confirm that the patches SEEM to be correct, but this has not yet been verified. None of the authors of dvb-core gave their ACK on these changesets. The DVB hotplug issue has been around since the very beginning. I assure you, that I consider this fix to be very important, and I really would love to see it hit mainline. However, given the situation, it is not appropriate to push these in during -rc7 I have doubts on CIJOML's testing method -- there is no way he could have unplugged the device while in use, while running 2.6.20.y and not receive an OOPS. CIJOML, please see the bottom of this email for Sure, this will prevent an OOPS on some, and hopefully all devices... but what if it causes a regression for those untested? Why do we have a merge window, if new changesets are going to be rushed into late -rc kernels without proper testing, and without the ack of a dvb subsystem maintainer? Are we prepared to go for another -rc and 3 or 4 weeks of testing to confirm that this fix doesn't cause new regressions? I don't think so. Markus Rechberger wrote: The patch has been around on the dvb mailinglist ([PATCH][RFC] DVB Hotplug Fix, 5. April 2007), The patch was merged into the development repository at the same time the pull request was issued to Linus. This has NOT been tested on a wide scale. It should go to -mm for a while before being merged to mainline. Mauro Carvalho Chehab wrote: I also explicitly warned at DVB ML that I were about to send this patch, together with other fixes, asking the community for more tests. After that, I received two positive answers on my mailbox from people that tested and noticed that this really fixed the issue. One of those positive answers was me - I explained that it worked for me, but we need others to test. You waited ONE DAY after sending this warning to the dvb mailing list? ( http://linuxtv.org/pipermail/linux-dvb/2007-April/017204.html ) I saw that email after seeing the pull request to Linus. We dont have users testing the repositories after each commit -- you _really_ need to give some more time to allow for such testing. CIJOML wrote: Hi, I have tested these patches with: Freecom DVB-T dongle Pluto2 pcmcia card Leadtek WinFast DTV dongle 1st generation Leadtek WinFast DTV dongle 2nd generation These are 4 different devices with 4 different hw and modules. All works. Please apply. Well, that helps... But it would still be nice to hear test results on a CinergyT2 or flexcop-usb. Which driver supports those Winfast dongles? We already know for sure that the patches work correctly for any driver based on the dvb-usb framework. If you had the device open, and then disconnect it from the usb bus, no matter what kernel version you're running, you should hit the OOPS. I confirm that these patches prevent that OOPS from occurring, but I have trouble believing that you did NOT experience such an OOPS in 2.6.20.y Could you please describe the method in which your test caused an OOPS using 2.6.21-rc and did NOT cause an oops in 2.6.20.y ? Hi, I have tested these patches with 2.6.20-mh1 + v4l-dvb-b5be3479f070 patchset. I also tried 2.6.21-rc6 +
Re: [patch] Fix bttv and friends on 64bit machines with lots of memory.
Am Freitag, den 12.01.2007, 22:42 -0200 schrieb Mauro Carvalho Chehab: > Em Qui, 2007-01-11 às 00:41 +0100, hermann pitton escreveu: > > Am Mittwoch, den 10.01.2007, 09:58 +0100 schrieb Gerd Hoffmann: > > > Hi, > > > > > > We have a DMA32 zone now, lets use it to make sure the card > > > can reach the memory we have allocated for the video frame > > > buffers. > > > > > > please apply, > > > > > > Gerd > > > > Hi, > > > > did anybody already pick up, comment, review Gerd's patch ? > > > > Walks in into his own home like a stranger ... > > > > Gerd, THANKS for all you did. > > It was a incredible lot! > > Hermann, > > I just picked it today. I was out this week due to a physical damage at > the hd on my notebook, were my mailboxes are retrieved. Only today I > have it on a stable condition to return back to activities, successfully > recovering my /home on it. Mauro, Gerd, sorry to be a pain with this one, just thought it could be a missing each other. Our maintainers don't need to excuse for anything! Adrian and all, thanks for fixing the remaining bugs. Cheers, Hermann - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] Fix bttv and friends on 64bit machines with lots of memory.
Am Freitag, den 12.01.2007, 22:42 -0200 schrieb Mauro Carvalho Chehab: Em Qui, 2007-01-11 às 00:41 +0100, hermann pitton escreveu: Am Mittwoch, den 10.01.2007, 09:58 +0100 schrieb Gerd Hoffmann: Hi, We have a DMA32 zone now, lets use it to make sure the card can reach the memory we have allocated for the video frame buffers. please apply, Gerd Hi, did anybody already pick up, comment, review Gerd's patch ? Walks in into his own home like a stranger ... Gerd, THANKS for all you did. It was a incredible lot! Hermann, I just picked it today. I was out this week due to a physical damage at the hd on my notebook, were my mailboxes are retrieved. Only today I have it on a stable condition to return back to activities, successfully recovering my /home on it. Mauro, Gerd, sorry to be a pain with this one, just thought it could be a missing each other. Our maintainers don't need to excuse for anything! Adrian and all, thanks for fixing the remaining bugs. Cheers, Hermann - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] Fix bttv and friends on 64bit machines with lots of memory.
Am Mittwoch, den 10.01.2007, 09:58 +0100 schrieb Gerd Hoffmann: > Hi, > > We have a DMA32 zone now, lets use it to make sure the card > can reach the memory we have allocated for the video frame > buffers. > > please apply, > > Gerd Hi, did anybody already pick up, comment, review Gerd's patch ? Walks in into his own home like a stranger ... Gerd, THANKS for all you did. It was a incredible lot! Hermann > einfaches Textdokument-Anlage (v4l-dma32) > Fix bttv and friends on 64bit machines with lots of memory. > > We have a DMA32 zone now, lets use it to make sure the card > can reach the memory we have allocated for the video frame > buffers. > > Signed-off-by: Gerds Hoffmann <[EMAIL PROTECTED]> > --- > drivers/media/video/video-buf.c |2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > Index: linux-2.6.18/drivers/media/video/video-buf.c > === > --- linux-2.6.18.orig/drivers/media/video/video-buf.c > +++ linux-2.6.18/drivers/media/video/video-buf.c > @@ -1224,7 +1224,7 @@ videobuf_vm_nopage(struct vm_area_struct > vaddr,vma->vm_start,vma->vm_end); > if (vaddr > vma->vm_end) > return NOPAGE_SIGBUS; > - page = alloc_page(GFP_USER); > + page = alloc_page(GFP_USER | __GFP_DMA32); > if (!page) > return NOPAGE_OOM; > clear_user_page(page_address(page), vaddr, page); - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] Fix bttv and friends on 64bit machines with lots of memory.
Am Mittwoch, den 10.01.2007, 09:58 +0100 schrieb Gerd Hoffmann: Hi, We have a DMA32 zone now, lets use it to make sure the card can reach the memory we have allocated for the video frame buffers. please apply, Gerd Hi, did anybody already pick up, comment, review Gerd's patch ? Walks in into his own home like a stranger ... Gerd, THANKS for all you did. It was a incredible lot! Hermann einfaches Textdokument-Anlage (v4l-dma32) Fix bttv and friends on 64bit machines with lots of memory. We have a DMA32 zone now, lets use it to make sure the card can reach the memory we have allocated for the video frame buffers. Signed-off-by: Gerds Hoffmann [EMAIL PROTECTED] --- drivers/media/video/video-buf.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) Index: linux-2.6.18/drivers/media/video/video-buf.c === --- linux-2.6.18.orig/drivers/media/video/video-buf.c +++ linux-2.6.18/drivers/media/video/video-buf.c @@ -1224,7 +1224,7 @@ videobuf_vm_nopage(struct vm_area_struct vaddr,vma-vm_start,vma-vm_end); if (vaddr vma-vm_end) return NOPAGE_SIGBUS; - page = alloc_page(GFP_USER); + page = alloc_page(GFP_USER | __GFP_DMA32); if (!page) return NOPAGE_OOM; clear_user_page(page_address(page), vaddr, page); - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 01/24] V4L: Common part Updates and tuner additions
Am Dienstag, den 06.09.2005, 17:01 -0700 schrieb Andrew Morton: > Two of these patches: > > v4l-adds-the-adapter-number-and-i2c-address-to.patch > v4l-allows-clearer-message-prefixes-containing-the-i2c-for-tveeprom_hauppauge_analog.patch > > throw great reject storms, due to changes in Linus's current tree. Greg's > i2c stuff. > > I'm not confident that the v4l changes will work without those two patches > and I'm not confident that they'll work against all the i2c changes, so > could you please redo all these patches against current -linus or most > recent -mm, retest and resend? > > Thanks. Hi, I'm very confident that all other patches should work without these two, if not, it is not related to this two patches, but right, let's check more carefully and if necessary resend. Greetings, Hermann - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 01/24] V4L: Common part Updates and tuner additions
Am Dienstag, den 06.09.2005, 17:01 -0700 schrieb Andrew Morton: Two of these patches: v4l-adds-the-adapter-number-and-i2c-address-to.patch v4l-allows-clearer-message-prefixes-containing-the-i2c-for-tveeprom_hauppauge_analog.patch throw great reject storms, due to changes in Linus's current tree. Greg's i2c stuff. I'm not confident that the v4l changes will work without those two patches and I'm not confident that they'll work against all the i2c changes, so could you please redo all these patches against current -linus or most recent -mm, retest and resend? Thanks. Hi, I'm very confident that all other patches should work without these two, if not, it is not related to this two patches, but right, let's check more carefully and if necessary resend. Greetings, Hermann - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2 errors in 2.6.12
Hello, this one is solved. Guess we will see similar issues more often for a while. Cheers, Hermann Am Montag, den 01.08.2005, 20:11 +0200 schrieb CIJOML: > > On Mon, 1 Aug 2005, hermann pitton wrote: > > > Am Montag, den 01.08.2005, 11:16 +0200 schrieb CIJOML: > > > Hi, > > > > > > my card is impossible to be autodetected. Valid sections for it's > > > identification are missing. > > > > > > I asked for this some time ago. I need to use insmod option. > > > > > > Michal > > > > Hi Michal, > > > > the "tuner type=N" insmod option is gone away. > > > > There has been a warning that it is deprecated for about 1 1/2 years > > in dmesg. Please remove it from /etc/modprobe.conf or where else it is > > called and replace it with "options bttv card=N tuner=N", guess you > > H This helped!!! Thanks a lot > after options bttv card=42 radio=1 tuner=1 > card works! :) > > Linux video capture interface: v1.00 > bttv: driver version 0.9.15 loaded > bttv: using 8 buffers with 2080k (520 pages) each for capture > bttv: Bt8xx card found (0). > ACPI: PCI Interrupt :01:0b.0[A] -> Link [LNKH] -> GSI 9 (level, low) > -> IRQ 9 > bttv0: Bt878 (rev 17) at :01:0b.0, irq: 9, latency: 32, mmio: > 0xb69fe000 > bttv0: using: ProVideo PV951 [card=42,insmod option] > bttv0: gpio: en=, out= in=00ff [init] > bttv0: using tuner=1 > bttv0: i2c: checking for TDA9875 @ 0xb0... not found > bttv0: i2c: checking for TDA7432 @ 0x8a... not found > tvaudio: TV audio decoder + audio/video mux driver > tvaudio: known chips: > tda9840,tda9873h,tda9874h/a,tda9850,tda9855,tea6300,tea6320,tea6420,tda8425,pic16c54 > (PV951),ta8874z > tvaudio: found pic16c54 (PV951) @ 0x96 > bttv0: i2c: checking for TDA9887 @ 0x86... not found > : chip found @ 0xc0 (bt878 #0 [sw]) > : All bytes are equal. It is not a TEA5767 > tuner 0-0060: type set to 1 (Philips PAL_I (FI1246 and compatibles)) > bttv0: registered device video0 > bttv0: registered device vbi0 > bttv0: registered device radio0 > bttv0: PLL: 28636363 => 35468950 .. ok > > Thanks a lot! > > Michal > > > > might use tuner=5, and what else you might need and then "depmod -a". > > Does this help? > > > > Greetings, > > Hermann > > > > > > > On Sun, 31 Jul 2005, Michael Krufky wrote: > > > > > > > Andrew Morton wrote: > > > > > > > > >Michal Semler <[EMAIL PROTECTED]> wrote: > > > > > > > > > > > > > > >> This is what I gets into dmesg: > > > > >> > > > > >> Linux video capture interface: v1.00 > > > > >> bttv: driver version 0.9.15 loaded > > > > >> bttv: using 8 buffers with 2080k (520 pages) each for capture > > > > >> bttv: Bt8xx card found (0). > > > > >> ACPI: PCI Interrupt :01:0b.0[A] -> Link [LNKH] -> GSI 9 (level, > > > > >> low) -> > > > > >> IRQ 9 > > > > >> bttv0: Bt878 (rev 17) at :01:0b.0, irq: 9, latency: 32, mmio: > > > > >> 0xb69fe000 > > > > >> bttv0: using: ProVideo PV951 [card=42,insmod option] > > > > >> bttv0: gpio: en=, out= in=00ff [init] > > > > >> bttv0: using tuner=1 > > > > >> bttv0: i2c: checking for TDA9875 @ 0xb0... not found > > > > >> bttv0: i2c: checking for TDA7432 @ 0x8a... not found > > > > >> tvaudio: TV audio decoder + audio/video mux driver > > > > >> tvaudio: known chips: > > > > >> tda9840,tda9873h,tda9874h/a,tda9850,tda9855,tea6300,tea6320,tea6420,tda8425,pic16c54 > > > > >> (PV951),ta8874z > > > > >> tvaudio: found pic16c54 (PV951) @ 0x96 > > > > >> bttv0: i2c: checking for TDA9887 @ 0x86... not found > > > > >> tuner: Unknown parameter `type' > > [...] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2 errors in 2.6.12
Hello, this one is solved. Guess we will see similar issues more often for a while. Cheers, Hermann Am Montag, den 01.08.2005, 20:11 +0200 schrieb CIJOML: On Mon, 1 Aug 2005, hermann pitton wrote: Am Montag, den 01.08.2005, 11:16 +0200 schrieb CIJOML: Hi, my card is impossible to be autodetected. Valid sections for it's identification are missing. I asked for this some time ago. I need to use insmod option. Michal Hi Michal, the tuner type=N insmod option is gone away. There has been a warning that it is deprecated for about 1 1/2 years in dmesg. Please remove it from /etc/modprobe.conf or where else it is called and replace it with options bttv card=N tuner=N, guess you H This helped!!! Thanks a lot after options bttv card=42 radio=1 tuner=1 card works! :) Linux video capture interface: v1.00 bttv: driver version 0.9.15 loaded bttv: using 8 buffers with 2080k (520 pages) each for capture bttv: Bt8xx card found (0). ACPI: PCI Interrupt :01:0b.0[A] - Link [LNKH] - GSI 9 (level, low) - IRQ 9 bttv0: Bt878 (rev 17) at :01:0b.0, irq: 9, latency: 32, mmio: 0xb69fe000 bttv0: using: ProVideo PV951 [card=42,insmod option] bttv0: gpio: en=, out= in=00ff [init] bttv0: using tuner=1 bttv0: i2c: checking for TDA9875 @ 0xb0... not found bttv0: i2c: checking for TDA7432 @ 0x8a... not found tvaudio: TV audio decoder + audio/video mux driver tvaudio: known chips: tda9840,tda9873h,tda9874h/a,tda9850,tda9855,tea6300,tea6320,tea6420,tda8425,pic16c54 (PV951),ta8874z tvaudio: found pic16c54 (PV951) @ 0x96 bttv0: i2c: checking for TDA9887 @ 0x86... not found : chip found @ 0xc0 (bt878 #0 [sw]) : All bytes are equal. It is not a TEA5767 tuner 0-0060: type set to 1 (Philips PAL_I (FI1246 and compatibles)) bttv0: registered device video0 bttv0: registered device vbi0 bttv0: registered device radio0 bttv0: PLL: 28636363 = 35468950 .. ok Thanks a lot! Michal might use tuner=5, and what else you might need and then depmod -a. Does this help? Greetings, Hermann On Sun, 31 Jul 2005, Michael Krufky wrote: Andrew Morton wrote: Michal Semler [EMAIL PROTECTED] wrote: This is what I gets into dmesg: Linux video capture interface: v1.00 bttv: driver version 0.9.15 loaded bttv: using 8 buffers with 2080k (520 pages) each for capture bttv: Bt8xx card found (0). ACPI: PCI Interrupt :01:0b.0[A] - Link [LNKH] - GSI 9 (level, low) - IRQ 9 bttv0: Bt878 (rev 17) at :01:0b.0, irq: 9, latency: 32, mmio: 0xb69fe000 bttv0: using: ProVideo PV951 [card=42,insmod option] bttv0: gpio: en=, out= in=00ff [init] bttv0: using tuner=1 bttv0: i2c: checking for TDA9875 @ 0xb0... not found bttv0: i2c: checking for TDA7432 @ 0x8a... not found tvaudio: TV audio decoder + audio/video mux driver tvaudio: known chips: tda9840,tda9873h,tda9874h/a,tda9850,tda9855,tea6300,tea6320,tea6420,tda8425,pic16c54 (PV951),ta8874z tvaudio: found pic16c54 (PV951) @ 0x96 bttv0: i2c: checking for TDA9887 @ 0x86... not found tuner: Unknown parameter `type' [...] - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
