date:20110527

On Wednesday, May 25, 2011 22:06:38 Laurent Pinchart wrote:
 Hi Jerry,
 
 On Wednesday 25 May 2011 21:44:59 Jerry Geis wrote:
  I am trying to find the code for h.264 mentioned
   http://www.spinics.net/lists/linux-media/msg29129.html
  
  I downloaded the linux-media-2011-05.24 and it is not part of uvc_driver.c
  
  Where can I get the code?
 
 That code only exists in the patches you've found. They haven't been applied 
 to the uvcvideo driver, because we haven't decided yet how H.264 should be 
 exposed to applications by the V4L2 API.
 
 We now have a better understanding of H.264. Hans, could you review the H.264 
 patch at the link above and tell me what you now think about the new fourcc ?

Yes, that's fine. It matches the proposals from Kamil Debski, so this can go 
ahead.

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: [PATCH][RFC] Add mt9p031 sensor support.

2011-05-27 Thread Guennadi Liakhovetski

On Fri, 27 May 2011, javier Martin wrote:

 On 25 May 2011 11:43, Laurent Pinchart
 laurent.pinch...@ideasonboard.com wrote:
  Hi Javier,
 
  On Wednesday 25 May 2011 11:41:42 javier Martin wrote:
  Hi,
  thank you for the review, I agree with you on all the suggested
  changes except on this one:
 
  On 25 May 2011 10:05, Laurent Pinchart wrote:
   On Tuesday 24 May 2011 16:30:43 Javier Martin wrote:
   This RFC includes a power management implementation that causes
   the sensor to show images with horizontal artifacts (usually
   monochrome lines that appear on the image randomly).
  
   Signed-off-by: Javier Martin javier.mar...@vista-silicon.com
  
   [snip]
  
   diff --git a/drivers/media/video/mt9p031.c
   b/drivers/media/video/mt9p031.c new file mode 100644
   index 000..04d8812
   --- /dev/null
   +++ b/drivers/media/video/mt9p031.c
  
   [snip]
  
   +#define MT9P031_WINDOW_HEIGHT_MAX            1944
   +#define MT9P031_WINDOW_WIDTH_MAX             2592
   +#define MT9P031_WINDOW_HEIGHT_MIN            2
   +#define MT9P031_WINDOW_WIDTH_MIN             18
  
   Can you move those 4 constants right below MT9P031_WINDOW_HEIGHT and
   MT9P031_WINDOW_WIDTH ? The max values are not correct, according to the
   datasheet they should be 2005 and 2751.
 
  In figure 4, it says active image size is 2592 x 1944
  Why should I include active boundary and dark pixels?
 
  Users might want to get the dark pixels for black level compensation 
  purpose.
  As the chip allows for that, it should be supported. The default should of
  course be the active area of 2592 x 1944 pixels.
 
 
 OK, that sounds reasonable. However, that would include black pixels
 that are located at the beginning of the array (0,0) to (16, 54),
 which means that users would have to specify a crop value of (15,54)
 to eliminate those initial black level pixels. Which seems quite
 unnatural to me.
 Another option could be setting (16,54) as default values and allowing
 to introduce negative cropping values. Is this possible?
 And finally, the most sensible idea IMHO could be not letting the user
 to see pixels from (0,0) to (15,54) (setting 15,54 as minimum and
 default )and, for black level compensation, ending pixels could be
 used (2608,1998) to (2751, 2003).

No, you set your crop bounds to (0,0)-... but your default rectangle to 
(15,54)-... and that's also what you set if noone issues an S_CROP.

Thanks
Guennadi

 What do you think?
 
 
 -- 
 Javier Martin
 Vista Silicon S.L.
 CDTUC - FASE C - Oficina S-345
 Avda de los Castros s/n
 39005- Santander. Cantabria. Spain
 +34 942 25 32 60
 www.vista-silicon.com
 

---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: PCTV nanoStick T2 290e support - Thank you!

2011-05-27 Thread Bjørn Mork

Antti Palosaari cr...@iki.fi writes:
 On 05/27/2011 12:25 AM, Nicolas WILL wrote:
 Just installed mine for MythTV.

 Works great on the first try!

 Many, many thanks!

 Thank you for the feedback!

I'm a bit curious about this device.  It seems to only be marketed as a
DVB-T2 device in areas where that spec is used.  But looking at your
driver, it seems that the device also supports DVB-C.  Is that correct?



Bjørn

--
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: PCTV nanoStick T2 290e support - Thank you!

2011-05-27 Thread Rémi Denis-Courmont

On Fri, 27 May 2011 13:36:37 +0200, Bjørn Mork bj...@mork.no wrote:

 Antti Palosaari cr...@iki.fi writes:

 On 05/27/2011 12:25 AM, Nicolas WILL wrote:

 Just installed mine for MythTV.



 Works great on the first try!



 Many, many thanks!



 Thank you for the feedback!

 

 I'm a bit curious about this device.  It seems to only be marketed as a

 DVB-T2 device in areas where that spec is used.  But looking at your

 driver, it seems that the device also supports DVB-C.  Is that correct?



At least, DVB-C worked for me.



-- 

Rémi Denis-Courmont

http://www.remlab.net/
--
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: PCTV nanoStick T2 290e support - Thank you!

2011-05-27 Thread Nicolas WILL

 -Original Message-
 From: linux-media-ow...@vger.kernel.org [mailto:linux-media-
 ow...@vger.kernel.org] On Behalf Of Bjørn Mork
 Sent: 27 May 2011 12:37
 To: linux-media@vger.kernel.org
 Subject: Re: PCTV nanoStick T2 290e support - Thank you!

 Antti Palosaari cr...@iki.fi writes:
  On 05/27/2011 12:25 AM, Nicolas WILL wrote:
  Just installed mine for MythTV.

  Works great on the first try!

  Many, many thanks!

  Thank you for the feedback!

 I'm a bit curious about this device.  It seems to only be marketed as a
 DVB-T2 device in areas where that spec is used.  But looking at your
 driver, it seems that the device also supports DVB-C.  Is that correct?

[   12.921835] DVB: registering adapter 4 frontend 0 (Sony CXD2820R 
(DVB-T/T2))...
[   12.921904] DVB: registering adapter 4 frontend 1 (Sony CXD2820R (DVB-C))...

Nico

--
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: PCTV nanoStick T2 290e support - Thank you!

2011-05-27 Thread Bjørn Mork

Rémi Denis-Courmont r...@remlab.net writes:
 On Fri, 27 May 2011 13:36:37 +0200, Bjørn Mork bj...@mork.no wrote:

 I'm a bit curious about this device.  It seems to only be marketed as a
 DVB-T2 device in areas where that spec is used.  But looking at your
 driver, it seems that the device also supports DVB-C.  Is that correct?
 
 At least, DVB-C worked for me.

Thanks.  Then I've ordered one of these :-)


Bjørn

--
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] [media] at91: add Atmel Image Sensor Interface (ISI)support

2011-05-27 Thread Wu, Josh

Hi, Guennadi

Sorry to answer the question so later, 

From: Guennadi Liakhovetski Sent: Thursday, May 12, 2011 5:32 PM
 On Thu, 12 May 2011, Wu, Josh wrote:

 Hi, Russell

 From: Russell King - ARM Linux [mailto:li...@arm.linux.org.uk] Sent: 
 Thursday, May 12, 2011 3:47 PM
  On Thu, May 12, 2011 at 03:42:18PM +0800, Josh Wu wrote:
  +err_alloc_isi:
  + clk_disable(pclk);
  clk_put() ?
 Ok, will be fixed in V2 patch. Thanks.

 You might wait with v2 until I find time to review your patch. Will take a 
 couple of days, I think. A general question, though: how compatible is 
 this driver with the AVR32?
Now from the information I got from AVR team, The AVR32 is not compatible with  
ISI driver patch v2. Since AVR32 use the previous version of ISI IP core. 
(AT91SAM9M10 using ISI_V2 IP, which has different hardware registers from V1 IP 
core, such like dma control, etc)
But I think in future we will add ISI V1 IP support since AT91SAM9263 also 
using ISI V1 IP core.

Best Regards,
Josh Wu
--
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: PCTV nanoStick T2 290e support - Thank you!

2011-05-27 Thread Steve Kerrison

The demodulator chip supports T,T2 and C.

Here in the UK you're not really allowed to attach cable receivers that
aren't supplied by the cable company (Virgin Media). That and the fact
that it has no access module for obvious reasons, I guess PCTV Systems
didn't see the benefit in marketing the C functionality.

I don't actually know if the windows driver supports C mode, it would be
amusing if we deliver more functionality with the Linux driver :)

Regards,
-- 
Steve Kerrison MEng Hons.
http://www.stevekerrison.com/ 

On Fri, 2011-05-27 at 13:36 +0200, Bjørn Mork wrote:
 Antti Palosaari cr...@iki.fi writes:
  On 05/27/2011 12:25 AM, Nicolas WILL wrote:
  Just installed mine for MythTV.
 
  Works great on the first try!
 
  Many, many thanks!
 
  Thank you for the feedback!
 
 I'm a bit curious about this device.  It seems to only be marketed as a
 DVB-T2 device in areas where that spec is used.  But looking at your
 driver, it seems that the device also supports DVB-C.  Is that correct?
 
 
 
 Bjørn
 
 --
 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: [PATCH v2] [media] at91: add Atmel Image Sensor Interface (ISI) support

2011-05-27 Thread Jean-Christophe PLAGNIOL-VILLARD

 +/* ISI interrupt service routine */
 +static irqreturn_t isi_interrupt(int irq, void *dev_id)
 +{
 + struct atmel_isi *isi = dev_id;
 + u32 status, mask, pending;
 + irqreturn_t ret = IRQ_NONE;
 +
 + spin_lock(isi-lock);
 +
 + status = isi_readl(isi, ISI_STATUS);
 + mask = isi_readl(isi, ISI_INTMASK);
 + pending = status  mask;
 +
 + if (pending  ISI_CTRL_SRST) {
 + complete(isi-isi_complete);
 + isi_writel(isi, ISI_INTDIS, ISI_CTRL_SRST);
 + ret = IRQ_HANDLED;
 + }
 + if (pending  ISI_CTRL_DIS) {
 + complete(isi-isi_complete);
 + isi_writel(isi, ISI_INTDIS, ISI_CTRL_DIS);
 + ret = IRQ_HANDLED;
 + }
no else here?
 +
 + if (pending  ISI_SR_VSYNC) {
 + switch (isi-state) {
 + case ISI_STATE_IDLE:
 + isi-state = ISI_STATE_READY;
 + wake_up_interruptible(isi-capture_wq);
 + break;
 + }
really switch here?
 + } else if (likely(pending  ISI_SR_CXFR_DONE)) {
 + ret = atmel_isi_handle_streaming(isi);
 + }
 +
 + spin_unlock(isi-lock);
 +
 + return ret;
 +}
 +
 +#define  WAIT_ISI_RESET  1
 +#define  WAIT_ISI_DISABLE0
 +static int atmel_isi_wait_status(int wait_reset, struct atmel_isi *isi)
