date:20110228

Hello,

On Saturday, February 26, 2011 8:20 PM Nicolas Pitre wrote:

 On Sat, 26 Feb 2011, Kyungmin Park wrote:
 
  On Sat, Feb 26, 2011 at 2:22 AM, Linus Walleij linus.wall...@linaro.org 
  wrote:
   2011/2/24 Edward Hervey bilb...@gmail.com:
  
    What *needs* to be solved is an API for data allocation/passing at the
   kernel level which v4l2,omx,X,GL,vdpau,vaapi,... can use and that
   userspace (like GStreamer) can pass around, monitor and know about.
  
   I think the patches sent out from ST-Ericsson's Johan Mossberg to
   linux-mm for HWMEM (hardware memory) deals exactly with buffer
   passing, pinning of buffers and so on. The CMA (Contigous Memory
   Allocator) has been slightly modified to fit hand-in-glove with HWMEM,
   so CMA provides buffers, HWMEM pass them around.
  
   Johan, when you re-spin the HWMEM patchset, can you include
   linaro-dev and linux-media in the CC? I think there is *much* interest
   in this mechanism, people just don't know from the name what it
   really does. Maybe it should be called mediamem or something
   instead...
 
  To Marek,
 
  Can you also update the CMA status and plan?
 
  The important thing is still Russell don't agree the CMA since it's
  not solve the ARM different memory attribute mapping issue. Of course
  there's no way to solve the ARM issue.
 
 There are at least two ways to solve that issue, and I have suggested
 both on the lak mailing list already.
 
 1) Make the direct mapped kernel memory usable by CMA mapped through a
page-sized two-level page table mapping which would allow for solving
the attributes conflict on a per page basis.

That's the solution I work on now. I've also suggested this in the last
CMA discussion, however there was no response if this is the right way

 2) Use highmem more aggressively and allow only highmem pages for CMA.
This is quite easy to make sure the target page(s) for CMA would have
no kernel mappings and therefore no attribute conflict.  Furthermore,
highmem pages are always relocatable for making physically contiguous
segments available.

I'm not sure that highmem is the right solution. First, this will force
systems with rather small amount of memory (like 256M) to use highmem just
to support DMA allocable memory. It also doesn't solve the issue with
specific memory requirement for our DMA hardware (multimedia codec needs
video memory buffers from 2 physical banks).

The relocation issue has been already addressed in the last CMA patch series.
Michal managed to create a framework that allowed to relocate on demand any
pages from the CMA area.

Best regards
--
Marek Szyprowski
Samsung Poland RD Center


--
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 v2 -resend#1 1/1] V4L: videobuf, don't use dma addr as physical

mem-dma_handle is a dma address obtained by dma_alloc_coherent which
needn't be a physical address in presence of IOMMU. So ensure we are
remapping (remap_pfn_range) the right page in __videobuf_mmap_mapper
by using virt_to_phys(mem-vaddr) and not mem-dma_handle.

While at it, use PFN_DOWN instead of explicit shift.

Signed-off-by: Jiri Slaby jsl...@suse.cz
Cc: Mauro Carvalho Chehab mche...@infradead.org
Cc: Konrad Rzeszutek Wilk konrad.w...@oracle.com
---
 drivers/media/video/videobuf-dma-contig.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/drivers/media/video/videobuf-dma-contig.c 
