Re: MIPI flag support updated

Hi On Fri, 15 Apr 2011, Kassey Lee wrote: > Hi, Guennadi , Hans: > > > I've updated the patch to support MIPI flag for camera sensor > and host controller as you suggested, would you please have time to > review ? It's queued for 2.6.40 > > http://thread.gmane.org/gmane.linux.driver

MIPI flag support updated

Hi, Guennadi , Hans: I've updated the patch to support MIPI flag for camera sensor and host controller as you suggested, would you please have time to review ? http://thread.gmane.org/gmane.linux.drivers.video-input-infrastructure/27609/focus=28195 thanks -- To unsubscribe from

Re: [RFC] V4L2 API for flash devices

Laurent Pinchart wrote: > Hi Sakari, Heippa, > On Wednesday 13 April 2011 14:16:38 Sakari Ailus wrote: >> Sung Hee Park wrote: >>> Here are two more use-cases for flash that might help inform the API >>> design. Sakari encouraged me to post these. The person writing this is >>> Andrew Adams, but

Re: [PATCH v2] tm6000: fix vbuf may be used uninitialized

Hi I think it's good. No regression, all works well. With my best regards, Dmitry. > In commit 8aff8ba95155df, most of the manipulations to vbuf inside > copy_streams were gated on if !dev->radio, but one place that touches > vbuf lays outside those gates -- a memcpy of vbuf isn't NULL. If we >

Re: [RFC] V4L2 API for flash devices

Hi Sakari, On Wednesday 13 April 2011 14:16:38 Sakari Ailus wrote: > Sung Hee Park wrote: > > Here are two more use-cases for flash that might help inform the API > > design. Sakari encouraged me to post these. The person writing this is > > Andrew Adams, but I'm sending this from Sung Hee's accou

[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:Thu Apr 14 19:00:28 CEST 2011 git hash:d9954d8547181f9a6a23f835cc1413732700b785 gcc version: i686-linux-gcc (GCC) 4.5

rc_maps.cfg default config for hauppauge

Hi! The default rc_maps.cfg doesn't work for hauppauge remotes, because there's no rc_keymaps/hauppauge, only rc_keymaps/haupp. Also, there's no config for rc-hauppauge-new table, so I made the following changes: $diff rc_maps.cfg_orig rc_maps.cfg 113c113 < * rc-rc5-hauppauge hauppaug

Re: KNC ONE DVB-C [1894:0022] can't find any channels, PAT/SDT/NIT filter timeout

On Thu, Apr 14, 2011 at 2:38 AM, Frantisek Augusztin wrote: > Tested using Arch Linux 2.6.37-ARCH and current 2.6.39-rc3 kernels, > same result. > > Signal level according to the set top box is ~57%, signal quality is > 97-99%, and as i mentoined, set top box works without problems, and > it works

[PATCH] mt9v022: fix pixel clock

The setup of the pixel clock is done wrong in the mt9v022 driver. The 'Invert Pixel Clock' bit has to be set to 1 for falling edge and not for rising. This is not clearly described in the data sheet. Tested on pcm037 and pcm027/pcm990. Signed-off-by: Teresa Gámez --- drivers/media/video/mt9v022

Re: Antwort: Re: [PATCH 1/2] mt9v022: fix pixel clock

Am Mittwoch, den 13.04.2011, 08:31 +0200 schrieb Guennadi Liakhovetski: > Hello Teresa > > Thanks very much for your extensive testing! I'm afraid, I don't have the > time right now to go through all those register settings, so, can we, > maybe, do the following: we currently have two platforms

Re: [PATCH 2.6.39 v2] V4L: videobuf-dma-contig: fix mmap_mapper broken on ARM

Hello. On 14-04-2011 1:01, Janusz Krzysztofik wrote: After switching from mem->dma_handle to virt_to_phys(mem->vaddr) used for obtaining page frame number passed to remap_pfn_range() (commit 35d9f510b67b10338161aba6229d4f55b4000f5b), videobuf-dma-contig Please specify the commit summary

Re: OMAP3 ISP deadlocks on my new arm

Yeah! S... when I initialized the the camera (loading a 108 bytes register listing) I just let run the camera and sent images. So I first realized a counter overflow if (count++ > 10) after a few seconds. But this seemed to be handled correctly (ignore and delete HS_VS_IRQ flag) while af

[PATCH] media: vb2: correct queue initialization order

q->memory entry is initialized to late, so if allocation of memory buffers fails, the buffers might not be freed correctly (q->memory is tested in __vb2_free_mem, which can be called before setting q->memory). Reported-by: Kamil Debski Signed-off-by: Marek Szyprowski Signed-off-by: Kyungmin Park

Re: OMAP3 ISP deadlocks on my new arm

Hi Bastian, On Thursday 14 April 2011 10:33:12 Bastian Hecht wrote: > 2011/4/13 Sakari Ailus : > > Bastian Hecht wrote: > >> Hello people, > > > > Hi Bastian, > > > > I'm cc'ing Laurent. > > > >> I switched to the new DM3730 from IGEP and while it's supposed to be > >> (almost) the same as the

Re: OMAP3 ISP deadlocks on my new arm

Hello Sakari, 2011/4/13 Sakari Ailus : > Bastian Hecht wrote: >> Hello people, > > Hi Bastian, > > I'm cc'ing Laurent. > >> I switched to the new DM3730 from IGEP and while it's supposed to be >> (almost) the same as the 3530 Version the isp deadlocks >> deterministically after I start capturing t

[PATCH] media: vb2: fix incorrect v4l2_buffer->flags handling

Videobuf2 core assumes that driver doesn't set any buffer flags. This is correct for buffer state flags that videobuf2 manages, but the other flags like V4L2_BUF_FLAG_{KEY,P,B}FRAME, V4L2_BUF_FLAG_TIMECODE and V4L2_BUF_FLAG_INPUT should be passed from or to the driver. Reported-by: Jonghun Han Si