I thinkhave teh atmel_isti first parameter is better
 +{
 + unsigned long timeout;
 + /*
 +  * The reset or disable will only succeed if we have a
 +  * pixel clock from the camera.
 +  */
 + init_completion(isi-isi_complete);
 +
 + if (wait_reset) {
 + isi_writel(isi, ISI_INTEN, ISI_CTRL_SRST);
 + isi_writel(isi, ISI_CTRL, ISI_CTRL_SRST);
 + } else {
 + isi_writel(isi, ISI_INTEN, ISI_CTRL_DIS);
 + isi_writel(isi, ISI_CTRL, ISI_CTRL_DIS);
 + }
 +
 + timeout = wait_for_completion_timeout(isi-isi_complete,
 + msecs_to_jiffies(100));
 + if (timeout == 0)
 + return -ETIMEDOUT;
 +
 + return 0;
 +}
 +
 +/* --
 + Videobuf operations
 +   --*/
 +static int queue_setup(struct vb2_queue *vq, unsigned int *nbuffers,
 + unsigned int *nplanes, unsigned long sizes[],
 + void *alloc_ctxs[])
 +{
 + struct soc_camera_device *icd = soc_camera_from_vb2q(vq);
 + struct soc_camera_host *ici = to_soc_camera_host(icd-dev.parent);
 + struct atmel_isi *isi = ici-priv;
 + unsigned long size;
 + int ret, bytes_per_line;
 +
 + /* Reset ISI */
 + ret = atmel_isi_wait_status(WAIT_ISI_RESET, isi);
 + if (ret  0) {
 + dev_err(icd-dev.parent, Reset ISI timed out\n);
 + return ret;
 + }
 + /* Disable all interrupts */
 + isi_writel(isi, ISI_INTDIS, ~0UL);
 +
 + bytes_per_line = soc_mbus_bytes_per_line(icd-user_width,
 + icd-current_fmt-host_fmt);
 +
 + if (bytes_per_line  0)
 + return bytes_per_line;
 +
 + size = bytes_per_line * icd-user_height;
 +
 + if (*nbuffers == 0)
 + *nbuffers = MAX_BUFFER_NUMS;
 + if (*nbuffers  MAX_BUFFER_NUMS)
else here
 + *nbuffers = MAX_BUFFER_NUMS;
 +
 + if (size * *nbuffers  VID_LIMIT_BYTES)
 + *nbuffers = VID_LIMIT_BYTES / size;
 +
 + *nplanes = 1;
 + sizes[0] = size;
 + alloc_ctxs[0] = isi-alloc_ctx;
 +
 + isi-sequence = 0;
 + isi-active = NULL;
 +
 + dev_dbg(icd-dev.parent, %s, count=%d, size=%ld\n, __func__,
 + *nbuffers, size);
 +
 + return 0;
 +}
 +
 +static int buffer_init(struct vb2_buffer *vb)
 +{
 + struct frame_buffer *buf = container_of(vb, struct frame_buffer, vb);
 +
 + buf-p_fb_desc = NULL;
 + buf-fb_desc_phys = 0;
memset 0?
 + INIT_LIST_HEAD(buf-list);
 +
 + return 0;
 +}
 +
otherwise the patch look good
if you fix the upper issue
Acked-by: Jean-Christophe PLAGNIOL-VILLARD plagn...@jcrosoft.com

Best Regards,
J.
--
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

Brazilian HDTV device

2011-05-27 Thread Moacyr Prado

Hi, I have a board with empia chipset. The em28xx driver not load, 
because the device ID is not listed on source(cards.c, I guess). 

Following bellow 
have some infos from board:
lsusb:
Bus 001 Device 004: ID 1b80:e755 Afatech

Opening the device, shows this ic:

empia em2888 d351c-195 727-00ag (em28xx)
nxp saa7136e/1/g SI5296.1 22 ZSD08411
NXP TDA 18271??C2 HDC2? (tda18271)
F JAPAN mb86a20s 0937 M01 E1 (mb86a20s)

but... dmesg shows:

[18373.454136] usb 6-1: USB disconnect, address 2
[18376.744074] usb 2-1: new high speed USB device using ehci_hcd and address 9
[18376.860283] usb 2-1: New USB device found, idVendor=1b80, idProduct=e755
[18376.860293] usb 2-1: New USB device strings: Mfr=0, Product=1, SerialNumber=2
[18376.860300] usb 2-1: Product: USB 2885 Device
[18376.860306] usb 2-1: SerialNumber: 1


Could The em28xx module (writing some code for me)handle this device?

Thanks,
Moa
--
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: PCTV nanoStick T2 290e support - Thank you!

2011-05-27 Thread Bjørn Mork

Steve Kerrison st...@stevekerrison.com writes:

The demodulator chip supports T,T2 and C.

Here in the UK you're not really allowed to attach cable receivers that
aren't supplied by the cable company (Virgin Media). That and the fact
that it has no access module for obvious reasons, I guess PCTV Systems
didn't see the benefit in marketing the C functionality.

Well, I found it a bit weird that they do announce DVB-T + DVB-C support
for the PCTV QuatroStick nano (which has the exact same form factor
and look, and therefore obviously no CA slot either):
http://www.pctvsystems.com/Products/ProductsEuropeAsia/Hybridproducts/PCTVQuatroSticknano/tabid/254/language/en-GB/Default.aspx

While the PCTV nanoStick T2 is announced as only DVB-T2 + DVB-T:
http://www.pctvsystems.com/Products/ProductsEuropeAsia/Digitalproducts/PCTVnanoStickT2/tabid/248/language/en-GB/Default.aspx

That's why I asked, even though the driver clearly supports DVB-C. But
you may be right that this is because the nanoStick T2 currently is
targeted for the UK.

Around here, we've actually got some cable companies supporting TV sets
with integrated receivers. Of course requiring their CAM. They
probably still don't like the thought of PC based receivers, but there
is some hope...

I don't actually know if the windows driver supports C mode, it would be
amusing if we deliver more functionality with the Linux driver :)

I thought downloading the Windows driver would tell, but
a) I cannot seem to find the Windows driver for this device, and
b) this info isn't easily found in the drivers I looked at

So who knows? It would certainly be amusing.

Bjørn

--
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: PCTV nanoStick T2 290e support - Thank you!

2011-05-27 Thread Steve Kerrison

Hi Bjørn,

 I thought downloading the Windows driver would tell, but
 a) I cannot seem to find the Windows driver for this device, and
 b) this info isn't easily found in the drivers I looked at

The bundled CD has the drivers on it, but I think it's also in the
driver bundle on their site for their other empia based cards:

ftp://ftp.pctvsystems.com/TV/driver/PCTV%2070e%2080e%20100e%20320e%
20330e%20800e/PCTV%2070e%2080e%20100e%20320e%20330e%20800e%20880e.zip

Found via
http://www.pctvsystems.com/tabid/62/default.aspx/Downloads/Driver/tabid/123/language/en-GB/Default.aspx

I'm not sure how you'd tell, other than perhaps firing up VLC on Windows
and seeing if you can open it as a DVB-C device?

Regards,
-- 
Steve Kerrison MEng Hons.
http://www.stevekerrison.com/ 

On Fri, 2011-05-27 at 14:41 +0200, Bjørn Mork wrote:
 Steve Kerrison st...@stevekerrison.com writes:
 
  The demodulator chip supports T,T2 and C.
 
  Here in the UK you're not really allowed to attach cable receivers that
  aren't supplied by the cable company (Virgin Media). That and the fact
  that it has no access module for obvious reasons, I guess PCTV Systems
  didn't see the benefit in marketing the C functionality.
 
 Well, I found it a bit weird that they do announce DVB-T + DVB-C support
 for the PCTV QuatroStick nano (which has the exact same form factor
 and look, and therefore obviously no CA slot either):
 http://www.pctvsystems.com/Products/ProductsEuropeAsia/Hybridproducts/PCTVQuatroSticknano/tabid/254/language/en-GB/Default.aspx
 
 While the PCTV nanoStick T2 is announced as only DVB-T2 + DVB-T:
 http://www.pctvsystems.com/Products/ProductsEuropeAsia/Digitalproducts/PCTVnanoStickT2/tabid/248/language/en-GB/Default.aspx
 
 That's why I asked, even though the driver clearly supports DVB-C.  But
 you may be right that this is because the nanoStick T2 currently is
 targeted for the UK.
 
 Around here, we've actually got some cable companies supporting TV sets
 with integrated receivers.  Of course requiring their CAM.  They
 probably still don't like the thought of PC based receivers, but there
 is some hope...
 
 
  I don't actually know if the windows driver supports C mode, it would be
  amusing if we deliver more functionality with the Linux driver :)
 
 I thought downloading the Windows driver would tell, but
 a) I cannot seem to find the Windows driver for this device, and
 b) this info isn't easily found in the drivers I looked at
 
 So who knows?  It would certainly be amusing.
 
 
 Bjørn
 
 --
 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

[PATCH 0/5] Fix micellaneous issues for M-5MOLS driver

This patch series is to handle some issues about M-5MOLS driver.

Except for first patch, most of these issues comes from to Sakari,
And I very appreciate the comments and reviews about this driver. Thanks.

The first change is fixing to read wrong capture image size.

The second change is preventing overwriting part of memory by u32 value
argument of m5mols_read(). So, add exclusive functions according to byte
width of value argument.

The third change is removing using union by reading version information,
and choose reading directly.

The fourth change is renmaing m5mols_capture_error_handler() to proper name -
m5mols_capture_post_work(). This function's object is to proceed all post works
in this function. And, so, I add more comments and rename this function
for preventing to confuse.

The fifth change is missign ,  for the email address.

Thanks, and any comments welcome.

Regards,
Heungjun Kim

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

[PATCH 1/5] m5mols: fix reading wrong size of captured main/thumb image

Signed-off-by: HeungJun, Kim riverful@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
 drivers/media/video/m5mols/m5mols_reg.h |4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/media/video/m5mols/m5mols_reg.h 
b/drivers/media/video/m5mols/m5mols_reg.h
index b83e36f..8260f50 100644
--- a/drivers/media/video/m5mols/m5mols_reg.h
+++ b/drivers/media/video/m5mols/m5mols_reg.h
@@ -382,8 +382,8 @@
 #define REG_CAP_START_MAIN 0x01
 #define REG_CAP_START_THUMB0x03
 
-#define CAPC_IMAGE_SIZEI2C_REG(CAT_CAPT_CTRL, 
CATC_CAP_IMAGE_SIZE, 1)
-#define CAPC_THUMB_SIZEI2C_REG(CAT_CAPT_CTRL, 
CATC_CAP_THUMB_SIZE, 1)
+#define CAPC_IMAGE_SIZEI2C_REG(CAT_CAPT_CTRL, 
CATC_CAP_IMAGE_SIZE, 4)
+#define CAPC_THUMB_SIZEI2C_REG(CAT_CAPT_CTRL, 
CATC_CAP_THUMB_SIZE, 4)
 
 /*
  * Category F - Flash
-- 
1.7.0.4

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

[PATCH 2/5] m5mols: add m5mols_read_u8/u16/u32() according to I2C byte width

For now, the m5mols_read() share in case of I2C packet 1, 2, 4 byte(2) width.
So, this commit adds 3 functions - m5mols_read_u8/u16/u32() according to byte
width of I2C packet. And, the u32 variables in spite of u8 or u16 for fitting
to m5mols_read() having no choice, is replaced to have original byte width
like u8, u16, u32 as same reason.

Signed-off-by: HeungJun, Kim riverful@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
 drivers/media/video/m5mols/m5mols.h  |   52 +++---
 drivers/media/video/m5mols/m5mols_capture.c  |   18 +++---
 drivers/media/video/m5mols/m5mols_controls.c |2 +-
 drivers/media/video/m5mols/m5mols_core.c |   96 ++
 4 files changed, 104 insertions(+), 64 deletions(-)

diff --git a/drivers/media/video/m5mols/m5mols.h 
b/drivers/media/video/m5mols/m5mols.h
index 10b55c8..dbe8928 100644
--- a/drivers/media/video/m5mols/m5mols.h
+++ b/drivers/media/video/m5mols/m5mols.h
@@ -106,23 +106,23 @@ struct m5mols_capture {
  * The each value according to each scenemode is recommended in the documents.
  */
 struct m5mols_scenemode {
-   u32 metering;
-   u32 ev_bias;
-   u32 wb_mode;
-   u32 wb_preset;
-   u32 chroma_en;
-   u32 chroma_lvl;
-   u32 edge_en;
-   u32 edge_lvl;
-   u32 af_range;
-   u32 fd_mode;
-   u32 mcc;
-   u32 light;
-   u32 flash;
-   u32 tone;
-   u32 iso;
-   u32 capt_mode;
-   u32 wdr;
+   u8 metering;
+   u8 ev_bias;
+   u8 wb_mode;
+   u8 wb_preset;
+   u8 chroma_en;
+   u8 chroma_lvl;
+   u8 edge_en;
+   u8 edge_lvl;
+   u8 af_range;
+   u8 fd_mode;
+   u8 mcc;
+   u8 light;
+   u8 flash;
+   u8 tone;
+   u8 iso;
+   u8 capt_mode;
+   u8 wdr;
 };
 
 /**
@@ -216,9 +216,9 @@ struct m5mols_info {
bool lock_ae;
bool lock_awb;
u8 resolution;
-   u32 interrupt;
-   u32 mode;
-   u32 mode_save;
+   u8 interrupt;
+   u8 mode;
+   u8 mode_save;
int (*set_power)(struct device *dev, int on);
 };
 
@@ -256,9 +256,11 @@ struct m5mols_info {
  *   +---+---+--+-+--+--+--+--+
  *   - d[0..3]: according to size1
  */