b/drivers/media/video/videobuf-dma-contig.c
index c969111..19d3e4a 100644
--- a/drivers/media/video/videobuf-dma-contig.c
+++ b/drivers/media/video/videobuf-dma-contig.c
@@ -300,7 +300,7 @@ static int __videobuf_mmap_mapper(struct videobuf_queue *q,
 
vma-vm_page_prot = pgprot_noncached(vma-vm_page_prot);
retval = remap_pfn_range(vma, vma-vm_start,
-mem-dma_handle  PAGE_SHIFT,
+PFN_DOWN(virt_to_phys(mem-vaddr))
 size, vma-vm_page_prot);
if (retval) {
dev_err(q-dev, mmap: remap failed with error %d. , retval);
-- 
1.7.4.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: [RFC PATCH RESEND v2 2/3] v4l2-ctrls: modify uvc driver to use new menu type of V4L2_CID_FOCUS_AUTO

Hi,

On Monday 28 February 2011 06:15:23 Kim, HeungJun wrote:
 2011-02-25 오후 9:58, Laurent Pinchart 쓴 글:
  On Friday 25 February 2011 13:46:01 Kim, HeungJun wrote:
  As following to change the boolean type of V4L2_CID_FOCUS_AUTO to menu
  type, this uvc is modified the usage of V4L2_CID_FOCUS_AUTO.
  
  Signed-off-by: Heungjun Kim riverful@samsung.com
  Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
  ---
  
   drivers/media/video/uvc/uvc_ctrl.c |9 -
   1 files changed, 8 insertions(+), 1 deletions(-)
  
  diff --git a/drivers/media/video/uvc/uvc_ctrl.c
  b/drivers/media/video/uvc/uvc_ctrl.c index 59f8a9a..b98b9f1 100644
  --- a/drivers/media/video/uvc/uvc_ctrl.c
  +++ b/drivers/media/video/uvc/uvc_ctrl.c
  @@ -333,6 +333,11 @@ static struct uvc_menu_info
  exposure_auto_controls[] = { { 8, Aperture Priority Mode },
  
   };
  
  +static struct uvc_menu_info focus_auto_controls[] = {
  +  { 1, Auto Mode },
  +  { 0, Manual Mode },
  
  Now that manual focus has value 0 and auto focus value 1, the menu
  entries need to be the other way around.
 
 I don't really get it. My understanding is that your words are structure
 uvc_menu_info should be changed as fitted to focus menu type. right?
 But, I thinks they don't need to be changed, and I don't find wrong,
 I don't know how to fix what you telling me exactly.
 
 So, could you explain more details? Some examples helps to me.

The menu entries are indexed by the V4L2 menu value. The first field is the 
UVC menu entry value, and the second field its name. As the V4L2 manual focus 
control has a value of 0, it must be the first entry.

 Sorry to bother if you are busy, but it's good for me your advice.
 I'll waiting.

No worries.

-- 
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: [st-ericsson] v4l2 vs omx for camera

On Saturday 26 February 2011 13:12:42 Hans Verkuil wrote:
 On Friday, February 25, 2011 18:22:51 Linus Walleij wrote:
  2011/2/24 Edward Hervey bilb...@gmail.com:
What *needs* to be solved is an API for data allocation/passing at the
   
   kernel level which v4l2,omx,X,GL,vdpau,vaapi,... can use and that
   userspace (like GStreamer) can pass around, monitor and know about.
  
  I think the patches sent out from ST-Ericsson's Johan Mossberg to
  linux-mm for HWMEM (hardware memory) deals exactly with buffer
  passing, pinning of buffers and so on. The CMA (Contigous Memory
  Allocator) has been slightly modified to fit hand-in-glove with HWMEM,
  so CMA provides buffers, HWMEM pass them around.
  
  Johan, when you re-spin the HWMEM patchset, can you include
  linaro-dev and linux-media in the CC?
 
 Yes, please. This sounds promising and we at linux-media would very much
 like to take a look at this. I hope that the CMA + HWMEM combination is
 exactly what we need.

Once again let me restate what I've been telling for some time: CMA must be 
*optional*. Not all hardware need contiguous memory. I'll have a look at the 
next HWMEM version.

-- 
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: [st-ericsson] v4l2 vs omx for camera

On Sunday, February 27, 2011 20:49:37 Arnd Bergmann wrote:
 On Saturday 26 February 2011, Edward Hervey wrote:
   
   Are there any gstreamer/linaro/etc core developers attending the ELC in 
San Francisco
   in April? I think it might be useful to get together before, during or 
after the
   conference and see if we can turn this discussion in something more 
concrete.
   
   It seems to me that there is an overall agreement of what should be 
done, but
   that we are far from anything concrete.
   
  
I will be there and this was definitely a topic I intended to talk
  about.
See you there.
 
 I'll also be there. Should we organize an official BOF session for this and
 invite more people?

I think that is an excellent idea. Do you want to organize that? (Always the
penalty for suggesting this first :-) )

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: [st-ericsson] v4l2 vs omx for camera

On Sunday 27 February 2011 20:49:37 Arnd Bergmann wrote:
 On Saturday 26 February 2011, Edward Hervey wrote:
   Are there any gstreamer/linaro/etc core developers attending the ELC in
   San Francisco in April? I think it might be useful to get together
   before, during or after the conference and see if we can turn this
   discussion in something more concrete.
   
   It seems to me that there is an overall agreement of what should be
   done, but that we are far from anything concrete.
   
  I will be there and this was definitely a topic I intended to talk about.
  
  See you there.
 
 I'll also be there. Should we organize an official BOF session for this and
 invite more people?

Any chance of an IRC backchannel and a live audio/video stream for those of us 
who won't be there ?

-- 
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: [st-ericsson] v4l2 vs omx for camera

On Monday, February 28, 2011 11:11:47 Laurent Pinchart wrote:
 On Saturday 26 February 2011 13:12:42 Hans Verkuil wrote:
  On Friday, February 25, 2011 18:22:51 Linus Walleij wrote:
   2011/2/24 Edward Hervey bilb...@gmail.com:
 What *needs* to be solved is an API for data allocation/passing at 
the

kernel level which v4l2,omx,X,GL,vdpau,vaapi,... can use and that
userspace (like GStreamer) can pass around, monitor and know about.
   
   I think the patches sent out from ST-Ericsson's Johan Mossberg to
   linux-mm for HWMEM (hardware memory) deals exactly with buffer
   passing, pinning of buffers and so on. The CMA (Contigous Memory
   Allocator) has been slightly modified to fit hand-in-glove with HWMEM,
   so CMA provides buffers, HWMEM pass them around.
   
   Johan, when you re-spin the HWMEM patchset, can you include
   linaro-dev and linux-media in the CC?
  
  Yes, please. This sounds promising and we at linux-media would very much
  like to take a look at this. I hope that the CMA + HWMEM combination is
  exactly what we need.
 
 Once again let me restate what I've been telling for some time: CMA must be 
 *optional*. Not all hardware need contiguous memory. I'll have a look at the 
 next HWMEM version.

Yes, it is optional when you look at specific hardware. On a kernel level 
however it is functionality that is required in order to support all the 
hardware. There is little point in solving one issue and not the other.

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: [RFC] snapshot mode, flash capabilities and control

On Saturday 26 February 2011 14:03:53 Guennadi Liakhovetski wrote:
 On Sat, 26 Feb 2011, Hans Verkuil wrote:
  On Friday, February 25, 2011 18:08:07 Guennadi Liakhovetski wrote:
  
  snip
  
 configure the sensor to react on an external trigger provided by
 the flash controller is needed, and that could be a control on the
 flash sub-device. What we would probably miss is a way to issue a
 STREAMON with a number of frames to capture. A new ioctl is
 probably needed there. Maybe that would be an opportunity to
 create a new stream-control ioctl that could replace STREAMON and
 STREAMOFF in the long term (we could extend the subdev s_stream
 operation, and easily map STREAMON and STREAMOFF to the new ioctl
 in video_ioctl2 internally).

How would this be different from queueing n frames (in total; count
dequeueing, too) and issuing streamon? --- Except that when the last
frame is processed the pipeline could be stopped already before
issuing STREAMOFF. That does indeed have some benefits. Something
else?
   
   Well, you usually see in your host driver, that the videobuffer queue
   is empty (no more free buffers are available), so, you stop streaming
   immediately too.
  
  This probably assumes that the host driver knows that this is a special
  queue? Because in general drivers will simply keep capturing in the last
  buffer and not release it to userspace until a new buffer is queued.
 
 Yes, I know about this spec requirement, but I also know, that not all
 drivers do that and not everyone is happy about that requirement:)

Is it a requirement, or just something some drivers do ? Several drivers just 
stop capturing when no buffer is available, and resume when a new buffer is 
queued.

  That said, it wouldn't be hard to add some flag somewhere that puts a
  queue in a 'stop streaming on last buffer capture' mode.
 
 No, it wouldn't... But TBH this doesn't seem like the most elegant and
 complete solution. Maybe we have to think a bit more about it - which
 soncequences switching into the snapshot mode has on the host driver,
 apart from stopping after N frames. So, this is one of the possibilities,
 not sure if the best one.

-- 
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: [RFC/PATCH 1/2] v4l: videobuf2: Handle buf_queue errors

Hello,

On Sunday, February 27, 2011 7:13 PM Laurent Pinchart wrote:

 videobuf2 expects drivers to check buffer in the buf_prepare operation
 and to return success only if the buffer can queued without any issue.
 
 For hot-pluggable devices, disconnection events need to be handled at
 buf_queue time. Checking the disconnected flag and adding the buffer to
 the driver queue need to be performed without releasing the driver
 spinlock, otherwise race conditions can occur in which the driver could
 still allow a buffer to be queued after the disconnected flag has been
 set, resulting in a hang during the next DQBUF operation.
 
 This problem can be solved either in the videobuf2 core or in the device
 drivers. To avoid adding a spinlock to videobuf2, make buf_queue return
 an int and handle buf_queue failures in videobuf2. Drivers must not
 return an error in buf_queue if the condition leading to the error can
 be caught in buf_prepare.
 
 Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com

Acked-by: Marek Szyprowski m.szyprow...@samsung.com

We discussed how to solve the hot-plug issue and this is the solution I prefer.

 ---
  drivers/media/video/videobuf2-core.c |   32 ++--
  include/media/videobuf2-core.h   |2 +-
  2 files changed, 27 insertions(+), 7 deletions(-)
 
 diff --git a/drivers/media/video/videobuf2-core.c 
 b/drivers/media/video/videobuf2-core.c
 index cc7ab0a..1d81536 100644
 --- a/drivers/media/video/videobuf2-core.c
 +++ b/drivers/media/video/videobuf2-core.c
 @@ -798,13 +798,22 @@ static int __qbuf_mmap(struct vb2_buffer *vb, struct 
 v4l2_buffer *b)
  /**
   * __enqueue_in_driver() - enqueue a vb2_buffer in driver for processing
   */
 -static void __enqueue_in_driver(struct vb2_buffer *vb)
 +static int __enqueue_in_driver(struct vb2_buffer *vb)
  {
   struct vb2_queue *q = vb-vb2_queue;
 + int ret;
 
   vb-state = VB2_BUF_STATE_ACTIVE;
   atomic_inc(q-queued_count);
 - q-ops-buf_queue(vb);
 + ret = q-ops-buf_queue(vb);
 + if (ret == 0)
 + return 0;
 +
 + vb-state = VB2_BUF_STATE_ERROR;
 + atomic_dec(q-queued_count);
 + wake_up_all(q-done_wq);
 +
 + return ret;
  }
 
  /**
 @@ -890,8 +899,13 @@ int vb2_qbuf(struct vb2_queue *q, struct v4l2_buffer *b)
* If already streaming, give the buffer to driver for processing.
* If not, the buffer will be given to driver on next streamon.
*/
 - if (q-streaming)
 - __enqueue_in_driver(vb);
 + if (q-streaming) {
 + ret = __enqueue_in_driver(vb);
 + if (ret  0) {
 + dprintk(1, qbuf: buffer queue failed\n);
 + return ret;
 + }
 + }
 
   dprintk(1, qbuf of buffer %d succeeded\n, vb-v4l2_buf.index);
   return 0;
 @@ -1101,6 +1115,7 @@ EXPORT_SYMBOL_GPL(vb2_dqbuf);
  int vb2_streamon(struct vb2_queue *q, enum v4l2_buf_type type)
  {
   struct vb2_buffer *vb;
 + int ret;
 
   if (q-fileio) {
   dprintk(1, streamon: file io in progress\n);
 @@ -1139,8 +1154,13 @@ int vb2_streamon(struct vb2_queue *q, enum 
 v4l2_buf_type type)
* If any buffers were queued before streamon,
* we can now pass them to driver for processing.
*/
 - list_for_each_entry(vb, q-queued_list, queued_entry)
 - __enqueue_in_driver(vb);
 + list_for_each_entry(vb, q-queued_list, queued_entry) {
 + ret = __enqueue_in_driver(vb);
 + if (ret  0) {
 + dprintk(1, streamon: buffer queue failed\n);
 + return ret;
 + }
 + }
 
   dprintk(3, Streamon successful\n);
   return 0;
 diff --git a/include/media/videobuf2-core.h b/include/media/videobuf2-core.h
 index 597efe6..3a92f75 100644
 --- a/include/media/videobuf2-core.h
 +++ b/include/media/videobuf2-core.h
 @@ -225,7 +225,7 @@ struct vb2_ops {
   int (*start_streaming)(struct vb2_queue *q);
   int (*stop_streaming)(struct vb2_queue *q);
 
 - void (*buf_queue)(struct vb2_buffer *vb);
 + int (*buf_queue)(struct vb2_buffer *vb);
  };
 
  /**
 --
 1.7.3.4

Best regards
--
Marek Szyprowski
Samsung Poland RD Center


--
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: [RFC] snapshot mode, flash capabilities and control

Hi Hans,

On Saturday 26 February 2011 14:56:18 Hans Verkuil wrote:
 On Saturday, February 26, 2011 14:39:54 Sylwester Nawrocki wrote:
  On 02/26/2011 02:03 PM, Guennadi Liakhovetski wrote:
   On Sat, 26 Feb 2011, Hans Verkuil wrote:
   On Friday, February 25, 2011 18:08:07 Guennadi Liakhovetski wrote:
   
   snip
   
   configure the sensor to react on an external trigger provided by
   the flash controller is needed, and that could be a control on the
   flash sub-device. What we would probably miss is a way to issue a
   STREAMON with a number of frames to capture. A new ioctl is
   probably needed there. Maybe that would be an opportunity to
   create a new stream-control ioctl that could replace STREAMON and
   STREAMOFF in the long term (we could extend the subdev s_stream
   operation, and easily map STREAMON and STREAMOFF to the new ioctl
   in video_ioctl2 internally).
   
   How would this be different from queueing n frames (in total; count
   dequeueing, too) and issuing streamon? --- Except that when the last
   frame is processed the pipeline could be stopped already before
   issuing STREAMOFF. That does indeed have some benefits. Something
   else?
   
   Well, you usually see in your host driver, that the videobuffer queue
   is empty (no more free buffers are available), so, you stop
   streaming immediately too.
   
   This probably assumes that the host driver knows that this is a
   special queue? Because in general drivers will simply keep capturing
   in the last buffer and not release it to userspace until a new buffer
   is queued.
   
   Yes, I know about this spec requirement, but I also know, that not all
   drivers do that and not everyone is happy about that requirement:)
  
  Right, similarly a v4l2 output device is not releasing the last buffer
  to userland and keeps sending its content until a new buffer is queued to
  the driver. But in case of capture device the requirement is a pain,
  since it only causes draining the power source, when from a user view
  the video capture is stopped. Also it limits a minimum number of buffers
  that could be used in preview pipeline.
 
 No, we can't change this. We can of course add some setting that will
 explicitly request different behavior.
 
 The reason this is done this way comes from the traditional TV/webcam
 viewing apps. If for some reason the app can't keep up with the capture
 rate, then frames should just be dropped silently. All apps assume this
 behavior. In a normal user environment this scenario is perfectly normal
 (e.g. you use a webcam app, then do a CPU intensive make run).

Why couldn't drivers drop frames silently without a capture buffer ? If the 
hardware can be paused, the driver could just do that when the last buffer is 
given back to userspace, and resume the hardware when the next buffer is 
queued.

 I agree that you might want different behavior in an embedded environment,
 but that should be requested explicitly.
 
  In still capture mode (single shot) we might want to use only one buffer
  so adhering to the requirement would not allow this, would it?
 
 That's one of the problems with still capture mode, yes.
 
 I have not yet seen a proposal for this that I really like. Most are too
 specific to this use-case (snapshot) and I'd like to see something more
 general.

I don't think snapshot capture is *that* special. I don't expect most embedded 
SoCs to implement snapshot capture in hardware. What usually happens is that 
the hardware provides some support (like two independent video streams for 
instance, or the ability to capture a given number of frames) and the 
scheduling is performed in userspace. Good quality snapshot capture requires 
complex algorithms and involves several hardware pieces (ISP, flash 
controller, lens controller, ...), so it can't be implemented in the kernel.

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

Sony CXD2099AR support

2011-02-28 Thread Issa Gorissen

Hi,

I have read that this CI chip driver is in staging because some questions on
how to handle it are still not answered.

I volunteer to handle this one. I'm a regular java developer, but I'm willing
to put effort in learning linux drivers writing.

So Ralph, can you give me some pointers on where the discussion should resume
?

Do we put people of Mythtv and VDR in the discussion ? I guess so.

I don't see anything related to MTD in the DVB CSA documents. I guess this
should be left out of the driver.

Thx,
--
Issa 

-- Original Message --
Received: 11:48 AM CET, 02/25/2011
From: Issa Gorissen flo...@usa.net
To: linux-media@vger.kernel.org
Subject: Re: Sony CXD2099AR decryption failing

 Follow up on the trouble with Digital Devices DuoFlex S2, CI, SMIT Viaccess
 CAM and Bis.tv card.
 
 The whole combination works under Windows 7 with Media Center. I have been
 able to watch and change channels I'm entitled to in the Bis.TV package.
Only
 condition was to disable CI for tuner no 2. If the CI is activated for tuner
1
 and tuner 2, Media Center will not be able to change the channels.
 
 Anything I can do to make progress for this issue under linux ?
 
 
 Thx
 --
 Issa

--
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: [st-ericsson] v4l2 vs omx for camera

On Monday 28 February 2011 11:21:52 Hans Verkuil wrote:
 On Monday, February 28, 2011 11:11:47 Laurent Pinchart wrote:
  On Saturday 26 February 2011 13:12:42 Hans Verkuil wrote:
   On Friday, February 25, 2011 18:22:51 Linus Walleij wrote:
2011/2/24 Edward Hervey bilb...@gmail.com:
  What *needs* to be solved is an API for data allocation/passing at 
 the kernel level which v4l2,omx,X,GL,vdpau,vaapi,... can use and
 that userspace (like GStreamer) can pass around, monitor and know
 about.

I think the patches sent out from ST-Ericsson's Johan Mossberg to
linux-mm for HWMEM (hardware memory) deals exactly with buffer
passing, pinning of buffers and so on. The CMA (Contigous Memory
Allocator) has been slightly modified to fit hand-in-glove with
HWMEM, so CMA provides buffers, HWMEM pass them around.

Johan, when you re-spin the HWMEM patchset, can you include
linaro-dev and linux-media in the CC?
   
   Yes, please. This sounds promising and we at linux-media would very
   much like to take a look at this. I hope that the CMA + HWMEM
   combination is exactly what we need.
  
  Once again let me restate what I've been telling for some time: CMA must
  be *optional*. Not all hardware need contiguous memory. I'll have a look
  at the next HWMEM version.
 
 Yes, it is optional when you look at specific hardware. On a kernel level
 however it is functionality that is required in order to support all the
 hardware. There is little point in solving one issue and not the other.

I agree. What I meant is that we need to make sure there's no HWMEM - CMA 
dependency.

-- 
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: ec168-9295d36ab66e compiling error

2011-02-28 Thread Vinicio Nocciolini


On 02/27/2011 07:10 PM, Antti Palosaari wrote:

Dont use my, or anyone else, old HG trees. You should follow that
http://www.linuxtv.org/wiki/index.php/How_to_install_DVB_device_drivers

Antti

On 02/24/2011 04:24 PM, Vinicio Nocciolini wrote:

Hi all

I have problem compiling the project

regards Vinicio

--- 




CC [M] /home/vinicio/Desktop/ec168-9295d36ab66e/v4l/vc032x.o
CC [M] /home/vinicio/Desktop/ec168-9295d36ab66e/v4l/zc3xx.o
CC [M] /home/vinicio/Desktop/ec168-9295d36ab66e/v4l/hdpvr-control.o
CC [M] /home/vinicio/Desktop/ec168-9295d36ab66e/v4l/hdpvr-core.o
CC [M] /home/vinicio/Desktop/ec168-9295d36ab66e/v4l/hdpvr-video.o
CC [M] /home/vinicio/Desktop/ec168-9295d36ab66e/v4l/hopper_cards.o
CC [M] /home/vinicio/Desktop/ec168-9295d36ab66e/v4l/hopper_vp3028.o
CC [M] /home/vinicio/Desktop/ec168-9295d36ab66e/v4l/ir-functions.o
CC [M] /home/vinicio/Desktop/ec168-9295d36ab66e/v4l/ir-keytable.o
/home/vinicio/Desktop/ec168-9295d36ab66e/v4l/ir-keytable.c: In function
'__ir_input_register':
/home/vinicio/Desktop/ec168-9295d36ab66e/v4l/ir-keytable.c:452:24:
warning: assignment from incompatible pointer type
/home/vinicio/Desktop/ec168-9295d36ab66e/v4l/ir-keytable.c:453:24:
warning: assignment from incompatible pointer type
CC [M] /home/vinicio/Desktop/ec168-9295d36ab66e/v4l/ir-sysfs.o
/home/vinicio/Desktop/ec168-9295d36ab66e/v4l/ir-sysfs.c: In function
'ir_register_class':
/home/vinicio/Desktop/ec168-9295d36ab66e/v4l/ir-sysfs.c:268:23: error:
'ir_raw_dev_type' undeclared (first use in this function)
/home/vinicio/Desktop/ec168-9295d36ab66e/v4l/ir-sysfs.c:268:23: note:
each undeclared identifier is reported only once for each function it
appears in
make[3]: *** [/home/vinicio/Desktop/ec168-9295d36ab66e/v4l/ir-sysfs.o]
Error 1
make[2]: *** [_module_/home/vinicio/Desktop/ec168-9295d36ab66e/v4l] 
Error 2

make[2]: Leaving directory `/usr/src/kernels/2.6.35.11-83.fc14.i686'
make[1]: *** [default] Error 2
make[1]: Leaving directory 
`/home/vinicio/Desktop/ec168-9295d36ab66e/v4l'

make: *** [all] Error 2








[vinicio@localhost ec168-9295d36ab66e]$ cat /etc/issue
Fedora release 14 (Laughlin)
Kernel \r on an \m (\l)
--
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








Hi
I have compiled and installed the driver
But I think there is an error
regards Vinicio


[root@localhost ~]# dmesg -c
[  304.598047] usb 1-4: new high speed USB device using ehci_hcd and 
address 5

[  304.712607] usb 1-4: New USB device found, idVendor=18b4, idProduct=1689
[  304.712614] usb 1-4: New USB device strings: Mfr=0, Product=0, 
SerialNumber=0
[  304.715963] input: HID 18b4:1689 as 
/devices/pci:00/:00:1d.7/usb1/1-4/1-4:1.0/input/input10
[  304.716902] generic-usb 0003:18B4:1689.0004: input,hidraw0: USB HID 
v1.11 Keyboard [HID 18b4:1689] on usb-:00:1d.7-4/input0
[  304.74] dvb-usb: found a 'E3C EC168 DVB-T USB2.0 reference 
design' in cold state, will try to load a firmware
[  304.742587] dvb-usb: did not find the firmware file. 
(dvb-usb-ec168.fw) Please see linux/Documentation/dvb/ for more details 
on firmware-problems. (-2)

[  304.742603] dvb_usb_ec168: probe of 1-4:1.1 failed with error -2
--
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: ec168-9295d36ab66e compiling error

2011-02-28 Thread Antti Palosaari


On 02/28/2011 12:37 PM, Vinicio Nocciolini wrote:

[ 304.74] dvb-usb: found a 'E3C EC168 DVB-T USB2.0 reference design'
in cold state, will try to load a firmware
[ 304.742587] dvb-usb: did not find the firmware file.
(dvb-usb-ec168.fw) Please see linux/Documentation/dvb/ for more details
on firmware-problems. (-2)


That error message should be rather clear. Use Google to find correct 
firmware.


Antti


--
http://palosaari.fi/
--
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: [RFC] snapshot mode, flash capabilities and control

On Monday 28 February 2011 11:40:31 Hans Verkuil wrote:
 On Monday, February 28, 2011 11:28:58 Laurent Pinchart wrote:
  On Saturday 26 February 2011 14:56:18 Hans Verkuil wrote:
   On Saturday, February 26, 2011 14:39:54 Sylwester Nawrocki wrote:
On 02/26/2011 02:03 PM, Guennadi Liakhovetski wrote:
 On Sat, 26 Feb 2011, Hans Verkuil wrote:
 On Friday, February 25, 2011 18:08:07 Guennadi Liakhovetski wrote:

[snip]

 Well, you usually see in your host driver, that the videobuffer
 queue is empty (no more free buffers are available), so, you stop
 streaming immediately too.
 
 This probably assumes that the host driver knows that this is a
 special queue? Because in general drivers will simply keep
 capturing in the last buffer and not release it to userspace
 until a new buffer is queued.
 
 Yes, I know about this spec requirement, but I also know, that not
 all drivers do that and not everyone is happy about that
 requirement:)

Right, similarly a v4l2 output device is not releasing the last
buffer to userland and keeps sending its content until a new buffer
is queued to the driver. But in case of capture device the requirement
is a pain, since it only causes draining the power source, when from a
user view the video capture is stopped. Also it limits a minimum
number of buffers that could be used in preview pipeline.
   
   No, we can't change this. We can of course add some setting that will
   explicitly request different behavior.
   
   The reason this is done this way comes from the traditional TV/webcam
   viewing apps. If for some reason the app can't keep up with the capture
   rate, then frames should just be dropped silently. All apps assume this
   behavior. In a normal user environment this scenario is perfectly
   normal (e.g. you use a webcam app, then do a CPU intensive make run).
  
  Why couldn't drivers drop frames silently without a capture buffer ? If
  the hardware can be paused, the driver could just do that when the last
  buffer is given back to userspace, and resume the hardware when the next
  buffer is queued.
 
 It was my understanding that the streaming would stop if no capture buffers
 are available, requiring a VIDIOC_STREAMON to get it started again. Of
 course, there is nothing wrong with stopping the hardware and restarting
 it again when a new buffer becomes available if that can be done
 efficiently enough. Just as long as userspace doesn't notice.
 
 Note that there are some problems with this anyway: often restarting DMA
 requires resyncing to the video stream, which may lead to lost frames.

You'll loose frames when you get a buffer underrun anyway :-)

 Also, the framecounter in struct v4l2_buffer will probably have failed to
 count the lost frames.
 
 In my opinion trying this might cause more problems than it solves.

Whether drivers will hold on the last buffer and keep filling it again and 
again until a new buffer is available, or stop the stream and resume it 
transparently when a new buffer is queued, should probably be left as a choice 
to the drivers. I'm in favour of the second option, but I understand that it 
might be difficult to implement for some hardware. The spec should at least 
not preclude it when efficient hardware support is available.

   I agree that you might want different behavior in an embedded
   environment, but that should be requested explicitly.
   
In still capture mode (single shot) we might want to use only one
buffer so adhering to the requirement would not allow this, would
it?
   
   That's one of the problems with still capture mode, yes.
   
   I have not yet seen a proposal for this that I really like. Most are
   too specific to this use-case (snapshot) and I'd like to see something
   more general.
  
  I don't think snapshot capture is *that* special. I don't expect most
  embedded SoCs to implement snapshot capture in hardware. What usually
  happens is that the hardware provides some support (like two independent
  video streams for instance, or the ability to capture a given number of
  frames) and the scheduling is performed in userspace. Good quality
  snapshot capture requires complex algorithms and involves several
  hardware pieces (ISP, flash controller, lens controller, ...), so it
  can't be implemented in the kernel.
 
 I agree.

-- 
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: [RFC] snapshot mode, flash capabilities and control

On Monday, February 28, 2011 11:28:58 Laurent Pinchart wrote:
 Hi Hans,
 
 On Saturday 26 February 2011 14:56:18 Hans Verkuil wrote:
  On Saturday, February 26, 2011 14:39:54 Sylwester Nawrocki wrote:
   On 02/26/2011 02:03 PM, Guennadi Liakhovetski wrote:
On Sat, 26 Feb 2011, Hans Verkuil wrote:
On Friday, February 25, 2011 18:08:07 Guennadi Liakhovetski wrote:

snip

configure the sensor to react on an external trigger provided by
the flash controller is needed, and that could be a control on the
flash sub-device. What we would probably miss is a way to issue a
STREAMON with a number of frames to capture. A new ioctl is
probably needed there. Maybe that would be an opportunity to
create a new stream-control ioctl that could replace STREAMON and
STREAMOFF in the long term (we could extend the subdev s_stream
operation, and easily map STREAMON and STREAMOFF to the new ioctl
in video_ioctl2 internally).

How would this be different from queueing n frames (in total; count
dequeueing, too) and issuing streamon? --- Except that when the 
last
frame is processed the pipeline could be stopped already before
issuing STREAMOFF. That does indeed have some benefits. Something
else?

Well, you usually see in your host driver, that the videobuffer 
queue
is empty (no more free buffers are available), so, you stop
streaming immediately too.

This probably assumes that the host driver knows that this is a
special queue? Because in general drivers will simply keep capturing
in the last buffer and not release it to userspace until a new buffer
is queued.

Yes, I know about this spec requirement, but I also know, that not all
drivers do that and not everyone is happy about that requirement:)
   
   Right, similarly a v4l2 output device is not releasing the last buffer
   to userland and keeps sending its content until a new buffer is queued 
to
   the driver. But in case of capture device the requirement is a pain,
   since it only causes draining the power source, when from a user view
   the video capture is stopped. Also it limits a minimum number of buffers
   that could be used in preview pipeline.
  
  No, we can't change this. We can of course add some setting that will
  explicitly request different behavior.
  
  The reason this is done this way comes from the traditional TV/webcam
  viewing apps. If for some reason the app can't keep up with the capture
  rate, then frames should just be dropped silently. All apps assume this
  behavior. In a normal user environment this scenario is perfectly normal
  (e.g. you use a webcam app, then do a CPU intensive make run).
 
 Why couldn't drivers drop frames silently without a capture buffer ? If the 
 hardware can be paused, the driver could just do that when the last buffer 
is 
 given back to userspace, and resume the hardware when the next buffer is 
 queued.

It was my understanding that the streaming would stop if no capture buffers 
are available, requiring a VIDIOC_STREAMON to get it started again. Of course, 
there is nothing wrong with stopping the hardware and restarting it again when 
a new buffer becomes available if that can be done efficiently enough. Just as 
long as userspace doesn't notice.

Note that there are some problems with this anyway: often restarting DMA 
requires resyncing to the video stream, which may lead to lost frames. Also, 
the framecounter in struct v4l2_buffer will probably have failed to count the 
lost frames.

In my opinion trying this might cause more problems than it solves.

  I agree that you might want different behavior in an embedded environment,
  but that should be requested explicitly.
  
   In still capture mode (single shot) we might want to use only one buffer
   so adhering to the requirement would not allow this, would it?
  
  That's one of the problems with still capture mode, yes.
  
  I have not yet seen a proposal for this that I really like. Most are too
  specific to this use-case (snapshot) and I'd like to see something more
  general.
 
 I don't think snapshot capture is *that* special. I don't expect most 
embedded 
 SoCs to implement snapshot capture in hardware. What usually happens is that 
 the hardware provides some support (like two independent video streams for 
 instance, or the ability to capture a given number of frames) and the 
 scheduling is performed in userspace. Good quality snapshot capture requires 
 complex algorithms and involves several hardware pieces (ISP, flash 
 controller, lens controller, ...), so it can't be implemented in the kernel.

I agree.

Regards,

Hans

 
 -- 
 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
 
--
To unsubscribe from this list: send the line

Re: Well supported USB DVB-C device?

2011-02-28 Thread Antti Palosaari


On 02/28/2011 11:49 AM, Magnus Alm wrote:

2011/2/28 Antti Palosaaricr...@iki.fi


On 02/28/2011 02:02 AM, Malte Gell wrote:


is there a DVB-C device with USB that is well supported by a recent kernel
(2.6.38)?



Anysee E30 C Plus is supported as far as I know.


It works fine, besides the card reader.


Yes it is working as E30 Combo Plus was too. The aim was try to say that 
you never know when chipset changes and it stops working. Anyhow, I am 
not currently aware that, I am that driver author.


Card reader is not supported in any of the Anysee models.


Antti


--
http://palosaari.fi/
--
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 -resend#1 1/1] V4L: videobuf, don't use dma addr as physical

Hi Jiri,

On Monday 28 February 2011 10:37:02 Jiri Slaby wrote:
 mem-dma_handle is a dma address obtained by dma_alloc_coherent which
 needn't be a physical address in presence of IOMMU. So ensure we are
 remapping (remap_pfn_range) the right page in __videobuf_mmap_mapper
 by using virt_to_phys(mem-vaddr) and not mem-dma_handle.

Quoting arch/arm/include/asm/memory.h,

/*
 * These are *only* valid on the kernel direct mapped RAM memory.
 * Note: Drivers should NOT use these.  They are the wrong
 * translation for translating DMA addresses.  Use the driver
 * DMA support - see dma-mapping.h.
 */
static inline unsigned long virt_to_phys(const volatile void *x)
{
return __virt_to_phys((unsigned long)(x));
}

Why would you use physically contiguous memory if you have an IOMMU anyway ?

 While at it, use PFN_DOWN instead of explicit shift.
 
 Signed-off-by: Jiri Slaby jsl...@suse.cz
 Cc: Mauro Carvalho Chehab mche...@infradead.org
 Cc: Konrad Rzeszutek Wilk konrad.w...@oracle.com
 ---
  drivers/media/video/videobuf-dma-contig.c |2 +-
  1 files changed, 1 insertions(+), 1 deletions(-)
 
 diff --git a/drivers/media/video/videobuf-dma-contig.c
 b/drivers/media/video/videobuf-dma-contig.c index c969111..19d3e4a 100644
 --- a/drivers/media/video/videobuf-dma-contig.c
 +++ b/drivers/media/video/videobuf-dma-contig.c
 @@ -300,7 +300,7 @@ static int __videobuf_mmap_mapper(struct videobuf_queue
 *q,
 
   vma-vm_page_prot = pgprot_noncached(vma-vm_page_prot);
   retval = remap_pfn_range(vma, vma-vm_start,
 -  mem-dma_handle  PAGE_SHIFT,
 +  PFN_DOWN(virt_to_phys(mem-vaddr))
size, vma-vm_page_prot);
   if (retval) {
   dev_err(q-dev, mmap: remap failed with error %d. , retval);

-- 
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: [RFC] snapshot mode, flash capabilities and control

On Mon, 28 Feb 2011, Hans Verkuil wrote:

 On Monday, February 28, 2011 11:28:58 Laurent Pinchart wrote:
  Hi Hans,
  
  On Saturday 26 February 2011 14:56:18 Hans Verkuil wrote:
   On Saturday, February 26, 2011 14:39:54 Sylwester Nawrocki wrote:
On 02/26/2011 02:03 PM, Guennadi Liakhovetski wrote:
 On Sat, 26 Feb 2011, Hans Verkuil wrote:
 On Friday, February 25, 2011 18:08:07 Guennadi Liakhovetski wrote:
 
 snip
 
 configure the sensor to react on an external trigger provided by
 the flash controller is needed, and that could be a control on the
 flash sub-device. What we would probably miss is a way to issue a
 STREAMON with a number of frames to capture. A new ioctl is
 probably needed there. Maybe that would be an opportunity to
 create a new stream-control ioctl that could replace STREAMON and
 STREAMOFF in the long term (we could extend the subdev s_stream
 operation, and easily map STREAMON and STREAMOFF to the new ioctl
 in video_ioctl2 internally).
 
 How would this be different from queueing n frames (in total; count
 dequeueing, too) and issuing streamon? --- Except that when the 
 last
 frame is processed the pipeline could be stopped already before
 issuing STREAMOFF. That does indeed have some benefits. Something
 else?
 
 Well, you usually see in your host driver, that the videobuffer 
 queue
 is empty (no more free buffers are available), so, you stop
 streaming immediately too.
 
 This probably assumes that the host driver knows that this is a
 special queue? Because in general drivers will simply keep capturing
 in the last buffer and not release it to userspace until a new buffer
 is queued.
 
 Yes, I know about this spec requirement, but I also know, that not all
 drivers do that and not everyone is happy about that requirement:)

Right, similarly a v4l2 output device is not releasing the last buffer
to userland and keeps sending its content until a new buffer is queued 
 to
the driver. But in case of capture device the requirement is a pain,
since it only causes draining the power source, when from a user view
the video capture is stopped. Also it limits a minimum number of buffers
that could be used in preview pipeline.
   
   No, we can't change this. We can of course add some setting that will
   explicitly request different behavior.
   
   The reason this is done this way comes from the traditional TV/webcam
   viewing apps. If for some reason the app can't keep up with the capture
   rate, then frames should just be dropped silently. All apps assume this
   behavior. In a normal user environment this scenario is perfectly normal
   (e.g. you use a webcam app, then do a CPU intensive make run).
  
  Why couldn't drivers drop frames silently without a capture buffer ? If the 
  hardware can be paused, the driver could just do that when the last buffer 
 is 
  given back to userspace, and resume the hardware when the next buffer is 
  queued.
 
 It was my understanding that the streaming would stop if no capture buffers 
 are available, requiring a VIDIOC_STREAMON to get it started again. Of 
 course, 
 there is nothing wrong with stopping the hardware and restarting it again 
 when 
 a new buffer becomes available if that can be done efficiently enough. Just 
 as 
 long as userspace doesn't notice.
 
 Note that there are some problems with this anyway: often restarting DMA 
 requires resyncing to the video stream, which may lead to lost frames. Also, 
 the framecounter in struct v4l2_buffer will probably have failed to count the 
 lost frames.
 
 In my opinion trying this might cause more problems than it solves.

So, do I understand it right, that currently there are drivers, that 
overwrite the last buffers while waiting for a new one, and ones, that 
stop capture for that time. None of them violate the spec, but the former 
will not work with the snapshot mode, and the latter will. Since we do 
not want / cannot enforce either way, we do need a way to tell the driver 
to enter the snapshot mode even if only to not overwrite the last 
buffer, right?

   I agree that you might want different behavior in an embedded environment,
   but that should be requested explicitly.
   
In still capture mode (single shot) we might want to use only one buffer
so adhering to the requirement would not allow this, would it?
   
   That's one of the problems with still capture mode, yes.
   
   I have not yet seen a proposal for this that I really like. Most are too
   specific to this use-case (snapshot) and I'd like to see something more
   general.
  
  I don't think snapshot capture is *that* special. I don't expect most 
 embedded 
  SoCs to implement snapshot capture in hardware. What usually happens is 
  that 
  the hardware provides some support (like two independent video streams for 
  instance, or the ability to

[PATCH v20 1/3] MFD: Wl1273 FM radio core: Add I2C IO functions.

Add I2C IO functions.
Change the IO operation from read to write in wl1273_fm_set_volume.
Update the year of the copyright statement.
Remove two unnecessary calls to i2c_set_clientdata.

Signed-off-by: Matti J. Aaltonen matti.j.aalto...@nokia.com
---
 drivers/mfd/Kconfig |2 +-
 drivers/mfd/wl1273-core.c   |  149 ++-
 include/linux/mfd/wl1273-core.h |2 +
 3 files changed, 149 insertions(+), 4 deletions(-)

diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
index fd01836..9db079b 100644
--- a/drivers/mfd/Kconfig
+++ b/drivers/mfd/Kconfig
@@ -615,7 +615,7 @@ config MFD_VX855
  and/or vx855_gpio drivers for this to do anything useful.
 
 config MFD_WL1273_CORE
-   tristate
+   tristate Support for TI WL1273 FM radio.
depends on I2C
select MFD_CORE
default n
diff --git a/drivers/mfd/wl1273-core.c b/drivers/mfd/wl1273-core.c
index d2ecc24..4025a4b 100644
--- a/drivers/mfd/wl1273-core.c
+++ b/drivers/mfd/wl1273-core.c
@@ -1,7 +1,7 @@
 /*
  * MFD driver for wl1273 FM radio and audio codec submodules.
  *
- * Copyright (C) 2010 Nokia Corporation
+ * Copyright (C) 2011 Nokia Corporation
  * Author: Matti Aaltonen matti.j.aalto...@nokia.com
  *
  * This program is free software; you can redistribute it and/or modify
@@ -31,6 +31,145 @@ static struct i2c_device_id wl1273_driver_id_table[] = {
 };
 MODULE_DEVICE_TABLE(i2c, wl1273_driver_id_table);
 
+static int wl1273_fm_read_reg(struct wl1273_core *core, u8 reg, u16 *value)
+{
+   struct i2c_client *client = core-client;
+   u8 b[2];
+   int r;
+
+   r = i2c_smbus_read_i2c_block_data(client, reg, sizeof(b), b);
+   if (r != 2) {
+   dev_err(client-dev, %s: Read: %d fails.\n, __func__, reg);
+   return -EREMOTEIO;
+   }
+
+   *value = (u16)b[0]  8 | b[1];
+
+   return 0;
+}
+
+static int wl1273_fm_write_cmd(struct wl1273_core *core, u8 cmd, u16 param)
+{
+   struct i2c_client *client = core-client;
+   u8 buf[] = { (param  8)  0xff, param  0xff };
+   int r;
+
+   r = i2c_smbus_write_i2c_block_data(client, cmd, sizeof(buf), buf);
+   if (r) {
+   dev_err(client-dev, %s: Cmd: %d fails.\n, __func__, cmd);
+   return r;
+   }
+
+   return 0;
+}
+
+static int wl1273_fm_write_data(struct wl1273_core *core, u8 *data, u16 len)
+{
+   struct i2c_client *client = core-client;
+   struct i2c_msg msg;
+   int r;
+
+   msg.addr = client-addr;
+   msg.flags = 0;
+   msg.buf = data;
+   msg.len = len;
+
+   r = i2c_transfer(client-adapter, msg, 1);
+   if (r != 1) {
+   dev_err(client-dev, %s: write error.\n, __func__);
+   return -EREMOTEIO;
+   }
+
+   return 0;
+}
+
+/**
+ * wl1273_fm_set_audio() - Set audio mode.
+ * @core:  A pointer to the device struct.
+ * @new_mode:  The new audio mode.
+ *
+ * Audio modes are WL1273_AUDIO_DIGITAL and WL1273_AUDIO_ANALOG.
+ */
+static int wl1273_fm_set_audio(struct wl1273_core *core, unsigned int new_mode)
+{
+   int r = 0;
+
+   if (core-mode == WL1273_MODE_OFF ||
+   core-mode == WL1273_MODE_SUSPENDED)
+   return -EPERM;
+
+   if (core-mode == WL1273_MODE_RX  new_mode == WL1273_AUDIO_DIGITAL) {
+   r = wl1273_fm_write_cmd(core, WL1273_PCM_MODE_SET,
+   WL1273_PCM_DEF_MODE);
+   if (r)
+   goto out;
+
+   r = wl1273_fm_write_cmd(core, WL1273_I2S_MODE_CONFIG_SET,
+   core-i2s_mode);
+   if (r)
+   goto out;
+
+   r = wl1273_fm_write_cmd(core, WL1273_AUDIO_ENABLE,
+   WL1273_AUDIO_ENABLE_I2S);
+   if (r)
+   goto out;
+
+   } else if (core-mode == WL1273_MODE_RX 
+  new_mode == WL1273_AUDIO_ANALOG) {
+   r = wl1273_fm_write_cmd(core, WL1273_AUDIO_ENABLE,
+   WL1273_AUDIO_ENABLE_ANALOG);
+   if (r)
+   goto out;
+
+   } else if (core-mode == WL1273_MODE_TX 
+  new_mode == WL1273_AUDIO_DIGITAL) {
+   r = wl1273_fm_write_cmd(core, WL1273_I2S_MODE_CONFIG_SET,
+   core-i2s_mode);
+   if (r)
+   goto out;
+
+   r = wl1273_fm_write_cmd(core, WL1273_AUDIO_IO_SET,
+   WL1273_AUDIO_IO_SET_I2S);
+   if (r)
+   goto out;
+
+   } else if (core-mode == WL1273_MODE_TX 
+  new_mode == WL1273_AUDIO_ANALOG) {
+   r = wl1273_fm_write_cmd(core, WL1273_AUDIO_IO_SET,
+   WL1273_AUDIO_IO_SET_ANALOG);
+   if (r)
+

[PATCH v20 2/3] V4L2: Wl1273 FM Radio: Remove I2C IO functions.

Remove I2C IO functions. After refactoring they currently
belong to the Wl1273 MFD driver. And now the IO functions
are accessed through pointers. Update the year in the
copyright statement.

Signed-off-by: Matti J. Aaltonen matti.j.aalto...@nokia.com
---
 drivers/media/radio/radio-wl1273.c |  360 +++-
 1 files changed, 106 insertions(+), 254 deletions(-)

diff --git a/drivers/media/radio/radio-wl1273.c 
b/drivers/media/radio/radio-wl1273.c
index 7ecc8e6..9e177dc 100644
--- a/drivers/media/radio/radio-wl1273.c
+++ b/drivers/media/radio/radio-wl1273.c
@@ -1,7 +1,7 @@
 /*
  * Driver for the Texas Instruments WL1273 FM radio.
  *
- * Copyright (C) 2010 Nokia Corporation
+ * Copyright (C) 2011 Nokia Corporation
  * Author: Matti J. Aaltonen matti.j.aalto...@nokia.com
  *
  * This program is free software; you can redistribute it and/or
@@ -104,58 +104,6 @@ static unsigned int rds_buf = 100;
 module_param(rds_buf, uint, 0);
 MODULE_PARM_DESC(rds_buf, Number of RDS buffer entries. Default = 100);
 
-static int wl1273_fm_read_reg(struct wl1273_core *core, u8 reg, u16 *value)
-{
-   struct i2c_client *client = core-client;
-   u8 b[2];
-   int r;
-
-   r = i2c_smbus_read_i2c_block_data(client, reg, sizeof(b), b);
-   if (r != 2) {
-   dev_err(client-dev, %s: Read: %d fails.\n, __func__, reg);
-   return -EREMOTEIO;
-   }
-
-   *value = (u16)b[0]  8 | b[1];
-
-   return 0;
-}
-
-static int wl1273_fm_write_cmd(struct wl1273_core *core, u8 cmd, u16 param)
-{
-   struct i2c_client *client = core-client;
-   u8 buf[] = { (param  8)  0xff, param  0xff };
-   int r;
-
-   r = i2c_smbus_write_i2c_block_data(client, cmd, sizeof(buf), buf);
-   if (r) {
-   dev_err(client-dev, %s: Cmd: %d fails.\n, __func__, cmd);
-   return r;
-   }
-
-   return 0;
-}
-
-static int wl1273_fm_write_data(struct wl1273_core *core, u8 *data, u16 len)
-{
-   struct i2c_client *client = core-client;
-   struct i2c_msg msg;
-   int r;
-
-   msg.addr = client-addr;
-   msg.flags = 0;
-   msg.buf = data;
-   msg.len = len;
-
-   r = i2c_transfer(client-adapter, msg, 1);
-   if (r != 1) {
-   dev_err(client-dev, %s: write error.\n, __func__);
-   return -EREMOTEIO;
-   }
-
-   return 0;
-}
-
 static int wl1273_fm_write_fw(struct wl1273_core *core,
  __u8 *fw, int len)
 {
@@ -188,94 +136,6 @@ static int wl1273_fm_write_fw(struct wl1273_core *core,
return r;
 }
 
-/**
- * wl1273_fm_set_audio() - Set audio mode.
- * @core:  A pointer to the device struct.
- * @new_mode:  The new audio mode.
- *
- * Audio modes are WL1273_AUDIO_DIGITAL and WL1273_AUDIO_ANALOG.
- */
-static int wl1273_fm_set_audio(struct wl1273_core *core, unsigned int new_mode)
-{
-   int r = 0;
-
-   if (core-mode == WL1273_MODE_OFF ||
-   core-mode == WL1273_MODE_SUSPENDED)
-   return -EPERM;
-
-   if (core-mode == WL1273_MODE_RX  new_mode == WL1273_AUDIO_DIGITAL) {
-   r = wl1273_fm_write_cmd(core, WL1273_PCM_MODE_SET,
-   WL1273_PCM_DEF_MODE);
-   if (r)
-   goto out;
-
-   r = wl1273_fm_write_cmd(core, WL1273_I2S_MODE_CONFIG_SET,
-   core-i2s_mode);
-   if (r)
-   goto out;
-
-   r = wl1273_fm_write_cmd(core, WL1273_AUDIO_ENABLE,
-   WL1273_AUDIO_ENABLE_I2S);
-   if (r)
-   goto out;
-
-   } else if (core-mode == WL1273_MODE_RX 
-  new_mode == WL1273_AUDIO_ANALOG) {
-   r = wl1273_fm_write_cmd(core, WL1273_AUDIO_ENABLE,
-   WL1273_AUDIO_ENABLE_ANALOG);
-   if (r)
-   goto out;
-
-   } else if (core-mode == WL1273_MODE_TX 
-  new_mode == WL1273_AUDIO_DIGITAL) {
-   r = wl1273_fm_write_cmd(core, WL1273_I2S_MODE_CONFIG_SET,
-   core-i2s_mode);
-   if (r)
-   goto out;
-
-   r = wl1273_fm_write_cmd(core, WL1273_AUDIO_IO_SET,
-   WL1273_AUDIO_IO_SET_I2S);
-   if (r)
-   goto out;
-
-   } else if (core-mode == WL1273_MODE_TX 
-  new_mode == WL1273_AUDIO_ANALOG) {
-   r = wl1273_fm_write_cmd(core, WL1273_AUDIO_IO_SET,
-   WL1273_AUDIO_IO_SET_ANALOG);
-   if (r)
-   goto out;
-   }
-
-   core-audio_mode = new_mode;
-out:
-   return r;
-}
-
-/**
- * wl1273_fm_set_volume() -Set volume.
- * @core:  A pointer to the device struct.
- *

[PATCH v20 3/3] ASoC: WL1273 FM radio: Access I2C IO functions through pointers.

These changes are needed to keep up with the changes in the
MFD core and V4L2 parts of the wl1273 FM radio driver.

Use function pointers instead of exported functions for I2C IO.
Also move all preprocessor constants from the wl1273.h to
include/linux/mfd/wl1273-core.h.

Also update the year in the copyright statement.

Signed-off-by: Matti J. Aaltonen matti.j.aalto...@nokia.com
---
 sound/soc/codecs/Kconfig  |2 +-
 sound/soc/codecs/wl1273.c |   11 ---
 2 files changed, 9 insertions(+), 4 deletions(-)

diff --git a/sound/soc/codecs/Kconfig b/sound/soc/codecs/Kconfig
index c48b23c..9726d6e 100644
--- a/sound/soc/codecs/Kconfig
+++ b/sound/soc/codecs/Kconfig
@@ -44,7 +44,7 @@ config SND_SOC_ALL_CODECS
select SND_SOC_TWL6040 if TWL4030_CORE
select SND_SOC_UDA134X
select SND_SOC_UDA1380 if I2C
-   select SND_SOC_WL1273 if RADIO_WL1273
+   select SND_SOC_WL1273 if MFD_WL1273_CORE
select SND_SOC_WM2000 if I2C
select SND_SOC_WM8350 if MFD_WM8350
select SND_SOC_WM8400 if MFD_WM8400
diff --git a/sound/soc/codecs/wl1273.c b/sound/soc/codecs/wl1273.c
index 861b28f..3c27fed 100644
--- a/sound/soc/codecs/wl1273.c
+++ b/sound/soc/codecs/wl1273.c
@@ -3,7 +3,7 @@
  *
  * Author:  Matti Aaltonen, matti.j.aalto...@nokia.com
  *
- * Copyright:   (C) 2010 Nokia Corporation
+ * Copyright:   (C) 2011 Nokia Corporation
  *
  * This program is free software; you can redistribute it and/or
  * modify it under the terms of the GNU General Public License
@@ -179,7 +179,12 @@ static int snd_wl1273_get_audio_route(struct snd_kcontrol 
*kcontrol,
return 0;
 }
 
-static const char *wl1273_audio_route[] = { Bt, FmRx, FmTx };
+/*
+ * TODO: Implement the audio routing in the driver. Now this control
+ * only indicates the setting that has been done elsewhere (in the user
+ * space).
+ */
+static const char * const wl1273_audio_route[] = { Bt, FmRx, FmTx };
 
 static int snd_wl1273_set_audio_route(struct snd_kcontrol *kcontrol,
  struct snd_ctl_elem_value *ucontrol)
@@ -239,7 +244,7 @@ static int snd_wl1273_fm_audio_put(struct snd_kcontrol 
*kcontrol,
return 1;
 }
 
-static const char *wl1273_audio_strings[] = { Digital, Analog };
+static const char * const wl1273_audio_strings[] = { Digital, Analog };
 
 static const struct soc_enum wl1273_audio_enum =
SOC_ENUM_SINGLE_EXT(ARRAY_SIZE(wl1273_audio_strings),
-- 
1.6.1.3

--
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 v20 0/3] ASoC/MFD/V4L2: WL1273 FM Radio driver

Hello.

And thanks for the comments. If we now move quickly enough we can
get this thing in before it becomes deprecated...

Samuel wrote:
 for Mauro to take this one you'd have to provide a
 diff against the already existing wl1273-core.

I've made these patches against the existing stuff.

 + * Copyright (C) 2010 Nokia Corporation
2011.

Changed.

 +}
 I'm confused with this one: Isn't WL1273_VOLUME_SET a command ? Also,
 how can reading from it set the volume ?

It cannot... so I've changed it (back) to write.

 + i2c_set_clientdata(client, NULL)
Not needed.

Removed.

 +err:
 + i2c_set_clientdata(client, NULL);
Ditto.

Ditto.

Cheers,
Matti

Matti J. Aaltonen (3):
  MFD: Wl1273 FM radio core: Add I2C IO functions.
  V4L2: Wl1273 FM Radio: Remove I2C IO functions.
  ASoC: WL1273 FM radio: Access I2C IO functions through pointers.

 drivers/media/radio/radio-wl1273.c |  360 +++-
 drivers/mfd/Kconfig|2 +-
 drivers/mfd/wl1273-core.c  |  149 +++-
 include/linux/mfd/wl1273-core.h|2 +
 sound/soc/codecs/Kconfig   |2 +-
 sound/soc/codecs/wl1273.c  |   11 +-
 6 files changed, 264 insertions(+), 262 deletions(-)

--
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: [RFC] snapshot mode, flash capabilities and control

Hi Guennadi,

On Monday 28 February 2011 12:02:41 Guennadi Liakhovetski wrote:
 On Mon, 28 Feb 2011, Hans Verkuil wrote:
  On Monday, February 28, 2011 11:28:58 Laurent Pinchart wrote:
   On Saturday 26 February 2011 14:56:18 Hans Verkuil wrote:
On Saturday, February 26, 2011 14:39:54 Sylwester Nawrocki wrote:
 On 02/26/2011 02:03 PM, Guennadi Liakhovetski wrote:
  On Sat, 26 Feb 2011, Hans Verkuil wrote:
  On Friday, February 25, 2011 18:08:07 Guennadi Liakhovetski
  wrote:
  
  snip
  
  configure the sensor to react on an external trigger provided
  by the flash controller is needed, and that could be a
  control on the flash sub-device. What we would probably miss
  is a way to issue a STREAMON with a number of frames to
  capture. A new ioctl is probably needed there. Maybe that
  would be an opportunity to create a new stream-control ioctl
  that could replace STREAMON and STREAMOFF in the long term
  (we could extend the subdev s_stream operation, and easily
  map STREAMON and STREAMOFF to the new ioctl in video_ioctl2
  internally).
  
  How would this be different from queueing n frames (in total;
  count dequeueing, too) and issuing streamon? --- Except that
  when the last frame is processed the pipeline could be stopped
  already before issuing STREAMOFF. That does indeed have some
  benefits. Something else?
  
  Well, you usually see in your host driver, that the videobuffer
  queue is empty (no more free buffers are available), so, you
  stop streaming immediately too.
  
  This probably assumes that the host driver knows that this is a
  special queue? Because in general drivers will simply keep
  capturing in the last buffer and not release it to userspace
  until a new buffer is queued.
  
  Yes, I know about this spec requirement, but I also know, that
  not all drivers do that and not everyone is happy about that
  requirement:)
 
 Right, similarly a v4l2 output device is not releasing the last
 buffer to userland and keeps sending its content until a new
 buffer is queued to the driver. But in case of capture device the
 requirement is a pain, since it only causes draining the power
 source, when from a user view the video capture is stopped. Also it
 limits a minimum number of buffers that could be used in preview
 pipeline.

No, we can't change this. We can of course add some setting that will
explicitly request different behavior.

The reason this is done this way comes from the traditional TV/webcam
viewing apps. If for some reason the app can't keep up with the
capture rate, then frames should just be dropped silently. All apps
assume this behavior. In a normal user environment this scenario is
perfectly normal (e.g. you use a webcam app, then do a CPU intensive
make run).
   
   Why couldn't drivers drop frames silently without a capture buffer ? If
   the hardware can be paused, the driver could just do that when the
   last buffer is given back to userspace, and resume the hardware when the
   next buffer is queued.
  
  It was my understanding that the streaming would stop if no capture
  buffers are available, requiring a VIDIOC_STREAMON to get it started
  again. Of course, there is nothing wrong with stopping the hardware and
  restarting it again when a new buffer becomes available if that can be
  done efficiently enough. Just as long as userspace doesn't notice.
  
  Note that there are some problems with this anyway: often restarting DMA
  requires resyncing to the video stream, which may lead to lost frames.
  Also, the framecounter in struct v4l2_buffer will probably have failed
  to count the lost frames.
  
  In my opinion trying this might cause more problems than it solves.
 
 So, do I understand it right, that currently there are drivers, that
 overwrite the last buffers while waiting for a new one, and ones, that
 stop capture for that time. None of them violate the spec, but the former
 will not work with the snapshot mode, and the latter will. Since we do
 not want / cannot enforce either way, we do need a way to tell the driver
 to enter the snapshot mode even if only to not overwrite the last
 buffer, right?
 
I agree that you might want different behavior in an embedded
environment, but that should be requested explicitly.

 In still capture mode (single shot) we might want to use only one
 buffer so adhering to the requirement would not allow this, would
 it?

That's one of the problems with still capture mode, yes.

I have not yet seen a proposal for this that I really like. Most are
too specific to this use-case (snapshot) and I'd like to see
something more general.
   
   I don't think snapshot capture is *that* special. I don't expect most
   embedded SoCs to implement snapshot capture in

Re: ec168-9295d36ab66e compiling error

2011-02-28 Thread Vinicio Nocciolini


On 02/28/2011 11:39 AM, Antti Palosaari wrote:

On 02/28/2011 12:37 PM, Vinicio Nocciolini wrote:

[ 304.74] dvb-usb: found a 'E3C EC168 DVB-T USB2.0 reference design'
in cold state, will try to load a firmware
[ 304.742587] dvb-usb: did not find the firmware file.
(dvb-usb-ec168.fw) Please see linux/Documentation/dvb/ for more details
on firmware-problems. (-2)


That error message should be rather clear. Use Google to find correct 
firmware.


Antti




root@localhost ~]# w_scan -c IT
w_scan version 20110206 (compiled for DVB API 5.2)
using settings for SPAIN
DVB aerial
DVB-T Europe
frontend_type DVB-T, channellist 4
output format vdr-1.6
Info: using DVB adapter auto detection.
main:3030: FATAL: * NO USEABLE DVB CARD FOUND. *
Please check wether dvb driver is loaded and
verify that no dvb application (i.e. vdr) is running.
--
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: [RFC] snapshot mode, flash capabilities and control

On Monday, February 28, 2011 12:07:33 Laurent Pinchart wrote:
 Hi Guennadi,
 
 On Monday 28 February 2011 12:02:41 Guennadi Liakhovetski wrote:
  On Mon, 28 Feb 2011, Hans Verkuil wrote:
   On Monday, February 28, 2011 11:28:58 Laurent Pinchart wrote:
On Saturday 26 February 2011 14:56:18 Hans Verkuil wrote:
 On Saturday, February 26, 2011 14:39:54 Sylwester Nawrocki wrote:
  On 02/26/2011 02:03 PM, Guennadi Liakhovetski wrote:
   On Sat, 26 Feb 2011, Hans Verkuil wrote:
   On Friday, February 25, 2011 18:08:07 Guennadi Liakhovetski
   wrote:
   
   snip
   
   configure the sensor to react on an external trigger 
provided
   by the flash controller is needed, and that could be a
   control on the flash sub-device. What we would probably miss
   is a way to issue a STREAMON with a number of frames to
   capture. A new ioctl is probably needed there. Maybe that
   would be an opportunity to create a new stream-control ioctl
   that could replace STREAMON and STREAMOFF in the long term
   (we could extend the subdev s_stream operation, and easily
   map STREAMON and STREAMOFF to the new ioctl in video_ioctl2
   internally).
   
   How would this be different from queueing n frames (in total;
   count dequeueing, too) and issuing streamon? --- Except that
   when the last frame is processed the pipeline could be 
stopped
   already before issuing STREAMOFF. That does indeed have some
   benefits. Something else?
   
   Well, you usually see in your host driver, that the 
videobuffer
   queue is empty (no more free buffers are available), so, you
   stop streaming immediately too.
   
   This probably assumes that the host driver knows that this is a
   special queue? Because in general drivers will simply keep
   capturing in the last buffer and not release it to userspace
   until a new buffer is queued.
   
   Yes, I know about this spec requirement, but I also know, that
   not all drivers do that and not everyone is happy about that
   requirement:)
  
  Right, similarly a v4l2 output device is not releasing the last
  buffer to userland and keeps sending its content until a new
  buffer is queued to the driver. But in case of capture device the
  requirement is a pain, since it only causes draining the power
  source, when from a user view the video capture is stopped. Also 
it
  limits a minimum number of buffers that could be used in preview
  pipeline.
 
 No, we can't change this. We can of course add some setting that 
will
 explicitly request different behavior.
 
 The reason this is done this way comes from the traditional 
TV/webcam
 viewing apps. If for some reason the app can't keep up with the
 capture rate, then frames should just be dropped silently. All apps
 assume this behavior. In a normal user environment this scenario is
 perfectly normal (e.g. you use a webcam app, then do a CPU intensive
 make run).

Why couldn't drivers drop frames silently without a capture buffer ? 
If
the hardware can be paused, the driver could just do that when the
last buffer is given back to userspace, and resume the hardware when 
the
next buffer is queued.
   
   It was my understanding that the streaming would stop if no capture
   buffers are available, requiring a VIDIOC_STREAMON to get it started
   again. Of course, there is nothing wrong with stopping the hardware and
   restarting it again when a new buffer becomes available if that can be
   done efficiently enough. Just as long as userspace doesn't notice.
   
   Note that there are some problems with this anyway: often restarting DMA
   requires resyncing to the video stream, which may lead to lost frames.
   Also, the framecounter in struct v4l2_buffer will probably have failed
   to count the lost frames.
   
   In my opinion trying this might cause more problems than it solves.
  
  So, do I understand it right, that currently there are drivers, that
  overwrite the last buffers while waiting for a new one, and ones, that
  stop capture for that time.

Does anyone know which drivers stop capture if there are no buffers available? 
I'm not aware of any.

  None of them violate the spec, but the former
  will not work with the snapshot mode, and the latter will. Since we do
  not want / cannot enforce either way, we do need a way to tell the driver
  to enter the snapshot mode even if only to not overwrite the last
  buffer, right?
  
 I agree that you might want different behavior in an embedded
 environment, but that should be requested explicitly.
 
  In still capture mode (single shot) we might want to use only one
  buffer so adhering to the requirement would not allow this, would
  it?
 
 That's one of the problems with still capture mode, yes.
 
 I have not yet

Re: [RFC] snapshot mode, flash capabilities and control

On Monday 28 February 2011 12:17:12 Hans Verkuil wrote:
 On Monday, February 28, 2011 12:07:33 Laurent Pinchart wrote:
  On Monday 28 February 2011 12:02:41 Guennadi Liakhovetski wrote:
   On Mon, 28 Feb 2011, Hans Verkuil wrote:

[snip]

It was my understanding that the streaming would stop if no capture
buffers are available, requiring a VIDIOC_STREAMON to get it started
again. Of course, there is nothing wrong with stopping the hardware
and restarting it again when a new buffer becomes available if that
can be done efficiently enough. Just as long as userspace doesn't
notice.

Note that there are some problems with this anyway: often restarting
DMA requires resyncing to the video stream, which may lead to lost
frames. Also, the framecounter in struct v4l2_buffer will probably
have failed to count the lost frames.

In my opinion trying this might cause more problems than it solves.
   
   So, do I understand it right, that currently there are drivers, that
   overwrite the last buffers while waiting for a new one, and ones, that
   stop capture for that time.
 
 Does anyone know which drivers stop capture if there are no buffers
 available? I'm not aware of any.

Do you mean stop capture in a way that requires an explicit VIDIOC_STREAMON ? 
None that I'm aware of (and I think that would violate the spec). If you 
instead mean pause capture and restart it on the next VIDIOC_QBUF, uvcvideo 
(somehow) does that, and the OMAP3 ISP does as well.

   None of them violate the spec, but the former will not work with the
   snapshot mode, and the latter will. Since we do not want / cannot
   enforce either way, we do need a way to tell the driver to enter the
   snapshot mode even if only to not overwrite the last buffer, right?

[snip]

   Right, but sensors do need it. It is not enough to just tell the sensor
   - a per-frame flash is used and let the driver figure out, that it has
   to switch to snapshot mode. The snapshot mode has other effects too,
   e.g., on some sensors it enables the external trigger pin, which some
   designs might want to use also without a flash. Maybe there are also
   some other side effects of such snapshot modes on some other sensors,
   that I'm not aware of.
  
  This makes me wonder if we need a snapshot mode at all. Why should we tie
  flash, capture trigger (and other such options that you're not aware of
  yet :-)) together under a single high-level control (in the general sense,
  not to be strictly taken as a V4L2 CID) ? Wouldn't it be better to expose
  those features individually instead ? User might want to use the flash in
  video capture mode for a stroboscopic effect for instance.
 
 I think this is certainly a good initial approach.
 
 Can someone make a list of things needed for flash/snapshot? So don't look
 yet at the implementation, but just start a list of functionalities that
 we need to support. I don't think I have seen that yet.

That's the right approach. I'll ping people internally to see if we have such 
a list already.

-- 
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: [RFC] snapshot mode, flash capabilities and control

On Sun, 27 Feb 2011, Sakari Ailus wrote:

Hi,

Guennadi Liakhovetski wrote:
On Fri, 25 Feb 2011, Sakari Ailus wrote:

Hi Guennadi,

Guennadi Liakhovetski wrote:
In principle - yes, and yes, I do realise, that the couple of controls,
that I've proposed only cover a very minor subset of the whole flash
function palette. The purposes of my RFC were:

Why would there be a different interface for controlling the flash in
simple cases and more complex cases?

Sorry, not sure what you mean. Do you mean different APIs when the flash
is controlled directly by the sensor and by an external controller? No, of
course we need one API, but you either issue those ioctl()s to the sensor
(sub)device, or to the dedicated flash (sub)device. If you mean my minor
subset above, then I was trying to say, that this is a basis, that has to
be extended, but not, that we will develop a new API for more complicated
cases.

I think I misunderstood you originally, sorry. I should have properly read the
RFC. :-)

Your proposal of the flash mode is good, but what about software strobe (a
little more on that below)?

Also, what about making this a V4L2 control instead?

These are two things, I think: first we have to decide which functions we
need, second - how to implement them. Sure, controls are also a
possibility.

The ADP1653 driver that
Laurent referred to implements flash control using V4L2 controls only.

A version of the driver is here:

URL:http://gitorious.org/omap3camera/mainline/commit/a41027c857dfcbc268cf8d1c7c7d0ab8b6abac92

It's not yet in mainline --- one reason for this is the lack of time to
discuss a proper API for the flash. :-)

