Re: OMAP3 ISP and camera drivers (update 2)

2009-06-23 Thread Tuukka.O Toivonen
On Monday 22 June 2009 17:00:53 ext Dongsoo Kim wrote:
 OK, what I'm afraid is that even though the device could be opened and  
 recognized as a v4l2 device but has no capability should be weird.  
 Actually I'm not sure about this case is spec-in or not.
 In my opinion it should be better when the camera interface (or ISP)  
 has no int device (or subdev) attahced on it, no device node mounted  
 in /dev or returning ENODEV. But before that, I'm very curious about  
 why you made in that way.

We had to be able to use other slave devices (eg. flash)
before attaching the actual camera module.

- Tuukka
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[GIT PATCHES for 2.6.31] V4L/DVB updates

2009-06-23 Thread Mauro Carvalho Chehab
Linus,

Please pull from:
ssh://master.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-2.6.git 
for_linus

For yet another series of improvements. 

Probably one of the most more visible to the users is the support 
for Logitech cameras based on stv06xx chipset. This also removes the 
driver need for merging a few out-of-tree driver for those cameras.

With the improvements on gspca, we'll get rid of two V4L1 only drivers 
on some future version. I'll later update the 
Documentation/feature-removal-schedule.txt to reflect those changes.

The rest of the series are bug fixes, a few api improvements for 
embedded, and usual new board additions. The full log is enclosed.

Cheers,
Mauro.

---

 Documentation/video4linux/CARDLIST.cx88|6 +-
 Documentation/video4linux/CARDLIST.em28xx  |1 +
 Documentation/video4linux/v4l2-framework.txt   |   24 +
 drivers/media/common/ir-keymaps.c  |   23 +
 drivers/media/dvb/frontends/stv0900.h  |7 +-
 drivers/media/dvb/frontends/stv0900_core.c |  100 ++-
 drivers/media/dvb/frontends/stv0900_priv.h |2 +
 drivers/media/dvb/frontends/stv090x.c  |   11 +-
 drivers/media/dvb/frontends/tda10048.c |1 +
 drivers/media/dvb/siano/smscoreapi.c   |4 +-
 drivers/media/radio/radio-tea5764.c|4 +-
 drivers/media/video/Kconfig|6 +-
 drivers/media/video/cx18/cx18-controls.c   |2 +
 drivers/media/video/cx231xx/cx231xx-avcore.c   |   19 +-
 drivers/media/video/cx231xx/cx231xx-video.c|   26 +-
 drivers/media/video/cx231xx/cx231xx.h  |3 -
 drivers/media/video/cx2341x.c  |2 +
 drivers/media/video/cx23885/cx23885-dvb.c  |   33 +-
 drivers/media/video/cx23885/cx23885-video.c|   11 +-
 drivers/media/video/cx88/cx88-cards.c  |   94 ++-
 drivers/media/video/cx88/cx88-video.c  |   11 +-
 drivers/media/video/em28xx/em28xx-cards.c  |   56 ++
 drivers/media/video/em28xx/em28xx-dvb.c|1 +
 drivers/media/video/em28xx/em28xx-video.c  |   38 +-
 drivers/media/video/em28xx/em28xx.h|1 +
 drivers/media/video/gspca/gspca.c  |8 +-
 drivers/media/video/gspca/ov519.c  |  981 ++--
 drivers/media/video/gspca/sonixj.c |  181 +++-
 drivers/media/video/gspca/stv06xx/Makefile |3 +-
 drivers/media/video/gspca/stv06xx/stv06xx.c|   53 +-
 drivers/media/video/gspca/stv06xx/stv06xx.h|   11 +
 drivers/media/video/gspca/stv06xx/stv06xx_hdcs.c   |   10 +-
 drivers/media/video/gspca/stv06xx/stv06xx_sensor.h |3 +-
 drivers/media/video/gspca/stv06xx/stv06xx_st6422.c |  453 +
 drivers/media/video/gspca/stv06xx/stv06xx_st6422.h |   59 ++
 drivers/media/video/ivtv/ivtv-controls.c   |2 +
 drivers/media/video/mt9m001.c  |   12 +-
 drivers/media/video/mt9t031.c  |   14 +-
 drivers/media/video/mt9v022.c  |   12 +-
 drivers/media/video/ov511.c|2 -
 drivers/media/video/pvrusb2/pvrusb2-audio.c|   14 +-
 drivers/media/video/pvrusb2/pvrusb2-cs53l32a.c |   24 +-
 drivers/media/video/pvrusb2/pvrusb2-cx2584x-v4l.c  |   37 +-
 drivers/media/video/pvrusb2/pvrusb2-hdw.c  |   60 +-
 drivers/media/video/pvrusb2/pvrusb2-video-v4l.c|   35 +-
 drivers/media/video/pxa_camera.c   |   34 +-
 drivers/media/video/saa7134/saa7134-video.c|   11 +-
 drivers/media/video/sh_mobile_ceu_camera.c |   12 +-
 drivers/media/video/tcm825x.c  |4 +-
 drivers/media/video/usbvideo/Kconfig   |5 +-
 drivers/media/video/v4l2-common.c  |  181 -
 drivers/media/video/vivi.c |   11 +-
 drivers/media/video/w9968cf.c  |   35 +-
 drivers/media/video/zoran/zoran_driver.c   |   14 +-
 include/linux/videodev2.h  |4 +-
 include/media/ir-common.h  |2 +
 include/media/v4l2-common.h|   26 +
 include/media/v4l2-i2c-drv.h   |5 +-
 include/media/v4l2-subdev.h|7 +-
 59 files changed, 2322 insertions(+), 489 deletions(-)
 create mode 100644 drivers/media/video/gspca/stv06xx/stv06xx_st6422.c
 create mode 100644 drivers/media/video/gspca/stv06xx/stv06xx_st6422.h

Abylay Ospan (2):
  V4L/DVB (12096): Bug fix: stv0900 register read must using i2c in one 
transaction
  V4L/DVB (12097): Implement reading uncorrected blocks for stv0900

Devin Heitmueller (3):
  V4L/DVB (12100): em28xx: make sure the analog GPIOs are set if we used a 
card hint
  V4L/DVB (12101): em28xx: add support for EVGA inDtube
  V4L/DVB (12102): em28xx: add Remote control support for 

Re: lsmod path hardcoded in v4l/Makefile

2009-06-23 Thread Matthias Schwarzott
On Dienstag, 23. Juni 2009, Andy Walls wrote:
 On Mon, 2009-06-22 at 16:36 +0200, Matthias Schwarzott wrote:
  Hi list!
 
  It seems the path to lsmod tool is hardcoded in the Makefile for
  out-of-tree building of v4l-dvb.
  Now at least gentoo has moved lsmod from /sbin to /bin.
  Additionally it is bad style (or at least I am told so), to not rely on
  $PATH but hardcode pathes for tools that should be in $PATH.

 It's a potential security hole to rely on $PATH instead of absolute
 paths when running a command as root.

Shouldn't $PATH of root be considered safe? Else the distro or the system 
setup is doing something worse, and can't be improved by using fixed pathes 
in some scripts and Makefiles.

Regards
Matthias
--
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: lsmod path hardcoded in v4l/Makefile

2009-06-23 Thread Matthias Schwarzott
On Dienstag, 23. Juni 2009, Trent Piepho wrote:
 On Mon, 22 Jun 2009, Andy Walls wrote:
  On Mon, 2009-06-22 at 16:36 +0200, Matthias Schwarzott wrote:
   Hi list!
  
   It seems the path to lsmod tool is hardcoded in the Makefile for
   out-of-tree building of v4l-dvb.
   Now at least gentoo has moved lsmod from /sbin to /bin.

 Won't your patch cause breakage for everyone who hasn't moved lsmod from
 /sbin and doesn't have sbin in the path?  Which was, and perhaps still is,
 the most common situation?  It would be better to do something that does
 not break things that used to work.

root without sbin in path is bad and broken, isn't it?
If you really think this is too common, we could add
PATH=/sbin:/bin:$PATH
at the start of the Makefile.

Regards
Matthias
--
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: Seeking recommendation for DVB-S PCI card with on-card CI

2009-06-23 Thread Thomas Kernen

Andy Zivkovic wrote:

Are these the same boards and/or different revisions? Are they supported by
the Mantis driver including the CI? This part I wasn't able to confirm from
my search.


Thomas,

The maintis driver currently doesn't support CI. Unfortunately I
bought a Twinhan SP300 (1034) before I knew this, so I now have a
DVB-S card that is effectively useless to me, but I'm hopeful someone
will fix the driver one day (although I bought the card months ago and
I'm close to cancelling my sat subscription since the set top box I
have is crap, so I don't watch it enough to justify the monthly fees).

In mid May, Manu, who I think is a (the?) mantis developer, posted on
this list saying he hadn't had time to work on mantis CI for the 2
months prior to that. I haven't noticed anything new since then, so I
don't know where it's at.



Andy,

Thanks for the feedback, that was what I feared (CI not supported). 
Better to know ahead of time that after ordering such a card


Manu,

Any chance you would be able to comment on the planned roadmap for the 
CI support on the Azurewave/Twinham 1034 based cards?


All,

Are there any known working PCI based solutions that have the CI slot on 
the card itself? I'm attempting to find something that can be self 
contained within a single PCI slot.


Regards,
Thomas
--
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: lsmod path hardcoded in v4l/Makefile

2009-06-23 Thread Matthias Schwarzott
On Dienstag, 23. Juni 2009, Theodore Kilgore wrote:
 On Mon, 22 Jun 2009, Andy Walls wrote:
  On Mon, 2009-06-22 at 16:36 +0200, Matthias Schwarzott wrote:
  Hi list!
 
  It seems the path to lsmod tool is hardcoded in the Makefile for
  out-of-tree building of v4l-dvb.
  Now at least gentoo has moved lsmod from /sbin to /bin.

 Sorry, but is it considered impertinent to ask why that lsmod should be
 moved from /sbin (system binaries, and lsmod certainly is one of those)
 and stick it into /bin instead? Is there any cogent reason for doing a

/sbin are binaries that only root should use. But lsmod can be used by users, 
too.
Suse also has only /bin/lsmod I think.
I don't know too much about the reason for the move, but it was long ago - 
version 0.9.11 contained that move and was released around year 2003.
Gentoo ebuild added /sbin/lsmod as compat symlink for things still hardcoding 
the path, but that was removed 2009 - 6 years should be enough.

 thing like that, which may have escaped my attention? Unless one is making
 some very small distro for some very small hardware and (say) one of /bin
 and /sbin is symlinked to the other, I find a change like that to be
 extremely puzzling. So, really. Why?
For a real answer to why, do ask module-init-tools maintainer.

Regards
Matthias
--
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: Sakar 57379 USB Digital Video Camera...

2009-06-23 Thread Andy Walls
On Mon, 2009-06-22 at 10:51 -0500, Theodore Kilgore wrote:
 
 On Mon, 22 Jun 2009, Andy Walls wrote:
 
  On Sun, 2009-06-21 at 22:39 -0500, Theodore Kilgore wrote:
  Andy,
 
  You are right. Your camera is emitting JPEG while streaming. I just
  succeeded in creating an image which resembles your test picture by
  extracting the frame data for one frame, tacking on a header, and running
  hex2bin on the combined file. I did not get the thing quite right, because
  your header is from your JPEG photo (640x480) and your stream is probably
  320x240. But I got something out which is obviously recognizable.
 
  Excellent.  Going from It may never work to something recognizable
  in one weekend is good progress.
 
 Well, sometimes the easy and obvious just works, and one is lucky. If only 
 they were all that easy. 

I'd contend most would be easy and obvious, as anything created by
people is usually easy to understand.  People are generally lazy and
want to avoid what they perceive as extra effort.  If you couple that
with management pressure on engineers to keep costs down and maintain
project schedules, you often end up with very simple solutions.

The data encoding used by the camera is indicative of that.  For this
camera, the engineers decided to simply drop the (M)JPEG headers to save
USB communications bandwidth instead of using a different, better
compression algorithm; or a imlementing new USB 2.0 interface.


 Besides, as we well know, this list is a place 
 where geniuses hang out. So perhaps some of the pixie dust has rubbed off 
 on us.

I thought genius was inspiration and perspiration. Pixie dust - I knew
Edison wasn't telling the whole truth. ;)



 
  Therefore with a little bit of further tweaking it will presumably come
  out exactly so. Namely, I have to remember where to stick the two
  dimensions into the header.
 
  Yes, as far as I'm concerned the problem is solved.  The details are
  left as an exercise for the reader. ;)
 
 
 I will try to get on it. There is nothing left but details, but there are 
 lots of those.

