Re: [v4l-dvb-maintainer] [GIT PATCHES] V4L/DVB changes for 2.6.24
On 10/10/07, Mauro Carvalho Chehab <[EMAIL PROTECTED]> wrote: > Linus, > > Please pull from: > ssh://master.kernel.org/pub/scm/linux/kernel/git/mchehab/v4l-dvb.git > master > > We have 300+ patches this time, covering lots of drivers improvements and > fixes. > > Also, there are several core changes: > - Unified support for Hybrid tuners on both V4L and DVB core; > - videobuf split into PCI DMA S/G specific and a generic module; > - added a videobuf handler for drivers that need vmalloc'ed memory like > USB devices). > > And some driver additions: > - cx23885 driver; > - ivtv framebuffer driver; > - tcm825x driver. > > I still have two cx88-alsa patches pending, at devel tree. Those two are > dependent from -ALSA merge. So, I should send you a pull request later, > after > being sure that you've already pulled from alsa. > > Cheers, > Mauro. > > --- > > Documentation/dvb/faq.txt |2 +- > Documentation/video4linux/CARDLIST.bttv|1 + > Documentation/video4linux/CARDLIST.cx23885 |5 + > Documentation/video4linux/CARDLIST.saa7134 |5 +- > drivers/media/Kconfig | 70 +- > drivers/media/common/Kconfig |2 +- > drivers/media/common/ir-functions.c|1 - > drivers/media/common/ir-keymaps.c | 62 +- > drivers/media/common/saa7146_core.c| 34 +- > drivers/media/common/saa7146_fops.c|5 +- > drivers/media/common/saa7146_i2c.c | 23 +- > drivers/media/common/saa7146_vbi.c |9 +- > drivers/media/common/saa7146_video.c | 11 +- > drivers/media/dvb/bt8xx/bt878.c|1 - > drivers/media/dvb/bt8xx/bt878.h|7 +- > drivers/media/dvb/bt8xx/dvb-bt8xx.c|1 - > drivers/media/dvb/cinergyT2/cinergyT2.c|8 +- > drivers/media/dvb/dvb-core/dmxdev.c|1 - > drivers/media/dvb/dvb-core/dvb_ca_en50221.c| 93 +- > drivers/media/dvb/dvb-core/dvb_demux.c |5 +- > drivers/media/dvb/dvb-core/dvb_frontend.c | 125 ++- > drivers/media/dvb/dvb-core/dvb_frontend.h | 13 +- > drivers/media/dvb/dvb-core/dvb_net.c | 22 +- > drivers/media/dvb/dvb-core/dvbdev.c| 41 +- > drivers/media/dvb/dvb-usb/Kconfig |2 + > drivers/media/dvb/dvb-usb/dib0700.h|5 +- > drivers/media/dvb/dvb-usb/dib0700_core.c | 23 +- > drivers/media/dvb/dvb-usb/dib0700_devices.c| 676 +- > drivers/media/dvb/dvb-usb/dtt200u.c| 28 +- > drivers/media/dvb/dvb-usb/dvb-usb-ids.h| 26 +- > drivers/media/dvb/dvb-usb/dvb-usb-init.c |2 +- > drivers/media/dvb/dvb-usb/gp8psk-fe.c | 84 +- > drivers/media/dvb/dvb-usb/gp8psk.c | 93 +- > drivers/media/dvb/dvb-usb/gp8psk.h | 32 +- > drivers/media/dvb/dvb-usb/vp7045.c |2 +- > drivers/media/dvb/frontends/Kconfig| 33 +- > drivers/media/dvb/frontends/Makefile |4 + > drivers/media/dvb/frontends/bcm3510.c |1 - > drivers/media/dvb/frontends/cx22700.c |1 - > drivers/media/dvb/frontends/cx24110.c |1 - > drivers/media/dvb/frontends/cx24123.c |1 - > drivers/media/dvb/frontends/dib0070.c | 580 > drivers/media/dvb/frontends/dib0070.h | 44 + > drivers/media/dvb/frontends/dib3000mb.c|1 - > drivers/media/dvb/frontends/dib3000mc.c| 192 ++- > drivers/media/dvb/frontends/dib7000m.c | 727 ++ > drivers/media/dvb/frontends/dib7000p.c | 908 > drivers/media/dvb/frontends/dib7000p.h | 14 +- > drivers/media/dvb/frontends/dibx000_common.h | 57 +- > drivers/media/dvb/frontends/dvb-pll.c | 147 ++- > drivers/media/dvb/frontends/dvb_dummy_fe.c |1 - > drivers/media/dvb/frontends/isl6421.c |1 - > drivers/media/dvb/frontends/l64781.c |1 - > drivers/media/dvb/frontends/lgdt330x.c |1 - > drivers/media/dvb/frontends/lnbp21.c |1 - > drivers/media/dvb/frontends/mt2060.c |1 - > drivers/media/dvb/frontends/mt2131.c | 314 > drivers/media/dvb/frontends/mt2131.h | 54 + > drivers/media/dvb/frontends/mt2131_priv.h | 49 + > drivers/media/dvb/frontends/mt2266.c | 287 > drivers/media/dvb/frontends/mt2266.h | 37 + > drivers/media/dvb/frontends/mt312.c|1 - > drivers/media/dvb/frontends/mt352.c|1 - > drivers/media/dvb/frontends/nxt200
Re: [v4l-dvb-maintainer] [GIT PATCHES] V4L/DVB changes for 2.6.24
On 10/11/07, Markus Rechberger <[EMAIL PROTECTED]> wrote: > On 10/10/07, Mauro Carvalho Chehab <[EMAIL PROTECTED]> wrote: > > Linus, > > > > Please pull from: > > > ssh://master.kernel.org/pub/scm/linux/kernel/git/mchehab/v4l-dvb.git > > master > > > > We have 300+ patches this time, covering lots of drivers improvements and > > fixes. > > > > Also, there are several core changes: > > - Unified support for Hybrid tuners on both V4L and DVB core; > > - videobuf split into PCI DMA S/G specific and a generic module; > > - added a videobuf handler for drivers that need vmalloc'ed memory like > > USB devices). > > > > And some driver additions: > > - cx23885 driver; > > - ivtv framebuffer driver; > > - tcm825x driver. > > > > I still have two cx88-alsa patches pending, at devel tree. Those two are > > dependent from -ALSA merge. So, I should send you a pull request later, > > after > > being sure that you've already pulled from alsa. > > > > Cheers, > > Mauro. > > > > --- > > > > Documentation/dvb/faq.txt |2 +- > > Documentation/video4linux/CARDLIST.bttv|1 + > > Documentation/video4linux/CARDLIST.cx23885 |5 + > > Documentation/video4linux/CARDLIST.saa7134 |5 +- > > drivers/media/Kconfig | 70 +- > > drivers/media/common/Kconfig |2 +- > > drivers/media/common/ir-functions.c|1 - > > drivers/media/common/ir-keymaps.c | 62 +- > > drivers/media/common/saa7146_core.c| 34 +- > > drivers/media/common/saa7146_fops.c|5 +- > > drivers/media/common/saa7146_i2c.c | 23 +- > > drivers/media/common/saa7146_vbi.c |9 +- > > drivers/media/common/saa7146_video.c | 11 +- > > drivers/media/dvb/bt8xx/bt878.c|1 - > > drivers/media/dvb/bt8xx/bt878.h|7 +- > > drivers/media/dvb/bt8xx/dvb-bt8xx.c|1 - > > drivers/media/dvb/cinergyT2/cinergyT2.c|8 +- > > drivers/media/dvb/dvb-core/dmxdev.c|1 - > > drivers/media/dvb/dvb-core/dvb_ca_en50221.c| 93 +- > > drivers/media/dvb/dvb-core/dvb_demux.c |5 +- > > drivers/media/dvb/dvb-core/dvb_frontend.c | 125 ++- > > drivers/media/dvb/dvb-core/dvb_frontend.h | 13 +- > > drivers/media/dvb/dvb-core/dvb_net.c | 22 +- > > drivers/media/dvb/dvb-core/dvbdev.c| 41 +- > > drivers/media/dvb/dvb-usb/Kconfig |2 + > > drivers/media/dvb/dvb-usb/dib0700.h|5 +- > > drivers/media/dvb/dvb-usb/dib0700_core.c | 23 +- > > drivers/media/dvb/dvb-usb/dib0700_devices.c| 676 +- > > drivers/media/dvb/dvb-usb/dtt200u.c| 28 +- > > drivers/media/dvb/dvb-usb/dvb-usb-ids.h| 26 +- > > drivers/media/dvb/dvb-usb/dvb-usb-init.c |2 +- > > drivers/media/dvb/dvb-usb/gp8psk-fe.c | 84 +- > > drivers/media/dvb/dvb-usb/gp8psk.c | 93 +- > > drivers/media/dvb/dvb-usb/gp8psk.h | 32 +- > > drivers/media/dvb/dvb-usb/vp7045.c |2 +- > > drivers/media/dvb/frontends/Kconfig| 33 +- > > drivers/media/dvb/frontends/Makefile |4 + > > drivers/media/dvb/frontends/bcm3510.c |1 - > > drivers/media/dvb/frontends/cx22700.c |1 - > > drivers/media/dvb/frontends/cx24110.c |1 - > > drivers/media/dvb/frontends/cx24123.c |1 - > > drivers/media/dvb/frontends/dib0070.c | 580 > > drivers/media/dvb/frontends/dib0070.h | 44 + > > drivers/media/dvb/frontends/dib3000mb.c|1 - > > drivers/media/dvb/frontends/dib3000mc.c| 192 ++- > > drivers/media/dvb/frontends/dib7000m.c | 727 ++ > > drivers/media/dvb/frontends/dib7000p.c | 908 > > drivers/media/dvb/frontends/dib7000p.h | 14 +- > > drivers/media/dvb/frontends/dibx000_common.h | 57 +- > > drivers/media/dvb/frontends/dvb-pll.c | 147 ++- > > drivers/media/dvb/frontends/dvb_dummy_fe.c |1 - > > drivers/media/dvb/frontends/isl6421.c |1 -
Re: [v4l-dvb-maintainer] [GIT PATCHES] V4L/DVB changes for 2.6.24
On 10/11/07, Linus Torvalds <[EMAIL PROTECTED]> wrote: > > > On Thu, 11 Oct 2007, Markus Rechberger wrote: > > > > the chances of the em28xx are not accepted from my side since the latest > code > > which supports way more hardware is offtree for various reasons. > > Well, I've talked to various people, and none of the main kernel people > end up being at all interested in a kernel that has external dependencies > on binary blobs for tuners. > the drivers are all opensource and the code is available. > So right now it seems like while I would personally want to have more > vendors supprt their own drivers, if that in this case means that we'd > have to have user-space and unmaintainable binaries to tune the cards, > everybody seems to hate that idea. > For me the reason is that some drivers in the kernel which that driver depends on are broken now. Those drivers got broken by several people who disagree with me. My conclusion after providing patches to fix those things is that I won't run after those people anymore. I'm not going to have further discussions with those people about it since there are enough other outstanding things to do with that driver. After 1 1/2 years I'm just fed up with it now and I want to continue to improve the driver. > As such, the old and decrepit em28xx driver seems more useful to people, > since at least it supports the limited set of hardware on its own. it does not since it's broken and feature limited. On the other side it requires a firmware from userspace too so I don't think it matters at all if the algorithm is done in kernelspace or userspace since it depends on such a blob (and I cannot get the source for that firmware, if someone's interested in that he has to disassemble the firmware). 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/
Re: [v4l-dvb-maintainer] [GIT PATCHES] V4L/DVB changes for 2.6.24
On 10/11/07, Chuck Ebbert <[EMAIL PROTECTED]> wrote: > On 10/10/2007 07:24 PM, Markus Rechberger wrote: > > > > To point to more changes within the available driver which hasn't been > merged > > within the last 1 1/2 years: > > * it supports non usbaudio based video devices. > > * has support for dvb-t/atsc > > * allows multiple device node access in case of analogue TV > > * has teletext/VBI support for PAL. > > * it supports modules which are now in userspace instead of > > kernelspace due disagreements with some developers for 1 1/2 years. > > * I do not agree with certain developers who do not have any experience > > with certain parts of the code for redoing it a 4th time now. My patience > > is over, which includes the company support in my back to get those > > devices supported. > > > > Do you plan on maintaining your own private driver tree for all of eternity? > I plan to tidy it up for inclusion and put everything together to get it work properly. The code which is in the kernel is around 5 % done, the code which is available on mcentral.de is around 50% done. It still requires some work to get _all_ devices supported, and keeping the development process in an endless loop and depending on people who have no idea and don't care about certain requirements is no option. The upcoming devices which use other chips and which have more features will at least also use those drivers. I expect that it will pump up the driver to support more than 100 devices within the next year. 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/
Re: [v4l-dvb-maintainer] [GIT PATCHES] V4L/DVB changes for 2.6.24
On 10/11/07, Andrew Morton <[EMAIL PROTECTED]> wrote: > On Thu, 11 Oct 2007 01:00:39 +0200 > "Markus Rechberger" <[EMAIL PROTECTED]> wrote: > > Please don't send 900 line emails to which you have added only an additional > paragraph. > > > > drivers/media/video/em28xx/em28xx-core.c |1 - > > > drivers/media/video/em28xx/em28xx-input.c |1 - > > > drivers/media/video/em28xx/em28xx-video.c |6 +- > > > > not accepted > > Until your attempt to get the userspace-driver work merged into the kernel > is successful (and from my reading of last month's discussion it is nowhere > near that), we should continue to maintain the present driver. > > If you choose to not participate in that maintenance then others will need > to do their best in this regard. > > What we should not and will not do is to permit the current driver to be > held hostage to your attempt to force a controversial and apparently > unwelcome change into the tree. > It makes no sense to keep the kernel driver uptodate, it would make more sense to support the latest driver (which some people are supporting). I just had a look at the driver downloads it makes around 600 downloads for september for this driver. If someone's interested in those stats I can give access to it privatly. The current option for people who own such a device is to take the driver from mcentral.de. 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/
Re: [v4l-dvb-maintainer] [GIT PATCHES] V4L/DVB changes for 2.6.24
On 10/11/07, Andrew Morton <[EMAIL PROTECTED]> wrote: > On Thu, 11 Oct 2007 07:09:47 +0200 "Markus Rechberger" > <[EMAIL PROTECTED]> wrote: > > > On 10/11/07, Andrew Morton <[EMAIL PROTECTED]> wrote: > > > On Thu, 11 Oct 2007 01:00:39 +0200 > > > "Markus Rechberger" <[EMAIL PROTECTED]> wrote: > > > > > > Please don't send 900 line emails to which you have added only an > additional > > > paragraph. > > > > > > > > drivers/media/video/em28xx/em28xx-core.c |1 - > > > > > drivers/media/video/em28xx/em28xx-input.c |1 - > > > > > drivers/media/video/em28xx/em28xx-video.c |6 +- > > > > > > > > not accepted > > > > > > Until your attempt to get the userspace-driver work merged into the > kernel > > > is successful (and from my reading of last month's discussion it is > nowhere > > > near that), we should continue to maintain the present driver. > > > > > > If you choose to not participate in that maintenance then others will > need > > > to do their best in this regard. > > > > > > What we should not and will not do is to permit the current driver to be > > > held hostage to your attempt to force a controversial and apparently > > > unwelcome change into the tree. > > > > > > > It makes no sense to keep the kernel driver uptodate, > > It makes heaps of sense to keep the in-tree driver up to date if the > out-of-tree driver is unmergeable, which appears to be the case. > what is unmergeable? > > it would make > > more sense to support the latest driver (which some people are > > supporting). > > But that ignores all of last month's discussion and the various > reservations which various people have expressed. > There were discussions since the beginning of 2006 which lead nowhere. It finally turned out to be a personal issue between developers and to stop those useless discussions and to not having to rely on an incomplete API and not having to strip off the sample drivers the alternative way was developed. > Please take my advise, based upon my experience in kernel development: I > don't expect that we'll be merging the mcentral.de driver in anything like > its present form. > > So we must continue to maintain and evolve the kernel.org driver. > > > I just had a look at the driver downloads it makes around 600 > > downloads for september for this driver. If someone's interested in > > those stats I can give access to it privatly. > > The current option for people who own such a device is to take the > > driver from mcentral.de. > > Well that's a shame. But we have n,000 drivers in-tree which work OK > without doing unusual and disturbing user/kernel splits. > ahm, there are more problems than you might think about... * broken drivers (eg saa7115, incomplete driver tvp5150) * limited API which is managed by a few (DVB/V4L) * having to deal with people who disagree alot I submitted the patches RFCs and didn't get proper comments back then this doesn't motivate me in any way to continue the work and spend any efforts in getting companies to release their sample drivers. As pointed out it's possible to release the complete driver in userland even as binary driver if someone wants to, unless someone kicks out usbfs. But the conversion would take a while. And regarding the plans of the other drivers I pointed out what my plans are. 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/
Re: [v4l-dvb-maintainer] [GIT PATCHES] V4L/DVB changes for 2.6.24
On 10/11/07, Aurelien Jarno <[EMAIL PROTECTED]> wrote: > Markus Rechberger a écrit : > > On 10/11/07, Linus Torvalds <[EMAIL PROTECTED]> wrote: > >> As such, the old and decrepit em28xx driver seems more useful to people, > >> since at least it supports the limited set of hardware on its own. > > > > it does not since it's broken and feature limited. On the other side > > I have a device which works perfectly with it if you add the vendor and > product ID to the list. I don't really call that broken. And it doesn't > need a firmware. > Aurelien, the device you're using is around 2 years old. You're one of the lucky ones, I have tonns of support mails in my mail account from people who own almost a similar device but with different videodecoders which are not fully supported in the kernel or which worked and got broken during the time. It took me around 4 hours to debug such an issue last years remotly with an enduser (which includes that noone cared to ask me if I'm fine with such an update, neither did someone ask people who own such devices that they should test the changes). Please also take other devices and upcoming devices into account, since i'm willing to spend that time and since I'm in contact with various companies who provide several components of those devices. > Please think that a lot of persons do not have enough knowledge to > compile out of tree drivers, and that a lot more do not even know about > this out of tree driver. > this is what all is about, the project does not depend on certain broken drivers anymore. And people who initially disagreed without having any solution nor contributed any code can continue to play their game without having an impact on that driver anymore. 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/
Re: [v4l-dvb-maintainer] [GIT PATCHES] V4L/DVB changes for 2.6.24
On 10/11/07, Marcel Siegert <[EMAIL PROTECTED]> wrote: > Markus Rechberger schrieb: > > On 10/11/07, Aurelien Jarno <[EMAIL PROTECTED]> wrote: > >> Markus Rechberger a écrit : > >>> On 10/11/07, Linus Torvalds <[EMAIL PROTECTED]> wrote: > >>>> As such, the old and decrepit em28xx driver seems more useful to > people, > >>>> since at least it supports the limited set of hardware on its own. > >>> it does not since it's broken and feature limited. On the other side > >> I have a device which works perfectly with it if you add the vendor and > >> product ID to the list. I don't really call that broken. And it doesn't > >> need a firmware. > >> > > > > Aurelien, > > > > the device you're using is around 2 years old. You're one of the lucky > > ones, I have tonns of support mails in my mail account from people who > > own almost a similar device but with different videodecoders which are > > not fully supported in the kernel or which worked and got broken > > during the time. > > It took me around 4 hours to debug such an issue last years remotly > > with an enduser (which includes that noone cared to ask me if I'm fine > > with such an update, neither did someone ask people who own such > > devices that they should test the changes). > > Please also take other devices and upcoming devices into account, > > since i'm willing to spend that time and since I'm in contact with > > various companies who provide several components of those devices. > > > >> Please think that a lot of persons do not have enough knowledge to > >> compile out of tree drivers, and that a lot more do not even know about > >> this out of tree driver. > >> > > > > this is what all is about, the project does not depend on certain > > broken drivers anymore. And people who initially disagreed without > > having any solution nor contributed any code can continue to play > > their game without having an impact on that driver anymore. > > > > Markus > > markus, > > its the same old story you are telling over and over again. > > of course there might be a huge community builded up the > last month @ mcentral, > of course your driver supports newer devices, > > BUT > > the same old story is - and you always miss that part > > we discussed a lot on your changes and also ACCEPTED those > for merging, if you would have changed your UNNECCESSARY touching > of dvb-core. its proven that things could work without that > nacked change to dvb core. but, you decided to stop discussion then, > and went away to perform your own tree/userspace thing. > > as linus and andrew stated within this thread they think they will not > merge your code like it is cause of different reasons, > i am wondering a bit whats your next step is. > I didn't read a clean statement about it. If so I won't continue to pull out opensource drivers from that company. Marcel, you haven't been and you are not into that topic otherwise you'd write about missing parts and address codeparts which I have mentioned in the past which are not ok in the kernel and how to solve that best. I remember the mail [1] where you (and Michael) tried to point me to something that doesn't work out. Please get into the whole topic which includes studying the requirements and what parts I'm complaining about. Markus (just for the record, although it's not relevant anymore) http://threebit.net/mail-archive/video4linux/msg07548.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: [v4l-dvb-maintainer] [GIT PATCHES] V4L/DVB changes for 2.6.24
On 10/11/07, Pádraig Brady <[EMAIL PROTECTED]> wrote: > Aidan Thornton wrote: > > I looked at this recently, and I'm not sure the core em28xx code was > > really that different (at least, pre-userspace). Most of the core > > changes seemed to be related to Markus' driver having (semi-working) > > VBI support. I haven't tried this recently; I disabled it a while back > > because it had a bug that caused a kernel panic half the time when > > attempting to record something with MythTV. > > > > The in-kernel driver looks mostly sound, though I can't test it > > myself. (One other interesting thing that was added in Markus' driver > > is various v4l1 ioctls, which may be useful to some people.) > > Yes, for example VLC doesn't support v4l2 yet. > Here is a patch I back ported to 2.6.17 last year. > http://www.pixelbeat.org/patches/linux-2.6.17-em28xx-v4l1.diff > I didn't try to get it merged as I thought Markus would do it, > but looks like that's unlikely now. > > Also here is a patch to allow shared access to the video device > (so you can have a separate tuner program to VLC for example): > http://www.pixelbeat.org/patches/linux-2.6.17-em28xx-shared.diff > > > Incidentally, I notice you appear to be developing userspace drivers > > for the tvp5150 and zl10353. Is that really necessary? > > It is necessary if Markus wants to stop people merging code back from > his in-kernel driver fork. Call me a cynic, but I'm confused about Markus' > motives in all this. > The tvp5150 as well as several other drivers have some slight changes in it to get some devices work. My motivation behind it is that since I don't agree with certain linuxtv development paths and it makes it alot easier to handle prewritten code from some companies. > Markus, please do the right thing and just merge your code! > (and please don't reply this giving reasons you won't/can't do this). > Merge the bridging code and the issue is done, the other guys should go their own paths with their own drivers if they want so. Time will show what will be better in the end. There are not so many devices out there which have newer requirements, although the em28xx is a good example for at least one device which doesn't fit. If someone's looking for another disagreement between developers (which my code is not part of): http://thread.gmane.org/gmane.linux.drivers.dvb/36583 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/
Re: [v4l-dvb-maintainer] [GIT PATCHES] V4L/DVB changes for 2.6.24
On 10/11/07, Marcel Siegert <[EMAIL PROTECTED]> wrote: > Markus Rechberger schrieb: > > On 10/11/07, Marcel Siegert <[EMAIL PROTECTED]> wrote: > >> Markus Rechberger schrieb: > >>> On 10/11/07, Aurelien Jarno <[EMAIL PROTECTED]> wrote: > >>>> Markus Rechberger a écrit : > >>>>> On 10/11/07, Linus Torvalds <[EMAIL PROTECTED]> wrote: > >>>>>> As such, the old and decrepit em28xx driver seems more useful to > >> people, > >>>>>> since at least it supports the limited set of hardware on its own. > >>>>> it does not since it's broken and feature limited. On the other side > >>>> I have a device which works perfectly with it if you add the vendor and > >>>> product ID to the list. I don't really call that broken. And it doesn't > >>>> need a firmware. > >>>> > >>> Aurelien, > >>> > >>> the device you're using is around 2 years old. You're one of the lucky > >>> ones, I have tonns of support mails in my mail account from people who > >>> own almost a similar device but with different videodecoders which are > >>> not fully supported in the kernel or which worked and got broken > >>> during the time. > >>> It took me around 4 hours to debug such an issue last years remotly > >>> with an enduser (which includes that noone cared to ask me if I'm fine > >>> with such an update, neither did someone ask people who own such > >>> devices that they should test the changes). > >>> Please also take other devices and upcoming devices into account, > >>> since i'm willing to spend that time and since I'm in contact with > >>> various companies who provide several components of those devices. > >>> > >>>> Please think that a lot of persons do not have enough knowledge to > >>>> compile out of tree drivers, and that a lot more do not even know about > >>>> this out of tree driver. > >>>> > >>> this is what all is about, the project does not depend on certain > >>> broken drivers anymore. And people who initially disagreed without > >>> having any solution nor contributed any code can continue to play > >>> their game without having an impact on that driver anymore. > >>> > >>> Markus > >> markus, > >> > >> its the same old story you are telling over and over again. > >> > >> of course there might be a huge community builded up the > >> last month @ mcentral, > >> of course your driver supports newer devices, > >> > >> BUT > >> > >> the same old story is - and you always miss that part > >> > >> we discussed a lot on your changes and also ACCEPTED those > >> for merging, if you would have changed your UNNECCESSARY touching > >> of dvb-core. its proven that things could work without that > >> nacked change to dvb core. but, you decided to stop discussion then, > >> and went away to perform your own tree/userspace thing. > >> > >> as linus and andrew stated within this thread they think they will not > >> merge your code like it is cause of different reasons, > >> i am wondering a bit whats your next step is. > >> > > > > I didn't read a clean statement about it. If so I won't continue to > > pull out opensource drivers from that company. > > Marcel, you haven't been and you are not into that topic otherwise > > you'd write about missing parts and address codeparts which I have > > mentioned in the past which are not ok in the kernel and how to solve > > that best. > > saving my time instead of commenting your code does not mean i am not > into it. as far as i remember i did say, that the api mixup within > dvb-core is NOT wanted and there are solutions for other devices, > that show it can be done otherwise. i must admit it would be a different > way but the only answer you said was "No, i wont do that" > > please go back through the irc logs on linuxtv.org and find the > appropiate place. > > > I remember the mail [1] where you (and Michael) tried to point me to > > something that doesn't work out. Please get into the whole topic which > > includes studying the requirements and what parts I'm complaining > > about. > as you may remember, i also offered you to ack a MERGE AS IS base for > your code in a private conversation on irc.
Re: [GIT PATCH] USB fixes for 2.6.24-rc5
Hi, did anyone already take care about: http://www.mail-archive.com/[EMAIL PROTECTED]/msg55641.html the fix seems to paper the issue although it happened with other people too now, so I wonder if there's any progress in that area? thanks & have a nice Christmas, Markus On Dec 23, 2007 8:24 AM, Greg KH <[EMAIL PROTECTED]> wrote: > Here are some USB fixes and new device ids against your 2.6.24-rc6 git > tree. > > Please pull from: > master.kernel.org:/pub/scm/linux/kernel/git/gregkh/usb-2.6.git/ > > The full patches will be sent to the linux-usb mailing list (note the > address change), if anyone wants to see them. > > thanks, > > greg k-h > > > > drivers/usb/gadget/fsl_usb2_udc.c |2 +- > drivers/usb/serial/cp2101.c |1 + > drivers/usb/serial/sierra.c |2 ++ > 3 files changed, 4 insertions(+), 1 deletions(-) > > --- > > Kevin R Page (1): > USB: VID/PID update for sierra > > Martin Kusserow (1): > USB: New device ID for the CP2101 driver > > Peter Korsgaard (1): > USB: Unbreak fsl_usb2_udc > > -- > 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/ > -- http://www.couchsurfing.com/people/mrec -- 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/
USB deadlock after resume
Hi, I'm looking at the linux uvc driver, and noticed after resuming my notebook it deadlocks at usb_set_interface. The linux kernel version on that notebook is 2.6.21.4, I searched around and haven't found any such bugreports. I wonder if anyone has ever heard about such a problem? I'm digging closer into that issue now.. thanks, 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/
Re: USB deadlock after resume
On 11/21/07, Mark Lord <[EMAIL PROTECTED]> wrote: > Markus Rechberger wrote: > > Hi, > > > > I'm looking at the linux uvc driver, and noticed after resuming my > .. > > Pardon me.. what is the "uvc" driver? Which module/source file is that? > http://linux-uvc.berlios.de/ it's not yet included in the kernel sources although many distributions already ship it. A "dry" run putting the device into sleep mode works fine (I added a proc interface for calling those suspend/resume function). 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/
Re: USB deadlock after resume
On 11/21/07, Markus Rechberger <[EMAIL PROTECTED]> wrote: > On 11/21/07, Mark Lord <[EMAIL PROTECTED]> wrote: > > Markus Rechberger wrote: > > > Hi, > > > > > > I'm looking at the linux uvc driver, and noticed after resuming my > > .. > > > > Pardon me.. what is the "uvc" driver? Which module/source file is that? > > > > http://linux-uvc.berlios.de/ it's not yet included in the kernel > sources although many distributions already ship it. > A "dry" run putting the device into sleep mode works fine (I added a > proc interface for calling those suspend/resume function). > it's not just usb_set_interface that hangs actually. It seems to hang at wait_event(usb_kill_urb_queue, atomic_read(&urb->use_count) == 0); in drivers/usb/core/urb.c after resuming. I disabled access to the usb subsystem in the uvc driver, although connecting any other usb storage fails too, just at the same point. The hardware is: 00:1d.0 USB Controller: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) USB UHCI #1 (rev 04) (8086:2658) 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/
Re: USB deadlock after resume
On 11/21/07, Oliver Neukum <[EMAIL PROTECTED]> wrote: > Am Mittwoch 21 November 2007 schrieb Markus Rechberger: > > On 11/21/07, Markus Rechberger <[EMAIL PROTECTED]> wrote: > > > On 11/21/07, Mark Lord <[EMAIL PROTECTED]> wrote: > > > > Markus Rechberger wrote: > > > > > Hi, > > > > > > > > > > I'm looking at the linux uvc driver, and noticed after resuming my > > > > .. > > > > > > > > Pardon me.. what is the "uvc" driver? Which module/source file is > that? > > > > > > > > > > http://linux-uvc.berlios.de/ it's not yet included in the kernel > > > sources although many distributions already ship it. > > > A "dry" run putting the device into sleep mode works fine (I added a > > > proc interface for calling those suspend/resume function). > > > > > > > it's not just usb_set_interface that hangs actually. > > It seems to hang at > > > > wait_event(usb_kill_urb_queue, atomic_read(&urb->use_count) == 0); > > > > in drivers/usb/core/urb.c after resuming. I disabled access to the usb > > subsystem in the uvc driver, although connecting any other usb storage > > fails too, just at the same point. > > Which URB is usb_kill_urb() called for? > it's the usb_control_message which calls usb_kill_urb if I haven't got it wrong. (if you're looking for some other information please let me know) Although, I got a bit further with it. The error seems to happen earlier already. If I load the driver, and do not access the device after suspending all usb_control commands fail with -71 eproto. Reloading the driver doesn't help at tht point, only reconnecting the device does. The data is transfered using bulk transfer. 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/
Re: USB deadlock after resume
On 11/21/07, Markus Rechberger <[EMAIL PROTECTED]> wrote: > On 11/21/07, Oliver Neukum <[EMAIL PROTECTED]> wrote: > > Am Mittwoch 21 November 2007 schrieb Markus Rechberger: > > > On 11/21/07, Markus Rechberger <[EMAIL PROTECTED]> wrote: > > > > On 11/21/07, Mark Lord <[EMAIL PROTECTED]> wrote: > > > > > Markus Rechberger wrote: > > > > > > Hi, > > > > > > > > > > > > I'm looking at the linux uvc driver, and noticed after resuming my > > > > > .. > > > > > > > > > > Pardon me.. what is the "uvc" driver? Which module/source file is > > that? > > > > > > > > > > > > > http://linux-uvc.berlios.de/ it's not yet included in the kernel > > > > sources although many distributions already ship it. > > > > A "dry" run putting the device into sleep mode works fine (I added a > > > > proc interface for calling those suspend/resume function). > > > > > > > > > > it's not just usb_set_interface that hangs actually. > > > It seems to hang at > > > > > > wait_event(usb_kill_urb_queue, atomic_read(&urb->use_count) == 0); > > > > > > in drivers/usb/core/urb.c after resuming. I disabled access to the usb > > > subsystem in the uvc driver, although connecting any other usb storage > > > fails too, just at the same point. > > > > Which URB is usb_kill_urb() called for? > > > > it's the usb_control_message which calls usb_kill_urb if I haven't got > it wrong. (if you're looking for some other information please let me > know) > Although, I got a bit further with it. The error seems to happen > earlier already. > If I load the driver, and do not access the device after suspending > all usb_control commands fail with -71 eproto. > > Reloading the driver doesn't help at tht point, only reconnecting the > device does. > > The data is transfered using bulk transfer. > Do you know any good way for performing a softreset within the driver? The video application should get a continuous datastream after resuming the notebook, so the driver shouldn't be unloaded. The driver also keeps a list of previous camera settings which should be set up again after resuming. Stopping the video application and reattaching the device using ACPI (this board supports reconnecting the device using ACPI) should be avoided. 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/
Re: USB deadlock after resume
On 11/21/07, Markus Rechberger <[EMAIL PROTECTED]> wrote: > On 11/21/07, Markus Rechberger <[EMAIL PROTECTED]> wrote: > > On 11/21/07, Oliver Neukum <[EMAIL PROTECTED]> wrote: > > > Am Mittwoch 21 November 2007 schrieb Markus Rechberger: > > > > On 11/21/07, Markus Rechberger <[EMAIL PROTECTED]> wrote: > > > > > On 11/21/07, Mark Lord <[EMAIL PROTECTED]> wrote: > > > > > > Markus Rechberger wrote: > > > > > > > Hi, > > > > > > > > > > > > > > I'm looking at the linux uvc driver, and noticed after resuming > my > > > > > > .. > > > > > > > > > > > > Pardon me.. what is the "uvc" driver? Which module/source file is > > > that? > > > > > > > > > > > > > > > > http://linux-uvc.berlios.de/ it's not yet included in the kernel > > > > > sources although many distributions already ship it. > > > > > A "dry" run putting the device into sleep mode works fine (I added a > > > > > proc interface for calling those suspend/resume function). > > > > > > > > > > > > > it's not just usb_set_interface that hangs actually. > > > > It seems to hang at > > > > > > > > wait_event(usb_kill_urb_queue, atomic_read(&urb->use_count) == 0); > > > > > > > > in drivers/usb/core/urb.c after resuming. I disabled access to the usb > > > > subsystem in the uvc driver, although connecting any other usb storage > > > > fails too, just at the same point. > > > > > > Which URB is usb_kill_urb() called for? > > > > > > > it's the usb_control_message which calls usb_kill_urb if I haven't got > > it wrong. (if you're looking for some other information please let me > > know) > > Although, I got a bit further with it. The error seems to happen > > earlier already. > > If I load the driver, and do not access the device after suspending > > all usb_control commands fail with -71 eproto. > > > > Reloading the driver doesn't help at tht point, only reconnecting the > > device does. > > > > The data is transfered using bulk transfer. > > > > Do you know any good way for performing a softreset within the driver? > The video application should get a continuous datastream after > resuming the notebook, so the driver shouldn't be unloaded. > The driver also keeps a list of previous camera settings which should > be set up again after resuming. Stopping the video application and > reattaching the device using ACPI (this board supports reconnecting > the device using ACPI) should be avoided. > ok usb_reset_device() did the job after resuming. First problem solved. 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/
Re: USB deadlock after resume
On 11/21/07, Oliver Neukum <[EMAIL PROTECTED]> wrote: > Am Mittwoch 21 November 2007 schrieb Markus Rechberger: > > > Which URB is usb_kill_urb() called for? > > > > > > > it's the usb_control_message which calls usb_kill_urb if I haven't got > > it wrong. (if you're looking for some other information please let me > > know) > > Although, I got a bit further with it. The error seems to happen > > earlier already. > > If I load the driver, and do not access the device after suspending > > all usb_control commands fail with -71 eproto. > > A timeout. You should add the RESET_RESUME quirk for your device. > usb_reset_device() from resume() is not a good idea. > ok this is good to know, although I have to stick with kernel 2.6.21.3 here. It's Laurent's driver best would be to check for the specific kernelversion and do whatever is appropriate. thanks, 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/
Re: [linux-usb-devel] USB deadlock after resume
On 11/21/07, Alan Stern <[EMAIL PROTECTED]> wrote: > On Wed, 21 Nov 2007, Markus Rechberger wrote: > > > > > it's not just usb_set_interface that hangs actually. > > > > It seems to hang at > > > > > > > > wait_event(usb_kill_urb_queue, atomic_read(&urb->use_count) == 0); > > > > > > > > in drivers/usb/core/urb.c after resuming. I disabled access to the usb > > > > subsystem in the uvc driver, although connecting any other usb storage > > > > fails too, just at the same point. > > > > > > Which URB is usb_kill_urb() called for? > > > > > > > it's the usb_control_message which calls usb_kill_urb if I haven't got > > it wrong. (if you're looking for some other information please let me > > know) > > Although, I got a bit further with it. The error seems to happen > > earlier already. > > If I load the driver, and do not access the device after suspending > > all usb_control commands fail with -71 eproto. > > That's very strange. Getting -71 errors is understandable; it > indicates that the device can't handle being suspended. But the > wait_event() line still shouldn't hang. If it does, it indicates that > there's something wrong with the USB host controller, not just the > device. > > Can you try testing this on a different sort of computer? > Not really, suspending doesn't work at all on my other notebook it just freezes.. I'm basically trying to get that driver work on my eee PC [1], it's cheap and tiny so I don't expect anything special in there.. The system is preloaded with Xandros (it's debian etch with a few custom applications) and linux 2.6.21.4. The system still locks up, although only if I leave the video application running during suspending. I don't have to reload the driver anymore after resuming if the video node doesn't get accessed (I'm looking for races in the uvc driver at the moment). thanks, Markus [1] http://eeepc.asus.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-usb-devel] USB deadlock after resume
On 11/21/07, Laurent Pinchart <[EMAIL PROTECTED]> wrote: > On Wednesday 21 November 2007, Markus Rechberger wrote: > > On 11/21/07, Alan Stern <[EMAIL PROTECTED]> wrote: > > > On Wed, 21 Nov 2007, Markus Rechberger wrote: > > > > > > it's not just usb_set_interface that hangs actually. > > > > > > It seems to hang at > > > > > > > > > > > > wait_event(usb_kill_urb_queue, atomic_read(&urb->use_count) == 0); > > > > > > > > > > > > in drivers/usb/core/urb.c after resuming. I disabled access to the > > > > > > usb subsystem in the uvc driver, although connecting any other usb > > > > > > storage fails too, just at the same point. > > > > > > > > > > Which URB is usb_kill_urb() called for? > > > > > > > > it's the usb_control_message which calls usb_kill_urb if I haven't got > > > > it wrong. (if you're looking for some other information please let me > > > > know) > > > > Although, I got a bit further with it. The error seems to happen > > > > earlier already. > > > > If I load the driver, and do not access the device after suspending > > > > all usb_control commands fail with -71 eproto. > > > > > > That's very strange. Getting -71 errors is understandable; it > > > indicates that the device can't handle being suspended. But the > > > wait_event() line still shouldn't hang. If it does, it indicates that > > > there's something wrong with the USB host controller, not just the > > > device. > > > > > > Can you try testing this on a different sort of computer? > > > > Not really, suspending doesn't work at all on my other notebook it > > just freezes.. > > I'm basically trying to get that driver work on my eee PC [1], it's > > cheap and tiny so I don't expect anything special in there.. > > The system is preloaded with Xandros (it's debian etch with a few > > custom applications) and linux 2.6.21.4. > > If I'm not mistaken, the EeePC ACPI bios plays tricks with the USB ports > during suspend/resume. You should really test suspend/resume with the same > camera chipset on a proper computer. If the camera still crashes, we have a > buggy chipset which needs a reset quirk. If it doesn't, the EeePC ACPI bios > is probably at fault. Adding quirks and hacks to the Linux kernel (either in > the USB stack or the uvcvideo driver) is pretty pointless if the bios tries > to make the system crash. The ACPI code should be fixed in that case. > With ACPI it seems to be possible to disconnect the uvc device. I tested the suspend/resume functions by adding a proc interface to it, and it worked properly. Although the eee PC also suspends the underlying bus where the usb controller is connected to (which is PCI or PCIe) > > The system still locks up, although only if I leave the video > > application running during suspending. I don't have to reload the > > driver anymore after resuming if the video node doesn't get accessed > > (I'm looking for races in the uvc driver at the moment). > The current state I revealed is that after suspend if the video node isn't used it's not necessary to reconnect the device nor to reload the driver again if that reset is implemented. That eee PC comes with 2.6.21.3 which has no such reset quirk feature in the usbcore (that's what I initially meant actually). If a videoapplication accesses the nodes during suspend the notebook won't come back again. I also think it's faulty hardware in that case but I'm moreover looking for a solution for it. My other intel notebook doesn't even awake from suspend to ram, and for some reason suspend to disk just didn't work as expected either (Acer Travelmate 660). thanks for the feedback, 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/
Re: FW: 2.6.24 breaks BIOS updates on all Dell machines
[EMAIL PROTECTED] wrote:
Markus, I see you were accidentally left off the cc: list on this bug.
The change was yours, so I suspect you'll have an opinion to share with
LKML.
Thanks,
Matt
--
Matt Domsch
Linux Technology Strategist, Dell Office of the CTO
linux.dell.com & www.dell.com/linux
-Original Message-
From: Greg KH [mailto:[EMAIL PROTECTED]
Sent: Tuesday, January 29, 2008 12:44 AM
To: Brown, Michael E
Cc: Jos?? Luis Tall??n; Warzecha, Douglas; Salunke, Abhay;
linux-kernel@vger.kernel.org; Domsch, Matt; [EMAIL PROTECTED]
Subject: Re: 2.6.24 breaks BIOS updates on all Dell machines
On Tue, Jan 29, 2008 at 12:32:44AM -0600, Michael E Brown wrote:
BIOS updates are broken on all Dell systems due to Commit
109f0e93b6b728f03c1eb4af02bc25d71b646c59, which is now in 2.6.24.
static inline void fw_setup_device_id(struct device *f_dev, struct
device *dev)
{
- /* XXX warning we should watch out for name collisions */
- strlcpy(f_dev->bus_id, dev->bus_id, BUS_ID_SIZE);
+ snprintf(f_dev->bus_id, BUS_ID_SIZE, "firmware-%s",
dev->bus_id);
}
Two programs are broken by this change:
1) dellBiosUpdate, which is part of libsmbios
2) All of the Dell Update Packages (DUPs) that are part of Dell
OpenManage: each BIOS release for each of 3-4 dozen platforms.
These programs are broken due to the pathname change from
/sys/class/firmware/dell_rbu/ to
/sys/class/firmware/firmware-dell_rbu/loading.
Realistically, I can fix libsmbios in a couple of weeks, but there is
no
way that we can go back and fix a couple hundred DUP packages for this
change. If this stays, we are looking at over 6 months before we have
an
officially-available Dell OpenManage that can deal with it, and that
would be for new BIOS releases only, I suspect.
Some of the relevant threads from when this was submitted and
accepted:
http://lkml.org/lkml/2005/5/23/73
http://lkml.org/lkml/2005/5/23/62
Due to the extremely large and disruptive nature of this bug, it would
be nice to get a 2.6.24.1 with this patch reverted.
I have copied the relevant developers at Dell who maintain this
driver.
Please preserve the cc: list when replying.
Fair enough, I have no problem reverting this.
Anyone want to keep it in?
Hi Greg,
reverting this breaks support for several media (DVB/V4L) devices. I
would have to look up some bugreports the same name collision happened
with several different drivers.
There was a comment in the fw code to watch out for name collisions
earlier already, so it needs a fix somewhere.
Here's some history:
http://mcentral.de/wiki/index.php5/Bugtracker#i2c_dev_problem
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/
Re: [linux-dvb] SAA7160/2
Creating a wiki site for Empia based devices and setting up a Mailinglist worked out well. That way you also get the email addresses of people who are very likely interested in such device. Markus On 8/1/07, Manu Abraham <[EMAIL PROTECTED]> wrote: > 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 > > ___ > linux-dvb mailing list > [EMAIL PROTECTED] > http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb > -- Markus Rechberger - 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_frontend_ioctl(): fix check-after-use
On 8/1/07, Manu Abraham <[EMAIL PROTECTED]> wrote:
> 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]>
>
This issue has been known for a while including some other problems at
that part.
http://article.gmane.org/gmane.linux.drivers.dvb/35351/match=patch+dvb_net+hotplugging+support
this includes a link where this and more got discussed in May.
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/
Re: [v4l-dvb-maintainer] [2.6 patch] dvb_frontend_ioctl(): fix check-after-use
On 8/11/07, Trent Piepho <[EMAIL PROTECTED]> wrote: > On Fri, 10 Aug 2007, Markus Rechberger wrote: > > On 8/1/07, Manu Abraham <[EMAIL PROTECTED]> wrote: > > > On 7/31/07, Adrian Bunk <[EMAIL PROTECTED]> wrote: > > > > The Coverity checker spotted that we have already oops'ed if "fe" was > > > NULL. > > > > > > > > --- linux-2.6.23-rc1-mm1/drivers/media/dvb/dvb-core/dvb_frontend.c.old > > > > +++ linux-2.6.23-rc1-mm1/drivers/media/dvb/dvb-core/dvb_frontend.c > > > > @@ -706,11 +706,11 @@ static int dvb_frontend_ioctl(struct ino > > > > - if (!fe || fepriv->exit) > > > > + if (fepriv->exit) > > > > return -ENODEV; > > > > This issue has been known for a while including some other problems at > > that part. > > > > > http://article.gmane.org/gmane.linux.drivers.dvb/35351/match=patch+dvb_net+hotplugging+support > > > > this includes a link where this and more got discussed in May. > > For dvb_net_close, I like the patch I already posted better. To fix the > check-after-use, it's not "use" part that's the problem, it's the "check" > part > that isn't necessary. > > I traced the dvb-net code, > http://article.gmane.org/gmane.linux.kernel/543689, > and I'm sure that dvbdev can't be NULL. > > My patch also deletes a few pieces of duplicated code by calling > dvb_generic_release(). > > The only problem is that practically no one uses dvb-net, so it's very hard > to > test these patches. > I didn't see this patch, it would be fine if it would get applied. > In all the dvb code, were is the locking for device open and release? I > don't > see it. What is preventing two threads from trying to open and/or close the > same dvb device at the same time? > Haven't looked at that yet, since I moreover work to get the em28xx driver included now. 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/
[PATCH] Firmware class name collision
Hi,
following patch fixes the i2c name collision with i2c-dev.
http://mcentral.de/wiki/index.php/Bugtracker#i2c_core_problem
This issue has been experienced with em28xx and saa7133 based devices.
I discussed that problem with Jean Delvare a while ago and he proposed
to add a prefix to the class name.
http://mcentral.de/~mrec/patches/firmware_class_name_collision.diff
Signed-off-by: Markus Rechberger <[EMAIL PROTECTED]>
index b24efd4..bfc54a1 100644
--- a/drivers/base/firmware_class.c
+++ b/drivers/base/firmware_class.c
@@ -297,8 +297,7 @@ firmware_class_timeout(u_long data)
static inline void fw_setup_device_id(struct device *f_dev, struct
device *dev)
{
- /* XXX warning we should watch out for name collisions */
- strlcpy(f_dev->bus_id, dev->bus_id, BUS_ID_SIZE);
+ snprintf(f_dev->bus_id, BUS_ID_SIZE, "fw-%s", dev->bus_id);
}
static int fw_register_device(struct device **dev_p, const char *fw_name,
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/
Re: [PATCH] Firmware class name collision
Hi Marcel,
Marcel Holtmann wrote:
Hi Markus,
following patch fixes the i2c name collision with i2c-dev.
http://mcentral.de/wiki/index.php/Bugtracker#i2c_core_problem
This issue has been experienced with em28xx and saa7133 based devices.
I discussed that problem with Jean Delvare a while ago and he proposed
to add a prefix to the class name.
http://mcentral.de/~mrec/patches/firmware_class_name_collision.diff
Signed-off-by: Markus Rechberger <[EMAIL PROTECTED]>
index b24efd4..bfc54a1 100644
--- a/drivers/base/firmware_class.c
+++ b/drivers/base/firmware_class.c
@@ -297,8 +297,7 @@ firmware_class_timeout(u_long data)
static inline void fw_setup_device_id(struct device *f_dev, struct
device *dev)
{
- /* XXX warning we should watch out for name collisions */
- strlcpy(f_dev->bus_id, dev->bus_id, BUS_ID_SIZE);
+ snprintf(f_dev->bus_id, BUS_ID_SIZE, "fw-%s", dev->bus_id);
}
I would prefer if we use "firmware-%s" since the "fw" might collide with
the new Firewire stack. Please change that and I agree.
firmware-%s sounds more informative and cannot be mistaken with firewire
yes.
Signed-off-by: Markus Rechberger <[EMAIL PROTECTED]>
http://mcentral.de/~mrec/patches/firmware_class_name_collision_2.diff
diff --git a/drivers/base/firmware_class.c b/drivers/base/firmware_class.c
index b24efd4..bfc54a1 100644
--- a/drivers/base/firmware_class.c
+++ b/drivers/base/firmware_class.c
@@ -297,8 +297,7 @@ firmware_class_timeout(u_long data)
static inline void fw_setup_device_id(struct device *f_dev, struct
device *dev)
{
- /* XXX warning we should watch out for name collisions */
- strlcpy(f_dev->bus_id, dev->bus_id, BUS_ID_SIZE);
+ snprintf(f_dev->bus_id, BUS_ID_SIZE, "firmware-%s", dev->bus_id);
}
static int fw_register_device(struct device **dev_p, const char *fw_name,
Acked-by: Marcel Holtmann <[EMAIL PROTECTED]>
Regards
Marcel
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Fix a memory leak in em28xx_usb_probe()
Hi Jesper,
On 8/9/07, Jesper Juhl <[EMAIL PROTECTED]> wrote:
> EHLO,
>
> If, in em28xx_usb_probe() the memory allocation
> dev->alt_max_pkt_size = kmalloc(32*
> dev->num_alt,GFP_KERNEL);
> fails, then we'll bail out and return -ENOMEM.
> The problem is that in that case we don't free the storage allocated
> to 'dev', thus causing a memory leak.
>
> This patch fixes the leak by freeing 'dev' before we return -ENOMEM.
> This fixes Coverity bug #647.
>
>
> Signed-off-by: Jesper Juhl <[EMAIL PROTECTED]>
Acked-by: Markus Rechberger <[EMAIL PROTECTED]>
thanks,
Markus
> ---
>
> drivers/media/video/em28xx/em28xx-video.c |1 +
> 1 files changed, 1 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/media/video/em28xx/em28xx-video.c
> b/drivers/media/video/em28xx/em28xx-video.c
> index 2c7b158..40307f3 100644
> --- a/drivers/media/video/em28xx/em28xx-video.c
> +++ b/drivers/media/video/em28xx/em28xx-video.c
> @@ -1772,6 +1772,7 @@ static int em28xx_usb_probe(struct usb_interface
> *interface,
> if (dev->alt_max_pkt_size == NULL) {
> em28xx_errdev("out of memory!\n");
> em28xx_devused&=~(1< + kfree(dev);
> return -ENOMEM;
> }
>
>
>
>
>
--
Markus Rechberger
-
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 changes for 2.6.24
On 10/11/07, Andrew Morton <[EMAIL PROTECTED]> wrote: > On Thu, 11 Oct 2007 01:00:39 +0200 > "Markus Rechberger" <[EMAIL PROTECTED]> wrote: > > Please don't send 900 line emails to which you have added only an additional > paragraph. > > > > drivers/media/video/em28xx/em28xx-core.c |1 - > > > drivers/media/video/em28xx/em28xx-input.c |1 - > > > drivers/media/video/em28xx/em28xx-video.c |6 +- > > > > not accepted > > Until your attempt to get the userspace-driver work merged into the kernel > is successful (and from my reading of last month's discussion it is nowhere > near that), we should continue to maintain the present driver. > > If you choose to not participate in that maintenance then others will need > to do their best in this regard. > > What we should not and will not do is to permit the current driver to be > held hostage to your attempt to force a controversial and apparently > unwelcome change into the tree. > (please read through it ... ) I didn't comment this one yet, so here a few further details. Note I'm not looking forward to annoy other developers I want to get that driver completly done. some background information on the further userspace idea: http://lists.freebsd.org/pipermail/freebsd-multimedia/2007-September/007497.html short overview, this driver has moved a massive amount to userspace: libtuner/ (libtuner.so) User-mode drivers for tuners, demodulators, and anything else that constitutes the "frontend". So how is this related to my project? This project can reuse all the userspace demods and tuner code which I have as they are including the floating point stuff. I had a discussion with Hans Verkuil (the IVTV maintainer) about my requirements and his answer was: 2:06 - However, it is a fact that the relationship between you and the linux(tv) community are strained to put it mildly. I remain convinced that none of this has any technical basis but has all to do with personality conflicts. To be honest, right now I think there is no solution in sight. This is a valid reason to consider stopping. the reason why I take the em28xx as hostage is, well I started with it and I work with that company and I don't see a way how to implement the latest devices without terrible hacks (and there are around 60 devices supported only by the current available driver and it will double that number since customers will change several chips on those boards) Due those "personal" conflicts I don't see how I can discuss it with the linuxtv people who are against me, I even tried to discuss this with Mauro (who never worked with a company in that area actually so he doesn't seem to understand what I try to achive, at least I haven't heard any technical reason why that work should be bad). Without any help to take aside those personal issues I don't see how this can be solved. I pulled all my linux opensource projects offline till this is cleared up I don't want to do 90% of all work and people taking over my project doing 10% of hacks for getting some credits. The long time support is not related to linux only. As for the BSD project, the developers who work with kaffeine and xine are fine with another interface which can support those BSD drivers, as for the linux world it would mean an easy abstraction to use i2c-dev with the existing userspace drivers without having to change a single line in those drivers. sorry for bothering but it seriously cost alot of my private time as well, 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/
Re: [v4l-dvb-maintainer] [GIT PATCHES] V4L/DVB changes for 2.6.24
On 10/14/07, Hans Verkuil <[EMAIL PROTECTED]> wrote: > On Sunday 14 October 2007 12:40:35 Markus Rechberger wrote: > > On 10/11/07, Andrew Morton <[EMAIL PROTECTED]> wrote: > > > On Thu, 11 Oct 2007 01:00:39 +0200 > > > "Markus Rechberger" <[EMAIL PROTECTED]> wrote: > > > > > > Please don't send 900 line emails to which you have added only an > > > additional paragraph. > > > > > > > > drivers/media/video/em28xx/em28xx-core.c |1 - > > > > > drivers/media/video/em28xx/em28xx-input.c |1 - > > > > > drivers/media/video/em28xx/em28xx-video.c |6 +- > > > > > > > > not accepted > > > > > > Until your attempt to get the userspace-driver work merged into the > > > kernel is successful (and from my reading of last month's > > > discussion it is nowhere near that), we should continue to maintain > > > the present driver. > > > > > > If you choose to not participate in that maintenance then others > > > will need to do their best in this regard. > > > > > > What we should not and will not do is to permit the current driver > > > to be held hostage to your attempt to force a controversial and > > > apparently unwelcome change into the tree. > > > > (please read through it ... ) > > > > I didn't comment this one yet, so here a few further details. Note > > I'm not looking forward to annoy other developers I want to get that > > driver completly done. > > > > some background information on the further userspace idea: > > http://lists.freebsd.org/pipermail/freebsd-multimedia/2007-September/ > >007497.html > > > > short overview, this driver has moved a massive amount to userspace: > > libtuner/ > > (libtuner.so) User-mode drivers for tuners, demodulators, and > > anything else that constitutes the "frontend". > > > > So how is this related to my project? This project can reuse all the > > userspace demods and tuner code which I have as they are including > > the floating point stuff. > > > > I had a discussion with Hans Verkuil (the IVTV maintainer) about my > > requirements and his answer was: > > > > 2:06 - However, it is a fact that the relationship between > > you and the linux(tv) community are strained to put it mildly. I > > remain convinced that none of this has any technical basis but has > > all to do with personality conflicts. To be honest, right now I think > > there is no solution in sight. This is a valid reason to consider > > stopping. > > Um, please ask next time when you want to quote from a private > discussion. > > To put it in perspective: I meant here that stopping the em28xx > development using GPL is a consideration, not to take em28xx hostage. > My first point in that same discussion was this: > > "hverkuil: - It is pointless to worry about what others might do with > your GPL code. Anyone can take it at any time and who knows, they might > succeed. Then again, they might not. In any case, it shouldn't be a > reason to consider stopping." > > The only people you are hurting by taking em28xx offline are the > end-users and yourself, I'm sorry to say. > Yes, but continuing as before keeping it aside of everything also hurts. I'm convinced that the roadmap which I aim at is fine there is code which works and which is valueable for other projects. What's the idea behind a forced separation? - One and the same code is also used as it is in Windows drivers. If someone wants to commit his free time in fixing or improving that work he's welcome to do so by touching it once 3 targets are affected. The roadmap also includes OSX which would be the 4th target. What's the value of having those shareable components which have a full implementation limited to linux which only supports a limited subset of those features (and it requires a rewrite to get it fit into the kernel, so those features will very likely get stripped off - this is the current way how it's done)? 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/
[patch] x86-64 ext2/ext3 datestamp problem
Hi, there is an issue with ext2/ext3 date stamps, if someone creates a file with a timestamp between 1902 and 1970(epoch 0) it will overflow and result in a higher date than 2038. $ touch --date "1905-01-01" test $ ls -lah test -rw-r--r-- 1 root root 0 Jan 1 1905 test (this is a cached value here) (remount the partition/clear the cache) $ ls -lah test -rw-r--r-- 1 root root 0 Feb 6 2041 test 11011000110001100111 .. -2051226000 (1905) 11011000110001100111 .. 2243741296 (2041) this was tested against linus git tree Markus -- Markus Rechberger Operating System Research Center AMD Saxony LLC & Co. KG diff --git a/fs/ext2/inode.c b/fs/ext2/inode.c index dd4e14c..9fa1bd6 100644 --- a/fs/ext2/inode.c +++ b/fs/ext2/inode.c @@ -1079,9 +1079,9 @@ void ext2_read_inode (struct inode * inode) } inode->i_nlink = le16_to_cpu(raw_inode->i_links_count); inode->i_size = le32_to_cpu(raw_inode->i_size); - inode->i_atime.tv_sec = le32_to_cpu(raw_inode->i_atime); - inode->i_ctime.tv_sec = le32_to_cpu(raw_inode->i_ctime); - inode->i_mtime.tv_sec = le32_to_cpu(raw_inode->i_mtime); + inode->i_atime.tv_sec = (signed)le32_to_cpu(raw_inode->i_atime); + inode->i_ctime.tv_sec = (signed)le32_to_cpu(raw_inode->i_ctime); + inode->i_mtime.tv_sec = (signed)le32_to_cpu(raw_inode->i_mtime); inode->i_atime.tv_nsec = inode->i_mtime.tv_nsec = inode->i_ctime.tv_nsec = 0; ei->i_dtime = le32_to_cpu(raw_inode->i_dtime); /* We now have enough fields to check if the inode was active or not. diff --git a/fs/ext3/inode.c b/fs/ext3/inode.c index beaf25f..5d171c0 100644 --- a/fs/ext3/inode.c +++ b/fs/ext3/inode.c @@ -2673,9 +2673,9 @@ void ext3_read_inode(struct inode * inode) } inode->i_nlink = le16_to_cpu(raw_inode->i_links_count); inode->i_size = le32_to_cpu(raw_inode->i_size); - inode->i_atime.tv_sec = le32_to_cpu(raw_inode->i_atime); - inode->i_ctime.tv_sec = le32_to_cpu(raw_inode->i_ctime); - inode->i_mtime.tv_sec = le32_to_cpu(raw_inode->i_mtime); + inode->i_atime.tv_sec = (signed)le32_to_cpu(raw_inode->i_atime); + inode->i_ctime.tv_sec = (signed)le32_to_cpu(raw_inode->i_ctime); + inode->i_mtime.tv_sec = (signed)le32_to_cpu(raw_inode->i_mtime); inode->i_atime.tv_nsec = inode->i_ctime.tv_nsec = inode->i_mtime.tv_nsec = 0; ei->i_state = 0;
Re: [patch] x86-64 ext2/ext3 datestamp problem
Signed-off-by: Markus Rechberger <[EMAIL PROTECTED]> Markus Rechberger wrote: > Hi, > > there is an issue with ext2/ext3 date stamps, if someone creates a file > with a timestamp between 1902 and 1970(epoch 0) it will overflow and > result in a higher date than 2038. > > $ touch --date "1905-01-01" test > $ ls -lah test > -rw-r--r-- 1 root root 0 Jan 1 1905 test (this is a cached value here) > (remount the partition/clear the cache) > $ ls -lah test > -rw-r--r-- 1 root root 0 Feb 6 2041 test > > 11011000110001100111 .. -2051226000 (1905) > 11011000110001100111 .. 2243741296 (2041) > > this was tested against linus git tree > > Markus > > > > > diff --git a/fs/ext2/inode.c b/fs/ext2/inode.c > index dd4e14c..9fa1bd6 100644 > --- a/fs/ext2/inode.c > +++ b/fs/ext2/inode.c > @@ -1079,9 +1079,9 @@ void ext2_read_inode (struct inode * inode) > } > inode->i_nlink = le16_to_cpu(raw_inode->i_links_count); > inode->i_size = le32_to_cpu(raw_inode->i_size); > - inode->i_atime.tv_sec = le32_to_cpu(raw_inode->i_atime); > - inode->i_ctime.tv_sec = le32_to_cpu(raw_inode->i_ctime); > - inode->i_mtime.tv_sec = le32_to_cpu(raw_inode->i_mtime); > + inode->i_atime.tv_sec = (signed)le32_to_cpu(raw_inode->i_atime); > + inode->i_ctime.tv_sec = (signed)le32_to_cpu(raw_inode->i_ctime); > + inode->i_mtime.tv_sec = (signed)le32_to_cpu(raw_inode->i_mtime); > inode->i_atime.tv_nsec = inode->i_mtime.tv_nsec = > inode->i_ctime.tv_nsec = 0; > ei->i_dtime = le32_to_cpu(raw_inode->i_dtime); > /* We now have enough fields to check if the inode was active or not. > diff --git a/fs/ext3/inode.c b/fs/ext3/inode.c > index beaf25f..5d171c0 100644 > --- a/fs/ext3/inode.c > +++ b/fs/ext3/inode.c > @@ -2673,9 +2673,9 @@ void ext3_read_inode(struct inode * inode) > } > inode->i_nlink = le16_to_cpu(raw_inode->i_links_count); > inode->i_size = le32_to_cpu(raw_inode->i_size); > - inode->i_atime.tv_sec = le32_to_cpu(raw_inode->i_atime); > - inode->i_ctime.tv_sec = le32_to_cpu(raw_inode->i_ctime); > - inode->i_mtime.tv_sec = le32_to_cpu(raw_inode->i_mtime); > + inode->i_atime.tv_sec = (signed)le32_to_cpu(raw_inode->i_atime); > + inode->i_ctime.tv_sec = (signed)le32_to_cpu(raw_inode->i_ctime); > + inode->i_mtime.tv_sec = (signed)le32_to_cpu(raw_inode->i_mtime); > inode->i_atime.tv_nsec = inode->i_ctime.tv_nsec = > inode->i_mtime.tv_nsec = 0; > > ei->i_state = 0; > -- Markus Rechberger Operating System Research Center AMD Saxony LLC & Co. KG - 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] x86-64 ext2/ext3 datestamp problem
H. Peter Anvin wrote: > Markus Rechberger wrote: >> Hi, >> >> there is an issue with ext2/ext3 date stamps, if someone creates a file >> with a timestamp between 1902 and 1970(epoch 0) it will overflow and >> result in a higher date than 2038. >> >> $ touch --date "1905-01-01" test >> $ ls -lah test >> -rw-r--r-- 1 root root 0 Jan 1 1905 test (this is a cached value here) >> (remount the partition/clear the cache) >> $ ls -lah test >> -rw-r--r-- 1 root root 0 Feb 6 2041 test >> >> 11011000110001100111 .. -2051226000 (1905) >> 11011000110001100111 .. 2243741296 (2041) >> >> this was tested against linus git tree >> > > I believe the timestamp fields in ext2/ext3 are defined as unsigned. > > -hpa > > My debian system's coreutils package only allows dates between 1902 and 2038, but it might be interesting to get that right if it's wrong. touch (GNU coreutils) 5.97 just says invalid dateformat to 2050-01-01 Markus -- Markus Rechberger Operating System Research Center AMD Saxony LLC & Co. KG - 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] x86-64 ext2/ext3 datestamp problem
H. Peter Anvin wrote: > Markus Rechberger wrote: >> My debian system's coreutils package only allows dates between 1902 and >> 2038, but it might be interesting to get that right if it's wrong. >> >> touch (GNU coreutils) 5.97 just says invalid dateformat to 2050-01-01 > > Lemme guess, you're on a 32-bit system... > I have both here, 64 and 32bit If I touch a file with 1905 on my 32bit system and remount the disk the date will remain at 1905 without any patch. 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/
Re: [patch] x86-64 ext2/ext3 datestamp problem
H. Peter Anvin wrote: > Markus Rechberger wrote: >> H. Peter Anvin wrote: >>> Markus Rechberger wrote: >>>> My debian system's coreutils package only allows dates between 1902 >>>> and >>>> 2038, but it might be interesting to get that right if it's wrong. >>>> >>>> touch (GNU coreutils) 5.97 just says invalid dateformat to 2050-01-01 >>> Lemme guess, you're on a 32-bit system... >>> >> >> I have both here, 64 and 32bit >> If I touch a file with 1905 on my 32bit system and remount the disk the >> date will remain at 1905 without any patch. >> > > The reason is that most 32-bit systems (e.g. i386) only have a 32-bit > time_t, so the user space interface wraps around in 2038. > > However, most 64-bit systems (e.g. x86_64) have 64-bit time_t, and > thus don't have that problem. > > -hpa > > I know time_t expands to long, anyway the existing filesystem layout cannot be changed so that problem would even remain with a 64bit system unless the whole system would really treat it as unsigned. A 64 bit system will cast the unsigned stamp over a signed long value which in this case is bigger than 32 bit and behaves differently. -- Markus Rechberger Operating System Research Center AMD Saxony LLC & Co. KG - 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: [Ksummit-2007-discuss] Re: +1 4 cz (Re: [Ksummit-2006-discuss] 2007 Linux Kernel Summit)
On 2/7/07, Arnd Bergmann <[EMAIL PROTECTED]> wrote: On Tuesday 06 February 2007 21:10, James Simmons wrote: > > So it is between Britian or the Czech Republic. BTW how long of a train > ride is to swizterland from CZ. My wife's family lives there. Too long. 15 hours according to http://reiseauskunft.bahn.de/bin/query.exe/en . You probably want to take a cheap flight instead. Isn't there a nighttrain? You could (try to) sleep during the journey. I'd be interested in Czech too. 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/
Re: O2micro smartcard reader driver.
Hi,
so finally I'm also looking at that driver,
http://pieleric.free.fr/o2scr/
the driver compiles fine, though it doesn't seem to work (unless I'm
doing something wrong here)
dmesg shows up following entries:
pccard: card ejected from slot 1
PCMCIA: socket c160c364: *** DANGER *** unable to remove socket power
pccard: PCMCIA card inserted into slot 1
pcmcia: registering new device pcmcia1.0
pccard: card ejected from slot 1
PCMCIA: socket c160c364: *** DANGER *** unable to remove socket power
pccard: PCMCIA card inserted into slot 1
pcmcia: registering new device pcmcia1.0
pccard: card ejected from slot 1
PCMCIA: socket c160c364: *** DANGER *** unable to remove socket power
pccard: PCMCIA card inserted into slot 1
pcmcia: registering new device pcmcia1.0
OZSCRLX O2Micro SmartCardBus Reader (for kernel >= 2.6.17)
The module for any reason has a usecount value of 1
ozscrlx21548 1
devicenode /dev/ozscrlx isn't opened anywhere either.
I'll do some further investigations uppon it, I'd also like to see it
directly in the kernel. It would be handy to use for encrypted
filesystems.
Markus
On 12/12/06, Eric Piel <[EMAIL PROTECTED]> wrote:
28.11.2006 12:49, Oliver Neukum wrote/a écrit:
>> Latest version I've published is there:
>> http://pieleric.free.fr/o2scr/
>
> case OZSCR_OPEN: /* Request ICC */
> dprintk("OZSCR_OPEN\n");
> ATRLength = ATR_SIZE;
> pRdrExt->IOBase = (PSCR_REGISTERS *) dev->io_base; //XXX
necessary?
> pRdrExt->membase = dev->am_base; //XXX necessary?
>
> pRdrExt->m_SCard.AvailableProtocol = 0;
> pRdrExt->m_SCard.RqstProtocol = 0;
> dprintk("membase:%p\n", pRdrExt->membase);
> dprintk("ioport:0x%03x\n", (unsigned)pRdrExt->IOBase);
>
> ret = CmdResetReader( pRdrExt, FALSE, ATRBuffer, &ATRLength );
> apdu.LengthOut = ATRLength;
>
> #ifdef PCMCIA_DEBUG
> printk(KERN_DEBUG "Open finished, ATR buffer = ");
> for( ATRLength = 0; ATRLength < apdu.LengthOut; ATRLength++ )
> printk(" [%02X] ", ATRBuffer[ATRLength] );
> printk("\n");
> #endif
>
> memcpy( apdu.DataOut, ATRBuffer, ATRLength );
> ret = copy_to_user((struct ozscr_apdu *)arg, &apdu,
sizeof(struct ozscr_apdu));
> break;
>
> 1. This needs locking against concurrent ioctls
> 2. The interpretation of copy_to_user()'s return code is incorrect
>
Hi Oliver,
Thanks a lot for reading my code, I didn't even hope that someone would!
I've corrected the copy_to_user (and copy_from_user) code. However I
don't know how to do locking for the concurrent ioctls. Indeed, I don't
think there is anything preventing two programs to call the driver at
the same time. Unfortunately, I've got no idea how to do the locking and
surprisingly couldn't find any ioctl code in the kernel doing locking.
Maybe I've just not looked at the right place, could you give a me some
hint how to do locking for ioctl's ?
See you,
Eric
-
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/
--
Markus Rechberger
-
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.20.git regression: 'PCI: add the sysfs driver name to all modules' causes hard hang on boot
On 2/17/07, Greg KH <[EMAIL PROTECTED]> wrote: On Sat, Feb 17, 2007 at 02:38:08AM +0100, Mike Galbraith wrote: > On Fri, 2007-02-16 at 14:36 -0800, Greg KH wrote: > > On Fri, Feb 16, 2007 at 10:55:10AM +0100, Mike Galbraith wrote: > > > Greetings, > > > > > > Per $subject, git.yesterday hangs hard on boot here. A git bisect > > > fingered the commit below, which I verified via git bisect reset; git > > > revert -n 725522b5453dd680412f2b6463a988e4fd148757, after which box > > > boots fine. (well, I hope I verified... i'm git-ignorant) > > > > If you change CONFIG_SYSFS_DEPRECATED to Y, does that solve the problem? > > It's already set. It's not set in the config file you sent to me and the list :) I'm having a hard lockup to when I fire up xmms in X (maybe some other apps too) I'm bisecting at the moment. CONFIG_SYSFS_DEPRECIATED is set to Y here too, so I might have another problem here.. let's see what bisecting will show up.. 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/
Re: 2.6.20.git regression: 'PCI: add the sysfs driver name to all modules' causes hard hang on boot
On 2/17/07, Markus Rechberger <[EMAIL PROTECTED]> wrote: On 2/17/07, Greg KH <[EMAIL PROTECTED]> wrote: > On Sat, Feb 17, 2007 at 02:38:08AM +0100, Mike Galbraith wrote: > > On Fri, 2007-02-16 at 14:36 -0800, Greg KH wrote: > > > On Fri, Feb 16, 2007 at 10:55:10AM +0100, Mike Galbraith wrote: > > > > Greetings, > > > > > > > > Per $subject, git.yesterday hangs hard on boot here. A git bisect > > > > fingered the commit below, which I verified via git bisect reset; git > > > > revert -n 725522b5453dd680412f2b6463a988e4fd148757, after which box > > > > boots fine. (well, I hope I verified... i'm git-ignorant) > > > > > > If you change CONFIG_SYSFS_DEPRECATED to Y, does that solve the problem? > > > > It's already set. > > It's not set in the config file you sent to me and the list :) > I'm having a hard lockup to when I fire up xmms in X (maybe some other apps too) I'm bisecting at the moment. CONFIG_SYSFS_DEPRECIATED is set to Y here too, so I might have another problem here.. let's see what bisecting will show up.. seems to be a "wrong" alarm here, it was caused by a new xorg.conf and an intel 855gm chipset. 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/
Re: O2micro smartcard reader driver.
Hi Eric,
I committed your code to linuxtv.org to review and modify it there.
http://linuxtv.org/hg/~mrechberger/chipcardreader
one thing I noticed is the error handling in ozscr_probe.
I'll continue the rest during the next few days, I'd like to see it as
soon as possible in the upstream kernel before some kernel api changes
again which affects your current driver.
Markus
On 2/17/07, Markus Rechberger <[EMAIL PROTECTED]> wrote:
Hi,
so finally I'm also looking at that driver,
http://pieleric.free.fr/o2scr/
the driver compiles fine, though it doesn't seem to work (unless I'm
doing something wrong here)
dmesg shows up following entries:
pccard: card ejected from slot 1
PCMCIA: socket c160c364: *** DANGER *** unable to remove socket power
pccard: PCMCIA card inserted into slot 1
pcmcia: registering new device pcmcia1.0
pccard: card ejected from slot 1
PCMCIA: socket c160c364: *** DANGER *** unable to remove socket power
pccard: PCMCIA card inserted into slot 1
pcmcia: registering new device pcmcia1.0
pccard: card ejected from slot 1
PCMCIA: socket c160c364: *** DANGER *** unable to remove socket power
pccard: PCMCIA card inserted into slot 1
pcmcia: registering new device pcmcia1.0
OZSCRLX O2Micro SmartCardBus Reader (for kernel >= 2.6.17)
The module for any reason has a usecount value of 1
ozscrlx21548 1
devicenode /dev/ozscrlx isn't opened anywhere either.
I'll do some further investigations uppon it, I'd also like to see it
directly in the kernel. It would be handy to use for encrypted
filesystems.
Markus
On 12/12/06, Eric Piel <[EMAIL PROTECTED]> wrote:
> 28.11.2006 12:49, Oliver Neukum wrote/a écrit:
> >> Latest version I've published is there:
> >> http://pieleric.free.fr/o2scr/
> >
> > case OZSCR_OPEN: /* Request ICC */
> > dprintk("OZSCR_OPEN\n");
> > ATRLength = ATR_SIZE;
> > pRdrExt->IOBase = (PSCR_REGISTERS *) dev->io_base; //XXX
> necessary?
> > pRdrExt->membase = dev->am_base; //XXX necessary?
> >
> > pRdrExt->m_SCard.AvailableProtocol = 0;
> > pRdrExt->m_SCard.RqstProtocol = 0;
> > dprintk("membase:%p\n", pRdrExt->membase);
> > dprintk("ioport:0x%03x\n", (unsigned)pRdrExt->IOBase);
> >
> > ret = CmdResetReader( pRdrExt, FALSE, ATRBuffer, &ATRLength
);
> > apdu.LengthOut = ATRLength;
> >
> > #ifdef PCMCIA_DEBUG
> > printk(KERN_DEBUG "Open finished, ATR buffer = ");
> > for( ATRLength = 0; ATRLength < apdu.LengthOut; ATRLength++
)
> > printk(" [%02X] ", ATRBuffer[ATRLength] );
> > printk("\n");
> > #endif
> >
> > memcpy( apdu.DataOut, ATRBuffer, ATRLength );
> > ret = copy_to_user((struct ozscr_apdu *)arg, &apdu,
> sizeof(struct ozscr_apdu));
> > break;
> >
> > 1. This needs locking against concurrent ioctls
> > 2. The interpretation of copy_to_user()'s return code is incorrect
> >
>
> Hi Oliver,
>
> Thanks a lot for reading my code, I didn't even hope that someone would!
> I've corrected the copy_to_user (and copy_from_user) code. However I
> don't know how to do locking for the concurrent ioctls. Indeed, I don't
> think there is anything preventing two programs to call the driver at
> the same time. Unfortunately, I've got no idea how to do the locking and
> surprisingly couldn't find any ioctl code in the kernel doing locking.
> Maybe I've just not looked at the right place, could you give a me some
> hint how to do locking for ioctl's ?
>
> See you,
> Eric
>
> -
> 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/
>
--
Markus Rechberger
--
Markus Rechberger
--- ozscrlx.c.1 2006-12-12 22:28:24.0 +0100
+++ ozscrlx.c 2007-02-17 01:00:46.0 +0100
@@ -596,14 +596,14 @@
dev = kzalloc(sizeof(struct ozscr_dev_t), GFP_KERNEL);
if (dev == NULL) {
dprintk("allocate ozscr_dev_t fail\n");
- goto ErrHandle;
+ goto ErrHandle1;
}
/* Allocate space for private device-specific data */
dev->o2scr_reader = kzalloc(sizeof(READER_EXTENSION *), GFP_KERNEL);
if (dev->o2scr_reader == NULL) {
dprintk("allocate READER_EXTENSION fail\n");
- goto ErrHandle;
+ goto ErrHandle2;
}
p_dev->priv = dev;
@@ -628,7 +628,7 @@
ret = ozscr_config(p_dev);
if (ret)
- goto ErrHandle;
+ goto ErrHandle3;
// it's just so redundant... we could merge those fields together
dev->o2scr_reader->IOBase = (PSCR_REGISTERS *) dev->io_base;
@@ -644,11 +644,11 @@
dprintk("function complete\n");
return 0;
- ErrHandle:
- /* Free the allocated memory space */
- if (dev)
- kfree(dev->o2scr_reader);
+ ErrHandle3:
+ kfree(dev->o2scr_reader);
+ ErrHandle2:
kfree(dev);
+ ErrHandle1:
return ret;
}
Re: smartcard reader + pcmcia/pccard subsystem problems
Hi,
after doing some code review it seems like I found 2 bugs.
a.) deadlock within the pccard/pcmcia framework
b.) slab corruption when unloading the driver
a.) it's easy to reproduce a, just run
$ while :; do pccardctl eject; pccardctl insert; done
concurrently on 2 shells.
another way to reproduce it is:
$ while :; do insmod oz...ko; pccardctl insert; pccardctl eject; rmmod
oz...ko; done
(it's sufficient to run that on one shell)
The bug is sysfs related, there are 2 locks one to protect critical
parts of the pccard/pcmcia framework, the other one to lock the sysfs
inode. I'll try to commit a patch for this during the next few days I
was able to solve one problem there already.
b.) slab corruption; it's a bit difficult to reproduce since a. might
lock up the device before anything shows up. So I haven't done much
here yet.
Markus
On 2/17/07, Markus Rechberger <[EMAIL PROTECTED]> wrote:
Hi Eric,
I committed your code to linuxtv.org to review and modify it there.
http://linuxtv.org/hg/~mrechberger/chipcardreader
one thing I noticed is the error handling in ozscr_probe.
I'll continue the rest during the next few days, I'd like to see it as
soon as possible in the upstream kernel before some kernel api changes
again which affects your current driver.
Markus
On 2/17/07, Markus Rechberger <[EMAIL PROTECTED]> wrote:
> Hi,
>
> so finally I'm also looking at that driver,
> http://pieleric.free.fr/o2scr/
> the driver compiles fine, though it doesn't seem to work (unless I'm
> doing something wrong here)
>
> dmesg shows up following entries:
>
> pccard: card ejected from slot 1
> PCMCIA: socket c160c364: *** DANGER *** unable to remove socket power
> pccard: PCMCIA card inserted into slot 1
> pcmcia: registering new device pcmcia1.0
> pccard: card ejected from slot 1
> PCMCIA: socket c160c364: *** DANGER *** unable to remove socket power
> pccard: PCMCIA card inserted into slot 1
> pcmcia: registering new device pcmcia1.0
> pccard: card ejected from slot 1
> PCMCIA: socket c160c364: *** DANGER *** unable to remove socket power
> pccard: PCMCIA card inserted into slot 1
> pcmcia: registering new device pcmcia1.0
> OZSCRLX O2Micro SmartCardBus Reader (for kernel >= 2.6.17)
>
> The module for any reason has a usecount value of 1
> ozscrlx21548 1
>
> devicenode /dev/ozscrlx isn't opened anywhere either.
>
> I'll do some further investigations uppon it, I'd also like to see it
> directly in the kernel. It would be handy to use for encrypted
> filesystems.
>
> Markus
>
>
> On 12/12/06, Eric Piel <[EMAIL PROTECTED]> wrote:
> > 28.11.2006 12:49, Oliver Neukum wrote/a écrit:
> > >> Latest version I've published is there:
> > >> http://pieleric.free.fr/o2scr/
> > >
> > > case OZSCR_OPEN: /* Request ICC */
> > > dprintk("OZSCR_OPEN\n");
> > > ATRLength = ATR_SIZE;
> > > pRdrExt->IOBase = (PSCR_REGISTERS *) dev->io_base; //XXX
> > necessary?
> > > pRdrExt->membase = dev->am_base; //XXX necessary?
> > >
> > > pRdrExt->m_SCard.AvailableProtocol = 0;
> > > pRdrExt->m_SCard.RqstProtocol = 0;
> > > dprintk("membase:%p\n", pRdrExt->membase);
> > > dprintk("ioport:0x%03x\n", (unsigned)pRdrExt->IOBase);
> > >
> > > ret = CmdResetReader( pRdrExt, FALSE, ATRBuffer,
&ATRLength
> );
> > > apdu.LengthOut = ATRLength;
> > >
> > > #ifdef PCMCIA_DEBUG
> > > printk(KERN_DEBUG "Open finished, ATR buffer = ");
> > > for( ATRLength = 0; ATRLength < apdu.LengthOut;
ATRLength++
> )
> > > printk(" [%02X] ", ATRBuffer[ATRLength] );
> > > printk("\n");
> > > #endif
> > >
> > > memcpy( apdu.DataOut, ATRBuffer, ATRLength );
> > > ret = copy_to_user((struct ozscr_apdu *)arg, &apdu,
> > sizeof(struct ozscr_apdu));
> > > break;
> > >
> > > 1. This needs locking against concurrent ioctls
> > > 2. The interpretation of copy_to_user()'s return code is incorrect
> > >
> >
> > Hi Oliver,
> >
> > Thanks a lot for reading my code, I didn't even hope that someone
would!
> > I've corrected the copy_to_user (and copy_from_user) code. However I
> > don't know how to do locking for the concurrent ioctls. Indeed, I don't
> > think there is anything preventing two
Re: O2micro smartcard reader driver.
On 2/19/07, Éric Piel <[EMAIL PROTECTED]> wrote: > 02/17/2007 04:55 AM, Markus Rechberger wrote/a écrit: > > Hi Eric, > > > > I committed your code to linuxtv.org to review and modify it there. > > http://linuxtv.org/hg/~mrechberger/chipcardreader > > > > one thing I noticed is the error handling in ozscr_probe. > > > > I'll continue the rest during the next few days, I'd like to see it as > > soon as possible in the upstream kernel before some kernel api changes > > again which affects your current driver. > > Hi Markus, > > Thank you very much for finding new bugs ;-) Actually, right now I've > just moved and don't have internet at home which is kind of slowing down > development... Anyway, I'll check if I have some more fixes on my > computer than on my website. Also, it would be good to double check some > lines which I've commented XXX. In particular, IIRC there were some > suspicious sleep saying it was sleeping a microsecond and sleeping one > millisecond! as user noone cares if it's 1 ns or 1 ms, since that part seems to work as it is just leave it. > > I'm also a bit concerned about the userspace "driver" for pscd which > comes with the original driver once the patch will be part of the > default kernel. Maybe this userspace part could become part of the > pscdlite distribution. > I couldn't find the sources of the userspace library, the link on musclecard.com is dead (and there's no backup on archive.org) > Wrt the module having always a usecount value of 1, it was worrying me > too at the begining until I noticed it decreased back to 0 once the card > is "ejected" (pccardctl eject 1). Although a bit surprising, I don't > think it's a bug, is it? this is where the pcmcia/pccard framework bug becomes relevant. The usecount is no bug, but the lockup (which got explained in the other mail) is one > > See you, > Eric > > -- Markus Rechberger Operating System Research Center AMD Saxony LLC & Co. KG - 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/
[PATCH] pcmcia/pccard deadlock fix
following patch prevents a mutex/semaphore deadlock within the pcmcia
framework when ejecting devices multiple times using pccardctl eject.
For some more details see:
http://lkml.org/lkml/2007/2/19/58
Signed-off-by: Markus Rechberger <[EMAIL PROTECTED]>
--
Markus Rechberger
Operating System Research Center
AMD Saxony LLC & Co. KG
index ac00424..c02bf0d 100644
--- a/drivers/pcmcia/cs.c
+++ b/drivers/pcmcia/cs.c
@@ -856,7 +856,8 @@ int pcmcia_eject_card(struct pcmcia_socket *skt)
cs_dbg(skt, 1, "user eject request\n");
- mutex_lock(&skt->skt_mutex);
+ if (!mutex_trylock(&skt->skt_mutex))
+ return -EAGAIN;
do {
if (!(skt->state & SOCKET_PRESENT)) {
ret = -ENODEV;
index 18e111e..b9d3440 100644
--- a/drivers/pcmcia/ds.c
+++ b/drivers/pcmcia/ds.c
@@ -1100,7 +1100,9 @@ static ssize_t pcmcia_store_allow_func_id_match(struct
device *dev,
if (!count)
return -EINVAL;
- mutex_lock(&p_dev->socket->skt_mutex);
+ if (!mutex_trylock(&p_dev->socket->skt_mutex))
+ return -EAGAIN;
+
p_dev->allow_func_id_match = 1;
mutex_unlock(&p_dev->socket->skt_mutex);
Yenta Cardbus allocation failure
Hi, I've got a PCMCIA Hybrid TV tuner, but when I plug it in it fails to allocate resources for the 3rd PCI function. I already searched with google and someone implemented an otion parm: override_bios:yenta ignore bios resource allocation (uint in yenta_socket, though this doesn't seem to work out with that device. Any idea how that problem can be solved? So here are some logs lspci: :03:00.0 Multimedia video controller: Conexant CX23880/1/2/3 PCI Video and Audio Decoder (rev 05) Subsystem: Yuan Yuan Enterprise Co., Ltd.: Unknown device 1788 Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium TAbort- SERR- Latency: 64 (5000ns min, 13750ns max) Interrupt: pin A routed to IRQ 10 Region 0: Memory at 3600 (32-bit, non-prefetchable) [size=16M] Capabilities: [44] Vital Product Data Capabilities: [4c] Power Management version 2 Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-) Status: D0 PME-Enable- DSel=0 DScale=0 PME- :03:00.1 Multimedia controller: Conexant CX23880/1/2/3 PCI Video and Audio Decoder [Audio Port] (rev 05) Subsystem: Yuan Yuan Enterprise Co., Ltd.: Unknown device 1788 Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium TAbort- SERR- Latency: 64 (1000ns min, 63750ns max) Interrupt: pin A routed to IRQ 10 Region 0: Memory at 3700 (32-bit, non-prefetchable) [size=16M] Capabilities: [4c] Power Management version 2 Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-) Status: D0 PME-Enable- DSel=0 DScale=0 PME- :03:00.2 Multimedia controller: Conexant CX23880/1/2/3 PCI Video and Audio Decoder [MPEG Port] (rev 05) Subsystem: Yuan Yuan Enterprise Co., Ltd.: Unknown device 1788 Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium TAbort- SERR- Interrupt: pin A routed to IRQ 10 Capabilities: [4c] Power Management version 2 Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-) Status: D0 PME-Enable- DSel=0 DScale=0 PME- cat /proc/iomem -0009f7ff : System RAM 0009f800-0009 : reserved 000a-000b : Video RAM area 000c-000ccdff : Video ROM 000cd000-000ce7ff : Adapter ROM 000f-000f : System ROM 0010-1ded : System RAM 0010-002ada17 : Kernel code 002ada18-0037ebc7 : Kernel data 1dee-1deebfff : ACPI Tables 1deec000-1def : ACPI Non-volatile Storage 1df0-1fff : reserved 3000-33ff : PCI Bus #02 3000-31ff : PCI CardBus #03 3200-33ff : PCI CardBus #07 3400-340003ff : :00:1f.1 3600-37ff : PCI CardBus #03 3600-36ff : :03:00.0 3600-36ff : cx88[0] 3700-37ff : :03:00.1 3700-37ff : cx88[0] 3800-39ff : PCI CardBus #07 e000-e007 : :00:02.0 e008-e00f : :00:02.1 e010-e01003ff : :00:1d.7 e010-e01003ff : ehci_hcd e0100800-e01008ff : :00:1f.5 e0100800-e01008ff : Intel 82801DB-ICH4 e0100c00-e0100dff : :00:1f.5 e0100c00-e0100dff : Intel 82801DB-ICH4 e020-e07f : PCI Bus #02 e020-e0203fff : :02:07.0 e0204000-e0205fff : :02:02.0 e0204000-e0205fff : b44 e0206000-e0206fff : :02:04.0 e0206000-e0206fff : ipw2100 e0207000-e0207fff : :02:06.0 e0207000-e0207fff : yenta_socket e0208000-e0208fff : :02:06.1 e0208000-e0208fff : yenta_socket e0209000-e02097ff : :02:07.0 e0209000-e02097ff : ohci1394 e026-e0260fff : pcmcia_socket1 e800-efff : :00:02.0 f000-f7ff : :00:02.1 fec1-fec1 : reserved ff80-ffbf : reserved fc00- : reserved dmesg: Yenta: CardBus bridge found at :02:06.0 [1025:0035] Yenta O2: res at 0x94/0xD4: 00/ea Yenta O2: enabling read prefetch/write burst Yenta: ISA IRQ mask 0x00b8, PCI irq 10 Socket status: 3820 Yenta: Raising subordinate bus# of parent bus (#02) from #02 to #06 pcmcia: parent PCI bridge I/O window: 0x3000 - 0x3fff cs: IO port probe 0x3000-0x3fff: clean. pcmcia: parent PCI bridge Memory window: 0xe020 - 0xe07f pcmcia: parent PCI bridge Memory window: 0x3000 - 0x33ff Yenta: CardBus bridge found at :02:06.1 [1025:0035] Yenta: ISA IRQ mask 0x00b8, PCI irq 10 Socket status: 3410 Yenta: Raising subordinate bus# of parent bus (#02) from #06 to #0a pcmcia: parent PCI bridge I/O window: 0x3000 - 0x3fff cs: IO port probe 0x3000-0x3fff: clean. pcmcia: parent PCI bridge Memory window: 0xe020 - 0xe07f pcmcia: parent PCI bridge Memory window: 0x3000 - 0
Re: [solved] Yenta Cardbus allocation failure
I went on with investigating that problem and found the problem, though I'm not sure if that solution is acceptable.. seems like the memory range gets preallocated in setup-bus.c, and CARDBUS_MEM_SIZE defines that size. I changed #define CARDBUS_MEM_SIZE(32*1024*1024) to #define CARDBUS_MEM_SIZE(48*1024*1024) and now the system is able to allocate the resources for the 3rd pci/pcmcia function. Can anyone please have a closer look at it too? I think the whole implementation isn't really good there.. so this is the new output of iomem: $ cat /proc/iomem ... 3000-35ff : PCI Bus #02 3000-32ff : PCI CardBus #03 3600-360003ff : :00:1f.1 3900-3bff : PCI CardBus #03 3900-39ff : :03:00.0 3a00-3aff : :03:00.1 3b00-3bff : :03:00.2 <- this one failed to allocate previously 3c00-3eff : PCI CardBus #07 4100-43ff : PCI CardBus #07 ... and lspci: $ lspci -vvv 03:00.0 Multimedia video controller: Conexant CX23880/1/2/3 PCI Video and Audio Decoder (rev 05) Subsystem: Yuan Yuan Enterprise Co., Ltd. Unknown device 1788 Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium TAbort- SERR- Interrupt: pin A routed to IRQ 10 Region 0: Memory at 3900 (32-bit, non-prefetchable) [disabled] [size=16M] Capabilities: [44] Vital Product Data Capabilities: [4c] Power Management version 2 Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-) Status: D0 PME-Enable- DSel=0 DScale=0 PME- 03:00.1 Multimedia controller: Conexant CX23880/1/2/3 PCI Video and Audio Decoder [Audio Port] (rev 05) Subsystem: Yuan Yuan Enterprise Co., Ltd. Unknown device 1788 Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium TAbort- SERR- Interrupt: pin A routed to IRQ 10 Region 0: Memory at 3a00 (32-bit, non-prefetchable) [disabled] [size=16M] Capabilities: [4c] Power Management version 2 Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-) Status: D0 PME-Enable- DSel=0 DScale=0 PME- 03:00.2 Multimedia controller: Conexant CX23880/1/2/3 PCI Video and Audio Decoder [MPEG Port] (rev 05) Subsystem: Yuan Yuan Enterprise Co., Ltd. Unknown device 1788 Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium TAbort- SERR- Interrupt: pin A routed to IRQ 10 NEW --> Region 0: Memory at 3b00 (32-bit, non-prefetchable) [disabled] [size=16M] Capabilities: [4c] Power Management version 2 Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-) Status: D0 PME-Enable- DSel=0 DScale=0 PME- thanks, Markus On 12/12/06, Markus Rechberger <[EMAIL PROTECTED]> wrote: Hi, I've got a PCMCIA Hybrid TV tuner, but when I plug it in it fails to allocate resources for the 3rd PCI function. I already searched with google and someone implemented an otion parm: override_bios:yenta ignore bios resource allocation (uint in yenta_socket, though this doesn't seem to work out with that device. Any idea how that problem can be solved? So here are some logs lspci: :03:00.0 Multimedia video controller: Conexant CX23880/1/2/3 PCI Video and Audio Decoder (rev 05) Subsystem: Yuan Yuan Enterprise Co., Ltd.: Unknown device 1788 Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- SERR- TAbort- SERR- TAbort- SERR- - 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: [solved] Yenta Cardbus allocation failure
On 12/19/06, Chuck Ebbert <[EMAIL PROTECTED]> wrote: In-Reply-To: <[EMAIL PROTECTED]> On Tue, 19 Dec 2006 01:12:07 +0100, Markus Rechberger wrote: > I went on with investigating that problem and found the problem, > though I'm not sure if that solution is acceptable.. > > seems like the memory range gets preallocated in setup-bus.c, and > CARDBUS_MEM_SIZE defines that size. > > I changed > #define CARDBUS_MEM_SIZE(32*1024*1024) > to > #define CARDBUS_MEM_SIZE(48*1024*1024) > > and now the system is able to allocate the resources for the 3rd > pci/pcmcia function. > > Can anyone please have a closer look at it too? I think the whole > implementation isn't really good there.. > > so this is the new output of iomem: > $ cat /proc/iomem > ... > 3000-35ff : PCI Bus #02 > 3000-32ff : PCI CardBus #03 > 3600-360003ff : :00:1f.1 > 3900-3bff : PCI CardBus #03 > 3900-39ff : :03:00.0 > 3a00-3aff : :03:00.1 > 3b00-3bff : :03:00.2 <- this one failed to allocate previously Wow, 3 regions of 16MB each! Your change fixes this problem for you, but what if someone needs four such regions? I documented everything I found about that issue (even the allocated resources in window$) http://linuxtv.org/v4lwiki/index.php/Talk:Pinnacle/310c#PCI_allocation_failed that's why I wrote that the current implementation isn't nice.. I'm currently on the cx88 driver (which needs that memory region) to get my Pinnacle Cardbus device work.. I won't get back to the PCI subsystem before I'm done with it. 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/
Re: How to improve the quality of the kernel?
On 6/17/07, Natalie Protasevich <[EMAIL PROTECTED]> wrote:
On 6/17/07, Adrian Bunk <[EMAIL PROTECTED]> wrote:
> On Sun, Jun 17, 2007 at 06:26:55PM +0200, Stefan Richter wrote:
> > Adrian Bunk wrote:
> > >>> And we should be aware that reverting is only a workaround for the
real
> > >>> problem which lies in our bug handling.
> > >> ...
> > >
> > > And this is something I want to emphasize again.
> > >
> > > How can we make any progress with the real problem and not only the
> > > symptoms?
> > ...
> >
> > Perhaps make lists of
> >
> > - bug reports which never lead to any debug activity
> > (no responsible person/team was found, or a seemingly person/team
> > did not start to debug the report)
> >
> > - known regressions on release,
> >
> > - regressions that became known after release,
> >
> > - subsystems with notable backlogs of old bugs,
> >
> > - other categories?
> >
> > Select typical cases from each categories, analyze what went wrong in
> > these cases, and try to identify practicable countermeasures.
>
> No maintainer or no maintainer who is debugging bug reports is the
> major problem in all parts of your list.
>
> > Another approach: Figure out areas where quality is exemplary and try
> > to draw conclusions for areas where quality is lacking.
>
> ieee1394 has a maintainer who is looking after all bug reports he gets.
>
> Conclusion: We need such maintainers for all parts of the kernel.
>
I noticed some areas are well maintained because there is an awesome
maintainer, or good and well coordinated team - and this is mostly in
the "fun" areas ;) But there are "boring" areas that are about to be
deprecated or no new development expected etc. It will be hard to get
a dedicated person to take care of such. How about having people on
rotation, or jury duty so to speak - for a period of time (completely
voluntary!) Nice stats on the report about contributions in non-native
areas for a developer would be great accomplishment and also good
chance to look into other things! Besides, this way "old parts" will
get attention to be be revised and re-implemented sooner. And we can
post "Temp maintainer needed" list...
I'd vote for that, I've seen alot very bad code already within some
subsystems and critical problems which just have been ignored by some
maintainers.
It mostly helps if some volunteers read through existing code and
state out their considerations about implementations which they don't
like.
I just grep'ed some examples I noticed (note I do not want to jump
onto someone's toe here, just give some examples):
(sn9c102_ov7660.c)
...
err += sn9c102_i2c_write(cam, 0x12, 0x80);
err += sn9c102_i2c_write(cam, 0x11, 0x09);
err += sn9c102_i2c_write(cam, 0x00, 0x0A);
err += sn9c102_i2c_write(cam, 0x01, 0x80);
err += sn9c102_i2c_write(cam, 0x02, 0x80);
err += sn9c102_i2c_write(cam, 0x03, 0x00);
... (around 150 lines directly after each other doing such writes and
adding error values to a variable, I don't understand why someone
should add the errors but continue with sending 150 more updates, how
about one write failed but others succeeded for any reason)
(tvp5150.c)
static int tvp5150_read(struct i2c_client *c, unsigned char addr)
{
unsigned char buffer[1];
int rc;
buffer[0] = addr;
if (1 != (rc = i2c_master_send(c, buffer, 1)))
tvp5150_dbg(0, "i2c i/o error: rc == %d (should be 1)\n", rc);
msleep(10);
if (1 != (rc = i2c_master_recv(c, buffer, 1)))
tvp5150_dbg(0, "i2c i/o error: rc == %d (should be 1)\n", rc);
tvp5150_dbg(2, "tvp5150: read 0x%02x = 0x%02x\n", addr, buffer[0]);
return (buffer[0]);
}
(i2c issues within some driver)
/* This code detects calls by card attach_inform */
if (NULL == t->i2c.dev.driver) {
tuner_dbg ("tuner 0x%02x: called during i2c_client
register by adapter's attach_inform\n", c->addr);
return;
}
... that code doesn't even work anymore since the i2c.dev.driver is
always initialized.
just reading through it and cleaning up some code isn't so difficult
and can be done by many people - if they're allowed/wanted to do so.
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/
Re: [PATCH 1/1] V4L: stk11xx, add a new webcam driver
r.
> +static int stk11xx_querystd(struct file *file, void *fh, v4l2_std_id
> *a)
> +{
> + *a = V4L2_STD_UNKNOWN;
> + return 0;
> +}
> +
> +static int stk11xx_s_std(struct file *file, void *fh, v4l2_std_id *a)
> +{
> + return *a == V4L2_STD_UNKNOWN ? 0 : -EINVAL;
> +}
This raises an interesting discussion about video standards. I would,
instead, use V4L2_STD_ALL, since webcams are capable of properly
handling on 525 raw lines/60Hz based standards (those derived from
640x480 res) as well as 625 raw lines/50Hz based standards (those
derived from ITU-T CIF resolutions).
As reference, STD_ALL is defined as:
#define V4L2_STD_ALL(V4L2_STD_525_60|\
V4L2_STD_625_50)
---
Also, I noticed that several hexadecimal values are using uppercases.
The better is to convert all of them to lowercase, to keep the same
codingstyle as the other drivers.
--
Cheers,
Mauro
--
video4linux-list mailing list
Unsubscribe mailto:[EMAIL PROTECTED]
https://www.redhat.com/mailman/listinfo/video4linux-list
--
Markus Rechberger
-
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/1] V4L: stk11xx, add a new webcam driver
On 5/24/07, Jiri Slaby <[EMAIL PROTECTED]> wrote:
On 5/24/07, Markus Rechberger <[EMAIL PROTECTED]> wrote:
> Hi Jiri,
>
> On 5/24/07, Jiri Slaby <[EMAIL PROTECTED]> wrote:
> > Well, no objections on v4l list, try to merge it. Any further comments
will
> > be
> > appreciated.
> >
> > --
> >
> > stk11xx, add a new webcam driver
> >
> > Cc: Mauro Carvalho Chehab <[EMAIL PROTECTED]>
> > Signed-off-by: Jiri Slaby <[EMAIL PROTECTED]>
> >
[...]
> > +/*
> > + * Bayer conversion
> > + */
> > +
> > +#define STK11XX_AVG2(x,y) (u8)(((int)x + (int)y) / 2)
> > +#define STK11XX_AVG4(a,b,c,d) (u8)(((int)a + (int)b + (int)c + (int)d)
/ 4)
> > +
> > +static void stk11xx_bayer_to_rgb(u8 *rgb, const u8 *bayer,
> > + const int width, const int height)
>
> hmm.. this is probably to support xawtv/tvtime?
> It would be better to do that in userspace, but the argument which
> seems to be against it is that userspace applications often don't
> support bayer.
Exactly. This would make the webcam driver unusable. Another one,
which awaits RGB is camstream, which also I use. After moving all
major used userspace apps to something like pwlib, this may be wiped
out.
> > +{
> > + unsigned int x, y, nwidth, nheight;
> > +
> > + nheight = height / factor;
> > + nwidth = width / factor;
> > +
> > + for (y = 0; y < nheight; y++) {
> > + for (x = 0; x < nwidth; x++) {
> > + /* R */
> > + out[y * nwidth * 3 + x * 3 + 0] =
> > + in[y * factor * width * 3 + x * factor * 3 +
0];
> > + /* G */
> > + out[y * nwidth * 3 + x * 3 + 1] =
> > + in[y * factor * width * 3 + x * factor * 3 +
1];
> > + /* B */
> > + out[y * nwidth * 3 + x * 3 + 2] =
> > + in[y * factor * width * 3 + x * factor * 3 +
2];
> > + }
> > + }
> > +}
> > +
> > +static void stk11xx_correct_brightness(u8 *rgb, unsigned int width,
> > + unsigned int height, int brightness)
> > +{
>
> same here, why do you want to have that in kernelspace?
not sure who from userspace can do this nowadays. Will check.
> > +/*
> > + * The configuration of device is composed of 12 steps.
> > + * This function is called by the initialization process.
> > + *
> > + * We don't know the meaning of these steps! We only replay the USB
log.
> > + */
> > +static int stk1135_configure_device(struct stk11xx *dev, int step)
> > +{
> > + int value;
> > +
> > + /* 0,1,2,3,4,5,6,7,8,9,
> > + 10, 11, 12, 13 */
> > +
> > + const u8 values_001B[] = {
> > + 0x0E, 0x03, 0x0E, 0x0E, 0x0E, 0x0E, 0x0E, 0x0E, 0x0E,
0x07,
> > + 0x07, 0x07, 0x07, 0x07
> > + };
> > + const u8 values_001C[] = {
> > + 0x06, 0x02, 0x46, 0x46, 0x46, 0x46, 0x46, 0x46, 0x06,
0x06,
> > + 0x06, 0x06, 0x06, 0x07
> > + };
> > + const u8 values_0202[] = {
> > + 0x1E, 0x0A, 0x1E, 0x1E, 0x1E, 0x1E, 0x1E, 0x1E, 0x1E,
0x1E,
> > + 0x1E, 0x1E, 0x1E, 0x1E
> > + };
> > + const u8 values_0110[] = {
> > + 0x07, 0x00, 0x00, 0x00, 0x00, 0x3E, 0x3E, 0x00, 0x04,
0x00,
> > + 0x00, 0x00, 0x00, 0x00
> > + };
> > + const u8 values_0112[] = {
> > + 0x07, 0x00, 0x00, 0x00, 0x00, 0x09, 0x09, 0x00, 0x04,
0x00,
> > + 0x00, 0x00, 0x00, 0x00
> > + };
> > + const u8 values_0114[] = {
> > + 0x87, 0x80, 0x80, 0x80, 0x80, 0xBE, 0xBE, 0x80, 0x84,
0x80,
> > + 0x80, 0x80, 0x80, 0x80
> > + };
> > + const u8 values_0116[] = {
> > + 0xE7, 0xE0, 0xE0, 0xE0, 0xE0, 0xE9, 0xE9, 0xE0, 0xE4,
0xE0,
> > + 0xE0, 0xE0, 0xE0, 0xE0
> > + };
> > + const u8 values_0100[] = {
> > + 0x20, 0x21, 0x21, 0x21, 0x21, 0x21, 0x21, 0x21, 0x23,
0x20,
> > + 0x20, 0x20, 0x20, 0x20
> > + };
> > +
> > + dev_dbg(&dev->udev->dev, "stk1135_configure_device: %d\n", step);
> > +
> > + stk11xx_write_registry(dev, 0x, 0x0024);
> > + stk11xx_write_registry(dev, 0x0002, 0x0068);
> >
Re: [PATCH 1/1] V4L: stk11xx, add a new webcam driver
On 5/28/07, Luca Risolia <[EMAIL PROTECTED]> wrote: On Monday 28 May 2007 17:14:51 Markus Rechberger wrote: > On 5/28/07, Mauro Carvalho Chehab <[EMAIL PROTECTED]> wrote: > > We don't do format conversions in kernel. Instead, you should return a > > proper Bayer Fourcc format (like V4L2_PIX_FMT_SBGGR8). > > It's ok in his case since most userspace applications do not support > this format, it helps noone if there's a driver out there which isn't > supported by most userspace applications and I don't expect that all > applications will add a conversion for that format soon. > This would moreover raise the question about a userspace library, > though there are many more important issues which are outstanding and > which got smashed down. Markus, I do think the userspace library is THE real problem with the whole V4L subsystem. It's annoying to keep repeating why these convertions should be done outside the kernel, be them in a library or not. I deliberatly never implemented the above convertion in the drivers that I have been maintaing for years, since I had the idea that this approach whould have pushed the developers to write the _best_ algorithm by themselves. I still think it's the correct approach, but now I give up. Mauro, if you are planning to accept this BayerToSomething color convertion, be also prepared to accept the same convertion for other drivers in the kernel. Rules are made for everyone. Initially asking for help doesn't lead anywhere either because most people aren't skilled enough or have personal issues with helping out at linuxtv. I'm fine with the conversion, a valid point is scaling, this is something userspace can handle already. And as I mentioned there are more important issues out there which should be handled first, but they're greatly getting ignored again (just as usual, and this also takes regressions and current implementation bugs in account). 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/
Re: [PATCH 1/1] V4L: stk11xx, add a new webcam driver
On 5/28/07, Mauro Carvalho Chehab <[EMAIL PROTECTED]> wrote: Em Seg, 2007-05-28 às 17:14 +0200, Markus Rechberger escreveu: > > > +/* > > > + * Bayer conversion > > > + */ > > > > We don't do format conversions in kernel. Instead, you should return a > > proper Bayer Fourcc format (like V4L2_PIX_FMT_SBGGR8). > > > > It's ok in his case since most userspace applications do not support > this format, it helps noone if there's a driver out there which isn't > supported by most userspace applications and I don't expect that all > applications will add a conversion for that format soon. > This would moreover raise the question about a userspace library, > though there are many more important issues which are outstanding and > which got smashed down. As Luca pointed, if we add conversion for one driver, we should add for the rest. Instead, it would be better if Jiri sends the decoding and the rescaling stuff as a patch to v4l2-apps/lib, starting the API decoding library. Once we have a library, we can ask the userspace developers to use it for the formats not recognized by their userspace apps. I think it would be better to evaluate existing solutions (eg. libpw). Instead starting another one (which would lack any design since I haven't seen any thread that was picking together requirements), improving that existing one might also be helpful for applications like ekiga. As for libpw it also supports colourspace conversion and software scaling, the used algorithms seem to need some improvement, but alot work has already been done there. Of course other libraries should also be taken into account, maybe someone knows something better which is more complete. 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/
Re: [linux-dvb] dst customization patchset
On 5/31/07, Uwe Bugla <[EMAIL PROTECTED]> wrote: Am Donnerstag, 31. Mai 2007 07:01 schrieb Bill Eldridge: > timecop wrote: > >> Guys, it's GPL code. Fork the project and stop your bitching. > >> If you do a better job, people will use and contribute to your version. > >> If you do a worse job, people will use and contribute to Manu's. > >> Some will use and contribute to both. Life's good, eh? > > > > This is exactly why Linux is shit. > > You have 100s of "forked projects" because some guy named Uwe thought > > he could do better than some guy named Manu and now you have two > > projects to contribute to, both suck in various ways, of course some > > idiot is going to be "backporting" from one to another, introducing > > weird bugs, etc etc etc. > > > > Make a fucking decision and stick with it. Stop wasting everyone's > > time. It's no secret that current Linux-DVB/V4L/whatever system is a > > pile of steaming feces. Every one of you admitted to it on this list > > at some point in the past. So get to it, make a fucking decision, > > "fire" (loool) retards who are slowing the project down, and get shit > > moving. I vote for Uwe as Linux-DVB maintainer. > > Regards, > > tc > > I nominate Timecop to be maintainer/top cop to figure out which version > sucks in which area > and do his best to get the best approach used. Sometimes a good strong > and outspoken > manager is more important than technical prowess (and I have no idea as > to your technical > abilities, just saying it looks like a management issue). I am not a fan of "strong men" or "strong managers" of whatever kind. We in Germany have very bad experiences concerning this kind of human desire / call regarding our history. Instead there should be one responsible code reviewer for v4l stuff, and at least one responsible code reviewer for DVB stuff. This is a minimum adequate demand to make things work. Inactivity on future projects in connection with Nacks of activities to optimize the stock kernel are no fair play or helpful behaviour at all, but they are just counterproductive. Who likes small kings? Well, I do not! > > For Uwe, it's not that I don't "want" to understand anything - I just > showed up 2 days ago and > simply want a workable driver for my machine, and instead had to switch > cards to something > else. Usually I assume if the code was forked the fork would be > somewhere else and you wouldn't > be complaining to this list, but I understand there are different ways. > (Samba did it this way for > quite some time). Forking may be OK for different Linux distros. But v4l-DVB is not a distro, it should be a common project instead. What you find is some 20 developers with a multiplicity of repositories. You do not even know who is maintainer and who is not. What you also find is the blocking gesture of that person who once threw his hat into the ring wanting to become maintainer. As the whole situation is one big mess you do not even know whether becoming a maintainer or not is product of a democtratic vote. Above that there is no team structure at all, but instead there is a big chaos, mess. And if some code, may it be humble or mature, is not even pulled into the mm-tree (its basic role has always been testing, nothing else) I would call that a catastrophe. Uwe writes alot insulting crap (which is a fact), even if the DVB subsystem has no maintainer the code should be managed appropriately and stopping the development is no way to do it. At the moment we have __tonns of critical bugs__ in the drivers and the video4linux and dvb framework; both frameworks are incomplete and don't provide the necessary flexibility to support an infrastructure for devices which could already be supported at the moment. We have several (technical) good people which which work on the framework on different parts but who don't cooperate at all and who cannot work together at all. We have alot code which is managed in separated repositories where different developers spent several years of development (including reverse engineering, hacking and so on) it's a shame that the whole project is stuck where it is. New developers who fundamentally want to change something are not welcome at all, even if they have valuable ideas. Some developers are also sick of contributing since the whole community is flawed at the moment. I propose a few ways to go * stopping that signed off by madness that every driver developer has to sign off changes which happened at the core which will definitelly never happen because people _do not like each other_. * change the maintainership and push it over to me, even if it sounds selfish at the moment _every_ code which provides additional features and where noone expects further improvements within the next few weeks (without throwing away alot of work or generating useless extra work by telling someone to rewrite the core of his work); everyone still can try to write better code - but then he _has to do it completly
Re: [linux-dvb] dst customization patchset
On 6/1/07, Bill Eldridge <[EMAIL PROTECTED]> wrote: Sounds good, Markus - do you have a list of known bugs that need to be handled? Yes, I put together a few things that came into mind: http://mcentral.de/wiki/index.php/Bugtracker Is this something that can go up on the Wiki, or are there enough that a bug tracking system is required? Wiki/ML should be fine, people use to avoid the bugzilla on kernel.org although I'd be fine with it (at least for the em28xx project) but people prefer to add bugreports to the wiki or send mails. While timelines won't be enforceable for people doing things in their spare time, it's still useful to put up time goals and priority lists on projects, both new development and bug fixes, to keep momentum going and gauge progress, including seeing that something that should have been fixed isn't getting handled. Can people accept Markus as a reasonable, informed arbiter of what will go into the main tree even if there are disagreements? It also sounds like new programmers here need more startup instructions/assistance/advice and ground rules than on many open source projects. I would appreciate to get more people involved with that project, VDR/mythTV/mplayer/ffmpeg etc. projects use the outcoming work. While the v4l and dvb project is doing really hard at the moment and improvements are handled in a snail speed (if ever handled) this should really change. cheers, Markus Regards, Bill Markus Rechberger wrote: > > Some developers are also sick of contributing since the whole > community is flawed at the moment. I propose a few ways to go > > * stopping that signed off by madness that every driver developer has > to sign off changes which happened at the core which will definitelly > never happen because people _do not like each other_. > > * change the maintainership and push it over to me, even if it sounds > selfish at the moment _every_ code which provides additional features > and where noone expects further improvements within the next few weeks > (without throwing away alot of work or generating useless extra work > by telling someone to rewrite the core of his work); everyone still > can try to write better code - but then he _has to do it completly_ > and get in peace with the projects by supporting them to get further. > > The problem I have with this project is that many more things are > upcoming at the moment (including bug fixing) but there are certain > developers which first weren't experienced enough, afterwards started > to think about the issues which were tried to discuss at the beginning > already and who don't have an overview about the requirements, neither > do they want to discuss the requirements. > I can name numerous of bugs of this project which can be solved but > which just get ignored. Some known bugs dont even get explained to > people who are interested in fixing them, so this is what I consider > that it's a major problem. > > I'm looking for a serious discussion about it, if anyone wants to know > about the history I can point out to many logfiles/older emails which > deeply explain the whole video4linux/dvb issues - the project should > turn back to a real community. > > Markus > -- Markus Rechberger - 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
On 5/16/07, Al Viro <[EMAIL PROTECTED]> wrote: On Wed, May 16, 2007 at 03:25:23AM +0400, Manu Abraham wrote: > 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 ? Because video-buf.c does. And VIDEO_EM28XX selects it. the em28xx does not rely on video-buf, this seems to be a dependency derived from another dependency. 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/
[patch] remove orphaned Email
Manuel Estrada Sainz passed away on May 9th 2004, his email account got
deactivated. He was in charge of the firmware_class code, and still got
CC'ed in recent discussions about it.
Signed-off-by: Markus Rechberger <[EMAIL PROTECTED]>
diff --git a/Documentation/firmware_class/README b/Documentation/firmware_class/README
index e9cc8bb..d19eb19 100644
--- a/Documentation/firmware_class/README
+++ b/Documentation/firmware_class/README
@@ -1,7 +1,7 @@
request_firmware() hotplug interface:
- Copyright (C) 2003 Manuel Estrada Sainz <[EMAIL PROTECTED]>
+ Copyright (C) 2003 Manuel Estrada Sainz (passed away on May 9th 2004 at a car accident)
Why:
---
diff --git a/Documentation/firmware_class/firmware_sample_driver.c b/Documentation/firmware_class/firmware_sample_driver.c
index 87feccd..3d4a877 100644
--- a/Documentation/firmware_class/firmware_sample_driver.c
+++ b/Documentation/firmware_class/firmware_sample_driver.c
@@ -1,7 +1,7 @@
/*
* firmware_sample_driver.c -
*
- * Copyright (c) 2003 Manuel Estrada Sainz <[EMAIL PROTECTED]>
+ * Copyright (c) 2003 Manuel Estrada Sainz (passed away on May 9th 2004 at a car accident)
*
* Sample code on how to use request_firmware() from drivers.
*
diff --git a/Documentation/firmware_class/firmware_sample_firmware_class.c b/Documentation/firmware_class/firmware_sample_firmware_class.c
index 9e1b0e4..678b050 100644
--- a/Documentation/firmware_class/firmware_sample_firmware_class.c
+++ b/Documentation/firmware_class/firmware_sample_firmware_class.c
@@ -1,7 +1,7 @@
/*
* firmware_sample_firmware_class.c -
*
- * Copyright (c) 2003 Manuel Estrada Sainz <[EMAIL PROTECTED]>
+ * Copyright (c) 2003 Manuel Estrada Sainz (passed away on May 9th 2004 at a car accident)
*
* NOTE: This is just a probe of concept, if you think that your driver would
* be well served by this mechanism please contact me first.
@@ -19,7 +19,7 @@
#include
-MODULE_AUTHOR("Manuel Estrada Sainz <[EMAIL PROTECTED]>");
+MODULE_AUTHOR("Manuel Estrada Sainz");
MODULE_DESCRIPTION("Hackish sample for using firmware class directly");
MODULE_LICENSE("GPL");
diff --git a/drivers/base/firmware_class.c b/drivers/base/firmware_class.c
index 97ab5bd..672c221 100644
--- a/drivers/base/firmware_class.c
+++ b/drivers/base/firmware_class.c
@@ -1,7 +1,7 @@
/*
* firmware_class.c - Multi purpose firmware loading support
*
- * Copyright (c) 2003 Manuel Estrada Sainz <[EMAIL PROTECTED]>
+ * Copyright (c) 2003 Manuel Estrada Sainz (passed away on May 9th 2004 at a car accident)
*
* Please see Documentation/firmware_class/ for more information.
*
@@ -23,7 +23,7 @@
#define to_dev(obj) container_of(obj, struct device, kobj)
-MODULE_AUTHOR("Manuel Estrada Sainz <[EMAIL PROTECTED]>");
+MODULE_AUTHOR("Manuel Estrada Sainz");
MODULE_DESCRIPTION("Multi purpose firmware loading support");
MODULE_LICENSE("GPL");
Re: pci probe
On 5/30/07, Greg KH <[EMAIL PROTECTED]> wrote: On Wed, May 16, 2007 at 04:29:38PM +0400, Manu Abraham wrote: > 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 Are you sure? PCI Hotplug is showing up in more places that people realize... In case of video4linux and dvb, there are cx88 and saa7134 based pcmcia devices available which show up as PCI devices, both of these drivers enable the interrupts as soon as they're connected and there's no need to access the device nodes for that. Another point is that they're not hotplug aware, the driver end up in an endless loop or crashes linux if someone unplugs the device (even if it's not in use). > > - 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. Uwe posted an example how to tie multiple functions of a device together, there are quite a few ways how to solve that problem. http://linuxtv.org/pipermail/linux-dvb/2007-June/018481.html 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/
Re: 2.6.22-rc6 spurious hangs
On 6/29/07, Mauro Carvalho Chehab <[EMAIL PROTECTED]> wrote: > Still we can't do this under cinergyt2->sem, because cinergyt2_query() > takes it too. This all looks very wrong to me, I hope maintaners can > explain. AFAIK, the driver authors are not working anymore with CinergyT2. The last patch we have on development tree from Holger is dated as Dec, 3 2004. Since them, only internal kernel API changes and a few sparse fixes from other contributors were applied. Also, none of the current DVB maintainers seem to have any hardware for testing. I received a Mail a while ago that this driver is open to the community, it duplicates some code because the developers wanted to use this driver for testing another DVB API which never took off. Best would be to remove the duplicated code in that driver and make it look like all other DVB drivers. 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/
Re: How should an exit routine wait for release() callbacks?
Alan,
seems like you have the same problem as the dvb framework has/had.
http://mcentral.de/hg/~mrec/v4l-dvb-stable
The last 3 changesets do the trick to not oops, it will delay the
deinitialization of the device till the last user closed the device node.
Markus
Cornelia Huck wrote:
On Thu, 12 Apr 2007 17:23:18 -0400 (EDT),
Alan Stern <[EMAIL PROTECTED]> wrote:
Here's a not-so-theoretical question.
I've got a module which registers a struct device. (It represents a
virtual device, not a real one, but that doesn't matter.) Obviously the
module's exit routine has to wait until the release() routine for that
device has been invoked -- if it returned too early then the release()
call would oops.
How should it wait?
Device lifetime vs. module lifetime - that's a fun one...
The most straightforward approach is to use a struct completion, like
this:
static struct {
struct device dev;
...
} my_dev;
static DECLARE_COMPLETION(my_completion);
static void my_release(struct device *dev)
{
complete(&my_completion);
}
static void __exit my_exit(void)
{
device_unregister(&my_dev.dev);
wait_for_completion(&my_completion);
}
The problem is that there is no guarantee a context switch won't take
place after my_release() has called complete() and before my_release()
returns. If that happens and my_exit() finishes running, then the module
will be unloaded and the next context switch back to finish off
my_release() will oops.
Other approaches have similar defects. So how can this problem be solved?
What I see that a device driver may do now is the following:
- disallow module unloading (duh)
- move the release function outside the module
To make the completion approach work, the complete() would need to be
after the release function. This would imply an upper layer, but this
upper layer would need to access the completion structure in the
module...
One could think about a owner field (for getting/putting the module
reference) for the object (with a final module_put() after the release
function has been called). The problem there would be that it would
preclude unloading of the module if there isn't a "self destruct" knob
for the object.
-
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/
--
| AMD Saxony Limited Liability Company & Co. KG
Operating | Wilschdorfer Landstr. 101, 01109 Dresden, Germany
System | Register Court Dresden: HRA 4896
Research | General Partner authorized to represent:
Center | AMD Saxony LLC (Wilmington, Delaware, US)
| General Manager of AMD Saxony LLC: Dr. Hans-R. Deppe, Thomas McCoy
-
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: How should an exit routine wait for release() callbacks?
Cornelia Huck wrote: On Fri, 13 Apr 2007 13:42:04 +0200, "Markus Rechberger" <[EMAIL PROTECTED]> wrote: seems like you have the same problem as the dvb framework has/had. http://mcentral.de/hg/~mrec/v4l-dvb-stable The last 3 changesets do the trick to not oops, it will delay the deinitialization of the device till the last user closed the device node. Probably dumb question (since I'm not at all familiar with the dvb code): Isn't that a different race you're solving there? I don't see any driver core objects involved (except class devices created by class_device_create, which obviously don't have the release function problem). This looks more like a race of "we want an object to go away, but a user still has a file open" (which would be similar to the kobject<->sysfs lifetime rules issues, where work is currently ongoing). most dvb usb drivers call the device node unregistration when a device gets unplugged (when At this time the filehandle can still be open, the patch on that site sets a flag that disallows any further access to the device node (in the DVB framework there are 4 of such nodes) This can happen any time, so while someone is reading or accessing the device some structures might have gone away already and this could cause an oops. The problem of the DVB framework is file operation related, the last user calls fops_put on the existing structure and sets the pointer to NULL before it wakes up the other function which frees the file operation structure. In Alan's case isn't there any users flag available that shows that the structure is still beeing accessed? If that would be the case he could set a flag when he enters my_exit which would disable access to all other functions by returning an error value at the beginning of the other functions, the only way out would be to call my_release for existing users and wake up my_exit when the last reference to that structure is gone. Some more information about the whole driver/scenario would be helpful. Markus -- | AMD Saxony Limited Liability Company & Co. KG Operating | Wilschdorfer Landstr. 101, 01109 Dresden, Germany System| Register Court Dresden: HRA 4896 Research | General Partner authorized to represent: Center| AMD Saxony LLC (Wilmington, Delaware, US) | General Manager of AMD Saxony LLC: Dr. Hans-R. Deppe, Thomas McCoy - 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
On 4/16/07, Manu Abraham <[EMAIL PROTECTED]> wrote: 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. The patch has been around on the dvb mailinglist ([PATCH][RFC] DVB Hotplug Fix, 5. April 2007), Michael looked at it when I told him about it again separatly (12. April 2007) Between that there was enough time to respond on it or review it. Mauro told me at the beginning if noone responds he'll go forward somehow because it fixes hotplugging, and after 2 weeks I wouldn't expect anyone commenting that thread anymore. It would be better to look and respond to that patch first before responding about that you don't like how it's handled, Mauro also wrote in his announcement that people should look at the recent mercurial tree and he'll revert it if something doesn't work by accident before submitting it to his git tree... still noone complained about the hotplugging patch in there. 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/
Re: [v4l-dvb-maintainer] [GIT PATCHES] V4L/DVB updates
On 4/16/07, Michael Krufky <[EMAIL PROTECTED]> wrote: Adrian Bunk wrote: > On Sun, Apr 15, 2007 at 08:33:38PM -0400, Michael Krufky wrote: >> Mauro, >> >> I've been out of town for the past few days... I just got home and saw this: >> >> >> Mauro Carvalho Chehab wrote: >>>- Fix 1/3 for bug 7819: fixed frontend hotplug issue >>>- Fix 2/3 for bug 7819: demux and dvr >>>- Fix 3/3 for bug 7819: fixed hotplugging for dvbnet >> I don't think that this is 2.6.21 material. These patches have not yet >> received >> enough testing to be sent to mainline. >> >> I have tested them, and they seem to work for my cxusb device, but we have >> yet to hear test results from users of usb dvb devices that do not use the >> dvb-usb framework. (ttusb, flexcop-usb, cinergyT2, for example) >> >> The bug that these patches fix has been around throughout the entire kernel >> history of the dvb subsystem. The bug is not a regression -- it has >> always been >> there. In my opinion, it is too late in 2.6.21 development to apply >> this change. >> Because these fixes are not obvious, I think we should let them get some >> more testing, and have them queued for 2.6.22 . > > Unless I misunderstand anything, this should fix [1]. > > And this is a bug that was reported to be present in 2.6.21-rc but not > in 2.6.20 (and it's therefore a regression, no matter whether the > underlying problem was older and only exposed by some other change). Not true. The DVB subsystem has NEVER been hot-unpluggable. I confirm that the patches SEEM to be correct, but this has not yet been verified. None of the authors of dvb-core gave their ACK on these changesets. The DVB hotplug issue has been around since the very beginning. I assure you, that I consider this fix to be very important, and I really would love to see it hit mainline. However, given the situation, it is not appropriate to push these in during -rc7 I have doubts on CIJOML's testing method -- there is no way he could have unplugged the device while in use, while running 2.6.20.y and not receive an OOPS. CIJOML, please see the bottom of this email for Sure, this will prevent an OOPS on some, and hopefully all devices... but what if it causes a regression for those untested? Why do we have a merge window, if new changesets are going to be rushed into late -rc kernels without proper testing, and without the ack of a dvb subsystem maintainer? Are we prepared to go for another -rc and 3 or 4 weeks of testing to confirm that this fix doesn't cause new regressions? I don't think so. The problem I see with the cinergyT2 is that this driver reimplements the frontend code and doesn't even use the dvb-core template, so a proper fix would also be to reimplement that fix in the cinergyT2 device. I don't think Daniel Mack or Holger Waechtler manage this driver anymore because they didn't comment the last few fixes that were applied to that driver (though I put them into CC here) As far as I remember someone wrote that they didn't want to use the dvb_frontend code back then for any reason. So the only driver I'd take into account would be the flexcop driver. Currently tested drivers are: dvb-usb based devices, and em28xx/em2880 based devices Markus Markus Rechberger wrote: > The patch has been around on the dvb mailinglist ([PATCH][RFC] DVB > Hotplug Fix, 5. April 2007), The patch was merged into the development repository at the same time the pull request was issued to Linus. This has NOT been tested on a wide scale. It should go to -mm for a while before being merged to mainline. Mauro Carvalho Chehab wrote: > I also explicitly warned at DVB ML that I were about to send this patch, > together with other fixes, asking the community for more tests. After > that, I received two positive answers on my mailbox from people that > tested and noticed that this really fixed the issue. One of those positive answers was me - I explained that it worked for me, but we need others to test. You waited ONE DAY after sending this "warning" to the dvb mailing list? ( http://linuxtv.org/pipermail/linux-dvb/2007-April/017204.html ) I saw that email after seeing the pull request to Linus. We dont have users testing the repositories after each commit -- you _really_ need to give some more time to allow for such testing. CIJOML wrote: > Hi, > > I have tested these patches with: > > Freecom DVB-T dongle > Pluto2 pcmcia card > Leadtek WinFast DTV dongle 1st generation > Leadtek WinFast DTV dongle 2nd generation > > These are 4 different devices with 4 different hw and modules. > All works. Please apply. Well, that helps... But it would still be nice to hear test results on a CinergyT2 o
Re: [linux-dvb] Re: [video4linux-cvs] [hg:v4l-dvb] Add support for Opera S1- DVB-USB
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.c Thu Apr 19 12:04:50 2007 -0300 > +++ b/linux/drivers/media/dvb/dvb-usb/opera1.c Thu 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. 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/
Re: Oops on 2.6.21 with dvb-usb-dib0700?
Hi, this will be fixed in upcoming kernel releases, there's already a patch for that in the video4linux/dvb repository on linuxtv.org. So if you update your v4l-dvb drivers that problem shouldn't occure anymore. http://linuxtv.org/repo/ -Markus On 4/19/07, Chris Murton <[EMAIL PROTECTED]> wrote: > Hi, > > Get an occasional Oops which can occur either when the device is in use, > or idle.. and it only usually happens after several hours of uptime with > the module and device loaded. The 'oops' seems to directly correlate > with the device appearing to disconnect and reconnect via USB (but > nothing physical has changed). > > In this example, the box was booted at 21:50 and the Oops occurred at > 03:13 when the device was idle: > > Apr 19 03:13:01 basil kernel: usb 2-1: USB disconnect, address 2 > Apr 19 03:13:01 basil kernel: ehci_hcd :04:08.2: qh 81003dbc61e0 > (#82) state 4(has tds) > Apr 19 03:13:01 basil kernel: mt2060 I2C write failed > Apr 19 03:13:01 basil kernel: mt2060 I2C write failed > Apr 19 03:13:01 basil kernel: dvb-usb: Hauppauge Nova-T 500 Dual DVB-T > successfully deinitialized and disconnected. > Apr 19 03:13:02 basil kernel: usb 2-1: new high speed USB device using > ehci_hcd and address 3 > Apr 19 03:13:02 basil kernel: usb 2-1: configuration #1 chosen from 1 choice > Apr 19 03:13:02 basil kernel: dvb-usb: found a 'Hauppauge Nova-T 500 > Dual DVB-T' in warm state. > Apr 19 03:13:02 basil kernel: **WARNING** I2C adapter driver [Hauppauge > Nova-T 500 Dual DVB-T] forgot to specify physical device; fi > x it! > Apr 19 03:13:02 basil kernel: dvb-usb: will pass the complete MPEG2 > transport stream to the software demuxer. > Apr 19 03:13:02 basil kernel: DVB: registering new adapter (Hauppauge > Nova-T 500 Dual DVB-T). > Apr 19 03:13:02 basil kernel: **WARNING** I2C adapter driver [DiBX000 > tuner I2C bus] forgot to specify physical device; fix it! > Apr 19 03:13:02 basil kernel: DVB: registering frontend 0 (DiBcom > 3000MC/P)... > Apr 19 03:13:02 basil kernel: MT2060: successfully identified (IF1 = 1220) > Apr 19 03:13:02 basil kernel: dvb-usb: will pass the complete MPEG2 > transport stream to the software demuxer. > Apr 19 03:13:02 basil kernel: DVB: registering new adapter (Hauppauge > Nova-T 500 Dual DVB-T). > Apr 19 03:13:02 basil kernel: **WARNING** I2C adapter driver [DiBX000 > tuner I2C bus] forgot to specify physical device; fix it! > Apr 19 03:13:02 basil kernel: DVB: registering frontend 1 (DiBcom > 3000MC/P)... > Apr 19 03:13:02 basil kernel: MT2060: successfully identified (IF1 = 1220) > Apr 19 03:13:03 basil kernel: dvb-usb: Hauppauge Nova-T 500 Dual DVB-T > successfully initialized and connected. > Apr 19 03:17:30 basil kernel: Unable to handle kernel NULL pointer > dereference at RIP: > Apr 19 03:17:30 basil kernel: [] > __mutex_lock_interruptible_slowpath+0x22/0x99 > Apr 19 03:17:30 basil kernel: PGD 13042067 PUD 13043067 PMD 0 > Apr 19 03:17:30 basil kernel: Oops: 0002 [1] > Apr 19 03:17:30 basil kernel: CPU 0 > Apr 19 03:17:30 basil kernel: Modules linked in: nvidia(P) snd_mpu401 > snd_mpu401_uart snd_seq_midi snd_seq_midi_event snd_hda_intel > snd_hda_codec snd_seq snd_pcm_oss snd_mixer_oss dvb_usb_dib0700 dib7000m > dib7000p dvb_usb snd_rawmidi dvb_core snd_pcm snd_timer snd > _seq_device lirc_imon lirc_mceusb2 lirc_dev dvb_pll dib3000mc > dibx000_common mt2060 snd_page_alloc > Apr 19 03:17:30 basil kernel: Pid: 7860, comm: mythbackend Tainted: > P 2.6.20 #1 > Apr 19 03:17:30 basil kernel: RIP: 0010:[] > [] __mutex_lock_interruptible_slowpath+0x22/0x99 > Apr 19 03:17:30 basil kernel: RSP: 0018:81002e929ea8 EFLAGS: 00010292 > Apr 19 03:17:30 basil kernel: RAX: c200101ad0a0 RBX: > c200101ad098 RCX: > Apr 19 03:17:30 basil kernel: RDX: 81002e929fd8 RSI: > 8100331ee980 RDI: c200101ad098 > Apr 19 03:17:30 basil kernel: RBP: 810034403200 R08: > R09: 1eb4 > Apr 19 03:17:30 basil kernel: R10: R11: > 0206 R12: c200101ad098 > Apr 19 03:17:30 basil kernel: R13: 81003cff7418 R14: > 81003da1a8c0 R15: 81003c997b70 > Apr 19 03:17:30 basil kernel: FS: 4a816960(0063) > GS:80615000() knlGS:f7db58c0 > Apr 19 03:17:30 basil kernel: CS: 0010 DS: ES: CR0: > 8005003b > Apr 19 03:17:30 basil kernel: CR2: CR3: > 13041000 CR4: 06e0 > Apr 19 03:17:30 basil kernel: Process mythbackend (pid: 7860, threadinfo > 81002e928000, task 810034403200) > Apr 19 03:17:30 basil kernel: Stack: c200101ad0a0 > 0008 > Apr 19 03:17:30 basil kernel: 81003c542fa0 c200101ad000 > 81003c542fa0 88043d22 > Apr 19 03:17:30 basil kernel: 0008 8100331ee980 > 81003cff7418 802618ec > Apr 19 03:17:30 basil kernel: Call Trace: > Apr 19 03:17:30 basil kernel: [] > :dvb_core:d
Re: [linux-dvb] DST/BT878 module customization (.. was: Critical points about ...)
On 5/3/07, Manu Abraham <[EMAIL PROTECTED]> wrote: 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 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. 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. I sent several comments to Uwe to stop flaming, Trent was in the CC sometimes I never wrote that he should flame on anyone. I can simply forward you all mails I sent to Uwe there's not one bad mail. My point is moreover to get that issue sorted out by either accepting his "proposal" or stating out why not to add it (and there must be a reason behind it, and no mail which is 2 years old, or explaining what the device is, again it got explained what's required from you) seems like your response is based on that misunderstood sentence, sorry for not beeing clear enough. 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/
Re: [linux-dvb] DST/BT878 module customization (.. was: Critical points about ...)
On 5/4/07, Manu Abraham <[EMAIL PROTECTED]> wrote: 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." And what issues are outstanding of these discussions? I went over it and it just shows up that there have been communication problems in 2005. We now have open issues with several device drivers and that's what we should focus at. 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/
Re: [4/4] 2.6.21-rc5: known regressions (v2)
Subject: USB: Oops when changing DVB-T adapter References : http://lkml.org/lkml/2007/3/9/212 Submitter : CIJOML <[EMAIL PROTECTED]> Status : unknown regarding this one there's a fix available for unplugging dvb devices when they're in still in use. The problem was that the filehandle was still open and the fops structure got deallocated immediatelly when a device got unplugged. http://mcentral.de/hg/~mrec/v4l-dvb-stable/ (the last 3 patches) Markus On 4/1/07, Michael S. Tsirkin <[EMAIL PROTECTED]> wrote: > > Subject: after resume: X hangs after drawing a couple of windows > > workaround: clocksource=acpi_pm > > References : http://lkml.org/lkml/2007/3/8/117 > > http://lkml.org/lkml/2007/3/25/20 > > http://lkml.org/lkml/2007/3/26/151 > > Submitter : Michael S. Tsirkin <[EMAIL PROTECTED]> > > Handled-By : Thomas Gleixner <[EMAIL PROTECTED]> > > Status : problem is being debugged > > Seems to be resolved with 399afa4fc9238fbae42116cf25a54671c0e8f56e. > Thanks Maxim! > > > -- > MST > - > 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/ > -- Markus Rechberger -- Markus Rechberger Operating System Research Center AMD Saxony LLC & Co. KG - 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] x86: limit mwait_idle to Intel CPUs
H. Peter Anvin wrote: Andreas Herrmann wrote: It is not equivalent. Usually users check /proc/cpuinfo for their CPU features. Deleting that flag is kind of obfuscation. I guess some time ago people did not care about their "svm" or "vmx" flags. Nowadays (e.g. with kvm) some people are quite happy if one of those strings occurs in /proc/cpuinfo (and they are quite disappointed if this feature was disabled by BIOS). What you're saying is that you want it to appear in /proc/cpuinfo for marketing reasons even though it's not usable. The ones in /proc/cpuinfo are cooked values anyway; there is plenty of history to that effect. I would agree with Andi that if as far as Linux is concerned mwait is unusable on AMD Fam10 processors, then the CPU detection code should turn this bit off on AMD Fam10 processors. please see: http://kvm.qumranet.com/kvmwiki/FAQ "How can I tell if I have Intel VT or AMD-V?" Markus -- Markus Rechberger Operating System Research Center AMD Saxony LLC & Co. KG - 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: kernel OOPSes when changing DVB-T adapter in 2.6.21-rc3
I committed a patch which fixes this issue: http://mcentral.de/hg/~mrec/v4l-dvb-stable/ That problem got caused by releasing data structures which are still in use when the device gets unplugged. These patches delay the deallocation of the data till the last user releases its reference to the dvb nodes. This patch got tested with devices which use the dvb-usb framework as well as em28xx based dvb devices. Markus On 3/16/07, Oliver Neukum <[EMAIL PROTECTED]> wrote: Am Freitag, 16. März 2007 10:13 schrieb CIJOML: > Hi, > > looks like more general problem with 2.6.21-rc3. This happens when I remove my > PCMCIA USB2.0/IEEE1384 adapter from slot: Yes, the more important it is to know whether -rc2 works. And please report this as a generic sysfs failure to lkml. Regards Oliver - 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/ -- Markus Rechberger - 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: Does V4L driver support audio capture?
On 4/10/07, code GG <[EMAIL PROTECTED]> wrote: Hi all, Are there any V4L API supporting audio capture (supposing the TV card hardware has such ability), just like the APIs and structures for video capture? for capturing usually OSS or alsa is used, you might have a look at the em28xx code and search for audio (VIDIOC_G_AUDIO, VIDIOC_S_AUDIO) there are drawbacks at the moment that you usually don't know what audio device belongs to your TV card if you want to capture audio digitally without looking at your dmesg or reading the individual description of the created audio device (userspace applications usually don't know about that and you have to set up the soundcard - tvtuner bridge manually) 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/
Re: [Intel IOMMU][patch 6/8] Doc updates for Intel Virtualization Technology for Directed I/O.
=== --- linux-2.6.21-rc5.orig/Documentation/kernel-parameters.txt 2007-04-17 04:59:42.0 -0700 +++ linux-2.6.21-rc5/Documentation/kernel-parameters.txt2007-04-17 05:41:56.0 -0700 @@ -710,6 +710,26 @@ inttest=[IA64] + intel_iommu=[DMAR] Intel IOMMU driver (DMAR) option + off + Disable intel iommu driver. + forcerw + Some drivers might incorrectly map DMA buffers as + write-only even when the device, requires read/write + mapping. This option works around the issue in IOMMU + driver by making all write-only map as read/write. + Default is off. + igfx_off [Default Off] + By default, gfx is mapped as normal device. If a gfx + device has a dedicated DMAR unit, the DMAR unit is + bypassed with this option. In this case, gfx device + will use physical address for DMA. + gfx_workaround [Default Off] + gfx devices tend to use physical address for DMA and + avoid using DMA api's. Setting this option permits + the IOMMU driver to set a unity map for all OS + visible memory. Hence the driver can continue to use + physical addresses for DMA. io7=[HW] IO7 for Marvel based alpha systems See comment before marvel_specify_io7 in arch/alpha/kernel/core_marvel.c. -- - 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/ -- Markus Rechberger - 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: More than 2Gb problem (dvb related) ?
just for the completeness, what does dmesg show up? You forgot to mention what device you have too... Markus On 4/27/07, Gregoire Favre <[EMAIL PROTECTED]> wrote: Hello, I have a computer (mother Asus Commando) with 4x1Gb Ram. If I start without the BIOS remap memory, my BIOS and linux just see 2Gb of ram, and DVB apps works just great. When I enable the remapping of the memory, my BIOS and linux just see the whole 4Gb but then, I can tune to any transponder without problem, but I am unable to get a TS... I have tested it with vdr/kaffeine/mplayer. szap/kaffeine/vdr get the lock just well. I had already asked about this on just linux-dvb ml, but maybe I am the first one to try DVB with a system with more than 2 Gb as I didn't receive any further info as someone get it working or not with such amount of ram. Anyone got an idea on what could be done to solve this issue ? PLEASE CC to me all message in lkml as I am not subscribed to this ml :) -- Grégoire FAVRE http://gregoire.favre.googlepages.com http://www.gnupg.org http://picasaweb.google.com/Gregoire.Favre - 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/ -- Markus Rechberger - 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
On 4/27/07, Trent Piepho <[EMAIL PROTECTED]> wrote:
On Mon, 16 Apr 2007, Markus Rechberger wrote:
> On 4/16/07, Michael Krufky <[EMAIL PROTECTED]> wrote:
> > Adrian Bunk wrote:
> > > On Sun, Apr 15, 2007 at 08:33:38PM -0400, Michael Krufky wrote:
> > >> Mauro,
> > >>
> > >> I've been out of town for the past few days... I just got home and
saw
> > this:
> > >>
> > >>
> > >> Mauro Carvalho Chehab wrote:
> > >>>- Fix 1/3 for bug 7819: fixed frontend hotplug issue
> > >>>- Fix 2/3 for bug 7819: demux and dvr
> > >>>- Fix 3/3 for bug 7819: fixed hotplugging for dvbnet
> > >> I don't think that this is 2.6.21 material. These patches have not
yet
> > >> received
> > >> enough testing to be sent to mainline.
I wish these patches had more comments about how they worked, because it's
not clear to me exactly what they are doing or why they do it.
Fix 3/3 for bug 7819: fixed hotplugging for dvbnet
I'm just going to talk about this one patch, since it appears to be the
simplest.
This patch removes the 'wait_queue' memory of dvb_demux. Why does a patch
to dvbnet have anything to do with the demux device? Should this change
have been part of the previous patch, the one what fixes demux and dvr?
The waitqueue got added in a previous patch just ignore it..
The patch replace the (file_operations)->release pointer with the new
function dvb_net_close() in place of dvb_generic_release(). The first
part of dvb_net_close() is just a cut&paste from dvb_generic_release(),
so maybe it would be better to just call dvb_generic_release() instead?
no because it needs the dvb_net structure which cannot be used in the
dvb_generic_release function.
There is also a bug:
+static int dvb_net_close(struct inode *inode, struct file *file)
+{
+ struct dvb_device *dvbdev = file->private_data;
+ struct dvb_net *dvbnet = dvbdev->priv;
+
+ if (!dvbdev)
+ return -ENODEV;
The check for !dvbdev is too late, dvbdev was already dereferenced on the
previous line to get dvbnet, so if dvbdev is NULL you will have already
crashed.
I think this check isn't needed at all actually, why should someone
release dvbdev before already?
Is the check for !dvbdev unnecessary paranoia? Or can dvbdev actually be
NULL is some cases?
So, w.r.t. dvbnet, my understanding is that somehow dvb_net_release() is
called while the net device is still in use. Is that correct?
dvb_net_release() will end up deleting some stuff that needs to be around
while there is still a user of the device?
Would it be possible to keep dvb_net_release() from getting called in the
first place until there are no users of the device?
When looking at this code, keep in mind that users starts at 1 and goes
down as the device is used.
void dvb_net_release (struct dvb_net *dvbnet)
{
int i;
dvbnet->exit = 1;
if (dvbnet->dvbdev->users < 1) /* line A */
wait_event(dvbnet->dvbdev->wait_queue, /* line B */
dvbnet->dvbdev->users==1);
/* line C */
dvb_unregister_device(dvbnet->dvbdev);
[...]
}
Isn't there a race condition here? What if there are no users of the
device at the time line A runs, but the device is opened before line C
runs? After the wait_even() on line B returns there are no users, but what
if new users opens the device after the after line B?
yes this is a valid argument, practically it will never occure though.
Since I also wrote that I didn't have a dvb signal at the time of
writing this I don't even know if the dvb-net implementation is ok at
all.
I don't even know if that part of the framework works and if someone
really uses it.
Is seems like you need something to prevent new users from opening the
device, i.e. make it so that dvbnet->exit=1 prevents the device from
getting opened, but if that's the intention, I don't see where it's
happening.
In dvb_net_close():
+ if(dvbdev->users == 1 && dvbnet->exit==1) {
+ fops_put(file->f_op);
+ file->f_op = NULL;
+ wake_up(&dvbdev->wait_queue);
+ }
What is the purpose of the fops_put() call and setting file->f_op to NULL?
fops_put lowers the usecount on the inode, after wake_up the f_op
structure is invalid because it's just allocated memory which gets
freed by the dvb release function.
thanks for reviewing,
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/
Re: More than 2Gb problem (dvb related) ?
Does this only happen with DVB and not with analogue TV (I know there are some cx88 hybrid devices out there, I recently got one but couldn't tested it yet ..)? Markus On 4/28/07, Robert Hancock <[EMAIL PROTECTED]> wrote: Gregoire Favre wrote: > Hello, > > I have a computer (mother Asus Commando) with 4x1Gb Ram. > > If I start without the BIOS remap memory, my BIOS and linux just see 2Gb > of ram, and DVB apps works just great. > > When I enable the remapping of the memory, my BIOS and linux just see > the whole 4Gb but then, I can tune to any transponder without problem, > but I am unable to get a TS... > > I have tested it with vdr/kaffeine/mplayer. > > szap/kaffeine/vdr get the lock just well. > > I had already asked about this on just linux-dvb ml, but maybe I am the > first one to try DVB with a system with more than 2 Gb as I didn't > receive any further info as someone get it working or not with such > amount of ram. > > Anyone got an idea on what could be done to solve this issue ? > > PLEASE CC to me all message in lkml as I am not subscribed to this ml :) Sounds like the cx88 driver is not using the DMA API properly to set up proper mappings, this will blow up if it tries to access memory above the 4GB mark if the device cannot do >32bit DMA.. -- Robert Hancock Saskatoon, SK, Canada To email, remove "nospam" from [EMAIL PROTECTED] Home Page: http://www.roberthancock.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/ -- Markus Rechberger - 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
On 4/28/07, Trent Piepho <[EMAIL PROTECTED]> wrote:
On Sat, 28 Apr 2007, Markus Rechberger wrote:
> On 4/27/07, Trent Piepho <[EMAIL PROTECTED]> wrote:
> > On Mon, 16 Apr 2007, Markus Rechberger wrote:
> > > > >> enough testing to be sent to mainline.
> >
> > I wish these patches had more comments about how they worked, because
it's
> > not clear to me exactly what they are doing or why they do it.
> >
> > Fix 3/3 for bug 7819: fixed hotplugging for dvbnet
> >
> > I'm just going to talk about this one patch, since it appears to be the
> > simplest.
> >
> > This patch removes the 'wait_queue' memory of dvb_demux. Why does a
patch
> > to dvbnet have anything to do with the demux device? Should this change
> > have been part of the previous patch, the one what fixes demux and dvr?
> >
>
> The waitqueue got added in a previous patch just ignore it..
Do the patches need to be applied all together? If I apply just the first
two, do I get something that's broken?
yes very likely only because of this wait_queue..
> > The patch replace the (file_operations)->release pointer with the new
> > function dvb_net_close() in place of dvb_generic_release(). The first
> > part of dvb_net_close() is just a cut&paste from dvb_generic_release(),
> > so maybe it would be better to just call dvb_generic_release() instead?
> >
>
> no because it needs the dvb_net structure which cannot be used in the
> dvb_generic_release function.
I mean, have dvb_net_close() call dvb_generic_release() and then do the
extra stuff.
dvb_generic_release is really generic and has no information about the
dvb net structure if it's used for eg. the frontend
for example the dvb_frontend release function:
static int dvb_frontend_release(struct inode *inode, struct file *file)
{
struct dvb_device *dvbdev = file->private_data;
struct dvb_frontend *fe = dvbdev->priv;
struct dvb_frontend_private *fepriv = fe->frontend_priv;
it would be possible to use dvb_release_generic if there wouldn't be
any reference to dvb_frontend and dvb_frontend_private.
In case of dvb-net it's a dvb_net specific release function by adding
the dvb_net structure.
If you look at dvb_generic_release it only uses dvb_device which is
really generic and used by all the dvb modules (frontend/dmx/..)
> > There is also a bug:
> >
> > +static int dvb_net_close(struct inode *inode, struct file *file)
> > +{
> > + struct dvb_device *dvbdev = file->private_data;
> > + struct dvb_net *dvbnet = dvbdev->priv;
> > +
> > + if (!dvbdev)
> > + return -ENODEV;
> >
> > The check for !dvbdev is too late, dvbdev was already dereferenced on
the
> > previous line to get dvbnet, so if dvbdev is NULL you will have already
> > crashed.
> >
>
> I think this check isn't needed at all actually, why should someone
> release dvbdev before already?
>
> > Is the check for !dvbdev unnecessary paranoia? Or can dvbdev actually
be
> > NULL is some cases?
> >
> > So, w.r.t. dvbnet, my understanding is that somehow dvb_net_release() is
> > called while the net device is still in use. Is that correct?
> > dvb_net_release() will end up deleting some stuff that needs to be
around
> > while there is still a user of the device?
> >
> > Would it be possible to keep dvb_net_release() from getting called in
the
> > first place until there are no users of the device?
What about this? I don't have any hot pluggable hardware, so how does
dvb_net_release() get called when the device disconnects?
I don't understand, it's inode based if you open the file it will also
release the file if you close it.
If it's not hotpluggable it will not use the wait_queue because the
usecount would be 0 already when unloading the module.
> > When looking at this code, keep in mind that users starts at 1 and goes
> > down as the device is used.
> >
> > void dvb_net_release (struct dvb_net *dvbnet)
> > {
> > int i;
> >
> > dvbnet->exit = 1;
> > if (dvbnet->dvbdev->users < 1) /* line A */
> > wait_event(dvbnet->dvbdev->wait_queue, /* line B */
> > dvbnet->dvbdev->users==1);
> > /* line C */
> > dvb_unregister_device(dvbnet->dvbdev);
> > [...]
> > }
> >
> > Isn't there a race condition here? What if there are no users of the
> > device at the time line A runs, but the device is opened before line C
> > runs? After the wait_
Re: Linux 2.6.21
On 4/27/07, Adrian Bunk <[EMAIL PROTECTED]> wrote: On Fri, Apr 27, 2007 at 12:31:43PM -0400, Theodore Tso wrote: > On Fri, Apr 27, 2007 at 04:58:05PM +0200, Adrian Bunk wrote: > > "no regressions" is definitely not feasible. > > > > 14 known regressions, some of them not yet debugged at all, are > > different from your "some small regression". > > Yes, but when were some of these regressions reported? Past a certain > point, I think it's reasonable to look at the regression, decide how > many people would be affected by it, and why it hadn't been noticed > earlier, and in some cases, decide that it's better to get this > debugged and fixed in the stable and development trees in parallel. 8 of them have been reported in March or earlier. [1] Patches for 2 of these 8 were available at the time of the release. [2] While the question whether to merge one of them into 2.6.21 was controversial, the other one was not controversial. I can imagine that the dvb oops bugfix got held back to avoid some noise with dvb developers who claimed that they didn't get notified about how that patch got into the v4l-dvb repository (it didn't get reviewed by these people for weeks because it simply got ignored and some of them were aware of that) On the other side if I read bugreports like the following one: http://www.mail-archive.com/linux-dvb%40linuxtv.org/msg23028.html (My Nova-T 500 crashes quite regularly. My machine has been running for about a week and in that time has had 5 oopses.) It doesn't solve the Nova-T disconnects, but it at least solves that the machine doesn't go down when this happens till the driver gets fixed. I think it would have been nice to get that patch into it Markus For one of the bugs, it became obvious when someone looked at it after the release of 2.6.21 that between the bug report on March 31th and the release of 2.6.21 on April 21th, noone started debugging this bug. [3] [4] > > And look e.g. at the many (and non-trivial) changes between -rc7 and > > -final, resulting in more than one report from people who were running > > -rc7 without problems - and 2.6.21 doesn't work for them. > > I agree that's unfortunate. > > > It's not a choice between "regressions don't matter" and "no regressions", > > it's about the place in the area between these two extremes. I have my > > opinions on what I want to expect from a stable Linux kernel, and other > > people have different opinins. > > Everyone is going to disagree to some extent; and their own comfort > zone. So a certain amount compromise is always going to be necessary. > Of course, it's up to you decide whether this has gone beyond the zone > where you aren't comfortable working with other people's development > style. > > Regards, > >- Ted cu Adrian [1] http://lkml.org/lkml/2007/4/26/2 [2] http://lkml.org/lkml/2007/4/25/496 [3] http://lkml.org/lkml/2007/4/26/496 [4] and although it turned out this specific regression was already fixed in 2.6.21, I hope you get my point -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed - 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/ -- Markus Rechberger - 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 2.6.21
On 4/29/07, Linus Torvalds <[EMAIL PROTECTED]> wrote: On Sat, 28 Apr 2007, Adrian Bunk wrote: > > We are already quite good at ignoring bug reports that come through > linux-kernel, and it's an _advantage_ of the kernel Bugzilla to see more > than 1600 open bugs because this tells how bad we are at handling bugs. No, it just shows that bugzilla doesn't matter for most of the kernel. Don't say that "bugzilla tells how bad we are at handling bugs". It tells how bad *bugzilla* is for handling bugs, nothing more. I totally disagree here, bugzilla is a very good tool. If someone is too lazy to look at it it's his problem. Kernel Janitors can pick out some bugs which aren't addressed by anyone or got left behind. I also found some bugs there which could have been solved by anyone here, the matter is just that many people aren't interested in mainly bug fixing and many also work on different other topics here. How else should bugs get handled, sending them to the lkml? I'm 100% sure some bugreports will also get lost then, but on the lkml they'll very likely remain lost whereas in the bugzilla they'll remain as open. Trying to play politics by pointing to bugzilla is pointless. Bugzilla is used for a few subsystems (ACPI seems to use it actively, for example), but I doubt most developers use it. as for the em28xx I actively use it, but I also set up a mailinglist etc. and there are many supporters already... Would be be good to have a better bug-tracking setup? Yes. But I think it takes man-power, and it would take something *fundamentally* better than bugzilla. what are your suggestions to improve a bugreporting tool, I'm very sure that many people, especially people who want to get into existing projects here, would love to contribute. Maybe the new "http://kernelnewbies.org/known_regressions"; thing will evolve to something worth tracking. Right now, bugzilla isn't it (although it can be a useful tracking place for individual bugs, *once* you've found and gotten the right developer involved - but that's a huge step that bugzilla generally does *not* do for us). I'd say this is a personal opinion, some people will get along with it and some of them will not... 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/
Re: Linux 2.6.21
On 4/29/07, Linus Torvalds <[EMAIL PROTECTED]> wrote: On Sun, 29 Apr 2007, Markus Rechberger wrote: > > I totally disagree here, bugzilla is a very good tool. If someone is > too lazy to look at it it's his problem. You must be doing things very differently from a lot of other people if you think that's the case. Well I'm behind the stuff I'm doing because I'm interested in it. And if some bugs are introduced by my work or derived by my work I'd like to get them cleaned up in the end. If I see that someone reports bugs which doesn't really address my work at all I just forward them to the subsystem/maintainer who's "in charge" (if someone can say it that way for an open source project) > Kernel Janitors can pick out some bugs which aren't addressed by > anyone or got left behind. IF that happened, it would actually be great. That's what I'm arguing for. And it was basically what Adrian was doing! I'm very sure that happens maybe it's just not visible to everyone because there are so many open issues. (I just take myself as an example here, I didn't do too much with other bugs but at least some of my work closed 5 other bugs this year beside the bugreports I'm getting directly) > How else should bugs get handled, sending them to the lkml? Actually, looking at Adrian's regression lists, yes. lkml worked better than bugzilla did. By at _least_ a factor of two. Yes Adrian did a very good job with collecting every bugreport and sending the mails to all corresponding subsystems. > I'm 100% sure some bugreports will also get lost then, but on the lkml > they'll very likely remain lost whereas in the bugzilla they'll remain > as open. What's the difference between bugzilla and lkml.org? Both have search buttons. Both archive the old stuff. Both can be pointed to. Both have search buttons yes, but the lkml doesn't leave an unread mail open ontop of the lkml as bugzilla does if you look for open bugs in a subsystem. > what are your suggestions to improve a bugreporting tool, I'm very > sure that many people, especially people who want to get into existing > projects here, would love to contribute. I don't know what the perfect setup is, but I do know that bugzilla is very close to be totally useless for the top-level maintainers. Try to think like a person who doesn't maintain *one* specific file in the kernel, but who can actually make a good judgement about a lot of things, or at least funnel a problem report to the right person? And now, imagine that that person is also fairly busy (exactly *because* he's not looking at a single file, he may be maintaining a huge subsystem that has multiple submaintainers etc). And ask yourself whether bugzilla really helps. bugzilla keeps the bugs open at least, at the lkml I use to skip days sometimes. Many people who consider themself as maintainer of a subsystem are assigned to a subsection on bugzilla, if it really doesn't work out we have to change the corresponding maintainer. If that maintainer doesn't know where to go with that bugreport he can easily send it to the lkml and some people will recognize the sender/email and pay extra attention to it (that's just how I think about it) > I'd say this is a personal opinion, some people will get along with it > and some of them will not... I think bugzilla really only works for very "directed" issues. If you already know exactly which driver is affected (which is often wrong anyway: some of the bugs that were due timer breakage got blamed as disk hangs!) it's almost totally useless. And yes, maybe that's why you have a much higher opinion of bugzilla than I do. To _me_ bugzilla is a total mess. There's absolutely _zero_ useful information there. And I'm pretty certain that is true of a *lot* of other people too. But if you have a small project, or you maintain a very specific (and clearly delineated) part of a big project, bugzilla probably looks a lot more palatable. well are there any bugs that cannot be forwarded/directed to a corresponding maintainer? Maybe I don't see something here, can you point me out to a bugreport which cannot be handled at all? As a reference I'll take following bugreport: http://thread.gmane.org/gmane.linux.kernel/521185 the bug doesn't even mention what device is affected, asking for further detailed information (dmesg) shows up what's left at least.. (in the meanwhile the bug even got solved) 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/
Re: Linux 2.6.21
On 4/29/07, Bob Tracy <[EMAIL PROTECTED]> wrote: Linus Torvalds wrote: > On Sun, 29 Apr 2007, Markus Rechberger wrote: > > How else should bugs get handled, sending them to the lkml? > > Actually, looking at Adrian's regression lists, yes. lkml worked better > than bugzilla did. By at _least_ a factor of two. Since 1992, lkml (with "Cc:" to the appropriate subsystem mailing list if applicable) and the presumed responsible parties are the only channels I've used to report the bugs I encounter. since there are subsystems out there which are managed separatly this doesn't work out. I wasn't happy when I noticed that patches got applied to the sourcecode I contributed without notifying me while I still worked on that code separatly It was moreover the fault of the subsystem maintainer to not notify me back then but a centralized bugreporting (as bugzilla) tool would at least have notified me, or I would have been able to see the suggested changes there. But I agree with that if you're only 1 level far away from the linux kernel. Other methods come and go, but old habits die hard, particularly when they have a knack for producing the desired result. Historically, requiring a developer to fire up a GUI to read a bug report decreases the chance that bug report will be noticed. The development community can do whatever flips its collective switch as far as tracking bugs, but the bugs have to be reported and noticed before tracking becomes a meaningful activity. One more thought and I'll get off your screens... We've steadfastly resisted making lkml and friends subscriber-only mailing lists precisely because we don't want to miss a potential bug report because a would-be submitter isn't subscribed. If people aren't looking for bug reports here, what's the point? it's just easy to miss something here, if an ext3 bug comes in and all people who're involved in the ext3 filesytem are on vacation I'm sure they won't read all the mails which came in during a week, now take a part of the kernel which is smaller than the ext3 filesystem (eg. usb gadgets, smaller drivers) 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/
Re: [linux-dvb] Re: Critical points about kernel 2.6.21 and pseudo-authorities
On 4/30/07, Uwe Bugla <[EMAIL PROTECTED]> wrote: Original-Nachricht Datum: Mon, 30 Apr 2007 02:58:33 +0200 Von: hermann pitton <[EMAIL PROTECTED]> An: Uwe Bugla <[EMAIL PROTECTED]> CC: Linus Torvalds <[EMAIL PROTECTED]>, [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], linux-kernel@vger.kernel.org Betreff: Re: [linux-dvb] Re: Critical points about kernel 2.6.21 and pseudo-authorities > Am Montag, den 30.04.2007, 01:00 +0200 schrieb Uwe Bugla: > > Original-Nachricht > > Datum: Sun, 29 Apr 2007 14:19:22 -0700 (PDT) > > Von: Linus Torvalds <[EMAIL PROTECTED]> > > An: Uwe Bugla <[EMAIL PROTECTED]> > > CC: [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], > linux-kernel@vger.kernel.org, [EMAIL PROTECTED] > > Betreff: Re: Critical points about kernel 2.6.21 and pseudo-authorities > > > > > > > > > > > On Sun, 29 Apr 2007, Uwe Bugla wrote: > > > > > > > > I have been trying diff and other tools in various variants (except > > > > git-bisect that I cannot handle because I do not understand the > practice > > > > of it). > > > > > > git bisect is _really_ simple if you already have a git tree anyway. > And > > > even if you don't, getting one isn't really hard either. Just do > > > > > > git clone > > > git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git > linux-2.6 > > > > > > and you have a tree (it will take a little while - it's going to > dowload > > > about 170MB or so of stuff, so the initial clone is going to be a bit > > > painful unless you have a fast internet connection). > > > > > > Once you have the git tree, assuming that 2.6.21-rc7 worked for you, > it's > > > really as easy as just saying > > > > > > git bisect start > > > git bisect good v2.6.21-rc7 > > > git bisect bad v2.6.21 > > > > > > and git will think for a short while (most of the time is going to be > > > checking out the new tree) and give you a tree to test. > > > > > > Just build, boot, and test that tree. > > > > > > If it was fine, do > > > > > > git bisect good > > > > > > and git will pick a new tree to test. And if it wasn't, instead just > do > > > "git bisect bad", and git will pick _another_ version to test. Do this > a > > > few times, and git will tell you which commit introduced them. > > > > > > There were just 125 commits in between 2.6.21-rc7 and the final one, > so it > > > should be quite quick - bisection basically does a binary search, so > doing > > > seven reboots should have you with the result. > > > > > > The fact that it already works in 2.6.21-git2 obviously means that _I_ > end > > > up being less interested, but the -stable tree people would love to > hear > > > what broke! > > > > Hi again Linus, > > my deep thanks for your excellent explication of git-bisect. > > But I unfortunately owe a 100Kbit flatrate, and so downloading some 170 > MB git tree will need the time amount of one entire night (11.5 kb /s if I > am lucky - no more). > > Just to take up a different approach: > > > > The difference between 2.6.21-rc7 and 2.6.21 official does not play any > role at all. > > > > On the other hand I found out that: > > 2.6.21-rc7 made my AMD K7 router work fine > > 2.6.21 official hung my AMD K7 router up > > 2.6.21-git1 hung my AMD K7 router up > > 2.6.21-git2 made my AMD K7 router work. > > > > In so far the diff between 2.6.21-git1 and 2.6.21-git2 obviously solves > the problem. > > Or am I saying something wrong as far as logical terms are concerned? > > > > > > > > > I like small and effective kernels instead of blown up RAM waste. > > > > This is no Windoze, man, this is Linux! > > > > > > Yes. But if you cannot be polite and *RESPECTFUL*, you won't get > anywhere > > > at all. > > > > > > This is Linux, not Windows. But that also means that those developers > that > > > you denigrate aren't getting paid by you, and if you don't show them > > > respect, they'll totally ignore you. > > > > > > Linus > > > > Now this is the old problem about it all: the hypocricy factor, the > utmost small, if not to say pre-pubertarian character plus some other obviously > counter-productive character traits in those so-called "maintainers" who > behave like kids, but not like grown-ups at all! > > Not only you, but also Andrew perfectly and willingly step into the > hypocritic trap and do not even feel that they are trapped! > > > > For the majority of all cases of the so-called "maintainer personnel" at > linuxtv.org the statement of some missing "politeness" or some missing > "respect" is nothing but an utmost dumb, kiddish, human mediocre and utmost > stupid and utmost hypocritic excuse for bare naked incompatibility, dumbness, > wrong solidarity, kiddishness and technical incompetence. > > > > They are building up pseudo-authorities to hide their lack of > competence, no matter if their lack of competence funds on technical or human lacks. > > And at least the Brazilian Mauro Carvalho Chehab does go even so far to > soap in Andrew
Re: [linux-dvb] Re: Critical points about kernel 2.6.21 and pseudo-authorities
On 4/30/07, Uwe Bugla <[EMAIL PROTECTED]> wrote: Original-Nachricht Datum: Mon, 30 Apr 2007 13:48:34 +0200 Von: "Markus Rechberger" <[EMAIL PROTECTED]> An: "Uwe Bugla" <[EMAIL PROTECTED]> CC: "hermann pitton" <[EMAIL PROTECTED]>, [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], linux-kernel@vger.kernel.org Betreff: Re: [linux-dvb] Re: Critical points about kernel 2.6.21 and pseudo-authorities > On 4/30/07, Uwe Bugla <[EMAIL PROTECTED]> wrote: > > > > Original-Nachricht > > Datum: Mon, 30 Apr 2007 02:58:33 +0200 > > Von: hermann pitton <[EMAIL PROTECTED]> > > An: Uwe Bugla <[EMAIL PROTECTED]> > > CC: Linus Torvalds <[EMAIL PROTECTED]>, [EMAIL PROTECTED], > > [EMAIL PROTECTED], [EMAIL PROTECTED], > > linux-kernel@vger.kernel.org > > Betreff: Re: [linux-dvb] Re: Critical points about kernel 2.6.21 > > and pseudo-authorities > > > > > Am Montag, den 30.04.2007, 01:00 +0200 schrieb Uwe Bugla: > > > > Original-Nachricht > > > > Datum: Sun, 29 Apr 2007 14:19:22 -0700 (PDT) > > > > Von: Linus Torvalds <[EMAIL PROTECTED]> > > > > An: Uwe Bugla <[EMAIL PROTECTED]> > > > > CC: [EMAIL PROTECTED], [EMAIL PROTECTED], > [EMAIL PROTECTED], > > > linux-kernel@vger.kernel.org, [EMAIL PROTECTED] > > > > Betreff: Re: Critical points about kernel 2.6.21 and > pseudo-authorities > > > > > > > > > > > > > > > > > > > On Sun, 29 Apr 2007, Uwe Bugla wrote: > > > > > > > > > > > > I have been trying diff and other tools in various variants > (except > > > > > > git-bisect that I cannot handle because I do not understand the > > > practice > > > > > > of it). > > > > > > > > > > git bisect is _really_ simple if you already have a git tree > anyway. > > > And > > > > > even if you don't, getting one isn't really hard either. Just do > > > > > > > > > >git clone > > > > > > git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git > > > linux-2.6 > > > > > > > > > > and you have a tree (it will take a little while - it's going to > > > dowload > > > > > about 170MB or so of stuff, so the initial clone is going to be a > bit > > > > > painful unless you have a fast internet connection). > > > > > > > > > > Once you have the git tree, assuming that 2.6.21-rc7 worked for > you, > > > it's > > > > > really as easy as just saying > > > > > > > > > >git bisect start > > > > >git bisect good v2.6.21-rc7 > > > > >git bisect bad v2.6.21 > > > > > > > > > > and git will think for a short while (most of the time is going to > be > > > > > checking out the new tree) and give you a tree to test. > > > > > > > > > > Just build, boot, and test that tree. > > > > > > > > > > If it was fine, do > > > > > > > > > >git bisect good > > > > > > > > > > and git will pick a new tree to test. And if it wasn't, instead > just > > > do > > > > > "git bisect bad", and git will pick _another_ version to test. Do > this > > > a > > > > > few times, and git will tell you which commit introduced them. > > > > > > > > > > There were just 125 commits in between 2.6.21-rc7 and the final > one, > > > so it > > > > > should be quite quick - bisection basically does a binary search, > so > > > doing > > > > > seven reboots should have you with the result. > > > > > > > > > > The fact that it already works in 2.6.21-git2 obviously means that > _I_ > > > end > > > > > up being less interested, but the -stable tree people would love > to > > > hear > > > > > what broke! > > > > > > > > Hi again Linus, > > > > my deep thanks for your excellent explication of git-bisect. > > > > But I unfortunately owe a 100Kbit flatrate, and so downloading some > 170 > > > MB git tree will need the time amount of one entire night (11.5 kb /s > if I > > > am lucky - no more). >
Re: [linux-dvb] Re: Critical points about kernel 2.6.21 and pseudo-authorities
all these discussions are about Makefile and documentation changes as far as I see. I don't see the point why there's a need for such a big discussion here just about these changes. Uwe please resend your patch files and lets get this story done, if your work breaks something we can point you out to what is wrong. We have what's in the repository now and it won't change unless we put some time in it again. Uwe, if you have a problem with anyone here keep it for yourself just submit the latest patches and I'll have a look asap at it. There's no need to be unfriendly here. Markus On 4/30/07, Helge Hafting <[EMAIL PROTECTED]> wrote: Uwe Bugla wrote: > Original-Nachricht > Datum: Mon, 30 Apr 2007 13:21:29 +0200 > Von: Helge Hafting <[EMAIL PROTECTED]> > An: Uwe Bugla <[EMAIL PROTECTED]> > CC: linux-kernel@vger.kernel.org > Betreff: Re: [linux-dvb] Re: Critical points about kernel 2.6.21 and pseudo-authorities > > >> Uwe Bugla wrote: >> >>> In this ten Emails you will yourself see the intellectual and technical >>> >> proof in how far Mr. Chehab is acting with nothing else but: >> >>> a. Lies >>> b. Unproven thesis >>> c. Stigmatizations >>> >>> and so on. >>> >>> THIS MAN HAS NO IDEA, BUT HE HAS THE POWER! >>> >>> >> Please note that there are ways to replace a bad maintainer. >> We still try to keep it polite. >> >> But note that you can't have someone "fired", no matter how bad they >> do their job. A bad maintainer is usually better than none - the bad >> maintainer might improve. Or at least get some simple stuff done. >> >> You therefore replace a bad maintainer by taking over the position. >> Contact whoever is above the maintainer (Linus or some other >> higher-level maintainer). You explain the problem, and you must also >> show that you have the time and knowledge to do a better job. >> > > Hi Helge, > A. I do neither have enough skills to take up a maintainers role > Then your only hope is to find someone else that is interested. > B. Linus and Andrew are high-leveled informed about the whole structural problem, but they close their eyes, they simply do not want to see the necessity of a replacement. > That is at least my impression. > The aren't doing any less than you do. They don't provide a better maintainer, but neither do you. Linus and Andrew don't have that much more resources than you have. They have programming skills and lots of trust in the community. >> You can, for example, maintain the same subsystem in parallel. After a >> while, >> all interested parties sees that your tree works better and that >> communicating with you is easier. >> If you aren't prepared to do this - then you have to live with the current >> maintainer. There is no staff ready to replace maintainers after >> complaints, a volunteer doing a better job is always necessary. >> > > Neither nor: I do not livbe with persons like Chehab and others, no matter what the consequence is. To be truthful I would strategically prefare a vacuum at the price that the work isn't even done for months. > ONLY IF there is a personnel vacuum the necessity for others to volunteer will arise. > A sufficiently bad maintainer will also do it. If lots of submitters send their patches to andrew in order to get past a dysfunctional maintainer, then the subsystem effectively is unmaintained. > So if you want a real change you gotta first kick the reactionary dumb bastards off from their seats without any return ticket - without that there won't be any changes at all! > Well then - create a patch to the MAINTAINERS file that removes this maintainer leaving the position open. Perhaps you can get that accepted despite the existing maintainer - *if* you can get most other developers for that subsystem to add signed-off lines. It will then be clear that the community agrees with you. However, if the bulk of them thinks the current maintainer is fine, then it stays that way. Satisfying everybody is unfortunately not always possible. You can always try submitting your own patches above this maintainer. > But the practice now is the typical "Sit out and do not react at all" behaviour as far as Chehab himself is concerned - Germans remember that reactionary gesture from the time when Hellmut Kohl was chancellor for 16 horrible years. > > So there will be no "soft" or "polite" solution at all, but only a harsh and rude one: > "Kick out the Jams!" Dropping lazy or incompetent maintainers do happen occationally. But don't let frustration lead to angry emails - al
Re: [linux-dvb] Re: Critical points about kernel 2.6.21 and pseudo-authorities
On 4/30/07, Jan Engelhardt <[EMAIL PROTECTED]> wrote: On Apr 30 2007 19:25, Uwe Bugla wrote: >THIS PATCH IS DONE TO AVOID RAM WASTE FOR CASES IN WHICH IT IS PROVEN THAT DST >AND DST_CA ARE NOT NEEDED AT ALL >[...] How much on the Theo-meter are we yet? it's enough, I told him that I'll look at it and try to get some other people involved if it really breaks something it should get stated out; and I'll refuse any further help if he starts to write any more abusive mail. So to his proposal: the whole noise is about following Makefile patch: -obj-$(CONFIG_DVB_BT8XX) += bt878.o dvb-bt8xx.o dst.o dst_ca.o +obj-$(CONFIG_DVB_BT8XX) += bt878.o dvb-bt8xx.o +obj-$(CONFIG_DVB_DST) += dst.o +obj-$(CONFIG_DVB_DST_CA) += dst_ca.o that symbol_request is unable to return a valid pointer if DST an DST_CA aren't selected should be ok because this would only happen if someone didn't compile them in (an appropriate error message should be added for that) I'm trying to look closer at this issue with some other developers, if it's really that easy to split off the dst module from the bt* objects without breaking anything, to me the direction this patch goes seems to be ok, some people stated out that there are problems so I'll try to get more information about that. 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/
DST/BT878 module customization (.. was: Critical points about ...)
Hi, Trent Piepho wrote another patch for it, it just completes Uwe's patch in the end. http://linuxtv.org/hg/~tap/dst-new?cmd=changeset;node=bbdd2b53cd5c;style=gitweb as far as I see from that patch it cleans up a memory leak which would happen when the system tries to load the dst module if it's not available and it also prints a message that points the user should enable it in the kernel if needed. It also bundles the dst and dst_ca objects to one selectable option. So the idea remains the same. 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. Markus On 4/30/07, Markus Rechberger <[EMAIL PROTECTED]> wrote: On 4/30/07, Jan Engelhardt <[EMAIL PROTECTED]> wrote: > > On Apr 30 2007 19:25, Uwe Bugla wrote: > > >THIS PATCH IS DONE TO AVOID RAM WASTE FOR CASES IN WHICH IT IS PROVEN THAT > DST > >AND DST_CA ARE NOT NEEDED AT ALL > >[...] > > > How much on the Theo-meter are we yet? > it's enough, I told him that I'll look at it and try to get some other people involved if it really breaks something it should get stated out; and I'll refuse any further help if he starts to write any more abusive mail. So to his proposal: the whole noise is about following Makefile patch: -obj-$(CONFIG_DVB_BT8XX) += bt878.o dvb-bt8xx.o dst.o dst_ca.o +obj-$(CONFIG_DVB_BT8XX) += bt878.o dvb-bt8xx.o +obj-$(CONFIG_DVB_DST) += dst.o +obj-$(CONFIG_DVB_DST_CA) += dst_ca.o that symbol_request is unable to return a valid pointer if DST an DST_CA aren't selected should be ok because this would only happen if someone didn't compile them in (an appropriate error message should be added for that) I'm trying to look closer at this issue with some other developers, if it's really that easy to split off the dst module from the bt* objects without breaking anything, to me the direction this patch goes seems to be ok, some people stated out that there are problems so I'll try to get more information about that. Markus -- Markus Rechberger - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-dvb] Re: Critical points about kernel 2.6.21 and pseudo-authorities
On 5/1/07, Manu Abraham <[EMAIL PROTECTED]> wrote: 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 ? Please show me where this change makes your work more difficult, Trent's change is small and I don't see the problem where it seriously affects your work. 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/
Re: [linux-dvb] Re: Critical points about kernel 2.6.21 and pseudo-authorities
cs DigiTV, TwinHan DST and clones, Avermedia of all kinds. Is that list complete? If not, please drop me a note where I can get that complete list of cards corresponding to that standard, and I'll instantly sit down and write a patch to improve documentation. But before I even think about doing that I appreciate you to do your homework: a. readd my name (I didn't delete it, so I won't do the same job again, not for sync reasons, and not for reasons of lack of time, and not for any other reason. b. fix orthographic errors in dvb-bt8xx.txt (for the same reason mentioned in point a.) c. reconstruct my 2.6.13-structure of dvb-bt8xx.txt as far as possible d. reflect very well, whether debug parameters should not better be situated in different documentation texts (logically structured, understandable) Regards Uwe Bugla P. S.: akpm never complains about lack of time, and he is doing a very fair and good job, and, at least for him, the amount of 54 patches is simply peanuts. I love cooperation with guys like him! In other words: I respect the demand that cvs-tree and current kernel must be in sync somehow, but if the output is rubbish for several reasons and, moreover, neglects my work, there is simply no reason for any kind of respect. Because I ain't no idiot, just to say it in very simple words. So please in future avoid to blame my person for things that you personally don't get worked (synchronization or whatever kind). And would you please answer me one question: How can I be shure that my patchwork at least enters the institution akpm, if there is someone like you in between complaining for lack of time and synchronization faults? I prefer flat hierarchies (the real hidden success principle of Linux) and cooperation with akpm works very fine. So, as a matter of principle, I don't see any reason why I should prepare and send in my work three, four, five times, just because at the other end someone doesn't get his stuff synchronized or lacks time. I ain't no idiot! Ya Basta! And even if I would give in now for strategic reasons and do the same fuckin' work again, how many Stezenbach clones or whoever would come up afterwards and continue to fuck up my work in the same or just in a different way you personally did? Who do you think you are and who do you think I am? So please do your homework, and do it correct in the future, or leave that job simply to another person. OK? Any further questions, Mr. Johannes Stezenbach? -- Lust, ein paar Euro nebenbei zu verdienen? Ohne Kosten, ohne Risiko! Satte Provisionen für GMX Partner: http://www.gmx.net/de/go/partner ___ linux-dvb mailing list [EMAIL PROTECTED] http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb -- Markus Rechberger - 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 ...)
On 5/1/07, Simon Arlott <[EMAIL PROTECTED]> wrote: On 30/04/07 22:17, Markus Rechberger wrote: > Trent Piepho wrote another patch for it, it just completes Uwe's patch > in the end. > 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: On 01/05/07 00:05, Uwe Bugla wrote: > Piepho, you are a devil, and your links do not work at all! > Uwe On 01/05/07 00:40, Uwe Bugla wrote: > Go to hell, Manuel Abraham, and do not return at all to absolutely no thinkable condition at all, and never come back to this place once more again > Just goto hell, you goddamn deeply asocial miserable sonofabitch!! > > Uwe > On 4/30/07, Markus Rechberger <[EMAIL PROTECTED]> wrote: >> it's enough, I told him that I'll look at it and try to get some other >> people involved if it really breaks something it should get stated >> out; and I'll refuse any further help if he starts to write any more >> abusive mail. It's not working. Patches should still be applied on the basis of what they do and how, not why they were made, of course. this patch was written by Trent, and it seems like he already had that idea earlier too. I really don't care if that patch goes in or not in the end, there's just no need to flame around for it. The only reason I see is that it's not needed to link it statically against the bt878 module and there isn't even much work to do. Uwe's Makefile patch worked as expected, but it wasn't clean/complete enough that was a reason to not include it. Now with Trent's patch I don't see that as a valid argument against it anymore. And the email from Manu claiming that it generates alot work (which is btw. 2 years old) doesn't seem to be valid either. 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/
Re: [linux-dvb] DST/BT878 module customization (.. was: Critical points about ...)
On 5/2/07, Manu Abraham <[EMAIL PROTECTED]> wrote: 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: Criticalpoints 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 behind this, please, I'd deeply appre
Re: [PATCH] pcmcia/pccard deadlock fix
Andrew Morton wrote:
On Tue, 20 Feb 2007 16:08:11 +0100
20 Feb was a long time ago, sorry. I was hoping to feed the pcmcia patches
through Dominik but I think he's busy with exams or such. So I get to
pretend to be pcmcia maintainer.
"Markus Rechberger" <[EMAIL PROTECTED]> wrote:
following patch prevents a mutex/semaphore deadlock within the pcmcia
framework when ejecting devices multiple times using pccardctl eject.
For some more details see:
http://lkml.org/lkml/2007/2/19/58
Signed-off-by: Markus Rechberger <[EMAIL PROTECTED]>
--
Markus Rechberger
Operating System Research Center
AMD Saxony LLC & Co. KG
[pcmcia-pccard-deadlock-fix.diff text/plain (757B)]
index ac00424..c02bf0d 100644
--- a/drivers/pcmcia/cs.c
+++ b/drivers/pcmcia/cs.c
@@ -856,7 +856,8 @@ int pcmcia_eject_card(struct pcmcia_socket *skt)
cs_dbg(skt, 1, "user eject request\n");
- mutex_lock(&skt->skt_mutex);
+ if (!mutex_trylock(&skt->skt_mutex))
+ return -EAGAIN;
do {
if (!(skt->state & SOCKET_PRESENT)) {
ret = -ENODEV;
index 18e111e..b9d3440 100644
--- a/drivers/pcmcia/ds.c
+++ b/drivers/pcmcia/ds.c
@@ -1100,7 +1100,9 @@ static ssize_t pcmcia_store_allow_func_id_match(struct
device *dev,
if (!count)
return -EINVAL;
- mutex_lock(&p_dev->socket->skt_mutex);
+ if (!mutex_trylock(&p_dev->socket->skt_mutex))
+ return -EAGAIN;
+
p_dev->allow_func_id_match = 1;
mutex_unlock(&p_dev->socket->skt_mutex);
This is a pretty sad-looking solution. Does it not mean that sometimes
user-initiated actions will mysteriously fail?
The userspace application should return the appropriate error then. It
can really happen any time when someone tries to eject the pcmcia device
(any time as within 1 minute - never in a normal scenario)
Are you able to provide a more detailed description of why/how the deadlock
actually occurs so that perhaps a more robust fix can be implemented?
There's a description about it in following Email:
http://lkml.org/lkml/2007/2/19/58
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/
Re: [linux-dvb] DST/BT878 module customization (.. was: Critical points about ...)
On 5/3/07, Manu Abraham <[EMAIL PROTECTED]> wrote: 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. Manu, to me it looks like your attitude is not acceptable here, I sent several mails already which you just use to ignore. 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. 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 -- Markus Rechberger - 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 ...)
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/
Re: [linux-dvb] DST/BT878 module customization (.. was: Critical points about ...)
On 5/3/07, VDR User <[EMAIL PROTECTED]> wrote: STOP FIGHTING ALL THE DAMN TIME! From an outsiders perspective there is a lot of unnecessary & childish behavior going on at the expense of good ideas and coding. It seems as though the Markus/Mauro team will go against anything Manu says simply because Manu is the one saying it. From what I've seen he is very knowledgeable and a good coder. From his technical knowledge he's as ok as many other developers are who have been involved for several years now. He tries to become the DVB Maintainer, from my side I wrote he first has to prove it for at least a half year that he supports the project and helps out people. Till now I haven't seen any response to the technical questions I had. And telling that the politicians here are so bad to everyone who'd like to help finding a solution for it is definitelly the wrong way either, so other people will not even be able to get an insight into the whole story. Manu is an asset and all the personal bickering and immature attitudes being displayed do not benefit any projects in any way. If you can't get past your personal problems then step down until you can learn to be unbiased and start treating these projects with some sanity/common sense. When you drive good people away, guess who loses? EVERYONE. Grow up and quit letting your personal feelings interfere in places it should not be in the first place!! Since all these issues have been there for more than one year now it either would be better that he leaves the project OR starts to seriously discuss the issues and how it would be best to solve them (and in a way where everyone agrees here) He just nacks the changes proposed by Uwe which got implemented by Trent and now Mauro wants to get it done somehow, either in a way explaining what he wants to do with it in future or changing these few lines NOW. I couldn't care less what will happen with his driver, the whole story gets blown up just because one party here doesn't understand that the other one doesn't know what he wants to do (and if he seriously will do something) I apologize for going off-topic but this is relevant to dvb dev as a whole. Things have degraded to a ridiculous state and it's time to knock it off. Enough is enough. The dvb projects should NOT have to suffer simply because people have lost the decency to act civil towards one another! Lastly, the opinions I'm sharing in this post are held by many others, although they hesitate to do the same publicly for certain reasons. I fully agree with that. 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/
Re: [linux-dvb] DST/BT878 module customization (.. was: Critical points about ...)
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. You wouldn't be better at the moment, Mauro at least aknowlidges the work of others. I don't know what problems you have with Mauro I heard that there have been some mails between you and some other developers as well and the whole situation is just terrible. If you want to change the whole situation, think about what you can do for improving the whole situation even if it means that you have to work with people you don't like. (2) one shouldn't make such judgement calls on somebody else's driver unless it falls within your own maintainership I wrote what I'd like to see from you, it would be a start if you could work on that first. 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/
Re: [linux-dvb] [PATCH] Userspace tuner
Let's add the LKML to this. On 9/13/07, Markus Rechberger <[EMAIL PROTECTED]> wrote: > On 9/12/07, Mauro Carvalho Chehab <[EMAIL PROTECTED]> wrote: > > Markus, > > > > Em Ter, 2007-08-14 às 16:31 +0200, Markus Rechberger escreveu: > > > Following patch adds the possibility to implement tuner drivers in > > > userspace. > > > > As you asked me about userspace driver, at Linux Conf Europe, let me > > give you my feedback about it. > > > > On Linux, userspace-to-kernelspace APIs are meant to be forever. This > > means that, once a newer API is created, this should remain supported > > for all future versions. So, such APIs should be carefully analyzed and > > accepted by the community, before going to mainstream. > > > > The V4L and DVB API is stable at the moment because it's at a stage > which is sufficient for older devices but not sufficient for newer > devices anymore. > To support newer device it needs a change. > > > I don't see any technical reason why tuner drivers should be moved to > > userspace. Looking at xc3028 device, the driver is very simple and > > doesn't require any special treatment that it isn't possible to be done > > at kernel. There are already some implementations on kernelspace that > > works fine. > > > > As from my side to support the xceive driver properly it needs a > rewrite and a proper API description. Since it's not possible to > discuss any API changes I will work around at least for those devices > which I can support for. > > > On the other hand, a TV driver without a tuner is a broken driver. With > > parts of the driver being at userspace, this means to add undesired > > complexity at the drivers architecture, while not bringing any benefit. > > > > If you look at V4L history, the first drivers started at userspace, > > being migrated to kernelspace, where we have the proper scenario for > > managing those devices. > > > > Another aspect that should be analyzed is what is desired by the > > community: > > don't get me wrong but the existing community is rather small and > kicking off people who are interested in changing things. > I recently had a talk with someone and I've been told that I'm kicking > off people. > Guess why I kick off people? -> because they do not contribute in a > productive way which also means submitting patches. Optical useless > changes don't make any difference at the functionality in the end. And > my requirements are ignored constantly here. > > > kernelspace tuners or userspace tuners. Keeping support for > > both at long term doesn't seem reasonable. The Linux community should > > decide what is the better way. Currently, only you are pushing for > > userspace tuners, mainly due to non-technical reasons. > > read the project site and you will see the reasons. > http://mcentral.de/wiki/index.php/Userspace_tuner#Advantages > Another advantage is that I have cygwin based code here which I can > easily reuse with all that work I'm not going to reinvent the wheel > even for newer devices which I work on. > > > Almost all the > > other developers are comfortable with kernelspace tuners. So, creating > > an userspace interface just to make you happy is not the way we should > > go. > > > > I'm afraid of giving the people which are against what I submitted the > responsibility over the project. Initially there was an RFC which > didn't get commented either (well there was one useless comment, I > tried to discuss it on IRC before with the same guy) after I > implemented exactly what I proposed there I got the first non > technical comments - also keep in mind that working on something costs > alot of time and talking about something unknown is rather cheap. > > > A final aspect is that having an userspace driver for tuner will mean > > that the kernel driver will depend on an userspace counterpart in order > > to work. This will allow a vendor with bad intentions to release a > > partially broken userspace driver, with limited capabilities, and a > > closed source driver for full support. This model is likely to occur, if > > you take a look at the past. For example: ATI and Nvidia closed source > > drivers, several soft modem drivers, some network drivers, ... > > > > Please go forward and discuss the UIO driver with Greg Kroah Hartmann > and the fuse driver with the other people. If companies want to > release binary drivers they can easily use the existing code put it > into an RPM or DEB package and Ubuntu will pick it up. > > > With all
Re: [linux-dvb] [PATCH] Userspace tuner
Hi, On 9/13/07, Johannes Stezenbach <[EMAIL PROTECTED]> wrote: > On Thu, Sep 13, 2007, Markus Rechberger wrote: > > > > We currently have an implementation that works, although > > it works by downloading several firmwares for several devices > > or even several countries. This is not what I want to have in > > future since it's not needed and it's also hard to manage for > > distributors. All those differences could be adjusted by > > software even without module parameter hacks. > > This argument doesn't hold water. The unpleasant point > for users and distributors isn't the "binary-only" > thing, it's the "no right to distribute" problem. > And that's the same for firmware blobs or binary-only > userspace blobs. > > IOW, if you can get the right to redistribute a binary-only > userspace blob which incudes the firmware inside, why > shouldn't you be able to get the right to redistribute > just the firmware? > In particular xceive based drivers provide a numerous set of features which cannot be implemented into the kernel because the API (both V4L and DVB) are limited. Since to me it seriously has the impression that the project especially the core of the project is closed to the outside world (just how someone stated it out recently "he licked the butts of others" to get his stuff accepted) > Or the other way round: Do you think your binary-only software > will be important enough so distributors will go through > all the trouble of trying to get a license to include it in > their distribution? If so, why wouldn't they do the same > for the plain firmware blobs for in-kernel drivers? I don't have any binary only software just as all the time before. I am also allowed to publish firmware for several drivers (not only the em28xx driver). Although as mentioned earlier already the current existing driver is not really manageable due the firmware mess and that driver will change completly and include templates for several other bridge drivers. 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/
Re: [linux-dvb] [PATCH] Userspace tuner
On 9/13/07, Johannes Stezenbach <[EMAIL PROTECTED]> wrote: > On Thu, Sep 13, 2007, Markus Rechberger wrote: > > Let's add the LKML to this. > > > > On 9/13/07, Markus Rechberger <[EMAIL PROTECTED]> wrote: > > > On 9/12/07, Mauro Carvalho Chehab <[EMAIL PROTECTED]> wrote: > > > > I don't see any technical reason why tuner drivers should be moved to > > > > userspace. Looking at xc3028 device, the driver is very simple and > > > > doesn't require any special treatment that it isn't possible to be > done > > > > at kernel. There are already some implementations on kernelspace that > > > > works fine. > > > > > > As from my side to support the xceive driver properly it needs a > > > rewrite and a proper API description. Since it's not possible to > > > discuss any API changes > > Not possible? We're doing it all the time... > Then ask Mauro about the audio standard discussion which I had with him. > However, your ideas were rejected in this discussion, > and you can't seem to get over it. > As for future projects I see other people having the same problems if they want to join the project. If deeper requirements and/or ideas will come up some particular people will try to run their own game. If I'm doing something wrong technically then state it out show me the bugs that I can understand what I did wrong or what I am doing wrong. As for design changes if someone thinks he has to deny something he has to state out _why_ and not only some overall nontechnical statements which do not help anyone. > > > don't get me wrong but the existing community is rather small and > > > kicking off people who are interested in changing things. > > IMHO there is a lack of openness caused by people being burned > in past flamewars. This makes it a bit difficult to see through > what happens and why, and to participate. However, I think it > is completely wrong to say that the community is "kicking off people". > You identified it already the right way in one mail much earlier. It's a messup caused by many people and not only by one single person. And that's also how I see it. > > > I'm against how the project works out at the moment and how it worked > > > out in history. Exactly this way will kick off companies to be > > > interested in future like Avermedia. A driver can easily be written > > > within a few weeks and I've been struggling with it for 2 years(!!!) > > > now just for nothing finally telling me that some guys want to steal > > > my code and move it to kernelspace although it would raise more > > > complications with upcoming and current devices which have even more > > > requirements. > > Oh dear, there we go again... more flame bait... > > I reality, 95% of your driver code could have been merged > without problems, but you refused to take the small, objectionable > part out of the picture. > the driver itself still evolves, so the main point is in getting those incomplete APIs to support further requirements. Instead of acknowlidging and seriously discussing the solutions of others all that's beeing done now is to redo things hundred times and splitting development one side beeing more open (which is the userspace work) and the other part beeing more closed to a few people only (the inkernel work). It's not my task to convince myself to rewrite the base of something which I don't think that it would be valueable. The one who wants me that I spend days in changing my code should try to convince me to change my mind on that, unless he can provide patches which demonstrate that his changes are definitelly an advantage over what has been done from my side. I will for sure acknowlidge everything that will seriously improve the work which has been done. > (For those interested: > http://mcentral.de/~mrec/patches/v4l-dvb/hg_v4l-dvb-experimental_01.patch > The patch changed the internal tuner API and required changes > to all tuner drivers.) > The main problem is moreover that the RFC didn't get discussed properly, afterwards people wondered what happened, even though the sources were also available all the time in a public repository. > Your all-or-nothing approach didn't work out. > well we got far enough that I end up to step away and preparing the sources to be able to get submitted beside linuxtv since I don't/didn't get any useful technical feedback there. Convince me that my work is welcome then I might start to submit smaller patches, I already spent days for exporting patches in history and it all end up nowhere but in unfriendly discussions - which also turned
Re: [linux-dvb] [PATCH] Userspace tuner
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. > 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. > The analogue tuner core is also only for i2c only devices which most devices rely on. > Also there is to consider a non technical aspect, whether vendors will > misuse this interface for binary only, undermining the efforts put in > for OSS drivers. > What holds companies for using the current available code putting it into an rpm or deb package and releasing such code now? The Avermedia example I pointed out to is a good example already. As from my side I won't release binary drivers. Although on the other side: * are drivers from vendors which work through several kernel versions that bad? * Why did someone duallicense videodev2 with BSD/GPL? I would appreciate if someone else on the list could also comment the reason that drivers should all be included in the linuxkernel just because forcing the companies to release binary drivers because of that. My opinion about that is if a company wants to go opensource they will do so, if not they will either not release a driver or release nothing. 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/
Re: [linux-dvb] [PATCH] Userspace tuner
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 in the current usual cases and such calls could be handled behind a callback function which is implemented in the driver. 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/
Re: [linux-dvb] [PATCH] Userspace tuner
On 9/13/07, Steven Toth <[EMAIL PROTECTED]> wrote: > > > > >> Also there is to consider a non technical aspect, whether vendors will > >> misuse this interface for binary only, undermining the efforts put in > >> for OSS drivers. > >> > >> > > > > What holds companies for using the current available code putting it > > into an rpm or deb package and releasing such code now? > > > > The Avermedia example I pointed out to is a good example already. > > As from my side I won't release binary drivers. > > Although on the other side: > > * are drivers from vendors which work through several kernel versions > > that bad? > > * Why did someone duallicense videodev2 with BSD/GPL? > > > > I would appreciate if someone else on the list could also comment > > the reason that drivers should all be included in the linuxkernel just > > because forcing the companies to release binary drivers because > > of that. My opinion about that is if a company wants to go opensource > > they will do so, if not they will either not release a driver or release > > nothing. > > > > > > > I know for certain that adding a userland API tuner/demod interface to > the kernel, allowing non-caring opportunistic silicon or board vendors > to developer closed source proprietary drivers, will have a negative > effect on the community and we'd set back linuxtv 3-5 years. > > I know for certain that it would happen. Trust me. > > I've told you this countless times and you're not hearing me. > > Hauppauge have some leverage with Conexant and NXP to release public > datasheets. If they just have to release a demod.so (or similar) > loadable, they'll defer to the board vendors and we'll see the certain > board vendors 'locking other board vendors' out of their drivers. We'll > see embedded firmware, not shared between drivers. > > Except, it won't stop at demod.so. It will extend into unfixable bugs > for VendorB's board, because VendorA doesn't want to release a new > demod.so, and VendorB has no linux resources. What happens next? For > financial reasons - demod.so will begin to include checks to see if > specific PCI or USB devices are present in the system, and will fail to > work properly (if at all) when they're not being used with the preferred > products. > Steven, what stops vendors of using the current existing code to achieve that goal. They could provide binary drivers with the existing API. What stops companies to intercept the ioctl calls and overriding some I2C commands? Since you know about windows drivers (at least I think that you know about it) you might know about the limitations of the v4l/dvb API in general the reason just put as much code as possible into the kernel just for forcing companies to release code under GPL doesn't seem to be valid. How about proprietary video formats, would you also place the decoding algorithms in kernel just to force companies to release their code for it? What do you think about the existing usbfs implementation, which allows to implement usb drivers completly in userspace? What do you think about IOMMU? please answer those questions. thanks, 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/
Re: [linux-dvb] [PATCH] Userspace tuner
On 9/14/07, Steven Toth <[EMAIL PROTECTED]> wrote: > Markus Rechberger wrote: > > On 9/13/07, Steven Toth <[EMAIL PROTECTED]> wrote: > > > >>>> Also there is to consider a non technical aspect, whether vendors will > >>>> misuse this interface for binary only, undermining the efforts put in > >>>> for OSS drivers. > >>>> > >>>> > >>>> > >>> What holds companies for using the current available code putting it > >>> into an rpm or deb package and releasing such code now? > >>> > >>> The Avermedia example I pointed out to is a good example already. > >>> As from my side I won't release binary drivers. > >>> Although on the other side: > >>> * are drivers from vendors which work through several kernel versions > >>> that bad? > >>> * Why did someone duallicense videodev2 with BSD/GPL? > >>> > >>> I would appreciate if someone else on the list could also comment > >>> the reason that drivers should all be included in the linuxkernel just > >>> because forcing the companies to release binary drivers because > >>> of that. My opinion about that is if a company wants to go opensource > >>> they will do so, if not they will either not release a driver or release > >>> nothing. > >>> > >>> > >>> > >> I know for certain that adding a userland API tuner/demod interface to > >> the kernel, allowing non-caring opportunistic silicon or board vendors > >> to developer closed source proprietary drivers, will have a negative > >> effect on the community and we'd set back linuxtv 3-5 years. > >> > >> I know for certain that it would happen. Trust me. > >> > >> I've told you this countless times and you're not hearing me. > >> > >> Hauppauge have some leverage with Conexant and NXP to release public > >> datasheets. If they just have to release a demod.so (or similar) > >> loadable, they'll defer to the board vendors and we'll see the certain > >> board vendors 'locking other board vendors' out of their drivers. We'll > >> see embedded firmware, not shared between drivers. > >> > >> Except, it won't stop at demod.so. It will extend into unfixable bugs > >> for VendorB's board, because VendorA doesn't want to release a new > >> demod.so, and VendorB has no linux resources. What happens next? For > >> financial reasons - demod.so will begin to include checks to see if > >> specific PCI or USB devices are present in the system, and will fail to > >> work properly (if at all) when they're not being used with the preferred > >> products. > >> > >> > > Steven, > > > > what stops vendors of using the current existing code to achieve that > > goal. They could provide binary drivers with the existing API. > > > > > > Because the good people in this mailing list are keeping them honest. > Give any board or silicon company the ability to protect their IP, even > in the smallest way and they'll do it, and for no good technical reason. > It's a cut throat market and it's not clear that everyone understands > just how thin sales margins really are. > > That means Hauppauge potentially releasing a binary driver, because it's > much easier than seeking silicon vendor permission for a public diver. > The net result of that would mean I'd have to leave the company and find > another company that practices the one thing I truly care about > open source and open development groups. > well you could already release binary drivers if you would be concerned about it, so again all that seems to be no reason for me. What stops Hauppauge in implementing drivers another way? For example the USB drivers completly in userspace. > I'm keeping Hauppauge honest with their Linux involvement and I'm not > alone. Other devs in other linux subsystems in other companies are doing > the same thing. > For example the UIO thing, accessing MMIO through userspace, also accessing usb control messages from userspace. Because of that reason since it is already possible to provide binary drivers your reason is again not valid. The code which the userspace tuners are connected to is GPL so what. Beside that Hauppauge is not the only company out there although I also have contacts there at Hauppauge Europe. > Binary drivers (or binary components) leads Linux back in time. > > I can't believe your so passionat
Re: [linux-dvb] [PATCH] Userspace tuner
On 9/14/07, Manu Abraham <[EMAIL PROTECTED]> wrote: > 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 ? > upcoming x86-64 processors from the AMD side. I'm not into what Intel is doing in that area at the moment. 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/
Re: [linux-dvb] [PATCH] Userspace tuner
On 9/14/07, Alan Cox <[EMAIL PROTECTED]> wrote: > On Fri, Sep 14, 2007 at 01:17:05AM +0200, Markus Rechberger wrote: > > what stops vendors of using the current existing code to achieve that > > goal. They could provide binary drivers with the existing API. > > If you feel lucky about the GPL > > > What stops companies to intercept the ioctl calls and overriding some > > I2C commands? > > The GPL - derivative work is the boundary not code linkage. Possibly a > userspace > tuner hack would probably fit this too. Especially if a specific vendor is > producing both bits together and trying to claim they are independant. > > > How about proprietary video formats, would you also place the decoding > > algorithms in kernel just to force companies to release their code > > for it? > > No, I would assume they'd provide a proprietary conversion library that > no nobody would use (just like their hw). We keep format conversion firmly > seperated from hardware I/O processing. > In general there are known formats available, the drawback is that every TV application deals with it in a non-unified way at the moment, meaning alot code duplication in userspace since there's no library available at the moment which does the videoconversion from one to another format. Such a library is beeing developed at the moment which gets plugged infront of accessing the devicenodes. Although in the long run I'm looking forward to reuse the userspace tuners with such a library infront of everything by using i2c-dev. This would also make it easy to reuse the sample code of several companies, without having to cut out several features of the drivers and to rewrite them to an inkernel format. 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/