...

This doesn't solve the flash/capture synchronization problem though. I
don't
think we need a dedicated snapshot capture mode at the V4L2 level. A
way to
configure the sensor to react on an external trigger provided by the
flash
controller is needed, and that could be a control on the flash
sub-device.

Well... Sensors call this a snapshot mode. I don't care that much how
we
_call_ it, but I do think, that we should be able to use it.

Some sensors and webcams might have that, but newer camera solutions
tend to contain a raw bayer sensor and and ISP. There is no concept of
snapsnot mode in these sensors.

Hm, I am not sure I understand, why sensors with DSPs in them should have
no notion of a snapshot mode. Do they have no strobe / trigger pins? And
no built in possibility to synchronize with a flash?

I was referring to ISPs such as the OMAP 3 ISP. Some hardware have a flash
strobe pin while some doesn't (such as the N900).

Of course, if no flash is present, you don't have to support it;)

Still, even if the strobe pin is missing it should be possible to allow
strobing the flash by using software strobe (usually an I2C message).

I agree using a hardware strobe is much much better if it's available.

Again - don't understand. Above (i2c message) you're referring to the
sensor. But I don't think toggling the flash on per-frame basis from
software via the sensor makes much sense. That way you could also just
wire your flash to a GPIO. The main advantage of a sensor-controlled flash
is, that is toggles the flash automatically, synchronised with its image
read-out. You would, however, toggle the flash manually, if you just
wanted to turn it on permanently (torch-mode).