Yes, I agree.  Getting those right is no small task.


 The first one is to get the header exactly right.

Well,  given that the Windows driver has the AVI video stream FourCC
'vids' appearing four or five times, I suspect there is more than 1
header template that the Windows driver can tack on to the incoming
stream.  I'm guessing that which one is used, depends on how the camera
stream is initialized.

There are probably all sorts of header permutations that will yield
viewable but suboptimal reconstruction. :(

Then again it's a cheap webcam, so by definition any image is probably
suboptimal.



  Then 
 there is the question, what is _my_ camera doing? I did not check that 
 yet. And so on. So it is an algorithm now, but many steps remain to be 
 completed.

Yes.  I agree.

 
 
  I'm not up to speed on Linux webcam kernel to userspace API details.
  However, might I suggest going forward for testing at least, that when
  one starts the webcam streaming, the driver emit the stream in the form
  of an AVI.  You'd need an AVI header declaring only an MJPEG 'vids'
  stream - no 'auds' nor 'idx' - and a 'movi' section with RIFF/AVI chunks
  that have MJPEG headers and the webcam payload.
 
 For all I know, it might be just a matter of following down a standard 
 path. Perhaps this is all handled already in libv4lconvert, and it is 
 merely a matter of plugging into that. I haven't checked yet, but that is 
 more or less what I expect right now.


Ah, OK.

 
  I haven't seen evidence that audio comes from the webcam when it is
  streaming, but I haven't looked very much either.
 
 Same. Actually, my impression is that these cameras can not walk and chew 
 gum at the same time. I would suspect that the audio is an either/or kind 
 of thing. Either on, and it can record audio but not stream it, or off. I 
 would be very surprised if an el cheapo like the one I have could do more. 
 I could be wrong, of course. Perhaps both of us ought to check closely.

I know it can simultaneously record audio and video to an AVI file in
it's local storage.  I'm thinking it would not make sense to shovel over
audio in webcam mode anyway, as most computers have their own microphone
to collect sound.


 
  In retrospect, I should have used the 6x7 (or 6x9) flash card, so the
  answer would have been 42. :)
 
 Well, then there would be no mysteries left, would there? We couldn't have 
 that.
 
 This is Monday, and I have to go off to the salt mine. I may be able to 
 get back to this after coming home from the class.

I have no timeline in mind.  Having this webcam work will simply be a
nice to have.  I'm available for testing and any
investigation/research that you don't have time to do.

Regards,
Andy


 Theodore Kilgore
 

--
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  

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

2009-06-23 Thread Mauro Carvalho Chehab
Em Mon, 22 Jun 2009 11:02:58 -0500
Karicheri, Muralidharan m-kariche...@ti.com escreveu:

 Hi,
 
 Snip
  
   -/**
   +/*
 * struct tvp514x_decoder - TVP5146/47 decoder object
   - * @v4l2_int_device: Slave handle
   - * @tvp514x_slave: Slave pointer which is used by @v4l2_int_device
   + * @sd: Subdevice Slave handle
 * @tvp514x_regs: copy of hw's regs with preset values.
 * @pdata: Board specific
   - * @client: I2C client data
   - * @id: Entry from I2C table
 * @ver: Chip version
   - * @state: TVP5146/47 decoder state - detected or not-detected
   + * @streaming: TVP5146/47 decoder streaming - enabled or disabled.
 * @pix: Current pixel format
 * @num_fmts: Number of formats
 * @fmt_list: Format list
 * @current_std: Current standard
 * @num_stds: Number of standards
 * @std_list: Standards list
   - * @route: input and output routing at chip level
   + * @input: Input routing at chip level
   + * @output: Output routing at chip level
 */
  
   Please read Documentation/kernel-doc-nano-HOWTO.txt for the proper
   format. Basically, it should be like this example:
  
   /**
* foobar() - short function description of foobar
* @arg1:   Describe the first argument to foobar.
* @arg2:   Describe the second argument to foobar.
*  One can provide multiple line descriptions
*  for arguments.
*
* A longer description, with more discussion of the function foobar()
* that might be useful to those using or modifying it.  Begins with
* empty comment line, and may include additional embedded empty
* comment lines.
*
* The longer description can have multiple paragraphs.
**/
  
 But kernel-doc-nano-HOWTO.txt says it should be of the form
 /**
  * foobar() - short function description of foobar
  * @arg1:   Describe the first argument to foobar.
  * @arg2:   Describe the second argument to foobar.
  *  One can provide multiple line descriptions
  *  for arguments.
  *
  * A longer description, with more discussion of the function foobar()
  * that might be useful to those using or modifying it.  Begins with
  * empty comment line, and may include additional embedded empty
  * comment lines.
  *
  * The longer description can have multiple paragraphs.
  */
 
 Only one * followed by slash as */, not **/ as you have mentioned.
 Please confirm so that I can send you a patch to correct this.

You're right. It seems that I was using an older version of the doc, since it
used to be like above, on the past versions of the doc:

commit f40b45a2e45b0f02aeedfcfbb28d8e2d4b8b86b1
Author: Randy Dunlap randy.dun...@oracle.com
Date:   Wed Feb 11 13:04:31 2009 -0800

kernel-doc: preferred ending marker and examples

Fix kernel-doc-nano-HOWTO.txt to use */ as the ending marker in kernel-doc
examples and state that */ is the preferred ending marker.

Signed-off-by: Randy Dunlap randy.dun...@oracle.com
Reported-by: Robert Love robert.w.l...@intel.com
Signed-off-by: Andrew Morton a...@linux-foundation.org
Signed-off-by: Linus Torvalds torva...@linux-foundation.org

diff --git a/Documentation/kernel-doc-nano-HOWTO.txt 
b/Documentation/kernel-doc-nano-HOWTO.txt
index d73fbd2..026ec7d 100644
--- a/Documentation/kernel-doc-nano-HOWTO.txt
+++ b/Documentation/kernel-doc-nano-HOWTO.txt
@@ -43,7 +43,8 @@ Only comments so marked will be considered by the kernel-doc 
scripts,
 and any comment so marked must be in kernel-doc format.  Do not use
 /** to be begin a comment block unless the comment block contains
 kernel-doc formatted comments.  The closing comment marker for
-kernel-doc comments can be either */ or **/.
+kernel-doc comments can be either */ or **/, but */ is
+preferred in the Linux kernel tree.
 
 Kernel-doc comments should be placed just before the function
 or data structure being described.
@@ -63,7 +64,7 @@ Example kernel-doc function comment:
  * comment lines.
  *
  * The longer description can have multiple paragraphs.
- **/
+ */
 
 The first line, with the short description, must be on a single line.
 
@@ -85,7 +86,7 @@ Example kernel-doc data structure comment.
  * perhaps with more lines and words.
  *
  * Longer description of this structure.
- **/
+ */
 
 The kernel-doc function comments describe each parameter to the
 function, in order, with the @name lines.
--
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: PxDVR3200 H LinuxTV v4l-dvb patch : Pull GPIO-20 low for DVB-T

2009-06-23 Thread Andy Walls
On Tue, 2009-06-23 at 11:39 +0800, Terry Wu wrote:
 Hi,
 
 I add the following codes in the cx23885_initialize() of cx25840-core.c:
   /* Drive GPIO2 (GPIO 19~23) direction and values for DVB-T */
   cx25840_and_or(client, 0x160, 0x1d, 0x00);
   cx25840_write(client, 0x164, 0x00);
 
 Before that, the tuning status is 0x1e, but 0 service found.
 Now, I can watch DVB-T (Taiwan, 6MHz bandwidth).
 
 And if you are living in Australia, you should update the
 tuner-xc2028.c too:
 
 http://tw1965.myweb.hinet.net/Linux/v4l-dvb/20090611-TDA18271HDC2/tuner-xc2028.c
 
 Best Regards,
 Terry


Hans,

As I think of potential ways to handle this, I thought we may need to
add a v4l2_subdev interface for setting and reading GPIO's.

A CX23418 based board has a Winbond W8360x GPIO IC connected via I2C.
When I get to writing a v4l2_subdevice driver for that, it will need
such an internal interface as well.

Thoughts?

Regards,
Andy

--
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: PxDVR3200 H LinuxTV v4l-dvb patch : Pull GPIO-20 low for DVB-T

2009-06-23 Thread claude

Terry Wu a écrit :

Hi,

I add the following codes in the cx23885_initialize() of cx25840-core.c:
/* Drive GPIO2 (GPIO 19~23) direction and values for DVB-T */
cx25840_and_or(client, 0x160, 0x1d, 0x00);
cx25840_write(client, 0x164, 0x00);

Before that, the tuning status is 0x1e, but 0 service found.
Now, I can watch DVB-T (Taiwan, 6MHz bandwidth).

And if you are living in Australia, you should update the
tuner-xc2028.c too:

http://tw1965.myweb.hinet.net/Linux/v4l-dvb/20090611-TDA18271HDC2/tuner-xc2028.c

Best Regards,
Terry
  
I have updaded the cx23885_initialize() function of the  cx25840-core.c 
file with your codes.


But with the new built kernel i have the same error both with scan and 
kaffeine.


Best regards

Claude



--
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] Support for Compro VideoMate S350

2009-06-23 Thread OM Ugarcina

Thanks for that Igor,

I have just pulled the latest hg and tried to apply patches . Patches 
12094 and 12095 went in with no problem . However patch 12096 failed 
with this output :


[r...@localhost v4l-dvb]# patch -p1  12096.patch
patching file linux/drivers/media/common/ir-keymaps.c
Hunk #1 FAILED at 2800.
1 out of 1 hunk FAILED -- saving rejects to file 
linux/drivers/media/common/ir-keymaps.c.rej

patching file linux/drivers/media/video/saa7134/Kconfig
patching file linux/drivers/media/video/saa7134/saa7134-cards.c
patching file linux/drivers/media/video/saa7134/saa7134-dvb.c
patching file linux/drivers/media/video/saa7134/saa7134-input.c
patching file linux/drivers/media/video/saa7134/saa7134.h
patching file linux/include/media/ir-common.h
Hunk #1 FAILED at 162.
1 out of 1 hunk FAILED -- saving rejects to file 
linux/include/media/ir-common.h.rej

[r...@localhost v4l-dvb]#

I will attach the rej files to the email .

[r...@localhost v4l-dvb]# cat linux/drivers/media/common/ir-keymaps.c.rej
***
*** 2800,2802 
   [0x1b] = KEY_B, /*recall*/
 };
 EXPORT_SYMBOL_GPL(ir_codes_dm1105_nec);
--- 2800,2850 
   [0x1b] = KEY_B, /*recall*/
 };
 EXPORT_SYMBOL_GPL(ir_codes_dm1105_nec);
