Re: [PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-core2

2009-08-17 Thread Hans Verkuil
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

2009-08-17 Thread Guennadi Liakhovetski
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

2009-08-17 Thread seth
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

2009-08-17 Thread Guennadi Liakhovetski
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/

2009-08-17 Thread Patrick Boettcher

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

2009-08-17 Thread Bert Haverkamp
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

2009-08-17 Thread Karicheri, Muralidharan
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

2009-08-17 Thread Ryan Raasch

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

2009-08-17 Thread Karicheri, Muralidharan
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?

2009-08-17 Thread Jarod Wilson

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

2009-08-17 Thread Karicheri, Muralidharan
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

2009-08-17 Thread Jim Paris
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

2009-08-17 Thread Darren Wilkinson

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

2009-08-17 Thread Jean-Francois Moine
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

2009-08-17 Thread Karicheri, Muralidharan
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

2009-08-17 Thread Hans Verkuil
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

2009-08-17 Thread Hans Verkuil
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

2009-08-17 Thread Hans Verkuil
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?

2009-08-17 Thread Thomas Fjellstrom
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

2009-08-17 Thread neilsikka
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

2009-08-17 Thread neilsikka
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

2009-08-17 Thread neilsikka
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

2009-08-17 Thread neilsikka
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

2009-08-17 Thread neilsikka
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

2009-08-17 Thread neilsikka
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

2009-08-17 Thread neilsikka
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

2009-08-17 Thread Karicheri, Muralidharan
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

2009-08-17 Thread Sikka, Neil
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

2009-08-17 Thread neilsikka
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

2009-08-17 Thread neilsikka
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

2009-08-17 Thread neilsikka
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

2009-08-17 Thread neilsikka
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

2009-08-17 Thread Karicheri, Muralidharan
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

2009-08-17 Thread Hans Verkuil
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]

2009-08-17 Thread Michael Krufky
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]

2009-08-17 Thread Malcolm Lewis
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

2009-08-17 Thread Brandon Philips
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

2009-08-17 Thread m-karicheri2
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

2009-08-17 Thread m-karicheri2
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 3/5 - v3] DaVinci: platform changes to support vpfe camera capture Signed-off-by: Muralidharan Karicheri m-kariche...@ti.com

2009-08-17 Thread m-karicheri2
From: Muralidharan Karicheri m-kariche...@ti.com

Recreating the patch to apply cleanly and compile.

There were no comments against v1 of this patch. So no change from v1/v2 of 
this patch

Reviewed-by: Hans Verkuil hverk...@xs4all.nl

Signed-off-by: Muralidharan Karicheri m-kariche...@ti.com
---
Applies to V4L-DVB linux-next repository
 arch/arm/mach-davinci/board-dm355-evm.c  |  140 +-
 arch/arm/mach-davinci/board-dm644x-evm.c |6 +-
 2 files changed, 140 insertions(+), 6 deletions(-)

diff --git a/arch/arm/mach-davinci/board-dm355-evm.c 
b/arch/arm/mach-davinci/board-dm355-evm.c
index 605bf03..8f2842a 100644
--- a/arch/arm/mach-davinci/board-dm355-evm.c
+++ b/arch/arm/mach-davinci/board-dm355-evm.c
@@ -24,6 +24,7 @@
 #include media/tvp514x.h
 #include linux/spi/spi.h
 #include linux/spi/eeprom.h
+#include linux/i2c/dm355evm_msp.h
 
 #include asm/setup.h
 #include asm/mach-types.h
@@ -136,14 +137,58 @@ static void dm355evm_mmcsd_gpios(unsigned gpio)
dm355evm_mmc_gpios = gpio;
 }
 
+#define PCA9543A_I2C_ADDR   (0x73)
+
+static struct i2c_client *pca9543a;
+
+static int pca9543a_probe(struct i2c_client *client,
+   const struct i2c_device_id *id)
+{
+   pca9543a = client;
+   return 0;
+}
+
+static int pca9543a_remove(struct i2c_client *client)
+{
+   pca9543a = NULL;
+   return 0;
+}
+
+static const struct i2c_device_id pca9543a_ids[] = {
+   { PCA9543A, 0, },
+   { /* end of list */ },
+};
+
+/* This is for i2c driver for the MT9T031 header i2c switch */
+static struct i2c_driver pca9543a_driver = {
+   .driver.name= PCA9543A,
+   .id_table   = pca9543a_ids,
+   .probe  = pca9543a_probe,
+   .remove = pca9543a_remove,
+};
+
 static struct i2c_board_info dm355evm_i2c_info[] = {
{   I2C_BOARD_INFO(dm355evm_msp, 0x25),
.platform_data = dm355evm_mmcsd_gpios,
},
+   {
+   I2C_BOARD_INFO(PCA9543A, 0x73),
+   },
/* { plus irq  }, */
/* { I2C_BOARD_INFO(tlv320aic3x, 0x1b), }, */
 };
 
