Re: Questions about IOMMU & PCIe switch
On Thu, Jan 8, 2015 at 8:35 PM, Raimonds Cicans wrote: > On 08.01.2015 10:34, Clemens Ladisch wrote: >> >> Raimonds Cicans wrote: >>> >>> https://github.com/ljalves/linux_media/issues/66 >> >> If the TBS driver works, why don't you use it? > > 1) driver is not stable in 24x7 setups > > 2) driver use old DVBAPI. This cause problems with some > user space programs. It shouldn't. It is backward compatible. > > 3) TBS recommends to use card in MSI interrupt mode > but this mode on IOMMU systems do not work: > card is able to find transponders and tune to it > but can not receive any data TBS didn't even have the courtesy to say thanks, but still. They don't have any clue on the driver. You shouldn't use MSI mode on most systems unless you are sure that your machine works perfectly well with MSI mode. You should simply use standard interrupt mode, if you are unsure. In any sense, that card looks a bit odd: 1. It doesn't need a PCIe switch, nor that CPLD in there for the fact that it is using a SAA7160, rather than an E version, which thereby support 4 FGPI inputs (4 simultaneous TS's) (Redundant components) 2. But in any sense, the PCIe switch is transparent, It doesn't need any programming. All what you can do with the PCIe switch is to reprogram the lines to it, nothing more. In any case, if your card is detected, there's no point in playing with the PCIe switch 3. The TS failure in a while can most likely be attributed to bad CPLD programming. On the cards that I have worked with, they've worked pretty well. Regards, Manu -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL for v3.11] media patches for v3.11
On Mon, Jul 1, 2013 at 11:12 PM, Mauro Carvalho Chehab wrote: > Em Mon, 1 Jul 2013 21:17:58 +0530 > Manu Abraham escreveu: > >> On Mon, Jul 1, 2013 at 9:05 PM, Mauro Carvalho Chehab >> wrote: >> > Em Mon, 1 Jul 2013 16:37:58 +0530 >> > Manu Abraham escreveu: >> > >> >> Mauro, >> >> >> >> On Mon, Jul 1, 2013 at 4:28 PM, Mauro Carvalho Chehab >> >> wrote: >> >> > Hi Linus, >> >> > >> >> > Please pull from: >> >> > git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media >> >> > v4l_for_linus >> >> > >> >> > For the media patches for Kernel v3.11. >> >> > >> >> >> >> > >> >> > Zoran Turalija (2): >> >> > [media] stb0899: allow minimum symbol rate of 100 >> >> > [media] stb0899: allow minimum symbol rate of 200 >> >> >> >> >> >> Somehow, I missed these patches; These are incorrect. Please revert >> >> these changes. >> >> Simply changing the advertized minima values don't change the search >> >> algorithm >> >> behaviour, it simply leads to broken behaviour. >> >> >> >> NACK for these changes. >> > >> > While this patch came from a sub-maintainer's tree, looking at its >> > history, the patch was proposed here: >> > https://linuxtv.org/patch/18341/ >> > >> >> >> Wherever it came from, the patch is incorrect. Anyone can throw in >> any patch as they want. >> >> >> > From what it is said there, with this patch, 6 additional channels >> > were discovered when using with Eutelsat 16A, that uses a symbol >> > rate between 2MS/s to 5 MS/s. Without this patch, those channels won't >> > be discovered, as the core won't try to use a symbol rate outside >> > the range. >> >> What you are stating is a hit and miss scenario, sometimes it might lock >> and sometimes it wouldn't. > > Well, before this change, it was a full miss scenario, as it will > never lock on low symbol rate channels. > >> The scanning algorithm that I implemented for the demodulator works >> with a symbol rate as low as 5 MSPS alone. Anything lower than that >> is hit and miss. > > Ok, so latter patches need to improve the algorithm to improve it > for lower symbol rates. By getting feedback about this patch, we'll > know more about how bad is the current algorithm, as people may now > report and work on improve it. > >> > Of course, transponders with a symbol rate equal or upper than 5MS/s >> > won't be affected by this patch. >> > >> >> >> How can you be sure ? I myself am not very sure. While we worked on >> the demodulator in the early days, we had different situations where a >> previous failed state could cause lockup of the demodulator, eventually >> resulting tuning failures. > > If that happens, that would be a firmware or hardware issue. > As I said before, ST can provide us an answer if the hardware has > such bug. > >> > Even if this is not a perfect patch and some changes would be >> > needed to improve tuning for those low symbol rate transponders, >> > it seems better than before, as at least now some channels are tuned. >> > >> > The only reason I can see to reverse this patch is that if setting >> > the frontend to low bit ranges could damage the frontend or could >> > hit some bug on the hardware (or internal firmware). >> > >> > Yet, from the datasheet pointed by the patch author, it seems that >> > this frontend allows such low symbol rates: >> > http://comtech.sg1002.myweb.hinet.net/pdf/dvbs2-6899.pdf >> >> >> The frontend allows a different lower symbol rate with a different >> scanning algorithm, not with this existing current one. >> >> I am pretty sure, that author saw some specifications written some >> place and simply copied those numbers in here. Also sure that he >> has no idea about the algorithm in use. >> >> According to ST itself, a 2MSPS algorithm was created for a very >> specific customer requirement, which is not applicable to the existing >> algorithm in use with the Linux STB0899 demodulator driver. > > Ok, so let's wait for ST to provide us some feedback on this public > thread, in order to be sure that we need to reverse it because of > some hardware bug, or to get an improved algorithm that will better > work with low symbol rates. I don't think anyone is going to spend enough time to answer your stupid comments. As being the author of this driver, and the person who added support for cards based on the chipset: NACK Linus, I NACK the patches for the said reasons. Regards, Manu Regards, Manu -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL for v3.11] media patches for v3.11
On Mon, Jul 1, 2013 at 9:05 PM, Mauro Carvalho Chehab wrote: > Em Mon, 1 Jul 2013 16:37:58 +0530 > Manu Abraham escreveu: > >> Mauro, >> >> On Mon, Jul 1, 2013 at 4:28 PM, Mauro Carvalho Chehab >> wrote: >> > Hi Linus, >> > >> > Please pull from: >> > git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media >> > v4l_for_linus >> > >> > For the media patches for Kernel v3.11. >> > >> >> > >> > Zoran Turalija (2): >> > [media] stb0899: allow minimum symbol rate of 100 >> > [media] stb0899: allow minimum symbol rate of 200 >> >> >> Somehow, I missed these patches; These are incorrect. Please revert >> these changes. >> Simply changing the advertized minima values don't change the search >> algorithm >> behaviour, it simply leads to broken behaviour. >> >> NACK for these changes. > > While this patch came from a sub-maintainer's tree, looking at its > history, the patch was proposed here: > https://linuxtv.org/patch/18341/ > Wherever it came from, the patch is incorrect. Anyone can throw in any patch as they want. > From what it is said there, with this patch, 6 additional channels > were discovered when using with Eutelsat 16A, that uses a symbol > rate between 2MS/s to 5 MS/s. Without this patch, those channels won't > be discovered, as the core won't try to use a symbol rate outside > the range. What you are stating is a hit and miss scenario, sometimes it might lock and sometimes it wouldn't. The scanning algorithm that I implemented for the demodulator works with a symbol rate as low as 5 MSPS alone. Anything lower than that is hit and miss. > Of course, transponders with a symbol rate equal or upper than 5MS/s > won't be affected by this patch. > How can you be sure ? I myself am not very sure. While we worked on the demodulator in the early days, we had different situations where a previous failed state could cause lockup of the demodulator, eventually resulting tuning failures. > Even if this is not a perfect patch and some changes would be > needed to improve tuning for those low symbol rate transponders, > it seems better than before, as at least now some channels are tuned. > > The only reason I can see to reverse this patch is that if setting > the frontend to low bit ranges could damage the frontend or could > hit some bug on the hardware (or internal firmware). > > Yet, from the datasheet pointed by the patch author, it seems that > this frontend allows such low symbol rates: > http://comtech.sg1002.myweb.hinet.net/pdf/dvbs2-6899.pdf The frontend allows a different lower symbol rate with a different scanning algorithm, not with this existing current one. I am pretty sure, that author saw some specifications written some place and simply copied those numbers in here. Also sure that he has no idea about the algorithm in use. According to ST itself, a 2MSPS algorithm was created for a very specific customer requirement, which is not applicable to the existing algorithm in use with the Linux STB0899 demodulator driver. Regards, Manu -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL for v3.11] media patches for v3.11
Mauro, On Mon, Jul 1, 2013 at 4:28 PM, Mauro Carvalho Chehab wrote: > Hi Linus, > > Please pull from: > git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media > v4l_for_linus > > For the media patches for Kernel v3.11. > > > Zoran Turalija (2): > [media] stb0899: allow minimum symbol rate of 100 > [media] stb0899: allow minimum symbol rate of 200 Somehow, I missed these patches; These are incorrect. Please revert these changes. Simply changing the advertized minima values don't change the search algorithm behaviour, it simply leads to broken behaviour. NACK for these changes. Regards, Manu -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] [media] stv090x: do not unlock unheld mutex in stv090x_sleep()
Hi, On Wed, Feb 20, 2013 at 12:28 AM, Alexey Khoroshilov wrote: > goto err and goto err_gateoff before mutex_lock(&state->internal->demod_lock) > lead to unlock of unheld mutex in stv090x_sleep(). Out of curiosity, what happens when you try to unlock an unlocked mutex ? Regards, Manu -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Re: [GIT PULL] Disintegrate UAPI for media
On Thu, Oct 11, 2012 at 1:53 PM, Oliver Endriss wrote:
> Mauro Carvalho Chehab wrote:
>> Em Tue, 09 Oct 2012 14:30:24 +0100
>> David Howells escreveu:
>>
>> > Can you merge the following branch into the media tree please.
>> >
>> > This is to complete part of the Userspace API (UAPI) disintegration for
>> > which
>> > the preparatory patches were pulled recently. After these patches,
>> > userspace
>> > headers will be segregated into:
>> >
>> > include/uapi/linux/.../foo.h
>> >
>> > for the userspace interface stuff, and:
>> >
>> > include/linux/.../foo.h
>> >
>> > for the strictly kernel internal stuff.
>> >
>> > ---
>> > The following changes since commit
>> > 9e2d8656f5e8aa214e66b462680cf86b210b74a8:
>> >
>> > Merge branch 'akpm' (Andrew's patch-bomb) (2012-10-09 16:23:15 +0900)
>> >
>> > are available in the git repository at:
>> >
>> >
>> > git://git.infradead.org/users/dhowells/linux-headers.git
>> > tags/disintegrate-media-20121009
>> >
>> > for you to fetch changes up to 1c436decd49665be131887b08d172a7989cdceee:
>> >
>> > UAPI: (Scripted) Disintegrate include/linux/dvb (2012-10-09 09:48:42
>> > +0100)
>> >
>> >
>> > UAPI Disintegration 2012-10-09
>> >
>> >
>> > David Howells (1):
>> > UAPI: (Scripted) Disintegrate include/linux/dvb
>> >
>> > include/linux/dvb/Kbuild| 8 -
>> > include/linux/dvb/dmx.h | 130 +--
>> > include/linux/dvb/video.h | 249
>> > +
>> > include/uapi/linux/dvb/Kbuild | 8 +
>> > include/{ => uapi}/linux/dvb/audio.h| 0
>> > include/{ => uapi}/linux/dvb/ca.h | 0
>> > include/uapi/linux/dvb/dmx.h| 155 ++
>> > include/{ => uapi}/linux/dvb/frontend.h | 0
>> > include/{ => uapi}/linux/dvb/net.h | 0
>> > include/{ => uapi}/linux/dvb/osd.h | 0
>> > include/{ => uapi}/linux/dvb/version.h | 0
>> > include/uapi/linux/dvb/video.h | 274
>> >
>> > 12 files changed, 439 insertions(+), 385 deletions(-)
>> > rename include/{ => uapi}/linux/dvb/audio.h (100%)
>> > rename include/{ => uapi}/linux/dvb/ca.h (100%)
>> > create mode 100644 include/uapi/linux/dvb/dmx.h
>> > rename include/{ => uapi}/linux/dvb/frontend.h (100%)
>> > rename include/{ => uapi}/linux/dvb/net.h (100%)
>> > rename include/{ => uapi}/linux/dvb/osd.h (100%)
>> > rename include/{ => uapi}/linux/dvb/version.h (100%)
>> > create mode 100644 include/uapi/linux/dvb/video.h
>>
>> Hmm... last year, it was decided that we would be putting the DVB av7110-only
>> API files on a separate place, as the API there conflicts with V4L/alsa APIs
>
> Wrong! Hans Verkuil and you tried to do it, without caring that it would
> break userspace, and it was NAKed.
>
> Btw, if there is an API conflict, you guys created it.
>
> Anyone, who is interested in the _true_ history, should have a look at
> the GIT changelog:
> - dvb/{video.h,audio.h,osd.h} was the original decoder API.
> - Then Hans extended this API, still using the same files.
> - Later the v4l guys decided to create a new API.
> - Now they want to (re)move the old one, breaking userspace.
>
> I explicitly NAK any attempt to break userspace applications and tools!
> There is no reason to do it!
>
>> and are used only by one upstream driver (there were two drivers using them,
>> at that time). As you might notice, av7110 hardware is really old, not
>> manufactured anymore since maybe 10 years ago, and it is an unmaintained
>> driver.
>
> The driver works fine, and it will continue to do so, unless someone
> tampers with it. It does not require maintenance.
> The hardware is old, but it is still in use, as it is easy to create a
> pc-based settopbox with it.
As of writing; the av7110 is the only driver in-kernel, but there is more to it:
Such drivers are hard to bring up and takes an awful amount of time. There
is already one driver which is nearing completion based on the same interface.
>
>> Some developers complained, arguing that moving it to a separate file would
>> be breaking the compilation on existing tools (they're basically concerned
>> with
>> it due to out-of-tree drivers - mostly propietary ones, that use this API).
>
> It you move the API somewhere else, you will break userspace applications
> like VDR. This is not acceptable.
>
>> Now that we're moving everything, it does make sense to do that, moving
>> dvb/(audio|osd|video).h to someplace else (maybe linux/dvb/av7110.h or
>> linux/dvb/legacy/*.h).
>
> As far as I understand the original patchset, it will not break
> userspace, as it will simply move all files somewhere else, preserving
> file names and the position of the files in the tree.
>
> Mauro is trying to the move the old decoder API somewhere else, possibly
> into a different file, w
Re: [PATCH] Blackfin I2C/TWI driver: update for 2.6.24 merge windows
Jean Delvare wrote: > BTW, as a rule of thumb, I am ignoring patches that are sent to the > LKML in addition to the i2c list. Why ? The statement would have made sense if the i2c list was not CC 'd, but stating that if LK is CC 'd additionally sounds ... - 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 3/3] V4L: cinergyT2, remove bad usage of ERESTARTSYS
Marcel Siegert wrote:
> Manu Abraham schrieb:
>> Mauro Carvalho Chehab wrote:
>>> Em Qua, 2007-10-10 Ã s 11:59 -0400, Alan Cox escreveu:
>>>> On Wed, Oct 10, 2007 at 12:35:41PM -0300, Mauro Carvalho Chehab wrote:
>>>>> Em Qua, 2007-10-10 Ã s 00:18 -0400, Michael Krufky escreveu:
>>>>>> Is this illegal as per kernel codingstyle?
>>>>> Yes, it is. CodingStyle states:
>>>>
>>>> No.. "Illegal" means prohibited by law. Its merely wrong 8)
>>>>
>>> LOL
>>>
>>>>> The proper fix is just to replace the offended code by this:
>>>>>
>>>>> err=foo();
>>>>> if (error)
>>>>> goto error;
>>>> Lots of code uses
>>>>
>>>> if ((err = foo()) < 0)
>>>>
>>>> so I would'y worry too much. The split one however clearer and also
>>>> safer.
>>> Yes, this is not a severe CodingStyle violation. Still, the above code
>>> is better than the used one.
>>>
>>> Since, on your example, it is clear that the programmer wanted to test
>>> if the value is less than zero.
>>> The code:
>>>
>>> if ( (err=foo()) )
>>>
>>> should also indicate an operator mistake of using =, instead of ==.
>>>
>>> Probably, source code analyzers like Coverity will complain about the
>>> above.
>>>
>>> If not violating CodingStyle, I would rather prefer to code this as:
>>> if ( !(err=foo() ) or, even better, using:
>>> if ( (err=foo()) != 0)
>>>
>>> clearly indicating that it is tested if the value is not zero.
>>>
>>> Even being a quite simple issue, I would prefer if Jiri can fix it.
>>>
>>
>>
>> When you have only some few lines of code you can write
>>
>> err = foo()
>> if (err) {
>> do whatever
>> }
>> doesn't matter ..
>>
>> But when you have hell a lot of code, checking error's what you
>> mention is insane.
>>
>> ie,
>>
>> if ((err = foo()) expr ) is better.
>>
>> http://lkml.org/lkml/2007/2/4/56
>>
>> Manu
>>
> hi manu,
>
> it's not worth discussing this in a way like
> "i know something from the past and that was a different solution".
>
didn't mean to look at it that way, because i had addressed my concerns
at that time as well.
> if you look to other parts in that thread like
>
> http://lkml.org/lkml/2007/2/3/150
>
> you will see that they came also to a kind of different solution,
> NOT to use the 1-liner for assignment statements.
>
> it's more like a religious/personal discussion how to
> struct/indent/format code.
> and, to state my position for clear,
It is. Sometimes i find such things in CodingStyle to be too silly.
>
> if kernel coding style document isnt updated to allow the constructions
> of code that caused this discussion, we dont have to discuss but follow
> the rules.
>
> anything else on this topic (coding style and it's sense) is to be
> discussed on kernel ml.
>
Marcel, It is on LKML.
Manu
-
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 3/3] V4L: cinergyT2, remove bad usage of ERESTARTSYS
Mauro Carvalho Chehab wrote:
> Em Qua, 2007-10-10 Ã s 11:59 -0400, Alan Cox escreveu:
>> On Wed, Oct 10, 2007 at 12:35:41PM -0300, Mauro Carvalho Chehab wrote:
>>> Em Qua, 2007-10-10 Ã s 00:18 -0400, Michael Krufky escreveu:
Is this illegal as per kernel codingstyle?
>>> Yes, it is. CodingStyle states:
>>
>> No.. "Illegal" means prohibited by law. Its merely wrong 8)
>>
>
> LOL
>
>>> The proper fix is just to replace the offended code by this:
>>>
>>> err=foo();
>>> if (error)
>>> goto error;
>> Lots of code uses
>>
>> if ((err = foo()) < 0)
>>
>> so I would'y worry too much. The split one however clearer and also
>> safer.
>
> Yes, this is not a severe CodingStyle violation. Still, the above code
> is better than the used one.
>
> Since, on your example, it is clear that the programmer wanted to test
> if the value is less than zero.
>
> The code:
>
> if ( (err=foo()) )
>
> should also indicate an operator mistake of using =, instead of ==.
>
> Probably, source code analyzers like Coverity will complain about the
> above.
>
> If not violating CodingStyle, I would rather prefer to code this as:
> if ( !(err=foo() )
> or, even better, using:
> if ( (err=foo()) != 0)
>
> clearly indicating that it is tested if the value is not zero.
>
> Even being a quite simple issue, I would prefer if Jiri can fix it.
>
When you have only some few lines of code you can write
err = foo()
if (err) {
do whatever
}
doesn't matter ..
But when you have hell a lot of code, checking error's what you
mention is insane.
ie,
if ((err = foo()) expr ) is better.
http://lkml.org/lkml/2007/2/4/56
Manu
-
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
Hello Markus, Markus Rechberger wrote: > The main discussion in this thread was about drivers in userspace > are bad because the API will allow binary drivers. The guy > who works for Hauppauge (again I also have good contacts > at Hauppauge Europe) writes it's bad - for no technical reason. AFAICS, Steven raised the same thoughts what i had. > If someone points out that it is bad (after reading the whole thread) > why don't we put X.org, bash, well everything into the kernel? I am not saying that userspace is bad. In fact i am all for userspace, _if_ there is much of a complication. For example we have had largely complex devices. You might like to read this thread a while back. This was the reason why we started up libdvbapi/mti (For those who don't know what it is, libdvbapi/mti is a userspace approach for having device support in userspace with complicated tuning algorithms with a lot of calculations) http://search.gmane.org/?query=Re%3A+%5BRFC%5D+Userspace+extensions%2C+was+Re%3A+%5Blinux-dvb%5D+%5Bpatch%5D+Add+support+for+different+tuning+algorithms&author=&group=linux.drivers.dvb&sort=relevance&DEFAULTOP=and&query= For that demodulator and a successor for the same, i had finally moved the same to in kernel with a lot of trouble. Maybe it is not as precise as it should have been. But what i mean is that we should use such approaches if there needs to be a heavy valid reason and if there are many more devices going that way, we should definitely move to userspace. Maybe the userspace idea is a bit still immature. That said, i don't see any such complexities with the XC3028 Manu - 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
Aidan Thornton wrote: > > I think this will require a rethink of either how the em2880-dvb > driver works or how frontend drivers work. The current API expects > users to initialise their frontend and then bind a tuner to it. > em2880-dvb is a sort of subdriver that attaches to the main driver, > and doesn't have any control over when or how it initialises its > tuner, so it can't delay tuner initialisation until the frontend has > been initialised. (I don't think it's the only hybrid driver that > works this way either). Of course, I could be missing something. The em28xx/xc3028 is in fact not too complex. Just for sake of demonstration, some time back i had posted a dummy driver how it can be done in a nice and clean way as an example. The patch assumes some additional standards, you can ignore them. But you get the general idea from in there. http://marc.info/?l=linux-video&m=117613833119350&w=2 > >> There is no reason why the Xceive driver cannot be merged into the >> current development tree using the hybrid tuner framework as it stands >> today. > > I'm not convinced this is entirely true. In order to avoid unnecessary > reinitialisation of the device, the driver needs to know whether the > device is in analog or digital mode, and I can't see a way of doing it > with the current API. (I think existing drivers, such as the xc2028 > driver in one branch, use the older analog API and make the digital > driver a wrapper around it.) Again, I may be missing something. You can read this post also for some additional information. http://marc.info/?l=linux-video&m=117922735929375&w=2 Use the ideas as you deem fit. ;-) Manu - 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
Joerg Roedel wrote: >>> Common new IOMMUs have only very few in common with the AGP GART. In >>> fact, with current modern IOMMU hardware it will be possible to >>> implement secure userspace device drivers that are even able to do DMA. >>> This is not possible with the GART. >>> Though you get a physical to virtual translation, what about interrupts, >>> Modern IOMMUs are able to remap interrupts. This will solve the problem >>> with PCI interrupt sharing. >> What CPU's are we talking about ? > > IOMMUs are not necessarily a CPU feature. These IOMMUS will be found in > the South/North Bridge or even on PCI devices itself (uncommon). The > Calgary IOMMU is such an example of an IOMMU not implemented on the CPU > itself. > I do understand that (an earlier reply from Grant Grundler on the same [1], while working on something else), but that wasn't exactly what i was getting at. The bridges are in fact tied up with a certain CPU class. Though your argument holds true: "secure userpsace device drivers can be implemented with modern hardware" There is a large flaw in it. (From an academic POV, you are correct) Now, if all the drivers were to depend on that certain feature, what happens to all other CPU class users ? Looking at a pile of CPU's being used, also not to forget that devices such as STB's use even very small embedded CPU's such as the PPC405 Vulcan based [2] to mobile devices such as mobile phones using ARM, Xtensa [3], OMAP CPU's/platforms, which do not in any way use the bridges nor the CPU class which you however mention. So .. we are looking at a small segment, ie. a subset of the PC users even, even if the larger segments like STB's can be ignored. This would mean that only a small subset of users using a certain CPU class can use those drivers (eventhough the devices themselves don't have that limitation, the limitation being the implementation of the driver alone), which is absurd. Manu [1] http://lkml.org/lkml/2007/5/26/217 [2] http://abraham.manu.googlepages.com/p3160033.jpg [3] http://tensilica.com/ - 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
Joerg Roedel wrote: > On Fri, Sep 14, 2007 at 11:57:59AM +0400, Manu Abraham wrote: >>>>> What do you think about IOMMU? >>>>> >>>>> >>>> Just because AMD or INTEL want to invent some whizzy new technology it >>>> doesn't say anything about the TV card development and retail business. >>>> Intel and AMD have teams of Linux engineers helping operating system >>>> developers bring their ideas and technologies to new platforms. That's a >>>> million miles away from any of the TV board vendors I know of, who have >>>> little or NO fulltime linux developers and consider the < 5% market >>>> fringe at best. >>>> >>> it helps to virtualize devices and introduces newer features for that. >>> Some interesting projects could be derrived out of that, there are >>> quite a few interesting papers floating around how drivers could be >>> handled in future. >>> >> IOMMU can be considered similar to the AGP GART, which is similar, >> remapping the Addresses, as far as i understand. > > Common new IOMMUs have only very few in common with the AGP GART. In > fact, with current modern IOMMU hardware it will be possible to > implement secure userspace device drivers that are even able to do DMA. > This is not possible with the GART. > >> Though you get a physical to virtual translation, what about interrupts, > > Modern IOMMUs are able to remap interrupts. This will solve the problem > with PCI interrupt sharing. What CPU's are we talking about ? Thanks for the explanation. Manu - 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
>>> What do you think about IOMMU? >>> >>> >> Just because AMD or INTEL want to invent some whizzy new technology it >> doesn't say anything about the TV card development and retail business. >> Intel and AMD have teams of Linux engineers helping operating system >> developers bring their ideas and technologies to new platforms. That's a >> million miles away from any of the TV board vendors I know of, who have >> little or NO fulltime linux developers and consider the < 5% market >> fringe at best. >> > > it helps to virtualize devices and introduces newer features for that. > Some interesting projects could be derrived out of that, there are > quite a few interesting papers floating around how drivers could be > handled in future. > IOMMU can be considered similar to the AGP GART, which is similar, remapping the Addresses, as far as i understand. Though you get a physical to virtual translation, what about interrupts, yet to be seen with how to do it with multipath scenarios. Something that i happened to read https://www.gelato.unsw.edu.au/archives/comp-arch/2007-March/007370.html Even Documentation/Intel-IOMMU.txt, doesn't seem to paint a very rosy picture Manu - 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
Markus Rechberger wrote: > On 9/13/07, Manu Abraham <[EMAIL PROTECTED]> wrote: >> Markus Rechberger wrote: >>> On 9/13/07, Manu Abraham <[EMAIL PROTECTED]> wrote: >>>>> It's only a step in development, I do not intend to keep the kernel >>>>> stub in the end, but I do intend to keep and use the userspace drivers >>>>> with i2c-dev in the long run, this requires a v4l/dvb library at the >> front >>>>> of everything. >>>> Well, this was what adq and myself did with libdvbapi and mti, (much >>>> before UIO was announced at LK.) It is not tied to I2C either. >>>> >>> I2C is the main communication path for it, although there are callback >>> mechanisms available which add the possibility for different configuration >>> paths. >> Sorry, i must say that what you said is wrong. >> >> The example implementation in libdvbapi/mti is I2C only with a STV0299 >> on the TTPCI, if that was what you meant. >> But if you need examples for every possible interface, then probably you >> are out of luck. >> > > I didn't comment the libdvbapi/mti driver. > I'm quite confident that non I2C protocols can be handled by a callback > function. In the end it's either a usb control command or pci mmio writes There's also DTL in some cases. It's not USB msgs and or PCI MMIO alone. The actual DTL spec is unfortunately not open. Manu - 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
Markus Rechberger wrote: > On 9/13/07, Manu Abraham <[EMAIL PROTECTED]> wrote: >>> It's only a step in development, I do not intend to keep the kernel >>> stub in the end, but I do intend to keep and use the userspace drivers >>> with i2c-dev in the long run, this requires a v4l/dvb library at the front >>> of everything. >> Well, this was what adq and myself did with libdvbapi and mti, (much >> before UIO was announced at LK.) It is not tied to I2C either. >> > > I2C is the main communication path for it, although there are callback > mechanisms available which add the possibility for different configuration > paths. Sorry, i must say that what you said is wrong. The example implementation in libdvbapi/mti is I2C only with a STV0299 on the TTPCI, if that was what you meant. But if you need examples for every possible interface, then probably you are out of luck. Manu - 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
> It's only a step in development, I do not intend to keep the kernel > stub in the end, but I do intend to keep and use the userspace drivers > with i2c-dev in the long run, this requires a v4l/dvb library at the front > of everything. Well, this was what adq and myself did with libdvbapi and mti, (much before UIO was announced at LK.) It is not tied to I2C either. But, according to your statements (with regards to i2c-dev) you can handle only some I2C based devices, which is in fact a subset of a subset. Also not to forget that hardly a few I2C devices are in fact "truly" I2C compatible. In fact many variables to be considered. 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. Manu - 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: file system for solid state disks
linux-os (Dick Johnson) wrote: > http://en.wikipedia.org/wiki/Solid_state_drive > > This is exactly what I proposed on this list a long > time ago. It is now a reality. It's been around for a couple of years ;-) http://forum.pcvsconsole.com/viewthread.php?tid=15802 http://www.anandtech.com/tradeshows/showdoc.aspx?i=2431&p=5 - 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] [2.6 patch] dvb_net_ule(): fix check-after-use
Adrian Bunk wrote:
> The Coverity checker spotted that we'd have already oops'ed if "dev"
> was NULL.
>
> Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
>
> ---
> --- linux-2.6.23-rc1-mm2/drivers/media/dvb/dvb-core/dvb_net.c.old
> 2007-08-08 06:17:19.0 +0200
> +++ linux-2.6.23-rc1-mm2/drivers/media/dvb/dvb-core/dvb_net.c 2007-08-08
> 06:17:35.0 +0200
> @@ -346,33 +346,28 @@
> static void dvb_net_ule( struct net_device *dev, const u8 *buf, size_t
> buf_len )
> {
> struct dvb_net_priv *priv = dev->priv;
> unsigned long skipped = 0L;
> const u8 *ts, *ts_end, *from_where = NULL;
> u8 ts_remain = 0, how_much = 0, new_ts = 1;
> struct ethhdr *ethh = NULL;
>
> #ifdef ULE_DEBUG
> /* The code inside ULE_DEBUG keeps a history of the last 100 TS cells
> processed. */
> static unsigned char ule_hist[100*TS_SZ];
> static unsigned char *ule_where = ule_hist, ule_dump = 0;
> #endif
>
> - if (dev == NULL) {
> - printk( KERN_ERR "NO netdev struct!\n" );
> - return;
> - }
> -
> /* For all TS cells in current buffer.
>* Appearently, we are called for every single TS cell.
>*/
> for (ts = buf, ts_end = buf + buf_len; ts < ts_end; /* no default incr.
> */ ) {
>
> if (new_ts) {
> /* We are about to process a new TS cell. */
>
> #ifdef ULE_DEBUG
> if (ule_where >= &ule_hist[100*TS_SZ]) ule_where =
> ule_hist;
> memcpy( ule_where, ts, TS_SZ );
> if (ule_dump) {
> hexdump( ule_where, TS_SZ );
> ule_dump = 0;
>
>
Signed-off-by: Manu Abraham <[EMAIL PROTECTED]>
-
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] [2.6 patch] dvb/bt8xx: "extern inline" -> "static inline"
Adrian Bunk wrote:
> "extern inline" will have different semantics with gcc 4.3.
>
> Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
>
> ---
> 6ffbe5b19606cd8756be4d04e0902de69e447c85
> diff --git a/drivers/media/dvb/bt8xx/bt878.h b/drivers/media/dvb/bt8xx/bt878.h
> index f685bc1..1c8e336 100644
> --- a/drivers/media/dvb/bt8xx/bt878.h
> +++ b/drivers/media/dvb/bt8xx/bt878.h
> @@ -149,7 +149,7 @@ void bt878_start(struct bt878 *bt, u32 controlreg, u32
> op_sync_orin,
> void bt878_stop(struct bt878 *bt);
>
> #if defined(__powerpc__) /* big-endian */
> -extern __inline__ void io_st_le32(volatile unsigned __iomem *addr, unsigned
> val)
> +static inline void io_st_le32(volatile unsigned __iomem *addr, unsigned val)
> {
> __asm__ __volatile__("stwbrx %1,0,%2":"=m"(*addr):"r"(val),
>"r"(addr));
>
>
Signed-off-by: Manu Abraham <[EMAIL PROTECTED]>
-
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
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. - 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
On 8/14/07, Mauro Carvalho Chehab <[EMAIL PROTECTED]> wrote: > > Em Seg, 2007-08-13 às 19:44 -0700, Joe Perches escreveu: > > On Mon, 2007-08-13 at 22:08 -0400, Michael Krufky wrote: > > > drivers/media/video -- v4l > > > drivers/media/radio -- v4l > > > > > > drivers/media/dvb -- dvb > > > > VIDEO FOR LINUX > > P:Mauro Carvalho Chehab > > M:[EMAIL PROTECTED] > > P:LinuxTV.org Project > > M:[EMAIL PROTECTED] > > L:[EMAIL PROTECTED] > > W:http://linuxtv.org > > T:git kernel.org:/pub/scm/linux/kernel/git/mchehab/v4l-dvb.git > > S:Maintained > > F:Documentation/video4linux/ > > F:drivers/media/video/ > > F:drivers/media/radio/ > > F:include/linux/video_decoder.h > > F include/linux/videodev.h > You missed ':' > > F:include/linux/videodev2.h > > F:include/media/ > > This is not ok. Some maintained files won't be hit. You should add also > something like: > F: drivers/media/* This is NOT OK ! - 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
On 8/14/07, Joe Perches <[EMAIL PROTECTED]> wrote: > On Mon, 2007-08-13 at 23:22 +0400, Manu Abraham wrote: > > > F: drivers/media/ > > This means everything under media is maintained under V4L. Incorrect > > What would you like? > media/video and media/radio *only* belong under V4L Manu - 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] [1/2many] - FInd the maintainer(s) for a patch - scripts/get_maintainer.pl
On 8/13/07, Arjan van de Ven <[EMAIL PROTECTED]> wrote: > > On Mon, 2007-08-13 at 19:33 +0200, Mariusz Kozlowski wrote: > > Hello, > > > > I don't recall discusion about this so here are my 3 cents: > > > > I like the idea. > > I don't actually. It shows a central MAINTAINERS file is the wrong > approach; just that 500+ patches to the same file were needed shows > that. > > The maintainer info should be in the source file itself! That's the only > reasonable way to keep it updated; now I'm all for having it machine > parsable so that tools can use it, but it still really should be in the > code itself, not in some central file that will always just go out of > data, and will be a huge source of needless patch conflicts. ACK. Very much agree. In fact MAINTAINERS is a wrong thing altogether. For example, code/drivers under a subsystem, might not be easily add "able" to a central file in some cases as it is scattered around. Maintainer info in the source is the right way to go. - 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
On 8/13/07, Joe Perches <[EMAIL PROTECTED]> wrote: > On Mon, 2007-08-13 at 15:15 -0300, Mauro Carvalho Chehab wrote: > > There are more include files to be added, for the older V4L APIs: > > F: include/linux/video_decoder.h > > F: include/linux/videodev.h > > VIDEO FOR LINUX > P: Mauro Carvalho Chehab > M: [EMAIL PROTECTED] > M: [EMAIL PROTECTED] > L: [EMAIL PROTECTED] > W: http://linuxtv.org > T: git kernel.org:/pub/scm/linux/kernel/git/mchehab/v4l-dvb.git > S: Maintained > F: Documentation/video4linux/ > F: drivers/media/ This means everything under media is maintained under V4L. Incorrect - 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] msleep() with hrtimers
On 8/8/07, Andi Kleen <[EMAIL PROTECTED]> wrote: > On Wed, Aug 08, 2007 at 03:09:14PM +0400, Manu Abraham wrote: > > On 08 Aug 2007 13:55:28 +0200, Andi Kleen <[EMAIL PROTECTED]> wrote: > > > Andrew Morton <[EMAIL PROTECTED]> writes: > > > > > > > > I'd be surprised if there was significant overhead - the maximum > > > > frequency > > > > at which msleep() can be called is 1000Hz. We'd need an awful lot of > > > > overhead for that to cause problems, surely? > > > > > > The bigger risk is probably to break drivers that rely on msleep(1) > > > really being msleep( very long depending on HZ ) > > > > > > But the only way to find out is to try it. > > > > Well, i am quite sure a lot of drivers will be broken. But well .. if > > If you know of specific examples you should list them so that > they can be fixed proactively. A bit hard to state, which all since quite some are RE'd. Well you can hear the cries when it is broken. :) Manu - 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] msleep() with hrtimers
On 08 Aug 2007 13:55:28 +0200, Andi Kleen <[EMAIL PROTECTED]> wrote: > Andrew Morton <[EMAIL PROTECTED]> writes: > > > > I'd be surprised if there was significant overhead - the maximum frequency > > at which msleep() can be called is 1000Hz. We'd need an awful lot of > > overhead for that to cause problems, surely? > > The bigger risk is probably to break drivers that rely on msleep(1) > really being msleep( very long depending on HZ ) > > But the only way to find out is to try it. Well, i am quite sure a lot of drivers will be broken. But well .. if it is for the better, guess, never mind ... Manu - 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] msleep() with hrtimers
Hi Arjan, On 8/6/07, Arjan van de Ven <[EMAIL PROTECTED]> wrote: > On Mon, 2007-08-06 at 12:03 +0200, Roman Zippel wrote: > > Hi, > > > > On Sun, 5 Aug 2007, Arjan van de Ven wrote: > > > > > > There's no problem to provide a high resolution sleep, but there is also > > > > no reason to mess with msleep, don't fix what ain't broken... > > > > > > John Corbet provided the patch because he had a problem with the current > > > msleep... in that it didn't provide as good a common case as he > > > wanted... so I think your statement is wrong ;) > > > > Only under the assumptation, that msleep _must_ be "fixed" for all other > > current users too. > > Give users a choice to use msleep or nanosleep, how do you know what's > > "best" for them? > > do you have any actual technical objections, or do you just hate > hrtimers in general? > > I really don't see what you hate so much about making the msleep() > implementation provide a more precise (typical sleep time of 1msec > rather than 20msec) behavior than the current one. Trying to distract > that by proposing a very different API (working on a totally different > time unit, while a lot of kernel users are using miliseconds; don't get > me wrong, a usleep() and nsleep() might be useful if there's users that > want to sleep in such times) is just trying to distract the issue. > > So, let me ask a direct question: What do you think is specifically > wrong about changing the msleep() implementation as is done here? The > behavior is clearly an improvement, so what is your objection on the > flipside? > I think there could be a flipside based on what Roman said, but it is my guess only. currently wherever msleep is used now it sleeps with an ambiguous amount. Eventhough the ambiguous sleep period is not appreciable, fixing msleep might have a bad side effect. ie, drivers which would be sleeping for a specified period would sleep less, just as compared to the more precise sleep. I think, it would be hard to fix, such breakages. Maybe a newer sleep method would be much better, such that it doesn't cause any breakage. - 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] msleep() with hrtimers
On 8/6/07, Roman Zippel <[EMAIL PROTECTED]> wrote: > Hi, > > On Sun, 5 Aug 2007, Arjan van de Ven wrote: > > > > There's no problem to provide a high resolution sleep, but there is also > > > no reason to mess with msleep, don't fix what ain't broken... > > > > John Corbet provided the patch because he had a problem with the current > > msleep... in that it didn't provide as good a common case as he > > wanted... so I think your statement is wrong ;) > > Only under the assumptation, that msleep _must_ be "fixed" for all other > current users too. > Give users a choice to use msleep or nanosleep, how do you know what's > "best" for them? > You mean to say, the granularity of msleep is in mS with a tolerance of +/- "n" mS whereas nanosleep would have the tolerance in nS ? (ignoring all the discussions about hrtimers and their internal design) I guess many people are/were confused on the aspect that, a msleep(1) meant sleep for a 1mS and nothing more. Well, this would explain, some of my hair raising incidents, if i understood you correctly. Since it is such a confusion, maybe it needs to be documented some place, that people don't fall into the same trap. Manu - 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: Distributed storage.
On 8/4/07, Dave Dillow <[EMAIL PROTECTED]> wrote: > On Fri, 2007-08-03 at 09:04 +0400, Manu Abraham wrote: > > On 7/31/07, Evgeniy Polyakov <[EMAIL PROTECTED]> wrote: > > > > > TODO list currently includes following main items: > > > * redundancy algorithm (drop me a request of your own, but it is > > > highly > > > unlikley that Reed-Solomon based will ever be used - it is too > > > slow > > > for distributed RAID, I consider WEAVER codes) > > > > > > LDPC codes[1][2] have been replacing Turbo code[3] with regards to > > communication links and we have been seeing that transition. (maybe > > helpful, came to mind seeing the mention of Turbo code) Don't know how > > weaver compares to LDPC, though found some comparisons [4][5] But > > looking at fault tolerance figures, i guess Weaver is much better. > > > > [1] http://www.ldpc-codes.com/ > > [2] http://portal.acm.org/citation.cfm?id=1240497 > > [3] http://en.wikipedia.org/wiki/Turbo_code > > [4] > > http://domino.research.ibm.com/library/cyberdig.nsf/papers/BD559022A190D41C85257212006CEC11/$File/rj10391.pdf > > [5] http://hplabs.hp.com/personal/Jay_Wylie/publications/wylie_dsn2007.pdf > > Searching Google for Dr. Plank's work at the University of TN turns up > some analysis of using LDPC codes in storage systems. > > http://www.google.com/search?hl=en&q=plank+ldpc&btnG=Google+Search > > Patents are an issue to watch out for around the use of Tornado/Raptor > codes. I've not researched it, but I believe there be dragons there. > We don't use the code in the driver straight away [2] (in the case that i mentioned), since that happens in the hardware (demodulator chip) [1], but we have an interface for selecting the code-rate [2] (LDPC/BCH) for DVB-S2 and the new papers for DVB-T2 looks geared that the base decision is to use LDPC. Though i now see a patent application for it [3]. Not sure whether it is a registered patent, i am under an agreement of Non-Disclosure with STM. Will ask the relevant person there, whether they have it registered. (Most probably they may have it registered). There are a few people from STM on LK, if not they can possibly confirm whether the patent is regsitered or not. [1] http://www2.dac.com/data2/42nd/42acceptedpapers.nsf/0c4c09c6ffa905c487256b7b007afb72/998f93e4b29e99fa87256fc400714617/$FILE/33_1.pdf [2] http://linuxtv.org/hg/~manu/stb0899-c5/file/760cb230695c/linux/include/linux/dvb/frontend.h [3] http://www.freepatentsonline.com/20060206779.html http://www.freepatentsonline.com/20060206778.html - 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: Distributed storage.
On 7/31/07, Evgeniy Polyakov <[EMAIL PROTECTED]> wrote: > TODO list currently includes following main items: > * redundancy algorithm (drop me a request of your own, but it is highly > unlikley that Reed-Solomon based will ever be used - it is too slow > for distributed RAID, I consider WEAVER codes) LDPC codes[1][2] have been replacing Turbo code[3] with regards to communication links and we have been seeing that transition. (maybe helpful, came to mind seeing the mention of Turbo code) Don't know how weaver compares to LDPC, though found some comparisons [4][5] But looking at fault tolerance figures, i guess Weaver is much better. [1] http://www.ldpc-codes.com/ [2] http://portal.acm.org/citation.cfm?id=1240497 [3] http://en.wikipedia.org/wiki/Turbo_code [4] http://domino.research.ibm.com/library/cyberdig.nsf/papers/BD559022A190D41C85257212006CEC11/$File/rj10391.pdf [5] http://hplabs.hp.com/personal/Jay_Wylie/publications/wylie_dsn2007.pdf - 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] SAA7160/2
Hi Steve, On 8/1/07, Steven Toth <[EMAIL PROTECTED]> wrote: > Hi manu, > > Hauppauge deal with NXP on a daily basis. We have a number of 716x > products either in the market or coming to market and we can add some > leverage. > > I can push this through our FAE and account manager. Who's your contact > at NXP that we should make reference to? > > Email me privately and we can work together on this. > Steve that would be cool. I will mail you the details. Thanks, Manu - 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/
SAA7160/2
Hi All, After a bit of talks with NXP, they stated that if shown enough of a user base (future business forecast) for the SAA7160 / SAA7162 PCIe chipset, they would take into consideration, an investment into support, such that the chips can be better supported. ie, i need to provide them information that there is some significant numbers in the user base. Additionally, vendors such as Azurewave are ready to help us as well, in whatever way they can. Any ideas, how we can show user support in terms of a future business case ? Comments appreciated. Thanks, Manu - 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.6 patch] dvb_frontend_ioctl(): fix check-after-use
On 7/31/07, Adrian Bunk <[EMAIL PROTECTED]> wrote:
> The Coverity checker spotted that we have already oops'ed if "fe" was NULL.
>
> Since "fe" being NULL seems impossible at this point this patch removes
> the NULL check.
>
> Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
>
> ---
> --- linux-2.6.23-rc1-mm1/drivers/media/dvb/dvb-core/dvb_frontend.c.old
> 2007-07-29 21:41:56.0 +0200
> +++ linux-2.6.23-rc1-mm1/drivers/media/dvb/dvb-core/dvb_frontend.c
> 2007-07-29 21:42:16.0 +0200
> @@ -706,11 +706,11 @@ static int dvb_frontend_ioctl(struct ino
> struct dvb_frontend_private *fepriv = fe->frontend_priv;
> int err = -EOPNOTSUPP;
>
> dprintk ("%s\n", __FUNCTION__);
>
> - if (!fe || fepriv->exit)
> + if (fepriv->exit)
> return -ENODEV;
>
> if ((file->f_flags & O_ACCMODE) == O_RDONLY &&
> (_IOC_DIR(cmd) != _IOC_READ || cmd == FE_GET_EVENT ||
> cmd == FE_DISEQC_RECV_SLAVE_REPLY))
>
> -
Acked-by: Manu Abraham <[EMAIL PROTECTED]>
-
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 5/7] I/OAT: Add support for MSI and MSI-X
On 7/21/07, Nelson, Shannon <[EMAIL PROTECTED]> wrote: Manu Abraham [mailto:[EMAIL PROTECTED] >Sorry for being not clear. What i was asking is thus: > >A device that has legacy interrupts and MSI-X. I was thinking that if >MSI-X failed one should fall back to MSI mode (single message), that's >what i was assuming. > >In such a case, i do enable MSI-X mode on the device, when the request >for 2 ^ n number of messages (where messages can be a max of 32), If >the request fails one falls into a single message mode, ie MSI ? > > >> What device do you have in mind? > > >The device that i have in mind is a SAA7160. Notice our code looks at the return from pci_enable_msix() - it will give you a hint whether MSI-X is not supported (returns < 0) or you simply asked for too many (returns > 0). If the former, then fallback to legacy; if the latter, try MSI-X with only one interrupt, which essentially emulates MSI mode. Ok. Thanks for clearing it up. So the idea would be that if pci_enable_msix() for "n" number of messages failed, then settle down for 1 message, which is equivalent to MSI mode - 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 5/7] I/OAT: Add support for MSI and MSI-X
On 7/21/07, Roland Dreier <[EMAIL PROTECTED]> wrote: > In a case where you have a device that which supports MSI-X (multiple > interrupts) but the device in default is in MSI mode, ie some > configuration change is needed on the device. In such a case, how > would one handle between MSI-X and MSI ? > > ie the device initially doesn't support MSI-X I don't understand the question really. Does the PCI spec even allow a device to be in MSI mode by default? Surely the OS must initialize the address/message before the device can generate an MSI? Sorry for being not clear. What i was asking is thus: A device that has legacy interrupts and MSI-X. I was thinking that if MSI-X failed one should fall back to MSI mode (single message), that's what i was assuming. In such a case, i do enable MSI-X mode on the device, when the request for 2 ^ n number of messages (where messages can be a max of 32), If the request fails one falls into a single message mode, ie MSI ? What device do you have in mind? The device that i have in mind is a SAA7160. I guess the interesting case is a PCIe device that supports MSI and MSI-X but not legacy interrupts. However I would assume such a device would come up with both MSI and MSI-X disabled. - R. - 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 5/7] I/OAT: Add support for MSI and MSI-X
On 7/21/07, Roland Dreier <[EMAIL PROTECTED]> wrote: > This driver supports some chipsets that do MSI, and some that do MSI-X, > but none that can do both. Thanks, that's the simple answer I was hoping for. Obviously if some chipsets only do MSI then you need the MSI code in addition to the MSI-X code. In a case where you have a device that which supports MSI-X (multiple interrupts) but the device in default is in MSI mode, ie some configuration change is needed on the device. In such a case, how would one handle between MSI-X and MSI ? ie the device initially doesn't support MSI-X - 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/
D state
Hi, When a device is in D3 state, is it possible to read from the PCI config space header ? Or does a D3 state imply that the whole PC itself is in standby ? I am trying to relate whether a device that i have, a new device that i am working upon, starts up in D3 state. whether that could be the cause of some weirdness. Thanks, Manu - 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: Reading a physical memory location
On 7/11/07, Nobin Mathew <[EMAIL PROTECTED]> wrote: See this in the documentation The returned virtual address is a current CPU mapping for the memory address given. It is only valid to use this function on addresses that have a kernel mapping This function does not handle bus mappings for DMA transfers. In almost all conceivable cases a device driver should not be using this function To get a better idea, look here http://tldp.org/LDP/khg/HyperNews/get/devices/addrxlate.html - 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: Reading a physical memory location
On 7/11/07, Nobin Mathew <[EMAIL PROTECTED]> wrote: Which is your platform ? Which processor? If you want to use physical address directly, then disable MMU. That is not possible in linux. ioremap does map io memory using phys_to_virt I thought phys_to_virt was enough to remap physical memory to virtual http://mirror.linux.org.au/linux.conf.au/2005/cdrom-beta-1/linux-mandocs-2.6.12.6/phys_to_virt.html Nobin On 7/11/07, Manu Abraham <[EMAIL PROTECTED]> wrote: > On 7/10/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > > > > Thanks for the quick reply. But I was wondering as to why I would have to map > > the physical address to the virtual address when I know that the string is > > permanently in the physical memory because its loaded into flash. Is there a way > > to directly read from the physical memory location? Also, do the functions > > ioremap() and readl(va) work when called from within a kernel module? > > > > Of course, if you look at almost any of the memory mapped device > drivers, you will find that ioremap/readl/writel is the backbone of > your infrastructure. > > > Manu > - 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: Reading a physical memory location
On 7/10/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: Thanks for the quick reply. But I was wondering as to why I would have to map the physical address to the virtual address when I know that the string is permanently in the physical memory because its loaded into flash. Is there a way to directly read from the physical memory location? Also, do the functions ioremap() and readl(va) work when called from within a kernel module? Of course, if you look at almost any of the memory mapped device drivers, you will find that ioremap/readl/writel is the backbone of your infrastructure. Manu - 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: Dual-Licensing Linux Kernel with GPL V2 and GPL V3
Bernd Petrovitsch wrote: > On Wed, 2007-06-20 at 18:14 -0300, Tomas Neme wrote: > [] >> Why, if you let user-compiled kernels to run in a TiVo, it might be >> modified so the TiVo can be used to pirate-copy protected content, > > Or it might be modified to fix a bug - either a technical one or a legal > one as described below. > >> which is a serious security hole. TiVo would need to read, approve of, > > "Pirate copying" is forbidden anyways in almost every jurisdiction > AFAIK. Perhaps we should disallow cars on the streets since one could > drive too fast with them. > Pirate copying should not be a reason to keep things closed as there are better methods to keep things open, yet provide a _not_ free service. But that would be upto the vendor how/what they wish to do rather than we talking about it. Which would be of no use. - 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: Dual-Licensing Linux Kernel with GPL V2 and GPL V3
[EMAIL PROTECTED] wrote: > what sort of signal can the network controller send that couldn't be > forged by the OS? > > how would you do this where the device is a receiver on the netwoek > (such as a satellite receiver) just for the question on the HOWTO (not on anything else) You can easily have scrambled streams with regards to DVB, eg: using EN50221. Some (like NDS for example in _some_ instances) use proprietary schemes, but there are standards based methods also. eg: Common Scrambling Algorithm (CSA) But in any case, this can be broken down too .. :-) - 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: Dual-Licensing Linux Kernel with GPL V2 and GPL V3
Lennart Sorensen wrote: > On Tue, Jun 19, 2007 at 07:28:22PM +0400, Manu Abraham wrote: >> Well, it is not Tivo alone -- look at http://aminocom.com/ for an >> example. If you want the kernel sources pay USD 50k and we will provide >> the kernel sources, was their attitude. > > Hmm, set top boxes are often rented from the cable company rather than > sold. Stupid grey area for sure. At least tivo does give you the > sources, without demanding more money. Rather big difference. I am not talking about the rented aspect, since these STB's are usually sold rather than rented. >> Well, it is not Tivo alone, a large chunk of the vendors do that. The >> vendors who actually do it the clean way are just few and can be counted >> very easily. > > Well at least where I work we don't try to lock down the hardware, we do > contribute our changes and bug fixes to upstream when it makes sense > (and where our changes wouldn't make sense for upstream, they are still > clearly included with the sources we have.) If a customer wants a copy > of the sources, they will get a nice DVD, although strangely none have > asked for one yet. Providing the changes back itself is a great thing altogether. - 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: Dual-Licensing Linux Kernel with GPL V2 and GPL V3
Alan Cox wrote: >> Well, it is not Tivo alone -- look at http://aminocom.com/ for an >> example. If you want the kernel sources pay USD 50k and we will provide >> the kernel sources, was their attitude. > > GPLv2 deals with that case, and they can (and should) be sued for it > [except that US copyright law is designed for large music companies not > people] Their argument was that the mentioned sources contain propreitary closed stuff from IBM/AMCC for the PPC 405/440 and or for the NXP (MIPS based) chips. Even if the GPLv2 deals with it, well haven't reached anywhere with it, inspite of talks with them. So most of the users just probably stopped talking sense with them, just like me. Have some of those Amino STB's, the software on it being buggy, including myself many others wanted to fix those bugs, but then people had to pay for their annual support to get the fixes. People who were able to fix also were denied the same since there is no source available. But if you wanted the sources, then you pay for the sources. If you don't pay for their sources, then pay for their Bronze/Silver/Gold Support schemes, where people pay through their nose. For a specific case with which i wanted to attach a USB based device to the box, they stated: we can port in a driver that which exists in the vanilla kernel, to their device but just that they need to be paid for that to be done, eventhough if someone else was willing to do that job, but that wasn't possible because of no sources. In either way, if you buy their devices, it is just that, you keep paying us, if you want your device your work as expected. - 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: Dual-Licensing Linux Kernel with GPL V2 and GPL V3
Lennart Sorensen wrote: > Well much as I don't like what Tivo did with only allowing signed > kernels to run, I don't see anything in the above that says they can't Well, it is not Tivo alone -- look at http://aminocom.com/ for an example. If you want the kernel sources pay USD 50k and we will provide the kernel sources, was their attitude. > do that. They let you have the code and make changes to it, they just > don't let you put that changed stuff on the device they build. The > software is free, even though the hardware is locked down. The GPL v3 > really seems to change the spirit to try and cover usage and hardware > behaviour, while the spirit of the GPL v2 seemed to me at least to > simply be to allow people to copy and change and use the code, and pass > that on to people. It didn't have anything to do with what they did > with it on hardware. Nothing prevents you from taking tivos kernel > changes and building your own hardware to run that code on, and as such > the spirit of the GPL v2 seems fulfilled. It covers freedom of the > source code and resulting binaries, not of the platform you run it on. > The GPL v3 has a much broader coverage of what it wants to control, > which to me means the spirit is different. > > I don't have a tivo, I use mythtv on my own PC. Tivo doesn't force you > to buy their hardware after all. Well, it is not Tivo alone, a large chunk of the vendors do that. The vendors who actually do it the clean way are just few and can be counted very easily. - 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: Dual-Licensing Linux Kernel with GPL V2 and GPL V3
Johannes Stezenbach wrote: > On Tue, Jun 19, 2007, Manu Abraham wrote: >> Johannes Stezenbach wrote: >> >>> I argue that if you keep the free loaders out, you miss >>> the chance to communicate with and educate them. >>> Communication across borders doesn't work well, and you create >>> a border between the morally "good" and the "bad". >>> >>> Of course you can't expect that every free loader will >>> learn and accept the free software philosopy, some just >>> won't. But to me that's acceptable, and the GPLv2, or indeed >>> Linus' tit-for-tat interpretation of the GPLv2, is IMHO >>> sufficient to protect my interests. >> Err .. when you say protection on one hand and on the other you state >> it's hard to keep free loaders away, > > I didn't say that. > > IMHO it isn't even useful to try to keep free loaders away, > it's better to try and integrate them gradually. That's part > of the game. > (Where "free loaders" is a term introduced by Alexandre, not by me.) > > The GPLv2 is a sufficient tool to defend free software > against those that don't even grasp tit-for-tat. But if > they do, you can talk to them *as peers* and try to convince > them that there's more to free software than just tit-for-tat. What i _feel_ is that "some" (vendors) think that even if they utilize existing resources what is open and keep what they have done, completely closed (ie, they use existing infrastructure as a building block, but they keep the stuff completely closed, in many cases the argument with regards to IP is not even valid, as looking at symbol tables etc we find some badly copied code from other parts etc, sewn together. The logical thought what i have is that they do this to avoid a competition in the short run) -- and they feel that they are doing things in a quite legal way. > But it has to be their decision, IMHO it's wrong to force them. Trying to force _anything_ on _anyone_ doesn't achieve anything, other than just anger. We at the worst could of course argue that users should avoid going for that specific product, but i don't know how much that would work. I say thus, because legally it would not be possible to challenge such vendors globally as rules and regulations are different with different governments and or countries. In such a case a tit-for-tat doesn't work at all. If all the people were to agree on common aspects, there wouldn't be any wars at all ? > The GPLv3 tries to be a tool to defend against those that > don't subscribe to the full Free Software Definition. If v3 defends the definition better, that would be a better use case, don't you think so ? (But i don't see how v3 also will defend the definition across international territories, in such a case what i outlined, since have been bitten by this many times, even talking to the black sheep which never helped) - 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: Dual-Licensing Linux Kernel with GPL V2 and GPL V3
Johannes Stezenbach wrote: > I argue that if you keep the free loaders out, you miss > the chance to communicate with and educate them. > Communication across borders doesn't work well, and you create > a border between the morally "good" and the "bad". > > Of course you can't expect that every free loader will > learn and accept the free software philosopy, some just > won't. But to me that's acceptable, and the GPLv2, or indeed > Linus' tit-for-tat interpretation of the GPLv2, is IMHO > sufficient to protect my interests. Err .. when you say protection on one hand and on the other you state it's hard to keep free loaders away, then don't you think that those 2 are two completely different things ? - 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: pci probe
Hi, Sorry for my late reply. Greg KH wrote: >>> - your driver will not work on any pci-hotplug type system (that >>> includes expresscard and pccard and lots of high-end servers. >> This doesn't matter > > Are you sure? PCI Hotplug is showing up in more places that people > realize... The PCI bridges that we have for the mentioned use, does not support Hotplugging at all and hence doesn't matter for those devices mentioned. >>> - your driver will not be notified if the system is being >>> suspended or resumed or wanting to drop into a low power >>> state. >>> - another driver can bind to your device without you ever >>> knowing it. >> These also sound bad. >> >>> So in short, use pci_probe and just handle the fact that you need to be >>> called for two PCI devices and bind to both of them. It shouldn't be >>> that hard... >> Thanks for the explanation. >> >> Do you mean to have two PCIID tables ? But then that does mean 2 modules >> don't you ? (i thought probe would be called once per module) Or you >> mean to say use PCI_ANY_ID in the table to match multiple devices and >> then allow probe to return a list of devices ? > > > No, you can specify multiple devices in the same device id table, and > your driver will get called for all of the matching devices. You just > need to "bind" them together in your driver to be able to handle > everything properly. It shouldn't be that tough. > Will take a go at it. I was using PCI_ANY_ID for the device id, so that should return all the devices. Thanks, Manu - 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: PCIE
Roland Dreier wrote: > > > At least on my device (PCI ID 1131:7162) there is no MSI-X capability, > > > so that's not an option for you. The current Linux implementation > > > does not support more than one MSI interrupt, so you just get one > > > interrupt with pci_enable_msi(). > > > > This would mean MSI or MSI-X ? A bit confused now. > > As I said, the device I have in my system: > > 02:00.0 Multimedia controller: Philips Semiconductors Unknown device 7162 > Subsystem: Animation Technologies Inc. Unknown device 0820 > Flags: bus master, fast devsel, latency 0, IRQ 11 > Memory at 9020 (64-bit, non-prefetchable) [size=1M] > Capabilities: [40] Message Signalled Interrupts: Mask- 64bit+ > Queue=0/5 Enable- > Capabilities: [50] Express Endpoint IRQ 0 > Capabilities: [74] Power Management version 2 > Capabilities: [80] Vendor Specific Information > > ...has only an MSI capability (the "[40] Message Signalled Interrupts" > line). So MSI-X is not possible, since the device cannot do it. And > that means you can at most do pci_enable_msi(). The current Linux MSI > support only handles a single interrupt, just like you get normally > (no matter how many MSI interrupts a device can handle). To get > multiple interrupts from a single device under Linux, you must use > MSI-X and pci_enable_msix -- but for this to work, your device must > support MSI-X of course. > > A device that supports both MSI and MSI-X would look like: > > 0b:00.0 InfiniBand: Mellanox Technologies MT25204 [InfiniHost III Lx HCA] > (rev 20) > Subsystem: Mellanox Technologies MT25204 [InfiniHost III Lx HCA] > Flags: bus master, fast devsel, latency 0, IRQ 16 > Memory at fc60 (64-bit, non-prefetchable) [size=1M] > Memory at d880 (64-bit, prefetchable) [size=8M] > Capabilities: [40] Power Management version 2 > Capabilities: [48] Vital Product Data > Capabilities: [90] Message Signalled Interrupts: Mask- 64bit+ > Queue=0/5 Enable- > Capabilities: [84] MSI-X: Enable- Mask- TabSize=32 > Capabilities: [60] Express Endpoint IRQ 0 > > with both "Message Signalled Interrupts" and "MSI-X" capabilities. > Thanks for the explanation. > However, as I said before I think you shouldn't worry about MSI right > now. Since there are many systems where MSI doesn't work, you'll need > to get the driver working with legacy (INTx) interrupts anyway. And > you seem to be in a bit over your head just doing that without adding > the complexity of MSI on top, hence my recommendation to just focus on > the basic driver. True, compatibility would be important. Thanks, Manu - 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: PCIE
Roland Dreier wrote: > > >> Another question would be if the device supports multiple messages, MSIX > > >> should be used ? > > > > > > Yes. Assuming the device supports multiple MSI-X messages. > > At least on my device (PCI ID 1131:7162) there is no MSI-X capability, > so that's not an option for you. The current Linux implementation > does not support more than one MSI interrupt, so you just get one > interrupt with pci_enable_msi(). This would mean MSI or MSI-X ? A bit confused now. • MSI capability - 32 different messages - programmable ID in MSI message data field - programmable TC in MSI message address field - 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: PCIE
Roland Dreier wrote: > > >> Another question would be if the device supports multiple messages, MSIX > > >> should be used ? > > > > > > Yes. Assuming the device supports multiple MSI-X messages. > > At least on my device (PCI ID 1131:7162) there is no MSI-X capability, > so that's not an option for you. The current Linux implementation > does not support more than one MSI interrupt, so you just get one > interrupt with pci_enable_msi(). > > I think it's probably simplest for you to forget about MSI until you > have the basic driver working. Damn. The NXP guys don't want me to go ahead with the generic registers. What they said : > And if you really use the SAA7162 in the PC application, > pls ignore the 0x520 . > That's not a good decision to use that. Might need to ask them why it would not be a good decision then. :-( - 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: PCIE
David Miller wrote: > From: "H. Peter Anvin" <[EMAIL PROTECTED]> > Date: Sat, 26 May 2007 19:34:26 -0700 > >> There are systems which only get a single bit indication that an MSI has >> happened. >> >> Presumably we need something like IRQF_MSI which can be set as >> appropriate depending on the architecture? > > Although I don't want to make the IRQ handling subsystems any more > complicated than they already are, one idea I floated around is that > we could seperate CPU irq numbers (the things we pass around today) > and MSI vector numbers. > > But I immediately understand how that is unnecessary to some extent, > any platform which needs to deal with that kind of distinction can use > virtual IRQ numbers like sparc64 and powerpc do. > > Sparc64 PCI-E controllers, for example, allow you to group several > MSIs into a 'group', and the interrupt source is for the group rather > than the individual MSIs. When the MSI group interrupt arrives, you > get a descriptor in a per-MSI-group ring buffer that describes the MSI > that arrived. > > This descriptor in fact passes on a ton of interesting information, > see arch/sparc64/kernel/pci_sun4v.c:pci_sun4v_msiq_entry. > > It gives you the type, the system TSC value at the time of interrupt > arrival (so you could do incredibly cool profiling with this), > the PCI bus/device/fn that generated the MSI vector, the MSI address > that was signalled, the MSI data field, and full information for PCI-E > MSG packets including bus/dev/fn of target, the message routing code, > and the message code. > > But we use none of these facilities currently because it's either > impossible or too cumbersome to be useful at the moment. > I think it is better to use IRQF_MSI as HPA suggested, since IRQF_SHARED is a bit confusing thing altogether since MSI doesn't share interrupts. - 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: PCIE
Grant Grundler wrote: > On Sun, May 27, 2007 at 05:01:02AM +0400, Manu Abraham wrote: >> David Miller wrote: >>> True, on sparc64 PCI-E controllers, for example, the MSI vector is >>> received by the PCI-E host controller, and the host controller turns >>> this into a cpu format interrupt packet for the system bus. >> Err .. why would a PCIe controller be CPU specific ? Looking at Figure >> 1-6 of the spec, i think it should be CPU independent ? > > To be pedantic, the PCIe controller isn't really CPU specific. > It's host bus specific. ie the PCI-e controller is a bridge between > whatever chipset defines the "cache coherency domain" and the PCI-e devices. > >> Excuse me for my ignorance, just that my head has begun to reel after >> reading through PCIe 1.0 and the device specs, still being inconclusive >> how to proceed. > > no problem...I suspect you need to figure out why DTL-MMIO isn't working. > I have never touched DTL and can't be of much help with that. > Have been reading a bit about DTL and so on. Haven't reached anything much solid yet. Will have something soon i presume. Thanks for the comments. Regards, Manu - 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: PCIE
David Miller wrote: > From: Grant Grundler <[EMAIL PROTECTED]> > Date: Sat, 26 May 2007 18:16:31 -0600 > >> Are they really? The device is generating the transaction on the bus. >> The PCI host controller (in general) will be routing that transaction >> to wherever the "dest addr" of the MSI lives. It doesn't have to be >> in the CPU but it will certainly be a proxy for that CPU if it's not. >> We won't care if the proxy only have one IRQ line going to the CPU >> as long as the de-muxing of the "data" portion results in a unique >> identifier that can be mapped to exactly one interrupt handler. > > True, on sparc64 PCI-E controllers, for example, the MSI vector is > received by the PCI-E host controller, and the host controller turns > this into a cpu format interrupt packet for the system bus. Err .. why would a PCIe controller be CPU specific ? Looking at Figure 1-6 of the spec, i think it should be CPU independent ? Excuse me for my ignorance, just that my head has begun to reel after reading through PCIe 1.0 and the device specs, still being inconclusive how to proceed. - 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: PCIE
David Miller wrote: > From: Manu Abraham <[EMAIL PROTECTED]> > Date: Sat, 26 May 2007 19:03:12 +0400 > >> i presume then i shouldn't be using IRQF_SHARED, if using MSI. > > That's actually a really good question. > > It is likely architecture dependant whether the PCI controller wires > unique MSI interrupts to shared cpu interrupt lines. > > I can imagine many systems where the cpu simply doesn't have enough > interrupt pins to uniquely identify every possible MSI interrupt > source. > Ok, that explains it a bit, but i am pulling out a bit of hair on the other aspects i wrote in this thread, of course i am a bit new to PCIe and hence all my questions/doubts. Hope someone can clear them. Thanks, Manu - 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: PCIE
Grant Grundler wrote: > On Sat, May 26, 2007 at 07:03:12PM +0400, Manu Abraham wrote: >> Roland Dreier wrote: >>> > I am now wondering whether the usage of MSI would help in this case and >>> > that i should be using enable_msi before request_irq ? >>> >>> MSI interrupts are never shared. So if pci_enable_msi() succeeds, you >>> can be sure that the interrupts you get with that IRQ number are >>> coming from your device. >>> >> i presume then i shouldn't be using IRQF_SHARED, if using MSI. > > I'm not sure...but my guess is not. Who ever "just knows", could you > please submit a patch to Documentation/MSI-HOWTO.txt ? did a bit of search in the sources, e1000 does avoid using IRQF_SHARED. tg3 uses IRQF_SAMPLE_RANDOM, don't understand why SAMPLE_RANDOM though. >> Another question would be if the device supports multiple messages, MSIX >> should be used ? > > Yes. Assuming the device supports multiple MSI-X messages. > What i read from the specs: 6.2 Message Signals Interrupts The MSI logic is responsible for generating the MSI messages.MSI is an optional feature in PCI Express that enables a device to request a service by writing a system-specified message to a system-specified address (PCI Express DWORD memory write transaction). The write transaction address specifies the MSI message destination and the write transaction data specifies the message including a message “ID”. During device configuration, system software reads the capability list of the logic core to find out whether it supports MSI, and if yes how many different MSI messages it is requesting. Using the multiple message feature allows an PCI Express device to give different MSI messages a unique message ID (e.g. an MSI message initiated by interrupt source #1 gets a different message ID than an MSI message initiated by interrupt source#2). The max. number of requested MSI messages is 32 and must be aligned to a power of two (1,2,4,8,16, or 32). The core will be configured for 32 requested messages, but optionally the default setting of 32 requested messages can be modified by the BOOT logic immediately after power-on-reset (i.e. before device configuration). After reading the capability list, system software initializes the following parameters: - Multiple Message Enable field Defines the number of allowed messages, which is either all or a subsetof the number of requested messages. For example, a PCI Express device can request 4messages and be allocated either four, two, or one message. The number of messages requested and allocated are aligned to a power of two (a PCI Express device that requires three messages must request four) - MSI message destination address Defines the (physical) message destination address of MSI messages. - MSI message data Defines the message data of MSI messages. The main features of the MSI logic are: • MSI capability - 32 different messages - programmable ID in MSI message data field - programmable TC in MSI message address field • Support for MSI delay timer • Support for the following interrupt sources: - DMA channel tag_ack (“buffer_done”) interrupts (12x) - DMA channel overflow interrupts (12x) - A/V interrupts (8x) - I2C interrupts (2x) - unmapped_tc interrupt (1x) - external interrupts from GPIO (16x) - all interrupts edge sensitive with programmable edge polarity - round-robin arbitration between multiple, simultaneous interrupt requests • Support for interrupt masking (i.e. enable/disable) • Support for INT-A emulation • DTL-MMIO target interface for SW access - 4Kbyte address aperture (12bit address / 32bit aligned) - 32bit read and write data >> In such a context, if i request for say more than the messages that i >> need, say i request 16 messages, but use only 1 or 2, that does bear any >> consequences ? > > Yes. One is allocating IRQ vectors from a finite number of vectors. > But this normally isn't a problem until one gets to larger machines that > have more than 4-8 PCI-e or PCI-X slots. Ok. Alongwith this, i am a bit confused with the mailbox approach of sending messages, every register type has it's own set of interrupt registers (for example I2C, say I2C has it's own set of 32 STATUS bitfields for it's interrupt, the same goes for the others) Another aspect is the DTL-MMIO interface, which isn't defined any place. Using the base addresses as an offset to the normal MMIO obtained using pci_resource_*/ioremap() doesn't seem to work at all. Seems like it needs some kind of a translation (guessing here, still no clue yet) The device supports 50 MSI interrupt sources Somewhere else it mentions thus: 6.4Global Register (GREG) The logic provides a set of global registers there are accessible via a device transaction level protocol memory mapped input output interface. Primarily,
Re: PCIE
Roland Dreier wrote: > > I am now wondering whether the usage of MSI would help in this case and > > that i should be using enable_msi before request_irq ? > > MSI interrupts are never shared. So if pci_enable_msi() succeeds, you > can be sure that the interrupts you get with that IRQ number are > coming from your device. > i presume then i shouldn't be using IRQF_SHARED, if using MSI. Another question would be if the device supports multiple messages, MSIX should be used ? In such a context, if i request for say more than the messages that i need, say i request 16 messages, but use only 1 or 2, that does bear any consequences ? > But using MSI does not work on all systems, so your driver needs to > work with standard (possibly shared) INTx interrupts too. And you > should probably provide at least a module flag to disable the use of > MSI, to avoid problems on buggy systems. I should probably look for CONFIG_PCI_MSI and check whether the system supports MSI pci_enable_msi() ? - 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: PCIE
Roland Dreier wrote: > Why does the device come up in a state where it generates a stream of > interrupts as soon as you enable the PCI device? That's somewhat > unusual behavior, although certainly not unheard of. > In fact the device wasn't generating a stream of interrupts when loaded (i guess). It was just that the shared handler was showing all the interrupts that occurred, since i was not looking at the interrupt mask/status. But accessing any registers caused me a flood of interrupts, which froze the system. excessive printing to the console caused a lockup. I am now wondering whether the usage of MSI would help in this case and that i should be using enable_msi before request_irq ? - 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: PCIE
Roland Dreier wrote: > > It looks so, from the logs. The only problem is i can't disable the > > interrupts, if i write "0" to 0x500, the interrupt/enable register, it > > gives me a solid freeze. If i read from the handler, commenting out the > > disable interrupts in init, that read also gives me a solid freeze. This > > lead me to think that there could be some problem with the MMIO block > > access. > > OK, this looks reasonable: > > > #define saa716x_write(dat, addr) writel((dat), (saa716x->mmio)+(addr)) > > although > > a) your driver has no hope of working on a system with more than one > device of this type; and to make it working with more than one device shouldn't be hard once it is going on. > b) there's really no point in obfuscating a simple use of writel() > this way. > > Why does the device come up in a state where it generates a stream of > interrupts as soon as you enable the PCI device? That's somewhat > unusual behavior, although certainly not unheard of. Will ask the vendor, what's going on. > This really has the feel of a typical driver bug to me, not anything > related to general PCIe access. I've definitely wedged my system many > times while trying to poke a device the right way. Yeah, you seem to sound right. > Also, where are you getting the offset of 0x500 from? The register offset is according to the device specs. Of course i already found some wrong offsets etc, maybe this one's wrong too, probably. > Is it possible > that the offset is really being given to you in bits (so you should > use 0x500 / 8) or 32-bit words (so you should use an offset of 0x500 * It says, the base address is currently 500h > 4)? Are the datasheet / programming docs available for this device? Working with this device, under NDA with the vendor. > I actually have: > > 02:00.0 Multimedia controller: Philips Semiconductors Unknown device 7162 > > in one of my systems so I'd be somewhat interested in getting a driver > working too. Cool, won't be that long, just the bridge part remains, most other parts are done or do exist. Thanks, Manu - 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: PCIE
Roland Dreier wrote:
> > If i uncomment the saa716x_read or write, what i get is a solid freeze
> > on module load. If i leave it commented out, the module loads fine.
>
> That sounds like a typical bug during driver development... you're
> probably wedging the hardware by doing the wrong access.
>
> I didn't see the source for saa716x_read or write in the code you
> posted, so it's hard to say if there's a problem with them.
>
Attaching saa716x_read/write in saa716x_priv.h
> Is your interrupt handler getting called? Is the device generating
> interrupts?
It looks so, from the logs. The only problem is i can't disable the
interrupts, if i write "0" to 0x500, the interrupt/enable register, it
gives me a solid freeze. If i read from the handler, commenting out the
disable interrupts in init, that read also gives me a solid freeze. This
lead me to think that there could be some problem with the MMIO block
access.
May 23 03:25:48 manu-04 kernel: [ 383.602737] saa716x_pci_init: found a
Twinhan VP-6090 device
May 23 03:25:48 manu-04 kernel: [ 383.602764] ACPI: PCI Interrupt
:06:00.0[A] -> GSI 16 (level, low) -> IRQ 16
May 23 03:25:48 manu-04 kernel: [ 383.603020] SAA7160/1/2 Rev 1
[1822:0027], irq: 16, latency: 0
May 23 03:25:48 manu-04 kernel: [ 383.603024] memory: 0x3220,
mmio: 0xe046e000
May 23 03:25:48 manu-04 kernel: [ 383.610761] === Interrupts[0010] [] ==
May 23 03:25:48 manu-04 kernel: [ 383.624056] === Interrupts[0010] [] ==
May 23 03:25:48 manu-04 kernel: [ 383.637348] === Interrupts[0010] [] ==
May 23 03:25:48 manu-04 kernel: [ 383.650650] === Interrupts[0010] [] ==
May 23 03:25:48 manu-04 kernel: [ 383.663951] === Interrupts[0010] [] ==
May 23 03:25:48 manu-04 kernel: [ 383.677253] === Interrupts[0010] [] ==
May 23 03:25:48 manu-04 kernel: [ 383.690554] === Interrupts[0010] [] ==
May 23 03:25:48 manu-04 kernel: [ 383.703858] === Interrupts[0010] [] ==
May 23 03:25:48 manu-04 kernel: [ 383.717156] === Interrupts[0010] [] ==
May 23 03:25:48 manu-04 kernel: [ 383.730459] === Interrupts[0010] [] ==
May 23 03:25:48 manu-04 kernel: [ 383.743760] === Interrupts[0010] [] ==
May 23 03:25:48 manu-04 kernel: [ 383.757064] === Interrupts[0010] [] ==
May 23 03:25:48 manu-04 kernel: [ 383.770364] === Interrupts[0010] [] ==
May 23 03:25:48 manu-04 kernel: [ 383.783665] === Interrupts[0010] [] ==
May 23 03:25:48 manu-04 kernel: [ 383.796966] === Interrupts[0010] [] ==
May 23 03:25:48 manu-04 kernel: [ 383.810269] === Interrupts[0010] [] ==
May 23 03:25:48 manu-04 kernel: [ 383.823569] === Interrupts[0010] [] ==
>
> > That part is then fine. Does MSI require any special tinkering ?
>
> Just pci_enable_msi() as usual.
Thanks
Regards,
Manu
#ifndef __SAA716x_PRIV_H
#define __SAA716x_PRIV_H
#include
#include
#include
#include
#include "dvbdev.h"
#include "dvb_demux.h"
#include "dmxdev.h"
#include "dvb_frontend.h"
#include "dvb_net.h"
#define SAA716x_ERROR 0
#define SAA716x_NOTICE 1
#define SAA716x_INFO2
#define SAA716x_DEBUG 3
#define dprintk(x, y, z, format, arg...) do {
\
if (z) {
\
if ((x > SAA716x_ERROR) && (x > y))
\
printk(KERN_ERR "%s (%d): " format "\n", __func__,
saa716x->num, ##arg);\
else if ((x > SAA716x_NOTICE) && (x > y))
\
printk(KERN_ERR "%s (%d): " format "\n", __func__,
saa716x->num, ##arg);\
else if ((x > SAA716x_INFO) && (x > y))
\
printk(KERN_ERR "%s (%d): " format "\n", __func__,
saa716x->num, ##arg);\
else if ((x > SAA716x_DEBUG) && (x > y))
\
printk(KERN_ERR "%s (%d): " format "\n", __func__,
saa716x->num, ##arg);\
} else {
\
if (x > y)
\
printk(format, ##arg);
\
}
\
} while (0);
#define MAKE_ENTRY(subven, subdev, configptr) { \
.vendor = 0x1131, \
.device = 0x7162, \
.subvendor = (subven), \
.subdevice = (subdev), \
.driver_data= (unsigned long) (configptr) \
}
#define saa716x_write(dat, addr)writel((dat), (saa716x->mmio)+(addr))
#define saa716x_
Re: PCIE
Roland Dreier wrote:
>>> Uncompressing Linux .. Ok, booting the kernel.
>>> BIOS bug, no explicit IRQ entries, using default mptable. (tell your hw
>>> vendor)
>>> PCI: Failed to allocate mem resource #6:[EMAIL PROTECTED] for :01:00.0
>
> This message is about device 01:00.0 as it says (your nvidia video
> card based on later lspci output).
>
> > The device is a new DTV bridge from NXP (SAA7162E) with a PCIe interface.
> >
> > 06:00.0 Multimedia controller: Philips Semiconductors Unknown device
> > 7162 (rev 01)
> > Subsystem: Twinhan Technology Co. Ltd Unknown device 0027
>
> This is device 06:00.0, so it's not related to that earlier message at
> all. You didn't say what problem you're having with your driver for
> this device...
If i uncomment the saa716x_read or write, what i get is a solid freeze
on module load. If i leave it commented out, the module loads fine.
static irqreturn_t saa716x_pcie_irq(int irq, void *dev_id)
{
struct saa716x *saa716x;
u32 stat, mask;
if (unlikely((saa716x = (struct saa716x *) dev_id) == NULL)) {
printk(KERN_ERR "%s: Aeie NULL ptr\n", __func__);
return IRQ_NONE;
}
// stat = saa716x_read(0x500);
dprintk(verbose, SAA716x_DEBUG, 0, "=== Interrupts[%04x] [", stat);
dprintk(verbose, SAA716x_DEBUG, 0, "] ==\n");
return IRQ_HANDLED;
}
int saa716x_pcie_init(struct saa716x *saa716x)
{
struct pci_dev *pdev = saa716x->pdev;
int err = 0;
u8 latency, revision;
printk(KERN_INFO "%s: found a %s device\n", __func__,
saa716x->hwconfig->model_name);
pci_set_drvdata(pdev, saa716x);
if ((err = pci_enable_device(pdev)) != 0) {
printk(KERN_ERR "%s ERROR: pci enable failed (%i)\n", __func__,
err);
goto fail0;
}
if (request_mem_region(pci_resource_start(pdev, 0),
pci_resource_len(pdev, 0), DRIVER_NAME) == NULL)
{
printk(KERN_ERR "%s ERROR: mem region request failed\n",
__func__);
err = -ENOMEM;
goto fail1;
}
saa716x->mmio = ioremap(pci_resource_start(pdev, 0), 0x1000); // FIXME:
check this size
if ((err = request_irq(pdev->irq, saa716x_pcie_irq, IRQF_SHARED |
IRQF_DISABLED,
DRIVER_NAME, (void *) saa716x)) != 0) {
printk(KERN_ERR "%s ERROR: irq request failed (%i)\n", err,
__func__);
goto fail2;
}
pci_set_master(pdev);
pci_read_config_byte(pdev, PCI_LATENCY_TIMER, &latency);
pci_read_config_byte(pdev, PCI_CLASS_REVISION, &revision);
dprintk(verbose, SAA716x_ERROR, 0, " SAA7160/1/2 Rev %d
[%04x:%04x], ",
revision,
saa716x->pdev->subsystem_vendor,
saa716x->pdev->subsystem_device);
dprintk(verbose, SAA716x_ERROR, 0,
"irq: %d, latency: %d\n memory: 0x%04x, mmio: 0x%p\n",
saa716x->pdev->irq, latency, pci_resource_start(pdev, 0),
saa716x->mmio);
saa716x->verbose = verbose;
// init_waitqueue_head(&saa716x->i2c_queue);
/* Disable all interrupts here */
// saa716x_write(0, 0x500);
return 0;
fail2:
iounmap(saa716x->mmio);
release_mem_region(pci_resource_start(saa716x->pdev, 0),
pci_resource_len(saa716x->pdev, 0));
fail1:
pci_disable_device(pdev);
fail0:
pci_set_drvdata(pdev, NULL);
return err;
}
EXPORT_SYMBOL_GPL(saa716x_pcie_init);
> but all standard PCI stuff should work fine for PCIe
> devices -- the normal PCI driver stuff is all you should need for
> everything but exotic cases.
That part is then fine. Does MSI require any special tinkering ?
Thanks,
Manu
-
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/
PCIE
Hi, Do the PCI Express chipsets also use the same PCI API ? The device specifications are thus for the device that i am looking at: PCI Express interface * Compliant to PCI Express Base Specification 1.0a * The PCI Express circuit supports isochronous data traffic intended for uninterrupted transfer of streaming data like video streaming o x1 PCI Express endpoint (2.5 Gbit/s) o Data and clock recovery from serial stream o Low jitter and BER * Type 0 configuration space header o 64-bit addressing o Single BAR; programmable address range of 17 bits, 18 bits, 19 bits or 20 bits dependent on application requirements * PCI Express capabilities o 128 bytes write packet size and 64 bytes read packet size o MSI support o Software directed power management of four device power states (D0 to D3) o Active state power management of link states o Vendor specific capability for VC1 support; after reset VC1 isochronous capability is disabled I have been trying the said card with a normal PCI style driver, but while booting the kernel (2.6.21.1) i do get a message like this (an Intel DP965LT motherboard with BIOS version: MQ96510J.86A.1612.2006.1227.1513) Also accessing the interrupt registers causes a hard freeze, for which only the RESET button seems to be of any help. Uncompressing Linux .. Ok, booting the kernel. BIOS bug, no explicit IRQ entries, using default mptable. (tell your hw vendor) PCI: Failed to allocate mem resource #6:[EMAIL PROTECTED] for :01:00.0 Any ideas as to what could be wrong ? Thanks, Manu - 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: pci probe
Greg KH wrote: > On Tue, May 15, 2007 at 05:15:28PM +0400, Manu Abraham wrote: >> Manu Abraham wrote: >>> Hi, >>> >>> I do have a device that's a multifunction device. Eventhough a MFD, it >>> just has one Interrupt which is shared by by a Configuration space for >>> each function. ie, INTA is shared between them functions. >>> >>> In such a case, i am wondering, (since pci_probe returns a pointer to >>> one PCI function alone and i need to use both the functions in one >>> module alone rather than using a module for each function and that the >>> functions are quite similar for them to be used in different modules, >>> such that a separate probe/ISR etc is used) whether using pci_get_device >>> would be a better alternative to do manual searching for the functions >>> in such a case. >>> >> Just figured out that pci_get_subsys() does work in a better. Looking at >> kernel sources all i find is just one single user of pci_get_subsys() >> >> building the code around pci_get_subsys(), does this have any negative >> impact ? > > Yes: > - your device will not show up properly in sysfs (no > device/driver binding ability from userspace, no good > information so that udev can properly name the device, etc.) This one sounds bad. > - your driver will not work on any pci-hotplug type system (that > includes expresscard and pccard and lots of high-end servers. This doesn't matter > - your driver will not be notified if the system is being > suspended or resumed or wanting to drop into a low power > state. > - another driver can bind to your device without you ever > knowing it. These also sound bad. > So in short, use pci_probe and just handle the fact that you need to be > called for two PCI devices and bind to both of them. It shouldn't be > that hard... Thanks for the explanation. Do you mean to have two PCIID tables ? But then that does mean 2 modules don't you ? (i thought probe would be called once per module) Or you mean to say use PCI_ANY_ID in the table to match multiple devices and then allow probe to return a list of devices ? Thanks, Manu - 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] em28xx and ivtv should depend on PCI
Al Viro wrote: > Signed-off-by: Al Viro <[EMAIL PROTECTED]> > --- > drivers/media/video/em28xx/Kconfig |2 +- > drivers/media/video/ivtv/Kconfig |2 +- > 2 files changed, 2 insertions(+), 2 deletions(-) > > diff --git a/drivers/media/video/em28xx/Kconfig > b/drivers/media/video/em28xx/Kconfig > index 3823b62..2c450bd 100644 > --- a/drivers/media/video/em28xx/Kconfig > +++ b/drivers/media/video/em28xx/Kconfig > @@ -1,6 +1,6 @@ > config VIDEO_EM28XX > tristate "Empia EM2800/2820/2840 USB video capture support" > - depends on VIDEO_V4L1 && I2C > + depends on VIDEO_V4L1 && I2C && PCI Err .. why would a USB device need to be depend on PCI ? - 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: pci probe
Manu Abraham wrote: > Hi, > > I do have a device that's a multifunction device. Eventhough a MFD, it > just has one Interrupt which is shared by by a Configuration space for > each function. ie, INTA is shared between them functions. > > In such a case, i am wondering, (since pci_probe returns a pointer to > one PCI function alone and i need to use both the functions in one > module alone rather than using a module for each function and that the > functions are quite similar for them to be used in different modules, > such that a separate probe/ISR etc is used) whether using pci_get_device > would be a better alternative to do manual searching for the functions > in such a case. > Just figured out that pci_get_subsys() does work in a better. Looking at kernel sources all i find is just one single user of pci_get_subsys() building the code around pci_get_subsys(), does this have any negative impact ? Thanks, Manu - 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/
pci probe
Hi, I do have a device that's a multifunction device. Eventhough a MFD, it just has one Interrupt which is shared by by a Configuration space for each function. ie, INTA is shared between them functions. In such a case, i am wondering, (since pci_probe returns a pointer to one PCI function alone and i need to use both the functions in one module alone rather than using a module for each function and that the functions are quite similar for them to be used in different modules, such that a separate probe/ISR etc is used) whether using pci_get_device would be a better alternative to do manual searching for the functions in such a case. Thanks, Manu - 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 ...)
Trent Piepho wrote: > This is not correct. The dvb_attach() system has no assumption that it will > be used for a front-end device. There are already users which are not > front-ends, such as tuners or lnb supply control chips, SEC (aka Satellite Equipment Control) is a part of the frontend. > > So as maintainer you are declaring that no changes of any kind are permitted? Please do take a look at the changesets whether it is as you say. - 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 ...)
Michael Krufky wrote: > Manu Abraham wrote: >> Mauro Carvalho Chehab wrote: >>> Hi Manu, >>> >>>> From my side, quite some time has been put forward to write that mail. >>>> Inspite of that if you feel that you do have to go your own way, then >>>> it is completely upto you. I would say: do as you feel in such a case. >>> The point is that those issues are pending for a long time, and they >>> should be solved, especially the module removal issue (*) >>> >>> If you are so afraid about applying those changes, maybe the better is >>> to apply those patches at v4l-dvb tree and at -mm, asking people to >>> test. >>> >>> We may hold their commit on kernel mainstream until the next kernel >>> release, if nobody complains about, or otherwise revert the changes, if >>> they proofed to cause troubles at dst and/or dvb-bt8xx. >>> >>> Also, you (or others) may write another approach keeping the fixes with >>> an strategy more adequate for dst. >>> >>> Do you agree with this way? >> NACK >> >>> -- >>> Cheers, >>> Mauro >>> >>> (*) Currently, dst can be removed only with "rmmod -f", due to a wrong >>> usage count. With Trent's patches, this were fixed. >> http://article.gmane.org/gmane.linux.drivers.dvb/27792/match=re+linux+dvb+unable+rmmod+dst+bt8xx > > Just to make things clear, Manu, Are you telling us that the patch in the > above > link addresses the use count bug? > Yes > If that is the case, are you suggesting that that patch be applied to the > repository instead of Trent's changesets? > Yes > Moreso, if that is the case, then the patch in the above link lacks a > sign-off... We need to apply SOMETHING to fix this problem, and you know the > rules... > Signed-off-by: Manu Abraham <[EMAIL PROTECTED]> > What should be done to fix the use count bug? > It does fix, AFAIR Regards, Manu - 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 ...)
Mauro Carvalho Chehab wrote: > Hi Manu, > >> From my side, quite some time has been put forward to write that mail. >> Inspite of that if you feel that you do have to go your own way, then >> it is completely upto you. I would say: do as you feel in such a case. > > The point is that those issues are pending for a long time, and they > should be solved, especially the module removal issue (*) > > If you are so afraid about applying those changes, maybe the better is > to apply those patches at v4l-dvb tree and at -mm, asking people to > test. > > We may hold their commit on kernel mainstream until the next kernel > release, if nobody complains about, or otherwise revert the changes, if > they proofed to cause troubles at dst and/or dvb-bt8xx. > > Also, you (or others) may write another approach keeping the fixes with > an strategy more adequate for dst. > > Do you agree with this way? NACK > > -- > Cheers, > Mauro > > (*) Currently, dst can be removed only with "rmmod -f", due to a wrong > usage count. With Trent's patches, this were fixed. http://article.gmane.org/gmane.linux.drivers.dvb/27792/match=re+linux+dvb+unable+rmmod+dst+bt8xx - 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 ...)
Hello Mauro, Mauro Carvalho Chehab wrote: > Hi Manu, > > Em Qui, 2007-05-03 às 23:03 +0400, Manu Abraham escreveu: >> Mauro Carvalho Chehab wrote: >>> Enough. Let's stop arguing non technical issues. >>> >>> If either one of you have any technical argue against the Trent's >>> patches, please point where the fix is wrong. Otherwise, if you wish, >>> you may send an acked-by agreeing with the fix. >>> >> Why don't you stop this childish behaviour ? > > I just want to solve the current issue, and decide the proper way for Trent's > fixes. > > I consider you a very skilled programmer. Unfortunately, it seems that > you're not interested anymore on submitting kernel patches, since your > last contribution, as an author, were back on Aug, 8, 2006: hmm .. multiple Caps "I 's" .. anyway. >From my side, quite some time has been put forward to write that mail. Inspite of that if you feel that you do have to go your own way, then it is completely upto you. I would say: do as you feel in such a case. In such a case are you willing to fix all the issues/requests that surface ? Really do you want me to explain those issues in this thread ? I would say, think over it yourself, why that huge gap occurred. Take some time off all this, think on a cool mind. > > commit bbdd11fa957913d6648cabbca59be1da479180ed > Author: Manu Abraham <[EMAIL PROTECTED]> > Date: Tue Aug 8 15:48:08 2006 -0300 > > V4L/DVB (4432): Fix Circular dependencies > > Signed-off-by: Manu Abraham <[EMAIL PROTECTED]> > Signed-off-by: Mauro Carvalho Chehab <[EMAIL PROTECTED]> > > It would be a pleasure to have you contributing again. However, we need to > fix the pointed issues. I do have a written another mail with regards to the issues that do prevail on the "discussions thread" > > Also, considering that: > > 1) the Trent patches addressing the issues exists since august, 2006; > > 2) nobody pointed any troubles at the current approach; > Surely there was a long mail from my side. I don't know whether you missed that mail, but surely you should read it again. > 3) the patch does provide a proper fix for module removal, working well on > both hardwares with and without DST; > Other than what i wrote earlier: DST is not for just one device alone (It is really a combo driver), AFAICS there are ~15 -20 main devices, for which there are additional 5 - 6 clone manufacturers. So eventually there are around 80 different cards at least. So, in fact there are a large number of cards that do exist rather than the one card that i have sent you, some time back. The non dst cards supported by dvb-bt8xx are just 3 or 4 cards, IIRC. > 4) I'm responsible for reviewing and forwarding patches for /drivers/media > stuff; > > I think there's no reason for me to not forward the proper fixes to > mainstream. > >From what i know, you do need an ACK from the relevant maintainer too. Did the concept of dvb-maintainers change without any of the DVB developers knowing ? - 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 ...)
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." Original Message Subject: Re: [linux-dvb] Re: Critical points about kernel 2.6.21and pseudo-authorities Date: Tue, 01 May 2007 04:19:41 +0400 From: Manu Abraham <[EMAIL PROTECTED]> To: Uwe Bugla <[EMAIL PROTECTED]> CC: [EMAIL PROTECTED], [EMAIL PROTECTED], linux-kernel@vger.kernel.org, [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] References: <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED] <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> Uwe Bugla wrote: > 1. You utmost personally are responsible for 4 ununsable kernels, as far as bt8xx cards are concerned: 2.6.13, 2.6.14, 2.6.15, 2.6.16! > 2. You did not even want to imply to resolve that issue by incarnating that "community and synergy principle" that linux community needs to exist at all, but you just perverted it by flaming capable people - You mean like this: Original Message Subject: kernel patch practice in 2.6.13-mm2 Date: Tue, 13 Sep 2005 16:46:35 +0200 (MEST) From: Uwe Bugla <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] CC: [EMAIL PROTECTED] Hi, if you continue to send or sign mm-patches for Kernel 2.6.13 as a consequence of a design change I would appreciate you to stop rubbing out my name. You did that in a file called /Documentation/dvb/bt8xx.txt. My objective is understandable good documentation, even if it may sound trivial for some developpers minds. I always have in mind that there are also lots of beginners reading those documents. As I respect your work I never in my life would even dare to rub out other coauthors names. That´s why I appreciate you to respect my name and stop rubbing it out. Thanks Uwe Bugla P. S.: If you f. ex. publish a book I ain´t gonna burn it as a matter of disrespect. So have a little respect vice versa! -- Lust, ein paar Euro nebenbei zu verdienen? Ohne Kosten, ohne Risiko! Satte Provisionen für GMX Partner: http://www.gmx.net/de/go/partner --- Original Message Subject: "synchronization problems" Date: Thu, 15 Sep 2005 10:44:38 +0200 (MEST) From: Uwe Bugla <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] CC: [EMAIL PROTECTED] Hallo Mr. Stezenbach, "You breached the protocol by not sending the patches to the maintainer or linux-dvb list. The result of this was that we had conflicting changes in CVS. I spent about 10 minutes thinking how I could merge the two, and then gave up (I had 53 other patches to prepare and I had little time left to do the job). So I didn't just remove your name, but all changes which you sent to akpm along with it. bt8xx.txt in the kernel is now in sync with the version in linuxtv.org CVS." I didn't breach any protocol, nor did I break any unwritten rule or law. I simply took the advice from Gerd Knorr that linuxtv maintainers were just moving to another place to the point of time when I sent in my first dvb-bt8xx-patch. So consequently I took the direct way to send it to akpm. Just to be sure it is really being applied without waiting 3, 4 weeks or however long. So if you continue to at least discussing with my person, please immediately stop doing that in such a bureaucratic manner. If synchronization of CVS and kernel.org only works unidirectional, and not bidirectional, then neither I, nor akpm, nor Manu or anybody else has a real problem, but you personally have one without any doubts. And if you lack time, simply delegate your job to another person. But simply stop rubbing out other peoples coauthorship and pay respect to their contributions. And the biggest joke about your personal misbehaviour is the fact that you personally cosigned at least one of my patch attempts, without dropping me a single note asking me to not bypass the linuxtv CVS maintainers. So good morning Mr. Stezenbach, I appreciate you to wake up a little bit earlier in the future! "Additionally you deleted information from bt8xx.txt which I think were useful help for debugging problems, and which were written there on purpose by the developer. So if you talk about respect, you could show some yourself by not bypassing the original authors and maintainers when sending patches." In fact I did, and I can tell you the simple reasons why. There are in fact two things that I simply cannot and will not tolerate: a. orthographic junk (examples: "bythe" or, even worse:
Re: [linux-dvb] DST/BT878 module customization (.. was: Critical points about ...)
Markus Rechberger wrote: > On 5/3/07, Manu Abraham <[EMAIL PROTECTED]> wrote: >> Mauro Carvalho Chehab wrote: >> > Enough. Let's stop arguing non technical issues. >> > >> > If either one of you have any technical argue against the Trent's >> > patches, please point where the fix is wrong. Otherwise, if you wish, >> > you may send an acked-by agreeing with the fix. >> > >> >> Why don't you stop this childish behaviour ? >> >> After explaining to you the reasons in the previous mail: >> being the author and maintainer of dst/dst_ca and maintainer of >> dvb-bt8xx, i NACK this change >> >> (1) You aren't DVB maintainer > > I've seen that too often already, now we could point to a mail someone > sent to Uwe regarding maintainership. FYI, I have never written to Uwe regarding any sort of maintainership. You seem to be quite up with an overdose of drugs >From 2005/09/13 - 2007/05/03 (till date) there have been 15 mails from my side to Uwe, none of which has a topic whatsoever you say. Only the first mail was a private mail and that is CC'd to Johannes as well. Firstly you seem to play politics by getting Uwe to flame me, then when it backfired, you are trying to play tricks with the rest of the community as well, by spreading nonsense statements. Great! - 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 ...)
Mauro Carvalho Chehab wrote: > Enough. Let's stop arguing non technical issues. > > If either one of you have any technical argue against the Trent's > patches, please point where the fix is wrong. Otherwise, if you wish, > you may send an acked-by agreeing with the fix. > Why don't you stop this childish behaviour ? After explaining to you the reasons in the previous mail: being the author and maintainer of dst/dst_ca and maintainer of dvb-bt8xx, i NACK this change (1) You aren't DVB maintainer (2) one shouldn't make such judgement calls on somebody else's driver unless it falls within your own maintainership > Mauro. > > Em Qui, 2007-05-03 às 19:19 +0200, Markus Rechberger escreveu: >> On 5/3/07, Manu Abraham <[EMAIL PROTECTED]> wrote: >>> Markus Rechberger wrote: >>> >>>> Manu, >>>> >>>> to me it looks like your attitude is not acceptable here, I sent >>>> several mails already which you just use to ignore. >>> You very well know the reason why i am ignoring your mails. You just >>> tend to flame people for nothing. I tend to ignore the flamers. >>> >> You should stop to rely on the history, since such a flame needs at >> least 2 parties and back then you were also involved. There's nothing >> else to say about that. >> >>>> If you don't change that attitude immediatelly I'd really wish to get >>>> you banned of this community until you're open for discussions. >>>> >>>> http://www.mail-archive.com/linux-dvb%40linuxtv.org/msg22943.html >>>> >>>> there's a bugreport and you fully ignore it, and you blame it on the >>>> "politicians" here, telling me that there are mails out there >>>> somewhere shows that you're not interested in getting forward. >>>> >>> That bug report very well proves my point. >> Well it would be nice if you could answer the question in that mail >> then, I don't see any reason why you shouldn't answer it. >> >> It's just a guess, but it seems like that you had a problem with other >> developers at that part and it seems like it didn't get to an end >> (probably because both parties didn't agree with each other) >> >> Markus >> - >> 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/ - 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 ...)
Michael Krufky wrote: > Manu Abraham wrote: >> Uwe Bugla wrote: >> >>> If you download the thing as tar.bz2 you get a zero file down. >>> >> I think could be a bug in hgweb probably. > [snip] >> Let me see why hgweb gives a zero length archive >> > Manu, > > We reported this bug to the selenic guys quite a long time ago... You > should inherit the fix if you upgrade mercurial on your server. > Cool. Thanks. I think it is a newer version .. [EMAIL PROTECTED] ~]$ hg --version Mercurial Distributed SCM (version 0.9) Copyright (C) 2005 Matt Mackall <[EMAIL PROTECTED]> This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. You have an account on that machine. Would you like to take a look ? - 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 ...)
Markus Rechberger wrote: > Manu, > > to me it looks like your attitude is not acceptable here, I sent > several mails already which you just use to ignore. You very well know the reason why i am ignoring your mails. You just tend to flame people for nothing. I tend to ignore the flamers. > If you don't change that attitude immediatelly I'd really wish to get > you banned of this community until you're open for discussions. > > http://www.mail-archive.com/linux-dvb%40linuxtv.org/msg22943.html > > there's a bugreport and you fully ignore it, and you blame it on the > "politicians" here, telling me that there are mails out there > somewhere shows that you're not interested in getting forward. > That bug report very well proves my point. > I'm waiting for your response here. > > Markus > >> > Waiting for your link meanwhile to download that hopeful project... >> >> http://thadathil.net:8000/cgi-bin/hgwebdir.cgi/cx878_41?ca=43abfe89c2c9;type=bz2 >> >> > > - 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 ...)
Uwe Bugla wrote: > Original-Nachricht > Datum: Thu, 03 May 2007 19:48:50 +0400 > Von: Manu Abraham <[EMAIL PROTECTED]> > An: Uwe Bugla <[EMAIL PROTECTED]> > CC: [EMAIL PROTECTED], linux-kernel@vger.kernel.org, [EMAIL PROTECTED], > [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] > Betreff: Re: [linux-dvb] DST/BT878 module customization (.. was: Critical > points about ...) > >> Uwe Bugla wrote: >> >>> Hi Manu, >>> >>> But it would be an acceptable compromise FOR NOW, wouldn't it? >> >> The reason is i do not wish to make changes to it, till i can fix it. It >> is indeed hard to fix things that support a lot of devices, with >> different issues. There are enough of issues in there. >> >> You can look at all those frontend not found issues on the DVB ML. >> >> The people who make all these noise, do nothing but just play politics. >> Just do a search on the linux-dvb ML at gmane.org. You can easily find >> them. >> >>> Waiting for your link meanwhile to download that hopeful project... >> http://thadathil.net:8000/cgi-bin/hgwebdir.cgi/cx878_41?ca=43abfe89c2c9;type=bz2 > > Sorry Manu, > > incorrect link! > Why? > > If you download the thing as tar.bz2 you get a zero file down. I think could be a bug in hgweb probably. > > However, if you download the thing as tar.gz you will succeed in getting it. > Ok. The gzip archive should be as good as the bzip archive, just that it is slightly larger. > I'll sit down this evening, try to make changes to imply it into the actual > mercurial tree, produce necessary patches and give you a bug report as far as > the compilation errors are concerned. > > I am really looking forward to see this fantastic thing finished > It's worth it for a thousands of very good reasons, not only RAM > optimization, but also stability and many many others... > > So gimme some time, and perhaps please supply a tar.bz2 version if you can, > or fix the download error (zero file) if there is any other reason that I > cannot see. > Let me see why hgweb gives a zero length archive - 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 ...)
Uwe Bugla wrote: > Hi Manu, > > But it would be an acceptable compromise FOR NOW, wouldn't it? The reason is i do not wish to make changes to it, till i can fix it. It is indeed hard to fix things that support a lot of devices, with different issues. There are enough of issues in there. You can look at all those frontend not found issues on the DVB ML. The people who make all these noise, do nothing but just play politics. Just do a search on the linux-dvb ML at gmane.org. You can easily find them. > Waiting for your link meanwhile to download that hopeful project... http://thadathil.net:8000/cgi-bin/hgwebdir.cgi/cx878_41?ca=43abfe89c2c9;type=bz2 - 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: DST/BT878 module customization (.. was: Critical points about ...)
Mauro Carvalho Chehab wrote: > Em Qua, 2007-05-02 às 04:10 -0700, Trent Piepho escreveu: >> On Tue, 1 May 2007, Mauro Carvalho Chehab wrote: > >>> However, when dst is selected, I got those errors: >> When I made this patch I was basing it off a patch I made around 9 months >> ago. I thought since that one was ok, this would be ok too, and in my >> hurry to get it done I've clearly put too little effort into checking it, >> and I'm sorry to have wasted your time. >> >> I promise, this time it's right! >> http://linuxtv.org/hg/~tap/dst-new > > Confirmed. Now the patch is properly working. My tests were done with a > board with DST. Those are the results: > > 1) when DST is unselected, on a board with DST, it will print the errors > indicating that the Kconfig items were not selected: > > DVB: registering new adapter (bttv0). > DVB: Unable to find symbol dst_attach() > frontend_init: Could not find a Twinhan DST. > dvb-bt8xx: A frontend driver was not found for device 109e/0878 subsystem > fbfb/f800 > > The only issue is the wrong printk msg, stating that a "frontend driver" > were not found. As this issue also happens with the current driver, due > the usage of dvb_attach() macro, I don't see any regressions. > > It would be nice, however, to have a patch making dvb_attach more > generic, by e.g. having a variant that allows passing another message. > > Trying to run dvb programs like scan and kaffeine will properly fail. > > 2) With DST selected, the driver works properly. > > The changes also solved the issue of removing the dst drivers. Before > the patch, sometimes it is required to force removal of dst module with > the '-f' flag, since the module count were wrong. > > --- > > I'll risk to make a briefing of the technical points: > > > Current issues: > 1) allow deselecting DST/DST_CA support, since this is not needed by > some supported boards; > 2) sometimes, module removal don't work with dst, since usage count > becomes wrong; > 3) if dst or dst_ca is not properly loaded, the printk message wrongly > indicates that "A frontend driver was not found" > > The Trent's original patch were written on Aug, 2006 (*). The current > version fixes (1) and (2). It doesn't touch on (3). There aren't any > other patches properly fixing (1) and (2). > > There's an argument against the prototype changes on dst_attach and > dst_ca_attach since they aren't frontend. > > > (*) Notice: I can't remember why the patches were not applied on that > time. I think somebody nacked they, although I didn't found any record > about the patch on my mailbox. > > About the usage of frontend support for a non-frontend module, I really > can't see any issues at the current implementation, since even before > the patch, all DST initialization are done by a routine called > "frontend_init()". *Wrong*. Frontend Init sends a command to the whole system to initialize the frontend, Not initialize the DST Whatever frontend naming conventions are in there are a relic from Andrew's FE_REFACTORING changesets. Even dst not being a frontend, the initialization > gets the result of the attachment process, using it as a "frontend": > > state = kmalloc(sizeof (struct dst_state), GFP_KERNEL); > > state->config = &dst_config; > state->i2c = card->i2c_adapter; > state->bt = card->bt; > state->dst_ca = NULL; > > dvb_attach(dst_attach, state, &card->dvb_adapter); > > card->fe = &state->frontend; > > (comments and error checks removed to make code cleaner) > > The patch basically moved state initialization to dst_attach. The above > code, after the patch is: > > card->fe = dvb_attach(dst_attach, &dst_config, card->bt, > card->i2c_adapter); > > So, I didn't noticed any regressions by running the modified driver nor > I couldn't identify any regressions by inspecting the source code. > > The end result seems also cleaner and easier to understand, preserving > all characteristics of the original code. Also, it uses dvb_attach the > same way as the other dvb helper modules. > > If later any changes will be needed to allow using DST on different > configurations, future patches probably will need to move dst > initialization to other places, and use different callbacks for it, > altering the above initialization. I can't see why those changes would > possibly avoid any further changes at the driver. > > That's said, I intend to commit the two patches, fixing the current > issues, at this weekend. > I did explain my stand in a previous mail. NACK - 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 ...)
Uwe Bugla wrote: > On the technical layer I noticed that I heard some Pinnacle relais click > during testing, but there were some i2c_bus symbols missing during > compilation. So I guess those missing symbols are responsible for getting > neither picture nor sound. Can you send your compile warnings ? I couldn't find the same in my mailbox any report on the same. Maybe my mail filter did something. > A. If you are really interested I can send you my basic puzzle parts in > short, opening a new thread on this issue. Just give me a short response if > you are interested. > > B. If you want to continue the cx878 project please drop me a short note > where I can download it to test and enlarge it with my own ideas as good as I > can. > > Must not be immediately (no sweat please), but I am looking forward to > receive a response from you. > What i would like to do is like this: Have the current state frozen as it is, such that there is a fallback case (The dst is quite fragile and change at some place would break another. ie, what looks good for one DST variant is bad for the other). Work on a new tree (CX878) and migrate stuff to it. Remove the old one, once things are done. I wouldn't want to mess up the current working situation and hence. - 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 ...)
Uwe Bugla wrote: > Original-Nachricht > Datum: Wed, 02 May 2007 17:30:32 +0400 > Von: Manu Abraham <[EMAIL PROTECTED]> > An: Trent Piepho <[EMAIL PROTECTED]> > CC: Simon Arlott <[EMAIL PROTECTED]>, Linux Kernel Mailing list > , [EMAIL PROTECTED], Jan Engelhardt <[EMAIL > PROTECTED]>, [EMAIL PROTECTED], [EMAIL PROTECTED], Linux DVB <[EMAIL > PROTECTED]> > Betreff: Re: [linux-dvb] DST/BT878 module customization (.. was: Critical > points about ...) > >> Trent Piepho wrote: >>> On Tue, 1 May 2007, Simon Arlott wrote: >>>> On 30/04/07 22:17, Markus Rechberger wrote: >>>>> From my side I do not see any problem with that patch, if someone else >>>>> has a problem with it please state out the reason. >>>> I have no problem with the patch since it has nothing to do with my DVB >>>> card but you're only encouraging Uwe to be abusive since it seems to >>>> help get him what he wants: >>> I've been aware of the problem with dst not fully using the dvb >> customization >>> systems(*) for a long time. It came up when dvb_attach() et al were >> first >>> being integrated, well before any rejected patches or strongly worded >> emails >>> or whatever from certain people that I'm aware of. >>> >> Well, your understanding of the device is quite limited and hence your >> comments and patches. >> >> The DST as it refers to is an embedded system a x86 Compatible RISC core >> [1] running at 20Mhz with 4MB Flash and 1MB RAM. The device has it's own >> IO and 2 DMA channels. What we have is a PQFP device >> >> This is the case in most cases. On some cheaper cards the embedded >> system is replaced by an 8 bit host microcontroller, to cut down costs >> where all the features are not required for a specific model >> >> Additionally this embedded system has a fast shovelling engine for the >> MPEG2 TS routing in between the >> This embedded system is connected to an actual >> (1) DVB frontend [2] >> (2) DVB CA interface [3] >> (3) Analog tuner >> (4) Audio interfaces >> >> These features are not the characteristics of a DVB Frontend. Here there >> is a DVB frontend like the normal ones which is hidden behind another >> pseudo bridge (So you don't have *any* access to the frontend at large) >> >> It is not necessary that *all* the dst cards (there are around ~15 >> different variants of the same) do have the very same feature set. >> >> It does support DVB-S/DSS/DVB-C/DVB-T/ATSC depending on the cards. In >> fact it is a combo driver supporting the entire devices using a common >> command set >> >> In such a case it has more characteristics of the PCI bridge and in fact >> heavily tied to it and has it's own advantages. >> >>> I saw some discussion about dst by Markus, Mauro, and Andrew Morton, and >> since >>> I already know about the issues here, I felt I should post a patch for >> them >>> any other reasonable developers who might spend time on this. >>> >> I would think that it would be *extremely* rude for a person to send in >> patches for a device that which you don't understand at all, when it is >> for limiting the capability of the said device > > Hi Manu, > now if this is your evalution about it all, then let me tell you that I feel > deeply sorry about it. > > Fact is: > Noone ever intended to send in patches limiting the capability of the said > device (DST): I never did, Trent never did, Markus, Mauro, Andrew and others > never did... > > Instead of this we all have very different knowledge and understanding > levels, with you obviously being the one with the most elaborate and > sophisticated level. > > So please why, instead of marking other people as "rude" whose solutions you > do not appreciate at all, don't you just pick up the pratical proposals of > other persons, even if you do not like them for some reasons, and at least > try to raise them up to a far more better level? > Thus you definitely could avoid a lots of flaming, misunderstanding, and > other counterproductive things to happen... > And this would conform to practising the synergetic principle, wouldn't it? > > Just one hint to help you: I remember a mail from Johannes in which he told > me that you started up this whole development thing from a zero level some > two or three years ago. And Johannes not forgot to state that in the > beginning you were nothing but nerving... (now add a smiley
Re: [linux-dvb] DST/BT878 module customization (.. was: Critical points about ...)
Uwe Bugla wrote: > Original-Nachricht > Datum: Wed, 02 May 2007 17:30:32 +0400 > Von: Manu Abraham <[EMAIL PROTECTED]> > An: Trent Piepho <[EMAIL PROTECTED]> > CC: Simon Arlott <[EMAIL PROTECTED]>, Linux Kernel Mailing list > , [EMAIL PROTECTED], Jan Engelhardt <[EMAIL > PROTECTED]>, [EMAIL PROTECTED], [EMAIL PROTECTED], Linux DVB <[EMAIL > PROTECTED]> > Betreff: Re: [linux-dvb] DST/BT878 module customization (.. was: Critical > points about ...) > >> Trent Piepho wrote: >>> On Tue, 1 May 2007, Simon Arlott wrote: >>>> On 30/04/07 22:17, Markus Rechberger wrote: >>>>> From my side I do not see any problem with that patch, if someone else >>>>> has a problem with it please state out the reason. >>>> I have no problem with the patch since it has nothing to do with my DVB >>>> card but you're only encouraging Uwe to be abusive since it seems to >>>> help get him what he wants: >>> I've been aware of the problem with dst not fully using the dvb >> customization >>> systems(*) for a long time. It came up when dvb_attach() et al were >> first >>> being integrated, well before any rejected patches or strongly worded >> emails >>> or whatever from certain people that I'm aware of. >>> >> Well, your understanding of the device is quite limited and hence your >> comments and patches. >> >> The DST as it refers to is an embedded system a x86 Compatible RISC core >> [1] running at 20Mhz with 4MB Flash and 1MB RAM. The device has it's own >> IO and 2 DMA channels. What we have is a PQFP device >> >> This is the case in most cases. On some cheaper cards the embedded >> system is replaced by an 8 bit host microcontroller, to cut down costs >> where all the features are not required for a specific model >> >> Additionally this embedded system has a fast shovelling engine for the >> MPEG2 TS routing in between the >> This embedded system is connected to an actual >> (1) DVB frontend [2] >> (2) DVB CA interface [3] >> (3) Analog tuner >> (4) Audio interfaces >> >> These features are not the characteristics of a DVB Frontend. Here there >> is a DVB frontend like the normal ones which is hidden behind another >> pseudo bridge (So you don't have *any* access to the frontend at large) >> >> It is not necessary that *all* the dst cards (there are around ~15 >> different variants of the same) do have the very same feature set. >> >> It does support DVB-S/DSS/DVB-C/DVB-T/ATSC depending on the cards. In >> fact it is a combo driver supporting the entire devices using a common >> command set >> >> In such a case it has more characteristics of the PCI bridge and in fact >> heavily tied to it and has it's own advantages. >> >>> I saw some discussion about dst by Markus, Mauro, and Andrew Morton, and >> since >>> I already know about the issues here, I felt I should post a patch for >> them >>> any other reasonable developers who might spend time on this. >>> >> I would think that it would be *extremely* rude for a person to send in >> patches for a device that which you don't understand at all, when it is >> for limiting the capability of the said device > > Hi Manu, > now if this is your evalution about it all, then let me tell you that I feel > deeply sorry about it. > > Fact is: > Noone ever intended to send in patches limiting the capability of the said > device (DST): I never did, Trent never did, Markus, Mauro, Andrew and others > never did... > > Instead of this we all have very different knowledge and understanding > levels, with you obviously being the one with the most elaborate and > sophisticated level. > > So please why, instead of marking other people as "rude" whose solutions you > do not appreciate at all, don't you just pick up the pratical proposals of > other persons, even if you do not like them for some reasons, and at least > try to raise them up to a far more better level? > Thus you definitely could avoid a lots of flaming, misunderstanding, and > other counterproductive things to happen... > And this would conform to practising the synergetic principle, wouldn't it? > > Just one hint to help you: I remember a mail from Johannes in which he told > me that you started up this whole development thing from a zero level some > two or three years ago. And Johannes not forgot to state that in the > beginning you were nothing but nerving... (now add a smiley
Re: [linux-dvb] DST/BT878 module customization (.. was: Critical points about ...)
Trent Piepho wrote: > On Tue, 1 May 2007, Simon Arlott wrote: >> On 30/04/07 22:17, Markus Rechberger wrote: >>> From my side I do not see any problem with that patch, if someone else >>> has a problem with it please state out the reason. >> I have no problem with the patch since it has nothing to do with my DVB >> card but you're only encouraging Uwe to be abusive since it seems to >> help get him what he wants: > > I've been aware of the problem with dst not fully using the dvb customization > systems(*) for a long time. It came up when dvb_attach() et al were first > being integrated, well before any rejected patches or strongly worded emails > or whatever from certain people that I'm aware of. > Well, your understanding of the device is quite limited and hence your comments and patches. The DST as it refers to is an embedded system a x86 Compatible RISC core [1] running at 20Mhz with 4MB Flash and 1MB RAM. The device has it's own IO and 2 DMA channels. What we have is a PQFP device This is the case in most cases. On some cheaper cards the embedded system is replaced by an 8 bit host microcontroller, to cut down costs where all the features are not required for a specific model Additionally this embedded system has a fast shovelling engine for the MPEG2 TS routing in between the This embedded system is connected to an actual (1) DVB frontend [2] (2) DVB CA interface [3] (3) Analog tuner (4) Audio interfaces These features are not the characteristics of a DVB Frontend. Here there is a DVB frontend like the normal ones which is hidden behind another pseudo bridge (So you don't have *any* access to the frontend at large) It is not necessary that *all* the dst cards (there are around ~15 different variants of the same) do have the very same feature set. It does support DVB-S/DSS/DVB-C/DVB-T/ATSC depending on the cards. In fact it is a combo driver supporting the entire devices using a common command set In such a case it has more characteristics of the PCI bridge and in fact heavily tied to it and has it's own advantages. > I saw some discussion about dst by Markus, Mauro, and Andrew Morton, and since > I already know about the issues here, I felt I should post a patch for them > any other reasonable developers who might spend time on this. > I would think that it would be *extremely* rude for a person to send in patches for a device that which you don't understand at all, when it is for limiting the capability of the said device > If there is an abusive person, I'm not going to let it affect my behavior. > You lose if you let them influence your decisions one way, or influence them > another way. > > > (*) There are two customization/dependency control systems in DVB. One is > dvb_attach(), the other is DVB_FE_CUSTOMISE. They are not two entirely > separate systems, but overlap in their design a great deal. > Here we have the attach method attaching different objects, but basically it can be handled for the frontend devices only (and that too that share a very common trait, in this case, frontends are coupled using the i2c bus) and not for other devices. Situation changes when you use another interface such as SPI, where the interface is not well defined. In the DVB OO concept we have, where the objects are at different levels, the basic concept is that an object is indeed a smaller subset, depending on the level that which it pertains to. In such a case the frontend is limited to do just frontend related operations. There could be other ways that things can be done maybe the DVB API can be redone to have all DVB operations through the frontend alone. But that is not at all decent way of doing it. > The significant part, common to both, is the overall design of the driver > framework. DVB uses what I would describe as an object oriented system. A > driver for a certain type of hardware exports a single attach function, which > returns an object for one instance of that hardware. All control of that > hardware is done via methods defined in this object. There is typical > hierarchy, where an 'adapter' object will contain a 'frontend' object which > will contain a 'tuner' object. Of course hardware designers are not > constrained by the software frameworks we create, so sometimes it's more > complex (e.g., dst). It is a bit more complex than you think. You can imagine the entire DVB-CORE along with proprietory vendor specific tuning algorithms (on all devices, specific to the hardware onbaord. Algorithms do change from slight change of hardware such as demodulators and or CA interface stacks) on CA devices it has an onboard EN50221 CA stack from SCM [4] called the Sunplus CI stack. On Hybrid DST devices they do feature in analog core support in there as well as Audio too on some cards. It is not a constraint as what you might think, as the DST is complete hardware solution of the interfaces that you are talking about. (There are 2 approaches, (1) do everything in hardware (2)
Re: [linux-dvb] Re: Critical points about kernel 2.6.21 and pseudo-authorities
Uwe Bugla wrote: > 1. You utmost personally are responsible for 4 ununsable kernels, as far as > bt8xx cards are concerned: 2.6.13, 2.6.14, 2.6.15, 2.6.16! > 2. You did not even want to imply to resolve that issue by incarnating that > "community and synergy principle" that linux community needs to exist at all, > but you just perverted it by flaming capable people - You mean like this: Original Message Subject: kernel patch practice in 2.6.13-mm2 Date: Tue, 13 Sep 2005 16:46:35 +0200 (MEST) From: Uwe Bugla <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] CC: [EMAIL PROTECTED] Hi, if you continue to send or sign mm-patches for Kernel 2.6.13 as a consequence of a design change I would appreciate you to stop rubbing out my name. You did that in a file called /Documentation/dvb/bt8xx.txt. My objective is understandable good documentation, even if it may sound trivial for some developpers minds. I always have in mind that there are also lots of beginners reading those documents. As I respect your work I never in my life would even dare to rub out other coauthors names. That´s why I appreciate you to respect my name and stop rubbing it out. Thanks Uwe Bugla P. S.: If you f. ex. publish a book I ain´t gonna burn it as a matter of disrespect. So have a little respect vice versa! -- Lust, ein paar Euro nebenbei zu verdienen? Ohne Kosten, ohne Risiko! Satte Provisionen für GMX Partner: http://www.gmx.net/de/go/partner --- Original Message Subject: "synchronization problems" Date: Thu, 15 Sep 2005 10:44:38 +0200 (MEST) From: Uwe Bugla <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] CC: [EMAIL PROTECTED] Hallo Mr. Stezenbach, "You breached the protocol by not sending the patches to the maintainer or linux-dvb list. The result of this was that we had conflicting changes in CVS. I spent about 10 minutes thinking how I could merge the two, and then gave up (I had 53 other patches to prepare and I had little time left to do the job). So I didn't just remove your name, but all changes which you sent to akpm along with it. bt8xx.txt in the kernel is now in sync with the version in linuxtv.org CVS." I didn't breach any protocol, nor did I break any unwritten rule or law. I simply took the advice from Gerd Knorr that linuxtv maintainers were just moving to another place to the point of time when I sent in my first dvb-bt8xx-patch. So consequently I took the direct way to send it to akpm. Just to be sure it is really being applied without waiting 3, 4 weeks or however long. So if you continue to at least discussing with my person, please immediately stop doing that in such a bureaucratic manner. If synchronization of CVS and kernel.org only works unidirectional, and not bidirectional, then neither I, nor akpm, nor Manu or anybody else has a real problem, but you personally have one without any doubts. And if you lack time, simply delegate your job to another person. But simply stop rubbing out other peoples coauthorship and pay respect to their contributions. And the biggest joke about your personal misbehaviour is the fact that you personally cosigned at least one of my patch attempts, without dropping me a single note asking me to not bypass the linuxtv CVS maintainers. So good morning Mr. Stezenbach, I appreciate you to wake up a little bit earlier in the future! "Additionally you deleted information from bt8xx.txt which I think were useful help for debugging problems, and which were written there on purpose by the developer. So if you talk about respect, you could show some yourself by not bypassing the original authors and maintainers when sending patches." In fact I did, and I can tell you the simple reasons why. There are in fact two things that I simply cannot and will not tolerate: a. orthographic junk (examples: "bythe" or, even worse: "autodected" and "Recognise") It was ME who corrected that in the past, and it was YOU personally who reversed that, if not to say: fucked it up in the current 2.6.14-rc1. So as a consequence it is YOUR task to do your homework and apologize for that, but not MINE! b. attempts of documentation that do NOT correspond to their appropriate kernel design What do I mean with b.? 1. In Kernels 2.6.12 AND 2.6.13 the simple command "modprobe dvb-bt8xx" caused ALL OTHER modules to load automatically: cx24110, dst, dst-ci and dst-ca. Now if the kernel design forces the automatic loading of dst, dst-ca and dst-ci, every attempt of discussion about debug parameters is simply obsolete! So if I cannot load the dst module separately, how should I be able to hack in debug parameters? I know what debug parameters are for, and I deeply respect developers work, but what the hell is it all worth for if a kernel design suppresses hacking in debug parameters? 2. Moreover I am not shure in how far the parameters 0x68 and 0x71 really correspond to TwinHan cards. A closer look to CARDLIST.bttv says: card ID = 113. But perhaps I have problems to deal with hexadecimal numbe
Re: [linux-dvb] Re: Critical points about kernel 2.6.21 and pseudo-authorities
Trent Piepho wrote: > 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. With regards to the dst, i have explained earlier to you that 1) the dst is not a frontend 2) i do not wish to use the frontend attach methods with regards to dst/dst_ca To mention, we had these discussions much long back how to go about it and don't think that every time a new developer get's an account with linuxtv.org, this has to be a matter that has to discussed to death http://article.gmane.org/gmane.linux.drivers.dvb/16156/match=patch+dvb+bt8xx+cleanup (eventhough of not much concern) If you now see most of the code in dvb-bt8xx especially the DMA stuff was refactored from the dst driver. But that said, the dst *is* different, so WTH ? - 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: suspend2 merge (was Re: [Suspend2-devel] Re: CFS and suspend2: hang in atomic copy)
Pavel Machek wrote: > STD needs to snapshot system, and then it needs devices to be > suspended so that snapshot is consistent. One question though, there are devices that can be suspended (broken suspend) and restore in such a case wouldn't work at all. The only possible way would be then to reinitialize the device instead of restore ? Manu - 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
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. Manu - 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
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 - 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
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 - 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
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. HTH, Manu - 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
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 . I am not arguing about the veracity of the patches, but how things are handled. Agreed to all the mentioned above. There is one more aspect. The mentioned patches, do not have any ACK/SOB from any DVB developer/maintainer for the same. Huge regressions are created this way. One more time the regression creator is caught. Manu - 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] DVB: Delete unused header file linux/dvb/version.h.
On 3/25/07, Arjan van de Ven <[EMAIL PROTECTED]> wrote: > There are cases where we need an API update since newer systems do show up. > In such a case, the only way is to provide backward compatibility > while adding in newer stuff. > > Currently we use the version major/minor for the userspace to identify > the in kernel API, while the userspace apps can remain binary > compatible this is the problem exactly! Your userspace binary knows about the kernel headers it was compiled against, not about the actual running kernel! They are very likely not the same. Well, we could go for an IOCTL in such a case to avoid the unpleasant scenario. Manu - 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] DVB: Delete unused header file linux/dvb/version.h.
On 3/23/07, Arjan van de Ven <[EMAIL PROTECTED]> wrote: On Fri, 2007-03-23 at 16:47 +0100, Marcel Siegert wrote: > On Friday 23 March 2007, Robert P. J. Day wrote: > > > > Delete the unreferenced header file include/linux/dvb/version.h. > > > > Signed-off-by: Robert P. J. Day <[EMAIL PROTECTED]> > > > NACK > this header is unreferenced in kernel, but used for applications that compile for userspace > to determine the api version. btw that is something extremely evil to do. Either you have varying apis between kernels (which is naughty, but I suppose you can go up in capabilities) or it's fully static. There are cases where we need an API update since newer systems do show up. In such a case, the only way is to provide backward compatibility while adding in newer stuff. Currently we use the version major/minor for the userspace to identify the in kernel API, while the userspace apps can remain binary compatible Regards, Manu - 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: GPL vs non-GPL device drivers
On 2/15/07, linux-os (Dick Johnson) <[EMAIL PROTECTED]> wrote: I don't think of GPL as a religion, only as an experiment that has run amok. The point of GPL, is that even if the vendor stopped supporting, you could fix the device driver by yourself. This is really happening, vendors do sell hardware with broken drivers and make the suers cry out loudly. At the mercy of the vendor. (This has happened and is still happening) This is exactly the whole point about GPL. If you think otherwise, you are just one of the vendors trying to force your hopeless driver to clueless users. So, IMO when someone says binary only modules are the way, i wouldn't bite the line. I don't think this is a religion, but a freedom to use what you want. HTH, manu - 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: GPL vs non-GPL device drivers
On 2/15/07, Mws <[EMAIL PROTECTED]> wrote: hi vj, On Thursday 15 February 2007, v j wrote: > This is in reference to the following thread: > > http://lkml.org/lkml/2006/12/14/63 > > I am not sure if this is ever addressed in LKML, but linux is _very_ > popular in the embedded space. We (an embedded vendor) chose Linux 3 > years back because of its lack of royalty model, robustness and > availability of infinite number of open-source tools. > > We recently decided to move to Linux 2.6 for our next product, mainly > because Linux has worked so well for us in the past, and we would like > to move up to keep up with the latest and greatest. you choose to move to linux 2.6 for your next product - fine. it has worked for you well in the past - fine. you would like to keep along with the latest and greatest - fine. _but_ for all those reasons you have to get along with all rules, licenses and at least all changes that the kernel community decided to perform. > However in moving to 2.6, we noticed a number of alarming things. > Porting drivers over from devfs to udev, though easy raised a number > of alarming issues. Driver's no longer could dynamically allocate > their MAJOR/MINOR numbers. Doing so would mean they would have to use > sysfs. However it seems that sysfs (and the class_ interface) is only > available to GPL modules. This is very concerning. The drivers which > we have written over the last three years are suddenly under threat. > We don't mind statically assigning MAJOR/MINOR numbers to our drivers. > We can do this and modify our user space applications too. > > However we have a worrying trend here. If at some point it becomes > illegal to load our modules into the linux kernel, then it is > unacceptable to us. We would have been better off choosing VxWorks or > OSE 3 years ago when we made an OS choice. The fact that Linux is > becoming more and more closed is very very alarming. the trend is not worrying. we are not responsible for your decisions you made in the past. the only real FACT is that linux is being stated to BE OPEN and what is much more important to STAY OPEN for everybody. you chose it years ago, because of those facts. of course linux is very popular on embedded systems. i am working within some open source projects that also run on embedded hardware designs. your main mistake in understanding linux and our way to have it also more open in future than by now. what actually costs you more in future? opening your drivers, as much it must be, to have your hardware supported under 2.6 _or_ paying license fees for runtime/development tools for vxworks, ose whatever? marcel, most of the vendors, who claim IP just cite nonsense. There are really hardly a few vendors who are really bound to the IP issue. Just that they do not know how to write proper code, they do not want to open up their code. In fact , such vendors do have a think probably like this "if we open up our driver if people see the pathetic quality, the customers would probably think how bad is the hardware and probably affect our sales" . So it would be better if we hide under the shade of the IP umbrella. Little do that these vendors know that customers wouldn't want to go alongwith such narrow minded vendors in the long run. But somehow due to a certain void people do the get along, that's it, not for long though. regards, manu - 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: smp and irq conflict
On 2/2/07, Erik Mouw <[EMAIL PROTECTED]> wrote: On Fri, Feb 02, 2007 at 01:04:53AM +0100, Lapo TIN wrote: > I need to capture at 25 frame per second from each channel... > So 25 x 8 total frames per second on the pci. Each PAL frame takes about 800k, so that makes 20MB/s per channel. With 8 channels that makes 160 MB/s. That will most certainly overwhelm a normal 33 MHz 32 bit PCI bus which has a theoretical bandwidth of 132 MB/s (90MB/s max in practice). Modern PCs have faster PCI busses (66MHz, 64 bit, PCI-X, or PCI-e) so there's less chance on bus contention. On the other hand, I suppose you will store the video streams on disk. That will use another 20MB/s per channel on the bus so the total becomes 320 MB/s. You need some careful system design in order to get that right. Especially look carefully at bus contention, if the system has multiple busses, distribute the bttv cards over those busses. Also be sure to have enough bandwidth for the disk subsystem. > So do you think I have to change the motherboard ? > What is important ? the chipset ? is there specification I need ? Last time I had to record frame-synchronous video from 3 streams (8 years ago) PCs could hardly manage 2 streams over their bus and there was no way to guarantee frame sync. The only way out was to use an SGI Onyx2 with 3 digital video option cards and a large disk subsystem. That made the whole system much more expensive but at that time it was the only way to meet all requirements. I don't know about current PCs, bus speeds have improved. It is however still important how those busses are connected together and to the chipset. You have to figure out from your motherboard documentation if there is enough bandwidth available. If there isn't, get a faster motherboard, or consider using compressing grabber cards like the Hauppauge PVR 150 or PVR 500. such devices can do a max of one input or 2 inputs. There are cards that do 16/32 video inputs, do hardware MPEG4 compression and write to disk/ stream out through the network interface. But most such devices have proprietory drivers and have issues working properly. Got bitten by a bug similarly, recently. The vendor was pig headed to either fix the driver or to provide driver source. (http://dvr.neugent.net/ They talked too much of Linux, but really pathetic stuff overall, claimed their issue was Intellectual Property) They claimed the Linux kernel was buggy rather than stating that their driver was buggy. In the end, luckily got my money back for the hardware. Manu - 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] Re: dvb shared datastructure bug?
On 2/13/07, Trent Piepho <[EMAIL PROTECTED]> wrote:
On Tue, 13 Feb 2007, Jakub Jelinek wrote:
> Wouldn't it be better to kmalloc both struct dvb_device and
> struct file_operations together instead of doing 2 separate allocations?
> struct dvd_device_plus_fops
> {
> struct dvb_device dev;
> struct file_operations fops;
> } *dev_fops = kmalloc (sizeof (struct dvd_device_plus_fops), GFP_KERNEL);
> *pdvbdev = dvbdev = (struct dvb_device *)dev_fops;
> if (dev_fops == NULL)
> error handling;
> memset (&dev_fops->fops, 0, sizeof (dev_fops->fops));
> ...
> dvbdev->fops = &dev_fops->fops;
Maybe change struct dvb_device:
struct dvb_device {
struct list_head list_head;
-struct file_operations *fops;
+struct file_operations fops;
struct dvb_adapter *adapter;
We can of course do that, but if we do that now, i will have to rework
on the changes that which i have, but considering the changes that i
have i wouldn't want to do such a change right now as marcel
explained. But we can surely go in for this, as soon as the rest of
the API changes goes in, ie, multiproto + adaptor changes
manu
-
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: dvb shared datastructure bug?
On 2/13/07, Marcel Siegert <[EMAIL PROTECTED]> wrote:
On Tuesday 13 February 2007, Arjan van de Ven wrote:
> Hi,
>
> while working on the last pieces of the file_ops constantification, DVB
> is the small village in France that is holding the Romans at bay... but
> I think I found the final flaw in it now:
>
>*pdvbdev = dvbdev = kmalloc(sizeof(struct dvb_device), GFP_KERNEL);
>
> if (!dvbdev) {
> mutex_unlock(&dvbdev_register_lock);
> return -ENOMEM;
> }
>
> memcpy(dvbdev, template, sizeof(struct dvb_device));
> dvbdev->type = type;
> dvbdev->id = id;
> dvbdev->adapter = adap;
> dvbdev->priv = priv;
>
> dvbdev->fops->owner = adap->module;
>
>
> this is the place in DVB that is writing to a struct file_operations.
> But as with almost all such cases in the kernel, this one is buggy:
> While the code nicely copies a template dvbdev, that template only has a
> pointer to a *shared* fops struct, the copy doesn't help that. So this
> code is overwriting the fops owner field for ALL active devices, not
> just the ones the copy of the template is for
>
> I'm lost in the maze of this part of DVB (it seems to have some magic
> potion to resist me) but I was hoping some of the local citizens could
> take a look at this buglet...
>
> Greetings,
> Arjan van de Ven
hi arjan,
thanks for pointing out this issue.
attached find a patch that fixes the problem.
@mauro - please pull changeset a7ac92d208fe
dvbdev: fix illegal re-usage of fileoperations struct
from http://www.linuxtv.org/hg/~mws/v4l-dvb-fixtree
Ack'd-by: Manu Abraham <[EMAIL PROTECTED]>
-
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] dvb shared datastructure bug?
On 2/13/07, Arjan van de Ven <[EMAIL PROTECTED]> wrote:
Hi,
while working on the last pieces of the file_ops constantification, DVB
is the small village in France that is holding the Romans at bay... but
I think I found the final flaw in it now:
*pdvbdev = dvbdev = kmalloc(sizeof(struct dvb_device), GFP_KERNEL);
if (!dvbdev) {
mutex_unlock(&dvbdev_register_lock);
return -ENOMEM;
}
memcpy(dvbdev, template, sizeof(struct dvb_device));
dvbdev->type = type;
dvbdev->id = id;
dvbdev->adapter = adap;
dvbdev->priv = priv;
dvbdev->fops->owner = adap->module;
this is the place in DVB that is writing to a struct file_operations.
But as with almost all such cases in the kernel, this one is buggy:
While the code nicely copies a template dvbdev, that template only has a
pointer to a *shared* fops struct, the copy doesn't help that. So this
code is overwriting the fops owner field for ALL active devices, not
just the ones the copy of the template is for
While working on a new device node, i stumbled across a similar issue
where attaching the frontend failed due to some sort of memory
corruption. This was seen as all the callbacks suddenly just vanished,
eventhough it existed in the driver
At that point, i figured it could be something due to an error at my
side , since the device that i was working was a bit complex and had
API changes as well.
Thanks for pointing it out. It looks like the issue sounds similar.
regards,
Manu
-
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: NAK new drivers without proper power management?
On 2/12/07, Nigel Cunningham <[EMAIL PROTECTED]> wrote: Hi. On Mon, 2007-02-12 at 02:57 +0400, Manu Abraham wrote: > On 2/12/07, Nigel Cunningham <[EMAIL PROTECTED]> wrote: > > > Neither am I. I'm just asking that new drivers have power management as > > standard. > What if the hardware doesn't support power management ? You would still want to do the cleanup and configuration that you'd do for module load/unload. By adding dummy functions, wouldn't that just look awkward ? regards, manu - 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/