+
+ IR_KEYTAB_TYPE ir_codes_videomate_s350[IR_KEYTAB_SIZE] = {
+   [0x00] = KEY_TV,
+   [0x01] = KEY_DVD,
+   [0x04] = KEY_RECORD,
+   [0x05] = KEY_VIDEO, /* TV/Video */
+   [0x07] = KEY_STOP,
+   [0x08] = KEY_PLAYPAUSE,
+   [0x0a] = KEY_REWIND,
+   [0x0f] = KEY_FASTFORWARD,
+   [0x10] = KEY_CHANNELUP,
+   [0x12] = KEY_VOLUMEUP,
+   [0x13] = KEY_CHANNELDOWN,
+   [0x14] = KEY_MUTE,
+   [0x15] = KEY_VOLUMEDOWN,
+   [0x16] = KEY_1,
+   [0x17] = KEY_2,
+   [0x18] = KEY_3,
+   [0x19] = KEY_4,
+   [0x1a] = KEY_5,
+   [0x1b] = KEY_6,
+   [0x1c] = KEY_7,
+   [0x1d] = KEY_8,
+   [0x1e] = KEY_9,
+   [0x1f] = KEY_0,
+   [0x21] = KEY_SLEEP,
+   [0x24] = KEY_ZOOM,
+   [0x25] = KEY_LAST,/* Recall */
+   [0x26] = KEY_SUBTITLE, /* CC */
+   [0x27] = KEY_LANGUAGE, /* MTS */
+   [0x29] = KEY_CHANNEL, /* SURF */
+   [0x2b] = KEY_A,
+   [0x2c] = KEY_B,
+   [0x2f] = KEY_SHUFFLE, /* Snapshot */
+   [0x23] = KEY_RADIO,
+   [0x02] = KEY_PREVIOUSSONG,
+   [0x06] = KEY_NEXTSONG,
+   [0x03] = KEY_EPG,
+   [0x09] = KEY_SETUP,
+   [0x22] = KEY_BACKSPACE,
+   [0x0c] = KEY_UP,
+   [0x0e] = KEY_DOWN,
+   [0x0b] = KEY_LEFT,
+   [0x0d] = KEY_RIGHT,
+   [0x11] = KEY_ENTER,
+   [0x20] = KEY_TEXT,
+ };
+ EXPORT_SYMBOL_GPL(ir_codes_videomate_s350);
[r...@localhost v4l-dvb]# cat linux/include/media/ir-common.h.rej
***
*** 162,167 
 extern IR_KEYTAB_TYPE ir_codes_kworld_plus_tv_analog[IR_KEYTAB_SIZE];
 extern IR_KEYTAB_TYPE ir_codes_kaiomy[IR_KEYTAB_SIZE];
 extern IR_KEYTAB_TYPE ir_codes_dm1105_nec[IR_KEYTAB_SIZE];
 #endif

 /*
--- 162,168 
 extern IR_KEYTAB_TYPE ir_codes_kworld_plus_tv_analog[IR_KEYTAB_SIZE];
 extern IR_KEYTAB_TYPE ir_codes_kaiomy[IR_KEYTAB_SIZE];
 extern IR_KEYTAB_TYPE ir_codes_dm1105_nec[IR_KEYTAB_SIZE];
+ extern IR_KEYTAB_TYPE ir_codes_videomate_s350[IR_KEYTAB_SIZE];
 #endif

 /*
[r...@localhost v4l-dvb]#



Best Regards

Milorad

--
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: PxDVR3200 H LinuxTV v4l-dvb patch : Pull GPIO-20 low for DVB-T

2009-06-23 Thread Hans Verkuil

 On Tue, 2009-06-23 at 11:39 +0800, Terry Wu wrote:
 Hi,

 I add the following codes in the cx23885_initialize() of
 cx25840-core.c:
  /* Drive GPIO2 (GPIO 19~23) direction and values for DVB-T */
  cx25840_and_or(client, 0x160, 0x1d, 0x00);
  cx25840_write(client, 0x164, 0x00);

 Before that, the tuning status is 0x1e, but 0 service found.
 Now, I can watch DVB-T (Taiwan, 6MHz bandwidth).

 And if you are living in Australia, you should update the
 tuner-xc2028.c too:
 
 http://tw1965.myweb.hinet.net/Linux/v4l-dvb/20090611-TDA18271HDC2/tuner-xc2028.c

 Best Regards,
 Terry


 Hans,

 As I think of potential ways to handle this, I thought we may need to
 add a v4l2_subdev interface for setting and reading GPIO's.

There is already an s_gpio in the core ops. It would be simple to add a
g_gpio as well if needed.

It is not a good idea to directly control GPIO pins from within a subdev
driver for the simple reason that the subdev driver has no idea how its
gpio pins are hooked up. This should really be done from the v4l driver
itself. If you need a notification from the subdev that the v4l driver
needs to take some action, then the subdev can send a notification through
the notify function in v4l2_device. That's currently used by one subdev
driver that requires that the v4l driver toggles a GPIO pin at the right
time.

Regards,

  Hans

 A CX23418 based board has a Winbond W8360x GPIO IC connected via I2C.
 When I get to writing a v4l2_subdevice driver for that, it will need
 such an internal interface as well.

 Thoughts?

 Regards,
 Andy




-- 
Hans Verkuil - video4linux developer - sponsored by TANDBERG

--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: PxDVR3200 H LinuxTV v4l-dvb patch : Pull GPIO-20 low for DVB-T

2009-06-23 Thread Terry Wu
Hi,

1. The CX23885's  GPIO 23 thru 19 - On the cx25840 a/v core is not
implemented yet.
You can find the following codes in the cx23885-core.c :
/* Mask represents 32 different GPIOs, GPIO's are split into multiple
 * registers depending on the board configuration (and whether the
 * 417 encoder (wi it's own GPIO's) are present. Each GPIO bit will
 * be pushed into the correct hardware register, regardless of the
 * physical location. Certain registers are shared so we sanity check
 * and report errors if we think we're tampering with a GPIo that might
 * be assigned to the encoder (and used for the host bus).
 *
 * GPIO  2 thru  0 - On the cx23885 bridge
 * GPIO 18 thru  3 - On the cx23417 host bus interface
 * GPIO 23 thru 19 - On the cx25840 a/v core
 */
void cx23885_gpio_set(struct cx23885_dev *dev, u32 mask)
{
if (mask  0x7)
cx_set(GP0_IO, mask  0x7);

if (mask  0x0007fff8) {
if (encoder_on_portb(dev) || encoder_on_portc(dev))
printk(KERN_ERR
%s: Setting GPIO on encoder ports\n,
dev-name);
cx_set(MC417_RWD, (mask  0x0007fff8)  3);
}

/* TODO: 23-19 */
if (mask  0x00f8)
printk(KERN_INFO %s: Unsupported\n, dev-name);
}

void cx23885_gpio_clear(struct cx23885_dev *dev, u32 mask)
{
if (mask  0x0007)
cx_clear(GP0_IO, mask  0x7);

if (mask  0x0007fff8) {
if (encoder_on_portb(dev) || encoder_on_portc(dev))
printk(KERN_ERR
%s: Clearing GPIO moving on encoder ports\n,
dev-name);
cx_clear(MC417_RWD, (mask  0x7fff8)  3);
}

/* TODO: 23-19 */
if (mask  0x00f8)
printk(KERN_INFO %s: Unsupported\n, dev-name);
}

void cx23885_gpio_enable(struct cx23885_dev *dev, u32 mask, int asoutput)
{
if ((mask  0x0007)  asoutput)
cx_set(GP0_IO, (mask  0x7)  16);
else if ((mask  0x0007)  !asoutput)
cx_clear(GP0_IO, (mask  0x7)  16);

if (mask  0x0007fff8) {
if (encoder_on_portb(dev) || encoder_on_portc(dev))
printk(KERN_ERR
%s: Enabling GPIO on encoder ports\n,
dev-name);
}

/* MC417_OEN is active low for output, write 1 for an input */
if ((mask  0x0007fff8)  asoutput)
cx_clear(MC417_OEN, (mask  0x7fff8)  3);

else if ((mask  0x0007fff8)  !asoutput)
cx_set(MC417_OEN, (mask  0x7fff8)  3);

/* TODO: 23-19 */
}

2. Also, I can not find GPIO functions in the cx25840-core.c

Something missing or unfinished ?

Best Regards,
Terry

2009/6/23 Hans Verkuil hverk...@xs4all.nl:

 On Tue, 2009-06-23 at 11:39 +0800, Terry Wu wrote:
 Hi,

     I add the following codes in the cx23885_initialize() of
 cx25840-core.c:
      /* Drive GPIO2 (GPIO 19~23) direction and values for DVB-T */
      cx25840_and_or(client, 0x160, 0x1d, 0x00);
      cx25840_write(client, 0x164, 0x00);

     Before that, the tuning status is 0x1e, but 0 service found.
     Now, I can watch DVB-T (Taiwan, 6MHz bandwidth).

     And if you are living in Australia, you should update the
 tuner-xc2028.c too:
     
 http://tw1965.myweb.hinet.net/Linux/v4l-dvb/20090611-TDA18271HDC2/tuner-xc2028.c

 Best Regards,
 Terry


 Hans,

 As I think of potential ways to handle this, I thought we may need to
 add a v4l2_subdev interface for setting and reading GPIO's.

 There is already an s_gpio in the core ops. It would be simple to add a
 g_gpio as well if needed.

 It is not a good idea to directly control GPIO pins from within a subdev
 driver for the simple reason that the subdev driver has no idea how its
 gpio pins are hooked up. This should really be done from the v4l driver
 itself. If you need a notification from the subdev that the v4l driver
 needs to take some action, then the subdev can send a notification through
 the notify function in v4l2_device. That's currently used by one subdev
 driver that requires that the v4l driver toggles a GPIO pin at the right
 time.

 Regards,

          Hans

 A CX23418 based board has a Winbond W8360x GPIO IC connected via I2C.
 When I get to writing a v4l2_subdevice driver for that, it will need
 such an internal interface as well.

 Thoughts?

 Regards,
 Andy




 --
 Hans Verkuil - video4linux developer - sponsored by TANDBERG


--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


RE: OMAP34XXCAM: Micron mt9d111 sensor support?

2009-06-23 Thread Aguirre Rodriguez, Sergio Alberto
 -Original Message-
 From: Gary Thomas [mailto:g...@mlbassoc.com]
 Sent: Monday, June 22, 2009 1:06 PM
 To: Aguirre Rodriguez, Sergio Alberto
 Cc: Zach LeRoy; linux-omap; linux-media@vger.kernel.org; Sakari Ailus
 Subject: Re: OMAP34XXCAM: Micron mt9d111 sensor support?
 
 Aguirre Rodriguez, Sergio Alberto wrote:
 
  -Original Message-
  From: linux-media-ow...@vger.kernel.org [mailto:linux-media-
  ow...@vger.kernel.org] On Behalf Of Zach LeRoy
  Sent: Wednesday, June 17, 2009 5:06 PM
  To: linux-omap; linux-media@vger.kernel.org
  Subject: OMAP34XXCAM: Micron mt9d111 sensor support?
 
  I am working on adding support for a micron 2 MP sensor: mt9d111 on a
  gumsitx overo.  This is a i2c-controlled sensor.  Ideally, I would like
 to
  use the omap34xxcam driver to interface with this sensor.  I am
 wondering
  if there are currently any distributions which already include support
 for
  this sensor through the omap34xxcam driver, or if anyone else is
  interested in this topic.
 
 
  Hi Zach,
 
  I'm working along with Sakari Ailus and others in this omap34xxcam
 driver you're talking about, and we are in the process to provide a newer
 patchset to work on the latest l-o tree.
 
  Sakari is sharing the camera core here:
 
  http://gitorious.org/omap3camera
 
  And I have also this repository which contains a snapshot of Sakari's
 tree + support from some sensors I have available for the 3430SDP and LDP
 (the name could confuse with the above, but I'll change the name/location
 soon):
 
  http://gitorious.org/omap3-linux-camera-driver
 
  Testing the driver with as much sensors as we can is very interesting
 (at least for me), because that help us spot possible bugs that aren't
 seen with our current HW. So, I'll be looking forward if you add this
 sensor driver to the supported list :)
 
 
 I'd like to move forward using this on OMAP/3530 with TVP5150 (S-video in)
 
 Sadly, the tree above (omap3-linux-camera-driver) won't build for the
 Zoom/LDP:
   CC  arch/arm/mach-omap2/board-ldp-camera.o
 /local/omap3-linux-camera-driver/arch/arm/mach-omap2/board-ldp-
 camera.c:59:
 error: implicit declaration of function 'PAGE_ALIGN'
 /local/omap3-linux-camera-driver/arch/arm/mach-omap2/board-ldp-
 camera.c:59:
 error: initializer element is not constant
 /local/omap3-linux-camera-driver/arch/arm/mach-omap2/board-ldp-
 camera.c:59:
 error: (near initialization for 'ov3640_hwc.capture_mem')
 /local/omap3-linux-camera-driver/arch/arm/mach-omap2/board-ldp-camera.c:
 In function 'ov3640_sensor_set_prv_data':
 /local/omap3-linux-camera-driver/arch/arm/mach-omap2/board-ldp-
 camera.c:89:
 error: 'hwc' undeclared (first use in this function)
 /local/omap3-linux-camera-driver/arch/arm/mach-omap2/board-ldp-
 camera.c:89:
 error: (Each undeclared identifier is reported only once
 /local/omap3-linux-camera-driver/arch/arm/mach-omap2/board-ldp-
 camera.c:89:
 error: for each function it appears in.)
 
 Looking at the code, it seems that some pieces are missing - merge
 problem maybe?