+/* have_sensor() - Check if we have support for sensor interface */
+static inline int have_sensor(void)
+{
+#if defined(CONFIG_SOC_CAMERA_MT9T031) || \
+defined(CONFIG_SOC_CAMERA_MT9T031_MODULE)
+   return 1;
+#else
+   return 0;
+#endif
+}
+
 static void __init evm_init_i2c(void)
 {
davinci_init_i2c(i2c_pdata);
@@ -151,7 +196,8 @@ static void __init evm_init_i2c(void)
gpio_request(5, dm355evm_msp);
gpio_direction_input(5);
dm355evm_i2c_info[0].irq = gpio_to_irq(5);
-
+   if (have_sensor())
+   i2c_add_driver(pca9543a_driver);
i2c_register_board_info(1, dm355evm_i2c_info,
ARRAY_SIZE(dm355evm_i2c_info));
 }
@@ -180,6 +226,72 @@ static struct platform_device dm355evm_dm9000 = {
.num_resources  = ARRAY_SIZE(dm355evm_dm9000_rsrc),
 };
 
+/**
+ * dm355_enable_i2c_switch() - Enable/Disable I2C switch PCA9543A for sensor
+ * @en: enable/disbale flag
+ */
+static int dm355evm_enable_i2c_switch(int en)
+{
+   static char val = 1;
+   int status;
+   struct i2c_msg msg = {
+   .flags = 0,
+   .len = 1,
+   .buf = val,
+   };
+
+   if (!en)
+   val = 0;
+
+   if (!pca9543a)
+   return -ENXIO;
+
+   msg.addr = pca9543a-addr;
+   /* turn i2c switch, pca9543a, on/off */
+   status = i2c_transfer(pca9543a-adapter, msg, 1);
+   return status;
+}
+
+/**
+ * dm355evm_setup_video_input() - setup video data path and i2c
+ * @id: sub device id
+ */
+static int dm355evm_setup_video_input(enum vpfe_subdev_id id)
+{
+   int ret;
+
+   switch (id) {
+   case VPFE_SUBDEV_MT9T031:
+   {
+   ret = dm355evm_msp_write(MSP_VIDEO_IMAGER,
+DM355EVM_MSP_VIDEO_IN);
+   if (ret = 0)
+   ret = dm355evm_enable_i2c_switch(1);
+   else
+   /* switch off i2c switch since we failed */
+   ret = dm355evm_enable_i2c_switch(0);
+   break;
+   }
+   case VPFE_SUBDEV_TVP5146:
+   {
+   ret = dm355evm_msp_write(0, DM355EVM_MSP_VIDEO_IN);
+   break;
+   }
+   default:
+   return -EINVAL;
+   }
+   return (ret = 0 ? 0 : ret);
+}
+
+/* Input available at the mt9t031 */
+static struct v4l2_input mt9t031_inputs[] = {
+   {
+   .index = 0,
+   .name = Camera,
+   .type = V4L2_INPUT_TYPE_CAMERA,
+   }
+};
+
 static struct tvp514x_platform_data tvp5146_pdata = {
.clk_polarity = 0,
.hs_polarity = 1,
@@ -203,7 +315,7 @@ static struct v4l2_input tvp5146_inputs[] = {
},
 };
 
-/*
+/**
  * this is the route info for connecting each input to decoder
  * ouput that goes to vpfe. There 

[PATCH 4/5 - v3] V4L-vpfe capture driver - adding support for camera capture

2009-08-17 Thread m-karicheri2
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

2009-08-17 Thread m-karicheri2
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

2009-08-17 Thread Karicheri, Muralidharan
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

2009-08-17 Thread Karicheri, Muralidharan
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

2009-08-17 Thread hermann pitton
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?

2009-08-17 Thread Jarod Wilson

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