Hm, don't think only the flash subdevice has to know about this.
First,
you have to switch the sensor into that mode. Second, it might be either
external trigger from the flash controller, or a programmed trigger and
a
flash strobe from the sensor to the flash (controller). Third, well, not
quite sure, but doesn't the host have to know about the snapshot mode?

I do not favour adding use case type of functionality to interfaces that
do not necessarily need it. Would the concept of a snapshot be
parametrisable on V4L2 level?

I am open to this. I don't have a good idea of whether camera hosts have
to know about the snapshot mode or not. It's open for discussion.

What functionality would the snapshot mode provide? Flash synchronisation?
Something else?

Also pre-defined number of images, enabling of the trigger pin and trigger
i2c command. Just noticed - on mt9t031 and mt9v022 the snapshot mode also
enables externally controlled exposure...

I have to admit I don't know of any hardware which would recognise a concept
of snapshot. Do you have a smart sensor which does this, for example? The
only hardware support for the flash use I know of is the flash strobe signal.

Several Aptina / Micron sensors have such a mode, e.g., mt9p031, mt9t031,
mt9v022, mt9m001, also ov7725 from OmniVision (there it's called a Single
frame mode), and, I presume, many others. And no, those are not some
smart sensors, the ones from

[DVB] Maintainers of dvb_core and budget_ci modules - Patches proposal