Hi Gary,

I'm currently on the process to rebase and verify all this code on 3430SDP, 
Zoom1 and soon Zoom2.

Here you can find my progress:

  http://dev.omapzoom.org/?p=saaguirre/linux-omap-camera.git;a=summary

Check devel branch, which contains all latest Sakari's tree patches 
(http://gitorious.org/omap3camera) rebased on top of latest Kevin's l-o PM 
tree, plus the patches, which are still in works, to make the above mentioned 
platforms to work.

I'm first trying to make 3430SDP work, don't have a Zoom1/Zoom2 handy right 
now...

My gitorious tree will eventually disappear, as I can work better with this new 
one.

I'll consolidate some patches when this sensor code is ready, and will CC you 
if interested.

Regards,
Sergio

 
 --
 
 Gary Thomas |  Consulting for the
 MLB Associates  |Embedded world
 
 

--
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: OMAP34XXCAM: Micron mt9d111 sensor support?

2009-06-23 Thread Gary Thomas
Aguirre Rodriguez, Sergio Alberto wrote:
 -Original Message-
 From: Gary Thomas [mailto:g...@mlbassoc.com]
 Sent: Monday, June 22, 2009 1:06 PM
 To: Aguirre Rodriguez, Sergio Alberto
 Cc: Zach LeRoy; linux-omap; linux-media@vger.kernel.org; Sakari Ailus
 Subject: Re: OMAP34XXCAM: Micron mt9d111 sensor support?

 Aguirre Rodriguez, Sergio Alberto wrote:
 -Original Message-
 From: linux-media-ow...@vger.kernel.org [mailto:linux-media-
 ow...@vger.kernel.org] On Behalf Of Zach LeRoy
 Sent: Wednesday, June 17, 2009 5:06 PM
 To: linux-omap; linux-media@vger.kernel.org
 Subject: OMAP34XXCAM: Micron mt9d111 sensor support?

 I am working on adding support for a micron 2 MP sensor: mt9d111 on a
 gumsitx overo.  This is a i2c-controlled sensor.  Ideally, I would like
 to
 use the omap34xxcam driver to interface with this sensor.  I am
 wondering
 if there are currently any distributions which already include support
 for
 this sensor through the omap34xxcam driver, or if anyone else is
 interested in this topic.

 Hi Zach,

 I'm working along with Sakari Ailus and others in this omap34xxcam
 driver you're talking about, and we are in the process to provide a newer
 patchset to work on the latest l-o tree.
 Sakari is sharing the camera core here:

 http://gitorious.org/omap3camera

 And I have also this repository which contains a snapshot of Sakari's
 tree + support from some sensors I have available for the 3430SDP and LDP
 (the name could confuse with the above, but I'll change the name/location
 soon):
 http://gitorious.org/omap3-linux-camera-driver

 Testing the driver with as much sensors as we can is very interesting
 (at least for me), because that help us spot possible bugs that aren't
 seen with our current HW. So, I'll be looking forward if you add this
 sensor driver to the supported list :)
 I'd like to move forward using this on OMAP/3530 with TVP5150 (S-video in)

 Sadly, the tree above (omap3-linux-camera-driver) won't build for the
 Zoom/LDP:
   CC  arch/arm/mach-omap2/board-ldp-camera.o
 /local/omap3-linux-camera-driver/arch/arm/mach-omap2/board-ldp-
 camera.c:59:
 error: implicit declaration of function 'PAGE_ALIGN'
 /local/omap3-linux-camera-driver/arch/arm/mach-omap2/board-ldp-
 camera.c:59:
 error: initializer element is not constant
 /local/omap3-linux-camera-driver/arch/arm/mach-omap2/board-ldp-
 camera.c:59:
 error: (near initialization for 'ov3640_hwc.capture_mem')
 /local/omap3-linux-camera-driver/arch/arm/mach-omap2/board-ldp-camera.c:
 In function 'ov3640_sensor_set_prv_data':
 /local/omap3-linux-camera-driver/arch/arm/mach-omap2/board-ldp-
 camera.c:89:
 error: 'hwc' undeclared (first use in this function)
 /local/omap3-linux-camera-driver/arch/arm/mach-omap2/board-ldp-
 camera.c:89:
 error: (Each undeclared identifier is reported only once
 /local/omap3-linux-camera-driver/arch/arm/mach-omap2/board-ldp-
 camera.c:89:
 error: for each function it appears in.)

 Looking at the code, it seems that some pieces are missing - merge
 problem maybe?
 
 Hi Gary,
 
 I'm currently on the process to rebase and verify all this code on 3430SDP, 
 Zoom1 and soon Zoom2.
 
 Here you can find my progress:
 
   http://dev.omapzoom.org/?p=saaguirre/linux-omap-camera.git;a=summary
 
 Check devel branch, which contains all latest Sakari's tree patches 
 (http://gitorious.org/omap3camera) rebased on top of latest Kevin's l-o PM 
 tree, plus the patches, which are still in works, to make the above mentioned 
 platforms to work.
 
 I'm first trying to make 3430SDP work, don't have a Zoom1/Zoom2 handy right 
 now...
 
 My gitorious tree will eventually disappear, as I can work better with this 
 new one.
 
 I'll consolidate some patches when this sensor code is ready, and will CC you 
 if interested.


Thanks.  I've already checked out this tree and at least
it builds for the Zoom (I have one here).  Is this in a
state where I can test it for you?  What do you use to
capture video from the sensor?


-- 

Gary Thomas |  Consulting for the
MLB Associates  |Embedded world

--
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: OMAP34XXCAM: Micron mt9d111 sensor support?

2009-06-23 Thread Gary Thomas
Aguirre Rodriguez, Sergio Alberto wrote:
 From: linux-media-ow...@vger.kernel.org [mailto:linux-media-
 ow...@vger.kernel.org] On Behalf Of Aguirre Rodriguez, Sergio Alberto
 From: Gary Thomas [mailto:g...@mlbassoc.com]
 Aguirre Rodriguez, Sergio Alberto wrote:
 From: Gary Thomas [mailto:g...@mlbassoc.com]
 Aguirre Rodriguez, Sergio Alberto wrote:
 From: linux-media-ow...@vger.kernel.org [mailto:linux-media-
 ow...@vger.kernel.org] On Behalf Of Zach LeRoy
 I am working on adding support for a micron 2 MP sensor: mt9d111 on
 a
 gumsitx overo.  This is a i2c-controlled sensor.  Ideally, I would
 like
 to
 use the omap34xxcam driver to interface with this sensor.  I am
 wondering
 if there are currently any distributions which already include
 support
 for
 this sensor through the omap34xxcam driver, or if anyone else is
 interested in this topic.

 Hi Zach,

 I'm working along with Sakari Ailus and others in this omap34xxcam
 driver you're talking about, and we are in the process to provide a
 newer
 patchset to work on the latest l-o tree.
 Sakari is sharing the camera core here:

 http://gitorious.org/omap3camera

 And I have also this repository which contains a snapshot of
 Sakari's
 tree + support from some sensors I have available for the 3430SDP and
 LDP
 (the name could confuse with the above, but I'll change the
 name/location
 soon):
 http://gitorious.org/omap3-linux-camera-driver

 Testing the driver with as much sensors as we can is very
 interesting
 (at least for me), because that help us spot possible bugs that
 aren't
 seen with our current HW. So, I'll be looking forward if you add this
 sensor driver to the supported list :)
 I'd like to move forward using this on OMAP/3530 with TVP5150 (S-
 video
 in)
 Sadly, the tree above (omap3-linux-camera-driver) won't build for the
 Zoom/LDP:
   CC  arch/arm/mach-omap2/board-ldp-camera.o
 /local/omap3-linux-camera-driver/arch/arm/mach-omap2/board-ldp-
 camera.c:59:
 error: implicit declaration of function 'PAGE_ALIGN'
 /local/omap3-linux-camera-driver/arch/arm/mach-omap2/board-ldp-
 camera.c:59:
 error: initializer element is not constant
 /local/omap3-linux-camera-driver/arch/arm/mach-omap2/board-ldp-
 camera.c:59:
 error: (near initialization for 'ov3640_hwc.capture_mem')
 /local/omap3-linux-camera-driver/arch/arm/mach-omap2/board-ldp-
 camera.c:
 In function 'ov3640_sensor_set_prv_data':
 /local/omap3-linux-camera-driver/arch/arm/mach-omap2/board-ldp-
 camera.c:89:
 error: 'hwc' undeclared (first use in this function)
 /local/omap3-linux-camera-driver/arch/arm/mach-omap2/board-ldp-
 camera.c:89:
 error: (Each undeclared identifier is reported only once
 /local/omap3-linux-camera-driver/arch/arm/mach-omap2/board-ldp-
 camera.c:89:
 error: for each function it appears in.)

 Looking at the code, it seems that some pieces are missing - merge
 problem maybe?
 Hi Gary,

 I'm currently on the process to rebase and verify all this code on
 3430SDP, Zoom1 and soon Zoom2.
 Here you can find my progress:

   http://dev.omapzoom.org/?p=saaguirre/linux-omap-camera.git;a=summary

 Check devel branch, which contains all latest Sakari's tree patches
 (http://gitorious.org/omap3camera) rebased on top of latest Kevin's l-o
 PM
 tree, plus the patches, which are still in works, to make the above
 mentioned platforms to work.
 I'm first trying to make 3430SDP work, don't have a Zoom1/Zoom2 handy
 right now...
 My gitorious tree will eventually disappear, as I can work better with
 this new one.
 I'll consolidate some patches when this sensor code is ready, and will
 CC you if interested.
 Thanks.  I've already checked out this tree and at least
 it builds for the Zoom (I have one here).  Is this in a
 state where I can test it for you?  What do you use to
 capture video from the sensor?
 I normally use a small test binary I wrote which saves the captured frames
 to memory, so later I can see them with either IrfanView (when capturing
 RAW images) or PYUV for seeing the YUV422 images.

 You should be able to use any standard V4l2 capturing application anyways.

 
 Btw, any contribution would be completely welcome. Either on Testing or on 
 development. :)
 
 Thanks for your interest in helping.

I've built for the Zoom, now I just need to figure out how
to capture the data.  I'll let you know if I have any questions
or problems.

Thanks

-- 

Gary Thomas |  Consulting for the
MLB Associates  |Embedded world

--
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: OMAP34XXCAM: Micron mt9d111 sensor support?