-int m5mols_read(struct v4l2_subdev *sd, u32 reg_comb, u32 *val);
+int m5mols_read_u8(struct v4l2_subdev *sd, u32 reg_comb, u8 *val);
+int m5mols_read_u16(struct v4l2_subdev *sd, u32 reg_comb, u16 *val);
+int m5mols_read_u32(struct v4l2_subdev *sd, u32 reg_comb, u32 *val);
 int m5mols_write(struct v4l2_subdev *sd, u32 reg_comb, u32 val);
-int m5mols_busy(struct v4l2_subdev *sd, u8 category, u8 cmd, u32 value);
+int m5mols_busy(struct v4l2_subdev *sd, u8 category, u8 cmd, u8 value);
 
 /*
  * Mode operation of the M-5MOLS
@@ -280,12 +282,12 @@ int m5mols_busy(struct v4l2_subdev *sd, u8 category, u8 
cmd, u32 value);
  * The available executing order between each modes are as follows:
  *   PARAMETER --- MONITOR --- CAPTURE
  */
-int m5mols_mode(struct m5mols_info *info, u32 mode);
+int m5mols_mode(struct m5mols_info *info, u8 mode);
 
-int m5mols_enable_interrupt(struct v4l2_subdev *sd, u32 reg);
+int m5mols_enable_interrupt(struct v4l2_subdev *sd, u8 reg);
 int m5mols_sync_controls(struct m5mols_info *info);
 int m5mols_start_capture(struct m5mols_info *info);
-int m5mols_do_scenemode(struct m5mols_info *info, u32 mode);
+int m5mols_do_scenemode(struct m5mols_info *info, u8 mode);
 int m5mols_lock_3a(struct m5mols_info *info, bool lock);
 int m5mols_set_ctrl(struct v4l2_ctrl *ctrl);
 