2011-02-28 Thread COEXSI

Dear all,

Are-there some maintainers for the dvb_core module and the budget_ci module
on the linux-media mailing list?

I would like to discuss and submit some patches I have developed for these
modules:
- dvb_core: add an option for logging the PDU exchanged with the CAM for
debugging purposes
- dvb_core: clean all ring buffers associated with CAM when a device is
opened
- budget_ci: print information about CI firmware used
- budget_ci: add module option for disabling the IR receiver and the IRQ
mode

Best regards,
Sebastien.




--
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] Prof 7301: switching frontend to stv090x, fixing LOCK FAILED issue


On 2011-01-16 21:44, Mariusz Bialonczyk wrote:

Fixing the very annoying tunning issue. When switching from DVB-S2 to DVB-S,
it often took minutes to have a lock.

 [...]

The patch is changing the frontend from stv0900 to stv090x.
The card now works much more reliable. There is no problem with switching
from DVB-S2 to DVB-S, tunning works flawless.


Igor, can I get your ACK on this patch?

regards,
--
Mariusz Bialonczyk
jabber/e-mail: ma...@skyboo.net
http://manio.skyboo.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: [RFC] snapshot mode, flash capabilities and control

On Mon, 28 Feb 2011, Laurent Pinchart wrote:

I don't think snapshot capture is *that* special. I don't expect most
embedded SoCs to implement snapshot capture in hardware. What usually
happens is that the hardware provides some support (like two independent
video streams for instance, or the ability to capture a given number of
frames) and the scheduling is performed in userspace. Good quality
snapshot capture requires complex algorithms and involves several
hardware pieces (ISP, flash controller, lens controller, ...), so it
can't be implemented in the kernel.
   
   I agree.
  
  Right, but sensors do need it. It is not enough to just tell the sensor -
  a per-frame flash is used and let the driver figure out, that it has to
  switch to snapshot mode. The snapshot mode has other effects too, e.g., on
  some sensors it enables the external trigger pin, which some designs might
  want to use also without a flash. Maybe there are also some other side
  effects of such snapshot modes on some other sensors, that I'm not aware
  of.
 
 This makes me wonder if we need a snapshot mode at all. Why should we tie 
 flash, capture trigger (and other such options that you're not aware of yet 
 :-)) together under a single high-level control (in the general sense, not to 
 be strictly taken as a V4L2 CID) ? Wouldn't it be better to expose those 
 features individually instead ? User might want to use the flash in video 
 capture mode for a stroboscopic effect for instance.

So, you'd also need a separate control for external exposure, there are 
also sensors, that can be configured to different shutter / exposure / 
readout sequence controlling... No, we don't have to support all that 
variety, but we have to be aware of it, while making decisions;)

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

Re: [PATCH] Prof 7301: switching frontend to stv090x, fixing LOCK FAILED issue


Tested-by: Michal Wegrzynek michal.wegrzy...@malloc.com.pl
--
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: [RFC] snapshot mode, flash capabilities and control

On Mon, 28 Feb 2011, Hans Verkuil wrote:

 Does anyone know which drivers stop capture if there are no buffers 
 available? 
 I'm not aware of any.

Many soc-camera hosts do that.

 I think this is certainly a good initial approach.
 
 Can someone make a list of things needed for flash/snapshot? So don't look 
 yet 
 at the implementation, but just start a list of functionalities that we need 
 to support. I don't think I have seen that yet.

These are not the features, that we _have_ to implement, these are just 
the ones, that are related to the snapshot mode:

* flash strobe (provided, we do not want to control its timing from 
generic controls, and leave that to reasonable defaults or to 
private controls)
* trigger pin / command
* external exposure
* exposure mode (ERS, GRR,...)
* use trigger or shutter for readout
* number of frames to capture

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

Re: [RFC] snapshot mode, flash capabilities and control

On Fri, 25 Feb 2011, Guennadi Liakhovetski wrote:

 On Fri, 25 Feb 2011, Sakari Ailus wrote:
 
  On Fri, Feb 25, 2011 at 06:08:07PM +0100, Guennadi Liakhovetski wrote:
  
   What we could also do, we could add an optional callback to subdev 
   (core?) 
   operations, which, if activated, the host would call on each frame 
   completion.
  
  It's not quite that simple. The exposure of the next frame has started long
  time before that. This requires much more thought probably --- in the case
  of lack of hardware support, when the parameters need to be actually given
  to the sensor depend somewhat on sensors, I suppose.
 
 Yes, that's right. I seem to remember, there was a case, for which such a 
 callback would have been useful... Don't remember what that was though.

I remember now:) I meant to use it to trigger the next frame from the 
software per sensor I2C command, if no hardware trigger is available.

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

Re: Well supported USB DVB-C device?

2011-02-28 Thread Malte Gell


Antti Palosaari cr...@iki.fi wrote

 On 02/28/2011 02:02 AM, Malte Gell wrote:
  is there a DVB-C device with USB that is well supported by a recent
  kernel (2.6.38)?

I have found a device from Terratec, the Terratec H7. They have published a 
driver for this device at 
http://linux.terratec.de/files/TERRATEC_H7_Linux.tar.gz

So I think, I will try this device when I have figured out, how their kernel 
modules is to be built.

Malte
--
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: [RFC] snapshot mode, flash capabilities and control

2011-02-28 Thread Sakari Ailus

On Mon, Feb 28, 2011 at 12:37:06PM +0100, Guennadi Liakhovetski wrote:
 So, you'd also need a separate control for external exposure, there are 
 also sensors, that can be configured to different shutter / exposure / 
 readout sequence controlling... No, we don't have to support all that 
 variety, but we have to be aware of it, while making decisions;)

Hi Guennadi,

Do you mean that there are sensors that can synchronise these parameters at
frame level, or how? There are use cases for that but it doesn't limit to
still capture.

Are there any public datasheets that you know of on these?

Regards,

-- 
Sakari Ailus
sakari dot ailus at iki dot fi
--
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: [RFC] snapshot mode, flash capabilities and control

On Mon, 28 Feb 2011, Sakari Ailus wrote:

 On Mon, Feb 28, 2011 at 12:37:06PM +0100, Guennadi Liakhovetski wrote:
  So, you'd also need a separate control for external exposure, there are 
  also sensors, that can be configured to different shutter / exposure / 
  readout sequence controlling... No, we don't have to support all that 
  variety, but we have to be aware of it, while making decisions;)
 
 Hi Guennadi,
 
 Do you mean that there are sensors that can synchronise these parameters at
 frame level, or how? There are use cases for that but it doesn't limit to
 still capture.

No, sorry, I don't mean exposure value, by external exposure I meant the 
EXPOSURE pin. But in fact, as I see now, it is just another name for the 
TRIGGER pin:( But what we do have on some sensors, e.g., on MT9T031.

On mt9t031 they distinguish between the beginning of the shutter sequence, 
the exposure and the read sequence, and depending on a parameter they 
decide which signals to use to start which action.

 Are there any public datasheets that you know of on these?

I think, I just searched for mt9t031 and found a datasheet somewhere in 
the wild...

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

please update dvb-t es-Madrid scan file

2011-02-28 Thread Alberto Segura


Hello,

es-Madrid has to be updated:

* Removing channels:

  - EsMadrid TV (not functional)
  - Onda 6 (now la10)
  - CNN+ (now Gran Hermano 24h)
  - 40 Latino (inexistent)
  - Telecinco Sport (inexistent)
  - Telecinco Estrellas (inexistent)
  - Fly Music (inexistent)

*Adding channels:

  - La Sexta 2 (not correctly tuned)
  - La Sexta 3 (new channel)
  - Nitro (new channel)
  - Boing (new channel)
  - La Siete (new channel)
  - La Sexta HD (HD)
  - TVE HD - pruebas (HD)
  - Telecinco HD (HD)
  - Telemadrid HD (HD)

THANKS,

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

tuner and PAL decoder - runtime suspend

2011-02-28 Thread Raffaele Recalcati

I'm trying to develop the tda9885 poweron + setting paramteres driver,
using the v4l2 structure, that feeds a tvp5151.
I can declare a tvp5151 input as V4L2_INPUT_TYPE_TUNER and than create
a v4l2 subdev driver for tda9885.
I don't know if I need to put code in tvp5151 driver in order to
trigger the tda9885 power on + setting parameters
(v4l2_device_call_all), or if there is an automatic way (I think so)
to do it.
Finally I'll add runtime suspend and resume code for tda9885 and tvp5151.
Is there any recommendation to do this in the right way?

Thx,
Raffaele
--
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: [GIT PULL] TI WL 128x FM V4L2 driver

2011-02-28 Thread halli manjunatha

On Sun, Feb 27, 2011 at 4:28 PM, Mauro Carvalho Chehab
mche...@redhat.com wrote:

 Em 25-01-2011 03:48, halli manjunatha escreveu:
  Hi Mauro,
 
  Please pull the WL128x FM V4L2 driver from
  http://dev.omapzoom.org/pub/scm/manju/L24x-btfm.git fm_v4l2_upstream
 
  This is TI WL128x FM V4L2 driver and it introduces ‘wl128x’ folder
  under the ‘drivers/media/radio’. This driver enables support for FM RX
  and TX for Texas Instrument's WL128x (also compatible with WL127x)
  WiLink chip sets. The V4L2 FM driver can work in either Rx or Tx mode,
  and V4L2 interfaces are provided for both.
 
  Texas Instrument's WL128x chip set packs BT, FM, GPS and WLAN in a
  single die with BT, FM and GPS being interfaced over a single UART.
  This driver works on top of the shared transport line discipline
  driver. This driver can also be made use for the WL127x version of the
  chip which packs BT, FM and WLAN only.
 
  This driver has been reviewed by various folks within TI and also in
  Linux media community. The driver has been tested extensively on TI
  platforms and we believe that it is ready for merge into mainline.

 Applied, thanks.

 From what I understood from your comments, this driver will also cover
 wl127x chips. As such, it would be better to double check if all 
 functionalities
 present at drivers/media/radio/radio-wl1273.c (assuming that wl1273 is 
 covered)
 are also on the new driver, and, if not, merge the remaining ones and 
 deprecate
 the wl1273-specific driver.

 Cheers,
 Mauro

Yes, this driver supports all the functionalities which are supported
by radio-wl1273.c [But our driver is on UART while wl1273 is based on
i2c..]

NOTE: V4L2 FM driver depend upon an underlying TI_ST driver which is
the core transport driver [based on UART, it is a ldisc driver]

Updates to TI-ST driver happen on linux-next tree on kernel.org and
are planned to be released in 2.6.39.

Since your tree
@[http://git.linuxtv.org/media_tree.git?a=shortlog;h=refs/heads/staging/for_v2.6.39]

lags behind the linux-next tree, the recent updates to TI-ST driver
are missing on your tree.

Unfortunately these would cause a build failure for the V4L2 driver,
since the APIs have changed on the TI-ST driver.


So, I will provide you one patch to make the present driver to work
with latest ST driver once your tree moves to 2.6.38-rc6+ kernel.

Regards
Manju
 
  The following changes since commit db309d3d54c2f721dd1176ce86c63b0381c0a258:
    Mauro Carvalho Chehab (1):
          [media] add support for Encore FM3
 
  are available in the git repository at:
 
    http://dev.omapzoom.org/pub/scm/manju/L24x-btfm.git fm_v4l2_upstream
 
  Manjunatha Halli (7):
        drivers:media:radio: wl128x: FM Driver common header file
        drivers:media:radio: wl128x: FM Driver V4L2 sources
        drivers:media:radio: wl128x: FM Driver Common sources
        drivers:media:radio: wl128x: FM driver RX sources
        drivers:media:radio: wl128x: FM driver TX sources
        drivers:media:radio: wl128x: Kconfig  Makefile for wl128x driver
        drivers:media:radio: Update Kconfig and Makefile for wl128x FM driver
 
   drivers/media/radio/Kconfig               |    3 +
   drivers/media/radio/Makefile              |    1 +
   drivers/media/radio/wl128x/Kconfig        |   17 +
   drivers/media/radio/wl128x/Makefile       |    6 +
   drivers/media/radio/wl128x/fmdrv.h        |  244 +
   drivers/media/radio/wl128x/fmdrv_common.c | 1677 
  +
   drivers/media/radio/wl128x/fmdrv_common.h |  402 +++
   drivers/media/radio/wl128x/fmdrv_rx.c     |  847 +++
   drivers/media/radio/wl128x/fmdrv_rx.h     |   59 +
   drivers/media/radio/wl128x/fmdrv_tx.c     |  425 
   drivers/media/radio/wl128x/fmdrv_tx.h     |   37 +
   drivers/media/radio/wl128x/fmdrv_v4l2.c   |  580 ++
   drivers/media/radio/wl128x/fmdrv_v4l2.h   |   33 +
   13 files changed, 4331 insertions(+), 0 deletions(-)
   create mode 100644 drivers/media/radio/wl128x/Kconfig
   create mode 100644 drivers/media/radio/wl128x/Makefile
   create mode 100644 drivers/media/radio/wl128x/fmdrv.h
   create mode 100644 drivers/media/radio/wl128x/fmdrv_common.c
   create mode 100644 drivers/media/radio/wl128x/fmdrv_common.h
   create mode 100644 drivers/media/radio/wl128x/fmdrv_rx.c
   create mode 100644 drivers/media/radio/wl128x/fmdrv_rx.h
   create mode 100644 drivers/media/radio/wl128x/fmdrv_tx.c
   create mode 100644 drivers/media/radio/wl128x/fmdrv_tx.h
   create mode 100644 drivers/media/radio/wl128x/fmdrv_v4l2.c
   create mode 100644 drivers/media/radio/wl128x/fmdrv_v4l2.h
 

 --
 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: [DVB] Maintainers of dvb_core and budget_ci modules - Patches proposal

2011-02-28 Thread Andreas Oberritter

Hello Sébastien,

On 02/28/2011 12:26 PM, Sébastien RAILLARD (COEXSI) wrote:
 I would like to discuss and submit some patches I have developed for these
 modules:
 - dvb_core: add an option for logging the PDU exchanged with the CAM for
 debugging purposes
 - dvb_core: clean all ring buffers associated with CAM when a device is
 opened
 - budget_ci: print information about CI firmware used
 - budget_ci: add module option for disabling the IR receiver and the IRQ
 mode

please, just send your patches to the mailing list, with a description
of what problems they solve and with your sign-off.

Regards,
Andreas
--
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: [RFC] snapshot mode, flash capabilities and control

2011-02-28 Thread Andy Walls

On Mon, 2011-02-28 at 12:17 +0100, Hans Verkuil wrote:
 On Monday, February 28, 2011 12:07:33 Laurent Pinchart wrote:

   So, do I understand it right, that currently there are drivers, that
   overwrite the last buffers while waiting for a new one, and ones, that
   stop capture for that time.
 
 Does anyone know which drivers stop capture if there are no buffers 
 available? 
 I'm not aware of any.

Not that it is a camera driver, but...

cx18 will stall the stream, due to the CX23418 engine being starved of
buffers for that stream, if the application doesn't read the buffers.
The reasoning for this behavior is that one large gap is better than a
series of small gaps, if the application has fallen behind.

The exceptional case is the cx18 MPEG Index stream, which will steal the
oldest buffers back in the call to cx18_stream_rotate_idx_mdls().

The CX23418 engine seems to gracefully handle being starved of buffers
for a stream for a period of time.

This driver does not use videobuf currently.

-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: [RFC] snapshot mode, flash capabilities and control

2011-02-28 Thread Andy Walls

On Mon, 2011-02-28 at 08:33 -0500, Andy Walls wrote:
 On Mon, 2011-02-28 at 12:17 +0100, Hans Verkuil wrote:
  On Monday, February 28, 2011 12:07:33 Laurent Pinchart wrote:
 
So, do I understand it right, that currently there are drivers, that
overwrite the last buffers while waiting for a new one, and ones, that
stop capture for that time.
  
  Does anyone know which drivers stop capture if there are no buffers 
  available? 
  I'm not aware of any.
 
 Not that it is a camera driver, but...
 
 cx18 will stall the stream, due to the CX23418 engine being starved of
 buffers for that stream, if the application doesn't read the buffers.

 The reasoning for this behavior is that one large gap is better than a
 series of small gaps, if the application has fallen behind.
^
Gah.  That didn't make sense.  I need more coffee before sending email.


-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

[patch 1/1] mantis_pci: remove asm/pgtable.h include

2011-02-28 Thread Rtp

mantis_pci.c is including asm/pgtable.h and it's leading to a build failure on
arm. It has been noticed here :

https://buildd.debian.org/fetch.cgi?pkg=linux-2.6arch=armelver=2.6.38~rc6-1~experimental.1stamp=1298430952file=logas=raw

As this header doesn't seem to be used, I'm removing it. I've build tested it
with arm and x86.

Signed-off-by: Arnaud Patard arnaud.pat...@rtp-net.org
Index: linux-2.6/drivers/media/dvb/mantis/mantis_pci.c
===
--- linux-2.6.orig/drivers/media/dvb/mantis/mantis_pci.c2011-02-27 
21:21:57.370731954 +0100
+++ linux-2.6/drivers/media/dvb/mantis/mantis_pci.c 2011-02-27 
21:22:02.142211398 +0100
@@ -22,7 +22,6 @@
 #include linux/moduleparam.h
 #include linux/kernel.h
 #include asm/io.h
-#include asm/pgtable.h
 #include asm/page.h
 #include linux/kmod.h
 #include linux/vmalloc.h


--
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: [RFC] snapshot mode, flash capabilities and control

2011-02-28 Thread Sakari Ailus

On Mon, Feb 28, 2011 at 12:20:52PM +0100, Guennadi Liakhovetski wrote:
   Sorry, not sure what you mean. Do you mean different APIs when the flash
   is controlled directly by the sensor and by an external controller? No, of
   course we need one API, but you either issue those ioctl()s to the sensor
   (sub)device, or to the dedicated flash (sub)device. If you mean my minor
   subset above, then I was trying to say, that this is a basis, that has to
   be extended, but not, that we will develop a new API for more complicated
   cases.
  
  I think I misunderstood you originally, sorry. I should have properly read 
  the
  RFC. :-)
  
  Your proposal of the flash mode is good, but what about software strobe (a
  little more on that below)?
  
  Also, what about making this a V4L2 control instead?
 
 These are two things, I think: first we have to decide which functions we 
 need, second - how to implement them. Sure, controls are also a 
 possibility.

Agreed.

...

  This doesn't solve the flash/capture synchronization problem 
  though. I
  don't
  think we need a dedicated snapshot capture mode at the V4L2 level. A
  way to
  configure the sensor to react on an external trigger provided by the
  flash
  controller is needed, and that could be a control on the flash
  sub-device.
 
 Well... Sensors call this a snapshot mode. I don't care that much 
 how
 we
 _call_ it, but I do think, that we should be able to use it.

Some sensors and webcams might have that, but newer camera solutions
tend to contain a raw bayer sensor and and ISP. There is no concept of
snapsnot mode in these sensors.
   
   Hm, I am not sure I understand, why sensors with DSPs in them should have
   no notion of a snapshot mode. Do they have no strobe / trigger pins? And
   no built in possibility to synchronize with a flash?
  
  I was referring to ISPs such as the OMAP 3 ISP. Some hardware have a flash
  strobe pin while some doesn't (such as the N900).
 
 Of course, if no flash is present, you don't have to support it;)

There is flash but no hardware flash strobe. Ok? :-)

  Still, even if the strobe pin is missing it should be possible to allow
  strobing the flash by using software strobe (usually an I2C message).
  
  I agree using a hardware strobe is much much better if it's available.
 
 Again - don't understand. Above (i2c message) you're referring to the 
 sensor. But I don't think toggling the flash on per-frame basis from 