2009-06-23 Thread Aguirre Rodriguez, Sergio Alberto


 -Original Message-
 From: Gary Thomas [mailto:g...@mlbassoc.com]
 Sent: Tuesday, June 23, 2009 8:23 AM
 To: Aguirre Rodriguez, Sergio Alberto
 Cc: Zach LeRoy; linux-omap; linux-media@vger.kernel.org; Sakari Ailus
 Subject: Re: OMAP34XXCAM: Micron mt9d111 sensor support?
 
 Aguirre Rodriguez, Sergio Alberto wrote:
  -Original Message-
  From: Gary Thomas [mailto:g...@mlbassoc.com]
  Sent: Monday, June 22, 2009 1:06 PM
  To: Aguirre Rodriguez, Sergio Alberto
  Cc: Zach LeRoy; linux-omap; linux-media@vger.kernel.org; Sakari Ailus
  Subject: Re: OMAP34XXCAM: Micron mt9d111 sensor support?
 
  Aguirre Rodriguez, Sergio Alberto wrote:
  -Original Message-
  From: linux-media-ow...@vger.kernel.org [mailto:linux-media-
  ow...@vger.kernel.org] On Behalf Of Zach LeRoy
  Sent: Wednesday, June 17, 2009 5:06 PM
  To: linux-omap; linux-media@vger.kernel.org
  Subject: OMAP34XXCAM: Micron mt9d111 sensor support?
 
  I am working on adding support for a micron 2 MP sensor: mt9d111 on a
  gumsitx overo.  This is a i2c-controlled sensor.  Ideally, I would
 like
  to
  use the omap34xxcam driver to interface with this sensor.  I am
  wondering
  if there are currently any distributions which already include
 support
  for
  this sensor through the omap34xxcam driver, or if anyone else is
  interested in this topic.
 
  Hi Zach,
 
  I'm working along with Sakari Ailus and others in this omap34xxcam
  driver you're talking about, and we are in the process to provide a
 newer
  patchset to work on the latest l-o tree.
  Sakari is sharing the camera core here:
 
  http://gitorious.org/omap3camera
 
  And I have also this repository which contains a snapshot of Sakari's
  tree + support from some sensors I have available for the 3430SDP and
 LDP
  (the name could confuse with the above, but I'll change the
 name/location
  soon):
  http://gitorious.org/omap3-linux-camera-driver
 
  Testing the driver with as much sensors as we can is very interesting
  (at least for me), because that help us spot possible bugs that aren't
  seen with our current HW. So, I'll be looking forward if you add this
  sensor driver to the supported list :)
  I'd like to move forward using this on OMAP/3530 with TVP5150 (S-video
 in)
 
  Sadly, the tree above (omap3-linux-camera-driver) won't build for the
  Zoom/LDP:
CC  arch/arm/mach-omap2/board-ldp-camera.o
  /local/omap3-linux-camera-driver/arch/arm/mach-omap2/board-ldp-
  camera.c:59:
  error: implicit declaration of function 'PAGE_ALIGN'
  /local/omap3-linux-camera-driver/arch/arm/mach-omap2/board-ldp-
  camera.c:59:
  error: initializer element is not constant
  /local/omap3-linux-camera-driver/arch/arm/mach-omap2/board-ldp-
  camera.c:59:
  error: (near initialization for 'ov3640_hwc.capture_mem')
  /local/omap3-linux-camera-driver/arch/arm/mach-omap2/board-ldp-
 camera.c:
  In function 'ov3640_sensor_set_prv_data':
  /local/omap3-linux-camera-driver/arch/arm/mach-omap2/board-ldp-
  camera.c:89:
  error: 'hwc' undeclared (first use in this function)
  /local/omap3-linux-camera-driver/arch/arm/mach-omap2/board-ldp-
  camera.c:89:
  error: (Each undeclared identifier is reported only once
  /local/omap3-linux-camera-driver/arch/arm/mach-omap2/board-ldp-
  camera.c:89:
  error: for each function it appears in.)
 
  Looking at the code, it seems that some pieces are missing - merge
  problem maybe?
 
  Hi Gary,
 
  I'm currently on the process to rebase and verify all this code on
 3430SDP, Zoom1 and soon Zoom2.
 
  Here you can find my progress:
 
http://dev.omapzoom.org/?p=saaguirre/linux-omap-camera.git;a=summary
 
  Check devel branch, which contains all latest Sakari's tree patches
 (http://gitorious.org/omap3camera) rebased on top of latest Kevin's l-o PM
 tree, plus the patches, which are still in works, to make the above
 mentioned platforms to work.
 
  I'm first trying to make 3430SDP work, don't have a Zoom1/Zoom2 handy
 right now...
 
  My gitorious tree will eventually disappear, as I can work better with
 this new one.
 
  I'll consolidate some patches when this sensor code is ready, and will
 CC you if interested.
 
 
 Thanks.  I've already checked out this tree and at least
 it builds for the Zoom (I have one here).  Is this in a
 state where I can test it for you?  What do you use to
 capture video from the sensor?

I normally use a small test binary I wrote which saves the captured frames to 
memory, so later I can see them with either IrfanView (when capturing RAW 
images) or PYUV for seeing the YUV422 images.

You should be able to use any standard V4l2 capturing application anyways.

Regards,
Sergio

 
 
 --
 
 Gary Thomas |  Consulting for the
 MLB Associates  |Embedded world
 

--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to 

RE: OMAP34XXCAM: Micron mt9d111 sensor support?

2009-06-23 Thread Aguirre Rodriguez, Sergio Alberto
From: linux-media-ow...@vger.kernel.org [mailto:linux-media-
ow...@vger.kernel.org] On Behalf Of Aguirre Rodriguez, Sergio Alberto
 From: Gary Thomas [mailto:g...@mlbassoc.com]
  Aguirre Rodriguez, Sergio Alberto wrote:
   From: Gary Thomas [mailto:g...@mlbassoc.com]
   Aguirre Rodriguez, Sergio Alberto wrote:
   From: linux-media-ow...@vger.kernel.org [mailto:linux-media-
   ow...@vger.kernel.org] On Behalf Of Zach LeRoy
   I am working on adding support for a micron 2 MP sensor: mt9d111 on
 a
   gumsitx overo.  This is a i2c-controlled sensor.  Ideally, I would
  like
   to
   use the omap34xxcam driver to interface with this sensor.  I am
   wondering
   if there are currently any distributions which already include
  support
   for
   this sensor through the omap34xxcam driver, or if anyone else is
   interested in this topic.
  
   Hi Zach,
  
   I'm working along with Sakari Ailus and others in this omap34xxcam
   driver you're talking about, and we are in the process to provide a
  newer
   patchset to work on the latest l-o tree.
   Sakari is sharing the camera core here:
  
   http://gitorious.org/omap3camera
  
   And I have also this repository which contains a snapshot of
 Sakari's
   tree + support from some sensors I have available for the 3430SDP and
  LDP
   (the name could confuse with the above, but I'll change the
  name/location
   soon):
   http://gitorious.org/omap3-linux-camera-driver
  
   Testing the driver with as much sensors as we can is very
 interesting
   (at least for me), because that help us spot possible bugs that
 aren't
   seen with our current HW. So, I'll be looking forward if you add this
   sensor driver to the supported list :)
   I'd like to move forward using this on OMAP/3530 with TVP5150 (S-
 video
  in)
  
   Sadly, the tree above (omap3-linux-camera-driver) won't build for the
   Zoom/LDP:
 CC  arch/arm/mach-omap2/board-ldp-camera.o
   /local/omap3-linux-camera-driver/arch/arm/mach-omap2/board-ldp-
   camera.c:59:
   error: implicit declaration of function 'PAGE_ALIGN'
   /local/omap3-linux-camera-driver/arch/arm/mach-omap2/board-ldp-
   camera.c:59:
   error: initializer element is not constant
   /local/omap3-linux-camera-driver/arch/arm/mach-omap2/board-ldp-
   camera.c:59:
   error: (near initialization for 'ov3640_hwc.capture_mem')
   /local/omap3-linux-camera-driver/arch/arm/mach-omap2/board-ldp-
  camera.c:
   In function 'ov3640_sensor_set_prv_data':
   /local/omap3-linux-camera-driver/arch/arm/mach-omap2/board-ldp-
   camera.c:89:
   error: 'hwc' undeclared (first use in this function)
   /local/omap3-linux-camera-driver/arch/arm/mach-omap2/board-ldp-
   camera.c:89:
   error: (Each undeclared identifier is reported only once
   /local/omap3-linux-camera-driver/arch/arm/mach-omap2/board-ldp-
   camera.c:89:
   error: for each function it appears in.)
  
   Looking at the code, it seems that some pieces are missing - merge
   problem maybe?
  
   Hi Gary,
  
   I'm currently on the process to rebase and verify all this code on
  3430SDP, Zoom1 and soon Zoom2.
  
   Here you can find my progress:
  
 http://dev.omapzoom.org/?p=saaguirre/linux-omap-camera.git;a=summary
  
   Check devel branch, which contains all latest Sakari's tree patches
  (http://gitorious.org/omap3camera) rebased on top of latest Kevin's l-o
 PM
  tree, plus the patches, which are still in works, to make the above
  mentioned platforms to work.
  
   I'm first trying to make 3430SDP work, don't have a Zoom1/Zoom2 handy
  right now...
  
   My gitorious tree will eventually disappear, as I can work better with
  this new one.
  
   I'll consolidate some patches when this sensor code is ready, and will
  CC you if interested.
  
 
  Thanks.  I've already checked out this tree and at least
  it builds for the Zoom (I have one here).  Is this in a
  state where I can test it for you?  What do you use to
  capture video from the sensor?
 
 I normally use a small test binary I wrote which saves the captured frames
 to memory, so later I can see them with either IrfanView (when capturing
 RAW images) or PYUV for seeing the YUV422 images.
 
 You should be able to use any standard V4l2 capturing application anyways.
 

Btw, any contribution would be completely welcome. Either on Testing or on 
development. :)

Thanks for your interest in helping.

 Regards,
 Sergio
 
 
 
  --
  
  Gary Thomas |  Consulting for the
  MLB Associates  |Embedded world
  
 
 --
 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  

RE: mx31moboard MT9T031 camera support

2009-06-23 Thread Karicheri, Muralidharan
Hi,

I am already working on porting MT9T031 driver to sub device framework. I have 
communicated this to Guennadi, earlier. So please don't work on it. I am going 
to send a patch for review in a week.

Thanks.
Murali Karicheri
Software Design Engineer
Texas Instruments Inc.
Germantown, MD 20874
email: m-kariche...@ti.com

-Original Message-
From: linux-media-ow...@vger.kernel.org [mailto:linux-media-
ow...@vger.kernel.org] On Behalf Of Guennadi Liakhovetski
Sent: Thursday, June 18, 2009 5:20 AM
To: Valentin Longchamp
Cc: Linux Media Mailing List; Sascha Hauer
Subject: Re: mx31moboard MT9T031 camera support

On Thu, 18 Jun 2009, Valentin Longchamp wrote:

 Hi Guennadi,

 I am trying to follow your developments at porting soc-camera to v4l2-
subdev.
 However, even if I understand quite correctly soc-camera, it is quite
 difficult for me to get all the subtleties in your work.

 That's why I am asking you for a little help: when do you think would be
the
 best timing for me to add the mt9t031 camera support for mx31moboard
within
 your current process ?

You can do this now, based either on the v4l tree, or wait for Linus to
pull it - a pull request has been sent ba Mauro yesterday, looks like
Linus hasn't pulled yet.

The way you add your platform is going to change, and the pull, that I'm
referring to above makes it possible for both old style and new style
board camera data to work. Of course, it would be best for you to
implement the new style platform data. You can do this by either looking
at my patches, which I've posted to the lists earlier, and which are also
included in my patch stack, which I announced yesterday. Or you can wait a
bit until I update my pcm037 patch (going to do this now) and post it to
arm-kernel. I'll (try not to forget to) add you to cc, that should be
quite easy to follow for you.

 I guess it should not be too difficult, I had done it before, and I can
base
 myself on what you have done for pcm037:
 http://download.open-technology.de/soc-camera/20090617/0025-pcm037-add-
MT9T031-camera-support.patch

Yes, use this or wait a bit for an updated version.

 Now I have a second question. On our robot, we physically have two
cameras
 (one looking to the front and one looking at a mirror) connected to the
i.MX31
 physical bus. We have one signal that allows us to control the
multiplexer for
 the bus lines (video signals and I2C) through a GPIO. This now works with
a
 single camera declared in software and choices to the multiplexer done
when no
 image transfer is happening ( /dev/video is not open). What do you think
 should be the correct way of dealing with these two cameras with the
current
 driver implementation (should I continue to declare only one camera in
the
 software) ?

 And do you think it could be possible to hot-switch from one camera to
the
 other ? My colleagues ask about it, I tell them that from my point of
view
 this seems not possible without changing the drivers, and even the
drivers
 would have to be changed quite heavily and it is not trivial.

Do the cameras use different i2c addresses? If they use the same address I
don't think you'd be able to register them simultaneously. If they do use
different addresses, you can register both of them and use platform
.power() callback to switch between them using your multiplexer. See
arch/sh/boards/mach-migor/setup.c for an example. There was also a
proposal to use switching input to select a data source, but this is
currently unsupported by soc-camera.

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