diff --git a/drivers/media/video/m5mols/m5mols_capture.c 
b/drivers/media/video/m5mols/m5mols_capture.c
index d71a390..751f459 100644
--- a/drivers/media/video/m5mols/m5mols_capture.c
+++ b/drivers/media/video/m5mols/m5mols_capture.c
@@ -58,9 +58,9 @@ static int m5mols_read_rational(struct v4l2_subdev *sd, u32 
addr_num,
 {
u32 num, den;
 
-   int ret = m5mols_read(sd, addr_num, num);
+   int ret = m5mols_read_u32(sd, addr_num, num);
if (!ret)
-   ret = m5mols_read(sd, addr_den, den);
+   ret = m5mols_read_u32(sd, addr_den, den);
if (ret)
return ret;
*val = den == 0 ? 0 : num / den;
@@ -99,20 +99,20 @@ static int m5mols_capture_info(struct m5mols_info *info)
if (ret)
return ret;
 
-   ret = m5mols_read(sd, EXIF_INFO_ISO, (u32 *)exif-iso_speed);
+   ret = m5mols_read_u16(sd, EXIF_INFO_ISO, exif-iso_speed);
if (!ret)
-   ret = m5mols_read(sd, EXIF_INFO_FLASH, (u32 *)exif-flash);
+   ret = m5mols_read_u16(sd, EXIF_INFO_FLASH, exif-flash);
if (!ret)
-   ret = m5mols_read(sd, EXIF_INFO_SDR, (u32 *)exif-sdr);
+   ret = m5mols_read_u16(sd, EXIF_INFO_SDR, exif-sdr);
if (!ret)
-   ret = m5mols_read(sd, EXIF_INFO_QVAL, (u32 *)exif-qval);
+   ret = m5mols_read_u16(sd, EXIF_INFO_QVAL, exif-qval);

[PATCH 3/5] m5mols: remove union in the m5mols_get_version(), and VERSION_SIZE

Remove union version in the m5mols_get_version(), and read version information
directly. Also remove VERSION_SIZE.

Signed-off-by: HeungJun, Kim riverful@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
 drivers/media/video/m5mols/m5mols.h  |1 -
 drivers/media/video/m5mols/m5mols_core.c |   42 +++---
 drivers/media/video/m5mols/m5mols_reg.h  |   13 -
 3 files changed, 33 insertions(+), 23 deletions(-)

diff --git a/drivers/media/video/m5mols/m5mols.h 
b/drivers/media/video/m5mols/m5mols.h
index dbe8928..9ae1709 100644
--- a/drivers/media/video/m5mols/m5mols.h
+++ b/drivers/media/video/m5mols/m5mols.h
@@ -154,7 +154,6 @@ struct m5mols_version {
u8  str[VERSION_STRING_SIZE];
u8  af;
 };
-#define VERSION_SIZE sizeof(struct m5mols_version)
 
 /**
  * struct m5mols_info - M-5MOLS driver data structure
diff --git a/drivers/media/video/m5mols/m5mols_core.c 
b/drivers/media/video/m5mols/m5mols_core.c
index 2b1f23f..8ccab95 100644
--- a/drivers/media/video/m5mols/m5mols_core.c
+++ b/drivers/media/video/m5mols/m5mols_core.c
@@ -386,33 +386,33 @@ int m5mols_mode(struct m5mols_info *info, u8 mode)
 static int m5mols_get_version(struct v4l2_subdev *sd)
 {
struct m5mols_info *info = to_m5mols(sd);
-   union {
-   struct m5mols_version ver;
-   u8 bytes[VERSION_SIZE];
-   } version;
-   u8 cmd = CAT0_VER_CUSTOMER;
+   struct m5mols_version *ver = info-ver;
+   u8 *str = ver-str;
+   int i;
int ret;
 
-   do {
-   ret = m5mols_read_u8(sd, SYSTEM_CMD(cmd), version.bytes[cmd]);
-   if (ret)
-   return ret;
-   } while (cmd++ != CAT0_VER_AWB);
+   ret = m5mols_read_u8(sd, SYSTEM_VER_CUSTOMER, ver-customer);
+   if (!ret)
+   ret = m5mols_read_u8(sd, SYSTEM_VER_PROJECT, ver-project);
+   if (!ret)
+   ret = m5mols_read_u16(sd, SYSTEM_VER_FIRMWARE, ver-fw);
+   if (!ret)
+   ret = m5mols_read_u16(sd, SYSTEM_VER_HARDWARE, ver-hw);
+   if (!ret)
+   ret = m5mols_read_u16(sd, SYSTEM_VER_PARAMETER, ver-param);
+   if (!ret)
+   ret = m5mols_read_u16(sd, SYSTEM_VER_AWB, ver-awb);
+   if (!ret)
+   ret = m5mols_read_u8(sd, AF_VERSION, ver-af);
+   if (ret)
+   return ret;
 
-   do {
-   ret = m5mols_read_u8(sd, SYSTEM_VER_STRING, 
version.bytes[cmd]);
+   for (i = 0; i  VERSION_STRING_SIZE; i++) {
+   ret = m5mols_read_u8(sd, SYSTEM_VER_STRING, str[i]);
if (ret)
return ret;
-   if (cmd = VERSION_SIZE - 1)
-   return -EINVAL;
-   } while (version.bytes[cmd++]);
-
-   ret = m5mols_read_u8(sd, AF_VERSION, version.bytes[cmd]);
-   if (ret)
-   return ret;
+   }
 
-   /* store version information swapped for being readable */
-   info-ver   = version.ver;
info-ver.fw= be16_to_cpu(info-ver.fw);
info-ver.hw= be16_to_cpu(info-ver.hw);
info-ver.param = be16_to_cpu(info-ver.param);
diff --git a/drivers/media/video/m5mols/m5mols_reg.h 
b/drivers/media/video/m5mols/m5mols_reg.h
index 8260f50..5f5bdcf 100644
--- a/drivers/media/video/m5mols/m5mols_reg.h
+++ b/drivers/media/video/m5mols/m5mols_reg.h
@@ -56,13 +56,24 @@
  * more specific contents, see definition if file m5mols.h.
  */
 #define CAT0_VER_CUSTOMER  0x00/* customer version */
-#define CAT0_VER_AWB   0x09/* Auto WB version */
+#define CAT0_VER_PROJECT   0x01/* project version */
+#define CAT0_VER_FIRMWARE  0x02/* Firmware version */
+#define CAT0_VER_HARDWARE  0x04/* Hardware version */
+#define CAT0_VER_PARAMETER 0x06/* Parameter version */
+#define CAT0_VER_AWB   0x08/* Auto WB version */
 #define CAT0_VER_STRING0x0a/* string including M-5MOLS */
 #define CAT0_SYSMODE   0x0b/* SYSTEM mode register */
 #define CAT0_STATUS0x0c/* SYSTEM mode status register */
 #define CAT0_INT_FACTOR0x10/* interrupt pending register */
 #define CAT0_INT_ENABLE0x11/* interrupt enable register */
 
+#define SYSTEM_VER_CUSTOMERI2C_REG(CAT_SYSTEM, CAT0_VER_CUSTOMER, 1)
+#define SYSTEM_VER_PROJECT I2C_REG(CAT_SYSTEM, CAT0_VER_PROJECT, 1)
+#define SYSTEM_VER_FIRMWAREI2C_REG(CAT_SYSTEM, CAT0_VER_FIRMWARE, 2)
+#define SYSTEM_VER_HARDWAREI2C_REG(CAT_SYSTEM, CAT0_VER_HARDWARE, 2)
+#define SYSTEM_VER_PARAMETER   I2C_REG(CAT_SYSTEM, CAT0_VER_PARAMETER, 2)
+#define SYSTEM_VER_AWB I2C_REG(CAT_SYSTEM, CAT0_VER_AWB, 2)
+
 #define SYSTEM_SYSMODE I2C_REG(CAT_SYSTEM, CAT0_SYSMODE, 1)
 #define REG_SYSINIT0x00/* SYSTEM mode */
 #define REG_PARAMETER  0x01/* PARAMETER mode */
-- 
1.7.0.4

--
To unsubscribe from this list: send

[PATCH 4/5] m5mols: rename m5mols_capture_error_handler() to proper name

The m5mols_capture_post_work() is collecting works after capture. The order 
should
be kept, and it's safe to say success of capture when all this conditions are 
fine.

Signed-off-by: HeungJun, Kim riverful@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
 drivers/media/video/m5mols/m5mols_capture.c |   17 -
 1 files changed, 12 insertions(+), 5 deletions(-)

diff --git a/drivers/media/video/m5mols/m5mols_capture.c 
b/drivers/media/video/m5mols/m5mols_capture.c
index 751f459..8436105 100644
--- a/drivers/media/video/m5mols/m5mols_capture.c
+++ b/drivers/media/video/m5mols/m5mols_capture.c
@@ -31,22 +31,29 @@
 #include m5mols.h
 #include m5mols_reg.h
 
-static int m5mols_capture_error_handler(struct m5mols_info *info,
-   int timeout)
+/**
+ * m5mols_capture_post_work - Handle post work after capture interrupt occur
+ *
+ * Return 0 if all condition associated with capture is fine.
+ */
+static int m5mols_capture_post_work(struct m5mols_info *info, int timeout)
 {
int ret;
 
-   /* Disable all interrupts and clear relevant interrupt staus bits */
+   /* First, disable capture interrupt */
ret = m5mols_write(info-sd, SYSTEM_INT_ENABLE,
   info-interrupt  ~(REG_INT_CAPTURE));
if (ret)
return ret;
 
+   /* Then, if timeout is exhasted, return ETIMEDOUT */
if (timeout == 0)
return -ETIMEDOUT;
 
+   /* All condition is satisfied, return 0 */
return 0;
 }
+
 /**
  * m5mols_read_rational - I2C read of a rational number
  *
@@ -150,7 +157,7 @@ int m5mols_start_capture(struct m5mols_info *info)
   test_bit(ST_CAPT_IRQ, info-flags),
   msecs_to_jiffies(2000));
if (test_and_clear_bit(ST_CAPT_IRQ, info-flags))
-   ret = m5mols_capture_error_handler(info, timeout);
+   ret = m5mols_capture_post_work(info, timeout);
}
if (!ret)
ret = m5mols_lock_3a(info, false);
@@ -187,5 +194,5 @@ int m5mols_start_capture(struct m5mols_info *info)
}
}
 
-   return m5mols_capture_error_handler(info, timeout);
+   return m5mols_capture_post_work(info, timeout);
 }
-- 
1.7.0.4

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

[PATCH 5/5] m5mols: add parenthesis for the head and back of email address

Signed-off-by: HeungJun, Kim riverful@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
 drivers/media/video/m5mols/m5mols.h  |4 ++--
 drivers/media/video/m5mols/m5mols_capture.c  |4 ++--
 drivers/media/video/m5mols/m5mols_controls.c |4 ++--
 drivers/media/video/m5mols/m5mols_core.c |4 ++--
 drivers/media/video/m5mols/m5mols_reg.h  |4 ++--
 include/media/m5mols.h   |4 ++--
 6 files changed, 12 insertions(+), 12 deletions(-)

diff --git a/drivers/media/video/m5mols/m5mols.h 
b/drivers/media/video/m5mols/m5mols.h
index 9ae1709..89d09a8 100644
--- a/drivers/media/video/m5mols/m5mols.h
+++ b/drivers/media/video/m5mols/m5mols.h
@@ -2,10 +2,10 @@
  * Header for M-5MOLS 8M Pixel camera sensor with ISP
  *
  * Copyright (C) 2011 Samsung Electronics Co., Ltd.
- * Author: HeungJun Kim, riverful@samsung.com
+ * Author: HeungJun Kim riverful@samsung.com
  *
  * Copyright (C) 2009 Samsung Electronics Co., Ltd.
- * Author: Dongsoo Nathaniel Kim, dongsoo45@samsung.com
+ * Author: Dongsoo Nathaniel Kim dongsoo45@samsung.com
  *
  * This program is free software; you can redistribute it and/or modify
  * it under the terms of the GNU General Public License as published by
diff --git a/drivers/media/video/m5mols/m5mols_capture.c 
b/drivers/media/video/m5mols/m5mols_capture.c
index 8436105..d91a67e 100644
--- a/drivers/media/video/m5mols/m5mols_capture.c
+++ b/drivers/media/video/m5mols/m5mols_capture.c
@@ -2,10 +2,10 @@
  * The Capture code for Fujitsu M-5MOLS ISP
  *
  * Copyright (C) 2011 Samsung Electronics Co., Ltd.
- * Author: HeungJun Kim, riverful@samsung.com
+ * Author: HeungJun Kim riverful@samsung.com
  *
  * Copyright (C) 2009 Samsung Electronics Co., Ltd.
- * Author: Dongsoo Nathaniel Kim, dongsoo45@samsung.com
+ * Author: Dongsoo Nathaniel Kim dongsoo45@samsung.com
  *
  * This program is free software; you can redistribute it and/or modify
  * it under the terms of the GNU General Public License as published by
diff --git a/drivers/media/video/m5mols/m5mols_controls.c 
b/drivers/media/video/m5mols/m5mols_controls.c
index d392c83..d135d20 100644
--- a/drivers/media/video/m5mols/m5mols_controls.c
+++ b/drivers/media/video/m5mols/m5mols_controls.c
@@ -2,10 +2,10 @@
  * Controls for M-5MOLS 8M Pixel camera sensor with ISP
  *
  * Copyright (C) 2011 Samsung Electronics Co., Ltd.
- * Author: HeungJun Kim, riverful@samsung.com
+ * Author: HeungJun Kim riverful@samsung.com
  *
  * Copyright (C) 2009 Samsung Electronics Co., Ltd.
- * Author: Dongsoo Nathaniel Kim, dongsoo45@samsung.com
+ * Author: Dongsoo Nathaniel Kim dongsoo45@samsung.com
  *
  * This program is free software; you can redistribute it and/or modify
  * it under the terms of the GNU General Public License as published by
diff --git a/drivers/media/video/m5mols/m5mols_core.c 
b/drivers/media/video/m5mols/m5mols_core.c
index 8ccab95..e2c8a10 100644
--- a/drivers/media/video/m5mols/m5mols_core.c
+++ b/drivers/media/video/m5mols/m5mols_core.c
@@ -2,10 +2,10 @@
  * Driver for M-5MOLS 8M Pixel camera sensor with ISP
  *
  * Copyright (C) 2011 Samsung Electronics Co., Ltd.
- * Author: HeungJun Kim, riverful@samsung.com
+ * Author: HeungJun Kim riverful@samsung.com
  *
  * Copyright (C) 2009 Samsung Electronics Co., Ltd.
- * Author: Dongsoo Nathaniel Kim, dongsoo45@samsung.com
+ * Author: Dongsoo Nathaniel Kim dongsoo45@samsung.com
  *
  * This program is free software; you can redistribute it and/or modify
  * it under the terms of the GNU General Public License as published by
diff --git a/drivers/media/video/m5mols/m5mols_reg.h 
b/drivers/media/video/m5mols/m5mols_reg.h
index 5f5bdcf..c755bd6 100644
--- a/drivers/media/video/m5mols/m5mols_reg.h
+++ b/drivers/media/video/m5mols/m5mols_reg.h
@@ -2,10 +2,10 @@
  * Register map for M-5MOLS 8M Pixel camera sensor with ISP
  *
  * Copyright (C) 2011 Samsung Electronics Co., Ltd.
- * Author: HeungJun Kim, riverful@samsung.com
+ * Author: HeungJun Kim riverful@samsung.com
  *
  * Copyright (C) 2009 Samsung Electronics Co., Ltd.
- * Author: Dongsoo Nathaniel Kim, dongsoo45@samsung.com
+ * Author: Dongsoo Nathaniel Kim dongsoo45@samsung.com
  *
  * This program is free software; you can redistribute it and/or modify
  * it under the terms of the GNU General Public License as published by
diff --git a/include/media/m5mols.h b/include/media/m5mols.h
index 2d7e7ca..aac2c0e 100644
--- a/include/media/m5mols.h
+++ b/include/media/m5mols.h
@@ -2,10 +2,10 @@
  * Driver header for M-5MOLS 8M Pixel camera sensor with ISP
  *
  * Copyright (C) 2011 Samsung Electronics Co., Ltd.
- * Author: HeungJun Kim, riverful@samsung.com
+ * Author: HeungJun Kim riverful@samsung.com
  *
  * Copyright (C) 2009 Samsung Electronics Co., Ltd.
- * Author: Dongsoo Nathaniel Kim, dongsoo45@samsung.com
+ * Author: Dongsoo Nathaniel Kim dongsoo45@samsung.com
  *
  * This

Re: [PATCH v2] [media] at91: add Atmel Image Sensor Interface (ISI) support

2011-05-27 Thread Arnd Bergmann

On Friday 27 May 2011, Josh Wu wrote:
 This patch is to enable Atmel Image Sensor Interface (ISI) driver support.
 - Using soc-camera framework with videobuf2 dma-contig allocator
 - Supporting video streaming of YUV packed format
 - Tested on AT91SAM9M10G45-EK with OV2640
 
 Signed-off-by: Josh Wu josh...@atmel.com

Looks good to me now.

Acked-by: Arnd Bergmann a...@arndb.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

[GIT PULL for -rc1] media updates

2011-05-27 Thread Mauro Carvalho Chehab

Hi Linus,

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

For a few more stuff for 3.0-rc1 (or 2.6.40-rc1).

This series contain a few bug fixes, and some stuff that were ready for the
merge window, but they took me some time to finish my review. Basically:
- an 8-megapixel sensor driver, used on some Samsung arm-based boards;
- a Remote Controller driver for a SuperIO chipset from Fintek;
- Media controller support for uvcvideo driver;
- DM04/QQBOX port to use the RC subsystem, instead of having its own 
implementation for IR.

Thanks!
Mauro


The following changes since commit cf25220677b3f10468a74278130fe224f73632a6:

  [media] gspca - sunplus: Fix some warnings and simplify code (2011-05-21 
09:36:15 -0300)

are available in the git repository at:
  ssh://master.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-2.6.git 
v4l_for_linus

Hans Petter Selasky (4):
  [media] cpia2: fix warning about invalid trigraph sequence
  [media] Remove invalid parameter description
  [media] Inlined functions should be static
  [media] Add missing include guard to header file

Hans Verkuil (2):
  [media] wl12xx: g_volatile_ctrl fix: wrong field set
  [media] Media DocBook: fix validation errors

HeungJun, Kim (1):
  [media] Add support for M-5MOLS 8 Mega Pixel camera ISP

Igor M. Liplianin (1):
  [media] dm1105: GPIO handling added, I2C on GPIO added, LNB control 
through GPIO reworked

Jarod Wilson (2):
  [media] fintek-cir: new driver for Fintek LPC SuperIO CIR function
  [media] gspca/kinect: wrap gspca_debug with GSPCA_DEBUG

Laurent Pinchart (3):
  [media] uvcvideo: Register a v4l2_device
  [media] uvcvideo: Register subdevices for each entity
  [media] uvcvideo: Connect video devices to media entities

Malcolm Priestley (1):
  [media] v1.88 DM04/QQBOX Move remote to use rc_core dvb-usb-remote

Mauro Carvalho Chehab (2):
  [media] Documentation/DocBook: Rename media fops xml files
  [media] add V4L2-PIX-FMT-SRGGB12  friends to docbook

Randy Dunlap (1):
  [media] fix kconfig dependency warning for VIDEO_TIMBERDALE

Sylwester Nawrocki (1):
  [media] s5p-csis: Add missing dependency on PLAT_S5P

 Documentation/DocBook/dvb/dvbproperty.xml  |5 +-
 Documentation/DocBook/media-entities.tmpl  |7 +-
 Documentation/DocBook/v4l/media-controller.xml |6 +-
 Documentation/DocBook/v4l/pixfmt.xml   |1 +
 Documentation/DocBook/v4l/subdev-formats.xml   |   10 +-
 drivers/media/dvb/dm1105/dm1105.c  |  272 ++-
 drivers/media/dvb/dvb-usb/lmedm04.c|  107 +--
 drivers/media/dvb/frontends/stb0899_algo.c |2 +-
 drivers/media/dvb/frontends/tda8261.c  |1 -
 drivers/media/radio/radio-wl1273.c |2 +-
 drivers/media/radio/wl128x/fmdrv_v4l2.c|2 +-
 drivers/media/rc/Kconfig   |   12 +
 drivers/media/rc/Makefile  |1 +
 drivers/media/rc/fintek-cir.c  |  684 
 drivers/media/rc/fintek-cir.h  |  243 ++
 drivers/media/rc/keymaps/rc-lme2510.c  |  134 ++--
 drivers/media/video/Kconfig|6 +-
 drivers/media/video/Makefile   |1 +
 drivers/media/video/cpia2/cpia2_v4l.c  |4 +-
 drivers/media/video/gspca/kinect.c |2 +-
 drivers/media/video/m5mols/Kconfig |5 +
 drivers/media/video/m5mols/Makefile|3 +
 drivers/media/video/m5mols/m5mols.h|  296 +++
 drivers/media/video/m5mols/m5mols_capture.c|  191 +
 drivers/media/video/m5mols/m5mols_controls.c   |  299 +++
 drivers/media/video/m5mols/m5mols_core.c   | 1004 
 drivers/media/video/m5mols/m5mols_reg.h|  399 ++
 drivers/media/video/uvc/Makefile   |3 +
 drivers/media/video/uvc/uvc_driver.c   |   66 ++-
 drivers/media/video/uvc/uvc_entity.c   |  118 +++
 drivers/media/video/uvc/uvcvideo.h |   20 +
 include/media/m5mols.h |   35 +
 include/media/videobuf-dvb.h   |4 +
 33 files changed, 3750 insertions(+), 195 deletions(-)
 create mode 100644 drivers/media/rc/fintek-cir.c
 create mode 100644 drivers/media/rc/fintek-cir.h
 create mode 100644 drivers/media/video/m5mols/Kconfig
 create mode 100644 drivers/media/video/m5mols/Makefile
 create mode 100644 drivers/media/video/m5mols/m5mols.h
 create mode 100644 drivers/media/video/m5mols/m5mols_capture.c
 create mode 100644 drivers/media/video/m5mols/m5mols_controls.c
 create mode 100644 drivers/media/video/m5mols/m5mols_core.c
 create mode 100644 drivers/media/video/m5mols/m5mols_reg.h
 create mode 100644 drivers/media/video/uvc/uvc_entity.c
 create mode 100644 include/media/m5mols.h

--
To unsubscribe from this list: send the line unsubscribe

Re: [beagleboard] [PATCH] Second RFC version of mt9p031 sensor with power managament.

2011-05-27 Thread Laurent Pinchart

Hi Javier,

On Thursday 26 May 2011 13:31:37 javier Martin wrote:
 OK, I think I've found the problem with the power management.
 
 As it is stated in mt9p031 datasheet [3] p 59, a sequence involving
 [VAA,VAA_PIX,VDD_PLL], [VDD,VDD_IO], [Reset] and [Ext Clk] must be
 followed in order to properly power up or down the sensor.
 
 If we take a look to the LI-5M031 schematic[1] and Beagleboard xM
 schematic [2] we'll notice that voltages are connected as follows:
 
 [VDD] (1,8V) --- V2.8 --- CAM_CORE --- VAUX3 TPS65950
 [VDD_IO (VDDQ)] (1,8V) --- V1.8 --- CAM_IO --- VAUX4 TPS65950
 [VAA, VAA_PIX, VDD_PLL] (2,8V) ---| U6 |-- V3.3VD -- HUB_3V3 --|
 U16 | enabled by USBHOST_PWR_EN -- LEDA TPS65950
 
 VAUX3 (VDD) and VAUX4 (VDD_IO) are fine, they are only used for
 powering our camera sensor. However, when it comes to the analog part
 (VAA, VAA_PIX...), it is got from HUB_3V3 which is also used for
 powering USB and ethernet.

*sigh* Why do hardware designers do things like that, really ?

 If we really want to activate/deactivate regulators that power mt9p031
 we need to follow [3] p59. However, for that purpose we need to ensure
 that a call to regulator_enable() or regulator_disable() will really
 power on/off that supply, otherwise the sequence won't be matched and
 the chip will have problems.
 
 Beagleboard xM is a good example of platform where this happens since
 HUB_3V3 and thus (VAA, VAA_PIX, etc...) cannot be deactivated since it
 is being used by other devices. But there could be others.
 
 So, as a conclusion, and in order to unblock my work, my purpose for
 power management in mt9p031 would be the following:
 - Drop regulator handling as we cannot guarantee that power on
 sequence will be accomplished.
 - Keep on asserting/de-asserting reset which saves a lot of power.
 - Also activate/deactivate clock when necessary to save some power.
 
 I'm looking forward to read your comments on this.

Even if you keep the sensor powered all the time, how do you ensure that VAUX3 
is available before HUB_3V3 when the system is powered up ?

 [1] https://www.leopardimaging.com/uploads/li-5m03_camera_board_v2.pdf
 [2] http://beagle.s3.amazonaws.com/design/xM-A3/BB-xM_Schematic_REVA3.pdf
 [3] http://www.aptina.com/products/image_sensors/mt9p031i12stc/

-- 
Regards,

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

Re: SV: omap3isp - H3A auto white balance

2011-05-27 Thread Laurent Pinchart

Hi Daniel,

On Thursday 26 May 2011 15:06:17 Daniel Lundborg wrote:
  On Thursday 26 May 2011 10:57:39 Daniel Lundborg wrote:
   Hello,
   
   I am developing a camera sensor driver for the Aptina MT9V034. I am only
   using it in snapshot mode and I can successfully trigger the sensor and
   receive pictures using the latest omap3isp driver from
   git://linuxtv.org/pinchartl/media.git branch omap3isp-next-sensors with
   kernel 2.6.38.
   
   I configure the sensor with media-ctl:
   
   media-ctl -r -l 'mt9v034 3-0048:0-OMAP3 ISP CCDC:0[1], OMAP3 ISP
   CCDC:1-OMAP3 ISP CCDC output:0[1]'
   
   media-ctl -f 'mt9v034 3-0048:0[SGRBG10 752x480], OMAP3 ISP
   CCDC:1[SGRBG10 752x480]'
   
   And take pictures with yavta:
   
   ./yavta -f SGRBG10 -s 752x480 -n 6 --capture=6 -F /dev/video2
   
   My trouble is that I am always receiving whiter pictures when I wait a
   moment before triggering the sensor to take a picture. If I take several
   pictures in a row with for instance 20 ms between them, they all look
   ok. But if I wait for 100 ms the picture will get much whiter.
   
   I have turned off auto exposure and auto gain in the sensor and the
   LED_OUT signal always have the same length (in this case 8 msec).
  
  I assume you've measured it with a scope ?
  
  Try disabling black level calibration and row noise correction as well.
  Please also double-check that AEC and AGC are disabled. I've had a similar
  issue with an MT9V032 sensor, where a bug in the driver enabled AEC/AGC
  instead of disabling them.
 
 The register on 0xaf (MT9V034_AGC_AEC_ENABLE) is set to 0 and is 0 when
 I read from it.
 bit 0 - AEC enable context A, bit 1 - AGC enable context A, bit 8 - AEC
 enable context B, bit 9 - AGC enable context B
 
 The register on 0x47 (MT9V034_BL_CALIB_CTRL) is set to 0 and is 0 when I
 read from it.
 bit 0 - (1 = override with programmed values, 0 = normal operation), bit
 7:5 - Frames to average over

If I'm not mistaken normal operation means that automatic black level 
calibration is enabled. Try to set bit 0 to 1 to override the automatic 
algorithm (and program a zero value in register 0x48).

 The register on 0x70 (MT9V034_ROW_NOISE_CORR_CONTROL) is set to 0 and is
 0 when I read from it.
 bit 0 - enable noise correction context A , bit 1 - Use black level avg
 context A, bit 8 - enable noise correction context B, bit 9 - Use black
 level avg context B
 
 I measure the signals with a scope and the LED_OUT signal is always 8
 msec when triggered.
 
 Code from my mt9v034.c:

[snip]

 And from my board-overo.c file:
 
 void overo_camera_configure(struct v4l2_subdev *subdev)
 {
   struct isp_device *isp =
 v4l2_dev_to_isp_device(subdev-v4l2_dev);
 
   isp_reg_clr_set(isp, OMAP3_ISP_IOMEM_MAIN, ISP_TCTRL_CTRL,
 ~0x9a1b63ff, 0x98036000); // Set CAM_GLOBAL_RESET pin as output, enable
 shutter, set DIVC = 216
   isp_reg_clr(isp, OMAP3_ISP_IOMEM_MAIN, ISP_TCTRL_SHUT_DELAY,
 0x01ff);  // Set no shutter delay
   isp_reg_clr_set(isp, OMAP3_ISP_IOMEM_MAIN, ISP_TCTRL_SHUT_LENGTH,
 0x01ff, 0x03e8); // Set shutter signal length to 1000 (= 1000 *
 1/216MHz * 216 = 1 ms)
   isp_reg_clr_set(isp, OMAP3_ISP_IOMEM_MAIN, ISP_TCTRL_GRESET_LENGTH,
 0x01ff, 0x03e8); // Set CAM_GLOBAL_RESET signal length to 1000
 (= 1000 * 1/216MHz * 216 = 1 ms)
 }
 
 static void overo_camera_take_picture(struct v4l2_subdev *subdev)
 {
   struct isp_device *isp =
 v4l2_dev_to_isp_device(subdev-v4l2_dev);
 
   isp_reg_clr_set(isp, OMAP3_ISP_IOMEM_MAIN, ISP_TCTRL_CTRL, 0,
 0x00e0);  // Enable shutter (SHUTEN bit = 1)
   isp_reg_clr_set(isp, OMAP3_ISP_IOMEM_MAIN, ISP_TCTRL_CTRL, 0,
 0x2000);  // Start generation of CAM_GLOBAL_RESET signal (GRESETEN
 bit = 1)
 }

I'll have to implement support for that in the OMAP3 ISP driver at some point.

[snip]

  Do you have a light source connected to the LED_OUT signal ? If so, can
  you try disabling it and using a constant light source ?
 
 No I'm not using the LED_OUT signal other than measuring the exposure time
 at this point.
 
   Why would the pictures become whiter if I wait a moment before taking a
   picture?
   
   If I set the sensor in streaming mode all pictures look like they
   should.
   
   Could there be something with the H3A auto white balance or auto
   exposure?
 
  The OMAP3 ISP isn't able to apply any H3A algorithm to the images by
  itself. The H3A hardware support only computes statistics, and a userspace
  application then needs to compute parameters (such as exposure time and
  gains) based on the statistics, and apply them to the hardware. As yavta
  doesn't include H3A algorithms, the differences in picture brightness can
  only come from the sensor.

-- 
Regards,

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

[PATCH] V4L: soc-camera: fix compiler warning

2011-05-27 Thread Guennadi Liakhovetski

Fix a compiler warning, introduced by the commit aed65af1

Author: Stephen Hemminger shemmin...@vyatta.com
drivers: make device_type const

Signed-off-by: Guennadi Liakhovetski g.liakhovet...@gmx.de
---
 drivers/media/video/soc_camera.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/drivers/media/video/soc_camera.c b/drivers/media/video/soc_camera.c
index 3988643..4e4d412 100644
--- a/drivers/media/video/soc_camera.c
+++ b/drivers/media/video/soc_camera.c
@@ -1512,7 +1512,7 @@ static int video_dev_create(struct soc_camera_device *icd)
  */
 static int soc_camera_video_start(struct soc_camera_device *icd)
 {
-   struct device_type *type = icd-vdev-dev.type;
+   const struct device_type *type = icd-vdev-dev.type;
int ret;
 
if (!icd-dev.parent)
-- 
1.7.2.5

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

[RFCv1 PATCH 0/5] Add autofoo/foo support to the control framework

This patch series sits on top of the Control Event patch series I posted on
Wednesday.

It adds core support for the common autofoo/foo controls (e.g. autogain/gain,
autoexposure/exposure, etc.).

See the commit comments of patches 1 and 3 and the documentation changes
in patch 4 for detailed information on the behavior.

The vivi driver has been adapted to test this new feature.

The full code is available here:

http://git.linuxtv.org/hverkuil/media_tree.git?a=shortlog;h=refs/heads/core5

Comments are welcome!

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

[RFCv1 PATCH 1/5] v4l2-ctrls: fix and improve volatile control handling.

From: Hans Verkuil hans.verk...@cisco.com

If you have a cluster of controls that is a mix of volatile and non-volatile
controls, then requesting the value of the volatile control would fail if the
master control of that cluster was non-volatile. The code assumed that the
volatile state of the master control was the same for all other controls in
the cluster.

This is now fixed.

In addition, it was clear from bugs in some drivers that it was confusing that
the ctrl-cur union had to be used in g_volatile_ctrl. Several drivers used the
'new' values instead. The framework was changed so that drivers now set the new
value instead of the current value.

This has an additional benefit as well: the volatile values are now only stored
in the 'new' value, leaving the current value alone. This is useful for
autofoo/foo control clusters where you want to have a 'foo' control act like a
volatile control if 'autofoo' is on, but as a normal control when it is off.

Since with this change the cur value is no longer overwritten when 
g_volatile_ctrl
is called, you can use it to remember the original 'foo' value. For example:

autofoo = 0, foo = 10 and foo is non-volatile.

Now autofoo is set to 1 and foo is marked volatile. Retrieving the foo value
will get the volatile value. Set autofoo back to 0, which marks foo as non-
volatile again, and retrieving foo will get the old current value of 10.

Signed-off-by: Hans Verkuil hans.verk...@cisco.com
---
 drivers/media/video/saa7115.c|4 +-
 drivers/media/video/v4l2-ctrls.c |   52 --
 2 files changed, 46 insertions(+), 10 deletions(-)

diff --git a/drivers/media/video/saa7115.c b/drivers/media/video/saa7115.c
index ae4b299..dc8710d 100644
--- a/drivers/media/video/saa7115.c
+++ b/drivers/media/video/saa7115.c
@@ -757,8 +757,8 @@ static int saa711x_g_volatile_ctrl(struct v4l2_ctrl *ctrl)
switch (ctrl-id) {
case V4L2_CID_CHROMA_AGC:
/* chroma gain cluster */
-   if (state-agc-cur.val)
-   state-gain-cur.val =
+   if (state-agc-val)
+   state-gain-val =
saa711x_read(sd, R_0F_CHROMA_GAIN_CNTL)  0x7f;
break;
}
diff --git a/drivers/media/video/v4l2-ctrls.c b/drivers/media/video/v4l2-ctrls.c
index 9807a20..7fc6d3f 100644
--- a/drivers/media/video/v4l2-ctrls.c
+++ b/drivers/media/video/v4l2-ctrls.c
@@ -26,8 +26,10 @@
 #include media/v4l2-event.h
 #include media/v4l2-dev.h
 
+#define has_op(master, op) \
+   (master-ops  master-ops-op)
 #define call_op(master, op) \
-   ((master-ops  master-ops-op) ? master-ops-op(master) : 0)
+   (has_op(master, op) ? master-ops-op(master) : 0)
 
 /* Internal temporary helper struct, one for each v4l2_ext_control */
 struct ctrl_helper {
@@ -665,6 +667,20 @@ static int new_to_user(struct v4l2_ext_control *c,
return 0;
 }
 
+static int ctrl_to_user(struct v4l2_ext_control *c,
+  struct v4l2_ctrl *ctrl)
+{
+   if (ctrl-is_volatile)
+   return new_to_user(c, ctrl);
+   return cur_to_user(c, ctrl);
+}
+
+static int ctrl_is_volatile(struct v4l2_ext_control *c,
+  struct v4l2_ctrl *ctrl)
+{
+   return ctrl-is_volatile;
+}
+
 /* Copy the new value to the current value. */
 static void new_to_cur(struct v4l2_fh *fh, struct v4l2_ctrl *ctrl)
 {
@@ -1614,7 +1630,7 @@ int v4l2_g_ext_ctrls(struct v4l2_ctrl_handler *hdl, 
struct v4l2_ext_controls *cs
struct ctrl_helper helper[4];
struct ctrl_helper *helpers = helper;
int ret;
-   int i;
+   int i, j;
 
cs-error_idx = cs-count;
cs-ctrl_class = V4L2_CTRL_ID2CLASS(cs-ctrl_class);
@@ -1640,6 +1656,7 @@ int v4l2_g_ext_ctrls(struct v4l2_ctrl_handler *hdl, 
struct v4l2_ext_controls *cs
for (i = 0; !ret  i  cs-count; i++) {
struct v4l2_ctrl *ctrl = helpers[i].ctrl;
struct v4l2_ctrl *master = ctrl-cluster[0];
+   bool has_volatiles;
 
if (helpers[i].handled)
continue;
@@ -1647,12 +1664,25 @@ int v4l2_g_ext_ctrls(struct v4l2_ctrl_handler *hdl, 
struct v4l2_ext_controls *cs
cs-error_idx = i;
 
v4l2_ctrl_lock(master);
-   /* g_volatile_ctrl will update the current control values */
-   if (ctrl-is_volatile)
+
+   /* Any volatile controls requested from this cluster? */
+   has_volatiles = ctrl-is_volatile;
+   if (!has_volatiles  has_op(master, g_volatile_ctrl) 
+   master-ncontrols  1)
+   has_volatiles = cluster_walk(i + 1, cs, helpers,
+   ctrl_is_volatile);
+
+   /* g_volatile_ctrl will update the new control values */
+   if (has_volatiles) {
+   for (j = 0; j  master-ncontrols; j++)
+

[RFCv1 PATCH 5/5] vivi: add autogain/gain support to test the autofoo/foo code.

From: Hans Verkuil hans.verk...@cisco.com

Signed-off-by: Hans Verkuil hans.verk...@cisco.com
---
 drivers/media/video/vivi.c |   51 +--
 1 files changed, 34 insertions(+), 17 deletions(-)

diff --git a/drivers/media/video/vivi.c b/drivers/media/video/vivi.c
index 5184e55..d056fb0 100644
--- a/drivers/media/video/vivi.c
+++ b/drivers/media/video/vivi.c
@@ -217,6 +217,12 @@ struct vivi_dev {
 
/* controls */
struct v4l2_ctrl   *volume;
+   struct v4l2_ctrl   *brightness;
+   struct v4l2_ctrl   *contrast;
+   struct v4l2_ctrl   *sat;
+   struct v4l2_ctrl   *hue;
+   struct v4l2_ctrl   *autogain;
+   struct v4l2_ctrl   *gain;
struct v4l2_ctrl   *button;
struct v4l2_ctrl   *boolean;
struct v4l2_ctrl   *int32;
@@ -448,14 +454,6 @@ static void gen_text(struct vivi_dev *dev, char *basep,
 
 static void vivi_fillbuff(struct vivi_dev *dev, struct vivi_buffer *buf)
 {
-   struct v4l2_ctrl *brightness = v4l2_ctrl_find(dev-ctrl_handler,
-   V4L2_CID_BRIGHTNESS);
-   struct v4l2_ctrl *contrast = v4l2_ctrl_find(dev-ctrl_handler,
-   V4L2_CID_CONTRAST);
-   struct v4l2_ctrl *saturation = v4l2_ctrl_find(dev-ctrl_handler,
-   V4L2_CID_SATURATION);
-   struct v4l2_ctrl *hue = v4l2_ctrl_find(dev-ctrl_handler,
-   V4L2_CID_HUE);
int wmax = dev-width;
int hmax = dev-height;
struct timeval ts;
@@ -463,6 +461,7 @@ static void vivi_fillbuff(struct vivi_dev *dev, struct 
vivi_buffer *buf)
unsigned ms;
char str[100];
int h, line = 1;
+   s32 gain;
 
if (!vbuf)
return;
@@ -485,14 +484,17 @@ static void vivi_fillbuff(struct vivi_dev *dev, struct 
vivi_buffer *buf)
dev-width, dev-height, dev-input);
gen_text(dev, vbuf, line++ * 16, 16, str);
 
+   gain = v4l2_ctrl_g_ctrl(dev-gain);
mutex_lock(dev-ctrl_handler.lock);
snprintf(str, sizeof(str),  brightness %3d, contrast %3d, saturation 
%3d, hue %d ,
-   brightness-cur.val,
-   contrast-cur.val,
-   saturation-cur.val,
-   hue-cur.val);
+   dev-brightness-cur.val,
+   dev-contrast-cur.val,
+   dev-sat-cur.val,
+   dev-hue-cur.val);
gen_text(dev, vbuf, line++ * 16, 16, str);
-   snprintf(str, sizeof(str),  volume %3d , dev-volume-cur.val);
+   snprintf(str, sizeof(str),  volume %3d, autogain %d, gain %3d ,
+   dev-volume-cur.val, dev-autogain-cur.val,
+   gain);
gen_text(dev, vbuf, line++ * 16, 16, str);
snprintf(str, sizeof(str),  int32 %d, int64 %lld, bitmask %08x ,
dev-int32-cur.val,
@@ -1005,6 +1007,15 @@ static int vidioc_subscribe_event(struct v4l2_fh *fh,
 
 /* --- controls -- */
 
+static int vivi_g_volatile_ctrl(struct v4l2_ctrl *ctrl)
+{
+   struct vivi_dev *dev = container_of(ctrl-handler, struct vivi_dev, 
ctrl_handler);
+
+   if (ctrl == dev-autogain)
+   dev-gain-val = jiffies  0xff;
+   return 0;
+}
+
 static int vivi_s_ctrl(struct v4l2_ctrl *ctrl)
 {
struct vivi_dev *dev = container_of(ctrl-handler, struct vivi_dev, 
ctrl_handler);
@@ -1074,6 +1085,7 @@ static int vivi_mmap(struct file *file, struct 
vm_area_struct *vma)
 }
 
 static const struct v4l2_ctrl_ops vivi_ctrl_ops = {
+   .g_volatile_ctrl = vivi_g_volatile_ctrl,
.s_ctrl = vivi_s_ctrl,
 };
 
@@ -1247,16 +1259,20 @@ static int __init vivi_create_instance(int inst)
 
hdl = dev-ctrl_handler;
v4l2_ctrl_handler_init(hdl, 12);
-   v4l2_ctrl_new_std(hdl, vivi_ctrl_ops,
+   dev-brightness = v4l2_ctrl_new_std(hdl, vivi_ctrl_ops,
V4L2_CID_BRIGHTNESS, i, 255, 1, 127 + i);
-   v4l2_ctrl_new_std(hdl, vivi_ctrl_ops,
+   dev-contrast = v4l2_ctrl_new_std(hdl, vivi_ctrl_ops,
V4L2_CID_CONTRAST, i, 255, 1, 16 + i);
-   v4l2_ctrl_new_std(hdl, vivi_ctrl_ops,
+   dev-sat = v4l2_ctrl_new_std(hdl, vivi_ctrl_ops,
V4L2_CID_SATURATION, i, 255, 1, 127 + i);
-   v4l2_ctrl_new_std(hdl, vivi_ctrl_ops,
+   dev-hue = v4l2_ctrl_new_std(hdl, vivi_ctrl_ops,
V4L2_CID_HUE, -128 + i, 127, 1, i);
dev-volume = v4l2_ctrl_new_std(hdl, vivi_ctrl_ops,
V4L2_CID_AUDIO_VOLUME, 0, 255, 1, 200);
+   dev-autogain = v4l2_ctrl_new_std(hdl, vivi_ctrl_ops,
+   V4L2_CID_AUTOGAIN, 0, 1, 1, 1);
+

[RFCv1 PATCH 3/5] v4l2-ctrls: add v4l2_ctrl_auto_cluster to simplify autogain/gain scenarios

From: Hans Verkuil hans.verk...@cisco.com

It is a bit tricky to handle autogain/gain type scenerios correctly. Such
controls need to be clustered and the V4L2_CTRL_FLAG_UPDATE should be set on
the autofoo controls. In addition, the manual controls should be marked
read-only or inactive when the automatic mode is on, and writable/active
when the manual mode is on. This also requires specialized volatile handling.

The chances of drivers doing all these things correctly are pretty remote.
So a new v4l2_ctrl_auto_cluster function was added that takes care of these
issues.

Signed-off-by: Hans Verkuil hans.verk...@cisco.com
---
 drivers/media/video/v4l2-ctrls.c |   85 --
 include/media/v4l2-ctrls.h   |   46 
 2 files changed, 118 insertions(+), 13 deletions(-)

diff --git a/drivers/media/video/v4l2-ctrls.c b/drivers/media/video/v4l2-ctrls.c
index 7fc6d3f..8ea60c6 100644
--- a/drivers/media/video/v4l2-ctrls.c
+++ b/drivers/media/video/v4l2-ctrls.c
@@ -40,6 +40,13 @@ struct ctrl_helper {
bool handled;
 };
 
+/* Small helper function to determine if the autocluster is set to manual
+   mode which means that the is_volatile flag should be ignored. */
+static bool ignore_volatile(const struct v4l2_ctrl *master)
+{
+   return master-is_auto  master-cur.val == master-manual_mode_value;
+}
+
 /* Returns NULL or a character pointer array containing the menu for
the given control ID. The pointer array ends with a NULL pointer.
An empty string signifies a menu entry that is invalid. This allows
@@ -682,7 +689,8 @@ static int ctrl_is_volatile(struct v4l2_ext_control *c,
 }
 
 /* Copy the new value to the current value. */
-static void new_to_cur(struct v4l2_fh *fh, struct v4l2_ctrl *ctrl)
+static void new_to_cur(struct v4l2_fh *fh, struct v4l2_ctrl *ctrl,
+   bool update_flag)
 {
bool changed = false;
 
@@ -706,8 +714,22 @@ static void new_to_cur(struct v4l2_fh *fh, struct 
v4l2_ctrl *ctrl)
ctrl-cur.val = ctrl-val;
break;
}
-   if (changed)
-   send_event(fh, ctrl, V4L2_EVENT_CTRL_CH_VALUE);
+   if (update_flag) {
+   if (ctrl-is_volatile)
+   ctrl-flags = ~V4L2_CTRL_FLAG_READ_ONLY;
+   else
+   ctrl-flags = ~V4L2_CTRL_FLAG_INACTIVE;
+   if (!ignore_volatile(ctrl-cluster[0])) {
+   if (ctrl-is_volatile)
+   ctrl-flags |= V4L2_CTRL_FLAG_READ_ONLY;
+   else
+   ctrl-flags |= V4L2_CTRL_FLAG_INACTIVE;
+   }
+   }
+   if (changed || update_flag)
+   send_event(fh, ctrl,
+   (changed ? V4L2_EVENT_CTRL_CH_VALUE : 0) |
+   (update_flag ? V4L2_EVENT_CTRL_CH_FLAGS : 0));
 }
 
 /* Copy the current value to the new value */
@@ -1252,7 +1274,7 @@ void v4l2_ctrl_cluster(unsigned ncontrols, struct 
v4l2_ctrl **controls)
int i;
 
/* The first control is the master control and it must not be NULL */
-   BUG_ON(controls[0] == NULL);
+   BUG_ON(ncontrols == 0 || controls[0] == NULL);
 
for (i = 0; i  ncontrols; i++) {
if (controls[i]) {
@@ -1263,6 +1285,31 @@ void v4l2_ctrl_cluster(unsigned ncontrols, struct 
v4l2_ctrl **controls)
 }
 EXPORT_SYMBOL(v4l2_ctrl_cluster);
 
+void v4l2_ctrl_auto_cluster(unsigned ncontrols, struct v4l2_ctrl **controls,
+   u8 manual_val, bool set_volatile)
+{
+   struct v4l2_ctrl *master = controls[0];
+   u32 auto_flag = 0;
+   int i;
+
+   v4l2_ctrl_cluster(ncontrols, controls);
+   WARN_ON(ncontrols = 1);
+   master-is_auto = true;
+   master-manual_mode_value = manual_val;
+   if (set_volatile)
+   master-flags |= V4L2_CTRL_FLAG_UPDATE;
+   if (master-cur.val != manual_val)
+   auto_flag = set_volatile ?
+   V4L2_CTRL_FLAG_READ_ONLY : V4L2_CTRL_FLAG_INACTIVE;
+
+   for (i = 1; i  ncontrols; i++)
+   if (controls[i]) {
+   controls[i]-is_volatile = set_volatile;
+   controls[i]-flags |= auto_flag;
+   }
+}
+EXPORT_SYMBOL(v4l2_ctrl_auto_cluster);
+
 void v4l2_ctrl_flags(struct v4l2_ctrl *ctrl, u32 clear_flags, u32 set_flags)
 {
u32 old_flags;
@@ -1673,7 +1720,7 @@ int v4l2_g_ext_ctrls(struct v4l2_ctrl_handler *hdl, 
struct v4l2_ext_controls *cs
ctrl_is_volatile);
 
/* g_volatile_ctrl will update the new control values */
-   if (has_volatiles) {
+   if (has_volatiles  !ignore_volatile(master)) {
for (j = 0; j  master-ncontrols; j++)
cur_to_new(master-cluster[j]);
ret = call_op(master,

[RFCv1 PATCH 4/5] DocBook: document autoclusters.

From: Hans Verkuil hans.verk...@cisco.com

Signed-off-by: Hans Verkuil hans.verk...@cisco.com
---
 Documentation/video4linux/v4l2-controls.txt |   56 +++
 1 files changed, 56 insertions(+), 0 deletions(-)

diff --git a/Documentation/video4linux/v4l2-controls.txt 
b/Documentation/video4linux/v4l2-controls.txt
index 65d4652..6e277fe 100644
--- a/Documentation/video4linux/v4l2-controls.txt
+++ b/Documentation/video4linux/v4l2-controls.txt
@@ -452,6 +452,25 @@ In the example above the following are equivalent for the 
VOLUME case:
ctrl == ctrl-cluster[AUDIO_CL_VOLUME] == 
state-audio_cluster[AUDIO_CL_VOLUME]
ctrl-cluster[AUDIO_CL_MUTE] == state-audio_cluster[AUDIO_CL_MUTE]
 
+In practice using cluster arrays like this becomes very tiresome. So instead
+the following equivalent method is used:
+
+   struct {
+   /* audio cluster */
+   struct v4l2_ctrl *volume;
+   struct v4l2_ctrl *mute;
+   };
+
+The anonymous struct is used to clearly 'cluster' these two control pointers,
+but it serves no other purpose. The effect is the same as creating an
+array with two control pointers. So you can just do:
+
+   state-volume = v4l2_ctrl_new_std(state-ctrl_handler, ...);
+   state-mute = v4l2_ctrl_new_std(state-ctrl_handler, ...);
+   v4l2_ctrl_cluster(2, state-volume);
+
+And in foo_s_ctrl you can use these pointers directly: state-mute-val.
+
 Note that controls in a cluster may be NULL. For example, if for some
 reason mute was never added (because the hardware doesn't support that
 particular feature), then mute will be NULL. So in that case we have a
@@ -474,6 +493,43 @@ controls, then the 'is_new' flag would be 1 for both 
controls.
 The 'is_new' flag is always 1 when called from v4l2_ctrl_handler_setup().
 
 
+Handling autogain/gain-type Controls with Auto Clusters
+===
+
+A common type of control cluster is one that handles 'auto-foo/foo'-type
+controls. Typical examples are autogain/gain, autoexposure/exposure,
+autowhitebalance/red balance/blue balance. In all cases you have one controls
+that determines whether another control is handled automatically by the 
hardware,
+or whether it is under manual control from the user.
+
+If the cluster is in automatic mode, then the manual controls should be
+marked read-only if they are volatile and inactive if they are non-volatile.
+When the volatile controls are read the g_volatile_ctrl operation should return
+the value that the hardware's automatic mode set up automatically.
+
+If the cluster is put in manual mode, then the manual controls should become
+writable/active again and the is_volatile flag should be ignored (so
+g_volatile_ctrl is no longer called while in manual mode).
+
+Finally the V4L2_CTRL_FLAG_UPDATE should be set for the auto control since
+changing that control affects the control flags of the manual controls.
+
+In order to simplify this a special variation of v4l2_ctrl_cluster was
+introduced:
+
+void v4l2_ctrl_auto_cluster(unsigned ncontrols, struct v4l2_ctrl **controls,
+   u8 manual_val, bool set_volatile);
+
+The first two arguments are identical to v4l2_ctrl_cluster. The third argument
+tells the framework which value switches the cluster into manual mode. The
+last argument will optionally set is_volatile flag for the non-auto controls.
+
+The first control of the cluster is assumed to be the 'auto' control.
+
+Using this function will ensure that you don't need to handle all the complex
+flag and volatile handling.
+
+
 VIDIOC_LOG_STATUS Support
 =
 
-- 
1.7.1

--
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: [beagleboard] [PATCH] Second RFC version of mt9p031 sensor with power managament.

2011-05-27 Thread javier Martin

On 27 May 2011 16:31, Laurent Pinchart
laurent.pinch...@ideasonboard.com wrote:
 Hi Javier,

 On Thursday 26 May 2011 13:31:37 javier Martin wrote:
 OK, I think I've found the problem with the power management.

 As it is stated in mt9p031 datasheet [3] p 59, a sequence involving
 [VAA,VAA_PIX,VDD_PLL], [VDD,VDD_IO], [Reset] and [Ext Clk] must be
 followed in order to properly power up or down the sensor.

 If we take a look to the LI-5M031 schematic[1] and Beagleboard xM
 schematic [2] we'll notice that voltages are connected as follows:

 [VDD] (1,8V) --- V2.8 --- CAM_CORE --- VAUX3 TPS65950
 [VDD_IO (VDDQ)] (1,8V) --- V1.8 --- CAM_IO --- VAUX4 TPS65950
 [VAA, VAA_PIX, VDD_PLL] (2,8V) ---| U6 |-- V3.3VD -- HUB_3V3 --|
 U16 | enabled by USBHOST_PWR_EN -- LEDA TPS65950

 VAUX3 (VDD) and VAUX4 (VDD_IO) are fine, they are only used for
 powering our camera sensor. However, when it comes to the analog part
 (VAA, VAA_PIX...), it is got from HUB_3V3 which is also used for
 powering USB and ethernet.

 *sigh* Why do hardware designers do things like that, really ?

 If we really want to activate/deactivate regulators that power mt9p031
 we need to follow [3] p59. However, for that purpose we need to ensure
 that a call to regulator_enable() or regulator_disable() will really
 power on/off that supply, otherwise the sequence won't be matched and
 the chip will have problems.

 Beagleboard xM is a good example of platform where this happens since
 HUB_3V3 and thus (VAA, VAA_PIX, etc...) cannot be deactivated since it
 is being used by other devices. But there could be others.

 So, as a conclusion, and in order to unblock my work, my purpose for
 power management in mt9p031 would be the following:
 - Drop regulator handling as we cannot guarantee that power on
 sequence will be accomplished.
 - Keep on asserting/de-asserting reset which saves a lot of power.
 - Also activate/deactivate clock when necessary to save some power.

 I'm looking forward to read your comments on this.

 Even if you keep the sensor powered all the time, how do you ensure that VAUX3
 is available before HUB_3V3 when the system is powered up ?

You can't. And in fact what happens its the opposite. But it works.

On the other hand, not being able to disable/enable HUB_3V3 can make,
as a hardware guy has told me, power on reset internal circuit not to
work [1] and thus the power down / power up fails.

[1] http://en.wikipedia.org/wiki/Power-on_reset


-- 
Javier Martin
Vista Silicon S.L.
CDTUC - FASE C - Oficina S-345
Avda de los Castros s/n
39005- Santander. Cantabria. Spain
+34 942 25 32 60
www.vista-silicon.com
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] [media] nuvoton-cir: in_use isn't actually in use, remove it

Signed-off-by: Jarod Wilson ja...@redhat.com
---
 drivers/media/rc/nuvoton-cir.c |2 --
 drivers/media/rc/nuvoton-cir.h |1 -
 2 files changed, 0 insertions(+), 3 deletions(-)

diff --git a/drivers/media/rc/nuvoton-cir.c b/drivers/media/rc/nuvoton-cir.c
index bf3060e..565f24c 100644
--- a/drivers/media/rc/nuvoton-cir.c
+++ b/drivers/media/rc/nuvoton-cir.c
@@ -991,7 +991,6 @@ static int nvt_open(struct rc_dev *dev)
unsigned long flags;
 
spin_lock_irqsave(nvt-nvt_lock, flags);
-   nvt-in_use = true;
nvt_enable_cir(nvt);
spin_unlock_irqrestore(nvt-nvt_lock, flags);
 
@@ -1004,7 +1003,6 @@ static void nvt_close(struct rc_dev *dev)
unsigned long flags;
 
spin_lock_irqsave(nvt-nvt_lock, flags);
-   nvt-in_use = false;
nvt_disable_cir(nvt);
spin_unlock_irqrestore(nvt-nvt_lock, flags);
 }
diff --git a/drivers/media/rc/nuvoton-cir.h b/drivers/media/rc/nuvoton-cir.h
index 379795d..1241fc8 100644
--- a/drivers/media/rc/nuvoton-cir.h
+++ b/drivers/media/rc/nuvoton-cir.h
@@ -70,7 +70,6 @@ struct nvt_dev {
struct ir_raw_event rawir;
 
spinlock_t nvt_lock;
-   bool in_use;
 
/* for rx */
u8 buf[RX_BUF_LEN];
-- 
1.7.1

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

[PATCH] [media] mceusb: plug memory leak on data transmit

Hans Petter Selasky pointed out to me that we're leaking urbs when
mce_async_out is called. Its used both for configuring the hardware and
for transmitting IR data. In the tx case, mce_request_packet actually
allocates both a urb and the transfer buffer, neither of which was being
torn down. Do that in the tx callback.

CC: Hans Petter Selasky hsela...@c2i.net
Signed-off-by: Jarod Wilson ja...@redhat.com
---
 drivers/media/rc/mceusb.c |3 +++
 1 files changed, 3 insertions(+), 0 deletions(-)

diff --git a/drivers/media/rc/mceusb.c b/drivers/media/rc/mceusb.c
index ad927fc..124f5af 100644
--- a/drivers/media/rc/mceusb.c
+++ b/drivers/media/rc/mceusb.c
@@ -612,6 +612,9 @@ static void mce_async_callback(struct urb *urb, struct 
pt_regs *regs)
mceusb_dev_printdata(ir, urb-transfer_buffer, 0, len, true);
}
 
+   /* the transfer buffer and urb were allocated in mce_request_packet */
+   kfree(urb-transfer_buffer);
+   usb_free_urb(urb);
 }
 
 /* request incoming or send outgoing usb packet - used to initialize remote */
-- 
1.7.1

--
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: PCTV nanoStick T2 290e support - Thank you!

2011-05-27 Thread Ondřej Caletka

Hello,

I would like to join the line of thankers for this wonderful driver. I
am using it with experimental DVB-T2 broadcast in Prague, CZE to stream
whole T2 MUX to a campus network using DVBlast. It run for a month now,
and only outages was the outages of the experimental transmisson itself.

It works as well as another DVB-T/S card. Great job!

--
Ondrej Caletka
--
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: ERRORS

This message is generated daily by a cron job that builds v4l-dvb for
the kernels and architectures in the list below.

Results of the daily build of v4l-dvb:

date:Fri May 27 19:01:05 CEST 2011
git hash:f9b51477fe540fb4c65a05027fdd6f2ecce4db3b
gcc version:  i686-linux-gcc (GCC) 4.5.1
host hardware:x86_64
host os:  2.6.32.5

linux-git-armv5: OK
linux-git-armv5-davinci: OK
linux-git-armv5-ixp: OK
linux-git-armv5-omap2: OK
linux-git-i686: OK
linux-git-m32r: OK
linux-git-mips: WARNINGS
linux-git-powerpc64: OK
linux-git-x86_64: OK
linux-2.6.31.12-i686: ERRORS
linux-2.6.32.6-i686: WARNINGS
linux-2.6.33-i686: WARNINGS
linux-2.6.34-i686: WARNINGS
linux-2.6.35.3-i686: WARNINGS
linux-2.6.36-i686: ERRORS
linux-2.6.37-i686: WARNINGS
linux-2.6.38.2-i686: WARNINGS
linux-2.6.31.12-x86_64: ERRORS
linux-2.6.32.6-x86_64: WARNINGS
linux-2.6.33-x86_64: WARNINGS
linux-2.6.34-x86_64: WARNINGS
linux-2.6.35.3-x86_64: WARNINGS
linux-2.6.36-x86_64: ERRORS
linux-2.6.37-x86_64: WARNINGS
linux-2.6.38.2-x86_64: WARNINGS
spec-git: OK
sparse: ERRORS

Detailed results are available here:

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

Full logs are available here:

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

The V4L-DVB specification from this daily build is here:

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

[PATCH] [media] lirc_dev: store cdev in irctl, up maxdevs

Store the cdev pointer in struct irctl, allocated dynamically as needed,
rather than having a static array. At the same time, recycle some of the
saved memory to nudge the maximum number of lirc devices supported up a
ways -- its not that uncommon these days, now that we have the rc-core
lirc bridge driver, to see a system with at least 4 raw IR receivers.
(consider a mythtv backend with several video capture devices and the
possible need for IR transmit hardware).

Signed-off-by: Jarod Wilson ja...@redhat.com
---
 drivers/media/rc/lirc_dev.c |   33 -
 include/media/lirc_dev.h|2 +-
 2 files changed, 25 insertions(+), 10 deletions(-)

diff --git a/drivers/media/rc/lirc_dev.c b/drivers/media/rc/lirc_dev.c
index fd237ab..9e79692 100644
--- a/drivers/media/rc/lirc_dev.c
+++ b/drivers/media/rc/lirc_dev.c
@@ -55,6 +55,8 @@ struct irctl {
struct lirc_buffer *buf;
unsigned int chunk_size;
 
+   struct cdev *cdev;
+
struct task_struct *task;
long jiffies_to_wait;
 };
@@ -62,7 +64,6 @@ struct irctl {
 static DEFINE_MUTEX(lirc_dev_lock);
 
 static struct irctl *irctls[MAX_IRCTL_DEVICES];
-static struct cdev cdevs[MAX_IRCTL_DEVICES];
 
 /* Only used for sysfs but defined to void otherwise */
 static struct class *lirc_class;
@@ -169,7 +170,9 @@ static int lirc_cdev_add(struct irctl *ir)
 {
int retval;
struct lirc_driver *d = ir-d;
-   struct cdev *cdev = cdevs[d-minor];
+   struct cdev *cdev;
+
+   cdev = kzalloc(sizeof(*cdev), GFP_KERNEL);
 
if (d-fops) {
cdev_init(cdev, d-fops);
@@ -180,12 +183,20 @@ static int lirc_cdev_add(struct irctl *ir)
}
retval = kobject_set_name(cdev-kobj, lirc%d, d-minor);
if (retval)
-   return retval;
+   goto err_out;
 
retval = cdev_add(cdev, MKDEV(MAJOR(lirc_base_dev), d-minor), 1);
-   if (retval)
+   if (retval) {
kobject_put(cdev-kobj);
+   goto err_out;
+   }
+
+   ir-cdev = cdev;
+
+   return 0;
 
+err_out:
+   kfree(cdev);
return retval;
 }
 
@@ -214,7 +225,7 @@ int lirc_register_driver(struct lirc_driver *d)
if (MAX_IRCTL_DEVICES = d-minor) {
dev_err(d-dev, lirc_dev: lirc_register_driver: 
\minor\ must be between 0 and %d (%d)!\n,
-   MAX_IRCTL_DEVICES-1, d-minor);
+   MAX_IRCTL_DEVICES - 1, d-minor);
err = -EBADRQC;
goto out;
}
@@ -369,7 +380,7 @@ int lirc_unregister_driver(int minor)
 
if (minor  0 || minor = MAX_IRCTL_DEVICES) {
printk(KERN_ERR lirc_dev: %s: minor (%d) must be between 
-  0 and %d!\n, __func__, minor, MAX_IRCTL_DEVICES-1);
+  0 and %d!\n, __func__, minor, MAX_IRCTL_DEVICES - 1);
return -EBADRQC;
}
 
@@ -380,7 +391,7 @@ int lirc_unregister_driver(int minor)
return -ENOENT;
}
 
-   cdev = cdevs[minor];
+   cdev = ir-cdev;
 
mutex_lock(lirc_dev_lock);
 
@@ -410,6 +421,7 @@ int lirc_unregister_driver(int minor)
} else {
lirc_irctl_cleanup(ir);
cdev_del(cdev);
+   kfree(cdev);
kfree(ir);
irctls[minor] = NULL;
}
@@ -453,7 +465,7 @@ int lirc_dev_fop_open(struct inode *inode, struct file 
*file)
goto error;
}
 
-   cdev = cdevs[iminor(inode)];
+   cdev = ir-cdev;
if (try_module_get(cdev-owner)) {
ir-open++;
retval = ir-d.set_use_inc(ir-d.data);
@@ -484,13 +496,15 @@ EXPORT_SYMBOL(lirc_dev_fop_open);
 int lirc_dev_fop_close(struct inode *inode, struct file *file)
 {
struct irctl *ir = irctls[iminor(inode)];
-   struct cdev *cdev = cdevs[iminor(inode)];
+   struct cdev *cdev;
 
if (!ir) {
printk(KERN_ERR %s: called with invalid irctl\n, __func__);
return -EINVAL;
}
 
+   cdev = ir-cdev;
+
dev_dbg(ir-d.dev, LOGHEAD close called\n, ir-d.name, ir-d.minor);
 
WARN_ON(mutex_lock_killable(lirc_dev_lock));
@@ -503,6 +517,7 @@ int lirc_dev_fop_close(struct inode *inode, struct file 
*file)
lirc_irctl_cleanup(ir);
cdev_del(cdev);
irctls[ir-d.minor] = NULL;
+   kfree(cdev);
kfree(ir);
}
 
diff --git a/include/media/lirc_dev.h b/include/media/lirc_dev.h
index 630e702..168dd0b 100644
--- a/include/media/lirc_dev.h
+++ b/include/media/lirc_dev.h
@@ -9,7 +9,7 @@
 #ifndef _LINUX_LIRC_DEV_H
 #define _LINUX_LIRC_DEV_H
 
-#define MAX_IRCTL_DEVICES 4
+#define MAX_IRCTL_DEVICES 8
 #define BUFLEN16
 
 #define mod(n, div) ((n) % (div))
-- 
1.7.5.2

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

Terratec Cinergy C HD - CAM support.... Need help?

2011-05-27 Thread Willem van Asperen

Hi All,

I need something but willing to help out!

I just got my Terratec Cinergy C HD card. After relatively minor issues I got 
the card running on my Mandriva 2010.2 (kernel 2.6.33) myth box.

But... I am getting my DVB-C signal from the Ziggo (former Casema) network. I 
found a post that claims that all channels are encrypted (except for Nederland 
1). Even though these are the standard channels that you also get when you 
just have an analog subscription.

So. I need CAM support. After a couple of nights swimming the net I come to 
the conclusion that

a) CAM support is currently not implemented
b) This support has been not implemented for quite some time
c) There are more people that would like it to work...

So, dear people, is anyone working on getting the CAM to work on the Terratec 
Cinergy C HD card, but having problems? Is there any way, shape or form that I 
can assist in getting this support done?

Or have we given up on this card and should I just take my loss and go for 
another card... If so, which one?

Thanks,
Willem
--
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] Terratec Cinergy C HD - CAM support.... Need help?

2011-05-27 Thread Marc Coevoet


Op 27-05-11 21:48, Willem van Asperen schreef:


a) CAM support is currently not implemented for terratec HD


For all cards?

I use TNT/dvb sticks, and you should be able to decode HD video with a 
so called no hd usb stick.


Because it is a question of software, not hardware.

Maybe, if one CAM card works, you should look for it ...


Marc

--
The Penguin has arrived - and he's not going away - ever.
What's on Shortwave guide: choose an hour, go!
http://shortwave.tk
700+ Radio Stations on SW http://swstations.tk
300+ languages on SW http://radiolanguages.tk

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

[PATCH] [media] fintek-cir: make suspend with active IR more reliable