saa716x driver status
Hi All, I've recently acquired a AverMedia Hybrid NanoExpress tv tuner and I'm trying to get it working with Fedora 13 and Fedora 12. I've found drivers at http://www.jusst.de/hg/saa716x/ On f12 the driver build and install, but I have missing symbols when I try to modprobe the drivers. On f13 the drivers fail to build. I've tried contacting Manu Abraham (whom I believe is the developer) about the f12 issues, but haven't heard back. I've searched google for everything from saa716x, AverMedia Hybrid Nano Express, HC82 and 1461:0555 (the pci address, I guess). There's bits and pieces about this driver in the results, but most are that they can build the driver, but it doesn't work. I'm happy to 'risk' my card and try stuff to get this to work, but I'm curious about whether or not development is ongoing and how I can help (not being a c coder) I'll attach the output of the build attempt on f13 in case someone can advise what is going wrong. The build log was captured using: $ make /tmp/saa716x.build.log.f13 regards Rodd make -C /tmp/saa716x-01c9f2163edd/v4l make[1]: Entering directory `/tmp/saa716x-01c9f2163edd/v4l' perl scripts/make_config_compat.pl /lib/modules/2.6.33-1.fc13.x86_64/source ./.myconfig ./config-compat.h creating symbolic links... make -C firmware prep make[2]: Entering directory `/tmp/saa716x-01c9f2163edd/v4l/firmware' make[2]: Leaving directory `/tmp/saa716x-01c9f2163edd/v4l/firmware' make -C firmware make[2]: Entering directory `/tmp/saa716x-01c9f2163edd/v4l/firmware' CC ihex2fw Generating vicam/firmware.fw Generating dabusb/firmware.fw Generating dabusb/bitstream.bin Generating ttusb-budget/dspbootcode.bin Generating cpia2/stv0672_vp4.bin Generating av7110/bootcode.bin make[2]: Leaving directory `/tmp/saa716x-01c9f2163edd/v4l/firmware' Kernel build directory is /lib/modules/2.6.33-1.fc13.x86_64/build make -C /lib/modules/2.6.33-1.fc13.x86_64/build SUBDIRS=/tmp/saa716x-01c9f2163edd/v4l modules make[2]: Entering directory `/usr/src/kernels/2.6.33-1.fc13.x86_64' CC [M] /tmp/saa716x-01c9f2163edd/v4l/tuner-xc2028.o CC [M] /tmp/saa716x-01c9f2163edd/v4l/tuner-simple.o CC [M] /tmp/saa716x-01c9f2163edd/v4l/tuner-types.o CC [M] /tmp/saa716x-01c9f2163edd/v4l/mt20xx.o CC [M] /tmp/saa716x-01c9f2163edd/v4l/tda8290.o CC [M] /tmp/saa716x-01c9f2163edd/v4l/tea5767.o CC [M] /tmp/saa716x-01c9f2163edd/v4l/tea5761.o CC [M] /tmp/saa716x-01c9f2163edd/v4l/tda9887.o CC [M] /tmp/saa716x-01c9f2163edd/v4l/tda827x.o CC [M] /tmp/saa716x-01c9f2163edd/v4l/au0828-core.o CC [M] /tmp/saa716x-01c9f2163edd/v4l/au0828-i2c.o CC [M] /tmp/saa716x-01c9f2163edd/v4l/au0828-cards.o CC [M] /tmp/saa716x-01c9f2163edd/v4l/au0828-dvb.o CC [M] /tmp/saa716x-01c9f2163edd/v4l/au0828-video.o CC [M] /tmp/saa716x-01c9f2163edd/v4l/au8522_dig.o CC [M] /tmp/saa716x-01c9f2163edd/v4l/au8522_decoder.o CC [M] /tmp/saa716x-01c9f2163edd/v4l/flexcop-pci.o CC [M] /tmp/saa716x-01c9f2163edd/v4l/flexcop-usb.o CC [M] /tmp/saa716x-01c9f2163edd/v4l/flexcop.o CC [M] /tmp/saa716x-01c9f2163edd/v4l/flexcop-fe-tuner.o CC [M] /tmp/saa716x-01c9f2163edd/v4l/flexcop-i2c.o CC [M] /tmp/saa716x-01c9f2163edd/v4l/flexcop-sram.o CC [M] /tmp/saa716x-01c9f2163edd/v4l/flexcop-eeprom.o CC [M] /tmp/saa716x-01c9f2163edd/v4l/flexcop-misc.o CC [M] /tmp/saa716x-01c9f2163edd/v4l/flexcop-hw-filter.o CC [M] /tmp/saa716x-01c9f2163edd/v4l/flexcop-dma.o CC [M] /tmp/saa716x-01c9f2163edd/v4l/bttv-driver.o In file included from /tmp/saa716x-01c9f2163edd/v4l/bttvp.h:36, from /tmp/saa716x-01c9f2163edd/v4l/bttv-driver.c:47: include/linux/input.h:599:1: warning: KEY_RFKILL redefined include/linux/input.h:379:1: warning: this is the location of the previous definition CC [M] /tmp/saa716x-01c9f2163edd/v4l/bttv-cards.o In file included from /tmp/saa716x-01c9f2163edd/v4l/bttvp.h:36, from /tmp/saa716x-01c9f2163edd/v4l/bttv-cards.c:41: include/linux/input.h:599:1: warning: KEY_RFKILL redefined include/linux/input.h:379:1: warning: this is the location of the previous definition CC [M] /tmp/saa716x-01c9f2163edd/v4l/bttv-if.o In file included from /tmp/saa716x-01c9f2163edd/v4l/bttvp.h:36, from /tmp/saa716x-01c9f2163edd/v4l/bttv-if.c:34: include/linux/input.h:599:1: warning: KEY_RFKILL redefined include/linux/input.h:379:1: warning: this is the location of the previous definition CC [M] /tmp/saa716x-01c9f2163edd/v4l/bttv-risc.o In file included from /tmp/saa716x-01c9f2163edd/v4l/bttvp.h:36, from /tmp/saa716x-01c9f2163edd/v4l/bttv-risc.c:36: include/linux/input.h:599:1: warning: KEY_RFKILL redefined include/linux/input.h:379:1: warning: this is the location of the previous definition CC [M] /tmp/saa716x-01c9f2163edd/v4l/bttv-vbi.o In file included from /tmp/saa716x-01c9f2163edd/v4l/bttvp.h:36, from /tmp/saa716x-01c9f2163edd/v4l/bttv-vbi.c:34: include/linux/input.h:599:1: warning: KEY_RFKILL redefined
Re: [PATCH/RFC 0/2] Fix DQBUF behavior for recoverable streaming errors
On Thursday 18 March 2010 16:37:18 Pawel Osciak wrote: Laurent Pinchart wrote: On Wednesday 17 March 2010 21:05:19 Hans Verkuil wrote: On Wednesday 17 March 2010 15:29:48 Pawel Osciak wrote: Hello, during the V4L2 brainstorm meeting in Norway we have concluded that streaming error handling in dqbuf is lacking a bit and might result in the application losing video buffers. V4L2 specification states that DQBUF should set errno to EIO in such cases: EIO VIDIOC_DQBUF failed due to an internal error. Can also indicate temporary problems like signal loss. Note the driver might dequeue an (empty) buffer despite returning an error, or even stop capturing. There is a problem with this though. v4l2-ioctl.c code does not copy back v4l2_buffer fields to userspace on a failed ioctl invocation, i.e. when __video_do_ioctl() does not return 0, it jumps over the copy_to_user() code: /* ... */ err = __video_do_ioctl(file, cmd, parg); /* ... */ if (err 0) goto out; /* ... */ if (copy_to_user((void __user *)arg, parg, _IOC_SIZE(cmd))) err = -EFAULT; /* ... */ out: This is fine in general, but in the case of DQBUF errors, the v4l2_buffer fields are not copied back. Because of that, the application does not have any means of discovering on which buffer the operation failed. So it cannot reuse that buffer, even despite the fact that the spec allows such behavior. This RFC proposes a modification to the DQBUF behavior in cases of internal (recoverable) errors to allow recovery from such situations. We propose a new flag for the v4l2_buffer flags field, V4L2_BUF_FLAG_ERROR. There already exists a V4L2_BUF_FLAG_DONE flag, so to support older applications, the new flag should always be set together with it. Applications unaware of the new flag would simply display a corrupted frame, but we believe it is still a better solution than failing altogether. Old EIO behavior remains so the change is backwards compatible. I will post relevant V4L2 documentation updates after (if) this change is accepted. This series is rebased onto my recent videobuf clean-up and poll behavior patches. The series contains: [PATCH 1/2] v4l: Add a new ERROR flag for DQBUF after recoverable streaming errors [PATCH 2/2] v4l: videobuf: Add support for V4L2_BUF_FLAG_ERROR Reviewed-by: Hans Verkuil hverk...@xs4all.nl I think this is a very sensible change. After all, DQBUF succeeds, even though the buffer itself contains errors. But that is not the fault of DQBUF. It is enough to flag that the buffer does have an error. Without this you actually loose the buffer completely from the point of view of the application. And that's really nasty. Especially with the current wording of the spec: Note the driver might dequeue an (empty) buffer despite returning an error, or even stop capturing. That's pretty bad. Because of video_ioctl2 the application won't know which buffer has been dequeued, if any, and will thus have no way to requeue it. Pavel, could you update the Docbook documentation as well in your patch set ? The behaviour of DQBUF needs to be properly documented. Sure. Although I just noticed something. The spec for V4L2_BUF_FLAG_DONE says: When this flag is set, the buffer is currently on the outgoing queue, ready to be dequeued from the driver. Drivers set or clear this flag when the VIDIOC_QUERYBUF ioctl is called. After calling the VIDIOC_QBUF or VIDIOC_DQBUF it is always cleared. Of course a buffer cannot be on both queues at the same time, the V4L2_BUF_FLAG_QUEUED and V4L2_BUF_FLAG_DONE flag are mutually exclusive. They can be both cleared however, then the buffer is in dequeued state, in the application domain to say so. So according to the spec, DONE means done but not yet returned to userspace. So it should be cleared during dequeueing. But videobuf actually sets that flag in dqbuf. And frankly, it seems more sensible to me. Could you confirm that this is how we want it and I should follow the specs? If so, I will fix videobuf to stop setting that flag. I think the spec makes sense, actually. But doesn't videobuf clear this already? On ERROR and DONE videobuf_dqbuf will change the state to IDLE. videobuf_status then won't set the DONE flag. So as far as I can tell there is nothing that needs to change here. Regards, Hans Best regards -- Pawel Osciak Linux Platform Group Samsung Poland RD Center -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- Hans Verkuil - video4linux developer - sponsored by TANDBERG -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a
Testers for the cpia2 driver wanted!
Hi all, I'm looking for someone who has hardware that can test the cpia2 driver. I thought I had hardware for that, but it turned out that it used the gspca mars driver instead. Regards, Hans -- Hans Verkuil - video4linux developer - sponsored by TANDBERG -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
New wiki page: V4L framework progress
Hi all! I started a new page on the wiki: http://www.linuxtv.org/wiki/index.php/V4L_framework_progress I want to be able to use this to keep track of the status of bridge and sub-device drivers. The bridge driver table is mostly finished, but I would appreciate it if maintainers of particular drivers can double check the table entry and add their initials to the 'have hardware' column. Don't bother with the i2c table yet, I still need to fill that in. Regards, Hans -- Hans Verkuil - video4linux developer - sponsored by TANDBERG -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Resubmit: PATCH-V2] Introducing ti-media directory
Hi Murali, On Tuesday 23 March 2010 18:52:44 Karicheri, Muralidharan wrote: Laurent, I'm not too sure to like the ti-media name. It will soon get quite crowded, and name collisions might occur (look at the linux-omap-camera tree and the ISP driver in there for instance). Isn't there an internal name to refer to both the DM6446 and AM3517 that could be used ? [Hiremath, Vaibhav] Laurent, ti-media directory is top level directory where we are putting all TI devices drivers. So having said that, we should worrying about what goes inside this directory. For me ISP is more generic, if you compare davinci and OMAP. Frankly, there are various naming convention we do have from device to device, even if the IP's are being reused. For example, the internal name for OMAP is ISP but Davinci refers it as a VPSS. Could you explain what name space issue you are referring to in linux-omap-camera since I am not quite familiar with that tree? The linux-omap-camera tree contains a driver for the OMAP3 ISP. Basically, most source files start with the isp prefix and are stored in drivers/media/video/isp/. ISP is quite a generic name, and other vendors will probably develop an ISP at some point (if not already done), so there's already a potential name conflict today. Using a dedicated directory in drivers/media/video for TI-specific cores is definitely a good idea (assuming the same IP cores won't be used by other vendors in the future). My concern is that, if we move the ISP driver in drivers/media/video/ti-media, the directory will soon get quite crowded. If a new TI processor comes up with a totally incompatible ISP, we will get a name conflict in drivers/media/video/ti-media. I was thinking about either replacing the isp prefix with omap3isp (or similar), or moving the driver to drivers/media/video/ti-media/omap3isp, but that will impede code sharing code between the Davinci and OMAP processor families. That's where my uncertainty comes from. Myself and Vaibhav had discussed this in the past and ti-media is the generic name that we could agree on. On DM SoCs (DM6446, DM355, DM365) I expect ti-media to be the home for all vpfe and vpbe driver files. Since we had a case of common IP across OMAP and DMxxx SoCs, we want to place all OMAP and DMxxx video driver files in a common directory so that sharing the drivers across the SoCs will be easy. We could discuss and agree on another name if need be. Any suggestions? It's not the name ti-media that I don't agree on, it's just that this will move the problem one step further in the directory hierarchy without actually solving it :-) Is it guaranteed today that no TI processors with new generation video blocks will reuse the names ISP, VPFE and VPBE ? The OMAP3 datasheet refers to VPFE and VPBE, but luckily those blocks are further divided into subblocks, and the driver doesn't refer to the VPFE and VPBE directly. -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: i2c interface bugs in dvb drivers
Hi Matthieu, On Sun, 21 Mar 2010 15:02:50 +0100, matthieu castet wrote: some dvb driver that export a i2c interface contains some mistakes because they mainly used by driver (frontend, tuner) wrote for them. But the i2c interface is exposed to everybody. One mistake is expect msg[i].addr with 8 bits address instead of 7 bits address. This make them use eeprom address at 0xa0 instead of 0x50. Also they shift tuner address (qt1010 tuner is likely to be at address 0x62, but some put it a 0xc4 (af9015, af9005, dtv5100)). Other mistakes is in xfer callback. Often the controller support a limited i2c support (n bytes write then m bytes read). The driver try to convert the linux i2c msg to this pattern, but they often miss cases : - msg[i].len can be null Zero, not null. This is a very rare case, I've never seen it in multi-message transactions (wouldn't make much sense IMHO), only in the single-message transaction known as SMBus quick command. Many controllers don't support it, so I2C bus drivers don't have to support it. It should be assumed by I2C chip drivers that an I2C adapter without functionality bit I2C_FUNC_SMBUS_QUICK does not support 0-byte messages. - msg write are not always followed by msg read And this can be dangerous if these interfaces are exported to userspace via i2c-dev : Even without that... We certainly hope to reuse client drivers for other families of DVB cards, and for this to work, every driver must stick to the standard. - some scanning program avoid eeprom by filtering 0x5x range, but now it is at 0xax range (well that should happen because scan limit should be 0x77) - some read only command can be interpreted as write command. Very bad indeed. What should be done ? Fix the drivers. Yes, definitely. The sooner, the better. Have a mode where i2c interface are not exported to everybody. I have considered this for a moment. It might be fair to let I2C bus drivers decide whether they want i2c-dev to expose their buses or not. We could use a new class bit (I2C_CLASS_USER or such) to this purpose. I didn't get to it yet though, as this doesn't seem to be urgent, and i2c-dev has so many other problems... That being said, this is hardly a valid answer to the problem you discovered. Preventing user-space from triggering bugs is not fixing them. Don't care. No, that's not an option. First why does the i2c stack doesn't check that the address is on 7 bits (like the attached patch) ? Performance reasons, I presume. Having to check this each time a transaction is attempted would be quite costly. Secondly, I suspect it was never thought that raw I2C messaging would become so popular. The original intent was to have all I2C device drivers (except maybe i2c-dev) register their clients. The legacy method for this (i2c_detect) _does_ have an address check included, and so do i2c_new_probed_device and i2c_sysfs_new_device. Probably we should add it to i2c_new_device as well, for consistency. It is way less expensive to check the address once and for all, than with each transaction. I certainly hope that DVB will move to client-based I2C device drivers at some point in time. Note though that the address check is in no way bullet-proof. If addresses in the range 0x03-0x3b are handled as 8-bit entities instead of 7-bit entities, they will appear to be in the range 0x06-0x76, which is perfectly valid. Also I believe a program for testing i2c interface corner case should catch most of these bugs : - null msg[i].len - different transactions on a device : - one write/read transaction - one write transaction then one read transaction [...] Does a such program exist ? We have several programs in the i2c-tools package, which can be used to this purpose: * i2cdetect * i2cdump * i2cget * i2cset With these 4 tools, almost all SMBus transaction types are covered. This is sufficient in most cases in my experience. If not, these tools can certainly get extended, at least to cover all of SMBus. -- Jean Delvare -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
saa716x driver status
Hi All, I've recently acquired a AverMedia Hybrid NanoExpress tv tuner and I'm trying to get it working with Fedora 13 and Fedora 12. I've found drivers at http://www.jusst.de/hg/saa716x/ On f12 the driver build and install, but I have missing symbols when I try to modprobe the drivers. On f13 the drivers fail to build. I've tried contacting Manu Abraham (whom I believe is the developer) about the f12 issues, but haven't heard back. I've searched google for everything from saa716x, AverMedia Hybrid Nano Express, HC82 and 1461:0555 (the pci address, I guess). There's bits and pieces about this driver in the results, but most are that they can build the driver, but it doesn't work. I'm happy to 'risk' my card and try stuff to get this to work, but I'm curious about whether or not development is ongoing and how I can help (not being a c coder) I'll attach the output of the build attempt on f13 in case someone can advise what is going wrong. The build log was captured using: $ make /tmp/saa716x.build.log.f13 regards Rodd make -C /tmp/saa716x-01c9f2163edd/v4l make[1]: Entering directory `/tmp/saa716x-01c9f2163edd/v4l' perl scripts/make_config_compat.pl /lib/modules/2.6.33-1.fc13.x86_64/source ./.myconfig ./config-compat.h creating symbolic links... make -C firmware prep make[2]: Entering directory `/tmp/saa716x-01c9f2163edd/v4l/firmware' make[2]: Leaving directory `/tmp/saa716x-01c9f2163edd/v4l/firmware' make -C firmware make[2]: Entering directory `/tmp/saa716x-01c9f2163edd/v4l/firmware' CC ihex2fw Generating vicam/firmware.fw Generating dabusb/firmware.fw Generating dabusb/bitstream.bin Generating ttusb-budget/dspbootcode.bin Generating cpia2/stv0672_vp4.bin Generating av7110/bootcode.bin make[2]: Leaving directory `/tmp/saa716x-01c9f2163edd/v4l/firmware' Kernel build directory is /lib/modules/2.6.33-1.fc13.x86_64/build make -C /lib/modules/2.6.33-1.fc13.x86_64/build SUBDIRS=/tmp/saa716x-01c9f2163edd/v4l modules make[2]: Entering directory `/usr/src/kernels/2.6.33-1.fc13.x86_64' CC [M] /tmp/saa716x-01c9f2163edd/v4l/tuner-xc2028.o CC [M] /tmp/saa716x-01c9f2163edd/v4l/tuner-simple.o CC [M] /tmp/saa716x-01c9f2163edd/v4l/tuner-types.o CC [M] /tmp/saa716x-01c9f2163edd/v4l/mt20xx.o CC [M] /tmp/saa716x-01c9f2163edd/v4l/tda8290.o CC [M] /tmp/saa716x-01c9f2163edd/v4l/tea5767.o CC [M] /tmp/saa716x-01c9f2163edd/v4l/tea5761.o CC [M] /tmp/saa716x-01c9f2163edd/v4l/tda9887.o CC [M] /tmp/saa716x-01c9f2163edd/v4l/tda827x.o CC [M] /tmp/saa716x-01c9f2163edd/v4l/au0828-core.o CC [M] /tmp/saa716x-01c9f2163edd/v4l/au0828-i2c.o CC [M] /tmp/saa716x-01c9f2163edd/v4l/au0828-cards.o CC [M] /tmp/saa716x-01c9f2163edd/v4l/au0828-dvb.o CC [M] /tmp/saa716x-01c9f2163edd/v4l/au0828-video.o CC [M] /tmp/saa716x-01c9f2163edd/v4l/au8522_dig.o CC [M] /tmp/saa716x-01c9f2163edd/v4l/au8522_decoder.o CC [M] /tmp/saa716x-01c9f2163edd/v4l/flexcop-pci.o CC [M] /tmp/saa716x-01c9f2163edd/v4l/flexcop-usb.o CC [M] /tmp/saa716x-01c9f2163edd/v4l/flexcop.o CC [M] /tmp/saa716x-01c9f2163edd/v4l/flexcop-fe-tuner.o CC [M] /tmp/saa716x-01c9f2163edd/v4l/flexcop-i2c.o CC [M] /tmp/saa716x-01c9f2163edd/v4l/flexcop-sram.o CC [M] /tmp/saa716x-01c9f2163edd/v4l/flexcop-eeprom.o CC [M] /tmp/saa716x-01c9f2163edd/v4l/flexcop-misc.o CC [M] /tmp/saa716x-01c9f2163edd/v4l/flexcop-hw-filter.o CC [M] /tmp/saa716x-01c9f2163edd/v4l/flexcop-dma.o CC [M] /tmp/saa716x-01c9f2163edd/v4l/bttv-driver.o In file included from /tmp/saa716x-01c9f2163edd/v4l/bttvp.h:36, from /tmp/saa716x-01c9f2163edd/v4l/bttv-driver.c:47: include/linux/input.h:599:1: warning: KEY_RFKILL redefined include/linux/input.h:379:1: warning: this is the location of the previous definition CC [M] /tmp/saa716x-01c9f2163edd/v4l/bttv-cards.o In file included from /tmp/saa716x-01c9f2163edd/v4l/bttvp.h:36, from /tmp/saa716x-01c9f2163edd/v4l/bttv-cards.c:41: include/linux/input.h:599:1: warning: KEY_RFKILL redefined include/linux/input.h:379:1: warning: this is the location of the previous definition CC [M] /tmp/saa716x-01c9f2163edd/v4l/bttv-if.o In file included from /tmp/saa716x-01c9f2163edd/v4l/bttvp.h:36, from /tmp/saa716x-01c9f2163edd/v4l/bttv-if.c:34: include/linux/input.h:599:1: warning: KEY_RFKILL redefined include/linux/input.h:379:1: warning: this is the location of the previous definition CC [M] /tmp/saa716x-01c9f2163edd/v4l/bttv-risc.o In file included from /tmp/saa716x-01c9f2163edd/v4l/bttvp.h:36, from /tmp/saa716x-01c9f2163edd/v4l/bttv-risc.c:36: include/linux/input.h:599:1: warning: KEY_RFKILL redefined include/linux/input.h:379:1: warning: this is the location of the previous definition CC [M] /tmp/saa716x-01c9f2163edd/v4l/bttv-vbi.o In file included from /tmp/saa716x-01c9f2163edd/v4l/bttvp.h:36, from /tmp/saa716x-01c9f2163edd/v4l/bttv-vbi.c:34: include/linux/input.h:599:1: warning: KEY_RFKILL redefined
[PATCH] V4L/DVB: budget: Oops: BUG: unable to handle kernel NULL pointer dereference
Never call dvb_frontend_detach if we failed to attach a frontend. This fixes
the following oops, which will be triggered by a missing stv090x module:
[8.172997] DVB: registering new adapter (TT-Budget S2-1600 PCI)
[8.209018] adapter has MAC addr = 00:d0:5c:cc:a7:29
[8.328665] Intel ICH :00:1f.5: PCI INT B - GSI 17 (level, low) - IRQ
17
[8.328753] Intel ICH :00:1f.5: setting latency timer to 64
[8.562047] DVB: Unable to find symbol stv090x_attach()
[8.562117] BUG: unable to handle kernel NULL pointer dereference at 00ac
[8.562239] IP: [e08b04a3] dvb_frontend_detach+0x4/0x67 [dvb_core]
Ref http://bugs.debian.org/575207
Signed-off-by: Bjørn Mork bj...@mork.no
Cc: sta...@kernel.org
Cc: 575...@bugs.debian.org
---
This patch should apply cleanly to 2.6.32, 2.6.33, 2.6.34-rc2 and with an
offset to git://linuxtv.org/v4l-dvb.git
Please apply to all of them
drivers/media/dvb/ttpci/budget.c |3 ---
1 files changed, 0 insertions(+), 3 deletions(-)
diff --git a/drivers/media/dvb/ttpci/budget.c b/drivers/media/dvb/ttpci/budget.c
index e48380c..95a463c 100644
--- a/drivers/media/dvb/ttpci/budget.c
+++ b/drivers/media/dvb/ttpci/budget.c
@@ -643,9 +643,6 @@ static void frontend_init(struct budget *budget)
budget-i2c_adap,
tt1600_isl6423_config);
- } else {
- dvb_frontend_detach(budget-dvb_frontend);
- budget-dvb_frontend = NULL;
}
}
break;
--
1.5.6.5
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] DTV2000 H Plus issues
An updated patch that includes the PxDVR3200 H (107d:6f39) support is now available at http://istvanv.users.sourceforge.net/v4l/xc4000.html. On 03/22/2010 07:33 PM, istva...@mailbox.hu wrote: On 03/15/2010 05:15 AM, Devin Heitmueller wrote: I'll try to go through my tree and see if I can get something upstream this week which you could build on. Are there any news on this ? By the way, I have just received this mail from Mirek Slugen, with a patch for PxDVR3200 with XC4000 tuner. Should that patch also be submitted ? On 03/22/2010 04:40 PM, Mirek Slugeň wrote: First I would like to thank you for your work on XC4000 Leadtek tuners, analog TV, analog FM and DVB-T works great. I created patch for new revision of Leadtek DVR3200 (xc4000) based on your patch and it works also (patch is included). After long testing I found only one small bug, signal strength is not working on DVB-T XC4000 based tuners, so i will try to fix it. -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
SOC camera port for ov7675/ov2640 on i.MX25
Hi,
I'm just beginning a Linux based project running on a Freescale i.MX25.
One of
my jobs is to write a camera driver for the sensor we're going to be
using
(Omnivision 7675). However at present I only have access to an ov2640
attached
to a Freescale 3stack development board. I thought it would be a useful
and
interesting exercise to port the driver provided by Freescale to the new
soc_camera framework.
I've written the ov2640 driver, using a variety of other drivers as
references
and I'm using the mx25_camera host driver (with a few mods) posted by
Arno
Euteneuer. After getting over some basic setup/config problems I've now
got as
far as the mx25_camera loading and this then auto loading the ov2640.
This
correctly probes the I2C and detects the sensor.
However I've now come up against a problem that I'm unsure of how to
solve and
I'm not sure whether its a case of my not properly following the current
framework. soc_camera_probe() is called and detects the the
soc_camera_link
object contains board information and therefore calls
soc_camera_init_i2c() this
in turn calls v4l2_i2c_new_subdev_board() which then attempts to create
a new
i2c_client (i2c_new_device()) and it is at this point things fail.
Because an i2c_client already exists (auto created from the static board
info
registered by the platform configuration), the one passed into the
probe()
routine of my chip driver, the i2c_new_device() call fails as it believe
the
device is busy as a client already exists for that I2C address.
I can only assume that there is something wrong with the way I've set
things up
/ used the framework. However I've compared it to several other modules
and
can't see any obvious faults (although its not obvious which drivers
represent
the current preferred approach).
I should say that I'm using a 2.6.31 based kernel (provided by
Freescale) into
which I've grafted the 2.6.33 media drivers (and obvious dependencies)
so I
guess something about this graft could be causing the problem. Though I
cannot
see what from looking at other changes.
I've pasted in the 4 files I think I relevant to what I'm doing:
drivers/media/video/mx25_camera.c
drivers/media/video/ov2640.c
arch/arm/mach-mx25/devices_merlin.c // extract only
arch/arm/mach-mx25/mx25_merlin.c // extract only
This is my first time posting to the mailing list so apologies if this
is not
the standard way of doing things.
I'd be grateful for any help.
Regards,
Adam
diff -Nuar a/devices_merlin.c b/devices_merlin.c
--- a/devices_merlin.c 1970-01-01 00:00:00.0 +
+++ b/devices_merlin.c 2010-03-24 11:16:22.0 +
@@ -0,0 +1,42 @@
+#if (defined CONFIG_VIDEO_MX25) || (defined CONFIG_VIDEO_MX25_MODULE)
+static u64 csi_dmamask = 0x;
+
+/* TODO: does this belong here or in the board spec?
+ * AND do we need a separate devices.c file? This doesn't seem to be
standard
practice?
+ */
+static struct mx25_camera_pdata camera_pdata = {
+ .flags = MX25_CAMERA_DATAWIDTH_8 | MX25_CAMERA_DATAWIDTH_10 |
MX25_CAMERA_DATAWIDTH_16,
+ .mclk_10khz = 2400,
+};
+
+static struct resource mx25_csi_resources[] = {
+ {
+ .start = 0x53FF8000,
+ .end = 0x53FFBFFF,
+ .flags = IORESOURCE_MEM,
+ }, {
+ .start = 17,
+ .end = 17,
+ .flags = IORESOURCE_IRQ,
+ },
+};
+
+struct platform_device mx25_csi_device = {
+ .name = mx25-camera,
+ .id = 0,
+ .dev = {
+ .coherent_dma_mask = 0x,
+ .dma_mask = csi_dmamask,
+ .platform_data = camera_pdata,
+ },
+ .num_resources = ARRAY_SIZE(mx25_csi_resources),
+ .resource = mx25_csi_resources,
+};
+static inline void mxc_init_csi(void)
+{
+ printk(%s: working\n, __func__);
+ if (platform_device_register(mx25_csi_device) 0)
+ dev_err(mx25_csi_device.dev,
+ Unable to register mx25 csi device\n);
+}
+#endif
diff -Nuar a/mx25_camera.c b/mx25_camera.c
--- a/mx25_camera.c 1970-01-01 00:00:00.0 +
+++ b/mx25_camera.c 2010-03-24 10:59:14.0 +
@@ -0,0 +1,1006 @@
+/*
+ * V4L2 Driver for i.MX25 camera (CSI) host
+ *
+ * Copyright (C) 2009, Arno Euteneuer arno.euteneuer at toptica.com
+ *
+ * Based on i.MXL/i.MXL camera (CSI) host driver
+ * Copyright (C) 2008, Paulius Zaleckas paulius.zaleckas at
teltonika.lt
+ * Copyright (C) 2009, Darius Augulis augulis.darius at gmail.com
+ *
+ * Based on PXA SoC camera driver
+ * Copyright (C) 2006, Sascha Hauer, Pengutronix
+ * Copyright (C) 2008, Guennadi Liakhovetski kernel at
pengutronix.de
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include linux/clk.h
+#include linux/delay.h
+#include linux/device.h
+#include linux/dma-mapping.h
+#include linux/errno.h
Re: [Resubmit: PATCH-V2] Introducing ti-media directory
Laurent Pinchart wrote: Hi Murali, On Tuesday 23 March 2010 18:52:44 Karicheri, Muralidharan wrote: Laurent, I'm not too sure to like the ti-media name. It will soon get quite crowded, and name collisions might occur (look at the linux-omap-camera tree and the ISP driver in there for instance). Isn't there an internal name to refer to both the DM6446 and AM3517 that could be used ? [Hiremath, Vaibhav] Laurent, ti-media directory is top level directory where we are putting all TI devices drivers. So having said that, we should worrying about what goes inside this directory. For me ISP is more generic, if you compare davinci and OMAP. Frankly, there are various naming convention we do have from device to device, even if the IP's are being reused. For example, the internal name for OMAP is ISP but Davinci refers it as a VPSS. Could you explain what name space issue you are referring to in linux-omap-camera since I am not quite familiar with that tree? The linux-omap-camera tree contains a driver for the OMAP3 ISP. Basically, most source files start with the isp prefix and are stored in drivers/media/video/isp/. ISP is quite a generic name, and other vendors will probably develop an ISP at some point (if not already done), so there's already a potential name conflict today. Using a dedicated directory in drivers/media/video for TI-specific cores is definitely a good idea (assuming the same IP cores won't be used by other vendors in the future). My concern is that, if we move the ISP driver in drivers/media/video/ti-media, the directory will soon get quite crowded. If a new TI processor comes up with a totally incompatible ISP, we will get a name conflict in drivers/media/video/ti-media. I was thinking about either replacing the isp prefix with omap3isp (or similar), or moving the driver to drivers/media/video/ti-media/omap3isp, but that will impede code sharing code between the Davinci and OMAP processor families. That's where my uncertainty comes from. There are two separate points here. The first one is re-using a driver or some symbols. Whatever directory structure is used, this won't prevent to share the code. Just create the header files under include/media and be sure that the Kbuild system will properly handle the dependencies, with depends on. Myself and Vaibhav had discussed this in the past and ti-media is the generic name that we could agree on. On DM SoCs (DM6446, DM355, DM365) I expect ti-media to be the home for all vpfe and vpbe driver files. Since we had a case of common IP across OMAP and DMxxx SoCs, we want to place all OMAP and DMxxx video driver files in a common directory so that sharing the drivers across the SoCs will be easy. We could discuss and agree on another name if need be. Any suggestions? It's not the name ti-media that I don't agree on, it's just that this will move the problem one step further in the directory hierarchy without actually solving it :-) Is it guaranteed today that no TI processors with new generation video blocks will reuse the names ISP, VPFE and VPBE ? The OMAP3 datasheet refers to VPFE and VPBE, but luckily those blocks are further divided into subblocks, and the driver doesn't refer to the VPFE and VPBE directly. I agree that a name like ti-media would be too generic. Also, if we take a look on how the drivers are currently organized, the trees aren't vendor-based, but chipset-design based. There are even some cases where there's just one or two C files that are directly stored under drivers/media/video (like tvp5150, for example). IMO, simpler drivers where just one or a couple of files are needed should be stored into drivers/media/video. Bigger drivers should be organized by family, and not by vendor. Otherwise, we would need to re-organize the tree to be coherent. One interesting example of the a per-family directory is cx25840. The same driver is used by several different chipsets. The driver supports a separate IC chip (cx25836, cx2584x), and two designs where the decoder logic is inside an IC chip with the bridge and other functional blocks (cx23885 and cx231xx). -- Cheers, Mauro -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: i2c interface bugs in dvb drivers
Jean Delvare wrote: Hi Matthieu, On Sun, 21 Mar 2010 15:02:50 +0100, matthieu castet wrote: some dvb driver that export a i2c interface contains some mistakes because they mainly used by driver (frontend, tuner) wrote for them. But the i2c interface is exposed to everybody. One mistake is expect msg[i].addr with 8 bits address instead of 7 bits address. This make them use eeprom address at 0xa0 instead of 0x50. Also they shift tuner address (qt1010 tuner is likely to be at address 0x62, but some put it a 0xc4 (af9015, af9005, dtv5100)). Other mistakes is in xfer callback. Often the controller support a limited i2c support (n bytes write then m bytes read). The driver try to convert the linux i2c msg to this pattern, but they often miss cases : - msg[i].len can be null Zero, not null. This is a very rare case, I've never seen it in multi-message transactions (wouldn't make much sense IMHO), only in the single-message transaction known as SMBus quick command. Many controllers don't support it, so I2C bus drivers don't have to support it. It should be assumed by I2C chip drivers that an I2C adapter without functionality bit I2C_FUNC_SMBUS_QUICK does not support 0-byte messages. - msg write are not always followed by msg read And this can be dangerous if these interfaces are exported to userspace via i2c-dev : Even without that... We certainly hope to reuse client drivers for other families of DVB cards, and for this to work, every driver must stick to the standard. - some scanning program avoid eeprom by filtering 0x5x range, but now it is at 0xax range (well that should happen because scan limit should be 0x77) - some read only command can be interpreted as write command. Very bad indeed. What should be done ? Fix the drivers. Yes, definitely. The sooner, the better. Agreed. Could you please propose some patches to fix them? Have a mode where i2c interface are not exported to everybody. I have considered this for a moment. It might be fair to let I2C bus drivers decide whether they want i2c-dev to expose their buses or not. We could use a new class bit (I2C_CLASS_USER or such) to this purpose. This is a good idea. Users shouldn't be playing with the internal interfaces inside the DVB driver. This can be dangerous, as it may cause driver miss-functioning, cause memory corruption or eventually hit some bug and make the driver crash. Also, due to I2C bridges that are very common on DVB designs, this interface is broken anyway, as the bridge code, when needed, is generally implemented outside i2c xfer routines. Cheers, Mauro -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] V4L/DVB: budget: Oops: BUG: unable to handle kernel NULL pointer dereference
Hi,
Bjørn Mork wrote:
Never call dvb_frontend_detach if we failed to attach a frontend. This fixes
the following oops, which will be triggered by a missing stv090x module:
[8.172997] DVB: registering new adapter (TT-Budget S2-1600 PCI)
[8.209018] adapter has MAC addr = 00:d0:5c:cc:a7:29
[8.328665] Intel ICH :00:1f.5: PCI INT B - GSI 17 (level, low) -
IRQ 17
[8.328753] Intel ICH :00:1f.5: setting latency timer to 64
[8.562047] DVB: Unable to find symbol stv090x_attach()
[8.562117] BUG: unable to handle kernel NULL pointer dereference at
00ac
[8.562239] IP: [e08b04a3] dvb_frontend_detach+0x4/0x67 [dvb_core]
...
Ref http://bugs.debian.org/575207
Signed-off-by: Bjørn Mork bj...@mork.no
Cc: sta...@kernel.org
Cc: 575...@bugs.debian.org
---
This patch should apply cleanly to 2.6.32, 2.6.33, 2.6.34-rc2 and with an
offset to git://linuxtv.org/v4l-dvb.git
Please apply to all of them
drivers/media/dvb/ttpci/budget.c |3 ---
1 files changed, 0 insertions(+), 3 deletions(-)
diff --git a/drivers/media/dvb/ttpci/budget.c
b/drivers/media/dvb/ttpci/budget.c
index e48380c..95a463c 100644
--- a/drivers/media/dvb/ttpci/budget.c
+++ b/drivers/media/dvb/ttpci/budget.c
@@ -643,9 +643,6 @@ static void frontend_init(struct budget *budget)
budget-i2c_adap,
tt1600_isl6423_config);
- } else {
- dvb_frontend_detach(budget-dvb_frontend);
- budget-dvb_frontend = NULL;
}
}
break;
This patch fixes only one of three possible problems.
Could you please extend your patch in a way
that it will also catch, if
- dvb_attach(stv6110x_attach,...)
- dvb_attach(isl6423_attach,...)
fail?
CU
Oliver
--
VDR Remote Plugin 0.4.0: http://www.escape-edv.de/endriss/vdr/
4 MByte Mod: http://www.escape-edv.de/endriss/dvb-mem-mod/
Full-TS Mod: http://www.escape-edv.de/endriss/dvb-full-ts-mod/
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Bug#575207: Info received ([PATCH] V4L/DVB: budget: Oops: BUG: unable to handle kernel NULL pointer dereference)
Thank you for the additional information you have supplied regarding this Bug report. This is an automatically generated reply to let you know your message has been received. Your message is being forwarded to the package maintainers and other interested parties for their attention; they will reply in due course. Your message has been sent to the package maintainer(s): Debian Kernel Team debian-ker...@lists.debian.org If you wish to submit further information on this problem, please send it to 575...@bugs.debian.org. Please do not send mail to ow...@bugs.debian.org unless you wish to report a problem with the Bug-tracking system. -- 575207: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=575207 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2] V4L/DVB: budget: Oops: BUG: unable to handle kernel NULL pointer dereference
Never call dvb_frontend_detach if we failed to attach a frontend. This fixes
the following oops:
[8.172997] DVB: registering new adapter (TT-Budget S2-1600 PCI)
[8.209018] adapter has MAC addr = 00:d0:5c:cc:a7:29
[8.328665] Intel ICH :00:1f.5: PCI INT B - GSI 17 (level, low) - IRQ
17
[8.328753] Intel ICH :00:1f.5: setting latency timer to 64
[8.562047] DVB: Unable to find symbol stv090x_attach()
[8.562117] BUG: unable to handle kernel NULL pointer dereference at 00ac
[8.562239] IP: [e08b04a3] dvb_frontend_detach+0x4/0x67 [dvb_core]
Ref http://bugs.debian.org/575207
Also clean up if we are unable to register the tuner and LNB drivers
Signed-off-by: Bjørn Mork bj...@mork.no
Cc: sta...@kernel.org
Reported-by: Fladischer Michael fladischermich...@fladi.at
---
Oliver Endriss o.endr...@gmx.de writes:
Could you please extend your patch in a way
that it will also catch, if
- dvb_attach(stv6110x_attach,...)
- dvb_attach(isl6423_attach,...)
fail?
OK. Attempting, although I have no clue whether such failures are really
fatal or not...
This is version 2 of this patch, adding cleanup in case we fail to register
the two submodules used by this card/frontend. I'm not certain that this
additional cleanup is appropriate for stable as any failure to register
these will be handled cleanly AFAICS. But I have no way to test this.
This patch should apply cleanly to 2.6.32, 2.6.33, 2.6.34-rc2
This does not apply cleanly to git://linuxtv.org/v4l-dvb.git master. I will
followup with a similar patch for that branch
Please apply to stable if appropriate. If not, please apply version 1
of the patch, which fixes only the oops condition.
drivers/media/dvb/ttpci/budget.c | 42 -
1 files changed, 23 insertions(+), 19 deletions(-)
diff --git a/drivers/media/dvb/ttpci/budget.c b/drivers/media/dvb/ttpci/budget.c
index e48380c..4666c1e 100644
--- a/drivers/media/dvb/ttpci/budget.c
+++ b/drivers/media/dvb/ttpci/budget.c
@@ -627,25 +627,29 @@ static void frontend_init(struct budget *budget)
tt1600_stv6110x_config,
budget-i2c_adap);
- tt1600_stv090x_config.tuner_init =
ctl-tuner_init;
- tt1600_stv090x_config.tuner_set_mode =
ctl-tuner_set_mode;
- tt1600_stv090x_config.tuner_set_frequency =
ctl-tuner_set_frequency;
- tt1600_stv090x_config.tuner_get_frequency =
ctl-tuner_get_frequency;
- tt1600_stv090x_config.tuner_set_bandwidth =
ctl-tuner_set_bandwidth;
- tt1600_stv090x_config.tuner_get_bandwidth =
ctl-tuner_get_bandwidth;
- tt1600_stv090x_config.tuner_set_bbgain=
ctl-tuner_set_bbgain;
- tt1600_stv090x_config.tuner_get_bbgain=
ctl-tuner_get_bbgain;
- tt1600_stv090x_config.tuner_set_refclk=
ctl-tuner_set_refclk;
- tt1600_stv090x_config.tuner_get_status=
ctl-tuner_get_status;
-
- dvb_attach(isl6423_attach,
- budget-dvb_frontend,
- budget-i2c_adap,
- tt1600_isl6423_config);
-
- } else {
- dvb_frontend_detach(budget-dvb_frontend);
- budget-dvb_frontend = NULL;
+ if (ctl) {
+ tt1600_stv090x_config.tuner_init
= ctl-tuner_init;
+ tt1600_stv090x_config.tuner_set_mode
= ctl-tuner_set_mode;
+
tt1600_stv090x_config.tuner_set_frequency = ctl-tuner_set_frequency;
+
tt1600_stv090x_config.tuner_get_frequency = ctl-tuner_get_frequency;
+
tt1600_stv090x_config.tuner_set_bandwidth = ctl-tuner_set_bandwidth;
+
tt1600_stv090x_config.tuner_get_bandwidth = ctl-tuner_get_bandwidth;
+ tt1600_stv090x_config.tuner_set_bbgain
= ctl-tuner_set_bbgain;
+ tt1600_stv090x_config.tuner_get_bbgain
= ctl-tuner_get_bbgain;
+ tt1600_stv090x_config.tuner_set_refclk
= ctl-tuner_set_refclk;
+ tt1600_stv090x_config.tuner_get_status
= ctl-tuner_get_status;
+
+ if (dvb_attach(isl6423_attach,
+ budget-dvb_frontend,
+ budget-i2c_adap,
+
Re: [PATCH] Fix Warning ISO C90 forbids mixed declarations and code - cx88-dvb
Signed-off-by: Ricardo Maraschini ricardo.marasch...@gmail.com --- a/linux/drivers/media/video/cx88/cx88-dvb.c Tue Mar 23 17:52:23 2010 -0300 +++ b/linux/drivers/media/video/cx88/cx88-dvb.c Wed Mar 24 09:57:06 2010 -0300 @@ -1401,8 +1401,6 @@ case CX88_BOARD_SAMSUNG_SMT_7020: dev-ts_gen_cntrl = 0x08; - struct cx88_core *core = dev-core; - cx_set(MO_GP0_IO, 0x0101); cx_clear(MO_GP0_IO, 0x01); -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 for v4l-dvb master] V4L/DVB: budget: Oops: BUG: unable to handle kernel NULL pointer dereference
Never call dvb_frontend_detach if we failed to attach a frontend. This fixes
the following oops:
[8.172997] DVB: registering new adapter (TT-Budget S2-1600 PCI)
[8.209018] adapter has MAC addr = 00:d0:5c:cc:a7:29
[8.328665] Intel ICH :00:1f.5: PCI INT B - GSI 17 (level, low) - IRQ
17
[8.328753] Intel ICH :00:1f.5: setting latency timer to 64
[8.562047] DVB: Unable to find symbol stv090x_attach()
[8.562117] BUG: unable to handle kernel NULL pointer dereference at 00ac
[8.562239] IP: [e08b04a3] dvb_frontend_detach+0x4/0x67 [dvb_core]
Ref http://bugs.debian.org/575207
Also clean up if we are unable to register the tuner and LNB drivers
Signed-off-by: Bjørn Mork bj...@mork.no
Reported-by: Fladischer Michael fladischermich...@fladi.at
---
This version should apply to to git://linuxtv.org/v4l-dvb.git master on
top of commit 30b8f0787e51a3ab0c447e0e3bf4aadc7caf9ffd.
It is otherwise identical to the v2 patch for the upstream and stable
kernel repositories.
drivers/media/dvb/ttpci/budget.c | 56 -
1 files changed, 30 insertions(+), 26 deletions(-)
diff --git a/drivers/media/dvb/ttpci/budget.c b/drivers/media/dvb/ttpci/budget.c
index fccb6ad..918679e 100644
--- a/drivers/media/dvb/ttpci/budget.c
+++ b/drivers/media/dvb/ttpci/budget.c
@@ -628,32 +628,36 @@ static void frontend_init(struct budget *budget)
tt1600_stv6110x_config,
budget-i2c_adap);
- tt1600_stv090x_config.tuner_init =
ctl-tuner_init;
- tt1600_stv090x_config.tuner_sleep =
ctl-tuner_sleep;
- tt1600_stv090x_config.tuner_set_mode =
ctl-tuner_set_mode;
- tt1600_stv090x_config.tuner_set_frequency =
ctl-tuner_set_frequency;
- tt1600_stv090x_config.tuner_get_frequency =
ctl-tuner_get_frequency;
- tt1600_stv090x_config.tuner_set_bandwidth =
ctl-tuner_set_bandwidth;
- tt1600_stv090x_config.tuner_get_bandwidth =
ctl-tuner_get_bandwidth;
- tt1600_stv090x_config.tuner_set_bbgain=
ctl-tuner_set_bbgain;
- tt1600_stv090x_config.tuner_get_bbgain=
ctl-tuner_get_bbgain;
- tt1600_stv090x_config.tuner_set_refclk=
ctl-tuner_set_refclk;
- tt1600_stv090x_config.tuner_get_status=
ctl-tuner_get_status;
-
- /* call the init function once to initialize
- tuner's clock output divider and demod's
- master clock */
- if (budget-dvb_frontend-ops.init)
-
budget-dvb_frontend-ops.init(budget-dvb_frontend);
-
- dvb_attach(isl6423_attach,
- budget-dvb_frontend,
- budget-i2c_adap,
- tt1600_isl6423_config);
-
- } else {
- dvb_frontend_detach(budget-dvb_frontend);
- budget-dvb_frontend = NULL;
+ if (ctl) {
+ tt1600_stv090x_config.tuner_init
= ctl-tuner_init;
+ tt1600_stv090x_config.tuner_sleep
= ctl-tuner_sleep;
+ tt1600_stv090x_config.tuner_set_mode
= ctl-tuner_set_mode;
+
tt1600_stv090x_config.tuner_set_frequency = ctl-tuner_set_frequency;
+
tt1600_stv090x_config.tuner_get_frequency = ctl-tuner_get_frequency;
+
tt1600_stv090x_config.tuner_set_bandwidth = ctl-tuner_set_bandwidth;
+
tt1600_stv090x_config.tuner_get_bandwidth = ctl-tuner_get_bandwidth;
+ tt1600_stv090x_config.tuner_set_bbgain
= ctl-tuner_set_bbgain;
+ tt1600_stv090x_config.tuner_get_bbgain
= ctl-tuner_get_bbgain;
+ tt1600_stv090x_config.tuner_set_refclk
= ctl-tuner_set_refclk;
+ tt1600_stv090x_config.tuner_get_status
= ctl-tuner_get_status;
+
+ /* call the init function once to
initialize
+ tuner's clock output divider and
demod's
+ master clock */
+ if (budget-dvb_frontend-ops.init)
+
[PATCH] Little fix on switch identation - cx88-dvb
Signed-off-by: Ricardo Maraschini ricardo.marasch...@gmail.com --- a/linux/drivers/media/video/cx88/cx88-dvb.c Tue Mar 23 17:52:23 2010 -0300 +++ b/linux/drivers/media/video/cx88/cx88-dvb.c Wed Mar 24 10:29:09 2010 -0300 @@ -1238,7 +1238,7 @@ fe-ops.tuner_ops.set_config(fe, ctl); } break; -case CX88_BOARD_PINNACLE_HYBRID_PCTV: + case CX88_BOARD_PINNACLE_HYBRID_PCTV: case CX88_BOARD_WINFAST_DTV1800H: fe0-dvb.frontend = dvb_attach(zl10353_attach, cx88_pinnacle_hybrid_pctv, -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Fix Warning ISO C90 forbids mixed declarations and code - cx88-dvb
Hello Ricardo, On Wed, Mar 24, 2010 at 10:27 AM, Ricardo Maraschini xrma...@gmail.com wrote: Signed-off-by: Ricardo Maraschini ricardo.marasch...@gmail.com --- a/linux/drivers/media/video/cx88/cx88-dvb.c Tue Mar 23 17:52:23 2010 -0300 +++ b/linux/drivers/media/video/cx88/cx88-dvb.c Wed Mar 24 09:57:06 2010 -0300 @@ -1401,8 +1401,6 @@ case CX88_BOARD_SAMSUNG_SMT_7020: dev-ts_gen_cntrl = 0x08; - struct cx88_core *core = dev-core; - cx_set(MO_GP0_IO, 0x0101); cx_clear(MO_GP0_IO, 0x01); This version seems ok to my eyes. Thanks Douglas -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] v4l: videobuf: code cleanup.
Mauro Carvalho Chehab wrote: Pawel Osciak wrote: Aguirre, Sergio wrote: Make videobuf pass checkpatch; minor code cleanups. I thought this kind patches were frowned upon.. http://www.mjmwired.net/kernel/Documentation/development-process/4.Coding#41 But maybe it's acceptable in this case... I'm not an expert on community policies :) Hm, right... I'm not an expert either, but it does seem reasonable. It was just a part of the roadmap we agreed on in Norway, so I simply went ahead with it. Merging with other patches would pollute them so I just posted it separately. I will leave the decision up to Mauro then. I have some more normal patches lined up, so please let me know. I'm guessing we are cancelling the clean-up then though. It is fine for me to send such patch in a series of changes. A pure CodingStyle patch is preferred if you're doing lots of changes, since it is very easy to review those changes. Yet, I generally hold pure CodingStyle changes to happen at the end of an rc cycle, to avoid conflicts with real patches, especially when the change is on a code that use to have lots of changes during a kernel cycle. In the specific case of videobuf, I prefer to merge any changes functional changes at the beginning of a -rc cycle, and after having several tested-by replies with different architectures and boards, as a trouble there will affect almost all drivers. I'm applying this CodingStyle fix to the tree. Better applying it sooner than later. Cheers, Mauro -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
we have marketing databases for sale
Email me at this address for a catalog of all our US lists: elma.h...@listpricereduction.co.cc Also, ask about our sale pricing for more than one list. to terminate please send a blank message to rem...@listpricereduction.co.cc -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
PCTV 73eSE driver not loaded
All, I am a Linux newbie trying to install a PCTV 73eSE DVB-T receiver, but the driver apparently does not get loaded. These are the 'cookbook' steps I followed: -Fresh Ubuntu 9.10 distribution installed. -kernel upgraded to 2.6.31-20-generic (using Ubuntu upgrade tool) -Mercurial installed -V4L-DVB kernel modules downloaded (source) -make (screen output attached) -make install -reboot (with the DVB-T USB dongle attached during boot) Outcome: -There is no /dev/dvb directory -/proc/modules does not list any relevant reference to the PCTV 73eSE USB dongle (apparently the correct driver for that should be the DIB0700 driver) Looking at the mailing list, there is some history on the PCTV 73eSE device: apparently this was originally owned by Pinnacle; the same device can have 2 different manuf ID's. Posts on the list (nov / dec 2009) point out that corrections have been done to support both manuf ID's. The relevant lsusb -v output is: Bus 001 Device 003: ID 2013:0245 Device Descriptor: bLength18 bDescriptorType 1 bcdUSB 2.00 bDeviceClass0 (Defined at Interface level) bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize064 idVendor 0x2013 idProduct 0x0245 bcdDevice1.00 iManufacturer 1 PCTV Systems iProduct2 PCTV 73e SE iSerial 3 000M99B4P6Q bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 46 bNumInterfaces 1 bConfigurationValue 1 iConfiguration 0 bmAttributes 0xa0 (Bus Powered) Remote Wakeup MaxPower 500mA Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber0 bAlternateSetting 0 bNumEndpoints 4 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass 0 bInterfaceProtocol 0 iInterface 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x01 EP 1 OUT bmAttributes2 Transfer TypeBulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 1 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x81 EP 1 IN bmAttributes2 Transfer TypeBulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 1 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x82 EP 2 IN bmAttributes2 Transfer TypeBulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 1 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x83 EP 3 IN bmAttributes2 Transfer TypeBulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 1 Device Qualifier (for other device speed): bLength10 bDescriptorType 6 bcdUSB 2.00 bDeviceClass0 (Defined at Interface level) bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize064 bNumConfigurations 1 Device Status: 0x (Bus Powered) The vendor ID in my case apparently is 0x2013. I am able to find back this ID in the source files (but I am not a programmer), so it looks as if this is not the reason why the driver doens't get loaded. Nevertheless, the 'automagic' part of udev seems to have abandoned me:) Any idea's to proceed on this? Thanks in advance, Luc Boschmans. Newtec’s MENOS system awarded IBC Innovation Award for Content Delivery the IBC Judges’ Award Newtec’s FlexACM awarded 2009 Teleport Technology of the Year by WTA *** e-mail confidentiality footer *** This message and any attachments thereto are confidential. They may also be privileged or otherwise protected by work product immunity or other legal rules. If you have received it by mistake, please let us know by e-mail reply and delete it from your system; you may not copy this message or disclose its contents to anyone. E-mail transmission cannot be guaranteed to be secure or error free as information could be intercepted, corrupted, lost, destroyed, arrive
Re: [PATCH v2] v4l: videobuf: code cleanup.
Mauro Carvalho Chehab wrote: Pawel Osciak wrote: Aguirre, Sergio wrote: Make videobuf pass checkpatch; minor code cleanups. I thought this kind patches were frowned upon.. http://www.mjmwired.net/kernel/Documentation/development-process/4.Coding#41 But maybe it's acceptable in this case... I'm not an expert on community policies :) Hm, right... I'm not an expert either, but it does seem reasonable. It was just a part of the roadmap we agreed on in Norway, so I simply went ahead with it. Merging with other patches would pollute them so I just posted it separately. I will leave the decision up to Mauro then. I have some more normal patches lined up, so please let me know. I'm guessing we are cancelling the clean-up then though. It is fine for me to send such patch in a series of changes. A pure CodingStyle patch is preferred if you're doing lots of changes, since it is very easy to review those changes. Yet, I generally hold pure CodingStyle changes to happen at the end of an rc cycle, to avoid conflicts with real patches, especially when the change is on a code that use to have lots of changes during a kernel cycle. In the specific case of videobuf, I prefer to merge any changes functional changes at the beginning of a -rc cycle, and after having several tested-by replies with different architectures and boards, as a trouble there will affect almost all drivers. I'm applying this CodingStyle fix to the tree. Better applying it sooner than later. Hooray! If time permits then I'll start a series of refactoring patches this weekend. I also have similar cleanup patches in my queue for v4l1 drivers that need to be converted to v4l2. I'll post a pull request for that as well during the weekend. Regards, Hans -- Hans Verkuil - video4linux developer - sponsored by TANDBERG Telecom -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: mmotm 2010-03-23-15-34 uploaded (staging vs. media)
On 03/23/10 15:34, a...@linux-foundation.org wrote: The mm-of-the-moment snapshot 2010-03-23-15-34 has been uploaded to http://userweb.kernel.org/~akpm/mmotm/ and will soon be available at git://zen-kernel.org/kernel/mmotm.git drivers/staging/cx25821/cx25821-video.c:89:struct cx25821_fmt *format_by_fourcc(unsigned int fourcc) (not static) conflicts with (has the same non-static name as) drivers/media/common/saa7146_video.c:87:struct saa7146_format* format_by_fourcc(struct saa7146_dev *dev, int fourcc) so when both of these drivers are built into the kernel image: (.text+0x6360): multiple definition of `format_by_fourcc' -- ~Randy -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Problems with ngene based DVB cards (Digital Devices Cine S2 Dual DVB-S2 , Mystique SaTiX S2 Dual)
Marco Lohse wrote: Marco Lohse wrote: Devin Heitmueller wrote: [..] Hi Marco, Ok, great. Like I said, I will see if I can reproduce it here, as that will help narrow down whether it's really an issue with the ngene bridge, or whether it's got something to do with that particular bridge/demod/tuner combination. We made some more tests and found some additional issues that we would like to report. Sorry, I forgot the attachment (modified szap-s2) Have fun, Marco *Problem A revisited * * It was suggested that due to a bug the dvr should never be closed (as a work-around) How does this affect channel tuning times? Test (using the latest version of the modified szap-s2) 0) su -c rmmod ngene modprobe ngene one_adapter=0 1) Run szap-s2 using a channels.conf with Das Erste and ZDF on different transponders szap-s2 -S 1 -H -c channels_DVB-S2_transponder_switch.conf -a 0 -n 1 -i reading channels from file 'channels_DVB-S2_transponder_switch.conf' Das Erste zapping to 1 'Das Erste': delivery DVB-S2, modulation QPSK sat 0, frequency 11836 MHz H, symbolrate 2750, coderate auto, rolloff 0.35 vpid 0x0065, apid 0x0066, sid 0x0068 using '/dev/dvb/adapter0/frontend0' and '/dev/dvb/adapter0/demux0' Opened frontend Opened video demux Opened audio demux status 1f | signal 69% | snr 67% | ber 1 | unc -2 | FE_HAS_LOCK Delay zap_to : 0.586872 ZDF zapping to 2 'ZDF': delivery DVB-S2, modulation QPSK sat 0, frequency 11953 MHz H, symbolrate 2750, coderate auto, rolloff 0.35 vpid 0x006e, apid 0x0078, sid 0x0082 status 1f | signal 67% | snr 63% | ber 1 | unc -2 | FE_HAS_LOCK Delay zap_to : 0.580473 Das Erste zapping to 1 'Das Erste': delivery DVB-S2, modulation QPSK sat 0, frequency 11836 MHz H, symbolrate 2750, coderate auto, rolloff 0.35 vpid 0x0065, apid 0x0066, sid 0x0068 status 1f | signal 69% | snr 67% | ber 1 | unc -2 | FE_HAS_LOCK Delay zap_to : 0.553754 = Good, you will see low tuning times. 2) in parallel to 1) - and without terminating 1) - run a second instance of szap-s2 that reads from the device szap-s2 -S 1 -H -c channels_DVB-S2_transponder_switch.conf -a 1 -n 1 -r reading channels from file 'channels_DVB-S2_transponder_switch.conf' zapping to 1 'Das Erste': delivery DVB-S2, modulation QPSK sat 0, frequency 11836 MHz H, symbolrate 2750, coderate auto, rolloff 0.35 vpid 0x0065, apid 0x0066, sid 0x0068 using '/dev/dvb/adapter1/frontend0' and '/dev/dvb/adapter1/demux0' Opened frontend Opened video demux Opened audio demux .. 3) while 2) is running, go back to 1) and tune to different transponders again: ZDF zapping to 2 'ZDF': delivery DVB-S2, modulation QPSK sat 0, frequency 11953 MHz H, symbolrate 2750, coderate auto, rolloff 0.35 vpid 0x006e, apid 0x0078, sid 0x0082 status 1f | signal 67% | snr 63% | ber 1 | unc -2 | FE_HAS_LOCK Delay zap_to : 1.774598 Das Erste zapping to 1 'Das Erste': delivery DVB-S2, modulation QPSK sat 0, frequency 11836 MHz H, symbolrate 2750, coderate auto, rolloff 0.35 vpid 0x0065, apid 0x0066, sid 0x0068 status 1f | signal 69% | snr 67% | ber 1 | unc -2 | FE_HAS_LOCK Delay zap_to : 1.772805 = Not good, whenver you use both tuners you will see tuning times to increase from approx. 0.5 secs to 1.7 secs. Was anyone able to reproduce the problem with the increased tuning times? Thank you for your comments. Have fun, Marco *Problem B revisited * * We also found that when reading data from the dvr device immediately after tuning was completed (e.g. the lock was successful), then approx. once in 50 iterations, we still get old data from the device. With old I mean from the transponder previously tuned to. This results, for example, in the wrong old PAT received first. Work-around: Simple and annoying. Add a sleep(1) before starting to read from device. *Remark* Both problems can _not_ be reproduced with any other board we tested (Tevii, KNC, ..) -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [Resubmit: PATCH-V2] Introducing ti-media directory
Laurent, Using a dedicated directory in drivers/media/video for TI-specific cores is definitely a good idea (assuming the same IP cores won't be used by other vendors in the future). If another vendor uses it in another SOC (assuming for discussion), then the driver should be re-used. So there shouldn't be another version of the driver right? So why is this an issue? My concern is that, if we move the ISP driver in drivers/media/video/ti- media, the directory will soon get quite crowded. If a new TI processor comes up with a totally incompatible ISP, we will get a name conflict in drivers/media/video/ti-media. I was thinking about either replacing the isp prefix with omap3isp (or similar), or moving the driver to drivers/media/video/ti-media/omap3isp, but that will impede code sharing code between the Davinci and OMAP processor families. That's where my uncertainty comes from. I think vpfe is used for DM devices which is equivalent to ISP in OMAP. omap3 CCDC/Previewer/Resizer/H3A is re-used from DM6446 CCDC or vice-versa. The ccdc is also re-used in AM35xxx OMAP device (excuse me if I wrote the name incorrectly) that Vaibhav is working on. So we might want to name it as just ccdc.c/resizer.c/previewer.c. Currently we have dm644x_ccdc.c under davinci for DM644x and dm355_ccdc.c for DM355. We need to sort out the differences in the driver and use a common ccdc.c on OMAP/DM644x/AM35xxx. I am not sure if we have any control on how hardware designers name the IP, and would have to deal with it as it happens. For new IPs that is considerably different, but share the same name might have to be named by adding some prefix/suffix as appropriate (example v1, v2 etc for different versions of the same IP, resizer.c for OMAP/DM644x/AM35xxx, resizer_v1.c for resizer on DM355). Myself and Vaibhav had discussed this in the past and ti-media is the generic name that we could agree on. On DM SoCs (DM6446, DM355, DM365) I expect ti-media to be the home for all vpfe and vpbe driver files. Since we had a case of common IP across OMAP and DMxxx SoCs, we want to place all OMAP and DMxxx video driver files in a common directory so that sharing the drivers across the SoCs will be easy. We could discuss and agree on another name if need be. Any suggestions? It's not the name ti-media that I don't agree on, it's just that this will move the problem one step further in the directory hierarchy without actually solving it :-) Is it guaranteed today that no TI processors with new generation video blocks will reuse the names ISP, VPFE and VPBE ? The OMAP3 datasheet refers to VPFE and VPBE, but luckily those blocks are further divided into subblocks, and the driver doesn't refer to the VPFE and VPBE directly. As discussed above, we will have to expect name conflicts in future and come up with some naming convention to name files(and add it to v4 documentation). I think this shouldn't prevent this patch from merging to the tree since you are okay with the name. I will send a pull request if you are okay with this patch. -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: mmotm 2010-03-23-15-34 uploaded (staging vs. media)
Hi Randy,
Randy Dunlap wrote:
On 03/23/10 15:34, a...@linux-foundation.org wrote:
The mm-of-the-moment snapshot 2010-03-23-15-34 has been uploaded to
http://userweb.kernel.org/~akpm/mmotm/
and will soon be available at
git://zen-kernel.org/kernel/mmotm.git
drivers/staging/cx25821/cx25821-video.c:89:struct cx25821_fmt
*format_by_fourcc(unsigned int fourcc)
(not static)
conflicts with (has the same non-static name as)
drivers/media/common/saa7146_video.c:87:struct saa7146_format*
format_by_fourcc(struct saa7146_dev *dev, int fourcc)
so when both of these drivers are built into the kernel image:
(.text+0x6360): multiple definition of `format_by_fourcc'
The cx25821 driver is capable of simultaneously handling 8 video inputs at the
same time,
and 4 video outputs. However, the way it does is by duplicating exactly the
same code
8 times, for input, and 4 times, for the output.
Due to that, several symbols that should normally be internal to the driver's
code are
exported (see the huge exports list at drivers/staging/cx25821/cx25821-video.h).
The proper fix is to remove all those duplicated code, adding one parameter
into the
board struct, with the number of the video input or output.
While this won't happen, I'll add a patch at the tree, renaming its symbols to
contain
cx28521 with this small script:
cat drivers/staging/cx25821/cx25821-video.h|perl -ne 'if (m/extern.*
([^\s\*]+)\(/) { $n=$1; print s/([^\d\w_\.])$1/\\1cx25821_$1/g;\n if (!($n =~
m/cx25821/)); }' changes; for i in drivers/staging/cx25821/*.[ch]; do sed -r
-f changes $i a mv a $i; done
Cheers,
Mauro
---
As reference, those are the only differences between each cx25821-video[0-7].c:
--- drivers/staging/cx25821/cx25821-video1.c2010-01-28 19:23:33.0
-0200
+++ drivers/staging/cx25821/cx25821-video2.c2010-01-28 19:23:33.0
-0200
@@ -30,7 +30,7 @@ static void buffer_queue(struct videobuf
struct cx25821_buffer *prev;
struct cx25821_fh *fh = vq-priv_data;
struct cx25821_dev *dev = fh-dev;
- struct cx25821_dmaqueue *q = dev-vidq[SRAM_CH01];
+ struct cx25821_dmaqueue *q = dev-vidq[SRAM_CH02];
/* add jump to stopper */
buf-risc.jmp[0] = cpu_to_le32(RISC_JUMP | RISC_IRQ1 | RISC_CNT_INC);
@@ -48,7 +48,7 @@ static void buffer_queue(struct videobuf
} else if (list_empty(q-active)) {
list_add_tail(buf-vb.queue, q-active);
cx25821_start_video_dma(dev, q, buf,
- dev-sram_channels[SRAM_CH01]);
+ dev-sram_channels[SRAM_CH02]);
buf-vb.state = VIDEOBUF_ACTIVE;
buf-count = q-count++;
mod_timer(q-timeout, jiffies + BUFFER_TIMEOUT);
@@ -120,7 +120,7 @@ static int video_open(struct file *file)
else
fh-height = 480;
- dev-channel_opened = SRAM_CH01;
+ dev-channel_opened = SRAM_CH02;
pix_format =
(dev-pixel_formats[dev-channel_opened] ==
PIXEL_FRMT_411) ? V4L2_PIX_FMT_Y41P : V4L2_PIX_FMT_YUYV;
@@ -147,7 +147,7 @@ static ssize_t video_read(struct file *f
switch (fh-type) {
case V4L2_BUF_TYPE_VIDEO_CAPTURE:
- if (res_locked(fh-dev, RESOURCE_VIDEO1))
+ if (res_locked(fh-dev, RESOURCE_VIDEO2))
return -EBUSY;
return videobuf_read_one(fh-vidq, data, count, ppos,
@@ -165,7 +165,7 @@ static unsigned int video_poll(struct fi
struct cx25821_fh *fh = file-private_data;
struct cx25821_buffer *buf;
- if (res_check(fh, RESOURCE_VIDEO1)) {
+ if (res_check(fh, RESOURCE_VIDEO2)) {
/* streaming capture */
if (list_empty(fh-vidq.stream))
return POLLERR;
@@ -183,7 +183,7 @@ static unsigned int video_poll(struct fi
if (buf-vb.state == VIDEOBUF_DONE) {
struct cx25821_dev *dev = fh-dev;
- if (dev dev-use_cif_resolution[SRAM_CH01]) {
+ if (dev dev-use_cif_resolution[SRAM_CH02]) {
u8 cam_id = *((char *)buf-vb.baddr + 3);
memcpy((char *)buf-vb.baddr,
(char *)buf-vb.baddr + (fh-width * 2),
@@ -204,12 +204,12 @@ static int video_release(struct file *fi
struct cx25821_dev *dev = fh-dev;
//stop the risc engine and fifo
- cx_write(channel1-dma_ctl, 0); /* FIFO and RISC disable */
+ cx_write(channel2-dma_ctl, 0); /* FIFO and RISC disable */
/* stop video capture */
- if (res_check(fh, RESOURCE_VIDEO1)) {
+ if (res_check(fh, RESOURCE_VIDEO2)) {
videobuf_queue_cancel(fh-vidq);
- res_free(dev, fh, RESOURCE_VIDEO1);
+ res_free(dev, fh, RESOURCE_VIDEO2);
}
if (fh-vidq.read_buf)
Re: [GIT FIX for 2.6.34] V4L - vpfe capture - fix for kernel crash on DM365
Hi Murali, Karicheri, Muralidharan wrote: Please discard this patch. I have sent an updated version to the list. The patch were already added at the fixes tree. I can't just discard, since this would break any other tree based on it. If the patch is so deadly broken, then we can add a rollback patch, making our and upstream tree dirty. Another alternative would be to add just a diff between the two patches. Btw, please send me a patchwork ID when you want to refer to a patch sent to the mailing list, especially when there are two patches with the same name. Is this the one you're referring? X-Patchwork-Id: 86729 Cheers, Mauro. -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[cron job] v4l-dvb daily build 2.6.22 and up: ERRORS, 2.6.16-2.6.21: WARNINGS
This message is generated daily by a cron job that builds v4l-dvb for the kernels and architectures in the list below. Results of the daily build of v4l-dvb: date:Wed Mar 24 19:00:20 CET 2010 path:http://www.linuxtv.org/hg/v4l-dvb changeset: 14512:5b152630ae7c git master: f6760aa024199cfbce564311dc4bc4d47b6fb349 git media-master: 8c69c6ed6c74c94fa7ad6fa24eda452e4b212d81 gcc version: i686-linux-gcc (GCC) 4.4.3 host hardware:x86_64 host os: 2.6.32.5 linux-2.6.32.6-armv5: OK linux-2.6.33-armv5: OK linux-2.6.34-rc1-armv5: OK linux-2.6.32.6-armv5-davinci: WARNINGS linux-2.6.33-armv5-davinci: WARNINGS linux-2.6.34-rc1-armv5-davinci: WARNINGS linux-2.6.32.6-armv5-ixp: WARNINGS linux-2.6.33-armv5-ixp: WARNINGS linux-2.6.34-rc1-armv5-ixp: WARNINGS linux-2.6.32.6-armv5-omap2: WARNINGS linux-2.6.33-armv5-omap2: WARNINGS linux-2.6.34-rc1-armv5-omap2: WARNINGS linux-2.6.22.19-i686: WARNINGS linux-2.6.23.17-i686: WARNINGS linux-2.6.24.7-i686: WARNINGS linux-2.6.25.20-i686: WARNINGS linux-2.6.26.8-i686: WARNINGS linux-2.6.27.44-i686: WARNINGS linux-2.6.28.10-i686: WARNINGS linux-2.6.29.1-i686: WARNINGS linux-2.6.30.10-i686: WARNINGS linux-2.6.31.12-i686: WARNINGS linux-2.6.32.6-i686: WARNINGS linux-2.6.33-i686: WARNINGS linux-2.6.34-rc1-i686: WARNINGS linux-2.6.32.6-m32r: OK linux-2.6.33-m32r: OK linux-2.6.34-rc1-m32r: OK linux-2.6.32.6-mips: WARNINGS linux-2.6.33-mips: WARNINGS linux-2.6.34-rc1-mips: WARNINGS linux-2.6.32.6-powerpc64: WARNINGS linux-2.6.33-powerpc64: WARNINGS linux-2.6.34-rc1-powerpc64: WARNINGS linux-2.6.22.19-x86_64: WARNINGS linux-2.6.23.17-x86_64: WARNINGS linux-2.6.24.7-x86_64: WARNINGS linux-2.6.25.20-x86_64: WARNINGS linux-2.6.26.8-x86_64: WARNINGS linux-2.6.27.44-x86_64: WARNINGS linux-2.6.28.10-x86_64: WARNINGS linux-2.6.29.1-x86_64: WARNINGS linux-2.6.30.10-x86_64: WARNINGS linux-2.6.31.12-x86_64: WARNINGS linux-2.6.32.6-x86_64: WARNINGS linux-2.6.33-x86_64: WARNINGS linux-2.6.34-rc1-x86_64: WARNINGS linux-git-armv5: OK linux-git-armv5-davinci: OK linux-git-armv5-ixp: OK linux-git-armv5-omap2: OK linux-git-i686: WARNINGS linux-git-m32r: OK linux-git-mips: OK linux-git-powerpc64: WARNINGS linux-git-x86_64: WARNINGS spec: ERRORS spec-git: OK sparse: ERRORS linux-2.6.16.62-i686: WARNINGS linux-2.6.17.14-i686: WARNINGS linux-2.6.18.8-i686: WARNINGS linux-2.6.19.7-i686: WARNINGS linux-2.6.20.21-i686: WARNINGS linux-2.6.21.7-i686: WARNINGS linux-2.6.16.62-x86_64: WARNINGS linux-2.6.17.14-x86_64: WARNINGS linux-2.6.18.8-x86_64: WARNINGS linux-2.6.19.7-x86_64: WARNINGS linux-2.6.20.21-x86_64: WARNINGS linux-2.6.21.7-x86_64: WARNINGS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Wednesday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Wednesday.tar.bz2 The V4L-DVB specification from this daily build is here: http://www.xs4all.nl/~hverkuil/spec/media.html -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-dvb] saa716x driver status
Am Mittwoch, den 24.03.2010, 21:45 +1100 schrieb Rodd Clarkson: Hi All, I've recently acquired a AverMedia Hybrid NanoExpress tv tuner and I'm trying to get it working with Fedora 13 and Fedora 12. I've found drivers at http://www.jusst.de/hg/saa716x/ On f12 the driver build and install, but I have missing symbols when I try to modprobe the drivers. On f13 the drivers fail to build. I've tried contacting Manu Abraham (whom I believe is the developer) about the f12 issues, but haven't heard back. I've searched google for everything from saa716x, AverMedia Hybrid Nano Express, HC82 and 1461:0555 (the pci address, I guess). There's bits and pieces about this driver in the results, but most are that they can build the driver, but it doesn't work. I'm happy to 'risk' my card and try stuff to get this to work, but I'm curious about whether or not development is ongoing and how I can help (not being a c coder) I'll attach the output of the build attempt on f13 in case someone can advise what is going wrong. The build log was captured using: $ make /tmp/saa716x.build.log.f13 regards Rodd ___ linux-dvb users mailing list For V4L/DVB development, please use instead linux-media@vger.kernel.org linux-...@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb Hi, i have a avertv hybrid nano express over here and managed to solve some build problems by copying some v4l files into the downloaded directories. but after installation finished succesfully, the driver unfortunately didnt work. so if you have any success please let me know regards martin -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [GIT FIX for 2.6.34] V4L - vpfe capture - fix for kernel crash on DM365
Mauro, Please discard this patch. I have sent an updated version to the list. The patch were already added at the fixes tree. I can't just discard, since this would break any other tree based on it. Ok. If the patch is so deadly broken, then we can add a rollback patch, making our and upstream tree dirty. Another alternative would be to add just a diff between the two patches. Not broken. I can send you another patch for adding the diff. Btw, please send me a patchwork ID when you want to refer to a patch sent to the mailing list, especially when there are two patches with the same name. Is this the one you're referring? X-Patchwork-Id: 86729 Yes. That is the one. I will send you a diff patch. Sorry for the trouble. Cheers, Mauro. -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[GIT PATCHES FOR 2.6.34] vtx feature removal, Kconfig fixes, saa7146 regression fix
The following changes since commit a8f0df5fc2bc2e0aa0ead578bb93214915573efd: Michael Hunold (1): V4L/DVB: saa7146: fix up bytesperline if it is an impossible value are available in the git repository at: ssh://linuxtv.org/git/hverkuil/fixes.git new-fixes Hans Verkuil (3): feature-removal: announce videotext.h removal. v4l: fix config dependencies: mxb and saa7191 are V4L2 drivers, not V4L1 saa7146: fix regression of the av7110/budget-av driver Documentation/feature-removal-schedule.txt | 21 + drivers/media/common/saa7146_fops.c| 11 +-- drivers/media/video/Kconfig|4 ++-- drivers/media/video/hexium_gemini.c|3 --- drivers/media/video/hexium_orion.c |4 drivers/media/video/mxb.c | 17 - include/media/saa7146_vv.h |1 - 7 files changed, 36 insertions(+), 25 deletions(-) -- Hans Verkuil - video4linux developer - sponsored by TANDBERG -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Which of my 3 video capture devices will work best with my PC?
Greetings all... I'm interested in doing video transfer from VCR to PC and want to know which of the 3 capture devices I have has the best chance of working with my setup? I have 3 different symptoms happening with each. My PC setup: Ubuntu Karmic 9.10/2.6.31-20 generic Socket 754 AMD Sempron 3000+ with passive cooling (non AMD64) Biostar MB with Nforce3 250Gb chipset NV31 GPU (Geforce FX5600 Ultra 128MB) using Nvidia 196 driver 1GB PC3200 DDR RAM 34GB SCSI coupled to a Adaptec 19160 card Soundblaster Audigy dvd+-R floppy etc etc. The devices in question: USB: Dazzle Digital Photo Maker, using a USBvision driver recognized as a Global Village GV-7000) --This one recognizes and I can display video but if I try to record in either xawtv or Kdenlive the program crashes. PCI: Hauppauge WinTV model 38101 --When installed it shows /dev/video0 when I do an ls, but I don't get a signal with either composite or coax input. I tried following steps from this link http://howtoubuntu.org/?p=20 but it didn't change a thing... PCI: Aurora Systems Fuse previously used on a Mac --This card picks up the ZR36067 driver, but it's saying it can't initialize the i2c bus. Thus, no /dev/video* shows Let me know which I should focus on and then I'll show the query dumps. Any help on this would be greatly appreciated. ~Serge -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[GIT PATCHES FOR 2.6.35] V4L1 cleanups
These patches prepare the way to convert these old drivers to V4L2. I have patches available that build on these cleanups to do the actual conversion from V4L1 to V4L2 for c-qcam, bw-qcam, arv and w9966, but I need to review them first. The pms change is just a fix and the zoran and meye patches remove some last V4L1 data structure usages from these drivers. Regards, Hans The following changes since commit 942ab4762505a51a7a433a7608ba5d3eed6e4f8b: Jean Delvare (1): V4L/DVB: saa7134: Fix IR support of some ASUS TV-FM 7135 variants are available in the git repository at: ssh://linuxtv.org/git/hverkuil/v4l-dvb.git v4l1 Hans Verkuil (10): c-qcam: coding style cleanup bw-qcam: coding style cleanup arv: coding style cleanup w9966: coding style cleanup v4l: add V4L2_PIX_FMT_Y4 and V4L2_PIX_FMT_Y6 pixelformats pms: remove unnecessary exclusive open/close w9966: reorganize the order of functions w9966: remove camelCase meye: remove last V4L1 remnants from the code and add v4l2_device zoran: remove V4L1 videodev.h include Documentation/DocBook/v4l/pixfmt.xml | 12 + drivers/media/video/Kconfig |2 +- drivers/media/video/arv.c| 153 +++--- drivers/media/video/bw-qcam.c| 452 ++--- drivers/media/video/c-qcam.c | 483 +++--- drivers/media/video/meye.c | 78 ++- drivers/media/video/meye.h | 10 +- drivers/media/video/pms.c| 18 - drivers/media/video/w9966.c | 1074 ++ drivers/media/video/zoran/zoran.h| 24 +- drivers/media/video/zoran/zoran_driver.c | 16 +- include/linux/meye.h | 12 +- include/linux/videodev2.h|2 + 13 files changed, 1122 insertions(+), 1214 deletions(-) -- Hans Verkuil - video4linux developer - sponsored by TANDBERG -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Which of my 3 video capture devices will work best with my PC?
--This one recognizes and I can display video but if I try to record in either xawtv or Kdenlive the program crashes. Try to use/adapt this script at v4l-utils git tree(http://git.linuxtv.org/v4l-utils.git) contrib/v4l_rec.pl It basically uses either mencoder or ffmpeg to generate an mpeg encoded stream from a video analog capture device. -- Cheers, Mauro -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] pwc Kconfig dependency fix
makes USB_PWC_INPUT_EVDEV to depend also on USB_PWC Signed-off-by: Christoph Fritz chf.fr...@googlemail.com --- drivers/media/video/pwc/Kconfig |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/media/video/pwc/Kconfig b/drivers/media/video/pwc/Kconfig index 340f954..11980db 100644 --- a/drivers/media/video/pwc/Kconfig +++ b/drivers/media/video/pwc/Kconfig @@ -39,7 +39,7 @@ config USB_PWC_DEBUG config USB_PWC_INPUT_EVDEV bool USB Philips Cameras input events device support default y - depends on USB_PWC=INPUT || INPUT=y + depends on USB_PWC (USB_PWC=INPUT || INPUT=y) ---help--- This option makes USB Philips cameras register the snapshot button as an input device to report button events. -- 1.5.6.5 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