--
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-vpfe-cap

2009-06-23 Thread Karicheri, Muralidharan
Mauro,

Thanks.

I have sent a patch yesterday for TVP514x that fixes the comment formatting. 
Please review that when you get a chance.

Murali Karicheri
Software Design Engineer
Texas Instruments Inc.
Germantown, MD 20874
Phone : 301-515-3736
email: m-kariche...@ti.com

-Original Message-
From: Mauro Carvalho Chehab [mailto:mche...@redhat.com]
Sent: Tuesday, June 23, 2009 6:50 AM
To: Karicheri, Muralidharan
Cc: Hans Verkuil; linux-media@vger.kernel.org
Subject: Re: [PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-vpfe-cap

Em Mon, 22 Jun 2009 11:02:58 -0500
Karicheri, Muralidharan m-kariche...@ti.com escreveu:

 Hi,

 Snip
  
   -/**
   +/*
 * struct tvp514x_decoder - TVP5146/47 decoder object
   - * @v4l2_int_device: Slave handle
   - * @tvp514x_slave: Slave pointer which is used by @v4l2_int_device
   + * @sd: Subdevice Slave handle
 * @tvp514x_regs: copy of hw's regs with preset values.
 * @pdata: Board specific
   - * @client: I2C client data
   - * @id: Entry from I2C table
 * @ver: Chip version
   - * @state: TVP5146/47 decoder state - detected or not-detected
   + * @streaming: TVP5146/47 decoder streaming - enabled or disabled.
 * @pix: Current pixel format
 * @num_fmts: Number of formats
 * @fmt_list: Format list
 * @current_std: Current standard
 * @num_stds: Number of standards
 * @std_list: Standards list
   - * @route: input and output routing at chip level
   + * @input: Input routing at chip level
   + * @output: Output routing at chip level
 */
  
   Please read Documentation/kernel-doc-nano-HOWTO.txt for the proper
   format. Basically, it should be like this example:
  
   /**
* foobar() - short function description of foobar
* @arg1:   Describe the first argument to foobar.
* @arg2:   Describe the second argument to foobar.
*  One can provide multiple line descriptions
*  for arguments.
*
* A longer description, with more discussion of the function
foobar()
* that might be useful to those using or modifying it.  Begins with
* empty comment line, and may include additional embedded empty
* comment lines.
*
* The longer description can have multiple paragraphs.
**/
  
 But kernel-doc-nano-HOWTO.txt says it should be of the form
 /**
  * foobar() - short function description of foobar
  * @arg1:   Describe the first argument to foobar.
  * @arg2:   Describe the second argument to foobar.
  *  One can provide multiple line descriptions
  *  for arguments.
  *
  * A longer description, with more discussion of the function foobar()
  * that might be useful to those using or modifying it.  Begins with
  * empty comment line, and may include additional embedded empty
  * comment lines.
  *
  * The longer description can have multiple paragraphs.
  */

 Only one * followed by slash as */, not **/ as you have mentioned.
 Please confirm so that I can send you a patch to correct this.

You're right. It seems that I was using an older version of the doc, since
it
used to be like above, on the past versions of the doc:

commit f40b45a2e45b0f02aeedfcfbb28d8e2d4b8b86b1
Author: Randy Dunlap randy.dun...@oracle.com
Date:   Wed Feb 11 13:04:31 2009 -0800

kernel-doc: preferred ending marker and examples

Fix kernel-doc-nano-HOWTO.txt to use */ as the ending marker in kernel-
doc
examples and state that */ is the preferred ending marker.

Signed-off-by: Randy Dunlap randy.dun...@oracle.com
Reported-by: Robert Love robert.w.l...@intel.com
Signed-off-by: Andrew Morton a...@linux-foundation.org
Signed-off-by: Linus Torvalds torva...@linux-foundation.org

diff --git a/Documentation/kernel-doc-nano-HOWTO.txt
b/Documentation/kernel-doc-nano-HOWTO.txt
index d73fbd2..026ec7d 100644
--- a/Documentation/kernel-doc-nano-HOWTO.txt
+++ b/Documentation/kernel-doc-nano-HOWTO.txt
@@ -43,7 +43,8 @@ Only comments so marked will be considered by the kernel-
doc scripts,
 and any comment so marked must be in kernel-doc format.  Do not use
 /** to be begin a comment block unless the comment block contains
 kernel-doc formatted comments.  The closing comment marker for
-kernel-doc comments can be either */ or **/.
+kernel-doc comments can be either */ or **/, but */ is
+preferred in the Linux kernel tree.

 Kernel-doc comments should be placed just before the function
 or data structure being described.
@@ -63,7 +64,7 @@ Example kernel-doc function comment:
  * comment lines.
  *
  * The longer description can have multiple paragraphs.
- **/
+ */

 The first line, with the short description, must be on a single line.

@@ -85,7 +86,7 @@ Example kernel-doc data structure comment.
  *perhaps with more lines and words.
  *
  * Longer description of this structure.
- **/
+ */

 The kernel-doc function comments describe each parameter to the
 function, in order, with the @name lines.

--
To unsubscribe from this list: send 

Re: CAM initialisation failing

2009-06-23 Thread Tomer Barletz
On Tue, Jun 23, 2009 at 12:11 PM, Thomas Kernentker...@deckpoint.ch wrote:
 Tomer Barletz wrote:

 On Mon, Jun 1, 2009 at 4:06 PM, Thomas Kernen tker...@deckpoint.ch
 wrote:

 Dear community,

 After finally getting my Mystique SaTiX DVB-S2 PCI card (clone of KNC1
 DVB
 Station S2), I'm now facing trouble with the CAM initialisation (KNC1 CA
 daughter card, PowerCam Pro CAM and Viaccess card)

 All of the hardware (DVB-S2 PCI card, sat card, CI, CAM) has been tested
 under Windows with any issues, hence I suspect this is a module related
 issue.

 To try and better understand the issue, I added some debug statements to
 the
 following modules:
 options dvb-core cam_debug=1 debug=1
 options budget-core debug=1

 And this is the output I'm getting:

 [    9.146782] DVB: registering new adapter (KNC1 DVB-S2)
 [    9.203364] adapter failed MAC signature check
 [    9.203366] encoded MAC from EEPROM was
 ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff
 [    9.410061] budget_av: saa7113_init(): saa7113 not found on KNC card
 [    9.510352] KNC1-1: MAC addr = 00:09:d6:65:2d:91
 [    9.642505] saa7146 (0) saa7146_i2c_writeout [irq]: timed out waiting
 for
 end of xfer
 [    9.764427] stb0899_attach: Attaching STB0899
 [    9.776853] tda8261_attach: Attaching TDA8261 8PSK/QPSK tuner
 [    9.776855] DVB: registering adapter 1 frontend 0 (STB0899
 Multistandard)...
 [    9.776888] dvb_ca_en50221_init
 [    9.777048] budget-av: ci interface initialised.
 [    9.777050] dvb_ca_en50221_thread
 snip
 [   14.770017] budget-av: cam inserted A
 [   14.770032] budget_av: ciintf_slot_reset(): ciintf_slot_reset
 [   14.950033] TUPLE type:0x1d length:4
 [   14.950041]   0x00: 0x00 .
 [   14.950048]   0x01: 0x61 a
 [   14.950055]   0x02: 0x00 .
 [   14.950063]   0x03: 0xff .
 [   14.950076] TUPLE type:0x1c length:4
 [   14.950083]   0x00: 0x00 .
 [   14.950091]   0x01: 0xd3 .
 [   14.950098]   0x02: 0x00 .
 [   14.950105]   0x03: 0xff .
 [   14.950118] TUPLE type:0x15 length:11
 [   14.950126]   0x00: 0x05 .
 [   14.950133]   0x01: 0x00 .
 [   14.950140]   0x02: 0x47 G
 [   14.950147]   0x03: 0x00 .
 [   14.950154]   0x04: 0x4d M
 [   14.950161]   0x05: 0x00 .
 [   14.950168]   0x06: 0x4c L
 [   14.950175]   0x07: 0x00 .
 [   14.950182]   0x08: 0x4c L
 [   14.950189]   0x09: 0x00 .
 [   14.950196]   0x0a: 0xff .
 [   14.950210] TUPLE type:0x20 length:4
 [   14.950217]   0x00: 0x02 .
 [   14.950224]   0x01: 0xca .
 [   14.950232]   0x02: 0x12 .
 [   14.950239]   0x03: 0x60 `
 [   14.950252] TUPLE type:0x1a length:21
 [   14.950260]   0x00: 0x01 .
 [   14.950267]   0x01: 0x0f .
 [   14.950274]   0x02: 0x00 .
 [   14.950281]   0x03: 0x02 .
 [   14.950288]   0x04: 0x03 .
 [   14.950295]   0x05: 0xc0 .
 [   14.950302]   0x06: 0x0e .
 [   14.950309]   0x07: 0x41 A
 [   14.950316]   0x08: 0x02 .
 [   14.950323]   0x09: 0x44 D
 [   14.950330]   0x0a: 0x56 V
 [   14.950337]   0x0b: 0x42 B
 [   14.950344]   0x0c: 0x5f _
 [   14.950352]   0x0d: 0x43 C
 [   14.950359]   0x0e: 0x49 I
 [   14.950366]   0x0f: 0x5f _
 [   14.950373]   0x10: 0x56 V
 [   14.950380]   0x11: 0x31 1
 [   14.950387]   0x12: 0x2e .
 [   14.950394]   0x13: 0x30 0
 [   14.950401]   0x14: 0x30 0
 [   14.950415] TUPLE type:0x1b length:42
 [   14.950422]   0x00: 0xcf .
 [   14.950429]   0x01: 0x04 .
 [   14.950436]   0x02: 0x09 .
 [   14.950443]   0x03: 0x7f .
 [   14.950450]   0x04: 0x55 U
 [   14.950458]   0x05: 0xcd .
 [   14.950465]   0x06: 0x19 .
 [   14.950472]   0x07: 0xd5 .
 [   14.950479]   0x08: 0x19 .
 [   14.950486]   0x09: 0x3d =
 [   14.950493]   0x0a: 0x9e .
 [   14.950500]   0x0b: 0x25 %
 [   14.950507]   0x0c: 0x26 
 [   14.950514]   0x0d: 0x54 T
 [   14.950521]   0x0e: 0x22 
 [   14.950528]   0x0f: 0xc0 .
 [   14.950535]   0x10: 0x09 .
 [   14.950542]   0x11: 0x44 D
 [   14.950549]   0x12: 0x56 V
 [   14.950557]   0x13: 0x42 B
 [   14.950564]   0x14: 0x5f _
 [   14.950571]   0x15: 0x48 H
 [   14.950578]   0x16: 0x4f O
 [   14.950585]   0x17: 0x53 S
 [   14.950592]   0x18: 0x54 T
 [   14.950599]   0x19: 0x00 .
 [   14.950606]   0x1a: 0xc1 .
 [   14.950613]   0x1b: 0x0e .
 [   14.950620]   0x1c: 0x44 D
 [   14.950627]   0x1d: 0x56 V
 [   14.950634]   0x1e: 0x42 B
 [   14.950642]   0x1f: 0x5f _
 [   14.950649]   0x20: 0x43 C
 [   14.950656]   0x21: 0x49 I
 [   14.950663]   0x22: 0x5f _
 [   14.950670]   0x23: 0x4d M
 [   14.950677]   0x24: 0x4f O
 [   14.950684]   0x25: 0x44 D
 [   14.950691]   0x26: 0x55 U
 [   14.950698]   0x27: 0x4c L
 [   14.950705]   0x28: 0x45 E
 [   14.950712]   0x29: 0x00 .
 [   14.950727] TUPLE type:0x14 length:0
 [   14.950734] END OF CHAIN TUPLE type:0xff
 [   14.950735] Valid DVB CAM detected MANID:ca02 DEVID:6012
 CONFIGBASE:0x200
 CONFIGOPTION:0xf
 [   14.950736] dvb_ca_en50221_set_configoption
 [   14.950750] Set configoption 0xf, read configoption 0xf
 [   14.950757] DVB CAM validated successfully
 snip
 [   15.050023] dvb_ca_en50221_link_init
 [   15.050030] dvb_ca_en50221_wait_if_status
 [   15.050037] 

Re: [linux-dvb] Gigabyte GT-P8000 dvb-t / analog / fm radio - pci

2009-06-23 Thread c kuruwita
Hi

You could try using the card= option when loading the kernel module
and use the cardnumber of a similar supported saa7134 dvb card.
you can find a complete list of supported card saa713 dvb cards in
Documentation/video4linux/CARDLIST.saa7134.

Cheers

Chatura

On Sat, May 23, 2009 at 6:42 AM, jhmoo...@telkomsa.net wrote:
 Does anyone have any information on the support status of this card? Or
 perhaps any hints I might try to get it working?

 I have built and installed the latest V4L-DVB kernel driver modules, but
 no luck.

 I noticed windows installs Philips 3xhybrid drivers if this helps...

 Product website:
 http://www.gigabyte.com.tw/Products/TVCard/Products_Spec.aspx?ClassValue=TV+CardProductID=2757ProductName=GT-P8000

 Tuner NXP 18271
 Decoder NXP 7131E

 lspci -vnn:
 00:09.0 Multimedia controller [0480]: Philips Semiconductors
 SAA7131/SAA7133/SAA7135 Video Broadcast Decoder [1131:7133] (rev d1)
        Subsystem: Giga-byte Technology Device [1458:9004]
        Flags: bus master, medium devsel, latency 32, IRQ 11
        Memory at e600 (32-bit, non-prefetchable) [size=2K]
        Capabilities: [40] Power Management version 2
        Kernel driver in use: saa7134
        Kernel modules: saa7134

 dmesg output:
 [ 3089.801191] saa7130/34: v4l2 driver version 0.2.15 loaded
 [ 3089.801419] saa7133[0]: found at :00:09.0, rev: 209, irq: 11,
 latency: 32, mmio: 0xe600
 [ 3089.801443] saa7133[0]: subsystem: 1458:9004, board: UNKNOWN/GENERIC
 [card=0,autodetected]
 [ 3089.801656] saa7133[0]: board init: gpio is 4
 [ 3089.952088] saa7133[0]: i2c eeprom 00: 58 14 04 90 54 20 1c 00 43 43
 a9
 1c 55 d2 b2 92
 [ 3089.952125] saa7133[0]: i2c eeprom 10: ff ff ff ff ff 20 ff ff ff ff
 ff
 ff ff ff ff ff
 [ 3089.952153] saa7133[0]: i2c eeprom 20: 01 40 01 02 02 01 01 03 08 ff
 00
 b3 ff ff ff ff
 [ 3089.952180] saa7133[0]: i2c eeprom 30: ff ff ff ff ff ff ff ff ff ff
 ff
 ff ff ff ff ff
 [ 3089.952206] saa7133[0]: i2c eeprom 40: 50 35 00 c0 96 10 05 32 d5 15
 0e
 00 ff ff ff ff
 [ 3089.952233] saa7133[0]: i2c eeprom 50: ff ff ff ff ff ff ff ff ff ff
 ff
 ff ff ff ff ff
 [ 3089.952260] saa7133[0]: i2c eeprom 60: ff ff ff ff ff ff ff ff ff ff
 ff
 ff ff ff ff ff
 [ 3089.952287] saa7133[0]: i2c eeprom 70: ff ff ff ff ff ff ff ff ff ff
 ff
 ff ff ff ff ff
 [ 3089.952314] saa7133[0]: i2c eeprom 80: ff ff ff ff ff ff ff ff ff ff
 ff
 ff ff ff ff ff
 [ 3089.952340] saa7133[0]: i2c eeprom 90: ff ff ff ff ff ff ff ff ff ff
 ff
 ff ff ff ff ff
 [ 3089.952367] saa7133[0]: i2c eeprom a0: ff ff ff ff ff ff ff ff ff ff
 ff
 ff ff ff ff ff
 [ 3089.952394] saa7133[0]: i2c eeprom b0: ff ff ff ff ff ff ff ff ff ff
 ff
 ff ff ff ff ff
 [ 3089.952421] saa7133[0]: i2c eeprom c0: ff ff ff ff ff ff ff ff ff ff
 ff
 ff ff ff ff ff
 [ 3089.952447] saa7133[0]: i2c eeprom d0: ff ff ff ff ff ff ff ff ff ff
 ff
 ff ff ff ff ff
 [ 3089.952474] saa7133[0]: i2c eeprom e0: ff ff ff ff ff ff ff ff ff ff
 ff
 ff ff ff ff ff
 [ 3089.952501] saa7133[0]: i2c eeprom f0: ff ff ff ff ff ff ff ff ff ff
 ff
 ff ff ff ff ff
 [ 3089.953430] saa7133[0]: registered device video0 [v4l2]
 [ 3089.953507] saa7133[0]: registered device vbi0
 [ 3090.023006] saa7134 ALSA driver for DMA sound loaded
 [ 3090.023158] saa7133[0]/alsa: saa7133[0] at 0xe600 irq 11
 registered
 as card -2

 --

  raincl...@fastmail.fm

 --
 http://www.fastmail.fm - Email service worth paying for. Try it for free


 ___
 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

--
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: Sakar 57379 USB Digital Video Camera...

2009-06-23 Thread Theodore Kilgore



On Tue, 23 Jun 2009, Andy Walls wrote:


On Mon, 2009-06-22 at 10:51 -0500, Theodore Kilgore wrote:


On Mon, 22 Jun 2009, Andy Walls wrote:


On Sun, 2009-06-21 at 22:39 -0500, Theodore Kilgore wrote:

Andy,

You are right. Your camera is emitting JPEG while streaming. I just
succeeded in creating an image which resembles your test picture by
extracting the frame data for one frame, tacking on a header, and running
hex2bin on the combined file. I did not get the thing quite right, because
your header is from your JPEG photo (640x480) and your stream is probably
320x240. But I got something out which is obviously recognizable.


Excellent.  Going from It may never work to something recognizable
in one weekend is good progress.


Well, sometimes the easy and obvious just works, and one is lucky. If only
they were all that easy.


I'd contend most would be easy and obvious, as anything created by
people is usually easy to understand.  People are generally lazy and
want to avoid what they perceive as extra effort.  If you couple that
with management pressure on engineers to keep costs down and maintain
project schedules, you often end up with very simple solutions.


There is some truth to this, yes.



The data encoding used by the camera is indicative of that.  For this
camera, the engineers decided to simply drop the (M)JPEG headers to save
USB communications bandwidth instead of using a different, better
compression algorithm; or a imlementing new USB 2.0 interface.



Besides, as we well know, this list is a place
where geniuses hang out. So perhaps some of the pixie dust has rubbed off
on us.


I thought genius was inspiration and perspiration. Pixie dust - I knew
Edison wasn't telling the whole truth. ;)






Therefore with a little bit of further tweaking it will presumably come
out exactly so. Namely, I have to remember where to stick the two
dimensions into the header.


Found that, as I said yesterday evening.



Yes, as far as I'm concerned the problem is solved.  The details are
left as an exercise for the reader. ;)



I will try to get on it. There is nothing left but details, but there are
lots of those.


Yes, I agree.  Getting those right is no small task.



The first one is to get the header exactly right.


Well,  given that the Windows driver has the AVI video stream FourCC
'vids' appearing four or five times, I suspect there is more than 1
header template that the Windows driver can tack on to the incoming
stream.  I'm guessing that which one is used, depends on how the camera
stream is initialized.


Sort of, yes. At least that is the way it looks over here. The sequence of 
button-push steps for initializing my camera to do streaming is just 
about the same as that for inducing it to shoot an AVI, and then the 
question is whether you turned on capturing from the computer or not. If 
you did, then you get a stream. If you didn't then it seems the camera 
makes an AVI.




There are probably all sorts of header permutations that will yield
viewable but suboptimal reconstruction. :(

Then again it's a cheap webcam, so by definition any image is probably
suboptimal.


Well, interestingly, your header and mine, when affixed to my one frame, 
are doing about equally well. But the two headers seem to differ from each 
other.


snip


I'm not up to speed on Linux webcam kernel to userspace API details.
However, might I suggest going forward for testing at least, that when
one starts the webcam streaming, the driver emit the stream in the form
of an AVI.  You'd need an AVI header declaring only an MJPEG 'vids'
stream - no 'auds' nor 'idx' - and a 'movi' section with RIFF/AVI chunks
that have MJPEG headers and the webcam payload.


For all I know, it might be just a matter of following down a standard
path. Perhaps this is all handled already in libv4lconvert, and it is
merely a matter of plugging into that. I haven't checked yet, but that is
more or less what I expect right now.



Ah, OK.


Revision:

It seems that some other drivers are providing the jpeg header. There is a 
file gspca/jpeg.h from which to get it. So perhaps libv4lconvert is not 
much involved after all. As I said, I have not yet looked seriously into 
this. I spent yesterday evening trying to write a module, with which I 
tried to grab a raw frame (no header, no nothing) and it did not succeed. 
Clearly, my efforts need to be refined.






I haven't seen evidence that audio comes from the webcam when it is
streaming, but I haven't looked very much either.


Same. Actually, my impression is that these cameras can not walk and chew
gum at the same time. I would suspect that the audio is an either/or kind
of thing. Either on, and it can record audio but not stream it, or off. I
would be very surprised if an el cheapo like the one I have could do more.
I could be wrong, of course. Perhaps both of us ought to check closely.


I know it can simultaneously record audio and video to an AVI file in
it's local storage.  I'm 

sub devices sharing same i2c address

2009-06-23 Thread Karicheri, Muralidharan
Hi,

I am having to switch between two sub devices that shares the same i2c address. 
First one is TVP5146 and the other is MT9T031. The second has a i2c switch and 
the evm has a data path switch. So in our internal release we could switch 
capture inputs between the two by configuring the above two switches. Right 
now, I am loading up the i2c sub devices using the new API (added by Hans) 
v4l2_i2c_new_subdev_board(). But since the i2c addresses are shared, it fails 
for the second sub device. Does someone know a way to get around this so that I 
could load up both sub devices and switch between them for capture?

Murali Karicheri
Software Design Engineer
Texas Instruments Inc.
Germantown, MD 20874
Phone : 301-515-3736
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


[cron job] v4l-dvb daily build 2.6.22 and up: WARNINGS, 2.6.16-2.6.21: ERRORS

2009-06-23 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:Tue Jun 23 19:00:04 CEST 2009
path:http://www.linuxtv.org/hg/v4l-dvb
changeset:   12132:b362d09e34d4
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.27-armv5-ixp: WARNINGS
linux-2.6.28-armv5-ixp: WARNINGS
linux-2.6.29.1-armv5-ixp: WARNINGS
linux-2.6.30-armv5-ixp: WARNINGS
linux-2.6.28-armv5-omap2: WARNINGS
linux-2.6.29.1-armv5-omap2: WARNINGS
linux-2.6.30-armv5-omap2: WARNINGS
linux-2.6.22.19-i686: WARNINGS
linux-2.6.23.12-i686: WARNINGS
linux-2.6.24.7-i686: WARNINGS
linux-2.6.25.11-i686: WARNINGS
linux-2.6.26-i686: WARNINGS
linux-2.6.27-i686: WARNINGS
linux-2.6.28-i686: WARNINGS
linux-2.6.29.1-i686: WARNINGS
linux-2.6.30-i686: WARNINGS
linux-2.6.23.12-m32r: OK
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.30-mips: WARNINGS
linux-2.6.27-powerpc64: WARNINGS
linux-2.6.28-powerpc64: WARNINGS
linux-2.6.29.1-powerpc64: WARNINGS
linux-2.6.30-powerpc64: WARNINGS
linux-2.6.22.19-x86_64: WARNINGS
linux-2.6.23.12-x86_64: WARNINGS
linux-2.6.24.7-x86_64: WARNINGS
linux-2.6.25.11-x86_64: WARNINGS
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: OK
linux-2.6.30-x86_64: WARNINGS
sparse (linux-2.6.30): 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: WARNINGS
linux-2.6.20.21-i686: WARNINGS
linux-2.6.21.7-i686: WARNINGS
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: WARNINGS
linux-2.6.20.21-x86_64: WARNINGS
linux-2.6.21.7-x86_64: WARNINGS

Detailed results are available here:

http://www.xs4all.nl/~hverkuil/logs/Tuesday.log

Full logs are available here:

http://www.xs4all.nl/~hverkuil/logs/Tuesday.tar.bz2

The V4L2 specification failed to build, but the last compiled spec 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: Leadtek Winfast DTV-1000S

2009-06-23 Thread Michael Krufky
(apologies if you've received this email twice -- something is strange
with my kernellabs.com email settings -- I will look into this soon)

On Mon, Jun 22, 2009 at 6:51 AM, James Moschoujames.mosc...@gmail.com wrote:
 Using dtv1000s tree revision 21a03349f7f9 and a blank modprobe.conf

 I can tune to channels but never all of them in the single run of w_scan.
 Every time I run w_scan it's different channels that say 'filter timeout'.

James,

Unfortunately, I can't say that a driver bug is the cause of your
inconsistency -- perhaps you can aim your antennae a bit better, or
find some other cause of interference.  Bad cabling?

Lets say that you have your channels.conf all set up and ready -- once
you found all your services, do you have trouble keeping a stream?

Regards,

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: sub devices sharing same i2c address

2009-06-23 Thread Daniel Glöckner
On Tue, Jun 23, 2009 at 01:10:11PM -0500, Karicheri, Muralidharan wrote:
 I am having to switch between two sub devices that shares the same i2c
 address. First one is TVP5146 and the other is MT9T031. The second has
 a i2c switch and the evm has a data path switch.

You could try Rodolfo Giometti's i2c bus multiplexing code:
http://i2c.wiki.kernel.org/index.php/I2C_bus_multiplexing

It will create a new i2c_adapter for each output of the i2c switch
and the switch is handled transparently when accessing the devices.

  Daniel
--
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: lsmod path hardcoded in v4l/Makefile

2009-06-23 Thread Trent Piepho
On Tue, 23 Jun 2009, Matthias Schwarzott wrote:
  On Mon, 2009-06-22 at 16:36 +0200, Matthias Schwarzott wrote:
   It seems the path to lsmod tool is hardcoded in the Makefile for
   out-of-tree building of v4l-dvb.
 
 Shouldn't $PATH of root be considered safe? Else the distro or the system

I believe make will set the variable whenever the makefile is used, even
when building as non-root.

It turns out that it was just lsmod with no path originally, but Michael
Krufky changed it back in 2005 (commit b0e7b40744ef) to have a hardcoded
path.  Then later in commit c91e7f84a1d6 the only use of 'v4l_modules' was
deleted, so we can just delete this line and not worry about sbin and
paths.

Mauro,

Please pull from http://linuxtv.org/hg/~tap/fix

for the following changeset:

build: Remove module list cruft
http://linuxtv.org/hg/~tap/fix?cmd=changeset;node=fb228bb1ad9f
--
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] Gigabyte GT-P8000 dvb-t / analog / fm radio - pci

2009-06-23 Thread hermann pitton
Hi,

Am Mittwoch, den 24.06.2009, 01:36 +1000 schrieb c kuruwita:
 Hi
 
 You could try using the card= option when loading the kernel module
 and use the cardnumber of a similar supported saa7134 dvb card.
 you can find a complete list of supported card saa713 dvb cards in
 Documentation/video4linux/CARDLIST.saa7134.
 

that might become a very frustrating experience and it is also not
without some danger. At least you might get the card in a not further
responding state and you might need a cold boot in between.

Minimum further to know is the type of the digital demodulator these
days!

If it is for example a tda10048, there are currently only two cards to
test on for DVB-T, but likely with slightly different hardware
configuration.

You also need to know if it needs firmware and which one.

The saa7134 insmod option i2c_scan=1 should be used to see if at least
all chips are visible. You might need special gpio switching else to get
them out of some power saving state.

You also don't know if you need gate control enabled of the tda8290
analog IF demod built into the saa7131e to initialize and further
program the tuner.

Tuner, digital demod and analog demod can be on four different i2c
addresses each. For dvb-t you need to know and set each of those
addresses correctly. It makes no sense to try on cards having this not
all the same.

The eeprom, if it is correct on this, says tuner at 0x60, analog demod
at 0x4b and digital demod at 0x08 in seven bit notation. The tuner at
0x60 is rather rare, if you look into saa7134-dvb.c. Makes no sense to
test on other cards.

Then we always want to have the antenna inputs reported. What shares
with what an input and what is on a separate one?
Only this way you can _eventually_ find a card with the same switching
there and also correct FM switch.

Next, most recent cards do have an additional RF LNA and there are
different types. All must be correctly set up for analog and digital
mode or you will have some unpleasant experiences. Seems there is no way
for us currently to know, if there is one at all or which type of
configuration it does need.

You must also know or find out, if the card uses serial or parallel TS
interface.

Even if you succeed with all the above, and that is possible by working
through step by step, especially with a tda10048 you might need a card
specific configuration not yet covered by other cards.

Blindly testing on cards without knowing on what you are testing
exactly, unlikely has good results on recent hybrid cards.

First of all you must know the type of digital demod on that card too.
The fuzzy picture I found seems to say it has only 48 pins ...

Always recommend to read further on the wiki about how to provide a good
report for new hardware.

Cheers,
Hermann

 
 On Sat, May 23, 2009 at 6:42 AM, jhmoo...@telkomsa.net wrote:
  Does anyone have any information on the support status of this card? Or
  perhaps any hints I might try to get it working?
 
  I have built and installed the latest V4L-DVB kernel driver modules, but
  no luck.
 
  I noticed windows installs Philips 3xhybrid drivers if this helps...
 
  Product website:
  http://www.gigabyte.com.tw/Products/TVCard/Products_Spec.aspx?ClassValue=TV+CardProductID=2757ProductName=GT-P8000
 
  Tuner NXP 18271
  Decoder NXP 7131E
 
  lspci -vnn:
  00:09.0 Multimedia controller [0480]: Philips Semiconductors
  SAA7131/SAA7133/SAA7135 Video Broadcast Decoder [1131:7133] (rev d1)
 Subsystem: Giga-byte Technology Device [1458:9004]
 Flags: bus master, medium devsel, latency 32, IRQ 11
 Memory at e600 (32-bit, non-prefetchable) [size=2K]
 Capabilities: [40] Power Management version 2
 Kernel driver in use: saa7134
 Kernel modules: saa7134
 
  dmesg output:
  [ 3089.801191] saa7130/34: v4l2 driver version 0.2.15 loaded
  [ 3089.801419] saa7133[0]: found at :00:09.0, rev: 209, irq: 11,
  latency: 32, mmio: 0xe600
  [ 3089.801443] saa7133[0]: subsystem: 1458:9004, board: UNKNOWN/GENERIC
  [card=0,autodetected]
  [ 3089.801656] saa7133[0]: board init: gpio is 4
  [ 3089.952088] saa7133[0]: i2c eeprom 00: 58 14 04 90 54 20 1c 00 43 43
  a9
  1c 55 d2 b2 92
  [ 3089.952125] saa7133[0]: i2c eeprom 10: ff ff ff ff ff 20 ff ff ff ff
  ff
  ff ff ff ff ff
  [ 3089.952153] saa7133[0]: i2c eeprom 20: 01 40 01 02 02 01 01 03 08 ff
  00
  b3 ff ff ff ff
  [ 3089.952180] saa7133[0]: i2c eeprom 30: ff ff ff ff ff ff ff ff ff ff
  ff
  ff ff ff ff ff
  [ 3089.952206] saa7133[0]: i2c eeprom 40: 50 35 00 c0 96 10 05 32 d5 15
  0e
  00 ff ff ff ff
  [ 3089.952233] saa7133[0]: i2c eeprom 50: ff ff ff ff ff ff ff ff ff ff
  ff
  ff ff ff ff ff
  [ 3089.952260] saa7133[0]: i2c eeprom 60: ff ff ff ff ff ff ff ff ff ff
  ff
  ff ff ff ff ff
  [ 3089.952287] saa7133[0]: i2c eeprom 70: ff ff ff ff ff ff ff ff ff ff
  ff
  ff ff ff ff ff
  [ 3089.952314] saa7133[0]: i2c eeprom 80: ff ff ff ff ff ff ff ff ff ff
  ff
  ff ff ff ff ff
  [ 3089.952340] 

Re: PxDVR3200 H LinuxTV v4l-dvb patch : Pull GPIO-20 low for DVB-T

2009-06-23 Thread Andy Walls
On Tue, 2009-06-23 at 14:33 +0200, Hans Verkuil wrote:
  On Tue, 2009-06-23 at 11:39 +0800, Terry Wu wrote:
  Hi,
 
  I add the following codes in the cx23885_initialize() of
  cx25840-core.c:
 /* Drive GPIO2 (GPIO 19~23) direction and values for DVB-T */
 cx25840_and_or(client, 0x160, 0x1d, 0x00);
 cx25840_write(client, 0x164, 0x00);
 
  Before that, the tuning status is 0x1e, but 0 service found.
  Now, I can watch DVB-T (Taiwan, 6MHz bandwidth).
 
  And if you are living in Australia, you should update the
  tuner-xc2028.c too:
  
  http://tw1965.myweb.hinet.net/Linux/v4l-dvb/20090611-TDA18271HDC2/tuner-xc2028.c
 
  Best Regards,
  Terry
 
 
  Hans,
 
  As I think of potential ways to handle this, I thought we may need to
  add a v4l2_subdev interface for setting and reading GPIO's.
 
 There is already an s_gpio in the core ops. It would be simple to add a
 g_gpio as well if needed.

Ooops.  Sorry for not doing my homework.  Thanks.

 
 It is not a good idea to directly control GPIO pins from within a subdev
 driver for the simple reason that the subdev driver has no idea how its
 gpio pins are hooked up. This should really be done from the v4l driver
 itself.

Agree. This is what I waas thinking.

Regards,
Andy

  If you need a notification from the subdev that the v4l driver
 needs to take some action, then the subdev can send a notification through
 the notify function in v4l2_device. That's currently used by one subdev
 driver that requires that the v4l driver toggles a GPIO pin at the right
 time.
 
 Regards,
 
   Hans


--
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: PxDVR3200 H LinuxTV v4l-dvb patch : Pull GPIO-20 low for DVB-T

2009-06-23 Thread Andy Walls
On Tue, 2009-06-23 at 21:10 +0800, Terry Wu wrote:


 2. Also, I can not find GPIO functions in the cx25840-core.c
 
 Something missing or unfinished ?

Missing: they are not implemented in the cx25840 driver.  I will at
least implement a change to the cx25840 module so the v4l bridge driver
(cx23885) can set the GPIOs.

Regards,
Andy


 Best Regards,
 Terry


--
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] [Resend] cxusb, d680 dmbth use unified lgs8gxx code instead of lgs8gl5

2009-06-23 Thread Timothy Lee

On 06/17/2009 03:05 AM, Mauro Carvalho Chehab wrote:

Hi David,

Em Thu, 11 Jun 2009 01:16:13 +0800
David Wongdavidtlw...@gmail.com  escreveu:
   

Use unified lgs8gxx frontend instead of reverse engineered lgs8gl5 frontend.
After this patch, lgs8gl5 frontend could be mark as deprecated.
Future development should base on unified lgs8gxx frontend.

Signed-off-by: David T.L. Wongdavidtlwongat  gmail.com
 

Your patch makes sense. Have you tested it with the Magic-Pro DMB-TH usb stick?

Michael and Timothy,

Can you check if the new frontend module works with the currently supported
devices?
   

Dear all,

It's Timothy here -- I'm the original author of the lgs8gl5 module.  
Sorry for the late reply, but since my office's relocation, I've been 
having a hard time getting good TV reception, and had not been able to 
exercise the patch.


However, I've been in close contact with David, and did try an earlier 
version of his patch prior to moving, so I'm optimistic that it should work.



Regards,
Timothy Lee
--
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