I'm referring to the flash controller, not the sensor. They're often
controlled using the I2C bus.

 software via the sensor makes much sense. That way you could also just 
 wire your flash to a GPIO. The main advantage of a sensor-controlled flash 
 is, that is toggles the flash automatically, synchronised with its image 
 read-out. You would, however, toggle the flash manually, if you just 

This is very true but unfortunately not all hardware has separate flash
strobe signal.

 wanted to turn it on permanently (torch-mode).

Not quite. There are use cases for the torch mode (an application called
Torch, for example).

In case the hardware strobe is absent the flash must be strobed using
software. This means that the user has to be better aware of the sensor
pixel area exposure timing than otherwise would be necessary.

 Hm, don't think only the flash subdevice has to know about this.
 First,
 you have to switch the sensor into that mode. Second, it might be 
 either
 external trigger from the flash controller, or a programmed trigger 
 and
 a
 flash strobe from the sensor to the flash (controller). Third, well, 
 not
 quite sure, but doesn't the host have to know about the snapshot mode?

I do not favour adding use case type of functionality to interfaces that
do not necessarily need it. Would the concept of a snapshot be
parametrisable on V4L2 level?
   
   I am open to this. I don't have a good idea of whether camera hosts have
   to know about the snapshot mode or not. It's open for discussion.
  
  What functionality would the snapshot mode provide? Flash synchronisation?
  Something else?
 
 Also pre-defined number of images, enabling of the trigger pin and trigger 
 i2c command. Just noticed - on mt9t031 and mt9v022 the snapshot mode also 
 enables externally controlled exposure...

Is the externally controlled exposure somehow essentially different from
just sending new esposure settings to the sensor via I2C?

  I have to admit I don't know of any hardware which would recognise a concept
  of snapshot. Do you have a smart sensor which does this, for example? The
  only hardware support for the flash use I know of is the flash strobe 
  signal.
 
 Several Aptina / Micron sensors have such a mode, e.g., mt9p031, mt9t031, 
 mt9v022, mt9m001, also ov7725 from OmniVision (there it's called a Single 
 frame mode), and, I presume, many others. And no, those are not some

Re: [RFC] snapshot mode, flash capabilities and control

2011-02-28 Thread Sakari Ailus

