Re: [PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-core2
On Monday 17 August 2009 02:49:01 Mauro Carvalho Chehab wrote: Em Sat, 15 Aug 2009 11:18:20 +0200 Hans Verkuil hverk...@xs4all.nl escreveu: On Saturday 15 August 2009 10:59:19 Hans Verkuil wrote: On Tuesday 11 August 2009 08:35:47 Hans Verkuil wrote: Hi Mauro, Please pull from http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-core2 for the following: - v4l: simplify v4l2_i2c_new_subdev and friends - v4l: remove video_register_device_index The first patch simplifies v4l2_i2c_new_subdev and removes v4l2_i2c_new_probed_subdev and v4l2_i2c_new_probed_subdev_addr. This was initially proposed for inclusion in 2.6.31 but that was considered too soon. I think it is now a good time to merge this so this will go into 2.6.32. The second patch removes the unused video_register_device_index function. This patch is part of a larger series of patches I'm working on to improve v4l2-dev.c. But since this patch is pretty straightforward I like to get this one in first. Mauro, Please disregard this pull request. I've found a serious bug that needs to be resolved first. OK, that was a false alarm. It's working fine after all so it's safe to pull this tree. Sorry for the confusion. The patches look fine to me. Yet, I see two merge conflict issues: 1) if a latter patch needs to touch at the subdev probing sequence to fix a bug, it will conflict with this patch, meaning that we'll have merge troubles on this tree and at my -git devel, linux-next and linux-2.6; 2) as Guennadi is converting soc_camera to v4l2 dev/subdev, this patch may conflict with his patch series. Due to that, I prefer to keep holding it until the beginning of the next merge window, since, if a merge conflict would rise, it would be just at -hg, instead of having it at the 4 trees. I thought things were pretty stable by now since we reached -rc6. And we have seen no bugs at all with respect to the subdev API. The disadvantage of waiting that long is that this patch has had no testing in v4l-dvb but goes straight into the mainline. I personally prefer to have it in earlier so it gets a few weeks testing before the merge window opens. Anyway, that's just my opinion. In the meantime, can you at least merge the second patch (remove video_register_device_index)? I can make a new tree if you don't want to cherry-pick it. 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: [PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-core2
On Sun, 16 Aug 2009, Mauro Carvalho Chehab wrote: The patches look fine to me. Yet, I see two merge conflict issues: 1) if a latter patch needs to touch at the subdev probing sequence to fix a bug, it will conflict with this patch, meaning that we'll have merge troubles on this tree and at my -git devel, linux-next and linux-2.6; 2) as Guennadi is converting soc_camera to v4l2 dev/subdev, this patch may conflict with his patch series. ...speaking about which, we should at some point start merging the soc-camera patch stack, which, however, requires some patches that are currently in next. Shall we pull those into the hg trees with the kernel-sync tag? The only issue then is, that we will have to remember to push the patches to Linus in the 2.6.32 merge window after those 3 patches are there. The patches update 3 PXA platforms to the new soc-camera API. Due to that, I prefer to keep holding it until the beginning of the next merge window, since, if a merge conflict would rise, it would be just at -hg, instead of having it at the 4 trees. Thanks Guennadi --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer http://www.open-technology.de/ -- 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
Hauppauge 2250 - second tuner is only half working
Hello, I've run into a problem with my capture card and wanted to solicit ideas on how to further pinpoint the problem and/or hopefully correct it. At the risk of being to presumptious/terse - my problem is the second tuner on the card is unable to lock on any frequency between 609mhz and 693mhz (while the first tuner does just fine). I recently purchased a bunch of hardware and assembled a HTPC. I'm running a fairly vanilla mythbuntu on it. I have only the one capture card installed, and i'm using comcast cable for input. Other than a handful of various apt packages i've added, i've compiled from source saa7164-dev branch (was on the -stable at one point), lcdproc-0.5.2 w/ imonlcd-0.3.patch, lirc (trunk), scte65scan, and a couple other tools. Unfortunately for me, I ran across the problem right after I did a big db merge on my mythtv's channel dtv_multiplex tables (I was joining schedules direct, scte65scan results, and dvb-app scan results). Naturally, i started troubleshooting from that point under the assumption i screwed up the tables. I eventually worked my way down to where i'm stuck at now - the second tuner mysteriously is unable to lock into some frequencies. I ran full scans (us-Cable-Standard-center-frequencies-QAM256) on both adapters - then sort -t : -k 2n -k 6n the output on both and diffed and ended up with the 609 and 693mhz numbers from above - all frequencies in that range are not tuneable for adapter1. It represents 109 tunable channels on adapter0 that just don't seem to work on adapter1 (there are about 250 that do work on both adapters properly). I spot checked at least a dozen channels in both the problem frequency range and in the good range (i used mythtv live tv and azap w/ dvbtraffic). dvbtraffic showed hundreds of lines of small bandwidth channels on the problem frequency range on adapter1 (For brevity sake, i simplified my scan list down to two channels to make it easier to test) channels.conf contains: KOMO:55500:QAM_256:1984:1985:3 SYFY:66900:QAM_256:2112:2113:7 s...@dh101:~/development/dvb-apps/dvb-apps_hg_co/util/szap$ ./azap -a 1 -c channels.conf komo using '/dev/dvb/adapter1/frontend0' and '/dev/dvb/adapter1/demux0' tuning to 55500 Hz video pid 0x07c0, audio pid 0x07c1 status 00 | signal | snr | ber | unc | status 1f | signal 0186 | snr 0186 | ber | unc | FE_HAS_LOCK status 1f | signal 0186 | snr 0186 | ber | unc | FE_HAS_LOCK ^C s...@dh101:~/development/dvb-apps/dvb-apps_hg_co/util/szap$ ./azap -a 0 -c channels.conf komo using '/dev/dvb/adapter0/frontend0' and '/dev/dvb/adapter0/demux0' tuning to 55500 Hz video pid 0x07c0, audio pid 0x07c1 status 00 | signal | snr | ber | unc | status 1f | signal 0190 | snr 0190 | ber | unc | FE_HAS_LOCK status 1f | signal 0190 | snr 0190 | ber | unc | FE_HAS_LOCK ^C s...@dh101:~/development/dvb-apps/dvb-apps_hg_co/util/szap$ ./azap -a 1 -c channels.conf syfy using '/dev/dvb/adapter1/frontend0' and '/dev/dvb/adapter1/demux0' tuning to 66900 Hz video pid 0x0840, audio pid 0x0841 status 00 | signal | snr | ber | unc | status 00 | signal | snr | ber | unc | status 00 | signal | snr | ber | unc | status 00 | signal | snr | ber | unc | status 00 | signal | snr | ber | unc | I've let it sit for 5+ min without lock ^C s...@dh101:~/development/dvb-apps/dvb-apps_hg_co/util/szap$ ./azap -a 0 -c channels.conf syfy using '/dev/dvb/adapter0/frontend0' and '/dev/dvb/adapter0/demux0' tuning to 66900 Hz video pid 0x0840, audio pid 0x0841 status 00 | signal | snr | ber | unc | status 1f | signal 0190 | snr 0190 | ber 0147 | unc 0147 | FE_HAS_LOCK status 1f | signal 0190 | snr 0190 | ber | unc | FE_HAS_LOCK dmesg output: [74217.307056] saa7164 driver loaded [74217.307106] saa7164 :03:00.0: PCI INT A - Link[AE3A] - GSI 16 (level, low) - IRQ 16 [74217.307944] CORE saa7164[0]: subsystem: 0070:8891, board: Hauppauge WinTV-HVR2250 [card=7,autodetected] [74217.307950] saa7164[0]/0: found at :03:00.0, rev: 129, irq: 16, latency: 0, mmio: 0xe500 [74217.307957] saa7164 :03:00.0: setting latency timer to 64 [74217.308710] saa7164[0]: i2c bus 0 registered [74217.308886] saa7164[0]: i2c bus 1 registered [74217.309069] saa7164[0]: i2c bus 2 registered [74217.343459] tveeprom 0-: Hauppauge model 88061, rev C3F2, serial# 6254250 [74217.343462] tveeprom 0-: MAC address is 00-0D-FE-5F-6E-AA [74217.343464] tveeprom 0-: tuner model is NXP 18271C2_716x (idx 152, type 4) [74217.343466] tveeprom 0-: TV standards NTSC(M) ATSC/DVB Digital (eeprom 0x88) [74217.343468] tveeprom 0-: audio processor is SAA7164 (idx 43) [74217.343470] tveeprom 0-: decoder processor
[Q] sensors, corrupting the top line
Hi Hans, all In soc-camera since its first version we have a parameter y_skip_top, which the sensor uses to tell the host (bridge) driver I am sending you that many lines more than what is requested, and you should drop those lines from the top of the image. I never investigated this in detail, originally this was a strong tip that the top line is always corrupted. Now I did investigate it a bit by setting this parameter to 0 and looking what the sensors actually produce. I am working with four sensor: mt9m001, mt9v022, mt9t031 and ov7725, of which only the first two had that parameter set to 1 from the beginning, the others didn't have it and also showed no signs of a problem. mt9m001 (monochrome) doesn't have the problem either, but mt9v022 does. It does indeed deliver the first line with randomly coloured pixels. Notice - this is not the top line of the sensor, this is the first read-out line, independent of the cropping position. So, it seems we do indeed need a way to handle such sensors. Do you have a suggestion for a meaningful v4l2-subdev API for this? Thanks Guennadi --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer http://www.open-technology.de/ -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: PULL request - http://linuxtv.org/hg/~pb/v4l-dvb/
Hi, in addition there is now: DiB0070: Update to latest internal release DiB0070: Indenting driver with indent -linux DiB8000: added support for DiBcom ISDB-T/ISDB-Tsb demodulator DiB8000 DiB0700: add support for STK807XP and STK807XPVR regards, -- Patrick Boettcher - Kernel Labs http://www.kernellabs.com/ On Fri, 14 Aug 2009, Patrick Boettcher wrote: Hi Mauro, can you please pull from http://linuxtv.org/hg/~pb/v4l-dvb/ for - ISDB-T: add mapping of LAYER_ENABLED to frontend-cache - ISDB-T: added reference to ARIB TR-B14 - ISDB-T: added bandwidth as an optional parameter - ISDB-T: Added note about DTV_FREQUENCY - DVB-API: add support for ISDB-T and ISDB-Tsb (version 5.1) In addition to that I have an ISDB-T demodulator driver ready (including device-support of course) and have modified 'scan' in dvb-apps to use the interface to scan for ISDB-T channels (can be used as an example showing how to tune ISDB-T) I'm looking forward to issue a pull request for that as well, but first I would like to have the API merged. I'm aware that the RFC was quite silent (thanks to Mike and Akihiro for commenting) - I'm taking that as a no-objection on the current implementation. I think binary compatibity is not broken, so applications compiled for DVB API 5.0 will continue to work without problems. I think that the 3 months from now on are enough time to fix up possibly bad things before a next kernel release (2.6.32). A pull would also widen the testers range, which I'm strongly depending on. thanks, -- Patrick Boettcher - Kernel Labs http://www.kernellabs.com/ -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- 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: usb dvb-c tuner status
Hello all, Can anyone confirm that the TT-connectR CT-3650 works with dvb-c with the current linux kernel? Regards, Bert -- 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
VPFE (v2) and VPIF capture patches for merge
Hans, Last week, I had sent vpfe capture (v2) and vpif capture(v1) patches for review. If they look good, please merge them to your tree and send a pull request to Mauro at your earliest convenience. Thanks. Murali Karicheri Software Design Engineer Texas Instruments Inc. Germantown, MD 20874 new phone: 301-407-9583 Old Phone : 301-515-3736 (will be deprecated) email: m-kariche...@ti.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: framebuffer overlay
I have another question. Has there been any discussion on any type of generic framebuffer v4l2 device (output device), like a gstreamer sink (like the soc_camera)? From this perspective, when the frame buffer registers itself, it could just *add* the capabilities, and allow the fb.c to handle many of the logistics. I am developing for a system where we do not use X and use the framebuffer directly (E17). It would be nice to fit any of the framebuffers into a *neat* v4l2 package for any app to use (gstreamer, mplayer). And with our camera, gstreamer, etc. could just be a command line away from live streaming :) Thanks, Ryan Dongsoo, Nathaniel Kim wrote: On Wed, Aug 12, 2009 at 5:56 PM, Ryan Raaschryan.raa...@gmail.com wrote: Thanks for the reply! Dongsoo, Nathaniel Kim wrote: On Wed, Aug 12, 2009 at 5:25 PM, Ryan Raaschryan.raa...@gmail.com wrote: Hello, I am trying to write a driver for a camera using the new soc_camera in the mainline kernel the output is the overlay framebuffer (pxa270) and i would like to use the overlay output feature of v4l2 framework, but the framebuffer does not expose itself as a output device (not yet). Hi Ryan, As far as I know the framebuffer of PXA2 even PXA3 can't be categorized in a overlay device. The pxa2 and pxa3 both have 3 framebuffers (4 if hardware curser included). There is the main fb, and 2 overlay framebuffers. The overlay 2 has hardware accelerated ycbcr decoding (which i use now with a camera using dma). And the overlay 1 can be used only with the various types of RGB. We have a solution which uses dma to copy the captured video from the camera sensor (mmap'd), directly to the mmap'd memory of the overlay. All occuring without user intervention. To be able to get used as overlay device by camera interface, I think there should be a direct FIFO between camera and framebuffer which means there is no need to copy memory from camera to fb. But unfortunately PXA architecture is not supporting this kind of feature. With the above there is no need for FIFO, the dma is directly copying the received camera data to the selected framebuffer. Ryan Cool. So, that means you need a SoC hardware based reference code right? (because pxa is also a SoC) I think there is not so many choices that you can put on the table. In my experience, OMP3 camera interface is supporting overlay feature through omap_vout I guess. I think it is not obvious in SoC H/W platform about *what is overlay device* and *how to use* them. And about omap3 camera interface driver, it is not in the mainline kernel yet. For the camera interface code you need to look into Sakari's gitorious repository and for omap_vout you need to look for Hardik's repository or any repository he is working on..I guess. I'm also trying to figure out the best way to use overlay feature on samsung's new cpu named S5PC1XX. The most complicated part of this job is the whole thing is happening in a single piece of chip and need to figure out the standardized way for compatibility. I wish you luck :-) Cheers, Nate Cheers, Nate Are there any fb that i can use as an example for this? From looking at the driver code, it seems like the generic code of fbmem.c needs a v4l2 device. Is this in the right ballpark? Thanks, Ryan -- video4linux-list mailing list Unsubscribe mailto:video4linux-list-requ...@redhat.com?subject=unsubscribe https://www.redhat.com/mailman/listinfo/video4linux-list -- 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 v1 - 1/5] DaVinci - restructuring code to support vpif capture driver
Hans, They are applied against davinci tree (also mentioned in the patch). General procedure what I follow is to create platform code against davinci tree and v4l patches against v4l-dvb linux-next tree. The architecture part of linux-next is not up to date. Davinci tree is at git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-davinci.git Murali Karicheri Software Design Engineer Texas Instruments Inc. Germantown, MD 20874 new phone: 301-407-9583 Old Phone : 301-515-3736 (will be deprecated) email: m-kariche...@ti.com -Original Message- From: Hans Verkuil [mailto:hverk...@xs4all.nl] Sent: Saturday, August 15, 2009 8:10 AM To: Karicheri, Muralidharan Cc: linux-media@vger.kernel.org; davinci-linux-open- sou...@linux.davincidsp.com; khil...@deeprootsystems.com Subject: Re: [PATCH v1 - 1/5] DaVinci - restructuring code to support vpif capture driver On Friday 14 August 2009 23:01:41 m-kariche...@ti.com wrote: From: Muralidharan Karicheri m-kariche...@ti.com This patch makes the following changes:- 1) Modify vpif_subdev_info to add board_info, routing information and vpif interface configuration. Remove addr since it is part of board_info 2) Add code to setup channel mode and input decoder path for vpif capture driver Also incorporated comments against version v0 of the patch series and added a spinlock to protect writes to common registers A quick question: against which git tree are these arch changes applied? I've lost track of that :-) 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: KWorld UB435-Q support?
On Aug 14, 2009, at 11:03 AM, Thomas Fjellstrom wrote: On Fri August 14 2009, Jarod Wilson wrote: On Aug 14, 2009, at 1:12 AM, Thomas Fjellstrom wrote: On Thu August 13 2009, Jarod Wilson wrote: On Aug 13, 2009, at 12:53 AM, Thomas Fjellstrom wrote: I stupidly bought the KWorld UB435-Q usb ATSC tuner thinking it was supported under linux, and it turns out it isn't. I'm wondering what it would take to get it supported. It seems like all of the main chips it uses are supported, but the glue code is missing. I have some C (10 years) programming experience, and have wanted to contribute to the linux kernel for quite a while, now I have a good excuse ;) Would anyone be willing to point me in the right direction? The UB435-Q is a rebadge of the revision B 340U, which is an em2870 bridge, lgdt3304 demodulator and an nxp tda18271hd/c2 tuner. Its got the same device ID and everything. I've got a rev A 340U, the only difference being that it has an nxp tda18271hd/c1 tuner (also same device ID). I *had* it working just fine until the stick up and died on me, before I could push the code for merge, but its still floating about. It wasn't quite working with a c2 device, but that could have been a device problem (these are quite franky, cheap and poorly made devices, imo). It could also be that the code ate both sticks and will pickle yours as well. With that caveat emptor, here's where the tree that should at least get you 95% of the way there with that stick resides: http://www.kernellabs.com/hg/~mkrufky/lgdt3304-3/ The last two patches are the relevant ones. They add lgdt3304 demod support to the lgdt3305 driver (because the current lgdt3304 driver is, um, lacking) and then add the bits to wire up the stick. Hi, thanks for the tips. I've applied the last two patches to v4l tip, a few hunks failed, but I managed to apply them by hand, though possibly not correctly as I can't seem to find a program that thinks the /dev/ video0 device that pops up is valid. One app claims there is no input on /dev/ video0, and others just get select timeouts and such (also errors regarding formats and whatnot). These sticks are digital-only. Its a driver shortcoming that the *analog* /dev/video0 device is being created. You need to be hitting / dev/dvb/adapterX/*, not /dev/video0. See http://linuxtv.org/wiki/index.php/Testing_your_DVB_device Ah, thanks for that. So far I've noticed the lgdt driver is very NOT robust, or maybe its one of the other drivers (em28xx?) causing it to die, but if the stick looses connection with usb at all, the driver locks up, spews a BUNCH of errors to dmesg, and eventually the kernel complains: [ 840.552148] INFO: task khubd:170 blocked for more than 120 seconds. [ 840.552155] echo 0 /proc/sys/kernel/hung_task_timeout_secs disables this message. [ 840.552162] khubd D 8800010220c0 0 170 2 [ 840.552172] 88003793a500 0046 88007bd2f600 0286 [ 840.552182] 88007a011900 000120c0 e250 88007d13a3c0 [ 840.552191] 88007d13a6b0 8034e421 88007bd3d800 a046a7c8 [ 840.552200] Call Trace: [ 840.552220] [804b4810] ? schedule+0x9/0x1d [ 840.552243] [a046d9ce] ? dvb_dmxdev_release+0xd8/0x119 [dvb_core] [ 840.552253] [80254736] ? autoremove_wake_function +0x0/0x2e [ 840.552265] [a00dd06e] ? dvb_fini+0x5b/0x91 [em28xx_dvb] [ 840.552289] [a045b099] ? em28xx_close_extension +0x35/0x56 [em28xx] [ 840.552308] [a0459654] ? em28xx_usb_disconnect +0xf4/0x120 [em28xx] [ 840.552319] [803e3628] ? usb_unbind_interface+0x5b/0xe1 [ 840.552329] [803d2618] ? __device_release_driver +0x77/0x9e [ 840.552336] [803d26f7] ? device_release_driver+0x1e/0x2a [ 840.552344] [803d1d7d] ? bus_remove_device+0x8d/0xac [ 840.552352] [803d07ad] ? device_del+0x130/0x198 [ 840.552359] [803e0d91] ? usb_disable_device+0x6c/0xe4 [ 840.552370] [803dc9f4] ? usb_disconnect+0x8c/0x10a [ 840.552378] [803dd9a1] ? hub_thread+0x625/0x1040 [ 840.552387] [80235f65] ? dequeue_entity+0xf/0x11f [ 840.552395] [80254736] ? autoremove_wake_function +0x0/0x2e [ 840.552403] [803dd37c] ? hub_thread+0x0/0x1040 [ 840.552410] [803dd37c] ? hub_thread+0x0/0x1040 [ 840.552418] [803dd37c] ? hub_thread+0x0/0x1040 [ 840.552427] [8025437a] ? kthread+0x54/0x80 [ 840.552435] [80210aca] ? child_rip+0xa/0x20 [ 840.552444] [80254326] ? kthread+0x0/0x80 [ 840.552450] [80210ac0] ? child_rip+0x0/0x20 I'm assuming the only way to restore any kind of function is to reboot (rmmoding em28xx_dbv hangs, and rmmod is unkillable). I'll try working with this a bit more tomorrow (if I can figure out why its hanging), as it is I'm off for some sleep :) Huh, that looks nothing like anything I
RE: [PATCH v1 - 4/5] V4L : vpif updates for DM6467 vpif capture driver
Vaibhav,
I don't see any serious issues raised here. I can send another patch to fix
this if needed.
Regards,
Murali
+#include linux/spinlock.h
#include linux/kernel.h
+#include linux/io.h
[Hiremath, Vaibhav] You may want to put one line gap here.
Ok. Just editorial.
+#include mach/hardware.h
#include vpif.h
@@ -31,6 +35,12 @@ MODULE_LICENSE(GPL);
#define VPIF_CH2_MAX_MODES (15)
#define VPIF_CH3_MAX_MODES (02)
+static resource_size_t res_len;
+static struct resource *res;
[Hiremath, Vaibhav] Do we really require this to be static variable?
I think we can manage it to be local variable.
Yes. We could. Probably change it with a new patch. Don't want to hold up merge
because of this.
+spinlock_t vpif_lock;
+
+void __iomem *vpif_base;
+
static inline void vpif_wr_bit(u32 reg, u32 bit, u32 val)
{
if (val)
@@ -151,17 +161,17 @@ static void config_vpif_params(struct
vpif_params *vpifparams,
else if (config-capture_format) {
/* Set the polarity of various pins */
vpif_wr_bit(reg, VPIF_CH_FID_POLARITY_BIT,
-vpifparams-
params.raw_params.fid_pol);
+vpifparams-iface.fid_pol);
vpif_wr_bit(reg, VPIF_CH_V_VALID_POLARITY_BIT,
-vpifparams-params.raw_params.vd_pol);
+vpifparams-iface.vd_pol);
vpif_wr_bit(reg, VPIF_CH_H_VALID_POLARITY_BIT,
-vpifparams-params.raw_params.hd_pol);
+vpifparams-iface.hd_pol);
value = regr(reg);
/* Set data width */
value = ((~(unsigned int)(0x3))
VPIF_CH_DATA_WIDTH_BIT);
-value |= ((vpifparams-params.raw_params.data_sz)
+value |= ((vpifparams-params.data_sz)
VPIF_CH_DATA_WIDTH_BIT);
regw(value, reg);
}
@@ -227,8 +237,60 @@ int vpif_channel_getfid(u8 channel_id)
}
EXPORT_SYMBOL(vpif_channel_getfid);
-void vpif_base_addr_init(void __iomem *base)
+static int __init vpif_probe(struct platform_device *pdev)
+{
+int status = 0;
+
+res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+if (!res)
+return -ENOENT;
+
+res_len = res-end - res-start + 1;
+
+res = request_mem_region(res-start, res_len, res-name);
+if (!res)
+return -EBUSY;
+
+vpif_base = ioremap(res-start, res_len);
+if (!vpif_base) {
+status = -EBUSY;
+goto fail;
+}
+
+spin_lock_init(vpif_lock);
+dev_info(pdev-dev, vpif probe success\n);
+return 0;
+
+fail:
+release_mem_region(res-start, res_len);
+return status;
+}
+
+static int vpif_remove(struct platform_device *pdev)
{
-vpif_base = base;
+iounmap(vpif_base);
+release_mem_region(res-start, res_len);
+return 0;
}
-EXPORT_SYMBOL(vpif_base_addr_init);
+
+static struct platform_driver vpif_driver = {
+.driver = {
+.name = vpif,
+.owner = THIS_MODULE,
+},
+.remove = __devexit_p(vpif_remove),
+.probe = vpif_probe,
+};
+
+static void vpif_exit(void)
+{
+platform_driver_unregister(vpif_driver);
+}
+
+static int __init vpif_init(void)
+{
+return platform_driver_register(vpif_driver);
+}
+subsys_initcall(vpif_init);
+module_exit(vpif_exit);
+
diff --git a/drivers/media/video/davinci/vpif.h
b/drivers/media/video/davinci/vpif.h
index fca26dc..188841b 100644
--- a/drivers/media/video/davinci/vpif.h
+++ b/drivers/media/video/davinci/vpif.h
@@ -19,6 +19,7 @@
#include linux/io.h
#include linux/videodev2.h
[Hiremath, Vaibhav] one line gap here.
Again editorial.
#include mach/hardware.h
+#include mach/dm646x.h
/* Maximum channel allowed */
#define VPIF_NUM_CHANNELS (4)
@@ -26,7 +27,9 @@
#define VPIF_DISPLAY_NUM_CHANNELS (2)
/* Macros to read/write registers */
-static void __iomem *vpif_base;
+extern void __iomem *vpif_base;
+extern spinlock_t vpif_lock;
[Hiremath, Vaibhav] I think I would want to check compete driver. How these
extern variables have been used.
Let me know if you find some thing wrong in the driver. At this time, I just
don't see any issues with this.
+
#define regr(reg) readl((reg) + vpif_base)
#define regw(value, reg)writel(value, (reg + vpif_base))
@@ -280,6 +283,10 @@ static inline void enable_channel1(int enable)
/* inline function to enable interrupt for channel0 */
static inline void channel0_intr_enable(int enable)
{
+unsigned long flags;
+
+spin_lock_irqsave(vpif_lock, flags);
+
if (enable) {
regw((regr(VPIF_INTEN) | 0x10), VPIF_INTEN);
ov534 + ov772x (playstation eye) broken in 2.6.30
Hi,
Commit 84fbdf87ab8eaa4eaefb317a7eb437cd4d3d0ebf:
V4L/DVB (11105): gspca - ov534: Adjust the packet scan function
broke the gspca ov534 driver for the Playstation Eye in 2.6.30.
Commit c874f3aa7e66158dccb2b9f3cfc46c65af6c223d:
V4L/DVB (11973): gspca - ov534: Do the ov772x work again.
fixes it for 2.6.31, but this leaves 2.6.30 users out in the cold.
I'd like to submit the fix to the -stable team in hopes that it can
get included in 2.6.30.6. Unfortunately 84fbdf87 depends on earlier
patches. The below patch is similar to 84fbdf87 but applies to
2.6.30.5. Does this look acceptable?
-jim
From 8dc9e3749ccb3f500fb8597454561ce18bf39cec Mon Sep 17 00:00:00 2001
From: Jim Paris j...@jtan.com
Date: Mon, 17 Aug 2009 13:45:00 -0400
Subject: [PATCH] gspca - ov534: Fix ov772x
The scan of the image packets of the sensor ov772x was broken when
the sensor ov965x was added.
[ Based on upstream 84fbdf87, reworked for v2.6.30.5 ]
Signed-off-by: Jim Paris j...@jtan.com
---
drivers/media/video/gspca/ov534.c |4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/drivers/media/video/gspca/ov534.c
b/drivers/media/video/gspca/ov534.c
index 19e0bc6..504f849 100644
--- a/drivers/media/video/gspca/ov534.c
+++ b/drivers/media/video/gspca/ov534.c
@@ -832,9 +832,11 @@ static void sd_pkt_scan(struct gspca_dev *gspca_dev,
struct gspca_frame *frame,
__u32 this_pts;
u16 this_fid;
int remaining_len = len;
+ int payload_len;
+ payload_len = (sd-sensor == SENSOR_OV772X) ? 2048 : 2040;
do {
- len = min(remaining_len, 2040); /*fixme: was 2048*/
+ len = min(remaining_len, payload_len);
/* Payloads are prefixed with a UVC-style header. We
consider a frame to start when the FID toggles, or the PTS
--
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
error with dvb-bt8xx needing a rmmod -f and a modprobe again
I've got a bt8xx based dvb card and have had problems with the card in multiple distros all with kernels =2.6.28. The 2.6.27 or less also worked on all distros that had them available. My card is a Nebula Electronics Digitv pci card using the dvb-bt8xx and nxt6000 modules. The problem I have is that when I boot up any linux distro the card won't work in mythtv until I rmmod -r dvb-bt8xx modprobe dvb-bt8xx. The correct entries are created in /dev/dvb/ and the card is detected correctly by dvb software but won't actually scan or tune to anything. I've searched the internet and looked at the mailing list archives and only found the following reference to my problem: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/368215 (the digitv card with the zarlink module is reported as having the same problem in this page. Also the post by chipsugar is mine) I don't have kaffeine or mandriva installed any more but can confirm this is an issue with mythbuntu and gentoo with mythtv and dvbscan and tzap. Building the modules into the kernel also fail obviously. -- 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: ov534 + ov772x (playstation eye) broken in 2.6.30
On Mon, 17 Aug 2009 13:47:44 -0400
Jim Paris j...@jtan.com wrote:
Hi,
Commit 84fbdf87ab8eaa4eaefb317a7eb437cd4d3d0ebf:
V4L/DVB (11105): gspca - ov534: Adjust the packet scan function
broke the gspca ov534 driver for the Playstation Eye in 2.6.30.
Commit c874f3aa7e66158dccb2b9f3cfc46c65af6c223d:
V4L/DVB (11973): gspca - ov534: Do the ov772x work again.
fixes it for 2.6.31, but this leaves 2.6.30 users out in the cold.
I'd like to submit the fix to the -stable team in hopes that it can
get included in 2.6.30.6. Unfortunately 84fbdf87 depends on earlier
patches. The below patch is similar to 84fbdf87 but applies to
2.6.30.5. Does this look acceptable?
-jim
From 8dc9e3749ccb3f500fb8597454561ce18bf39cec Mon Sep 17 00:00:00 2001
From: Jim Paris j...@jtan.com
Date: Mon, 17 Aug 2009 13:45:00 -0400
Subject: [PATCH] gspca - ov534: Fix ov772x
The scan of the image packets of the sensor ov772x was broken when
the sensor ov965x was added.
[ Based on upstream 84fbdf87, reworked for v2.6.30.5 ]
Signed-off-by: Jim Paris j...@jtan.com
---
drivers/media/video/gspca/ov534.c |4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/drivers/media/video/gspca/ov534.c
b/drivers/media/video/gspca/ov534.c index 19e0bc6..504f849 100644
--- a/drivers/media/video/gspca/ov534.c
+++ b/drivers/media/video/gspca/ov534.c
@@ -832,9 +832,11 @@ static void sd_pkt_scan(struct gspca_dev
*gspca_dev, struct gspca_frame *frame, __u32 this_pts;
u16 this_fid;
int remaining_len = len;
+ int payload_len;
+ payload_len = (sd-sensor == SENSOR_OV772X) ? 2048 : 2040;
do {
- len = min(remaining_len,
2040);/*fixme: was 2048*/
+ len = min(remaining_len, payload_len);
/* Payloads are prefixed with a UVC-style header. We
consider a frame to start when the FID toggles,
or the PTS
It's OK for me.
Acked-by: Jean-Francois Moine moin...@free.fr
--
Ken ar c'hentañ | ** Breizh ha Linux atav! **
Jef | http://moinejf.free.fr/
--
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 v1 - 4/5] V4L : vpif updates for DM6467 vpif capture driver
Yes. I will send another patch later to fix the static variables.
Murali Karicheri
Software Design Engineer
Texas Instruments Inc.
Germantown, MD 20874
new phone: 301-407-9583
Old Phone : 301-515-3736 (will be deprecated)
email: m-kariche...@ti.com
-Original Message-
From: Hiremath, Vaibhav
Sent: Monday, August 17, 2009 12:35 PM
To: Karicheri, Muralidharan; linux-media@vger.kernel.org
Cc: davinci-linux-open-sou...@linux.davincidsp.com; hverk...@xs4all.nl
Subject: RE: [PATCH v1 - 4/5] V4L : vpif updates for DM6467 vpif capture
driver
H Murali,
-Original Message-
From: Karicheri, Muralidharan
Sent: Monday, August 17, 2009 9:38 PM
To: Hiremath, Vaibhav; linux-media@vger.kernel.org
Cc: davinci-linux-open-sou...@linux.davincidsp.com;
hverk...@xs4all.nl
Subject: RE: [PATCH v1 - 4/5] V4L : vpif updates for DM6467 vpif
capture driver
Vaibhav,
I don't see any serious issues raised here. I can send another patch
to fix this if needed.
[Hiremath, Vaibhav] yes most of them are editorial, as I mentioned I just
reviewed it quickly.
But as far as static variables are concerned I still think we can avoid
them completely, again it's not critical though.
As I mentioned I will have to look for extern variables, how they have been
used and stuff like that.
As of now, I am ok if it gets merged.
Regards,
Murali
+#include linux/spinlock.h
#include linux/kernel.h
+#include linux/io.h
[Hiremath, Vaibhav] You may want to put one line gap here.
Ok. Just editorial.
+#include mach/hardware.h
#include vpif.h
@@ -31,6 +35,12 @@ MODULE_LICENSE(GPL);
#define VPIF_CH2_MAX_MODES (15)
#define VPIF_CH3_MAX_MODES (02)
+static resource_size_t res_len;
+static struct resource *res;
[Hiremath, Vaibhav] Do we really require this to be static
variable?
I think we can manage it to be local variable.
Yes. We could. Probably change it with a new patch. Don't want to
hold up merge because of this.
+spinlock_t vpif_lock;
+
+void __iomem *vpif_base;
+
static inline void vpif_wr_bit(u32 reg, u32 bit, u32 val)
{
if (val)
@@ -151,17 +161,17 @@ static void config_vpif_params(struct
vpif_params *vpifparams,
else if (config-capture_format) {
/* Set the polarity of various pins */
vpif_wr_bit(reg, VPIF_CH_FID_POLARITY_BIT,
- vpifparams-
params.raw_params.fid_pol);
+ vpifparams-iface.fid_pol);
vpif_wr_bit(reg, VPIF_CH_V_VALID_POLARITY_BIT,
- vpifparams-params.raw_params.vd_pol);
+ vpifparams-iface.vd_pol);
vpif_wr_bit(reg, VPIF_CH_H_VALID_POLARITY_BIT,
- vpifparams-params.raw_params.hd_pol);
+ vpifparams-iface.hd_pol);
value = regr(reg);
/* Set data width */
value = ((~(unsigned int)(0x3))
VPIF_CH_DATA_WIDTH_BIT);
- value |= ((vpifparams-params.raw_params.data_sz)
+ value |= ((vpifparams-params.data_sz)
VPIF_CH_DATA_WIDTH_BIT);
regw(value, reg);
}
@@ -227,8 +237,60 @@ int vpif_channel_getfid(u8 channel_id)
}
EXPORT_SYMBOL(vpif_channel_getfid);
-void vpif_base_addr_init(void __iomem *base)
+static int __init vpif_probe(struct platform_device *pdev)
+{
+ int status = 0;
+
+ res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+ if (!res)
+ return -ENOENT;
+
+ res_len = res-end - res-start + 1;
+
+ res = request_mem_region(res-start, res_len, res-name);
+ if (!res)
+ return -EBUSY;
+
+ vpif_base = ioremap(res-start, res_len);
+ if (!vpif_base) {
+ status = -EBUSY;
+ goto fail;
+ }
+
+ spin_lock_init(vpif_lock);
+ dev_info(pdev-dev, vpif probe success\n);
+ return 0;
+
+fail:
+ release_mem_region(res-start, res_len);
+ return status;
+}
+
+static int vpif_remove(struct platform_device *pdev)
{
- vpif_base = base;
+ iounmap(vpif_base);
+ release_mem_region(res-start, res_len);
+ return 0;
}
-EXPORT_SYMBOL(vpif_base_addr_init);
+
+static struct platform_driver vpif_driver = {
+ .driver = {
+ .name = vpif,
+ .owner = THIS_MODULE,
+ },
+ .remove = __devexit_p(vpif_remove),
+ .probe = vpif_probe,
+};
+
+static void vpif_exit(void)
+{
+ platform_driver_unregister(vpif_driver);
+}
+
+static int __init vpif_init(void)
+{
+ return platform_driver_register(vpif_driver);
+}
+subsys_initcall(vpif_init);
+module_exit(vpif_exit);
+
diff --git a/drivers/media/video/davinci/vpif.h
b/drivers/media/video/davinci/vpif.h
index fca26dc..188841b 100644
---
[cron job] v4l-dvb daily build 2.6.22 and up: ERRORS, 2.6.16-2.6.21: ERRORS
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:Mon Aug 17 19:00:05 CEST 2009 path:http://www.linuxtv.org/hg/v4l-dvb changeset: 12458:3f7e382dfae5 gcc version: gcc (GCC) 4.3.1 hardware:x86_64 host os: 2.6.26 linux-2.6.22.19-armv5: OK linux-2.6.23.12-armv5: OK linux-2.6.24.7-armv5: OK linux-2.6.25.11-armv5: OK linux-2.6.26-armv5: OK linux-2.6.27-armv5: OK linux-2.6.28-armv5: OK linux-2.6.29.1-armv5: OK linux-2.6.30-armv5: OK linux-2.6.31-rc5-armv5: OK linux-2.6.27-armv5-ixp: OK linux-2.6.28-armv5-ixp: OK linux-2.6.29.1-armv5-ixp: OK linux-2.6.30-armv5-ixp: OK linux-2.6.31-rc5-armv5-ixp: OK linux-2.6.28-armv5-omap2: OK linux-2.6.29.1-armv5-omap2: OK linux-2.6.30-armv5-omap2: OK linux-2.6.31-rc5-armv5-omap2: OK linux-2.6.22.19-i686: ERRORS linux-2.6.23.12-i686: ERRORS linux-2.6.24.7-i686: OK linux-2.6.25.11-i686: OK linux-2.6.26-i686: OK linux-2.6.27-i686: OK linux-2.6.28-i686: OK linux-2.6.29.1-i686: WARNINGS linux-2.6.30-i686: WARNINGS linux-2.6.31-rc5-i686: OK linux-2.6.23.12-m32r: ERRORS linux-2.6.24.7-m32r: OK linux-2.6.25.11-m32r: OK linux-2.6.26-m32r: OK linux-2.6.27-m32r: OK linux-2.6.28-m32r: OK linux-2.6.29.1-m32r: OK linux-2.6.30-m32r: OK linux-2.6.31-rc5-m32r: OK linux-2.6.30-mips: WARNINGS linux-2.6.31-rc5-mips: OK linux-2.6.27-powerpc64: OK linux-2.6.28-powerpc64: OK linux-2.6.29.1-powerpc64: WARNINGS linux-2.6.30-powerpc64: WARNINGS linux-2.6.31-rc5-powerpc64: OK linux-2.6.22.19-x86_64: ERRORS linux-2.6.23.12-x86_64: ERRORS linux-2.6.24.7-x86_64: OK linux-2.6.25.11-x86_64: OK linux-2.6.26-x86_64: OK linux-2.6.27-x86_64: OK linux-2.6.28-x86_64: OK linux-2.6.29.1-x86_64: WARNINGS linux-2.6.30-x86_64: WARNINGS linux-2.6.31-rc5-x86_64: OK sparse (linux-2.6.30): OK sparse (linux-2.6.31-rc5): OK linux-2.6.16.61-i686: ERRORS linux-2.6.17.14-i686: ERRORS linux-2.6.18.8-i686: ERRORS linux-2.6.19.5-i686: ERRORS linux-2.6.20.21-i686: ERRORS linux-2.6.21.7-i686: ERRORS linux-2.6.16.61-x86_64: ERRORS linux-2.6.17.14-x86_64: ERRORS linux-2.6.18.8-x86_64: ERRORS linux-2.6.19.5-x86_64: ERRORS linux-2.6.20.21-x86_64: ERRORS linux-2.6.21.7-x86_64: ERRORS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Monday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Monday.tar.bz2 The V4L2 specification from this daily build is here: http://www.xs4all.nl/~hverkuil/spec/v4l2.html The DVB API specification from this daily build is here: http://www.xs4all.nl/~hverkuil/spec/dvbapi.pdf -- 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 v1 - 1/5] DaVinci - restructuring code to support vpif capture driver
On Monday 17 August 2009 16:52:20 Karicheri, Muralidharan wrote: Hans, They are applied against davinci tree (also mentioned in the patch). General procedure what I follow is to create platform code against davinci tree and v4l patches against v4l-dvb linux-next tree. The architecture part of linux-next is not up to date. Davinci tree is at git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-davinci.git I must have missed the mention of this tree. I have a problem, though, as the current v4l-dvb repository doesn't compile against the linux-davinci git tree. And the only way I can get it to compile is to apply all five patches first. However, the whole tree should still compile after each patch is applied. And that goes wrong with your second patch where the Kconfig and Makefile are modified when the new sources aren't even added yet! What I would like to see is a patch series that starts with one patch that makes the current v4l-dvb tree compile again, then the arch patch is added, then a series of v4l-dvb patches in such an order that everything compiles after each step. Merging this is already complicated enough without breaking compilation in this way. 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: [Q] sensors, corrupting the top line
On Monday 17 August 2009 12:09:12 Guennadi Liakhovetski wrote: Hi Hans, all In soc-camera since its first version we have a parameter y_skip_top, which the sensor uses to tell the host (bridge) driver I am sending you that many lines more than what is requested, and you should drop those lines from the top of the image. I never investigated this in detail, originally this was a strong tip that the top line is always corrupted. Now I did investigate it a bit by setting this parameter to 0 and looking what the sensors actually produce. I am working with four sensor: mt9m001, mt9v022, mt9t031 and ov7725, of which only the first two had that parameter set to 1 from the beginning, the others didn't have it and also showed no signs of a problem. mt9m001 (monochrome) doesn't have the problem either, but mt9v022 does. It does indeed deliver the first line with randomly coloured pixels. Notice - this is not the top line of the sensor, this is the first read-out line, independent of the cropping position. So, it seems we do indeed need a way to handle such sensors. Do you have a suggestion for a meaningful v4l2-subdev API for this? Hmm, I think that the best way is to make a struct v4l2_subdev_sensor_ops, move the enum_framesizes/intervals from the video_ops to the sensor_ops (since these are only used by sensors AFAIK), and add a new op to sensor_ops: int (*skip_top_lines)(struct v4l2_subdev *sd, u32 *lines). When we add the op to set the bus_params, then that can be added to sensor_ops as well. I've always thought that we need sensor-specifc ops eventually and this is a good reason to do so. 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: KWorld UB435-Q support?
On Mon August 17 2009, Jarod Wilson wrote: On Aug 14, 2009, at 11:03 AM, Thomas Fjellstrom wrote: On Fri August 14 2009, Jarod Wilson wrote: On Aug 14, 2009, at 1:12 AM, Thomas Fjellstrom wrote: On Thu August 13 2009, Jarod Wilson wrote: On Aug 13, 2009, at 12:53 AM, Thomas Fjellstrom wrote: I stupidly bought the KWorld UB435-Q usb ATSC tuner thinking it was supported under linux, and it turns out it isn't. I'm wondering what it would take to get it supported. It seems like all of the main chips it uses are supported, but the glue code is missing. I have some C (10 years) programming experience, and have wanted to contribute to the linux kernel for quite a while, now I have a good excuse ;) Would anyone be willing to point me in the right direction? The UB435-Q is a rebadge of the revision B 340U, which is an em2870 bridge, lgdt3304 demodulator and an nxp tda18271hd/c2 tuner. Its got the same device ID and everything. I've got a rev A 340U, the only difference being that it has an nxp tda18271hd/c1 tuner (also same device ID). I *had* it working just fine until the stick up and died on me, before I could push the code for merge, but its still floating about. It wasn't quite working with a c2 device, but that could have been a device problem (these are quite franky, cheap and poorly made devices, imo). It could also be that the code ate both sticks and will pickle yours as well. With that caveat emptor, here's where the tree that should at least get you 95% of the way there with that stick resides: http://www.kernellabs.com/hg/~mkrufky/lgdt3304-3/ The last two patches are the relevant ones. They add lgdt3304 demod support to the lgdt3305 driver (because the current lgdt3304 driver is, um, lacking) and then add the bits to wire up the stick. Hi, thanks for the tips. I've applied the last two patches to v4l tip, a few hunks failed, but I managed to apply them by hand, though possibly not correctly as I can't seem to find a program that thinks the /dev/ video0 device that pops up is valid. One app claims there is no input on /dev/ video0, and others just get select timeouts and such (also errors regarding formats and whatnot). These sticks are digital-only. Its a driver shortcoming that the *analog* /dev/video0 device is being created. You need to be hitting / dev/dvb/adapterX/*, not /dev/video0. See http://linuxtv.org/wiki/index.php/Testing_your_DVB_device Ah, thanks for that. So far I've noticed the lgdt driver is very NOT robust, or maybe its one of the other drivers (em28xx?) causing it to die, but if the stick looses connection with usb at all, the driver locks up, spews a BUNCH of errors to dmesg, and eventually the kernel complains: [ 840.552148] INFO: task khubd:170 blocked for more than 120 seconds. [ 840.552155] echo 0 /proc/sys/kernel/hung_task_timeout_secs disables this message. [ 840.552162] khubd D 8800010220c0 0 170 2 [ 840.552172] 88003793a500 0046 88007bd2f600 0286 [ 840.552182] 88007a011900 000120c0 e250 88007d13a3c0 [ 840.552191] 88007d13a6b0 8034e421 88007bd3d800 a046a7c8 [ 840.552200] Call Trace: [ 840.552220] [804b4810] ? schedule+0x9/0x1d [ 840.552243] [a046d9ce] ? dvb_dmxdev_release+0xd8/0x119 [dvb_core] [ 840.552253] [80254736] ? autoremove_wake_function +0x0/0x2e [ 840.552265] [a00dd06e] ? dvb_fini+0x5b/0x91 [em28xx_dvb] [ 840.552289] [a045b099] ? em28xx_close_extension +0x35/0x56 [em28xx] [ 840.552308] [a0459654] ? em28xx_usb_disconnect +0xf4/0x120 [em28xx] [ 840.552319] [803e3628] ? usb_unbind_interface+0x5b/0xe1 [ 840.552329] [803d2618] ? __device_release_driver +0x77/0x9e [ 840.552336] [803d26f7] ? device_release_driver+0x1e/0x2a [ 840.552344] [803d1d7d] ? bus_remove_device+0x8d/0xac [ 840.552352] [803d07ad] ? device_del+0x130/0x198 [ 840.552359] [803e0d91] ? usb_disable_device+0x6c/0xe4 [ 840.552370] [803dc9f4] ? usb_disconnect+0x8c/0x10a [ 840.552378] [803dd9a1] ? hub_thread+0x625/0x1040 [ 840.552387] [80235f65] ? dequeue_entity+0xf/0x11f [ 840.552395] [80254736] ? autoremove_wake_function +0x0/0x2e [ 840.552403] [803dd37c] ? hub_thread+0x0/0x1040 [ 840.552410] [803dd37c] ? hub_thread+0x0/0x1040 [ 840.552418] [803dd37c] ? hub_thread+0x0/0x1040 [ 840.552427] [8025437a] ? kthread+0x54/0x80 [ 840.552435] [80210aca] ? child_rip+0xa/0x20 [ 840.552444] [80254326] ? kthread+0x0/0x80 [ 840.552450] [80210ac0] ? child_rip+0x0/0x20 I'm assuming the only way to restore any kind of function is to reboot (rmmoding
[PATCH] DM365 Platform support for VPFE
From: Neil Sikka neilsi...@ti.com
This has platform and board setup changes to support the vpfe capture
driver for DM365 EVMs.
Reviewed-by: Muralidharan Karicheri m-kariche...@ti.com
Mandatory-Reviewer: Hans Verkuil hverk...@xs4all.nl
Mandatory-Reviewer: Kevin Hilman khil...@deeprootsystems.com
Signed-off-by: Neil Sikka neilsi...@ti.com
---
Applies to Kevin Hilman's linux-davinci repository
arch/arm/mach-davinci/board-dm365-evm.c| 71
arch/arm/mach-davinci/dm365.c | 68 ++
arch/arm/mach-davinci/include/mach/dm365.h |2 +
3 files changed, 141 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-davinci/board-dm365-evm.c
b/arch/arm/mach-davinci/board-dm365-evm.c
index f6adf79..757ad13 100644
--- a/arch/arm/mach-davinci/board-dm365-evm.c
+++ b/arch/arm/mach-davinci/board-dm365-evm.c
@@ -38,6 +38,8 @@
#include mach/common.h
#include mach/mmc.h
#include mach/nand.h
+#include linux/videodev2.h
+#include media/tvp514x.h
static inline int have_imager(void)
@@ -98,6 +100,11 @@ static inline int have_tvp7002(void)
static void __iomem *cpld;
+static struct tvp514x_platform_data tvp5146_pdata = {
+ .clk_polarity = 0,
+ .hs_polarity = 1,
+ .vs_polarity = 1
+};
/* NOTE: this is geared for the standard config, with a socketed
* 2 GByte Micron NAND (MT29F16G08FAA) using 128KB sectors. If you
@@ -210,6 +217,68 @@ static int cpld_mmc_get_ro(int module)
return !!(__raw_readb(cpld + CPLD_CARDSTAT) BIT(module ? 5 : 1));
}
+#define TVP514X_STD_ALL(V4L2_STD_NTSC | V4L2_STD_PAL)
+/* Inputs available at the TVP5146 */
+static struct v4l2_input tvp5146_inputs[] = {
+ {
+ .index = 0,
+ .name = Composite,
+ .type = V4L2_INPUT_TYPE_CAMERA,
+ .std = TVP514X_STD_ALL,
+ },
+ {
+ .index = 1,
+ .name = S-Video,
+ .type = V4L2_INPUT_TYPE_CAMERA,
+ .std = TVP514X_STD_ALL,
+ },
+};
+
+/*
+ * this is the route info for connecting each input to decoder
+ * ouput that goes to vpfe. There is a one to one correspondence
+ * with tvp5146_inputs
+ */
+static struct vpfe_route tvp5146_routes[] = {
+ {
+ .input = INPUT_CVBS_VI2B,
+ .output = OUTPUT_10BIT_422_EMBEDDED_SYNC,
+ },
+{
+ .input = INPUT_SVIDEO_VI2C_VI1C,
+ .output = OUTPUT_10BIT_422_EMBEDDED_SYNC,
+ },
+};
+
+static struct vpfe_subdev_info vpfe_sub_devs[] = {
+{
+ .module_name = tvp5146,
+ .grp_id = 0,
+ .num_inputs = ARRAY_SIZE(tvp5146_inputs),
+ .inputs = tvp5146_inputs,
+ .routes = tvp5146_routes,
+ .can_route = 1,
+ .ccdc_if_params = {
+ .if_type = VPFE_BT656,
+ .hdpol = VPFE_PINPOL_POSITIVE,
+ .vdpol = VPFE_PINPOL_POSITIVE,
+ },
+ .board_info = {
+ I2C_BOARD_INFO(tvp5146, 0x5d),
+ .platform_data = tvp5146_pdata,
+ },
+ }
+};
+
+static struct vpfe_config vpfe_cfg = {
+ .num_subdevs = ARRAY_SIZE(vpfe_sub_devs),
+ .sub_devs = vpfe_sub_devs,
+ .card_name = DM365 EVM,
+ .ccdc = DM365 ISIF,
+ .num_clocks = 1,
+ .clocks = {vpss_master},
+};
+
static struct davinci_mmc_config dm365evm_mmc_config = {
.get_cd = cpld_mmc_get_cd,
.get_ro = cpld_mmc_get_ro,
@@ -461,6 +530,8 @@ static struct davinci_uart_config uart_config __initdata = {
static void __init dm365_evm_map_io(void)
{
+ /* setup input configuration for VPFE input devices */
+ dm365_set_vpfe_config(vpfe_cfg);
dm365_init();
}
diff --git a/arch/arm/mach-davinci/dm365.c b/arch/arm/mach-davinci/dm365.c
index f8bac94..aa432d4 100644
--- a/arch/arm/mach-davinci/dm365.c
+++ b/arch/arm/mach-davinci/dm365.c
@@ -904,6 +904,62 @@ void __init dm365_init(void)
davinci_common_init(davinci_soc_info_dm365);
}
+static struct resource dm365_vpss_resources[] = {
+ {
+ /* VPSS ISP5 Base address */
+ .name = vpss,
+ .start = 0x01c7,
+ .end= 0x01c7 + 0xff,
+ .flags = IORESOURCE_MEM,
+ },
+ {
+ /* VPSS CLK Base address */
+ .name = vpss,
+ .start = 0x01c70200,
+ .end= 0x01c70200 + 0xff,
+ .flags = IORESOURCE_MEM,
+ },
+};
+
+static struct platform_device dm365_vpss_device = {
+ .name = vpss,
+ .id = -1,
+ .dev.platform_data = dm365_vpss,
+ .num_resources = ARRAY_SIZE(dm365_vpss_resources),
+ .resource =
[PATCH] DM365 VPSS support
From: Neil Sikka neilsi...@ti.com
This patch adds support for DM365 VPSS
Reviewed-by: Muralidharan Karicheri m-kariche...@ti.com
Mandatory-Reviewer: Hans Verkuil hverk...@xs4all.nl
Signed-off-by: Neil Sikka neilsi...@ti.com
---
Applies to v4l-dvb linux-next repository
drivers/media/video/davinci/vpss.c | 232
include/media/davinci/vpss.h | 59 +-
2 files changed, 268 insertions(+), 23 deletions(-)
diff --git a/drivers/media/video/davinci/vpss.c
b/drivers/media/video/davinci/vpss.c
index 6d709ca..83dac1b 100644
--- a/drivers/media/video/davinci/vpss.c
+++ b/drivers/media/video/davinci/vpss.c
@@ -42,9 +42,12 @@ MODULE_AUTHOR(Texas Instruments);
/* masks and shifts */
#define VPSS_HSSISEL_SHIFT 4
-/*
+/* lock to write into common register */
+static spinlock_t vpss_lock;
+
+/**
* vpss operations. Depends on platform. Not all functions are available
- * on all platforms. The api, first check if a functio is available before
+ * on all platforms. The api, first check if a function is available before
* invoking it. In the probe, the function ptrs are intialized based on
* vpss name. vpss name can be dm355_vpss, dm644x_vpss etc.
*/
@@ -53,14 +56,19 @@ struct vpss_hw_ops {
int (*enable_clock)(enum vpss_clock_sel clock_sel, int en);
/* select input to ccdc */
void (*select_ccdc_source)(enum vpss_ccdc_source_sel src_sel);
- /* clear wbl overlflow bit */
+ /* clear wbl overflow bit */
int (*clear_wbl_overflow)(enum vpss_wbl_sel wbl_sel);
+ /*set sync polarity */
+ void (*set_sync_pol)(struct vpss_sync_pol);
+ /*set the PG_FRAME_SIZE register*/
+ void (*set_pg_frame_size)(struct vpss_pg_frame_size);
};
/* vpss configuration */
struct vpss_oper_config {
- __iomem void *vpss_bl_regs_base;
- __iomem void *vpss_regs_base;
+ __iomem void *vpss_regs_base0;
+ __iomem void *vpss_regs_base1;
+ resource_size_t *vpss_regs_base2;
struct resource *r1;
resource_size_t len1;
struct resource *r2;
@@ -75,22 +83,32 @@ static struct vpss_oper_config oper_cfg;
/* register access routines */
static inline u32 bl_regr(u32 offset)
{
- return __raw_readl(oper_cfg.vpss_bl_regs_base + offset);
+ return __raw_readl(oper_cfg.vpss_regs_base0 + offset);
}
static inline void bl_regw(u32 val, u32 offset)
{
- __raw_writel(val, oper_cfg.vpss_bl_regs_base + offset);
+ __raw_writel(val, oper_cfg.vpss_regs_base0 + offset);
+}
+
+static inline u32 isp5_read(u32 offset)
+{
+ return __raw_readl(oper_cfg.vpss_regs_base0 + offset);
+}
+
+static inline void isp5_write(u32 val, u32 offset)
+{
+ __raw_writel(val, oper_cfg.vpss_regs_base0 + offset);
}
static inline u32 vpss_regr(u32 offset)
{
- return __raw_readl(oper_cfg.vpss_regs_base + offset);
+ return __raw_readl(oper_cfg.vpss_regs_base1 + offset);
}
static inline void vpss_regw(u32 val, u32 offset)
{
- __raw_writel(val, oper_cfg.vpss_regs_base + offset);
+ __raw_writel(val, oper_cfg.vpss_regs_base1 + offset);
}
static void dm355_select_ccdc_source(enum vpss_ccdc_source_sel src_sel)
@@ -98,12 +116,25 @@ static void dm355_select_ccdc_source(enum
vpss_ccdc_source_sel src_sel)
bl_regw(src_sel VPSS_HSSISEL_SHIFT, DM355_VPSSBL_CCDCMUX);
}
+static void dm365_select_ccdc_source(enum vpss_ccdc_source_sel src_sel)
+{
+ u32 temp = isp5_read(DM365_ISP5_CCDCMUX) ~CCD_SRC_SEL_MASK;
+
+ /* if we are using pattern generator, enable it */
+ if (src_sel == VPSS_PGLPBK || src_sel == VPSS_CCDCPG)
+ temp |= 0x08;
+
+ temp |= (src_sel CCD_SRC_SEL_SHIFT);
+ isp5_write(temp, DM365_ISP5_CCDCMUX);
+}
+
int vpss_select_ccdc_source(enum vpss_ccdc_source_sel src_sel)
{
if (!oper_cfg.hw_ops.select_ccdc_source)
return -1;
- dm355_select_ccdc_source(src_sel);
+ oper_cfg.hw_ops.select_ccdc_source(src_sel);
+
return 0;
}
EXPORT_SYMBOL(vpss_select_ccdc_source);
@@ -120,9 +151,56 @@ static int dm644x_clear_wbl_overflow(enum vpss_wbl_sel
wbl_sel)
mask = ~(mask wbl_sel);
val = bl_regr(DM644X_SBL_PCR_VPSS) mask;
bl_regw(val, DM644X_SBL_PCR_VPSS);
+
return 0;
}
+static void dm365_enable_irq(void)
+{
+ u32 current_val = isp5_read(DM365_VPSS_INTSEL1);
+ /*just enable INTSEL0 and INTSEL1 and leave everything else as is*/
+ current_val = ~(CCD_INT_SEL_MASK);
+ current_val |= BIT_MASK(8);
+ isp5_write(current_val, DM365_VPSS_INTSEL1);
+}
+
+void dm365_set_sync_pol(struct vpss_sync_pol sync)
+{
+ int val = 0;
+ val = isp5_read(DM365_ISP5_CCDCMUX);
+
+ val |= (sync.ccdpg_hdpol DM365_CCDC_PG_HD_POL_SHIFT);
+ val |= (sync.ccdpg_vdpol DM365_CCDC_PG_VD_POL_SHIFT);
+
+ isp5_write(val, DM365_ISP5_CCDCMUX);
+}
+
+void vpss_set_sync_pol(struct
[PATCH] Build system support for DM365 CCDC
From: Neil Sikka neilsi...@ti.com This patch sets up the build system for DM365 VPFE support Reviewed-by: Muralidharan Karicheri m-kariche...@ti.com Mandatory-Reviewer: Hans Verkuil hverk...@xs4all.nl Signed-off-by: Neil Sikka neilsi...@ti.com --- Applies to v4l-dvb linux-next repository drivers/media/video/Kconfig |9 + drivers/media/video/davinci/Makefile |3 ++- 2 files changed, 11 insertions(+), 1 deletions(-) diff --git a/drivers/media/video/Kconfig b/drivers/media/video/Kconfig index 1fa3c87..e0dd402 100644 --- a/drivers/media/video/Kconfig +++ b/drivers/media/video/Kconfig @@ -578,6 +578,15 @@ config VIDEO_DM355_CCDC To compile this driver as a module, choose M here: the module will be called vpfe. +config VIDEO_DM365_ISIF + tristate DM365 CCDC/ISIF HW module + depends on ARCH_DAVINCI_DM365 VIDEO_VPFE_CAPTURE + default y + help + Enables DM365 ISIF hw module. This is the hardware module for + configuring ISIF in VPFE to capture Raw Bayer RGB data from + a image sensor or YUV data from a YUV source. + source drivers/media/video/bt8xx/Kconfig config VIDEO_PMS diff --git a/drivers/media/video/davinci/Makefile b/drivers/media/video/davinci/Makefile index f44cad2..5f4c830 100644 --- a/drivers/media/video/davinci/Makefile +++ b/drivers/media/video/davinci/Makefile @@ -8,8 +8,9 @@ obj-$(CONFIG_VIDEO_DAVINCI_VPIF) += vpif.o #DM646x EVM Display driver obj-$(CONFIG_DISPLAY_DAVINCI_DM646X_EVM) += vpif_display.o -# Capture: DM6446 and DM355 +# Capture: DM6446, DM355, DM365 obj-$(CONFIG_VIDEO_VPSS_SYSTEM) += vpss.o obj-$(CONFIG_VIDEO_VPFE_CAPTURE) += vpfe_capture.o obj-$(CONFIG_VIDEO_DM6446_CCDC) += dm644x_ccdc.o obj-$(CONFIG_VIDEO_DM355_CCDC) += dm355_ccdc.o +obj-$(CONFIG_VIDEO_DM365_ISIF) += dm365_ccdc.o -- 1.6.0.4 -- 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] DM365 Platform support for VPFE
From: Neil Sikka neilsi...@ti.com
This has platform and board setup changes to support the vpfe capture
driver for DM365 EVMs.
Reviewed-by: Muralidharan Karicheri m-kariche...@ti.com
Mandatory-Reviewer: Hans Verkuil hverk...@xs4all.nl
Mandatory-Reviewer: Kevin Hilman khil...@deeprootsystems.com
Signed-off-by: Neil Sikka neilsi...@ti.com
---
Applies to Kevin Hilman's linux-davinci repository
arch/arm/mach-davinci/board-dm365-evm.c| 71
arch/arm/mach-davinci/dm365.c | 68 ++
arch/arm/mach-davinci/include/mach/dm365.h |2 +
3 files changed, 141 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-davinci/board-dm365-evm.c
b/arch/arm/mach-davinci/board-dm365-evm.c
index f6adf79..757ad13 100644
--- a/arch/arm/mach-davinci/board-dm365-evm.c
+++ b/arch/arm/mach-davinci/board-dm365-evm.c
@@ -38,6 +38,8 @@
#include mach/common.h
#include mach/mmc.h
#include mach/nand.h
+#include linux/videodev2.h
+#include media/tvp514x.h
static inline int have_imager(void)
@@ -98,6 +100,11 @@ static inline int have_tvp7002(void)
static void __iomem *cpld;
+static struct tvp514x_platform_data tvp5146_pdata = {
+ .clk_polarity = 0,
+ .hs_polarity = 1,
+ .vs_polarity = 1
+};
/* NOTE: this is geared for the standard config, with a socketed
* 2 GByte Micron NAND (MT29F16G08FAA) using 128KB sectors. If you
@@ -210,6 +217,68 @@ static int cpld_mmc_get_ro(int module)
return !!(__raw_readb(cpld + CPLD_CARDSTAT) BIT(module ? 5 : 1));
}
+#define TVP514X_STD_ALL(V4L2_STD_NTSC | V4L2_STD_PAL)
+/* Inputs available at the TVP5146 */
+static struct v4l2_input tvp5146_inputs[] = {
+ {
+ .index = 0,
+ .name = Composite,
+ .type = V4L2_INPUT_TYPE_CAMERA,
+ .std = TVP514X_STD_ALL,
+ },
+ {
+ .index = 1,
+ .name = S-Video,
+ .type = V4L2_INPUT_TYPE_CAMERA,
+ .std = TVP514X_STD_ALL,
+ },
+};
+
+/*
+ * this is the route info for connecting each input to decoder
+ * ouput that goes to vpfe. There is a one to one correspondence
+ * with tvp5146_inputs
+ */
+static struct vpfe_route tvp5146_routes[] = {
+ {
+ .input = INPUT_CVBS_VI2B,
+ .output = OUTPUT_10BIT_422_EMBEDDED_SYNC,
+ },
+{
+ .input = INPUT_SVIDEO_VI2C_VI1C,
+ .output = OUTPUT_10BIT_422_EMBEDDED_SYNC,
+ },
+};
+
+static struct vpfe_subdev_info vpfe_sub_devs[] = {
+{
+ .module_name = tvp5146,
+ .grp_id = 0,
+ .num_inputs = ARRAY_SIZE(tvp5146_inputs),
+ .inputs = tvp5146_inputs,
+ .routes = tvp5146_routes,
+ .can_route = 1,
+ .ccdc_if_params = {
+ .if_type = VPFE_BT656,
+ .hdpol = VPFE_PINPOL_POSITIVE,
+ .vdpol = VPFE_PINPOL_POSITIVE,
+ },
+ .board_info = {
+ I2C_BOARD_INFO(tvp5146, 0x5d),
+ .platform_data = tvp5146_pdata,
+ },
+ }
+};
+
+static struct vpfe_config vpfe_cfg = {
+ .num_subdevs = ARRAY_SIZE(vpfe_sub_devs),
+ .sub_devs = vpfe_sub_devs,
+ .card_name = DM365 EVM,
+ .ccdc = DM365 ISIF,
+ .num_clocks = 1,
+ .clocks = {vpss_master},
+};
+
static struct davinci_mmc_config dm365evm_mmc_config = {
.get_cd = cpld_mmc_get_cd,
.get_ro = cpld_mmc_get_ro,
@@ -461,6 +530,8 @@ static struct davinci_uart_config uart_config __initdata = {
static void __init dm365_evm_map_io(void)
{
+ /* setup input configuration for VPFE input devices */
+ dm365_set_vpfe_config(vpfe_cfg);
dm365_init();
}
diff --git a/arch/arm/mach-davinci/dm365.c b/arch/arm/mach-davinci/dm365.c
index f8bac94..aa432d4 100644
--- a/arch/arm/mach-davinci/dm365.c
+++ b/arch/arm/mach-davinci/dm365.c
@@ -904,6 +904,62 @@ void __init dm365_init(void)
davinci_common_init(davinci_soc_info_dm365);
}
+static struct resource dm365_vpss_resources[] = {
+ {
+ /* VPSS ISP5 Base address */
+ .name = vpss,
+ .start = 0x01c7,
+ .end= 0x01c7 + 0xff,
+ .flags = IORESOURCE_MEM,
+ },
+ {
+ /* VPSS CLK Base address */
+ .name = vpss,
+ .start = 0x01c70200,
+ .end= 0x01c70200 + 0xff,
+ .flags = IORESOURCE_MEM,
+ },
+};
+
+static struct platform_device dm365_vpss_device = {
+ .name = vpss,
+ .id = -1,
+ .dev.platform_data = dm365_vpss,
+ .num_resources = ARRAY_SIZE(dm365_vpss_resources),
+ .resource =
[PATCH] Build system support for DM365 CCDC
From: Neil Sikka neilsi...@ti.com This patch sets up the build system for DM365 VPFE support Reviewed-by: Muralidharan Karicheri m-kariche...@ti.com Mandatory-Reviewer: Hans Verkuil hverk...@xs4all.nl Signed-off-by: Neil Sikka neilsi...@ti.com --- Applies to v4l-dvb linux-next repository drivers/media/video/Kconfig |9 + drivers/media/video/davinci/Makefile |3 ++- 2 files changed, 11 insertions(+), 1 deletions(-) diff --git a/drivers/media/video/Kconfig b/drivers/media/video/Kconfig index 1fa3c87..e0dd402 100644 --- a/drivers/media/video/Kconfig +++ b/drivers/media/video/Kconfig @@ -578,6 +578,15 @@ config VIDEO_DM355_CCDC To compile this driver as a module, choose M here: the module will be called vpfe. +config VIDEO_DM365_ISIF + tristate DM365 CCDC/ISIF HW module + depends on ARCH_DAVINCI_DM365 VIDEO_VPFE_CAPTURE + default y + help + Enables DM365 ISIF hw module. This is the hardware module for + configuring ISIF in VPFE to capture Raw Bayer RGB data from + a image sensor or YUV data from a YUV source. + source drivers/media/video/bt8xx/Kconfig config VIDEO_PMS diff --git a/drivers/media/video/davinci/Makefile b/drivers/media/video/davinci/Makefile index f44cad2..5f4c830 100644 --- a/drivers/media/video/davinci/Makefile +++ b/drivers/media/video/davinci/Makefile @@ -8,8 +8,9 @@ obj-$(CONFIG_VIDEO_DAVINCI_VPIF) += vpif.o #DM646x EVM Display driver obj-$(CONFIG_DISPLAY_DAVINCI_DM646X_EVM) += vpif_display.o -# Capture: DM6446 and DM355 +# Capture: DM6446, DM355, DM365 obj-$(CONFIG_VIDEO_VPSS_SYSTEM) += vpss.o obj-$(CONFIG_VIDEO_VPFE_CAPTURE) += vpfe_capture.o obj-$(CONFIG_VIDEO_DM6446_CCDC) += dm644x_ccdc.o obj-$(CONFIG_VIDEO_DM355_CCDC) += dm355_ccdc.o +obj-$(CONFIG_VIDEO_DM365_ISIF) += dm365_ccdc.o -- 1.6.0.4 -- 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] DM365 VPSS support
From: Neil Sikka neilsi...@ti.com
This patch adds support for DM365 VPSS
Reviewed-by: Muralidharan Karicheri m-kariche...@ti.com
Mandatory-Reviewer: Hans Verkuil hverk...@xs4all.nl
Signed-off-by: Neil Sikka neilsi...@ti.com
---
Applies to v4l-dvb linux-next repository
drivers/media/video/davinci/vpss.c | 232
include/media/davinci/vpss.h | 59 +-
2 files changed, 268 insertions(+), 23 deletions(-)
diff --git a/drivers/media/video/davinci/vpss.c
b/drivers/media/video/davinci/vpss.c
index 6d709ca..83dac1b 100644
--- a/drivers/media/video/davinci/vpss.c
+++ b/drivers/media/video/davinci/vpss.c
@@ -42,9 +42,12 @@ MODULE_AUTHOR(Texas Instruments);
/* masks and shifts */
#define VPSS_HSSISEL_SHIFT 4
-/*
+/* lock to write into common register */
+static spinlock_t vpss_lock;
+
+/**
* vpss operations. Depends on platform. Not all functions are available
- * on all platforms. The api, first check if a functio is available before
+ * on all platforms. The api, first check if a function is available before
* invoking it. In the probe, the function ptrs are intialized based on
* vpss name. vpss name can be dm355_vpss, dm644x_vpss etc.
*/
@@ -53,14 +56,19 @@ struct vpss_hw_ops {
int (*enable_clock)(enum vpss_clock_sel clock_sel, int en);
/* select input to ccdc */
void (*select_ccdc_source)(enum vpss_ccdc_source_sel src_sel);
- /* clear wbl overlflow bit */
+ /* clear wbl overflow bit */
int (*clear_wbl_overflow)(enum vpss_wbl_sel wbl_sel);
+ /*set sync polarity */
+ void (*set_sync_pol)(struct vpss_sync_pol);
+ /*set the PG_FRAME_SIZE register*/
+ void (*set_pg_frame_size)(struct vpss_pg_frame_size);
};
/* vpss configuration */
struct vpss_oper_config {
- __iomem void *vpss_bl_regs_base;
- __iomem void *vpss_regs_base;
+ __iomem void *vpss_regs_base0;
+ __iomem void *vpss_regs_base1;
+ resource_size_t *vpss_regs_base2;
struct resource *r1;
resource_size_t len1;
struct resource *r2;
@@ -75,22 +83,32 @@ static struct vpss_oper_config oper_cfg;
/* register access routines */
static inline u32 bl_regr(u32 offset)
{
- return __raw_readl(oper_cfg.vpss_bl_regs_base + offset);
+ return __raw_readl(oper_cfg.vpss_regs_base0 + offset);
}
static inline void bl_regw(u32 val, u32 offset)
{
- __raw_writel(val, oper_cfg.vpss_bl_regs_base + offset);
+ __raw_writel(val, oper_cfg.vpss_regs_base0 + offset);
+}
+
+static inline u32 isp5_read(u32 offset)
+{
+ return __raw_readl(oper_cfg.vpss_regs_base0 + offset);
+}
+
+static inline void isp5_write(u32 val, u32 offset)
+{
+ __raw_writel(val, oper_cfg.vpss_regs_base0 + offset);
}
static inline u32 vpss_regr(u32 offset)
{
- return __raw_readl(oper_cfg.vpss_regs_base + offset);
+ return __raw_readl(oper_cfg.vpss_regs_base1 + offset);
}
static inline void vpss_regw(u32 val, u32 offset)
{
- __raw_writel(val, oper_cfg.vpss_regs_base + offset);
+ __raw_writel(val, oper_cfg.vpss_regs_base1 + offset);
}
static void dm355_select_ccdc_source(enum vpss_ccdc_source_sel src_sel)
@@ -98,12 +116,25 @@ static void dm355_select_ccdc_source(enum
vpss_ccdc_source_sel src_sel)
bl_regw(src_sel VPSS_HSSISEL_SHIFT, DM355_VPSSBL_CCDCMUX);
}
+static void dm365_select_ccdc_source(enum vpss_ccdc_source_sel src_sel)
+{
+ u32 temp = isp5_read(DM365_ISP5_CCDCMUX) ~CCD_SRC_SEL_MASK;
+
+ /* if we are using pattern generator, enable it */
+ if (src_sel == VPSS_PGLPBK || src_sel == VPSS_CCDCPG)
+ temp |= 0x08;
+
+ temp |= (src_sel CCD_SRC_SEL_SHIFT);
+ isp5_write(temp, DM365_ISP5_CCDCMUX);
+}
+
int vpss_select_ccdc_source(enum vpss_ccdc_source_sel src_sel)
{
if (!oper_cfg.hw_ops.select_ccdc_source)
return -1;
- dm355_select_ccdc_source(src_sel);
+ oper_cfg.hw_ops.select_ccdc_source(src_sel);
+
return 0;
}
EXPORT_SYMBOL(vpss_select_ccdc_source);
@@ -120,9 +151,56 @@ static int dm644x_clear_wbl_overflow(enum vpss_wbl_sel
wbl_sel)
mask = ~(mask wbl_sel);
val = bl_regr(DM644X_SBL_PCR_VPSS) mask;
bl_regw(val, DM644X_SBL_PCR_VPSS);
+
return 0;
}
+static void dm365_enable_irq(void)
+{
+ u32 current_val = isp5_read(DM365_VPSS_INTSEL1);
+ /*just enable INTSEL0 and INTSEL1 and leave everything else as is*/
+ current_val = ~(CCD_INT_SEL_MASK);
+ current_val |= BIT_MASK(8);
+ isp5_write(current_val, DM365_VPSS_INTSEL1);
+}
+
+void dm365_set_sync_pol(struct vpss_sync_pol sync)
+{
+ int val = 0;
+ val = isp5_read(DM365_ISP5_CCDCMUX);
+
+ val |= (sync.ccdpg_hdpol DM365_CCDC_PG_HD_POL_SHIFT);
+ val |= (sync.ccdpg_vdpol DM365_CCDC_PG_VD_POL_SHIFT);
+
+ isp5_write(val, DM365_ISP5_CCDCMUX);
+}
+
+void vpss_set_sync_pol(struct
[PATCH v1 0/4] Adding capture support for DM365 device
From: Neil Sikka neilsi...@ti.com This patch series adds support for the VPSS capture on the DM365 SOC. Specifically, it supports the CCDC/ISIF module. This code has been tested and works with the TVP5146 decoder (using the tvp514x driver). During testing of this code, the NTSC capture format was used. This patch depends on previous other patches contributed by Muralidharan Karicheri. Please see the individual patch notes for dependency details. The patches contained in this patch set are: 1) DM365 Platform support for VPFE-additions to the DM365 SOC files 2) DM365 VPSS support-additions to the VPSS.h and VPSS.c files 3) CCDC support on DM365-the actual DM365 CCDC driver and its supporting files NOTE: All patches are to be applied before build. Mandatory reviewers: Hans Verkuil hverk...@xs4all.nl for V4L tree Kevin Hilman khil...@deeprootsystems.com for DaVinci tree Reviewed-by: Muralidharan Karicheri m-kariche...@ti.com Signed-off-by: Neil Sikka neilsi...@ti.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v1 - 1/5] DaVinci - restructuring code to support vpif capture driver
Hans, Ok. I will rework the patch and send you the same. Murali Karicheri Software Design Engineer Texas Instruments Inc. Germantown, MD 20874 new phone: 301-407-9583 Old Phone : 301-515-3736 (will be deprecated) email: m-kariche...@ti.com -Original Message- From: Hans Verkuil [mailto:hverk...@xs4all.nl] Sent: Monday, August 17, 2009 2:47 PM To: Karicheri, Muralidharan Cc: linux-media@vger.kernel.org; davinci-linux-open- sou...@linux.davincidsp.com; khil...@deeprootsystems.com Subject: Re: [PATCH v1 - 1/5] DaVinci - restructuring code to support vpif capture driver On Monday 17 August 2009 16:52:20 Karicheri, Muralidharan wrote: Hans, They are applied against davinci tree (also mentioned in the patch). General procedure what I follow is to create platform code against davinci tree and v4l patches against v4l-dvb linux-next tree. The architecture part of linux-next is not up to date. Davinci tree is at git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-davinci.git I must have missed the mention of this tree. I have a problem, though, as the current v4l-dvb repository doesn't compile against the linux-davinci git tree. And the only way I can get it to compile is to apply all five patches first. However, the whole tree should still compile after each patch is applied. And that goes wrong with your second patch where the Kconfig and Makefile are modified when the new sources aren't even added yet! What I would like to see is a patch series that starts with one patch that makes the current v4l-dvb tree compile again, then the arch patch is added, then a series of v4l-dvb patches in such an order that everything compiles after each step. Merging this is already complicated enough without breaking compilation in this way. 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: [PATCH v1 0/4] Adding capture support for DM365 device
Please disregard the previous patch. I am sending one with corrected Subject fields. -Original Message- From: Sikka, Neil Sent: Monday, August 17, 2009 3:35 PM To: linux-media@vger.kernel.org; davinci-linux-open-sou...@linux.davincidsp.com Cc: khil...@deeprootsystems.com; hverk...@xs4all.nl; Sikka, Neil Subject: [PATCH v1 0/4] Adding capture support for DM365 device From: Neil Sikka neilsi...@ti.com This patch series adds support for the VPSS capture on the DM365 SOC. Specifically, it supports the CCDC/ISIF module. This code has been tested and works with the TVP5146 decoder (using the tvp514x driver). During testing of this code, the NTSC capture format was used. This patch depends on previous other patches contributed by Muralidharan Karicheri. Please see the individual patch notes for dependency details. The patches contained in this patch set are: 1) DM365 Platform support for VPFE-additions to the DM365 SOC files 2) DM365 VPSS support-additions to the VPSS.h and VPSS.c files 3) CCDC support on DM365-the actual DM365 CCDC driver and its supporting files NOTE: All patches are to be applied before build. Mandatory reviewers: Hans Verkuil hverk...@xs4all.nl for V4L tree Kevin Hilman khil...@deeprootsystems.com for DaVinci tree Reviewed-by: Muralidharan Karicheri m-kariche...@ti.com Signed-off-by: Neil Sikka neilsi...@ti.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v1 0/4] Adding capture support for DM365 device
From: Neil Sikka neilsi...@ti.com This patch series adds support for the VPSS capture on the DM365 SOC. Specifically, it supports the CCDC/ISIF module. This code has been tested and works with the TVP5146 decoder (using the tvp514x driver). During testing of this code, the NTSC capture format was used. This patch depends on previous other patches contributed by Muralidharan Karicheri. Please see the individual patch notes for dependency details. The patches contained in this patch set are: 1) DM365 Platform support for VPFE-additions to the DM365 SOC files 2) DM365 VPSS support-additions to the VPSS.h and VPSS.c files 3) CCDC support on DM365-the actual DM365 CCDC driver and its supporting files NOTE: All patches are to be applied before build. Mandatory reviewers: Hans Verkuil hverk...@xs4all.nl for V4L tree Kevin Hilman khil...@deeprootsystems.com for DaVinci tree Reviewed-by: Muralidharan Karicheri m-kariche...@ti.com Signed-off-by: Neil Sikka neilsi...@ti.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v1 2/4] DM365 VPSS support
From: Neil Sikka neilsi...@ti.com
This patch adds support for DM365 VPSS
Reviewed-by: Muralidharan Karicheri m-kariche...@ti.com
Mandatory-Reviewer: Hans Verkuil hverk...@xs4all.nl
Signed-off-by: Neil Sikka neilsi...@ti.com
---
Applies to v4l-dvb linux-next repository
drivers/media/video/davinci/vpss.c | 232
include/media/davinci/vpss.h | 59 +-
2 files changed, 268 insertions(+), 23 deletions(-)
diff --git a/drivers/media/video/davinci/vpss.c
b/drivers/media/video/davinci/vpss.c
index 6d709ca..83dac1b 100644
--- a/drivers/media/video/davinci/vpss.c
+++ b/drivers/media/video/davinci/vpss.c
@@ -42,9 +42,12 @@ MODULE_AUTHOR(Texas Instruments);
/* masks and shifts */
#define VPSS_HSSISEL_SHIFT 4
-/*
+/* lock to write into common register */
+static spinlock_t vpss_lock;
+
+/**
* vpss operations. Depends on platform. Not all functions are available
- * on all platforms. The api, first check if a functio is available before
+ * on all platforms. The api, first check if a function is available before
* invoking it. In the probe, the function ptrs are intialized based on
* vpss name. vpss name can be dm355_vpss, dm644x_vpss etc.
*/
@@ -53,14 +56,19 @@ struct vpss_hw_ops {
int (*enable_clock)(enum vpss_clock_sel clock_sel, int en);
/* select input to ccdc */
void (*select_ccdc_source)(enum vpss_ccdc_source_sel src_sel);
- /* clear wbl overlflow bit */
+ /* clear wbl overflow bit */
int (*clear_wbl_overflow)(enum vpss_wbl_sel wbl_sel);
+ /*set sync polarity */
+ void (*set_sync_pol)(struct vpss_sync_pol);
+ /*set the PG_FRAME_SIZE register*/
+ void (*set_pg_frame_size)(struct vpss_pg_frame_size);
};
/* vpss configuration */
struct vpss_oper_config {
- __iomem void *vpss_bl_regs_base;
- __iomem void *vpss_regs_base;
+ __iomem void *vpss_regs_base0;
+ __iomem void *vpss_regs_base1;
+ resource_size_t *vpss_regs_base2;
struct resource *r1;
resource_size_t len1;
struct resource *r2;
@@ -75,22 +83,32 @@ static struct vpss_oper_config oper_cfg;
/* register access routines */
static inline u32 bl_regr(u32 offset)
{
- return __raw_readl(oper_cfg.vpss_bl_regs_base + offset);
+ return __raw_readl(oper_cfg.vpss_regs_base0 + offset);
}
static inline void bl_regw(u32 val, u32 offset)
{
- __raw_writel(val, oper_cfg.vpss_bl_regs_base + offset);
+ __raw_writel(val, oper_cfg.vpss_regs_base0 + offset);
+}
+
+static inline u32 isp5_read(u32 offset)
+{
+ return __raw_readl(oper_cfg.vpss_regs_base0 + offset);
+}
+
+static inline void isp5_write(u32 val, u32 offset)
+{
+ __raw_writel(val, oper_cfg.vpss_regs_base0 + offset);
}
static inline u32 vpss_regr(u32 offset)
{
- return __raw_readl(oper_cfg.vpss_regs_base + offset);
+ return __raw_readl(oper_cfg.vpss_regs_base1 + offset);
}
static inline void vpss_regw(u32 val, u32 offset)
{
- __raw_writel(val, oper_cfg.vpss_regs_base + offset);
+ __raw_writel(val, oper_cfg.vpss_regs_base1 + offset);
}
static void dm355_select_ccdc_source(enum vpss_ccdc_source_sel src_sel)
@@ -98,12 +116,25 @@ static void dm355_select_ccdc_source(enum
vpss_ccdc_source_sel src_sel)
bl_regw(src_sel VPSS_HSSISEL_SHIFT, DM355_VPSSBL_CCDCMUX);
}
+static void dm365_select_ccdc_source(enum vpss_ccdc_source_sel src_sel)
+{
+ u32 temp = isp5_read(DM365_ISP5_CCDCMUX) ~CCD_SRC_SEL_MASK;
+
+ /* if we are using pattern generator, enable it */
+ if (src_sel == VPSS_PGLPBK || src_sel == VPSS_CCDCPG)
+ temp |= 0x08;
+
+ temp |= (src_sel CCD_SRC_SEL_SHIFT);
+ isp5_write(temp, DM365_ISP5_CCDCMUX);
+}
+
int vpss_select_ccdc_source(enum vpss_ccdc_source_sel src_sel)
{
if (!oper_cfg.hw_ops.select_ccdc_source)
return -1;
- dm355_select_ccdc_source(src_sel);
+ oper_cfg.hw_ops.select_ccdc_source(src_sel);
+
return 0;
}
EXPORT_SYMBOL(vpss_select_ccdc_source);
@@ -120,9 +151,56 @@ static int dm644x_clear_wbl_overflow(enum vpss_wbl_sel
wbl_sel)
mask = ~(mask wbl_sel);
val = bl_regr(DM644X_SBL_PCR_VPSS) mask;
bl_regw(val, DM644X_SBL_PCR_VPSS);
+
return 0;
}
+static void dm365_enable_irq(void)
+{
+ u32 current_val = isp5_read(DM365_VPSS_INTSEL1);
+ /*just enable INTSEL0 and INTSEL1 and leave everything else as is*/
+ current_val = ~(CCD_INT_SEL_MASK);
+ current_val |= BIT_MASK(8);
+ isp5_write(current_val, DM365_VPSS_INTSEL1);
+}
+
+void dm365_set_sync_pol(struct vpss_sync_pol sync)
+{
+ int val = 0;
+ val = isp5_read(DM365_ISP5_CCDCMUX);
+
+ val |= (sync.ccdpg_hdpol DM365_CCDC_PG_HD_POL_SHIFT);
+ val |= (sync.ccdpg_vdpol DM365_CCDC_PG_VD_POL_SHIFT);
+
+ isp5_write(val, DM365_ISP5_CCDCMUX);
+}
+
+void vpss_set_sync_pol(struct
[PATCH v1 1/4] DM365 Platform support for VPFE
From: Neil Sikka neilsi...@ti.com
This has platform and board setup changes to support the vpfe capture
driver for DM365 EVMs.
Reviewed-by: Muralidharan Karicheri m-kariche...@ti.com
Mandatory-Reviewer: Hans Verkuil hverk...@xs4all.nl
Mandatory-Reviewer: Kevin Hilman khil...@deeprootsystems.com
Signed-off-by: Neil Sikka neilsi...@ti.com
---
Applies to Kevin Hilman's linux-davinci repository
arch/arm/mach-davinci/board-dm365-evm.c| 71
arch/arm/mach-davinci/dm365.c | 68 ++
arch/arm/mach-davinci/include/mach/dm365.h |2 +
3 files changed, 141 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-davinci/board-dm365-evm.c
b/arch/arm/mach-davinci/board-dm365-evm.c
index f6adf79..757ad13 100644
--- a/arch/arm/mach-davinci/board-dm365-evm.c
+++ b/arch/arm/mach-davinci/board-dm365-evm.c
@@ -38,6 +38,8 @@
#include mach/common.h
#include mach/mmc.h
#include mach/nand.h
+#include linux/videodev2.h
+#include media/tvp514x.h
static inline int have_imager(void)
@@ -98,6 +100,11 @@ static inline int have_tvp7002(void)
static void __iomem *cpld;
+static struct tvp514x_platform_data tvp5146_pdata = {
+ .clk_polarity = 0,
+ .hs_polarity = 1,
+ .vs_polarity = 1
+};
/* NOTE: this is geared for the standard config, with a socketed
* 2 GByte Micron NAND (MT29F16G08FAA) using 128KB sectors. If you
@@ -210,6 +217,68 @@ static int cpld_mmc_get_ro(int module)
return !!(__raw_readb(cpld + CPLD_CARDSTAT) BIT(module ? 5 : 1));
}
+#define TVP514X_STD_ALL(V4L2_STD_NTSC | V4L2_STD_PAL)
+/* Inputs available at the TVP5146 */
+static struct v4l2_input tvp5146_inputs[] = {
+ {
+ .index = 0,
+ .name = Composite,
+ .type = V4L2_INPUT_TYPE_CAMERA,
+ .std = TVP514X_STD_ALL,
+ },
+ {
+ .index = 1,
+ .name = S-Video,
+ .type = V4L2_INPUT_TYPE_CAMERA,
+ .std = TVP514X_STD_ALL,
+ },
+};
+
+/*
+ * this is the route info for connecting each input to decoder
+ * ouput that goes to vpfe. There is a one to one correspondence
+ * with tvp5146_inputs
+ */
+static struct vpfe_route tvp5146_routes[] = {
+ {
+ .input = INPUT_CVBS_VI2B,
+ .output = OUTPUT_10BIT_422_EMBEDDED_SYNC,
+ },
+{
+ .input = INPUT_SVIDEO_VI2C_VI1C,
+ .output = OUTPUT_10BIT_422_EMBEDDED_SYNC,
+ },
+};
+
+static struct vpfe_subdev_info vpfe_sub_devs[] = {
+{
+ .module_name = tvp5146,
+ .grp_id = 0,
+ .num_inputs = ARRAY_SIZE(tvp5146_inputs),
+ .inputs = tvp5146_inputs,
+ .routes = tvp5146_routes,
+ .can_route = 1,
+ .ccdc_if_params = {
+ .if_type = VPFE_BT656,
+ .hdpol = VPFE_PINPOL_POSITIVE,
+ .vdpol = VPFE_PINPOL_POSITIVE,
+ },
+ .board_info = {
+ I2C_BOARD_INFO(tvp5146, 0x5d),
+ .platform_data = tvp5146_pdata,
+ },
+ }
+};
+
+static struct vpfe_config vpfe_cfg = {
+ .num_subdevs = ARRAY_SIZE(vpfe_sub_devs),
+ .sub_devs = vpfe_sub_devs,
+ .card_name = DM365 EVM,
+ .ccdc = DM365 ISIF,
+ .num_clocks = 1,
+ .clocks = {vpss_master},
+};
+
static struct davinci_mmc_config dm365evm_mmc_config = {
.get_cd = cpld_mmc_get_cd,
.get_ro = cpld_mmc_get_ro,
@@ -461,6 +530,8 @@ static struct davinci_uart_config uart_config __initdata = {
static void __init dm365_evm_map_io(void)
{
+ /* setup input configuration for VPFE input devices */
+ dm365_set_vpfe_config(vpfe_cfg);
dm365_init();
}
diff --git a/arch/arm/mach-davinci/dm365.c b/arch/arm/mach-davinci/dm365.c
index f8bac94..aa432d4 100644
--- a/arch/arm/mach-davinci/dm365.c
+++ b/arch/arm/mach-davinci/dm365.c
@@ -904,6 +904,62 @@ void __init dm365_init(void)
davinci_common_init(davinci_soc_info_dm365);
}
+static struct resource dm365_vpss_resources[] = {
+ {
+ /* VPSS ISP5 Base address */
+ .name = vpss,
+ .start = 0x01c7,
+ .end= 0x01c7 + 0xff,
+ .flags = IORESOURCE_MEM,
+ },
+ {
+ /* VPSS CLK Base address */
+ .name = vpss,
+ .start = 0x01c70200,
+ .end= 0x01c70200 + 0xff,
+ .flags = IORESOURCE_MEM,
+ },
+};
+
+static struct platform_device dm365_vpss_device = {
+ .name = vpss,
+ .id = -1,
+ .dev.platform_data = dm365_vpss,
+ .num_resources = ARRAY_SIZE(dm365_vpss_resources),
+ .resource =
[PATCH v1 4/4] Build system support for DM365 CCDC
From: Neil Sikka neilsi...@ti.com This patch sets up the build system for DM365 VPFE support Reviewed-by: Muralidharan Karicheri m-kariche...@ti.com Mandatory-Reviewer: Hans Verkuil hverk...@xs4all.nl Signed-off-by: Neil Sikka neilsi...@ti.com --- Applies to v4l-dvb linux-next repository drivers/media/video/Kconfig |9 + drivers/media/video/davinci/Makefile |3 ++- 2 files changed, 11 insertions(+), 1 deletions(-) diff --git a/drivers/media/video/Kconfig b/drivers/media/video/Kconfig index 1fa3c87..e0dd402 100644 --- a/drivers/media/video/Kconfig +++ b/drivers/media/video/Kconfig @@ -578,6 +578,15 @@ config VIDEO_DM355_CCDC To compile this driver as a module, choose M here: the module will be called vpfe. +config VIDEO_DM365_ISIF + tristate DM365 CCDC/ISIF HW module + depends on ARCH_DAVINCI_DM365 VIDEO_VPFE_CAPTURE + default y + help + Enables DM365 ISIF hw module. This is the hardware module for + configuring ISIF in VPFE to capture Raw Bayer RGB data from + a image sensor or YUV data from a YUV source. + source drivers/media/video/bt8xx/Kconfig config VIDEO_PMS diff --git a/drivers/media/video/davinci/Makefile b/drivers/media/video/davinci/Makefile index f44cad2..5f4c830 100644 --- a/drivers/media/video/davinci/Makefile +++ b/drivers/media/video/davinci/Makefile @@ -8,8 +8,9 @@ obj-$(CONFIG_VIDEO_DAVINCI_VPIF) += vpif.o #DM646x EVM Display driver obj-$(CONFIG_DISPLAY_DAVINCI_DM646X_EVM) += vpif_display.o -# Capture: DM6446 and DM355 +# Capture: DM6446, DM355, DM365 obj-$(CONFIG_VIDEO_VPSS_SYSTEM) += vpss.o obj-$(CONFIG_VIDEO_VPFE_CAPTURE) += vpfe_capture.o obj-$(CONFIG_VIDEO_DM6446_CCDC) += dm644x_ccdc.o obj-$(CONFIG_VIDEO_DM355_CCDC) += dm355_ccdc.o +obj-$(CONFIG_VIDEO_DM365_ISIF) += dm365_ccdc.o -- 1.6.0.4 -- 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 v1 - 1/5] DaVinci - restructuring code to support vpif capture driver
Hans, Would you like the architecture specific changes against v4l-dvb linux-next tree or linux-davinci ? I will rework both the vpfe and vpif patches as per your comment. Murali Karicheri Software Design Engineer Texas Instruments Inc. Germantown, MD 20874 new phone: 301-407-9583 Old Phone : 301-515-3736 (will be deprecated) email: m-kariche...@ti.com -Original Message- From: Hans Verkuil [mailto:hverk...@xs4all.nl] Sent: Monday, August 17, 2009 2:47 PM To: Karicheri, Muralidharan Cc: linux-media@vger.kernel.org; davinci-linux-open- sou...@linux.davincidsp.com; khil...@deeprootsystems.com Subject: Re: [PATCH v1 - 1/5] DaVinci - restructuring code to support vpif capture driver On Monday 17 August 2009 16:52:20 Karicheri, Muralidharan wrote: Hans, They are applied against davinci tree (also mentioned in the patch). General procedure what I follow is to create platform code against davinci tree and v4l patches against v4l-dvb linux-next tree. The architecture part of linux-next is not up to date. Davinci tree is at git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-davinci.git I must have missed the mention of this tree. I have a problem, though, as the current v4l-dvb repository doesn't compile against the linux-davinci git tree. And the only way I can get it to compile is to apply all five patches first. However, the whole tree should still compile after each patch is applied. And that goes wrong with your second patch where the Kconfig and Makefile are modified when the new sources aren't even added yet! What I would like to see is a patch series that starts with one patch that makes the current v4l-dvb tree compile again, then the arch patch is added, then a series of v4l-dvb patches in such an order that everything compiles after each step. Merging this is already complicated enough without breaking compilation in this way. 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: [PATCH v1 - 1/5] DaVinci - restructuring code to support vpif capture driver
On Monday 17 August 2009 22:10:04 Karicheri, Muralidharan wrote: Hans, Would you like the architecture specific changes against v4l-dvb linux-next tree or linux-davinci ? I will rework both the vpfe and vpif patches as per your comment. v4l-dvb linux-next. The current v4l-dvb at least compiles against that one, so that is the most appropriate tree to do the patches against. 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: [linux-dvb] au0828: experimental support for Syntek Teledongle [05e1:0400]
On Mon, Aug 17, 2009 at 4:25 PM, Malcolm Lewiscoyoteu...@gmail.com wrote:
Hi
I've been using the patches from
http://linuxtv.org/hg/~mkrufky/teledongle/rev/676e2f4475ed
on a Sabrent device in openSuSE and SLED, during testing with the
milestone 5 release of
11.2 and kernel version 2.6.31-rc5-git3-2-desktop there needs to be
some changes to the
au0828-cards.c patch to enable building a kmp module;
--- au0828-cards.c 2009-08-12 18:16:39.435886920 -0500
+++ au0828-cards.c.orig 2009-08-12 18:28:22.176126368 -0500
@@ -116,6 +116,12 @@
.tuner_addr = ADDR_UNSET,
.i2c_clk_divider = AU0828_I2C_CLK_250KHZ,
},
+ [AU0828_BOARD_SYNTEK_TELEDONGLE] = {
+ .name = Syntek Teledongle [EXPERIMENTAL],
+ .tuner_type = UNSET,
+ .tuner_addr = ADDR_UNSET,
+ .i2c_clk_divider = AU0828_I2C_CLK_250KHZ,
+ },
};
/* Tuner callback function for au0828 boards. Currently only needed
@@ -248,6 +254,7 @@
case AU0828_BOARD_HAUPPAUGE_HVR950Q:
case AU0828_BOARD_HAUPPAUGE_HVR950Q_MXL:
case AU0828_BOARD_HAUPPAUGE_WOODBURY:
+ case AU0828_BOARD_SYNTEK_TELEDONGLE: /* FIXME */
/* GPIO's
* 4 - CS5340
* 5 - AU8522 Demodulator
@@ -325,6 +332,8 @@
.driver_info = AU0828_BOARD_HAUPPAUGE_HVR950Q_MXL },
{ USB_DEVICE(0x2040, 0x8200),
.driver_info = AU0828_BOARD_HAUPPAUGE_WOODBURY },
+ { USB_DEVICE(0x05e1, 0x0400),
+ .driver_info = AU0828_BOARD_SYNTEK_TELEDONGLE },
{ },
};
There are two versions I'm building and src for both can be found here;
http://download.opensuse.org/repositories/home:/malcolmlewis/
Malcolm,
I would strongly advise against distributing packages based on these
patches... This code was never merged into the master branch because
it has potential to break devices at the hardware level, and it will
create a support nightmare, based on the fact that there are multiple
UNLIKE devices that use the same USB ID but actually contain different
hardware components. As the patch may enable support for ONE of the
variations, nobody has ever verified that the GPIO programming is safe
to use, and there is no way to prevent the potentially harmful code
from running on the wrong device.
I, personally, do not want the responsibility of explaining to users
that their usb sticks may be damaged because of code that got merged
into the kernel -- that's why the code is in a separate repository
until the issues can be dealt with. In general, users know that if
they have to manually apply patches themselves, that they are doing so
at their own risk.
If you succeed in getting your device to work, please let me know -- I
will be very interested to hear about it.
Good Luck,
Mike
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-dvb] au0828: experimental support for Syntek Teledongle [05e1:0400]
On Mon, Aug 17, 2009 at 3:59 PM, Michael Krufkymkru...@kernellabs.com wrote:
On Mon, Aug 17, 2009 at 4:25 PM, Malcolm Lewiscoyoteu...@gmail.com wrote:
Hi
I've been using the patches from
http://linuxtv.org/hg/~mkrufky/teledongle/rev/676e2f4475ed
on a Sabrent device in openSuSE and SLED, during testing with the
milestone 5 release of
11.2 and kernel version 2.6.31-rc5-git3-2-desktop there needs to be
some changes to the
au0828-cards.c patch to enable building a kmp module;
--- au0828-cards.c 2009-08-12 18:16:39.435886920 -0500
+++ au0828-cards.c.orig 2009-08-12 18:28:22.176126368 -0500
@@ -116,6 +116,12 @@
.tuner_addr = ADDR_UNSET,
.i2c_clk_divider = AU0828_I2C_CLK_250KHZ,
},
+ [AU0828_BOARD_SYNTEK_TELEDONGLE] = {
+ .name = Syntek Teledongle [EXPERIMENTAL],
+ .tuner_type = UNSET,
+ .tuner_addr = ADDR_UNSET,
+ .i2c_clk_divider = AU0828_I2C_CLK_250KHZ,
+ },
};
/* Tuner callback function for au0828 boards. Currently only needed
@@ -248,6 +254,7 @@
case AU0828_BOARD_HAUPPAUGE_HVR950Q:
case AU0828_BOARD_HAUPPAUGE_HVR950Q_MXL:
case AU0828_BOARD_HAUPPAUGE_WOODBURY:
+ case AU0828_BOARD_SYNTEK_TELEDONGLE: /* FIXME */
/* GPIO's
* 4 - CS5340
* 5 - AU8522 Demodulator
@@ -325,6 +332,8 @@
.driver_info = AU0828_BOARD_HAUPPAUGE_HVR950Q_MXL },
{ USB_DEVICE(0x2040, 0x8200),
.driver_info = AU0828_BOARD_HAUPPAUGE_WOODBURY },
+ { USB_DEVICE(0x05e1, 0x0400),
+ .driver_info = AU0828_BOARD_SYNTEK_TELEDONGLE },
{ },
};
There are two versions I'm building and src for both can be found here;
http://download.opensuse.org/repositories/home:/malcolmlewis/
Malcolm,
I would strongly advise against distributing packages based on these
patches... This code was never merged into the master branch because
it has potential to break devices at the hardware level, and it will
create a support nightmare, based on the fact that there are multiple
UNLIKE devices that use the same USB ID but actually contain different
hardware components. As the patch may enable support for ONE of the
variations, nobody has ever verified that the GPIO programming is safe
to use, and there is no way to prevent the potentially harmful code
from running on the wrong device.
I, personally, do not want the responsibility of explaining to users
that their usb sticks may be damaged because of code that got merged
into the kernel -- that's why the code is in a separate repository
until the issues can be dealt with. In general, users know that if
they have to manually apply patches themselves, that they are doing so
at their own risk.
If you succeed in getting your device to work, please let me know -- I
will be very interested to hear about it.
Good Luck,
Mike
___
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 Mike
Ahh, OK :) I can confirm I've had no issues using it with smplayer on
openSuSE 11.0, openSuSE 11.1 and openSuSE 11.2 M5 i586 (ViA Artigo and
ASUS 1000HE) and SLED 11 x86_64 (home build AMD 4400 X2 system).
System tunes into FTA HDTV great, have scan in different areas and all
scanned channels found have worked. (I'm in Mississippi)
I'm happy to do further testing if you can advise on what is required.
--
Cheers
Malcolm
--
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] quickcam_messenger.c: add support for all quickcam Messengers of the same family
On 21:33 Sun 16 Aug 2009, Mauro Carvalho Chehab wrote: Could you please check if stv06xx.c is properly working with those devices? Feel free to submit patches improving it, if needed. Alright, I asked the two users who reported the bug to test gspca_stv06xx.ko also. I will let you know how that goes. Cheers, Brandon -- 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 1/5 - v3] Adding new fields to add the vpfe capture enhancements
From: Muralidharan Karicheri m-kariche...@ti.com
Restructured the patch to apply cleanly. This will allow compilation after
applying each patch. To do this existing fields in the header files are
retained and removed later when the new fields are used.
Reviewed-by: Hans Verkuil hverk...@xs4all.nl
Signed-off-by: Muralidharan Karicheri m-kariche...@ti.com
---
Applies to V4L-DVB linux-next repository
include/media/davinci/vpfe_capture.h | 27 ---
1 files changed, 24 insertions(+), 3 deletions(-)
diff --git a/include/media/davinci/vpfe_capture.h
b/include/media/davinci/vpfe_capture.h
index 71d8982..196245e 100644
--- a/include/media/davinci/vpfe_capture.h
+++ b/include/media/davinci/vpfe_capture.h
@@ -47,6 +47,8 @@ struct vpfe_pixel_format {
struct v4l2_fmtdesc fmtdesc;
/* bytes per pixel */
int bpp;
+ /* decoder format */
+ u32 subdev_pix_fmt;
};
struct vpfe_std_info {
@@ -61,9 +63,16 @@ struct vpfe_route {
u32 output;
};
+enum vpfe_subdev_id {
+ VPFE_SUBDEV_TVP5146 = 1,
+ VPFE_SUBDEV_MT9T031 = 2
+};
+
struct vpfe_subdev_info {
- /* Sub device name */
+ /* Deprecated. Will be removed in the next patch */
char name[32];
+ /* Sub device module name */
+ char module_name[32];
/* Sub device group id */
int grp_id;
/* Number of inputs supported */
@@ -72,12 +81,16 @@ struct vpfe_subdev_info {
struct v4l2_input *inputs;
/* Sub dev routing information for each input */
struct vpfe_route *routes;
- /* check if sub dev supports routing */
- int can_route;
/* ccdc bus/interface configuration */
struct vpfe_hw_if_param ccdc_if_params;
/* i2c subdevice board info */
struct i2c_board_info board_info;
+ /* Is this a camera sub device ? */
+ unsigned is_camera:1;
+ /* check if sub dev supports routing */
+ unsigned can_route:1;
+ /* registered ? */
+ unsigned registered:1;
};
struct vpfe_config {
@@ -92,6 +105,12 @@ struct vpfe_config {
/* vpfe clock */
struct clk *vpssclk;
struct clk *slaveclk;
+ /* setup function for the input path */
+ int (*setup_input)(enum vpfe_subdev_id id);
+ /* number of clocks */
+ int num_clocks;
+ /* clocks used for vpfe capture */
+ char *clocks[];
};
struct vpfe_device {
@@ -102,6 +121,8 @@ struct vpfe_device {
struct v4l2_subdev **sd;
/* vpfe cfg */
struct vpfe_config *cfg;
+ /* clock ptrs for vpfe capture */
+ struct clk **clks;
/* V4l2 device */
struct v4l2_device v4l2_dev;
/* parent device */
--
1.6.0.4
--
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 2/5 - v3] V4L: ccdc driver - select MSP driver for CCDC input selection
From: Muralidharan Karicheri m-kariche...@ti.com Just being recreated to apply cleanly and compile. There were no comments against v1 of this patch. So no change from v1/v2 of the patch Reviewed-by: Hans Verkuil hverk...@xs4all.nl Signed-off-by: Muralidharan Karicheri m-kariche...@ti.com --- Applies to V4L-DVB linux-next repository drivers/media/video/Kconfig |4 +++- 1 files changed, 3 insertions(+), 1 deletions(-) diff --git a/drivers/media/video/Kconfig b/drivers/media/video/Kconfig index e8a6e4d..1fa3c87 100644 --- a/drivers/media/video/Kconfig +++ b/drivers/media/video/Kconfig @@ -565,13 +565,15 @@ config VIDEO_DM355_CCDC tristate DM355 CCDC HW module depends on ARCH_DAVINCI_DM355 VIDEO_VPFE_CAPTURE select VIDEO_VPSS_SYSTEM + select MFD_DM355EVM_MSP default y help Enables DM355 CCD hw module. DM355 CCDC hw interfaces with decoder modules such as TVP5146 over BT656 or sensor module such as MT9T001 over a raw interface. This module configures the interface and CCDC/ISIF to do - video frame capture from a slave decoders + video frame capture from a slave decoders. MFD_DM355EVM_MSP + is enabled to select input to CCDC at run time. To compile this driver as a module, choose M here: the module will be called vpfe. -- 1.6.0.4 -- 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 4/5 - v3] V4L-vpfe capture driver - adding support for camera capture
From: Muralidharan Karicheri m-kariche...@ti.com
Recreating this patch to apply cleanly and compile.
v2 of the patch incorporated following comments received against v1 patch
series.
1) retained vpfe_g_std() since for vbi support g_std handling in v4l2
framework
is not sufficient.
2) rename name field in vpfe_subdev_info to module_name and camera to
is_camera.
also grouped bit field variables
Additional features added on top v1 patch:-
2) vpfe_enable/disable_clock restructered to allow configuration of
required
clocks in vpfe_capture configuration. This is required for upcoming
DM365
support.
Reviewed-by: Hans Verkuil hverk...@xs4all.nl
Signed-off-by: Muralidharan Karicheri m-kariche...@ti.com
---
Applies to V4L-DVB linux-next repository
drivers/media/video/davinci/vpfe_capture.c | 545 +---
include/media/davinci/vpfe_capture.h |5 -
2 files changed, 413 insertions(+), 137 deletions(-)
diff --git a/drivers/media/video/davinci/vpfe_capture.c
b/drivers/media/video/davinci/vpfe_capture.c
index 402ce43..ff43446 100644
--- a/drivers/media/video/davinci/vpfe_capture.c
+++ b/drivers/media/video/davinci/vpfe_capture.c
@@ -59,10 +59,8 @@
*TODO list
* - Support multiple REQBUF after open
* - Support for de-allocating buffers through REQBUF
- * - Support for Raw Bayer RGB capture
* - Support for chaining Image Processor
* - Support for static allocation of buffers
- * - Support for USERPTR IO
* - Support for STREAMON before QBUF
* - Support for control ioctls
*/
@@ -79,11 +77,24 @@
static int debug;
static u32 numbuffers = 3;
static u32 bufsize = (720 * 576 * 2);
+static int interface;
+module_param(interface, bool, S_IRUGO);
module_param(numbuffers, uint, S_IRUGO);
module_param(bufsize, uint, S_IRUGO);
-module_param(debug, int, 0644);
-
+module_param(debug, bool, 0644);
+
+/**
+ * VPFE capture can be used for capturing video such as from TVP5146 or TVP7002
+ * and for capture raw bayer data from camera sensors such as MT9T031. At this
+ * point there is problem in co-existence of mt9t031 and tvp5146 due to i2c
+ * address collision. So set the variable below from bootargs to do either
video
+ * capture or camera capture.
+ * interface = 0 - video capture (from TVP514x or such),
+ * interface = 1 - Camera capture (from MT9T031 or such)
+ * Re-visit this when we fix the co-existence issue
+ */
+MODULE_PARM_DESC(interface, interface 0-1 (default:0));
MODULE_PARM_DESC(numbuffers, buffer count (default:3));
MODULE_PARM_DESC(bufsize, buffer size in bytes (default:720 x 576 x 2));
MODULE_PARM_DESC(debug, Debug level 0-1);
@@ -143,6 +154,7 @@ static const struct vpfe_pixel_format vpfe_pix_fmts[] = {
.pixelformat = V4L2_PIX_FMT_SBGGR8,
},
.bpp = 1,
+ .subdev_pix_fmt = V4L2_PIX_FMT_SGRBG10,
},
{
.fmtdesc = {
@@ -152,6 +164,7 @@ static const struct vpfe_pixel_format vpfe_pix_fmts[] = {
.pixelformat = V4L2_PIX_FMT_SBGGR16,
},
.bpp = 2,
+ .subdev_pix_fmt = V4L2_PIX_FMT_SGRBG10,
},
{
.fmtdesc = {
@@ -161,6 +174,7 @@ static const struct vpfe_pixel_format vpfe_pix_fmts[] = {
.pixelformat = V4L2_PIX_FMT_SGRBG10DPCM8,
},
.bpp = 1,
+ .subdev_pix_fmt = V4L2_PIX_FMT_SGRBG10,
},
{
.fmtdesc = {
@@ -170,6 +184,7 @@ static const struct vpfe_pixel_format vpfe_pix_fmts[] = {
.pixelformat = V4L2_PIX_FMT_UYVY,
},
.bpp = 2,
+ .subdev_pix_fmt = V4L2_PIX_FMT_UYVY,
},
{
.fmtdesc = {
@@ -179,6 +194,7 @@ static const struct vpfe_pixel_format vpfe_pix_fmts[] = {
.pixelformat = V4L2_PIX_FMT_YUYV,
},
.bpp = 2,
+ .subdev_pix_fmt = V4L2_PIX_FMT_UYVY,
},
{
.fmtdesc = {
@@ -188,12 +204,15 @@ static const struct vpfe_pixel_format vpfe_pix_fmts[] = {
.pixelformat = V4L2_PIX_FMT_NV12,
},
.bpp = 1,
+ .subdev_pix_fmt = V4L2_PIX_FMT_UYVY,
},
};
-/*
- * vpfe_lookup_pix_format()
- * lookup an entry in the vpfe pix format table based on pix_format
+/**
+ * vpfe_lookup_pix_format() - lookup an entry in the vpfe pix format table
+ * @pix_format: v4l pix format
+ * This function lookup an entry in the vpfe pix format table based on
+ * pix_format
*/
static const struct vpfe_pixel_format *vpfe_lookup_pix_format(u32 pix_format)
{
@@ -241,19 +260,19 @@ int vpfe_register_ccdc_device(struct ccdc_hw_device *dev)
* walk through it
[PATCH 5/5 - v3] V4L: ccdc driver - adding support for camera capture
From: Muralidharan Karicheri m-kariche...@ti.com
Recreating this to apply cleanly and compile
There was no comment against v1 of the patch. So no change in this file
Reviewed-by: Hans Verkuil hverk...@xs4all.nl
Signed-off-by: Muralidharan Karicheri m-kariche...@ti.com
---
Applies to V4L-DVB linux-next repository
drivers/media/video/davinci/dm355_ccdc.c | 16 +++-
drivers/media/video/davinci/dm644x_ccdc.c | 13 +
include/media/davinci/dm355_ccdc.h|2 +-
include/media/davinci/dm644x_ccdc.h |2 +-
4 files changed, 22 insertions(+), 11 deletions(-)
diff --git a/drivers/media/video/davinci/dm355_ccdc.c
b/drivers/media/video/davinci/dm355_ccdc.c
index 4629cab..4efffc2 100644
--- a/drivers/media/video/davinci/dm355_ccdc.c
+++ b/drivers/media/video/davinci/dm355_ccdc.c
@@ -92,7 +92,7 @@ static struct ccdc_params_raw ccdc_hw_params_raw = {
/* Object for CCDC ycbcr mode */
static struct ccdc_params_ycbcr ccdc_hw_params_ycbcr = {
- .win = CCDC_WIN_PAL,
+ .win = CCDC_WIN_NTSC,
.pix_fmt = CCDC_PIXFMT_YCBCR_8BIT,
.frm_fmt = CCDC_FRMFMT_INTERLACED,
.fid_pol = VPFE_PINPOL_POSITIVE,
@@ -548,7 +548,7 @@ static int ccdc_config_vdfc(struct ccdc_vertical_dft *dfc)
*/
static void ccdc_config_csc(struct ccdc_csc *csc)
{
- u32 val1, val2;
+ u32 val1 = 0, val2;
int i;
if (!csc-enable)
@@ -925,8 +925,11 @@ static int ccdc_set_hw_if_params(struct vpfe_hw_if_param
*params)
ccdc_hw_params_ycbcr.vd_pol = params-vdpol;
ccdc_hw_params_ycbcr.hd_pol = params-hdpol;
break;
+ case VPFE_RAW_BAYER:
+ ccdc_hw_params_raw.vd_pol = params-vdpol;
+ ccdc_hw_params_raw.hd_pol = params-hdpol;
+ break;
default:
- /* TODO add support for raw bayer here */
return -EINVAL;
}
return 0;
@@ -961,9 +964,12 @@ static struct ccdc_hw_device ccdc_hw_dev = {
static int dm355_ccdc_init(void)
{
+ int ret;
+
printk(KERN_NOTICE dm355_ccdc_init\n);
- if (vpfe_register_ccdc_device(ccdc_hw_dev) 0)
- return -1;
+ ret = vpfe_register_ccdc_device(ccdc_hw_dev);
+ if (ret 0)
+ return ret;
printk(KERN_NOTICE %s is registered with vpfe.\n,
ccdc_hw_dev.name);
return 0;
diff --git a/drivers/media/video/davinci/dm644x_ccdc.c
b/drivers/media/video/davinci/dm644x_ccdc.c
index 2f19a91..5dff8d9 100644
--- a/drivers/media/video/davinci/dm644x_ccdc.c
+++ b/drivers/media/video/davinci/dm644x_ccdc.c
@@ -65,7 +65,7 @@ static struct ccdc_params_raw ccdc_hw_params_raw = {
static struct ccdc_params_ycbcr ccdc_hw_params_ycbcr = {
.pix_fmt = CCDC_PIXFMT_YCBCR_8BIT,
.frm_fmt = CCDC_FRMFMT_INTERLACED,
- .win = CCDC_WIN_PAL,
+ .win = CCDC_WIN_NTSC,
.fid_pol = VPFE_PINPOL_POSITIVE,
.vd_pol = VPFE_PINPOL_POSITIVE,
.hd_pol = VPFE_PINPOL_POSITIVE,
@@ -825,8 +825,10 @@ static int ccdc_set_hw_if_params(struct vpfe_hw_if_param
*params)
ccdc_hw_params_ycbcr.vd_pol = params-vdpol;
ccdc_hw_params_ycbcr.hd_pol = params-hdpol;
break;
+ case VPFE_RAW_BAYER:
+ ccdc_hw_params_raw.vd_pol = params-vdpol;
+ ccdc_hw_params_raw.hd_pol = params-hdpol;
default:
- /* TODO add support for raw bayer here */
return -EINVAL;
}
return 0;
@@ -861,9 +863,12 @@ static struct ccdc_hw_device ccdc_hw_dev = {
static int dm644x_ccdc_init(void)
{
+ int ret;
+
printk(KERN_NOTICE dm644x_ccdc_init\n);
- if (vpfe_register_ccdc_device(ccdc_hw_dev) 0)
- return -1;
+ ret = vpfe_register_ccdc_device(ccdc_hw_dev);
+ if (ret 0)
+ return ret;
printk(KERN_NOTICE %s is registered with vpfe.\n,
ccdc_hw_dev.name);
return 0;
diff --git a/include/media/davinci/dm355_ccdc.h
b/include/media/davinci/dm355_ccdc.h
index df8a7b1..9395900 100644
--- a/include/media/davinci/dm355_ccdc.h
+++ b/include/media/davinci/dm355_ccdc.h
@@ -254,7 +254,7 @@ struct ccdc_config_params_raw {
#ifdef __KERNEL__
#include linux/io.h
-#define CCDC_WIN_PAL {0, 0, 720, 576}
+#define CCDC_WIN_NTSC {0, 0, 720, 480}
#define CCDC_WIN_VGA {0, 0, 640, 480}
struct ccdc_params_ycbcr {
diff --git a/include/media/davinci/dm644x_ccdc.h
b/include/media/davinci/dm644x_ccdc.h
index 3e178eb..e34a54a 100644
--- a/include/media/davinci/dm644x_ccdc.h
+++ b/include/media/davinci/dm644x_ccdc.h
@@ -131,7 +131,7 @@ struct ccdc_config_params_raw {
#define NUM_EXTRALINES 8
/* settings for commonly used video formats */
-#define CCDC_WIN_PAL {0, 0, 720, 576}
+#define CCDC_WIN_NTSC {0, 0, 720, 480}
/* ntsc square pixel */
#define CCDC_WIN_VGA {0, 0, (640 + NUM_EXTRAPIXELS), (480 + NUM_EXTRALINES)}
--
RE: [PATCH 1/5 - v3] Adding new fields to add the vpfe capture enhancements
Please ignore this since v4l prefix is missing in the subject.
Murali Karicheri
Software Design Engineer
Texas Instruments Inc.
Germantown, MD 20874
new phone: 301-407-9583
Old Phone : 301-515-3736 (will be deprecated)
email: m-kariche...@ti.com
-Original Message-
From: Karicheri, Muralidharan
Sent: Monday, August 17, 2009 7:19 PM
To: linux-media@vger.kernel.org
Cc: davinci-linux-open-sou...@linux.davincidsp.com; hverk...@xs4all.nl;
Karicheri, Muralidharan
Subject: [PATCH 1/5 - v3] Adding new fields to add the vpfe capture
enhancements
From: Muralidharan Karicheri m-kariche...@ti.com
Restructured the patch to apply cleanly. This will allow compilation after
applying each patch. To do this existing fields in the header files are
retained and removed later when the new fields are used.
Reviewed-by: Hans Verkuil hverk...@xs4all.nl
Signed-off-by: Muralidharan Karicheri m-kariche...@ti.com
---
Applies to V4L-DVB linux-next repository
include/media/davinci/vpfe_capture.h | 27 ---
1 files changed, 24 insertions(+), 3 deletions(-)
diff --git a/include/media/davinci/vpfe_capture.h
b/include/media/davinci/vpfe_capture.h
index 71d8982..196245e 100644
--- a/include/media/davinci/vpfe_capture.h
+++ b/include/media/davinci/vpfe_capture.h
@@ -47,6 +47,8 @@ struct vpfe_pixel_format {
struct v4l2_fmtdesc fmtdesc;
/* bytes per pixel */
int bpp;
+ /* decoder format */
+ u32 subdev_pix_fmt;
};
struct vpfe_std_info {
@@ -61,9 +63,16 @@ struct vpfe_route {
u32 output;
};
+enum vpfe_subdev_id {
+ VPFE_SUBDEV_TVP5146 = 1,
+ VPFE_SUBDEV_MT9T031 = 2
+};
+
struct vpfe_subdev_info {
- /* Sub device name */
+ /* Deprecated. Will be removed in the next patch */
char name[32];
+ /* Sub device module name */
+ char module_name[32];
/* Sub device group id */
int grp_id;
/* Number of inputs supported */
@@ -72,12 +81,16 @@ struct vpfe_subdev_info {
struct v4l2_input *inputs;
/* Sub dev routing information for each input */
struct vpfe_route *routes;
- /* check if sub dev supports routing */
- int can_route;
/* ccdc bus/interface configuration */
struct vpfe_hw_if_param ccdc_if_params;
/* i2c subdevice board info */
struct i2c_board_info board_info;
+ /* Is this a camera sub device ? */
+ unsigned is_camera:1;
+ /* check if sub dev supports routing */
+ unsigned can_route:1;
+ /* registered ? */
+ unsigned registered:1;
};
struct vpfe_config {
@@ -92,6 +105,12 @@ struct vpfe_config {
/* vpfe clock */
struct clk *vpssclk;
struct clk *slaveclk;
+ /* setup function for the input path */
+ int (*setup_input)(enum vpfe_subdev_id id);
+ /* number of clocks */
+ int num_clocks;
+ /* clocks used for vpfe capture */
+ char *clocks[];
};
struct vpfe_device {
@@ -102,6 +121,8 @@ struct vpfe_device {
struct v4l2_subdev **sd;
/* vpfe cfg */
struct vpfe_config *cfg;
+ /* clock ptrs for vpfe capture */
+ struct clk **clks;
/* V4l2 device */
struct v4l2_device v4l2_dev;
/* parent device */
--
1.6.0.4
--
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 v1 - 1/5] DaVinci - restructuring code to support vpif capture driver
Hans, I have re-send vpfe capture patch. I will re-send vpif patches tomorrow. Murali Karicheri Software Design Engineer Texas Instruments Inc. Germantown, MD 20874 new phone: 301-407-9583 Old Phone : 301-515-3736 (will be deprecated) email: m-kariche...@ti.com -Original Message- From: Hans Verkuil [mailto:hverk...@xs4all.nl] Sent: Monday, August 17, 2009 4:27 PM To: Karicheri, Muralidharan Cc: linux-media@vger.kernel.org; davinci-linux-open- sou...@linux.davincidsp.com; khil...@deeprootsystems.com Subject: Re: [PATCH v1 - 1/5] DaVinci - restructuring code to support vpif capture driver On Monday 17 August 2009 22:10:04 Karicheri, Muralidharan wrote: Hans, Would you like the architecture specific changes against v4l-dvb linux- next tree or linux-davinci ? I will rework both the vpfe and vpif patches as per your comment. v4l-dvb linux-next. The current v4l-dvb at least compiles against that one, so that is the most appropriate tree to do the patches against. 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: Pinnacle 300i antenna power kernel oops
Hi Martin, Am Sonntag, den 16.08.2009, 11:53 +0200 schrieb Martin Konopka: Hi, after my failed attempts to activate the external antenna power on an Pinnacle 310i, I bought a 300i. When I load the module saa7134_dvb with the option antenna_pwr = 1 I can indeed measure a voltage at the HF-Socket. But when my tv application tries to access the DVB device, I get a kernel oops. I have attached the log messages below. I'm using kernel 2.6.28-11-generic SMP i686 . The card works perfectly when the antenna power is disabled. Thanks for your help! Martin did not try to analyze the oops yet, but since the driver code for this card is unchanged since years, I suspect it happens on a higher level. You might try, if it still happens with recent v4l-dvb stuff. In that case, Michael Krufky eventually can confirm it, since he is the only one active on the lists currently having such a card. Depending on what other stuff he is working on, this might be still time consuming and an annoyance for him, but maybe he will have a look ;) Btw, I received an used Pinnacle 310i this afternoon, since I'm a little bit stuffed with mysteries on such. First impression on recent: The massive silver remote works, sometimes the driver fails to read the eeprom on load. Else, it has 100% the same reception quality for analog TV and DVB-T like all my other cards with tda8275a and without LNA support and is totally stable. I suspect now, that it is like on the HVR1110s currently, that we might have already different models with and without LNA there too. Cheers, Hermann [ 22.556260] BUG: unable to handle kernel paging request at f84b92d0 [ 22.556349] IP: [f7e8341a] pinnacle_antenna_pwr+0xda/0x140 [saa7134_dvb] [ 22.556412] *pde = 35d3f067 *pte = [ 22.556416] Oops: [#1] SMP [ 22.556500] last sysfs file: /sys/devices/virtual/net/pan0/flags [ 22.556532] Dumping ftrace buffer: [ 22.556563](ftrace buffer empty) [ 22.556592] Modules linked in: bridge stp bnep video output input_polldev nfsd auth_rpcgss exportfs nfs lockd nfs_acl sunrpc xfs it87 hwmon_vid lp mt352 saa7134_dvb videobuf_dvb dvb_core saa7134_alsa mt20xx tea5767 tda9887 tda8290 tuner snd_seq_dummy snd_seq_oss snd_hda_intel snd_seq_midi saa7134 snd_rawmidi snd_seq_midi_event snd_pcm_oss snd_mixer_oss ir_common snd_pcm videodev snd_seq fglrx(P) v4l1_compat compat_ioctl32 agpgart snd_seq_device snd_timer ppdev pcspkr i2c_piix4 v4l2_common videobuf_dma_sg videobuf_core tveeprom shpchp snd soundcore snd_page_alloc parport_pc parport usbhid floppy ohci1394 r8169 mii ieee1394 fbcon tileblit font bitblit softcursor [ 22.558582] [ 22.558612] Pid: 3361, comm: kdvb-ad-0-fe-0 Tainted: P (2.6.28-11-generic #42-Ubuntu) System Product Name [ 22.558646] EIP: 0060:[f7e8341a] EFLAGS: 00010282 CPU: 1 [ 22.558678] EIP is at pinnacle_antenna_pwr+0xda/0x140 [saa7134_dvb] [ 22.558710] EAX: f84b92d0 EBX: f5dd3000 ECX: 0165f000 EDX: 001b [ 22.558741] ESI: f5dd3000 EDI: f5dd3140 EBP: f5f4fe9c ESP: f5f4fe84 [ 22.558772] DS: 007b ES: 007b FS: 00d8 GS: SS: 0068 [ 22.558803] Process kdvb-ad-0-fe-0 (pid: 3361, ti=f5f4e000 task=f5a0d7f0 task.ti=f5f4e000) [ 22.558837] Stack: [ 22.558867] c03e7a3d 0001 f5f4fed0 f5c4d404 f5c4d404 f5dd3000 f5f4feec f7e837af [ 22.559090] 0003 25a0 c012888f f5a0d7f0 f5b48c90 f5f4fee4 c0102ab7 [ 22.559369] f5a0db2c c1e18280 f5f4feec 0043 c1e10002 f5f4fedc f1007100 f1cc [ 22.559677] Call Trace: [ 22.559707] [c03e7a3d] ? i2c_transfer+0x6d/0x90 [ 22.559770] [f7e837af] ? mt352_pinnacle_tuner_set_params+0xcf/0xe0 [saa7134_dvb] [ 22.559834] [c012888f] ? dequeue_task+0xcf/0x130 [ 22.559894] [c0102ab7] ? __switch_to+0xb7/0x1a0 [ 22.559954] [f7e9a3b8] ? mt352_set_parameters+0x2d8/0x410 [mt352] [ 22.560020] [c0122d58] ? default_spin_lock_flags+0x8/0x10 [ 22.560081] [c0502c0e] ? _spin_lock_irqsave+0x2e/0x40 [ 22.560142] [f7f0c871] ? dvb_frontend_swzigzag_autotune+0xc1/0x240 [dvb_core] [ 22.560202] [c05016e6] ? schedule_timeout+0x86/0xe0 [ 22.560202] [c0143db0] ? process_timeout+0x0/0x10 [ 22.560202] [f7f0d6e1] ? dvb_frontend_swzigzag+0x221/0x270 [dvb_core] [ 22.560202] [f7f0e037] ? dvb_frontend_thread+0x397/0x440 [dvb_core] [ 22.560202] [c014ecb0] ? autoremove_wake_function+0x0/0x50 [ 22.560202] [f7f0dca0] ? dvb_frontend_thread+0x0/0x440 [dvb_core] [ 22.560202] [c014e90c] ? kthread+0x3c/0x70 [ 22.560202] [c014e8d0] ? kthread+0x0/0x70 [ 22.560202] [c0105477] ? kernel_thread_helper+0x7/0x10 [ 22.560202] Code: c8 8b 93 20 01 00 00 81 c2 b4 01 00 00 8b 02 0d 00 00 00 10 89 02 b8 c6 a7 00 00 e8 91 96 44 c8 8b 83 20 01 00 00 05 d0 06 00 00 8b 30 a1 88 7f e8 f7 81 e6 00 00 00 08 85 c0 75 22 85 f6 75 15 [ 22.560202] EIP: [f7e8341a] pinnacle_antenna_pwr+0xda/0x140 [saa7134_dvb] SS:ESP 0068:f5f4fe84 -- To unsubscribe from
Re: KWorld UB435-Q support?
On Aug 17, 2009, at 3:28 PM, Thomas Fjellstrom wrote: Yeah, I've had absolutely no luck with it so far, and have returned it :( given your experience, and mine combined, I don't think its worth the time to fix it. Especially since I can't even tune a channel on the darn thing in any OS I have access to. Now, did you try it with some other OS before trying it under Linux, and it failed to work, or did you only try other OS after trying under Linux w/that tree? There's some concern that perhaps the stick might be getting neutered on the Linux side by an incorrect gpio setting or something... But my stick worked (flaky usb connection aside) for quite some time before it stopped working, even with lots of unplugging and replugging over several days while working on the driver... It did indeed have trouble keeping a connection, but when ever it lost connection, I got that message. And the driver is pretty much stuck. can't rmmod it, and it won't redetect the stick, so every single time it looses connection, I have to reboot. Hardly a good way to work. Indeed. I wonder if there are bad solder joints in these, or what?... Mine's dead, yours is dead, Mike Krufky had to RMA his first one and his second one seems it might be dead too... :\ -- Jarod Wilson ja...@wilsonet.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