On Mon, Feb 28, 2011 at 01:44:25PM +0100, Guennadi Liakhovetski wrote:
 On Mon, 28 Feb 2011, Sakari Ailus wrote:
 
  On Mon, Feb 28, 2011 at 12:37:06PM +0100, Guennadi Liakhovetski wrote:
   So, you'd also need a separate control for external exposure, there are 
   also sensors, that can be configured to different shutter / exposure / 
   readout sequence controlling... No, we don't have to support all that 
   variety, but we have to be aware of it, while making decisions;)
  
  Hi Guennadi,
  
  Do you mean that there are sensors that can synchronise these parameters at
  frame level, or how? There are use cases for that but it doesn't limit to
  still capture.
 
 No, sorry, I don't mean exposure value, by external exposure I meant the 
 EXPOSURE pin. But in fact, as I see now, it is just another name for the 
 TRIGGER pin:( But what we do have on some sensors, e.g., on MT9T031.

The partial datasheet of that sensor I was able to find in Aptina website
suggests there are separate trigger and strobe pins. Trigger is another name
for global reset which can be performed over the I2C as well, also on that
sensor.

 On mt9t031 they distinguish between the beginning of the shutter sequence, 
 the exposure and the read sequence, and depending on a parameter they 
 decide which signals to use to start which action.

The global reset and mechanical shutter control is exclusively related to
operation with mechanical shutter as far as I know. This is essentially
extra hardware to enhance one use case a little.

What about newer sensors; do they support this kind of functionality?

Regards,

-- 
Sakari Ailus
sakari dot ailus at iki dot fi
--
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 -resend#1 1/1] V4L: videobuf, don't use dma addr as physical

On 02/28/2011 11:53 AM, Laurent Pinchart wrote:
 On Monday 28 February 2011 10:37:02 Jiri Slaby wrote:
 mem-dma_handle is a dma address obtained by dma_alloc_coherent which
 needn't be a physical address in presence of IOMMU. So ensure we are
 remapping (remap_pfn_range) the right page in __videobuf_mmap_mapper
 by using virt_to_phys(mem-vaddr) and not mem-dma_handle.
 
 Quoting arch/arm/include/asm/memory.h,
 
 /*
  * These are *only* valid on the kernel direct mapped RAM memory.

Which the DMA allocation shall be.

  * Note: Drivers should NOT use these. 

This is weird.

 They are the wrong
  * translation for translating DMA addresses.  Use the driver
  * DMA support - see dma-mapping.h.

Yes, ACK, and vice versa. DMA addresses cannot be used as physical ones.

  */
 static inline unsigned long virt_to_phys(const volatile void *x)
 {
 return __virt_to_phys((unsigned long)(x));
 }
 
 Why would you use physically contiguous memory if you have an IOMMU anyway ?

Sorry, what? When IOMMU is used, dma_alloc_* functions may return tags
as a DMA address, not a physical address. So using these DMA addresses
directly (e.g. in remap_pfn_range) is a bug.

Maybe there is a better way to convert a kernel address of the DMA
mapping into a physical frame, but I'm not aware of any...

 While at it, use PFN_DOWN instead of explicit shift.

 Signed-off-by: Jiri Slaby jsl...@suse.cz
 Cc: Mauro Carvalho Chehab mche...@infradead.org
 Cc: Konrad Rzeszutek Wilk konrad.w...@oracle.com
 ---
  drivers/media/video/videobuf-dma-contig.c |2 +-
  1 files changed, 1 insertions(+), 1 deletions(-)

 diff --git a/drivers/media/video/videobuf-dma-contig.c
 b/drivers/media/video/videobuf-dma-contig.c index c969111..19d3e4a 100644
 --- a/drivers/media/video/videobuf-dma-contig.c
 +++ b/drivers/media/video/videobuf-dma-contig.c
 @@ -300,7 +300,7 @@ static int __videobuf_mmap_mapper(struct videobuf_queue
 *q,

  vma-vm_page_prot = pgprot_noncached(vma-vm_page_prot);
  retval = remap_pfn_range(vma, vma-vm_start,
 - mem-dma_handle  PAGE_SHIFT,
 + PFN_DOWN(virt_to_phys(mem-vaddr))
   size, vma-vm_page_prot);
  if (retval) {
  dev_err(q-dev, mmap: remap failed with error %d. , retval);
 

regards,
-- 
js
suse labs
--
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 -resend#1 1/1] V4L: videobuf, don't use dma addr as physical

Hi Jiri,

On Monday 28 February 2011 16:07:43 Jiri Slaby wrote:
 On 02/28/2011 11:53 AM, Laurent Pinchart wrote:
  On Monday 28 February 2011 10:37:02 Jiri Slaby wrote:
  mem-dma_handle is a dma address obtained by dma_alloc_coherent which
  needn't be a physical address in presence of IOMMU. So ensure we are
  remapping (remap_pfn_range) the right page in __videobuf_mmap_mapper
  by using virt_to_phys(mem-vaddr) and not mem-dma_handle.
  
  Quoting arch/arm/include/asm/memory.h,
  
  /*
  
   * These are *only* valid on the kernel direct mapped RAM memory.
 
 Which the DMA allocation shall be.
 
   * Note: Drivers should NOT use these.
 
 This is weird.
 
  They are the wrong
  
   * translation for translating DMA addresses.  Use the driver
   * DMA support - see dma-mapping.h.
 
 Yes, ACK, and vice versa. DMA addresses cannot be used as physical ones.
 
   */
  
  static inline unsigned long virt_to_phys(const volatile void *x)
  {
  
  return __virt_to_phys((unsigned long)(x));
  
  }
  
  Why would you use physically contiguous memory if you have an IOMMU
  anyway ?
 
 Sorry, what? When IOMMU is used, dma_alloc_* functions may return tags
 as a DMA address, not a physical address. So using these DMA addresses
 directly (e.g. in remap_pfn_range) is a bug.

What I mean is that videobuf-dma-contig is meant to be used by drivers that 
require physically contiguous memory. If the system has an IOMMU, why would 
drivers need that ?

 Maybe there is a better way to convert a kernel address of the DMA
 mapping into a physical frame, but I'm not aware of any...
 
  While at it, use PFN_DOWN instead of explicit shift.
  
  Signed-off-by: Jiri Slaby jsl...@suse.cz
  Cc: Mauro Carvalho Chehab mche...@infradead.org
  Cc: Konrad Rzeszutek Wilk konrad.w...@oracle.com
  ---
  
   drivers/media/video/videobuf-dma-contig.c |2 +-
   1 files changed, 1 insertions(+), 1 deletions(-)
  
  diff --git a/drivers/media/video/videobuf-dma-contig.c
  b/drivers/media/video/videobuf-dma-contig.c index c969111..19d3e4a
  100644 --- a/drivers/media/video/videobuf-dma-contig.c
  +++ b/drivers/media/video/videobuf-dma-contig.c
  @@ -300,7 +300,7 @@ static int __videobuf_mmap_mapper(struct
  videobuf_queue *q,
  
 vma-vm_page_prot = pgprot_noncached(vma-vm_page_prot);
 retval = remap_pfn_range(vma, vma-vm_start,
  
  -   mem-dma_handle  PAGE_SHIFT,
  +   PFN_DOWN(virt_to_phys(mem-vaddr))
  
  size, vma-vm_page_prot);
 
 if (retval) {
 
 dev_err(q-dev, mmap: remap failed with error %d. , retval);

-- 
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: [PATCH v2 -resend#1 1/1] V4L: videobuf, don't use dma addr as physical

2011-02-28 Thread Konrad Rzeszutek Wilk

On Mon, Feb 28, 2011 at 10:37:02AM +0100, Jiri Slaby wrote:
 mem-dma_handle is a dma address obtained by dma_alloc_coherent which
 needn't be a physical address in presence of IOMMU. So ensure we are

Can you add a comment why you are fixing it? Is there a bug report for this?
Under what conditions did you expose this fault?

You also might want to mention that needn't be a physical address as
a hardware IOMMU can (and most likely) will return a bus address where
physical != bus address.

Otherwise you can stick 'Reviewed-by: Konrad Rzeszutek Wilk 
konrad.w...@oracle.com'
on it.

 remapping (remap_pfn_range) the right page in __videobuf_mmap_mapper
 by using virt_to_phys(mem-vaddr) and not mem-dma_handle.
 
 While at it, use PFN_DOWN instead of explicit shift.
 
 Signed-off-by: Jiri Slaby jsl...@suse.cz
 Cc: Mauro Carvalho Chehab mche...@infradead.org
 Cc: Konrad Rzeszutek Wilk konrad.w...@oracle.com
 ---
  drivers/media/video/videobuf-dma-contig.c |2 +-
  1 files changed, 1 insertions(+), 1 deletions(-)
 
 diff --git a/drivers/media/video/videobuf-dma-contig.c 
 b/drivers/media/video/videobuf-dma-contig.c
 index c969111..19d3e4a 100644
 --- a/drivers/media/video/videobuf-dma-contig.c
 +++ b/drivers/media/video/videobuf-dma-contig.c
 @@ -300,7 +300,7 @@ static int __videobuf_mmap_mapper(struct videobuf_queue 
 *q,
  
   vma-vm_page_prot = pgprot_noncached(vma-vm_page_prot);
   retval = remap_pfn_range(vma, vma-vm_start,
 -  mem-dma_handle  PAGE_SHIFT,
 +  PFN_DOWN(virt_to_phys(mem-vaddr))
size, vma-vm_page_prot);
   if (retval) {
   dev_err(q-dev, mmap: remap failed with error %d. , retval);
 -- 
 1.7.4.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

Fwd: scan file norway, bergen

2011-02-28 Thread Thomas Amland

-- Forwarded message --
From: Thomas Amland thomas.aml...@gmail.com
Date: Mon, Feb 28, 2011 at 4:03 PM
Subject: scan file norway, bergen
To: linux-...@linuxtv.org


Created with w_scan, frequencies from http://www.ntv.no/dekningskart,
and confirmed with scan.

# Norway, Bergen
# T freq bw fec_hi fec_lo mod transmission-mode guard-interval hierarchy
T 57000 8MHz AUTO AUTO AUTO AUTO AUTO AUTO
T 61800 8MHz AUTO AUTO AUTO AUTO AUTO AUTO
T 65000 8MHz AUTO AUTO AUTO AUTO AUTO AUTO
T 69800 8MHz AUTO AUTO AUTO AUTO AUTO AUTO
T 73000 8MHz AUTO AUTO AUTO AUTO AUTO AUTO
--
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] Prof 7301: switching frontend to stv090x, fixing LOCK FAILED issue

В сообщении от 28 февраля 2011 13:37:01 автор Mariusz Bialonczyk написал:
 On 2011-01-16 21:44, Mariusz Bialonczyk wrote:
  Fixing the very annoying tunning issue. When switching from DVB-S2 to
  DVB-S, it often took minutes to have a lock.
  
   [...]
  
  The patch is changing the frontend from stv0900 to stv090x.
  The card now works much more reliable. There is no problem with switching
  from DVB-S2 to DVB-S, tunning works flawless.
 
 Igor, can I get your ACK on this patch?
 
 regards,
Never. 
Think first what you are asking for.

-- 
Igor M. Liplianin
Microsoft Windows Free Zone - Linux used for all Computing Tasks
--
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: [RFC/PATCH 1/2] v4l: videobuf2: Handle buf_queue errors

2011-02-28 Thread Pawel Osciak

Hi Laurent,
A few questions from me below. I feel we need to talk about this
change a bit more, it introduces some recovery and consistency
problems, unless I'm missing something.

On Sun, Feb 27, 2011 at 10:12, Laurent Pinchart
laurent.pinch...@ideasonboard.com wrote:
 videobuf2 expects drivers to check buffer in the buf_prepare operation
 and to return success only if the buffer can queued without any issue.

 For hot-pluggable devices, disconnection events need to be handled at
 buf_queue time. Checking the disconnected flag and adding the buffer to
 the driver queue need to be performed without releasing the driver
 spinlock, otherwise race conditions can occur in which the driver could
 still allow a buffer to be queued after the disconnected flag has been
 set, resulting in a hang during the next DQBUF operation.

 This problem can be solved either in the videobuf2 core or in the device
 drivers. To avoid adding a spinlock to videobuf2, make buf_queue return
 an int and handle buf_queue failures in videobuf2. Drivers must not
 return an error in buf_queue if the condition leading to the error can
 be caught in buf_prepare.

 Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
 ---
  drivers/media/video/videobuf2-core.c |   32 ++--
  include/media/videobuf2-core.h       |    2 +-
  2 files changed, 27 insertions(+), 7 deletions(-)

 diff --git a/drivers/media/video/videobuf2-core.c 
 b/drivers/media/video/videobuf2-core.c
 index cc7ab0a..1d81536 100644
 --- a/drivers/media/video/videobuf2-core.c
 +++ b/drivers/media/video/videobuf2-core.c
 @@ -798,13 +798,22 @@ static int __qbuf_mmap(struct vb2_buffer *vb, struct 
 v4l2_buffer *b)
  /**
  * __enqueue_in_driver() - enqueue a vb2_buffer in driver for processing
  */
 -static void __enqueue_in_driver(struct vb2_buffer *vb)
 +static int __enqueue_in_driver(struct vb2_buffer *vb)
  {
        struct vb2_queue *q = vb-vb2_queue;
 +       int ret;

        vb-state = VB2_BUF_STATE_ACTIVE;
        atomic_inc(q-queued_count);
 -       q-ops-buf_queue(vb);
 +       ret = q-ops-buf_queue(vb);
 +       if (ret == 0)
 +               return 0;
 +
 +       vb-state = VB2_BUF_STATE_ERROR;
 +       atomic_dec(q-queued_count);
 +       wake_up_all(q-done_wq);
 +
 +       return ret;

Unless I am missing something, when this happens for an n-th buffer,
we wake up all, but only one buffer will have the ERROR state, all the
other will be in QUEUED state. This will mess up return values from
dqbuf (if this happens on streamon) for other buffers, they will have
their V4L2_BUF_FLAG_QUEUED set after dqbuf. Also, returning 0 from
DQBUF and the V4L2_BUF_FLAG_ERROR for the failed buffer suggests that
streaming may continue.

So how do we recover from this disconnection event? What is the
general idea? If buf_queue fails, can we restart from some point (i.e.
reuse the buffers later) or do we have to clean up completely (i.e.
deallocate, etc.)? Right now we are staying in an undefined state.
If we cannot recover, we shouldn't be setting V4L2_BUF_FLAG_ERROR, but
returning a stronger error instead and maybe clean up the rest, which
is not waited for somehow. If we can recover on the other hand, we
shouldn't be probably waking up all sleepers or at least giving them
meaningful errors.

  }
  /**
 @@ -890,8 +899,13 @@ int vb2_qbuf(struct vb2_queue *q, struct v4l2_buffer *b)
         * If already streaming, give the buffer to driver for processing.
         * If not, the buffer will be given to driver on next streamon.
         */
 -       if (q-streaming)
 -               __enqueue_in_driver(vb);
 +       if (q-streaming) {
 +               ret = __enqueue_in_driver(vb);
 +               if (ret  0) {
 +                       dprintk(1, qbuf: buffer queue failed\n);
 +                       return ret;
 +               }
 +       }


What errors can be allowed to be returned from driver here? EIO? Also,
isn't returning an error here to userspace suggesting that qbuf didn't
happen? But it actually did happen, we put the buffer onto vb2 list
and set it state to QUEUED. From the point of view of vb2, the buffer
is on its queue, but the userspace may not think so.

        dprintk(1, qbuf of buffer %d succeeded\n, vb-v4l2_buf.index);
        return 0;
 @@ -1101,6 +1115,7 @@ EXPORT_SYMBOL_GPL(vb2_dqbuf);
  int vb2_streamon(struct vb2_queue *q, enum v4l2_buf_type type)
  {
        struct vb2_buffer *vb;
 +       int ret;

        if (q-fileio) {
                dprintk(1, streamon: file io in progress\n);
 @@ -1139,8 +1154,13 @@ int vb2_streamon(struct vb2_queue *q, enum 
 v4l2_buf_type type)
         * If any buffers were queued before streamon,
         * we can now pass them to driver for processing.
         */
 -       list_for_each_entry(vb, q-queued_list, queued_entry)
 -               __enqueue_in_driver(vb);
 +       list_for_each_entry(vb, q-queued_list, queued_entry) {
 +               ret = __enqueue_in_driver(vb);
 +               if

Re: [PATCH v2 -resend#1 1/1] V4L: videobuf, don't use dma addr as physical

On 02/28/2011 04:14 PM, Laurent Pinchart wrote:
 Hi Jiri,
 
 On Monday 28 February 2011 16:07:43 Jiri Slaby wrote:
 On 02/28/2011 11:53 AM, Laurent Pinchart wrote:
 On Monday 28 February 2011 10:37:02 Jiri Slaby wrote:
 mem-dma_handle is a dma address obtained by dma_alloc_coherent which
 needn't be a physical address in presence of IOMMU. So ensure we are
 remapping (remap_pfn_range) the right page in __videobuf_mmap_mapper
 by using virt_to_phys(mem-vaddr) and not mem-dma_handle.

 Quoting arch/arm/include/asm/memory.h,

 /*

  * These are *only* valid on the kernel direct mapped RAM memory.

 Which the DMA allocation shall be.

  * Note: Drivers should NOT use these.

 This is weird.

 They are the wrong

  * translation for translating DMA addresses.  Use the driver
  * DMA support - see dma-mapping.h.

 Yes, ACK, and vice versa. DMA addresses cannot be used as physical ones.

  */

 static inline unsigned long virt_to_phys(const volatile void *x)
 {

 return __virt_to_phys((unsigned long)(x));

 }

 Why would you use physically contiguous memory if you have an IOMMU
 anyway ?

 Sorry, what? When IOMMU is used, dma_alloc_* functions may return tags
 as a DMA address, not a physical address. So using these DMA addresses
 directly (e.g. in remap_pfn_range) is a bug.
 
 What I mean is that videobuf-dma-contig is meant to be used by drivers that 
 require physically contiguous memory. If the system has an IOMMU, why would 
 drivers need that ?

Aha. They actually need not but they would need do the mapping
themselves which they currently do not.

IOW the vbuf-dma-contig allocator is used unconditionally in the few
drivers I checked.

BUT Even if they need only one page and use vbuf-dma-contig, which I
don't see a reason not to, it will cause problems too.

regards,
-- 
js
suse labs
--
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 -resend#1 1/1] V4L: videobuf, don't use dma addr as physical

On 02/28/2011 03:53 PM, Konrad Rzeszutek Wilk wrote:
 On Mon, Feb 28, 2011 at 10:37:02AM +0100, Jiri Slaby wrote:
 mem-dma_handle is a dma address obtained by dma_alloc_coherent which
 needn't be a physical address in presence of IOMMU. So ensure we are
 
 Can you add a comment why you are fixing it? Is there a bug report for this?
 Under what conditions did you expose this fault?

No, by a just peer review when I was looking for something completely
different.

 You also might want to mention that needn't be a physical address as
 a hardware IOMMU can (and most likely) will return a bus address where
 physical != bus address.

Mauro, do you want me to resend this with such an udpate in the changelog?

 Otherwise you can stick 'Reviewed-by: Konrad Rzeszutek Wilk 
 konrad.w...@oracle.com'
 on it.

thanks,
-- 
js
suse labs
--
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

Bulding az6007 module fails

2011-02-28 Thread Malte Gell

Hello,

Terratec has released sources for the AzureWave 6007 chipset at
http://linux.terratec.de/files/TERRATEC_H7_Linux.tar.gz

I have merged these sources into a 2.6.38-rc tree and tried to compile these 
modules, but I get an error. Can someone tell me how to fix this in order to 
build the modules? Maybe these sources could even become part of the official 
Linux kernel? Below is the output when I try to buld the modules.

Thanx in advance
Malte

CALLscripts/checksyscalls.sh
  CC [M]  drivers/media/dvb/dvb-usb/az6007.o
In file included from drivers/media/dvb/dvb-usb/az6007.c:11:
drivers/media/dvb/frontends/mt2063_cfg.h: In function ‘tuner_MT2063_Open’:
drivers/media/dvb/frontends/mt2063_cfg.h:62: error: ‘DVBFE_TUNER_OPEN’ 
undeclared (first use in this function)
drivers/media/dvb/frontends/mt2063_cfg.h:62: error: (Each undeclared 
identifier is reported only once
drivers/media/dvb/frontends/mt2063_cfg.h:62: error: for each function it 
appears in.)
drivers/media/dvb/frontends/mt2063_cfg.h: In function 
‘tuner_MT2063_SoftwareShutdown’:
drivers/media/dvb/frontends/mt2063_cfg.h:83: error: 
‘DVBFE_TUNER_SOFTWARE_SHUTDOWN’ undeclared (first use in this function)
drivers/media/dvb/frontends/mt2063_cfg.h: In function 
‘tuner_MT2063_ClearPowerMaskBits’:
drivers/media/dvb/frontends/mt2063_cfg.h:104: error: 
‘DVBFE_TUNER_CLEAR_POWER_MASKBITS’ undeclared (first use in this function)
drivers/media/dvb/dvb-usb/az6007.c: At top level:
drivers/media/dvb/dvb-usb/az6007.c:156: error: array type has incomplete 
element type
drivers/media/dvb/dvb-usb/az6007.c:535: error: ‘USB_PID_AZUREWAVE_6007’ 
undeclared here (not in a function)
drivers/media/dvb/dvb-usb/az6007.c:536: error: ‘USB_PID_TERRATEC_H7’ 
undeclared here (not in a function)
drivers/media/dvb/dvb-usb/az6007.c:576: error: unknown field ‘rc_key_map’ 
specified in initializer
drivers/media/dvb/dvb-usb/az6007.c:576: error: initializer element is not 
constant
drivers/media/dvb/dvb-usb/az6007.c:576: error: (near initialization for 
‘az6007_properties.identify_state’)
drivers/media/dvb/dvb-usb/az6007.c:577: error: unknown field ‘rc_key_map_size’ 
specified in initializer
drivers/media/dvb/dvb-usb/az6007.c:577: error: invalid operands to binary / 
(have ‘struct usb_device_id *’ and ‘long unsigned int’)
drivers/media/dvb/dvb-usb/az6007.c:577: warning: missing braces around 
initializer
drivers/media/dvb/dvb-usb/az6007.c:577: warning: (near initialization for 
‘az6007_properties.rc’)
drivers/media/dvb/dvb-usb/az6007.c:577: error: initializer element is not 
constant
drivers/media/dvb/dvb-usb/az6007.c:577: error: (near initialization for 
‘az6007_properties.rc.mode’)
drivers/media/dvb/dvb-usb/az6007.c:578: error: unknown field ‘rc_interval’ 
specified in initializer
drivers/media/dvb/dvb-usb/az6007.c:578: warning: initialization makes pointer 
from integer without a cast
drivers/media/dvb/dvb-usb/az6007.c:579: error: unknown field ‘rc_query’ 
specified in initializer
drivers/media/dvb/dvb-usb/az6007.c:579: warning: initialization makes integer 
from pointer without a cast
drivers/media/dvb/dvb-usb/az6007.c:579: error: initializer element is not 
computable at load time
drivers/media/dvb/dvb-usb/az6007.c:579: error: (near initialization for 
‘az6007_properties.generic_bulk_ctrl_endpoint’)
make[4]: *** [drivers/media/dvb/dvb-usb/az6007.o] Fehler 1
make[3]: *** [drivers/media/dvb/dvb-usb] Fehler 2
make[2]: *** [drivers/media/dvb] Fehler 2
make[1]: *** [drivers/media] Fehler 2
make: *** [drivers] Fehler 2
(Fehler=error)
--
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: Well supported USB DVB-C device?

2011-02-28 Thread Benny Amorsen

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

 On 02/28/2011 02:02 AM, Malte Gell wrote:
 is there a DVB-C device with USB that is well supported by a recent kernel
 (2.6.38)?

 Anysee E30 C Plus is supported as far as I know.

I can confirm that. The only downside so far is that it seems to need a
lot of hand-holding by the CPU, which in turn leads to increased power
consumption.

 Note that new revision of Anysee E30 Combo Plus is no longer supported
 since they changed to new NXP silicon tuner. E30 Combo Plus and E30 C
 Plus are different devices.

Ouch. I really wish vendors would stop using the same name for different
devices.


/Benny
--
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] Prof 7301: switching frontend to stv090x, fixing LOCK FAILED issue

2011-02-28 Thread Andreas Oberritter

Hello Igor,

On 02/28/2011 04:41 PM, Igor M. Liplianin wrote:
 В сообщении от 28 февраля 2011 13:37:01 автор Mariusz Bialonczyk написал:
 On 2011-01-16 21:44, Mariusz Bialonczyk wrote:
 Fixing the very annoying tunning issue. When switching from DVB-S2 to
 DVB-S, it often took minutes to have a lock.

   [...]

 The patch is changing the frontend from stv0900 to stv090x.
 The card now works much more reliable. There is no problem with switching
 from DVB-S2 to DVB-S, tunning works flawless.

 Igor, can I get your ACK on this patch?

 regards,
 Never. 
 Think first what you are asking for.

for those who aren't involved in the development of these drivers, may I
ask you what's the problem with this patch?

Regards,
Andreas
--
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 v20 1/3] MFD: Wl1273 FM radio core: Add I2C IO functions.

2011-02-28 Thread Samuel Ortiz

Hi Matti,

On Mon, Feb 28, 2011 at 01:02:29PM +0200, Matti J. Aaltonen wrote:
 Add I2C IO functions.
 Change the IO operation from read to write in wl1273_fm_set_volume.
 Update the year of the copyright statement.
 Remove two unnecessary calls to i2c_set_clientdata.
Provided that you add a changelog relevant to the patch itself, and not to the
v1-v2 diff:
Acked-by: Samuel Ortiz sa...@linux.intel.com

Cheers,
Samuel.

-- 
Intel Open Source Technology Centre
http://oss.intel.com/
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] Prof 7301: switching frontend to stv090x, fixing LOCK FAILED issue

В сообщении от 28 февраля 2011 18:09:56 автор Andreas Oberritter написал:
 Hello Igor,
 
 On 02/28/2011 04:41 PM, Igor M. Liplianin wrote:
  В сообщении от 28 февраля 2011 13:37:01 автор Mariusz Bialonczyk написал:
  On 2011-01-16 21:44, Mariusz Bialonczyk wrote:
  Fixing the very annoying tunning issue. When switching from DVB-S2 to
  DVB-S, it often took minutes to have a lock.
  
[...]
  
  The patch is changing the frontend from stv0900 to stv090x.
  The card now works much more reliable. There is no problem with
  switching from DVB-S2 to DVB-S, tunning works flawless.
  
  Igor, can I get your ACK on this patch?
  
  regards,
  
  Never.
  Think first what you are asking for.
 
 for those who aren't involved in the development of these drivers, may I
 ask you what's the problem with this patch?
For those who ...
He asked me to get rid of my driver. Why should I?
I have 7301, test it myself and see nothing bad with stv0900.
Obviously, I better patch stv0900 then convert the driver to stv090x.
And if you ask something then be prepaired to not be given smth.

Best Regards
Igor
 
 Regards,
 Andreas

-- 
Igor M. Liplianin
Microsoft Windows Free Zone - Linux used for all Computing Tasks
--
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

V4L2 'brainstorming' meeting in Warsaw, March 2011

Hello everyone!

The idea of v4l2 'brainstorming' session came out after a few discussions on 
#v4l
IRC channel about various RFCs and proposals that have been posted recently. I
would like to announce that Samsung Poland RD Center (SPRC) agreed to take an
opportunity to organize this meeting. I've got a reservation for a conference
room for 16-18 March 2011 in our office.

I would like to invite all of You for this V4L2 'brainstorming' session.

I hope that this initial meeting date I've selected will fit us. We have 2 only
weeks for the preparation, but I hope we will manage. I'm open for another date
and if required I will change the reservation.

The meeting will last 3 days what gives us a lot of possibility to present the
issues and proposals, discuss them further and work out a solution that will be
accepted by others.

From SPRC 4 developers will attend this meeting: Sylwester Nawrocki (s5p-fimc
author), Kamil Debski (s5p-mfc author), Tomasz Stanislawski (s5p-tv author) and 
me
(videobuf2 co-author and kernel lead developer in SPRC).

A quick summary of the above:

1. Type of the meeting:
V4L2 'brainstorming' mini-summit :)

2. Place:
Samsung Poland RD Center
Polna 11 Street
00-633 Warsaw, Poland

3. Date:
16-18 March 2011

4. Agenda
TBD, everyone is welcomed to put his items here :)

I will post some travel information tomorrow. SPRC office is in the center of 
Warsaw,
there are a few hotels nearby. I will check for a free rooms and I will make a
recommendation soon. I hope we will meet together soon!

Best regards
--
Marek Szyprowski
Samsung Poland RD Center

The above message is intended solely for the named addressee and may contain 
trade secret, industrial technology or privileged and confidential information 
otherwise protected under applicable law. Any unauthorized dissemination, 
distribution, copying or use of the information contained in this communication 
is strictly prohibited. If you have received this communication in error, 
please notify sender by email and delete this communication immediately.


Powyższa wiadomość przeznaczona jest wyłącznie dla adresata niniejszej 
wiadomości i może zawierać informacje będące tajemnicą handlową, tajemnicą 
przedsiębiorstwa oraz informacje o charakterze poufnym chronione obowiązującymi 
przepisami prawa. Jakiekolwiek nieuprawnione ich rozpowszechnianie, 
dystrybucja, kopiowanie lub użycie informacji zawartych w powyższej wiadomości 
jest zabronione. Jeśli otrzymałeś powyższą wiadomość omyłkowo, uprzejmie proszę 
poinformuj o tym fakcie drogą mailową nadawcę tej wiadomości oraz niezwłocznie 
usuń powyższą wiadomość ze swojego komputera.

V4L2 'brainstorming' meeting in Warsaw, March 2011

Hello everyone!

The idea of v4l2 'brainstorming' session came out after a few discussions on 
#v4l
IRC channel about various RFCs and proposals that have been posted recently. I
would like to announce that Samsung Poland RD Center (SPRC) agreed to take an
opportunity to organize this meeting. I've got a reservation for a conference
room for 16-18 March 2011 in our office.

I would like to invite all of You for this V4L2 'brainstorming' session.

I hope that this initial meeting date I've selected will fit us. We have 2 only
weeks for the preparation, but I hope we will manage. I'm open for another date
and if required I will change the reservation.

The meeting will last 3 days what gives us a lot of possibility to present the
issues and proposals, discuss them further and work out a solution that will be
accepted by others.

From SPRC 4 developers will attend this meeting: Sylwester Nawrocki (s5p-fimc
author), Kamil Debski (s5p-mfc author), Tomasz Stanislawski (s5p-tv author) and 
me
(videobuf2 co-author and kernel lead developer in SPRC).

A quick summary of the above:

1. Type of the meeting:
V4L2 'brainstorming' mini-summit :)

2. Place:
Samsung Poland RD Center
Polna 11 Street
00-633 Warsaw, Poland

3. Date:
16-18 March 2011

4. Agenda
TBD, everyone is welcomed to put his items here :)

I will post some travel information tomorrow. SPRC office is in the center of 
Warsaw,
there are a few hotels nearby. I will check for a free rooms and I will make a
recommendation soon. I hope we will meet together soon!

Best regards
--
Marek Szyprowski
Samsung Poland RD Center



The above message is intended solely for the named addressee and may contain 
trade secret, industrial technology or privileged and confidential information 
otherwise protected under applicable law. Any unauthorized dissemination, 
distribution, copying or use of the information contained in this communication 
is strictly prohibited. If you have received this communication in error, 
please notify sender by email and delete this communication immediately.


Powyższa wiadomość przeznaczona jest wyłącznie dla adresata niniejszej 
wiadomości i może zawierać informacje będące tajemnicą handlową, tajemnicą 
przedsiębiorstwa oraz informacje o charakterze poufnym chronione obowiązującymi 
przepisami prawa. Jakiekolwiek nieuprawnione ich rozpowszechnianie, 
dystrybucja, kopiowanie lub użycie informacji zawartych w powyższej wiadomości 
jest zabronione. Jeśli otrzymałeś powyższą wiadomość omyłkowo, uprzejmie proszę 
poinformuj o tym fakcie drogą mailową nadawcę tej wiadomości oraz niezwłocznie 
usuń powyższą wiadomość ze swojego komputera.

Remote control not working for Terratec Cinergy C (2.6.37 Mantis driver)

2011-02-28 Thread Jonas Hanschke

Hi,

despite lots of time spent tinkering around and looking for help on
the web, I've had no success in getting to work the remote control of
my DVB-C card.

It is a Terratec Cinergy C:
http://linuxtv.org/wiki/index.php/TerraTec_Cinergy_C_DVB-C

and am using the Mantis driver. Since it was merged into the kernel
tree in 2.6.33, watching TV works without patches, but the remote
control does not, although it is supposed to be supported, according
to the link above.

Kernel is a vanilla 2.6.37.2 with custom configuration on an old AMD
Athlon XP machine, running debian Squeeze.


When I modprobe the Mantis driver, the following IR-modules are pulled
in automagically:
ir_lirc_codec
lirc_dev
ir_core

However, no input device is created during module loading. dmesg output:
Mantis :01:0a.0: PCI INT A - Link[APC1] - GSI 16 (level, high) - IRQ 16
DVB: registering new adapter (Mantis DVB adapter)
IR LIRC bridge handler initialized
DVB: registering adapter 0 frontend 0 (Philips TDA10023 DVB-C)...

Am I missing some additional modules? Are there any dependencies on
other kernel config options that are not handled automatically by make
menuconf?

If additional information is needed, I will be happy to provide it.
However, I am not sure what is useful and what is not and did not want
to bloat this message.

Thanks in advance,

Jonas
--
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] DVB : add option to dump PDU exchanged with CAM in dvb_core

2011-02-28 Thread COEXSI

Dear all,

Here is a patch for the dvb_core module, you'll find it attached to this
message.

It's adding a new module integer parameter called cam_dump_pdu that can
have the following values:
- 0 (by default): don't dump PDU (do nothing)
- 1: Dump all PDU written and read on device through the syscall functions.
The PDU are dumped in segments of 16 bytes maximum written in hexadecimal.
- 2: like value 1 but remove the commonly used PDU for polling (generating a
lot of noise in the logs)

The goal of dumping PDU exchanged with CAM is to help debugging userland
applications and libraries.

This is my first patch submission, so I may have made some errors regarding
the submission rules.

Best regards,
Sebastien.


dvb_ca_en50221.patch
Description: Binary data

Re: V4L2 'brainstorming' meeting in Warsaw, March 2011

On Monday, February 28, 2011 18:11:47 Marek Szyprowski wrote:
 Hello everyone!
 
 The idea of v4l2 'brainstorming' session came out after a few discussions on 
 #v4l
 IRC channel about various RFCs and proposals that have been posted recently. I
 would like to announce that Samsung Poland RD Center (SPRC) agreed to take an
 opportunity to organize this meeting. I've got a reservation for a conference
 room for 16-18 March 2011 in our office.
 
 I would like to invite all of You for this V4L2 'brainstorming' session.
 
 I hope that this initial meeting date I've selected will fit us. We have 2 
 only
 weeks for the preparation, but I hope we will manage. I'm open for another 
 date
 and if required I will change the reservation.
 
 The meeting will last 3 days what gives us a lot of possibility to present the
 issues and proposals, discuss them further and work out a solution that will 
 be
 accepted by others.
 
 From SPRC 4 developers will attend this meeting: Sylwester Nawrocki (s5p-fimc
 author), Kamil Debski (s5p-mfc author), Tomasz Stanislawski (s5p-tv author) 
 and me
 (videobuf2 co-author and kernel lead developer in SPRC).
 
 A quick summary of the above:
 
 1. Type of the meeting:
 V4L2 'brainstorming' mini-summit :)
 
 2. Place:
 Samsung Poland RD Center
 Polna 11 Street
 00-633 Warsaw, Poland
 
 3. Date:
 16-18 March 2011
 
 4. Agenda
 TBD, everyone is welcomed to put his items here :)

In no particular order:

1) pipeline configuration, cropping and scaling:

http://www.mail-archive.com/linux-media@vger.kernel.org/msg27956.html
http://www.mail-archive.com/linux-media@vger.kernel.org/msg26630.html

2) HDMI API support

Some hotplug/CEC code can be found here:

http://www.mail-archive.com/linux-media@vger.kernel.org/msg28549.html

but Cisco will soon post RFCs on this topic as well.

3) Snapshot functionality.

http://www.mail-archive.com/linux-media@vger.kernel.org/msg28192.html
http://www.mail-archive.com/linux-media@vger.kernel.org/msg28490.html

If we finish quicker than expected, then we can also look at this:

- use of V4L2 as a frontend for SW/DSP codecs

Regards,

Hans

-- 
Hans Verkuil - video4linux developer - sponsored by Cisco
--
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: V4L2 'brainstorming' meeting in Warsaw, March 2011

On Monday 28 February 2011 19:03:39 Hans Verkuil wrote:
 On Monday, February 28, 2011 18:11:47 Marek Szyprowski wrote:

[snip]

  4. Agenda
  
  TBD, everyone is welcomed to put his items here :)
 
 In no particular order:
 
 1) pipeline configuration, cropping and scaling:
 
 http://www.mail-archive.com/linux-media@vger.kernel.org/msg27956.html
 http://www.mail-archive.com/linux-media@vger.kernel.org/msg26630.html
 
 2) HDMI API support
 
 Some hotplug/CEC code can be found here:
 
 http://www.mail-archive.com/linux-media@vger.kernel.org/msg28549.html
 
 but Cisco will soon post RFCs on this topic as well.
 
 3) Snapshot functionality.
 
 http://www.mail-archive.com/linux-media@vger.kernel.org/msg28192.html
 http://www.mail-archive.com/linux-media@vger.kernel.org/msg28490.html
 
 If we finish quicker than expected, then we can also look at this:
 
 - use of V4L2 as a frontend for SW/DSP codecs

In still no particular order:

 - Muxed formats (H.264 inside MJPEG)
 - H.264
 - Buffers pool
 - Entity information ioctl
 - Userspace drivers (OMX)
 - Sensor blanking/pixel-clock/frame-rate settings (including 
enumeration/discovery)
 - GL/ES in V4L2 devices

-- 
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: [PATCH v2 -resend#1 1/1] V4L: videobuf, don't use dma addr as physical

2011-02-28 Thread Mauro Carvalho Chehab

Em 28-02-2011 12:47, Jiri Slaby escreveu:
 On 02/28/2011 03:53 PM, Konrad Rzeszutek Wilk wrote:
 On Mon, Feb 28, 2011 at 10:37:02AM +0100, Jiri Slaby wrote:
 mem-dma_handle is a dma address obtained by dma_alloc_coherent which
 needn't be a physical address in presence of IOMMU. So ensure we are

 Can you add a comment why you are fixing it? Is there a bug report for this?
 Under what conditions did you expose this fault?
 
 No, by a just peer review when I was looking for something completely
 different.
 
 You also might want to mention that needn't be a physical address as
 a hardware IOMMU can (and most likely) will return a bus address where
 physical != bus address.
 
 Mauro, do you want me to resend this with such an udpate in the changelog?

Having it properly documented is always a good idea, especially since a similar
fix might be needed on other drivers that also need contiguous memory. While it
currently is used only on devices embedded on hardware with no iommu, there are
some x86 hardware that doesn't allow DMA scatter/gather.

Btw, it may be worth to take a look at vb2 dma contig module, as it might have
similar issues.

 Otherwise you can stick 'Reviewed-by: Konrad Rzeszutek Wilk 
 konrad.w...@oracle.com'
 on it.

Cheers,
Mauro
--
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:Mon Feb 28 19:00:27 CET 2011
git master:   1b59be2a6cdcb5a12e18d8315c07c94a624de48f
git media-master: gcc version:  i686-linux-gcc (GCC) 4.5.1
host hardware:x86_64
host os:  2.6.32.5

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

Detailed results are available here:

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

Full logs are available here:

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

The 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

Re: Bulding az6007 module fails

2011-02-28 Thread Torfinn Ingolfsen

Hello,

On Mon, Feb 28, 2011 at 4:49 PM, Malte Gell malte.g...@gmx.de wrote:
 Hello,

 Terratec has released sources for the AzureWave 6007 chipset at
 http://linux.terratec.de/files/TERRATEC_H7_Linux.tar.gz

 I have merged these sources into a 2.6.38-rc tree and tried to compile these
 modules, but I get an error.

I tried that myself a while ago (note: I'm not very familiar with
Linux drivers, so I might have done it wrong). Anyway, my effort is
documented here:
http://sites.google.com/site/tingox/asus_m2a-vm_hdmi_linux

Let us know if you
a) get any help
b) figure out a solution

Have a nice day.
-- 
Regards,
Torfinn Ingolfsen,
Norway
--
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] Prof 7301: switching frontend to stv090x, fixing LOCK FAILED issue

On 02/28/2011 06:01 PM, Igor M. Liplianin wrote:
 For those who ...
 He asked me to get rid of my driver. Why should I?
Maybe because (now) your frontend has problems with tunning on this card?
I though that references are known for you:
1. http://article.gmane.org/gmane.linux.drivers.video-input-infrastructure/24573
2. http://article.gmane.org/gmane.linux.drivers.video-input-infrastructure/25275
3. http://linuxdvb.org.ru/wbb/index.php?page=ThreadthreadID=641

And to be more specific: I am not asking to get rid of your driver,
my patch doesn't touch your stv0900 implementation, it only change the
frontend for one particular card.

 I have 7301, test it myself and see nothing bad with stv0900.
If it is working for you - lucky you! But keep in mind that it it doesn't
mean that it is working for others. Have you tested it with my patch applied?
Besides it is not using your frontend, maybe it just *work*?

 Obviously, I better patch stv0900 then convert the driver to stv090x.
Sure, go ahead... I am only wondering why wasn't you so helpful when I was
trying to contact you and offer debugging help when I discovered the problem
after I started using this card. Your only response was:
I know this issue. Your card is fine.
So now I resolved the problem myself and sent a working solution (tested
by some people - always with good results) and you disagree now.

I'm only hoping that a hardware *usability* will win over an ego!

regards,
-- 
Mariusz Bialonczyk
jabber/e-mail: ma...@skyboo.net
http://manio.skyboo.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: [GIT PATCHES FOR 2.6.39] cx23885, altera-ci: remove operator return value in void procedure

The following changes since commit 9e650fdb12171a5a5839152863eaab9426984317:

  [media] drivers:media:radio: Update Kconfig and Makefile for wl128x FM driver 
(2011-02-27 
07:50:42 -0300)

are available in the git repository at:
  git://linuxtv.org/liplianin/media_tree.git dual_dvb_t_c_ci_rf

Igor M. Liplianin (2):
  cx23885, altera-ci: remove operator return value in void procedure
  stv0900: speed up DVB-S searching

 drivers/media/dvb/frontends/stv0900_core.c |5 -
 drivers/media/video/cx23885/altera-ci.h|2 --
 2 files changed, 4 insertions(+), 3 deletions(-)
--
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] Prof 7301: switching frontend to stv090x, fixing LOCK FAILED issue

В сообщении от 28 февраля 2011 21:45:46 автор Mariusz Bialonczyk написал:
On 02/28/2011 06:01 PM, Igor M. Liplianin wrote:
For those who ...
He asked me to get rid of my driver. Why should I?

Maybe because (now) your frontend has problems with tunning on this card?
I though that references are known for you:
1.
http://article.gmane.org/gmane.linux.drivers.video-input-infrastructure/24
573 2.
http://article.gmane.org/gmane.linux.drivers.video-input-infrastructure/25
275 3. http://linuxdvb.org.ru/wbb/index.php?page=ThreadthreadID=641

And to be more specific: I am not asking to get rid of your driver,
my patch doesn't touch your stv0900 implementation, it only change the
frontend for one particular card.

I have 7301, test it myself and see nothing bad with stv0900.

If it is working for you - lucky you! But keep in mind that it it doesn't
mean that it is working for others. Have you tested it with my patch
applied? Besides it is not using your frontend, maybe it just *work*?

Obviously, I better patch stv0900 then convert the driver to stv090x.

Sure, go ahead... I am only wondering why wasn't you so helpful when I was
trying to contact you and offer debugging help when I discovered the
problem after I started using this card. Your only response was:
I know this issue. Your card is fine.
So now I resolved the problem myself and sent a working solution (tested
by some people - always with good results) and you disagree now.

I'm only hoping that a hardware *usability* will win over an ego!

regards,
Sorry, I have nothing against you personally.
I have excuses, but you not intresting, I think.
Peace, friendship, chewing gum, like we use to say in my childhood :)

Switching to other driver not helps me, so be patient.

I patched stv0900 and send pull request.
Tested on Prof 7301, 7500, NetUP Dual DVB-S2, DVBWorld 2104 cards by myself.
With all of that vendors I have good relationships.

--
Igor M. Liplianin
Microsoft Windows Free Zone - Linux used for all Computing Tasks
--
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] Prof 7301: switching frontend to stv090x, fixing LOCK FAILED issue

And to be more specific: I am not asking to get rid of your driver,
my patch doesn't touch your stv0900 implementation, it only change the
frontend for one particular card.

I have 7301, test it myself and see nothing bad with stv0900.

Obviously, I better patch stv0900 then convert the driver to stv090x.

I'm only hoping that a hardware *usability* will win over an ego!

regards,
http://git.linuxtv.org/liplianin/media_tree.git?a=shortlog;h=refs/heads/dual_dvb_t_c_ci_rf

Re: WinTV HVR-900 (usb 2040:6500) (model 65008) / no audio but clicking noise

2011-02-28 Thread AW

Hi!

Since I really need analog TV support, I would like to bring this up again... 
:-)

Now i hacked the em28xx module,
so that it would try to get the audio data via the em28xx_alsa module...

But that fails in the usb_submit_urb() call in the em28xx_init_audio_isoc() 
function, because:
wMaxPacketSize of endpoint 0x83 is 0...

Does someone still know how em28xx_alsa was to be used properly?
Is there some specialist, that could help me?
Markus R. doesnt like to do open src things anymore, or did I misunderstand 
that?

Btw: I have an em2882/em2883 chip, which needs to be handled by the em28xx_alsa 
module according to this page:
http://www.linuxtv.org/wiki/index.php/Em28xx_devices#em2880.2F2881.2F2883

Here is the em28xx related syslog from my box:
https://bugzilla.redhat.com/attachment.cgi?id=481332

Bye
Arne


--
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] Prof 7301: switching frontend to stv090x, fixing LOCK FAILED issue

On 02/28/2011 09:37 PM, Igor M. Liplianin wrote:
 Sorry, I have nothing against you personally.
me too :)

 I have excuses, but you not intresting, I think.
 Peace, friendship, chewing gum, like we use to say in my childhood :)
 
 Switching to other driver not helps me, so be patient.
 
 I patched stv0900 and send pull request.
I've tested it - and for the first sight it seems that it indeed
solves the problem. Thank you :)

And about frontend: I think I found a solution which I hope will
satisfy all of us. I think it would be great if user have
an alternative option to use stv090x frontend anyway. I mean your
frontend as default, but a module parameter which enables using
stv090x instead of stv0900 (enabling what's is inside my patch).
This will be a flexible solution which shouldn't harm anyone,
but instead gives an option.

Igor, Mauro, do you have objections against this solution?
If you agree, then I'll try to prepare an RFC patch for that.

regards,
-- 
Mariusz Bialonczyk
jabber/e-mail: ma...@skyboo.net
http://manio.skyboo.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: MCEUSB: falsly claims mass storage device

2011-02-28 Thread Jarod Wilson

On Feb 17, 2011, at 6:46 AM, Lucian Muresan wrote:

 On 09.02.2011 06:19, Jarod Wilson wrote:
 [...]
 Looks like bInterfaceNumber == 2 on this device. The patch to handle this
 similar to the conexant polaris devices should be pretty trivial. I'll
 try to get something together tomorrow.
 
 Hi,
 
 any news on this one?

I suck, but I have a patch in my local tree now. Need to build and
quickly test it to make sure it doesn't break the devices I've got,
then I'll get it posted.

-- 
Jarod Wilson
ja...@wilsonet.com



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

Re: [RFC] snapshot mode, flash capabilities and control

On Mon, 28 Feb 2011, Guennadi Liakhovetski wrote:

 On Mon, 28 Feb 2011, Hans Verkuil wrote:
 
  Does anyone know which drivers stop capture if there are no buffers 
  available? 
  I'm not aware of any.
 
 Many soc-camera hosts do that.
 
  I think this is certainly a good initial approach.
  
  Can someone make a list of things needed for flash/snapshot? So don't look 
  yet 
  at the implementation, but just start a list of functionalities that we 
  need 
  to support. I don't think I have seen that yet.
 
 These are not the features, that we _have_ to implement, these are just 
 the ones, that are related to the snapshot mode:
 
 * flash strobe (provided, we do not want to control its timing from 
   generic controls, and leave that to reasonable defaults or to 
   private controls)
 * trigger pin / command
 * external exposure
 * exposure mode (ERS, GRR,...)
 * use trigger or shutter for readout
 * number of frames to capture

Add

* multiple videobuffer queues

to the list

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

Re: [PATCH] Prof 7301: switching frontend to stv090x, fixing LOCK FAILED issue